Hi Yves,

nice to hear from you again.

On Thu, Jul 03, 2008 at 05:06:04PM -0600, Yves Dorfsman wrote:
> >You just have to be prepared to the client going disconnected
> >once in a while and as the result also having somewhat higher probability
> >of creating/encountering conflicts.
> 
> So is this the only risk of doing client operations on a server ? If I 
> understand you well, the risk is that once in a while I'll be working in 
> disconnected mode, which in itself is not a huge problem since everything 
> will right itself up once the connection establish itself again, right ?

If updating in the disconnected mode you have a corresponding window
for possible parallel updates => conflicts.
Random disconnections may also exercise corner cases in the code and
as such trigger obscure bugs more readily.

> I just need to make sure I "hoard" everything, right ?

Possibly, but I do not use hoarding myself so am not qualified
to give an advice here.

In any case the experience depends a lot on your usage pattern.
You may be quite happy (I am. Hardly can imagine a satisfying
digital side of life without Coda),
or you may be very frustrated if e.g. your key application happens
to crash because of "connection timed out" in disconnected mode
or because of any other Coda-specific glitch.

> >As soon as your 6 users learn how to clog you may just skip any adjustments
> >on the clients. Think, no more tweaks in fstab!
> 
> I never use tweaks in fstab, just use automount with NFS.

Ok, then - no more automount setup! :)
No maintenance of NIS or LDAP or files for automounter maps.

> Ok, assuming client operations on the server are not as bad as I thought, 
> and that I am able to quickly put a script to copy my UNIX auth into the 
> CODA database + hack a pam script to automagically login, I'll give it 
> another try.

Have you got your user's login passwords in clear text?
Otherwise you can not teach Coda to use them.

Anyway, there are many ways to deploy Coda as the main distributed file
service. Clearly, you will never have the same functionality as with NFS,
but that's not the goal.

You will get a lot of additional possibilities you never had with NFS
and also a set of "impossibilities" like putting DVD-images there.

Be cautious, you are not yet in a position to clearly distinguish between
what is feasible and what isn't, concerning compatibility between NFS and Coda.

So it will be most productive if you do not try to "fix" all the issues,
as the time goes you will have a better view of which ones are important,
which ones are easy to fix and which ones are to live with.

Coda does not need client computer administration.
If you nevertheless insist on doing this, or if you have to administrate
the client computers for some other reasons, then you lose a big deal
of the advantages.

(in fact, you can use Coda _for_ computer administration,
for Linux workstations at Chalmers we distribute all Unix-account information
over Coda:
 - the uid/name mapping (going to /etc/passwd)
 - the gid/name mapping (going to /etc/group)
 - the authorization information (allowed users list used by pam_listfile)
We could even distribute authentication info (the hashes for /etc/shadow)
the same way, thanks to Coda protection, but there is a Kerberos realm
in place and we use Kerberos for autentication purposes.

Oh well, we have to support NFS as well, so Coda is used to deliver
automounter maps, too :)

Note that "computers as consumers of data from Coda" is not trivial, Coda
does not trust ip numbers like NFS (thank goodness), so you have to give
each computer a unique identity and a secret password, or let them fetch
Coda tokens via the anonymousssl service present in the modular clog.

Coda for human users is straightforward, as soon as they know how to clog.
Unfortunately, conflict repairs still may need expert help.

Regards,
Rune