Problem reported in 2013 still causing problems in SSH.py file?

Hi,
The original issue reported:
Traceback (most recent call last):
File "/opt/vertica/bin/verticaInstall.py", line 1232, in
code, result = SSH.installNode( installerSSH, host, rootPassword, options.rpm_file_name, localhost, running_as )
File "/opt/vertica/oss/python/lib/python2.7/site-packages/vertica/network/SSH.py", line 1986, in installNode
if int(data[1][0]) < sz:
ValueError: invalid literal for int() with base 10: '8%'
was marked as fixed in bug 27421 versions 6.1.SP3 and 7.0. The engineering note states as below:
added --portability flag to df command to support long volume group names found in RHEL6 (and other more recent distributions)The "--portability" is equivalant to the "-P" used in the workaround at the link you provided.
This could be a variation. Was there a specific value at the end of the "ValueError", and if so was it "8%" or something else. There was a comment related to the fragile parsing of the df command and the general "base10" error it sends back, but no other examples beyond the reported one.

Here's the response from the customer:
I don't have long filesystem names on the servers.
The output I get from the SSH.py script df command is:
root@RHSPOBMV002:~# df --portability /tmp | tail -1 | awk '{print $4}'
33M
This output have 2 problems and is not in the "df --portability /tmp" command, the problem is with "awk '{print $4}'" that selects the wrong column (Used column instead of Avail):
root@RHSPOBMV002:~# df --portability /tmp
Filesystem Type Size Used Avail Use% Mounted on
/dev/mapper/vgroot-lvtmp xfs 5.0G 33M 5.0G 1% /tmp
Then we have the problem that the output is not an integer value due to the parsed "M" value.
To fix this issues I simple changed the line:
cmd = "df --portability /tmp | tail -1 | awk '{print $4}'"
to
cmd = "df -k /tmp | tail -1 | awk '{print $5}'"
But for me the worst issue is with the scp that can't parse the correct file directory to validate the installation, as I mentioned in the previous post. (Error: scp failed. Tried to retrieve '/opt/vertica/log/verify-latest.xml')
Thanks,
Sandro

I was able to debug the df issue, for what it's worth. So far I have not found any other occurrences of the ssh issue, nor can I reproduce it.

Here's my tests, findings, and theory on why it happens. Seems to be due to user customization of the df command defaults in .bashrc.

Redhat 7.4

[root@partg9-010 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.4 (Maipo)
[root@partg9-010 ~]# df --portability /tmp
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda3 50264616 3295472 44392760 7% /
[root@partg9-010 ~]# df --portability /tmp | tail -1 | awk '{print $4}'
44392760

Redhat 7.7

[root@part14 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.7 (Maipo)
[root@part14 ~]# df --portability /tmp
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda1 286141864 6872620 264710988 3% /
[root@part14 ~]# df --portability /tmp | tail -1 | awk '{print $4}'
264710988

CentOS 7.4

[root@localhost ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
[root@localhost ~]# df --portability /tmp
Filesystem 1024-blocks Used Available Capacity Mounted on
/dev/sda2 20027216 12685276 6301556 67% /
[root@localhost ~]# df --portability /tmp | tail -1 | awk '{print $4}'
6301556

Noticed the customer output of df was different than the default I was getting. Sizes were human readable and the file system type column was present. So their df is using something more like below. The added file system type column is what's causing the awk $4 to be incorrect.

[root@localhost ~]# df -Th --portability /tmp
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 ext4 20G 13G 6.1G 67% /
[root@localhost ~]# df -Th --portability /tmp | tail -1 | awk '{print $4}'
13G

Sounds like in the user's .bashrc the df command has been aliased to include some additional dash options. Here I added an alias for df with the -Th. And when I run the df command without those options I get the same extended offset by 1 output I previously got by adding -Th on the command line (pre alias).

[root@localhost ~]# cat .bashrc

.bashrc

User specific aliases and functions

alias df='df -Th'

Source global definitions

if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

[root@localhost ~]# source .bashrc
[root@localhost ~]# df --portability /tmp
Filesystem Type Size Used Avail Use% Mounted on
/dev/sda2 ext4 20G 13G 6.1G 67% /
[root@localhost ~]# df --portability /tmp | tail -1 | awk '{print $4}'
13G

Thanks Stephen for the investigation - our customer confirmed a df alias was at the "root" of the vertica install failure. This will hopefully increase their confidence in our solution.

Hi Doug,
He's right, I found that the user root have alias configured in .bash_profile:
alias df='df -PTh'
This kind of profile customization is made by our unix team that I was not aware of.
I'll keep this in mind in the future.
Thank you

Doug, Thanks for passing confirmation. I'm glad we were able to resolve at least that piece of it.