Date: Thu, 21 Sep 1995 09:50:45 -0700 From: patl@asimov.volant.org To: chuckr@eng.umd.edu, gryphon@healer.com, kelly@fsl.noaa.gov 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: <9509211650.AA22389@asimov.volant.org>
next in thread | raw e-mail | index | archive | help
|> When are you going to start a daemon in more than one place?
|> Or set a global environment variable, then change it later?
|>
|> Define it as "Run Level N" includes all "Run Level 0..N-1". Simple.
If it really were that simple, why didn't SVr4 do it that way?
|> > 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'.)
|>
|> We are not System V. If we want to be System V stop calling ourselves
|> FreeBSD and become FreeUnix (FreeNix anyone? :-)
I'm not suggesting that we become System V. But if they have a better
solution to one of our problems, why not adopt it? I have no problem
with differences that provide some significant technical advantage.
But differences just because "we aren't System V" only hurt us. We
don't want people refusing to run FreeBSD because it is too different
from the other unixes, (without significant advantage) do we?
|> Seriously. If we want to throw away how /etc/rc works (and it does
|> work), then only take from other camps what we need. I have yet
|> to see a standard out (ie. all parts work identically) there on the
|> 8-10 unix flavors that I work with. So which one are you going to clone?
We have two reasonable choices:
1. Whichever one we feel is technically superior.
2. The one with the biggest market presence (Solaris2).
|> > cron.d
|>
|> Crontab entries already exist in /var/cron/tabs, except for root's entry
|> which is in /etc. You could easily move it to /var/cron/tabs as well.
Solaris keeps the crontab entries in /var/spool/cron/crontabs, with
at job entries in /var/spool/cron/atjobs. /etc/cron only contains
the administrative scripts (logchecker), access control files (at.deny,
cron.deny), etc.
|> > mail
|> > Mail.rc, aliases{,.dir,.pag}, mailx.rc, main.cf, sendmail.cf,
|> > sendmail.hf, subsidiary.cf
|>
|> OK, or can be in /etc/inet.
Could be, but I kind of like the separate dir for mail.
|> > skel
|> > Default user rc files. (.profile, local.cshrc,
|> > local.login, local.profile)
|>
|> I put all the stuff normally in /usr/share/skel in /etc/skel.
|> If you want all the default stuff ("csh.cshrc" as well as "dot.cshrc")
|> that makes sense to me.
The current /usr/share/skel is a fine location.
|> > default
|> > Default versions of some control files: cron, fs, init,
|> > login, passwd, su, tar, utmpd
|>
|> Why bother? We are shipping a live file-system CD anyway.
|> If they download it and want the default stuff, keep it somewhere else.
I tend to agree. But I was on the SunSoft WOS (Wad Of S*) team for
a while, and I know how tight they are on space usage. I can't help
but suspect that there is some less obvious reason for having these
files. (I'm certainly willing to forego them until we find it though.)
|> > opt
|>
|> Same as with shared libs and other executables: please no.
Even in Solaris /etc/opt is depreciated in favor of /opt. The
FreeBSD convention is to install everything into /usr/local.
The separate-subdir-per-vendor (or major package cluster) has
some adantages for installation, update, and multiple version
support; but makes for huge PATHs and confuses some users.
|> > named
|> > DNS server control files
|>
|> OK, it can be separate or combined with /etc/inet
Keep it where it is (/etc/namedb). All of the books on DNS and BIND
expect it to be there. (I would class moving it into /etc/inet as
a gratuitous difference.)
|> Let's not go overboard and try and stick everything in it's own
|> little nook and cranny.
|>
|> One directory for network related config files (that will change
|> from system to system). One directory each for major subsystems
|> (UUCP, PPP, NEWS). I define major subsystems as ones that have
|> more than a half dozen files to keep track of just for it.
Agreed. (Although I wouldn't necessarily make half a dozen a hard
limit. After all named only has five.)
-Pat
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9509211650.AA22389>