Path: utzoo!mnetor!uunet!seismo!sundc!pitstop!sun!plaid!chuq
From: chuq@plaid.Sun.COM (Chuq Von Rospach)
Newsgroups: comp.sources.d
Subject: Re: Wiping out /bin in OS upgrades
Message-ID: <46626@sun.uucp>
Date: 23 Mar 88 20:53:42 GMT
References: <1904@epimass.EPI.COM> <2662@orstcs.CS.ORST.EDU> <1682@desint.UUCP> <1007@mcgill-vision.UUCP>
Sender: news@sun.uucp
Reply-To: chuq@sun.UUCP (Chuq Von Rospach)
Organization: Fictional Reality
Lines: 82

>Our SA was flaming about the Sun upgrades a few months ago.  It appears
>that Sun upgrades are very painless if you run a standard system and
>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.

From an administration end, this makes life much nicer. You no longer have
to do backups of either / or /usr, saving lots of time and tapes. You lose a
disk, you re-install, and copy the special files back into the distribution.

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.

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?

(document? me? No! I'm a UNIX Hacker!)

chuq
sun tech support
-----
#! /bin/csh -f
#
# shell script to automatically save any custom files in the distribution
# (i.e unbacked up) part of the disk to a directory.  The idea is to keep a
# copy of things where (1) they go onto a backup tape and (2) can be easily
# found in case of upgrades or disaster. 
#
# You could, in theory keep the originals in a directory and symlink to
# them, but this gives you a spare copy in case of clumsy fingers
#
# Run this from cron on a regular basis to keep it up to date.
#
# This is where we put the files to save them:
set save_dir = /usr/plaid/save_files
# Directories where changes are made:
# /
foreach i ( .cshrc .login .profile .rhosts)
    cp /$i $save_dir/$i
end
# /etc
foreach i (ethers hosts.equiv servers hosts networks services fstab passwd group printcap rc.local exports syslog.conf rc.boot rc stars_servers netgroup BACKUP BACKUP.CONFIG termcap)
	cp /etc/$i $save_dir/etc/$i
end
# /usr/etc/yp
foreach i (aliases.yp Makefile ypservers group.yp)
	cp /usr/etc/yp/$i $save_dir/usr/etc/yp/$i
end
# /usr/lib
foreach i (aliases crontab sendmail.cf)
	cp /usr/lib/$i $save_dir/usr/lib/$i
end
# /usr/ucb
foreach i (quota)
	cp /usr/ucb/$i $save_dir/usr/ucb/$i
end


Chuq Von Rospach			chuq@sun.COM		Delphi: CHUQ

                               Speed it up. Keep it Simple. Ship it on time.
                                                            -- Bill Atkinson