HorizSync 64.0 - 74.0
VertRefresh 57.0 - 67.0
Modeline "1920x1080" 187.00  1920 2016 2240 2672  1080 1080 1083 1121

danach gdm/kdm/whatever neu starten und glücklich sein, ohne flackern.

Was ist Subversion?

Subversion ist ein sogenanntes Versions-Kontroll-System welches es ermöglicht einfach und unkompliziert an jede beliebige Version einer bestimmten Datei innerhalb eines Quell-Code-Projekts zu gelangen. Subversion gibt es seit etwa 2000. Alternativen dazu sind unteranderem GIT und CVS. Subversion gilt als Quasi-Standard der Versions-Kontroll-Systeme. Es ist kostenlos (OpenSource) und es gibt unterschiedliche Clients für Windows, Linux und auch MacOS. Unter Windows dürfte das bekannteste wohl TortoiseSVN sein.

Der Sinn hinter Subversion versteckt sich darin, dass man ein Projekt entwickeln kann, und immer wieder zu einem bestimmten Stand zurückkehren kann, auch noch nach Jahren. Dabei ist keine Änderung innerhalb des Subversion-Archives redundant es werden im Endeffekt nur Änderungen gespeichert, und dann solange durchgeführt, bis Subversion die gewünschte Version der Datei zurückgeben kann. So ist die aktuelle WordPress Version 2.6 entpackt und lauffähig 4,36 MB groß, das komplette Subversion Archiv „nur“ 107 MB groß. Dies hört sich nun viel an, ist aber, wenn man bedenkt wirkliche jede Änderung im Quellcode bis Version x rückgängig machen zu können wirklich nicht viel

WordPress und Subversion

Automattic Inc. betreibt einen Subversionserver auf dem unter Anderem die Quelltexte für WordPress abgelegt sind. Darüber gestaltet sich der Zugriff auf die Entwicklerversion („bleeding“) und alle vorherigen Veröffentlichungen der Software recht einfach. Um nun WordPress über Subversion zu aktualisieren müssen mehrere Voraussetzungen erfüllt sein:

• Subversion-Client-Software
  Der Subversion Client muss installiert sein. Dies geschieht unter Debian-Abkömmlingen mit dem als root auszuführenden Befehl „apt-get install subversion“. Für ein manuelles aktualisieren von WordPress empfiehlt sich unter Windows Servern die Installation von TortoiseSVN. Für ein Automatisches Update wird allerdings ein Kommandozeilen-Client benötigt, hier bietet sich der Client von Collab.net an, auf den ich mich im weiteren Verlauf auch beziehe.

• Shellzugriff bzw. Remotezugriff
  Zum Einrichten des Aktualisierungsprozesses wird Shellzugriff (SSH) unter Linux, beziehungsweise Remotezugriff (RemoteDesktop) unter Windows benötigt.

• Cronjobs / geplante Tasks
  Um eine Automatische Aktualisierung einzurichten benötigen Sie entsprechende Rechte um einen geplanten Task unter Windows beziehungsweise einen Cronjob unter Linux einrichten zu können.

Ich biete einen Mirror des WordPress-SVNs an, der im Regelfall jede Stunde aktualisiert wird. Dies dient dazu um die Belastung des Ursprünglichen SVN-Servers zu verringern. Auch wenn es ein OpenSource-Projekt ist, sollte man sich nicht einfach immer nur gedankenlos bedienen. Das Mirrorverzeichnis ist wie folgt zugänglich:

Unter dem Archiv auf http://svn.nyforge.eu/get/WP-Mirror liegt eine direkte stündlich aktuelle Kopie des WordPress SVN Archivs. Hierbei geht die Primäre Auswahl über die sogenannten Tags beziehungsweise nur den Entwickler-Zweig „trunk“. Kommt ein neues WordPress-Release heraus, ist ein manuelles Nacharbeiten notwendig, wenn man trunk nicht verwendet.

Als kleine Randanmerkung: Man sollte nur „trunk“ auswählen wenn man sich den Gefahren einer aktuellen Entwickler-Version bewusst ist, und die Risiken entsprechend in Kauf nehmen will. Hierzu gehören unter Anderem plötzliche Änderungen an der Datenbankstruktur die den Blog temporär zumindest unbrauchbar machen können, sowie einfache Fehler in Quelldateien. (So sind zum Beispiel bei der Entwicklerversion von 2.4 auf 2.5 alle eingepflegten Tags verloren gegangen) Ich rate dringendst davon ab, eine Entwickler-Version im Produktivbetrieb einzusetzen. Dennoch beziehen sich die folgenden Beispiele alle auf „trunk“. Wenn man die letzte Stabile Version verwenden will, benutzt man bitte anstatt „trunk“ die Zeichenfolge „tags/2.6“.

Backup erstellen!
Auch wenn es sich kleinlich anhört, aber es wird dringend das Erstellen eines kompletten Backups eines bereits bestehenden Blogs empfohlen! Dies beinhaltet:

• Die Datenbank
• Alles was sich im Blogverzeichnis befindet
• insbesondere aber den Ordner wp-content, sowie die Datei wp-config.php

Erst wenn dieses Backup existiert, sollte man mit der Einrichtung fortfahren.

Ich gehe nun von folgender Situation aus:

• Der Blog ist oder soll über http://www.example.com/blog erreichbar sein
• Das DocumentRoot liegt unter /home/hosts/example-com bzw c:\inetpub\wwwroot\example-com
• Das SVN Binary ist unter Windows im Pfad vorhanden.

Es geht los!
Als erstes muss das Ursprüngliche Verzeichnis gelöscht werden wenn der Blog bereits existierte, beziehungsweise angelegt werden wenn der Blog neu eingerichtet werden soll.
Unter Linux geschieht dies mit dem Befehl

rm -Rf /home/hosts/example-com/blog ; mkdir /home/hosts/example-com/blog –p

Unter Windows kann man dies komfortabel über den Explorer lösen.
Als nächsten Schritt müssen wir die gewünschte Version von WordPress „auschecken“.
Unter Linux ist dies über den Befehl

svn co http://svn.nyforge.eu/get/WP-Mirror/trunk /home/hosts/example-com/blog 

zu erreichen.
Subversion listet daraufhin alle Dateien auf die heruntergeladen wurden.
Unter Windows muss man entsprechend den Befehl wie folgt ändern:

svn co http://svn.nyforge.eu/get/WP-Mirror/trunk c:\inetpub\wwwroot\example-com\blog

Einrichtung
Handelt es sich um eine neue WordPressinstallation kann man die Einrichtung von WordPress gemäß der Anleitung von WordPress starten. (Mit dem Browser auf http://www.example.com/blog/wp-admin wechseln und 2 Seiten ausfüllen, fertig.)
Wenn es sich um ein Update einer bereits vorhandenen (und vorher gesicherten) WordPressinstallation handelt ist die Sache etwas komplizierter.
Der geneigte Blogbesitzer muss nun seine wp-config.php aus dem Backupverzeichnis in die neue WordPress installation kopieren. Ebenso muss der Ordner wp-content/uploads, diverse plugins aus wp-content/plugins sowie das verwendete theme aus wp-content/themes/meintollestheme aus dem Backup in die aktuelle WordPress installation kopiert werden, also zum Beispiel

cp /home/hosts/example-com/blog.bak/wp-config.php /home/hosts/example-com/blog/wp-config.php
cp –rf /home/hosts/example-com/blog.bak/wp-content/uploads /home/hosts/example-com/blog/wp-content
cp –rf /home/hosts/example-com/blog.bak/wp-content/themes/meintollestheme /home/hosts/example-com/blog/wp-content/themes
cp –rf /home/hosts/example-com/blog.bak/wp-content/plugins/TollesPlugin /home/hosts/example-com/blog/wp-content/plugins/TollesPlugin

Damit ware der Blog nun wieder lauffähig. Im Regelfall muss der Blogeigentümer nun noch die Datenbank aktualisieren, was sich einfach mit einem Klick auf http://www.example.com/blog/wp-admin erledigen lässt.
Aktualisieren kann man den Blog nun über den Befehl

svn up /home/hosts/example-com/blog 

Beziehungsweise

svn up c:\inetpub\wwwroot\example-com\blog

Dies sind auch die Befehle die man entweder in die Crontab unter Linux, oder als geplanten Task einrichtet unter Windows, wenn man in den Genuss einer automatischen Aktualisierung kommen will.

Warum über Subversion aktualisieren?
Die Gründe für ein automatisches Update waren für mich recht simpel: Fehlerbeseitigungen sind schneller eingespielt, und ab 2 Installationen die man zu verwalten hat spart man Zeit . Auch wenn man WordPress testen will, und durch das Verwenden von sogenannten Bleeding-Versionen mithelfen will die Qualität zu verbessern bietet sich dieser Weg nun einmal an. Ein wichtiger Grund dürfte auch einfache stupide Faulheit sein, denn es spart wie gesagt Unmengen an Zeit.
Ich müsste mehrere Blogs händisch auf dem neusten Stand halten, mich um die Sicherheitsupdates kümmern, alles Arbeit die man sich sparen kann.
Sicherlich ist es einmalig ein kleiner Aufwand das ganze einzurichten, aber die Arbeit lohnte sich zumindest für mich.

mailq | tail +2 | grep -v '^ *(' | awk  'BEGIN { RS = "" }
# $7=Absender, $8=Empfänger1, $9=Empfänger2
{ if ($8 == "gibtsnicht@rainerbendig.com" && $7 == "MAILER-DAEMON")
print $1 }
' | tr -d '*!' | postsuper -d -

Nach dem Starten von gwservice bot sich mir recht lange das folgende Bild:
shorn:~ # /etc/init.d/gwservices restart
Stopping Groundwork Services [ OK ]
Starting Groundwork Services
Connecting to Foundation listener Host:localhost Port:4913
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Listener not ready to accept data feeds ....
Couldn't connect to localhost:4913: IO::Socket::INET: connect: Connection refused
gwservices start failed. [ FAILED ]

Ursache hierfür ist einfach, dass sich Java nicht im Pfad befindet. nach einem kurzen Edit der Datei /etc/init.d/gwservices wo ich die zeilen

export JAVA_HOME=/usr/java
export JRE_HOME=$JAVA_HOME/bin

einfügte lies sich der Service ohne probleme starten:
shorn:~ # /etc/init.d/gwservices restart
Stopping Groundwork Services [ OK ]
Cannot stat file /proc/28148/fd/3: No such file or directory
Cannot stat file /proc/28148/fd/4: No such file or directory
Cannot stat file /proc/28148/fd/5: No such file or directory
Starting Groundwork Services
Connecting to Foundation listener Host:localhost Port:4913
Listener not ready to accept data feeds ....
Listener ready to accept data feeds....
gwservices start [ OK ]

Original: http://www.softpanorama.org/Tools/Find/find_mini_tutorial.shtml
PDF-Version: http://notepad.bobkmertz.com/content/UnixFindTutorial.pdf