Beiträge von SCD

    Hallo Felix,

    sorry wegen dem falschem Bereich.

    Leider ist es nicht mehr der aktuelle Stand. Kurz nach meiner Mail ist wieder ein Kernelfehler aufgetreten

    Hallo,

    mein neuer RS 2000 G7SE 15 years ist sehr instabil. Ich wurde bereits zweimal auf einen anderen Node verschoben. Das System, Debian Stretch unter 3.14.51-grsec, lief auf dem Root-Server M SSD v6 ohne Probleme. Dies wurde per RSync in der Recovery-Console auf das neue System kopiert und nur die IP-Addresse /etc bzw. die fstab entsprechend angepaßt.

    Da ich vermutet habe, das der Kernel mit dem neuen Server nicht richtig zusammenläuft, habe ich den Kernel auf 4.11.8 aktualisiert. Trotzdem bekomme ich noch ständig Kernel-Meldungen wie

    Code: /etc/sysctl.conf
    vm.dirty_background_ratio=5
    vm.dirty_ratio=10
    kernel.perf_event_paranoid=3
    kernel.sched_min_granularity_ns=10000000
    vm.swappiness=10
    kernel.sched_wakeup_granularity_ns=15000000
    kernel.sysrq=1
    kernel.dmesg_restrict=1
    Code: /etc/default/grub
    GRUB_CMDLINE_LINUX_DEFAULT="quiet elevator=noop nohz=off"

    (durch das weglassen von nohz=off gibt es keine Verbesserung)

    NC#2017070510003676 und NC#2017070310000315

    Was möglich wäre, ist eine persönliche Statusübersicht im CCP. Das bedarf allerdings ein wenig Arbeit bei uns.

    Wie wäre es mit einem RSS-Feed ?

    Durch die Anmeldung per HTTP-Auth könnten dann gleich die persönlichen Meldungen angezeigt werden.

    Und eine automatische Weiterverarbeitung steht auch nichts im Wege ;)

    Mein Plan ist/war eigentlich am 31.07 ein Komplett-Backup zu erstellen und am 01.08. den neuen Server zu bestellen.

    Auf diesen erfolgt dann ein Restore des Komplett-Backups, Anpassung der IP-Adressen und per RSync werden die letzten Änderungen vom gekündigten Server (home / mail / mysql / logs) kopiert. Anschließend wird die DNS geändert (TTL wird hier ein paar Tage vorher auf 60 gesetzt) und eine Weiterleitung der alten IP auf die neue (iptables) angelegt.

    Netcup stellt ja den neuen Server am gleichen Tag bereit. So sollte der Umzug in ein bis zwei Stunden erledigt sein und der tatsächliche Ausfall sich auf vielleicht 15 Minuten beschränken.

    Hallo,

    ich habe einen Server wegen eines Produktwechsels gekündigt. Im CCP steht:

    Für dieses Produkt ist eine Kündigung zum 02.08.2017 vorgemerkt

    Welche Aussage stimmt nun

    1. der Server wird am 01.08.2017 um 23:59:59 deaktiviert
    2. der Server wird am 02.08.2017 um 23:59:59 deaktiviert
    3. der Server wird am 02.08.2017 irgendwann im Laufe des Tages deaktiviert
    4. ...

    Hallo,

    habe das seit gestern das gleiche Problem. Nutze einen Server als Monitoring und der schlägt öfter Alarm:

    22:20 Uhr, 22:55 Uhr, 23:06 Uhr, 0:27Uhr, 1:17 Uhr, 1:51 Uhr, 3:42 Uhr, 5:06 Uhr, 6:12 Uhr

    Ich lasse jetzt auf den Server (noch im Normal-Mode) MTR laufen. Als Gegen-Server einen weiteren bei Netcup. Mal sehen was passiert.

    Zu dem habe ich eine andere Art Frage, wird für den DDoS Schutz eigentlich ein gesonderter Vertrag mit dem Kunden geschlossen oder ist dieser bereits bei allen Verträgen ein Bestandteil?

    Ist immer dabei. Bei mir wurde dieser schon aktiv, obwohl kein gesonderter Vertrag abgeschlossen wurde.

    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.

    Genau aus diesem Grund habe ich meinen Root-Server M SSD v6 12M zum 02.08. gekündigt. (Wechsel auf dem Netcup RS 1000 SAS G7).

    Wenn jetzt aber achte Generation kurz vor der Tür steht, frage ich mich, ob sich der Zwischenschritt G7 noch lohnt.

    Problem ist dabei die Vertragslaufzeit von 12 Monaten.

    Auf der anderen Art habe ich den Server am 03.08 mit eine Laufzeit von drei Monaten bestellt und nach einen Monat auf 12 Monate umgestellt und damit eigentlich eine Laufzeit bis zum 02. November 2017 (siehe auch Ticket NC#2015091610000809). Vermutlich gibt es dann die Generation 8.

    Root-Server M SSD v6 12M

    Code
     hdparm -tT /dev/sda1
    
    /dev/sda1: 
    
    Timing cached reads:   16228 MB in  2.00 seconds = 8121.20 MB/sec 
    Timing buffered disk reads: 152 MB in  3.15 seconds =  48.32 MB/sec

    Also etwa wie Dein Root-Server L SSD v6

    Edit: Formatierung - Konnte den Beitrag nicht ändern

    Root-Server M SSD v6 12M

    Code
     hdparm -tT /dev/sda1
    /dev/sda1: Timing cached reads:   16228 MB in  2.00 seconds = 8121.20 MB/sec Timing buffered disk reads: 152 MB in  3.15 seconds =  48.32 MB/sec

    Also etwa wie Dein Root-Server L SSD v6

    Hallo,

    seit gestern kommt die Meldung

    postfix/smtpd[6196]: warning: TLS library problem: error:1417D18C:SSL routines:tls_process_client_hello:version too low:../ssl/statem/statem_srvr.c:992:

    extrem oft im syslog vor. Rollt da eine Spam-Welle von schlecht konfigurierten Server auf uns zu oder ist es ein Fehler auf meiner Seite ?

    Der SMTP-Text von mxtoolbox sagt jedoch alles in Ordnung. Hier meine Postfix-Conf (3.1.4-4)

    Wenn Debian Stretch komplett per Netinstall ISO installiert wird und die Festplatte über den Installer eingerichtet wird, hat man vom derzeitigen Recovery-System kein Zugriff auf das ext4-Filesystem:

    Zitat

    mount: wrong fs type, bad option, bad superblock on /dev/sda1,
    missing codepage or helper program, or other error
    In some cases useful info is found in syslog - try
    dmesg | tail or so

    Zitat

    rescue:~# dmesg | tail
    [ 65.203775] EXT4-fs (sda1): couldn't mount RDWR because of unsupported optional features (400)


    Wann kann mit einem Update gerechnet werden und wie komme ich solange im Fehlerfall über das Recovery-System trotzdem an meine Daten ?