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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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
On Tue, Aug 4, 2009 at 2:01 PM, Matt Delves
<m.delves@ballarat.edu.au>wrote:
>
> 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
>
>
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Tue, Aug 4, 2009 at 2:34 PM, Avi Miller <avi.miller@gmail.com> wrote:> > 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 > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Akins, Brian
2009-Aug-04 12:24 UTC
[Puppet Users] Re: 32bit and 64bit versions of packages
On 8/4/09 2:34 AM, "Avi Miller" <avi.miller@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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
2009/8/4 Ohad Levy <ohadlevy@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.) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 On Wed, Aug 5, 2009 at 2:56 PM, Duncan Hill <bajandude@googlemail.com>wrote:> > 2009/8/4 Ohad Levy <ohadlevy@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.) > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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) On Wed, Aug 5, 2009 at 3:17 PM, Avi Miller <avi.miller@gmail.com> wrote:> > 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 > > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
thanks, that good to know, but I still maintain RHE3 and RHE4... :( On Wed, Aug 5, 2009 at 5:02 PM, Calimero <calimero.ng@evolutive.org> wrote:> > > > 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 > > >--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---