21/07/2017: Remontage hwhost2 lors d'une réunion hackstub Installation de Puppet (doc ARN https://wiki.arn-fai.net/technique:puppet)

Réflexion 1 : on supprime le certif sur hwhost-2 et on procède comme pour un fresh instal

Suite à cela on modifie le hostname en ajoutant le fqdn

Commande pour supprimer le certif sur le LXC “puppet” Affichage de la totalité de la liste des certifs sudo puppet cert list –all Purge du certif puppet sudo puppet cert clean hwhost-2.arn-fai.net

Création du nouveau certificat puppet agent -t –server puppet.arn-fai.net

problème de version : le master doit être plus haut comme version que les clients… on met à jour le master à stretch (vu qu'il faudra de toutes façons le faire un jour…) réinjecter les confs dans le puppet.conf (allow des IP)

allow_ip 89.234.141.0/24 # ARN allow_ip 169.254.69.0/24 # Interco hwhosts allow_ip 91.224.149.146/32 # alsace.ttnn

LXC a pas reboot, il faut le relancer depuis la VM int.

signature certificat puppet sudo puppet cert sign hwhost-2.arn-fai.net

ça fonctionne mais n'applique aucune config

https://docs.puppet.com/puppet/4.0/upgrade_server.html

tentative (cf doc plus haut) :

root@puppet:/etc/puppet# mkdir -p code/environments/production/ root@puppet:/etc/puppet# mv manifests/ modules/ code/environments/production/

Node inheritance often causes ambiguous or counterintuitive behavior. More effective code reuse can be achieved using classes and defined types.

on n'a plus import ni inherits

https://groups.google.com/forum/#!topic/puppet-users/L54vNTSQN68

inherits ⇒ class + require

problème import qui n'est plus relatif : https://docs.puppet.com/puppet/3.8/deprecated_language.html#relative-resolution-of-class-names ⇒ passer à des import absolus (dans les import et les déclarations de classes)

compatibilité des modules installés : https://github.com/saz/puppet-locales puppet module upgrade saz-locales Notice: Preparing to upgrade 'saz-locales' … Notice: Found 'saz-locales' (v2.0.1) in /etc/puppet/code/environments/production/modules … Notice: Downloading from https://forgeapi.puppet.com … Notice: Upgrading – do not interrupt … /etc/puppet/code/environments/production/modules ??? saz-locales (v2.0.1 → v2.4.0)

https://github.com/netmanagers/puppet-bacula ⇒ I don't have the time required to actively add new features, fix issues other people report or port it to Puppet 4.x. ⇒ désactivé pour le moment…

gid de groupe ne doit plus être vide… ?! mis 27 pour sudo

Notice: Applied catalog in 51.58 seconds

login normal ok pas de motd ⇒ toujours vide même sans template, mis le module à jour, perdu les templates… mais fonctionne, recréé les templates ⇒ pas accès aux backup à l'intérieur de puppet modules/manifests

23/07/2017:

Il est plus que temps de faire un point là-dessus, ça a assez traîné…

On a fait une grande séance de travail avec accès + mumble le 11/07. La soirée a permit de remonter toute la partie réseau, adressage, routage, etc. Depuis ça tourne, pas de problème constaté. On peut supposer que cette partie est réglée.

Vendredi dernier, comme les participants du 11/07 étaient à la réunion hebdomadaire Hackstub au Shadok, on s'est dit qu'on pourrait avancer quelques bricoles entre deux. On essaye donc d'avancer un peu sur puppet, avec la grande télé branchée pour afficher.https://wiki.arn-fai.net/technique:puppet Il faut mettre à jour le serveur puppet, qui passe d'une version 3.x à 4.x et donc tout migrer… en commençant par mettre à jour le LXC vers stretch. Puis les manifests. Plus rien ne fonctionne, on fait 2/3 tentatives puis il est trop tard. Jonathan : Je viens de terminer de faire tomber en marche puppet, dans mon coin parce que absolument pas passionnant et beaucoup plus facile de se concentrer comme cela. Il reste le module bacula qui ne passe pas et qui n'est plus maintenu.

On a donc maintenant une machine qui commence à être “normale” avec une configuration (SSH etc.) correcte et correspondant aux autres.

Il reste des “petites choses” comme iptables, ucarp, le RAID… Et il reste ganeti. Je me suis dit que peut-être qu'on pourrait installer l'ancienne version de ganeti pour être raccord avec celle de hwhost-1 et ensuite mettre à jour avec un cluster réparé ?

25/07/2017:

### Raid Lors de l'installation 4 disques ont été ajouté en raid dans le array md0. Un cinquième disque (le seul ssd qui a survécu sur l'ancien serveur) a été inséré pour être utilisé en spare. On constate toutefois que ce dernier a été ajouté dans un autre spare. CI dessous les actions que nous avons fait pour ajouter Voir les raid ``` $ cat /proc/mdstat Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10] md127 : inactive sde1[4](S) 499942400 blocks super 1.2

md0 : active raid5 sdc1[2] sda1[0] sdd1[3] sdb1[1] 1499925504 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU] bitmap: 1/4 pages [4KB], 65536KB chunk ```

Stopper un “array” de disque ``` mdadm -S /dev/md127 ```

mdadm –remove /dev/md127

# mdadm /dev/md0 –add-spare /dev/sde1 | mdadm: Cannot open /dev/sde1: Device or resource busy

mdadm –remove /dev/md127 Lancer rapidement ensuite la commande suivante (sinon ça remonte automatiquement…) mdadm –zero-superblock /dev/sde1 mdadm /dev/md0 –add-spare /dev/sde1 mdadm: /dev/sde1 not large enough to join array

apt-get install partprobe #(pour avoir

Copier la table de partition sur le disque sfdisk -d /dev/sda | sfdisk /dev/sde

Et là ça passe :) mdadm /dev/md0 –add-spare /dev/sde1

26/07/2017: ganeti sur hwhost-2 (johndescs)

https://wiki.arn-fai.net/technique:ganeti#reinstaller_un_hyperviseur_suite_a_une_panne_materielle

ipv6 que depuis 2 et pas 1 zebra a bien la route : K>* 2a00:5881:8110::/56 via fe80::42:2, tap0 il semblerait qu'il y ait une “route ipv6 de la mort” ou tout autre pb avec interoute (et juste interoute), qui empêche quagga d'envoyer (à hwhost1) quoi que ce soit quand cette session est active… (outQ reste bloqué à un nombre de routes non envoyées variables) revenir à l'ancienne version de Quagga (celle de Jessie) : OK Entre Jessie et Stretch, on passe de la version 0.99.23 à 1.1.1… Le changelog (https://savannah.nongnu.org/news/?group=quagga ) est trop cryptique pour qu'on sache en tirer quoi que ce soit. ⇒ TODO: poser un bugreport chez Quagga et essayer de debug avec eux (car nous n'avons aucune idée de comment debug :/ ). En attendant, notre quagga tourne sans la session Interoute IPv6.

gnt-cluster verify vérifie et constante une incohérence quand aux paramètres d'instance-debootstrap (qu'on n'utilise plus en réalité). On refait le dpkg-divert quand même… dpkg-divert –add –rename –divert /usr/share/ganeti/os/debootstrap/parameters.list.divert /usr/share/ganeti/os/debootstrap/parameters.list cp /etc/ganeti/instance-debootstrap/parameters.list /usr/share/ganeti/os/debootstrap/parameters.list

(lg) ouais, on a acté qu'on n'utilise plus le passage de paramètres par Ganeti depuis que nos hooks savent les récupérer direct dans les descriptions des VM dans /etc/ganeti/arn. Donc je ne màj pas le tuto sur le wiki afin de le garder clean. TODO: la meilleure solution serait donc de clean ces paramètres dans la définition des VMs et sur hwhost1 et ainsi d'en finir proprement.

TODO: vérif que /var/lib/ganeti/config.data est bien backup !

UCARP

reprise des fichiers de conf git de l'unit systemd et des script up/down

installer thc-ipv6 ⇒ (lg) Information ajoutée dans la doc' (https://wiki.arn-fai.net/technique:carp#scripts ) et dans le code (http://gitlab.netlib.re/arn/arn-confs/commit/899f398a57a467743b019772101d3a1bdbcd9048 )

tester, ça fonctionne

SNMPd

Zabbix dit toujours “snmp timeout”. ⇒ snmpd n'est pas lancé par l'unit car elle demande d'exec snmpd avec l'utilisateur « snmp » qui a disparu de Stretch, remplacé par « Debian-snmp ». =⇒ On allait patcher notre unit quand on a vu que le package debian en propose une désormais. Mais elle positionne la verbosité à un seuil qui ne nous a jamais convenu ==⇒ On patche l'unit et on la met dans notre git : http://gitlab.netlib.re/arn/arn-confs/commit/6ac02c29ed2ec0ae66d13a30c99e628a7423ed34

=⇒ Si l'utilisateur qui fait tourner snmpd change, il faut aussi adapté /etc/sudoers sinon les checks qui ont besoin des droits root (check_lvm, check_ucarp, check bgpd) ne fonctionnent plus.

Le check_ucarp continue à sortir en erreur dans Zabbix ⇒ snmpd retourrne désormais la sortie (stdout) du check sous un format hexadécimal. Forcément, notre Zabbix, configuré pour chercher la chaîne de caractère “BACKUP” reste en erreur =⇒ changer l'OID que Zabbix doit demander au serveur snmp afin de récupérer à nouveau la valeur textuelle.

26/07/2017: Parefeu sur hwhost-2 (ljf)

hwhost-2 est sous debian stretch, le parefeu a changé depuis jessie ce n'est plus iptables mais nftables. nftables a un avantage comparé à jessie c'est qu'il gère nativement les data set (équivalent de ipsets).

Il existe un outil pour convertir des règles iptables en nftables, exemple: ``` # iptables-translate -A INPUT -p tcp –dport 22 -m conntrack –ctstate NEW -j ACCEPT nft add rule ip filter INPUT tcp dport 22 ct state new counter accept ```

Pour y avoir accès il faut installer 'iptables-nftables-compat' qui contient iptables-translate ``` # apt-get install iptables-nftables-compat ```

Après essai de conversion, ça ne marche pas à cause des ipsets, l'outil ne convertit pas les ipsets, uniquement les règles classiques de iptables ``` # iptables-restore-translate -f rules.v4 […] iptables-translate-restore v1.6.0: Set intlink doesn't exist.

Error occurred at line: 16 ```

Il est toutefois possible de faire la transcription à la main, des ipsets en data set. je suppose qu'ensuite le message disparaitra Tentative avec “intlink” (nom donné à un des ipsets) ``` create intlink hash:net family inet hashsize 1024 maxelem 65536 add intlink 89.234.141.131/32 add intlink 169.254.69.1/32 add intlink 89.234.141.130/32 ``` Devient (sans doute) ``` nft -f /etc/nftables.conf nft add set filter intlink {type ipv4_addr\; flags constant\; size 65536\; elements=\{89.234.141.131,169.254.69.1,89.234.141.130\} \;} ```

Malheureusement, 'iptables-restore-translate -f rules.v4' redonne la même erreur.

Proposition: faire la transcription ligne par ligne avec iptables-translate en remplacant les ipsets. Puis intégrer les data sets.

Je m'arrête là.

(johndescs 29/07) restaurer pour l'instant comme avant et faire cela plus tard…

apt install iptables-persistent copie des fichiers ipsets, rules.v4, rules.v6 depuis les backup dans /etc/iptables, vérifications visuelles instructions et utilisation des ipsets : https://wiki.arn-fai.net/technique:bcp38 wget http://gitlab.netlib.re/arn/arn-confs/raw/master/bcp38/05-ipsets -O /usr/share/netfilter-persistent/plugins.d/05-ipsets dpkg-divert –add –rename –divert /usr/sbin/netfilter-persistent.divert /usr/sbin/netfilter-persistent wget http://gitlab.netlib.re/arn/arn-confs/raw/master/bcp38/netfilter-persistent -O /usr/sbin/netfilter-persistent

port 2222 bien présent dans les règles et BMC activée et logué dessus, je tente un load service netfilter-persistent start ⇒ rien faire un chmod +x /usr/sbin/netfilter-persistent et chmod +x /usr/share/netfilter-persistent/plugins.d/05-ipsets et installer ipset… apt install ipset

il manque les deux dernières lignes du fichier ipv4, alors que dans les backup ils y sont…

⇒ ok les règles se chargent et semblent fonctionner

(lg) j'ai patché la page de wiki https://wiki.arn-fai.net/technique:bcp38 pour prendre en compte les manques identifiés par John.

30/07/2017:

Hier j'ai donc remis rapidement le pare-feu comme il était avant, avec iptables. On garde ce début de taff sous le coude, pour quand on aura migré l'autre machine aussi en Stretch je pense ?

Dans la foulée j'ai attaqué ganeti. Je suis parti, comme proposé plus tôt, de la version de Jessie, installée sur Stretch. Ça s'est bien passé ! Pas de soucis avec DRBD malgré une différence de version (mineure). Bon bien sûr ça a pris du temps, une erreur après l'autre. Il a fallu recréer tous les volumes LVM à la main (mais c'est facile, une fois sûr que ça fonctionne, de faire un petit script) et initialiser les metadata de DRBD. Au bout de 6h de taff, il y avait un ganeti fonctionnel, et possibilité de migrer entre les deux machines (avec redémarrage du VPS, car il y a des problèmes de compatibilité dus aux différences de versions pour la migration “en live”, sans redémarrage).

À 22h il subsistait un seul problème : les routes IPv6 des VM n'étaient pas retransmises de hwhost-2 vers hwhost-1. Problème qu'on avait déjà vu au moment de remonter le routage et qui avait disparu automagiquement – et manifestement, temporairement. Avec lg on a creusé et on a déterminé que c'était Quagga qui oubliait subitement de transmettre quoi que ce soit en IPv6 lorsqu'il montait la session avec notre transitaire Interoute. Avec uniquement Cogent et la transmission en interne, pas de soucis. Et avec l'ancien Quagga de Jessie, pas de soucis non plus… probablement un sale bug… À voir si on passe à Bird (dommage car on voulait rester sur deux codes différents) ou si on arrive à debug, avec les développeurs par exemple.

Entretemps, on a fait la synchronisation de quelques disques de VM entre les deux machines, puis à la fin, vers 2h, on a lancé la réplication de toutes les données des VM via DRBD. Ce matin la synchro est donc rétablie ! Les VPS sont enfin de nouveau redondés entre les deux machines. On va du même coup pouvoir recréer des VPS.

Tant qu'on y était avec lg, on a aussi remonté le uCARP (qui permet d'avoir un routeur “virtuel” pour redonder la sortie vers internet de l'hébergement physique, https://wiki.arn-fai.net/technique:carp) puis remonté le monitoring… a priori la machine est à peu près opérationnelle.

Il faudra encore tester, créer les 3 VPS en attente, et bientôt migrer ganeti de 2.12 à 2.15 puis hwhost-1 en Stretch pour terminer complètement l'opération et être à jour !

Nous avons amélioré les pages de documentation du wiki (<https://wiki.arn-fai.net/technique>) en y ajoutant quelques petits détails qui n'y étaient pas consignés. De même, les scripts que nous avons dû modifier ont été poussé dans notre dépôt de code (<http://gitlab.netlib.re/arn/arn-confs>).

Nous avons aussi produit une sorte de tutoriel pour réintégrer un hyperviseur défunt à une grappe d'hyperviseurs orchestrée par Ganeti. Voir :<https://wiki.arn-fai.net/technique:ganeti#reinstaller_un_hyperviseur_suite_a_une_panne_materielle>.