HIN Mailgateway 15.0.5: solucionar el fallo de inicio de sesión tras la actualización del clúster
Tras actualizar un clúster de HIN Mailgateway a la versión 15.0.5, el inicio de sesión falla en ambos nodos al cabo de pocos minutos. Este procedimiento permite volver a poner las appliances en funcionamiento de forma controlada.
Al actualizar un HIN Mailgateway de la versión 14.1.4.2 a la 15.0.5, un error en la replicación del clúster puede provocar que el inicio de sesión deje de funcionar en ambas appliances. Los sistemas individuales no se ven afectados. El fabricante conoce el problema y prevé una corrección para una versión posterior.
Actualización del 29 de julio de 2026: La corrección anunciada ya está disponible. La versión parche 15.0.6 suprime el rehashing de contraseñas cuando los miembros del clúster ejecutan versiones de firmware diferentes. Esta es exactamente la configuración que había provocado el fallo descrito aquí. El contexto se explica en el artículo sobre SEPPmail 15.0.6 y 15.0.6.1; el siguiente procedimiento de recuperación sigue siendo relevante para los clústeres que aún se actualicen a la versión 15.0.5.
Síntomas
Inmediatamente después de la actualización, la interfaz web todavía se puede abrir. Unos diez minutos más tarde, el inicio de sesión falla en ambos nodos del clúster. El hecho de que el error se produzca con retraso y en ambos sistemas apunta a que la configuración replicada del clúster es la causa.
Recuperación
Los siguientes pasos modifican la configuración del clúster. Antes deben estar disponibles copias de seguridad actuales y el identificador del clúster.
- Restaurar los snapshots creados simultáneamente de ambos nodos del clúster.
- Tras la restauración, dejar apagado uno de los nodos.
- En el nodo en ejecución, descargar primero el identificador del clúster y después disolver el clúster.
- Atención: tras disolverlo, la appliance se reinicia inmediatamente y sin más confirmación.

- Actualizar el primer nodo a la versión 15.0.5 y apagarlo después.
- Iniciar el segundo nodo y repetir allí los mismos pasos.
- Solo cuando ambos sistemas funcionen por separado y tengan la misma versión, volver a crear el clúster conforme a la documentación del fabricante.
Este procedimiento evita que una configuración defectuosa vuelva a replicarse entre los nodos durante la actualización.
Comentarios
Los comentarios se cargan desde GitHub / Giscus.