Your system is confused at the moment because I’ve renamed our package. You presumably have the non-renamed package installed, which is then the synocommunity package.
What I ask not be discussed here is how the synocommunity edition decides to do upgrades and auto upgrades. It’s besides the point.
Icons seem to load “after a while”, this being a Synology issue…
Thanks for doing the rename, that’s a good measure already.
Maybe we can reach a point where it is no longer needed. Toward that goal, I think the following questions should be answered:
Why do the packages not access a common home location containing database and config? Even when they did use the same package name?
Are you interested in porting over the missing features from the community package? Firewall integration, permission management strategy and user / group names, possibly better SSL certificate integration come to mind. The packaging scripts are quite different so I could not yet estimate what effort that would take and whether I could help out much.
If we make a switch to the Kastelo version seamless and offer an improvement, I’d happily retire the community package with its inferior update policy (granted, @odin but hard to improve considering available manpower) and focus on maintaining an “official” SPK in sync with upstream Syncthing. The latter is probably already better automated to require less manual release duties.
Yeah, I understand that. Sorry about the tone; re-reading I see it’s rather brusque.
To correct this change, uninstallation and reinstallation were required. The connetion data was not deleted during the deinstallation. Therefore, all peer connections were immediately available again during the new installation, and the ID of Synology remained the same. The only thing to do was to reassign the “Internal System User” with the name “syncthing.net” in the file system. Then Syncthing runs again, effort about 5 minutes.
However, the old user “syncthing” was not deleted, I made this correction manually in “/etc/passwd”, there you could also see the change of the package in “/var/packages/syncthing.net”.
@calmh, maybe you can tell us something about your planning regarding the package updates. If version 1.3.4 comes out in the foreseeable future, or after that 1.3.x etc., how long that updates in these packages takes, until they can be installed. Ideally, the package updates also come with the release updates.
The use of beta versions would not be important now, but it would be interesting if you could use the beta functionality from Synology’s DSM. In my opinion and if you want to stay consistent, you can not regulate it via the GUI. But basically, I personally would not care whether betas would go or not.
Yes, I will look at this. So far I haven’t looked closely at all at the community package, for various reasons. If this package can provide an upgrade path with equivalent functionality that would be good. Even if it’s not an “upgrade”, being as compatible as possible is still good.
The Synology package v1.3.4 on our package source will be released tomorrow with the other packagings of v1.3.4 on GitHub etc, and likewise in lockstep moving forward. It’s literally a mouse click after the other releases.
However, for the moment consider the Synology package “in beta”, packaging wise. There have been changes based on the feedback in this thread (package name) and it’s likely there will be further changes to be compatible with the synocommunity package. Things might break.
The official package store is different. As far as I can tell at the moment the upgrade process is “send in the new package via email; it might get published in a month or so”… It’s not optimal.
That is understandable. However, for a beta, it worked out well spontaneously and well, I like that.
In any case, it is good that there is the “syncthing-data” directory, which is not available in the version of SynoComm. So if there are complications with the package and a new installation is necessary, it is not nice, but the basic data is still available, I saw this with the current change.
Otherwise, I’m assuming normal package updates. They are carried out and then it continues.
After another test, the use of an internal system user has no advantages, but rather disadvantages:
1.) The assignment of rights for the main directories as a an internal system user is cumbersome, if “syncthing.net” would be a user or a group user, this could be easily and quickly stored in the main directories in the system control.
2.) The same errors also occur in this version of Kastelo. It always happens with the same main directories that messages appear, such as “error while traversing / volume1 / abcxyz: permission denied”.
3.) In directories, such as “photo”, the rights are assigned by default in the photostation and not in the control panel. In contrast, no rights for internal system users can be configured in the photostation, only for users and group users. Only with special knowledge the rights can be assigned in the system control by removing the ACLs in the subfolders. Only a few user can do that (!).
I therefore strongly advise (!) To store “syncthing.net” not as an internal system user, but as a user or group user, this has only advantages.
I have seen that version 1.3.4 has been online for about 1 hour. All GUI updates are updated. The Kastelo update for v1.3.4 was also offered and the update went flawlessly and runs.
By the way, the SynoCommunity package runs as a user sc-syncthing (sc for SynoCommunity I suppose, all their service users have this prefix) and group syncthing. The former is also an “internal system user” and they advise to use the group for ACL entries. There were some good reasons I cannot remember, but what @Andy described sounds important enough.
So @calmh, I propose you use the same group named syncthing for your package so that users switching between packages do not need to reassign all permissions. Your syncthing.net internal user is fine as a distinction from sc-syncthing, as both packages might try to remove the user so it should be different. As long as both users are in the syncthing group, things should work fine.
IIUC, the configuration and database directory is not placed within the “installation target”, /var/packages/syncthing/target/, which is actually a symlink to the chosen volume for add-on packages (/volume3/@appstore/syncthing on my NAS). The way SPK updates work as I understood is that the “target” directory is backed up (at least its var subfolder?), then the new package extracted, and the backup restored over the new package files. Removing and reinstalling discards the state directory though.
So having the Syncthing home folder outside of @appstore is an interesting approach to keep the data safe even after uninstallation. Not quite sure which is better, but an automated migration path between the different packages would be nice. If the Kastelo approach is preferred, I will propose to adopt that within the SynoCommunity package.
Btw. sorry for asking about the Kastelo package behaviour instead of just checking for myself. Time and a spare NAS for experimentation being the limiting factors mainly.
I installed both packages on one of my servers, it works without problems. Only the package name “syncthing” may is a problem for system-related actions such as stop and start of the package, because both affected. So if I want to stop a package, then both stops.
Regarding users and groups: On none of my Synology servers I have a user “syncthing” or “sc-syncthing”
I only have the group user “sc-syncthing”
At the internal system users I have “sc-syncthing” and “syncthing.net”.
There is nothing more.
Indeed, you are right the group which can be found via the GUI is named sc-syncthing. That one is used for ACL permission management.
On my two NASes there is a second group called syncthing, and all the package files under /var/packages/syncthing/target/ from the SPK are owned by sc-syncthing:syncthing. That’s how I got confused. Now where does that come from and why is it different from the GUI-visible group?
$ grep syncthing /etc/group /etc/passwd
/etc/group:sc-syncthing:x:65536:sc-syncthing
/etc/group:syncthing:x:104555:
/etc/passwd:sc-syncthing:x:114670:104555::/var/packages/syncthing/target:/sbin/nologinThe Kastelo package uses a group “syncthing” as per earlier suggestions.
Why you change that to a internal systemuser?
What?
Why you change from the early Group User to the current internal System User?
I have done no such change
I have on no server the group “syncthing”. But a group would be good for handling.