> Note that Luigi has recently committed something similar to create the
> sysctl kern.bootp_cookie (see /sys/nfs_client/bootp.c rev 1.36).
>
i will check that out asap.
> I have also been doing the same thing for some time, but the difference in
> my version is that I use four separate DHCP options (133,134,135,136 at
> present, though this isn't important) and concatenate their together onto
> the end of the (MFS copy of) /etc/rc.conf from rc.diskless1.
>
well, not much different from my proposal, which probably means that we are
thinking
somewhat alike :-)
with my scheme, i could concat more than one file, and place all the
name/value pairs
in the environmet.
im trying to solve the chicken and egg problem: there are some (few) things
that have
to be dealt very early - ie. is / RO or RW, etc.
secondly, im also getting bogged down trying to configure clusters/few/single
hosts
with some particularities, and having some kind of central control is
escential so
that i can keep my sanity.
we developed a very sophisticated (in other words complicated) system to
configure
our linux boxes, and it's getting to the point that too much time is spent
debugging
the system each time a new hardare/box appears :-)
the freebsd scheme is much more to my liking, it just needs something more ...
> The reason for using four options is that in the DHCP configuration there
> are a number of different scopes in which you can put the option
> assignments, all of which are potentially useful for diskless
> configuration options.
>
> For example, in our setup we have some things that need to be set
> per-subnet (eg. which servers to use), some that need to be per group{} of
> machines in the dhcpd.conf (eg. we have one group of 486-class machines
> that are pure X-terminals, and another of more powerful machines which are
> allowed to run more services locally), and finally there are some options
> that need to be set per-machine (eg. which machines need to run lpd
> because they have a printer attached). Each scope gets its own DHCP
> option, and then they are all concatenated together onto the end of
> rc.conf.
>
> Before implementing this scheme, we tried to use the /etc/conf/<ipaddr>
> scheme, but this didn't really scale well. We started with just two
> classes of hardware, so had two /etc/conf/{IBM,COMPAQ} directories with
> symlinks for each of the machines of that class, but then as the network
> expanded we needed per-subnet configuration and the /etc/conf/${ipba}
> scheme didn't work as we still needed the per-machine-class configuration
> too. Then we started adding local printers and we now had
> /etc/conf/{IBM-net10,COMPAQ-net10,IBM-net11,COMPAQ-net11,IBM-net10-printer}
> etc and then we got some new hardware that wasn't quite the same...
>
he he, been there too! we get a batch of 50 machines, they are all alike,
great, then
some want to swap localy, fine, then some change the cd to cdr, they add a
different
sound card, etc, etc,
> With the new scheme, everything is configured in just one place and
> adding a new machine or a new per-subnet service is easy.
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
