Why I'm Writing this, and What to Expect
Over fifteen years of managing enterprise infrastructure, I've accumulated a specific kind of knowledge that rarely shows up in documentation: the workarounds, the edge cases, the "this should work but doesn't on Alpine Linux" moments that cost real hours to figure out. This blog is where those findings live.
The goal isn't to cover every concept from scratch. It's to document the specific, reproducible solutions to problems that were genuinely hard to solve — so the next person spends their time building, not debugging.
I work primarily in environments that span on-premise compute clusters, identity systems, hybrid Microsoft 365 deployments, and containerized workloads. The problems I run into are rarely simple, and the solutions I find rarely fit neatly into a single vendor's documentation. These posts are the connective tissue.
Each post will walk through a real problem — something I actually encountered — with the full configuration, the reasoning behind each decision, and the troubleshooting that got it working. No filler, no fluff. Just what the problem was, why the standard approach didn't cut it, and what did.
What to expect posts on:
The first post is already up. It covers building a containerized Postfix SMTP relay that authenticates to Microsoft 365 using a Let's Encrypt TLS certificate — no username/password, no IP allowlisting, just a clean Docker Compose setup that sidesteps every DNS and chroot pitfall that makes containerizing Postfix on Ubuntu a headache.
If you're a sysadmin, infrastructure engineer, or anyone who's spent an afternoon staring at a Postfix log wondering why DNS resolution works everywhere except inside a container — you're in the right place.
Jevell Acebedo