Path: utzoo!utgpu!water!watmath!clyde!att-cb!att-ih!gargoyle!oddjob!mimsy!sjr From: sjr@mimsy.UUCP (Stephen J. Roznowski) Newsgroups: comp.sources.d Subject: Re: Wiping out /bin in OS upgrades Message-ID: <10851@mimsy.UUCP> Date: 30 Mar 88 01:28:23 GMT References: <1682@desint.UUCP> <1007@mcgill-vision.UUCP> <46626@sun.uucp> <1703@desint.UUCP> Reply-To: sjr@mimsy.umd.edu.UUCP (Stephen J. Roznowski) Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742 Lines: 103 In article <1703@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >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. > > [ Much Deleted ] > >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. > > > [ Much Deleted ] > > Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff Sorry Chuq, but Geoff is right. I have had to fight with the Sun setup/UPGRADE programs several times so that I can set the system up the way that I believe it should be. As examples, during the upgrade to 3.5, /.profile was not saved. It was not fun (or necessary) that I should have to replace 20+ copies. Empty /.rhosts were created on all my systems. I don't want an /.rhosts file if there is nothing in it. [Again 20+ rm's I had to execute.] As a side issue, I'm using NEC D2363 Drives [for the full story of the problems with these drives, see one of the latest Sun-Spots] and setup insists that all file systems are created with cylinder groups of size 16. [I needed to create file systems with cylinder groups of size 8.] After running setup, I needed to copy everything somewhere, recreate the disks, and copy everything back. Also when I was upgrading, every single client upgrade failed, so I had to upgrade 12 clients by hand. Perusing the UPGRADE scripts shows that whoever wrote it did not ignore commented fields. I had my file set up something like this: user alpha 0 /dev/xy0d 0 12000 0 user alpha 1 /dev/xy0d 96000 24000 -1 user alpha 2 /dev/xy2d 96000 24000 -1 user beta 0 /dev/xy0d 12000 24000 1 user beta 1 /dev/xy0d 72000 24000 -1 user beta 2 /dev/xy2d 72000 24000 -1 # #user alpha 0 /dev/xy0d 0 12000 0 #user beta 0 /dev/xy0d 12000 24000 1 # #user beta 1 /dev/xy0d 72000 24000 -1 #user beta 2 /dev/xy2d 72000 24000 -1 #user alpha 1 /dev/xy0d 96000 24000 -1 #user alpha 2 /dev/xy2d 96000 24000 -1 This way at a glance, I could tell how the nd partition was allocated. We "grow" root partitions down, and swap partitions up. On every client the files /etc/ttys and /etc/ttytype were wiped out. [You remembered to save it on the server]. Again for many systems, I had to reconstruct the files. Secondly, I buy several other vendors software, and I have very little control over where the software vendor wants its software placed. I cannot begin to name all the vendors who insist that their software is installed into /usr/bin with libraries in /lib. Usually I do the upgrades entirely by hand. This time I decided to try the Sun UPGRADE script to see if it would work. I don't know which was less work, doing 30+ systems by hand, or cleaning up after the UPGRADE script. Until Sun can prove to me that they can finally get an UPGRADE script working, (you would think that after a few releases Sun would be able to get it right) I guess that I'll continue doing it by hand. [Already I am dreading the MAJOR upgrade to 4.0 that is coming down the pipe....] Stephen Roznowski P.S. I just finished upgrading an Silicon Graphics IRIS. No problems.... Perhaps Sun should try to hire away some Silicon Graphics employees to see how to write upgrade scripts.... :-) ? -- Stephen J. Roznowski sjr@mimsy.umd.edu