Linux

4 min read

Where DevOps actually happens

Most production Linux servers have no screen, no mouse, and no desktop — the terminal is the entire interface. Think of it as a very literal conversation: you type an instruction, press Enter, and it happens immediately. No confirmation dialogs, no "are you sure?" — which is exactly why the basics in this page matter before anything else in this guide.

Opening a terminal

On Linux or macOS, a Terminal app is already built in. On Windows, Windows Terminal or PuTTY both work, and WSL (Windows Subsystem for Linux) gives you a real Linux environment alongside it. Whichever you use, the commands you type from here on are identical — that's the whole point of a standard shell.

Connecting to a remote server: SSH

ssh alice@10.0.1.5              # connect as user "alice"
ssh alice@10.0.1.5 -p 2222      # a non-default port
ssh -i ~/.ssh/id_rsa alice@10.0.1.5   # connect using a specific key instead of a password

The first time you connect to a new server, SSH shows a host key fingerprint and asks whether to trust it — that's normal, and it's SSH's way of noticing if you ever connect to that same address and get a different server unexpectedly later.

Reading the prompt

alice@web-01:~$

sudo: borrowing admin power for one command

sudo systemctl restart nginx

sudo runs a single command with administrator privileges, then hands control straight back — rather than staying logged in as root the whole session. It asks for your own password, not root's, and every use gets logged, so there's a record of who ran what.

Your first ten minutes on a new server

Whenever you land on a machine you have not seen before, run the same short set of commands. They tell you what you are standing on, before you change anything. The values below are examples, and yours will differ.

whoami                       # root, or your own user? decides how careful to be
hostname -s                  # web-01     which machine is this, really?
grep PRETTY /etc/os-release  # PRETTY_NAME="Ubuntu 24.04 LTS"   which distribution and version
uname -sr                    # Linux 6.8.0-45-generic           the kernel
uptime -p                    # up 41 days, 3 hours              how long since a reboot
df -h /                      # Size 50G  Used 12G  Avail 36G  Use% 26%     is the disk filling up?
free -h                      # total 7.6Gi  used 693Mi  available 7.0Gi    memory
nproc                        # 4          how many CPU cores
ip -br a                     # lo UNKNOWN 127.0.0.1/8 ...   eth0 UP 10.0.1.5/24    its addresses

Each answers a question you would otherwise learn the hard way: a deploy that fails because the disk is 100 percent full, a command that behaves differently because it is a different distribution, a "fix" applied to the wrong server because you never checked the hostname. who shows who else is logged in, and last -n 5 shows the most recent logins.

Practise somewhere it is safe to break things

You learn the terminal fastest by trying things, and you should not learn on a production server. Pick one of these:

• WSL on Windows: a real Ubuntu, alongside your normal desktop.
• A virtual machine, or a small cloud VM that you can delete afterwards.
• A throwaway container, if Docker is installed:

docker run -it --rm ubuntu:24.04 bash

The last command drops you into a fresh Ubuntu shell. Everything you break there disappears when you type exit, which makes it perfect for practising commands like rm and chmod. Minimal images may lack tools such as man, nano or ip, so you may need apt-get update && apt-get install -y nano iproute2 first.

Command anatomy

ls -la /var/log

• ls — the command
• -la — flags (options) that change its behavior — here, "list format" and "include hidden files"
• /var/log — the argument: what to run it against