Yes, the identical id's are pathological, although I do not recall
anything particularly screwy about setting up either of those groups.
The one thing that prdb_check turns up, and that looks vaguely wrong, is
the zero header:
[root@afs1c db]# prdb_check -verbose -database prdb.DB0.copy -uheader
Ubik Header
Magic = 0x354545
Size = 0
Version.epoch = 1316114301
Version.counter = 2
Ubik header size is 0 (should be 64)
Database has 14 entries
What do you suggest?
Danko
Andrew Deason wrote:
On Fri, 16 Sep 2011 15:33:09 -0400
Danko Antolovic <[email protected]> wrote:
Is the "@" syntax implemented in the "fs setacl" command? It looks as
if only the first half of the foreign user/group name was considered.
Yes; to just alleviate your fears (if I were in your situation, I would
be skeptical that 'fs' accepted that syntax), I can certainly do this:
$ fs sa /afs/.localcell system:[email protected] l
$ fs la /afs/.localcell
Access list for /afs/.localcell is
Normal rights:
system:[email protected] l
system:administrators rlidwka
system:anyuser rl
What am I missing?
I'm not sure how the pt database managed to get in this state, but
something appears pretty screwed up. Just to show you what this would
normally look like:
$ pts examine system:authuser
Name: system:authuser, id: -102, owner: system:administrators, creator:
system:administrators,
membership: 0, flags: S-M--, group quota: 0.
$ pts examine system:[email protected]
Name: system:[email protected], id: -5029, owner: system:administrators, creator:
adeason,
membership: 0, flags: S-M--, group quota: 0.
But your cell looks like:
$ pts examine system:authuser -cell afs1.bedrock.iu.edu -noauth
Name: system:authuser, id: -102, owner: system:administrators, creator:
system:administrators,
membership: 0, flags: S-M--, group quota: 0.
$ pts examine system:[email protected] -cell afs1.bedrock.iu.edu -noauth
Name: system:authuser, id: -102, owner: system:administrators, creator:
system:administrators,
membership: 0, flags: S-M--, group quota: 0.
Note that both groups appear to be pointing at the same id, even though
'listent -groups' lists a different one, suggesting that the ptdb is
corrupt, probably due to a name hash chain pointing at the wrong thing.
Do you have the tool prdb_check? Copy prdb.DB0, and run
'prdb_check prdb.DB0.copy'.
_______________________________________________
OpenAFS-info mailing list
[email protected]
https://lists.openafs.org/mailman/listinfo/openafs-info
