Package migration to generic service support

Support has only been testing on DSM 5 and 6 and relies on availability of

• synouser
• synogroup
• servicetool
• synoshare
• synoacltool

Please first refer to complete documentation.

Common actions

Discard INSTALL_DIR from Makefile as new default is now set to /var/packages/$(SPK_NAME)/target/ in mk/spk.directory.mk

If relevant, take benefit from group and share folder creation with SERVICE_WIZARD_GROUP and SERVICE_WIZARD_SHARE

If INSTALLER_SCRIPT contains other specific actions like configuration setup or link creation, move them to service_ACTION functions in SERVICE_SETUP script.

For non service application, add explicitely STARTABLE=no for proper Package Center status reporting.

Service application

If SSS_SCRIPT has specific code, try to move behaviour to service_prestart or service_poststop. If not possible, create package specific from mk/spksrc.service.start-stop-service.

Service user transition

If service user already exists in system, DSM will create an additional account with _PKGtime suffix which prevents installer to enlist it in group for share permissions.

Service user transistion with busybox user commands is obsolete, as we do not support dsm5 -> dsm6 migration anymore (since DSM7 beta, 2021).

For package transition, it is recommended to keep busybox dependency to properly clean "legacy" service account (without any prefix) thanks to following function in SERVICE_SETUP script file:

service_postinst ()
{
   # Discard legacy obsolete busybox user account
   BIN=${SYNOPKG_PKGDEST}/bin
   $BIN/busybox --install $BIN
   $BIN/delgroup "${USER}" "users" >> ${INST_LOG}
   $BIN/deluser "${USER}" >> ${INST_LOG}
}

Example with mosquitto update PR: #3025

Application storage locations

As a generic principal, application must produce files to user in DSM share folder configured thanks to SERVICE_WIZARD_SHARE wizard variable or SHARE_PATH in SERVICE_SETUP script.

By defaults, var folder is expected to be the only package location where application can write its log, configuration or any other content.

Generic installer handles backup and restore process for var content only. Other location content is discarded by DSM upgrade process which simply consists in an uninstall/install sequence with additional preupgrade and postupgrade scripts.

In case an application writes any persistent content out of var because locations cannot be configured, please select either of these options:

• Create target folder in var and use service_postinst to create symbolic links from original location

• Extend service_postinst function to set proper permission and backup/restore process with service_preupgrade and service_postupgrade to handle modified files out of var.