Project

General

Profile

Actions

Bug #9283

closed

The rpmPackageInstallation technique tries to install package-* instead of package when no version is specified

Bug #9283: The rpmPackageInstallation technique tries to install package-* instead of package when no version is specified

Added by Florian Heigl about 9 years ago. Updated over 3 years ago.

Status:
Released
Priority:
N/A
Category:
Techniques
Target version:
Severity:
Critical - prevents main use of Rudder | no workaround | data loss | security
UX impact:
User visibility:
Operational - other Techniques | Technique editor | Rudder settings
Effort required:
Priority:
0
Name check:
Fix check:
Regression:

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!
@


Related issues 1 (0 open1 closed)

Related to Rudder - Bug #9547: package_install should use another package body when using a specific package versionReleasedNicolas CHARLESActions

Updated by Jonathan CLARKE about 9 years ago Actions #1

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 9 years ago Actions #2

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 almost 9 years ago Actions #3

  • 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 almost 9 years ago Actions #4

  • 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 8 years ago Actions #5

  • 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 8 years ago Actions #6

  • 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 8 years ago Actions #7

It is specific to old package technique/methods.

Updated by Vincent MEMBRÉ over 8 years ago Actions #8

  • Target version changed from 3.1.19 to 3.1.20

Updated by Jonathan CLARKE over 8 years ago Actions #9

  • 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 8 years ago Actions #10

  • Target version changed from 3.1.20 to 3.1.21
  • Priority changed from 33 to 32

Updated by Alexis Mousset over 8 years ago Actions #11

  • Status changed from New to In progress
  • Assignee set to Alexis Mousset

Updated by Alexis Mousset over 8 years ago Actions #12

  • 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 8 years ago Actions #13

  • Translation missing: en.field_tag_list set to Sponsored
  • Priority changed from 32 to 54

Updated by Alexis Mousset over 8 years ago Actions #14

  • Related to Bug #9547: package_install should use another package body when using a specific package version added

Updated by Alexis Mousset over 8 years ago Actions #15

  • Status changed from Pending technical review to Pending release

Updated by Alexis Mousset over 8 years ago Actions #16

  • 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 8 years ago Actions #17

  • 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 8 years ago Actions #18

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 3.1.21 which was released today.

Updated by Alexis Mousset over 3 years ago Actions #19

  • Priority changed from 75 to 0
Actions

Also available in: PDF Atom