Linux Server Administration — Challenge
Create users and groups, set permissions that actually hold, and manage services and packages on a server you did not build.
- Time
- 22 min
- Level
- Beginner
- Objectives
- 4 objectives
- Cost
- Free
Where this fits in the platform
Already built
—
This lab adds
- A Linux server you can navigate, inspect and administer
Before you start
You will need
- Any Linux (Ubuntu 22.04+ or RHEL 9)
- sudo access
You do not need these already — the lab environment below provides them.
You will be able to
- Create users and groups with correct ownership and permissions
- Read and set permissions without reaching for chmod 777
- Manage packages and services, and make them survive a reboot
- Find what is consuming disk on a server that is full
Cost — Free
— runs on any Linux machine, a VM, or a container
The goal#
Achieve the same outcome as Linux Server Administration, from an empty starting point, without the steps.
You have been handed SSH access to a server somebody else built. A colleague needs to deploy to it, the application directory is owned by root, and the disk is at 91%. Nobody documented any of it.
This is the most common first task in the job, and none of it is exotic — it is users, permissions, services and disk.
Hands-on environment
Run this lab in a real terminal, free and in your browser. The environment is temporary and yours alone — break it as much as you like.
Start the challengeOpens in Killercoda, in a new tab — keep this page open for the steps.
This is the guided lab's environment — the same machine, with its walkthrough on the left. Work from the task above and leave those steps alone until you are done, or you are reading the answers.
Run it on your own machine
Run this lab on your own machine. One command starts the environment, with everything the lab needs already installed:
You will need:
- bash
git clone https://github.com/EgyKode/EgyKode-lab.git
cd EgyKode-lab
./egykode start
./egykode shell
ssh node1You need Docker and Git installed. Everything else runs inside the environment. The first start downloads it and takes a few minutes; later starts are seconds.
Not sure what you already have? Run: npm run doctor — it checks and changes nothing.
Anything you tick here is your own record. EgyKode cannot see inside that terminal, so the success criteria stay self-assessed even when the environment checks your work for you.
What must be true when you are done
Step 1 of 3
What must be true when you are done#
- A deploy user exists, belongs to a shared group, and can read the application directory without being root.
/opt/appis owned by that group and group-writable, and a second user in the group can write to it.- A service is installed, running, and comes back after
reboot— proven bysystemctl is-enabled. - You can state which directory is consuming the most disk, with the command that told you.
Rules#
- Do not open the guided lab until you are finished, or until you have been stuck on the same thing for 20 minutes. Being stuck is the exercise; staying stuck is not.
- Official documentation is allowed and encouraged. In the job it is the first thing you open.
- Verify every criterion yourself with a command whose output you can read. "It looks right" is not a check.
If you get stuck#
Work in layers rather than restarting things:
- What did you expect to happen, exactly?
- What happened instead — the error text, not a paraphrase?
- Which layer is that error from?
- What is the smallest command that proves the layer below is fine?
That sequence is the skill this tier exists to build. The commands are lookup-able; the sequence is not.
You are done when
0 of 4
The concept behind it
Next up
Lab 1 of 59 on the project path