Date: Mon, 8 Feb 1999 16:47:05 -0800 (PST) From: David Wolfskill <dhw@whistle.com> Cc: current@FreeBSD.ORG Subject: Re: some woes about rc.conf.site Message-ID: <199902090047.QAA20458@pau-amma.whistle.com> In-Reply-To: <199902072048.MAA07248@dingo.cdrom.com>
next in thread | previous in thread | raw e-mail | index | archive | help
>Date: Sun, 07 Feb 1999 12:48:13 -0800 >From: Mike Smith <mike@smith.net.au> >> 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 dhw@whistle.com voice: (650) 577-7158 pager: (650) 371-4621 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199902090047.QAA20458>