Error.log vom Busybox httpd

Enkidoo

Neuer User
Mitglied seit
28 Mrz 2013
Beiträge
60
Punkte für Reaktionen
2
Punkte
8
Hallo!

Ich mache gerade erste Schritte beim Modifizieren meiner Fritzbox 7270v3 und bin mittlerweile so weit, dass die Box Ihre neue Aufgabe ausführt, die darin besteht, meine Kalender mittels "Baikal" im LAN bereitzustellen. Dazu musste ich lighttpd installieren, denn mit dem "mitgelieferten" httpd der Busybox wollte es einfach nicht klappen. Interessieren würde es mich aber schon, ob es nicht doch funktionieren würde. Aber wo anfangen? Gibt es einen error.log des Busybox httpd?

Beste Grüße!
 
Zuletzt bearbeitet:
Danke für Deine Antwort! Der busybox httpd ist ja bei Freetz schon mit dabei und via freetz habe ich php installiert. Das müsste doch dem entsprechen, was du bei fritzmod.net verlinkt hast, oder sind das andere Versionen?

Durch trial & error habe ich die notwendigen php-extensions herausgefunden, die baikal braucht, dabei war der errorlog von lighttpd sehr hilfreich. Wenn der busybox-httpd tatsächlich keinerlei Fehlermeldungen ausgibt, wüsste ich auch nicht, wie ich dem Problem auf die Spur kommen könnte.

Der busybox-httpd läuft auch so weit mit php, dass die index.php von baikal dargestellt wird, aber sobald es an die Einstellungen oder eigentlichen Kalender geht, kommt entweder nur eine leere Seite oder 404 "not found". Ich habe den Verdacht, dass es an sqlite liegen könnte, aber was weiß ich schon :confused:

PS: httpd hat ja den Parameter -v für "verbose". Wo würden denn die Ausgaben landen?
 
Zuletzt bearbeitet:
Moins

Welches SQLite ?
Das Serverbasierende, oder das Dateibasierte SQLite3 ?
...die Dateibasierende muss/sollte in PHP enthalten sein.
( php -m )

Busybox httpd mit verboser Ausgabe auf der Konsole: httpd -vv -f
... -f startet den httpd nicht als Dämon.
 
Zuletzt bearbeitet:
Das dateibasierte (Baikal legt eine "db.sqlite" an). Aber mittlerweile denke ich, dass es nicht an sqlite liegt, denn es ist mir gelungen, die gesamte Installation zu durchlaufen und einen Benutzer anzulegen, der sich in der db.sqlite dann auch findet. Erste Hürde war, httpd beizubringen, "index.php" als Index-Datei zu benutzen (einfach in der Konfigurationsdatei die Zeile "I:index.php" eintragen). Standardmäßig sucht er nämlich nur nach "index.htm(l)" Mit der Datenbank scheint es also so weit zu klappen.

Neue Hypothese: Es liegt an der Authenifizierung. Die Abfrage eines Kalenders erfolgt z.B. über folgende Url:

Code:
[URL]http://fritz.box:8008/baikal/html/cal.php/calendars/BENUTZERNAME/KALENDERNAME/[/URL]

Bei Apache und lighttpd werden Benutzername und Passwort verlangt, wenn man diese URL im Browser oder Kalenderprogramm aufruft. Das sieht dann im access.log von lighttpd so aus:

Code:
"GET /baikal/html/cal.php/calendars/test/default/ HTTP/1.1" 401 354 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/calendars/test/default/ HTTP/1.1" 200 27245 "-" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=openiconic%2Fopen-iconic.css HTTP/1.1" 401 354 "http://fritz.box:8008/baikal/html/cal.php/calendars/test/default/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=sabredav.css HTTP/1.1" 401 354 "http://fritz.box:8008/baikal/html/cal.php/calendars/test/default/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=sabredav.png HTTP/1.1" 401 354 "http://fritz.box:8008/baikal/html/cal.php/calendars/test/default/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=openiconic%2Fopen-iconic.css HTTP/1.1" 200 14041 "http://fritz.box:8008/baikal/html/cal.php/calendars/test/default/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=sabredav.css HTTP/1.1" 200 3043 "http://fritz.box:8008/baikal/html/cal.php/calendars/test/default/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=sabredav.png HTTP/1.1" 200 2825 "http://fritz.box:8008/baikal/html/cal.php/calendars/test/default/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=openiconic/open-iconic.woff HTTP/1.1" 200 12404 "http://fritz.box:8008/baikal/html/cal.php/?sabreAction=asset&assetName=openiconic%2Fopen-iconic.css" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"
"GET /baikal/html/cal.php/?sabreAction=asset&assetName=favicon.ico HTTP/1.1" 200 4286 "http://fritz.box:8008/baikal/html/cal.php/calendars/test/default/" "Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.116 Safari/537.36"

Mit dem Busybox-httpd wird aber kein Passwort abgefragt, sondern direkt "404 Not Found" angezeigt. Was ich noch probiert habe, war in der httpd.conf einen Passwortschutz für baikal und seine Unterverzeichnisse einzutragen.
Code:
/baikal:test:test
Das Passwort wird zwar abgefragt, aber offenbar nicht an baikal weitergegeben; weiterhin "404 Not Found". Das scheint also ein reiner Verzeichnischutz zu sein.

Wenn ich die Anmerkungen im httpd Quellcode richtig verstanden habe, hat der Parameter "-r" etwas mit der HTTP-Authentifizierung zu tun. Bringt aber auch nichts, es wird kein Passwort abgefragt.
 
Wenn man den "httpd" mit "-f" aufruft, sollte das Protokoll in der Konsole zu sehen sein, bei "-vv" dann sogar recht ausführlich.

Ansonsten klingt das ein wenig so, als würden PHP-Seiten nicht über "php-cgi" ausgeliefert.

Wenn die Authentifizierung durch den Server erfolgreich war, sollte als "REMOTE_USER" im Environment für den CGI-Aufruf der angegebene Benutzername zur Verfügung stehen.

Ohne konkrete Fehlermeldungen des PHP-Moduls ist aber kaum zu erraten, was da schief läuft ... wenigstens den Inhalt der verwendeten "httpd.conf" hätte ich in so einer Diskussion dann auch als "Grundlage" erwartet - bisher muß man raten, was da wohl enthalten sein könnte. Auch habe ich noch nicht so richtig verstanden, ob das nun eine gesonderte Instanz des "httpd" ist (die 8008 als Port spricht eigentlich dafür) oder ob das in die GUI-Instanz vom Freetz integriert wurde und die dann eben auf 8008 läuft.
 
SQLite3 Datenbanken kenne ich eigentlich nur ohne Benutzer/Passwort Zugriff.
...kann/muss aber die Accountinformationen für das PHP/CMS enthalten.
(Sie sollte wegen der Sicherheit/Datenschutz also nicht im Webspace/downloadbar, sondern an geeigneter Stelle (Benutzer/Gruppenrechte) im (beschreibbaren) Dateisystem abgelegt/geladen werden)

Busybox httpd
Das -r (Realm) kannste vergessen, das wird nur in der Dialogbox (httpd.conf - /baikal:test:test) für Benutzer/Passwort als Info verwendet.

Beispiel: httpd -r "Dukommsthiernetrin"
 
Zuletzt bearbeitet:
Danke für den Hinweis mit "-f -vv"! Über die Ursache findet sich in der Ausgabe leider nichts so direkt Aussagekräftiges:
Code:
[::ffff:192.168.0.9]:6264: url:/baikal/html/cal.php/calendars/test/default/
[::ffff:192.168.0.9]:6264: response:404
[::ffff:192.168.0.9]:6310: url:/favicon.ico
[::ffff:192.168.0.9]:6310: response:404

Wo würde ich denn die Fehlermeldungen des PHP-Moduls finden?

In der httpd.conf steht nur folgendes:
Code:
*.php:/usr/bin/php-cgi

I:index.php

H:/var/media/ftp/uStor01/FRITZ/busyboxhttpd

Der httpd wird als separate Instanz gestartet:
Code:
httpd -p 8008 -c /var/media/ftp/uStor01/FRITZ/busyboxhttpd/webcfg.conf -f -vv

Darüber, wie die Authentifizierung bei Baikal (bzw. sabre/dav, auf dem Baikal aufbaut) gelöst ist, findet sich hier etwas: http://sabre.io/dav/authentication/ Leider verstehe ich davon kaum etwas; Baikal bietet zur Auswahl nur "basic" und "digest".
 
Noch ein Hinweis: Ein "nichtklartext" Passwort machst du mit dem httpd mit der Option -m ...
Code:
 # httpd -m dukommsthiernetrin
$1$4/jnde/l$gTGyFUqvgl58yue9ki9Tl1
...und dann in der httpd.conf ...
Code:
/baikal:test:$1$4/jnde/l$gTGyFUqvgl58yue9ki9Tl1
 
Wenn ich die URL richtig lese, dann klappt das auf diesem Weg mit PHP ziemlich sicher nicht.

Der "httpd" würde ja die Datei bzw. das Verzeichnis "/var/media/ftp/uStor01/FRITZ/busyboxhttpd/baikal/html/cal.php/calendars/test/default/" suchen und darin eine "index.php" (als Default-File) ausliefern wollen. Für die würde er dann allerdings sogar den PHP-Interpreter über den CGI-Wrapper aufrufen, wenn man der "*.php"-Zeile in der httpd.conf folgt.

Das Problem bei der URL dürfte sein, daß hier Teile der URL gleichzeitig angeben, welcher Kalender gemeint ist ... wenn das alles in Query-Parametern liegt (die sind mit "?" von der Pfadangabe getrennt), sieht das ggf. schon wieder anders aus. Hier braucht es aber wohl einen HTTP-Server, der Teile der URL ignoriert oder umschreibt auf eine andere Adresse (rewriting), damit solche (virtuellen) Pfade dann auch verwendet werden können.

Ich kenne jetzt "baikal" nicht (möchte es auch nicht kennenlernen) ... aber der HTTP-Server in der BusyBox ist wirklich nur rudimentär angelegt - eigentlich ideal für solche eher selten genutzten Dienste (da kommen ja sicherlich nicht 3 Requests pro Sekunde rein), aber eben mehr auf statische Inhalte ausgelegt und schon die CGI-Schnittstelle ist vermutlich ein Problem. Das geht dann bei der parallelen Verarbeitung mehrerer Requests weiter und auch ansonsten fehlt dem halt vieles, was einen "richtigen HTTP-Server" ausmacht. Vielleicht bleibst Du doch lieber beim "lighttpd", wenn es damit funktioniert. Der BusyBox-"httpd" ist z.B. ganz witzig, wenn man darüber ein "Let's Encrypt"-Zertifikat für die FRITZ!Box anfordern will.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.