Node ID generation

Edit: Ok, so this was not actually an issue with syncthing but a typical EBCAK. In case anyone is interested: The approach of setting up syncthing as described below works, but if you leave your browser open between quitting and restarting syncthing, you want to reload the page every now and then. The page displays an error once synchting is gone and that error disappears as soon as synchting is back, so I never thought of hitting F5…

Original post below:


How does a node know what his own node-id is?

Some background information: We want to setup syncthing on 5 machines. Ideally, an installer program will take care of everything, including syncthing setup.

So the idea is to generate 5 key/certificate pairs and 5 configs and than have the installer copy the files to the right places.

In order to test whether or not this is possible, We have set up syncthing on two machines and then tried to swap their key/cert. pairs, adjusting the configs accordingly. The result is that afterwards the nodes can’t connect to each other anymore. Whats especcialy strange is that on startup, syncthing reports the original node id on each machine, but in the web-gui it displays the new one.

To better illustrate:

Original setup (everything works fine)

Machine 1: Id posted by syncthing on startup in terminal: A Id displayed in web gui: A

Machine 2: Id posted by syncthing on startup in terminal: B Id displayed in web gui: B

Altered setup

Machine 1: Id posted by syncthing on startup in terminal: A Id displayed in web gui: B

Machine 2: Id posted by syncthing on startup in terminal: B Id displayed in web gui: A

When we let syncthing generate a new key/cert pair, it also generates a new node id for itself. So we thought that it

1 Like

Yeah, so syncthing automatically reloads some things, such as node and repository status continously, but not the config. The original thinking was that the config is changed through the GUI, so the GUI knows it has changed anyway. Obviously, after a restart or being down it should reload everything because things might have changed “behind the back” of the web GUI. I’ll get that fixed.

@Flo could you go into more detail on how you generated the key/certificate pairs?

I’ve been realizing that Syncthing is pretty much unusable at a large scale (>15 nodes) without some sort of installer that would generate node IDs and config files for a given setup.

@mplorentz Our approach would be a preety big hassle indeed: Istarted syncthing on my machine and let it generate a key/certificate pair together with a config. Then I saved those files in a folder named for the intended target machine. Then I repeated the procedure 5 times until I had 6 key/certificate pairs and 6 configs. Next, I manually edited all the configs so that in the end I had 6 folders, each with their own key, certificate and config. In our application installer we check which machine we are installing on and copy the corresponding folder.

I’ve been thinking about various kinds of more or less centralized config management. Possibilities include storing nodes and repo info in srv/txt records in DNS and pointing syncthing to a given subdomain to look up things in, or using a rest interface on top of https a to push/pull configs. Perhaps something along riots lines could be useful to you.

I’m glad to hear you’ve been thinking about it. It seems like the biggest pain point for users at this point and a good solution could open up Syncthing to larger deployments and less technically savvy users.

I don’t think the less technically savvy users are the ones deploying clusters with tens of nodes and autogenerated configs though, so these are separate target audiences (simplification for the one-off user and ease of management in larger deployments).