Maxscale should have its own SELinux security context, and Keepalived directions should explain how to make them work together when SELinux is enforcing.

Although MaxScale runs as an unconfined service under SELinux, keepalived uses the keepalived_t security context, so it does not have rights into /home directories. Therefore it fails when SELinux is enforcing because it cannot see the script under /home/scripts.

Further, the is_maxscale_running.sh procedure ( as written in the walktrhough at at https://mariadb.com/kb/en/mariadb-enterprise/mariadb-maxscale-22-failover-with-keepalived/ ) attempts to write a file, causing a second SELinux error for the same reason, regardless of where the file is written.

Once these two obstacles are overcome by putting is_maxscale_running.sh in /usr/local/sbin/ and re-writing it to capture the output of 'maxadmin list servers' in a variable instead of a file, we run into a third problem: sockets.

MaxScale does not have its own policy, and it would make sense to run MaxScale and Keepalived in the same security context, so an interim solution (alternative to adding just the necessary permissions and nothing else to the keepalived_exec_t security context) is to change the context of keepalived once installed to match that of maxscale.

This can be accomplished in two ways:

in /usr/sbin, you can enter:

chcon system_u:object_r:bin_t:s0 keepalived

(chcon is part of the coreutils package)

alternatively, you can simply rename the executable to /usr/bin/keepalived_old, and then copy it as root with:

cp keepalived_old keepalived

and the new copy will inherit the correct security context.