Bug 1828672
| Summary: | postfix main.cf: unnecessary explicit value of shlib_directory | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 8 | Reporter: | Max <mnikulin> |
| Component: | postfix | Assignee: | Jaroslav Škarvada <jskarvad> |
| Status: | CLOSED WONTFIX | QA Contact: | qe-baseos-daemons |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 8.1 | Flags: | pm-rhel:
mirror+
|
| Target Milestone: | rc | ||
| Target Release: | 8.0 | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-05-15 09:04:13 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: | |||
(In reply to Max from comment #0) > It seems that shlib_directory=%{postfix_shlib_dir} > should not be passed to make non-interactive-package > in the postfix.spec file > https://src.fedoraproject.org/rpms/postfix/c/ > 193d7f243dcaf0c480da201198321892aee61775 > So it should be easy to fix the issue. > No, this doesn't work, because it seems that 'postfix-install' always calls 'postconf -c "shlib_directory = $shlib_directory"'. I am not going to patch the upstream install script to remove this. If you think it's bug, please bring the problem upstream. Also I don't understand why is this problem. The config files should be handled by rpm, if you have default configuration files it will be replaced automatically. If not, .rpmnew files will be created. If the packager of your 3rd party rpm calls the postfix-install (i.e. the upstream way), the shlib_directory should be also there (in the config file). Not counting that running third party build of postfix in RHEL is not supported. If it is important for you or your business, please escalate through the support channel. Sorry, my bad. The problem is really not with postfix-install argument, you are completely right. My incorrect expectation was that no additional patches are required and the problem is solely caused by the package .spec file. The problem with .rpmnew file is that restoring postfix configuration to working state requires manual action. Modification of configuration files is usual procedure for administrators and smooth upgrades should be ensured if possible. I did not asked for support of 3rd party rpm package, the issue is about unnecessary obstacles to other packages. I still believe that transition to or from RedHat (Fedora) package could be more reliable. Discussion of the issue with upstream: https://marc.info/?l=postfix-users&m=158877630705116&w=2 I have not managed to convince postfix developers to avoid setting of shlib_directory during postfix-install. On the other hand I got the suggestion to use 'postfix upgrade-configuration' (post install scriptlet) to make value consistent with new package version. It sounds reasonable unless there are scenarios when the value must be customized by server administrator. It is still not clear for me why having explicit value of shlib_directory in main.cf file is considered more reliable, if its absence makes package upgrades easier and the build time value could be always obtained from any external tool using 'postconf shlib_directory' command. You could consider adding shlib_directory argument to 'postfix upgrade-configuration' command, but there are might be drawbacks I am not aware of. Feel free to close the issue. Thank you for the hint concerning actual source of problem. OK, thanks for info, closing as wontfix because I dont' want to diverge from upstream. |
Description of problem: /etc/postfix/main.cf config file contains the following line shlib_directory = /usr/lib64/postfix It leads to a problem during upgrade to custom postfix package having newer version if the latter has another shlib_directory. Version-Release number of selected component (if applicable): postfix-3.3.1-9.el8.x86_64.rpm How reproducible: reproducible Steps to Reproduce: 1. Ensure that postfix from RHEL repository is installed 2. Modify /etc/postfix/main.cf, e.g. just add some comment line 3. Upgrade postfix to 3rd party package having newer version Actual results: - Postfix (3rd party) could not be started - /etc/postfix/main.cf: shlib_directory = /usr/lib64/postfix Apr 17 15:34:13 test.tld systemd[1]: Starting Postfix Mail Transport Agent... Apr 17 15:34:13 test.tld postfix[3613]: /usr/libexec/postfix/postfix-script: line 74: cd: /usr/lib64/postfix: No such file or directory Apr 17 15:34:13 test.tld postfix/postfix-script[3615]: fatal: no Postfix shared-library directory /usr/lib64/postfix! Apr 17 15:34:14 test.tld systemd[1]: postfix.service: Control process exited, code=exited status=1 Apr 17 15:34:14 test.tld systemd[1]: postfix.service: Failed with result 'exit-code'. Apr 17 15:34:14 test.tld systemd[1]: Failed to start Postfix Mail Transport Agent. Expected results: - Postfix is running. - Directives in original main.cf file do not cause problems during package upgrade (no shlib_directory directive at all or shlib_directory = no) Workaround: Comment-out shlib_directory line in main.cf Additional info: I suppose, everything should work without explicit shlib_directory setting, since configured value coincides with the default one: postconf -d shlib_directory shlib_directory = /usr/lib64/postfix postconf shlib_directory shlib_directory = /usr/lib64/postfix It seems that shlib_directory=%{postfix_shlib_dir} should not be passed to make non-interactive-package in the postfix.spec file https://src.fedoraproject.org/rpms/postfix/c/193d7f243dcaf0c480da201198321892aee61775 So it should be easy to fix the issue. I think, the same problem may happen later with RedHat packages if it will be decided to change location of shlib_directory. Removing of unnecessary directive is better than dealing with the problem in package scripts.