In windows, you can’t overwrite the exe without shutting down the syncthing first, is it possible to enable a manual update server within a private network so that I don’t have to update it by handle for each version? can I have the control on uniting the version?
AFAIK you cannot change the URL, where syncthing checks for updates.
But you can disable automatic updates and then use the option
-upgrade-to="" Force upgrade directly from specified URL
to upgrade the currently running syncthing to another version.
With the current versions, you will need to sign your syncthing version (if you do not use the original).
1 Like
Currently the upgrade check is tied quite tightly towards the Github API, since that’s where we look for and load upgrades. So just being able to set the URL for auto update checks wouldn’t be terribly useful, unless you actually want to replicate the Github API and structures on your own server.
I’ve been considering doing something about that, but it’s not a priority…
As @wweich says though, you can point to an URL of your own to force an upgrade from there. The v0.11 code will just blindly accept any archive that looks nice (and includes a checksum of the binary). The v0.12 code expects a correct cryptographic signature, which means you need to use the official binaries + signatures, or you need to fork the code to add your own key and produce your own builds. There’s some sparse documentation on this here.
1 Like
I did a command “syncthing -upgrade-to=http://x.x.x.x/syncthing.exe” while syncthing is running, and I didn’t get it updated, what did I missed? the file is copyed from an updated version: v0.11.24
I tested from another PC, that path I can download the exe, and I noticed that the syncthing -upgrade-to command uses HTTP GET command, because I was trying to use my existing FTP server.
You need to point it to a release archive, i.e. one of the .zip or .tar.gz files.
1 Like
Also, it only supports http(s).
1 Like
@JinxGenius in a trusted environment you could shutdown Syncthing, copy the new .exe from a controlled location (e.g. central server share), and start Syncthing
@uok the problem is, I’ll have to manually vnc into each environment, stop the process, copy the new exe, and start again, I don’t mind doing this for around 10 computers in fast connection, but I’m doing 80+ with different connection type/speed. I just want a better way to solve it.
I’m talking about building a private sector and maintaining it to the same standard, and what I ask for is an option to override the “standard update server” and point to my own.
as the developer don’t like lots of people temper this thing, I’d say hide it in advance option is surely good enough.
You can just have a separate agent process which does that.
of course a seperate agent is not as efficient as the original.
my work around right now is to execute the specific update url with a batch but I still need to find a way to massively deploy them all, and my another problem is network disruption, I can’t really dispatch the update to all at the same time.
setting up a server is a lot easier than repeating a process manually.
Well I doubt it will happen, as even if we do allow a custom URL, you’d have to mimic githubs apis which is a fair share of work. Plus 99% of users are fine to update from github, hence not a lot of incentive to begin with. Ofcourse, if you propose a reasonable pull request which solves that, I am sure we’d be happy to merge it, but it needs to work around the github api issue.
@JinxGenius here are a few suggestions as I don’t know your environment
idea A (central fileserver, clients use VPN)
- client connects with VPN
- VPN autoscript copies file syncthing.exe
- start Syncthing
idea B (own webserver with HTTPS)
- client always starts Syncthing with
-upgrade-to
idea C (no central fileserver, no VPN, only company webspace)
- client downloads syncthing.exe with wget from your webspace with non-public URL
- replace .exe and start syncthing
In all cases you should make use of a script that runs on successful VPN connection (A), after client login (B, C) or you could use the windows task scheduler to run a certain times.
Replicating the API sounds easier to me than writing a upgrade script for multiple operating systems. Writing the upgrade server is then something for the community because everybody may have different needs there 
Syncthing should just have the option to change the URL in my opinion.
We can do that, for sure. Please file an issue on Github, and preferably a pull request to resolve it.
PR not before next week, but I could do that 
thanks for the ideas,
but unfortunately they don’t really work,
here’s the brief of my situation:
I have 80+ pc, all running on windows, mostly XP, but still have different OS version, one of them is a file server (the mother), I can only VNC into them in order to change anything (both mother and sons), they all run 24/7, most of them are in class A network with a few exception, those exception can automatically update themselves from github, the rest are solely depend on the mother.
I planned to use Psexec but all of them don’t have ssh running, I have setup a webserver on mother side just for specific URL update purpose.
The reason I ask for implementation is because there isn’t a break while syncthing is running, the above ideas require a “start” but there is no such procedure of “starting” nor “rebooting” unless the PC crashed, but syncthing still need to update IMO.
idea B is not a bad idea, I can batch the process with -upgrade-to at the front and force restart once a day but then I will lost the ability to count how long does the system last, and compare it to how frequent does the connection drop.
idea C contains the problem of stopping exe before I can replace it, which I don’t have to proper way to execute the command but to do it manually. like I said, the only way I can run/change anything is to VNC into those PCs.
Well. All we really need is to be able to change the update url, and to generate a JSON file or two to emulate the github API. Your process would then be to have an HTTP server somewhere, point your clients to it for upgrades, and when you want to roll out an upgrade you download the package from github, run a tool to generate the “manifest” and put those files on your server. It’s totally doable.
Well, not now but when it’s released.
1 Like