On Wed, Jul 13, 2016 at 08:48:29PM +0200, Karl-Philipp Richter wrote:
> The cell is identified by it's domain name `richtercloud.de`
> which is a dynamic DNS (DDNS) address updated in a reliable time (< 2
> minutes over night when I didn't do any connection attempts so far). I
> am very sure that the issue(s) described below isn't caused DDNS name
> resolution problems.
> 
> Is it possible to use coda in the above described scenario? The ancestor

I am pretty sure it is. There are caveats though.

I guess you have at least two issues at hand, because you write

> it's not resolved by starting `venus` with the `-init` flag

There are many variables at play in your kind of setup (upstream packages
on Ubuntu, both a server and a client on the same machine behind NAT
and with a dynamic DNS for the external address).

I doubt pretty much that the corresponding setup scripts support
out of the box such kind of installation.

The server finds out its ip number by looking up the result of
gethostname() (for no good reason, but this is another story) while
the client resolves the realm name via DNS (or a "realms" file") to a
"rootserver" ip.

Do the results of these lookups correspond to each other in your setup?

> of coda OpenAFS requires a fixed IPv4 address which makes it unusable
> for non-millionaires which cannot buy some of the few addresses
> available for sale.

The upstream Coda assumes to a high degree the server addresses to be
static (like AFS). The server ip-numbers are derived on the servers and
sent to the clients, where they are being used as a server identifier.

This does not disallow their eventual invalidation and reresolution
(I think Jan added hooks for making server addresses less permanent on
the clients) but anyway this historical approach inherited from AFS
confuses addressing with identities which leads to harm.

Among others there is no support for cases where different clients would
use different addresses to the same server. Nor is this compatible with
addresses other than ipv4.

These deficiencies led Aetey to develop another (currently fully
interoperable but inherently different) method of resolving server
addresses, doing this on the clients.

So the answer to your question is - yes this is possible and should
just work. Your client will go disconnected when the server changes
the address and shortly thereafter it will reestablish the connection.
This assumes a client running Aetey code.

This should work for an upstream client too, at least if you reinitialize
it at each address change (possibly not otherwise, but you apparently
tried reinit).

Regards,
Rune