Lighttpd einrichten

Hier ist die Debian Etch – Version aktuell, also erledigen wir die Installation mit apt-get install lighttpd. Die Fehlermeldung, dass lighttpd nicht gestartet werden konnte, ignorieren wir erst mal. Denn der Port 80 ist natürlich vom Apache belegt. Die Ruby fcgi-Anpassung klappt über gem install fcgi, dazu wird aber noch mind. das Debian-Paket libfcgi-dev benötigt.

Zur Konfiguration:

Apache
Da ich mich bei der lighttpd-Konfiguration für Subdomains entscheide, passen wir die ProxyPass-Direktiven der Apache-Konfiguratio in etwa wie folgt an:

ProxyPass /railsblog/ http://railsblog.michael-alt.info:81/
ProxyPassReverse /railsblog/ http://railsblog.michael-alt.info:81/

Der Port ist natürlich frei wählbar.

Lighttpd
Anpassungen in der /etc/lighttpd/lighttpd.conf:

  • Module: mindestens mod_rewrite und mod_fastcgi dazunehmen
  • index-file.names um dispatch.fcgi ergänzen
  • url.access-deny um “.htaccess” ergänzen (die verarbeitet der lighttpd nicht)
  • Portnummer: server.port = 81 (oder der entprechende Port)
  • Endungen der Dateien, die nicht statisch ausgeliefert werden sollen static-file.exclude-extensions = ( “.rb”, “.php”, “.pl”, “.fcgi” )

Und natürlich unsere Host-Sektion

$HTTP["host"] =~ "railsblog.michael-alt.info" {
  server.document-root = "/path/to/railsblog/public" 
  server.error-handler-404 = "dispatch.fcgi"  
  fastcgi.server = ( ".fcgi" =>
  (
    (
      "socket" => "/path/to/railsblog/log/code.socket",
      "min-procs" => 2,
      "max-procs" => 5,
      "bin-path" =>  "/path/to/railsblog/public/dispatch.fcgi",
      "bin-environment" => ( "RAILS_ENV" => "development" )
  )))
}

Die Pfade /path/to/… müssen natürlich angepasst werden, der User/die Gruppe www-data braucht Schreibrechte in den log und tmp – Verzeichnissen. Und dann können wir starten mit /etc/init.d/lighttpd start.

Apache proxying

Nachdem ich im letzten Beitrag die Rails-Anwendung aufgesetzt habe, geht es nun daran, die “hässliche” Url mit der Portnummer 3000 los zu werden. Natürlich könnten wir jetzt versuchen, den Apache FCGI “sprechen” zu lassen. Ich entscheide mich aber lieber für eine Proxying-Lösung, mit dem Hintergrund den Blog on Rails sowie in Zukunft weitere (insbesondere FCGI-) Anwendungen vom lighttpd servieren zu lassen. Zwei Bemerkungen noch bevor es aber an die Installation des Lighty geht: zum einen verschieben wir das Anwendungsverzeichnis an einen passenderen Ort bzw. erstellen es neu (Vorschlag: ein Verzeichnis parallel zum htdocs-Verzeichnis; ich selbst gehe noch einen Schritt weiter und erstelle an dieser Position ein rails-Verzeichnis, in dass ich die zukünftigen Rails-Anwendungen packe) und des weiteren ersetzen wir erst mal unseren WEBrick durch den schnelleren Mongrel: gem install mongrel und wie gehabt starten mit ruby script/server im Rails-Anwendungsverzeichnis.

Nun zur Proxy-Konfiguration:

  1. Apache-Module
    Wir benötigen zwei Module: proxy und proxy_http, die wir einfach beide mit a2enmod proxy_http einschalten. Die Debian conf-Dateien sind in Ordnung; es sollte mindestens ProxyRequests Off eingestellt sein, das aber auch Standard ist.
  2. Konfiguration
    Die Apache-Direktiven, die wir anpassen müssen, sind der Proxy-Tag und ProxyPass-Direktiven wie dort im Beispiel zu sehen. Die Cookie-Geschichte können wir erst mal vernachlässigen, wichtig ist natürlich aber das Ziel des ProxyPass: unsere URL http://servername.com:3000/ . Nicht vergessen an der Stelle: Einen Directory-Tag erstellen, der den Zugriff erlaubt. Alle Direktiven wandern entweder in die globale Server-Konfiguration oder in einen VirtualHost.

Apache neu starten/laden und ab geht es unter Blog on Rails

Ruby on Rails from Sources

Der Server, der diese Seite und den Blog hostet, ist ein Debian GNU/Linux (Etch). Mit Etch ist Debian zwar nicht mehr ganz so zurückhaltend was die Aktualität der Pakete betrifft, aber ich bin halt ein Freund der Methode from Scratch und compiliere ganz schnell mal selbst ein Paket. Weniger aus dem Grund, dass ich es anpassen kann, eher weil mein Verständnis darüber wächst (insbesondere bei Problemen!).

Fangen wir an mit Ruby on Rails.

  1. Ruby stable (1.8.6-p110) von ruby-lang.org
    Es gibt zwar schon die 1.9, diese wird aber ausdrücklich als Entwicklerversion bezeichnet (und das bedeutet eben nicht für die Menschen, die mit Ruby entwickeln).
    Mein Debian-Server hat schon eine Reihe der dev-Bibliotheken, also läuft das Linux-Standardprozedere einwandfrei durch (siehe README), die Installation wanderte nach /usr/local in die entsprechenden Verzeichnisse.
    Zum Testen: ruby -v
  2. RubyGems (1.0.1)
    Download von RubyForge entpacken, ruby setup.rb und das wars schon
  3. Rails (2.0.2)
    Jetzt müssen wir nicht mehr downloaden, hier reicht gem install rails —include-dependencies. Und wir haben das wichtigste zusammen.
  4. Testapplikation
    Im Verzeichnis /tmp ein einfaches rails blog, dann im enstandenen blog-Verzeichnis ruby script/server und der WEBrick-Server startet und lauscht am Port 3000. Ein https://michael-alt.info:3000 – Aufruf im Browser begrüßt mich mit dem bekannten Welcome aboard
  5. Datenbankschnittstellen
    Ruby hat bis dato natürlich noch keine Schnittstellen zu Datenbanken. Für die Testapplikation reicht hier ein gem install sqlite3-ruby, um später (nach Anpassung der config/database.yml) an MySQL zu binden gem install mysql.

Als Demonstration werd ich später hier auf der Seite einen Link zu einer Rails-Applikation haben (möglicherweise einfach meinen Blog mit RoR). Der komplette Sourcecode wird dann über SVN bzw. ein WebSVN abrufbar und einsehbar sein.