Plesk scheint es nicht so mit den Cronjobs für den sa-update zu haben

Ich habe dieser Tage für einen Kunden einen frischen Server mit Debian 6 (squeeze) und dem aktuellen Plesk 10.4.4 aufgesetzt, der laut Kundenaussage auch bisher wunderbar läuft. Nur meldet sich der tägliche “sa-update” Cronjob jeden Morgen mit einer Fehlermeldung, die da lautet:

/etc/cron.daily/60sa-update:
[: 9: 1: unexpected operator
[: 14: 1: unexpected operator
run-parts: /etc/cron.daily/60sa-update exited with return code 1

Die hier früher schonmal beschriebenen Fehler dieses Cronjobs hatte ich seinerzeit an Parallels gemeldet, woraufhin die natürlich nicht meinen "quick and dirty" Hack übernommen haben, sondern das Script wie folgt umgeschrieben haben:

#!/bin/sh

/usr/bin/sa-update
ERR=$?

# Only restart spamd if sa-update returns 0, meaning it updated the rules
if [ $ERR == 0 ]; then
/etc/init.d/psa-spamassassin restart | tee -a /var/log/sa-update.log;
fi

# if sa-update returns 1 when there are no updates
if [ $ERR == 1 ]; then
exit 0;
fi

exit $ERR

Naja, auch nicht unbedingt “schön” aber es funktionierte… bis jetzt.

Das Problem bei der Verwendung unter Debian Squeeze ist, dass “/bin/sh” mittlerweile ein Symlink auf “dash, und nicht mehr auf “bash”, ist. Die dash-Shell kennt den hier verwendeten “==” Befehl zum vergleichen von Strings nicht und gibt deshalb einen Fehler aus.
Möglichkeiten zur Abhilfe gibt es (wie immer unter Linux ) einige; ich habe beim Kunden das “==” durch “=” im Script ersetzt, also:

#!/bin/sh

/usr/bin/sa-update
ERR=$?

# Only restart spamd if sa-update returns 0, meaning it updated the rules
if [ $ERR = 0 ]; then
/etc/init.d/psa-spamassassin restart | tee -a /var/log/sa-update.log;
fi

# if sa-update returns 1 when there are no updates
if [ $ERR = 1 ]; then
exit 0;
fi

exit $ERR

Alternativ könnte man das Script natürlich auch durch die bash ausführen lassen, also “#!/bin/sh” in “#!/bin/bash” in der ersten Zeile des Scripts ändern.

Das “==” könnte man auch durch “-eq” ersetzen, was genau genommen aber nicht so sauber ist, da hier Strings und keine Integer verglichen werden…

Den Symlink auf dash zu löschen und einen neuen auf die bash (wie unter Debian 5 Lenny) anzulegen würde wohl auch funktionieren, könnte aber u.U. ungewollte “Nebenwirkungen” haben, weshalb davon abzuraten ist.

Rund 100.000 Mal in der Sekunde wird von irgendwo in der Welt eine Internetadresse mit .de am Ende aufgerufen. Mehr als 14,6 Millionen gibt es davon inzwischen und täglich kommen rund 3.000 neue hinzu. Größenordnungen, die selbst die Vorstellungskraft der visionärsten Internetpioniere übertreffen und die gesellschaftlichen und wirtschaftlichen Kommunikationsgewohnheiten in nur einem Vierteljahrhundert grundlegend verändert haben.

Es begann alles am 5. November 1986. An diesem Tag wurde das Länderkürzel .de in die offizielle Liste der IANA (Internet Assigned Numbers Authority) aufgenommen und damit erstmals Domains mit der deutschen Länderkennung zugelassen. Chronologisch gesehen war die Bundesrepublik Deutschland somit als zehnter Staat im Internet vertreten. Infolge der deutschen Wiedervereinigung im Jahre 1990 nie genutzt wurde das ursprünglich für die DDR reservierte Länderkürzel .dd.

Dank der stabilen Infrastruktur und den vergleichsweise liberalen Registrierungsbedingungen in (West )Deutschland konnte .de sich schon früh an die Spitze der Länderdomains (ccTLDs) setzen und hat mit aktuell mehr als 14,6 Millionen Registrierungen weiterhin eindeutig die Nase vorn, gefolgt von Großbritannien (.uk) mit derzeit rund 9,7 Millionen und den Niederlanden (.nl) mit 4,7 Millionen registrierten Domains. Allein die generische TLD .com übertrifft .de mit einem Domainbestand von zurzeit knapp 97,6 Millionen. 25 Jahre nach der Einführung des Länderkürzels entfallen auf 1.000 Bundesbürger im Durchschnitt 178 .de-Domains. Rein rechnerisch hat somit jeder Sechste seinen eigenen Internetauftritt. Auch faktisch sind heute nahezu 80 Prozent aller Domaininhaber unter .de Privatpersonen.
Weiterlesen… »

Heute ist bei einer Konfiguration einer MySQL Master-Slave Replikation ein merkwürdiger Fehler aufgetreten, dessen Lösung ich erst nach langem Suchen im Internet gefunden habe. Damit es andere vielleicht schneller finden, möchte ich ihn hier beschreiben. Und weil es so schön dazu passt, noch ein kleines Mini-Tutorial, wie man eine einfache Master-Slave Replikation unter MySQL aufsetzt.

Sinn und Zweck ist, dass am Ende die Datenbank auf dem Slave eine identische Kopie der Master-Datenbank ist. Dies kann u.a. zu Sicherungszwecken nützlich sein.

Die Master-DB vorbereiten für die Replikation

In die Datei /etc/mysql/my.cnf (Sektion mysqld) wird ergänzt:

server_id = 1
log_bin = /var/log/mysql/mysql-bin.log
log_bin_index = /var/log/mysql/mysql-bin.log.index
relay_log = /var/log/mysql/mysql-relay-bin
relay_log_index = /var/log/mysql/mysql-relay-bin.index
expire_logs_days = 10
max_binlog_size = 100M
log_slave_updates = 1

Danach den Benutzer für die Replikation erstellen:

mysql> GRANT REPLICATION SLAVE ON *.* TO ‘replication’@'<slave-server-ip>’ IDENTIFIED BY ‘<super kennwort>’;
Query OK, 0 rows affected (0.02 sec)

Damit die neuen Werte übernommen werden, einmal MySQL neu starten.

Kopieren der Daten auf den Slave-Server

Damit nachher auf beiden Servern zum Start der Replikation identische Datenbanken vorliegen, müssen wir feststellen, an welcher Stelle wir aktuell schreiben. Dazu halten wir erst alle Datenbankvorgänge an.

mysql> FLUSH TABLES WITH READ LOCK;
Query OK, 0 rows affected (0.04 sec)

Am Besten stoppt man auch kurz die Prozesse, die auf die Datenbank zugreifen möchten (vor allem Schreibende). Dann geht es an das Kopieren und merken des korrekten Replikationsstarts:

mysql> SHOW MASTER STATUS;
+——————+———-+————–+——————+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+——————+———-+————–+——————+
| mysql-bin.000001 | 8741 | |
|+——————+———-+————–+——————+
1 row in set (0.00 sec)

Achtung: Diese MySQL-Shell nicht zumachen, da sonst der Lock entfernt wird! Auf einer neuen Ebene die Daten exportieren:

#mysqldump -u root -p –all-databases > /tmp/database-backup.sql

Dann den Dump kopieren:

# scp /tmp/database-backup.sql <slave server>:~database-backup.sql
52% 3096MB 8.7MB/s 05:24 ETA

und einspielen:

root@<slave server>:~# mysql -u root -p < database-backup.sql

Bei Debian muß auch die /etc/mysql/debiError_code: 1045an.cnf angepasst werden, da wir die komplette mysql-user Tabelle auch kopieren. Danach MySQL neustarten oder flush privileges. Wir können nun die Datenbanken auf dem Master Server wieder frei geben:

mysql> UNLOCK TABLES;
Query OK, 0 rows affected (0.00 sec)

Synchronisation einrichten

Es liegen beide Datenbanken identisch vor ab einem gesetzten Zeitpunkt. Um die Replikation zu starten, führen wir auf dem Slave aus:

mysql> CHANGE MASTER TO master_host=’<MASTER HOST>’, master_port=3306, master_user=’replication’,
master_password=’<KENNWORT VOM REPLICATION USER>’, master_log_file=’mysql-bin.000001′, master_log_pos=8741;
Query OK, 0 rows affected (0.07 sec)

Die entsprechenden Werte für die Position und dem Logfile entnehmen wir dem weiter oben auf dem Master ausgeführtem Kommando. Die eigentliche Replikation starten wir nun mit

mysql> START SLAVE;

Den Status kann man mit einem”Show Slave Status” einsehen. Ist alles gut gegangen, baut der Slave eine Verbindung zum Master auf und wartet auf Änderungen, die vom Master gesendet werden.

Der Fehler

Erst beim Status erhielt ich einen Fehler:

[ERROR] Slave I/O: error connecting to master [....] Error_code: 1045

Die Lösung:

Das Kennwort für MySQL unterliegt keiner Längenbeschränkung – das vom Replikation-User darf allerdings nur 32 Zeichen lang sein. Daher sieht das Kennwort korrekt aus, wenn man es über die Konsole verifiziert – nur eben die Replikation funktioniert nicht.

Viel Spaß beim Einrichten!