[opensuse-packaging] systemd service presets: branding files or packages?
I would like to open a discussion about use of systemd presets while packaging. Systemd preset files are preferred way how packages set the default state of services. Preset files are located in /usr/lib/systemd/system-preset directory. %service_add_post is aware of presets, and if the package adds systemd service together with presets, %service_add_post performs one-time set to the preset default state. Current policy is simple: All presets belongs to: systemd-presets-branding-{product} /usr/lib/systemd/system-preset/90-default-openSUSE.preset and the default to disable all other: /usr/lib/systemd/system-preset/99-default-disable.preset It makes a lot of sense for packages with optional services, that should be always on, like apache, network servers etc. But I think that makes less sense for packages that are optional to install, but it they are installed and not active, they are broken. Especially if they are socket activated, the standby state means no more than one socket opened by systemd. I have two examples from last weeks: uuidd: Optional socket activated util-linux daemon providing support for UUIDs. pcsc-lite pcscd: Smart Card daemon that is socket activated whenever application attempts to use Smart Card PC/SC API. If it is not enabled, Smart Card access does not work. Note that it has a security implication: Each package that installs default-on preset, should be audited by security team. Security team would need to watch the whole directory, not only a branding file. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
В Tue, 11 Nov 2014 16:37:32 +0100 Stanislav Brabec <sbrabec@suse.cz> пишет:
I would like to open a discussion about use of systemd presets while packaging.
Systemd preset files are preferred way how packages set the default state of services. Preset files are located in /usr/lib/systemd/system-preset directory. %service_add_post is aware of presets, and if the package adds systemd service together with presets, %service_add_post performs one-time set to the preset default state.
Current policy is simple: All presets belongs to: systemd-presets-branding-{product} /usr/lib/systemd/system-preset/90-default-openSUSE.preset and the default to disable all other: /usr/lib/systemd/system-preset/99-default-disable.preset
It makes a lot of sense for packages with optional services, that should be always on, like apache, network servers etc.
But I think that makes less sense for packages that are optional to install, but it they are installed and not active, they are broken. Especially if they are socket activated, the standby state means no more than one socket opened by systemd.
I think the while point of presets is that they are external policy provided by independent authority. If package is going to install preset that always enables some service, package can just as well simply enable it in postinstall script, no?
I have two examples from last weeks: uuidd: Optional socket activated util-linux daemon providing support for UUIDs. pcsc-lite pcscd: Smart Card daemon that is socket activated whenever application attempts to use Smart Card PC/SC API. If it is not enabled, Smart Card access does not work.
Note that it has a security implication: Each package that installs default-on preset, should be audited by security team. Security team would need to watch the whole directory, not only a branding file.
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Andrei Borzenkov wrote:
В Tue, 11 Nov 2014 16:37:32 +0100 Stanislav Brabec <sbrabec@suse.cz> пишет:
I think the while point of presets is that they are external policy provided by independent authority. If package is going to install preset that always enables some service, package can just as well simply enable it in postinstall script, no?
Preset is a higher level of systemd setup: 1. systemctl start/stop sets the current service state 2. systemctl enable/disable sets the service state to active/inactive state. 3. systemctl preset sets the service to the proposed default state. Using systemctl enable should be reserved to system admin. It is should not be used in package post scripts, as it overwrites state defined by the system admin. Package should use presets. Then %service_add_post is sufficient. It does one time set to preset, and on the next update, service will stay in the previous state, i. e. if system admin decides to turn off the service, the customization will be kept. Ideally, all services should have a reasonable preset. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
The goal of presets is as an admin to define a policy on which services should be enabled and which not. I do not see how your proposal will allow me to do this, Andreas -- Andreas Jaeger aj@{suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF:Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB 21284 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Nov 12 08:40 Andreas Jaeger wrote (excerpt):
The goal of presets is as an admin to define a policy on which services should be enabled and which not.
What exactly do you mean with "presets" here? As far as I understand it via the systemd-presets-branding-* RPMs it is the distributor who defines which services should by default be enabled and which not. As far as I understand it is is impossible to make a RPM package with packaged systemd presets where it is the admin who defines it. When making a RPM package the one who makes the package defines it. Accordingly - as far as I understand it - Stanislav Brabec is talking here on the opensuse-packaging list about how openSUSE defines it. Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Johannes Meixner wrote:
Hello,
On Nov 12 08:40 Andreas Jaeger wrote (excerpt):
The goal of presets is as an admin to define a policy on which services should be enabled and which not.
What exactly do you mean with "presets" here?
If it does not make sense to install the package but keep it disabled (e. g. uuidd), I propose to create preset file /usr/lib/systemd/system-preset/50-uuidd.preset containing preset for the particular package instead of requesting of adding a line to the the central /usr/lib/systemd/system-preset/90-default-openSUSE.preset
As far as I understand it via the systemd-presets-branding-* RPMs it is the distributor who defines which services should by default be enabled and which not.
I agree for packages, which make sense to install but still disable the service and packages, which need service configuration before turning on the service. But there are packages that are completely optional, but if they are installed and service is left disabled, the packages are simply broken (e. g. uuidd, pcsc-lite). In such case, distributor has much easier option to disable them: Don't install them.
As far as I understand it is is impossible to make a RPM package with packaged systemd presets where it is the admin who defines it. When making a RPM package the one who makes the package defines it.
Admin should use "systemctl enable/disable" to enable/disable service. "systemctl preset" sets the service to the default (rpm/distribution author) defined state. (But admin still can install own system-preset file with a high priority and then use customized behavior of "sytemctl preset".)
Accordingly - as far as I understand it - Stanislav Brabec is talking here on the opensuse-packaging list about how openSUSE defines it.
Yes, my concern is just about packaging of preset files, not about presets itself: I am sending it to opensuse-packaging to find an answer do question: Does it make sense to add preset file for every particular optional package to systemd-presets-branding-{anything}? Isn't it sometimes better to add preset file to particular package? -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Andreas Jaeger wrote:
The goal of presets is as an admin to define a policy on which services should be enabled and which not.
I do not see how your proposal will allow me to do this,
My proposal will not change things for admins. Things would only change for branding package authors. Branding authors will not need to change branding file whenever any such service appears and is approved by security team. I propose to move preset files from branding package to service providing package only for presets that don't make sense to change. Installing pcsc-lite package but disabling by default it does not make sense, as it makes to impossible to use the package. Installing uuidd package but disabling by default it does not make sense, as it makes to impossible to use the package. These services don't need any configuration. Both were audited as secure to be started by default. Now they will not be started by default, but just socket activated. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Nov 11, 2014 at 04:37:32PM +0100, Stanislav Brabec wrote:
I would like to open a discussion about use of systemd presets while packaging.
Systemd preset files are preferred way how packages set the default state of services. Preset files are located in /usr/lib/systemd/system-preset directory. %service_add_post is aware of presets, and if the package adds systemd service together with presets, %service_add_post performs one-time set to the preset default state.
Current policy is simple: All presets belongs to: systemd-presets-branding-{product} /usr/lib/systemd/system-preset/90-default-openSUSE.preset and the default to disable all other: /usr/lib/systemd/system-preset/99-default-disable.preset
It makes a lot of sense for packages with optional services, that should be always on, like apache, network servers etc.
But I think that makes less sense for packages that are optional to install, but it they are installed and not active, they are broken. Especially if they are socket activated, the standby state means no more than one socket opened by systemd.
I have two examples from last weeks: uuidd: Optional socket activated util-linux daemon providing support for UUIDs. pcsc-lite pcscd: Smart Card daemon that is socket activated whenever application attempts to use Smart Card PC/SC API. If it is not enabled, Smart Card access does not work.
Note that it has a security implication: Each package that installs default-on preset, should be audited by security team. Security team would need to watch the whole directory, not only a branding file.
As you noticed, security likes a tight control over presets on systemd services/sockets/etc. The security team (well basically me) are(is) maintaining the systemd-presets-branding-openSUSE (and -SLE) packages. And these are the system defaults. In general we take all requests and also usually allow them, so its not needed to have packages do it seperately. You mention apache etc, but these are usually enabled either by the admin or someone else. So I would like not to have specific presets in packages, but track them all in the branding-presets-. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Marcus Meissner Wrote:
So I would like not to have specific presets in packages, but track them all in the branding-presets-.
I understand your concern. There is a question, whether branding-presets- should be considered as presets approved by security team for particular product or a standard branding package, which is expected to be modified by branders. There are still ways to force-enable services in packages, even without presets and review. grep -l "systemctl.*enable" */*.spec on the current Factory shows these candidates: bluez/bluez.spec cups/cups.spec ipmiutil/ipmiutil.spec ModemManager/ModemManager.spec NetworkManager/NetworkManager.spec openldap2/openldap2-client.spec openldap2/openldap2.spec openvpn/openvpn.spec rsyslog/rsyslog.spec sendmail/sendmail.spec spice-vdagent/spice-vdagent.spec syslogd/syslogd.spec syslog-ng/syslog-ng.spec systemd/systemd-mini.spec systemd/systemd.spec sysvinit/powerd.spec wicked/wicked.spec xen/xen.spec -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Nov 12 17:54 Stanislav Brabec wrote (excerpt):
grep -l "systemctl.*enable" */*.spec on the current Factory shows these candidates:
cups/cups.spec
This one is a false positive: ------------------------------------------------------------------------ $ osc cat openSUSE:Factory cups cups.spec | grep -A1 "systemctl.*enable" if systemctl --quiet is-enabled cups.service then # (without "|| :" build fails with ... systemctl --quiet reenable cups.service || : fi ------------------------------------------------------------------------ Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Johannes Meixner wrote:
cups/cups.spec
This one is a false positive:
Yes, it was a quick search over all packages. Also openldap seems to be false positive: They use enable for smart migration from sysv init scripts. But for example xen and ModemManager are true positives. wicked: https://bugzilla.suse.com/show_bug.cgi?id=843526 and my comment in this thread dated Wed, 12 Nov 2014 18:47:43 +0100. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Nov 12 18:58 Stanislav Brabec wrote (excerpt):
https://bugzilla.opensuse.org/show_bug.cgi?id=843526#c1 ----------------------------------------------------------------------- you can't use presets since they don't apply on for upgrade, only for new package installation (and it is not flexible enough for wha you want, I think). you will probably need to handle the migration on your own, with explicit systemctl enable calls. ----------------------------------------------------------------------- Good grief! This means the systemd-presets-branding-* package is curently basically useless because a package must of course also work in case of updates. Perhaps the systemd-presets-branding-* package needs RPM trigger scripts that get triggered whan one of the other packages for which systemd-presets-branding-* provides presets gets installed/removed/updated? Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Le jeudi 13 novembre 2014 à 10:54 +0100, Johannes Meixner a écrit :
Hello,
On Nov 12 18:58 Stanislav Brabec wrote (excerpt):
https://bugzilla.opensuse.org/show_bug.cgi?id=843526#c1 ----------------------------------------------------------------------- you can't use presets since they don't apply on for upgrade, only for new package installation (and it is not flexible enough for wha you want, I think).
you will probably need to handle the migration on your own, with explicit systemctl enable calls. -----------------------------------------------------------------------
Good grief! This means the systemd-presets-branding-* package is curently basically useless because a package must of course also work in case of updates.
No, it isn't. You want presets to do something different that what they are. Presets are doing exactly what their name imply: it is a preset, ie a default value. You obviously don't want this default value to be applied when packages are updated, overriding sysadmin changes. Case not handled currently in presets is when a preset file is introduced for a particular package which is already installed. People versatile in RPM and bash are welcome to help to fix that (filetriggers like in Mageia RPM would be great to automate that but AFAIK, they haven't landed in upstream RPM yet) General upgrade case from sysvinit to systemd service is properly handled (sysvinit initscript status is applied instead of preset in the initial migration). -- Frederic Crozat Project Manager Enterprise Desktop SUSE -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello On Nov 13 11:18 Frederic Crozat wrote (excerpt):
You obviously don't want this default value to be applied when packages are updated, overriding sysadmin changes.
Of course I do not want overriding sysadmin changes for systemd units that still exist after package update.
Case not handled currently in presets is when a preset file is introduced for a particular package which is already installed.
This is what I had actually meant. I want presets be applied for systemd units that are new in case of a package update. And perhaps also for systemd units that are removed in case of a package update something may have to be done: Assume the old package provided foo.service and foo.socket. In systemd-presets-branding-* only foo.socket was enabled but foo.service was not enabled (I don't know if this makes sense in practice - it is only meant as an example here). Assume the new package only provides foo.service. Then it seems reasonable to change the preset for foo.service to be enabled so that the admin could do "systemctl preset foo" and have the service foo still enabled.
People versatile in RPM and bash are welcome to help to fix that (filetriggers like in Mageia RPM would be great to automate that but AFAIK, they haven't landed in upstream RPM yet)
Currently (as time permits - i.e. when there are no SLE issues with higher priority) I am working on a generic %posttrans RPM scriptlet to clean up obsoleted systemd units and refresh still valid units in case of a package update. But it is really complicated (as always with systemd), see https://bugzilla.opensuse.org/show_bug.cgi?id=904215 If and only if I had implemented this successfully, I am interested to work together with other people versatile in systemd to implement basically the same functionality for systemd-presets-branding-* (i.e. clean up stuff after package updates) or alternatively to implement a generic RPM macro that is run in %posttrans that cleans up systemd stuff after package updates. Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Johannes Meixner wrote:
Assume the old package provided foo.service and foo.socket. In systemd-presets-branding-* only foo.socket was enabled but foo.service was not enabled (I don't know if this makes sense in practice - it is only meant as an example here). Assume the new package only provides foo.service. Then it seems reasonable to change the preset for foo.service to be enabled so that the admin could do "systemctl preset foo" and have the service foo still enabled.
I found an easy way to work-around this limitation and perform one-time initialization when preset is added to file. See my mail in this thread dated Tue, 11 Nov 2014 22:32:32 +0100 I think that it is possible to invent something similar in the branding file: %pre: Check, whether old branding contains preset (or branding contains old version of preset). If not, remember it by touch something un /run. %post: After installation of new preset, call one-time presetting of already existing package. You can check, whether user diverged from the default, and provide smart upgrade path. The package %service_add_post will never do presetting on upgrade. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Nov 12, Stanislav Brabec wrote:
But for example xen and ModemManager are true positives.
So how exactly should xen deal with that? It is expected that xencommons gets enabled during package install. But if xencommons.service is disabled it should remain disabled during package upgrade. Right now the code looks like this: ... %post tools %if %{?with_systemd}0 %{fillup_and_insserv -i -y -n xencommons xencommons} /bin/systemctl enable xencommons.service %else %{fillup_and_insserv -y -n xencommons xencommons} %endif ... Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Dec 04, 2014 at 01:18:57PM +0100, Olaf Hering wrote:
On Wed, Nov 12, Stanislav Brabec wrote:
But for example xen and ModemManager are true positives.
So how exactly should xen deal with that? It is expected that xencommons gets enabled during package install. But if xencommons.service is disabled it should remain disabled during package upgrade.
Right now the code looks like this:
... %post tools %if %{?with_systemd}0 %{fillup_and_insserv -i -y -n xencommons xencommons} /bin/systemctl enable xencommons.service %else %{fillup_and_insserv -y -n xencommons xencommons} %endif ...
xencommons.service would need to be added to systemd-presets-branding-SLE/openSUSE Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Dec 04, Marcus Meissner wrote:
xencommons.service would need to be added to systemd-presets-branding-SLE/openSUSE
Does that enable it with 'Install Hypervisor and Tools' via YaST or 'zypper in xen-tools xen'? I think it does not. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Dec 04, 2014 at 02:42:47PM +0100, Olaf Hering wrote:
On Thu, Dec 04, Marcus Meissner wrote:
xencommons.service would need to be added to systemd-presets-branding-SLE/openSUSE
Does that enable it with 'Install Hypervisor and Tools' via YaST or 'zypper in xen-tools xen'? I think it does not.
If you fix the following RPMLINT warnings the presets will start to work better at least. (presets only work if all 4 of the %service_add/del/_section are present.) Ciao, Marcus osc bl standard x86_64|grep systemd-service-without [ 946s] xen-xend-tools.x86_64: W: systemd-service-without-service_del_preun xend.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_del_preun xen-watchdog.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_del_preun xendomains.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_del_preun xencommons.service [ 946s] xen-xend-tools.x86_64: W: systemd-service-without-service_del_postun xend.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_del_postun xen-watchdog.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_del_postun xendomains.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_del_postun xencommons.service [ 946s] xen-xend-tools.x86_64: W: systemd-service-without-service_add_pre xend.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_add_pre xen-watchdog.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_add_pre xendomains.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_add_pre xencommons.service [ 946s] xen-xend-tools.x86_64: W: systemd-service-without-service_add_post xend.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_add_post xen-watchdog.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_add_post xendomains.service [ 946s] xen-tools.x86_64: W: systemd-service-without-service_add_post xencommons.service [ 521s] xen-xend-tools.x86_64: W: systemd-service-without-service_del_preun xend.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_del_preun xen-watchdog.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_del_preun xendomains.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_del_preun xencommons.service [ 521s] xen-xend-tools.x86_64: W: systemd-service-without-service_del_postun xend.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_del_postun xen-watchdog.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_del_postun xendomains.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_del_postun xencommons.service [ 521s] xen-xend-tools.x86_64: W: systemd-service-without-service_add_pre xend.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_add_pre xen-watchdog.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_add_pre xendomains.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_add_pre xencommons.service [ 521s] xen-xend-tools.x86_64: W: systemd-service-without-service_add_post xend.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_add_post xen-watchdog.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_add_post xendomains.service [ 521s] xen-tools.x86_64: W: systemd-service-without-service_add_post xencommons.service Ciao, Marcus -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, Nov 12, Stanislav Brabec wrote:
There are still ways to force-enable services in packages, even without presets and review.
How many of them are buggy, and should be solved in some other way? For example whenever I disable xen to use my private copy it will be reenabled during the next update of the xen-tools package. Maybe the concern with doing it that way was that presets do not trigger if the packages are installed (not upgraded) later. Olaf -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Olaf Hering wrote:
On Wed, Nov 12, Stanislav Brabec wrote:
There are still ways to force-enable services in packages, even without presets and review.
How many of them are buggy, and should be solved in some other way? For example whenever I disable xen to use my private copy it will be reenabled during the next update of the xen-tools package.
Maybe the concern with doing it that way was that presets do not trigger if the packages are installed (not upgraded) later.
If packages use presets and %service_add_pre/post, then such incorrect behavior does not happen. If preset defines default-on, service is enabled just once on the first installation and never more. If packages do that by systemctl [--force] enable, they not only obey security review, but package maintainers also have to handle upgrade process on their own. And most of them don't do it correctly. Note: %service_add_post works correctly only if the preset is introduced together with the service scriptlets. There are some tricks, how to do it better in other situations: Migration from sysv init files to systemd services (from openldap2.spec): %pre if /usr/bin/chkconfig {initscript} 2>&1 | grep -q on; then touch /run/enable_{service}_service fi %service_add_pre {service}.service %post %service_add_post {service}.service if [ -f /run/enable_{service}_service ]; then /usr/bin/systemctl --quiet enable {service} rm /run/enable_{service}_service fi Presets added later than services (from util-linux.spec, works only if the preset is part of the package): %pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi %post %service_add_post {service}.service -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stanislav Brabec schrieb:
Olaf Hering wrote:
On Wed, Nov 12, Stanislav Brabec wrote:
There are still ways to force-enable services in packages, even without presets and review.
How many of them are buggy, and should be solved in some other way? For example whenever I disable xen to use my private copy it will be reenabled during the next update of the xen-tools package.
Maybe the concern with doing it that way was that presets do not trigger if the packages are installed (not upgraded) later.
If packages use presets and %service_add_pre/post, then such incorrect behavior does not happen. If preset defines default-on, service is enabled just once on the first installation and never more.
If packages do that by systemctl [--force] enable, they not only obey security review, but package maintainers also have to handle upgrade process on their own. And most of them don't do it correctly. [...] Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset? I guess that in such case it is initialized to a state defined by the presets in time of migration, i. e. most probably value defined in 99-default-disable.preset. My test with 13.2 failed to auto-migrate uuidd. The migration process does not discriminate between implicit default-off preset and the explicit preset in 90-default-openSUSE.preset. For %service_add_pre, the migration was already done in past, and no change is needed. And because the migration was done in time, where presets were set incorrectly, it remains broken. I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK". So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369 -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default, hence my question above. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
>Presets added later than services (from util-linux.spec, works only if >the preset is part of the package): > >%pre >%service_add_pre {service}.service >if [ $1 -gt 1 ] ; then > if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then > echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade > fi >fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default,
Really? Then why I have to do chkconfig boot.multipath on on every SLES installation? :) I believe boot scripts were handled just like other run levels and could be disabled and enabled as needed. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:46]:
On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote: >Stanislav Brabec schrieb:
>>Presets added later than services (from util-linux.spec, works only if >>the preset is part of the package): >> >>%pre >>%service_add_pre {service}.service >>if [ $1 -gt 1 ] ; then >> if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then >> echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade >> fi >>fi > >That is no longer necessary. %service_add_pre does that itself since >January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default,
Really? Then why I have to do
chkconfig boot.multipath on
on every SLES installation? :)
I believe boot scripts were handled just like other run levels and could be disabled and enabled as needed.
They are not even listed by chkconfig. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Thu, Nov 20, 2014 at 2:50 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:46]:
On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb: >Ludwig Nussel wrote: >>Stanislav Brabec schrieb: > >>>Presets added later than services (from util-linux.spec, works only if >>>the preset is part of the package): >>> >>>%pre >>>%service_add_pre {service}.service >>>if [ $1 -gt 1 ] ; then >>> if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then >>> echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade >>> fi >>>fi >> >>That is no longer necessary. %service_add_pre does that itself since >>January. > >Are you sure that it helps in situation, where service was introduced in >past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
>[...] >I even don't see a reasonable fully automatic solution. The process >cannot discriminate between "no preset is present because maintainer >forgot to define it" and "no preset is present because the implicit >default off is OK". > >So I think that any later preset and systemd-presets-branding-* change >need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default,
Really? Then why I have to do
chkconfig boot.multipath on
on every SLES installation? :)
I believe boot scripts were handled just like other run levels and could be disabled and enabled as needed.
They are not even listed by chkconfig.
boot.apparmor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.cgroup 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cleanup 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.clock 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on S:on boot.compliance 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.crypto 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.crypto-early 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cycle 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.debugfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.device-mapper 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.dmraid 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.efivars 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.fuse 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ipconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.klog 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ldconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.loadmodules 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localnet 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.lvm 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.lvm_monitor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.md 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.multipath 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.open-iscsi 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.proc 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.quota 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.rootfsck 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.scpm 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.swap 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysctl 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev_retry 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 13:28]:
On Thu, Nov 20, 2014 at 2:50 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:46]:
On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]: > Stanislav Brabec schrieb: > >Ludwig Nussel wrote: > >>Stanislav Brabec schrieb: > > > >>>Presets added later than services (from util-linux.spec, works only if > >>>the preset is part of the package): > >>> > >>>%pre > >>>%service_add_pre {service}.service > >>>if [ $1 -gt 1 ] ; then > >>> if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then > >>> echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade > >>> fi > >>>fi > >> > >>That is no longer necessary. %service_add_pre does that itself since > >>January. > > > >Are you sure that it helps in situation, where service was introduced in > >past, and now we are introducing its preset? > > You are right. The macro only handles the case where a new service is > introduced. I agree that > > >[...] > >I even don't see a reasonable fully automatic solution. The process > >cannot discriminate between "no preset is present because maintainer > >forgot to define it" and "no preset is present because the implicit > >default off is OK". > > > >So I think that any later preset and systemd-presets-branding-* change > >need a special handling in scripts like the code above. > > Is it really worth the effort? We are talking about an optional package > here. So if the admin installed the package but did not enable it's > services it could be assumed that this is intentional. So even if the > default policy for the package changed to enable a service by default > now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default,
Really? Then why I have to do
chkconfig boot.multipath on
on every SLES installation? :)
I believe boot scripts were handled just like other run levels and could be disabled and enabled as needed.
They are not even listed by chkconfig.
boot.apparmor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.cgroup 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cleanup 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.clock 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on S:on boot.compliance 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.crypto 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.crypto-early 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cycle 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.debugfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.device-mapper 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.dmraid 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.efivars 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.fuse 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ipconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.klog 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ldconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.loadmodules 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localnet 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.lvm 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.lvm_monitor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.md 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.multipath 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.open-iscsi 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.proc 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.quota 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.rootfsck 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.scpm 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.swap 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysctl 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev_retry 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on
Not on openSUSE. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
В Thu, 20 Nov 2014 13:37:13 +0100 Guido Berhoerster <gber@opensuse.org> пишет:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 13:28]:
On Thu, Nov 20, 2014 at 2:50 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:46]:
On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote: > * Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]: >> Stanislav Brabec schrieb: >> >Ludwig Nussel wrote: >> >>Stanislav Brabec schrieb: >> > >> >>>Presets added later than services (from util-linux.spec, works only if >> >>>the preset is part of the package): >> >>> >> >>>%pre >> >>>%service_add_pre {service}.service >> >>>if [ $1 -gt 1 ] ; then >> >>> if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then >> >>> echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade >> >>> fi >> >>>fi >> >> >> >>That is no longer necessary. %service_add_pre does that itself since >> >>January. >> > >> >Are you sure that it helps in situation, where service was introduced in >> >past, and now we are introducing its preset? >> >> You are right. The macro only handles the case where a new service is >> introduced. I agree that >> >> >[...] >> >I even don't see a reasonable fully automatic solution. The process >> >cannot discriminate between "no preset is present because maintainer >> >forgot to define it" and "no preset is present because the implicit >> >default off is OK". >> > >> >So I think that any later preset and systemd-presets-branding-* change >> >need a special handling in scripts like the code above. >> >> Is it really worth the effort? We are talking about an optional package >> here. So if the admin installed the package but did not enable it's >> services it could be assumed that this is intentional. So even if the >> default policy for the package changed to enable a service by default >> now that doesn't mean it needs to enforce that on update. > > What about packages which provided boot.* sysvinit scripts > before, which are after conversion off by default? That seems > wrong and unexpected to me and I'd like what I should do in that > case. Concrete example: > https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default,
Really? Then why I have to do
chkconfig boot.multipath on
on every SLES installation? :)
I believe boot scripts were handled just like other run levels and could be disabled and enabled as needed.
They are not even listed by chkconfig.
boot.apparmor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.cgroup 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cleanup 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.clock 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on S:on boot.compliance 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.crypto 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.crypto-early 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.cycle 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.debugfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.device-mapper 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.dmraid 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.efivars 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.fuse 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ipconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.klog 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.ldconfig 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.loadmodules 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localfs 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.localnet 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.lvm 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.lvm_monitor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.md 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.multipath 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.open-iscsi 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.proc 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.quota 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.rootfsck 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.scpm 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.swap 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysctl 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.sysstat 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.udev_retry 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on
Not on openSUSE.
bor@opensuse:~/build/grub> cat /etc/os-release NAME=openSUSE VERSION="13.2 (Harlequin)" ... bor@opensuse:~/build/grub> chkconfig -A --list | fgrep boot. ... boot.apparmor 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.cycle 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on boot.kdump 0:off 1:off 2:off 3:off 4:off 5:off 6:off boot.udev 0:off 1:off 2:off 3:off 4:off 5:off 6:off B:on bor@opensuse:~/build/grub> -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Guido Berhoerster wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
Optional packages should be working properly out of the box. If the service is socket activated, its running needs no configuration, and it's secure to turn it on, we should do setup on packaging level. Especially if admin already enabled them, update should not break it. I think that these cases should be handled by packagers, not macro authors.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
I expect per/post macros to handle this properly (i.e. service replacing initscript must be left in the same state as initscript). If not, it sounds like a bug to me.
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default, hence my question above.
There are two tips how to handle special cases: Preset introduced later than the service, and you need one time preset: %pre ... if [ $1 -gt 1 ] ; then if ! {test if preset exists in file or branding file} ; then echo -n "" >/run/rpm-%{name}-update-{service name}-new-in-upgrade fi fi (Exact look of the check depends on the result of this discussion. If there will be decision to move all presets to the branding file, script should be modified.) Used in: util-linux/uuidd, pcsc-lite/pcscd Keeping service state during migration from sysv style init scripts: %pre if /usr/bin/chkconfig {initscript} 2>&1 | grep -q on; then touch /run/enable_{service}_service fi %service_add_pre {service}.service %post %service_add_post {service}.service if [ -f /run/enable_{service}_service ]; then /usr/bin/systemctl --quiet enable {service} rm /run/enable_{service}_service fi Used in: openldap2 -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Stanislav Brabec <sbrabec@suse.cz> [2014-11-21 16:24]:
Guido Berhoerster wrote:
I'm happy to fix it if someone tells me how that should be handled, https://en.opensuse.org/openSUSE:Systemd_packaging_guidelines says nothing about it. IMO former boot.* scripts should always be enabled by default, hence my question above.
There are two tips how to handle special cases:
Preset introduced later than the service, and you need one time preset:
%pre ... if [ $1 -gt 1 ] ; then if ! {test if preset exists in file or branding file} ; then echo -n "" >/run/rpm-%{name}-update-{service name}-new-in-upgrade fi fi
(Exact look of the check depends on the result of this discussion. If there will be decision to move all presets to the branding file, script should be modified.) Used in: util-linux/uuidd, pcsc-lite/pcscd
Keeping service state during migration from sysv style init scripts:
%pre if /usr/bin/chkconfig {initscript} 2>&1 | grep -q on; then touch /run/enable_{service}_service fi %service_add_pre {service}.service
%post %service_add_post {service}.service if [ -f /run/enable_{service}_service ]; then /usr/bin/systemctl --quiet enable {service} rm /run/enable_{service}_service fi
Used in: openldap2
Thanks, the latter looks like a suitable workaround until systemd-sysv-convert is fixed. -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stanislav Brabec schrieb:
Guido Berhoerster wrote:
* Andrei Borzenkov <arvidjaar@gmail.com> [2014-11-20 12:25]:
On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster <gber@opensuse.org> wrote:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
Optional packages should be working properly out of the box. If the service is socket activated, its running needs no configuration, and it's secure to turn it on, we should do setup on packaging level. Especially if admin already enabled them, update should not break it.
I agree but the way to turn on things is the preset mechanism.
I think that these cases should be handled by packagers, not macro authors.
rpm scripts are fragile by nature. The more we can do in a generic way where the individual packager doesn't have to care the better.
Preset introduced later than the service, and you need one time preset:
%pre ... if [ $1 -gt 1 ] ; then if ! {test if preset exists in file or branding file} ; then echo -n "" >/run/rpm-%{name}-update-{service name}-new-in-upgrade fi fi
See also the discussion on the systemd list: http://lists.freedesktop.org/archives/systemd-devel/2014-November/025363.htm... It's perfectly fine for us to change the default enable state of a service. However the package should not make guesses whether the previous (disabled) state was because of the distro default or a conscious decision of the admin. IOW don't do that :-)
Keeping service state during migration from sysv style init scripts: [...]
That's what systemd-sysv-convert is supposed to do automatically, right? If it doesn't do it for some reason it's most likely a bug that needs to be fixed in systemd-sysv-convert. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Nov 24, 2014 v at 14:08 Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Optional packages should be working properly out of the box. If the service is socket activated, its running needs no configuration, and it's secure to turn it on, we should do setup on packaging level. Especially if admin already enabled them, update should not break it.
I agree but the way to turn on things is the preset mechanism.
Yes. I still talk about presets. I am just thinking about the proper package for presets for packages, which are "apparently broken" if the preset is set differently. Does it make sense to add such packages to the distro-wide preset file, or does it make sense to distribute the preset together with such package?
I think that these cases should be handled by packagers, not macro authors.
rpm scripts are fragile by nature. The more we can do in a generic way where the individual packager doesn't have to care the better.
I agree. Standard macros handle standard upgrade process correctly (i. e. read sysvinit script state, remember it, use it in case of upgrade, otherwise use preset just for one time setup). But if macros were not used correctly, then The Bad Thing already happened. Macro authors cannot cover the whole range of Bad Things. Package maintainer should find a fix, as only the package maintainer knows, what was done incorrectly in the previous version.
Preset introduced later than the service, and you need one time preset:
%pre ... if [ $1 -gt 1 ] ; then if ! {test if preset exists in file or branding file} ; then echo -n "" >/run/rpm-%{name}-update-{service name}-new-in-upgrade fi fi
See also the discussion on the systemd list: http://lists.freedesktop.org/archives/systemd-devel/2014-November/025363.htm...
It's perfectly fine for us to change the default enable state of a service. However the package should not make guesses whether the previous (disabled) state was because of the distro default or a conscious decision of the admin. IOW don't do that :-)
Well. The Bad Thing already happened: Package was installed without any prefix, resulting in the bad default state for everybody who did the upgrade. Even worse, we cannot discriminate between conscious decision of the admin to stop the service and misbehavior introduced by the previous incorrect package upgrade. We have only two chances: - Keep it broken forever to everybody except conscious admins. - Ignore the current service state and set it to the default. The work around above does the second, and it does it only once while introducing preset and never more. IMHO it is the least pain possible.
That's what systemd-sysv-convert is supposed to do automatically, right? If it doesn't do it for some reason it's most likely a bug that needs to be fixed in systemd-sysv-convert.
I this case the script in the package is superfluous. -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Guido Berhoerster schrieb:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
That's an entirely different topic. sysv migration is handled by /usr/sbin/systemd-sysv-convert. If it doesn't handle boot.* scripts then that needs to be fixed there. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 14:12]:
Guido Berhoerster schrieb:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 11:20]:
Stanislav Brabec schrieb:
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Presets added later than services (from util-linux.spec, works only if the preset is part of the package):
%pre %service_add_pre {service}.service if [ $1 -gt 1 ] ; then if ! test -f /usr/lib/systemd/system-preset/{service preset file} ; then echo -n "" >/run/rpm-%{name}-update-{service}.socket-new-in-upgrade fi fi
That is no longer necessary. %service_add_pre does that itself since January.
Are you sure that it helps in situation, where service was introduced in past, and now we are introducing its preset?
You are right. The macro only handles the case where a new service is introduced. I agree that
[...] I even don't see a reasonable fully automatic solution. The process cannot discriminate between "no preset is present because maintainer forgot to define it" and "no preset is present because the implicit default off is OK".
So I think that any later preset and systemd-presets-branding-* change need a special handling in scripts like the code above.
Is it really worth the effort? We are talking about an optional package here. So if the admin installed the package but did not enable it's services it could be assumed that this is intentional. So even if the default policy for the package changed to enable a service by default now that doesn't mean it needs to enforce that on update.
What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
That's an entirely different topic. sysv migration is handled by /usr/sbin/systemd-sysv-convert. If it doesn't handle boot.* scripts then that needs to be fixed there.
Well from my testing it seems that previously run boot.* scripts are disabled after conversion. Is there anything else I'm supposed to do besides adding: %pre %service_add_pre storage-fixup.service %post %service_add_post storage-fixup.service %preun %service_del_preun storage-fixup.service %postun %service_del_postun storage-fixup.service Do I need to get this whitelisted in the systemd-presets-branding-* before doing the conversion or is this a bug in the systemd-sysv-convert script? -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Guido Berhoerster schrieb:
* Ludwig Nussel <ludwig.nussel@suse.de> [2014-11-20 14:12]:
Guido Berhoerster schrieb:
[...] What about packages which provided boot.* sysvinit scripts before, which are after conversion off by default? That seems wrong and unexpected to me and I'd like what I should do in that case. Concrete example: https://build.opensuse.org/request/show/262369
That's an entirely different topic. sysv migration is handled by /usr/sbin/systemd-sysv-convert. If it doesn't handle boot.* scripts then that needs to be fixed there.
Well from my testing it seems that previously run boot.* scripts are disabled after conversion. Is there anything else I'm supposed to do besides adding:
%pre %service_add_pre storage-fixup.service
%post %service_add_post storage-fixup.service
%preun %service_del_preun storage-fixup.service
%postun %service_del_postun storage-fixup.service
Do I need to get this whitelisted in the systemd-presets-branding-* before doing the conversion or is this a bug in the systemd-sysv-convert script?
Both. You need the service in the presets file for new installations and systemd-sysv-convert needs to be able to handle boot.* scripts for the update case. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, Am Donnerstag, 20. November 2014 schrieb Ludwig Nussel:
That's an entirely different topic. sysv migration is handled by /usr/sbin/systemd-sysv-convert. If it doesn't handle boot.* scripts then that needs to be fixed there.
I just had a look at systemd-sysv-convert. It doesn't contain "boot." anywhere - and all *.service files come without the "boot." prefix, so I'm quite sure boot.* initscripts can't be handled by systemd-sysv- convert. Do you want a bugreport for it? ;-) Regards, Christian Boltz --
Das geschulte Auge sieht '<IfDefine MAILMAN>', denkt 'grep APACHE_SERVER_FLAGS /etc/sysconfig/apache2' Können Augen denken? Ja, irgendwann schon. Es kann aber etliche Jahre dauern, bis es soweit ist. [> Andre Tann und Peter Poeml in suse-linux]
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
* Christian Boltz <opensuse@cboltz.de> [2014-11-20 18:42]:
Hello,
Am Donnerstag, 20. November 2014 schrieb Ludwig Nussel:
That's an entirely different topic. sysv migration is handled by /usr/sbin/systemd-sysv-convert. If it doesn't handle boot.* scripts then that needs to be fixed there.
I just had a look at systemd-sysv-convert. It doesn't contain "boot." anywhere - and all *.service files come without the "boot." prefix, so I'm quite sure boot.* initscripts can't be handled by systemd-sysv- convert.
Do you want a bugreport for it? ;-)
https://bugzilla.opensuse.org/show_bug.cgi?id=906448 -- Guido Berhoerster -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Wed, 12 Nov 2014 17:54, Stanislav Brabec wrote:
Marcus Meissner Wrote:
So I would like not to have specific presets in packages, but track them all in the branding-presets-.
I understand your concern.
There is a question, whether branding-presets- should be considered as presets approved by security team for particular product or a standard branding package, which is expected to be modified by branders.
There are still ways to force-enable services in packages, even without presets and review.
grep -l "systemctl.*enable" */*.spec on the current Factory shows these candidates:
bluez/bluez.spec cups/cups.spec ipmiutil/ipmiutil.spec ModemManager/ModemManager.spec NetworkManager/NetworkManager.spec openldap2/openldap2-client.spec openldap2/openldap2.spec openvpn/openvpn.spec rsyslog/rsyslog.spec sendmail/sendmail.spec spice-vdagent/spice-vdagent.spec syslogd/syslogd.spec syslog-ng/syslog-ng.spec systemd/systemd-mini.spec systemd/systemd.spec sysvinit/powerd.spec wicked/wicked.spec xen/xen.spec
IMHO it is remarkable that neither the 'big' databases (postgres/mysql) nor any of the httpd / imapd / popd / sshd have any of this 'special' handling in the spec file. I have little trouble with the thought of a 'enable'-preset for the syslog trio (rsyslog / syslogd / syslog-ng), but the hacks in the spec files smack of remnants of earlier time. Personally, I vote for 'no enabling' for any daemon that can not be used in a secure way out of the box without user input for the configuration. That means "NO to auto-enable" of any Imap / POP / mail daemon. Is openldap really usable without further config? And IMPI is a known security risk on its own. As it is, it is hair-rising in terms of security. - Yamaban. (who abhors wicked, it kills vlan setups) -- We, the under-trained, insufficient supplied, are called to work the miracles of tomorrow. Well, same s..t as yesterday then. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Yamaban wrote:
IMHO it is remarkable that neither the 'big' databases (postgres/mysql) nor any of the httpd / imapd / popd / sshd have any of this 'special' handling in the spec file.
It would be bad to enable them just after installation. Package maintainers are aware of it and they don't even attempt to start them by default.
I have little trouble with the thought of a 'enable'-preset for the syslog trio (rsyslog / syslogd / syslog-ng), but the hacks in the spec files smack of remnants of earlier time.
I think that it is OK to have it enabled by default. If packages behave correctly, they should respect your decision to keep services off on upgrade. Review is needed.
Personally, I vote for 'no enabling' for any daemon that can not be used in a secure way out of the box without user input for the configuration.
That means "NO to auto-enable" of any Imap / POP / mail daemon. Is openldap really usable without further config? And IMPI is a known security risk on its own.
Yes, it is the default fallback in openSUSE: /usr/lib/systemd/system-preset/99-default-disable.preset: disable * i. e. anything that is not listed in preset files is disable by default. (It works if package respects presets.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Nov 12 18:34 Yamaban wrote (excerpt):
it is remarkable that neither the 'big' databases (postgres/mysql) nor any of the httpd / imapd / popd / sshd have any of this 'special' handling in the spec file.
This is because normal users do not need that "big" stuff. And admins who install it are expected to know what to do. (sshd is perhaps an exception because normal users may need it but sshd is explicitly handled by YaST during installation.)
Personally, I vote for 'no enabling' for any daemon that can not be used in a secure way out of the box without user input for the configuration.
Personally I agree. But it does not work for normal (i.e. unexperieced) users who expect that after installing a software package that provides a service, that service of course "just works" out of the box (of course with basically all its fatures). As far as I understand Stanislav Brabec, this is what he likes to get solved, see his initial mail: --------------------------------------------------------------- for packages that are optional to install, but it they are installed and not active, they are broken. --------------------------------------------------------------- In short: How to package correctly a package that provides a service where the user experience would be "just broken crap" if the service would not be active after package install?
As it is, it is hair-rising in terms of security.
What do you expect when the decision under what circumstances what service should be enabled/disabled/started/stopped in what way is not implemented and maintained by a team who know what they do but is basically left to each individual package maintainer so that each individual package maintainer implements and maintains on his own what he honestly assumes is best. See also https://bugzilla.opensuse.org/show_bug.cgi?id=857372#c19 Kind Regards Johannes Meixner -- SUSE LINUX GmbH -- Maxfeldstrasse 5 -- 90409 Nuernberg -- Germany HRB 21284 (AG Nuernberg) GF: Jeff Hawn, Jennifer Guild, Felix Imendoerffer -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Stanislav Brabec schrieb:
Marcus Meissner Wrote:
So I would like not to have specific presets in packages, but track them all in the branding-presets-.
I understand your concern.
The central file has one big drawback, the ordering on update is undefined. Ie there is no guarantee that e.g. from one Factory snapshot to the next systemd-presets-branding gets upgraded first. If it's not first some newly added services may not get activated. Central tracking could be maintained by having an rpmlint check with a whitelist similar to what we have with users, dbus services etc. The effort for the packager to request inclusion in the whitelist would be similar as with the central file.
There are still ways to force-enable services in packages, even without presets and review.
grep -l "systemctl.*enable" */*.spec on the current Factory shows these candidates:
Unfortunately, yes. Some of them are legacy workarounds and some certainly need to be fixed. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE LINUX GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg) Maxfeldstraße 5; 90409 Nürnberg; Germany -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Ludwig Nussel wrote:
Stanislav Brabec schrieb:
Marcus Meissner Wrote:
So I would like not to have specific presets in packages, but track them all in the branding-presets-.
I understand your concern.
The central file has one big drawback, the ordering on update is undefined. Ie there is no guarantee that e.g. from one Factory snapshot to the next systemd-presets-branding gets upgraded first. If it's not first some newly added services may not get activated. Central tracking could be maintained by having an rpmlint check with a whitelist similar to what we have with users, dbus services etc. The effort for the packager to request inclusion in the whitelist would be similar as with the central file.
A long time ago I have been working on the branding specification:http://old-en.opensuse.org/SUSE_Package_Conventions/Branding In your case, the branding for package is optional, so only the branding package knows that it is essential for the package. You have to list all packages you are providing preset for in Supplements. (No packageand form is needed, as all systemd-enabled packages already depend on systemd.) zypper will do it correctly then. (I should probably migrate the document to the new Wiki.) -- Best Regards / S pozdravem, Stanislav Brabec software developer --------------------------------------------------------------------- SUSE LINUX, s. r. o. e-mail: sbrabec@suse.cz Lihovarská 1060/12 tel: +49 911 7405384547 190 00 Praha 9 fax: +420 284 084 001 Czech Republic http://www.suse.cz/ PGP: 830B 40D5 9E05 35D8 5E27 6FA3 717C 209F A04F CD76 -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
В Tue, 11 Nov 2014 16:37:32 +0100 Stanislav Brabec <sbrabec@suse.cz> пишет:
I would like to open a discussion about use of systemd presets while packaging.
You may also be interested in this one: "/usr vs /etc for default distro units enablement" http://lists.freedesktop.org/archives/systemd-devel/2014-November/025288.htm...
Systemd preset files are preferred way how packages set the default state of services. Preset files are located in /usr/lib/systemd/system-preset directory. %service_add_post is aware of presets, and if the package adds systemd service together with presets, %service_add_post performs one-time set to the preset default state.
Current policy is simple: All presets belongs to: systemd-presets-branding-{product} /usr/lib/systemd/system-preset/90-default-openSUSE.preset and the default to disable all other: /usr/lib/systemd/system-preset/99-default-disable.preset
It makes a lot of sense for packages with optional services, that should be always on, like apache, network servers etc.
But I think that makes less sense for packages that are optional to install, but it they are installed and not active, they are broken. Especially if they are socket activated, the standby state means no more than one socket opened by systemd.
I have two examples from last weeks: uuidd: Optional socket activated util-linux daemon providing support for UUIDs. pcsc-lite pcscd: Smart Card daemon that is socket activated whenever application attempts to use Smart Card PC/SC API. If it is not enabled, Smart Card access does not work.
Note that it has a security implication: Each package that installs default-on preset, should be audited by security team. Security team would need to watch the whole directory, not only a branding file.
-- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
participants (12)
-
Andreas Jaeger -
Andrei Borzenkov -
Christian Boltz -
Frederic Crozat -
Guido Berhoerster -
Johannes Meixner -
Ludwig Nussel -
Marcus Meissner -
Olaf Hering -
Olaf Hering -
Stanislav Brabec -
Yamaban