Ubuntu szerver + HestiaCP — telepítés és optimalizálás

01-bevezetesBevezetés és architektúra

Ez a kézikönyv egy teljes, éles üzemre szánt webszerver felépítését dokumentálja. A célkitűzés konkrét: 10–20 weboldal (jellemzően WordPress, Laravel vagy statikus oldalak) és a hozzájuk tartozó teljes levelezés kiszolgálása egyetlen szerveren, úgy, hogy a rendszer évekig karbantartható maradjon.

A dokumentáció nem csak kezdőknek szól. A HestiaCP telepítője kiváló alapot ad, de alapértelmezésben konzervatív: olyan beállításokkal indul, amelyek egy 1 GB RAM-os minigépen is elműködnek. A mi gépünk ennél sokkal erősebb, ezért a könyv jelentős része arról szól, hogyan hangoljuk a komponenseket a tényleges hardverhez és terheléshez.

Hogyan épül fel a kérés útja?

A HestiaCP által épített stack úgynevezett hibrid architektúra. Egy beérkező HTTP-kérés a következő láncon halad végig:

Böngésző
   │  :80 / :443  (TLS-terminálás itt történik)
   ▼
NGINX  — reverse proxy, statikus fájlok, cache, gzip/brotli
   │  :8080 / :8443  (csak localhost)
   ▼
APACHE — .htaccess feldolgozás, rewrite szabályok
   │  unix socket
   ▼
PHP-FPM 8.3 — alkalmazáslogika (pool-onként izolálva)
   │
   ├──▶ MariaDB  (adat)
   └──▶ Redis    (cache, session)

A könyv jelölésrendszere

• A terminál-blokkok másolható parancsokat tartalmaznak. A # kezdetű sorok magyarázó kommentek.
• A MIÉRT? dobozok a döntések mögötti indoklást adják — ez a könyv lelke.
• A FIGYELEM dobozok olyan pontokat jelölnek, ahol hibázni adatvesztést vagy kizárást okozhat.
• Minden fejezet végén ellenőrzés: hogyan győződj meg róla, hogy amit beállítottál, tényleg él.

02-netcup-rsA Netcup RS 1000 G12

Az RS („root server") sorozat a Netcup kínálatában a klasszikus VPS-ek fölött helyezkedik el: itt nem másokkal osztott vCore-okat, hanem dedikált CPU-magokat kapunk. A gépünk kiépítése:

Mit ad a dedikált mag a gyakorlatban?

Egy hagyományos VPS-en a vCore-okon a szomszédokkal osztozol: ha ők pörögnek, a te folyamataid várnak — ez a CPU steal. Dedikált magoknál ez a jelenség megszűnik: a teljesítmény kiszámítható, forgalmi csúcsban is. Ellenőrizni bármikor tudod:

top -bn1 | grep '%Cpu'   # az "st" (steal) értéke dedikált magokon ~0.0
nproc                     # → 4
dpkg --print-architecture # → amd64

A 4 mag kevesebbnek tűnhet, mint egyes VPS-ek 6–8 vCore-ja — de a mi terhelésünknél (sok párhuzamos, rövid PHP-kérés) 4 garantált EPYC-mag többet ér, mint 8 bizonytalan. A könyv CPU-érzékeny beállításai (Nginx workerek, Apache szálak) a 4 maghoz igazodnak.

Miért érdekes az ECC RAM?

A Netcup SCP és az első teendők a panelen

A Netcup SCP (Server Control Panel) a hoszting-szolgáltató saját felülete — nem keverendő a később telepítendő HestiaCP-vel. Az SCP-ben három dolgot intézz el még az OS telepítése előtt/közben:

1. Ubuntu 24.04 LTS image telepítése. Válaszd a minimál/serveres változatot, felesleges desktop-csomagok nélkül.
2. rDNS (PTR) rekord beállítása. Az SCP hálózati beállításainál a szerver IPv4 (és IPv6) címéhez rendeld hozzá a leendő hosztnevet, pl. srv1.pelda.hu. Erre a 14. fejezetben, a levelezésnél lesz égető szükség.
3. Snapshot-stratégia. Ismerd meg a snapshot funkciót: a nagy beavatkozások előtt (Hestia telepítés, verzióváltások) készíts pillanatképet. A snapshot nem mentés (ugyanazon a tárolón él), de az „elrontottam a telepítést" típusú hibáknál percek alatt visszaállít.

03-ubuntu-alapokUbuntu 24.04 — első lépések

Az első SSH-belépéstől a "Hestia-kész" állapotig. Minden lépés sorrendje szándékos: előbb zárjuk a kaput, aztán rendezkedünk be.

Frissítés és alapcsomagok

# Teljes frissítés — friss image-nél is kötelező
apt update && apt full-upgrade -y

# Alapeszközök, amikre a könyvben építünk
apt install -y curl wget git htop iotop ncdu unzip \
  ca-certificates gnupg lsb-release

# Újraindítás, ha kernel is frissült
[ -f /var/run/reboot-required ] && reboot

Hostname és FQDN — a levelezés alapköve

A szervernek teljes, feloldható domainnevet (FQDN) adunk, pl. srv1.pelda.hu. Ez lesz a Hestia panel címe és az Exim HELO-neve is.

hostnamectl set-hostname srv1.pelda.hu

# /etc/hosts — a saját IP-hez az FQDN kerüljön ELSŐ helyre
# 203.0.113.10  srv1.pelda.hu  srv1
nano /etc/hosts

# Ellenőrzés — mindkettőnek helyes értéket kell adnia:
hostname -f        # → srv1.pelda.hu
hostname -s        # → srv1

Ezzel párhuzamosan a DNS-zónádban vedd fel az A (és ha van IPv6, az AAAA) rekordot: srv1.pelda.hu → 203.0.113.10. A kör akkor zárul, ha a 2. fejezetben beállított PTR is erre a névre mutat vissza.

Sudo-felhasználó és SSH-kulcsos belépés

# Saját admin user létrehozása
adduser deploy
usermod -aG sudo deploy

# A SAJÁT GÉPEDEN: kulcspár generálása (ha még nincs)
#   ssh-keygen -t ed25519 -C "deploy@srv1"
# majd a publikus kulcs feltöltése:
#   ssh-copy-id deploy@srv1.pelda.hu

# Teszteld ÚJ terminálból, hogy kulccsal be tudsz-e lépni,
# MIELŐTT a jelszavas belépést kikapcsolod!

SSH hardening

Ubuntu 24.04-en az OpenSSH konfigurációt drop-in fájlban tartjuk karban — így a csomagfrissítések nem írják felül:

PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LoginGraceTime 20
AllowUsers deploy
X11Forwarding no

sshd -t && systemctl restart ssh   # -t: szintaktikai teszt ELŐBB

Kell-e portot cserélni?

Megosztó kérdés. Mellette: a 22-es portot bombázó automata botok zaját 95%-kal csökkenti, tisztábbak a logok, kevesebb fail2ban-esemény. Ellene: biztonságot érdemben nem ad (a portscan másodpercek alatt megtalálja), és minden kliensben, scriptben, mentésben konfigurálni kell. A könyv álláspontja: kulcsos belépés + fail2ban mellett a 22-es port maradhat; ha a logzaj zavar, tedd át (pl. 2222), de tudd, hogy ez kényelmi, nem biztonsági intézkedés.

Időzóna és NTP

timedatectl set-timezone Europe/Budapest
timedatectl                     # "System clock synchronized: yes" kell
systemctl status systemd-timesyncd

04-hardeningHardening még Hestia előtt

A Hestia telepítője maga is beállít tűzfalat és fail2bant — ezekhez nem nyúlunk előre. Amit viszont az OS szintjén most érdemes rendezni: automatikus biztonsági frissítések, memóriakezelés és néhány kernel-paraméter.

Automatikus biztonsági frissítések

apt install -y unattended-upgrades
dpkg-reconfigure -plow unattended-upgrades   # → Yes

// Csak a security csatorna települjön automatikusan —
// a sima frissítéseket ütemezetten, kézzel visszük fel (19. fejezet)
Unattended-Upgrade::Allowed-Origins {
    "${distro_id}:${distro_codename}-security";
};
Unattended-Upgrade::Automatic-Reboot "false";
Unattended-Upgrade::Remove-Unused-Dependencies "true";

Swap-stratégia: zram + kis biztonsági swapfile

8 GB RAM-nál a swap szerepe nem a "kevés a memória" kezelése, hanem a OOM-killer elleni védőháló és a ritkán használt lapok kiszorítása. SSD-s VPS-en a legjobb kombináció:

# 1) zram: tömörített, RAM-beli swap — gyors, nem koptatja az SSD-t
apt install -y zram-tools
sed -i 's/#PERCENT=.*/PERCENT=25/' /etc/default/zramswap
systemctl restart zramswap

# 2) 2 GB-os hagyományos swapfile, alacsony prioritással — vészhelyzetre
fallocate -l 2G /swapfile
chmod 600 /swapfile
mkswap /swapfile && swapon /swapfile
echo '/swapfile none swap sw,pri=1 0 0' >> /etc/fstab

# 3) Kernel: csak tényleg szükség esetén swapoljon
cat > /etc/sysctl.d/90-swap.conf << 'EOF'
vm.swappiness = 10
vm.vfs_cache_pressure = 50
EOF
sysctl --system

swapon --show   # zram magas, swapfile alacsony prioritással

Hálózati sysctl-alapok

# Nagyobb kapcsolat-várólisták forgalmi csúcsokhoz
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096

# TIME_WAIT socketek gyorsabb újrahasznosítása (kimenő oldalon)
net.ipv4.tcp_tw_reuse = 1
net.ipv4.ip_local_port_range = 10240 65000

# BBR torlódásvezérlés — jobb átvitel távoli/mobil kliensek felé
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

sysctl --system
sysctl net.ipv4.tcp_congestion_control   # → bbr

Ellenőrzés a rész végén: hostname -f helyes; kulcsos SSH él, jelszavas nem; swapon --show két bejegyzés; sysctl net.ipv4.tcp_congestion_control = bbr. Ha mind rendben — jöhet a Hestia. Most készíts snapshotot az SCP-ben.

05-telepito-flagekA telepítő flagek anatómiája

A telepítő letöltése

cd /root
wget https://raw.githubusercontent.com/hestiacp/hestiacp/release/install/hst-install.sh

# Nézd meg, mit fogsz futtatni — sose futtass vakon letöltött scriptet
less hst-install.sh

A mi telepítési parancsunk

bash hst-install.sh \
  --apache yes \
  --phpfpm yes \
  --multiphp yes \
  --mysql yes \
  --postgresql no \
  --exim yes \
  --dovecot yes \
  --sieve yes \
  --clamav no \
  --spamassassin no \
  --rspamd yes \
  --vsftpd no \
  --proftpd no \
  --named yes \
  --iptables yes \
  --fail2ban yes \
  --quota yes \
  --api yes \
  --port 8083 \
  --hostname srv1.pelda.hu \
  --email admin@pelda.hu \
  --lang hu

Kapcsolónkénti indoklás

Mit csinál a telepítő a háttérben?

Érdemes tudni, mihez nyúl a script, mert később ezekkel a mechanizmusokkal élünk együtt:

• Csomagtárolók: hozzáadja a Hestia APT repót és a ppa:ondrej/php-t (a multiphp PHP-verziók forrása), majd telepíti a kiválasztott komponenseket.
• Template-rendszer: a /usr/local/hestia/data/templates/ alá kerülnek a web- (Nginx/Apache/FPM), DNS- és mail-sablonok. Minden domain konfigurációja ezekből generálódik — ez a kulcs a 7–9. fejezet testreszabásaihoz: sosem a generált fájlt, hanem a sablont módosítjuk.
• Cron-jobok: a v-update-sys-queue, napi mentés, Let's Encrypt megújítás, statisztikák — crontab -l -u hestiaadmin (vagy admin) alatt láthatók.
• iptables + fail2ban: saját láncokat és jail-eket hoz létre (SSH, Exim, Dovecot, Hestia panel), amiket a panel Firewall menüje kezel.
• Saját szolgáltatás: a panel maga egy külön PHP-FPM + Nginx példányon fut a 8083-as porton, a rendszer többi részétől elszigetelve.

06-elso-teendokTelepítés utáni első teendők

Belépés és admin-higiénia

1. Lépj be: https://srv1.pelda.hu:8083 — az első alkalommal a böngésző tanúsítványhibát jelez, ez normális, még önaláírt a cert.
2. Változtasd meg az admin jelszót a telepítő által generáltról, és kapcsold be a kétfaktoros hitelesítést (Felhasználó → Szerkesztés → OTP).
3. Állítsd a panel nyelvét/időzónáját, ha a telepítő nem jól találta el.

Let's Encrypt a panelre és a mail-szolgáltatásokra

# Feltétel: srv1.pelda.hu A-rekordja már a szerverre mutat!
v-add-letsencrypt-host

# Ellenőrzés
v-list-sys-hestia-ssl | head

Az első felhasználó és weboldal — tudatosan

# Új user + első domain (a panelen is megtehető, CLI-ből gyorsabb)
v-add-user ugyfel1 'ErősJelszó-ide' ugyfel1@pelda.hu default "Ugyfel Egy"
v-add-domain ugyfel1 pelda.hu

# Let's Encrypt az oldalra, www-vel együtt
v-add-letsencrypt-domain ugyfel1 pelda.hu www.pelda.hu

DNS-ellenőrzőlista domainenként

• A rekord: pelda.hu → 203.0.113.10 (+ www)
• MX rekord: pelda.hu → mail.pelda.hu, és mail.pelda.hu A-rekordja a szerverre
• SPF / DKIM / DMARC — a 14. fejezet szerint
• PTR a szerver IP-jén: srv1.pelda.hu (Netcup SCP)

Gyorsteszt

# Fut minden szolgáltatás?
v-list-sys-services

# A lánc él? (fejlécekből látszik: nginx elöl, mögötte apache)
curl -sI https://pelda.hu | head -8

# Memóriahelyzet a kiinduló állapotban — jegyezd fel viszonyítási alapnak
free -h && systemd-cgtop --depth=1 -n 1

Ha minden zöld: a szerver működik. A következő rész arról szól, hogyan lesz belőle gyors.

07-nginxNginx — a kapuőr

Hová nyúlhatunk biztonságosan?

Globális finomhangolás

worker_processes     auto;              # = dedikált magok száma (4)
worker_rlimit_nofile 65535;

events {
    worker_connections 8192;            # default 1024-ről fel
    multi_accept       on;
}

http {
    # Fájlküldés kernel-szinten
    sendfile           on;
    tcp_nopush         on;

    # Kapcsolat-újrahasznosítás: kevesebb TLS-kézfogás
    keepalive_timeout  30s;
    keepalive_requests 1000;

    # Gzip — szöveges tartalomra, értelmes szinten
    gzip               on;
    gzip_comp_level    5;
    gzip_min_length    1024;
    gzip_types         text/css application/javascript application/json
                       image/svg+xml application/xml text/plain;
    gzip_vary          on;
}

Proxy cache — a Hestia rejtett fegyvere

A Hestia beépítve tudja az Nginx proxy cache-t: a dinamikus (Apache/PHP által generált) válaszokat rövid ideig memóriában/diszken tartja, és a következő látogatónak PHP érintése nélkül adja vissza.

# Cache-támogatás globális bekapcsolása (ha a panelen még nincs)
v-add-sys-web-cache

# Bekapcsolás egy domainre, 2 perces érvényességgel
v-add-web-domain-proxy-cache ugyfel1 pelda.hu 2m

# A panelen: WEB → domain → Edit → Proxy Template: "caching"

Saját sablon: statikus fájlok agresszív cache-elése

Sablont mindig másolatból szerkesztünk:

cd /usr/local/hestia/data/templates/web/nginx
cp default.tpl  custom-static.tpl
cp default.stpl custom-static.stpl   # az .stpl az SSL-es változat

Mindkét fájlba, a location / blokk elé:

location ~* \.(css|js|jpg|jpeg|png|gif|webp|avif|svg|ico|woff2?)$ {
    root       %sdocroot%;
    expires    30d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

Ezután a panelen a domain Web Template-jét állítsd custom-static-ra, vagy CLI-ből: v-change-web-domain-tpl ugyfel1 pelda.hu custom-static.

Ellenőrzés

nginx -t && systemctl reload nginx

# Statikus fájl: az Expires/Cache-Control fejlécnek látszania kell
curl -sI https://pelda.hu/wp-content/valami.css | grep -iE 'cache|expires'

# Proxy cache működik? (X-Cache: HIT a 2. kéréstől)
curl -sI https://pelda.hu/ | grep -i x-cache

08-apacheApache — a .htaccess-motor

Az Apache nálunk belső munkás: csak a localhost 8080/8443-on figyel, kizárólag az Nginxtől kap kérést. Ehhez a szerephez igazítjuk.

MPM event + HTTP/1.1 keepalive a proxy felé

A Hestia PHP-FPM-es telepítése az mpm_event-et használja (ellenőrzés: apachectl -V | grep MPM) — ez a helyes: a PHP nem az Apache folyamataiban fut, így az Apache szálai csak a kérés-továbbítást végzik, olcsón.

<IfModule mpm_event_module>
    ServerLimit              8
    ThreadsPerChild          64
    MaxRequestWorkers        512
    MaxConnectionsPerChild   10000
</IfModule>

# A proxy mögött a keepalive olcsó és hasznos
KeepAlive            On
KeepAliveTimeout     5
MaxKeepAliveRequests 500

# Információ-szivárgás csökkentése
ServerTokens Prod
ServerSignature Off
TraceEnable Off

a2enconf tuning && apachectl configtest && systemctl reload apache2

mod_remoteip — valódi látogatói IP-k

Proxy mögött az Apache alapból mindenhol a 127.0.0.1-et látná kliens-IP-ként. A Hestia ezt jellemzően előre bekonfigurálja (remoteip modul + a Nginx által küldött X-Real-IP), de ellenőrizd, mert e nélkül a WordPress-bővítmények, a naplók és a fail2ban is vakok:

apachectl -M | grep remoteip          # remoteip_module (shared)
cat /etc/apache2/mods-enabled/remoteip.conf
# Elvárt tartalom:
#   RemoteIPHeader X-Real-IP
#   RemoteIPInternalProxy 127.0.0.1

# Teszt: a domain access logjában valós IP-k jelenjenek meg
tail -3 /var/log/apache2/domains/pelda.hu.log

Felesleges modulok

# Mi töltődik most?
apachectl -M | sort

# Tipikusan kikapcsolható (ha egyik oldalad sem használja):
a2dismod -f autoindex status cgid
apachectl configtest && systemctl reload apache2

09-php-fpmPHP 8.3 és PHP-FPM — ahol a RAM eldől

A PHP-FPM a szerver legnagyobb memóriafogyasztója és a teljesítmény kulcsa. A Hestia userenként/domainenként külön poolt hoz létre — ez kiváló izoláció, de az alapértékek óvatosak. Itt számolunk.

A méretezés képlete

Teljes RAM                                8192 MB
  − rendszer + Hestia + Nginx + Apache   −  900 MB
  − MariaDB (10. fejezet)                − 2600 MB
  − Redis (11. fejezet)                  −  300 MB
  − levelezés (Exim+Dovecot+Rspamd)      −  500 MB
  − biztonsági tartalék                  −  700 MB
  ─────────────────────────────────────────────────
  PHP-FPM-nek marad                      ≈ 3200 MB

Egy WP/Laravel FPM-child átlagosan:       60–80 MB
  → összes child-plafon a szerveren:  3200/80 ≈ 40

ps --no-headers -o rss,cmd -C php-fpm8.3 | grep -v master \
  | awk '{sum+=$1; n++} END {printf "átlag: %.0f MB (n=%d)\n", sum/n/1024, n}'

ondemand — a helyes process manager 10–20 oldalhoz

A Hestia FPM-sablonjai a /usr/local/hestia/data/templates/web/php-fpm/ alatt élnek. Készítsünk sajátot:

cd /usr/local/hestia/data/templates/web/php-fpm
cp default.tpl custom-ondemand.tpl

pm = ondemand
pm.max_children = 12          ; PLAFON poolonként — nem előre lefoglalt!
pm.process_idle_timeout = 10s ; ennyi tétlenség után a child leáll
pm.max_requests = 1000        ; memószivárgás-higiénia

php_admin_value[memory_limit] = 256M
php_admin_value[max_execution_time] = 60
request_terminate_timeout = 90s
slowlog = /var/log/php8.3-fpm-%pool.slow.log
request_slowlog_timeout = 5s

Hozzárendelés: panelen a domain Backend Template-je, vagy v-change-web-domain-backend-tpl ugyfel1 pelda.hu custom-ondemand.

OPcache — a legolcsóbb 3× gyorsulás

opcache.enable = 1
opcache.memory_consumption = 256      ; MB — 15-20 oldal kódja beleférjen
opcache.interned_strings_buffer = 32
opcache.max_accelerated_files = 50000 ; egy WP+pluginok ~10-20e fájl
opcache.validate_timestamps = 1
opcache.revalidate_freq = 60          ; mp-enként max 1× stat-ol fájlonként
opcache.save_comments = 1             ; annotációkhoz (Doctrine/Laravel) kell

; realpath cache — fájlútvonal-feloldások gyorsítótára
realpath_cache_size = 4M
realpath_cache_ttl  = 120

; éles szerveren a hibát naplózzuk, nem kirajzoljuk
display_errors = Off
log_errors = On

php-fpm8.3 -t && systemctl reload php8.3-fpm

# OPcache-kihasználtság élőben (bármely oldal alá tett opcache-status is jó)
php -r 'print_r(opcache_get_status(false)["memory_usage"]);'

Per-site PHP-verziók

A multiphp miatt bármely domainhez választható 8.1/8.2/8.3 backend a panelen. A fenti tuning-fájlokat minden használt verzió conf.d-jébe másold be (/etc/php/8.2/fpm/conf.d/ stb.) — az OPcache memória verziónként külön él, ezért ha csak 1–2 oldal fut régi verzión, azok bufferét vedd kisebbre (pl. 96 MB).

10-mariadbMariaDB — az adatbázis-réteg

Az Ubuntu 24.04 MariaDB 10.11 LTS-t ad. A disztribúciós alapkonfig szinte üres — minden fontos érték a beépített defaulton áll, ami egy 512 MB-os gépre van belőve. Itt hozzuk a legtöbb "ingyen" sebességet.

A saját konfigfájlunk

Nem a meglévő fájlokat szerkesztjük, hanem saját, magas sorszámú drop-int teszünk melléjük — csomagfrissítés-biztosan:

[mysqld]
# ---- InnoDB: a lényeg ----
innodb_buffer_pool_size   = 2G      # lásd a MIÉRT dobozt
innodb_redo_log_capacity  = 512M    # írás-intenzív csúcsok elsimítása
innodb_flush_method       = O_DIRECT
innodb_flush_log_at_trx_commit = 1  # teljes tartósság (lásd lentebb)

# ---- Kapcsolatok, ideiglenes táblák ----
max_connections    = 150
tmp_table_size     = 64M
max_heap_table_size = 64M
table_open_cache   = 4000

# ---- Lassú lekérdezések naplója: a diagnózis alapja ----
slow_query_log      = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time     = 1
log_queries_not_using_indexes = 0

mkdir -p /var/log/mysql && chown mysql:mysql /var/log/mysql
systemctl restart mariadb
mariadb -e "SELECT @@innodb_buffer_pool_size/1024/1024 AS buffer_MB;"

mysqltuner — a visszajelző hurok

apt install -y mysqltuner
# Csak legalább 1-2 hét ÉLES futás után ad értelmes javaslatot!
mysqltuner

Hogyan olvasd a kimenetét:

• InnoDB buffer pool hit rate: 99% fölött egészséges. Ha alatta van és van szabad RAM-költségvetés, emeld a poolt 512 MB-os lépésekben.
• Created_tmp_disk_tables aránya: ha magas, a rendezések diszkre lógnak ki — tmp_table_size emelése vagy (gyakrabban!) a bűnös lekérdezés indexelése segít.
• Max connections used: ha a 150-et súrolja, előbb az FPM-plafonokat nézd (9. fejezet) — a DB-kapcsolatszám a PHP-childok tükre.
• A javaslatait ne másold vakon: a tuner nem tudja, hogy a RAM-on másokkal osztozol.

A slow log feldolgozása

# Top lekérdezések összesítve (a mariadb-server része)
mariadb-dumpslow -s t -t 10 /var/log/mysql/slow.log

# Egy kiszúrt lekérdezés boncolása:
mariadb nevezetes_db -e "EXPLAIN SELECT ...\G"

11-redisRedis — memória-cache és session-tár

A Redis-t a Hestia nem telepíti — ez az első komponens, amit teljesen mi adunk a rendszerhez. Két feladatot kap: object cache (az alkalmazások ismétlődő DB-lekérdezéseinek eredményét tartja RAM-ban) és PHP session-tár.

apt install -y redis-server php8.3-redis
systemctl enable --now redis-server

Konfiguráció: socket, memóriaplafon, kiszorítás

# Csak lokálisan, unix socketen — TCP-port ki
port 0
unixsocket /var/run/redis/redis-server.sock
unixsocketperm 770

# Memóriaplafon + kiszorítási politika
maxmemory 256mb
maxmemory-policy allkeys-lru

# Cache-hez nem kell tartósság — diszk-I/O nullázása
save ""
appendonly no

# A webes felhasználók érjék el a socketet
usermod -aG redis www-data
systemctl restart redis-server
redis-cli -s /var/run/redis/redis-server.sock ping   # → PONG

PHP sessionök Redisben

session.save_handler = redis
session.save_path = "unix:///var/run/redis/redis-server.sock?database=1"
session.gc_maxlifetime = 86400

WordPress és Laravel bekötés

// Redis Object Cache plugin telepítése után:
define('WP_REDIS_SCHEME', 'unix');
define('WP_REDIS_PATH', '/var/run/redis/redis-server.sock');
define('WP_REDIS_DATABASE', 0);
define('WP_REDIS_PREFIX', 'pelda_hu:');   // OLDALANKÉNT EGYEDI!

CACHE_STORE=redis
SESSION_DRIVER=redis
REDIS_CLIENT=phpredis
REDIS_SCHEME=unix
REDIS_PATH=/var/run/redis/redis-server.sock
REDIS_PREFIX=appnev:

Ellenőrzés

redis-cli -s /var/run/redis/redis-server.sock info stats \
  | grep -E 'keyspace_(hits|misses)'
# Egészséges arány beüzemelés után: hits ≫ misses (90%+ hit rate)
redis-cli -s /var/run/redis/redis-server.sock info memory | grep used_memory_human

12-cache-lancA teljes cache-lánc — összeáll a kép

Az előző öt fejezet rétegei együtt alkotnak rendszert. Egy kérés a leggyorsabb rétegnél áll meg, amelyik ki tudja szolgálni:

1. Böngésző-cache      expires/immutable      → 0 ms, a kérés el sem indul
2. Nginx statikus      css/js/kép a diszkről   → ~1 ms, PHP nem érintett
3. Nginx proxy cache   kész HTML 1-2 percig    → ~1 ms, PHP nem érintett
4. OPcache             PHP bytecode RAM-ból    → fordítás megspórolva
5. Redis object cache  DB-eredmények RAM-ból   → SQL megspórolva
6. InnoDB buffer pool  adat-lapok RAM-ból      → diszk-I/O megspórolva
7. Diszk               a végső igazságforrás

WordPress-specifikus ajánlások

• Object cache: Redis Object Cache plugin (11. fejezet szerint, egyedi prefixszel).
• Page cache plugin: a Nginx proxy cache mellett a legtöbb oldalnak nem kell külön page-cache plugin — kettős HTML-cache csak az invalidálást bonyolítja. Ha mégis (pl. bejelentkezett-felhasználó-tudatos cache kell), válassz egyet, és a proxy cache-t arra a domainre kapcsold ki.
• Cron: a WP-cron minden látogatásnál ellenőrzést futtat, cache-elt oldalon pedig ki is éhezhet. Tedd rendszer-cronra:
  root@vps

  # wp-config.php-be: define('DISABLE_WP_CRON', true);
  # a user cronjába (v-add-cron-job vagy panel):
  */5 * * * * cd /home/ugyfel1/web/pelda.hu/public_html && php wp-cron.php

Mérés — bizonyíték, nem benyomás

apt install -y apache2-utils
# 200 kérés, 20 párhuzamosan — először hideg, majd meleg cache-sel
ab -n 200 -c 20 https://pelda.hu/ | grep -E 'Requests per|Time per'

Tipikus eredmény ezen a stacken: cache nélkül 30–60 req/s (PHP-limitált), az Nginx proxy cache-sel 2000+ req/s. Ezt a mérést dokumentáld — a 19. fejezet havi rutinjában viszonyítási alap lesz.

13-exim-dovecotExim és Dovecot — a gépezet

Ki mit csinál?

BEJÖVŐ:  internet ──:25──▶ Exim ──▶ Rspamd (pontozás)
                              │
                              ▼ LMTP/pipe
                          Dovecot ──▶ /home/user/mail/... (Maildir)
                              │  + Sieve szűrők (Spam mappába rendezés)
                              ▼
KLIENS:  IMAP :993 / Roundcube ◀── Dovecot

KIMENŐ:  kliens ──:587 (submission, auth!)──▶ Exim
              ──▶ Rspamd (DKIM-aláírás) ──▶ címzett szervere :25

Az Exim az MTA: ő beszél SMTP-t a világgal mindkét irányban, ő kezeli a várólistát (queue) és az újrapróbálkozásokat. A Dovecot az MDA/IMAP-szerver: tárolja a leveleket Maildir formátumban a felhasználók home-jában, kiszolgálja a klienseket, és futtatja a Sieve-szűrőket. A hitelesítés közös: az Exim a 587-es porton a Dovecot auth-szolgáltatásán keresztül ellenőrzi a küldő jelszavát.

Postafiókok létrehozása és kvóták

# Mail-domain (a webdomainnel együtt jellemzően már létrejött)
v-add-mail-domain ugyfel1 pelda.hu

# Postafiók 2 GB kvótával
v-add-mail-account ugyfel1 pelda.hu info 'ErősJelszó' 2048

v-list-mail-accounts ugyfel1 pelda.hu

Sieve — szerveroldali szűrés

A Hestia a Dovecot Sieve-et úgy konfigurálja, hogy az Rspamd által spamnek jelölt levelek automatikusan a Junk mappába kerüljenek. A felhasználók saját szabályokat is írhatnak (Roundcube → Beállítások → Szűrők): mappába rendezés, vakáció-válasz, továbbítás. Mivel ez a szerveren fut, minden kliensen (telefon, gép, webmail) egységesen érvényesül — ez a nagy előnye a kliensoldali szabályokkal szemben.

Az Exim várólista kezelése

exim -bpc                 # hány levél áll sorban? (egészséges: 0-5)
exim -bp | head -20       # melyek azok?
exim -qff                 # azonnali kézbesítési kísérlet mindenre
exim -Mrm <msg-id>        # egy konkrét levél eltávolítása

# Mi történt egy levéllel? A mainlog a legjobb barátod:
grep 'cimzett@example.com' /var/log/exim4/mainlog | tail

14-kezbesithetosegKézbesíthetőség: SPF · DKIM · DMARC

2024 óta a Gmail és a Yahoo kötelezővé tette a hitelesített levélküldést — SPF/DKIM nélkül a leveleid tömegesen visszapattannak. A három rekord együtt egy állítás-láncot alkot:

• SPF — "ezekről az IP-kről küldhet levelet a domainem";
• DKIM — "a levelet kriptográfiai aláírás köti a domainemhez, és útközben nem módosult";
• DMARC — "ha egyik sem stimmel, ezt tegyétek a levéllel — és ide küldjetek róla jelentést".

A rekordok felvétele

A Hestia a mail-domain létrehozásakor DKIM-kulcsot generál (az Rspamd írja alá vele a kimenő leveleket). A szükséges DNS-rekordokat a panel megmutatja: MAIL → domain → DNS-rekordok listája, vagy CLI-ből:

v-list-mail-domain-dkim-dns ugyfel1 pelda.hu

; SPF — a szerver IP-i küldhetnek, más senki (-all)
pelda.hu.            TXT  "v=spf1 ip4:203.0.113.10 -all"

; DKIM — a Hestia által generált publikus kulcs
mail._domainkey      TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkq...KULCS..."

; DMARC — kezdésnek megfigyelő mód + riportcím
_dmarc               TXT  "v=DMARC1; p=none; rua=mailto:dmarc@pelda.hu; adkim=s; aspf=s"

rDNS + HELO — a záró láncszem

A 2. fejezetben beállított PTR most fizet: ellenőrizd, hogy a kör zárt-e.

dig -x 203.0.113.10 +short        # → srv1.pelda.hu.
dig srv1.pelda.hu +short          # → 203.0.113.10 (forward-confirmed!)

Tesztelés — sose hidd, mérd

1. mail-tester.com: küldj levelet a kapott egyedi címre a Roundcube-ból. Cél: 10/10. A riport tételesen mutatja, mi hiányzik.
2. Gmail-önteszt: küldj saját Gmail-címre, majd "Eredeti megjelenítése" — az SPF/DKIM/DMARC mellett PASS-nak kell állnia.
3. Google Postmaster Tools: regisztráld a domaint — hosszú távon itt látod a Gmail-es reputációdat és a spam-arányt.
4. Feketelista-ellenőrzés: mxtoolbox.com/blacklists az IP-re. Netcup-IP-nél ritka az örökölt lista, de induláskor nézd meg.

Ha mégis spambe kerülsz

1. Fejléc-analízis a fogadott levélen: melyik ellenőrzés bukik (SPF? DKIM? none-align?).
2. IP-reputáció: friss feketelista-találatnál a lista saját delist-folyamata (ok megszüntetése után!).
3. Volumen-türelem: friss IP-ről hirtelen napi több ezer levél maga is gyanújel — a reputáció hetek alatt épül ("IP warming").
4. Tartalmi jelek: link-rövidítők, csupa-kép levelek, hiányzó List-Unsubscribe hírlevélnél.

15-rspamdRspamd finomhangolás

Az Rspamd webes felülete a szerveren a 11334-es porton fut, a Hestia panelből érhető el (Mail szekció), vagy SSH-tunnelen: ssh -L 11334:localhost:11334 deploy@srv1.pelda.hu, majd böngészőben http://localhost:11334. Innen látod a pontozási statisztikákat, a history-t és taníthatod a szűrőt.

Hogyan pontoz?

Minden bejövő levél tucatnyi szimbólum-ellenőrzésen megy át (SPF/DKIM-eredmény, feketelisták, bayes-valószínűség, URL-reputáció...), a részpontszámok összeadódnak, és küszöbök döntenek: greylist (~4), add header / junk (~6), reject (~15). A finomhangolás művészete a küszöbök és súlyok igazítása a saját levélforgalmadhoz.

A saját beállítások a local.d könyvtárba kerülnek — a Hestia és a csomagfrissítések ezt sosem bántják:

greylist = 4;
add_header = 6;
reject = 18;   # óvatosabb reject: inkább Junk-ba, mint visszadobni

Greylisting: pro és kontra

A greylisting az először látott feladó-szervernek átmeneti hibát (4xx) ad; a szabályos MTA-k pár perc múlva újrapróbálják, a primitív spambotok nem. Ára: az első levél új partnertől 5–15 percet késhet — regisztrációs megerősítő e-maileknél ez frusztráló. Az Rspamd okosan csak a gyanús (küszöb feletti) leveleket greylisteli, ezért alapállapotban hagyd bekapcsolva; ha a felhasználók panaszkodnak a késésekre, kapcsold ki:

enabled = false;

Bayes-tanulás Redis-backenddel

A Hestia az Rspamd-t saját Redis-példánnyal köti össze a bayes-statisztikákhoz és a greylist-adatbázishoz (ellenőrzés: rspamadm configdump redis). A tanulás két csatornán folyik:

• Automatikus: a Dovecot-integráció révén amikor a felhasználó egy levelet a Junk mappába húz, az spamként, amikor kivesz onnan, hamként tanul. Ezért fontos a felhasználókat megtanítani: ne töröld a spamet — húzd a Junk-ba.
• Kézi, meglévő korpuszból:
  root@vps

  rspamc learn_spam /home/ugyfel1/mail/pelda.hu/info/.Junk/cur/
  rspamc learn_ham  /home/ugyfel1/mail/pelda.hu/info/cur/
  rspamc stat | grep -A2 'Statfile'   # tanult minták száma

Fehér- és feketelisták

local_wl_from {
  type = "from";
  map = "/etc/rspamd/local.d/whitelist_from.map";
  score = -10.0;
  description = "Megbízható feladók";
}
local_bl_from {
  type = "from";
  map = "/etc/rspamd/local.d/blacklist_from.map";
  score = 10.0;
  description = "Tiltott feladók";
}

echo 'fontos-partner.hu' >> /etc/rspamd/local.d/whitelist_from.map
touch /etc/rspamd/local.d/blacklist_from.map
systemctl restart rspamd

16-roundcubeRoundcube — a webmail

A Roundcube a Hestia telepítésével együtt érkezik, a https://srv1.pelda.hu/webmail (vagy domainenként a webmail.pelda.hu) címen. Néhány beállítás, amit az alapértelmezésen felül érdemes rendezni:

Feltöltési és üzenetméret-korlátok

A csatolmány-limit három rétegben dől el, és a legkisebb érvényesül: PHP (upload_max_filesize a webmail PHP-poolján), Roundcube, és az Exim üzenetméret-plafonja. Ha 25 MB-os csatolmányokat akarsz engedni:

# 1) Exim üzenetlimit ellenőrzése (Hestia-alapérték jellemzően bőven elég)
exim -bP message_size_limit

# 2) Roundcube saját configja — a config.inc.php-t a Hestia kezeli,
#    a helyi felülbírálás helye:
nano /etc/roundcube/config.inc.php
#    $config['max_message_size'] = '25M';

Biztonsági beállítások

• Bejelentkezési védelem: a Hestia fail2ban jailje figyeli a Roundcube auth-hibáit (17. fejezet) — ellenőrizd, hogy aktív: fail2ban-client status.
• Session-szigorítás a config.inc.php-ban: $config['session_lifetime'] = 30; (perc) és $config['ip_check'] = true; — utóbbi mobilhálózatos felhasználóknál (gyakran váltó IP) okozhat kiléptetést, mérlegelj.
• Identitás-fegyelem: a Roundcube-ban a felhasználó tetszőleges feladó-címet beállíthat identitásként — de az Exim/Hestia a hitelesített fiókhoz köti a küldhető címeket, így a domain-hamisítás szerveroldalon akad el. Ezt ne lazítsd.

Hasznos pluginok

A /etc/roundcube/config.inc.php $config['plugins'] tömbjében kapcsolhatók; a Hestia-telepítés a lényegeseket (pl. managesieve a szűrőszerkesztőhöz, password a jelszóváltoztatáshoz) általában már tartalmazza. Ellenőrizd, hogy a managesieve aktív — e nélkül a felhasználók nem érik el a 13. fejezetben dicsért szerveroldali szűrőket.

17-tuzfal-fail2banTűzfal és fail2ban

A Hestia tűzfal-modellje

A Hestia saját iptables-szabálykészletet kezel, amit a panel Firewall menüje vagy a v-*-firewall-* parancsok írnak. Kézzel ne iptables-ezz — a Hestia a következő rebuildnél visszaállítaná a sajátját. A nyitott portok auditja:

v-list-firewall
ss -tlnp | grep -v 127.0.0.1     # mi figyel ténylegesen kifelé?

Elvárt kifelé nyitott portok: 22 (SSH), 80/443 (web), 25/465/587 (SMTP), 993 (IMAPS), 8083 (panel), 53 (DNS, ha named=yes). Minden más találat kivizsgálandó.

A panel elérésének szűkítése

# A 8083-as portot csak a saját (fix) IP-dről engedjük:
# 1) töröld a meglévő 8083 ACCEPT szabályt a v-list-firewall alapján
v-delete-firewall-rule <RULE_ID>
# 2) vedd fel IP-korlátosan
v-add-firewall-rule ACCEPT 198.51.100.7 8083 TCP "panel-csak-otthonrol"

fail2ban — a Hestia jailjei és a hangolásuk

fail2ban-client status
# tipikusan: ssh-iptables, hestia-iptables, exim-iptables,
#            dovecot-iptables, roundcube-auth ...
fail2ban-client status ssh-iptables   # tiltások élőben

A szigorítást saját drop-in fájlban végezzük (a Hestia a jail.local-t kezeli, mi a jail.d-be dolgozunk):

[DEFAULT]
bantime  = 1h
findtime = 10m
maxretry = 5

# visszaesők: aki 1 napon belül többször tiltásba fut, 1 hétre megy
[recidive]
enabled  = true
logpath  = /var/log/fail2ban.log
bantime  = 1w
findtime = 1d
maxretry = 3

Saját jail: WordPress login-védelem

A 20 oldalunk ellen futó legnagyobb volumenű támadás nem az SSH, hanem a wp-login.php és az xmlrpc.php elleni jelszószórás lesz. Erre a Hestia nem ad kész jailt — építsünk:

[Definition]
failregex = ^<HOST> .* "POST .*(wp-login\.php|xmlrpc\.php).*" (200|401|403)
ignoreregex =

[wp-auth]
enabled  = true
filter   = wp-auth
logpath  = /var/log/nginx/domains/*.log
port     = http,https
maxretry = 8
findtime = 5m
bantime  = 2h

fail2ban-client -t && systemctl restart fail2ban
fail2ban-client status wp-auth

18-mentesMentési stratégia

A Hestia beépített mentése — és a korlátja

A Hestia naponta teljes user-szintű mentést készít (web + DNS + mail + DB + cron) a /backup alá; visszaállítás egy paranccsal vagy a panelből.

v-list-user-backups ugyfel1
v-backup-user ugyfel1                       # kézi mentés most
v-restore-user ugyfel1 ugyfel1.2026-07-18.tar   # teljes visszaállítás

# hány példány maradjon meg userenként:
v-change-user-backups ugyfel1 5

Offsite mentés rclone-nal

Célpont lehet a Netcup Storage, bármely S3-kompatibilis tárhely vagy egy másik gép SFTP-je. A recept ugyanaz:

apt install -y rclone
rclone config          # távoli tár felvétele, pl. "offsite" néven

#!/bin/bash
set -euo pipefail
LOG=/var/log/offsite-backup.log
{
  echo "== $(date -Is) start"
  # a Hestia hajnali mentése után szinkronizálunk
  rclone sync /backup offsite:srv1-backup/hestia \
     --max-age 48h --transfers 4 --checksum
  echo "== $(date -Is) done"
} >> "$LOG" 2>&1

chmod 700 /usr/local/bin/offsite-backup.sh
# root cronjába, a Hestia-mentés (alapból ~05:00) UTÁNRA:
( crontab -l; echo '30 6 * * * /usr/local/bin/offsite-backup.sh' ) | crontab -

A visszaállítási próba — a mentés, amit sosem teszteltél, nem létezik

• Negyedévente: tölts le egy user-archívumot, bontsd ki, ellenőrizd hogy a DB-dump nem nulla bájt és kibontható.
• Félévente: teljes tűzpróba — hozz létre egy órára egy olcsó VPS-t, telepíts rá Hestiát, és futtass rajta valódi v-restore-user-t. Mérd az időt: ez a te valós RTO-d (helyreállítási időd), és ezt tudod ügyfélnek is mondani.
• Riasztás: a 19. fejezet monitoringja szólj, ha az offsite-log 26 óránál régebbi sikeres futást mutat.

19-monitorozasMonitorozás és karbantartás

Hol vannak a logok?

Egyszerű, függőségmentes őrszem

Húsz oldalhoz nem kell Prometheus-stack — kell viszont egy script, ami óránként ránéz a létfontosságú jelekre, és baj esetén e-mailt küld (a saját, immár megbízható levelezőnkkel):

#!/bin/bash
ALERT=admin@pelda.hu; MSG=""

# 1) diszk 85% felett?
USE=$(df --output=pcent / | tail -1 | tr -dc '0-9')
[ "$USE" -gt 85 ] && MSG+="Diszk: ${USE}%\n"

# 2) mail-queue 25 felett?
Q=$(exim -bpc); [ "$Q" -gt 25 ] && MSG+="Exim queue: ${Q}\n"

# 3) állnak-e kulcsszolgáltatások?
for s in nginx apache2 php8.3-fpm mariadb redis-server exim4 dovecot rspamd fail2ban; do
  systemctl is-active --quiet "$s" || MSG+="LEÁLLT: ${s}\n"
done

# 4) offsite mentés friss?
find /var/log/offsite-backup.log -mmin -1560 | grep -q . \
  || MSG+="Offsite mentés 26h+ óta nem futott\n"

[ -n "$MSG" ] && printf "%b" "$MSG" | mail -s "[srv1] RIASZTAS" "$ALERT"

apt install -y bsd-mailx
chmod 700 /usr/local/bin/watchdog.sh
( crontab -l; echo '*/30 * * * * /usr/local/bin/watchdog.sh' ) | crontab -

Havi karbantartási rutin

• Snapshot az SCP-ben, aztán: apt update && apt full-upgrade — kernel esetén reboot időzítve, forgalommentes sávban.
• Hestia-frissítés: a panel jelzi; changelog átfutása után v-update-sys-hestia-all vagy a panelből.
• mysqltuner lefuttatása, buffer pool hit rate és tmp-disk-tables ellenőrzése (10. fejezet).
• ab-benchmark a referencia-oldalon (12. fejezet), összevetés a korábbi számokkal.
• fail2ban-client status + auth.log átfutás: van-e szokatlan minta?
• Tanúsítványok: v-list-web-domains admin + böngészős szúrópróba — a Let's Encrypt megújítás automatikus, de a néma bukása klasszikus hiba.
• Negyedévente: mentés-visszaállítási próba (18. fejezet).

20-hibakeresesHibakeresés — a tipikus esetek

A hibakeresés első parancsa mindig ugyanaz — helyzetkép:

uptime && free -h && df -h /          # terhelés? RAM? DISZK?
v-list-sys-services                    # mi áll?
journalctl -p err -S -1h --no-pager    # hibák az elmúlt órából

502 Bad Gateway / 504 Gateway Timeout

Az Nginx nem kap (időben) választ a mögöttes láncból. Fentről lefelé haladj:

1. Fut az Apache és az FPM? systemctl status apache2 php8.3-fpm
2. FPM-poolplafon betelt? grep max_children /var/log/php8.3-fpm.log | tail — a "reached pm.max_children" sor a füstjel. Nézd meg, melyik pool, és hogy forgalom vagy lassú kód okozza-e (slowlog!). Plafont emelni csak a 9. fejezet költségvetésén belül.
3. Egy kérés lassú (504)? az FPM slowlog megmutatja a beragadt stack trace-t — tipikusan külső API-hívás timeout nélkül, vagy indexhiányos SQL (10. fejezet slow logja a párja).
4. Minden fut, mégis 502? Socket-jog vagy rossz backend-cím a domain konfigjában — v-rebuild-web-domain ugyfel1 pelda.hu újragenerálja a sablonból.

Betelt diszk — és miért ő az 1. számú gyanúsított

df -h && df -i               # az inode-fogyás is "betelt diszk"!
ncdu -x /                    # hol a hízás? tipikus: /backup, /var/log, mail

# gyors elsősegély — SOSE az éles adatot töröld először:
journalctl --vacuum-size=200M
apt clean

Betelt diszknél a MariaDB írási hibára állhat, a levelek pattognak, a Let's Encrypt megújítás bukik — a tünetek szerteágazóak, az ok egy. Ezért figyeli a watchdog 85%-nál, és ezért van kvóta mindenkin.

Mail-problémák gyorstérképe

Let's Encrypt megújítás bukik

tail -50 /usr/local/hestia/log/LE-*.log
# leggyakoribb okok:
#  - a domain A-rekordja már nem erre a szerverre mutat
#  - .well-known útvonalat egy .htaccess/redirect eltéríti
#  - rate limit (túl sok próbálkozás) — 1 hét várakozás
v-add-letsencrypt-domain ugyfel1 pelda.hu www.pelda.hu   # kézi újrapróba

„Lassú az oldal" — a módszeres út

1. Hol a késés? curl -so /dev/null -w 'dns:%{time_namelookup} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n' https://pelda.hu/ — magas TTFB = szerveroldal, magas total alacsony TTFB mellett = frontend-súly.
2. Szerveroldal: proxy cache HIT-el? (7. fejezet) → FPM slowlog → MariaDB slow log → Redis hit rate. A lánc ugyanaz, mint a 12. fejezet ábrája — felülről lefelé.
3. Mindig mérj a beavatkozás előtt és után — a "gyorsabbnak érzem" nem adat.

fuggelek-aA · Parancs-gyorsreferencia

fuggelek-bB · Méretezési táblázat

A könyv 8 GB-ra méretezett értékei, és ugyanazok a döntések 4 GB-os, illetve 16 GB-os gépre vetítve. A logika mindig azonos: előbb a fix költségek, a maradékon a PHP és a MariaDB osztozik.

Ezzel a kézikönyv végére értél. A szerver, amit így építettél fel, nem csak működik: érted is, miért — és pontosan ez az, ami két év múlva, egy hajnali riasztásnál a különbséget jelenti majd.