I’m working on implementing a multi-user / multi-instances setup for the users of my fileserver. Therefore I’ve set up a startup script to start an instance for each of the users, configured by a simple string. I define users and their gui-ports in a config file (users=“userA:8384;userB:8385;userC8386”) and start syncthing with the according -gui-address option. There is an apache reverse proxy set up to allow users to acces their gui via https://server/username/.
So far, so good.
What now causes work for me is to get the user instances to bind to different ports (default 2200/TCP). Configuration is easy, just adopt the line above to users=“userA:8384:2200;userB:8385:2201”.
The thing is there is no command line option in syncthing to set the protocol port. Either I setup a script that adopts every users config, what can only be done after the first start. Or I log in to every users gui and change the port - or tell the users to do so.
I would like to see a Command Line Option, let’s call it [-protocol-address=<address>], to set or better override the syncthing protocol address/port the same way as I can set the gui-address. It would make administration (also firewalling) of multi-user/multi-instance setups easier.
There could be an argument for doing every config option ever as a command line switch to override the config file. I don’t think that would scale. The -gui-address is special as it gives you a way to talk to Syncthing regardless of what the config file says. I think you should do the sync port changes via API or config file scripting.
Given that I can’t access the gui and need to alter the gui-address because the config file is faulty/broken. If I am able to / have permission to alter the command line options on the server I would assume that I can fix the config.xml directly. So one might also argue that the -gui-address option is useless.
Having an command line option to override the protocol-address would also add security/stability to mutli-user setups. The administrator defines the command line options, and this way manages the listening ports. If I setup the protocol-address for each user via gui/cli/config.xml and one user changes the settings of his instance to use a port that is already taken by another user, he could break not only his own setup but also the one of the other user. Users will do that, because they will play with the settings, especially if an administrator tells them to not alter option X.
Syncthing is not made for multi-tenant environments, the fact that you decided to run it in multi-tenant environments doesn’t mean we need to mend to suit your your needs, as thats not the usecase we are targetting.
You could argue that but it’s not the case. It’s very useful for things like GUI wrappers (Android, SyncTrayzor, Syncthing-GTK etc.) as they can start Syncthing and assign it both an API address and an API key using command line flags.
Note that there can be any number of listening ports, and we’ll soon default to having at least two out of the box: 22000/TCP and 22020/UDP (for KCP). If you’re multi-tenanting Syncthing and letting users access the configuration I highly recommend at the very least running each instance in its own container. You solve the port conflict issue and can simply let your users know that if they want incoming connections to work they shouldn’t change the listening port from 22123 or whatever you’ve assigned them. You also avoid them getting a too close peek into the system by adding / as a folder.
two FreeBSD 11.1 servers at two sites, sharing data with users via nfs, samba, sftp - and now syncthing
users sync their data (mostly portions of it) to laptops (Win, Mac, Linux) and mobiles (Android, iOS)
on the servers there’s one Syncthing instance per user, running as the user to keep permissions/ownership (the users still use nfs, samba and sftp to access their network-drives)
one of the servers is somehow a “master server” by being added as introducer to all other servers and users
How I synchronized stuff before:
up to recently there was only one Server
owncloud/nextcloud was used to sync laptops and mobiles
network shares were mounted via sftp into own-/nextcloud
especially common files caused a lot of traffic between the sites, because of the central server architecture
Why I switched to syncthing, and built the multi-user init script:
Syncthings decentralized architecture is a mercy - it’s easy now to have a second server (or even more)
it keeps the servers in sync, plus
users moving between sites (what happens quite a lot) is no problem
that’s what kept me from setting up a server on the second site
Let’s say a user has added something on site A, has it synchronized to server A and then moves to site B. Arriving at B, server A has partly synchronized with server B. Now synchronizing the users laptop with server B could/will lead to conflicts.
With Syncthing and it’s peer-to-peer approach this use-case is not only no problem anymore, it even safes traffic between the sites by “sneaker-netting” (parts of) the data between sites.