Blog nach 10 Jahren auf Ubuntu 16.04 auf FreeBSD migriert

(crocidb.com)

1 Punkte von GN⁺ 3 시간 전 | 1 Kommentare | Auf WhatsApp teilen

Das auf Ubuntu 16.04 LTS basierende DigitalOcean-VPS war zwar vom Support-Ende und Sicherheitsrisiken betroffen, erreichte bis zur Abschaltung aber eine Uptime von 1491 Tagen
Der neue Server wurde auf einen deutschen Hetzner VPS mit FreeBSD 14.3 umgezogen und bietet für weniger als 6 Euro im Monat stärkere Spezifikationen als der bisherige 13-Dollar-Server
Mit Jails und Bastille wurde für jede Site eine isolierte Umgebung geschaffen; ein Caddy-Jail übernimmt SSL und Reverse Proxy und leitet an die jeweiligen nginx-Jails weiter
Im Lasttest erreichte der neue FreeBSD-Server nach Anpassung von kern.ipc.somaxconn für 10.000 gleichzeitige Verbindungen einen 3- bis 11-fach höheren Durchsatz
Der Umstieg erforderte das Erlernen von Netzwerktechnik und FreeBSD-Konfiguration, war dank zentralisierter Einstellungen und guter Dokumentation aber leichter als erwartet

Hintergrund der Migration

Der bisherige Blog lief mehr als 10 Jahre auf einem DigitalOcean VPS mit Ubuntu 16.04 LTS im Rechenzentrum New York
- Ubuntu 16.04 LTS war bereits seit mindestens 5 Jahren aus dem Support gefallen, und für die apt-Paketquellen gab es keine Updates mehr
- Ein veraltetes System ist aus Sicherheitssicht nachteilig; ein früherer separater WordPress-Blog auf einem alten VPS war bereits Ziel eines Angriffs geworden, bei dem Casino- und Glücksspiel-Links eingeschleust wurden
Neben dem Blog lieferte der bisherige Server noch einige weitere Sites aus, die aber größtenteils statische Websites waren
- Selbst der populärste Blog kam normalerweise nur auf einige Tausend Pageviews pro Monat; abgesehen von einzelnen viralen Beiträgen auf Hacker News war der Traffic gering
- Der Server lieferte statische Dateien mit nginx/1.10.3 aus, und die Site-spezifischen Konfigurationen lagen unter /etc/nginx/sites-available
- Der Blog wurde mit Hugo erzeugt; der bisherige Deployment-Ablauf war: lokal schreiben → ins Repository committen und pushen → per SSH auf den Server → Repository pullen → hugo ausführen
Das bisherige VPS war anfangs auch für Tests und Programmierung genutzt worden, weshalb dort viel veraltete Software verblieb
- Trotzdem funktionierte es zuverlässig und hatte bei der Abschaltung eine Uptime von 1491 Tagen, also etwa 4 Jahre ohne Reboot
Der neue Server wurde auf einen Hetzner VPS in Deutschland umgezogen und bot höhere Spezifikationen bei weniger als halben monatlichen Kosten
- Der bisherige DigitalOcean-Server hatte 2 GB RAM, 1 vCPU, 50 GB Speicher, 2 TB Traffic pro Monat und kostete 13 US-Dollar monatlich
- Schon Hetzners günstigster Server bot doppelt so viel Speicher und CPU-Leistung wie der alte, etwas weniger Disk-Speicher, aber das Zehnfache an Traffic
- Die letztlich gewählte Hetzner-Konfiguration war stärker und kostete weniger als 6 Euro pro Monat

Warum FreeBSD gewählt wurde

FreeBSD wurde gewählt, um ein neues System einmal unter realen Betriebsbedingungen auszuprobieren
- Als Vorteile galten das integrierte Design, Stabilität, Sicherheit und Jails
Jails sind eine seit mehr als 25 Jahren in FreeBSD enthaltene Virtualisierungs- und Container-Technik
- Darin lassen sich wie in einer Sandbox „Mini-Systeme“ betreiben, die keinen Zugriff auf das Host-System haben
- Container-Lösungen wie Docker eignen sich stärker zum Verpacken von Programmen und haben eher einen flüchtigen, unveränderlichen Charakter, während Jails eher wie Subsysteme oder Mini-VMs behandelt werden, die denselben Kernel teilen
Auch ZFS war als Dateisystem für einen Server attraktiv
- Es bietet Datenintegrität und Snapshot-Funktionen und hat Ähnlichkeiten mit Btrfs auf Linux
- ZFS galt als deutlich reifer als Btrfs, und mit häufigen Snapshots lässt sich die Abhängigkeit von kostenpflichtigen Snapshot- oder Backup-Systemen des VPS-Anbieters verringern
Die Zielarchitektur sah für jede Site ein eigenes Jail vor, in dem sich die jeweils nötigen Build-Tools und nginx befinden
- Ein Jail für den Haupt-Webserver sollte als nach außen erreichbarer Reverse Proxy dienen
- Bei einer Kompromittierung eines bestimmten Jails sollte dieses gelöscht und neu aufgebaut werden können

FreeBSD-Installation und Einführung von Bastille

Im VM-Erstellungsbildschirm von Hetzner waren nur begrenzt Standard-OS-Images sichtbar, weshalb BSD zunächst nicht direkt auftauchte
- Es wurde das offizielle Hetzner-Installationsvideo auf dem FreeBSD-YouTube-Kanal herangezogen
- Hetzner stellt zwar FreeBSD-ISO-Images bereit, diese mussten nach dem Anlegen der VM aber im Reiter ISO Images der Konsole gemountet werden
- Für die Installation wurde das ISO von FreeBSD 14.3 verwendet, und das System wurde entlang des Ablaufs im offiziellen Video eingerichtet
Bastille wurde gewählt, um die Verwaltung von Jails zu vereinfachen
- Mehrere Schritte, die bei einer manuellen Jail-Erstellung nötig wären, lassen sich mit dem Befehl bastille erledigen
- Beispielbefehle sind bastille list, bastille create und bastille console
- Installation und Aktivierung erfolgten nach der Bastille-Startdokumentation

pkg install bastille
sysrc bastille_enable="YES"

Netzwerk- und Reverse-Proxy-Struktur

Der gesamte Stack ist so aufgebaut, dass ein einzelnes Caddy-Jail alle Domains und SSL-Zertifikate verarbeitet und den Traffic per Reverse Proxy an die Site-spezifischen Jails weiterleitet
- Jedes Site-Jail enthält nur die Werkzeuge, die zum Bauen und Ausliefern der jeweiligen Site nötig sind
- Die Struktur lässt sich mit mehreren virtuellen Maschinen innerhalb desselben Netzwerks vergleichen
Die interne virtuelle Netzwerkschnittstelle wurde als bastille0 angelegt

sudo sysrc cloned_interfaces+="lo1"
sudo sysrc ifconfig_lo1_name="bastille0"
sudo service netif cloneup
sudo sysrc ifconfig_bastille0="inet 10.0.0.1 netmask 255.255.255.0"

Dazu wurde eine Loopback-Schnittstelle geklont, bastille0 genannt und dem Netz 10.0.0.1/24 zugewiesen
Die Jails laufen auf dieser Netzwerkschnittstelle
Externe HTTP- und HTTPS-Anfragen werden per PF(Packet Filter)-Regeln an das Caddy-Jail weitergeleitet
- In /etc/pf.conf wurden die externe Schnittstelle vtnet0, die interne Schnittstelle bastille0 und tailscale1 definiert
- Traffic auf den Ports 80 und 443 wird auf 10.0.0.5, den künftigen Caddy-Server, umgeleitet

ext_if = "vtnet0"
int_if = "bastille0"
vpn_if = "tailscale1"
set skip on $int_if
set skip on $vpn_if
nat on $ext_if from 10.0.0.0/24 to any -> ($ext_if)
rdr pass on $ext_if proto tcp from any to any port {80, 443} -> 10.0.0.5
block all
pass out quick on $ext_if keep state

PF und Gateway wurden mit den folgenden Befehlen aktiviert

sysrc pf_enable="YES"
service pf start
sysrc gateway_enable="YES"

Konfiguration von Caddy und Site-spezifischen Jails

Auf dem bisherigen Server wurde lange nginx verwendet, in der neuen Konfiguration fiel die Wahl aber auf Caddy, um die Verwaltung von SSL-Zertifikaten zu automatisieren
- In der früheren nginx-Umgebung mussten Zertifikate regelmäßig mit certbot erneuert werden, was mehrfach versäumt wurde
Bevor das Caddy-Jail erstellt wurde, wurde die FreeBSD-Release für Bastille gebootstrapt

bastille bootstrap 14.3-RELEASE

Das Caddy-Jail wurde mit der IP 10.0.0.5 erstellt

bastille create caddy 14.3-RELEASE 10.0.0.5 bastille0
bastille start caddy

Der Jail-Name ist caddy, die Release 14.3-RELEASE, die Schnittstelle bastille0
Mit bastille list lässt sich der Laufstatus prüfen, mit bastille console caddy gelangt man in eine Shell innerhalb des Jails
Die Installation von Caddy und das Aktivieren des Dienstes erfolgten innerhalb des Jails

pkg install caddy
sysrc caddy_enable="YES"
service caddy start

Die Caddy-Konfigurationsdatei liegt im Jail unter /usr/local/etc/caddy/Caddyfile
- Wenn die Konfiguration vom Host aus verwaltet werden soll, kann ein Host-Verzeichnis in das Jail gemountet werden
- Im Beispiel wurde mit nullfs und der schreibgeschützten Option ro gemountet, damit Caddy die Konfiguration nicht verändern kann

bastille mount caddy /usr/local/etc/my-caddy-config /usr/local/etc/caddy nullfs ro 0 0

Deployment von Sites und Blog

Das erste Ziel für das Deployment war es.cro.to; das Site-Repository wird im GitHub-Repository verwaltet
- Das Repository liegt auf dem Host unter /usr/local/www/escroto, und in das Site-Jail wird dieses Verzeichnis schreibgeschützt eingehängt
- Alle Sites werden gesammelt unter /usr/local/www auf dem Host abgelegt
Das Jail escroto wurde mit dem nginx-Bastille-Template erstellt

bastille bootstrap https://github.com/bastillebsd/templates
bastille create escroto 14.3-RELEASE 10.0.0.11 bastille0
bastille template escroto www/nginx

Die IP wurde auf 10.0.0.11 gesetzt
Die Standardseite von nginx wird nach FreeBSD-Konvention unter /usr/local/www/nginx ausgeliefert
Das Site-Verzeichnis des Hosts wurde schreibgeschützt in das Jail gemountet

bastille mount escroto /usr/local/www/escroto /usr/local/www/escroto nullfs ro 0 0

Damit das .git-Verzeichnis des Repositorys nicht über das Web ausgeliefert wird, kam ein Deployment-Skript zum Einsatz

rm -fr /usr/local/www/nginx/*
cp -R /usr/local/www/escroto/* /usr/local/www/nginx/
rm -fr /usr/local/www/nginx/.git

Eine neue Version wird ausgerollt, indem auf dem Host das Repository aktualisiert und dann im Jail das Deployment-Skript ausgeführt wird

cd /usr/local/www/escroto
git pull
bastille cmd escroto /root/deploy.sh

Die Caddy-Konfiguration leitet cro.to dauerhaft auf es.cro.to um und proxyt es.cro.to auf 10.0.0.11

cro.to {
    redir https://es.cro.to{uri} permanent
}
es.cro.to {
    reverse_proxy 10.0.0.11
}

Der Blog verwendet Hugo und wird im GitHub-Repository verwaltet
- Das Repository wurde auf den Host nach /usr/local/www/blog geklont
- Das Jail blog wurde ähnlich wie escroto erstellt und erhielt die IP 10.0.0.12

bastille create blog 14.3-RELEASE 10.0.0.12 bastille0
bastille template blog www/nginx
bastille mount blog /usr/local/www/blog /usr/local/www/blog nullfs ro 0 0

Hugo wurde innerhalb des Jails blog installiert

bastille pkg blog update
bastille pkg blog install gohugo

Das Deployment-Skript des Blogs leert den nginx-Webroot und erzeugt die Hugo-Ausgabe in /usr/local/www/nginx

rm -fr /usr/local/www/nginx/*
cd /usr/local/www/blog
hugo -d /usr/local/www/nginx

Vor dem Umzug des DNS wurde zum Testen statt der bisherigen Domain crocidb.cro.to auf den neuen Blog-Server gezeigt

crocidb.cro.to {
    reverse_proxy 10.0.0.12
}

Benchmarks und Lasttests

Vor dem Umstellen der DNS-Einträge wurde die Lastfähigkeit des bisherigen Servers crocidb.com mit der des neuen Servers crocidb.cro.to verglichen
- Die Besucher des Blogs kommen hauptsächlich aus Nordamerika, danach aus Europa und Südamerika; dadurch könnte der neue Server in Deutschland für einige Nutzer etwas höhere Latenzen haben
- Entscheidend war, wie schnell statische Sites ausgeliefert werden und wie gut hohe Last abgefangen werden kann
Es kamen auch kostenlose Online-Tools wie GTMetrix, Pingdom und WebPageTest zum Einsatz, doch der Unterschied zwischen beiden Servern lag meist nur bei der Latenz
Für HTTP-Lasttests wurden wrk und hey verwendet
- Beide Tools erzeugen große Mengen gleichzeitiger Requests und sammeln Daten zu Request-Latenz, Fehlerantworten, Durchsatz pro Sekunde und mehr
Als wrk von einem anderen VPS bei Hetzner ausgeführt wurde, lag der neue Server deutlich vorne

wrk -t4 -c100 -d30s --latency https://crocidb.com/

Die Optionen bedeuteten 4 Threads, 100 gleichzeitige Verbindungen und 30 Sekunden Laufzeit
Der alte Server erreichte eine durchschnittliche Latenz von 89.63ms, 833.41 Requests pro Sekunde und 8.29MB/s Durchsatz
Der neue Server erreichte eine durchschnittliche Latenz von 6.75ms, 12260.10 Requests pro Sekunde und 130.80MB/s Durchsatz
Da die Testmaschine im selben Rechenzentrum wie der neue Server stand, war der Vergleich nicht vollständig fair
Es wurde auch versucht, wrk über Proton VPN aus mehreren Regionen laufen zu lassen, doch die Ergebnisse fielen schwächer aus als erwartet
- Für den alten Server wurden im Mittel etwa 300 Requests pro Sekunde gemessen, für den neuen etwa 800
- Schließlich wurde statt eines Consumer-VPNs der Ansatz gewählt, echte VPS in mehreren Regionen zu erstellen

Regionale Tests auf Basis von Vultr-VPS

Um eine andere Infrastruktur als die von DigitalOcean und Hetzner zu nutzen, wurde Vultr gewählt
- Wegen des manuellen Aufwands wurden die Regionen auf London, São Paulo, Silicon Valley und Tokyo beschränkt
- In jeder Region wurde eine günstige Fedora-VM erstellt und die Tests dort ausgeführt
Als finales Testwerkzeug wurde hey als geeigneter eingeschätzt

./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.com/ > crocidb.com.log
./hey_linux_amd64 -n 1000000 -c 10000 -t 10 -z 5m -h2 https://crocidb.cro.to/ > crocidb.cro.to.log

Die Konfiguration war: insgesamt 1,000,000 Requests, 10,000 gleichzeitige Requests, Timeout 10 Sekunden, Gesamtlaufzeit 5 Minuten und HTTP/2 aktiviert
Das war eine Last, die weit über realistischem Blog-Traffic lag
Beim ersten Durchlauf hielt der neue FreeBSD-Server 10.000 gleichzeitige Verbindungen nicht aus und scheiterte früh
- Mit netstat -Lan wurde die Größe der Socket-Queues geprüft; überall stand 128
- Der Standardwert von kern.ipc.somaxconn war 128 und wurde daher wie folgt erhöht

sysctl kern.ipc.somaxconn=16384

Im Test aus São Paulo lieferten beide Server erhebliche Fehlerzahlen, doch der FreeBSD-Server bewältigte die erwarteten 1,000,000 Requests, während der Ubuntu-Server nicht einmal 20,000 Requests zurückliefern konnte
- Der bisherige Ubuntu-Server schloss nur etwa 7% aller Requests erfolgreich ab
- Der neue FreeBSD-Server erreichte etwa 94%
- In Tokyo war die Erfolgsquote des neuen Servers etwas geringer, wurde aber nicht als ernsthafte Sorge betrachtet
Nach Requests pro Sekunde war der neue Server gegenüber dem alten mindestens 3-mal, maximal 11-mal schneller
- Bei den Latenz-Perzentilen stieg der neue Server bis etwa zum 90%-Punkt linearer an und verhielt sich damit vorhersehbarer
- Selbst unter hoher Last konnte der Inhalt der Blog-Startseite in den meisten Regionen der Welt in unter 3,5 Sekunden empfangen werden
Das Ergebnis aus Tokyo wurde nicht im Detail analysiert
- Die phasenbezogene Analyse von hey deutete darauf hin, dass Traffic nach Japan langsamer sein könnte
- Die DNS-Dial-up- und Lookup-Werte der zweiten Domain wirkten ungewöhnlich niedrig; ein Einfluss des CNAME-Records war möglich
- Auch resp wait und resp read waren auffällig hoch; da nur erfolgreiche Requests gezählt wurden, könnte der alte Server anfangs schnell geantwortet und danach neue Requests faktisch blockiert haben

Endgültiger Umzug und wichtigste Erkenntnisse

Auch wenn die Benchmarks viele Fragen offenließen, waren die Ergebnisse überzeugend genug, um die DNS-Einträge auf den neuen Server umzuschalten
- Dieser Blog wird seither offiziell auf einem FreeBSD-basierten Hetzner-Server betrieben
Das Aufsetzen einer Hosting-Maschine für Websites mit FreeBSD erforderte viele Stunden Experimentieren, Anpassen, Bauen und Scheitern, war aber weniger komplex als erwartet
- Es wäre auch möglich gewesen, einen Webhosting-Dienst zu nutzen, der die Anforderungen erfüllt; als Beispiel wird OpenBSD Amsterdam genannt
- Mit Proxmox hätten auch Container und ein Verwaltungs-Dashboard genutzt werden können
- Als Alternative im FreeBSD-Umfeld wurde außerdem Sylve erwähnt
- Der selbst aufgebaute Weg war zufriedenstellend, weil er viel Lerngewinn brachte
Auch der bisherige Ubuntu-Server war äußerst robust
- Er bewältigte 10 Jahre lang die Last der Sites zuverlässig und lief die letzten 4 Jahre ohne Reboot
- Selbst ohne großen Konfigurationsaufwand arbeitete er stabil
Die FreeBSD-Konfiguration war einfacher als erwartet, und sowohl die zentrale Organisation der Systemeinstellungen als auch die Qualität der Online-Dokumentation überzeugten
Wer eine eigene Hosting-Maschine für einen Blog aufbauen will, braucht Netzwerkkenntnisse, die über das hinausgehen, was ein Game-Entwickler üblicherweise weiß
- Das Lernen eines anderen Systems machte Spaß, und als Nächstes könnten OpenBSD oder NetBSD ausprobiert werden
- Abschließend wird angemerkt, dass der praktische Nutzen der ganzen Arbeit begrenzt ist, weil der Großteil des Blog-Traffics ohnehin von Crawlern für KI-Systeme stammt

1 Kommentare

GN⁺ 3 시간 전

Hacker-News-Kommentare

Mein größter Fehler war die hohe Uptime
arjie.com lief über 10 Jahre lang auf einem Hetzner-VPS, und als Hetzner die zugrunde liegende Maschine abschalten wollte, hatte ich keine Ahnung mehr, was mein Teenager-Ich damals eingerichtet hatte
Backups habe ich, aber die Website ist seit 10 Jahren offline
Heute sorge ich dafür, dass alles migrierbar ist, und ziehe es auch tatsächlich ein paarmal um, um zu prüfen, ob es funktioniert
- Die Aussage „mein größter Fehler war hohe Uptime“ stimmt
  Ich erinnere mich noch an Zeiten, in denen die Uptime einer Maschine wie ein Ehrenabzeichen galt
  Ich bin zwar älter geworden, aber nicht unbedingt klüger, doch heute schaue ich auf die Service-Uptime
  Schon früher gingen DNS-Records wie MX in diese Richtung, und alte Cluster waren ziemlich kryptisch, aber Lehren wie Split Brain wirken bis heute nach, weshalb ich immer noch erklären muss, warum Proxmox-Cluster mit 2 Nodes kaputtgehen und warum ein zusätzlicher Witness empfohlen wird
  Dass VMware die Probleme von 2-Node-HA-Clustern früher mit einem riesigen Workaround zugedeckt hat, war falsch, und falls diese Methode noch existiert, ist sie wahrscheinlich immer noch falsch
  Hohe Uptime bedeutet, dass nicht gepatcht wurde, und Patchen ist bekanntlich etwas, das alle lieben
- Das erinnert mich an den Ise-Schrein in Japan
  Er wird alle 20 Jahre komplett abgebaut und neu errichtet; in Dan Wangs Breakneck, das ich kürzlich gelesen habe, wird erklärt, dass diese Praxis des Wiederaufbaus Wissen bewahrt, das mit der Zeit sonst verloren ginge
  Wang stellt den Ise-Schrein Notre Dame gegenüber und meint, ein Grund dafür, dass der Wiederaufbau des Dachs von Notre Dame recht schwierig ist, könnte verlorenes Wissen sein
  Ich kenne beide Bauwerke nicht gut genug, um zu sagen, ob das ein fairer Vergleich ist, aber das Prinzip gefällt mir
  Im Buch ist das nur eine kleine Metapher, insgesamt ist es aber eine starke Empfehlung
- Hohe Uptime bedeutet in einer VM nicht besonders viel
  Ein Reboot dauert nur ein paar Sekunden, und Upgrades lassen sich ohne Downtime durchführen, indem man einfach den DNS-Eintrag auf eine neue Instanz umstellt
  Bei physischer Hardware, die sich nicht leicht klonen lässt, ist das etwas anderes
- Ich habe angefangen, Konfigurationen in ein großes Ansible-Playbook-Repository zu packen
  Es muss nicht alles vollständig von Ansible verwaltet werden; meistens liegt dort nur die anfängliche Einrichtung, und vieles pflege ich noch per Hand
- Ich schreibe manchmal sogar für persönliche Projekte Architectural Decision Records
  Das wirkt etwas lächerlich, hilft aber überraschend oft
Für private/Hobby-Zwecke betreibe ich meistens die Kombination Caddy davor + Docker Compose
Bei einfachen Websites liefert Caddy die Inhalte direkt aus, und bei „Web-Apps“ ist fast alles containerisiert; Caddy übernimmt dann die TLS-Terminierung und den Reverse Proxy zu den Apps unter Docker
Meist ist die Struktur ~/apps/appname, und in jedem App-Verzeichnis liegen die Docker-Compose-Datei und die eingebundenen Datenverzeichnisse
Nach compose down kann man die Daten per (s)ftp herausziehen, langfristig archivieren oder die Site bzw. den Dienst umziehen
Früher habe ich mehrere VMs auf einem dedizierten Server betrieben, bin dann aber zu separaten VPSen bei OVH gewechselt; wenn man dort Mail betreiben will, sollte man die Local-Zone-VMs meiden, auf denen Mail-Hosting nicht erlaubt ist
Je nach Umgebung kann das unterschiedlich sein
- Bei einem Projekt habe ich angefangen, Traefik zu nutzen, und das war ein gutes Upgrade gegenüber nginx proxy manager
  NPM ist ebenfalls hervorragend, und die Web-GUI ist okay, aber bei Traefik reicht es, im Docker-Compose-File anzugeben, was man haben will
- Mein Setup zu Hause ist ähnlich
  Nur dass Unraid die Container ausführt und einer davon ein nginx-artiges Tool ist, das dafür gedacht ist, die anderen Dienste per Reverse Proxy bereitzustellen
- Ich mache es fast genauso
  Ich überlege nur, auf Debian von etwas in Richtung Flatcar zu wechseln, also container-first und mit unveränderlichem System/OS
  FreeBSD hat interessante technische Vorteile, aber ob man es mag oder nicht: Für viel Open-Source-Software ist Docker der Standard, und ich habe weder die Zeit noch die Motivation, alles in FreeBSD-Jails umzuziehen
Ich habe vor ein paar Wochen dasselbe gemacht
Der Server war seit etwa 2015 nicht mehr aktualisiert worden, und darauf liefen ein Ghost-Blog von damals und node 0.10
Ich bin etwas brachialer vorgegangen und habe nur ein Backup gemacht und dann einen Hermes-Agenten (Gemini 3.1 Pro) darauf losgelassen
Er hat alle nötigen Upgrades und Patches durchgeführt und dann auf die passenden aktuellen Gegenstücke migriert
Danach wurde der Server noch deutlich gehärtet und ungenutzte Dienste wurden entfernt; ohne AI-Unterstützung hätte ich das vermutlich weiter aufgeschoben
- Auch ohne AI ist das Update selbst sehr einfach
  Das eigentliche Problem ist das Risiko, dass etwas kaputtgeht, und genau dabei helfen Backups
Es hat Spaß gemacht, FreeBSD auf einem persönlichen Server zu nutzen
Es hatte etwas Cooles, Klares, Einfaches und wirkte irgendwie „punkig“
Aber ich habe es wegen einiger großer Schmerzpunkte aufgegeben: PM2 hatte auf FreeBSD Bugs und war das Tool, das ich für Prozessmanagement benutzt habe; als Alternative wollte ich Daemons mit rc.d betreiben, aber die Log-Konfiguration war zu schwierig; bei der Firewall musste man zu viel selbst festlegen, wenn man auch Security-Best-Practices wie den Umgang mit ICMP korrekt abbilden wollte, und mir fehlte so etwas wie die Standardvorgaben von UFW
- Solche Standard-Templates sind bei FreeBSD sogar enthalten
  Sie sind nur mit IPFW statt PF umgesetzt
  Schau dir einfach den Schlüssel firewall_type in rc.conf an: https://cgit.freebsd.org/src/tree/libexec/rc/rc.conf?id=8e08...
  Wenn du eine Firewall für eine einzelne Maschine einfach konfigurieren willst, nimm firewall_type=client, oder firewall_type=workstation, wenn du etwas hosten willst
  Im letzteren Fall steuern firewall_myservices und firewall_allowservices, welche Ports geöffnet werden und welche Netze/IPs zugreifen dürfen
  Ein sehr einfaches NAT-Gateway bekommt man mit firewall_type=simple und firewall_simple_(iif|inet|oif|onet)(_ipv6)?, wobei du die Interface-Namen auf ISP-/interner Seite sowie die IPv4-/IPv6-Netzbereiche setzt
  Was die einzelnen Optionen genau tun, ist in /etc/rc.firewall implementiert: https://cgit.freebsd.org/src/tree/libexec/rc/rc.firewall?id=...
- Ich frage mich, ob du PM2 zur Supervision verwendet hast
  Für Logs von rc.d-Daemons gilt der Unix-Weg: für einfache Meldungen logger(1) verwenden oder in Dateien umleiten und die Größe dann mit newsyslog(8) verwalten
  Für Firewalls empfehle ich The Book of PF[0]
  Das PF von FreeBSD unterscheidet sich syntaktisch zwar von pf auf OpenBSD, aber um ein Gefühl dafür zu bekommen, wie Firewalls funktionieren und welche Regeln man schreiben sollte, reicht es völlig aus
  [0]: https://nostarch.com/book-of-pf-4e
- PM2 war auf jedem OS, auf dem ich es benutzt habe, immer fehlerhaft
  Anfangs ist es extrem bequem, aber zugleich eine unangenehme Software, und beim Deploy wurden Umgebungsvariablen aktualisieren nie auch nur ein einziges Mal so ausgeführt, wie es sollte
- Mein Hauptproblem war, dass es Stromausfälle nicht gut verkraftet hat
  Nach einem Stromverlust verlangte es beim Reboot ein manuelles fsck des Dateisystems
Etwas anderes Thema, aber ich frage mich gerade, welche freie Linux-Distribution derzeit den längsten Support-Zeitraum hat
Eine Weile lang habe ich für kleine VMs CentOS 7 verwendet, weil es sehr lange Sicherheitsupdates bekam und das Risiko gering war, dass durch ein Update etwas kaputtgeht
Ein wenig Recherche lässt mich vermuten, dass aktuell Alma/Rocky Linux die beste Wahl ist, mit 10 Jahren Support
Ich frage mich nur, ob das auch gut gepflegt wird
- Auch ich habe über 10 Jahre lang CentOS auf Servern betrieben, in der Hoffnung auf langfristige Stabilität und Seelenfrieden
  Aber über so lange Zeit driftet das Ökosystem stark auseinander, und es wird zunehmend schwieriger, Anwendungen auf dem OS aktuell zu halten und lauffähig zu betreiben
  Infrastrukturpakete wie glibc, die Python/Apache-Kombination oder GCC passen dann nach und nach nicht mehr zu modernen Application-Stacks
  Spätere Versionsupgrades waren ebenfalls schmerzhaft, nicht nur weil ich mich mit seltsamen Paketmischungen selbst in die Ecke manövriert hatte, sondern auch, weil der Upgrade-Pfad selbst immer nur Best Effort war
  Ich glaube, ich habe beim Schritt von 6 auf 7 aufgegeben und irgendwann erkannt, dass ich eigentlich Fedora brauchte
  Mit jährlichen oder halbjährlichen Updates muss man nicht gegen die Distributionspakete kämpfen, die Konfiguration bleibt modern und funktionierend, große Dist-Updates laufen glatt, und die Downtime ist minimal
  Ich habe nicht vor, jemals wieder zu einer „Server-Distribution“ zurückzukehren
- Alma ist inzwischen nicht mehr quellkompatibel zu RHEL, was etwas Spielraum schafft
  So können sie etwa Kernel-Updates für die Behebung von Privilege-Escalation-Schwachstellen schneller veröffentlichen
  Rocky hat darauf mit einem optionalen Security-Repository reagiert, das Exploit-Mitigation bereitstellt, während man darauf wartet, dass es von RHEL herabkommt
  Nach den jüngsten Ereignissen wirken beide ziemlich gut gepflegt
- Ich sehe keinen guten Grund, auf einem privaten Server Rolling-Release-Distributionen nicht zu verwenden
  Alle Dienste laufen in Containern, und das Basis-OS kann so oft automatisch aktualisiert werden, wie nötig
  Ich habe mich für openSUSE MicroOS entschieden und bin ziemlich zuversichtlich, dass mein Server gesund ist, weil er fast täglich Updates und Reboots bekommt
  Durch atomare Updates kann ich, falls etwas kaputtgeht und ich mich gerade nicht darum kümmern will, in Cockpit einfach auf Rollback klicken und es mir später ansehen
- Man wettet im Grunde darauf, dass das, was man hostet, nicht länger lebt als der Upgrade-Zyklus
  Wenn das Upgrade dann doch kommt, wird es wahrscheinlich ziemlich schmerzhaft
  Ich halte es für besser, öfter kleinere Versionssprünge zu machen, statt nach langer Zeit, wenn sich schon alles verändert hat, einen riesigen Sprung zu wagen
- Wenn es komplett kostenlos sein soll oder du viele Maschinen hast, passen Alma und Rocky
  Wenn du dich bei Red Hat registrieren möchtest, gibt es auch RHEL; pro registriertem Account bekommt man für bis zu 10 Maschinen kostenlosen Update-Zugang
  RHEL ist ganz klar die stabilste der großen Distributionen, und Alma und Rocky sind im Wesentlichen Downstream-Klone von RHEL
Ich sitze im selben Boot
Ich habe zwei alte Server, die ich „zu“ lange habe verstauben lassen, und inzwischen habe ich Angst, sie überhaupt noch anzufassen, um Updates zu machen
Angesichts des Theaterdonners, den Linux-Distributionen derzeit rund um Altersverifikation/-nachweise veranstalten, denke ich aber auch darüber nach, ganz abzuwandern
Ich habe auch Artix ausprobiert, aber das ist letzte Woche nach einem Neustart kaputtgegangen; offenbar war beim vorherigen Kernel-Update etwas schiefgelaufen, sodass ich sogar ein Rescue-ISO auspacken musste
Deshalb habe ich die Kiste auf Devuan umgestellt, aber ich enthalte mich noch eines Urteils
Große Beschwerden habe ich nicht, aber sie ist noch in der Einlaufphase
Auf meinem Laptop läuft Arch, aber die Community wirkt wegen der Zensurproblematik ziemlich feindselig, deshalb warte ich nur noch auf ein freies Wochenende, um alles plattzumachen und etwas anderes zu installieren
Ich will keine politischen Dramen in meiner Software
Interessanterweise war das das erste Mal, dass ich einen neuen Laptop gekauft und nie in Windows gebootet, sondern direkt Linux installiert habe, und alles hat „einfach funktioniert“
Es ist traurig, dass ausgerechnet jetzt, wo ich Linux mit Begeisterung nutzen wollte, die großen Player Phasen der Privacy-Erosion akzeptieren wie AI überall, Altersnachweise/-verifikation und standardmäßig aktivierte Telemetrie
Mit so etwas will ich einfach nichts zu tun haben
- Ich habe einmal einen Ubuntu-Server 10 Jahre lang unberührt gelassen und ihn dann in 20 Minuten schmerzfrei aktualisiert
  Dieser Server läuft bis heute auf dem neuesten LTS
  Ich weiß nicht einmal mehr, ob er mit Ubuntu 4 oder 6 angefangen hat, aber es lief durchweg problemlos
  Vielleicht haben die langsamen Upgrades sogar geholfen, den Pain der Early Adopters zu vermeiden
  Heute nutze ich viel häufiger Debian
  In einer Zeit voller Supply-Chain-Angriffe ist Debian Stable wirklich ein Juwel, und auch wenn ich für ein paar Pakete separat modernere Versionen brauche, mag ich diesen altmodischen, nüchternen Engineering-Geist
- Was die Altersverifikation/-nachweise betrifft, scheint man dich da in die Irre geführt zu haben
- Dass es nach dem Neustart wegen eines früheren Kernel-Updates kaputtging, ist größtenteils ein Arch-/Artix-Problem
  Diese beiden folgen dem neuesten Stand besonders schnell und sind nicht immer auf maximale Stabilität ausgerichtet
  Das heißt aber nicht, dass Rolling-Distributionen immer von allem die allerneueste Version liefern müssen
  Ich benutze seit ein paar Monaten Void Linux; es ist zwar rolling, verwendet aber einen LTS-Kernel, erlaubt optional Mainline, und die Maintainer konzentrieren sich stärker auf stabile App-Versionen als auf möglichst schnelle Updates
- Meine Server/VMs laufen meistens mit FreeBSD oder Alpine
  Debian setze ich dort ein, wo es nötig ist, zum Beispiel bei Proxmox, auf VPSen ohne Alpine-Support oder auf arbeitsbezogenen Geräten
  Ich habe auch ein paar Testsysteme mit Chimera, aber bevor es einen Stable-Release gibt, will ich mich nicht stark darauf verlassen
  Mit AerynOS experimentiere ich ebenfalls ein wenig
- Ich wünschte, der Support-Zyklus von FreeBSD wäre länger
  Die Support-Lebensdauer eines Releases liegt unter einem Jahr, und wenn man das Upgrade-Fenster verpasst, werden Upgrades danach schwieriger als bei anderen Distributionen wie Debian Stable
Für Serverzwecke bin ich zu Debian und Ubuntu gewechselt, aber als ich jünger war, Mitte der 2000er, war ich total auf FreeBSD fixiert
Ich habe mehr Zeit mit Konfiguration und Setup verbracht als damit, tatsächlich etwas Nützliches zu tun
Damals war es schwer, dedizierte Server oder VPS mit BSD-Varianten zu finden, und ich glaube, ich bin dann bei so etwas wie Panix.com gelandet
Davor gab es meiner Erinnerung nach auch eine Firma namens 15MinuteServers, wohl früher NAC in New Jersey, die BSD angeboten hat
Jetzt schweife ich nur noch nostalgisch ab
- Heutzutage ist die Installation bei meinen Anbietern ziemlich einfach
  Ich nutze FreeBSD bei Hetzner und OVH, und früher auch bei Vultr
- Bei OVH gibt es ein FreeBSD-Template
  Und die meisten Anbieter von KVM-VMs/VPS erlauben Konsolenzugriff und das Einhängen eigener ISOs, sodass man installieren kann, was man möchte
Dass fastfetch mehr Speicher meldet als tatsächlich verwendet wird, liegt vermutlich am ZFS ARC
Ähnlich wie der Page Cache unter Linux kann er jederzeit freigegeben werden, und verschiedene Tools benennen ihn unterschiedlich: https://www.linuxatemyram.com/
Als mir jemand Docker zum ersten Mal erklärt hat, weiß ich noch, wie ich antwortete: „Ach so, du meinst jails?“
Wie im Artikel erklärt, ist es nicht komplett dasselbe
Auch kqueue war ein großer Gewinn
Vielen Dank an die FreeBSD-Entwickler
Ich habe mein erstes Unternehmen 15 Jahre lang auf FreeBSD betrieben, und die Uptime und Resilienz waren erstaunlich
Ich habe auch einen Ubuntu-16.04-Server, vor dessen Updates ich Angst habe
Die aktuelle Uptime liegt bei 1281 Tagen, und an diesem Punkt fühlt es sich fast unhöflich an, ihn neu zu starten
- Du könntest das Dateisystem per dd auf eine andere Maschine kopieren und es dann in einem Emulator wie qemu booten, um eine Generalprobe zu machen
  Wenn dabei etwas automatisch startet, das Verbindungen nach außen aufbaut, sollte man vorsichtig sein
- Ich verstehe nicht, wovor du Angst hast
  Du hast doch Backups, oder?
  Debian-/Ubuntu-Systeme lassen sich leicht so einrichten, dass sie regelmäßig automatische Updates und Reboots machen, sodass manuell nur noch größere Versionsupgrades anfallen
- Mein ältester Server läuft noch auf 8.04

Blog nach 10 Jahren auf Ubuntu 16.04 auf FreeBSD migriert

Hintergrund der Migration

Warum FreeBSD gewählt wurde

FreeBSD-Installation und Einführung von Bastille

Netzwerk- und Reverse-Proxy-Struktur

Konfiguration von Caddy und Site-spezifischen Jails

Deployment von Sites und Blog

Benchmarks und Lasttests

Regionale Tests auf Basis von Vultr-VPS

Endgültiger Umzug und wichtigste Erkenntnisse

Verwandte Beiträge

1 Kommentare

Hacker-News-Kommentare