Für Housing-Kunden sowie die Server von Kunden, die wir betreuen, haben wir nun ein eigenes Debian-Repository eingerichtet.

Dieses beinhaltet derzeit Pakete, die in der Debian Stable-Distribution zu alt, oder gar nicht vorhanden sind.

Dazu gehört u.a. das idnkit-Paket, das lediglich als Source verfügbar ist, sowie die 3ware-Pakete von Jonas Genannt.

Auch Pakete für das von uns eingesetzte Zabbix-Monitoring können bequem eingerichtet werden.

Damit Debian sich nicht über “nicht vertrauenswürdige” Pakete beschwert, wurden die Pakete mit gpg signiert, der Key ist dort ebenfalls zum Download verfügbar.

Aus Sicherheitsgründen ist das Repository geschützt, und nur von durch uns freigegebenen Servern aus erreichbar.

Unter folgender URL ist das Repository erreichbar:

http://debian.a1a-server.de/

Dort sind auch die zur Verwendung nötigen Schritte aufgeführt.

Die von uns eingesetzt Version 3.3.2 von Confixx zeigte gestern einige Fehler, die anfangs unerklärlich waren.

Das Hinzufügen von Umlaut-Domains zu einem Kunden-Account war nicht möglich. Confixx entfernte den Umlaut vor der Umwandlung zu Punycode, weshalb der Domain-Name nicht konvertiert wurde. Aus “müller.de” wurde “mller.de”, was natürlich keine IDN-Domain mehr darstellt.

Nach Durchsicht des Quellcodes und einigem Debugging zeigte sich, dass die Umlaute durch die Funktion “escapeshellarg()” entfernt werden.

Nach Beiträgen auf drupal.org bzw. im PHP-Handbuch tritt der Fehler genau dann auf, wenn die verwendete Locale am Server kein UTF-8 kann.

Der Apache wird bei Debian Lenny fix auf “LANG=C” festgesetzt, was genau die Ursache zu sein scheint: mit Debian Etch wurden UTF8-Encodierungen als gültige Zeichen der Shell erkannt, mit Debian Lenny nicht mehr.

Abhilfe schafft der Aufruf von “setlocale()” direkt im PHP-Code, hier in die “idn-functions.php” eingefügt, da nur für IDN-Domains benötigt:

setlocale(LC_ALL, "de_DE.UTF-8");

Nun werden die Umlaute nicht mehr aus dem Domain-Namen entfernt, und die Konvertierung nach Punycode funktioniert.

Liebe Confixx-Entwickler, falls ihr das hier lesen solltet: Es gibt tolle PEAR-Module für IDN-Unterstützung, dann muss nicht extra ein externes Perl-Skript aufgerufen werden, nur um einen Domain-Namen zu konvertieren.

Mit dem Upgrade auf Lenny wurde auch PHP statt in Version 5.2.0 jetzt auf Version 5.2.6 aktualisiert.

Wäre eigentlich kein Problem, wenn nicht – trotz minor Version-Upgrade – die PHP-Entwickler ein relativ zentrales Verhalten geändert hätten.

Bisher war es möglich, Objekte über serialize() in der Datenbank “schlafen” zu legen, und später über unserialize() wieder “aufzuwecken”:

$this = unserialize($data);

Mit PHP 5.2.2 wurde dieser Code komplett zerstört, da auf $this nun nur noch Read-Only zugegriffen werden kann, Schreib-Zugriffe auf das Objekt selbst sind nicht mehr möglich.

Sichtbar wird diese Änderung durch Fehlermeldungen wie:

Cannot re-assign $this in …

Abhilfe? Keine, das Verhalten ist laut PHP-Bugreport erwünscht:

Actually this is expected behavior. We explicitly decided to have $this
being readonly because of interna problems with the new engine.

Sehr geehrte Kunden,

wie bereits in unserem Blog angekündigt, werden wir nach internen Tests alle Hosting-Systeme auf das neue Debian Lenny aktualisieren.

Durch Lenny werden alle Server-Anwendungen wie PHP oder mySQL auf neuere Versionen aktualisiert, sowie weiter Sicherheitsupdates durch die Debian-Distribution bereitgestellt. Unsere Kunden mit Django erhalten die neuere Version Python2.5.

Die Wartungsarbeiten zur Umstellung aller Systeme werden am Sonntag, 15.03.2009, zwischen ca. 20:00 Uhr und ca. 22:00 Uhr stattfinden.

In dieser Zeit muss mit kurzzeitigen Störungen der Web-, Mail- und Datenbankserver gerechnet werden.

Aktuelle Hinweise finden Sie wie immer auf unserer Serverstatus-Übersicht:

http://serverstatus.aditsystems.de/

Gerade beim Upgrade des Dell-Servers eines Kunden auf Debian Lenny auf größere Probleme gestoßen:

im Server verbaut sind gesamt vier Netzwerkkarten, davon zwei mit Intel e1000-Chipsatz, sowie zwei Broadcom NetXtreme II.

Verbunden sind die zwei Broadcom-Netzwerkkarten zum Einen mit dem Internet / restlichen Netzwerk, und zum Anderen mit dem Netzwerk zum Backup-Server, die zwei Intel-Netzwerkkarten sind ungenutzt.

Die Intel-Netzwerkkarten machen grundsätzlich keine Probleme, diese wurden problemlos erkannt.

Die Broadcom-Karten zwar auch, aber die Netzwerk-Devices konnten nicht initialisiert werden: Die Firmware für die Broadcom-Karte fehlte.

Wäre normalerweise, sprich in unserer regulären Umgebung, ja kein Problem: Rescue-System des Rechenzentrums booten, Firmware innerhalb des chroot nachinstallieren, Problem gelöst.

Bei HostEurope geht das ganze nicht so einfach: Hier gibts kein Rescue – lediglich einen “Serverrepairmodus”, und der ist Beta, lies: “funktioniert nicht” (zumindest nicht bei diesem Server).

Glücklicherweise gibts da noch ne DRAC5-Karte mit KVM-Möglichkeiten. Nach dem fast schon obligatorischen “racadm dracreset” funktionierte dann auch der Zugriff im Browser.

Nur: wie kann man ohne Netzwerk-Zugriff Daten nachinstallieren? Oh, toll: die DRAC bietet einen “virtuellen Datenträger” an – der jedoch wegen einer etwas komischen Fehlermeldung nicht nutzbar ist, fällt also auch weg.

Nicht zu vergessen sind außerdem die Fehlerquellen, die durch udev und die Zuordnung der NIC via MAC-Adresse zum Netzwerk-Device entstehen …

Letztendlich war der Netzwerk-Zugriff erst wieder möglich, nachdem der alte 2.6.18er Kernel aus Etch gebootet wurde. Nun wurde noch “firmware-bnx2″ nachinstalliert, dem Kernel über “update-initramfs -k all -u” beigebracht, ein beherzter Reboot – und der Server lief wieder.

Da Debian Lenny bereits seit längerem Stable ist, und die Tests intern problemlos verliefen, beginnen wir derzeit mit dem Upgrade aller eigenen und der durch uns betreuten Hosting-Systeme.

Probleme gab es bisher wenige, auf überschriebene Config-Dateien oder ähnliches waren wir dank der Tests bereits vorbereitet, so dass die Änderungen sofort wieder zurückgenommen werden konnten.

Lediglich Confixx zickte etwas: Das Update-Script, das Änderungen im Webinterface effektiv in das System überträgt, basiert auf einem verschlüsseltem Perl-Code. Das Filter-Modul, um das Skript aufrufen zu können, machte jedoch in der von uns eingesetzten Confixx-Version 3.3.2 Probleme. Die Installation des Moduls aus Confixx 3.3.4 brachte Abhilfe.

Auf einem Kunden-System kam es zu komplett unerwarteten Problemen: Debian Lenny bringt keine Unterstützung für Apache1 und – hier Grund gewesen – PHP4 mit. Da der Server bereits seit längerem läuft, und der Kunde die Hosting-Accounts nur zögerlich auf PHP5 migriert hat, musste schnell Abhilfe geschaffen werden. Der Versuch, das vorhandene PHP4-Paket aus Etch neu für Lenny zu übersetzen, scheiterte. In Rücksprache mit dem Kunden haben wir dann den gesamten Server auf PHP5 umgestellt, die Sicht-Überprüfung der Webseiten zeigte keine Fehler. Bisher kam es auch zu keinen Beschwerden.

Wann unsere Hosting-Systeme Mars und Venus migriert werden, steht noch nicht fest – wir werden alle Kunden aber in einer Rundmail über die Wartungsarbeiten informieren.

Seit dem 14. Februar 2009 (Valentinstag – Zufall?) ist Debian in Version 5.0 (Codename “Lenny”) stabil.

Was gibt es neues?

Für uns – wenig: neuere Versionen von Apache, PHP, MySQL, dabei aber keine großen Versionssprünge. Lediglich mit XEN 3.2 gibt es größere Neuerungen (Virtualisierung von Windows ist nun direkt möglich).

Die Umstellung lief auf dem Test-System relativ problemlos, wenn man von Konfigurations-Problemen mit Postfix und Freeradius absieht – hier war Handarbeit notwendig.

Wichtig ist auch die Reihenfolge des Upgrades: Während bei Etch nach dem Anpassen der sources.list ein “aptitude update && aptitude upgrade && aptitude dist-upgrade” reichte, sollte man beim Wechsel auf Lenny etwas anders vorgehen (siehe MDlog/sysadmin):

1. Anpassen der sources.list:

   sed -i 's/etch/lenny/g' /etc/apt/sources.list

2. Update der Paketlisten:

   aptitude update

3. Upgrade der Paketverwaltungs-Programme auf Lenny:

   aptitude install apt dpkg aptitude

4. Nun das Upgrade von etch nach Lenny:

   aptitude full-upgrade

Wird der 3. Schritt nicht durchgeführt, versucht aptitude von Etch, die Abhängigkeiten zu lösen – und scheitert daran.

Statt “dist-upgrade” wird nun “full-upgrade” verwendet, was der Funktionalität aber keinen Abbruch tut.