[opensuse-packaging] systemd presets vs. package install order
Hello, AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed. The result is: AppArmor doesn't get enabled :-( (see also https://bugzilla.opensuse.org/show_bug.cgi?id=931792 ) Can someone recommend a solution for this, or do I need to add a "systemctl enable apparmor.service" in %post? Regards, Christian Boltz -- Please note that unstable software can harm your computer, your cat and even your dog. [Ismail Dönmez in opensuse-factory] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2015-06-15 at 12:16 +0200, Christian Boltz wrote:
Hello,
AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
The result is: AppArmor doesn't get enabled :-( (see also https://bugzilla.opensuse.org/show_bug.cgi?id=931792 )
Can someone recommend a solution for this, or do I need to add a "systemctl enable apparmor.service" in %post?
I'd think that would be the wrong approach.... but that's my gut
feeling.
What about something like this in apparmor's post script:
%post
if [ "$1" = "1" ]; then # This is a fresh install, not an update...
systemctl preset apparmor.service # Set the service enable/disable as
per distribution preset
fi
This should be ess surprising in all cases, and if the preset ever
changes, this would not even need to be changed, and still do the right
thing on a new package install
Dominique
--
Dimstar / Dominique Leuenberger
On 15.06.2015 12:22, Dimstar / Dominique Leuenberger wrote:
On Mon, 2015-06-15 at 12:16 +0200, Christian Boltz wrote:
Hello,
AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
The result is: AppArmor doesn't get enabled :-( (see also https://bugzilla.opensuse.org/show_bug.cgi?id=931792 )
Can someone recommend a solution for this, or do I need to add a "systemctl enable apparmor.service" in %post?
I'd think that would be the wrong approach.... but that's my gut feeling.
What about something like this in apparmor's post script:
%post if [ "$1" = "1" ]; then # This is a fresh install, not an update... systemctl preset apparmor.service # Set the service enable/disable as per distribution preset fi
This should be ess surprising in all cases, and if the preset ever changes, this would not even need to be changed, and still do the right thing on a new package install
If we do this, what's the purpose of the systemd-presets-branding-openSUSE ? Shouldn't apparmor require it directly or indirectly? Greetings, Stephan -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2015-06-15 at 12:32 +0200, Stephan Kulow wrote:
On 15.06.2015 12:22, Dimstar / Dominique Leuenberger wrote:
On Mon, 2015-06-15 at 12:16 +0200, Christian Boltz wrote:
Hello,
AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
The result is: AppArmor doesn't get enabled :-( (see also https://bugzilla.opensuse.org/show_bug.cgi?id=931792 )
Can someone recommend a solution for this, or do I need to add a "systemctl enable apparmor.service" in %post?
I'd think that would be the wrong approach.... but that's my gut feeling.
What about something like this in apparmor's post script:
%post if [ "$1" = "1" ]; then # This is a fresh install, not an update... systemctl preset apparmor.service # Set the service enable/disable as per distribution preset fi
This should be ess surprising in all cases, and if the preset ever changes, this would not even need to be changed, and still do the right thing on a new package install
If we do this, what's the purpose of the systemd-presets-branding-openSUSE ? Shouldn't apparmor require it directly or indirectly?
Greetings, Stephan
The idea wouldn't work anyway - as apparmor is installed prior to the
preset package and thus can't read the default.
Probably the only way around this would be to require(post) the systemd
-preset-branding package, ensuring it is there during post script
execution of apparmor (and other packages installing service files).
Dominique
--
Dimstar / Dominique Leuenberger
Hello, thanks for all the responses! Am Montag, 15. Juni 2015 schrieb Dimstar / Dominique Leuenberger:
On Mon, 2015-06-15 at 12:32 +0200, Stephan Kulow wrote:
On 15.06.2015 12:22, Dimstar / Dominique Leuenberger wrote:
What about something like this in apparmor's post script:
%post if [ "$1" = "1" ]; then # This is a fresh install, not an update... systemctl preset apparmor.service # Set the service enable/disable as per distribution preset fi
This should be ess surprising in all cases, and if the preset ever changes, this would not even need to be changed, and still do the right thing on a new package install
For the records: The AppArmor package has to cover two usecases when it comes to preset (= enable) the service file: a) fresh install b) update from older version (from openSUSE <= 13.2), which didn't have a service file %service_add_pre apparmor.service (in %pre) and %service_add_post apparmor.service (in %post) are expected to cover both cases. Just to avoid the question: yes, those macro calls are in apparmor.spec. Hmm, I just wanted to say that %systemd_requires is also there and it actually is - but at a slightly wrong place, which means it won't be used for the apparmor-parser package :-/ (Argh, I should really double- and triple-check SRs, even (or especially?) if they come from systemd experts :-/ ) A package with %systemd_requires at the right place is in security:apparmor (and on its way to tumbleweed, SR 312168). An interesting question remains - %systemd_requires adds _unversioned_ Requires(post) etc. - how can I be sure that systemd and the preset package get updated before apparmor-parser gets updated? Unfortunately this can't be tested easily - I'd have to install a fresh tumbleweed (easy one - on a fresh install, even unversioned dependencies work) or even 13.2 and then update to tumbleweed :-/ (Did I miss an easy way to test?)
If we do this, what's the purpose of the systemd-presets-branding-openSUSE ? Shouldn't apparmor require it directly or indirectly?
The idea wouldn't work anyway - as apparmor is installed prior to the preset package and thus can't read the default.
Exactly this is the problem - and in this case the "*: disabled" default will be used. I'm seriously thinking about adding something like grep ' apparmor.service' /usr/lib/systemd/system-preset/*.preset >/dev/null || systemctl enable apparmor.service to make sure we get the expected result if the preset package wasn't updated yet, while honoring the preset if it is there. This doesn't cover all cases (especially tumbleweed -> newer tumbleweed [1]), but at least updates from <= 13.2. If someone has an idea how I can fix this for everybody, please speak up ;-) Regards, Christian Boltz [1] for a moment, I thought about checking the timestamp of /var/lib/systemd/migrated/apparmor (and ignoring it if it's older than the guaranteed-to-work %post script), but I'm not sure if this is the best idea. -- <jjohansen> I just need to stop responding to cboltz <cboltz> no, but you should come up with things I don't notice ;-) <jjohansen> something you don't notice? Isn't that asking a bit much :) <cboltz> no, that's called "high quality code" or at least "high quality well-hidden bug" *g,d&r* * jjohansen fails to believe there is such a thing as a well-hidden bug for cboltz [from #apparmor] -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Christian Boltz wrote:
[...] I'm seriously thinking about adding something like grep ' apparmor.service' /usr/lib/systemd/system-preset/*.preset >/dev/null || systemctl enable apparmor.service to make sure we get the expected result if the preset package wasn't updated yet, while honoring the preset if it is there. This doesn't cover all cases (especially tumbleweed -> newer tumbleweed [1]), but at least updates from <= 13.2.
If apparmor was previously installed but not enabled you cannot know whether the admin intentionally left it in that state. Maybe the admin tried to use apparmor, ran into problems and didn't enable it at boot. Therefore we cannot suddenly enable apparmor on upgrade just because we changed our minds and enable apparmor on new installs again now. If that is your scenario please do not add workarounds. The behavior is expected as is. The current presets method indeed has blind spots but I'm not sure you hit one in your case. Anyways, there was a discussion about that a few months ago: http://lists.opensuse.org/opensuse-packaging/2014-11/msg00061.html We also discussed some smarter presets handling offline but I'm not sure if Stanislav already had time to draft something. cu Ludwig -- (o_ Ludwig Nussel //\ V_/_ http://www.suse.de/ SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 16 09:25 Ludwig Nussel wrote (excerpt):
If apparmor was previously installed but not enabled you cannot know whether the admin intentionally left it in that state.
I think the actual issue is not what the old state was versus what the new default state will be but that one cannot know if our default is what the admin intentionally wants. If our distribution default for the previously installed package is known but the actual setings of the previously installed package differs, the admin must have intentionally changed it and the update of the package is not allowed to "simply change" the admin's intentional settings. Now one might think that when the actual settings of the previously installed package is our distribution default, the update of the package is allowed to change it to the distribution default of the new package. Example: When the service in the old package is disabled by default and its actual state is disabled, and the new default is enabled, then the update would be allowed to enable the service. But this is not true because the old package default could be what the admin intentionally wants. The following question might be off-topic but is still related: Is there a generic method in the running system to reset the systemd configuration of a service back to "factory defaults"? My usecase: For testing I run several "systemctl start/stop/enable/disable" commands and afterwards I would like to go back to the pristine state after a new system installation from scratch. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 16 10:44 Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-06-16 at 10:13 +0200, Johannes Meixner wrote:
Is there a generic method in the running system to reset the systemd configuration of a service back to "factory defaults"?
systemctl preset servicename
plus reboot? At least I don't know how to go back to "factory defaults" for the actually running services with reasonable effort (I do not want to manually check the dependencies betwenn running services). Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Tue, Jun 16, 2015 at 1:08 PM, Johannes Meixner
Hello,
On Jun 16 10:44 Dimstar / Dominique Leuenberger wrote:
On Tue, 2015-06-16 at 10:13 +0200, Johannes Meixner wrote:
Is there a generic method in the running system to reset the systemd configuration of a service back to "factory defaults"?
systemctl preset servicename
plus reboot?
At least I don't know how to go back to "factory defaults" for the actually running services with reasonable effort (I do not want to manually check the dependencies betwenn running services).
Current upstream systemctl got --now switch which disables *and* stops service (respectively enables and starts) in one invocation. Not sure if it is applies to "preset" but it is logical to expect and should not be hard to extend. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 16 13:21 Andrei Borzenkov wrote (excerpt):
On Tue, Jun 16, 2015 at 1:08 PM, Johannes Meixner
wrote: At least I don't know how to go back to "factory defaults" for the actually running services with reasonable effort (I do not want to manually check the dependencies betwenn running services).
Current upstream systemctl got --now switch which disables *and* stops service (respectively enables and starts) in one invocation.
One single service is no problem. If one is disabled by default one can simply stop that one. Dependencies between services seem to be a problem (at least as far as I currently understand systemd). When I had started service foo for a test and foo requires service bar, then bar will also become running and I do not want to manually check those dependencies to find out that stopping only foo would be insufficient to go back to the state before. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
В Tue, 16 Jun 2015 13:42:14 +0200 (CEST)
Johannes Meixner
Hello,
On Jun 16 13:21 Andrei Borzenkov wrote (excerpt):
On Tue, Jun 16, 2015 at 1:08 PM, Johannes Meixner
wrote: At least I don't know how to go back to "factory defaults" for the actually running services with reasonable effort (I do not want to manually check the dependencies betwenn running services).
Current upstream systemctl got --now switch which disables *and* stops service (respectively enables and starts) in one invocation.
One single service is no problem. If one is disabled by default one can simply stop that one.
Dependencies between services seem to be a problem (at least as far as I currently understand systemd).
When I had started service foo for a test and foo requires service bar, then bar will also become running and I do not want to manually check those dependencies to find out that stopping only foo would be insufficient to go back to the state before.
I do not think this is possible at all, the same reason - there is no way to know why service was started. I.e. even if service A Wants (or Requires) service B does not mean service B was started *because* service A was started. Hmm ... theoretically systemctl isolate multi-user.target (or whatever default target is) should have the same effect as reboot - it /should/ stop any service that would not be started if booting into this target. Worth a try. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 16 19:25 Andrei Borzenkov wrote (excerpt):
Hmm ... theoretically
systemctl isolate multi-user.target
(or whatever default target is) should have the same effect as reboot - it /should/ stop any service that would not be started if booting into this target. Worth a try.
On my SLES12 system I tried # systemctl default and # systemctl isolate default.target (which should be mostly equivalent according to "man systemctl"). Both just hang up so that - in a sense - they do have the same final effect as reboot because I was forced to do a real reboot afterwards ;-) Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Christian Boltz
AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires? Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2015-06-15 12:34, Andreas Schwab wrote:
Christian Boltz
writes: AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Jan Engelhardt
On Monday 2015-06-15 12:34, Andreas Schwab wrote:
Christian Boltz
writes: AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd.
Any one that comes with a service file, see above. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2015-06-15 at 12:46 +0200, Andreas Schwab wrote:
Jan Engelhardt
writes: On Monday 2015-06-15 12:34, Andreas Schwab wrote:
Christian Boltz
writes: AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd.
Any one that comes with a service file, see above.
Andreas.
Indeed, and I just rechecked the macros and the setup:
systemd does require the branding package, as we'd expect
%systemd_requires expands to:
Requires(pre): systemd
Requires(post): systemd
Requires(preun): systemd
Requires(postun): systemd
Which is also exactly what we'd need (with this, the post script has
the preset available and can setup the service as expected).
We might want to have at least a lint warning for .service files being
installed, but systemd_requires not being added.
Dominique
--
Dimstar / Dominique Leuenberger
On Monday 2015-06-15 12:46, Andreas Schwab wrote:
Jan Engelhardt
writes: On Monday 2015-06-15 12:34, Andreas Schwab wrote:
Christian Boltz
writes: AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd.
Any one that comes with a service file, see above.
Well the service file's presence still does not mandate having systemd in the RPM database. Nothing better comes to mind, so doing the preset thing in %post seems like the best choice currently. Preferably with a macro itself. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Jan Engelhardt
On Monday 2015-06-15 12:46, Andreas Schwab wrote:
Jan Engelhardt
writes: On Monday 2015-06-15 12:34, Andreas Schwab wrote:
Christian Boltz
writes: AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd.
Any one that comes with a service file, see above.
Well the service file's presence still does not mandate having systemd in the RPM database.
But it's how things are currently supposed to work. Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Monday 2015-06-15 13:39, Andreas Schwab wrote:
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd.
Any one that comes with a service file, see above.
Well the service file's presence still does not mandate having systemd in the RPM database.
But it's how things are currently supposed to work.
I am already setting out to fixchange it. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Hello, On Jun 15 12:46 Andreas Schwab wrote (excerpt):
Didn't it require %systemd_requires? Any one that comes with a service file
I think we should keep RPM requirements as small as possible because RPM requirements are hard dependencies that cannot be cleanly skipped by the user. Therefore RPM requirements should be only what is really mandatory to let a software run at all. Anything else should be RPM recommends so that it is possible to install a minimal system cleanly. I think the possibility to let systemd launch a software via a systemd unit file is not mandatory. Accordingly I think a package with a systemd unit file may recommend systemd but should not require it. Kind Regards Johannes Meixner -- SUSE LINUX GmbH - GF: Felix Imendoerffer, Jane Smithard, Dilip Upmanyu, Graham Norton - HRB 21284 (AG Nuernberg) -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 15 Jun 2015 12:40, Jan Engelhardt wrote:
On Monday 2015-06-15 12:34, Andreas Schwab wrote:
Christian Boltz writes:
AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd.
IMHO this problem should be addressed at the root cause: The install of "systemd" should include a "Require: systemd-presets-branding-openSUSE" and thus make shure it's installed before any other services. Or a full workaround in Apparmour in the "%pre" sequence to force the install of "systemd-presets-branding-openSUSE" before Apparmour in really installed. - Yamaban. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
Yamaban
IMHO this problem should be addressed at the root cause: The install of "systemd" should include a "Require: systemd-presets-branding-openSUSE" and thus make shure it's installed before any other services.
$ rpm -q systemd --requires | grep presets systemd-presets-branding Andreas. -- Andreas Schwab, SUSE Labs, schwab@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org
On Mon, 2015-06-15 at 12:40 +0200, Jan Engelhardt wrote:
On Monday 2015-06-15 12:34, Andreas Schwab wrote:
Christian Boltz
writes: AppArmor has a preset "enable by default" (in the separate systemd- presets-branding-openSUSE), but unfortunately the AppArmor package gets installed before systemd-presets-branding-openSUSE gets installed.
How did that happen? Didn't it require %systemd_requires?
Well, few packages *actually* require systemd.
seems systemd is a small misnomer: it actually requires systemd for the
scripts (which, in turn is correct, as none of the scripts checks if
systemctl is present before trying to start it.. so in fact we DO
require systemd present for the scripts.
just, they all mask errors nicely away with:
/usr/bin/systemctl preset apparmor.service >/dev/null 2>&1 || :
Dominique
--
Dimstar / Dominique Leuenberger
participants (9)
-
Andreas Schwab
-
Andrei Borzenkov
-
Christian Boltz
-
Dimstar / Dominique Leuenberger
-
Jan Engelhardt
-
Johannes Meixner
-
Ludwig Nussel
-
Stephan Kulow
-
Yamaban