>Date: Sun, 07 Feb 1999 12:48:13 -0800
>From: Mike Smith <[email protected]>
>> What do you think ? Or what are your experiences ?
>I hate it unreservedly. If we need a source of seeded default values,
>we should have rc.conf.default, uncommented, read-only. rc.conf is
>where people expect to make their changes, and it is immensely bogus to
>have sysinstall creating rc.conf.site which is quietly included *after*
>everything in rc.conf (so that when someone changes rc.conf, the change
>is overridden).
I confess that I experienced what sure felt like a POLA violation when I
set up a system with a recent 3.0-SNAP (from about 01 February or so):
Since it was on a scratch box, I did a fresh install. But I wanted to
see what it would take to make the box "play nice" on our internal
Engineering network.
So immediately after sysinstall finished, and I told the system to boot
single-user (since sysinstall doesn't seem to provide a way to specify
the NIS domain name), and:
fsck -p
mount -a
cd
vi .cshrc [change EDITOR from "ee" to "vi"]
csh
cd /etc
mkdir /RCS
ci -u sendmail.cf rc.conf fstab printcap group inetd.conf
[hand-enter descriptions of each file]
co -l !:3*
vi !:2*
[hand-enter the NIS domain. Also change the amd_map_program &
amd_flags; those are easier to change w/ a normal editor. Do
reality check on everything else in rc.conf.]
[Add MFS-mounted /tmp.]
[Add a couple of networked printers.]
[Add the NIS "magic cookie" to /etc/group.]
[Add the amanda client-side entry.]
ci -u !*
[hand-enter brief descriptions of the above]
vipw [Add NIS "magic cookie" to passwd.]
reboot
intending to come up multi-user. (Note that I had deliberately not
changed sendmail.cf yet; that comes later.)
Machine comes up... amd says "no work to do--quitting". Huh? I try
logging in (as "dhw"); no go. ??!? Login as root; works fine.
"ls -F ~dhw/" -- no such user. Foo. "domainname"... null. :-(
"grep nis /etc/rc.conf" -- yeah; the domain name is set. ??!??!
*Then* my manager points out rc.conf.site.
:-(
So I check *that* file in & out, edit it, check it back in, come up
multi-user, and things are *much* happier. So then I'm able to
cd /etc
cp -p /usr/local/share/sendmail/cf-8.9.2/cf/dhw.cf sendmail.cf
ci -u !$
kill `head -1 /var/run/sendmail.pid` && tail -f /var/log/maillog
OK so far.... (Then all I needed to do was un-tar a bunch of the a.out
libraries (as well as /usr/libexec/ld.so) where they can be found.)
*Then* I was able to login....
Later, on another machine (on an engineer's desk), I've upgraded the box
to that SNAP. And now he's re-booted, and can't login. I login as
root, and we happen to look at the results of
rcsdiff -u /etc/rc.conf.site
??!? All kinds of changes.... Then he says he was doing some things
with sysinstall. :-( Fine; "co /etc/rc.conf.site" restores it back
again. Re-boot, and he can login again.... Seems that whatever he did
completely trashed thinsg like the NIS domain name....
OK; this note is way too long already.... But it does seem to me that
there's a bit of a POLA violation, if nothing else, in the naming.
You see, when I got here, I inherited a network where /usr/local was
NFS-exported from a box (that is now running 2.2.6-R). And this seems
to be rather at odds with the expectation of the "ports" system. Now,
since this has been my first experience with FreeBSD, I didn't know any
better... and I had no idea how much hassle this usage of /usr/local
would be in an environment where such a "ports" system is used.
Further, having /usr/local be "site-local" vs. "machine-local" isn't all
that unusual in the environments I've used and administered before
(mostly Suns).
But if /usr/local is expected to be machine-specific, it seems to me
that what sysinstall messes with should also be machine-specific, and
the names should be of a similar pattern.
At the same time, there is value in having a site-specific configuration
file (just as there is value in having some site-wide files, some of
which may well be executables). I would expect, moreover, that the
machine-specific information would override the site-specific
information.
I hope that was of *some* use (or interest, at least),
david
--
David Wolfskill UNIX System Administrator
[email protected] voice: (650) 577-7158 pager: (650) 371-4621
To Unsubscribe: send mail to [email protected]
with "unsubscribe freebsd-current" in the body of the message
