Date: Wed, 29 Mar 95 9:54:32 MST From: terry@cs.weber.edu (Terry Lambert) To: jkh@freefall.cdrom.com (Jordan K. Hubbard) Cc: bde@zeta.org.au, freebsd-bugs@freefall.cdrom.com, pst@shockwave.com Subject: Re: Changed information for PR misc/278 Message-ID: <9503291654.AA19490@cs.weber.edu> In-Reply-To: <12916.796469126@freefall.cdrom.com> from "Jordan K. Hubbard" at Mar 29, 95 01:25:26 am
index | next in thread | previous in thread | raw e-mail
> 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.
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9503291654.AA19490>