anyproto / any-sync-dockercompose

docker-compose for testing any-sync
MIT License
234 stars 29 forks source link

The client cannot sync after changing EXTERNAL_LISTEN_HOSTS #45

Closed ms-xie closed 4 weeks ago

ms-xie commented 2 months ago

Have you read a contributing guide?

Current Behavior

After changing the EXTERNAL_LISTEN_HOSTS in .env.override and restart the docker compose, the client (which is login before) cannot sync and stuck on “preparing”. re-logout / login not help.

My current workaround: delete all folder in data Directory and re-sync all data.

Expected Behavior

The client can sync after upload new client.yml and without fetch all data again.

Steps To Reproduce

  1. edit EXTERNAL_LISTEN_HOSTS in .env.override
  2. restart the docker compose make restart
  3. export the new client.yml
  4. upload new client.yml in client
  5. enter the key
  6. the client (which is login before) cannot sync and stuck on “preparing”

Environment

- OS: Docker-in-Docker-DinD v26.0.0 under unRaid 6.9.2
- Version: v4.0.2

Anything else?

No response

fb929 commented 2 months ago

can't reproduce

cat .env.override
EXTERNAL_LISTEN_HOSTS="127.0.0.2"
Screenshot 2024-05-04 at 15 48 20

cat you show me your configuration client file? path "./etc/client.yml"

ms-xie commented 2 months ago

The port 100.100.182.62 is tailscale assign (another container in this Docker-in-Docker-DinD)

Also notice that I do not quote the ip, like this: EXTERNAL_LISTEN_HOSTS=100.100.182.62

Could the problem be here?

etc/client.yml

id: 6631310efe1cab0019a5343e
networkId: N4GKRjMCc9Gs7AodExgyZE4SfhVAZyWrcZtVqw5eL3FKdpkd
nodes:
  - addresses:
      - any-sync-node-1:1001
      - quic://any-sync-node-1:1011
      - 100.100.182.62:1001
      - quic://100.100.182.62:1011
    peerId: 12D3KooWDJaL77GcLtskmE3L4spiqbk4SjPqzK91s32UuBqekNDw
    types:
      - tree
  - addresses:
      - any-sync-node-2:1002
      - quic://any-sync-node-2:1012
      - 100.100.182.62:1002
      - quic://100.100.182.62:1012
    peerId: 12D3KooWDgKEe3SJt5EzhhCcY4VWSnE81LuzVRNnhPdPvqknRUcZ
    types:
      - tree
  - addresses:
      - any-sync-node-3:1003
      - quic://any-sync-node-3:1013
      - 100.100.182.62:1003
      - quic://100.100.182.62:1013
    peerId: 12D3KooWMHqUAdqMeRiKrjNvyE2dVvzzYUsn4SYXzcjnruN8QVrz
    types:
      - tree
  - addresses:
      - any-sync-coordinator:1004
      - quic://any-sync-coordinator:1014
      - 100.100.182.62:1004
      - quic://100.100.182.62:1014
    peerId: 12D3KooWHofxyQLSR3KMbR7oZGigyrCxHvyRHiRCBC3cuTumDRTQ
    types:
      - coordinator
  - addresses:
      - any-sync-filenode:1005
      - quic://any-sync-filenode:1015
      - 100.100.182.62:1005
      - quic://100.100.182.62:1015
    peerId: 12D3KooWRo4eBuzwqhYE59GvSsjt61HYVFHrNiuGTW6vuTPzq48G
    types:
      - file
  - addresses:
      - any-sync-consensusnode:1006
      - quic://any-sync-consensusnode:1016
      - 100.100.182.62:1006
      - quic://100.100.182.62:1016
    peerId: 12D3KooWCXq9NPu6wTHegg5oW7VXqtpqk63w5q3obyqgrotyZXEz
    types:
      - consensus
fb929 commented 2 months ago

Are you sure that the IP address 100.100.182.62 is accessible to the client? Could you please check the port availability using the command:

telnet 100.100.182.62 1001
JirR02 commented 1 month ago

Hey @fb929,

I have the same issue just with another ip adress. I tried telnet myip 1001 with the following output.

telnet myip 1001
Trying myip...
Connected to rockpi-4bplus.tail2e082.ts.net.
Escape character is '^]'.
Connection closed by foreign host.

Hope this helps further :-)

Maybe it's a problem using tailscale at the first place since it depends on the fact that every single client has to be connected to the tailscale client.

fb929 commented 1 month ago

We haven't tested the product for compatibility with Tailscale. First of all, you need to check the availability of all any-sync-* daemons. Take the list of nodes.addresses from the file etc/client.yml and check your external IP addresses/ports using Telnet. Secondly, try different clients. Android or iOS may have issues with synchronization over VPN, but the desktop client definitely supports synchronization in a VPN network.

JirR02 commented 1 month ago

Is it normal that there are IP adresses assigned to the containers. Isn't this a problem since the containers cannot be reached if the IP adress does not correspond to the IP Adress of the VPN Network?

image

fb929 commented 1 month ago

For this, we use port forwarding. The "Docker Host" system, needs to be in a network that is accessible to the clients. And IP address "Docker Host" in this network should be added to EXTERNAL_LISTEN_HOSTS.

JirR02 commented 1 month ago

Ah I see the problem. Maybe... Is it correct that the EXTERNAL_LISTEN_HOST does not correspond to the ip address were the docker instance is running but rather the ip of the client which is trying to sync with the host running the docker instance? Or do I need to add both the ip addresses of the the host running the docker instance and the client trying to sync to the .env.override file? It is kind of weirdly formulated in the wiki.

fb929 commented 1 month ago

EXTERNAL_LISTEN_HOST (and EXTERNAL_LISTEN_HOSTS) can be either a hostname or an IP address. Your clients (desktop, android, ios) will resolve this host to an IP and will attempt to connect with the self-hosted any-sync-* daemons. In a simple situation, this IP address is present on the docker-host. And the scheme in this case is as follows: client -> EXTERNAL_LISTEN_HOST -> internal docker network -> any-sync-XXX container.

In more complex cases, such as when using a network load balancer or DNAT, this IP may not be present on the docker-host system. However, in any case, you must ensure that the client can establish a connection to EXTERNAL_LISTEN_HOST:PORT and that it reaches the appropriate any-sync-* daemon.

JirR02 commented 4 weeks ago

Update: I think I found the problem. So i have a quite old ARM chip running on my server and it does not support the newest mongodb docker version. I think there is a problem with that because when I run it on my mac which runs the newest versions of the docker clients it works even with the ip adress so yeah. I guess I have to find an alternative. Thanks for the help though @fb929