Dev Log #1: First Successful Bareos Connection
Two weeks in. The first commit was January 17th — a blank Qt6 window with a dream. Today, Onesimus successfully authenticated against a live Bareos Director for the first time.
The Protocol Challenge
Bareos uses a custom protocol over TCP — not REST, not gRPC, not anything with a nice client library. The bconsole protocol involves a CRAM-MD5 handshake, custom packet framing, and a state machine that would make a network engineer raise an eyebrow.
We had to implement:
- CRAM-MD5 authentication — the challenge-response mechanism Bareos uses for PSK connections
- Packet parsing — Bareos frames messages with 4-byte length headers, with special semantics for signals
- TLS negotiation — upgrading the plaintext connection to TLS-PSK after the initial handshake
The CRAM-MD5 implementation alone took three days of debugging. The Bareos source code was the documentation.
Why Not Use the Bareos REST API?
Bareos offers a REST API through bareos-webui. But it requires a running web server, adds a dependency, and doesn’t expose everything bconsole can do. Direct bconsole protocol means:
- No extra infrastructure — connect directly to the Director
- Full command access — anything bconsole can do, Onesimus can do
- Works behind firewalls — no web server port needed
What’s Next
Now that authentication works, we can send commands and parse responses. Jobs, clients, storage — the data is flowing. Time to build the UI that makes it useful.