RFC - per-host configuration of pxe booting
Danny Braniss
danny at cs.huji.ac.il
Sat Nov 22 02:24:46 PST 2008
> [this mailing list is as good as anyone i guess... feel free
> to forward it if you believe there is a more appropriate forum]
>
> The goal of this email is to figure out how to load host-specific
> configurations from pxeboot -- maybe as simple as loading
> /boot/loader.conf.${hostname} and possibly something slightly more
> flexible that allows me to define machine 'classes' (e.g. based on
> similar hardware configurations etc.).
>
why not use DHCP? you need it to boot the diskless anyways, and it can provide
a wealth of information. The code has been around for many years.
for example, in the dhcpd.conf:
option FBSD.ind1 "hw.msk.legacy_intr=1";
option FBSD.ind2 "machdep.conspeed=115200";
option FBSD.rc-conf4 "rc.ws"
these are placed, by bootp.c, in kenv.
> I have a trivial suggestion (patches below) to implement the former,
> and some ideas for the latter.
>
> At the moment the only host-specific variables available to pxeboot
> are: "boot.netif.hwaddr", "boot.netif.ip", and "dhcp.host-name".
>
> "loaddev" is also available but it is not machine-specific.
>
> The list of config files is specified in /boot/defaults/loader.conf
> in the "loader_conf_files" variable, and there is no way
> to override it from other files.
> So we need to change its default value to include the hostname, e.g.
>
> loader_conf_files="/boot/device.hints /boot/device.hints.${dhcp.host-name} /boot/loader.conf /boot/loader.conf.${dhcp.host-name}"
>
> (pardon the ling line -- forth does not allow line breaks)
>
> Also we need to redefine the function set_conf_files
> in /boot/support.4th so that it can expand ${variable}
>
> : set_conf_files
> conf_files .addr @ ?dup if free-memory then
> set_environment_variable
> s" loader_conf_files" getenv
> strdup
> conf_files .len ! conf_files .addr !
> ;
>
> (this is actually a slight simplification of the existing code).
>
> It might be useful to let dhcp pass more parameters to pxeboot
> so e.g. we can expand it to a 'machine class' which can be used
> for multiple machines. This should be relatively trivial to impelemnt,
> but it requires modifications to the pxeboot binary -- no big deal
> since this is something centralized.
>
> Comments ?
>
> cheers
> luigi
> _______________________________________________
> freebsd-current at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscribe at freebsd.org"
>
More information about the freebsd-current
mailing list