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.

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!

Ich bekam gerade ein Ticket eines Server-Kunden “auf den Tisch”. Der Kunde verwendet Plesk 10.0.1 und hatte Probleme beim Anlegen eines neuen Kunden mit Abonnement in Plesk.

Ich trage also die gewünschten Daten ein und erhalte beim Klick auf “OK” folgende, rot unterlegte, Meldung bei “Benutzer” im Bereich “Website-Informationen” (also dem FTP-Benutzer).

Sie können in dem Benutzernamen kleingeschriebene alphanumerische Zeichen, Unterstriche und Geviertstriche verwenden. Der Benutzername darf kleingeschriebene alphanumerische Zeichen enthalten und sollte zwischen 1 und 16 Zeichen lang sein.

Abgesehen davon daß mir “Geviertstriche” bisher unbekannt waren scheint diese Meldung wohl so nicht korrekt übersetzt worden zu sein, denn erst als ich den FTP-Benutzernamen komplett mit Kleinbuchstaben eingegeben habe, zeigt sich Plesk zufrieden und legte den Account an.

Falls jemand hier andere Erfahrungen gemacht hat; sachdienliche Hinweise nimmt unser Kommentarbereich entgegen

In Plesk 10.1.1 hat sich in der deutschen Übersetzung ein kleiner Fehler eingeschlichen, der Benutzer, die mit den “Gepflogenheiten” von Plesk bei der Erstellung neuer Datenbanken nicht vertraut sind,  zumindest leicht irritieren kann.

Wenn man eine neue Datenbank angelegt hat und diese auswählt, erhält man den “ausgegrauten” Button zum “WebAdmin”, sowie -neu- die Möglichkeit eine Kopie der DB anzulegen und, als mittleren Button, die Funktion zum anlegen eines neuen Benutzers für die Datenbank. Dieser ist aber leider mit “Neue Datenbank anlegen” beschriftet – der beim “mouseover” erscheinende Hilfetext ist allerdings korrekt.

Wer nicht auf einen Fix oder ein Update seitens Parallels warten will, kann die fehlerhafte Übersetzung wie folgt korrigieren:

In der Datei “admin/smb/application/resources/languages/de-DE/controllers/database/properties.php”, je nach Installation und OS unter “/opt/psa/” oder  “/usr/local/psa/” muss dazu der Inhalt des Array-Elements “buttonAddUser” geändert werden.

Wenn man den wie hier beschriebenen Tip ausgefuehrt hat, laeuft der taegliche cronjob “60sa-update” zwar, ist aber noch ein wenig “geschwaetzig”. So erhaelt man nach erfolgreichem “sa-update” vom Cron Daemon eine Email mit dem Inhalt:

/etc/cron.daily/60sa-update:
Shutting down psa-spamassassin service: done
Starting psa-spamassassin service: done

Gab es fuer “sa-update” hingegen nichts zu tun, erhaelt man immerhin noch folgenden Hinweis vom Cron:

run-parts: /etc/cron.daily/60sa-update exited with return code 1

“man sa-update” meint: “An exit code of 1 means no fresh updates were available.”, was ja fuer sich erstmal kein Fehler ist.

Wem es also genuegt nur dann eine Email zu erhalten, wenn der Exit-Code von “/usr/bin/sa-update” groesser “1″ ist, oder nach erfolgreichem “sa-update” das Start-Stop-Script fuer den SpamAssassin einen Fehler ausgibt, kann die Zeile

/usr/bin/sa-update && /etc/init.d/psa-spamassassin restart | tee -a /var/log/sa-update.log

in

/usr/bin/sa-update && { /etc/init.d/psa-spamassassin restart >> /var/log/sa-update.log; } \
|| { rc=$?; [ $rc -eq 1 ] && exit 0 || exit $rc; };

aendern.

“Quick and dirty”, aber damit sollten eigentlich nur noch Emails von Cron kommen, wenn wirklich etwas “aus der Spur” ist

Verbesserungsvorschlaege sind natuerlich willkommen!

Wer Plesk als Verwaltungssoftware fuer shared hosting Server benutzt, kennt ja das “leidige” Problem, dass nach einem Major-Update meistens irgend etwas gar nicht oder nicht richtig funktioniert, weswegen die meisten – wie man liest – ja mit dem Update auch immer mindestens auf die Minor-Version x.1 eines jeden Releases warten

Wir haben also auch mit dem Update bis zum Erscheinen der Plesk-Version 10.0.1 gewartet, welche aber auch noch den einen oder anderen kleineren Fehler mitbringt. So meldet der Cron Daemon taeglich einen fehlgeschlagenen Job, der die Regeln des mitgelieferten Spamassassins updaten soll:

/etc/cron.daily/60sa-update:
run-parts: failed to exec /etc/cron.daily/60sa-update: Exec format error
run-parts: /etc/cron.daily/60sa-update exited with return code 1

Der Fehler steckt in der ersten Zeile der Datei “60sa-update”:

#/bin/sh

Diese einfach aendern in

#!/bin/sh

das war’s schon

Der Aachener Serviceprovider Net-Publics.de hat seine Produktpalette um ein weiteres Angebot erweitert. Gab es bisher das Servermanagement für die hauseigenen (v)Server als optionales Zusatzpaket, können sicherheitsbewusste Kunden dieses Angebot nun auch zur Absicherung der Server bei anderen Anbietern erwerben.

Das Servermanagement umfasst wesentliche Aspekte im Hinblick auf Serversicherheit und Datensicherheit, die in den heutigen Zeiten immer wichtiger werden. Durch die breite Palette an Software wird es den Hackern immer leichter gemacht, vorhandene Lücken auszuspähen und zu nutzen. Gleichzeitig wird es für den Betreiber eines Servers immer schwerer, hier den Überblick zu behalten um immer auf dem neusten Stand zu sein.

Das Angebot von Net-Publics.de umfasst folgende Bereiche:

* tägliche Sicherheitsupdates
* Überwachung der Dienste und Eingreifen bei Fehlfunktionen
* regelmäßiges Backup mit mindestens vier Tagen Vorhaltezeit
* Unterstützung bei Serveroptimierung und Anpassung an der Software

Die durch dieses Angebot erworbene Sicherheit resultiert für den Kunden in einem minimiertem Ausfallrisiko, kein Zeitaufwand mit der Wartung, kein Bedarf an eigenen Administratoren oder externen Schulungen. Zudem steht immer ein kompetenter Ansprechpartner zur Verfügung.

“Die Kunden können die Sicherheit ihres Servers in erfahrene Hände legen und haben so mehr Zeit für ihr Kerngeschäft. Es spielt für uns keine Rolle, ob der Server bei uns oder bei einem anderen Anbieter gehostet wird”, erlärt Heiko Heeskens, einer der Gesellschafter der Net-Publics GbR.

Nähere Informationen zu dem Angebot finden Interessenten unter:
http://www.net-publics.de/server/management/

Ab und zu steht man einfach wie ein Ochs vom Berg…

Wir hatten gerade die Situation, dass unsere Secondary DNS keine Reverse-Auflösung machen wollten. Langes suchen und überlegen brachte uns irgendwie nicht auf die Lösung.

Wir importieren unsere original BIND-Konfiguration mit

mydnsimport –axfr=<DNS-IP>:53 <ZONE> -r

Damit haben wir alle Einträge, bis auf die PTR-Records.
Na und wer soll denn da direkt drauf kommen, dass man diese mit

mydnsimport –axfr=<DNS-IP>:53 <NETZ>.in-addr.arpa. -r

bekommt?! Wir haben jedenfalls gebraucht.
Und hier ist es für alle, die gerne das auch mit google finden würden. *g*