OptiYummy-Update-2012
Zielpraezisierung
Im Jahre 2008 wurde das Optimierungsportal OptiYummy auf einem eigenen Linux-Server in Betrieb genommen. Zwar waren dafür mittelmäßige Kenntnisse in Bezug auf die Administration von Windowssystemen vorhanden, aber in Hinblick auf die Installation und Pflege von Linux-Systemen fehlten jegliche praktische Erfahrungen. Auf Rat eines Freundes (Linux-Experte) fiel damals die Wahl auf die openSUSE-Distribution 10.3 welche auch das MediaWiki 1.10.0 enthielt. Bis auf wenige Hürden, welche durch die Hilfe weiterer Linux-Experten genommen wurden, gestaltete sich die Inbetriebnahme des MediaWiki-Systems beherrschbar für jemanden, der sich nur mit Windows auskennt.
Leider werden für eine openSUSE-Distribution nur für eine begrenzte Zeit automatisiert Sicherheitsupdates eingespielt. Irgendwann ist also unbedingt ein Update auf eine neuere Version erforderlich, auch wenn das bisherige System noch stabil läuft.
Um den Betrieb des noch laufenden alten Systems nicht zu stören, sollte auf neuer Hardware die neueste openSUSE-Distribution mit der neuesten MediaWiki-Version installiert werden. Nach den im Jahr 2008 gesammelten Erfahrungen sollte das problemlos möglich sein.
Leider waren dann die Erfahrungen mit der Installation von MediaWiki 1.18 auf openSUSE 12.1 ziemlich deprimierend. Die Installation erfolgte parallel durch zwei Bearbeiter auf zwei unterschiedlichen PC. Dabei wurde versucht, möglichst systematisch in den von der alten Version bekannten Schritten vorzugehen:
- Erste Probleme gab es mit dem Fernzugriff mitteln NX-Protokoll und NoMachine-Client. Irgendwie klappte es dann in der einen Installation, nachdem es anfänglich auch nicht ging. In der anderen Installation gelang es nicht, mittels NoMachine-Client eine Verbindung zum Server herzustellen. So wurde hier der VNC-Zugriff genutzt.
- Das Klonen der benutzten SSD-Festplatten war ein mehr oder weniger zufälliger Prozess. Das kann sowohl an Schwächen der openSUSE-Live-CD in Hinblick auf die konkrete Hardware liegen. Das können aber auch Probleme mit den SSD-Platten sein.
- Am Schlimmsten war, dass die Inbetriebnahme des Wiki-Systems auf einem System scheiterte. Es wurde danach nur eine leere Seite im Browser angezeigt. Nach erneuter System-Installation (beginnend mit einer leeren Festplatte) gelang es, ein Test-Wiki zu installieren.
- Auf dem parallel installierten System lief alles zunächst relativ problemlos. Doch im laufenden Betrieb kam es immer wieder zu Problemen (z.B. sporadischer System-Stillstand, Update-Blockade).
Auf Grund der aufgetretenen Stochastik wurde beschlossen, von einem Betrieb des Wiki-Systems auf eigener Hardware und eigenem Betriebssystem Abstand zu nehmen und stattdessen ein normales Webhoster-Paket nutzen:
- Die Installation wird unter einem STRATO Hostingpaket PowerWeb Basic vorgenommen, welches über die erforderlichen Ressourcen für des Betrieb eines MediWiki-System verfügt.
- Diese Instalaltion wird im folgenden in nachvollziehbarer Form dokumentiert.
MediaWiki-System installieren
Das Web-Interface für Hosting-Pakete wird von Strato kontinuierlich modifiziert. Die Beschreibung entspricht dem Stand vom Anfang Juli 2012:
- Für Bestandskunden, deren Pakete PHP-Unterstützung enthielt, bot STRATO zu diesem Zeitpunkt einen kostenlosen Umzug auf eine Plattform an welche für dynamische Webanwendungen optimiert ist. Diesen Umzug muss man aktivieren, bevor man ein WikiSystem installieren kann! Angeboten wurde dieses Kostenlos Aktivieren auf der Hauptseite der Paket-Verwaltung.
- Wenn man den Anweisungen folgt, ist der Umzug auf die neue Plattform innerhalb weniger Sekunden erledigt.
- Die existierende Installation von optiyummy.de auf einem eigenen Server sollte natürlich erhalten bleiben, bis die neue Installation bei STRATO läuft. Deshalb wurde optiyummy.net als Domäne für die Einrichtung vorgesehen. Die zuvor bestehende Weiterleitung von optiyummy.net auf den eigenen Server wurde dazu zurückgesetzt.
Auf der Paket-Hauptseite wird für "In wenigen Schritten zu Ihrer Webanwendung!" geworben. Zu Konfiguration der unterschiedlichsten Anwendungen gelangt man auch über den Menüpunkt Homepagegestaltung > AppWizard > Wiki:
- Die von STRATO bereitgestellte MediaWiki-Version (im Beispiel 1.15.2-4) hinkt der aktuellen Version von www.mediawiki.org immer um einige Versionsnummern hinterher (im Beispiel 1.19.1). Die Auswirkung auf die Funktionalität sind sicher gering.
- Nach Wahl von Jetzt Installieren erfolgt die Installation in 4 Schritten:
- 1. MediaWiki - Einstellungen zur Administration
- Bezeichnung: OptiYummy
- Benutzername: WikiSysop
- Passwort: ganz geheim
- E-Mail Adresse: admin@domain.de
- 2. MediaWiki - Domain Einstellungen
- Die bestehende Domäne optiyummy.net wurde infolge der zurückgesetzten Weiterleitung als verwendbar für das WikiSystem angeboten.
- Nach Auswahl der Domäne genügt ein Weiter.
- 3. MediaWiki - Datenbank
- Es wird die MySQL-Version 5.x benutzt
- Den Kommentar "Datenbank für OptiYummy" kann man beibehalten.
- 4. MediaWiki - Fertigstellen
- Man muss die Lizenz-Bedingungen akzeptieren.
- Das Verzeichnis für das WikiSystem ist Beispiel mediawiki_02.
- Das Fertigstellen dauert nur einige Sekunden.
Danach steht ein Mediwiki-System in seiner Grundeinstellung zur Verfügung.
Wiki-System individuell konfigurieren
Geht man für das Paket erneut in Homepagegestaltung > AppWizard, so wird OptiYummy dort als MediaWiki-Anwendung gelistet. Hier sollte man die zugeörigen Details aufrufen:
- Die Datenbank verwalten wir erst später.
- Die Links zur Webseite und zum Admin-Bereich führen beide zur Startseite des Wiki-Systems. Dort kann man nur die Verwaltung durchführen, welche nach Anmeldung als WikiSysop möglich sind.
Man benötigt den Zugang direkt auf die Dateien des Wiki-Systems im Homeverzeichnis. Von STRATO werden für den Zugriff auf das Homeverzeichnis sowohl ein FTP- als auch ein SSH-Zugang zur Verfügung gestellt:
- Server: ftp.strato.de bzw. ssh.strato.de
- Benutzername: Domän-Name (im Beispiel: www.optiyummy.net)
Leider gelangt man mit beiden Zugriffsmechanismen zu unterschiedlichen Ziel-Ordnern. Nur der unverschlüsselte Zugang per FTP ermöglichte den Zugriff auf das Wiki-Verzeichnis mediawiki_02. Sehr komfortabel ist dabei z.B. die Nutzung des Total-Commanders.
Vergeben von Nutzerrechten
Die folgenden Einstellungen sind in der Datei LocalSettings.php vorzunehmen, welche sich im Wiki-Verzeichnis mediawiki_02 befindet. Dazu wurde mittels Total-Commander eine lokale Kopie von LocalSettings.php erzeugt. Diese wird schrittweise verändert und zum Test der Wirkung wieder per FTP in das Wiki-Verzeichnis kopiert.
Wichtig: Standardmäßig können auch anonyme Nutzer Wiki-Seiten editieren! Deshalb sollte man als erste Aktionen die Nutzerrechte ändern. dazu ergänzt man in der Datei LocalSettings.php die Zeilen:
## Benutzerverwaltung ## Nur noch angemeldeten Benutzern das Bearbeiten erlauben $wgGroupPermissions['*']['edit'] = false; ## Neuanmeldungen verbieten $wgGroupPermissions['*']['createaccount'] = false; ## Anlegen neuer Seiten nur für angemeldete Nutzer $wgGroupPermissions['*']['createpage'] = false; ## Anlegen neuer Diskussionen nur für angemeldete Nutzer $wgGroupPermissions['*']['createtalk'] = false; ## Verstecken der Edit-Section-Links vor nichtangemeldeten Nutzern $wgDefaultUserOptions['editsection'] = false; ## Ausschalten der Links auf IP-Diskussionsseiten rechts oben $wgShowIPinHeader = false;
Das Versenden von E_Mails wurde abgeschalten:
$wgEnableEmail = false; $wgEnableUserEmail = false;
Es wird ein Creative Commons Lizenzmodell für die Inhalte benutzt. Zulässig ist folgende Verwertung der Inhalte:
- Verteilung: kopieren, verbreiten and öffentlich Aufführen
- Modifikation: Anpassung der Inhalte an die eigene Arbeit
- Kommerzielle Verwertung
Unter der Bedingung:
- der Namensnennung des Autors oder des Lizenzsgebers,
- ohne den Eindruck zu erwecken, bei der Verwertung Unterstützung erhalten zu haben.
Dazu sind folgenden Variablen in LocalSettings.php zu ergänzen:
$wgRightsUrl = "http://creativecommons.org/licenses/by/3.0/"; $wgRightsText = "Creative Commons"; $wgRightsIcon = "http://i.creativecommons.org/l/by/3.0/88x31.png";
Anpassung des Erscheinungsbildes
Eigenes Logo und Favicon:
- Die erforderlichen Dateien werden per FTP in den images-Ordner kopiert.
- in LocalSettings.php wird die Zeile:
$wgLogo = "";
- ersetzt durch:
## Eigenes Logo 135x135 Pixel einbinden $wgLogo = "/images/logo.gif"; $wgFavicon = "/images/favicon.ico";
Änderungen in der Datei "/skins/MonoBook.php":
- In der MediaWiki-Version 1.15 kann man noch über Änderungen in dieser Datei überflüssige Elemente der Oberfläche ausblenden. Zumindest ab der MediaWiki-Version 1.18 ist dies nicht mehr möglich!
- Die folgenden Änderungen in der Datei "MonoBook.php" im "Skin"-Ordner bergen die Gefahr, dass Änderungen bei Updates verloren gehen. Doch zuvor besteht die Gefahr, dass man die Struktur dieser Datei versehentlich durch die Änderungen zerstört:
Achtung: Vorher eine Kopie der Orignal-Version von MonoBook.php erzeugen und sichern.
Ausblenden von Items in der Fußzeile:
- Alle nicht gewünschten Items wurden mit Kommentar /* */ ausgeklammert
- Nur disclaimer (=Impressum) blieb erhalten:
$footerlinks = array( /*'lastmod', 'viewcount', 'numberofwatchingusers', 'credits', 'copyright',*/ /*'privacy', 'about',*/ 'disclaimer', /*'tagline',*/ );
Ausblenden des Werkzeuge-Menüs für nichtangemeldete Nutzer:
- Finden des folgenden Abschnitts (Suchen nach p-tb):
<div class="portlet" id="p-tb"> <h5><?php $this->msg('toolbox') ?></h5>
- Ersetzen durch die folgenden Zeilen:
<div class="portlet" id="p-tb"> <?php if($this->data['loggedin']) { ?> <h5><?php $this->msg('toolbox') ?></h5>
- Weiter unten steht das Ende des soeben editierten div-Blockes. Dort sucht man folgenden Abschnitt:
wfRunHooks( 'MonoBookTemplateToolboxEnd', array( &$this ) ); ?> </ul> </div> </div>
- Dort ergänzt man die Zeile (zwischen den beiden /div), welche das neue "if"-Statement schließt:
wfRunHooks( 'MonoBookTemplateToolboxEnd', array( &$this ) ); ?> </ul> </div> <?php } ?> </div>
Ausblenden der Register-Tabs für nichtangemeldete Nutzer:
Man sucht in "MonoBook.php" die folgende Zeile:
foreach($this->data['content_actions'] as $key => $tab) {
und fügt unmittelbar nach "$tab)" die fett markierte Bedingung ein:
foreach($this->data['content_actions'] as $key => $tab) if($this->data['loggedin']==1) {
Datei-Upload mit PHP
Die max. Größe für den PHP-unterstützten Upload einer Datei muss man in php.ini-Dateien festlegen. Im Beispiel wird für das Wiki-System die Version PHP 5.2.17 (cgi-fcgi) verwendet:
- Auf einem eigenen Server müsste man in den Dateien /etc/php5/apache2/php.ini und /etc/php5/cli/php.ini die Begrenzung z.B. auf 200 MByte ändern:
upload_max_filesize = 200M
- Der Wert soll im Beispiel so groß sein, weil die vorhandenen Datenbank-Inhalte des alten Wiki-Systems wahrscheinlich über das PHP-Webinterface hochgeladen werden müssen.
Damit man auf die erforderliche Ordner mit den php.ini-Dateien Zugriff erhält, muss man sich mittels SSH verbinden:
- Im Ordner \opt\RZphp52\etc\ findet man die Datei php.ini. Darin modifiziert man in einer lokalen Kopie die vorhandene Zeilen von 10M auf 200M:
post_max_size = 200M upload_max_filesize = 200M
- Leider hat man keine Schreibrechte auf die Originaldatei, so dass man hier nicht weiter kommt!
- Zumindest für das Wiki-System kann man die maximal hochladbare Dateigröße anpassen, indem man die lokale Kopie von php.ini per FTP-Zugriff in das Wurzelverzeichnis des Wiki-Systems speichert (dort, wo auch LocalSettings.php liegt). Auf der Hochlade-Seite wird im Wiki-System der erhöhte Größenwert dann angezeigt und das Hochladen von Dateien > 10MB funktioniert dann!
Für das Wiki-System muss man zusätzlich die Konfiguration der Datei-Größe über LocalSettings.php vornehmen:
- Das deaktivierte Upload:
$wgEnableUploads = true;
- wurde ersetzt durch folgende Beschreibung, welche zusätzlich die Ordnerstruktur und erlaubte Inhalte spezifiziert:
$wgEnableUploads = true; $wgMaxUploadSize = 1024*1024*200; # 200MB $wgUploadSizeWarning = 1024*1024*10; # 10MB $wgUseImageResize = true; $wgUseImageMagick = true; $wgImageMagickConvertCommand = "/usr/bin/convert"; $wgFileExtensions = array( 'png', 'gif', 'jpg', 'jpeg', 'zip', 'pdf', 'hlp', 'swf', 'wmv' ); ## erfordert Directories images/archive, images/thumb and images/temp (all writable) $wgHashedUploadDirectory = false; # nicht Bilder-Verzeichnisstruktur "/a/ab/foo.png" verwenden
Hinweis zu Filetypen:
- svg Bildertyp in dieser MediaWiki-Konfiguration nicht darstellbar
- zip wird anderweitig als unzulässig blockiert, auch wenn in obiger Liste!
Die für LaTex erforderlichen texvc-Komponenten befinden sich bereits im Ordner math. Man muss in der zugehörigen Zeile in LocalSettings.php die Variable auf true setzen:
$wgUseTeX = true; # erfordert Directory images/math
- Nach dem Aktualisieren der LocalSettings.php sollte man die erforderliche Ordner anlegen und das Hochladen eines Bildes bzw. das Erstellen einer Formel testen. Beim Hochladen eines Bildes wird auch die maximal mögliche Dateigröße angezeigt.
- Leider funktionierte LaTex nicht (Parser-Fehler: texvc-Programm wurde nicht gefunden!).
Vorhandene Datenbank importieren
Auf den ersten Blick findet man nur das Exportieren von datenbanken. Aber laut Aussage des STRATO-Supports geht es:
"Ich kann Sie beruhigen, der Karteireiter wurde nicht entfernt. Sie können Daten importieren, wenn Sie in dem Phpmyadmin links oben auf das kleine eckige Symbol "SQL" klicken. Es geht dann in einem Popupfenster ein kleines Fenster auf mit dem Karteireiter "Dateiimport". Der andere Weg ist, wenn Sie auf der linken Seite oben auf den Datenbankbezeichner DB... klicken und im mittleren Bereich auf den Karteireiter "SQL"."
Das funktioniert, aber leider scheitert der Import dort jedoch vorläufig an der maximalen Dateigröße: 2.048KB!