LinuxBeginner 12 min Lesson 1 of 24

Linux Basics

What Linux is, why servers run it, how the filesystem is laid out, and the handful of ideas that make everything else make sense.

Linux · Lesson 1 of 24
0/24 done(0%)

What is it? #

Linux is the operating system almost all servers run. If your code leaves your laptop, it probably lands on a Linux machine.

You do not need to master it. You need to be able to move around the filesystem, read logs, manage services, check what is running, and fix things when a deployment goes wrong.

Two ideas explain most of Linux. Everything is a file — including devices, processes and configuration. And small programs are combined with pipes rather than one large program doing everything.

Distributions differ mainly in package manager and defaults. Ubuntu and Debian use apt; Red Hat, Rocky and Amazon Linux use dnf or yum. The concepts are identical.

Think of it like this #

A well-organised workshop where every tool does one job. There is no single machine that cuts, sands and paints — there is a saw, a sander and a sprayer, and you pass the work from one to the next.

That is exactly what a pipe does: the output of one small tool becomes the input of the next.

Simple example #

You connect to a server for the first time. You need to know where you are, what the machine is, how much disk and memory it has, and where things live.

Code #

BASH
# Where am I and who am I?
pwd                  # print working directory
whoami               # current user
hostname             # machine name
uptime               # how long it has been running, and load average

# What is this machine?
cat /etc/os-release  # distribution and version
uname -a             # kernel version and architecture
nproc                # number of CPU cores
free -h              # memory, human readable
df -h                # disk space per filesystem

# Getting help
man ls               # the manual page (q to quit)
ls --help            # short help
type ls              # is it a program, a builtin or an alias?
TEXT
The filesystem layout that matters

/etc        configuration files          nginx, ssh, systemd units
/var/log    log files                    where you look when something breaks
/var/www    web content, by convention
/home       user home directories
/opt, /srv  application code, by convention
/tmp        temporary files, cleared on reboot
/usr/bin    installed programs
/proc       live kernel and process information, not real files
/dev        devices, also exposed as files

There are no drive letters. Everything hangs off a single root: /
BASH
# Small tools, combined with pipes
cat /var/log/nginx/access.log | grep " 500 " | wc -l
#   read the file    | keep 500 errors | count the lines

ps aux | grep python | grep -v grep
#  list processes | find python ones | remove grep itself from the results

How it works #

pwd prints where you are. Paths starting with / are absolute, from the root; anything else is relative to your current directory.

cat /etc/os-release reads a plain text file. Nearly all configuration on Linux is plain text, which is why you can read, edit, version-control and diff it.

free -h and df -h answer the two most common "why is this server unhappy" questions: out of memory, or out of disk.

man is the built-in manual. It is dense but authoritative, and learning to skim it is faster than searching the web for common commands.

The pipe examples show the composition idea. | sends the output of the left command into the right one. cat reads, grep filters, wc -l counts — three tiny programs solving one problem together.

grep -v grep in the second example removes the grep process itself from the results, which would otherwise always appear. It is a small idiom you will see constantly.

The filesystem layout is worth memorising because it is consistent. Configuration in /etc, logs in /var/log, and that alone resolves a large share of "where is it" questions.

Real-world use #

Every deployment, container image and CI runner is Linux. Docker images are Linux filesystems, which is why the same knowledge applies whether you use servers or containers.

The skills that matter most in practice are narrow: reading logs, checking disk and memory, restarting a service, tailing output, and editing a configuration file. Those five cover most incidents.

Plain text configuration is a genuine advantage. Configuration can live in git, be reviewed in a pull request, and be applied by a script — which is what makes infrastructure as code possible.

Working as a normal user and using sudo only when needed is the standard discipline. Running everything as root is how a mistyped command deletes something important.

Common mistakes #

  • Assuming case insensitivity. Config.yml and config.yml are different files.
  • Running everything as root instead of using sudo for the commands that need it.
  • Editing configuration without keeping a copy, then having no way back.
  • Ignoring df -h until the disk is full and the service has already failed.
  • Searching the web for a flag when man or --help would answer faster.

Practice #

On any Linux machine or container, find out the distribution and version, the number of CPU cores, free memory and free disk. Then use a pipe to count how many lines in any log file contain the word "error", and explain each part of the pipeline.

Quick quiz

  1. 1. Where do configuration files usually live?

  2. 2. What does the pipe character do?

  3. 3. Which command shows free disk space?

  4. 4. Are Linux filenames case sensitive?

  5. 5. Why is plain text configuration an advantage?

Summary

  • Linux runs almost all servers, so basic fluency is unavoidable.
  • Everything hangs off a single root, with config in /etc and logs in /var/log.
  • Small tools combined with pipes solve most tasks.
  • Filenames are case sensitive.
  • Work as a normal user and use sudo only where required.