 |
For extra points, this was taken from an 'older' working host: $ rpm -q --whatprovides /usr/lib/fence-agents/bundled python-s3transfer-0.1.10-8.el7.noarch Work around hack for anyone encountering this issue who needs to get things working ASAP: sed -i -e 's/\/lib\//\/lib64\//' /usr/lib/python2.7/site-packages/awscli/clidriver.py And, the hack for everyone playing the puppet game: exec {'patch-clidriver': command => "sed -i -e 's/\/lib\//\/lib64\//' /usr/lib/python2.7/site-packages/awscli/clidriver.py", onlyif => '[ $(grep -c lib64 /usr/lib/python2.7/site-packages/awscli/clidriver.py) -eq 0 ]', path => ['/usr/bin', '/usr/sbin'], require => Package['awscli'] } |
|
|
Same issue here, after applying the latest system updates via "yum update", the aws cli no longer works, can't backup our files. # awscli-1.14.28-5.el7_5.1.noarch # python-s3transfer-0.1.13-1.el7.noarch # Traceback (most recent call last): File "/usr/bin/aws", line 19, in <module> import awscli.clidriver File "/usr/lib/python2.7/site-packages/awscli/clidriver.py", line 18, in <module> import botocore.session ImportError: No module named botocore.session |
|
|
This has also been killing our amazon auto scaling group bootstraps: ``` cloud-init: File "/usr/bin/aws", line 19, in <module> cloud-init: import awscli.clidriver cloud-init: File "/usr/lib/python2.7/site-packages/awscli/clidriver.py", line 18, in <module> cloud-init: import botocore.session cloud-init: ImportError: No module named botocore.session cloud-init: + EC2_ASG= cloud-init: ++ aws elb describe-load-balancers --region us-east-1 cloud-init: ++ jq -r '.LoadBalancerDescriptions[] | select(.Instances[].InstanceId == "i-XXX") | .LoadBalancerName ' cloud-init: Traceback (most recent call last): cloud-init: File "/usr/bin/aws", line 19, in <module> cloud-init: import awscli.clidriver cloud-init: File "/usr/lib/python2.7/site-packages/awscli/clidriver.py", line 18, in <module> ``` Not the first time this year python/aws-cli has killed hosts :-( |
 |
Attached patch is a result of the sed command in comment #1.
awscli-1.14.28-5-lib64fix.patch (477 bytes) |
|
|
I suspect that the patch to change this single occurrence of /usr/lib/ to /usr/lib64/ is not the correct fix. There's a big patch in the awscli package that adds those lines into the python source and all of those added lines are /usr/lib/. I suspect it happens to work by patching one file as that is adding the /usr/lib64 path to the PATH so just happens to fix it for all those others at the same time. I'm wondering if the problem package is actually python-s3transfer which is installing the bundled botocore stuff under /usr/lib64 on CentOS and I wonder if that is the same on RHEL or if RHEL uses /usr/lib/ instead. |
|
|
Confirmed. Problem is actually the python-s3transfer package in CentOS installs under /usr/lib64/fence-agents/bundled but under /usr/lib/fence-agents/bundled on RHEL. The patch to awscli to make it use the bundled version hardcodes the RHEL path into all the .py files so they do not find it on CentOS. It'll require a rebuild of python-s3transfer on CentOS 7.6 to fix this. |
 |
Category changed to python-s3transfer. |
 |
This is fixed in python-s3transfer-0.1.13-1.el7.0.1.noarch.rpm , whihc is syncing to the master server now. Should be in updates in about an hour on mirror.centos.org. |
|
|
Please note that users who have applied the bypass mentioned in the first comment of this bug report will have to reverse that change in order to work with the fixed package. |
|
|
On a fresh install of 7.6.1810 `yum install awscli` works as expected for me. (it did indeed install `python-s3transfer.noarch 0:0.1.13-1.el7.0.1`) Awesome! Thanks. |
|
|
I can confirm that the latest build of python-s3transfer resolves the issue for me. Thank you! |
- Anonymous
