Creating AFS Group Space

There doesn't seem to be an existing document on creating AFS group space. So I thought I'd note down what I did to create some. Note at present we don't have a scheme for where to locate (ie which AFS partitions) to put group volumes and their mirrors. One thing for sure is that they shouldn't go on the recently allocated AFS user partitions.

A few basic points:

  • The group areas in the afs space are mounted at /afs/<sub-dir>/GROUP_NAME in a similar manner to the existing /group/<sub-dir>/GROUP_NAME NFS structure that we have. See AFSGroupSpaceUpdate.
  • Not all group space is mirrored and backed up to tape. All AFS RW volumes, including group volumes, should have at least a local readonly and backup volumes, but perhaps not the offsite RO copy.
  • We don't (currently) have any guidance on how to actually manage group ACLs.
  • PTS group entries live in the same namespace as usernames, which means in the UUN name space, so you shouldn't create a PTS group entry called ephones unless you've got it excluded from the UUN name space. Or Ms Emily Phones is going to be a bit miffed when she turns up to Informatics looking for her AFS space!

Select a server and partition

Currently this is a black art and needs to be formalised. The only thing for certain is that you should not use any of the partitions that are allocated for AFS User space (see the list of AFSPartitions). If appropriate, you will also need to identify a server and partition for the offsite RO copy.

You should probably try to pick a server that is physically near to the bulk of people in the group that will be using the space, but also bear in mind overloadings of the partitions.

Also see probably click on the "all four" links for the Forum in most cases to see where there is space.

Creating and mounting the space

Having selected the server and partition for the area, create a group.NAME volume:

  /usr/sbin/vos create <server> <partition> group.<groupname>
  /usr/sbin/vos create -verbose sphinx /vicepb group.ephones

Create the local RO volume:

  vos addsite sphinx /vicepb group.ephones
  vos release -verbose group.ephones

Where an offsite RO volume is also needed, see the "Backups and Mirrors" section.

Then mount it as a read write volume, note the leading "." before, this get you to the read/write version of the /group/ directory so that you can create the mount point within it.

  fs mkmount -rw /afs/<groupname> group.<groupname>
  fs mkmount -rw /afs/ group.ephones
The -rw option forces the mounting of the read/write version of the group volume, otherwise the cache manager will mount the RO copies.

Once mounted, the group-directory-containing directory should be updated, eg:

    /usr/sbin/vos release gdir

Or it may be under gdir.project, gdir.conference, gdir.cstrproj gdir.mscproj etc - use fs exam XXX to see which gdir XXX is on. e.g.

  fs ls /afs/
This updates any read-only copies of /afs/ Then flushes the cached data:
    fs checkvolumes 

Set the agreed/requested quota for the volume, eg:

    fs setquota /afs/<groupname> -max 1000000 

Then create a backup volume:

    /usr/sbin/vos backup group.<groupname> 

and mount it as Yesterday:

    fs mkmount /afs/<groupname>/Yesterday group.<groupname>.backup

Apply an appropriate ACL to the group area. Probably just make it full access to the user that requested the area eg:

  fs setacl /afs/<groupname>  <username> all

The default unix file permissions for this new area will be drwxrwxrwx which though (nearly) irrelevant with AFS ACLs, can cause some confusion, so perhaps best to remove Group and Other write bits:

  chmod go-w /afs/<groupname>

At this point you might want to do another vos backup group.<groupname> so that the ACL will get copied to the .backup version of the volume, and hence Yesterday will be accessible to the user. This will happen automatically during the nightly AFS backup run.

Backups and Mirrors

Depending on what the group wants/has/hasn't paid for, you should create off site readonly (RO) copies of their group volume, and add it to the backups exclusion list. Remember, by default everything will be backed up to tape. You perhaps don't want this if they've not paid for it, and have 500GB of data!

Excluding from tape backup

To exclude the group volume from the tibs tape backups, you need to update the header live/tibsconf-server.h. The old way was to add something like:

!tibsconf.omissions mADD(foo)
tibsconf.omit_foo  ||
however, due the the wonders of a labour saving macro, you can now just put:
This assumes the volume is named "", which it will be if you're following the naming convention. Also make sure you do this after the macro definition.

Create offsite ReadOnly (RO) volume - mirroring

To create offsite RO volumes use "vos addsite". You should have already created a RO volume on the same partition as the RW volume (see above). All that remains is to add the offsite RO location. Based on the location of the RW volume, from the AFSPartitions page find out what the corresponding offsite server and partition should be. Then do:

   /usr/sbin/vos addsite <readonly_server> <readonly_partition> group.<groupname>
   /usr/sbin/vos addsite nuggle /vicepc group.ephones

Then update the RO copies with a vos release group.<groupname eg vos release group.ephones

Group ACL Management

[I'm kind of running out of steam here, so only the basics ...]

See the bullet points at the top of this, but essentially the PTS group names are in the same name-space as UUNs, so you need to get your group name excluded from the UUN space - or choose something that doesn't clash, eg it could contain a hyphen. It has been suggested that we simply prefix all AFS group names with afs-, but at this time this hasn't been confirmed. But it is as close to a decision as we've made, so go with it!

Note if this is space for an existing group for which a unix group already exists, then perhaps the Automatics AFS groups section below will remove the need to do any of the following.

It is probably helpful to create an AFS group that the requester can maintain, do this with: (ephones is the name of the group in this case, see the UUN name consideration above):

  pts creategroup -name afs-ephones

  pts adduser -user <requester> -group afs-ephones

  pts chown -name afs-ephones -owner afs-ephones

So now there is a new AFS pts group "afs-ephones" owned by the members of "afs-ephones" ie anyone in that group can administer that group, and it has a single member set to the person who requested the ASF group space. This means they can then add further people to the group.

You should then set the ACL of the group volume to give the appropriate access to the group you have just created.

What to tell the user

Here's an example of what I sent to the requester who asked for the group space:

There is now a 7GB group area
for you at /afs/

I've created an AFS "afs-ephones" group, which is managed by people in that
group, and currently you are the only member. See "man pts", or "pts
help", or for the list of
pts commands, eg:

pts membership afs-ephones
pts adduser neilb afs-ephones

You can then give that group appropriate access to the ephones space, eg:

fs setacl /afs/ afs-ephones all
fs setacl /afs/ neilb rl

The first gives all members of "afs-ephones" full AFS access, the second
only gives the named user (me) Read and List access.

Again there are man pages and web pages for "fs",

Automatics AFS groups

To make AFS more friendly to users moving from the NFS world, we automatically generate afs PTS entries of the form "inf:<group-name>" that have the same membership of the unix group <group-name> and so generated from roles and capabilities, eg the unix group sysman will be equivalent to the AFS PTS group inf:sysman. The syncgroups2afs script currently runs hourly during the day on the tibs backup server, it's part of the dice-afsutils RPM.

Hey, maybe they want some group webspace too

group webspace

-- NeilBrown - 13 Mar 2007 updated -- NeilBrown - 05 Jun 2009 updated -- JenniferOxley - 11 Jan 2012 updated -- RogerBurroughes - 18 Mar 2013 updated -- RichardBell - 15 Jun 2016

Topic revision: r24 - 01 Nov 2019 - 15:09:51 - AdamKirylczuk
This site is powered by the TWiki collaboration platformCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback
This Wiki uses Cookies