[OpenAFS] Debian - openafs -noauth problems

[Madhusudan Singh]

Hi

Thanks for your patience.

On Monday 15 August 2005 12:44 pm, Sergio Gelato wrote: 

> * Madhusudan Singh [2005-08-15 11:26:16 -0400]:
> > On Saturday 13 August 2005 7:41 am, Sergio Gelato wrote:
> > > * Madhusudan Singh [2005-08-12 15:34:14 -0400]:
> > > > Tokens held by the Cache Manager:
> > > >
> > > > User's (AFS ID 2) tokens for afs@omega.domain.edu [Expires Aug 13
> > > > 01:18]
>
> Would that be omega.eecs.umich.edu ?
>

It might have been so a year ago, but no, not today.

> > omega:~# head -1 /etc/openafs/server/krb.conf
> > KERBEROS.DOMAIN.EDU
>
> So you say it checks out.

I guess so.

>
> Did you also check the consistency of the KDC's view of things (key, kvno)
> with the contents of your own KeyFile ? Any discrepancy at that level

My /etc/openafs/server/KeyFile was generated using asetkey from the supplied 
keytab.

How do I check what is going on there ?

Further, if I am able to authenticate and obtain tickets, should it not just 
work from there on ?

My /etc/krb5.conf :

[logging]
        default = FILE:/var/log/krb5libs.org
[libdefaults]
        default_realm = KERBEROS.DOMAIN.EDU
        krb5_config = /etc/krb.conf
        krb5_realms = /etc/krb.realms
        forwardable = true
        proxiable = true
        noaddresses = true
        default_keytab_name = FILE:/etc/krb5.keytab
        default_tgs_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 
des-cbc-crc des-cbc-md5
        default_tkt_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 
des-cbc-crc des-cbc-md5
        permitted_enctypes = aes256-cts arcfour-hmac-md5 des3-hmac-sha1 
des-cbc-crc des-cbc-md5


You were making a reference to the enctypes earlier. Could above be a part of 
the reason for my inability to work on the filesystem ?

> would not show up using -localauth but only when using token-based
> authentication; which means you can test it by issuing some vos commands
> on your server, both with -localauth and using an administrator's tokens.
> "vos create" and "vos remove" should be adequate for this test.
> A difference between "fs setacl /afs" and "vos create" is that the
> latter doesn't involve the /afs mount point; that should help draw
> the line between authentication on the one hand and afsd issues on the
> other.

vos commands did work for me when I created the partition. But I believe that 
I issued them while running bos under -noauth. Could that have caused these 
problems ?

Should I then recreate root.afs on /vicepa while authenticated as the admin ? 
If so, how do I delete that volume first ?

>
> You should also dump your pts database with pt_util, and make sure
> it's correct. I have:
>

omega:/etc# pt_util -p /var/lib/openafs/db/prdb.DB0 -m
Ubik Version is: 2103638850.67108864
system:backup 2/0 -205 -204 -204
system:administrators 130/20 -204 -204 -204
   <adminname>  2
system:ptsviewers 2/0 -203 -204 -204
system:authuser 2/0 -102 -204 -204
system:anyuser 2/0 -101 -204 -204

where <adminname> is the name of the admin here.

omega:/etc# cat /etc/openafs/server/UserList
cat: /etc/openafs/server/UserList: No such file or directory

Hmm.

> If none of this yields any clues, then I'm not sure what to do. Wipe out
> the entire openafs-*server configuration and redo it from scratch may be
> part of the answer; you'll probably end up with a working cell but we
> won't know exactly what went wrong the first time.

"Keep rebooting windows until it works" type of solution is not one I want to 
go for.