Probleme nach Update von php

[bl0w]

Hallo Leute,

 

hab ein ziemliche Problem!

 

Hab heute meinen Server ein neues php spendiert und seitdem funktioniert das mit dem Safe_Mode ?berhaupt nicht mehr

 

Folgender fehler:

 

[error] [client x.x.x.x] PHP Warning:  session_start(): SAFE MODE Restriction in effect.  The script whose uid is 10007 is not allowed to access /tmp owned by uid 0 in /var/customers/webs/web8/shobba/inc/global.php on line 3
[Thu May 19 19:56:07 2011] [error] [client x.x.x.x] PHP Fatal error:  session_start(): Failed to initialize storage module: files (path: ) in /var/customers/webs/web8/shobba/inc/global.php on line 3
[Thu May 19 19:56:07 2011]

 

Und das bei jedem User und jeder domain die uids ?ndern sich halt

 

 

/var/www/froxlor hat chown -R www-data:www-data

/var/customers/tmp geh?rt root mit 1777

 

hier noch die phpinfo: http://geg0r.de/phpinfo.php

 

 

Hab jetzt bei den wichtigen domains das safe_mode und openbase dir deaktiviert das soll aber nicht so bleiben.

 

Bitte dringend um hilfe!

 

Vielen Dank.

 

 

Gr??e

 

 

p.s.: es gab anfang april mal einen ?hnlichen fall, hab den thread gelesen aber er hat mir nicht weiter geholfen

[bl0w]

hab nochmal was gefunden evtl k?nnte damit auch eine l?sung gefunden sein:

 

http://redmine.froxlor.org/issues/797

 

 

bin mir aber nicht ganz sicher... vllt hast du ja noch ein testsystem wo du das verifizieren kannst =)

 

 

gr??e

[Alf Gaida]

So per Handauflegen kann ich das nicht best?tigen, vielleicht bin ich aber auch nur zu stumpf. Nachdem ich diverse Sachen ?berpr?ft habe, funktioniert das jetzt alles mit Sid. Ein paar bl?de Typos und vor allem Denkfehler sind hochgekommen. Vor allem habe ich aber wieder die Kontrolle ?ber mein System ?bernommen. Alles, was debian hie?, ist im Zusammenhang mit Web und PHP rausgeflogen. Die PHP-Konfiguration wird jezt nur noch von froxlor und meine Wenigkeit beeinflusst, bei den Anwendungen wie phpmyadmin ist das debian-Ged?ns rausgeflogen. F?r php-Quellen brauche ich keinen debian-Maintainer, der f?r mich entscheidet, wie ich mein Zeug ablege. Da reicht mir Git wirklich aus. Damit waren meine Probleme gel?st. Irgendwie decken sich die Intentionen der Macher von Froxlor und meine eigenen ?ber sinnvolle Strukturen zu bisher 100%.

 

Nachdem ich das auf die beschriebene Art und Weise nachgehalten habe, funktioniert auch Tine2.0 ohne jegliche ?nderung in Quellen und Konfiguration, so dass ich von galoppierendem Schwachsinn und partieller Lese-/Rechtschreibschw?che auf meiner Seite ausgehe.

[Alf Gaida]

access /tmp owned by

- Der meint wirklich /tmp - Einfach mal die Settings pr?fen.

[bl0w]

- Der meint wirklich /tmp - Einfach mal die Settings pr?fen.

 

 

Danke f?r deine Antwort =)

 

Also /tmp is auch auf 1777 gesetzt. Also mit Sticky bit... hab das mal auf 777 gemacht aber trotzdem keine verbesserung

 

Werde heute mal schaun ob ich wieder auf php5.3.3 von den original debian squeeze packeges zur?ck kann und die php5.3.6 von dotdeb zum teufel haun...

Hoffe ein downgrade funzt so einfach

 

Werde euch berichten ob es geklappt hat... ich hoffe nun einfach mal =)

 

 

Greetz

[Alf Gaida]

Das mit dem Sticky meinte ich nicht: der soll imho nicht auf /tmp zugreifen. Was php anbelangt, hat alles in Deinem konfigurierten /var/customers/tmp zu landen. Ich muss zu meiner Schande aber auch gestehen, dass bei den 2 Scripten, die das wie bei Dir falsch gemacht haben, auch erst mal den Schalter umgelegt habe. Wenn ich denne mal Zeit habe, schaue ich, wer schuld ist, Fall 1. ich - dann wird das ge?ndert und die Stelle hier gepostet. Fall 2. Applikationsseitig, dann landet das in deren Bugtracker, ist das im Upstream, es im Upstream. Liegt der Fehler beim Paketieren, dann landet das bei mir bei debian. Die Zeit habe ich aber momentan nicht, dass steht recht weit hinten auf der Liste der Unstimmigkeiten und zu erledigenden Dinge.

[bl0w]

Das mit dem Sticky meinte ich nicht: der soll imho nicht auf /tmp zugreifen. Was php anbelangt, hat alles in Deinem konfigurierten /var/customers/tmp zu landen. Ich muss zu meiner Schande aber auch gestehen, dass bei den 2 Scripten, die das wie bei Dir falsch gemacht haben, auch erst mal den Schalter umgelegt habe. Wenn ich denne mal Zeit habe, schaue ich, wer schuld ist, Fall 1. ich - dann wird das ge?ndert und die Stelle hier gepostet. Fall 2. Applikationsseitig, dann landet das in deren Bugtracker, ist das im Upstream, es im Upstream. Liegt der Fehler beim Paketieren, dann landet das bei mir bei debian. Die Zeit habe ich aber momentan nicht, dass steht recht weit hinten auf der Liste der Unstimmigkeiten und zu erledigenden Dinge.

 

 

Also auch das /var/customers/tmp hat 1777 wie oben geschrieben =) rechte liegen bei root:root was aber vor dem update ja auch ohne probleme geklappt hat.

Bin im moment dabei mein System von dem php5.3.6 zu befreien 2 Pakete hab ich noch und dann wird wieder das original php5 von squeeze installiert...

Weil ich auch immer basteln muss

 

 

Ich vermute ja das das php5.3.6 von dotdeb eine andere php.ini hat und so ein paar einstellungen verschiebt bzw die neue version ein paar neuerungen im bezug auf safemod und openbase_dir hat die hier den stolperstein darstellen...

 

mal schaun ich hoffe es funzt nach dem downgrade auf die php5.3.3 wieder =)

 

bis gleich =)

[bl0w]

so nun kleines Update:

 

Hab die ganzen Pakete von dotdeb (also php5.3.6) inkl. mysql-server und mysql-client und allem was da sonst noch drin war entfernt.

Dann (wenn auch mit a bissal bauweh) wollte er froxlor entfernen wegen den anh?ngigkeiten -> Ok

 

Nun wieder apt-get install froxlor und er hat sich alles was er braucht wieder installiert.

Bei der Frage ob er eine neue php.ini schreiben soll hab ich best?tigt das er die nehmen soll die beim paket dabei ist (also neu erstellen)

Noch 2-3 php5-module nachinstalliert und siehe da:

 

Es geht wieder =)

 

Also schein es tats?chlich ein prob von php5.3.6 von dotdeb zu sein... -> bitte nicht verwenden!!

 

 

Bin nun erstmal froh das es wieder funktioniert. dennoch w?re es schon interessant woran es gelegen hat. Vllt kann ich ja nochwas rausfinden.

Ein Upgrad auf eine neue php version werd ich mir aber in zukunft eher sparen

 

Danke nochmal

 

 

Gr??e bl0w

[Alf Gaida]

Ist doch mal ne Aussage. Dann werde ich mal die Magie von bcompare verwenden und squeeze gegen sid laufen lassen. Da habe ich dann ja wohl ein ?hnlich gelagertes Problem. Wenn sich das best?tigt, waren die Buben von debian mal nicht schuld. (oder vielleicht doch, weil die ?nderung sinnvoll ist. Ich glaub ich muss mir von dem Schrott erst mal einen Plan machen) Ich werde aber meine saubere Sid-Installation nicht durch Squeeze verw?ssern oder wenn doch nur im ?ussersten Notfall.

[bl0w]

Ist doch mal ne Aussage. Dann werde ich mal die Magie von bcompare verwenden und squeeze gegen sid laufen lassen. Da habe ich dann ja wohl ein ?hnlich gelagertes Problem. Wenn sich das best?tigt, waren die Buben von debian mal nicht schuld. (oder vielleicht doch, weil die ?nderung sinnvoll ist. Ich glaub ich muss mir von dem Schrott erst mal einen Plan machen) Ich werde aber meine saubere Sid-Installation nicht durch Squeeze verw?ssern oder wenn doch nur im ?ussersten Notfall.

 

Also ich fahre mit Squeeze ganz gut. Ich vermute das Problem eher bei dem dotdeb-repository... is aber nur ein vermutung =9

 

W?rde mich freun wenn du deine Erfahrung dann noch mitteilen kannst

 

 

Gr??e bl0w

[Alf Gaida]

Ist ja nur so eine Idee - aber da mir eigentlich sid zu alt ist und ich lieber wirklich bleeding fahre, habe ich mich auch schon oft genug geschnitten. Rein von der Papierform beim ersten Blick komme ich schon ins Gr?beln. PHP ist nicht f?r ?berbordende Kreativit?t in der Vergabe neuer Versionen bekannt, das gibt mir zu denken.

php5 5.3.6-11 install ok installed
php5 5.3.3-7  squeeze ftp.debian.org
php5 5.3.6-11 sid     ftp.debian.org
php5/sid uptodate 5.3.6-11

 

Ohne jetzt weiter ins Detail zu gehen - ein apt-get changelog php5 k?nnte schon zur Aufhellung beitragen.

php5 (5.3.6-1) unstable; urgency=low

 * Imported Upstream version 5.3.6
   + PEAR updated to 1.9.2 (CVE-2011-1072)
 * Cherry-pick CVE-2011-1144 from PEAR 1.9.3 (Closes: #546164)
 * Debian packaging:
   + Start using pristine-tar
   + Remove patches merged upstream or otherwise deprecated
   + Move php5-fpm.postrm extras to debian/rules
 * FPM SAPI changes:
   + Set initial chdir to /tmp in www pool (Closes: #601243)
   + Rename main configuration file to php-fpm.conf to match upstream
   + Enable error reporting in init.d file
   + Patch FPM SAPI to use Debian php-fpm.conf as default
 * Fix regression with missing CRYPT_SALT_LENGTH (Closes: #603012)
 * Generate SHA512 salt string when provided salt is null (Closes: #581170)
 * Fix FTBFS with gold or ld --no-add-needed (Closes: #615770)
 * Don't mmap large >4GB files
 * CVE-2011-0441: Be more careful when removing session files
   (Closes: #618489)

-- Ond?ej Sur? <ondrej@debian.org>  Fri, 18 Mar 2011 15:51:50 +0100

 

So per Handauflegen w?rde ich mal sagen, das k?nnte in die richtige Richtung gehen, bedarf aber noch einer Pr?fung. Vielleicht ist ja squeeze dann doch erst mal die Wahl der Waffen.