27 juin 2017 : Au DC
Voilà, on a un système Debian 9 Stretch sur l'IBM, qui fonctionne ! \o/
Détails : Le plus gros problème a été d'installer le gestionnaire d'amorçage (bootloader, ici GRUB). Avec notre configuration (UEFI et table de partition GPT), on doit soit avoir une partition EFI (boot normal EFI) soit passer en legacy (boot BIOS/MBR) mais, là aussi, à cause du GPT, on doit avoir une (plus petite) partition pour GRUB. Sauf que le debian-installer n'a pas voulu nous laisser faire une partition aussi petite que sur l'autre machine (l'idée était de faire totalement symétrique). Et l'outil de l'installer disponible en ligne de commande ne supporte pas le type de partition nécessaire pour GRUB. Il a donc fallu installer gdisk à la main après installation, en chroot depuis le debian-installer. Et une fois la partition pour GRUB créée, basculer de GRUB-efi à GRUB-pc pour repartir en mode boot BIOS comme c'est le cas sur l'autre machine.
Une fois l'OS démarré, l'installation étant basée sur une netinst, le système est vraiment minimal. Pour l'instant on a juste installé OpenSSH. Pour installer les paquets, on a configuré le lien interne entre les deux machines, puis mis l'IP publique de la machine sur la même interface. Avec une route par défaut et la route qui va bien sur l'autre machine, on a donc du vrai net dessus (mais donc on peut s'en prendre plein la tronche). Seule la configuration du lien interne est “en dur” dans les confs. On a aussi renommé les interface “comme avant” eth0/eth1 au lieu des noms reproductibles modernes.
Actuellement on peut donc se connecter, via l'autre machine, au système tout frais. La prochaine étape est probablement de relancer le routage, donc Quagga, en partant des configuration des backup et de la doc en ligne dispo ici :http://gitlab.netlib.re/arn/arn-confs/tree/master/routing/bgp/Quagga
Il y a aussi le 5e SSD de spare à reconfigurer, car on a fait l'installation sans, pour être sûrs de prendre les 4 nouveau pour le RAID en temps normal.
Côté ganeti, il y a un backport pour Jessie de la version de Stretch, donc on peut éventuellement l'utiliser avant de faire l'upgrade. À voir si ça passe niveau DRBD…
Mardi 11 juillet 2017 : Remontage de l'infra (pas forcément à publier) (en faire une page technique ?)
La discussion a lieu sur mumble.michalon.eu
Pour se connecter ``` ssh XXX@hwhost-1.arn-fai.net -P 2222 ``` Puis on se rend sur la machine IBM qui est uniquement connecté en local pour le moment (hwhost2) ``` ssh test@169.254.69.2 ``` johndescs se connecte à la BMC (carte qui permet de controller la console physique du serveur) L'objectif est d'avoir un moyen de secours si jamais on perd la connexion au serveur, ça évite d'aller au DC :) . Vu que c'est en http il faut y accéder via un tunnel qui nous amène dans la baie http://hwhost-2-bmc.arn-fai.net/#
## Remise en route du réseau ### Copie du fichier interfaces et remise des droits 644 ``` cp /home/test/brest/etc/network/interfaces /etc/network/interfaces chmod ```
### Activation de l'interface loopback1 TODO: compléter j'ai loupé l'explication Loopback1 est une interface sur la machine qui ne correspond pas a une interface physique (type dummy ifup loopback1
### Ajout de la route à la main (on passe par le liens interne entre les 2 serveurs) ip r a 89.234.141.131 dev eth1 ip r a default dev eth1 src 89.234.141.132 via 89.234.141.131 ip a a fe80::69:2/112 dev eth1
## Installation de quelques paquets utiles apt install less quagga vim
## Remise en route de quagga Quagga est le daemon qui implémente les protocoles de routage dynamique Pour s'y connecter il faut utiliser telnet puis on obtient une console pour lancer des commandes (Cisco like)
### Copie des fichiers quagga cp /home/test/brest/etc/quagga/* /etc/quagga/
### Vérifier que les routes sont bien synchronisées entre les 2 Dans /etc/quagga/bgpd.conf commenter tout ce qui est pas ibgp et le setup Grifon dans notre cas car tunnel plus actif Objectif: vérifier que les 2 machines se causent bien entre elles pour éviter le “split AS” (une espece de désynchronisation de la gestion des routes entre les 2 machines“) service zebra start service zebra status
root@hwhost-2:~# service zebra status ? zebra.service - GNU Zebra routing manager Loaded: loaded (/lib/systemd/system/zebra.service; enabled; vendor preset: enabled) Active: active (running) since Tue 2017-07-11 22:57:37 CEST; 11min ago Docs: man:zebra Process: 10794 ExecStart=/usr/sbin/zebra -d -A 127.0.0.1 -f /etc/quagga/zebra.conf (code=exited, status=0/SUCCESS) Process: 10790 ExecStartPre=/bin/chown -f quagga:quaggavty /etc/quagga/vtysh.conf (code=exited, status=1/FAILURE) Process: 10786 ExecStartPre=/bin/chown -f quagga:quagga /run/quagga /etc/quagga/zebra.conf (code=exited, status=0/SU Process: 10783 ExecStartPre=/bin/chmod -f 640 /etc/quagga/vtysh.conf /etc/quagga/zebra.conf (code=exited, status=1/F Process: 10779 ExecStartPre=/sbin/ip route flush proto zebra (code=exited, status=0/SUCCESS) Main PID: 10795 (zebra) Tasks: 1 (limit: 4915) CGroup: /system.slice/zebra.service ??10795 /usr/sbin/zebra -d -A 127.0.0.1 -f /etc/quagga/zebra.conf
pas de vtysh.conf mais probablement vide (simplement ça fait des erreurs de preexec)
routes de l'AS (DNS etc.) blackhole Ajout de la route vers le DNS ip r a 89.234.141.66 dev eth1 via 89.234.141.131
service bgpd start
telnet localhost 2601 show ip route On doit voir les routes vers tous les internet qui passe par le lien eth1
Vérifier que c'est aussi le cas pour l'ipv6
telnet bgpb 2605 MEMO:port 2605 bgp et 2601 zebra show bgp summary
### Test d'une route ip r g 89.234.141.96
### Test de l'ajout d'une route et vérification qu'elle apparait sur hwhost-1 ip r a 89.234.141.123/32 dev loopback1 ip r d 89.234.141.123/32 dev loopback1
Et vérification sur host 1 C'est OK
## Lien avec les transitaire ifup eth0 ifup cogent
Soucis lors du montage de l'interface cogent : on précise le nom de l'interface mais il nomme l'interface “renamexx” https://wiki.archlinux.org/index.php/VLAN (cf fin de la page) Lors de l'installation au DC, on a édité à la main les règles udev de nommage des interfaces pour garder les mêmes noms qu'avant, mais sans mettre la partie DRIVERS, donc potentiellement de notre fait
Test en enlevant les commentaires du fichiers de conf → /etc/quagga/bgpd.conf et relance du daemon bgpd
### On enlève les routes temporaires
ip r d default dev eth1 src 89.234.141.132 via 89.234.141.131 ip r d 89.234.141.131 dev eth1
ET on oublie pas de remettre l'ip forwarding SINON les paquets echo 1 > /proc/sys/net/ipv4/ip_forward echo 1 > /proc/sys/net/ipv6/conf/all/forwarding + éditer /etc/sysctl.conf (pour péréniser)
On a reboot la machine
/!\ Check UDP hwhost-1 regle iptable pour traceroot Lié à une règle de parefeu sur hwhost-1 Traceroute et filtrage Bilan traceroute suck si pas 10k - 12k ports ouverts
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>.