In the default mode of operation, EDB Postgres Failover Manager (EFM) agents run as the ‘efm’ operating system user. The agent uses sudo to perform various operating system and database tasks. More information about how sudo is used is in the Extending Failover Manager Permissions section of the user’s guide.
Starting with version 3.0, EFM can now be run without sudo (or a sudo replacement). This blog expands on the user’s guide section Running Failover Manager without sudo. Root access is still required to install EFM, and is needed for a one time setup task before running. There is also a limitation that root privileges are needed for running services (e.g. using systemctl), so running EFM without sudo requires that the databases being monitored are started/stopped with pg_ctl rather than running as services.
To work without sudo, an agent is run as the same operating system user that runs the database server. This allows the agent to perform tasks like creating a trigger file, editing the recovery.conf file, etc. For VIP operations without root privileges, a new binary has been added that uses setuid to be able to run the ip addr command:
Only members of the ‘efm’ group (and root) can access this binary. It is important to limit membership in this group because any user in it will be able to acquire/drop the virtual IP address.
For the following example, we will assume that the enterprisedb user is being used to run EFM agents. After installing, the enterprisedb user must be added to the ‘efm’ group in order to have access to necessary files and tools. For example:
usermod -a -G efm enterprisedb
Please note: If you have previously used a cluster named ‘efm’ (the default) and want to run without sudo, you must remove any log files already created and owned by the efm user, as the enterprisedb user will not be able to write to them. If your system hosts both sudo and non-sudo cases, you should use a different name for each cluster. In the example that follows, we will use the name ‘mycluster’ for our non-sudo cluster.
As the enterprisedb user, create a directory to store the properties/nodes files, and copy the templates to create working copies. For instance:
-bash-4.2$ mkdir ~/efm-3.0
-bash-4.2$ cp /etc/edb/efm-3.0/efm.properties.in ~/efm-3.0/mycluster.properties
-bash-4.2$ cp /etc/edb/efm-3.0/efm.nodes.in ~/efm-3.0/mycluster.nodes
The directory can be in any location, but it can simplify certain commands to use ‘efm-3.0’ in the home directory (more information below).
When modifying the mycluster properties file, make sure the service name is blank and the service owner is set to the same user who will be running the agent. If the service name is not blank, efm will still run as the enterprisedb user, but will use sudo to run systemctl/service to start/stop the database.
The mycluster.nodes file doesn’t require any special steps to run in no-sudo mode.
After the configuration files are ready, EFM can be started/stopped with:
/usr/edb/efm-3.0/bin/runefm.sh start|stop <path>/<cluster name>.properties
If you are using the default directory name ~/efm-3.0, the path above can be left out and only the cluster name is required. For example:
/usr/edb/efm-3.0/bin/runefm.sh start mycluster
Similarly, when invoking commands to manage the cluster, EFM will look in the user’s home directory first if just a cluster name is given. Otherwise, it uses the path provided. For example, the enterprisedb user can run this command for status and EFM will find the properties file in ~/efm-3.0:
efm cluster-status mycluster
For a different user to run the command, the full path is needed to find the file:
efm cluster-status /var/lib/edb/efm-3.0/mycluster.properties.
Because EDB Postgres Failover Manager is running as the enterprisedb user in this example, any scripts that are run by the agent will be run as enterprisedb. Any script specified in a script.* property must be executable by the operating system user running EFM.
Bobby Bissett is a Cloud Architect at EnterpriseDB.