How to run coda with a server/cell behind a dynamic DNS (DDNS) name and a client in the internet?

[Karl-Philipp Richter]

Hi,
I'm getting things started with coda step by step and it's advancing.
After I got my client running on the same machine as the server/cell,
I'm now trying to get a connection to the cell from a client via
internet. 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
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.

After a sucessful start of the `coda-client` `systemd` unit I see

$ ls -la /coda
insgesamt 3
dr-xr-xr-x 1 root nogroup 2048 Jul 12 23:16 .
drwxr-xr-x 1 root root 438 Jul 7 17:35 ..
lrw-r--r-- 1 root nogroup 18 Jul 12 23:17 richtercloud.de ->
#@richtercloud.de

which is very similar to the [issue I had for the client access on the
server
machine](http://www.coda.cs.cmu.edu/maillists/codalist/codalist-2016/9502.html),
but it's not resolved by starting `venus` with the `-init` flag or
running `cfs purgeml`. `cfs checkservers` returns `All servers up`. `cfs
listvol /coda` returns

$ cfs listvol /coda/
Status of volume ff000001 (4278190081) named "CodaRoot"
Volume type is Backup
Connection State is Reachable
Reintegration age: 0 sec, time 0.000 sec
Minimum quota is 0, maximum quota is unlimited
Current blocks used are 0
The partition has 0 blocks available out of 0

and `cfs listvol /coda/richtercloud.de` returns `/coda/richtercloud.de:
No such file or directory`. `codacon` prints messages in the form of

unreachable 192.168.179.1 ( 20:45:12 )
DisconnectFS ( 20:45:12 )
BeginStatusWalk [2] ( 20:45:19 )
[0, 0, 0, 0] [0] ( 20:45:19 )
EndStatusWalk [2] ( 20:45:19 )
[0, 0, 0, 0] [0, 0, 0] [1, 0, 0.0] ( 20:45:19 )
BeginDataWalk [4] ( 20:45:19 )
EndDataWalk [4] ( 20:45:19 )
[1, 0, 0.0] [0, 0, 0, 0] ( 20:45:19 )
Probe ( 20:45:42 )
BackProbe dslc-082-082-043-120.pools.arcor-ip.net ( 20:45:45 )

during `cfs listvol /coda/richtercloud.de`. I don't understand why the
192.168.0.0/16 address is contacted which seems to be a good explanation
for the connection failure.

Looking forward to great help again :)

-Kalle

[Jan Harkes]

On Wed, Jul 13, 2016 at 08:48:29PM +0200, Karl-Philipp Richter wrote:
> internet. 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
> 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.

Coda has the same problem, when a server is started it resolves it's
hostname to an IPv4 address and uses that when a client request the
volume location information.

Additionally, clients very agressively cache these IPv4 addresses so
they will keep trying to connect to the old IPv4 long after your DDNS
has been updated.

Jan

[u-x...@aetey.se]

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

[Karl-Philipp Richter]

Am 13.07.2016 um 23:06 schrieb u-x...@aetey.se:
> 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?

The server has the hostname `richtercloud.de` returned by `gethostname`
which I tested in a minimal C program. Afaik this is not a valid
hostname (because of the dot), but I hope that I can keep it because
that's the domain I rented and the only way I can talk to my server via
internet.

> 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.

Where can I find the Aetey client code? A superficial [google
search](https://www.google.de/search?client=ubuntu&channel=fs&q=Aetey+coda&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=p6WHV-XtPJTZ8AfR3K6wAg#)
yields no results.

I could now test the client I used to connect via internet in the LAN of
the cell (same subnet) and it connected without trouble just like the
client running on the server machine. If I shutdown and boot the machine
without network connection (pull the cable) I have the same behaviour of
`ls /coda/[cell]` like when I connect via internet with a running
internet connection. Does that mean that the disconnected mode doesn't
work in my case (an explicit `cfs disconnect` doesn't help)?

I realized that `coda-client` wasn't fully configured by `dpkg` for
unknown reasons before experiencing the above, but completing the
configuration didn't fix any issues. The incomplete configuration might
have caused an corrupted directories, though. I cannot evalute that.

Thanks for you extended and comprehensive support.

-Kalle

[Karl-Philipp Richter]

Am 14.07.2016 um 17:01 schrieb Karl-Philipp Richter:
>> > 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.
> Where can I find the Aetey client code? A superficial [google
> search](https://www.google.de/search?client=ubuntu&channel=fs&q=Aetey+coda&ie=utf-8&oe=utf-8&gfe_rd=cr&ei=p6WHV-XtPJTZ8AfR3K6wAg#)
> yields no results.

So, I found http://aetey.se/files/pages/CodaInstHowto.html and ran the
`.bin` installer. I'm able to see `/coda/richtercloud.de` now after
`sudo codaclient start` and `clog [user]@richtercloud.de` (which gives a
token according to `ctokens`). However listing files in the
`/coda/richtercloud.de` fails with `Input/output error`. I attached
Aetey `venus.log` in which I don't see any suspicious entries.

I verified that I'm using the Aetey binaries and deactivated the
`coda-client` `systemd` unit in order to avoid any confusing. I'm
loading the `coda` kernel module with `modprobe` after login to the
display manager before all other actions.

-Kalle

[u-x...@aetey.se]

Hello Karl-Philip,

On Fri, Jul 15, 2016 at 01:44:48PM +0200, Karl-Philipp Richter wrote:
> So, I found http://aetey.se/files/pages/CodaInstHowto.html and ran the
> `.bin` installer. I'm able to see `/coda/richtercloud.de` now after

Nice!

> `sudo codaclient start` and `clog [user]@richtercloud.de` (which gives a
> token according to `ctokens`). However listing files in the
> `/coda/richtercloud.de` fails with `Input/output error`. I attached
> Aetey `venus.log` in which I don't see any suspicious entries.

I happen to see some.

> I verified that I'm using the Aetey binaries and deactivated the
> `coda-client` `systemd` unit in order to avoid any confusing. I'm
> loading the `coda` kernel module with `modprobe` after login to the
> display manager before all other actions.

Good.

>
> [ W(13) : 0000 : 12:39:40 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:41 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:41 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:42 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:44 ] fsobj::Fetch: bytes mismatch (0, 2048)
> [ W(13) : 0000 : 12:39:48 ] fsobj::Fetch: bytes mismatch (0, 2048)

I guess this is where the trouble is seen (it looks also
like the mailer has mangled these lines into one?)

Would you describe your setup once again?

- how many computers are involved
- which one has the hostname "richtercloud.de"
- which one is running the Coda client you are testing with
- whether you followed the advice on
http://codawiki.cse.chalmers.se/Setting_up_a_server_to_work_from_behind_a_NAT.html

Note that a more or less robust test order would be:

- a separate server host
- a separate client host
- only a single server ip number involved, not across NAT
(this can be a local ip-number now, but not for the later steps)
- DNS service which delivers the server computer's ip number
when asked for what it believes to be its hostname
- both server and client start after the computers got their network
connections, server first, client afterwards
- does this work? if yes then continue:

- follow the steps from the wiki (above) to ensure service availability
from outside the apparently present NAT
- test with the client computer located outside the NAT
- does this work? if yes then continue:

- try to talk to the service from inside the NAT (still from
a separate clent computer)
- does this work? if yes then continue:

- try to talk to the server from the same computer

When all of this works you may wish to explore disconnected
operation. Otherwise there are a way too many variables at play.

How long down this sequence do you manage to come?

Note, for NAT operation you can _not_ have "richtercloud.de" resolving
to a local ip number, neither for the server, nor for the client.
This must be the ip number corresponding to your external connection. Note
also that the server must be restarted every time your external connection
gets a different ip number.

Regards,
Rune

[u-x...@aetey.se]

On Fri, Jul 15, 2016 at 03:35:32PM +0200, u-x...@aetey.se wrote:
> Note, for NAT operation you can _not_ have "richtercloud.de" resolving
> to a local ip number, neither for the server, nor for the client.

I mean: neither when it is the server who tries to resolve the name,
nor when it is the client who tries to resolve it.

Rune