Hi Gordan,

On Thu, Jan 31, 2008 at 11:25:14AM +0000, coda_at_bobich.net wrote:
> using clog username, there's a chicken and the egg problem with putting 
> that into the user's .bashrc (because that lives in the home directory, 
> which is in Coda, which cannot be accessed until the user has logged in).

One-time it is apparently no problem, just log in without homedir,
clog manually, logout, log in.

Coda is theoretically capable of keeping the cached files accessible
for the uid who cached/accessed them, even when there are no tokens
around any more.

Unfortunately this rights management has been implemented in such a way
(long time ago) that it is really hard to do it right.
The net result is: you may try to use this possibility, but make sure
you explicitely access all files which must be present before clog -
_after_ any clog you may have done. This seems to refresh the accessibility.

This is my approach based on some guesses, totally "unsupported".
Seems to work though, somehow. Hope one nice day Jan will
rewrite that part of the code and fix the old (originally flawed, it seems)
logic.

> data. Also, home directories would need to remain accessible to users' 
> accounts between logins, so their cron jobs can run with access to their 
> files. How can this be achieved?

Of course, just give the cron jobs relevant credentials.

It can be differing accounts, with rights to a subset of the user files,
their passwords can be stored on the local disk.

Note that the cron jobs do not have to run under users' local uids,
they just have to have proper credentials.

Note also that cron jobs do not have to run on the same computer
as the users log in (watch out for concurrent updates, of course!).

In general, you will have to forget a lot of traditional Unix ways of doing
things, they are very often plain wrong when applied to global file systems.

Cron is one application not designed with such systems in mind.

Coda is fortunately quite "unattended job"-friendly, the tokens are attached
to a local uid, so it is easy to refresh them from an independent
process, without playing tricks with PAGs.

> The next question that arises is how to authenticate Coda from a 
> centralized user database, so as to make it transparently fit with the 
> rest of the system (authenticating via NIS, or LDAP/Kerberos). I have seen 

Short: forget NIS and LDAP, they have nothing to do with Coda.
(Not with authentication either, they are nothing but directory services.
They are often abused as a delivery mechanism for authentication data,
but that's all.)

In some sense, Coda can not "fit the rest of the system",
while it can gracefully cooperate of course. See it that way:
build your system "to fit Coda" if you want the best result.

As the first step, do not synchronize user ids between computers.
It is NFS who needs that, why else? Your directory service does not have
to include numerical uids, you can even create local passwd entries
"on-the-fly" as needed. Essentially all a directory service may need to
contain is the lists of who is allowed to log in to which host.
A _lot_ of complexity in traditional setups will be gone.

It is easy to put the login-allowed lists and similar on Coda,
so you do not need any LDAP nor NIS.
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).
Do not forget to never use the numeric uids for anything,
this will improve your life, trust me. :)

> references to both NIS and Kerberos being used in the list archives, but 
> I've yet to find any documentation that explains how to set it up. Is 
> there such a piece of documentation somewhere that somebody could point me 
> at, please?

I think we could arrange an (expensive) course on that matter :)
and most of experienced sysadmins would find something to learn there :(

No, there is no such document. There are few people who really
understand the matters and know Coda. They usually have no extra time.
Feel free to use the suggestions above.

Coda is a global system, even if you deply it locally, so it is devastating
to apply the traditional practices. Then Coda would become hardly as good
as other file systems, while it can do a lot more - and does not do some
traditional but fundamentally unsuitable things.
As an example - show a "right" username in "ls -l" output.
When someone e.g. tries to implement such a feature,
he or she is missing the point.

As for making a Coda realm trust a Kerberos realm for authentication,
we are running such setups and we include full support in the client and
server installers (www.dapty.com->Getting Started->Coda HowTo).
Unfortunately, a server setup HowTo is yet to be written. The client
does not need any setup.

Regards,
Rune