rubyworks is a full rails stack put together also by thoughtworks. this time it’s all open source. it features haproxy (supposed to be much faster and light weight than apache_mod_balancer) as load balancer, mongrel as application server, monit and runit for monitoring and controlling mongrel, mysql/postgrs/oracle ruby bindings for database connectivity and also bindings for ferret, libxml, hpricot and rmagick.

everything is nicely packaged as rpms and debian packages so it can easily be installed within 5 minutes (it really works). even better, the packages at the same time pretend to be ruby gems, so you can safely install other debian packages *and* gems that depend on one of the libraries provided by rubyworks.

now we had already set up a cluster of 6 servers for autoki with everything set up more or less perfectly so why would we need rubyworks? answer: to steal the config files for runit/monit and haproxy. our mongrel setup has always been a bit shaky, especially when it came to restarting the mongrels after a deployment. after using the rubyworks setup with runit now everything is stable. (btw runit can run and supervise any process in *nix and is ready to be the successor of the old init which is used by most linux distros to start up all the processes. one advantage is that it starts all processes at once instead of piece by piece, plus runit handles putting a process in the background and keeping it alive there, something mongrel is especially bad at).

Eigentlich hatte ich mich schon damit abgefunden: zuletzt erreichten mich taeglich ca. 150 Spam-Emails pro Tag, in denen mir die bekannten Aktienpakete, Pillen und anderen Schätze versprochen wurden. Neulich musste ich dann für einen Kunden ein paar Emailaccounts bei webmail.us (Email-Provider) einrichten. Also schnell Adressen eingetragen und noch kurz eine Testmail versandt und … kam nicht an. Also mal kurz ins Logfile des eigenen Mailserver geschaut und siehe da: temporarily rejected RCPT … greylisted (see http://en.wikipedia.org/wiki/Greylisting).

Greylisted? Black lists, white lists, klar. Aber grau? Schnell nachgesehen und herausgefunden: method of defending electronic mail users against e-mail spam. A mail transfer agent which uses greylisting will “temporarily reject” any email from a sender it does not recognize. If the mail is legitimate, the originating server will try again to send it later, at which time the destination will accept it. If the mail is from a spammer, it will probably not be retried - coole sache, nur … Mailserver umkonfigurieren? Au weia. ich bin froh, dass der überhaupt funktioniert. Glücklicherweise gibt’s für Exim auf Debian ein Paket namens greylistd. Einfach apt-get install greylistd und anschließend ein greylistd-setup-exim4 add und voila - greylisting a la Debian. Und das beste, ich habe in den letzten zweit Tagen tatsächlich nur eine einzige (!) Spam-Email erhalten.

Wenn mir jetzt noch jemand erklärt, wie ich diese Zeitverzögerung beim senden von Emails von dynamisch verteilten IP-Adressen aus wegbekomme….