PHP als CGI

[schluffi]

SuPhp, hab das mal getestet indem ich im vh die einträge rauskommentiere, dann läuft wieder php 4.3.1 als apache. So sollte das sein denke ich, besonders vorteilhaft auf hosts auf denen plesk oder confixx läuft!

Supi :-D

[blnsnoopy26]

SuPhp, hab das mal getestet indem ich im vh die einträge rauskommentiere, dann läuft wieder php 4.3.1 als apache. So sollte das sein denke ich, besonders vorteilhaft auf hosts auf denen plesk oder confixx läuft!

Supi :-D

Hi,

Also wenn du auch php 4.4.0 als mod_php4 haben willst, was angebracht währe, dann musste leider noch etwas aufwand aufbringen.

- php source ordner löschen und neu entpacken

- in den Source ordner gehen und die selben kompilierungs params verwenden mit dem anhang --with-apxs2=/usr/sbin/apxs2

- Dann kompilieren und make && make install machen, damit haste dann php 4.4.0 als mod_php.

Um es dann noch als CGI wieder zu bekommen die selbe Prozedur nur das ganze dann ohne apxs oder apxs2 je nachdem was du drauf hast.

Zu Empfehlen ist es auch mod_php4 als 4.4.0 laufen zu lassen schon Sicherheitstechnisch gesehn.

Bin darin schon geschult was das php als CGI und suphp angeht :D Weil bei meinem anderen Projekt was ich habe braucht man es und da erkläre ich es fast täglich :D

[schluffi]

Hmm, hab da angst wg. plesk... ich weiss nich :) Ausserdem kämpfe ich gerade noch mit der blöden gd rum. Muss ich das sourcenpaket immer löschen wenn ich kompilieren will?

configure: error: libjpeg.(a|so) not found.
controller:~/php4src/php-4.4.0 #

libjpeg liegt definitiv in /usr

Grüßchen

[blnsnoopy26]

Hmm, hab da angst wg. plesk... ich weiss nich :) Ausserdem kämpfe ich gerade noch mit der blöden gd rum. Muss ich das sourcenpaket immer löschen wenn ich kompilieren will?

configure: error: libjpeg.(a|so) not found.
controller:~/php4src/php-4.4.0 #

libjpeg liegt definitiv in /usr

Grüßchen

Plesk läuft auch unter php 4.4.0 da brauchste keine angst haben.
wegen dem Fehler da musst du das libjpeg devel paket installieren, weil die headerfiles nicht vorhanden sind.

Wegen source ordner löschen das mache ich persönlich immer so, weil es für mich eine saubere variante ist.

Weil brauchst auch das php 4.4.0 als mod php, weil wenn es als apache2 handler läuft, dann hast ja auch eine andere php.ini.

[schluffi]

bzw in usr/lib64 gibts ne libjpeg.so.62 ... mit der kann das php nix anfangen... oh mann

Naja, wir schon mal weiter vom ziel weg. Unter debian war das alles etwas einfacher

[blnsnoopy26]

bzw in usr/lib64 gibts ne libjpeg.so.62 ... mit der kann das php nix anfangen... oh mann

Naja, wir schon mal weiter vom ziel weg. Unter debian war das alles etwas einfacher

hast du suse?

wenn ja, dann gehe mal in yast rein und bei software installieren /deinstallieren und suche da mal nach libjpeg da musstte dann das devel paket auswählen und installieren, dann sollte es gehen, wenn du eh ein 64Bit sys hast sollte es ja eh dabei sein.

[schluffi]

Jepp Suse 9.3, ist ein 1und1, aber sowas von spartanisch ausgerüstet. jetzt fehlt ihm nich libpng obwohl da das devel auch installiert ist. Echt buggy

[blnsnoopy26]

Jepp Suse 9.3, ist ein 1und1, aber sowas von spartanisch ausgerüstet. jetzt fehlt ihm nich libpng obwohl da das devel auch installiert ist. Echt buggy

Schau nochmal genau in yast nach evtl. devel paket neu installieren
und schauen ob es nicht zuhörigkeiten gibt zu dem paket.

Gehn muss es, weil hab selber einen von 1und1 nur halt kein 64Bit sys sondern ein normalo mit confixx und Suse 9.1

[Joe User]

Echt buggy

Richtig, Eure Vorgehensweise ist "echt buggy". Warum nimmst Du nicht die fertigen Pakete Deiner Distribution und ersparst Dir den ganzen Ã?rger?

[blnsnoopy26]

Echt buggy

Richtig, Eure Vorgehensweise ist "echt buggy". Warum nimmst Du nicht die fertigen Pakete Deiner Distribution und ersparst Dir den ganzen Ã?rger?

Sicher kann man fertige RPMS benutzen, aber man braucht nicht jeden mist der mit reinkompeliert wurde und dann stimmen meist die pfade nicht und man hat plötzlich 2 binarys auf dem server.

Hier wird immer gepredigt selber bauen ist immer besser und nu soll man doch fertiges benutzen - wers braucht :-D

Und ich habe noch keine fertigen php 4.4.0 RPM's gesehn nur 4.3.11'er.

[sledge0303]

Richtig, Eure Vorgehensweise ist "echt buggy". Warum nimmst Du nicht die fertigen Pakete Deiner Distribution und ersparst Dir den ganzen Ã?rger?

In anbetracht der *Nutzungsbedingungen* dieses Boards ist es sicherlich nicht an Anfänger gerichtet, aber heisst es nicht learning by doing?
Ich selber informiere mich auch bevor etwas neues angefasst wird, lese Threads, Erfahrungsberichte, Installationsmanuals, frage bei erfahrene Roots nach und manchmal lernt man auch in so einem "buggy" thread ein paar andere sicht- und vorgehenssweisen zur Lösung eines Problems kennen...
ist daran was verkehrt?

Gruss Thomas

[blnsnoopy26]

Richtig, Eure Vorgehensweise ist "echt buggy". Warum nimmst Du nicht die fertigen Pakete Deiner Distribution und ersparst Dir den ganzen Ã?rger?

In anbetracht der *Nutzungsbedingungen* dieses Boards ist es sicherlich nicht an Anfänger gerichtet, aber heisst es nicht learning by doing?
Ich selber informiere mich auch bevor etwas neues angefasst wird, lese Threads, Erfahrungsberichte, Installationsmanuals, frage bei erfahrene Roots nach und manchmal lernt man auch in so einem "buggy" thread ein paar andere sicht- und vorgehenssweisen zur Lösung eines Problems kennen...
ist daran was verkehrt?

Gruss Thomas

Sehe ich auch so. Erst wenn man es selber baut, dann versteht man da was vor sich geht. Habe früher auch nur RPMS benutzt zum updaten. Heute baue ich so gut wie alles selber, weil wenn man es öfter macht, dann prägt das.

Auch wenn was ich hier geschrieben habe nicht einem Profi entspricht sondern alle schritte zerstückele und einzeln mache lernt man auch dabei.

Ich habe es mir so beigebraucht und auch durch das Lesen.
Warum Kompliziert, wenn es auch einfach geht, würden viele sagen, aber ich bin der Meinung so kann man besser lernen und ich für mein teil habe es mir so beibringen können

Jeder so wie er kann - solange zum schluss das Ergebnis stimmt :roll:

[schluffi]

Stimmt.

Das mit libpng scheint ein kleines Problem der Pfade im /.configure zu sein. /.configure geht von /usr/lib/ oder /usr/local/lib/ aus, x64 installiert aber in /usr/lib64/ seine module.
Sind diese module in /usr/lib/ drinn, gehts problemlos!

Grüße Manfred

[sledge0303]

Sehe ich auch so. Erst wenn man es selber baut, dann versteht man da was vor sich geht. Habe früher auch nur RPMS benutzt zum updaten. Heute baue ich so gut wie alles selber, weil wenn man es öfter macht, dann prägt das.

Auch wenn was ich hier geschrieben habe nicht einem Profi entspricht sondern alle schritte zerstückele und einzeln mache lernt man auch dabei.

Ich habe es mir so beigebraucht und auch durch das Lesen.
Warum Kompliziert, wenn es auch einfach geht, würden viele sagen, aber ich bin der Meinung so kann man besser lernen und ich für mein teil habe es mir so beibringen können

Jeder so wie er kann - solange zum schluss das Ergebnis stimmt :roll:

Ich selber beschäfte mich auch erst seit 4 Monaten intensiv mit Debian als Server, hab alleine durch das lesen von Problemthreads viele Lösungen - wenn auch nicht immer 100%ig zutreffend als eigene Lösung, gefunden. Inzwischen kompiliere ich soweit es geht alle Pakete selber, nicht nur Apache2 und PHPs, auch Treiber für Drucker usw.- unter der Voraussetzung das Quellpaket ist verfügbar.
Schreibe dazu kleine Tutorials wie was womit geklappt hat, lege das auf meinen Groupwareserver uffn Laptop und wenn ich bei Kunden oder Bekannten auf ein ähnliches/gleiches Problem treffe, kann man wunderbar nachschauen ohne jemanden mit dämlichen Fragen zu belästigen.
Finde es manchmal Schade wie sehr User durch das verschieben in den *Unerwünscht* Ordner vor weiteren Posts abgehalten werden. Nicht alle sind Anfänger, nebenbei erwähnt!

[blnsnoopy26]

Hi,

Ja damit hast du schon recht. Ich selber, wenn ich einmal was erfolgreich gemacht habe, dann behalte ich das auch im Kopf, aber für etwas kompliziertere dinge mache ich mir auch schon mal notitzen.

Ich habe auch auf nem Produktivserver mit Linux angefangen, aber hatte bisher nie unerwünschten besuch drauf - also das mein Server wurde nie für Warez oder ähnliches mißbraucht.

Erst letztens habe ich mein Apache2 selber kompeliert (2.0.54), weil nicht einmal die suse rpms was gebracht hatten. Kam immer nur Segmentfault etc. durch selber bauen kam dann das Problem nicht mehr

Aber mal wieder zum Thema zurück zu kehren - kann sein das beim 64 bit system bischen anders aufgebaut hat und wenn er ne bibliothek woanders hat macht man ein symlink auf den eigentlichen ordner, dann sollte php es auch finden :)

[captaincrunch]

Wo's ohnehin schon OT ist: beim "kompeliert" läuft's mir jedes Mal kalt den Rücken runter. Keine Ahnung, was der Duden dazu sagt, aber es ist immer noch das Kompilieren.

[blnsnoopy26]

Wo's ohnehin schon OT ist: beim "kompeliert" läuft's mir jedes Mal kalt den Rücken runter. Keine Ahnung, was der Duden dazu sagt, aber es ist immer noch das Kompilieren.

Jaja hast ja schon recht :-D
Kannst ja den Fehler bei eBay verkaufen - achtung Ironie :-D

[schluffi]

:-D

Also um dem ganzen noch einen sauberen Abschnitt zu geben habe ich den Server nochmals reinitialisiert, alle benötigten Pakete und devels installiert (Sind ne ganze Menge, 1und1 war da etwas knausrig). Ich habe festgestellt, das Horde noch dem PHP kompilieren nicht mehr läuft. Hat allerdings mit einer einstellung in der php.ini zu tun (mit der alten läufts). Ich muss jetzt noch beide php.ini´s vergleichen um das problem zu beheben. Was mich jetzt aber noch ganz stark wundert ist das PHP auf console zwar 4.4.0 (cgi) ist, in phpinfo über browser aber immer noch das alte 4.3.

So habe ich kompiliert:

Code: Select all

./configure --prefix=/usr --datadir=/usr/share/php --bindir=/usr/bin --libdir=/usr/share --includedir=/usr/include --sysconfdir=/etc --with-_lib=lib --with-config-file-path=/etc --with-exec-dir=/usr/lib/php/bin --disable-debug --enable-bcmath --enable-calendar --enable-ctype --enable-dbase --enable-discard-path --enable-exif --enable-filepro --enable-force-cgi-redirect --enable-ftp --enable-gd-imgstrttf --enable-gd-native-ttf --enable-inline-optimization --enable-magic-quotes --enable-mbstr-enc-trans --enable-mbstring --enable-mbregex --enable-memory-limit --enable-safe-mode --enable-shmop --enable-sigchild --enable-sysvsem --enable-sysvshm --enable-track-vars --enable-trans-sid --enable-versioning --enable-wddx --enable-yp --with-bz2 --with-dom=/usr/include/libxml2 --with-ftp --with-gettext --with-jpeg-dir=/usr --with-mcrypt --with-mhash --with-mysql=/usr --with-png-dir=/usr--with-tiff-dir=/usr --with-ttf --with-freetype-dir=yes --with-zlib=yes --with-gd --with-openssl --with-curl

und so sieht die phpinfo noch aus:

Code: Select all

'./configure' '--prefix=/usr' '--datadir=/usr/share/php' '--mandir=/usr/share/man' '--bindir=/usr/bin' '--libdir=/usr/share' '--includedir=/usr/include' '--sysconfdir=/etc' '--with-_lib=lib64' '--with-config-file-path=/etc' '--with-exec-dir=/usr/lib64/php/bin' '--disable-debug' '--enable-inline-optimization' '--enable-memory-limit' '--enable-magic-quotes' '--enable-safe-mode' '--enable-sigchild' '--disable-ctype' '--disable-session' '--without-mysql' '--disable-cli' '--without-pear' '--with-openssl' '--with-apxs2=/usr/sbin/apxs2-prefork' 'x86_64-suse-linux' 

Irgendwie bin ich jetzt Ratlos weil Du heute ja gesagt hattest, benutze aspx2 um es komplett für alles bereitzustellen. Oder hab ich das falsch interpretiert?

So, ja, auch wenns manchen wohl nicht so genehm ist würde ich das Topic gerne weiterführen und am Ende zusammenfassend ein HowTo für aktuelle 1und1 Suse 9.3 mit Plesk 7.5 images zusammenfassen.

Grüße manfred

[blnsnoopy26]

Wenn du in der phpinfo was anderes angeziegt bekommst als in der Konsole vermute ich das du nu 2 Binarys auf deinem Rooti hast.

whereis php gibt aufschluss ob dem so ist.
Aber man kann es auch radikal machen :D per yast das alte deinstallieren und dann aus den sourcen Frisch Kompilieren.

Oder du hast vergessen Apache zu restarten.
was dem apxs angeht, wenn du einmal php mit apxs kompilierst, dann kommt mod_php raus und wenn du es ohne machst, dann kommt CGI raus.

Vermutlich hast du es nur als CGI kompiliert und somit erscheint bei der phpinfo die alte Version.

[schluffi]

Achso, hmm :) das heisst erst ohne apxs und anschliessend gleich nochmal mit apxs ? Das habe ich natürlich nicht gemacht. Dumm jetzt irgendwie... ich wollte eigentlich was "sauberes machen". Ich denke Du hast da etwas mehr Erfahrung: Jetzt nochmal ohne apxs komp. und dann mit oder nochmal ganz von vorne :)

Grüßle

[blnsnoopy26]

Hi,

zuerst mit und dann ohne, weil wenn du es umgekehrt machst, dann haste wieder CLI - nur mod_php :D

[schluffi]

Also den ersten Teil habe ich geschafft. Aber leider auch nur wieder mit triks:

./configure mit apxs2 erwartet eine httpd2-prefork.conf , aufgrund der pleskschen architektur gibts nur httpd.conf mit ganz vielen Includes. Demnach kommts zum Fehler. Workaraound:

Code: Select all

cp /etc/apache2/httpd.con /etc/apache2/http2-prefork.conf

und eine Zeile

Code: Select all

LoadModule mod_perl /usr/lib64/mod_perl.so

einfügen.

Danach läuft auf 1und1 Rooti auch ./configure --with-apxs2=/usr/sbin/apxs2-prefork

Naja, nur noch so zur Info :)