Hello Przemyslaw,

please take my words with a grain of salt as I have just few and very
loyal users who accept downtimes and who ask for help politely
even when they suspect their files may have been lost :)

Otherwise I am very happy with Coda serving both home directories, shared
"project" areas and all user-visible programs, for a handful of Linux
workstations and a handful of everyday www/mail/openoffice users.

Cannot say much about managing backups, I have them only for disaster
recovery, otherwise the users know they have yesterday's files but
not anything more.

>  I`m planning to use CODA in an environment of between 30 to 50 client
> stations operated by non-technically oriented users (office clerks). It

> will be used primarily for home directiories and file exchange space
> located on the server.

The biggest danger would be conflicting updates on file sharing areas,
and/or same user logins to different workstations sumultaneously, while
running programs that update their [dot]files continuously.
Be sure you know the usage pattern - whether the applications can keep
common files opened for writing for a long time (run two such instances on
the same file on different clients, and you get a conflict).

> Could, please anybody elaborate on whether CODA is
> stable and hassle free enough to achieve such a setup without getting on
> users` nerves ?

There is still a bug with cache reuse that makes venus crash some time
after client cache once becomes full. If you can set up cache size bigger
than users' file areas, you will be safe.
On modern hardware it is not hard :)

As for hassle-free, I am running for years with users' homedirs on Coda,
authentication against Kerberos, and pam modules for krb5 and kerberized
Coda. No problems, as long as your users logout at least once a day.
Anyway, an additional login to the same computer (say via an alphanumeric
console) restores the tokens in case they have expired.
I have instructed xscreensaver to renew Kerberos tickets and Coda tokens
(via pam) too.
User administration is in that sence mostly administration of Kerberos
principals and Coda's pdbtool and createvol_rep.

Stability depends a lot on usage pattern (how "unusual" it is).
I think [if you know your data is saved for possible disaster recovery]
you will be able to sleep at night in peace and quiet.
Even if something goes wrong, usually nobody notices that a server is
down, unless it stays down for hours, or unless a replicated server is
down for days...
You see, Coda is wonderful! :-)

For, say, three years there were a couple of times I was near a
"disaster recovery" point because of newly discovered bugs in Coda - but
never had to do such recovery as the data was intact and the bugs got
fixed promptly (thanks Jan!).

A word of caution - big files with some programs cause "very slow"
behaviour, if a program say creates big temporary files under home
directory and keeps opening and closing them (audacity - I had to wrap it
to reduce this risk). Be prepared to wrap some (broken) programs that try
to create named pipes under home directory. Well-written programs can be
convinced to use a directory on a _local_ file system.
[pam_tmpdir is very handy to have, too.]

> Client machines will run R.H. Linux.

Should not matter which distribution it is as long as you have
 - working krb5 and kcoda pam modules
 - recent (preferably self-compiled) kernel [and of course coda module]
 - recent (-----------"------------) venus
and maintain krb5.conf and pam.d/{login,*dm,xscreensaver} properly,
these are the files you have to share with the rest of the distribution
so that some configuration tool may want to change them behind your back.

My 2c,
--
Ivan