Installation und Einrichtung von
in einer Multisiteumgebung auf einem lokalen Rechner unter Debian 4(etch).
Verwendet wurden die Pakete PHP5 in der Version 5.2.0-8+etch11 und apache2 in der Version 2.2.3-4+etch5, drupal in der Version 6.4 in deutsch von drupalcenter.de und PostgreSQL in der Version 8.1.11
Die folgenden Pakete werden benötigt:
Die eigentliche Installation:
Installation und Konfiguration der von Drupal benötigten PHP-Module, die nötigen Schritte um Suchmaschinenfreundlichen URL's nutzen zu können und das Hochsetzen der memory_limit-Direktive.
Die folgenden Schritte sind unter der ID von root auszuführen.
oder mit
falls sudo konfiguriert ist.
Um einem "White-Screen" vorzubeugen wenn zu viele Drupal-Module installiert sind,
setzen wir die memory_limit in /etc/php5/apache2/php.ini höher.
Um das Feature der Suchmaschinenfreundlichen URL's(clean-url's) nutzen zu können, muß noch das mod_rewrite-Modul aktiviert werden. Hier werden die symbolischen Links von /etc/apache2/mods-available nach /etc/apache2/mods-enabled gesetzt für die entsprechenden Module gesetzt:
Damit die voherigen Änderungen wirksam werden, starten wir Apache erneut.
Zum testen der Apache-Installation geben wir den FQDN oder die IP-Adrese in Browser ein
und sehen ein It works!
Um zu testen, ob php läuft und alle benötigten Module enthält legen wir eine Datei mit dem Namen index.php im Ordner /var/www an.
Anschließend rufen Datei index.php mit der URL unseres Webservers + /index.html über Browser auf
und sehen in der Sektion apache2handler im Unterpunkt Loaded Modules, mod_rewrite und weiter unten die von Drupal benötigten PHP-Erweiterungen gd und pgsql.
Damit der Benutzerwechsel funktioniert, machen wir uns zu root.
Um die folgenden Befehle auszuführen starten wir eine Shell unter der Identität von postgres
Anlegen des zukünftigen Datenbankbenutzer mit den Optionen:
-P oder --pwprompt für Passwortauthentifizierung
-S oder --no-superuser, Default, deshalb optional
-D oder --no-createdb
-R oder --no-createrole, Benutzer darf keine Rollen anlegen
-E oder --encrypted, Verschlüsselung der Passwörter in der Datenbank
Anlegen der Datenbank mit UTF-8Kodierung,-E oder --encoding- für den durch -O oder --owner spezifizierten Benutzer.
Anschließend
um die Shell von postgres zu beenden,
um auch die Rootshell wieder zu verlassen, damit wir die nächsten Schritte als normaler Benutzer auszuführen.
Damit wir uns definitiv in unserem Home-Directory befinden:
Anlegen des Verzeichnisses welches später unser Drupal-Instanzen enthält,
Verzeichniswechsel nach drupal,
runterladen der deutschen 6er Version von drupalcenter.de,
(natürlich ist 6.4 durch die momentan aktuelleste Version von Drupal zu ersetzten)
entpacken.
So soll die Multisiteumgebung später mal aussehen:
Der Ordner 6.x_backup beziehungsweise der symbolische Link backup in der
Wurzel der Drupal-Installation ist drush-spezifisch.
Der Ordner 6.x_sites beziehungsweise der symbolische Link sites beinhaltet die einzelnen Sites und deren Daten.
Erstellung des symbolische Links auf die Wurzel der Drupal-Installation, welche später in unserem VirtualHost die DokumentRoot darstellt .
Erstellung der Verzeichnisse 6.x_sites, welche später unser die Subsites, Module, und Themes enthalten wird und 6.x_backup, in welchem Sicherheitskopien von Modulen und Themes, welche durch drush aktualisiert worden sind abgelegt werden.
Verschieben der Ordner drupal-6.4-DE/sites/all und drupal-6.4-DE/sites/default nach 6.x_sites.
Ersetzen des Verzeichnisses sites unterhalb von drupal-6.4-DE durch einen symbolischen Link mit relativer Pfadangabe welcher auf 6.x_sites zeigt uns setzen des symbolischen Links für backup.
Erstellung der Verzeichnisse modules und themes, hier sollten seit Drupal 5.x angepasste und runtergeladene Module und Themes abgelegt werden. Diese sind somit auch für die Subsites verfügbar.(Siehe auch README.txt in sites/)
Damit unsere zukünfige Seite über einen FQDN erreichbar ist, erweitern wir die Datei /etc/hosts um die folgende Zeile:
Um die Apache-Direktiven und den Virtual-Host anzulegen benötigen wir wieder erhöhte Privilegien.
sudo su
oder
su
Damit die von Drupal benutzte .htaccess funktioniert legen wir die Datei /etc/apache2/conf.d/drupal.conf mit folgendem Inhalt an:
Um Drupals cron.php vor unberechtigtem Zugriff zu schützen, tragen wir in /etc/apache2/conf.d/drupal.conf noch die folgende Passage ein:
In der ersten Allow-Direktive wird per CIDR-Notation der Zugriff vom kompletten VPN gewährt.
In der zweiten wird der Zugriff von localhost aus erlaubt.
Entscheidend ist aber, daß die IP-Adresse des Server(die 3.te Direktive) gelistet ist, von hier wird cron.php per Cronjob aufgerufen,
Damit unsere /etc/apache2/conf.d/drupal.conf wirksam wird, muß der Webserver auch hier die Konfiguration neu einlesen:
Mein erster Gedanke war, die CHANGLOG.txt mit in Direktive für die Absicherung von Drupals cron.php zu nehmen um diese Datei ebenso vor fremden Blicken zu schützen...
Aber nach überprüfen der Konfiguration mit
kam der folgende Fehler:
Zu praktisch gedacht, doch ein eigenes Statement:
Nachdem der Configtest durchgelaufen ist muss der Webserver neu gestartet werden.
Anlegen der Datei /etc/apache2/sites-available/example.com.localhost.conf,
auch hier ist foobar wieder durch den eigenen Benutzernamen zu ersetzten, DocumentRoot zeigt auf den symbolischen Link, welcher wiederum auf die Wurzel der Drupal-Installation zeigt.
Analog zur Aktivierung des rewrite-Moduls, werden auch hier wieder symbolische Links gesetzt und zwar von /etc/apache2/sites-available nach /etc/apache2/sites-enabled.
Nach den letzten Schritten müssen wir den den Webserver neu starten, damit er seine Konfiguration erneut einließt und die angelegten Direktiven wirksam werden.
Um als wieder Benutzer weiterzumachen:
Wechsel in das 6.x_sites Verzeichnis:
Anlegen eines Verzeichnisses für die erste Site,
Das Verzeichnis files für den Webserver schreibbar machen:
An dieser Stelle explizit kein su - um auch in diesem Verzeichnis zu bleiben.
Gesetz dem Fall, daß example.com irgendwann in den Produktiveinsatz
geht, geben wir diesen bei der Installationsroutine von Drupal den zukünftigen Speicherort für unsere Dateien an(sites/example.com/files)
und setzen hierfür noch einen Symlink
Für Module und Themes, die nur für unsere Subsite verfügbar sein sollen legen wir noch die folgenden 2 Verzeichnisse an:
Jetzt brauchen wir noch die settings.php, welche die Einstellungen für unser Site enthalten wird.
Jetzt können wir mit unsere Browser unter example.com.localhost aufrufen und kommen zur Installationsroutine von Drupal.
Bei einem Drupal Setup wie hier beschrieben, sind nur 8 Schritte für ein Update innerhalb eines Drupal-Zweiges nötig.
Hier wird exemplarisch das Update von Drupal-6.9 auf Drupal-6.10, welches am 27. Februar durchgeführt wurde beschrieben.
Es wird empfohlen die zu aktualisierende Seite in den Wartungsarbeiten-Modus zu versetzen und die Dateien sowie Datenbank im Vorfeld sichern.
Download der neuen Drupal-Version in das Verzeichnis in dem sich die auch die alte Drupal-Version befindet.
Falls aktiviert, den Maintanance-Modus abschalten und Voila!
Um drush in einer Multisiteumgebung zu arbeiten, haben sich folgende Mechanismen als nützlich erwiesen:
An dieser Stelle werden Aliase auf die jeweiligen drush-Version(Symlink) und der auf -r bzw. --root folgenden Wurzel der Drupal-Installation gesetzt.
Alternativ zu Aliasen auf die Drupal-Wurzel, kann dies auch über
drushrc.php, die Konfigurationsdatei für drush erfolgen.
Drush ist in nach /usr/local/share/ installiert worden und das Wrapper-Skript /usr/local/share/drush/drush ist ein Softlink nach /usr/local/bin/drush.
Der Aufruf von drush erfolgt über den angelegten Alias + die Spezifizierung der Subsite,
mittels -l oder --uri="".
Im folgenden Beispiel werden die Informationen über den Status der Seite aktualisiert.
Für 5.x ist das Modul Update Status Voraussetzung für die Aktionen pm-refresh (rf) und pm-update (up).
Wenn sites/all/modules und sites/example.com/modules parallel existieren, installiert drush Module nach sites/all/modules.
Im Falle, das sites/all/modules nicht existiert, dafür aber sites/example.com/modules wird sites/all/modules erstellt und benutzt.
Um trotzdem sites/example.com/modules verwenden zu können existiert in sites/all kein modules Verzeichnis und sites/all ist schreibgeschütz.
Drupal-Multisite-Module
To be continued...