I''m having an issue using package resources on RHEL 4 systems using up2date with RHN. I need to ensure that libacl.i386 is installed on a x86_64 system, however the up2date provider does not seem to like the yum syntax for specifying arch, and there doesn''t seem to be any other method for doing so. I found this thread, http://projects.reductivelabs.com/issues/2043, that is the same issue, but apparently no progress has been made on it in 10 months. Considering there are a large number of RHEL4 / Centos4 boxes around, I am surprised that a solution for this has not been implemented yet. Does anyone have a solution for this? Can I extend the package resource somehow to allow up2date to handle the arch properly? Thanks, James C. -- 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 Tue, 19 Jan 2010 13:07:21 -0800 (PST), James <jimi@sngx.net> wrote:> I''m having an issue using package resources on RHEL 4 systems using > up2date with RHN. I need to ensure that libacl.i386 is installed on a > x86_64 system, however the up2date provider does not seem to like the > yum syntax for specifying arch, and there doesn''t seem to be any other > method for doing so. > > I found this thread, http://projects.reductivelabs.com/issues/2043, > that is the same issue, but apparently no progress has been made on it > in 10 months. Considering there are a large number of RHEL4 / Centos4 > boxes around, I am surprised that a solution for this has not been > implemented yet. > > Does anyone have a solution for this? Can I extend the package > resource somehow to allow up2date to handle the arch properly?Never saw any response to this, has anyone run into this issue besides me? -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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.
Unfortunately even the yum provider sucks at this too. It may have been fixed
recently, but I don''t think so since the problem exists in how rpm
reports back queries for available packages. I have to solve this with an exec.
. You could do something similar to:
exec {"install libacl.i386":
command => "up2date --arch i386 libacl",
onlyif => "rpm -qa libacl.i386 | grep ''libacl''
";
}
On Jan 27, 2010, at 10:17 AM, James Cammarata wrote:
>
> On Tue, 19 Jan 2010 13:07:21 -0800 (PST), James <jimi@sngx.net>
wrote:
>> I''m having an issue using package resources on RHEL 4 systems
using
>> up2date with RHN. I need to ensure that libacl.i386 is installed on a
>> x86_64 system, however the up2date provider does not seem to like the
>> yum syntax for specifying arch, and there doesn''t seem to be
any other
>> method for doing so.
>>
>> I found this thread, http://projects.reductivelabs.com/issues/2043,
>> that is the same issue, but apparently no progress has been made on it
>> in 10 months. Considering there are a large number of RHEL4 / Centos4
>> boxes around, I am surprised that a solution for this has not been
>> implemented yet.
>>
>> Does anyone have a solution for this? Can I extend the package
>> resource somehow to allow up2date to handle the arch properly?
>
> Never saw any response to this, has anyone run into this issue besides
> me?
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> 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.
>
--
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 Wed, 27 Jan 2010 11:50:41 -0600, Carl Caum <carl.caum@gmail.com> wrote:> Unfortunately even the yum provider sucks at this too. It may have been > fixed recently, but I don''t think so since the problem exists in how rpm > reports back queries for available packages. I have to solve this withan> exec. . You could do something similar to: > > exec {"install libacl.i386": > command => "up2date --arch i386 libacl", > onlyif => "rpm -qa libacl.i386 | grep ''libacl'' "; > }Yeah, I was hoping to avoid using an exec, but it looks like this would be the easiest solution to fix it immediately. I haven''t had any issues on RHEL5 using the yum provider, it likes the .arch syntax well enough. Thanks! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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.
Make extra sure that''s true. I found it won''t give you an error but the package still won''t always be installed. On Jan 27, 2010, at 12:05 PM, James Cammarata wrote:> > On Wed, 27 Jan 2010 11:50:41 -0600, Carl Caum <carl.caum@gmail.com> wrote: >> Unfortunately even the yum provider sucks at this too. It may have been >> fixed recently, but I don''t think so since the problem exists in how rpm >> reports back queries for available packages. I have to solve this with > an >> exec. . You could do something similar to: >> >> exec {"install libacl.i386": >> command => "up2date --arch i386 libacl", >> onlyif => "rpm -qa libacl.i386 | grep ''libacl'' "; >> } > > Yeah, I was hoping to avoid using an exec, but it looks like this would be > the easiest solution to fix it immediately. I haven''t had any issues on > RHEL5 using the yum provider, it likes the .arch syntax well enough. > > Thanks! > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > 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. >-- 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 Wed, 27 Jan 2010 14:42:12 -0600, Carl Caum <carl.caum@gmail.com> wrote:> Make extra sure that''s true. I found it won''t give you an error but the > package still won''t always be installed. > > On Jan 27, 2010, at 12:05 PM, James Cammarata wrote: > >> >> On Wed, 27 Jan 2010 11:50:41 -0600, Carl Caum <carl.caum@gmail.com> >> wrote: >>> Unfortunately even the yum provider sucks at this too. It may havebeen>>> fixed recently, but I don''t think so since the problem exists in howrpm>>> reports back queries for available packages. I have to solve this with >> an >>> exec. . You could do something similar to: >>> >>> exec {"install libacl.i386": >>> command => "up2date --arch i386 libacl", >>> onlyif => "rpm -qa libacl.i386 | grep ''libacl'' "; >>> }Right, the above onlyif isn''t perfect. It needs to be more like this: onlyif => "rpm -q --qf=''%{NAME}.%{ARCH}\n'' libacl | grep -q ''libacl.x86_64''" Otherwise, RPM outputs something like this: $ rpm -q libacl libacl-2.2.23-5.3.el4 Which has no arch on it. Note that you don''t have to use -qa and then grep, that''s slow. You can just do -q <package name> which is much faster (especially if you have a lot of RPMs installed). This also works on packages that have multiple arches: $ rpm -q --qf ''%{NAME}.%{ARCH}\n'' tcp_wrappers tcp_wrappers.x86_64 tcp_wrappers.i386 So now I just need to set this up so it''s transparent between RHEL4-5... -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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 Jan 28, 2010, at 10:08 AM, James Cammarata wrote:> > On Wed, 27 Jan 2010 14:42:12 -0600, Carl Caum <carl.caum@gmail.com> wrote: >> Make extra sure that''s true. I found it won''t give you an error but the >> package still won''t always be installed. >> >> On Jan 27, 2010, at 12:05 PM, James Cammarata wrote: >> >>> >>> On Wed, 27 Jan 2010 11:50:41 -0600, Carl Caum <carl.caum@gmail.com> >>> wrote: >>>> Unfortunately even the yum provider sucks at this too. It may have > been >>>> fixed recently, but I don''t think so since the problem exists in how > rpm >>>> reports back queries for available packages. I have to solve this with >>> an >>>> exec. . You could do something similar to: >>>> >>>> exec {"install libacl.i386": >>>> command => "up2date --arch i386 libacl", >>>> onlyif => "rpm -qa libacl.i386 | grep ''libacl'' "; >>>> } > > Right, the above onlyif isn''t perfect. It needs to be more like this: > > onlyif => "rpm -q --qf=''%{NAME}.%{ARCH}\n'' libacl | grep -q > ''libacl.x86_64''" > > Otherwise, RPM outputs something like this: > > $ rpm -q libacl > libacl-2.2.23-5.3.el4 > > Which has no arch on it. Note that you don''t have to use -qa and then > grep, that''s slow. You can just do -q <package name> which is much faster > (especially if you have a lot of RPMs installed). This also works on > packages that have multiple arches: > > $ rpm -q --qf ''%{NAME}.%{ARCH}\n'' tcp_wrappers > tcp_wrappers.x86_64 > tcp_wrappers.i386 > > So now I just need to set this up so it''s transparent between RHEL4-5...Sweet. Thanks. I''ve never bothered to become a RPM master since I switched to administering RHEL based systems. At some point I''ll break down and do it ;)> > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > 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. >-- 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.
after a very long discussion about this topic in the past, we internally
decided to have a simple script which checks the yum repo for 32bit versions
when the 64bit version exists.
e.g. if you did
package{"libacl": ensure => installed}
then the script will install the 32bit version of the same package.
the script is triggered every time the mtime on the rpm database file is
changed.
cheers,
Ohad
On Fri, Jan 29, 2010 at 12:08 AM, James Cammarata <jimi@sngx.net> wrote:
>
> On Wed, 27 Jan 2010 14:42:12 -0600, Carl Caum <carl.caum@gmail.com>
wrote:
> > Make extra sure that''s true. I found it won''t give
you an error but the
> > package still won''t always be installed.
> >
> > On Jan 27, 2010, at 12:05 PM, James Cammarata wrote:
> >
> >>
> >> On Wed, 27 Jan 2010 11:50:41 -0600, Carl Caum
<carl.caum@gmail.com>
> >> wrote:
> >>> Unfortunately even the yum provider sucks at this too. It may
have
> been
> >>> fixed recently, but I don''t think so since the
problem exists in how
> rpm
> >>> reports back queries for available packages. I have to solve
this with
> >> an
> >>> exec. . You could do something similar to:
> >>>
> >>> exec {"install libacl.i386":
> >>> command => "up2date --arch i386 libacl",
> >>> onlyif => "rpm -qa libacl.i386 | grep
''libacl'' ";
> >>> }
>
> Right, the above onlyif isn''t perfect. It needs to be more like
this:
>
> onlyif => "rpm -q --qf=''%{NAME}.%{ARCH}\n'' libacl
| grep -q
> ''libacl.x86_64''"
>
> Otherwise, RPM outputs something like this:
>
> $ rpm -q libacl
> libacl-2.2.23-5.3.el4
>
> Which has no arch on it. Note that you don''t have to use -qa and
then
> grep, that''s slow. You can just do -q <package name> which
is much faster
> (especially if you have a lot of RPMs installed). This also works on
> packages that have multiple arches:
>
> $ rpm -q --qf ''%{NAME}.%{ARCH}\n'' tcp_wrappers
> tcp_wrappers.x86_64
> tcp_wrappers.i386
>
> So now I just need to set this up so it''s transparent between
RHEL4-5...
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
> --
> 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<puppet-users%2Bunsubscribe@googlegroups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
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 Fri, 29 Jan 2010 09:47:05 +0800, Ohad Levy <ohadlevy@gmail.com> wrote:> after a very long discussion about this topic in the past, we internally > decided to have a simple script which checks the yum repo for 32bit > versions > when the 64bit version exists. > > e.g. if you did > package{"libacl": ensure => installed} > > then the script will install the 32bit version of the same package. > > the script is triggered every time the mtime on the rpm database file is > changed. > > cheers, > OhadBut not the same for up2date, or any other provider? I understand the logic behind the decision, but it should be consistent across all providers. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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 Fri, 29 Jan 2010 06:13:44 -0600, James Cammarata <jimi@sngx.net> wrote:> On Fri, 29 Jan 2010 09:47:05 +0800, Ohad Levy <ohadlevy@gmail.com> wrote: >> after a very long discussion about this topic in the past, we internally >> decided to have a simple script which checks the yum repo for 32bit >> versions >> when the 64bit version exists. >> >> e.g. if you did >> package{"libacl": ensure => installed} >> >> then the script will install the 32bit version of the same package. >> >> the script is triggered every time the mtime on the rpm database file is >> changed. >> >> cheers, >> Ohad > > But not the same for up2date, or any other provider? I understand the > logic behind the decision, but it should be consistent across all > providers.Nevermind, I think I misunderstood. You just have something cron''d, and this isn''t something built into puppet. That''s what I get for responding to emails before drinking coffee :) -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. -- 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.
its actually trigger by puppet, puppet keeps track on the mtime of the rpm db file, each time it changes, it notify an exec which runs the script. cheers, Ohad On Fri, Jan 29, 2010 at 8:19 PM, James Cammarata <jimi@sngx.net> wrote:> > On Fri, 29 Jan 2010 06:13:44 -0600, James Cammarata <jimi@sngx.net> wrote: > > On Fri, 29 Jan 2010 09:47:05 +0800, Ohad Levy <ohadlevy@gmail.com> > wrote: > >> after a very long discussion about this topic in the past, we internally > >> decided to have a simple script which checks the yum repo for 32bit > >> versions > >> when the 64bit version exists. > >> > >> e.g. if you did > >> package{"libacl": ensure => installed} > >> > >> then the script will install the 32bit version of the same package. > >> > >> the script is triggered every time the mtime on the rpm database file is > >> changed. > >> > >> cheers, > >> Ohad > > > > But not the same for up2date, or any other provider? I understand the > > logic behind the decision, but it should be consistent across all > > providers. > > Nevermind, I think I misunderstood. You just have something cron''d, and > this isn''t something built into puppet. That''s what I get for responding > to emails before drinking coffee :) > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > -- > 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<puppet-users%2Bunsubscribe@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/puppet-users?hl=en. > >-- 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.