Thema: freebsd
-
rc.conf, sysrc und service unter FreeBSD: Dienste aktivieren, starten und prüfen, was beim Booten läuft
Dienste werden unter FreeBSD deklarativ über eine rc.conf-Variable aktiviert (in /etc/rc.conf oder in einer dienstspezifischen Datei unter /etc/rc.conf.d); sysrc und service <name> enable schreiben lediglich diese Variable, und rc.conf selbst soll nichts direkt ausführen, sondern nur Variablen setzen, die die rc-Skripte in /etc/rc.d auswerten. Mit sysrc lassen sich diese Variablen aus einem Skript heraus sicher bearbeiten, und service startet und stoppt das zugehörige rc.d-Skript und meldet dessen Status.
-
FreeBSD aktualisieren: freebsd-update für das Basissystem, pkg upgrade für Pakete und pkg audit für bekannte Schwachstellen
FreeBSD verteilt das Patchen auf zwei voneinander unabhängige Werkzeuge: freebsd-update fetch/install für das Basissystem (mit upgrade -r für einen Wechsel des Major-Release) und pkg upgrade für installierte Pakete. pkgbase, also die Installation des Basissystems selbst als pkg(8)-Pakete, ist für FreeBSD 14 als experimentell und für FreeBSD 15.0 als Technology Preview dokumentiert und noch nicht der Standardweg.
-
FreeBSD-Jails: Überblick für Administratoren zu jail.conf, jls, jexec und Ressourcenlimits mit rctl
Ein Jail erweitert chroot(2) um eine eigene Sicht auf Prozesse, Netzwerk und (optional) Ressourcen und wird deklarativ in jail.conf statt über ad hoc aufgerufene jail(8)-Kommandozeilen konfiguriert. jls listet laufende Jails auf, jexec wechselt in eines, und rctl begrenzt, was die Prozesse eines Jails verbrauchen dürfen – alles vom Host aus verwaltet, wo auch die Kompromittierung eines einzelnen Jails eingedämmt werden soll.
-
Die PF-Firewall unter FreeBSD: pf.conf vor dem Laden mit pfctl -n testen und per geplantem Rollback gegen SSH-Aussperrung absichern
Die Regeln in pf.conf bauen auf einer Standardrichtlinie (pass/block) auf und können über Anchors um Teilregelwerke ergänzt werden. Geladen werden sie mit pfctl -f erst, nachdem pfctl -nf sie geparst hat, ohne sie zu laden. Da ein fehlerhaftes Regelwerk genau die SSH-Sitzung kappen kann, mit der es eingespielt wird, ist ein vor dem Laden neuer Regeln mit at(1) geplanter, unbeaufsichtigter Rollback ein verbreitetes Sicherheitsmuster (keine PF-Funktion), um Änderungen auf einem entfernten FreeBSD-Host zu testen.
-
ZFS Boot Environments mit bectl: ein Rollback-Pfad für FreeBSD- und Paket-Upgrades
bectl klont das ZFS-Root-Dataset in Sekunden zu einer Boot Environment. Wer vor einem freebsd-update oder einem grossen pkg-Upgrade eine anlegt, erhält einen sofortigen, im Loader-Menü wählbaren Weg zurück zu einem funktionierenden System – unabhängig von und zusätzlich zu den eigenen Patch-, Install- und Rollback-Mechanismen von freebsd-update.
Maschinenlesbar: JSON