cPanel & WHM-release: Nya funktioner och säkra uppdateringsstrategier

Gör en tydlig åtskillnad mellan cPanel och WHM

cPanel och WHM ingår visserligen i samma produkt, men hanterar olika nivåer på en webbhotellserver. cPanel är gränssnittet för ett enskilt webbhotellskonto: där hanterar kunderna bland annat domäner, e-postkonton, filer, databaser och de säkerhetsfunktioner som är aktiverade för deras konto. Vilka områden som är synliga och tillgängliga bestäms främst av funktionslistor, paket, tema, kontobehörigheter och webbhotellets konfiguration.

WHM är däremot den administrativa nivån i hostingpanelen. Där konfigurerar serveradministratörer konton, paket, funktionslistor och serveromfattande tjänster, medan leverantörer av managed hosting dessutom fastställer standarder för driftsättning, uppdateringar och support. Återförsäljare arbetar, beroende på de delegerade behörigheterna, med ett begränsat WHM-område; detta innebär inte automatiskt åtkomst till operativsystemet, globala tjänster eller alla serverriktlinjer.

En cPanel-uppdatering Det handlar därför inte bara om en ny vy i kundkontot. Ändringar kan påverka tilldelningen av teman, tillgängliga funktioner i paketmallar och automatiserade processer. På systemnivå tillkommer gränssnitt, behörighetskontroller, installerade tillägg och samspelet med operativsystemet. Release-nivån avgör vilken produktversion och vilken build som blir tillgängliga för servern, inte direkt synligheten för enskilda funktioner i ett visst kundkonto.

Ett praktiskt exempel är införandet av Meridian: Om temat fördefinieras via ett WHM-paket påverkar detta val gränssnittet för nya eller tilldelade konton. Om provisioneringsskript samtidigt använder API:er eller om supportanvisningar förutsätter vissa menyvägar måste temapolicy, paketmall och automatisering granskas tillsammans. Annars kan ett isolerat temabytet få funktionellt korrekta, men för kunder och support oväntade konsekvenser.

Skillnaden mellan versionsstatus, buildar och release-nivåer

För att kunna planera uppdateringar på ett tillförlitligt sätt måste Huvudversion, där build och release-nivåer betraktas separat. Enligt den dokumenterade informationen är cPanel & WHM 138 den senaste publicerade huvudversionen för produktion. Version 134 är den aktuella LTS-grenen med en längre, planerbar supportperiod. Version 136 förklarar visserligen ursprunget till enskilda ändringar, men den reguljära supporten upphörde redan i augusti 2026; den är därför inte ett lämpligt nytt uppgraderingsmål.

En huvudversion anger en release-gren, till exempel 138. Buildnumret specificerar en viss version inom denna gren; i ändringsloggen dokumenteras ändringar för 138 fram till build 138.0.13. Detta innebär inte att varje server får denna build eller ens uppdateras till 138. Det spelar också roll vilken offentlig distributionskanal servern använder.

Das Utgivningsnivå styr i vilken testfas och med vilken frekvens uppdateringar tillhandahålls. LTS, STABLE, RELEASE, CURRENT och EDGE är därför inte bara etiketter för samma programvaruversion. En server i LTS-nivån kan medvetet ligga på en annan huvudversionsgren än ett system i RELEASE-nivån, även om 138 i allmänhet är den senaste huvudversionen i produktion.

Särskild försiktighet bör iakttas vid versionsnummer med udda huvudnummer. Dessa ingår i utvecklingsversionen i EDGE-grenen och ska inte likställas med en publicerad produktionsversion. Deras existens bevisar varken att utvecklingen är avslutad eller att de är lämpliga för kundservrar. För ändringshantering och supportkommunikation bör administratörer därför alltid dokumentera den installerade versionen, den specifika builden och den valda nivån tillsammans.

Varför en uppdatering av cPanel kräver planering

En Versionsbyte I cPanel & WHM går det inte att ångra en uppgradering utan konsekvenser: En nedgradering till en tidigare huvudversion eller en tidigare release-nivå stöds inte. Vid större versionshopp går uppdateringsprogrammet igenom nödvändiga mellanversioner och kontrollerar kompatibiliteten före varje enskilt steg. Detta minskar antalet olämpliga uppgraderingsförsök, men ersätter inte en förhandsgranskning av den egna miljön utförd av en expert.

Tekniska förutsättningar kan hindra en uppdatering eller avgöra hur den ska genomföras. Till detta hör vilket operativsystem som används samt tillräckligt med ledigt lagringsutrymme under /usr/local/cpanel och aktiva spärrar i pakethanteraren. Ett dokumenterat exempel är att Ubuntu 22 inte kan uppdateras till cPanel & WHM 136. Sådana upplysningar är inte en uppmaning att byta till en äldre gren, utan ett skäl att i förväg klargöra operativsystemets version och den planerade migreringsvägen.

Förutom bassystemet ingår en kontrollista för driften i uppdateringen. De dokumenterade ändringarna av SSL-API-behörigheter och borttagna redovisningshjälpmedel visar att egna automatiseringar eller redovisningsintegrationer kan påverkas. Ändringar i Meridian och CSF gör dessutom tematilldelningar, funktionslistor, lokala brandväggsanpassningar och tillhörande tillägg till viktiga kontrollpunkter. Det här är inga kontroller som uppdateraren garanterar, utan beroenden som du måste utvärdera specifikt i din miljö.

Som en förebyggande åtgärd bör uppdateringen endast påbörjas om man har en återställningsplan som är anpassad till den egna miljön, en säkerhetskopia som redan har kontrollerats samt tydligt definierade ansvarsområden. I tillverkarens dokumentation rekommenderas att en ny huvudversion först testas på ett kompatibelt testsystem; först efter egna funktionstester bör produktionsmiljön följa efter på ett kontrollerat sätt. Eftersom en nedgradering inte är avsedd får en eventuell återställning från säkerhetskopior inte förväxlas med att återgå till en tidigare release-nivå.

Välj utgivningsnivåer utifrån verksamhetsmål

Release-nivån avgör vilken utvecklings- och testversion en server får; det är alltså ett driftsbeslut och inte bara en inställning för automatiska uppdateringar. LTS fokuserar under sin livslängd på säkerhetsuppdateringar, kritiska uppdateringar och kompatibilitetsuppdateringar. STABLE släpps mer sällan än RELEASE, medan RELEASE är den dokumenterade standarden för nya installationer.

CURRENT uppdateras oftare och kan innehålla funktioner som fortfarande är under utveckling. EDGE genomgår endast grundläggande tester och bör därför endast användas i kontrollerade testmiljöer. Udda huvudversionsnummer betecknar utvecklingsversioner i EDGE-grenen; de innebär varken att en enskild funktion är produktionsklar eller att den är säker att använda.

För planerbar delad hosting gäller att LTS är lämpligt när en funktionsnivå som kan beräknas på längre sikt är viktigare än ett nytt gränssnitt eller tidiga automatiseringsfunktioner. Det innebär inte att man ska avstå från uppdateringar: säkerhetsuppdateringar och kritiska korrigeringar ingår fortfarande i driften. RELEASE rekommenderar nya servrar, förutsatt att beroenden har kontrollerats i förväg och underhållsfönster har planerats in.

Valet bör dessutom passa testorganisationen. Precis som med andra hostingpaneler är det inte ett enskilt versionsnummer som är avgörande, utan samspelet mellan panelen, tillägg, operativsystem och kundstacken. Artikeln Planera Plesk-uppdateringar för webbhotellleverantörer på ett kontrollerat sätt förtydligar denna allmänna princip för en annan plattform. En fördröjning på flera arbetsdagar gäller, enligt uppdateringsdokumentationen, endast automatiska uppgraderingar till nästa huvudversion i RELEASE-nivån och endast under de villkor som anges där; EDGE, CURRENT, STABLE och LTS undantas från detta.

Se över nya funktioner i version 138

Version 138 innehåller Meridian som kundgränssnitt. För de som ansvarar för WHM är det inte bara den ändrade layouten som är relevant: val av tema, paketallokering, funktionslistor, utbildningsmaterial och supportrutiner måste stämma överens. Release-nivån avgör om den nödvändiga produkt- och buildversionen finns tillgänglig på servern; vilka områden ett enskilt konto kan se beror däremot främst på tema, paket, funktionslistor och leverantörskonfiguration.

Hos Meridian är en omfattande övergång utan riktlinjer riskabel. Konton som skapats med Meridian och som aldrig har använt Jupiter kan inte själva byta tillbaka till Jupiter. Administratörer kan dock ställa in temat via WHM, ett paket eller API:et. Därför bör paketmallar och kommunikationen till en liten pilotgrupp samordnas noggrant innan en bred införande sker.

WHM-API-1-funktionen set_primary_domain_docroot kan ändra dokumentroten för en primär domän och har portats tillbaka till versionerna 134 och 136. Detta underlättar driftsättning eller migrering, men ersätter inte en granskning av applikationen. Ett CMS, en omdirigering, filbehörigheter eller ett distributionsskript kan fortfarande förutsätta den tidigare sökvägen; en lyckad uppdatering känner inte automatiskt av detta tekniska antagande.

Från och med build 138.0.10 kräver API-funktioner för hämtning av SSL-certifikat och nycklar funktionen sslinstall eller . sslmanager. Begränsade funktionslistor och externa faktureringsintegrationer måste därför granskas noggrant. Dessutom har cPanel tagit bort föråldrade hjälpfiler från Cpanel/Accounting; direkta integreringar i enskilda faktureringslösningar kräver anpassning och innebär inte automatisk kompatibilitet.

Build 138.0.13 ändrar dessutom kraven på Återförsäljares ACL:er vid konfigurationen av namnservrar. Återförsäljare som hanterar DNS-kluster kan behöva behörigheten all, för att ändra serverns namnserverinställningar. Kontrollera därför före uppdateringen delegerade driftsmodeller, rollerna för de återförsäljare som används samt automatiserade DNS-klusterprocesser. Denna behörighet utökar åtkomsten avsevärt och bör inte tilldelas generellt, utan endast efter en roll- och säkerhetsgranskning.

Förbereda uppdateringar med inventering och pilotprojekt

Innan uppdateringen genomförs kartläggs först det aktuella läget: installerad version, release-nivå, operativsystem, plugin-program från tredjepartsleverantörer, egna API-anrop, brandväggsinställningar samt rutiner för säkerhetskopiering och återställning. Versionen kan fastställas i terminalen utan att systemet behöver ändras. Denna inventering kopplar samman tekniska komponenter med de ansvariga och förhindrar att oklara beroenden upptäcks först efter uppdateringen.

/usr/local/cpanel/cpanel -V

För en uppgradering kräver cPanel minst 5 GB ledigt lagringsutrymme under /usr/local/cpanel. Aktiva spärrar i pakethanteraren kan blockera processen; även operativsystemets sökväg kan medföra begränsningar beroende på version. Dessa punkter bör hanteras före underhållsfönstret, liksom en återställning vars förlopp och åtkomsträttigheter har klargjorts i förväg.

Därefter följer Iscensättning på ett separat, jämförbart testsystem. Där testas de relevanta paketen, temana, tilläggen och API-integrationerna med simulerade testkonton. Testa typiska arbetsflöden som inloggning, certifikatautomatisering, provisionering och drift av applikationer. Tillverkarens dokumentation rekommenderar uttryckligen att uppgraderingen först ska genomföras på ett testsystem innan produktionssystemet uppdateras.

En pilotdrift i produktionsmiljön ska hanteras separat. Verkliga kundkonton får endast inkluderas efter uttryckligt godkännande, i begränsad omfattning, under övervakning och med en tydligt angiven supportkanal. Fastställ i förväg vilka funktionstester som ska genomföras, vem som fattar beslut vid driftstörningar och vilka återställningsåtgärder som är möjliga för respektive konto eller server. Ett test på simulerade konton ersätter inte detta driftsgodkännande; omvänt är ett kundtest inte en riskfri staging.

I WHM uppdaterar „Upgrade to Latest Version“ till den senaste builden i den valda release-nivån. Funktionen garanterar därför inte att man byter till den allmänna senaste huvudversionen. Vid RELEASE kan dessutom en automatisk fördröjning gälla; en tvingad uppdatering kringgår denna. Säkerhetsrelaterade driftsåtgärder kring åtkomst, säkerhetskopior och brandvägg bör vidtas parallellt med uppdateringsprocessen; praktiska grunder förklaras i artikeln Säkerhet i kontrollpanelen för webbhotell i WHM och cPanel.

Driva Meridian och CSF på ett kontrollerat sätt

Meridian är mer än bara en ny kundvy i cPanel & WHM 138. Temat samlar uppgifter inom områden som webbplatser, e-post, filer, databaser, säkerhet och prestanda. För driften är det därför inte bara viktigt att gränssnittet ser bra ut, utan också att kunderna fortfarande tydligt kan hitta och utföra de avsedda uppgifterna med de funktioner de har tecknat sig för.

Innan godkännandet bör administratören utfärda en bindande Temapolicy Fastställa: Vilka konton tilldelas Meridian, vilka paketmallar tilldelas temat och vilka funktionslistor begränsar enskilda funktioner? Dessa inställningar hör ihop. Ett paket kan visserligen ange ett tema, men en funktion som saknas i funktionslistan förblir ändå otillgänglig för det tillhörande kontot.

I praktiken rekommenderas en begränsad pilotgrupp med representativa prisplaner, till exempel ett enkelt webbhotellskonto, ett konto med flera domäner och ett återförsäljarscenario. Kontrollera samtidigt typiska supportfunktioner som hantering av e-postkonton, databasåtkomst och sökning efter säkerhetsfunktioner. I kommunikationen med kunderna bör man ange tidpunkt, synliga förändringar och en tillgänglig supportkanal, istället för att presentera förändringen som en rent kosmetisk åtgärd.

Återgången till Jupiter måste ingå i denna planering. Konton som skapats med Meridian och som aldrig har använt Jupiter kan inte själva byta tillbaka till Jupiter. Administratörer kan fortfarande byta tema i WHM, via ett paket eller via API. Detta innebär att tematilldelningen och den ansvariga processen måste vara fastställda innan nya konton skapas med Meridian som standard.

CSF ska betraktas separat från huvudversionen av cPanel & WHM. WebPros tillhandahåller denna fork som ett separat versionerat paket för de cPanel & WHM-versioner som stöds. cpanel-csf klar; den installeras och uppdateras via cPanels pakethantering. Den tidigare aviserade migreringen av icke-stödda eller föråldrade CSF-installationer till den stödda forken har portats tillbaka till alla stödda cPanel- och WHM-versioner. Därför går det inte att på ett tillförlitligt sätt avgöra CSF-versionen enbart utifrån den installerade cPanel-versionen.

Som testunderlag behöver du den installerade cpanel-csf-paketstatus, den separata CSF-ändringsloggen, paketförvaltningens status och den lokala konfigurationen. Säkerhetskopiera och jämför egna regler, tillåtna- och förbjudna listor, hooks, aviseringar samt plugins eller distributionsskript. Kontrollera dessutom om externa verktyg kräver filer eller kommandon från en tidigare CSF-installation. cPanel-versionen är fortfarande relevant i det allmänna uppdateringssammanhanget, men ersätter varken denna paketkontroll eller utvärderingen av den lokala brandväggskonfigurationen.

Systematiskt avgränsa fel efter uppdateringen

Om funktioner slutar fungera efter en uppdatering inleds analysen med den valda release-nivån och den faktiskt installerade builden. Den generellt sett senaste huvudversionen är inte automatiskt den version som gäller för en server; det avgörande är vilken build som levererades inom den konfigurerade nivån. Notera dessutom tidpunkt, berörda konton och den specifika funktionen innan ändringar görs för att förmodat åtgärda felet.

Därefter analyserar du uppdateringsloggar och eventuella Uppgraderingsblockerare . Vid större versionshopp går uppdateringsprogrammet igenom mellanversioner och utför kompatibilitetskontroller; aktiva spärrar i pakethanteraren eller felaktiga operativsystemspår kan påverka processen. En avbruten eller endast delvis genomförd uppgradering motiverar inte ett blint försök att upprepa processen med tvingande alternativ, utan kräver först en utredning av den loggade orsaken.

Därefter testar du beroenden i en fast ordning: först egna WHM- eller cPanel-API-anrop, sedan funktionslistor och tematilldelningar, därefter plugins samt brandväggsregler. På så sätt kan felsökningen skilja en central behörighetsändring från ett enskilt kundkonto eller ett tillägg. Ändringar bör dokumenteras på ett överskådligt sätt och om möjligt först testas på en staging-miljö eller ett avgränsat konto.

Ett specifikt fel gäller SSL-automatiseringar: Från och med build 138.0.10 kräver API-funktioner för hämtning av SSL-certifikat och nycklar funktionen sslinstall eller . sslmanager. Om ett skript efter uppdateringen inte längre levererar certifikatdata bör du därför först kontrollera den funktionslista som tilldelats kontot och behörigheterna för den användning som används, inte bara nätverket eller certifikatbeståndet.

Även om dokumentrotarna har ändrats innebär ett lyckat API-anrop inte nödvändigtvis att webbplatsen fungerar. Funktionen set_primary_domain_docroot kan ställa in sökvägen för den primära domänen, medan CMS-konfigurationer, omdirigeringar, filbehörigheter, VHost-antaganden eller distributionsskript fortfarande pekar på den gamla sökvägen. Testa därför applikationens leverans, administrationsgränssnitt och skrivoperationer separat.

Även individuellt integrerade redovisningsintegrationer kan påverkas, eftersom föråldrade PHP-hjälpfiler från Cpanel/Accounting har tagits bort. Om en avräkningsprocess är affärskritisk och det inte finns någon kompatibel anpassning tillgänglig, är det lämpligare att avbryta driften för underhåll eller återställa systemet från en verifierad säkerhetskopia än att genomföra ytterligare en påtvingad uppdatering. Tillverkarens dokumentation och loggar utgör då grunden för en robust anpassningsplan.

Fastställa en lämplig uppdateringsstrategi som är bindande

En hållbar uppdateringsstrategi utgår från verksamhetsmålet, inte från det högsta synliga versionsnumret. Avgörande faktorer är supportperioden, behovet av nya funktioner, förväntad påverkan på kunderna, tillgänglig testkapacitet, beroenden av tredjepartsleverantörer och säkerhetsdriften. Dessa kriterier måste utvärderas för varje servergrupp: ett kluster för delad hosting, en ny hanterad plattform och ett internt testsystem medför olika risker och har olika förändringstakter.

LTS är lämpligt när en långsiktigt planerbar version är viktigare än ständigt nya funktioner. Under sin livslängd får denna gren främst säkerhetsuppdateringar, kritiska uppdateringar och kompatibilitetsuppdateringar. LTS innebär därför varken att uppdateringar avbryts, och det ersätter inte heller säkerhetskopiering, återställning och beroendetester. För etablerade erbjudanden inom delad hosting kan denna begränsning av funktionsförändringar göra supporten lättare att beräkna.

STABLE släpps mer sällan än RELEASE och har genomgått mer offentlig testning. RELEASE har full funktionalitet och är standard för nya installationer. Båda är lämpliga alternativ när nya funktioner behövs, men tester genomförs innan de införs i stor skala. Vilken av de två nivåerna som passar bäst beror därför på om tidig tillgänglighet eller en extra testperiod är viktigare för den aktuella plattformen.

CURRENT uppdateras oftare och kan innehålla funktioner som fortfarande är under utveckling. EDGE genomgår endast grundläggande tester och är uteslutande avsedd för kontrollerade testmiljöer. Udda huvudversionsnummer hör till utvecklingsutgåvor i EDGE-grenen; de innebär inte att en funktion är stabil nog för produktionsanvändning. För produktiva kundservrar är EDGE därför ingen genväg till tidigare funktioner.

Lägg den Policy för utgivning skriftligen fastställt: tillåtet antal instanser per serverklass, ansvariga för godkännanden, minimikrav för staging-testet, underhållsfönster och kriterier för avbrytande. En fördröjning på flera arbetsdagar gäller uteslutande för automatiska uppgraderingar till nästa huvudversion i RELEASE-nivån, förutsatt att uppgraderingen inte startas manuellt eller tvingas fram och endast hoppar över en huvudversion. EDGE, CURRENT, STABLE, LTS och fast angivna versionsnivåer omfattas inte av denna fördröjning.

Typiska felbeslut är EDGE i produktion, fastställandet av enskilda build-nummer i /etc/cpupdate.conf, avsaknaden av staging och antagandet att LTS inte kräver säkerhetsuppdateringar. Det är lika problematiskt att likställa en lyckad uppdateringskörning med ett tekniskt godkännande. Först när kundfunktioner, automatiseringar, plugins och skyddsmekanismer har testats i den planerade omfattningen blir en teknisk uppdatering en kontrollerad driftsövergång.