[ClusterLabs] ocf-tester always claims failure, even with built-in resource agents?

[Antony Stone]

On Friday 26 March 2021 at 17:59:07, Andrei Borzenkov wrote:

> On 26.03.2021 17:28, Antony Stone wrote:

> > # ocf-tester -n Asterisk /usr/lib/ocf/resource.d/heartbeat/asterisk
> > Beginning tests for /usr/lib/ocf/resource.d/heartbeat/asterisk...
> > /usr/sbin/ocf-tester: 226: /usr/sbin/ocf-tester: xmllint: not found
> > * rc=127: Your agent produces meta-data which does not conform to
> > ra-api-1.dtd * Your agent does not support the notify action (optional)
> > * Your agent does not support the demote action (optional)
> > * Your agent does not support the promote action (optional)
> > * Your agent does not support master/slave (optional)
> > * Your agent does not support the reload action (optional)
> > Tests failed: /usr/lib/ocf/resource.d/heartbeat/asterisk failed 1 tests

> As is pretty clear from error messages, ocf-tester calls xmllint which
> is missing.

Ah, I had not realised that this meant the rest of the output would be 
invalid.

I thought it just meant "you don't have xmllint installed, so there's some 
stuff we might otherwise be able to tell you, but can't".

If xmllint being installed is a requirement for the remained of the output the 
be meaningful, I'd expected that ocf-tester would simply give up at that point 
and tell me that until I install xmllint, ocf-tester can't do its job.

That seems like a bit of a bug to me.

After installing xmllint I now get:

/usr/lib/ocf/resource.d/heartbeat/asterisk passed all tests

/usr/lib/ocf/resource.d/heartbeat/anything passed all tests

So I'm now back to working out how to debug the failures I do see in "normal" 
operation, which were notocurring with the older versions of corosync & 
pacemaker...

> > My second question is: how can I debug what caused pacemaker to decide
> > that it couldn't run Asterisk due to "insufficient privileges"

> Agent returns this error if it fails to chown directory specified in its
> configuration file:
> 
>         # Regardless of whether we just created the directory or it
>         # already existed, check whether it is writable by the configured
>         # user
>         if ! su -s /bin/sh - $OCF_RESKEY_user -c "test -w $dir"; then
>             ocf_log warn "Directory $dir is not writable by
> $OCF_RESKEY_user, attempting chown"
>             ocf_run chown $OCF_RESKEY_user:$OCF_RESKEY_group $dir \
> 
>                 || exit $OCF_ERR_PERM
> 
> Either agent does not run as root or something blocks chown. Usual
> suspects are apparmor or SELinux.

Well, I'm not running either of those, but your comments point me in what I 
think is a helpful direction - thanks.


Regards,

Antony.

-- 
It may not seem obvious, but (6 x 5 + 5) x 5 - 55 equals 5!

                                                   Please reply to the list;
                                                         please *don't* CC me.