[via Huschi]

Das Skript lädt jeweils die aktuellste Version von WordPress herunter, entpackt diese und aktualisiert die angegebenen Verzeichnisse. Um das Skript zu verwenden sollte man allerdings genau wissen was man tut und vorher ein Backup erstellt haben. Ich habe es zudem zuerst an meiner Beta-Installation getestet. Folgende Schritte sind durchzuführen:

1. Als Root einloggen und in das Verzeichnis /root/ wechseln (# cd /root)
2. Ein Verzeichnis namens wpupgrade anlegen (# mkdir wpupgrade)
3. In diesem Verzeichnis das Skript (s.u.) z.B. unter dem Namen wpupdate speichern
4. Das Skript mit ausführbar machen (# chmod +x ./wpupdate)
5. Ein Verzeichnis mit allen benötigten Sprachdateien anlegen (# mkdir languages)
   Die aktuelle deutsche Sprachdatei findet man bei WordPress-Deutschland
6. Die Datei installations anlegen und dort die absoluten Pfade zu den einzelnen WordPress-Installationen und den Url folgendermaßen angeben:
   /srv/www/vhosts/domain.de/httpdocs/=http://domain.de/
/srv/www/vhosts/domain2.de/httpdocs/=http://domain2.de/
7. Das Skript ausführen (# ./wpupdate)

Hier das Skript zum Download: wpupdate.
Hinweis: Das Skript funktioniert mit der aktuellen WordPress-Dateistruktur und ich habe es zum Update auf Version 2.2.1 verwendet. Bitte die Lizenzhinweise im Header beachten.

Update:

Beim Update der von mir verwalteten Weblogs habe ich einen Fehler beim chown der kopierten Dateien erhalten. Die neue WordPress-Version wird vom Skript mit den Berechtigungen des root-User kopiert. Deshalb müssen am Ende der Besitzer und die Gruppe korrigiert werden. Damit das Skript vollständig auf meinem Server mit einer Linux Suse 10.0 Installation und Plesk 8.2 funktioniert waren dazu folgende Anpassungen notwendig.

In Zeile 67 & 68:

USER=$(ls -l ${DIR}/wp-config.php | cut -f 4 -d ' ')
GROUP=$(ls -l ${DIR}/wp-config.php | cut -f 5 -d ' ')


In Zeile 86:

chown -R ${USER}:${GROUP} ${DIR}/*


Die Anpassungen in Zeile 67 & 68 bewirken, dass der richtige Benutzer und die richtige Gruppe zugeordnet werden. Mit der Anpassung in Zeile 86 wird festgelegt, dass nur Dateien innerhalb des WordPress Installationsverzeichnisses angepasst werden.

Um festzustellen ob tatsächlich der benötigte Benutzer und die richtige Gruppe eingesetzt wird, können folgende Befehle im WordPress-Verzeichnis ausgeführt werden. Dabei wird jeweils der Benutzer und die Gruppe ausgegeben:

# ls -l wp-config.php | cut -f 4 -d ' '
# ls -l wp-config.php | cut -f 5 -d ' '


Vielen Dank an Alex Günsche für den netten live Support bei der Anpassung an meine Bedürfnisse.

Für die Installation wird ein Webserver inkl. Perl-Unterstützung und installiertem RCS benötigt (vgl. TWiki System Requirements). Mit einem eigenen Server kann man benötigte Software installieren und hat außerdem den benötigten Zugriff auf die Apache-Konfiguration.
Und so bekommt man TWiki 4.1 auf einem Server installiert (hier Suse Linux 10 incl. Apache-Server und vorhandenem Plesk 8 Administrationstool).

Installation benötigter Software

Am besten überprüft man zuerst ob die benötigte Software vorhanden ist und installiert diese bei Bedarf auf dem Server. Dazu einfach Yast aufrufen und nach den Paketen suchen (perl, rcs, diff, patch, grep, cron). IdR. sind die meisten Pakete installiert.

Wer möchte kann auch gleich überprüfen ob die benötigten CPAN – Module installiert sind:

 #  cpan

cpan> i Modul:Name (gibt aus ob das Modul installiert ist)

cpan> install Modul:Name (installiert das entsprechende Modul)

Installation von TWiki

1. Download der aktuellen Version:

# wget http://twiki.org/p/pub/Codev/Release/TWiki-4.1.0.tgz

2. Auspacken des Tarballs:

# tar -xzf TWiki-4.1.0.tgz

Da nach sollte im entsprechenden Verzeichnis eine Seite (index.html) mit weiteren Informationen zur Installation sichtbar sein.

3. Den Apachen konfigurieren.

Dazu kann man den ApacheConfigGenerator verwenden. Dort gibt man den absoluten Pfad zum TWiki-Verzeichnis ein (in meinem Fall /srv/www/vhosts/domain/httpdocs) und erstellt die Konfigurationseinstellungen.

Nun müssen die generierten Textzeilen in die Apache httpd.conf inkludiert werden. Plesk inkludiert automatisch Dateien mit dem Namen vhost.conf die sich im Verzeichnis /srv/www/vhosts/domain/conf/ befinden. Einfach die Zeilen in den Editor der Wahl Einfügen und als vhost.conf an entsprechender Stelle ablegen. Wer kein Plesk verwendet sollte sich die Apache Dokumentation dazu anschauen.

Nach dem Speichern der Datei muss man dafür sorgen das die Einstellungen übernommen werden. Folgender Befehl sorg dafür das Plesk die vhost.conf in Apache inkludiert:

# /usr/local/psa/admin/sbin/websrvmng -v -a

4. Konfiguration von TWiki

Jetzt kann man das Configure-Skript aufrufen (http://domain.de/bin/view/configure). Falls man einen Error 500 erhält liegt dies meist an den Datei-Berechtigungen. Wenn man als root user arbeitet, muss man das twiki-Verzeichnis dem richtigen ftp-user zuordnen. In Plesk ist es der verwendete FTP-Benutzer.

# chown -R ftp-user:psacln*

Das Configure-Skrip Präsentiert nun einige Fehler, die aber beim ersten Aufruf völlig normal sind. Unter General-Path-Settings überprüft man ob die vorgeschlagenen Pfade korrekt sind. Nachdem man die Admin-Emailadresse angegeben hat kann man erstmal weiterklicken. Nun sollte man als nächstes das Configure-Skript mit einem Passwort versehen um Missbrauch zu verhindern.

Damit ist TWiki installiert. Wenn man auf einem öffentlichen Server arbeitet sollte man sich nun um einige Sicherheitseinstellungen kümmern. Am einfachsten ist es anfangs das gesamte Verzeichnis zusätzlich per .htaccess zu schützen bis man alle Einstellungen überprüft hat. Als erstes einen eigenen Benutzeraccount registrieren und in diesen im Main-Web in der Seite TWikiAdminGroup eintragen. Da nach die Group Seite schützen (Gelbe Infobox in der betreffenden Seite beachten). Weitere Hinweise dazu findet man in der Dokumentation.

Screenshots

Download und auspacken des Tarballs

Index.html mit Link zur Dokumentation und Configure-Skript

Installation benötigter Software mit YAST

Erstellen der Apache Konfiguration

Konfiguration des TWiki über das Configure-Skript

Plesk verfügt über ein Migrationstool, um Daten von einem auf den anderen Server umzuziehen. Dies erspart natürlich viel Arbeit, vor allem wenn es sich um viele Benutzer und Domains handelt. Hier nun einige Tipps und Erfahrungen zur Migration:

Automatische Migration mit Plesk

Mit dem Migrationstool von Plesk kann man recht einfach sämtliche Daten (Benutzer-Accounts, Domains, Einstellungen, Dokumente, Datenbanken) von einem anderen Server importieren. Ich war überrascht wie problemlos die Daten übertragen wurden. Zumindest zwischen ähnlichen Systemen (Suse 9.1, Plesk 7.5 und Suse 10, Plesk 8 bzw. 8.1).

Um alle Daten auf den gewünschten Server zu übertragen loggt man sich dessen Plesk-Administrationsoberfläche ein und wählt Server > Migration Manager. Nach Eingabe der IP des bisherigen Servers und dem dazugehörigen root-Passwort werden nach einstellen einiger Optionen die Daten übertragen:

Mit etwas Glück ist alles innerhalb kurzer Zeit erledigt. Probleme bekam ich erst, als ich die Migration nach einer Server-Neuinstallation erneut durchführen wollte.

Eventuelle Probleme

Leider gibt es scheinbar Fehler bei der Neuinstallation des Servers über Virtuozzo. Aus mir unbekannten Gründen (Fehlkonfiguration von Hosteurope, oder Bug von SWSoft?) werden die angelegten Datenbank- und FTP-Benutzer bei der Neuinstallation beibehalten, obwohl man in den Einstellungen angeben kann, dass keine vorhandenen Daten übernommen werden sollen. Eine erneute Migration ist damit nach Neuinstallation des Servers nicht ohne weiteres möglich. Die Migration wird mit einer Fehlermeldung beendet: “Unable to create database user: User with requested name already exists”. Um die Migration erneut durchführen zu können habe ich die entsprechenden Kunden / Benutzer in Plesk gelöscht. Da nach muss direkt auf dem Server überprüft werden ob die zugehörigen Datenbank- und FTP-Benutzer gelöscht wurden und falls nicht diese von Hand gelöscht werden. Die Datenbankbenutzer sind dabei in der Datenbank mysql in der Tabelle user abgelegt. Dort müssen die für den Kunden angelegten Benutzer gelöscht werden. Die FTP-Benutzer sind in der Datei etc/passwd abgelegt. Man sollte natürlich sehr sorgsam vorgehen um sich nicht selbst den Zugriff zu versperren. Diese Informationen sind natürlich wie üblich auf eigenes Risiko anzuwenden.

Da nach sollte die erneute Migration wieder fehlerfrei möglich sein.

Wenn man einen lauffähigen Server hat, ist es natürlich sinnvoll zuerst eine Sicherung davon zu erstellen. Die Wiederherstellung eines Images hat bisher immer schnell und problemlos funktioniert.