Traffic-Statistik Transmission

Mit der veröffentlichung der neusten Ubuntu-Version sind noch ein paar GB dazu gekommen:

Beitrag erstellt am 17.10.2021 um 20:39:55 Uhr von Daniel in Kategorie(n): IT, Linux

Das 10GBit-Zeitalter hat begonnen – Teil 3/3

Ich hatte mir für den dritten Teil ja noch vorgenommen, auch meine Windows 10 Installation (bevor es evtl. zu Windows 11 wird) ebenfalls mit 20Gbit-Anbindung zu versorgen.

Die beiden Ports sind als Ethernet-Adapter bereits eingerichtet und von mir entsprechend benannt:

Also kurz bei Microsoft in der Dokumentation (https://docs.microsoft.com/en-us/powershell/module/netlbfo/new-netlbfoteam?view=windowsserver2019-ps) geforscht… und dann doch ziemlich schnell ernüchtert:

Das Internet sagt, dass das Feature bis 1809 in Windows 10 enthalten war und dann von MS entfernt wurde.

Habs natürlich trotzdem schnell ausprobiert… aber natürlich ohne Erfolg:

Man kann wohl die nötigen Funktionen aus den Server-Images extrahieren, aber dafür fehlt mir im Moment die Zeit 😉

Vielleicht später mal: https://codeinsecurity.wordpress.com/2020/05/27/re-enabling-nic-teaming-lbfo-in-windows-10-desktop-skus-even-after-microsoft-removed-it/

Beitrag erstellt am 06.10.2021 um 22:33:12 Uhr von Daniel in Kategorie(n): IT, Linux

Das 10GBit-Zeitalter hat begonnen – Teil 2.1/3

Heute Abend bin ich dann auch mal dazu gekommen, die neuen Netzwerk-Interfaces in mein Checkmk aufzunehmen:

Linux-Workstation (ryzen)
VMware-Server (vm)
NAS-VM (nas)

Beitrag erstellt am 04.10.2021 um 21:01:05 Uhr von Daniel in Kategorie(n): Checkmk, IT, Linux

Das 10GBit-Zeitalter hat begonnen – Teil 2/3

Da ich ja zu den eher ungeduldigen Menschen gehöre… kann es nie schnell genug gehen.

Und wenn man schon eine 10Gbit-Netzwerkkarte mit 2 Ports hat, dann sollte man diese auch nutzen!

Los geht es mit der Einrichtung auf VMware-Seite. Wie in Teil 1/3 schon beschrieben, habe ich mir überlegt, dass ich die Link Aggregation auf Switch-Ebene realisieren möchte, damit potentiell mehrere VMs profitieren können.

Schnell geprüft, dass auch beide Links verfügbar sind:

Beide 10GBit-Links (vmnic2 und vmnic3) sind mit 10GBit/s-Vollduplex aktiv
Dem bestehenden vSwitch10 wird ein weiterer Uplink hinzugefügt
So sieht die Switch-Topologie nach hinzufügen des zweiten Uplinks aus
Wichtig ist, das Load-Balancing auf „Route based on IP hash“ zu stellen und das Failback auszuschalten!

Weiter geht es auf der Linux-Workstation… zunächst muss man für jeden Port / jedes Interface ein Slave-Interface anlegen:

Ein neues Bond-Interface wird für die beiden Slave-Interfaces erstellt und konfiguriert

Leider schränkt die Hardware-Ausstattung meines VMware-Systems die Performance etwas ein :/

Das SATA-SSD-Raid 5 liefert round about 550MB/s, die NVME-SSD ist da schon ein wenig schneller…

Der Datastore für diese Disk liegt auf einer NVME-SSD, auch hier sind nicht gerade super Werte zu erzielen.

pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso
9,25GiB 0:00:05 [1,62GiB/s] [================================================================>] 100% 

Für mehr Tempo, bleibt mir nur, temporär ein tmpfs einzurichten:

tmpfs /ramfs tmpfs defaults,size=20G,nosuid,noexec 0 0

Entsprechend erreicht man so ca. 2,7 GByte / Sekunde:

dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso
9,25GiB 0:00:03 [2,69GiB/s] [================================================================>] 100%            
dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso
9,25GiB 0:00:03 [2,71GiB/s] [================================================================>] 100%            
dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso
9,25GiB 0:00:03 [2,75GiB/s] [================================================================>] 100%            
dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso
9,25GiB 0:00:03 [2,68GiB/s] [================================================================>] 100%            
dneubert@ryzen:/ramfs$ pv /mnt/nas_nvme/Oracle\ Enterprise\ Linux\ 8.4.iso > test1.iso
9,25GiB 0:00:03 [2,69GiB/s] [================================================================>] 100%            
dneubert@ryzen:/ramfs$ 

Weiter geht es dann irgendwann mal in Teil 3/3… da werde ich mir dann mal anschauen, ob/wie ich das unter Windows hin bekomme.

Beitrag erstellt am 27.09.2021 um 21:05:58 Uhr von Daniel in Kategorie(n): IT, Linux

Das 10GBit-Zeitalter hat begonnen – Teil 1/3

Nach langem hin und her, Kupfer oder Fiber… ist es endlich soweit: Die Entscheidung für Kupfer ist gefallen. Also schnell mal zwei Netzwerkkarten gekauft:

Ein Blick in den VMware Compatibility Guide bestätigt, dass die gewünschte Karte bzw. deren Chips unterstützt werden.

Qlogic/Broadcom NetXtreme II 57810 Dual 2xRJ45

Ein paar Überlegungen vorab:

  • Da ich aktuell noch keinen 10GBit-Switch habe, wird es eine direkte Kupfer-Verbindung zwischen zwei Hosts geben
  • Host 1: Meine Linux-Workstation
  • Host 2: Mein VMware-Server
  • In Teil 1/3 richte ich die 10GBit-Verbindung ein, in Teil 2/3 dann Link-Aggregation
  • In Teil 3/3 versuche ich mich dann an Windows 10

Dann legen wir mal los…

Einrichtung und Einbau in meine Linux-Workstation sind denkbar einfach – Karte einbauen, der Broadcom-Chipsatz wird direkt unterstützt:

dneubert@ryzen:~$ lspci |grep Broad
05:00.0 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)
05:00.1 Ethernet controller: Broadcom Inc. and subsidiaries NetXtreme II BCM57810 10 Gigabit Ethernet (rev 10)
dneubert@ryzen:~$ 
dneubert@ryzen:~$ find /sys | grep drivers.*05:00* --color=never
/sys/bus/pci/drivers/bnx2x/0000:05:00.1
/sys/bus/pci/drivers/bnx2x/0000:05:00.0
dneubert@ryzen:~$ 

… also nur schnell die IPv4-Konfiguration erstellen und die MTU auf 9000 setzen – fertig:

root@ryzen:~# ifconfig enp5s0f0
enp5s0f0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 9000
        inet 10.10.0.3  netmask 255.255.255.0  broadcast 10.10.0.255
        ether 00:0e:1e:86:48:e0  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B) 
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
        device interrupt 39  memory 0xe4000000-e47fffff 

Damit die Kommunikation mit meinem virtualisierten NAS über die neue Verbindung läuft, hinterlege ich die zukünftige IP des NAS in der /etc/hosts. Das ist aktuell die einfachste Variante. Später lasse ich meiner Workstation diese IP via DHCP mitteilen – dafür wäre aber noch einiges an zusätzlicher Konfiguration erforderlich.

dneubert@ryzen:~$ grep nas /etc/hosts
10.10.0.2	nas
dneubert@ryzen:~$

Auf der VMware-Seite ist die Konfiguration ebenfalls denkbar einfach. Die Netzwerkkarte wird erkannt, der Link ist mit 10GBit / Vollduplex aktiv:

Es ist ein neuer vSwitch erforderlich – auch hier eine MTU von 9000 einrichten und das neue Interface als Uplink auswählen:

Um die Anbindung nutzen zu können wird noch eine entsprechende Portgruppe für die VMs angelegt:

Um auf das neue 10GBit-Netz zugreifen zu können, richte ich eine weitere Netzwerkkarte für die VM „nas“ ein. Die sieht im OS dann natürlich unspektakulär aus:

[root@nas ~]# lspci | grep Ether
03:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
04:00.0 Ethernet controller: VMware VMXNET3 Ethernet Controller (rev 01)
[root@nas ~]# 

Auch hier schnell eine entsprechende Konfiguration erstellt…

[root@nas ~]# cat /etc/sysconfig/network-scripts/ifcfg-LAN-10GBit 
DEVICE=eth1
TYPE=Ethernet
BOOTPROTO=static
DEFROUTE=no
IPV4_FAILURE_FATAL=no
IPV6INIT=no
NAME=LAN-10GBit
ONBOOT=yes
MTU=9000
IPADDR=10.10.0.2
PREFIX=24
[root@nas ~]# 

… und schon steht die Verbindung:

[root@nas ~]# ifconfig eth1
eth1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 9000
        inet 10.10.0.2  netmask 255.255.255.0  broadcast 10.10.0.255
        ether 00:50:56:bc:c4:e0  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 6  bytes 252 (252.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[root@nas ~]# 

Pingtest erfolgreich:

dneubert@ryzen:~$ ping nas -s 8972 -M do -c 1
PING nas (10.10.0.2) 8972(9000) bytes of data.
8980 bytes from nas (10.10.0.2): icmp_seq=1 ttl=64 time=0.249 ms

--- nas ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 0.249/0.249/0.249/0.000 ms
dneubert@ryzen:~$ 

Nachdem ich meine NFS-Exports in der /etc/exports um die neue IP-Adresse meiner Linux-Worksation ergänzt habe kann es an den ersten Speed-Test gehen:

dneubert@ryzen:/tmp$ pv /mnt/nas/ISO-Images/Oracle/Oracle\ Enterprise\ Linux\ 8.4.iso > oel_84.iso
9,25GiB 0:00:17 [ 529MiB/s] [================================================================================================================>] 100%            
dneubert@ryzen:/tmp$ 

Das sieht doch schon mal recht brauchbar aus – Quelle für die Daten ist hier das SATA-RAID 5.

Mehr Geschwindigkeit bekommen wir dann vielleicht in Teil 2/2 mit Daten von einer der NVME-SSDs 😉

Beitrag erstellt am 26.09.2021 um 17:33:36 Uhr von Daniel in Kategorie(n): IT, Linux

NVIDIA-Grafikkarten unter Linux mit Checkmk überwachen

Das Überwachen von NVIDIA-Grafikkarten unter Linux gelingt mit Checkmk durch einen einfachen Local-Check. Einzig das nvidia-smi-Binary muss vorhanden sein.

Der Check übermittelt die Metriken für Temperatur, Speichernutzung und Stromverbrauch.

Visualisierung der Metriken in Checkmk
#!/bin/bash

# Version 1.0, 2021-07-24, (c) Daniel Neubert, https://neubert.at

TEMP_WARN=50
TEMP_CRIT=60

NVIDIA_SMI=`/usr/bin/which nvidia-smi`

if [ -z "{NVIDIA_SMI}" ] || [ ! -x "${NVIDIA_SMI}" ]; then
  exit
fi

trim() {
  local s2 s="$*"
  until s2="${s#[[:space:]]}"; [ "$s2" = "$s" ]; do s="$s2"; done
  until s2="${s%[[:space:]]}"; [ "$s2" = "$s" ]; do s="$s2"; done
  echo "$s"
}

for GPU_INDEX in `${NVIDIA_SMI} --query-gpu=index --format=csv,noheader`; do
    while IFS="," read -r index gpu_name driver_version temperature_gpu memory_total memory_used utilization_gpu power_draw
    do
        if (( $(trim $temperature_gpu) >= ${TEMP_CRIT} )); then
            SEVERITY=2
        elif (( $(trim $temperature_gpu) >= ${TEMP_WARN} )); then
            SEVERITY=1
        else
            SEVERITY=0
        fi

        echo "${SEVERITY} NVIDIA_GPU_$(trim $index) gpu_temp=$(trim $temperature_gpu);${TEMP_WARN};${TEMP_CRIT}|power_draw=$(trim $power_draw)|gpu_memory=$(trim $memory_used);;0;$(trim $memory_total) $(trim $gpu_name), Version $(trim $driver_version) - Temp GPU $(trim $temperature_gpu)"°C" - $(trim $memory_used)MB/$(trim $memory_total)MB used - Power $(trim $power_draw)W"
    done  < <( nvidia-smi --query-gpu=index,gpu_name,driver_version,temperature.gpu,memory.total,memory.used,utilization.gpu,power.draw --format=csv,noheader,nounits )

Das Script findet sich auch in meinem Github-Repository für Checkmk: https://github.com/glutorange/checkmk

Beitrag erstellt am 25.07.2021 um 00:54:06 Uhr von Daniel in Kategorie(n): Checkmk, Linux

Projekt NAS-SSD-RAID-Upgrade

So langsam wurde es Zeit, die alten Magnet-Platten aus NAS zu werfen. Einige der verwendeten 2TB-WD-Disks sind Baujahr 2009 und haben entsprechend hohe Laufzeiten hinter sich. Auch wenn das NAS bei mir längst nicht mehr 24/7 läuft, sind da über die ganzen Jahre schon so einige Stunden zusammen gekommen.

Das bisher verwendete RAID 5, bestehend aus 7 x 2 TB Disks wird abgelöst durch ein minimal kleineres RAID 5, bestehend aus 6 x 2 TB SATA-SSDs.

Bei Geizhals hat sich für die von mir gewählte Crucial BX 500 mit 2TB ein Anbieter mit einem Preis von 144€ je Disk (und damit wieder auf dem Nivau der letzten Angebote) gefunden so dass ich hier einfach zugreifen musste:

Damit wird das NAS nebenbei um 7 x 820g, also ca. 5,7kg (!) erleichtert. Die SSDs wiegen jeweils 38g, in Summe also gerade mal etwa 230g.

Um die SSDs im Gehäuse ordentlich befestigen zu können, habe ich den 3D-Drucker bemüht und ein kleines SSD-Case modelliert:

Hier lassen sich bis zu 8 2,5″ SSDs einschieben und dann auf einen 3,5″ Quick-Release-Rahmen setzen so dass im Gehäuse maximale Ordnung herrscht. Da die SSDs nie für längere Zeit beansprucht werden ist die Belüftung/Kühlung sekundär, im Gehäusebereich für die Laufwerke herrscht allgemein ein brauchbarer Luftstrom.

Aufgesetzt auf den QUick-Release-Rahmen…
… und auf der Unterseite mit Klebe-Füßchen gesichert

Das Software-RAID 5 mit 6 SSDs:

[root@nas ~]# mdadm --detail /dev/md0
/dev/md0:
           Version : 1.2
     Creation Time : Sat Apr 10 15:29:45 2021
        Raid Level : raid5
        Array Size : 9766912000 (9.10 TiB 10.00 TB)
     Used Dev Size : 1953382400 (1862.89 GiB 2000.26 GB)
      Raid Devices : 6
     Total Devices : 6
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Mon Apr 12 00:38:34 2021
             State : clean 
    Active Devices : 6
   Working Devices : 6
    Failed Devices : 0
     Spare Devices : 0

            Layout : left-symmetric
        Chunk Size : 512K

Consistency Policy : bitmap

              Name : nas:0  (local to host nas)
              UUID : 21422187:a0472572:9362bf60:cd407cf9
            Events : 7168

    Number   Major   Minor   RaidDevice State
       0       8       32        0      active sync   /dev/sdc
       1       8       80        1      active sync   /dev/sdf
       2       8       96        2      active sync   /dev/sdg
       3       8       16        3      active sync   /dev/sdb
       4       8       48        4      active sync   /dev/sdd
       6       8       64        5      active sync   /dev/sde
[root@nas ~]# 

Und sauber im Monitoring:

Beitrag erstellt am 11.04.2021 um 11:52:58 Uhr von Daniel in Kategorie(n): IT, Linux

SysMonTask – Task-Manager für Linux

Es ist mal wieder Zeit für ein neues Linux-Tool: SysMonTask:

Das stark an den Windows-Task-Manager angelehnte Tool bietet auf einen Blick alles, was man braucht und ist damit auch deutlich übersichtlicher als der Standard System Monitor oder auch CLI-Tools wie htop und Konsorten.

Download und Installations-Anleitung gibt es auf der Projektseite bei Github, einen interessanten Artikel dazu bei Its‘ FOSS.

Beitrag erstellt am 04.03.2021 um 12:00:33 Uhr von Daniel in Kategorie(n): Linux

game.neubert.at

Schaut doch mal auf der neuen Status-Seite game.neubert.at vorbei:

Aktuell laufen hier neben dem obilagtorischen Mumble-Server jeweils Server für Valheim und Starbound.

Beitrag erstellt am 14.02.2021 um 09:14:15 Uhr von Daniel in Kategorie(n): Funstuff, Game-Server, Linux, Odroid

Firmware-Update unter Linux

Auch wenn es schon lange verfügbar ist, habe ich heute zum ersten mal den fwupdmgr unter Linux benutzt um eine Geräte-Firmware zu aktualisieren. Wenn es doch immer so einfach wäre…

dneubert@ryzen:~$ sudo fwupdmgr get-upgrades
• Samsung SSD 970 EVO 1TB has no available firmware updates
• Samsung SSD 970 EVO 1TB has no available firmware updates
X570 AORUS PRO
│
└─Unifying Receiver:
  │   Device ID:           5bb8be566f7b007e87240de3ad212f80349dda9c
  │   Summary:             A miniaturised USB wireless receiver
  │   Current version:     RQR12.01_B0019
  │   Bootloader Version:  BOT01.02_B0014
  │   Vendor:              USB:0x046D
  │   Install Duration:    30 seconds
  │   GUIDs:               9d131a0c-a606-580f-8eda-80587250b8d6
  │                        fcf55bf5-767b-51ce-9c17-f6f538c4ee9f ← HIDRAW\VEN_046D&DEV_C52B&REV_00
  │                        279ed287-3607-549e-bacc-f873bb9838c4 ← HIDRAW\VEN_046D&DEV_C52B
  │   Device Flags:        • Updatable
  │                        • Supported on remote server
  │ 
  ├─Unifying Receiver (RQR12) Device Update:
  │     New version:       RQR12.10_B0032
  │     Remote ID:         lvfs
  │     Summary:           Firmware for the Logitech Unifying Receiver (RQR12.xx)
  │     License:           Proprietary
  │     Size:              56,8 kB
  │     Vendor:            Logitech
  │     Duration:          30 seconds
  │     Flags:             is-upgrade
  │     Description:       This release addresses an encrypted keystroke injection vulnerability sent by pointing devices. The vulnerability is complex to replicate and would require a hacker to be physically close to a target.
  │     
  │     A few of Logitech's devices used to send select buttons in an unencrypted way, and in an effort to protect against this vulnerability, Logitech removed the feature. Affected hardware is:
  │     
  │      • Wireless Mouse M335
  │      • Zone Touch Mouse T400
  │      • Wireless Mouse M545
  │      • Wireless Mouse M560
  │      • Touch Mouse M600
  │      • Touch Mouse T620
  │      • Wireless Rechargeable Touchpad T650
  │     
  │     Although Logitech does not recommend it, these features may be re-activated by keeping/downgrading the receiver to an older firmware.
  │   
  ├─Unifying Receiver (RQR12) Device Update:
  │     New version:       RQR12.08_B0030
  │     Remote ID:         lvfs
  │     Summary:           Firmware for the Logitech Unifying Receiver (RQR12.xx)
  │     License:           Proprietary
  │     Size:              72,7 kB
  │     Vendor:            Logitech
  │     Duration:          30 seconds
  │     Flags:             is-upgrade
  │     Description:       This release addresses an encrypted keystroke injection issue known as Bastille security issue #13. The vulnerability is complex to replicate and would require a hacker to be physically close to a target.
  │     
  │     A few of Logitech's devices used to send select buttons in an unencrypted way, and in an effort to protect against this vulnerability, Logitech removed the feature. Affected hardware is:
  │     
  │      • Wireless Mouse M335
  │      • Zone Touch Mouse T400
  │      • Wireless Mouse M545
  │      • Wireless Mouse M560
  │      • Touch Mouse M600
  │      • Touch Mouse T620
  │      • Wireless Rechargeable Touchpad T650
  │     
  │     Although Logitech does not recommend it, these features may be re-activated by keeping/downgrading the receiver to an older firmware.
  │   
  └─Unifying Receiver (RQR12) Device Update:
        New version:       RQR12.07_B0029
        Remote ID:         lvfs
        Summary:           Firmware for the Logitech Unifying Receiver (RQR12.xx)
        License:           Proprietary
        Size:              69,6 kB
        Vendor:            Logitech
        Duration:          30 seconds
        Flags:             is-upgrade
        Description:       This release addresses an unencrypted keystroke injection issue known as Bastille security issue #11. The vulnerability is complex to replicate and would require a hacker to be physically close to a target.

Hier wird uns verraten, dass es ein Firmware-Update für den Logitech Unifying Receiver gibt, also fix das Update angestoßen:

dneubert@ryzen:~$ sudo fwupdmgr update 5bb8be566f7b007e87240de3ad212f80349dda9c
Unifying Receiver and all connected devices may not be usable while updating. Continue with update? [Y|n]: 
Downloading RQR12.10_B0032 for Unifying Receiver...
Fetching firmware https://fwupd.org/downloads/8d83954fcf79453738dbeba9615a095bae9caed9-Logitech-Unifying-RQR12.10_B0032.cab
Downloading…             [***************************************] Less than one minute remaining…
Decompressing…           [***************************************]
Authenticating…          [***************************************]
Updating Unifying Receiver…
Idle…                    [***************************************]
Updating Unifying Receiver…**************************************]
Writing…                 [***************************************]
Successfully installed firmware
dneubert@ryzen:~$ 

Nach knapp 15 Sekunden ist alles erledigt. Während des Updates ist die Maus – wie im Hinweistext beschrieben – nicht nutzbar 😉

Weitere Informationen liefern folgende Links:

Beitrag erstellt am 04.02.2021 um 01:07:49 Uhr von Daniel in Kategorie(n): IT, Linux

[Impressum]