Hi,

Quoting Jan Harkes <jaharkes_at_cs.cmu.edu>:

> If you use replicated volumes, the clients will always talk to all
> servers in the replicated group. The only exception are file data
> fetches, in which case we use the server that has been the fastest in
> answering previous requests. If that server dies, the client
> automatically fetches the rest of the file from the other available
> replica.
> 
> Changing ip-addresses will at the moment only help to confuse the
> codasrv daemon.
> 
> Jan

What if you had a 2nd 100mbps NIC in each of the SCM and the NON-SCM, 
dedicated to CODA rep, with their own private network (say 192.168.0.1, and 
192.168.0.2) linked by a crossover cable and /etc/hosts would look like this 
in both machines:
192.168.0.1      SCM
192.168.0.2      NonSCM
and you setup Coda on both machines using those priv hostnames.
This will allow you to use your 1st nic's with real IP addresses and IMHO you 
can do lots of stuff like:
1. LVS-DR (Direct Routing) for load balancing and failover to the real servers 
(the coda servers) using 1 or more LVS Directors (Linux only for now)
2. IP-Takover, if you wanted 1 coda server to take over the other's ip if goes 
down by sharing a VirtualIP (LVS stuff) on the lo interface. The machine 
taking over an ip will watch if the other machine goes back up and change its 
IP back to the original.

Another reason why I'd rather run coda on a isolated network is because I 
still don't know how secure coda's daemon services are. 
# grep -i coda /etc/services:
codaauth2       370/udp
codasrv         2432/tcp   #codasrv
codasrv         2432/udp   #codasrv
codasrv-se      2433/tcp   #codasrv-se
codasrv-se      2433/udp   #codasrv-se

# lsof | grep UDP
auth2       277  root    3u  IPv4 0xccd5cb00        0t0     UDP *:codaauth2
rpc2portm   280  root    4u  IPv4 0xccd5ca40        0t0     UDP *:rpc2portmap
updatesrv   281  root    3u  IPv4 0xccd5cc80        0t0     UDP *:1048
updatesrv   281  root    4u  IPv4 0xccd5c980        0t0     UDP *:1049
updatecln   282  root    3u  IPv4 0xccd5cbc0        0t0     UDP *:1046
updatecln   282  root    4u  IPv4 0xccd5cd40        0t0     UDP *:1047
codasrv     314  root    5u  IPv4 0xccd5c8c0        0t0     UDP *:codasrv
codasrv     314  root    6u  IPv4 0xccd5c800        0t0     UDP *:codasrv-se
venus      8281  root    6u  IPv4 0xccd5c680        0t0     UDP *:1070

CODA of course, runs as root, so if there was a security hole in any of its 
listening daemon's, that could result in a remote root, which is not good.
So my question is, has anyone at the least audited coda's services?
Is it possible to firewall coda's ports and exclusively allow the trusted 
clients IP's?

Also, what happens if the SCM crashes?
Having setup venus on the scm like: venus-setup localhost 1000000
and on the non-scm like: venus-setup scmhostname 1000000
would that pose a problem in case of SCM crash. Can I still have read/write 
access to replicated volumes under /coda on the non-scm?
What if files changed on the non-SCM and the SCM later comes online, is the 
integration seemless or do I have to manually reintegrate the changes?

I have also setup Coda-6.0.1 on scm and nonscm (both FreeBSD-4.8), but as 
mentioned before on the list, the clients still has problems so I stuck with 
the 5.2.x from ports. My understanding is that will fix integration problems, 
but will not allow me to use the "realms" thing.
Which brings up the question, what is "realms"? is there documentation on it 
anywhere? I read something on the list about /coda/realm being the root volume 
instead of the older /coda. If so, what are the advantages over the old style?

I was able to finally create a 1GB RVM partition (and 30M Log) on both 
machines (thanks to Jan for notes on how to fit it), using the following 
options with rdsinit:
   length of data segment: 0x40000000 (1073741824)
  starting address of rvm: 0x70000000 (1879048192)
                 heap len: 0x3fefd000 (1072680960)
               static len:   0x100000 (   1048576)
                   nlists:       0x50 (        80)
               chunk size:       0x20 (        32)

On a P3 800Mhz, 256M RAM, 1.4GB SWAP, the fileserver startup time was about 
2min - 2.5mins, which I think isn't very bad. Is that Ok?

Sorry about the overwhelming amount of questions. Hope I get answers =)

Cheers,
Tim