FreeIPA auf FreeBSD - Call for Testing - Jochen’s Bits & Bytes

🇩🇪 Dieser Artikel ist auf Deutsch. An English version will follow as a separate post.

Ich fange mal ehrlich an: FreeIPA ist der größte Brocken, den ich mir bisher vorgenommen habe. BunkerWeb war ein Reverse Proxy, code-server ein (zugegeben widerspenstiges) Node.js-Projekt. FreeIPA dagegen ist kein einzelnes Programm, sondern ein ganzer Stapel aus Verzeichnisdienst, Kerberos-KDC, einer eigenen Zertifizierungsstelle und einer Web-Oberfläche, die alle zusammenspielen müssen. Auf Linux ist das eine eingespielte Maschine. Auf FreeBSD gab es sie schlicht nicht.

Seit Monaten sitze ich abends daran. Der Server-Aufbau läuft inzwischen komplett durch, ein FreeBSD-Client kann sich in die Domäne einschreiben, und die Kiste übersteht sogar einen Reboot. Genau deshalb schreibe ich diesen Artikel: Ich brauche jetzt Leute, die das Ganze auf ihren Systemen testen. Aber der Reihe nach.

1. Warum FreeIPA auf FreeBSD?

Die Frage, mit der bei mir eigentlich alles anfängt, war wieder dieselbe wie bei BunkerWeb: Was nehme ich auf FreeBSD, wenn ich zentrale Identitäten brauche? Also einen Ort, an dem Benutzer, Gruppen, Hosts, Passwortrichtlinien und Zertifikate zusammenlaufen, also das, was in der Windows-Welt Active Directory macht.

Die ehrliche Antwort: nicht viel. Man kann sich aus OpenLDAP, einem Kerberos-KDC und ein paar Skripten selbst etwas bauen, aber das ist Handarbeit, fehleranfällig und niemand pflegt es außer einem selbst. FreeIPA ist genau diese Kombination, nur fertig integriert, mit Web-UI, CLI, sauberer Delegation und einer Zertifizierungsstelle, die Host- und Service-Zertifikate automatisch ausstellt und erneuert. Auf Linux ist FreeIPA seit Jahren die Antwort. Auf FreeBSD wollte ich sie auch haben.

2. Was da eigentlich alles portiert werden musste

FreeIPA ist nach außen ein Produkt, nach innen ein halbes Dutzend Projekte. Damit freeipa-server überhaupt baut und läuft, hängt ein ganzer Unterbau daran, den ich Stück für Stück nach FreeBSD bringen musste:

Baustein	Rolle
389 Directory Server	Der LDAP-Verzeichnisdienst, das Herz, in dem alles steht
MIT Kerberos (KDC)	Authentifizierung, Tickets, Single Sign-On
Dogtag PKI	Die Zertifizierungsstelle (CA), Java/Tomcat, ein Monster für sich
Apache + mod_wsgi	Web-UI und API, das Framework läuft in Python
SSSD, slapi-nis, oddjob …	Client-seitige Auflösung, Schema-Kompatibilität, Helferdienste

Das Kernstück des Ganzen ist eine Frage, die sich durch die komplette Portierung zieht: Kerberos. FreeBSD bringt im Basissystem ein eigenes Kerberos mit, in den Ports gibt es MIT Kerberos (security/krb5). FreeIPA erwartet durchgängig ein Kerberos, und zwar das aus den Ports. Sobald sich an irgendeiner Stelle das Basis-Kerberos hineinmogelt, fliegt einem der Stack um die Ohren. Das war der rote Faden für die meisten der harten Bugs.

3. Die Nächte, die man nicht auf der Verpackung sieht

Ein Port ist am Ende ein pkg install. Was man dem nicht ansieht, sind die Abende davor. Drei Geschichten, stellvertretend für viele:

Der Verzeichnisdienst, der beim GSSAPI-Bind einfach abstürzt. Der Installer lief bis fast zum Schluss und dann fiel ns-slapd mit Signal 6 um, reproduzierbar und ohne Fehlermeldung. Die Spur führte zum SASL-GSSAPI-Plugin, das gegen das Basis-Kerberos gelinkt war, während der Rest des Prozesses das Ports-Kerberos benutzte. Zwei Kerberos-Bibliotheken in einem Prozess, und der Kernel macht daraus ein abort(). Lösung: security/cyrus-sasl2-gssapi muss mit der Option GSSAPI_MIT gebaut werden. Klingt nach einem Häkchen, war aber tagelanges Ausschlussverfahren.

Die JSON-Antwort, die bei 64 KB abgeschnitten ankam. Der allerletzte Schritt der Installation lädt das LDAP-Schema über HTTP, und die Antwort kam abgeschnitten an, immer irgendwo um die 64 Kilobyte. Ich habe das mit einem winzigen, isolierten mod_wsgi-Testprogramm eingekreist, bis der Übeltäter feststand: FreeIPA setzt einen Socket-Timeout auf INT_MAX, um Timeouts praktisch abzuschalten. Auf FreeBSD läuft dieser Wert, mal 1000 gerechnet, in einem 32-Bit-Kontext über und wird zu einem winzigen oder negativen Timeout. Der Daemon brach nach dem ersten Puffer ab. Ein einziger Zahlenwert, ein halber Abend Detektivarbeit.

Der Server, der sich nach jedem Reboot selbst abschaltete. Mein Favorit. Frisch installiert lief alles. Nach einem Neustart fuhr der Verzeichnisdienst hoch und rund zwanzig Sekunden später sauber wieder herunter. Kein Absturz, kein Fehler im Log, nichts. Nur beim Boot, nie beim manuellen Start. Ich habe über etwa vierzehn Reboots hinweg mit dtrace jedes Signal an den Prozess mitgeschnitten, bis es dastand: FreeBSDs rc-System räumt am Ende einer Boot-Subshell die Prozessgruppe auf und schickt ihr ein SIGHUP. Der 389 Directory Server interpretiert SIGHUP als „bitte herunterfahren“. Die Lösung ist eine einzige Zeile im rc-Skript: der Dienst wird jetzt über daemon(8) in einer eigenen Session gestartet, außerhalb der Reichweite des Boot-SIGHUP. Aber bis man weiß, dass es genau das ist, vergehen viele Abende.

Ich erzähle das nicht, um zu jammern, sondern weil genau solche Kleinigkeiten der Unterschied zwischen „läuft auf Linux“ und „läuft auf FreeBSD“ sind. Und weil sie zeigen, warum ich jetzt Tester brauche: Manche dieser Effekte tauchen nur unter ganz bestimmten Bedingungen auf.

4. Wo ich heute stehe

Der Stand, ganz nüchtern: Auf FreeBSD 15.1 läuft ipa-server-install komplett durch. Nach der Installation stehen alle Dienste, also Verzeichnisdienst, KDC, kadmin, Dogtag-CA, httpd, der KDC-Proxy und der OTP-Daemon:

Directory Service: RUNNING
krb5kdc Service:    RUNNING
kadmin Service:     RUNNING
httpd Service:      RUNNING
ipa-custodia:       RUNNING
pki-tomcatd:        RUNNING   (die CA)
ipa-otpd:           RUNNING

ipa ping antwortet mit „IPA server version 4.13.1“, die Weboberfläche kommt sauber hoch, und ein FreeBSD-Client kann sich mit ipa-client-install einschreiben und danach IPA-Benutzer über SSSD auflösen: id admin und getent passwd admin liefern das Erwartete. Und das Wichtigste nach der Reboot-Odyssee: Die Maschine kommt nach einem Neustart von allein wieder vollständig hoch.

Der grobe Aufbau sieht so aus:

        Browser / ipa-CLI / Client
                   │  HTTPS (Kerberos/SPNEGO)
                   ▼
        Apache + mod_wsgi  ───►  Dogtag PKI (CA, Java/Tomcat)
                   │
                   ▼
        389 Directory Server (LDAP)  ◄──►  MIT Kerberos KDC

5. Der eigentliche Grund für diesen Artikel: Bitte testet mit

Ich rufe hiermit offiziell zum Call For Testing auf. Der Port ist noch nicht im offiziellen FreeBSD-Ports-Tree. Er soll es werden, aber vorher will ich, dass möglichst viele Augen und möglichst viele unterschiedliche Setups draufschauen.

Ich habe dafür beide Ports (Server und Client) samt Dokumentation auf GitHub gelegt:

👉 github.com/joneum/FreeBSD-freeipa-server

Was ich mir wünsche: Baut es, installiert es, richtet einen Server ein, schreibt einen Client ein, rebootet die Kiste, dreht an allen Schrauben, die ihr findet, und meldet mir, was funktioniert und was nicht. Gerade die unbequemen Pfade sind interessant: externe CA, eigene Realm-/Domain-Kombinationen, das komplette ipa-Kommandoset, Replikas, Deinstallation. Fehlerberichte bitte als GitHub-Issue.

Ein paar ehrliche Worte vorab, damit niemand in eine Falle läuft:

Nichts für den Produktivbetrieb. Das ist ausdrücklich Work-in-Progress zum Testen. Nehmt eine Wegwerf-VM, nicht euren Firmen-Login-Server.
Ein Stolperstein vorweg: security/cyrus-sasl2-gssapi muss mit GSSAPI_MIT gebaut sein (siehe oben), sonst scheitert die Installation ganz am Ende. Steht alles in der README.
Der Unterbau ist bereits im Tree. Alle Abhängigkeiten (389-ds-base mit meinen Änderungen, Dogtag, slapi-nis und die anderen) sind inzwischen committet. Aus dem Repo brauchst du nur noch die beiden freeipa-Ports selbst.
Der Client (net/freeipa-client) braucht Fixes, die noch als Pull Request offen sind (PR 297487). Die gepatchte Fassung liegt im selben Repo bei.

6. So kommt ihr rein

Weil das Repo die Ports-Baum-Struktur spiegelt, ist der Einstieg kurz:

git clone https://github.com/joneum/FreeBSD-freeipa-server.git /tmp/ipa-cft
cp -R /tmp/ipa-cft/net/freeipa-server \
      /tmp/ipa-cft/net/freeipa-client /usr/ports/net/

Danach die beiden Dinge nachtragen, die außerhalb der Port-Verzeichnisse liegen: den SUBDIR-Eintrag in net/Makefile und die Service-Benutzer in den tree-weiten UIDs/GIDs-Dateien (die passenden Zeilen liegen im Repo unter tree-integration/). Dann bauen, am besten mit poudriere und der oben genannten Kerberos-Option:

# in der make.conf des Build-Jails:
security_cyrus-sasl2-gssapi_SET=GSSAPI_MIT
security_cyrus-sasl2-gssapi_UNSET=GSSAPI_BASE

poudriere testport -j <jail> -p <tree> net/freeipa-server

Den Rest (ipa-server-install, die nötigen rc.conf-Zeilen freeipa_server_enable, dbus_enable, gssproxy_enable, und der Weg in die Weboberfläche) habe ich in der ausführlichen README im Port dokumentiert. Genau die Doku freut sich übrigens auch über Korrekturen.

Fazit

FreeIPA auf FreeBSD ist noch nicht am Ziel, aber es ist erstaunlich weit: Der Server steht, der Client schreibt sich ein, der Reboot hält. Was jetzt zählt, ist Praxis auf fremden Systemen, und genau dafür ist ein Call For Testing da. Wenn ihr FreeBSD im Einsatz habt und euch eine echte Identity-Management-Lösung darauf schon immer gefehlt hat: Jetzt ist der Moment, mitzumachen.

In einem Folgeartikel nehme ich mir dann einen einzelnen dieser harten Bugs im Detail vor, vermutlich die Reboot-Geschichte, die ist es wert.

Und ganz persönlich zum Schluss: Ich mache das alles unentgeltlich, neben einem ganz normalen Job und einer Familie. Auch die Hardware, auf der ich in VMs teste, bezahle ich komplett selbst bei Hetzner. Wenn dir meine Arbeit gefällt, freue ich mich über eine Spende. Ganz besonders freue ich mich, wenn Firmen etwas geben, die FreeBSD einsetzen und durch solche Ports einen echten Mehrwert haben, weil sie damit bares Geld sparen. Die Links zu PayPal, Patreon und GitHub Sponsors findest du in der Seitenleiste. Jeder Beitrag hilft.

FreeIPA auf FreeBSD – Call for Testing