Teil 9

Hosting ist ein System: erst Fakten feststellen, dann etwas ändern

Ein Hosting-Problem sieht schnell nach „das Skript ist kaputt“ aus, obwohl die eigentliche Ursache eine PHP-Version, fehlende Erweiterung, voller Speicher, Rechte, Netzwerkweg oder Mail-Transport ist. Terminalarbeit wird ruhiger, wenn zuerst die Maschine beschrieben wird, die tatsächlich vorhanden ist.

Dasselbe Projekt kann sich auf einem anderen Host anders verhalten

Die Dateien können identisch sein, der Laufzeitumgebung aber nicht. PHP-Version, geladene Erweiterungen, Dateisystemgrenzen, Eigentümer, Rechte, Uhrzeit, Netzwerkzugang und Serverrichtlinien bestimmen mit, was die Anwendung tun kann.

Darum lautet die erste nützliche Frage nicht „was soll ich ändern?“, sondern „in welcher Umgebung läuft das hier?“. Ein Terminal macht aus dieser vagen Umgebung überprüfbare Fakten.

Beginnen Sie mit einem Bildschirm voller Fakten

core zeigt aktuellen lil Core, PHP, Interface-Schicht, Extension-Datei, Updates, aktive Datei und Verzeichnis. doctor -q liefert einen kompakten Gesundheitsblick; sys host und sys uptime beschreiben Host und Laufzeit des Systems.

Eine gesunde Zusammenfassung beweist nicht, dass jede Anwendung gesund ist. Sie ist eine Ausgangszustand: ein schneller Weg zu erkennen, dass Maschine, Core oder Laufzeitumgebung nicht dem entsprechen, was Sie erwartet haben.

core

doctor -q

sys host

sys uptime

Eine PHP-Funktion existiert nur, wenn diese Laufzeitumgebung sie wirklich bereitstellt

php version, php modules und doctor extensions beantworten Fragen zur verfügbaren Funktionalität direkt. IMAP, SQLite, GD oder eine Kryptofunktion kann in einem Hosting-Tarif vorhanden und in einem anderen fehlen.

Eine fehlende Funktionalität ist etwas anderes als ein falscher Befehl. Eine klare klare Meldung über eine fehlende Funktion ist besser als zufällige Umgehungen: erst Erweiterung prüfen, dann entscheiden, ob sie aktiviert, ein anderes Werkzeug genutzt oder die Aufgabe verlagert wird.

php version

php modules

php info memory -c

doctor extensions

Freier Speicher, Verzeichnisgröße und Rechte sind verschiedene Fragen

disk . meldet die Kapazität des Dateisystems; disk . -r durchläuft bewusst den aktuellen Baum und berechnet seine Nutzung. stat zeigt, was ein Pfad tatsächlich ist. Rechte sind eine weitere Ebene: Eine Datei kann existieren und Platz frei sein, während PHP trotzdem nicht lesen oder schreiben darf.

Rechte nicht dadurch „reparieren“, dass alles schreibbar wird. Eigentümer und Modus prüfen, nur das kleinste notwendige Ziel ändern und danach erneut verifizieren. Rechte sind eine lokale Zugriffsgrenze, kein Ersatz für Authentifizierung oder Verschlüsselung.

disk .

disk . -r

stat .

Logs lesen, bevor gelöscht, neu gestartet oder geraten wird

log -l findet wahrscheinliche Logdateien. Ist die richtige Datei bekannt, lassen sich Anfang/Ende begrenzt lesen und literale Filter anwenden, ohne ein riesiges Log komplett in den Browser zu laden.

Eine nützliche Logzeile hat Kontext: Zeit, Komponente, Anfrage oder Operation und den tatsächlichen Fehler. Diesen Kontext vor jeder „Bereinigung“ bewahren. Viele schwierige Vorfälle werden gewöhnlich, sobald klar ist, wann der Fehler begann und was sich in der Nähe dieses Zeitpunkts änderte.

log -l

Umgebungswerte und Mail sind eigene Subsysteme, die gezielt getestet werden sollten

env zeigt Umgebungs-, Server- und Anfrage-Werte lesbar und maskiert dabei sensible Namen. So lässt sich etwa prüfen, welches temporäre Verzeichnis oder welche Serveradresse PHP sieht, ohne blind den gesamten Laufzeitumgebung auszugeben.

mail besitzt eine eigene Diagnosefläche: lokaler PHP-Mailtransport und IMAP-Verbindung sind nicht dasselbe. Eine Website kann perfekt rendern, während ausgehende Mail abgewiesen wird; IMAP kann schlicht wegen einer fehlenden Erweiterung fehlen. Testen Sie das Subsystem, von dem Sie wirklich abhängen.

env server SERVER_ADDR

env TMP

mail

Die Ausgangszustand vor der Reparatur speichern

Leiten Sie kompakte Berichte in diagnostics/ um, bevor Sie PHP-Einstellungen, Module, Rechte oder Hosting-Konfiguration ändern. Danach dieselben Berichte erneut sammeln und Fakten vergleichen statt sich auf „jetzt wirkt es besser“ zu verlassen.

Diese Gewohnheit gilt weit über lil-terminal hinaus. Unter Linux, macOS, Windows, in Containern und Control Panels folgt gute Diagnose demselben Muster: Umgebung identifizieren, Ebene isolieren, Belege sammeln, eine Sache ändern, prüfen.

md diagnostics

doctor -j > diagnostics/doctor.json -r

sys > diagnostics/system.txt -r

php version > diagnostics/php.txt -r

Als Skript aufbewahren

Speichern Sie dies als hosting-baseline.lil. Das Skript sammelt einen kompakten Diagnose-Momentaufnahme in diagnostics/, ohne Anwendungsdaten zu verändern. Bewahren Sie Momentaufnahmes vor und nach Hosting-Änderungen auf: Vergleichen ist meist hilfreicher als Erinnern.

#lil
@install md doctor sys php disk log env
md diagnostics
core > diagnostics/core.txt -r
doctor -q > diagnostics/doctor.txt -r
sys > diagnostics/system.txt -r
php version > diagnostics/php.txt -r
disk . > diagnostics/disk.txt -r
log -l > diagnostics/logs.txt -r
env server SERVER_ADDR > diagnostics/server.txt -r