[ClusterLabs] [OCF] [RFC at agents] unresolved issue with handling parameters containing whitespaces

[Alan Robertson]

On 05/15/2015 02:37 PM, Jan Pokorný wrote:
> On 13/05/15 11:44 +0200, Lars Ellenberg wrote:
>> On Tue, May 12, 2015 at 07:23:36AM -0600, Alan Robertson wrote:
>>> This is not a problem in the OCF API, but in the pcs command.
>>>
>>> There is no issue with having spaces in environment variables.
>>>
>>> It's the pcs command that's doing you dirty here...
> I am afraid I sense some short-circuiting here.  I should have provided
> more details to preempt blaming pcs for everything, as it only served
> to demonstrate the point (and the bugs at the end served to show somewhat
> relevant issues with handling doublequotes, e.g., in case explicit quoting
> of white-space contained parameter value becomes recommended practice
> ~ C1.-second option/"suboptimal").
>
> To compensate it now, clarification follows:
>
>   # pcs resource create mysql-test1 ocf:heartbeat:mysql \
>     'config=/mnt/foo/mysql/config final.cnf'
>
> will lead to the following nvpair in CIB:
>
>   <nvpair id="mysql-test1-instance_attributes-config"
>           name="config"
>           value="/mnt/foo/mysql/config final.cnf"/>
>
> and, likewise,
>
>   # pcs resource create mysql-test2 ocf:heartbeat:mysql \
>     'config="/mnt/foo/mysql/config final.cnf"'
>
> to
>
>   <nvpair id="mysql-test2-instance_attributes-config"
>           name="config"
> 	  value=""/mnt/foo/mysql/config final.cnf""/>
>
> So there is _no_ issue on pcs side so far.
> Also Pacemaker will pass the environment variables in a correct manner
> (yes, it's perfectly valid to have spaces there).
>
> Only later in chain, some assumptions may be broken in such a case:
>
>> In this case it is also the mysql RA (and helper functions)
>> that do not properly quote.
>>
>> https://github.com/ClusterLabs/resource-agents/blob/master/heartbeat/mysql-common.sh#L108
>> ff.
>>
>> if [ ! -f $OCF_RESKEY_config ]; then
>>
>> Well, sure, that breaks.
> Sure, I know :)  But this is not an isolated case at all (see below) and
> that's why I wanted to bring this up.
>
>> But Alan is right, of course, this is not a problem with the OCF API.
> I hope I haven't implied the contrary -- I only offered a prospect
> of possibly solving this issue on the API level by either excluding
> spaces from a parameter value domain altogether (A./"dull") or setting
> rules how to enquote spec-contained parameter values explictly
> (C1.-second option/"suboptimal").  This is the only relevance to OCF.
>
> Oh, there's also a possibility for more granular parameter value domain/
> data type restrictions akin to what you can achieve in Relax NG
> (mentioned that at the HA Summit in Brno) -- parameters could
> determine themselves whether space in string is supported or not
> and the validators in management tools could enforce that.
> Apparently, OCF standard would have to be amended first, but
> I anticipate this would be optional, non-disruptive extension.
They should just support spaces. Otherwise the agents are broken. Fix them.

Don't change the spec to deal with the fact that some people aren't very
good at writing shell scripts. This is a general, common, and well-known
"gotcha" in writing shell scripts.

If you want to fix something, then fix the *documentation* on how to
write them. I wonder if one can fix the agent test code to ensure that
parameters with spaces are given? [probably not].  But it could
certainly offer a reminder to make sure they are tested with spaces in them.

    -- Alan Robertson
       alanr at unix.sh
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20150515/b2bfe1c9/attachment-0003.html>