-=Kernel-Error=-

IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Kategorie: Linux & BSD (Seite 5 von 8)

Anleitungen und Erfahrungsberichte rund um Linux-Distributionen und FreeBSD — vom Desktop bis zum Server.

RFC 7858 – DNS over Transport Layer Security

30. Oktober 2017 / / Keine Kommentare

Ich habe in den letzten Tagen etwas mit dem RFC 7858 (https://tools.ietf.org/html/rfc7858) herumgespielt. Meine Zonen und auch Dienste sind per DNSsec, HSTS, Pinning usw. usw. abgesichert. Warum also noch DNS per TLS? Nun ja… Sinn macht es sicher keinen, bei mir ist nichts spannendes zu finden und kaum ein Besucher wird mit Problemen rechnen müssen wenn er hier ist. Für mich sollte Kryptographie nicht die Ausnahme sondern der Normalzustand sein. RFC 7858 ist da nur ein weiteres Detail. In einer DNS Abfrage finden sich selten geheime Daten. Klar wäre es schlecht wenn diese verändert würden um diese zu verhindern reicht eine Signatur. Das mitlesen der DNS Abfragen würde einer dritten Person so aber offenlegen wo man surft und welche Dienste man nutzt. Sind diese Abfragen per TLS verschlüsselt bleibt dieses geheim. Daher macht es wohl am meisten Sinn es für seinen lokalen DNS Resolver zu nutzen oder es auf großen DNS Servern zu aktivieren. DNS Servern welche sich um viele Zonen kümmern….

Um irgendwo zu starten und selbst einen Eindruck davon zu bekommen habe ich es auf meinen DNS Servern für meine Zonen aktiviert. Bis auf ns2.kernel-error.org haben die Server gültige Zertifikate. Bei ns2.kernel-error.org muss ich mal schauen wie es sich entwickelt.

Als Test:

$ getdns_query -s www.kernel-error.de a @176.9.109.53 -l L

Viel Spaß

Siehe auch: DoT und DoH mit BIND 9.20, DNS over TLS mit Stunnel und BIND9: Eigenen DoT-Server einrichten, DNS over TLS (DoT) mit BIND, Stunnel und Android 9 einrichten, DNS over TLS mit BIND, Stunnel und Android 9: Eigener DoT-Server

Fragen? Einfach melden.

ioping: Read- und Write-Latency schnell messen

8. August 2017 / / Keine Kommentare

Für ausführliche Storage-Benchmarks gibt es Tools wie bonnie++ oder fio. Wenn man nur schnell die Read- oder Write-Latency eines Dateisystems prüfen will, reicht ioping — ein einzelner Befehl, Ergebnis in Sekunden.

Installation

# FreeBSD
pkg install ioping

# Debian/Ubuntu
apt install ioping

Read-Latency messen

ioping -s 256k -T 120 -D -c 20 ./
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=1 time=16.0 us (warmup)
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=2 time=35.7 us
256 KiB <<< ./ (zfs tanksmeer/usr/home): request=3 time=45.8 us
...

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 853.7 us, 4.75 MiB read, 22.3 k iops, 5.43 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.2 KiB/s
min/avg/max/mdev = 35.7 us / 44.9 us / 52.8 us / 3.85 us

Die Parameter im Detail:

  • -s 256k — Blockgröße pro Request (hier 256 KiB)
  • -T 120 — Timeout in Sekunden, Requests die länger brauchen werden ignoriert
  • -D — Direct I/O, umgeht den Kernel-Cache (misst die echte Disk-Latency)
  • -c 20 — Anzahl der Requests
  • ./ — Pfad zum Dateisystem das gemessen werden soll

Die Summary am Ende zeigt min/avg/max/mdev — genau wie bei ping. Hier: durchschnittlich 44,9 µs Read-Latency auf einem ZFS-Dataset.

Write-Latency messen

Für die Write-Latency kommt ein einziger Parameter dazu — -W:

ioping -s 256k -T 120 -D -W -c 20 ./
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=1 time=27.0 us (warmup)
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=2 time=54.4 us
256 KiB >>> ./ (zfs tanksmeer/usr/home): request=3 time=60.6 us
...

--- ./ (zfs tanksmeer/usr/home) ioping statistics ---
19 requests completed in 3.86 ms, 4.75 MiB written, 4.93 k iops, 1.20 GiB/s
generated 20 requests in 19.0 s, 5 MiB, 1 iops, 269.5 KiB/s
min/avg/max/mdev = 51.6 us / 202.9 us / 2.65 ms / 577.9 us

Write ist hier erwartungsgemäß langsamer — 202,9 µs im Schnitt gegenüber 44,9 µs beim Lesen. Die höhere Standardabweichung (577,9 µs vs. 3,85 µs) zeigt, dass einzelne Writes deutlich länger dauern können (hier ein Ausreißer mit 2,65 ms — vermutlich ein ZFS Transaction Group Commit).

Weitere nützliche Optionen

# Fortlaufend messen (wie ping ohne -c)
ioping -D ./

# Nur die Summary nach 10 Requests
ioping -D -c 10 -q ./

# Bestimmte Blockgröße (4k für Random I/O)
ioping -s 4k -D -c 20 ./

# Netzlaufwerk / NFS-Mount testen
ioping -D -c 20 /mnt/nfs-share/

Praktisch für einen schnellen Vergleich: Lokale SSD, NFS-Share und USB-Platte mit dem gleichen Befehl messen — die Unterschiede werden sofort sichtbar. Fragen? Einfach melden.

FreeBSD CPU Microcode Updates

2. August 2017 / / Keine Kommentare

Das es auch mal in einer CPU Fehler geben kann ist nicht jedem bewusst. Da es aktuell sehr durch die Presse geht, inzwischen vielleicht schon einigen Menschen mehr als vorher. Das diese Fehler in CPUs sogar recht oft vorkommen, daran denken die wenigsten. Ich kann mich noch an einen Intel Prozessor erinnern bei dem man einfach mit dem Windows Taschenrechner testen konnte ob ein bestimmte Bug vorliegt. Diese CPU durfte man sogar zurückgeben weil es sich nicht durch ein simples Update fixen lässt.

Update? Ja man kann den sogenannten Microcode der CPU updaten. Ja der Microcode ist fest in der CPU „eingebrannt“ ein solches Update muss also jedes mal gemacht werden, wenn die CPU erneut eingeschaltet wird. Daher lösen es die meisten Mainbordhersteller über ein Bios Update. Wenn ihr also mal die Changelogs eurer Bios Updates durchgeht werdet ihr immer mal wieder etwas von CPU und oder Microcode lesen. Das ist dann genau so etwas. Setzt man ein älteres Mainboard ein gibt es auch kein Update. Setzt man Linux ein installiert man sich die Microcode Updates und bei jedem Start bekommt die CPU so ihr Update. Bei FreeBSD geht dieses natürlich ebenfalls. Da diese Frage bei mir schon ein paar mal angekommen ist, dieser Beitrag.

Das Paket nennt sich devcpu-data und findet sich in der Ports und ebenfalls auch als Binary:

$ pkg install devcpu-data

Damit es aktiviert ist und beim Booten geladen wird, ja ihr erratet es… Folgendes muss in die /etc/rc.conf :

microcode_update_enable="YES"

Dann lässt sich alles einmal anstarten und direkt sehen ob es erfolgreich ist:

$ /usr/local/etc/rc.d/microcode_update start
Updating cpucodes...
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl0 from rev 0x28 to rev 0x29... done.
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl2 from rev 0x28 to rev 0x29... done.
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl4 from rev 0x28 to rev 0x29... done.
/usr/local/share/cpucontrol/m12206a7_00000029.fw: updating cpu /dev/cpuctl6 from rev 0x28 to rev 0x29... done.
Done.

Wie man sieht, er konnte ich ein Update vom Microcode durchführen und es gab auch eines. Es kommt immer mal wieder vor das Fehler gefunden werden daher dieses immer aktuell halten.

Siehe auch: FreeBSD auf dem Desktop

Fragen? Einfach melden.

FreeBSD: WLAN und der Ländercode korrekt einstellen

31. Mai 2017 / / 1 Kommentar
Grafik zum Thema FreeBSD WLAN und Ländercode: Ein WLAN-Router mit Antennen, daneben Terminal-Kommandos zur ifconfig-Konfiguration von Regdomain und Country. Im Hintergrund eine Weltkarte mit Markierungen für FCC/US-Default und ETSI/DE sowie der FreeBSD-Daemon als zentrales Element.

Funkregulierung ist länderspezifisch. Jede Region definiert, welche 2,4 GHz und 5 GHz-Kanäle, Sendeleistung und Radar-/DFS-Regeln gelten. In FreeBSD steuert eine Kombination aus Regulatory Domain (z. B. ETSI für Europa, FCC für USA, APAC für Asien/Pazifik) und Country (z. B. „DE“ bzw. „Germany“, „AT“ bzw. „Austria“, „GB“ bzw. „United Kingdom“) den erlaubten Betrieb. Ohne Anpassung bleibt oft der US-Default aktiv, der in Europa eingeschränkter ist.

FreeBSD nutzt keine ISO-Kurzcodes allein (also nicht nur „DE“, „UK“). Der Country-Name muss exakt aus den Einträgen in /etc/regdomain.xml kommen (z. B. „United Kingdom“ statt „UK“). Diese Erkenntnis hat bei mir zum Beginn etwas gebraucht

Praxis: So stellst du es sauber ein.

1 Hardware/Interface prüfen

sysctl net.wlan.devices      # listet WiFi-Chips
ifconfig wlan0               # zeigt aktuelles Regdomain/Country
ifconfig wlan0 list regdomain
ifconfig wlan0 list countries

2 Interface runterfahren

ifconfig wlan0 down

3 Regdomain & Country setzen

ifconfig wlan0 regdomain etsi2 country DE
# etsi2 bezieht sich auf die regionale Definition (Europa),
# DE ist der länderspezifische Eintrag aus /etc/regdomain.xml

4 Interface wieder hochfahren

ifconfig wlan0 up

5 Persistenz in /etc/rc.conf (denn das was wir bis jetzt gemacht haben ist nach dem nächsten Reboot weg).

sysrc create_args_wlan0="country DE regdomain etsi2"
sysrc wlans_iwn0="wlan0"
sysrc ifconfig_wlan0="WPA DHCP"

Ersetze iwn0 durch dein Device und etsi2 durch den passenden Regdomain-Block, wenn du nicht DE bist, sonst ist copy&paste gut.

Warum das wichtig ist

  • Rechtliche Konformität: falsche Domain/Code kann gegen lokale Funkbestimmungen verstoßen. Was in der Regel aber eher ein theoretisches Problem sein sollte.
  • Kanalauswahl: Europa nutzt 1–13, USA nur 1–11. US-Default kann daher Kanäle ausblenden. Kanal 13 ist meist sehr „leer“ also gut, wenn viel um einen herum los ist ABER alle Geräte müssen das auch können und passend, wie hier beschrieben, für sich konfiguriert sein.
  • DFS/5 GHz: moderne Regime wie ETSI/ETSI2 definieren zusätzliche Regeln für 5 GHz/DFS; FCC-Default kann hier ebenfalls andere Limits haben.

Aktuelle Unterschiede zu älteren Releases (Update 2026).

FreeBSD 14.x/15.x haben bessere Treiber und WLAN-Stack-Support (siehe auch FreeBSD auf dem Desktop), was dazu führt, dass viele Geräte stabiler laufen. Die Regulatory Domain-Mechanik selbst hat sich nicht grundlegend verändert; sie ist weiterhin über ifconfig steuerbar. Firmware-Unterstützung für Chips kann aber Einfluss auf die tatsächliche Kanalnutzung haben, unabhängig von RegDomain-Einstellungen. Auf Probleme bin ich damit noch nicht gestoßen, was aber nur bedeutet, dass meine Hardware kein Problem macht.

Risiken/Trade-offs

  • Falsche Codes: „AU“ ist nicht immer Australien, manchmal Österreich im Regdomain XML; achte auf die Einträge. Aber hey, es gibt in Wien am Flughafen ja auch einen Schalter, nur um Menschen zu erklären, warum sie jetzt in Österreich und nicht in Australien sind Hin und wieder würde ich da gerne Sitzen, nur um die Gesichter zu sehen. Ja, das ist böse, ich weiß.
  • Installer-Defaults: Der FreeBSD-Installer setzt nicht immer den passenden Regdomain/Country für WLAN – du musst das nachinstallieren/konfigurieren. Aber hey, das kennen wir doch von FreeBSD und mögen ja auch irgendwie diese Verlässlichkeit, oder?
  • Treiber/Firmware: Manche WLAN-Adapter benötigen separate Firmware-Blobs (z. B. Realtek), sonst funktioniert WiFi gar nicht – unabhängig von Regdomain.

Fragen? Einfach melden.

FreeBSD slim lightDM MATE und Shutdown/Reboot durch den Benutzer

17. März 2017 / / Keine Kommentare

Auf fast jedem Unix ähnlichen System haben Benutzer nicht das Recht das komplette System herunterfahren oder neustarten zu können. Macht ja nur Sinn… Nutzt man dieses System aber als Desktop könnte es in gewissen Fällen ebenfalls nicht dumm sein, wenn Benutzer nicht in der Lage sind das System zu rebooten und einen shutdown abzusetzten. In den Meisten Fällen ist man dann wohl doch alleine auf seinem System und es ist eher eine Einschränkung wenn man sich erst als privilegierter Benutzer anmelden muss um seinen Comupter/Laptop abschalten zu können.

Dafür wurden nun verschiedenste Dienste entwickelt um dieses so einfach wie möglich zu erledigen. Das wohl bekannteste und verbreitetste ist consolekit / policykit / polkit. Dieses System ermöglicht es bestimmte Rechte basierend auf Benutzer oder Gruppen zu verteilen. Die gängigen Logonmanager sowie Displaymanager haben in der Regel bereits die Möglichkeit eingebaut um sich damit auszutauschen. Der normale Linux Benutzer wird damit wohl kaum noch in Berührung kommen.

Am einfachsten schaut man sich als Benutzer einmal in einem xterminal an welche Möglichkeiten einem geboten werden:

$ pkaction

Schon gibt es eine Liste der aktuell konfigurierbaren „Berechtigungen“. Ob shutdown und reboot dabei ist sagt einem:

$ pkaction | grep -E 'stop|restart'
org.freedesktop.consolekit.system.restart
org.freedesktop.consolekit.system.restart-multiple-users
org.freedesktop.consolekit.system.stop
org.freedesktop.consolekit.system.stop-multiple-users

Ob der eigene Benutzer es bereits darf sagt einem:

$ pkaction --action-id org.freedesktop.consolekit.system.restart --verbose
org.freedesktop.consolekit.system.restart:
  description:       Restart the system
  message:           System policy prevents restarting the system
  vendor:            
  vendor_url:        
  icon:              
  implicit any:      no
  implicit inactive: no
  implicit active:   yes

Implicit active ist hier der spannende Eintrag… Dieser ergibt sich für mich aus der von mir angelegten Regel 05-shutreboot.rules unter /usr/local/etc/polkit-1/rules.d diese schaut wie folgt aus:

polkit.addRule(function (action, subject) {
  if (action.id == "org.freedesktop.consolekit.system.restart" ||
  action.id == "org.freedesktop.consolekit.system.stop"
  && subject.isInGroup("wheel")) {
  return polkit.Result.YES;
  }
});

Die Regel besagt das org.freedesktop.consolekit.system.stop sowie restart das Ergebnis YES zurückgeben soll, wenn der Benutzer in der Gruppe wheel ist. ist diese Regel eingetragen, und man ist sich sicher das alles klappen müsste, es dennoch nicht funktioniert sind ein beliebter Fehler die Rechte vom Ordner. Hier könnte folgendes helfen:

$ chown polkitd:wheel /usr/local/etc/polkit-1

In diesem Sinne…

Siehe auch: FreeBSD auf dem Desktop

Fragen? Einfach melden.

Die fish shell geht unter FreeBSD 11 nicht mehr :-P

12. Oktober 2016 / / Keine Kommentare

Ich dachte schon voll einen am Zaun zu haben. Nach meinem letzten Update von fish ging plötzlich ein Backspace mehr und die Pfeiltasten gaben ebenso lustige Steuerzeichen zurück wie Ende oder Pos1 :-/

Es ist tatsächlich ein dummer Bug. Darauf gekommen bin ich über: https://github.com/fish-shell/fish-shell/issues/3050

Sowie am Ende: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213013

Comment 9 weckt Hoffnung:

 Baptiste Daroussin freebsd_committer 2016-10-06 19:52:25 UTC

The issue is fixed in head (12) I will merge in 11 in a month and will propose the fix for an errata, thanks for reporting

Bis dahin verhilft mir folgender Workaround beim Starten meines Terminals zu einer sauberen Shell:

Einfach als Start Command für mein Mate-Terminal:

env LC_ALL=C mate-terminal

Tut was es soll!

So long…

Siehe auch: FreeBSD auf dem Desktop

Fragen? Einfach melden.

Upgrade FreeBSD Desktop 10.3 to 11.0

27. September 2016 / / Keine Kommentare

Veraltet: FreeBSD 10.3 und 11.0 haben seit Jahren keinerlei Support mehr. Aktuelle Versionen: FreeBSD Releases. Das Upgrade-Verfahren mit freebsd-update ist aber weiterhin identisch.

Da hier schon die Fragen gekommen sind.. Folgende kurze Schritte haben mir zu meinem neuen FreeBSD 11 Desktop gebracht:

$ pkg upgrade
$ freebsd-update fetch install
$ freebsd-update -r 11.0-RELEASE upgrade
$ freebase-update install
$ reboot
$ freebase-update install
$ pkg remove -f javavmwrapper
$ pkg install pkg
$ pkg upgrade
$ rehash
$ freebase-update install
$ reboot
$ uname -a

Mein Benutzer musste dann noch in die Gruppe Video:

$ pw groupmod video -m username

Der Bootloader hatte ebenfalls ein Problem das nvidia Modul zu laden. Daher habe ich den Eintrag aus der /boot/loader.conf entfernt und lasse es nun über die /etc/rc.conf mit folgendem Eintrag laden:

kld_list="nvidia"

Das ist auch schon alles 🙂

Fragen? Einfach melden.

FreeBSD 11 kommt…

26. September 2016 / / Keine Kommentare

Ich ertappe mich aktuell immer mal wieder dabei auf die Release Process Seite von FreeBSD 11 zu schauen. Mit immer mal wieder meine ich 1 / 2 mal am Tag.

https://www.freebsd.org/releases/11.0R/schedule.html

Oh ich bin gerade total gespannt auf die neue Version. Auf den Testkisten habe ich die RCs ja schon angetestet und ich lese ganz brav die current-liste (was es nicht besser macht). Jetzt wurde der RC3 Build ja vom 26.08 auf den 14.09 verschoben, das hat natürlich den Rest ebenfalls geschoben *schnief* 28.09 ist nun also erst einmal der press release Termin. uhhh das ist schon übermorgen *freu*.

Ich habe auch ganz brav wieder Geld gegeben: https://www.freebsdfoundation.org/donate/

Auf was ich besonders warte? Ohh auf 1000 Dinge der neuen Version aber besonders auf ein, vielleicht etwas dummes, Detail. trim auf zfs mit geli.

Wann habt ihr eigentlich das letzte mal etwas gespendet und sei es nur 5€??

Dear Sebastian van de Meer,

The FreeBSD Foundation would like to thank you for your generous donation of $200.00 on September 26, 2016.
 
It's people like you that make it possible for us to continue supporting the FreeBSD Project and community worldwide. We are incredibly grateful for all the support we receive from you and so many individuals and organizations that value FreeBSD.
 
The FreeBSD Foundation is a 501(c)3 non-profit organization dedicated to supporting and promoting the FreeBSD Project and community worldwide. The Foundation gratefully accepts donations from individuals and businesses. Donations are used to fund and manage development projects, educating the public and promoting FreeBSD, sponsoring BSD conferences and summits, providing travel grants to FreeBSD developers, protecting FreeBSD IP and providing legal support to the Project, and purchasing hardware to build and improve FreeBSD Project infrastructure.
 
The FreeBSD Foundation is entirely supported by donations. For information regarding our goals, projects and use of collected funds, please visit our web site: www.FreeBSDFoundation.org.
 
No goods or services of any value were or will be transferred to you in connection with this donation. Please keep this written acknowledgment of your donation for your tax records.
 
Thanks again for your support!
 
Sincerely,
 
Deb Goodkin
Executive Director
The FreeBSD Foundation

Siehe auch: FreeBSD auf dem Desktop

Fragen? Einfach melden.

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

13. November 2015 / / 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.

Fragen? Einfach melden.

« Ältere Beiträge Neuere Beiträge »

© 2026 -=Kernel-Error=- — RSS

Theme von Anders Norén — Hoch ↑