> On Thu, 2018-09-27 at 10:23 +0000, cfpubl...@verimatrix.com wrote: > > > > 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 > > The crmd does indeed run meta-data queries as the hacluster user, while the > lrmd executes all other resource actions as root. It's a > longstanding goal to correct this by making crmd go through lrmd to get > meta-data, but unfortunately it's a big project and there are many > more pressing issues to address. :-( > > There's no workaround within pacemaker, but the setfacl approach sounds > useful. > > As a best practice, an agent's meta-data action should not do anything other > than print meta-data. I.e. many agents have common > initialization that needs to be done before all actions, but this should be > avoided for meta-data. Even without this issue, regular users and > higher-level tools should be able to obtain meta-data without permission > issues or side effects. > -- > Ken Gaillot <kgail...@redhat.com>
Thank you, Ken, for the confirmation that there is no workaround within pacemaker. I will re-visit all our OCFs then and make sure they are world accessible and the meta-data action requires no special permissions. I still wonder why it worked with pacemaker 1.1.7, though ;-) Thanks, Carsten _______________________________________________ Users mailing list: Users@clusterlabs.org 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