running an additional discovery server

Hello everyone,

so, I was thinking I could speed up my different devices finding each other after restarting syncthing, if I run my own discovery sever.

But, can I run and configure a discovery server on the same system that runs syncthing, and can I make use of the normal discovery servers, too?

Thanks, Heinrich

Running a discovery server pretty much will yield nothing. Public discovery servers already do what they are supposed to.

Furthermore, it’s not possible to run a discovery server on the same machine, or for matter of fact even in the same LAN, as it will not function the way it’s supposed to (discover wrong IPs for the syncthing instance).

Tried running own discovery server on same network as Syncthing instance. If do so the local machine will send a LAN IP to the discovery server so in order to run one’s own effective discovery servers one will need to run it on a separate network than any of one’s own Syncthing instances.

Well I have a dedicated server on the internet, not in any LAN with the other syncthing units. However, it is running a syncthing instance.

I also read in an older tutorial, that stated, that I would have to move the discovery server to other ports, so it wouldn’t interfere with the syncthing app.

However, I couldn’t even find an up-to-date version of the discovery-server-software or a tutorial to work with, that was recent.

1 Like

The documentation article is fully up to date and links to the latest release. In fact, at the moment it’s so up to date it’s ahead of the released software (since a couple of days). But if you ignore the part about replication which is not yet released, it’s all good.

That said, the only time you need to run a discovery server is if you need global-ish discovery inside your own LAN/WAN/VPN setup, or if you strongly distrust the global infrastructure we provide - and in the latter case there is a lot more you need to disable as well.

1 Like

Download from here: https://github.com/syncthing/discosrv/releases

Open the necessary ports (think it is 8443 by default)

Run the below script:

#!/bin/bash
nohup \
/home/user/stdiscosrv/stdiscosrv \
> /dev/null 2>&1&

Could be better if run with dedicated user but above will work. Can also just run this command manually:

nohup /home/user/stdiscosrv/stdiscosrv > /dev/null 2>&1&

You probably don’t want to throw away all log messages, particular for someone who’s trying to set it up for the first time…

Great point and completely agree @canton7

Try running the below manually before discarding the output once get comfortable:

/home/user/stdiscosrv/stdiscosrv

One also will need to run at least once manually to see the device ID (or just look in the config files). Assuming that are not using custom SSL certificates will need to add the device ID of the discovery server to the discovery server address like this (documentation explains this very well):

https://disco.example.com:8443/?id=7DDRT7J-UICR4PM-PBIZYL3-MZOJ7X7-EX56JP6-IK6HHMW-S7EK32W-G3EUPQA

Thanks for all the help.

Currently I have the server running, and seemingly using the Let’s Encrypt Certs I want it to use.

However, the syncthing instance on the same machine can’t connect do to a bead cert (possibly because it is using the same certs). Syncthing on another system can’t connect due to a “404” HTTP error.

404 from the discovery server is also the expected response when asking for a device that hasn’t announced itself

So, what would I do to fix that ?

Fix the other problem.

You think the problem that the syncthing instance on the same machine can’t connect to the discoveryserver is related to the problem that another system can’t connect ?

How so?

If I call the discoservers port (i changed it, so it has no conflict with the instance of syncthing running on the same system) with firefox I also get the 404, but the certificate seems correct.

The syncthing instance on the same server uses it’s own certs, but has separate https-certs from Let’s encrypt, so it will work with the apache installation in the system. Apparently I can’t use the web server certs as syncthing certs, because they aren’t made for that service.

No, I’m saying 404 is a valid response and not an indication that it can’t connect. But you have Apache and certificate issues and I’d start with those.

So, syncthing on the same system thinks that the discovery server certificate (which is from Let’s encrypt) is a bad certificate. Error reads: x509: certificate signed by unknown authority

I added the let’s encrypt intermediate certificates to the ca pool, but that didn’t change the fact…

You can use openssl to verify it. Syncthing uses OS pki AFAIK.

1 Like

Apparently restarting syncthing via GUI didn’t make the process add the new ca entries, but killing the process and restarting it did.

Now the discovery server doesn’t throw “http: TLS handshake error” anymore and the syncthing on the machine that has the discovery server shows the same 404 error the other system does, too.

I’m not quite sure how to fix that. I assume the discovery server should answer to the specific port it listens to (via the listen= parameter). So it should answer with whatever it is supposed to answer, right ?

I’m not sure what you mean by the port, but try to run it with -debug and see what it says.

Well, even with -debug the discoveryserver only gives occasional lines:

Stats: 0.00 announces/s, 0.00 queries/s, 0.00 answers/s, 0.00 errors/s
Stats: 0.00 announces/s, 0.00 queries/s, 0.00 answers/s, 0.00 errors/s
Database: 0 devices, 0 addresses

The error on the clients’ sides hasn’t changed. I would assume that they star some dialog, the discovery server server adding the clients to its database and telling them about each other. But for now, I’m stuck with the 404 error.

I changed the tcp/ip port, with the listen= parameter to 8401, because the default 8443 is used by the syncthing instance on the same machine, so the discovery server can’t use it, too. I made sure, however, that I called the discovery server with this port in the syncthing settings: default, https://example.org:8401/

Try https://example.org:8401/v2/