[Bug 1017260] New: apparmor.service missing in Leap
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260 Bug ID: 1017260 Summary: apparmor.service missing in Leap Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.2 Hardware: Other OS: openSUSE 42.2 Status: NEW Severity: Normal Priority: P5 - None Component: AppArmor Assignee: suse-beta@cboltz.de Reporter: suse-beta@cboltz.de QA Contact: qa-bugs@suse.de CC: maintenance@opensuse.org Found By: Beta-Customer Blocker: --- CC: maintenance@opensuse.org Flags: needinfo?(maintenance@opensuse.org) Thanks to a wrong suse_version check, apparmor.service is not included in the AppArmor packages for Leap 42.1 and 42.2. In practise this doesn't change much - the package still includes the good old initscript, and AppArmor gets enabled by default and works as expected. The biggest (only?) problem is that Saltstack fails to enable a service that is started by an initscript (or maybe it's just because it's a boot.* initscript). (Needless to say: I noticed this bug while working on Salt stuff for the upcoming openSUSE cloud setup.) Adding the real apparmor.service (which is a wrapper around the initscript) in a maintenance update isn't hard, and shouldn't change things for most people because the preset is to enable it. However, if someone intentionally disabled AppArmor, the update will re-enable it once and annoy that user. The alternative is to live without apparmor.service in 42.1 and 42.2, and deliver the apparmor.service to the openSUSE infrastructure via salt for now. This is obviously annoying on the Salt side, but it's guaranteed not to annoy any user. Maintenance team, what's your opinion on this? Should I add the apparmor.service file in a maintenance update for 42.2 (and also for 42.1?), or do you think it's a bad idea? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c1
--- Comment #1 from Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c2
Andreas Stieger
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c3
Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c8
Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c10
--- Comment #10 from Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c11
--- Comment #11 from Frank Kruger
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c12
--- Comment #12 from Frank Kruger
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c13
Dirk Weber
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c14
Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c15
--- Comment #15 from Dirk Weber
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
Stakanov Schufter
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c16
Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c20
Christian Boltz
Preset is the correct way to activate service default state.
All other ways are incorrect.
I'm afraid your answer was not too helpful :-( The problem is: there _is_ a preset, but it was ignored :-( so I'm looking for a way to re-enable AppArmor _for users who had it enabled before_ (via initscript). May I ask you for a more specific answer on - why the preset was ignored - if my script in comment #16 would work in %post and get accepted as part of the next AppArmor maintenance update for Leap -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c22
Stanislav Brabec
/run/rpm-%{name}-update-apparmor.service-new-in-upgrade fi fi
(The /etc/init.d/boot.apparmor will be removed in the upgrade, so it will be called never again. The hack can be removed after expiring of upgrade protection.) -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c23
--- Comment #23 from Christian Boltz
I propose:
1) Completely drop support for migration from the old name "subdomain". It will make spec file more readable. Direct upgrade from such an ancient version (e. g. SLES 9) would cause much more problems than just not migrating apparmor state.
2) Completely drop sysv support for suse_version > 1200 (I think), exactly as all other packages did.
1) and 2) are already done in Tumbleweed (thanks to Thorsten), but I'm not too keen to do this in a maintenance update for 42.1 and 42.2. I especially dislike dropping the /etc/init.d/boot.apparmor initscript - someone out there might call it directly in a script (for whatever reason), and removing the initscript would mean to break this.
3) Add a hack to fix the migration.
That looks like a nice trick. I added something similar (based on the /etc/init.d/boot.d/*boot.apparmor symlinks, so if someone explicitely disabled AppArmor, it should stay disabled). Updated packages (not tested yet) are building in home:cboltz:branches:OBS_Maintained:apparmor/apparmor.openSUSE_Leap_42.2_Update I'll do some testing tomorrow (and won't complain if someone else tests and reports back ;-) and submit a maintenance update if everything works. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c24
--- Comment #24 from Stanislav Brabec
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c25
--- Comment #25 from Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c26
--- Comment #26 from Stanislav Brabec
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c27
--- Comment #27 from Christian Boltz
The suggested fix again enables apparmor even if it was intentionally disabled before. That could break services and potentially even lock out people. There is no easy way out here anymore. So I'd say the released update should be reverted ASAP. A follow-up update should be released that removes that service file but still contains the other fixes.
I'd agree with that two days after the broken update went out - but reverting something 6 weeks later is calling for more trouble IMHO. I just did some testing, always restarting from a clean 42.2 JeOS without any AppArmor package. In the following tests, - "oss" means the original 42.2 oss repo - "update" means the current 42.2 update repo - "my test repo/packages" means home:cboltz:branches:OBS_Maintained:apparmor 1) - install AppArmor from oss (-> enabled) - update to the latest update (-> disabled) - update to my test package (-> enabled again - so my fix is working) 2) - install AppArmor from update repo (-> enabled) - update to my test package (-> enabled) 3) - install AppArmor from oss (-> enabled) - "insserv -r boot.apparmor" (-> disabled) (note: systemctl disable doesn't work for the initscript) - update to my test package (-> disabled) 4) - install AppArmor directly from my test repo (-> enabled) I'd argue that all this looks good and covers the usual upgrade paths. Yes, there's another possible case: - install AppArmor from oss (-> enabled) - updated to the last update (-> disabled) - manually re-enable AppArmor with systemctl enable apparmor (-> enabled) - disable AppArmor some days later with systemctl disable apparmor (-> disabled, but symlinks in /etc/init.d/boot.d/ will still exist) In this case AppArmor will be re-enabled with my test update - but I'd say this way is the most unlikely case to happen ;-) Did I miss another possible upgrade/enable/disable path? Note: thanks to bug 1029696 we shouldn't wait too long with pushing out an update. I'll submit the update tomorrow if nobody objects. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c28
--- Comment #28 from Ludwig Nussel
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c31
Christian Boltz
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260
http://bugzilla.opensuse.org/show_bug.cgi?id=1017260#c32
--- Comment #32 from Frank Kruger
participants (1)
-
bugzilla_noreply@novell.com