On Thu, 31 Jan 2008, [EMAIL PROTECTED] 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
