Apache 1.3.37 + PHP 5.2.2 CGI + More

XML Parsing

Erst mal Danke an cpq für den Apachen mit PHP für die Fritz!Box. Großes Lob!

Ich vermisse nur eine für mich sehr wichtige Funktion, nämlich die des XML parsens mittels "simplexml". Ist das performance-technisch für die FB zu viel, oder warum wurde diese Funktion deaktiviert? Ich bräuchte es, um die XML-Datei von Weather.com auf meiner Seite zu parsen um die aktuelle Wetterlage an meinem Ort als kleines Gimik auf meiner Website zu präsentieren (mit Erlaubnis von weather.com). Wäre aber bestimmt auch interessant für weitere Nutzer um andere XML-Feeds auf den Seiten zu zeigen.

Schon mal danke für eure Antworten...
 
reuzzli;
was ein Zufall, habe gerade eine php Version mit libxml hochgeladen... gerade fertig geworden und jetzt lese ich deinen post ;)
Bislang habe ich xml aussen vor gelassen, da es eine ziemlich umfangreiche Bibliothek ist und nicht so einfach zu kompilieren/patchen war. Heute hat es aber geklappt.
Du bist also nun offiziell der erste Tester dieser php-Version!
 
cpq schrieb:
reuzzli;
was ein Zufall, habe gerade eine php Version mit libxml hochgeladen... gerade fertig geworden und jetzt lese ich deinen post ;)
Bislang habe ich xml aussen vor gelassen, da es eine ziemlich umfangreiche Bibliothek ist und nicht so einfach zu kompilieren/patchen war. Heute hat es aber geklappt.
Du bist also nun offiziell der erste Tester dieser php-Version!

Hi CPQ,
danke für die Datei "php-5.2.2-libxml-zlib-sqlite-mipsel.tar.bz2". Hab sie gerade herunter geladen und in mein cgi-bin entpackt. Leider kommt jetzt ein 500 Internal Server Error. Muss ich noch irgendwelche Dateien anpassen (phpconfig, phpize)? Hab das Verzeichnis schon mit chmod 777 ausgestattet.
Mit "apache-1.3.37-php-5.2.1-cgi.tar.bz2" + "php-5.2.2-mipsel.tar.bz2" lief alles einwandfrei.

Achja, die error.log sagt folgendes:
[Sun May 6 10:26:22 2007] [error] [client 192.168.178.20] Premature end of script headers: /var/media/ftp/USBFlashDrive-Partition-0-1/apache-1.3/cgi-bin/php
php: can't load library 'libxml2.so.2'
 
Zuletzt bearbeitet:
reuzzli,
sieht so aus als hätten wir hier ein ähnliches Problem wie ein paar posts weiter oben. bei einem Aufruf von php -i wirst du feststellen, dass noch eine xml library fehlt... die kannst du aber auch von meinem post aus laden und dann mit
Code:
export LD_LIBRARY_PATH=/pfad/zur/xml/lib
auffindbar machen. wenn apache die php aufruft, besser mit einem shell skript wrapper arbeiten, der den path setzt und dann erst php aufruft. Ist aber doch ziemlich unbequem.

krigaex,
vielleicht hast Du ein paar Tipps, wie man das statische kompilieren von libraries erzwingen kann?

ich bin jedenfalls im Moment überfragt... PHP ist ein ziemliches Biest, die "große" version braucht auch jedes mal eine halbe Stunde bis sie kompiliert ist. Dementsprechend nervtötend kann es sein, wenn man hier den bug finden will.
 
PHP statisch kompilieren

Bei Apache reicht ein -static in den LDFLAGS, bei PHP muß man das Libtool mit -all-static aufrufen, am besten bei sapi/cli/php und sapi/cgi/php, damit man beide Binaries erwischt. So mache ich es in meinem DS-Mod-Paket (schon eingecheckt, kommt im nächsten Patch oder Release). Hier der Patch für configure (mit Dank an olistudent, der mich auf die passende Stelle hingewiesen hat):
Code:
--- configure	2007-05-05 02:06:14.000000000 +0200
+++ configure	2007-05-05 02:00:25.000000000 +0200
@@ -8923,7 +8923,7 @@
     BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -Lnetware -lphp5lib -o \$(SAPI_CLI_PATH)"
     ;;
   *)
-    BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
+    BUILD_CLI="\$(LIBTOOL) --mode=link \$(CC) [B][COLOR="Blue"]-all-static[/COLOR][/B] -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_CLI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CLI_PATH)"
     ;;
   esac
   INSTALL_CLI="\$(mkinstalldirs) \$(INSTALL_ROOT)\$(bindir); \$(INSTALL) -m 0755 \$(SAPI_CLI_PATH) \$(INSTALL_ROOT)\$(bindir)/\$(program_prefix)php\$(program_suffix)\$(EXEEXT)"
@@ -12196,7 +12196,7 @@
         BUILD_CGI="\$(CC) \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(NATIVE_RPATHS) \$(PHP_GLOBAL_OBJS:.lo=.o) \$(PHP_SAPI_OBJS:.lo=.o) \$(PHP_FRAMEWORKS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CGI_PATH)"
       ;;
       *)
-        BUILD_CGI="\$(LIBTOOL) --mode=link \$(CC) -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_SAPI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CGI_PATH)"
+        BUILD_CGI="\$(LIBTOOL) --mode=link \$(CC) [B][COLOR="blue"]-all-static[/COLOR][/B] -export-dynamic \$(CFLAGS_CLEAN) \$(EXTRA_CFLAGS) \$(EXTRA_LDFLAGS_PROGRAM) \$(LDFLAGS) \$(PHP_RPATHS) \$(PHP_GLOBAL_OBJS) \$(PHP_SAPI_OBJS) \$(EXTRA_LIBS) \$(ZEND_EXTRA_LIBS) -o \$(SAPI_CGI_PATH)"
       ;;
     esac
 
Zuletzt bearbeitet:
cpq schrieb:
reuzzli,
sieht so aus als hätten wir hier ein ähnliches Problem wie ein paar posts weiter oben. bei einem Aufruf von php -i wirst du feststellen, dass noch eine xml library fehlt... die kannst du aber auch von meinem post aus laden und dann mit
Code:
export LD_LIBRARY_PATH=/pfad/zur/xml/lib
auffindbar machen. wenn apache die php aufruft, besser mit einem shell skript wrapper arbeiten, der den path setzt und dann erst php aufruft. Ist aber doch ziemlich unbequem.

:noidea: Also ich muss mich jetzt mal aus DAU outen - ich verstehe nur Bahnhof. Ich habe einmal php -i aufgerufen und da kommt html output in der konsole. Im error.log ist seit neuestem auch absolut kein neuer Eintrag mehr. Es kommt weiterhin der 500 Internal Server Error. Bin jetzt wieder auf die "normale" Version von PHP 5.2.2 zurück gegangen, jetzt läuft meine Seite wenigstens wieder. Anscheinend bin ich als Tester ungeeignet ;) Habe auch keinen MOD am laufen. Evtl. kommt daher der Fehler.:confused:
 
Gute Nachricht für Dich: cpq wird mit meinem Patch eine DAU-freundliche, statisch gelinkte Version bauen können, die das überflüssig macht.
 
Besten Dank an kriegaex für den Tipp. Die php binary ist jetzt natürlich noch größer geworden (5243588 bytes), aber dafür scheint es jetzt zu laufen.
Die binary findet ihr wie immer am Anfang des threads.
 
Statisch gelinkte Binaries für 2.4 und 2.6

Ich habe mal die statischen Binaries für Kernel 2.4 bzw. uClibc 0.9.26 mit dem oben beschriebenen PHP-Integer-Fehler auf meiner Box unter Kernel 2.6 laufen lassen. Auf die Idee hätte ich vorher auch kommen können, denn da sie ja statisch gelinkt waren, hätten sie bei mir auch laufen sollen. Es trat aber der gleiche Fehler auf. Demzufolge scheint an der Toolchain des alten DS-Mod 0.9.26-p8 irgendetwas nicht zu stimmen.

Folglich habe ich die statischen Binaries einfach unter ds26-14.4 für Kernel 2.6 bzw. uClibc 0.9.28 gebaut. Die laufen wunderbar und sollten auch unter Kernel 2.4 ihren Dienst tun, was Ihr dann wieder testen solltet, da ich nur die eine Box habe. Ich würde mal sagen, zu 90% sollte es glatt gehen.

Download immer noch unter Posting #42.
 
kriegaex schrieb:
Gute Nachricht für Dich: cpq wird mit meinem Patch eine DAU-freundliche, statisch gelinkte Version bauen können, die das überflüssig macht.

Juhuu!!! Danke an kriegaex und cpq! Es funktioniert. Jetzt hüpft grad ein kleiner froher DAU auf seiner grünen sonnigen Wiese und freut sich des Lebens. :dance:
 
Aaaah - ich Idiot! Jetzt weiß ich auch, warum es mit 2.4 gebaut nicht ging. Ich habe mit Soft-Float-Support gebaut, aber das ist ja in der in den AVM-Firmwares enthaltenen uClibc-0.9.26 nicht aktiviert. Also muß ich
  • entweder ohne Soft Float bauen, dann müßte es sowohl statisch als auch dynamisch gelinkt auf den Boxen klappen (statisch erfolgreich getestet, mit 2.4 gebaut, auf 2.6 laufen lassen).
  • oder mit Soft Float und selbst gebauter uClibc (SF eingeschaltet) statisch linken, das sollte auch gehen.
Falls also jemand Interesse an dynamisch gelinkten Binaries für 2.4er-Firmwares hat, möge er sich melden.

Die statischen mit uClibc-0.9.26 sind übrigens auch ein wenig kleiner als die geposteten mit 0.9.28, macht aber nicht viel aus (14 KB bei Apache, ca. 40 bei PHP).
 
Hi

ich hab da mal ne frage

ich hab debian auf meiner usb platte laufen, die platte habe ich mit volgenden befehlen gemounted:
mkdir /var/mod/home/ftp/uStor01
modprobe ext3
mount /dev/sda1 /var/mod/home/ftp/uStor01 -t ext3 -o noatime
chown samba:users /var/mod/home/ftp/uStor01
mkswap /dev/sda2
swapon /dev/sda2
mount --bind /dev /var/mod/home/ftp/uStor01/dev
mount -t proc none /var/mod/home/ftp/uStor01/proc
mount -t devpts devpts /var/mod/home/ftp/uStor01/dev/pts


dann habe ich einen

chroot /var/mod/home/ftp/uStor01

um root darauf zu legen

wenn ich jetzt den script hier ausführe:
#!/bin/sh
#send script to background so the other stuff in debug.cfg will get executed
for x in 1; do
#Wait until we have a network connection.
#Script can be disabled by removing network cable
#either http://web.de or www.google.com must respond to ping
while !(ping -c 1 web.de>/dev/null) && !(ping -c 1 www.google.com>/dev/null)
sleep 15
done

#Wait until drive has been mounted
while !(mount | grep -q /var/media/ftp); do
sleep 15
done

#Look for start script on usb disk
BASEDIR=/var/media/ftp/*/FritzBox
for f in $BASEDIR; do
cd $f
if [ -x boot.sh ]; then
./boot.sh
fi
done
done &

natürlich mit abgeänderten pfaden, komme ich nicht mehr an meine platte und auch nicht an den dsmod

führe ich den script nur auf :

WEBSERVER_IP=10.0.0.2
USB_DISK_ROOT=/var/media/ftp/$(ls /var/media/ftp/ | sed -n 1p)
APACHE_DIR=$USB_DISK_ROOT/FritzBox/apache-1.3.37

if !(ifconfig | grep -q $WEBSERVER_IP); then
ifconfig eth0:1 $WEBSERVER_IP netmask 255.255.0.0 up
fi
if [ $(ps w | grep -c $APACHE_DIR/apache) -gt 1 ]; then
echo "Apache running, killing Apache"
killall apache
fi
echo Starting Webserver \(apache 1.3.37\)
$APACHE_DIR/apache -f $APACHE_DIR/conf/apache.conf

bekomm ich den fehler :
line 14: syntax error: unexpected end of file


was mache ich falsch ???:confused:

oder wie muss ich das script ändern das es funzt ???

mfg
 
HIB HIB HORAY !!

:dance:

PHP WORKS !

hm.. die libs machen 3mb aus ? krass...

THX TO: kriegaex, cpq, ... :groesste:
 
WAHNSINN!!!

Wie schon vom Piraten erwähnt, es funktioniert!!!!
Deshalb an dieser Stellen ein RIESENLOB und ein FETTES DANKE an alle, die hier mitgeholfen haben!!!

:p :p :p :p :p
 
Hallo zusammen,

das Rundum-Sorglos-Paket (Apache und PHP) wird derzeit wohl nicht zum Download angeboten, oder? Ich habe mir Apache jetzt seperat aus dem ersten Posting gezogen und PHP in den Ordner cgi-bin verfrachtet. Jetzt fehlen wohl noch die Einträge in der apache.conf, damit PHP auch geladen wird. Kann mir jemand auf die Sprünge helfen?

Danke im Voraus. ;)
 
FritzKatze schrieb:
Kann mir jemand auf die Sprünge helfen?

Thread lesen, insbesondere Posting #1?
Signatur zulegen?
 
Thread lesen, insbesondere Posting #1?
Habe ich selbstverständlich mehrfach getan, bevor ich hier gepostet habe.

Im Einsatz habe ich derzeit apache-1.3.37 in Komination mit php-5.2.2-mipsel aus dem ersten Beitrag. Die PHP-Files liegen im Ordner cgi-bin. Apache läuft und php ebenfalls, sofern es manuell aufgerufen wird. Apache weiß mit PHP derzeit nichts anzufange, sodass der Quelltext der PHP-Dateien im Browser ausgegeben wird.

Im Thread ist noch die Rede von einem Paket namens apache-1.3.37-php-5.2.1-cgi.tar.bz2, das ich aber nicht finden kann. Es scheint PHP bereits zu beinhalten und entsprechend vorkonfiguriert zu sein.

Signatur zulegen?
Ist erledigt. ;)
 
In die apache.conf folgendens eintragen:

Code:
ScriptAlias  /cgi-bin/      /var/media/ftp/<USB_DEVICE_NAME>/apache-1.3/cgi-bin/
Action  php-script      /cgi-bin/php
AddHandler      php-script      .php

... und "<USB_DEVICE_NAME>" entsprechend anpassen...
 
FritzKatze schrieb:
Im Thread ist noch die Rede von einem Paket namens apache-1.3.37-php-5.2.1-cgi.tar.bz2, das ich aber nicht finden kann. Es scheint PHP bereits zu beinhalten und entsprechend vorkonfiguriert zu sein.

Dann hat cpq wohl umgebaut bei den Downloads, das war mir entgangen. Dementsprechend entschuldige ich mich für die unangemessene Bemerkung. Ich habe das Paket bei mir noch auf der Platte und benutzte es als Basis, die beiden Programme in diesen Versionen in den DS-Mod einzubauen.
 
holofox schrieb:
In die apache.conf folgendens eintragen:

Code:
ScriptAlias  /cgi-bin/      /var/media/ftp/<USB_DEVICE_NAME>/apache-1.3/cgi-bin/
Action  php-script      /cgi-bin/php
AddHandler      php-script      .php

... und "<USB_DEVICE_NAME>" entsprechend anpassen...
Danke für den Hinweis. So ähnlich versuche ich es schon seit einer Weile.

ScriptAlias /cgi-bin/ /var/media/ftp/USBMassStorageDevice-Partition-0-1/FRITZ!Box/apache-1.3.37/cgi-bin/
Action php-script /cgi-bin/php
AddHandler php-script .php
Das ist der aktuelle Stand. Leider werden die PHP-Files nach wie vor im Quelltext ausgeliefert. Mit dem Unterschied, dass sie jetzt nicht mehr direkt im Browser angezeigt werden, sondern erst, wenn ich mir den Quelltext der Seite ansehe. Die hat übrigens den folgenden Inhalt:


Der Pfad zu PHP scheint korrekt zu sein. Wenn ich diesen minimal ändere, erscheint gleich eine Not Found-Meldung.
 

Zurzeit aktive Besucher

Neueste Beiträge

Statistik des Forums

Themen
246,061
Beiträge
2,245,351
Mitglieder
373,491
Neuestes Mitglied
Nana2000
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.