Bug 1380274

Summary: Problem with verification package osad
Product: Red Hat Satellite 5 Reporter: Martin Korbel <mkorbel>
Component: ClientAssignee: Jiří Dostál <jdostal>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Studeník <pstudeni>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 570CC: 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    

Description Martin Korbel 2016-09-29 07:37:51 UTC
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:

Comment 2 Tomas Lestach 2016-09-29 11:54:20 UTC
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.

Comment 3 Martin Korbel 2016-09-29 12:49:09 UTC
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.

Comment 4 Tomas Lestach 2016-09-29 13:10:59 UTC
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.

Comment 5 Martin Korbel 2016-09-29 13:34:04 UTC
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.

Comment 6 Jiří Dostál 2016-09-29 13:55:52 UTC
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.

Comment 7 Grant Gainey 2016-09-29 19:11:21 UTC
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 :)

Comment 8 Tomas Lestach 2016-09-30 10:05:16 UTC
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.

Comment 9 Martin Korbel 2016-09-30 11:36:50 UTC
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.

Comment 10 Jan Hutař 2016-10-03 06:47:53 UTC
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

Comment 11 Jan Hutař 2016-10-03 06:58:00 UTC
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

Comment 13 Pavel Studeník 2017-05-10 13:58:32 UTC
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