When the user installs your package.
Well I think this thread shows that the problem is not about âpristineâ installations, but only matters when there is already an existing configuration, that was touched by a more recent Syncthing binary at some time.
Right. But the user is installing your package. They do that because they want what it provides. Since you allow auto upgrades, the package implicitly provides a random version of Syncthing. The one thing you canât allow to happen is that a reinstall becomes a downgrade. So providing the latest version at install time seems reasonable.
In fact, looking at what happens, a standard Syncthing will auto upgrade immediately on startup when itâs not been prohibited from doing so. So in effect you are already doing this, just not explicitly. So whatever binary youâre bundling, as soon as weâve released something new thatâs no longer what the user gets when they install, even if they elect to disallow upgrades when they first get to the GUI.
1 Like
Okay, agreed. But I wouldnât count on being able to grab the latest version. If there is already a binary in the location we would be overwriting, and it is not older than the one we have bundled, it should just be left untouched and possibly do its auto-upgrade thing when started the next time.
I know the people at SynoCommunity wonât welcome that approach. They have a lot of framework stuff in place to build Syncthing and even Go itself when creating the package, instead of just bundling a released binary. The fact that Syncthing is allowed to auto-upgrade at all is probably because they trust that the internal updater will pick a compatible replacement binary matching the platform, and authenticate it as well.
Thatâs true for a âstandardâ Syncthing, yes. But Iâm still talking about the unfortunate situation where the (re)installation meets an existing config from a previous but higher-versioned binary.
What I want to achieve is actually just what you describe. Just that it bails out trying to read the future config before the upgrade check right now. Instead it should read as much of it as possible to see whether upgrades were disabled in there, and only if autoUpgradeIntervalH == 0 it should fail (with a better explanation). Thatâs what would fix the failure mode experienced in this topic with SyncTrayzor.
For the SynoCommunity package, the main fault is overwriting an existing binary with an older version without comparing versions first. We need to mirror something like what SyncTrayzor does to mitigate that.
1 Like
Thatâs entirely inconsistent: Either you care about distributing your custom built, perfectly suiting Syncthing binary, or you let it auto-upgrade. Using a custom built thingy and letting it auto-upgrade makes no sense.
I donât think Syncthing should do any half reading like that: Either config is usable â go ahead, or itâs not â error. If a package allows auto-upgrades and bundles Syncthing, itâs entirely sensible to make it upgrade when installing the package and encountering a newer config (or better yet, package detects that Syncthing was newer before).
Especially since Syncthing will auto upgrade within seconds of initial package installation, so the user will almost never be running the shipped binary⊠I said âstandard Syncthingâ but I donât mean just our builds - the synology shipped binary will also do this.
I think part of the problem here is that the error message is too technical for the average user to know what to do next (as clearly shown in this topic). In other words, they understand that Syncthing is unable to start, but theyâve got no idea how to fix it.
The solution mentioned in the error message itself, i.e. telling the user to do -allow-newer-config isnât really an option, because the user still has got no idea where to actually use the flag. The alternative is to go and manually delete/modify the config file, which is problematic too, because the average Windows user doesnât even know what %LOCALAPPDATA% is.
It would be nice if SyncTrayzor (and other wrappers) had a newbie-friendly solution to either automatically fix the problem or simply ask the user whether they are OK with downgrading their previous config, and then proceed if the user agrees.
Thatâs because of the historic necessites to get anything built for DSM at all. The multitude of CPU architectures used in Synologyâs DiskStations is usually handled by having a cross-compilation toolchain for each model and OS version combo. The generic approach for any C-based software is to cross-compile it using the Synology-supplied toolchain.
For Go programs, they first compile a host-native Golang toolchain. It could just as well be documented as required on the developerâs host, or included in the build Docker image. But itâs built from source for trust or whatever reasons, maybe to allow cross-compiling Golang for use on DSM as well? To generate Go binaries, they hardcode a mapping of DSM architectures to GO_ARCH settings, then use Goâs cross-compilation skills.
I guess besides mimicking the cross-compilation of all other SynoCommunity packages, it must be about trustability and / or having a reproducible build process to not rely on whoever built the âofficialâ binaries. Including their choice of platforms to provide binaries for at all. Since the authenticated source code contains the procedure used to verify and authenticate updates, that leaves the chain of trust intact.
The other possibility would be to record digests of each platformâs binary release as root of trust and download those files directly to pack into the different SPK architecture packages. I can see how one could be skeptical regarding long-term availability of the binary releases and needing to depend on all expected architectures being actually part of the release. Of course the same limitations apply to Syncthingâs internal updater.
But Iâm getting a bit off topic I suppose. SynoCommunity works like it does, but this usability problem popping up without user action and without a way to diagnose / fix it should be addressed with the simplest possible means.
Itâs even much more complicated on Synologyâs DSM platform. You canât just ârunâ Syncthing from a terminal. Getting to the terminal itself is a nontrivial task and only gets you an âadminâ shell. Switching to the correct user account and setting up the environment like HOME path and Syncthingâs --home flag in addition all needs to be done manually.
Again, asking the user is completely out of the question on Synology. There is just no GUI at all unless you log into a browser session, and even during an upgrade âwizardâ the user interaction possiblities are severely restricted. So whatever happens there must be automatic or the user will be left completely oblivious. Thatâs quite a different situation from SyncTrayzorâs installer in that regard. The common factor is just managing a bundled, but auto-upgrading syncthing binary.
Well it reads the config version currently, so thereâs some precedent here.
In my perfect world Iâd just like to pass a flag when I first run Syncthing for a given user (ie when I copy Syncthing into a userâs AppData), which makes it auto update there and then.
(Note that this is first run, not install time. Install time has all sorts of complications, not least that the user doing the installation might not be the user who runs Syncthing, and I donât want to be doing things with downloading binaries from the internet when running elevated.)
2 Likes
Re synology toolchain:
I donât need an explanation as to why someone would want to make a custom build. I am a tiny bit involved in debian - thereâs a thousand more reasons there (good and less so) why itâs built in a custom way. My entire point is that doing that and not disabling auto-upgrades makes zero sense. And if you disable auto-upgrades, the entire discussion we are having here becomes moot.
Thatâs almost there: syncthing --upgrade will to that, except that it will exit after upgrading. So you first start would be syncthing --upgrade && syncthing serve.
1 Like
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.