Proposition Scénario #21110
restauration.sh : pouvoir restaurer sur un zephir non instancié
0%
Description
Nous avons un parc de 5 zephirs 2.5.2 et un zephir 2.6.1 en environnement virtualisés.
4 zephirs 2.5.2 et le 2.6.1 sont connectés à notre annuaire ldap en ldaps; le dernier 2.5.2 a une base locale. Ils possèdent tous un certificat valide de notre IGC et l'ensemble fonctionne correctement.
Pour pouvoir déployer la 2.6 chez nous, il nous faut migrer tous les zephirs vers la 2.6.1.
Voici la méthode utilisée, procédure rodée jusqu'à la 2.6 :
sur un 2.5.2 à migrer, récupération du tarball issu de sauvegarde.sh
réinstallation en 2.6.1
instanciation à "vide" car sinon restauration.sh ne fonctionne pas
restauration.sh
instanciation
Résultat :
pour les 4 zephirs 2.5.2 ldapisés => ko
pour le zephir 2.5.2 autonome => ok
La panne se caractérise par une authentification frontend impossible, le backend tournant sans soucis.
Au reconfigure apparaît :
Doing /usr/lib/ssl/certs WARNING: Skipping duplicate certificate ca_local.crt WARNING: Skipping duplicate certificate ca_local.crt WARNING: Skipping duplicate certificate ACCVRAIZ1.pem WARNING: Skipping duplicate certificate ACCVRAIZ1.pem WARNING: Skipping duplicate certificate eole.crt WARNING: Skipping duplicate certificate eole.crt WARNING: Skipping duplicate certificate infrastructures.pem WARNING: Skipping duplicate certificate infrastructures.pem Chaîne de certificats incomplète.
Pour essayer d'avancer, on refait la même procédure mais en partant de l'iso 2.6.0.
Même punition ...
Évidemment, plein de tests sur les certificats; rien à faire !
Pour finir, on a profité de la virtualisation pour cloner le zephir 2.6.1 ldapisé existant et pour rapatrier la sauvegarde d'un 2.5.2.
Et là, malgré le message "Chaîne de certificats incomplète", miracle, ça marche !
Moralité, il y a quelque chose de nébuleux dans sauvegarde.sh ou restauration.sh
Historique
#1 Mis à jour par Thierry Bertrand il y a plus de 6 ans
Précisions :
/etc/ssl/local_ca contient deux fichiers : le certificat racine de l'IGC et le certificat applicatif de l'IGC ayant signé le certificat du serveur zephir
lors de l'authentification, seules des erreurs sont remontées au niveau zephir_web.alert.log. Je n'ai plus le message exact en tête mais il y avait une ligne ou apparaissait l'adresse ip du serveur ldap et authentification échouée
on pouvait faire un ldapsearch en ldaps sans soucis depuis le zephir.
#2 Mis à jour par Emmanuel IHRY il y a plus de 6 ans
le message sur les certificats apparaît aussi au reconfigure des seth . Je ne sais pas s'il y a un rapport
eole-schedule - WARNING: Skipping duplicate certificate ca-certificates.crt
eole-schedule - WARNING: Skipping duplicate certificate ca-certificates.crt
eole-schedule - WARNING: Skipping duplicate certificate eole.pem
eole-schedule - WARNING: Skipping duplicate certificate eole.pem
eole-schedule - WARNING: Skipping duplicate certificate ca_local.crt
eole-schedule - WARNING: Skipping duplicate certificate ca_local.crt
eole-schedule - WARNING: Skipping duplicate certificate infrastructures.pem
eole-schedule - WARNING: Skipping duplicate certificate infrastructures.pem
#3 Mis à jour par Thierry Bertrand il y a plus de 6 ans
pour préciser, j'ai fait la manip suivante hier sur un zephir 2.5.2. Cependant, contrairement à l'infra de production, celui-ci ne possède qu'une base locale.
1 - sauvegarde.sh puis externalisation
2 - réinstallation depuis l'iso 2.6.1 amd64
A ce niveau, la reinstallation sur une machine avec des partitions présentes n'a pas fonctionné. Il a fallu que je passe par parted pour tout supprimer. Bug ou problème matériel ? Je retesterai sur VM + tard.
3 - instanciation avec une conf minimale (au passage, instancier pour pouvoir rappatrier un backup, c'est lourd...)
4 - remise en place de la sauvegarde sous /var/liv/zephir_backups
5 - restauration.sh
6 - gen_config
7 - instance avec préservation des bases.
Du coup, c'est passé. Pas de problème avec le certificat ssl du zephir.
Donc la seule différence se trouve au niveau de la base de compte. Sur l'infra nationale, en 2.5.2 on s'appuyait sur un patch au niveau du ldap.conf pour préciser le certificat "client". En 2.6.1, cette façon de faire semble poser problème.
#4 Mis à jour par Daniel Dehennin il y a plus de 6 ans
Emmanuel IHRY a écrit :
le message sur les certificats apparaît aussi au reconfigure des seth . Je ne sais pas s'il y a un rapport
eole-schedule - WARNING: Skipping duplicate certificate ca-certificates.crt
eole-schedule - WARNING: Skipping duplicate certificate ca-certificates.crt
eole-schedule - WARNING: Skipping duplicate certificate eole.pem
eole-schedule - WARNING: Skipping duplicate certificate eole.pem
eole-schedule - WARNING: Skipping duplicate certificate ca_local.crt
eole-schedule - WARNING: Skipping duplicate certificate ca_local.crt
eole-schedule - WARNING: Skipping duplicate certificate infrastructures.pem
eole-schedule - WARNING: Skipping duplicate certificate infrastructures.pem
Ces messages informent que certains certificats sont en double et qu’une seule copie est utilisée, et non pas qu’il en manque.
#5 Mis à jour par Gérald Schwartzmann il y a plus de 6 ans
- est-ce que sauvegarde.sh et restauration.sh peuvent être améliorés ?
- est-ce que le problème rencontré vient du patch ou du Zéphir ?
- est-ce que le message WARNING: Skipping duplicate certificate peut/doit être évité ?
#6 Mis à jour par Gérald Schwartzmann il y a plus de 6 ans
- Assigné à mis à Gérald Schwartzmann
#7 Mis à jour par Gérald Schwartzmann il y a plus de 6 ans
- Statut changé de Nouveau à En attente d'informations
#8 Mis à jour par Thierry Bertrand il y a plus de 6 ans
est-ce que sauvegarde.sh et restauration.sh peuvent être améliorés ?
Instancier un zephir pour pouvoir ensuite rapatrier une sauvegarde est une étape qu'il faudrait pouvoir éviter.
est-ce que le problème rencontré vient du patch ou du Zéphir ?
A priori, plutôt du zephir.
est-ce que le message WARNING: Skipping duplicate certificate peut/doit être évité ?
il introduit un doute donc s'il était évité ce serait un plus.
Après ce n'est qu'un warning ...
#9 Mis à jour par Thierry Bertrand il y a environ 6 ans
- Tracker changé de Demande à Proposition Scénario
- Sujet changé de restauration.sh : soucis de certificats ssl à la migration de version à restauration.sh : pouvoir restaurer sur un zephir non instancié
La procédure de restauration actuelle oblige à instancier le zephir avant de pouvoir faire toute restauration.
C'est une étape superflue qui pourrait être évitée.