Am 02.11.2010 um 23:30 Uhr wird der Server, auf dem dieser Blog gehostet wird, in einem neuen Rechenzentrum verbracht, so dass alle Aktivitäten bis zum 03.11.2010 spätestens 8 Uhr eingestellt werden.
Dieses für alle Leser dieses Blogs als Information, damit sich keiner in besagtem Zeitraum wundert.
Oder: Wie man sich Stunde um Stunde wegen “Kleinigkeiten” um die Ohren hauen kann…
So zumindest hatte ich nach der Lösung meines Problems mit Ajaxterm auf meinem Server die Erkenntnis, dass ich auch zuweilen recht kompliziert denke.
Auf meinem alten Server hatte ich noch Confixx als Admin-Software installiert und da war der Einsatz von Ajaxterm kein Problem. Also Paket installiert, Daemon gestartet, Virtuellen Host/Proxy eingerichtet, geht.
Auf dem neuen Server unter Plesk ist das eigentlich auch sehr einfach. Eine sehr gute Installationsanleitung hierfür lässt sich sehr schnell über Google finden.
Was allerdings dann folgte war zunächst Ernüchterung: Kein Ajaxterm beim Aufruf der Seite, sondern nur Serverfehlermeldungen.
Okay, dachte ich mir, Log-Files anschauen. Ergebnis: Nichts. Es blieb ein Rätzel, warum Ajaxterm nicht nutzbar war.
Bis dann ein paar Tage und ettliche Websiten später auffiel, dass neben dem Apache Modul proxy auch proxy_http und ggf. auch proxy_html nötig sind, um Ajaxterm bedienen zu können.
Und was soll ich sagen: Danach lief es auch. Allerdings nicht im Firefox, sondern nur im Internet Explorer, was mich schon sehr verwunderte. Denn der Firefox stellte nur die allererste Zeile der Webshell dar, der Rest des “Fensters” blieb verborgen.
Diverse Prüfungen später war dann auch noch nicht einmal das zu sehen und ich begann zu verzweifeln. Ist der Zugriff auf die Shell doch lebenswichtig, wenn man nicht gerade Programme wie putty verwenden kann…
Nun, lage Rede, kurzer Unsinn: Ich schaute einfach mal nach, welche Prozesse auf dem Server liefen. Ajaxterm war aktiv, der Port wurde auch abgehört, allerdings, Ajaxterm basiert ja auch Python, waren mehrere Python-Instanzen aktiv; basierend auf meinen “unerfahrenen” Korrekturversuchen.
Was also tun? Nun, Python komplett abschiessen, also jeden Prozeß einzeln beenden und dann Ajaxterm versuchen zu starten: Nada! Wieder nur ein Serverfehler, der aber auf einen nicht gestarteten Dienst schliessen lies.
Nun, Python war nicht mehr im Speicher, also: Ajaxterm neu starten, Apache neu starten und ggf. Python noch einmal aufrufen und wieder beenden und siehe da: Die erste Zeile des Webterminals war wieder zu sehen.
Blieb bis hierher nun wieder mal mehr der Punkt zu ergründen, warum der Firefox nicht mit Ajaxterm zusammenarbeiten wollte, sondern nur der Internet Explorer.
Nach weiteren Recherschen hierzu im Internet kam dann auch schnell die Lösung: Sarissa, die JS/XML-Umgebung auf der Ajaxterm basiert, war in der Version, wie sie Ajaxterm verwendet nicht kompatibel mit dem Firefox 3.6 (den ich ja aktuell verwende) und auch nicht mit jedem anderen Browser.
Aber ein Patch, der lediglich nur eine Zeile aus der sarissa.js entfernen sollte, schaffte auch hier wieder Abhilfe und siehe da: Sowohl auf dem neuen und auch auf dem alten Server (letzteren hatte ich auch zwischenzeitig neu eingerichtet) läuft nun meine Webshell Ajaxterm wie gewünscht.
Merke also:
Nicht jeder Anleitung im Internet 100%ig vertrauen und auch mal die wirklich einfachen Dinge nachprüfen, wie eben z. B. hängengebliebene Prozesse. Dann klappt es auch meist wieder mit dem “Nachbarn”…
Spam, Spam, SPAM überall.
Es wird immer schlimmer.
Daher habe ich jetzt auch mal die Catchall-E-Mail-Adressen abgeschaltet und lasse alle so ankommenden Emails ins Leere laufen.
Und dazu Clamav als Daemon eingesetzt und siehe da: Der Server Load ist gleich in top Regionen gerutscht (deutlich unter 1).
In wie weit das jetzt stabil bleibt, wird sich zeigen, allerdings sind aktuell die Ladezeiten der Foren auf meinem Server wieder absolut okay.
Drücken wir mal die Daumen, dass alles so bleibt, wie es jetzt ist.
Und ich vermutete erst einen ganz anderen Fehler im System, aber nein, wieder mal “nur” der viele Spam !!
Und das Gute nach der Downzeit: Der Server ist auch wieder recht fix unterwegs, wobei es dennoch weiterhin zu herben Server loads kommt.
Was auch immer passiert… Es wird weiter beobachtet, umgestellt und geändert.
Zuletzt war das Dateisystem selber angegriffen und hatte Fehler.
Nach einem Check aus dem Recoverysystem heraus (dank meines Anbieters zur Verfügung gestellt), war das dann endlich auch behoben und schwupps: Der neue Reboot bracht den Server wieder ins Leben zurück.
Man, und die falschen Inodes, Blocks und FS Dir-Fehler waren bei den E-Mails aufgelaufen.
Scheint so, dass der Server nun doch zu alt für das E-Mail-Aufkommen wird?!?
Jetzt werden andere Seiten aufgezogen und der E-Mail-Empfang von eindeutig als Spam identifizierbaren E-Mails vor dem Empfang aussortiert.
Der Server ist nun schon über 2 Jahre als, aber nicht überaltert und kommt mit den gegebenen Anforderungen sehr gut zurecht, aber die Last, die Spam-E-Mails hier verursachen und damit alle meine Foren deutlich verlangsamen bis hin zur Nichterreichbarkeit für gewisse Zeiträume ist nicht mehr länger tragbar.
Nun, der MTA auf dem Server kann hierfür bereits konfiguriert werden, die betreffenden E-Mails gleich abzulehnen und das wird im Laufe des Abends auch passieren.
Vielleicht kommt dann die eine oder andere E-Mail von Kunden nicht an, aber das kann man dann ja wieder korrigieren.
Ich habe jedenfalls jetzt so was von die Schn… voll, dann wirklich ernsthaft andere Seiten aufgezogen werden müssen…
Hat jemand anderes auch so arge Probleme mit seinem E-Mail-Eingang und Massenspams?
Kommentiert doch einfach hierzu, dann können wir gerne ausführlich darüber diskutieren. Oder auch gerne im Forum.
Lösungen und Tricks sind dazu auch immer gerne willkommen.
KAMPF DEM SPAM!!!
