[OpenAFS] Openafs broken on Ubuntu Hardy ?

[Sergio Gelato]

* Madhusudan Singh [2008-10-14 11:52:37 -0700]:
> >> I am running the latest versions of openafs-modules-source, openafs-client
> >> and openafs-krb5 on an up to date installation of Ubuntu Hardy. I used
> >> modules-assistant to compile the kernel module against my kernel :
> >> $ uname -r
> >> 2.6.24-21-generic
> >>
[...]
Stefan Pohl:
> > I just completed an OpenAFS-client test setup on Ubuntu Hardy. Same
> > versions of the Openafs-stuff, slightly older kernel (2.6.24-19-generic) and
> > it works. So it's not broken on Ubuntu Hardy as such.
> 
> Ok. That gives me hope.

I upgraded from -19 to -21 this morning, built and installed
openafs-modules-2.6.24-21-generic_1.4.6.dfsg1-2+2.6.24-21.42_i386.deb
using m-a as usual, and it still works.

> >> :$ cd /afs/YYY.edu/users/X/Y/Z/XYZABC
> >> bash: cd: /afs/YYY.edu/users/X/Y/Z/XYZABC: Permission denied
> >>
> > This look like the user you authenticate as, simply doesn't have the
> > required permissions to access the directory.
> 
> Impossible. I can ssh into the server with the same username and password
> without any issues. I use rsync to do regular (every 1 hour) backups to this
> directory ( a process that is cumbersome, which is why I am looking to set
> up my openafs client).

All right. Your problem *is* client-side, then. Could you look at the
output of "klist -a -n" and verify that your AFS service ticket is for
the right address? (Addressless is usually OK.) NAT gateways sometimes
interfere.

> o/p of fs listacl at the above level (which is one level above my own
> directory) :
> 
> $ fs listacl
> Access list for . is
> Normal rights:
>   systems:backup rl
>   system:administrators rlidwka
>   system:anyuser rl

In other words, you don't need a token to get this far: the ACL grants
anonymous read access.

> I cannot cd into my own directory, so I ssh'ed into the server and issued fs

Which authentication method did you use with ssh? Does GSSAPI work?

> listacl :
> 
>   $ fs listacl
> Access list for . is
> Normal rights:
>   systems:backup rl
>   www-hosts l
>   system:administrators rlidwka
>   XYZABC rlidwka
 
Looks good. One question, though: is the server you ran this on a member
of www-hosts ?

> The owner of all directories under /afs/YYY.EDU/users/X/Y/Z is root.root
> (tested both through the local /afs tree and by ssh'ing to the server and
> doing a cd ..). I do not recall what this was when things were working fine
> (never needed to check), but is this normal (sounds fishy) ? In a different
> cell, a long time ago, I seem to vaguely recall that the directory was owned
> by the user in question. 

The UID that owns the volume root has implicit "a" permission on all
directories in the volume. That would let you recover from a "fs setacl
$HOME XYZABC none" without having to bother the AFS administrators. But
since the ACL explicitly grants you full access, you should have full
access --- as long as your token is valid.

> To test if this was messing up things, I cd'ed to
> /afs/YYY.EDU/users/X/Y/Z/XYZABC and issued a command :
> 
> $ cd XYZABC/Private
> bash: cd: XYZABC/Private: Permission denied

So you were trying to access /afs/YYY.EDU/users/X/Y/Z/XYZABC/XYZABC/Private ?

Was this on the server or on your client? If on the client (as your
other statements are suggesting), it simply restates that your token 
is not being accepted. If on the server, I'd want to see the ACL on 
that subdirectory (and know whether the server is in www-hosts).

> This is more nonsense as ~/Private holds my backups :) Maybe the fact that I
> do not own /afs/YYY.EDU/users/X/Y/Z/XYZABC is shortcircuiting that command.

I don't see how that would work as an explanation.

> The owner of all files inside /afs/YYY.EDU/users/X/Y/Z/XYZABC is obviously
> XYZABC.

Not so obviously since you said that the top-level directory is owned by
root, not by XYZABC. You could be locked out of a subdirectory by its ACL.

My impression is that the token you got on your client is either invalid
or belongs to a different AFS user. The explanations I can think of are
(a) that you are behind a NAT and your token is for the wrong address;
(b) that you're obtaining the token via Kerberos cross-realm and it's
really for user XYZABC@OTHER.REALM (in which case you could try
	fs setacl /afs/YYY.EDU/users/X/Y/Z/XYZABC XYZABC@other.realm all
on the server where you do have access, or learn how to authenticate to
the correct realm in the first place).

Can't the helpdesk at YYY.EDU help you with this?