Maybe I'm missing something, but other than administratively taking eth0 down, and leaving eth0:0 up, how would eth 0 go down and NOT take eth0:0 with it?
IE, a cable being bad, or the switch port that patch cable is plugged into going bad, is going to take eth0 AND eth0:0 down. They're both part of the same physical port, no? Now, if you had eth0 and eth1, both different physical ports, with different physical connections, I could see what you're trying to accomplish... Two ip addresses doesn't necessarily mean two separate connections, just because you've bound them to a physical Ethernet interface and a virtual/sub interface... Mike -----Original Message----- From: Tim Pleiman [mailto:[email protected]] Sent: Thursday, October 06, 2011 10:13 AM To: [email protected] Subject: [qmailtoaster] Is Qmailtoaster patched to be able to use these Qmail Control Files? I now have a toaster server with multiple ip addresses bound to the WAN Nic. Qmail-smtpd automatically listens on both ip addresses inbound (eth0 and eth0:0), but by default qmail-remote binds to only the first (eth0) outbound. In a situation where eth0 is down (with only eth0:0 available), this causes qmail-remote to hold messages in queue until eth0 becomes available again. Are the following qmail control options available for qmail-remote--e.g. patched into the toaster distribution? If so, what would be the best configuration utilizing these control options--e.g. to always have qmail-remote bind to the IP address on eth0 when available, but to automatically fail to the IP address on eth0:0 when eth0 is not available? Or would I need a script to update one of these control files that executes automatically during a failover to the IP on eth0:0 when the IP on eth0 is not available? bindroutes (qmail-remote) Any mail sent from an specific source IP address will be sent from the given IP address. The entry in bindroutes looks like this: source ip:ip Example for bindroutes: # network 10.x.x.x 10.:1.2.3.4 # network 10.10.x.x 10.10.:1.2.3.4 # network 10.10.10.x 10.10.10.:1.2.3.4 # host 10.10.10.10 10.10.10.10:1.2.3.4 # rest :1.2.3.4 # don't send any mail to this 1.2.3.4: If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. senderip overwrites bindroutes. and/or senderip (qmail-remote) Any mail sent from an email address in the given domain will be sent from the given IP address. The entry in senderip looks like this: domain:ip If qmail-remote is not able to bind to that IP address then the message will stay in the queue until the problem has been corrected. -- Tim Pleiman Bravo Systems Technologies "Advanced Open Source Solutions for Business" Chicago, IL USA ---------------------------------------------------------------------------- ----- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! ---------------------------------------------------------------------------- ----- Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected] --------------------------------------------------------------------------------- Qmailtoaster is sponsored by Vickers Consulting Group (www.vickersconsulting.com) Vickers Consulting Group offers Qmailtoaster support and installations. If you need professional help with your setup, contact them today! --------------------------------------------------------------------------------- Please visit qmailtoaster.com for the latest news, updates, and packages. To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
