Kritische Sicherheitslücke in vielen Plesk-Versionen

In den Versionen 7.6.1 bis 10.3.1 der Server-Verwaltungsoberfläche Plesk Panel von Parallels wurde eine schwerwiegende Sicherheitslücke entdeckt, die es einem Angreifer erlaubt ein System zu kompromittieren.

Parallels hat dazu einen Knowledge Base-Artikel erstellt, der beschreibt wie man die Lücke schließt: http://kb.parallels.com/en/113321.

Supported page size in this release is=16384

Ein Bug in den MySQL Server Versionen ab 5.5.20 (die von mir getestete Version 5.5.21 war ebenfalls betroffen) sorgt dafür, dass der Datenbank-Server nach einem Update eventuell nicht mehr gestartet werden kann.

Im Log findet sich dann folgende Fehlermeldung:

120223 20:03:12 InnoDB: Error: data file /var/lib/mysql/ibdata2 uses page size 1024,
120223 20:03:12 InnoDB: but the only supported page size in this release is=16384

Ein Bugfix von offizieller Seite existiert leider noch nicht. 5.5.19 ist die letzte Version, in der dieser Fehler noch nicht zu finden ist. Mittlerweile existiert auch ein Patch von Oracle.

Mehr zu diesem Problem gibt es im MySQL Bugtracker: #64160.

Query caused different errors on master and slave…

Was tun, wenn die MySQL Replikation mit folgendem Fehler abbricht:

Last_Error: Query caused different errors on master and slave. Error on master: ‘Deadlock found when trying to get lock; try restarting transaction’ (1213), Error on slave: ‘no error’ (0).

Man überprüft auf dem Master und Slave die durch das Query betroffenen Tabellen auf Fehler hin (z.B. mit check table), meistens sollte hier noch alles in Ordnung sein. Falls nicht, müssen diese vorher gefixt werden. (z.B. repair table, Backup oder binlog).

Anschließend kann mit folgenden Befehlen auf dem Slave die Replikation wieder angestoßen werden:

mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = 1;
mysql> START SLAVE;

Die Replikation sollte wieder laufen, es kann jedoch durchaus ein wenig dauern bis Master und Slave wieder auf dem gleichen Datenbestand sind.