Schlagwort: Jail

FreeBSD: Unverschlüsseltes ZFS-Dataset nachträglich verschlüsseln

26. April 2021 / Sebastian van de Meer / Keine Kommentare

Bild der Bücher FreeBSD Mastery ZFS und FreeBSD Mastery Advanced ZFS

ZFS Encryption lässt sich nicht nachträglich auf ein bestehendes Dataset aktivieren. Die Daten müssen per zfs send | zfs receive in ein neues, verschlüsseltes Dataset geschrieben werden. Typischer Anwendungsfall: Jails, die in eigenen Datasets liegen und nach einem FreeBSD-Upgrade auf 13+ verschlüsselt werden sollen.

Wer die Grundlagen zu ZFS Encryption noch braucht (Dataset anlegen, Passphrase, Mount nach Reboot), findet sie im Beitrag Native ZFS Encryption einrichten.

Ausgangslage

Ein Pool zroot mit dem unverschlüsselten Dataset varta:

zfs list zroot/varta
NAME          USED  AVAIL     REFER  MOUNTPOINT
zroot/varta   100M  12.0G      100M  /zroot/varta

zfs get encryption zroot/varta
NAME         PROPERTY    VALUE   SOURCE
zroot/varta  encryption  off     default

Migration

Bei zfs send | zfs receive kann man kein Passphrase interaktiv eingeben, weil stdin durch die Pipe belegt ist. Deshalb legt man den Schlüssel temporär in einer Datei ab:

echo 'MeinGeheimesPassphrase' > /tmp/keyfile.txt
chmod 600 /tmp/keyfile.txt

Snapshot erstellen und in ein neues verschlüsseltes Dataset senden:

zfs snapshot zroot/varta@migration

zfs send zroot/varta@migration | \
  zfs receive -F \
  -o encryption=on \
  -o keyformat=passphrase \
  -o keylocation=file:///tmp/keyfile.txt \
  zroot/en-varta

Das neue Dataset zroot/en-varta enthält jetzt dieselben Daten, verschlüsselt mit AES-256-GCM:

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

Aufräumen

Die Keyfile-Referenz auf Passphrase-Abfrage umstellen und die temporäre Datei löschen:

zfs set keylocation=prompt zroot/en-varta

zfs get keylocation zroot/en-varta
NAME            PROPERTY     VALUE   SOURCE
zroot/en-varta  keylocation  prompt  local

rm /tmp/keyfile.txt

Dann das alte Dataset entfernen und das neue umbenennen:

zfs destroy -r zroot/varta
zfs rename zroot/en-varta zroot/varta

Fertig. Das Dataset liegt jetzt verschlüsselt am selben Mountpoint wie vorher:

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   -

Hinweise

Bei Jails: Jail vorher stoppen, nach der Migration den Mountpoint anpassen falls nötig (zfs set mountpoint=...), dann neu starten. Bei großen Datasets dauert der zfs send | zfs receive entsprechend lange. Ein Test mit einem kleinen Dataset vorher schadet nicht.

Eine Übersicht über alle ZFS-Funktionen gibt es im ZFS-Überblick. Fragen? Einfach melden.

FreeBSD Jail Upgrade: Wenn freebsd-update die Version nicht erkennt

26. Juli 2018 / Sebastian van de Meer / Keine Kommentare

FreeBSD-Jails lassen sich mit freebsd-update genauso upgraden wie das Host-System. Der Parameter -b gibt den Pfad zur Jail an:

# Normales Jail-Upgrade
freebsd-update -r 14.2-RELEASE upgrade -b /zroot/jails/myjail
freebsd-update install -b /zroot/jails/myjail
service jail restart myjail
freebsd-update install -b /zroot/jails/myjail
# Pakete aktualisieren
jexec myjail pkg upgrade
freebsd-update install -b /zroot/jails/myjail

Das Problem: Falsche Versionserkennung

Manchmal ist freebsd-update davon überzeugt, dass die Jail bereits auf der Zielversion läuft, obwohl sie es nicht ist. Prüft man manuell, steht da noch die alte Version:

jexec myjail freebsd-version
13.2-RELEASE-p9

Das passiert typischerweise wenn die Jail schon Patches bekommen hat oder wenn der Host auf einer anderen Version läuft als die Jail. freebsd-update liest die Version aus Dateien im Jail-Dateisystem und kommt durcheinander.

Die Lösung: –currently-running

Mit --currently-running gibt man freebsd-update die aktuelle Version explizit vor:

freebsd-update -b /zroot/jails/myjail --currently-running 13.2-RELEASE-p9 -r 14.2-RELEASE upgrade

Danach läuft das Upgrade normal durch. Die Version, die man bei --currently-running angibt, muss exakt der Ausgabe von freebsd-version in der Jail entsprechen, inklusive Patchlevel.

Tipp: Vor dem Upgrade einen ZFS-Snapshot der Jail anlegen. Falls etwas schiefgeht, ist ein Rollback in Sekunden erledigt.

Fragen? Einfach melden.

ZFS send/recv: „Cannot receive incremental stream“ beheben

20. März 2017 / Sebastian van de Meer / Keine Kommentare

Inkrementelle Replikation mit ZFS

Mit zfs send und zfs recv lassen sich Datasets über SSH auf ein anderes System replizieren. Das Schöne daran: Nach einem initialen Vollabgleich muss man nur noch die Differenz zwischen zwei Snapshots übertragen. Bei großen Datasets spart das enorm Bandbreite und Zeit.

Beispiel: Eine FreeBSD Jail mit 100 GB Mediadaten. Wöchentliche Snapshots werden automatisch erstellt. Der initiale Transfer:

zfs send zroot/jails/subsonic@weekly-2017-03-12 | ssh zfsrecv@system02 zfs recv zroot/backup/subsonic

Ab jetzt nur noch das Delta zum nächsten Snapshot:

zfs send -i zroot/jails/subsonic@weekly-2017-03-12 zroot/jails/subsonic@weekly-2017-03-19 \
  | ssh zfsrecv@system02 zfs recv zroot/backup/subsonic

Der Fehler

Das funktioniert nur, solange das Ziel-Dataset seit dem letzten Snapshot nicht verändert wurde. Jede Änderung — und sei es nur ein Update der Access-Time (atime) durch einen Lesezugriff — reicht aus, damit ZFS den inkrementellen Stream ablehnt:

cannot receive incremental stream: destination zroot/backup/subsonic has been modified
since most recent snapshot
warning: cannot send 'zroot/jails/subsonic@weekly-2017-03-19': signal received

ZFS sagt damit: Zwischen dem letzten gemeinsamen Snapshot und jetzt hat sich am Ziel etwas geändert. Das Delta passt nicht mehr.

Lösung und Prävention

Man muss nicht alles neu übertragen. Mit -F weist man zfs recv an, das Ziel-Dataset auf den letzten gemeinsamen Snapshot zurückzurollen und dann das Delta anzuwenden:

zfs send -i zroot/jails/subsonic@weekly-2017-03-12 zroot/jails/subsonic@weekly-2017-03-19 \
  | ssh zfsrecv@system02 zfs recv -F zroot/backup/subsonic

Damit das Problem gar nicht erst auftritt, setzt man das Ziel-Dataset auf readonly:

zfs set readonly=on zroot/backup/subsonic

So kann nichts am Ziel verändert werden — kein atime-Update, kein versehentliches Schreiben. Das -F im Skript schadet trotzdem nicht als Sicherheitsnetz. Und nicht vergessen: Auf dem Zielsystem regelmäßig alte Snapshots aufräumen, sonst wächst der Plattenverbrauch stetig.

Mehr Details in der OpenZFS-Dokumentation zu zfs send. Mehr zu ZFS: ZFS Compression und Deduplication und TRIM im ZFS-Pool aktivieren. Fragen? Einfach melden.

Debian in einer FreeBSD Jail: Linux-Userland mit iocage und debootstrap

13. November 2015 / Sebastian van de Meer / Keine Kommentare

FreeBSD kann Linux-Binaries ausführen. Das ist nichts Neues. Aber ein komplettes Debian in einer Jail laufen lassen, mit apt-get und allem was dazugehört? Das geht auch. Die Jail nutzt den FreeBSD-Kernel, das Userland kommt von Debian GNU/kFreeBSD. iocage erstellt die Jail, debootstrap installiert das Debian-Basissystem hinein.

Hinweis: Debian GNU/kFreeBSD wurde nach Debian 8 (Jessie) eingestellt. Für aktuelle Setups ist linux_enable="YES" in der /etc/rc.conf mit einer regulären Linux-Jail der bessere Weg. Die hier gezeigte Methode funktioniert aber weiterhin mit älteren Debian-Versionen und zeigt das Prinzip.

Voraussetzungen

iocage muss installiert und konfiguriert sein. Zusätzlich wird debootstrap benötigt:

pkg install debootstrap

Jail erstellen

Die Jail wird mit iocage angelegt. Die entscheidenden Parameter sind exec_start und exec_stop. Statt der üblichen FreeBSD-Init-Skripte werden die Debian-Runlevel aufgerufen:

iocage create -e tag=debian-jail01 \
  exec_start="/etc/init.d/rc 3" \
  exec_stop="/etc/init.d/rc 0"

Runlevel 3 startet die Dienste, Runlevel 0 fährt herunter. Den Mountpoint der neuen Jail auslesen:

iocage get mountpoint debian-jail01
# /iocage/jails/19e3594f-.../

Debian installieren

debootstrap holt ein minimales Debian von den Mirrors und entpackt es in das Root-Verzeichnis der Jail. In diesem Beispiel Debian Wheezy:

debootstrap wheezy /iocage/jails/19e3594f-.../root/
# I: Retrieving Release
# I: Retrieving Packages
# I: Resolving dependencies of required packages...
# I: Resolving dependencies of base packages...
# [... ~150 Pakete werden heruntergeladen und entpackt ...]
# I: Configuring adduser...
# I: Configuring apt...
# I: Base system installed successfully.

Das dauert ein paar Minuten. Am Ende steht ein komplettes Debian-Basissystem im Jail-Verzeichnis.

fstab für die Jail

Debian braucht ein paar Dateisysteme die FreeBSD nicht automatisch in Jails mountet. Die fstab der Jail (nicht die im Debian) bekommt drei Einträge:

# /iocage/jails/19e3594f-.../fstab
linsysfs  .../root/sys         linsysfs  rw          0 0
linprocfs .../root/proc        linprocfs rw          0 0
tmpfs     .../root/lib/init/rw tmpfs     rw,mode=777 0 0

linsysfs und linprocfs stellen die Linux-kompatiblen /sys und /proc bereit. Ohne die funktionieren viele Linux-Programme nicht. Das tmpfs für /lib/init/rw braucht Debians Init-System.

Netzwerk und Hostname

IP-Adresse und Hostname setzen:

iocage set vnet=off debian-jail01
iocage set ip4_addr="em0|192.168.1.46/16" debian-jail01
iocage set hostname="debian-jail01" debian-jail01
iocage set host_hostname="debian-jail01" debian-jail01

Die /etc/hosts im Debian-Dateisystem anpassen:

# /iocage/jails/19e3594f-.../root/etc/hosts
127.0.0.1       localhost debian-jail01
::1             localhost ip6-localhost ip6-loopback debian-jail01

Starten und nutzen

Beim ersten Start kommen ein paar Fehlermeldungen wegen mount_unionfs und fehlenden Verzeichnissen. Die sind harmlos und können ignoriert werden:

iocage start debian-jail01
# mount_unionfs: .../: No such file or directory
# mount: .../root/usr/home: No such file or directory
# * Starting 19e3594f-... (debian-jail01)
#   + Started (shared IP mode) OK
#   + Starting services        OK

Konsole betreten:

iocage console debian-jail01
# GNU/kFreeBSD debian-jail01 10.2-RELEASE-p4
root@debian-jail01:~# apt-get update
root@debian-jail01:~# apt-get install mc

apt-get funktioniert, Pakete lassen sich installieren, Dienste starten. Von aussen geht auch iocage exec debian-jail01 uname -a und zeigt den FreeBSD-Kernel mit GNU/kFreeBSD-Userland.

Das Stoppen funktioniert wie bei jeder anderen Jail:

iocage stop debian-jail01

Einordnung

Das hier ist kein Ersatz für eine richtige Linux-VM. Es ist ein Trick: Der FreeBSD-Kernel stellt die Jail-Isolation, Debian liefert das Userland. Nützlich wenn man ein bestimmtes Linux-Tool braucht das es für FreeBSD nicht gibt, oder wenn man testen will wie sich Software unter Debian verhält.

Für produktive Linux-Workloads auf FreeBSD ist heute eher eine reguläre Jail mit dem Linux-Kompatibilitätslayer oder gleich bhyve die bessere Wahl.