Mein Datenhaufen zu IT und Elektronik Themen.
Es ist wieder der System Administrator Appreciation Day 2022. Schaut doch einmal bei euren IT Menschen vorbei und freut euch mit ihnen 🙂
In diesem Jahr möchte ich zu einer netten kleinen Präsentation von eaton verlinken.
https://www.eaton.com/explore/c/eaton-what-does-an-i?x=bevc72
Viel Spaß!
Über die Techniken DoT (DNS over TLS) habe ich bereits im Zusammenhang mit Bind 9.16 geschrieben. Ebenfalls DoH (DNS over HTTPS) gibt es einen kleinen Beitrag.
Zu diesem Zeitpunkt bracht BIND 9 die Unterstützung für DoH und DoT noch nicht selbst mit. Daher waren zu diesem Zeitpunkt noch Umwege über stunnel oder nginx zusammen mit doh-proxy nötig.
Zum Glück kommt die letzte stable Version 9.18.0 (26. Januar 2022) mit dem nötigen Support.
named now supports securing DNS traffic using Transport Layer Security (TLS). TLS is used by both DNS over TLS (DoT) and DNS over HTTPS (DoH).Warum möchte man noch gleich DoH oder DoT benutzen? Ganz einfach… Über diese Techniken werden DNS Abfragen verschlüsselt übertragen. Dieses ist ein weiterer Schutz davor manipulierte Antworten zu bekommen und selbstverständlich, damit die eigenen DNS Abfragen erst überhaupt nicht mitgelesen werden. Denn wenn von einem Gerät im Netzwerk die DNS Abfrage zu z.B.: www.tagesschau.de kommt, könnte man davon bereits Dinge ableiten.
Wie die meisten Bind Konfigurationen ist dieses ebenfalls straightforward. Ab Version 9.18 bringt Bind alles Nötige mit. Da wir nun TLS mit dem Bind sprechen möchten, benötigen wir natürlich ein gültiges Zertifikat, wie z.B. beim nginx für seine Webseite.
Ebenfalls sollte man ein paar frische Diffie-Hellmann Parameter generieren:
openssl dhparam -out dhparam.pem 4096
Die eigentliche bind Konfiguration kann in der named.conf.options geschehen:
options {
[...]
listen-on port 853 tls local-tls { 37.120.183.220; };
listen-on-v6 port 853 tls local-tls { 2a03:4000:38:20e::853; };
listen-on port 443 tls local-tls http default { 37.120.183.220; };
listen-on-v6 port 443 tls local-tls http default { 2a03:4000:38:20e::853; };
[...]
allow-recursion-on { 127.0.0.0/8; ::1/128; 2a03:4000:38:20e::853; 37.120.183.220; };
[...]
};
Da der bind auf weiteren Ports lauschen soll erweitert man diese für IPv4 und IPv6. Der Default Port für DoH ist dabei 443 und der default Port für DoT ist 853, beides TCP.
listen-on sowie listen-on-v6 sind wohl selbsterklärend.
port ist der TCP Port und erklärt sich ebenfalls.
tls sagt dem Bind das wir tls sprechen möchten.
local-tls verweißt auf den gleichnamigen tls Block über welchen man seine TLS Konfiguration vornimmt.
http ist für DoH.
default gibt den eigentlichen endpoint für die DoH Abfragen an, im default ist es /dns-query
Da der Server unsere DNS Abfragen erledigen soll, müssen wir ihm dieses noch per allow-recursion-on auf den jeweiligen Adressen erlauben.
Als nächstes wird die eigentliche TLS Terminierung konfiguriert (das lässt sich ebenfalls auslagern, wenn gewünscht). Dafür wird der folgende Block, außerhalb der Options Blocks, ergänzt:
tls local-tls {
cert-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/chain.crt";
key-file "/usr/local/etc/ssl/wild.kernel-error.de/2022/ecp/http.key";
dhparam-file "/usr/local/etc/ssl/dhparam.pem";
protocols { TLSv1.2; TLSv1.3; };
ciphers "TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256:TLS_AES_128_GCM_SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256";
prefer-server-ciphers yes;
session-tickets no;
};
local-tls ist dabei der name des Blocks. Auf diesen verweisen wir oben.
cert-file ist der Pfad zum Zertifikat. Ich habe dort nicht nur das Zertifikat, sondern die gesamte Chain, also mit Intermediate und Root.
key-file ist der Pfad zum Key des Zertifikates.
dhparam-file ist der Pfad zu den Diffie-Hellman Parametern.
protocols definiert die zu verwendenden TLS Protokolle. In diesem Beispiel TLS1.2 sowie TLS1.3.
ciphers definiert die zu verwendenden cipher. Es soll ja „sicher“ bleiben.
prefer-server-ciphers übermittelt dem Client die Information, in welcher Reihenfolge protokoll/cipher Kombinationen probiert werden sollen um einen Match zu finden. Erst das vermeintlich sicherste und dann immer „schlechter“.
session-tickets regelt ob eine Wiederaufnahme von TLS Sessions erlaubt ist oder nicht. Da ich forward secrecy nutzen möchte, ist es deaktiviert.
Damit ist die Konfiguration schon abgeschlossen (Firewall ggf. nicht vergessen!). Also testen….
Ein einfaches Tool dafür ist dog, oder natürlich dig aus den bind-tools aber Version 9.18. Für bind gibt es dann die Optionen +https oder auch +tls
dig +https @dns.kernel-error.de www.kernel-error.de A dig +tls @dns.kernel-error.de www.kernel-error.de A
Der gleiche Test mit dog, sieht wie folgt aus:
dog www.kernel-error.de --tls "@dns.kernel-error.de" A www.kernel-error.de. 6h00m00s 148.251.40.23 dog www.kernel-error.de --https "@https://dns.kernel-error.de/dns-query" A www.kernel-error.de. 6h00m00s 148.251.40.23
Das war es auch schon! Viele Spaß mit einem „besseren“ DNS und wenn es noch Fragen gibt, einfach fragen 🙂
Auf irgendeinem CCC Event bin ich über eine lustige Projektidee einer jammernde Pflanze gestoßen. Diese hat mir und auch meiner größeren Tochter so gut gefallen, dass wir es zusammen nachbauen wollten.
Ziel ist ein kleines „Gerät“, welches den Feuchtigkeitsgehalt der Blumenerde einer Pflanze misst. Ist der Wert zu „trocken“, soll mittels eines kleinen MP3 Players eine Audiodatei abgespielt werden. So bekommt man als Pflanzeneigentümer mit, wenn die Pflanze gegossen werden muss. Damit die Pflanze sich nur beschwert, wenn auch jemand da ist (sonst hört es ja keiner) gibt es noch einen kleinen Bewegungsmelder. Ist also die Blumenerde zu trocken und es wird eine Bewegung erkannt, jammert die Pflanze und schon weiß man, dass die Pflanze Wasser braucht.
Da es das erste Projekt dieser Art für meine Tochter ist, sollte es so übersichtlich und einfach wie möglich sein. Daher wird es auch nicht bis ins letzte Detail ausgeklügelt sein.
Beim Arduino haben wir uns für den Nano entschieden, denn er hat fast die gleichen Möglichkeiten, wie der große UNO, ist aber halt deutlich kleiner. Der MP3 Player ist ein kleines DFPlayer Modul, als Bewegungsmelder arbeitet der HC-SR312 und der normale Feuchtigkeitssensor.
Gestartet haben wir mit einem einfachen Breadboard um die Verschaltung, Modul für Modul, zu setzen und die Ansteuerung mit dem Arduino anhand der Beispiele zu testen. So ist es einfacher nachzuvollziehen und man konnte jedes Modul einfach testen.
Beim DFPlayer haben wir per TTS Texte in verschiedene MP3s umgewandelt und auf der SD Karte im Ordner mp3 gespeichert. Diese MP3s werden random abgespielt, wenn die Erde zu trocken ist und eine Bewegung erkannt wurde.
Nachdem die elektronische Verschaltung klar war und zusammen mit dem Code funktionierte.
Haben wir mit KiCad eine kleine Platine designt um diese „drucken“ zu lassen, damit am Ende alle Bauteile auf dieser verlötet werden können. So hat man weniger Kabelsalat und alles ist platzsparend aufgehoben.
Im Anschluss haben wir noch mittels FreeCAD ein Gehäuse für die Elektronik designt und es mit dem 3D Drucker gedruckt. Die einzelnen Teile haben wir, um es einfach zu halten, jeweils mit einem Tropfen Sekundenkleber fixiert.
Inzwischen steckt das Teil in der Blume und meldet sich erfolgreich wenn es Zeit ist, die Blume zu wässern. Da es abhängig von den MP3s auf dem Player ist, was die Pflanze „sagt“… Sind damit lustige Reaktionen fast schon garantiert. Die Pflanze kann dich im Vorbeigehen voll jammern, um Wasser betteln oder beginnen zu schimpfen.
Natürlich wird meine Tochter nach dem Projekt nicht in der Lage sein, dieses vollständig ohne Hilfe zu wiederholen aber die einzelnen Schritte sind klar. Wie so ein Gerät entsteht, was für Punkte im groben nötig sind… All diese Dinge sind nun deutlich transparenter. Schnell findet man Dinge, welche man verbessern könnte. Feuchtigkeitssensor und die restliche Elektronik trennen oder mit einem NodeMCU ESP8266 mit WIFI Statusdaten auf einem Webserver oder so etwas senden. Oder einfach alles mittels Li-Ion Polymer Akkus und einem kleinen BMS unabhängig vom Stromnetz werden. Usw usw usw….
Wenn jemand dieses kleine Projekt selbst nachbauen möchte, kommen ab hier die nötigen Dinge.
Arduino Quellcode für die Jammernde Pflanze:
#include "Arduino.h"
#include "SoftwareSerial.h"
#include "DFRobotDFPlayerMini.h"
int serialRX = 10;
int serialTX = 11;
int bewegungsstatus = 0;
int messwert = 0;
int schwellwert = 380;
int bewegung = 7;
SoftwareSerial mySoftwareSerial(serialRX, serialTX);
DFRobotDFPlayerMini myDFPlayer;
void printDetail(uint8_t type, int value);
void setup()
{
pinMode(serialRX, INPUT);
pinMode(serialTX, OUTPUT);
pinMode(bewegung, INPUT);
mySoftwareSerial.begin(9600);
Serial.begin(115200);
Serial.println(F("Initializing DFPlayer ..."));
if (!myDFPlayer.begin(mySoftwareSerial)) {
Serial.println(F("Unable to begin:"));
Serial.println(F("1.Please recheck the connection!"));
Serial.println(F("2.Please insert the SD card!"));
while(true);
}
else
{
Serial.println(F("DFPlayer Mini online."));
}
myDFPlayer.volume(20);
myDFPlayer.outputDevice(DFPLAYER_DEVICE_SD);
myDFPlayer.EQ(DFPLAYER_EQ_NORMAL);
myDFPlayer.setTimeOut(500);
}
void loop() {
messwert = analogRead(A0);
bewegungsstatus = digitalRead(bewegung);
if (messwert > schwellwert && bewegungsstatus == HIGH) {
Serial.println("Bewegung + Wert schlecht, spiele Sound ab und warte 15 Sekunden.");
myDFPlayer.next();
delay(15000);
}
else {
if (messwert > schwellwert)
Serial.println((String)"Keine Bewegung aber Messwert schlecht "+messwert);
if (messwert < schwellwert)
Serial.println((String)"Keine Bewegung und Messwert gut "+messwert);
if (bewegungsstatus == HIGH)
Serial.println((String)"Bewegung aber Messwert gut "+messwert);
delay(500);
}
delay(500);
if (myDFPlayer.available()) {
printDetail(myDFPlayer.readType(), myDFPlayer.read());
}
}
void printDetail(uint8_t type, int value) {
switch (type) {
case TimeOut:
Serial.println(F("Time Out!"));
break;
case WrongStack:
Serial.println(F("Stack Wrong!"));
break;
case DFPlayerCardInserted:
Serial.println(F("Card Inserted!"));
break;
case DFPlayerCardRemoved:
Serial.println(F("Card Removed!"));
break;
case DFPlayerCardOnline:
Serial.println(F("Card Online!"));
break;
case DFPlayerPlayFinished:
Serial.print(F("Number:"));
Serial.print(value);
Serial.println(F(" Play Finished!"));
break;
case DFPlayerError:
Serial.print(F("DFPlayerError:"));
switch (value) {
case Busy:
Serial.println(F("Card not found"));
break;
case Sleeping:
Serial.println(F("Sleeping"));
break;
case SerialWrongStack:
Serial.println(F("Get Wrong Stack"));
break;
case CheckSumNotMatch:
Serial.println(F("Check Sum Not Match"));
break;
case FileIndexOut:
Serial.println(F("File Index Out of Bound"));
break;
case FileMismatch:
Serial.println(F("Cannot Find File"));
break;
case Advertise:
Serial.println(F("In Advertise"));
break;
default:
break;
}
break;
default:
break;
}
}
Für den DFPlayer benötigt man noch die nötige library, diese gibt es zum Beispiel bei GitHub und wird einfach lokal unter /home/USERNAME/Arduino/libraries abgelegt.
Die STL Dateien für den 3D Drucker gibt es hier:
STL File Gehäuse / STL File Deckel
Eine Amazon Einkaufsliste haben wir hier:
Optional oder zum Test:
Dann fehlen nur noch die >>Gerber Dateien<< zum bestellen der Platine.
Datenschutz ist oft ein sehr langweilige und oft schwer verständliches Thema. Ein Bekannter (danke dir) hat mir den folgenden Link zukommen lassen:
https://www.datenschutz-leicht-erklaert.de/#videos
Die Link verweist einer Initiative vom Berufsverband der Datenschutzbeauftragten Deutschlands (BvD) e.V. mit dem Namen Datenschutz geht zur Schule. Die Zielgruppe sind dabei Schüler:rinnen um ihnen das Thema Datenschutz näher zu bringen. Dazu gibt es kurze, Themen bezogene Videos, welche wirklich gut verständlich sind.
Vielleicht ebenfalls etwas für euch?
Tote Links auf einer Webseite zu suchen, kann aufwendig sein. Es gibt viele Angebote im Internet, diese sind aber meist auf eine gewisse Anzahl Seiten beschränkt und ab dann kostenpflichtig.
Ich mag Tools, die einen Job gut können und dieses möglichst einfach erledigen. Daher habe ich für diesen Fall den LinkChecker für die CLI.
Das Tool ist schnell per pip installiert:
pip3 install linkchecker
Die Bedienung ist nicht viel komplizierter:
linkchecker https://www.kernel-error.de
Ohne weitere Angaben läuft das Tool mit 10 threads los, dieses lässt sich über die Option -t erweitern:
linkchecker -t 200 https://www.kernel-error.de
Nun läuft das Tool über die komplette Webseite und prüft alle Links, ist einer kaputt, meldet das Tool dieses. Dabei bekommt man direkt die Informationen, was verlinkt wurde, was der eigentliche Link ist und auf welcher seiner Seiten sich dieses befindet. So lässt sich ohne große Mühe und Arbeit nach toten Links suchen und diese im Anschluss beheben.
URL `www.kernel-error.de' Parent URL https://www.kernel-error.de/en/lala/seite, line 746, col 17 Real URL https://www.kernel-error.de/en/lala/zeugen Check time 67.089 seconds Result Error: 404 Not Found
Viel Spaß!
Link zur Dead Link Bild Quelle: https://www.deviantart.com/amiamalilium/art/It-looks-like-you-found-a-dead-link-365756737
Der Raspberry Pi 4 , egal ob mit 4GB oder 8GB RAM, ist in der Kombination mit Kodi eine wunderbare Erweiterung am Fernseher. Leider sorgte die letzte Version Kodi v19.3 (Matrix) bei mir für ein paar Problemchen. So stockte oder ruckelte die Wiedergabe von Videos oder die Wiedergabe lief für einige Minuten gut, dann wurde gebuffert, nur damit sich dieses Spielchen alle paar Minuten wiederholte. Egal ob im WLAN oder direkt am LAN.
Folgende Änderungen haben bei mir für eine Lösung der Probleme gesorgt:
<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
<cache>
<memorysize>524288000</memorysize>
<buffermode>1</buffermode>
<readfactor>6</readfactor>
</cache>
</advancedsettings>
Achtung… Bei XML Dateien, spielt das richtige „Einrücken“ schon mal eine Rolle 😉
2. Erweitern des Arbeitsspeichers für die GPU, sowie das Erzwingen des „Turbo“ Modus.
Dafür einfach die Datei /flash/config.txt um folgende Zeilen erweitern/einpassen:
# Default GPU memory split, 76MB are needed for H264 decoder gpu_mem=256 force_turbo=1
Wer dieses gerne per SSH machen möchte, muss das Volume /flash einmal schreibfähig mounten:
mount -o remount,rw /flash
Die Option gpu_mem setzt recht einfach den, für die Grafikkarte, reservierten Arbeitsspeicher fest auf 256MB. Dieses macht selbst bei der 4GB Raspberry PI 4 Version kein Problem.
force_turbo deaktiviert das dynamische, lastabhängige takten der CPU, GPU und des Arbeitsspeichers, sowie der Spannungen. Alles läuft daher auf Maximum, aber ohne zu übertakten. Dieses hat weniger Auswirkungen auf die Probleme bei der Wiedergabe, sorgt aber für ein allgemein „flüssigeres“ Verhalten. Dafür steigt die Stromaufnahme und die Temperatur. Da wir hier über einen Raspberry sprechen, ist es wohl für die Meisten zu vernachlässigen.
3. Um Temperatur und Geräuschpegel im Zaum zu halten, empfiehlt sich ein gutes passiv gekühltes Gehäuse. Folgendes kann ich empfehlen: https://amzn.to/3qF61pe
Das mitgelieferte Netzteil hat ausreichend Power, man kommt noch an „alles“ ran, das Gehäuse ist sehr massiv und selbst bei großer Last/langem Betrieb, wird alles nur handwarm.
Von QUIC habt ihr sicher alle schon gehört, seit knapp Mitte 2021 ist dieser neue Standard fertig und in einem recht einfach zu merkendem RFC 9000 beschrieben.
Im Grunde geht es darum, HTTP Verbindungen schneller zu machen und dabei sogar UDP zum Einsatz zu bringen. Nicht ganz korrekt ist es einfach eine Weiterentwicklung von SPDY.
Um zu testen, ob eine Webseite bereits HTTP/3 also QUIC unterstüzt kann ich euch http3check.net ans Herz legen. Diese gibt, wenn gewünscht, sogar noch ein paar Detailinformationen aus.
Wer sehen möchte, ob sein Browser QUIC „macht“, kann auch nginx.org nutzen. Steht oben „Congratulations! You’re connected over QUIC.“ Dann ist man ein Gewinner.
Die Konfiguration am NGINX ist wie immer sehr einfach und ein sehr gutes Beispiel findet sich direkt von nginx.
Mein NGINX spricht dieses nun ebenfalls, mal sehen ob es Probleme gibt.
Ich nutze Joomla seit 2006, als es aus Mambo hervorging. Die Datenbank und einige Plugins/Teils sind inzwischen also sehr alt und machen bei Versionssprüngen immer mehr Probleme. Den Wechsel vom CMS habe ich dennoch immer von mir weggeschoben, denn es macht viel Arbeit und für eine solch kleine Spielerei lohnt der Aufwand kaum. Da ich es inzwischen eh nur noch für einfache Blogeinträge nutze… Nun ich werde wohl in der nächsten Zeit auf WordPress wechseln. Damit wird es ebenfalls einen neuen RSS Feed geben und sicher wird ebenfalls viel Content verschwinden.
Lieber Thorben,
vielen Dank, dass du uns so lange ertragen hast. Du hast unsere Arbeit leichter und bunter gemacht. Ohne dich hätten wir sicher schon die Raufasertapete mehr als einmal von der Wand gefressen.
Vielen Dank für deine Unterstützung in technischer und menschlicher Weise! Wir werden dich NIE vergessen!
Liebe Grüße
Die zwei „Dicken“
Mit FreeBSD 13 lässt sich die native ZFS Verschlüsselung direkt nutzen. Dabei muss man zwischen einem komplett verschlüsselten zpool und verschlüsselten Datasets unterscheiden. Hat man einen komplett verschlüsselten zpool, bedeutet es nicht, dass damit auch alle Datasets verschlüsselt sein müssen, so wie es auch nicht bedeutet, dass man Datasets nur verschlüsseln kann, wenn auch der komplette ZFS Pool verschlüsselt ist.
Wer nun also sein FreeBSD auf Version 13 gehoben hat, möchte ggf. einzelne ZFS Datasets verschlüsseln. In der Praxis trifft dieses sicher oft auf Jails zu. Diese liegen in der Regel in eigenen ZFS Datasets und mit dem folgenden Beispiel lassen sich diese und andere Datasets nachträglich verschlüsseln.
Im Beispiel haben wir den Pool zroot und in diesem das Dataset varta. Weder der zpool noch das Dataset sind aktuell verschlüsselt:
root@testtest:/ # zfs list zroot/varta NAME USED AVAIL REFER MOUNTPOINT zroot/varta 100M 12.0G 100M /zroot/varta root@testtest:/ # zfs get encryption zroot/varta NAME PROPERTY VALUE SOURCE zroot/varta encryption off default root@testtest:/ #
Aktiviert man bei ZFS Dinge wie Komprimierung oder Deduplikation sind diese immer nur ab dem Moment der Aktivierung und bis genau zur Deaktivierung aktiv. Dieses hat viele Vorteile aber auch Nachteile. So greift dieses nur für Daten, welche neu geschrieben werden. Möchte man dieses nachträglich auf alle Daten anwenden, muss man die Daten komplett neu schreiben. Dieses lässt sich am einfachsten und schnellsten per zfs send und zfs receive erledigen. Wenn man also sein bestehendes Dataset verschlüsseln möchte, dann geht dieses faktisch nicht, sondern man erstellt im Grunde ein neues verschlüsseltes Dataset und schreibt seine Daten dort rein.
Bevor wir nun mit der Migration starten, müssen wir noch eine Kleinigkeit wissen…. Zum Verschlüsseln der Daten benötigen wir noch ein Geheimnis, einen Schlüssel/Key. Dieser kann bei ZFS in verschiedenster Form und an verschiedensten Orten liegen. So könnte man den Key zur Ver- und Entschlüsselung auf einen USB-Stick ablegen. Nur wenn dieser auch im System steckt usw. usw.. Der eingängigste Weg ist sicher ein Passphrase welches per prompt abgefragt wird. Will man sein verschlüsseltes Dataset öffnen, wird man nach einem Kennwort gefragt, welches sich das System bis zum nächsten Reboot oder dem manuellen „Schließen“ des Datasets merkt. Diesen Zustand wollen wir nach der Migration, in diesem Beispiel, erreichen.
Zur Verdeutlichung erstellen wir kurz ein neues verschlüsseltes Dataset:
root@testtest:/ # zfs create -o encryption=on -o keyformat=passphrase -o keylocation=prompt zroot/enc-beispiel Enter passphrase: Re-enter passphrase:
Damit haben wir ein neues Dataset welches sofort benutzt werden kann, alles was wir in dieses legen, ist verschlüsselt.
root@testtest:/ # zfs list zroot/enc-beispiel NAME USED AVAIL REFER MOUNTPOINT zroot/enc-beispiel 200K 12.0G 200K /zroot/enc-beispiel
Schauen wir in die Optionen des Datasets ist die Verschlüsselung aktiviert und der Schlüssel wird per Prompt vom Benutzer abgefragt:
root@testtest:/ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel NAME PROPERTY VALUE SOURCE zroot/enc-beispiel encryption aes-256-gcm - zroot/enc-beispiel keylocation prompt local zroot/enc-beispiel keyformat passphrase -
Wie immer wird das Dataset sofort eingehangen:
root@testtest:/ # mount |grep enc-beispiel zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)
Nach einem reboot, wird das Dataset nicht automatisch eingehangen, da ZFS den Schlüssel nicht hat. Wenn wir es nun einhängen und ZFS anweisen, den Schlüssel zu laden (Option -l), dann werden wir zur Eingabe des Kennwortes aufgefordert und können das Dataset im Anschluss wieder nutzen:
root@testtest:~ # mount | grep enc-beispiel root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/enc-beispiel NAME PROPERTY VALUE SOURCE zroot/enc-beispiel encryption aes-256-gcm - zroot/enc-beispiel keylocation prompt local zroot/enc-beispiel keyformat passphrase - root@testtest:~ # mount | grep enc-beispiel root@testtest:~ # zfs mount -l zroot/enc-beispiel Enter passphrase for 'zroot/enc-beispiel': root@testtest:~ # mount | grep enc-beispiel zroot/enc-beispiel on /zroot/enc-beispiel (zfs, local, noatime, nfsv4acls)
Gut gut… So viel zu den Basics. Damit ist nun auch klar, warum im nun folgenden zfs send / zfs reveive Beispiel, der Schlüssel einen Umweg nehmen wird. Denn durch das pipen kommen wir so schlecht an die stdin heran, um das Passphrase einzugeben 😉 Wir sind nun also wieder zurück bei unserem unverschlüsselten Dataset varta und dessen Migration in einen verschlüsselten Zustand. Als erstes legen wir nun das gewünschte Passphrase in einer Datei ab:
root@testtest:~ # echo 'Tolles-Kennwort' > /kennwort.txt root@testtest:~ # cat /kennwort.txt Tolles-Kennwort
Ebenfalls erstellen wir einen snapshot vom Dataset varta, welchen wir zur Migration nutzen:
root@testtest:~ # zfs snapshot zroot/varta@migration root@testtest:~ # zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT zroot/varta@migration 0B - 100M -
Jetzt kann die eigentliche Migration starten:
root@testtest:~ # zfs send zroot/varta@migration | zfs receive -F -o encryption=on -o keyformat=passphrase -o keylocation=file:///kennwort.txt zroot/en-varta root@testtest:~ # zfs list zroot/varta zroot/en-varta NAME USED AVAIL REFER MOUNTPOINT zroot/en-varta 100M 11.8G 100M /zroot/en-varta zroot/varta 100M 11.8G 100M /zroot/varta root@testtest:~ # zfs list -t snapshot NAME USED AVAIL REFER MOUNTPOINT zroot/en-varta@migration 112K - 100M - zroot/varta@migration 0B - 100M -
Das ist schnell und einfach, oder? Natürlich liegt nun noch immer das Passphrase offen in einer Datei im root des Systems. Wir müssen nun also den Ort des Schlüssels auf prompt ändern:
root@testtest:~ # zfs get keylocation zroot/en-varta NAME PROPERTY VALUE SOURCE zroot/en-varta keylocation file:///kennwort.txt local root@testtest:~ # zfs set keylocation=prompt zroot/en-varta root@testtest:~ # zfs get keylocation zroot/en-varta NAME PROPERTY VALUE SOURCE zroot/en-varta keylocation prompt local
Damit kann die Datei mit dem Passphrase gelöscht werden:
root@testtest:~ # rm /kennwort.txt
Ebenfalls kann nun auch das unverschlüsselte Dataset weg:
root@testtest:~ # zfs destroy -r zroot/varta
Wenn man nun möchte, kann man das neue Dataset natürlich an die gleiche Stelle mounten oder direkt komplett gleich dem alten benennen:
root@testtest:~ # zfs rename zroot/en-varta zroot/varta
Damit ist die Migration fertig und das Dataset ist verschlüsselt:
root@testtest:~ # zfs list zroot/varta NAME USED AVAIL REFER MOUNTPOINT zroot/varta 100M 11.9G 100M /zroot/varta root@testtest:~ # zfs get encryption,keylocation,keyformat zroot/varta NAME PROPERTY VALUE SOURCE zroot/varta encryption aes-256-gcm - zroot/varta keylocation prompt local zroot/varta keyformat passphrase -
Es sieht nun nach sehr viel aus, ist es aber nicht und es lässt sich sogar automatisieren.
Fragen? Dann fragen!
© 2024 -=Kernel-Error=-
Theme von Anders Norén — Hoch ↑
