On Tue, 2003-07-08 at 22:04, Ivan Popov wrote:
> On Tue, 8 Jul 2003, Jan Harkes wrote:
> 
> > > > > On Mon, Jul 07, 2003 at 10:45:47AM +0200, Dick Kniep wrote:
> > >     I am sorry, but i don't understand in which combination (exactly)
> > > i can use (safely) Coda with NFS.
> >
> > Well, the problem is mainly that the NFS 'layer' makes it impossible to
> > use cfs and repair and such on the NFS clients. So as long as you stick
> > to read-only operation it should be fine, but when you write anything
> > there is a chance that there will be a conflict.
> 
> I think before allowing writes to Coda via NFS one has to solve the
> problem to
> 1. give the NFS daemon suitable Coda credentials for each user
> 2. teach NFS daemon to switch identities according to user ids doing
>    write requests
> otherwise the NFS uid-bound unix permission checks will be unavailable.
> 
> That is going to be tricky, so it is hard to expect any "safe" Coda export
> over NFS. Of course if it is one and only user possibly present on all
> allowed NFS clients, it might work, but then all the things Jan wrote
> about still apply.
> 
> Readonly Coda export via NFS should be "ok", but AFAIK it would work
> _only_ with the user space daemon, and with the "reexport" flag.
> 
> Samba export of Coda might work better than NFS as the daemon needs a
> password to establish an authenticated connection and hence can get the
> corresponding tokens. We do it with DFS for the sake of some platforms and
> it works fine (over stunnel to protect the clear text passwords).
> 
> Anyway a native Coda client is better.

Yeah, but without a harddisk, it is pretty useless!

I am drawing the conclusion that under these circumstances, it is better
to go for hardware solutions? Because:

1. To use a Coda client for remote boot on a thin client without a
harddisk is hard to establish, and unreliable, because if we establish
local caching it will be on a RAM disk, which is integrated only once in
a while, and not usable in case of a crash, so we will probably loose
data (and the users will hate me for it...)

2. To use NFS from Coda gives me the following problems: We'll have the
problem to establish credentials, and we'll have other problems as well
because NFS is holding the connection, and not the actual user, which
causes a host of other problems.

3. Do accept a harddisk on the clients. In that case, we could use the
harddisk as the local cache, and the problems are solved. However, the
real reason behind the remote boot, is the fact that management of many
clients is so much easier, because the configuration is maintained
centrally on the server. But this means that we still have to solve the
remote boot problems (with an INITRD which contains Venus etc.)

So I'm drawing the conclusion that hardware RAID solutions should be the
way to go? (Remember we are trying to solve Single Point of Failures) We
should implement a number of systems with LVS, and connect a RAID
cabinet to the different systems. The reliability will be less, but I
think it is probably not feasible to get the Coda/NFS solution working
in a reliable way without a lot of programming.

Please comment!

Kind regards,
D.Kniep

> 
> My 2c,
> --
> Ivan
> 
>