Installation von MediaWiki beim Provider 1&1

Posted on by

Einführung
Will man die Opensource Software “MediaWiki” beim Provider 1&1 installieren, so gibt es einige kleinere Hürden zu überwinden. Voraussetzung für die aktuellen MediaWiki-Versionen ist in jedem Fall ein Webhosting-Paket, das eine MySQL-Datenbank (am besten MySQL 5) und einen PHP5-Interpreter beinhaltet. Die Standardeinstellungen bzgl. des nutzbaren Speichers für PHP-Prozesse sind bei 1&1 ausreichend (40 MB; gefordert sind 32MB).

Wir folgen mit der nachfolgenden Beschreibung in Teilen einem Blog-Artikel von Johan Cyprich
(http://www.cyprich.com/2007/08/17/installing-mediawiki-on-11/#),
auf den wir als grundlegende Lektüre verweisen. Zur generellen Einführung in MediaWiki und dessen Installation ist (trotz einiger Schwächen) vielleicht das Buch “MediaWiki Administrators’ Tutorial Guide” von M. Rahman, PACKT Publishing, 2007, geeignet.

Es sind vor allem folgende drei Punkte, die bei der Installation im Rahmen eines 1&1 Webhosting-Pakets zu beachten sind:

  • Während der Installation von MediaWiki muss das Installationsprogramm lokale Einstellungen in ein bestimmtes Verzeichnis “config” schreiben. Hierzu muß die Schreibberechtigung für das Verzeichnis gesetzt sein. Zudem muss im Zuge der Installation eine Datei “/config/index.php” gefunden werden, was ohne weitere Maßnahmen misslingt.
  • Normalerweise wird das PHP5 – Modul des Web-Servers bei 1&1 nur dann gezogen, wenn die entsprechende PHP-Datei die Endung .php5 aufweist. Dies kann und sollte man für die Wiki-Seiten ändern.
  • Die Zugangsdaten zur Datenbank sollten zur Sicherheit in einem für Benutzer nicht zugänglichen Verzeichnis außerhalb der Wurzelverzeichnisse der angebotenen Websites hinterlegt und zur Laufzeit in die PHP-Skripts eingebunden werden. (Hier unterscheidet sich unser Vorgehen übrigens von der Beschreibung von Cyprich.)

——————————————————————————–

Schritt 1: Anlegen oder Auswahl der Datenbank
MediaWiki kann seine Tabellen in einer bereits vorhandenen Datenbank anlegen. Zur Unterscheidung von Tabellen anderer Applikationen kann man während der Installation einen Prefix für die Tabellennamen definieren. Hat man mehrere Datenbanken zur Verfügung, so lohnt es sich ggf. allein aus Platzgründen, für MediaWiki eine separate Bank zu reservieren. Das Erstellen von Backups vereinfacht sich dann zudem.

Die Anlage einer spezifischen Datenbank erfolgt nach dem Kundenlogin bei 1&1 über die Auswahl des Punktes “MySQL-Datenbank” unter der Leiste “Homepage/Anwendungen”. Das aufgehende Fenster gibt eine Übersicht über bereits angelegte Banken und bietet zudem die Möglichkeit, eine neue Bank zu initialisieren. Die Dialoge sind leicht verständlich. Wir gehen hier nicht weiter darauf ein. Als Version der Bank wähle man trotz der Warnhinweise MySQL 5. Nach der Anlage der Datenbank erhält man die Informationen zum Datenbankserver, zum Datenbanknamen, zum Datenbanknutzer und zum Passwort durch Anklicken des entsprechenden Buttons “Bearbeiten” in der Übersicht zu den vorhandenen Datenbanken.

Schritt 2: Anlegen einer PHP-Include Datei mit den Zugangsdaten für die Datenbank
Dieser Schritt ist wie Schritt 10 optional; wir raten aber dazu, ihn aus Sicherheitsgründen auszuführen.
Bei 1&1 bekommt man pro Vertrag typischerweise einen einzigen zusammenhängenden Verzeichniszweig für seine Dateien auf einem Server zugewiesen. Das Wurzelverzeichnis dieser Ordnerstruktur sollte man typischerweise nicht als Wurzelverzeichnis seiner Website oder seiner Websites definiert haben. Vielmehr weist man die Webdomainen definierten Verzeichnissen unterhalb der Wurzel der eigenen Verzeichnisstruktur zu.

Hat man etwa 2 Domainen “mydomain.de”
und “mydomain.com” reserviert, so wird man typischerweise Verzeichnisse “/de” und “/com” definieren, unter denen man die Index- und sonstigen Webdateien der jeweiligen Site platziert. (Die Zuordnung der Domaine zum jeweiligen Verzeichnis erfolgt bei 1&1 unter dem Punkt “Domainverwaltung”). Dieses Vorgehen hat den Vorteil, dass man außerhalb der Verzeichnisse für die Inhalte der Webdomainen weitere Verzeichnisse definieren kann, die für Besucher der Websites nicht direkt sichtbar oder zugänglich sind. Damit kann man insbesondere beim Einsatz von PHP oder PERL die Sicherheit etwas verbessern; man kann etwa sensible Dateien in genau solchen nicht sichtbaren Verzeichnissen unterbringen und diese zusätzlich durch “.htaccess”-Dateien weiter gegen unbefugte Zugriffe absichern.

Wie man seine MediaWiki-Seiten in der zugänglichen Verzeichnisstruktur aufhängt, ist ein wenig Geschmackssache. Sinnvoll ist ggf. die Definition einer Subdomaine. Wir gehen nachfolgend davon aus, dass die (Installations-) Dateien für MediaWiki in einem speziellen Verzeichnis – das also als lokale Wurzel für den Wiki-Bereich fungieren soll – abgelegt wurden. In unserem Beispiel etwa im Verzeichnis: “/de/mywiki”.

Nun definiert man mit Hilfe eines FTP-Tools auf oberster Ebene der eigenen Verzeichnisstruktur ein Verzeichnis mit beispielsweise dem Namen “mywiki_include” (Pfad: /mywiki_include) und legt darunter eine PHP-Datei – beispielsweise “db_access.php” – mit folgendem Inhalt an:

<?
$wgDBserver = “dbxxxx.1und1.de”;
$wgDBname = “dbxxxxxxxxx”;
$wgDBuser = “dboxxxxxxxxx”;
$wgDBpassword = “xxxxxxxxx”;
?>

Man ersetze dabei die xxx-Platzhalter durch die eigenen Access-Daten für die in Schritt 1 gewählte Datenbank.

Das Verzeichnis “mywiki_include” kann man danach noch mit einer “.htaccess-Datei” schützen. Wir gehen hier nicht weiter auf den “.htaccess”-Mechanismus ein, verweisen aber auf die Möglichkeit, einen solchen Schutz bei 1&1 unter der Rubrik “Zugänge” über den Punkt “Geschützte Verzeichnisse” zu aktivieren. Man legt dabei zunächst eine Zugangskennung fest und ordnet diese und ein zugehöriges Passwort dann dem zu schützenden Verzeichnis (hier “mywiki_include”) zu.

Schritt 3: Kopieren der MediaWiki-Installationsdateien in das Verzeichnis für den Wiki-Bereich
Die aktuellen MediaWiki-Dateien holt man sich (als tar-Archiv) am besten von folgender Website: http://www.mediawiki.org/wiki/Download/de.
Die Dateien kopiert man dann in unserem Beispiel in das Verzeichnis “/de/mywiki”.

Schritt 4: Erzeugen einer htaccess-Datei zur Änderung des Dateityps für PHP5
Das Wurzelverzeichnis zum Wiki (hier: /de/mywiki) ergänze man um eine Datei “.htaccess” oder erweitere eine evtl. bereits vorhandene .htaccess-Datei) mit folgendem Inhalt:
AddType x-mapp-php5 .php
Nun werden auch Dateien mit der Endung .php (soweit sie aus diesem Verzeichnis stammen) durch den PHP 5 Interpreter verarbeitet.

Schritt 5: Umbenennen und Ersetzen des “config”-Verzeichnisses
Man bennene nun (per FTP-Tool) das “config”-Verzeichnis (/de/mediawiki/config) um in “configure”. Danach erzeuge man ein neues Verzeichnis “config” (/de/mywiki/config) und erteile (per FTP) einen temporären Schreibzugriff auf dieses Verzeichnis (z.B. die UNIX-Rechtekombination “757” ).

Schritt 6: Starten der Installation
Man rufe im Browser seiner Wahl (z.B. Firefox) die Seite “index.php” oder die Seite “index.php5” im Wiki-Verzeichnis auf.
Das sollte etwa so aussehen: “http://www.mydomain.de/mywiki/index.php5”. Auf der dann im Browser angezeigten Seite klickt man den Punkt “set_up wiki” an.
Bei der nachfolgenden Fehlermeldung ersetzt man in der angezeigten Adresszeile des Browsers “config” durch “configure” und drückt die Enter-Taste, um die geänderte
Adresse
“http://www.mydomain.de/mywiki/configure/index.php”
aufzurufen.

Schritt 7: Ausfüllen des MediaWiki-Installationsformulars
Wir nehmen an, dass im oberen Bereich der nun angezeigten Seite keine Fehlermeldungen erscheinen. Man sollte danach alle erforderlichen Angaben im Formular ausfüllen – im Besonderen auch die Angaben zum Datenbankaccess. (Wir werden die entsprechenden Zeilen später in der zugehörigen PHP-Datei identifizieren und ersetzen).

Schritt 8: Verschieben der Datei LocalSettings.php
Nach der Abschlußmeldung zur Installation verschiebe man (per FTP) die Datei “LocalSettings.php” vom “config”-Ordner in das Hauptverzeichnis des Wiki-Bereichs. In unserem Fall also von “/de/mywiki/config/LocalSettings.php” nach “/de/mywiki/LocalSettings.php”. Danach ist das WIki bereits lauffähig und man kann einen ersten Blick darauf werfen, indem man im Browser “http://www.mydoman.de/mywiki” als Adresse angibt.

Schritt 9: Entfernen der in Schritt 5 vergebenen Schreibberechtigung auf dem Verzeichnis “config”
Bitte setzen Sie die Zugangsberechtigungen auf dem Verzeichnis “config” wieder auf die Standardwerte (keine Schreibberechtigung).

Schritt 10: Ersetzen der Datenbank-Zugangsdaten in der Datei “LocalSettings.php”
Die eben in Schritt 8 verschobene Datei “LocalSettings.php” lädt man sich per FTP auf den lokalen Rechner zuhause, macht sich zur Sicherheit eine Kopie davon, und editiert dann die Datei. Man identifiziere die Einträge zum Datenbankzugang der Form

$wgDBserver = “dbxxxx.1und1.de”;
$wgDBname = “dbxxxxxxxxx”;
$wgDBuser = “dboxxxxxxxxx”;
$wgDBpassword = “xxxxxxxxx”;

Man lösche diese 4 Zeilen (!!!!!! nicht aber die Zeile mit dem Inhalt $wgDBtype = “mysql”;) und ersetze Sie durch eine Include-Anweisung (require_once) mit einer relativen Pfadangabe zur Datei “db_access.php” aus Schritt 2. In unserem Beispiel sähe die Zeile dann so aus:

require_once( “../../mywiki_include/db_access.php”);

Die so modifizierte Datei “LocalSettings.php” speichert man nun und lädt sie per FTP auf den Webserver bei 1&1 in das Verzeichnis “/de/mywiki/” (Überschreiben der vorhandenen Datei – letztere ggf. vorab zur Sicherheit umbenennen und als Sicherheitskopie ablegen).

Abschließend sollte man im Browser erneut in das nun fertig installierte Wiki gelangen können. Nun kann man sich entspannt den erforderlichen Administrationsaufgaben widmen oder die ersten Wiki-Seiten anlegen.

OX5 – Login Problem mit Konqueror – Nachtrag 1

Posted on by

Wie man der Kommunikation zu den Konqueror-Bugs

http://bugs.kde.org/show_bug.cgi?id=150070 und http://bugs.kde.org/show_bug.cgi?id=149957

entnehmen kann, gibt es seit ein paar (Entwicklungs-) Versionen wohl tatsächlich Schwierigkeiten bei der Interpretation von HTTP Header Direktiven. Es handelt sich dann also nicht um ein OX5 spezifisches Problem des Browsers Konqueror.

Die KDE-Entwickler arbeiten anscheinend daran – das ist beruhigend, obwohl man sich natürlich fragt, wie denn die Tests aussehen, wenn in einen so wichtigen Bereich eines Browsers eingegriffen wurde. Auf der anderen Seite führt aber auch nicht jeder Benutzer mit so hoher Frequenz wie ich ein Update der KDE Umgebung durch.

Betrachten wir das Ganze also mal als Test, wie denn die Opensource Gemeinde mit so einem Problemchen umgeht. Ich bin jedenfalls gespannt, ob und in welcher der nächsten Versionen der von SUSE publizierten KDE rpms dieser Fehler behoben sein wird.

Ergänzung:
Mir ist bei der Analyse des HTTP-Datenverkehrs zwischen OX-Server und Browser (mittels Wireshark) aufgefallen, dass die OX-Leute für den Redirect im Login-Prozess eine “REFRESH”-Direktive im HTTP-Header benutzen. Das ist insofern bemerkenswert, als dies kein HTTP 1.1-Standard ist, wenngleich diese Direktive von Firefox, IE und Opera unterstützt wird. Bis zur Version 3.5.7-64.1 wohl eben auch von Konqueror. Nur danach halt leider nicht mehr!

Eine Lehre, die sich an diesem Beispiel erneut bestätigt, ist die Folgende:

Gerade beim produktiven Einsatz von Opensource muss jedes Update des Desktops vor dem Produktiv-Einsatz gründlich auf die Funktionstüchtigkeit der Standard-Arbeitsabläufe hin getestet werden. Es wird keineswegs alles besser, wenn ein neues (Zwischen-) Release auf den Markt kommt.    


VMware – bei anracon täglich im Einsatz

Posted on by

VMware – bei anracon unter Linux und Windows im produktiven Einsatz

Dies ist zwar ein Linux-Blog. Dennoch kommt in unserer Firma auch Windows zum Einsatz. Entscheidende Gründe hierfür sind:

  • Die weite Verbreitung von Windows bei unseren Kunden (im Besonderen bei Konzernkunden).
    Es wäre zu zeitaufwändig, Projektdokumente zwischen Openoffice und den MS Produkten hin- und her (!) zu transformieren. Dies funktioniert im professionellen Umfeld nur mit erheblichem Aufwand, der einem leider nicht bezahlt wird. (In eine Richtung – z.B. von Openoffice zu MS Office – arbeitet man allerdings deutlich aufwandsärmer. Beim Anlegen neuer Dokumente verwenden wir diese Richtung sehr oft. Leider tritt aber sehr viel häufiger der Fall ein, dass ein Dokument dauerhaft gepflegt werden muss. Dann arbeiten wir, wo immer erforderlich, direkt mit den MS-Produkten.)
  • WEB-Entwicklung: Wir setzen die Produkte von Adobe/Macromedia ein.
    Diese sind rein für MS Windows entwickelt worden. Man kann Flash und Dreamweaver 8 zwar unter Crossover Office (Wine) zum Laufen bringen. An einigen Details, die für den produktiven Einsatz zumindest störend sind, gibt es dann aber doch immer wieder Schwierigkeiten. Zudem ist die Performance unter Crossover Office wenig berauschend. Web-Entwicklungstools sind unter Linux zwar im Aufbau; ihre Leistungsfähigkeit und ihr Umfang scheinen uns aber noch nicht mit den Eigenschaften der Adobe/Macromedia-Produkte vergleichbar.

Es galt und gilt daher, bei aller Bevorzugung von Linux einen ausgewogenen Einsatz von Windows zu realisieren. Der Kompromiss bei anracon sieht wie folgt aus:

  • Serverbetrieb: Alle für den täglichen Betrieb benötigten Serverkomponenten (Groupware, LDAP, CUPS, Samba, MySQL, Postgres, Dateiserver, Apache etc.) laufen komplett auf dedizierten Linux-Systemen.
  • Clientbetrieb: PCs für Webentwicklung sind Windows-Rechner mit VMware oder Linux-Rechner mit VMware.

Ob wir auf einem Client-PC Windows oder Linux als Primärsystem (im VMware Chargon: “Host-System”) einsetzen, machen wir (nach vielen Tests) heute rein von der HW-Konfiguration abhängig:

  • Auf neueren Maschinen mit Doppelcoreprozessor (z.B. Athlon X2, ab Baureihe 4000+) und ausreichendem Speicher (> 2GByte) verwenden wir als Host-System Linux. Hier gibt es bei dedizierter Zuordnung von VMware und des Gastsystems (noch XP) keinerlei Probleme mit der Performance der benötigten Applikationen. Die komplette Web Premium Suite CS3 läuft heute auf einem System mit einem Athlon X2 4800 anstandslos.
  • Auf älteren Maschinen mit Einzelprozessor und geringerem Hauptspeicher ist dagegen MS Windows das Hauptsystem. Linux-Applikationen bieten wir hier im Rahmen einer maßgeschneiderten Linuxinstallation auf einer virtuellen VMware-Maschine an. Dies ist insbesondere bei plattformübergreifenden Tests sehr angenehm.

Wir haben mit dieser Vorgehensweise seit ca. sehr positive Erfahrungen gemacht und können den Einsatz von VMware sehr empfehlen.

Wir wollen an dieser Stelle nicht unerwähnt lassen, dass VMware natürlich auch unschätzbare Dienste leistet, wenn es gilt, neue Betriebssysteme, Applikationen, Netzwerkkonfigurationen und Firewall-Einstellungen vor dem Produktiveinsatz zu testen.

In einem kommenden Beitrag befassen wir uns näher mit der VMware-Istallation auf Systemen mit inzwischen betagteren Athlon X2 Prozessor. Hier gibt es Besonderheiten bzgl. der problematischen Synchronisation der CPU Cores zu beachten.

FwBuilder – eine Perle von einem Programm

Posted on by

Auch Linux-Systeme benötigen Firewalls. Auch wenn ganze Firmennetzwerke nach außen hin durch kommerzielle Firewalls abgeschottet werden, treten innerhalb des Netzwerkes immer wieder Situationen auf, bei denen man bestimmten Rechnern nicht gestatten will, mit anderen Systemen im Netz frei zu kommunizieren oder von anderen Rechnern beliebige Zugriffe anzunehmen. Eine Anwendungssituation ist z.B. die Begrenzung des Schadens durch evtl. Trojaner.

Zur schnellen Konfiguration von server- und generell rechnerspezifischen Firewalls auf der Basis von Iptables setzen wir bei anracon das Programm fwbuilder ein. Ich werde in weiteren Beiträgen hierzu mehr berichten.

Im Moment möchte ich festhalten: Es gibt immer mal wieder Momente, in denen man außerordentlich positive Erfahrungen mit Opensource-Programmen unter Linux macht. Mein Einstieg vor etwa einem Jahr in die Anwendung FWBuilder war ein solcher Moment:

Diese Anwendung

  • ist leicht verständlich
  • prüft die Konsistenz der Firewall-Bedingungen sehr weitgehend
  • hat eine ansprechende graphische Oberfläche, die sehr klar strukturiert ist
  • und entpuppt sich nach einer rel. kurzen Einarbeitungszeit als echte, langfristig wirksame Arbeitserleichterung.

Kurzum: Es handelt sich um echte Perle von einem Programm! Es macht Freude, damit zu arbeiten.

Leute, macht euch mit diesem Programm vertraut und setzt es ein!

Open-Xchange 5 und Konqueror – Login-Problem

Posted on by

Ein permanentes Ärgernis beim Einsatz von Open-Xchange unter Linux sind Unzulänglichkeiten, die im Zusammenhang mit dem Standard KDE (Web-) Browser Konqueror auftauchen.
Das neueste Beispiel ist ein fehlerhafter Login-Vorgang, bei dem Konqueror die Anforderungen des Servers nicht richtig handhabt. Ich beschreibe kurz das Problem, so wie es sich mir darstellt:

Ein Login auf dem Open-Xchange Server setzt wie üblich die Angabe einer Userid und eines Passwortes voraus. Der OX-Server (bzw. das dortige Sessionmanagement) vergeben eine SessionId. Dies wird dem Client zurückgemeldet und daraufhin wird ein Redirect zu einem Servlet des Servers vorgenommen, dass dafür sorgt, dass die Portalseite des Servers für den authentifizierten User aufgebaut und dem Client übermittelt wird. (Ich vermute, dass nach der Vergabe der SessionId der Client aufgefordert wird, die User-Daten nochmal zu übermitteln.)

Bis zur kdebase-Version 3.5.7-64.1 (in meinem Fall über ein SuSE x86-64 rpm unter Opensuse 10.2 eingespielt) lief dieser Login-Vorgang einwandfrei. In der neuesten Version 3.5.7-90.2 klappt dies jedoch nicht mehr. Es erfolgt zwar noch die Anzeige der Meldung, dass eine SessionId vergeben wurde, der anschließende Redirect wird aber nicht mehr ausgeführt und die Portalseite wird nicht angezeigt. Interessanterweise kommt man weiter, wenn man die Seite mit der redirect-Meldung nochmal lädt -> Die Login-Daten des usprünglichen Formulars werden nochmals geschickt, eine neue SessionId wird vergeben und die Portalseite erscheint unmittelbar danach.

Weder Firefox noch Opera zeigen ein derartiges Verhalten.

Wie man der Bug-Datenbank zu Konqueror entnehmen kann, gab es bereits in früheren Versionen von Konqueror Probleme mit Redirects (auch im Zusammenhang mit Authentifizierungs-Dialogen).

Es ist ärgerlich, dass solche Problemchen immer wieder auftauchen und einen flüssigen, produktiven Arbeitsablauf unter Linux (KDE) verhindern. Da es noch weitere Probleme im Zusammenspiel zwischen Konqueror und einem OX5-Server gibt (siehe weitere kommende Beiträge in diesem Blog), rate ich jedem OX5-User eher auf Firefox oder Opera als CLient-Browser zu setzen.