[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