Linux Administration
Linux Best Practices for Beginners
In this lesson
Linux best practices for beginners are the habits, disciplines, and mental models that separate administrators who work safely and deliberately from those who learn through costly, avoidable mistakes. Linux gives every user extraordinary power over the system — including the power to destroy it irreversibly in a single command. The practices in this lesson exist not to restrict what you can do, but to make sure you always have a path back when something goes wrong.
The Principle of Least Privilege
The single most important habit in Linux administration is running commands with the minimum privilege required for the task. Every action performed as root bypasses all permission checks — a typo, a misunderstood flag, or a malicious script can delete the entire filesystem without a single confirmation prompt.
❌ Logging in as root
Every command runs with unrestricted system access. A single typo — rm -rf / home/user instead of rm -rf /home/user — deletes the root filesystem. No warning, no undo.
# Dangerous — avoid this entirely
ssh root@server
su -
✅ Using sudo for elevated tasks
Only specific commands run as root. Every privileged action is logged with a timestamp and username in /var/log/auth.log. Session mistakes affect only normal user scope.
# Correct — elevate only what needs it
sudo systemctl restart nginx
sudo apt update
# Check which user you are currently logged in as
whoami
# Check your current effective privileges
id
# Run a single command as root, then drop back to your normal user
sudo apt update
sudo systemctl reload sshd
# Open a root shell only when genuinely needed — and exit immediately when done
sudo -i
# ... do root-only work ...
exit
# Review what sudo permissions your account has
sudo -l# whoami
adminuser
# id
uid=1001(adminuser) gid=1001(adminuser) groups=1001(adminuser),27(sudo)
# sudo -l
Matching Defaults entries for adminuser on server1:
env_reset, mail_badpass, secure_path=/usr/local/sbin:...
User adminuser may run the following commands on server1:
(ALL : ALL) ALL
What just happened? id confirmed the user is a normal account that belongs to the sudo group — meaning they can elevate individual commands with sudo without needing to log in as root. sudo -l listed the exact permissions granted, which is always worth reviewing on a new server.
Analogy: Root access is like a master key that opens every door in a building and also disables all the locks. You use it to do a specific job, then put it back in the safe. You do not carry it around all day as your everyday key.
Think Before You Run — Destructive Commands
Several common Linux commands are irreversible. Unlike deleting a file on a desktop OS, there is no Recycle Bin and no undo. Before running any command that modifies or deletes data, build the habit of previewing what it will affect.
Always run ls -la targetdir/ first to confirm what is in the directory. Consider using rm -i (interactive) for non-scripted deletions to require per-file confirmation.
A single character typo in the of= (output file) argument can wipe the wrong disk instantly. Always double-check lsblk output before specifying a device.
Formatting the wrong partition is a common beginner error. Verify the device name with lsblk and blkid before running mkfs.
A commonly copy-pasted "fix" that creates serious security vulnerabilities. Use the minimum permissions required — typically 644 for files and 755 for directories.
A single > overwrites; use >> to append. Redirecting to the wrong file can destroy configuration files or log data.
# SAFE HABIT: preview before deleting — use ls or echo first
ls -la /tmp/oldlogs/
# Then, only if correct:
rm -rf /tmp/oldlogs/
# SAFE HABIT: use --dry-run or -n flags where available
rsync -av --dry-run /source/ /destination/
# SAFE HABIT: use rm -i for interactive confirmation on important deletions
rm -i important-config.conf
# SAFE HABIT: verify disk devices before any low-level disk operation
lsblk
blkidAlways Back Up Config Files Before Editing
Configuration files control how every service on a Linux system behaves. A syntax error in /etc/ssh/sshd_config can lock you out of a remote server permanently. The simplest protection is a one-line backup before every edit.
Step 1 — Back up the original file
Create a dated copy with a .bak or timestamped suffix before touching any config file. The original is your recovery point.
sudo cp /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak
Step 2 — Make your changes
Edit the live file. Make one logical change at a time rather than many simultaneous edits, so a problem can be isolated quickly.
sudo nano /etc/nginx/nginx.conf
Step 3 — Validate before reloading
Most services provide a syntax check flag. Use it every time — reloading a service with a broken config can take it offline immediately.
sudo nginx -t
sudo sshd -t
sudo named-checkconf
Step 4 — Reload the service
Only after a clean syntax check passes. Use reload rather than restart where supported — reload applies config changes without dropping active connections.
sudo systemctl reload nginx
# Backup with a timestamp — more useful than .bak when you edit a file multiple times
sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.$(date +%Y%m%d)
# Validate SSH config before reloading — prevents locking yourself out
sudo sshd -t
# Restore from backup if something goes wrong
sudo cp /etc/ssh/sshd_config.20240315 /etc/ssh/sshd_config
sudo systemctl reload sshd
# View a diff between your edited file and the backup to confirm only intended changes
diff /etc/nginx/nginx.conf /etc/nginx/nginx.conf.bak# sudo sshd -t (clean — no output means no errors) # sudo sshd -t (with a syntax error) /etc/ssh/sshd_config line 42: Bad configuration option: PermitRootLogon sshd: /etc/ssh/sshd_config: terminating, 1 bad configuration options # diff output (showing a single changed line) 42c42 < PermitRootLogin no --- > PermitRootLogin yes
What just happened? sshd -t caught a config error before the service was reloaded — if this check had been skipped, the SSH daemon would have refused to restart and the server would have become inaccessible remotely. The diff confirmed only the intended line changed.
Test Changes in a Safe Order
Experienced administrators follow a consistent order of operations when making changes to a live system. Applying this sequence — even for small changes — builds a habit that prevents the most common production incidents.
Fig 1 — Safe order of operations for every system change
Shell Habits That Save You
Beyond individual commands, a set of small shell habits compound over time to dramatically reduce errors and speed up daily work. These are practised by every experienced Linux administrator.
# Use echo as a dry run to preview what a command will affect
FILE="/home/user/reports"
echo rm -rf "$FILE"
# Output: rm -rf /home/user/reports
# Only remove echo once the path looks correct
# Quote all variables containing file paths
TARGET="/var/log/app logs" # space in path
rm "$TARGET" # correct — treated as one argument
rm $TARGET # wrong — splits into rm /var/log/app and rm logs
# Check history and search it
history | tail -20
# Press Ctrl+R then type part of a command to reverse search
# Confirm your location before a delete operation
pwd
ls -la
rm -rf old_cache/Build a Personal Admin Checklist
Professional administrators do not rely on memory for safety-critical steps. They build and follow personal checklists — for new server setup, for making firewall changes, for deploying application updates. A written checklist applied consistently is more reliable than experience alone, because experience can be overridden by fatigue, distraction, or pressure.
- Back up affected files
- Understand the rollback procedure
- Know the validation command
- Notify stakeholders if needed
- Update all packages
- Create non-root admin user
- Disable root SSH login
- Configure and enable firewall
- Check service status
- Review logs for errors
- Test the expected behaviour
- Document what you changed
# New server first-steps — a minimal starting checklist
# 1. Update all packages immediately
sudo apt update && sudo apt upgrade -y # Debian/Ubuntu
sudo dnf update -y # RHEL/Rocky/Fedora
# 2. Create a non-root admin user
sudo useradd -m -s /bin/bash adminuser
sudo usermod -aG sudo adminuser # Debian/Ubuntu
sudo usermod -aG wheel adminuser # RHEL
# 3. Verify the service is running after a change
sudo systemctl status nginx
sudo journalctl -u nginx --since "5 minutes ago"
# 4. Document your change (append to a simple change log)
echo "$(date): Updated nginx.conf — set worker_processes to auto" >> ~/change.logAnalogy: A pilot does not skip the pre-flight checklist because they have flown thousands of times. The checklist exists precisely because experienced operators are capable of overlooking familiar steps under routine conditions. Linux administration is no different.
Never Run Commands Copied from the Internet Without Reading Them First
A pattern common in tutorials and forums is curl https://example.com/install.sh | sudo bash — this downloads a script and runs it as root in a single step, with no opportunity to review the script's contents. Always download the script first, read it, and only then run it. Similarly, never copy a multi-stage pipeline command without understanding every segment — malicious commands are routinely hidden in the middle of a seemingly useful chain.
Lesson Checklist
sudo for elevated tasks rather than logging in as root
sudo bash
Teacher's Note
Every experienced Linux administrator has a story about a mistake that took down a server. The habits in this lesson exist because of those stories. The goal is not to make you fearful of the command line, but to make your caution deliberate and fast — back up, validate, reload takes ten seconds and has saved careers.
Practice Questions
1. You need to edit /etc/ssh/sshd_config on a remote production server to change the SSH listening port. Write out every command you would run, in order, from backup through to confirming the change is live — including the validation step that prevents locking yourself out.
2. Explain why curl https://example.com/setup.sh | sudo bash is considered dangerous, and describe the two-step alternative that allows you to run the same script safely.
3. A variable TARGET contains the path /home/user/my documents. Explain what happens when you run rm -rf $TARGET versus rm -rf "$TARGET", and which is correct.
Lesson Quiz
1. Which of the following best describes the principle of least privilege in Linux administration?
2. Before reloading a service after editing its configuration file, what is the correct step to take to avoid taking the service offline?
3. Why is running curl https://example.com/install.sh | sudo bash considered a security risk?
Up Next
Lesson 11 — User and Group Management
Creating, modifying, and removing users and groups — the foundation of multi-user Linux administration