On Thu, 31 Jan 2008, u+codalist-p4pg_at_chalmers.se 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.

Fair enough. It's a bodge, but I can see that it might work since caching 
makes the files and credentials stick. It still means doing what I've seen 
a reference to elsewhere with:

cat .password | clog username

in .bashrc
which isn't exactly pretty... :-/

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

I don't think the logic is flawed, it just needs to be hooked from 
somewhere when the user is logging in, not afterwards.

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

Again by piping the password into clog? :-/

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

Indeed, I'm aware of all that, but I don't think Coda is unsuitable for 
doing things in a more traditional way. All it would take is for the ACLs 
to be hooked and initialised at login time, while authenticating off 
passwd/nis/kerberos.

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

I don't have a problem with bending things to fit Coda, but I am rather 
hoping there is a better way than piping the password into clog. Not to 
mention that having a unified way to change the login (local or 
centralized) and clog passwords at the same time would be useful, too.

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

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

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

This is why I would ideally like to do it off NIS or another centralized 
method.

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

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

That may not be a bad idea. :)

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

Maybe so, but that doesn't mean that seeing the right username in ls -l 
output is a bad thing. It's useful. And if it can be achieved by bolting 
someting reasonably straightforward on, then it may be good to encourage 
such a thing. I reserve the right to be completely missing the point here, 
though - as you said. :-)

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

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

Thanks.

Gordan