Package ensure present but install older version if missing (not latest in repo)?

[Joseph Lombardo]

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.

Thanks!

[jcbollinger]

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

[Joseph Lombardo]

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!

[Thomas Müller]

You could define a versionlock ( yum plugin available in the rhel/centos repo) for the specific package versions.

- Thomas

[jcbollinger]

On Friday, December 19, 2014 10:12:03 AM UTC-6, Joseph Lombardo wrote:

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.

That explains your thinking, but it's really not a very good reason for approaching the problem is you suggest doing.  If different machines have inconsistent requirements on what should be installed, then those machines should not be served by the same declarations.

Have you considered using a different (Puppet) environment for initially configuring new servers than for configuring others?  Say a "provisioning" environment and a "production" environment?  In the "provisioning" environment you 'ensure' whatever specific versions of these packages you want, and in the "production" environment you just 'ensure' "present" (or whatever).  You can share as much of your manifest set as is appropriate between environments.  Perhaps you could even share everything, and let Hiera make the environment-based distinction.

John

[Jochen Häberle]

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

> --
> 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 puppet-users...@googlegroups.com.
> 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.