Hi,
if I get you right, we are doing the same thing for critical parts of our
infrastructure. We are on Debian Wheezy…
I use puppetlabs-apt module to manage repos and automatic upgrades. It offers a
way to create holds/pins for selected packages. This way you can install a
selected version of a package and tell apt not to update it easily.
For example, this is how we install Percona-MySQL-Server to a given version.
The parameter allows us to have one host (testing) to install another, newer
version:
class profile::perconadb ($percona_version='5.6.21-70.1-698.wheezy') {
apt::source { 'Percona':
comment => 'The Percona MySQL Repo',
location => 'http://repo.percona.com/apt',
release => 'wheezy',
repos => 'main',
key => '1C4CBDCDCD2EFD2A',
key_server => 'keys.gnupg.net',
pin => '600',
include_src => false,
include_deb => true
}
package {'percona-server-server-5.6':
ensure => $percona_version,
require => Apt::Source['Percona'],
}
package {'percona-server-tokudb-5.6':
ensure => $percona_version,
require => Package['percona-server-server-5.6'],
}
apt::hold { 'percona-server-server-5.6':
version => $percona_version,
}
apt::hold { 'percona-server-tokudb-5.6':
version => $percona_version,
}
}
Regards
Jochen
> Am 19.12.2014 um 17:12 schrieb Joseph Lombardo <[email protected]>:
>
> Sorry, I should have been more thorough with my explanation. We use Spacewalk
> to manage our repositories and package installations/updates. However, when a
> system first comes up it is puppet that registers it in spacewalk and does
> the initial package install. The reason we want to ensure => present but
> install a particular version is that we may be doing updates on something
> like MySQL which means there are newer versions in the repo but we want our
> current production version installed on new machines. The updates are
> performed with Spacewalk on servers as we roll through then once everything
> is updated we change the version in Puppet. Otherwise, large amounts of time
> would need to be spent setting the versions individually on each node. If it
> was a handful of servers there wouldn't be an issue but when it is hundreds
> to roll an update through, pushing out individual node exclusions is too much.
>
> I am probably going to wrap the package resource in a custom fact which
> checks if it is installed so I can ensure => $version but not affect anything
> that has been upgraded.
>
> Something like:
> if !$mysql_installed{
> class { 'mysql::shared':
> package_name => 'blah'
> } ->
> etc.
> }
>
> Thanks for the help John!
>
> On Friday, December 19, 2014 9:54:09 AM UTC-5, jcbollinger wrote:
>
>
> On Thursday, December 18, 2014 11:10:52 AM UTC-6, Joseph Lombardo wrote:
> We have a use case where when a new server comes up, it needs to install a
> particular version of a package. However, if this package is upgraded puppet
> should ignore it. I have been unable to find a non-hacky way to do this.
> Basically, need to ensure present but install a particular version (not the
> latest in the repo) if missing. Any help will be great.
>
>
>
> Your requirements are a bit inconsistent. If it's ok for machines to have a
> more recent version of the package in question, then why would it wrong for
> Puppet to install such a package?
>
> In any case, there is no mechanism in Puppet proper by which your requirement
> can be expressed. You could perhaps build something with custom facts,
> conditionals, etc., but I'd suggest you consider a custom requirements-only
> package, and have Puppet ensure that present. This could certainly be done
> with Yum/RPM, and I pretty sure with Apt/DEB, because they support richer
> expressions of dependencies on other packages. If your package is of a
> different type then you'll need to evaluate whether this would be a viable
> solution for you.
>
>
> John
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/109e20cd-2209-4cfd-b1a3-e735b27e3f6a%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/FC0AA269-825D-472C-A599-83D33E59D265%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
