Lanzamiento de cPanel y WHM: nuevas funciones y estrategias de actualización seguras

Diferenciar claramente entre cPanel y WHM

Aunque cPanel y WHM forman parte del mismo producto, se utilizan en distintos niveles de un servidor de alojamiento. cPanel Es la interfaz de una cuenta de alojamiento individual: desde allí, los clientes gestionan, por ejemplo, dominios, buzones de correo electrónico, archivos, bases de datos y las funciones de seguridad habilitadas para su cuenta. Las listas de funciones, los paquetes, el tema, los derechos de la cuenta y la configuración del proveedor de alojamiento determinan, sobre todo, qué secciones son visibles y se pueden utilizar.

WHM, por su parte, es el nivel administrativo del panel de alojamiento. En él, los administradores de servidores configuran cuentas, paquetes, listas de funciones y servicios para todo el servidor, mientras que los proveedores de alojamiento gestionado establecen además normas para el aprovisionamiento, las actualizaciones y la asistencia técnica. Los revendedores trabajan con un área limitada de WHM, en función de los derechos que se les hayan delegado; esto no implica automáticamente acceso al sistema operativo, a los servicios globales ni a todas las políticas del servidor.

A Actualización de cPanel Por lo tanto, no se trata únicamente de una nueva vista en la cuenta del cliente. Los cambios pueden afectar a la asignación de temas, a las funciones disponibles en las plantillas de paquetes y a los procesos automatizados. A nivel del sistema, hay que añadir las interfaces, los controles de permisos, las extensiones instaladas y la interacción con el sistema operativo. El nivel de lanzamiento determina qué versión del producto y qué compilación estarán disponibles para el servidor, no directamente la visibilidad de funciones concretas en una cuenta de cliente determinada.

Un ejemplo práctico es la implementación de Meridian: si el tema se establece a través de un paquete de WHM, esta decisión influye en la interfaz de las cuentas nuevas o asignadas. Si los scripts de aprovisionamiento utilizan al mismo tiempo API o si las guías de asistencia técnica requieren determinadas rutas de menú, es necesario comprobar conjuntamente la política de temas, la plantilla del paquete y la automatización. De lo contrario, un cambio aislado de tema puede tener consecuencias funcionalmente correctas, pero inesperadas para los clientes y el servicio de asistencia técnica.

Diferenciar entre versiones, compilaciones y niveles de lanzamiento

Para elaborar un plan de actualizaciones sólido, es necesario que Versión principal, hay que considerar por separado el «build» y el «release tier». Según la información disponible, cPanel & WHM 138 es la última versión principal de producción publicada. La versión 134 es la rama LTS actual, con un periodo de soporte más prolongado y previsible. Aunque la versión 136 explica el origen de algunos cambios concretos, su plazo de soporte técnico habitual ya finalizó en agosto de 2026; por lo tanto, no constituye un nuevo objetivo de actualización recomendable.

Una versión principal identifica una rama de lanzamiento, por ejemplo, la 138. El número de compilación especifica una versión concreta dentro de esa rama; en el registro de cambios se documentan los cambios de la 138 hasta la compilación 138.0.13. Esto no implica que todos los servidores reciban esta compilación ni que se actualicen a la versión 138. También es determinante el canal de distribución público que utilice el servidor.

El Nivel de lanzamiento determina el nivel de prueba y la periodicidad con la que se distribuyen las actualizaciones. Por lo tanto, LTS, STABLE, RELEASE, CURRENT y EDGE no son meras etiquetas para la misma versión de software. Un servidor del nivel LTS puede encontrarse deliberadamente en una rama de versión principal diferente a la de un sistema del nivel RELEASE, aunque 138 sea, en general, la versión principal de producción más reciente.

Hay que tener especial cuidado con los números de versión cuyo número principal sea impar. Estos pertenecen a la versión de desarrollo de la rama EDGE y no deben equipararse a una versión de producción publicada. Su existencia no implica ni que el desarrollo haya concluido ni que sean aptas para los servidores de los clientes. Por lo tanto, a efectos de la gestión de cambios y la comunicación con el servicio de asistencia, los administradores deben documentar siempre de forma conjunta la versión instalada, la compilación concreta y el nivel seleccionado.

¿Por qué es necesario planificar una actualización de cPanel?

A Cambio de versión En cPanel & WHM, la reversión no se puede realizar sin consecuencias: no se admite el cambio a una versión principal anterior ni a un nivel de lanzamiento anterior. En el caso de saltos importantes, el programa de actualización pasa por las versiones intermedias necesarias y comprueba la compatibilidad antes de cada paso. Esto reduce los intentos de actualización inadecuados, pero no sustituye a una evaluación previa por parte de un experto de tu propio entorno.

Los requisitos técnicos pueden bloquear una actualización o determinar su ruta. Entre ellos se incluyen el sistema operativo utilizado y una cantidad suficiente de espacio libre en /usr/local/cpanel y bloqueos activos del gestor de paquetes. Un ejemplo documentado es que Ubuntu 22 no se puede actualizar a cPanel & WHM 136. Estas indicaciones no son una invitación a recurrir a una rama antigua, sino un motivo para aclarar de antemano el estado del sistema operativo y la ruta de migración prevista.

Además del sistema básico, la actualización incluye una lista de comprobación operativa. Los cambios documentados en los permisos de la API de SSL y la eliminación de los auxiliares de contabilidad indican que las automatizaciones propias o las integraciones de facturación pueden verse afectadas. Además, los cambios en Meridian y CSF hacen que las asignaciones de temas, las listas de funciones, los ajustes del cortafuegos local y las extensiones asociadas se conviertan en puntos de verificación importantes. No se trata de comprobaciones garantizadas por el programa de actualización, sino de dependencias que debes evaluar de forma específica en tu entorno.

Como medida de precaución operativa, la actualización solo debería iniciarse si se cuenta con un plan de recuperación adecuado al entorno propio, una copia de seguridad previamente comprobada y unas responsabilidades claramente definidas. La documentación del fabricante recomienda probar primero una nueva versión principal en un sistema de pruebas compatible; solo tras haber realizado las propias pruebas de funcionamiento debería realizarse la implementación controlada en el entorno de producción. Dado que no está prevista la posibilidad de volver a una versión anterior, no debe confundirse una posible restauración a partir de copias de seguridad con el retroceso al nivel de versión anterior.

Seleccionar niveles de lanzamiento según el objetivo operativo

El nivel de versión determina qué versión de desarrollo y prueba recibe un servidor; por lo tanto, se trata de una decisión operativa y no de una mera configuración para las actualizaciones automáticas. Durante su periodo de vigencia, LTS se centra en actualizaciones de seguridad, críticas y de compatibilidad. STABLE se publica con menos frecuencia que RELEASE, mientras que RELEASE es el estándar documentado para las nuevas instalaciones.

CURRENT se actualiza con mayor frecuencia y puede incluir funciones que aún se encuentran en fase de desarrollo. EDGE solo se somete a pruebas básicas y, por lo tanto, debe utilizarse exclusivamente en entornos de prueba controlados. Los números de versión principales impares identifican las versiones de desarrollo de la rama EDGE; no garantizan ni la madurez para producción ni la disponibilidad segura de ninguna función concreta.

Para un alojamiento compartido predecible, es LTS Es recomendable cuando es más importante contar con un nivel de funcionalidad predecible a largo plazo que disponer de una nueva interfaz o de funciones de automatización avanzadas. Esto no significa suspender las actualizaciones: las correcciones de seguridad y las críticas siguen formando parte del funcionamiento. RELEASE recomienda el uso de servidores nuevos, siempre que se comprueben previamente las dependencias y se planifiquen ventanas de mantenimiento.

Además, la elección debe ajustarse a la organización de las pruebas. Al igual que ocurre con otros paneles de alojamiento, lo decisivo no es un único número de versión, sino la interacción entre el panel, las extensiones, el sistema operativo y la pila del cliente. El artículo Planificar de forma controlada las actualizaciones de Plesk para proveedores de alojamiento web Ilustra este principio general para otra plataforma. Según la documentación de la actualización, un retraso de varios días hábiles solo afecta a las actualizaciones automáticas a la siguiente versión principal en el nivel RELEASE y únicamente en las condiciones allí especificadas; los niveles EDGE, CURRENT, STABLE y LTS quedan excluidos.

Comprobar las nuevas funciones de la versión 138

La versión 138 incluye Meridiano como interfaz de usuario. Para los responsables de WHM, no solo es relevante el nuevo diseño: la selección de temas, la asignación de paquetes, las listas de funciones, los materiales de formación y los procesos de asistencia técnica deben encajar entre sí. El nivel de lanzamiento determina si la versión del producto y la compilación necesarias están disponibles en el servidor; por el contrario, las áreas a las que tiene acceso una cuenta concreta dependen principalmente del tema, el paquete, las listas de funciones y la configuración del proveedor.

En Meridian, una migración generalizada sin una política definida es arriesgada. Las cuentas creadas con Meridian que nunca hayan utilizado Jupiter no pueden volver a Jupiter por sí mismas. No obstante, los administradores pueden configurar el tema a través de WHM, un paquete o la API. Por lo tanto, las plantillas de los paquetes y la comunicación con un pequeño grupo piloto deben coordinarse de forma vinculante antes de la implantación generalizada.

La función WHM-API-1 set_primary_domain_docroot Permite modificar la raíz de documentos de un dominio principal y se ha retroportado a las versiones 134 y 136. Esto facilita el aprovisionamiento o la migración, pero no sustituye a una comprobación de la aplicación. Un CMS, una redirección, los permisos de los archivos o un script de implementación pueden seguir requiriendo la ruta anterior; una ejecución correcta del programa de actualización no detecta automáticamente esta suposición técnica.

A partir de la versión 138.0.10, las funciones de la API para recuperar certificados y claves SSL requieren la función sslinstall o sslmanager. Por lo tanto, es necesario comprobar de forma específica las listas de funciones limitadas y las integraciones de facturación externas. Además, cPanel ha eliminado los archivos auxiliares obsoletos de Cpanel/Accounting; las integraciones directas en soluciones de facturación individuales requieren una adaptación; no se trata de un problema de compatibilidad que se resuelva automáticamente.

La versión 138.0.13 también modifica los requisitos para ACL de revendedores en la configuración de los servidores de nombres. Es posible que los distribuidores que gestionan clústeres de DNS necesiten el privilegio all, para modificar la configuración de los servidores de nombres del servidor. Por lo tanto, antes de realizar la actualización, comprueba los modelos operativos delegados, las funciones de los revendedores utilizados y los procesos automatizados de los clústeres de DNS. Este privilegio amplía considerablemente el acceso y no debe asignarse de forma generalizada, sino únicamente tras una comprobación de funciones y seguridad.

Preparar las actualizaciones con el inventario y la fase piloto

Antes de la actualización, se registra primero el estado actual: versión instalada, nivel de lanzamiento, sistema operativo, complementos de terceros, llamadas a la API propia, ajustes del cortafuegos y procedimientos de copia de seguridad y restauración. La versión se puede determinar en el terminal sin necesidad de realizar cambios en el sistema. Este inventario vincula los componentes técnicos con sus responsables y evita que, tras la actualización, salgan a la luz dependencias poco claras.

/usr/local/cpanel/cpanel -V

Para realizar una actualización, cPanel requiere al menos 5 GB de espacio libre en /usr/local/cpanel. Los bloqueos activos de los gestores de paquetes pueden impedir el proceso; la ruta del sistema operativo también puede imponer limitaciones en función de la versión. Estos aspectos deben abordarse antes de la ventana de mantenimiento, al igual que una restauración cuyos pasos y derechos de acceso se hayan aclarado de antemano.

A continuación viene Puesta en escena en un sistema de pruebas independiente y comparable. Allí se comprueban los paquetes, temas, plugins e integraciones de API pertinentes utilizando cuentas de prueba simuladas. Prueba procesos típicos como el inicio de sesión, la automatización de certificados, el aprovisionamiento y el funcionamiento de las aplicaciones. La documentación del fabricante recomienda expresamente realizar primero la actualización de forma gradual en un sistema de pruebas antes de actualizar el sistema de producción.

Las pruebas piloto de producción deben tratarse por separado. Las cuentas reales de clientes solo se incluirán tras una autorización expresa, con un alcance limitado, supervisión y una vía de asistencia técnica previamente comunicada. Establece de antemano qué pruebas funcionales se llevarán a cabo, quién tomará las decisiones en caso de fallo y qué medidas de recuperación son posibles para la cuenta o el servidor en cuestión. Una prueba en cuentas simuladas no sustituye a esta autorización de funcionamiento; por el contrario, una prueba con clientes no es un entorno de prueba sin riesgos.

En WHM, la opción „Actualizar a la última versión“ actualiza a la última compilación del nivel de lanzamiento seleccionado. Por lo tanto, esta función no garantiza el cambio a la versión principal más reciente en general. Además, en RELEASE puede aplicarse un retraso automático; una actualización forzada lo evita. Las medidas operativas relacionadas con la seguridad en materia de accesos, copias de seguridad y cortafuegos deben mantenerse al día en paralelo al proceso de actualización; en este artículo se explican los fundamentos prácticos. Seguridad del panel de control de alojamiento en WHM y cPanel.

Gestionar Meridian y CSF de forma controlada

Meridian es, en cPanel & WHM 138, algo más que una nueva vista de clientes. El tema agrupa tareas en áreas como sitios web, correo electrónico, archivos, bases de datos, seguridad y rendimiento. Por lo tanto, a la hora de utilizarlo, no solo importa si la interfaz resulta visualmente atractiva, sino si los clientes pueden seguir encontrando y realizando con claridad las tareas previstas con las funciones que han contratado.

Antes de la publicación, el administrador debería realizar una Política de temas Definir: ¿Qué cuentas reciben Meridian, qué plantillas de paquete asignan el tema y qué listas de funciones limitan las funciones individuales? Estos ajustes van de la mano. Aunque un paquete pueda especificar un tema, una función que no figure en la lista de funciones seguirá sin estar disponible para la cuenta correspondiente.

En la práctica, se recomienda un grupo piloto limitado con tarifas representativas, como una cuenta sencilla de alojamiento web, una cuenta con varios dominios y un escenario de revendedor. Comprueba los procesos típicos de asistencia técnica, como la gestión de buzones de correo, el acceso a bases de datos y la búsqueda de funciones de seguridad. La comunicación con los clientes debería indicar la fecha, los cambios visibles y un canal de asistencia accesible, en lugar de anunciar el cambio como algo meramente cosmético.

El cambio de vuelta a Jupiter debe formar parte de esta planificación. Las cuentas creadas con Meridian que nunca hayan utilizado Jupiter no pueden volver a Jupiter por sí mismas. Los administradores pueden seguir cambiando el tema en WHM, mediante un paquete o a través de la API. De ello se deduce que la asignación del tema y el proceso correspondiente deben estar definidos antes de que las nuevas cuentas se creen por defecto con Meridian.

CSF debe considerarse independientemente de la versión principal de cPanel y WHM. WebPros ofrece esta bifurcación como un paquete con una versión independiente para las versiones compatibles de cPanel y WHM. cpanel-csf Listo; se instala y actualiza a través del gestor de paquetes de cPanel. La migración, anunciada anteriormente, de las instalaciones de CSF no compatibles u obsoletas a la bifurcación compatible se ha retroportado a todas las versiones compatibles de cPanel y WHM. Por ello, no es posible determinar de forma fiable la versión de CSF basándose únicamente en la versión instalada de cPanel.

Para realizar la comprobación, necesitas tener instalado el Estado del paquete cpanel-csf, el registro de cambios independiente de CSF, el estado de la gestión de paquetes y la configuración local. Guarda y compara tus propias reglas, listas de permitidos y prohibidos, hooks, notificaciones, así como plugins o scripts de implementación. Comprueba además si hay herramientas externas que requieran archivos o comandos de una instalación anterior de CSF. La versión de cPanel sigue siendo relevante en el contexto general de la actualización, pero no sustituye ni a esta comprobación de paquetes ni a la evaluación de la configuración local del cortafuegos.

Localizar sistemáticamente los errores tras la actualización

Si tras una actualización dejan de funcionar algunas funciones, el análisis comienza con el nivel de versión seleccionado y la compilación realmente instalada. La versión principal más reciente en general no es automáticamente la versión actual de un servidor; lo que cuenta es qué compilación se entregó en el nivel configurado. Anota además la hora, las cuentas afectadas y la función concreta antes de realizar cambios para intentar solucionar el supuesto error.

A continuación, analizarás los registros de actualización y los posibles Bloqueador de actualizaciones . En el caso de saltos de versión importantes, el programa de actualización pasa por versiones intermedias y realiza comprobaciones de compatibilidad; los bloqueos activos del gestor de paquetes o las rutas del sistema operativo incorrectas pueden afectar al proceso. Una actualización interrumpida o completada solo parcialmente no justifica repetirla a ciegas con opciones forzadas, sino que primero hay que aclarar la causa registrada en el registro.

A continuación, comprueba las dependencias siguiendo un orden fijo: primero, las propias llamadas a la API de WHM o cPanel; después, las listas de funciones y las asignaciones de temas; y, por último, los plugins y las reglas del cortafuegos. De este modo, la localización de errores permite diferenciar un cambio de permisos centralizado de uno relacionado con una cuenta de cliente concreta o con una extensión. Los cambios deben documentarse de forma clara y, a ser posible, comprobarse primero en un entorno de pruebas o en una cuenta aislada.

Un error concreto afecta a las automatizaciones SSL: a partir de la versión 138.0.10, las funciones de la API para recuperar certificados y claves SSL requieren la función sslinstall o sslmanager. Por lo tanto, si tras la actualización un script deja de proporcionar datos de certificados, comprueba primero la lista de funciones asignadas a la cuenta y los permisos del acceso utilizado, y no solo la red o el inventario de certificados.

Aunque se modifiquen las raíces de los documentos, una llamada a la API que se haya realizado correctamente tampoco garantiza que el sitio web funcione. La función set_primary_domain_docroot Puede establecer la ruta del dominio principal, mientras que las configuraciones del CMS, las redirecciones, los permisos de los archivos, los ajustes de los servidores virtuales o los scripts de implementación sigan apuntando a la ruta anterior. Por lo tanto, comprueba por separado la entrega, el área de administración y las operaciones de escritura de la aplicación.

Las integraciones contables implementadas de forma individual también pueden verse afectadas, ya que los archivos auxiliares de PHP obsoletos de Cpanel/Accounting se han eliminado. Si un proceso de facturación es crítico para el negocio y no hay ninguna adaptación compatible disponible, es más adecuado detener el servicio o restaurar el sistema a partir de una copia de seguridad comprobada que realizar otra actualización forzada. La documentación del fabricante y los registros sirven entonces de base para elaborar un plan de adaptación sólido.

Establecer de forma vinculante la estrategia de actualización adecuada

Una estrategia de actualización viable parte del objetivo operativo, no del número de versión más alto visible. Son factores decisivos el periodo de soporte, la necesidad de nuevas funciones, el impacto previsto en los clientes, la capacidad de pruebas disponible, las dependencias de terceros y las operaciones de seguridad. Estos criterios deben evaluarse para cada grupo de servidores: un clúster de alojamiento compartido, una nueva plataforma gestionada y un sistema de pruebas interno presentan riesgos y ritmos de cambio distintos.

La versión LTS es adecuada cuando es más importante contar con una versión que permita planificar a largo plazo que disponer continuamente de nuevas funciones. Durante su periodo de vigencia, esta rama recibe principalmente actualizaciones de seguridad, críticas y de compatibilidad. Por lo tanto, LTS no implica suspender las actualizaciones, ni sustituye a las pruebas de copia de seguridad, recuperación y dependencias. En el caso de las ofertas de alojamiento compartido ya consolidadas, esta limitación en los cambios de funcionalidad puede hacer que el soporte técnico sea más predecible.

La versión STABLE se publica con menos frecuencia que la RELEASE y ha sido sometida a más pruebas públicas. RELEASE cuenta con todas las funcionalidades y es el estándar para las nuevas instalaciones. Ambas son opciones válidas cuando se necesitan nuevas funciones, pero se realizan pruebas antes de su implantación generalizada. Por lo tanto, cuál de las dos versiones es la más adecuada depende de si para la plataforma en cuestión es más importante una disponibilidad temprana o un periodo de pruebas adicional.

CURRENT se actualiza con mayor frecuencia y puede incluir funciones que aún se están desarrollando. EDGE solo se somete a pruebas básicas y está destinado exclusivamente a entornos de prueba controlados. Los números de versión principales impares corresponden a versiones de desarrollo de la rama EDGE; no garantizan que una función esté disponible de forma estable para producción. Por lo tanto, para los servidores de producción de los clientes, EDGE no supone un atajo hacia funciones anteriores.

Coloca la Política de lanzamientos Establecido por escrito: número de animales permitidos por clase de servidor, responsables de las autorizaciones, alcance mínimo de las pruebas de staging, ventanas de mantenimiento y criterios para la interrupción. El retraso de varios días laborables se aplica exclusivamente a las actualizaciones automáticas a la siguiente versión principal en el nivel RELEASE, siempre que la actualización no se inicie de forma manual o forzada y solo se salte una versión principal. Las versiones EDGE, CURRENT, STABLE, LTS y aquellas registradas de forma fija no se acogen a este retraso.

Algunas decisiones erróneas típicas son el uso de EDGE en producción y la especificación de números de compilación concretos en /etc/cpupdate.conf, la falta de un entorno de pruebas y la suposición de que las versiones LTS no requieren actualizaciones de seguridad. Igualmente problemático es equiparar una ejecución satisfactoria del programa de actualizaciones con una aprobación técnica. Solo cuando se hayan comprobado las funciones de los clientes, las automatizaciones, los complementos y los mecanismos de protección en la medida prevista, una actualización técnica se convierte en un cambio operativo controlado.