Hi Folks,
I am fairly new to using Puppet, but am trying to use it to control
production servers running:
- CentOS 5.5
- Puppet 2.6.3
- Yum 3.2.22
We would like to specify that certain versions of packages be loaded
on a system. Our requirement is to have fixed versions of all critical
packages upon which our applications depend. We do not want any
surprises due to unplanned updates to the latest and greatest release
of a critical software dependency.
We are using manifests with a package resource like:
package { "mysql": ensure => "5.0.77-4.el5_5.3", }
The problem we run into is that when one server is loaded the manifest
and puppet works like a charm. If some time passes and a later version
of a package is available in the yum repository and we attempt to load
another server using the same puppet catalog; then puppet will
complain that it is unable to load the specified version in the
manifest, because it found a later version via yum (e.g.
mysql-5.0.77-4.el5_5.4). The error message is shown below:
err: /Stage[base]/Centos-server-pack/Package[mysql]/ensure: change
from 5.0.77-4.el5_5.4 to 5.0.77-4.el5_5.3 failed: Could not update:
Failed to update to version 5.0.77-4.el5_5.3, got version
5.0.77-4.el5_5.4 instead at /etc/puppet/modules/centos-base-pkg/
manifests/init.pp:288
Has anyone else run into this problem or have an suggestions?
Thanks in advance for your advice.
Andy
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Hi Andy, That looks like the mysql RPM with version 5.0.77-4.el5_5.3 no longer exists in your Yum repository and it''s been replaced by 5.0.77-4.el5_5.4. If you want fine grained control of your RPMs with Puppet you''ll also need to manage your own Yum repo and make sure you control what goes in, but more importantly what gets removed. Are you removing old files from your repo or are you using someone elses Yum mirror? If I look in my own local copy of a CentOS 5.5 mirror I see both versions: centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.3.x86_64.rpm centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.4.i386.rpm centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.3.i386.rpm centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.4.x86_64.rpm On Nov 16, 4:46 am, Andy <andy....@gmail.com> wrote:> Hi Folks, > > I am fairly new to using Puppet, but am trying to use it to control > production servers running: > > - CentOS 5.5 > - Puppet 2.6.3 > - Yum 3.2.22 > > We would like to specify that certain versions of packages be loaded > on a system. Our requirement is to have fixed versions of all critical > packages upon which our applications depend. We do not want any > surprises due to unplanned updates to the latest and greatest release > of a critical software dependency. > > We are using manifests with a package resource like: > > package { "mysql": ensure => "5.0.77-4.el5_5.3", } > > The problem we run into is that when one server is loaded the manifest > and puppet works like a charm. If some time passes and a later version > of a package is available in the yum repository and we attempt to load > another server using the same puppet catalog; then puppet will > complain that it is unable to load the specified version in the > manifest, because it found a later version via yum (e.g. > mysql-5.0.77-4.el5_5.4). The error message is shown below: > > err: /Stage[base]/Centos-server-pack/Package[mysql]/ensure: change > from 5.0.77-4.el5_5.4 to 5.0.77-4.el5_5.3 failed: Could not update: > Failed to update to version 5.0.77-4.el5_5.3, got version > 5.0.77-4.el5_5.4 instead at /etc/puppet/modules/centos-base-pkg/ > manifests/init.pp:288 > > Has anyone else run into this problem or have an suggestions? > > Thanks in advance for your advice. > Andy-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Hi Luke, Thanks for the reply. I was wondering about the underlying repositories. When I did a "yum list all mysql" I only show the latest release. I am using the standard repos and mirrors for CentOS base, epel, extras, updates, addons, and rpmforge. Assuming I get the repository issue worked out, can I expect to hold the mysql version at the older release using puppet? We do this until we have verified the applications against the newer release before upgrading in production. Also, do you typically create your own mirrors of the repositories to control the repository contents? Thanks again for your help! Andy On Nov 16, 11:28 am, "luke.bigum" <luke.bi...@fasthosts.co.uk> wrote:> Hi Andy, > > That looks like the mysql RPM with version 5.0.77-4.el5_5.3 no longer > exists in your Yum repository and it''s been replaced by > 5.0.77-4.el5_5.4. > > If you want fine grained control of your RPMs with Puppet you''ll also > need to manage your own Yum repo and make sure you control what goes > in, but more importantly what gets removed. Are you removing old files > from your repo or are you using someone elses Yum mirror? If I look in > my own local copy of a CentOS 5.5 mirror I see both versions: > > centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.3.x86_64.rpm > centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.4.i386.rpm > centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.3.i386.rpm > centos55/updates/x86_64/RPMS/mysql-5.0.77-4.el5_5.4.x86_64.rpm > > On Nov 16, 4:46 am, Andy <andy....@gmail.com> wrote: > > > Hi Folks, > > > I am fairly new to using Puppet, but am trying to use it to control > > production servers running: > > > - CentOS 5.5 > > - Puppet 2.6.3 > > - Yum 3.2.22 > > > We would like to specify that certain versions of packages be loaded > > on a system. Our requirement is to have fixed versions of all critical > > packages upon which our applications depend. We do not want any > > surprises due to unplanned updates to the latest and greatest release > > of a critical software dependency. > > > We are using manifests with a package resource like: > > > package { "mysql": ensure => "5.0.77-4.el5_5.3", } > > > The problem we run into is that when one server is loaded the manifest > > and puppet works like a charm. If some time passes and a later version > > of a package is available in the yum repository and we attempt to load > > another server using the same puppet catalog; then puppet will > > complain that it is unable to load the specified version in the > > manifest, because it found a later version via yum (e.g. > > mysql-5.0.77-4.el5_5.4). The error message is shown below: > > > err: /Stage[base]/Centos-server-pack/Package[mysql]/ensure: change > > from 5.0.77-4.el5_5.4 to 5.0.77-4.el5_5.3 failed: Could not update: > > Failed to update to version 5.0.77-4.el5_5.3, got version > > 5.0.77-4.el5_5.4 instead at /etc/puppet/modules/centos-base-pkg/ > > manifests/init.pp:288 > > > Has anyone else run into this problem or have an suggestions? > > > Thanks in advance for your advice. > > Andy-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
On Nov 16, 11:03 am, Andy <andy....@gmail.com> wrote:> Also, do you typically create your own mirrors of the repositories to > control the repository contents?I don''t know about Luke, but I do. That provides not only control over the repository contents, but also (for me) much better performance, as my queries and package retrievals do not have to leave my internal network. I also get better availability because the repository has fewer clients, and if it ever goes down I can fix it. Moreover, you then have the option to rely on your local repository instead of Puppet for control of package versions. That is, maintain in your repository only those software versions you want to use, and let your Package resources all simply specify the "latest" version. No more tweaking manifests when you qualify a new package version! Cheers, John -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Using "latest" and controlling the repositories yourself is best practice I believe. On Nov 16, 2010 2:16 PM, "jcbollinger" <John.Bollinger@stjude.org> wrote:> > On Nov 16, 11:03 am, Andy <andy....@gmail.com> wrote: >> Also, do you typically create your own mirrors of the repositories to >> control the repository contents? > > I don''t know about Luke, but I do. That provides not only control > over the repository contents, but also (for me) much better > performance, as my queries and package retrievals do not have to leave > my internal network. I also get better availability because the > repository has fewer clients, and if it ever goes down I can fix it. > > Moreover, you then have the option to rely on your local repository > instead of Puppet for control of package versions. That is, maintain > in your repository only those software versions you want to use, and > let your Package resources all simply specify the "latest" version. > No more tweaking manifests when you qualify a new package version! > > > Cheers, > > John > > -- > You received this message because you are subscribed to the Google Groups"Puppet Users" group.> To post to this group, send email to puppet-users@googlegroups.com. > To unsubscribe from this group, send email topuppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> .> For more options, visit this group athttp://groups.google.com/group/puppet-users?hl=en.>-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
To All, Thanks so much for the input. We have plans on mirroring the repositories that we need to control the production package versions and another mirror for testing/development that will contain upstream versions. The usage of the "ensure => latest" parameter makes sense to us in this context. Thanks again, Andy On Nov 16, 5:26 pm, Nigel Kersten <ni...@puppetlabs.com> wrote:> Using "latest" and controlling the repositories yourself is best practice I > believe. > On Nov 16, 2010 2:16 PM, "jcbollinger" <John.Bollin...@stjude.org> wrote: > > > > > On Nov 16, 11:03 am, Andy <andy....@gmail.com> wrote: > >> Also, do you typically create your own mirrors of the repositories to > >> control the repository contents? > > > I don''t know about Luke, but I do. That provides not only control > > over the repository contents, but also (for me) much better > > performance, as my queries and package retrievals do not have to leave > > my internal network. I also get better availability because the > > repository has fewer clients, and if it ever goes down I can fix it. > > > Moreover, you then have the option to rely on your local repository > > instead of Puppet for control of package versions. That is, maintain > > in your repository only those software versions you want to use, and > > let your Package resources all simply specify the "latest" version. > > No more tweaking manifests when you qualify a new package version! > > > Cheers, > > > John > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group.> To post to this group, send email to puppet-users@googlegroups.com. > > To unsubscribe from this group, send email to > > puppet-users+unsubscribe@googlegroups.com<puppet-users%2Bunsubscribe@googlegroups.com> > .> For more options, visit this group at > > http://groups.google.com/group/puppet-users?hl=en. > >-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.