Re: [Puppet Users] Patterns for multi-arch libraries...

[jcbollinger]

On Tuesday, April 19, 2016 at 11:07:07 AM UTC-5, J.T. Conklin wrote:
>
> Rob Nelson  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

-- 
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/39e43216-c6da-481e-af56-58b31f1cd7b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Patterns for multi-arch libraries...

[Ramin K]

On 4/19/16 9:06 AM, J.T. Conklin wrote:

Rob Nelson  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



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


Ramin

--
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/57167AA4.6080104%40badapple.net.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Patterns for multi-arch libraries...

[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
rnels...@gmail.com

On Tue, Apr 19, 2016 at 12:06 PM, J.T. Conklin 
wrote:

> Rob Nelson  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
>
> --
> 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/877fftd1lq.fsf%40wopr.acorntoolworks.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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/CAC76iT9%2BzCqi98D8_%3DkftjzTqwWf_OTinW5W0mB8WW%3DkvxLiHQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [Puppet Users] Patterns for multi-arch libraries...

[J.T. Conklin]

Rob Nelson  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

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

Re: [Puppet Users] Patterns for multi-arch libraries...

[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?

On Monday, April 18, 2016, J.T. Conklin  wrote:

> 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.
>


-- 

Rob Nelson
rnels...@gmail.com

-- 
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/CAC76iT8_0DHz3%3DMeanfgajkuYu3VB%3Du--txmdFbsQmyMmWKPzw%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

[Puppet Users] 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



-- 
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.