Using perl without "#!"
Chip Salzenberg
difficult to use on systems without the "#!" hack for scripts. (This is
one case where Berzerkeley Unix has the edge. :-])
So, here is a way to fake it without "#!": use one of the commands that
is the same under sh and perl: "eval". Put this at the top of each perl
script:
eval "exec /bin/perl $0 $*"
if (0);
So when sh sees the first line, it executes it; then when perl sees it,
it passes the syntax check, but the if(0) keeps it from being executed.
--
Chip Salzenberg UUCP: "{codas,uunet}!ateng!chip"
A T Engineering My employer's opinions are a trade secret.
"Anything that works is better than anything that doesn't."
Larry Wall
: ...here is a way to fake it without "#!": use one of the commands that
: is the same under sh and perl: "eval". Put this at the top of each perl
: script:
:
: eval "exec /bin/perl $0 $*"
: if (0);
:
: So when sh sees the first line, it executes it; then when perl sees it,
: it passes the syntax check, but the if(0) keeps it from being executed.
That's wondrous fair, Chip! I'm still grinning.
I'd suggest a few improvements, however. First, the parens around the 0
are unnecessary. Second, why not make it self-documenting:
eval "exec /bin/perl $0 $*"
if $running_via_sh;
Third, rather than putting it *instead* of #!/bin/perl, put it after that line
if your sh understands # comments. That way the script is more portable.
Incidental-like, that /bin/perl reminds me of a complaint that I've been
getting from some people--why a2p always puts #!/bin/perl in the front
of its output when in Configure you've told it to put perl into some other
directory. The answer is that I want people to be able to write somewhat
portable perl scripts. I intended that you should always be able to get
to /bin/perl on any machine, even it is just a symbolic link to where the
real perl is stored. If you look carefully at the Makefile you'll see
that that is what it tries to do. At least for systems with symbolic links,
this gets us standardization without forcing people to use much storage in
the root partition. So a2p will continue to spit out #!/bin/perl.
Now I just have to decide if a2p should put the above eval in for systems
without #!. I do feel sorry for all victims of NIH.
Larry Wall
lw...@jpl-devvax.jpl.nasa.gov
Computer Center
> The answer is that I want people to be able to write somewhat
> portable perl scripts. I intended that you should always be able to get
> to /bin/perl on any machine, even it is just a symbolic link to where the
> real perl is stored.
Trying to lock non-standard programs into /bin is a typical hacker's
mistake. Even a program as fine as perl is said to be doesn't belong
in /bin.
Normally, Unix systems have very limited space in the root filesystem
for very good reasons and even if there were space its contents should
remain standardized for each version (at the least).
The appropriate place for such programs is /usr/local/bin with their
support files in /usr/local/lib and their own subdirectories there
if multiple files are required. This isolates the local additions
into a distinct subtree which may be a separate filesystem allowing
more flexible space control.
The virtues of such a structure are obvious; the name /usr/local is
both suggestive and the most widely used convention although not a
formal standard (unless /usr/group has responded to the suggestion).
Setting up this structure makes it easy for users to determine when
they are using programs which they may not find at other installations,
simplifies system administration, and improves reliability.
You only need to go through one system upgrade on a large system where
promiscuous insertion of non-standard programs into assorted parts
of the filesystem structure has been permitted to appreciate firm
enforcement of such a convention.
Thos Sumner (th...@cca.ucsf.edu) BITNET: thos@ucsfcca
(The I.G.) (...ucbvax!ucsfcgl!cca.ucsf!thos)
OS|2 -- an Operating System for puppets.
#include <disclaimer.std>
Skip Gilbrech
writes:
>I'd suggest a few improvements, however. First, the parens around the 0
>are unnecessary. Second, why not make it self-documenting:
>
> eval "exec /bin/perl $0 $*"
> if $running_via_sh;
>
>Third, rather than putting it *instead* of #!/bin/perl, put it after that line
>if your sh understands # comments. That way the script is more portable.
Thanks to Chip & Larry for these ideas: I was planning to suggest to
Larry that he consider hacking perl to get it to ignore a line like:
exec /bin/perl $0 $*
if it was the first non-comment line in a script, but Chip's way doesn't
require perl changes, is much more clever, & is even cleaner in an off-
white sort of way (:->
I do want to point out some portability problems, though, with leaving
#!/bin/perl as the very first line of the script if you're running
csh under Xenix or (at least one small implementation of) 'real' System V.
Under Xenix, '#!whatever' not only doesn't exec 'whatever', but explicitly
tells csh that it should do this script. From the Xenix csh man page:
"... C shell will execute ... a standard shell if the first character of
a script IS NOT a #".
The same man page from Microport System V/AT reads:
"... C shell will execute ... a 'standard' shell if the first character of
a script IS a ':' or a newline" (my emphasis on IS NOT and IS).
Leaving aside the infuriatingly typical inconsistency, the effect is almost
the same as under Xenix, except that Chip's original idea to begin the
script with 'eval ...' works under Xenix but probably won't under uport
unless there's a blank line before it, since csh doesn't understand 'eval'.
The trick, of course, under both systems is first to get /bin/sh to read the
script, after which everything works fine.
Unfortunately, the recommended way to accomplish this with both systems
(begin the script with ':') isn't appreciated by perl:
syntax error in file TEST at line 1, next token ":"
Execution aborted due to compilation errors.
The only thing that seems to make everybody happy is a blank line, but
of course that screws up the '#!' for those systems that use it, so out
comes the editor whenever these files are moved...
If anybody comes up with a way to make shell and (by extension & with
the above hack) perl scripts portable with NO source changes, I'd love
to hear about it!
>Now I just have to decide if a2p should put the above eval in for systems
>without #!. I do feel sorry for all victims of NIH.
Please do (include the 'eval', I mean!)...
--
Skip Gilbrech UUCP: uunet!pwcmrd!skip
PaineWebber, NYC attmail!skipnyc!skip
Joe Buck
>Trying to lock non-standard programs into /bin is a typical hacker's
>mistake. Even a program as fine as perl is said to be doesn't belong
>in /bin.
Ah, but when Larry Wall gives us a program, it usually becomes a
standard!
:-)
--
- Joe Buck {uunet,ucbvax,sun,<smart-site>}!epimass.epi.com!jbuck
Old Internet mailers: jbuck%epimass...@uunet.uu.net
Marion Hakanson
>In article <11...@ucsfcca.ucsf.edu> ro...@cca.ucsf.edu (Computer Center) writes:
>>Trying to lock non-standard programs into /bin is a typical hacker's
>>mistake. Even a program as fine as perl is said to be doesn't belong
>>in /bin.
>
>Ah, but when Larry Wall gives us a program, it usually becomes a
>standard!
>:-)
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.
Marion Hakanson Domain: haka...@cs.orst.edu
CSNET : hakanson%cs.or...@relay.cs.net
UUCP : {hp-pcd,tektronix}!orstcs!hakanson
Geoff Kuenning
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 ge...@ITcorp.com {uunet,trwrb}!desint!geoff
Jay R. Ashworth
}Trying to lock non-standard programs into /bin is a typical hacker's
}mistake. Even a program as fine as perl is said to be doesn't belong
}in /bin.
To which, in article <19...@epimass.EPI.COM>,
jb...@epimass.EPI.COM (Joe Buck) replies:
> Ah, but when Larry Wall gives us a program, it usually becomes a
> standard!
Complete with the obligatory smiley. Good point, Joe. Now, the
unidentifiable "computer center" person may or may not know who Larry
Wall *is*, but I think that using the phrase "hacker's mistake" was,
maybe, a little strong? Personally, now--just my opinion, you
understand--Larry Wall can do just about anything he likes on my
machine. I've used his programs, looked at his code, etc., and I
think he probably considered the balance between ease of backup, and
maximum portability.
I used the phrase "who Larry Wall *is*..." back up there a ways. Now,
don't get me wrong, (Larry, ignore this part) I'm not trying to
suggest that Larry is one of the net.deities or anything, (OK, larry,
you can look again :-), but *I* sure couldn't write RN. Maybe Mr
"computer center" can. I wish he'd signed his real name. It sounds
like I'm trying to put him down, there, and I'm not. I just don't
*know* his name. Anyway, I follow more news than anyone else I've
ever met, and I didn't recognize the account name at all. So maybe
he's just new. A suggestion, sir: while newness to the network
shouldn't inhibit people from posting their views, take great care
with tone and such when you don't know for certain that you know all
the pertinent facts.
I like the Harlan Ellison quote used in (sorry, hon, I don't remember
your name, I'm so embarrassed)'s .sig:
Everyone is entitled to an *informed* opinion.
I read the net for a year and a half before posting my first article.
And you sir?
-- jra
--
Jay R. Ashworth ---+-- The Great Ashworth & ------------+ ...!uunet!codas!
10974 111th St. N. | Petrillo Production Company | !usfvax2!jc3b21!jra
Seminole FL 34648 +-- Gonna hafta face it, I'm addicted to news...-+---------
(813) 397-1859 ----+-- Tampa Bay's Smallest Video Production House -+ :-) !$
Thomas Mitchell
>> The answer is that I want people to be able to write somewhat
>> portable perl scripts. I intended that you should always be able to get
>> to /bin/perl on any machine, even it is just a symbolic link to where the
>> real perl is stored.
>Trying to lock non-standard programs into /bin is a typical hacker's
>mistake. Even a program as fine as perl is said to be doesn't belong
>in /bin.
I agree -- programs which are 'locked' in to any given path are
death. My preference for a default is "/usr/local" and
"/usr/local/lib" as Larry Wall suggests. But go one step
further.
Select unique environment variables (perhaps: $PERLHOME,
$PERLPATH, $PERLOPTS) test for them and use them if present to
define the location of the binary ($PERLHOME) and if useful a
path ($PERLPATH) to find libraries. $PERLOPTS can be used to
pass the equivalent of command line options.
This is not excessively difficult to code and can add much to
portability. In this way only 'perl' need be found by $PATH
'perl' can be a shell script which checks for these environment
variables and can set them and then exec $PERLHOME/PERL arg_list
to load the real binary.
OH Yes -- document them as well :-)
Mark W. Eichin
have placed a copy of the kits@21 directory (perl.kit{1..11}.Z) on
CHARON.MIT.EDU [18.80.0.13] in ~ftp/pub/perl. This is perl1.0 at
patchlevel 21. The file sums contains the results of sum *.Z on that
directory.
Mark Eichin
<eic...@athena.mit.edu>
SIPB Member & Project Athena ``Watchmaker''
PS. If you are an ATHENA user, attach watchmaker; perl is in
/mit/watchmaker/vaxbin/perl.
Rick Richardson
>
>I agree -- programs which are 'locked' in to any given path are
>death. My preference for a default is "/usr/local" and
>"/usr/local/lib" as Larry Wall suggests. But go one step
>further.
>
>Select unique environment variables (perhaps: $PERLHOME,
>$PERLPATH, $PERLOPTS) test for them and use them if present to
>define the location of the binary ($PERLHOME) and if useful a
>path ($PERLPATH) to find libraries. $PERLOPTS can be used to
>pass the equivalent of command line options.
I hate having a zillion environment variables laying around.
I hate man(1) not knowing where the man page got stashed.
I hate auxilliary files laying around in .../lib.
I hate telling people how to setup and/or find the above mentioned
stuff.
I've been tossing around the idea of using the comment sections
of COFF object files (sorry BSD) to store auxilliary files, manual
pages, and the like. Then, all you need is the PATH variable set
correctly. A build of a program which had an auxilliary file (prog.aux)
and a man page (prog.1) would look like this:
cc prog.c -o prog
coff_comm -a "ManPage1" prog.1 prog # Add comment section
coff_comm -a "prog.aux" prog.aux prog # Add comment section
To get the man page:
coff_comm -x "ManPage1" prog | man # Extract comment section
(Of course, suitably disguised for mortals as a shell script).
The whole COFF comment package would consist of the aforementioned
coff_comm program, plus a library which (hopefully) would allow
position independence whether the needed auxilliary files are stashed
inside the COFF file, or whether they are laying around somewhere
else.
I have a prototype of this scheme already. I wonder if there's
any net-wide interest?
--
Rick Richardson, President, PC Research, Inc.
(201) 542-3734 (voice, nights) OR (201) 834-1378 (voice, days)
uunet!pcrat!rick (UUCP) rick%pcrat...@uunet.uu.net (INTERNET)
Glen Dudek
>
>I hate having a zillion environment variables laying around.
>
>I hate man(1) not knowing where the man page got stashed.
>
>I hate auxilliary files laying around in .../lib.
>
>I hate telling people how to setup and/or find the above mentioned
>stuff.
>
The best software distribution scheme I have seen uses command line
arguments to pass information about where the auxiliary files for
a program reside. This is taken from the startup of the Saber-C
program development environment (a wonderful debugging and program
development system :-)
#!/bin/sh
exec /usr/local/lib/Saber/saber_exec -h/usr/local/lib/Saber \
-gsa...@harvard.harvard.edu $*
This requires no changes to object file format, no environment variables
that need to be put in everyones login initialization, no recompiling
after changing a configuration file, and is completely self-documenting.
Unfortunately, it doesn't help the man page problem.
--
Glen Dudek
Kendall Square Research
Disclaimer: These are my opinions, and may not be anyone elses.
der Mouse
> In article <26...@orstcs.CS.ORST.EDU> haka...@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: mo...@mcgill-vision.uucp
arpa: mo...@larry.mcrcim.mcgill.edu
Chuq Von Rospach
>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 ch...@sun.COM Delphi: CHUQ
Speed it up. Keep it Simple. Ship it on time.
-- Bill Atkinson
Geoff Kuenning
>> 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?
Bill.Stewart.<ho95c>
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...
Thomas P. Mitchell
<46...@sun.uucp> ch...@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 (mi...@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.
Stephen J. Roznowski
>In article <46...@sun.uucp> ch...@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.
>
>
>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.
>
>
>
> Geoff Kuenning ge...@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 s...@mimsy.umd.edu
John Pierce
too. Mostly they've got to design this sort of thing for people who have no
idea whatever about what they're doing. We finally decided to put in the
effort to write scripts that save everything we really care about someplace
where it's easy for us to get it back. Life's been a lot simpler since then.
Sure, the vendor's going to change it on you. Just put back the old binaries
(it's very unlikely they won't run) and recompile as you get the chance.
It only requires a little thought, and the occassional screw up, to make this
relatively less painful than griping about what the vendor did to you. They
don't have a chance in hell of figuring out everything you may have changed.
--
John Pierce Chemistry Dept, B-032, UC San Diego
Internet: j...@chem.ucsd.edu UC San Diego, La Jolla, CA 92093
Bitnet: jwpierce@ucsd +1 619 534 0203
Rich Salz
the stat(2) information and a checksum of every file. The first part of
upgrading a new release is to compare this file with the current state of
the system. That way, if the checksum of /etc/rc.local is not what was
originally shipped, you can at least warn the sysadmin. I wrote such a
program once, and the company used it all the time. It's not hard, even
when you're selective (e.g., "do a stat of everything in
/rel1.2/xy/include except /rel1.2/xy/include/sys, and assume the
destination is /xy/include"). In fact, I recall that the UniSoft port
of SystemV had something like this.
One tricky part is proper updating of the file for maintenance releases.
It's almost always a mistake to blindly wipe out entire directories,
rather than inserting new files. And requiring people to repartition
their disks shows a real lack of foresight on the vendor's part.
I remember being real pleasantly surprised by how nicely most upgrades
from mt. Xinu and Pyramid were handled.
This is an interesting discussion, but it's not really about sources;
where should it go?
/r$
--
Please send comp.sources.unix-related mail to rs...@uunet.uu.net.
Chuq Von Rospach
>>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 ch...@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 Richardson
>
>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 ...
:-) :-) :-) :-) :-) :-)
Andrew Burt
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 <47...@sun.uucp> ch...@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.
Sun ECD Software
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
-- gmc...@ecd.sun.com
-- {ucbvax,seismo,ihnp4,cbosgd}!sun!eagle_snax!gmcgary
-- {decvax,ima,alliant,phoenix}!eagle_snax!gmcgary
John Gilmore
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 g...@toad.com
"Watch me change my world..." -- Liquid Theatre
t...@cpe.uucp
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 Kuenning
to reciprocate.
In article <47...@sun.uucp> ch...@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.
Charles Cleveland
)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: ch...@ss.physics.gatech.edu
David H. Wolfskill
[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: da...@dhw68k.cts.com