Our current scriptlets for systemd result in an unacceptable upgrade case. Specifically, it reverts all services to their default enabled/disabled status. We should allow packagers to include scripts that keep the user-selected auto-start between upgrades.
For example, HTTPD does not start automatically when installed (because its default configuration is not necessarily useful). However, once it's been set up by a user and selected for autostart with ckconfig (for example), we should not be disabling it on upgrade.
The reverse might also be true. In a hardened environment, a service that is configured for auto-start by default might be disabled for security reasons. Turning it back on by default during an upgrade could then be viewed as a security vulnerability.
I think the guidelines need to be relaxed so that scriptlets like the following could be added:
%triggerun -- sssd < %{version}-%{release} if /sbin/chkconfig --level 3 sssd ; then /bin/systemctl --no-reload enable sssd.service >/dev/null 2>&1 || : fi
if /sbin/chkconfig --level 5 sssd ; then /bin/systemctl --no-reload enable sssd.service >/dev/null 2>&1 || : fi
/sbin/chkconfig --del sssd >/dev/null 2>&1 || :
In this case, we check to see if the sssd service was running in runlevel three or five, and if so we enable it on upgrade. (Yes, I'm aware that this is currently in violation of packaging standards, but SSSD was converted prior to the standard being decided upon).
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 09/20/2011 09:04 AM, Stephen Gallagher wrote:
Our current scriptlets for systemd result in an unacceptable upgrade case. Specifically, it reverts all services to their default enabled/disabled status. We should allow packagers to include scripts that keep the user-selected auto-start between upgrades.
As stated before, we argued about this, but this is what we had to factor in:
* Lots of packages had services that were enabled by default, but should not have been * Certain services used to need to be enabled by default in a pre-systemd universe, but no longer need to be. * There is no way to differentiate between a service which is on because it was set that way by the package and on because the user made a conscious choice to set it that way. * Runlevels and ordering in the SysV universe don't have exact mappings in the systemd model, and we have to assume that it is possible that both have been customized by the user.
So, for Fedora 16, we decided to force a clean reset of the proper defaults for services, as decided by FESCo, and:
* Save a copy of the runlevel and priority status of the service being migrated to systemd * Provide a simple tool (/usr/bin/systemd-sysv-convert in systemd-sysv, 150 lines of python) that can take the saved service status and make an attempt to convert it to systemd, so that if the user wishes to view or restore the same settings they had prior to the upgrade, they can do so.
I'm not terribly interested in revisiting this painful discussion, and to be honest, just want to move past it.
~tom
== Fedora Project
packaging@lists.fedoraproject.org
-
Stephen Gallagher -
Tom Callaway