Hi Gordan,

you questions are in fact really good in the sense of being typical
for a seasoned system administrator,
so I am trying to explain what is wrong with these...

And a note also:

On Thu, Jan 31, 2008 at 01:36:06PM +0000, coda_at_bobich.net wrote:
> >rewrite that part of the code and fix the old (originally flawed, it seems)
> >logic.
> 
> I don't think the logic is flawed, it just needs to be hooked from 
> somewhere when the user is logging in, not afterwards.

I should have been more clear. Broken is the logic of implementation,
which was not presented (pretty complicated, I do not have a clean picture
of it either), which is unfortunately not what the semantics should be.
That's why the behaviour is currently broken in several ways,
including problems to access cached files when you have a net
connection but no tokens.

> mention that having a unified way to change the login (local or 
> centralized) and clog passwords at the same time would be useful, too.

Note that Coda objects in your realm are accessible with your realm's
accounts on all Coda-aware computers of the world, not only those you
install and administer yourself. As such, any synchronization is limited.
As soon as your realm users want to access things from their homes,
you have no way to sychronize anything. As soon as your users begin
accessing other Coda realms, you can not synchronize anything.

It was in the past that resources were bound to _computers_ which could
access them. Not the case with Coda.

Of course, it is good to let the _users_ synchronize their passwords,
but in general a user is interested in clog-ing to several realms
which of course have different policies, account names and passwords.

(Not a problem though, the modular clog handles this situation
transparently, given suitable .codafs/clog/pref and possibly
several passwords)

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.

> What harm is there in synchronising uids/gids? It just makes things easier 
> when you want to know who created a file.

_Why_ in the first hand do you want to know who created the file?
(probably because you believe it is the person who has the responsibility
for the file's contents; doubtful even on Unix)
_Why_ do you need any numeric uid for this purpose?

You see. The responsibility has the one who has the rights. Nothing
to do with any "owner", which is just a (quite limited) Unix way to grant
privileges. Not on Coda. So you do not need a numeric uid of the "owner",
possibly you want to know who was the last who modified the file.

_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, 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? :)

> >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.

> >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... :)

> >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 :)

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.

> And if it can be achieved by bolting 

Sigh. I tried hard to open your eyes, if you still believe that
"it can be achieved", then we are still on the point 0.

> 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.

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

Best regards Gordan,
Rune