Before we started using puppet at work, we didn't have a systematic
process to install packages on our servers. As a result, we had servers
in the same "role" that (unintentionally) had different sets of packages
installed.
A very common case was that the 64 bit version of a library was
installed but the corresponding 32 bit version was not. This usually
wouldn't be detected until one of our users tried to run a 32 bit binary
that used that library on that particular system.
So we used puppet to bring our systems in line, selecting what packages
to install based on architecture. For example, in our openssl module,
we changed:
$package = 'openssl'
to:
if $architecturee == 'x86_64' {
$package = [ 'openssl.x86_64', 'openssl.i686' ]
} else {
$package = 'openssl'
}
While this worked the first time to install the 32 bit openssl on all 64
bit machines, it fails when installing/updating to a new openssl version
(due to security issues, etc. as has been necessary recently) as the yum
provider attempts to install the 64 and 32 bit packages in the array
separately when they must be installed simultaneously. I tried changing
the array to:
$package = [ 'openssl', 'openssl.x86_64', 'openssl.i686' ]
thinking that having the un-suffixed version first would cause both to
be updated in the common case, and the suffixed versions to install the
specific 32 or 64 bit version if it's not already installed.
Unfortunately, this fails the same way.
Now that all our legacy systems have been "fixed", I suppose we could
drop the package array and go back to the original un-suffixed package
definition. But if there is a pattern that will work, I'd prefer using
it instead. Do any of you have a working idiom?
Thanks in advance,
--jtc
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/87oa96o0yu.fsf%40wopr.acorntoolworks.com.
For more options, visit https://groups.google.com/d/optout.
