[OpenAFS-devel] pts examine

[Martin MOKREJŠ]

On 3 Dec 2002, Derek Atkins wrote:

Hi,

> If you ignore the @XXX then how are you supposed to look up cross-cell
> pts ids?  For example:

You're right, it's not that simple. :(

> I suppose we could:
>         1) downcase the @(realm>
>         2) if <realm> == cell (which is either on the command-line or implied)
>            then drop it from the string.
>
> But that seems an awful lot of work to me.  However, feel free to send in
> a patch ;)

Unfortunately I'm not a programmer.

> Martin MOKREJŠ <mmokrejs@natur.cuni.cz> writes:
>
> > # pts examine mokrejs/admin@GSF.DE -noauth
> > pts: User or group doesn't exist so couldn't look up id for mokrejs/admin@gsf.de

Would someone believe that I'm so stupid to put into UserList usernames in
a syntax of kerberos5 and NOT kerberos4? Thanks to Johan Danielson who
pointed me to this problem.

Yes, having mokrejs/admin@GSF.DE there was my problem and that was the
reason why my AFS authentication did not work (kerberos KDC worked and
issued tickes for me, also AFS tokens), but ptserver/fs and others said
always "Permission denied".

Would be nice if bosserver and ptserver would check that users specified
are entered in the mokrejs.admin@GSF.DE way. Probably syntax checking of
the whole UserList file during startup would be the best and when
inserting new users into the list. :)


> > # pts examine -nameorid 3 -force -noauth
> > Name: mokrejs/admin, id: 3, owner: system:administrators, creator: anonymous,
> >   membership: 1, flags: S----, group quota: unlimited.
> > # pts examine -nameorid 4 -force -noauth
> > Name: mokrejs, id: 4, owner: system:administrators, creator: anonymous,
> >   membership: 0, flags: S----, group quota: 20.
> > # pts examine mokrejs/admin -noauth
> > Name: mokrejs/admin, id: 3, owner: system:administrators, creator: anonymous,
> >   membership: 1, flags: S----, group quota: unlimited.
> > #
> >
> > I think mokrejs/admin@GSF.DE might not be converted to mokrejs/admin@gsf.de at least,
> > at the best the "@GSF.DE" could be removed from the string, if it's really
> > causing lookup failure. Any opinions?

-- 
Martin Mokrejs <mmokrejs@natur.cuni.cz>, <m.mokrejs@gsf.de>
PGP5.0i key is at http://www.natur.cuni.cz/~mmokrejs
MIPS / Institute for Bioinformatics <http://mips.gsf.de>
GSF - National Research Center for Environment and Health
Ingolstaedter Landstrasse 1, D-85764 Neuherberg, Germany
tel.: +49-89-3187 3683 , fax: +49-89-3187 3585