Generating an AppArmor profile in 'enforce' mode disallows access to the OSD volumes
Bug #1860801 reported by
Peter Matulis
This bug affects 1 person
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Ceph OSD Charm |
Fix Committed
|
Medium
|
Unassigned | ||
Quincy.2 |
Fix Committed
|
Undecided
|
Unassigned |
Bug Description
This command
$ juju config ceph-osd aa-profile-
causes loss of access to the OSD volumes. The `juju status` command shows:
"No block devices detected using current configuration"
Details here:
https:/
Reverting to 'disable' mode (the default) restores access.
Changed in charm-ceph-osd: | |
status: | New → Triaged |
importance: | Undecided → Medium |
Changed in charm-ceph-osd: | |
status: | Triaged → In Progress |
To post a comment you must log in.
As per the documentation for the ceph-osd charm, this does not necessarily seem like a bug:
AppArmor Profiles
AppArmor is not enforced for Ceph by default. An AppArmor profile can be generated by the charm. However, great care must be taken.
Changing the value of the aa-profile-mode option is disruptive to a running Ceph cluster as all ceph-osd processes must be restarted as part of changing the AppArmor profile enforcement mode.
The generated AppArmor profile currently has a narrow supported use case, and it should always be verified in pre-production against the specific configurations and topologies intended for production.
The AppArmor profile(s) which are generated by the charm should NOT yet be used in the following scenarios:
- When there are separate journal devices.
- On any version of Ceph prior to Luminous.
- On any version of Ubuntu other than 16.04.
- With Bluestore enabled.
---
With this documentation in mind, is this bug still valid?