Dev Log #1: Erste erfolgreiche Bareos-Verbindung
Zwei Wochen drin. Der erste Commit war am 17. Januar — ein leeres Qt6-Fenster mit einer Vision. Heute hat sich Onesimus zum ersten Mal erfolgreich an einem Live Bareos Director authentifiziert.
Die Protokoll-Herausforderung
Bareos verwendet ein eigenes Protokoll über TCP — kein REST, kein gRPC, nichts mit einer fertigen Client-Library. Das bconsole-Protokoll beinhaltet einen CRAM-MD5-Handshake, eigenes Packet-Framing und eine State Machine, die jeden Netzwerker ins Grübeln bringt.
Wir mussten implementieren:
- CRAM-MD5-Authentifizierung — der Challenge-Response-Mechanismus, den Bareos für PSK-Verbindungen nutzt
- Paket-Parsing — Bareos rahmt Nachrichten mit 4-Byte-Längenheadern, mit spezieller Semantik für Signale
- TLS-Aushandlung — Upgrade der Klartextverbindung auf TLS-PSK nach dem initialen Handshake
Allein die CRAM-MD5-Implementierung hat drei Tage Debugging gekostet. Der Bareos-Quellcode war die Dokumentation.
Warum nicht die Bareos REST API?
Bareos bietet eine REST API über bareos-webui. Aber die braucht einen laufenden Webserver, fügt eine Abhängigkeit hinzu und stellt nicht alles bereit, was bconsole kann. Direktes bconsole-Protokoll bedeutet:
- Keine Extra-Infrastruktur — direkte Verbindung zum Director
- Voller Befehlszugang — alles, was bconsole kann, kann Onesimus auch
- Funktioniert hinter Firewalls — kein Webserver-Port nötig
Was kommt als Nächstes
Jetzt, wo die Authentifizierung funktioniert, können wir Befehle senden und Antworten parsen. Jobs, Clients, Storage — die Daten fließen. Zeit, die UI zu bauen, die das Ganze nützlich macht.