Linux server setup
Provisioning, users, SSH, firewalls, web servers, services, and the deployment foundation a site needs to run predictably.
Systems / Linux & bare metal
The website is only the top layer.
Linux server administration, bare-metal infrastructure, troubleshooting, and recovery. This is the practical systems work that keeps a digital product reachable when the interface is no longer the only thing that needs attention.
Environment
- DebianLinux
- UbuntuLinux
- AlmaLinuxLinux
- CentOSLinux
- Red Hat Enterprise LinuxLinux
- RHEL-based systemsLinux
The operating systems are listed because they are part of the working practice — not as a certification claim.
01 / The interest
Web development is my profession. System administration is my passion. The two are not separate hobbies for me; they are different views of the same promise that a digital service will be there when someone needs it.
I enjoy the physicality of bare-metal work: installing an operating system, checking storage and network configuration, bringing services up in the right order, and understanding what the machine is actually doing. I also enjoy the detective work of a failure — reading logs, checking the layers, and finding the difference between a symptom and a cause.
I have experience rescuing and recovering Linux servers. That work has taught me to respect access, backups, and reversibility. The best recovery is the one that does not destroy the evidence needed to prevent the next failure.
No invented uptime figures. No fictional infrastructure clients.
Public case-study detail is limited to what is genuinely verified. Client server names, specifications, and private operational data do not belong on a portfolio.
02 / Capabilities
Practical work, not a logo wall.
The scope of an infrastructure engagement is agreed around the actual system, access available, backup status, and recovery path.
Bare-metal setup
Installing and configuring physical servers, storage, networking, and operating systems — with recovery access considered before changes.
Administration
Package updates, service management, backups, monitoring, certificates, and routine maintenance for Debian/Ubuntu and RHEL-family systems.
Troubleshooting
A methodical approach to boot, disk, memory, networking, DNS, TLS, and service failures. Preserve access, gather evidence, then change one thing.
Recovery & rescue
Reaching a failed machine through console or rescue mode, restoring access, and bringing services back without turning the incident into data loss.
Configuration & maintenance
Documenting the current state, reducing avoidable failure, and leaving the system more understandable than it was found.
03 / The stack beneath the stack
Think in layers.
When something is unreachable, the useful question is which layer has actually failed. A browser error, a DNS problem, an expired certificate, a dead service, and a full disk can all look similar to the person waiting for the page.
- 01BrowserThe interface a customer sees.
- 02Web serverRequests, routing, TLS, caching.
- 03ApplicationBusiness logic and integrations.
- 04DataPersistent state and backups.
- 05LinuxServices, storage, network, users.
- 06HardwareThe physical or virtual machine.
The discipline is to test the layer that is actually failing, with the least disruptive command that can confirm or reject a theory.
04 / Working approach
Calm beats clever.
Before a risky change, I want to know how to get back in. Before a reboot, I want to know whether the machine will come back. Before deleting anything, I want to know what depends on it.
That may sound slow during an incident, but it is usually faster than creating a second failure while trying to fix the first. The process is simple: establish access, record the state, check the evidence, protect what still works, make the smallest useful change, verify the result, and document what happened.
This is also why I care about backups that have been restored, monitoring that can actually alert someone, and configuration that another person can understand.
Selected reading