Installation und Einrichtung von Drupal6, PHP5, PostgreSQL, Apache2, phppgadmin, Suchmaschinenfreundlichen URL’s und deutscher Lokalisierung als 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.

Installation der benötigten Pakete

Die folgenden Pakete werden benötigt:

  • apache2 - Der Apache Webserver in der Version 2
  • libapache2-mod-php5 - Das Apache-Modul für PHP5
  • php5 und php5-common - Den PHP-Interpreter
  • php5-gd - Die GD Grafikbibliothek für PHP5
  • php5-pgsql - Das PHP-Modul für den Zugriff auf die PostgreSQL Datenbank
  • php5-cli - PHP für die Kommandozeile, benötigt von drush
  • postgresql-8.1 - Der PostgreSQL Datenbankserver
  • phppgadmin - Webbasiertes Administrationswerkzeug für PostgreSQL(ähnlich phpmyadmin für mysql)

Die eigentliche Installation:

aptitude install apache2 libapache2-mod-php5 php5 php5-common php5-pgsql php5-gd php5-cli postgresql-8.1 phppgadmin

Konfiguration

Grundlegende Konfiguration

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.

su oder mit sudo <BEFEHL>

falls sudo konfiguriert ist.

php memory_limit hochsetzen

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.

memory_limit = 64M ; Maximum amount of memory a script may consume (16MB)

Installation der clean-urls

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:

a2enmod rewrite

Neustart von Apache2

Damit die voherigen Änderungen wirksam werden, starten wir Apache erneut.

/etc/init.d/apache2 force-reload

Testen der Installation

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.

echo -e "<php\n phpinfo();\n?>" > /var/www/index.php

Anschließend rufen Datei index.php mit der URL unseres Webservers ü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.

Einrichtung der Datenbank

Damit der Benutzerwechsel funktioniert, machen wir uns zu root. su

Um die folgenden Befehle auszuführen starten wir eine Shell unter der Identität von postgres

su 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

createuser -P -S -R -E datenbankbenutzer

Anlegen der Datenbank mit UTF-8 Kodierung,-E oder --encoding- für den durch -O oder --owner spezifizierten Benutzer.

createdb -E UNICODE -O datenbankbenutzer datenbankname

Anschließend exit um die Shell von postgres zu beenden,

exit um auch die Rootshell wieder zu verlassen, damit wir die nächsten Schritte als normaler Benutzer auszuführen.

Drupal installieren

Damit wir uns definitiv in unserem Home-Directory befinden: cd

Anlegen des Verzeichnisses welches später unser Drupal-Instanzen enthält,

mkdir drupal

Verzeichniswechsel nach drupal,

cd drupal

runterladen der deutschen 6er Version von drupalcenter.de,
(natürlich ist 6.4 durch die momentan aktuelleste Version von Drupal zu ersetzten)

wget http://www.drupalcenter.de/files/drupal-6.4-DE.tar.gz

entpacken.

tar -xzvf drupal-6.4-DE.tar.gz

Die Drupal Multisite-Umgebung

So soll die Multisiteumgebung später mal aussehen:

drupal/
|-- 6.x -> drupal-6.4
|-- 6.x_modules
|-- 6.x_sites
|   |-- example.com -> example.com.localhost
|   |  |-- files
|   |  |-- modules
|   |  `-- themes
|   `-- example.com.localhost
|      |-- files
|      |-- modules
|      `-- themes
|-- 6.x_themes
`-- drupal-6.4
    |-- backup
    |-- includes
    |-- misc
    |-- modules
    |-- profiles
    |-- scripts
    `-- sites
        |-- all
        |    |-- modules -> ../../../6.x_modules
        |    |-- themes -> ../../../6.x_themes
        |-- example.com -> ../../6.x_sites/example.com
        `-- example.com.localhost -> ../../6.x_sites/example.com.localhost

Anmerkungen

Der Ordner 6.x_backup beziehungsweise der symbolische Link backup in der
Wurzel der Drupal-Installation ist drush-spezifisch.

Seit Commit 16a4e2b3cf0420a7dce7d3ed79f6701bdd97e095 auf Drush nicht mehr möglich:

Force to use a location for backups outside the drupal root.

Der Ordner 6.x_sites beziehungsweise der symbolische Link sites beinhaltet die einzelnen Sites und deren Daten.

Seit dem Fix von Issue #694708 auf drush_multi, behandle ich profiles analog zu sites.

Mulisiteumgebung vorbereiten

Erstellung des symbolische Links auf die Wurzel der Drupal-Installation, welche später in unserem VirtualHost die DokumentRoot darstellt .

```ln -s drupal-6.4-DE 6.x´´´

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.

mkdir 6.x_sites 6.x_backups

Verschieben der Ordner drupal-6.4-DE/sites/all und drupal-6.4-DE/sites/default nach 6.x_sites.

mv drupal-6.4-DE/sites/* 6.x_sites </div>

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.

rmdir drupal-6.4-DE/sites```
cd drupal-6.4-DE
ln -s ../6.x_sites sites
ln -s ../6.x_backup backup
cd ..

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/)

mkdir 6.x_sites/all/modules 6.x_sites/all/themes

Eintrag in /etc/hosts

Damit unsere zukünfige Seite über einen FQDN erreichbar ist, erweitern wir die Datei /etc/hosts um die folgende Zeile:

127.0.0.1 example.com.localhost

Konfiguration von Apache

Einrichtung der Virtual-Hosts und Absichern der Installation.

Um die Apache-Direktiven und den Virtual-Host anzulegen benötigen wir wieder erhöhte Privilegien.

sudo su oder su

Drupal und .htaccess

Damit die von Drupal benutzte .htaccess funktioniert legen wir die Datei /etc/apache2/conf.d/drupal.conf mit folgendem Inhalt an:

<Directory /home/foobar/drupal/>
  Options +FollowSymLinks Indexes
  AllowOverride All
  order allow,deny
  allow from all
</Directory>

Drupals cron.php absichern

Um Drupals cron.php vor unberechtigtem Zugriff zu schützen, tragen wir in /etc/apache2/conf.d/drupal.conf noch die folgende Passage ein:

<Files cron.php>
Order deny,allow
Deny from all
Allow from 10.10.10.0/24
Allow from 127.0.0.1
Allow from 1.2.3.4
</Files>

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:

/etc/init.d/apache2 reload

Drupals CHANGELOG.txt absichern

Security by obscurity: <p>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…</p>

<Files cron.php,CHANGELOG.txt>
Order deny,allow
Deny from all
# Zugriff aus dem VPN erlauben
Allow from 10.10.10.0/24
Allow from 127.0.0.1
Allow from 81.169.175.14
</Files>

Aber nach überprüfen der Konfiguration mit

sudo apache2ctl configtest

kam der folgende Fehler:

Syntax error on line 6 of /etc/apache2/conf.d/drupal.conf: Multiple <Files> arguments not (yet) supported.

Zu praktisch gedacht, doch ein eigenes Statement:

<Files CHANGELOG.txt>
Order deny,allow
Deny from all
</Files>

Nachdem der Configtest durchgelaufen ist muss der Webserver neu gestartet werden.

/etc/init.d/apache2 restart

Virtual Host einrichten

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.

<VirtualHost *>
ServerName example.com.localhost
ServerAlias www.example.com.localhost
ServerAdmin foobar@example.com.localhost
DocumentRoot /home/foobar/drupal/6.x
ErrorLog /var/log/apache2/example.com.localhost-error.log
CustomLog /var/log/apache2/example.com.localhost-access.log combined
</VirtualHost>

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.

a2ensite example.com.localhost.conf

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.

Einrichtung einer Site

Um als wieder Benutzer weiterzumachen: exit

Wechsel in das 6.x_sites Verzeichnis:

cd
cd drupal/6.x_sites/

Anlegen eines Verzeichnisses für die erste Site,

mkdir -p example.com.localhost/files

Das Verzeichnis files für den Webserver schreibbar machen:

chmod 775 example.com.localhost/files

An dieser Stelle explizit kein su - um auch in diesem Verzeichnis zu bleiben. su

chgrp www-data example.com.localhost/files
exit

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

ln -s example.com.localhost example.com

Für Module und Themes, die nur für unsere Subsite verfügbar sein sollen legen wir noch die folgenden 2 Verzeichnisse an:

mkdir example.com.localhost/themes example.com.localhost/modules </div>

Jetzt brauchen wir noch die settings.php, welche die Einstellungen für unser Site enthalten wird.

cp default/default.settings.php example.com.localhost/settings.php </div>

Jetzt können wir mit unsere Browser unter example.com.localhost aufrufen und kommen zur Installationsroutine von Drupal.

Updates der Multisite-Umgebung

Drupal Update in 8 Schritten

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.

1) Runterloaden der neuen Drupal-Version

Download der neuen Drupal-Version in das Verzeichnis in dem sich die auch die alte Drupal-Version befindet.

wget <a href="http://ftp.osuosl.org/pub/drupal/files/projects/drupal-6.10.tar.gz

2) Entpacken des Drupal-Tarballs

tar xfz drupal-6.10.tar.gz

3) sites Ordner löschen
cd drupal-6.10
rm -r sites
ln -s ../6.x_sites sites
ls -l
lrwxrwxrwx 1 florian server  12 2009-02-27 10:13 sites -> ../6.x_sites
ln -s ../6.x_backup backups
ls -l
rwxrwxrwx 1 florian server  13 2009-02-27 10:19 backups -> ../6.x_backup
cd ..
unlink 6.x
ln -s drupal-6.10 6.x
ls -l
lrwxrwxrwx 1 florian server   11 2009-02-27 10:22 6.x -> drupal-6.10
8) update.php als User 1 aufrufen

Falls aktiviert, den Maintanance-Modus abschalten und Voila!

drush_multi: Drupal Multisite Updates mit nur einem Befehl

Drush Multi ist eine Erweiterung für die Drupal Shell aka drush. Die eigentliche Kernkomponente, welche aus einem Shellskript hervorgegangen ist behandelt Drupal-Updates von Drupal-Multisite-Umgebungen.

drush multi-drupalupdate

Aktualisiert die Installation falls es (Minor-)Updates auf den Drupal-Core gibt.

Einfaches multi-drupalupdate...

drush -r /path/to/drupal multi-drupalupdate

multi-drupalupdate mit ein paar zusätzlichen Optionen...

drush -r /path/to/drupal multi-drupalupdate --sql-dump --comment='Vor Aktualisierung auf Drupal 7.12' --updatedb

Führt ein multi-drupalupdate auf /path/to/drupal aus

  1. Sichert die Datenbanken aller Sites, mit einem optionalem Kommentar im Dateinamen, über --sql-dump und --comment Option
  2. Versetzt alle Sites in den Wartungsmodus, über --updatedb Option
  3. Download des Drupal-Cores
  4. Ersetzung der Drupal-Verzeichnisse und Dateien durch symbolische Links, die in der aktuellen Installation gefunden wurden, wie z.B. sites, profiles, .htaccess, etc
  5. Umbiegen des symbolischen Links auf die neue Drupal-Root
  6. Ausführung von ggf. anstehenden Drupal-Datenbank-Updates
  7. Beenden des Wartungsmodus

Besonderheiten

Weitere Befehle in drush_multi

Während der ArByte an dem eigentlichen Kernstück multi-drupalupdate sind noch andere Dinge entstanden...

  • drush multi-status
    • Ein erweiterter drush core Status
  • drush multi-site
    • Legt eine Site innerhalb der Multisite-Installation an
  • drush multi-create
    • Erzeugt eine Drupal-Multisite-Installation nach dem beschriebenem Schema, unterstützt zudem die Benutzung von drush_make makefiles
  • drush multi-exec
  • drush multi-sql-dump
    • Ein erweiterter sql dump, welcher z.B. die Datenbank auch tabelleweise sichert, bzip2-Kompremierung ermöglicht (Recheninternsiver aber besser Kompremierung).
  • drush multi-nagios
    • Zur Benutzung als Nagios/Icinga plugin um Drupal-Sites und Drupal-Installations zu überwachen

      Nach drush_nagios ausgelagert

Dokumentation

Drush in einer Multisite-Umgebung

Um drush in einer Multisiteumgebung zu arbeiten, haben sich folgende Mechanismen als nützlich erwiesen:

Drush-Alias für Multisite

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.

alias drush5_='/usr/local/bin/drush/drush -r /home/drupal/5.x '
alias drush6_='/usr/local/bin/drush/drush -r /home/drupal/6.x '

Verwendung von drush in der Multisiteumgebung

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.

drush6_ -l example.com pm-refresh

Für 5.x ist das Modul Update Status Voraussetzung für die Aktionen pm-refresh (rf) und pm-update (up).

sites/all/modules & sites/example.com/modules

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.