From owner-freebsd-ports  Thu Sep 21 08:26:34 1995
Return-Path: owner-ports
Received: (from root@localhost)
          by freefall.freebsd.org (8.6.12/8.6.6) id IAA08766
          for ports-outgoing; Thu, 21 Sep 1995 08:26:34 -0700
Received: from phoenix.volant.org (root@phoenix.volant.org [205.179.79.1])
          by freefall.freebsd.org (8.6.12/8.6.6) with ESMTP id IAA08748
          ; Thu, 21 Sep 1995 08:26:25 -0700
From: patl@asimov.volant.org
Received: from asimov.volant.org (asimov.volant.org [205.179.79.65]) by phoenix.volant.org (8.6.11/8.6.9) with SMTP id IAA00513; Thu, 21 Sep 1995 08:25:02 -0700
Received: by asimov.volant.org (5.x/SMI-SVR4)
	id AA22279; Thu, 21 Sep 1995 08:30:32 -0700
Date: Thu, 21 Sep 1995 08:30:32 -0700
Message-Id: <9509211530.AA22279@asimov.volant.org>
To: chuckr@eng.umd.edu, kelly@fsl.noaa.gov, gryphon@healer.com
Subject: Re: ports startup scripts
Cc: asami@cs.berkeley.edu, hackers@freebsd.org, julian@ref.tfs.com,
        ports@freebsd.org, terry@lambert.org
X-Sun-Charset: US-ASCII
Sender: owner-ports@freebsd.org
Precedence: bulk

|>  > The files generally have fairly clear names, and they all live in
|>  > /etc/init.d.  The rc* directories only contain symlinks to the file
|>  > in init.d, and the symlinks are clearly named.
|>  
|>  Yuk. One sub-directory of /etc being used just to have symlinks to
|>  another sub-directory of /etc?

Actually, I was wrong - they are hard links.

|>  If you want to use seperate sub-directories for each "run-level"
|>  then use the seperate scripts in each directory, so all someone
|>  has to do to find where something is being run is
|>  
|>  	grep mumbled /etc/rc.*/*
|>  

But some of the scripts are used in more than one subdirectory.  And
some may not be in any rc? directory unless the related service is
actually in use.  Having a single directory as the canonical location
of all of the service start/stop scripts makes life easier.

And you can still use that grep, even with symlinks or hardlinks.

|>  With the directories named something like "rc.0", "rc.1", ...

Sun originally used 'rc0', 'rc1', etc.  These are now symlinks to
'rc0.d', 'rc1.d', etc.  I don't know why they made the change.
We should probably find out - it might save us from running into
the same sort of problem ourselves.  (And, again, I urge consistancy
with existing implementations.  There's no point in being the only
ones to use 'rc.?' if everyone else is using 'rc?.d'.)


|>  Then if you want to have other startup directories scatter throughout
|>  the system (personally the idea dislikes me), you can symlink from
|>  the normal starting place to wherever on other file systems.

I agree.  Init shouldn't know about any startup area except /etc/rc?.d.
Off hand, I can't think of any argument for putting startup directories
elsewhere.  Note that subsystems may have their own startup/data
directories elsewhere (e.g., /etc/named); but these aren't directly
accessed by init.


|>  In other words, keep it simple.

		--- YES !!! ---

|>  And while we're on the subject of completely reworking /etc, how
|>  about a "inet" directory which holds (as seperate files) all the
|>  network specific config files, such as host name, ip-addresses,
|>  resolv.conf, ...
|>
|>  Why? So if you are doing cookie-cutter installs on lots of systems,
|>  you go through that one directory to change everything there, and
|>  leave everything else in /etc alone.

Sounds good to me.  Partitioning into subdirectories can also make it
easier for the occasional sysadmin to find all of the files related to
a given subsystem.

My Solaris 2.4 system has the following subdirs of /etc:
(I'm not suggesting we slavishly copy what they did; but we probably
want to think about -why- they made those choices, and whether we
could benefit from something similar.)

	cron.d
		.proto, at.deny, cron.deny, logchecker, queuedefs

	fs
		Subdir for each installed loadable filesystem type
		(hsfs, nfs, proc, ufs)  Each subdir (except proc)
		contains an executable binary named 'mount'.  (proc
		is empty.)

	inet
		hosts, inetd.conf, netmasks, networks, protocols, services

	init.d
		The canonical site for the per-service rc scripts.

	lib
		ia_scheme.so, ld.so.1, libdl.so.1, nss_files.so.1,
		unix_scheme.so.1

	mail
	Mail.rc, aliases{,.dir,.pag}, mailx.rc, main.cf, sendmail.cf,
		sendmail.hf, subsidiary.cf

	rc?.d
		The per-runlevel hardlinks to the per-service rc scripts
		in init.d.

	security
		Things relating to the security audit daemon

	skel
		Default user rc files.  (.profile, local.cshrc,
		local.login, local.profile)

	default
		Default versions of some control files: cron, fs, init,
		login, passwd, su, tar, utmpd

	dfs
		Control files for distributed filesystems (NFS, etc.)

	net
		Subdirs: ticlts, ticots, ticotsord.  Each holds a
		hosts and a services file.

	opt
		One of the standard places for installing third-party
		and optional software.  (The other is /opt.)

	saf
		Control files and subdirs for the Service Access Controller
		(Don't ask.)

	tm
		Empty

	lp
		Various control files and subdirs related to printing

	acct
		holidays: Prim/Nonprime table for unix accounting system
	
	uucp
		Control files used by uucp, cu, etc. for foreign system
		access.  (Also used by their dial-up PPP - very convienent.)

	cetables
		Tooltalk type files.

	named
		DNS server control files