I was able to delete and re-create the foreign-realm group:
[root@afs1c afs]# pts delete system:authu...@ads.iu.edu -noauth
[root@afs1c afs]# pts creategroup -name system:authu...@ads.iu.edu
-owner system:administrators
group system:authu...@ads.iu.edu has id -207
[root@afs1c afs]# pts listentries -groups
Name ID Owner Creator
system:administrators -204 -204 -204
system:backup -205 -204 -204
system:anyuser -101 -204 -204
system:authuser -102 -204 -204
system:ptsviewers -203 -204 -204
system:authu...@ads.iu.edu -207 -204 2
The command prdb_check -verbose -entries turns up a database item for
this group, apparently with the correct id:
Entry at 67136: flags 0x2, id -207i, next 0.
c:09/22 11:51:47 a:time-not-set r:time-not-set n:time-not-set
hash (id 0 name 0). Owner -204i, creator 2i
quota groups 0, foreign users 0. Mem: 0, inst: 0
Owned chain 0, next owned 66368, inst ptrs(0 0 0).
Name is 'system:authu...@ads.iu.edu'
But pts examine is still apparently looking at system:authuser, as if
not understanding the foreign-realm group name:
[root@afs1c afs]# pts examine system:authu...@ads.iu.edu
Name: system:authuser, id: -102, owner: system:administrators, creator:
system:administrators,
membership: 0, flags: S-M--, group quota: 0.
Similarly, fs setacl merely adds the group system:authuser to the
ACL, again as if not understanding the group name:
[root@afs1c afs]# fs listacl /afs/afs1.bedrock.iu.edu
Access list for /afs/afs1.bedrock.iu.edu is
Normal rights:
system:administrators rlidwka
system:authuser rlidwka
dantolov rlidwka
[root@afs1c afs]# fs setacl -dir /afs/afs1.bedrock.iu.edu -acl
system:authu...@ads.iu.edu rlidwka
[root@afs1c afs]#
[root@afs1c afs]# fs listacl /afs/afs1.bedrock.iu.edu
Access list for /afs/afs1.bedrock.iu.edu is
Normal rights:
system:administrators rlidwka
system:authuser rlidwka
system:authuser rlidwka
dantolov rlidwka
Incidentally, this is openafs-1.6.0, which is not terribly old. Have
there been any recent changes to the foreign-realm groups code?
Thanks,
Danko
Danko Antolovic wrote:
Another facet of the foreign-realm groups: when creating a
foreign-realm group, I had to give it an explicit owner. The command
"pts creategroup" reports the id -206 for the newly created group, and
so does "pts listentries"; command "pts examine" shows the id
-102, and the name of the existing group system:authuser.
I had completely removed the existing prdb.DB0, and was in the process
of rebuilding it, when I noticed this anomaly. Does this mean that the
foreign-realm group is screwed up, as before, or is there something
wrong with "pts examine" ?
Below are the instructions, in the sequence in which I issued them.
Danko
[root@afs1c afs]# pts creategroup system:authu...@ads.iu.edu
pts: Badly formed name (group prefix doesn't match owner?) ; unable to
create group system:authu...@ads.iu.edu
[root@afs1c afs]# pts creategroup -name system:authu...@ads.iu.edu
-owner system:administrators
group system:authu...@ads.iu.edu has id -206
[root@afs1c afs]# pts examine system:authuser
Name: system:authuser, id: -102, owner: system:administrators,
creator: system:administrators,
membership: 0, flags: S-M--, group quota: 0.
[root@afs1c afs]# pts examine system:authu...@ads.iu.edu
Name: system:authuser, id: -102, owner: system:administrators,
creator: system:administrators,
membership: 0, flags: S-M--, group quota: 0.
[root@afs1c afs]# pts listentries -groups
Name ID Owner Creator
system:administrators -204 -204 -204
system:backup -205 -204 -204
system:anyuser -101 -204 -204
system:authuser -102 -204 -204
system:ptsviewers -203 -204 -204
system:authu...@ads.iu.edu -206 -204 2
Andrew Deason wrote:
On Sun, 18 Sep 2011 13:30:02 -0400
Danko Antolovic <danto...@indiana.edu> wrote:
[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?
Hmm, that's all it outputs? Don't worry about the 'size' thing; that
check is just broken (should be fixed in gerrit 5466).
If you just want it to be up and running, it's probably easiest to just
delete the existing ptdb and start over from scratch (that is, with the
ptdb, not with everything). Since the database is rather small, that
shouldn't be too much of a problem.
We'd also like to look at fixing whatever's wrong with the database
though, so if you could at least save a copy of it as it exists now so
we could take a look at it, that'd be great.
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
_______________________________________________
OpenAFS-info mailing list
OpenAFS-info@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-info
