🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Thread View: comp.unix.large
4 messages
4 total messages Started by Wallace Colyer Tue, 07 Apr 1992 13:12
managing /usr/local
#18
Author: Wallace Colyer
Date: Tue, 07 Apr 1992 13:12
6 lines
639 bytes
I am interested in hearing how large sites manage local software.  We
have a procedure that helps us to easily manage over 100 packages on 6
different system types and 700+ workstations, but I am wondering what
other people do. 

-Wallace
Re: managing /usr/local
#19
Author: Anthony A. Datri
Date: Wed, 08 Apr 1992 14:41
10 lines
996 bytes
>I am interested in hearing how large sites manage local software.  We
>have a procedure that helps us to easily manage over 100 packages on 6
>different system types and 700+ workstations,

"package" from Transarc, right?

-- 


======================================================8--<
Re: managing /usr/local
#21
Author: Wallace Colyer
Date: Wed, 08 Apr 1992 18:28
44 lines
2658 bytes
>>I am interested in hearing how large sites manage local software.  We
>>have a procedure that helps us to easily manage over 100 packages on 6
>>different system types and 700+ workstations,
>
>"package" from Transarc, right?

The answer is yes sorta.  The package we use predates Transarc and is of
a completely different code base, but we use it only the manage the OS
trees.

For /usr/local we use a locally developed program called depot which is
not the same as The NIST Depot.  They were seperate project and did not
know about eachother until the names had been used too many places. 
Depot was originally thought of in 1988 and the first prototype was
written in perl in early 1989.  It is now written in C and is being used
by a few AFS sites and one NFS site is looking at it seriously.

Depot breaks the software environment up into collections, but then
integrates the collections so that the users only see one consistant
environment.  It creates the environment by pulling collections in from
a variety of locations and can either copy the files off a remote
filesystem or make symbolic links to them at a directory, file or
collection level of granularity.  So, if the workstation maintainer
wants the gnu-emacs collection on the local disk all that need be done
is add a the line, gnu-emacs.mapcommand: copy, to a configuration file. 
To save disk space they can specify that for any collection copied to
the local disk, the man and doc directories will be linked.

It allows a large central environment to be easily maintained, but at
the same time individual workstations can be customized easily to the
hearts content.

If anyone is interested the sources can be found on:

export.acs.cmu.edu [128.2.35.66]
pub/depot

We are finishing a new paper about it which should be put in place in
the next couple days.  Depot has really helped us manage our reletively
large environment.  We forsee it being able to extent to manage the
entire workstation, but a great deal of work is needed to make that
possible.

-Wallace
Re: managing /usr/local
#23
Author: Wallace Colyer
Date: Wed, 08 Apr 1992 20:44
43 lines
2700 bytes
>>I am interested in hearing how large sites manage local software.  We
>>have a procedure that helps us to easily manage over 100 packages on 6
>>different system types and 700+ workstations,
>
>"package" from Transarc, right?

The answer is yes sorta.  The package we use predates Transarc and is of
a completely different code base, but we use it only the manage the OS
trees.

For /usr/local we use a locally developed program called depot which is
not the same as The NIST Depot.  They were seperate project and did not
know about eachother until the names had been used too many places. 
Depot was originally thought of in 1988 and the first prototype was
written in perl in early 1989.  It is now written in C and is being used
by a few AFS sites and one NFS site is looking at it seriously.

Depot breaks the software environment up into collections, but then
integrates the collections so that the users only see one consistant
environment.  It creates the environment by pulling collections in from
a variety of locations and can either copy the files off a remote
filesystem or make symbolic links to them at a directory, file or
collection level of granularity.  So, if the workstation maintainer
wants the gnu-emacs collection on the local disk all that need be done
is add a the line, gnu-emacs.mapcommand: copy, to a configuration file. 
To save disk space they can specify that for any collection copied to
the local disk, the man and doc directories will be linked.

It allows a large central environment to be easily maintained, but at
the same time individual workstations can be customized easily to the
hearts content.

If anyone is interested the sources can be found on:

export.acs.cmu.edu [128.2.35.66]
pub/depot

We are finishing a new paper about it which should be put in place on
Friday.  Depot has really helped us manage our reletively large
environment.  We forsee it being able to extent to manage the entire
workstation, but a great deal of work is needed to make that possible.

-Wallace
Thread Navigation

This is a paginated view of messages in the thread with full content displayed inline.

Messages are displayed in chronological order, with the original post highlighted in green.

Use pagination controls to navigate through all messages in large threads.

Back to All Threads