Thread View: comp.unix.large
4 messages
4 total messages
Started by Wallace Colyer
Tue, 07 Apr 1992 13:12
managing /usr/local
Author: Wallace Colyer
Date: Tue, 07 Apr 1992 13:12
Date: Tue, 07 Apr 1992 13:12
6 lines
639 bytes
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
Author: Anthony A. Datri
Date: Wed, 08 Apr 1992 14:41
Date: Wed, 08 Apr 1992 14:41
10 lines
996 bytes
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
Author: Wallace Colyer
Date: Wed, 08 Apr 1992 18:28
Date: Wed, 08 Apr 1992 18:28
44 lines
2658 bytes
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
Author: Wallace Colyer
Date: Wed, 08 Apr 1992 20:44
Date: Wed, 08 Apr 1992 20:44
43 lines
2700 bytes
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