From owner-freebsd-bugs Wed Mar 29 09:01:02 1995 Return-Path: bugs-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id JAA21958 for bugs-outgoing; Wed, 29 Mar 1995 09:01:02 -0800 Received: from cs.weber.edu (cs.weber.edu [137.190.16.16]) by freefall.cdrom.com (8.6.10/8.6.6) with SMTP id JAA21952; Wed, 29 Mar 1995 09:00:58 -0800 Received: by cs.weber.edu (4.1/SMI-4.1.1) id AA19490; Wed, 29 Mar 95 09:54:33 MST From: terry@cs.weber.edu (Terry Lambert) Message-Id: <9503291654.AA19490@cs.weber.edu> Subject: Re: Changed information for PR misc/278 To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Date: Wed, 29 Mar 95 9:54:32 MST Cc: bde@zeta.org.au, freebsd-bugs@freefall.cdrom.com, pst@shockwave.com In-Reply-To: <12916.796469126@freefall.cdrom.com> from "Jordan K. Hubbard" at Mar 29, 95 01:25:26 am X-Mailer: ELM [version 2.4dev PL52] Sender: bugs-owner@FreeBSD.org Precedence: bulk > Well, it also seems to be something of a sacred cow around here and I > got flamed when I tried to significantly alter it. I've really no > immediate idea as to how to restructure the thing, and there's a lot > to be said for adding a `NETWORKED=[yes|no]' that possibly even turns > most of this stuff OFF for situations where the machine *isn't even on > a network and never will be*. Has anyone stopped to consider this > case? We've always just barreled along and never even really given > the user the opportunity to easily deselect what might be an entirely > gratuitous set of daemons.. > > Sigh.. I think it must be said: Most of /etc is a mess, it always has > been a mess and all I've ever seen other operating systems do with it > is make it a more *convoluted* mess (SVR4 - gag me!). What's the > cool, killer paradigm shift we're missing here? :-) Well, let me take a stab at attracting flames here.... 8-). % cd /etc % pseudogrep netstart rc ... # Uncomment the following line if you are on a network. This replaces # the old /etc/netstart. This really should be conditional on the # contents of a configuration file that gets sourced by rc. # /etc/rc.net start # start networking ... % pseudocat rc.net ... # Save argument ACTION=$1 # The following environment variable refers to the file that is set # up by the configuration management tools during install and which # can be modified by rerunning them (TBD). # NETCONF=/var/etc/netconfig # # The $NETCONFIG file is a file that sets environment variables and # does nothing else. These environment variable can have 'YES' or 'NO' # for various network options. We import them to tell rc.net how to # behave. # . $NETCONF # # Because the tools exist (TBD) to allow us to reconfigure the network # on the host while the machine is up (if we use a local terminal), or # to reconfigure the machine and have the changes take effect next # reboot (for a non-local administrator, we have to be able to start, # stop, and restart the commands in this file at will. So we provide # a "start" and a "stop" entry point. # # -- HANDLE START ------------------------------------------------ if test "$1" = "start" then echo "NETWORK: starting up" ... echo "NETWORK: startup complete" exit 0 fi # -- HANDLE STOP ------------------------------------------------- if test "$1" = "stop" then echo "NETWORK: shutting down" ... echo "NETWORK: shutdown complete" exit 0 fi # -- DEFAULT ACTION ---------------------------------------------- echo "usage: /etc/rc.net [start|stop]" exit 1 The basic idea is to cannonize the name ("netstart" is a stupid name in that it doesn't fit with where and how this thing is to be run), provide a mechanism for abstracting the procedure from the system configuration so the scripts can be shared between multiple hosts via network mount, and provide the capability of modifying the configuration using system management tools (which admittedly don't exist yet). The tools management procedure would be: 1) copy the current configuration to a work location 2) edit the work copy 3) decide to make it the active copy 4) shut down the net 5) move the work copy to the current configuration 6) start the net 7) the system runs with the new configuration The offline (remote management) procedure would be: 1) copy the current configuration to a work location 2) edit the work copy 3) decide to make it the active copy 4) move the work copy to a "shutdown install" directory 5) shut the system down 6) last act of shutdown is to move "shutdown install" directory contents to the current configuration locations 7) system reboots using new configuration Of course, you could launch a daemon to do the tools management procedure steps 4, 5, and 6 in a non-network dependent way. This would be more difficult, but more elegant. Because this is data driven, it also lends itself to remote management via snmp agent. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.