The Puppet Labs Issue Tracker has Moved: https://tickets.puppetlabs.com
yumhelper.py: yum check-config fallback if yum module is not available does not work with yum 3.2.22
|Status:||In Topic Branch Pending Review||Start date:||05/01/2012|
|Affected Puppet version:||2.7.6||Branch:|
|Keywords:||yum yumhelper.py check-config python|
Ticket tracking is now hosted in JIRA: https://tickets.puppetlabs.com
I’m running Puppet on RHEL5.5. My environment has a PATH set up so that the default Python in my path is not
/usr/bin/python, but a newer version of Python. This new installation does not have a yum module. Til now, I haven’t been bothering to reset my PATH when running ‘puppet apply’ on my system, and for other reasons my sudoers setup passes the env through. Though idiosyncratic, this setup does give me the opportunity to test yumhelper.py’s fallback ability if it can’t find the yum module.
- Set PATH so that an installation of Python with no yum module is first on the path. Installing the latest Python 2.7 in your home directory, and putting
~/binfirst on the PATH, should do it.
- Modify sudoers as necessary to make sure that
env_resetis disabled for Puppet runs, ensuring that Puppet sees this PATH.
- Create a local yum repo, let’s say at
/var/lib/myrepo. Drop a test RPM in there; let’s call it
createrepo -d /var/lib/myrepoto update it.
- Set up a puppet manifest something like test.pp (see attached). Run
sudo puppet apply test.ppto install the package.
- Create a new version of the package, let’s say
test-1.1-1.x86_64.rpm, and copy it to the YUM repo. Run
createrepo --update -d /var/lib/myrepoto pick up the new package. Run
sudo yum clear expire-cacheto make sure the update will be seen right away by YUM.
- You could rerun
sudo puppet apply test.ppat that point, and it should fail when it invokes yumhelper.py to prefetch the ‘yum’ provider. But to make the root cause clearer, let’s run yumhelper.py directly. Do
sudo python /opt/puppet/lib/ruby/site_ruby/1.8/puppet/provider/package/yumhelper.py, where python resolves to your new instance of python.
The output should look something like:
_pkg test 0 1.1 1 ia32e
which correctly reports that the test package has been updated to 1.1-1. Your specific arch may vary depending on how you built your package. (BTW, this should be what you would see if you ran yumhelper.py with /usr/bin/python too, only in that case it would use the yum module to get this info.)
Root Cause & Workaround¶
Fortunately, the comments in yumhelper.py were clear enough that I know what’s wrong. The format of
yum check-config, used by the fallback, has changed between the last version yumhelper.py supports (2.*) and the version of yum I’m using (3.2.22). In this version, instead of arch being in its own space-delimited field, it’s now appended to the package name, e.g. “test.ia32e”. I don’t know when exactly this change was made in the output.
I have a workaround patch to yumhelper.py that checks the yum version using yum-version, and grabs the arch from the first space-delimited field in that case. I’ve submitted it here if anyone finds it useful, but it is most certainly not ready for integration at this point in time.
Other workarounds, of course, are to turn on
env_reset in sudoers, or otherwise run
puppet apply from an environment where PATH is standard and the yum module works.