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 over 13 years ago. Updated over 9 years ago.
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.
Updated by Jonathan CLARKE over 13 years ago
- Target version changed from 9 to 10
Updated by François ARMAND about 13 years ago
- Target version changed from 10 to 24
Updated by Jonathan CLARKE over 12 years ago
- Target version changed from 24 to Ideas (not version specific)
Updated by Nicolas CHARLES almost 12 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 ?
Updated by Jonathan CLARKE over 11 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.
Updated by Jonathan CLARKE over 11 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
- 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)
Updated by Jonathan CLARKE over 11 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
Updated by Jonathan CLARKE over 11 years ago
- Status changed from Pending technical review to Pending release
- % Done changed from 0 to 100
Applied in changeset commit:9a3111c72f817cc970353d50a12bc4c2febff5a8.
Updated by Jonathan CLARKE over 11 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
Updated by Jonathan CLARKE over 11 years ago
- Status changed from Pending technical review to Pending release
Updated by Nicolas PERRON about 11 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
Updated by Nicolas PERRON about 11 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:
- The release announcement: http://www.rudder-project.org/pipermail/rudder-announce/2013-September/000044.html
- The full ChangeLog: http://www.rudder-project.org/foswiki/bin/view/System/Documentation:ChangeLog24
- Download information: http://www.rudder-project.org/foswiki/Download/
Updated by Benoît PECCATTE over 9 years ago
- Project changed from 24 to Rudder
- Category changed from Techniques to Techniques