Ga naar de inhoud 
De CloudLinux PHP Selector regelt per account de specifieke PHP-versie en de geactiveerde extensies, zonder de serverbrede instelling te wijzigen. Ik laat zien hoe deze technologie in CageFS en LVE werkt, welke Grenzen van toepassing zijn en hoe je de selector in het dagelijks leven veilig gebruikt.
Centrale punten
- Architectuur: alt-php draait geïsoleerd in CageFS met een eigen naamruimte.
- Vereisten: CageFS actief, alt-php-pakketten geïnstalleerd, geschikte handler.
- Gebruik: Een versie kiezen, extensies inschakelen, php.ini-parameters aanpassen.
- Afbakening: MultiPHP Manager stelt de standaardinstelling in, Selector overschrijft deze in het account.
- Praktijk: Configuratie per site via Isolates voor gemengde projectomgevingen.
Hoe de CloudLinux PHP Selector intern werkt
Ik beschouw de selector als een schakelaar die in de persoonlijke CageFS-naamruimte van het account de gewenste oud-php-binaire bestanden weergeeft. Deze alternatieve versies staan los van de systeem-PHP en gebruiken hun eigen paden en configuratie. Zodra ik in het paneel de versie instel, maakt de aanroep van php binnen mijn gebruikerscontext gebruik van precies dit binaire bestand. De systeem-PHP blijft hierdoor onaangetast, waardoor beheerders hun betrouwbare Standaard . Doorslaggevend is de isolatie door LVE en CageFS: elk project draait in zijn eigen context, zodat afhankelijkheden en paden voor naburige projecten geen rol spelen.
Vereisten en compatibiliteit
Zonder een actieve CageFS werkt de selector niet, want alleen deze omgeving kapselt de Account netjes. Daarnaast moeten de ‘alt-php’-pakketten geïnstalleerd zijn, anders geeft het paneel geen keuzemogelijkheid weer. De bestaande PHP-handler van de server blijft bepalend; de selector vervangt deze niet, maar bouwt erop voort. Voor de keuze tussen CGI, FCGI, LSAPI of FPM helpt een korte PHP handler vergelijking, zodat ik de runtime-omgeving goed kan plannen. mod_php/DSO of bepaalde FPM-configuraties kunnen problemen opleveren als ze niet zijn afgestemd op gebruik met CageFS werden voorbereid.
Installatie- en beheerworkflow
In de praktijk stel ik de Selector altijd in volgens een duidelijke procedure: eerst installeer ik de benodigde oude PHP-versies inclusief de standaard-extensies (bijvoorbeeld 8.1, 8.2, 8.3, eventueel 7.4 voor legacy-systemen). Vervolgens initialiseer en update ik CageFS, zodat de nieuwe binaire bestanden in de gebruikersskeletten terechtkomen. In het configuratiescherm activeer ik de Selector en definieer ik welke versies en modules überhaupt worden aangeboden. Ik houd de lijst bewust beperkt om het RAM-gebruik te beperken en conflicten te voorkomen.
Ter kwaliteitscontrole test ik met een demo-account: phpinfo() op het web en php -v bij het inloggen via SSH laten me zien of de paden in CageFS correct worden weergegeven. Pas als CGI/FCGI/LSAPI-toepassingen correct werken en de lijst met extensies volledig wordt weergegeven, geef ik de functie vrij voor klanten. Updates installeer ik vervolgens per versie: nieuwe alt-php-pakketten komen eerst op staging-hosts terecht, daarna op productieknooppunten met een onderhoudsvenster en monitoring.
CloudLinux PHP Selector versus MultiPHP Manager
Ik maak een duidelijk onderscheid tussen het beheerdersniveau en het gebruikersniveau om misverstanden te voorkomen. De MultiPHP Manager stelt per domein of globaal vast welke systeembrede Versie geldt. Met de CloudLinux PHP Selector kan ik binnen mijn account een andere versie gebruiken, inclusief extensies en php.ini-instellingen. Als de standaardinstelling van het domein en de keuze via de Selector op een zinvolle manier overeenkomen, wordt de keuze van de gebruiker transparant toegepast. Zo beheren beheerders de veilige Basislijn-status, terwijl gebruikers flexibel kunnen overschakelen naar oudere of nieuwere versies.
Functies voor gebruikers: versie, uitbreidingen, php.ini
In de dagelijkse praktijk wissel ik van PHP-versie, afhankelijk van de behoeften van het project, bijvoorbeeld van 7.4 naar 8.2, zonder de rest van het account in gevaar te brengen. Via de grafische interface activeer ik de gewenste PHP uitbreidingen zoals intl, imagick, redis of opcache met slechts een paar muisklikken. Daarnaast pas ik typische php.ini-waarden zoals memory_limit, upload_max_filesize, post_max_size of max_execution_time. De beheerder stelt de whitelist van de aanpasbare richtlijnen in, waardoor veiligheidsgevoelige opties beschermd blijven. Voor oudere software gebruik ik indien nodig Hardened PHP-versies, die beveiligingsfixes bevatten voor verouderde Vrijgaven ter beschikking stellen.
De werking van php.ini en overerving
Belangrijk voor het dagelijks gebruik: welke php.ini is waar van toepassing? In de Selector definieer ik de standaardinstellingen voor het hele account. Daarnaast kunnen per map .user.ini-bestanden van kracht zijn, bijvoorbeeld in de documentroot of in submappen. Deze lokale bestanden overschrijven dan afzonderlijke richtlijnen, zonder de globale accountconfiguratie te wijzigen. Als ik met Apache werk, voeg ik bij geschikte handlers de benodigde waarden toe aan .htaccess via php_value/php_flag – mits de beheerder dit toestaat. Ik houd de configuratie overzichtelijk en gedocumenteerd: instellingen voor het hele account in de Selector, projectspecifieke fijnafstemming in .user.ini dicht bij de applicatie.
PHP-selector per site en isolaten
Vroeger deelden alle websites van één account dezelfde configuratie, wat het beheren van gemengde projectomgevingen bemoeilijkte. Met de ‘Per-Site PHP Selector’ wijs ik aan elke afzonderlijke site een eigen Versie en een bijpassende uitbreidingsset. Zo laat ik legacy-code op 7.x draaien, terwijl een nieuw project tegelijkertijd op 8.3 presteert. De besturing werkt momenteel het beste in cPanel-omgevingen en wordt via CLI-tools ingesteld. Voor bureaus biedt dit het duidelijke Voordelen, omdat ik migraties stapsgewijs en op een overzichtelijke manier kan uitvoeren.
CLI, Cron en automatisering
De web- en CLI-omgeving moeten dezelfde versie gebruiken, anders ontstaan er moeilijk te verklaren fouten. In cronjobs en deploy-scripts roep ik het gewenste binaire bestand expliciet aan, bijvoorbeeld via een pad naar de oude PHP-versie van het project. Composer, WP-CLI en Artisan draaien dan precies met de extensies en limieten van de gekozen omgeving. Ik controleer met `php -v` en `php -m` in het cron-log of de verwachte versie en het aantal modules actief zijn.
Voor massale wijzigingen zet ik in op automatisering: per klant kan ik via de CLI van versie en module wisselen en zo de volledige reseller-bestanden op één lijn brengen. Ik houd ook rekening met rollbacks door de vorige versie te noteren en indien nodig automatisch terug te schakelen. Zo blijven updates reproduceerbaar en voorkom ik inconsistente gemengde toestanden.
Grenzen en typische struikelblokken
De selector is geen vervanging voor een centraal beheer van de systeemversie; daarom blijft de standaardregeling bij de paneeltools. Als CageFS ontbreekt of als er geen alt-php-pakketten zijn geïnstalleerd, geldt de keuze van de gebruiker niet zoals verwacht. Gebruikers kunnen alleen de vrijgegeven richtlijnen wijzigen; meer gedetailleerde parameters blijven beveiligd. In omgevingen met concurrerende tools zorg ik ervoor dat niet twee systemen tegelijkertijd versies activeren. Wie functies per site buiten cPanel om wil gebruiken, moet workarounds inplannen of voorlopig bij functies per account blijven.Instellingen.
Prestaties en veiligheid
Meerdere versies op één server vereisen extra RAM, omdat elke oude PHP-versie haar eigen OPcache bijhoudt. Daarom beperk ik het aantal versies dat echt nodig is Vrijgaven en meet het verbruik. LVE-limieten en CageFS beschermen accounts tegen elkaar, wat vooral op drukbezette knooppunten belangrijk blijft. Voor verouderde systemen vertrouw ik op Hardened-PHP om kritieke kwetsbaarheden te dichten zonder meteen een codemigratie af te dwingen; details over alt-php en beveiligingsaspecten vat ik hier praktijkgericht samen: Oude PHP en beveiliging. Wie OPcache op een slimme manier inricht en onnodige uitbreidingen vanschakelt, waardoor de latentie laag blijft.
OPcache-fijnafstemming en caches
Ik stel de OPcache per versie en account zo in dat deze de werkelijke code-footprint weergeeft: stel `opcache.memory_consumption` niet te laag in, stel `revalidate_freq` op een redelijke waarde in en laat de timestamp-controles bij ontwikkelingsprojecten ingeschakeld. Bij implementaties met veel bestanden helpt het om vóór de volgende release oude caches te verwijderen, zodat er geen verouderde bytecode wordt uitgevoerd. Als er meerdere parallelle versies actief zijn, houd ik er rekening mee dat elke versie zijn eigen cache bijhoudt; dit beïnvloedt de opstarttijden en het RAM-geberuik. Ik gebruik APCu of Redis alleen als de applicatie daar baat bij heeft – minder modules verminderen het aanvalsoppervlak en het risico op incompatibiliteiten.
Toepassing bij agentschappen en wederverkopers
Ik maak een onderscheid tussen onderhoud en innovatie door oude projecten eerst te controleren en vervolgens gericht te migreren. Voor tests schakel ik afzonderlijke accounts bij wijze van proef over naar een nieuw Versie, meet laadtijden en bekijk foutlogboeken. Zo minimaliseer ik storingen en kan ik klanten concrete stappen aanreiken. Tegelijkertijd maak ik gebruik van instellingen per site, zodat de webshop, de landingspagina en de staging-omgeving elk een optimale omgeving hebben. Deze aanpak vermindert het aantal supportverzoeken en verhoogt de Planbaarheid voor updates.
Migratiehandleiding: van 7.x naar 8.x
Voor grotere overstappen werk ik volgens een checklist: eerst maak ik een staging-kopie aan en activeer ik daar de doelversie (bijv. 8.2/8.3). Vervolgens controleer ik verouderde functies in het foutenlogboek, schakel ik tijdelijk `display_errors` in de staging-omgeving in en maak ik gebruik van de eigen gezondheidscontroles van de applicatie. Kritieke extensies zoals intl, mbstring, gd, imagick, sodium en pdo_mysql test ik expliciet. Als Composer in het spel is, vernieuw ik de lockfiles en zorg ik ervoor dat de platformcontroles aansluiten bij de nieuwe PHP-versie. Pas als de functietests, caches en cronjobs vlekkeloos verlopen, schakel ik het productiedomein om. Voor het geval dat houd ik een rollback-stap achter de hand (vorige selector-status, OPcache-reset, cache-invalidatie).
Best practices voor aanbieders
Ik schakel CageFS consequent in en test de selector met demosites voordat ik de functie vrijgeef. De systeemwijde PHP-versie stel ik conservatief in, zodat de Standaard veilig blijft, terwijl klanten flexibel kunnen upgraden of downgraden. Voor populaire apps geef ik duidelijke versie-aanbevelingen, bijvoorbeeld „WordPress vanaf 8.1, webwinkels vanaf 8.2“, met korte toelichtingen. Ik sta alleen zinvolle extensies toe en verwijder experimentele modules die problemen zouden kunnen veroorzaken. Daarnaast houd ik alt-php-pakketten en Hardened-PHP-fixes bij huidige, zodat bekende kwetsbaarheden zijn verholpen.
Compatibiliteit per handler: overzicht
Voor een nette installatie controleer ik eerst welke handler in productie wordt gebruikt en of deze goed samenwerkt met CageFS. CGI, FastCGI en LSAPI werken doorgaans erg goed, terwijl DSO weinig zin heeft, omdat de isolatie daar dan onder lijdt. PHP-FPM kan draaien, maar vereist aangepaste Profielen en een duidelijke toewijzing van processen per account. suPHP heeft een lange geschiedenis, maar werkt vaak traag; op drukbezochte hosts geef ik de voorkeur aan LSAPI of FCGI. De volgende tabel geeft een beknopt overzicht van gangbare handelaar en de geschiktheid ervan met de Selector.
| handelaar | Geschiktheid met Selector | Kort bericht |
|---|---|---|
| CGI (suexec) | Goed | Eenvoudig, geïsoleerd; matige doorvoer, degelijke foutseparatie. |
| FastCGI (mod_fcgid) | Zeer goed | Snel, per account instelbaar; efficiënt gebruik van caching. |
| LiteSpeed/LSAPI | Zeer goed | Hoge prestaties, lage latentie; integratie met CageFS getest. |
| PHP-FPM | Gedeeltelijk | Werkt met een correcte toewijzing; speciale configuratie vereist. |
| mod_php/DSO | Zwak | Ontbrekende isolatie; niet geschikt voor CageFS/Selector. |
| suPHP | Voldoende | Betrouwbaar, maar traag; prima voor oudere hosts, anders moet je een vervanging regelen. |
Uitbreidingen en native bibliotheken: valkuilen
Naast PHP-modules spelen ook systeembibliotheken een rol. intl is afhankelijk van ICU-versies, imagick van ImageMagick – als pakketten niet op elkaar zijn afgestemd, ontbreken er functies of crashen processen. Ik zorg ervoor dat de alt-php-extensies consistent met hun afhankelijkheden worden geïnstalleerd en verwijder duplicaten. Voor versleutelde legacy-toepassingen controleer ik of er loaders beschikbaar zijn voor de gekozen versie; bij zeer recente PHP-releases kan dat ontbreken en is dan een tussenstap nodig (bijv. 8.1 in plaats van 8.3). In het algemeen geldt: zo min mogelijk modules, zoveel als nodig is, en wijzigingen altijd documenteren.
Problemen oplossen: typische foutpatronen
Als de ingestelde versie blijkbaar wordt genegeerd, controleer ik eerst CageFS en de geïnstalleerde oud-php-pakketten. Als het paneel geen extensies weergeeft, ontbreken er meestal pakketten of blokkeert de whitelist de weergave. Als een site onverwacht traag werkt, controleer ik de OPcache-groottes, de lijst met extensies en de keuze van de handler. Ontbrekende schrijfrechten in de tmp-map vertragen sessies en uploads, daarom leg ik paden en rechten duidelijk vast. Bij 502/504-fouten verhoog ik ter test de `max_execution_time` en stel ik realistische limieten in, voordat ik grotere Migratie-stappen plan.
Monitoring en diagnose tijdens het gebruik
Ik houd de observability simpel: per site stel ik een schoon `error_log` in en controleer ik de eerste uren na versie-updates extra nauwkeurig. Bij FPM/LSAPI maak ik in testfasen gebruik van slow-log- of debug-opties om knelpunten zichtbaar te maken. Op serverniveau houd ik LVE-limieten (CPU, RAM, IO, EP) in de gaten en bekijk ik pieken – wie regelmatig tegen limieten aanloopt, heeft baat bij tuning of een groter pakket. Met kleine belastingstests (bijv. warm-ups, cron-seeds) verzamel ik vergelijkingswaarden, zodat ik bij klachten snel kan vaststellen of het aan de applicatie, de handler, het netwerk of de limieten ligt.
Kort samengevat
De CloudLinux PHP Selector biedt mij de nodige Vrijheid, per account of site de juiste PHP-versie inclusief extensies te kiezen. De technologie is gebaseerd op LVE en CageFS, maakt gebruik van alt-php los van het systeem en respecteert de bestaande handler. Wie aan de vereisten voldoet, profiteert van isolatie, voorspelbare prestaties en minder supportaanvragen. Ik houd de standaardinstellingen conservatief, geef gebruikers gerichte speelruimte en documenteer duidelijke migratietrajecten. Zo blijft hosting betrouwbaar, flexibel en veilig – zowel voor WordPress, webwinkels als individuele projecten.
