[ClusterLabs] Antw: pcmk 1.1.17: Which effective user is calling OCF agents for querying meta-data?

cfpublic1 at verimatrix.com cfpublic1 at verimatrix.com
Thu Sep 27 06:23:18 EDT 2018


>> 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
>> 
> 
> Could it be as simple as /usr/lib/ocf/resource.d/verimatrix/anything4 not having the execute bit set (for the user)?

The OCF agent is not physically located there. /usr/lib/ocf/resource.d/verimatrix is a symbolic link that points to a directory in our software distribution. That part is not reachable for "other".

>> 
>> 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.
> 
> Why? You can selectively grat access (man setfacl)!

That's an option, thank you.

>> 
>> Is this behavior of using different users intended? If yes, any clue 
>> why was
>> it working with pacemaker 1.1.7 under RHEL6?
> 
> Finally: Why are you asking thei list for help, when you removed execute permission for your home-grown (as it seems) resource agent?
> What could WE do?

I would like to understand the concept behind it to determine the best solution. If there was a way to configure or tell crmd to do the meta-data query as root, I would prefer that. It's because even if the actual access to the OCF agent scripts worked, we would hit the next problems because some OCF scripts use the "ocf_is_root" function from /usr/lib/ocf/lib/heartbeat/ocf-shellfuncs. These OCFs would fail miserably.
So before I revisit all our OCFs to check if the well-behave if called as non-root, I wanted to check if there is another way.

Thanks,
  Carsten



More information about the Users mailing list