Linux Server Setup
Linux, SSH, users, permissions, services and logs.
Overview
Set up a Linux server from scratch: manage users and permissions, harden SSH, run and manage services with systemd, and configure persistent logging.
The problem
Provision and harden a Linux server with correct users, permissions, services and logging.
Why it matters
Server administration is the foundation of every DevOps role.
What you'll build
- A hardened Linux server
- A user/permission matrix
- Managed services
- Persistent logs
What you'll learn
- Linux administration
- SSH security
- systemd
- Logging
Business problem
Every production system begins with a correctly configured, secure Linux host.
Technical problem
Provision and secure a Linux host with usable accounts, correct permissions and managed services.
When you're done: A secure, well-administered Linux server.
Requirements
User requirements
- Log in securely over SSH
- Manage multiple users
- Run services reliably
- See system logs
System requirements
- A running Linux server
- SSH access
- systemd
Functional requirements
- SSH hardening
- User/group management
- Service management
- Persistent logging
Non-functional requirements
- Secure by default
- Reproducible via commands
Technical requirements
- ssh config
- useradd/usermod
- systemctl
- journald
Security requirements
- Disable password/root SSH
- Least-privilege accounts
Operational requirements
- Documented provisioning commands
Constraints
- Bare-metal or VM Linux
Success criteria
- SSH key-only login
- Users have correct permission
- Services start on boot
- Logs persist
Flows
Request Flow
- 1
Browser
User requests the application over HTTPS.
- 2
CDN / DNS
Edge routes the request to the origin.
- 3
Load Balancer
Distributes traffic across healthy app instances.
- 4
Application
Handles the request, applies business logic.
- 5
Cache
Serves fast reads for hot data.
- 6
Database
Persists data and returns results.
Project Structure
Root of the client application source.
Setup
- 1
Prerequisites
You need the tools required by Linux, SSH, systemd installed and available on your PATH.
- 2
Clone project
Clone the repository locally.
1. Clone the repositorygit clone <your-repo-url> <project-folder> - 3
Install dependencies
Install the project dependencies.
1. Check the OSLinuxcat /etc/os-releaseExpected
Shows the OS name and version.
If it fails
File not found
Fix
Use a standard Linux distribution.
- 4
Configure environment
Set the environment variables documented for this project. Never commit secrets.
1. Create the environment filecp .env.example .env # then edit values - 5
Start project
Run the development command and confirm it starts.
1. List usersLinuxcat /etc/passwdExpected
Lists user accounts.
If it fails
Permission denied
Fix
Read the world-readable passwd file.
- 6
Verify
Open the printed local URL and confirm the primary flow works.
Build Phases
0 of 6 phases complete
Objective: Establish the next milestone of the operational environment.
What changes: The project advances to the next coherent state, keeping the previous milestones working.
Files touched
Relevant source and configuration files for this milestone.Run
1. Check the OSLinuxcat /etc/os-releaseExpected
Shows the OS name and version.
If it fails
File not found
Fix
Use a standard Linux distribution.
Tasks
- Implement the specific behaviour required for this milestone.
- Verify the previous milestone still works.
Validate: The milestone behaves as expected and does not break existing functionality.
Common mistakes
- • Skipping validation and moving on before confirming the milestone works.
Objective: Establish the next milestone of the operational environment.
What changes: The project advances to the next coherent state, keeping the previous milestones working.
Files touched
Relevant source and configuration files for this milestone.Run
1. List usersLinuxcat /etc/passwdExpected
Lists user accounts.
If it fails
Permission denied
Fix
Read the world-readable passwd file.
Tasks
- Implement the specific behaviour required for this milestone.
- Verify the previous milestone still works.
Validate: The milestone behaves as expected and does not break existing functionality.
Common mistakes
- • Skipping validation and moving on before confirming the milestone works.
Objective: Establish the next milestone of the operational environment.
What changes: The project advances to the next coherent state, keeping the previous milestones working.
Files touched
Relevant source and configuration files for this milestone.Tasks
- Implement the specific behaviour required for this milestone.
- Verify the previous milestone still works.
Validate: The milestone behaves as expected and does not break existing functionality.
Common mistakes
- • Skipping validation and moving on before confirming the milestone works.
Objective: Establish the next milestone of the operational environment.
What changes: The project advances to the next coherent state, keeping the previous milestones working.
Files touched
Relevant source and configuration files for this milestone.Tasks
- Implement the specific behaviour required for this milestone.
- Verify the previous milestone still works.
Validate: The milestone behaves as expected and does not break existing functionality.
Common mistakes
- • Skipping validation and moving on before confirming the milestone works.
Objective: Establish the next milestone of the operational environment.
What changes: The project advances to the next coherent state, keeping the previous milestones working.
Files touched
Relevant source and configuration files for this milestone.Tasks
- Implement the specific behaviour required for this milestone.
- Verify the previous milestone still works.
Validate: The milestone behaves as expected and does not break existing functionality.
Common mistakes
- • Skipping validation and moving on before confirming the milestone works.
Objective: Establish the next milestone of the operational environment.
What changes: The project advances to the next coherent state, keeping the previous milestones working.
Files touched
Relevant source and configuration files for this milestone.Tasks
- Implement the specific behaviour required for this milestone.
- Verify the previous milestone still works.
Validate: The milestone behaves as expected and does not break existing functionality.
Common mistakes
- • Skipping validation and moving on before confirming the milestone works.
Commands
cat /etc/os-releaseExpected
Shows the OS name and version.
If it fails
File not found
Fix
Use a standard Linux distribution.
cat /etc/passwdExpected
Lists user accounts.
If it fails
Permission denied
Fix
Read the world-readable passwd file.
Testing
Unit tests
Core logic and pure functions behave correctly.
cat /etc/os-releaseSuccess: All unit tests pass without errors.
Integration tests
Components integrate correctly with data sources and services.
npm testSuccess: Integration tests pass for the primary flows.
API tests
Endpoints respond to valid and invalid input correctly.
npm testSuccess: API tests cover happy and failure paths.
End-to-end tests
A user can complete the primary journey end to end.
npm run test:e2eSuccess: The main user journey completes successfully.
Security tests
No obvious security regressions are introduced.
npm auditSuccess: No high or critical vulnerabilities.
Debugging & Troubleshooting
Port already in use at startup
Why: Another process is binding the same port your app wants.
Check: List what is using the port.
lsof -i :3000 # Linux/macOS | netstat -ano | findstr :3000 # Windows
Fix: Free the port or start your app on a different port.
Prevent: Choose uncommon ports and document them in the README.
Environment variable missing or undefined
Why: A required value was not loaded into the runtime.
Check: Print the variable or inspect the config loader.
echo $MY_VAR # Linux/macOS | echo %MY_VAR% # Windows
Fix: Add the variable to your .env file and restart the process.
Prevent: Fail fast at startup when required env vars are absent.
API request times out
Why: An upstream call is slow or the network is blocked.
Check: Time a direct request against the upstream.
curl -w 'time_total: %{time_total}\n' http://upstream/healthFix: Add timeouts and retries to the client; verify the upstream is up.
Prevent: Set explicit timeouts and circuit breakers on outbound calls.
Dependency fails to install or run
Why: Version conflicts or an incompatible runtime.
Check: Inspect the error and the installed versions.
npm ls <pkg>
Fix: Align versions or clear the lockfile and reinstall.
Prevent: Commit a lockfile and use the same Node version everywhere.
Security
Security is treated as a core requirement: input is validated, secrets are protected, and dependencies are kept up to date.
Input validation
Validate and sanitize all user input before use.
Secrets management
Store secrets in environment variables, never in source.
Dependency hygiene
Regularly audit dependencies for known vulnerabilities.
Deployment
- 1
Prepare for deployment
Build the production artifact.
1. Build for productionnpm run build - 2
Deploy
Deploy to the project target platform following its documented steps.
1. Deploynpm run deploy # or the platform-specific command - 3
Verify
Confirm the deployed application responds and its health check passes.
1. Check healthcurl -I https://<your-deployed-url>
Documentation
Project Overview
Set up a Linux server from scratch: manage users and permissions, harden SSH, run and manage services with systemd, and configure persistent logging. This is a beginner infrastructure project in the operational environment space, built to demonstrate real engineering, not just copied code.
What You Will Build
- A hardened Linux server - A user/permission matrix - Managed services - Persistent logs
Problem Statement
Every production system begins with a correctly configured, secure Linux host. Provision and secure a Linux host with usable accounts, correct permissions and managed services.
Technology Stack
Linux, SSH, systemd
Installation
Clone the repository and install dependencies with the documented commands.
Local Development
Run the development command and open the printed local URL.
Testing
Run the test commands documented in the Testing section and confirm they pass.
Deployment
Follow the documented deployment steps for this project's target platform.
Interview Explanation
Use the Interview section to explain the architecture, technology choices and trade-offs.
Build Process
Phases guide the build in 6 checkpoints. Complete each and validate before moving on.
Interview Prep
30-second pitch
I built Linux Server Setup — provision and harden a linux server with correct users, permissions, services and logging. It uses Linux, SSH, systemd and solves every production system begins with a correctly configured, secure linux host.
2-minute walkthrough
Set up a Linux server from scratch: manage users and permissions, harden SSH, run and manage services with systemd, and configure persistent logging. The core requirements were SSH hardening, User/group management, Service management. I structured the work around Administer users and permissions, Harden SSH access, Manage services with systemd and validated the result with the documented tests.
Architecture
Because this is a devops-foundations project, the architecture is concentrated in operational environment rather than a distributed system.
Why these technologies
I chose Linux, SSH, systemd because they are the pragmatic, well-supported tools best suited to building a infrastructure of this kind.
Why this architecture
The structure exists to keep concerns separated, make each piece testable, and scale the project cleanly as requirements grow.
At scale
At scale I would introduce caching, move to a service boundary structure, add proper observability, and enforce stricter contracts between components.
What can fail
The data source becomes unavailable, A dependency introduces a breaking change, Performance degrades under load, Configuration drift between environments
Monitoring
Monitoring is covered in the Observability section, focusing on basic health and error signals.
Security
Security was handled by validating input, protecting secrets, and following the practices listed in the Security section.
Deployment strategy
Deployment follows the steps in the Deployment section for the target platform, with a health check to confirm success.
What I'd do differently
With more time I would add deeper test coverage, stronger observability, and automated deployment.
Practice Q&A
Why did you build Linux Server Setup?
To demonstrate Administer users and permissions and Harden SSH access on a real, portfolio-worthy project.
What was the hardest part?
Coordinating the pieces so each stays correct as the project grows, and validating end to end.
How do you handle failure and scale?
By designing for correctness first and adding resilience once the core works.
Extensions
- Add deeper test coverage
- Add observability and alerting
- Harden security
- Automate deployment