My understanding of the “folder master” configuration option is that on a “master” server, setting it will protect the contents of that folder from changes via syncthing. I tested this. I configured a 3 node grid: master, pwnd and slave1. I shared a folder and marked it as “Folder Master” on server master. I threw a file in there and see it is propagated to all the other servers. I then go onto server pwnd and modify that file. I see that on slave1 the changes propagate. I see that on master the file remains unchanged and I get a big red button that says “Override changes”. When I click that button, I see that the file reverts to it’s previous state on both the pwnd and slave1.
Desired Behavior
The feature I’d like to see is for “folder master” to be a server id. In the event that syncthing receives a change, it checks to see if this change originates from the configured folder master. If it does, then the change gets applied. If it does not, then the change is ignored. There is never any “Override changes” button to push. In the event that a file changes on disk, if the server is the folder master, then it sends out that change. Otherwise, it would re-download / revert the file.
If there is agreement in the community on this, can I please get an estimate on what would be required to implement it?
In that case, wouldn’t the master have to send a full copy of the data to each node? If so, think about whoever is letting Syncthing manage 19 tibibytes… I wonder if they are also the cluster with 485 nodes?
Currently this isn’t possible because we don’t know where the change originated (protocol wise). It could be made possible, though.
This has been discussed a couple of times, and it’s not behavior I want to see in Syncthing. If you want files not to be modified locally on a given device, have those files be owned by a specific Syncthing user and writeable only by that user.
That’d be fairly neat, and there’s a ticket on at least part of this that is actionable. But not even I can find it at the moment…
it checks to see if this change originates from the configured folder master. If it does, then the change gets applied.
Currently this isn’t possible because we don’t know where the change originated (protocol wise). It could be made possible, though.
What would need to happen to make this possible? I’d love to see a crypto signature on whatever it is that is analogous to the torrent file generated by the server sending updates. This would allow differentiation between servers which can change data and servers which can merely distribute it.
Well, you’d need to start signing index entries, so adding a signature to the FileInfo struct which spans all attributes.
Secondly you’d need to store and preserve the full public key for each device as you first connect, and check the signature as you receive updates, and either refuse incorrectly signed updates as they arrive or ignore them if you store them.
If we wanted to do that, which I’m not convinced of, then we should probably look at using a different, small ECDSA key for the update signing. To avoid having to carry huge RSA blobs around.
Strikes me as a valuable feature, being able to differentiate between servers that may change data and servers which may only distribute it. I’d like to use Syncthing to distribute a bunch of production config data across a few hundred servers in several geographically distributed data-centers. The security team is going to take issue with the idea that having any of our servers hacked could lead to the intruders being able to update or delete configs for all our servers, even if it’s only temporary and we can revert it by clicking a button.
If there’s a way to sponsor development of this feature, I might be able to squeeze some money out of my boss.
It’s best to squeeze development time from your boss, especially if you want this done within a reasonable timeframe, rather than waiting for someone to care enough to take the money.
Hmm, I don’t think we have any GoLang developers around here. Maybe I can hire a contractor? Sigh. This seems like a pretty central use case for enterprise applications.
Go is not hard to learn, I picked it up in a matter of hours.
Yeah, you can try hiring someone, that will probably be better than just putting a bounty on it, because as we’ve seen in the past with the support for encryption ticket, throwing money at the general public doesn’t always work out.
For me atleast, this is a hobby project, so I work on stuff which I find interesting or find it useful to the average Joe.
To be honest, I am like Robin Hood, I personally couldn’t care less about the enterprise (no offence), as this is not a commercial product which makes money so I see no need to please the enterprise. It’s actually the opposite, the more the enterprise has to sweat to make it fit it’s needs the happier I am, as that will usually come back as pull requests in return back to us, which always makes me happy.
My two cents: I would recommend to the dev team that they should continue with the protocol that they have before going down this path. There are several possible topologies that would have to be considered before trying to tackle this. After all, you are not trying to develop a distributed filesystem; that’s another thing entirely. Your current protocol has tons of potential and custom implementations are quite possible using networking and permissions.