[ClusterLabs] Which effective user is calling OCF agents for querying meta-data?
kgaillot at redhat.com
Fri Sep 28 09:57:43 EDT 2018
On Wed, 2018-09-26 at 13:26 +0000, cfpublic1 at verimatrix.com wrote:
> Hi all,
> we have been using pacemaker 1.1.7 for many years on RedHat 6.
> Recently, we moved to RedHat 7.3 and pacemaker 1.1.17.
> Note that we build pacemaker from source RPMs and don’t use the
> packages supplied by RedHat.
> With pacemaker 1.1.17, we observe the following messages during
> startup of pacemaker:
> 2018-09-18T11:58:18.452951+03:00 p12-0001-bcsm03 crmd:
> warning: Cannot execute
> '/usr/lib/ocf/resource.d/verimatrix/anything4': Permission denied
> 2018-09-18T11:58:18.453179+03:00 p12-0001-bcsm03 crmd:
> error: Failed to retrieve meta-data for ocf:verimatrix:anything4
> 2018-09-18T11:58:18.453291+03:00 p12-0001-bcsm03 crmd:
> error: No metadata for ocf::verimatrix:anything4
> However, apart from that, we can control the respective cluster
> resource (start, stop, move, etc.) as expected.
> crmd is running as user ‘hacluster’, both on the old pacemaker 1.1.7
> deployment on RHEL6 and on the new pacemaker 1.1.17 deployment on
> It seems that on startup, crmd is querying the meta-data on the OCF
> agents using a non-root user (hacluster?) while the regular resource
> control activity seems to be done as root.
> The OCF resource in question intentionally resides in a directory
> that is inaccessible to non-root users.
> Is this behavior of using different users intended? If yes, any clue
> why was it working with pacemaker 1.1.7 under RHEL6?
This was answered elsewhere, but for anyone searching who ends up here:
The crmd executes meta-data actions as hacluster, while the lrmd
executes all other resource agent actions as root. It is a long-term
goal to make crmd go through the lrmd to get meta-data, to fix this and
As a best practice, resource agents' meta-data action should not
require any permissions or have any side effects, as normal users
should be able to query meta-data.
I'm not sure why it worked under 1.1.7. My best guess is that you were
using the old corosync 1 plugin (as opposed to the CMAN layer more
commonly used on RHEL 6), and that the plugin launched all processes as
Giving hacluster access to the protected directory, using setfacl or
group membership, might be a useful workaround.
Ken Gaillot <kgaillot at redhat.com>
More information about the Users