Configuration of a server for Ruby-on-Rails 2.1

Posted by Christian Noack on 2009-01-28
Words 638 and Reading Time 3 Minutes
Viewed Times

Für Ruby-on-Rails-Anwendungen scheint sich zur Zeit Mongrel als Server durchzusetzen. Wenn man eine Ruby-On-Rails-Anwendung im Mongrel-Server betreibt, erlaubt diese den Zugriff auf die Anwendung nur über HTTP, also unverschlüsselt. Das ist für Anwendungen, die im Internet verfügbar sind häufig nicht gewünscht. Um den Zugriff auf den Anwendung mit SSL abzusichern und somit den Zugang über HTTPS zu ermöglichen gibt es nur die Möglichkeit einen Apache oder einen Lighttpd als Proxy davor zu schalten. Diese nehmen die Anfragen über HTTPS entgegen und leiten sie an den lokalen Mongrel weiter. Die Konfiguration der beteiligten Komponenten gelingt wie folgt:

Wie das für reine HTTP-Anfragen funktioniert wird für Lighttpd auf dem Homo-Adminus-Blog beschrieben. Für die Verwendung von Apache als Proxy gibt es einige Quellen im Netz, z.B. diese auf schwunk.com. Diese Anleitungen haben jedoch zwei Nachteile. Ersten beschreiben sie nicht, wie der Proxy mit SSL funktioniert und zweitens fehlt die Information wie man die Anwendung in einer Sub-URL z.B. “myApp” laufen lassen kann, so dass es möglich wird, vom Apache aus auf mehrere Rails-Anwendungen unter verschiedenen URLs (z.B. https://www.example.com/myRailsApp1 und https://www.example.com/myRailsApp2) zu verzweigen. Die folgende Beschreibung setzt Rails 2.2, Mongrel und Apache 2.x voraus.

Konfiguration von Apache, Mongrel und Rails

Konfiguration von Mongrel: Zuerst muss der Rails-Anwendung mitgeteilt werden, dass sie unter einer Sub-URL zu errreichen ist. Das geht am Einfachsten durch Hinzufügen vonconfig.action_controller.relative_url_root= “/myApp” ans Ende der Datei config/environment.rb (direkt vor end). Danach kann man die Anwendung neu starten und sollte sie unter http://localhost:3000/myApp erreichen können. Allerdings funktioniert der Zugriff auf die statischen Resourcen wie Bilder nicht mehr. Dafür muss im Unterordner public ein Ordner mit dem Namen myApp angelegt werden. In diesem Ordner muss dann ein symbolischer Link auf alle Dateien aus dem Public-Ordner erstellt werden. Unter Linux und Mac OS X geht das wie folgt:

  • cd public
  • mkdir myApp
  • cd myApp
  • ln -s ../* .
  • rm myApp um den rekursiven Link auf sich selbst zu entfernen
    *Danach den Server neu Starten. Die Anwendung sollte nun unter http://localhost:3000/myApp erreichbar sein und funktionieren.

Konfiguration von Apache

  • Die Apache-Konfiguration sollte bereits alles für SSL notwendige enthalten und für den HTTPS-Zugang einen eigenen Virtual-Host definieren.
  • Die Module proxy_module, proxy_http_module und ssl_module müssen im Apache geladen werden
  • Die Virtual-Host-Konfiguration sollte so aussehen:
  • SSLProxyEngine on
  • RequestHeader set X_FORWARDED_PROTO ‘https’
  • Redirect /myApp /myApp/
  • ProxyPass /myApp/ http://localhost:3000/myApp/
  • ProxyPassReverse /myApp/ http://localhost:3000/myApp/
  • Nun den Apache neu starten (sudo apachectl restart)
  • Die Anwendung sollte nun unter https://localhost/myApp erreichbar sein
  • Siehe dazu auch: http://railsforum.com/viewtopic.php?id=21753

Besonderheit für rails 2.1:

Das Festlegen einer Sub-URL durch das Setzen von config.action_controller.relative_url_root= “/myApp” in environment.rb funktioniert erst ab rails 2.2. Die vorherige MethodeActionController:AbstractRequest.relative_url_root= “/myApp” funktioniert meiner Erfahrung nach nicht mehr mit rails 2.1. Die einzige Variante, die bei mir funktioniert hat, ist es, den Mogrel mit der Option –prefix=”/myApp” zu starten. Da man den Mongrel aber in der Regel nicht direkt, sondern über “script/server” startet, muss man diesem Aufruf den Prefix mitgeben. Das geht in rails 2.1 aber nicht. Auf rubyonrails.org ist ein Patch veröffentlicht, der es ermöglicht, den Prefix beim Start des Servers zu übergeben. Das ist besonders interessant, wenn man die Anwendung Projektmanagement-Anwendung Redmine betreiben möchte. Diese bringt ihre Rails-2.1-Distribution im vendor-Ordner selbst mit. Dort kann dann problemlos gepatcht werden und man kann Redmine dann mit einer Sub-URL laufen lassen.