ROOT@PRODUCTION  ::  MIDDLEWARE / UNIX

I keep middleware alive when everything is trying to break it.Petar Sugarev — Linux / Unix Systems Administrator, enterprise middleware

I operate the layer most engineers never see: enterprise application servers, web servers and reverse proxies under real production load, across multi-region AWS infrastructure. I take that layer end to end — from a bare OS to a running, hardened, documented node, and from a legacy platform to its successor without an outage window anyone remembers.

install
Provisioning from bare OS to a running, hardened node — repeatable and documented, not improvised.
maintain
Patching, certificate lifecycle, tuning, capacity and the kind of uptime nobody has to think about.
migrate
Version jumps and platform moves across every environment, with rollback planned before cutover.
troubleshoot
Root cause, not restarts — thread dumps, TLS handshakes, connector queues, SELinux denials, logs.
> VIEW_LOG> OPEN_UPLINK

// SYS_PROFILE

STATUS: 200 OK
scope
LINUX SYSTEMS · ENTERPRISE MIDDLEWARE
Enterprise middleware estates from development through production, run as one consistent standard rather than per-environment guesswork.
lifecycle
INSTALL · CONFIGURE · UPGRADE · MIGRATE · SUPPORT
Full ownership of the platform layer: builds, upgrades, migrations, patching, certificates and the runbooks that make all of it repeatable.
TROUBLESHOOTING
LOGS FIRST · ROOT CAUSE SECOND
Root-cause troubleshooting across operating system, middleware, Java/JVM, certificates, keystores, SELinux, DNS and network connectivity.
approach
AUTOMATE IT, THEN DOCUMENT IT
Manual once, scripted twice, written down always. If it only works when I run it, it isn't finished.
process
CHANGE-MANAGED BY DEFAULT
Comfortable inside a real client workflow — changes, requests and approvals tracked in ServiceNow, Jira and OpenProject before anything touches production.
on call
YES — AND IT'S USUALLY DNS
Incident work is where I started, so a 3 a.m. page gets a calm, methodical response instead of a panicked restart.

// OPERATIONS_LOG

5 ENTRIES
~/aws-emea/migration
01On-Prem → AWS Middleware Migration
problem
A full middleware estate had to move to AWS with effectively no documentation — no inventory of what ran where, which versions were in play, or how any of it had been built.
solution
Took an active role in the migration across every environment: reverse-engineered the existing setups, mapped dependencies and traffic paths, rebuilt them on AWS, and wrote the documentation that had never existed. Also contributed to the Ansible-based installation so the rebuilt platforms could be provisioned the same way twice.
impact
All environments landed consistent, understood and reproducible — and for the first time the estate could be explained to anyone, not just operated by whoever remembered it.
~/oncall/deploy-vars-vault
02On-Call Deployment Support — Vars & Vault
problem
Deployments run on-call fail for the least interesting reasons: a variable pointing at the wrong environment, a value missing from the inventory, a Vault path or credential that was never updated after a change.
solution
Ran these deployments through on-call rotations and made variable and secret validation the first step, not the postmortem — reading the playbook run back to the actual vars and Vault contents, spotting the mismatch, and correcting it before it propagated further down the environments.
impact
Deployment failures stopped being a mystery at 2 a.m. The class of error that used to consume a whole window now gets caught and named in minutes.
~/hardening/tomcat-apache
03Tomcat & Apache Hardening for the Client
problem
The client's web and application tier had no consistent security posture — every instance a slightly different configuration, and every audit a fresh set of findings.
solution
Hardened Tomcat and Apache against current security guidance rather than whatever the defaults shipped with: TLS protocol and cipher policy, security headers, module and connector minimization, error and version disclosure, file permissions, SELinux contexts and firewalld rules — reviewed as the recommendations move, not set once.
impact
One auditable standard across the client's estate, aligned with up-to-date guidance and able to survive a scan without a remediation scramble.
~/scripts/bash-crontab-cleanup
04Legacy Bash & Crontab Rework
problem
Years of inherited bash scripts and crontab entries held critical routines together — no error handling, no logging, chained commands that silently did half the job, and schedules nobody could explain.
solution
Rewriting them properly: real exit-code handling, guards against duplicate or overlapping runs, logging you can actually read afterwards, and schedules moved to the right mechanism for the job instead of a cron line that happened to work once.
impact
Scheduled work fails loudly instead of quietly, and the scripts can be handed to someone else without a verbal explanation attached.
~/homelab
05Homelab — Where Everything Gets Tried First
problem
Production is the worst possible place to learn something new. I wanted somewhere to break things on purpose.
solution
A self-hosted stack on my own hardware: NAS storage, Docker containers for services, websites published through a reverse proxy with TLS, segmented networking and backups — built, torn down and rebuilt whenever there's a better way to do it.
impact
Every pattern I use at work has been run at home first. The site you're reading is served from it.

// TRAJECTORY

INCIDENTS → PROJECTS
stage 01
Incident Management
Started on the incident queue — triage, diagnosis and resolution under time pressure, on systems I had to learn while they were already broken. That's where the habit of reading logs before touching anything came from.
stage 02
Oracle Patching
Moved quickly onto Oracle patching — scheduled, change-controlled maintenance where the window is fixed, the rollback has to be real, and "it should work" is not an acceptable plan.
stage 03
Change & Request Delivery
Promoted onto full request and change work in OpenProject, Jira and ServiceNow: raising and executing changes, deploying applications with Ansible, managing client variables and secrets in Vault, and troubleshooting everything the pipeline threw back.
stage 04 · current
Project Work
Now fully on project delivery — migrations, new platform builds, hardening baselines and automation, instead of a ticket queue. The operational years are what make the project work land safely.

// CORE_STACK

SYSADMIN → SRE
Ansible / IaCOPERATING
I work with and maintain an existing Ansible automation estate for middleware installs and application deploys — extending roles, fixing them, running them in anger. I didn't author it from zero; I keep it working.
Owning roles end to end, building new ones from scratch
CI/CD · JenkinsOPERATING
Responsible for the client's application deployments out of Jenkins, including the pipeline failures nobody else wanted to open — SSH auth, credentials, environment drift.
GitHub Actions / GitLab CI, pipelines built rather than inherited
Secrets · VaultOPERATING
Client variables and credentials handled through Vault as part of the deployment path — no secrets in repositories, no secrets in playbooks.
Automated rotation and policy-driven access
ObservabilityLEARNING
Log-driven root-causing today — audit logs, deployment failures, bind errors, handshake traces.
Prometheus + Grafana for proactive detection
Security & HardeningACTIVE
CIS-adjacent web server, SELinux and firewalld hardening; TLS negotiation and certificate debugging.
Scored CIS benchmarks, automated compliance checks
Cloud · AWSACTIVE
Running middleware across multi-region AWS EMEA infrastructure, including a full on-prem to cloud migration across all environments.
Deeper into networking, IAM and infrastructure provisioning