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