FEUERWERK.net Die unmittelbare Zukunft von FEUERWERK.net

Dieses Thema im Forum "Ankündigungen, Regeln, Gewinnspiele" wurde erstellt von Pyro, 10. November 2005.

  1. Hängt auch mit Firefox...
     
  2. sehr merkwürdig. also unterhalb des tickers hängt bei mir nix was auch immer ich versuche (IE, FF; opera, XP, 2k, NT nur nen alter konquerer meldet "connection lost).
    das nachhängen wenn die seite bereits komplett aufgebaut ist lässt sich aber reproduzieren. es wäre wirklich interessant rauszukriegen WAS er da eigentlich als nicht beendete Übertragung erkennt... .
     
  3. Dem sollten wir nachgehen - habe das KeepAlive aber ersteinmal wieder abgeschaltet.

    Bei mir daheim auf Athlon64 mit Firefox 1.0.7 oder IE 6 unter XP Home hängt nichts, weder in der Mitte noch nach dem Laden. An einem anderen Rechner im Büro kann ich dagegen beide Fehler deutlich im Firefox 1.0.7 unter W2003Server nachvollziehen...
     
  4. Hallo!

    1. Wenn curl nicht benötigt wird hat sich das aber erledigt. libcURL ermöglicht Aufrufe, um Inhalte von anderen servern "on the fly" per ftp/http/..... einzubinden und hat(te) offensichtlich ein Problem mit "keep-alive on" im httpd, da es die "durchgereichte" Verbindung zu lange (keep-alive timeout) offengelassen hat. Dann würde sich mal ein update auf libcurl 7.15.2 lohnen (aktuell). Im Falle einer eingebundenen Werbung würde also sowas dann Fehler wie den, der hier auftritt, hervorrufen. Da Du es ja aber nicht verwendest hat sich das erledigt - die cURL aufrufe müssten direkt im PHPcode geschehen. Ich weiss zwar nicht ob vbulletin intern cURL verwendet, da es aber hauptsächlich drum geht fremder serverinhalte einzubinden denke ich nein.

    2. Um rauszukriegen WO das Problem eigentlich steckt (HTML-code / PHP code / Serverconfig) habe ich die Startseite von www.feuwerk-forum.de mal als HTML-seite abgespeichert, "as is" auf einen andren server kopiert, dort ein langes keep-alive im httpd aktiviert und die Seite geladen --> keine Hänger (auf einem Rechner, der diesen einen Hänger (X Sekunden warten nach laden der kompletten Seite) sicher zeigt. Natürlich wurden die enthaltenen Grafiken etc. nicht eingebunden (was die Aussagekraft auf den reinen html code reduziert und nur Fehlerchen wie "ich versuche 404 nachzuladen" ausschliesst). Um daraus sinnvollere Schlüsse zu ziehen würde ich vorschlagen:
    a) Abspeichern der HTML Seite und diese Seite auf www.feuerwerk-forum.de/test/test.html (oder, unterverzeichnis wichtig!, s.u.) legen und keep-alive im httpd aktivieren. Kann man diese seite, die dann ohne grafiken oder ähnliches kommt, ohne Hänger sehen --> es liegt nicht am HTML code. hat sie Hänger --> es steckt im HTML code.
    b)das tag <base=www.feuerwerk-forum.de> im html code einfügen bzw. die test.html in das / verzeichnis des webservers verschieben. Seite erneut laden. Wenn es nicht hängt liegt es nicht am HTML code UND nicht an den eingebundenen Grafiken, die nachgeladen werden. --> Es muss intern im PHP stecken, der irgendwas nicht beendet.
    Wenn es hängt --> es liegt an einer serverconfig (Beispiel: ich erreiche beim Laden die max. Grenze der Verbindungen (es gibt doch maxconn im PHP und im httpd zu konfigurieren soweit ich weiss) des servers, da ich die alten Verbindungen offen lasse aber irgendetwas wird durch eine neue Verbindung runtergeladen, Diese darf ich aber erst öffnen nachdem durch schliessen der alten Verbindungen maxconn/IP <X geworden ist...) ODER an einem durch das nun mögliche (da die verknüpfungen ja nun tun) aktivieren eines eingebundenen scripts (die Möglichkeit das ein bestimmtest Bild für den Fehler verantwortlich ist halte ich erstmal für unrealistisch).
    Um nun noch zu entscheiden, ob ein eingebundenes automatisch auch aus der statischen html-Seite aufgerufenes script schuld ist (ist das überhaupt der Fall? im stil von "frame source= xyz.php" habe ich in der startseite nichts gefunden... da hast Du den Überblick und kannst es vielleicht gleich auf 2-3 php-scripts einschränken oder was am schönsten wäre ausschliessen, weil sämtliche PHP verweise nur echte links sind und nicht onLOAD geladen werden) würde ich mittels suchen-ersetzen jedes php in der test.html durch php2 ersetzen. Sollte nichts an den eingebundenen Grafiken ändern, per aktivem click aufgerufene pp module gehen dann logischwerweise nicht, was in der test.html ja aber völlig egal wäre. Seite hängt dann nicht mehr --> es lag an einem sich bei aufruf der ladenden Seite startenden Script (welches man danach einzeln betrachten könnte oder aber wieder auf ein generelles PHP / keepalive Problem schliessen könnte).

    3. Hatte der alte Server keep-alive=on? Damit liesse sich klären ob es sich um ein generelles Problem handelt oder eines, welches erst jetzt auftritt. Wenn der alte server keep-alive=on gesetzt hatte, würde es sich vielleicht lohnen einmal die übrigen Parameter im PHP/httpd zu vergleichen ob irgendeine setting offensichtlich abweicht.

    Soweit erstmal ein paar Vorschläge...

    Gruß,

    ivhp
     
  5. vielen dank schonma. wir werden es bei zeiten genauer unter die lupe neben ;)
     
  6. Hallo ivhp,

    besten Dank für Deine Überlegungen!

    Ich denke nicht, dass vBulletin solche Aufrufe tätigt. Externe PHP-Quellen werden wir folgt eingebunden:
    PHP:
    ob_start();
       include(\
    "http://host/irgendwas.php");
       
    $variable ob_get_contents();
     
    ob_end_clean(); 
    Im Code wird dann nur noch die $variable angegeben. Aber ich werde mal die Scripte auf der Festplatte nach curl durchsuchen lassen, um ganz sicher zu gehen.

    Versuche wird am Wochenende durchgeführt, um Klarheit zu schaffen.


    Genau das werde ich sowieso machen, um überflüssige Apache und PHP-Module ausfindig zu machen und auszukommentieren.

    Übrigens - von Anfang an hängt auch der http://webring.feuerwerk.net im Firefox am Ende nach. Und das auf einem völlig anderen Server... ;)

    Vielen herzlichen Dank,
    Gruß und Schuss
    Markus von FEUERWERK.net
     
  7. Die unmittelbare Vergangenheit ...

    Heute (2005-11-25) gegen halb zwölf am Mittag war das Forum plötzlich seeehr träge. Feuerwerk.net und div. fremde Seiten liefen einwandfrei. Zugang über GMX/T-Com-Backbone.

    Während der letzten 3/4 Stunde wurde es wieder (fast) normal. DNS-Hänger oder DoS-Angriff?
     
  8. Der Server, auf dem die Chat-Benutzer-Liste liegt, ist (war?!) weg - das blockierte include der Liste führte zum Ausfall des Forums. Ich habe die Chat-Liste deshalb abgeschaltet.

    Eigentlich hättest Du aber keine Seiten im Forum aufrufen können, also nicht nur träge, nur FEUERWERK.net und Album sind von dem include unbeeinflusst. Das Forum sollte also eigentlich "weg" (nicht erreichbar) gewesen und dann gegen 12 Uhr plötzlich wieder vollständig da gewesen sein. Hänger wären merkwürdig...

    Aber danke für den Hinweis!
     
  9. Geht der neue Server schon in die Knie? Der große Ansturm steht dem Server ja noch bevor. Und im Dezember gibt es sicher zahlreiche neue User.
     
  10. Ähhhh - tatsächlich hatte ich jetzt drei Meldungen. Also alles, was zwischen 11:30 - 12:05 passierte, sollte geklärt sein.

    Stimmt sonst noch etwas nicht?
     
  11. Mir ist nur aufgefallen, dass ich für ein paar Min. nicht ins Forum kam oder irgendwas machen konnte.
     
  12. Wir sind immer noch in der "Perfekte-Konfiguration-Findungsphase" - da kann es schon nochmal zwischendurch krachen.

    Ganz wichtig ist dann, dass Ihr mir per eMail/PN/hier im Thema GENAU bescheibt, wann Ihr was GENAU gemacht hat und was GENAU dann nicht ging, bzw. wie sich das Forum verhalten hat.

    Ein "geht nicht" hilft leider nicht wirklich...

    Besten Dank im voraus!
     
  13. Derzeit ziehen sämtliche statische Seiten der FEUERWERK Homepage um - keine Panik, das dauert hoffentlich max. einen Tag - dann ist alles beim alten oder besser beim neuen (Server)...

    Also nicht wundern, wenn unter FEUERWERK.net steht "Diese Domain wurde im Kundenauftrag registriert" - das war so angekündigt und soll genau so sein. Sobald ich selber wieder Zugriff habe, gehen die Seiten auch wieder ;)
     
  14. Hallo,

    seit mindestens heute morgen erhalte ich keine Benachrichtigungs-mail mehr wenn ich eine PN erhalte. Um sicherzugehen, dass es nicht nur mir so geht wurde es eben mal von Kamikoze aus dem chat gegengeprüft --> auch keine Mail.
    Kein dringendes Problem aber wahrscheinlich auch keine Absicht?

    Gruß,

    ivhp
     
  15. Kannst Du nochmals die eMails überprüfen, bitte?
     
  16. Bei mir kommen die Benachrichtigungen
     
  17. Vergesst es Problem hat sich gerade geklärt... ich hab im Forum eine gmx Adresse eingetragen die an meine eigentliche weiterleitet.. und gmx filtert seit HEUTE feuerwerk.forum mails als Spam (?). Natürlich wie es sein muss hatte Kamikoze auch eine gmx Adresse --> gleiches Problem.
    Hab direkt die Email Adresse eingetragen an die geforwarded wird --> nun geht's.
    Danke und Sorry für die unnötige Mühe...

    ivhp
     
  18. Ich habe heute oder so in der vB-Konfiguration den mail() -f Parameter testweise entfernt. Das könnte bei einigen Mail-Providern zum bösen Ausfiltern unserer eMails führen. Habe ihn jetzt wieder angeschaltet, d.h. wenn es bei Dir, @ivhp jetzt wieder klappt, weiß ich Bescheid ;)
     
  19. @ivhp - genau das meine ich - bitte nochmals in der ursprünglichen Variante prüfen!
     
  20. geht auch mit gmx

    jetzt geht es auch mit gmx wieder - danke!
    Dann lag es tatsächlich daran und die waren sogar halbwegs unschuldig :)
     
  21. na dann bleibt der -f Parameter an - was immer der besagt, muss mal auf php.net nachlesen ;)
     
  22. Der -f heißt wohl nichts anderes, als dass mit Sendmail gesendet wird. Sonst vermutlich via SMTP. ;)
    Wäre dann die Frage, inwiefern sich die Sendmail-Mail von der SMTP-Mail unterscheidet, dass gmx die SMTP-Mails filtert...? :dontthinkso:
     
  23. SMTP ist doch nur das Protokoll (simple mail transfer protocol). egal wie das mail generiert wird - es geht immer via SMTP raus. möglicherweise hat PHP eine eigene email-engine die an Stelle von sendmail benutzt werden kann - ich vermute jedoch das -f bezieht sich lediglich auf die Absender-Email-Angabe:

    X-Authentication-Warning: srv008.msg.de: apache set sender to [email protected] using -f

    findet sich in dem Mail-Header.
     
  24. Hmm, man lernt doch nie aus ;)
     
  25. Kann es sein, daß GMX Mails als Spam identifiziert, bei denen der absendende Server nicht zum angegebenen Absender passt? IP-Adressen und/oder Domain-mäßig?

    Oder weil im Moment wegen Umzug o.g. Diskrepanzen auftreten?
     
  1. Diese Seite verwendet Cookies, um Inhalte zu personalisieren, diese deiner Erfahrung anzupassen und dich nach der Registrierung angemeldet zu halten.
    Wenn du dich weiterhin auf dieser Seite aufhältst, akzeptierst du unseren Einsatz von Cookies.
    Information ausblenden