Greetings all:
A-ha, now I see what the problem is.
Excellent! What is the problem? :p
sandbox1# /vice/bin/pdbtool list
Is this the whole output? Note that "pdbtool list" may be not reliable,
it does not necessarily output the whole database (not big databases
anyway). The reliable way to examine the whole contents is
"pdbtool export".
Our database is tiny. I ran pdbtool export and it shows the same data (in
/etc/passwd,group format). The key to understand, is that there is no ID
484. Here's the parsed down output (if you want me to send the full output
privately, I can do that):
codaadmin:*:83886:500::/:
codauser:*:83896:500::/:
System%Administrators:*:-1:realmadmin,codaadmin
System%AnyUser:*:-2:System
GROUP%codauser:*:-8:codauser
sandbox4# cunlog @coda.realm; clog admin -keytab admin-krb5.keytab; ctokens
@coda.realm
Another remark, it would help a lot if you use "clog acco...@realm",
otherwise you implicitely refer to your clog config, which is
an additional source of possible errors.
Ok, no change:
sandbox4# cunlog @coda.realm; clog codau...@coda.realm -keytab
~/.codafs/clog/krb5.keytab; ctokens @coda.realm
Tokens [local user id: root]
@coda.realm
Coda user id: 484
Expiration time: Thu Mar 4 23:12:46 2010
sandbox4# cunlog @coda.realm; clog user -keytab user-krb5.keytab; ctokens
@coda.realm
What is "user" ??? (see my remark above)
maps to codau...@coda.realm
What does your /vice/auth2/AuthLog say at the time of clog?
18:13:01 vid = 83886
18:13:01 AuthNewConn(0x7da9cdba, 0, 66, 2, 83886)
22:11:47 vid = 484
22:11:47 AuthNewConn(0x72199dd5, 0, 66, 2, 484)
Where is coda getting this ID? Clearly it believes there is a 484, but
executing: pdbtool export /tmp/file1 /tmp/file2; grep 484 /tmp/file?
results in null output.
Note that in a multiserver realm clog may talk to any of the
authentication servers. Have the servers (if multiple)
synchronized data?
Not applicable. There is only one for simplicity of testing.
Logged in as coda admin, IDs match and everything works. Logged in
as any other coda user, and IDs do NOT match, and cannot access
anything.
This is odd.
I'd hate to waste your time with anything less.
Does it happen even if you use Coda password authentication?
Yes. I don't have the output handy on that one, but there's no change.
Even if it didn't, as you said, coda's IDs are internal to itself. It would
do nothing to answer the question of where coda is getting ID 484.
FYI: I tried issuing a /vice/bin/codaservice stop/start on the coda server,
and cunlog/clog/ctokens on the coda client, and still have ID 484 in both
token and AuthLog.
Very much waiting for assistance on this one.
Thanks,
-Don
{void}
