LNX-01 · EXPERIENCE
I keep production Linux and Unix fleets stable, patched, and secure.
I administer RHEL, CentOS, and Debian systems that have to stay up. That means clean provisioning, real hardening, patch cycles that don't break things, and monitoring that catches a problem before users do. When something breaks at 2 a.m., I leave behind documented procedures any on-call engineer can follow.
01 · What I do
The actual work
- Provision RHEL, CentOS, and Debian hosts with consistent, repeatable builds
- Harden systems with SELinux, SSH lockdown, and STIG-aligned baselines
- Stand up monitoring and alerting so failures surface early, not after users complain
- Manage patch cycles with staged testing and a clear rollback path
- Write systemd units and Bash scripts so routine work runs hands-off
- Build on-call procedures anyone on the team can follow
- Scan configurations against published baselines with SCAP and fix the gaps
02 · What you get
What you are left with
- A fleet that boots clean, patches on schedule, and survives reboots
- Hardening you can prove against a published baseline, not just claim
- Monitoring and alerts that catch problems while they are still small
- Written procedures so on-call doesn't live in one person's head
- A documented change history you can hand to an auditor
03 · Tools and knowledge
What I work with here
04 · How I approach it
Planned, scoped, and owned
Every engagement starts with a 30-minute scoping call and a same-day written fit assessment, so we both know whether I'm the right hands for the work. Before I touch anything in production, I write a documented change plan with a rollback, and we agree on the gates that prove the change worked. I make the change inside a defined window, validate it against those gates, and keep ownership of the rollback until the system is clearly stable. Nothing gets done from memory, because the procedure is written down and anyone can repeat it.
05 · Questions
Good questions, straight answers
Can you work across RHEL, CentOS, and Debian, or just one?
All three. Package managers and defaults differ, but the discipline is the same: clean builds, hardened baselines, tested patches, and documented changes.
Will my team be able to operate the systems after you leave?
Yes. I write procedures plain enough that an on-call engineer who never built the system can follow them. The goal is a fleet that doesn't depend on me.
How do you patch production without taking it down?
Staged testing first, a defined maintenance window, validation gates that confirm the patch worked, and a rollback I own until the system is clearly stable.
06 · Related experience
Adjacent work I do
Need this handled?
Tell me what you are trying to move and where it is stuck. A few sentences is plenty to start, and it goes straight to my inbox.