Kort sagt: Gamle PHP-versioner deaktiverer I mest sikkert i tre faser: find brugen, spær versionen og observér, og afinstallér først derefter. I Plesk kan en handler først deaktiveres, så den ikke længere kan vælges, og senere fjernes under opdateringer og komponenter. Hver fjernet version er én mindre, som I skal patche og genstarte ved den næste sårbarhed som PHP2Shell.
Hvorfor rydde op netop nu?
Ugen efter PHP2Shell har vist mange administratorer, hvor mange PHP-versioner der er installeret på deres servere. Hver af dem skulle kontrolleres, hver krævede en opdatering eller overgangsforanstaltninger, hver tjeneste en genstart. Til PHP 8.1 og ældre findes der kun minimale kilde-backports, for PHP 8.2 udløber understøttelsen den 31.12.2026.
Med denne erfaring frisk i erindringen er det det rette tidspunkt at rydde op. Hvordan I overhovedet finder alle installationer, beskriver indlægget Flere PHP-versioner på én server. Her handler det om det næste skridt: den kontrollerede nedlukning.
Fase 1: Find brugen
Før I slår noget fra, skal I vide, hvem der bruger en version. Websites er den åbenlyse del. Mindre synlige er subdomæner, testinstallationer, cronjobs, scripts og panelkomponenter.
I Plesk viser kommandoen plesk bin php_handler --list alle registrerede handlere. Med --get-usage viser Plesk ifølge dokumentationen, hvilke domæner der bruger en bestemt handler. Begge kommandoer ændrer intet.
# Plesk: alle handlere og de domæner, der bruger en handler
plesk bin php_handler --list
plesk bin php_handler --get-usage -id <handler-id>
# Generelt: cronjobs, der kalder en bestemt PHP-version
grep -rE "php(7|8\.0|8\.1)" /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
Kontrollér desuden adgangslogs for de berørte websites: En testinstallation, der ikke har modtaget en forespørgsel i flere måneder, er en kandidat til fjernelse, ikke til migrering. Notér for hver gammel version, hvem der bruger den, og hvorfor.
Spørg desuden dem, der arbejder med websitene. Redaktioner, bureauer og fagafdelinger kender ofte forløb, der ikke står på nogen liste: den årlige eksport til bogholderiet, formularen til en messe, grænsefladen til varestyringssystemet. Det, der dér hænger på en gammel version, opdages ellers først, når det mangler.
Fase 2: Spær og observér
Mellemtrinnet forhindrer, at en version tildeles på ny, uden at den straks slettes. I Plesk findes der mulighed for at deaktivere enkelte handlere. Ifølge Plesk-dokumentationen kan en deaktiveret handler ikke længere vælges i et websites PHP-indstillinger; versionen forbliver installeret. På kommandolinjen sker det med plesk bin php_handler --disable -id <handler-id>.
Domæner, der stadig bruger den gamle version, omstiller I først i samråd med de ansvarlige til en understøttet version. Hvordan det ser ud fra website-ejerens side, beskriver indlægget Skift PHP-version i hostingens kundeområde. Valget af den rette handler forklarer indlægget Plesk: Forstå PHP-handlere.
I observationstiden holder I øje med fejlmeddelelser i logs, udeblevne cronjob-resultater og tilbagemeldinger fra brugerne. I andre paneler hedder funktionerne noget andet; kontrollér dér producentens dokumentation.
Fastlæg slutningen af observationstiden som en dato, og angiv, hvem der derefter frigiver afinstallationen. Ellers bliver mellemtrinnet til en varig tilstand, og den gamle version bliver alligevel liggende på serveren.
Fase 3: Afinstallér
Først når observationstiden er gået uden bemærkninger, fjerner I versionen helt. I Plesk sker det ifølge dokumentationen under Tools & Settings, Updates, Add/Remove Components, i området Web hosting ved PHP-fortolkerversionerne. Installerede versioner er dér markeret og kan vælges til fjernelse.
På servere uden panel overtager pakkehåndteringen denne opgave. Sikr først versionens konfiguration, f.eks. /etc/php/7.4/ under Debian og Ubuntu, så I i nødstilfælde kan efterspore, hvilke indstillinger der gjaldt.
# Sikr konfigurationen, fjern derefter pakkerne i en gren (eksempel Debian/Ubuntu, PHP 7.4)
tar czf /root/php74-konfiguration.tar.gz /etc/php/7.4/
apt remove 'php7.4*'
Efter fjernelsen er en kontrol umagen værd. I Plesk anbefaler dokumentationen plesk bin php_handler --reread for at indlæse handler-oplysninger på ny efter ændringer af PHP-binaries. Kontrollér desuden, om serviceplaner stadig henviser til den fjernede version.
Typiske faldgruber
| Faldgrube | Sådan opdager I den | Hvad hjælper |
|---|---|---|
| Panelkomponent hænger på versionen | Panelet melder en afhængighed ved fjernelsen | Omstil først komponenten, eller behold versionen |
| Serviceplan henviser til gammel version | Nye websites får den gamle version eller en fejlmeddelelse | Tilpas planen, fjern derefter versionen |
| Cronjob kalder en fast sti | Scriptet fejler efter fjernelsen | Ret stien til en understøttet version |
| Applikation kører ikke på ny version | Fejl efter omstillingen i fejlloggen | Opdatér eller migrér applikationen |
Kan en applikation ikke løftes til en understøttet version, er nedlukningen af den gamle version ikke længere et konfigurationsspørgsmål, men et migreringsprojekt. Risiciene ved forældede grene beskriver vejledningen PHP End of Life: Risici ved forældede versioner.
Den næste kandidat er allerede givet
Oprydning er ikke en engangshandling. Allerede den 31.12.2026 falder PHP 8.2 ud af PHP-projektets understøttelse. Den, der nu fjerner versioner til og med 8.1, bør i samme omgang fastlægge, hvordan det går med 8.2. Ellers begynder det samme spil forfra om få uger.
En enkel regel for serveren har vist sig at fungere: Der tilbydes kun grene, som PHP-projektet understøtter. Hver gren får ved opsætningen en dato, hvor den kontrolleres igen, med udgangspunkt i supportens udløb på php.net. Baggrunden for denne cyklus forklarer siden PHP-versioner og release-cyklus.
Den, der som hostingudbyder eller bureau har kunder på serveren, bør informere dem tidligt. En varsling med dato, en opfordring til omstilling og et tilbud om hjælp forhindrer, at websites falder ud på skæringsdagen. Kunder, hvis applikation ikke følger med, opdager på den måde i god tid, at en opdatering eller en migrering er på vej, og kan planlægge efter det.
Hvordan hjælper PHP SOS konkret?
- Vi finder ud af, hvilke websites, cronjobs og panelkomponenter der bruger hvilken PHP-version.
- Vi omstiller domæner i samråd til understøttede versioner og spærrer gamle handlere.
- Efter observationstiden fjerner vi gamle versioner kontrolleret og kontrollerer resultatet.
- Hvor applikationer ikke følger med, planlægger vi migreringen fra PHP 8.1 og ældre.
Ofte stillede spørgsmål
Hvorfor bør jeg fjerne ubrugte PHP-versioner?
Hver installeret version skal ved hver sårbarhed kontrolleres, opdateres og genstartes. Gamle grene som PHP 8.1 og ældre får ikke længere opdateringer fra PHP-projektet. Ubrugte versioner bringer kun risiko og arbejde.
Hvad er forskellen på at deaktivere og afinstallere?
Ved deaktivering forbliver versionen installeret, men kan ikke længere vælges på ny. Ved afinstallation fjernes den fra serveren. Deaktivering er det sikre mellemtrin for at se, om noget mangler.
Kan fjernelsen af en PHP-version forstyrre panelfunktioner?
Ja. Nogle komponenter i et panel, f.eks. webmail eller administrationsværktøjer, hænger på en bestemt PHP-version. Afklar sådanne afhængigheder, før I fjerner den; panelet gør som regel opmærksom på det.
Hvor lang bør observationstiden være?
Så lang, at alle regelmæssige forløb har kørt mindst én gang, altså også månedlige cronjobs og eksporter. Fastlæg varigheden sammen med fagafdelingerne.