Path: utzoo!utgpu!water!watmath!clyde!rutgers!cmcl2!nrl-cmf!ames!ucsd!sdcsvax!ucsdhub!hp-sdd!hplabs!sdcrdcf!trwrb!desint!geoff
From: geoff@desint.UUCP (Geoff Kuenning)
Newsgroups: comp.sources.d
Subject: Re: Wiping out /bin in OS upgrades
Message-ID: <1703@desint.UUCP>
Date: 27 Mar 88 19:57:53 GMT
References: <1682@desint.UUCP> <1007@mcgill-vision.UUCP> <46626@sun.uucp>
Reply-To: geoff@desint.UUCP (Geoff Kuenning)
Organization: Interrupt Technology Corp., Manhattan Beach, CA
Lines: 56

In article <46626@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes:

>> extremely painful otherwise.  I don't recall the full list of files
>> that it destroyed, but among them: /etc/rc (almost, barely, just
>> possibly, excusable), /etc/rc.local (inexcusable), /etc/inetd.co...uh,
>> /etc/servers (inexcusable), and on one of our machines, even
>> /etc/passwd (somehow).  I think there were a handful of others, too; we
>> were finding configuration files that got destroyed for the next week.

> As someone who seems to upgrade weekly (someone has to run the stuff before
> customers do.... I find Sun upgrades to be relatively painless, as long as
> you're careful about what you do to the standard system directories. I'm
> pretty careful to install all my non-standard stuff in a separate filesystem
> like /usr/local, with (documented!) symlinks if they have to be mirrored in
> the standard directories. I keep my home directories in another file system.
> I also use the following shell script to keep a copy of EVERY non-standard
> file in the system directories in a mirrored tree on one of those
> filesystems.

In other words, if you administer your system *exactly* the way chuq@sun
does, you won't have problems.  Too bad Sun doesn't see fit to document Chuq's
personal habits as a "you must do it this way" procedures.

> When people get hosed by an install, in most of the cases it's because they
> went in and played with a system directory and either forgot they'd made the
> changes (the word 'document' comes to mind) or they expected the system to
> somehow know that they'd fudged with an area the system believes it owns.
> I'm not sure why they expect the upgrade software to magically know you
> modified /etc/rc, but it doesn't.

Because /etc/rc (and even more so /etc/rc.local;  howcome you
overlooked his mention of that one?) is one of a very small list of
files that you can count on users to change.  As to how the system can
"magically" know /etc/rc has been modified, I'd suggest looking in your
beloved documentation under cmp(1), diff(1), and the -mtime switch of
find(1).  If you find a difference, just load the new file into an alternate
name, warn the user of this, and let him reconcile the differences.  It's
not that hard -- we did this at Callan, and we had a *much* smaller staff
than Sun has.

> If you (1) minimize encroaching into the system directories, (2) document
> the changes so you know what needs to be saved, and (3) SAVE the changes
> before you upgrade, you won't have any problems at all. Trusting yourself to
> remember all the customizations you made to a system is insane -- besides,
> what'll happen to the person who takes over your job when you get promoted?

How nice.  Just to save Sun a person-month of effort to do it right,
*every* Sun customer in the world has to spend a person-day to cover
Sun's laziness.

C'mon, Chuq.  The shell script you posted already contains a list of
the files that need special treatment;  developing that list is 90% of
the work.  How about doing the other 10% instead of expecting every Sun
customer to have a UNIX guru who can read Sun's mind?
-- 
	Geoff Kuenning   geoff@ITcorp.com   {uunet,trwrb}!desint!geoff