Folks,
So, for our upcoming production systems (CentOS 5.6 & chef-client 0.10.8), we have built our own local copy of monit 5.3.2 (5.3.2-1, to be precise), and put that on our internal repo. We want to force our machines to use this explicit version of monit, and not anything else. However, recently rpmforge posted 5.3.2-2, and now even though we try to lock down the explicit version we want, yum_package keeps trying to install monit-5.3.2-2.el5.rf instead of our own monit-5.3.2-1.x86_64.rpm.
Doing a “yum info monit” will come up with the reference to the rpmforge version, but at least there we can provide a “–disablerepo=rpmforge” and get it to find the version that we have on our internal repo server.
Trying to do the same thing within the yum_package provider fails, however – when searching the available provides, it still finds monit-5.3.2-2.el5.rf (which is only on rpmforge), but then when it goes to try to install this version it will apparently honor the “–disablerepo=rpmforge” option, and then the package doesn’t actually get installed.
Okay, so I could rebuild our version of the package (which I know works the way we want), and bump the version number. That will work right up to the point where rpmforge does this to me again. I’m looking for a better solution to this problem. Any ideas?
–
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
yum_package should be installing the specific version you asked for,
when you specify a version... that sounds like a bug in itself.
Have you tried turning off obsoletes processing? I found that it was
constantly messing me up for installing packages with puppet (haven't
migrated that set of systems to chef yet).
-Jesse
On Tue, Jan 31, 2012 at 14:46, Brad Knowles bknowles@ihiji.com wrote:
Folks,
So, for our upcoming production systems (CentOS 5.6 & chef-client 0.10.8), we have built our own local copy of monit 5.3.2 (5.3.2-1, to be precise), and put that on our internal repo. We want to force our machines to use this explicit version of monit, and not anything else. However, recently rpmforge posted 5.3.2-2, and now even though we try to lock down the explicit version we want, yum_package keeps trying to install monit-5.3.2-2.el5.rf instead of our own monit-5.3.2-1.x86_64.rpm.
Doing a "yum info monit" will come up with the reference to the rpmforge version, but at least there we can provide a "--disablerepo=rpmforge" and get it to find the version that we have on our internal repo server.
Trying to do the same thing within the yum_package provider fails, however -- when searching the available provides, it still finds monit-5.3.2-2.el5.rf (which is only on rpmforge), but then when it goes to try to install this version it will apparently honor the "--disablerepo=rpmforge" option, and then the package doesn't actually get installed.
Okay, so I could rebuild our version of the package (which I know works the way we want), and bump the version number. That will work right up to the point where rpmforge does this to me again. I'm looking for a better solution to this problem. Any ideas?
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
On Jan 31, 2012, at 2:29 PM, Jesse Campbell wrote:
yum_package should be installing the specific version you asked for,
when you specify a version... that sounds like a bug in itself.
Have you tried turning off obsoletes processing? I found that it was
constantly messing me up for installing packages with puppet (haven't
migrated that set of systems to chef yet).
Rackspace is totally b0rked right now (see http://status.mosso.com/2012/01/cloud-sites-control-panel-provisioning-degraded.html), but once I get something back that I can actually use, I'll take a look at the obsoletes processing and see if that helps.
Thanks!
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
On Tue, Jan 31, 2012 at 12:29 PM, Jesse Campbell hikeit@gmail.com wrote:
yum_package should be installing the specific version you asked for,
when you specify a version... that sounds like a bug in itself.
So long as it's a yum_package :install and not an :upgrade I believe
it should. Be sure to pass a complete "1.1-el5" version string as
well. Please open a ticket if this proves not to be the case.
Have you tried turning off obsoletes processing? I found that it was
constantly messing me up for installing packages with puppet (haven't
migrated that set of systems to chef yet).
No obsoletes processing quite yet: http://tickets.opscode.com/browse/CHEF-2680
--
Matthew Kent | http://magoazul.com
On Tue, Jan 31, 2012 at 11:46 AM, Brad Knowles bknowles@ihiji.com wrote:
Folks,
So, for our upcoming production systems (CentOS 5.6 & chef-client 0.10.8), we have built our own local copy of monit 5.3.2 (5.3.2-1, to be precise), and put that on our internal repo. We want to force our machines to use this explicit version of monit, and not anything else. However, recently rpmforge posted 5.3.2-2, and now even though we try to lock down the explicit version we want, yum_package keeps trying to install monit-5.3.2-2.el5.rf instead of our own monit-5.3.2-1.x86_64.rpm.
Doing a "yum info monit" will come up with the reference to the rpmforge version, but at least there we can provide a "--disablerepo=rpmforge" and get it to find the version that we have on our internal repo server.
Trying to do the same thing within the yum_package provider fails, however -- when searching the available provides, it still finds monit-5.3.2-2.el5.rf (which is only on rpmforge), but then when it goes to try to install this version it will apparently honor the "--disablerepo=rpmforge" option, and then the package doesn't actually get installed.
Okay, so I could rebuild our version of the package (which I know works the way we want), and bump the version number. That will work right up to the point where rpmforge does this to me again. I'm looking for a better solution to this problem. Any ideas?
With a specific version I believe so long as yum can see it you should
be able to install it with Chef. Check that it can by adding by
adding showdupesfromrepos=1 to yum.conf and running 'yum list
available'. Note this only applies to :install, if you are passing
:upgrade you are going to get the latest version.
The proper solution for this though is to run (and love) yum
priorities. Give your local repository a higher priority than rpmforge
- your version will effectively mask the newer one. This is a better
long term solution then someone accidentally upgrading it down the
road.
--
Matthew Kent | http://magoazul.com
On Jan 31, 2012, at 3:44 PM, Matthew Kent wrote:
So long as it's a yum_package :install and not an :upgrade I believe
it should. Be sure to pass a complete "1.1-el5" version string as
well. Please open a ticket if this proves not to be the case.
We don't do :upgrades anymore in our recipes. We're preparing to lock everything down for the launch into actual production, so everything is a :install now. For our own packages that we have built, we do not currently have any additional version or release numbering beyond what I previously mentioned. However, that is a good idea.
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
On Jan 31, 2012, at 3:44 PM, Matthew Kent wrote:
With a specific version I believe so long as yum can see it you should
be able to install it with Chef. Check that it can by adding by
adding showdupesfromrepos=1 to yum.conf and running 'yum list
available'. Note this only applies to :install, if you are passing
:upgrade you are going to get the latest version.
I had enabled showdupesfromrepos, and on the command-line I could see multiple versions with a "yum info", but there was only ever one version showing up within a chef-client run.
The proper solution for this though is to run (and love) yum
priorities. Give your local repository a higher priority than rpmforge
- your version will effectively mask the newer one. This is a better
long term solution then someone accidentally upgrading it down the
road.
I had gone with yum priorities previously, but so far as I can tell the yumrepo cookbook doesn't give you a way to implement that sort of thing. It may be time to ditch the yumrepo cookbook and simply put everything into the main yum cookbook that we had been doing through yumrepo.
I guess I need to take a closer look at the yum cookbook.
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
I had gone with yum priorities previously, but so far as I can tell the yumrepo cookbook doesn't give you a way to implement that sort of thing. It may be time to ditch the yumrepo cookbook and simply put everything into the main yum cookbook that we had been doing through yumrepo.
I guess I need to take a closer look at the yum cookbook.
The yumrepo cookbook is simply a collection of recipes which enable
common repos by utilizing the yum_repository LWRP in the upstream yum
cookbook. I don't personally use yum priorities, or else I would submit
that feature upstream to be incorporated into yum::yum (manages the
yum.conf to enable the priorities plugin) and yum_repository (LWRP which
manages the repos).
If that feature were available in the yum cookbook, you could then
easily modify the yumrepo cookbook locally to utilize priorities.
Brad, how are you specifying the version when asking for a specific
version? Also, what shows up when you do a yum list? might just be a
matter of typing the version a slightly different way, the yum
cookbook is quite picky...
-Jesse
On Tue, Jan 31, 2012 at 18:11, Eric G. Wolfe eric.wolfe@marshall.edu wrote:
I had gone with yum priorities previously, but so far as I can tell the
yumrepo cookbook doesn't give you a way to implement that sort of thing. It
may be time to ditch the yumrepo cookbook and simply put everything into the
main yum cookbook that we had been doing through yumrepo.
I guess I need to take a closer look at the yum cookbook.
The yumrepo cookbook is simply a collection of recipes which enable common
repos by utilizing the yum_repository LWRP in the upstream yum cookbook. I
don't personally use yum priorities, or else I would submit that feature
upstream to be incorporated into yum::yum (manages the yum.conf to enable
the priorities plugin) and yum_repository (LWRP which manages the repos).
If that feature were available in the yum cookbook, you could then easily
modify the yumrepo cookbook locally to utilize priorities.
On Jan 31, 2012, at 10:48 PM, Jesse Campbell wrote:
Brad, how are you specifying the version when asking for a specific
version? Also, what shows up when you do a yum list? might just be a
matter of typing the version a slightly different way, the yum
cookbook is quite picky...
The version that we had built is 5.3.2-1. No additional sub-versions, patch releases, etc.... That would have been fine, if yum allowed us to disable searching specific repos for more recent versions.
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
It does :]
Can you actually paste in here the output of the yum list?
On Wed, Feb 1, 2012 at 09:11, Brad Knowles bknowles@ihiji.com wrote:
On Jan 31, 2012, at 10:48 PM, Jesse Campbell wrote:
Brad, how are you specifying the version when asking for a specific
version? Also, what shows up when you do a yum list? might just be a
matter of typing the version a slightly different way, the yum
cookbook is quite picky...
The version that we had built is 5.3.2-1. No additional sub-versions, patch releases, etc.... That would have been fine, if yum allowed us to disable searching specific repos for more recent versions.
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1
On Feb 1, 2012, at 9:11 AM, Jesse Campbell wrote:
It does :]
Can you actually paste in here the output of the yum list?
Loaded plugins: fastestmirror
Loading mirror speeds from cached hostfile
- base: mirrors.easynews.com
- epel: fedora-epel.mirror.lstn.net
- extras: mirror.raystedman.net
- updates: centos.mirrorcatalogs.com
Installed Packages
monit.x86_64 5.3.2-2.el5.rf installed
Available Packages
monit.x86_64 4.9-1.el5.rf rpmforge
monit.x86_64 4.9-2.el5.rf rpmforge
monit.x86_64 4.10.1-8.el5 epel
monit.x86_64 5.0-1.el5.rf rpmforge
monit.x86_64 5.0.3-2.el5.rf rpmforge
monit.x86_64 5.1.1-1.el5.rf rpmforge
monit.x86_64 5.2-1.el5.rf rpmforge
monit.x86_64 5.2.3-1.el5.rf rpmforge
monit.x86_64 5.2.4-1.el5.rf rpmforge
monit.x86_64 5.2.5-1.el5.rf rpmforge
monit.x86_64 5.3.2-1 ihiji
monit.x86_64 5.3.2-1.el5.rf rpmforge
monit.x86_64 5.3.2-2.el5.rf rpmforge
--
Brad Knowles bknowles@ihiji.com
SAGE Level IV, Chef Level 0.0.1