|
|
Mediawiki installieren und wartenSchreibkollektivErik Möller |
Wiki wiki heißt auf Hawaiianisch so viel wie schnell - und rasant setzte sich auch die so benannte Webtechnologie durch. Die Idee kam 1995 Ward Cunningham, als er gemeinsam mit anderen Muster für wiederkehrende Programmieraufgaben sammeln wollte.
Der simple Grundgedanke: Jede Wiki-Seite lässt sich direkt im Browser ändern. Eckige Klammern genügen, um einen Text in einen Link zu verwandeln. Gibt es schon eine entsprechend benannte Seite, wird diese verlinkt, andernfalls erhält der Besucher beim Klick darauf eine Edit-Box, um eine neue Seite mit diesem Titel anzulegen (Abbildung 1). Eine leicht verständliche Syntax sorgt für die Formatierung. So erzeugen Sternchen am Zeilenanfang eine Liste, Gleichheitszeichen eine Überschrift.
Mittlerweile gibt es über 100 Wiki-Engines[11]. Sehr beliebt ist Mediawiki[1], die Grundlage der Copyleft-Enzyklopädie Wikipedia, die als das Erfolgsmodell für Wikis überhaupt gilt (siehe Kasten "Reiseführer durch die Mediawiki-Welt"). Im ersten Jahr lief Wikipedia mit dem in Perl geschriebenen Usemod-Wiki[10]. Doch schon bald erwies es sich als unterdimensioniert für die Last von Hunderttausenden von Artikeln und Besuchern. Die Wikipedianer entwickelten deshalb die Wiki-Engine Mediawiki in PHP mit MySQL als Backend. Beim Einrichten und Anpassen an die eigenen Wünsche helfen PHP-Kenntnisse, doch auch ohne sie lässt sich mit Mediawiki bereits ein performantes und komfortables Wiki aufsetzen.
Reiseführer durch die Mediawiki-Welt |
Obwohl speziell für Wikipedia entwickelt eignet sich Mediawiki nicht nur für Enzyklopädien. Zusätzlich zu Wikipedia gründete die Wikipedia-Community im Dezember 2002 das Wiktionary [http://www.wiktionary.org]. Für jedes Wort liefert dieses Wörterbuch eine englische Definition und eine Liste von Übersetzungen in einer Vielzahl von Sprachen. Das Wiki-Modell ist hier ideal, da Nutzer aus aller Welt Übersetzungen beisteuern können.
Zitatsammlung und SchulbücherWikiquote [http://www.wikiquote.org] ist eine kategorisierte Zitatensammlung; Wikisource [http://www.wikisource.org] ergänzt Wikipedia um Original-Quellenmaterial, das gemeinfrei ist oder unter einer freien Lizenz steht. Inhaltlich unabhängig von Wikipedia ist das Wikibooks-Projekt auf [http://www.wikibooks.org], das freie Lehrmaterialien zu beliebigen Themen schaffen will. Das Projekt könnte sich zum zentralen Archiv für universitäre Vorlesungsskripte entwickeln.
PropagandalexikonEine Liste weiterer Mediawikis findet sich auf Wikipedia[6]. Erwähnenswert sind die Propaganda-Enzyklopädie Disinfopedia [http://www.disinfopedia.org] und deren deutscher Ableger Lobbywatch [http://www.lobbywatch.de]. Für Programmierer könnte das deutsche Datenbankentwickler-Wiki [http://www.wikitravel.org] den Reiseführer Wikitravel, der Autor dieses Artikels hat die Open-Source-Wissensdatenbank Openfacts zur Open-Source-Dokumentation gestartet: [http://openfacts.berlios.de] |
Mediawiki kommt in zwei Ausführungen daher: Die stabile Version gibt es als Archiv auf der Homepage[1] zum Download. Die Entwicklerversion sollte zwar stets lauffähig sein, enthält aber experimentelle Funktionen, die mitunter Probleme bereiten. Wer das Risiko eingehen will, lädt sie per CVS herunter:
cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/wikipedia login cvs -z3 -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/wikipedia co phase3
Im Verzeichnis »phase3« findet man danach die Software, die der Befehl »cvs update« jederzeit aktualisiert.
Mediawiki benötigt mindestens Apache 1.3.27, MySQL 4.0.13 und PHP 4.3.2 inklusive Kommando-Interpreter. Mit PHP 5 ist es kompatibel. Soll die Software Bilder automatisch verkleinern, kommen noch wahlweise das Toolkit Imagemagick oder die in aktuellen PHP-Versionen enthaltene Bibliothek »gd« hinzu. Imagemagick unterstützt jedoch deutlich mehr Dateiformate als »gd«.
Zur Installation dient das Skript »install .php« im Mutterverzeichnis. Zuvor ist allerdings ein wenig Konfigurationsarbeit angesagt. Der Administrator sollte die Beispielkonfigurationen »LocalSettings.sample« und »AdminSettings.sample« nach »LocalSettings.php« und »AdminSettings.php« kopieren. Tabelle 1 zeigt, welche Variablen in »LocalSettings.php« an lokale Gegebenheiten anzupassen sind.
Tabelle 1: Grundkonfiguration | |
$IP | Lokaler Pfad auf dem Server, in den das Wiki kopiert werden soll, zum Beispiel »/var/www/wiki« |
$wgServer | Teil der Serveradresse vor dem ersten Slash, zum Beispiel »http://www.meinwiki.de« |
$wgScriptPath | Unterverzeichnis mit den PHP-Dateien, zum Beispiel »wiki«; leer lassen (»""«), wenn diese im Hauptverzeichnis liegen |
$wgEmergencyContact | E-Mail-Adresse des Administrators, die bei Problemen angezeigt wird |
$wgDBserver | Name der MySQL-Datenbank |
$wgDBuser und $wgDBpassword | MySQL-Benutzer für den normalen Datenbankzugriff |
$wgDBsqluser und $wgDBsqlpassword | MySQL-Benutzer für SQL-Queries per Webinterface, hat nur Leserechte |
$wgLanguageCode | Zwei-Buchstaben-Code der verwendeten Sprache, zum Beispiel »de« für Deutsch |
Da es Wikipedia in über 50 Sprachen gibt, gehört auch die Software zu den am besten übersetzten Wikis. Wer möchte, setzt sich ein Wiki in Arabisch, Chinesisch, Japanisch, Hebräisch, Hindi, Russisch oder Vietnamesisch auf, Unicode-Unterstützung inklusive. Dazu stellt der Wiki-Betreiber die Variablen »$wgInputEncoding« und »$wgOutputEncoding« auf »UTF-8«.
Das Installationsskript legt drei MySQL-Benutzer an und setzt deren Rechte in der Datenbank. Den »$wgDBuser« benutzt Mediawiki für alle normalen Datenbankoperationen, während der SQL-Benutzer »$wgDBsqluser« nur Lesezugriff hat. Er wird für eine Spezialseite verwendet, auf der Sysops SQL-Queries ausführen können. Die Wikipedia-Sysops machen damit zum Beispiel neue Benutzer ausfindig und begrüßen sie. In die Datei »AdminSettings.php« trägt der Wiki-Betreiber noch den MySQL-Admin-Benutzer »$wgDBadminuser« und dessen Passwort ein. Dieser User mit Schreibrecht auf die Wiki-Datenbank wird bei der Installation und von den Wartungsskripten benutzt.
Zur Installation ruft man nun als Root den Befehl »php install.php« auf. Auf manchen Distribution heißt der Kommando-Interpreter statt »php« auch »php4«. Das Skript fragt unter anderem nach dem MySQL-Root-Passwort und legt die Datenbank, Tabellen und MySQL-Benutzer an. Zu guter Letzt bietet es an, zwei Wiki-Benutzeraccounts, einen Sysop und einen Developer zu erzeugen. Das empfiehlt sich auf jeden Fall, da man sonst von Hand die entsprechenden Benutzerrechte in der Datenbank setzen muss.
Die Konfiguration für den Webserver beschränkt sich darauf, in der »httpd.conf« die Datei-Endung »phtml« als PHP-Erweiterung einzutragen:
AddType application/x-httpd-php .php .phtml
Im bei der Installation erzeugten Verzeichnis »upload«, in dem Mediawiki hochgeladene Dateien speichert, sollte die Ausführung von PHP und die Darstellung von HTML verboten sein:
<Directory "/pfad/zu/uploadverzeichnis"> AllowOverride None AddType text/plain .html .htm .shtml php_admin_flag engine off </Directory>
Für das Skriptverzeichnis müssen globale Variablen aktiviert sein. Das erledigt die Anweisung »php_value register_globals 1« in der entsprechenden Directory-Direktive der Apache-Konfig. Es lässt sich aber auch systemweit in der Datei »php.ini« einstellen, die typischerweise in »/etc« oder »/etc/php4« liegt.
Das Installationsskript kopiert alle PHP-Dateien ins Webserver-Verzeichnis. Je mehr Skripte dort von außen zugänglich sind, desto größer ist das Risiko, dass ein Angreifer auf interne Funktionen Zugriff erlangt. Dies gilt besonders in Verbindung mit »register_globals«, da man über die URL-Parameter interne Variablen des Skripts setzen kann.
Deshalb sollten im Webserver-Verzeichnis nur die essenziellen Dateien liegen, das heißt alles mit der Endung ».phtml«, Bilder und Stylesheets. Am besten verschiebt der Admin nach der Installation alle Dateien mit der Endung ».php« in ein separates Verzeichnis außerhalb des »Document Root«. Anschließend muss er in den »phtml«-Dateien noch die Verweise auf »./LocalSettings.php« durch »LocalSettings.php« ersetzen und in der Datei »php.ini« den zuvor gewählten Pfad dem »include_path« hinzufügen.
Hat man auf dem Server keinen Root-Zugriff oder versagt das Installationsskript, lässt sich Mediawiki auch manuell installieren. Dafür ist zuerst eine Datenbank anzulegen. Vorsicht: Wer eine vorhandene Datenbank verwendet, kann in Namenskonflikte mit bestehenden Tabellen geraten - ein Präfix verwendet Mediawiki nicht.
In »LocalSettings.php« kommen nur die Minimaleinstellungen, den SQL-Benutzer etwa kann man weglassen und »AdminSettings.php« ignorieren. Der Hauptdatenbankbenutzer sollte dann natürlich existieren. Alle ».php«- und ».phtml«-Dateien aus »includes« und »languages« sowie die Verzeichnisse »stylesheets« und »images« werden ins Hauptverzeichnis des Webservers kopiert.
Per Aufruf der Datei »wiki.phtml« mit dem vorher gewählten Pfad ist nun im Browser die Hauptseite des frisch installierten Mediawiki zu erreichen. Das bietet die Gelegenheit, sich ein wenig umzuschauen und mit den Funktionen der Software vertraut zu machen (siehe Kasten "Kleines Mediawiki-Abc"). Akzeptiert der Webserver »phtml« nicht als Endung für PHP, lässt sich die Datei in »index.php« umbenennen, in diesem Fall muss man zusätzlich die Variablen »$wgScript« und »$wgRedirectScript« ändern. Die Datei »DefaultSettings.php« enthält dafür eine Vorlage.
Die meisten Wikis erlauben auch anonymen Nutzern das Bearbeiten von Seiten. Das wirft die Frage auf, wie der Wiki-Betreiber mit unerwünschten Einträgen oder sogar Vandalismus umgeht. Mediawiki stellt dafür einige Verteidigungsmechanismen bereit.
Mitunter ist es aber auch wünschenswert, nur ausgewählten Benutzergruppen das Lesen oder Bearbeiten von Inhalten zu gestatten. Hierzu dienen die Flags »$wgWhitelistEdit« und »$wgWhitelistRead« in »LocalSettings.php«. Welche Gruppen Seiten bearbeiten oder lesen dürfen, definiert das Array »$wgWhitelistAccount«:
$wgWhitelistAccount=array("user" => 0, "sysop" => 1, "developer" => 1)
In dieser Einstellung dürfen nur Sysops und Entwickler Seiten bearbeiten. So lässt sich ein neuer Benutzertyp »editor« hinzufügen:
$wgWhitelistAccount=array("editor" => 1, "user" => 0, "sysop" => 1, "developer" => 1)
Anschließend vergibt der Wiki-Betreiber noch die Schreib- oder Leserechte, indem er das Feld »user_rights« in der Datenbank für einen Benutzer auf den Wert »editor« setzt.
Für die Rechteverwaltung gibt es gegenwärtig noch kein generisches Werkzeug in Mediawiki. Um Nutzer zum »sysop«, »developer« oder »editor« zu ernennen, ist eine SQL-Abfrage an die Datenbank erforderlich, zum Beispiel:
USE Datenbankname; UPDATE SET user_rights='sysop' WHERE user_name='Benutzername';
Die Entwicklerversion kennt inzwischen den Typ des Bürokraten, der über eine Spezialseite andere Benutzer zu Sysops befördern kann. Er braucht dazu die Rechte »sysop, bureaucrat«.
Über die Liste der letzten Änderungen ist zu verfolgen, was gerade im Wiki passiert. Für jede Änderung bietet Mediawiki ein »diff«, das die Unterschiede zwischen zwei Revisionen im Kontext hervorhebt (siehe Abbildung 3). Alle Änderungen an einer Seite werden bis zur allerersten Version protokolliert. Über die Versionsgeschichte lassen sich vergangene Revisionen laden und bei Bedarf auch erneut speichern. Schließlich gibt es über die Funktion »Benutzerbeiträge« auf der Seite des Benutzers die Möglichkeit, sich alle Beiträge eines Nutzers anzeigen zu lassen. Sysops können aus dieser Liste heraus mit einem Mausklick einzelne Edits rückgängig machen: Damit ist der von einem Vandalen angerichtete Schaden innerhalb weniger Sekunden repariert.
Im Falle eines akuten Streits über den Inhalt einer Seite kann ein Sysop einen temporären Schutz verhängen. Hartnäckige Störenfriede lassen sich auch per IP-Sperre aus dem System verbannen. Einziges Problem: Nicht registrierte Nutzer mit Dialup-Verbindung haben wechselnde IP-Adressen. IP-Blocks dauern deshalb standardmäßig nur 24 Stunden (Option »$wgIPBlockExpiration«).
Insgesamt ist Vandalismus aber ein stark überschätztes Problem. Die größten Schwierigkeiten sind eher sozialer Natur: Welche Seiten sind im Wiki erlaubt, welches Verhalten ist zulässig? Hier muss sich der Betreiber Gedanken über ein schlüssiges Regelwerk machen.
Da viele Nutzer sich nicht registrieren, sollte der Wiki-Betreiber sinnvolle Standardoptionen im Array »$wgDefaultUserOptionsEn« in der Datei »Language.php« vorgeben. Die zugehörigen deutschen Texte befinden sich in »LanguageDe.php«. Wichtig sind die Optionen »quickbar« (0 = keine Navigationsleiste, 1 = Navigationsleiste links, 2 = rechts). Bei »editondblclick« öffnet ein Doppelklick auf die Seite das Edit-Fenster, »showtoc« generiert bei Seiten mit mehr als drei Überschriften ein Inhaltsverzeichnis und »showtoolbar« schaltet die Javascript-Werkzeugleiste im Edit-Fenster ein (Abbildung 1).
Die Option »editsection« zeigt für angemeldete Benutzer neben jeder Überschrift einen »Bearbeiten«-Link an. Damit lassen sich gezielt einzelne Abschnitte ändern. Das ist besonders bei großen Seiten bequem, weil das lange Navigieren im Edit-Fenster entfällt. Andererseits zerstören diese Links aber manchmal das Layout. Ist die Option »editsectiononrightclick« aktiviert, hat ein rechter Mausklick auf eine Überschrift den gleichen Effekt. In Konqueror führte dies allerdings im Test gelegentlich zu Abstürzen.
Für Wikipedia stellte sich sehr bald das Problem, wie man Informationen über das Wiki, Regeln oder Diskussionen von Enzyklopädie-Artikeln trennt. So gibt es einen Artikel über das Phänomen FAQ, aber auch eine offizielle Wikipedia-FAQ. Um hier eine sinnvolle Trennung zu ermöglichen, gibt es in Mediawiki so genannte Namensräume. Sie sind in der Datei »Language.php« und deren lokalen Übersetzungen definiert. Standardmäßig gibt es den Hauptnamensraum, mehrere Diskussions-Namensräume, einen Namensraum für Bilder, einen für Benutzerseiten, den Spezial-Namensraum und den noch spezielleren Mediawiki-Namensraum. Artikel außerhalb des Haupt-namensraums haben stets ein Präfix vor ihrem Titel. So verweist etwa »[[Diskussion:Hauptseite]]« auf die zur Hauptseite gehörige Diskussionsseite, »[[Benutzer:Troll]]« ist die persönliche Seite des Users Troll.
Wer kein gigantisches Wiki betreibt, der kann sich einen Namensraum bestimmt sparen: den Meta-Namensraum. Er ist standardmäßig nach der Variablen »$wgSitename« in »DefaultSettings.php« benannt. So liegt die Wikipedia-FAQ unter »[[Wikipedia:FAQ]]«. Das löst zwar den oben erwähnten Konflikt, ist aber für kleinere Websites eher störend. Werden in der Datei »LanguageDe.php« aus dem Array »$wgNamespaceNamesDe« die Namensräume 4 und 5 gelöscht, verschwinden sie auch aus der Benutzerschnittstelle.
Eine vom Usemod-Wiki übernommene Funktion sind Unterseiten. Zum Artikel »Linux« könnte es eine Unterseite »Linux/Kernel-Tipps« geben. Auf der Kernel-Tipps-Seite zeigt dann automatisch ein Link auf »Linux«. Unterseiten lassen sich für jeden Namensraum einzeln in der Variablen »$wgNamepacesWithSubpages« anschalten.
Der über »$wgUseDatabaseMessages« aktivierbare »MediaWiki«-Namensraum erlaubt es, alle Textelemente der Software innerhalb des Wiki zu bearbeiten, was Übersetzungen erheblich vereinfacht. Die Namen der Programmtext-Variablen stehen in »Language.php«.
Der Inhalt der in diesem Namensraum angelegten Seiten lässt sich überall im Wiki einbinden. Wer beispielsweise einen Standard-Begrüßungstext formulieren möchte, legt eine Seite »MediaWiki:greeting« an. »{{msg:greeting}}« zeigt deren Inhalt anderswo an. Ändert man die Mediawiki-Seite, ändern sich auch alle Seiten, die mit »{{msg}}« darauf zugreifen. Der Befehl »{{subst:greeting}}« fügt hingegen den Text an Ort und Stelle ein, ohne ihn automatisch zu aktualisieren. Achtung: Seiten im Mediawiki-Namensraum dürfen keine Umlaute oder Leerzeichen im Titel enthalten. Da jedoch jeder Programmtext aus der Datenbank abgefragt wird, ist es besser, dieses Feature nur in Kombination mit Memcached (siehe unten) zu nutzen.
Der dauerhafte Betrieb von Mediawiki ist wesentlich stressärmer als die sachgerechte Installation. Im Idealfall muss der Wiki-Betreiber sich lediglich um die Vergabe von Sysop- und Entwickler-Rechten kümmern. Zum Backup der Datenbank empfehlen sich »mysqldump« oder »phpMyAdmin«. Wer größere Datenbestände wie die Artikel der Wikipedia von[5] importieren möchte, sollte nach dem Import das Skript »maintenance/rebuildall.php« aus dem Installationsverzeichnis aufrufen, andernfalls funktionieren »Was zeigt hierher« und ähnliche Abfragen nicht mehr.
Mediawiki bietet verschiedene Optionen zur Performance-Optimierung - Beispiele enthält die Datei »DefaultSettings.php«. Die geänderten Optionen sollte der Admin aber in die »LocalSettings.php« kopieren, um ein versehentliches Überschreiben bei einem Upgrade zu verhindern.
Für große Wikis stellt Mediawiki die Option »$wgMiserMode« bereit, die zeitintensive Abfragen wie etwa die Liste der längsten Artikel deaktiviert. Auf jeden Fall empfiehlt es sich, über »$wgUseFileCache« den Seitencache zu aktivieren. Anonyme Nutzer erhalten dann statische HTML-Seiten, was die Performance erheblich erhöht.
Wer dazu bereit ist, ein wenig Geduld und Spucke zu investieren, holt mit Memcached[7] und Zlib noch mehr heraus. Memcached reduziert Datenbankzugriffe, indem es Benutzerdaten und Link-Informationen im Speicher hält, Zlib komprimiert alte Seitenrevisionen. Dazu muss allerdings PHP mit den Optionen »--enable-sockets« und »--with -zlib« kompiliert sein, ein Aufruf von »<?phpinfo()?>« in einer PHP-Testseite gibt darüber Auskunft.
Der Daemon sollte im Hintergrund mit den Optionen »-d -l 127.0.0.1 -p 11000 -m 64« laufen. Dies stellt für lokal laufende Anwendungen 64 MByte RAM als Speichercache bereit. Achtung: Memcached verfügt über keine Authentifizierung. Lokale Benutzer haben freien Zugriff, daher sollte Memcached keinesfalls auf Systemen mit mehreren Nutzern laufen. Ohne Firewall oder ohne den Parameter »-l« können auch externe Benutzer auf den Server zugreifen, etwa um Passwörter auszuspionieren.
Jetzt lassen sich die Optionen »$wgCompressRevisions«, »$wgUseMemCached«, »$wgSessionsInMemcached« und »$wgLinkCacheMemcached« aktivieren. Die Option »$wgCompressRevisions« spart durch Kompression alter Seitenrevisionen mit »gzip« viel Platz auf dem Server.
Noch ist sie nicht in der offiziellen Version enthalten, doch erlaubt[9] schon einen Blick auf die von Peter Danenberg entwickelte Wikitex-Schnittstelle. Mit ihr lassen sich in Zukunft zahlreiche Backends an Mediawiki koppeln: GNU Lilypond[8] zum Beispiel übersetzt eine einfache Syntax in schön formatierte Notensätze, unterschiedliche Latex-Makros generieren mathematische und chemische Formeln oder Schachbrett-Bilder zur Illustration von Spielanalysen (siehe Abbildung 6).
Die Funktionsfülle der Software wirkt auf Neulinge mitunter verwirrend. Im Allgemeinen hilft die Mediawiki-Gemeinde aber gerne bei Fragen und Problemen. Wer ein Mediawiki betreibt, sollte sich der Mailingliste »mediawiki-l«[4] anschließen oder im IRC-Channel »#mediawiki« auf [irc.freenode.net] vorbeischauen. (eba)
Infos |
[1] Mediawiki: [http://www.mediawiki.org] [2] Mediawiki-Handbuch: [http://meta.wikipedia.org/wiki/MediaWiki_User%27s_Guide] [3] Handbuch der deutschen Wikipedia: [http://de.wikipedia.org/wiki/Wikipedia:Handbuch] [4] Mailingliste des Projekts: [http://mail.wikipedia.org/mailman/listinfo/mediawiki-l] [5] SQL-Dumps der Wikipedia: [http://download.wikimedia.org] [6] Projekte, die Mediawiki einsetzen: [http://en.wikipedia.org/wiki/Wikipedia:Sites_using_MediaWiki] [7] Memcached: [http://www.danga.com/memcached] [8] Lilypond: [http://lilypond.org/web] [9] Wikitex-Demo: [http://wikisophia.org] [10] Usemod-Wiki: [http://www.usemod.com] [11] Masterlist verfügbarer Wiki-Engines: [http://c2.com/cgi/wiki?WikiEngines] |
Der Autor |
Erik Möller ist Mitentwickler der Mediawiki-Software und Autor der englischen Wikipedia. |