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
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?
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?
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.
(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?)
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.
(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 - 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)?
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.
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.