Hi Sunil, I meant the ceph's audit log. That's either in the MGR's log or in a dedicated log. I'd like to know which MON Commands were issues by the cluster. MON log should also be ok
(In reply to Sebastian Wagner from comment #5) > Hi Sunil, I meant the ceph's audit log. That's either in the MGR's log or in > a dedicated log. I'd like to know which MON Commands were issues by the > cluster. MON log should also be ok Hi Sebastian, MON log files are already attached in `Ceph logs` attachment.
Any updates? This is a blocker for QE's CI.
https://chat.google.com/room/AAAAHvpVoDg/lkg7VaW4qys
Pr is in upstream QA
*** Bug 2028132 has been marked as a duplicate of this bug. ***
workaround: disable selinux for now
Containers can not tell whether or not they are confined. So running getenforce inside of a container could be correct or the selinux library could be lying. $ getenforce Enforcing $ podman run fedora id -Z id: --context (-Z) works only on an SELinux-enabled kernel This shows that inside of the container, it thinks that SELinux is disabled, but the host is clearly in enforcing mode. Bottom line all that matters is how the host is set. SElinux does not change per container, only for the host. Containers can run with different types, container_t being a confined type, while spc_t being an unconfined type. $ podman run fedora cat /proc/self/attr/current system_u:system_r:container_t:s0:c36,c918 $ podman run --privileged fedora cat /proc/self/attr/current unconfined_u:system_r:spc_t:s0
BTW is there a reason this is being blamed on SELinux?
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Moderate: Red Hat Ceph Storage 5.1 Security, Enhancement, and Bug Fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2022:1174