From owner-cvs-all Mon Jan 25 19:06:48 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id TAA09992 for cvs-all-outgoing; Mon, 25 Jan 1999 19:06:48 -0800 (PST) (envelope-from owner-cvs-all@FreeBSD.ORG) Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id TAA09985; Mon, 25 Jan 1999 19:06:45 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.2/8.9.1) id TAA12075; Mon, 25 Jan 1999 19:06:41 -0800 (PST) (envelope-from dillon) Date: Mon, 25 Jan 1999 19:06:41 -0800 (PST) From: Matthew Dillon Message-Id: <199901260306.TAA12075@apollo.backplane.com> To: "Jordan K. Hubbard" Cc: Julian Elischer , Poul-Henning Kamp , Mike Smith , cvs-committers@FreeBSD.ORG, cvs-all@FreeBSD.ORG Subject: Re: cvs commit: src/sys/kern kern_mib.c References: <88277.917316664@zippy.cdrom.com> Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk :> What's the solution? : :And the assumption here is that you're working from a shared /etc for :all diskless nodes, right? Furthermore, you probably don't want your :details in /etc/rc.conf even if you could have it local because you're :DHCP'ing for all that information and already know which interfaces to :bring up, correct? : :Before we start suggesting solutions, let's just make sure we all :agree on the definition of the problem. :) : :- Jordan Ok, basically I'm working on the situation where you have one or more 'diskless' workstations, aka BOOTP workstations, and one server. We want all the workstations to operate without having to create a root environment for each one, so the server needs to export / and /usr read-only to all of the diskless workstations. Or, if the server is security concious, it might make a *single* root environment and export that as root, read-only to all the diskless workstations. From the workstation's point of view, the following is configured prior to /etc/rc being run by the kernel: * vfs.nfs.diskless_valid will be non-zero * vfs.nfs.diskless_rootpath will be configured * vfs.nfs_diskless_swappath may be configured * one of the machine's ethernet interfaces will be configured with an IP address, netmask, and default route * an NFS root will be mounted * an NFS swap partition may be mounted. Here's the problem: * The workstations cannot simply run the server's /etc configuration scripts * The workstations may also have different environments What we need is an /etc/rc, /etc/rc.conf solution that allows the rc script to distinguish the type of boot occuring and to distinguish between workstations. For example, in a poor-man's network the server's root drive will be NFS exported and mounted by BOOTP on the workstations. Goals: * /etc/rc and /etc/rc.conf operate almost normally * /etc/rc.local /etc/rc.conf.local are *NOT* accessed, but instead replaced with a workstation-specific ( aka IP-address-specific ) rc.local and rc.conf.local * System boots pretty much normally using the global rc and rc.conf, and the per-workstation rc.local and rc.conf.local overrides. Problem: * /etc/rc must recognize the diskless boot early ( easy ) and run /etc/rc.diskless to setup the basic environment such that the rest of /etc/rc can run 'normally'. * /etc/rc.diskless must somehow cause /etc/rc.conf to use /conf/IPADDRESS/rc.conf.local as the local override instead of /etc/rc.conf.local. * We can make /etc/rc deal with /conf/IPADDRESS/rc.local vs /etc/rc.local, no need for rc.conf specifics there. * We want any stand-alone executions of /etc/rc.conf to also return the correct configuration, not just when we run it from /etc/rc. So local variables in /etc/rc that are detected by /etc/rc.conf will not work. ( aka 'ndc restart' and other administrative scripts run /etc/rc.conf ). It would also be nice if /etc/rc could run /etc/rc.conf *BEFORE* trying to do the fsck's and other mounts and such, which would allow us to override their operation with a conf variable instead of a hack. But I didn't change the ordering because I was worried it would break existing installations. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message