[ClusterLabs] Q: HA_RSCTMP in SLES11 SP4 at first start after reboot

[Jan Pokorný]

On 14/08/18 08:01 +0200, Ulrich Windl wrote:
>>>> Vladislav Bogdanov <bubble at hoster-ok.com> schrieb am 13.08.2018 um 17:13
>>>> in Nachricht <35541484-1f3e-e5f6-5938-cf17e12184f3 at hoster-ok.com>:
>>> 10.08.2018 19:52, Ulrich Windl wrote:
>>> 
>>> A simple question: One of my RAs uses $HA_RSCTMP in SLES11 SP4, and it 
>> reports the following problem:
>>>   WARNING: Unwritable HA_RSCTMP directory /var/run/resource‑agents ‑ using
>>> /tmp
>> 
>> Just make sure you avoid using that code in 'meta‑data' action handler 
>> (it is run by crmd which runs under hacluster user to obtain and cache 
>> agent meta‑data and I bet that message is from that run).
> 
> This is a very plausible explanation. However I wonder whether it should be
> documented more clearly in the RA writers guide (or corresponding document).

Perhaps it would be wise to clearly instruct authors of resource agents
to never cast any side effects when plain meta-data query is invoked
-- such a bad style (also as exercised with the stated snippet if
placed directly at the file-level scope of the script) generates
recurring problems, especially when such "always fired" code decides
to talk back to resource manager unconditionally(!):

https://bugs.clusterlabs.org/show_bug.cgi?id=5357#c16

> The other thing is whether a group "hacluster" and a "chgrp hacluster
> $HA_RSCTMP; chmod g+rwx $HA_RSCTMP" would be a good idea (assuming crmd is run
> as hacluster:hacluster then).

Tentative plan is to delegate fetching meta-data for the purpose of
caching them also into lrmd/pacemaker-execd, which would close this
hole once for all.

> The other thing would be messing with "setfacl -m u:hacluster:rwx $HA_RSCTMP"

Nonportable.

-- 
Nazdar,
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/20180814/cda384c9/attachment-0002.sig>