Mono from Sources

Die nächste serverseitige Webdevelopment-Technologie, die ich auf dem Server zur Verfügung stellen will, ist ASP.NET unter Mono .Die Debian-Pakete sind mir etwas zu alt, auch hier kompiliere ich lieber selbst. Sourcen gibt es hier . Auf der Mono-Homepage gibt es mittlerweile ja einen grafischen Installer, den kann ich natürlich auf dem Server kaum einsetzen. Es geht schon, da er auch über einen Textmode verfügt, allerdings werden ohne Wahlmöglichkeit alle Bibliotheken und Tools installiert.

Ich hab libgdiplus (wäre denke ich für eine ASP.NET – Anwendung unnötig gewesen, hier wird im wesentlichen der System.Drawing – Namespace abgebildet), mono und natürlich xsp kompiliert und installiert (nach /usr/local).

Fehlende Abhängigkeiten waren bei mir noch glib2.0-dev für Mono selbst und die Bibliotheken libexif-dev, libtiff4-dev, libungif4-dev und libxrender-dev für Gdi+.

Zum Testen:

cd /usr/local/lib/xsp/test/
xsp --port 9000

oder

xsp2 --port 9000

für den Testserver unter ASP.NET 1.1 bzw 2.0. Der Port ist natürlich wieder frei wählbar.

Netbeans 6 unter Ubuntu Gutsy 7.10

Lange war ich auf der Suche nach einem vernünftigen Repository für den aktuellen Netbeans Release, der die Schwierigkeiten bei der Installation (insbesondere im Zusammenhang mit Desktop-Effekten) meistert und zudem den ganzen Enterprise-Stack gut abbildet. Gestern bin ich fündig geworden; und zwar nicht überraschend auf dem Launchpad . Die Homepage mit den eigentlichen Informationen zum Repository ist zwar in französisch, doch die “wichtigen” Informationen lassen sich natürlich auch so heraus lesen.Das ganze steht natürlich auch schon länger zur Verfügung (natürlich fehlen dann auch die letzten Patches), netterweise genau seit meinem letzten Geburtstag. Ich bin aber leider erst jetzt drüber gestolpert. Auf jeden Fall herzlichen Dank an Remi und Artem, die Contributoren.

Das wichtigste zusammengefasst:

Repository-Adresse:
deb http://srvremi.free.fr/ubuntu gutsy main

Key-Import:

gpg --keyserver wwwkeys.eu.pgp.net --recv-keys AA82C25A36399439
gpg --armor --export AA82C25A36399439 | sudo apt-key add -
sudo apt-get update

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.