Datenhaufen zu IT und Elektronik.

Schlagwort: FreeBSD (Seite 2 von 2)

SSD Secure Erase mit FreeBSD: So löschst du deine SSD sicher

Um alle Daten einer SSD möglichst sicher zu löschen gibt es im ATA die Funktion: „ATA Secure Erase“. Möchte man nun seine SSD schnell und einfach von allen Daten befreien (dd mit Nullen ist ja eher eine schlechte und nicht funktionsfähige Möglichkeit bei SSDs), nutzt man einfach diese Funktion.

Bei einem FreeBSD sieht dieses unter optimalen Bedingungen wie folgt aus:

root@sun-wks:/usr/home/kernel # camcontrol security ada4 -s Erase -e Erase
pass7: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device
pass7: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes)

You are about to ERASE ALL DATA from the following device:
pass7,ada4: <OCZ-AGILITY3 2.15> ATA8-ACS SATA 3.x device

Are you SURE you want to ERASE ALL DATA? (yes/no) yes
Issuing SECURITY_SET_PASSWORD password='Erase', user='master', mode='high'
Issuing SECURITY_ERASE_PREPARE
Issuing SECURITY_ERASE_UNIT password='Erase', user='master'

Erase Complete

Optimale Bedingungen?

Das eine oder andere BIOS „schützt“ die Festplatten vor dieser Funktion und sorgt dafür das sie nicht genutzt werden kann. Hier hilft es die Platte erst nach dem Boot anzuschließen. Um die Funktion nutzen zu können muss der SSD ebenfalls erst ein Kennwort gegeben werden. Ohne gesetztes Kennwort kann die Funktion ebenfalls nicht genutzt werden. Ich habe dieses in einem Abwasch erledigt indem ich erst das Kennwort und dann direkt die Funktion mit dem gesetzten Kennwort aufrufe (-s Erase -e Erase) Erase ist also in meinem Beispiel das gesetzte Kennwort.

Da wir gerade dabei sind… Viele SSDs habe eine Art „Selbstheilungsmodus“… Ist diese aktiviert prüft sich die SSD selbst und repariert sich, soweit möglich. Dieser Modus wird aktiviert wenn die SSD am Strom aber nicht am Datenbus angeschlossen ist. Bedeutet. SATA/SAS Kabel abziehen. Strom anschließen/einschalten und warten. In der Regel sollten SSDs nach knapp 4 Stunden mit ihrer „Selbstheilung“ fertig sein. Dieses lässt sich natürlich im Anschluss noch einmal wiederholen. Funktioniert die SSD nach zwei Durchläufen noch nicht wie gewünscht, wird sie wohl wirklich kaputt sein.

Fragen? Dann Fragen 😀

FreeBSD CPU Microcode Updates

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.

FreeBSD: WLAN und der Ländercode korrekt einstellen

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, 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.

Frag? Dann wie immer fragen 😀

ZFS send/recv Fehler: ‚Cannot receive incremental stream‘ – Lösung

Tach auch… Heute mal wieder etwas zum Thema ZFS (anscheinend wohl im Moment gefragt…)

Wenn man ZFS Volumes abgleichen möchte hilft einem bekanntermaßen ja zfs send / revc. Möchte man noch eine gewisse Historie am Ziel oder es handelt sich um recht große Volumes, dann freut man sich sehr über die Möglichkeit nur die Differenz zwischen zwei Snapshots abgleichen zu müssen.

Als kleines Beispiel:

Ich habe eine FreeBSD Jail für subsonic. In dieser liegen einfach die gesamten Mediafiles, was weiß ich.. Sagen wir mal 100GB. Vom Volume werden dann automatisch per zfsutils snapshots erstellt. Die wöchentlichen snapshots davon möchte ich nun gerne per SSH auf ein anderes System schieben, einfach um die Daten so „gesichert“ zu haben. Jedes System steht dann vielleicht noch in der Colocation in einem anderen DataCenter. Einmal die Woche 100GB abgleichen, das sind dann im Monat 400GB (ja, viel ist anders aber es ist ein reales Beispiel).

Initial pumpt das Skript nun also die 100GB rüber. Ich schreib mal den Befehl ohne Variablen zur besseren Lesbarkeit, ok?

zfssend@system01:~ # zfs send zroot/jails/subsonic@zfs-auto-snap_weekly-2015-06-14-00h14 | ssh zfsrecv@system02 zfs recv zroot/backup/bsd02/subsonic

So jetzt habe ich also auf der zweiten Kiste eine 1a Kopie der Jail. Ab dem Moment muss ich nun nur noch die Differenz zum nächsten Snapshot übertragen mit einem:

zfssend@system01:~ # zfs send -i zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-12-00h14 zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14 | ssh zfsrecv@system02 zfs recv zroot/backup/bsd02/subsonic

Dieses funktioniert natürlich nur so lange die Daten im Ziel nicht verändert werden. Klar wie bei jeder Datensicherung die auf Inkrementen beruht. Ändere ich eines sind die nachfolgenden nicht mehr konsistent. Wie könnte nun so eine Änderung passieren? Ganz einfach ich renne in dem Filesystem herum und ändere Daten oder lege neue an. Was viele übersehen ist etwas wie atime. Also das einfache speichern der Information: Wann wurde die Datei zuletzt angefasst. Dieses würde schon als Änderung reichen um folgendes zu bekommen:

zfssend@system01:~ # zfs send -i zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-12-00h14 zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14 | ssh zfsrecv@system02 zfs recv zroot/backup/bsd02/subsonic
cannot receive incremental stream: destination zroot/backup/bsd02/subsonic has been modified
since most recent snapshot
warning: cannot send 'zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14': signal received

Und nun ist Essig mit der schönen Sicherung und man muss wieder Initial alles rüber schieben? Jain… Natürlich kann man dem zfs recv einfach mitteilen die Änderung zu ignorieren. Denn der snapshot ist dem Ziel ja bekannt. Also kann man dem Ziel sagen: der bestehende snapshot zählt, ignoriere als was danach passiert ist und gleiche das Delta zum aktuellen ab:

zfssend@system01:~ # zfs send -i zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-12-00h14 zroot/jails/subsonic@zfs-auto-snap_weekly-2017-03-19-00h14 | ssh zfsrecv@system02 zfs recv -F zroot/backup/bsd02/subsonci

Ein -F ist hier also unser Freund. Hat man alles sauber geskriptet und ebenfalls nicht vergessen im Ziel hin und wieder die alten snapshots aufzuräumen, sollte man damit schon eine ganz brauchbare Datensicherheit haben!

Viel Spaß!

Neuere Beiträge »

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑