Actualizar el sistema y el kernel de un VPS con cPanel sin problemas.

cPanel se actualiza solo y el sistema también instala parches de seguridad por su cuenta, pero hay algo que no hace: reiniciar. Un kernel nuevo queda instalado y no se usa hasta reiniciar el servidor. En un VPS con KVM (puedes comprobarlo con systemd-detect-virt), el kernel es tuyo y conviene mantenerlo al día.

Esto no es un script, sino un procedimiento manual: el reinicio deja los sitios sin servicio 1 a 3 minutos, y prefiero estar mirando cuando pasa.

Antes de empezar

• Necesitas un VPS o servidor dedicado con cPanel/WHM y acceso root (desde WHM → Terminal basta).
• Los scripts se probaron en AlmaLinux 10 con cPanel 138, PHP 8.3 de EasyApache (/opt/cpanel/ea-php83) y WP-CLI instalado en /usr/local/bin/wp. Si tu servidor usa otra versión de PHP, cambia la ruta ea-php83 en el script.
• Pruébalos primero en un horario tranquilo y lee lo que hace cada uno antes de ejecutarlo. Se comparten tal cual, sin garantía: adáptalos a tu servidor.

Cuándo hacerlo

• Cuando el chequeo del servidor muestre paquetes pendientes o «Reinicio pendiente».
• De noche o de madrugada, cuando casi no hay visitas, y lejos de la hora de los respaldos.

Paso 1. Ver qué se va a actualizar

dnf -q check-update | grep -E '^[a-zA-Z0-9]' | awk '{printf "%-45s %s\n", $1, $2}'
needs-restarting -r            # dice si ya hay un reinicio pendiente y por qué

Si la lista incluye paquetes kernel, habrá que reiniciar. Que salgan kernels nuevos cada pocas semanas es normal: casi siempre son correcciones de seguridad.

Paso 2. Instalar

dnf -y update 2>&1 | tail -3
echo -n "Kernel actual: "; uname -r
echo -n "Kernel con el que arrancara: "; grubby --default-kernel
needs-restarting -r >/dev/null 2>&1 && echo "NO hace falta reiniciar" || echo "SI hace falta reiniciar"

Paso 3. Reiniciar (solo si hace falta)

reboot

La terminal de WHM se desconecta. Espera un par de minutos y recarga la página.

Paso 4. Comprobar que todo volvió bien

echo -n "Kernel en uso: "; uname -r
systemctl --failed --no-legend --plain | grep . || echo "Ningun servicio con falla"
for s in httpd mariadb exim dovecot cpanel lfd crond; do printf "%s=%s  " $s "$(systemctl is-active $s)"; done; echo
for d in $(grep -h "^DNS=" /var/cpanel/users/* | cut -d= -f2); do echo -n "$d: "; curl -s -o /dev/null -k -m 20 --resolve $d:443:127.0.0.1 -w "%{http_code}\n" https://$d/; done

Lo correcto: el kernel nuevo en uso, ningún servicio con falla, todos los servicios active y cada sitio respondiendo 200.

Un servicio que falla en cada reinicio: cpgreylistd

Si apagaste el Greylisting de cPanel (puede atrasar correos legítimos), es posible que después de cada reinicio aparezca cpgreylistd como servicio con falla: cPanel lo intenta levantar aunque esté desactivado. No afecta el correo, pero ensucia los chequeos.

Desactivarlo en WHM y en systemd no siempre basta, y systemctl mask no funciona porque cPanel guarda el servicio en /etc/systemd/system. Lo que sí funciona es agregarle una condición en un archivo aparte, que sobrevive a las actualizaciones de cPanel:

mkdir -p /etc/systemd/system/cpgreylistd.service.d
printf '[Unit]\nConditionPathExists=/etc/cpgreylistd-activar\n' > /etc/systemd/system/cpgreylistd.service.d/no-arrancar.conf
systemctl daemon-reload; systemctl reset-failed
systemctl start cpgreylistd; systemctl is-active cpgreylistd   # debe decir: inactive

Como /etc/cpgreylistd-activar no existe, systemd salta el servicio sin marcarlo como falla. Para volver a usar el Greylisting: borra no-arrancar.conf, corre systemctl daemon-reload y actívalo en WHM → Email → Greylisting.

Avisos de LFD del tipo «System Integrity checking detected a modified system file» justo después de una actualización suelen ser eso mismo, una actualización. Para confirmarlo: rpm -qf ARCHIVO dice a qué paquete pertenece y rpm -V PAQUETE (sin salida) confirma que no fue alterado después de instalarse.