Update naar Leap 15.4

Huishoudelijke mededeling

Ik heb de update naar OpenSUSE Leap 15.4 een tijdje voor me uit geschoven, want oei, en gedoe, en gaan er dan geen dingen stuk, maar vanavond besloot ik dat het toch eens tijd was.

Is uiteindelijk goed gegaan, behalve dat PHP-gedreven sites (waaronder deze) ineens niet meer werkten... Uiteindelijk bleek het simpel op te lossen, maar was het wel even zoeken.

Op deze pagina:

  • Een rechtendingetje
  • AppArmor
  • De socket
  • De bestanden

Een rechtendingetje

Na de update kreeg ik in eerste instantie 502-fouten te zien; dat geeft aan dat de webserver (Nginx) niet kan praten met de applicatieserver (PHP-FPM). Een blik op systemctl status php7-fpm geeft aan dat PHP-FPM inderdaad niet kon starten (au), en dat dat te maken had met het niet kunnen openen van een socket op op te luisteren (oei).

De tweede hobbel bestond uit het niet kunnen benaderen van de script-bestanden, waardoor het natuurlijk ook wat lastig wordt om die uit te voeren.

Beide problemen werden... niet zozeer veroorzaakt door AppArmor, maar hadden er wel mee te maken, bleek uit wat ge-duckduckgo.

AppArmor

Leap 15.4 wordt geleverd met AppArmor. Heel simpel gezegd: een extra verdedigingslinie om het geboefte te weren. Niet gehinderd door enige vorm van diepgaande kennis vergelijk ik het maar even met SELinux, waar ik ook vaker dan eens ruzie mee heb gehad.

Wat het onder andere kan doen, is de toegang tot delen van het bestandssysteem beperken voor bepaalde processen. Zoals in mijn geval PHP-FPM.

De socket

Het socket-probleem was nog het makkelijkste: in mijn (aangepaste en via Ansible uitgerolde configuratie van PHP-FPM liet ik de socket aanmaken in /var/run/php-fpm-<pool>.sock, en AppArmor verleende alleen goedkeuring aan /run/php-fpm/php*-fpm.sock. Dat was simpel aangepast, en daarna liet PHP-FPM zich in ieder geval weer opstarten.

De bestanden

De volgende foutmelding had te maken met een scriptbestand: "Unable to open primary script: /srv/www/doenietzomoeilijk.nl/releases/119/public/index.php (Permission denied)". Een beetje frutten in de AppArmor-configuratie om daar op de bonnefooi de paden aan proberen toe te voegen werkte niet, dus dat werd een tweede uitstapje naar DuckDuckGo. Daarmee kwam ik op de eerder gelinkte handleiding van OpenSUSE uit — tja, handleidingen, wie leest die dingen.

Uiteindelijk blijkt het onvolprezen YaST ook voor AppArmor wat configuratiemogelijkheden te hebben, waaronder de mogelijkheid om voor applicaties profielen aan te maken. Dat gedaan, et voilá, de boel werkt weer. Yay.

Ik moet me binnenkort maar eens wat in AppArmor gaan verdiepen, en in wat zo'n profiel nou precies inhoudt, en vooral, hoe ik dat in mijn Ansible-configuratie ga vastleggen. En daarna dan doorstomen naar PHP8, want daar is het wel eens tijd voor...

Publicatie: 1 november 2022. Max Max Updates Apparmor sysadmin php opensuse ansible linux selfhosting Permalink

Respons

Gerelateerd

Gebaseerd op tags:

  • Herstart misschien maar gewoon na een update ...of misschien ook maar niet Artikel, 1 oktober 2021 — 23 september 2022
  • Die keer dat ik de server opnieuw installeerde Straks vers het nieuwe jaar in Artikel, 29 december 2020
  • Hoe je eigen server je vrij merkbaar kan DoS-en Server-hardware is prachtig, behalve als het niet meewerkt Artikel, 15 april 2019 — 27 oktober 2022
  • Dotfiles bijhouden met Git en Stow Artikel, 27 december 2021 — 28 november 2022
  • Terugblik: de opnieuw geïnstalleerde server, een maand later TL;DR: hij doet het nog! Artikel, 29 januari 2021 — 25 januari 2021
  • Server-geneuzel Upgrade! Upgrade! Upgrade! Artikel, 28 maart 2020

Vorige:

Gedoe om Twitter Doorbraak voor de fediverse? 30 oktober

Volgende:

De Twintig Jaar-club ...give or take 4 november
  • Home
  • Over
  • Nu
  • Digitale tuin
  • Archief
↑