Filoo

Nach 5 Jahren der webmäßigen Dürre haben wir endlich die Webseiten der Filoo GmbH neu gelaunched. Jetzt auch mit richtigen Inhalten. Wir haben auch einen Twitter-Account für die Filoo GmbH angelegt, mit dem wir unsere Kunden und Freunde über Neuigkeiten bei Filoo auf dem Laufenden halten wollen.

Außerdem habe ich gestern mit der prima Software phpMyFAQ (ja, Thorsten - endlich nutze ich Deine Software mal produktiv, hoffentlich sind alle Securitybugs beseitigt )  eine FAQ für alle Produkte der Filoo GmbH aufgesetzt: Filoo-FAQ.

Die Inhalte sind natürlich noch nicht alle da, aber das wird sukzessive in den nächsten Wochen von unserem Team erledigt. Stay tuned.

Unser Hosting-Kunde aka-aki hat ein Spiel angekündigt. Location-based, social, “weather aware”, klingt auf jeden Fall hochspannend. Präsentiert wird das Ganze am 17.12. in Berlin.

If you are trying to run an OpenVPN server on a machine with multiple virtual interfaces bound to the physical interface that binds the OpenVPN server, you should always use the local 1.2.3.4 (with 1.2.3.4 being the IP you want to use for OpenVPN) keyword in the OpenVPN server configuration file.

Otherwise, the packets that arrive on 1.2.3.4 are returned through another virtual interface (I think the one with the highest ifIndex, although I can’t verify that in my current setup).

Typical symptoms are these:

• TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)


•  Initial packet from 1.2.3.4:1194, sid=c912ec05 45db03c6 but no packet returned from server to client

I have a little story from an administrator’s life for you today.

Today at around 1pm CEST, our mail cluster started behaving very odd. Although SMTP ports were open, establishing a connection to the initial server greeting took around 30 seconds on each of the 8 nodes.

Long delays normally indicate DNS problems, so I checked if the resolvers were b0rked. Both were working fine and DNS lookups on the command line on each of the mail servers were blazing fast. Ho-humm... stracing the qmail-smtpd processes showed that my assumption was correct - the delays were definitely caused by DNS lookups to our resolverss being slow. Just to be on the safe side and to rule out firewall or routing issues between our networks, I used the OpenDNS resolvers on one node - nothing changed.

My next guess was: Maybe a RBL shut down?! We are only filtering against XBL and the iX blacklist and both were up - I tried anyway. Still, SMTP was slow on every mail server.

We are using qmail with rblsmtpd, so I could quickly disable the rblsmtpd service altogether. Suddenly, the connection speed was up to past standards again. So it had to do with rblsmtpd, but with none of the RBLs it is filtering against. Weird.

I went to the resolvers and checked which queries were actually performed during a smtp connection initiation - and to my astonishment, I saw that queries to resolve 1.2.3.4.rbl.maps.vix.com were used during each connection initiation. I googled a bit and read that the long defunct MAPS RBL was the fallback blacklist that was used by rblsmtpd when no other RBLs were specified in the configuration.
However, I had two blacklists in the config - yet rblsmtpd tried to look up at the MAPS RBL, too.

It seems someone disabled the nameservers for the vix.com zone, so I took the liberty of telling my resolvers to serve it to all clients - empty, of course. Now, everything is back to normal. It cost me about two hours to solve that problem.

We recently got a couple interesting new customers:

First, there is Nimble, an irish-swedish (interesting mix) local community / social networking site that moved to our infrastructure recently. They are a fast-growing community in Ireland and recently launched their site in Sweden, so be sure to stop by them if you are into social networking.

Then there’s aka-aki, who -- overwhelmed by their social networking app’s success in the Apple Store -- installed a number of machines on our site to ease the load on their main server farm.

I wish both projects lots of success and: We’re happy to have you!

Ich werde dieses Jahr - auf Einladung des Heise Verlags - auf der “Open Source Meets Business” (kurz OSMB) 2009 einen Workshop zum Thema Rechenzentrums-Management moderieren. Dieser Workshop wird sich mit folgenden Themen befassen:

• Green IT


• Virtualisierung


• Open Source in RZs


• Cloud Computing

Was erstmal nach einer wirren Stichwortsammlung klingt, wird sicher zu einer interessanten Veranstaltung, da alle diese Themen - wenn man mal darüber nachdenkt - ineinander greifen.
Um die Diskussion mit dem hoffentlich zahlreich anwesenden Publikum zu vertiefen, habe ich einige Kollegen aus dem RZ-Geschäft an meiner Seite, u.a. von der Firma Netways und der Thomas-Krenn.AG.

Mein Workshop wird am Mittwoch, dem 28.01. stattfinden - übrigens ist die OSMB neben dem unvermeidlichen Networking auch eine gute Gelegenheit, endlich die LPI-Zertifizierungen zu machen.

Bis dahin!

In einigen unserer Gameserver sind RAID-Volumes defekt, sie werden daher jetzt heruntergefahren, ausgebaut und mit neuen Platten versehen.

Nach einer viel zu kurzen Nacht im HOtel sitzen wir bereits wieder an den Rechnern und durften erstmal einen kleinen dDoS abschalten. Unsichere Includes gibts tatsächlich immer noch zuhauf... *seufz*.

Als nächstes auf der Agenda: phpMyAdmin für den neuen DB-Server sowie diverseste Rechner-Wiederbelebungen.

Der Datenbankserver ist erfolgreich auf eine deutlich schnellere Maschine migriert worden und läuft (bis auf einige Filoo-interne Services) wieder.

Nun wird in zweien der Racks diverser Kabelverhau und unverschraubte Server aufgeräumt, was u.U. zu Connectivity-Verlust im Minutenbereich führen kann.

So. Die neuen Rechner (24 an der Zahl) sind fertig, und jetzt kopiert gerade der neue Datenbankserver seine Datenbanken vom alten runter. Dummerweise muß, damit die Kopie nicht outdated ist, sobald sie angefertigt wurde, dafür der Datenbankserver down gehen - was gerade eben passiert ist.

Das Ganze sollte in Kürze behoben sein.

So. Bißchen zu spät aufgestanden, jetzt nix wie ab zum Bahnhof.

Zum ersten Mal werde ich von einem Deployment in unserem Rechenzentrum in Frankfurt “live” berichten, mit etwas Glück sogar ein paar Fotos online stellen.

Vorab: Für einen Kunden sollen wir morgen etwa 30 Maschinen einbauen, installieren und (hinter einer Firewall) online bringen. Eine derart große Einbauaktion dauert typischerweise über 16 Stunden und geht eigentlich nie gut.

Nebenbei werden noch die üblichen Jahresend-Aufgaben erledigt, wie die korrekte Beschriftung und Verkabelung von Servern, die vom NOC-Personal aufgebaut wurden und noch nicht in unseren Datenbanken stehen, Auf- und Umrüstung und ein ganzer Stapel Festplatten, die defekte Geräte wiederbeleben sollen.

Ich werde jetzt mal meine Mütze Schlaf nehmen, bis morgen in diesem Theater.