Beiträge von SCD

  • Instabiler RS 2000 G7SE 15 years

    Hallo,


    das Problem ist leider wieder da :(


    Ich vermute einen Zusammenhang mit dem aktuellen Kernel-Upgrade (https://www.debian.org/security/2018/dsa-4120) von Debian Strech, da es nach einspielen und Reboot aufgetreten ist. Eine Migration auf einen anderen Host hat schon stattgefunden (NC#2018022510002521).



  • Das längste Thema

    Zitat von mainziman

    Du registrierst bei Anbieter A im September 2017 und dieser kassiert 1 Jahr im voraus, also ist die Domain bis September 2018 bezahlt

    Du wechselst im März 2018 zu Netcup, Netcup kassiert jetzt ebenfalls 1 Jahr im voraus, ABER: die Domain ist nun bis September 2019(!) bezahlt

    und dennoch kommt die Rechnung f. die nächste Jahresgebühr bereits im September 2018(!) ...


    kann das jemand erklären?


    Vermutlich handelt es sich bei der TLD nicht um eine de-Domain. Bei vielen TLDs wird beim Transfer die Laufzeit um ein Jahr erhöht. Die Vergabestelle bekommt das Geld also für das nächste Jahr nur früher und nicht doppelt.


    Die Domain ist dann bei der Vergabestelle bis Sep 2019 bezahlt.

    Die nächste Rechnug von Netcup kommt dann für Dich im März 2019.

    Netcup muß die Domain aber erst im September 2019 wieder bezahlen.

    März 2019 bis September 2019 ist also für Netcup kostenlos.


    Würde die Domain im Mai 2018 wieder von Netcup wegziehen, wäre diese dann bei der Vergabestelle bis Sep 2020 bezahlt und der neue Anbieter freut sich weil er die Domain ein Jahr umsonst bekommen hat.


    Es gibt auch Domainanbieter, die geben die kostenlose Zeit an ihre Kunden weiter.

  • Cipher Suite TLS_RSA deaktivieren

    -ALL:kEECDH+aRSA+AES:kEDH+aRSA+AES:-SHA1:DES-CBC3-SHA hat genau die CipherSuite gebracht, die Du angegeben hast.

    Trotzdem hat sich ssllabs beschwert das keine forward secrecy möglich ist.


    -ALL:kEECDH+aRSA+AES:kEDH+aRSA+AES:+SHA1:DES-CBC3-SHA ergibt deine Suite und zusätzlich

    Zitat

    TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA (0xc014) ECDH secp256r1 (eq. 3072 bits RSA) FS 256

    TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA (0xc013) ECDH secp256r1 (eq. 3072 bits RSA) FS 128

    TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x39) DH 2048 bits FS 256

    TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x33) DH 2048 bits FS 128


    Damit habe ich wieder forward secrecy mit A+.Also genau das was ich wollte. Die Cipher sind auch nicht als WEAK gekennzeichnet.

    Ich nutze sowohl Debian Jessie als auch Debian Strech. Bei Strech nutze ich jedoch eine angepaßte libssl1.0.2 (mit enable-weak-ssl-ciphers)

  • Cipher Suite TLS_RSA deaktivieren

    Hallo,


    da TLS_RSA nun ja als unsicher deklariert wurde, möchte ich diesen entfernen.


    Ich könnte zwar jeden einzelnen (TLS_RSA_WITH_AES_256_GCM_SHA384, TLS_RSA_WITH_AES_256_GCM_SHA384, etc...) angeben,

    doch es gibt bestimmt einen Sammelbezeichnung.


    Bis jetzt nutze ich ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:!RC4:+HIGH:+MEDIUM:!ECDHE-RSA-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA

    Der neue soll alle NONE-WEAK beinhalten und zusätzlich als Ausnahme für Windows XP den TLS_RSA_WITH_3DES_EDE_CBC_SHA.


    @MOD: Bitte unter Administration VServer verschieben. Irgendwie bin ich beim erstellen immer im falschen Thema

  • Performance Root Server "Adv17 RS 1000 Plus"

    Ich gehe von den Munin-Werten aus.


    Da ist jeder Kern 100%, also bei 4 Kernen 400%. 100% Steal ist dann ein CPU-Kern wurde wir geklaut ;)

    Bei Top wird die gesamte Leistung auf 100% gesetzt und damit ist die Steal-Time wirklich Durchschnitt und muß nicht multipliziert werden.

  • Instabiler RS 2000 G7SE 15 years

    Hallo,


    hier ein Langzeitbericht: Der Server läuft nun knapp 64 Tage stabil.


    Es gibt nur zwei Meldungen im Kernel-Log die mir etwas komisch vorkommen, jedoch keine sichtbaren Auswirkungen haben:


    Code
    [Mi Jul 12 12:50:21 2017] TCP: ens3: Driver has suspect GRO implementation, TCP performance may be compromised.
[Di Sep 12 06:45:01 2017] hrtimer: interrupt took 19561754 ns


    Leider hat sich die Disk-Latency aber erheblich verschlechtert. Sie liegt im Durchschnitt bei 200 ms und stellenweise bei 1s.


    ----


    Der Server v22016103897838572 meines Arbeitgebers, welchen ich ebenfalls betreue und aus der gleichen Reihe stammt hat jedoch ähnliche Probleme wie meiner früher:



    Jede dieser Meldungen hatte eine Load von über 100 zur Folge weshalb der Server nicht verfügbar war.


    Er wurde vor 42 Tagen migiert, was leider einen Ausfall von knapp einer Stunde verursacht hat (auf dem alten Node wurde er schon beendet und erst nach etwa Stunde auf den neue Host gestartet - Meldung war damals "Server Informationen konnten nicht ermittelt werden".


    Wurde eventuell die Host-Anpassungen von meinen Node v22017072950850975 bei Host vom v22016103897838572 nicht durchgeführt ?

  • IPv6 instabil

    Mach mal bitte nach dem Neustart


    Code
    ip -6 route show

    Und wenn die IPv6 weg ist

    Code
    ip -6 route add default via fe80::1 dev ens3

    Geht es dann wieder ohne Neustart ?

  • Das längste Thema

    Folgende Aussagen gibt es bereits:

    Zitat von [netcup] Felix

    Aus dem Grund raten wir selber dazu die Generation 7 bzw. Generation 7 SE zu nutzen, wenn wirklich ein sehr guter IO-Durchsatz gewünscht wird. Generation 6 ist ja nun schon etwas in die Jahre gekommen. In einigen Monaten folgt Generation 8. Die Generation wird nochmal einen großen Leistungsschub bekommen, wenn auch weniger im IO-Bereich.

    Zitat von [netcup] Felix

    Die Generation 8 könnte ja z.B. auf CPUs von AMD laufen ;)

  • Mining auf vServer erlaubt?

    Nicht ganz richtig:

  • Instabiler RS 2000 G7SE 15 years

    Hallo,


    laut munin war der Test um 16:30 beendet. Wenn Sie dies stimmt, kann ich bestätigen, dass die Maßnahmen ein voller Erfolg waren.

    Keine Fehler im Kernel-Log und auch kein jumped von Dovecot. Nun kann ich wohl wieder ruhiger schlafen ;)


    Nun warte ich auf die Antwort vom Ticket 2017070110004422

  • Instabiler RS 2000 G7SE 15 years

    Neuer Zwischenstand:


    Keine Stalls, Stucks und dovecot jumped mehr.


    Jedoch ist ab 13:00 Uhr die Steal-Time auf über 35% (von 400%) gestiegen und hat sich jetzt auf 10% eingependelt.

    Vor 13 Uhr war die unter 1%.


    Die Disk latency hat sich seit 13 Uhr auf 170m auch leider verdoppelt.