Patterns for multi-arch libraries...

[J.T. Conklin]

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

[Rob Nelson]

Silly question, but what package manager doesn't let you upgrade those two packages independently but also doesn't update the dependent packages at the same time?

--
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/87oa96o0yu.fsf%40wopr.acorntoolworks.com.
For more options, visit https://groups.google.com/d/optout.

--

Rob Nelson
rnel...@gmail.com

[J.T. Conklin]

Rob Nelson <rnel...@gmail.com> writes:
> Silly question, but what package manager doesn't let you upgrade those
> two packages independently but also doesn't update the dependent
> packages at the same time?

We have this problem on CentOS machines using the yum provider. The logs
reported something to the effect of openssl.x86_64 couldn't be updated
to version N+1 as that conflicted with openssl.i686 version N. I wish
I had saved the logs at the time so I could share the exact text with
you all.

For a while - when it seemed like there was a new OpenSSL vulnerabilty
every other day - we had the openssl module's "version" parameter set to
"latest" in our hiera config. When a new openssl version was available,
puppet would attempt and fail to install it each run. We'd manually have
to install the new version - so much for saving time. I'm hoping to find
a better option before the next time we need to update.

--jtc

[Rob Nelson]

That's weird, but I guess it kind of makes sense as they're independent. Shame they have conflicts, though. It looks like, of all things, it's the shared man pages causing the problem... https://bugs.centos.org/view.php?id=5489

I assume you have both versions on purpose, but in case that wasn't the intent, this article describes how to prevent non-systemarch packages from getting through: https://access.redhat.com/solutions/158883

Rob Nelson
rnel...@gmail.com

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

To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/877fftd1lq.fsf%40wopr.acorntoolworks.com.

[Ramin K]

Try adding install_options => 'update', to the package resource. Only
works in Puppet 3+.

Ramin

[jcbollinger]

On Tuesday, April 19, 2016 at 11:07:07 AM UTC-5, J.T. Conklin wrote:

Rob Nelson <rnel...@gmail.com> writes:
> Silly question, but what package manager doesn't let you upgrade those
> two packages independently but also doesn't update the dependent
> packages at the same time?

We have this problem on CentOS machines using the yum provider. The logs
reported something to the effect of openssl.x86_64 couldn't be updated
to version N+1 as that conflicted with openssl.i686 version N.  I wish
I had saved the logs at the time so I could share the exact text with
you all.

Yes, yum can be configured so that it forces co-installed 32-bit and 64-bit versions of the same package to have the same epoch:version-release, and that option ('protected_multilib') is enabled by default.  You could consider disabling it in your yum.conf, which, of course, Puppet could help you do.  That does not override general conflict detection, however, which could still be in play, nor normal dependency resolution.  And, really, having mismatched library versions seems a little dubious to me, but perhaps allowing it as a transitory state would make for smoother integration with Puppet.

It is conceivable that you would benefit from setting yum's 'multilib_policy' option to 'all' to automatically install all available architectures of each package, instead of, by default, only the one that best matches the machine architecture.  The former was the default configuration in EL5, whereas the latter became the default in EL6.  I don't think that will directly address your current problem, but it, too, might make for smoother integration.

As an ongoing concern, if you have multiple architectures of the same package installed on a given system, then yum commands that give the package name but no arch will affect all packages of that name.  Thus, updating just 'openssl' will update all installed arches of that package, whereas updating (or installing) 'openssl.x86_64' is specific to that arch of the package.  And that's where you're running into trouble.  Puppet's package providers manage a single package at a time (as it appears to them).  In your case, then, even though you're managing both openssl.x86_64 and openssl.i686, Puppet attempts to perform a separate install / update for each.  The separate installs work, but separate updates do not.  You need to update both arches in the same yum run (supposing that protected_multilib is enabled), and the only way to do that in Puppet is to leave the arch off the package name.


John