Meta: DSM7 package status

Question

Meta: DSM7 package status

hgy59 opened this issue 4 years ago · 118 comments

Overview of the status of packages for DSM7

Successfull build/install/run is tested with x64 only (unless otherwise stated).

As of may 2021 all pure CLI packages are ready to be published for DSM7. Please regard DSM7 packages still as beta.
The synocommunity package repository does not support beta packages per TCVERSION so it is not possible to mark packages as beta for DSM7 only.
Packages that other packages depend on are distingueshed in bold. Those should be published as early as possible.

PACKAGE	Build	Install	Run	Data Folders ⁸⁾	Published	COMMENT
adminer	✔️	✔️	✔️		✔️	⁷⁾, noarch, #4514, finallized with #5160, but issue #5191
beets	✔️	✔️	✔️		✔️
bicbucstriim	✔️	✔️	✔️		✔️	^{1, 7)}, noarch, #5952
borgbackup	✔️	✔️	✔️		✔️	#4710
boxbackup-client	✔️				⛔	¹⁾
chromaprint	✔️	✔️	✔️		✔️	#4545, #4692
comskip	✔️	✔️	✔️		✔️	#4545, #4692
cops	✔️	✔️	✔️		✔️	^{2, 7)}, noarch #5192
couchpotatoserver	✔️					⁴⁾, noarch
couchpotatoserver-custom	✔️					noarch
curaengine	✔️					¹⁾
dante-sockd	✔️				⛔	#4898, #5006
darkstat	✔️				⛔	requires root to capture network trafic
debian-chroot	❌️
deluge	✔️	✔️	✔️		✔️	⁶⁾, #4429, #4695, #5398
demoservice	✔️					⁶⁾, noarch
dnscrypt-proxy	✔️					³⁾
domoticz	✔️	✔️	✔️		✔️	#4674
duplicity	✔️	✔️	✔️		✔️	#3823
ejabberd	✔️	✔️	✔️	~~target/etc/ejabberd/~~ target/var/lib/ejabberd/	✔️	#4333, #4959
erlang	✔️	✔️	✔️		✔️
fengoffice	✔️	✔️	✔️		✔️	²⁾, #5992
ffmpeg	✔️	✔️	✔️		✔️	#4545, #4576, #4692
ffsync	✔️	✔️	✔️		✔️	#5942
fish	✔️	✔️	✔️		✔️
fishnet	✔️	✔️	✔️
flexget	✔️	✔️	✔️		✔️	#4603, #4657
fossil-scm	✔️	✔️	✔️		✔️	#4915
full-text-rss	✔️					¹⁾, noarch
gateone	✔️				⛔	noarch
gentoo-chroot	❌️			target/etc
git	✔️	✔️	✔️		✔️	#4597
~~git-server~~	✔️					^3,7), ⁵⁾, git, noarch, package removed, use gitea instead
gnupg	✔️	✔️	✔️		✔️	#4599
haproxy	✔️				⛔	³⁾
~~hassio~~	✔️					Package removed
he853	✔️				⚙️	needs root to activate udev rules
headphones	✔️	✔️	✔️		✔️	⁴⁾, noarch, #5488
headphones-custom	✔️					noarch
homeassistant	✔️	✔️	✔️		✔️	#4580
horde	✔️					²⁾, noarch
htpcmanager	✔️					³⁾, noarch
icecast	✔️	✔️	✔️		✔️	#4628
imagemagick	✔️	✔️	✔️		✔️	#4585
inotify-tools	✔️	✔️	✔️		✔️	#4644
irssi	✔️			target/etc		¹⁾
itools	✔️				⚙️	³⁾, #4985
jackett	✔️	✔️	✔️		✔️	.net version only, mono is not supported (yet)
jappix	✔️					¹⁾, noarch
jellyfin	✔️	✔️	✔️		✔️	⁵⁾, ffmpeg #3932
~~jupp~~	✔️					¹⁾, package removed, integrated into synocli-file
lazylibrarian	✔️	✔️	✔️			noarch
lidarr	✔️	✔️	✔️		✔️	⁵⁾, ~~mono~~, chromaprint #5485
lirc	❌️			target/etc		Mandatory requires kernel sources and they are not available for DSM7
lua	✔️	✔️	✔️		✔️	#4596
mantisbt	✔️	✔️	✔️		✔️	²⁾, noarch, #6237
maraschino	✔️					³⁾, noarch
mediainfo	✔️	✔️	✔️		✔️	#4762
memcached	✔️	✔️	✔️		✔️	³⁾, #4522
mercurial	✔️	✔️	✔️		✔️	^1,5), #4591
minio	✔️	✔️	✔️		✔️	^{6, 9, 10)}, #4683
mkvtoolnix	✔️	✔️	✔️		✔️	#4622
monit	✔️	✔️	✔️		✔️	#4827
monitoring-plugins	✔️	✔️	✔️		✔️	#5082
mono	✔️	✔️	✔️		✔️	(#4669) - avoid mono for DSM7, migrate related packages to dotnet instead #3715 #4669 (comment)
mosh	✔️	✔️	✔️		✔️	#4667
mosquitto	✔️	✔️	✔️		✔️
mtproxy	✔️					#4725
mutt	✔️	✔️	✔️		✔️	#4922
mylar	✔️					noarch
node-exporter	✔️	✔️	✔️		✔️	#5207
nodejs	❌️				✔️	#5037, DSM 7 only
ntopng	✔️				⛔	^3,5), redis
nzbget	✔️	✔️	✔️	target/share	✔️	⁶⁾, #4996
~~nzbget-testing~~						package removed
nzbhydra	✔️					noarch
nzbmegasearch	✔️					³⁾
octoprint	✔️	✔️	✔️		✔️ ⚙️	³⁾ this might have issues with serial devices
owncloud	✔️	✔️	✔️		✔️	²⁾ #5619
plexivity	✔️					³⁾, noarch
plexpy-custom	✔️					noarch
plowshare	✔️					package completly removed with #6246
ps3netsrv	✔️	✔️	✔️		✔️	⁶⁾, #4984
pyload	✔️	✔️	✔️
python2	✔️	✔️	✔️			¹¹⁾, ~~dependent packages should use python 2.7.18 of DSM7~~
python3	✔️	✔️	✔️		✔️
python38	✔️	✔️	✔️		✔️
rabbitmq	✔️	✔️	✔️		✔️	⁵⁾, erlang
radarr	✔️	✔️	✔️		✔️	finally fixed with #5268
rdiff-backup	✔️
redis	✔️	✔️	✔️		✔️	#4727
roundcube	✔️	✔️	✔️		✔️	²⁾, noarch, #6243
rsnapshot	✔️	✔️	✔️		✔️	noarch, #5019
ruby	✔️	✔️	✔️		✔️	#4715
rutorrent	✔️	✔️	✔️		✔️	^{6, 7)} #4695, #5617
sabnzbd	✔️	✔️	✔️		✔️	⁶⁾
salt-master	✔️	✔️	✔️		✔️	#5017, #5145
salt-minion	✔️	✔️	✔️		✔️	#5017, #5145
saltpad	✔️					^3,5), salt-master
selfoss	✔️	✔️	✔️		✔️	²⁾, #5916
shairport-sync	✔️
sickbeard-custom	✔️					noarch
sickchill	✔️	✔️	✔️		✔️	¹⁾, #4703, #4964
sickrage	✔️					noarch
sonarr	✔️	✔️	✔️		✔️	#4706
squidguard	✔️			target/etc		#4695
sslh	✔️	✔️	✔️		✔️	⁹⁾, #4742
stockfish	✔️	✔️	✔️
stunnel	✔️	✔️	✔️		✔️	#4828
subliminal	✔️					³⁾
syncthing	✔️	✔️	✔️		✔️	#4527
synocli-disk	✔️	✔️	✔️		✔️	#4694
synocli-file	✔️	✔️	✔️		✔️	#4616
synocli-monitor	✔️	✔️	✔️		✔️	#4694
synocli-net	✔️	✔️	✔️		✔️	#4643
syno-magnet	✔️	✔️	✔️		✔️	noarch
tcl	✔️	✔️	✔️		✔️	#4577
transmission	✔️	✔️	✔️		✔️	⁶⁾, #4313, #4719, #5956
tt-rss	✔️	✔️	✔️		✔️	²⁾, #4840, #4630, #4923
tvheadend	✔️	✔️	✔️		✔️	#4545, #4686, #4692
umurmur	✔️	✔️	✔️		✔️	#4990
vim	✔️	✔️	✔️		✔️
wallabag	✔️	✔️	✔️		✔️	²⁾, #6232
znc	✔️	✔️	✔️		✔️	#4602
zsh	✔️	✔️	✔️		✔️
zsh-static	✔️	✔️	✔️		✔️

Remarks:
¹⁾ Avoid link and usage of /usr/local/{package-name}
²⁾ Migrate mysql to mariadb-10
³⁾ Does not install due to required root privilege
⁴⁾ Installer uses unsupported function like set_unix_permissions, syno_remove_user, syno_group_create, syno_group_remove, syno_user_add_to_group, set_syno_permissions, syno_user_add_to_legacy_group
⁵⁾ Requires a dependent package that might not be published yet.
⁶⁾ SERVICE_WIZARD_SHARE is not supported for DSM7. Shared folders must be declared in resources and must be the name of the share (without volume).
⁷⁾ Packages that integrate into WebStation (web apps, web services) must register via WebStation webapi or use a Package Worker.
⁸⁾ target/var is not listed here, as migration is already implemented in current installer.
⁹⁾ Invalid version number. DSM7 validates $(SPK_VERS)-$(SPK_REV) with regex [^\d+(\.\d+){0,5}(-\d+)?$]. So only digits and dots are allowed in SPK_VERS.
¹⁰⁾ SERVICE_EXE needs migration to SERVICE_COMMAND.
¹¹⁾ As Python2 of DSM 7 comes neigther with pip nor virtualenv it looks like we have to deploy python2 for DSM 7 (at least for the single package ffsync that will never be ported to Python 3 as it is about to be migrated to Rust).

⛔ Packages that require root privilege to run will not be compatible with DSM7.
⌛ Packages that need root previlege for installation will not be compatible until synology allows permission settings for specific installation steps.
⚙️ Packages that need access to USB devices. synology might drop support for USB devices.

Answer 1 · 2021-03-30T07:57:54.000Z

@hgy59 Is there an overview of changes I need to make to get DSM7 compatibility for my package (sabnzbd)?

Answer 2 · 2021-03-30T08:50:55.000Z

@Safihre I suggest to start with the Wiki DSM7.0-Beta

For your package you may only need to change ${SYNOPKG_PKGDEST}/var to ${SYNOPKG_PKGVAR} and knowing set_syno_permissions won't be doing anything in DSM 7. Just inspect the log files if there are additional permission errors. Unfortunately I can't test DSM7 stuff for now, as I'm waiting for my replacement unit (possibly something wrong with the power/mobo inside my unit failed.) 😢

Answer 3 · 2021-03-30T09:14:25.000Z

So how do we handle the permissions?

Answer 4 · 2021-03-30T11:34:58.000Z

Generally you don't. Since you don't have root. DSM will chown the folders for you (using the package name) if you need other folders they need to be given in the resource worker or the user has to add the package from the DSM settings (look for "internal users" category) to a folder.

Answer 5 · 2021-04-04T07:23:45.000Z

Can we maybe update set_syno_permissions to do the service worker stuff?

Answer 6 · 2021-04-04T08:08:14.000Z

Under the DSM 7 restrictions I don't have a clear idea how that would work. Not saying it's impossible but even if done it wouldn't be backwards compatible anyway. If you're willing to contribute sure. But once you read DSM Developer Guide 7 0 Beta in full I think you might reconsider. IMHO the work required (if it's even possible with the new restrictions) to make it work is not worth the time.

I encourage you look at the transmission package. It allows only the user to choose a Shared Folder through the wizard.

The reality is that the NAS now manages the permissions, and packages only get a few selected knobs to play with. The permissions are in the user hands through the file manager and control center as "internal user" (IHMO that's a good thing. So malicious software can't just upload random files to a remote server)

Answer 7 · 2021-04-04T08:28:47.000Z

Sabnzbd also has a wizard already, but I don't quite see from the Transmission example what needs to be changed about it to make it work. Is it something in the name of the variable?
I have not really been part of the whole DSM 7 story, so I don't know what's already impmented in the framework. My own NAS can't even run it (old model), so I will admit that I am not very motivated to really dive deep just to update my 1 package. 😕

Answer 8 · 2021-04-06T10:31:33.000Z

On DSM7.0, rabbitmq is failing to start due to incorrect service_postinst().
As indicate in #4539, the installer logs must be redesigned and fixed for DSM7.0 to allow many packages to work again :)

Answer 9 · 2021-04-10T15:09:35.000Z

update/repairing after update to dsm7 of umurmur fails because of

Does not install due to required root privilege

Answer 10 · 2021-04-11T03:17:56.000Z

@daxcore This is expected. Did you read our Readme.md? If you where to read the table above then you would see that everything is very much work in progress on the master branch. (no packages are published yet, but you can compile your own).

Answer 11 · 2021-04-12T06:17:05.000Z

@publicarray Thanks for the wiki-page DSM-7.0-Beta.

As we get closer to DSM 7.0, I wonder when we will rename this page (remove the beta). As all the existing links to this page will be broken by a rename, we might better start with a new wiki page for DSM 7.

We could wait for such a page until DSM 7 (final or RC1) is released and document validated facts only.

What would you prefer?

Answer 12 · 2021-04-12T09:52:18.000Z

I propose that relevant stuff in DSM-7.0-Beta is moved/copied to their respective wiki page (Permission Management, Generic Service Support etc.) and that we create a quick DSM7 upgrade guide or a quick dsm7 reference for developers (IMHO the detailed wikis tend to quite long, I think some stuff is repetitive and or It's hard to find a specific thing. It's good to have them tough especially for newcomers but a quick dot-point list like the DSM-7.0-beta is more digestible for a quick lookup, kinda like a cheat sheet. What do you think?

Answer 13 · 2021-04-19T06:18:47.000Z

To give an overview of packages that need additional data migration, I have added the column Data Folder.
This is for all folders that need extra data migration (config files). The target/var folder must not be listed here as it is already migrated in the current installer code.

Answer 14 · 2021-04-19T08:10:58.000Z

Maybe we should migrate the target/etc the same way we migrate target/var ?

Answer 15 · 2021-04-22T06:23:26.000Z

Maybe we should start to set os_max_ver (as in #4567) for all DSM<=6 packages to something like os_max_ver=6.999 .
Hopefully this will limit the packages shown in DSM7 package center to those that are published for DSM7.

Answer 16 · 2021-04-23T12:15:11.000Z

@hgy59 perhaps something closer to os_max_ver=6.9-39999.
Sadly this field is not well documented in the developer guide (even in previous I found).
Will it actually block it from showing in the package center? I guess that could be tested?

That could be quite easy to add to my current PR such as seting from the spksrc.tc-vers.mk file such as:

if ($(word 1,$(subst ., ,$(TC_VERS)),5)
TC_OS_MAX_VER=5.9-6999
else if ($(word 1,$(subst ., ,$(TC_VERS)),6)
TC_OS_MAX_VER=6.9-39999
endif

Then in spksrc.spk.mk change my snipet for:

ifneq ($(strip $(OS_MAX_VER)),)
	@echo os_max_ver=\"$(OS_MAX_VER)\" >> $@
else ifeq ($(strip $(TC_OS_MAX_VER)),)
	@echo os_max_ver=\"$(TC_OS_MAX_VER)\" >> $@
# If require kernel modules then limit
# 'os_max_ver' to point releases only
else ifeq ($(strip $(REQUIRE_KERNEL)),1)
	@echo os_max_ver=\"$(word 1,$(subst ., ,$(TC_VERS))).$(word 2,$(subst ., ,$(TC_VERS)))-$$(expr $(TC_BUILD) + 10)\" >> $@
endif

Lastly add to spksrc.tc.mk:

        @echo TC_BUILD := $(TC_BUILD)
        @echo TC_OS_MIN_VER := $(TC_OS_MIN_VER)
        @echo TC_OS_MAX_VER := $(TC_OS_MAX_VER)
        @echo TC_ARCH := $(TC_ARCH)

Answer 17 · 2021-04-23T15:03:53.000Z

That could be quite easy to add to my current PR such as seting from the spksrc.tc-vers.mk file such as:

I prefer to test this with my local repo as we have to wait up to 48h for the repo on synocommunity.com until new packages appear in the package center in DSM.

Answer 18 · 2021-04-23T15:06:13.000Z

@hgy59 let me know if you want me to adjust #4567 or prefer another PR if deemed working out as expected.

Answer 19 · 2021-04-23T21:45:19.000Z

Unfortunatly this does not work with the current implementation of spkrepo and there is already an open issue SynoCommunity/spkrepo#63.
Your solution in #4567 will not work either.

Answer 20 · 2021-04-24T11:39:54.000Z

Your solution in #4567 will not work either.

@hgy59 The intent of that particular PR was not related to spkrepo but rather making sure that after an upgrade the package would be disabled as now incompatible with the new kernel.

Answer 21 · 2021-04-24T12:36:13.000Z

@th0ma7 I do not understand what you mean by disabled.
As the spkrepo does not care about the third part of the version number and always delivers the highest build number of Major.Minor version this will look like this:

say we have only such versions of package in the repo:

package-6.2-22259
package-6.2-24922
package-6.2-25423
package-6.2-25556

Now you have devices with different DSM Versions installed

DSM 6.2-22259
DSM 6.2.2-24922
DSM 6.2.3-25423
DSM 6.2.4-25556
DSM 7.0-40000

With the current spkrepo implementation all these devices will get the same version of package downloaded in the DSM package center

package-6.2-25556

You cannot force to download package-6.2-24922 for DSM 6.2.2 when package-6.2-25556 is not compatible with DSM 6.2.2 due to different kernel version.

Answer 22 · 2021-04-24T13:29:15.000Z

@hgy59 from a spkrepo point of view, you are most probably right. I don't know if there is anything that can be done to add such field so it is understood somehow from the package center which would be quite useful.

I am rather referring to the actual package, already installed/running on your DSM: I want to make sure that it becomes disabled (or removed) pre-post applying a DSM upgrade that affects the kernel.

With this I assume that, lets say you are running DSM 6.2.3-25423 and using a compatible kernel package, it will stop working when you install DSM 6.2.4-25556 upgrade due to the os_max_ver variable in already installed package.

Answer 23 · 2021-04-29T07:50:25.000Z

Dear @hgy59 how can i install these packages (noarch) on my NAS with DSM 7.0? i do not find any source?

thanks

Answer 24 · 2021-04-29T09:50:42.000Z

Dear @hgy59 how can i install these packages (noarch) on my NAS with DSM 7.0? i do not find any source?

As long as those packages are not published, you need to install the spk files manually in the DSM Package Center of your Diskstation.

You can download packages created with github build action of the related PR or on master branch for merged PRs.
Or you can create those packages in the development environment in the spk/{package} folder with

make TCVERSION=7.0

Answer 25 · 2021-06-23T18:08:05.000Z

offical release of DSM 7 for those who hasn't seen the news final build comes out June 29th,

Answer 26 · 2021-06-27T02:34:04.000Z

ffmpeg + tvheadend + chromaprint + comskip now published.

Answer 27 · 2021-06-28T12:16:20.000Z

I did some testing on DSM 7 and here are some findings and suggestions.
For packages that need to share files, the old (pre DSM 7) framework supported the group sc-downloads, but because as of DSM 7 the installation scripts can only run with package privs so this solution does not function any more.

My suggestion would be to use the next privilege file for those packages who needs to share files with other packages.

{
  "defaults": {
    "run-as": "package"
  },
  "username": "sc-<packagename>",
  "groupname": "synocommunity"
}

All those package are then using the group e.g."downloads" (don't use sc-downloads, because that can already exists and will create problems).

Also I would suggest to use a resource file like this:

{
  "data-share": {
    "shares": [
      {
        "name": "{{wizard_share_name}}",
        "permission": {
          "rw": [
            "sc-<package name>"
          ]
        }
      }
    ]
  },
  "port-config": {
    "protocol-file": "app/<package name>.sc"
  }
}

This will create a new share owned by the package user and the group "downloads"

The input for the sharename can be gotten from a install_uifile (or hard coded if you which).
Here an example of a install_uifile to do so.

[
  {
    "step_title": "Basic configuration",
    "items": [
      {
        "type": "textfield",
        "desc": "Used Share for downloads",
        "subitems": [
          {
            "key": "wizard_share_name",
            "desc": "sharename",
            "defaultValue": "<package name>"
          }
        ]
      }
    ]
  }
]

Combined with a postinstall script like this:

if [ ! -d "$SYNOPKG_PKGDEST_VOL/$SYNOPKG_PKGNAME/downloads" ] 
then
  mkdir "$SYNOPKG_PKGDEST_VOL/$SYNOPKG_PKGNAME/downloads"
  chmod 770 "$SYNOPKG_PKGDEST_VOL/$SYNOPKG_PKGNAME/downloads"
fi

This configuration will create a new share with group privileges for the group "downloads" and a subfolder name "downloads" with the correct privs.

Answer 28 · 2021-06-29T09:58:49.000Z

unsure if this is the final release thats suppose to come out today but its higher then the RC version
https://archive.synology.com/download/Os/DSM/7.0-41890

Answer 29 · 2021-06-29T10:13:38.000Z

@sam43434 yeah this one is the final release.

Answer 30 · 2021-06-30T07:33:21.000Z

@hgy59 , @ymartin59 , @th0ma7 and @publicarray
What is your opinion on my suggestion to use the same groupname in the privilege file for packages that need to be able to access files from other packages instead of creating the group sc0download in the scripts?
And also create a data-share with the resource file to place the files they need to share.

And if you agree with this proposal, what is the best name for this group?

Answer 31 · 2021-06-30T08:38:31.000Z

Oh no... I thought this whole problem of shared folders between applications was already implemented 😔 seems like yesterday when we had to fix this exact same problem for DSM 6.
@BenjV so your proposal is allowed by DSM, so that multiple resources can be shared between applications?

Answer 32 · 2021-06-30T09:41:25.000Z

@Safihre
Yes I tested it on DSM 7, and this way the "hidden" package users will all be using the same "hidden" group.
And within the resource file you can create a share which is owned by this "hidden" user:group combo and if you add group access to that share in the postinstall phase with a chmod command, all packages from that group will have access.

So the most important issue at the moment is to agree on this methode and to decide the name of that group.
We could use the name "download", but not the old name "sc-download" because that will give conflicts.

Answer 33 · 2021-06-30T10:05:22.000Z

In the data share definition, we can define multiple users, so we can additionally give access to the community groups (@sc-download, @sc-media, ...) for such shares.

"data-share": {
    "shares": [{
            "name": "<share-name>",
            "permission": {
                "ro": ["<user-name>", ...],
                "rw": ["<user-name>", ...]
            },
            "once": "<once>"
        }, ...]
}

Answer 34 · 2021-06-30T10:05:47.000Z

... postinstall phase with a chmod command, all packages from that group will have access.

Wouldn't chmod fail in DSM7 as now restricted (or I got this wrong)?

So the most important issue at the moment is to agree on this methode and to decide the name of that group.
We could use the name "download", but not the old name "sc-download" because that will give conflicts.

We have sc-download and sc-media (any others?). I would much rather keep them...

Answer 35 · 2021-06-30T10:14:52.000Z

@th0ma7
That share is created and owned by the "hidden" package owner and so the script has privs to chmod them.
Default it is created with only rw privs for the owner so you have to add rw privs for its group as well

If you use an existing name "sc-download" and people upgrade from DSM 6 to DSM 7 you get problems.
The existing share will be renamed to something like "sc-download_PKG" and that can create problems if the old name is used by the end-user.

@hgy59
You can only add a share during installation of a package, not later on.
So adding access later on won't work.
Adding an existing name with another package will cause a rename of the share created by a previous package.
And if you use the "once" keyword, it won't do anything at all if the share already exists, so no extra privs are added.

Using the same group for all those packages is clearly the easiest way to solve this.
After all, groups exists for sharing privs.

Answer 36 · 2021-06-30T10:36:35.000Z

You can only add a share during installation of a package, not later on.
So adding access later on won't work.

This behavior is when setting "once" : "true" in the data share definition.
If you set this to "false" or omit this, the share permissions are adjusted/updated at every service start.

Answer 37 · 2021-06-30T10:47:31.000Z

Would it make sense to create a SynoCommunity core package to manage this specifically (and potentially other items alike)?
Then make all packages depends on it by default with DSM7.

Answer 38 · 2021-06-30T10:49:14.000Z

@hgy59
I just tested that and you are correct, so that could work too.
In that case just the privs are added.

If this methode would be used, a share with a fixed name should be created for those packages and not leave it to the user via a install_ui wizard, because we must be sure the same share name is always used.
If you use the group method that would not be necessary, because every share created via this method would be part of the same group.

Answer 39 · 2021-06-30T14:06:51.000Z

@hgy59 @BenjV Isn't the whole wizard stuff removed in DSM 7? At least that's what I understood from the discussions previously?

Answer 40 · 2021-06-30T16:55:29.000Z

@Safihre
I tested it and you are correct.
Synology removed it from the final DSM 7 release.

My testing was first done on the release candidate and their it was still functioning, in de final DSM 7 release you cannot install a package with a wizard_ui file on board anymore.

In the release candidate it still was available and functioning, but in the final version it is gone.
Also in de beta version of the development guide it was still present, but in the new development guide that chapter is gone.

@hgy59, @ymartin59, @th0ma7 and @publicarray
So a fixed share must be created by all those packages, via the resource file.
Anyone wants to propose a name?

Answer 41 · 2021-06-30T16:59:16.000Z

Here's a proposal:

volume1/
└── SynoCommunity
    ├── download
    └── media

Answer 42 · 2021-06-30T17:04:35.000Z

So far we discuss new installations, but what about existing shares and packages? How do users grant access to the packages to use other/existing folders? Is it obvious how to do it? How will it work after packages are upgraded, can they still access their old shares?
(my ancient Synology won't get DSM 7 update)

Answer 43 · 2021-06-30T17:11:19.000Z

@th0ma7
Fine with me, but you cannot choose the volume.
Via the resource file the share is always created on the same volume as the volume where the package is installed (mostly volume1).
This can create problems if end-users are installing different packages on different volumes, but that is not to be avoided and will rarely occur I think.

I would still suggest to use a common group name in the privilege file for all packages, that would create maximal flexibility.
Lets name that group also "SynoCommunity"

Answer 44 · 2021-06-30T17:13:01.000Z

So far we discuss new installations, but what about existing shares and packages? How do users grant access to the packages to use other/existing folders? Is it obvious how to do it? How will it work after packages are upgraded, can they still access their old shares?
(my ancient Synology won't get DSM 7 update)

Imo it's clear how to grant access

Answer 45 · 2021-06-30T17:21:35.000Z

@Safihre
End-users can login as admin and give privs to the "system internal users" on shares.
The problem for packages is that they cannot assign privs during installation, because the scripts do not run as root anymore.

And current installed packages should still work, although they all must be updated because all actions from the scrips that need root privs will not work and will stop installation and/or upgrading.
DSM 7 is very picky and will refuse to install with the message that the package is corrupted.
When I upgraded to DSM 7 there was only one of several packages that survived it ( it was git) all other installed package disappeared from the package center.

Answer 46 · 2021-06-30T18:54:59.000Z

@hgy59 @BenjV Isn't the whole wizard stuff removed in DSM 7? At least that's what I understood from the discussions previously?

No, wizards are not removed (and the discussion was withing the maintainers group of this community)
I have a WIP with minio and the wizard including the page to choose share (name), access-key and secret key is still shown with DSM 7.0-41890.

Answer 47 · 2021-06-30T19:10:20.000Z

So a fixed share must be created by all those packages, via the resource file.
Anyone wants to propose a name?

Even when synology might remove installation wizards some time, we should only use real shared folders defined by the share-name.

We still have to verify that an existing share is used and the users defined in the resource file of the package are added to that share.

But: This will allow the users to create the share on any volume before installation.

real shared folders mean folders, that are created similar to "Control Panel - Shared Folders - Create". Such folders can only be managed by the "Control Panel - Shared Folders" control - it is not possible to delete those on the command line (even with root access).

My preference would be to use the named shared folders sc-download and sc-media (i.e. name it with the name of the synocommunity common group names).

Answer 48 · 2021-06-30T19:32:53.000Z

If you add a share in the resource file it is just like all other shares a real share.
The only difference is that the "system internal user" of the package is the owner of that share.

You should not use existing shares, that will cause the existing share to be renamed.

All shares can be remove via the commandline with the synoshare --del command is you have root privs.
And to create two shares is pointless, just create one share and two folders on that share like @th0ma7 suggested.

Answer 49 · 2021-06-30T20:59:00.000Z

My preference would be to use the named shared folders sc-download and sc-media (i.e. name it with the name of the synocommunity common group names).

Agreeing with you on using the sc- prefix. Also, usage of singular, always.

With it I wonder if the SynoCommunity top folder is really needed:

volumeX/
└── SynoCommunity
    ├── sc-download
    └── sc-media

or

volumeX/
├── sc-download
└── sc-media

Answer 50 · 2021-06-30T21:34:08.000Z

In the first case you only need one share and two folders.
The second case needs two shares to be created.

In my opinion it is better not to create unnecessary shares.
Rember that shares have more overhead then folders, especialy on the network.

Answer 51 · 2021-06-30T23:06:09.000Z

I like the idea of a SynoCommunity shared folder, however migrating data from DSM6 is might be hard. I think I would prefer the user to mange their own files and permissions, we can guide them. The positives of this approach is that it eases maintenance significantly. It also means that users can organise their folder how they want. And Less magic/code to migrate if Synology releases a DSM8. Just my 2c

Edit: I've updated the permission wiki with DSM7 screenshots

Answer 52 · 2021-07-02T14:11:51.000Z

Regardless whether or not a SynoCommunity share is implemented, it would be a good idea to use common group for all SynoCommunity packages by adding this groupname to the privilege file of all packages.

Answer 53 · 2021-07-03T11:21:57.000Z

In the table it says borgbackup can Build, Install, and Run on DSM7, but it seems failed in my test. #4709

Answer 54 · 2021-07-03T13:43:54.000Z

In the table it says borgbackup can Build, Install, and Run on DSM7, but it seems failed in my test. #4709

The table says that borgbackup is not published to the synocommunity package repository. So you must build this package yourself and install manually in the DSM package center of your Diskstation.

There are different reasons that a package is not published yet.
Most are mentioned in the comment column, but others are not, like: package upgrade is not updated for DSM7.

Answer 55 · 2021-07-04T08:36:40.000Z

@publicarray
You wrote a nice wiki on permissions, but some of that is no longer valid for DSM 7.
Packages cannnot execute any command that needs root privs anymore on DSM 7, so things like creating or adding users to the group sc-download does not function anymore.
Adding the "system internal user" of a package to a group like sc-download is not possible anymore on DSM 7.
So maybe add some comment that this Concepts is only valid for DSM 6.

Also I would suggest to add a statement that when using existing shares/ folders or files permissions to the "system internal user" this must be set recursively and not only on the top share or folder.

By the way, if all packages would be created (via the privilege file) in the same group then we can mimic the behavior of the old sc-download group, because all package would then belong to that group.

Answer 56 · 2021-07-04T15:13:53.000Z

@BenjV I think @ymartin59 wrote those a while ago, I've only updated some of the DSM7 part, there are many things that still need to be updated. This just was one I thought needed it most since we link to it in the wizard. AFAIK anyone can contribute, edit and improve the wiki. I'll look at updating the wiki further when I'm able.

By the way, if all packages would be created (via the privilege file) in the same group then we can mimic the behavior of the old sc-download group, because all package would then belong to that group.

I don't think it works, last time I played with it the implantation seemed incomplete or partly broken. Or maybe I just did not understand how they were meant to be used. Any group name is not visible to the user, so I don't see any benefit here. The only potential use I found is that you can read/write files from another package with the same group. Another problem is that if you called the group sc-download in the privilege file it will be renamed if the group already exits in the user interface. So there is no migration path.

If wizards are really going to go without an official alternative I think there are 4 ways to work without them.

Provide sensible defaults for packages and let the user change setting from the package interface themselves. (Transmission etc. could work well here)

Most secure, easy for maintainers, not beginner friendly,
some packages don't have an interface so SSH is the only other way to change config files. We would need to make users aware of the configuration file locations. (e.g. HASS.io)

Create a package that has the permissions to edit any other package file from SynoCommunity (I attempted something like this before: SynoEdit) I might revisit this if there is interest.

Less secure, need to setup the permissions for every package. More user-friendly, but more work for maintainers
2 ways the editor can work,
1. With a file allow list which we would need to constantly maintain.
2. Or just any file on the system (would need to implement a file browser) which could also allow a user to break things

Create a shared SynoCommunity folder where package config files can go and use Synology's build in text editor.

Less secure, more initial work for maintainers,
Some packages might not like to have the config files in non-standard locations.

Any better option you can think of 💡

Answer 57 · 2021-07-04T19:15:10.000Z

In the past you could not use the same group for different packages, if you did the packagecenter added a random number to it.
When Synology release Dsm 6, I asked their developers to change this a they said they would consider it in future release and now it is corrected.
I tested this and it functions fine on Dsm 7.

The user can use this group in the permission viewer and in the advanced permission settings.

The most benefit would be that all packages would belong to the same group and could read/write each others files if they have group permissions.
This can replace the current functionality create with the current sc-download group.

And as you said, using sc-download is not possible, so I would propose to use the groupname "synocommunity".

The wizard is gone from the documentation, but still functions as before, so lets just use it as long as it is there.
Synology themselves are also still using it in their packages.

Answer 58 · 2021-07-05T13:41:17.000Z

On the zsh and zsh-static packages I do not see anything in the COMMENT column. I was wondering if they are being also looked at for the DSM7 package format (same problem as others are reporting on other packages that the installer is complaining about the format).

I've just pulled the trigger on the DSM7.0 and I was probably a bit too early and realized that a dozen of my scripts are not working anymore because zsh is not working :-)

Answer 59 · 2021-07-05T19:09:08.000Z

On the zsh and zsh-static packages I do not see anything in the COMMENT column. I was wondering if they are being also looked at for the DSM7 package format (same problem as others are reporting on other packages that the installer is complaining about the format).

@mirceadamian, all (stateless) CLI packages are expected to run with DSM 7. These must be built for DSM 7 only.
I've just published zsh and zsh with modules for DSM 7. These have the same Version as the latest DSM6 packages (v5.8-11 and v5.8-7) and are ready for manual download.
It will take up to 48 hours until those are available for Installation with the DSM integrated package manager (until then, you still get the non installabel DSM 6 version).

Answer 60 · 2021-07-05T20:40:48.000Z

It was working but I was trying to cleanup the repair list and accidentally uninstalled it. I will manually download it.

Answer 61 · 2021-07-08T08:27:25.000Z

@BenjV I've updated the wiki please let me know if this is accurate. The groups you are talking about won't be available to select in the GUI anymore, so it doesn't make managing permissions any easier for the end user.

The wizard is gone from the documentation, but still functions as before, so lets just use it as long as it is there.
Synology themselves are also still using it in their packages

Agree 100%, but I think it's worth exploring other options just in case.

Answer 62 · 2021-07-08T17:02:08.000Z

@publicarray
With setting the same group for all packages, it makes it possible to share data between packages without the end-users involvement, that would be the purpose.
If you have for example a package like SickChill that search for torrents and use the Transmission package for the download, during installation the package could create a share for that and via the group settings they can share the files.
Package builders don't need to use this, but if we choose to use the same group, this option is available.
If we leave is as is, then for every package DSM will create it's own (useless) group.

Regarding the wiki:
When users migrate from DSM 6 to DSM 7 and the need to give access to another package user, then granting that "system internal user" access to that share is not enough if there already are existing folders and/or files present.
The privs of those will not change.
That has to be done with FileStation, by creating permissions for the "system Internal user", and thick the box "apply to this folder, sub-folders and files.

Maybe you could add that advice to the wiki?

By the way DSM 7 defined and create several new locations for files (see page 76, FHS of the development manual).
DSM does not clean-up those folders after uninstalling the a package.
I would suggest to add cleaning up of those folder in the post-uninstall phase of all packages to keep the system clean.
Something like this:

rm -fr "${SYNOPKG_PKGVAR}"
rm -fr "${SYNOPKG_PKGHOME}"
rm -fr "${SYNOPKG_PKGDEST_VOL}/@appconf/${SYNOPKG_PKGNAME}"

Answer 63 · 2021-07-08T21:54:53.000Z

With setting the same group for all packages, it makes it possible to share data between packages without the end-users involvement, that would be the purpose.
If you have for example a package like SickChill that search for torrents and use the Transmission package for the download, during installation the package could create a share for that and via the group settings they can share the files.

yes, but not shared folders, they behave differently: you would have to add every package username

"data-share": {
    "shares": [{
    "name": "<share-name>",
    "permission": {
        "ro": ["<user-name>", ...],
        "rw": ["<user-name>", ...]
    },
    "once": "<once>"
        }
, ...]
}

ls -l /volume1/downloads/somefile.txt
-rwx------+ 1 sc-transmission sc-transmission 

group of the package was `synocommunity`

Please test your ideas first.

Regarding the wiki:

Yea thanks, I agree the wiki can be made more clear.

DSM does not clean-up those folders after uninstalling the a package.

We already have a new uninstall wizard that takes care of this.

Answer 64 · 2021-07-08T22:08:13.000Z

Not clear what you mean with "test your ideas first".
I did test it.
Seems to me that you tested with the wrong privilege file.

If you add in the privilege file the groupname "synocommunity" then everything the package creates wiil have "synocommunity" as group, only if you don't add a groupnane Dsm will create a group with the package name and currently the framework uses sc-********* as username and also as groupname in the privilege file
See my ealier post abiut this. #4524 (comment)

Answer 65 · 2021-07-09T09:28:13.000Z

If you have for example a package like SickChill that search for torrents and use the Transmission package for the download, during installation the package could create a share for that and via the group settings they can share the files.

This use case works when both packages use the same shared folder and have correct permissions. With the DSM7 transmission package (#4719) this works by using a wizard. No groups needed. I probably don't understand what you are after.

seby@DSM7:/$ sudo synogroup --get synocommunity
Group Name: [synocommunity]
Group Type: [AUTH_LOCAL]
Group ID:   [207066]
Group Members: 
0:[sc-transmission]
1:[synoedit]
seby@DSM7:/$ ls -lh /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part
-rwxrwxrwx+ 1 sc-transmission sc-transmission 2.7G Jul  9 10:15 /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part

~~not sure why the permissions changed to rwxrwxrwx~~

seby@DSM7:/$ sudo su
Password: 
ash-4.4#  ls -lh /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part
-rwx------+ 1 sc-transmission sc-transmission 2.7G Jul  9 10:36 /volume1/downloads/ubuntu-21.04-desktop-amd64.iso.part

🤔

What you are saying about groups is true for files not in shared folders.

ls -l /var/packages/transmission/var/settings.json
-rw------- 1 sc-transmission synocommunity 2321 Jul  9 10:54 /var/packages/transmission/var/settings.json

So how I really don't see how that would help....

FYI: To set a group in the permission file just set the SPK_GROUP variable in a Makefile. (after #4721 is merged to fix a bug)

Thanks for the link to your comment (It got lost to me in this long thread). I did this stuff ages ago too and did the transmission package but for some reason it didn't get merged from the dsm7-packages branch, hence the new PR.

Answer 66 · 2021-07-09T11:18:11.000Z

Files created in folders get the permission of the parent.
So if you create a shared folder in resource files and create subfolder there with the correct permissions then all files and folder created there gets the correct permissions.
Those subfolder must be created by the package of package group.
If you do it as in my example(#4524 (comment)), everything will function fine.
I tested it extensively.

And I propose not to set the group via the SPK_GROUP but to force it for all packages to "synocommunity", that is the only reliable way else we get a possible mixture of all kind of groups.
Remember the whole Linux group idea is to share groups, not to create a separate group for every package user.

Answer 67 · 2021-08-04T12:54:18.000Z

MediaInfo can be marked as not compatible. Version 20.08-11 doesn't repair or install on DSM 7.0-41890 showing error about invalid file format.

Mosquitto 1.6.15-12 failed to launch after repair. Uninstalled (erased config), installed again and works like a charm.

Answer 68 · 2021-08-04T16:21:47.000Z

MediaInfo can be marked as not compatible. Version 20.08-11 doesn't repair or install on DSM 7.0-41890 showing error about invalid file format.

All packages that are not marked as published in the table above are not yet available for DSM7.

Answer 69 · 2021-08-22T20:48:03.000Z

What about mc (Midnight Commander) port to DSM7? I don't see it in the table above. Is it abandoned? Or are there technical issues with the port (I don't see related separate issues either)?

Answer 70 · 2021-08-22T20:52:44.000Z

mc is part of synocli-file package and thus available for DSM 7.
There is no dedicated mc package anymore (but you could build one by your self with diyspk/mc).

Answer 71 · 2021-08-30T08:40:20.000Z

I do know that rsnapshot is still red, yet it is working with DSM7 (at least with intel x64): I had installed it before the update to DSM7, the package manager also still says rsnapshot has to be repaired. Yet it is working nicely every day. Anyway, I hope an update will be made some day for first installations.

Answer 72 · 2021-09-05T07:42:10.000Z

I am not able to find info about Medio

https://bitbucket.org/polandj/medio/src/master/

it was a helpful piece of software - it needs Python ( apparently not compatible with DSM 7 )
is it any reason to not be listed here?

Answer 73 · 2021-09-05T08:02:14.000Z

i'm waiting for the port of umurmur. is there any reason, why it is not adapted?

Answer 74 · 2021-09-05T10:13:43.000Z

i'm waiting for the port of umurmur. is there any reason, why it is not adapted?

Because SynoCommunity is run by volunteers that have to do this next to their regular jobs and life, so to implement the changes Synology requires takes time since (almost) each package needs to be manually updated.

Answer 75 · 2021-09-10T22:29:16.000Z

Hey everyone. Is there any news about #4429 ?
Thanks!

Answer 76 · 2021-09-18T10:20:04.000Z

Will there be packages for Radarr and Jackett that are compatible with the EVANSPORT Architecture (DS214 Play)?

Answer 77 · 2021-09-19T17:47:06.000Z

Please make the ps3netsrv package compatible with DSM 7.

Answer 78 · 2021-09-20T07:00:50.000Z

Will there be packages for Radarr and Jackett that are compatible with the EVANSPORT Architecture (DS214 Play)?

No, the 32-bit (x86) architecture is not supported by .NET on Linux and mono builds will be phased out anyway, at least there are no new builds for Radarr. Maybe if someone wants to spend some time on it and push a PR or when .NET decides it wants to support 32 bit on Linux

Answer 79 · 2021-09-27T09:51:52.000Z

Just a short message to say that I tried to upgrade the tt-rss package to MariaDB 10 and then DSM 7.
The migration to MariaDB 10 worked well, but upgrading DSM to 7 broke the package. I recompiled it directly for DSM 7 and the new version was not working at all (I assume there are privileges issues).
In the end, I manually installed tt-rss to /var/services/web. I needed a few changes (especially to be able to run the rss feeds auto-update ; there's a call to the php cli from within the scripts and the PHP_EXECUTABLE const must be modified in /classes/config.php to fit the dedicated php73 cli binary) but it is working well now.
The thing is that tt-rss doesn't support officially anymore such installations. They now provide a Docker image and it's the only official way to use tt-rss (data must be migrated from MariaDB to Postgre, that's why I did not make it, but there is a procedure for that), so I guess that this package will (should ?) be dropped off from SynoCommunity.

Answer 80 · 2021-09-27T16:57:42.000Z

@LeBlondTenebreux there is already @smaarn working on this (see #4840 and #4630 )

Answer 81 · 2021-09-29T01:18:25.000Z

Merging #4695 would add 4x new "build" check-marks that now builds on DSM7, namely deluge, ffsync, rutorrent and squidguard. Afterwards I'll look into getting the remaining ones to build on DSM7 ...

Answer 82 · 2021-11-15T08:19:03.000Z

sickchill works fine now.

Answer 83 · 2021-11-20T07:22:03.000Z

@hgy59 grateful if you could update the table now that SickChill can install and run on DSM7.

Answer 84 · 2021-12-01T04:56:35.000Z

I do not understand the status of nzbget. Is it not possible to develop this for DSM 7? Is there a workaround, besides running the package in Docker?

Answer 85 · 2021-12-01T08:25:21.000Z

@McEnnes I'm certainly keenly interested in this as well. Without hearing from someone more knowledgeful, I only guessed that it was related to the way it had to be installed on DSM6 (via command line). The remarks for the package status indicate SERVICE_WIZARD_SHARE is not supported, but I don't know if that means PRs upstream or just work for the Synocommunity.
People with docker capabilities don't have any qualms, but lowly little people like us just have to wait :)
I do appreciate all the work on the rest of the repo, this (and less so headphones) are the only components that's keeping me from upgrading.

Answer 86 · 2021-12-01T12:23:05.000Z

Hi @McEnnes, @timrettop is mostly right. Packages are slowly being updated to include DSM7 support with limited resources this can take some time. Some technical details: Indeed SERVICE_WIZARD_SHARE has given us some trouble. We did add support to DSM7 but We had reports where it doesn't always work. Basically when the share already exist and was initially created with an older version (unknown what specific settings/dsm version causes this) then it could fail. As it turns out Synology had a different implementation for shared folders or ACL permissions and the new API/worker in DSM7 can't work with it. The solution so far is to recreate them in DSM7.

Answer 87 · 2021-12-01T12:43:58.000Z

Hi @publicarray, @timrettop , thanks for the updates, i appreciate this! Keep up the good work guys!

Answer 88 · 2021-12-10T09:58:20.000Z

Literally, I would throw some money to someone who will complete the NZBGet process. It has value enough to me.

Answer 89 · 2021-12-17T06:30:35.000Z

Any update on supporting dnscrypt-proxy on DSM 7?

Answer 90 · 2021-12-17T07:00:24.000Z

Any update on supporting dnscrypt-proxy on DSM 7?

dnscrypt-proxy will need a new approach for DSM 7 as it is not possible to serve privileged ports (53) without root access.

Answer 91 · 2021-12-17T20:32:27.000Z

Any update on supporting dnscrypt-proxy on DSM 7?

dnscrypt-proxy will need a new approach for DSM 7 as it is not possible to serve privileged ports (53) without root access.

Yes I've started doing this and have created a beta release here:
https://github.com/publicarray/spksrc/releases/tag/dnscrypt-proxy-2.0.45_1

Answer 92 · 2021-12-23T14:57:13.000Z

I am a bit surprised, that rsnapshot is still open: I thought this in my opinion best backup solution would be used by some more people. The binaries from the DSM6 package are still working under DSM7, so for me it looks like the issue is only the package itself, which has to be reworked?

Answer 93 · 2021-12-23T17:06:47.000Z

I am a bit surprised, that rsnapshot is still open: I thought this in my opinion best backup solution would be used by some more people. The binaries from the DSM6 package are still working under DSM7, so for me it looks like the issue is only the package itself, which has to be reworked?

@eddie8de you're right, rsnapshot is not a big deal to update for DSM 7. Can't remember what the reason was to mark does not build in the table above.
This is now WIP in #5019.
I would like to move the config file from etc to var folder to benefit of the backup/restore automatism in our framework. If you don't object?

Answer 94 · 2021-12-23T17:30:27.000Z

@eddie8de you're right, rsnapshot is not a big deal to update for DSM 7. Can't remember what the reason was to mark does not build in the table above. This is now WIP in #5019. I would like to move the config file from etc to var folder to benefit of the backup/restore automatism in our framework. If you don't object?

Thank you so much for the fast reply. If somewhere in early 2022 an installation would be possible, it would safe me lot of time, cause I want to set up two new NAS with rsnapshot.
For me, I do not mind where the config file is located, and I cannot think of a reason why other people could bother.

Answer 95 · 2022-01-27T21:28:10.000Z

Hi community!
Can anyone have time to publish new package update in synocommunity ?
https://packages.synocommunity.com/

Answer 96 · 2022-01-27T21:31:09.000Z

Hi community!

Can anyone have time to publish new package update in synocommunity ?

https://packages.synocommunity.com/

Can be more specific? What package do you require?

Answer 97 · 2022-01-27T21:48:32.000Z

My HomeAssistant is still in version 2021.9.7
I have a DS218play (no docker), so I only use synocommunity system to update it
Thanks for support ☺️

Answer 98 · 2022-01-27T22:13:49.000Z

@Dragoniacs16 in #4969 I gave some hints why it will take some time for the next updated homeassistant package.
Currently I tend to say: do not expect more than two updates / year.

Answer 99 · 2022-01-28T08:10:28.000Z

Ok, no problem, I'll wait.
Thanks for not forgetting syno package users 😁

Answer 100 · 2022-08-12T11:42:18.000Z

Is there an overview which packages are ready for DSM 7.1 ? I'm afraid my Setup beaks after updating to DSM 7.1. I'm running all SynoCLI, Python 3.10, zsh and git.

Edit: I’ve successfully upgrade to 7.1 without any problems.