On Thu, Feb 10, 2005 at 06:16:10AM +0800, Alan Tam wrote:
> Two machines are on a "VPN", using unroutable IP to communicate (say 
> 10.0.0.1, 10.0.0.2). But they do own public IP, and services like apache 
> would depend on the hostname. Hence the domain coda guessed would 
> probably refer to some public IP (like 1.2.3.4, 2.3.4.5). Of course we 
> won't expect 1.2.3.4 to be able to login 2.3.4.5 via port 2432. Then 
> shan't we be able to tell coda to simply treat the machines as 10.0.0.1 
> and 10.0.0.2 regardless of their other IP addresses?

Multi-homed can't work because we only have room for a single IPv4
address per replica in the response to a volume location query, but what
you are trying to do should be possible, although it is probably a pain
to get everything right.

First of all both servers resolve all names in /vice/db/servers to
ip-addresses and use those addresses whenever it responds to the client.

I see 2 possible ways to do this, one is to use /etc/hosts to associate
the hostname with the private address instead of the public address. The
other solution would be to create unique names that are associated with
the private addresses and use those names in /vice/db/servers, but then
the server might not realize that 2.3.4.5 is in fact referring to
itself, since it uses the result of gethostbyname(gethostname()); to
figure out it's own identity. In that case you would use either
'hostname=private.addr.name' or 'ipaddress=2.3.4.5' option in
server.conf. My guess is that you would want to use the hostname=
option.

In any case, you might have to fix the init.d scripts for the coda
update daemons to make sure that the SCM runs the update server and that
the update clients on all servers actually connect to the update server
on the right (private) ip of the SCM. They connect to the server named
in /vice/db/scm. Then when the server is started, check the logs if it
actually found /vicepa, if not you need to update /vice/db/vicetab with
the correct name.

Finally if all servers are up, use 'getvolinfo' to check whether the
volume location information is correct.

    getvolinfo serverA.private.name.or.address ""

should return the replication information of the root volume as seen by
serverA. Check if the values (and especially ip addresses) make sense,
and repeat for the other servers.

Once all of this checks out, you could try to start a client and see if
it can see /coda/serverA.private.name/. If that works create an entry in
/etc/coda/realms that contains something like,

    private serverA.private.name serverB.private.name

Restart and reinitialize the client
    (killall venus; umount /coda; venus -init)

And then see if you can access /coda/private/

Jan