AFS Tips

Various AFS tips

Reviewed by John Sopko 4/27/2012

Resources on AFS

See the AFS Introduction page for more information on getting started with AFS, or click on the “filed under” AFS tag at the top of the page.

The pagsh command

The pagsh command creates a PAG, or Process Authentication Group, structure into which the ticket is stored.  All children of the pagsh (the shell you type as the next command) have access to that ticket.  If you omit the pagsh, commands such as lpr that don’t run under your userid will not be able to access your ticket and your files.  When you log in at the console or via ssh the PAG structure is already set up for you.

If you use ssh public keys to login to our systems you need to run the following to get an afs token:

pagsh
/usr/kerberos/bin/kinit
aklog

See “man pagsh” and the AFS aklog help page for more information.

Write on close

Network filesystems often have semantic differences from local filesystems, and OpenAFS is no exception.  For OpenAFS, the big difference for developers is that it does not implement write on commit semantics but rather write on close.  In other words, when a client issues a write request, that request does not necessarily cause other clients reading the data to be aware of the new contents.  Instead, OpenAFS will write on the closing of the file (or an fsync() call).  While this is not necessarily specific to OpenAFS, it is a subtlety of networked filesystems that many developers may not be aware of, so they need to be more careful about checking the return status of file close() calls, and they also need to be aware of the differences so that they can properly handle cross-system coordination if based on contents of files.

Accessing your AFS home directory from the Mac

When you are on your Macintosh, you *are* authenticated to AFS.  Consequently, you have access to your AFS home directory.   You do not
need to acquire a token on the Unix-Share server, as the KA-Share software acquires one for you when you connect.

Renew kerberos tickets and afs tokens

If you have long-running jobs that exceed your token lifetime, or you need to keep a token alive, you can use the krenew command to extend you AFS token to a maximum of two weeks.  Before you can do this, you must set the KINIT_PROG environment variable.  In bash shell, to this:

% export KINIT_PROG=/usr/bin/aklog

In the csh/tcsh shell, do this:

% setenv KINIT_PROG /usr/bin/aklog

The  krenew command renews your Kerberos 5 TGT and AFS token up to the maximum of 14 days, to renew every 60 minutes execute:

% krenew -K 60 -t -b

See “man krenew” for more information.

Cron and at jobs

Cron and at jobs don’t work with AFS because you aren’t there to authenticate as yourself.  Thus the cron or at job has no afs token with which to modify your files.

If you need to a job just once, similar to an “at” job, you can start the job in a script and use the “sleep” command to execute your job in the future.  It is possible to run cron jobs using the “k5start” command.  See man k5start for more information.  This requires a special account that uses Kerberos5 keytabs.

Changing multiple ACLs at once

If you wish to change the ACL on an entire subtree of your directory, you can use the find command:

1. Set the permissions the way you want on the top of the subtree, using ‘fs sa’.

2. Execute a find command to change everything in and below subtree:

% find subtree -type d -exec fs copyacl subtree {} \;

There MUST be a space between the right bracket and backslash “} \;” at the end of the line!

How do I use ‘su’?

Su only runs as the UNIX user, not the AFS user.  If someone runs ‘su’ in one of your windows, they do not get a token for that user.  This is one of the security benefits of AFS.  Someone cannot su and get to your AFS protected files.

Long distance collaboration using AFS

AFS facilitates collaboration and file-sharing between the many remote sites that also run AFS. The purpose of this post is to describe how to access remote files and how to make files available.

AFS was originally installed in this department to support the STC, or “Gang-of-Five” grant. DARPA funded several of our AFS server licenses to observe how this particular grant makes use of the collaboration capabilities.

There are AFS cells at most of the major universities. They contain a subset of the files at that university, and may include the work space of the researcher you are working with. All cells are addressed as

/afs/cellname

where ‘cellname‘ is normally identical to the Internet domain name. You can see the cells accessible from our machines by typing

ls /afs

If you have ‘ls’ aliased to ‘ls -F’, use ‘/bin/ls’ or ‘\ls’ so thatyou don’t contact each AFS cell when doing the listing.

To access remote files, ‘cd’ to /afs/cellname/pathname, where pathname is specified by the person at the other site.  The files you access will be brought across the network to your local disk and cached there.  Subsequent accesses will be very fast.

Making your files accessible to others

There are several ways to make files available to external researchers. In increasing degrees of privacy, these are:

1. You can making files in a directory available to all users on AFS by adding

system:anyuser rl

to the acl for that directory. You will also have to have

system:anyuser l

on every path above the shared directory. It is already on /afs and/afs/cs.unc.edu.

2. To make files accessible to all users on a remote machine (e.g.,, the researcher’s workstation), send mail to help specifying the Internet number of the workstation.  A “user” for that machine will be created that can then be added to your acl.

3. If you need to ensure only the researcher can access the files, send mail to help and we can arrange for an account in our AFS cell.  This account would not have any disk space available, but the user would be able to

klog login -cell cs.unc.edu

to become authenticated in our cell.  That user can be added to yourACLs like any other user in our cell.  Please send mail to help if you need assistance in arranging file sharing.

If you are working at another AFS site, you can authenticate to our cell by typing:

kinit login@CSX.UNC.EDU
aklog -cell cs.unc.edu

and

cd /afs/cs.unc.edu

Remember to use the full path name, as “/afs/unc” is only a local alias.