pf load balancing and failover
Hey, On 10/26/06, Pete Vickers <[EMAIL PROTECTED]> wrote: If I recall correctly, You don't. :o) slbd adds new rules to pf for each incoming tcp session. Since I couldn't get it to work (old version) I do not know what the session and Sources tables will look like, but I suspect there will be no problems with them in slbd. Client-server association is maintained by slbd and implemented with separate rules for each tcp session. slbd doesn't maintain separate rules for each tcp session. Client-server association is NOT maintained by slbd. This seems a bit ineffective and rather pointless since pf has the load balancing functionality built in. Which slbd relies on. Slbd just inserts the load balancing rules into pf based on it's own config. Then it does the job of health-checking the servers listed in it's config file, and removing them from the server list if they go down. The problems with using pf and a health checking script is related to removal of failed backends. There are two separate issues: 1) When using sticky-address in the rdr rules client-server associations are added to the internal Sources table. It is impossible to remove entries for a single backend from this table. If a backend fails and is removed from the rdr destination table this table will have to be flushed, making all clients end up on new backends, wich is unacceptable in many configurations. If this table is not cleared then the rdr destination table is not inspected for client IP's found in the Sources table. These clients will still be sent to the failed and removed backend. Preferably entries could be removed from this table based on source-IP and backend-IP:backend-port, and maybe even the virtual service IP:port or a pf rule number. Which is what slbd avoids. slbd doesn't use sticky-address for this reason. slbd seems mostly geared for web servers where the web application is written well enough to not need each request to go back to the same server. Kevin
Re: pf load balancing and failover
On 10/22/06, Per-Olov Sjvholm <[EMAIL PROTECTED]> wrote: Hi again I am looking at the CVS. I can't see its possible to out of the box remove addresses from a round robin scheme in PF against a faulty web server. Am I missing something? But I maybe misunderstood Kevin Reay that in this thread said: "and it would automatically remove the address from a pf poll (and optionality run a command) when a host failed.". Maybe I have to do some scripting after all... It can be a little confusing at first, but it makes a lot of sense once you understand it. The way I remember it, a person creates a config file for slbd that defines the various pools and their polling methods, and slbd creates the load balancing pools in pf at start-up automatically (in an anchored ruleset). Then it removes entries from those pools when a server goes down. So... no scripting required. Of course, Bill Marquette will probably have more knowledge/details about this then me... Kevin
Re: pf load balancing and failover
Point of correction, slbd didn't have the ability to ping IP addresses. Good call. You might check the code in CVS, it should compile and work on 3.9. Your right, I didn't notice it was being maintained. Thanks for the pointer, and thanks so much for keeping it maintained (I just noticed you were the one who updated it in CVS). Back to the original question; it looks slbd would be a good and elegant way to achieve what your looking to do. Just grab it from the sourceforge CVS repository. Kevin
Re: pf load balancing and failover
there should be a userland process doing these checks and reoving the offending address from the pool on failure. unfortunately, to my knowledge, still nobody wrote something which does it. A while ago I used this with great success: http://slbd.sourceforge.net/ It's open source (bsd!) and written for OpenBSD and pf. Unfortunately it seems to have become outdated (won't compile on recent versions of OpenBSD) because of the changed pf interface. (updating it probably wouldn't be too much work) It had the ability to query webservers (http), ping ip addresses, and connect to specific tcp ports for heartbeat; and it would automatically remove the address from a pf poll (and optionality run a command) when a host failed. It really would be cool if someone updated it (maybe me if I get some time in the future) Kevin
Re: Spamd - whitelist of mis-behaving SMTP server POOLS
On 10/19/06, Steve Williams <[EMAIL PROTECTED]> wrote: Hi, I have been running spamdb greylisting only for several years as my only line of defense at home. At work I have managed to sneak in a Sparc64 Sunfire 120 (OpenBSD 3.9) as a caching web proxy & default gateway. Today, we had a fairly agressive attack on our email system, 6000+ emails in a relatively short period of time. I took the opportunity to deploy greylisting on the OpenBSD box (which is our first line of defense... first of many). It's performed well, and is up to about 300 email servers whitelisted. I know from personal experience that Bell in Ontario (at the minimum) and a few other ISP's have server pools that do not cooperate nicely with greylisting. They do not guarantee the same server will retry sending the email when it's blocked by spamdb (451 temporary failure). On my computer at home, I notice these entries when I do a spamdb | more and see something like: GREY|205.152.59.48|<[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>|1161299154|1161313554|1161313554|1|0 GREY|205.152.59.51|<[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>|1161296098|1161310498|1161310498|1|0 GREY|205.152.59.65|<[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>|1161300604|1161315004|1161315004|1|0 GREY|205.152.59.66|<[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>|1161302039|1161316439|1161316439|1|0 GREY|205.152.59.67|<[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>|1161294517|1161308917|1161308917|1|0 GREY|205.152.59.68|<[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>|1161292315|1161306715|1161306715|1|0 GREY|205.152.59.72|<[EMAIL PROTECTED]>|<[EMAIL PROTECTED]>|1161297659|1161312059|1161312059|1|0 On my personal email server, it happens VERY seldom. On our work server, it only took a couple of hours for this to show up. It looks like Yahoo might be the same way. I am 99% sure that I have seen on the internet SOMEWHERE a "whitelist" of servers that are like this. I thought Bob Beck had forwarded one at one point in time, but I can only find his post regarding the tarfile he maintains for the "zombie" hosts. Bob, if you are listening, what do you do at the U of A to handle these mis-behaving server pools? Anyone else?? Thanks, Steve Williams As seen on undeadly: http://home.xnet.com/~ansible/openbsd_spamd_conf.html contains a tutorial on setting up spamd on OpenBSD. It is helpful as it shows an example script that creates a whitelist by looking at SPF DNS records in a list of domains. Also, as someone else mentioned, greylisting.org has an excellent whitelist in a CVS repository here: http://cvs.puremagic.com/viewcvs/greylisting/schema/whitelist_ip.txt Kevin