plusWEB: MehrWert im Netz.

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.

Nun hatte ich ja schon einige Tage Zeit, die beiden Kontrahenten im Vergleich laufen zu lassen. Von den Ressourcen her, geben sich die beiden Kandidaten nicht viel. Beide Systeme laufen vergleichsweise fix.

Die Aufgabe, eine ziemlich gut frequentierte Webseite auf einem Typo3-CMS laufen zu lassen, erledigten die vServer von Hosteurope und Strato zufriedenstellend. Knackpunkt bei beiden Servern waren hier nicht die bereitgestellte Menge an Arbeitsspeicher, sondern die manchmal etwas zu knappe CPU-Leistung, die eine flinke Abarbeitung auch zu Spitzenzeiten behinderten. Die Zugriffszahlen lagen bei gegen 4000 Besucher pro Stunde. Für ein TYPO3 CMS mit Datenbankintensiven Plug-Ins, z.B. einem für den Kunden angepassten tt_news, geht es für mich in Ordnung, wenn die vServer überhaupt noch in erträglichen Zeitspannen überhaupt etwas ausliefern. Weiterlesen »

Durch das schlanke Bestellsystem bei Strato ging die Bereitstellung des neuen Servers recht fix. Wenn man das Wochenende mal abzieht benötigte Strato für die Auslieferung eines vServers an einen unbekannten Neukunden grade mal 7 Stunden. Punkt für Strato. Hosteurope lässt sich die Kundendaten per Briefpost bestätigen und hinkt initial um einige Tage hinterher.

Genau wie bei Hosteurope erhält man ein aus einem Image geklontes System. Dieses ist nicht auf dem neuesten Stand, in meinem Fall handelt es sich um ein OpenSuSE 11.1 mit aktiviertem Plesk 9.2.1. Ich hätte gern ein Ubuntu-Image gehabt, aber im Gegensatz zu Hosteurope bekommt man bei Strato immer eine SuSE Installation. Über den Punkt “Neuinstallation” im Kundenbereich kann man dann eine Installation eines anderen Images anwählen, hier “aktuell” Ubuntu 8.04 mit Plesk 9.0. Weiterlesen »

Ein Kunde hostet derzeit sein Projekt auf einem V-Server 4.0 L von Hosteurope. Da gewünscht wird, eine “Ready-to-Switch” Backup-Lösung zu implementieren, soll ein ähnlicher V-Server bei einem anderen Provider zum Einsatz kommen, der im Fall eines Ausfalls einfach die Funktion des ausgefallenen “Kollegen” übernimmt.

Soweit die Theorie. Ein wenig Recherche später fiel die Wahl auf das durchaus vergleichbare Modell “V-PowerServer M” von Strato. Die beiden Server unterscheiden sich auf dem Papier nur marginal, Hosteurope bietet mehr inklusiven Traffic, aber weniger garantiertes RAM, dafür ist Strato ein paar Euro teuerer. Wenn man eine kürzere Vertragslaufzeit möchte, ist Hosteurope derzeit die bessere Wahl: Die Zahlung einer Einmalpauschale von 19,90 Euro garantiert bei Hosteurope eine einmonatige Mindestvertragslaufzeit mit monatlicher Kündigungsfrist, während Strato für die selbe Einmalzahlung nur eine Reduktion auf 6 Monate Mindestlaufzeit gewährt. Weiterlesen »

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 »

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?