[ClusterLabs] Possible intrusive change in bundles for 2.0.3
lejeczek
peljasz at yahoo.co.uk
Fri Jun 7 05:15:32 EDT 2019
On 06/06/2019 23:34, Ken Gaillot wrote:
> Hi all,
>
> It has been discovered that newer versions of selinux-policy prevent
> bundles in pacemaker 2.0 from logging. I have a straightforward fix,
> but it means that whenever a cluster is upgraded from pre-2.0.3 to
> 2.0.3 or later, all active bundles will restart once the last older
> node leaves the cluster.
>
> This is because the fix passes the "Z" mount flag to docker or podman,
> which tells them to create a custom SELinux policy for the bundle's
> container and log directory. This is the easiest and most restrictive
> solution.
>
> An alternative approach would be for pacemaker to start delivering its
> own custom SELinux policy as a separate package. The policy would allow
> all pacemaker-launched containers to access all of
> /var/log/pacemaker/bundles, which is a bit broader access (not to
> mention more of a pain to maintain over the longer term). This would
> avoid the restart.
>
> I'm leaning to the in-code solution, but I want to ask if anyone thinks
> the bundle restarts on upgrade are a deal-breaker for a minor-minor
> release, and would prefer the packaged policy solution.
I personally could live with such a case of restart on my small deployment.
(what does the "bundle" constitute?)
But there is more in terms of SELinux which should be investigated and
fixed when it comes to pacemaker. Yesterday I had to prep a custom
selinux module because SE policies stop pacemaker from starting/managing
virt domain with storage off a gluster volume and xml config in
/var/lib/pacemaker.
thanks, L.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pEpkey.asc
Type: application/pgp-keys
Size: 1757 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190607/ecd3ae24/attachment.bin>
More information about the Users
mailing list