cPanel & WHM-release: nieuwe functies en veilige updatestrategieën

cPanel en WHM duidelijk van elkaar onderscheiden

cPanel en WHM maken weliswaar deel uit van hetzelfde product, maar bedienen verschillende niveaus van een hostingserver. cPanel is de interface voor een afzonderlijk hostingaccount: klanten beheren daar bijvoorbeeld domeinen, e-mailaccounts, bestanden, databases en de beveiligingsfuncties die voor hun account zijn vrijgegeven. Welke onderdelen zichtbaar en bruikbaar zijn, wordt vooral bepaald door functielijsten, pakketten, het thema, accountrechten en de configuratie van de hostingprovider.

WHM is daarentegen het administratieve niveau van het hostingpaneel. Serverbeheerders richten daarin accounts, pakketten, functielijsten en serverbrede diensten in, terwijl aanbieders van managed hosting bovendien normen vaststellen voor provisioning, updates en ondersteuning. Resellers werken, afhankelijk van de gedelegeerde rechten, met een beperkt WHM-gedeelte; dit houdt niet automatisch in dat ze toegang hebben tot het besturingssysteem, globale diensten of alle serverbeleidsregels.

A cPanel-update Het gaat dus niet alleen om een nieuwe weergave in het klantaccount. Wijzigingen kunnen invloed hebben op de toewijzing van thema’s, de beschikbare functies in pakketsjablonen en geautomatiseerde processen. Op systeemniveau komen daar nog interfaces, rechtencontroles, geïnstalleerde uitbreidingen en de interactie met het besturingssysteem bij. De release-tier bepaalt daarbij welke productversie en welke build beschikbaar komen voor de server, en niet direct de zichtbaarheid van afzonderlijke functies in een bepaald klantaccount.

Een praktisch voorbeeld is de invoering van Meridian: als het thema via een WHM-pakket wordt voorgeschreven, heeft deze keuze invloed op de gebruikersinterface van nieuwe of toegewezen accounts. Als provisioningsscripts tegelijkertijd gebruikmaken van API’s of als ondersteuningshandleidingen bepaalde menupaden vereisen, moeten het themabeleid, het pakketsjabloon en de automatisering gezamenlijk worden gecontroleerd. Een geïsoleerde themawijziging kan anders functioneel correcte, maar voor klanten en de ondersteuning onverwachte gevolgen hebben.

Het verschil tussen versienummers, builds en releaselevels

Voor een betrouwbare planning van updates moet Hoofdversie, waarbij build en release-tier afzonderlijk moeten worden beschouwd. Volgens de gedocumenteerde stand van zaken is cPanel & WHM 138 de meest recente gepubliceerde hoofdversie voor productie. Versie 134 is de huidige LTS-tak met een langere, voorspelbare ondersteuningsperiode. Hoewel versie 136 de oorsprong van afzonderlijke wijzigingen toelicht, liep de reguliere ondersteuning hiervoor al in augustus 2026 af; deze versie is daarom geen zinvol nieuw upgradedoel.

Een hoofdversie verwijst naar een releasetak, bijvoorbeeld 138. Het buildnummer geeft een specifieke stand binnen die tak aan; in de changelog staan voor 138 wijzigingen gedocumenteerd tot en met build 138.0.13. Dit betekent niet dat elke server deze build ontvangt of überhaupt naar 138 wordt bijgewerkt. Het is ook van belang welk openbaar distributiekanaal de server gebruikt.

De Release-niveau bepaalt in welke testfase en met welke frequentie updates worden uitgebracht. LTS, STABLE, RELEASE, CURRENT en EDGE zijn daarom niet louter labels voor dezelfde softwareversie. Een server in het LTS-niveau kan bewust op een andere hoofdversietak staan dan een systeem in het RELEASE-niveau, hoewel 138 over het algemeen de meest recente productieversie is.

Wees bijzonder voorzichtig met versienummers met een oneven hoofdnummer. Deze behoren tot de ontwikkelingsrelease in de EDGE-tak en mogen niet worden gelijkgesteld aan een gepubliceerde productieversie. Hun bestaan wijst noch op een voltooide ontwikkeling, noch op geschiktheid voor klantservers. Voor changemanagement en supportcommunicatie moeten beheerders daarom altijd de geïnstalleerde versie, de specifieke build en het gekozen niveau gezamenlijk documenteren.

Waarom een cPanel-update planning vereist

A Versiewisseling Bij cPanel & WHM kan dit niet zonder gevolgen ongedaan worden gemaakt: een downgrade naar een eerdere hoofdversie of een eerdere release-tier wordt niet ondersteund. Bij grotere sprongen werkt de updater via de vereiste tussenversies en controleert hij vóór elke stap de compatibiliteit. Dit vermindert het aantal ongeschikte upgrade-pogingen, maar vervangt geen technische voorafgaande controle van de eigen omgeving.

Technische vereisten kunnen een update blokkeren of het pad ervan bepalen. Hiertoe behoren het gebruikte besturingssysteem en voldoende vrije opslagruimte onder /usr/local/cpanel en actieve blokkades van de pakketbeheerder. Een gedocumenteerd voorbeeld hiervan is dat Ubuntu 22 niet kan worden bijgewerkt naar cPanel & WHM 136. Dergelijke opmerkingen zijn geen oproep om uit te wijken naar een oude branch, maar een aanleiding om vooraf duidelijkheid te scheppen over de stand van het besturingssysteem en het beoogde migratietraject.

Naast het basissysteem maakt ook een bedrijfspecifieke controlelijst deel uit van de update. Uit de gedocumenteerde wijzigingen in SSL-API-machtigingen en verwijderde accounting-hulpprogramma’s blijkt dat eigen automatiseringen of factureringsintegraties hierdoor kunnen worden beïnvloed. Meridian- en CSF-wijzigingen maken bovendien thematoewijzingen, feature lists, lokale firewallaanpassingen en bijbehorende uitbreidingen tot zinvolle controlepunten. Dit zijn geen controles die door de updater worden gegarandeerd, maar afhankelijkheden die je in je eigen omgeving gericht moet beoordelen.

Als voorzorgsmaatregel binnen het bedrijf mag de update pas worden gestart als er een herstelplan is dat is afgestemd op de eigen omgeving, een vooraf gecontroleerde back-upstatus en duidelijke verantwoordelijkheden. In de documentatie van de fabrikant wordt aanbevolen om een nieuwe hoofdversie eerst op een compatibel testsysteem te testen; pas na de eigen functionele tests mag de productie op gecontroleerde wijze volgen. Aangezien een downgrade niet is voorzien, mag een eventueel herstel vanuit back-ups niet worden verward met het terugzetten van de releaselayer.

Kies release-niveaus op basis van bedrijfsdoelstellingen

Het release-niveau bepaalt welke ontwikkelings- en testversie een server krijgt; het is dus een operationele beslissing en niet louter een instelling voor automatische updates. LTS richt zich tijdens zijn levensduur op beveiligings-, kritieke en compatibiliteitsupdates. STABLE wordt minder vaak uitgebracht dan RELEASE, terwijl RELEASE de gedocumenteerde standaard is voor nieuwe installaties.

CURRENT wordt vaker bijgewerkt en kan functies bevatten die nog in ontwikkeling zijn. EDGE wordt alleen aan basistests onderworpen en is daarom uitsluitend bedoeld voor gecontroleerde testomgevingen. Oneven hoofdversienummers duiden op ontwikkelingsreleases in de EDGE-tak; ze garanderen noch dat een functie productierijp is, noch dat deze veilig beschikbaar is.

Voor voorspelbare shared hosting is LTS Dit is zinvol wanneer een functieniveau dat op langere termijn voorspelbaar is, belangrijker is dan een nieuwe interface of vroege automatiseringsfuncties. Dit betekent niet dat updates moeten worden uitgesteld: beveiligings- en kritieke correcties blijven onderdeel van de bedrijfsvoering. RELEASE pleit voor nieuwe servers, mits afhankelijkheden vooraf zijn gecontroleerd en onderhoudsvensters zijn ingepland.

De keuze moet bovendien aansluiten bij de testorganisatie. Net als bij andere hostingpanelen is niet één specifiek versienummer doorslaggevend, maar de interactie tussen het paneel, de uitbreidingen, het besturingssysteem en de klantstack. Het artikel Plesk-updates voor hostingproviders op een gecontroleerde manier plannen illustreert dit algemene principe voor een ander platform. Volgens de updatedocumentatie geldt een vertraging van meerdere werkdagen alleen voor automatische upgrades naar de volgende hoofdversie in het RELEASE-niveau en uitsluitend onder de daar genoemde voorwaarden; EDGE, CURRENT, STABLE en LTS zijn hiervan uitgesloten.

Bekijk de nieuwe functies in versie 138

Versie 138 biedt Meridiaan als gebruikersinterface. Voor WHM-beheerders is niet alleen de gewijzigde lay-out van belang: de thema-keuze, pakkettoewijzing, functielijsten, trainingsmateriaal en ondersteuningsprocessen moeten op elkaar zijn afgestemd. De release-tier bepaalt of de vereiste product- en buildversie op de server beschikbaar is; welke onderdelen een afzonderlijk account te zien krijgt, hangt daarentegen vooral af van het thema, het pakket, de functielijsten en de configuratie van de provider.

Bij Meridian is een grootschalige overstap zonder beleid riskant. Accounts die met Meridian zijn aangemaakt en nog nooit Jupiter hebben gebruikt, kunnen niet zelf terugkeren naar Jupiter. Beheerders kunnen het thema echter instellen via WHM, een pakket of de API. Daarom moeten pakketsjablonen en de communicatie met een kleine pilotgroep voorafgaand aan de brede invoering bindend worden afgestemd.

De WHM-API-1-functie set_primary_domain_docroot kan de documentroot van een primair domein wijzigen en is teruggeporteerd naar 134 en 136. Dit vergemakkelijkt de provisioning of migratie, maar vervangt geen controle van de applicatie. Een CMS, een omleiding, bestandsrechten of een implementatiescript kunnen nog steeds uitgaan van het oude pad; een succesvolle uitvoering van de updater herkent deze functionele aanname niet automatisch.

Vanaf build 138.0.10 is de functie vereist voor API-functies waarmee SSL-certificaten en sleutels worden opgehaald sslinstall of sslmanager. Beperkte functielijsten en externe factureringsintegraties moeten daarom gericht worden gecontroleerd. Daarnaast heeft cPanel verouderde hulpbestanden verwijderd uit Cpanel/Accounting; directe integraties in individuele factureringsoplossingen vereisen aanpassingen; het gaat hier niet om compatibiliteit die automatisch wordt opgelost.

Build 138.0.13 wijzigt bovendien de vereisten voor Reseller-ACL's bij de configuratie van de naamservers. Resellers die DNS-clustering beheren, hebben mogelijk het recht nodig all, om de nameserver-instellingen van de server te wijzigen. Controleer daarom vóór de update de gedelegeerde bedrijfsmodellen, de rollen van de betrokken resellers en de geautomatiseerde DNS-clusterprocessen. Dit privilege vergroot de toegang aanzienlijk en mag niet zomaar worden toegekend, maar alleen na een rol- en veiligheidscontrole.

Updates voorbereiden met inventarisatie en proefprojecten

Vóór de update wordt eerst de huidige status in kaart gebracht: geïnstalleerde versie, release-tier, besturingssysteem, plug-ins van derden, eigen API-aanroepen, firewall-aanpassingen en back-up- en herstelprocedures. De versie kan zonder systeemwijzigingen in de terminal worden vastgesteld. Deze inventarisatie koppelt technische componenten aan de verantwoordelijken ervoor en voorkomt dat onduidelijke afhankelijkheden pas na de update aan het licht komen.

/usr/local/cpanel/cpanel -V

Voor een upgrade vereist cPanel minimaal 5 GB vrije opslagruimte onder /usr/local/cpanel. Actieve blokkades door pakketbeheerders kunnen het proces verhinderen; ook het pad van het besturingssysteem kan, afhankelijk van de versie, beperkingen opleggen. Deze punten moeten vóór het onderhoudsvenster worden afgehandeld, evenals een herstelbewerking waarvan de procedure en de toegangsrechten vooraf zijn vastgesteld.

Daarna volgt Staging op een apart, vergelijkbaar testsysteem. Daar worden de relevante pakketten, thema’s, plug-ins en API-integraties getest met nagebootste testaccounts. Test typische processen zoals aanmelding, certificaatautomatisering, provisioning en applicatiebeheer. De documentatie van de fabrikant raadt uitdrukkelijk aan om de upgrade eerst op een testsysteem te testen voordat het productiesysteem wordt bijgewerkt.

Een proefdraaien in de productie moet hier los van worden behandeld. Echte klantaccounts worden pas na uitdrukkelijke goedkeuring, op beperkte schaal, onder toezicht en via een vooraf gecommuniceerd ondersteuningskanaal bij het proces betrokken. Bepaal vooraf welke functietests worden uitgevoerd, wie er bij storingen beslist en welke herstelmaatregelen mogelijk zijn voor de betreffende account of server. Een test op nagebootste accounts vervangt deze operationele goedkeuring niet; omgekeerd is een klanttest geen risicovrije staging.

In WHM zorgt „Upgrade to Latest Version“ voor een update naar de nieuwste build van het geselecteerde releaselevel. De functie garandeert daarom niet dat er wordt overgeschakeld naar de algemeen nieuwste hoofdversie. Bij RELEASE kan bovendien een automatische vertraging van kracht zijn; een geforceerde update omzeilt deze. Beveiligingsgerelateerde maatregelen met betrekking tot toegangen, back-ups en de firewall moeten parallel aan het updateproces worden uitgevoerd; praktische basisprincipes worden in het artikel toegelicht Beveiliging van het hostingcontrolepaneel in WHM en cPanel.

Meridian en CSF op gecontroleerde wijze gebruiken

Meridian is in cPanel & WHM 138 meer dan alleen een nieuwe klantweergave. Het thema bundelt taken op gebieden zoals websites, e-mail, bestanden, databases, beveiliging en prestaties. Voor het gebruik is het daarom niet alleen van belang of de interface er visueel goed uitziet, maar ook of klanten de beoogde taken met hun geboekte functies nog steeds duidelijk kunnen vinden en uitvoeren.

Voordat de goedkeuring wordt gegeven, moet de beheerder een bindende Thema-beleid Vastleggen: welke accounts krijgen Meridian, welke pakketsjablonen wijzen het thema toe en welke functielijsten beperken afzonderlijke functies? Deze instellingen horen bij elkaar. Een pakket kan weliswaar een thema voorschrijven, maar een ontbrekende functie in de functielijst blijft voor het bijbehorende account toch niet beschikbaar.

In de praktijk is het raadzaam om een beperkte proefgroep te kiezen met representatieve tarieven, bijvoorbeeld een eenvoudig webhostingaccount, een account met meerdere domeinen en een resellerscenario. Controleer daarbij typische ondersteuningsprocessen zoals het beheer van mailboxen, toegang tot databases en het zoeken naar beveiligingsfuncties. In de communicatie met klanten moeten het tijdstip, zichtbare wijzigingen en een bereikbaar ondersteuningskanaal worden vermeld, in plaats van de overstap aan te kondigen als louter cosmetisch.

De terugkeer naar Jupiter moet deel uitmaken van deze planning. Accounts die met Meridian zijn aangemaakt en nog nooit Jupiter hebben gebruikt, kunnen niet zelf terugkeren naar Jupiter. Beheerders kunnen het thema nog steeds wijzigen in WHM, via een pakket of via de API. Hieruit volgt: de thematoewijzing en het bijbehorende proces moeten vastliggen voordat nieuwe accounts standaard met Meridian worden aangemaakt.

CSF moet los van de hoofdversie van cPanel & WHM worden beschouwd. WebPros biedt de fork aan als een apart gepubliceerd pakket voor de ondersteunde versies van cPanel & WHM. cpanel-csf klaar; het wordt geïnstalleerd en bijgewerkt via het cPanel-pakketbeheer. De eerder aangekondigde migratie van niet-ondersteunde of verouderde CSF-installaties naar de ondersteunde fork is teruggeporteerd naar alle ondersteunde cPanel- en WHM-versies. Daarom kan de CSF-status niet op betrouwbare wijze worden afgeleid uit de geïnstalleerde cPanel-build alleen.

Als testbasis heb je de geïnstalleerde Status van het cPanel-CSF-pakket, het afzonderlijke CSF-wijzigingslogboek, de status van het pakketbeheer en de lokale configuratie. Maak een back-up van je eigen regels, allow- en deny-lijsten, hooks, meldingen, plug-ins en implementatiescripten, en vergelijk deze. Controleer bovendien of externe tools bestanden of commando’s van een eerdere CSF-installatie vereisen. De cPanel-build blijft relevant in de algemene updatecontext, maar vervangt noch deze pakketcontrole, noch de beoordeling van de lokale firewallconfiguratie.

Fouten na de update systematisch opsporen

Als er na een update functies niet meer werken, begint de analyse met het geselecteerde release-niveau en de daadwerkelijk geïnstalleerde build. De algemeen meest recente hoofdversie is niet automatisch de stand van een server; bepalend is welke build binnen het geconfigureerde niveau is geleverd. Noteer bovendien het tijdstip, de betrokken accounts en de specifieke functie voordat er wijzigingen worden aangebracht om de vermeende fout te verhelpen.

Vervolgens analyseer je updatelogboeken en mogelijke Upgrade-blokkering uit. Bij grotere versiesprongen doorloopt de updater tussenversies en voert hij compatibiliteitscontroles uit; actieve blokkades door pakketbeheerders of onjuiste paden naar het besturingssysteem kunnen het proces beïnvloeden. Een afgebroken of slechts gedeeltelijk voltooide upgrade is geen reden om deze blindelings te herhalen met geforceerde opties, maar om eerst de vastgelegde oorzaak op te helderen.

Vervolgens test je de afhankelijkheden in een vaste volgorde: eerst je eigen WHM- of cPanel-API-aanroepen, daarna feature lists en thematoewijzingen, en vervolgens plug-ins en firewallregels. Op deze manier kan bij het opsporen van fouten een onderscheid worden gemaakt tussen een centrale wijziging in de machtigingen en een wijziging in een afzonderlijk klantenaccount of een uitbreiding. Wijzigingen moeten op een traceerbare manier worden gedocumenteerd en indien mogelijk eerst worden getest op een staging-omgeving of een afgeschermd account.

Een specifiek foutbeeld heeft betrekking op SSL-automatiseringen: vanaf build 138.0.10 hebben API-functies voor het ophalen van SSL-certificaten en sleutels de functie nodig sslinstall of sslmanager. Als een script na de update geen certificaatgegevens meer levert, controleer je daarom eerst de aan het account toegewezen functielijst en de machtigingen van de gebruikte toegang, en niet alleen het netwerk of de certificaatvoorraad.

Ook bij gewijzigde documentroots is een succesvolle API-aanroep nog geen garantie dat de website werkt. De functie set_primary_domain_docroot kan het pad van het primaire domein instellen, terwijl CMS-configuraties, omleidingen, bestandsrechten, VHost-aannames of implementatiescripts nog steeds naar het oude pad verwijzen. Test daarom de weergave, het beheergedeelte en de schrijfbewerkingen van de applicatie afzonderlijk.

Ook individueel geïntegreerde boekhoudsystemen kunnen hierdoor worden beïnvloed, omdat verouderde PHP-helperbestanden uit Cpanel/Accounting zijn verwijderd. Als een afrekeningsproces bedrijfskritisch is en er geen compatibele aanpassing beschikbaar is, zijn het stilleggen van het systeem of het terugzetten vanuit een geteste back-up passender dan nog een gedwongen update. Documentatie van de fabrikant en logbestanden vormen dan de basis voor een degelijk aanpassingsplan.

De juiste updatestrategie bindend vastleggen

Een haalbare updatestrategie begint bij de bedrijfsdoelstelling, niet bij het hoogste zichtbare versienummer. Doorslaggevend zijn de ondersteuningsperiode, de behoefte aan nieuwe functies, de verwachte impact op klanten, de beschikbare testcapaciteit, afhankelijkheden van derde partijen en het beveiligingsbeleid. Deze criteria moeten per servergroep worden beoordeeld: een shared-hostingcluster, een nieuw beheerd platform en een intern testsysteem hebben verschillende risico’s en wijzigingsfrequenties.

LTS is geschikt wanneer een op lange termijn planbare status belangrijker is dan voortdurend nieuwe functies. Gedurende de looptijd ontvangt deze tak vooral beveiligings-, kritieke en compatibiliteitsupdates. LTS betekent daarom niet dat updates worden opgeschort, noch vervangt het back-up-, herstel- en afhankelijkheidscontroles. Voor gevestigde shared-hostingaanbieders kan deze beperking van functionele wijzigingen de ondersteuning beter voorspelbaar maken.

STABLE wordt minder vaak uitgebracht dan RELEASE en heeft meer openbare tests ondergaan. RELEASE is functioneel compleet en de standaard voor nieuwe installaties. Beide zijn zinvolle opties wanneer nieuwe functies nodig zijn, maar er eerst tests plaatsvinden voordat ze op grote schaal worden geïntroduceerd. Welke van de twee niveaus geschikt is, hangt daarom af van de vraag of eerdere beschikbaarheid of een extra testperiode belangrijker is voor het betreffende platform.

CURRENT wordt vaker bijgewerkt en kan functies bevatten die nog verder worden ontwikkeld. EDGE wordt alleen aan basistests onderworpen en is uitsluitend bedoeld voor gecontroleerde testomgevingen. Oneven hoofdversienummers behoren tot ontwikkelingsreleases in de EDGE-tak; ze betekenen niet dat een functie stabiel beschikbaar is voor productie. Voor productieve klantservers is EDGE daarom geen snelkoppeling naar eerdere functies.

Leg de Release-beleid schriftelijk vastgelegd: toegestaan aantal servers per serverklasse, verantwoordelijken voor vrijgaven, minimale omvang van de staging-test, onderhoudsvensters en criteria voor afbreking. Een vertraging van meerdere werkdagen geldt uitsluitend voor automatische upgrades naar de volgende hoofdversie in het RELEASE-niveau, mits de upgrade niet handmatig of geforceerd wordt gestart en slechts één hoofdversie wordt overgeslagen. EDGE, CURRENT, STABLE, LTS en vastgelegde versienummers vallen niet onder deze vertraging.

Typische verkeerde beslissingen zijn EDGE in productie, het vastleggen van afzonderlijke buildnummers in /etc/cpupdate.conf, het ontbreken van staging en de veronderstelling dat LTS geen beveiligingsupdates vereist. Even problematisch is het om een succesvolle uitvoering van de updater gelijk te stellen aan een technische goedkeuring. Pas wanneer klantfuncties, automatiseringen, plug-ins en beveiligingsmechanismen in de geplande omvang zijn getest, wordt een technische update een gecontroleerde overgang naar de productieomgeving.