On Wed, 2018-09-26 at 13:26 +0000, [email protected] 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[2871]: > warning: Cannot execute > '/usr/lib/ocf/resource.d/verimatrix/anything4': Permission denied > (13) > 2018-09-18T11:58:18.453179+03:00 p12-0001-bcsm03 crmd[2871]: > error: Failed to retrieve meta-data for ocf:verimatrix:anything4 > 2018-09-18T11:58:18.453291+03:00 p12-0001-bcsm03 crmd[2871]: > 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 > RHEL7. > > 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? > > Thanks, > Carsten
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 other issues. 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 root. Giving hacluster access to the protected directory, using setfacl or group membership, might be a useful workaround. -- Ken Gaillot <[email protected]> _______________________________________________ Users mailing list: [email protected] https://lists.clusterlabs.org/mailman/listinfo/users Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
