Beiträge von RHA

    Zitat
    • Webhosting BigEi
    • VPS OsterEi
    • Webhosting SmallEi
    • Root-Server Eierkanone

    Na, da bin ich mal gespannt was sich hinter den Bezeichnungen versteckt .... :S

    Du kannst dich doch per SSH auf den Server einloggen und dein Passwort ändern. Wo ist das Problem?


    Oder du installierst den Server nichnt mit einem Image, sondern von einer der DVDs (oder einen eigenen DVD). Dann musst du zwar die Installation komplet selber übernehmen, hast aber ALLE Einstellungen im Zugriff und bestimmst diese selber. Wie z.B. auch den FQDN / Servernamen.

    ... Viele Menschen haben die letzten Tage ihr Erspartes verloren, da die Kurse im freien Fall sind. Die ersten unserer Kunden die hunderte von Servern im letzten Jahr bestellt haben, bitten um Zahlungsaufschub oder sind zahlungsunfähig. Mining ist ein gefährlicher Hype der den Wohlstand einiger Menschen [...] gefährdet. ...

    Für Netcup als Unternehmen natürlich sehr ärgerlich, wenn Kunden zahlungsunfähig werden. Für die "Miner" habe ich allerdings absolut null Bedauern .... das ist halt als wenn man mit Wertpapieren handelt, man ist von den Kursen abhängig und diese können steigen aber auch fallen. Wer mit Kursabhängigen Vermögen handelt, der muss das Geld dafür übrig haben. Daher investiere ich persönlich auch nur Geld in Wertpapiere, welches ich langfristig nicht benötige, und auf welches ich im Härtefall sogar verzichten kann (auch wenn es trotzdem schmerzt, weil man es quasi "verbrannt" hat).

    Bei meinem Server hat es ca. 45 Minuten gedauert bis Patch und ReBoot durch waren. In der Zeit war die Abfrage der Server-Informationen auch nicht möglich. Also evtl noch ein wenig warten.

    Der TS-Server zeigt dir aber nicht, wo die Pakete verloren gehen ;-)


    Ich bin auch kein Profi im Lesen eines MTR-Protokolls (benötige dabei auch Hilfe), aber bei solchen Problemen ist es halt am besten MTR's in beide Richtungen anzufertigen (von Außerhalb zum Server am besten von mehreren Quellen). Im Protokoll des MTR kannst du dann sehen WO die Pakete verloren gehen. Liegt die Störung im Bereich Netcup, dann kannst du dich an den Support wenden (das kannst du eigentlich immer, der Support wird dir schon sagen wenn der Fehler nicht im Bereich von Netcup liegt).


    Daher würde ich wieder empfehlen : Mache bitte einen (oder mehrere) MTR von außerhalb zum Server (im Rettungsmodus). Der Rettungsmodus ist dabei wichtig, damit keine Fremdsoftware für den Fehler verantwortlich sein kann. Ggf. mache parallel/zeitgleich einen MTR vom Server nach aussen, dann kann man beide Richtungen zur gleichen Zeit (bzw. im gleichen Zeitraum) beurteilen.

    Aber was nützt es bei einer DDos wenn die Firewall (iptables) auf dem Server greift? Der Traffic geht dann bereits bis zu dem einzelnen Server durch und belastet die vorgeschaltete Infrastruktur, wodurch wiederum andere Kunden in Mitleidenschaft gezogen werden. Ab einem bestimmten Punkt bleibt dem Provider (in diesem Fall Netcup) nur die Möglichkeit "den Stecker zu ziehen". Über die Firewall kann das eigene System geschützt werden, damit kein Einbruch möglich ist, und kleinere Attacken können abgewehrt werden, aber mehr ist da wohl nicht drin.

    So,

    ich habe eben nochmal Rücksprache mit einigen Personen gehalten, welche den TS3-Server nutzen. Gestern abend schien alles wieder in Ordnung zu sein. Keine Paketverluste und keine Aussetzer. Ein User hatte zwar 2mal einen 'Connection Lost', da er aber der einzige war (zur gleichen Zeit waren noch andere User online), nehme ich an, das dieses Problem auf User-Seite zu suchen ist.


    Somit denke ich das der Server wieder vernünftig läuft.


    Vielen Dank an den Support.

    Es wurde nun eine Änderung an der Netzwerkinfrastruktur vorgenommen. Zwei MTRs mit einmal 500 Counts und einmal 1000 Counts sind im Rettungsmodus erfolgreich durchgelaufen ohne Paketverluste.


    Ich freue mich aber erst, wenn der Server heute abend unter Last korrekt läuft.

    Ich hatte bisher noch nicht die Möglichkeit ins Rettungssystem zu booten.

    Ich habe das Glück, das auf dem betroffenen vServer nur der TS3-Server und noch Monitorix läuft. Da kann man schnell mal eine Lücke finden und den Server in den Rettungsmodus starten.

    Jaaaa, jetzt hat es mich auch erwischt. Aus heiterem Himmel habe ich plötzlich ständige Paketverluste für ein paar Sekunden (2-5 Sekunden), während derer man die anderen nicht mehr hören kann. Laut den Logs kann ich keine Auffälligkeiten feststellen, und die Serverlast ist deutlich im gesunden Rahmen.


    Da der TS3-Server auf einem vServer läuft ... könnte es sich lohnen mal beim Support nachzufragen ob die den Node mal prüfen könnten?