Drupalcenter.de: Serverumzug

Natürlich klappt das !

... hoffentlich geht alles gut....
Backup nich vergessen

Mein Drupal Projekt: http://www.jeloro.de
Web 2.0 Community and more ...

Die Umkopierfunktion ist ja quasi ein Backup ;)
--
"Look, Ma, I'm dead!"
Cell, Stephen King

Juhu, endlich :-) Wünsche viel Glück...

-------------------------------------
Drupal is sächsäää! :-D http://www.flickr.com/photos/8471827@N06/2531785706/

Aber zur allgemeinen Beruhigung habe ich auf dem neuen Server schonmal das nächtliche automatische FTP-Backup eingerichtet und getestet. Scheint soweit hinzuhauen... Würde mich auch wunder wenn nicht, schließlich benutze ich das Ding schon ein Jahr und es hat gute Dienste geleistet. Naja, soweit man das sagen kann, so lange der Ernstfall nie eingetreten ist.. ;-)

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Gerade heute kommt der Serverumzug gut :), denn es kam vorher eine "Too many users" Meldung

Viel Erfolg und Glück!
--------------
Blog www.freeblogger.org: Deutscher IRC-Channel: irc.freenode.net #drupal.de ... Jabber-me: dwehner@im.calug.deXING

Mist, hab ich gar nicht gesehen... ;)

Theoretisch sollte alles gut gehen. Wir haben die letzte Zeit immer mal wieder mit einer Kopie des aktuellen Systems getestet und das ging soweit. Es kann sein, dass es hier und da mal beim Abschicken von Formulardaten einen 500er gibt. Das ist beim Einsatz von ModSecurity nicht so ganz auszuschließen. Darauf muss man dann zeitnah hinweisen, dann durchpflüg ich die Logfiles und deaktiviere die entsprechende Regel.

Mir machen es einfach wie Microsoft und lassen den zahlenden Kunden den Betatest absolvieren. ;-)

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Wir ziehen den Umzug zeitlich ein wenig vor. D.h. innerhalb der nächsten Stunde geht's los und dann sind wir erstmal ein paar Stunden offline...

--
bv - drupalcenter.de

...mal schauen ob alles läuft.

--
bv - drupalcenter.de

also Kommentare funktionieren...

Mal in die YSlow Ergebnisse schauen...

Na, hat doch geklappt...

Was mich interessieren würde, habt ihr einen Managed oder Dedicated bei Hetzner genommen?

Gruß, derhil

Es ist ein dedizierter Rootie mit Debian Etch 64 Bit. Das Managment mache ich irgendwie so nebenher. Speed müssen wir mal abwarten, wie er sich zu Stoßzeiten verhält. Dann kann man noch immer hier und da ein wenig drehen.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

...gute Wahl!

Gruß, derhil

Scheint geklappert zu haben.
Meinen Glückwunsch.

"/ e t c /" (ohne Leerzeichen) geht (fast zu erwartender Weise) nicht durch. Wie macht man das nun eigtl., wenn man mod-security bei einem Root-Forum einsetzt? :)

Interessanter wäre die Frage, ob DAS Root-Forum ModSec2 einsetzt und wenn nein, warum nicht? ;)

Aber um die Frage zu beantworten: SecRuleRemoveById ist dein Freund :)

--
"Look, Ma, I'm dead!"
Cell, Stephen King

... unter der Du also die Regel temporär deaktivieren würdest, wäre wiederum für mich ziemlich interessant. Jedenfalls würde damit ein Sicherheitsloch erzeugt. Du hast ja im Drupal-Textkörper nicht auszuschließender Weise auch zuweilen PHP ... - Aber vergiss es an dieser Stelle - das ist ja jetzt so was von off topic ...

Glückwunsch zum hoffentlich gut gemachten Job,

Nunja, Sicherheit ist immer relativ und im Vergleich zu den Shared Hosting Angeboten der diversen Anbieter, vermitteln mir meine Systeme relativ gesehen mehr Sicherheit. Ob dem objektiv so ist.. wer will das schon ausprobieren? ;)

Maßnahmen, wie eben der Einsatz auch von ModSecurity leisten ihren Beitrag ein System sicherer zu machen. Ich werde mir bald auch mal testeshalber PHPIDS anschauen.. Selbst wenn ich hier und da ein paar Standard-Regeln in ModSec deaktivieren muss (was global ebenso möglich ist, wie auf VirtualHost-Ebene, also auch über .htaccess), mag das die zusätzliche Sicherheit ein klein wenig beschneiden, dennoch untergrabe ich damit nicht gleich das gesamte System.

Interssanterweise ist mir bewusst noch kein Hoster untergekommen, der ModSec einsetzt. Es ist zu vermuten, dass das auch einfach viel zuviel Wartungsaufwand bedeuten würde, denn man weiß ja nie was der Kunde so an Anwendungen programmiert oder sonstwie installiert und ganz schnell ist das Geschrei groß, wenn dann etwas nicht funktioniert.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Es kann heute / die nächsten Tage dann und wann mal ganz kurz (es sollten wirklich schlimmstenfalls wenige Sekunden sein) zu Ausfällen der DB und entsprechenden Fehlermeldungen kommen, wenn ich gerade MySQL neu starte. Ich bin derzeit dabei die Konfigurationsparameter spezifisch auf die Bedürfnisse des DC anzupassen.

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Hallo,

Kann ich das als Aufruf zu einem Hack Wettbewerb auffassen? :-D

-------------------------------------
Drupal is sächsäää! :-D http://www.flickr.com/photos/8471827@N06/2531785706/

Ach, das wäre ja langweilig, denn es gibt gar nichts zu gewinnen - außer einer Ohrfeige, wenn ich den Schuft mal persönlich treffen sollte, der es gewagt hat, .. ;)

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Also heute habe ich zum ersten Mal den Eindruck, dass das DC wirklich deutlich flotter reagiert als gewohnt.
Beifall, Alexander.

Subjektiv empfinde ich das ebenso. Grundsätzlich ist es natürlich von Vorteil, wenn man die Zahl der laufenden Anwendungen überblicken und gezielt daraufhin optimieren kann.

Was mich noch etwas sorgenvoll stimmt, ist die relativ hohe Anzahl ziemlich gruseliger DB-Abfragen. Das mag damit zusammenhängen, dass einige Module hier mal ein Update gebrauchen könnten, womöglich haben die Entwickler jazwischenzeitlich ihre SQL-Hausaufgaben gemacht.

Mehr als 1% aller DB Abfragen dauern 4s und länger. Ich habe noch nicht die Muße gefunden mich durch die Logs zu quälen und zu schauen, welche das sind. Mglw. sind das Abfragen des Cron-Jobs, z.B. zur Suchindizierung. Das wäre dann nicht weiter tragisch. Dann haben wir immer rund 40% aller erzeugten temporären Tabellen (90.000 in den letzten 22 Stunden), die auf die Platte geschrieben werden, ganz egal wie groß oder klein ich die Parameter für Heap- und Temp-Tabellen setze. Das lässt darauf schließen, dass die erzeugten Tabellen BLOB- oder TEXT-Spalten enthalten, denn die kann MySQL nicht In-Memory abbilden. Mehr als 34000 Afragen in den letzen 22 Stunden benutzten einen JOIN ohne passenden Index...
Da gibt es noch einiges zu forschen und ggf. zu optimieren.

Dann hatten wir heute Morgen noch den berühmten White Screen of Death, wegen dem ich das PHP Memory Limit von 96 MB auf 128 MB erhöhen musste, was mir recht viel vorkommt, zumal das DC auf dem Ex-Server mit ich glaube 64 oder 80 MB lief. Wäre interessant zu erfahren, mit was für Settings andere inhaltlich große und komplexe D5-Websites so laufen...

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Die Views, die Views ...

Mag gut sein. Manchmal, wenn ich mir beim Debuggen den SQL Code angeschaut habe, der für manch einen View erzeugt wurde, ist mir auch ziemlich übel geworden. Zum Glück spreche ich noch immer ein paar Brocken SQL und kann mir auch anders helfen, wenn ich mal nen View wirklich nur als Krücke zur Abfrageerstellung und nicht als Datentopf für irgend ein anderes (von Views abhängiges) Modul benötige.

Ich meine bei einem flüchtigen Blick ins Slow Querys Log seien mir ein paar Abfragen bzgl. Userpoints untergekommen....

--
"Look, Ma, I'm dead!"
Cell, Stephen King

Nach ein paar Tagen (mal mehr, mal weniger) setzt es derzeit Probleme mit dem Indianer. Dann steigen die Webserver-Prozesse mit Segfaults aus und hinterlassen dabei den berühmten WSOD. Das Ganze lässt sich derzeit nicht wirklich zurückverfolgen. Mal betrifft es dann nur die Ansicht z.B. der letzten Kommentare, mal die Ansicht aller Posts im Forum. Alle Module, Apache und das komplette System sind auf dem aktuellen Stand. An Modulen läuft nur, was das System zum Leben so braucht.

Nervige Geschichte :(

--
Alexander Langer