On Thu, 31 Jan 2008, u+codalist-p4pg_at_chalmers.se wrote:

> It is not a task for a computer's login setup to know about
> the user's realms of interest. The user having a homedir on Coda
> is capable of using it on _any_ computer where (s)he can log in,
> not only on a computer sharing its administrator with the realm servers.
> Given multiple realms such "sharing" is plainly impossible.

Hmm, I can see the point you're making. Coda is too global a system for 
UIDs to be sensibly replicatable.

I think I'll have to read up on coda ACLs in more detail.

> _This_ information is in fact present on Coda servers (IIRC) but not exported
> in a sensible way. It should though _not_ be exported numerically
> as Coda numeric uids have nothing to do with a certain host local uids.
> A (not yet present) "cfs ls-al" command might be appropriate,
> presenting the Coda-specific metainformation (not numbers) instead of /bin/ls
> who does not know any better than the local Unix owner/group/other.

OK, I get it. I'll ignore the UIDs.

>>> Ok, there is not yet any pam_create_passwd_entry_on_the_fly module :)
>>> either write one or with some easy tricks put a shared version of
>>> /etc/passwd and /etc/group on Coda (egg-och-chicken has to be taken care
>>> of, at boot, but this is easy).
>>
>> This is why I would ideally like to do it off NIS or another centralized
>> method.
>
> I offer you a simple way to avoid maintaining an extra service and you refuse,
> why? :)

Something to do with the fact that I need a centralized authentication 
service anyway. :)

>>> Do not forget to never use the numeric uids for anything,
>>> this will improve your life, trust me. :)
>>
>> Can you elaborate on this? How will that make things better? Remember, I'm
>> a Coda newbie, with many years of traditional UNIX ways to unlearn.
>
> I tried to elaborate above. There is a lot to unlearn with Coda,
> (took myself years). That's probably the biggest obstacle for its popularity.
> People have very hard time thinking beyond "a better NFS" which Coda
> is definitely not.

It's largely to do with the fact that the standard UNIX tools (chmod et 
al) don't work sanely in a coda environment. Things don't just behave one 
might expect them to. The integration is just not seamless enough. Some of 
it may be correctable, some of it may not be.

>>> I think we could arrange an (expensive) course on that matter :)
>>> and most of experienced sysadmins would find something to learn there :(
>>
>> That may not be a bad idea. :)
>
> Go ahead. I can be available given a reasonable compensation,
> did I say it is going to be expensive? :)
>
> Alas, I think it is even hard to make people realise that they need
> to (un)learn something. You will hardly collect a class... :)

I was just thinking about whether you might get enough people together to 
make it worthwhile. :)

>>> When someone e.g. tries to implement such a feature,
>>> he or she is missing the point.
>>
>> Maybe so, but that doesn't mean that seeing the right username in ls -l
>> output is a bad thing. It's useful.
>
> What is a "right username" on a file under /coda/testserver.cs.cmu.edu ?
> How would your "ls" know that name?
> In my eyes "unknown" is as right as it can be
> but unfortunately ls does not have a documented way to cause such output
> on certain file systems :)

I understand. There needs to be an automagical way for the coda username 
to be presented by ls, rather than a uid cross-reference to the unix user 
database. I know this sounds crazy, but maybe a ls replacement wrapper 
that calls ls or coda's equivalent depending on what is mounted? Of 
course, then there's the whole POSIX compatibility abstraction layer that 
still wouldn't work...

> The Coda kernel module could in fact return something
> more meaningful than unusable and confusing uid numbers it currently
> returns (could be say either the running process' local uid
> or the local "nobody" uid). This would not solve anything but
> reduce the confusion.

Or just have the main package add a coda user (if one doesn't already 
exist in passwd/nis/ldap/whatever) and always say that the uid/gid of all 
coda files is "coda"...

>> Thanks, I'll have a look at the docs. Would using Kerberos authentication
>> allow for:
>> 1) not having to explicitly clog in
>> 2) uid replication for that missing the point ls -l output
>
> It is orthogonal, you can or can't, both with or without Kerberos.
>
> Kerberos makes it possible to maintain the identities and
> authentication information in one place and use them in multiple
> service contexts:
>
> - Coda acls
> - Login rights (essentially login acls, expressed often in terms of
>  account pam module options)
> - other, like IMAP service
>
> Note, login is a service.
>
> It is of course easier to arrange "integrated login" to several services
> if all of them use the same type of identification (in this case Kerberos).
>
> "Uid replication" is a (NFS-specific) directory service which maps
> names to numbers and vice versa.
> Nothing to do with Coda, nothing to do with Kerberos.

OK, I'm convinced. I'll forget about uids.

> (Now, would you be so kind to put the questions and the answers on the Wiki? :)

Will do, although it may be a few days before I have a chance to fully 
review all that has been said and break it down into sensible sections. :)

Gordan