There is now a “supported” packaging of Syncthing for Synology. Instructions and package source here: https://docs.kastelo.net/synology/. I welcome testing and reports of success or otherwise, as well as requests for clarification of the documentation.
For issues with the package or it’s documentation, please open issues at the kastelo/syncthing-synology repository, or let me know in this thread.
Note that that this is not an “official” package in the sense that the Syncthing foundation or open source community is behind it. It’s a third party packaging much like any other, it just so happens that I work with/at the third party in question. It could conceivably become an official packaging at some point, but that would require a community around it first and I’m not going to foist responsibility of this thing on the Syncthing community at this point – while Kastelo currently has commercial interests in maintaining it.
I’d like to point out that there is also a well integrated Syncthing package in the SynoCommunity repository. It is maintained as open source (in part by myself) and although tge version suggests otherwise, keeps up to date with the built in upgrade feature.
Might be an option to support that effort instead and just point to the download package page? Sorry I haven’t looked at your build solution yet, but the SynoCommunity folks are very experienced in making it work for all Synology architectures.
The question is, in fact, what would be the benefit of the Kastelo version. I have the version of SynoCommunity in use for years and it runs very well.
From time to time I have problems with permissions. “sc-syncthing” is stored as a group, which can be assigned relatively easily for the main directories. However, it always happens with the main directories that messages appear, such as “error while traversing /volume1/abcxyz: permission denied”
An “internal system user” is stored in the version of Kastelo. My question would therefore be whether the above effect would be gone. What are the advantages of the “internal system user” over a group and is it above a group? That would be very interesting for me.
What I saw in difference, the version of Kastelo can not update via the release channel, that is deactivated. But I suppose this can be changed in the options, I will check it.
The next step is to be careful when storing the package source “https://synology.kastelo.net/” if the package from SynoCommunity is installed at the same time. As v1.2.2 is currently up to date for the SPK and v1.3.3.3 for Kastelo, an update is displayed. I was careful and did the update on a Test Synology. The update itself was successful, but then the folder and device settings were all gone (!), which is equivalent to a new installation.
This now only as a hint, if you think about a change, you should take into account that everything has to be set up again afterwards.
There is no advantage, if you are running the current SynoCommunity release and it works for you. Carry on as you were.
The Kastelo distribution exists for one specific reason: for inclusion into the main Synology package store, as a supported package for a client. This has the side effect of also making it available for everyone, hence this topic.
I’m not sure; this seemed like the simplest setup. The service needs to run as a user, and that is the syncthing user.
The Synology package will behave like other package manager controlled distributions: the package itself is updated at each release and can be auto upgraded by the Synology package manager. This is akin to the APT and Snap distributions. The built in upgrade method is disabled in all these packagings to avoid having package version 1.3.3 suddenly run Syncthing 1.4.0.
After setting up and first testing of the Kastelo version compared to the version of SynoCommunity, I have two advantages for the version of SynoCommunity.
I cannot find any relevant difference between “internal system users” and “local groups” at the moment. The “sc-syncthing” group can be easily assigned to the various main directories in the Control Panel as “Local Groups” (SynoComm.). In contrast, for “internal system users” (Kastelo) each individual main directory has to be edited separately, which means considerably more effort. In any case, these two user assignments do not appear to have any influence on the known synchronization problems. No user mapping has an advantage or disadvantage over the other.
In the version of SynoCommunity, updates are made directly via the GUI, as usual. With the Kastelo version, an update of the SPK is required, I assume a new SPK will be displayed in the package center. It remains to be seen how close these updates are to the releases.
The Kastelo version has no advantage over the version of SynoCommunity with regard to the package center, since this also has an SPK for the package center. Unfortunately, the SPK update cycles are much to long and not connected to the releases, v1.2.2 is still current. The good thing in connection is that after the SPK installation, the GUI can then be updated to the latest version, currently v1.3.3. However, I understood what the intention with the Kastelo version is to do the releases with the SPK and not through the GUI. In the end, I think that’s an advantage.
Another point for the SynoCommunity version is better integration with the DSM UI. An install wizard IIRC asking some permission stuff and educating about the sc-syncthing group for ACL management. Predefined rules for the DSM integrated firewall. An icon on the “Desktop” linking to Syncthing’s own web GUI. I was working on integration with the system certificate store, so that the installed certificates (e.g. from Let’s Encrypt with auto renewal) get reused for Syncthing. Got stuck with DSM internals there, however.
Regarding upgrades, the SynoCommunity folks are quite busy so if an app updates itself internally, there is no pressing need to keep publishing SPKs. So usually a new Syncthing version gets pulled as part of other changes in the packaging. I’ve been doing that for the last couple releases and will keep monitoring for when incompatible changes might warrant a new SPK. Just trying to keep the effort for SynoCommunity low.
If anyone feels a strong need for an updated SPK, I will quickly take care of it upon request.
What do you mean by “major updates”? Bumps in the second version digit, for example 1.2.x to 1.3.x?
What could happen currently is: Syncthing 1.2.2 is installed from SPK, then internally updates to 1.3.x. You then make a backup of the configuration, reinstall the SPK version 1.2.2 for some reason and restore your configuration from the backup. Then Syncthing 1.2.2 could theoretically choke on the more recent configuration or database version. It’s a rather unlikely scenario though and can be avoided by letting Syncthing auto-update before restoring the backup.
Don’t get me wrong, I’m not trying to argue against @calmh’s efforts. Just having these two packages doing stuff differently and not even using the same configuration will lead to user troubles sooner or later. We could try to merge the features from SynoCommunity to the Kastelo package, provided its packaging is open for contributions.
Perhaps it’s a matter of preference in a corporate environment. The corporation may trust Kastelo differently than it trusts the SynoCommunity. Personally, I’ll use the SynoCommunity software. In a corporate environment, I’ll use what’s officially in the Synology repos. I think what calmh is working on is getting the Kastelo version into the official Synology repos for corporate clients.
Neither overrides the other, but it’s good to have choices.
The problem, however, is that if both package sources are specified, only one can be used. I added the package source for Kastelo in my test synology and it became an update for the existing SynoComm. offered. Description above. I have not tested this yet, but this could mean that the user can only install the latest package because of the naming.
Major updates could occur for various reasons. Change of program files, the structure etc. Using the example of ownCloud software: if you use version 9.0.1 and want to use the current 10.3.2, you have to carry out all intermediate updates as major steps up to version 10.3.2
However, that is not currently the situation with Syncthing. As far as I can tell from the source code, each release includes code to upgrade from all the older versions’ database formats and will iterate through all these procedures in turn, automatically. That’s a good design IMHO and I hope it will stay that way.
@calmh whatever differences there are or will be between the two SPKs, would you consider renaming your package before it gets uploaded to the official Synology repos? That would avoid big trouble (reset configuration basically) for all the users who already have the community repo enabled.
Naming it “syncthing-official” or similar would prevent it from showing as a harmless update for the other package.
Yeah that’s unfortunate. The publishing process for packages into the Synology store is both slow and crappy so there is time to consider. Not calling the package “syncthing” seems like probably the best option, after looking into it. For now the package is called syncthing.net instead.
This would be deemed unacceptable by any sane packaging system I know of. Version upgrades are supposed to happen through the packages, not willy-nilly.
The version of Kastelo is installed on the Test Synology DS and you can see what is displayed. There is a systematic error in the package naming, otherwise the DS could make the difference. This is by no means a permanent solution!
