Project

General

Profile

Actions

action #48146

closed

Disable apparmor persistently on OSD worker hosts

Added by mkittler about 6 years ago. Updated about 6 years ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
-
Target version:
-
Start date:
2019-02-20
Due date:
% Done:

0%

Estimated time:

Description

Today we noticed that apparmor was enabled on openqaworker{3,5,6,7,8,9}. We disabled the service manually but it should be disabled persistently. Apparently https://gitlab.suse.de/openqa/salt-states-openqa/blob/master/openqa/worker.sls#L260 has no effect.


Related issues 1 (0 open1 closed)

Related to openQA Infrastructure (public) - action #48143: [tools][functional][u] openq: permission issues on openqaworker5Resolvedmgriessmeier2019-02-20

Actions
Actions #1

Updated by mkittler about 6 years ago

  • Related to action #48143: [tools][functional][u] openq: permission issues on openqaworker5 added
Actions #2

Updated by nicksinger about 6 years ago

  • Status changed from New to In Progress
  • Assignee set to nicksinger

mkittler wrote:

Today we noticed that apparmor was enabled on openqaworker{3,5,6,7,8,9}. We disabled the service manually but it should be disabled persistently. Apparently https://gitlab.suse.de/openqa/salt-states-openqa/blob/master/openqa/worker.sls#L260 has no effect.

It has. Unfortunately just removing the package is not enough to really ensure the service is stopped.
I don't really know what caused the re-installation of that package and therefore its start after reboot. My current guess would be that some update pulled in apparmor as dependency again.

Therefore I've prepared https://gitlab.suse.de/openqa/salt-states-openqa/merge_requests/99 which still needs testing on staging but should ensure we're not hit by this again.

I might extend the MR with a mask for zypper to avoid accidental reinstallation in the future.

Another improvement would be a new salt class to distinguish between "simple workers" (where apparmor could be enabled and not causing problems) and workers with more complex setups where apparmor is not applicable.

Actions #3

Updated by nicksinger about 6 years ago

  • Status changed from In Progress to Resolved

Current MR seems to be sufficient. Apparmor is disabled and masked on all workers now.

Actions

Also available in: Atom PDF