DEV Community: Hécate R.

Sharing an article about databases files in MariaDB

Hécate R. — Thu, 05 Nov 2026 09:50:12 +0000

https://hecate.neurozone.fr/2026/10/23/inside-database-data-files-1-3-innodb-from-mysql-to-mariadb/

I hope I can have some feedback !

How-to: the MariaDB settings that really matter, and how to check them

Hécate R. — Sun, 01 Nov 2026 14:00:00 +0000

The Internet is full of hundred-line my.cnf files, copied from server to server, where nobody remembers why each line is there. Most of MariaDB’s defaults are sensible; only about ten MariaDB settings make a real difference. This tutorial goes through them using a real server: MariaDB 12.3 on Rocky Linux, about thirty sites (WordPress, Matomo, Piwigo…), 32 GB of RAM shared with PHP, nginx and other services, spinning disks.

For each MariaDB setting: what it does, how to choose the value, and above all how to check it’s right. A MariaDB setting you can’t measure is a setting you shouldn’t touch.

Eight settings, how to choose them, and how to measure each one.

Where the configuration lives, and how to read the real value

MariaDB reads /etc/my.cnf then the files in /etc/my.cnf.d/. MariaDB settings go in a [mariadb] section (read only by MariaDB) or [mysqld] (also read by MySQL-compatible tools). The classic trap: the same variable defined in two files, the last one read wins. Two commands tell the truth:

mariadbd --print-defaults # what the server will read at next start
mariadb -e "SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_size'" # the current value

A misspelt variable in the file is ignored with a mere warning in the error log. Always compare the current value with the one you think you set.

The whole file

[mariadb]
# --- Memory -------------------------------------------------------------
innodb_buffer_pool_size = 12G
innodb_log_file_size = 2G
innodb_log_buffer_size = 256M
tmp_table_size = 256M
max_heap_table_size = 256M

# --- Durability ----------------------------------------------------------
innodb_flush_log_at_trx_commit = 1
sync_binlog = 1
innodb_flush_method = O_DIRECT

# --- I/O (spinning disks) ----------------------------------
innodb_io_capacity = 200
innodb_io_capacity_max = 400

# --- Connexions ----------------------------------------------------------
max_connections = 400
thread_cache_size = 64
wait_timeout = 28800

# --- Tables et fichiers --------------------------------------------------
table_open_cache = 4096
table_open_cache_instances = 8
table_definition_cache = 4096
open_files_limit = 68000

# --- Binlogs, replication ------------------------------------------------
server_id = 10
log_bin = /data/mysql/binlogs/logbin
binlog_format = ROW
binlog_expire_logs_seconds = 432000
max_binlog_size = 512M
log_slave_updates = ON

# --- Hygiene -------------------------------------------------------------
character_set_server = utf8mb4
collation_server = utf8mb4_uca1400_ai_ci
transaction_isolation = READ-COMMITTED
skip_name_resolve = ON
local_infile = OFF
max_allowed_packet = 256M
slow_query_log = ON
long_query_time = 5
log_slow_verbosity = query_plan,explain

Memory

innodb_buffer_pool_size, the setting that matters most

It’s the cache where InnoDB keeps table and index pages. As long as the data actually used fits, reads don’t touch the disk, which is often a factor of a hundred in response time. The usual rule: 60 to 75% of RAM on a server dedicated to the database, 30 to 40% on a server that also runs the application and the web server. Here, 12 GB out of 32.

To know whether it’s enough, measure the share of reads served by the cache:

SELECT ROUND(100 * (1 - r.v / q.v), 2) AS hit_ratio_pct
FROM (SELECT VARIABLE_VALUE v FROM information_schema.GLOBAL_STATUS
      WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') r,
     (SELECT VARIABLE_VALUE v FROM information_schema.GLOBAL_STATUS
      WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests') q;

Above 99% over a normal day, memory isn’t your problem. Below 95%, every query that touches cold data reads the disk: grow the cache if RAM allows, or look for queries that scan whole tables. Since MariaDB 10.5 there’s no need to split the cache into innodb_buffer_pool_instances: it’s handled internally.

innodb_log_file_size: sizing the redo log

Every change is first written to the redo log, then the modified pages are written to the data files in the background. A redo log that’s too small forces InnoDB to flush pages in a hurry when it fills up, which causes latency spikes. A good size covers about an hour of writes. Measure it:

SELECT VARIABLE_VALUE INTO @a FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME='Innodb_lsn_current';
SELECT SLEEP(3600);
SELECT VARIABLE_VALUE INTO @b FROM information_schema.GLOBAL_STATUS WHERE VARIABLE_NAME='Innodb_lsn_current';
SELECT ROUND((@b - @a) / 1024 / 1024) AS redo_mb_per_hour;

If the result is 400 MB per hour, a 512 MB to 1 GB log is enough; here 2 GB leaves room for imports. A bigger log only lengthens crash recovery, from seconds to a few minutes.

Per-connection memory: the multiplication trap

sort_buffer_size, join_buffer_size, read_buffer_size, read_rnd_buffer_size are allocated per connection , sometimes several times per query. A 64 MB join_buffer_size looks harmless, but multiplied by 400 connections it could in theory claim 25 GB. Keep the defaults unless a measurement says otherwise, and raise them only for one session (SET SESSION) during a heavy job.

tmp_table_size and max_heap_table_size go together: the smaller of the two sets the maximum size of an in-memory temporary table before it moves to disk. Watch the ratio of Created_tmp_disk_tables to Created_tmp_tables: above 10 to 20%, some queries sort or group large volumes.

Durability

innodb_flush_log_at_trx_commit = 1 writes and syncs the redo log at every commit; sync_binlog = 1 does the same for the binlog. Together they guarantee that a power cut loses no committed transaction and that the replica stays consistent with the primary. Values 2 or 0 reduce synchronous writes, at the cost of up to one second of lost transactions if the system crashes: acceptable on a replica you can rebuild, never on the primary.

innodb_flush_method = O_DIRECT makes InnoDB write straight to disk without going through the system cache: data isn’t cached twice (in InnoDB’s cache and in the kernel’s). It’s the default in recent versions; check it rather than assume it.

I/O

innodb_io_capacity tells InnoDB how many operations per second the storage can absorb for background work (page flushing, purge). The default suits SSDs. On spinning disks, 200 keeps InnoDB from saturating the disk at the expense of queries; innodb_io_capacity_max sets the ceiling when it falls behind. To check: iostat -x 5 during a busy period; the %util column must not stay stuck at 100.

Connections

max_connections should cover the sum of connections the applications can open, with a margin, no more: each connection uses memory, and raising this limit to “fix” Too many connections errors often hides an application that doesn’t close its connections. Look at the real peak:

SHOW GLOBAL STATUS LIKE 'Max_used_connections';
SHOW GLOBAL STATUS LIKE 'Aborted_c%';
SHOW GLOBAL STATUS LIKE 'Threads_created';

thread_cache_size keeps threads ready for reuse: if Threads_created grows quickly, raise it. wait_timeout closes idle connections; 8 hours suits web applications, which reconnect on their own.

Tables and files

table_open_cache keeps tables open between queries; it’s split into table_open_cache_instances to limit contention between threads. If Opened_tables keeps growing, the cache is too small.

The trap that cost me time: this cache depends on how many files the process may open. MariaDB computes its limits from open_files_limit, but systemd imposes its own (LimitNOFILE). If systemd’s is lower, MariaDB silently shrinks its caches at startup: I found a server set to 8 instances that was only using 3. The fix is a systemd override file:

# /etc/systemd/system/mariadb.service.d/limits.conf
[Service]
LimitNOFILE=68000

systemctl daemon-reload && systemctl restart mariadb
mariadb -e "SHOW GLOBAL VARIABLES WHERE Variable_name IN ('open_files_limit','table_open_cache_instances')"

Binlogs and replication

The binlog records every change; it serves replication and point-in-time recovery. binlog_format = ROW records the changed rows rather than the statements: bigger, but unambiguous (a statement with NOW() or RAND() doesn’t give the same result replayed elsewhere). binlog_expire_logs_seconds purges old files: keep at least the interval between two full backups, or point-in-time recovery becomes impossible for the period in between. server_id must be unique across the whole replication topology, and log_slave_updates lets a replica act as a source itself.

Hygiene

utf8mb4 : real 4-byte UTF-8, emoji included. The historical utf8 set is limited to 3 bytes and truncates some characters;
collation_server : recent versions offer UCA 14.0 collations (utf8mb4_uca1400_ai_ci), more accurate for comparisons and sorting;
READ-COMMITTED : fewer locks than the default REPEATABLE-READ, a good fit for web applications;
skip_name_resolve : no DNS lookup on every connection (slow DNS would mean slow connections), and grants are given by IP address;
local_infile = OFF : closes a door that lets a client make the server read files;
max_allowed_packet : the maximum size of a query or a row; too small, and imports and large contents fail;
the slow query log : beyond 5 seconds, with the execution plan. Read it every week: it’s the best optimisation source there is.

The method for any MariaDB setting

change one setting at a time, and note the measurement before and after;
many variables can be changed live (SET GLOBAL) for a trial; then write them to the file, or they vanish at restart;
those that need a restart (redo log size, open_files_limit) get scheduled;
keep the configuration under version control, with the reason for each non-default value as a comment. In six months, that comment will be worth more than the value itself.

Checks after a change

systemctl restart mariadb && systemctl is-active mariadb
journalctl -u mariadb -n 30 --no-pager | grep -iE 'warn|error'
mariadb -e "SHOW GLOBAL VARIABLES" > /tmp/vars.after
diff <(sort /tmp/vars.before) <(sort /tmp/vars.after)

If a Prometheus exporter watches the database, compare over a few days the cache hit ratio, on-disk temporary tables, connections and query latency. A MariaDB setting is only good if those curves confirm it.

A real check, 75 minutes after a restart

To show what these checks give on a real server, here is my web server’s MariaDB 12.3 on 2 November 2026, read with the monitoring account (which only needs to read variables and counters). The machine had rebooted 75 minutes earlier, which makes the numbers more instructive, not less.

SELECT @@innodb_buffer_pool_size/1024/1024/1024 AS buffer_pool_gb,
       @@innodb_log_file_size/1024/1024 AS redo_mb,
       @@max_connections, @@innodb_flush_log_at_trx_commit, @@sync_binlog;
+----------------+---------+-------------------+---------------------------------+---------------+
| buffer_pool_gb | redo_mb | @@max_connections | @@innodb_flush_log_at_trx_commit| @@sync_binlog |
+----------------+---------+-------------------+---------------------------------+---------------+
| 12.31 | 2048 | 400 | 1 | 1 |
+----------------+---------+-------------------+---------------------------------+---------------+

SHOW GLOBAL STATUS WHERE Variable_name IN (...);
| Uptime | 4487 |
| Innodb_buffer_pool_read_requests | 5163358 |
| Innodb_buffer_pool_reads | 121600 |
| Innodb_log_waits | 0 |
| Max_used_connections | 61 |
| Threads_created | 61 |
| Connections | 11846 |
| Created_tmp_tables | 37637 |
| Created_tmp_disk_tables | 5223 |

How I read it, line by line:

Buffer pool hit ratio : 1 − 121 600 / 5 163 358 = 97.6 %. On a server that has been up for weeks I expect above 99.9 %. Here the cache is still filling: every page read from disk since the restart counts as a miss. That’s why the ratio must be compared over days, never right after a restart, and why a restart is followed by a slow first hour.
Innodb_log_waits = 0 : no transaction had to wait for room in the log buffer. With a 2 GB redo log, even the start-up traffic didn’t saturate it.
Max_used_connections = 61 out of 400 allowed, and Threads_created = 61 for 11 846 connections: the thread cache reuses threads instead of creating one per connection. If Threads_created grew almost as fast as Connections, thread_cache_size would be too small.
Temporary tables on disk : 5 223 out of 37 637, i.e. 14 %. That’s mostly WordPress queries sorting text columns, which go to disk regardless of tmp_table_size. Above 25 %, it’s worth looking for the queries responsible before raising any limit.
innodb_flush_log_at_trx_commit = 1 and sync_binlog = 1 : full durability on the primary. The replica runs with 2 and 0, the reasons are in the MariaDB series.

Total time: two queries, one minute. Run them before and after every change, and keep the outputs: that’s what turns “it feels faster” into a measurement.

This post is part of a series of sysadmin tutorials (tag “how-to”).

Series “How-to”, tutorial 6/77. · ← Previous tutorial · Next tutorial → · Version française

The post How-to: the MariaDB settings that really matter, and how to check them appeared first on Hécate Regnier - Neurozone.

How-to: install and configure WireGuard between a server and home

Hécate R. — Sun, 01 Nov 2026 09:00:00 +0000

This tutorial links a hosted server (a Rocky Linux VPS) to the home network through a WireGuard tunnel. At the end, the server reaches the home machines, the house reaches the server, and only one UDP port is exposed to the Internet. It’s the basis for many uses: backups sent to a NAS, monitoring a public server from home, access to services you really don’t want to publish.

Every configuration line is explained, along with the checks to run and the most common failures. The addresses are examples; adapt them to your own addressing plan.

The tunnel, one exposed UDP port, and the five failures you will meet.

Why WireGuard

WireGuard fits in a few thousand lines of code in the Linux kernel, against hundreds of thousands for OpenVPN or IPsec. It offers no choice of algorithm: the cryptography is fixed (Curve25519, ChaCha20-Poly1305, BLAKE2s), which removes a whole class of configuration mistakes. It looks stateless: no session to negotiate by hand, a handshake renewed automatically about every two minutes, and a tunnel that survives a peer’s address changing. And it’s silent: a packet not authenticated by a known key gets no answer, so the port looks closed to a scan.

Concepts to keep in mind

One key pair per end. The private key stays on the machine; the public key is its identity for the other side. There’s no user and no password;
Peers, not a client and a server. Each side declares the other as a peer. What looks like a “server” is simply the peer with a fixed address that waits to be called;
Cryptokey routing. The AllowedIPs directive ties networks to a peer. A packet for those networks leaves encrypted for that peer; a packet received from that peer is accepted only if its source address belongs to those networks;
UDP only. Everything goes through a single UDP port, which crosses ISP boxes’ address translation well.

The addressing plan

Item	Value	Role
Tunnel network	`10.99.0.0/24`	addresses inside the tunnel, one per end
Router (tunnel)	`10.99.0.2`	home side, behind the ISP box
Server (tunnel)	`10.99.0.3`	the VPS
Home network	`192.168.10.0/24`	what the server must reach
Server (public)	`203.0.113.25`	the VPS’s fixed public address, UDP port 51820

Pick a tunnel network that exists nowhere else at home or at the provider: overlapping addresses produce failures that are very hard to understand.

Prerequisites

a Rocky Linux 9 or 10 server with a fixed public IPv4 address and root access;
a home router that does WireGuard (MikroTik RouterOS 7, OpenWrt, pfSense, OPNsense…), or failing that an always-on Linux machine;
console access to the server at the provider, in case a firewall mistake cuts SSH.

Step 1: install the tools

The kernel module ships with Rocky Linux since version 9. Only the userspace tools are missing, wg and wg-quick:

dnf install wireguard-tools
modprobe wireguard
lsmod | grep wireguard # the module is loaded

Step 2: generate the keys

umask 077
cd /etc/wireguard
wg genkey | tee server.key | wg pubkey > server.pub
wg genpsk > home.psk # preshared key, optional but recommended
cat server.pub

The umask 077 ensures the files are created readable by root only, with no window during which another user could read them. The preshared key adds a layer of symmetric encryption on top of the key exchange: it replaces nothing, but protects traffic recorded today against a future quantum computer able to break Curve25519. It must be identical on both sides and travel only over a safe channel.

Do the same on the router and note its public key. Private keys never appear in a version-controlled file in clear text: put them in a secrets store (Vault, OpenBao, Ansible Vault) if you automate the deployment.

Step 3: write /etc/wireguard/wg0.conf

[Interface]
Address = 10.99.0.3/24
ListenPort = 51820
PrivateKey = <server private key>
MTU = 1420
SaveConfig = false

[Peer]
# home router
PublicKey = <router public key>
PresharedKey = <preshared key>
AllowedIPs = 192.168.10.0/24, 10.99.0.0/24
PersistentKeepalive = 25

The [Interface] section

Address : the server’s address in the tunnel. The /24 mask makes wg-quick create a route to the whole tunnel network, useful if other servers join the same tunnel later;
ListenPort : the UDP listening port. 51820 is the convention; nothing forces you to use it;
PrivateKey : the content of server.key. A variant is to leave it out of the file and load it with PostUp = wg set %i private-key /etc/wireguard/server.key;
MTU = 1420 : the maximum packet size in the tunnel. WireGuard adds 60 bytes of header over IPv4 (80 over IPv6); 1420 leaves room on a standard 1500 Ethernet link. If the home box uses PPPoE (MTU 1492), go down to 1412, or 1380 when in doubt;
SaveConfig = false : keeps wg-quick from rewriting the file with the current state on shutdown, which would erase your comments and could freeze in a manual change made for a test.

The [Peer] section

PublicKey : the router’s identity;
PresharedKey : the shared key generated above;
AllowedIPs : the most important directive, and the most misunderstood. It’s both a routing table (packets to 192.168.10.0/24 and 10.99.0.0/24 go to this peer) and a filter (a packet from this peer whose source isn’t in these networks is dropped). Don’t put 0.0.0.0/0 here: only traffic for the house goes through the tunnel, the rest of the server’s traffic leaves normally. That’s a split tunnel;
no Endpoint : the server doesn’t know where to reach the house, whose public address may change. The router calls it; the server learns its address at the first handshake and updates it if it changes;
PersistentKeepalive = 25 : a small packet every 25 seconds. Essential on the router side, because the box forgets an idle UDP translation after 30 to 120 seconds and the server could no longer reach the house. On the server side it’s harmless and keeps the tunnel active both ways.

Step 4: the home side

The router declares the server as a peer, this time with an Endpoint: the VPS’s public address. Its AllowedIPs for that peer is just the server’s tunnel address. Example on a MikroTik running RouterOS 7:

/interface wireguard add name=wg-servers listen-port=13231 private-key="<router private key>"
/ip address add address=10.99.0.2/24 interface=wg-servers
/interface wireguard peers add interface=wg-servers \
    public-key="<server public key>" preshared-key="<preshared key>" \
    endpoint-address=203.0.113.25 endpoint-port=51820 \
    allowed-address=10.99.0.3/32 persistent-keepalive=25s

The router’s firewall must also allow traffic between the WireGuard interface and the LAN (forward chain), placed before the generic drop rules. A common rule that drops private addresses (“bogons”) must apply only to the Internet-facing interface: otherwise it drops the WireGuard tunnel network itself.

Step 5: the server’s firewall

firewall-cmd --permanent --add-port=51820/udp
# attach wg0 to a zone: 'trusted' to allow everything from home,
# or a dedicated zone that opens only what's needed (SSH, exporters…)
firewall-cmd --permanent --new-zone=wireguard
firewall-cmd --permanent --zone=wireguard --add-interface=wg0
firewall-cmd --permanent --zone=wireguard --add-service=ssh
firewall-cmd --reload

A dedicated zone is more careful than trusted: if a home machine were compromised, it would see only the services you chose on the server. The server doesn’t need to forward packets between networks (net.ipv4.ip_forward can stay at 0) since it’s only an endpoint.

Step 6: start

systemctl enable --now wg-quick@wg0

wg-quick creates the wg0 interface, gives it its address, loads the WireGuard configuration and adds the routes derived from AllowedIPs. The service comes back at boot. To apply a change to the file without dropping the WireGuard tunnel: wg syncconf wg0 <(wg-quick strip wg0).

Step 7: check, in order

wg show wg0
# peer: <router public key>
# endpoint: 198.51.100.7:13231
# allowed ips: 192.168.10.0/24, 10.99.0.0/24
# latest handshake: 41 seconds ago
# transfer: 1.20 MiB received, 3.45 MiB sent

latest handshake under two minutes: keys and UDP port are right;
endpoint filled in: the server knows the house’s current address;
transfer growing both ways: traffic flows.

ip route get 192.168.10.20 # must answer "dev wg0"
ping -c3 10.99.0.2 # the router in the tunnel
ping -c3 192.168.10.20 # a home machine
ssh admin@192.168.10.20 # a real TCP connection
# from a home machine, the other way:
ssh root@10.99.0.3

Don’t stop at ping. A firewall can accept ICMP early in its chain and reject new TCP connections further down: ping works, nothing else. Test a real connection, in both directions.

What it looks like on my server

Here is the same check on my web server, captured on 2 November 2026, about an hour after a reboot. Addresses are rewritten to the plan used in this tutorial; everything else is as printed.

# wg show wg0
interface: wg0
  public key: (hidden)
  private key: (hidden)
  listening port: 51820

peer: (router public key)
  endpoint: 198.51.100.7:13231
  allowed ips: 192.168.10.0/24, 10.99.0.0/24
  latest handshake: 1 minute, 9 seconds ago
  transfer: 4.01 MiB received, 74.50 MiB sent
  persistent keepalive: every 25 seconds

# ip route get 192.168.10.20
192.168.10.20 dev wg0 src 10.99.0.3 uid 0

# ping -c3 -q 10.99.0.2
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 8.060/8.424/8.976/0.396 ms

latest handshake: 1 minute, 9 seconds ago : WireGuard renews the session key every two minutes as long as traffic flows, so anything under about two and a half minutes is normal. A value in hours, or no line at all, means the two sides no longer agree on keys or the UDP port is blocked.
transfer: 4.01 MiB received, 74.50 MiB sent : the asymmetry is expected here, the server pushes backups and metrics towards home. What matters is that both counters grow.
persistent keepalive: every 25 seconds : the setting from the [Peer] section, applied. Without it, the router’s NAT forgets the flow after a few minutes of silence.
8.4 ms round trip between a datacentre and a home fibre line: the tunnel itself adds well under a millisecond, the rest is the distance.

Two more tests worth keeping in a notebook. The first measures the largest packet the WireGuard tunnel accepts without fragmentation, which is how you confirm the MTU of 1420:

# ping -c2 -M do -s 1392 192.168.10.20 # 1392 + 28 header bytes = 1420
2 packets transmitted, 2 received, 0% packet loss, time 1001ms

# ping -c1 -M do -s 1393 192.168.10.20 # one byte more
ping: sendmsg: Message too long

-M do forbids fragmentation, -s sets the payload size, and ICMP plus IP add 28 bytes. 1420 passes, 1421 is refused locally with Message too long: the interface MTU is exactly what the configuration asked for. If large transfers freeze while small ones work, this is the first test to run, from both ends.

The second is a real TCP connection, because ping alone proves nothing about the firewall: an SSH session from the server to a home machine through the WireGuard tunnel opened in 0.27 s, banner included.

The most common failures

No handshake

The UDP port is closed (at the provider or in firewalld), the public keys are swapped, or the router has the wrong Endpoint address. tcpdump -ni eth0 udp port 51820 on the server shows whether the router’s packets arrive: if they arrive with no answer, it’s a key; if they don’t arrive, it’s the network.

Handshake, but no traffic

The AllowedIPs don’t match on both sides: the router sends packets whose source isn’t in the server’s list, and the server silently drops them. Or the return route is missing at home.

Ping works, TCP doesn’t

A firewall rule treats ICMP separately. The typical case is a “bogons” address list containing 10.0.0.0/8 applied to every interface: it drops the WireGuard tunnel network in the forward chain. Restrict it to the Internet interface.

Small exchanges work, large transfers freeze

An MTU problem. Full-size packets exceed the allowed size somewhere on the path and are lost. Test with ping -M do -s 1372 192.168.10.20, increasing the size until it fails, then lower the tunnel’s MTU accordingly on both sides.

Everything works, then stops after a while

PersistentKeepalive is missing on the router side, and the box forgot the address translation. Or the house’s public address changed and the server hasn’t learned it yet: it’s up to the router to restart the handshake, which the keepalive does on its own.

Home machine names don’t resolve

The tunnel carries addresses, not names. To resolve nas.home.lan from the server, send only that domain to the home DNS server, for example with NetworkManager’s dnsmasq plugin, rather than replacing the server’s whole DNS.

Maintaining the WireGuard tunnel

Rotating keys without losing access : first add the server’s new public key as a second peer on the router, switch the server to its new key, check the handshake, then remove the old peer. Never change both sides blindly from outside;
Adding a second server : new tunnel address (10.99.0.4), new peer on the router with allowed-address=10.99.0.4/32. Each address must appear in a single peer only, or routing becomes unpredictable;
Monitoring : the age of the latest handshake is the best indicator. Beyond three minutes, the tunnel is down. A script that reads wg show wg0 latest-handshakes and publishes the value for Prometheus, or a simple probe from home, is enough;
Changing a router remotely : turn on its safe mode (Safe Mode on RouterOS) before any change. If the session is lost, the router undoes everything done since.

Going further

The same tunnel can carry monitoring (Prometheus querying the server’s exporters), backups (rsync to an account jailed in a NAS directory) and administration (SSH limited to the tunnel interface). Once the tunnel is in place, many ports you might have been tempted to open to the Internet no longer need to be.

This post is part of a series of sysadmin tutorials (tag “how-to”).

Series “How-to”, tutorial 5/77. · ← Previous tutorial · Next tutorial → · Version française

The post How-to: install and configure WireGuard between a server and home appeared first on Hécate Regnier - Neurozone.

PHP2Shell: understanding the October 2026 PHP flaws and checking your servers

Hécate R. — Fri, 30 Oct 2026 09:00:00 +0000

PHP2Shell is the name given to two PHP vulnerabilities published on 21 October 2026, CVE-2026-109618 and CVE-2026-109619. They allow, with a simple HTTP request and no authentication, running code on a server that runs PHP. With PHP powering about 70% of websites whose server technology is known (WordPress, Drupal, Joomla and a host of applications), the reach is considerable: government sites, Wikimedia and the Internet Archive were taken offline as a precaution, and some experts compared it with Heartbleed.

This post explains what these flaws are, without going into exploitation details, starting from how PHP manages a request’s memory. It then describes how to check a server is really protected, which takes a little more than a version number, and what I did on my own servers. The facts come from the PHP project’s security advisories and the Wikipedia page about the affair.

Exploited before publication: four checks that go beyond the version number.

The PHP2Shell facts

	CVE-2026-109618	CVE-2026-109619
advisory title	“RCE via OOM corruption”	“RCE via stale global state”
nature	memory corruption on out-of-memory during request cleanup	request-owned internal state surviving after its memory was freed
CVSS 3.1	9.8 (no authentication, no interaction)	8.1 (high attack complexity)
CVSS 4.0	9.2	9.2
affected versions	PHP 5.4 to 8.5	PHP 5.4 to 8.5
fixed in	8.2.35, 8.3.36, 8.4.27, 8.5.12	same

Date (2026)	Event
August	discovery by two teams, helped by AI-assisted analysis tools; one of the bugs had been spotted in a 2024 audit, left unfixed for lack of agreement on the fix
17 October	first exploitation attempt seen by a honeypot, four days before publication
20 October	public announcement, leaks (a demo video released by mistake), fixes already visible at one distributor
21 October, 13:34 UTC	advisories and fixed versions published; exploitation observed the same day
23 October	follow-up advisory CVE-2026-115560, tied to session upload progress

Two elements of this timeline deserve attention. The flaw was exploited before it was published: when the fix comes out, there’s no grace period any more. And the first bug had been spotted two years earlier, left unfixed for lack of a demonstration that it was exploitable: the arrival of tools able to build that demonstration changed everything. Expect this scenario to repeat with other old “theoretical” bugs.

Understanding: the life of a request in PHP

To grasp what “corruption on out-of-memory” and “stale global state” mean, you need to know how PHP handles a request, especially with PHP-FPM, the most common mode behind nginx.

reused processes : PHP-FPM starts a group of processes (workers), each handling one request after another, hundreds or thousands of times before being recycled (pm.max_requests). It isn’t a fresh process per request;
a four-step cycle : when the process starts, PHP initialises its extensions once and for all (the MINIT phase). Then for each request: request-specific initialisation (RINIT), script execution, then cleanup (RSHUTDOWN), which must return the process to a clean state for the next request;
per-request memory : PHP’s memory manager (the Zend Memory Manager) allocates the script’s memory in an area owned by the request, freed in one go at the end. It’s fast and avoids most leaks, but it assumes nothing keeps, beyond the request, a pointer into that area;
a memory limit : memory_limit caps a request’s memory. When a script exceeds it, PHP interrupts execution… in the middle of whatever it was doing, cleanup included.

The two bugs, at this level of explanation

The first bug concerns precisely that case: running out of memory during a request’s cleanup leaves some internal structures in an inconsistent, half-freed state. An attacker who knows how to trigger that exhaustion at the right moment, with a request built for it, gets a corruption of the process’s memory.

The second bug belongs to the same family: a piece of internal state belonging to a request isn’t reset and survives the release of its memory. The next request, handled by the same process, finds a reference to an area that was freed then reused, possibly filled by the attacker. It’s a use-after-free, a classic in programs written in C.

In both PHP2Shell bugs, controlled memory corruption makes it possible to hijack the PHP process’s execution flow, hence to run code with its rights: those of the web server user, who can read the sites’ files, their database credentials, and often write into their directories. The name “PHP2Shell” sums up the result.

Why every mode is affected

Both bugs are in PHP’s core, not in a particular module. PHP-FPM, Apache with mod_php, php-cgi, FrankenPHP, LiteSpeed: everything that serves web requests is concerned. The command line is less so, since no remote attacker sends it requests. And the fact that FPM processes are reused from one request to the next is precisely what makes state that “survives” a request exploitable.

Why a web application firewall isn’t enough

Web application firewall vendors published temporary rules within the first days. They have their use against published exploitation tools, but a memory corruption flaw triggered by the shape of a request lends itself poorly to filtering: varying the payload is often enough. PHP’s maintainers said it plainly: no workaround is complete, only updating protects. The US National Security Agency went as far as recommending taking offline the sites that couldn’t be updated immediately.

Checking a server: the version isn’t enough

php -v # the command-line binary
rpm -qa 'php*-fpm' 'php*-common' --qf '%{NAME} %{VERSION} installed %{INSTALLTIME:date}\n'
systemctl show -p ActiveEnterTimestamp php-fpm # did PHP-FPM restart AFTER the update?
needs-restarting -s | grep -i php # is a process still using old libraries?
ls /opt/remi/*/root/usr/sbin/php-fpm 2>/dev/null # parallel versions (software collections)

the installed version must be at least 8.2.35, 8.3.36, 8.4.27 or 8.5.12. For older versions, no longer maintained by the project, only source patches exist; distributions and some vendors (cPanel, CloudLinux) packaged them;
the running process must have restarted after the update. A PHP-FPM started before installation keeps running the old code in memory, whatever package is on disk. needs-restarting -s lists the services concerned;
every copy of PHP : a server can have several (the main package, parallel collections in /opt/remi, containers bundling their own PHP). Each must be checked;
backported numbers : on a distribution that fixes without changing version (RHEL and derivatives for their stock PHP), it’s the package’s changelog you must read (rpm -q --changelog), not the version number.

What I found on my servers

# main
php-fpm 8.5.12 installed 21 Oct 2026 at 21:10 (advisory published at 15:34 Paris time)
# homelab
php-fpm 8.4.27 installed 21 Oct 2026 at 20:30

My two servers running PHP use packages from the Remi repository, which tracks official releases closely: the fixed versions were installed the very evening of publication, within five to six hours. One server’s PHP-FPM process had restarted since, and so had the other’s, but needs-restarting still flagged it for a library updated afterwards: one more restart settled that. It’s the check most often forgotten.

The follow-up flaw: upload progress

; 99-local.ini : disable session upload progress (CVE-2026-115560)
session.upload_progress.enabled = Off

On 23 October, the PHP team published an advisory on a third flaw, CVE-2026-115560, distinct from the first two: a configuration-dependent code execution tied to the session upload progress tracking feature. When it’s on (the default), PHP writes into the session, during an upload, information partly coming from the request. If no application uses it, disabling it costs nothing. I checked no PHP code on my sites used the feature (searching for PHP_SESSION_UPLOAD_PROGRESS and upload_progress), then disabled it through the common configuration deployed by Ansible.

Detecting an attempt

journalctl -u php-fpm --since "-7 days" | grep -E "exited on signal (11|6)|SIGSEGV|SIGABRT"
# WARNING: [pool www] child 12345 exited on signal 11 (SIGSEGV) after 3.2 seconds from start

A failed exploitation attempt against memory corruption often shows up as a crash of the targeted process. PHP-FPM processes dying on signal 11 (segmentation fault) or 6 (abort), especially in a series from the same address in the web server logs, are a signal to watch. An alert rule on those messages, in a tool like Wazuh, costs little.

The lessons

update speed matters more than ever : exploitation before publication, exploit tools within days. A package repository that tracks upstream releases closely, and automatic security updates, make the difference;
an update only applies when the process using the code restarts. Check it, don’t assume it;
end-of-life versions (PHP 8.1 and older) only got source patches. A server on an old version means compiling it yourself at the worst possible moment;
reduce what’s exposed : an unused feature (upload progress) disabled is one flaw fewer on the day it’s discovered;
and a deeper shift: AI-assisted analysis tools find and demonstrate old flaws faster than before. “Never exploited” bugs may not stay that way.

Sources: PHP project security advisories (GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp); Wikipedia page “PHP2Shell”; Help Net Security and Recorded Future, October 2026.

This post is part of a series of sysadmin tutorials (tag “how-to”).

Series “How-to”, tutorial 1/77. · Next tutorial → · Version française

The post PHP2Shell: understanding the October 2026 PHP flaws and checking your servers appeared first on Hécate Regnier - Neurozone.

DEV Community: Hécate R.

Sharing an article about databases files in MariaDB

How-to: the MariaDB settings that really matter, and how to check them

Where the configuration lives, and how to read the real value

The whole file

Memory

innodb_buffer_pool_size, the setting that matters most

innodb_log_file_size: sizing the redo log

Per-connection memory: the multiplication trap

Durability

I/O

Connections

Tables and files

Binlogs and replication

Hygiene

The method for any MariaDB setting

Checks after a change

A real check, 75 minutes after a restart

Related articles

How-to: install and configure WireGuard between a server and home

Why WireGuard

Concepts to keep in mind

The addressing plan

Prerequisites

Step 1: install the tools

Step 2: generate the keys

Step 3: write /etc/wireguard/wg0.conf

The [Interface] section

The [Peer] section

Step 4: the home side

Step 5: the server’s firewall

Step 6: start

Step 7: check, in order

What it looks like on my server

The most common failures

No handshake

Handshake, but no traffic

Ping works, TCP doesn’t

Small exchanges work, large transfers freeze

Everything works, then stops after a while

Home machine names don’t resolve

Maintaining the WireGuard tunnel

Going further

Related articles

PHP2Shell: understanding the October 2026 PHP flaws and checking your servers

The PHP2Shell facts

Understanding: the life of a request in PHP

The two bugs, at this level of explanation

Why every mode is affected

Why a web application firewall isn’t enough

Checking a server: the version isn’t enough

What I found on my servers

The follow-up flaw: upload progress

Detecting an attempt

The lessons

Related articles