[OpenAFS] Re: OpenAFS and AD trusts

[Danko Antolovic]

I was able to delete and re-create the foreign-realm group:

[root@afs1c afs]# pts  delete system:authuser@ads.iu.edu   -noauth  

[root@afs1c afs]# pts creategroup -name  system:authuser@ADS.IU.EDU  
-owner  system:administrators
group system:authuser@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:authuser@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:authuser@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:authuser@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:authuser@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:authuser@ads.iu.edu
> pts: Badly formed name (group prefix doesn't match owner?) ; unable to 
> create group system:authuser@ads.iu.edu
>
> [root@afs1c afs]# pts creategroup -name  system:authuser@ADS.IU.EDU  
> -owner  system:administrators
> group system:authuser@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:authuser@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:authuser@ads.iu.edu   -206   -204       2
>
>
>
>
>
> Andrew Deason wrote:
>> On Sun, 18 Sep 2011 13:30:02 -0400
>> Danko Antolovic <dantolov@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