[Puppet Users] 32bit and 64bit versions of packages

[Matt Delves]

Hey folks,
For some of the systems I administer, I'm wanting to use puppet to make
sure that the correct packages are installed. For one particular
instance this would for an oracle database server. What I require is
that both 32bit and 64bit versions of particular packages are present.

Is there a way to specify this? Also, can ralsh be used to identify both
the 32bit and 64bit versions which are installed as well as just the
package name?

Thanks,
Matt Delves

[Ohad Levy]

Hi,

we tried to do it with puppet a few times, but at the end what we do is:
(for example on a redhat system)
check if /var/lib/rpm/Packages has changed if it has, it probably means that a package has been installed.
if it has, then execute a script which compares the 32bit and 64bit packages, install them if they are missing.

e.g. in puppet language:
file { "/var/lib/rpm/Packages": checksum => md5 }
exec { "install missing 32bit packages":
  # only start if there are any changes in the packagelist
   subscribe => File["/var/lib/rpm/Packages"], refreshonly => true,
...
}

maybe there is a easier way to do that, but this was the only one way that worked also with old versions of yum etc.

Ohad

[Avi Miller]

Matt Delves wrote:
> Is there a way to specify this?

If you're using Yum as the provider, yes:

package { "package.i386": ensure => latest, provider => "yum" }
package { "package.x86_64": ensure => latest, provider => "yum" }

Works fine on my test system.

Also, if you're interested in getting all the pre-requisite RPMs for
Oracle, why not just use the oracle-validated RPM:

http://oss.oracle.com/el5/oracle-validated/

This will also create the oracle user and oinstall/dba groups, as well
as set sysctl.conf and limits.conf and everything else that usually has
to be done manually before you can install Oracle. :)

cYa,
Avi

[Ohad Levy]

Hi,

It does work, the main problem is that usually libs are dependents of other rpms.
if you do it this way, you have to find out the  each and every lib rpm which the application you actually want to use depends upon.

Ohad

[Avi Miller]

Ohad Levy wrote:
> It does work, the main problem is that usually libs are dependents of
> other rpms.

Yum just pulls in the various dependencies automatically for me. Seems
to work fine just specifying the target RPM.

cYa,
Avi

[Akins, Brian]

On 8/4/09 2:34 AM, "Avi Miller" <avi.m...@gmail.com> wrote:

> This will also create the oracle user and oinstall/dba groups, as well
> as set sysctl.conf and limits.conf and everything else that usually has
> to be done manually before you can install Oracle. :)

Except, in my case, puppet controls those files :)
--
Brian Akins

[Duncan Hill]

2009/8/4 Ohad Levy <ohad...@gmail.com>:

> Hi,
>
> It does work, the main problem is that usually libs are dependents of other
> rpms.
> if you do it this way, you have to find out the  each and every lib rpm
> which the application you actually want to use depends upon.

Yum certainly handles this.

What I have done in the past is store the 64 and 32-bit RPMs in the
same repository. yum install <package> then grabs both unless you
explicitly override the arch. (To be honest, this bit me in the ass
with an install and then I realised that it was a useful trick.)

[Ohad Levy]

I need to double check this, but from vague memory I remember that if you had one rpm that required a package, and if it didn't specify that it requires both archs, than it would end up installing the package + 64bit lib only and not the 32bit libs.

Ohad

[Avi Miller]

Ohad Levy wrote:
> I need to double check this, but from vague memory I remember that if
> you had one rpm that required a package, and if it didn't specify that
> it requires both archs, than it would end up installing the package +
> 64bit lib only and not the 32bit libs.

Correct -- but that's a fault of the RPM package, not Puppet, i.e. just
doing a yum install <package> would have the same result.

cYa,
Avi

[Ohad Levy]

yeah, so I guess that's what I had in mind all along (i don't know how common it is today, but in the past it was fairly common)

[Calimero]

On 5 août, 09:11, Ohad Levy <ohadl...@gmail.com> wrote:
> I need to double check this, but from vague memory I remember that if you
> had one rpm that required a package, and if it didn't specify that it
> requires both archs, than it would end up installing the package + 64bit lib
> only and not the 32bit libs.

Indeed. We've had problems in CentOS 5.2 (don't remember the exact yum
version).
Installing "curl-dev" would install both 32/64 packages and we ended
with problems (using 32b libs when building 64b which obviously
failed).

We then used yum's plugin "basearchonly". But with yum 3.2.19 that now
ships with CentOS 5.3 basearchonly seems deprecated/unsupported. But
there's a yum.conf option: multilib_policy=best

" multilib_policy
Can be set to ’all’ or ’best’. All means install all
possible arches for any package you want to install. Therefore yum
install
foo will install foo.i386 and foo.x86_64 on x86_64,
if it is available. Best means install the best arch for this
platform,
only."

Looks like "all" was the default or previous behavior. And "best"
works like yum-basearchonly worked.

Anyway we didn't experience any 32b/64b gotchas since we've set
multilib to "best".


Calimero

[Ohad Levy]

thanks, that good to know, but I still maintain RHE3 and RHE4... :(