Beiträge von Bernd aus No

Hi Ralf,

so alt, wie du es darstellst, ist mein System nicht. Ich habe lauter virtuelle Maschinen unter xen laufen.
Grundlage ist der "c't-Server" vom letzten Jahr (Debian etch).

Alle Maschinen sind auf dem aktuellen Stand, den man mit 'apt-get update; apt-get -y upgrade' erreichen kann.
Natürlich weiß ich, dass es eine neuere Debian-Variante gibt und dass auch Apache, mySQl und PHP sich weiter entwickelt haben.

Ein neues System aufzusetzen bedeutet, neue Hardware beschaffen. Das laufende System wird gebraucht und kann nicht einfach vom Netz genommen werden.

Das Host-System muss mit neuem Debian nachgebaut werden (einen neueren "c't-Server" gibt es leider noch nicht) und alle virtuellen Maschinen müssen portiert werden (einige Hundert GByte).

Ich denke, ein einigermaßen gut funktionierendes System sollte zwei bis drei Jahre laufen, bevor man es gegen etwas Neueres austauscht - zumindest im privaten Bereicht.

Wir sollten die Diskussion an dieser Stelle beenden.
Ich danke allen, die zur Lösung meines Problems beigetragen haben.

Gruß
Bernd

Hi Ingo,

den Hinweis aus das Plugin habe ich nicht die Aufmerksamkeit zukommen lassen, die ihm gebührt.
Ich bin zutiefst zerknirscht!!

Habe das "123 HTTP Transport" installiert.
Wenn "streams" und "fopen" deaktiviert sind, läuft alles wunderbar.

-------- Problem behoben --------

Vielen Dank für deine Hilfe.
Bernd

PS: Beim Aktivieren des Plugin gab es diese Fehlermeldung:
"Das Plugin hat unerwartet 166 Zeichen während der Aktivierung erzeugt. Falls du Meldungen “headers already sent” siehst oder dein Feed nicht funktioniert, solltest du das Plugin deaktivieren oder löschen."
Es scheint jedoch gut zu funktionieren.

Hi sayrue,

meine Blogs laufen auf Rechnern, die bei mir im Haus stehen.
Für einen Umzug auf einen privaten Rechner muss du an die Dateien bei deinem Provider kommen. Gelingt dir dies, ist die Chance groß, dass du alles auf deinen Rechner bekommst.

Du brauchst das Verzeichnis, in dem sich der Quellcode von WordPress befindet, einschließlich aller Unterverzeichnisse. Dann hast du die verwendeten Themes und alle Uploads.
Dann brauchst du die Datenbank (aus vermutlich mySQL) als Export. Diesen Export kannst du in deine eigene Datenbank importieren. Die Daten für den Datenbank-User findest du in der Datei ./wordpress/wp-config.php.

Mehr sollte für einen Umzu nicht nötig sein.

Gruß
Bernd

Hi Ingo,

dein Tipp geht sicher in die richtige Richtung.
Mit tcpdump, netstat und lsof sowie der paralellen Überwachung des Logs von Apache konnte ich sehen,
dass jeder Request von Aussen sofort ankommt.

Nach einem Abbruch des ersten Request und sofortiger Wiederholung funktioniert alles, wie erwartet.
Nach einer Minute (plus knapp eine Sekunde) behebt sich fehlerhafte Zustand von selbst.
Bricht man keinen Request ab, dauert jeder eine Minute.
Bricht man einen ab, kann man anschließend normal arbeiten.
Es darf jedoch keine längere Pause entstehen.
Ist die Pause länger als 25 .. 30 Sekunden, kommt das Programm wieder in den fehlerhaften Zustand.

Während des fehlerhaften Zustands gibt keine Kontaktversuche nach Außen.
Auch meine Firewall liefert keine Hinweise auf abgewiesene Pakete.
Die Maschinen der DMZ dürfen über die Ports 80, 53 und 123 mit der Außenwelt Kontakt aufnehmen,
dies ist bisher immer ausreichend gewesen.

Nun bleibt die Frage, auf was wartet der PHP-Code.
Der Abbruch eines Requests und seine Wiederholung scheint den Programmablauf für kurze Zeit in den richtigen Zustand zu bringen.
Oder man muss dem Programm geben, worauf es wartet - nur was könnte es sein?
Meine Forschungen haben haben keine Hinweise ergeben.

Gibt es ein Forum, in dem man mit den Entwicklern Kontakt aufnehmen kann?
Es geht ja nun nicht mehr um Fragen zur Installation.
Eine Frage der Konfiguration wird es wohl auch nicht sein.
Ich vermute fehlerhaften Code oder Unverträglichkeit in der Betriebssystemumgebung.
Irgend etwas wird erwartet, was in meiner Umgebung nicht vorhanden ist.

Gruß
Bernd

Hi *,

ich habe die letzten zwei Tage einige Testfälle generiert und muss feststellen: meine Überschrift zum Thread ist falsch!

Das Problem ist nicht http oder https sondern sind Unterschiede in den Versionen 2.0 und 3.0 von WordPress.

Um meine Testfälle verstehen zu können, ist die Kenntnis meines Intranets wichtig.
Internet
|
v
Router
|
------------------ privates Netz 172.128.100.x (DMZ)
| : : : |
v v
'Maschine A' 'Maschine wpt'

Alle Anfragen über http (Port 80) und https (Port 443) werden vom Router an die Maschine 'A' weitergeleitet.
In der Maschine 'A' läuft ein apache2-Server, der Anhand der Pfadangabe entscheidet, welche Maschine für die Bearbeitung zuständig ist.
Wenn eine andere Maschine beauftragt wird, erfolgt die Weiterleitung per Apache-Directive ProxyPass.
Die Weiterleitung benutzt immer http, auch wenn der Request per https kam.

Für meine Testfälle habe ich eine virtuelle Maschine 'wpt' erstellt.
Sie bassiert auf debian, benutzt apache2, php5 und mysql5.0.32.
Vier WordPress-Installationen habe ich erstellt, je zwei mit der Version 2.0 und 3.0.
Sie benutzen alle die selbe mySQL-Datenbank, jede Installation hat ihren eigenen Tabellensatz (unterschiedliche Prefixe).

In der Maschine 'A' ist neben apache2 ebenfalls php5 und mysql5.0.32 installiert.
Hier sind zwei WordPress-Installationen erstellt, je eine mit der Version 2.0 und 3.0.

Damit ergeben sich die folgende 6 Testfälle:
lfdNr URL Protokoll WP-Version Ausführung in Maschine
1 http://v-h.homeip.net/wordpress-20/ http 2.0.10 A
2 http://v-h.homeip.net/wordpress-30/ http 3.0.1 A
3 http 2.0.10 wpt
4 http 3.0.1 wpt
5 https 2.0.10 wpt
6 https 3.0.1 wpt

Die genannten URLs können zum Testen verwendet werden ('/' am Ende ist wichtig!).
Zum Test der normalen Geschwindigkeit (ohne Nutzung von WordPress) kann 'mein_script.php' an die URL angehängt werden.
[ Nach Abschluss dieses Threads werde ich die Zugänge wieder verschließen. ]

Die von mir beobachteten Geschwindigkeitsunterschiede durch die interne Weiterleitung sind maginal.
Krass sind die Unterschiede zwischen Version 2.0 und 3.0. Dabei spielt die interne Weiterleitung offensichtlich keine Rolle.

Der Fehler muss an einer ganz anderen Stelle liegen. In der php.ini habe ich das Memory-Limit von 16 auf 48 MByte erhöht, brachte aber nichts.

Diese Diskussion sollte ggfs an einer anderen Stelle des Forums weitergeführt werden. Der Admin möge den Thread bitte verschieben.

Gruß
Bernd

PS: Der Tipp von Ingo hat leider nichts gebracht.

Hi Ralf,

ich arbeite auf meinem eigenen Rechner (bzw. Intranet), nicht über einen Provider. Der Zugang zu meinem Rechner erfolgt über eine DynDNS-Adresse.

Da mein Intranet von Außen nur für wenige Personen geöffnet ist, baue ich gerade an einer offen erreichbaren, virtuellen Maschine, in der ich das nachbilde, was in der geschützten Umgebung nicht funktioniert.

Vielleicht finde ich dabei Unterschiede und kann das Problem lösen. Oder ein freundlicher Zeitgenosse testet von Außen und kann mir helfen.

Gruß
Bernd

Hallo Ralf,

die Inspektion der Variablen _SERVER hat keinen Hinweis auf auf https oder den Port 443 ergeben. Der Request kommt über Port 80, so wie erwartet.

Ich habe auch mal die Function is_ssl manipuliert (sie lieferte immer false) - hat nichts gebracht.

Gruß
Bernd

Hi,

ich betreibe zwei Blogs auf einer Datenbank (die Prefixe unterscheiden sich).
Der eine Blog läuft unter einer sehr alten WordPress-Version (2.0.x), der zweite Blog ist in der Version 3.0.1.

Aus dem Intranet kann ich beide Blogs per http bedienen und dies mit normalen Reaktionsgeschwindigkeiten. Normalerweise benutze ich die Blogs aus dem Internet heraus und verwende https. Die alte WordPress-Version reagiert normal schnell, die neue ist ätzend langsam, bis zu zwei Minuten vergehen, bis man von einem Beitrag zum anderen kommt.

Der https-Request kommt von Außen an meiner Firewall an und wird per Portforwarding auf eine Maschine in der DMZ weiter geleitet. Dort läuft eine aktuelle Apache2-Installation, die die Anfragen abhängig vom Pfad hinter der Domainangabe auf weitere virtuelle Maschinen in der DMZ verteilt (mit der Direktive ProxyPass - der weitergeleitete Request erfolgt mit http).

Diese Technik setze ich seit Jahren ein, sie funktioniert mit alten WordPress-Versionen sowie mit MediaWiki, SVN und WebDav einwandfrei.

Meine Vermutung:

• WordPress in der Version 3.0.x versucht erst eine Antwort mit https (der Ursprungsrequest ist ja https)
• Nach Ablauf eines Timers wird dann auf die Antwort mit http gegeben.

Messungen auf den beteiligten Maschinen zeigen während der Wartezeiten keinen IP-Trafik und keine Aktivitäten der beteiligten Apache-Server.

Gibt es einen Weg, das Verhalten der neuen WordPress-Versionen zu beeinflussen?

Gruß
Bernd

Meine Apache2-Konfiguration auf dem Rechner zum Internet sieht so aus (https
über Port 443):

<IfModule mod_proxy.c>
  <Proxy *>
    Order allow,deny
    Allow from all
  </Proxy>


  ProxyRequests off
  ProxyPass /yyy/ http://192.168.100.250/yyy/
  ProxyPass /yyyWiki/ http://192.168.100.250/yyyWiki/
  ProxyPass /yyysvn/ http://192.168.100.250/yyysvn/
</IfModule>

Auf der Maschine in der DMZ (192.168.100.250) steht in der Apache2-
Konfiguration für die ersten zwei Verweise je eine Alias/Directory-Directive.
Für den dritten Verweis habe ich eine Location-Directive verwendet.

Das Wiki und SVN funktionieren sehr gut und auch WordPress in der alten Version.

Ich habe mal die Vorschläge von von 'codestyling' probiert. Die Blöcke

# Diese Regeln sorgen für das Parsen und Umschreiben der URL’s in HTML Seiten
    SetOutputFilter proxy-html
    ProxyHTMLURLMap https://xxx.homeip.net/ http://192.168.100.250/
    ProxyHTMLExtended On

und

# WICHTIG! Deaktiviert die gzip-Kompression - ohne funktioniert das URL Rewriting nicht
    RequestHeader unset Accept-Encoding

funktionieren nicht - sie führen zu Fehlermeldungen beim (re)start des Apache-
Servers. Wahrscheinlich muss ich dazu noch Module laden.

Die Zeilen

SSLProxyEngine On

und

ProxyPass /yyy/ http://192.168.100.250/yyy/
    ProxyPassReverse /yyy/ http://192.168.100.250/yyy/

haben alleine aber nicht zum Erfolg geführt.

Es folgt noch ein 'Mitschnitt' Vom Tool, das Ammaletu empfohlen hat.

https://xxx.homeip.net/yyy/wordpress/


GET /yyy/wordpress/ HTTP/1.1
Host: xxx.homeip.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.1.16) Gecko/20080702 Firefox/2.0.0.16
Accept: text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Accept-Language: de
Accept-Encoding: gzip,deflate
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Cookie: wordpress_test_cookie=WP+Cookie+check; wordpress_logged_in_4c27c762cc9d5f6ac75be4686a7b3e03=admin%7C1217710221%7C58cc5e27d16f30fda805219318531a9d
If-Modified-Since: Thu, 31 Jul 2008 20:50:21 GMT
Authorization: Basic QmFzaXM6YmFzaXM=


HTTP/1.x 301 Moved Permanently
Date: Thu, 31 Jul 2008 20:51:18 GMT
Server: Apache/2.2.3 (Debian) DAV/2 SVN/1.4.2 PHP/5.2.0-8+etch11
X-Powered-By: PHP/5.2.0-8+etch11
X-Pingback: https://xxx.homeip.net/basis/wordpress/xmlrpc.php
Expires: Wed, 11 Jan 1984 05:00:00 GMT
Last-Modified: Thu, 31 Jul 2008 20:51:18 GMT
Cache-Control: no-cache, must-revalidate, max-age=0
Pragma: no-cache
Location: http://xxx.homeip.net/basis/wordpress/
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Via: 1.1 xxx.homeip.net
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive

Interessant ist die 6. Zeile von unten. Hier wird der Fehler dokumentiert.

Gruß
Bernd

Hi Ammaletu

Ich habe bei den Add-Ons ein Tool gefunden, dass sich als 'Header Monitor' meldet.
Es zeigt jedoch, egal mit welcher Einstellung, keine Infos zu einem Aufruf (auch bei anderen Seiten nicht). Habe ich das falsche Add-on erwischt?

Im WordPress habe ich unter den allgemeinen Einstellungen zwei Optionen, die WordPress-
Adresse (URL) und Blog-Addresse (URL) heißen. In beiden Fällen habe ich https://xxx.homeip.net/yyy/wordpress/ stehen. Diese Optionen gibt es schon in der Version 2.0.10. Gibt es noch eine Stelle? Hattest Du eine andere Option gemeint?

Gruß
Bernd

Hi

Ich betreibe ein Blog (WordPress in der Version 2.0.10) auf meinem Rechner zu Hause.
Über das Internet kann ich zugreifen und alle Funktionen aufrufen.

Ich hatte vor einiger Zeit versucht, auf die Version 2.5.1 umzusteigen.
Die Admin-Seiten waren aus dem Internet erreichbar, nicht aber die Normalseiten.

Die neuste Version 2.6 zeigt das gleiche Verhalten.

Der Zugang zu meinem Blog vom Internet aus ist etwas komplizierter, als es sich die Entwickler von WordPress wohl vorgestellt haben. Ich verwende einen Apache2-Server, der nur über https angesprochen werden kann.
Der Aufruf sieht wie folgt aus:
https://xxx.homeip.net/yyy/wordpress/

Der Apache-Server leitet den Request an eine Maschine in meinem Netz weiter mit der Direktive
ProxyPass /yyy/ http://192.168.100.250/yyy/
Der Request kommt in der Zielmaschine an und wird bearbeitet.
[size=8](Diese Technik verwende ich für unterschiedliche Benutzer und Tools wie SVN, MediaWiki und auch WordPress in der alten Version.)[/SIZE]

Das Problem entsteht dadurch, dass irgendwo in der Verarbeitungsfolge ab /yyy/wordpress/index.php aus der ursprünglichen URL https://... ein http://... wird.

In der Datenbank sind in der Tabelle wp_options 4 Einträge in der Spalte options_value,
die die Zeichenfolge https://xxx.homeip.net/yyy/wordpress/ enthalten.
Darunter sind auch 'siteurl' und 'home'.

Irgendwo im PHP-Kode wird für einzelne Komponenten einer Seite die URL neu zusammengesetzt und dabei das falsche Protokoll verwendet.

Ich habe im Kode viele Stellen gefunden, die auf 'home' und 'siteurl' referenzieren.
Leider habe ich nicht die Stelle finden können, die das Problem verursacht.

Wie gesagt, die Version 2.0.10 verhält sich, so wie ich es wünsche.

Kann mir jemand helfen?

Gruß
Bernd