geoff@desint.UUCP (Geoff Kuenning) (02/17/88)
In article <2662@orstcs.CS.ORST.EDU> hakanson@mist.UUCP (Marion Hakanson) writes: > I agree, it probably will be standard. But anything in /bin is > guaranteed to be lost in the next OS upgrade. We try to not even > add stuff to /usr/lib around here. Lately, we even stay out of /etc > as much as possible. The proper solution to this is to blast your OS supplier for being so arrogant and stupid as to distribute so-called upgrades that destroy important data. It is not really very hard to do it right; at Callan it cost us about two person-months. (In the "arrogant and stupid" department, BTW, the last update I got from Microport even wiped out /etc/passwd! Now that takes the cake.) -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
mouse@mcgill-vision.UUCP (der Mouse) (03/17/88)
In article <1682@desint.UUCP>, geoff@desint.UUCP (Geoff Kuenning) writes: > In article <2662@orstcs.CS.ORST.EDU> hakanson@mist.UUCP (Marion Hakanson) writes: >> I agree, it probably will be standard. But anything in /bin is >> guaranteed to be lost in the next OS upgrade. We try to not even >> add stuff to /usr/lib around here. Lately, we even stay out of /etc >> as much as possible. A good idea. We do our best to keep /bin, /lib, /usr/lib, and so on pristine as far as possible (a policy which has paid off on occasion). Everything local goes under /local/bin, /local/lib, /local/etc, etc. (For example, if I ever do install perl, it will not, ever, go in /bin. It will go in /local/bin, and if it doesn't like it, tough. We have one local program in /bin, and I now believe that was a mistake.) > (In the "arrogant and stupid" department, BTW, the last update I got > from Microport even wiped out /etc/passwd! Now that takes the cake.) 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. If anyone is curious enough, I can ask him what files got destroyed; I'm sure he remembers much better than I do (after all, he's the one who did the upgrade). der Mouse uucp: mouse@mcgill-vision.uucp arpa: mouse@larry.mcrcim.mcgill.edu
chuq@plaid.Sun.COM (Chuq Von Rospach) (03/24/88)
>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
geoff@desint.UUCP (Geoff Kuenning) (03/28/88)
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
wcs@ho95e.ATT.COM (Bill.Stewart.<ho95c>) (03/28/88)
For tools that are genuinely useful to root, I prefer to keep them in /bin. That way they're accessible even when /usr isn't mounted, or when other things go wrong. For instance, Korn Shell is /bin/ksh; if I used perl, it would be /bin/perl (I prefer sed and awk.) In general, tools that get used constantly, and aren't very large, go in /bin. Any upgrade procedure that trashes commands it doesn't use is *wrong*. One of the worst offenders is DEC's install scripts for their System V disk drivers, which typically look like mv /etc/foo /etc/foo.orig cp /dec/foo /etc If everything works right the first time (fat chance) you're ok. If the install doesn't complete, and you run the script again, it copies the new /etc/foo over /etc/foo.orig, trashing the original. -- # Thanks; # Bill Stewart, AT&T Bell Labs 2G218, Holmdel NJ 1-201-949-0705 ihnp4!ho95c!wcs # So we got out our parsers and debuggers and lexical analyzers and various # implements of destruction and went off to clean up the tty driver...
mitch@stride1.UUCP (Thomas P. Mitchell) (03/30/88)
In previous articles <1703@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) <46626@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) write: About updates that destroy this file and that dir. >>> that it destroyed, but among them: /etc/rc (almost, barely, just > >> 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 >... Too bad Sun doesn't see fit to document Chuq's >personal habits as a "you must do it this way" procedures. Not in defense of Sun, or us here at MicroSage and other Unix(TM) vendors let me comment. A Unix release like our UniStride or Sun's is large. Perhaps huge is a better word. Ours is some 5000+ files (cpio -ot | wc). Maintaining a coherent product of this size IS a monumental task. Updates to anything of this size are also a non trivial task. The only way I have found to update a customer cleanly is to have that customer: 1) Backup his system (some have none) 2) Backup his users areas 3) Isolate local changes and additions. *** a) /etc/passwd; b) /etc/group etc. 4) Install the release from scratch on new file systems. a) mkfs on all devices b) run all configuration scripts and programs 5) Install file by file each of the local changes. 6) Install the user areas. 7) Respond to any missing items by extracting from the backup. Time after time I have chased down a 'bug' report that resulted from a half way update. Sometimes it is only a manual page that no longer matches the program, other times it is an include file. Because Unix was designed to get multiple use from program code the interactions are many in number. One real problem is 'dead' programs. With time files left behind from previous releases can begin to eat up disk space. Worse when invoked they call other programs now changed only slightly. *** Local changes. System managers very much need to keep a system notebook. ("Nut Shell" people???) I am constantly amazed by customers who never keep records about the hardware they have, let alone the installed software. After all what is a manager! P.S. My thanks to Chuq Von Rospach for the shell script I saved a copy. Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702)322-6868 TWX: 910-395-6073 FAX: (702)322-7975 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.
sjr@mimsy.UUCP (Stephen J. Roznowski) (03/30/88)
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
chuq@plaid.Sun.COM (Chuq Von Rospach) (03/31/88)
>>... Too bad Sun doesn't see fit to document Chuq's >>personal habits as a "you must do it this way" procedures. Let me ask a semi-rhetorical question. I don't want to start a flame war, I'm really curious how to do this 'right' since I don't see a way: If you look at the shell script I posted, one of the files I modify is /usr/ucb/quota. Now, I'm going to upgrade my system. How, without telling the upgrade process what that change is for, does the upgrade process do the right thing? o You can tell the file is changed because the checksum is different, right? But how much information about checksums do we keep? The previous release? What if I'm upgrading from 3.2 directly to 3.5? Or for 3.0? 2.2? Should the upgrade notice that the version of /usr/ucb/quota isn't from ANY sun tape? o What about patches? Suppose I'd modified quota because the new version fixes a bug? (for the record, this isn't the case....) And say that bug is fixed in the release I'm installing? Shouldn't it ignore the fact that the binary is patched and install the new standard version? How do you tell this? o Local changes? I've modified quota to do something different than the standard release. How does the system recognize this as a legitimate change that it should NOT override? And how does it tell that this is really a legitimate change and not some trojan horse that someone ELSE put into your system for you? o And what if there's significant new functionality in our version of the binary that doesn't get overridden because your private patch means we don't install over it. Let's even say that the program involved is, say, /bin/login. Now you can't log in, because your old private version isn't compatible with our new system, and we didn't install our copy of the new, improved program. Private changes in the system directories aren't easy. There are so many possibilities and the ways of dealing with them are exceptionally complex. And there are no really clean answers that don't involve manual intervention anyway. There's no way to install on a modified system directory structure and do it cleanly without adding a lot of complexity to the install system AND requiring a knowledgable installer. Rather than building all the complexity (and likely a few bugs) into the install program, especially when it won't really solve the problem completely, doesn't make sense. In my eyes makes more sense to have the administrator keep track of what they've changed and re-install them after they upgrade. This gives them a chance to figure out whether the changes they have they really still want (or need) and deal with changes in functionality or filesystem structures. And if you keep documentation and copies of all the changes in the system trees, you no longer have to back up those file systems, saving tapes and time -- and you no longer have ulcers when disks go down. You re-install, and restore your changes. Chuq Von Rospach chuq@sun.COM Delphi: CHUQ Even with my limited Chuq I got into a few conversations, and one man wanted to argue politics with me. -- Lisa Goldstein (After the Master, Asim, 5/88)
rick@pcrat.UUCP (Rick Richardson) (03/31/88)
In article <10851@mimsy.UUCP> sjr@mimsy.umd.edu.UUCP (Stephen J. Roznowski) writes: > >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. Perhaps Sun ought to hire Larry Wall for an evening. I can see it now: Looking for locally modified files... /.profile /etc/rc /.rhosts ... Hmm, I don't see an /.rhosts file out there, offhand. Want one? [y] Good. Looks like "perl" was installed in /bin. Leave it there? [y] Congratulations, you don't have blah-blah disks! Some clown made / mode 777. Leave it that way? [n] Want to patch your /etc/rc with new additions? [y] Hunk #1 succeeded at ... :-) :-) :-) :-) :-) :-) -- Rick Richardson, President, PC Research, Inc. (201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days) uunet!pcrat!rick (UUCP) rick%pcrat.uucp@uunet.uu.net (INTERNET)
aburt@isis.UUCP (Andrew Burt) (03/31/88)
I worked for a place several years ago that OEM'd Suns for whom I wrote install scripts (of our software; we went with Sun's install tapes for better or worse on the rest of it). The method we used was approximately as follows. I notice that Pyramid uses a similar scheme as well. In article <47576@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: > o You can tell the file is changed because the checksum is different > ... What if I'm upgrading from 3.2 directly to 3.5? Notice if the cksum isn't what it was on the last official release and rename that file to foo.orig. If you feel the need to reformat the system disk (ugh, not again) then make a pass on the old disk noting which files are (a) different than the official (last) versions and (b) not even present in the last version (e.g., locally added files). The remainder are files that are the same as the last official version and can thus be wiped out with no remorse. Make a tape/copy-of-some-type of the (a) and (b) files. After installing the new system, put the files from (a) in place as the .orig files; and files from (b) back where they were (if the file doesn't now exist) or as .orig (if the file now exists). Some files should get special treatment, such as /etc/passwd, /etc/ttys, and so on. If a format change takes place (e.g., ttys from the single to multi-field format) CONVERT the file for the poor user. (But still leave the .orig.) > o What about patches? Suppose I'd modified quota because the new > version fixes a bug? (for the record, this isn't the case....) And > say that bug is fixed in the release I'm installing? Shouldn't it > ignore the fact that the binary is patched and install the new > standard version? How do you tell this? Yes, install the new version, but leave the old one around (.orig) in case it's needed. Let the admin remove all the .orig files when he's ready. Be sure to give the admin a list of what was in (a) and (b) from above so they know what to deal with (and which category it's in). > o Local changes? I've modified quota to do something different than > the standard release. How does the system recognize this as a > legitimate change that it should NOT override? And how does it tell > that this is really a legitimate change and not some trojan horse > that someone ELSE put into your system for you? The admin decides this after checking source code of new and modified-old versions. > o And what if there's significant new functionality in our version > of the binary that doesn't get overridden because your private patch > means we don't install over it. Let's even say that the program > involved is, say, /bin/login. Now you can't log in, because your > old private version isn't compatible with our new system, and we > didn't install our copy of the new, improved program. Since the new version's has been put in place, everything works. If there are local hacks to login, they can be put in later. To discourage the admin from trying the old version in place of the new (to see if it still works) the documentation on and off-line should state explicitly that if a file was replaced (and the old mv'd to .orig) then there was good reason for it and the .orig probably won't work as is. >Private changes in the system directories aren't easy. There are so many >possibilities and the ways of dealing with them are exceptionally complex. Yes, but many of the admins out there are less qualified to make some of these decisions than a "smart" install program should be. See below. >And there are no really clean answers that don't involve manual intervention >anyway. I didn't get the impression the call was for completely automated install scripts -- just ones that don't wipe out local changes completely. Ones that do as much of the install as possible -- not simply putting in the new version and stopping, regardless of changes made to the old version. If you can minimize the amount of work the installer has to do, AND direct him to where his intervention is needed (reconciling .orig's with new versions) you have saved him a lot of work and stress. >There's no way to install on a modified system directory structure >and do it cleanly without adding a lot of complexity to the install system >AND requiring a knowledgable installer. Correct me if I'm wrong, but aren't computers supposed to make our lives easier? You'll still need an admin around, but the less he has to do the better. Particularly if he isn't a guru. Many admin's of small machines like Suns are not well trained. I see them all the time in classes I teach (I do a Unix class for a "night school" division of the university which gets a lot of small Unix box admins: They've done the job for a while already and have decided they need to learn something about Unix...) >Rather than building all the complexity (and likely a few bugs) into the >install program, especially when it won't really solve the problem >completely, doesn't make sense. Again, it doesn't need to solve the problem completely -- just get closer to a solution. Just do MORE of the work -- the work it can be programmed how to do. Using this argument we might as well throw all of AI out the window because we can't produce truly intelligent software, i.e., we haven't "completely" solved the "problem". If you have bugs, they'd be subtle (or they would have been seen during thorough testing, right?); so the installer still has the level 0 dump to rely on; and he'll let you know that the install failed in such and such a way (or he should be encouraged to tell you at least). >In my eyes makes more sense to have the >administrator keep track of what they've changed and re-install them after >they upgrade. Agreed. This is great in theory. So is saying that nobody will ever actually hit "return" after having typed incorrect data -- let's assume every keyboard user double checks input before making it official... Many admins I know are doing the admin job part time; they have full time responsibilities beyond running a system. These people *should* be doing a better job of administration, but they (a) don't know how, and/or (b) don't have time. Plus, (c) people do sometimes forget even with the best intentions. (E.g., admin adds 3 programs to /bin, notes down two of them but forgets about the third...) Telling them it's their fault isn't the solution. They'll resent it (the "if the computer lets me do it it must be ok" mindset) -- and you don't want your customers resenting you. Especially when the computer as a tool is to make life easier. If the admin sees that this could be done for him, he'll dislike the fact that it isn't. Maybe you feel these people shouldn't be admins of <brand X> computer then. In response to which I'd say: (a) This attitude gives Unix a bad reputation. Unix is too fantastic to allow this to impede its spread. (b) These admins generally didn't make the choice to go with <brand X> or maybe even with Unix; they are told to run the machine. Either way you look at it, running the machine (using the machine in any way, for that matter) should be made as simple as possible. So, (c) maybe next time they WON'T be admins of a <brand X> -- they switch to your competitor. Expecting every admin to make lists of what has changed in /bin when they have a fuzzy concept of what's in /bin to start with is really pushing it. The best you can do is document how they *should* do this, but I don't think you can expect every one of them to actually do it. Sun should be in a consumer serving position. You get and keep customers by doing what customers want. You lose them by ignoring their desires; they'll go to another vendor who'll listen. -- Andrew Burt isis!aburt Fight Denver's pollution: Don't Breathe and Drive.
gmcgary@eagle_snax.UUCP ( Sun ECD Software) (04/01/88)
Here's a simple procedure for preserving locally modified files across
upgrades/installations:
* As preparation, when a new installation is complete, create an empty
file called /epoch, or whatever. The mod-time of this file will be
used later as a reference point.
* When it comes time to do another installation/upgrade,
`find / -newer /epoch -print' will yield a list of files that have
been added/changed since the last installation/upgrade.
You may want to hand-edit this list of files to filter out the cruft.
* Use the list of files to create an archive with cpio(1) or tar(1)
or whatever.
* Install/upgrade the new release.
* Load your archive of locally modified files on top of the new release.
* Touch /epoch for the next time around.
--
-- Greg McGary
-- gmcgary@ecd.sun.com
-- {ucbvax,seismo,ihnp4,cbosgd}!sun!eagle_snax!gmcgary
-- {decvax,ima,alliant,phoenix}!eagle_snax!gmcgarygnu@hoptoad.uucp (John Gilmore) (04/01/88)
I agree completely that OS upgrades should preserve locally-modified
state somewhere so that the administrator can reconcile it after the
upgrade. Installing Sun releases is a major trauma -- I tend to
allocate about a week for it unless it's a minor (updates only) release.
It helps a *lot* to have some spare disk partitions (or spare disks) --
you can copy your old stuff onto the spare partitions before you install (and
make *damn* sure that you check the little nondefault box in Setup
that causes it to erase all your other disks -- I either power them down
or turn on the write protect switches, if they are separate disks).
Then you have both online at once and marvelous tools like "diff" can
come into play.
I think that a well thought out upgrade procedure could be:
* Back up the world on tape
* Read in some upgrade scripts from the new release tape
* Run these scripts, feeding them the OLD release tapes, so they can
diff them against the disks and produce lists of changed files (possibly
diffs, for the humans' perusal).
* Sysadmin gets a chance here to clean up his system and rerun the
scripts, if desired...s/he may not even know that all this stuff has
changed, and might want to investigate. Also, cleaning up at this
stage makes for less to do later.
* Now run the install script, which saves the old files that weren't
straight off the release tape, then installs the new release tapes.
* Install script does whatever merging it knows about (e.g. mfr changed
the format of some file, it can convert the old one for you)
* It produces a report on disk including what it merged, and lists of
files that were changed in the old release and should be merged by hand
into the new release. The install scripts should NOT just dump their
output on the screen, where it will disappear!
* Sysadmin runs the system as best they can straight off the new release
tapes, while merging in their changes by hand.
--
{pyramid,pacbell,amdahl,sun,ihnp4}!hoptoad!gnu gnu@toad.com
"Watch me change my world..." -- Liquid Theatretif@cpe.UUCP (04/02/88)
Written 2:53 pm Mar 23, 1988 by plaid.Sun.COM!chuq in cpe:comp.sources.d >I'm not sure why they expect the upgrade software to magically know you >modified /etc/rc, but it doesn't. Yea, those modification time-stamps are pretty tricky :-) Paul Chamberlain Computer Product Engineering, Tandy Corp. ihnp4!sys1!cpe!tif
geoff@desint.UUCP (Geoff Kuenning) (04/02/88)
Kudos to Chuq for keeping this discussion rational. I'll try my best to reciprocate. In article <47576@sun.uucp> chuq@sun.UUCP (Chuq Von Rospach) writes: > If you look at the shell script I posted, one of the files I modify is > /usr/ucb/quota. Now, I'm going to upgrade my system. How, without telling > the upgrade process what that change is for, does the upgrade process do > the right thing? > > o You can tell the file is changed because the checksum is different, > right? But how much information about checksums do we keep? The > previous release? What if I'm upgrading from 3.2 directly to 3.5? > Or for 3.0? 2.2? Should the upgrade notice that the version of > /usr/ucb/quota isn't from ANY sun tape? Obviously, the user would ideally like near-perfection; equally obviously, such is rather expensive. It's pretty easy for Sun to keep checksum files from all releases in-house, of course. At Callan, our support people kept paper copies in filing cabinets, and often used them during phone support calls, to verify that the user had a particular (and uncorrupted) version of a troublesome utility. Putting multiple checksum files on an upgrade kit is a little more bothersome, especially if the kit is floppy-based. Checksums for 5000 files take quite a bit of disk space. At Callan, we took the easy way out, and insisted that customers not skip any upgrades. If you wanted the "naive" upgrade from X.0 to X.2, you had to install X.1 first. This was especially important because our floppy-based upgrades were incremental, so there was no guarantee that X.2 had the /bin/foo upgrade that was included in X.1. I think the trick is how you define your "supported" customer base. If you want to define them as "Unix gurus", you don't have to hold hands at all. If you want to define them as anyone who ever bought a Sun machine from anybody, regardless of the current state, you've got an AI problem worthy of at least a thesis, if not an endowed chair. Nobody picks these extremes, of course. Sun picked "intelligent system managers who have the foresight to keep records." Callan picked "anyone who bought a system, modified 'reasonable' system management-related files, and followed our upgrades when they came out." (I should also mention that, at Callan, we did *not* try to be "good" about every single file on the system. For example, I run with private versions of cron, crontab, tellcron, and at. I wouldn't expect any upgrade process to respect my changes to those files; it's not reasonable for an "average naive" user to change them. As an allegedly expert user, I consider it my own responsibility to take care of such things.) > o What about patches? Suppose I'd modified quota because the new > version fixes a bug? (for the record, this isn't the case....) And > say that bug is fixed in the release I'm installing? Shouldn't it > ignore the fact that the binary is patched and install the new > standard version? How do you tell this? In my view, this depends somewhat on where the patch came from. See my cron example above for one alternative, when only "expert" users would be patching things. However, the simple answer for the general case is to output the following warning, and also mail it to root: WARNING: /usr/ucb/quota is not the X.Y version. For safety, it has been preserved in /usr/ucb/quota.old, and replaced by the latest version from the update tape. You should investigate and decide which version is the one you want to run, and remove the other. Obviously, you could also leave the old version alone, and put the new one in /usr/ucb/quota.new. The theory is that, if the user is expert enough to patch a program, he's also expert enough to decide whether he wants to go with an upgrade of it. (Also, you should watch out for disk overflows if very much of this happens. Disk overflow is a knotty problem; about all you can do is spawn a shell for the guy to use to clean up. The Callan script checked at the beginning to be sure you had the amount of disk a "standard" upgrade would need to add new features, but it's not so easy to predict at startup time exactly how much extra you'll need to keep new/old copies of things the user has updated.) > o Local changes? I've modified quota to do something different than > the standard release. How does the system recognize this as a > legitimate change that it should NOT override? And how does it tell > that this is really a legitimate change and not some trojan horse > that someone ELSE put into your system for you? For legitimate changes, the new/old procedure given above should suffice. For ASCII files such as /etc/passwd, the documentation should point the user at useful integration tools such as /usr/bin/sdiff, rcs merge, or Larry Wall's patch program. For Trojan horses, the new/old procedure will call root's attention to the possibility of such a critter. Perhaps it would also be a good idea to provide an option like cpio's "-u", which says "I don't know or care how screwed-up this system used to be, just install the latest stuff and make it clean again." > o And what if there's significant new functionality in our version > of the binary that doesn't get overridden because your private patch > means we don't install over it. Let's even say that the program > involved is, say, /bin/login. Now you can't log in, because your > old private version isn't compatible with our new system, and we > didn't install our copy of the new, improved program. Again, see the new/old procedure above. In an important incompatibility case like login, obviously you should move the user's version to ".old" so you can install a version you're sure is compatible. The user can clean up later if that's wrong. Also, I would hope that there are bootable floppies or similar procedures which allow non-destructive recovery of severely damaged disks. Finally, on System V, it is a one-character (and thus easily reversible) change to /etc/inittab to cause a system to boot into single-user mode. If you had /bin/login inconsistencies, the upgrade procedure could do this edit, thus making sure that the system can be worked on even if login is broken. The user can easily put it back later. (Of course, this wouldn't be of much use if the program in question were /bin/sh instead!) > Private changes in the system directories aren't easy. There are so many > possibilities and the ways of dealing with them are exceptionally complex. > And there are no really clean answers that don't involve manual intervention > anyway. There's no way to install on a modified system directory structure > and do it cleanly without adding a lot of complexity to the install system > AND requiring a knowledgable installer. The trick is to separate things into categories. The files listed in your script (crontab, passwd, rc.local, etc.) are ones you COUNT on the user to muck with. And they *have* to be in system directories. So your upgrade script should deal with them in a clean fashion. The few people who change /bin/login are willing to re-install it after an upgrade, especially because (a) they've got source and makefiles handy, and (b) you helpfully sent them a mail message reminding them that they need to do so. As to the manual intervention issue, you're entirely correct: manual intervention in such cases is necessary to achieve a clean answer. The question is whether the upgrade process makes manual intervention a difficult process involving foresight, or an easy one involving reading your mail and typing "make install" a few times. > Rather than building all the complexity (and likely a few bugs) into the > install program, especially when it won't really solve the problem > completely, doesn't make sense. In my eyes makes more sense to have the > administrator keep track of what they've changed and re-install them after > they upgrade. This gives them a chance to figure out whether the changes > they have they really still want (or need) and deal with changes in > functionality or filesystem structures. And if you keep documentation and > copies of all the changes in the system trees, you no longer have to back up > those file systems, saving tapes and time -- and you no longer have ulcers > when disks go down. You re-install, and restore your changes. To me, this is a question of whether Sun or the customer does the work. *Somebody* has to keep track of what's in /usr/lib/crontab. Anything Sun does, is done once. Anything the customer does, has to happen <however many machines Sun has sold to date> times. I hope this helps. I strongly feel that it *is* possible to write an upgrade procedure that holds the average customer's hand without forcing him to be an "ideal" system manager (remember, some of these people are coming from the DOS world). It also wouldn't hurt for Sun to ship Chuq's script with every machine, and to document his system management suggestions prominently in the basic-installation manual (if they haven't done this already), because they *are* good suggestions. -- Geoff Kuenning geoff@ITcorp.com {uunet,trwrb}!desint!geoff
chas@gtss.UUCP (Charles Cleveland) (04/03/88)
In article <517@pcrat.UUCP> rick@pcrat.UUCP (Rick Richardson) writes:
)Perhaps Sun ought to hire Larry Wall for an evening. I can see it
Personally, I think everybody ought to hire Larry.
(Say, do I need to add this line to avoid the >-counter?)
--
-Life would be so much easier if we could just look at the source code.-
Charles Cleveland Georgia Tech School of Physics Atlanta, GA 30332
UUCP: ...!gatech!gtss!chas INTERNET: chas@ss.physics.gatech.edudavid@dhw68k.cts.com (David H. Wolfskill) (04/04/88)
In article <1704@desint.UUCP> geoff@desint.UUCP (Geoff Kuenning) writes: >[A bunch of good stuff....] [Referring to the problem of a vendor-distributed file overlaying a customer-modified version of that file:] > However, the simple answer for the general case is to output the >following warning, and also mail it to root: > WARNING: /usr/ucb/quota is not the X.Y version. For safety, it > has been preserved in /usr/ucb/quota.old, and replaced by the > latest version from the update tape. You should investigate and > decide which version is the one you want to run, and remove the other. >Obviously, you could also leave the old version alone, and put the new >one in /usr/ucb/quota.new. The theory is that, if the user is expert >enough to patch a program, he's also expert enough to decide whether he >wants to go with an upgrade of it. (Also, you should watch out for disk >overflows if very much of this happens. Disk overflow is a knotty problem; >about all you can do is spawn a shell for the guy to use to clean up.... I like this approach -- finding something that may be amiss and notifying the S/A. However, because of 1) Disc space constraints (as noted above); 2) Possible name conflicts; and 3) Possibly leaving the system in an unknown state what I would like to see is an *option* to do a "dry run". That is, to run the script in such a way that the S/A is informed of questionable files, but *nothing* is modified (except for the S/A's mailbox). Ideally, the level of verbosity would be specifiable, ranging (at least) from fairly terse comments about files that look as if they may have been modified clear up to a list of every file that would be modified, together with the kind (ASCII text, script, binary, ...) of file that is being discussed. This way, the S/A would have an opportunity to take some evasive action. I use something similar to the above where I work -- in an IBM mainframe environment; I will, however, spare the folks involved with this discussion too much exposure to IBM's way of doing things.... :-) I am, of course, willing to go into more detail if asked. (My position at work is in O/S support; (re-)installation of products is my primary function -- or (at least) the one that involves the most technical expertise.) Of course, as someone else has already suggested, this could also be a useful tool for checking out a system for tampering, as well. david -- David H. Wolfskill uucp: ...{trwrb,hplabs}!felix!dhw68k!david InterNet: david@dhw68k.cts.com