Bug #9283
closed
The rpmPackageInstallation technique tries to install package-* instead of package when no version is specified
Description
100% reproducible issue, can't install clamav via rudder ncf.
error: Package 'clamav' cannot be updated -- no match or not installed
rudder info: Installing clamav...
rudder info: Q:yum --quiet --setopt ...:Error: clamav-data-empty conflicts with clamav-data-0.99.2-1.el7.noarch
rudder info: Q:yum --quiet --setopt ...:Error: clamav-data conflicts with clamav-data-empty-0.99.2-1.el7.noarch
rudder info: Q:yum --quiet --setopt ...: You could try using --skip-broken to work around the problem
rudder info: Q:yum --quiet --setopt ...:** Found 1 pre-existing rpmdb problem(s), 'yum check' output follows:
rudder info: Q:yum --quiet --setopt ...:1:quota-4.01-11.el7_2.1.x86_64 has missing requires of rpcbind
error: Finished command related to promiser 'clamav' -- an error occurred, returned 1
error: Bulk package schedule execution failed somewhere - unknown outcome for 'clamav-*.*'
R: [ERROR] Promise could not be repaired, error encountered: Install or update package clamav in version latest
error maldet_install Package install clamav Install or update package clamav in version latest could not be repaired
error: Method 'package_install_version_cmp_update' failed in some repairs
error: Method 'package_install_version_cmp' failed in some repairs
error: Method 'package_install_version' failed in some repairs
error: Method 'package_install' failed in some repairs
So what I know:
Centos7
EPEL Repo is the one delivering clamav
The packages available are[root@ip-172-31-13-51 ~]# yum list available| grep clam
clamav.x86_64 0.99.2-1.el7 epel
clamav-data.noarch 0.99.2-1.el7 epel
clamav-data-empty.noarch 0.99.2-1.el7 epel
clamav-devel.x86_64 0.99.2-1.el7 epel
clamav-filesystem.noarch 0.99.2-1.el7 epel
clamav-lib.x86_64 0.99.2-1.el7 epel
clamav-milter.x86_64 0.99.2-1.el7 epel
clamav-milter-systemd.noarch 0.99.2-1.el7 epel
clamav-milter-sysvinit.noarch 0.99.2-1.el7 epel
clamav-scanner.noarch 0.99.2-1.el7 epel
clamav-scanner-systemd.noarch 0.99.2-1.el7 epel
clamav-scanner-sysvinit.noarch 0.99.2-1.el7 epel
clamav-server.x86_64 0.99.2-1.el7 epel
clamav-server-systemd.noarch 0.99.2-1.el7 epel
clamav-server-sysvinit.noarch 0.99.2-1.el7 epel
clamav-unofficial-sigs.noarch 3.7.2-1.el7 epel
clamav-update.x86_64 0.99.2-1.el7 epel
only clamav is mentioned in that technique.
manually doing yum -y install clamav works flawless, this is a bug.
I'm 90% sure it's related to the number of dashes in packages if they share a common name part.
@Including mirror: mirror2.hs-esslingen.de
Including mirror: ftp.uni-bayreuth.de
Including mirror: mirror.cuegee.de
Including mirror: mirror.fraunhofer.de
Resolving Dependencies
--> Running transaction check
---> Package clamav.x86_64 0:0.99.2-1.el7 will be installed
--> Processing Dependency: clamav-lib = 0.99.2-1.el7 for package: clamav-0.99.2-1.el7.x86_64
--> Processing Dependency: libclamav.so.7(CLAMAV_PUBLIC)(64bit) for package: clamav-0.99.2-1.el7.x86_64
--> Processing Dependency: libclamav.so.7(CLAMAV_PRIVATE)(64bit) for package: clamav-0.99.2-1.el7.x86_64
--> Processing Dependency: data(clamav) for package: clamav-0.99.2-1.el7.x86_64
--> Processing Dependency: libclamav.so.7()(64bit) for package: clamav-0.99.2-1.el7.x86_64
--> Running transaction check
---> Package clamav-data.noarch 0:0.99.2-1.el7 will be installed
--> Processing Dependency: clamav-filesystem = 0.99.2-1.el7 for package: clamav-data-0.99.2-1.el7.noarch
---> Package clamav-lib.x86_64 0:0.99.2-1.el7 will be installed
--> Running transaction check
---> Package clamav-filesystem.noarch 0:0.99.2-1.el7 will be installed
--> Finished Dependency Resolution
Dependencies Resolved
=======================================================================================================================================================================================================================
Package Arch Version Repository Size
=======================================================================================================================================================================================================================
Installing:
clamav x86_64 0.99.2-1.el7 epel 845 k
Installing for dependencies:
clamav-data noarch 0.99.2-1.el7 epel 111 M
clamav-filesystem noarch 0.99.2-1.el7 epel 20 k
clamav-lib x86_64 0.99.2-1.el7 epel 3.8 M
Transaction Summary
=======================================================================================================================================================================================================================
Install 1 Package (+3 Dependent packages)
Total download size: 115 M
Installed size: 124 M
Is this ok [y/d/N]: y
Downloading packages:
(1/4): clamav-0.99.2-1.el7.x86_64.rpm | 845 kB 00:00:00
(2/4): clamav-data-0.99.2-1.el7.noarch.rpm | 111 MB 00:00:07
(3/4): clamav-filesystem-0.99.2-1.el7.noarch.rpm | 20 kB 00:00:00
(4/4): clamav-lib-0.99.2-1.el7.x86_64.rpm | 3.8 MB 00:00:00
-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 14 MB/s | 115 MB 00:00:07
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
etckeeper: pre transaction commit
Installing : clamav-filesystem-0.99.2-1.el7.noarch 1/4
Installing : clamav-data-0.99.2-1.el7.noarch 2/4
Installing : clamav-lib-0.99.2-1.el7.x86_64 3/4
Installing : clamav-0.99.2-1.el7.x86_64 4/4
etckeeper: post transaction commit
Verifying : clamav-filesystem-0.99.2-1.el7.noarch 1/4
Verifying : clamav-lib-0.99.2-1.el7.x86_64 2/4
Verifying : clamav-data-0.99.2-1.el7.noarch 3/4
Verifying : clamav-0.99.2-1.el7.x86_64 4/4
Installed:
clamav.x86_64 0:0.99.2-1.el7
Dependency Installed:
clamav-data.noarch 0:0.99.2-1.el7 clamav-filesystem.noarch 0:0.99.2-1.el7 clamav-lib.x86_64 0:0.99.2-1.el7
Complete!
@
Updated by Jonathan CLARKE about 8 years ago
That looks bad indeed.
There are several issues in the existing package_install* ncf methods that boil down to major issues in the underlying implementation.
In Rudder 3.2.8 we introduced two new methods, package_present and package_absent. These are based on an entirely new underlying implementation and initial testing had showed they succeed where the old methods fail.
May I suggest you test these methods? We'd love to hear your feedback.
See http://www.ncf.io/pages/reference.html#package_present
Assuming these methods work well, the long term plan is for them to phase out the older ones.
Updated by Florian Heigl about 8 years ago
I'll upgrade and switch this affected technique.
migrating all of them sounds like a good case for sed, if it's just switching the method being called... :-)
Updated by Alexis Mousset over 7 years ago
- Target version set to 3.1.19
We may be able to fix this by having different bodies with different package_name_convention whether we have a defined version or not.
The best option is to use the new package Technique when possible.
Updated by Alexis Mousset over 7 years ago
- Subject changed from ncf package install yum/rpm doing weird things (wildcard matching???) to Use different package_name_convention in rpm package_method body when there is a defined version
Updated by Benoît PECCATTE over 7 years ago
- Severity set to Major - prevents use of part of Rudder | no simple workaround
- User visibility set to Getting started - demo | first install | level 1 Techniques
- Priority set to 0
Updated by François ARMAND over 7 years ago
- Priority changed from 0 to 50
We need to check if the problem is still here with the new package techniques.
Updated by Alexis Mousset over 7 years ago
It is specific to old package technique/methods.
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.19 to 3.1.20
Updated by Jonathan CLARKE over 7 years ago
- User visibility changed from Getting started - demo | first install | level 1 Techniques to Operational - other Techniques | Technique editor | Rudder settings
- Priority changed from 50 to 33
Alexis MOUSSET wrote:
It is specific to old package technique/methods.
OK, then changing the visibility to Operational, because this won't be visible on new setups.
Updated by Vincent MEMBRÉ over 7 years ago
- Target version changed from 3.1.20 to 3.1.21
- Priority changed from 33 to 32
Updated by Alexis Mousset over 7 years ago
- Status changed from New to In progress
- Assignee set to Alexis Mousset
Updated by Alexis Mousset over 7 years ago
- Status changed from In progress to Pending technical review
- Assignee changed from Alexis Mousset to Nicolas CHARLES
- Pull Request set to https://github.com/Normation/rudder-techniques/pull/1153
Updated by Alexis Mousset over 7 years ago
- Translation missing: en.field_tag_list set to Sponsored
- Priority changed from 32 to 54
Updated by Alexis Mousset over 7 years ago
- Related to Bug #9547: package_install should use another package body when using a specific package version added
Updated by Alexis Mousset over 7 years ago
- Status changed from Pending technical review to Pending release
Applied in changeset rudder-techniques|fa0e8a750902ce14f0fd4b51a4731c32e5a2fe55.
Updated by Alexis Mousset over 7 years ago
- Severity changed from Major - prevents use of part of Rudder | no simple workaround to Critical - prevents main use of Rudder | no workaround | data loss | security
- Priority changed from 54 to 76
The severity of this issue was underestimated, because it was seen as an impossibility to install a package (with correct reporting). It should actually have been considered critical as it has unwanted and unreported effects on target systems (i.e. install more packages than expected) that could, in some rare cases, break systems or increase attack surface.
Updated by Alexis Mousset over 7 years ago
- Subject changed from Use different package_name_convention in rpm package_method body when there is a defined version to The rpmPackageInstallation technique tries to install package-* instead of package when no version is specified
- Priority changed from 76 to 75
Updated by Alexis Mousset over 7 years ago
- Status changed from Pending release to Released
This bug has been fixed in Rudder 3.1.21 which was released today.
- 3.1.21: Announce Changelog
- Download: https://www.rudder-project.org/site/get-rudder/downloads/