Hide Forgot
*** Description of problem: I upgraded my RHEL-7 Workstation laptop to RHEL-7.3 Beta, and my dovecot setup stopped working. *** Version-Release number of selected component (if applicable): dovecot-2.2.10-7.el7.x86_64 *** How reproducible: 1/1 *** Steps to Reproduce: 1. Dovecot 2.2.10-7.el7 addressed bug 1280433; the new "first_valid_uid" setting in "/etc/dovecot/conf.d/10-mail.conf" is explicitly 1000 now, as opposed to the previous default 500. 2. However, on my RHEL-7 system, /etc/login.defs specifies SYS_UID_MIN=500, and SYS_UID_MAX=499. I understand that 1000 is the default value <https://fedoraproject.org/wiki/Features/1000SystemAccounts>, but in my understanding it's valid for users and sysadmins to customize /etc/login.defs. On my system, I have 17 (seventeen) allocated UIDs in the 201..499 (SYS_UID_MIN..SYS_UID_MAX) range. 3. The real problem is not that "first_valid_uid" has been set to 1000. I guess if that's the login.defs default that we have for SYS_UID_MIN, then the dovecot default should match it -- fine. The real problem is that the upgrade broke my configuration *silently*. It did not create any xxx.rpmnew or xxx.rpmsave files; it just overwrote "/etc/dovecot/conf.d/10-mail.conf" in-place. The only reason I can now narrow down the problem (after looking at the terse dovecot log in journalctl) is that I keep regular backups of my system, and I can recursively diff "/etc/dovecot" between my last backup and my current (upgraded, broken) config. *** Actual results: Preexistent non-default configuration is changed silently. *** Expected results: New configuration should be installed under xxxx.rpmnew, or at least the old configuration should be saved (and reported during the upgrade) as xxxx.rpmsave. *** Additional info: The upgrade to RHEL-7.3 Beta changed ~770 packages on my system, and produced ~15 warnings about rpmsave and rpmnew files. After the upgrade, I meticulously reviewed all those files, sometimes adopting the new, sometimes keeping the old, and frequently merging my old changes into the new configs. While rpm -q --configfiles dovecot does report /etc/dovecot/conf.d/10-mail.conf as a configuration file, the upgrade overwrote that config file silently.
(In reply to Laszlo Ersek from comment #0) > 3. The real problem is not that "first_valid_uid" has been set to 1000. I > guess if that's the login.defs default that we have for SYS_UID_MIN, then > the dovecot default should match it -- fine. Typo; s/SYS_UID_MIN/UID_MIN/ in the above please.
Thanks for reporting this. We will make sure this is properly documented with update release notes, that it can require admins attention to check the configuration. Unfortunately, what you describe is not how config *.rpmnew handling works. Files that are marked as config files have special treatment. This means that if you changed that file, it won't get overwritten and won't receive any configuration updates. When default configuration changes, it is stored as *.rpmnew file. On the other hand, if config file was not manually changed, then system will not treat it specially and it will write new config file over the old one.
Thank you for the update. (In reply to Michal Hlavinka from comment #4) > Thanks for reporting this. We will make sure this is properly documented > with update release notes, that it can require admins attention to check the > configuration. > > Unfortunately, what you describe is not how config *.rpmnew handling works. > Files that are marked as config files have special treatment. This means > that if you changed that file, it won't get overwritten and won't receive > any configuration updates. When default configuration changes, it is stored > as *.rpmnew file. On the other hand, if config file was not manually > changed, then system will not treat it specially and it will write new > config file over the old one. I understand that this is how things are *supposed* to work. After I wrote my earlier comments, I sought to educate myself on the config file handling. Namely, I found this very helpful article / table: http://www-uxsup.csx.cam.ac.uk/~jw35/docs/rpm_config.html So I went to the dovecot rhpkg / dist-git repo, and checked the spec file. I found: %config(noreplace) %{_sysconfdir}/dovecot/conf.d/10-mail.conf And that's what I don't understand! The SPEC file looks correct. The situation was as follows: - the original package specified %config(noreplace) for 10-mail.conf, - on my system, 10-mail.conf was locally modified after the original package installation, - the upgrade package specified %config(noreplace) for 10-mail.conf just the same, - the upgrade package provided 10-mail.conf with changed contents. According to the table referenced above, this *should have* resulted in a "10-mail.conf.rpmnew" file on my system, after the upgrade. But, there was no such file, the local file which I had modified meanwhile was silently overwritten. In other words: as far as I can see, everything is fine in Dovecot, and (I guess?) I hit an obscure bug in "rpm" instead. RPM didn't do what it was supposed to do, in response to %config(noreplace). Should we move this bug to RPM? Thanks.
You are right, that in above case it should have created the .rpmnew file. So, if it did not create it, it would be a bug. On the other hand, this is a code that is used many times during many updates and no issues were reported so far, which makes it odd. Are you 100 % sure, that your 10-mail.conf was modified? What changes did you have there? Also, is it possible for you to try to reproduce this?
At the time of the upgrade from 2.2.10-5.el7 to 2.2.10-7.el7 my dovecot configuration in the file "etc/dovecot/conf.d/10-mail.conf" was matching the *RHEL-6* default configuration. For example, the one you can find in dovecot-2.0.9-22.el6.x86_64.rpm right now. The reason for this is that when I installed RHEL-7.0 (Beta?) originally, I preserved most of my RHEL-6 configuration files. So, when the upgrade from 2.2.10-5.el7 to 2.2.10-7.el7 was started, for some reason RPM thought that I had an unmodified 10-mail.conf file. This was not the case: what I had at that point didn't equal the default configuration from "2.2.10-5.el7"; instead, it matched the default configuration from "2.0.9-22.el6". To RPM this should just have meant a locally modified file, though. Perhaps timestamps (mtimes) matter -- I'm not sure. The mtime on the "2.2.10-5.el7" default config file is (in UTC) 2014-06-11 15:01:51 while my local 10-mail.conf file (with the contents matching the RHEL-6 default) had the following mtime (in UTC): 2015-08-24 14:57:16 Thus, not only was the content of the local file different, from the 2.2.10-5.el7 default (at the time of the 2.2.10-5.el7 --> 2.2.10-7.el7 upgrade), but the local file was even younger than the 2.2.10-5.el7 default. With regard to reproducing it again... I don't think so. My apologies but my laptop is my production / work environment, and I'm glad it's working again. I'm fine if we close this issue as INSUFFICIENT_DATA. After all, the dovecot SPEC file is correct. Thanks.
I've just tried it: clean rhel7 virtual machine install dovecot 2.2.10-5.el7 rpm -Vf /etc/dovecot/conf.d/10-mail.conf -> reports as not changed overwrite 10-mail.conf with file from 2.0.9-22.el6 rpm -Vf ... reports fole is different "S.5....T. c" yum update to dovecot 2.2.10-7.el7 -> 10-mail.conf.rpmnew created, file not overwritten closing as you've suggested