SCS Computing
 Services and Solutions
  links to the SCS and CMU home pages Carnegie Mellon School of Computer Science Carnegie Mellon University
 » How to… 
 » Accounts & passwords 
 » AFS 
 » AV help 
 » Backups & restores 
 » Calendaring 
 » E-mail 
 » Networking 
 » Printing 
 » Purchasing 
 » Resource management 
 » Security 
 » Software licensing 
 » Support charges 
 » Support lifecycle 
 » Web publishing 
 » Mac support 
 » Linux support 
 » Windows PC support 

The coll.conf file

The current way that we use depot involves a script which generates the depot.pref file based on various configuration files.

The primary configuration file is /usr/local/depot/ This file is common among all machines of a given architecture and contains directives that apply to all those machines. The file /usr/local/depot/depot.pref.local is different on each host and contains depot directives that only apply to that host.

In addition to those, there is also a configuration file in each misc collection named /afs/

The directory that this file is in is supposed to be writable by the collection maintainer. If your collection's coll.conf is not writable by you, please send mail to and we will fix this.

The syntax of the coll.conf file is very simple. At the top of the file there should be a line of the form

   systypes list_of_systypes
This says which kinds of machines the collection should be valid on. A typical collection which is valid for all of the currently-supported architectures would have:
The rest of the lines in the "coll.conf" file should be "contents" lines, which describe what lines should be added to the depot.pref file in order to find all the pieces of this collection. The format of these lines is
   on systype contents release list_of_subdirs 
The "on systype" part is optional. If present, it causes the line to only apply to the specified systype. If absent, the line applies to all valid systypes (as listed in the "systypes" line.

If the release part is "all", then the line describes the contents of all releases. The tokens "@sys" and "@release" are expanded into the systype and release-level that each host is depoting that collection at, respectively.

The list of subdirs is used to tell depot what depot-collections should be created from this misc-collection. The primary reason why there would be more than one depot-collection per misc-collection is to add in a common area. The generated depot-collections are named "collection/n", where n is just the zero-indexed location of that subdir in the list.


   systypes i386_fc5 sun4x_59
   contents all @sys/omega
This means that for Redhat FC5, the collection is found in /afs/, and for Solaris 9 it's in /afs/, for all releases of the collection. This is approximately what most volunteer misc maintainers should be using, unless they are going to populate the alpha and beta releases(of course you can add additional common areas with "common/omega" or such as detailed further on).
   systypes i386_fc5 sun4x_59
   contents all @sys/@release all_mach/@release
This means that there are two "depot collections" generated for this misc collection. For a beta-release Redhat FC5 host, these are: /afs/ and /afs/ For an omega-release Solaris 9 host, these are: /afs/ and /afs/ And so on for alpha release on both systypes.
   systypes i386_fc5 sun4x_59
   contents all @sys/omega
   on sun4x_59 contents alpha @sys/@release common/@release
This means that the collection is valid on Redhat FC5 and Solaris 9 The contents of the collection will be /afs/ on everything except alpha-release Solaris 9, for which the contents will be /afs/ and /afs/