Linux for website builders

<section data-background="images/linux-for-website-builders/linux-for-website-builders.jpg" data-state="frontpage">
<div class="atitle2">Why website builders should know 
 <div class="atitle" style="font-size:200% !important">a bit of Linux</div>
 
 Stop clicking, start understanding
 
 by Peter Martin / <a href="https://db8.nl" target="_blank">db8.nl</a>
 
 slides: <a href="https://petermartin.nl" target="_blank">https://petermartin.nl</a>
 <style>.atitle{text-shadow: 2px 2px 2px #000;}
 .atitle2{text-shadow: 2px 2px 2px #000;}
 </style>
 <div style="margin: 0 auto;">
 <a href="https://db8.nl" title="Joomla Specialist db8 Nijmegen" target="_blank">
 <img height="50" style="border:0;background:transparent;margin-right:20px;
 box-shadow: 0 0 0 rgba(0, 0, 0, 0.15);" src="images/db8-logo.svg" alt="db8">
 </a>
 </div>
</div>

---

### Before we start

Who uses:
<ul>
<li class="fragment">cPanel, Plesk or DirectAdmin</li>
<li class="fragment">FileZilla or WinSCP</li>
<li class="fragment">Shared hosting or a VPS</li>
</ul>

Congratulations. 
You already use Linux every day.

Note:
Almost every hand goes up. The punchline: all those panels and hosts run Linux underneath. You're not learning a new OS today — you're learning to talk directly to the OS you already depend on, instead of clicking through a middleman.

----

### Overview

1. The Linux basics
2. The filesystem (spoiler: everything is a file)
3. Permissions & ownership
4. The Unix principle (= small tools with one task)
5. Practical examples: grep, rsync, bash
6. a bit more difficult: scripts, cron, Docker

**Easy first. Bit more difficult at the end.**

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 1: The Linux basics</div>
</div>

----

### Linux = The kernel

<a class="doclink" href="https://petermartin.nl/en/focus-on/linux/kernel" target="_blank" title="More about the kernel on petermartin.nl">📖 kernel</a>

The core of Linux. It talks to the hardware: 
memory, disks,
network, processes.

**Stable. Boring. Invisible.**

The same Linux kernel runs on your 
Android phone, router, Raspberry Pi, car navigation, 
mail server, and the server that hosts your website.

Note:
You will never touch the kernel directly. You just need to know it exists. Everything else — the terminal, the tools — is a layer on top of it.

----

### The distribution

Linux Kernel + tools + package manager + "opinions"

<table class="distrotable">
<thead>
<tr><th>Linux distribution</th><th>Commonly found on</th></tr>
</thead>
<tbody>
<tr><td>Ubuntu</td><td>Most VPS hosts, WSL</td></tr>
<tr><td>Debian</td><td>Shared hosting</td></tr>
<tr><td>Red Hat Enterprise Linux (RHEL)</td><td>Corporate data centres</td></tr>
<tr><td>AlmaLinux / Rocky Linux</td><td>cPanel servers</td></tr>
<tr><td>Alpine Linux</td><td>Docker containers</td></tr>
</tbody>
</table>

Note:
Your website is almost certainly running on one of these. Ask your host — they'll tell you. The differences matter less than you'd think: the commands in this talk work on all of them.

----

### The shell (terminal)

<a class="doclink" href="https://petermartin.nl/en/focus-on/linux/shell" target="_blank" title="More about the shell on petermartin.nl">📖 shell</a>

A text conversation with the operating system

```bash
$ pwd
/var/www/mysite

$ ls
administrator/  images/  templates/  index.php
```

You type something. 
The computer answers. 
That's all it is.

Note:
The terminal is the window, the shell is the conversation. The shell most servers use is called bash. Don't worry about the distinction — people use the words interchangeably.

----

### Your first five commands

<a class="doclink" href="https://petermartin.nl/en/focus-on/linux" target="_blank" title="All Linux commands on petermartin.nl">📖 commands</a>

```bash
pwd           # print working directory: where am I?
ls -lah       # list: what is here?
cd images/    # change directory: go somewhere
cat index.php # concatenate: show me a file
nano index.php # edit a file
```

**That's 80% of daily terminal use.**

Note:
Nano shows its commands at the bottom of the screen: Ctrl+O to save, Ctrl+X to exit. Start with nano, ignore vim discussions for now.

----

### The terminal types for you

```bash
cd /var/w<Tab> # completes to /var/www/
```

- `Tab` — autocomplete commands and paths
- `↑` — walk through previous commands
- `Ctrl+R` — search your command history
- `!!` — repeat the last command

Typing far less than you fear.

Note:
Live demo this — Tab completion alone removes the biggest beginner frustration: typing long paths without typos. Ctrl+R gets the biggest "wow": type a few letters, and last month's rsync command reappears.

----

### Getting onto your server: SSH

Secure SHell = shell on distant computer

≈ FileZilla for commands

```bash
ssh user@yourserver.com
```

Same credentials as SFTP. 
Most hosting panels can enable SSH access.

```bash
# secure copy one file over the same connection
scp backup.tar.gz user@yourserver.com:/tmp/
```

💻 live demo

Note:
If you use SFTP in FileZilla, you already have everything you need — SFTP runs over SSH. Live demo: log in to a real server here, run pwd and ls, nothing scary.

----

### Installing software

**The Windows/MacOS way:**

> Find website. Download installer. Hope it's not malware. Click next, next, next, finish.

**The Linux way:**

```bash
sudo apt install rsync
```

One curated, signed catalog: the repository.

Note:
sudo means "do this as administrator". apt is the package manager on Ubuntu/Debian. The repository model is why Linux servers stay clean: software comes from one trusted, maintained source.

----

### Open source

You already know this model: 
a repository is your CMS's extension directory, 
but for the whole server.

Linux is to operating systems what your CMS is to websites.

Same philosophy. Same licenses. 
Same community. Same reasons to trust it.

Note:
Nothing on this slide should surprise you — you build on open source every day. The whole stack underneath your site shares that ethos: Linux, Apache or nginx, PHP, MariaDB, your CMS. Curated, reviewed, one place to get it, and you can read the source when you need to. Learning Linux is not stepping outside your world; it is the same world, one layer down.

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 2: Everything is a file</div>
</div>

----

### The filesystem is one big tree

```
/          ← the root, everything starts here
├── etc/   ← configuration
├── home/  ← your files
├── var/
│   ├── www/ ← your websites
│   └── log/ ← the answers to your questions
└── tmp/   ← temporary files
```

No `C:\` drives. Everything hangs under `/`

Note:
For website builders, three places matter: /var/www (your site), /var/log (what went wrong), /etc (how the server is configured). Learn those three and you can find your way on any server.

----

### Everything is a file

- Configuration → a file
- Logs → a file
- Devices → a file
- Processes → a file
- Network connections → a file

**So every tool that works on files works on *everything*.**

Note:
This is the most useful sentence in web development. One mental model, infinite applications. The tools you learn for text files also inspect logs, config, even running processes under /proc.

----

### Why it matters for your website

```bash
# Your site's config? A file.
cat /var/www/mysite/configuration.php

# Why is the site broken? Read a file.
tail -f /var/log/apache2/error.log

# Where is that old domain still used? Search files.
grep -Rn "oldsite.com" /var/www/mysite
```

**Same tools. Three different jobs.**

💻 live demo

Note:
tail -f follows a log live: keep it open, reload the broken page, and watch the actual error appear. This alone replaces hours of guessing in a control panel. Demo: break a PHP file on the test site, reload, watch the fatal error scroll by.

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 3: Permissions & ownership</div>
</div>

----

### The three questions Linux asks

Every file. Every folder. Every time.

What can

1. the owner do?
2. the group do?
3. everyone else do?

For each: read, write, execute

----

### Reading `ls -l`

```bash
$ ls -l
-rw-r--r-- 1 peter www-data  1524 index.php
drwxr-xr-x 2 peter www-data  4096 images/
```

Owner: peter    Group: www-data

`-rw-r--r--` = 
owner `rw-` 
group `r--` 
others `r--`

----

### The octal numbers

| # | Rights | Meaning |
|----|----|----|
| 7 | `rwx` | read, write, execute |
| 6 | `rw-` | read, write |
| 5 | `r-x` | read, execute |
| 4 | `r--` | read only |
| 0 | `---` | nothing at all |

**755** = folders    **644** = files

Note:
r=4, w=2, x=1, add them up. 644: owner edits, everyone else reads. 755: same, but folders need x to be entered. Write these two numbers down — they solve most permission questions.

----

### chmod changes permissions

<a class="doclink" href="https://petermartin.nl/en/focus-on/linux/chmod" target="_blank" title="More about chmod on petermartin.nl">📖 chmod</a>

CHange file's permissions MODe

```bash
# Files: 644
find /var/www/mysite -type f -exec chmod 644 {} \;

# Folders: 755
find /var/www/mysite -type d -exec chmod 755 {} \;

# Your config file: 444 — read-only, even for you
chmod 444 /var/www/mysite/configuration.php
```

#### Never `chmod 777`

"Anyone on this server may do anything to this file"

Note:
444 on the config file is cheap insurance: it holds your database credentials, and nothing needs to write to it after installation. Your CMS will complain when it wants to change a setting — that is the point, you chmod it back to 644 for a minute and then lock it again. When a forum post says "just chmod 777" they are telling you to leave the front door open. More hacked sites trace back to 777 than to any other single cause. There is almost always a better answer — and it is usually ownership, next slide.

----

### chown changes owner

<a class="doclink" href="https://petermartin.nl/en/focus-on/linux/chown" target="_blank" title="More about chown on petermartin.nl">📖 chown</a>

CHange OWNership

```bash
sudo chown -R www-data:www-data /var/www/mysite
```

| Symptom | Real cause |
|----|----|
| "Cannot write to config" | wrong owner |
| Upload to images/ fails | wrong owner |
| Cache won't clear | wrong owner |

**90% of "permission" problems are ownership problems.**

Note:
The web server runs as a user, often www-data. If your files are owned by your FTP user, the web server cannot write to them. That's why uploads fail — not because the permission number is wrong.

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 4: Small tools, one task</div>
</div>

----

### The Unix philosophy

> "Make each program do one thing well."
> 
> — Doug McIlroy, Bell Labs, 1978

Older than the web.

Note:
The reason this idea survived: small tools that combine are more powerful than big tools that don't. Every impressive command you'll see next is just this idea applied.

----

### The pipe: `|`

connects 
the output of one tool to 
the input of the next tool

```bash
du -sh */ | sort -h
```

- `du -sh */` → size of every folder
- `sort -h` → sort by human-readable size

**"Which folder is eating my disk space?" — answered.**

Note:
Compare with the GUI way: right-click every folder, properties, write the number down... The pipe answers it in one line, sorted, on any server.

----

### grep — find text in files

g/re/p = command in old "ed" line editor

Global / Regular Expression / Print

```bash
# Which template file prints this string?
grep -Rn "Copyright 2019" /var/www/mysite

# How often was this IP in the access log?
grep "203.0.113.42" access.log | wc -l

# All PHP errors of today
grep "$(date +%d-%b-%Y)" error.log
```

Note:
grep -r searches recursively, -n shows line numbers. Combined with pipes you get instant answers to questions a control panel cannot even ask.

----

### Detective work: Was I hacked?

```bash
# Which files changed in the last 24 hours?
find . -type f -mtime -1

# Any suspiciously large files?
find . -type f -size +10M

# Look for a common PHP malware pattern
grep -Rn "eval(base64_decode" .
```

**Your control panel cannot answer these questions.**
**Be aware: mtime can be tampered with!**

Note:
This is the moment for the skeptics in the room. After a hack, the first question is always "what changed, and when?" — find answers it in seconds. These three commands are a real incident-response starter kit.

----

### Task: find the 10 biggest images on the site

GUI: open every folder in FileZilla, sort by size, write down, compare... ☠️

Linux:

```bash
find . -name "*.jpg" -size +1M | head -10
```

The terminal saves you hours of clicking.

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 5: Migrating with rsync</div>
</div>

----

### The FileZilla migration

<ul>
 <li>Download 20,000 files   (2 hours)</li>
 <li>Connection drops at 87%   (start over?)</li>
 <li>Upload 20,000 files   (3 hours)</li>
 <li>Which files failed?   (No idea.)</li>
</ul>

There has to be a better way

----

### rsync — copy, but smart

<a class="doclink" href="https://petermartin.nl/en/focus-on/linux/rsync" target="_blank" title="More about rsync on petermartin.nl">📖 rsync</a>

Remote SYNChronise

```bash
rsync -avz /var/www/mysite/ user@newserver:/var/www/mysite/
```

- Copies only what changed
- Survives dropped connections — just run it again
- Keeps permissions and timestamps
- Runs server-to-server, your laptop stays out of it

Note:
-a = archive (keep permissions, times, everything), -v = verbose, -z = compress. First run copies everything, second run only the differences — so you can pre-sync days before, and do the final sync in minutes during the maintenance window.

----

### Careful: the trailing slash

<a class="doclink" href="https://petermartin.nl/en/focus-on/linux/rsync" target="_blank" title="More about rsync on petermartin.nl">📖 rsync</a>

```bash
# Copies the CONTENTS of mysite/
rsync -av /var/www/mysite/  backup/

# Copies the folder mysite itself
rsync -av /var/www/mysite   backup/
```

One character difference. Test first with <code>--dry-run</code>

💻 live demo

Note:
This bites everyone once. --dry-run shows what would happen without doing it. Make it a habit for every rsync you did not run before. Demo: run the same rsync with and without the trailing slash in --dry-run mode and compare the file lists.

----

### The database comes along too

```bash
# Export on the old server
mysqldump -u dbusername -p dbname > my-db-export.sql

# Import on the new server
mysql -u dbusername -p dbname < my-db-export.sql
```

`>` and `<` redirect output and input, yes files again!

Note:
Note the theme: even the database export is just a file, moved with the same tools. rsync the .sql file across like everything else.

----

### Before you change anything

Small edit? Make it reversible:

```bash
cp configuration.php configuration.php.bak
nano configuration.php
diff configuration.php.bak configuration.php
```

Big change? Backup with today's date:

```bash
tar -czf site-$(date +%F).tar.gz /var/www/mysite
mysqldump -u user -p mydb > mydb-$(date +%F).sql
```

**The best admin is not fearless. 
The best admin is reversible.**

Note:
diff shows exactly what you changed — and the .bak file means any mistake is a one-command rollback. $(date +%F) puts today's date in the filename, so backups never overwrite each other. This habit costs ten seconds and saves weekends.

----

### The last step: the DNS switch

Files synced ✓   Database synced ✓   Now the domain:

```bash
# Which IP does the domain point to right now?
$ dig a petermartin.nl +short
203.0.113.42
```

Changed the DNS record? 
Watch it propagate, live:

```bash
watch dig a petermartin.nl
```

`watch` re-runs any command every 2 seconds

💻 live demo

Note:
dig asks the DNS directly — no "is it live yet?" guessing, no flush-your-cache voodoo. Leave watch running on the beamer and the whole room sees the old IP flip to the new one. Tip for real migrations: lower the record's TTL to 300 a day in advance, so the switch propagates in minutes instead of hours. And note watch itself: a small tool that does one thing — repeat another tool — the Unix philosophy again.

---

<div style="position:relative;height:600px;">
<div class="sheet">Part 6: a bit more difficult</div>
</div>

----

### A bash script = commands in a file

`backup.sh`:

```bash
#!/bin/bash

DATE=$(date +%Y%m%d)

mysqldump -u user -p"$PASS" mydb > /backup/db-$DATE.sql
tar -czf /backup/files-$DATE.tar.gz /var/www/mysite
rsync -az /backup/ user@backupserver:/backups/mysite/
```

```bash
chmod +x backup.sh   # remember execute permission?
./backup.sh
```

Note:
Nothing new here — three commands you've already seen, saved in a file. That x permission from part 3 is what makes a file runnable. This is where the earlier basics pay off.

----

### cron — run it every night

```bash
crontab -e
```

```bash
# min hour day month weekday   command
30 3 * * * /home/user/backup.sh
```

**Every night at 03:30. While you sleep.**

Note:
Five time fields, then the command. crontab.guru is a great site to decode the syntax. A nightly automated backup puts you ahead of most agencies.

----

### Docker, a server in a box

A complete test environment in seconds:

```bash
docker run -d -p 8080:80 joomla
```

- Try new CMS version **before** upgrading production
- Same environment on every developer's laptop
- Broke it? Delete it, start fresh

Note:
Docker packs an application plus its whole environment into a container. Under the hood it's pure Linux: kernel features, and yes — containers are configured with files. Show docker ps and docker logs if there's time.

----

### docker-compose — the whole stack

`docker-compose.yml`:

```yaml
services:
  web:
    image: joomla
    ports: ["8080:80"]
  db:
    image: mariadb
    environment:
      MYSQL_ROOT_PASSWORD: example
```

```bash
docker compose up -d
```

**Website + database. One file. One command.**

Note:
The configuration of the entire stack is — of course — a file. Which means you can version it in git, share it, and reproduce it anywhere. Everything is a file, all the way down.

----

### Five common mistakes

1. Running everything as root
2. "Just" `chmod 777`
3. No backup before editing
4. Editing production first
5. Ignoring the logs

Every one of them has a slide in this talk.

Note:
Quick recap disguised as a warning list: sudo for one-off commands only (part 1), ownership instead of 777 (part 3), backups (part 5), Docker as your test environment instead of production (part 6), and tail -f (part 2).

---

<div style="position:relative;height:600px;">
<div class="sheet">Monday morning</div>
</div>

----

### Windows: install WSL2

```powershell
wsl --install
```

Restart, open "Ubuntu" from the Start menu.

**Real Linux inside Windows. Free. Ten minutes.**

### macOS: Terminal is already there

`Cmd + Space` → "Terminal" → Enter

Note:
WSL2 is not a simulator — it's a real Linux kernel running inside Windows, built by Microsoft. For Mac users: macOS is a Unix, nearly all of this talk works out of the box.

----

### Three commands to try tonight

```bash
# Where am I, what is here?
pwd && ls -lah

# Read the manual of any command (q = quit)
man rsync

# Ask your host to enable SSH,
# then log in to your own server
ssh user@yourserver.com
```

----

### Take this home

Every command from this talk, on one page

<a href="https://petermartin.nl/en/focus-on/linux" target="_blank">petermartin.nl/en/focus-on/linux</a>

Note:
Leave this slide up during the questions — that is when people actually reach for their phone. If the venue lets you, put the printed cheat sheet in the conference bags as well.

---

<div style="position:relative;height:600px;">
<div class="sheet">Website broken...</div>
</div>

----

### Final exercise

> Client calls: *"The site is broken after the migration!"*

What do you check?

1. Can I get in? ssh
2. Are the files where I expect them? ls -lah
3. What do the logs say? tail -f error.log
4. Ownership and permissions OK? ls -l + chown
5. Did anything not arrive? rsync --dry-run

Note:
Let the audience shout answers before revealing the list. Every step uses a command from this talk — that's the point: they already know the whole diagnostic workflow now.

----

### The ideas to take home

- 1. Everything is a file

- 2. Small tools, pipe them together

- 3. Ownership before permissions, never 777

Every Linux trick you'll ever learn 
is one of these ideas in disguise.

----

### Your starter toolkit

`ssh` · `pwd` · `ls` · `cd` · `cat` · `nano`

`grep` · `find` · `tail` · `chmod` · `chown`

`rsync` · `mysqldump` · `dig` · `watch` · `docker`

**Sixteen commands. That was the whole talk.**

Note:
This slide doubles as the cheat sheet — photograph it. Point out that none of these commands is longer than six letters.

---

<div style="position:relative;height:600px;">
<div class="sheet">Questions?</div>
</div>

Note:
Common questions to prepare for:
- "Which distro?" → Ubuntu LTS on desktop/WSL; on the server, whatever your host runs.
- "Is the terminal dangerous?" → Only rm and anything with sudo. Read twice, press enter once.
- "How do I learn more?" → "The Linux Command Line" by William Shotts, free online.

</section>