this should eliminate most of the need to contact
<tt>sipb-afsreq</tt> in order to control ACLs for SIPB project
lockers (requests to <tt>sipb-afsreq</tt> are still necessary to get
- new lockers created).
+ new lockers created, and to add new lists to the <tt>sipb-afs-sync</tt>
+ list).
## Usage
Suppose you have a Moira list <tt>super-project</tt> that you
can use it as the ACL in the <tt>sipb.mit.edu</tt> AFS cell. To set
it up to by synchronized, you first need to make sure that
<tt>super-project</tt> is flagged as an AFS group in Moira (so that
- there is a corresponding <tt>athena.mit.edu</tt> cell group), and
- add <tt>super-project</tt> to the <tt>sipb-afs-sync</tt> list, as
+ there is a corresponding <tt>athena.mit.edu</tt> cell group), as
follows:
blanche super-project -G
+
+ Then if a SIPB AFS administrator (e.g., e-mail <tt>sipb-afsreq</tt>)
+ adds <tt>super-project</tt> to the <tt>sipb-afs-sync</tt> list, as
+ follows:
+
blanche sipb-afs-sync -a super-project
- The membership of the AFS group <tt>system:super-project</tt>
+ the membership of the AFS group <tt>system:super-project</tt>
will then be copied from the <tt>athena.mit.edu</tt> cell into the
<tt>sipb.mit.edu</tt> cell, creating the group if necessary, and
creating sipb cell PTS entries for any Kerberos principals as
- necessary.
+ necessary. The sipb cell group will be kept up-to-date with
+ changes to the athena one.
- Currently, the synchronization is run in a cron job that updates
+ Currently, the synchronization is run in a cron job on rc that updates
every 15 minutes. Certain special groups (like
system:administrators) are in a blacklist that will not be
synchronized. If you want to change the blacklist status of a