[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

[et-mgmt-tools] DNS-related trigger negatively affected by resolver check

I have been working on a cobbler dns zone factory trigger, which populates zone files according to a customizable regex-based hostname-ip-mapping setting.

The trigger is very basic now and uses static settings.  Essentially it

  • Checks to see whether the hostname is valid.
    • This is done by means of a modifiable regex-based function.
  • The hostname is converted to an IP address
    • This is done by means of a modifiable regex-based function.
  • Forward/Reverse DNS zone templates are cheetahfied and written to a zone directory.

Unfortunately, cobbler does two things that limit certain this kind of DNS trigger:

  1. The 'syncing' occurs prior to the call of this trigger (and, I would gather, all triggers).
    • This prohibits custom checks for a valid --name, among other arguments, before the actual sync should occur.
      • Basically, the cobbler check that I've traced (as show below in the get_pxe_filename definition) determines whether the --name is a valid MAC address or IP address (the actual checking functions found in utils.py) OR whether the --name is a resolveable hostname.
    • Custom checks are a good idea, because they promote moving policy to trigger-space.
  2. The check on 'resolveable hostnames'
    • This prevents modifications to zone files in triggers.
      • If the zone file(s) targeted for modification during the trigger mechanism do not possess name entries for the targeted systems (corresponding to system --name), cobbler will complain that --name does not resolve, and one receives an exception.
My problem is that, by (2) I cannot implement my trigger at all without modifying cobbler source code (to allow unresolvable names as argument for system adds).  If I were to modify the source code accordingly, I find the deeper problem (1), where although my custom check may prohibit a certain kind of hostname from being added to DNS, the system is *still* added, since syncing occurs prior to the call to the trigger.

This is an architectural question, which has strong bearing on the development of triggers, and a philosophical question as to whether policy ought to be pushed out to the triggers.

What would the best short-term approach to resolving this problem be?  I appreciate your time.

--BEGIN action_sync.py SNIPPER--
def get_pxe_filename(self,name_input):
        The configuration file for each system pxe uses is either
        a form of the MAC address of the hex version of the IP.  Not sure
        about ipv6 (or if that works).  The system name in the config file
        is either a system name, an IP, or the MAC, so figure it out, resolve
        the host if needed, and return the pxe directory name.
        if name_input == "default":
            return "default"
        name = utils.find_system_identifier(name_input)
        if utils.is_ip(name):
            return utils.get_host_ip(name)
        elif utils.is_mac(name):
            return "01-" + "-".join(name.split(":")).lower()
            raise cexceptions.CobblerException("err_resolv", name)
--END action_sync.py SNIPPET--


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]