Date: Thu, 21 Sep 1995 08:30:32 -0700 From: patl@asimov.volant.org To: chuckr@eng.umd.edu, kelly@fsl.noaa.gov, gryphon@healer.com Cc: asami@cs.berkeley.edu, hackers@freebsd.org, julian@ref.tfs.com, ports@freebsd.org, terry@lambert.org Subject: Re: ports startup scripts Message-ID: <9509211530.AA22279@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> > 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509211530.AA22279>