On Tue October 18 2005 15:10, Jan Harkes wrote:
> On Mon, Oct 17, 2005 at 09:51:20PM -0500, Jerry Amundson wrote:
> > OK. I thought the whole point was that the client wouldn't *need*
> > to talk to one server, or any for that matter. Hence, "disconnected
> > operation". Having "everything die" is not what I'm looking for
> > here...
>
> Well, you do need to somehow connect to the replicated group at least
> once. From the startup log messages it was clear that your client was
> starting from scratch and had never talked to the servers before.
>
> So it didn't have any information cached about what the name of the
> root volume was. Also, the servers are pretty dumb and although they
> can resolve some types of conflicts, they have to be told where the
> conflict is in the first place by a client. This can only happen when
> a client can see all servers at the same time.

Is it sufficient for the client, upon starting for the first time, to 
see one server? Or must it see all servers? Or a quorum, i.e. 2 of 3, 
3 of 4, etc.?

Also, I assume the above holds true for servers found either via DNS 
or /etc/coda/realms?

> > I've re-initialized everything and put /etc/hosts the way it was
> > (the server as localhost). As expected, startserver fails, killing
> > vice-setup. That's
>
> Ehh, I just said in my previous email that having the server resolve
> to the localhost address is wrong. So why do you put it back to the
> way it was.

Because this section of server.conf gives me the impression it can work:
#
# When a server is confused about it's identity the server will complain.
# (i.e. gethostbyname(hostname()) == 127.x.x.x). Use this option to force
# the ip-address through which clients will be able to reach this machine.
#
# The actual cause seems to be a very common setup when the machine has no
# default interfaces configured and /etc/hosts contains a line similar to
# 127.0.0.1 (or .2)     myhostname.mydomain
#
# Removing that line from /etc/hosts also solves the problem.
#
#ipaddress=10.1.110.5


> > [root_at_aspen vice]# getvolinfo docs aspen
> > RPC2 connection to docs:2432 failed with RPC2_NOBINDING (F).
>
> Swapped args, I see in your follow up email that you already figured
> that one out.
>
> > Ugh. Sorry for the rambling. I just don't see why the "ipaddress"
> > setting is described in server.conf, as I get the impression Coda
> > servers just won't work with the server as 127.0.0.1 in /etc/hosts?
> > Yes, perhaps RedHat is brain-damaged for defaulting it that way,
> > but it's what I have to work with...
>
> Well, I think that in a way Redhat is slightly braindamaged for
> defaulting that way, but the real problem is that on a very low
> level, Coda is doing something wrong.

I'll go back to the setup I had working - I was just looking for a more
"out-of-the-box" approach...

> We are passing volume location information around based on the IPv4
> address of the server, and are doing the name->address mapping by
> resolving on the server. Now 127.0.0.1 is a perfectly fine address to
> use to contact the Coda-server if you happen to be on the same
> machine. But a client is typically not on the same machine and
> 127.0.0.1 is useless/misleading information in that case.
>
> To really fix the problem, the volume location information should be
> passed to the client in the form of the unresolved fqdn hostname of
> the server. The client can then resolve that to (the list of) valid
> address(es) for that server. If the client happens to run on the same
> machine, it can just as well use 127.0.0.1, if it is on the private
> network it might use 192.168.x.x, and remotely it may use the real
> public ip-address, or even several fallback addresses when we're
> talking to multi-homed hosts.
>
> But changing that in the code isn't totally straightforward. Right
> now the RPC2 GetVolumeInfo request doesn't have the space to store
> the fqdn names, the client internally indexes servers based on a
> single 32-bit value which is assumed to be the ipv4 address, etc. And
> we'd have to deal with things like timing out stale DNS data, or
> re-resolving when we move from one network to another. So the simple
> change right now is to make sure that the server hostname maps to a
> single public ip-address where the server can be reached.

So for client access from public networks:

1. Is it secure in current versions, to some extent? (sorry, didn't
this much beyond the "Coda security" postscript doc...)

2. For a client, e.g. laptop, to reach servers from private and public
the server names need to resolve to public IP's, even within the private
network, right? 

Great info, as always. Thanks!!

jerry