Dem Mailserver die Geschwätzigkeit austreiben: Backscatter mit Plesk eindämmen.

Man hat’s nicht leicht – aber leicht hat’s einen! Zum Beispiel immer wieder gerne am Montag nach den Ferien. Wenn die ersten Mails mal wieder auf was gröberes schliessen lassen, geeignet den mühsam errungenen Erholungseffekt in der grosse Wolke der Erinnerungen aufgehen zu lassen.

Zum Beispiel das Mail der Kundin K., das mir mitteilt, dass einer unserer Server angeblich auf einer Blacklist für Spammer steht.  Und tatsächlich: Auf Backscatter.org finde ich die angegebene IP als geblockt eingetragen. Eine klare Aufforderung zur Handlung, auch wenn ich geneigt bin anzunehmen, dass die Backsquatter-Liste nicht von den allermeisten Mailprovidern verwendet wird und unsere IP sich dort in wirklich guter, illustrer Gesellschaft befindet…

Was ist Backscatter überhaupt!? Zurückschnattern? Weiterlesen »


Update auf Plesk 9.5.2 auf Strato Power Server L

Nur mal schnell, weil ich’s gestern hatte und sonst vielleicht vergesse. Vielleicht interessierts ja sonst noch jemanden.

Die Strato Power Server werden aktuell mit Plesk 9.3.0 und einer recht aktuellen Ubuntu Hardy Installation ausgeliefert. Um nun auf das aktuelle Plesk Panel updaten zu können, sollte man zunächst im Kundenbereich (config.stratoserver.net // Serverkonfiguration // Plesk) beim betreffenden Server die aktuelle plesk-Lizenz aktivieren (PLESK_95_FOR_VZ). Die Wartezeit, bis die Lizenz gültig und herunterladbar ist, kann man damit überbrücken, das Update zu fahren.

Dazu als Root mittels SSH auf die Shell einloggen und

apt-get update
apt-get dist-upgrade

eingeben.

Dann wird Plesk 9.5.x aus den Repositories gezogen und installiert. Versuchts erst gar nicht mir dem Web-Installer, der bricht immer mit Lizenzproblemen ab. Nachdem dist-upgrade durchgelaufen ist, kann man die aktuelle Lizenz aus dem Config-Bereich von Strato herunterladen und im Plesk-Backend hochladen. Viola!

Achja: Vergiss vorher Dein Backup nicht!

Plesk 9.5.1: Nach Update funktioniert Webmail “Horde” nicht mehr

Früher Vogel fängt den Wurm. Ich konnte mal wieder die Finger nicht davon lassen und habe die neueste Version von Plesk auf meinen virtuellen Servern aufspielen müssen.

Dabei sollte ich doch wissen, das gröbere Versionssprünge bei Plesk gern mal zu erhöhtem Kaffekonsum, Zigarettennotstand und Rändern unter den Augen führen ;)

Diesmal ging aber alles erstaunlich glatt über die Bühne. Ein paar Fehlermeldungen, die aber so abstrus klangen, das ich Sie einfach mal ignorierte. Und tatsächlich, nach wenigen Minuten Wartezeit strahlte mich der Loginscreen von Plesk 9.5.1. an. Im Update-Manager alle Häkchen grün, was will man mehr!?

Aber bekanntlich soll man den Tag ja nicht vor dem Abend loben! Niemals!
Und tatsächlich, nach einigen Stunden trudelten die ersten Kundenmails ein: Das Webmail geht nicht. Na Klasse. Eines meiner “Lieblingsthemen”.

Zuerst also das Error-Log gecheckt: /var/log/psa-horde/psa-horde.log war genau Null Bytes gross.
Also mal wieder Blindflug.

Am einfachsten ist in solchen Fällen zunächst immer mal die typische “Windows-Lösung”:  Runter mit dem Kram und dann neu installieren. Nur hilft das nicht über das Plesk-Panel. Da bleiben nämlich, ähnlich Windows, nach einer Deinstallation Reste der alten Version übrig.

Geholfen hat dann folgendes Vorgehen:

  • Das Verzeichnis /etc/psa-webmail/horde sichern:
    cp /etc/psa-webmail/horde /etc/psa-webmail/horde.bak -R
  • Den ganzen Horde-Krempel löschen:
    dpkg –purge –force-depends psa-horde psa-imp psa-kronolith psa-mnemo psa-turba psa-ingo psa-mimp
  • Wirklich allen Horde-Kram löschen:
    delete /etc/psa-webmail/horde/*
  • Dann über den Autoinstaller auf der SSH-Shell Horde nachinstallieren. Nich ganz trivial, wenn man die guten, alten Kommandozeilen-Installer nicht kennt ;)
  • Zu guter letzt die Zugangspasswörter für Horde restaurieren:
    cp /etc/psa-webmail/horde.bak/.horde.shadow /etc/psa-webmail/horde.bak/.horde.shadow
  • Ich neige dann zu Server-Restarts um mal Ordnung in alles zu bringen.

Fertig. Horde läuft wieder. Bei mir zumindest.

Update von TYPO3 4.2.10 Hosteurope vServer 3.0 auf vServer 4.0 und TYPO3 4.3.0

Angeregt durch einen Kommentar von Thorsten auf meinem etwas älteren Post über ein geteiltes Typo3-Setup auf einem virtuellen Server 3.0 von Hosteurope, habe ich über das Wochenende ein Update auf die neueste Version des vServers gemacht und dabei gleich auch das Typo3 auf den aktuellen Stand gebracht. Ein kurzer Abriss.

Hosteurope bietet für die 4. Generation der virtuellen Server leider kein SuSE Linux mehr an, weshalb ich mich für das Update auf ubuntu entschied.
Die Bereitstellung des Servers für das Update dauerte ca. 24 Stunden, nun hatte ich 7 Tage Zeit, den gesamten Content vom “alten” 3.0. Server auf den “neuen” 4′er zu verfrachten.

Hier also der Bericht über die “Stoplersteine” beim Umzug und TYPO3-Upgrade.

Weiterlesen »

Plesk VServer: shmpages im schwarzen Bereich?

Manche Sachen muss man nicht verstehen, sondern einfach nur hinnehmen.
So auch das:

Ein von mir mitbetreuter Hosteurope vServer 3.0 “Max” verabschiedete sich in unregelmässigen Abständen immer wieder im Service httpd, also Web.
Der Kunde, der normalerweise recht gut mit seinem System klar kommt, wandte sich heute morgen an mich, mit der Bitte doch mal nachzusehen, woran denn das liegen könnte.

Der erste Verdacht fiel natürlich auf die Ressourcenbeschränkung innerhalb der Virtuozzo / Plesk Umgebung. Und richtig: Der Parameter für die Beschränkung der shmpages war hin und wieder und nicht ganz nachvollziehbar im “schwarzen Bereich”, also am Anschlag. Das hatte zur Folge, dass keine neuen Prozesse mehr gestartet werden konnten und daher der Apache Webserver keine neuen Childprozesse mehr zu erzeugen im Stande war.

Was sind denn nun diese “shmpages”?

Parallels meint dazu:

shmpages: the total size of shared memory (IPC, shared anonymous mappings and tmpfs objects).

Aha, also der von Anwendungen geteilte, für Interprozesskommunikation und Objekten im temporären Filesystem genutzte Speicher.

tmpfs?
Da hab ich dann, bevor ich den Bohnenzähler (cat /proc/user_beancounter) anwerfe, einfach mal ein df -h auf der Root-Shell abgesetzt um zu gucken, was denn auf dem Filesystem so abgeht.

Und wirklich: in /usr/psa/handlers/spool fand ich dann über 20.000 E-Mails, teilweise recht alt, die darauf warteten, händisch gelöscht zu werden.

Der shmpages – Counter ist dann sofort um diese 20.000 Einheiten zurück gegangen und alles ist wieder gut. Hoffe ich :)

Weiss jemand, warum das Spool-Verzeichnis im tmpfs liegt und den shmpages zugerechnet wird? Notwendigkeit oder Schikane?