cPanel & WHM-udgivelse: Nye funktioner og sikre opdateringsstrategier

Skel klart mellem cPanel og WHM

cPanel og WHM er ganske vist en del af det samme produkt, men betjener forskellige niveauer på en hosting-server. cPanel er brugergrænsefladen for en enkelt hostingkonto: Her kan kunderne blandt andet administrere domæner, e-mail-konti, filer, databaser og de sikkerhedsfunktioner, der er aktiveret for deres konto. Hvilke områder der er synlige og kan bruges, bestemmes først og fremmest af funktionslister, pakker, tema, kontorettigheder og hostingudbyderens konfiguration.

WHM er derimod det administrative niveau i hostingpanelet. Her opretter serveradministratorer konti, pakker, funktionslister og serverdækkende tjenester, mens udbydere af managed hosting desuden fastlægger standarder for klargøring, opdateringer og support. Afhængigt af de delegerede rettigheder arbejder forhandlere med et begrænset WHM-område; dette medfører ikke automatisk adgang til operativsystemet, globale tjenester eller alle serverretningslinjer.

En cPanel-opdatering Det drejer sig derfor ikke kun om en ny visning i kundekontoen. Ændringer kan påvirke tildelingen af temaer, de tilgængelige funktioner i pakkeskabeloner og automatiserede processer. På systemniveau kommer der desuden grænseflader, rettighedskontrol, installerede udvidelser og samspillet med operativsystemet. Release-niveauet bestemmer her, hvilken produktversion og hvilken build der bliver tilgængelig for serveren, og ikke umiddelbart synligheden af enkelte funktioner i en bestemt kundekonto.

Et praktisk eksempel er indførelsen af Meridian: Hvis temaet fastlægges via et WHM-pakke, påvirker denne beslutning brugergrænsefladen for nye eller tildelte konti. Hvis provisioneringsscripts samtidig bruger API'er, eller hvis supportvejledninger forudsætter bestemte menupatier, skal temapolitik, pakkeskabelon og automatisering kontrolleres i sammenhæng. Et isoleret temaskift kan ellers have funktionelt korrekte, men for kunder og support uventede konsekvenser.

Skelne mellem versionsstatus, builds og udgivelsesniveauer

For at kunne udarbejde en pålidelig opdateringsplan skal Hovedversion, hvor build og release-niveau betragtes hver for sig. Ifølge den dokumenterede status er cPanel & WHM 138 den seneste udgivne hovedversion til produktion. Version 134 er den aktuelle LTS-gren med en længere, planlægbar supportperiode. Version 136 forklarer ganske vist baggrunden for enkelte ændringer, men den regulære support udløb allerede i august 2026; den er derfor ikke et fornuftigt nyt opgraderingsmål.

En hovedversion angiver en udgivelsesgren, for eksempel 138. Build-nummeret specificerer en bestemt status inden for denne gren; i changeloggen er der dokumenteret ændringer for 138 frem til build 138.0.13. Det betyder dog ikke, at alle servere modtager denne build eller overhovedet bliver opdateret til 138. Det afhænger også af, hvilken offentlig distributionskanal serveren bruger.

Das Udgivelsesniveau bestemmer, i hvilket teststadium og med hvilken hyppighed opdateringerne udgives. LTS, STABLE, RELEASE, CURRENT og EDGE er derfor ikke blot betegnelser for den samme softwareversion. En server i LTS-kategorien kan bevidst befinde sig på en anden hovedversionsgren end et system i RELEASE-kategorien, selvom 138 generelt er den nyeste produktionshovedversion.

Der skal udvises særlig forsigtighed ved versionsnumre med ulige hovednummer. Disse hører til udviklingsudgivelsen i EDGE-grenen og kan ikke sidestilles med en offentliggjort produktionsversion. Deres eksistens beviser hverken, at udviklingen er afsluttet, eller at de er egnede til kundeservere. I forbindelse med ændringsstyring og supportkommunikation bør administratorer derfor altid dokumentere den installerede version, den konkrete build og det valgte niveau samlet.

Hvorfor en cPanel-opdatering kræver planlægning

En Versionsskift I cPanel & WHM kan man ikke fortryde uden konsekvenser: En nedgradering til en tidligere hovedversion eller et tidligere udgivelsesniveau understøttes ikke. Ved større spring arbejder opdateringsprogrammet via de nødvendige mellemversioner og kontrollerer kompatibiliteten før de enkelte trin. Dette reducerer uhensigtsmæssige opgraderingsforsøg, men erstatter ikke en faglig forudgående kontrol af dit eget miljø.

Tekniske forudsætninger kan forhindre en opdatering eller bestemme dens forløb. Herunder hører det anvendte operativsystem, tilstrækkelig ledig lagerplads under /usr/local/cpanel og aktive blokeringer i pakkehåndteringen. Et dokumenteret eksempel er, at Ubuntu 22 ikke kan opgraderes til cPanel & WHM 136. Sådanne bemærkninger er ikke en opfordring til at skifte til en ældre gren, men en anledning til på forhånd at afklare operativsystemets version og den planlagte migrationsvej.

Ud over basissystemet indeholder opdateringen en driftsmæssig tjekliste. De dokumenterede ændringer af SSL-API-rettigheder og fjernede regnskabshjælpeprogrammer viser, at egne automatiseringer eller regnskabsintegrationer kan blive berørt. Ændringer i Meridian og CSF gør desuden tematildelinger, funktionslister, lokale firewall-tilpasninger og tilhørende udvidelser til relevante kontrolpunkter. Dette er ikke kontroller, som opdateringsprogrammet lover at udføre, men afhængigheder, som du målrettet skal vurdere i dit miljø.

Som en forebyggende foranstaltning i virksomheden bør opdateringen kun påbegyndes, hvis der foreligger en genopretningsplan, der passer til det egne miljø, en på forhånd kontrolleret sikkerhedskopi og klare ansvarsforhold. Producentens dokumentation anbefaler, at en ny hovedversion først testes på et kompatibelt testsystem; først efter egne funktionstests bør produktionsmiljøet følge efter under kontrollerede forhold. Da der ikke er mulighed for nedgradering, må en eventuel gendannelse fra sikkerhedskopier ikke forveksles med en tilbageførsel til et tidligere release-niveau.

Vælg udgivelsesniveauer efter driftsmål

Release-niveauet bestemmer, hvilken udviklings- og testversion en server modtager; det er altså en driftsbeslutning og ikke blot en indstilling for automatiske opdateringer. LTS fokuserer i sin levetid på sikkerheds-, kritiske og kompatibilitetsopdateringer. STABLE udgives sjældnere end RELEASE, mens RELEASE er den dokumenterede standard for nye installationer.

CURRENT opdateres oftere og kan indeholde funktioner, der stadig er under udvikling. EDGE gennemgår kun grundlæggende test og bør derfor udelukkende anvendes i kontrollerede testmiljøer. Ulige hovedversionsnumre angiver udviklingsudgivelser i EDGE-grenen; de er hverken et tegn på, at en enkelt funktion er klar til produktion, eller at den er tilgængelig på en sikker måde.

For planlagt shared hosting er LTS Det er fornuftigt, hvis en funktionsstatus, der kan forudsiges på længere sigt, er vigtigere end en ny brugergrænseflade eller tidlige automatiseringsfunktioner. Det betyder ikke, at opdateringer skal udskydes: Sikkerhedsopdateringer og kritiske rettelser forbliver en del af driften. RELEASE taler for nye servere, forudsat at afhængigheder er blevet kontrolleret på forhånd, og der er planlagt vedligeholdelsesvinduer.

Valget bør desuden passe til testorganisationen. Ligesom med andre hostingpaneler er det ikke et enkelt versionsnummer, der er afgørende, men samspillet mellem panel, udvidelser, operativsystem og kundestack. Artiklen Planlæg Plesk-opdateringer for hostingudbydere på en kontrolleret måde illustrerer dette generelle princip for en anden platform. Ifølge opdateringsdokumentationen gælder en forsinkelse på flere arbejdsdage kun for automatiske opgraderinger til den næste hovedversion i RELEASE-kategorien og kun under de der angivne betingelser; EDGE, CURRENT, STABLE og LTS er undtaget herfra.

Se nye funktioner i version 138

Version 138 introducerer Meridian som brugergrænseflade. For WHM-ansvarlige er det ikke kun det ændrede layout, der er relevant: Valg af tema, pakketildeling, funktionslister, undervisningsmateriale og supportprocesser skal passe sammen. Release-niveauet afgør, om den nødvendige produkt- og build-version er tilgængelig på serveren; hvilke områder en enkelt konto har adgang til, afhænger derimod primært af tema, pakke, funktionslister og udbyderkonfiguration.

Hos Meridian er en omfattende overgang uden en klar politik risikabel. Konti, der er oprettet med Meridian og aldrig har brugt Jupiter, kan ikke selv skifte tilbage til Jupiter. Administratorer kan dog angive temaet via WHM, et pakke eller API'en. Derfor bør pakkeskabeloner og kommunikationen til en lille pilotgruppe afstemmes på forhånd inden den bredere implementering.

WHM-API-1-funktionen set_primary_domain_docroot kan ændre dokumentroden for et primært domæne og er blevet tilbageporteret til version 134 og 136. Dette letter opsætning eller migrering, men erstatter ikke en kontrol af applikationen. Et CMS, en omdirigering, filrettigheder eller et implementeringsskript kan stadig forudsætte den hidtidige sti; en vellykket opdatering genkender ikke automatisk denne tekniske antagelse.

Fra build 138.0.10 kræver API-funktioner til hentning af SSL-certifikater og nøgler denne funktion sslinstall eller sslmanager. Begrænsede funktionslister og eksterne faktureringsintegrationer skal derfor undersøges nøje. Derudover har cPanel fjernet forældede hjælpefiler fra Cpanel/Accounting; direkte integrationer i individuelle afregningsløsninger kræver tilpasning og er ikke et kompatibilitetsproblem, der løses automatisk.

Build 138.0.13 ændrer desuden kravene til Forhandler-ACL'er ved konfigurationen af navneserverne. Forhandlere, der administrerer DNS-clustering, kan have brug for rettigheden all, for at ændre serverens navneserverindstillinger. Kontroller derfor inden opdateringen de delegerede driftsmodeller, de anvendte forhandleres roller og de automatiserede DNS-klynge-processer. Denne rettighed udvider adgangen betydeligt og bør ikke tildeles generelt, men kun efter en rolle- og sikkerhedskontrol.

Forbered opdateringer med lageropgørelse og pilotprojekt

Før opdateringen registreres først den aktuelle tilstand: installeret version, release-niveau, operativsystem, tredjeparts-plugins, egne API-kald, firewall-tilpasninger samt procedurer for sikkerhedskopiering og gendannelse. Versionen kan fastslås i terminalen uden at ændre systemet. Denne oversigt knytter tekniske komponenter sammen med de ansvarlige og forhindrer, at uklare afhængigheder først bliver synlige efter opdateringen.

/usr/local/cpanel/cpanel -V

Til en opgradering kræver cPanel mindst 5 GB ledig plads under /usr/local/cpanel. Aktive spærringer i pakkehåndteringen kan blokere processen; også operativsystemets sti kan sætte begrænsninger afhængigt af versionen. Disse punkter skal klargøres inden vedligeholdelsesvinduet, ligesom en gendannelse, hvis forløb og adgangsrettigheder er afklaret på forhånd.

Derefter følger Iscenesættelse på et separat, sammenligneligt testsystem. Her testes de relevante pakker, temaer, plugins og API-integrationer ved hjælp af simulerede testkonti. Test typiske processer såsom login, automatisering af certifikater, provisionering og drift af applikationer. Producentens dokumentation anbefaler udtrykkeligt, at opgraderingen først gennemføres på et testsystem, inden produktionssystemet opdateres.

En pilotfase i produktionen skal behandles separat. Rigtige kundekonti inddrages kun efter udtrykkelig godkendelse, i begrænset omfang, under overvågning og med en fastlagt supportprocedure. Fastlæg på forhånd, hvilke funktionstests der skal udføres, hvem der træffer beslutninger i tilfælde af fejl, og hvilke genopretningsmuligheder der er for den pågældende konto eller server. En test på simulerede konti erstatter ikke denne driftsgodkendelse; omvendt er en kundetest ikke en risikofri staging.

I WHM opdaterer „Upgrade to Latest Version“ til den nyeste build i det valgte udgivelsesniveau. Funktionen garanterer derfor ikke, at der skiftes til den generelt nyeste hovedversion. Ved RELEASE kan der desuden være en automatisk forsinkelse; en tvungen opdatering omgår denne. Sikkerhedsrelevante driftsforanstaltninger vedrørende adgang, sikkerhedskopier og firewall bør vedligeholdes sideløbende med opdateringsprocessen; de praktiske grundprincipper forklares i artiklen Sikkerhed i hosting-kontrolpanelet i WHM og cPanel.

Kontrolleret drift af Meridian og CSF

Meridian er mere end blot en ny kundevisning i cPanel & WHM 138. Temaet samler opgaver inden for områder som hjemmesider, e-mail, filer, databaser, sikkerhed og ydeevne. For driften er det derfor ikke kun afgørende, om brugergrænsefladen ser godt ud, men også om kunderne fortsat klart kan finde og udføre de tiltænkte opgaver med de funktioner, de har bestilt.

Inden frigivelsen bør administratoren udarbejde en bindende Temapolitik Fastlæg: Hvilke konti skal have Meridian, hvilke pakkeskabeloner skal tildeles temaet, og hvilke funktionslister begrænser de enkelte funktioner? Disse indstillinger hører sammen. En pakke kan ganske vist angive et tema, men en funktion, der mangler i funktionslisten, vil alligevel ikke være tilgængelig for den tilhørende konto.

I praksis anbefales det at nøjes med en begrænset pilotgruppe med repræsentative prispakker, f.eks. en simpel webhosting-konto, en konto med flere domæner og et forhandler-scenarie. Undersøg i den forbindelse typiske supportkanaler såsom postkasseadministration, databaseadgang og søgning efter sikkerhedsfunktioner. Kundekommunikationen bør angive tidspunkt, synlige ændringer og en tilgængelig supportkanal i stedet for at annoncere ændringen som rent kosmetisk.

Overgangen tilbage til Jupiter skal indgå i denne planlægning. Konti, der er oprettet med Meridian og aldrig har brugt Jupiter, kan ikke selv skifte tilbage til Jupiter. Administratorer kan fortsat ændre temaet i WHM, via et pakke eller via API. Det betyder, at tema-tildelingen og den relevante proces skal være fastlagt, før nye konti oprettes med Meridian som standard.

CSF skal betragtes separat fra hovedversionen af cPanel og WHM. WebPros stiller denne fork til rådighed som et separat versioneret pakke til de understøttede versioner af cPanel og WHM. cpanel-csf klar; den installeres og opdateres via cPanel-pakkehåndteringen. Den tidligere annoncerede migrering af ikke-understøttede eller forældede CSF-installationer til den understøttede fork er blevet tilbageført til alle understøttede cPanel- og WHM-versioner. Derfor kan CSF-versionen ikke pålideligt udledes alene ud fra den installerede cPanel-build.

Som testgrundlag skal du have den installerede cPanel-CSF-pakkestatus, den separate CSF-ændringslog, status for pakkehåndteringen og den lokale konfiguration. Sikkerhedskopier og sammenlign dine egne regler, tilladelses- og afvisningslister, hooks, notifikationer samt plugins eller implementeringsscripts. Kontroller desuden, om eksterne værktøjer forudsætter filer eller kommandoer fra en tidligere CSF-installation. cPanel-buildet er stadig relevant i den generelle opdateringssammenhæng, men erstatter hverken denne pakkekontrol eller vurderingen af den lokale firewall-konfiguration.

Systematisk indsnævring af fejl efter opdateringen

Hvis visse funktioner ikke fungerer efter en opdatering, starter analysen med det valgte release-niveau og den faktisk installerede build. Den generelt nyeste hovedversion er ikke automatisk den version, der er installeret på en server; det afgørende er, hvilken build der blev leveret i det konfigurerede niveau. Notér desuden tidspunktet, de berørte konti og den konkrete funktion, inden der foretages ændringer med henblik på den formodede fejlretning.

Derefter gennemgår du opdateringslogfiler og eventuelle Opgraderingsblokker . Ved større versionsspring gennemgår opdateringsprogrammet mellemversioner og udfører kompatibilitetstests; aktive blokeringer i pakkehåndteringen eller forkerte operativsystemstier kan påvirke forløbet. En afbrudt eller kun delvist gennemført opgradering er ikke en grund til blindt at gentage den med tvungne indstillinger, men kræver først en afklaring af den loggede årsag.

Derefter tester du afhængighederne i en fast rækkefølge: først egne WHM- eller cPanel-API-kald, derefter funktionslister og tematildelinger, efterfulgt af plugins og firewall-regler. På denne måde adskiller fejlfindingen en central ændring af adgangsrettigheder fra en enkelt kundekonto eller en udvidelse. Ændringer bør dokumenteres på en overskuelig måde og om muligt først testes på en staging-miljø eller en afgrænset konto.

Et konkret fejlscenarie vedrører SSL-automatiseringer: Fra build 138.0.10 kræver API-funktioner til hentning af SSL-certifikater og nøgler funktionen sslinstall eller sslmanager. Hvis et script efter opdateringen ikke længere leverer certifikatdata, skal du derfor først kontrollere den funktionsliste, der er tildelt kontoen, og de rettigheder, der er knyttet til den anvendte adgang, og ikke kun netværket eller certifikatbeholdningen.

Selv hvis dokumentrødderne ændres, er et vellykket API-kald ikke i sig selv nogen garanti for, at hjemmesiden fungerer. Funktionen set_primary_domain_docroot kan indstille stien til det primære domæne, mens CMS-konfigurationer, omdirigeringer, filrettigheder, VHost-indstillinger eller implementeringsscripts fortsat peger på den gamle sti. Test derfor applikationens visning, administrationsområde og skriveoperationer hver for sig.

Også individuelt integrerede regnskabsintegrationer kan blive berørt, fordi forældede PHP-hjælpefiler fra Cpanel/Accounting er blevet fjernet. Hvis en afregningsproces er forretningskritisk, og der ikke findes en kompatibel tilpasning, er det mere hensigtsmæssigt at standse vedligeholdelsen eller gendanne systemet fra en testet sikkerhedskopi end at gennemføre endnu en tvungen opdatering. Producentens dokumentation og logfiler danner i så fald grundlaget for en robust tilpasningsplan.

Fastlægge den rette opdateringsstrategi på en bindende måde

En bæredygtig opdateringsstrategi tager udgangspunkt i driftsmålet, ikke i det højeste synlige versionsnummer. Afgørende faktorer er supportperioden, behovet for nye funktioner, den forventede indvirkning på kunderne, den tilgængelige testkapacitet, afhængigheder af tredjepartsleverandører og sikkerhedsdriften. Disse kriterier skal vurderes for hver servergruppe: Et shared hosting-cluster, en ny managed platform og et internt testsystem har forskellige risici og ændringsfrekvenser.

LTS er velegnet, når en langsigtet planlægbar status er vigtigere end løbende nye funktioner. I løbet af sin levetid modtager denne gren primært sikkerheds-, kritiske og kompatibilitetsopdateringer. LTS betyder derfor hverken, at opdateringer suspenderes, eller at det erstatter backup-, gendannelses- og afhængighedstests. For etablerede shared hosting-tilbud kan denne begrænsning af funktionsændringer gøre supporten lettere at beregne.

STABLE udgives sjældnere end RELEASE og har gennemgået mere offentlig testning. RELEASE er funktionsmæssigt komplet og er standarden for nye installationer. Begge er fornuftige valgmuligheder, når der er behov for nye funktioner, men der skal foretages test før en bred implementering. Hvilket af de to niveauer der passer bedst, afhænger derfor af, om tidligere tilgængelighed eller en ekstra testperiode er vigtigst for den pågældende platform.

CURRENT opdateres oftere og kan indeholde funktioner, der stadig er under udvikling. EDGE gennemgår kun grundlæggende test og er udelukkende beregnet til kontrollerede testmiljøer. Ulige hovedversionsnumre hører til udviklingsudgivelser i EDGE-grenen; de er ikke et tegn på, at en funktion er stabil nok til at blive taget i brug i produktionsmiljøet. For produktive kundeservere er EDGE derfor ikke en genvej til tidligere funktioner.

Læg den Udgivelsespolitik fastlagt skriftligt: tilladt antal dyr pr. serverklasse, ansvarlige for godkendelser, minimumsomfanget af staging-testen, vedligeholdelsesvinduer og kriterier for afbrydelse. En forsinkelse på flere arbejdsdage gælder udelukkende for automatiske opgraderinger til den næste hovedversion i RELEASE-niveauerne, forudsat at opgraderingen ikke startes manuelt eller tvunget og kun springer én hovedversion over. EDGE, CURRENT, STABLE, LTS og fastlagte versionsstandarder er ikke omfattet af denne forsinkelse.

Typiske fejlbeslutninger er EDGE i produktionen, fastlæggelsen af enkelte build-numre i /etc/cpupdate.conf, manglende staging og antagelsen om, at LTS ikke kræver sikkerhedsopdateringer. Det er ligeledes problematisk at sidestille en vellykket opdateringskørsel med en faglig godkendelse. Først når kundefunktioner, automatiseringer, plugins og beskyttelsesmekanismer er testet i det planlagte omfang, bliver en teknisk opdatering til en kontrolleret driftsændring.