Hi,
Quoting Jan Harkes <[EMAIL PROTECTED]>:
> 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
