Bug #1465
Puppet mistakenly thinks openssl-devel.x86_64 is installed.
| Status: | Closed | Start date: | 07/30/2008 | |
|---|---|---|---|---|
| Priority: | Normal | Due date: | ||
| Assignee: |  Puppet Community |
% Done: | 0% |
|
| Category: | Red Hat | |||
| Target version: | - | |||
| Affected Puppet version: | 0.24.7 | Branch: | ||
| Keywords: | yum package | |||
| Votes: | 0 |
Description
I’m requiring @openssl-devel.$architecture@, which resolves to @openssl-devel.x86_64@. Puppet isn’t installing it, so my application build is failing.
@puppetd —test —debug@ shows it running @/bin/rpm -q openssl-devel.x86_64@.
debug: Puppet::Type::Package::ProviderYum: Executing '/bin/rpm -q \
openssldevel.x86_64 --nosignature --nodigest --qf %{NAME} \
%|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}
(I’ve wrapped it, indicating line splits with @\@)
Pupppet doesn’t go on to install anything new. Poking around a little, I see @rpm -q openssl-devel.x86_64@ return without error despite @openssl-devel.x86_64@ not appearing in the output of @yum list installed@:
# /bin/rpm -q openssl-devel.i386 openssl-devel-0.9.8b-10.el5 # echo $? 0 # /bin/rpm -q openssl-devel-0.9.8b-10.el5 openssl-devel-0.9.8b-10.el5 # echo $? 0 # /bin/rpm -q openssl-devel.x86_64 # echo $? 0 # /bin/rpm -q openssl-devel.garbage package openssl-devel.garbage is not installed # echo $? 1 # yum list installed | grep openssl openssl.i686 0.9.8b-10.el5 installed openssl.x86_64 0.9.8b-10.el5 installed openssl-devel.i386 0.9.8b-10.el5 installed
If I run ‘yum install openssl-devel.x86_64",it offers to install it.
# yum install openssl-devel.x86_64 Loading "rhnplugin" plugin rhel-x86_64-server-5 100% |=========================| 1.4 kB 00:00 Setting up Install Process Parsing package install arguments Resolving Dependencies --> Running transaction check ---> Package openssl-devel.x86_64 0:0.9.8b-10.el5 set to be updated --> Finished Dependency Resolution Dependencies Resolved ============================================================================= Package Arch Version Repository Size ============================================================================= Installing: openssl-devel x86_64 0.9.8b-10.el5 rhel-x86_64-server-5 1.8 M Transaction Summary ============================================================================= Install 1 Package(s) Update 0 Package(s) Remove 0 Package(s) Total download size: 1.8 M Is this ok [y/N]:
I can temporarily work around this by manually installing @openssl-devel.x86_64@, of course, but that goes against the whole point of Puppet.
I suspect Puppet could fix this by checking for output from @rpm -q@ as well as an exit code of @0@. Hopefully, that won’t break on other systems.
Other system information:
# facter architecture => x86_64 facterversion => 1.5.0 hardwareisa => x86_64 hardwaremodel => x86_64 hostname => test1 id => root interfaces => eth0,eth1,sit0 kernel => Linux kernelrelease => 2.6.18-53.1.4.el5.xs4.0.96.17xen lsbdistcodename => Tikanga lsbdistdescription => Red Hat Enterprise Linux Server release 5.2 (Tikanga) lsbdistid => RedHatEnterpriseServer lsbdistrelease => 5.2 lsbmajdistrelease => 5 lsbrelease => :core-3.1-amd64:core-3.1-ia32:core-3.1-noarch:\ graphics-3.1-amd64:graphics-3.1-ia32:graphics-3.1-noarch memoryfree => 302.15 MB memorysize => 512.00 MB operatingsystem => RedHat operatingsystemrelease => 5 processor0 => Intel(R) Xeon(R) CPU E5345 @ 2.33GHz processorcount => 1 ps => ps -ef puppetversion => 0.24.5 rubysitedir => /usr/lib/ruby/site_ruby/1.8 rubyversion => 1.8.5 swapfree => 543.95 MB swapsize => 543.99 MB
Related issues
History
Updated by Garth Roxburgh-Kidd almost 4 years ago
- Affected Puppet version changed from 0.24.4 to 0.24.5
Whups. Got the version wrong. Thanks, fujin!
Updated by AJ Christensen almost 4 years ago
- Status changed from Unreviewed to Needs More Information
- Assignee set to Puppet Community
- Target version set to 0.24.5
- Keywords set to yum package
Anyone have a rh-based machine to try and replicate this behaviour?
Updated by BMDan - almost 4 years ago
Am I wrong to think that this sounds more like an RPM bug than a Puppet one? Or is this one of those things that have been buggy about RPM from the beginning, and can’t be changed now for compatibility reasons?
Updated by Garth Roxburgh-Kidd almost 4 years ago
I’m concerned it’s the latter. I’m also concerned that there might be cases where @rpm@ gives no output when a module is actually installed.
An easy test:
- Roll a patch into the next release of Puppet so that it generates a warning if rpm gives no text response.
- Ask the community to look for those warnings.
- If we don’t see them, the workaround is safe. Have Puppet check for 0 AND text output in the subsequent release.
- If we see warnings for modules that are definitely installed: go back to the drawing board.
I regret I lack any Ruby skills whatsoever, and can’t submit a patch.
Updated by James Turnbull almost 4 years ago
- Target version changed from 0.24.5 to 4
Updated by Sven Mueller over 3 years ago
- Affected Puppet version changed from 0.24.5 to 0.24.7
Hmm, didn’t find this bug when I searched for yum related bugs yesterday. Unfortunately, like others, I lack the ruby skills to fix the bug. But this really is a big problem on any rpm based multiarch installation. If there is any non-Ruby-coding help I could give here, let me know.
Updated by Sven Mueller over 3 years ago
Adding on to this, I think one possible fix is to make provider/package/rpm.rb “query” return nil if output is empty (as is already done if the rpm command fails for any reason).
More importantly, I really think this bug should be priority “high”, since it cripples puppet in a very bad and unexpected way. Installing package.arch using yum directly works perfectly fine (i.e. installs the package) while puppet fails badly (i.e. installs no package when requested to ensure it is installed, yet doesn’t provide any error).
I found a commandline which could emulate the query as done by rpm.rb in the query function. Namely:
yum -q list installed | grep PACKAGENAME | ( FOUND=0; while read a b c; do export FOUND=1; PCK=`echo $a | sed -e 's/\.[^.]*//'`; ARC=`echo $a | sed -e 's/.*\.\([^.]*\)/\1/'`; if echo $b | grep -q ":"; then EPOCH=`echo $b| cut -d : -f 1`; VER=`echo $b | cut -d : -f 2-`; else EPOCH=0; VER="$b" ; fi; REL=`echo $VER | sed -e 's/\(.*\)-\([^-]*\)/\2/'`; VER=`echo $VER | sed -e 's/\(.*\)-\([^-]*\)/\1/'`; echo $PCK $EPOCH $VER $REL $ARC; done ; test $FOUND == 1 )
Of course, this is a really ugly hack around the issue. Fixing the rpm provider would be better by far.
My real suggestion so far is that
if output.empty?
return nil
end
@property_hash.update(self.class.nevra_to_hash(output))
return @property_hash.dup
is used in “query” instead of the last two lines alone.
Finally, the rpm provider (and probably the yum provider) need some serious rework to support multi-arch (where the rpm query for a package can actually return multiple lines, see the FIXME notes in the source), but the above would at least make the package installation work again as far as I can tell.
Regards, Sven
Updated by Sven Mueller over 3 years ago
Another note: The bug is tagged “Needs more information”, however, it is not stated what sort of information is needed. At least I didn’t see any such statement.
Updated by Paul Lathrop over 3 years ago
Updated by Sven Mueller over 3 years ago
Just wanted to confirm that the latest rpm upgrade (released on 2009-01-20 by RedHat) does indeed fix the problem of not installing package of ArchitectureA if already installed in ArchitectureB.
This means that now only the part of updating all packages (in all installed architectures) of a given name with “ensure=>latest” is missing.
Updated by Luke Kanies about 3 years ago
- Status changed from Needs More Information to Closed
It sounds like this was an rpm bug and it’s now fixed upstream.
As a result, I’m closing the ticket; please reopen or file anew if you think there’s still a problem. In particular, if you think it’s critical that we work around this rpm bug, reopen.
Updated by James Turnbull about 1 year ago
- Target version deleted (
4)