The Puppet Labs Issue Tracker has Moved:

This issue tracker is now in read-only archive mode and automatic ticket export has been disabled. Redmine users will need to create a new JIRA account to file tickets using See the following page for information on filing tickets with JIRA:

Bug #14265 yum check-config fallback if yum module is not available does not work with yum 3.2.22

Added by Owen Smith over 3 years ago. Updated over 2 years ago.

Status:In Topic Branch Pending ReviewStart date:05/01/2012
Priority:LowDue date:
Assignee:-% Done:


Target version:-
Affected Puppet version:2.7.6 Branch:
Keywords:yum check-config python

We've Moved!

Ticket tracking is now hosted in JIRA:


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’s fallback ability if it can’t find the yum module.

Test Case

  1. 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 ~/bin first on the PATH, should do it.
  2. Modify sudoers as necessary to make sure that env_reset is disabled for Puppet runs, ensuring that Puppet sees this PATH.
  3. Create a local yum repo, let’s say at /var/lib/myrepo. Drop a test RPM in there; let’s call it test-1.0-1.x86_64.rpm. Run createrepo -d /var/lib/myrepo to update it.
  4. Set up a puppet manifest something like test.pp (see attached). Run sudo puppet apply test.pp to install the package.
  5. 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/myrepo to pick up the new package. Run sudo yum clear expire-cache to make sure the update will be seen right away by YUM.
  6. You could rerun sudo puppet apply test.pp at that point, and it should fail when it invokes to prefetch the ‘yum’ provider. But to make the root cause clearer, let’s run directly. Do sudo python /opt/puppet/lib/ruby/site_ruby/1.8/puppet/provider/package/, where python resolves to your new instance of python.

Expected Output

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 with /usr/bin/python too, only in that case it would use the yum module to get this info.)

Actual Output

You see:

 <type 'exceptions.AttributeError'>

Root Cause & Workaround

Fortunately, the comments in 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 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 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.

test.pp - Test manifest for local YUM installation of test package (223 Bytes) Owen Smith, 05/01/2012 01:24 pm

yumhelper_workaround_patch.txt Magnifier - Incomplete patch to to fix issue (1.53 KB) Owen Smith, 05/01/2012 01:24 pm


#1 Updated by Owen Smith over 3 years ago

Update to test case step 5: should be yum clean, not yum clear.

#2 Updated by Anonymous over 3 years ago

Owen, it doesn’t look like you have signed a CLA; if not, could you do that for us? The link to sign it is:

Without that we can’t use any code that you contribute.

#3 Updated by Kelsey Hightower over 3 years ago

  • Status changed from Unreviewed to Requires CLA to be signed
  • Assignee set to Owen Smith

#4 Updated by Owen Smith over 3 years ago

The CLA indicates I should sign somewhere (where?) and either mail or scan/email or fax. I followed a link to the online form instead (not mentioned in the agreement), and agreed through the form, so hopefully that took care of it?

#5 Updated by James Turnbull over 3 years ago

  • Status changed from Requires CLA to be signed to In Topic Branch Pending Review
  • Assignee changed from Owen Smith to Anonymous

#6 Updated by Anonymous over 2 years ago

  • Assignee deleted (Anonymous)

Also available in: Atom PDF