Basic Apache Performance Tips

Anyone mass-hosting virtual domains on apache knows the problems. Over the time I collected some basic and important performance tips which I want to give back to the community in aggregated form. Sorry, that I don’t remember all sources of information – so I will mention none. Google will help you. Here’s the list: Den Rest des Beitrags lesen »

SecurePoint Appliances: Paßwort zurücksetzen

Aktuelle SecurePoint-Appliances bringen nicht mehr die Standard-Linux-Umgebung mit Befehlen wie “passwd” und ähnlich mit sich. Hier das Paßwort zurückzusetzen gestaltet sich als schwierig; hinzukommt, daß die kleineren Appliances keinen Monitor- und Tastaturanschluß besitzen und zudem von CompactFlash booten. Der serielle Anschluß gibt zwar die Linux-Konsole aus, jedoch erst, wenn der Kernel läuft. Um die Paßwörter der Datenbank ändern zu können, muß man jedoch die Appliance im Restore-Mode booten – außer man möchte seine Konfiguration verlieren. In letzterem Fall kann man natürlich per Rescue-Image neu installieren.

Das wollte ich allerdings nicht (war relativ aufwändig und gewachsen). Der Trick war, die CF-Karte auszubauen und in einen USB-Kartenleser einzubauen. Als nächstes benötigt man VirtualBox. Man richtet nun in VirtualBox ein virtuelles Festplatten-Image mit Verweis auf ein echtes Device ein. Das geht allerdings nicht über die GUI. Deshalb wechselt man ins Verzeichnis ~/.VirtualBox/VDI und gibt nun dort folgenden Befehl ein:

VBoxManage internalcommands createrawvmdk -filename "SecurePointDisk1.vmdk" -rawdisk /dev/sdc -register

“/dev/sdc” ist hier durch das Device der eingelegten CF-Karte zu ersetzen. Da dies in der Regel nur als “root” zugreifbar ist, muß man entweder VirtualBox als root starten (würde ich nicht machen) oder den Eigentümer des Devices mittels “chown” auf den eigenen User umbiegen (würde ich empfehlen). Wichtig ist: Keinesfalls die CF-Karte irgendwie mounten!

Nun legen wir eine virtuelle Maschine über die VirtualBox-GUI an. Dort verbinden wir den “Primary Master” mit der eben angelegten “SecurePointDisk1″. Weiter dürfen keine IDE-Geräte verbunden werden – auch keine CD. Das Image booten wir nun. Nun geht es größtenteils nach Leitfaden von SecurePoint weiter:

Im Grub-Menü muß der zweite Menüpunkt (“change configuration”) gewählt werden. Aber bitte noch nicht starten, sondern erst mit Tastendruck auf “e” editieren. Am Ende der Kernelzeile müssen wir den Primary Master auf den Secondary Master umbiegen, da sich dieser nicht in VirtualBox verbinden läßt, SecurePoint hier aber die CF-Karte erwartet. Dazu ergänzen wir folgendes:

“ide0=0x1e8,0x3ee,14″ (brauchen wir gleich noch einmal)

Nun eine Leerzeile am Ende der Liste anfügen und in dieser Ctrl+X drücken. Das Image bootet nun. Der Name der zu bootenden Konfiguration ist “none”. Den Namen der anderen Konfiguration bitte notieren – wir brauchen ihn gleich. Wahrscheinlich heißt sie “wizard”. Nun die Konfiguration “none” booten. Die Appliance ändert die Boot-Parameter und startet neu. Diesmal den ersten Grub-Menüpunkt booten – nicht vergessen, wieder den Parameter “ide0=…” zu ergänzen.

Am Ende des Boot-Vorgangs dauert es ggf. ein paar Sekunden, bis die Netzwerk-Geräte konfiguriert sind – kurz warten also, es stört sonst die Eingabe. Jetzt mit User “admin” und Paßwort “insecure” anmelden. Man befindet sich nun auf der CLI.

Hier kann mit dem Befehl “config load” die richtige Konfiguration geladen werden, das Paßwort nach Anleitung von SecurePoint mit “change user” geändert werden (für “admin”) und die Konfiguration anschließend gespeichert (“config save”) und als aktiv gesetzt (“config set”) werden.

Jetzt kann die Appliance mit “reboot” neu gebootet werden und wir lassen sie zum Test einmal komplett in VirtualBox hochfahren (bitte wieder “ide0=…” ergänzen) und versuchen uns einzuloggen. Alles sollte nun wieder klappen und wir können VirtualBox beenden und die Karte wieder im Gerät einbauen.

Mehrere Rails-Anwendungen pro VHost auf Lighttpd

Wer es schonmal versucht hat, Ruby on Rails unter Lighttpd zum Laufen zu bekommen, wird wissen, daß dies im Prinzip super einfach ist. Sobald man aber eine Rails-Anwendung in einem Unterverzeichnis der Domain laufen lassen möchte, bekommt man gewaltige Kopfschmerzen. Alle googlebaren Tricks führen entweder dazu, daß man beim Deployment Code ändern muß, böse Hacks in den Routen vornehmen muß oder an Stellen Hack’s einbaut, die nicht nötig sind.

Sogar Lighttpd selbst bringt einen solchen Hack mit, der beim Request das Prefix von der URL entfernt und dem Rails-Dispatcher so vorgauckelt, er würde im Hauptverzeichnis laufen. Dies führt zwar dazu, daß die Routen richtig erkannt werden, dafür muß bei allen Links in den Templates das Prefix manuell ergänzt werden. Kategorie: Buh! *thumbsdown* Die Idee war für mich gestorben.

Der nächste Hack führt eine Variable ein, die je nach Situation im Rails-Quellcode entweder gesetzt oder eben wieder gelöscht wird, um den Routen-Generator und den Routen-Parser zu überlisten. Auf so einen Blödsinn hatte ich keine Lust.

Nach dem Studium des Quellcodes fand ich heraus, daß es eine Variable RAILS_RELATIVE_URL_ROOT gibt, die man im Environment selbst setzen kann und die unter Apache sogar per Autodetect durch Rails selbst gesetzt wird. Weil Lighttpd aber etwas anders funktioniert, ist das dort nicht einsetzbar.

Anders gesprochen: Wenn ich also diese Variable händisch setze, müßte Rails ja damit klar kommen. Ist leider nicht so, Rails weiß überhaupt nichts davon, daß diese Variable gesetzt ist, wenn man den dokumentierten Weg für die Einstellungen des FCGI-Servers geht:

9 fastcgi.server = (
10   ".fcgi" => (
11     "localhost" => (
12       "min-procs" => 1,
13       "max-procs" => 5,
14       "socket" => approot + appname + "/tmp/lighttpd.socket",
15       "bin-path" => "/usr/bin/ruby " + approot + appname + "/public/dispatch.fcgi",
16       "bin-environment" => ( "RAILS_ENV" => "production", "RAILS_RELATIVE_URL_ROOT" => "/" + appname ))))

Dies ist wegen einer schlecht dokumentierten Eigenschaft des FCGI-Protokolls zum Scheitern verurteilt, da der Rails-FCGI-Dispatcher zum Zeitpunkt der Ausführung keinen Zugriff auf diese Variable mehr hat. Der Trick ist, die Variable aus dem “bin-environment”-Array herauszunehmen und mit dem Lighttpd-Modul “mod_setenv” zu setzen. Der komplette Code-Schnippsel für die Rails-Konfiguration in Lighttpd sieht dann wie folgt aus:

5 server.error-handler-404 = "/" + appname + "/dispatch.fcgi"
6 alias.url = ( "/" + appname => approot + appname + "/public" )
7 index-file.names = ( "index.html", "dispatch.fcgi" )
8 setenv.add-environment = ( "RAILS_RELATIVE_URL_ROOT" => "/" + appname )
9 fastcgi.server = (
10   ".fcgi" => (
11     "localhost" => (
12       "min-procs" => 1,
13       "max-procs" => 5,
14       "socket" => approot + appname + "/tmp/lighttpd.socket",
15       "bin-path" => "/usr/bin/ruby " + approot + appname + "/public/dispatch.fcgi",
16       "bin-environment" => ( "RAILS_ENV" => "production" ))))

Den etwas umständlichen “bin-path”-Aufruf führe ich so aus, damit sich Grsec und PaX im Kernel eines Hardened-Linux nicht über Ausführungsrechte in einem potentiell unsicheren Verzeichnis beschweren. Andere Lighttpd-Rails-Beispiele im Netz starten hier direkt den FCGI-Dispatcher ohne den Interpreter explizit anzugeben. Die Variablen “approot” und “appname” sind vorher entsprechend zu besetzen. Auch “server.document-root” sollte noch richtig gesetzt werden (passiert bei mir in einer seperaten Config-Datei und fehlt hier deshalb).

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.