[et-mgmt-tools] Question regarding api.sync and the necessity of using MAC addresses as system.name in dhcp templating

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

 



Is the requirement of using MAC addresses as system.name as a prerequisite for DHCP templating necessary?  I'm trying to understand the reason for the decision to enforce this policy.  Hardware addresses should all be considered 'unique', so the problem lies with duplicate virtual MAC addresses (at least those attached to the systems provisioned with cobbler), no?  If this is the reason, I would recommend a resolution as follows:

By default make virtual MAC addresses randomly assigned.  The script from http://www.redhat.com/docs/manuals/enterprise/RHEL-5-manual/Virtualization-en-US/ch19s21.html does the job.  Maintain an array of cobbler-provisioned MACs and check against the array before assigning a new, random MAC address to a provisioned virtual system.  The default behavior can be overridden by the use of another (optional) command line argument to 'cobbler system (add|edit)'.  This frees up system.name to be any valid hostname and mirrors the behavior of 'xm create'.  A more robust solution would be to have a /var/lib/cobbler/macs file (bound to the array) which would allow users to manually provision virtual servers and add the noncobbler-provisioned MACs to the list if they so desired.

If there is another reason for depriving dhcp templating (and tied-in arguments; e.g. xen domU names) of anything other than MAC addresses, I would be curious to understand why.

Thanks,

 - Adam.

[Index of Archives]     [Fedora Users]     [Fedora Legacy List]     [Fedora Maintainers]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]

  Powered by Linux