19. 02

Wie schon berichtet, hat bei mir jede (Sub-)Domain ihr eigenes chroot. Daraus ergibt sich nun aber das (noch-nicht)-Problem, dass ich maximal 17 (Sub-)Domains (ein /28 IPv4 und die Standard-IP) verwenden kann. Daher habe ich seit heute einen weiteren lighty laufen, diesen aber als Reverse-Proxy, der je nach angefragtem Host die Anfrage an einen der anderen, auf localhost lauschenden lighty (wenn ich es mal brauchen sollte würden hierdurch auch Tomcat und andere Perversitäten gehen) weiterreicht.

Als besonderes Schmankerl fungiert er gleichzeitig noch als https-Verschlüssler. Ich habe mir hierzu bei CAcert ein Zertifikat mit mehreren SubAltNames, welches sämtliche Domains enthält, erzeugt. Mit diesem einen Zertifikat füttere ich nun nur den Proxy, und schon sind alle Seite hintendrann auch über https erreichbar!

Das genaue Setup dazu sieht wie folgt aus:

Der bis jetzt genutzte Webserver wird so umkonfiguriert, dass er ab nun nurnoch auf localhost, Port 60001 lauscht. Der nächste kommt dann auf localhost, Port 60002 und so weiter. Somit ist es möglich, beliebig viele chroots anzulegen, und trotzdem nach aussen auf einer einzigen IP aufzutreten.

Den lighttpd wird installiert, unter Debian ganz normal per aptitude install lighttpd. Die relevanten Teile der Konfiguration sind:

server.modules = (
            "mod_accesslog",
            "mod_proxy"
 )
Der lighty soll nichts weiter machen als die Anfragen durchzureichen. Zusätzlich lasse ich ihn und nicht die Backends den Acceslog schreiben, damit ich logrotate, awstats etc nur für eine einzige Datei konfigurieren muss. Daher brauche ich nur diese beiden Module.
$SERVER["socket"] == "80.244.243.94:443" {
                  ssl.engine    = "enable"
                  ssl.pemfile   = "/etc/lighttpd/certs/proxy-80.244.243.94.pem"
                  ssl.ca-file   = "/etc/lighttpd/certs/cacert-class3.crt"
}
Ich aktiviere SSL für Verbindungen auf Port 443, der Trick hierbei ist nun das Zertifikat /etc/lighttpd/certs/proxy-80.244.243.94.pem, welches wie oben bereits beschrieben sämtliche Domains, die ich verwenden will, enthält. Die einzelnen Domains werden dann wiefolgt konfiguriert:
$HTTP["host"] == "netzhure.de" {
        proxy.server  = ( "" => ( (
                "host" => "127.0.0.1",
                "port" => 60001
        ) ) )
}

$HTTP["host"] == "git.netzhure.de" {
        proxy.server  = ( "" => ( (
                "host" => "127.0.0.1",
                "port" => 60002
        ) ) )
}
Anstatt == als Vergleichsoperator ist auch =~ möglich, desweiteren kann auch auf einige andere Eigenschaften gematcht werden. Mit $HTTP["URL"] kann so zum Beispiel sogar http://example.com/foo an ein anderes Backend als http://example.com/bar geschickt werden. $HTTP["host"] =~ "^(www\.)?example.com" leitet Anfragen für example.com und www.example.com an das selbe Backend. Somit sind hier deutlich flexiblere Szenarien als mit den klassischen Name Based Virtual Hosts, wie man sie vom Apachen kennt, möglich.

git.netzhure.de gibt es bis jetzt noch nicht, aber dieser Blog ist schon unter https://netzhure.de erreichbar. Die gesamte Proxy-Konfiguration zum runterladen gibts nochmal hier, es sollte allerdings beachtet werden dass einige Optionen schon für das chroot angepasst sind in dem es läuft...

Tags für diesen Artikel: ,

Trackbacks


Keine Trackbacks

Kommentare

Ansicht der Kommentare: (Linear | Verschachtelt)

Vielleicht solltest du noch erwaehnen, dass jeder lighty, der extra aufgesetzt wird als vhost auch nochmal extra RAM frisst. ;-)
Sicher, lighty frisst im Vergleich zu apache nichtmal ansatzweise soviel, trotzdem find ich es als erwaehnenswert. :-)
#1 jchome (Homepage) am 20.02.2007 09:43
Irgendwie....sollte das denkbar sein. Und diese einstellige MB-Zahl ist eigentlich vernachlässigbar auf gescheit ausgestatteten Server, genauso wie die 20-50MB pro chroot ;)
#1.1 mømø (Homepage) am 20.02.2007 12:15
Vernachlaessigbar ist bar nichts, das haben wir immer wieder bemerkt. *g*
Aber ja, bei normaler Nutzung ist es in der Tat absolut nicht auffaellig. Jedoch koennen die Zahlen variieren je nach Zahl der Anfragen an den Server und nun lass mal knapp 1k Anfragen auf den Server los. *g*
However, gute Arbeit. :-)
#1.1.1 jchome (Homepage) am 20.02.2007 13:17
Bei 1k Anfragen macht eher PHP das System dicht....gut, so viele fastcgi-Prozesse habe ich zum Glück nicht laufen :D
#1.1.1.1 mømø (Homepage) am 20.02.2007 13:52
Da will man zum Glueck ja eh was anderes, wie zum Beispiel C oder Python. :-)
#1.1.1.1.1 jchome (Homepage) am 21.02.2007 08:40
Hi momo,

nettes Tutorial, das mir einige Probleme löst. Danke!

Ach ja, müssen die Captcha wirklich sein? ;-)
#2 ramses (Homepage) am 08.06.2007 23:59
Danke!

Und ja, oder hast du Lust mir Spam zu loeschen ;)
#2.1 mømø am 09.06.2007 19:32
Nö, hab ich nicht, aber es gibt auch andere Methoden zur Spamvermeidung, die weder Barrieren aufbauen noch die User nerven - z. B. dadurch, daß sie nicht wirklich funktionieren, wie deine eben, als ich diesen Eintrag abschicken wollte ;-). Ist halt die Frage, inwieweit die mit einem fertigen System vereinbar sind, aber vom Prinzip her alles kein Problem, s. z. B. http://groups.google.de/group/de.comm.infosystems.www.authoring.misc/browse_thread/thread/2b8ea283fce067ff/af405bb475f0d472?lnk=st&q=scheller+schestag&rnum=1&hl=de#af405bb475f0d472. Ich kenne Leute, die solche Methoden zusammen mit gewissen Filterkriterien recht erfolgreich im Mailbereich einsetzen. Das dürfte auch hier funktionieren. Mehr dazu gern gelegentlich mal an 'nem Donnerstag.
#2.1.1 ramses am 09.06.2007 22:08
Was klappte da denn nicht?

Und ich bin mir nicht sicher, ob ich die Beitraege trotz korrektem Captcha nach 7 Tagen zusätzlich noch zur Moderation angezeigt bekomme.
#2.1.1.1 mømø am 10.06.2007 23:55
Als ich meinen ersten und auch den zweiten Kommentar absenden wollte, wurde er 2x trotz korrekt eingegebenem Captcha zurückgewiesen. Erst beim dritten Anlauf ging es
#3 ramses am 11.06.2007 01:53

Kommentar schreiben


Die angegebene E-Mail-Adresse wird nicht dargestellt, sondern nur für eventuelle Benachrichtigungen verwendet.

Um maschinelle und automatische Übertragung von Spamkommentaren zu verhindern, bitte die Zeichenfolge im dargestellten Bild in der Eingabemaske eintragen. Nur wenn die Zeichenfolge richtig eingegeben wurde, kann der Kommentar angenommen werden. Bitte beachten Sie, dass Ihr Browser Cookies unterstützen muss, um dieses Verfahren anzuwenden.
CAPTCHA

Pavatar, Gravatar, MyBlogLog, Monster ID, Pavatar Autoren-Bilder werden unterstützt.
HTML-Tags werden in ihre Entities umgewandelt.
BBCode-Formatierung erlaubt