| Summary: | upgrading from 2.2.10-5.el7 to 2.2.10-7.el7 regresses existing configuration SILENTLY | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Laszlo Ersek <lersek> |
| Component: | dovecot | Assignee: | Michal Hlavinka <mhlavink> |
| Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | qe-baseos-daemons |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 7.3 | ||
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: |
Dovecot's default configuration of first_valid_uid was changed to 1000 to match system wide configuration from /etc/login.defs If sytem has configuration manually changed to 500 and is relying on dovecot's default value, dovecot will not serve users with id lower than first_valid_uid. As a consequence you have to update first_valid_uid if you have regular users with id less than 1000. With this change, dovecot will work as expected.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-10-31 15:23:30 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: | |
|
Description
Laszlo Ersek
2016-10-24 11:11:18 UTC
(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 |