Zum Inhalt springen 
Der CloudLinux PHP Selector steuert pro Account die konkrete PHP-Version und die aktivierten Erweiterungen, ohne die serverweite Vorgabe zu ändern. Ich zeige, wie die Technik in CageFS und LVE greift, welche Grenzen gelten und wie du den Selector im Alltag sicher nutzt.
Zentrale Punkte
- Architektur: alt-php läuft isoliert in CageFS mit eigenem Namespace.
- Voraussetzungen: CageFS aktiv, alt-php-Pakete installiert, passender Handler.
- Nutzung: Version wählen, Extensions schalten, php.ini-Parameter anpassen.
- Abgrenzung: MultiPHP Manager setzt Default, Selector überschreibt im Account.
- Praxis: Per-Site-Konfiguration via Isolates für gemischte Projektlandschaften.
Wie der CloudLinux PHP Selector intern arbeitet
Ich sehe den Selector als Schalter, der im persönlichen CageFS-Namespace des Accounts die gewünschten alt-php-Binaries einblendet. Diese alternativen Versionen liegen getrennt vom System-PHP und verwenden eigene Pfade sowie eigene Konfiguration. Sobald ich im Panel die Version setze, greift der Aufruf von php innerhalb meines Benutzerkontexts auf genau diese Binary zu. Das System-PHP bleibt davon unberührt, wodurch Admins ihren verlässlichen Default halten. Entscheidend ist die Isolation durch LVE und CageFS: Jedes Projekt läuft im eigenen Kontext, sodass Abhängigkeiten und Pfade für Nachbarn keine Rolle spielen.
Voraussetzungen und Kompatibilität
Ohne aktives CageFS funktioniert der Selector nicht, denn erst diese Umgebung kapselt den Account sauber. Zusätzlich müssen die alt-php-Pakete installiert sein, sonst zeigt das Panel keine Wahlmöglichkeit an. Der vorhandene PHP-Handler des Servers bleibt weiter maßgeblich; der Selector ersetzt ihn nicht, sondern setzt auf ihm auf. Für die Wahl zwischen CGI, FCGI, LSAPI oder FPM hilft ein kurzer PHP-Handler Vergleich, damit ich die Laufzeitumgebung sauber plane. Problematisch können mod_php/DSO oder bestimmte FPM-Setups sein, wenn sie nicht für den Einsatz mit CageFS vorbereitet wurden.
Installations- und Admin-Workflow
In der Praxis richte ich den Selector immer über einen klaren Ablauf ein: Zuerst installiere ich die benötigten alt-php-Versionen samt Standard-Extensions (zum Beispiel 8.1, 8.2, 8.3, ggf. 7.4 für Legacy). Danach initialisiere und aktualisiere ich CageFS, damit die neuen Binaries in die Benutzerskelette gelangen. Im Control-Panel aktiviere ich den Selector und definiere, welche Versionen und Module überhaupt angeboten werden. Ich halte die Liste bewusst schlank, um den RAM-Footprint zu begrenzen und Konflikte zu vermeiden.
Zur Qualitätssicherung teste ich mit einem Demo-Account: phpinfo() im Web und php -v im SSH-Login zeigen mir, ob die Pfade in CageFS korrekt eingeblendet sind. Erst wenn CGI/FCGI/LSAPI-Fälle sauber funktionieren und die Extension-Liste vollständig erscheint, gebe ich die Funktion für Kunden frei. Updates spiele ich anschließend versioniert ein: Neue alt-php-Pakete landen zuerst auf Staging-Hosts, danach auf Produktionsknoten mit Wartungsfenster und Monitoring.
CloudLinux PHP Selector vs. MultiPHP Manager
Ich trenne klar zwischen der Admin-Ebene und der Nutzer-Ebene, um Missverständnisse zu vermeiden. Der MultiPHP Manager legt pro Domain oder global fest, welche systemweite Version gilt. Der CloudLinux PHP Selector erlaubt mir innerhalb meines Accounts eine abweichende Version samt Extensions und php.ini-Settings. Stimmen domainseitiger Default und Selector-Entscheidung sinnvoll überein, greift die Auswahl des Nutzers transparent. So steuern Admins den sicheren Baseline-Zustand, während Anwender flexibel auf ältere oder neuere Stände wechseln können.
Funktionen für Anwender: Version, Erweiterungen, php.ini
Im Alltag wechsle ich die PHP-Version je nach Projektbedarf, etwa von 7.4 auf 8.2, ohne den Rest des Accounts zu gefährden. Über die grafische Oberfläche aktiviere ich gewünschte PHP-Extensions wie intl, imagick, redis oder opcache mit wenigen Klicks. Zusätzlich passe ich typische php.ini-Werte wie memory_limit, upload_max_filesize, post_max_size oder max_execution_time an. Die Whitelist der änderbaren Direktiven setzt der Admin, wodurch sicherheitskritische Optionen geschützt bleiben. Für ältere Software nutze ich bei Bedarf Hardened-PHP-Versionen, die Sicherheitsfixes für abgekündigte Releases bereitstellen.
php.ini-Mechanik und Vererbung
Wichtig für den Alltag: Welche php.ini greift wo? Im Selector definiere ich die accountweiten Defaults. Zusätzlich können pro Verzeichnis .user.ini-Dateien wirken, etwa im Document-Root oder in Unterordnern. Diese lokalen Dateien überschreiben dann einzelne Direktiven, ohne die globale Account-Konfiguration zu verändern. Arbeite ich mit Apache, ergänze ich bei geeigneten Handlern benötigte Werte in .htaccess über php_value/php_flag – sofern der Admin das erlaubt. Ich halte die Konfiguration klar und dokumentiert: Accountweite Settings im Selector, projektspezifische Feinanpassungen in .user.ini nahe der Anwendung.
Per-Site PHP Selector und Isolates
Früher teilten alle Websites eines Accounts eine Konfiguration, was gemischte Projektlandschaften erschwert hat. Mit Per-Site PHP Selector vergebe ich je isolierter Site eine eigene Version und ein passendes Extension-Set. So lasse ich Legacy-Code auf 7.x laufen, während ein neues Projekt gleichzeitig auf 8.3 performt. Die Steuerung funktioniert derzeit am besten in cPanel-Umgebungen und wird über CLI-Werkzeuge eingerichtet. Für Agenturen bringt das klare Vorteile, weil ich Migrationen schrittweise und nachvollziehbar umsetzen kann.
CLI, Cron und Automatisierung
Web- und CLI-Umgebung sollten dieselbe Version nutzen, sonst entstehen schwer erklärbare Fehler. In Cronjobs und Deploy-Skripten rufe ich die gewünschte Binary explizit auf, zum Beispiel über einen Pfad auf die alt-php-Version des Projekts. Composer, WP-CLI und Artisan laufen dann exakt mit den Extensions und Limits der gewählten Umgebung. Ich prüfe mit php -v und php -m im Cron-Log, ob die erwartete Version und Modulmenge aktiv sind.
Für Massenänderungen setze ich auf Automatisierung: Pro Kunde kann ich Versionen und Module per CLI umschalten und so ganze Reseller-Bestände harmonisieren. Rollbacks plane ich gleich mit ein, indem ich die vorherige Version vermerke und bei Bedarf automatisch zurückschalte. So bleiben Updates reproduzierbar und ich vermeide inkonsistente Mischzustände.
Grenzen und typische Stolpersteine
Der Selector ersetzt keine zentrale Administration der Systemversion, daher bleibt die Default-Steuerung bei den Panel-Werkzeugen. Fehlt CageFS oder sind alt-php-Pakete nicht installiert, greift die Auswahl des Nutzers nicht wie erwartet. Nutzer ändern nur freigegebene Direktiven, tiefergehende Parameter bleiben geschützt. In Umgebungen mit konkurrierenden Tools sorge ich dafür, dass nicht zwei Systeme gleichzeitig Versionen schalten. Wer Per-Site-Funktionen außerhalb von cPanel einsetzen möchte, plant Workarounds ein oder bleibt vorerst bei per-Account-Settings.
Performance und Sicherheit
Mehrere Versionen auf einem Server erzeugen zusätzlichen RAM-Bedarf, weil jede alt-php-Version ihren eigenen OPcache führt. Ich beschränke deshalb die Vielfalt an wirklich benötigten Releases und messe den Verbrauch. LVE-Limits und CageFS schützen Accounts voreinander, was gerade auf gut ausgelasteten Knoten wichtig bleibt. Für Altsysteme setze ich auf Hardened-PHP, um kritische Lücken zu schließen, ohne sofort eine Code-Migration zu erzwingen; Details zu alt-php und Sicherheitsaspekten fasse ich hier praxisnah zusammen: Alt‑PHP und Sicherheit. Wer OPcache klug dimensioniert und unnötige Erweiterungen abschaltet, hält Latenzen niedrig.
OPcache-Feintuning und Caches
Ich stelle den OPcache pro Version und Account so ein, dass er den echten Code-Footprint abbildet: opcache.memory_consumption nicht zu knapp wählen, revalidate_freq sinnvoll setzen und Timestamp-Checks bei Entwicklungsprojekten aktiv lassen. Bei Deployments mit vielen Dateien hilft es, vor dem nächsten Release alte Caches zu verwerfen, damit kein veralteter Bytecode läuft. Falls mehrere parallele Versionen aktiv sind, bedenke ich, dass jede ihren eigenen Cache pflegt; das beeinflusst Warmup-Zeiten und RAM-Bedarf. APCu oder Redis nutze ich nur, wenn die Anwendung davon profitiert – weniger Module reduzieren Angriffsfläche und Inkompatibilitäten.
Einsatz in Agenturen und bei Resellern
Ich trenne Wartung und Innovation, indem ich alte Projekte erst prüfe und dann gezielt migriere. Für Tests schalte ich einzelne Accounts testweise auf eine neue Version, messe Ladezeiten und schaue mir Error-Logs an. So minimiere ich Ausfälle und kann Kunden konkrete Schritte nennen. Parallel setze ich per-Site-Settings ein, damit Shop, Landingpage und Staging je eine optimale Umgebung nutzen. Diese Vorgehensweise senkt Supportvolumen und erhöht die Planbarkeit bei Updates.
Migrations-Playbook: von 7.x auf 8.x
Für größere Sprünge arbeite ich nach Checkliste: Zuerst erstelle ich eine Staging-Kopie und aktiviere dort die Zielversion (z. B. 8.2/8.3). Dann prüfe ich Deprecations im Error-Log, aktiviere temporär display_errors in der Staging-Umgebung und nutze applicationseigene Health-Checks. Kritische Extensions wie intl, mbstring, gd, imagick, sodium und pdo_mysql teste ich explizit. Wenn Composer im Spiel ist, erneuere ich Lockfiles und stelle sicher, dass Platform-Checks zur neuen PHP-Version passen. Erst wenn Funktionstests, Caches und Cronjobs sauber laufen, schalte ich die Produktivdomain um. Für den Notfall halte ich einen Rollback-Schritt bereit (vorheriger Selector-Stand, OPcache-Reset, Cache-Invalidierung).
Best Practices für Anbieter
Ich aktiviere CageFS konsequent und teste den Selector mit Demosites, bevor ich die Funktion freigebe. Die systemweite PHP-Version setze ich konservativ, damit der Default sicher bleibt, während Kunden flexibel hoch- oder runterstufen können. Für populäre Apps gebe ich klare Versionspfade an, etwa „WordPress ab 8.1, Shops ab 8.2“ mit kurzen Begründungen. Ich lasse nur sinnvolle Extensions zu und entferne experimentelle Module, die Probleme erzeugen könnten. Außerdem halte ich alt-php-Pakete und Hardened-PHP-Fixes aktuell, damit bekannte Schwachstellen geschlossen sind.
Kompatibilität nach Handler: Überblick
Für ein sauberes Setup prüfe ich zuerst, welcher Handler produktiv genutzt wird und ob er mit CageFS zusammenspielt. CGI, FastCGI und LSAPI funktionieren in der Regel sehr gut, während DSO wenig Sinn ergibt, weil die Isolation dann leidet. PHP-FPM kann laufen, benötigt jedoch angepasste Profile und klare Prozesszuordnung je Account. suPHP kommt historisch vor, wirkt aber oft träge; auf stark frequentierten Hosts setze ich lieber auf LSAPI oder FCGI. Die folgende Tabelle zeigt eine verdichtete Sicht auf gängige Handler und ihre Tauglichkeit mit dem Selector.
| Handler | Tauglichkeit mit Selector | Kurznotiz |
|---|---|---|
| CGI (suexec) | Gut | Einfach, isoliert; moderater Durchsatz, solide Fehlertrennung. |
| FastCGI (mod_fcgid) | Sehr gut | Schnell, pro Account steuerbar; Caching effizient nutzbar. |
| LiteSpeed/LSAPI | Sehr gut | Hohe Performance, geringe Latenz; Integration mit CageFS erprobt. |
| PHP-FPM | Teils | Funktioniert mit sauberer Zuordnung; besondere Konfiguration nötig. |
| mod_php/DSO | Schwach | Fehlende Isolation; nicht für CageFS/Selector geeignet. |
| suPHP | Ausreichend | Sicher, aber träge; für ältere Hosts ok, sonst Ersatz einplanen. |
Erweiterungen und native Bibliotheken: Stolperfallen
Neben PHP-Modulen spielen Systembibliotheken eine Rolle. intl hängt an ICU-Versionen, imagick an ImageMagick – wenn Pakete nicht zueinander passen, fehlen Funktionen oder stürzen Prozesse ab. Ich sorge dafür, dass die alt-php-Extensions konsistent zu ihren Abhängigkeiten installiert sind und entferne Dubletten. Für verschlüsselte Legacy-Anwendungen prüfe ich, ob Loader für die gewählte Version verfügbar sind; bei sehr neuen PHP-Releases kann das fehlen und begründet dann eine Zwischenstufe (z. B. 8.1 statt 8.3). Generell gilt: so wenig Module wie möglich, so viel wie nötig, und Änderungen stets dokumentieren.
Troubleshooting: typische Fehlerbilder
Wenn die eingestellte Version scheinbar ignoriert wird, prüfe ich zuerst CageFS und die installierten alt-php-Pakete. Zeigt das Panel keine Extensions, fehlen meist Pakete oder die Whitelist blockiert die Anzeige. Läuft eine Site unerwartet langsam, kontrolliere ich OPcache-Größen, Extension-Liste und Handler-Wahl. Fehlende Schreibrechte im tmp-Ordner bremsen Sessions und Uploads, daher lege ich Pfade und Rechte klar fest. Bei 502/504-Fehlern erhöhe ich testweise max_execution_time und setze Limits realistisch, bevor ich größere Migrations-Schritte plane.
Monitoring und Diagnose im Betrieb
Ich halte die Observability einfach: Pro Site setze ich ein sauberes error_log und überprüfe nach Versionswechseln die ersten Stunden besonders genau. Bei FPM/LSAPI nutze ich Slow-Log- oder Debug-Optionen in Testphasen, um Engpässe sichtbar zu machen. Auf Serverebene beobachte ich LVE-Limits (CPU, RAM, IO, EP) und schaue mir Spitzen an – wer regelmäßig an Limits stößt, profitiert von Tuning oder einem größeren Paket. Mit kleinen Lasttests (z. B. Warmups, Cron-Seeds) sammle ich Vergleichswerte, damit ich bei Beschwerden schnell differenzieren kann, ob es an Anwendung, Handler, Netzwerk oder Limits liegt.
Kurz zusammengefasst
Der CloudLinux PHP Selector gibt mir die nötige Freiheit, pro Account oder Site die passende PHP-Version samt Extensions zu wählen. Die Technik baut auf LVE und CageFS auf, nutzt alt-php getrennt vom System und respektiert den vorhandenen Handler. Wer Voraussetzungen beachtet, profitiert von Isolation, planbarer Performance und geringeren Supportfällen. Ich halte Defaults konservativ, lasse Nutzern gezielte Spielräume und dokumentiere klare Migrationspfade. So bleibt Hosting verlässlich, flexibel und sicher – für WordPress, Shops und individuelle Projekte gleichermaßen.
