Skip to main content

CMS Installation - Voraussetzungen

Drupal LogoIch will mit diesem Artikel aufzeigen, was mir wichtig erscheint um eine Homepage mit Joomla! oder mit Drupal zu erstellen und damit die ersten Schritte mit einem CMS zu machen. Ein CMS bietet natürlich viel mehr Möglichkeiten als bei esmeralda.at oder auf dieser Homepage verwendet wurden, aber das werde ich erst dann ergänzen, wenn ich es in der Praxis auch ausprobiert habe.

Joomla LogoEs geht nicht um eine detaillierte Installationsanleitung für ein CMS. Davon gibt es im Web einiges, wie z.B. für Drupal das Benutzerhandbuch des deutschen Drupalcenters oder die englische Dokumentation bei drupal.org oder das Joomla! Official Documentation Wiki. Mir ging es dabei meist so, dass ich alles möglich fand, nur das nicht, das ich für meine ersten Schritte suchte. Zu Drupal 5 gibt es auch das Buch von von Hagen Graf bei Addison Wesley kostenlos als E-Book zum Download. Das will man aber auch nicht im Detail am Anfang lesen, wenn man nicht weis, ob Drupal überhaupt das ist, was man sucht. „Joomla! Das Handbuch für Einsteiger“ von Anja Ebersbach, Markus Glaser, Radovan Kubani (Galileo Computing) kann man online lesen.

Ich setze hier die Dinge voraus, die ich nicht erkläre (LOL). Wie man mit einem Webspace arbeitet, hängt natürlich auch vom Betriebssystem und den Programmen, die zur Verfügung stehen, ab. Da Webserver meistens unter einem Unix-/Linux-Betriebssystem laufen, erleichtern Basiskenntnisse mit einer Linux-Shell die Administration, wenn es Probleme gibt und ich war sehr froh, dass ich einen Shell-Zugang für meine 1. Installation hatte.

Ich empfehle also, dass man sich unbedingt einen Web-Hoster sucht, der einen Shell-Zugang bietet. Oft wird cpanel zur Administration.verwendet, das mir beim Restore schon ziemlich Kopfzerbrechen mit den Rechten machte. Auch muss man bei cpanel-Backups rechnen, dass man plötzliche unbrauchbare Backups hat, nachdem alles viele Monate gut funktioniert hat! Es bleibt nur die Alternative  nach jedem Backup zu prüfen(!), ob die MySQL-Sicherung (mysqldump) brauchbar ist oder ob da vielleicht nur eine Fehlermeldung und sonst nichts enthalten ist. Das public_html-Verzeichnis muss man auch nach jedem Backup entpacken und prüfen, ob das Ergebnis brauchbar aussieht.. Natürlich ist das aufwendig, aber ich sehe dazu keine Alternative. Ich kenne jemanden, der regelmäßig gesichert hat, aber dann mit kaputter Sicherung da stand, als der Hoster gehackt wurde. Bei Drupal sollte man sich garantieren lassen, dass für PHP 128MB kurzfristig bei der Konfiguration der Module zur Verfügung stehen, 92MB reichen vielleicht auch noch, wenn man in Etappen Module aktiviert.

Wenn man es sich zutraut, dann sollte es man sich sehr überlegen einen VPS (virtual private server) zuzulegen, da hat man root-Rechte und braucht sich nicht über cpanel ärgern, oder dass der Hoster rumpfuscht. Allerdings ist man dann auch selber für die Sicherheit verantwortlich.  Ein VPS mit Drupal sollte mindestens 256MB RAM +128MB für kurzfristige Nutzung., haben, vemutlich wird man mehr brauchen. Mit 192MB RAM wurde bei der Installation die Datenbenk zerschossen. Sehr guten Support hat zB Ramhost, aber auch Panix hat interessante Angebote.

Ich bin mir auch nicht sicher, ob es Konflikte mit anderen Anwendungen gibt, die auch eine Rewrite-Engine (mod_rewrite) verwenden, also zB eine Foto-Galerie wie die Menalto-Gallery oder ein 2. CMS wie Joomla! für eine Addon-Domain in einem Unterverzeichnis.

Dies kann man leicht vermeiden, wenn man sich einen Reseller-Account besorgt, der gar nicht so teuer sein muss. Man muss ja nicht zwingend die Accounts an Fremde weiterverkaufen, man kann ja auch sein eigener Wiederverkäufer sein oder den Zugang mit Freunden teilen und hat dadurch mit WHM wesentlich bessere Konfigurations- und Administrationsmöglichkeiten. US-Hoster haben meist keine komplizierten Konditionen wie bei deutschen und österreichischen Webspace-Hostern. Alles ist unbegrenzt bis auf den Webspace und die Bandbreite. Wenn ich z.B. noch eine MySQL-Datenbank brauche, dann lege ich die mir selber an und werde nicht extra zur Kasse gebeten. Ähnliches gillt für die Anzahl der Email-Adressen, weitere Domains, usw. Man sollte skeptisch sein bei Superpreisen mit riesigem Webspace, das sowieso nur dazu führt, dass der mögliche Webspace dann als Datengrab genutzt wird und alles sehr langsam wird.

Ich warne vor Anbietern, die alles „unlimited“ haben und deutlch unter $10 liegen. Das gibt bald großen Ärger und man fängt von vorne an. (You get what you pay for). Eine Ausfallstatistik meines Servers ist bei key.priv.at verlinkt. Wenn man liest, dass es von Januar bis September 2008 10 Ausfälle dieses Web-Servers (und ein Hoster betreibt natürlich mehrere Server) bei einer „Uptime“ von 99.814% gab, dann muss man sich klar darüber sein, was gemessen wurde. Wenn der MySQL-Server „down“ ist, dann merkt das ein Service wie siteuptime nicht und ebenso, wenn der Server unbrauchbar langsam ist. „Average response time: 0.390 seconds“ liest sich zwar auch gut, wenn man aber manchmal für ein paar Minuten 30 Sekunden warten muss bis etwas passiert, dann hat man einen anderen Eindruck. Ich habe das aber selten erlebt und danach war es wieder sehr schnell. Vermutlich hat gerade ein Backup das System langsam gemacht. In der Praxis gab es daher sicher mehr Probleme als siteuptime vermuten lässt. Nach ein paar Monaten merkt man zerknirscht, dass der so billige Hoster mit den vielen Versprechungen auch für private Zwecke nicht brauchbar ist und man sich einen neuen Hoster suchen muss. Webspace-Rankings sind jedenfalls mit großer Vorsicht zu genießen.

Für die Installation von Drupal kann es passieren, dass „PHP register globals“ in der .htaccess  mit  „php_flag register_globals off“ deaktiviert werden und „PHP-Memory“ erhöht werden muss  Zu wenig „PHP-Memory“ kann kritisch werden und ein Hoster der nicht bereit ist, das System entsprechend zu konfigurieren, ist nicht brauchbar. Es hängt natürlich auch mit der Anzahl der Module zusammen, aber die Module können im Laufe der Zeit mehr werden und dann sind die Probleme unvermeidlich.

Konqueror-Logo (GPL)Ich gehe bei meinen Erklärungen davon aus, dass ein Shell-Zugang existert, cpanel als Konfigurationswerkzeug zur Verfügung steht und die Installation mit einem Linux-Rechner erfolgt, auf dem Konqueror zur Verfügung steht. Nutzer anderer Betriebssysteme müssen sich gleichwertige Möglichkeiten mit ihrem Betriebssystem suchen. Manchmal schlage ich Lösungen für Windows-Benutzer vor.

Konqueror bietet über fish:// die Möglichkeit eine verschlüsselte Verbindung via ssh aufzubauen und das entfernte Dateisystem wie ein lokales Dateisystem zu verwenden. Man gibt also im Konqueror „fish://user@domain.tld“ ein, wird nach dem Login-Namen und Passwort gefragt, lässt die digitale Brieftasche KWallet das Passwort speichern und hat in Zukunft den Webspace wie einen lokalen Speicherplatz zur Verfügung ohne jedes Mal nach dem Passwort beim Hoster gefragt zu werden. Ich muss auch gleich warnen, dass die Übertragung von vielen kleinen Dateien, wie z.B. bei der Installation, mit fish:// sehr lange dauert. Für viele Dinge ist fish:// aber sehr praktisch. Viele kleine einzelne Dateien überträgt man besser gepackt mit scp oder auch fish:// und entpackt sie via ssh und Shell beim Hoster.

Ich kenne unter Windows nichts vergleichbares und denke, dass man für die Installation am besten WinSCP und Putty verwendet. Irgendwie ist es sicher auch mit einem FTP-Programm und ohne Shell-Zugang zu schaffen, aber das dauert dann viele Stunden länger, wenn man tausende kleine Dateien per FTP einzeln überträgt. Ohne Shell-Zugang macht mir ein Webspace keinen Spaß.

 

(Fortsetzung folgt)