Beiträge von [netcup] Kai S.

    zur Erläuterung:

    wir senden den Kunden in solchen fällen einen netflow dump mit. die einzelnen werte sind dann in der Regel in der folgenden Reihenfolge angegeben:

    Code
    Src IP Addr:Port    Dst IP Addr:Port    Date flow start    Date flow end    Packets    pps    Bytes    bps

    Zusätzlich zu diesem Output der nun hier aufgelistet wurde, ist die Angabe "Aggregated flows" relevant, auch diese Angabe ist in der Abusemeldung zu finden.

    Man könnte ja jetzt spekulieren und sagen, dass dieser Produktname nur gewählt wurde, um die weniger erfahrenen Kunden mit dem Glauben an einen "richtigen" Root-Server zu locken.. ^^

    Und ein vServer ist kein Root Server? die Begrifflichkeit sagt nur aus "Sie erhalten Root Zugriff". Alles andere ist ein Überinterpretation des Begriffs. Wenn es kein virtuelles System ist, handelt es sich um einen dedizierten Server. Aber egal ob dediziert oder Virtuell: Sofern man Root Zugriff bekommt ist es auch ein Root-Server.

    Bei einem ddos würde ich erwarten, dass viel Traffic generiert wird oder?

    DDoS Steht für Distributed Denial of Service. im Vergleich zu einem einfachen DoS wird der Angriff von sehr vielen Quellen ausgeführt, was zur Folge haben kann, dass ein einzelner Host gar nicht so viel Traffic erzeugt. Es Macht eben einen Unterschied ob z.b. ein Gesamtvolumen von 500mbit/s von einem Host oder von 5000 Hosts generiert wird.

    die leichteste Methode bei den KVM Systemen ein neues Root Passwort zu setzen ist:

    1.) Rettungssystem Starten
    2.) Folgende Befehle eingeben:

    • mount /dev/vda2 /mnt
    • chroot /mnt
    • passwd

    Dann einfach /dev/vda2 wieder unmounten und das System rebooten.

    Ob /dev/vda2 richtig ist, hängt natürlich von der individuellen Partitionierung ab. Bei den Systemen mit LVM muss z.b. das LVM-Volume gemountet werden.

    Zu sagen das die Latenz, nur weil ein Server in Nürnberg und nicht in Frankfurt steht, 4ms länger ist ist falsch. So etwas kann man nicht pauschalisieren.

    Wenn man einen Ping absetzt und sich dann die Latenz ansieht betrachtet man dir round trip time (rtt). Man schaut also wie viel zeit vergangen ist bis ein Paket versendet wurde und dann ein Antwortpaket angekommen ist. Diese zeit hängt sicherlich auch vom Serverstandort ab.

    Allerdings nur zu einem gewissen teil.

    Vielmehr hängt es davon ab: wie lang sind die Kabelstrecken insgesamt die ein Datenpaket zurücklegt. Ich kann auch bei einer Verbindung von einem Internetzugang in einem 0815 Büro in Frankfurt zu einem Server der im Rechenzentrum 5 Häuser weiter steht Latenzzeiten von 50ms oder höher haben. Es hängt eben davon ab wie es geroutet wird.

    Sicherlich ist es unrealistisch hier auf diese Entfernung 50ms zu bekommen, aber wenn z.b. eine direkte Leitung weggebrochen ist und nur noch eine zur Verfügung steht die einmal durch halb Europa geht, dann bekommt man auch auf 50meter Luftlinie 50ms hin.

    Zusätzlich zu der Strecke die die Datenpakete zurücklegen müssen, erhöht sich die Latenz mit jeder Komponente die dazwischen steht. jeder Router der das Paket verarbeitet brauch dafür eine gewisse zeit. Je mehr Router auf der Verbindung aktiv sind, desto höher wird also die Latenz.

    Wenn ich in z.b. Köln wohne kann ich trotz der geographisch höheren Entfernung nach Nürnberg dorthin eine bessere Verbindung haben als nach Frankfurt. Dies hängt davon ab was für Routen zur Verfügung stehen. In der Regel arbeiten die Router so, dass diese immer die kürzeste offene Verbindung für die Datenpakete nehmen.

    Es ist also unmöglich pauschal zu sagen nach Frankfurt ist die Latenz 4ms kürzer als nach Nürnberg.

    In den meisten fällen wird man zwar nach Frankfurt kürzere Verbindungen haben, da dort der DE-CIX steht (einer der größten Internetknotenpunkte der Welt), aber dennoch ist es genauso gut möglich das viele Leute nach Nürnberg kürzere Verbindungen haben. Das hängt eben auch sehr stark davon ab wie der jeweilige Rechenzentrumsprovider und vor allem der DSL Provider aufgestellt ist.

    Teamspeak kann auch problemlos ohne root Rechte eingerichtet werden. es kann natürlich kein /home/teamspeak erstellt werden, weil nach /home kein normaler Confixx Nutzer schreiben darf. Der Confixx Benutzer darf auf /var/www/webX/html und auf /var/www/webX/files schreibend zugreifen. Ich würde empfehlen Teamspeak in files zu installieren und dort einen entsprechenden Unterordner zu erstellen, da die Inhalte im Ordner files nicht per http abrufbar sind.

    Sie müssen die Anleitungen die Sie durcharbeiten auf die gegebene Ausgangssituation adaptieren. Sie können in den seltensten Fällen Anleitungen Schritt für Schritt ohne Anpassung übernehmen.

    Muss mich mit Superscharfen Antibaktarielen Küchen Messern in Farbe Rum schlagen ^^ und das Messer das ich mal selbst angefertigt hatte war nicht wirklich sonderlich gebrauchbar ^^

    Klingt nach pinken Keramik Messern :D

    Naja selber geschmiedet hab ich die ja auch nicht. hab sie heute gekauft. Hatte erst bei japanesechefsknives geschaut, dann aber durch Zufall raus gefunden das es hier einen Händler für die Messer oben gibt. Da mir Zakuri nix gesagt hat, hab ich dann mal ein bisschen im Netz gesucht und die teile wurden zurecht gut bewertet. Also den Händler angerufen, hin gefahren, die Messer angesehen und gekauft :D

    Kosten zwar deutlich mehr als diese standard Supermarkt Messer, sind aber dafür eben für die Ewigkeit gemacht.

    Natürlich steht bei diesem MTR 0%, wäre ja noch härter..
    Bei TS sind aber zu hohe Latenzzeiten = Packageloss, aufgrund von livestream -> udp -> sprache
    was zu spät ist, wird weggelassen, sonst wärs ja n sprach messenger bzw. nicht aktuell bzw.
    ich höre was jmd. gesagt, der teil der verz. kam einfach mit dem was er jetzt sagt..

    Wenn Sie Netzwerkseitig 0% packetloss haben, aber Im teamspeak ein Packetloss auftritt, dann ist dies ein deutliches Zeichen für ein Problem seitens Teamspeak.

    Warum wird nich hergegangen und die User die noch alte V-Server nutzen können doch zusammen gelegt werden auf einen Node.

    Dies wir früher oder später auch gemacht. Allerdings ist unser Langfristiges Ziel kein einziges System mehr auf Linux vServer zu betreiben da es sich nicht lohnt für eine handvoll vServer noch eine gesonderte Linux vServer Umgebung zu betreiben. Dies ist vor allem aus Wartungsgründen wirtschaftlich nicht realisierbar weil wir dann alle neue Images sowohl für KVM als auch für Linux vServer bereitstellen müssten. Dies ist jedoch nicht so ohne weiteres möglich da Linux vServer kein rsyslogd unterstützt und somit derzeit bereits Ubuntu und bald auch Debian nur bedingt lauffähig ist.

    Die Images von neuen Betriebssystemen dann also für Linux vServer lauffähig zu bekommen (sofern überhaupt irgendwie möglich) erfordert massiv viel Aufwand was einfach wirtschaftlich nicht vertretbar ist.