From 4afb7732872b4c0903af86658709cdf16238d4e1 Mon Sep 17 00:00:00 2001 From: Arnaud Daby-Seesaram Date: Thu, 29 Aug 2024 14:31:03 +0200 Subject: [PATCH 1/9] outils: logiciels: systemd. * outils/logiciels/systemd.org: Deleted file. * outils/logiciels/systemd.md: New file. skeleton of the documentation file. --- outils/logiciels/systemd.md | 64 +++++++++++ outils/logiciels/systemd.org | 198 ----------------------------------- 2 files changed, 64 insertions(+), 198 deletions(-) create mode 100644 outils/logiciels/systemd.md delete mode 100644 outils/logiciels/systemd.org diff --git a/outils/logiciels/systemd.md b/outils/logiciels/systemd.md new file mode 100644 index 0000000..8ffbe7b --- /dev/null +++ b/outils/logiciels/systemd.md @@ -0,0 +1,64 @@ +# Systemd + +Systemd est une suite logiciel pour systèmes GNU/Linux. Cette suite logiciel +fournit de nombreuses fonctionnalités, notamment pour configurer son OS et +suivre les *daemon*\ s actifs et leurs journaux. + +Ce document décrit *certaines* fonctionnalités de Systemd bien choisies, +lesquelles sont jugées intéressantes pour l'administration système ou pour +utilisateurices. Il sera sans doute découpé en plusieurs morceaux s'il devient +trop long. + + +## Unités de configuration: un format unifiant. + +### Services. + +### Minuteurs. + +### (Auto)mount. + + +## Configuration Réseau. + +### Obtenir des adresses IPs. + +### Configuration DNS (récursif). + + +## Journalisation. + +### Lecture des journaux: les bases. + +### Espaces de noms. + +### Partage de journaux entre machines. + + +## Aspect pratique (pour utilisateurices) + +### Chiffrement de disque. + +### Chargeur d'amorçage. + + +## Conteneurisation et virtualisation. + +### Conteneurisation. + +### Virtualisation. + + +## Gestion des secrets. + + +## Trucs et astuces. + +### Systèmes dynamiques: gestion des erreurs dans les services. + +### Administration à distance. + + + --> diff --git a/outils/logiciels/systemd.org b/outils/logiciels/systemd.org deleted file mode 100644 index f8ef173..0000000 --- a/outils/logiciels/systemd.org +++ /dev/null @@ -1,198 +0,0 @@ --*- mode: org; org-hide-emphasis-markers: t; -*- - -#+TITLE: Description de ~systemd~ et comment l'utiliser? -#+AUTHOR: Des nounous quelconques. -#+EMAIL: contact@crans.org -#+SEQ_TODO: TODO | in_progress | DONE -#+DESCRIPTION: Pfiou que c'est fastidieux d'apprendre à parler au monde entier. -#+INSTITUTE: Cr@ns -#+LANGUAGE: fr -#+STARTUP: overview - -Le présent document est destiné aux proptiétaires de VMs au Cr@ns, mais plus -généralement à nos membres qui souhaitent tirer le plus de ~systemd~. - -~systemd~ est une suite logicielle qui a pour objectif de fournir une interface -simple et unifiée à de nombreuses fonctionnalités du noyau Linux. En effet, les -APIs Linux sont nombreuses et les utilisations multiples des mêmes interfaces -peut être redondant. - -Par exemple, considérons la tâche "lancer une backup" et supposons que l'on -veuille (1) que la commande soit lancée un jour après que la dernière itération -se soit terminée, et (2) éviter qu'une nouvelle backup soit lancée si l'ancienne -n'est pas encore terminée. Systemd permet de paramétrer cela en quelques lignes, -là où d'autres seraient tentés de faire un cron, dont la tâche associés commence -par effectuer les vérications nécessaires au lancement conditionel. - ------ - -~systemd~ fournit un langage de configuration unifié et permet de paramétrer son -système de manière déclarative, ce qui mène à des configurations plus sûres, -systématiques et dont les sémantiques sont claires. - -* Résumé succint (et partiel) des tâches effectuées par un utilitaire ~systemd~ - -| *Tâche* | *Utilitaire disponible* | Optionel (pour un système basé sur ~systemd~) | -|------------------------+----------------------------+---------------------------------------------| -| Boot loader | ~systemd-boot~ | Oui | -| Init système (initrd) | ~systemd~ | Oui | -| Init système | ~systemd~ | Non | -| Gestionaire de service | ~systemd~ | Non | -| DNS récursif | ~systemd-resolvd~ | Oui | -| Gestion des ~$HOME~ | systemd-homed | Oui | -| Montage de disques | ~systemd-fstab-generator~ | Pas à ma connaissance | -| | ~systemd-gpt-auto-generator~ | Oui | -| | ~systemd-fsck-generator~ | Peut-être | -| Chiffrement de disques | ~systemd-cryptsetup~ | Oui | -| | ~systemd-cryptenroll~ | Oui | -| | ~systemd-crypttab-generator~ | | -| Chiffrement de secrets | ~systemd-creds~ | Oui | -| Gestion de l'horloge | ~systemd-timedated~ | Oui | -| | ~systemd-timesyncd~ | Oui | -| Nom d'hôte | ~systemd-hostnamed~ | Je ne sais pas | - -** Critiques communes - -/Cf/. la [[https://www.freedesktop.org/wiki/Software/systemd/FrequentlyAskedQuestions/][FAQ officielle]] du projet. - -- /Il est dit que ~sd~ fait trop de choses/ ! - Ah bon ? Pourtant, ~systemd~ n'apparait pas si souvent dans le tableau ci-dessus. - -- /Il est dit que ~sd~ est une dictature/ ! - - Je ne contribue pas, mais suis les messages postés sur les mailing list et - parfois les issues du GitHub. Je trouve la communauté très accueillante. - - -** Évolution de ~systemd~ - -~systemd~ évolue rapidement, pour permettre une gestion toujours plus fine des -services, VMs, ... Certaines mises à jour de ~systemd~ retirent des -fonctionnalités (/e.g./ ~/usr~ séparé ou ~cgroupsv1~). Lorsqu'il y a retrait d'une -fonctionnalité, cela est au annoncé à l'avance, pour que chacun·e ait le temps -de s'y préparer. Pour les deux exemples susmentionnés, cela a été annoncé plus -d'un an à l'avance. - - -* Rappel : processus de démarrage d'un ordinateur /systemd/GNU/Linux/ - -Ce paragraphe présente la manière dont les machines démarrent. Cette -présentation se veut rapide, mais suffisante pour que chacun·e puisse comprendre -à quelle étape de ce processus les disques d'un ordinateur sont déchiffrés, -montés, /etc./ - -/Note/ : Je me concentrerai que sur les systèmes (U)EFI utilisant une table de -partitions ~gpt~ (/i.e./ le disque sur lequel se trouvent les fichiers de démarrage -contient un partitionnement ~gpt~). - -Procédé de démarrage : - -1. le logiciel de la carte mère est le premier élément à démarrer. Il charge - vos paramètres (/e.g./ secure boot activé ou non) ; - -2. le logiciel cherche à démarrer ou bien votre système d'exploitation - directement, ou bien un /système d'amorçage/ (/bootloader/ en, anglais) ; - -3. supposons qu'il lance ~systemd-boot~. - ~systemd-boot~ va constituer un menu avec - - une ou plusieurs entrées pour lancer le(s) système(s) d'exploitation - disponible(s) sur votre machine (ou en réseau), - - une entrée pour redémarrer dans le panneau de configuration du logiciel - UEFI, - - une entrée pour redémarrer ; - -4. Supposons que l'utilisateurice (ou ~systemd-boot~) choisisse un système sous - ~systemd~. - ~systemd~, qui est actuellement lancé dans un petit environnement (appelé - /initrd/) va chercher à initialiser le système, noramment en : - 1. déchiffrant la partition racine du système (si nécessaire), - 2. montant la partition racine du sysème, - 3. pivotant sur le système final dont ~systemd~ vient de monter ~/~. - -5. Nous sommes sur la bonne voie : le système de fichier principal est monté. - ~systemd~ monte les partitions/disques/resources réseaux supplémentaires - requis, met en place les sous-systèmes nécessaires (journalisation, réseau, - ...). - - L'un des derniers services démarré permet aux utilisateurices de - s'authentifier. Le sysème a fini de démarrer. - - -* TODO Configuration - -** TODO Unité de configuration (~man systemd.unit~) - -** TODO Service (~man systemd.service~) - -** TODO Cibles (~man systemd.target~) - -** TODO Minuteurs (~man systemd.timer~) - - -* TODO Systemd : aspect pratique - -** TODO Chiffrement (mots de passe, recovery key, FIDO2 ou TMP2) - -L'utilitaire principal pour gérer le chiffrement de disques est -~systemd-cryptenroll~. - -** TODO Reconnaissance automatique de partitions - -Lors de l'installation d'un système d'exploitation (avec UEFI), il y a au moins -deux partitions : -- une ESP (/EFI System Partition/), laquelle stocke les images de démarrage (dont - l'éventuel boot loader) ; -- une partition racine (root, ou ~/~), laquelle correspond au chemin ~/~ pour le - système. C'est ici que sont généralement stockées vos applications, la - configuration système, /etc/. - -Pour ~systemd~, touts les points de montage sont des /unités de montage/ et le -déchiffrement des disques est effectué via des /unités de services/. Ces unités -sont /générées/ (/Cf./ plus bas). - - -Lors du démarrage, il faut mettre le système de fichiers en place, /i.e./ monter -les disques. Lors de l'installation du système d'exploitation, deux choix -s'offrent à vous : -- /OU BIEN/ Décrire les blocks à déchiffrer dans ~/etc/crypttab~ (/crypt table/) et - les points de montage dans ~/etc/fstab~ (/file systems table/). - - Ces fichiers seront inclus dans l'image de démarrage (qui est souvent appellée - /initrd/ ou /initramfs/), afin que ~systemd~ sache quels disques déchiffrer et - monter (et comment). - -- /OU BIEN/ Indiquer le type de chaque partition ("X est ~/~", "Y est ~/boot~", "Z est - ~/home~", /etc./). Si tel est le cas, il n'est plus nécessaire d'inclure les - partitions concernées dans ~/etc/fstab~. - /Note/ : Si vous utilisez LUKS2 pour chiffrer vos disques, il n'est pas non plus - nécessaire d'indiquer ces éléments dans ~/etc/crypttab~. - - /Exemple/ : Partition ~/home~, troisième partition du disque ~/dev/nvme0n1~. - Il suffit : - - de changer le type de partition de ~/dev/nvme0n1p3~ : - #+begin_src fdisk - fdisk /dev/nvme0n1 - - t # change le type de partition - 3 # numéro de la partition à mettre à jour - home # (ou 43) abbréviation pour "933ac7e1-2eb4-4f13-b844-0e14e2aef915" - w # écrit les changements à la table de partitions - #+end_src - - retirer la ligne correspondant à ~/home~ dans ~/etc/fstab~ (et si la partition - est chiffrée, de ~/etc/crypttab~ aussi), - - régénrer les images de démarrage, - - redémarrer et tester. - - /Note/ : se référer à ~man systemd-gpt-auto-generator(8)~ pour une liste complète - des tags ~gpt~ reconnus par ~systemd~. - - -** TODO Redimension automatique de partitions - -** TODO UKI et Secure boot - -* TODO Réseau - -* TODO Journalisation - -* TODO Administration à distance From 593c5092a35be3f6249b68136dc733bb83acd6fc Mon Sep 17 00:00:00 2001 From: bleizi Date: Wed, 11 Sep 2024 10:56:27 +0200 Subject: [PATCH 2/9] Update 2 files - /compte_rendus/2024_08_29.md - /compte_rendus/2024_06_22.md --- compte_rendus/2024_06_22.md | 86 +++++++++++++++++++ compte_rendus/2024_08_29.md | 166 ++++++++++++++++++++++++++++++++++++ 2 files changed, 252 insertions(+) create mode 100644 compte_rendus/2024_06_22.md create mode 100644 compte_rendus/2024_08_29.md diff --git a/compte_rendus/2024_06_22.md b/compte_rendus/2024_06_22.md new file mode 100644 index 0000000..46e42ac --- /dev/null +++ b/compte_rendus/2024_06_22.md @@ -0,0 +1,86 @@ +# Réunion IN + + * Date : Samedi 22 Juin 2024 + * Lieu : MB87 et Galène (https://galene.crans.org/group/CA) + * Début : 14h23 - reprise à 15h20 + * Fin : 16h07 + +## Présent⋅es + +* GaBo +* [Chiaroush](https://wiki.crans.org/WikiChiaroush) +* [vanille](https://wiki.crans.org/VanilleNiven) +* lzebulon +* Otthorn +* [RDB](https://wiki.crans.org/WikiRDB) +* [bleizi](https://wiki.crans.org/WikiBleizi) +* [Aplanos](https://wiki.crans.org/WikiAplanos) + +## Ordre du jour + +* Clé usb d’installation de 128go avec ventoy ou équivalent pour les installations +* commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le faire en live) +* [GaBo] Ansible est trop vieux (drop de support de certain plugin, peut pas relancer les playbooks. Marche encore avec ansible_2_14) +* [Otthorn] ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org pas le bon LDAP, faut utiliser wall-e +* [Otthorn] Action deny sur WikiMoinMoin +* [Lzebulon] Point sur les backups : ne semble pas fonctionner (backup-{thot,ft} non contactable) +* VM Collabora +* [Gabo] Ecriture du guide pour faire des VM dans la documentation +* Owncloud : soucis de LDAP +* Gitlab : à mettre à jour au plus vite (on est en 16.1) + +### Clé USB d'installation 128 go Ventoy + +(En référence à une conversation du 16 Mai 2024) +Une seule clé avec plusieurs ISO plutôt que clés nombreuses avec distros différents -> Problèmes de sécurité, mais intéressant pour les nounous +Le logiciel proposé (Ventoy) est plutôt répandu/réputé mais pas terrible. Problèmes de sécurité entre-autre. +On propose de faire minimaliste sans utiliser le logiciel Ventoy. Ce serait intéressant parce que ça nous épargnerait le trousseau de clés (qui a été perdu il paraît), à discuter au prochain CA. +GaBo propose de partir sur 5 clés de 128 go -> 1 clé / Nounous présentes sur le plateau. +GaBo propose 64 go. 128 go lui paraît overkill. Pas de différence trop grande en terme de prix -> On part sur du 128 go. +En Install Party, on fait rarement plus de 5 installs en parallèle. +(Prendre en compte qu'il y a toujours une clé qui est perdue...) + +Projet apprenti rigolo de créer un script qui génère les clés (mettre tel OS sur une clé). + + +### Commande des disques + +Les disques sont commandés et arrivés ! +Il reste les ventilos. +GaBo a payé avec sa carte, il attend le remboursement de la part du Trésorier (Macéo) pour procéder à l'achat des ventilos. + +Avons-nous prévu un moment pour installer les nouveaux disques ? <- On en a discuté dans le point disques du CA. + + +### Ansible + +On a plein de version de retard (on est en 2.14 et la version actuelle est la 10). +https://endoflife.date/ansible +Il faudrais mette ça à jour : plugin LDAP et README en particulier et peut-être le plugin pass. On eput essayer de faire en même temps que l'install de Colabora + +### WikiMoinMoin + +On a des soucis avec l'action "deny" qui ne permettait de voir une page privée. Otthorn a fait un proof au concept de l'erreur. Il a réactivé deny, c'est bon. Mais on sait pas pourquoi ça avit été désactivé il y a longtemps. + +### Backups + +Faut se bouger pour aller voir VR en vrai à une de leurs permanences. C'est peut-être juste l'ethernet qui est débranchée. (Et potentiellement aussi changer pour un cable qui fonctionne) + +Faire les backups correctement (comme l’a indiqué Otthorn, en excluant les trucs reliés à postgress et utilisé le hook conçu pour) +voir dans la config ansible + +### Colabora + +(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c'est chiant je comprends rien à comment ça fonctionne) + +### Owncloud + +La config a disparu par magie (À enquêter) + +### GitLab + +Il faut mettre à jour. (On le fera vers juste après l’IN) + +### Documentation + +GaBo a été désigné grand gagnant de qui s'occupera de la documentation d'Ansible. \ No newline at end of file diff --git a/compte_rendus/2024_08_29.md b/compte_rendus/2024_08_29.md new file mode 100644 index 0000000..8dcc464 --- /dev/null +++ b/compte_rendus/2024_08_29.md @@ -0,0 +1,166 @@ +# Réunion IN + +* Date : Jeudi 29 Août 2024 +* Lieu : MB87 et Galène (https://galene.crans.org/group/CA) +* Début : 18h58 +* Fin : 21h + +## Présent⋅es + +* [bleizi](https://wiki.crans.org/WikiBleizi) +* [Pigeon Moelleux](https://wiki.crans.org/WikiPigeonMoelleux) +* GaBo +* [vanille](https://wiki.crans.org/VanilleNiven) +* korenst1 +* Lzebulon +* Shinigami +* [Hachino](https://wiki.crans.org/WikiHachino) +* underscore_j +* RDB +* Otthorn + +## Ordre du jour + +### Rapide compte-rendu de ce qu'il s'est passé cet été +Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de mauvaises configurations +problème entre ansible et les scripts qui sont dépréciés. + +Mise à jour de gitlab + +Au milieu de l'été. pb entre owncloud et nextcloud. impossibilité d'écrire (indépendant du reste). esum a résolu le pb. Owncloud a ensuite perdu sa conf ldap. +Nextcloud a fini d'être configuré (paramêtre de partage et les mails (envoi de mail automatique pour les événements)). Nextcloud marche bien. +Pub pour nextcloud possible. + +pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé dans apt. Pas possible d'installer onlyoffice comme ça. On doit le faire à la main. Donc ce n'est pas ansibelisable. +Il n'est pas possible d'utiliser onlyoffice sur téléphone (firefox) et limité à 20 connexions en même temps. du coup, est-ce qu'on utilise Collabora ou Onlyoffice ? + +Du coup on peut passer sur collabora qui n'a pas ces problèmes. +Sinon Otthorn a trouvé la variable à modifier. + +``` +server/Common/sources/constant.js +exports.LICENSE_CONNECTIONS = 20; +``` + +### état sur les serveurs de backup +2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais il marche et permet de faire +Peut-être la poussière ou les ventilos sont cassés. Bref, il faudra probablement faire qch. +On ne sait pas si l'ilo marche. Mais il est possible de relancer les backups. + +specs du serveurs chez viarezo : https://wiki.crans.org/CransNostalgie/CransTechnique/LesServeurs/ServeurFt + +Pour thot : le serveur s'éteint spontanément après le démarrage. c'est probablement à cause de la sonde de température + +On remet ft puis on réinstalle thot + +Il existe plus simple que borg. Est-ce qu'on ne passerait pas sur truc plus récent. mais on garde borg pour le moment. Sinon on peut utiliser restic. + +On s'assure que ft remarche avant de faire thot (moins urgent) + +Pigeon : "IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP" + +Tealc : on n'arrive pas à ajouter les disques donc pk on y arriverait avec thot ? + + + +Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu de membre actif chez eux. + +Chez Tuxae ? -> c'est possible on a l'accord du président. + +Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer pour récupérer les données. + +ft urgent et une fois fonctionnel, on commence sur thot. On peut aussi chiffrer les disques nativement avec zfs. + +### Cephiroth +Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux). + +### Serveur matrix +De plus en plus de demande pour avoir une alternative libre à discord, whatsapp.... + + +Mastodon -> pas adapté +Zulipe -> pas adapté +Mattermost -> pas adapté +Matrix -> faire de la pédagogie. Pas le temps de faire le support technique ? Il est possible de faire des vocaux. Il faut présenter ça aux gens mais iels auront besoin d'une passphrase et ou une clef de récupération. + +Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais est-ce que le serveur est possible de gérer plus de connexions. +En principal, obligation de mettre le ldap du crans. Possibilité d'utiliser la note via Oauth... +Les alias ça change. On doit conserver le pk. Potentiellement, on peut ajouter un préfix (genre "note_"). + +Ou alors, 2 instances de matrix, une pour chaque ldap. L'une est au bde mais le crans s'en occupe. +Migrer SQLite à PostgreSQL. +Si on migre le bde, il faut que se soit très stable. +Est-ce qu'il est possible d'avoir de la redondance sur le serveur matrix ? a priori oui... mais peut-être pas intégrer pas défaut à matrix. +matrix.crans.org juste un relai (bridge irc/matrix) pour la réinstallation, il faut demander à Erdnaxe. + +On garde le serveur matrix tel quel (quitte à augmenter les perfs). migre de SQLite à PostgreSQL. LDAP crans en priorité. +On met element +chat.crans.org (facile à retenir) +FAIRE DE LA PUB ! + +5 secondes sur Mastodon selon pigeon (c'est (déjà) perdu) mais moi je pense que la vérité est toute autre... +Retirer la condition "cephirot.date < mastodon.date". +Ajouter l'affirmation "Constellation.state == Cephiroth.state" + +### Reprise des séminaires hebdomadaires + +On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire ce point moulte années plutard !)) + +### état de l'imprimante + +bref : ça marche pas + +L'imprimante a été déplacée mais impossible de communiquer avec l'imprimante. +Il faudra se poser avec des personnes de la DSI pour résoudre le pb. Mais dire ce qu'on a fait, il est possible que ça avance. +pigeon pense pouvoir s'en charger mais il ne connait pas ce qu'il y a autour de l'imprimante. + +On essaie de s'en occuper assez rapidement (bleizi et pigeonmoelleux) + +### mettre les clés gpg dans le pass +pb de rétention des clefs gpg. pigeon a "pillé" à bleizi les clefs. +potentiellement signer les clefs gpg des nounous. + +Remettre de l'ordre dans le pass. thot renommé en surface sans raison (a priori). + +Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou autre... +Sinon, demander aux vielles nounous (peb, pollion) si iels veulent garder leurs droits nounous (ça ressemble à une invitation à partir...). +Pour les autres, on propose de rajouter les clefs gpg dans le pass. + +== Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin == +Près de 400 jours qu'il tourne. (pas de coupure estivale). +Pas possible de la faire avant les prochaines vacances. En profiter pour refaire le cablage. +Une réunion de préparation de la réparation. +(redémarrage et brassage)-> prochain IN + +### Chronolgie TODO list + +Très urgent : + - Backup ft (commencé à faire les backup) + - 1/2 qui non important (genre voyager et helloworld) + - par ordre d'importance (genre mailman) + - d'ici là samedi rangement, inté, séminaires + - Cephiroth (garantie go GaBo) + - puis on s'occupe de thot + +on est déjà dans qq semaines : + - onlyoffice (la limite) + - bleizi, pigeon -> imprimante + - les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent rester nounous) + - enlever les vielles nounous (charlie, peb ? et pollion ?) + +Le mois prochain : + - prévénir tout le monde que les serveurs du crans sont down + - Backup tealc sur zéphir/cameron + - inventaire et commander des disques d'avances (un disque en rab compatible pour chacun des serveurs) + - coupure : recabler, (vérifier l'étiqueteuse) + - PASSER LA POOL EN 4096 + - réinstaller tealc + +Après : + - voir matrix + - rediscuter de mastodon + - Nix + +Jamais : + - Constellation + - Ceph \ No newline at end of file From eadaa4926b6dc3c89d47969ddf3e40e9449130ef Mon Sep 17 00:00:00 2001 From: bleizi Date: Wed, 11 Sep 2024 10:57:18 +0200 Subject: [PATCH 3/9] Update 2024_08_29.md --- compte_rendus/2024_08_29.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/compte_rendus/2024_08_29.md b/compte_rendus/2024_08_29.md index 8dcc464..8832f1f 100644 --- a/compte_rendus/2024_08_29.md +++ b/compte_rendus/2024_08_29.md @@ -126,7 +126,7 @@ Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou autre... Sinon, demander aux vielles nounous (peb, pollion) si iels veulent garder leurs droits nounous (ça ressemble à une invitation à partir...). Pour les autres, on propose de rajouter les clefs gpg dans le pass. -== Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin == +### Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin Près de 400 jours qu'il tourne. (pas de coupure estivale). Pas possible de la faire avant les prochaines vacances. En profiter pour refaire le cablage. Une réunion de préparation de la réparation. From d1eaad0535dac31ce9d3f71364705c7099dd7c2d Mon Sep 17 00:00:00 2001 From: RatCornu Date: Thu, 10 Oct 2024 19:28:24 +0200 Subject: [PATCH 4/9] fix: lint --- compte_rendus/2024_06_22.md | 77 +++++++++++------ compte_rendus/2024_08_29.md | 159 +++++++++++++++++++++++------------- howto/creer_vm_crans.md | 4 +- outils/logiciels/systemd.md | 7 -- 4 files changed, 155 insertions(+), 92 deletions(-) diff --git a/compte_rendus/2024_06_22.md b/compte_rendus/2024_06_22.md index 46e42ac..85301d8 100644 --- a/compte_rendus/2024_06_22.md +++ b/compte_rendus/2024_06_22.md @@ -1,9 +1,9 @@ # Réunion IN - * Date : Samedi 22 Juin 2024 - * Lieu : MB87 et Galène (https://galene.crans.org/group/CA) - * Début : 14h23 - reprise à 15h20 - * Fin : 16h07 +* Date : Samedi 22 Juin 2024 +* Lieu : MB87 et Galène +* Début : 14h23 - reprise à 15h20 +* Fin : 16h07 ## Présent⋅es @@ -18,12 +18,17 @@ ## Ordre du jour -* Clé usb d’installation de 128go avec ventoy ou équivalent pour les installations -* commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le faire en live) -* [GaBo] Ansible est trop vieux (drop de support de certain plugin, peut pas relancer les playbooks. Marche encore avec ansible_2_14) -* [Otthorn] ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org pas le bon LDAP, faut utiliser wall-e +* Clé usb d’installation de 128go avec ventoy ou équivalent pour les + installations +* commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le faire en + live) +* [GaBo] Ansible est trop vieux (drop de support de certain plugin, peut pas + relancer les playbooks. Marche encore avec ansible_2_14) +* [Otthorn] ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org pas le bon + LDAP, faut utiliser wall-e * [Otthorn] Action deny sur WikiMoinMoin -* [Lzebulon] Point sur les backups : ne semble pas fonctionner (backup-{thot,ft} non contactable) +* [Lzebulon] Point sur les backups : ne semble pas fonctionner + (backup-{thot,ft} non contactable) * VM Collabora * [Gabo] Ecriture du guide pour faire des VM dans la documentation * Owncloud : soucis de LDAP @@ -32,46 +37,63 @@ ### Clé USB d'installation 128 go Ventoy (En référence à une conversation du 16 Mai 2024) -Une seule clé avec plusieurs ISO plutôt que clés nombreuses avec distros différents -> Problèmes de sécurité, mais intéressant pour les nounous -Le logiciel proposé (Ventoy) est plutôt répandu/réputé mais pas terrible. Problèmes de sécurité entre-autre. -On propose de faire minimaliste sans utiliser le logiciel Ventoy. Ce serait intéressant parce que ça nous épargnerait le trousseau de clés (qui a été perdu il paraît), à discuter au prochain CA. -GaBo propose de partir sur 5 clés de 128 go -> 1 clé / Nounous présentes sur le plateau. -GaBo propose 64 go. 128 go lui paraît overkill. Pas de différence trop grande en terme de prix -> On part sur du 128 go. +Une seule clé avec plusieurs ISO plutôt que clés nombreuses avec distros +différents -> Problèmes de sécurité, mais intéressant pour les nounous +Le logiciel proposé (Ventoy) est plutôt répandu/réputé mais pas terrible. +Problèmes de sécurité entre-autre. +On propose de faire minimaliste sans utiliser le logiciel Ventoy. Ce serait +intéressant parce que ça nous épargnerait le trousseau de clés (qui a été +perdu il paraît), à discuter au prochain CA. +GaBo propose de partir sur 5 clés de 128 go -> 1 clé / Nounous présentes sur +le plateau. +GaBo propose 64 go. 128 go lui paraît overkill. Pas de différence trop grande +en terme de prix -> On part sur du 128 go. En Install Party, on fait rarement plus de 5 installs en parallèle. (Prendre en compte qu'il y a toujours une clé qui est perdue...) -Projet apprenti rigolo de créer un script qui génère les clés (mettre tel OS sur une clé). - +Projet apprenti rigolo de créer un script qui génère les clés (mettre tel +OS sur une clé). ### Commande des disques Les disques sont commandés et arrivés ! Il reste les ventilos. -GaBo a payé avec sa carte, il attend le remboursement de la part du Trésorier (Macéo) pour procéder à l'achat des ventilos. - -Avons-nous prévu un moment pour installer les nouveaux disques ? <- On en a discuté dans le point disques du CA. +GaBo a payé avec sa carte, il attend le remboursement de la part du Trésorier +(Macéo) pour procéder à l'achat des ventilos. +Avons-nous prévu un moment pour installer les nouveaux disques ? <- On en a +discuté dans le point disques du CA. ### Ansible -On a plein de version de retard (on est en 2.14 et la version actuelle est la 10). -https://endoflife.date/ansible -Il faudrais mette ça à jour : plugin LDAP et README en particulier et peut-être le plugin pass. On eput essayer de faire en même temps que l'install de Colabora +On a plein de version de retard (on est en 2.14 et la version actuelle est la +10). + +Il faudrais mette ça à jour : plugin LDAP et README en particulier et +peut-être le plugin pass. On eput essayer de faire en même temps que +l'install de Colabora ### WikiMoinMoin -On a des soucis avec l'action "deny" qui ne permettait de voir une page privée. Otthorn a fait un proof au concept de l'erreur. Il a réactivé deny, c'est bon. Mais on sait pas pourquoi ça avit été désactivé il y a longtemps. +On a des soucis avec l'action "deny" qui ne permettait de voir une page +privée. Otthorn a fait un proof au concept de l'erreur. Il a réactivé deny, +c'est bon. Mais on sait pas pourquoi ça avit été désactivé il y a +longtemps. ### Backups -Faut se bouger pour aller voir VR en vrai à une de leurs permanences. C'est peut-être juste l'ethernet qui est débranchée. (Et potentiellement aussi changer pour un cable qui fonctionne) +Faut se bouger pour aller voir VR en vrai à une de leurs permanences. C'est +peut-être juste l'ethernet qui est débranchée. (Et potentiellement aussi +changer pour un cable qui fonctionne) -Faire les backups correctement (comme l’a indiqué Otthorn, en excluant les trucs reliés à postgress et utilisé le hook conçu pour) +Faire les backups correctement (comme l’a indiqué Otthorn, en excluant les +trucs reliés à postgress et utilisé le hook conçu pour) voir dans la config ansible ### Colabora -(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c'est chiant je comprends rien à comment ça fonctionne) +(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c'est +chiant je comprends rien à comment ça fonctionne) ### Owncloud @@ -83,4 +105,5 @@ Il faut mettre à jour. (On le fera vers juste après l’IN) ### Documentation -GaBo a été désigné grand gagnant de qui s'occupera de la documentation d'Ansible. \ No newline at end of file +GaBo a été désigné grand gagnant de qui s'occupera de la documentation +d'Ansible. diff --git a/compte_rendus/2024_08_29.md b/compte_rendus/2024_08_29.md index 8832f1f..3bfb3d6 100644 --- a/compte_rendus/2024_08_29.md +++ b/compte_rendus/2024_08_29.md @@ -1,7 +1,7 @@ # Réunion IN * Date : Jeudi 29 Août 2024 -* Lieu : MB87 et Galène (https://galene.crans.org/group/CA) +* Lieu : MB87 et Galène * Début : 18h58 * Fin : 21h @@ -22,145 +22,190 @@ ## Ordre du jour ### Rapide compte-rendu de ce qu'il s'est passé cet été -Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de mauvaises configurations -problème entre ansible et les scripts qui sont dépréciés. + +Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de +mauvaises configurations problème entre ansible et les scripts qui sont +dépréciés. Mise à jour de gitlab -Au milieu de l'été. pb entre owncloud et nextcloud. impossibilité d'écrire (indépendant du reste). esum a résolu le pb. Owncloud a ensuite perdu sa conf ldap. -Nextcloud a fini d'être configuré (paramêtre de partage et les mails (envoi de mail automatique pour les événements)). Nextcloud marche bien. +Au milieu de l'été. pb entre owncloud et nextcloud. impossibilité d'écrire +(indépendant du reste). esum a résolu le pb. Owncloud a ensuite perdu sa conf +ldap. +Nextcloud a fini d'être configuré (paramêtre de partage et les mails (envoi +de mail automatique pour les événements)). Nextcloud marche bien. Pub pour nextcloud possible. -pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé dans apt. Pas possible d'installer onlyoffice comme ça. On doit le faire à la main. Donc ce n'est pas ansibelisable. -Il n'est pas possible d'utiliser onlyoffice sur téléphone (firefox) et limité à 20 connexions en même temps. du coup, est-ce qu'on utilise Collabora ou Onlyoffice ? +pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé dans apt. +Pas possible d'installer onlyoffice comme ça. On doit le faire à la main. +Donc ce n'est pas ansibelisable. +Il n'est pas possible d'utiliser onlyoffice sur téléphone (firefox) et +limité à 20 connexions en même temps. du coup, est-ce qu'on utilise +Collabora ou Onlyoffice ? Du coup on peut passer sur collabora qui n'a pas ces problèmes. Sinon Otthorn a trouvé la variable à modifier. -``` +```txt server/Common/sources/constant.js exports.LICENSE_CONNECTIONS = 20; ``` ### état sur les serveurs de backup -2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais il marche et permet de faire -Peut-être la poussière ou les ventilos sont cassés. Bref, il faudra probablement faire qch. + +2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais il marche +et permet de faire +Peut-être la poussière ou les ventilos sont cassés. Bref, il faudra +probablement faire qch. On ne sait pas si l'ilo marche. Mais il est possible de relancer les backups. -specs du serveurs chez viarezo : https://wiki.crans.org/CransNostalgie/CransTechnique/LesServeurs/ServeurFt +specs du serveurs chez viarezo : + -Pour thot : le serveur s'éteint spontanément après le démarrage. c'est probablement à cause de la sonde de température +Pour thot : le serveur s'éteint spontanément après le démarrage. c'est +probablement à cause de la sonde de température On remet ft puis on réinstalle thot -Il existe plus simple que borg. Est-ce qu'on ne passerait pas sur truc plus récent. mais on garde borg pour le moment. Sinon on peut utiliser restic. +Il existe plus simple que borg. Est-ce qu'on ne passerait pas sur truc plus +récent. mais on garde borg pour le moment. Sinon on peut utiliser restic. On s'assure que ft remarche avant de faire thot (moins urgent) Pigeon : "IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP" -Tealc : on n'arrive pas à ajouter les disques donc pk on y arriverait avec thot ? +Tealc : on n'arrive pas à ajouter les disques donc pk on y arriverait avec +thot ? - - -Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu de membre actif chez eux. +Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu de membre +actif chez eux. Chez Tuxae ? -> c'est possible on a l'accord du président. -Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer pour récupérer les données. +Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer pour +récupérer les données. -ft urgent et une fois fonctionnel, on commence sur thot. On peut aussi chiffrer les disques nativement avec zfs. +ft urgent et une fois fonctionnel, on commence sur thot. On peut aussi chiffrer +les disques nativement avec zfs. ### Cephiroth + Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux). ### Serveur matrix -De plus en plus de demande pour avoir une alternative libre à discord, whatsapp.... +De plus en plus de demande pour avoir une alternative libre à discord, +whatsapp.... Mastodon -> pas adapté Zulipe -> pas adapté Mattermost -> pas adapté -Matrix -> faire de la pédagogie. Pas le temps de faire le support technique ? Il est possible de faire des vocaux. Il faut présenter ça aux gens mais iels auront besoin d'une passphrase et ou une clef de récupération. +Matrix -> faire de la pédagogie. Pas le temps de faire le support technique ? +Il est possible de faire des vocaux. Il faut présenter ça aux gens mais iels +auront besoin d'une passphrase et ou une clef de récupération. -Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais est-ce que le serveur est possible de gérer plus de connexions. -En principal, obligation de mettre le ldap du crans. Possibilité d'utiliser la note via Oauth... -Les alias ça change. On doit conserver le pk. Potentiellement, on peut ajouter un préfix (genre "note_"). +Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais est-ce que +le serveur est possible de gérer plus de connexions. +En principal, obligation de mettre le ldap du crans. Possibilité d'utiliser la +note via Oauth... +Les alias ça change. On doit conserver le pk. Potentiellement, on peut ajouter +un préfix (genre "note_"). -Ou alors, 2 instances de matrix, une pour chaque ldap. L'une est au bde mais le crans s'en occupe. +Ou alors, 2 instances de matrix, une pour chaque ldap. L'une est au bde mais le +crans s'en occupe. Migrer SQLite à PostgreSQL. Si on migre le bde, il faut que se soit très stable. -Est-ce qu'il est possible d'avoir de la redondance sur le serveur matrix ? a priori oui... mais peut-être pas intégrer pas défaut à matrix. -matrix.crans.org juste un relai (bridge irc/matrix) pour la réinstallation, il faut demander à Erdnaxe. +Est-ce qu'il est possible d'avoir de la redondance sur le serveur matrix ? a +priori oui... mais peut-être pas intégrer pas défaut à matrix. +matrix.crans.org juste un relai (bridge irc/matrix) pour la réinstallation, il +faut demander à Erdnaxe. -On garde le serveur matrix tel quel (quitte à augmenter les perfs). migre de SQLite à PostgreSQL. LDAP crans en priorité. +On garde le serveur matrix tel quel (quitte à augmenter les perfs). migre de +SQLite à PostgreSQL. LDAP crans en priorité. On met element chat.crans.org (facile à retenir) FAIRE DE LA PUB ! -5 secondes sur Mastodon selon pigeon (c'est (déjà) perdu) mais moi je pense que la vérité est toute autre... +5 secondes sur Mastodon selon pigeon (c'est (déjà) perdu) mais moi je pense +que la vérité est toute autre... Retirer la condition "cephirot.date < mastodon.date". Ajouter l'affirmation "Constellation.state == Cephiroth.state" ### Reprise des séminaires hebdomadaires -On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire ce point moulte années plutard !)) +On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire ce +point moulte années plutard !)) ### état de l'imprimante bref : ça marche pas -L'imprimante a été déplacée mais impossible de communiquer avec l'imprimante. -Il faudra se poser avec des personnes de la DSI pour résoudre le pb. Mais dire ce qu'on a fait, il est possible que ça avance. -pigeon pense pouvoir s'en charger mais il ne connait pas ce qu'il y a autour de l'imprimante. +L'imprimante a été déplacée mais impossible de communiquer avec +l'imprimante. +Il faudra se poser avec des personnes de la DSI pour résoudre le pb. Mais dire +ce qu'on a fait, il est possible que ça avance. +pigeon pense pouvoir s'en charger mais il ne connait pas ce qu'il y a autour de +l'imprimante. On essaie de s'en occuper assez rapidement (bleizi et pigeonmoelleux) ### mettre les clés gpg dans le pass + pb de rétention des clefs gpg. pigeon a "pillé" à bleizi les clefs. potentiellement signer les clefs gpg des nounous. -Remettre de l'ordre dans le pass. thot renommé en surface sans raison (a priori). +Remettre de l'ordre dans le pass. thot renommé en surface sans raison (a +priori). Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou autre... -Sinon, demander aux vielles nounous (peb, pollion) si iels veulent garder leurs droits nounous (ça ressemble à une invitation à partir...). +Sinon, demander aux vielles nounous (peb, pollion) si iels veulent garder leurs +droits nounous (ça ressemble à une invitation à partir...). Pour les autres, on propose de rajouter les clefs gpg dans le pass. ### Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin + Près de 400 jours qu'il tourne. (pas de coupure estivale). -Pas possible de la faire avant les prochaines vacances. En profiter pour refaire le cablage. +Pas possible de la faire avant les prochaines vacances. En profiter pour +refaire le cablage. Une réunion de préparation de la réparation. (redémarrage et brassage)-> prochain IN ### Chronolgie TODO list Très urgent : - - Backup ft (commencé à faire les backup) - - 1/2 qui non important (genre voyager et helloworld) - - par ordre d'importance (genre mailman) - - d'ici là samedi rangement, inté, séminaires - - Cephiroth (garantie go GaBo) - - puis on s'occupe de thot + +* Backup ft (commencé à faire les backup) + * 1/2 qui non important (genre voyager et helloworld) + * par ordre d'importance (genre mailman) +* d'ici là samedi rangement, inté, séminaires +* Cephiroth (garantie go GaBo) +* puis on s'occupe de thot on est déjà dans qq semaines : - - onlyoffice (la limite) - - bleizi, pigeon -> imprimante - - les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent rester nounous) - - enlever les vielles nounous (charlie, peb ? et pollion ?) + +* onlyoffice (la limite) +* bleizi, pigeon -> imprimante +* les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent rester + nounous) +* enlever les vielles nounous (charlie, peb ? et pollion ?) Le mois prochain : - - prévénir tout le monde que les serveurs du crans sont down - - Backup tealc sur zéphir/cameron - - inventaire et commander des disques d'avances (un disque en rab compatible pour chacun des serveurs) - - coupure : recabler, (vérifier l'étiqueteuse) - - PASSER LA POOL EN 4096 - - réinstaller tealc + +* prévénir tout le monde que les serveurs du crans sont down +* Backup tealc sur zéphir/cameron +* inventaire et commander des disques d'avances (un disque en rab compatible + pour chacun des serveurs) +* coupure : recabler, (vérifier l'étiqueteuse) +* PASSER LA POOL EN 4096 +* réinstaller tealc Après : - - voir matrix - - rediscuter de mastodon - - Nix + +* voir matrix +* rediscuter de mastodon +* Nix Jamais : - - Constellation - - Ceph \ No newline at end of file + +* Constellation +* Ceph diff --git a/howto/creer_vm_crans.md b/howto/creer_vm_crans.md index 3b55853..86b73f6 100644 --- a/howto/creer_vm_crans.md +++ b/howto/creer_vm_crans.md @@ -116,7 +116,8 @@ En cas de problème, il est possible de le configurer après installation dans `/etc/network/interfaces`. Nom de domaine pour les machines adm : `adm.crans.org` -```config + +```txt FQDN : `[nom du service].adm.crans.org` ``` @@ -172,6 +173,7 @@ Ensuite, ajoutez un fichier `host_vars/[serveur].adm.crans.org` contenant la configuration réseau (`interfaces`). Enfin, il faut rendre le LDAP accessible à votre machine : + ```bash ssh -L 1636:wall-e.adm.crans.org:636 wall-e.adm.crans.org ``` diff --git a/outils/logiciels/systemd.md b/outils/logiciels/systemd.md index 8ffbe7b..c714f55 100644 --- a/outils/logiciels/systemd.md +++ b/outils/logiciels/systemd.md @@ -9,7 +9,6 @@ lesquelles sont jugées intéressantes pour l'administration système ou pour utilisateurices. Il sera sans doute découpé en plusieurs morceaux s'il devient trop long. - ## Unités de configuration: un format unifiant. ### Services. @@ -18,14 +17,12 @@ trop long. ### (Auto)mount. - ## Configuration Réseau. ### Obtenir des adresses IPs. ### Configuration DNS (récursif). - ## Journalisation. ### Lecture des journaux: les bases. @@ -34,24 +31,20 @@ trop long. ### Partage de journaux entre machines. - ## Aspect pratique (pour utilisateurices) ### Chiffrement de disque. ### Chargeur d'amorçage. - ## Conteneurisation et virtualisation. ### Conteneurisation. ### Virtualisation. - ## Gestion des secrets. - ## Trucs et astuces. ### Systèmes dynamiques: gestion des erreurs dans les services. From 6fcdafbf603e5068724945cbb55dee0bc34c6aa1 Mon Sep 17 00:00:00 2001 From: aeltheos Date: Sun, 27 Oct 2024 18:17:41 +0100 Subject: [PATCH 5/9] arista doc before sleeping --- crans.info | 1325 +++++++++++++++++++ infrastructure/machines/physiques/arista.md | 53 +- 2 files changed, 1377 insertions(+), 1 deletion(-) create mode 100644 crans.info diff --git a/crans.info b/crans.info new file mode 100644 index 0000000..cd02098 --- /dev/null +++ b/crans.info @@ -0,0 +1,1325 @@ +This is crans.info, produced by makeinfo version 7.0.3 from crans.texi. + +Documentation du Cr@ns. + + Normalement, je n’ai oublié personne, mais n’hésitez pas à vous +rajouter si nécessaire (ou retirer des doublons ou dead-names que +j’aurais loupé). + + Copyright © 2021-2024 Arnaud Daby-Seesaram +Copyright © 2023-2024 bleizi +Copyright © 2024 korenstin +Copyright © 2024 Lzebulon +Copyright © 2023-2024 Otthorn +Copyright © 2023-2024 pigeonmoelleux +Copyright © 2023 Michaël Paulon +Copyright © 2024 Neven Villani +Copyright © 2021-2023 shirenn +Copyright © 2021-2022 Emmy D’ANELLO +Copyright © 2021-2022 Benjamin Graillot +Copyright © 2021 Alexandre Iooss +Copyright © 2022 Maxime Bombar + + TODO: information concernant la licence... + + The document was typeset with GNU Texinfo +(https://www.gnu.org/software/texinfo/). + +INFO-DIR-SECTION Le Cr@ns +START-INFO-DIR-ENTRY +* Crans: (crans). Documentation de l’infra du Cr@ns et de nos outils. +END-INFO-DIR-ENTRY + + +File: crans.info, Node: Top, Next: Comptes rendus, Up: (dir) + +Documentation du Cr@ns +********************** + +* Menu: + +* Comptes rendus:: +* How-Tos:: +* CONTRIBUTING:: +* Tools:: +* Index:: + + +File: crans.info, Node: Comptes rendus, Next: How-Tos, Prev: Top, Up: Top + +1 Comptes rendus de réunion +*************************** + +Cette section contient l’ensemble des comptes-rendus des IN. + + Les IN, ou Inter-Nounous, sont les réunions techniques des membres +actifs⋅ves du Crans. Celle-ci sont publiques et sont organisées tous +les mois. Celles-ci sont annoncées sur IRC et sur les ML + et . + + Chaque sous-section est le compte-rendu d’une réunion technique. +Vous pouvez trouver un template de compte-rendu dans sous-section +TEMPLATE (*note CR Template::) si nécessaire. La seule contrainte pour +cette section est le nom des sous-sections. Les comptes-rendus sont +identifiés par la date de la réunion : pour une réunion du JJ/MM/AAAA, +la sous-section devra se nommer ‘AAAA MM JJ’ (et non ‘JJ MM AAAA’ car le +tri par date se fait plus simplement). + +* Menu: + +* CR Template:: +* 2024 01 13:: +* 2024 06 22:: +* 2024 08 29:: + + +File: crans.info, Node: CR Template, Next: 2024 01 13, Up: Comptes rendus + +1.1 Réunion IN +============== + +Date + ... +Lieu(x) + ... +Heure de début + ... +Heure de fin + ... + +Présent·es +---------- + + • Nounou 1 (https://wiki.crans.org/CransNounous) + • Apprentie 1 (https://wiki.crans.org/CransApprentis) + • Apprenti 2 (https://wiki.crans.org/CransApprentis) + • Nounou 2 (https://wiki.crans.org/CransNounous) + • Personne sans page wiki + +Ordre du jour +------------- + + • [Nounou 1] Point 1 + • [Nounou 2] Point 2 + • Sous-point 1 + • Sous-point 2 + • [Apprentie 1] Point 3 + • [Nounou 1] Point 4 + • [Apprenti 2] Point 5 + +1.1.1 Point 1 +------------- + +Détails et résumé des discussions du point 1 + +1.1.2 Point 2 +------------- + +Détails et résumé des discussions du point 2 + +... + + +File: crans.info, Node: 2024 01 13, Next: 2024 06 22, Prev: CR Template, Up: Comptes rendus + +1.2 IN du samedi 13 janvier 2024 +================================ + +Date + Samedi 13 janvier 2024 +Lieu + MB87 et Galène () +Début + 13h32 +Fin + 15h32 + +Présent·es +---------- + + • bleizi (https://wiki.crans.org/WikiBleizi) + • Pigeon Moelleux (https://wiki.crans.org/WikiPigeonMoelleux) + • GaBo + • vanille (https://wiki.crans.org/VanilleNiven) + • Otthorn (https://wiki.crans.org/SolalNathan) + • Hachino (https://wiki.crans.org/WikiHachino) + • esum (https://wiki.crans.org/Esum) + • Korenst1 + • shirenn + • Floflo + • RDB + • lzebulon + • Aplanos (https://wiki.crans.org/WikiAplanos) + • Abidos + +Ordre du Jour +------------- + + • Présentation SRS et fix ‘mailman‘ (spam, SPF, comptes bizarres) + • Point sur les DistUpgrades des VM + • Discussions avec la DSI (imprimante, eduroam, radius dans les + locaux associatifs) + • État de la DGNum (Crans à Ulm) + • Autres remarques diverses + +1.2.1 Guix +---------- + +Le conseil technique s’est prononcé lors d’une séance précédente contre +la mise en place de test Guix et a approuvé uniquement le fait de tester +Nix. Les tests d’intégration Guix de l’infrastructure du Crans sont de +facto une perte de temps et devraient être interrompus. + +1.2.2 Désinscription mailing lists +---------------------------------- + +Un email de plainte a levé des doutes sur le bon fonctionnement du +mécanisme de désinscription de ‘lists.crans.org’. Des tests ont été +réalisés en direct par un membre et ont confirmé que l’échec de la +procédure n’est pas de la faute du Crans. + +1.2.3 SRS +--------- + +‘shirenn’ a présenté la motivation et le fonctionnement de SRS +(https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme) pour nos +redirections de mails. Il a été identifié en direct que cela est lié +directement aux problèmes récents de surabondance d’emails “Successful +Mail Delivery Report” sur lorsqu’un accusé de réception +est demandé. + + Étant donné l’importance de ne pas perdre d’emails et la relative +fragilité du système il est décidé de ne pas immédiatement supprimer ces +reports, mais lorsque nous serons plus certains de la robustesse de SRS +nous envisagerons de retirer ‘root’ des récipients. + +1.2.4 Mailman +------------- + +Nous observons des mails acceptés qui ne sont visiblement pas conformes +à la whitelist mise en place. L’abondance de problèmes avec mailman en +général nous mène à envisager la migration à sympa +(https://www.sympa.community/). + + Cela pourra faire l’objet d’un projet apprentis, pour lequel +lzebulon, RDB, Korenst1 et GaBo se disent motivés. + +1.2.5 DU (distrib upgrade) +-------------------------- + +Tout casse à chaque fois qu’on DU un serveur. On va passer soon^{TM} +sur NixOS. + +1.2.6 DSI: eduroam +------------------ + +La DSI a accepté de mettre à jour une pratique obsolète concernant la +connexion au wifi eduroam dans l’enceinte de l’ENS Paris-Saclay qui +empêchait auparavant la connexion aux élèves de l’ENSAE. L’accès est +rétabli. + +1.2.7 DSI: wifi Crans +--------------------- + +Pascal – membre de la DSI de l’ENS Paris-Saclay – est maintenant un +contact du Crans. Cela nous donne l’opportunité de ressusciter le +projet de wifi Crans dans l’ENS, sans toutefois être une priorité. + + Il sera important de contacter Aurore au préalable pour distuter du +volume que l’association peut gérer. + + Sur le plan technique, OpenRadius est envisagé. + + +File: crans.info, Node: 2024 06 22, Next: 2024 08 29, Prev: 2024 01 13, Up: Comptes rendus + +1.3 IN du samedi 22 juin 2024 +============================= + +Date + Samedi 22 juin 2024 +Lieu + MB87 et Galène () +Début + 14h23 — reprise à 15h20 +Fin + 16h07 + +Présent·es +---------- + + • GaBo + • Chiaroush (https://wiki.crans.org/WikiChiaroush) + • vanille (https://wiki.crans.org/VanilleNiven) + • lzebulon + • Otthorn + • RDB (https://wiki.crans.org/WikiRDB) + • bleizi (https://wiki.crans.org/WikiBleizi) + • Aplanos (https://wiki.crans.org/WikiAplanos) + +Ordre du jour +------------- + + • Clé usb d’installation de 128go avec ventoy ou équivalent pour les + installations + • commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le + faire en live) + • [GaBo] Ansible est trop vieux (drop de support de certain plugin, + peut pas relancer les playbooks. Marche encore avec ansible_2_14) + • [Otthorn] ‘ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org’ + pas le bon LDAP, faut utiliser wall-e + • [Otthorn] Action deny sur WikiMoinMoin + • [Lzebulon] Point sur les backups : ne semble pas fonctionner + (backup-{thot,ft} non contactable) + • VM Collabora + • [Gabo] Ecriture du guide pour faire des VM dans la documentation + • Owncloud : soucis de LDAP + • Gitlab : à mettre à jour au plus vite (on est en 16.1) + +1.3.1 Clé USB d’installation 128 go Ventoy +------------------------------------------ + +(En référence à une conversation du 16 Mai 2024) Une seule clé avec +plusieurs ISO plutôt que clés nombreuses avec distros différents -> +Problèmes de sécurité, mais intéressant pour les nounous Le logiciel +proposé (Ventoy) est plutôt répandu/réputé mais pas terrible. Problèmes +de sécurité entre-autre. On propose de faire minimaliste sans utiliser +le logiciel Ventoy. Ce serait intéressant parce que ça nous épargnerait +le trousseau de clés (qui a été perdu il paraît), à discuter au prochain +CA. GaBo propose de partir sur 5 clés de 128 go -> 1 clé / Nounous +présentes sur le plateau. GaBo propose 64 go. 128 go lui paraît +overkill. Pas de différence trop grande en terme de prix -> On part sur +du 128 go. En Install Party, on fait rarement plus de 5 installs en +parallèle. (Prendre en compte qu’il y a toujours une clé qui est +perdue...) + + Projet apprenti rigolo de créer un script qui génère les clés (mettre +tel OS sur une clé). + +1.3.2 Commande des disques +-------------------------- + +Les disques sont commandés et arrivés ! Il reste les ventilos. GaBo a +payé avec sa carte, il attend le remboursement de la part du Trésorier +(Macéo) pour procéder à l’achat des ventilos. + + Avons-nous prévu un moment pour installer les nouveaux disques ? <- +On en a discuté dans le point disques du CA. + +1.3.3 Ansible +------------- + +On a plein de version de retard (on est en 2.14 et la version actuelle +est la 10). Il faudrais mette ça à +jour : plugin LDAP et README en particulier et peut-être le plugin pass. +On eput essayer de faire en même temps que l’install de Colabora + +1.3.4 WikiMoinMoin +------------------ + +On a des soucis avec l’action "deny" qui ne permettait de voir une page +privée. Otthorn a fait un proof au concept de l’erreur. Il a réactivé +deny, c’est bon. Mais on sait pas pourquoi ça avit été désactivé il y a +longtemps. + +1.3.5 Backups +------------- + +Faut se bouger pour aller voir VR en vrai à une de leurs permanences. +C’est peut-être juste l’ethernet qui est débranchée. (Et +potentiellement aussi changer pour un cable qui fonctionne) + + Faire les backups correctement (comme l’a indiqué Otthorn, en +excluant les trucs reliés à postgress et utilisé le hook conçu pour) +voir dans la config ansible + +1.3.6 Colabora +-------------- + +(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c’est +chiant je comprends rien à comment ça fonctionne) + +1.3.7 Owncloud +-------------- + +La config a disparu par magie (À enquêter) + +1.3.8 GitLab +------------ + +Il faut mettre à jour. (On le fera vers juste après l’IN) + +1.3.9 Documentation +------------------- + +GaBo a été désigné grand gagnant de qui s’occupera de la documentation +d’Ansible. + + +File: crans.info, Node: 2024 08 29, Prev: 2024 06 22, Up: Comptes rendus + +1.4 IN du jeudi 29 août 2024 +============================ + +Date + jeudi 29 août 2024 +Lieu + MB87 et Galène () +Début + 18h58 +Fin + 21h + +Présent·es +---------- + + • bleizi (https://wiki.crans.org/WikiBleizi) + • Pigeon Moelleux (https://wiki.crans.org/WikiPigeonMoelleux) + • GaBo + • vanille (https://wiki.crans.org/VanilleNiven) + • korenst1 + • Lzebulon + • Shinigami + • Hachino (https://wiki.crans.org/WikiHachino) + • underscore_j + • RDB + • Otthorn + +Ordre du jour +------------- + +1.4.1 Rapide compte-rendu de ce qu’il s’est passé cet été +--------------------------------------------------------- + +Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de +mauvaises configurations problème entre ansible et les scripts qui sont +dépréciés. + + Mise à jour de gitlab + + Au milieu de l’été. pb entre owncloud et nextcloud. impossibilité +d’écrire (indépendant du reste). esum a résolu le pb. Owncloud a +ensuite perdu sa conf ldap. Nextcloud a fini d’être configuré +(paramêtre de partage et les mails (envoi de mail automatique pour les +événements)). Nextcloud marche bien. Pub pour nextcloud possible. + + pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé +dans apt. Pas possible d’installer onlyoffice comme ça. On doit le +faire à la main. Donc ce n’est pas ansibelisable. Il n’est pas +possible d’utiliser onlyoffice sur téléphone (firefox) et limité à 20 +connexions en même temps. du coup, est-ce qu’on utilise Collabora ou +Onlyoffice ? + + Du coup on peut passer sur collabora qui n’a pas ces problèmes. +Sinon Otthorn a trouvé la variable à modifier. + +server/Common/sources/constant.js +exports.LICENSE_CONNECTIONS = 20; + +1.4.2 état sur les serveurs de backup +------------------------------------- + +2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais +il marche et permet de faire Peut-être la poussière ou les ventilos sont +cassés. Bref, il faudra probablement faire qch. On ne sait pas si +l’ilo marche. Mais il est possible de relancer les backups. + + specs du serveurs chez viarezo : + + + Pour thot : le serveur s’éteint spontanément après le démarrage. +c’est probablement à cause de la sonde de température + + On remet ft puis on réinstalle thot + + Il existe plus simple que borg. Est-ce qu’on ne passerait pas sur +truc plus récent. mais on garde borg pour le moment. Sinon on peut +utiliser restic. + + On s’assure que ft remarche avant de faire thot (moins urgent) + + Pigeon: “IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP” + + Tealc : on n’arrive pas à ajouter les disques donc pk on y arriverait +avec thot ? + + Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu +de membre actif chez eux. + + Chez Tuxae ? -> c’est possible on a l’accord du président. + + Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer +pour récupérer les données. + + ft urgent et une fois fonctionnel, on commence sur thot. On peut +aussi chiffrer les disques nativement avec zfs. + +1.4.3 Cephiroth +--------------- + +Le point ne bouge toujours pas. GaBo cherche la facture (c’est faux). + +1.4.4 Serveur matrix +-------------------- + +De plus en plus de demande pour avoir une alternative libre à discord, +whatsapp... + + Mastodon -> pas adapté Zulipe -> pas adapté Mattermost -> pas adapté +Matrix -> faire de la pédagogie. Pas le temps de faire le support +technique ? Il est possible de faire des vocaux. Il faut présenter ça +aux gens mais iels auront besoin d’une passphrase et ou une clef de +récupération. + + Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais +est-ce que le serveur est possible de gérer plus de connexions. En +principal, obligation de mettre le ldap du crans. Possibilité +d’utiliser la note via Oauth... Les alias ça change. On doit conserver +le pk. Potentiellement, on peut ajouter un préfix (genre "note_"). + + Ou alors, 2 instances de matrix, une pour chaque ldap. L’une est au +bde mais le crans s’en occupe. Migrer SQLite à PostgreSQL. Si on migre +le bde, il faut que se soit très stable. Est-ce qu’il est possible +d’avoir de la redondance sur le serveur matrix ? a priori oui... mais +peut-être pas intégrer pas défaut à matrix. matrix.crans.org juste un +relai (bridge irc/matrix) pour la réinstallation, il faut demander à +Erdnaxe. + + On garde le serveur matrix tel quel (quitte à augmenter les perfs). +migre de SQLite à PostgreSQL. LDAP crans en priorité. On met element +chat.crans.org (facile à retenir) FAIRE DE LA PUB ! + + 5 secondes sur Mastodon selon pigeon (c’est (déjà) perdu) mais moi je +pense que la vérité est toute autre... Retirer la condition +"cephirot.date < mastodon.date". Ajouter l’affirmation +"Constellation.state == Cephiroth.state" + +1.4.5 Reprise des séminaires hebdomadaires +------------------------------------------ + +On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire +ce point moulte années plutard !)) + +1.4.6 état de l’imprimante +-------------------------- + +bref : ça marche pas + + L’imprimante a été déplacée mais impossible de communiquer avec +l’imprimante. Il faudra se poser avec des personnes de la DSI pour +résoudre le pb. Mais dire ce qu’on a fait, il est possible que ça +avance. pigeon pense pouvoir s’en charger mais il ne connait pas ce +qu’il y a autour de l’imprimante. + + On essaie de s’en occuper assez rapidement (bleizi et pigeonmoelleux) + +1.4.7 mettre les clés gpg dans le pass +-------------------------------------- + +pb de rétention des clefs gpg. pigeon a "pillé" à bleizi les clefs. +potentiellement signer les clefs gpg des nounous. + + Remettre de l’ordre dans le pass. thot renommé en surface sans +raison (a priori). + + Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou +autre... Sinon, demander aux vielles nounous (peb, pollion) si iels +veulent garder leurs droits nounous (ça ressemble à une invitation à +partir...). Pour les autres, on propose de rajouter les clefs gpg dans +le pass. + +1.4.8 Quand est-ce qu’on redémarre tous les serveurs qui en ont besoin +---------------------------------------------------------------------- + +Près de 400 jours qu’il tourne. (pas de coupure estivale). Pas +possible de la faire avant les prochaines vacances. En profiter pour +refaire le cablage. Une réunion de préparation de la réparation. +(redémarrage et brassage)-> prochain IN + +1.4.9 Chronolgie TODO list +-------------------------- + +Très urgent + • Backup ft (commencé à faire les backup) + • 1/2 qui non important (genre voyager et helloworld) + • par ordre d’importance (genre mailman) + • d’ici là samedi rangement, inté, séminaires + • Cephiroth (garantie go GaBo) + • puis on s’occupe de thot + +on est déjà dans qq semaines + • onlyoffice (la limite) + • bleizi, pigeon -> imprimante + • les clefs gpg dans le passe (demander à pollion et peb, s’ils + veulent rester nounous) + • enlever les vielles nounous (charlie, peb ? et pollion ?) + +Le mois prochain + • prévénir tout le monde que les serveurs du crans sont down + • Backup tealc sur zéphir/cameron + • inventaire et commander des disques d’avances (un disque en + rab compatible pour chacun des serveurs) + • coupure : recabler, (vérifier l’étiqueteuse) + • PASSER LA POOL EN 4096 + • réinstaller tealc + +Après + • voir matrix + • rediscuter de mastodon + • Nix + +Jamais + • Constellation + • Ceph + + +File: crans.info, Node: How-Tos, Next: CONTRIBUTING, Prev: Comptes rendus, Up: Top + +2 How-Tos +********* + +Cette section contient les “how to” (tutoriels) du Crans concernant des +tâches techniques demandant des connaissances généralement sur plusieurs +parties de l’infrastructure. + + Si vous souhaitez que d’autres soient ajoutés, n’hésitez pas à vous +réferrer à *note CONTRIBUTING::. + +* Menu: + +* Changer de pseudo: Changer de pseudo. + +Comment faire pour changer le nom d’utilisateur (pseudonyme) d’un⋅e +utilisateur⋅rice. Cela peut être utile par exemple lors d’un changement +d’état civil. + +* Creer VM adherent: Creer VM adherent. + +Comment faire pour créer une VM pour un⋅e adhérent⋅e. + +* La suppression d'un⋅e utilisateurice:: + +Comment supprimer un⋅e utilisateur⋅rice ainsi que toutes ses données. + +* Comment devenir nounou ?:: guide pour les nouvelles nounous ! + + +File: crans.info, Node: Changer de pseudo, Next: Creer VM adherent, Up: How-Tos + +2.1 Changer de pseudo +===================== + +Le pseudo est l’identifiant unique permettant de s’authentifier sur +l’ensemble des services du Crans. Pour diverses raisons dont il n’est +pas question de juger, un⋅e utilisateur⋅rice peut vouloir changer de +pseudo. C’est pénible mais faisable : respecter la volonté de +l’utilisateur⋅rice dans ce cas est important. Ce petit guide est là +pour rappeler tout ce qu’il ne faut pas oublier. + +2.1.1 Re2o +---------- + +Il faut bien un début, c’est sur l’intranet qu’on commence par renommer +quelqu’un⋅e. Il suffit d’éditer le profil et de changer le pseudo. + + Ne pas oublier d’aller contrôler le LDAP sur ‘yson-partou’ pour +s’assurer que l’ancien compte a bien été supprimé. Pour cela, faire un +‘sudo shelldap’ sur ‘yson-partou’, puis taper ‘cn=Utilisateurs’ et +s’assurer que ‘cat cn=ancienpseudo’ ne renvoie rien. + +2.1.2 Zamok +----------- + +Le plus évident, il faut déplacer le home ainsi que les mails. + + Si le pseudo vient à l’instant d’être modifié, il suffit de faire un +‘sudo mv /home/{ancienpseudo,nouveaupseudo}’, sinon avec l’accord de la +personne on peut faire un ‘rsync -ar +/home/{ancienpseudo,nouveaupseudo}/’, ce qui va copier le contenu de +l’ancien home dans le nouveau, mais attention au remplacement de +données. L’ancien home peut ensuite être supprimé. + + De la même manière, il faut renommer ‘/var/mail/ancienpseudo’ en +‘/var/mail/nouveaupseudo’, ou déplacer le contenu et supprimer l’ancien +dossier. + +2.1.3 Backups +------------- + +Étape non pressante, mais on peut se rendre sur ‘backup-ft’ et +‘backup-thot’ pour déplacer ‘/backup/borg-adh/home/ancienpseudo’ en +‘/backup/borg-adh/home/nouveaupseudo’, si ce n’est pas trop tard. Si le +nouveau dossier est déjà créé, alors on peut attendre quelques jours +voire quelques mois au cas où pour supprimer l’ancien dossier inutile. + + À faire avec précaution. Mais à faire puisqu’on ne garde pas des +backups éternellement. Pas pour des raisons de place mais pour des +raisons de non-conservation de données personnelles. + +2.1.4 Gitlab +------------ + +S’il n’y a pas d’ancien compte, il n’y a rien à faire. + + S’il y a un ancien compte ET un nouveau compte, c’est pénible. Il +faut transférer les appartenances de projet d’un compte à l’autre. Ce +cas ne s’étant pour l’instant pas présenté, il sera à détailler à terme. + + On se place dans l’hypothèse où l’on veut renommer un ancien compte. +On commence par se rendre dans l’interface d’administration de Gitlab, +section utilisateurs : . + + Si la personne s’est reconnectée avec son nouveau pseudo SANS AUCUNE +CONTRIBUTION, alors on peut supprimer librement ce nouveau compte. On +se rend ensuite dans les paramètres de l’ancien compte, on clique sur +“Éditer” et on remplace le pseudo. Inutile de remplacer nom et adresse +mail, ces champs sont importés par LDAP. + + Ensuite, on se rend dans l’onglet “Identités”, et on met à jour +l’identifiant LDAP. Normalement, la personne peut désormais se connecter +en n’ayant perdu ni projets ni commits, et son adresse mail ainsi que +son nom seront mis à jour à sa prochaine connexion. + +2.1.5 Owncloud +-------------- + +Deux cas à considérer : l’utilisateur⋅rice s’est servi⋅e des agendas +Owncloud ou non. Dans le premier cas, c’est pénible et cette +documentation sera mise à jour afin de détailler comment exporter et +réimporter les calendriers. + + Si l’utilisateurice n’a pas utilisé d’application externe et +uniquement le téléversement de fichiers, il suffit simplement de se +rendre dans l’interface d’administration, section utilisateur⋅rices : +, puis de chercher l’ancien +compte et de simplement le supprimer. Les données étant montées sur +Zamok, seul le home local inutile sera supprimé. + +2.1.6 Mailman +------------- + +On commence par se rendre dans Django-Admin +(https://lists.crans.org/admin/). + + S’il n’y a pas d’ancien compte, aucune question à se poser. + + S’il y a un nouveau compte inutile, on le supprime. + + S’il n’y a pas de nouveau compte, on peut changer le pseudo Mailman +si souhaité, mais l’important est surtout d’aller dans les connexions +sociales et de changer le pseudo utilisé pour lier le compte Mailman. + +2.1.7 Wiki +---------- + +Si la connexion par le CAS est configurée, il faut penser à ‘mv +/var/local/wiki/assowiki/{ancienpseudo,nouveaupseudo}’. Concerne a +priori peu de monde. + +2.1.8 The Lounge +---------------- + +Si on tient à ne pas perdre sa connexion WebIRC (si concernée), on peut +aller sur Zamok et ‘mv +/etc/thelounge/users/{ancienpseudo,nouveaupseudo}.json’ Il y a aussi des +fichiers de d’historiques des messages que l’on peut supprimer ‘rm +/etc/thelounge/logs/{pseudo}’ et ‘rm +/etc/thelounge/logs/{pseudo}.sqlite3’ ou remommer. + + +File: crans.info, Node: Creer VM adherent, Next: La suppression d'un⋅e utilisateurice, Prev: Changer de pseudo, Up: How-Tos + +2.2 Création de machine virtuelle pour les adhérent⋅es +====================================================== + +Le crans propose un système de locations de vms dont vous pouvez +retrouver les tarifs dans les annexes des statuts de l’association. En +voici un récapitulatif ici, mais attention celui-ci peut ne pas être à +jour et seul ce qui est marqué dans les statuts fait foi. + +Article Tarifs +-------------------------------------------------------------------------- +Service minimal 10€ +Connexion Internet 30€ +Cœeur additionnel 5€ +2GB de RAM additionnel 5€ +Disque additionnel (par tranche de 1€ +16G) + + Le service minimal comprend : + • n disque de 8H + • un cœur + • 2G de ram + + Tous les services sont proposés pour une durée de 1 an. + +2.2.1 Utilisateur⋅ices +---------------------- + +La documentation pour les utilisateur⋅ices se trouvent sur le wiki +(https://wiki.crans.org/VieCrans/VPS). + +2.2.2 Nounous et apprenti⋅es +---------------------------- + +2.2.2.1 Facturation +................... + +Quand cela est possible, privilégier la note. Sinon, voir avec un⋅e +trésorier⋅ère pour d’autres méthodes (espèces, virement, ...). + +2.2.2.2 LDAP +............ + +Quand un⋅e adhérent⋅e vous demande de lui créer une vm, il faut au +préalable læ rajouter dans le ldap des adhérent⋅es (qui n’est pas le +même que le ldap re2o). + + Celui ci se situe sur flirt et à la structure suivante : + +ou=users +├── cn=toto +└── cn=titi +ou=clubs +└── o=rover +ou=hosts +├── cn=voyager +└── cn=curiosity + + Pour référence ma configuration ‘shelldap’ pour me connecter au ldap +est la suivante : + +# +---------------------------------+ +# | Connexion à flirt.adm.crans.org | +# +---------------------------------+ +server: ldaps://flirt.adm.crans.org/ +promptpass: yes +binddn: cn=admin,dc=adh,dc=crans,dc=org +basedn: dc=adh,dc=crans,dc=org + + et le mot de passe est disponible dans le password-store sous +‘ldap-adh’. + +2.2.2.3 Utilisateur⋅ices +........................ + +Les objets utilisateur⋅ices dispose des champs suivants : + +dn: cn=toto,ou=users,dc=adh,dc=crans,dc=org +objectClass: inetOrgPerson +objectClass: organizationalPerson +objectClass: person +objectClass: top +cn: toto +description: birthDate:1998-01-08 +description: birthLocation:Cachan +description: membershipStart:20xx-xx-xx +description: membershipEnd:20xx-xx-xx +description: re2oId:xxxxx +givenName: Toto +mail: nobody [AT] crans [DOT] org +postalAddress: 60 rue camille desmoulins, 94230, Cachan +sn: Passoir +telephoneNumber: +336xxxxxxxx +userPassword: {CRYPT}$6$… + + Le script ‘addadherent’ du repo crans-ldap +(https://gitlab.crans.org/nounous/crans-ldap) permet néanmoins de +configurer la plupart des informations à renseigner : + +[ _shirenn@flirt ] $ ./addadherent --re2o-id xxxxx toto +Prénom: Toto +NOM: Passoir +Adresse email: nobody [AT] crans [DOT] org +Adresse: 60 avenue camille desmoulins, 94230, Cachan +Numéro de téléphone: +33600000000 +Date de naissance (YYYY-MM-DD): 1998-01-08 +Lieu de naissance: Cachan + + Cela rajoutera automatiquement la date de début d’adhésion mais pas +celle de fin d’adhésion, celle-ci doit être rajoutée à la main en +utilisant votre client ldap favori. + +2.2.2.4 Club +............ + +Les clubs sont des objets ldap très simple qui ne contiennent que le nom +des adhérent⋅es qui gèrent le club : + +dn: o=rover,ou=clubs,dc=adh,dc=crans,dc=org +objectClass: organization +objectClass: top +description: toto +o: rover + + Similairement, un script permet de rajouter ces informations +automatiquement au ldap : + +[ _shirenn@flirt ]$ ./addclub rover +Pseudo du responsable: toto +Pseudo du responsable: titi +Pseudo du responsable: + +2.2.2.5 Machines +................ + +Les machines sont des objets ldap qui répertorient des informations sur +leur configuration et leurs propriétaires : + +dn: cn=curiosity,ou=hosts,dc=adh,dc=crans,dc=org +objectClass: top +objectClass: device +objectClass: ipHost +objectClass: ieee802Device +cn: curiosity +description: ip.icmp.in,ip.icmp.out,ip6.icmpv6.in,ip6.icmpv6.out,ip.tcp.out:0-65535,ip6.tcp.out:0-65535,ip.udp.out:0-65535,ip6.udp.out:0-65535,ip.tcp.in:22,ip6.tcp.in:22 +ipHostNumber: 185.230.78.199 +macAddress: 02:a0:00:01:99:12 +owner: o=rover,ou=clubs,dc=adh,dc=crans,dc=org +serialNumber: 199 + + Le script ‘addadherenthost’ crée la machine dans le ldap + +[ _shirenn@flirt ]$ ./addadherenthost --ip 185.230.78.199 --mac +02:a0:00:01:99:02 --vmid 199 --club rover curiosity + + Le part-feu par défaut laisse passer tous les paquets icmp, tous les +paquets en sortie et ne laisse rentrer que le port 22 en tcp, en ip +legacy et en ipv6. + + Une fois l’adhérent⋅e ou le club et la machine rajoutée dans le ldap. +Les scripts devraient mettre à jour la configuration du parefeu, du dhcp +et de proxmox. + +2.2.2.6 Proxmox +............... + +Il faut maintenant aller sur le cluster constitué de gulp, odlyd et +stitch pour créer la machine virtuelle. C’est du clic clic dans +proxmox, vous êtes assez grand⋅es pour savoir lire des menus. (Par +contre faites bien attention à créer les disques sur la pool ‘vm’). + + Ensuite, deux possibilités, soit l’adhérent⋅e vous a juste demandé de +créer la machine virtuelle et à ce moment là c’est fini et iel peut +aller la configurer seul⋅e (c.f. section suivante), soit iel vous a +demandé si vous pouviez lui installer une distribution de son choix. + + Vous pouvez alors lui demander une clé publique ssh, et après avoir +installé la vm, vous la déposez dans ‘/root/.ssh/authorized_keys’ (en +faisant attention à créer le ‘.ssh’ avec les bonnes permissions ‘mkdir +-m 0700 /root/.ssh’) et vous supprimez les mots de passe que vous avez +rentrer pendant l’installation ‘passwd -d root’). + + +File: crans.info, Node: La suppression d'un⋅e utilisateurice, Next: Comment devenir nounou ?, Prev: Creer VM adherent, Up: How-Tos + +2.3 La suppression d’un⋅e utilisateurice +======================================== + +Pour diverses raisons dont il n’est pas question de juger, un⋅e +utilisateur⋅rice peut vouloir supprimer son compte Crans et les données +associées. En particulier cela peut rentrer dans le cadre du RGPD +(https://www.cnil.fr/fr/reglement-europeen-protection-donnees/). Il y a +certaines informations qu’il faut garder une durée minimale, mais les +autres doivent être supprimées à la demande de l’utilisateurice. C’est +pénible mais faisable : respecter la volonté de l’utilisateur⋅rice dans +ce cas est important. Ce petit guide est là pour rappeler tout ce qu’il +ne faut pas oublier. + +2.3.1 La demande de suppression +------------------------------- + +Il faut s’assurer que c’est bien la bonne personne qui fait la demande. +En cas de doute, on peut demander une preuve d’identité (pièce +d’identité, mail depuis l’adresse mail crans...). Ensuite, on peut +vérifier que la personne à bien compris ce que la suppression de compte +impliquait : la perte de toutes les données non sauvegardées par +l’utilisateurice, ne plus avoir accès aux services qui nécessite un +compte crans... Selon ce qui est demandé (et ce qu’on a le droit de +faire), le compte peut être seulement archivé, on peut supprimer les +données liées au compte (en totalité ou partie), voire les données d’un +service non-lié à un compte crans (wiki...). Si la personne est encore +adhérente, elle va probablement devoir démissionner de l’association. + +2.3.2 Re2o +---------- + +Il faut bien un début, c’est sur l’intranet qu’on commence par +supprimer/archiver quelqu’un⋅e. + +2.3.2.1 Archiver sur Re2o +......................... + +Si la personne à une facture/adhésion de moins de 10 ans, on ne peut pas +supprimer le compte. Dans ce cas-là, ou si c’est ce que préfère +l’utilisateurice, on archive le compte : dans le profil, il faut changer +l’état de "Actif⋅ves" à "Complétement archivé⋅es". On peut +éventuellement supprimer certaines informations (bannissement, +établissement...) mais on doit garder les informations de contact et les +factures/adhésions de moins de 10 ans. + + On peut repasser au bout des 10 ans pour tout supprimer (ça serait +bien d’avoir un truc automatique ou que l’utilisateurice nous le +rappelle). + +2.3.2.2 Supprimer sur Re2o +.......................... + +Il faut aller dans l’interface d’administration + et supprimer l’user. Il va +falloir supprimer les objets protégés avant, django vous dira lesquels. + + Ne pas oublier d’aller contrôler le LDAP sur ‘yson-partou’ pour +s’assurer que le compte a bien été supprimé. Pour cela, faire un ‘sudo +shelldap’ sur ‘yson-partou’, puis taper ‘cn=Utilisateurs’ et s’assurer +que ‘cat cn={pseudo}’ ne renvoie rien. + +2.3.3 Zamok +----------- + +Le plus évident, il faut supprimer le home ainsi que les mails. + + Il suffit de faire un ‘sudo rm -rf /home/{pseudo}’, pour supprimer le +home. De même pour les mails dans ‘/var/mail/{pseudo}’. + +2.3.4 Backups +------------- + +Étape non pressante, mais on peut se rendre sur ‘backup-ft’ et +‘backup-thot’ pour supprimer ‘/backup/borg-adh/home/{pseudo}’. + + À faire avec précaution. Mais à faire puisqu’on ne garde pas des +backups éternellement. Pas pour des raisons de place mais pour des +raisons de non-conservation de données personnelles (même si les backup +ne sont pas concernées par le RGPD). + +2.3.5 Gitlab +------------ + +S’il n’y a pas de compte, il n’y a rien à faire. + + On se place dans l’hypothèse où l’on veut supprimer un compte. On +commence par se rendre dans l’interface d’administration de Gitlab, +section utilisateurs : . On se +rend dans les paramètres du compte, on clique sur "Administration des +utilisateur" puis sur "Supprimer un compte utilisateur" ou "Supprimer un +compte utilisateur et ses contributions". Dans le deuxième cas, il faut +faire attention surtout s’il y a des contributions à des projets +partagés (comme ceux du crans). + +2.3.6 Owncloud +-------------- + +Il suffit simplement de se rendre dans l’interface d’administration, +section utilisateurices : , +puis de chercher le compte et de simplement le supprimer. + +2.3.7 Mailman +------------- + +On commence par se rendre dans Django-Admin +(https://lists.crans.org/admin/). + + S’il n’y a pas de compte, aucune question à se poser. + + S’il y a un compte, on le supprime. + + Potentiellement, la personne est présente sur mailman de manière +non-liée à son éventuel compte crans. Dans ce cas, il va falloir faire +du ménage avec l’adresse mail et donc de l’aide de l’utilisateurice qui +va devoir indiquer son adresse et les ML qu’iel reçoit/administre. Ça +peut être un peu les bazar si il y a plusieurs adresses non-liées. Si +la personne est lae dernièr⋅e propriétaire d’une liste, il faudra soit +la supprimer soit lui trouver un⋅e nouvelleau propriétaire (c’est pas +obligatoire mais alors c’est le propriétaire par +défaut, ce qui n’est pas une solution durable). + +2.3.8 Wiki +---------- + +Si la connexion par le CAS est configurée, il faut penser à ‘rm +/var/local/wiki/assowiki/{pseudo}’. Concerne a priori peu de monde. + + Si la personne le demande, on peut supprimer son compte wiki et les +pages qui concernent son compte (page perso...), historique compris. +Pour cela il faut aller sur ‘kiwi’ et supprimer le dossier contenant la +page. Cela peut concerner des personnes n’ayant pas de compte crans, +mais il faudra le WikiNom. + +2.3.8.1 The Lounge +.................. + +S’il y a eu une utilisation de WebIRC, on peut aller sur Zamok et ‘rm +/etc/thelounge/users/{pseudo}.json’ (configuration), ‘rm +/etc/thelounge/logs/{pseudo}’ et ‘rm +/etc/thelounge/logs/{pseudo}.sqlite3’ (pour l’historique des messages). + +2.3.8.2 Autres données +...................... + +Il y a probablement des données personnelles qui trainent ailleurs, il +faudra mettre à jour cette page si on en trouve. Par exemple, pour les +membres actif⋅ves qui ont un compte underscore ou les utilisateurices +qui ont (eu) une VM (perso ou de club). + +2.3.8.3 Données hébergées mais pas administrée par le Crans +........................................................... + +Le Crans héberge des VM pour les clubs (note, serveur photos, bdd +med...) qui peuvent contenir des données personnelles. La personne +devra aller voir les admins de ces services pour supprimer les données. + + +File: crans.info, Node: Comment devenir nounou ?, Prev: La suppression d'un⋅e utilisateurice, Up: How-Tos + +2.4 Comment devenir nounou ? +============================ + +Bonjour jeune apprenti⋅e, tu regardes sûrement avec des yeux pleins +d’étoiles tes ainé⋅es qui actuellement disposent des droits suprêmes sur +l’infrastructure du Crans. Ce petit document est là pour t’expliquer +comment toi aussi un jour tu pourras devenir l’un⋅e d’elleux. Et quand +il sera temps et que tu commenceras à t’encrouter, comment tu pourras +rendre tes droits. + + Déjà commençons par une question un peu conne mais néanmoins légitime +“Qui "mérite" d’être nounou ?” Premièrement, devenir nounou N’EST PAS +une question de compétence. Pas besoin de connaître l’infrastructure +par cœur, tous les fichiers de conf, être un pro d’apt, d’ansible et de +la couche 2. Tout ce qu’on attend d’une nouvelle nounou c’est d’être +capable de ne pas faire n’importe quoi avec ces droits. Devenir nounou +ce n’est pas avoir fini son apprentissage mais bien la deuxième étape de +celui-ci où on commence à mettre les mains dans le camboui. Et ça ça +présuppose seulement qu’on va pas causer du tort en utilisant ces +droits. + + Détaillons-les un peu ces droits, ce qu’il permette de faire et +qu’est ce qu’on entend par « causer du tort ». En devenant nounou, vous +débloquez les accès à toute l’infrastructure. Techniquement, il n’y a +plus de fichiers que vous ne pouvez pas voir, modifier ou supprimer et +ce sur toutes les machines du Crans. De même, on chiffre pour vous tous +les mots de passe qui ont trait au technique du Crans. Ce sont des +droits très extensifs. D’où la possibilité de faire une erreur de +manipulation. Normalement tout est fait dans l’infrastructure pour +limiter la casse possible. On a de la redondance où c’est possible et +nécessaire, on fait des backups quotidiennes à la fois des données +utilisateur⋅rices mais aussi des données d’administration. Cependant, +tout ça ne change pas le fait qu’une mauvaise commande rentrée dans +votre shell peut rendre le Crans hors ligne pour quelques heures ou +supprimer de manière irreversible des données. Quand vous devenez +nounou, on vous fait confiance pour éviter ce genre de choses au +maximum. Après les erreurs ça arrive toujours. La personne qui écrit +ces lignes en a fait un certain nombre avec des conséquences diverses. +Ce qui compte ce n’est pas de ne pas en faire du tout, c’est d’en faire +peu, d’apprendre de celles-ci et de s’assurer qu’elles ne sont pas +irréversibles. + + Il y a aussi quelque chose qu’il faut souligner. Et normalement +quand vous deviendrez nounou vous allez le voir assez fréquement (à +chaque fois que vous faîtes un sudo pour la première fois sur une +machine) : + +We trust you have received the usual lecture from the local System +Administrator. It usually boils down to these three things: + + #1) Respect the privacy of others. + #2) Think before you type. + #3) With great power comes great responsibility. + + Ce court texte résume bien ce que je veux aborder ici. Les droits +que vous vous voyez confier sont une intrusion phénoménale dans la vie +privée des gens. Si vous voulez une métaphore, vous pouvez voir ça +comme si les adhérent⋅es du Crans vous avait donné la clé de leur maison +pour que vous puissiez réparer quand il y a une fuite d’eau, mais pas +pour que vous fouillez dans le bureau pour voir leurs papiers. Beaucoup +de nos adhérent⋅es utilisent les outils qu’on met à leur disposition +pour organiser une partie de leur vie, que ce soit d’utiliser l’adresse +mail qui leur est fournie ou stocker des données dans leur Owncloud, et +nous en sommes très heureux⋅ses. La charte que vous avez signé en +devenant apprenti⋅e mentionne déjà ces problématiques mais il est +important que ce soit très clair. _Vous ne pouvez consulter ou diffuser +les données personnelles d’un⋅e adhérent⋅e qu’avec son consentement +explicite._ On a parfois tendance à l’ENS à faire des abus de droits +une blague, ce n’est pas le cas au Crans ! + + Bon maintenant que ces clarifications et rappels ont été faits, on va +pour passer aux choses plus intéréssantes : comment on se donne ces +droits (et dans la marge, comment on se les retire) ? + +2.4.1 Rentre dans le cercle +--------------------------- + +Le groupe des superadministrateur⋅rices au Crans est le groupe nounou. +On va donc faire un petit tour dans le ldap et sous ou=groups,cn=_nounou +on rajoute les uids correspondant au⋅x personne⋅s qu’on souhaite +ajouter. Voilà, vous avez normalement:tm: les accès root sur toutes les +machines du Crans. Cependant, vous allez peut-être constater qu’il y a +certaines machines où cela ne fonctionne pas. C’est sûrement dû à ces +(conneries) de replicat ldap. Il faut à ce moment là aller faire un +tour dessus pour forcer la resynchro (*note LDAP::). + +2.4.2 Give me the password +-------------------------- + +Vous avez 50 nouveaux mot de passes. Il est maintenant nécessaire de +rechiffrer le pass pour vous. C’est un peu chiant mais on s’y fait. +Voilà la procédure: + + 1. On se souvient du hash de commit courant : ‘HASH=$(git rev-parse + HEAD)’ + 2. On ajoute toutes les personnes concernées dans le groupe nounou + dans le fichier ‘.groups.yml’ du store et on commit ces changements + ‘git commit -m toto1234’. + 3. On rechiffre tous les fichiers à rechiffrer ‘cat .last_group.json | + jq -r '. | with_entries( select(.value | any( .== "nounou"))) | + keys[]' | xargs pass rans reencrypt’ + 4. On supprime tous les commits inutiles : ‘git reset --soft $HASH; + git commit -m 'Coucou les ami⋅es'’ + 5. On vérifie que ça marche et on push :) + + Petit point pour quand on retire des droits au gens. Là où pour tous +les autres droits, quand vous les retirez à quelqu’un⋅e bah iel les a +plus, ce n’est pas le cas pour les mots de passe. Il reste dans +l’historique de git un moment où la personne qui perds ces droits à +toujours les mots de passes chiffrées pour elle. On choisit +généralement de s’en tamponner l’oreille avec une babouche. Cependant, +il peut y avoir certains moments où on veut effectivement retirer +complètement à quelqu’un⋅e la possibilité d’utiliser un mot de passe. +Dans ce cas il faut le changer :( + +2.4.3 Thank you for your services +--------------------------------- + +Au Crans on a plein de services. Certains sont gentils et écoutent +directement le ldap pour savoir qui a des droits, d’autres s’en foutent +et ils faut se rajouter dans les admins à la main. Petite liste ci +dessous. + +2.4.3.1 Gitlab +.............. + +Il faut aller dans la zone d’administration, puis dans la liste +d’utilisateur⋅ices et changez le profil de l’utilisateur⋅ice de regular +à admin. + +2.4.3.2 Mailman +............... + +Il faut se connecter normalement au logiciel, puis allez dans la section +admin , dans la sous page +utilisateur⋅rices, on peut rechercher les personnes concernées pour leur +donner les deux statuts admin (accès à la zone d’administration) et +superutilisateur (bypass tous les checks de droits). + +2.4.3.3 Owncloud +................ + +Il faut aller dans la zone d’administration et rajouter les +utilisateur⋅ices au groupe d’administration. + +2.4.3.4 Re2o +............ + +Oh lad, j’espère que ça aussi ça existe plus. Il faut aller dans la +section gestion des groupes et rajouter les personnes aux groupes +nounous et au groupe superutilisateur⋅rice. + +2.4.3.5 Kiwi +............ + +On édite le fichier de conf du wiki sous ‘/etc/moin/mywiki.py’ et on +rajoute son compte wiki dans la liste des administrateur⋅rices. + +2.4.3.6 IRC +........... + +On édite le fichier ‘/etc/inspircd/opers.conf’ pour rajouter un bloc +suivant + + + password="" + hash="sha256" + host="*" + type="Deity" + fingerprint="" + autologin="on" +> + + Où le hash du mot de passe peut être obtenu en envoyant ‘/quote +mkpasswd hmac-sha256 ’. Pour rendre les changements effectifs +on reload le service inspircd (tips, la manière la plus rapide de perdre +ses droits est de restart le serveur plutôt que de le reload ^^). + +2.4.3.7 Mails +............. + +Il faut maintenant vous rajouter en alias de . C’est le +début du spam. Pour ce faire, rendez-vous sur le dépôt Gitlab +‘mail-aliases’, et ajoutez votre pseudo Crans sur la bonne ligne dans +les bons fichiers, en face de ‘root:’. Pensez ensuite à mettre à jour +le dépôt pour le service ‘mail’, et enfin mettez bien à jour +‘redisdead’, ‘sputnik’ et surtout ‘zamok’ dans le dossier +‘/var/local/services/mail’. Enfin, pensez bien à filtrer les mails +arrivant à l’adresse sur votre client. + + Voilà, tu as maintenant gagné le droit de t’ajouter ou de te retirer +de < ! + + +File: crans.info, Node: CONTRIBUTING, Next: Tools, Prev: How-Tos, Up: Top + +3 Contributing +************** + +TODO. + + +File: crans.info, Node: Tools, Next: Index, Prev: CONTRIBUTING, Up: Top + +4 Tools +******* + +* Menu: + +* LDAP:: + + +File: crans.info, Node: LDAP, Up: Tools + +4.1 LDAP +======== + +TODO. + + +File: crans.info, Node: Index, Prev: Tools, Up: Top + +Index +***** + + + +Tag Table: +Node: Top1228 +Node: Comptes rendus1420 +Node: CR Template2425 +Node: 2024 01 133274 +Node: 2024 06 226935 +Node: 2024 08 2911304 +Node: How-Tos19272 +Node: Changer de pseudo20199 +Node: Creer VM adherent25328 +Node: La suppression d'un⋅e utilisateurice31366 +Node: Comment devenir nounou ?38189 +Node: CONTRIBUTING47316 +Node: Tools47435 +Node: LDAP47550 +Node: Index47621 + +End Tag Table + + +Local Variables: +coding: utf-8 +End: diff --git a/infrastructure/machines/physiques/arista.md b/infrastructure/machines/physiques/arista.md index dc11b46..ee349c5 100644 --- a/infrastructure/machines/physiques/arista.md +++ b/infrastructure/machines/physiques/arista.md @@ -144,13 +144,64 @@ thor(config-if-Et3-4)#exit ``` Puis ensuite on peut configurer le reste (VLANs et tout …) dans l'interface -Port-Channel 3. +Port-Channel 3. (Et non pas sur les interfaces eth). ```txt thor(config)#interface Port-Channel 3 thor(config-if-Po3)# ``` +### Configurer le MLAG (Multi chassis Link AGregregation) + +Nos switch arista supportent une feature que arista appele le MLAG. Cette feature +permet notaments de faire du LACP avec des ports entre deux switch et donc d'avoir +une redondance sur les switchs. + +Il faut commencer par configurer le MLAG entre les deux switchs. + +```txt + TODO +``` + +On peut ensuite configurer un lien en LACP. On configure ici les ports 3 de chaque switch +en redondance sur le port-channel 3 / mlag 3. + +sur le premier switch: +```txt +arceus(config)#interface ethernet 3 +arceus(config-if-Et3)#channel-group 3 mode active +arceus(config-if-Et3)#interface port-channel 3 +arceus(cofnig-if-Po3)#mlag 3 +``` + +sur le second switch: +```txt +carapuce(config)#interface ethernet 3 +carapuce(config-if-Et3)#channel-group 3 mode active +carapuce(config-if-Et3)#interface port-channel 3 +carapuce(config-if-Po3)#mlag 3 +``` + +On peut vérifier l'état des liens configurés en mlag via: +```txt +carapuce(config-if-Po11)#show mlag interfaces + local/remote + mlag desc state local remote status +---------- ---------- ----------------- ----------- ------------ ------------ + 1 active-full Po1 Po1 up/up + 3 active-full Po3 Po3 up/up + 5 active-full Po5 Po5 up/up + 6 inactive Po6 Po6 down/down + 7 inactive Po7 Po7 down/down + 8 active-full Po8 Po8 up/up + 9 inactive Po9 Po9 down/down + 10 active-full Po10 Po10 up/up + 11 active-full Po11 Po11 up/up + 12 inactive Po12 Po12 down/down +``` + +Il faudra configurer les vlans et autres sur les port-channel des deux switchs. + ### Mettre à jour le switch > C'est pas forcément nécessaire et ça peut tout casser, si néanmoins tu From d1ef8bac02cda8b3f7d5617d1c1f076e9557cf17 Mon Sep 17 00:00:00 2001 From: RatCornu Date: Sat, 9 Nov 2024 18:12:50 +0100 Subject: [PATCH 6/9] Fix pipeline --- infrastructure/machines/physiques/arista.md | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-) diff --git a/infrastructure/machines/physiques/arista.md b/infrastructure/machines/physiques/arista.md index ee349c5..5188175 100644 --- a/infrastructure/machines/physiques/arista.md +++ b/infrastructure/machines/physiques/arista.md @@ -163,10 +163,11 @@ Il faut commencer par configurer le MLAG entre les deux switchs. TODO ``` -On peut ensuite configurer un lien en LACP. On configure ici les ports 3 de chaque switch -en redondance sur le port-channel 3 / mlag 3. +On peut ensuite configurer un lien en LACP. On configure ici les ports 3 de +chaque switch en redondance sur le port-channel 3 / mlag 3. + +sur le premier switch : -sur le premier switch: ```txt arceus(config)#interface ethernet 3 arceus(config-if-Et3)#channel-group 3 mode active @@ -174,7 +175,8 @@ arceus(config-if-Et3)#interface port-channel 3 arceus(cofnig-if-Po3)#mlag 3 ``` -sur le second switch: +sur le second switch : + ```txt carapuce(config)#interface ethernet 3 carapuce(config-if-Et3)#channel-group 3 mode active @@ -182,7 +184,8 @@ carapuce(config-if-Et3)#interface port-channel 3 carapuce(config-if-Po3)#mlag 3 ``` -On peut vérifier l'état des liens configurés en mlag via: +On peut vérifier l'état des liens configurés en mlag via : + ```txt carapuce(config-if-Po11)#show mlag interfaces local/remote From 67af7977b1c6a49ec6cdea10d2c3e6ddfe62e014 Mon Sep 17 00:00:00 2001 From: RatCornu Date: Sat, 9 Nov 2024 18:09:41 +0100 Subject: [PATCH 7/9] =?UTF-8?q?Ajout=20howto/red=C3=A9marrer=5Fcrans.md?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- howto/redemarrer_crans.md | 106 ++++++++++++++++++++++++++++++++++++++ 1 file changed, 106 insertions(+) create mode 100644 howto/redemarrer_crans.md diff --git a/howto/redemarrer_crans.md b/howto/redemarrer_crans.md new file mode 100644 index 0000000..af0590e --- /dev/null +++ b/howto/redemarrer_crans.md @@ -0,0 +1,106 @@ +# Comment redémarrer le Crans ? + +Le Crans dispose de beaucoup de serveurs physiques en salle opérateur de l'ENS +(actuellement en SQ39), ainsi que beaucoup de machines virtuelles tournant sur +les hyperviseurs. De temps en temps (environ une fois par an), vous serez +amené⋅es à redémarrer l'entièreté des machines, par exemple pour recâbler la +baie, et il faudra alors faire les choses dans l'ordre. Voici un petit guide +sur comment faire précisément. + +## Préparation + +Tout d'abord, il faut discuter quelques semaines (~2 mois) en avance du besoin +d'un redémarrage : ce n'est pas un acte à prendre à la légère car des personnes +(même des vieilleux !) utilisent des services du Crans dans la vie de tout les +jours, il faut donc éviter de les couper trop souvent. Cependant, pour faire +des mises à jour majeures, du recâblage, des changements de serveurs, ... cela +peut s'avérer nécessaire. + +Il faut discuter du besoin d'un redémarrage pendant au moins 2 IN au préalable +pour bien définir ce qu'il y a précisément à faire, et quelles seront les +nounous présentes pour aider. Bien évidemment, les apprenti⋅es sont les +bienvenu⋅es, mais il est impératif que des nounous soient présentes pour bien +expliquer ce qu'il se passe. + +Ensuite, une fois que le besoin de redémarrer est bien acté, il faut prévenir +la **totalité** des adhérent⋅es et des ancien⋅nes adhérent⋅es du Crans avec ce +qu'on appelle communément un "mail all". Pour cela, vous devez vous rendre sur +la VM `re2o`, écrire le mail dans un nouveau dossier puis exécuter le script +d'envoi de mail. Ce mail doit être envoyé au minimum deux semaines avant la +coupure, voire plus si possible. Il ne faut pas hésiter en plus de cela de +prévenir de nouveau les adhérent⋅es via d'autres plateformes de communications +(newsletter BdE, Discord, ...). + +## Avant la coupure + +Le jour de la coupure, le mieux est de réunir toutes les personnes souhaitant +participer (sans compter les retardaires) dans le bureau du Crans (actuellement +en MB87). Une bonne idée est de prendre le temps qu'il faut pour clairement +poser le plan du jour sur un tableau avec les différents objectifs à réaliser, +potentiellement en parallèle. N'hésitez pas à vous répartir sur différentes +tâches effectuables simultanément si vous êtes suffisamment nombreux⋅ses +(compter au moins deux personnes dont une nounou par tâche pour ne laisser +personne seul). + +Vous pouvez au préalable ou par la suite récupérer les badges du Crans ouvrant +la salle opérateur SQ39 au PC sécurité : prendre deux badges au lieu d'un est +une plutôt bonne idée pour qu'un groupe de personnes puisse faire un +aller-retour sans se retrouver coincé à l'extérieur. Ne pas hésiter également à +prendre à boire, de préference dans des récipients qui ne se renversent pas +facilement et des boissons qui ne tâchent pas trop. + +En parallèle, vous pouvez garder une trace de toutes les actions effectuées +dans la journée en notant tout ce que vous faites sur un pad (qui n'est pas +hébergé au Crans) pour pouvoir retracer toutes les actions, ce qui est pratique +lorsque que quelque chose casse (un peu souvent donc). + +## Éteindre les serveurs + +Pour éviter au maximum les problèmes, l'extinction des serveurs peut se faire +dans un ordre important peu, sauf pour quelques machines importantes. Voici +un ordre qui fonctionne avec l'infrastructure actuelle : + +- serv[ENS] +- VM adh (passer par Proxmox sur stitch/odlyd/gulp) +- hyperviseurs adh : stitch/odlyd/gulp +- zamok +- VM adm (sauf routeur-sam !, passer par Proxmox sur sam) +- hyperviseurs adm (sauf sam !) : jack/daniel +- cameron +- tealc +- sam + +Surtout ne pas hésiter à vous ssh sur les machines au préalable pour ne pas se +retrouver coincé car le LDAP adm est éteint. + +## Rallumer les serveurs + +De même que pour l'extinction, l'allumage des serveurs peut se faire dans à peu +près n'importe quel ordre, sauf pour quelques machines importantes. Voici un +ordre qui fonctionne avec l'infrastructure actuelle : + +- sam et routeur-sam +- tealc +- cameron +- hyperviseurs adm : jack/daniel +- zamok +- VM adm (passer par Proxmox sur sam) +- hyperviseurs adh : stitch/odlyd/gulp +- VM adh (passer par Proxmox sur stitch/odlyd/gulp) +- serv[ENS] + +Attention : pour zamok, vous devez redémarrer le service postfix avec + +```bash +sudo systemctl restart postfix.service +``` + +après avoir rétabli le réseau et **avant** de redémarrer redisdead afin de ne +perdre aucun mail. Plus exactement : il faut vérifier que le dossier +`/home/mail` sur zamok contienne des centaines d'adhérent⋅es en non pas +seulement quelques dizaines. + +Ensuite, assurez-vous bien que **TOUS** les serveurs soient allumés, dont ceux +de serv[ENS] ! Profitez-en alors pour faire des mises à jour nécessaires +pendant que les adhérent⋅es ne sont pas encore de retour sur zamok et les +autres services. From 7381166084319c640cecda20ea9bbdad0d07c498 Mon Sep 17 00:00:00 2001 From: RatCornu Date: Sat, 9 Nov 2024 23:01:47 +0100 Subject: [PATCH 8/9] fix comments --- howto/redemarrer_crans.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/howto/redemarrer_crans.md b/howto/redemarrer_crans.md index af0590e..71a4547 100644 --- a/howto/redemarrer_crans.md +++ b/howto/redemarrer_crans.md @@ -56,9 +56,9 @@ lorsque que quelque chose casse (un peu souvent donc). ## Éteindre les serveurs -Pour éviter au maximum les problèmes, l'extinction des serveurs peut se faire -dans un ordre important peu, sauf pour quelques machines importantes. Voici -un ordre qui fonctionne avec l'infrastructure actuelle : +Pour éviter au maximum les problèmes, il est important que certaines machines +soient éteintes avant d'autres. Voici un ordre qui fonctionne avec +l'infrastructure actuelle : - serv[ENS] - VM adh (passer par Proxmox sur stitch/odlyd/gulp) @@ -89,7 +89,7 @@ ordre qui fonctionne avec l'infrastructure actuelle : - VM adh (passer par Proxmox sur stitch/odlyd/gulp) - serv[ENS] -Attention : pour zamok, vous devez redémarrer le service postfix avec +⚠ Attention : pour zamok, vous devez redémarrer le service postfix avec ```bash sudo systemctl restart postfix.service From 84f5d6dd64d167bd4383f02436de6f1e1ac926c9 Mon Sep 17 00:00:00 2001 From: RatCornu Date: Tue, 19 Nov 2024 02:22:58 +0100 Subject: [PATCH 9/9] =?UTF-8?q?Ajout=20restic=20+=20d=C3=A9placement=20bor?= =?UTF-8?q?g?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit --- outils/logiciels/backups/README.md | 92 ++++++++++++++++ outils/logiciels/backups/borg.md | 110 +++++++++++++++++++ outils/logiciels/backups/restic.md | 138 ++++++++++++++++++++++++ services/borg.md | 164 ----------------------------- 4 files changed, 340 insertions(+), 164 deletions(-) create mode 100644 outils/logiciels/backups/README.md create mode 100644 outils/logiciels/backups/borg.md create mode 100644 outils/logiciels/backups/restic.md delete mode 100644 services/borg.md diff --git a/outils/logiciels/backups/README.md b/outils/logiciels/backups/README.md new file mode 100644 index 0000000..2b5f9b7 --- /dev/null +++ b/outils/logiciels/backups/README.md @@ -0,0 +1,92 @@ +# Outils de backups + +## Présentation + +Ce dossier contient une présentation des logiciels utilisés par le Crans pour +faire ses sauvegardes, ou backups en anglais. On entend ici par backup une +opération qui consiste à dupliquer de manière sécurisée (chiffrée en +l'occurrence) sur d'autres serveurs les données des utilisateurices et des +machines du Crans. + +Comme dans tout le dossier [logiciels](../../../), le but n'est pas de +réexpliquer l'entièreté des fonctionnalités mais simplement d'a voir les bases +de compréhension. + +## Organisation + +Vous trouverez ici deux fichiers correspondant aux deux logiciels utilisés pour +les backups au Crans : + +- [borg](./borg.md) pour les logiciels borg et borgmatic ; +- [restic](./restic.md) pour le logiciel du même nom. + +Il est cependant fortement conseillé de lire la fin de ce fichier présentant +certaines informations concernant les backups qu'il est important de connaître +avant de lire plus en détails les autres fichiers détaillant plus +spécifiquement les logiciels. + +## Contexte + +### Historique + +Pour prevenir certains incidents dus à des erreurs de manipulation, le collège +technique a mis en place en système de backups. Le but de celui-ci est de +pouvoir, si le besoin s'en fait ressentir, aller rechercher un fichier supprimé +ou écrasé. Bien qu'il serait possible de simplement faire une copie périodique +des données sur un serveur distant, on lui préfère des solutions un peu plus +développées qui permettent de faire des sauvegardes incrémentales. Fut un temps, +la solution technique en place était le logiciel +[BackupPC](https://backuppc.github.io/backuppc/), cependant celui-ci commençant +à dater et ayant une faible ergonomie, nous utilisons aujourd'hui le logiciel +[borg](https://borgbackup.readthedocs.io/) et son frontend +[borgmatic](https://torsion.org/borgmatic/). De plus, le logiciel +[restic](https://restic.readthedocs.io/) a été installé en parallèle pour sa +simplicité d'utilisation : borg/borgmatic et restic cohabitent donc pour le +moment pour que les jeunes membres actif⋅ves puissent comparer afin de faire un +choix à long terme. + +### Backups incrémentales + +Avant de présenter ces logiciels, attardons nous un peu sur ce qu'on entend par +faire des backups incrémentales. Pour cela revenons à notre piètre solution +initiale qui consiste à copier (à grands coups de rsync, unison, scp...) toutes +les données que l'on souhaiterait sauvegarder. Pour que ces sauvegardes soient +utiles, il faut les réaliser assez fréquemment (quelque part entre un jour et +une semaine disons). Cependant, à chaque nouvelle backup réalisée, celle-ci va +venir écraser le contenu de la précédente et ainsi, on ne dispose jamais plus +que d'une copie des données de la veille. Ainsi, des dysfonctionnements +automatiques ou simplement de la négligence peuvent faire que l'on ne se rendra +compte que l'on avait besoin de récupérer notre fichier il y a déjà quelques +jours et qu'il a maintenant déjà été supprimé de la copie de sauvegarde. + +On préfererait donc pouvoir disposer d'une collection de sauvegardes qui +remonte sur quelques jours voir moi en fonction de la politique de rétention de +sauvegarde qu'on mettrait en place. Par exemple, une sauvegarde pour chacun des +septs derniers jours puis quelques unes espacée d'une semaine. Si l'on reprend +notre solution naïve, on peut facilement en étendre l'usage pour ce nouvel +office : on réalise une copie complète des données par jour que l'on souhaite +sauvegarder. Suivant la politique de rétention que l'on a donné plus tôt cela +consisterais en une quinzaine de copies distinctes des données à sauvegarder et +donc une multiplication par quinze de la taille de celle-ci. + +Si je jette un œil rapide à la taille que prends aujourd'hui les données +utilisateurices, je vois qu'on utilise un peu plus de 2.5T de stockage, donc si +l'on suit la logique, on devrait disposer d'une ou plusieurs machines +totalisant un stockage d'environ 40T. Inutile de le dire je pense, mais cela +fait (beaucoup) trop. Heureusement pour nous, d'un jour sur l'autre +l'intégralité de nos données stockées ne varie pas et seule une petite partie +change sur le cours d'une journée. Ainsi, si l'on ne stocke que les différences +accumulé sur une journée par rapport à la veille, on se retrouvera avec une +taille beaucoup plus raisonnable de sauvegarde. C'est ~la déduplication. + +### Qu'est-ce que l'on sauvegarde ? + +Au Crans, on sauvegarde deux types de données : + +- D'un côté, on a les données d'administration, c'est une partie des disques + de tous les serveurs (généralement le /etc et le /var sauf cas particulier), + le home des nounous, les bases de données... + +- De l'autre côté; on a les données des adhérents, c'est à dire : le contenu + de leur répertoire personnel et de leur dossier mail qui au jour où j'écris + ses lignes peut contenir au maximum 30G et 10G de données respectivement. diff --git a/outils/logiciels/backups/borg.md b/outils/logiciels/backups/borg.md new file mode 100644 index 0000000..36d345f --- /dev/null +++ b/outils/logiciels/backups/borg.md @@ -0,0 +1,110 @@ +# Borg + +Page officiel de borg : . + +Documentation de borg : . + +Page officielle de borgmatic : (contient la +documentation). + +## Borg et borgmatic + +Borg est un logiciel client/serveur permettant d'effectuer des sauvegardes +incrémentales, dédupliquées et chiffrées par le client. Le serveur est simple à +installer et utilise ssh comme protocole de transport entre lui et le client. +Ainsi, il suffit de donner un accès ssh au client via une paire de clés pour lui +autoriser à discuter avec le serveur. Quelque chose ressemblant à ça dans le +`.ssh/authorized_keys` de l'utilisateur sur le serveur qui fera les backups : + +```txt +command="borg serve --restrict-to-path {{ chemin vers les sauvegardes }}",restrict {{ clé publique ssh }} +``` + +Avec l'installation du paquet `borg` c'est la seule chose à faire sur le serveur +et le reste du travail sera réalisé par le client. Après avoir aussi installé +`borg` sur le client, on peut déjà commencer à faire quelques sauvegardes. +Cependant, si l'on utilise que borg pour les faire (ce qui est possible), on se +retrouvera avec des commandes bien trop longues dans lesquels on passe notre +temps à spécifier des arguments plusieurs fois : comment contacter le serveur ? +où stocker les sauvegardes ? quel politique de rétentions garder ? que faut-il +sauvegarder ? Borgmatic est un frontend de borg qui définir une bonne fois pour +toutes ses options dans un fichier de configuration pour ensuite n'avoir plus +qu'à faire des appels simples à borgmatic qui pasera à borg tous les paramètres +dont il a besoin. Le but n'est pas ici d'être exhaustif sur ce que peut/doit +contenir ce fichier de configuration. Je vous redirige pour ça vers la +[documentation +officielle](https://torsion.org/borgmatic/docs/reference/configuration/). Ici, +je vais plus chercher à vous donner quelques options minimales et des exemples +d'utilisations de borgmatic. Commençons par donner le contenu d'un fichier de +configuration partiel : + +```txt +location: + source_directories: + - /etc + - /var + repositories: + - borg@backup-server:/folder/to/bacup/to + +storage: + encryption_passphrase: PASSPHRASE + ssh_command: ssh -i /etc/borgmatic/id_ed25519_borg + +retention: + keep_daily: 4 + keep_monthly: 6 +``` + +Dans la section `location`, on définit deux choses : ce que l'on souhaite +sauvegarder et où on souhaite le sauvegarder. Ici on va backupé le `/etc` et +`/var` de notre client sur un serveur distant qu'on contactera via ssh. Dans la +section suivante, `storage`, on définit quelques options relatives au stockage +et à comment y accéder. Premièrement, on donne la passphrase de chiffrement des +sauvegardes (attention, si elle est perdue, les sauvegardes ne seront plus +accessibles). Ensuite, on précise comment accéder au serveur (ici, l'information +importante est où se trouve la clé privée pour pouvoir se connecter). Enfin, +dans la section retention, on définit notre politique de retention : le serveur +ne doit stocker qu'une backup quotidienne sur les 4 derniers jours, et une +backup mensuelle sur les 6 derniers mois. + +En supposant les autres options de fonctionnement renseignées dans le fichier, +que je ne détaillerais pas ici, il est maintenant possible de commencer à +utiliser le logiciel et faire nos premières sauvegardes. + +## Créer l'archive de stockage + +La commande suivante permet de créer l'archive où seront stockées les +sauvegardes sur le serveur. + +```bash +borgmatic init -e repokey +``` + +## Faire une première sauvegarde + +Pour faire une sauvegarde, rien de plus simple, on appelle simplement le +programme borgmatic sans option. Il est néanmoins possible de demander un +affichage plus verbeux pour le débogage. + +```bash +borgmatic +borgmatic -v 2 +``` + +## Lister les différentes sauvegardes dans l'archive + +```bash +borgmatic list +``` + +## Monter une sauvegarde précise sur un point de montage + +```bash +borgmatic mount --archive {{ nom de l'archive ou latest pour la dernière }} --mount-point /mnt --path {{ chemin à monter de l'archive }} +borgmatic mount --archive latest --mount-point /mnt --path etc/nginx/nginx.conf +``` + +## Automatiser les backups + +Pour réaliser des backups périodique, on peut en laisser la charge à un cron ou +à systemd à l'aide d'un timer. diff --git a/outils/logiciels/backups/restic.md b/outils/logiciels/backups/restic.md new file mode 100644 index 0000000..9c6207e --- /dev/null +++ b/outils/logiciels/backups/restic.md @@ -0,0 +1,138 @@ +# Restic + +Page officielle de restic : . + +Documentation de restic : . + +Dépôt officiel de restic rest-server : . + +## Présentation + +Restic est un logiciel client/serveur permettant d'effectuer des sauvegardes +incrémentales, dédupliquées et chiffrées par le client. Différents serveurs +sont utilisables par le client, nous présenterons ici le serveur REST de restic +utilisant le protocole HTTP, qui est installé actuellement au Crans sur +[thot](../../../infrastructure/machines/physiques/thot.md). + +Pour la configuration d'un client, vous aurez besoin d'installer le paquet +`restic` sur les machines sous debian, restic étant déjà packagé dans nixpkgs +pour les machines sous NixOS. + +## Configuration du serveur + +Le choix le plus simple à mettre en place pour la partie serveur de restic est +restic rest-server, très simple à mettre en place. Vous pouvez trouver la +configuration actuelle dans le module restic du +[dépôt NixOS](https://gitlab.crans.org/nounous/nixos). + +Le fonctionnement de ce serveur REST est le suivant : le client compresse et +chiffre ses données avec un mot de passe, vient s'authentifier en +[basic auth](https://en.wikipedia.org/wiki/Basic_access_authentication) auprès +du serveur, puis dépose la backup au fur et à mesure de son avancée sur le +serveur. Chaque client dispose donc de deux mots de passe : une clef de +chiffrement pour les données, ainsi qu'un mot de passe pour s'authentifier +auprès du serveur REST. + +Deux notions sont importantes à comprendre ici dans la configuration du serveur +REST. + +- L'option `privateRepos`/`--private-repos` : permet de faire en sorte qu'un⋅e + utilisateurice (dans notre cas une machine) ne puisse accéder qu'à ses + propres backups et puisse créer tous les dépôts souhaités dans un sous + dossier à son nom. Ainsi, une fois authentifiée, la VM flirt aura accès à + tous dépôt de la forme `restic:http://thot.adm.crans.org/flirt/`, ce + qui est particulièrement pratique pour ne pas avoir à gérer les accès à la + main pour chaque machine. +- Les clients sont authentifiées par le serveur grâce à un fichier `.htpasswd` + situé à la racine du dossier de données. Ainsi, si le dossier de données est + `/backups`, le fichier d'authentification sera `/backups/.htpasswd`. Ce + fichier est un fichier d'authentification standard : vous pouvez consulter la + [page Wikipédia](https://en.wikipedia.org/wiki/.htpasswd) dédiée pour plus + d'informations. Vous pouvez alors ajouter une machine à ce fichier avec la + commande : + + ```bash + sudo htpasswd -B /backups/.htpasswd [] + ``` + + Si le mot de passe n'est pas spécifié, il sera alors demandé sur l'entrée + standard. + +## Configuration du client + +Théoriquement, restic est uniquement un logiciel qui s'utilise directement. +Cependant, nous souhaitons faire des sauvegardes automatiquement en utilisant +des systemd timer, on va donc créer plusieurs fichiers pour ne pas à avoir tout +à spécifier directement dans les lignes de commande. + +Actuellement, la configuration des clients restic se situe dans le dossier +`/etc/restic` sous debian, et dans le +[dépôt NixOS](https://gitlab.crans.org/nounous/nixos) pour les machines sous +NixOS. Dans les deux cas, on retrouve les mêmes éléments (on donne les noms +pour la configuration par défault des machines sous debian) : + +- un fichier d'environnement `base.env`, contenant plusieurs variables d'environnement + dont l'utilité précise peut être trouvée dans + [la documentation de restic](https://restic.readthedocs.io/en/stable/040_backup.html#environment-variables). +- un fichier `base-repo` contenant la position du dépôt (serveur REST), avec + les identifiants de connexion, qui se présente sous la forme + `restic:http://:@thot.adm.crans.org//base`. +- un fichier `base-password` contenant le mot de passe de chiffrement des + sauvegardes. +- deux fichiers `base-includes` et `base-excludes` indiquant respectivement les + dossiers inclus et exclus pour les sauvegardes. + +En plus de cela, on trouve un service systemd `restic-base` ainsi qu'un timer +associé dans le dossier `/etc/systemd/system/`. Ce service lancera deux +commandes : une commande pour lancer une sauvegarde, et une commande pour +supprimer les anciennes sauvegardes qui ne seront pas gardées en tant que +sauvegarde journalière/hebdomadaire/mensuelle/annuelle (définies par la +configuration). + +## Initialiser un dépôt + +En supposant que vous avez la configuration décrite ci-dessus, vous pouvez +initialiser un dépôt grâce à la commande suivante : + +```bash +restic init --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password +``` + +## Faire une sauvegarde à la main + +Pour faire une sauvegarde à la main, rien de compliqué, il suffit de lancer le +service systemd normalement de la manière suivante : + +```bash +sudo systemctl start restic-base.service +``` + +(Même si c'est surprenant, vous pouvez faire CTRL+C à ce moment dans votre +terminal, la tâche continuera en fond.) + +De plus, si la variable `RESTIC_PROGRESS_FPS` a été affectée à une valeur +strictement positive, vous pourrez voir la progression de la sauvegarde dans +le journal. Vous pouvez donc y accéder par la commande : + +```bash +sudo journalctl -xefu restic-base +``` + +## Consulter l'état des sauvegardes + +Pour consulter la liste actuelle des sauvegardes, vous pouvez simplement +utiliser la commande : + +```bash +restic snapshots --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password +``` + +De plus, vous pouvez facilement monter une sauvegarde sur un point de montage +avec la commande suivante : + +```bash +restic mount /mnt --repository-file /etc/restic/data-repo --password-file /etc/restic/data-password +``` + +Cela bloquera alors votre terminal, et la sauvegarde sera démontée dès que vous +quitterez votre terminal, évitant d'avoir une sauvegarde montée et oubliée. diff --git a/services/borg.md b/services/borg.md deleted file mode 100644 index 6b0c7b1..0000000 --- a/services/borg.md +++ /dev/null @@ -1,164 +0,0 @@ -# Borg - -Pour prevenir certains incidents dus à des erreurs de manipulation, le collège -technique a mis en place en système de backups. Le but de celui-ci est de -pouvoir, si le besoin s'en fait ressentir, aller rechercher un fichier supprimé -ou écrasé. Bien qu'il serait possible de simplement faire une copie périodique -des données sur un serveur distant, on lui préfère des solutions un peu plus -développées qui permettent de faire des sauvegardes incrémentales. Fut un temps, -la solution technique en place était le logiciel -[BackupPC](https://backuppc.github.io/backuppc/), cependant celui-ci commençant -à dater et ayant une faible ergonomie, nous utilisons aujourd'hui le logiciel -[borg](https://borgbackup.readthedocs.io/en/stable/) et son frontend -[borgmatic](https://torsion.org/borgmatic/). - -Avant de présenter ce logiciel, attardons nous un peu sur ce qu'on entend par -faire des backups incrémentales. Pour cela revenons à notre piètre solution -initiale qui consiste à copier (à grands coups de rsync, unison, scp…) toutes -les données que l'on souhaiterait sauvegarder. Pour que ces sauvegardes soient -utiles, il faut les réaliser assez fréquemment (quelque part entre un jour et -une semaine disons). Cependant, à chaque nouvelle backup réalisée, celle-ci va -venir écraser le contenu de la précédente et ainsi, on ne dispose jamais plus -que d'une copie des données de la veille. Ainsi, des dysfonctionnements -automatiques ou simplement de la négligence peuvent faire que l'on ne se rendra -compte que l'on avait besoin de récupérer notre fichier il y a déjà quelques -jours et qu'il a maintenant déjà été supprimé de la copie de sauvegarde. On -préfererait donc pouvoir disposer d'une collection de sauvegardes qui remonte -sur quelques jours voir moi en fonction de la politique de rétention de -sauvegarde qu'on mettrait en place. Par exemple, une sauvegarde pour chacun des -septs derniers jours puis quelques unes espacée d'une semaine. Si l'on reprend -notre solution naïve, on peut facilement en étendre l'usage pour ce nouvel -office : on réalise une copie complète des données par jour que l'on souhaite -sauvegarder. Suivant la politique de rétention que l'on a donné plus tôt cela -consisterais en une quinzaine de copies distinctes des données à sauvegarder et -donc une multiplication par quinze de la taille de celle-ci. Si je jette un œil -rapide à la taille que prends aujourd'hui les données utilisateur⋅ices, je vois -qu'on utilise un peu plus de 2.5T de stockage, donc si l'on suit la logique, on -devrait disposer d'une ou plusieurs machines totalisant un stockage d'environ -40T. Inutile de le dire je pense, mais cela fait (beaucoup) trop. Heureusement -pour nous, d'un jour sur l'autre l'intégralité de nos données stockées ne varie -pas et seule une petite partie change sur le cours d'une journée. Ainsi, si l'on -ne stocke que les différences accumulé sur une journée par rapport à la veille, -on se retrouvera avec une taille beaucoup plus raisonnable de sauvegarde. C'est -~la déduplication. - -## Qu'est ce que l'on sauvegarde ? - -Au crans, on sauvegarde deux types de données : - -* D'un côté, on a les données d'administration, c'est une partie des disques - de tous les serveurs (généralement le /etc et le /var sauf cas particulier), - le home des nounous, les bases de données… - -* De l'autre côté; on a les données des adhérents, c'est à dire : le contenu - de leur répertoire personnel et de leur dossier mail qui au jour où j'écris - ses lignes peut contenir au maximum 30G et 10G de données respectivement. - -Même si les deux types de sauvegardes sont fait avec borg/borgmatic, la manière -dont les sauvegardes sont effectivement lancé varie entre les deux. Je -m'attarderais ici plus sur le fonctionnement générale de borg/borgmatic et donc -je présenterais le cas de la sauvegarde de données administratives qui est une -utilisation assez normale du logiciel. L'explication de comment se passe les -sauvegardes pour les données adhérents est disponible [ici](services/borg.md). - -## Borg et borgmatic - -Borg est un logiciel client/serveur permettant d'effectuer des sauvegardes -incrémentales, dédupliquées et chiffrées par le client. Le serveur est simple à -installer et utilise ssh comme protocole de transport entre lui et le client. -Ainsi, il suffit de donner un accès ssh au client via une paire de clés pour lui -autoriser à discuter avec le serveur. Quelque chose ressemblant à ça dans le -`.ssh/authorized_keys` de l'utilisateur sur le serveur qui fera les backups : - -```txt -command="borg serve --restrict-to-path {{ chemin vers les sauvegardes }}",restrict {{ clé publique ssh }} -``` - -Avec l'installation du paquet `borg` c'est la seule chose à faire sur le serveur -et le reste du travail sera réalisé par le client. Après avoir aussi installé -`borg` sur le client, on peut déjà commencer à faire quelques sauvegardes. -Cependant, si l'on utilise que borg pour les faire (ce qui est possible), on se -retrouvera avec des commandes bien trop longues dans lesquels on passe notre -temps à spécifier des arguments plusieurs fois : comment contacter le serveur ? -où stocker les sauvegardes ? quel politique de rétentions garder ? que faut-il -sauvegarder ? Borgmatic est un frontend de borg qui définir une bonne fois pour -toutes ses options dans un fichier de configuration pour ensuite n'avoir plus -qu'à faire des appels simples à borgmatic qui pasera à borg tous les paramètres -dont il a besoin. Le but n'est pas ici d'être exhaustif sur ce que peut/doit -contenir ce fichier de configuration. Je vous redirige pour ça vers la -[documentation -officielle](https://torsion.org/borgmatic/docs/reference/configuration/). Ici, -je vais plus chercher à vous donner quelques options minimales et des exemples -d'utilisations de borgmatic. Commençons par donner le contenu d'un fichier de -configuration partiel : - -```txt -location: - source_directories: - - /etc - - /var - repositories: - - borg@backup-server:/folder/to/bacup/to - -storage: - encryption_passphrase: PASSPHRASE - ssh_command: ssh -i /etc/borgmatic/id_ed25519_borg - -retention: - keep_daily: 4 - keep_monthly: 6 -``` - -Dans la section `location`, on définit deux choses : ce que l'on souhaite -sauvegarder et où on souhaite le sauvegarder. Ici on va backupé le `/etc` et -`/var` de notre client sur un serveur distant qu'on contactera via ssh. Dans la -section suivante, `storage`, on définit quelques options relatives au stockage -et à comment y accéder. Premièrement, on donne la passphrase de chiffrement des -sauvegardes (attention, si elle est perdue, les sauvegardes ne seront plus -accessibles). Ensuite, on précise comment accéder au serveur (ici, l'information -importante est où se trouve la clé privée pour pouvoir se connecter). Enfin, -dans la section retention, on définit notre politique de retention : le serveur -ne doit stocker qu'une backup quotidienne sur les 4 derniers jours, et une -backup mensuelle sur les 6 derniers mois. - -En supposant les autres options de fonctionnement renseignées dans le fichier, -que je ne détaillerais pas ici, il est maintenant possible de commencer à -utiliser le logiciel et faire nos premières sauvegardes. - -### Créer l'archive de stockage - -La commande suivante permet de créer l'archive où seront stockées les -sauvegardes sur le serveur. - -```bash -borgmatic init -e repokey -``` - -### Faire une première sauvegarde - -Pour faire une sauvegarde, rien de plus simple, on appelle simplement le -programme borgmatic sans option. Il est néanmoins possible de demander un -affichage plus verbeux pour le débogage. - -```bash -borgmatic -borgmatic -v 2 -``` - -### Lister les différentes sauvegardes dans l'archive - -```bash -borgmatic list -``` - -### Monter une sauvegarde précise sur un point de montage - -```bash -borgmatic mount --archive {{ nom de l'archive ou latest pour la dernière }} --mount-point /mnt --path {{ chemin à monter de l'archive }} -borgmatic mount --archive latest --mount-point /mnt --path etc/nginx/nginx.conf -``` - -### Automatiser les backups - -Pour réaliser des backups périodique, on peut en laisser la charge à un cron ou -à systemd à l'aide d'un timer.