diff --git a/howto/creer_vm_adherent.md b/howto/creer_vm_adherent.md index cf39fcc..5ac7a72 100644 --- a/howto/creer_vm_adherent.md +++ b/howto/creer_vm_adherent.md @@ -171,7 +171,7 @@ 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`). +à 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 diff --git a/infrastructure/machines/qui_est_qui.md b/infrastructure/machines/qui_est_qui.md index fdbabf6..179b4e2 100644 --- a/infrastructure/machines/qui_est_qui.md +++ b/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 diff --git a/infrastructure/reseaux/dns.md b/infrastructure/reseaux/dns.md index e30a518..54f6b92 100644 --- a/infrastructure/reseaux/dns.md +++ b/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 ..crans.org et/ou .crans.org +* Créer l'entrée `..crans.org` et/ou `.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. diff --git a/outils/logiciels/ansible.md b/outils/logiciels/ansible.md index 22a57fe..20c388b 100644 --- a/outils/logiciels/ansible.md +++ b/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 diff --git a/outils/logiciels/ssh.md b/outils/logiciels/ssh.md index 7c2b824..0069e02 100644 --- a/outils/logiciels/ssh.md +++ b/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 - signé GPG. +* Se faire confirmer la clef par un mail signé GPG d'un⋅e administrateur⋅ice de + 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`. diff --git a/outils/protocoles/http.md b/outils/protocoles/http.md index dba99f9..3b6efb5 100644 --- a/outils/protocoles/http.md +++ b/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 -[TLS](tools/tls.md) au protocole et utilise le port 443. +Sa version sécurisée (HTTPS) consiste en une intégration de +[TLS](./tls.md) au protocole et utilise le port 443. diff --git a/outils/protocoles/ip.md b/outils/protocoles/ip.md index 455639d..958a017 100644 --- a/outils/protocoles/ip.md +++ b/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 diff --git a/services/imprimante.md b/services/imprimante.md new file mode 100644 index 0000000..14e225b --- /dev/null +++ b/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`. diff --git a/services/monitoring/ninjabot.md b/services/monitoring/ninjabot.md index 1c51dd4..d851d21 100644 --- a/services/monitoring/ninjabot.md +++ b/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). diff --git a/services/networking/isc-dhcp-server.md b/services/networking/isc-dhcp-server.md index 271b4a1..3ec07a2 100644 --- a/services/networking/isc-dhcp-server.md +++ b/services/networking/isc-dhcp-server.md @@ -1,10 +1,10 @@ # 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 -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. +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. ## Principe @@ -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 - 255.255.255.255 en spécifiant son adresse MAC dans la requète + 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 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 @@ -47,14 +47,14 @@ encore. Pour cela, il se contente de reprendre à partir de la troisième Attention, il n'est pas rare qu'on composant actif (un switch par exemple) sur le lien dispose par défaut de fonctionnalité bloquant par sécurité le traffic dhcp. C'est une option de sécurité désactivable. Il est aussi -possible parfois d'utiliser cette fonctionnalité à notre avantage pour +possible parfois d'utiliser cette fonctionnalité à notre avantage pour 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 +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 -au machines derrière de communiquer avec une autre adresse que celle qu'elles -ont récupéré par dhcp. +Certains switchs permettent aussi de configurer certains ports pour qu'ils +interdisent aux machines de communiquer avec une autre adresse que celle +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 -listées ici soit bien démarrées et dispose d'une ipv4, sinon celui-ci refusera +Attention pour que le serveur démarre effectivement, il faut que les interfaces +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) diff --git a/services/networking/keepalived.md b/services/networking/keepalived.md index 0f3c27b..3c2c9c0 100644 --- a/services/networking/keepalived.md +++ b/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 -script lors des changements d'état de l'instance. Keepalived appelera alors -le script avec les paramètres suivant : -`script [TYPE] [NAME] [STATE] [PRIORITY]` où `[TYPE]` vaut `INSTANCE` dans -notre cas, `[NAME]` donne le nom de l'instance concernée, `[STATE]` donne +Comme précisé dans la section précédente, il est possible d'appeler [un +script](https://gitlab.crans.org/nounous/keepalived/) lors des changements +d'état de l'instance. Keepalived appelera alors le script avec les paramètres +suivant : `script [TYPE] [NAME] [STATE] [PRIORITY]` où `[TYPE]` vaut `INSTANCE` +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. diff --git a/services/networking/nftables.md b/services/networking/nftables.md index d29582e..b61887f 100644 --- a/services/networking/nftables.md +++ b/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). diff --git a/services/networking/prefix_delegation.md b/services/networking/prefix_delegation.md index ad6ae0b..2181c30 100644 --- a/services/networking/prefix_delegation.md +++ b/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 -fixée à des utilisateurs. +été écrite permettant notamment d'attribuer des préfixes IPv6 de taille fixée +à 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 -préfixes et de les attribuer à des adhérents en leur assignant des -passerelles (machine de l'adhérent à contacter pour router ce préfixe). +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érent⋅es en leur assignant des +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` -de rafraîchir la liste des préfixes et de leur passerelle dans le noyau de la +L'application fourni une API Rest HTTP permettant [au script +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 -peuvent être attribués à un ou plusieurs préfixes afin de résoudre les -adresses IPv6 délégués vers des noms de domaines choisis par l'adhérent. 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`. +Le reverse [DNS](/outils/protocoles/dns.md) est également délégué : des +serveurs DNS peuvent être attribués à un ou plusieurs préfixes afin de résoudre +les adresses IPv6 délégués vers des noms de domaines choisis par l'adhérent⋅e. +Il est même possible de configurer du DNSSEC pour le reverse DNS. Ceci est géré +par [le script dns](https://gitlab.crans.org/nounous/dns/) sur la VM +`silice`. diff --git a/services/networking/services/dhcp.md b/services/networking/services/dhcp.md index fed15a6..05e3f17 100644 --- a/services/networking/services/dhcp.md +++ b/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 -de données d'adhérent du crans. Actuellement celle ci est gérée par re2o donc on -fait des requêtes à l'API de re2o pour récupérer la liste des machines des -adhérents. +pour [/services/networking/isc-dhcp-server.md](isc-dhcp-server) à partir de la +base de données d'adhérent du crans. Actuellement, celle ci est gérée par re2o +donc on fait des requêtes à l'API de re2o pour récupérer la liste des machines +des adhérent⋅es. ## Installation diff --git a/services/networking/services/firewall.md b/services/networking/services/firewall.md index fe83101..8926c1b 100644 --- a/services/networking/services/firewall.md +++ b/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 diff --git a/services/re2o.md b/services/re2o.md index fcd49fa..f7ca7fe 100644 --- a/services/re2o.md +++ b/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) -sur `intranet.crans.org`. +Lorsqu'un⋅e nouvel⋅le adhérent⋅e rejoint le crans, son home doit être créé. +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`.