Bug 1404229 - Unable to use some valid file names with the flag "-f".
Summary: Unable to use some valid file names with the flag "-f".
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: pcs
Version: 7.2
Hardware: Unspecified
OS: Unspecified
medium
unspecified
Target Milestone: rc
: ---
Assignee: Ivan Devat
QA Contact: cluster-qe@redhat.com
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-12-13 12:33 UTC by Ivan Devat
Modified: 2017-08-01 18:24 UTC (History)
6 users (show)

Fixed In Version: pcs-0.9.156-1.el7
Doc Type: Bug Fix
Doc Text:
Cause: user runs a pcs command so that it should change configuration in the file named "-INFINITY" instead of live cluster Consequence: pcs does not recognize the argument "-INFINITY" after "-f" flag as a value of the option "-f" and does not interpret the command correctly Fix: pcs recognizes "-INFINITY" after "-f" flag as a value of the option "-f" Result: pcs interprets the command correctly
Clone Of:
Environment:
Last Closed: 2017-08-01 18:24:40 UTC
Target Upstream Version:


Attachments (Terms of Use)
proposed fix (16.48 KB, patch)
2017-01-09 16:41 UTC, Ivan Devat
no flags Details | Diff


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:1958 normal SHIPPED_LIVE pcs bug fix and enhancement update 2017-08-01 18:09:47 UTC

Description Ivan Devat 2016-12-13 12:33:06 UTC
Description of problem:
Unable to use some valid file names with the flag "-f".


How reproducible:
always


Steps to Reproduce:
[vm-rhel72-1 ~] $ pcs -f -INFINITY resource create R ocf:heartbeat:Dummy


Actual results:

Usage: pcs [-f file] [-h] [commands]...
....
[vm-rhel72-1 ~] $ echo $?                                               
1


Expected results:
[vm-rhel72-1 ~] $ echo $?                                                
0
[vm-rhel72-1 ~] $ ls -l |grep "\-INFINITY"
-rw-r--r--. 1 root root   653 13. pro 13.17 -INIFINITY


Additional info:
With the most filenames like "-SOMETHING" it works correctly. The reason is that parameters "-INFINITY" and "-1" (or any other digits) are taken before parsing options. This problem potentially affect all options (including long options) that expect value in following argument.

Comment 1 Ivan Devat 2016-12-13 14:49:48 UTC
There is another problem with parsing options. Even if the option not expect value (eg. -V) it steals following argumet.

[vm-rhel72-1 ~] $ pcs resource create S ocf:heartbeat:Dummy meta a=b -V c=d

In cib is:
<primitive class="ocf" id="S" provider="heartbeat" type="Dummy">          
  <instance_attributes id="S-instance_attributes"/>                       
  <meta_attributes id="S-meta_attributes">                                
    <nvpair id="S-meta_attributes-a" name="a" value="b"/>                 
  </meta_attributes>                                                      
  <operations>                                                            
    <op id="S-start-interval-0s" interval="0s" name="start" timeout="20"/>
    <op id="S-stop-interval-0s" interval="0s" name="stop" timeout="20"/>  
    <op id="S-monitor-interval-10" interval="10" name="monitor" timeout="20"/>
  </operations>                                                           
</primitive>  

But expected is:

<primitive class="ocf" id="S" provider="heartbeat" type="Dummy">          
  <instance_attributes id="S-instance_attributes"/>                       
  <meta_attributes id="S-meta_attributes">                                
    <nvpair id="S-meta_attributes-a" name="a" value="b"/>                 
    <nvpair id="S-meta_attributes-c" name="c" value="d"/>                 
  </meta_attributes>                                                      
  <operations>                                                            
    <op id="S-start-interval-0s" interval="0s" name="start" timeout="20"/>
    <op id="S-stop-interval-0s" interval="0s" name="stop" timeout="20"/>  
    <op id="S-monitor-interval-10" interval="10" name="monitor" timeout="20"/>
  </operations>                                                           
</primitive>

Comment 2 Ivan Devat 2017-01-09 16:41:34 UTC
Created attachment 1238822 [details]
proposed fix

Test:
1)
[vm-rhel72-1 ~] $ ls -l|grep "INFINITY"
[vm-rhel72-1 ~] $ pcs -f -INFINITY resource create R ocf:heartbeat:Dummy
[vm-rhel72-1 ~] $ ls -l|grep "INFINITY"
-rw-r--r--. 1 root root   653  9. led 17.35 -INFINITY

2)
[vm-rhel72-1 ~] $ pcs resource create S ocf:heartbeat:Dummy meta a=b -V c=d
[vm-rhel72-1 ~] $ pcs cluster cib|grep 'name="c"' -B 4
      <primitive class="ocf" id="S" provider="heartbeat" type="Dummy">
        <instance_attributes id="S-instance_attributes"/>
        <meta_attributes id="S-meta_attributes">
          <nvpair id="S-meta_attributes-a" name="a" value="b"/>
          <nvpair id="S-meta_attributes-c" name="c" value="d"/>

Comment 4 Ivan Devat 2017-02-20 07:50:54 UTC
After Fix:

[vm-rhel72-1 ~] $ rpm -q pcs
pcs-0.9.156-1.el7.x86_64

> 1)

[vm-rhel72-1 ~] $ ls -l|grep "INFINITY"
[vm-rhel72-1 ~] $ pcs -f -INFINITY resource create R ocf:heartbeat:Dummy
[vm-rhel72-1 ~] $ ls -l|grep "INFINITY"
-rw-r--r--. 1 root root   595 15. úno 15.46 -INFINITY

> 2)

[vm-rhel72-1 ~] $ pcs resource create S ocf:heartbeat:Dummy meta a=b -V c=d
[vm-rhel72-1 ~] $ pcs cluster cib|grep 'name="c"' -B 3
      <primitive class="ocf" id="S" provider="heartbeat" type="Dummy">
        <meta_attributes id="S-meta_attributes">
          <nvpair id="S-meta_attributes-a" name="a" value="b"/>
          <nvpair id="S-meta_attributes-c" name="c" value="d"/>

Comment 8 errata-xmlrpc 2017-08-01 18:24:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:1958


Note You need to log in before you can comment on or make changes to this bug.