Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!zaphod.mps.ohio-state.edu!samsung!uunet!cme!durer!klm From: klm@cme.nist.gov (Ken Manheimer) Newsgroups: comp.unix.admin Subject: Re: Software installation opinions needed Message-ID: Date: 26 Sep 90 18:56:01 GMT References: <312@pcad.UUCP> Sender: news@cme.nist.gov Organization: National Institute of Standards and Technology Lines: 62 In-reply-to: rowe@cme.nist.gov's message of 26 Sep 90 09:23:22 GMT We've actually implemented a refinement on the 'rc.site' scheme that walter mentioned in a prior article. The refinements eliminate problem with additional points-of-failure that the unadorned scheme introduces. As walter mentioned, a hook is inserted at the end of /etc/rc to call rc.site, which in turn is where any site-specific boot activities are placed. (We put it in /etc/rc instead of /etc/rc.local because rc.local is run in the middle of rc (on Suns, at least) and we want the rc.site stuff to be done *last* in the boot process.) A couple of nifty aliases (rc.site was developed as a cshell script, 'cause that's what i was more comfortable with at the time) allow you to conditionalize what hosts are to run or to be excluded from running specific inits: alias IfHostIn echo "\!* | grep -s $hostname ;" 'if ($status == 0) then' alias IfHostNotIn echo "\!* | grep -s $hostname ;" 'if ($status == 1) then' The rc.site approach has two general benefits - the standard boot rc files only need to be changed once (to introduce the hook for rc.site and maybe eliminate any features or bugs the vendor introduced) and the custom boot activites are centralized in a single place, which has proven invaluable for keeping track of what does what as our installation has grown. The drawback is that all the clients become dependent on some central server(s) for the rc.site customizations. The refinement to fix this consists of changing the hook to the global rc.site to the following sort of thing: if [ -f /usr/local/site/rc.site ]; then cp /usr/local/site/rc.site /etc/rc.site chmod 555 /etc/rc.site fi if [ -f /etc/rc.site ]; then echo -n Site-specific business: /etc/rc.site echo "." fi This way, if the global rc.site file is accessible a local copy is made. In any case a local copy, if any exists, is executed. The trick is that if the current global copy of the rc.site is not accessible the last copied version is still run anyway. In the rare cases where the global copy turns out not to be accessible the last copied version is almost always going to be at least adequate if not identical. For almost any situation this setup is more than adequate to get the right custom activities done... If it's not too obnoxious of me to do, i recommend the general rc.site approach highly. It's helped enourmously to consolidate our handle on our site's operations and to ease the job of administering customizations in general and across OS upgrades. Yay. Ken Manheimer Nat'l Inst of Standards and Technology klm@cme.nist.gov (301)975-3539 (Formerly Nat'l Bureau of Standards) Factory Automation Systems Division Unix Systems Support Manager I like time. It's one of my favorites.