Beiträge von tbrumm

    Great, jetzt bin ich endgültig von WP2 überzeugt, ich kann endlich wieder richtig damit arbeiten!!! Super Tip, danke....an das Script habe ich echt nicht mehr gedacht....

    :-)

    Performance.....Nachtrag. Ich habs nochmal ein wenig getestet, unter MySQL 4 läuft es wirklich performanter, ich werde mal die alte MySQL DB ein wenig "tunen" und die Indix neu schreiben....mal sehen was passiert...

    OK, ich hab jetzt endlich das WP2 einigermassen schnell am rennen. Nach einiger Sucherei im WP Forum bin ich auf einen Tip gestossen, welcher es dann letzlich doch brachte.

    Durch die eingebaute Pingomatic (Optionen/Schreiben) wird bei jeder Seite wohl eine Verbindung zu den angegebenen Server (u.a. wordpress-deutschland.org bei mir) aufgemacht, wenn die Server langsam antworten, wartet wohl das eigene Blog auf die Antworten - deaktiviert und siehe da, obwohl meine Seite nicht wirklich kleine ist, kann ich sie jetzt in akzeptabler Zeit laden.....

    Torsten

    PS: Bleibt noch das Problem mit dem blöden Editor. Hat jemand eine Idee, warum ich jedesmal, wenn ich ein bestehendes Posting editieren will, der Editor lädt, kurz angezeigt wird und dann wieder auf die normale Seite zurück switcht????

    Hallo nach Östereich, Hallo Monika,

    das die Seite lange lädt, das habe ich auch gemerkt ;-) Mein Problem ist nicht dass die Seite überladen ist, sondern, dass sie unter WP2 etwa 10-20mal länger lädt als unter WP 1.5. Und daher die Vermutung, dass es u.U. mit der alten Apache/MySQL Version zusammenhängt.

    Torsten

    Hi Olaf,

    danke für Deinen Test. Die externen Seiten, welche geladen werden, sind zu 99% auf dem gleich server gehostet - ausnahme ist das Skype und ICQ Plugin - die 600kb sind doch eigentlich OK, der server hat ne 1 gb anbindung - dediziert !!! und die meisten user haben dsl, bei isdn oder modem ist die seite definitiv zu gross - klaro. Mein Problem ist einfach, dass die seite selbst bei mir (DSL mit 10 MBIT und Firma 45MIBT) einfach zu langsam ist. Der server ist definitiv nicht der engpass, habe die seite dort nochmal unter 1.5 am laufen, wo es wesentlich fixer geht.

    Die einzigen Punkte, welche ich noch testen will sind:

    1. die MySQL Version ist uralt
    2. der Apache ist alt
    3. das PHP ist alt.

    Ich werde die heute nochmal auf einem neuen server installieren und da mal schauen, wie sie sich dort verhält....ich vermute aber dass die Kombination apache/mysql das nadelöhr sind....

    Hi,

    habe jetzt ein wenig rumgespielt, habe sowohl mal gzip deaktiviert und wieder aktiviert - kein Unterschied. Habe dann das cache Modul mal installiert und gzip wie beschreiben auch deaktiviert - kein unterschied, es ist und bleibt langsam.

    Auf dem Server (Linux) kann ich beobachten, dass die Kiste nicht wirklich was zu tun hat, die Load geht kaum bis gar nicht über 4% und die Speicherausnutzung ist auch im normalen Rahmen.

    Ich hab echt keine Idee mehr und werde wohl wieder auf 1.5 wechseln :-(

    Torsten

    PS: Wer mag, kann sich ein wenig die Seitenladenzeiten ansehen unter http://www.torsten-brumm.de aber vorsicht, dauert echt ewig....

    Hallo Again,

    weiterhin sind mir einige Performance Issues mit WP 2.0 aufgefallen. Ich habe zum vergleichen noch meine Seite auf 1.5 da und die Unterschiede sind enorm.

    Laden der Seite in WP 1.5: 4 s und in WP 2.0: 20 s

    Umgebung: MySQL 3.23 Max, Apache 1.3 und php4

    Hat jemand eine Idee woran das liegen kann???

    Danke

    Torsten

    Hallo,

    habe gestern auf WP2 upgegraded, die installation läuft auch sehr gut, habe nur ein problem, dass ich keine bestehenden Artikel oder Pages mehr editieren kann, jedesmal wenn ich versuche eine bereits fertige Seite zu editieren, springt WP aus dem Editor immer wieder zur normalen Seitenansicht.

    Wenn ich eine neue erstelle geht es ohne Probleme.

    Hat jemand auch dieses Problem oder eine Lösung?

    Danke

    Torsten

    Gerade bei http://www.heise.de/newsticker/meldung/62827 gelesen, bin mir aber nicht sicher ob WP auch betroffen ist:

    Schwachstellen in PHP-Modulen gefährden zahlreiche Webapplikationen

    Webanwendungen, die auf PHP beruhen und in denen Funktionen für XML-RPC zum Einsatz kommen, laufen Gefahr, geknackt zu werden. Nach Angaben des Sicherheits- und PHP-Spezialisten Stefan Esser sind in PHPXMLRPC und dessen Ableger PEAR XML_RPC Sicherheitslücken enthalten, mit denen Angreifer eigenen PHP-Code einschleusen und im Kontext des Webservers ausführen können. Gemäß der zwei von Esser veröffentlichten Advisorys ist der Fehler in den Funktionen zu finden, die XMLRPC-Anfragen und -Antworten verarbeiten.

    Zentrale Rolle spielt wieder einmal die Funktion eval(), die auch bereits Anfang Juni in den genannten Modulen Löcher aufriss. Esser weist allerdings in seinen Reports darauf hin, dass die Probleme diesmal nicht von fehlerhaftem Escaping von Nutzereingaben herrühren. Stattdessen bietet diesmal die Auswertung der in Dokumenten eingebetteten XML-Tags Angreifern die Gelegenheit, Schadcode auszuführen.

    Zusammen mit den Entwicklern ist man das Problem angegangen und hat eine zusätzliche Prüfung der Tags eingebaut. Darüberhinaus wurden noch sämtliche eval()-Aufrufe eliminiert, um zukünftigen darauf basierenden Angriffen vorzubeugen. Die aktualisierten Versionen von PHPXMLRPC und PEAR XMP_RPC stehen zum Download bereit. Betreiber von Webapplikationen sollten in den nächsten Tagen auf Advisorys der Hersteller achten. Sehr wahrscheinlich sind zahlreiche Content-Management-Systeme und Wikis betroffen. Für das CMS Drupal ist bereits ein Security Advisory erschienen.

    Siehe dazu auch:

    * PEAR XML_RPC Remote PHP Code Injection Vulnerability, Fehleranalyse von Stefan Esser
    * PHPXMLRPC Remote PHP Code Injection Vulnerability, Fehleranalyse von Stefan Esser

    Hi Monika,

    ja gleiches Problem bei mir, achte mal in den Logs des Apache auf /blog/index.php(und dann kryptische URLS dahinter) die kommen meist von Referrern wie *.xroad.com oder *.pulsar.net oder eben diesem *.oho.cc

    Liegen Deine WP's auch unter /blog/ dann schnellsten wo anders damit hin.

    Wenn es bei Dir genau so aussieht, können wir mal mailen und ggf. gemeins gegen die Leute vorgehen versuche. (tob@brummix.de)

    Torsten

    Hallo WP Community,

    ich nutze WP nun schon seit geraumer Zeit, meine Seiten laufen alle unter WP. Seit etwa 3 Wochen stelle ich allerdings fest, dass es massive Angriffe auf meine Seiten (naja, wahrscheinlich auch auf andere) mittels stranger Refferrer gibt.

    Szenario:

    3 von 10 WP Blogs laufen unter /blog/ und genau diese werden massiv angeggriffen. Jeder der Angriffe kommt von Refferrern wie:

    http://buy-phentermine.pulsar.net
    http://online-poker.pulsar.net

    http://order-hydrocodone.olo.cc

    http://seks.bir.ru/xanax.html

    und so weiter. Das Problem: Diese Verbindungen machen jeweils nur Sessions zum Webserver auf, welche dann im TIME_WAIT stehen und nach einem bestimmten Schwellwert (max. Sessions für den Apache) wird ein neuer HTTPD Prozess gestartet, der dann auch wieder mit solchen Verbindungen zugemüllt wird. Zu jedem der Prozesse (httpd) kommen auch neue MySQL Sessions hinzu, so dass nach einiger Zeit so viele Apache's und MySQLd's laufen, dass man mit dem System nicht mehr arbeiten kann.

    Ich habe jetzt erstmal, um der Lage herr zu werden die WP Instanzen aus dem /blog/ Dir verschoben nach /irgendwas und nun sehe ich die Sessions sauber mit einem 404 ins leere laufen, die Performance ist jetzt OK.

    Meine Frage: Hat von Euch das auch schon jemand beobachtet?

    MFG

    Torsten

    Zitat von kinjin

    ...Desweitern wird ja auch die IP gelogt, IPs sind einmalig, und damit über deinen Provider zurückverfolgbar!

    Hi Timo,

    das stimmt per default so nicht ganz. Ja, die IP's werden per default gelogt, aber das Teledinges Gesetzt schreibt auch vor, das die Daten nach round about 6 Woche gelöscht werden müssen und des weitern, wie in den letzten Monaten mehrfach zu lesen war, auch die Speicherung der IP's bei Flatrates NICHT erlaubt ist, ergo hat ein DSL Flatrate User relativ gute Karten unentdeckt zu bleiben, theoretisch, denn Praktisch sieht es eher so aus, dass viele Provider die Daten eh nicht löschen und der Staat das sogar gerne sieht.

    Torsten

    PS: Wer was bloggt oder im Netz veröffentlicht, sollte auch dazu stehen!