# 2020/07/04 (Hub infra) ## Présences * HgO * Tharyrok * tierce * deuxnixx * fredux ## Météo Moment informel. La fin prévue est a 17h (au pif) ## Qu'est ce que l'infra ? **Fredux**: c'est là où y a tous les struc durs **deuxnixx**: Tout ce qui est backstage, mais aussi organisation pour faire des présentations, cela inclut le réseau humain. Insaisissable, en mutation. **tierce**: la boite noire dont on (neutrinet et ses membres - ou n'importe qu'elles associations, entreprises ou organisation) dépendent **hgo**: le machin qui fait tourner tous nos services, une sorte de machine, le totem de 2001 l'odyssée de l'espace. Avec des trucs comme isp-ng qui fait parfois des trucs bizarres, et qu'on redémarre. Un peu mystique, et l'idée serait de le démystifié **Tharyrok** : c'est l'endroit dont tout le monde dépend mais qui n'est pas du tout facile a expliqué/comprendre et sa donne l’effet de peur voir de frayeur. Faut passer la « peur de tout ce que ça peut englober ». C'est pas qu'une boite noire, il y a beaucoup « de temps d'humain » derrière. ## Quelles sont nos attentes vis-à-vis de l'infra ? Qu'elle fonctionne (facilement, en un claquement de doigts (= digital), au doigts et à l'œil) Créer des liens, des ponts, se rendre utile, amener un support comme on peut. On devient dépendant des outils qu'on met en place. Éviter des coupures, éviter de passer de la panne ponctuelle à l'instabilité, parce que du côté des utilisateurs cela devient difficile de faire la promotion de l'auto-hébergement ou de l'assos. En même temps, c'est aussi un laboratoire. Pouvoir « revendiquer » l'erreur. Définir des points clés, de base, qui doivent fonctionner coûte que coûte (mails, vpn, etc.), en parallèle des autres outils / services « laboratoires » En attendre un service, parce qu'il n'est pas toujours possible de « s'y investir » et peut-être pouvoir soutenir, même pécuniairement. Avoir une vision des différents « modules » de Neutrinet comme il y a la brique, yunohost, le vpn, etc. L'aspect humain de l'infrastructure est important, et il y a l'espoir de ne pas « tout » reposer sur une personne. En profiter pour documenter notre infra, de sorte à faciliter le partage de connaissance et distribuer la charge de travail. Il faudrait donc une transparence entre le « noyau dur » au moins, sans quoi l'idée même de transparence et de partage n'est pas cohérente. Se donner du temps de faire les choses. Qu'on ne travaille plus dans l'urgence, qu'elle soit réduite au maximum. Qu'on puisse accueillir des nouveaux·elles et qu'on puisse leur dire que si il y a de la « casse », pouvoir facilement réparer. On a pas la possibilité de créer un laboratoire, de simuler l'infra pour avoir la liberté de tester et ça serait bien d'y penser. Qu'elle ne consomme pas de resource humide ? humble ? humoristique ? mais on a déjà fredux... ## Back to the past / Retour aux sources 92.1 FM https://pads.domainepublic.net/p/Neutrinet-infra-2019 ligne 144 "Réunion du 29/01/2019" À l'époque, Tharyrok voulait se mettre en retrait du hub infra, et donc l'idée était que les autres participants proposent la nouvelle infra, et tharyrok serait là pour l'appliquer [ Au final, quelques semaines/mois plus tard, il ne restait pas grand monde dans le hub infra (tierce et tharyrok) ] Pour éviter d'avoir un service qui casse (site web, vpn, etc.), il était question de haute disponibilité (HA) Donc avoir des machines physiques en haute disponibilité, et par ex une VM par service, avec même possibilité d'avoir des VMs pour les copains, membres, etc. À l'époque, il y avait deux pôles « bare-metal » et « HA + VMs », mais le pôle bare-metal a disparu chez Neutrinet Exemple de HA : * Une alimentation pète : * en HA les services tournent encore, on a le temps de venir remplacer l'alim * en bare-metal : ben on a perdu tous les services sur le serveur où y avait l'alim, donc c'est la panique, l'urgence, le CHAOS En HA, les notions de « réseau » sont différentes (plus abstraites) que pour le bare-metal. Beaucoup viennent, jettent un œil à l'infra, et ne viennent plus. Avoir accès aux différentes machines, c'était pas facile. En partie parce qu'il y avait des trucs « fragiles ». Il faut des prérequis techniques … et pour de la HA … il en faut plus encore. Mais on pourra intégrer les nouveaux par étape, en créant une VM perso pour faire des exos, puis en donnant accès à une VM de test, puis une VM en production, et puis enfin (le graal) Proxmox Au tout début, dans les temps anciens, est-ce que c'était du bare-metal ? C'est tharyrok qui a installé Proxmox + ceph, mais avant c'était du KVM libvirt et du drbd, ce qui ne marchait pas trop bien. Puis le drbd à pété (2016-2017) et on a dû aller physiquement changer le drdb en glusterfs avec proxmox et puis encore après glusterfs à aussi lâché. ## Comment emménager les serveurs HP (physique) * Avoir une date de la part de Verixi (TODO : tharyrok va relancer Verixi pour une date) * Il faut une voiture (probablement) parce que je (HgO) ne me vois pas trimballer les serveurs dans le bus sous le bras, masqué * deuxnixx a une voiture, mais en août ce ne sera pas possible pour lui * la mère d'hgo a aussi une voiture, mais elle revient fin juillet ## Comment récupérer les serveurs SuperMicro (physique) * Définir une date pour venir chercher les serveurs * Il faut une voiture * Inscrire la voiture chez i3d (n° de plaque) + carte d'identité (cela prend 1 semaine) * Casser le contrat avec i3d Le trajet : https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=50.81858%2C4.38738%3B51.91251%2C4.53911#map=9/51.3708/4.5653 ## Comment migrer l'infra (i3d vers verixi) Voir le schéma analogique de tharyrok https://files.neutrinet.be/s/btYHNFK7jG6S3Ng * Update whois as204059 annonce IP/PA (il faut annoncer en amont que Verixi peut annoncer notre bloc d'IP) * Update le whois pour les reverses dns * Créer et config les vm Edge (1,2) & pfsense (1,2) Est-ce qu'on déménage le SuperMicro chez Verixi ou bien est-ce qu'on va le chercher après avoir installé les HPs + Comptoir et migrer les VMS ? Et au sujet de migrer les VMS, est-ce qu'on les migres « telles quelles » ou bien est-ce qu'on remplace ISP-NG « avant » ? * On va être obligé de garder ISP-NG pendant un moment, le temps de la migration vers le nouveau VPN, parce qu'on passera d'un système à un autre, qui ne seront pas compatibles entre-eux * Donc le temps que toutes les briques utilisent le nouveau VPN, il faudra que ISP-NG tourne toujours (par ex pendant 6 mois le temps de la transition) * Pour les autres VMs, ce serait possible de séparer la grosse VM web en plusieurs petites (backoffice, website, wiki, etc.) mais évidemment on pourra aussi le faire plus tard Plan d'action : * Sauvegarde des vm chez i3d * Restauration des vm chez verixi Volonté de faire le projet Chez Mémé, projet de colocation d'une baie * Nécessité d'acquérir du matos (par ex switches) pour le réseau, notamment faire des sessions BGP * On peut faire sans ces switches au début, il faudra juste garder ça en tête pour plus tard * En fait, ce sont les VM edge qui vont prendre la place de ces switches « en attendant » et le jour où on les achète, on éteint les VM edge * Déménagement des IPs à prévoir si on compte prévoir le réseau de Chez Mémé * Ce qui se fait assez facilement, cependant les personnes qui auraient utilisé les IPs « en dur » au lieu de vpn.neutrinet.be (par ex) seraient dans le dark choucroute * Communication à faire de notre part, et actions à faire pour ces quelques membres * Actuellement les ip .1, .2, 3 sont sur des VMs (notamment Gateway) MAIS migrer Gateway sur la nouvelle config / infra Proxmox / avec les VM Edge actuelles, c'est pas compatible parce qu'elles sont prévues temporairement en tant que Switch/Routeurs/BGP dont nous aurons besoin pour ChezMémé. Parce qu'il y aura un changement d'IP pour « vpn.neutrinet.be » (le serveur auquel se connectent les clients) ET que certain·e utilisent les IPs 80.67.181.3 et 2001:913:1000::3 en dur dans leur config, il faudra avertir les membres que ces IPs vont changer (ou leur rappeler d'utiliser le nom dns). * À noter que : les briques ayant l'app Neutrinet voient leur config VPN gérée par cette app (donc pas de hardcodage) * TODO : faire un mail expliquant cette histoire Le schéma du futur réseau : https://files.neutrinet.be/s/btYHNFK7jG6S3Ng Et c'est pareil ici : Edge-01 = 2001:913:1000::2 Edge-02 = 2001:913:1000::3 Edge-00 = 2001:913:1000::1 (ip vip = ip flottante partagée par deux ou plusieurs VMs) pfsense-01 = 2001:913:1000::4 pfsense-02 = 2001:913:1000::5 pfsense-00 = 2001:913:1000::6-7-8-9-... (ip vip = ip flottante) par exemple 2001:913:1000::4 nous sert pour la vm web, vpn, mail .... ## Météo de fin et prochaine réunion Moment informel. Prochaine réunion : à définir après avoir fixé date avec Verixi ## Ansible ;) Dépot git : https://git.domainepublic.net/Neutrinet/infra Comment un décrit « proprement » une infra, ses hôtes et ses services avec un Ansible, pour éviter de devoir « décrire sur des pads et des pages wiki » quelque chose qui est technique ? Ajouté des readme a chaque arborescence pour apporté des informations humain qui explique les raisons de nos choix.Ajouté dans le code au endroit stratégique de l'information. Par exemple : https://gitlab.domainepublic.net/Neutrinet/infra/-/blob/045baf404346288d410017f7bb969d5b9ec9019a/hosts On rajoute du terraforme ( https://github.com/Telmate/terraform-provider-proxmox ) ? Création d'infrastructure, dans le sens création de VM, d'hardware, etc. et permet de documenter à un plus bas niveau que Ansible (les deux sont complémentaires) * cela créer un détachement sur ce qui va ce passer On ajoure awx ? Maintenance dans le temps, permet de s'assurer que l'infrastructure est toujours celle qu'on avait définie Dans tous les cas, c'est beaucoup trop tôt pour se positionner * Nous aider a détecter quand le code sur gitlab n'est pas le même sur la vm. Peut nous aider a déployer automatiquement. Besoin de faire des réunions pour penser notre infra Ansible * Bien penser la question de la documentation (a priori dans des Readme plutôt que dans le wiki) en restant économe et « humain» comme par exemple ci-dessous où « un peu de commentaire » peut en dire long : * https://gitlab.domainepublic.net/Neutrinet/infra/-/commit/045baf404346288d410017f7bb969d5b9ec9019a * https://gitlab.domainepublic.net/Neutrinet/infra/-/commit/99990221c6be92a66802a0e97846b119bdeba2f7 * Inclure les personnes qui ne connaissent pas Ansible ## Password-store Pour rappel, on a un password store : https://gitlab.domainepublic.net/Neutrinet/password Et maintenant, le mot de passe d'i3d il s'y trouve didans. Peut-être faire un Readme pour notre password store, ne serait-ce que pour savoir comment l'utiliser (ajout d'utilisateur -> besoin de clé gpg, etc.) * https://woile.github.io/gopass-cheat-sheet/ * https://ps.zoethical.org/t/gnuragistes-et-lutilisation-de-gitea/3817 ## Météo de fin fin Ainsi fin fin fin les petites marionnettes Moment informel. ## New ISPNG TODO ## New Carnet rose TODO ## New Tharyrok 3000 TODO L'ancien étant tout cassé, je propose de remplacer le Tharyrok actuelle par le nouveau modèle 3000, beaucoup plus efficace. ## Matériel a acquérir Pour le « test » j'ai mis ces liens dans le hosts de ansible : https://gitlab.domainepublic.net/Neutrinet/infra/-/blob/master/hosts https://www.serverhome.nl/psu-hp-750-506822-101-hstns-pd18.html https://www.serverhome.nl/parts/harddisk/brackets/hp/hp-bracket-gen8-651687-001.html https://www.serverhome.nl/hp-smart-array-p420-raid-controller.html --- Idée créer des réunions explication du VPN avec les membres Créer des réunions hub infra explicative sur l'infra {{tag>infra}}