Linux#

Day 1 · Foundations

Every Welzin engineer ships software that runs on Linux - on a customer's box, in a container, on a cloud VM, or on a homelab. You don't need to be a kernel hacker. You need to be fluent at the shell so you can read a stranger's machine, diagnose a problem, and not be afraid of sudo.

If by the end of Day 1 you can SSH into a fresh Ubuntu server, install a service, look at its logs, fix its firewall, and explain what you did - you're ready for Chapter 2.

Outline#

1. The shell - bash basics, navigation, files, redirection, pipes
2. The filesystem - /etc, /var, /home, /proc, where things live and why
3. Users, groups, permissions - chmod, chown, sudo, umask
4. Processes - ps, top/htop, kill, signals, job control
5. Networking - ip, ss, curl, ports, /etc/hosts, DNS basics
6. Package management - apt, dpkg, repositories, why not to curl | bash from random sources
7. systemd - units, systemctl, journalctl, enabling services at boot
8. Logs - /var/log, journal, tailing, grepping, log rotation
9. SSH - keys vs passwords, ~/.ssh/config, port forwarding, scp/rsync
10. Editing in place - vim survival, nano for the impatient

101 Primer#

Why Linux, and which one?#

When we say "Linux" we almost always mean a distribution - typically Ubuntu Server LTS at Welzin. LTS = Long Term Support, five years of security patches, what production runs on. You'll occasionally see Alpine (inside containers), Debian (upstream of Ubuntu), and Amazon Linux (on EC2). Same shell, slightly different package manager.

The mental model#

Linux is a tree of files with processes acting on them, talking over sockets. Almost everything else is a refinement of those three ideas.

• A device? File in /dev.
• A running process? Directory in /proc.
• A network connection? A socket, which is also a file descriptor.

This is why the shell feels powerful once it clicks: the same verbs (cat, ls, grep, >) compose across all of these.

The 20 commands you'll use every day#

pwd              # where am I
ls -lah          # what's here, long, human-readable, hidden
cd -             # back to previous directory
cat file         # dump a file
less file        # paginate a file (q to quit)
head -n 50 file  # first 50 lines
tail -f file     # follow a log as it grows
grep -rin "foo" .   # recursive, case-insensitive, with line numbers
find . -name "*.py" # find files by pattern
which python3    # where does this binary live
df -h            # disk usage by mount
du -sh *         # directory sizes here
free -h          # memory
ps aux | grep nginx
kill -9 1234     # nuke pid 1234
sudo -i          # become root
systemctl status nginx
journalctl -u nginx -f
curl -I https://welzin.ai
ssh user@host

If you can't read these without looking them up, drill them.

Permissions in 60 seconds#

-rw-r--r--  1 aman staff  42 May 30 10:24 notes.md

That string left of aman is type | owner | group | others. Three triplets of rwx. The numeric form is what you'll actually type:

• chmod 644 file → owner read/write, everyone else read
• chmod 755 script.sh → same, but executable for everyone
• chmod 600 ~/.ssh/id_ed25519 → only owner, nobody else. SSH will refuse the key otherwise.

chown user:group file changes ownership. sudo runs as root. Use it deliberately.

systemd is how services live#

On modern Ubuntu, you don't start daemons by running them in & and hoping. You declare a unit file in /etc/systemd/system/myapp.service, then:

sudo systemctl daemon-reload
sudo systemctl enable --now myapp
sudo systemctl status myapp
sudo journalctl -u myapp -f

enable = start on boot. --now = also start it right now. journalctl -u <unit> -f is the single most useful debugging command on a Linux server. Memorise it.

Networking - the three questions#

When something on a server "doesn't work," you ask three questions in order:

1. Is the process running? systemctl status or ps aux | grep.
2. Is it listening on the right port? ss -tlnp (TCP, listening, numeric, with PIDs).
3. Is the firewall letting it through? sudo ufw status verbose.

90% of "the server is down" tickets are answered by these three commands. The other 10% is DNS.

Vim survival kit#

You will eventually SSH into a box that has no nano. Know this much:

i        insert mode
ESC      back to normal mode
:w       save
:q       quit
:wq      save and quit
:q!      quit and discard
/foo     search for foo
dd       delete line
u        undo

That's enough to edit a config file without crying.

Hands-on Checkpoints#

Mark this chapter complete only after you've done these:

• Spin up an Ubuntu VM (UTM on Mac, Multipass, or a $5 droplet) and SSH in with a key pair you generated yourself.
• Install nginx, hit the default page from your laptop's browser.
• Block port 80 with ufw, observe the failure, unblock it, observe it work.
• Write a systemd unit that runs a one-line Python HTTP server on boot.
• Tail its logs with journalctl -fu <unit> while curling it.
• Read /var/log/auth.log and find your own SSH login.

Further reading#

• The Linux Command Line - William Shotts (free PDF, classic)
• man bash - yes, actually
• Julia Evans zines - short, illustrated, excellent
• explainshell.com - paste any shell command, get an explainer

Welzin opinion: Don't memorise flags. Build a ~/.bashrc and ~/.ssh/config you actually trust, and a notes file of the 30 commands you reach for monthly. That file is more valuable than any tutorial.