Full Hands‑On Labs for Users, Permissions, sudo, Packages.

Linux Core Operations: Full Practical Labs (Beginner → Intermediate)

This post contains pure hands‑on labs you can run on any Linux system. Every exercise is designed to build confidence through repetition, real‑world scenarios, and structured progression.

You can use Ubuntu, Debian, CentOS, Rocky, AlmaLinux, or any cloud VM. All commands are distribution‑friendly, with alternatives provided where needed.

Preparing Your Environment

Before starting, update your system.

Ubuntu / Debian:

sudo apt update && sudo apt upgrade -y

RHEL / CentOS / Rocky / AlmaLinux:

sudo dnf update -y

This ensures your package index and installed software are current.

Lab 1: User & Group Management 👤

Linux uses users and groups to control access. These labs teach you how to create, modify, and delete accounts safely.

1.1 Create a New User

sudo adduser devuser

You’ll be prompted to set a password and optional details.

1.2 Create a New Group

sudo groupadd devteam

1.3 Add User to Group

sudo usermod -aG devteam devuser

1.4 Verify Group Membership

groups devuser

1.5 Create Multiple Users in One Command

for user in user1 user2 user3; do sudo adduser $user -q --disabled-password; done

1.6 Delete a User Safely

sudo deluser devuser

1.7 Delete a Group

sudo groupdel devteam

1.8 Inspect User & Group Files

cat /etc/passwd
cat /etc/group

These files store account metadata and group definitions.

Lab 2: Permissions & Ownership

Permissions determine who can read, write, or execute files. These labs help you master rwx, chmod, chown, and advanced permission bits.

2.1 Create a Test Directory

mkdir ~/permissions-lab
cd ~/permissions-lab

2.2 Create a File

touch file1.txt

2.3 View Permissions

ls -l

2.4 Change Permissions (Symbolic)

chmod u+rwx,g+rx,o-rwx file1.txt

2.5 Change Permissions (Numeric)

chmod 750 file1.txt

2.6 Change Ownership

sudo chown $USER:$USER file1.txt

2.7 Create a Shared Folder

sudo mkdir /shared
sudo chgrp devteam /shared
sudo chmod 770 /shared

2.8 Apply SGID to Shared Folder

This ensures new files inherit the group.

sudo chmod g+s /shared

2.9 Set Sticky Bit (Useful for /tmp‑style folders)

sudo chmod +t /shared

2.10 Test Permissions with Another User

sudo -u user1 touch /shared/testfile

This confirms group inheritance works.

Lab 3: sudo & Privilege Escalation

sudo allows controlled access to administrative commands.

3.1 Add User to sudo Group (Ubuntu/Debian)

sudo usermod -aG sudo devuser

3.2 Add User to wheel Group (RHEL/CentOS)

sudo usermod -aG wheel devuser

3.3 Test sudo Access

su - devuser
sudo whoami

Expected output:

root

3.4 Grant Specific sudo Permissions

Open sudoers safely:

sudo visudo

Add:

devuser ALL=(ALL) /usr/bin/systemctl

This grants service‑management privileges only.

3.5 View sudo Logs

sudo grep sudo /var/log/auth.log

Ubuntu:

sudo grep sudo /var/log/auth.log

RHEL:

sudo grep sudo /var/log/secure

Lab 4: Package Management

Package managers install, update, and remove software.

4.1 Install a Package (Ubuntu)

sudo apt install nginx -y

4.2 Install a Package (RHEL)

sudo dnf install httpd -y

4.3 Remove a Package

Ubuntu:

sudo apt remove nginx -y

RHEL:

sudo dnf remove httpd -y

4.4 Search for Packages

Ubuntu:

apt search python3

RHEL:

dnf search python3

4.5 Update Package Index

Ubuntu:

sudo apt update

RHEL:

sudo dnf check-update

4.6 Upgrade Installed Packages

Ubuntu:

sudo apt upgrade -y

RHEL:

sudo dnf upgrade -y

Lab 5: Managing Services with systemd

systemd controls background services and startup behavior.

5.1 Start a Service

sudo systemctl start nginx

5.2 Stop a Service

sudo systemctl stop nginx

5.3 Restart a Service

sudo systemctl restart nginx

5.4 Check Service Status

systemctl status nginx

5.5 Enable Service at Boot

sudo systemctl enable nginx

5.6 Disable Service

sudo systemctl disable nginx

5.7 View Service Logs

journalctl -u nginx

5.8 Create a Custom Service

Create file:

sudo nano /etc/systemd/system/myapp.service

Add:

[Unit]
Description=My Custom Python App

[Service]
ExecStart=/usr/bin/python3 /opt/myapp/app.py
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Reload systemd:

sudo systemctl daemon-reload

Start service:

sudo systemctl start myapp

Enable at boot:

sudo systemctl enable myapp

LAB 6: Managing Default Shells & User Profiles

Understanding shells and login profiles is essential for user management and troubleshooting.

6.1 Check a User’s Default Shell

getent passwd devuser

What You’re Seeing

The last field shows the shell:

/bin/bash
/bin/sh
/bin/zsh

6.2 Change a User’s Shell

sudo chsh -s /bin/bash devuser

Why This Matters

Different shells behave differently. Some users may require bash for scripts or zsh for customization.

6.3 View Login Profile Files

ls -a /home/devuser

Look for:

.bashrc
.profile
.bash_logout

6.4 Add a Login Message

echo "Welcome to the server, devuser!" | sudo tee -a /home/devuser/.bashrc

Reload:

su - devuser

Real‑World Use

Teams often add environment variables, aliases, or warnings to .bashrc.

LAB 7: Advanced Permissions (ACLs)

ACLs (Access Control Lists) allow fine‑grained permissions beyond rwx.

7.1 Install ACL Tools

Ubuntu:

sudo apt install acl -y

RHEL:

sudo dnf install acl -y

7.2 Set an ACL for a User

sudo setfacl -m u:user1:rwx file1.txt

7.3 View ACLs

getfacl file1.txt

7.4 Remove an ACL

sudo setfacl -x u:user1 file1.txt

Why ACLs Matter

They allow permissions like:

“Give user1 read access”
“Give devteam write access”
“Give auditors read‑only access”

Without changing ownership.

LAB 8: sudo Security & Restrictions

(Real‑World Admin Work)

sudo is more than “run commands as root.” This lab teaches controlled privilege escalation.

8.1 Allow a User to Run Only One Command

sudo visudo

Add:

projectuser ALL=(ALL) /usr/bin/apt

8.2 Allow a User to Run Commands Without Password

projectuser ALL=(ALL) NOPASSWD: /usr/bin/systemctl

8.3 Deny a User from Running a Command

projectuser ALL=(ALL) !/usr/bin/rm

8.4 Log All sudo Commands

sudo grep sudo /var/log/auth.log

RHEL:

sudo grep sudo /var/log/secure

Real‑World Use

Companies use sudo restrictions to enforce least privilege.

LAB 9: Package Management: Repositories & Caching

Package managers do more than install software.

9.1 Check Installed Repositories

Ubuntu:

ls /etc/apt/sources.list.d/

RHEL:

dnf repolist

9.2 Add a Repository

Ubuntu:

sudo add-apt-repository universe
sudo apt update

RHEL:

sudo dnf config-manager --set-enabled crb

9.3 Clean Package Cache

Ubuntu:

sudo apt clean

RHEL:

sudo dnf clean all

9.4 Check Package Info

Ubuntu:

apt show nginx

RHEL:

dnf info httpd

Why This Matters

Package metadata helps you understand:

Dependencies
Versions
Maintainers
Installed files

LAB 10: systemd Advanced: Dependencies, Targets & Timers

systemd is more than start/stop. This lab teaches deeper service management.

10.1 Check Service Dependencies

systemctl list-dependencies nginx

10.2 Check Boot Targets

systemctl get-default

Common targets:

multi-user.target (servers)
graphical.target (desktops)

10.3 Change Boot Target

sudo systemctl set-default multi-user.target

10.4 Create a systemd Timer (Cron Replacement)

Create a script:

sudo nano /usr/local/bin/backup.sh

Add:

#!/bin/bash
echo "Backup ran at $(date)" >> /var/log/backup.log

Make executable:

sudo chmod +x /usr/local/bin/backup.sh

Create a timer unit:

sudo nano /etc/systemd/system/backup.timer

Add:

[Unit]
Description=Run backup script every minute

[Timer]
OnCalendar=*:0/1
Unit=backup.service

[Install]
WantedBy=timers.target

Create the service unit:

sudo nano /etc/systemd/system/backup.service

Add:

[Unit]
Description=Backup Script

[Service]
ExecStart=/usr/local/bin/backup.sh

Enable & Start Timer:

sudo systemctl daemon-reload
sudo systemctl enable --now backup.timer

Check Timer Status:

systemctl list-timers

Real‑World Use

Timers replace cron in modern systems.

LAB 11: File Ownership & Permissions in Real‑World Scenarios

This lab simulates a real company environment.

Scenario: A Shared Project Folder

Step 1: Create the folder

sudo mkdir -p /opt/company/projectA

Step 2: Create a team group

sudo groupadd projectA-team

Step 3: Assign group ownership

sudo chown :projectA-team /opt/company/projectA

Step 4: Give group write access

sudo chmod 2770 /opt/company/projectA

2 = SGID Ensures new files inherit the group.

Step 5: Add users to the team

sudo usermod -aG projectA-team user1
sudo usermod -aG projectA-team user2

Step 6: Test access

sudo -u user1 touch /opt/company/projectA/test1
sudo -u user2 touch /opt/company/projectA/test2

Real‑World Use

This is how engineering teams collaborate on shared codebases.

LAB 12: Troubleshooting Services (Real‑World Debugging)

This lab teaches how to diagnose failing services.

12.1 Check Service Status

systemctl status nginx

12.2 Check Logs

journalctl -u nginx --no-pager

12.3 Check Port Usage

sudo ss -tulpn | grep 80

12.4 Restart the Service

sudo systemctl restart nginx

12.5 Reload Configuration Without Restart

sudo systemctl reload nginx

Real‑World Use

Reloading avoids downtime.

Final Challenge (Beginner → Intermediate)

This challenge reinforces everything you’ve learned.

Your Task

Create a user named projectuser.
Create a group named projectteam.
Add the user to the group.
Create /opt/project.
Assign group ownership to projectteam.
Apply SGID to the folder.
Install Apache or Nginx.
Enable and start the service.
Document your steps in a text file.

This challenge simulates a real‑world onboarding task for junior engineers.