Cookbook version

4.1.0

Chef-client version

12.14.89

Platform Details

redhat 6

Scenario:

I intended to enable a yum repo, but setting only the yum//enable attribute doesn't do the trick. It also requires setting the yum//managed attribute to true before a file is dropped onto /etc/yum.repos.d/.repo.

Steps to Reproduce:

in a role, set the enabled attribute to true:

    "yum": {
      "remi": {
        "enabled": true
      }
    }

Expected Result:

I should see /etc/yum.repos.d/remi.repo on the target node. Setting the enabled attribute should imply that the managed attribute is also true.

Actual Result:

nothing is created.

Sometimes repo file may contain credentials and it's not secure to have file permission as 0644.

Cookbook doesn't allow to set file (repo) permission and even if you override it using file resource, it's going to set it back to 0644 during next chef-client run and it will loop forever.

https://github.com/opscode-cookbooks/yum/blob/master/providers/repository.rb#L46

What about having an attribute for that ?

Thanks

Hi:

The default value of /var/cache/yum/$basearch/$releasever in ./attributes/main.rb does not actually have $basearch and $releasever substituted with their values on CentOS 5:

[vagrant@default-centos-510 $releasever]$ pwd
/var/cache/yum/$basearch/$releasever
[vagrant@default-centos-510 $releasever]$ ls
base  epel  extras  updates

Which is not technically an invalid path, but it is a bit ugly and has some interesting side effects.

If:

• a repository is installed without using the yum cookbook (via a noarch rpm, which is a common way to install repo configs, or just directly as a file managed by chef in to /etc/yum.repos.d/)
• the repository has a GPG key for either repository metadata or rpm signature checking
• a repository is installed using the yum cookbook AFTER the above happens

Then:

• the GPG keys will appear to have failed being imported

because the gpg keys are written to the cachedir, then the cachedir is overwritten by chef to be "/var/cache/yum/$basearch/$releasever", and so yum can't find keys written to the old cachedir.

Anyone using CentOS 6 or CentOS 7 wouldn't be affected because:

• the default path on those systems is /var/cache/yum/$basearch/$releasever
• the substitution actually works there.
• 99.999...9% of people never touch /var/cache/yum/$basearch/$releasever so even when yum.conf gets overwritten by chef, it is overwritten to the default value where all the directories and keys and stuff already are.

On CentOS 5, the default path is: /var/cache/yum.

I'd suggest changing the default path to be /var/cache/yum in the yum cookbook for CentOS 5 and leaving the default path unchanged for CentOS 6 and 7 as it works fine as is.

In the documentation for the global parameters, it says that keepcache defaults to true. However, in the attributes section, it says the default is false.

Cookbook version

5.1.0

Chef-client version

13.8.5

Platform Details

CentOS Linux 7.5

Scenario:

Perhaps I'm misunderstanding how yum_globalconfig works, but I'm trying to get it to create an /etc/yum.conf file with attributes that I set in default['yum']['main']. The attributes are set, but the /etc/yum/conf file that is created doesn't reflect those attributes.

Steps to Reproduce:

In my cookbook I have the following:

node.default['yum']['main']['exclude'] = 'foo'
yum_globalconfig '/etc/yum.conf' do
    action :create
end 

Expected Result:

I expect to see an "exclude=" line in /etc/yum.conf, e.g.

[main]
cachedir=/var/cache/yum/$basearch/$releasever
debuglevel=2
exactarch=1
exclude=foo
gpgcheck=1

This is what I get if I actually put the 'exclude' statement inside yum_globalconfig, like this:

yum_globalconfig '/etc/yum.conf' do
    exclude 'foo'
    action :create
end 

But I prefer to do this with attributes.

Actual Result:

The 'exclude=' line is missing from /etc/yum.conf:

[main]
cachedir=/var/cache/yum/$basearch/$releasever
debuglevel=2
exactarch=1
gpgcheck=1

yum makecache fails inside the yum_repository provider when you point to a mirror with an older repomd.xml than what has already been downloaded. This could happen if you start out pointing to an official mirror, then reconfigure yum to point to your own local mirror (which may not have had a chance to sync up yet):

Mixlib::ShellOut::ShellCommandFailed
------------------------------------
Expected process to exit with [0], but received '1'
---- Begin output of yum -q makecache --disablerepo=* --enablerepo=foo ----
STDOUT:
STDERR: Not using downloaded repomd.xml because it is older than what we have:
 Current  : Tue Oct  7 15:14:53 2014
 Downloaded: Thu Oct  2 15:00:04 2014
http://example.com/repodata/filelists.xml.gz: [Errno -1] Metadata file does not match checksum
Trying other mirror.
Error: failure: repodata/filelists.xml.gz from foo: [Errno 256] No more mirrors to try.
---- End output of yum -q makecache --disablerepo=* --enablerepo=foo ----
Ran yum -q makecache --disablerepo=* --enablerepo=foo returned 1

I think the solution is to run a yum clean before running yum makecache. Unless there's some flag I'm missing to force yum to use the older repomd.xml.

I would like to have "disable the repository action available".
Do you think it can be useful?

I might look into that...

Enhancement request: it would be helpful if this cookbook could help use createrepo to create a local repository. This could either be another resource, or a property on the repository resource.

The yum clean command only operates against repositories that are currently defined and enabled.
From the yum man page:

CLEAN OPTIONS
The following are the ways which you can invoke yum in clean mode. Note
that "all files" in the commands below means "all files in currently
enabled repositories". If you want to also clean any (temporarily)
disabled repositories you need to use --enablerepo=’*’ option.

In the provider, the repository config file is deleted and then the cache is cleaned; however, this means that the cache is left intact for the cache that you just removed.
It looks like the provider is trying to explicitly enable the deleted repo, but if you try this on a box with a repo that's undefined, you get an error:

[root@server01 yum]# yum clean all --disablerepo=* --enablerepo=chef_stable
Loaded plugins: security


Error getting repository data for chef_stable, repository not found

The provider should try to flush the cache first, delete the repository file, and then reload the cache.

A :before timer could be used instead of :immediately, but that is only supported in Chef 12+ somewhere. Alternatively, an only_if block could be used to test for the file's existence, which would preserve chef 11 support.

If you attempt to set 'diskspacecheck' to 'false', the diskspacecheck parameter does not get written to the config file at all. Because the parameter defaults to true, there is no way to set it to false via this cookbook.

the obsoletes attribute is defaulted to nil
the resource for globalconfig then sets the default of true.

when the recipe runs this "under the covers" set the default to true which chef compiles the resource in.

the only way to make obsoletes false in this scenario, i think, is to make a node override of false.

i would request that the attribute be defaulted to true and to have the resource not have a default

Hi - I'm not certain this is a bug with this cookbook, so apologies in advance if not. I have a problem installing a repository with repo_gpgcheck = true without manual intervention.

Version info:

• Chef 12.3.0
• Centos 7.0
• yum cookbook 3.6.1

Steps to reproduce:

Converge the following recipe:

# somecookbook/recipes/default.rb

yum_repository "passenger" do
  description "Phusion Passenger repository"
  baseurl "https://oss-binaries.phusionpassenger.com/yum/passenger/el/$releasever/$basearch"
  gpgcheck false
  repo_gpgcheck true
  gpgkey "https://packagecloud.io/gpg.key"
end

Output:

[2015-06-19T12:31:57+00:00] ERROR: yum_repository[passenger] (somecookbook::default line 14) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[yum-makecache-passenger] (/tmp/kitchen/cookbooks/yum/providers/repository.rb line 61) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
---- Begin output of yum -q makecache --disablerepo=* --enablerepo=passenger ----
STDOUT: Is this ok [y/N]:
STDERR: Importing GPG key 0xD59097AB:
 Userid     : "packagecloud ops (production key) <[email protected]>"
 Fingerprint: 418a 7f2f b0e1 e6e7 eabf 6fe8 c2e7 3424 d590 97ab
 From       : https://packagecloud.io/gpg.key
https://oss-binaries.phusionpassenger.com/yum/passenger/el/7/x86_64/repodata/repomd.xml: [Errno -1] Gpg Keys not imported, cannot verify repomd.xml for repo passenger
Trying other mirror.

The problem appears to be that an interactive prompt is generated, receives the default response and the repo verification fails as a result, preventing the makecache call from succeeding. If I manually run the command with -y on the node, the recipe then converges successfully:

$ yum -q makecache -y --disablerepo=* --enablerepo=passenger

FWIW this is how packagecloud's own cookbook handles it. Even if I switch the key reference to a local file (even one in /etc/pki/rpm-gpg) the prompt still appears and the node fails to converge.

Would a patch adding the -y flag to the makecache call be considered, or is that barking up completely the wrong tree?

Cookbook version

• yum (3.10.0)

Chef-client version

Starting Chef Client, version 12.9.41

Platform Details

CentOS 6.7

Scenario:

Per the baseurl documentation i expect to be able to specify multiple url.

baseurl - Must be a URL to the directory where the yum repository's 'repodata' directory lives. Can be an http://, ftp:// or file:// URL. You can specify multiple URLs in one baseurl statement.

Steps to Reproduce:

yum_repository 'centos' do
description "demo"
baseurl [ 'http://mirror.hmc.edu/centos/6.7/os/x86_64/', 'http://mirrors.liquidweb.com/CentOS/6.7/os/x86_64/ ]
gpgkey 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-CentOS-6'
action :create
end

Expected Result:

this should produce 1 baseurl entry and the addition entry should be url. as in manpage
reference http://linux.die.net/man/5/yum.conf

baseurl Must be a URL to the directory where the yum repository's 'repodata' directory lives. Can be an http://, ftp:// or file:// URL. You can specify multiple URLs in one baseurl statement. The best way to do this is like this:

[repositoryid]
name=Some name for this repository
baseurl=url://server1/path/to/repository/
url://server2/path/to/repository/
url://server3/path/to/repository/

Actual Result:

only produces a single baseurl

@someara It looks like the order here was accidentally reversed. The cache should be cleaned before makecache gets called.

https://github.com/chef-cookbooks/yum/blob/v3.6.0/providers/repository.rb#L49-L50

We are using this cookbook on Centos 6.4, and get the folowing error, as the repository.rb never makes the nessessary folder etc/yum.repos.d
Chef::Exceptions::EnclosingDirectoryDoesNotExist

template[/etc/yum.repos.d/mysql56-community.repo](/tmp/kitchen/cache/cookbooks/yum/providers/repository.rb line 39) had an error: Chef::Exceptions::EnclosingDirectoryDoesNotExist: Parent directory /etc/yum.repos.d does not exist.

on centos 6.6 this error disappears, so its version specific.

greetings alex

EDIT: was using accidently ubuntu 12.04 while this error occured, issue closed

I have a recipe which installs several repositories:

%w{ftp3 ftp3-updates ftp3-optional ftp3-supplementary}.each do |repo|
  yum_repository repo do
    description node['yum'][repo]['description']
    baseurl node['yum'][repo]['baseurl']
    gpgkey node['yum'][repo]['gpgkey']
    enabled node['yum'][repo]['enabled']
  end
end

I've observed a significant delay after each repository add instead of waiting until all are complete. This per-repository action seems to unnecessarily extend the recipe's run time by several minutes.

I think that I'd like the ability to suppress the makecache and Chef yum cache rebuild until after I've added all of the repositories. Then, I can manually trigger the actions.

it is failing if you setup any numeric value like 2 ..
and if is set up "2", it is failing in repo side...

Have you guys tested it..
I am setting up values in environment file

This change 121da3b which introduced a yum clean headers call in place of yum clean all has broken compatibility with dnf. We had been using this cook with dnf on fedora-22 for several weeks with no other issues, FWIW.

    docker: [2015-09-08T01:20:15+00:00] ERROR: yum_repository[fedora] (pantheon_package_repository::fedora line 8) had an error: Mixlib::ShellOut::ShellCommandFailed: execute[yum clean fedora] (/opt/pantheon/infrastructure/cookbooks/yum/providers/repository.rb line 55) had an error: Mixlib::ShellOut::ShellCommandFailed: Expected process to exit with [0], but received '1'
    docker: ---- Begin output of yum clean headers --disablerepo=* --enablerepo=fedora ----
    docker: STDOUT:
    docker: STDERR: Yum command has been deprecated, redirecting to '/usr/bin/dnf clean headers --disablerepo=* --enablerepo=fedora'.
    docker: See 'man dnf' and 'man yum2dnf' for more information.
    docker: To transfer transaction metadata from yum to DNF, run:
    docker: 'dnf install python-dnf-plugins-extras-migrate && dnf-2 migrate'
    docker:
    docker: Error: invalid clean argument: u'headers'
    docker: Mini usage:
    docker:
    docker: clean [packages|metadata|dbcache|plugins|expire-cache|all]

yum clean metadata might be an acceptable compromise for yum and dnf? I'm not sure what the difference between metadata and headers is, though, and mostly just wondering if someone else already has a good answer here.

not entirely sure if this is the right place.

one of my dependencies uses the yum cookbook version ~>3.6 and i've come to realize that it removes the pair releasever=latest from /etc/yum.conf, thereby breaking the rolling release mechanism of Amazon's distro. This should probably be considered, as the default in this cookbook equals nil, afaik.

does that make sense?

Cookbook version

yum 3.10.0

Chef-client version

version 12.11.18

Platform Details

Centos openlogic- 7.1 azure VM

Scenario:

I want to install these packages
gcc gcc-c++ graphviz graphviz-devel patchutils gd gd-devel wget perl* -x perl-homedir

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?]

Expected Result:

Installation of above packages

How can I install them?

Cookbook version

5.1.0

Chef-client version

12 - 15

Platform Details

CentOS Linux release 7.7.1908

Scenario:

I'd like to use yum_globalconfig to set ip_resolve=4 in the default yum configuration file.

Steps to Reproduce:

Nothing to do here.

Expected Result:

Ability to leave ip_resolve unset, or set to either 4 or 6

Actual Result:

n/a

From the documentation of both parameters in http://linux.die.net/man/5/yum.conf: "You can also change from the default of using seconds to using days, hours or minutes by appending a d, h or m respectively."

Please change the regexes for both to \d+[dhm]?

Cookbook version

5.1.0

Chef-client version

12.13.37

Platform Details

macOS

Scenario:

Trying to download yum 5.1.0 from the chef supermarket

Steps to Reproduce:

knife cookbook site show yum

Expected Result:

expect knife to show 5.1.0 version since it was release back in Aug per the CHANGELOG

Actual Result:

Only shows the 5.0.1 version

average_rating:  
category:        Other
created_at:      2011-04-20T22:16:12.000Z
deprecated:      false
description:     Configures various yum components on Red Hat-like systems
external_url:    https://github.com/chef-cookbooks/yum
issues_url:      https://github.com/chef-cookbooks/yum/issues
latest_version:  https://supermarket.chef.io/api/v1/cookbooks/yum/versions/5.0.1

I have a use case where I am using a third party cookbook which installs a rpm package via a yum repository on a RHEL 7 OS in AWS. The problem I am experiencing is that the rpm package is in a RHEL optional repository that is not enabled by default. I figured with this cookbook, I could own the AWS RHEL repository and create definitions for all of the various AWS RHEL repositories.

However instead of doing that, it may be an interesting use case (since this cookbook effectively owns the yum_repository namespace 😄 ) if yum_repository could have two actions to enable and disable a repository without having to own the entire repository definition. I figured behind the scenes it would perform a yum-config-manager --enable or yum-config-manager --disable behind the scenes.

If this is something that you think would fit into the purview of this cookbook, I would be more than happy to whip something up.

Just wanted to run this past you before doing so.

Thanks!

I have a deployment scenario in which I only want to use a specific baseurl for the repos. I can set this just fine with attributes, however there does not seem to be a way to unset mirrorlist.

Scenario:

The apt Cookbook provides a mechanism to do an apt-get update as part of the chef run in its default recipe. I am wondering if the yum Cookbook should provide a similar construct for parity which seems like it would be yum makecache

Cookbook version

[Version of the cookbook where you are encountering the issue]

Chef-client version

[Version of chef-client in your environment]

Platform Details

[Operating system distribution and release version. Cloud provider if running in the cloud]

Scenario:

[What you are trying to achieve and you can't?]

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?]

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?]

Actual Result:

[What actually happens after the reproduction steps? Include the error output or a link to a gist if possible.]

i don't see the chef client rpm for rhel 8
https://downloads.chef.io/chef, Can someone please tell me

Cookbook version

5.0.0

Question

I noticed that this cookbook is certified for use with Chef Client version 12.14+. The question I have is that I would have thought the the community maintained cookbooks published by Chef would have the same backwards compatibility promise as the Chef Client (back to v12.0). Is this no longer the case? Just curious.

Here is an example of my yum.conf after a chef run.

My role set the attribute node["yum"]["main"]["tolerant"] to TrueClass. Note how the value was not turned into a 1 inside of the config.

I also noticed that multilib_policy is set in the documentation as an array, but the resource demands a string. Perhaps other config attributes are amiss as well!

# This file was generated by Chef
# Do NOT modify this file by hand.

[main]
cachedir=/var/cache/yum/$basearch/$releasever
debuglevel=2
distroverpkg=centos-release
exactarch=1
gpgcheck=1
installonly_limit=3
keepcache=0
logfile=/var/log/yum.log
multilib_policy=best
obsoletes=1
plugins=1
tolerant=true
tsflags=repackage

We need to rework the tests to use working repos on all platforms. We're failing due to poorly setup tests at the moment.

Any chance support for whyrun on globalconfig could be added, please? Really been relying on whyruns these days for quality assurance. Share the whyrun love!

When creating a yum repo, I want to disable this yum repo by setting enabled to false, but the chef client will run into error when yum -q makecache --disablerepo=* --enablerepo=#{new_resource.repositoryid} .

The related code :
https://github.com/opscode-cookbooks/yum/blob/master/providers/repository.rb#L56

yum-epel should be used. README shows an example of yum_repository to set up EPEL.

Give me a verdict and I will submit a README patch with some other tiny typo fixes as well.

Warning message from Chef 13

==> Server-003: Deprecated features used!

==> Server-003:   Cannot specify both default and name_property together on property path of resource yum_globalconfig. Only one (name_property) will be obeyed. In Chef 13, this will become an error. at 1 location:

==> Server-003:     - /var/chef/cache/cookbooks/yum/resources/globalconfig.rb:76:in `class_from_file'

==> Server-003:   version nil currently does not overwrite the value of version. This will change in Chef 13, and the value will be set to nil instead. Please change your code to explicitly accept nil using "property :version, [MyType, nil]", or stop setting this value to nil. at 3 locations:

==> Server-003:     - /var/chef/cache/cookbooks/python/recipes/pip.rb:52:in `block in from_file'

==> Server-003:     - /var/chef/cache/cookbooks/python/recipes/virtualenv.rb:25:in `block in from_file'

==> Server-003:     - /var/chef/cache/cookbooks/python/providers/pip.rb:98:in `load_current_resource'

yum_repository implements several username/password attributes, but doesn't allow to hide them from chef run output.

Support of sensitive option of template resource in https://github.com/chef-cookbooks/yum/blob/297977cd7ca3f0dda7042709913981273e638b4c/providers/repository.rb#L46-L60 would be useful to protect such sensitive information

As per resources sslverify can take either true or false
resources/repository.rb
attribute :sslverify, :kind_of => [TrueClass, FalseClass], :default => true
but in template it checks sslverify is nil ..
<% unless @config.sslverify.nil? %>
sslverify=<%= @config.sslverify %>
<% end %>

Because of this when I use the LWRP
sslverify nil => repo file has sslverify=true

In my opinion
attribute :sslverify, :kind_of => [TrueClass, FalseClass], :default => true
should be
attribute :sslverify, :kind_of => [TrueClass, FalseClass], :default => nil

An ongoing issue for testing.

I will do the initial infrastructure which will look similar to https://github.com/chef-cookbooks/yum/blob/master/TESTING.md adjusted to fit our needs.

We're testing a bunch of cookbooks using kitchen and vagrant-cachier to cache yum, apt, rubygems and a few other packages.

However the yum clean operation that got added in version 3.6 is a bit of an inconvenience because it blows away all yum caches.

I'm happy to submit a PR to make that behaviour optional by specifying a yum_clean (?) parameter that defaults to true, but can be turned off if desired.

Thoughts?

/cc @someara (the original author who added that line of code)

Cookbook version

5.0.1

Chef-client version

12.19.36

Platform Details

AWS, various AMIs

Scenario:

Amazon releases new AMIs semi-annually. New AMIs may include breaking changes, somewhat akin to a RHEL or CentOS major release. I would like to lock the AMI to a specific release. Per Amazon's instructions:

To lock existing instances to their current version (indicated in /etc/system-release), edit /etc/yum.conf. Comment out the line that reads releasever=latest and run yum clean all to clear the cache.

Steps to Reproduce:

I have created a role to configure the yum cookbook to render /etc/yum.conf:

{
  "name": "my_yum",
  "description": "Apply MyCO's standard config to yum.conf",
  "json_class": "Chef::Role",
  "default_attributes": {
      "yum": {
          "main": {
              "exclude": "kernel* nginx* mongo* mysql-server* varnish* Percona-Server-server*",
              "exactarch": true,
              "obsoletes": true,
              "gpgcheck": true,
              "deltarpm": false
          }
      }
  },
  "chef_type": "role",
  "run_list": [
      "recipe[yum]"
  ],
  "env_run_lists": {
  }
}

On Amazon Linux boxes (as documented), this creates an /etc/yum.conf containing:

releasever=latest

Expected Result:

I would like to create an /etc/yum.conf file on Amazon Linux without any releasever line.

Actual Result:

If I use "releasever": false, I get a validation error from here. If I use "releasever": "", I end up with releasever= in /etc/yum.conf, which breaks yum.

As noted here:

http://seven.centos.org/2015/05/signed-repository-metadata-is-now-available-for-centos-6-and-7-for-the-updates-repo/

CentOS repos now make use of gpg-signed repository metadata. Would be great to be able to set this up with this cookbook (and to turn it on by default in the "cents" cookbook).

Cookbook version

3.11.0

Chef-client version

12.6.0

Platform Details

RHEL 6, 7

Scenario:

Is there any reason, aside from backward compatibility with previous versions of this cookbook, why node['yum']['main']['exclude'] is a space-separated string and not an array that then gets munged in the code for the yum_globalconfig resource? On the surface, an array makes much more sense for the data type, to me.

Maybe an array for a 4.0.0 release?

Hey. mode and options attributes appear to be missing from the yum_repository documentation. would you accept a pull request to fix it?

The repository resource doesn't check to see if /etc/yum.repos.d directory already exists.

This caused a problem for me on Ubuntu (I know Ubuntu isn't technically supported, but I have a bunch of RPMs to install, and adding a local yum repo seemed like the way to go).

hi,
Could i download yum rpm to intel's machine and install in another ARM64 machine？ because i have a x86 machine which can surfer internet and a arm64 machine which cannot surfer internet, but i need use yum to install massive RPM to ARM64. wish your response, thank you very much

Will DNF support be included soon? I think there was a DNF workaround included in Chef: chef/chef#3774

I've tried cleaning, making fresh caches, etc. no luck.

Recipe: python::package

• yum_package[python] action install (up to date)

• yum_package[python-devel] action install

  Error executing action install on resource 'yum_package[python-devel]'

  Chef::Exceptions::Exec

  yum -d0 -e0 -y install python-devel-2.6.6-51.el6 returned 1:
  STDOUT:
  STDERR:

  Error Downloading Packages:
  python-devel-2.6.6-51.el6.x86_64: failure: python-devel-2.6.6-51.el6.x86_64.rpm from oracle_linux_base_6: [Errno 256] No more mirrors to try.

  Resource Declaration:

  In /var/chef/cache/cookbooks/python/recipes/package.rb

  41: package pkg do
  42: action :install
  43: end
  44: end

  Compiled Resource:

  Declared in /var/chef/cache/cookbooks/python/recipes/package.rb:41:in `block in from_file'

  yum_package("python-devel") do
  action [:install]
  retries 0
  retry_delay 2
  default_guard_interpreter :default
  package_name "python-devel"
  version "2.6.6-51.el6"
  flush_cache {:before=>false, :after=>false}
  declared_type :package
  cookbook_name "python"
  recipe_name "package"
  end

Running handlers:
[2015-08-31T17:51:16+00:00] ERROR: Running exception handlers
Running handlers complete
[2015-08-31T17:51:16+00:00] ERROR: Exception handlers complete
Chef Client failed. 1 resources updated in 6.802199844 seconds
[2015-08-31T17:51:16+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2015-08-31T17:51:16+00:00] ERROR: yum_package[python-devel](python::package line 41) had an error: Chef::Exceptions::Exec: yum -d0 -e0 -y install python-devel-2.6.6-51.el6 returned 1:
STDOUT:
STDERR:

Error Downloading Packages:
python-devel-2.6.6-51.el6.x86_64: failure: python-devel-2.6.6-51.el6.x86_64.rpm from oracle_linux_base_6: [Errno 256] No more mirrors to try.

[2015-08-31T17:51:16+00:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)
[root@derp ~]# chef-client -v
Chef: 12.4.1
[root@derp ~]# yum -d0 -e0 -y install python-devel-2.6.6-51.el6
[root@derp ~]# echo $?
0
[root@derp ~]# rpm -q python-devel-2.6.6-51.el6
python-devel-2.6.6-51.el6.x86_64

I attempted to add a proxy attribute and have proxy=<proxyserver> show up in the yum.conf and it doesn't seems to show up.

I tried:
ip of proxy:port
proxy:port
http://proxy:port

None of them showed up 😦

After pulling in the yum 3.5.0 package all my converges on my 5.10 and 5.11 boxes fail on the yum-epel package with the following error

package[ca-certificates] (/var/chef/cache/cookbooks/yum/providers/repository.rb line 40) had an error: Chef::Exceptions::Package: No candidate version available for ca-certificates

CentOS 6.6 if fine