Diese Anleitung leistete mir sehr gute Hilfe beim Update von Wordpress 2.3.3 auf die aktuelle Version 2.5.1. Trotzdem finde ich das Update Prozedere immer sehr umständlich. Eigentlich ändern sich bei den Minor-Updates - also wenn sich die letzte Ziffer ändert - nur wenige Dateien. Trotzdem kopiert man immer alle Dateien einer Wordpress-Installation auf den Webspace. Dies kostet natürlich neben Bandbreite und Zeit auch gehörig Nerven.

Die c’t Ausgabe 10/08 hat hier einen recht interessanten Ansatz, den ich heute direkt umgesetzt habe. Man benötigt hierzu einen Shell-Zugang, bzw. auch Kommandozeilen-Zugang genannt, zu seinem Webspace. Weiter benötigt man auf dem Server Subversion - welches aber in der Regel vorhanden ist. Bei mir ist dies der Fall - klar, ist auch mein eigener Server.

Egal ob man seine bestehende Wordpress-Installation aus dem Automattic-Repository holen möchte um die Installation zukünftig mit Subversion aktuell zu halten, oder aber Wordpress neu installieren will, man benötigt auf jeden Fall erst einmal ein leeres Verzeichnis und sollte unter gar keinen Umständen seine alte Installation überschreiben.

Zuerst holt man sich die aktuelle Version aus dem Repository. Ich setzte voraus, das Wordpress in ein Unterverzeichnis mit dem Namen “wordpress” installiert werden soll. Dies geht für Version 2.5.1 wie folgt:

svn co http://svn.automattic.com/wordpress/tags/2.5.1 wordpress

Nun sind die Dateien schon mal auf dem Webspace. Handelt sich um eine frische Installation - d. h. es sollen keine alten Daten übernommen werden - dann folgt man ab jetzt der Standardinstallationsanleitung. Möchte man Daten aus einer alten Wordpress-Installation übernehmen, dann kopiert man die Datei wp-config.php, .htaccess, sowie seinen Themes-Ordner, ggfs. Plugins-Ordner und weitere hinzugekommene Dateien in das frische Wordpress-Verzeichnis.

Möchte man noch das deutsche Sprachpaket installieren, gibt man folgendes ein:

svn co http://svn.automattic.com/wordpress-i18n/de_DE/branches/2.5/messages wordpress/wp-content/languages -N

Das war es soweit mit der Installation!

Erscheint nun eine neue Wordpress-Version, dann wechselt man in sein Wordpress-Verzeichnis und wechselt erst einmal das Repository-Verzeichnis auf die neue Version. Hier dient als Beispiel die noch nicht existierende Wordpress-Version 2.5.2:

svn switch http://svn.automattic.com/wordpress/tags/2.6

Um nun das Update durchzuführen ist nur noch ein Befehl nötig und man hat die aktuelle Version auf seinem Webspace liegen. Dies geht natürlich sehr schnell, da nur die Dateien ausgetauscht werden, die auch aktualisiert wurden.

svn update

Das wars! Das aber evtl. das nötige Datenbank-Update wie nach einem normalen Update durchzuführen ist, muss ich den Wordpress-Profis unter euch ja nicht erwähnen.

Wenn jetzt einer meiner Freunde diese gern nutzen möchte, aber leider keinen Webspace mit Shell-Zugang oder Subversion hat, soll sich einfach mal bei mir melden. Auf meinem Server ist noch Platz frei

Ich habe ja einen eigenen Server, der den ganzen Schnickschnack drauf hat, um eben diese (und ein paar Seiten von Freunde) zu generieren. Damit die Konfiguration für meine Freunde und mich etwas einfacher ist, nutze ich Confixx von SWSoft. Bei Confixx kann man über eine Weboberfläche Domainen anlegen, diesen Verzeichnisse zuordnen, etc. pp.. Dieses Confixx erstellt dann - nachdem man alle Eintragungen in der Weboberfläche gemacht hat - alle Konfigurationsdateien für den Webserver usw.

Confixx benötigt auch dringend PHP. Diese Skriptsprache, auf der auch diese Seite beruht. PHP kommt in verschiedenen Ausführungen daher. Einmal als Apache-Modul. Dieses hat den Vorteil, daß es sehr schnell ist, aber den Nachteil, daß jeder Benutzer auf dem Webserver jedem anderen in die Verzeichnisse schauen kann, weil alle PHP-Skripte unter einem einzigen Systemuser (dem des Webservers) ausgeführt werden.

Seit einiger Zeit kann Confixx auch mit suPHP umgehen. Hier ist der Vorteil, daß alle PHP-Skripte unter einem seperaten Systemuser ausgeführt werden, d. h. keiner kann dem anderen in die Karten schauen. Nachteil ist, daß jedesmal wenn eine Seite aufgerufen wird, ein grosser Overhead erzeugt wird, der in der Regel grösser ist, als das Ausführen des PHP-Skripts selbst, d. h. die Seiten werden sehr langsam und der Server ist immer sehr stark ausgelastet.

Der Kompromiss zwischen den beiden o. g. Möglichkeiten stellt fcgid dar (der Nachfolger von fastcgi). Es ist schnell, hat wenig Overhead und alle Skripte werden unter einem seperaten User ausgeführt. Der Nachteil ist, daß Confixx dies von Haus aus nicht unterstützt.

Ich habe mich zumindest daran gesetzt und ein kleines Skript erstellt, welches vor dem confixx_counter-Skript ausgeführt werden muß. Dieses erstellt für alle User die entsprechenden fcgid-Wrapper-Skripte, mit denen die PHP-Skripte ansich dann aufgerufen werden.

Zusätzlich wird eine weitere Apache-Konfigurations-Datei (confixx_special_vhost.php) erstellt, welche am Ende der httpd.conf eingefügt werden muss.

Wenn man soweit ist, trägt man in Confixx unter http-Special noch dies ein

# FCGI
AddHandler fcgid-script .php
AddHandler fcgid-script .php4
AddHandler fcgid-script .php5
AddHandler fcgid-script .phtml
#/suPHP_ConfigPath .*/
# FCGI

und die Sache sollte laufen.

Ich setzte dies nun seit ca. einer Woche ein, und der Server wurde merklich entlastet und die Seiten rauschen sehr viel schneller an.

Das Skript downloaden und auf dem Server ausführen. Wenn Fragen sind, diese in den Kommentaren stellen und ich werde ggfs. diese Ausführung erweitern.

Ich bin nun seit Mittwoch krank und habe nichts besseres zu tun, als Heissgetränke zu mir zu nehmen und an meinem Server zu schrauben.

Spamassassin machte mir schon seit einige Zeit Probleme, doch hatte ich bisher nicht die Lust, der Sache auf den Grund zu gehen. In den Log-Dateien kam immer der Fehler

spamd[13416]: dns: sendto() failed: Connection refused at /usr/lib/perl5/vendor_perl/5.8.8/Mail/SpamAssassin/DnsResolver.pm line 340

und Spamassassin benötigte ewig bis die eMail gescannt war. Ich tippte zu erst darauf, daß die DNS-Auflösung nicht mehr funktionierte, doch das konnte ich definitv ausschliessen.

Das Problem liegt an Spamassassin, bzw. der Perl-Klasse selbst. Es nimmt aus der resolv.conf nur den ersten, eingetragenen DNS-Server und versucht zu diesem eine Verbindung herzustellen. Schlägt dies fehl oder dauert dies zu lange, kommt der o. g. Fehler.

Ich habe nun den ersten DNS-Server Eintrag geändert und nun läuft wieder alles einwandfrei.

Dienstag ist ja mein Zweitserver ausgefallen und kam nach dem Reboot nicht mehr in einen definierten Zustand. Ich habe jetzt ein gcc-Update durchgeführt und mußte deswegen auch alle Pakete auf dem System neu kompilieren. Dies wird bei der Linux-Distribution Gentoo mit einem kleinen Befehl erledigt. Problem war, daß 240 Pakete neu gebaut werden mußten und wenn das Kompilieren bei Paket 229 abbricht, mußte ich den Fehler beheben und das System fing wieder von vorn an, die 240 Pakete zu kompilieren. Darum hat es bis gerade gedauert, daß alle Pakete neu erstellt waren.

Im Moment rennt der Server mit Mühe und Not, der Apache rennt und eMail werden empfangen und versandt. Ich werde nächste Woche den Kernel neu erstellen müssen und hoffen, daß dann der Server nach dem booten wieder hochfährt.

Wenn das durch ist, pack ich die Kiste wieder ein Jahr nicht an …

Neben meinem eigenen Webserver habe ich noch den Webserver meines Cousins unter meinen Fittichen. Eingesetzt wird die Linuxdistribution Gentoo, wie auf meinem Server auch. Sorgen machte mir der Server schon lange, da ich von Hand einige wichtige Pakete selbst kompiliert hatte und so kein komplettes Distributionupdate machen wollte, sondern nur wichtige Sicherheitsupdates nachgezogen habe.

Beim letzen Sicherheitsupdate schmiss der Compiler schon bei einigen Paketen Fehler, so daß ich Angst hatte, den Server danach zu rebooten und wollte mich irgendwann - wenn man mal Zeit hat - dem Komplettupdate hingeben.

Hätte ich dies mal früher getan! Gestern konnten keine eMails mehr versandt werden, weil der Mailfilter immer wieder mit nicht nachvollziehbaren Fehlermeldungen ausstieg und ich Dussel ließ mich zu einem Reboot hinreissen. Tja, der Server fuhr zwar hoch, startete aber seine Netzwerkdienste nicht mehr und jetzt bin ich seit gestern Abend dabei, alles neu zu machen und so wie es aussieht, wird das noch einige Tage in Anspruch nehmen - und das, wo ich immer noch nicht wirklich Zeit dafür übrig habe

Kleine Notiz für mich! Um eine IP-Adresse zu blocken einfach folgendes nutzen:

iptables -I INPUT -s zu_sperrende_ip -j DROP

Langsam glaube ich wirklich, daß es o. g. Gesetz gibt!

Erst zerlegt sich meine dBox selbständig. Es war zwar “nur” eine Kabel-Box, aber ich war zufrieden, daß es ein bessere Bild liefert, als das analoge Kabel-Signal. Diese wird seit Freitag aber nur noch als Sat-Box erkannt und ein Software-Update brachte keine Besserung. Jetzt ist wohl erst einmal Sendepause …

Dann habe ich mir letzte Woche eine Peppercon eRic Remote Management Karte bestellt. Diese ist dafür da, daß meinen seinen Server bedienen kann, als würde man mit Tastatur, Maus und Bildschirm direkt davor stehen, kann einen Reset ausführen, falls der Server mal hängt, etc.. Die Karte habe ich mir nur gekauft, da ich gegen Ende letzten Jahres knapp hintereinander mehrere Probleme hatte, die es erforderten zum Rechenzentrum zu fahren und einen Techniker zu bemühen.

Diese Karte wurde heute geliefert! Wer errät wann der Server ausgefallen ist? GENAU! Vorgestern! Der Techniker war nicht greifbar, meine Karte noch nicht eingebaut und so kam es, daß mein Server bis gerade nicht erreichbar war.

Ich wette darauf, daß - sobald die eRic-Karte eingebaut ist - der Server ein Jahr keine Ausfallerscheinungen mehr hat … Murphy’s Law eben ….

Da mein alter VServer-Anbieter noDeeps mich wiederholt im Stich gelassen hat, indem er nie auf Supportanfragen reagierte, telefonisch nur schwer zu erreichen und dann noch genervt war und der Server mehrere Tage down war ohne das es jemanden dort auffiel, habe ich nun den Wechsel vollzogen und habe einen VServer bei NetFabrik gemietet.

Bisher kann ich mich nicht beklagen!
Pro

• Die Weboberfläche zur Administration ist übersichtlich
• Reverse-DNS Einträge können geädnert werden
• Hostname kann geändert werden
• Confixx-Oberfläche inklusive
• sehr schnell eingerichtet

Contra

• Support ist nur über teure 0900-Nummer erreichbar
• Die bestellte Domain wurde immer noch nicht regestriert

Alles im allem bin ich damit aber zufrieden, da er nämlich das tut, was er soll. Denn auf dem VServer läuft nur mein dritter Nameserver, sowie ein Monitoring mit Nagios für meine beiden (vollwertigen) Server.

Ich hoffe, daß ich auch weiterhin weniger Probleme haben werde!