19 juin 2026 3 min de lecture

HIN Mailgateway 15.0.5 : corriger la panne de connexion après la mise à jour du cluster

Après la mise à jour d’un cluster HIN Mailgateway vers la version 15.0.5, la connexion échoue après quelques minutes sur les deux nœuds. Cette procédure permet de remettre les appliances en service de manière contrôlée.

Lors de la mise à jour d’un HIN Mailgateway de la version 14.1.4.2 vers la version 15.0.5, une erreur dans la réplication du cluster peut empêcher la connexion sur les deux appliances. Les systèmes individuels ne sont pas concernés. Le fabricant connaît le problème et prévoit un correctif dans une version ultérieure.

Mise à jour du 29 juillet 2026 : Le correctif annoncé est disponible. La version corrective 15.0.6 empêche le rehachage du mot de passe lorsque les membres du cluster utilisent des versions de firmware différentes. C’est exactement la configuration qui avait déclenché la panne décrite ici. L’explication se trouve dans l’article sur SEPPmail 15.0.6 et 15.0.6.1; la procédure de restauration suivante reste pertinente pour les clusters qui effectuent encore la mise à jour vers la version 15.0.5.

Symptômes

Immédiatement après la mise à jour, l’interface web peut encore être ouverte. Environ dix minutes plus tard, la connexion échoue sur les deux nœuds du cluster. Le fait que l’erreur survienne avec un décalage et sur les deux systèmes indique que la configuration de cluster répliquée en est la cause.

Restauration

Les étapes suivantes modifient la configuration du cluster. Des sauvegardes récentes ainsi que l’identifiant du cluster doivent être disponibles au préalable.

  1. Restaurer les snapshots créés simultanément sur les deux nœuds du cluster.
  2. Après la restauration, laisser un nœud éteint.
  3. Sur le nœud en cours d’exécution, télécharger d’abord l’identifiant du cluster, puis dissoudre le cluster.
  4. Attention : après sa dissolution, l’appliance redémarre immédiatement, sans autre confirmation.

  1. Mettre à jour le premier nœud vers la version 15.0.5, puis l’arrêter.
  2. Démarrer le second nœud et y répéter les mêmes étapes.
  3. Ne reconstruire le cluster conformément à la documentation du fabricant que lorsque les deux systèmes fonctionnent individuellement et disposent de la même version.

Cette procédure empêche qu’une configuration défectueuse soit à nouveau répliquée entre les nœuds pendant la mise à jour.

Sources

  1. Documentation SEPPmail – « Cluster / haute disponibilité »
    types de clusters et réplication de la configuration sur tous les nœuds.
    https://docs.seppmail.com/ch/04_com_09_cl_01_general.html
  2. Documentation SEPPmail – « Administration »
    ordre de mise à jour dans le cluster (frontend avant backend) et exigence de versions identiques.
    https://docs.seppmail.com/de/07_mi_11_adm__administration.html
  3. HIN Mailgateway : Backup & Disaster Recovery dans le cluster
    analyse approfondie de la réplication du cluster, de la sauvegarde et de la restauration.
    https://rafaelpfister.ch/blog/hin-mailgateway-backup-disaster-recovery

Commentaires

Les commentaires sont chargés depuis GitHub / Giscus.