[geloest] Klartextausgabe Settings.php

[ageltixx]

Guten Tag. Ich hatte eben das Phänomen, dass der fast komplette Inhalt der Settings.php und der index.php bei Aufruf des Forums auf dem Bildschirm zu sehen war. Grund dafür war, dass in der Zeile 34, unterhalb der Zeile $db_last_error = 1092159942; einmal "?>" stand. Folge: PHP zuende und alles andere fliegt an den Browser. Dabei auch die Zugangsdaten für die Datenbank, was die Sache unlustig macht.

Hat das schon jemand beobachtet? Wo kommt das her?

Der Timestamp der letzten Änderung der Settings.php entspricht (logischerweise) dem og. Timestamp des letzten Errors.

[andrea]

Habe das Problem weitergemeldet. Mit welcher Version trat der Fehler auf? Was für ein Datenbankfehler war das genau?

[ageltixx]

Hi.

Vielen Dank für die Weitergabe.

Ich benutze die Beta 5. Einen Datenbankfehler hab ich gar nicht gesehen, die Logs geben nichts her, was mich noch mehr verwirrt.

[mediman]

Der Datenbankfehler ist irrelevant, das ?> macht mich nervös!

Muss ich mir dringend anschauen.

Übrigens, wenn deine Datenbank nicht auf extern gesetzt ist, dann ist es eher harmlos, bei allem Ärger.

mediman

[andrea]

Muss ich mir dringend anschauen.

Falls Du Dich um das Problem kümmern möchtest Medi, dann guck bitte auch diesen Thread an, welchen ich dazu im Team-Forum eröffnet habe:
http://www.simplemachines.org/community/index.php?topic=15006.0

[mediman]

Bin schon dabei.
danke @andrea

[ageltixx]

Übrigens, wenn deine Datenbank nicht auf extern gesetzt ist, dann ist es eher harmlos, bei allem Ärger.

Ist sie nicht, aber das PW benutzen wir nicht nur da (ja, ich weiss, soll man nicht  )

[mediman]

Übrigens, wenn deine Datenbank nicht auf extern gesetzt ist, dann ist es eher harmlos, bei allem Ärger.

Ist sie nicht, aber das PW benutzen wir nicht nur da (ja, ich weiss, soll man nicht  )

Das ist dann ärgerlich!
Bis jetzt hab ich nix finden können, hab extra einen Datenbankfehler provoziert.
Es ist die 5er oder?
Ist der selbe Unsinn in der Settings.bak.php?

mediman

[ageltixx]

Nein, da ist das nicht. Da steht db_last_error auch auf 0.

Ich hab leider die kaputte Datei nicht gesichert, sondern gleich da drin geändert. Das ?> stand zwischen db_last_error und db_error_send. Vielleicht hilft Dir das weiter.

Edit: Ja, die 5er.

[andrea]

Ich hab leider die kaputte Datei nicht gesichert, sondern gleich da drin geändert. Das ?> stand zwischen db_last_error und db_error_send. Vielleicht hilft Dir das weiter.

Du solltest eigentlich vom Forum eine Email erhalten haben mit einer DB-Fehlermeldung. Ist diese bei Dir angekommen? Falls ja kannst Du die volle Email hier zitieren?

[ageltixx]

Hab ich nicht bekommen. Hab ich noch nie bekommen!

[mediman]

Nutzt du vielleicht einen Editor der fehlende close tags automatisch schliesst?

Ja, die Position ist auf alle Fälle interessant, thx!

medi

[ageltixx]

Nutzt du vielleicht einen Editor der fehlende close tags automatisch schliesst?

Nö. Wenn ich wirklich die Settings "zu Fuss" bearbeite, mach ich das auf Konsole mit dem vi. Zum Zeitpunkt des Auftretens saß ich außerdem im Auto

Ich bin mir also 99%ig sicher, dass das niemand direkt da reingetippt hat.

[mediman]

Naja, hätte ja sein können ...
Aber wenn du ein Alibi hast ... 

Erinnere mich da dunkel an Leute, die hatten mal kurz den YaBB SE Code angeguckt, und ohne was zu ändern abgespeichert...
Resultat: aus den Entities wie z.b. > und < wurden die ASCII Zeichen und nichts ging mehr in der Subs.php!

mediman, der nochmal ne Guckung macht, bevor er sich mit XML weiter quält.

[ageltixx]

Die hatten nicht zufällig den Fehler begangen, den Editor des Conf[us]ixx-WebFTP zu benutzen?

Ich habs jetzt nochmal versucht nachzuvollziehen. Ich hab das ?> einfach auf einer Testkopie des Forums nochmal eingefügt. Das Ergebnis war aber ein ganz anderes. Es wurden nur die beiden restlichen Zeilen der Settings.php ausgegeben, darunter das normale Forum. Beim letzten Mal erschien jedoch fast die komplette Settings.php auf dem Bildschirm. Daraufhin hab ich die Test-Settings und die produktive verglichen und dabei festgestellt, dass in der Produktivumgebung, wo der Fehler aufgetreten war, die Zeile db_last_error zweimal vorkommt. Einmal ganz unten in der drittletzten Zeile, so wie es normal ist, und zusätzlich in Zeile 33, nach mtitle, vor guestaccess. Und hinter dem falschen Eintrag in Zeile 33 muss seinerzeit das ?> gestanden haben, sonst wären ja nicht die später auftauchenden DB-Zugangsdaten ausgegeben worden.

Hier der betreffende Teil:

Code Select Expand

########## Board Info ##########
# Note: these settings must be properly changed for YaBB to work

$maintenance = 0;               # Set to 1 to enable Maintenance mode
$mtitle = "Update";                                             # Subject for display

$db_last_error = 1092159942;
$guestaccess = 1;                               # Set to 0 to disallow guests from doing anything but login or register

$yyForceIIS = 0;                                        # Set to 1 if you encounter errors while running on an MS IIS server
$yyblankpageIIS = 0;                    # Set to 1 if you encounter blank pages after posting (usually on MS IIS servers)

$language = 'german';           # Change to language pack you want to use



Ich hoffe, es war verständlich und hilft weiter.

[mediman]

Ob Confixx oder WebAdmin oder CPanel, alles schlimme Teile, wobei mir Confixx 3 fast wieder gefällt.

Danke für die explizite Erläuterung, so kann man der Sache eher nachkommen.

medi

[ageltixx]

Ob Confixx oder WebAdmin oder CPanel, alles schlimme Teile, wobei mir Confixx 3 fast wieder gefällt.

Danke für die explizite Erläuterung, so kann man der Sache eher nachkommen.

Nur mal interessehalber: Wird diese Variable db_last_error nur aus einem Script geschrieben und wenn ja aus welchem? Vielleicht schaue ich morgen ja auch mal rein, nur mal aus Interesse und ohne Confusixx

[mediman]

Errors.php exactly the function db_error();

medi

[ageltixx]

Ich hab mir das mal angeschaut und würde den Fehler eher in der Admin.php in der Funktion updateSettingsFile vermuten. Kann es da beim Einlesen zu einem Problem gekommen sein?

[mediman]

Ich hab mir das mal angeschaut und würde den Fehler eher in der Admin.php in der Funktion updateSettingsFile vermuten. Kann es da beim Einlesen zu einem Problem gekommen sein?

ja, ist denkbar! und wahrscheinlicher.
kannste mal ne phpinfo(); postulieren?

mediman

[ageltixx]

Die ganze?? Oder brauchste einen bestimmten Teil?

[mediman]

das error_log zeugs reicht! keine pfade, nix

[ageltixx]

Kopiert sich so schlecht... Check your PM.

[mediman]

Thx, wie ich sehe liegt es am PHP-Bug.. nicht am SMF...

Es handelt sich dabei um einen PHP&Apache Bug, der bei großer Last auf dem Server die PHP´s dumped anstatt sie zu parsen...

Das heisst ruft jermand die datei www.meinedomain.tld/bla.php auf bekommt er die bla.php zum download angeboten...

Wenn jetzt ein Script versucht, diese Datei zu includen, dann kommen ganz lustige Sachen bei raus...

Ab der PHP 4.3.5RC1 ist das Problem gelöst.
Für SuSE gibt es den mod_php4 schon für 4.3.8 als Patch für die bisherige 4.3.3!

ftp.suse.com/pub/projects/apache/mod_php4/9.0-i386/apache2-mod_php4-4.3.8-1.i586.rpm
ftp.suse.com/pub/projects/apache/mod_php4/9.0-i386/mod_php4-core-4.3.8-1.i586.rpm
ftp.suse.com/pub/projects/apache/mod_php4/9.0-i386/mod_php4-devel-4.3.8-1.i586.rpm

per

Code Select Expand

wget auf den server ziehen und mit

Code Select Expand

rpm -Uvh mod_php4*.i586.rpm  installen!
danach mit

Code Select Expand

rm mod_php4*.i586.rpm die rpm´s deleten und per

Code Select Expand

rcapache2 restart restarten...

wer mag kann dann die alte gesicherte php.ini (heisst dann php.ini.rpmdsafe deleten (/etc/).

mediman

[Pitti]

dumped anstatt sie zu parsen...

na prima, sachen gibts.
gut, wenn man die chance hat selber upzudaten.


gruß pitti

[mediman]

Die 4.3.3 gehört zum Standard bei den neuen Suse 9ern, das bedeutet faktisch jeder Besitzer eines normalen Hostingpackages ist betroffen.

Und wie die Auslastung der shared Server aussieht wissen wir ja...

mediman

[ageltixx]

So, war ne größere Sache, aber funzt jetzt. Ich hatte noch nen Apache 1.3.X auf Susi 8.1. Update (natürlich mit den passenden Paketen) ging natürlich wieder schief, warum auch immer. Egal, neuer Server mit Suse 9.0 und php 4.3.3, update auf 4.3.8 wie oben beschrieben hat funktioniert. Danke mediman.

[mediman]

Na bitte doch...

Sobald wieder einmal ein relevantes Update verfügbar ist bell ich.

P.S. Beim 1er Apachen gehts e weng anners...

mediman

[ageltixx]

*lol*

Mir isses ja mittlerweile egal, aber wenn ein anderer User vor dem Problem steht....

Wie gehts denn mit Apache 1?

[ageltixx]

Egal, neuer Server mit Suse 9.0 und php 4.3.3, update auf 4.3.8 wie oben beschrieben hat funktioniert.

... bis heute abend. Ich fahre inzwischen mit 
PHP Version: 4.3.8
MySQL Version: 4.0.15
Server Version: Apache/2.0.48

aber immernoch mit der Beta5.

Heute abend sah meine Settings.php So aus:

Code Select Expand


########## Board Info ##########

$db_last_error = 1100281103;


Bisschen wenig, oder?
Hab dann erstmal die _bak zurückgeholt, damit es wieder läuft.

Woran mag es jetzt liegen?

[mediman]

smf bug

bitte auf rc2 updaten ...

mediman

[ageltixx]

Gerade erfolgreich gemacht. Danke.

[mediman]

supi