More... This question has actually been asked similarly before (in 2008), but not recently from what I can tell:
http://www.mail-archive.com/[email protected]/msg20024.html So, perhaps just an update answer as to whether I need to patch qmail-remote manually or whether these features are now included in the toaster. Any other suggestions also appreciated. Thanks! Tim On Thu, October 6, 2011 10:52 pm, Tim Pleiman wrote: > eth0:0 is a child of the parent, eth0. If the physical interface itself > dies, they both go down. You also cannot manually take down (ifdown > <interface>) eth0 without also taking down eth0:0. They function together > as eth0. However, when you have a multi-wan setup in this situation (which > is a real life setup in this case), the interface is binding to two ip > addresses with two different network routes. iproute2 routing entries are > utilized to direct in/out traffic to the correct network gateway, > depending on origination, and a failover script changes the default > outbound gateway from the parent's to the child's if a particular server > beyond the parent's gateway cannot be detected via the parent. > > This is not an issue with the actual interface going down, but with the > route becoming unavailable on the parent (eth0) when the service > provider's network goes down on the parent. What I've discovered is that > Qmail remote natively binds to the ip address of the parent here unless > otherwise instructed, disregarding the default outbound gateway no matter > what. Hence the need for bindroutes or senderip, which I do believe can be > utilized to solve my problem. > > So, the original question, I do believe, applies. There may be other > solutions, e.g. additional routing entries placed in failover script as > well to route traffic from one network to the other network, but either > way, I need to get qmail traffic to go out the child interface ip address > here instead of getting stuck in the queue on the parent interface ip > address. bindroutes and/or senderip should work as one solution though, > perhaps the simplest, unless I have to re-patch to use them. > > Thanks! > Tim > > > On Thu, October 6, 2011 2:52 pm, Michael J. Colvin wrote: >> 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] >> >> >> > > > -- > 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] > > > -- 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]
