dbfunk@icaen.uiowa.edu (David B Funk) (02/27/90)
I've just been shafted by RAI again and I've getting sick and tired of it.
When I use RAI tools (install) to install a piece of software for the first
time, I have to go back and carefully look at EVERY darned file or directory
that was affected by that install. Just to find out what it may have done to
me! Regardless of what options you put on the install, it may still sneak
around behind your back, making a mess of your system with out giving ANY
indication of what it is doing to you.
For example:
I just installed DPCE v3.3 on a node. My system has closed Aegis style
ACLs. Before I started the install, the ACL on "/sys" looked like:
$ acl /sys -all
Acl for /sys:
Required entries
root.%.% prwx-
%.sys_admin.% prwxk
%.%.is -r-x-
%.%.% -r-x-
Extended entry rights mask: -----
Initial (default) acl for directories created under /sys
Required entries For the current process:
root.%.% prwx-
%.sys_admin.% prwxk
%.%.is -r-x-
%.%.% -r-x-
Extended entry rights mask: -----
Initial (default) acl for files created under /sys
Required entries For the current process:
root.%.% prwx-
%.sys_admin.% prwxk
%.%.is -r-x-
%.%.% -r-x-
Extended entry rights mask: -----
After doing the install, the ACL on "/sys" looked like:
$ acl /sys -all
Acl for /sys:
Required entries
root.%.% prwx-
%.sys_admin.% prwxk
%.%.is -r-x-
%.%.% -r-x-
Extended entry rights mask: -----
Initial (default) acl for directories created under /sys
Required entries For the current process:
user.%.% prwx-
%.none.% prwxk
%.%.none prwx-
%.%.% prwx-
Extended entry rights mask: -----
Initial (default) acl for files created under /sys
Required entries For the current process:
user.%.% prwx-
%.none.% prwxk
%.%.none prwx-
%.%.% prwx-
Extended entry rights mask: -----
Notice that it wiped out the initial default file & directory ACL. This
particular install did that to EACH directory that it put something into.
Now in the past I've had installs create new objects (files & dirs) that
had wide opened ACLs inspite of the fact that my baseline says "closed", but
it respected the ACLs that were on existing objects. This is the first time
that an install clobbered ACLs on existing objects. What is next?
I don't care why it did this, what burns me is that there is no way to find
out what has been done with out wasting a lot of time looking at everything
that the install MIGHT have touched after it is done.
What I want is some option on the install tool (call it paranoid, super
verbose) that will cause it to report EVERYTHING that it does (or is going to
do if in "test" mode). Failing that, how about some kind of "viewer" that can
scan the "ri" file and display the operations used during the install. Then,
at least, I can be on the lookout for things that may be dangerous.
With the old sr9.7 install system, I could read the shell scripts to get
some idea what the install was going to do. If there were going to be problems
I could save things ahead of time or edit the install scripts to work around
things.
It is not easy to maintain a heavily customized system in the face of that
steam-roller called RAI. It will mash ACLs, wipe out customized system
configuration files, and play general havoc with a carefully distributed system
of links. Is there any hope for a tool to view & edit "ri" files to do local
customizations of installs? "cfgsa" & "config" are totally inadequate, they
only let you answer those few questions that the creator of the product saw
fit to provide you with. If you don't fit in that general mold, then you
are out of luck. In the case of many optional products, there is no way to
give customer input to the install process, such as the above mentioned DPCE.
In our case, RAI is so painful that I avoid using it as much as possible.
I have installed dozens of nodes with a full OS, optional product set, & local
customized software totally with out the hinderence of RAI by careful use of
tools like "cpt".
"inprot" is another RAI fiasco, in some ways it is worse than useless.
Under sr9.x I had a 3 page set of ACL templates that when I ran the ACL option
of install, I could feel secure in knowing that everything was protected.
A 900 page inprot file is not enough to protect the basic OS. Even then, there
are some things that inprot can not do, such as protected subsystems. The
creator of inprot did not understand the propogation of ACL objects (or
else couldn't be bothered with it). With the sr9.7 install ACL tools, a
dozen or so ACL objects was enough to protect a whole set of system software.
If a user makes the mistake of being clever enought to understand extended
ACL objects and tries to use "inprot" to install them, he/she will be left
with a system disk that has tens of thousands of them. Even when a few dozen
would be enough. Yes, I know that you could then go back with "salacl" and
clean up the whole giant mess, but why should the user be forced to waste all
that time and effort in the first place? Because there is no wildcard
mechanism in "inprot" a user is forced to create a template file for each
disk on his/her system, or risk unprotected software.
Dave Funkdennis@peanuts (Dennis Cottel) (02/28/90)
Among other complaints about Apollo's installation tools, dbfunk@icaen.uiowa.edu (David B Funk) writes: > It is not easy to maintain a heavily customized system in the face of that > steam-roller called RAI. It will mash ACLs, wipe out customized system > configuration files, and play general havoc with a carefully distributed system > of links. ... > "cfgsa" & "config" are totally inadequate, they > only let you answer those few questions that the creator of the product saw > fit to provide you with. If you don't fit in that general mold, then you > are out of luck. I heartily agree with David, here. We have just begun converting from SR9.7 to SR10.2 and I was extremely disappointed with RAI. Having read the glossies on the Super Installation Tools (I should know better by now), what I thought we were going to get was a truly useful toolset which would allow the system manager to tailor the exact configuration of each node in the network. Further, this tool could be used at any time to run a check to verify that the node contained exactly the configuration specified by its configuration file. In fact, as David points out, you get no more configurability than someone at Apollo thought you needed. There is no way to finely tune the installation by telling exactly which files should be links and which should be local copies. For instance, the DPCE installation doesn't even allow you to create links to the binaries -- you either load it on the disk or you can't use it. So, as before, we are left with no ability to automatically install a node; first we do the install using some generic configuration file, then we go through a long check list of items: "delete this, make a link to there, copy this from the admin node, ...". And no way to verify anything. Rats. As far as I am concerned as a system manager and user, Apollo wasted their time developing RAI. The tools may help application developers but are of no benefit to the rest of us. Dennis Cottel, dennis@NOSC.MIL, (619) 553-1645 Naval Ocean Systems Center, San Diego, CA 92152