Best Way To Learn Linux

Best Way To Learn Linux

Reading time1 min
#Linux#Learning#Tech#LinuxTutorial#LinuxSkills#LinuxCommunity

Mastering Linux Efficiently: Hands-On Over Memorization

Expecting to master Linux by memorizing every command is a losing battle. What actually builds competence is direct exposure to real tasks, repeated troubleshooting, and incremental automation.


Reality Check: Linux in Production

Consider supporting a backend MySQL service (say, MariaDB 10.6) on a CentOS 9 Stream host running in a mixed environment—Docker containers, CI/CD deployment scripts, and half a dozen cron jobs. At 2 AM, something fails. Few stop to reference a manual. Instead, pattern recognition, familiarity with the command-line environment, and the ability to adapt matter most.


Build Your Sandbox

Provisioning a safe place to experiment isn’t optional—avoid learning on production. Options:

MethodTrade-Off
Dedicated spare machineClosest to bare metal, power/hardware cost
VirtualBox/KVM VMFast reset, snapshots, less “real” hardware
WSL2 on Windows 11Good enough for CLI, some kernel gaps
Cloud instance (e.g. AWS t3.micro)Possible cost, public IP issues

Note: For scripting tests involving emails or networking, full VM/Cloud often exposes more relevant failure-modes (e.g., ufw, actual mail transfer). WSL2 lacks certain kernel modules—SELinux, AppArmor won’t work as expected.


Learn by Solving Actual Problems

Authentic tasks integrate multiple skills. For example, “User gets ‘permission denied’ after SSH-key update” isn’t theoretical. Trace:

sudo grep "<username>" /etc/passwd
sudo tail -f /var/log/secure
ls -l /home/<username>/.ssh/authorized_keys

Notice SELinux denial?

sudo ausearch -m avc -ts recent

If you see:

type=AVC msg=audit(1718267998.150:115): avc:  denied  { read } for  pid=885 comm="sshd" name="authorized_keys" scontext=system_u...

Compare restorecon -Rv /home/<username>/.ssh/ vs. just fixing ownership.

Gotcha: Changing file permissions alone on CentOS won’t resolve SELinux rejections. Reading the log and running restorecon are faster than searching “ssh permission denied linux”.


Mini-Projects Over Repetition

Quick exercises beat passive reading. Examples:

A) Deploy and Secure nginx

  1. sudo dnf install nginx
  2. sudo systemctl enable --now nginx
  3. sudo firewall-cmd --add-service=http --permanent
  4. Tweak /etc/nginx/nginx.conf; reload and check config
  5. Add a self-signed cert (see openssl flags below).
  6. Scan for open ports: sudo ss -tuln

Want a list of enabled systemd services? systemctl list-unit-files --state=enabled

Tip: Quickly revert—dnf history undo last rolls back a single package transaction (not perfect, leaves configs).

B) Bash Scripting: Backup Routine

#!/bin/bash

src="/etc"
dest="$HOME/backup-$(hostname)-$(date +%Y%m%d).tar.gz"

tar --numeric-owner -czpf $dest $src 2>error.log
echo "$(date): Backup to $dest complete" >> ~/backup.log

Non-obvious: Using --numeric-owner is critical if restoring onto a different UID-mapped system. Missed in many blog posts.


Systematic Troubleshooting

Error messages aren’t just noise. For systemd-based systems:

sudo journalctl -xeu nginx

Interpret actual output, e.g.:

nginx[2234]: [emerg] bind() to 0.0.0.0:80 failed (98: Address already in use)

Don’t just kill processes. Run ss -tulpn to identify port users, try lsof -i :80 to see if a rogue process still holds the port after systemctl stop.

Side Note: Sometimes containers conflict with host ports—especially with Docker Compose defaults.


Automation and Tooling

Start simple, e.g., automate log rotation when learning cron:

0 2 * * * /usr/sbin/logrotate /etc/logrotate.d/custom

Then, move to Ansible for stateful configuration across hosts. Don’t attempt to script everything in bash—awkward error handling, hard to test. For anything multi-host, transition to a declarative tool.


Community, Documentation, “man” Pages

Active participation in r/linuxadmin or Stack Exchange exposes you to less-documented edge cases (e.g., obscure iptables modules, systemd-analyze blame for boot profiling).

Often man pages include practical EXAMPLES at the bottom, which are better than dry option definitions.


Final Principle

Put theory to the test early and often. Document what you break and how you fix it. Not every fix is elegant—sometimes chattr -i is required to modify a stubborn file, though it’s rarely recommended.


No substitute exists for daily command-line work—errors, weird outputs, and partial successes included. If you’re stuck, try a different tool (htop vs. ps, ncdu vs. du -h, etc.). Shortcuts emerge only through repetition.

What’s the smallest practical Linux automation you’ve written that genuinely saved you time? Consider sharing it.