Die ursprüngliche Etherpad-Software ist enorm ressourcenhungrig und die Codebase sehr umfangreich – insbesondere die hohen Anforderungen an den Arbeitsspeicher (im laufenden Betrieb wohl ca. 1 GB!) hielten mich von der Installation auf meinem Server ab. Etherpad Lite hingegen begnügt sich nach eigenen Angaben im laufenden Betrieb mit rund 30 MB Arbeitsspeicher.

Diese Anleitung beschreibt die Installation von Node.js, NPM und Etherpad Lite auf Ubuntu 10.04 Server. Da in den meisten Fällen auf Port 80 eines bestehenden Servers bereits ein Webserver (in meinem Fall Apache) läuft, wird Etherpad Lite hinter Apache als Reverse-Proxy (via mod_proxy) installiert. Sicherlich nicht die beste Lösung, eine “non-blocking” Node.js-Applikation hinter einem “blocking” Apache-Server zu installieren – Nginx wäre hier sicherlich eine bessere Wahl. Aber vorerst soll Apache als Reverse-Proxy genügen. Des weiteren richten wir eine Upstart-Konfiguration ein, die Etherpad Lite nach jedem Reboot automatisch startet.

Installation von Node.js

Zunächst installieren wir Node.js auf dem Server. Die Version in den Ubuntu-Paketquellen ist deutlich zu alt, deshalb müssen wir selbst kompilieren. Da wir Node.js, den Node-Paketmanager NPM und die Applikation aus Sicherheitsgründen unter einem eigenen User installieren möchten, legen wir diesen zunächst an:

groupadd nodejs
useradd -g nodejs -s /bin/bash -d /var/lib/nodejs nodejs
mkdir /var/lib/nodejs
chown nodejs:nodejs /var/lib/nodejs

Nun wurde der User nodejs angelegt, sein Home-Verzeichnis ist /var/lib/nodejs. Nun bereiten wir den User für die Installation von Node.js und NPM vor – wir wechseln in den User nodejs:

su nodejs
cd ~

Der folgende Inhalt muss in die Datei /var/lib/nodejs/.npmrc:

root =    /var/lib/nodejs/.node_modules
binroot = /var/lib/nodejs/local/bin
manroot = /var/lib/nodejs/local/share/man

Die entsprechenden Ordner müssen nun noch angelegt werden:

mkdir ~/local
mkdir ~/local/bin
mkdir ~/local/share
mkdir ~/local/share/man

Nun fügen wir den Ordner ~/local/bin noch zum PATH hinzu – die folgende Zeile muss zum einen in die Datei /var/lib/nodejs/.bashrc, zum anderen einmal in der Shell eingegeben werden:

export PATH=$HOME/local/bin:$PATH

Jetzt installieren wir die notwendigen Abhängigkeiten über apt / aptitude:

sudo apt-get install build-essential python libssl-dev git-core libsqlite3-dev gzip curl

Nun kann Node.js heruntergeladen und kompiliert werden. Dazu “klonen” wir das Git-Repository und checken die letzte stabile Version aus – was spätere Updates erleichtert.

mkdir ~/local/src
cd ~/local/src
git clone git://github.com/joyent/node.git
cd node
git checkout v0.4.12
./configure --prefix=$HOME/local/
make
make install

Installation von NPM

Jetzt ist Node.js installiert – wir benötigen aber noch den Node.js-Paketmanager NPM. Den installieren wir ebenfalls aus den GIT-Quellen:

cd ~/local/src
git clone https://github.com/isaacs/npm.git
cd npm
git checkout v1.0.30
make install

Zu guter letzt legen wir noch einen Symlink an, damit NPM später das Verzeichnis für die Node-Module findet, das wir weiter oben bereits konfiguriert haben:

ln -s ~/local/lib/node_modules ~/.node_modules

Installation von Etherpad Lite

Nun sind endlich die Voraussetzungen gegeben, um Etherpad Lite zu installieren. Dies tun wir ebenfalls aus den GIT-Quellen. Danach rufen wir ein Shell-Script auf, um die Abhängigkeiten zu installieren.

mkdir ~/node-apps
cd ~/node-apps
git clone git://github.com/Pita/etherpad-lite.git
cd etherpad-lite
./bin/installDeps.sh

Jetzt kann die Konfiguration angepasst werden, die sich in der Datei /var/lib/nodejs/node-apps/etherpad-lite/settings.json befindet. Da ich das Etherpad mit MySQL als Datenbank betreiben möchte, kommentiere ich die vorhandene SQLite-Konfiguration aus und füge den MySQL-Benutzer und den Datenbank-Namen hinzu, die ich beide vorher angelegt habe. Den “loglevel” setze ich außerdem auf “WARN”, um nicht zu viele unnötige Log-Meldungen zu schreiben.

Jetzt legen wir gleich eine Upstart-Konfiguration an, um sicherzustellen, dass das Etherpad nach jedem System-Neustart automatisch gestartet wird. Für eine regelmäßige Überwachung und ggf. Neustart des Etherpads im Fehlerfalle bietet sich Monit an – was aber nicht Teil dieses Artikels sein soll.

Wir legen nun die Datei /etc/init/etherpad-lite.conf mit folgendem Inhalt an (auf Grundlage dieser Quelle):

description "etherpad-lite"
 
start on started networking
stop on runlevel [!2345]
 
env NODEBIN=/var/lib/nodejs/local/bin/node
env EPHOME=/var/lib/nodejs/node-apps/etherpad-lite
env EPLOGS=/var/log/etherpad-lite
env EPUSER=nodejs
 
pre-start script
    chdir $EPHOME
    mkdir $EPLOGS                              ||true
    chown $EPUSER:admin $EPLOGS                ||true
    chmod 0755 $EPLOGS                         ||true
    chown -R $EPUSER:admin $EPHOME/var         ||true
#    exec su -s /bin/bash -c 'exec "$0" "$@"' $EPUSER $EPHOME/bin/installDeps.sh >> $EPLOGS/error.log || { stop; exit 1; }
end script
 
script
  cd $EPHOME/node
  exec su -s /bin/bash -c 'exec "$0" "$@"' $EPUSER $NODEBIN server.js \
                        >> $EPLOGS/access.log \
                        2>> $EPLOGS/error.log
end script

(Diese Upstart-Konfiguration ist noch nicht optimal – spontan gelang es mir nicht, das Shell-Script installDeps.sh im pre-start erfolgreich auszuführen. Deshalb muss man daran denken, dieses Script nach einem Etherpad-Update manuell auszuführen.)

Jetzt kann Etherpad ganz einfach mittels

start etherpad-lite

gestartet werden.

Einrichtung des Apache Reverse-Proxys

Nun richten wir Apache ein, damit Etherpad auf Port 80 erreichbar ist. Dafür verwenden wir z.B. die Subdomain etherpad.example.lit – und folgende virtuelle Host-Konfiguration (beispielsweise in der Datei /etc/apache2/sites-available/etherpad.example.lit):

<virtualhost *:80>
        ServerName etherpad.example.lit
 
        ServerAdmin webmaster@localhost
 
        <ifmodule mod_proxy.c>
            ProxyVia On
            ProxyRequests Off
            ProxyPass / http://localhost:9001/
            ProxyPassReverse / http://localhost:9001/
            ProxyPreserveHost on
            <proxy *>
                Options FollowSymLinks MultiViews
                AllowOverride All
                Order allow,deny
                allow from all
            </proxy>
        </ifmodule>
 
        ErrorLog /var/log/etherpad-lite/apache2/error.log
 
        # Possible values include: debug, info, notice, warn, error, crit,
        # alert, emerg.
        LogLevel warn
 
        CustomLog /var/log/etherpad-lite/apache2/access.log combined
        ServerSignature Off
</virtualhost>

Wichtig: das Verzeichnis /var/log/etherpad-lite/apache2/ für die Apache-Logs muss angelegt werden!

Daraufhin kann der oben angelegte virtuelle Apache-Host aktiviert werden. Außerdem müssen die Apache-Module mod_proxy und mod_proxy_http aktiviert sein, danach kann die Apache-Konfiguration neu geladen werden:

a2ensite etherpad.example.lit
a2enmod proxy proxy_http
/etc/init.d/apache2 reload

Nun sollte das Etherpad unter http://etherpad.example.lit erreichbar sein!

Konfiguration von Logrotate

Wir haben nun einige Log-Dateien unterhalb von /var/log/etherpad-lite/, die schnell sehr groß werden können. Deshalb konfigurieren wir Logrotate so, dass diese Dateien wöchentlich rotiert und gepackt und für acht Wochen vorgehalten werden. Dazu fügen wir einfach folgende Zeilen zur /etc/logrotate.conf hinzu – oder legen eine /etc/logrotate.d/etherpadlite mit dem folgenden Inhalt an:

# rotate etherpad lite logs
/var/log/etherpad-lite/*.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
}
/var/log/etherpad-lite/apache2/*.log {
        weekly
        missingok
        rotate 8
        compress
        notifempty
}

Installation von Abiword für Import/Export (optional)

Für den erweiterten Import/Export muss die Textverarbeitungs-Software Abiword installiert werden – deren Binaries benutzt Etherpad zum Lesen und Schreiben von Dokumenten. In Ubuntu 10.04 ist Abiword in den Paketquellen vorhanden, deshalb reicht ein:

apt-get install abiword

Daraufhin muss in der /var/lib/nodejs/node-apps/etherpad-lite/settings.json der Pfad zum Abiword-Binary angepasst werden:

/* This is the path to the Abiword executable. Setting it to null, disables abiword.
     Abiword is needed to enable the import/export of pads*/
  "abiword" : "/usr/bin/abiword",

Nach einem Neustart mittels

stop etherpad-lite
start etherpad-lite

stehen die erweiterten Import-/Export-Funktionen zur Verfügung – dann kann ein Pad beispielsweise auch als PDF exportiert werden.

Abschluss

Etherpad Lite ist meiner Meinung nach ein sehr nützliches Tool, um gemeinsam Dokumente zu bearbeiten, Protokolle und To-Do-Listen zu erstellen usw. – was durch die Export-Funktion in viele Formate sehr gut ergänzt wird. Es existieren auch bereits viele Bibliotheken und Plugins, welche die HTTP-API von Etherpad nutzen, um Etherpads in eigenen Applikationen bequem einzubinden – Libraries für Ruby, PHP, ein jQuery-Plugin, ein Drupal-Modul (im Entwicklungsstadium) und viele mehr.

Ein Hinweis zum Schluss: diese Anleitung stellt sicher kein Optimum dar – jedoch war es mir wichtig, Node.JS sowie NPM nicht als root-User zu installieren. Deshalb weicht diese Anleitung zum Teil von den meisten im Netz zu findenden Anleitungen ab. Verbesserungsvorschläge nehme ich gern per Kommentar oder E-Mail entgegen!

Quellen und weiterführende Links:

• Ein besseres Etherpad dank Etherpad Lite!
• Building and Installing Node.js
• Etherpad Lite Readme
• Node.js HOWTO: Install NPM as user (not root)
• Install Etherpad Lite on Ubuntu and Debian
• npm install locally
• How to put Etherpad Lite behind a reverse Proxy
• Deploying Node.js With Upstart and Monit
• Run Node.js as a Service on Ubuntu
• How to deploy Etherpad Lite as a service

Abhilfe gibt es theoretisch bereits seit mehreren Jahren: Server Name Indication (SNI) ist eine Erweiterung des SSL-Protokolls, bei der einfach bereits beim Verbindungsaufbau vor dem SSL-Handshake der gewünschte Hostname mitgesendet wird.

Serverseitig benötigt diese Erweiterung insbesondere OpenSSL ab Version 0.9.8f sowie Apache ab 2.2.12 – außerdem müssen beim Kompilieren diverse Flags gesetzt sein. Seit Ubuntu 9.10 “Karmic Koala” sind sämtliche Voraussetzungen erfüllt, ich habe SNI nun erstmalig problemlos mit 10.04 “Lucid Lynx” im Einsatz. SNI funktioniert mit Apache und OpenSSL nun ohne Neu-Kompilieren “out of the box”.

Die Vorgehensweise ist im Prinzip ganz einfach: nach einem

NameVirtualHost *:443

können in den Apache-Konfigurationsdateien mehrere virtuelle SSL-Hosts definiert werden, die jeweils eigene SSL-Zertifikate besitzen. Weitere Infos sind im Apache-Wiki sowie hier zu finden.

Eine weitere Option erlaubt das Erzwingen von SNI: übermittelt ein Client nicht die SNI-Header, kann er den jeweiligen virtuellen SSL-Host nicht erreichen. Diese Option ist standardmäßig auf “off”.

SSLStrictSNIVHostCheck on

Der Haken: neben dem Server muss natürlich auch der Client SNI unterstützen. Internet Explorer unter Windows XP unterstützen SNI generell nicht (wobei es Berichte gibt, dass mit XP SP3 die Unterstützung vorhanden ist), Konqueror beherrscht SNI ebenfalls nicht. Ein Überblick über die Browser-Unterstützung findet sich hier. Ob ein Browser SNI unterstützt, kann man bei sni.velox.ch testen.

Zumindest in einigen Bereichen kann man SNI trotz der teilweise fehlenden Client-Kompatibilität bereits einsetzen – die client-seitige Unterstützung wird sich in Zukunft weiterhin verbessern.

Ein Artikel zum Thema ist in der c’t 23/09 erschienen und ebenfalls bei sni.velox.ch zu finden.

Nach meinem Upgrade konnte ich leider Permalinks zu Artikeln nicht mehr erreichen (das offizielle Theme gibt eine 404er-Fehlermeldung), die Übersicht samt Paging und Permalinks zu Kategorien und Tags sowie “Seiten” waren erreichbar.

Zur Erklärung: ich verwendete keine mod_rewrite-Permalinks, sondern die PATHINFO-Permalinks im Stil

http://www.kallensee.info/journal/index.php/2008/08/22/test-beitrag

Nur bei diesen Permalinks, in denen die index.php vorkommt, tritt auch der Fehler auf.

Das Problem ist auch bereits bekannt. Ein Workaround wäre, in der Konfiguration unter Permalinks für Tags und Kategorien eine “Basis” einzutragen (ganz unten). Dadurch ändern sich allerdings Links zu Tags und Kategorien.

Ich habe den Bug gleich dazu genutzt, meine Permalinks auf die mod_rewrite-Variante umzustellen und von unnötigen Informationen zu bereinigen. Der SEO Blog brachte mich auf den Gedanken, dass die Datumsangabe in der URL ziemlich unnötig ist.

Das neue Permalink-Schema für Artikel ist deutlich schlanker als zuvor:

http://www.kallensee.info/journal/test-beitrag

Jetzt ist es natürlich an der Zeit, sich um die alten URLs zu kümmern. Alle Links – bis auf die Beitrags-Permalinks – werden von WordPress automatisch vom alten Format auf die neue Link-Struktur umgeleitet – Tags, Archive usw. Wichtig sind natürlich aber vor allem die Beitrags-Permalinks – die ja bei Google und anderen Blogs noch im alten Permalink-Format vorliegen. Damit die nicht auf einer Fehlerseite landen, habe ich in meine Apache-Konfiguration für den entsprechenden Host eine RedirectMatch-Direktive eingefügt:

RedirectMatch permanent ^/journal/index.php/200(6|7|8)/[0-9][0-9]/[0-9][0-9]/([A-Za-z0-9-/#]*) http://www.kallensee.info/journal/$2

Diese Direktive leitet alle Anfragen auf Beiträge des alten URL-Formats auf das neue Format um. Im Test werden aber alle URL’s korrekt umgeleitet. Wichtig: durch den Parameter “permanent” erfolgt die Weiterleitung mit dem HTTP-Statuscode 301, auf Deutsch: dem Anfragenden wird neben der neuen Adresse mitgeteilt, dass die Seite permanent “verzogen” ist. Für Suchmaschinen äußerst wichtig zu wissen.

Für Verbesserungsvorschläge bin ich jederzeit offen – zumindest optimieren kann man den regulären Ausdruck mit Sicherheit…

(13)Permission denied: /var/www/[...]/.htaccess pcfg_openfile: unable to check htaccess file, ensure it is readable

Kam mir unbekannt vor – und obwohl die Fehlermeldung recht aussagekräftig war, kam ich erst hier auf die Spur: das Verzeichnis (bzw. schon ein Verzeichnis einige Ebenen tiefer) war für den Apache-User einfach nicht lesbar…