Skip to content

php2shell on 13 servers

That is all you type

“Research php2shell and fix the problem on every server affected by it.”

Who
An admin, from a phone
Servers
All 13 of Example Ltd, web01 first
Your part
One sentence and one go
Level
rwx Changes alone, see the three levels

Problem

In the afternoon php.net publishes two holes in PHP, together called php2shell. Every web application is affected, the fix is ready. Example Ltd has 13 servers, not all of them run PHP, and the admin is on the road. Checking and patching every server by hand costs the evening, and whoever forgets one notices too late.

Wanted: every affected server closed today, one first as a trial, then the others, from a phone and without reading a command.

Solution

One sentence from a phone, and Heinzel Pro researches, checks every server and installs the fix: on one first, on all of them after your go. At the level "Changes alone" nothing waits for you meanwhile.

Step 1: You describe the task, for every server

The sentence above, the way you would write it to a colleague. "The same on many" makes it a rollout: one session per server, on web01 first, the others after your go. You set the level to "Changes alone": today every minute counts, and what Heinzel Pro did on web01 you read at leisure before the go.

A new session in Heinzel Pro on a phone: the typed sentence about php2shell, the choice "The same on many", the 13 servers chosen, web01 as the first, and the level "Changes alone"

Step 2: It researches and looks

Heinzel Pro fetches the announcement from php.net and then reads web01: which PHP packages are there, whether the new version is in the mirror yet, which services run. None of it waits for you, and every command still stands in the session with its classification and output.

Then it is clear: web01 is affected, PHP 8.2.29 as php-fpm behind nginx, and the fix is ready.

The session on web01: the fetch of the announcement from php.net with the classification "write" and its output, Heinzel Pro's answer on the two holes, the reading command with the PHP packages, and the finding that web01 is affected

Step 3: It writes the plan down and goes through it

Three steps, each with its command, server and classification: package, service, read-only. With them, what could go wrong and how to undo it. At this level nobody approves it, but it is there before the first step runs: afterwards you read what Heinzel Pro set out to do and what came of it.

The plan in the session: three steps with command, server and classification, package, service and read-only, below them what could go wrong and how to undo it, with the note that the session changes alone

Step 4: After your go the other twelve follow

web01 is closed after 24 seconds, the portal answers 200. You read the session, say go, and the other servers get a session each at the same level, four at a time. backup2 has no PHP: its session says so and changes nothing.

The rollout's page: the task, the go by Anna Berg, below it the table of the 13 servers with their state, web01 and backup2 through, three running, the rest waiting