From owner-freebsd-stable Wed Apr 25 8: 8:50 2001 Delivered-To: freebsd-stable@freebsd.org Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166]) by hub.freebsd.org (Postfix) with ESMTP id 5B69F37B424 for ; Wed, 25 Apr 2001 08:08:45 -0700 (PDT) (envelope-from arg@arg1.demon.co.uk) Received: by arg1.demon.co.uk (Postfix, from userid 300) id 4D55A9B08; Wed, 25 Apr 2001 16:08:40 +0100 (BST) Received: from localhost (localhost [127.0.0.1]) by arg1.demon.co.uk (Postfix) with ESMTP id 43BD05D1A; Wed, 25 Apr 2001 16:08:40 +0100 (BST) Date: Wed, 25 Apr 2001 16:08:40 +0100 (BST) From: Andrew Gordon X-Sender: arg@server.arg.sj.co.uk To: Sven Huster Cc: freebsd-stable@freebsd.org Subject: Re: diskless startup again In-Reply-To: <5.1.0.14.0.20010425105221.02657d00@mx01.mailsurf.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-stable@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Wed, 25 Apr 2001, Sven Huster wrote: > 1. > maybe it is after the release of FreeBSD-4.3 possible to think about the > remaining mount_null in /etc/rc.diskless* again. > > the two solutions i see are: > - seperate mount_mfs for /tmp > - symlink /tmp to /var/tmp by default in the scripts I favour the symlink. For resource limited discless clients (think 486s), the extra cost of the extra mfs is unwelcome, mainly in terms of the extra boot time. My discless 486 machines are already way slower to boot than the 20-year-old discless 8-bit machines they are replacing (it's not a fair comparison, but it's a comparison the users make!). > 2. > Another thing is that i want to run different local daemons depending on > the machines (ip's or hostnames), or machine groups > So what i thought is to add the same function as for /etc to /usr/local/etc, > maybe which the enhancement of grouping machines in a config file. > This might be also useful for global config of "normal" machines, > which then can be mirrored to all of them. I'm not convinced that this is the best mechanism to use: it's cumbersome and slow, and the only real advantage is that you end up with a read-write /etc rather than read-only. For the simple requirement of controlling which services start, you can readily set local_startup= in rc.conf (and, given that rc.conf is a shellscript, it's only convention that the statements in there are simple assignments - you can put stuff in there that sets variables algorithmically). Alternatively, you can keep a shared /usr/local/etc/rc.d and modify the scripts in there to start only on the machines where you want them to. If you really need the whole of /usr/local/etc/* to be different on a per-client basis, then the copying mechanism would work as for /etc, but since it's all going to end up back on the server's disc in swapspace eventually, so you might as well NFS-mount a different /usr/local/etc for each machine. You can keep the generic/per-netmask/per-machine sets of files that get overlaid, but do it with a script so that you do all the copying once when you update the configuration, rather than doing it every time a machine boots. Personally, I'm about to experiment with doing it a completely different way: keep the initial /etc constant for all machines, and control which services get started or configured differently by private DHCP variables. This is a natural way for us to go, since in our environment the DHCP database is the main place where we keep track of which machines have been installed where etc. - the process for installing a new discless machine, or replacing one that's died is to grab a new machine off the heap, register it's MAC address in the DHCP database, and then plug it in where it's needed. If we can also record things like whether or not it has a 17" monitor in the same place, it will be a big win (type of monitor affects the version of /etc/XF86Config, currently achieved by per-machine symlinks in /conf for all machines needing something other than the default, but this gets tiresome when there's several things needing to be configured and you need base directories for all the combinations). DHCP configuration naturally handles the per-subnet configuration differences - the one area that's handled efficiently by the current rc.diskless scheme. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message