Beiträge von perryflynn

    Nimmt man einen Server mit physikalischen Cores (RS 2000 SAS G7SEa1), sieht das ganze schon viel viel besser aus:

    Code
    root@root:~# openssl speed -elapsed -evp aes-128-gcm
    OpenSSL 1.0.1t  3 May 2016
    built on: Thu Nov  2 14:01:13 2017
    options:bn(64,64) rc4(16x,int) des(idx,cisc,16,int) aes(partial) blowfish(idx) 
    The 'numbers' are in 1000s of bytes per second processed.
    type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes
    aes-128-gcm     376293.16k   866140.67k  1306579.54k  1420143.96k  1458309.80k

    Habe hier eine SQLite Datenbank mit knapp 100.000 Datensätzen in einer Tabelle, die bisher eine Text-Column als PRIMARY KEY genutzt hat. Eine recht komplexe Abfrage mit diversen JOINs hat knapp 10 Sekunden gedauert.

    Nun habe ich den PRIMARY KEY, auf INT umgestellt. Die gleiche Abfrage dauert nun 0,2 Sekunden.

    Krass.

    Ich weiß nicht wie es bei den netcup Images ist. Bei den Vanilla Installationen der jeweiligen Distributionen ist dies aber mittlerweile normal, dass ein Login via Root nur noch mit einem Key geht. Nicht mehr mit Kennwort.

    Einfach über die VNC Konsole einloggen und die sshd_config entsprechend anpassen oder einen normalen User erstellen.

    Seit dem immer IPMI -> BIOS -> RAID

    Bei Supermicro Boards soll es wohl egal sein. Aber ich hatte auch erst IPMI dann BIOS. Hardware-Raid habe ich nicht. Beim Updates des IPMI über das Web UI bekam ich dann noch einen "ENTITY TOO LARGE" HTTP Error, der laut FAQ von Supermicro durch das löschen des Browser Caches gelöst werden kann. Das hat sogar funktioniert, mich allerdings auch sehr verstört.

    Update des BIOS anschließend mit einem FreeDOS USB Stick. Die längsten 15 Minuten des Jahres.

    Aber hey, nun kann das IPMI endlich iKVM ohne Java. Funktioniert ähnlich wie die VNC Konsole hier im netcup SCP.

    Server Firmware Updates sind echt Ungesund für den Admin. Mein Supermicro-Homeserver ist nach der Installation neuer IPMI/BIOS Versionen mehrfach direkt nach dem POST resettet. Hatte echt schiss, dass irgendwas schief gegangen ist... :|

    Anschließend gleich den intel-microcode aktualisiert, und es scheint auch die neuste Version drauf zu sein, wenn man das mit den Releasenotes von Intel vergleicht:

    Code
    root@eisenbart:~# dmesg | grep microcode
    [    0.844025] microcode: sig=0x506e3, pf=0x2, revision=0xc2
    [    0.844376] microcode: Microcode Update Driver: v2.2.
    Code
    Intel Processor Microcode Package for Linux
    20180108 Release
    -- Updates upon 20171117 release --
    SKL-U/Y D0    (06-4e-03:c0) ba->c2
    SKL-H/S R0    (06-5e-03:36) ba->c2
    Code
    root@eisenbart:~# cat /proc/cpuinfo
    model name      : Intel(R) Xeon(R) CPU E3-1260L v5 @ 2.90GHz
    microcode       : 0xc2
    bugs            : cpu_insecure

    Mal schauen, wann die nächsten Updates kommen...

    Zu nftables kann ich leider nichts sagen. Aber ich habe hier für LXC kurzerhand Proxmox installiert und auch ein internes Netz gebaut, welches via iptables NAT macht.

    vmbr1 ist in dem Fall die Bridge, welche die eigentliche öffentliche IPv4 zugewiesen hat.

    Bei mir steht also als "outgoing Interface" nur das Interface drin, was die öffentliche IP hat. Bei Dir steht anscheinend zusätzlich die lxc Bridge mit drin.

    die Gastsysteme nicht zu rebooten, sondern in den 'Suspend-to-Disk' zu schicken?

    Ich wäre da vorsichtig. Bei dem Update könnte sich die "Hardware", welche von KVM "emuliert" wird, ändern. Da könnte sich so ein pausiertes System dran verschlucken. Korrekt herunterfahren sollte immer die beste Maßnahme sein.

    Wir wissen ja schließlich nicht, was netcup genau macht. Ob einfach nur ein Patch eingespielt wurde, oder ob eine komplett neue Kernelversion ausgerollt wird.