[PATCH] lighttpd Konfigurationsfrontend

[Darkyputz]

klingt gut...
Aber was anderes...mit dem Lighttpd habe ich ja wenn ich das richtig sehe nun den 3ten Webserver am laufen auffer Box...ctlmgr von AVM, httpd von Freetz und Lighttpd als paket für Webhosting...
Kann man da nicht nen bissel konsolidieren?
Z.b. bei Einbau des Lighttpd das Freetzwebif darüber laufen lassen oder sowas?

 

[linuxkasten]

Jap, das hab ich mir auch schon gedacht.
Zum testen hab ich mal das AVM-WebIF per httpd (busybox) gestartet und es ging tadellos. Allerdings braucht man den ctlmgr trotzdem (leider; für bestimmte andere Sachen).
Also müsste es genauso mit lighttpd oder apache funktionieren.

Und was ist mit der Option "Statically linked libraries"? Wann sollte man die aktivieren? Ich hab die momentan aktiviert, liegt es vielleicht deswegen daran, dass PHP bei mir nicht funktioniert?

Also bei mir ist alles dynamisch gelinkt und ich hab trotzdem den gleichen Fehler.

 

[mehle]

Und was soll solch eine Konsolidierung bringen? IMHO nichts bzw mehr Ressourcenverbrauch:

- AVM können wir nicht umziehen

- Freetz Webif sollte keine zusätzlichen Softwareanforderungen stellen - der httpd kommt von busybox und ist von Haus aus dabei (oder soll jeder mind. 200KB zusätzlich opfern, nur um das Freetz Webif via lighttpd anzuzeigen?)

- httpd ist viel kleiner während der Laufzeit als lighttpd - ausreichend für Freetz

- Für deine eigenen Seiten kannst du aber wählen: nimm den busybox httpd, Apache or lighttpd

Ergo, wenn du etwas konsolidieren willst, dann nimm httpd für deine privaten Seiten. Mit dem hast du aber kaum solche Möglichkeiten wie mit Apache oder lighttpd.

Ciao
Stephan

 

[Loewe81]

Ich geb zu das es mir sicher etwas leichter Fallen würde den letzten Posts besser zu folgen, wenn ich fundiertere Linuxkenntnisse habe. Hab ich aber leider nicht, zumindest wohl nicht hinreichend genug.
Ok, was ich verstanden habe ist, dass ich chroot wohl aus Sicherheitsgründen aktivieren sollte. Sehe ich das allerdings richtig, dass diese Einstellung nichts mit einem Funktionieren/Nichtfunktionieren des lighttpd zu tun hat?
Und könnte mir vielleicht nochmal jemand den Unterschied zw. dynamisch und statisch gelinkt erklären. Welche Option muss ich wann nehmen (ich will möglichst wenig selbst machen). Ich möchte lediglich lighttpd und PHP im menuconfig selektieren und danach sollte es laufen. Ok, noch das webroot-Verzeichnis angeben, aber das sollte es doch eigentlich sein, oder?
Danke!

Ciao Stefan

 

[mehle]

Chroot: Schau zu wikipedia, um zu klären, was es ist. Chroot kann nichts bezüglich der Stabilität oder Angreifbarkeit von lighttpd verändern. Es ist ausschließlich dafür da, um im Falle eines Einbruchs in lighttpd (oder jeder andere Prozess, der in einem chroot läuft) den Einbreicher auf dieses "Gefängnis" zu beschränken. Der Angreifer kann damit nicht an Device Dateien rankommen oder an andere Schnittstellen / Information welche außerhalb des chroot liegen, die er für weitere Schadzwecke nutzen kann.

Linking: siehe http://de.wikipedia.org/wiki/Linker_(Computerprogramm)

Ciao
Stephan

 

[Silent-Tears]

Wenn wir schon anfangen, alles möglich im chroot-jail laufen zu lassen: Wie wäre es, das etwas genralisierter zu betrachten und möglichst alles, was geht darin unterzubringen?
Irgendwo in den Configs entsprechend, welche Files im Jail benötigt werden, und im rc-Script dann die automatisierte kopiererei & co?

 

[mehle]

Die Erstellung eines Chroots ist normalerweise relativ schwierig, wenn das betreffende Programm nicht schon darauf vorbereitet ist (du kannst dir ja mal zum Spaß das compartment Programm von http://www.chronox.de anschauen - dann siehst du, daß ein chroot für Applikationen, die nicht vorbereitet sind, schwierig bis unmöglich ist).

Natürlich wäre es mir lieber, wenn alle Daemons zum Internet in einem chroot und unter einer UID != 0 laufen würden.

Zumindest sollten wir schauen, daß alle Programme, die chroot von Haus aus unterstützen, auch entsprechend konfiguriert werden (können).

Ciao
Stephan

 

[olistudent]

Ich hatte den Vorschlag so verstanden, dass wir ein "chroot"-Verzeichnis erzeugen und alle Server (die das unterstützen) in diesem einen chroot laufen lassen!?

MfG Oliver

 

[mehle]

Uh, dann habe ich es falsch verstanden.

Aber auch dieser Vorschlag ist nicht umsetzbar IMHO. Das chroot für openvpn kann gut und gerne im tmpfs oder von mir aus auch im flash liegen. Aber das lighttpd chroot muß immer dort liegen, wo auch das docroot ist (normalerweise auf einer externen Platte). Demzufolge können wir die chroots schlecht synchronisieren.

Ciao
Stephan

 

[Silent-Tears]

Nein, das war eher so gemeint, dass man unsere Umgebung so vorbereitet, dass mit dme Setzen einiger Variablen (wo, welche files, welcher user, welche gruppe) ein chroot aus dem rc-script heraus(eher wohl modlib) für die erzeugen, die das abkoennen, und den rest einfach ohne laufen lassen.
Alle in einem chroot ist ja reichlich unsinnig, da man sonst ja auch die anderen Services angreifen kann noch.

 

[Darkyputz]

Edit:

Sooo...nu ist lighttpd nach zigfachem testen und versuchen am laufen MIT dem Freetz PHP.
Aber nur in folgender Configuration:
Chroot aktiv, Webseitn nicht im htdocs Ordner wie in Config angegeben, sondern im Ordner

"htdocs\websites"

der nicht von mir erstellt wurde
Und beim Starten von Lighttpd kommt noch die Meldung:

mknod: /var/media/ftp/uStor02/tools/webserver/htdocs//dev/null: File exists
cp: cannot stat '//tmp/flash/php.ini': No such file or directory
cp: cannot stat '//tmp/flash/php': No such file or directory

die mir nix sagt.

Hier die Config dazu:

export LIGHTTPD_DOCROOT='/var/media/ftp/uStor02/tools/webserver/htdocs/'
export LIGHTTPD_LOGGING='yes'
export LIGHTTPD_LOGGING_ACCESS='/var/media/ftp/uStor02/tools/webserver/access.log'
export LIGHTTPD_LOGGING_ERROR='/var/media/ftp/uStor02/tools/webserver/error.log'
export LIGHTTPD_LOGGING_ERROR_FILE='no'
export LIGHTTPD_MODCGI='yes'
export LIGHTTPD_MODFASTCGIPHP='yes'
export LIGHTTPD_MODFASTCGIPHPPATH='/usr/bin/php-cgi'
export LIGHTTPD_MODSTATUS='yes'
export LIGHTTPD_MODSTATUSSORT='enable'
export LIGHTTPD_PORT='85'

Edit Ende

 

[mehle]

Edit:

"htdocs\websites"

der nicht von mir erstellt wurde

Hach ja, RTFM siehe Webfrontend zum chroot, da steht genau dieses.

Und beim Starten von Lighttpd kommt noch die Meldung:
mknod: /var/media/ftp/uStor02/tools/webserver/htdocs//dev/null: File exists

Diese Meldung ist erwartet worden. Ich hatte diese Meldung gelassen, da ja auch die Meldung von existierenden IDs da steht. Wenn es nicht gefällt, kann man die löschen.

cp: cannot stat '//tmp/flash/php.ini': No such file or directory
cp: cannot stat '//tmp/flash/php': No such file or directory
die mir nix sagt.

Uhh, im SVN ist rc.php immer noch nicht mit Rechten 755 gespeichert @olistudent: kannst du dies bitte ändern?

Ciao
Stephan

 

[Darkyputz]

Sorry für das RTFM...Aber so hat es wenigstens was aufgedeckt...
Hoffe wir sind damit wieder quit? ;-)

 

[mehle]

Sorry für das RTFM...Aber so hat es wenigstens was aufgedeckt...
Hoffe wir sind damit wieder quit? ;-)

Kein Problem Für mich sind solche Probleme ein Hinweis, dass es zu komplex ist (gut, chroot ist nie besonders einfach).

Ich denke, ich werde im Webif noch einen kleinen Absatz reinmachen, wo das endgültige docroot aufgeführt ist.

Ciao
Stephan

 

[olistudent]

http://trac.freetz.org/changeset/3265

MfG Oliver

 

[matze1985]

Das chroot für openvpn kann gut und gerne im tmpfs oder von mir aus auch im flash liegen.

Ein chroot für verschiedene Dienste wie Openvpn oder Lighthttpd, die nach außen lauschen ist aus Sicherheitsgründen bestimmt nicht verkehrt.

Aber wird es mit dem Ram nicht irgendwann etwas eng, wenn man als benötigten Libs in eben dieses chroot kopiert, welches im tmpfs (ram) liegt?

 

[mehle]

Aber wird es mit dem Ram nicht irgendwann etwas eng, wenn man als benötigten Libs in eben dieses chroot kopiert, welches im tmpfs (ram) liegt?

Wie oben ausgeführt kann es genau deswegen kein chroot dir geben in dem die verschiedenen chroots der verschiedenen Dienste liegen. Genau deswegen ist ja auch das chroot des lighttpd das Docroot, welches ja wohl kaum im Ram liegt.

Ciao
Stephan

 

[mehle]

Ich denke, ich werde im Webif noch einen kleinen Absatz reinmachen, wo das endgültige docroot aufgeführt ist.

Hier der Patch

Ciao
Stephan

 

[Loewe81]

Einen wunderschönen guten Morgen.
Gestern habe ich dann mal meinen zweiten Versuch mit lighttpd und PHP gestartet doch leider wieder ohne Erfolg. Basis war diesmal der Trunk 3273 und ausgewählt habe ich PHP (diesmal OHNE statisch gelinkte Librariers) und lighttpd mit ALLEN Optionen. Ich habe auch nichts nach external ausgelagert.
Könnte mir jetzt vielleicht jemand mal sagen, welche Pfade, Einstellungen und Häkchen ich im Freetz WebIf nach der Imageinstallation setzen muss bzw. wie die Verzeichnisstruktur der externen Festplatte aussehen muss?
Mein Problem gestern war wieder, dass sich der lighttpd Dienst bei aktivierten FastCGI und/oder Logging NICHT starten ließ. Ohne diese Optionen ließ er sich zwar starten aber beim Aufruf der Website bekam ich diesmal einen 404-Fehler.
Auf meiner externen Platte habe ich ein Verzeichnis "www", welches ich als docroot in den lighttpd-Einstellungen stehen habe. chroot ist aktiviert und da ich ldd mit installiert habe sind unterhalb des "www"-Verzeichnis auch die entsprechenden Unterverzeichnisse vorhanden.
Die anderen Dienste wie SSH, SFTP (via dropbear), Samba und Transmission laufen ohne Probleme, das kann doch bei lighttpd auch nicht so schwierig sein.
Vielen lieben Dank schonmal!

Ciao Stefan

 

[mehle]

Re chroot: siehe Patch von oben, aber generell sind die Pfade Dokumentiert IMHO (siehe chroot doku) - hier aber nochmal die Verzeichnisse im chroot:

LIGHTTPD_DOCROOT
Wenn "LIGHTTPD_CHROOT" = "yes", dann $LIGHTTPD_DOCROOT/websites"
Wenn "LIGHTTPD_VIRTHOST" = "yes" && LIGHTTPD_CHROOT = yes, dann LIGHTTPD_DOCROOT/websites/default und LIGHTTPD_DOCROOT/websites/$LIGHTTPD_VIRTHOSTTYPE

re Häckchen: es gibt keine zwanghaften Optionen, alle Optionen sind unabhängig. Das Problem ist scheinbar, dass php-cgi nicht gestartet werden kann. Ich habe noch keine Lösung für dieses Problem, da ich es noch nicht debuggen konnte.

Ciao
Stephan