Fladi.at

Photo by Mr. 0Almost a month ago I moved my whole server infrastructure to the German hoster Hetzner. The former uni.fladi.at physical host has been replaced with a dedicated server located in their data center. The new hardware is more than 4 time more powerful than the old one an is now accompanied by a dynamic cloud computing back-end infrastructure which takes care of offloading backup&restore to Amazon S3 and computing tasks to Amazon EC2. The new host now resides at root.fladi.at (with a CNAME for uni.fladi.at).

For me the most interesting new feature provided by Hetzner is their ability to route native IPv6 subnets directly to my infrastructure. At the moment I’ve been assigned two /64 subnets where one is used for connecting the front-end host to the IPv6 Internet and the other is routed further into my VPN network to provide mobile hosts (like laptops and smartphones) with IPv6 connectivity. Thanks to the guys & girls at the Hetzner NOC for providing the second /64 subnet for free

All in all I’m looking forward to a big improvement in availability and performance throughout all the Fladi.at services. Oh and Subversion repository hosting is bound to expire due to the slowly advancing migration to Git.

Vor einigen Monaten wurde bei meinem Arbeitgeber eine Weboberfläche zur Administration von Nagios3 installiert. Der Hersteller dieser Webanwendung will nicht genannt werden. Das Produkt trägt einen Namen der nicht genannt werden darf

Zur Funktionalität will ich nicht viel sagen, da ich nicht dem Zielpublikum einer solchen Anwendung gehöre. Ich bevorzuge die CLI.

Jedoch kam es heute auf unserem Server, der die Webanwendung namenlosenFirma hostet, zu Problemen bei der Performance. Der MySQL-Server rotierte bei 100% CPU-Last und ich wollte mich auf die Suche nach der Ursache für dieses Verhalten machen. Sehr bald war ein PHP-Skript als Verursacher ausgemacht, welches als Daemon lief und massiv auf dem MySQL-Dienst zugriff. Als nächstes erfolgt natürlich der blick in das PHP-Skript und was muss ich da entdecken? Das gesamte Skript besteht aus diesem Inhalt:

sg_load(’47FCD54C293AADB0AAQAAAAQAAAABI…….AAAAAA’);

Wer das nicht kennt: Das ist Quellcode-Verschleierung durch SourceGuardian. Jetzt stehe ich vor einem zentral wichtigen System, das die gesamte Überwachung der Infrastruktur meines Arbeitgebers inne hat und kann keine Fehlersuche betreiben. Was vielleicht aber noch schlimmer wiegt:

Hier läuft Code auf einem System, welches umfassende Zugriffsberechtigungen auf die gesamte Infrastruktur hat, von dem ich nicht weiß, was er macht oder welchen Zweck er erfüllt.

Liebe unbekannte Firma, das ist nicht professionell!
Update: Die betroffene Firma hat bei meinem ehemaligen Arbeitgeber Beschwerde wegen diesem Beitrag eingelegt und will nicht namentlich erwähnt werden. Deshalb die Abänderung des Beitrags zu anonymen Bezeichnungen.  Das Verhalten finde ich jetzt im Kontext der Professionalität als noch tieferen Abstieg, da die Lösung in diesem Fall relativ einfach wäre: SourceGuardian nicht benutzen. Immerhin habe ich auch noch am Rande erfahren, dass die besagte Firma daran gescheitert ist, ihre Software auf Asterisk 1.8 zu portieren

While working on Debian packages for the Mozilla Sync Server, I came across the task to provide a URL for uscan to identify new releases. Mozilla does only provide Mercurial tags for each new release in their repository. To be able to use those tags as pointers to the tarballs of the new releases I set up a simple redirector for sites like hg.mozilla.org.

It can be found at http://debian.fladi.at/hgredir and should be used like in this example for the repository at http://hg.mozilla.org/services/server-reg/:

http://debian.fladi.at/hgredir/hg.mozilla.org/services/server-reg/

The accompanying debian/watch file would look like this:

version=3
opts=filenamemangle=s/.*\/rpm-([\d\.]+)-\d+\.tar\.bz2/mozilla-syncreg-$1\.tar\.bz2/ \
http://debian.fladi.at/hgredir/hg.mozilla.org/services/server-reg/ \

http://hg.mozilla.org/services/server-reg/archive/rpm-([\d\.]+)-\d+\.tar\.bz2

Maybe this redirector could be useful to others so I will maintain it as an freely available service.

A  while ago I migrated my /home LVM volume to the new (experimental) btrfs in order to take advantage of snapshots for backup. Despite my overall satisfaction with btrfs in terms of usability and features, it turned out that there is one major issue with applications making excessive use of fsync(3). The symptom of this issue is a high latency to user-actions while data is being written to disk. The impact on my system was especially high with liferea, my news feed reader. It was completely unusable while fetching data or marking a batch of items as read.

After some investigation I found eatmydata, which basically replaces all calls to fsync(3) with it’s own implementation, which just returns without doing anything. On Debian, it can be installed directly from the archives:

aptitude install eatmydata

It offers a small binary which can be used to bootstrap other applications to use the variant of fsync(3) provided by eatmydata instead of glibc. This is how I use it right now to start liferea:

eatmydata -- liferea

There are of course drawbacks and risks of using eatmydata. The purpose of fsync(3) is to ensure that data is safley written to a disk before going on with the work-flow inside an application. Effectively discarding those calls to fsync(3) exposes an application to potential data-loss! As liferea does not handle data for which I depend on integrity, I can cope with the risk of losing it but I would never ever use it on critical applications!

What a great day it was. World IPv6 day happened on 8th of June 2011 and I was able to reach a lot of websites with IPv6 without any troubles. That made this day also a going test run for my own IPv6 deployment. Native IPv6 at home and a HE tunnel at work allowed me to use Google & Youtube over IPv6 without tinkering with DNS resolution.

Sadly, most of the participants decided to disable their AAAA-Records in DNS after the day was over, so it’s back to DNS-hacking or using IPv4 for those who do not have the balls to enable IPv6 in a dual-stack way permanently. Maybe we can have an IPv6 day soon