Andrei Borzenkov wrote:

В Tue, 11 Nov 2014 16:37:32 +0100 Stanislav Brabec пишет:

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

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

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

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

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

Le jeudi 13 novembre 2014 à 10:54 +0100, Johannes Meixner a écrit :

Hello,

On Nov 12 18:58 Stanislav Brabec wrote (excerpt):

...

https://bugzilla.suse.com/show_bug.cgi?id=843526

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

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 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, 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

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

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

* Ludwig Nussel [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

* Andrei Borzenkov [2014-11-20 12:25]:

On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster wrote:

...

* Ludwig Nussel [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

* Andrei Borzenkov [2014-11-20 12:46]:

On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster wrote:

...

* Andrei Borzenkov [2014-11-20 12:25]:

...

On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster wrote:

...

* Ludwig Nussel [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

* Andrei Borzenkov [2014-11-20 13:28]:

On Thu, Nov 20, 2014 at 2:50 PM, Guido Berhoerster wrote:

...

* Andrei Borzenkov [2014-11-20 12:46]:

...

On Thu, Nov 20, 2014 at 2:32 PM, Guido Berhoerster wrote:

...

* Andrei Borzenkov [2014-11-20 12:25]:

...

On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster wrote:

...

* Ludwig Nussel [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

Guido Berhoerster wrote:

* Andrei Borzenkov [2014-11-20 12:25]:

...

On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster wrote:

...

* Ludwig Nussel [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 schrieb:

Guido Berhoerster wrote:

...

* Andrei Borzenkov [2014-11-20 12:25]:

...

On Thu, Nov 20, 2014 at 1:38 PM, Guido Berhoerster wrote:

...

* Ludwig Nussel [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

Guido Berhoerster schrieb:

* Ludwig Nussel [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

Guido Berhoerster schrieb:

* Ludwig Nussel [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

* Christian Boltz [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

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

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