[ClusterLabs] Fence agent definition under Centos7.6

[Jan Pokorný]

On 18/06/19 13:08 +0000, Michael Powell wrote:
> * The document does not specify where the agent should be installed.
>   (On /usr/sbin.)

This could give a precise answer:
https://github.com/ClusterLabs/pacemaker/blob/Pacemaker-2.0.2/lib/fencing/st_rhcs.c#L33

> * The document does not mention that, if the agent requires root
> permissions (a not-unlikely scenario, I think), it needs the setuid
> bit set (e.g. chmod u+s /usr/sbin/fence-agent), or some similar
> mechanism, since crmd and stonith-ng apparently do not execute the
> fence agent with root privileges.

Executing daemons (pacemaker-fenced [formerly stonith-ng] or possibly
pacemaker-execd [formerly lrmd] as used for general resources) run
as root, so you can rely on having the root perms from the get go.

Do you observe the contrary?

> * The document does not specify support for "action=metadata". 
> I got this from
> https://github.com/ClusterLabs/resource-agents/blob/master/doc/dev-guides/ra-dev-guide.asc
> and by looking at the output of the fence-ipmilan agent.

This should be covered with the very last line in FenceAgentAPI.md:

  Output of fence_agent -o metadata should validate against RelaxNG
  schema available at lib/metadata.rng

Oyvind could provide a further guidance or corrections, but these
fence agents are not unified with resource agents in this regard
(yet, if that's still a final goal).

> Another issue I found is that I needed to use "pcs create stonith"
> rather than "crm configure primitive" to create the agent.  Our old
> code was based upon crmsh, and my on-line reading suggested that the
> choice of crmsh vs pcs was up to the user.  This is apparently not
> true.  For the most part, it looks as though transitioning our
> scripts from crmsh to pcs will be pretty straightforward, though.

Crm shell representatives can comment on this.
As far as pcs is concerned, it's rather natural for it to support
that family of fence-agents, since it's inherited from an older
cluster stack arrangement...

> Finally, I have two questions:
> * The FenceAgentsAPI.md doc describes the cluster.conf file (though,
> again, it does not indicate where it should be installed.)  AFAICT,
> this isn't really necessary for the fence agent to reboot another
> node.  Am I missing something?

...sometimes referred to per its legacy name Red Hat Cluster Suite
(that explains "rhcs" abbreviations in the source file name linked
above).  That stack used to use single point of configuration, and
it was -- you've guessed it -- cluster.conf file.  That it is still
referred from that API document is just a legacy thing, but the
important parts remain practically unchanged from those times.

> * In some cases, the fence agent receives "action=reboot" followed
> by "nodename=<name of the node running the agent>".  I.e. it's asked
> to reboot itself.  This doesn't make sense to me.  Again, what am I
> missing?

Might be the case of misconfiguration.  Showing your configuration
would provide a basis for further dissection.  Also, "node running the
agent" is ambiguous, it may mean the node running periodic "monitor"
operations, which doesn't have any direct bearings on node being
selected as a target to be fenced.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20190620/60ff2203/attachment-0001.sig>