Wersja cPanel & WHM: nowe funkcje i bezpieczne strategie aktualizacji

Wyraźnie odróżnić cPanel od WHM

Chociaż cPanel i WHM należą do tego samego produktu, obsługują różne poziomy serwera hostingowego. cPanel jest to interfejs dla pojedynczego konta hostingowego: klienci zarządzają tam między innymi domenami, skrzynkami e-mailowymi, plikami, bazami danych oraz funkcjami bezpieczeństwa udostępnionymi dla ich konta. To, które sekcje są widoczne i dostępne, zależy przede wszystkim od listy funkcji, pakietów, szablonu, uprawnień do konta oraz konfiguracji dostawcy usług hostingowych.

Z kolei WHM stanowi poziom administracyjny panelu hostingowego. Administratorzy serwerów konfigurują w nim konta, pakiety, listy funkcji oraz usługi obejmujące cały serwer, podczas gdy dostawcy hostingu zarządzanego dodatkowo ustalają standardy dotyczące wdrażania, aktualizacji i wsparcia technicznego. Resellerzy, w zależności od przyznanych uprawnień, korzystają z ograniczonego zakresu WHM; nie oznacza to automatycznie dostępu do systemu operacyjnego, usług globalnych ani wszystkich zasad serwera.

A Aktualizacja cPanel Dotyczy to zatem nie tylko nowego widoku na koncie klienta. Zmiany mogą wpłynąć na przypisanie motywów, dostępne funkcje w szablonach pakietów oraz zautomatyzowane procesy. Na poziomie systemu dochodzą do tego interfejsy, kontrole uprawnień, zainstalowane rozszerzenia oraz interakcja z systemem operacyjnym. Poziom wydania (Release Tier) określa, która wersja produktu i która kompilacja (build) będą dostępne dla serwera, a nie bezpośrednio widoczność poszczególnych funkcji na konkretnym koncie klienta.

Praktycznym przykładem jest wdrożenie motywu Meridian: jeśli motyw jest przypisany za pośrednictwem pakietu WHM, decyzja ta wpływa na wygląd nowych lub przypisanych kont. Jeśli skrypty provisioningu korzystają jednocześnie z interfejsów API lub instrukcje pomocy technicznej zakładają określone ścieżki menu, należy wspólnie sprawdzić zasady dotyczące motywów, szablon pakietu oraz automatyzację. W przeciwnym razie izolowana zmiana motywu może mieć skutki poprawne pod względem funkcjonalnym, ale nieoczekiwane dla klientów i działu pomocy technicznej.

Rozróżnienie między numerami wersji, kompilacjami i poziomami wydania

Aby zapewnić solidne planowanie aktualizacji, należy Wersja główna, należy rozpatrywać osobno poziomy kompilacji i wydania. Zgodnie z udokumentowanym stanem cPanel & WHM 138 jest najnowszą opublikowaną główną wersją produkcyjną. Wersja 134 stanowi aktualną gałąź LTS z dłuższym, przewidywalnym okresem wsparcia. Wersja 136 wyjaśnia co prawda pochodzenie poszczególnych zmian, jednak jej regularne wsparcie techniczne zakończyło się już w sierpniu 2026 r.; w związku z tym nie stanowi ona sensownego celu aktualizacji.

Wersja główna określa gałąź wydania, na przykład 138. Numer kompilacji precyzuje konkretny stan w ramach tej gałęzi; w dzienniku zmian dla wersji 138 udokumentowano zmiany aż do kompilacji 138.0.13. Nie oznacza to jednak, że każdy serwer otrzyma tę kompilację lub w ogóle zostanie zaktualizowany do wersji 138. Istotne znaczenie ma również to, z jakiego publicznego kanału dystrybucji korzysta serwer.

Das Poziom wydania określa, na jakim poziomie testowania i w jakim tempie udostępniane są aktualizacje. LTS, STABLE, RELEASE, CURRENT i EDGE nie są zatem jedynie etykietami oznaczającymi ten sam stan oprogramowania. Serwer w warstwie LTS może świadomie znajdować się na innej gałęzi głównej wersji niż system w warstwie RELEASE, mimo że 138 jest ogólnie najnowszą główną wersją produkcyjną.

Szczególną ostrożność należy zachować w przypadku numerów wersji o nieparzystej liczbie głównej. Należą one do wydania rozwojowego w gałęzi EDGE i nie należy ich utożsamiać z opublikowaną wersją produkcyjną. Ich istnienie nie świadczy ani o zakończeniu prac rozwojowych, ani o przydatności do wdrożenia na serwerach klientów. W związku z tym administratorzy powinni zawsze dokumentować zainstalowaną wersję, konkretną kompilację oraz wybrany poziom (tier) na potrzeby zarządzania zmianami i komunikacji z działem wsparcia technicznego.

Dlaczego aktualizacja cPanel wymaga odpowiedniego planowania

A Zmiana wersji W przypadku cPanel & WHM cofnięcie zmian nie jest możliwe bez konsekwencji: nie jest obsługiwane przejście na wcześniejszą wersję główną lub niższy poziom wydania. W przypadku większych skoków aktualizator przechodzi przez niezbędne wersje pośrednie i przed każdym krokiem sprawdza kompatybilność. Ogranicza to nieudane próby aktualizacji, ale nie zastępuje fachowej wstępnej weryfikacji własnego środowiska.

Wymagania techniczne mogą zablokować aktualizację lub określić jej ścieżkę. Należą do nich używany system operacyjny, wystarczająca ilość wolnego miejsca w /usr/local/cpanel oraz aktywne blokady menedżera pakietów. Jako udokumentowany przykład można podać, że systemu Ubuntu 22 nie da się zaktualizować do wersji cPanel & WHM 136. Takie uwagi nie stanowią zachęty do przejścia na starszą gałąź, lecz są powodem do wcześniejszego wyjaśnienia aktualnej wersji systemu operacyjnego oraz planowanej ścieżki migracji.

Oprócz systemu podstawowego aktualizacja obejmuje również listę kontrolną dla przedsiębiorstw. Udokumentowane zmiany w uprawnieniach API SSL oraz usunięte narzędzia pomocnicze do rozliczeń wskazują, że może to mieć wpływ na własne rozwiązania automatyzacyjne lub integracje rozliczeniowe. Zmiany w Meridian i CSF sprawiają ponadto, że przypisania motywów, listy funkcji, lokalne dostosowania zapory sieciowej i powiązane rozszerzenia stają się istotnymi punktami kontrolnymi. Nie są to kontrole zapewnione przez narzędzie aktualizacyjne, lecz zależności, które należy celowo ocenić w swoim środowisku.

Jako środek ostrożności w przedsiębiorstwie należy rozpocząć aktualizację dopiero po opracowaniu planu przywracania danych dostosowanego do własnego środowiska, sprawdzeniu stanu kopii zapasowych oraz jasnym określeniu zakresu odpowiedzialności. Dokumentacja producenta zaleca, aby nową wersję główną najpierw przetestować na kompatybilnym systemie testowym; dopiero po przeprowadzeniu własnych testów funkcjonalnych należy w kontrolowany sposób wdrożyć ją do środowiska produkcyjnego. Ponieważ nie przewidziano możliwości powrotu do poprzedniej wersji, ewentualnego przywrócenia systemu z kopii zapasowej nie należy mylić z cofnięciem poziomu wydania.

Wybierz poziomy wydania zgodnie z celem operacyjnym

Poziom wydania określa, jaką wersję rozwojową i testową otrzyma serwer; jest to zatem decyzja operacyjna, a nie tylko ustawienie automatycznych aktualizacji. W trakcie swojego cyklu życia wersja LTS koncentruje się na aktualizacjach dotyczących bezpieczeństwa, poprawkach krytycznych i kompatybilności. Wersja STABLE jest wydawana rzadziej niż RELEASE, natomiast RELEASE stanowi udokumentowany standard dla nowych instalacji.

Wersja CURRENT jest częściej aktualizowana i może zawierać funkcje, które są nadal rozwijane. Wersja EDGE przechodzi jedynie podstawowe testy i dlatego powinna być stosowana wyłącznie w kontrolowanych środowiskach testowych. Nieparzyste numery wersji głównych oznaczają wersje rozwojowe w gałęzi EDGE; nie świadczą one ani o gotowości do wdrożenia w środowisku produkcyjnym, ani o pewnej dostępności poszczególnych funkcji.

W przypadku hostingu współdzielonego z możliwością planowania jest to LTS Ma to sens, gdy ważniejszy jest długoterminowy poziom funkcjonalności niż nowy interfejs użytkownika lub wczesne funkcje automatyzacji. Nie oznacza to jednak wstrzymywania aktualizacji: poprawki bezpieczeństwa i krytyczne poprawki pozostają częścią codziennej eksploatacji. Za wprowadzeniem nowych serwerów przemawia RELEASE, o ile wcześniej sprawdzono zależności i zaplanowano okna serwisowe.

Wybór powinien ponadto być dostosowany do organizacji testów. Podobnie jak w przypadku innych paneli hostingowych, decydujące znaczenie ma nie tyle konkretny numer wersji, co współdziałanie panelu, rozszerzeń, systemu operacyjnego i stosu klienta. Artykuł Planowanie aktualizacji Plesk dla dostawców usług hostingowych z zachowaniem kontroli ilustruje tę ogólną zasadę w odniesieniu do innej platformy. Zgodnie z dokumentacją aktualizacji opóźnienie wynoszące kilka dni roboczych dotyczy wyłącznie automatycznych aktualizacji do następnej głównej wersji w warstwie RELEASE i tylko na warunkach tam określonych; warstwy EDGE, CURRENT, STABLE i LTS są z tego wyłączone.

Sprawdź nowe funkcje w wersji 138

Wersja 138 wprowadza Meridian jako interfejs użytkownika. Dla osób odpowiedzialnych za WHM istotny jest nie tylko zmieniony układ: wybór motywu, przypisanie pakietów, listy funkcji, materiały szkoleniowe i procedury wsparcia technicznego muszą do siebie pasować. Poziom wydania określa, czy wymagana wersja produktu i kompilacji jest dostępna na serwerze; natomiast to, które obszary są widoczne dla poszczególnych kont, zależy przede wszystkim od motywu, pakietu, listy funkcji oraz konfiguracji dostawcy.

W przypadku Meridianu wprowadzenie zmian na szeroką skalę bez odpowiedniej polityki jest ryzykowne. Konta utworzone w Meridianie, które nigdy nie korzystały z Jupiter, nie mogą samodzielnie powrócić do Jupiter. Administratorzy mogą jednak ustawić motyw za pomocą WHM, pakietu lub API. Dlatego przed szerokim wdrożeniem należy obowiązkowo uzgodnić szablony pakietów oraz komunikację z niewielką grupą pilotażową.

Funkcja WHM-API-1 set_primary_domain_docroot może zmienić katalog główny dokumentów domeny głównej i zostało ponownie wprowadzone w wersjach 134 i 136. Ułatwia to konfigurację lub migrację, ale nie zastępuje sprawdzenia aplikacji. System CMS, przekierowanie, uprawnienia do plików lub skrypt wdrożeniowy mogą nadal wymagać dotychczasowej ścieżki; pomyślne uruchomienie narzędzia aktualizującego nie rozpoznaje automatycznie tego założenia technicznego.

Począwszy od wersji 138.0.10 funkcje API służące do pobierania certyfikatów SSL i kluczy wymagają włączenia tej funkcji sslinstall lub sslmanager. Należy zatem dokładnie sprawdzić ograniczone listy funkcji oraz zewnętrzne integracje rozliczeniowe. Ponadto cPanel usunął przestarzałe pliki pomocnicze z Cpanel/Accounting; bezpośrednie integracje z indywidualnymi rozwiązaniami rozliczeniowymi wymagają dostosowania i nie są automatycznie zapewniane pod względem zgodności.

Wersja 138.0.13 zmienia również wymagania dotyczące Listy ACL dla dystrybutorów podczas konfiguracji serwerów nazw. Resellerzy zarządzający klastrowaniem DNS mogą potrzebować uprawnienia all, aby zmienić ustawienia serwerów nazw danego serwera. Dlatego przed aktualizacją należy sprawdzić delegowane modele operacyjne, role wykorzystywanych resellerów oraz zautomatyzowane procesy klastrowania DNS. Uprawnienie to znacznie rozszerza zakres dostępu i nie powinno być przyznawane ogólnie, lecz wyłącznie po przeprowadzeniu weryfikacji ról i bezpieczeństwa.

Przygotowanie aktualizacji wraz z inwentaryzacją i wdrożeniem pilotażowym

Przed aktualizacją najpierw rejestruje się aktualny stan: zainstalowaną wersję, poziom wydania, system operacyjny, wtyczki innych producentów, własne wywołania API, dostosowania zapory sieciowej oraz procedury tworzenia kopii zapasowych i przywracania danych. Wersję można sprawdzić w terminalu bez wprowadzania zmian w systemie. Taka inwentaryzacja łączy elementy techniczne z osobami za nie odpowiedzialnymi i zapobiega pojawieniu się niejasnych zależności dopiero po aktualizacji.

/usr/local/cpanel/cpanel -V

Aby przeprowadzić aktualizację, cPanel wymaga co najmniej 5 GB wolnego miejsca w katalogu /usr/local/cpanel. Aktywne blokady menedżera pakietów mogą uniemożliwić przeprowadzenie tej operacji; również ścieżka systemu operacyjnego może nakładać ograniczenia w zależności od wersji. Kwestie te należy uwzględnić przed rozpoczęciem okna serwisowego, podobnie jak przywracanie danych, którego przebieg i uprawnienia dostępu zostały wcześniej ustalone.

Następnie następuje Inscenizacja na oddzielnym, porównywalnym systemie testowym. Tam sprawdzane są odpowiednie pakiety, motywy, wtyczki i integracje API przy użyciu symulowanych kont testowych. Przetestuj typowe procesy, takie jak logowanie, automatyzacja certyfikatów, provisioning i obsługa aplikacji. Dokumentacja producenta wyraźnie zaleca przeprowadzenie aktualizacji najpierw w środowisku testowym, zanim zostanie zaktualizowany system produkcyjny.

Pilotaż produkcyjny należy traktować oddzielnie. Prawdziwe konta klientów są uwzględniane wyłącznie po wyraźnym zatwierdzeniu, w ograniczonym zakresie, pod nadzorem i z ustalonym kanałem wsparcia. Należy wcześniej określić, jakie testy funkcjonalne zostaną przeprowadzone, kto podejmuje decyzje w przypadku awarii oraz jakie działania naprawcze są możliwe w odniesieniu do danego konta lub serwera. Test na symulowanych kontach nie zastępuje tego zatwierdzenia do eksploatacji; z drugiej strony test przeprowadzony u klienta nie jest bezryzykownym środowiskiem stagingowym.

W WHM opcja „Upgrade to Latest Version“ aktualizuje system do najnowszej kompilacji wybranego poziomu wydania. Funkcja ta nie gwarantuje zatem przejścia na najnowszą ogólnodostępną wersję główną. W przypadku opcji RELEASE może ponadto obowiązywać automatyczne opóźnienie; wymuszona aktualizacja pozwala je ominąć. Równolegle z procesem aktualizacji należy zadbać o środki bezpieczeństwa dotyczące dostępu, kopii zapasowych i zapory sieciowej; praktyczne podstawy wyjaśniono w artykule Bezpieczeństwo panelu sterowania hostingiem w WHM i cPanel.

Kontrolowane korzystanie z Meridian i CSF

W cPanel & WHM 138 Meridian to coś więcej niż tylko nowy widok klienta. Motyw ten grupuje zadania w takich obszarach, jak strony internetowe, poczta elektroniczna, pliki, bazy danych, bezpieczeństwo i wydajność. Dlatego przy obsłudze nie liczy się wyłącznie to, czy interfejs jest estetyczny, ale czy klienci nadal mogą bez trudu znaleźć i wykonać przewidziane zadania, korzystając z wykupionych funkcji.

Przed zatwierdzeniem administrator powinien sporządzić wiążącą Polityka dotycząca tematów Określić: które konta otrzymają motyw Meridian, które szablony pakietów przypisują ten motyw oraz które listy funkcji ograniczają poszczególne funkcje? Te ustawienia stanowią spójną całość. Pakiet może wprawdzie określać motyw, ale funkcja, której brakuje na liście funkcji, i tak pozostanie niedostępna dla powiązanego konta.

W praktyce zaleca się utworzenie ograniczonej grupy pilotażowej z reprezentatywnymi planami taryfowymi, na przykład z prostym kontem hostingowym, kontem z kilkoma domenami oraz scenariuszem dla resellerów. Należy przy tym sprawdzić typowe kanały wsparcia, takie jak zarządzanie skrzynkami pocztowymi, dostęp do baz danych oraz funkcje bezpieczeństwa. Komunikat skierowany do klientów powinien zawierać informacje o terminie, widocznych zmianach oraz dostępnym kanale wsparcia, zamiast zapowiadać zmianę jako czysto kosmetyczną.

Powrót do motywu Jupiter musi być częścią tego planu. Konta utworzone przy użyciu motywu Meridian, które nigdy nie korzystały z motywu Jupiter, nie mogą samodzielnie powrócić do tego motywu. Administratorzy mogą nadal zmieniać motyw w WHM, za pomocą pakietu lub poprzez API. Wynika z tego, że przypisanie motywu i odpowiedni proces muszą być ustalone, zanim nowe konta będą domyślnie tworzone z motywem Meridian.

CSF należy traktować oddzielnie od głównej wersji cPanel i WHM. WebPros udostępnia ten fork jako osobny pakiet o odrębnej numeracji wersji dla obsługiwanych wersji cPanel i WHM. cpanel-csf gotowe; instaluje się je i aktualizuje za pomocą menedżera pakietów cPanel. Zapowiadana wcześniej migracja nieobsługiwanych lub przestarzałych instalacji CSF do obsługiwanego forka została przeniesiona wstecz na wszystkie obsługiwane wersje cPanel i WHM. Dlatego nie można wiarygodnie określić wersji CSF wyłącznie na podstawie zainstalowanej kompilacji cPanel.

Jako podstawę do testów potrzebujesz zainstalowanego Stan pakietu cPanel-CSF, oddzielny dziennik zmian CSF, stan zarządzania pakietami oraz lokalną konfigurację. Utwórz kopię zapasową i porównaj własne reguły, listy zezwoleń i blokad, haki, powiadomienia, a także wtyczki lub skrypty wdrażania. Dodatkowo sprawdź, czy narzędzia zewnętrzne wymagają plików lub poleceń z poprzedniej instalacji CSF. Kompilacja cPanel pozostaje istotna w ogólnym kontekście aktualizacji, ale nie zastępuje ani tej weryfikacji pakietów, ani oceny lokalnej konfiguracji zapory sieciowej.

Systematyczne zawężanie zakresu błędów po aktualizacji

Jeśli po aktualizacji niektóre funkcje przestaną działać, analiza rozpoczyna się od wybranego poziomu wydania (Release Tier) oraz faktycznie zainstalowanej kompilacji (Build). Najnowsza ogólnodostępna wersja główna niekoniecznie odpowiada aktualnemu stanowi serwera; decydujące znaczenie ma to, która kompilacja została dostarczona w ramach skonfigurowanego poziomu wydania. Przed wprowadzeniem zmian mających na celu rzekome usunięcie błędu należy również odnotować czas wystąpienia problemu, konta, których dotyczy, oraz konkretną funkcję.

Następnie analizujesz logi aktualizacji i ewentualne Blokada aktualizacji . W przypadku większych skoków wersji program aktualizujący przechodzi przez wersje pośrednie i przeprowadza testy zgodności; aktywne blokady menedżera pakietów lub nieprawidłowe ścieżki systemu operacyjnego mogą wpłynąć na przebieg procesu. Przerwana lub tylko częściowo zakończona aktualizacja nie uzasadnia ślepego powtórzenia procesu z użyciem opcji wymuszających, lecz najpierw wyjaśnienie przyczyny zarejestrowanej w logu.

Następnie należy przetestować zależności w ustalonej kolejności: najpierw własne wywołania API WHM lub cPanel, potem listy funkcji i przypisania motywów, a następnie wtyczki oraz reguły zapory sieciowej. W ten sposób podczas wyszukiwania błędów można oddzielić centralną zmianę uprawnień od pojedynczego konta klienta lub rozszerzenia. Zmiany powinny być szczegółowo udokumentowane i w miarę możliwości najpierw przetestowane na środowisku stagingowym lub na odizolowanym koncie.

Jednym z konkretnych problemów dotyczących automatyzacji SSL jest to, że od wersji 138.0.10 funkcje API służące do pobierania certyfikatów SSL i kluczy wymagają włączenia tej funkcji sslinstall lub sslmanager. Jeśli po aktualizacji skrypt nie dostarcza już danych certyfikatu, należy zatem najpierw sprawdzić listę funkcji przypisanych do konta oraz uprawnienia używanego dostępu, a nie tylko sieć lub zasoby certyfikatów.

W przypadku zmiany katalogów głównych dokumentów pomyślne wywołanie interfejsu API również nie gwarantuje, że strona internetowa będzie działać. Funkcja set_primary_domain_docroot można ustawić ścieżkę domeny głównej, podczas gdy konfiguracje CMS, przekierowania, uprawnienia do plików, założenia dotyczące wirtualnych hostów lub skrypty wdrażania nadal będą odnosić się do starej ścieżki. Dlatego należy osobno przetestować stronę docelową, panel administracyjny oraz operacje zapisu w aplikacji.

Problem ten może dotyczyć również indywidualnie wdrożonych integracji z systemami księgowymi, ponieważ przestarzałe pliki pomocnicze PHP z Cpanel/Accounting zostały usunięte. Jeśli proces rozliczeniowy ma kluczowe znaczenie dla działalności firmy, a nie jest dostępna żadna kompatybilna modyfikacja, wstrzymanie konserwacji lub przywrócenie danych z zweryfikowanej kopii zapasowej są bardziej wskazane niż kolejna wymuszona aktualizacja. Dokumentacja producenta i protokoły stanowią wówczas podstawę do opracowania solidnego planu dostosowawczego.

Określić w sposób wiążący odpowiednią strategię aktualizacji

Skuteczna strategia aktualizacji zaczyna się od celu operacyjnego, a nie od najwyższego widocznego numeru wersji. Kluczowe znaczenie mają: okres wsparcia technicznego, zapotrzebowanie na nowe funkcje, spodziewany wpływ na klientów, dostępne możliwości testowe, zależności od dostawców zewnętrznych oraz działania związane z bezpieczeństwem. Kryteria te należy oceniać osobno dla każdej grupy serwerów: klaster hostingu współdzielonego, nowa platforma zarządzana oraz wewnętrzny system testowy wiążą się z różnymi rodzajami ryzyka i różnym tempem wprowadzania zmian.

Wersja LTS sprawdza się wtedy, gdy ważniejsza jest możliwość długoterminowego planowania niż ciągłe wprowadzanie nowych funkcji. W trakcie okresu wsparcia ta gałąź otrzymuje przede wszystkim aktualizacje dotyczące bezpieczeństwa, poprawek krytycznych oraz kompatybilności. LTS nie oznacza zatem wstrzymania aktualizacji, ani nie zastępuje testów kopii zapasowych, przywracania danych i testów zależności. W przypadku sprawdzonych ofert hostingu współdzielonego to ograniczenie zmian funkcjonalnych może sprawić, że wsparcie techniczne będzie łatwiejsze do oszacowania.

Wersja STABLE jest wydawana rzadziej niż RELEASE i została poddana bardziej szczegółowym testom publicznym. Wersja RELEASE jest w pełni funkcjonalna i stanowi standard dla nowych instalacji. Obie wersje są sensownymi opcjami, gdy potrzebne są nowe funkcje, ale przed ich szerokim wdrożeniem przeprowadzane są testy. Wybór odpowiedniego poziomu zależy zatem od tego, czy dla danej platformy ważniejsza jest wcześniejsza dostępność, czy też dodatkowy okres testowania.

Wersja CURRENT jest częściej aktualizowana i może zawierać funkcje, które są nadal rozwijane. Wersja EDGE przechodzi jedynie podstawowe testy i jest przeznaczona wyłącznie do kontrolowanych środowisk testowych. Nieparzyste numery wersji głównych odnoszą się do wydań rozwojowych w gałęzi EDGE; nie oznaczają one, że dana funkcja jest stabilna i gotowa do wdrożenia w środowisku produkcyjnym. W związku z tym w przypadku serwerów produkcyjnych klientów gałąź EDGE nie stanowi skrótu do wcześniejszych funkcji.

Umieść Zasady publikacji określone na piśmie: dopuszczalna liczba instancji na klasę serwera, osoby odpowiedzialne za zatwierdzanie, minimalny zakres testów stagingowych, okna serwisowe oraz kryteria przerwania. Opóźnienie wynoszące kilka dni roboczych dotyczy wyłącznie automatycznych aktualizacji do następnej wersji głównej w warstwie RELEASE, o ile aktualizacja nie zostanie uruchomiona ręcznie lub wymuszona i pomija tylko jedną wersję główną. Opóźnienie to nie dotyczy poziomów EDGE, CURRENT, STABLE, LTS oraz stałych wersji.

Typowymi błędnymi decyzjami są: wdrożenie EDGE w produkcji oraz zapisywanie poszczególnych numerów kompilacji w /etc/cpupdate.conf, brak etapu testowego oraz założenie, że wersje LTS nie wymagają aktualizacji zabezpieczeń. Równie problematyczne jest utożsamianie pomyślnego przebiegu aktualizacji z zatwierdzeniem technicznym. Dopiero po przetestowaniu funkcji klienckich, automatyzacji, wtyczek i mechanizmów zabezpieczających w planowanym zakresie aktualizacja techniczna staje się kontrolowaną zmianą operacyjną.