> As a first guess, I'd suspect a key version difference between the server
> ticket constructed from the key in /usr/afs/etc/KeyFile and that being
> used by the "afs" principal in the kerberos database. However, I have to
Yes, but I get the impression from Renata's post that the job accually
succeeds and a key skew would cause the backupsys to fail. The server
will have to decrypt the administrators ticket with its Keyfile, and
the admin ticket is encrypted with the afs entry in the DB. So if the
DB and Keyfile don't match, not only would the backupsys fail, but all
other access to the server that required privilege (reading protected
files, moving/creating/deleting volumes, ... just about everything)
would also fail.
Im also just shooting from the hip here, but I would look at ALL the
KeyFiles with bos listkey and look at the afs entry in the db (with
kas examine). The keyfiles should be identical, and I can't imagine
an "extra" key in one of the files causing a problem, but perhaps so.
In general, I would check all the basic configuration on all servers
and the client you are running from. I have seen some cases where the
problem is configuration and we spend alot of time digging in the
code looking for a nonexistant bug.
* correct and consistent server CellServDB files (/usr/afs/etc)
* correct and consistent client CellServDB files (/usr/vice/etc - and
don't forget the check the clientside CSDB files that are on your
server machines
* correct ThisCell files (both /usr/vice/etc and /usr/afs/etc)
* correct License files on servers
* accurate and consistant time (the error for time skews is different,
but it can't hurt to check anyway)
Then also try a few more tests to see if this only happens on the one
machine and if it only happens with the one command.
Pierette VanRyzin
Transarc Educational Services (AFS/DFS)
