On Sat, Sep 11, 1999 at 01:54:56PM -0400, squeegy_at_squeegy.org wrote:
> I do have some other questions:
> 
> In AFS, every cell is under the /afs.  Does coda do the same thing?
> If I install the server on a nother pc,  and build another volume,
> will both show up under /coda?  or do I have to do something on the
> SCM to make that happen?  Can I change which machine is SCM?  And if I
> can, how? 

Coda currently has no support for importing other administrative cells
into it's local namespace. (aka. mounting volumes from some other Coda
installation into your own tree).

However, it does support multiple servers within one administrative
cell. And volumes can be replicated across several servers.

To go from a single server Coda setup to a multiple server Coda setup is
relatively painless if you follow the following steps. Maybe this is
even documented in the Coda-HOWTO, if it isn't it probably needs to be
added.

- On the SCM, add to /vice/db/servers the name of the new server, with a
  new unique server-id (in the range 1-126 or 128-254, the reason why is
  one of the few things in the FAQ on the Web).

e.g. /vice/db/servers
    1 SCM
    2 NewServer

- Also on the SCM add new volume-server-groups to /vice/db/VSGDB.
  This defines which servers are responsible for storing volume
  replicas. A volume can at most be replicated across 8 servers, it is
  theoretically possible to resize/shrink VSG's, but nobody has
  succesfully done so.

  The numbers are interpreted as hexadecimal, and seem to have once been
  used as multicast IP-addresses, that's why they start with E0 == 224
  == multicast ip. Multicast support is present in rpc2, but unlikely to
  work.

e.g. /vice/db/VSGDB
    E0000100 SCM
    E0000101 NewServer
    E0000102 SCM NewServer

- Install your second server, and at the question "Is this the master
  server, aka the SCM machine? (y/n)", answer `n'. And finish the setup
  by giving the hostname of the SCM, and configuring RVM.

- Start the update client on the new server, on a redhat installation
  this is done by:
    /etc/rc.d/init.d/update.init start

- Check whether the files in /vice/db are updated. Otherwise restart the
  updatesrv on the SCM (/etc/rc.d/init.d/update.init stop; ... start).
  When the prot_users.db etc. files have appeared, everything should
  be ready to start the auth2 daemon and the codasrv on the new server.

Creating volumes is still done on the SCM, but you should pass another
VSG identifier to the createvol_rep script.

e.g.
    createvol_rep replicated E0000102 /vicepa
    # creates a replicated volume on both SCM and NewServer, according
    # to the VSGDB show earlier.

If you want to move the SCM, put the hostname of the new SCM in
/vice/db/scm, and after this file has propagated, stop updateclnt,
updatesrv and the auth2 daemon on all machines. Then simply restart all
updateclnt, updatesrv and the auth2 daemons. Maybe check if /vice/db/scm
is correct before actually restarting them.

The codasrv itself doesn't care whether it is an SCM or not, the other
daemons have to know it because of the simple replication technique of
copying the files in /vice/db from the SCM to the other servers.

Jan