FOOD FOR THOUGHT postfix instead of sendmail

[chris_c_]

Looked around and didn't find any previous answers to this so here goes.

Ubuntu default MTA is postfix for good reason it's arguably the most secure, easier to configure and rated the best.

However when the ipbx install script calls apt to install sendmail, apt removes postfix because they are marked as conflicting.

Would prefer to run postfix instead of the sendmail package.

The control panel Webmin/Virtualmin work very well with Postfix.

Would it break ipbx to not blindly install sendmail thereby removing postfix as a side effect, when postfix is already installed.

Postfix includes a sendmail binary so any script trying to call sendmail would continue to work.

It seems sendmail is probably a holdover from the first centos days of ipbx/piaf 10 years ago.

Surely someone has already faced this issue and has tested keeping postfix on debian and ubuntu, and found out whether that would run flawlessly...??

 

[wardmundy]

We try to keep all builds with same mix of apps. Too hard to support otherwise. Nothing insecure about sendmail.

 

[hecatae]

but Sendmail just works, to take this further, Ubuntu recommends UFW, a firewall that does not even exist in any of Redhat/Centos/Scientific/Fedora/Korora's repositories

The mix of apps that PBXiaF/IPBX use work well over multiple platforms, I would prefer to recommend new features than try replacing tried and tested applications

 

[chris_c_]

Wasn't say to replace sendmail with postfix. Just saying, if there is an existing MTA on the system (postfix in the case of most ubuntu and debian machines), let it stay installed!

The big 4, Postfix, qmail, and exim all come with sendmail binaries, located in "/usr/sbin/sendmail", for compatibility with any app that wants to call that sendmail binary directly to send mail.

ipbx and all of the apps included with it, call either "sendmail", or "mailutils" which call the sendmail binary provided by each of these MTAs.

An update to the 13-12.2-U14 installer script, at line 392...

#Installing SendMail
if [ -e "/usr/sbin/sendmail" ]; then
echo "/usr/sbin/sendmail binary not found. Installing sendmail."
sudo apt-get -y install sendmail
fi
sudo apt-get -y install mailutils
wait

As for security of postfix vs sendmail vs exim vs qmail, see the following info boxes. They're not very specific and shouldn't influence anyone to not use either of the MTA's but I don't feel ipbx should mandate removing the existing installed MTA when they're all compatible thru the binary sendmail as well as the access layer "mailutils", thru which the pbx applications are reading and sending mail items.

 

[rjaiswal]

Volunteering and helping as much as I can, it's would be a real pain to learn every permutation of every MTA, when someone has a question on why they are not receiving their voicemails via email, and you'd like to help and answer...

I really believe in KISS, and the adage "If it ain't broke, don't fix it."

 

[Jake]

The beautiful thing about PBX in a Flash is you can install postfix, exim or whatever you want to use.
Case in point: I've been working on a Mitel system lately that is nice but if I had root access I could really do what I want to. I can see underlying the Linux/Unix platform but I can't get to it!

 

[wardmundy]

chris_c_ Let's be clear. We're not "mandating" that anybody do anything. We have built an open source GPL aggregation that anyone is free to use or not use, modify or leave alone, and redistribute or sell to your heart's content. We have the one and only product for Asterisk that works identically on numerous hardware platforms and in the Cloud with numerous operating systems. Moving between the systems is fairly transparent once you get over the apt-get/yum hurdle, and we've pretty much hidden that one.

Now multiply the apt-get/yum issue by all of the other permutations, and you can see how support nightmares develop. Let's see. There's SendMail and Postfix and Exim, Apache and Lighttpd and Nginx, MySQL and Postgres, MyISAM and InnoDB, bash and sh, IPtables and Firewalld, HylaFax and Proprietary Fax, Asterisk and FreeSwitch, FreePBX and Asterisk-GUI, and on and on. Does it mean one is better than the other? Not at all. Nothing against people doing their own thing or driving on the left side of the road with the steering wheel on the right, but it's different and we've tried it more than once. Different is a real pain when you're trying to diagnose problems and help out new users. It also means having to document and support multiple ways of doing the same thing to get to the same place. Been there, done that. No thanks!

My dad always had a sign on his desk that caused me to snicker more than once growing up. With age, I've come to appreciate it more and more...

* For those that don't know me, some of the you-know-who fanboys have taken exception to my retelling of one of my childhood growing pains. Rest assured, we want everyone to use all or any of our code as you see fit. That's what the GPL is all about. We obviously cannot support dozens of permutations and combinations of alternative applications. We've tried to document why we endeavor to keep all the builds compatible. That in no way is meant to suggest that you shouldn't substitute the mix of applications that best meets your own requirements.

 

[Dan Lawrence]

While I fully support PiaF keeping consistency with their distributed apps, I often choose to replace sendmail with postfix (usually when I need to set up gmail as a smarthost).

"apt-get install sendmail- postfix" does the trick nicely on debian based systems.

 

[chris_c_]

Yes, agreed, there is a limited amount of time and energy to support all the possible permutations of the number of MTAs, times the number of pbx implementations, times the number of dbs, times web servers, times the number of forked linux distros.

Microsoft always claimed that forking linux distros would be the downfall of linux - if you all remember...

This is why in the interest of get past the forking/incompatibility hurdle, and still reach the most possible linux systems, a way must be found to save time and energy.

To save time and energy, so you can focus on adding performance improvements, features, and and bug fixes, you have to make a separate wrapper layer.

I propose IPBX should sooner or later refactor the hardcoded assumptions currently in the code, move them out of the install script, into a wrapper layer.
When you do this, then IPBX installer would "just work" with whatever "system services" and OS happen to be installed at the time when the IPBX installer is running.

The "wrapper layer" detects the OS, as well as which services are installed.
The script talks to the wrapper layer, makes generic requests.
The wrapper layer talks in "the right commands" to the OS and system services.

Detecting Centos, redhat, fedora, or SL, the "install_binary_package_prerequisites()" function calls yum with the list of RPMs.
For debian/ubuntu/mint it calls apt with the list of DEBs.

"install_MTA_config" wrapper function, on a system with postfix would installs the postfix gist to the postfix config file and tells postfix to reloads the config.
On a system with sendmail detected, it'd install the sendmail gist to the sendmail confg, and tells sendmail to reload the config.
And so on.

This way you're factoring out the permutations and combinations, instead of having to generate one install script for each and every permutation.

One install script, one "wrapper layer" class with about 50 functions, and that's all you need, to be compatible with:
* the top 5-10 linux distros,
* the big 4 MTAs,
* possibly add support for freeswitch engine,
* possibly add wrapper code for kamailio secure encrypted carrier grade sip proxy,
* top 2 web servers (but I expect hardly anyone to care if full support is only for apache to being with),
* top 2-5 databases (again I expect hardly anyone to care about support for only mysql to start with).

 

[wardmundy]

We've actually given that some thought, and you'll find the code in several of the scripts already even though most of it isn't used. The major problem isn't doing what you suggest. It's supporting the mess that would come out on the other end.

 

[chris_c_]

We've actually given that some thought, and you'll find the code in several of the scripts already even though most of it isn't used. The major problem isn't doing what you suggest. It's supporting the mess that would come out on the other end.

Are you taking about paid support? There are apps that let you remotely admin a linux machine with nothing more than knowledge of the customer's ip and ssh port.
Open source community support? That's for the community to do collectively.
As long as the wrapper layer is doing its thing correctly for each supported distro, mta, pbx, proxy, web server, and database, then support would boil down to identifying the occasional exceptional "corner cases" and adding them back into the wrapper layer.
EDIT: one of the big advantages is factoring out "add_amportal_as_service()", "add_hylafax_as_service()" - the implementation of which depends on which version on debian/ubuntu/mint, or centos/rhel/fedora, you're running as to whether it adds service settings into sysvinit, upstart, or systemd. With a wrapper layer it's no problem at all to detect OS and version, add service to the right place, it just works, the user's happy, and you conquer the problem triumphantly.

 

[wardmundy]

Are you taking about paid support? There are apps that let you remotely admin a linux machine with nothing more than knowledge of the customer's ip and ssh port.
Open source community support? That's for the community to do collectively.
As long as the wrapper layer is doing its thing correctly for each supported distro, mta, pbx, proxy, web server, and database, then support would boil down to identifying the occasional exceptional "corner cases" and adding them back into the wrapper layer.
EDIT: one of the big advantages is factoring out "add_amportal_as_service()", "add_hylafax_as_service()" - the implementation of which depends on which version on debian/ubuntu/mint, or centos/rhel/fedora, you're running as to whether it adds service settings into sysvinit, upstart, or systemd. With a wrapper layer it's no problem at all to detect OS and version, add service to the right place, it just works, the user's happy, and you conquer the problem triumphantly.

Sounds a little ambitious. Keep us posted on your progress.

 

[wardmundy]

Nothing beats a war of words about a technical topic on Twitter...


Let me try one final time to explain the rationale behind the choice of SendMail for all of the PIAF and Incredible PBX builds running under CentOS, Ubuntu, Debian, and Raspbian on standalone hardware, in the Cloud, on virtual machine platforms, and on small devices including the Raspberry Pi, the BeagleBone Black, and the PogoPlug.

It's all about ease of use and support. The same commands work everywhere. The same fixes and patches can be loaded everywhere. The same problems can be diagnosed and addressed in the same way everywhere. We don't have paid staff, and we don't charge for support. So, instead of needing an expert on SendMail, Postfix, and Exim to diagnose and resolve email problems, we can support all of the platforms with expertise on SendMail only. Instead of a half dozen messages just to figure out the mix of hardware, OS, and MTA, we can just deal with and quickly resolve the email issue. Can people with MTA expertise load an MTA of their choice? Absolutely!

Most of our users wouldn't know an MTA if it bit them in the . No reason they should. All they do know is that their voicemails or faxes aren't getting sent or delivered (and they never know which). Most never bother to tell you what platform their server is running on much less what the underlying OS and MTA happen to be. Nearly half of all the hobbyist VoIP market uses providers like Comcast and Time Warner, ISPs that are notorious for blocking downstream SMTP traffic. Now factor in the time it takes to diagnose, resolve, and fix email issues on three different MTA platforms and four different OS platforms. Then add the time it takes to maintain a secure MTA on all of those platforms. For anyone that actually administers networks for a living, one would think the solution would be a no-brainer. HINT: It has NOTHING to do with being heavy-handed.

 

[chris_c_]

Make no mistake, I love IPBX and appreciate the time and energy put into developing it by Ward and his army of volunteers!
My suggestions for improvements are coming from a place of wanting to improve the quality reliability and friendliness of the IPBX installer, and increase its penetration into all linux distros, which would be a phenomenal thing for both IPBX and linux and the users.
To add a wrapper layer and thereby achieve a much higher degree of distro independence and interop with user preferred system services, we'll have to take development of this wrapper layer to github, first for the Fax installer. It'd be the same wrapper layer used by the PBX installer script.
I can envision a roadmap that includes improved IPBX and Fax installer scripts, which evolve into DEB and RPM packages, and achieve much higher credibility and traction in the mainstream.