If I have a production mailserver and a series of Linux servers that all develop mail from logging etc, it seems slightly redundant to have so many smtp servers installed on each of those boxes simply forwarding mail as I choose to not have local delivery. Is there a mechanism possible in CentOS to setup a pointer to a different mailserver such that programs like mailx could still send mail?
Currently I have postfix setup with maps so that root on server A has mail sent from root@server-a.fqdnmailto:root@server-a.fqdn and that is relayed to my production box. It just seems like it is an additional service to manage on so many hosts?
Thanks! jlc
Joseph L. Casale wrote:
Currently I have postfix setup with maps so that root on server A has mail sent from root@server-a.fqdnmailto:root@server-a.fqdn and that is relayed to my production box. It just seems like it is an additional service to manage on so many hosts?
I'm not aware of any other method, and as for managing, it's typically set it and forget it. Forward all mail to a central server, no other configuration needed on the local systems.
my postfix config for this purpose is 8 lines, and could probably be cut down even further, haven't tried though
# Postfix Client configuration for production environments queue_directory = /var/spool/postfix command_directory = /usr/sbin daemon_directory = /usr/libexec/postfix mail_owner = postfix inet_interfaces = 127.0.0.1 recipient_delimiter = _ setgid_group = postdrop relayhost = prod-utility-vip.sea2.my.domain
nate
On Feb 6, 2008 12:03 PM, nate centos@linuxpowered.net wrote:
Joseph L. Casale wrote:
Currently I have postfix setup with maps so that root on server A has mail sent from root@server-a.fqdnmailto:root@server-a.fqdn and that is relayed to my production box. It just seems like it is an additional service to manage on so many hosts?
I'm not aware of any other method, and as for managing, it's typically set it and forget it. Forward all mail to a central server, no other configuration needed on the local systems.
my postfix config for this purpose is 8 lines, and could probably be cut down even further, haven't tried though
<snip>
Same here, I don't like having mail daemons running on 30+ virtual machines, but I do it anyway, with postfix similar to Nate. I'm obsessive-compulsive when it comes to minimizing the footprint of a virtual machine, but I've given up on this one. An advantage to having outbound mail handled by a local daemon is the queuing of failures. When your mail server or network is temporarily down, you don't want to lose messages. Think of your typical fat-client mail program like Thunderbird. If it can't reach the outbound server, you're done, message failed. With postfix handling the transfer of messages, it queues it up and delivers it as soon as possible with no intervention. Any attempt at getting mail off a Linux box without a local daemon is ultimately going to be much messier and higher maintenance than running a local MTA.
My $0.02,
Jeff
Same here, I don't like having mail daemons running on 30+ virtual machines, but I do it anyway, with postfix similar to Nate. I'm obsessive-compulsive when it comes to minimizing the footprint of a virtual machine, but I've given up on this one. An advantage to having outbound mail handled by a local daemon is the queuing of failures. When your mail server or network is temporarily down, you don't want to lose messages.
Yeah, that is my reasoning but your justification is good.
Thanks guys! jlc
Joseph L. Casale wrote:
If I have a production mailserver and a series of Linux servers that all develop mail from logging etc, it seems slightly redundant to have so many smtp servers installed on each of those boxes simply forwarding mail as I choose to not have local delivery. Is there a mechanism possible in CentOS to setup a pointer to a different mailserver such that programs like mailx could still send mail?
Currently I have postfix setup with maps so that root on server A has mail sent from root@server-a.fqdnmailto:root@server-a.fqdn and that is relayed to my production box. It just seems like it is an additional service to manage on so many hosts?
you don't need an smtpd server (listener) but you need a daemon that queues mail and sends it to the relay host. programs such as cron cannot handle mail delivery failures.
it is a wrong approach to try to minimize daemons. having many daemons that do only one task is better than a monolythic service that does everything. In other words, look at the plan9 side, not at the windows side.
On 06/02/2008 17:26, Joseph L. Casale wrote:
If I have a production mailserver and a series of Linux servers that all develop mail from logging etc, it seems slightly redundant to have so many smtp servers installed on each of those boxes simply forwarding mail as I choose to not have local delivery. Is there a mechanism possible in CentOS to setup a pointer to a different mailserver such that programs like mailx could still send mail?
Currently I have postfix setup with maps so that root on server A has mail sent from root@server-a.fqdn mailto:root@server-a.fqdn and that is relayed to my production box. It just seems like it is an additional service to manage on so many hosts?
Thanks! jlc
There are lightweight SMTP clients that can be used as drop-in sendmail(1) replacements by speaking directly to a remote SMTP server instead of dropping the message in the local queue directory. One that I've used is mini_sendmail (http://www.acme.com/software/mini_sendmail/), though this was a while ago but I seem to recall having some success with it.
Others have mentioned the trade-off between the additional complexity of maintaining an MTA on each system and the fault-tolerance such a setup provides, however, you can achieve similar levels of fault tolerance by implementing redundancy on your relay server system(s). I guess it's up to you to figure out what's appropriate to your environment.
cheers Luke
Luke Dudney wrote:
There are lightweight SMTP clients that can be used as drop-in sendmail(1) replacements by speaking directly to a remote SMTP server instead of dropping the message in the local queue directory. One that I've used is mini_sendmail (http://www.acme.com/software/mini_sendmail/), though this was a while ago but I seem to recall having some success with it.
Others have mentioned the trade-off between the additional complexity of maintaining an MTA on each system and the fault-tolerance such a setup provides, however, you can achieve similar levels of fault tolerance by implementing redundancy on your relay server system(s). I guess it's up to you to figure out what's appropriate to your environment.
it's not a redundancy issue. it's a queue issue. when cron sends mail and if the sendmail command fails, cron can't do anything (it won't queue mail and retry later).
That said, one can write a script (perl comes to mind) or program that: - replaces sendmail - tries to send, and if it fails saves the message in a queue - runs periodically (from cron for example) to check the queue
but I am not convinced that setting this up on every machine would be easier than configuring postfix or sendmail as a "null client".
on 2/7/2008 4:22 AM mouss spake the following:
Luke Dudney wrote:
There are lightweight SMTP clients that can be used as drop-in sendmail(1) replacements by speaking directly to a remote SMTP server instead of dropping the message in the local queue directory. One that I've used is mini_sendmail (http://www.acme.com/software/mini_sendmail/), though this was a while ago but I seem to recall having some success with it.
Others have mentioned the trade-off between the additional complexity of maintaining an MTA on each system and the fault-tolerance such a setup provides, however, you can achieve similar levels of fault tolerance by implementing redundancy on your relay server system(s). I guess it's up to you to figure out what's appropriate to your environment.
it's not a redundancy issue. it's a queue issue. when cron sends mail and if the sendmail command fails, cron can't do anything (it won't queue mail and retry later).
That said, one can write a script (perl comes to mind) or program that:
- replaces sendmail
- tries to send, and if it fails saves the message in a queue
- runs periodically (from cron for example) to check the queue
but I am not convinced that setting this up on every machine would be easier than configuring postfix or sendmail as a "null client".
Sendmail in its default setup is almost perfect in this respect. It doesn't listen to anything but localhost, and it will get security upgrades with the rest of the system. The only real change it needs is to set up a smarthost for it to relay its notices to, and an alias to root to receive the notices.
The default install of postfix might also be setup this way, but I can't vouch for that personally.
Scott Silva schrieb:
Sendmail in its default setup is almost perfect in this respect. It doesn't listen to anything but localhost, and it will get security upgrades with the rest of the system. The only real change it needs is to set up a smarthost for it to relay its notices to, and an alias to root to receive the notices.
It is even pretty simple to switch off the sendmail daemon and only run the queueing submission agent:
1) edit /etc/sysconfig/sendmail and set "DAEMON=no" 2) edit /etc/mail/submit.mc and set FEATURE(`msp', `[IP.of.relayhost]')dnl
Given the sendmail-cf RPM is already installed a "service sendmail restart" is enough to a light, direct submitting sendmail setup.
Alexander
It is even pretty simple to switch off the sendmail daemon and only run the queueing submission agent:
- edit /etc/sysconfig/sendmail and set "DAEMON=no"
- edit /etc/mail/submit.mc and set FEATURE(`msp', `[IP.of.relayhost]')dnl
Given the sendmail-cf RPM is already installed a "service sendmail restart" is enough to a light, direct submitting sendmail setup.
Alexander
Nice, I only asked about Postfix is that's all I sort-of know. But this helps in that I don't have to install Postfix then switch-mail if sendmail is installed already.
Thanks! jlc
-
Alexander Dalloz -
Jeff Larsen -
Joseph L. Casale -
Luke Dudney -
mouss -
nate -
Scott Silva