To try the hands-on steps you will need a terminal. On Windows run
wsl --install in PowerShell; on a Mac use the Terminal app. Everything here is free.To try the hands-on steps you will need a terminal. On Windows run
wsl --install in PowerShell; on a Mac use the Terminal app. Everything here is free.DevOps runs on the Linux command line. You do not need to memorize the manual. Learn about fifteen commands well: moving around the filesystem, reading files, fixing permissions, and finding what broke. Everything else you look up as you go. Get comfortable in a black rectangle with a blinking cursor and the rest of this series stops feeling like twenty separate tools.
Who this is for: a college passout or career switcher who has used Windows or a Mac but never lived in a terminal, plus a developer who knows one language and now has to run the servers too.
Your first week on a DevOps team often looks like this. Someone drops a server address in chat, tells you the nightly deploy failed on that box, and moves on to the next thing. There is no dashboard. There is no button. There is no window to click. You open a terminal, connect over SSH, and you are standing in front of a blinking cursor with no idea where the file even is. Everything you do for the rest of that job starts here.
Part 3 mapped the eight stages of the DevOps loop and the tools that fill each one. Here is what nobody puts on the map. Every one of those tools, Git and Docker and Kubernetes and Terraform and Ansible, is driven from a command line that runs on Linux. Learn the shell and those tools stop being twenty things to memorize. They become twenty programs you talk to the same way.
Why DevOps lives in the terminal
A graphical interface is built for a human doing one thing once. The command line is built for a machine doing the same thing a thousand times. That difference is the whole reason DevOps prefers the terminal. A command can be saved in a file, checked into Git, run by a pipeline at 3am, and produce the exact same result every time. You cannot save a mouse click. When your job is to make deploys boring and repeatable, text you can script beats pixels you have to point at.
Here is what that failed deploy looks like when you connect to the box and start poking around. Read it top to bottom. The dollar sign is the prompt, and everything after it is what you typed.
$ ssh deploy@10.12.0.5
deploy@web-01:~$ pwd
/home/deploy
deploy@web-01:~$ cd /var/www/app
deploy@web-01:/var/www/app$ ls -l
total 16
drwxr-xr-x 4 deploy deploy 4096 Jul 2 21:14 releases
-rw-r--r-- 1 deploy deploy 812 Jul 2 21:14 deploy.sh
-rw-r--r-- 1 deploy deploy 240 Jul 1 09:02 .env
deploy@web-01:/var/www/app$ ./deploy.sh
bash: ./deploy.sh: Permission deniedIllustrative session. You connect, check where you are with pwd, move into the app folder, list what is there, and try to run the script. It refuses. Hold that error. We fix it further down.
Four commands got you oriented on a machine you had never touched: ssh to connect, pwd to see where you landed, cd to move, and ls -l to look. That is most of what navigation ever is.
The commands you use every single day
People new to Linux see thousands of commands and freeze. Ignore that number. In real DevOps work a small set does the vast majority of the job. Here is the set. Learn these and you can function on any Linux box on the planet.
| Command | What it does | Example |
|---|---|---|
cd | Change directory | cd /var/log |
ls | List files, add -l for detail | ls -l |
pwd | Print the folder you are in | pwd |
cat | Print a whole file | cat .env |
less | Page through a long file | less app.log |
grep | Search text inside files | grep error app.log |
tail | Show the end, -f to follow live | tail -f app.log |
find | Locate files by name or type | find . -name '*.yml' |
chmod | Change file permissions | chmod +x deploy.sh |
ps | List running processes | ps aux |
ss | Show sockets and open ports | ss -tulnp |
journalctl | Read logs from system services | journalctl -u nginx |
Those commands move you around a filesystem that follows the same layout on almost every Linux server. Knowing where things live means you can go straight to the right folder instead of hunting. Here are the four places you will visit most.
Reading a file without opening an editor
Half of DevOps troubleshooting is reading a file you did not write. For a short config, cat dumps the whole thing. For a log that is thousands of lines long, cat floods your screen and you learn nothing. Use less to scroll, or tail to see only the newest lines. When something is failing right now, tail -f follows the file live and prints each new line as the app writes it.
$ tail -n 3 app.log
2026-07-02 21:14:07 INFO starting worker pool size=4
2026-07-02 21:14:07 INFO listening on 0.0.0.0:8080
2026-07-02 21:14:12 ERROR db connect failed: connection refusedThree lines and you already know the app started fine and then could not reach its database. That is the command line earning its keep.
Files, permissions, and the error that stops every beginner
Go back to that Permission denied from the first session. It is the single most common wall a beginner hits, and once you understand it you will never be confused by it again. Every file on Linux carries permissions for three groups: the owner, the group, and everyone else. Each group gets three switches: read, write, and execute. The ls -l output shows all nine switches as a string at the start of the line.
The same permissions have a number form, and you will see both. Each switch is worth a value: read is 4, write is 2, execute is 1. Add them per group and you get a three digit number. So rwx is 7, r-x is 5, and rw- is 6. Here are the combinations you actually meet.
| Number | Looks like | Who can do what | Typical use |
|---|---|---|---|
755 | rwxr-xr-x | Owner full, others read and run | Scripts and folders |
644 | rw-r--r-- | Owner edits, others read | Normal files |
600 | rw------- | Owner only, nobody else | Secrets, .env, keys |
700 | rwx------ | Owner runs, nobody else | Private scripts |
Look again at the failing script in the first session. Its permission string was
-rw-r--r--, which is 644. Read yes, write yes, execute no. The x switch is off, so the shell refuses to run it. The fix is one command that flips the execute switch on:$ chmod +x deploy.sh$ ls -l deploy.sh-rwxr-xr-x 1 deploy deploy 812 Jul 2 21:14 deploy.sh$ ./deploy.shDeploying release 2026.07.02 ... doneNow the string reads
-rwxr-xr-x, the deploy runs, and the mystery is over. One more trap sits right next to this one. If you run deploy.sh with no ./ in front and get command not found, the shell is not looking in the current folder on purpose. The ./ tells it to run the file right here.One warning before you get chmod happy. Do not fix permission errors by running chmod 777, which grants everyone the right to read, write, and run the file. It looks like it solves the problem because the error goes away, but you just let any user or process on that machine rewrite your script and run it. That is how a small mistake becomes a security hole. Use 755 for scripts, 644 for files, and 600 for anything with a secret in it.
Finding what broke: processes, ports, and logs
When an app is down, three questions cover most of it. Is the process even running? Is it listening on the port it should be? What do the logs say? Three commands answer those three questions.
$ ps aux | grep node
deploy 4821 0.4 1.2 998412 51200 ? Sl 21:14 0:03 node server.js
$ ss -tulnp
Netid State Local Address:Port Process
tcp LISTEN 0.0.0.0:8080 users:(("node",pid=4821))
$ journalctl -u myapp --since "10 min ago" | grep -i error
Jul 02 21:14:12 web-01 myapp[4821]: ERROR db connect failed: connection refusedThe process is up. It is listening on 8080 as expected. The log says the real problem is the database refusing the connection, not the app itself. You just moved the investigation off your box and onto the database in three commands, without guessing once. Note ss here, not netstat. On current Linux systems netstat is deprecated and often not installed at all, while ss reads straight from the kernel and ships by default. The flags spell out the request: -t for TCP, -u for UDP, -l for listening only, -n for numeric ports, and -p to name the process.
The most useful single command for a listening-port audit is
ss -tulnp. Memorize that one string. When a service will not start with an address already in use error, this tells you in one line which process grabbed the port, and its pid, so you can stop guessing and go deal with it.Pipes: the one idea that makes the shell powerful
You already used a pipe twice above without me naming it. The vertical bar | takes the output of the command on its left and hands it straight to the command on its right as input. Small commands that each do one thing snap together into a tool that does exactly what you need. This is the core idea of the shell, and it is why old, simple commands never get retired.
A disk fills up and the server starts throwing errors. You need the biggest folders, fast. No single command does that, but three chained together do.
$ du -sh * | sort -h | tail -n 5
120M cache
340M uploads
512M node_modules
1.4G backups
6.2G logsdu -sh * measures the size of each item, sort -h orders those human readable sizes smallest to largest, and tail -n 5 keeps the last five. The logs folder is eating 6.2G. Problem found in one line. You did not learn a new command to do this. You combined three you already had, and that recombining is the skill that separates someone who survives on Linux from someone who is fluent.
The fifteen commands worth memorizing
A lot of Linux courses hand beginners a printout of two hundred commands and imply you must know them all before you are allowed to feel competent. That advice wastes your time. Nobody working in the field has all two hundred memorized. What they have is fluency in about fifteen, plus the habit of looking up the rest the second they need it. Every command carries its own manual: type man ss or ss --help and the flags are right there. Knowing a tool exists and how to read its help beats memorizing flags you use twice a year and forget.
So spend your effort in the right place. Drill the fifteen in the table above until they are muscle memory, because you type them fifty times a day and speed there compounds. For everything else, get comfortable saying I do not remember the exact flag, let me check, and then checking. That is not a gap in your knowledge. That is how the job is actually done.
A script gives you Permission denied when you run it. Walk me through what you check. A strong answer names the cause and the fix in one breath: run
ls -l to see the permissions, notice the missing x, run chmod +x to add execute, and run it with ./ in front so the shell looks in the current folder. Bonus points for adding that you would use 755 rather than 777, and why 777 is a security risk. Interviewers ask this because it is the exact wall a real beginner hits, and your answer tells them whether you have actually been on a box or only watched videos.No one expects a junior to be a shell wizard. They expect you to connect to a server, find your way to the right folder, read a log, and describe what you see without freezing. When a senior says the app is down on web-01, being able to SSH in and come back with the process is running but the log shows a database connection refused is worth more than any certificate. That one loop, connect, look, report, is the daily reality of the role, and it is built entirely on the commands in this part.
Free, about fifteen minutes, no cloud account needed. On Windows install WSL with
wsl --install from PowerShell, which gives you a real Ubuntu shell. On a Mac the Terminal app is already a Unix shell. Then do this: make a folder, create a file called hello.sh containing echo hello from the shell, and try to run it with ./hello.sh. Watch it fail with Permission denied. Run chmod +x hello.sh, run it again, and watch it print. How to check you did it right: ls -l hello.sh shows rwx at the front and the script prints its line. You just reproduced and fixed the most common Linux error there is.Command line questions beginners actually ask
Which Linux distribution should I learn on?
Ubuntu, for one practical reason: most tutorials, cloud images, and container base images assume it, so your commands match what you read. The everyday commands in this part are identical across Ubuntu, Debian, Fedora, and Amazon Linux anyway. The differences only show up in how you install packages, and you can learn that later.
Do I need to learn shell scripting, or just commands?
Commands first, and get fluent there. Scripting is just putting those same commands into a file so they run in order without you. Once typing the commands feels natural, wrapping a few into a .sh file is a small step, and that is the moment your manual chores start becoming automation.
What is the difference between cat, less, and tail?
All three read files. cat dumps the whole thing at once, fine for short files. less lets you scroll a long file up and down and quit with q. tail shows only the end, and tail -f keeps printing new lines as they arrive, which is what you want when watching a live log during a deploy.
Is it dangerous to practice on a real server?
Practice on a throwaway one first. Use WSL, a local virtual machine, or a free tier cloud box you can delete. The commands here are safe to read and inspect with, but a mistyped rm on a production box is unforgiving, so build your reflexes somewhere nothing matters before you touch anything that does.
Get these commands into your fingers and the rest of this series lands on solid ground. Next up is Part 5 on Git and version control, the tool that tracks every change you and your team make. Git runs from this same command line, so the comfort you build here pays off immediately.
New to the series? Start with Part 1 on what DevOps actually means and the Part 3 toolchain map. If you want the language side too, the Python for Beginners series and the Cloud for Beginners series pair well with this one.
References
GNU Coreutils manual
ss command manual page
Install Linux with WSL on Windows
About The Author
DrJha