can't seem to get the client connected

[vtacquet]

client was activated, server shows no errors, it is running on the same docker server in the same compose file, it does not work with "unison_server" as servername, so I tried with the ip address but it has the same error, client starts and immediately exits error 255

http/api and ssh ports are working (see the telnet commands for that), I restarted the server to test that too.

any idea ?

[agarbato]

Hi there,

Are you testing ports from the container or from your host? Ports should be reached from the client for SSH to work, so it really depends on how you expose ports on docker-compose and the docker network you're using.

If you can share your docker-compose it's easier to help.

If you check example here server and client are on the same docker network so client can resolve server hostname using an alias.

    networks:
      unison:
        aliases:
          - unicloud_server

for SSH port if you are on the same network (like in the compose example) you can use internal port SERVER_PORT=22, if you are on another machine you need to use exposed port.

If you clone the repo and run docker-compose up -d everything should works just fine. I tested several times on different platforms :-) If you use the docker-compose on the root of the repo you'll find a local_test folder with all the files generated by the app, one for server and another for the client.

Just to clarify what's the registration process.

When you register a client, its ssh public key is added to server authorized key. You should have on server data volume a file like this.

local_tests/server/.ssh/unicloud_authorized_keys

Check if the client pub key is there but it should be if you completed the registration process. Please share your docker-compose, I'll be happy to have a look.

Start with the docker-compose example provided, if you want to start fresh just cleaning all possible leftover files enter local_test folder and run cleanup.sh script.

Hope this was useful. Thanks A.

[vtacquet]

Hi,

The only difference with my compose files is that I am using macvlan for networking, so I don't need to define any ports, both containers have their own ip. I can confirm that the public key from the client is in the authorized file on the server, I can also confirm that when I replace the entrypoint for the client with "tail -f /dev/null" and when I enter the container via bash, I can ping the server on its hostname, I can also telnet on the server ports 22 and 80, so networking everything is ok. Some evidence in attach, still the unison_client doesn't want to connect. I attached the compose file too.

I started clean for the third time, on 3 different servers already (first try was without macvlan and where server and client were on different hosts in different regional zones - client in US and server in Europe)

Thanks V

[agarbato]

Thanks for sharing compose and other evidence. Everything from network perspective seems just fine.

When client start checks ssh connection, if not able to connect will exit. It's possible that when the client start, the server (or at least port 22) is still not up. This is why I added this on code example that is not on your compose file.

restart: on-failure

this will make a loop restart until server ssh port is ready. In your case it will just fail once without restarting. Can you try to add it? I tried also depends_on but for local testing restart seems more efficient.

You can comment also UNISON_PARAMS env from the client, it's a leftover (my bad) for a test with a windows machine to change ssh algorithm but unless you are on windows you don't really need it.

If you can enter client container with ssh this is what the client does to initiate sync (make sure server is up and running).

unison unicloud

Sync works through ssh, if you run the command above and it works, there should be no reasons for the ssh connection to fail, unless the client is testing the connection while server is not yet ready.

A

[vtacquet]

I removed the PARAMS (I am running the containers on Ubuntu 20.04) and restarted the client, same issue. Server is still running (couple of days) so it can't be that the SSH is not up yet. I changed the container to start a shell and did the "unison unicloud" but that does not work, there is no prf file

[agarbato]

Client Profile is on unison user $HOME

Should be /data/.unison/unicloud.prf

Run the same command as unison user.

[agarbato]

I did some other tests with ubuntu 20.04 and everything seems fine with the docker-compose.yml in the repo.

Something is broken server side, maybe ssh port is up but it's in a loop restart.

You can check ssh status on server using supervisor (as root)

supervisorctl status

still on server container check also /data/logs/supervisor* for possible errors.

I can't think of anything else that could explain the error.

Test fresh with the default docker-compose.

[vtacquet]

The server is fine

I really think the client is the issue, there are no files in /data/.unison

[agarbato]

You should have unicloud.prf inside /data/.unison folder. Unison profile is generated during client startup process so if you changed the docker entrypoint it's normal you don't have it.

Something like this.

root=ssh://unison@unicloud_server:22//shares/share1

root=/data/share
clientHostName=testing-client1
batch = true
auto = true
prefer = newer
log = false
#place additional params with UNISON_PARAMS env
ignore = Name .git*
ignore = Name .idea
ignore = Name .unison
ignore = Name .DS_Store

You might try to register the client again. Stop the client container, delete it from client management page /clients/mgt Remove client data folder (in your case seems /opt/docker/unison/client/data) make sure you delete all hidden files as well. Remove custom docker entrypoint and try registration process again.

[vtacquet]

I tried everything, I abandoned my macvlan config, just copied your entire compose file, just the same error, I even changed the my compose version from 3.5 to 3.3 too.

Since the client restarts in 10ms it probably does not create the .prf file, in the bind mount outside the container, the .unison folder is empty (see last screenshot)

[agarbato]

Thanks for your patience :-)

I'm really trying to replicate the issue but I really can't. I'm testing with ubuntu 20.04 and on my macos but always the same behavior. I register the client, I create the share and after a couple of restarts the client start the sync normally.

The other thing that comes to my mind could be related to permissions reading ssh pvt key when testing connection. Is default userid 1000 a valid user on your machine?

On startup process unison profile is created after successfully tested the ssh connection, that's the reason why you don't have it.

code

That's the command the client run to test ssh connecton.

[vtacquet]

yes user with 1000 exists on my host, but this has nothing to do with the permissions on the filesystem within the container, I don't see why that should matter, it's just a number in the container

[agarbato]

If client ssh key has wrong permission ssh auth won't work.

If you want to enable ssh logs (server side) check this comment on a previous issue:

https://github.com/agarbato/unicloud/issues/16#issuecomment-1024980007

At least you'll know if the client can reach the server and connection is refused server side.

Meanwhile I'll keep trying to replicate on a fresh ubuntu server and add some debug logs when ssh connection is not working.

Sorry it's not working for you.

[agarbato]

I just pushed a new image with ssh connection test debug enabled.

Pull the new image with docker-compose pull.

When connection is not working you should see on compose logs something like this:

test_unicloud_client_1  | SSH Connection KO, exit code 255, output unison@unicloud_server: Permission denied (publickey,password,keyboard-interactive).

[agarbato]

Pushed another image update with server ssh debug log enabled when SERVER_DEBUG=True (like in compose example).

On server /data/log/sshd.log you'll find ssh connection logs.

[vtacquet]

server

client before activate

client after activate

server log and ssh info

[vtacquet]

# more sshd.log

Server listening on 0.0.0.0 port 22.
Server listening on :: port 22.
Connection from 172.21.0.3 port 43394 on 172.21.0.2 port 22 rdomain ""
Failed publickey for unison from 172.21.0.3 port 43394 ssh2: RSA SHA256:1jE/Av9SUtGF7EAcxB0UqjpBxNqHvCzI/7fk/iZkCDM
Connection closed by authenticating user unison 172.21.0.3 port 43394 [preauth]
Connection from 172.21.0.3 port 43402 on 172.21.0.2 port 22 rdomain ""
Failed publickey for unison from 172.21.0.3 port 43402 ssh2: RSA SHA256:1jE/Av9SUtGF7EAcxB0UqjpBxNqHvCzI/7fk/iZkCDM
Failed none for unison from 172.21.0.3 port 43402 ssh2
Failed password for unison from 172.21.0.3 port 43402 ssh2
Failed password for unison from 172.21.0.3 port 43402 ssh2
Connection closed by authenticating user unison 172.21.0.3 port 43402 [preauth]

[vtacquet]

Connection from 172.21.0.3 port 43448 on 172.21.0.2 port 22 rdomain ""
Authentication refused: bad ownership or modes for directory /data
Failed publickey for unison from 172.21.0.3 port 43448 ssh2: RSA SHA256:1jE/Av9SUtGF7EAcxB0UqjpBxNqHvCzI/7fk/iZkCDM
Connection closed by authenticating user unison 172.21.0.3 port 43448 [preauth]

thanks for helping, but I have lost too much time with this, it surely has something to do with file/directory permissions, but this should be handled by the containers when starting up, and not by me constantly changing permissions just to get it started, will look into something else.

[agarbato]

It's definitely a permission issue. It's well written in bold on README.md and I tried to point you in the right direction. Thanks for testing anyway, all feedback are well appreciated. The best I can do is check permission on startup and exit with a clear message. SSH must have proper permission to work.