[15] in Information Retrieval
[Bill Cattey : Fwd: User-contributed programs available (& sought)]
daemon@ATHENA.MIT.EDU (Tim McGovern)
Thu Sep 5 15:34:43 1991
Date: Thu, 05 Sep 91 15:31:48
From: tjm@eagle.mit.edu (Tim McGovern)
To: elibdev@MIT.EDU
FYI...
------- Forwarded Message
Date: Thu, 5 Sep 1991 14:42:29 -0400 (EDT)
From: Bill Cattey <wdc@ATHENA.MIT.EDU>
To: dcns-apps@ATHENA.MIT.EDU
Subject: Fwd: User-contributed programs available (& sought)
Cc: f_l@ATHENA.MIT.EDU
References: <UcUxSUf0BwwbJUQ15Z@transarc.com>
This is FYI for anyone who has not heard of it.
I mentioned it's existance at a recent library meeting but nobody knew
about it.
---------- Forwarded message begins here ----------
From: Ed._Zayas@transarc.com
To: Info-AFS@transarc.com
Subject: User-contributed programs available (& sought)
Folks...
The grand.central.org cell (which I'll abbreviate as GCO for easy
reference) exists as a result of a research program assessing the impact
of a wide-area distributed file system on how people communicate. One
of the services provided by GCO in support of the general AFS population
is providing a place where user-contributed software of general interest
may be located. Specifically, the
/afs/grand.central.org/darpa/usr/contrib tree has been established as a
well-known location where any AFS user may make available code, scripts,
documentation, libraries, and man pages they've written which may be
useful to other AFS users. These materials are provided as-is to the
AFS community, with no warranties or assurances.
This post has three purposes:
1. To briefly describe the organization of this community-wide
usr/contrib facility.
2. To briefly describe the material already installed there.
3. To solicit contributions to this collection.
--------------------------------------------------------
1. How usr/contrib is organized
The /afs/grand.central.org/darpa/usr/contrib tree presents itself as a
flat set of directories, as follows:
- bin: All user-contributed executables are accessible here.
This directory is really implemented as a symlink to .bin/@sys,
which points people to binaries appropriate to the machine type
on which they are executing. Special provisions are made for
shell or other scripts, which do not change between
architectures.
-doc: Documents describing the user-contributed executables
visible in the bin directory are kept here.
-etc: Miscellaneous files dealing with user-contributed software
are stored here.
-include: Include files required or exported by the
user-contributed works are gathered at this location.
-lib: Any libraries related to the user-contributed code are
placed here. This directory is really implemented as a symlink
to .lib/@sys, which points people to libraries appropriate to
the machine type on which they are executing.
-man: Location for associated man pages.
-misc: Anything else that doesn't fit into the above categories.
Thus, all user-contributed material appears at the same level,
regardless of the organization from which it originated.
In reality, everything is stored per contributing organization, as
follows. The .site directory under usr/contrib heads a tree in which
any AFS cell may be allocated space in which to place their
contributions. For example, the .site/andrew.cmu.edu tree is a
mountpoint to a volume providing storage for users belonging to CMU's
main cell. All of the items appearing in the high-level usr/contrib
directories are implemented as symlinks down into this area. For
example, bin/mklog points off to
.site/grand.central.org/.bin/common/mklog, since it was contributed by a
GCO user (myself).
This architecture provides the following benefits:
- All user-contributed software is referenced and invoked
regardless of who contributed it, all at the same level.
- It is easy to see who contributed what software if it is
important to know (e.g., ls -ld).
- Each cell wishing to contribute software can be allocated a
set amount of space in which to place their wares, which can be
augmented simply by increasing the quota on the corresponding
volume. Thus, administrative grain can be made reasonably large.
- ACLs and per-cell authentication-only accounts in GCO can be
used to insure that only people from a given cell may enter
material into that cell's playground.
Currently, only a GCO administrator can run the program that installs
binaries into this tree structure (of course, any AFS user anywhere can
access all contributed materials). In the future, once this facility is
more developed and procedures/guidelines are better worked out and
documented, installations may be carried out by any AFS user
authenticated in GCO as the usr/contrib principal for their cell.
Incidentally, it is hoped that AFS users will use GCO's usr/contrib
facility to point to software residing within their own cell when
feasible. Thus, GCO will serve in these cases as a ``switchboard'',
providing a central place in which people symlink to their interesting
publicly-available work as stored at their own sites.
--------------------------------------------------------
2. What is currently installed
The usr/contrib/doc/Index file lists all contributed binaries, who
contributed them, and provides a brief description of what they do. As
of this moment, there are four executables available in the bin
directory:
- dev-tree: Perl script which builds package files for the /dev tree.
- gco-install: Shell script used to install binaries & scripts
into usr/contrib itself.
- mklog: Shell script to facilitate authentication to multiple
cells using the same password (i.e., multiple klog).
- pckg-tree: Perl script which builds package files (companion
to dev-tree).
More detailed descriptions of these items appear in the usr/contrib/doc
directory. In the near future, the following administrative scripts
will be released (as soon as I finish dinking with them - I'm currently
running them from /afs/grand.central.org/admin/bin, and the usr/contrib
entries will simply point back to here. They're self-documenting):
- add.auth.acct: Create an authentication-only account (i.e.,
create ProtectionServer and AuthServer entries but no volume or
home directory) in any cell (as long as you're authorized),
optionally making the new account a member of a list of
specified AFS groups.
- rm.auth.acct: Destroy an authentication-only account. The
named user in the specified cell is removed from all groups to
which he or she belongs, then their ProtectionServer and
AuthServer entries are deleted.
- update.CellServDB: Create and install a new CellServDB if
necessary, chiming off the version stored in
/afs/transarc.com/service/etc/CellServDB.export (this currently
only works for GCO, but may serve as an example for automatic
CellServDB updates for other cells).
-add.cell: Makes the named cell visible to all client
workstations for a given cell. It creates a mountpoint in the
/afs directory for the new cell, releases the root.afs volume as
needed, and force-feeds the cell name and its server machine
names to the CacheManager running on the invoking workstation (a
la fs newcell).
--------------------------------------------------------
3. Want to make your software/work easily visible to the general AFS community?
Anyone wishing to thus advertise their original, unencumbered software,
documents, etc. is highly encouraged to do so. Right now, the only way
accomplish this is to send me mail (erz@transarc.com), telling me where
to pick up your material. I will install it in the usr/contrib tree and
make the appropriate entry in usr/contrib/doc/Index. Announcements of
newly-installed goodies will be posted to this forum as reasonable.
In addition to software, I am very interested in receiving comments,
suggestions, constructive criticisms, and so on regarding this facility.
Ed. Zayas
Transarc Corporation
------- End of Forwarded Message
