feed-image -=Kernel-Error=- BlogFeed

TRIM für SSDs im ZFS Pool unter Linux aktivieren.

Speicherzellen eine SSD sind nicht unendlich beschreibbar. Irgendwann sind sie "kaputt". Damit dieses möglichst spät passiert, hat jede SSD eine interne Logik, um Schreibzugriffe möglichst gut auf Speicherbereiche zu verteilen. Im optimalen Fall wird jeder Speicherbereich gleich oft zum Schreiben benutzt. Damit dieses möglichst gut funktioniert, muss die SSD wissen, welche Speicherbereiche wirklich frei sind. Diese Information kann die SSD fast nur vom Filesystem selbst bekommen. Damit die Info weitergeleitet wird, gibt es TRIM https://de.wikipedia.org/wiki/TRIM.

ZFS bietet diese Möglichkeit natürlich auch und dieses ebenfalls unter Linux. Im zpool nennt sich diese Option autotrim und um zu prüfen ob es aktiviert ist, hilft folgender Befehl:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  off        local
rpool  autotrim  off        local

Wie man sehen kann, gibt es die beiden ZFS Pools mit den Namen bpool und rpool. Auf beiden ist autotrim deaktiviert. Zum Aktivieren ist folgender Befehl nötig:

$ zpool set autotrim=on bpool
$ zpool set autotrim=on rpool

Wenn man nun prüft, ob es aktiviert ist:

$ zpool get autotrim bpool rpool
NAME   PROPERTY  VALUE     SOURCE
bpool  autotrim  on        local
rpool  autotrim  on        local

Sollte man dieses bestätigt bekommen.

Einen kleinen Tipp habe ich darüber hinaus zusätzlich noch. Wenn eine SSD an den Strom angeschlossen wird, ohne dass ein "Computer" angeschlossen ist, fallen viele SSD in eine Art Wartungs- / Reparaturmodus. Dann sortieren SSDs selbstständig ihre Speicherzellen um. Wenn also einmal etwas in den ersten Speicherbereich geschrieben wurde, ist dieses nicht gleichbedeutend, dass es für immer in nur diesem Bereich liegen bleibt. Im laufenden Betrieb wird dieses verschoben, wenn die SSD (wie beschrieben) nur am Strom angeschlossen ist forciert man dieses zusätzlich bei vielen SSDs. Einfach 2 / 3 Stunden "laufen" lassen... Hin und wieder lassen sich über diesen Weg "tote" SSDs wiederbeleben. Alles funktioniert natürlich mit TRIM viel besser :D

Frage? Dann fragen..

Mein FreeBSD hat Probleme mit IPv6 bei netcup

Als Kunden der bei netcup FreeBSD "rootserver" auf KVM qemu Basis einsetzt, habe ich schnell gemerkt, dass meine IPv6 Verbindung nicht stabil ist.

Dieses zeigt sich wie folgt:

- Direkt nach dem Boot scheinen IPv6 Verbindungen zu funktionieren, wie gewünscht.

- Nach einiger Zeit brechen die Verbindungen zusammen, sowohl Verbindungen vom System in die Welt als auch Verbindungen von der Welt ins System.

- Verbindungen scheinen "Startprobleme" zu haben. Ein ping läuft erst ein paar Mal ins Leere und dann funktionieren alle Verbindungen plötzlich wieder für einen Moment.

 

Ein möglicher Workaround ist es, vom System aus einen ping auf die IPv6 Adresse des Gateways von netcup zu starten. Dieses sorgt in der Regel kurzzeitig für funktionsfähige IPv6 Verbindungen. Aber was ist das genaue Problem und wie könnte eine brauchbare Lösung aussehen?

Als Leser mit IPv6 Wissen, denkt man natürlich sofort a NDP das Neighbor Discovery Protocol und ja ich denke genau hier liegt das Problem. Dieses unterscheidet sich zur Implementation bei Linux etwas, daher funktioniert IPv6 im netcup Testsystem problemfrei unter FreeBSD, NetBSD usw. aber nicht. Die Probleme im NDP lassen sich auf dem System schnell wie folgt erkennen:

root@netcup-vps:~ # netstat -s -picmp6
icmp6:
    0 calls to icmp6_error
    0 errors not generated in response to an icmp6 message
    0 errors not generated because of rate limitation
    Output histogram:
        neighbor solicitation: 29
        neighbor advertisement: 10
        MLDv2 listener report: 8
    0 messages with bad code fields
    0 messages < minimum length
    0 bad checksums
    0 messages with bad length
    Input histogram:
        router advertisement: 17
        neighbor solicitation: 633
        neighbor advertisement: 25
    Histogram of error messages to be generated:
        0 no route
        0 administratively prohibited
        0 beyond scope
        0 address unreachable
        0 port unreachable
        0 packet too big
        0 time exceed transit
        0 time exceed reassembly
        0 erroneous header field
        0 unrecognized next header
        0 unrecognized option
        0 redirect
        0 unknown
    0 message responses generated
    0 messages with too many ND options
    0 messages with bad ND options
    423 bad neighbor solicitation messages
    0 bad neighbor advertisement messages
    0 bad router solicitation messages
    0 bad router advertisement messages
    0 bad redirect messages
    0 path MTU changes

Ich habe einige Zeit damit verbracht, mich mit dem Support darüber auszutauschen. Wie immer landet man zuerst in der human firewall, im Anschluss erreichte ich oft Supportmitarbeiter in Ausbildung eines IT Berufes. Zwischenzeitlich wurde mir das Problem von netcup dann auch bestätigt und mit dem Hinweis versehen, dass es an ihren Core-Routern liege, welche irgendwann ein Update bekommen sollen. Wann genau dieses Updates gemacht wird, konnte/wollte mir niemand bestätigen. Ebenfalls wurde versucht mein System auf verschiedene Hosts zu verschieben, von welchen andere Kunden wohl positives berichtet hatten. Dann sollte das Problem irgendwann behoben sein und netcup war erstaunt, dass es dieses noch nicht ist. Was auch immer... Aus meiner Sicht liegt das Problem an netcup.

Gelöst werden kann dadurch, dass man seinem BSD mitteilt, es soll bitte ND nach RFC4861 machen. Dieses ähnelt zumindest im Punkt der Bindung des jeweiligen ND ans Interface. Dafür kann man dieses als kurzen Test wie folgt aktivieren:

sysctl net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Stellt sich der gewünschte Erfolg ein, wird es mit dem passenden Eintrag in der /etc/sysctl.conf permanent aktiviert:

net.inet6.icmp6.nd6_onlink_ns_rfc4861=1

Dabei aber bitte beachten, dass FreeBSD dieses vor ca. 10 Jahren aus Sicherheitsgründen deaktiviert hat. https://www.freebsd.org/security/advisories/FreeBSD-SA-08:10.nd6.asc

Ich bin mit meinen Bemühungen aber leider nicht zu einer, für mich funktionierenden, Lösung von Seiten netcups gekommen. Daher blieb mir nur RFC4861.

Ich denke das Problem ist sicher schon lange beim Support bekannt, einfache google Suchen oder im netcup Forum zeigen dieses schnell auf. Dennoch vermittelte der Support mir erst das Gefühl, selbst etwas falsch konfiguriert zu haben, nur um mir dann den Eindruck zu vermitteln, dass sie noch nie von einem solchen Problem gehört haben. Ich vermute daher, dass ihr Setup aktuell einfach keine "einfache" Lösung dieses Problems zulässt und sie daher so agieren. Was aber natürlich reine Spekulation ist, ich kann auch nur "vor" das Setup schauen.

Fragen? Dann fragen...

Linux Mint 20.1 mit ZFS root Pool und native Verschlüsselung

Zu ZFS und warum man es haben will, muss ich hier sicher nicht mehr viel schreiben. Ebenfalls wird sich niemand mehr die Frage stellen, warum man seine Festplatte verschlüsseln möchte.

ABER wenn man nun Linux, ZFS und Verschlüsselung kombinieren möchte, dann gibt es etwas, worüber es sich zu schreiben lohnt. Wie man nun also sehr einfach unter sein Linux Mint >= 20.1 einen native encryptet zfs root pool bekommt, darum geht es hier.

Linux Mint bringt seit Version 20 bereits alles mit um dieses ohne besonderen Aufwand zu erledigen. Natürlich ging es bereits schon früher, nur war es dann fast nur über den Weg möglich, die Festplatte inkl. Grub vollständig von Hand vor und während der Installation selbst fertig zu machen. Dieses ist... Sagen wir mal... "Für den erweiterten Anwender schon fast nicht zu machen".

Zurück zu Linux Mint 20.1!

Wie erwähnt bringt diese Version alles Nötige mit, nur der Installer ist noch nicht ganz so weit und man muss ihm mit zwei Kleinigkeiten unter die Arme greifen. Einmal muss man die nötigen Pakete im Live-System nachinstallieren. Also einfach die gewünschte Version von Linux mit downloaden und davon booten. Ist man im Live-System angekommen, öffnen man ein Terminal und wirft die Installation der Pakete mit folgendem Befehl an:

sudo aptitude -y install libzfs2linux zfs-initramfs zfsutils-linux zfs-zed

Möchte man nun einfach nur sein Linux Mint auf einem ZFS Pool installieren, ist man schon fertig. Einfach den Installer starten und beim Punkt, auf welche Festplatte man sein neues System installieren möchte auf Advanced features... klicken und unten auf EXPERIMENTAL: Erase disk and use ZFS. Fertig ist!

Möchte man noch seinen zroot Pool verschlüsseln fehlt noch die zweite Kleinigkeit. Da der Installer den Wunsch und somit ebenfalls das Kennwort zur Verschlüsselung des ZFS Pools nicht abfragt, muss man es dem Installer mitgeben, bevor er mit seiner Arbeit startet. Dazu bleibt man im Terminal und editiert das Installerscript wie folgt:

sudo vi /usr/share/ubiquity/zsys-setup

Hier sucht man nun die Sektion, in welcher es ums Anlegen der ZFS Pools geht ?zpool create wäre eine gute Suche ;-)

Hat man dieses gefunden (derzeit sollte es genau zwei Mal im Installerscript auftauchen) setzt man einfach vor das zpool create des rpools ein:

echo 'SUPER-SECURE' | 

Die Hochkomma bleiben dabei stehen und ihr ersetzt SUPER-SECURE durch euer gewünschtes Kennwort, was sich natürlich schon jeder gedacht hat. Damit wird dem zpool create rpool später im Installationsprozess euer Kennwort übergeben.

Fehlen nur noch die Optionen beim Erstellen des Pools, damit er ihn auch verschlüsselt. Dafür bitte folgendes vor die Zeile -O mountpoint=/ -R "${target}" rpool "${partrpool}" eintragen:

-O encryption=aes-256-gcm \
-O keylocation=prompt \
-O keyformat=passphrase \

Am Ende sieht der Ausschnitt also beispielhaft wie folgt aus:

echo 'Kennwort!' | zpool create -f \
        -o ashift=12 \
        -O compression=lz4 \
        -O acltype=posixacl \
        -O xattr=sa \
        -O relatime=on \
        -O normalization=formD \
        -O mountpoint=/ \
        -O canmount=off \
        -O dnodesize=auto \
        -O sync=disabled \
        -O encryption=aes-256-gcm \
        -O keylocation=prompt \
        -O keyformat=passphrase \
        -O mountpoint=/ -R "${target}" rpool "${partrpool}"

Das war es auch schon. Jetzt, wie gewohnt den Installer starten und schon wird man nach dem Reboot aufgefordert seinen ZFS Pool mit einem Kennwort zu entschlüsseln. Oh, geht natürlich so mit EFi und lagacy und überhaupt....

Ob alles so funktioniert hat, wie man es sich vorstellt, lässt sich direkt nach dem ersten Boot ins neue System prüfen. Einfach Terminal öffnen und mittels folgender Befehle prüfen, ob die Verschlüsselung aktiviert ist und sich auch sauber durch den Pool bis zu den Benutzerdaten weiter vererbt hat:

test@test-VirtualBox:~$ sudo zpool list
NAME    SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
bpool  1,38G  97,3M  1,28G        -         -     0%     6%  1.00x    ONLINE  -
rpool  26,5G  4,46G  22,0G        -         -     3%    16%  1.00x    ONLINE  -
test@test-VirtualBox:~$ sudo zpool get feature@encryption
NAME   PROPERTY            VALUE               SOURCE
bpool  feature@encryption  disabled            local
rpool  feature@encryption  active              local
test@test-VirtualBox:~$ sudo zfs get encryption rpool/USERDATA/test_9d9i92
NAME                        PROPERTY    VALUE        SOURCE
rpool/USERDATA/test_9d9i92  encryption  aes-256-gcm  -
test@test-VirtualBox:~$

Hier noch Bilder zum Klicken, das mögen ja viele.

  • Linux-Mint-ZFS-root-01
  • Linux-Mint-ZFS-root-02
  • Linux-Mint-ZFS-root-03
  • Linux-Mint-ZFS-root-04
  • Linux-Mint-ZFS-root-06
  • Linux-Mint-ZFS-root

Fragen? Dann fragen...

Managebarer 4 Port MikroTik 10 Gbit SFP+ Switch für knapp über 100€

Ich habe einen neuen Switch. MikroTik CRS305-1G-4S+IN… Das Gerät verbindet bei mit zuhause im Arbeitszimmer meine Workstation, das Storage, meinen eigentlichen Switch und meinen Windows PC.


Das Teil ist der Knaller! Die angepriesene Leistung ist tatsächlich da, das Gerät kommt zwar nur mit einem Netzteil, man könnte aber ein weiteres anschließen. Ebenfalls kann man den Switch per PoE betrieben, somit hätte man im Grunde schon drei Netzteile als Ausfallsicherheit, wenn man es denn braucht. Das Gehäuse ist komplett aus Metall und dient zusätzlich zur passiven Kühlung. Es gibt also keinen Lüfter oder ähnliches, dass Geräusche machen könnte.


Unter dem Gehäuse sind noch Löcher, um es einfach an einer Wand oder ähnlichem befestigen zu können.


Wer MikroTik kennt, der fragt sich natürlich sofort: „Läuft da ein MikroTik OS drauf?“ JA tut es… Voll nutzbar und mit allem was man so gewohnt ist. Man könnte also noch über verschiedenste Dinge wir z.B.: VRRP die verrücktesten Failover Szenarien abbilden. Aber selbst, wenn nicht… 4 SFP+ Ports mit 10 GB/s für knapp über 100€, muss man da noch nachdenken?!?


Ich mache ja eher selten Werbung für ein Produkt aber den Switch wollt ihr haben. Als „Desktopswitch“ für zuhause (wie bei mir) ist der schon zu schade. Ich kann mir den gut als Pärchen vorstellen um klassische 1GB/s Switche zu verbinden oder ähnliche Dinge. Klickt euch den und testet ihn. Das Ding ist super: https://amzn.to/3r3kQiW

  • MikroTik-10Gbit-01
  • MikroTik-10Gbit-02
  • MikroTik-10Gbit-03
  • MikroTik-10Gbit-04
  • MikroTik-10Gbit-05

Bose QuietComfort 35 Akku tauschen

Der Akku in meinem Bose QC35 hat inzwischen seine Zeit hinter sich. Also muss dieser getauscht werden. Der verbaute Akku ist ein AHB110520CPS von Synergy. Leider habe ich diesen nicht als Ersatzakku finden können..... Gut man kann ihn aus China bestellen (35€), dann ist er zwar gebraucht, weil er aus einem alten Kopfhörer ausgebaut wurde aber natürlich "getestet".

Was ich ebenfalls gefunden habe ist die Möglichkeit den Kopfhörer einzuschicken und so den Akku tauschen zu lassen (70€). Beides Lösungen, welche mir nicht gefallen, denn im Grunde ist es nur ein einfacher 3,7V Akku mit knapp 500mAh.

Nach einiger Suche habe ich daher einen brauchbaren Ersatz gefunden. Der folgende Akku GSP072035 hat zwar ein paar mAh weniger, die Kopfhörer sind also etwas früher leer, aber damit kann ich leben. Vor allem bin ich aktuell eh nur sehr kleine Standzeiten der Kopfhörer gewohnt, da der Akku derzeit aufgebraucht ist. Ich habe bei Amazon bestellt: https://amzn.to/2JXwhJc

Der Akku passt zwar nicht ins Akkufach des alten Akkus, aber er ist klein genug, um problemlos im Kopfhörer seinen Platz zu finden. Ganz ohne Einfluss auf Gewicht oder Klangqualität zu nehmen. Man merkt es also nicht!

Als kleiner Tipp... Wenn man schon dabei ist ebenfalls die Ohrmuscheln tauschen. Die folgenden habe ich selbst schon zweimal zur Erneuerung benutzt und ich kann sie nur empfehlen: https://amzn.to/2L4xcbo

Wie man den Akku selbst tausch, da hat IFIXIT natürlich bereits eine erstklassige Anleitung erstellt. Diese ist hier zu finden: https://de.ifixit.com/Anleitung/Bose+QuietComfort+35+Akku+tauschen/134337

 

Ist der alte Akku raus, klebt man den neuen einfach mit einem kleinen Tropfen Heißkleber oben in die Ecke und lötet ihn, wie den alten, fest. Ist alles wieder zusammengebaut sollte der Kopfhörer wieder wie

gewohnt funktionieren. Bis auf die 20/25 Minuten weniger Höhrzeit.

Fragen? Dann fragen :-)