Apache Server zum Abstürzen bringen

[Guest]

Eine kleines eckiges Klammernpaar schafft das, wovon viele bösartige Hacker träumen:

$key[keys] bringt den Apache gnadenlos zum Absturz, wenn keys ein Array ist.

 

[Sascha Ahlers]

QUOTE (Tuemmel @ Mo 27.2.2006, 19:21) [...] $key[keys] bringt den Apache gnadenlos zum Absturz, wenn keys ein Array ist.

Unter welchen Betriebssystem und welche Apache Version?

Ich bekomme bei dieser Anweisung nur eine Fehlermeldung, da der entsprechende Variablenaufruf nicht korrekt ist.



MfG Sascha Ahlers

 

[Guest]

Hallo Sascha,

Apache/2.0.50 (Win32) mod_ssl/2.0.50 OpenSSL/0.9.7c PHP/5.0.0 Server
unter win nt 5.1

Über eine Fehlermeldung hätte ich mich zweimal auch gefreut.

 

[Sascha Ahlers]

QUOTE (Tuemmel @ Mo 27.2.2006, 19:52)[...] Apache/2.0.50 (Win32) mod_ssl/2.0.50 OpenSSL/0.9.7c PHP/5.0.0 Server
unter win nt 5.1 [...]

Gut, dann werde ich vermutlich nicht betroffen sein.

Ich vermute mal der Hauptauslöser wird die relative fehlerbehaftete PHP Version 5.0.0 sein, welches durch den ziemlich alten Apache noch verstärkt wird.
Bei mir hat er aber bei einen solchen Variablenaufruf bisher immer eine Fehlermeldung erzeugt, zum Absturzt kam es dabei nie, zumindenstens nicht in meiner Testumgebung unter Linux.

MfG Sascha Ahlers

 

[Guest]

Vor einem Update graut's mir mehr als vor ein paar korrigierbaren Fehlern.
Allein von mysql 4.02 auf 5.0 braucht's step by step bestimmt einen ganzen Tag.

Ausserdem funktionierte das neue Apachefriends-Paket Anfang Februar noch nicht
und alles seperat zu aktualisieren fehlt die Zeit.

Gruss

Tümmel

 

[Sascha Ahlers]

Ich hatte bisher keine Probleme mit dem Update von Mysql 4.1.x nach 5.0.x, es lief alles ohne irgendwelche Zwischenfälle weiter, auch wenn ich mich durchaus auf mögliche Probleme eingestellt habe.
MySQL ab Version 5.0.2 bringt auch endlich ein Varchar-Feld mit, welches bis zu 65535 lang sein darf (hat ja lange genug gedauert..., mehr als 5 Jahre habe ich darauf warten müssen

).

Ich habe da weniger Stress mit den Aktualisierung, die laufen bei Linux Debian schön übter apt-get laufen. So muss ich nur eingreifen, wenn apt-get was zu bemängeln hat, oder es handelt sich um (gewünschte) größere Versionssprünge, wie von PHP 4.3 nach PHP 5.



MfG Sascha Ahlers

 

[Mar-T]

QUOTE (Tuemmel @ Mo 27.2.2006, 19:21)Eine kleines eckiges Klammernpaar schafft das, wovon viele bösartige Hacker träumen:
$key[keys] bringt den Apache gnadenlos zum Absturz, wenn keys ein Array ist.

Bei mir passiert da gar nix.. läuft alles munter weiter... Apache/2.0.49, PHP/4.3.4

 

[Guest]

Bei der mysql 5.0 Installation gibt's im alten sowie im neuen Xampp-Paket für windows Probleme mit den Änderungen im Authentifizierungsprotokoll und nur wegen eines subselects war's mir den Aufwand dann nicht wert heraufzusteppen. Mitte März steht aber auf jeden Fall eine Rundumerneuerung an.
Mit php 5.0 bin ich sehr zufrieden.
Mit 64k in einem varchar speichert man ja ganze html-Dateien als screenshots. Bei varchars über 20bytes bekomme ich schon ein schlechtes Gewissen. Als jet-geschädigter kann ich es mir wahrscheinlich nie abgewöhnen bytes zu zählen und die Tabellengrösse soweit möglich unter 500k zu halten, sonst wird eben komprimiert.

Gruss

Tümmel

 

[Sascha Ahlers]

QUOTE (Tuemmel @ Mo 27.2.2006, 23:31)[...] Bei varchars über 20bytes bekomme ich schon ein schlechtes Gewissen. Als jet-geschädigter kann ich es mir wahrscheinlich nie abgewöhnen bytes zu zählen und die Tabellengrösse soweit möglich unter 500k zu halten, sonst wird eben komprimiert.
[...]

Bei 19 Zeichen schon ein schlechtes Gewissen? Ob diese Einstellung unbedingt so gut, würde ich mal leicht anzweifeln, Komprimierung geht wieder auf die CPU und nachher wird nicht mal das Platten-Subsystem ausgelastet, weil die CPU nicht mehr kann. Wohl nicht bei 500 KB, aber ich bin es mittlerweile eher gewohnt in großeren Speichermengen zu denken (bei einigen Sachen geht es auch mal in den zweistelligen TeraByte-Bereich - bisher zum Glück aber nur in der Administration).


Nun, besser als ein entsprechendes Textfeld zu erzeugen, um mehr als 255 Zeichen zu speichern. Immerhin kann man ein Feld vom Typ VARCHAR auch noch begrenzen, ich brauche halt auch mal 350 Zeichen oder ähnliches, außerdem möchte ich in ein Feld vom Typ VARCHAR auch keine Zeilenumbrüche speichern.
Der Speicherverbrauch ist auch etwas geringer beim Typ VARCHAR: Länge + 1 Byte, beim Typ TEXT bzw. BLOB sieht es dann so aus: Länge + 2 Byte.

Aber das ist ja nicht die einzigste Erneuerung in Mysql 5.0.x, es nur ein Punkt, auf den ich schon relative lange warte und mich eigentlich schon damit abgefunden habe, dass dieser wohl nicht mehr erfüllt wird.



MfG Sascha Ahlers

 

[Guest]

Ich komprimiere, indem die Datenbank aktualisiert wird.
Meistens werden Daten über einen umbestimmten Zeitraum gesammelt.
Diesen unbestimmten Zeitraum kann man in Perioden teilen und nach Abschluss einer
Periode alle anfallenden Daten zusammenfassen und archivieren. Wenn ich einmal im Monat ein Datenbankarchivierung durchführe, kommen in 10 Jahren 120 Tabellen dabei raus + 10 für die Jahreszusammenfassung. Die werden der Ordnung halber und aus Performancegründen in einer anderen Datenbank gespeichert. Je nach Art der Daten kann man so um den Faktor 50 bis fast unbegrenzt komprimieren. Ich hab gerade wieder(editiert: das Ergebnis aus zwei Tabellen) eine Tabelle, wo unbegrenzt viele Datensätze auf einen komprimiert werden können, der zu 99% genauso aussagekräftig ist. Welches Ereignis genau in welcher Sekunde passiert ist, spielt doch in der Fülle der Ereignisse keine Rolle.
Die eigentlichen Datenerfassungstabellen werden so entschlackt und bleiben in der Grösse begrenzt.
Von Datenbestandserhaltung halte ich genauso viel, wie ein Unternehmer seinen Aktenkeller.

 

[andreas_grießer]

auf servern, wo viele kunden drauf sind, wo man als admin keinen echten überblick hat, was die leute so für verkrüppelte scriptkonstruktionen laufen lassen, ist es am besten einen apache-überwacher einzubauen.

ein shellscript, welches per cron alle minute mal läuft und checkt ob der apache noch brav buckelt oder ob er abgestürzt ist.

im falle des falles macht das script dann einen harten stop& restart....

 

[Guest]

Für Hoster ist das wohl ein Muss.
Wenn der Server wegen eines scriptfehlers abstürzen kann, stürzt der jedesmal ab, wenn das script geladen wird, solange man das Script nicht blockt, rausschmeisst oder korrigiert.

Bei dem obigen bug gibt's noch nicht einmal eine Fehlermeldung.
Der cron job müsste also noch ins log schauen, welche Seite vor dem Absturz aufgerufen wurde und der Datei zumindest einen anderen Namen verpassen. Dann wär's perfekt.

Genial an mysql finde ich das integer-werte in varchars als integer erkannt und mit Rechenoperationen bearbeitet können. (Da hab ich mal richtig Glück gehabt.)