Bug 767375

Summary: Postfix does not set alternative mta properly.
Product: Red Hat Enterprise Linux 5 Reporter: Richard Shade <rshade98>
Component: postfixAssignee: Jaroslav Škarvada <jskarvad>
Status: CLOSED NOTABUG QA Contact: qe-baseos-daemons
Severity: high Docs Contact:
Priority: unspecified    
Version: 5.6   
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-12-15 14:47:58 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Richard Shade 2011-12-13 22:10:50 UTC
Description of problem:
The postfix install should run "alternatives --set mta /usr/sbin/sendmail.postfix" after it runs the alternatives --install in the %post part of the rpm. 

Version-Release number of selected component (if applicable):
2.3.3

How reproducible: Very Reproducible. 


Steps to Reproduce:
1. Install postfix
2. alternatives --display mta
3. echo 'content' | mail -s "mail subject" user 
4. alternatives --set mta /usr/sbin/sendmail.postfix
5. echo 'content' | mail -s "mail subject" user 
  
Actual results:
Permission denied Program mode requires special privileges, e.g., root or TrustedUser

Expected results:
should send email


Additional info:

Comment 1 Jaroslav Škarvada 2011-12-14 16:45:13 UTC
Hi Richard,

I think the current behavior is correct. The installation of alternative mailer shouldn't change your system wide defaults. From my point of view it is the admin task to change the system mailer. Also from the RHEL-5 deployment guide:

> Important: Before using Postfix, the default MTA must be switched from Sendmail to Postfix.

You also need to manually take down your current mailer and start postfix, after the change, e.g.:
# service sendmail stop
# service postfix start

Comment 2 Richard Shade 2011-12-14 17:05:27 UTC
Jaroslav, Thanks for your reply. These are probably some noob questions so please excuse me if they seem simple. Could you explain the use-case where I would install the alternative mailer but not want it to be the default? It seems like sendmail and postfix would be in conflict then, and postfix should stop sendmail automatically. Also the point of rpms as I understand it is to have an automated install, hence why there is nothing like debconf on them, so it should make it functioning, right?

Comment 3 Jaroslav Škarvada 2011-12-14 17:43:42 UTC
(In reply to comment #2)
> Jaroslav, Thanks for your reply. These are probably some noob questions so
> please excuse me if they seem simple. Could you explain the use-case where I
> would install the alternative mailer but not want it to be the default?
>
Probably not the major use cases. Maybe something like testing / benchmarking when you need to periodically switch the mailers in defined time frames. Or imagine the situation when the postfix would be (accidentally) required as a dep by other package - it would change you system settings.

Also from my point of view the switch process is not trivial to be done automatically. In business environment it would require defined outage when the sysadmin would manage processing of all queued mail, migrate the settings, harden the default configs, test it's setup, etc. For me the mailer installation and migration are two distinct things that needn't happen simultaneously.

If you run:
# yum install postfix
# yum remove sendmail

you will end with postfix to be the only mailer (I think probably most of the use cases). Removing your previously default system mailer is probably enough signal that your new mailer setup is ready.

Comment 4 Jaroslav Škarvada 2011-12-15 14:47:58 UTC
According to comment 1 the current behavior is conformable with RHEL-5 Deployment Guide (http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/Deployment_Guide/), thus I am closing this. If you need the current behavior to be changed (e.g. business requirements), please escalate the issue through Customer Portal.