Path: utzoo!mnetor!uunet!ccicpg!felix!dhw68k!david
From: david@dhw68k.cts.com (David H. Wolfskill)
Newsgroups: comp.sources.d
Subject: Re: Wiping out /bin in OS upgrades
Message-ID: <6490@dhw68k.cts.com>
Date: 4 Apr 88 13:05:11 GMT
References: <1703@desint.UUCP> <756@stride.Stride.COM> <47576@sun.uucp> <1704@desint.UUCP>
Reply-To: david@dhw68k.cts.com (David H. Wolfskill)
Organization: Wolfskill residence; Anaheim, CA (USA)
Lines: 55
Summary: Option for "dry run" would be helpful

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