On Mon, 29 May 2000, Antti Andreimann wrote:

> Hi!
> 
> Im new to coda so please spare me if I ask something incredably stupid OK ;-)
> 
> I want to build a network of Linux systems that should work like this:
> * All files including system files are held in CODA cell.
> * Each box has it's own set of configuration files (/etc) stored on separate
>   coda volume, however all software (/usr, /bin(s) e.t.c) and possibly even
>   /var becomes shared among machines.
> * Each box uses about 300-500Mb of it's own harddrive for caching
> * Remaining space becomes a coda server that's part of the cell
> * Each coda volume (eg. user's home) gets replicated twice among the machines 
> * Applications on the other hand are only stored in one server that
>   also acts as the SCM.

The main particularly difficult part of this is placing anything needed
before venus starts in the boot sequence in coda. eg : /etc, /bin, /sbin

> 
> If any1 is still reading I would like to know the following:
> * Is there a way to mount a coda volume somewhere else than under /coda on 
>   client? Yes I know I can use symlinks to link /etc to something like 
>   /coda/etcs/spooky but I don't want to do it. Linux has a very nice feature
>   that there may be existing files in a mount point. So I could install
>   coda client configuration and other nesseseary boot files on the local root
>   partition and when system boots they get replaced on fly. Of course I
>   can create some scripts that mangle with symlinks during system boot,
>   but I don't like this idea.

This would be somewhat difficult at present; both venus & the kernel
module have /coda hardcoded in them. Also, we can only have one coda
"device" mounted in one place, and need a venus per each device, which the
kernel module doesn't allow right now. Fixing both of these is an eventual
goal. 

> * How can I make sure that in the case of sotware upgrade or installation
>   configuration files in every box's /etc get updated/created? Should I teach
>   RPM some coda stuff or is there a way to do that with some coda magic,
>   custom conflict resolvers?

You could keep one base /etc tree that would be modified by rpm when
upgrading. Then you could run a script that merged the differences into
the each machine's individual /etc. Sort of the same effect as doing a cvs
commit of the new base /etc & a cvs update in each of the individual
/etc's, which would be another way of doing it, though diff & patch would
probably do as well. 
 

> * How difficult it is to integrate coda with RPM in such a way that every
>   file marked as %config in RPM database gets coda's special attention and
>   is automatically managed individually for each client.

Besides being fairly painful, this violates the principle of filesystems
storing blobs of binary data without regard to their content. On the other
hand, Coda used to support the AFS feature of /afs/@sys being a
symlink to /afs/bin/arch-machine-os, but that may or may not have had a
pressing reason. Leaving the package management up to the package
manager by getting RPM to understand the case of a config file on
shared filesystems would probably be cleaner, and work for people using
NFS, etc. 

> * Is there a root filesystem on CODA patch/initiative?

This has been tried a couple of times in the past, I forget exactly how
far it got. The basic approach was to have a local root with a kernel &
bare minimum /etc & /bin, then do a chroot or mount a loopback fs from
within /coda, or something more complex. 

Shafeeq