Blogs

Nachdem Squeeze vor ein paar Tagen freigegeben wurde, tut sich auch etwas an der Updatefront. Eins der Probleme mit Debian, war das gewisse Pakete einfach nicht schnell genug aktualisiert wurden. Der Virenscanner ClamAV ist ein gutes Beispiel. Deshalb wurde vor einiger Zeit das Repository Volatile ins Leben gerufen. In diesem wurde ein kleiner Teil der Debian Pakete sehr zügig aktualisiert. Das hat den Einsatz von Debian an vielen Stellen einfacher und besser gemacht. Die Leute hinter Debian haben Volatile auch als Erfolg gewertet und gehen nun einen Schritt weiter:

Zitat: "The Debian Volatile archive is discontinued starting from the upcoming Debian release 6.0 (Squeeze). It is replaced by the suite squeeze-updates on the official mirrors. Its management will move to the Debian Release Team, who already manage regular updates to Debian stable and oldstable."

Der Name wird offizieller und das Team "dahinter" ist nun auch gleich wie das für die normalen Updates. Ein Schritt in die richtige Richtung! Debian ist sehr groß, da ist es schon verständlich, dass nicht jedes Paket auf den super aktuellen Stand gehalten werden kann. Sich auf ein gewisses Subset aus dem ganzen Pool zu beschränken und diese Pakte zu pflegen ist ein guter Ansatz.

Mehr Infos gibt es hier.

 Genauer gesagt, ist es schon ein paar Tage "draußen". Die erste paar Server sind bereits aktualisiert.
Nachdem Debian das ganze konservativ angeht, sprich relativ alter Kernel, alter gcc und div. andere,
bereits leicht angestaubte Pakete, gehe ich davon aus, dass Squeeze sehr stabil läuft.
Die umgestellten Server tun dies auch schon seit ein paar Tagen, also außer der Aufwand,
der fürs Update notwendig wird, gibt es nichts zu befürchten.

Bis jetzt hatte ich auch noch keinen größeren Aufwand mit einem Update.
Es kommt schon mal vor, dass Pakte kollidieren, aber bei unseren LAMP / Datenbank / Cluster Servern lief alles glatt .

Ich wünsche den ganzen Admins da draußen auch soviel Glück und ein reibungsloses Update auf Squeeze!

 Lange hat es gedauert, aber endlich ist es soweit: Oracle / MySQL AB haben Version 5.5 zur finalen Version erklärt.

Das ist das erste stabile Release, seit der Übernahme von MySQL AB durch Oracle, wir sind gespannt! Wie mit fast jeder Version,
wird uns von Oracle/MySQL AB nahe gelegt, dass sich die Performance gesteigert hat und natürlich viele Bugs behoben worden sind.
Unsere Erfahrung hat gezeigt, dass beides zwar richtig ist, aber Performancesteigerung sich oft auf "Corner Cases" bezieht,
das Beheben von Bugs wieder neue mit sich bringt und der große erhoffte Schritt vorwärts doch nicht so groß ist.

Mit 5.5 haben sich aber grundlegende Dinge geändert, z.B. ist die Standard Storage Engine nicht mehr MyISAM, sondern innodb. Im selben Zuge,
hat Oracle bekannt gegeben, dass innodb durch diverse Anpassungen nun schneller geworden ist, und darum zur Standard Engine wurde.
Nachdem wir MySQL 5.5 in einer Testumgebung  bereits seit der Betaphase ausführlich prüfen, können wir das insofern bestätigen. Ob innodb aber nun in jedem Fall schneller ist als MyISAM ist zu bezweifeln. Was allerdings außer frage steht: innodb ist die robustere und erwachsenere Storage Engine. Mit den vielen Änderungen ist innodb nun in der Lage Mehrkernsystem besser auszunutzen und wird dadurch auf modernen Servern schneller.

Was noch geändert wurde, ist die Replikation. Vorher war diese nur asychron möglich, mit Version 5.5 gibt es nun die Möglichkeit diese semi-synchron durchzuführen. Das ist einfacher erklärt, als man denkt: früher hat der MySQL Daemon auf dem Master Server einen Bin Log geführt und diesen an die Slaves, auf Anfrage selbiger, verteilt. Der Master Server hat nie eine Nachricht erhalten, ob der Slave nun synchron läuft ist, oder nicht. Das ist nun anders: Slaves die MySQL 5.5 benutzen, bzw. generell den semi-synchronen Mechanismus unterstützen, können den Master zurück melden, ob sie alle Daten repliziert haben, oder nicht. Dies ist nun interessant, da man Transaktionen auf dem Master Server so setzen kann, dass die erst als erfolgreich abgeschlossen sind, wenn die/einer der Slaves diese auch repliziert haben. Auf diesem Weg, hat man also Gewissheit, dass die Daten auf dem Master und auf dem Slave gespeichert / verändert bzw. gelöscht wurden.
Dieses neue Feature ist besonders interessant für Applikationen die Master - Master Replikation nicht unterstützen. Man behilft sich in dem Fall mit einem Master - Slave Failover, aber früher war nie gesichert, dass der Slave auch wirklich synchron läuft. Man konnte den Status zwar überwachen, aber mit dem neuen System ist man auf der besseren Seite.

Mehr Informationen zur Replikation in 5.5 gibt es hier.

Mehr Informationen zu den Neuerungen in MySQL 5.5 gibt es hier.

 Werte Leser,

endlich ein guter Grund diesen Blog ins Leben zu rufen: in exim4 versteckt sich eine Lücke,
die sich ausnutzen lässt, eine Shell zu erstellen. Auf diese Shell kann sich ein Angreifer einloggen und in weiterer Folge ggf. sogar root Rechte auf dem Server bekommen. Die gerade entdeckte Lücke lässt sich von der Ferne ausnützen, daher ist diese besonders heikel.
Die von Debian (Lenny und Squeez) mitgelieferte Version von exim4 ist offensichtlich auch betroffen.

Also temporäre Lösung kann folgendes gemacht werden:
mount --bind /var/spool/exim4 /var/spool/exim4
mount -oremount,noexec /var/spool/exim4
 
Oder man stellt sicher, dass sich niemand von extern auf exim4 ( Port 25 ) verbinden kann. Entweder per iptables oder einer Hardware Firewall.

Weitere Details zu dem Thema sind hier zu finden.