(Illustration by Gaich Muramatsu)
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. GordanReceived on 2008-01-31 08:37:31