Bug 1380274
| Summary: | Problem with verification package osad | ||
|---|---|---|---|
| Product: | Red Hat Satellite 5 | Reporter: | Martin Korbel <mkorbel> |
| Component: | Client | Assignee: | Jiří Dostál <jdostal> |
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Pavel Studeník <pstudeni> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 570 | CC: | ggainey, jdostal, jhutar, pstudeni, tlestach |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | osad-5.11.63-7-sat | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2017-06-21 12:19:44 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | |||
| Bug Blocks: | 1358815 | ||
Honestly, I do not believe this is a bug. I install osad and see: # rpm -V osad # # cat /etc/sysconfig/rhn/osad-auth.conf # Automatically generated. Do not edit! After I start the service using 'service osad start' I see: # rpm -V osad S.5....T. c /etc/sysconfig/rhn/osad-auth.conf # cat /etc/sysconfig/rhn/osad-auth.conf # Automatically generated. Do not edit! [osad-auth] username = osad-207d109204 password = c91105b7e74005e5302a resource = osad The file really changed. Now it contains generated username/password/resource. It make sense, rpm reports the file has changed since the installation. This is the same situation as https://github.com/spacewalkproject/spacewalk/blob/master/client/rhel/yum-rhn-plugin/yum-rhn-plugin.spec#L65 or https://github.com/spacewalkproject/spacewalk/blob/master/client/rhel/rhn-client-tools/rhn-client-tools.spec#L256 I think, the verification should pass, especially when the config file was not modified manually. rpm does not recognize, whether the file has been changed manually or automatically. It reports, it's different from the file packaged in the rpm. correct, but if the user makes a change, he expects the verification can fail for this file. But in this situation, file is changed automatically and user don't know what happened and he is forced to investigate it. next important thing, the application should be consistent. Some config files are ignored and some no (my comment 3). And last thing, no so important, all TPS tests fail for this reason. I have already merged your PR. I'm enclosing Spacewalk commit, but we can discuss this further. spacewalk.git 92691b849e38e1e4fd27570acde9ebfac87b8576 In my opinion I agree with Martin, as the error shown might not be expected by user and may result in investigation of something that is working correctly. Switching to MODIFIED, please change if you disagree. Just throwing my $0.02 in here - I did some digging on the topic, and got a lot of conflicting results (of course). The question boils down to whether -V is to let the user detect *any* change, vs *unexpected* changes. The problem with turning off checks in "expected" cases, as tlestach points out, is -V then stops noticing any changes at all (although you can use -Vv to see all-changes, even ones that -V has been told to ignore) However, the vague consensus (at least as far as I could determine) was that if you expect the RPM to modify the file, then -V shouldn't notice those changes. If we *really* want to fix this, I suspect we'd need to go down the road of what we do with default_configs vs /etc/rhn/rhn.conf - stop modifying files delivered with the RPMs and make local cfg-changes to files that override the defaults. I don't think it's worth the effort, honestly. Anyway - the net for me is, I think making this change gains us more than it loses, and addressing it "the right way" would cost us without giving much back. I say go4it :) For packages like osad, when osad-auth.conf content will be generated at the first start of the daemon and not at build or installation time (by rpm), there isn't a good setting. In both cases the --verify option stops noticing any changes:
* when using "%verify(not md5 size mtime)" - no changes will be noticed ever
* when not using "%verify(not ...)" - the first change will be noticed (== daemon start)
> If we *really* want to fix this, I suspect we'd need to go down the road of
> what we do with default_configs vs /etc/rhn/rhn.conf - stop modifying files
> delivered with the RPMs and make local cfg-changes to files that override
> the defaults.
Well, the rhn.conf is also delivered with an RPM (spacewalk-config) and marked as %verify(not md5 size mtime) in the spec file.
RPM man page says about the --verify option:
===================================
Verifying a package compares information about the installed files in the package with information about the files taken from the package metadata stored in the rpm database.
===================================
I simply believe, we're breaking this statement by introducing the requested change.
As mentioned by Grant, currently linux applications are used configuration folders (d-folder) very often. A package deliveries default configuration file and create something.d folder. In this default configuration file there is mask for loading all local configurations from this d-folder. User makes changes only in own configuration files in d-folder. Update of package updates only default configuration file. It is clear and simple, everyone knows what are default values and what are local changes. In this case, we should be very strict in verification of default configuration files. But SW does not use this clear model and we have to make a compromise. We or users have to be vague to verification. I think in this case, when we write in this file "Automatically generated. Do not edit!" the ball is in our court. Note that 10 years ago, this was implemented for up2date config: Bug 168312 - up2date config file is not ignored in rpm -V https://bugzilla.redhat.com/show_bug.cgi?id=168312 Although I'm for silencing rpm about this file (see IMO similar case: # rpm -qf /etc/shadow setup-2.8.14-20.el6_4.1.noarch # rpm -V setup | grep /etc/shadow ), I believe this is not correct: (In reply to Grant Gainey from comment #7) > ... > (although you can use -Vv to > see all-changes, even ones that -V has been told to ignore) > ... # rpm -V rhn-client-tools # rpm -Vv rhn-client-tools | grep '/etc/sysconfig/rhn/up2date' ......... c /etc/sysconfig/rhn/up2date Reproducer: >> yum install osad-5.11.44-10.el6sat.noarch -y >> service osad start Starting osad: [ OK ] >> rpm -V osad S.5....T. c /etc/sysconfig/rhn/osad-auth.conf Verified with osad-5.11.63-11.el6sat.noarch |
Description of problem: if we try to install osad package on client side and then register system to the satellite then we get error during verification package. Version-Release number of selected component (if applicable): osad-5.11.44-10 How reproducible: 100% Steps to Reproduce: 1. we have client with installed osad package 2. register it to satellite / SW 3. execute command > rpm -V osad Actual results: S.5....T. c /etc/sysconfig/rhn/osad-auth.conf Expected results: <empty> Additional info: