Here is what I've come to, on what I think would be suitable changes to lcfg-dhcpd; that is, here is my proposal for what I should go ahead and implement.

I would value comments, criticism and counter-proposals:

A. Preamble

  1. For background and general rationale, I refer you all back to the current problems discussed in previous emails; I won't repeat that background here.

  2. I am completely disregarding any considerations of the contents of our inventory, or of any system which we might build to maintain that inventory. That's in the 'too hard' basket. If anybody considers that an important consideration in this context then we should simply call a halt to this effort until the inventory work progresses.

  3. The problems I want to address are:

    3.1 Full and complete DHCP entries for multi-homed machines, (where such multiple entries are wanted by us.)

    3.2 Correct specification of hostname and domainname in our DHCP tables.

    3.3 The current overloading of the dhclient.hostname resource: it is currently incorrectly used to specify both the IP address, and hostname entry in the DHCP tables.

    3.4 The related overloading of the dhclient.bmchostname resource, which currently follows the same incorrect model.

    3.5 Allowance for the use of ad-hoc 'extrahosts' files which specify (MAC, [IP address|FQDN]) pairs in the format of /etc/ethers; thereby allowing the generation of DHCP table entries in addition to those specified the LCFG DHCP spanning maps.

    3.6 As painless a transition as possible from the status quo.

  4. Iain's prototype code achieves most of the above and could be used as-is. But I think a couple of aspects could be improved and, in particular, I have concluded that I do not like the idea of overloading/reusing the 'dhclient.mac' resource as a container for multiple (MAC, [IP address|FQDN]) pairs. For one thing: the name of the resource should give a mnemonic clue as to what it contains - and an overloaded dhclient.mac does not.

B. Proposal

  1. lcfg-dhclient currently publishes the following resources to lcfg-dhcpd via a spanning map:
       hostname <%profile.node%>
       @mac %string(mac address): /^([0-9A-Fa-f]{2}(:|-)){5}[0-9A-Fa-f]{2}$/
       mac 00:00:00:00:00:00
       hostfilename
       hostbootmenu
       hostrootpath
       @mailmanager    %boolean
       manageremail
       hostnetbiosnodetype
       hostnetbiosservers
       bmchostname
       bmcmac
    

    I propose to add the following resources (and note that I am not wedded to the actual names):

    Per-client resources:

    ResourceDefinition
    domainname the domainname of the machine to be defined in the DHCP tables
    macipmappings(MAC, [IP address|FQDN]) pairs of the machine in the format MAC|[IP address|FQDN] whitespace MAC|[IP address|FQDN] whitespace ..
    bmcdomainnamethe domainname of the BMC to be defined in the DHCP tables
    bmcmacipmappings(MAC, [IP address|FQDN]) pairs of the BMC in the format MAC|[IP address|FQDN] whitespace MAC|[IP address|FQDN] whitespace ...
    (There should only ever be one such pair.)

    Per-DHCP-server resource:

    ResourceDefinition
    etherfilesa whitespace delimited list containing the full filenames of all auxiliary files in /etc/ethers format from which DHCP table entries will be generated

  2. Use and official semantics of all existing resources will remain unchanged, and supported by the component. Use of dhclient.mac and dhclient.bmcmac will become officially deprecated, and will be removed at some future release.

  3. Where dhclient.macipmappings is defined for a machine, dhclient.mac will be ignored, and macipmappings will be used to generate a full set of DHCP entries. Where any (MAC, [IP address|FQDN]) pair is of the form (MAC, FQDN) and FQDN resolves to multiple IP addresses, multiple DHCP entries will be made.

  4. Where dhclient.bmcmacipmappings is defined for a BMC, dhclient.bmcmac will be ignored, and macipmappings will be used to generate a full set of DHCP entries. Where any (MAC, [IP address|FQDN]) pair is of the form (MAC, FQDN) and FQDN resolves to multiple IP addresses, multiple DHCP entries will be made.

  5. Where dhclient.domainname is defined, it will be used to populate the 'option domainname' field in the relevant DHCP table entry. Likewise for dhclient.bmcdomainname.

  6. Where dhclient.domainname is defined, dhclient.hostname is intended to be an unqualified hostname used to populate the 'option hostname' field in the relevant DHCP table entry.

    It is not an error (but it is not desirable) to specify both a fully-qualified dhclient.hostname, as well as a dhclient.domainname. (Likewise for dhclient.bmchostname.)

  7. Entries in files specified by etherfiles will be treated as (IP address|FQDN, MAC) for a host whose hostname and domainname can be resolved from its IP address. If no such hostname/domainname can be resolved, then those fields will not be set in the resulting DHCP table entry.

C. Transition to new scheme

  1. Existing LCFG profiles will continue to work unchanged with the new lcfg-component but would generate deprecation warnings. That is: we can introduce the new lcfg-dhcpd component without requiring anychanges to client profiles, other than to enable the new dhclient resources.

  2. Other components using the value of dhclient.mac need to be converted to first check for the existence of dhclient.macipmappings and, should that be defined, to use it instead of dhclient.mac (in whatever way they think reasonable.)

  3. Existing LCFG profiles for all machines should then be transitioned immediately to the use of dhclient.macipmappings (and dhclient.bmcmacipmappings) in favour of dhclient.mac (and dhclient.bmcmac.) (Note: the value in either resource for all profiles will be identical - namely, a single MAC address - so this change should be achievable by a single mass edit.)

  4. LCFG profiles for multi-homed machines should then be transitioned over time to the use of full MAC|[IP|FQDN] dhclient.macipmappings entries in order to fully use the new facilities.

  5. Files defined by extrahosts resources can be used as soon as the new version of lcfg-dhcp is in place on the DHCP servers.

-- IanDurkacz - 09 Aug 2013

Topic revision: r1 - 09 Aug 2013 - 15:33:34 - IanDurkacz
 
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies