cPanel PHP Apache EU-hosting legacy-hosting

cPanel EasyApache4 konflikt modułów PHP: przebudowa Apache z kompatybilnymi modułami

Rozwiązanie konfliktów modułów PHP w cPanel EasyApache4, gdy zależności pakietów kolidują podczas przebudowy Apache, powodując błędy buildu lub uszkodzone instalacje PHP.

Jerzy Kopaczewski · 2025-11-12

EasyApache4 odmawia buildu. Rozszerzenia PHP się nie ładują. yum wypluwa konflikty zależności między pakietami ea-php. Strony tkwią na uszkodzonej konfiguracji PHP, a WHM pokazuje build jako nieudany. Oto jak to rozplątać.

Jeśli szukasz szerszego wsparcia w zakresie utrzymania infrastruktury hostingowej, zobacz naszą stronę operacje na serwerach dedykowanych.

Objawy

Build EasyApache4 pada z błędami zależności lub PHP po częściowym buildzie cicho traci rozszerzenia:

# EasyApache4 build pada z konfliktami
/usr/local/cpanel/bin/rebuild_phpconf --current
# Error: Transaction check error:
#   file /opt/cpanel/ea-php81/root/usr/lib64/php/modules/imagick.so
#   from install of ea-php81-php-imagick-3.7.0-1.el7.x86_64
#   conflicts with file from package ea-php81-php-pecl-imagick-3.6.0-2.el7.x86_64

# PHP nie ma oczekiwanych modułów
php -m | grep -i imagick
# (brak wyniku - moduł nie załadowany)

# Yum pokazuje konflikty pakietów
yum list installed | grep ea-php
# ea-php81-php-imagick.x86_64         3.7.0-1.el7   @EA4
# ea-php81-php-pecl-imagick.x86_64    3.6.0-2.el7   @epel-ea4

# Profil EasyApache4 w WHM pokazuje błąd buildu
whmapi1 php_get_installed_versions
# version: ea-php74
# version: ea-php81
# (ale moduły są niekompletne)

Strony zwracają błędy 500 na podstronach wymagających brakujących rozszerzeń. Witryny WordPress padają z komunikatem „Your PHP installation appears to be missing the MySQL extension” lub podobnym.

Przyczyna

Konflikty modułów PHP w EasyApache4 wynikają najczęściej z trzech scenariuszy:

Wiele źródeł pakietów dla tego samego rozszerzenia - repozytorium EA4 cPanelu i zewnętrzne repo (EPEL, Remi, IUS) dostarczają ten sam moduł PHP pod różnymi nazwami pakietów
Konflikty wersji (version pinning) - starszy pakiet ea-php jest zablokowany przez yum versionlock, podczas gdy nowsze zależności wymagają zaktualizowanej wersji
Kontaminacja modułów między wersjami - moduły zainstalowane dla ea-php74 wciągają biblioteki współdzielone, które kolidują z modułami ea-php81 lub ea-php82

System EasyApache4 w cPanelu oczekuje wyłącznej kontroli nad pakietami PHP w /opt/cpanel/ea-php*/. Gdy zewnętrzne repozytoria wstrzykują pakiety do tej przestrzeni nazw lub gdy ręczne komendy yum install omijają resolver zależności EasyApache4, system buildu nie jest w stanie uzgodnić grafu pakietów.

Jest to szczególnie częste na serwerach, które przeszły przez wiele aktualizacji cPanelu, lub gdzie poprzedni administratorzy instalowali rozszerzenia PHP ręcznie zamiast przez WHM.

Rozwiązanie

Krok 1: Zidentyfikuj kolidujące pakiety

# Wylistuj wszystkie pakiety EA4 PHP i ich źródłowe repozytoria
yum list installed | grep ea-php | sort

# Sprawdź duplikaty dostarczające ten sam moduł
rpm -qa | grep -E "ea-php.*(imagick|redis|memcached|sodium)" | sort

# Sprawdź, które repozytoria są włączone
yum repolist enabled | grep -iE "epel|remi|ius|ea4"

# Szukaj wpisów versionlock blokujących aktualizacje
yum versionlock list | grep ea-php

Krok 2: Usuń kolidujące pakiety z zewnętrznych repozytoriów

# Usuń wersję z zewnętrznego repo (zachowaj wersję EA4)
# Zidentyfikuj, który pakiet pochodzi z zewnętrznego repo
rpm -qi ea-php81-php-pecl-imagick | grep "From repo"
# From repo   : epel-ea4

# Usuń kolidujący pakiet
yum remove ea-php81-php-pecl-imagick

# Jeśli versionlock blokuje aktualizacje, wyczyść blokadę
yum versionlock delete ea-php81-php-imagick

Krok 3: Wyczyść metadane yum i zweryfikuj priorytety repozytoriów

# Wyczyść wszystkie zbuforowane metadane
yum clean all

# Upewnij się, że repo EA4 ma wyższy priorytet niż zewnętrzne
cat /etc/yum.repos.d/EA4.repo | grep priority
# Powinno być: priority=15 (niższa liczba = wyższy priorytet)

# Jeśli priorytet brakuje lub jest za wysoki, ustaw go
sed -i '/\[EA4\]/a priority=15' /etc/yum.repos.d/EA4.repo

# Wyklucz pakiety ea-php z zewnętrznych repozytoriów
echo "exclude=ea-php*" >> /etc/yum.repos.d/epel.repo

Krok 4: Przebuduj konfigurację PHP od zera

# Zregeneruj konfigurację PHP
/usr/local/cpanel/bin/rebuild_phpconf --current

# Jeśli powyższe nadal pada, wykonaj pełną przebudowę profilu EA4
# Najpierw wyeksportuj obecny profil
whmapi1 php_get_installed_versions
ea_current_to_profile --output=/root/ea4-backup-profile.json

# Usuń wszystkie pakiety PHP dla problematycznej wersji
yum remove 'ea-php81-php-*'

# Zainstaluj ponownie z zapisanego profilu
/usr/local/cpanel/scripts/ea_install_profile --profile=/root/ea4-backup-profile.json

Krok 5: Zablokuj wersje pakietów, żeby zapobiec nawrotom

# Zablokuj pakiety EA4 przed ingerencją zewnętrznych repozytoriów
yum versionlock add ea-php81-php-imagick

# Lub wyłącz problematyczne repo dla pakietów ea-php na stałe
yum-config-manager --save --setopt=epel.exclude="ea-php*"

Krok 6: Zweryfikuj przypisanie handlerów PHP

# Upewnij się, że wersje PHP są prawidłowo przypisane do domen
whmapi1 php_get_installed_versions
# Powinno wylistować wszystkie oczekiwane wersje

# Sprawdź konfigurację handlera
/usr/local/cpanel/bin/rebuild_phpconf --current
# Powinno pokazać: ea-php81 => cgi / fpm / lsapi

# Jeśli używasz PHP-FPM, zrestartuj pool
systemctl restart ea-php81-php-fpm

Weryfikacja

# 1. Zweryfikuj, że EasyApache4 nie zgłasza konfliktów pakietów
yum check 2>&1 | grep ea-php
# Oczekiwane: brak wyniku (brak konfliktów)

# 2. Zweryfikuj, że PHP ładuje wszystkie oczekiwane moduły
/opt/cpanel/ea-php81/root/usr/bin/php -m | grep -iE "imagick|redis|mysql|curl"
# Oczekiwane: wszystkie wymagane moduły na liście

# 3. Zweryfikuj, że Apache serwuje strony PHP poprawnie
curl -sI http://localhost/test.php | head -5
# Oczekiwane: HTTP/1.1 200 OK

# 4. Zweryfikuj przez WHM API, że wersje są czyste
whmapi1 php_get_installed_versions
# Oczekiwane: wszystkie skonfigurowane wersje PHP bez błędów

# 5. Przetestuj phpinfo, żeby potwierdzić ładowanie modułów
/opt/cpanel/ea-php81/root/usr/bin/php -r "phpinfo();" | grep -c "module"
# Oczekiwane: liczba odpowiada oczekiwanej ilości załadowanych modułów

# 6. Sprawdź status buildu EasyApache4 w WHM
whmapi1 ea4_get_build_status
# Oczekiwane: state=complete, brak błędów

Jeśli yum check nie zgłasza konfliktów i PHP ładuje wszystkie oczekiwane moduły, build jest czysty. Apache będzie poprawnie serwować strony PHP, a przyszłe przebudowy EasyApache4 zakończą się bez błędów.

Serwery, na których przez lata narastało ręczne zarządzanie pakietami, mają tendencję do powtarzania tych konfliktów. Każda aktualizacja cPanelu, każde dodanie wersji PHP, każdy „szybki fix” przez yum install ze Stack Overflow dodaje kolejny potencjalny konflikt. Jeśli panel hostingowy walczy z Tobą bardziej niż pomaga, być może czas przemyśleć architekturę od nowa.

Dla witryn, które nie wymagają już dynamicznego hostingu, warto rozważyć konwersję na stronę statyczną - eliminuje zarówno zależność od panelu hostingowego, jak i powierzchnię ataku. Zobacz nasz runbook konwersji WordPress na Jekyll z pełną procedurą.

Czas zmodernizować legacy hosting?

Umów bezpłatną 30-minutową rozmowę. Pomagamy zespołom migrować z serwerów zarządzanych panelami na infrastrukturę, która nie stawia oporu - czy to konteneryzacja workload, statyczna dostawa treści, czy zarządzane usługi cloud.