Setting up a MariaDB Galera cluster can easily become tedious if its being setup on a Linux system with SELinux enabled.
140805 16:16:20 [Note] WSREP: gcomm: connecting to group 'my_wsrep_cluster', peer '' 140805 16:16:20 [ERROR] WSREP: Permission denied 140805 16:16:20 [ERROR] WSREP: failed to open gcomm backend connection: 13: error while trying to listen 'tcp://0.0.0.0:4567?socket.non_blocking=1', asio error 'Permission denied': 13 (Permission denied) at gcomm/src/asio_tcp.cpp:listen():814 140805 16:16:20 [ERROR] WSREP: gcs/src/gcs_core.c:gcs_core_open():202: Failed to open backend connection: -13 (Permission denied) 140805 16:16:20 [ERROR] WSREP: gcs/src/gcs.c:gcs_open():1291: Failed to open channel 'my_wsrep_cluster' at 'gcomm://': -13 (Permission denied) 140805 16:16:20 [ERROR] WSREP: gcs connect failed: Permission denied 140805 16:16:20 [ERROR] WSREP: wsrep::connect() failed: 7 140805 16:16:20 [ERROR] Aborting
In a test environment one can bypass this by simply disabling SELinux :
$ sudo setenforce 0 $ getenforce permissive
But, this certainly is not the right way especially when we are dealing with a cluster in production.
So, I tried to configure SELinux for a 2-node MariaDB Galera cluster on CentOS by using some useful tools provided to manage SELinux policies. The basic idea is to let the MariaDB Galera nodes run under permissive mode in order to get all possible operations (which SELinux would have otherwise denied) logged into the audit log and then create a policy module using allow2audit tool after carefully analyzing the “denials”. This module can then be installed before enabling (enforcing) SELinux.
Prepare hosts 1 & 2
* Install MariaDB Galera server packages ($ sudo yum install MariaDB-Galera-server)
* Setup MariaDB configuration options ($sudo vi /etc/my.cnf.d/server.cnf)
* Install SELinux policy management tools ($ sudo yum install policycoreutils-python)
* Firewall settings (see resources below)
On host 1:
* Put SELinux in permissive mode. ($ sudo setenforce 0) : Once SELinux is in permissive mode, it basically logs all the denial operations as warnings instead of enforcing them.
* Start the server (the donor node) ($ sudo /etc/init.d/mysql start)
* Wait for the joiner node (node 2) to start and join the cluster post-SST (snapshot state transfer).
* Stop the node, edit the configuration to make it join the already running node 2 and start it back again to initiate SST this time in reverse direction.
* Once the node has successfully started and joined the cluster, carefully analyze (sealert Messages) all the “denials” logged in the audit log (/var/log/audit/audit.log). If the denials are expected, create a local policy module using allow2audit.
$ sudo grep mysql audit.log | audit2allow -M galera $ sudo semodule -i galera.pp
- Put SELinux back to enforcing mode ($sudo setenforce 1)
On host 2:
* Follow the steps performed for node 1. Note: the node will be started as the “joiner node” and would later become the “donor”.