Seit langem wollte ich einen Teamspeak Server auf einem Virtual Server von 1&1 mit SUSE LINUX 10.1 (X86-64) installieren. Dabei stiess ich immer wieder auf das Problem, dass Teamspeak mit dem Fehler „Runtime error 230 at 0804CE2F“ abgestürzt ist.
Hier kommt die Lösung, wie ich das Problem letztendlich beheben konnte.
Die Seite www.abgespeist.de bietet viele, gut aufbereitete Informationen über Lebensmittel und deren Inhaltsstoffe. Auf jeden Fall einen Blick wert!
Es war mal wieder an der Zeit, dass mich die EDV im Stich lässt. Aber von Anfang an:
Ich habe meine Mail Adressen und Webseiten von einem Server auf einen anderen umgezogen, da auf dem alten System gerade die Festplatten das Zeitliche segnet. Auf dem neuen System läuft eine SUSE LINUX 10.1 (X86-64) mit Plesk auf einem Virtual-Server. Der eigentliche Umzug der Mails und Seiten sowie der installierten Applikationen wie Gallery2 und WordPress verlief problemlos.
Als ich mich gestern jedoch mal wieder im Administrationsbereich von WordPress angemeldet habe, prangte auf der Startseite die Aufforderung die neueste Version WordPress 2.8 zu installieren. Aktuell war bei mir die Version 2.7. Da ich auf dem alten Server die automatische Update Funktion nicht ausführen konnte, reizte es mich schon, dies jetzt einmal zu probieren. Gesagt, getan. Ein kleiner Klick auf Update und das System begann zu arbeiten. Nach ein paar Minuten bekam ich dann die Meldung, dass WordPress erfolgreich upgedated werden konnte. Prima!
Als nächstes machte ich mich daran, mich im Adminbereich ein wenig umzuschauen. Alles war wie bisher, bis auf den Theme Editor. Die Stylesheet-Dateien konnten wie gewohnt bearbeitet werden. Aber die Template-Dateien liessen sich nicht mehr öffnen. Ich bekam nur eine weisse Seite zu sehen. Im Error Log des Apache-Webservers war folgendes zu lesen:
PHP Fatal error: Call to undefined function token_get_all() in /srv/www/…/wordpress/wp-admin/includes/misc.php on line 273
Da ich nicht sagen kann, ob der Theme Editor auf dem alten Server ohne Probleme gearbeitet hat, kann ich auch nicht mit Bestimmtheit sagen, dass dieser Fehler auf das Update von WordPress zurück zu führen ist oder es an dem Serverumzug gelegen hat.
Fakt ist, dass laut php.net die Tokenizer-Extension ab php 4.3.0 per default aktiviert sein soll. Bei mir läuft php5 und beim kompilieren wurde nicht „–disable-tokenizer“ angegeben. Also habe ich als Nächstes die Funktion in einem Skript von der Kommandozeile aufgerufen. Auch hier bekam ich die Fehlermeldung. Ich loggte mich auf einem Debian-Test-Server ein und probierte den Funktionsaufruf im Skript erneut. Hier funktionierte Alles wie es sollte. Kein Fehler! Ich schaute mir die installierten PHP-Pakete in aptitude auf dem Test-Server an und verglich sie mit den installierten Paketen in yast. Sie waren identisch. Also schaute ich mir noch die nicht installierten PHP-Pakete in SuSE an. Hier gab es das Paket PHP-tokenizer. Vielleicht bringt die Installation ja die gewünschte Funktion.
Da ich unter SuSE auf diesem virtuellen Server von 1&1 nicht genug RAM habe, damit yast Pakete erfolgreich installiert, tat ich dies mit rug. Dafür wird zuerst der Dienst novell-zmd gestartet. Rug greift hierauf zu.
/etc/init.d/novell-zmd start
Dann kann per rug das Paket php-tokenizer installiert werden.
rug install php-tokenizer
Anschliessend muss der Webserver neu gestartet werden.
/etc/init.d/apache restart
Jetzt der Test. Im PHP-Skript kann die Funktion token_get_all() – die vorher im Fehlerlog moniert wurde – erfolgreich aufgerufen werden. Und der Theme-Editor von WordPress zeigt auch keine weisse Seite mehr sondern öffnet die gewählte Vorlage zum Bearbeiten.
Vielleicht hilft dieser Artikel ja einigen, die wie ich im Netz erfolglos nach einer Lösung für das WordPress-Update 2.7 auf 2.8 unter SuSE auf einem virtuellen Server bei 1&1 gesucht haben.
Nachtrag: Das Problem mit der Funktion kam nicht durch den Serverwechsel, sondern durch das Update der WordPress Version zu stande. Der Funktionsaufruf von token_get_all() in der Datei misc.php kam erst in WordPress Version 2.8 hinzu.
In der Superhelden-Fabrik baust auch Du Dir Deinen ganz persönlichen Super-Helden.
Auch bei mir verlief das Update der Serversoftware Plesk von Version 8 auf 9.0.1 nicht fehlerfrei. Nach dem Updatestart wurden zu allererst die „Base Packages of Plesk“, der „Plesk Updater“, die „Plesk API“ und der „Plesk Backup Manager“ automatisch heruntergeladen und installiert. Die von vorherigen Updates gewohnte Erfolgsmail blieb auch nach einer Stunde aus. Also habe ich den Server neu gestartet und mit den ausstehenden Updates fortgefahren. Alle Pakete befinden sich nun auf dem aktuellen Stand (Jan 27, 2009). Doch auch nach diesem Update blieb das System mir die Erfolgsmail schuldig.
Da die laufenden Applikationen eine höhere Priorität hatten als die interne Verwaltungssoftware begann ich mit dem Test dieser. Der erste Anschein vermittelte: Alles klar – keine Probleme: Alle Webseiten sind ohne Ausfall abrufbar. Jedoch lauerte die Tücke im Detail. Beim Test der Mailingfunktion der Applikation wurden die versandten Mails nicht dem Empfänger zugestellt. Die php-Funktion mail() arbeitete nicht korrekt. Auch der Aufruf des mail Befehls von der Unix-Shell beförderte alle Mails direkt ins Datennirvana.
Der nächste Schritt lenkte darum meine Aufmerksamkeit auf die Logdatei /var/log/mail.info. Hier ein kleiner Auszug:
=============== SCHNIPP ==================
Feb 11 18:53:01 qmail-queue-handlers[22449]: from=root@s12345678.s12345678Feb 11 18:53:01 qmail-queue-handlers[22449]: to=admin@validdomain.de
Feb 11 18:53:01 qmail: 1234374781.356154 info msg 158991456: bytes 359 from <root@s12345678.s12345678> qp 22450 uid 0
Feb 11 18:53:01 qmail: 1234374781.362156 starting delivery 9: msg 158991456 to remote admin@validdomain.de
Feb 11 18:53:01 qmail: 1234374781.474744 delivery 9: failure: 123.12.123.12_does_not_like_recipient./Remote_host_said:_550-Verification_failed_for_<root@s12345678.s12345678>
550-Unrouteable_address/550_Sender_verify_failed/Giving_up_on_123.12.123.12./
=============== SCHNIPP ==================
Das Problem, warum die Mails nicht verschickt werden wird in der 5. Zeile deutlich: Der Fehlercode 550 besagt, dass der entfernte Mailserver 123.12.123.12 unsere Absenderadresse root@s12345678.s12345678 nicht mag.
Man muss wissen: Mailserver (123.12.123.12) checken vor der Annahme einer Mail, ob die Absenderdomain (s12345678.s12345678) mit der IP-Adresse des einliefernden Mailservers zusammanpasst. Da sich unser Mailserver aber nach dem Update mit der Domain s12345678.s12345678 identifiziert und dieser Domain nicht die richtige IP-Adresse unseres Servers zugeordnet ist, verweigert der entfernte Mailserver unserer Mailannahme.
Nach ein wenig googlen bin ich auf diesen interessanten Forumseintrag gestossen. Der qmail Mailserver setzt die Absenderadresse in der Datei /var/qmail/control/me. Hier muss nicht wie bei mir nur s12345678 stehen, sondern der vollständige Domainname, also s12345678.onlinehome-server.info. Nach einem Neustart des qmail werden die Mails wieder ordnungsgerecht versandt.