Date: Wed, 24 Apr 2002 18:10:20 +0300 From: Danny Braniss <danny@cs.huji.ac.il> To: Andrew Gordon <arg-bsd@arg1.demon.co.uk> Cc: Freebsd Current <current@FreeBSD.org>, luigi@freebsd.org Subject: Re: what if/diskless booting Message-ID: <E170OPU-0002J2-00@peetree.cs.huji.ac.il> In-Reply-To: Message from Andrew Gordon <arg-bsd@arg1.demon.co.uk> of "Wed, 24 Apr 2002 15:45:13 BST." <20020424144458.J40139-100000@server.arg.sj.co.uk>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?E170OPU-0002J2-00>