Project

General

Profile

Actions

Bug #1175

closed

Techniques "Package management for RHEL / CentOS / SuSE / RPM systems" and "Package management for Debian / Ubuntu / APT systems": Always report success, even on repair

Added by Jonathan CLARKE almost 13 years ago. Updated about 9 years ago.

Status:
Released
Priority:
3
Category:
Techniques
Target version:
Severity:
UX impact:
User visibility:
Effort required:
Priority:
Name check:
Fix check:
Regression:

Description

This is due to a limitation in apt-get/aptitude/yum/rpm that don't return interesting exit codes, and/or cfengine that can't detect changes otherwise.

See #1073 for details.


Related issues 1 (0 open1 closed)

Related to Rudder - Bug #3816: Technique "Package management for RHEL / CentOS / SuSE / RPM systems": Typos related changes - refs #1175ReleasedNicolas CHARLES2013-08-05Actions
Actions #1

Updated by Jonathan CLARKE almost 13 years ago

  • Target version changed from 9 to 10
Actions #2

Updated by François ARMAND over 12 years ago

  • Target version changed from 10 to 24
Actions #3

Updated by Jonathan CLARKE almost 12 years ago

  • Target version changed from 24 to Ideas (not version specific)
Actions #4

Updated by Nicolas CHARLES about 11 years ago

  • Category changed from Policy Templates to Techniques
  • Status changed from New to Discussion
  • Assignee set to Jonathan CLARKE

I checked this behavior with the technique Apache2, and it correctly told me that the package was installed/repaired given the state (it was with CFEngine 3.2.4 on debian-5-32)
So I guess if the problem exists, it exists either on CFEngine 3.2, or on non-debian package.
Could you confirm that this bug still exists ?

Actions #5

Updated by Jonathan CLARKE over 10 years ago

  • Status changed from Discussion to In progress

Nicolas CHARLES wrote:

I checked this behavior with the technique Apache2, and it correctly told me that the package was installed/repaired given the state (it was with CFEngine 3.2.4 on debian-5-32)
So I guess if the problem exists, it exists either on CFEngine 3.2, or on non-debian package.
Could you confirm that this bug still exists ?

The bug still exists, but I guess the title is not clear enough: this is a bug in our package installation Techniques (aptPackageInstallation and rpmPackageInstallation).

The cause of the bug is that we look only at the return codes from apt-get/aptitude/yum to determine whether packages installation was successful or not. CFEngine defines "repaired" or "kept" status depending on the action it finds necessary, based on the list of packages it knows about and the action required. But using return codes overrides this.

The problem with this approach is that these tools do not differentiate in their return code "kept" (as in "I did nothing") and "repaired" (as in "I did what you told me and changed something").

I do not recall the reason for using return codes initially, but I think it was to detect errors. I will check and see if CFEngine now looks at the package manager's return code to detect errors too. If so, we can remove our return code testing and just rely on CFEngine's repaired/kept/error classes, and fix this bug.

Actions #6

Updated by Jonathan CLARKE over 10 years ago

Jonathan CLARKE wrote:

I do not recall the reason for using return codes initially, but I think it was to detect errors. I will check and see if CFEngine now looks at the package manager's return code to detect errors too. If so, we can remove our return code testing and just rely on CFEngine's repaired/kept/error classes, and fix this bug.

So CFEngine does indeed check return codes, even if we don't specifically ask for this.

Currently, CFEngine can:
  • If the package is already installed (according to the package_list command), set a "kept" class - good
  • If the package is not already installed (according to the package_list command), run the package_add command and set a "repaired" class if it returns 0, and an "error" class if it returns anything else - good
  • If you try and install a package that doesn't exist, run the package_add command and set a "repaired" class for aptitude and yum (because they return 0) -- not good
    • Note this actually works fine with apt-get and zypper, that kindly returns 100 and 104 if you try and install a package that doesn't exist
Given this information, I think we should:
  • Ignore return codes ourselves, and let CFEngine handle them. This means that if the package manager does return an error code, it will be considered an error (good) and if it doesn't, the kept/repaired status will be decided by CFEngine based on it's package promise logic (good)
  • Prefer apt-get on Debian-like systems, to benefit from the return codes (aptitude doesn't provide them)
This will represent an improvement (we get a repaired status at least sometimes), but doesn't fix the fact that yum doesn't care about not installing a package that doesn't exist. I have opened two other bugs found in the process of analyzing this:
  • #3814: Attempting to install a non-existant package via yum should return an error
  • #3815: Package installation using yum doesn't work (RPM based systems like Red Hat / CentOS)
Actions #7

Updated by Jonathan CLARKE over 10 years ago

  • Status changed from In progress to Pending technical review
  • Assignee changed from Jonathan CLARKE to Nicolas CHARLES
  • Pull Request set to https://github.com/Normation/rudder-techniques/pull/163

I have made a Pull Request to add new versions of aptPackageInstallation and rpmPackageInstallation in order to fix several bugs in one, including this one.

Please review: https://github.com/Normation/rudder-techniques/pull/163

Actions #8

Updated by Jonathan CLARKE over 10 years ago

  • Status changed from Pending technical review to Pending release
  • % Done changed from 0 to 100

Applied in changeset commit:9a3111c72f817cc970353d50a12bc4c2febff5a8.

Actions #9

Updated by Jonathan CLARKE over 10 years ago

  • Status changed from Pending release to Pending technical review
  • Target version changed from Ideas (not version specific) to 2.4.8
  • % Done changed from 100 to 0
Actions #10

Updated by Jonathan CLARKE over 10 years ago

  • Status changed from Pending technical review to Pending release
Actions #11

Updated by Nicolas PERRON over 10 years ago

  • Subject changed from PT packages (apt+rpm) always report success, even on repair to Techniques "Package management for RHEL / CentOS / SuSE / RPM systems" and "Package management for Debian / Ubuntu / APT systems": Always report success, even on repair
Actions #12

Updated by Nicolas PERRON over 10 years ago

  • Status changed from Pending release to Released

This bug has been fixed in Rudder 2.4.8, which was released today.
Check out:

Actions #13

Updated by Benoît PECCATTE about 9 years ago

  • Project changed from 24 to Rudder
  • Category changed from Techniques to Techniques
Actions

Also available in: Atom PDF