Path: utzoo!mnetor!uunet!lll-winken!lll-lcc!ames!ncar!boulder!cu-den!udenva!isis!aburt From: aburt@isis.UUCP (Andrew Burt) Newsgroups: comp.sources.d Subject: Re: Wiping out /bin in OS upgrades Message-ID: <2240@isis.UUCP> Date: 31 Mar 88 15:27:24 GMT References: <1682@desint.UUCP> <1007@mcgill-vision.UUCP> <46626@sun.uucp> <1703@desint.UUCP> <756@stride.Stride.COM> <47576@sun.uucp> Reply-To: aburt@isis.UUCP (Andrew Burt) Organization: Math/CS, University of Denver Lines: 152 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 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 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 -- 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.