Debian GNU: Setting up OpenAFS 1.4.x

AFS' primary purpose is to serve files over the network in a robust, efficient, reliable and fault-tolerant way.

Its secondary purpose may be to serve user meta information through libnss-afs, unless you choose OpenLDAP for the purpose as explained in another article from the series, the OpenLDAP Guide.

While the idea of a distributed file system is not unique, let's quickly identify some of the AFS specifics:

You can find the complete AFS documentation at the OpenAFS website. After grasping the basic concepts, your most helpful resources will be quick help options supported in all commands, such as in fs help, vos help, pts help or bos help and the Unix manpages.

On all GNU/Linux-based platforms, Linux-PAM is available for service-specific authentication configuration. Linux-PAM is an implementation of PAM ("Pluggable Authentication Modules") from Sun Microsystems.

Network services, instead of having hard-coded authentication interfaces and decision methods, invoke PAM through a standard, pre-defined interface. It is then up to PAM to perform any and all authentication-related work, and report the result back to the application.

Exactly how PAM reaches the decision is none of the service's business. In traditional set-ups, that is most often done by asking and verifying usernames and passwords. In advanced networks, that could be Kerberos tickets and AFS tokens.

PAM will allow for inclusion of OpenAFS into the authentication path of all services. After typing in your password, it will be possible to verify the password against the Kerberos database and automatically obtain the Kerberos ticket and AFS token, without having to run kinit and aklog manually.

You can find the proper introduction (and complete documentation) on the Linux-PAM website. Pay special attention to the PAM Configuration File Syntax page. Also take a look at the Linux-PAM(7) and pam(7) manual pages.

Building the OpenAFS kernel module today is very simple. There are basically two methods available: the module-assistant (older) and DKMS (newer). Both of them offer an extremely simple and elegant way to not have to deal with any of the complexities behind the scenes.

sudo apt-get install build-essential dkms linux-headers-`uname -r`
sudo apt-get install openafs-modules-dkms

sudo apt-get install module-assistant
sudo m-a prepare openafs
sudo m-a a-i openafs

After the kernel module is installed, we can proceed with installing the OpenAFS client:

sudo apt-get install openafs-{client,krb5}

Debconf answers for reference:

AFS cell this workstation belongs to: spinlock.hr
# (Your domain name in lowercase, matching the Kerberos realm in uppercase)

Size of AFS cache in kB? 4000000
# (Default value is 50000 for 50 MB, but you can greatly increase the
# size on modern systems to a few gigabytes, with 20000000 (20 GB) being
# the upper reasonable limit. The example above uses 4 GB)

Run Openafs client now and at boot? No
# (It is important to say NO at this point, or the client will try to 
# start without the servers in place for the cell it belongs to!)

Look up AFS cells in DNS? Yes

Encrypt authenticated traffic with AFS fileserver? No
# (OpenAFS client can encrypt the communication with the fileserver. The
# performance hit is not too great to refrain from using encryption, but
# generally, disable it on local and trusted-connection clients, and enable
# it on clients using remote/insecure channels)

Dynamically generate the contents of /afs? Yes

Use fakestat to avoid hangs when listing /afs? Yes

DB server host names for your home cell: afs1
# (Before continuing, make sure you've edited your DNS configuration or 
# /etc/hosts file as mentioned above in the section "Conventions", and that
# the command 'ping afs1' really does successfully ping your server)

sudo mkfs.ext4 /dev/my-cache-partition
sudo sh -c "echo '/dev/my-cache-partition /var/cache/openafs ext4 defaults 0 2' >> /etc/fstab"

cd /var/cache
sudo dd if=/dev/zero of=openafs.img bs=10M count=410   # (~4.1 GB partition)
sudo mkfs.ext4 openafs.img
sudo sh -c "echo '/var/cache/openafs.img /var/cache/openafs ext4 defaults,loop 0 2' >> /etc/fstab"
sudo tune2fs -c 0 -i 0 -m 0 openafs.img

sudo mount /var/cache/openafs

Now that the kernel module and the AFS client are ready, we can proceed with the last step — installing the OpenAFS server.

sudo apt-get install openafs-{fileserver,dbserver}

Debconf answers for reference:

Cell this server serves files for: spinlock.hr

That one was easy, wasn't it? Let's follow with the configuration part to get it running:

sudo rm -f /tmp/afs.keytab

sudo kadmin.local

Authenticating as principal root/admin@SPINLOCK.HR with password.

kadmin.local:  addprinc -policy service -randkey -e des-cbc-crc:normal afs/spinlock.hr
Principal "afs/spinlock.hr@SPINLOCK.HR" created.

kadmin.local:  ktadd -k /tmp/afs.keytab -norandkey -e des-cbc-crc:normal afs/spinlock.hr
Entry for principal afs with kvno 1, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/tmp/afs.keytab.

kadmin.local:  quit

sudo asetkey add 1 /tmp/afs.keytab afs/spinlock.hr

sudo bos listkeys afs1 -localauth

key 1 has cksum 2035850286
Keys last changed on Tue Jun 24 14:04:02 2008.
All done.

sudo mkfs.ext4 /dev/my-vice-partition
sudo sh -c "echo '/dev/my-vice-partition /vicepa ext4 defaults 0 2' >> /etc/fstab"

cd /home
sudo dd if=/dev/zero of=vicepa.img bs=100M count=100   # (10 GB partition)
sudo mkfs.ext4 openafs.img
sudo sh -c "echo '/home/openafs.img /vicepa ext4 defaults,loop 0 2' >> /etc/fstab"
sudo tune2fs -c 0 -i 0 -m 0 openafs.img

sudo mkdir -p /vicepa
sudo mount /vicepa

mkdir -p /vicepa
touch /vicepa/AlwaysAttach

sudo afs-newcell

                            Prerequisites

In order to set up a new AFS cell, you must meet the following:

1) You need a working Kerberos realm with Kerberos4 support.  You
   should install Heimdal with KTH Kerberos compatibility or MIT
   Kerberos 5.

2) You need to create the single-DES AFS key and load it into
   /etc/openafs/server/KeyFile.  If your cell's name is the same as
   your Kerberos realm then create a principal called afs.  Otherwise,
   create a principal called afs/cellname in your realm.  The cell
   name should be all lower case, unlike Kerberos realms which are all
   upper case.  You can use asetkey from the openafs-krb5 package, or
   if you used AFS3 salt to create the key, the bos addkey command.

3) This machine should have a filesystem mounted on /vicepa.  If you
   do not have a free partition, then create a large file by using dd
   to extract bytes from /dev/zero.  Create a filesystem on this file
   and mount it using -oloop.

4) You will need an administrative principal created in a Kerberos
   realm.  This principal will be added to susers and
   system:administrators and thus will be able to run administrative
   commands.  Generally the user is a root or admin instance of some
   administrative user.  For example if jruser is an administrator then
   it would be reasonable to create jruser/admin (or jruser/root) and
   specify that as the user to be added in this script.

5) The AFS client must not be running on this workstation.  It will be
   at the end of this script.

Do you meet these requirements? [y/n] y

If the fileserver is not running, this may hang for 30 seconds.
/etc/init.d/openafs-fileserver stop

What administrative principal should be used? root/admin

/etc/openafs/server/CellServDB already exists, renaming to .old
/etc/init.d/openafs-fileserver start
Starting OpenAFS BOS server: bosserver.
bos adduser afs.spinlock.hr root -localauth

Creating initial protection database.  This will print some errors
about an id already existing and a bad ubik magic.  These errors can
be safely ignored.

pt_util: /var/lib/openafs/db/prdb.DB0: Bad UBIK_MAGIC. Is 0 should be 354545
Ubik Version is: 2.0

bos create afs1.spinlock.hr ptserver simple /usr/lib/openafs/ptserver -localauth
bos create afs1.spinlock.hr vlserver simple /usr/lib/openafs/vlserver -localauth
bos create afs1.spinlock.hr fs fs -cmd '/usr/lib/openafs/fileserver -p 23 -busyat 600 \
  -rxpck 400 -s 1200 -l 1200 -cb 65535 -b 240 -vc 1200' -cmd /usr/lib/openafs/volserver \
  -cmd /usr/lib/openafs/salvager -localauth
bos setrestart afs1.spinlock.hr -time never -general -localauth
Waiting for database elections: done.
vos create afs1.spinlock.hr a root.afs -localauth
Volume 536870915 created on partition /vicepa of afs.spinlock.hr
/etc/init.d/openafs-client force-start
Starting AFS services: afsd.
afsd: All AFS daemons started.

Now, get tokens as root/admin in the spinlock.hr cell.
Then, run afs-rootvol to create the root volume.

sudo su # (We want to switch to the root user)

kinit root/admin

Password for root/admin@SPINLOCK.HR: PASSWORD

aklog

aklog: Couldn't get hcoop.net AFS tickets:
aklog: unknown RPC error (-1765328184) while getting AFS tickets

klist -5f

Ticket cache: FILE:/tmp/krb5cc_1116
Default principal: root/admin@SPINLOCK.HR

Valid starting     Expires            Service principal
02/09/10 17:18:18  02/10/10 03:18:18  krbtgt/SPINLOCK.HR@SPINLOCK.HR
renew until 02/10/10 17:18:16, Flags: FPRIA
02/09/10 17:18:18  02/10/10 03:18:18  afs/spinlock.hr@SPINLOCK.HR
renew until 02/10/10 17:18:16, Flags: FPRAT

tokens

Tokens held by the Cache Manager:

User's (AFS ID 1) tokens for afs@spinlock.hr [Expires Feb 10 03:18]
   --End of list--

afs-rootvol

                            Prerequisites

In order to set up the root.afs volume, you must meet the following
pre-conditions:

1) The cell must be configured, running a database server with a
   volume location and protection server.  The afs-newcell script will
   set up these services.

2) You must be logged into the cell with tokens in for a user in
   system:administrators and with a principal that is in the UserList
   file of the servers in the cell.

3) You need a fileserver in the cell with partitions mounted and a
   root.afs volume created.  Presumably, it has no volumes on it,
   although the script will work so long as nothing besides root.afs
   exists.  The afs-newcell script will set up the file server.

4) The AFS client must be running pointed at the new cell.
Do you meet these conditions? (y/n) y

You will need to select a server (hostname) and AFS partition on which to
create the root volumes.

What AFS Server should volumes be placed on? afs1
What partition? [a] a

vos create afs1 a root.cell -localauth
Volume 536870918 created on partition /vicepa of afs1
fs sa /afs system:anyuser rl
fs mkm /afs/spinlock.hr root.cell -cell spinlock.hr -fast || true
fs mkm /afs/grand.central.org root.cell -cell grand.central.org -fast || true
.....
.....
.....
.....
.....
fs sa /afs/spinlock.hr system:anyuser rl
fs mkm /afs/.spinlock.hr root.cell -cell spinlock.hr -rw
fs mkm /afs/.root.afs root.afs -rw
vos create afs1 a user -localauth
Volume 536870921 created on partition /vicepa of afs1
fs mkm /afs/spinlock.hr/user user 
fs sa /afs/spinlock.hr/user system:anyuser rl
vos create afs1 a service -localauth
Volume 536870924 created on partition /vicepa of afs1
fs mkm /afs/spinlock.hr/service service 
fs sa /afs/spinlock.hr/service system:anyuser rl
ln -s spinlock.hr /afs/spinlock
ln -s .spinlock.hr /afs/.spinlock
vos addsite afs1 a root.afs -localauth
Added replication site afs /vicepa for volume root.afs1
vos addsite afs1 a root.cell -localauth
Added replication site afs1 /vicepa for volume root.cell
vos release root.afs -localauth
Released volume root.afs successfully
vos release root.cell -localauth
Released volume root.cell successfully

If you remember, during the AFS installation phase, we've answered "No" to the question "Run OpenAFS client now and at boot?". AFS init script is such that it just won't run the client as long as the client startup is disabled in the config file — even if you invoke sudo invoke-rc.d openafs-client start manually (you'd have to invoke sudo invoke-rc.d openafs-client force-start, but this is not what happens during regular boot). So we have to enable the client in /etc/openafs/afs.conf.client by replacing AFS_CLIENT=false with AFS_CLIENT=true:

sudo perl -pi -e's/AFS_CLIENT=false/AFS_CLIENT=true/' /etc/openafs/afs.conf.client
sudo invoke-rc.d openafs-client restart

Now let's drop any tokens or tickets that we may have initialized, to continue with a clean slate:

unlog; kdestroy

And at this point, you've got yourself one helluva OpenAFS cell up and running!

The following sections provide some more information on OpenAFS and its usage, but your installation and configuration phases have been completed.

While the whole point of AFS is in accessing files from remote workstations, remember that all AFS servers are also regular AFS clients and you can use them to browse the files just as fine. So let's explain the AFS directory structure a bit and then use our just-installed machine to look at the actual contents of the /afs/ directory.

As we've hinted in the section called “Introduction”, AFS uses a global namespace. That means all AFS sites are instantly accessible from /afs/ as if they were local directories, and all files have a unique AFS path. For example, file /afs/spinlock.hr/service/test will always be /afs/spinlock.hr/service/test, no matter the client, operating system, local policy, connection type or geographical location.

In order to avoid clashes in this global AFS namespace, by convention, each cell's "AFS root" starts with /afs/domain.name/.

Beneath it, AFS automatically creates two directories, common/ and user/. The latter is where the users' home directories should go, usually hashed to two levels, such as /afs/spinlock.hr/user/r/ro/root/.

Let's list /afs/ directory contents to verify what we've just said about AFS cells and their mount points:

cd /afs

ls | head
1ts.org
acm-csuf.org
acm.uiuc.edu
ams.cern.ch
andrew.cmu.edu
anl.gov
asu.edu
athena.mit.edu
atlass01.physik.uni-bonn.de
atlas.umich.edu

ls | wc -l

189

The 189 directories were automatically created by the afs-rootvol script, but you can create additional and remove existing mount points (AFS mount points) at will.

With the above said, we can predict that AFS has created our own directory in /afs/spinlock.hr/. This directory is only visible automatically within the local cell and is not seen by the world in ls /afs listing (because you have not asked for its inclusion in the global "CellServDB" file). Its default invisibility, however, does not make it inaccessible — supposing that you have a functioning network link, and that your cell name and server hostnames are known, your cell is reachable from the Internet).

Now that we're in AFS land, we can quickly get some more AFS-specific information on /afs/spinlock.hr/:

fs lsm /afs/spinlock.hr

'/afs/spinlock.hr' is a mount point for volume '#spinlock.hr:root.cell'

fs lv /afs/spinlock.hr

File /afs/spinlock.hr (536870919.1.1) contained in volume 536870919
Volume status for vid = 536870919 named root.cell.readonly
Current disk quota is 5000
Current blocks used are 4
The partition has 763818364 blocks available out of 912596444

The output above is showing a cell setup with 1 TB of AFS storage — the block size in OpenAFS is 1 KB.

Each time you mount a volume, you can mount it read-write or read-only.

Read-write mounts are simple — reads and writes are done through the same filesystem path, such as /afs/spinlock.hr/common/testfile, and are always served by the AFS server on which the volume resides.

Read-only mounts make things interesting — volumes may have up to 8 read-only replicas and clients will retrieve files from the "best" source. However, that brings two specifics:
First, as the read-only mount is read-only by definition, a different file path (prefixed with a dot), such as /afs/.spinlock.hr/common/testfile, must be used when access in a read-write fashion is required.
Second, any change of data in the read-write tree won't show up in the read-only tree until you "release" the volume contents with the vos release command.

As said, read-write paths for read-only mounts are prefixed by a leading dot. Let's verify this:

fs lsm /afs/spinlock.hr

'/afs/spinlock.hr' is a mount point for volume '#spinlock.hr:root.cell'

fs lsm /afs/.spinlock.hr

'/afs/.spinlock.hr' is a mount point for volume '%spinlock.hr:root.cell'

Equipped with the above information, let's visit /afs/spinlock.hr/, look around, and then try to read and write files.

cd /afs/spinlock.hr

ls -al

total 14
drwxrwxrwx 2 root root 2048 2008-06-25 02:05 .
drwxrwxrwx 2 root root 8192 2008-06-25 02:05 ..
drwxrwxrwx 2 root root 2048 2008-06-25 02:05 service
drwxrwxrwx 2 root root 2048 2008-06-25 02:05 user

echo TEST > testfile

-bash: testfile: Read-only file system

cd /afs/.spinlock.hr

echo TEST > testfile

-bash: testfile: Permission denied

Good. The first command has been denied since we were in the read-only AFS mount point. The second command has been denied since we did not obtain the Kerberos/AFS identity yet to acquire the necessary write privilege.

Now let's list access permissions (AFS ACL) for the directory, and then obtain AFS admin privileges that will allow us to write files. Note that we first establish our Kerberos identity using kinit, and then obtain the matching AFS token using aklog. Aklog obtains a token automatically and without further prompts, on the basis of the existing Kerberos ticket.

cd /afs/.spinlock.hr

fs la .

Access list for . is
Normal rights:
  system:administrators rlidwka
  system:anyuser rl

kinit root/admin; aklog

Password for root/admin@SPINLOCK.HR: PASSWORD

klist -5

Ticket cache: FILE:/tmp/krb5cc_0
Default principal: root/admin@SPINLOCK.HR

Valid starting     Expires            Service principal
06/29/08 19:38:05  06/30/08 05:38:05  krbtgt/SPINLOCK.HR@SPINLOCK.HR
        renew until 06/30/08 19:38:05
06/29/08 19:38:12  06/30/08 05:38:05  afs@SPINLOCK.HR
        renew until 06/30/08 19:38:05

tokens

Tokens held by the Cache Manager:

User's (AFS ID 1) tokens for afs@spinlock.hr [Expires Jun 30 05:38]
   --End of list--

At this point, writing the file succeeds:

echo TEST > testfile

cat testfile

TEST

rm testfile

As we've seen in previous chapters, to obtain read or write privilege in AFS, you authenticate to Kerberos using kinit and then to AFS using aklog.

We're dealing with two separate authentication databases here — the Kerberos database, and the AFS "Protection Database" or PTS.

That means all users have to exist in both Kerberos and AFS if they want to access AFS data space in an authenticated fashion. The only reason we did not have to add root/admin user to AFS PTS is because this was done automatically by the virtue of afs-newcell.

So let's add a regular AFS user. We're going to add user "mirko", which should already exist in Kerberos if you've followed the MIT Kerberos 5 Guide, section "Creating first unprivileged principal". Make sure you hold the administrator Kerberos ticket and AFS token, and then execute:

pts createuser mirko 20000

User mirko has id 20000

You will notice that Kerberos and AFS do not require any use of sudo. (Actually, we do use sudo to invoke Kerberos' sudo kadmin.local, but that's only because we want to access the local Kerberos database directly by opening the on-disk Kerberos database file). Kerberos and AFS privileges are determined solely by tickets and tokens one has obtained, and have nothing to do with traditional Unix privileges nor are tied to certain usernames or IDs.

Now that we have a regular user "mirko" created in both Kerberos and AFS, we want to create an AFS data volume that will correspond to this user and be "mounted" in the location of the user's home directory in AFS.

This is an established AFS practice — every user gets a separate volume, mounted in the AFS space as their home directory. Depending on specific uses, further volumes might also be created for the user and mounted somewhere under their toplevel home directory, or even somewhere else inside the cell file structure.

Make sure you still hold the administrator Kerberos ticket and AFS token, and then execute:

vos create afs1 a user.mirko 200000

Volume 536997357 created on partition /vicepa of afs1

vos examine user.mirko

user.mirko                        536997357 RW          2 K  On-line
    afs1.spinlock.hr /vicepa 
    RWrite  536997357 ROnly          0 Backup          0 
    MaxQuota     200000 K 
    Creation    Sun Jun 29 18:06:43 2008
    Copy        Sun Jun 29 18:06:43 2008
    Backup      Never
    Last Update Never

    RWrite: 536997357
    number of sites -> 1
       server afs1.spinlock.hr partition /vicepa RW Site 

Having the volume, let's mount it to a proper location. We will use a "hashed" directory structure with two sublevels, so that the person's home directory will be in /afs/spinlock.hr/user/p/pe/person/ (instead of directly in user/person/). Follow this AFS convention and you will be able to use libnss-afs and 3rd party management scripts without modification.

cd /afs/spinlock.hr/user

mkdir -p m/mi

fs mkm m/mi/mirko user.mirko -rw

Let's view the volume and directory information:

fs lsm m/mi/mirko

'm/mi/mirko' is a mount point for volume '#user.mirko'

fs lv m/mi/mirko

File m/mi/mirko (536997357.1.1) contained in volume 536997357
Volume status for vid = 536997357 named user.mirko
Current disk quota is 200000
Current blocks used are 2
The partition has 85448567 blocks available out of 140861236

Let's view the permissions on the new directory and allow user full access:

fs la m/mi/mirko

Access list for m/mi/mirko is
Normal rights:
  system:administrators rlidwka

fs sa m/mi/mirko mirko all

fs la !:2

Access list for m/mi/mirko is
Normal rights:
  system:administrators rlidwka
  mirko rlidwka

(On a side note, the "!:2" above is a Bash construct that will insert the 3rd word from the previous line. Expanded, that line should read "fs la m/mi/mirko")

Now switch to user mirko and verify you've got access to the designated home directory:

unlog; kdestroy

kinit mirko; aklog

Password for mirko@SPINLOCK.HR: PASSWORD

cd /afs/spinlock.hr/user/m/mi/mirko

echo IT WORKS > test

cat test

IT WORKS

AFS volumes have a concept of "volume quota", or the maximum amount of data a volume can hold before denying further writes with the appropriate "Quota exceeded" error. It's important to know that AFS volumes do not take a predefined amount of disk space as physical disk partitions do; you can create thousands of volumes, and they only take as much space as there is actual data on them. Likewise, AFS volume quotas are just limits that do not affect volume size except "capping" the maximum size of data a volume can store.

Let's list volume data size quota and increase it from the default 5 MB to 100 MB:

cd /afs/.spinlock.hr

fs lq

Volume Name                   Quota      Used %Used   Partition
root.cell                      5000        28    1%         38% 

fs sq . 100000

fs lq

Volume Name                   Quota      Used %Used   Partition
root.cell.readonly           100000        28    1%         38% 

A complete LDAP setup is explained in another article from the series, the OpenLDAP Guide. If you have followed and implemented the procedure, especially the part about modifying /etc/nsswitch.conf, then there's only one thing that should be done here — you should modify users' entries in LDAP to make their home directories point to AFS instead of to /home/.

Actually, you can symlink /home/ to AFS, and then no change in LDAP will be necessary. One benefit of this approach is that /home/ looks familiar to everyone. One drawback is that you need to symlink that directory to AFS on all machines where users will be logging in.

To create the symlinks, use:

sudo mv /home /home,old
sudo ln -sf /afs/.spinlock.hr/user /home
sudo ln -sf /afs/spinlock.hr/user /rhome

To literally change users' home directories in LDAP (to point to /afs/spinlock.hr/user/u/us/user/), construct a LDIF file and use ldapmodify to apply the LDIF file.

Here's an example for user mirko (which should already exist in your LDAP directory if you've followed the OpenLDAP Guide Guide). Save the following as /tmp/homechange.ldif:

dn: uid=mirko,ou=people,dc=spinlock,dc=hr
changetype: modify
replace: homeDirectory
homeDirectory: /afs/spinlock.hr/user/m/mi/mirko

And apply using:

ldapmodify -c -x -D cn=admin,dc=spinlock,dc=hr -W -f /tmp/homechange.ldif

As said, libnss-afs is an AFS-dependent approach to serving metadata, so it only makes sense to describe it in the context of the OpenAFS Guide.

Adam Megacz created libnss-afs on the basis of Frank Burkhardt's libnss-ptdb, which in turn was created on the basis of Todd M. Lewis' nss_pts. The primary motivation for libnss-afs has been the use at HCoop, the first non-profit corporation offering public AFS hosting and accounts.

Good. Let's move onto the technical setup:

libnss-afs must run in combination with nscd and cache the replies from the AFS ptserver, so let's install nscd:

sudo apt-get install nscd

Once nscd is installed, edit its config file, /etc/nscd.conf to include the following:

enable-cache hosts no
persistent passwd no
persistent groups no
persistent hosts  no

(Note that all of the above lines already exist in /etc/nscd.conf, although the formatting of the file is a bit strange and finding them is an exercise for your eyes. So you should not be adding the above lines in there, but just locating them in the config file and turning the appropriate "yes" to "no".)

Then, restart nscd as usual with sudo invoke-rc.d nscd restart.

libnss-afs homepage is on libnss-afs, and the software can be downloaded as Gitweb tarball. Once the tarball is unpacked, Debian package can be built and installed by cd-ing into the libnss-afs/ directory and running:

sudo apt-get install libopenafs-dev

sudo dpkg-buildpackage

sudo dpkg -i ../libnss-afs*deb

After libnss-afs is installed, let's modify the existing lines in /etc/nsswitch.conf to look like the following:

passwd:  afs files
group:   afs files
shadow:  files

We are ready to test metadata retrieval:

sudo nscd -i passwd

id mirko

uid=20000(mirko) gid=65534(nogroup) groups=65534(nogroup)

getent passwd mirko

mirko:x:20000:65534:mirko:/afs/hcoop.net/user/m/mi/mirko:/bin/bash

auth    sufficient        pam_unix.so nullok_secure
auth    sufficient        pam_krb5.so use_first_pass
auth    optional          pam_afs_session.so program=/usr/bin/aklog
auth    required          pam_deny.so

session required pam_limits.so
session optional pam_krb5.so
session optional pam_unix.so
session optional pam_afs_session.so program=/usr/bin/aklog