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

Adam Rosenwald thestrider at gmail.com
Tue May 29 00:45:08 UTC 2007


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.
          o This is done by means of a modifiable regex-based function.
    * The hostname is converted to an IP address
          o 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.
                o 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.
                o 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()
        else:
            raise cexceptions.CobblerException("err_resolv", name)
--END action_sync.py SNIPPET--


--Adam
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/et-mgmt-tools/attachments/20070528/25bf7612/attachment.htm>


More information about the et-mgmt-tools mailing list