Remplacement des liens cassés, ajout documentations scripts pythons et imprimante

infrastructure/machines/qui_est_qui.md

@@ -391,6 +391,12 @@ Redémarrage et mise à jour automatique.
 
 OS : debian Bookworm
 
+### neo : matrix
+
+C'est la machine virtuelle qui héberge l'instance Matrix du crans.
+
+OS : nixos
+
 ### neree : galene
 
 C'est le serveur galene du Crans, l'un des deux logiciels qu'on utilise pour
@@ -444,6 +450,12 @@ Redémarrage et mise à jour automatique.
 
 OS : debian Bullseye
 
+### periodique : element
+
+C'est le serveur qui héberge element (le client web de matrix)
+
+OS : nixos
+
 ### ptf : la mémoire (fatiguée)
 
 C'est le serveur ftp sur lequel est hébergé les vidéos des installs party du

infrastructure/reseaux/dns.md

@@ -17,12 +17,12 @@ L'automatisation est gérée par un script python disponible sur le
 
 ### Configuration générique
 
-Il s'agit de la partie automatisé de la configuration du DNS. En effet, lorsque
+Il s'agit de la partie automatisée de la configuration du DNS. En effet, lorsque
 vous ajoutez une nouvelle machine dans le ldap, par exemple en suivant le
-[guide d'installation](../../howto/reer_vm_crans.md), vous avez ajouté plusieurs
+[guide d'installation](../../howto/creer_vm_crans.md), vous avez ajouté plusieurs
 informations :
 
-* Créer l'entrée <machine>.<vlan>.crans.org et/ou <machine>.crans.org
+* Créer l'entrée `<machine>.<vlan>.crans.org` et/ou `<machine>.crans.org`
 * L'adresse IP (v4 et v6)
 * Un (ou plusieurs) nom(s)
 
@@ -32,7 +32,7 @@ ses alias les adresses IP v4 et v6 configurées.
 ### Remarques
 
 Pour la configuration des services du crans ([pad](https://pad.crans.org),
-[framadate](https://framadate.crans.org)), etc...), les noms `pad` et
+[framadate](https://framadate.crans.org), etc...), les noms `pad` et
 `framadate` doivent être configurés pour pointer sur le reverse proxy. Ainsi,
 ils sont considérés comme des alias du reverse proxy dans le ldap.
 

outils/logiciels/ansible.md

@@ -53,6 +53,14 @@ Certains fichiers de configuration contiennent des secrets. Ceux-ci sont alors
 dans le pass du crans. Il est donc nécessaire d'installer le pass du crans
 comme indiqué sur le git.
 
+### Des modules en plus
+
+Pour exécuter certaines configurations, des modules peuvent être nécessaires.
+Voici une liste non exhaustives des modules pythons supplémentaires à
+installer :
+
+- jmespath
+
 ### Configuration de ssh
 
 Il faudra copier coller cette configuration ssh dans `~/.ssh/config` en
@@ -96,7 +104,7 @@ l'architecture du git
 - `roles` : il s'agit du dossier qui contient l'ensemble des fichiers de
   configurations ainsi que les commandes à exécuter.
 
-:bulb: Pour utiliser des variable de groupe, il faut que la machine soit dans
+:bulb: Pour utiliser des variables de groupe, il faut que la machine soit dans
 le groupe correspondant dans `hosts`
 
 ### Configuration basique

outils/logiciels/ssh.md

@@ -63,20 +63,20 @@ Are you sure you want to continue connecting (yes/no/[fingerprint])?
 
 Il est de bon usage de confirmer l'authenticité de cette clef afin de ne pas
 être vulnérable aux attaque de type Man in the Middle. Pour celà il y a une
-solution : l'administrateur du serveur doit vous confirmer l'empreinte
+solution : l'administrateur⋅ice du serveur doit vous confirmer l'empreinte
 (fingerprint) de la clef par un moyen sécurisé. Voici une liste non
 exhaustive de moyens plus ou moins sécurisés :
 
-* Si vous êtes vous-même l'administrateur du serveur la commande `for key in
+* Si vous êtes vous-même l'administrateur⋅ice du serveur la commande `for key in
   /etc/ssh/ssh_host_*.pub; do ssh-keygen -lf ${key}; done` sur le serveur pour
   afficher les empreintes de vos clefs.
 
-* Se faire confirmer la clef oralement par l'administrateur.
+* Se faire confirmer la clef oralement par l'administrateur⋅ice.
 
-* Se faire confirmer la clef par un mail d'un administrateur de confiance
+* Se faire confirmer la clef par un mail signé GPG d'un⋅e administrateur⋅ice de
-  signé GPG.
+  confiance.
 
-* Utiliser des clefs stockées dans le [DNS](/tools/dns.md) et signées
+* Utiliser des clefs stockées dans le [DNS](/outils/protocoles/dns.md) et signées
   DNSSEC, ceci peut se faire en ajoutant l'option `-oVerifyHostKeyDNS=yes` à
   `ssh`.
 

outils/protocoles/http.md

@@ -3,5 +3,5 @@
 HTTP (Hypertext Transfer Protocol) est un protocole permettant de servir un
 site web. Il utilise le port 80.
 
-Sa version sécurisé (HTTPS) consiste en une intégration de
+Sa version sécurisée (HTTPS) consiste en une intégration de
-[TLS](tools/tls.md) au protocole et utilise le port 443.
+[TLS](./tls.md) au protocole et utilise le port 443.

outils/protocoles/ip.md

@@ -35,7 +35,7 @@ par exemple pour le bloc `192.168.0.0/24`, l'adresse `192.168.0.0` est
 réservée et l'adresse `192.168.0.255` est l'adresse de broadcast.
 
 Cette restriction peut être contournée sous Linux, par exemple sous
-[Debian](/tools/debian.md) on peut modifier l'interface comme ceci :
+[Debian](/outils/os/debian.md) on peut modifier l'interface comme ceci :
 
 ```txt
 iface eth0 inet static

services/imprimante.md

@@ -0,0 +1,30 @@
+# Imprimante
+
+## Fonctionnement
+
+### Site web
+
+Le site de l'imprimante utilise le framework django. Le code source est
+disponible sur le [gitlab](https://gitlab.crans.org/nounous/django-printer).
+
+### Gestion des scans
+
+Le scan est géré par un script python disponible sur le [gitlab du
+crans](https://gitlab.crans.org/nounous/scanner).
+
+Il est géré par le systemd `scanner`. Il se charge d'établir une connexion
+avec l'imprimante puis de récupérer les documents scannés et de les écrire
+sur le serveur afin de le rendre accessible depuis la page web. Cependant,
+La création des shortcuts de l'imprimante pour le scan est géré par le site
+django.
+
+### Gestion des impressions
+
+Les impressions sont gérées par cups depuis le site django.
+
+## Installation
+
+- [Installation du site](https://gitlab.crans.org/nounous/django-printer) en
+  suivant le `README.md`.
+- [Installation du script](https://gitlab.crans.org/nounous/scanner) pour le
+  scanner en suivant le `README.md`.

services/monitoring/ninjabot.md

@@ -1,6 +1,6 @@
 # NinjaBot
 
-NinjaBot est un bot [IRC](/tools/irc.md) qui permet d'envoyer des notifications
+NinjaBot est un bot [IRC](/outils/protocoles/irc.md) qui permet d'envoyer des notifications
 en temps réel sur des canaux de discussion, ses sources sont disponibles
 [ici](https://gitlab.crans.org/nounous/NinjaBot).
 

services/networking/isc-dhcp-server.md

@@ -1,7 +1,7 @@
 # ISC-DHCP-SERVER
 
 ISC-DHCP-SERVER est une implémentation du protocole DHCP qui permet à un
-hôte  via une requète DHCP au serveur de récupérer une adresse IP, des
+hôte via une requête DHCP au serveur de récupérer une adresse IP, des
 informations à propos des dns et l'adresse de la passerelle. Il est
 actuellement un peu vieillisant mais il est très robuste, il est envisagé de
 le remplacer par son successeur kea quand il sera plus stable.
@@ -16,8 +16,8 @@ client.
 Le protocole DHCP fonctionne de la manière suivante :
 
 1. le client qui cherche à configurer son interface réseaux envoie une
-   requète DHCPDISCOVER sur le lien en broadcast avec comme adresse cible
+   requête DHCPDISCOVER sur le lien en broadcast avec comme adresse cible
-   255.255.255.255 en spécifiant son adresse MAC dans la requète
+   255.255.255.255 en spécifiant son adresse MAC dans la requête
 
 1. le serveur vérifie s'il est configuré pour répondre au client :
 
@@ -26,7 +26,7 @@ Le protocole DHCP fonctionne de la manière suivante :
    * sinon il lui fait une offre cohérente par rapport à sa configuration et
      son état actuel via un paquet DHCPOFFER
 
-1. le client lui répond avec une requète DHCPREQUEST dans lequel il précise
+1. le client lui répond avec une requête DHCPREQUEST dans lequel il précise
    l'adresse qu'il souhaiterait que le serveur dhcp lui alloue
 
 1. le serveur statue finalement sur l'adresse qu'il alloue effectivement au
@@ -52,9 +52,9 @@ améliorer la sécurité de notre infrastructure en précisant l'adresse de
 notre serveur dhcp permettant au switch de bloquer les acquittements dhcp
 excepté celle provenant de nos serveurs.
 
-Certains switchs permettent aussi de configurer certains ports qu'il interdit
+Certains switchs permettent aussi de configurer certains ports pour qu'ils
-au machines derrière de communiquer avec une autre adresse que celle qu'elles
+interdisent aux machines de communiquer avec une autre adresse que celle
-ont récupéré par dhcp.
+qu'elles ont récupéré par dhcp.
 
 ## Installation
 
@@ -147,6 +147,14 @@ options.
 INTERFACESv4="ens22 ens23 ens1 enp1s3"
 ```
 
-Attention pour que le serveur démarre effectivement, il faut que interfaces
+Attention pour que le serveur démarre effectivement, il faut que les interfaces
-listées ici soit bien démarrées et dispose d'une ipv4, sinon celui-ci refusera
+listées ici soient bien démarrées et disposent d'une ipv4, sinon celui-ci refusera
 de se lancer.
+
+### Mise à jour de la configuration
+
+Depuis que le crans ne fournit plus internet à ces adhérent⋅es, le dhcp ne sert
+plus qu'à fournir les adresses IP au VM des adhérent⋅es. Le DHCP fournit alors
+l'adresse IP contenu dans le LDAP adhérent. Pour synchroniser le LDAP et le
+DHCP, le cron `services-dhcp` exécute toutes les 2 minutes un [script
+python](./services/dhcp.md)

services/networking/keepalived.md

@@ -22,7 +22,7 @@ s'affectera les ressources.
 
 ## Installation
 
-On se contente de tirer le logiciel des repositorys debian
+On se contente de tirer le logiciel des repositoires debian
 `sudo apt install keepalived`. Il y est packagé (correctement) depuis Jessie.
 
 ## Configuration
@@ -30,7 +30,7 @@ On se contente de tirer le logiciel des repositorys debian
 Il est fortement recommandé de sortir le `man 5 keepalived.conf` qui détaille
 assez bien les différents cas d'utilisation du logiciel.
 
-Le logiciel nous permet de définir quelques options générale dans la section
+Le logiciel nous permet de définir quelques options générales dans la section
 global_defs. En particulier on peut y préciser le nom de la machine et la
 configuration de l'envoi de mail :
 
@@ -43,12 +43,12 @@ global_defs {
 }
 ```
 
-On peut ensuite rentré dans la configuration des instances. Une instance
+On peut ensuite rentrer dans la configuration des instances. Une instance
 correspond à un bloc de ressource que l'on souhaite partagé entre deux
 machines. Comme les protocoles sous-jacent sont distincts en ipv4 et en ipv6,
 la  configuration pour des ressources ipv4 et ipv6 se fait dans des blocs
 différents. Dans une instance, on doit préciser la priorité de la machine
-dans l'instance, l'interface surlaquelle se font les alertes vrrp,
+dans l'instance, l'interface sur laquelle se font les alertes vrrp,
 l'identifiant de l'instance et un bloc définissant les ressources qui sont
 partagées. Il est aussi possible de définir un script qui sera appelé au
 changement d'état. On donne ici l'exemple d'une instance en ipv4.
@@ -80,11 +80,11 @@ vrrp_instance VI_ALL {
 
 ### Script de changement d'état
 
-Comme préciser dans la section précédente, il est possible d'appeler un
+Comme précisé dans la section précédente, il est possible d'appeler [un
-script  lors des changements d'état de l'instance. Keepalived appelera alors
+script](https://gitlab.crans.org/nounous/keepalived/) lors des changements
-le script avec les paramètres suivant :
+d'état de l'instance. Keepalived appelera alors le script avec les paramètres
-`script [TYPE] [NAME] [STATE] [PRIORITY]` où `[TYPE]` vaut `INSTANCE` dans
+suivant : `script [TYPE] [NAME] [STATE] [PRIORITY]` où `[TYPE]` vaut `INSTANCE`
-notre cas, `[NAME]` donne le nom de l'instance concernée, `[STATE]` donne
+dans notre cas, `[NAME]` donne le nom de l'instance concernée, `[STATE]` donne
 l'état vers lequel on transitionne et `[PRIORITY]`  la  priorité dans
 l'instance.
 

services/networking/nftables.md

@@ -352,4 +352,4 @@ l'aide de la commande `nft monitor`
 
 * Il est possible d'utiliser des variables dans un fichier de configuration.
   Leur valeur sera substituée lors de la lecture du fichier. Un exemple est
-  donné dans le fichier `services/firewall.md`.
+  donné dans le fichier [firewall](./services/firewall.md).

services/networking/prefix_delegation.md

@@ -1,31 +1,33 @@
 # Délégation de préfixe IPv6
 
 La longueur des adresses IPv6 (128 bits) nous permet de déléguer des
-préfixes (c'est à dire des sous-réseaux) IPv6.
+préfixes (c'est-à-dire des sous-réseaux) IPv6.
 
 Il est possible de fournir des préfixes grâce au protocole DHCPv6 mais cette
 solution n'a pas été privilégiée au Crans : nous lui avons préféré une
 attribution statique.
 
 Dans [Re2o](/services/re2o.md) une application Django, `prefix_delegation`, a
-été écrite permettant notamment d'attribuer des préfixes IPv6 de taille
+été écrite permettant notamment d'attribuer des préfixes IPv6 de taille fixée
-fixée à des utilisateurs.
+à des utilisateurs.
 
 Dans cette application il est possible de définir des sous-réseaux IPv6 ainsi
-que le taille des préfixes contenus dans ces sous-réseaux puis de créer des
+que la taille des préfixes contenus dans ces sous-réseaux puis de créer des
-préfixes et de les attribuer à des adhérents en leur assignant des
+préfixes et de les attribuer à des adhérent⋅es en leur assignant des
-passerelles (machine de l'adhérent à contacter pour router ce préfixe).
+passerelles (machine de l'adhérent⋅e à contacter pour router ce préfixe).
 
-L'application fourni une API Rest HTTP permettant au script `prefix_delegation`
+L'application fourni une API Rest HTTP permettant [au script
-de rafraîchir la liste des préfixes et de leur passerelle dans le noyau de la
+prefix_delegation](https://gitlab.crans.org/nounous/prefix_delegation) de
+rafraîchir la liste des préfixes et de leur passerelle dans le noyau de la
 VM de routage.
 
 Ce script utilise un protocole particulier pour gérer ses routes, ce protocole
-est défini dans `/etc/iproute2/rt_protos.d` sur les machines où le script des
+est défini dans `/etc/iproute2/rt_protos.d` sur les machines où le script est
 déployé.
 
-Le reverse [DNS](/tools/dns.md) est également délégué : des serveurs DNS
+Le reverse [DNS](/outils/protocoles/dns.md) est également délégué : des
-peuvent être attribués à un ou plusieurs préfixes afin de résoudre les
+serveurs DNS peuvent être attribués à un ou plusieurs préfixes afin de résoudre
-adresses IPv6 délégués vers des noms de domaines choisis par l'adhérent. Il
+les adresses IPv6 délégués vers des noms de domaines choisis par l'adhérent⋅e.
-est même possible de configurer du DNSSEC pour le reverse DNS. Ceci est géré
+Il est même possible de configurer du DNSSEC pour le reverse DNS. Ceci est géré
-par le script `dns` sur la VM `silice`.
+par [le script dns](https://gitlab.crans.org/nounous/dns/) sur la VM
+`silice`.

services/networking/services/dhcp.md

@@ -1,10 +1,10 @@
 # Services DHCP
 
 Le script de services DHCP permet de générer des fichiers de bails statiques
-pour [/critical/networking/isc-dhcp-server](isc-dhcp-server) à partir de la base
+pour [/services/networking/isc-dhcp-server.md](isc-dhcp-server) à partir de la
-de données d'adhérent du crans. Actuellement celle ci est gérée par re2o donc on
+base de données d'adhérent du crans. Actuellement, celle ci est gérée par re2o
-fait des requêtes à l'API de re2o pour récupérer la liste des machines des
+donc on fait des requêtes à l'API de re2o pour récupérer la liste des machines
-adhérents.
+des adhérent⋅es.
 
 ## Installation
 

services/networking/services/firewall.md

@@ -1,6 +1,6 @@
 # Pare-feu
 
-Voir `/critical/networking/nftables.md` pour une documentation minimale sur
+Voir [nftables](../nftables.md) pour une documentation minimale sur
 nftables.
 
 Voici un pare-feu basique dans lequel des adhérent·e·s se trouvent derrière un

services/re2o.md

@@ -8,7 +8,19 @@ sur le [GitLab FedeRez](https://gitlab.federez.net/re2o/re2o).
 
 Re2o permet de gérer la base de données des adhérents et de leur machine
 ainsi que quelques autres objets tels que les définitions des zones
-[DNS](/tools/dns.md).
+[DNS](/outils/protocoles/dns.md).
 
-Il est déployé sur la VM `re2o` et est joignable en [HTTP](tools/http.md)(S)
+Lorsqu'un⋅e nouvel⋅le adhérent⋅e rejoint le crans, son home doit être créé.
-sur `intranet.crans.org`.
+Un cron sur cameron exécute toutes les minutes un [script python](https
+://gitlab.crans.org/nounous/home) qui s'occupe de créer les homes des
+adhérent⋅es. Il s'occupe notamment de créer le dossier Owncloud, le dossier
+Mail, les quotas et éventuellement des configurations par défaut de certains
+services.
+
+Lorsqu'une adhésion arrive à son terme, le script python [notif-users](https
+://gitlab.crans.org/nounous/notif-users/) envoie automatiquement un mail. Un
+cron sur `zamok` exécute ce script tout les jours. À noter que le cron semble
+avoir été désactivé.
+
+Il est déployé sur la VM `re2o` et est joignable en
+[HTTP](outils/protocoles/http.md)(S) sur `intranet.crans.org`.