So I’m building a VPS with the relay and discovery servers both running on it locally. Now I want to install the syncthing client along side them. What I’m trying to do is find a way to secure the “client” by default. I don’t want a default shared folder at all. I can set the user/pass and TLS boolean no problem. Is the best way to go about this to setup the skeleton of a config.xml and start from there? Or should I use the REST API to do the configuration? Or is there some sort of manual config through the web GUI that HAS to be done?
I’m trying to make the end result reproducible since it’s an IaC type deployment with Terraform and Ansible.
Have a look at the syncthing generate CLI sub-command. It’s intended for exactly this purpose, including --no-default-folder. Feel free to ask if any details are unclear, otherwise have fun at Syncthing — Syncthing documentation
After using that, I usually script the syncthing config CLI afterwards to enable TLS and such, add custom discovery servers, etc.
Note that discovery announcements won’t make sense and will be unusable when connecting from the same machine, as the ip discovery will see it as loopback address.
Yes, but if A runs on the same machine as discovery server, addresses B get for A will make no sense, in which case you can only get B to connect to A.
That has no meaning, as that is “what address do I think I have”, and what we really want is “what address did this device connected from”, to account for NATs, firewalls etc.
So pragmatically speaking, don’t run a discovery server on something also functioning as a sync “client”? Is there any issue running relay/disco on the same server?
I can’t confirm this, at least on Linux. I also run a discovery server and a syncthing client on the same machine and the discovery server does see the correct IP.
If I have a machine with IP address 1.2.3.4, I can do local communication with either:
127.0.0.0/8, which is independent of any other machine IP
1.2.3.4, which the host also routes to itself, as long as it’s an IP address from one of its interfaces.
Since my DNS resolves to 1.2.3.4*, the discovery server sees the local client as connecting from 1.2.3.4, just as any external client would. There is no localhost address involved at any time. This also works with IPv6 as well.
(The packet-reflection via network interfaces may not be as optimized as going through loopback, but that doesn’t matter in this case)
*I use different FQDNs for IPv4-discovery and IPv6-discovery, both are different from the machine’s hostname, but resolve to one of its public IPs.
I guess this all depends on routing rules, and I guess might end up being configurable somewhere in the kernel. I guess I would not be surprised if the routing for an ip that the kernel thinks it owns on its own adapter got short circuited to not go out to the actual network.
I am saying what I am saying because people complained before that this didn’t work, hence I am just echoing what they said before, but perhaps the setup involved docker or something like that that made things worse.
I will be working on it late this week and will report back how it behaves. If I need to spin up another VPS it’s no big deal but I’ll post the configuration on here with the behavior I’m seeing from it when I’m done.
I’m trying to restrict the administrative access to local only so I’m hoping I can still use this (/var/run/st.sock) GUI address for the local socket connection and REST API… can anyone confirm? I read the CLI client is obsolete elsewhere in the forum
