From owner-freebsd-current Wed Apr 24 8:12:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from peetree.cs.huji.ac.il (peetree.cs.huji.ac.il [132.65.80.34]) by hub.freebsd.org (Postfix) with ESMTP id 2CCE337B41D; Wed, 24 Apr 2002 08:12:24 -0700 (PDT) Received: from pampa.cs.huji.ac.il ([132.65.80.32] ident=danny) by peetree.cs.huji.ac.il with esmtp id 170OPU-0002J2-00; Wed, 24 Apr 2002 18:10:20 +0300 X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: Andrew Gordon Cc: Freebsd Current , luigi@freebsd.org Subject: Re: what if/diskless booting In-Reply-To: Message from Andrew Gordon of "Wed, 24 Apr 2002 15:45:13 BST." <20020424144458.J40139-100000@server.arg.sj.co.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 24 Apr 2002 18:10:20 +0300 From: Danny Braniss Message-Id: Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG > 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/ > 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