Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!bbs!karl
From: karl@naitc.naitc.com (Karl Denninger)
Newsgroups: comp.unix.admin
Subject: Re: Software installation opinions needed
Summary: So what IS the solution?  I'm always listening...
Message-ID: <1990Sep26.205309.14394@naitc.naitc.com>
Date: 26 Sep 90 20:53:09 GMT
References: <25908@shamash.cdc.com> <1990Sep19.125944.6489@cs.utk.edu> <1990Sep24.171752.13221@naitc.naitc.com> <650@silence.princeton.nj.us>
Reply-To: karl@bbs.naitc.com (Karl Denninger)
Organization: You're joking!
Lines: 132

In article <650@silence.princeton.nj.us> jay@silence.princeton.nj.us (Jay Plett) writes:
>In article <1990Sep24.171752.13221@naitc.naitc.com>, karl@naitc.naitc.com (Karl Denninger) writes:
>> In article <649@silence.princeton.nj.us> jay@silence.princeton.nj.us (Jay Plett) writes:
>> >In article <1990Sep20.160212.241@naitc.naitc.com>, karl@naitc.naitc.com (Karl Denninger) writes:
>[ whether an install program should touch /etc/passwd, /etc/group, and /etc ]
>
>> I don't understand how people are using computers eh?  Add some ad-hominen
>> in there for good measure too, no?
>I apologize for the ad hominem inference that can be drawn due to my
>careless use of pronouns in my remark "if you ... then you ..."  This
>inference was not intended.  Please substitute "one" for "you".

Ok.  Accepted.

>Providing for installation by a naive user is indeed frustrating and
>difficult.  But that doesn't negate the fact that each of /etc/passwd,
>/etc/group, and /etc--on the machine where a software package is being
>installed--might be inaccessible to the software or otherwise have no
>relevance to it when it is executed.  

/etc/passwd inaccessible?  That's a good trick, if it's not readable!  And
for nearly any package (mine included) read-only is what is required - AFTER
installation.

I guess you could do that, if you wanted to SGID (or something similar) all
the programs which read /etc/passwd (like /bin/ls, for example :-)

>I believe that a software
>provider must be entitled to assume that each site has at least one
>user who is capable of adding users and groups to their system, whether
>by hand-editting the appropriate files or by using software that was
>provided with or for the OS.  Meanwhile, it's presumptuous and risky
>for a software provider to assume that (s)he can predict what steps are
>required to successfully add a user or group to a particular system (or
>that the system the software is being installed on is the system
>it will be executed on).  

This is not true if the provider knows what the binary runs on, and what it
was built for.  If I am sending out software for ISC 2.2, for example, I
know darn well what the format of the password file is, and that it uses a
shadow file, and what I have to do to make that install work.  If I'm not
sure I can always go looking for a copyright notice in /unix (with strings,
or something similar) and only do the "dangerous" parts if the install
script finds the proper "signature".

Now if you're talking about source distributions, you're absolutely correct.
I'm talking binary distributions.

>How the software is to "find itself" is a
>stickier problem.  Looking in /etc for a config file is not the
>solution.

Ok, so what's preferred?  Environment variables?  Those are an even worse
hack; check the mess that Framemaker makes you go through to get it to
work, or SYBASE.  I prefer a single file in /etc, thank you very much!

For a network environment, a service provided by TCP/IP is ok, if the
clients are going to mount the original (it can save the IP and port address
of the "find me" server this way).  However, if clients are loaded on
the user's workstation and can't directly get to the original "server" or
"backend" code area, this doesn't work automatically either!

The only >other< possibility I can come up with in 30 seconds or less would 
be to link the binary on the customer's machine, and have the loaded 
directory burned into the binary.  This stinks too; now I can't move the
product from one place to another!

AKCS' use of a file in /etc is not perfect, but it does give you one place
to look for the parameters, and moving the directory the package uses takes
about 10 seconds.  And the file is called "/etc/V7Akcsparams", at least
it's obvious.

>In some cases it might be reasonable to include a program to automate
>certain superuser tasks which are likely to succeed on most common
>systems.  But no such program should be embedded in a more complicated
>installation program, or leave the installer wondering about the
>consequence of departing from the vendor's recommendations, or leave no
>choices for the installer, or require that the installer spend more
>time reverse-engineering the install script than (s)he should need to
>spend installing the entire package.  

If it's documented, you don't have to wonder -- if the installer chooses to
read the manual.  Since you have to read the manual to figure out how to run
the install script in the first place, I don't see that as being a major
problem -- as long as the information is in there!

>No third-party software should
>depend for its execution on discovering its essence in any particular
>pathname.

Ok, so how does a package discover where the libraries are loaded, or the
databases it needs to use to run?  Any ideas?  Environment variables have
already been decried as inane (with good reason) -- so what's the
alternative that people out there would prefer?

>It should be both possible and easy for any user to install a third-
>party software package even if that user lacks either the authority or
>the ability to add users, groups, or files in system directories.

Kinda difficult when the package does things which require that a user be
added.  An example?  A "bbs" package which uses a public login (with no
password) and does it's own user authentication.  Now, since that's central
to the idea of the software, how much sense does it make to install it if
you can't do these things?  Not a lot I'd venture....

>Ideally, software shouldn't depend on any of these things.  If such
>dependencies are truly unavoidable, then it is acceptable that a
>software package require its installer to seek help for a few critical
>tasks that require superuser privilege.

Is it?  

The average purchaser of the AKCS bbs package doesn't know how to do much
more than power up, down, back up, and follow explicit directions such as
"type: tar xvf /dev/rdsk/f0q15dt; cd /tmp; sh install".

How does this user manage to get a package installed if he/she doesn't
understand the underlying concepts of the operating system they're using?
And no, this is not a rarity.  We have a network of Sun machines here at
NAITC, and I'd gander that the majority couldn't do a successful
installation of the AKCS package here on their own workstations without the
install script, WITH OR WITHOUT explicit documentation.

As Unix becomes more commodity-oriented (which, by the way, I believe is
GOOD for the amount of software available commercially) this is going to be
an increasing problem.  I believe that providers need to make available the
information to do the installs manually, should the installer desire, but
need also to provide a "stupid mode" for those who are unable or unwilling
to take the steps to fully understand what they need to do.

-- Karl Denninger	
kdenning@ksun.naitc.com