diff --git a/crans.texi b/crans.texi
index 092a3fb..29463e8 100644
--- a/crans.texi
+++ b/crans.texi
@@ -55,6 +55,9 @@ The document was typeset with
 
 @menu
 * Comptes rendus::
+* How-Tos::
+* CONTRIBUTING::
+* Tools::
 * Index::
 @end menu
 
@@ -80,6 +83,7 @@ car le tri par date se fait plus simplement).
 * CR Template::
 * 2024 01 13::
 * 2024 06 22::
+* 2024 08 29::
 @end menu
 
 @node CR Template
@@ -403,6 +407,974 @@ Il faut mettre à jour. (On le fera vers juste après l’IN)
 GaBo a été désigné grand gagnant de qui s'occupera de la documentation
 d'Ansible.
 
+@node 2024 08 29
+@section IN du jeudi 29 août 2024
+
+@table @asis
+@item Date
+jeudi 29 août 2024
+@item Lieu
+MB87 et Galène (@url{https://galene.crans.org/group/CA})
+@item Début
+18h58
+@item Fin
+21h
+@end table
+
+@subheading Présent·es
+
+@itemize
+@item
+@url{https://wiki.crans.org/WikiBleizi, bleizi}
+@item
+@url{https://wiki.crans.org/WikiPigeonMoelleux, Pigeon Moelleux}
+@item
+GaBo
+@item
+@url{https://wiki.crans.org/VanilleNiven, vanille}
+@item
+korenst1
+@item
+Lzebulon
+@item
+Shinigami
+@item
+@url{https://wiki.crans.org/WikiHachino, Hachino}
+@item
+underscore_j
+@item
+RDB
+@item
+Otthorn
+@end itemize
+
+@subheading Ordre du jour
+
+@subsection 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.
+
+@verbatim
+server/Common/sources/constant.js
+exports.LICENSE_CONNECTIONS = 20;
+@end verbatim
+
+@subsection é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 :
+@url{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)
+
+@quotation Pigeon
+``IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP''
+@end quotation
+
+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.
+
+@subsection Cephiroth
+
+Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux).
+
+@subsection Serveur matrix
+
+De plus en plus de demande pour avoir une alternative libre à discord, whatsapp@dots{}
+
+
+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"
+
+@subsection 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 !))
+
+@subsection é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)
+
+@subsection 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.
+
+@subsection 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
+
+@subsection Chronolgie TODO list
+
+@table @asis
+@item Très urgent
+@itemize
+@item
+Backup ft (commencé à faire les backup)
+@itemize
+@item
+1/2 qui non important (genre voyager et helloworld)
+@item
+par ordre d'importance (genre mailman)
+@end itemize
+@item
+d'ici là samedi rangement, inté, séminaires
+@item
+Cephiroth (garantie go GaBo)
+@item
+puis on s'occupe de thot
+@end itemize
+
+@item on est déjà dans qq semaines
+@itemize
+@item
+onlyoffice (la limite)
+@item
+bleizi, pigeon -> imprimante
+@item
+les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent
+rester nounous)
+@item
+enlever les vielles nounous (charlie, peb ? et pollion ?)
+@end itemize
+
+@item Le mois prochain
+@itemize
+@item
+prévénir tout le monde que les serveurs du crans sont down
+@item
+Backup tealc sur zéphir/cameron
+@item
+inventaire et commander des disques d'avances (un disque en rab
+compatible pour chacun des serveurs)
+@item
+coupure : recabler, (vérifier l'étiqueteuse)
+@item
+PASSER LA POOL EN 4096
+@item
+réinstaller tealc
+@end itemize
+
+@item Après
+@itemize
+@item
+voir matrix
+@item
+rediscuter de mastodon
+@item
+Nix
+@end itemize
+
+@item Jamais
+@itemize
+@item
+Constellation
+@item
+Ceph
+@end itemize
+@end table
+
+@node How-Tos
+@chapter 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 à @ref{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 !
+@end menu
+
+@node Changer de pseudo
+@section 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.
+
+@subsection 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 @code{yson-partou} pour
+s'assurer que l'ancien compte a bien été supprimé. Pour cela, faire un
+@code{sudo shelldap} sur @code{yson-partou}, puis taper
+@code{cn=Utilisateurs} et s'assurer que @code{cat cn=ancienpseudo} ne
+renvoie rien.
+
+@subsection 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
+@code{sudo mv /home/@{ancienpseudo,nouveaupseudo@}}, sinon avec l'accord
+de la personne on peut faire un @code{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 @file{/var/mail/ancienpseudo} en
+@file{/var/mail/nouveaupseudo}, ou déplacer le contenu et supprimer
+l'ancien dossier.
+
+@subsection Backups
+
+Étape non pressante, mais on peut se rendre sur @code{backup-ft} et
+@code{backup-thot} pour déplacer
+@file{/backup/borg-adh/home/ancienpseudo} en
+@file{/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.
+
+@subsection 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 : @url{https://gitlab.crans.org/admin/users}.
+
+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.
+
+@subsection 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 :
+@url{https://owncloud.crans.org/settings/users}, 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é.
+
+@subsection Mailman
+
+On commence par se rendre dans @url{https://lists.crans.org/admin/,
+Django-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.
+
+@subsection Wiki
+
+Si la connexion par le CAS est configurée, il faut penser à @code{mv
+/var/local/wiki/assowiki/@{ancienpseudo,nouveaupseudo@}}. Concerne a
+priori peu de monde.
+
+@subsection The Lounge
+
+Si on tient à ne pas perdre sa connexion WebIRC (si concernée), on peut
+aller sur Zamok et @code{mv
+/etc/thelounge/users/@{ancienpseudo,nouveaupseudo@}.json} Il y a aussi
+des fichiers de d'historiques des messages que l'on peut supprimer
+@code{rm /etc/thelounge/logs/@{pseudo@}} et @code{rm
+/etc/thelounge/logs/@{pseudo@}.sqlite3} ou remommer.
+
+@node Creer VM adherent
+@section 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.
+
+@multitable @columnfractions .5 .5
+@headitem Article @tab Tarifs
+@item
+Service minimal
+@tab 10€
+@item
+Connexion Internet
+@tab 30€
+@item
+Cœeur additionnel
+@tab 5€
+@item
+2GB de RAM additionnel
+@tab 5€
+@item
+Disque additionnel (par tranche de 16G)
+@tab 1€
+@end multitable
+
+Le service minimal comprend :
+@itemize
+@item
+n disque de 8H
+@item
+un cœur
+@item
+2G de ram
+@end itemize
+
+Tous les services sont proposés pour une durée de 1 an.
+
+@subsection Utilisateur⋅ices
+
+La documentation pour les utilisateur⋅ices se trouvent sur le
+@url{https://wiki.crans.org/VieCrans/VPS, wiki}.
+
+@subsection Nounous et apprenti⋅es
+
+@subsubsection 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, @dots{}).
+
+@subsubsection 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 :
+
+@verbatim
+ou=users
+├── cn=toto
+└── cn=titi
+ou=clubs
+└── o=rover
+ou=hosts
+├── cn=voyager
+└── cn=curiosity
+@end verbatim
+
+Pour référence ma configuration @code{shelldap} pour me connecter au
+ldap est la suivante :
+
+@verbatim
+# +---------------------------------+
+# | 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
+@end verbatim
+
+et le mot de passe est disponible dans le password-store sous
+@code{ldap-adh}.
+
+@subsubsection Utilisateur⋅ices
+
+Les objets utilisateur⋅ices dispose des champs suivants :
+
+@verbatim
+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$…
+@end verbatim
+
+Le script @code{addadherent} du repo
+@url{https://gitlab.crans.org/nounous/crans-ldap, crans-ldap} permet
+néanmoins de configurer la plupart des informations à renseigner :
+
+@verbatim
+[ _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
+@end verbatim
+
+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.
+
+@subsubsection 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 :
+
+@verbatim
+dn: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
+objectClass: organization
+objectClass: top
+description: toto
+o: rover
+@end verbatim
+
+Similairement, un script permet de rajouter ces informations
+automatiquement au ldap :
+
+@verbatim
+[ _shirenn@flirt ]$ ./addclub rover
+Pseudo du responsable: toto
+Pseudo du responsable: titi
+Pseudo du responsable:
+@end verbatim
+
+@subsubsection Machines
+
+Les machines sont des objets ldap qui répertorient des informations sur
+leur configuration et leurs propriétaires :
+
+@verbatim
+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
+@end verbatim
+
+Le script @code{addadherenthost} crée la machine dans le ldap
+
+@verbatim
+[ _shirenn@flirt ]$ ./addadherenthost --ip 185.230.78.199 --mac
+02:a0:00:01:99:02 --vmid 199 --club rover curiosity
+@end verbatim
+
+
+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.
+
+@subsubsection 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 @code{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 @file{/root/.ssh/authorized_keys}
+(en faisant attention à créer le @file{.ssh} avec les bonnes permissions
+@code{mkdir -m 0700 /root/.ssh}) et vous supprimez les mots de passe que
+vous avez rentrer pendant l'installation @code{passwd -d root}).
+
+@node La suppression d'un⋅e utilisateurice
+@section 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
+@url{https://www.cnil.fr/fr/reglement-europeen-protection-donnees/,
+RGPD}. 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.
+
+@subsection 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@dots{}). 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@dots{} 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@dots{}). Si la personne est
+encore adhérente, elle va probablement devoir démissionner de
+l'association.
+
+@subsection Re2o
+
+Il faut bien un début, c'est sur l'intranet qu'on commence par
+supprimer/archiver quelqu'un⋅e.
+
+@subsubsection 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@dots{}) 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).
+
+@subsubsection Supprimer sur Re2o
+
+Il faut aller dans l'interface d'administration
+@url{https://re2o.crans.org/admin/users/user/} 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 @code{yson-partou} pour
+s'assurer que le compte a bien été supprimé. Pour cela, faire un
+@code{sudo shelldap} sur @code{yson-partou}, puis taper
+@code{cn=Utilisateurs} et s'assurer que @code{cat cn=@{pseudo@}} ne
+renvoie rien.
+
+@subsection Zamok
+
+Le plus évident, il faut supprimer le home ainsi que les mails.
+
+Il suffit de faire un @code{sudo rm -rf /home/@{pseudo@}}, pour
+supprimer le home. De même pour les mails dans
+@file{/var/mail/@{pseudo@}}.
+
+@subsection Backups
+
+Étape non pressante, mais on peut se rendre sur @code{backup-ft} et
+@code{backup-thot} pour supprimer
+@file{/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).
+
+@subsection 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 : @url{https://gitlab.crans.org/admin/users}.  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).
+
+@subsection Owncloud
+
+Il suffit simplement de se rendre dans l'interface d'administration,
+section utilisateurices :
+@url{https://owncloud.crans.org/settings/users}, puis de chercher le
+compte et de simplement le supprimer.
+
+@subsection Mailman
+
+On commence par se rendre dans @url{https://lists.crans.org/admin/,
+Django-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 @email{root@@crans.org} le propriétaire par
+défaut, ce qui n'est pas une solution durable).
+
+@subsection Wiki
+
+Si la connexion par le CAS est configurée, il faut penser à @code{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@dots{}), historique
+compris. Pour cela il faut aller sur @code{kiwi} et supprimer le dossier
+contenant la page. Cela peut concerner des personnes n'ayant pas de
+compte crans, mais il faudra le WikiNom.
+
+@subsubsection The Lounge
+
+S’il y a eu une utilisation de WebIRC, on peut aller sur Zamok et
+@code{rm /etc/thelounge/users/@{pseudo@}.json} (configuration), @code{rm
+/etc/thelounge/logs/@{pseudo@}} et @code{rm
+/etc/thelounge/logs/@{pseudo@}.sqlite3} (pour l'historique des
+messages).
+
+@subsubsection 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).
+
+@subsubsection 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@dots{}) qui peuvent contenir des données personnelles. La personne
+devra aller voir les admins de ces services pour supprimer les données.
+
+@node Comment devenir nounou ?
+@section 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 @b{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) :
+
+@verbatim
+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.
+@end verbatim
+
+
+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. @emph{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) ?
+
+@subsection 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 (@pxref{LDAP}).
+
+@subsection Give me the password
+
+Vous avez @b{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:
+
+@enumerate
+@item
+On se souvient du hash de commit courant : @code{HASH=$(git rev-parse
+HEAD)}
+@item
+On ajoute toutes les personnes concernées dans le groupe nounou dans le
+fichier @file{.groups.yml} du store et on commit ces changements
+@code{git commit -m toto1234}.
+@item
+On rechiffre tous les fichiers à rechiffrer @code{cat .last_group.json |
+jq -r '. | with_entries( select(.value | any( .== "nounou"))) | keys[]'
+| xargs pass rans reencrypt}
+@item
+On supprime tous les commits inutiles : @code{git reset --soft $HASH;
+git commit -m 'Coucou les ami⋅es'}
+@item
+On vérifie que ça marche et on push :)
+@end enumerate
+
+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 :(
+
+@subsection Thank you for your services
+
+Au Crans on a @b{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.
+
+@subsubsection 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.
+
+@subsubsection Mailman
+
+Il faut se connecter normalement au logiciel, puis allez dans la section
+admin @url{https://lists.crans.org/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).
+
+@subsubsection Owncloud
+
+Il faut aller dans la zone d'administration et rajouter les
+utilisateur⋅ices au groupe d'administration.
+
+@subsubsection 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.
+
+@subsubsection Kiwi
+
+On édite le fichier de conf du wiki sous @file{/etc/moin/mywiki.py} et
+on rajoute son compte wiki dans la liste des administrateur⋅rices.
+
+@subsubsection IRC
+
+On édite le fichier @file{/etc/inspircd/opers.conf} pour rajouter un
+bloc suivant
+
+@verbatim
+<oper
+    name=<nick>
+    password="<pass-hash>"
+    hash="sha256"
+    host="*"
+    type="Deity"
+    fingerprint="<fingerprint certificat>"
+    autologin="on"
+>
+@end verbatim
+
+
+Où le hash du mot de passe peut être obtenu en envoyant @code{/quote
+mkpasswd hmac-sha256 <password>}. 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 ^^).
+
+@subsubsection Mails
+
+Il faut maintenant vous rajouter en alias de
+@email{root@@crans.org}. C'est le début du spam. Pour ce faire,
+rendez-vous sur le dépôt Gitlab @code{mail-aliases}, et ajoutez votre
+pseudo Crans sur la bonne ligne dans les bons fichiers, en face de
+@code{root:}.  Pensez ensuite à mettre à jour le dépôt pour le service
+@code{mail}, et enfin mettez bien à jour @code{redisdead},
+@code{sputnik} et surtout @code{zamok} dans le dossier
+@file{/var/local/services/mail}. Enfin, pensez bien à filtrer les mails
+arrivant à l'adresse @email{root@@crans.org} sur votre client.
+
+Voilà, tu as maintenant gagné le droit de t'ajouter ou de te retirer de
+@url{<https://wiki.crans.org/CransNounous} !
+
+@node CONTRIBUTING
+@chapter Contributing
+
+TODO.
+
+@node Tools
+@chapter Tools
+
+@menu
+* LDAP::
+@end menu
+
+@node LDAP
+@section LDAP
+
+TODO.
+
 @node Index
 @unnumbered Index