arnold@mango.synopsys.com (Arnold de Leon) (12/22/90)
Here is an update on what I've found/thought on a design for
managing /usr/local.
I was referred to the a paper presented at the Usenix LISA IV,
"The Depot". IT is apparently available for anonymous ftp
at durer.cme.nist.gov (129.6.32.4) as ~ftp/pub/depot.lisa.ps.Z
I happen to have the LISA IV proceedings so did not end up
ftping a copy.
"The depot" is very close to what I want to do. I am
working on adapting it to what I want.
Here is what I have so far (Much of it lifted straight the
"The depot":
Software packages would be in installed in a package directory,
I'm using "/depot" same as the paper.
Working with the example "perl", the installation on "server" would look like
Assuming a sun4 binary
/export/depot/.primary/perl/plat-sun4-OS4/bin/perl
/h2p
/lib/perl/[bunch of stuff]
/README
The clients will "see" this as
/depot/.primary/perl/plat/bin/perl
/h2p
/lib/perl/[bunch of stuff]
although I am thinking of just making it
/depot/perl/bin/perl
/h2p
/lib/perl/[bunch of stuff]
I haven't thought through the side effect yet.
I intend to implement the client view via the automounter.
Aside: I would expect that in this example that perl would be have
been configured to expect itself to be installed
in /depot/perl/bin (or /depot/.primary/perl/plat/bin)
and to find it's libaries in /depot/perl/lib
(/depot/.primary/perl/plat/lib) This is make the packages
"self-contained"
An "installation program" would then build symlinks so that
there will be links in /usr/local that would look like:
/usr/local/bin/perl -> /depot/perl/bin/perl
/h2p
/usr/local/lib/perl -> /depot/perl/lib/perl
I expect to have a "deinstall" program to remove the symlinks also.
Issues that I am still uncertain are:
o Shared libraries and associated problems
lidl@eng.umd.edu (Kurt J. Lidl) mentioned this and I
don't have a good understanding of how to deal with it.
o Performance -- while I think it will be fine and several
people have agreed, I don't have concrete data to back me
this assertion up. If someone can explain the "cost"
a /usr/local/bin full of symlinks I would appreciate it.
(I am hoping for something like: In our environment of 100
clients and 10 servers the extra overhead is about 2% extra stat
traffic which is insignifant and delays in starting up
are applications is tolerable)
I've also glossed over some very hard problems in using the automounter
for doing this. I will probably bring those up as I get closer to
them.
Many of the ideas, terminology in the above description are adaptations
or blatant ripoffs of those presented in "The Depot: A framework for
shareing software installation across organization and UNIX platform
boundaries" by Manheimer, Warsaw, Clark and Rowe.
I appreciate the feed back and comments that people have sent it so far.
--
Arnold de Leon arnold@synopsys.com
Synopsys Inc. (415) 962-5051
1098 Alta Ave.
Mt. View, CA 94043clark@cme.nist.gov (Steve Clark) (12/24/90)
>>>>> On 21 Dec 90 23:07:39 GMT, arnold@mango.synopsys.com (Arnold de Leon) said:
Arnold> I was referred to the a paper presented at the Usenix LISA IV,
Arnold> "The Depot". IT is apparently available for anonymous ftp
Arnold> at durer.cme.nist.gov (129.6.32.4) as ~ftp/pub/depot.lisa.ps.Z
It is, indeed. As one of the authors of this paper, I just wanted to
clarify one thing.
Arnold> Working with the example "perl", the installation on "server"
Arnold> would look like
Arnold> /export/depot/.primary/perl/plat-sun4-OS4/bin/perl
Arnold> The clients will "see" this as
Arnold> /depot/.primary/perl/plat/bin/perl
or
Arnold> /depot/perl/bin/perl
The .primary/.develop directories are intended to be visible only in
the server's view. They serve two purposes: 1) Organizational: they
distinguish the primary use copy(ies) of a package from the
development/testing copy(ies), and 2) Technical: We wanted the server
to be able to use a depot in the same manner as any other client, i.e.
to compose a client view via NFS mounts. In the absence of .primary/,
a server would mount /depot/perl onto /depot/perl. This gives NFS
fits when another client comes along and tries to mount /depot/perl
from that server. Pushing stuff into /depot/.primary/perl on the
server allows the client view to be composed on the server without
obscuring the actual origin from other clients.
Arnold's approach of putting stuff under /export on the server is very
appealing to me. I've never gotten around to trying it, but it seems
like the "right" way to avoid the collision I described above. With
or without /export, though, the client view should not contain
.primary: The client sees the perl binary as /depot/perl/bin/perl.
Arnold> Aside: I would expect that in this example that perl would be
Arnold> have been configured to expect itself to be installed
Arnold> in /depot/perl/{bin,lib}
Yup ... that's 'zactly right!
Arnold> o Shared libraries and associated problems
We have the X11R4 shared libraries (libX*.so.*) in
/depot/X11R4/arch/lib. There are symbolic links in /usr/local/lib
which point to these libraries. Some users prefer to bypass
/usr/local entirely, putting /depot/*/arch/bin on their PATH and
setting LD_LIBRARY_PATH to pick up the shared libraries directly from
/depot/X11R4/arch/lib.
Arnold> o Performance
Sorry ... we have no hard performance numbers, but the symlink
overhead on startup certainly seems insignificant (~80 clients, ~4
depot servers).
--
-steve
------------------------------------------------------------------
Steve Clark
National Institute for Standards and Technology (formerly NBS)
clark@cme.nist.gov ..uunet!cme-durer!clark
(301)975-3595 / 3544