Bug 509968 - ldap.conf.rpmnew not created on package upgrade if ldap.conf modified
ldap.conf.rpmnew not created on package upgrade if ldap.conf modified
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: openldap (Show other bugs)
4.8
All Linux
low Severity medium
: rc
: ---
Assigned To: Jan Vcelak
BaseOS QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-07-07 03:55 EDT by Karel Volný
Modified: 2013-03-03 20:27 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-06-20 12:16:53 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Karel Volný 2009-07-07 03:55:53 EDT
Description of problem:
Verifying openldap package fails if configfile was modified. But this is expected, so the file should be excluded from verification not to cause false alarms.

Version-Release number of selected component (if applicable):
openldap-2.2.13-12.el4_8.1

How reproducible:
always

Steps to Reproduce:
1. yum install openldap
2. make some changes to /etc/openldap/ldap.conf
3. rpm -V openldap
  
Actual results:
S.5....T. c /etc/openldap/ldap.conf

Expected results:
(nothing reported)

Additional info:
please see http://docs.fedoraproject.org/drafts/rpm-guide-en/ch09s05.html#id2973021
Comment 1 Jan Zeleny 2010-01-21 07:47:48 EST
I think this notification is intentional to find out whether config file was modified or not. It's true that it is expected, but nevertheless, IMO this verification exception you propose shouldn't be included. Do you have any policy reference or other examples that this is actually done in other packages?
Comment 2 Karel Volný 2010-03-24 07:06:35 EDT
I've investigated a bit further, and it seems I was mistaken a bit at the first try, seems I've messed the reproducer and missed the (noreplace) statement which took me to wrong conclusions, sorry ...

what actually happens:

if ldap.conf gets modified, and the package is updated, it does not get overwritten, and subsequent rpm -V openldap fails on ldap.conf

when using (noreplace), this would be ok, except that ldap.conf.rpmnew should have been created - but it is not

to be exact:

.qa.[root@i386-4as-m1 tps]# rpm -U /mnt/redhat/brewroot/packages/openldap/2.2.13/12.el4_8.2/data/signed/db42a60e/i386/openldap-2.2.13-12.el4_8.2.i386.rpm /mnt/redhat/brewroot/packages/openldap/2.2.13/12.el4_8.2/data/signed/db42a60e/i386/openldap-servers-2.2.13-12.el4_8.2.i386.rpm /mnt/redhat/brewroot/packages/openldap/2.2.13/12.el4_8.2/data/signed/db42a60e/i386/compat-openldap-2.1.30-12.el4_8.2.i386.rpm /mnt/redhat/brewroot/packages/openldap/2.2.13/12.el4_8.2/data/signed/db42a60e/i386/openldap-clients-2.2.13-12.el4_8.2.i386.rpm /mnt/redhat/brewroot/packages/openldap/2.2.13/12.el4_8.2/data/signed/db42a60e/i386/openldap-devel-2.2.13-12.el4_8.2.i386.rpm /mnt/redhat/brewroot/packages/openldap/2.2.13/12.el4_8.2/data/signed/db42a60e/i386/openldap-servers-sql-2.2.13-12.el4_8.2.i386.rpm
.qa.[root@i386-4as-m1 tps]# rpm -V openldap
S.5....T. c /etc/openldap/ldap.conf
.qa.[root@i386-4as-m1 tps]# ls /etc/openldap/*rpmnew
ls: /etc/openldap/*rpmnew: No such file or directory

so this looks like a rpm problem instead

from the RPM Guide linked above:

"Use this option to help protect local modifications. If you use %config(noreplace), the file will not overwrite an existing file that has been modified. If the file has not been modified on disk, the rpm command will overwrite the file. But, if the file has been modified on disk, the rpm command will copy the new file with an extra file-name extension of .rpmnew."

Jan, please could you verify I haven't overlooked anything this time and analyse what happens with the configfile, if it is really a bug of rpm?
Comment 4 Jan Zeleny 2010-03-31 07:36:31 EDT
As I found out, rpm -V should in fact warn that config file has been changed. It is intended feature which helps to pinpoint problems with package. In this case, let's say openldap clients stop working. You run rpm -V openldap and you see that /etc/openldap/ldap.conf has been modified, so that is the first place you should look for problems.

Marking file as %config(noreplace) doesn't turn this feature off, it has to be disabled specifically e.g. by %verify (not md5 mtime). But this would also "kill" the main reason why the feature exists in the first place.

So my opinion is this should be closed as not a bug.
Comment 5 Karel Volný 2010-03-31 10:03:22 EDT
(In reply to comment #4)
> As I found out, rpm -V should in fact warn that config file has been changed.
> It is intended feature which helps to pinpoint problems with package. In this
> case, let's say openldap clients stop working. You run rpm -V openldap and you
> see that /etc/openldap/ldap.conf has been modified, so that is the first place
> you should look for problems.

that is true, but as always, rules have exceptions - if a file is expected to be modified by the system itself then it should not be reported, as it would cause false alarm

however, this is not the case ...

> Marking file as %config(noreplace) doesn't turn this feature off, it has to be
> disabled specifically e.g. by %verify (not md5 mtime). But this would also
> "kill" the main reason why the feature exists in the first place.
> 
> So my opinion is this should be closed as not a bug.    

please see comment #2, there *is* a problem, I just misidentified it at first

I've also changed the Summary to match the problem - or what I think now the problem is

the file on disk differs from the version in the package, as proven by failing the verify test - but the version from the package did not get installed (as .rpmnew), while it should have been installed (or at least this is my understanding of the quoted docs?)
Comment 6 Jan Zeleny 2010-03-31 10:35:21 EDT
I'm sorry, I just wanted to point out that the original issue (md5sum mismatch) isn't an issue after all and the bug should be closed (and for the second issue a new one should have been opened). But since you already renamed this one, I guess we can avoid this procedure and continue here.

About the bug itself: I'm not sure what is the correct behavior of rpm in this case (remember that RHEL4 is quite old and rpm might behaved differently in the time RHEL4 was released). I think it is possible that rpm creates .rpmnew file only when config file in the new version of package differs from the one in current package version.
Comment 7 Karel Volný 2010-04-01 08:03:38 EDT
(In reply to comment #6)
> I'm sorry, I just wanted to point out that the original issue (md5sum mismatch)
> isn't an issue after all and the bug should be closed (and for the second issue
> a new one should have been opened). But since you already renamed this one, I
> guess we can avoid this procedure and continue here.

okay

as for me, I prefer to keep the history of the bug instead of opening a new one, it is useful to have an overview what has been done already

> About the bug itself: I'm not sure what is the correct behavior of rpm in this
> case (remember that RHEL4 is quite old and rpm might behaved differently in the
> time RHEL4 was released). I think it is possible that rpm creates .rpmnew file
> only when config file in the new version of package differs from the one in
> current package version.

in that case I guess we should ask someone more experienced ... CCing & NEEDINFO the rpm owner pmatilai@redhat.com

- Panu, please, could you take a look at the problem (see comment #2) and tell us if the problem is with rpm or if it may be within the openldap package (or if it is just misunderstanding what the correct behaviour should be)?
Comment 8 RHEL Product and Program Management 2010-10-22 14:49:06 EDT
This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated in the
current release, Red Hat is unfortunately unable to address this
request at this time. Red Hat invites you to ask your support
representative to propose this request, if appropriate and relevant,
in the next release of Red Hat Enterprise Linux.
Comment 9 Jiri Pallich 2012-06-20 12:16:53 EDT
Thank you for submitting this issue for consideration in Red Hat Enterprise Linux. The release for which you requested us to review is now End of Life. 
Please See https://access.redhat.com/support/policy/updates/errata/

If you would like Red Hat to re-consider your feature request for an active release, please re-open the request via appropriate support channels and provide additional supporting details about the importance of this issue.

Note You need to log in before you can comment on or make changes to this bug.