diff --git a/.mdlrc b/.mdlrc new file mode 100644 index 0000000..eaa88b4 --- /dev/null +++ b/.mdlrc @@ -0,0 +1 @@ +style "#{File.dirname(__FILE__)}/.mdstyle.rb" diff --git a/.mdstyle.rb b/.mdstyle.rb new file mode 100644 index 0000000..20d7df6 --- /dev/null +++ b/.mdstyle.rb @@ -0,0 +1,5 @@ +all +rule 'MD013', :ignore_code_blocks => true, :tables => false +exclude_rule 'MD024' +exclude_rule 'MD026' +rule 'MD033', :allowed_elements => "sup" diff --git a/CONTRIBUTE.md b/CONTRIBUTE.md deleted file mode 100644 index 296bd29..0000000 --- a/CONTRIBUTE.md +++ /dev/null @@ -1,17 +0,0 @@ -# Contribute - -## Structure - -La documentation a la structure suivante - * `tools`: dans cette section, on rassemble tous les outils utilisés et les descriptions de certains protocoles utilisés - * Exemples d'outils : TLS, APT, debian, rsync, ssh, … À mettre dans `/tools` - * Exemples de connaissances : IP, Firewall, NAT, DHCP, … À mettre dans `/tools` - * `howto`: dans cette section, on regroupe les connaissances pratiques utiles : acheter un disque, dimensionner une clim, … - * `infrastructure`: ici on décrit l'infrastructure dans sa globalité, pour faire simple ce que le Crans met à disposition du Crans - * Exemples : LDAP administration, NFS, Plan IP & VLAN, matériel technique, PostgreSQL - * `services`: on y décrit la liste des services offerts aux adhérents - -## Contribuer - -Pour contribuer rien de plus simple : il suffit de créer un fichier `.md` (en Markdown) dans la section idoine. -On priviliégiera des noms de fichier en minuscules et le plus simple possible : par exemple acheter un disque → `/howto/disk.md`. diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000..57c96a2 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,99 @@ +# Contribution + +Merci de contribuer à la documentation ! Même si le déploiement/la +maintenance des différents services du Crans peut paraître plus intéressante +que faire de la documentation, il s'agit au même titre d'une étape cruciale du +bon fonctionnement du Crans : on ne peut pas faire fonctionner tout un parc +informatique si on ne sait pas ce qu'il y a dedans. + +## Contribuer + +Toute contribution est la bienvenue ! Surtout n'hésitez pas à demander de +l'aide aux vieilles nounous si vous n'êtes pas certain⋅e de ce que vous +faites. + +On distingue ici deux types de contributions : + +* les contributions directes, c'est-à-dire un ajout d'une documentation sur + un ou plusieurs sujet, ou une modification d'une documentation déjà existante + pour la corriger, la mettre à jour, ... + +* les demandes de contribution, c'est-à-dire les demandes d'ajout de + documentation sur un sujet que vous trouvez mal expliqué et que vous ne + comprenez pas bien (sinon vous pourriez le faire vous-même ^^), ou les + demandes d'ajout de tutoriels dans le dossier [`howto`](howto). + +Pour les demandes de contribution, vous pouvez directement demander à une +nounou, mais pour ne pas oublier il vaut mieux dans tous les cas ouvrir une +issue sur le dépôt gitlab . +Une nounou ou un⋅e apprenti⋅e se chargera alors (lorsqu'iel aura le temps) +d'écrire cela. + +Pour les contributions directes, il n'y a aucun problème à directement mettre +vos modifications sur ce dépôt, à partir du moment où les +modifications/ajouts respectent l'organisation décrite dans [la section +Organisation du README.md](README.md#organisation) ainsi que les conventions de +rédactions décrites ci-dessous. Si vous avez effectué ou prévoyez beaucoup +de modifications, il peut alors être préférable de placer tous les +changements sur une autre branche puis de faire une merge request sur gitlab +pour qu'une autre nounou vérifie vos changements. De plus, si besoin, vous +pouvez vous aider des fichiers `TEMPLATE.md` pour avoir une idée de comment +structurer votre documentation. + +## Conventions de rédaction + +### Structuration + +Tous les fichiers doivent être écrits en +[markdown](https://fr.wikipedia.org/wiki/Markdown). Cela permet de lire toute +la documentation dans toutes circonstances avec des mises en forme +standardisées. Vous pouvez trouver de la documentation markdown sur [ce +site](https://www.markdownguide.org/) si nécessaire. Un linter est configuré +dans ce dépôt : [markdownlint](https://github.com/markdownlint/markdownlint). +Aucun fichier ne doit renvoyer d'avertissement après exécution de la commande +`mdl .` à la racine du dépôt. + +**Tout dossier doit contenir un fichier `README.md`**, même si celui-ci est +court. Il doit contenir le rôle de ce que contient le dossier avec une brêve +description de tous les fichiers et sous-dossiers présents. + +Tout dossier peut également contenir en plus, si nécessaire et approprié, un +fichier `TEMPLATE.md` mettant à disposition un template pour les futures +documentations. + +De plus, mis à part les fichiers `README.md` et `TEMPLATE.md`, et les fichiers +uniques [`CONTRIBUTING.md`](CONTRIBUTING.md), [`CRITICAL.md`](CRITICAL.md) et +[`LICENSE.md`](LICENSE.md), tous les noms de fichiers doivent être **clairs** +et en minuscules. Il vaut mieux un nom long qu'une abrévation peu +compréhensible. Dans le cas d'un nom de fichiers de plusieurs mots, on les +séparera par des tirets bas (underscores). Par ailleurs, on évite autant que +possible de créer des dossiers contenant 50 fichiers : on préfère avoir des +sous-dossiers thématiques plus navigables. + +### Mise en page + +Il n'y a jamais assez d'hyperliens : n'hésitez pas à mettre des références +vers de la documentation officielle ou à rediriger vers d'autres fichiers de +la documentation du Crans si cela est possible ! Cela permet de naviguer +facilement sans se perdre dans les sous-dossiers. + +De plus, pour faciliter la lisibilité, que ce soit dans le terminal ou sur +internet, on limite la taille des lignes à 80 caractères en comptant les +caractères non affichés sur des rendus graphiques (comme les hyperliens ou +les étoiles pour les mots en gras/italique/...). Si besoin, vous pouvez +facilement configurer un formatter dans votre éditeur de texte (vim, helix, +...) avec simplement la commande `fold -s -w80`. + +### Langue + +* Il serait préférable que toute la documentation soit (au minimum) être + écrite en français. Cela ne signifie pas qu'il ne peut pas y avoir de + traduction en anglais ou de termes informatiques anglais, mais la langue de + rédaction devrait rester le français pour être compris par tous et toutes + sans difficulté. + +* On privilégie le vouvoiement au tutoiement. + +* L'usage de l'écriture inclusive est recommandé, que ce soit par + l'utilisation prioritaire de termes épicènes, par la coordination (ex: "tous + et toutes") ou par l'emploi du point médian. diff --git a/CRITICAL.md b/CRITICAL.md new file mode 100644 index 0000000..cab6f3d --- /dev/null +++ b/CRITICAL.md @@ -0,0 +1,5 @@ +# Section critique + +Tout est cassé, que faire ? + +TODO diff --git a/README.md b/README.md new file mode 100644 index 0000000..6b347bb --- /dev/null +++ b/README.md @@ -0,0 +1,66 @@ +# Documentation Crans + +Voici la documentation technique du Crans à destination des apprenti⋅e⋅s +et des nounous du Crans. Vous pouvez retrouver (prochainement) toute la +documentation mise en forme à l'adresse . Attention : +ce n'est pas la documentations des utilisateurices qui se situe dans [ce +dépôt](TODO). + +## Utilisation + +Pour la bonne maintenance des services du Crans, il est impératif d'avoir une +documentation permettant une bonne compréhension du fonctionnement global de +l'infrastructure et des services. C'est pourquoi il est essentiel que ce +dépôt soit le plus à jour possible en toutes circonstances. + +Il est par ailleurs recommandé à toutes les nounous et aux apprenti⋅e⋅s +souhaitant s'investir dans le Crans d'avoir une copie locale de ce depôt (avec +un petit `git clone`) : il est plus simple de dépanner un service critique +sans avoir à chercher où est la documentation (sur un serveur gitlab qui est +potentiellement cassé également ^^'). + +Si vous voyez un service/un serveur/... non documenté, ou si vous souhaitez +voir un tutoriel (appelé ici "how to") sur un sujet, réferrez-vous à +[CONTRIBUTING.md](CONTRIBUTING.md). Il est **impératif** de le lire avant de +contribuer pour une bonne cohérence organisationnelle et stylistique. + +## Organisation + +Tous les dossiers contiennent un fichier `README.md` que vous pouvez lire pour +comprendre le rôle de ce qui est présenté dans ce dossier ainsi qu'une +brêve description de tous les fichiers et sous-dossiers présents. + +Voici l'organisation générale de la documentation : + +* [`compte_rendus`](compte_rendus) : ensemble des comptes rendus des IN + (Inter-Nounous) ; + +* [`howto`](howto) : liste non exhaustive de tutoriels explicatifs sur une + démarche précise nécessitant généralement la manipulation de plusieurs + services ; + +* [`infrastructure`](infrastructure) : documentation concernant + l'infrastructure du Crans, c'est-à-dire les machines (physiques et + virtuelles), les réseaux utilisés ou encore le fonctionnement des services + mis à disposition pour une utilisation interne au Crans (les LDAP, + PostgreSQL, ...) ; + +* [`outils`](outils) : présentation rapide (ou détaillée selon la + pertinence) de tous les outils et protocoles utilisés par le Crans ; + +* [`services`](services) : présentation rapide des différents services du + Crans mis à disposition des utilisateurices. + +En plus de ces dossiers, on trouve également les fichiers suivants jouant un +rôle particulier : + +* [`CONTRIBUTING.md`](CONTRIBUTING.md) : fichier expliquant comment bien + contribuer à la documentation du Crans ; + +* [`CRITICAL.md`](CRITICAL.md) : que faire si c'est la panique ? + +* [`LICENSE.md`](LICENSE.md) : licence sous laquelle est publiée la + documentation du Crans. + +* [`SECURITY.md`](SECURITY.md) : bases de sécurité, valables au Crans mais + pas que. diff --git a/ROADMAP.md b/ROADMAP.md deleted file mode 100644 index f4068f5..0000000 --- a/ROADMAP.md +++ /dev/null @@ -1,59 +0,0 @@ -# ROADMAP - -``` -. -├── critical -│ ├── borg.md [DONE] -│ ├── cas.md [ynerant] -│ ├── gitlab.md [ÿnerant] -│ ├── irc [esum] -│ │ ├── anope.md -│ │ ├── inspircd.md [DONE] -│ │ └── thelounge.md -│ ├── mail -│ │ ├── autoconfig.md [DONE] -│ │ ├── dovecot.md [DONE] -│ │ ├── horde.md [shirenn] -│ │ ├── mailman.md [ÿnérant] -│ │ ├── nullmailer.md [erdnaxe] -│ │ ├── opendkim.md [shirenn] -│ │ ├── policyd.md [shirenn] -│ │ ├── postfix.md [shirenn] -│ │ ├── roundcube.md [erdnaxe] -│ │ └── services -│ │ └── mail.md [DONE] -│ ├── moinmoin.md [erdnaxe] -│ ├── monitoring -│ │ ├── grafana.md [DONE] -│ │ ├── ninjabot.md [DONE] -│ │ └── prometheus.md [erdnaxe] -│ ├── networking -│ │ ├── bind.md [shirenn] -│ │ ├── bird.md [DONE] -│ │ ├── freeradius.md [vanille] -│ │ ├── isc-dhcp-server.md [DONE] -│ │ ├── keepalived.md [DONE] -│ │ ├── nftables.md [DONE] -│ │ ├── radvd.md [DONE] -│ │ └── services -│ │ ├── dhcp.md [DONE] -│ │ ├── firewall.md [DONE] -│ │ └── prefix-delegation.md [DONE] -│ ├── owncloud.md [erdnaxe] -│ └── services -│ ├── borg.md [shirenn] -│ └── monitoring.md [shirenn] -└── services - ├── belenios.md [DONE] - ├── ethercalc.md [erdnaxe] - ├── etherpad.md [erdnaxe] - ├── framadate.md [DONE] - ├── galene.md [DONE] - ├── gitea.md [shirenn] - ├── jitsi.md [ynerant] - ├── linx.md [DONE] - ├── re2o.md [DONE] - ├── vsftpd.md [DONE] - ├── zerobin.md [shirenn] - └── zamok.md [shirenn] -``` diff --git a/SECURITY.md b/SECURITY.md new file mode 100644 index 0000000..7385de7 --- /dev/null +++ b/SECURITY.md @@ -0,0 +1,78 @@ +# Securité + +Le but ici est de donner quelques conseils généraux de sécurité qui est bon +à respecter le plus possible lors de changements de l'infrastructure ou de +services. La liste ne se veut pas exhaustive, mais permet de donner l'esprit +global qu'il faut avoir. + +## Sécurité des comptes utilisateurs + +Que ce soit les membres de l'association, comme les membres actif⋅ves, il faut +prendre les précautions pour s'assurer que ses identifiants ne fuient pas dans +la nature : + +* **Ne pas avoir de comptes locaux avec des mots de passe actifs.** + Un compte avec possibilité d'authentification par mot de passe DOIT être + dans l'annuaire LDAP. Cela permet de faciliter le changement de mot de + passe et ne pas laisser des mots de passe cassés traîner. + +* **Ne pas partager un compte.** + Et oui, on évite de filer son mot de passe à son voisin. + +* **Avoir un mot de passe solide.** + `toto2345` n'est pas un bon mot de passe et prend en moyenne moins de 5 + minutes à être bruteforcée avec + [john](https://fr.wikipedia.org/wiki/John_the_Ripper). + +* **Favoriser l'authentification par paire de clées.** + Pour les services le permettant (SSH, Git...), il est préférable d'avoir + une paire de clé. Une clé privée ne doit jamais quitter le périphérique + où elle a été créée (que ça soit un token matériel ou une machine + Linux). Il est préférable de protéger la clé privée par un mot de + passe. Ainsi si une de vos machine est compromise, vous pouvez révoquer + seulement sa clé et tracer où elle a été utilisée. + +* **Favoriser la double authentification.** + Pour les services critiques (paiement, accès root...) il est préférable + d'ajouter un second facteur d'authentification et d'alerter l'équipe si + seulement le premier facteur a réussi mais le second a échoué. + Pour les services Web, voir le standard WebAuthn. Pour OpenSSH il existe + des intégrations avec des applications de second authentification. + +* **Utiliser un gestionnaire de mots de passe pour les secrets partagés.** + Pour les secrets partagés au sein de l'équipe technique, on les chiffre + pour les clés privées de chaque administrateur. + +## Sécurité des logiciels développés + +* **Ne pas fixer strictement les versions des paquets.** + Il faut s'assurer que les contraintes sur les dépendances permettent + d'obtenir les mises à jour de sécurité. Souvent il n'est que nécessaire + de fixer la version majeure (`~=2.1`, plutôt que `==2.1.1`). + +* **Privilégier le gestionnaire de paquet de la distribution.** + La distribution rétroporte les mises à jour de sécurité. Il est donc de + bon goût d'utiliser le plus possible ses paquets pour simplifier la mise + à jour de l'ensemble de l'infrastructure. + +* **Utiliser des outils de linting avec des règles de sécurité.** + Les bons outils de linting connaissent les patterns pouvant potentiellement + se traduire en faille de sécurité. + +* **Lancer le logiciel en non-privilégiés.** + Un logiciel ne devrait jamais avoir besoin de `root` ou de `sudo`. + Lors de l'écriture du service, on peut également ajouter des protections + supplémentaires pour augmenter l'isolation. + +## Sécurité de l'infrastructure + +* **Faire ses backups, et vérifier qu'elles marchent.** + +* **Faire des scans des ports ouverts.** + Pour cela on peut lancer `nmap` sur la plage d'adresses IP. + +* **Monitorer et alerter.** + +* **Segmenter les services.** + Isoler les services sur différentes machines et augmenter l'indépendance + permet d'améliorer la robustesse de l'infrastructure. diff --git a/compte_rendus/2024-01-13.md b/compte_rendus/2024-01-13.md deleted file mode 100644 index 4d47d9c..0000000 --- a/compte_rendus/2024-01-13.md +++ /dev/null @@ -1,90 +0,0 @@ -# Réunion IN - -* Date : Samedi 13 Janvier 2024 -* Lieu : MB87 et Galène (https://galene.crans.org/group/IN) -* 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 - -### 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. - -### 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. - -## 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 `root@crans.org` 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. - -## 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. - -## DU (distrib upgrade) - -Tout casse à chaque fois qu'on DU un serveur. -On va passer soon^{TM} sur NixOS. - -## 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. - -## 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é. - - diff --git a/compte_rendus/2024_01_13.md b/compte_rendus/2024_01_13.md new file mode 100644 index 0000000..48d0707 --- /dev/null +++ b/compte_rendus/2024_01_13.md @@ -0,0 +1,91 @@ +# Réunion IN + +* 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 + +### 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. + +### 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. + +## 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 `root@crans.org` 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. + +## 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. + +## DU (distrib upgrade) + +Tout casse à chaque fois qu'on DU un serveur. +On va passer soon^{TM} sur NixOS. + +## 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. + +## 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é. diff --git a/compte_rendus/README.md b/compte_rendus/README.md new file mode 100644 index 0000000..2c45d10 --- /dev/null +++ b/compte_rendus/README.md @@ -0,0 +1,20 @@ +# Comptes-rendus + +## Présentation + +Ce dossier 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 +apprenti-es@lists.crans.org et nounou@crans.org. + +## Organisation + +Chaque fichier de ce dossier est le compte-rendu d'une réunion technique. Vous +pouvez trouver un template de compte-rendu dans le fichier +[`TEMPLATE.md`](TEMPLATE.md) si nécessaire. La seule contrainte pour ce +dossier est le nom des fichiers. Les comptes-rendus sont identifiés par la +date de la réunion : pour une réunion du JJ/MM/AAAA, le fichier devra se +nommer `AAAA_MM_JJ.md` (et non `JJ_MM_AAAA.md` car le tri par date se fait plus +simplement). diff --git a/compte_rendus/TEMPLATE.md b/compte_rendus/TEMPLATE.md new file mode 100644 index 0000000..688960d --- /dev/null +++ b/compte_rendus/TEMPLATE.md @@ -0,0 +1,34 @@ +# 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/CransTechnique/CransApprentis) +* [Apprenti 2](https://wiki.crans.org/CransTechnique/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 + +### Point 1 + +Détails et résumé des discussions du point 1 + +### Point 2 + +Détails et résumé des discussions du point 2 + +... diff --git a/critical/monitoring/grafana.md b/critical/monitoring/grafana.md deleted file mode 100644 index 4040538..0000000 --- a/critical/monitoring/grafana.md +++ /dev/null @@ -1,15 +0,0 @@ -# Grafana - -Grafana est une traceur de données à destination des humains. Il est codé en NodeJS et correctement packagé dans une source de paquets Debian. - -L'idée de Grafana est de se connecter à des sources de données puis de réaliser des dashboards contenant des modules faisant des requêtes à ces sources de données. - -Là vous vous dites « *Mais du coup il faut passer beaucoup de temps pour créer les dashboards ? C'est nul !* ». Effectivement comparé à Munin il y a plus de travail nécessaire pour afficher des données, mais cela permet une plus grande adaptabilité. Beaucoup de dashboards existent en ligne (surtout sur les dépôts de code des exporters Prometheus) et sont téléchargeable en JSON pour ensuite les importer. - -## Securité - -Par défaut Grafana crée un compte avec pour login `admin` et mot de passe `admin`. Parfois quand on bidouille la configuration, cet utilisateur est recréé automatiquement. Pensez à le supprimer s'il apparait dans la liste des utilisateurs ou changer son mot de passe. - -Évitez d'installer des plugins qui ne sont pas de confiance. -Le service Systemd de Grafana le conteneurise pour éviter des potentielles exécutions de code distantes. - diff --git a/critical/monitoring/ninjabot.md b/critical/monitoring/ninjabot.md deleted file mode 100644 index af0e04c..0000000 --- a/critical/monitoring/ninjabot.md +++ /dev/null @@ -1,8 +0,0 @@ -# NinjaBot -NinjaBot est un bot [IRC](/tools/irc.md) qui permet d'envoyer des notifications en temps réel sur des canaux de discussion, ses sources sont disponibles [ici](). - -Au Crans il est utilisé pour retransmettre les alertes du monitoring sur `#monitoring` et possède le nick `monitoring`. - -NinjaBot utilise [Flask](https://flask.palletsprojects.com/) afin d'écouter des webhooks et de pousser des notifications en fonction des données envoyées par le webhook. Ces notification sont ensuite envoyée sur une fifo lue par le bot IRC en lui-même : il est donc possible de modifier le comportement des notifications sans redémarrer le bot en lui-même. - -NinjaBot est déployé sur la VM `monitoring` et le service systemd qui lui est associé est `ninjabot`. diff --git a/critical/networking/bird.md b/critical/networking/bird.md deleted file mode 100644 index 712403a..0000000 --- a/critical/networking/bird.md +++ /dev/null @@ -1,148 +0,0 @@ -# Bird -Bird est un daemon de routage. Il supporte de nombreux protocoles de routages -comme BGP and OSPF. Au crans on l'utilise pour faire de l'échange de route avec -notre FAI grace au protocole BGP. C'est donc le seul que je détaillerais ici -pour le moment. - -## Principe -### L'IANA, le RIPE et le CRANS, les IPs et les numéros d'AS -Après l'adoption du protocole IP, il a été décidé que ce serait à l'IANA -(Internet Assigned Number Authority) de se charger de l'allocation des adresses -IPs. Elle délègue cependant cette responsabilité à des entités régionales -appelées RIR pour Regional Internet Registry. En Europe, c'est le RIPE (pour -Réseaux IP Européens, cocorico) qui remplit cette office. Les gens à qui un RIR -alloue des ressources est appelée un LIR pour Local Internet Registery. Et vous -savez quoi, depuis 2017 le crans est un LIR à part entière \o/. Et le RIPE -(notre RIR) nous a assigné les ressources suivantes : - - 185.230.76.0/22 - - 2a0c:700::/32 - - 204515 - -Les deux premiers éléments de cette liste suivent assez logiquement ce que j'ai -dit plus haut. Le RIPE est censé assigné au LIR européen des ressources ip. Il -nous a donc délégué un `/22` d'IPv4 et un `/32` d'IPv6 (aussi appellée une -mole). Mais le troisième élément semble pour le moment plus absconts. En fait -l'IANA et les RIR ne se contente pas de fournir des adresses IP mais toutes les -ressources relatif à l'internet. En particulier, le dernier élément de notre -liste est un numéro d'AS pour autonomous system. Un AS est un réseaux -informatique qui opère sa propre politique de routage interne. C'est le cas au -crans. Un numéro d'AS est identifiant unique alloué par un RIR et est utilisé -dans certains protocoles internet entre AS comme le protocole BGP. - -### Le protocole BGP -Le protocole BGP est un protocole de routage qui permet l'échange de route entre -deux AS. J'avoue avoir un peu la flemme de rentrer dans les détails de comment -marche le protocole (si ça vous intéresse aller lire la RFC). Mais l'idée -générale est que deux AS pairs dans le réseaux vont s'échanger des routes qui -décrivent ce qu'ils sont capables d'atteindre. Si un AS recoit deux chemins -différents pour la même route, il choisira celle qui a l'AS path le plus court, -c'est à dire celle qui passe par le moins d'AS différent avant d'arriver à bon -port. - -## Installation -On tire bird2 des repository debian : `sudo apt install bird2`. - -## Configuration -Le logiciel n'inclut pas de page de manuel détaillant les différentes options de -configuration mais le [https://bird.network.cz/](site internet de bird) est très -bien fourni en explication. - -Comme le logiciel supporte plusieurs protocole sa configuration est ségmenté en -fonction des différents protocoles configurées en plus de quelques options de -configurations fournis générales. - -### Options de configurations générales -Il est nécessaire de définir l'identifiant du routeur sur le lien. Cet -identifiant en ipv6 comme en ipv4 doit être une adresse ipv4 qui pointe vers le -routeur pour assurer son unicité. - -### Le protocole kernel -Le protocole kernel permet de définir la politique que bird va utiliser pour -inserer des routes dans le kernel. Les options import et export permettent de -définir quels routes bird va importer de la table de routage et exporter vers la -table de routage. Au crans, on choisit assez simplement d'insérer toutes les -routes que bird connait dans le noyau et de ne rien importer du noyau. L'option -scan time permet de régler la fréquence à laquelle bird lira le contenu de la -table de routage du kernel. Il est possible d'être plus précis⋅e sur les routes -importé et exporté du protocol en utilisant des filtres. - -``` -protocol kernel { - ipv4 { - import none; - export all; - }; -} - -protocol kernel { - ipv6 { - import none; - export all; - }; -} -``` - -### Le protocole device -C'est pas vraiment un protocole, il permet simplement à bird de lister les -interfaces du routeur. - -``` -protocole device {} -``` - -### Le protocole static -Le protocole static permet de définir des routes manuellement. Il est possible -de définir plusieurs types de routes mais au crans on n'en définit que d'un seul -type : les routes reject. Le comportement de ces routes est différent selon s'il -est inséré dans le kernel où s'il est partagé via un protocole de partage de -routes. Dans le premier cas, il dit au kernel assez litteralement de jetter tous -les paquets vers cette route, comme le kernel choisi la route de plus long -préfixe qui correspond à la destination cela revient à dire au routeur de jetter -les paquets que le routeur ne sait pas joindre dans le bloc d'ips. Cependant -dans un protocole d'échange de routes, il signifie que le routeur connait une -route vers les éléments de ce bloc d'ips. Par exemple, - -``` -protocol static { - ipv4; - route 185.230.76.0/22 reject; -} - -protocol static { - ipv6; - route 2a0c:700::/32 unreachable; -} -``` - -### Le protocol BGP -Comme expliqué au dessus, le protocole BGP permet de faire de l'échange de -routes entre différents AS. Il faut spécifier notre numéro d'AS, le numéro d'AS -du pair et l'adresse sur laquelle on souhaite le contacter. Il est possible de -préciser avec quelle adresse on veut le contacter. On peut là aussi définir des -filtres d'import et d'exports de routes. Par exemple, - -``` -protocol bgp aurore4 { - description "BGP4 session with example"; - local 203.0.113.1 as crans_asn; - neighbor 203.0.113.2 as example_asn; - strict bind; - - ipv4 { - import all; - export where source ~ [ RTS_STATIC ]; - }; -} - -protocol bgp aurore6 { - description "BGP6 session with example"; - local 2001:db8:28::1 as crans_asn; - neighbor 2001:db8::28::2 as example_asn; - strict bind; - - ipv6 { - import all; - export where source ~ [ RTS_STATIC ]; - }; -} -``` diff --git a/critical/networking/keepalived.md b/critical/networking/keepalived.md deleted file mode 100644 index ba1c818..0000000 --- a/critical/networking/keepalived.md +++ /dev/null @@ -1,90 +0,0 @@ -# Keepalived - -Keepalived est une implémentation du protocole VRRP. Il permet de partager des -ips entre plusieurs machines. Si celle qui qui porte l'adresse à un moment -tombe, c'est une des autres qui prend le relai. - -## Principe - -Le protocole VRRP permet de s'assurer qu'un ensemble d'adresses ip soit toujours -tenues par un pair sur le reseaux. Par exemple, au crans, pour rajouter de la -résilience sur la panne d'un routeur, les ips du routeurs sont partagées entre -plusieurs machines. Celle qui porte les ressources en fonctionnement normal est -appelée le `MASTER` et les autres sont appelées les `BACKUP` et on leur assigne -des priorités décroissantes. Sur le lien local que partage les différentes -machines, elles négocient qui devrait porter les ressources actuellement. En -ipv4, la négociation se fait en multicast en utilisant l'ip `224.0.0.18` et en -ipv6 cela ce fait via le groupe `ff02::12` (il faut bien faire attention à ce -que le parefeu ou qu'un commutateur ne le filtre pas). Si le porteur de l'ip -actuel arrète de transmettre des alertes VRRP alors le candidat avec la plus -haute priorité s'affectera les ressources. - -## Installation - -On se contente de tirer le logiciel des repositorys debian `sudo apt install keepalived`. -Il y est packagé (correctement) depuis Jessie. - -## Configuration - -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 -global_defs. En particulier on peut y préciser le nom de la machine et la -configuration de l'envoi de mail : - -``` -global_defs { - notification_email { root@crans.org } - notification_email_from keepalived@crans.org - smtp_server smtp.adm.crans.org - router_id routeur-sam -} -``` - -On peut ensuite rentré 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, 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. - -``` -vrrp_instance VI_ALL { - # Définit l'état de priorité de la machine dans l'instance - state MASTER - priority 150 - # Active l'envoie des mails lors des changement d'état - smtp_alert - - # Lien sur lequel se font les alertes VRRPS - interface ens18 - # Identifiant de l'instance sur le lien - virtual_router_id 60 - # Fréquence des envois d'alertes VRRPs - advert_int 2 - - # Script appelé lors des changement d'état - notify /var/local/services/keepalived/keepalived.py - - # Bloc définissant les ressources partagées - virtual_ipaddress { - 185.230.79.62/26 brd 185.230.79.63 dev ens22 scope global - } -} -``` - -### 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 l'état vers lequel on transitionne et `[PRIORITY]` la -priorité dans l'instance. - -En utilisant un script, il est possible (comme on le fait actuellement au crans) -de laisser à keepalived le soin de démarrer certains services. diff --git a/critical/networking/prefix_delegation.md b/critical/networking/prefix_delegation.md deleted file mode 100644 index 0ab5497..0000000 --- a/critical/networking/prefix_delegation.md +++ /dev/null @@ -1,14 +0,0 @@ -# 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. - -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. - -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). - -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 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 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`. diff --git a/critical/networking/radvd.md b/critical/networking/radvd.md deleted file mode 100644 index af0da06..0000000 --- a/critical/networking/radvd.md +++ /dev/null @@ -1,88 +0,0 @@ -# Radvd - -Radvd est une implementation du mécanisme d'autoconfiguration des adresses IP en -ipv6. Il permet au client de connaitre l'adresse du routeur et de se construire -lui même une adresse à partir du préfixe annoncé par le routeur et de son -adresse MAC. Des extensions du protocoles permettes aussi la configuration des -serveurs dns. - -## Principe - -### Adresse ipv6 et EUI-64 - -Il est possible pour un pair possédant une adresse MAC et un prefixe ipv6 de -taille au plus `/64` de construire une adresse ipv6. Cependant, rien n'assure -qu'elle soit unique à ce stade et il faudra par la suite le vérifier. Mais on ne -s'interesse ici qu'au processus de construction. - -De son adresse MAC (donnée à 48 bits), on dérive un identifiant de l'interface -sur le lien de 64 bits en insertant les 16 bits `FF:FE` au milieu de l'adresse -MAC puis on inverse le 7 ème bit. On peut ensuite suffixer cet identifiant au -préfixe dans lequel on chercher à construire notre addresse ipv6. Ainsi -`00:25:90:69:8c:74` devient `00:25:90:ff:fe:69:8c:74` puis -`02:25:90:ff:fe:69:8c:74` qui donne l'adresse `fd00::10:0225:90ff:fe69:8c74/64` -dans le prefixe `fd00:0:0:10::/64`. - -### Processus d'autoconfiguration complet - -Lorsqu'une machine configure une interface supportant l'ipv6 sur un lien, celle -ci va tenter de se crééer une premier adresse local au lien. Elle est donc -judicieusement appelé ip de lien locale. Pour cela, il va se contruire comme -expliquer précedemment une adresse dans le prefixe `fe80::/64`. Pour s'assurer -qu'elle est effectivement unique, il va envoyer au groupe ipv6 all-node -(`ff02::1`) qui comme son nom l'indique contient tous les nœuds si quelqu'un -utilise déjà l'adresse. Si c'est le cas, il ne poussera pas sa configuration -plus loin. Sinon après un délai sans réponse, il s'assignera l'adresse. Notre -pair a donc maintenant une adresse sur le lien et il peut écouter les annonces -(judicieusement appelé routeur-advertissement ou RA) périodiques qu'envoie le -routeur au groupe all-node. S'il ne désire pas patienté jusqu'à la prochaine -annonce le client peut envoyer un routeur-sollicitation au groupe all-routers. -Dans ces annonces le routeur inclut entre autre le prefixe dans lequel le client -devrait prendre son adresse, son adresse de lien local ainsi que des informations à -propos des serveurs dns. Une fois ces informations récupérées le client peut -procéder aux dernières étape de configuration de son interface réseaux en -assignant l'adresse qu'il a construit à partir du préfixe que lui a fourni le -routeur (en vérifiant en amont son unicité sur le lien) et en configurant la -gateway à l'adresse de lien local du routeur. - -## Installation - -On se contente de tirer le logiciel des repository debian `sudo apt install -radvd`. - -## Configuration - -La page de manuel détaillant les options de configurations de radvd est -consultable en utilisant `man 5 radvd.conf`. - -La configuration du logiciel se fait par bloc d'interface sur lesquel on va -publier nos RA. Dans un bloc on peut ensuite définir - * des options génériques à propos de l'annonce comme par exemple l'intervalle - auquel notre routeur devrait publier des annonces ou le temps que la route - devrait être conservé par le client. - * les prefixes que le routeur va annoncer sur le lien et certaines options - associées - * les options de configurations du DNS - -Par exemple, le bloc suivant configure des annonces sur l'interface ens1 envoyé -toutes les 30 secondes avec comme préfixe `2a0c:700:12::/64`, `adh.crans.org` -comme liste de recherche pour les dns et `2a0c:700:12::ff:fe00:9912` comme -adresse du serveur dns. - -``` -interface ens1 { - AdvSendAdvert on; - AdvDefaultPreference high; - MaxRtrAdvInterval 30; - - prefix 2a0c:700:12::/64 { - AdvRouterAddr on; - }; - - # La zone DNS - DNSSL adh.crans.org {}; - - # Les DNS récursifs - RDNSS 2a0c:700:12::ff:fe00:9912 {}; -}; -``` diff --git a/critical/networking/services/firewall.md b/critical/networking/services/firewall.md deleted file mode 100644 index e4ff1a0..0000000 --- a/critical/networking/services/firewall.md +++ /dev/null @@ -1,124 +0,0 @@ -# Pare-feu - -Voir `/critical/networking/nftables.md` pour une documentation minimale sur -NFTables. - - - -Voici un pare-feu basique dans lequel des adhérants se trouvent derrière un -routeur : - - -``` -#!/usr/sbin/nft -f - -flush ruleset - -# +~~~~~~+ -# | IPV4 | -# +~~~~~~+ -define adh_prefix = 172.16.54.1 - 172.16.54.98 -define srv_prefix = 185.230.79.0/24 - -define nat_out = 185.230.79.37 - -# +~~~~~~+ -# | IPV6 | -# +~~~~~~+ -define adh_prefix6 = 2a0c:700:54::/64 - - -# définit les adresses utilisées par les adhérants -define adh4 = 100.66.0.0/16 ### Qu'est-ce que cette adresse ? - - - -# +~~~~~~~~~~~~~~+ -# | Filter table | -# +~~~~~~~~~~~~~~+ -table inet filter { - # Définiton des ports ouverts sur chaque machine - # (Utilise un mapping plutôt que des sets pour éviter uen complexité - # terrifiante en O(nm) et passer à O(n+m) \(\ddot\smile\)) - set authorized_in_forward_tcp4 { - type ipv4_addr . inet_service - flags interval - } - set authorized_in_forward_udp4 { - type ipv4_addr . inet_service - flags interval - } - set authorized_in_forward_tcp6 { - type ipv6_addr . inet_service - flags interval - } - set authorized_in_forward_udp6 { - type ipv6_addr . inet_service - flags interval - } - - chain input { - type filter hook input priority 0; policy drop; - - # Accept local traffic - meta iiftype loopback accept comment "allow from loopback" - - # Accepts existsing connections - ct state { related, established } accept - ct state invalid drop - - # Accept SSH and DHCP - meta l4proto { udp, tcp } th dport { ssh, 67 } ct state new accept - - # Accept ping - ip protocol icmp accept - icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept - } - - chain forward { - type filter hook forward priority 0; policy drop; - - # Accept established and ping connnections - ct state { established, related } accept - ct state invalid drop - - # On log tout ce qui est neuf et qui passe - log prefix "FORWARD: " - ip protocol icmp accept - icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept - - # Ouverture de ports pour les gens se trouvant derrière - ip daddr . tcp dport @authorized_in_forward_tcp4 accept - ip6 daddr . tcp dport @authorized_in_forward_udp4 accept - ip daddr . udp dport @authorized_in_forward_tcp6 accept - ip6 daddr . udp dport @authorized_in_forward_udp6 accept - - # Accepter toutes les connexions sortantes des clubs / adh et les logger - ip saddr $adh_prefix accept - ip6 saddr $adh_prefix6 accept - } -} - - - -# +~~~~~+ -# | NAT | -# +~~~~~+ -table inet loggonsTout { - chain prerouting { - type nat hook prerouting priority dstnat; - # On log ce qui est neuf - ct state new log prefix "LOGALL: " - } -} - -table ip nat { - chain postrouting { - type nat hook postrouting priority srcnat; - - # traffic des adhérants et des clubs ===> $nat_out (range) - ip saddr $adh_prefix snat to $nat_out persistent - } -} -``` - diff --git a/howto/README.md b/howto/README.md new file mode 100644 index 0000000..ae773ab --- /dev/null +++ b/howto/README.md @@ -0,0 +1,24 @@ +# How To : les tutos techniques + +## Présentation + +Ce dossier 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 [au CONTRIBUTING.md](../CONTRIBUTING.md). + +## Organisation + +* [Changer de pseudo](changer_de_pseudo.md) : 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. + +* [Créer une VM pour les adhérent⋅es](creer_vm_adherent.md) : comment + faire pour créer une VM pour un⋅e adhérent⋅e. + +* [Devenir nounou](devenir_nounou.md) : guide pour les nouvelles nounous ! + +* [Supprimer un⋅e utilisateur⋅rice](supprimet_utilisateur.md) : comment + supprimer un⋅e utilisateur⋅rice ainsi que toutes ses données. diff --git a/howto/cec.md b/howto/changer_de_pseudo.md similarity index 55% rename from howto/cec.md rename to howto/changer_de_pseudo.md index 8849da7..7818277 100644 --- a/howto/cec.md +++ b/howto/changer_de_pseudo.md @@ -1,12 +1,12 @@ -# Changement d'état civil (ou plutôt changement de pseudo) +# Changement 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, ce petit guide est là pour rappeler tout ce qu'il ne faut pas +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. - ## Re2o Il faut bien un début, c'est sur l'intranet qu'on commence par renommer @@ -14,23 +14,22 @@ 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. - +`yson-partou`, puis taper `cn=Utilisateurs` et s'assurer que +`cat cn=ancienpseudo` ne renvoie rien. ## 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. +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. ## Backups @@ -44,43 +43,44 @@ mois au cas où pour supprimer l'ancien dossier inutile. éternellement. Pas pour des raisons de place mais pour des raisons de non-conservation de données personnelles. - ## 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. +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 : +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 : [https://gitlab.crans.org/admin/users](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 ayant perdu ni projets -ni commits, et son adresse mail ainsi que son nom seront mis à jour à sa -prochaine connexion. +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. ## 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. +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. -Dans le cas où il n'y a rien d'important de stocké sur Owncloud, si ce n'est -les données (mais qui sont sur Zamok), il suffit simplement de se rendre dans -l'interface d'administration, section utilisateur⋅rices : +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 : [https://owncloud.crans.org/settings/users](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é. - ## Mailman On commence par se rendre dans [Django-Admin](https://lists.crans.org/admin/). @@ -93,18 +93,16 @@ 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. - ## 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. - +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. ## 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. \ No newline at end of file +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. diff --git a/howto/create_vm.md b/howto/creer_vm_adherent.md similarity index 73% rename from howto/create_vm.md rename to howto/creer_vm_adherent.md index b415d09..cf39fcc 100644 --- a/howto/create_vm.md +++ b/howto/creer_vm_adherent.md @@ -1,8 +1,9 @@ # 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. J'en fournis un -récapitulatif ici mais attention celui-ci peut ne pas être à jour et seul ce qui -est marqué dans les statuts fait foi. +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 | |:---------------------------------------:|:------:| @@ -13,25 +14,34 @@ est marqué dans les statuts fait foi. | Disque additionnel (par tranche de 16G) | 1€ | Le service minimal comprend : - - un disque de 8G - - un cœur - - 2G de ram + +* un disque de 8G +* un cœur +* 2G de ram Tous les services sont proposés pour une durée de 1 an. ## Utilisateur⋅ices + La documentation pour les utilisateur⋅ices se trouvent sur le [wiki](https://wiki.crans.org/VieCrans/VPS). ## Nounous et apprenti⋅es + ### Facturation -TODO + +Quand cela est possible, privilégier la note. Sinon, voir avec un⋅e +trésorier⋅ère pour d'autres méthodes (espèces, virement, ...). ### 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). + +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: -``` + +```txt ou=users ├── cn=toto └── cn=titi @@ -41,9 +51,11 @@ ou=hosts ├── cn=voyager └── cn=curiosity ``` -Pour référence ma configuration `shelldap` pour me connecter au ldap est -la suivante : -``` + +Pour référence ma configuration `shelldap` pour me connecter au ldap est la +suivante : + +```txt # +---------------------------------+ # | Connexion à flirt.adm.crans.org | # +---------------------------------+ @@ -52,11 +64,14 @@ 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`. #### Utilisateur⋅ices + Les objets utilisateur⋅ices dispose des champs suivants : -``` + +```txt dn: cn=toto,ou=users,dc=adh,dc=crans,dc=org objectClass: inetOrgPerson objectClass: organizationalPerson @@ -75,10 +90,12 @@ 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 : -``` + +```bash [ _shirenn@flirt ] $ ./addadherent --re2o-id xxxxx toto Prénom: Toto NOM: Passoir @@ -89,23 +106,27 @@ 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. +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. #### 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 : -``` + +```txt 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 : -``` + +```txt [ _shirenn@flirt ]$ ./addclub rover Pseudo du responsable: toto Pseudo du responsable: titi @@ -113,9 +134,11 @@ Pseudo du responsable: ``` #### Machines + Les machines sont des objets ldap qui répertorient des informations sur leur configuration et leurs propriétaires : -``` + +```txt dn: cn=curiosity,ou=hosts,dc=adh,dc=crans,dc=org objectClass: top objectClass: device @@ -128,9 +151,12 @@ 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 + +```txt +[ _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 @@ -141,18 +167,19 @@ scripts devraient mettre à jour la configuration du parefeu, du dhcp et de proxmox. ### 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. +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`). -Vous pouvez alors lui demander une clé publique ssh et après avoir installer la -vm, vous la déposer dans `/root/.ssh/authorized_keys` (en faisant attention à -créer le `.ssh` avec les bonnes permissions `mkdir -m 0700 /root/.ssh`) et vous -supprimer les mots de passe que vous avez rentrer pendant l'installation `passwd --d root`). +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`). diff --git a/howto/become_nounou.md b/howto/devenir_nounou.md similarity index 94% rename from howto/become_nounou.md rename to howto/devenir_nounou.md index b11bb61..8bf9682 100644 --- a/howto/become_nounou.md +++ b/howto/devenir_nounou.md @@ -1,4 +1,5 @@ # 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 @@ -36,7 +37,8 @@ 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) : -``` + +```txt We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: @@ -44,6 +46,7 @@ Administrator. It usually boils down to these three things: #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 @@ -63,6 +66,7 @@ passer aux choses plus intéréssantes : comment on se donne ces droits (et dans marge, comment on se les retire) ? ## 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 @@ -73,6 +77,7 @@ fonctionne pas. C'est sûrement dû à ces ~~conneries~~ de replicat ldap. Il fa `tools/ldap.md`). ## 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: @@ -99,38 +104,45 @@ complètement à quelqu'un⋅e la possibilité d'utiliser un mot de passe. Dans cas il faut le changer :( ## 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. ### 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. ### Mailman + Il faut se connecter normalement au logiciel, puis allez dans la section admin -https://lists.crans.org/admin, dans la sous page utilisateur⋅rices, on peut +, 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). ### Owncloud -Il faut aller dans la zone d'administration et rajouter les utilisateur⋅icess au + +Il faut aller dans la zone d'administration et rajouter les utilisateur⋅ices au groupe d'administration. ### 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. ### 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. ### IRC + On édite le fichier `/etc/inspircd/opers.conf` pour rajouter un bloc suivant -``` +```txt password="" @@ -141,10 +153,11 @@ On édite le fichier `/etc/inspircd/opers.conf` pour rajouter un bloc suivant 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 ^^). + +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 ^^). ### Mails @@ -157,4 +170,4 @@ bien à jour `redisdead`, `sputnik` et surtout `zamok` dans le dossier l'adresse `root@crans.org` sur votre client. Voilà, tu as maintenant gagné le droit de t'ajouter ou de te retirer de -https://wiki.crans.org/CransNounous ! + ! diff --git a/howto/security_101.md b/howto/security_101.md deleted file mode 100644 index 3b522b9..0000000 --- a/howto/security_101.md +++ /dev/null @@ -1,79 +0,0 @@ -# Security 101: Quelques bases de sécurité - -Le but ici est de donner quelques conseils généraux de sécurité qui est bon à -respecter le plus possible lors de changements de l'infrastructure ou de -services. -La liste ne se veut pas exhaustive, mais permet de donner l'esprit global qu'il -faut avoir. - -## Sécurité des comptes utilisateurs - -Que ce soit les membres de l'association, comme les membres actifs, il faut -prendre les précautions pour s'assurer que ses identifiants ne fuient pas dans -la nature : - - * **Ne pas avoir de comptes locaux avec des mots de passe actifs.** - Un compte avec possibilité d'authentification par mot de passe DOIT être - dans l'annuaire LDAP. Cela permet de faciliter le changement de mot de - passe et ne pas laisser des mots de passe cassés traîner. - - * **Ne pas partager un compte.** - Et oui, on évite de filer son mot de passe à son voisin. - - * **Avoir un mot de passe solide.** - `toto2345` n'est pas un bon mot de passe et prend en moyenne moins de 5 - minutes à être bruteforcée avec - [john](https://fr.wikipedia.org/wiki/John_the_Ripper). - - * **Favoriser l'authentification par paire de clées.** - Pour les services le permettant (SSH, Git...), il est préférable d'avoir - une paire de clé. Une clé privée ne doit jamais quitter le périphérique - où elle a été créée (que ça soit un token matériel ou une machine Linux). - Il est préférable de protéger la clé privée par un mot de passe. - Ainsi si une de vos machine est compromise, vous pouvez révoquer seulement - sa clé et tracer où elle a été utilisée. - - * **Favoriser la double authentification.** - Pour les services critiques (paiement, accès root...) il est préférable - d'ajouter un second facteur d'authentification et d'alerter l'équipe si - seulement le premier facteur a réussi mais le second a échoué. - Pour les services Web, voir le standard WebAuthn. Pour OpenSSH il existe - des intégrations avec des applications de second authentification. - - * **Utiliser un gestionnaire de mots de passe pour les secrets partagés.** - Pour les secrets partagés au sein de l'équipe technique, on les chiffre - pour les clés privées de chaque administrateur. - -## Sécurité des logiciels développés - - * **Ne pas fixer strictement les versions des paquets.** - Il faut s'assurer que les contraintes sur les dépendances permettent - d'obtenir les mises à jour de sécurité. Souvent il n'est que nécessaire - de fixer la version majeure (`~=2.1`, plutôt que `==2.1.1`). - - * **Privilégier le gestionnaire de paquet de la distribution.** - La distribution rétroporte les mises à jour de sécurité. Il est donc de - bon goût d'utiliser le plus possible ses paquets pour simplifier la mise - à jour de l'ensemble de l'infrastructure. - - * **Utiliser des outils de linting avec des règles de sécurité.** - Les bons outils de linting connaissent les patterns pouvant potentiellement - se traduire en faille de sécurité. - - * **Lancer le logiciel en non-privilégiés.** - Un logiciel ne devrait jamais avoir besoin de `root` ou de `sudo`. - Lors de l'écriture du service, on peut également ajouter des protections - supplémentaires pour augmenter l'isolation. - -## Sécurité de l'infrastructure - - * **Faire ses backups, et vérifier qu'elles marchent.** - - * **Faire des scans des ports ouverts.** - Pour cela on peut lancer `nmap` sur la plage d'adresses IP. - - * **Monitorer et alerter.** - - * **Segmenter les services.** - Isoler les services sur différentes machines et augmenter l'indépendance - permet d'améliorer la robustesse de l'infrastructure. diff --git a/howto/delete_user.md b/howto/supprimer_utilisateur.md similarity index 53% rename from howto/delete_user.md rename to howto/supprimer_utilisateur.md index 9eb69d4..4db2da9 100644 --- a/howto/delete_user.md +++ b/howto/supprimer_utilisateur.md @@ -1,62 +1,64 @@ # 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 +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, ce petit guide est là pour rappeler tout ce qu'il ne faut pas oublier. +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. ## 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-backupées par l'utilisateurice, ne plus avoir accès aux services qui -neccessite 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. - +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. ## Re2o -Il faut bien un début, c'est sur l'intranet qu'on commence par supprimer/ -archiver quelqu'un⋅e. +Il faut bien un début, c'est sur l'intranet qu'on commence par +supprimer/archiver quelqu'un⋅e. ### 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. +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). +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). ### Supprimer sur Re2o Il faut aller dans l'interface d'administration -https://re2o.crans.org/admin/users/user/ et supprimer l'user. Il va falloir + 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. - +`yson-partou`, puis taper `cn=Utilisateurs` et s'assurer que `cat cn={pseudo}` +ne renvoie rien. ## 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}`. +Il suffit de faire un `sudo rm -rf /home/{pseudo}`, pour supprimer le home. De +même pour les mails dans `/var/mail/{pseudo}`. ## Backups @@ -68,18 +70,19 @@ pour supprimer `/backup/borg-adh/home/{pseudo}`. non-conservation de données personnelles (même si les backup ne sont pas concernées par le RGPD). - ## 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 : +par se rendre dans l'interface d'administration de Gitlab, section utilisateurs +: [https://gitlab.crans.org/admin/users](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). +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). ## Owncloud @@ -88,7 +91,6 @@ utilisateurices : [https://owncloud.crans.org/settings/users](https://owncloud.crans.org/settings/users), puis de chercher le compte et de simplement le supprimer. - ## Mailman On commence par se rendre dans [Django-Admin](https://lists.crans.org/admin/). @@ -97,19 +99,19 @@ 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 bazard 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 nouveau -propriétaire (c'est pas obligatoire mais alors c'est root@crans.org le -propriétaire par défaut, ce qui n'est pas une solution durable) +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 root@crans.org +le propriétaire par défaut, ce qui n'est pas une solution durable). ## 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 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 @@ -120,19 +122,18 @@ des personnes n'ayant pas de compte crans, mais il faudra le WikiNom. 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). +`rm /etc/thelounge/logs/{pseudo}` et `rm /etc/thelounge/logs/{pseudo}.sqlite3` +(pour l'historique des messages). ## 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). +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). ## 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. +peuvent contenir des données personnelles. La personne devra aller voir les +admins de ces services pour supprimer les données. diff --git a/infrastructure/README.md b/infrastructure/README.md new file mode 100644 index 0000000..9ebf9a6 --- /dev/null +++ b/infrastructure/README.md @@ -0,0 +1,20 @@ +# Infrastructure + +## Présentation + +Ce dossier contient toute la documentation concernant l'infrastructure du +Crans, c'est à dire les machines, les VM (machines virtuelles), les réseaux +virtuels ou encore le fonctionnement des services internes au Crans (les LDAP, +PostgreSQL, ...). + +## Organisation + +* [`machines`](machines) : contient la documentation de l'ensemble des + machines physiques et virtuelles du Crans. On y inclut également par extension + les appareils physiques (comme les switchs). + +* [`reseaux`](reseaux) : documentation sur les réseaux (virtuels ou non) + utilisés au Crans, et sur leur utilisation. + +* [`services`](services) : documentation sur les services mis à disposition + par le Crans et pour le Crans (les LDAP, PostgreSQL, le CAS, ...). diff --git a/infrastructure/cachan.md b/infrastructure/cachan.md deleted file mode 100644 index 272ee0a..0000000 --- a/infrastructure/cachan.md +++ /dev/null @@ -1,16 +0,0 @@ -# Infrastructure restant Cachan sur le début de l'année 2022 - -Le temps d'avoir un système de backups opérationnel chez Aurore et ViaRézo, -trois serveurs sont encore présents à Cachan, à savoir Charybde, Zephir et Omnomnom. - - -## Plan d'adressage - -| VLAN | Bloc d'IPv4 | Bloc d'IPv6 | Utilisation | -|------|---------------------|-----------------------------------------|----------------| -| 8 | `82.65.62.126` | `2a01:e0a:9d4:e1b0:a873:65ff:fe63:6f77` | Freebox | -| 10 | `172.17.10.0/24` | `fd00:0:0:10::/64` | cachan-adm | - - -### ADM -Le réseau ADM est bridgé sur Charybde au réseau d'administration de Saclay. diff --git a/infrastructure/cluster-adh.md b/infrastructure/cluster-adh.md deleted file mode 100644 index 2ad2f6e..0000000 --- a/infrastructure/cluster-adh.md +++ /dev/null @@ -1,8 +0,0 @@ -# Cluster adhérents - -Le Crans dispose d'un cluster de virtualisation [Proxmox](/tools/proxmox.md) comptant en date du 8 décembre 2021 deux virtualiseurs, à savoir : - * `odlyd` - * `stitch` - * `gulp` - -Le stockage des machines virtuelles de ce cluster est fait sur `cameron` dans le dataset `pool/vm-adh` via le VLAN `san`. diff --git a/infrastructure/debian.md b/infrastructure/debian.md deleted file mode 100644 index 075d5c5..0000000 --- a/infrastructure/debian.md +++ /dev/null @@ -1,24 +0,0 @@ -# Debian - -C'est le SEUL os qu'on utilise au crans. - -## Bookworm - -Voilà la liste des machines qui ont été passées sous bookworm : - - wall-e (100) - - eclat (104) - - gitlab-ci (106) - - roundcube (107) - - voyager (109) - - mailman (110) - - belenios (111) - - ptf (113) - - flirt (114) - - boeing (117) - - cas (120) - - ecilis (122) - - trinity (123) - - redisdead (124) - - routeur-2754 (127) - - romanesco (128) - - helloworld (131) diff --git a/infrastructure/ldap-adh.md b/infrastructure/ldap-adh.md deleted file mode 100644 index 80aa910..0000000 --- a/infrastructure/ldap-adh.md +++ /dev/null @@ -1,81 +0,0 @@ -# LDAP Adhérents - -Le Crans dispose d'une base de données stockant les machines des adhérents disposant d'une connexion active et accessible vie le protocole LDAP. - -## Connexion - -Le serveur LDAP est hébergé sur la machine `flirt` et est accessible sur le port 389. Pour s'y connecter, on peut faire une redirection de ports comme par exemple : - -```bash -ssh -L 1636:172.16.10.114:636 tealc.adm.crans.org -J zamok.adm.crans.org -``` - -Le plus simple est d'utiliser `shelldap`, permettant de naviguer simplement à travers la base (voir [la documentation sur le LDAP admin](ldap.md)). - -## Schéma - -Voici la hiérarchie actuelle du LDAP (mars 2023) : - -``` -dc=adh,dc=crans,dc=org -| -+-cn=admin -| -+-cn=membership -| -+-cn=reader -| -+-ou=users -| +-cn=user (inetOrgPerson) -| -+-ou=clubs -| +-o=club (organization) -| -+-ou=hosts -| +-cn=machine (device, ipHost, ieee802Device) -| -+-ou=networks - +-ipNetworkNumber= (ipNetwork, ipHost) -``` - -## Utilisateurs - -Les adhérents sont ajoutés dans `ou=users` et ont les attributs suivants : - * `cn`: le pseudo de l'adhérent - * `givenName`: le prénom de l'adhérent - * `sn`: le nom de famille de l'adhérent - * `mail`: l'adresse email de l'adhérent - * `postalAddress`: l'adresse postale de l'adhérent (au format 1 Rue Machin, 75000 Ville) - * `telephoneNumber`: le numéro de téléphone de l'adhérent - -L'attribut `description` est utilisé afin de stocker des informations supplémentaires: - * `birthDate`: la date de naissance de l'adhérent au format `YYYY-MM-DD` - * `birthLocation`: la ville de naissance de l'adhérent - * `membershipStart`: la date de la première adhésion de l'adhérent au format `YYYY-MM-DD` - * `membershipEnd`: la date de fin de l'adhésion de l'adhérent au format `YYYY-MM-DD` - * `re2oId`: l'identifiant d'utilisateur de l'adhérent dans l'intranet - -# Clubs - -Les clubs sont ajoutés dans `ou=clubs` et ont les attributs suivants : - * `o`: le nom du club - * `description`: le pseudo de l'adhérent responsable du club - -# Machines - -Les machines sont ajoutées dans `ou=hosts` et ont les attributs suivants : - * `cn`: le nom de la machine - * `ipHostNumber`: les addresses IP de la machine - * `macAddress`: l'adresse MAC de la machine - * `description`: l'ouverture de ports de la machine - * `owner`: le dn du propriétaire de la machine (utilisateur ou club) - -# Réseaux - -Les sous-réseaux adhérents sont ajoutés dans `ou=networks` et ont les attributs suivants : - * `dn`: le nom du sous-réseau - * `cn`: le pseudo de l'adhérent propriétaire du sous-réseau - * `description` (optionnel) : deux NSRecord et un DSRecord du sous-réseau - * `ipHostNumber`: IPv6 interface avec le sous-réseau - * `ipNetMaskNumber`: masque de sous-réseau - * `ipNetworkNumber`: première IPv6 du sous-réseau diff --git a/infrastructure/machines/debian.md b/infrastructure/machines/debian.md new file mode 100644 index 0000000..38420f0 --- /dev/null +++ b/infrastructure/machines/debian.md @@ -0,0 +1,41 @@ +# Debian + +C'est le SEUL os qu'on utilise au crans. + +## Bookworm + +Voilà la liste des machines qui ont été passées sous bookworm : + +* wall-e (100) + +* eclat (104) + +* gitlab-ci (106) + +* roundcube (107) + +* voyager (109) + +* mailman (110) + +* belenios (111) + +* ptf (113) + +* flirt (114) + +* boeing (117) + +* cas (120) + +* ecilis (122) + +* trinity (123) + +* redisdead (124) + +* routeur-2754 (127) + +* romanesco (128) + +* helloworld (131) diff --git a/infrastructure/switch/arista.md b/infrastructure/machines/physiques/arista.md similarity index 55% rename from infrastructure/switch/arista.md rename to infrastructure/machines/physiques/arista.md index 7c178ce..dc11b46 100644 --- a/infrastructure/switch/arista.md +++ b/infrastructure/machines/physiques/arista.md @@ -1,6 +1,8 @@ # Arista 7150S-24 -Le CRANS possède des switches [Arista 7150S-24](https://www.arista.com/en/products/7150-series) avec 24 ports SFP/SFP+. +Le CRANS possède des switches +[Arista 7150S-24](https://www.arista.com/en/products/7150-series) avec 24 ports +SFP/SFP+. ## Se connecter au switch @@ -8,21 +10,28 @@ Il existe différentes façons de se connecter au switch. ### Port console en série -Les switches Arista ont un port série au format RJ-45, il suffit de brancher un cable USB-Série+Série-Ethernet et d'utiliser `screen`. +Les switches Arista ont un port série au format RJ-45, il suffit de brancher un +cable USB-Série+Série-Ethernet et d'utiliser `screen`. Par exemple : + ```bash sudo screen /dev/ttyUSB0 ``` -Pour éviter de lancer screen en root, il est également possible d'ajouter son utilisateur dans le groupe `dialout` avec `gpasswd -a $USER dialout`. +Pour éviter de lancer screen en root, il est également possible d'ajouter son +utilisateur dans le groupe `dialout` avec `gpasswd -a $USER dialout`. ### Port de management -> L'unité de management du switch est isolé du reste du switch. Il est donc impossible de ping les machines connectés au switch depuis l'interface d'administration. +> L'unité de management du switch est isolé du reste du switch. Il est donc +> impossible de ping les machines connectés au switch depuis l'interface +> d'administration. -Il est également possible de se connecter en SSH sur le port de management du switch, que l'on peut activer depuis la connexion en série : -``` +Il est également possible de se connecter en SSH sur le port de management du +switch, que l'on peut activer depuis la connexion en série : + +```txt switch>enable switch#config switch(config)#management ssh @@ -36,71 +45,86 @@ switch#write Il faut ensuite créer un utilisateur pour la connexion ssh. -``` +```txt switch(config)#username [nom d'utilisateur] secret [mot de passe] ``` On peut aussi préciser sa clé ssh -``` + +```txt switch(config)#username [nom d'utilisateur] sshkey file tftp:[ip du serveur tftp]/[fichier de clé publique] ``` ## Remettre à zéro le switch -Se connecter en série au boot du switch puis entrer dans Aboot en utilisant `^C` quand c'est indiqué puis entrer les commandes : -``` +Se connecter en série au boot du switch puis entrer dans Aboot en utilisant +`^C` quand c'est indiqué puis entrer les commandes : + +```txt Aboot#cd /mnt/flash Aboot#mv startup-config startup-config.old Aboot#exit ``` -Le switch va alors reboot avec la configuration par défaut. Le login par défaut de l'administrateur est `admin` et n'a pas de mot de passe. +Le switch va alors reboot avec la configuration par défaut. Le login par défaut +de l'administrateur est `admin` et n'a pas de mot de passe. ## Autoriser les SFP tiers -Par défaut le switch n'accepte que les SFP/SFP+ Arista, il est possible d'utiliser des SFP tiers (comme ceux de !FiberStore) avec les commandes suivantes : -``` +Par défaut le switch n'accepte que les SFP/SFP+ Arista, il est possible +d'utiliser des SFP tiers (comme ceux de !FiberStore) avec les commandes +suivantes : + +```bash switch>enable switch#bash [admin@switch ~]$ touch /mnt/flash/enable3px [admin@switch ~]$ sudo reboot ``` -Le switch va alors reboot en mode de compatibilité avec les SFP tiers. +Le switch va alors reboot en mode de compatibilité avec les SFP tiers. ## Actions d'administration ### Créer un VLAN -Pour que le switch accepte de commuter les trames taggées il faut créer le VLAN : -``` +Pour que le switch accepte de commuter les trames taggées il faut créer le +VLAN : + +```txt switch>enable switch#config switch(config)#vlan 2 switch(config-vlan-2)# ``` -Cela suffit à créer le VLAN, la liste des VLAN peut être affichée avec la commande `show vlan`. +Cela suffit à créer le VLAN, la liste des VLAN peut être affichée avec la +commande `show vlan`. ### Configurer les VLANs -On va commencer par la stratégie de bourrins. On va autoriser tous les VLANs sur le port courant. Pour cela, on le passe en mode trunk pour qu'il accepte de commuter sur tous les VLANs connus du switch : +On va commencer par la stratégie de bourrins. On va autoriser tous les VLANs +sur le port courant. Pour cela, on le passe en mode trunk pour qu'il accepte de +commuter sur tous les VLANs connus du switch : -``` +```txt switch(config)#interface ethernet 1 switch(config-if-Et1)#switchport mode trunk ``` -C'est un peu violent et en plus ça a le mauvais gout de tagger tous les VLANs sauf celui dit natif (par défaut celui de plus petit nombre défini ou 1). On peut remédier au deuxième point en lui disant de tagger son VLAN natif : +C'est un peu violent et en plus ça a le mauvais gout de tagger tous les VLANs +sauf celui dit natif (par défaut celui de plus petit nombre défini ou 1). On +peut remédier au deuxième point en lui disant de tagger son VLAN natif : -``` +```txt switch(config)#interface ethernet 1 switch(config-if-Et1)# switchport trunk native vlan tag ``` -Et si on veut restreindre le caractère bourrin d'autoriser tous les VLANs, on peut specifier lesquels nous intéressent (et même en ajouter à posteriori) : +Et si on veut restreindre le caractère bourrin d'autoriser tous les VLANs, on +peut specifier lesquels nous intéressent (et même en ajouter à posteriori) : -``` +```txt switch(config)#interface ethernet 1 switch(config-if-Et1)# switchport trunk allowed vlan 1-3,9-77,999 switch(config-if-Et1)# switchport trunk allowed vlan add 7 @@ -108,66 +132,93 @@ switch(config-if-Et1)# switchport trunk allowed vlan add 7 ### Configurer le LACP -Pour configurer le LACP entre 2 ports, on commence par les sélectionner dans l'interface de configuration, puis on lui dit de faire du LACP sur ces deux ports. On utilise le plus petit nombre de port sélectionné comme identifiant de LACP. +Pour configurer le LACP entre 2 ports, on commence par les sélectionner dans +l'interface de configuration, puis on lui dit de faire du LACP sur ces deux +ports. On utilise le plus petit nombre de port sélectionné comme identifiant de +LACP. -``` +```txt thor(config)#interface ethernet 3-4 thor(config-if-Et3-4)#channel group 3 mode active thor(config-if-Et3-4)#exit ``` -Puis ensuite on peut configurer le reste (VLANs et tout …) dans l'interface Port-Channel 3. +Puis ensuite on peut configurer le reste (VLANs et tout …) dans l'interface +Port-Channel 3. -``` +```txt thor(config)#interface Port-Channel 3 thor(config-if-Po3)# ``` ### Mettre à jour le switch -> C'est pas forcément nécessaire et ça peut tout casser, si néanmoins tu ressens la nécessité de le faire, voila comment. +> C'est pas forcément nécessaire et ça peut tout casser, si néanmoins tu +> ressens la nécessité de le faire, voila comment. -Bon la première étape, c'est de trouver les images de EOS. Et là, c'est déjà pas trivial de les trouver… Arista fait payer les images de ses OS et du coup, il faut chercher par des moyens détourner de les trouver. Nous on les avaient trouvé là http://41.78.188.108/sw/eos/ mais rien n'assure que cela vous aidera. +Bon la première étape, c'est de trouver les images de EOS. Et là, c'est déjà +pas trivial de les trouver… Arista fait payer les images de ses OS et du coup, +il faut chercher par des moyens détourner de les trouver. Nous on les avaient +trouvé là mais rien n'assure que cela vous aidera. -Ensuite on va télécharger l'image sur le switch, mais là un problème de place pourrait survenir, il n'y a pas beaucoup d'espace mémoire dans la mémoire flash et il faudra probablement supprimer l'ancienne image avant de télécharger la nouvelle (considérer la copier quelques part avant pour la sauvegarder en utilisant par exemple {{{copy [ancienne image] scp:[user]@[ip du serveur]/[chemin vers le home du user]/[ancienne image]}}}). +Ensuite on va télécharger l'image sur le switch, mais là un problème de place +pourrait survenir, il n'y a pas beaucoup d'espace mémoire dans la mémoire flash +et il faudra probablement supprimer l'ancienne image avant de télécharger la +nouvelle (considérer la copier quelques part avant pour la sauvegarder en +utilisant par exemple : +```bash +copy [ancienne image] scp:[user]@[ip du serveur]/[chemin vers le home du user]/[ancienne image] ``` + +```txt georges(config)# delete [ancienne image] #### uniquement si nécessaire georges(config)# copy tftp:[ip du serveur tftp]/[nouvelle image] flash:/[nouvelle image] ``` Et là on va dire à l'os de boot dessus : -``` +```txt georges(config)# boot system flash:/[nouvelle image] ``` -Il se peut que la commande rate à cause de manque d'espace sur la mémoire flash. Si c'est le cas, je vous conseille de recopier l'ancienne image sur le switch et de passer votre chemin. Mais si vous êtes vraiment tenieux, vous pouvez essayer de stocker l'image autre part et ensuite de la deployer (mais c'est à vos risques et périls mais surtout à celui du switch). Si vous avez cependant réussi à déployer l'image, ''il ne faut surtout pas oublier de sauvegarder les modifications''. +Il se peut que la commande rate à cause de manque d'espace sur la mémoire +flash. Si c'est le cas, je vous conseille de recopier l'ancienne image sur le +switch et de passer votre chemin. Mais si vous êtes vraiment tenieux, vous +pouvez essayer de stocker l'image autre part et ensuite de la deployer (mais +c'est à vos risques et périls mais surtout à celui du switch). Si vous avez +cependant réussi à déployer l'image, "il ne faut surtout pas oublier de +sauvegarder les modifications". -``` +```txt georges(config)#write ``` ## Rendre compatible le switch aux personnes ayant de l'hyperacousie -Par défaut les `fan-speed` sont à 80% ce qui donne un bruit de disqueuse, tout en gardant des températures très basses tout en ayant aucune charge. +Par défaut les `fan-speed` sont à 80% ce qui donne un bruit de disqueuse, tout +en gardant des températures très basses tout en ayant aucune charge. -Il peut être intéressant de baisser au moins temporairement la vitesse si vous travaillez à côté du switch et que vous êtes en visio. Le bruit généré n'est pas linéaire avec la vitesse du ventilo et trop baisser la vitesse peut éteindre violemment le switch dès qu'il chauffe trop. Déjà 10% de vitesse en moins réduit grandement le bruit. +Il peut être intéressant de baisser au moins temporairement la vitesse si vous +travaillez à côté du switch et que vous êtes en visio. Le bruit généré n'est +pas linéaire avec la vitesse du ventilo et trop baisser la vitesse peut +éteindre violemment le switch dès qu'il chauffe trop. Déjà 10% de vitesse en +moins réduit grandement le bruit. Par les observations d'erdnaxe en visio, 60% est un bon compromis, -``` +```txt georges(config)#environment fan-speed override 60 ``` Pour voir la vitesse actuelle, -``` +```txt georges(config)#show environment cooling ``` Pour remettre le mode auto, -``` +```txt georges(config)#environment fan-speed auto ``` diff --git a/infrastructure/machines/physiques/cluster-adh.md b/infrastructure/machines/physiques/cluster-adh.md new file mode 100644 index 0000000..5b55973 --- /dev/null +++ b/infrastructure/machines/physiques/cluster-adh.md @@ -0,0 +1,13 @@ +# Cluster adhérents + +Le Crans dispose d'un cluster de virtualisation [Proxmox](/tools/proxmox.md) +comptant en date du 8 décembre 2021 deux virtualiseurs, à savoir : + +* `odlyd` + +* `stitch` + +* `gulp` + +Le stockage des machines virtuelles de ce cluster est fait sur `cameron` dans +le dataset `pool/vm-adh` via le VLAN `san`. diff --git a/infrastructure/servers.md b/infrastructure/machines/physiques/serveurs.md similarity index 93% rename from infrastructure/servers.md rename to infrastructure/machines/physiques/serveurs.md index 3ccc899..15eb89e 100644 --- a/infrastructure/servers.md +++ b/infrastructure/machines/physiques/serveurs.md @@ -3,7 +3,7 @@ Voici la liste des serveurs du Crans : | Nom du serveur | Modèle | Numéro de série | Référence | Date de la facture | Fin de garantie | Fonction | -|-|-|-|-|-|-|-| +|----------------|--------|-----------------|-----------|--------------------|-----------------|----------| | tealc | Syneto | à reporter ici | | N/A | N/A | Baie de stockage des disques des VMs et des homes des nounous | | cameron | Syneto | à reporter ici | | N/A | N/A | Baie de stockage des homes et des mails des adhérents | | sam | HP ProLiant DL360 G8 | à reporter ici | | N/A | N/A | Virtualiseur | diff --git a/infrastructure/machines/physiques/sfp.md b/infrastructure/machines/physiques/sfp.md new file mode 100644 index 0000000..36d4683 --- /dev/null +++ b/infrastructure/machines/physiques/sfp.md @@ -0,0 +1,38 @@ +# Optiques SFP(+) et fibres optiques + +Le Crans dispose d'un backbone 10G pour relier ses serveurs, les modules +optiques utilisés sont des [10GBASE-SR compatibles +Arista](https://www.fs.com/fr/products/36982.html) (afin d'être compatibles +avec nos switches Arista). Ces modules sont reliés par des [jarretières +optiques LC LC OM4](https://www.fs.com/fr/products/40220.html). + +Pour son interconnexion avec ViaRézo et Aurore le Crans utilise des modules +optiques [10GBASE-LR](https://www.fs.com/fr/products/36983.html) reliés aux +platines de fibres par des [jarretières optiques LC SC +OS2](https://www.fs.com/fr/products/96102.html). + +## Qu'est-ce qu'est une optique SFP ? + +C'est un module actif composé d'un micro-contrôlleur (par exemple un STM32 +Cortex-M3) et d'un ou plusieurs lasers. Il permet de relier une fibre optique +à un switch. + +### Codage des optiques + +Une optique est codé avec un identifiant constructeur, changeable avec une +codeuse. Un switch d'un certain constructeur n'acceptera que certains codes. +Par exemple sur des Quanta, coder correctement les optiques permet de collecter +des métriques tel que leur température. Sur certains switchs il est possible +d'activer le support des optiques avec le mauvais code. + +## Choses à ne pas faire + +Il peut être tentant d'acheter une optique 10km pour une liaison de 100m en +partant sur l'idée que « qui peut le plus, peut le moins ». Dans le cas de +l'optique c'est faux. Utiliser une optique trop puissante sur une distance +beaucoup plus petite que son design va brûler le récepteur. + +Une optique chauffe et un laser qui chauffe dérive légèrement. Malgré qu'il +y ait des plaques à effet Peltier dans certaines optiques pour compenser, il +reste une bonne idée de vérifier que les optiques sont correctement +refroidites par le switch. diff --git a/infrastructure/thot.md b/infrastructure/machines/physiques/thot.md similarity index 78% rename from infrastructure/thot.md rename to infrastructure/machines/physiques/thot.md index 94a294e..505cd85 100644 --- a/infrastructure/thot.md +++ b/infrastructure/machines/physiques/thot.md @@ -1,13 +1,14 @@ # Thot -Ce document détaille la procédure d'installation qui a été suivi pour installer -thot. Elle n'a probablement pas sa place ici, je la déplacerais le moment venue. +Ce document détaille la procédure d'installation qui a été suivi pour installer +thot. ## Installation initiale de debian -On utilise normalement l'installateur de debian en utilisant le partitonnement + +On utilise normalement l'installateur de debian en utilisant le partitonnement suivant : -``` +```txt +---------------------------+ +--------------------------+ +-----------+---------------+ | +-----------------------+ | | +----------------------+ | | /dev/sda1 | /dev/sda2 | | | /dev/sda3 | | | | /dev/sda4 | | @@ -38,51 +39,67 @@ suivant : Et on finit en installant GRUB sur /dev/sda. ## Dropbear -On va maintenant installer un petit serveur ssh dans le initramfs pour qu'au + +On va maintenant installer un petit serveur ssh dans le initramfs pour qu'au boot du serveur on puisse se ssh et déchiffrer les disques. + ```bash sudo apt install dropbear-initramfs ``` -On edite ensuite les options du logiciel dans -`/etc/dropbear-initramfs/config` pour lui préciser des options de lancement: + +On edite ensuite les options du logiciel dans +`/etc/dropbear-initramfs/config` pour lui préciser des options de lancement : + ```bash DROPBEAR_OPTIONS="-I 180 -j -k -p 2222 -s" ``` -L'option importante qu'on set ici est `-p 2222` qui dit au serveur ssh d'écouter -sur le port 2222 plutôt que 22. On fait ça pour qu'un client ssh ne croit pas -que l'host ait changé entre l'état au boot et l'état courant. -En plus de ça on va fournir au serveur une clé ssh publique via laquelle on +L'option importante qu'on set ici est `-p 2222` qui dit au serveur ssh +d'écouter sur le port 2222 plutôt que 22. On fait ça pour qu'un client ssh ne +croit pas que l'host ait changé entre l'état au boot et l'état courant. + +En plus de ça on va fournir au serveur une clé ssh publique via laquelle on pourra se connecter. Pour générer une clé ssh (`ssh-keygen(1)`) on fait -``` + +```bash ssh-keygen -t ed25519 -f ``` -Puis on copie la clé publique de `.pub` dans + +Puis on copie la clé publique de `.pub` dans `/etc/dropbear-initramfs/authorized_keys`. ### Configuration réseau -On va aussi configurer le initramfs pour configurer ses interfaces réseaux au -boot. On édite le fichier `/etc/initramfs-tools/initramfs.conf` et on rajoute -une variable `IP` à la fin du fichier: - - Pour qu'il prenne une ip statique + +On va aussi configurer le initramfs pour configurer ses interfaces réseaux au +boot. On édite le fichier `/etc/initramfs-tools/initramfs.conf` et on rajoute +une variable `IP` à la fin du fichier : + +* Pour qu'il prenne une ip statique + ```bash IP=::::: ``` - - Pour qu'il prenne une ip via dhcp + +* Pour qu'il prenne une ip via dhcp + ```bash IP=::::::dhcp ``` Ensuite, on régénère le initramfs -``` + +```bash initramfs -u ``` -Pour tester que ça fonctionne, on reboot et après le chargement du initramfs, on -fait un `ssh -i -p ` suivi d'un `cryptroot-unlock` qui devrait -vous demander la passphrase pour déchiffrer le disque. +Pour tester que ça fonctionne, on reboot et après le chargement du initramfs, +on fait un `ssh -i -p ` suivi d'un `cryptroot-unlock` qui +devrait vous demander la passphrase pour déchiffrer le disque. ## Installation de proxmox -https://pve.proxmox.com/wiki/Install_Proxmox_VE_on_Debian_11_Bullseye + + + ## Installation de zfs -https://timor.site/2021/11/creating-fully-encrypted-zfs-pool/ + + diff --git a/infrastructure/whoswho.md b/infrastructure/machines/qui_est_qui.md similarity index 64% rename from infrastructure/whoswho.md rename to infrastructure/machines/qui_est_qui.md index dbb0e39..b392c44 100644 --- a/infrastructure/whoswho.md +++ b/infrastructure/machines/qui_est_qui.md @@ -1,28 +1,37 @@ # Who's who -Bon, on aime bien choisir des noms rigolos pour les vms, mais parfois ça amène à -un peu de confusion. Du coup, on va répertorier ici les différentes machines -(virtuelles ou non) et leurs différentes fonctions. Si une machine n'est pas -renseigné, n'hésitez pas à aller jeter un coup d'œil sur ansible ou à raller sur -#roots :) +Bon, on aime bien choisir des noms rigolos pour les vms, mais parfois ça +amène à un peu de confusion. Du coup, on va répertorier ici les différentes +machines (virtuelles ou non) et leurs différentes fonctions. Si une machine +n'est pas renseigné, n'hésitez pas à aller jeter un coup d'œil sur ansible +ou à raller sur #roots :) ## Zamok -C'est le serveur physique des adhérent⋅es. Il sert principalement à deux choses, -donner un terminal aux adhérents et destination finale des mails. C'est aussi -lui qui hébèrge les pages personnelles des adhérent⋅es. Le [webirc -persistent](https://webirc.crans.org) y est aussi hébergé. + +C'est le serveur physique des adhérent⋅es. Il sert principalement à deux +choses, donner un terminal aux adhérents et destination finale des mails. +C'est aussi lui qui hébèrge les pages personnelles des adhérent⋅es. Le +[webirc persistent](https://webirc.crans.org) y est aussi hébergé. Liste des logiciels installés : - - postfix + opendkim + rspamd - - apache (bouh) - - webirc + +* postfix + opendkim + rspamd + +* apache (bouh) + +* webirc Redémarrage et mise à jour : - - pas de redémarrage automatique - - mise à jour manuelle de linux et nftables - - éviter de redémarrer car les adhérent⋅es peuvent avoir des scripts qui tournent + +* pas de redémarrage automatique + +* mise à jour manuelle de linux et nftables + +* éviter de redémarrer car les adhérent⋅es peuvent avoir des scripts qui + tournent ## Tealc + C'est le serveur qui hébèrge les disques de nos vms. C'est un gros machins pleins de disques qui utilise zfs pour exposer une pool en nfs sur le réseau pour qu'elle soit montée par le cluster proxmox. Il héberge aussi un serveur @@ -31,143 +40,194 @@ crans. C'est aussi lui qui héberge les homes des nounous et le mirroir des logiciels. Liste de logiciels installés : - - zfs - - postgres - - nginx + +* zfs + +* postgres + +* nginx Redémarrage et mise à jour : - - pas de redémarrage automatique - - mise à jour manuelle de postgresql - - éviter de redémarrer car tous les services perdent leur disques + +* pas de redémarrage automatique + +* mise à jour manuelle de postgresql + +* éviter de redémarrer car tous les services perdent leur disques ## Cameron -C'est le serveur qui héberge les homes des adhérent⋅es et leurs répertoires -mails. C'est aussi depuis lui que sont effectués les backups quotidiennes des -données des adhérent⋅es. Une de ses pools sert à stocker et à exposer sur le -réseau les disques des vms des adhérent⋅es pour qu'elles soit montées sur le -cluster proxmox des adhérent⋅es. + +C'est le serveur qui héberge les homes des adhérent⋅es et leurs +répertoires mails. C'est aussi depuis lui que sont effectués les backups +quotidiennes des données des adhérent⋅es. Une de ses pools sert à stocker +et à exposer sur le réseau les disques des vms des adhérent⋅es pour +qu'elles soit montées sur le cluster proxmox des adhérent⋅es. Liste de logiciels installés : - - zfs + +* zfs Redémarrage et mise à jour : - - pas de redémarrage automatique - - éviter de redémarrer car tous les adhérents perdent leur disques + +* pas de redémarrage automatique + +* éviter de redémarrer car tous les adhérents perdent leur disques ## Sam, Daniel, Jack : le cluster proxmox du crans + Les trois serveurs sont organisés en un cluster proxmox pour hébergé les machines virtuelles du crans. Ils hébergent en sus une copie en lecture seule des bases de données et un replicat du serveur ldap. Liste de logiciels installés : - - proxmox - - postgres - - slapd + +* proxmox + +* postgres + +* slapd Redémarrage : - - pas de redémarrage automatique - - migrer les VM avant de redémarrer + +* pas de redémarrage automatique + +* migrer les VM avant de redémarrer ### wall-e : le serveur ldap + C'est le serveur qui hébèrge le ldap d'administration. Sur celui-ci sont -consignés toutes nos machines, les utilisateurices qui ont accès au réseau et -les privilèges dont iel dispose sur celui-ci, la configuration des zones dns. +consignés toutes nos machines, les utilisateurices qui ont accès au réseau +et les privilèges dont iel dispose sur celui-ci, la configuration des zones +dns. Liste de logiciels installés : - - slapd + +* slapd Redémarrage et mise à jour automatique ### routeur-{sam,daniel,jack} : les routeurs -Les routeurs sont responsables de connecter le reste du crans au reste du monde. -Chacun d'entre eux est équipé pour pouvoir effectuer cette tache seule. À tout -instant un seul d'entre eux s'occupe du routage et les autres attendent. Si un -problème devait arriver au routeur actif, l'un des deux prendraient le relai via -keepalived. Chacun des routeurs disposent d'une copie du parefeu généré par un -script, d'un serveur radvd pour broadcast des router advertisement sur le -réseau des adhérent⋅es, d'un serveur dhcp pour aider les machines des -adhérent⋅es à configurer leur ipv4 et d'un serveur bird pour échanger des routes -avec nos isps (aurore et via). + +Les routeurs sont responsables de connecter le reste du crans au reste du +monde. Chacun d'entre eux est équipé pour pouvoir effectuer cette tache +seule. À tout instant un seul d'entre eux s'occupe du routage et les autres +attendent. Si un problème devait arriver au routeur actif, l'un des deux +prendraient le relai via keepalived. Chacun des routeurs disposent d'une copie +du parefeu généré par un script, d'un serveur radvd pour broadcast des +router advertisement sur le réseau des adhérent⋅es, d'un serveur dhcp pour +aider les machines des adhérent⋅es à configurer leur ipv4 et d'un serveur +bird pour échanger des routes avec nos isps (aurore et via). Liste de logiciels installés : - - nftables - - isc-dhcp-server - - radvd - - bird - - keepalived + +* nftables + +* isc-dhcp-server + +* radvd + +* bird + +* keepalived Redémarrage et mise à jour : - - pas de redémarrage automatique - - mise à jour manuelle de linux et nftables - - ne pas redémarrer plusieurs en même temps et faire attention avac routeur-sam car c'est notre routeur principal (un peu de downtime si on ne change pas les routes avant) + +* pas de redémarrage automatique + +* mise à jour manuelle de linux et nftables + +* ne pas redémarrer plusieurs en même temps et faire attention avec + routeur-sam car c'est notre routeur principal (un peu de downtime si on ne + change pas les routes avant) ### routeur-2754 : le routeur pour l'ENS + Ce routeur est responsable de connecter le Crans au VLAN 2754 de l'ENS. Redémarrage et mise à jour : - - pas de redémarrage automatique - - mise à jour manuelle de linux et nftables - - redémarrage manuel possible (surtout tant qu'il sert à rien) + +* pas de redémarrage automatique + +* mise à jour manuelle de linux et nftables + +* redémarrage manuel possible (surtout tant qu'il sert à rien) ### eclat : le mirroir publique + C'est la machine virtuelle qui synchronise les mirroirs de logiciels et les -expose au reste d'internet pour que les adhérent⋅es puissent télécharger les -logiciels. Le mirroir est hébergé sur tealc et c'est ce serveur que toutes nos -machines viennent intérroger pour se mettre à jour. Seul les machines -exterieures utilisent eclat. +expose au reste d'internet pour que les adhérent⋅es puissent télécharger +les logiciels. Le mirroir est hébergé sur tealc et c'est ce serveur que +toutes nos machines viennent intérroger pour se mettre à jour. Seul les +machines exterieures utilisent eclat. Liste de logiciels installés : - - rsyncd - - vsftpd - - nginx - - apt-mirror + +* rsyncd + +* vsftpd + +* nginx + +* apt-mirror Redémarrage et mise à jour automatique. ### gitzly : le serveur gitlab + C'est le serveur gitlab du crans. Redémarrage et mise à jour : - - redémarrage automatique - - mise à jour manuelle de gitlab + +* redémarrage automatique + +* mise à jour manuelle de gitlab ### gitlab-ci : le serveur d'intégration continue + C'est le serveur sur lesquels sont exectués les taches d'intégration continue grâce à docker (beurk). Redémarrage et mise à jour automatique. ### owncloud: le serveur owncloud + C'est le serveur owncloud du crans. Redémarrage et mise à jour : - - redémarrage automatique - - mise à jour manuelle de owncloud + +* redémarrage automatique + +* mise à jour manuelle de owncloud ### roundcube : le (seul) webmail -C'est le webmail sur lequel les adhérent⋅es peuvent consulter leur mails. C'est -un logiciel php. + +C'est le webmail sur lequel les adhérent⋅es peuvent consulter leur mails. +C'est un logiciel php. Redémarrage et mise à jour automatique. ### voyager : framadate & la meilleure vm -C'est la machine virtuelle qui héberge framadate (un logiciel php), et une base -de donnée mysql. Mais surtout c'est une vm qui a beaucoup servi de vms de tests -random, son état est donc chaotique et incertain. + +C'est la machine virtuelle qui héberge framadate (un logiciel php), et une +base de donnée mysql. Mais surtout c'est une vm qui a beaucoup servi de vms de +tests random, son état est donc chaotique et incertain. Redémarrage et mise à jour automatique. ### kenobi: les pads + C'est la machine virtuelle qui héberge les pads et les tmpads. Redémarrage et mise à jour automatique. ### ethercalc: les tableurs + C'est la machine virtuelle qui héberge les tabeurs ethercalc. Redémarrage et mise à jour automatique. ### mailman : les listes de diffusion + C'est la machine virtuelle qui héberge les listes de diffusion. On utilise mailman3, un logiciel django et la machine dispose aussi de son instance de postfix pour pouvoir envoyer et recevoir les mails. @@ -175,100 +235,124 @@ postfix pour pouvoir envoyer et recevoir les mails. Redémarrage et mise à jour automatique. ### belenios : la démocratie -C'est la machine virtuelle qui héberge le logiciel éponyme qui sert à organiser -des éléctions sécurisées. C'est un logiciel en ocaml, use with care or with L3 -info. + +C'est la machine virtuelle qui héberge le logiciel éponyme qui sert à +organiser des éléctions sécurisées. C'est un logiciel en ocaml, use with +care or with L3 info. Redémarrage et mise à jour automatique. ### apprentis : la machine virtuelle des apprenti⋅es + Play ground pour que les apprenti⋅es puissent s'amuser à faire ce qu'iels -veulent. À priori rien est installé dessus mais tout peut-être installé dessus. +veulent. À priori rien est installé dessus mais tout peut-être installé +dessus. Redémarrage et mise à jour automatique. ### ptf : la mémoire (fatiguée) + C'est le serveur ftp sur lequel est hebergé les vidéos des installs party du -crans. Il dispose d'un serveur vsftpd et d'un serveur nginx. Il est peu utilisé. +crans. Il dispose d'un serveur vsftpd et d'un serveur nginx. Il est peu +utilisé. Redémarrage et mise à jour automatique. ### flirt : le ldap des machines des adhérent⋅es + C'est la machine virtuelle qui héberge le ldap sur lequel sont consignés les machines virtuelles des adhérent⋅es et des clubs. Elle dispose d'un serveur -slapd. On a l'ambition de rassembler les deux ldap des adhérent⋅es un jour mais -ça risque de pas convergé (c.f. constellation). +slapd. On a l'ambition de rassembler les deux ldap des adhérent⋅es un jour +mais ça risque de pas convergé (c.f. constellation). Redémarrage et mise à jour automatique. ### neree : galene + C'est le serveur galene du crans, l'un des deux logiciels qu'on utilise pour faire de la visio conférence. Redémarrage et mise à jour automatique. -### jitsi: -C'est le serveur jitsi du crans, l'autre logiciel qu'on utilise pour faire -de la visio conférence. +### jitsi : visio-conférence + +C'est le serveur jitsi du crans, l'autre logiciel qu'on utilise pour faire de +la visio conférence. Redémarrage et mise à jour automatique. ### ferle : anchor ripe + C'est la machine virtuelle qu'on met à disposition du ripe pour être des bons élèves. On a donc pas accès à la machine. ### boeing : pont wireguard + C'est la machine qui héberge la plupart des ponts wireguard qu'on a vers l'exterieur (sputnik, thot, ft). Redémarrage et mise à jour automatique. ### fluxx : à bruler + Redémarrage et mise à jour automatique. ### linx : serveur d'hébergement de fichier + C'est la machine virtuelle qui héberge le logiciel éponyme. Redémarrage et mise à jour automatique. ### cas : cas + C'est le cas. (django-cas) Redémarrage et mise à jour automatique. ### fyre : monitoring + C'est la machine virtuelle qui monitore l'état de l'infrastructure. Il utilise la suite de logiciels prometheus, grafana et ninjaaa(bot). Redémarrage et mise à jour automatique. ### ecilis : dns de test + C'est une machine virtuelle qui fait partie de l'infrastructure de test et qui héberge un dns authoritaire (knot). Redémarrage et mise à jour automatique. ### trinity : pont matrix + C'est le pont matrix qui permet aux utilisateurices de matrix de participer aux discutions sur irc. Redémarrage : - - pas de redémarrage automatique - - le redémarrage déconnecte les utilisateurices + +* pas de redémarrage automatique + +* le redémarrage déconnecte les utilisateurices ### irc: le serveur irc + C'est le serveur irc du crans. Redémarrage : - - pas de redémarrage automatique - - le redémarrage déconnecte les utilisateurices + +* pas de redémarrage automatique + +* le redémarrage déconnecte les utilisateurices ### kiwi: le wiki -C'est le wiki du crans qui tourne avec moinmoin2 (c'est du python2 donc il faut pas mettre à jour debian qui va drop python2). + +C'est le wiki du crans qui tourne avec moinmoin2 (c'est du python2 donc il faut +pas mettre à jour debian qui va drop python2). Redémarrage et mise à jour automatique. ### redisdead : serveur mail principale + C'est le serveur mail principale du crans, c'est sur lui que les mails arrivent et de lui que les mails partent. Ce n'est cependant pas la destination finale des mails qui sont redirigés vers zamok. C'est un serveur postfix, mais il y a @@ -277,122 +361,158 @@ aussi un serveur opendkim et policyd sur la machine. Redémarrage et mise à jour automatique. ### en7 : la connexion de secours + L'ens nous a donné une ip de secours sur leur réseaux au cas où il y ait un -problème sur les routeurs et qu'on ait besoin de se connecter sur le réseaux. Il -est projetté d'y hébergé un serveur dns et un serveur mail. +problème sur les routeurs et qu'on ait besoin de se connecter sur le réseaux. +Il est projetté d'y hébergé un serveur dns et un serveur mail. Redémarrage : - - pas de redémarrage automatique - - redémarrage manuel possible (sauf en période de crise et faire attention si c'est votre point d'entrée adm) + +* pas de redémarrage automatique + +* redémarrage manuel possible (sauf en période de crise et faire attention si + c'est votre point d'entrée adm) ### owl : serveur pop3/imap + C'est le serveur qui expose aux adhérentes leur email en imap ou en pop3. Redémarrage et mise à jour automatique. ### re2o: la gestion des adhérent⋅es + C'est l'intranet du Crans. Redémarrage et mise à jour automatique. ### yson-partout: le ldap des adhérent⋅es + C'est le ldap qui liste les comptes des adhérent⋅es depuis re2o. Redémarrage et mise à jour automatique. ### helloworld: le serveur d'impression + C'est le serveur qui heberge le service web pour l'impression Redémarrage et mise à jour automatique. ### listenup: ??? + J'ai aucune idée de l'utilité de cette VM. Redémarrage : - - pas de redémarrage automatique -### netns: +* pas de redémarrage automatique + +### netns Redémarrage et mise à jour automatique. -### proxy-pve-adh: +### proxy-pve-adh + Comme son nom l'indique... Redémarrage et mise à jour automatique. ### romanesco: le dns récursif + C'est le serveur DNS récursif du Crans. Liste de logiciels installés : - - unbound + +* unbound Redémarrage et mise à jour automatique. ### silice: le dns + C'est le serveur DNS du Crans. Liste de logiciels installés : - - bind + +* bind Redémarrage et mise à jour automatique. ## Hodaur : le serverse proxy + C'est le reverse proxy. Liste de logiciels installés : - - nginx + +* nginx Redémarrage et mise à jour automatique. -### … (les serveur avec "-dev" dans le nom ou un nom très proche d'un serveur de la liste sont des serveurs de test qui ont plus ou moins la même conf que le serveur copié) +### ...-dev + +Les serveur avec "-dev" dans le nom ou un nom très proche d'un serveurs de la +liste sont des serveurs de test qui ont plus ou moins la même conf que le +serveur copié). ## Gulp, Odlyd, Stitch : le cluster proxmox des adhérent⋅es + Les trois serveurs sont organisés en un cluster proxmox pour hébergé les machines virtuelles des adhérent⋅es. Liste de logiciels installés : - - proxmox + +* proxmox Redémarrage : - - pas de redémarrage automatique - - migrer les VM avant de redémarrer + +* pas de redémarrage automatique + +* migrer les VM avant de redémarrer ## Thot, Ft : les serveurs de backups + Ces deux serveurs ne sont pas dans la baie mais à des endroits distincts pour -éviter qu'un accident dans la salle serveur détruise toutes les données. Thot -est chez via et ft chez auro.re (une chance sur deux que je me sois trompée et -que c'est l'inverse). Ce sont des serveurs proxmox, donc peu de choses tournent -sur les machines. On décrit dans les sections qui suiventt les vms qui sont -hébergés sur ces serveurs. +éviter qu'un accident dans la salle serveur détruise toutes les données. +Thot est chez via et ft chez auro.re (une chance sur deux que je me sois +trompée et que c'est l'inverse). Ce sont des serveurs proxmox, donc peu de +choses tournent sur les machines. On décrit dans les sections qui suivent les +vms qui sont hébergés sur ces serveurs. Liste de logiciels installés : - - proxmox + +* proxmox Redémarrage : - - pas de redémarrage automatique - - redémarrage manuel possible (éviter si l'autre serveur de backup à des problèmes car on a pas aacès directement aux machines en cas de problème) + +* pas de redémarrage automatique + +* redémarrage manuel possible (éviter si l'autre serveur de backup à des + problèmes car on a pas aacès directement aux machines en cas de problème) ## routeur-{ft,thot} : les routeurs + Ces deux machines virtuelles servent à connecter leur hyperviseur et les machines virtuelles qu'il héberge au reste du réseau d'administration via un tunnel wireguard dont l'autre pair est boeing. Liste de logiciels installés : - - wireguard + +* wireguard Redémarrage et mise à jour automatique. ## backup-{ft,thot} : les serveurs de backup + C'est sur ces machines virtuelles que sont effectivement faites les backups via borgmatic. Liste de logiciels installés : - - borgmatic + +* borgmatic Redémarrage et mise à jour automatique. ## Zbee : un serveur physique + Un serveur physique qui sert pas. Redémarrage : - - pas de redémarrage automatique \ No newline at end of file + +* pas de redémarrage automatique diff --git a/infrastructure/plan.md b/infrastructure/reseaux/plan.md similarity index 100% rename from infrastructure/plan.md rename to infrastructure/reseaux/plan.md diff --git a/infrastructure/services/README.md b/infrastructure/services/README.md new file mode 100644 index 0000000..7a3ac3b --- /dev/null +++ b/infrastructure/services/README.md @@ -0,0 +1,11 @@ +# Services + +## Présentation + +Ce dossier contient la documentation des différents services à utilisation +interne. La documentation des services à disposition des utilisateurices est +disponible dans [ce dossier](../../services). + +## Organisation + +TODO diff --git a/infrastructure/services/ldap-adh.md b/infrastructure/services/ldap-adh.md new file mode 100644 index 0000000..b7ae974 --- /dev/null +++ b/infrastructure/services/ldap-adh.md @@ -0,0 +1,114 @@ +# LDAP Adhérents + +Le Crans dispose d'une base de données stockant les machines des adhérents +disposant d'une connexion active et accessible vie le protocole LDAP. + +## Connexion + +Le serveur LDAP est hébergé sur la machine `flirt` et est accessible sur le +port 389. Pour s'y connecter, on peut faire une redirection de ports comme par +exemple : + +```bash +ssh -L 1636:172.16.10.114:636 tealc.adm.crans.org -J zamok.adm.crans.org +``` + +Le plus simple est d'utiliser `shelldap`, permettant de naviguer simplement à +travers la base (voir [la documentation sur le LDAP admin](ldap.md)). + +## Schéma + +Voici la hiérarchie actuelle du LDAP (mars 2023) : + +```txt +dc=adh,dc=crans,dc=org +| ++-cn=admin +| ++-cn=membership +| ++-cn=reader +| ++-ou=users +| +-cn=user (inetOrgPerson) +| ++-ou=clubs +| +-o=club (organization) +| ++-ou=hosts +| +-cn=machine (device, ipHost, ieee802Device) +| ++-ou=networks + +-ipNetworkNumber= (ipNetwork, ipHost) +``` + +## Utilisateurs + +Les adhérents sont ajoutés dans `ou=users` et ont les attributs suivants : + +* `cn`: le pseudo de l'adhérent + +* `givenName`: le prénom de l'adhérent + +* `sn`: le nom de famille de l'adhérent + +* `mail`: l'adresse email de l'adhérent + +* `postalAddress`: l'adresse postale de l'adhérent (au format 1 Rue Machin, + 75000 Ville) + +* `telephoneNumber`: le numéro de téléphone de l'adhérent + +L'attribut `description` est utilisé afin de stocker des informations +supplémentaires: + +* `birthDate`: la date de naissance de l'adhérent au format `YYYY-MM-DD` + +* `birthLocation`: la ville de naissance de l'adhérent + +* `membershipStart`: la date de la première adhésion de l'adhérent au + format `YYYY-MM-DD` + +* `membershipEnd`: la date de fin de l'adhésion de l'adhérent au format + `YYYY-MM-DD` + +* `re2oId`: l'identifiant d'utilisateur de l'adhérent dans l'intranet + +## Clubs + +Les clubs sont ajoutés dans `ou=clubs` et ont les attributs suivants : + +* `o`: le nom du club + +* `description`: le pseudo de l'adhérent responsable du club + +## Machines + +Les machines sont ajoutées dans `ou=hosts` et ont les attributs suivants : + +* `cn`: le nom de la machine + +* `ipHostNumber`: les addresses IP de la machine + +* `macAddress`: l'adresse MAC de la machine + +* `description`: l'ouverture de ports de la machine + +* `owner`: le dn du propriétaire de la machine (utilisateur ou club) + +## Réseaux + +Les sous-réseaux adhérents sont ajoutés dans `ou=networks` et ont les +attributs suivants : + +* `dn`: le nom du sous-réseau + +* `cn`: le pseudo de l'adhérent propriétaire du sous-réseau + +* `description` (optionnel) : deux NSRecord et un DSRecord du sous-réseau + +* `ipHostNumber`: IPv6 interface avec le sous-réseau + +* `ipNetMaskNumber`: masque de sous-réseau + +* `ipNetworkNumber`: première IPv6 du sous-réseau diff --git a/infrastructure/ldap.md b/infrastructure/services/ldap.md similarity index 59% rename from infrastructure/ldap.md rename to infrastructure/services/ldap.md index f092534..76294d9 100644 --- a/infrastructure/ldap.md +++ b/infrastructure/services/ldap.md @@ -1,18 +1,24 @@ # LDAP -Le Crans dispose d'une base de donnée avec laquelle on peut communiquer via le protocole LDAP (que nous appellerons par la suite base LDAP ou simplement LDAP) stockant l'ensemble de ses administrateurs, groupes, serveurs, réseaux et services. +Le Crans dispose d'une base de donnée avec laquelle on peut communiquer via le +protocole LDAP (que nous appellerons par la suite base LDAP ou simplement LDAP) +stockant l'ensemble de ses administrateurs, groupes, serveurs, réseaux et +services. -La serveur LDAP se trouve sur tealc et est répliqué sur les virtualiseurs ainsi que sur sputnik et gulp. +La serveur LDAP se trouve sur tealc et est répliqué sur les virtualiseurs +ainsi que sur sputnik et gulp. ## Connexion -Le LDAP écoute uniquement sur son interface `adm` en LDAPS et en local sur `flirt`. Pour s'y connecter, le plus simple est de se connecter en ssh sur `flirt`, puis d'utiliser `shelldap` (voir ci-dessous). +Le LDAP écoute uniquement sur son interface `adm` en LDAPS et en local sur +`flirt`. Pour s'y connecter, le plus simple est de se connecter en ssh sur +`flirt`, puis d'utiliser `shelldap` (voir ci-dessous). ## Schéma Voici la hiérarchie actuelle du LDAP (mars 2023) : -``` +```txt dc=crans,dc=org +-ou=dns | +-dc=eu (dNSDomain, domain) @@ -39,17 +45,27 @@ dc=crans,dc=org ### DNS -Les enregistrements DNS sont ajoutés dans `ou=dns`, il y a actuellement trois groupes : `eu`, `fr` et `org` contenant chacun le groupe `crans`, correspondant respectivement à `crans.eu`, `crans.fr` et `crans.org`. L'enregistrement DNS de `subdomain.crans.org` sera modifiable dans un attribut `description` de l'entrée `dc=crans,dc=org,ou=dns,dc=crans,dc=org` ou dans une entrée `dc=subdomain,dc=crans,dc=org,ou=dns,dc=crans,dc=org` selon le besoin. +Les enregistrements DNS sont ajoutés dans `ou=dns`, il y a actuellement trois +groupes : `eu`, `fr` et `org` contenant chacun le groupe `crans`, correspondant +respectivement à `crans.eu`, `crans.fr` et `crans.org`. L'enregistrement DNS +de `subdomain.crans.org` sera modifiable dans un attribut `description` de +l'entrée `dc=crans,dc=org,ou=dns,dc=crans,dc=org` ou dans une entrée +`dc=subdomain,dc=crans,dc=org,ou=dns,dc=crans,dc=org` selon le besoin. ### Groupes Les groupes sont ajoutés dans `ou=group`, il y a actuellement deux groupes : - * `_user`: qui contient tout le monde - * `_nounou`: qui contient les nounous et permet de `sudo` sur les serveurs + +* `_user`: qui contient tout le monde ; + +* `_nounou`: qui contient les nounous et permet de `sudo` sur les serveurs. ### Machines -Les machines sont ajoutées dans `ou=hosts` et sont de classe `device`. Les interfaces sont regroupées sous les machines et sont de classes `device`, `ipHost` (ce qui permet de leur ajouter une IP) et `ieee802Device` (qui permet de leur ajouter un attribut `macAddress`) +Les machines sont ajoutées dans `ou=hosts` et sont de classe `device`. Les +interfaces sont regroupées sous les machines et sont de classes `device`, +`ipHost` (ce qui permet de leur ajouter une IP) et `ieee802Device` (qui permet +de leur ajouter un attribut `macAddress`). ### Réseaux @@ -57,14 +73,17 @@ Les réseaux sont ajoutés dans `ou=networks` et sont de classe `ipNetwork`. ### Utilisateurs -Les utilisateurs sont ajoutés dans `ou=passwd` et sont de classes `inetOrgPerson` et `posixAccount`. +Les utilisateurs sont ajoutés dans `ou=passwd` et sont de classes +`inetOrgPerson` et `posixAccount`. ### Services -Les services (noms des protocoles TCP/UDP utilisés au Crans) sont ajoutés dans `ou=services` et sont de classe `ipService`. +Les services (noms des protocoles TCP/UDP utilisés au Crans) sont ajoutés +dans `ou=services` et sont de classe `ipService`. Voici un exemple de service : -``` + +```txt dn: cn=ssh,ou=services,dc=crans,dc=org objectClass: ipService cn: ssh @@ -74,41 +93,58 @@ ipServiceProtocol: tcp ## Conventions -La base LDAP suit un certain nombre de conventions qu'il faut respecter quand on ajoute une entrée. +La base LDAP suit un certain nombre de conventions qu'il faut respecter quand +on ajoute une entrée. ### Machines La description des machines indique le rôle de la machine. -La description des interfaces sert à spécifier l'ouverture de ports sur celles-ci, par exemple : -``` +La description des interfaces sert à spécifier l'ouverture de ports sur +celles-ci, par exemple : + +```txt description: in:service1,in:service2,out:service3 ``` -Pour autoriser les `service1` et `service2` en entrée et le `service3` en sortie. Il ne faut pas mettre d'espace et bien préciser `in:` ou `out:` avant le nom du service qui doit exister dans `ou=services`. + +Pour autoriser les `service1` et `service2` en entrée et le `service3` en +sortie. Il ne faut pas mettre d'espace et bien préciser `in:` ou `out:` avant +le nom du service qui doit exister dans `ou=services`. ### Réseaux -La description du réseau est le numéro du VLAN sur lequel ce réseau est présent. +La description du réseau est le numéro du VLAN sur lequel ce réseau est +présent. ### Utilisateurs -Le nom d'utilisateur (`uid`) doit nécessairement commencer par un `_` (underscore), cette contrainte est forcée dans la configuration du serveur. +Le nom d'utilisateur (`uid`) doit nécessairement commencer par un `_` +(underscore), cette contrainte est forcée dans la configuration du serveur. ### Services -Le champ description du service sert à spécifier une range de ports : on met alors le port de fin dans la description. +Le champ description du service sert à spécifier une range de ports : on met +alors le port de fin dans la description. ## Configuration -Par défaut, la configuration de l'annuaire LDAP est dans la base LDAP elle-même. Mais on trouve ça peu pratique, et il est possible de la déplacer dans un fichier texte : `/etc/ldap/slapd.conf`. Pour cela, il suffit de supprimer `/etc/ldap/slapd.d` et de restart `sladp`. +Par défaut, la configuration de l'annuaire LDAP est dans la base LDAP +elle-même. Mais on trouve ça peu pratique, et il est possible de la déplacer +dans un fichier texte : `/etc/ldap/slapd.conf`. Pour cela, il suffit de +supprimer `/etc/ldap/slapd.d` et de restart `sladp`. -Pour faire écouter uniquement en LDAPS sur adm, on a ajouté dans `/etc/default/slapd` : -``` +Pour faire écouter uniquement en LDAPS sur adm, on a ajouté dans +`/etc/default/slapd` : + +```txt SLAPD_SERVICES="ldaps://172.16.10.1/ ldapi:///" ``` -Pour que les nounous puissent modifier les mots de passe des utilisateurs et que chacun puisse modifier son mot de passe, on ajoute la configuration suivante : -``` +Pour que les nounous puissent modifier les mots de passe des utilisateurs et +que chacun puisse modifier son mot de passe, on ajoute la configuration +suivante : + +```txt access to attrs=userPassword,shadowLastChange by anonymous auth by self write @@ -116,31 +152,37 @@ access to attrs=userPassword,shadowLastChange by * none ``` -Pour que tout le monde puisse modifier son shell, mail et numéro de téléphone et que les nounous puissent modifier ceux des autres -``` +Pour que tout le monde puisse modifier son shell, mail et numéro de +téléphone et que les nounous puissent modifier ceux des autres : + +```txt access to attrs=loginShell,mail,telephoneNumber by self write by set="[cn=nounou,ou=group,dc=crans,dc=org]/memberUid & user/uid" write by * read ``` -Pour que les nounous puissent modifier tout le reste -``` +Pour que les nounous puissent modifier tout le reste : + +```txt access to * by set="[cn=nounou,ou=group,dc=crans,dc=org]/memberUid & user/uid" write by * read ``` -Le LDAPS a été configuré avec un certificat autosigné valable 1000 ans: -``` +Le LDAPS a été configuré avec un certificat autosigné valable 1000 ans : + +```txt TLSCertificateFile /etc/ldap/ldap.pem TLSCertificateKeyFile /etc/ldap/ldap.key ``` ### Réplication -Le LDAP est répliqué notamment sur les virtualiseurs et sur `sputnik` grâce à la configuration suivante : -``` +Le LDAP est répliqué notamment sur les virtualiseurs et sur `sputnik` grâce +à la configuration suivante : + +```txt syncrepl rid=1 provider=ldaps://172.16.10.1:636 @@ -156,9 +198,14 @@ syncrepl retry="30 20 300 +" tls_reqcert=allow ``` -(les valeurs `rid`, et `credentials` sont à remplacer : `rid` doit être unique pour chaque serveur répliqué et `credentials` doit correspondre au mot de passe du `binddn`) -Si jamais le LDAP ne se synchronise pas il faut lancer les commandes suivantes (en remplaçant la valeur de `rid` par celle du serveur répliqué) : +(les valeurs `rid`, et `credentials` sont à remplacer : `rid` doit être +unique pour chaque serveur répliqué et `credentials` doit correspondre au mot +de passe du `binddn`). + +Si jamais le LDAP ne se synchronise pas il faut lancer les commandes suivantes +(en remplaçant la valeur de `rid` par celle du serveur répliqué) : + ```bash systemctl stop slapd slapd -c rid=1,csn=0 @@ -167,16 +214,21 @@ systemctl start slapd ### Overlays -Les overlays sont des modules pour slapd (le serveur LDAP) on utilise plusieurs overlays dans la base de données des membres actifs. Tout est spécifié dans `/etc/ldap/slapd.conf`. +Les overlays sont des modules pour slapd (le serveur LDAP) on utilise plusieurs +overlays dans la base de données des membres actifs. Tout est spécifié dans +`/etc/ldap/slapd.conf`. #### auditlog -Auditlog permet de logguer les modifications faites à la base LDAP dans un fichier LDIF. +Auditlog permet de logguer les modifications faites à la base LDAP dans un +fichier LDIF. #### constraint -Constraint permet de restreindre certains atttributs à certaines valeurs, par exemple on force l'`uid` d'un membre actif à commencer par `_`. -``` +Constraint permet de restreindre certains atttributs à certaines valeurs, par +exemple on force l'`uid` d'un membre actif à commencer par `_`. + +```txt constraint_attribute uid regex ^_ restrict=ldap:///ou=passwd,dc=crans,dc=org??one?(objectClass=posixAccount) ``` @@ -185,16 +237,19 @@ constraint_attribute uid regex ^_ ### Curl -C'est l'outil sans doute le plus basique pour faire des requêtes, et il supporte LDAP(S). Avec la redirection de ports définie plus haut: -``` -curl -k "ldaps://localhost:1636/ou=hosts,dc=crans,dc=org?cn?one?description=pve" -``` -me renvoie tous les virtus, ie pve1, pve2 et pve3. +C'est l'outil sans doute le plus basique pour faire des requêtes, et il +supporte LDAP(S). Avec la redirection de ports définie plus haut : -et +```bash +curl -k "ldaps://localhost:1636/ou=hosts,dc=crans,dc=org?cn?one?description=pve" ``` + +me renvoie tous les virtus, ie pve1, pve2 et pve3. Et + +```bash curl -k "ldaps://localhost:1636/ou=hosts,dc=crans,dc=org?cn?one?description=radius" ``` + me renvoie tous les serveurs radius. ### Apache Directory Studio @@ -203,26 +258,40 @@ Plus d'info [ici](https://directory.apache.org/studio/). C'est un outil graphique pour naviguer dans un annuaire LDAP. Bien pratique ! -Pour le configurer il faut créer une nouvelle connexion (dans le menu en bas à gauche). Par exemple, pour utiliser le LDAP membres actifs du crans on peut utiliser : +Pour le configurer il faut créer une nouvelle connexion (dans le menu en bas +à gauche). Par exemple, pour utiliser le LDAP membres actifs du crans on peut +utiliser : Dans le menu Network Parameter - * Connection name : LDAP nounous - * Hostname : localhost - * Port : 1636 (ou n'importe quel autre port). - * Encryption method : Use SSL encryption (ldap://) + +* Connection name : LDAP nounous + +* Hostname : localhost + +* Port : 1636 (ou n'importe quel autre port). + +* Encryption method : Use SSL encryption (ldap://) et dans le menu Authentication - * Authentication Method : Simple Authentication - * Bind DN or user : votre DN, par exemple pour moi c'est `uid=_pollion,ou=passwd,dc=crans,dc=org` + +* Authentication Method : Simple Authentication + +* Bind DN or user : votre DN, par exemple pour moi c'est + `uid=_pollion,ou=passwd,dc=crans,dc=org` Et renseignez votre mot de passe sur le LDAP Membres actifs. -Avec cette configuration, il suffit de faire une redirection du port 636 distant vers localhost 1636 et à vous la navigation sur le LDAP ! +Avec cette configuration, il suffit de faire une redirection du port 636 +distant vers localhost 1636 et à vous la navigation sur le LDAP ! ### Shelldap -Pour naviguer dans la base, on peut aussi utiliser un utilitaire en ligne de commande : shelldap qui permet de se déplacer à coup de `ls`, `cd` et `cat`. shelldap est installé sur `tealc`, mais non configuré. En ajoutant la configuration dans le fichier `.shelldap.rc` : -``` +Pour naviguer dans la base, on peut aussi utiliser un utilitaire en ligne de +commande : shelldap qui permet de se déplacer à coup de `ls`, `cd` et `cat`. +shelldap est installé sur `tealc`, mais non configuré. En ajoutant la +configuration dans le fichier `.shelldap.rc` : + +```txt server: ldaps://172.16.10.1:636 binddn: uid=<_pseudo>,ou=passwd,dc=crans,dc=org basedn: dc=crans,dc=org @@ -232,9 +301,11 @@ tls_cacert: /etc/ldap/ldap.pem ``` Et on peut ensuite se connecter au LDAP : -``` + +```txt _shirenn@tealc $ shelldap -Bind password: coucoupollion // Ce mot de passe est le mot de passe du compte <_pseudo>, et non l'un de ceux dans le pass crans. +Bind password: coucoupollion // Ce mot de passe est le mot de passe du compte +<_pseudo>, et non l'un de ceux dans le pass crans. ~ > ls cn=admin cn=replicator diff --git a/infrastructure/sfp.md b/infrastructure/sfp.md deleted file mode 100644 index 72c9867..0000000 --- a/infrastructure/sfp.md +++ /dev/null @@ -1,22 +0,0 @@ -# Optiques SFP(+) et fibres optiques - -Le Crans dispose d'un backbone 10G pour relier ses serveurs, les modules optiques utilisés sont des [10GBASE-SR compatibles Arista](https://www.fs.com/fr/products/36982.html) (afin d'être compatibles avec nos switches Arista). -Ces modules sont reliés par des [jarretières optiques LC LC OM4](https://www.fs.com/fr/products/40220.html). - -Pour son interconnexion avec ViaRézo et Aurore le Crans utilise des modules optiques [10GBASE-LR](https://www.fs.com/fr/products/36983.html) reliés aux platines de fibres par des [jarretières optiques LC SC OS2](https://www.fs.com/fr/products/96102.html). - -## Qu'est-ce qu'est une optique SFP ? - -C'est un module actif composé d'un micro-contrôlleur (par exemple un STM32 Cortex-M3) et d'un ou plusieurs lasers. -Il permet de relier une fibre optique à un switch. - -### Codage des optiques - -Une optique est codé avec un identifiant constructeur, changeable avec une codeuse. Un switch d'un certain constructeur n'acceptera que certains codes. Par exemple sur des Quanta, coder correctement les optiques permet de collecter des métriques tel que leur température. Sur certains switchs il est possible d'activer le support des optiques avec le mauvais code. - -## Choses à ne pas faire - -Il peut être tentant d'acheter une optique 10km pour une liaison de 100m en partant sur l'idée que « qui peut le plus, peut le moins ». Dans le cas de l'optique c'est faux. Utiliser une optique trop puissante sur une distance beaucoup plus petite que son design va brûler le récepteur. - -Une optique chauffe et un laser qui chauffe dérive légèrement. Malgré qu'il y ait des plaques à effet Peltier dans certaines optiques pour compenser, il reste une bonne idée de vérifier que les optiques sont correctement refroidites par le switch. - diff --git a/outils/README.md b/outils/README.md new file mode 100644 index 0000000..03b8dd2 --- /dev/null +++ b/outils/README.md @@ -0,0 +1,40 @@ +# Outils + +## Présentation + +Ce dossier contient une présentation rapide de plusieurs outils logiciels, +systèmes d'exploitation et protocoles utilisés par le Crans pour +l'installation et la maintenance des serveurs et des services qui y sont +associés. + +Le but n'est pas de réexpliquer l'entièreté des fonctionnalités, mais +simplement d'avoir une explication de ce que l'on parle pour avoir des bases +de compréhension. + +## Organisation + +Chaque fichier de ce dossier contient une présentation, au moins succinte, de +l'outil ou du protocole. On peut y mettre autant de détails que l'on juge +nécessaire bien évidemment (il vaut mieux trop de documentation que pas +assez), mais ce n'est pas non plus absolument vital. On s'assurera en plus que +chaque fichier contient un lien vers de la documentation officielle (si elle +existe) et/ou vers une explication relativement simple du fonctionnement. + +Si l'outil ou le protocole est assez complexe et qu'il n'existe pas de bonne +documentation **simple** en ligne, il est alors vivement recommandé que les +nounous/apprenti⋅es le comprenant bien écrivent une explication de son +fonctionnement. + +Les fichiers sont nommés par l'acronyme de l'outil ou du protocole (car on les +connait en général mieux que les noms complets). + +On retrouve les dossiers suivants : + +* [`logiciels`](logiciels) : contient la documentation des logiciels utilisés + par le Crans. + +* [`protocoles`](protocoles) : contient la documentation des protocoles + utilisés pas le Crans. + +* [`os`](os) : contient la documentation des systèmes d'exploitation + utilisés par le Crans. diff --git a/outils/logiciels/README.md b/outils/logiciels/README.md new file mode 100644 index 0000000..b881a59 --- /dev/null +++ b/outils/logiciels/README.md @@ -0,0 +1,15 @@ +# Logiciels + +## Présentation + +Ce dossier contient une présentation de plusieurs outils logiciels utilisés +par le Crans. + +Le but n'est pas de réexpliquer l'entièreté des fonctionnalités, mais +simplement d'avoir une explication de ce que l'on parle pour avoir des bases +de compréhension. + +## Organisation + +L'organisation est la même que décrite dans [le fichier `README.md` du +dossier parent](../README.md). diff --git a/tools/apt.md b/outils/logiciels/apt.md similarity index 62% rename from tools/apt.md rename to outils/logiciels/apt.md index 92733e2..dbb3d69 100644 --- a/tools/apt.md +++ b/outils/logiciels/apt.md @@ -1,9 +1,11 @@ # APT -APT (pour Advanced Package Tool) est un des gestionnaires de paquets de [Debian](https://www.debian.org/). Il dispose d'une interface en CLI, voici quelques exemples de commandes : +APT (pour Advanced Package Tool) est un des gestionnaires de paquets de +[Debian](https://www.debian.org/). Il dispose d'une interface en CLI, voici +quelques exemples de commandes : | commande | description | -| - | - | +|----------|-------------| | `apt install package` | Installe `package` | | `apt search package` | Recherche `package` | | `apt list` | Liste les paquets | @@ -17,15 +19,22 @@ APT (pour Advanced Package Tool) est un des gestionnaires de paquets de [Debian] | `apt update` | Met à jour les listes de paquets | | `apt upgrade` | Met à jour les paquets | -Un paquet Debian va placer des fichiers dans `/bin/`, `/usr/` par exemple. Il faut donc avoir les droits administrateurs pour installer, mettre à jour ou supprimer un paquet. Il n'est pas possible d'installer un paquet APT pour seulement un utilisateur. +Un paquet Debian va placer des fichiers dans `/bin/`, `/usr/` par exemple. Il +faut donc avoir les droits administrateurs pour installer, mettre à jour ou +supprimer un paquet. Il n'est pas possible d'installer un paquet APT pour +seulement un utilisateur. ## Les sources de paquets -APT est en réalité une interface au dessus de DPKG (Debian PacKaGe) qui va simplifier le téléchargement et l'installation de paquets en les synchronisant de sources de paquets. +APT est en réalité une interface au dessus de DPKG (Debian PacKaGe) qui va +simplifier le téléchargement et l'installation de paquets en les +synchronisant de sources de paquets. -Les sources de paquets sont définies dans `/etc/apt/source.list` et dans le dossier `/etc/apt/source.list.d/`. Un système Debian classique au Crans devrait avoir les sources suivantes : +Les sources de paquets sont définies dans `/etc/apt/source.list` et dans le +dossier `/etc/apt/source.list.d/`. Un système Debian classique au Crans +devrait avoir les sources suivantes : -``` +```txt # Paquets principaux de Debian Buster deb https://ftps.crans.org/debian buster main @@ -36,10 +45,17 @@ deb https://ftps.crans.org/debian buster-updates main deb https://ftps.crans.org/debian-security buster/updates main ``` -Si on souhaite également synchroniser la liste des sources de paquets pour potentiellement les reconstruire, on peut dupliquer chaque ligne en substituant `deb` par `deb-src`. +Si on souhaite également synchroniser la liste des sources de paquets pour +potentiellement les reconstruire, on peut dupliquer chaque ligne en substituant +`deb` par `deb-src`. ## Vérifier l'état de santé des paquets systèmes Debian -Debian fournit un outil nommé `debsums` (Debian Checksum) pour vérifier que les fichiers installés par les paquets Debian n'ont pas été altérés. Un fichier d'un paquet peut être altéré soit par un virus ou un administrateur chaotique qui écrase ses exécutables, soit quand il s'agit de changer sa configuration. +Debian fournit un outil nommé `debsums` (Debian Checksum) pour vérifier que +les fichiers installés par les paquets Debian n'ont pas été altérés. Un +fichier d'un paquet peut être altéré soit par un virus ou un administrateur +chaotique qui écrase ses exécutables, soit quand il s'agit de changer sa +configuration. -Pour lister rapidement la liste des fichiers de configuration changés : `debsums -ce` +Pour lister rapidement la liste des fichiers de configuration changés : +`debsums -ce`. diff --git a/outils/logiciels/gpg.md b/outils/logiciels/gpg.md new file mode 100644 index 0000000..1f27cc8 --- /dev/null +++ b/outils/logiciels/gpg.md @@ -0,0 +1,44 @@ +# GPG + +GPG (GNU Privacy Guard) est une implémentation libre et open source du +protocole OpenPGP (Pretty Good Privacy), un protocole cryptographique +permettant de signer, chiffrer et déchiffrer des documents (notamment des +emails). + +## Clef + +Une clef GPG est une clé numérique qui permet d'être identifié de façon +unique dans le monde numérique. + +Elle est composée de deux éléments : + +* une clé privée protégée par une phrase clé qui permet d'éviter à une + tierce personne d'utiliser cette clef si elle parvient à la voler + +* une clé publique qui une fois distribuée et signée par son entourage, + permet à celui-ci de vérifier que les messages que l'on signe le sont bien + avec la clé privée associée à cette clé publique. + +Elle peut être générée à l'aide d'une des commandes suivantes (selon le +nombre d'option que vous souhaitez avoir) : + +* `gpg --generate-key` + +* `gpg --full-generate-key` + +* `gpg --full-generate-key --expert` + +## Web of trust + +Le web of trust (ou toile de confiance en français) permet d'établir +l'authenticité de l'appartenance d'une clef publique ; il est décentralisé : +il n'a donc pas besoin d'autorité de certification. + +Voici les règles par défaut du web of trust d'OpenPGP, on estime que la clef +publique appartient au bon propriétaire si : + +* On a soi-même fait confiance à cette clef + +* Une personne en qui on a totalement confiance a signé cette clef + +* Trois personnes en qui on a partiellement confiance ont signé cette clef diff --git a/outils/logiciels/ssh.md b/outils/logiciels/ssh.md new file mode 100644 index 0000000..7c2b824 --- /dev/null +++ b/outils/logiciels/ssh.md @@ -0,0 +1,100 @@ +# SSH + +SSH (Secure Shell) est un protocole permettant d'exécuter des commandes sur un +serveur distant. Il utilise le port 22 en TCP. + +Sa version 2 est spécifiée par les RFC +[4250](https://datatracker.ietf.org/doc/html/4250), +[4251](https://datatracker.ietf.org/doc/html/4251), +[4252](https://datatracker.ietf.org/doc/html/4252), +[4253](https://datatracker.ietf.org/doc/html/4253) et +[4254](https://datatracker.ietf.org/doc/html/4254). + +## OpenSSH + +Le client de prédilection pour utiliser SSH est le client de la suite OpenSSH +(qui fourni également un serveur et d'autres utilitaires permettant de gérer +les clefs cryptographiques), disponible dans le paquet Debian `openssh-client`. + +## Clefs SSH + +Vous pouvez générer des clefs cryptographiques permettant de vous +authentifier directement sur le serveur distant (plutôt que par mot de passe) +avec l'utilitaire `ssh-keygen` ainsi : + +```bash +ssh-keygen -t ${TYPE} -b ${BITS} +``` + +Où `TYPE` peut être : + +* `rsa` + +* `ecdsa` (dans ce cas `BITS` doit valoir 256, 384 ou 521) + +* `ed25519` (dans ce cas `BITS` doit valoir 256) + +`ssh-keygen` vous demande ensuite le chemin du fichier de clef ainsi que sa +passphrase et génère une clef privée ainsi qu'une clef publique se terminant +par `.pub`. + +Un autre utilitaire, `ssh-copy-id` permet de copier la clef sur le serveur +distant par exemple : + +```bash +ssh-copy-id -i ~/.ssh/id_ed25519.pub login@zamok.crans.org +``` + +Attention : il faut absolument garder la clef privée sur votre serveur et ne +pas l'envoyer sur le serveur distant. + +## Exemples + +À la première connexion `ssh` demande s'il faut faire confiance à la clef du +serveur : + +```bash +benjamin@om ~ $ ssh gitlab.crans.org +The authenticity of host 'gitlab.crans.org (185.230.79.14)' can't be +established. +ECDSA key fingerprint is SHA256:StU+25vCTTs+opjyjMZTLvl+gvR+ViQWUkE1jRENnkQ. +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 +(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 + /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 par un mail d'un administrateur de confiance + signé GPG. + +* Utiliser des clefs stockées dans le [DNS](/tools/dns.md) et signées + DNSSEC, ceci peut se faire en ajoutant l'option `-oVerifyHostKeyDNS=yes` à + `ssh`. + +Une fois que vous vous êtes assuré de l'authenticité de la clef vous pouvez +entrer `yes` dans le prompt ci-dessus. + +`ssh` vous demande ensuite votre mot de passe ou la passphrase de votre clef, +entrez le et appuyez sur Entrée pour vous connecter, félicitations vous +devriez avoir votre shell sur le serveur distant. + +## Exemple de conf ssh + +Après avoir `ssh-copy-id` sa clef public comme précisé plus haut on peut +définir une conf qui permet d'aller sur nimporte quel serveur depuis votre +machine via un `ProxyJump`. + +```txt +Host *.adm.crans.org + User _usernounou + ProxyJump _usernounou@hodaur.crans.org +``` diff --git a/howto/systemd.org b/outils/logiciels/systemd.org similarity index 100% rename from howto/systemd.org rename to outils/logiciels/systemd.org diff --git a/outils/logiciels/zfs.md b/outils/logiciels/zfs.md new file mode 100644 index 0000000..adc6d59 --- /dev/null +++ b/outils/logiciels/zfs.md @@ -0,0 +1,201 @@ +# ZFS + +## ZFS c'est quoi ? + +ZFS est un système de fichier avec plein de features natives, notamment de la +gestion de volume, du RAID (RAID-Z), des snapshots, etc. + +> ZFS a été ouvert sous licence +> [CDDL](https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License) +> incompatible avec la GPL. Par conséquent, ZFS n'est pas supporté nativement +> par le noyau Linux. + +## Petit glossaire + +* RAID-Z#N: Le raid de ZFS. Le chiffre #N correspond au nombre de disques que + l'on peut perdre (e.g. RAID-Z2 correspond à du RAID 6 classique). + +* Pool: Une *pool* de stockage est le bloc de base de ZFS. C'est un ensemble + logique de données. Une pool ZFS est composée d'un ou plusieurs *vdev*. + +* Vdev: Un *vdev* (pour ''virtual device'') est un sous élément d'une pool. + Un vdev peut contenir un ou plusieurs disques physiques. Dans le cas où + plusieurs disques sont utilisés, les données sont étendues (*stripped*) sur + tous les disques afin d'améliorer sa durée de vie. + +* Dataset: *Dataset* est le terme générique pour désigner un volume de + fichiers ZFS. Chaque dataset a un nom unique de la forme *Pool/Dataset*. La + racine de la pool est techniquement un dataset aussi. Les dataset sont + organisés comme des dossiers classique, avec une arborescence, et les enfants + héritent des propriétés des parents. + +## Installation + +Il faut ajouter les dépots `contrib` de debian dans lesquels se trouvent les +paquets installés ci-dessous. + +Pour installer le module noyau ZFS sous Debian et les outils d'administration : + +```bash +apt install linux-headers-amd64 +apt install zfs-dkms +``` + +Il faut ensuite reboot pour loader le module zfs, puis : + +```bash +apt install zfsutils-linux +``` + +Cela installe aussi `zfs-zed` un daemon permettant de monitorer les pool ZFS. +Les headers du noyau doivent être installés à chaque mise à jour du noyau. + +## Créer une pool ZFS + +La première étape de création d'un filesystem ZFS est la création d'une +pool. Une pool contient des vdev qui eux même contiennent des disques, la +commande suivante permet de créer une pool de nom «pool» et montée dans +`/pool` avec un vdev en RAIDZ-3 : + +```bash +zpool create -f -m /pool pool raidz3 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03494499 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03563166 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03570970 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03575828 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03614378 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03626582 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03694920 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03704580 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03707506 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03731830 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734763 \ + ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734769 +``` + +Les identifiants de disques peuvent être récupérés dans `/dev/disks/by-id/`. + +L'état des pool peut-être consulté avec la commande : + +```bash +zpool status +``` + +## Créer un dataset + +Une fois la pool créée il est préférable de créer des datasets qui +permettent une gestion plus fine de la pool. Pour cela on utilise la commande +suivante qui créé un dataset du nom de «home» dans la pool «pool» : + +```bash +zfs create pool/home +``` + +## Partager un dataset en NFS + +ZFS permet de partager un dataset en NFS pour cela il faut installer le paquet +`nfs-kernel-server` : + +```bash +apt install nfs-kernel-server +``` + +Le dataset «home» de la pool «pool» peut ensuite être partager ainsi : + +```bash +zfs set sharenfs="no_root_squash,rw=@172.16.10.0/24" pool/home +``` + +Cette commande partage le dataset au sous-réseau `172.16.10.0/24`, l'option +`no_root_squash` permet au root du client NFS d'avoir tous les droits sur les +fichiers du dataset. + +Il est également préférable d'activer les acl POSIX sur la pool, dans le cas +contraire il peut y avoir des problèmes de permissions à la création de +fichiers : + +```bash +zfs set acltype=posixacl pool +``` + +## Détruire un dataset + +Pour détruire le dataset `pool/path` on utilise la commande : + +```bash +sudo zfs destroy pool/path +``` + +## Désactiver le sync + +Renvoyer une confirmation d'écriture sur le disque après chaque opération +diminue énormément les performances du NFS. On peut dire à ZFS de mentir au +NFS sur le retour des opérations sync(). Pour ça, on utilise la commande : + +```bash +sudo zfs set sync=disabled pool/path +``` + +## Changer un disque + +Récupérer le guid du disque qu'on souhaite changer avec `zdb` (`zpool status` +peut aider à récuperer le nom du disque concerné). Une fois que c'est fait +on peut retirer le disque avec : `zpool offline pool ${guid}` puis on remplace +l'ancien disque par le nouveau : +`zpool replace pool ${guid} ${nouveau disque}`. +Après ça, on peut monitorer la reconstruction avec `zpool status`. + +## Chiffrement + +ZFS permet de nativement chiffrer un dataset. Attention, il faut que ça soit +fait à la **creation** du dataset. Ça ne peut pas se changer après. + +### Créer un dataset chiffré + +Pour créer un dataset chiffré il suffit de rajouter les options de +chiffrement avec `encryption=on`. Il faut aussi spécifier le format de la clé +(`raw, hex, passphrase`). Par défaut, la clé va être promptée, mais il est +possible de la stocker sur le système de fichier, ou bien via une URL. +L'option `encryption` permet aussi de spéficier l'algorithme de chiffrement à +utiliser. + +Par exemple: + +```bash +sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase pool/dataset +``` + +Pour vérifier que tout va bien on peut récupérer la propriété de +chiffrement : + +```bash +sudo zfs get encryption pool/dataset +``` + +Pour changer la clé il suffit d'utiliser la commande suivante : + +```bash +sudo zfs key -c pool/dataset +``` + +qui va demander la nouvelle passphrase. + +Il est aussi possible de changer la source de la clé (pour aller chercher la +clé dans un fichier par exemple). + +### Monter/démonter un dataset chiffré + +Par défaut le dataset sera monté. Pour le démonter il suffit d'utiliser la +commande `unmount`. Attention, la clé de chiffrement sera toujours chargée, +et le dataset pourra être remonté sans redemander la clé. Pour ça, il faut +décharger la clé : + +```bash +sudo zfs unmount pool/dataset && sudo zfs unload-key pool/dataset +``` + +Pour remonter le dataset il faut alors recharger la clé : + +```bash +sudo zfs load-key pool/dataset && sudo zfs mount pool/dataset +``` diff --git a/outils/os/README.md b/outils/os/README.md new file mode 100644 index 0000000..8cb2f81 --- /dev/null +++ b/outils/os/README.md @@ -0,0 +1,15 @@ +# Systèmes d'exploitation + +## Présentation + +Ce dossier contient une présentation des systèmes d'exploitation utilisés +par le Crans. + +Le but n'est pas de réexpliquer l'entièreté des fonctionnalités, mais +simplement d'avoir une explication de ce que l'on parle pour avoir des bases +de compréhension. + +## Organisation + +L'organisation est la même que décrite dans [le fichier `README.md` du +dossier parent](../README.md). diff --git a/tools/debian.md b/outils/os/debian.md similarity index 100% rename from tools/debian.md rename to outils/os/debian.md diff --git a/outils/os/nixos.md b/outils/os/nixos.md new file mode 100644 index 0000000..81dd035 --- /dev/null +++ b/outils/os/nixos.md @@ -0,0 +1,6 @@ +# NixOS + +Le Crans utilise [NixOS](https://nixos.org/) sur plusieurs machines virtuelles. + +Une documentation complète est disponible au [dépôt git de la configuration +NixOS du Crans](https://gitlab.crans.org/nounous/nixos). diff --git a/tools/proxmox.md b/outils/os/proxmox.md similarity index 100% rename from tools/proxmox.md rename to outils/os/proxmox.md diff --git a/outils/protocoles/README.md b/outils/protocoles/README.md new file mode 100644 index 0000000..b66015f --- /dev/null +++ b/outils/protocoles/README.md @@ -0,0 +1,15 @@ +# Protocoles + +## Présentation + +Ce dossier contient une présentation de plusieurs protocoles utilisés par le +Crans. + +Le but n'est pas de réexpliquer l'entièreté des fonctionnalités, mais +simplement d'avoir une explication de ce que l'on parle pour avoir des bases +de compréhension. + +## Organisation + +L'organisation est la même que décrite dans [le fichier `README.md` du +dossier parent](../README.md). diff --git a/tools/bgp.md b/outils/protocoles/bgp.md similarity index 50% rename from tools/bgp.md rename to outils/protocoles/bgp.md index e25f74d..562a36c 100644 --- a/tools/bgp.md +++ b/outils/protocoles/bgp.md @@ -1,16 +1,22 @@ # BGP -BGP (Border Gateway Protocol) est un protocole d'échange de routes IP entre AS sur internet. On le qualifie de protocole de routage à vecteurs de chemins. +BGP (Border Gateway Protocol) est un protocole d'échange de routes IP entre AS +sur internet. On le qualifie de protocole de routage à vecteurs de chemins. BGP utilise le port 179 en TCP. -Sa version 4 est spécifiée par la [RFC 4271](https://datatracker.ietf.org/doc/html/rfc4271). +Sa version 4 est spécifiée par la [RFC +4271](https://datatracker.ietf.org/doc/html/rfc4271). -# Autonomous System +## Autonomous System -Un système autonome (AS) est un ensemble de préfixes IP sous le contrôle d'une seule entité ayant une politique de routage cohérente sur l'internet. +Un système autonome (AS) est un ensemble de préfixes IP sous le contrôle +d'une seule entité ayant une politique de routage cohérente sur l'internet. -Chaque AS est identifié par son numéro (ASN) qui est utilisé dans le protocole BGP. À l'origine un ASN était un entier représenté sur 16 bits mais la [RFC 6793](https://datatracker.ietf.org/doc/html/rfc6793) a étendu cette représentation à 32 bits. +Chaque AS est identifié par son numéro (ASN) qui est utilisé dans le +protocole BGP. À l'origine un ASN était un entier représenté sur 16 bits +mais la [RFC 6793](https://datatracker.ietf.org/doc/html/rfc6793) a étendu +cette représentation à 32 bits. Certains ASN sont réservés à des usages particuliers : diff --git a/outils/protocoles/dns.md b/outils/protocoles/dns.md new file mode 100644 index 0000000..dd582fd --- /dev/null +++ b/outils/protocoles/dns.md @@ -0,0 +1,137 @@ +# DNS + +DNS (Domain Name System) est un protocole d'annuaire. Il utilises deux ports : + +* Le port 53 en UDP pour la plupart des échanges. + +* Le port 53 en TCP pour les échanges de grande taille (tels que du transfert + de zone). + +DNS sert principalement à traduire les noms de domaines en adresse IP. + +C'est est un service hierarchisé dont le sommet est appelé la racine, et est +représentée par un point (`.`). Chaque nom de domaine est découpé en +plusieurs sous parties : + +Par exemple `zamok.crans.org` est un sous-domaine de `crans.org` lui-même +sous-domaine de `org` qui est un sous-domaine de `.` (la racine). + +Il existe plusieurs types de serveurs DNS : + +* Les serveurs Autoritaires, qui s'occupent de garder à jour le gros + dictionnaire (ou annuaire) de la zone qu'ils gouvernent (par exemple + `crans.org`, `crans.eu` ou `crans.fr`) + +* Les serveurs Récursifs, qui s'occupent de faire des requêtes successives + pour obtenir la valeur souhaitée, ils gardent très souvent en cache les + informations récoltées, ce qui permet d'accélérer la réponse et d'éviter + de surcharger les serveurs autoritaires. + +DNS permet d'associer des enregistrements (records) à des noms, ces +enregistrements ont une classe et un type dont la liste est disponible [sur le +site de +l'IANA](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml). + +La classe utilisée traditionnellement est la classe `IN` (pour internet), +voici quelques types courants : + +| Type | Description | +|------|-------------| +| `A` | Adresse IPv4 | +| `AAAA` | Adresse IPv6 | +| `CNAME` | Alias vers un autre nom de domaine | +| `NS` | Nom d'un serveur DNS autoritaire | +| `MX` | Nom d'un serveur mail | + +Ainsi on a par exemple les enregistrements suivants dans la zone `crans.org` : + +```txt +zamok.crans.org. IN A 185.230.79.1 +perso.crans.org. IN CNAME hodaur.crans.org. +crans.org. IN NS silice.crans.org. +crans.org. IN MX 10 redisdead.crans.org. +``` + +Le 10 dans la valeur du champ MX est la priorité du serveur mail. + +## host + +Pour résoudre des noms de domaines la commande privilégiée est la commande +`host` : + +```bash +benjamin@tiamat ~ $ host zamok.crans.org +zamok.crans.org has address 185.230.79.1 +zamok.crans.org has IPv6 address 2a0c:700:2:0:ec4:7aff:fe59:a1ad +``` + +```bash +benjamin@tiamat ~ $ host crans.org +crans.org has address 185.230.79.10 +crans.org has IPv6 address 2a0c:700:2::ff:fe01:4502 +crans.org mail is handled by 10 redisdead.crans.org. +crans.org mail is handled by 15 sputnik.crans.org. +crans.org mail is handled by 25 freebox.crans.org. +``` + +## dig + +La commande `dig` permet d'effectuer des requêtes DNS plus complexes que +`host`, la commande `dig -t TYPE @server name` est équivalente à la commande +`host -vt TYPE name server`. `dig` peut prendre des options de requête plus +qui modifient son comportement, en voici quelques exemples : + +* `+short`: affiche uniquement la section de réponses de la requête et de + manière compacte + +* `+dnssec`: affiche également les résultats des requêtes pour les champs + DNSSEC associés à la requête demandée + +* `+rrcomments`: affiche des commentaires sur certains enregistrements + +* `+https`: effectue une query DNS over HTTPS (DoH) + +* `+trace`: fait les requêtes successives récursivement côté client afin + de déterminer le résultat par exemple : + `dig +trace @ns0.fdn.fr zamok.crans.org`: + + ```txt + . 47747 IN NS a.root-servers.net. + . 47747 IN NS b.root-servers.net. + . 47747 IN NS c.root-servers.net. + . 47747 IN NS d.root-servers.net. + . 47747 IN NS e.root-servers.net. + . 47747 IN NS f.root-servers.net. + . 47747 IN NS g.root-servers.net. + . 47747 IN NS h.root-servers.net. + . 47747 IN NS i.root-servers.net. + . 47747 IN NS j.root-servers.net. + . 47747 IN NS k.root-servers.net. + . 47747 IN NS l.root-servers.net. + . 47747 IN NS m.root-servers.net. + . 47747 IN RRSIG NS 8 0 518400 20220629170000 20220616160000 47671 . WGw6h2UFnKlJdCnApXM7dYkGuSpmRwokdwl0PzQMt0yUUG/Dumwpijn5 MEeOCxhoP29ni62JRMCGxgIirXVOHGfiMHDcx/dnv2gMnsr1OhQjPgwj hOu/NjZVkb612QW3b/i0mwDdjcEwRFQs9wzVZIBc4mPTFjocT2C2GlQc noLupUmliv38lfaPd+knrbhIUdwD8VEHDrzpDfdwR/kws+fWDjBcgUjA 77WzsA+FiwkqNvFIhQfMG+5CSXd0PpD3pPhdA6lCKa3l1AM4Cfnbtvj6 tuejEnNvbxsBaPOkiRz642/ysLV+fhXrP4U9BnWncUwe92NtFlZYRCHe a/D+yw== + ;; Received 525 bytes from 2001:910:800::12#53(ns0.fdn.fr) in 23 ms + + org. 172800 IN NS a0.org.afilias-nst.info. + org. 172800 IN NS a2.org.afilias-nst.info. + org. 172800 IN NS b0.org.afilias-nst.org. + org. 172800 IN NS b2.org.afilias-nst.org. + org. 172800 IN NS c0.org.afilias-nst.info. + org. 172800 IN NS d0.org.afilias-nst.org. + org. 86400 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32 + org. 86400 IN RRSIG DS 8 1 86400 20220630050000 20220617040000 47671 . bKm4Ul/DPpqbqvF0gRS1Gzrmk9N0VU2Qa1dBIb/vbx6N+SEVK1wGpD20 BA6mdyFL2SOOuhEldC44N/cj401aLoli/9Bj71hdYl0XLcW/Hiq1xo2U 6Iqvfu4GwBGb36aLfce8DYEdnTtpbicXrFszx8dg2CAnFvCYLve6sA/r DOzs+K8LCsTi3cdOTuee3mEN1XC6SAfIrZDDtLEwZXiyxRAI7GbuM0i8 LCFHRa7YBlf8EOFNafkFsCi4qM4cHdnavVAxDH+gOeYnjVOd3yhezJb9 /hRBo3aIKGY1orjb+erQAOxhly26f8v2H/h0czKOXriNL7d4id8aa1fN qWiFeA== + ;; Received 781 bytes from 199.7.83.42#53(l.root-servers.net) in 27 ms + + crans.org. 3600 IN NS sputnik.crans.org. + crans.org. 3600 IN NS silice.crans.org. + crans.org. 3600 IN DS 40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2 + crans.org. 3600 IN RRSIG DS 8 2 3600 20220630152826 20220609142826 41346 org. EjZHR/kgXopDL/Rqw5wMWQn2AB2stt6eu0TtGHa2Gt1/LhOPraqNbXJq Ufg7VhcCRtY4DaZnp9wnBXzK9vdqUIIRMuNQoA6mEdj8qpjRajsjfPdT D87bU6h1OH5YghQAzi2N90LGgjlDqdB50xWIZHgMeLLH53nePcAcxpxE VA4= + ;; Received 358 bytes from 2001:500:e::1#53(a0.org.afilias-nst.info) in 243 ms + + zamok.crans.org. 3600 IN A 185.230.79.1 + zamok.crans.org. 3600 IN RRSIG A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5 + crans.org. 3600 IN NS silice.crans.org. + crans.org. 3600 IN NS sputnik.crans.org. + crans.org. 3600 IN RRSIG NS 14 2 3600 20220711101913 20220611094455 40871 crans.org. +BvWwsxxekrKHDFCXTL2d/pHP/2i75U6qah3Ee15SSDSQhjbnwCkI2+a Q6zGpnkwnSsB6HfRgoCbXp8r/rRzgAV7pGN06wPyejJRzkgRB+euSjbD tUmc8ODVxVWYH7iQ + ;; Received 1041 bytes from 2a0c:700:2::ff:fe01:4702#53(silice.crans.org) in 23 ms + ``` diff --git a/outils/protocoles/dnssec.md b/outils/protocoles/dnssec.md new file mode 100644 index 0000000..5cab7cf --- /dev/null +++ b/outils/protocoles/dnssec.md @@ -0,0 +1,81 @@ +# DNSSEC + +DNSSEC (Domain Name System Security Extensions) est un ensemble d'extension de +sécurité pour DNS. Il permet d'authentifier les données obtenues par le +protocole DNS. + +Pour cela, chaque entrée du DNS est signée cryptographiquement avec une clef +privée. La clef publique, elle-même publiée dans le DNS permet de vérifier +les signatures. L'authenticité de la clef publique est assurée par la zone +parente (via les enregistrements DS), dans laquelle elle est publiée. + +Ainsi, il suffit de faire confiance à la clef publique de la racine du DNS (et +seulement de la racine) pour pouvoir établir une chaîne de confiance dans +tous le DNS. + +Les enregistrements DNS associés au DNSSEC sont les suivants : + +* `DNSKEY`: une clef publique servant à signer une zone + +* `DS`: un hash de clef publique d'une zone fille (conceptuellement proche + d'un GLUE record NS) + +* `RRSIG`: une signature d'un enregistrement + +* `NSEC`: un pointeur vers la prochaine entrée DNS signée (dans l'ordre + alphabétique), celui sert à prouver l'absence d'un enregistrement + +* `NSEC3`: une variante de `NSEC` où les entrées DNS sont hashées + +* `NSEC3PARAM`: des informations servant à calculer les hash pour les + enregistrements `NSEC3` + +## Exemples + +### DNSKEY + +On lance la commande `dig -t DNSKEY @silice.crans.org crans.org` : + +```txt +;; QUESTION SECTION: +;crans.org. IN DNSKEY + +;; ANSWER SECTION: +crans.org. 3600 IN DNSKEY 257 3 14 Db282t/1HUd5ccAnJ0BSaidrnseZEtG/8Cj9MbzYl/GbgGxA8msR/Dq8 KfIeobLwnZFF5277dhdzAAdfKAb/XclhHBqpDtaV+bvd21n8MLR3yhdI VsFAde/yOBFW28fV +crans.org. 3600 IN DNSKEY 256 3 14 4gBTKamW1QSNWNSWkR0qVswo+GcIV7cmKf6y4zuqlinDcvN0a5+ppqW2 almA4TF7vh7u9jH2/iwZVmHiikgpTiRzZJzga158/AlYTqE4pTK6zhin YlPz9w/PTSdOXMU6 +``` + +La zone `crans.org` possède deux clefs de signature : une KSK (Key Signing +Key) et une ZSK (Zone Signing Key). + +### DS + +On lance la commande `dig -t DS @a0.org.afilias-nst.info crans.org`: + +```txt +;; QUESTION SECTION: +;crans.org. IN DS + +;; ANSWER SECTION: +crans.org. 3600 IN DS 40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2 +``` + +La zone `crans.org` a publié dans la zone `org` le hash d'une clef publique +(la KSK). + +### RRSIG + +On lance la commande `dig -t RRSIG @silice.crans.org zamok.crans.org` : + +```txt +;; QUESTION SECTION: +;zamok.crans.org. IN RRSIG + +;; ANSWER SECTION: +zamok.crans.org. 3600 IN RRSIG A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5 +zamok.crans.org. 3600 IN RRSIG AAAA 14 3 3600 20220711100552 20220611093221 40871 crans.org. 2XkmJYJbeKgXK0plIB/d1nnhQ6mXhubZu4k6jASlp9BumPy6WLRPUxR1 QhFV+gidKTVidsWL6faL28HH8j4pmxVGeIC50c5NOfaBa3nVTfeD+pUp MEhC0VwhBYnODuu9 +zamok.crans.org. 3600 IN RRSIG SSHFP 14 3 3600 20220711100552 20220611093221 40871 crans.org. nd/HiLy0qw3NMo2Lwn8P/J2h1UaXjGWAFYPCK5ISQWBILPE5iO+TdaXy uyOy4l4Dc9hdanzvKQFBuE9hG9gkr3KpmtCEFWtHlg6PAu7MIqXTzpbV 4kR2wjiuCLfmPq2W +``` + +`zamok.crans.org` possède trois enregistrements signés : ils sont de types +`A`, `AAAA` et `SSHFP`. diff --git a/outils/protocoles/http.md b/outils/protocoles/http.md new file mode 100644 index 0000000..dba99f9 --- /dev/null +++ b/outils/protocoles/http.md @@ -0,0 +1,7 @@ +# HTTP + +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. diff --git a/outils/protocoles/ip.md b/outils/protocoles/ip.md new file mode 100644 index 0000000..455639d --- /dev/null +++ b/outils/protocoles/ip.md @@ -0,0 +1,133 @@ +# IP + +## Généralités + +IP (Internet Protocol) est le protocole principal de communication sur +l'internet, actuellement deux versions sont en cours d'utilisation : IPv4 et +IPv6. + +IP permet de transmettre des datagrammes d'un point à un autre. + +### Adressage + +Les adresses IP sont alloués avec la méthode du CIDR (Classless Inter-Domain +Routing). Cette méthode consiste à noter une adresse au format +`adresse/longueur_préfixe`, elle induit une attribution des IP par blocs. + +Les `n` bits (où `n` est la longueur du préfixe) les plus significatifs +servent à identifier le réseau auquel l'adresse appartient. + +## IPv4 + +Une adresse IPv4 s'écrit sur 32 bits et utilise une notation décimale +pointée (4 entiers séparés par des `.`), par exemple `192.168.0.1` est une +adresse IPv4. + +De même `192.168.0.0/24` est un exemple de notation CIDR pour un sous-réseau +IPv4. + +Dans un réseau local les adresses IPv4 peuvent être attribuées par le +protocole DHCP ou configurées statiquement. + +À noter que dans un sous-réseau IPv4 la première et la dernière sont +réservées respectivement pour identifier le réseau et effectuer du broadcast +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 : + +```txt +iface eth0 inet static + broadcast - +``` + +Ceci permet d'utiliser des blocs d'adresses IPv4 d'une taille de préfixe +égale à 31 afin d'interconnecter deux machines. + +### IPv4 privées + +Certains blocs d'adresses IPv4 sont réservés à des utilisations privées, +celà signifie qu'ils ne sont pas annoncés sur l'internet. Ils sont +spécifiés par la [RFC 1918](https://tools.ietf.org/html/rfc1918) et sont les +suivants : + +* `10.0.0.0/8` + +* `172.16.0.0/12` + +* `192.168.0.0/16` + +### IPv4 de lien local + +Un bloc d'IPv4 est réservé pour utilisation sur le réseau local, c'est à +dire que ce bloc n'est normalement jamais routé, il s'agit du bloc +`169.254.0.0/16`. + +### IPv4 multicast + +un bloc d'IPv4 est réservé pour du multicast, il s'agit du bloc `224.0.0.0/4`. + +## IPv6 + +Une adresse IPv6 s'écrit sur 128 bits et utilise une notation hexadécimale +séparée par des `:` (deux-points), par exemple +`2001:0db8:0000:0000:0000:0000:0000:0000` (on regroupe les octets par groupe de +2). + +Il existe également une notation compacte pour les adresses IPv6 : on peut +omettre les 0 en début de bloc et remplacer la plus longue suite de blocs nuls +par `::`, par exemple l'adresse précédente peut s'écrire `2001:db8::`. + +Ainsi `2001:db8::/32` est un exemple de notation CIDR pour un sous-réseau IPv6. + +Dans un réseau local les adresses IPv6 peuvent être attribuées par le +protocole NDP, par le protocole DHCPv6 ou configurées statiquement. + +La liste des IPv6 attribuées est disponible +[ici](https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml) +et +[là](https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml). + +Il n'y a pas de broadcast en IPv6 et la première adresse du bloc peut être +utilisée sans risque. Le broadcast est remplacé par du multicast : tous les +nœuds sur le réseau local répondent sur l'adresse `ff02::1`. + +### IPv6 uniques locales + +Un bloc d'adresses IPv6 est réservé pour des utilisations privées, c'est +l'équivalent des blocs d'IPv4 privées. Il s'agit du bloc `fc00::/7`. + +### IPv6 de lien local + +Un bloc d'IPv6 est réservé pour utilisation sur le réseau local, il s'agit +du bloc `fe80::/10`. + +### IPv6 multicast + +Un bloc d'IPv6 est réservé pour du multicast, il s'agit du bloc `ff00::/8`. + +## ip + +Sous Linux la commande privilégiée pour consulter l'état de la configuration +réseau est `ip` (fournie par la suite `iproute2`) voici quelques exemples de +commandes : + +Afficher l'état des interfaces de la machine (adresses IP attribuées et leur +sous-réseau) : + +```bash +ip address +``` + +Afficher l'état des routes IPv4 de la machine : + +```bash +ip route +``` + +Afficher l'état des routes IPv6 de la machine : + +```bash +ip -6 route +``` diff --git a/outils/protocoles/irc.md b/outils/protocoles/irc.md new file mode 100644 index 0000000..00b4c8e --- /dev/null +++ b/outils/protocoles/irc.md @@ -0,0 +1,36 @@ +# IRC + +IRC (Internet Relay Chat) est un protocole de communication textuelle. C'est le +protocole privilégié pour les discussions instantanées entre membres actifs. + +Sa version 2 est spécifiée par la [RFC +2812](https://tools.ietf.org/html/rfc2812), une [version 3](https://ircv3.net/) +est en cours de développement. + +Il utilise 2 ports : + +* Le port 6667 en TCP pour la communication en clair. + +* Le port 6697 en TCP pour la communication chiffrée avec TLS. + +Il existe deux types d'entités dans le protocole IRC : les utilisateurs et les +canaux. Un nom d'utilisateur (nick) commence obligatoirement par une lettre ou +un des caractères spéciaux définis dans la RFC. Un nom de canal commence +obligatoirement par un caractère `#`, `&`, `!` ou `+`, en pratique seul le `#` +est implémenté de manière universelle. + +Le protocole IRC utilise des commandes, dans la plupart des clients il est +possible d'envoyer une commande en entrant un `/` suivi de la commande dans le +prompt du client. + +## Modes + +Il est possible d'attribuer des «flags» aux utilisateurs et aux canaux qui +permettent de modifier leur comportement, ceux-ci s'appellent des modes, +certains modes sont spécifiés dans la RFC mais la quasi-totalité des +serveurs IRC implémentent d'autres modes pour ajouter des fonctionnalités au +protocole. + +Ces modes sont manipulables avec la commande `MODE`, par exemple `MODE nick +w` +pour ajouter le mode `w` à l'utilisateur `nick` ou `MODE #channel -t` pour +retirer le mode `t` du canal `#channel`. diff --git a/outils/protocoles/ldap.md b/outils/protocoles/ldap.md new file mode 100644 index 0000000..5e293c6 --- /dev/null +++ b/outils/protocoles/ldap.md @@ -0,0 +1,5 @@ +# LDAP + +LDAP (Lightweight Directory Access Protocol) est un protocole d'accès à une +base donnée arborescente (directory). Sa dernière version (version 3) est +spécifiée dans la [RFC 4511](https://tools.ietf.org/html/rfc4511). diff --git a/outils/protocoles/nfs.md b/outils/protocoles/nfs.md new file mode 100644 index 0000000..6d9d18f --- /dev/null +++ b/outils/protocoles/nfs.md @@ -0,0 +1,16 @@ +# NFS + +NFS (Network File System) est un système de fichiers pouvant être monté à +travers le réseau : le serveur NFS expose des parties de son arborescence qui +peuvent être montées par les clients. + +NFS utilise le port 2049 en TCP et en UDP. + +Le système de fichier ZFS supporte nativement l'export NSF de tout ou partie +de son arborescence, vous pouvez vous référer à la section *Partager un +dataset en NFS* de la page ZFS pour savoir comment faire. + +## Version 4 + +La dernière version de NFS est la version 4.2 spécifiée par la [RFC +7862](https://tools.ietf.org/html/rfc7862). diff --git a/outils/protocoles/ntp.md b/outils/protocoles/ntp.md new file mode 100644 index 0000000..7db357a --- /dev/null +++ b/outils/protocoles/ntp.md @@ -0,0 +1,7 @@ +# NTP + +NTP (Network Time Protocol) est un protocole de synchronisation d'horloge, il +utilise le port 123 en UDP. + +Sa version 4 est spécifiée par la [RFC +5905](https://tools.ietf.org/html/rfc5905). diff --git a/outils/protocoles/smtp.md b/outils/protocoles/smtp.md new file mode 100644 index 0000000..ae4810e --- /dev/null +++ b/outils/protocoles/smtp.md @@ -0,0 +1,11 @@ +# SMTP + +SMTP (Simple Mail Transfer Protocol) est un protocol d'échange de courrier +électronique. Il utilise 3 ports différents : + +* Le port 25 en TCP (smtp) pour l'échange de mail entre serveurs. + +* Le port 465 en TCP (submissions) pour la soumission de mail chiffrée par TLS. + +* Le port 587 en TCP (submission) pour la soumission de mail en clair avec + possibilité de chiffrement via la commande STARTTLS. diff --git a/tools/snmp.md b/outils/protocoles/snmp.md similarity index 62% rename from tools/snmp.md rename to outils/protocoles/snmp.md index a4dd500..59af586 100644 --- a/tools/snmp.md +++ b/outils/protocoles/snmp.md @@ -7,61 +7,59 @@ connectées. ## SNMPv3 vs SNMPv1/v2 -Pour des raisons de sécurité, vous devriez toujours utiliser SNMPv3 qui -a un système d'authentification et de chiffrement. Si votre documentation -parle de « communautés SNMP », c'est que c'est de la v1 ou v2 et que vous -devriez mieux partir en courant. +Pour des raisons de sécurité, vous devriez toujours utiliser SNMPv3 qui a un +système d'authentification et de chiffrement. Si votre documentation parle de +"communautés SNMP", c'est que c'est de la v1 ou v2 et que vous devriez +mieux partir en courant. ## Monitoring d'un APC Rack PDU avec Prometheus -Lors du déménagement de Cachan vers Saclay, le Crans a récupérer un -[APC Rack PDU 2G Metered-by-Outlet with Switching](https://www.apc.com/shop/th/en/products/Rack-PDU-2G-Metered-by-Outlet-with-Switching-ZeroU-20A-208V-16A-230V-21-C13-3-C19/P-AP8659) -venant de l'ancien équipement de la DSI à Cachan. -Ce Power Distribution Unit (PDU) est utilisé pour alimenter notre -baie de serveur principale. -Cette unité de distribution de courant est capable de monitorer chaque -prise avec plusieurs métriques utiles. Par exemple, reçoit -un courrier quand une prise surcharge la distribution. +Lors du déménagement de Cachan vers Saclay, le Crans a récupéré un [APC +Rack PDU 2G Metered-by-Outlet with +Switching](https://www.apc.com/shop/th/en/products/Rack-PDU-2G-Metered-by-Outlet-with-Switching-ZeroU-20A-208V-16A-230V-21-C13-3-C19/P-AP8659) +venant de l'ancien équipement de la DSI à Cachan. Ce Power Distribution Unit +(PDU) est utilisé pour alimenter notre baie de serveur principale. Cette unité +de distribution de courant est capable de monitorer chaque prise avec plusieurs +métriques utiles. Par exemple, reçoit un courrier quand une +prise surcharge la distribution. -Dans les sous-sections on va présenter comment mettre en place le -monitoring en SNMPv3 de ce PDU vers la base de monitoring Prometheus. +Dans les sous-sections on va présenter comment mettre en place le monitoring +en SNMPv3 de ce PDU vers la base de monitoring Prometheus. ### Configuration du SNMPv3 et des droits d'accès -*On a réalisé ces étapes sur le firmware AOS v6.1.3. -Si vous vous sentez aventureux et mettez à jour le PDU, les menus -et identifiants risquent de changer.* +*On a réalisé ces étapes sur le firmware AOS v6.1.3. Si vous vous sentez +aventureux et mettez à jour le PDU, les menus et identifiants risquent de +changer.* -Connectez-vous à l'interface Web du PDU. Par défault il écoute en HTTP -sur son port 80 et on peut s'identifier avec l'identifiant `apc` et le -mot de passe `apc`. *Néanmoins, pour sécuriser l'infrastructure, le mot de -passe actuel est dans la bibliothèque de mots de passe du Crans.* +Connectez-vous à l'interface Web du PDU. Par défault il écoute en HTTP sur +son port 80 et on peut s'identifier avec l'identifiant `apc` et le mot de passe +`apc`. *Néanmoins, pour sécuriser l'infrastructure, le mot de passe actuel +est dans la bibliothèque de mots de passe du Crans.* -Après connexion, allez dans -`Configuration > Network > SNMPv3 > Access` et cochez -`Enable SNMPv3 access` puis appliquez. +Après connexion, allez dans `Configuration > Network > SNMPv3 > Access` et +cochez `Enable SNMPv3 access` puis appliquez. -Le PDU va proposer de se redémarrer pour appliquer les changements. -Déjà, redémarrer le PDU ne coupe pas les prises (heureusement!), mais -on a d'autres changements à réaliser avant de le redémarrer. +Le PDU va proposer de se redémarrer pour appliquer les changements. Déjà, +redémarrer le PDU ne coupe pas les prises (heureusement!), mais on a d'autres +changements à réaliser avant de le redémarrer. -On change les identifiants pour collecter les métriques en SNMPv3. -Allez dans +On change les identifiants pour collecter les métriques en SNMPv3. Allez dans `Configuration > Network > SNMPv3 > User Profiles` et configurez un utilisateur Vous devriez utiliser `SHA` pour `Authentication Protocol` et `AES` pour `Privacy Protocol` (car `MD5` et `DES` sont vraiment faibles). + *Au Crans, le compte s'appelle `crans`.* -Maintenant que le compte est configuré, il faut lui autoriser l'accès. -Allez dans -`Configuration > Network > SNMPv3 > Access Control` et choisissez l'utilisateur, -puis activez l'accès et mettez l'adresse IPv4 de la machine qui contactera le PDU en SNMP. +Maintenant que le compte est configuré, il faut lui autoriser l'accès. Allez +dans `Configuration > Network > SNMPv3 > Access Control` et choisissez +l'utilisateur, puis activez l'accès et mettez l'adresse IPv4 de la machine qui +contactera le PDU en SNMP. ### Test de l'accès SNMP -La commande suivante devrait maintenant marcher -(changer `PDU_*` avec les bonnes valeurs). -Sur les dérivées de Debian, vous devriez installer `snmp` et +La commande suivante devrait maintenant marcher (changer `PDU_*` avec les +bonnes valeurs). Sur les dérivées de Debian, vous devriez installer `snmp` et `snmp-mibs-downloader` (optionnel, télécharge une base de données non libre de correspondance des valeurs SNMP, appelées `MIBs`). @@ -73,7 +71,8 @@ echo "mibdirs +$HOME/.snmp/mibs" >> $HOME/.snmp/snmp.conf curl "https://download.schneider-electric.com/files?p_enDocType=Firmware&p_File_Name=powernet432.mib&p_Doc_Ref=APC_POWERNETMIB_432" -o $HOME/.snmp/mibs/powernet432.mib ``` -Une fois cela effectué, la commande suivante devrait afficher les valeurs intéressantes : +Une fois cela effectué, la commande suivante devrait afficher les valeurs +intéressantes : ```bash # -m ALL: try to load all SNMP MIBs to output metrics name @@ -91,25 +90,28 @@ personne habitué au SNMPv3. métriques utiles. Vous tombez devant un donjon qui vient de vous spammer plus de 2000 métriques, que faites-vous ?* -`snmpwalk` devrez vous spammer de métriques toutes plus ou moins utiles. -Si vous avez la base de données de MIBs installée, la sortie devrait être -lisible et vous devriez rapidement trouver votre bonheur. Sinon vous êtes -en quête soit pour deviner les identifiants des métriques intéressantes, -soit pour aller chercher un fichier de définition MIB sur le site du -constructeur. +`snmpwalk` devrez vous spammer de métriques toutes plus ou moins utiles. Si +vous avez la base de données de MIBs installée, la sortie devrait être +lisible et vous devriez rapidement trouver votre bonheur. Sinon vous êtes en +quête soit pour deviner les identifiants des métriques intéressantes, soit +pour aller chercher un fichier de définition MIB sur le site du constructeur. Pour le PDU, après quelques observations, on a gardé : - * `rPDU2DeviceStatusLoadState` - * `rPDU2DeviceStatusPower` - * `rPDU2DeviceStatusPeakPower` - * `rPDU2PhaseStatusPowerFactor` - * `rPDU2OutletMeteredStatusPower` +* `rPDU2DeviceStatusLoadState` + +* `rPDU2DeviceStatusPower` + +* `rPDU2DeviceStatusPeakPower` + +* `rPDU2PhaseStatusPowerFactor` + +* `rPDU2OutletMeteredStatusPower` ### Configuration de l'exporteur Prometheus SNMP -*C'est bien beau le SNMPv3, mais je ne vais pas snmpwalk dans un -cron tout de même !* +*C'est bien beau le SNMPv3, mais je ne vais pas snmpwalk dans un cron tout de +même !* Prometheus SNMP exporter est livré avec un générateur de configuration. Cette étape de génération permet de créer la configuration de l'exporteur @@ -139,18 +141,17 @@ modules: priv_password: PDU_PRIVACY_PASSPHRASE ``` -Sur les dérivées de Debian, vous aurez à installer `prometheus-snmp-exporter` -puis lancer -`prometheus-snmp-generator generate` dans `/etc/prometheus/` qui contient -`generator.yml`. +Sur les dérivées de Debian, vous aurez à installer +`prometheus-snmp-exporter` puis lancer `prometheus-snmp-generator generate` +dans `/etc/prometheus/` qui contient `generator.yml`. ### Collecter l'exporteur avec Prometheus -Maintenant que l'exporteur est configuré, vous pouvez le démarrer. -Il écoutera sur le port `9116` par défaut. +Maintenant que l'exporteur est configuré, vous pouvez le démarrer. Il +écoutera sur le port `9116` par défaut. -Dans la configuraiton de Prometheus, vous pouvez ajouter une section -pour interroger cet exporteur en utilisant la définition `apc_pdu` définie dans +Dans la configuraiton de Prometheus, vous pouvez ajouter une section pour +interroger cet exporteur en utilisant la définition `apc_pdu` définie dans la dernière section: ```YAML @@ -174,9 +175,10 @@ scrape_configs: target_label: __address__ ``` -La bidouille `relabel_configs` permet à Prometheus de query l'exporter avec -le nom d'hôte ou adresse IP du périphérique afin de collecter les métriques +La bidouille `relabel_configs` permet à Prometheus de query l'exporter avec le +nom d'hôte ou adresse IP du périphérique afin de collecter les métriques SNMP tout en gardant le label `instance` propre dans sa base de données. Vous devriez pouvoir redémarrer Prometheus et le PDU devrait être monitoré. + *Voilà, vous brandissez Excalibur de fierté!* diff --git a/tools/tls.md b/outils/protocoles/tls.md similarity index 62% rename from tools/tls.md rename to outils/protocoles/tls.md index 56b2cc0..f01fd6d 100644 --- a/tools/tls.md +++ b/outils/protocoles/tls.md @@ -1,26 +1,34 @@ # TLS -TLS (Transport Layer Security) est un protocole cryptographique permettant une communication sécurisée sur un réseau. +TLS (Transport Layer Security) est un protocole cryptographique permettant une +communication sécurisée sur un réseau. ## TLS 1.3 -La dernière version de TLS est TLS 1.3 spécifiée dans la [RFC 8446](https://tools.ietf.org/html/rfc8446). +La dernière version de TLS est TLS 1.3 spécifiée dans la [RFC +8446](https://tools.ietf.org/html/rfc8446). ## OpenSSL -[OpenSSL](https://www.openssl.org/) est une bibliothèque implémentant le protocole TLS elle vient avec un binaire `openssl` permettant notamment de gérer les certificats TLS et d'effectuer des connexions chiffrées. +[OpenSSL](https://www.openssl.org/) est une bibliothèque implémentant le +protocole TLS elle vient avec un binaire `openssl` permettant notamment de +gérer les certificats TLS et d'effectuer des connexions chiffrées. ### s_client -Le binaire `openssl` lancé avec la sous-commande `s_client` permet d'effectuer une connexion TLS à la manière de netcat. Voici un exemple : +Le binaire `openssl` lancé avec la sous-commande `s_client` permet d'effectuer +une connexion TLS à la manière de netcat. Voici un exemple : ```bash openssl s_client -connect irc.crans.org:6697 ``` -Ceci permet de se connecter sur le port 6697 du serveur identifié par le nom de domaine `irc.crans.org`. +Ceci permet de se connecter sur le port 6697 du serveur identifié par le nom +de domaine `irc.crans.org`. -Il est également possible d'utiliser des protocoles utilisant STARTTLS (c'est à dire passant d'une connexion en clair à une connexion chiffrée a l'aide d'une commande) : +Il est également possible d'utiliser des protocoles utilisant STARTTLS (c'est +à dire passant d'une connexion en clair à une connexion chiffrée a l'aide +d'une commande) : ```bash openssl s_client -starttls smtp -connect redisdead.crans.org:25 @@ -28,31 +36,45 @@ openssl s_client -starttls smtp -connect redisdead.crans.org:25 ### genpkey -La sous-commande `genpkey` permet de générer une clef privée, par exemple (pour générer une clef privée ED25519) : +La sous-commande `genpkey` permet de générer une clef privée, par exemple +(pour générer une clef privée ED25519) : ```bash openssl genpkey -algorithm ED25519 -out key.pem ``` -Voici les valeurs notables possible de l'option `-algorithm` et les valeurs associées de l'option `-pkeyopt` permettant d'ajuster les paramètres de la clef privée: - * `ED25519` (pas d'options) - * `ED448` (pas d'options) - * `RSA` +Voici les valeurs notables possible de l'option `-algorithm` et les valeurs +associées de l'option `-pkeyopt` permettant d'ajuster les paramètres de la +clef privée: + +* `ED25519` (pas d'options) + +* `ED448` (pas d'options) + +* `RSA` + * `rsa_keygen_bits`: le nombre de bits de la clef privée - * `EC` + + * `EC` + * `ec_paramgen_curve`: le nom de la courbe de la clef privée ### x509 -La sous-commande `x509` permet d'afficher des informations sur un certificat et d'effectuer des opérations de signature. +La sous-commande `x509` permet d'afficher des informations sur un certificat et +d'effectuer des opérations de signature. On peut par exemple l'utiliser pour afficher la clef publique d'un certificat : + ```bash openssl x509 -pubkey -in cert.pem -noout ``` Ou encore signer un certificat avec une autorité : + ```bash openssl x509 -req -in cert.csr -CA ca_cert.pem -CAkey ca_key.pem -CAcreateserial -out cert.pem -days 3650 ``` -Le certificat `cert.pem` est délivrée par l'autorité `ca_cert.pem` pour 10 ans (3650 jours). + +Le certificat `cert.pem` est délivrée par l'autorité `ca_cert.pem` pour 10 +ans (3650 jours). diff --git a/services/README.md b/services/README.md new file mode 100644 index 0000000..360b794 --- /dev/null +++ b/services/README.md @@ -0,0 +1,11 @@ +# Services + +## Présentation + +Ce dossier contient une présentation rapide des différents services du Crans +mis à disposition aux utilisateurices. La documentation des services du Crans +pour le Crans est disponible dans [ce dossier](../infrastructure/services). + +## Organisation + +TODO diff --git a/services/belenios.md b/services/belenios.md index e3198fb..9563375 100644 --- a/services/belenios.md +++ b/services/belenios.md @@ -1,70 +1,82 @@ # Belenios -Belenios est un service développé par l'Inria recréant un bureau de vote complet en ligne avec autant voire plus de sécurité grâce à des bulletins chiffrés. Il a été mis en place pour l'assemblée générale du Crans en 2020, alors que la pandémie de Covid-19 empêchait toute réunion physique. +Belenios est un service développé par l'Inria recréant un bureau de vote +complet en ligne avec autant voire plus de sécurité grâce à des bulletins +chiffrés. Il a été mis en place pour l'assemblée générale du Crans en +2020, alors que la pandémie de Covid-19 empêchait toute réunion physique. ## Installation -On considère que l'on dispose d'une machine virtuelle neuve installée sous Debian Bullseye. +On considère que l'on dispose d'une machine virtuelle neuve installée sous +Debian Bullseye. -Belenios n'est malheureusement pas encore packagé dans Debian. Par chance, toutes ses dépendances le sont. On installe donc toutes les dépendances via APT, puis on compile Belenios manuellement. +Belenios n'est malheureusement pas encore packagé dans Debian. Par chance, +toutes ses dépendances le sont. On installe donc toutes les dépendances via +APT, puis on compile Belenios manuellement. ### Dépendances -Belenios est intégrallement écrit en OcamL. On installe toutes ses dépendances Debian, comme indiqué dans le README : +Belenios est intégralement écrit en OCaml. On installe toutes ses +dépendances Debian, comme indiqué dans le README : ```bash -$ sudo apt update -$ sudo apt install --no-install-recommends bubblewrap build-essential ca-certificates cracklib-runtime jq libgd-securityimage-perl libgmp-dev libncurses-dev libpcre3-dev libssl-dev libsqlite3-dev m4 pkg-config unzip wget zip zlib1g-dev +sudo apt update +sudo apt install --no-install-recommends bubblewrap build-essential ca-certificates cracklib-runtime jq libgd-securityimage-perl libgmp-dev libncurses-dev libpcre3-dev libssl-dev libsqlite3-dev m4 pkg-config unzip wget zip zlib1g-dev ``` -On installe ensuite toutes les dépendances OCamL depuis les paquets Debian, ce qui est plus économe par rapport à compiler toutes les bibliothèques avec Opam : +On installe ensuite toutes les dépendances OCamL depuis les paquets Debian, ce +qui est plus économe par rapport à compiler toutes les bibliothèques avec +Opam : ```bash -$ sudo apt install --no-install-recommends dune eliom libatdgen-ocaml-dev libcalendar-ocaml-dev libcmdliner-ocaml-dev libcryptokit-ocaml-dev libcsv-ocaml-dev libgettext-ocaml-dev libzarith-ocaml-dev +sudo apt install --no-install-recommends dune eliom libatdgen-ocaml-dev libcalendar-ocaml-dev libcmdliner-ocaml-dev libcryptokit-ocaml-dev libcsv-ocaml-dev libgettext-ocaml-dev libzarith-ocaml-dev ``` -On doit enfin installer ``ocsigenserver``, qui sert de serveur web tel Nginx ou Apache adapté pour les projets OcamL : +On doit enfin installer `ocsigenserver`, qui sert de serveur web tel Nginx ou +Apache adapté pour les projets OCaml : ```bash -$ sudo apt install --no-install-recommends ocsigenserver +sudo apt install --no-install-recommends ocsigenserver ``` - ### Compilation de Belenios On commence par cloner le dépôt dans un endroit adapté : ```bash -$ sudo git clone https://gitlab.inria.fr/belenios/belenios.git /opt/belenios -b 1.14 +sudo git clone https://gitlab.inria.fr/belenios/belenios.git /opt/belenios -b 1.14 ``` -Il suffit ensuite dans le dossier ``/opt/belenios`` de lancer ``make build-release-server``. - +Il suffit ensuite dans le dossier `/opt/belenios` de lancer +`make build-release-server`. ### Liens symboliques -Pour avoir des binaires à des endroits cohérents avec la distribution Debian, on ajoute des liens symboliques à des endroits pertinents : +Pour avoir des binaires à des endroits cohérents avec la distribution Debian, +on ajoute des liens symboliques à des endroits pertinents : ```bash -$ sudo ln -s /opt/belenios/_run/usr/lib/belenios /usr/lib/ocaml/belenios -$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform /usr/lib/ocaml/belenios-platform -$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-js /usr/lib/ocaml/belenios-platform-js -$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-native /usr/lib/ocaml/belenios-platform-native -$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-server /usr/lib/ocaml/belenios-server -$ sudo ln -s /opt/belenios/_run/usr/lib/belenios-tool /usr/lib/ocaml/belenios-tool -$ sudo ln -s /opt/belenios/_run/usr/share/belenios-server /usr/share/belenios-server +sudo ln -s /opt/belenios/_run/usr/lib/belenios /usr/lib/ocaml/belenios +sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform /usr/lib/ocaml/belenios-platform +sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-js /usr/lib/ocaml/belenios-platform-js +sudo ln -s /opt/belenios/_run/usr/lib/belenios-platform-native /usr/lib/ocaml/belenios-platform-native +sudo ln -s /opt/belenios/_run/usr/lib/belenios-server /usr/lib/ocaml/belenios-server +sudo ln -s /opt/belenios/_run/usr/lib/belenios-tool /usr/lib/ocaml/belenios-tool +sudo ln -s /opt/belenios/_run/usr/share/belenios-server /usr/share/belenios-server ``` - ### Configuration de ocsigenserver -On commence par créer les dossiers de données qui nous intéressent, avec les bonnes permissions : +On commence par créer les dossiers de données qui nous intéressent, avec les +bonnes permissions : ```bash -$ sudo -u ocsigen mkdir -p /etc/ocsigenserver/conf.d /var/lib/belenios /var/lib/belenios/data /var/lib/belenios/upload /var/lib/belenios/spool /var/log/belenios +sudo -u ocsigen mkdir -p /etc/ocsigenserver/conf.d /var/lib/belenios /var/lib/belenios/data /var/lib/belenios/upload /var/lib/belenios/spool /var/log/belenios ``` -On ajoute enfin le fichier de configuration fourni par Belenios dans ``/etc/ocsigenserver/conf.d/belenios.conf``, en remplaçant les bonnes variables : +On ajoute enfin le fichier de configuration fourni par Belenios dans +`/etc/ocsigenserver/conf.d/belenios.conf`, en remplaçant les bonnes +variables : ```xml @@ -146,28 +158,41 @@ On ajoute enfin le fichier de configuration fourni par Belenios dans ``/etc/ocsi ``` -Il faut noter que ``ocsigenserver`` n'est pas lancé au démarrage par défaut et un ``systemctl start ocsigenserver`` ne fonctionne pas, un ``service ocsigenserver start`` en revanche si. Pour autoriser ``ocsigenserver`` à se lancer au démarrage, il faut modifier le fichier ``/etc/default/ocsigenserver`` pour écrire ``LAUNCH_AT_STARTUP=true``. Il sera ensuite possible de démarrer le serveur grâce à systemd. +Il faut noter que ``ocsigenserver`` n'est pas lancé au démarrage par défaut +et un ``systemctl start ocsigenserver`` ne fonctionne pas, un +`service ocsigenserver start` en revanche si. Pour autoriser `ocsigenserver` à +se lancer au démarrage, il faut modifier le fichier +`/etc/default/ocsigenserver` pour écrire `LAUNCH_AT_STARTUP=true`. Il sera +ensuite possible de démarrer le serveur grâce à systemd. -En redémarrant ``ocsigenserver``, Belenios sera accessible sur son port 80. Après une configuration de reverse-proxy près, Belenios est déjà accessible :) - -Pour modifier le logo, il faut regarder autour de ``/usr/share/belenios-server/logo.png``. +En redémarrant `ocsigenserver`, Belenios sera accessible sur son port 80. +Après une configuration de reverse-proxy près, Belenios est déjà accessible :) +Pour modifier le logo, il faut regarder autour de +`/usr/share/belenios-server/logo.png`. ### Déployer avec Ansible -L'ensemble des opérations décrites sont déployées par le rôle Ansible du Crans : `` - -Il prend en configuration le nom de domaine utilisé (``belenios.domain``), des adresses mails de contact (``belenios.email_contact`` et ``belenios.email_from``) ainsi que les paramètres du CAS (``belenios.cas.name`` et ``belenios.cas.server``, voir ci-dessous). +L'ensemble des opérations décrites sont déployées par le rôle Ansible du Crans +. +Il prend en configuration le nom de domaine utilisé (``belenios.domain``), des +adresses mails de contact (`belenios.email_contact` et `belenios.email_from`) +ainsi que les paramètres du CAS (`belenios.cas.name` et `belenios.cas.server`, +voir ci-dessous). ## Utilisation -Toute personne ayant un compte Crans peut créer une élection sur Belenios en se connectant via le CAS du Crans. Cela se configure sur la ligne du fichier de configuration ocsigenserver : +Toute personne ayant un compte Crans peut créer une élection sur Belenios en +se connectant via le CAS du Crans. Cela se configure sur la ligne du fichier de +configuration ocsigenserver : + ```xml ``` -On peut remplacer le nom par ``CAS Cr@ns`` et le serveur par ``. +On peut remplacer le nom par ``CAS Cr@ns`` et le serveur par +. Une fois connecté, on peut créer et administrer une élection. @@ -175,32 +200,49 @@ Une fois connecté, on peut créer et administrer une élection. Belenios propose deux modes pour gérer les mots de passe : - * Automatique (mode dégradé : les codes de vote seront générés par le serveur) - * Manuel (mode sécurisé : un tiers se chargera des codes de vote) +* Automatique (mode dégradé : les codes de vote seront générés par le + serveur) -Dans le premier mode, Belenios se charge de générer les codes de vote et les envoie lui-même par mail. -Dans le second mode, recommandé, c'est vous qui envoyez vous même les codes de vote aux électeurs. +* Manuel (mode sécurisé : un tiers se chargera des codes de vote) -Le code de vote ne servant qu'à débuter l'élection pour une personne, la sécurité ne réside pas ici. C'est plus ou moins l'équivalent de donner son nom au bureau de vote. Ce n'est pas une information sensible. À la fin du vote on demande aux votants de réellement s'identifier avant de glisser les bulletins dans l'urne. On dispose de deux moyens d'authentification : +Dans le premier mode, Belenios se charge de générer les codes de vote et les +envoie lui-même par mail. Dans le second mode, recommandé, c'est vous qui +envoyez vous même les codes de vote aux électeurs. - * Générer des mots de passe confidentiels (hashés sur le serveur) par personne, géré par Belenios ; - * Utiliser un CAS. +Le code de vote ne servant qu'à débuter l'élection pour une personne, la +sécurité ne réside pas ici. C'est plus ou moins l'équivalent de donner son +nom au bureau de vote. Ce n'est pas une information sensible. À la fin du vote +on demande aux votants de réellement s'identifier avant de glisser les +bulletins dans l'urne. On dispose de deux moyens d'authentification : -Il va de soi qu'on vous recommande la deuxième option. Cela peut être n'importe quel serveur CAS, pas nécessairement celui du Crans. Par exemple, on utilisera `` pour le Crans, `` pour la Note Kfet, ou `` pour celui de l'Inria. +* Générer des mots de passe confidentiels (hashés sur le serveur) par + personne, géré par Belenios ; -Pensez bien à autoriser Belenios à utiliser votre serveur CAS, et à faire attention à ce que les pseudos renvoyés soient en ASCII ! +* Utiliser un CAS. -Plus d'informations ici : `` +Il va de soi qu'on vous recommande la deuxième option. Cela peut être +n'importe quel serveur CAS, pas nécessairement celui du Crans. Par exemple, on +utilisera pour le Crans, + pour la Note Kfet, ou + pour celui de l'Inria. + +Pensez bien à autoriser Belenios à utiliser votre serveur CAS, et à faire +attention à ce que les pseudos renvoyés soient en ASCII ! + +Plus d'informations ici : . ### Inscription des électeurs -La liste des électeurs doit être arrêtée avant la création de l'élection. La liste doit être donnée sous la forme ``ADRESSE@EMAIL,PSEUDO``. +La liste des électeurs doit être arrêtée avant la création de l'élection. +La liste doit être donnée sous la forme `ADRESSE@EMAIL,PSEUDO`. -Depuis la dernière version, il est également définir un poids par électeur. +Depuis la dernière version, il est également possible de définir un poids par +électeur. **Atention :** -Belenios ne supporte pas l'UTF-8 dans les pseudos. Assurez-vous de garder des pseudos ASCII. Et dans les adresses e-mail, mais cela va de soi. +Belenios ne supporte pas l'UTF-8 dans les pseudos. Assurez-vous de garder des +pseudos ASCII. Et dans les adresses e-mail, mais cela va de soi. #### Générer la liste des adhérents avec Re2o @@ -210,23 +252,39 @@ Pas besoin de plus d'une ligne : "\n".join(map(lambda user: f"{user.get_mail},{user.pseudo}", utils.all_adherent(including_asso=False).filter(adherent__isnull=False))) ``` -C'est faux : il faut importer ```utils``` et sans doute écrire dans un fichier. +C'est faux : il faut importer `utils` et sans doute écrire dans un fichier. ### Déclaration des autorités de déchiffrement -Il s'agit de l'équivalent des assesseurs qui vont contrôler et dépouiller l'élection. Il peut y en avoir plusieurs. Chacun aura sa clé, et la clé sera nécessaire pour le dépouillement. Dans tous les cas, Belenios lui-même est une autorité de déchiffrement mais il est recommandé d'avoir une autorité extérieure. +Il s'agit de l'équivalent des assesseurs qui vont contrôler et dépouiller +l'élection. Il peut y en avoir plusieurs. Chacun aura sa clé, et la clé sera +nécessaire pour le dépouillement. Dans tous les cas, Belenios lui-même est +une autorité de déchiffrement mais il est recommandé d'avoir une autorité +extérieure. **IMPORTANT :** -Cela tient plus du mauvais pressentiment que de l'expérience, mais pensez bien à VRAIMENT conserver la clé privée en lieu sûr, elle n'est pas récupérable. Jeter sa clé privée, c'est comme acheter une urne en verre incassable avec une serrure qui tient le coup et jeter le trousseau dans les égouts, en veillant à la fondre et la broyer avant. Vous pourrez ajouter des bulletins dans l'urne mais jamais la dépouiller. +Cela tient plus du mauvais pressentiment que de l'expérience, mais pensez bien +à VRAIMENT conserver la clé privée en lieu sûr, elle n'est pas +récupérable. Jeter sa clé privée, c'est comme acheter une urne en verre +incassable avec une serrure qui tient le coup et jeter le trousseau dans les +égouts, en veillant à la fondre et la broyer avant. Vous pourrez ajouter des +bulletins dans l'urne mais jamais la dépouiller. ### Élection -Une fois l'élection créée, il n'est plus possible de la modifier, ce qui est normal. Il est possible de définir les horaires d'ouverture de l'élection (attention : les horaires sont sur le fuseau UTC !). - -Pour voter, chaque participant doit présenter son code d'élection, voter pour chacune des questions, puis soumettre son bulletin en s'authentifiant via le moyen défini. Son bulletin est ensuite chiffré et enregistré. Il est possible de revoter autant de fois que nécessaire, chaque vote annulant le précédent. +Une fois l'élection créée, il n'est plus possible de la modifier, ce qui est +normal. Il est possible de définir les horaires d'ouverture de l'élection +(attention : les horaires sont sur le fuseau UTC !). +Pour voter, chaque participant doit présenter son code d'élection, voter pour +chacune des questions, puis soumettre son bulletin en s'authentifiant via le +moyen défini. Son bulletin est ensuite chiffré et enregistré. Il est possible +de revoter autant de fois que nécessaire, chaque vote annulant le précédent. ### Dépouillement -Après l'élection, et pas avant (ce qui n'est de toute façon pas possible), chaque autorité de déchiffrement doit soumettre sa clé privée pour ouvrir l'urne. Une fois cela fait, les résultats sont publics sur la page de l'élection. +Après l'élection, et pas avant (ce qui n'est de toute façon pas possible), +chaque autorité de déchiffrement doit soumettre sa clé privée pour ouvrir +l'urne. Une fois cela fait, les résultats sont publics sur la page de +l'élection. diff --git a/critical/borg.md b/services/borg.md similarity index 93% rename from critical/borg.md rename to services/borg.md index cfb6b50..6b0c7b1 100644 --- a/critical/borg.md +++ b/services/borg.md @@ -1,4 +1,5 @@ # 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é @@ -42,11 +43,14 @@ 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 + +* 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 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. @@ -58,15 +62,18 @@ 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. @@ -84,7 +91,8 @@ 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 @@ -118,32 +126,39 @@ 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. -``` -$ borgmatic init -e repokey + +```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. -``` -$ borgmatic -$ borgmatic -v 2 + +```bash +borgmatic +borgmatic -v 2 ``` ### Lister les différentes sauvegardes dans l'archive -``` -$ borgmatic list + +```bash +borgmatic list ``` ### Monter une sauvegarde précise sur un point de montage -``` -$ 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 + +```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/services/framadate.md b/services/framadate.md index 6e8670f..7487c12 100644 --- a/services/framadate.md +++ b/services/framadate.md @@ -1,50 +1,74 @@ # Framadate + Framadate est un software qui permet de faire un choix commun entre plusieurs options depuis un navigateur web. ## Installation + Pour installer le logiciel, on clone le dépot du projet depuis le serveur gitlab -de framadate : `git clone https://framagit.org/framasoft/framadate/framadate.git --b 1.1.11 /var/www/framadate`. Il est aussi nécessaire de tirer quelques -dépendances à la main : `sudo apt install php-fpm php-intl php-mbstring -php-mysql composer`. On utilise ensuite composer pour installer les -dépéndances php `cd /var/www/framadate; sudo -u www-data composer install`. On -créée le fichier de log à la main `sudo -u www-data touch -/var/www/framadate/admin/stdout.log; sudo chmod 0600 -/var/www/framadate/admin/stdout.log`. +de framadate : + +```bash +git clone https://framagit.org/framasoft/framadate/framadate.git -b 1.1.11 /var/www/framadate +``` + +Il est aussi nécessaire de tirer quelques +dépendances à la main : + +```bash +sudo apt install php-fpm php-intl php-mbstring php-mysql composer +``` + +On utilise ensuite composer pour installer les +dépéndances php `cd /var/www/framadate; sudo -u www-data composer install`. +On créée le fichier de log à la main + +```bash +sudo -u www-data touch /var/www/framadate/admin/stdout.log; sudo chmod 0600 /var/www/framadate/admin/stdout.log +``` ## Configuration de la base de données + Le logiciel a besoin d'une base de donnée, ici on a pas le choix et on doit -utiliser une base de données mysql qu'on installera donc en local: +utiliser une base de données mysql qu'on installera donc en local : `sudo apt install mariadb`. Dans laquelle on crééra (via le shell mysql `sudo mysql`): - - `CREATE USER 'framadate'@'localhost' WITH PASSWORD 'ploptoto';` un - utilisateur framadate - - `CREATE DATABASE framadate;` une base de données éponyme - - `GRANT ALL PRIVILEGES ON DATABASE framadate to 'framadate'@'localhost';` sur - laquelle on donnera tous les droits à l'utilisateur framadate + +* `CREATE USER 'framadate'@'localhost' WITH PASSWORD 'ploptoto';` un + utilisateur framadate + +* `CREATE DATABASE framadate;` une base de données éponyme + +* `GRANT ALL PRIVILEGES ON DATABASE framadate to 'framadate'@'localhost';` sur + laquelle on donnera tous les droits à l'utilisateur framadate ## Configuration du logiciel + Le fichier de configuration du logiciel est trouvable dans `/var/www/framadate/app/inc/config.php`. Le fichier de configuration a des défauts plutôt sains mais il y a quand meme quelques options de configuration à préciser : - - pour la connexion à la base de donnée : -``` -// Database server name, leave empty to use a socket -const DB_CONNECTION_STRING = 'mysql:host=localhost;dbname=framadate;port=3306'; -// Database user -const DB_USER= 'framadate'; -// Database password -const DB_PASSWORD = 'ploptoto'; -``` - - pour le serveur smtp, on authorise l'envoir de mail `'use_smtp' => true`, - on précise le serveur smtp auquel se connecter `'port' => 25` et la source - des mails : `const ADRESSEMAILREPONSEAUTO = 'framadate@crans.org';` + +* pour la connexion à la base de donnée : + + ```txt + // Database server name, leave empty to use a socket + const DB_CONNECTION_STRING = 'mysql:host=localhost;dbname=framadate;port=3306'; + // Database user + const DB_USER= 'framadate'; + // Database password + const DB_PASSWORD = 'ploptoto'; + ``` + +* pour le serveur smtp, on authorise l'envoir de mail `'use_smtp' => true`, + on précise le serveur smtp auquel se connecter `'port' => 25` et la source + des mails : `const ADRESSEMAILREPONSEAUTO = 'framadate@crans.org';` ## Configuration nginx + Il faut maintenant configurer nginx et protéger l'accès à la zone d'administration par mot de passe. ## Migrations + Il ne reste plus qu'à effectuer les migrations dans la section d'administrations du site `https://framadate.crans.org/admin/migrations.php` diff --git a/services/galene.md b/services/galene.md index 62283fd..162958f 100644 --- a/services/galene.md +++ b/services/galene.md @@ -1,40 +1,82 @@ # Galène, visio-conférence -Galène est un logiciel de visio-conférence écrit en Golang (pure) sous licence MIT. -Il s'appuie sur le standard Web W3C WebRTC afin de connecter plusieurs navigateurs Web ensembles pour réaliser des visio-conférences. +Galène est un logiciel de visio-conférence écrit en Golang (pure) sous +licence MIT. Il s'appuie sur le standard Web W3C WebRTC afin de connecter +plusieurs navigateurs Web ensembles pour réaliser des visio-conférences. Site officiel : -Il est trivial à installer sur tous les systèmes d'exploitation en suivant le fichier `INSTALL` du dépôt de code. Il suffit d'avoir Golang et d'ouvrir le parefeu correctement. +Il est trivial à installer sur tous les systèmes d'exploitation en suivant le +fichier `INSTALL` du dépôt de code. Il suffit d'avoir Golang et d'ouvrir le +parefeu correctement. ## Acronymes -L'audio-visuel est un domaine remplie d'acronymes. Pour le bien être des futurs responsables techniques qui s'arracheront les cheveux en essayant de debugguer Galène, voici une liste partielle d'acronymes : +L'audio-visuel est un domaine remplie d'acronymes. Pour le bien être des +futurs responsables techniques qui s'arracheront les cheveux en essayant de +debugguer Galène, voici une liste partielle d'acronymes : - * **WebRTC** : Web Real Time Communication. Protocole permettant aux navigateurs Web de gérer des flux UDP. Utilisé par exemple par WebTorrent pour réaliser du Torrent, ou par toutes les applications classiques de visio-conférences. Le chiffrement est forcé dans le standard. - * **HLS** : HTTP Live Streaming. Le principe consiste à découper un flux vidéo en segments et d'exposer ces segments sur un serveur HTTP. En 2021, le HLS est utilisé par PeerTube (sur du WebTorrent), Twitch et YouTube. - * **SRT** : ce n'est pas le standard de sous-titre `.srt`, mais un protocole libre qui a pour but de remplacer `RTMP` (qui est un stream de fichier FLV, héritage de Flash Player). - * **RTP** : Real Time Protocol, standard audio-visuel initialement pour le téléphone SIP, VoIP, VoLTE (appels sur 4G) et la Télévision Digitale (IPTV). - * **DTLS-SRTP** : Secure Real Time Protocol avec un chiffrement standardisé. - * **SFU** : Selective Forwarding Unit. Galène est un SFU, il reçoit des flux de plusieurs navigateurs Web et les redistribue selon des salons et permissions. - * **Pion** : la librarie Golang pour utiliser WebRTC. Utilisé par Galène. - * **TURN** : Traversal Using Relays around NAT. Serveur intermédiaire (proxy) pour traverser un parefeu trop limitant. - * **STUN** : Session Traversal Utilities for NAT. Serveur permettant de réfléchir les adresse IP publiques d'un utilisateur et de taper sur son parefeu de l'extérieur. Un TURN contient un STUN. - * **ICE** : Interactive Connectivity Establishment. Procédure pour trouer des parefeux (en utilisant des STUN et TURN) et ouvrir des flux UDP entre des machines distantes. - * **VP8/VP9/AV1** : Codecs vidéos royalty-free développés par Google. Ils sont intégrés dans le code source de Chromium et Firefox. AV1 est le successeur de VP9 qui est le successeur de VP8. AV1 est un codec vidéo adaptatif. - * **Opus** : Codec audio libre intégré dans le code source des navigateurs Web. Il est très performant pour coder de la musique ou de la voix. Il hérite de SILK qui est le codec historique de Skype. - * **H264/H265** : Codecs non royalty-free (bouh!) poussés par la fondation MPEG et Apple. Les vielles versions de Safari ne supportent que ces codecs. +* **WebRTC** : Web Real Time Communication. Protocole permettant aux + navigateurs Web de gérer des flux UDP. Utilisé par exemple par WebTorrent + pour réaliser du Torrent, ou par toutes les applications classiques de + visio-conférences. Le chiffrement est forcé dans le standard. + +* **HLS** : HTTP Live Streaming. Le principe consiste à découper un flux + vidéo en segments et d'exposer ces segments sur un serveur HTTP. En 2021, le + HLS est utilisé par PeerTube (sur du WebTorrent), Twitch et YouTube. + +* **SRT** : ce n'est pas le standard de sous-titre `.srt`, mais un protocole + libre qui a pour but de remplacer `RTMP` (qui est un stream de fichier FLV, + héritage de Flash Player). + +* **RTP** : Real Time Protocol, standard audio-visuel initialement pour le + téléphone SIP, VoIP, VoLTE (appels sur 4G) et la Télévision Digitale (IPTV). + +* **DTLS-SRTP** : Secure Real Time Protocol avec un chiffrement standardisé. + +* **SFU** : Selective Forwarding Unit. Galène est un SFU, il reçoit des + flux de plusieurs navigateurs Web et les redistribue selon des salons et + permissions. + +* **Pion** : la librarie Golang pour utiliser WebRTC. Utilisé par Galène. + +* **TURN** : Traversal Using Relays around NAT. Serveur intermédiaire + (proxy) pour traverser un parefeu trop limitant. + +* **STUN** : Session Traversal Utilities for NAT. Serveur permettant de + réfléchir les adresse IP publiques d'un utilisateur et de taper sur son + parefeu de l'extérieur. Un TURN contient un STUN. + +* **ICE** : Interactive Connectivity Establishment. Procédure pour trouer + des parefeux (en utilisant des STUN et TURN) et ouvrir des flux UDP entre des + machines distantes. + +* **VP8/VP9/AV1** : Codecs vidéos royalty-free développés par Google. Ils + sont intégrés dans le code source de Chromium et Firefox. AV1 est le + successeur de VP9 qui est le successeur de VP8. AV1 est un codec vidéo + adaptatif. + +* **Opus** : Codec audio libre intégré dans le code source des navigateurs + Web. Il est très performant pour coder de la musique ou de la voix. Il hérite + de SILK qui est le codec historique de Skype. + +* **H264/H265** : Codecs non royalty-free (bouh!) poussés par la fondation + MPEG et Apple. Les vielles versions de Safari ne supportent que ces codecs. ## How to debug -Le mieux est d'utiliser Firefox pour débugger le WebRTC car leur interface est plus intuitive. -Sur Firefox vous pouvez ouvrir `about:webrtc` et sur Chromium `chrome://webrtc-internals`. +Le mieux est d'utiliser Firefox pour débugger le WebRTC car leur interface est +plus intuitive. Sur Firefox vous pouvez ouvrir `about:webrtc` et sur Chromium +`chrome://webrtc-internals`. -Souvent ce qui casse c'est l'ICE et la connexion met soit beaucoup de temps à s'établir, ou ne s'établit pas. Le tableau décrivant l'ICE dans Firefox est utile car il donne les raisons des fails. +Souvent ce qui casse c'est l'ICE et la connexion met soit beaucoup de temps à +s'établir, ou ne s'établit pas. Le tableau décrivant l'ICE dans Firefox est +utile car il donne les raisons des fails. ## Faire gaffe à la sécurité -Un TURN est un proxy. Il faut donc s'assurer qu'il ne permet pas d'accéder aux réseaux d'administration à partir de l'extérieur. - -Voir . +Un TURN est un proxy. Il faut donc s'assurer qu'il ne permet pas d'accéder aux +réseaux d'administration à partir de l'extérieur. +Voir +. diff --git a/critical/irc/inspircd.md b/services/irc/inspircd.md similarity index 93% rename from critical/irc/inspircd.md rename to services/irc/inspircd.md index 6cc9123..01c9fce 100644 --- a/critical/irc/inspircd.md +++ b/services/irc/inspircd.md @@ -1,13 +1,22 @@ # InspIRCd -InspIRCd est un logiciel serveur implémentant le [protocole IRC](/tools/irc.md) ses sources sont disponibles sur [GitHub](https://github.com/inspircd/inspircd). + +InspIRCd est un logiciel serveur implémentant le +[protocole IRC](../../outils/irc.md) ses sources sont disponibles sur +[GitHub](https://github.com/inspircd/inspircd). Ce serveur est déployé sur la VM `irc` et est joignable sur `irc.crans.org`. -InspIRCd est modulaire : la majorité de ses fonctionnalités sont fournies pas des modules qui peuvent être activés ou désactivés. +InspIRCd est modulaire : la majorité de ses fonctionnalités sont fournies pas +des modules qui peuvent être activés ou désactivés. -Voici la liste (en anglais) des modes supportés par InspIRCd, la plupart d'entre eux sont fournis par des modules chargés au Crans. La liste des modules chargés peut être consulté dans l'Ansible ou dans `/etc/inspircd` sur la VM `irc`. +Voici la liste (en anglais) des modes supportés par InspIRCd, la plupart +d'entre eux sont fournis par des modules chargés au Crans. La liste des +modules chargés peut être consulté dans l'Ansible ou dans `/etc/inspircd` +sur la VM `irc`. + +InspIRCd est compilé directement sur la VM `irc`, ses sources se trouvent dans +`/root/inspircd`. La procédure pour la compilation est la suivante : -InspIRCd est compilé directement sur la VM `irc`, ses sources se trouvent dans `/root/inspircd`. La procédure pour la compilation est la suivante : ```bash git pull git checkout tags/${VERSION} @@ -32,15 +41,15 @@ InspIRCd supports 5 types of modes : | Character | Name | Type | Parameter syntax | Usable by | Module | Description | |-----------|---------------|---------------|---------------------|-------------------|--------|-------------| | `A` | allowinvite | Switch | | Channel operators | allowinvite | Allows unprivileged users to use the `INVITE` command. | -| `B` | anticaps | Parameter | type:minlen:percent | Channel operators | anticaps | Enables blocking excessively capitalised messages (type can be `ban`, `block`, `mute`, `kick` or `kickban`). | +| `B` | anticaps | Parameter | type:minlen:percent | Channel operators | anticaps | Enables blocking excessively capitalised messages (type can be `ban`, `block`, `mute`, `kick` or `kickban`). | | `B` | blockcaps | Switch | | Channel operators | blockcaps | Enables blocking excessively capitalised messages. | | `b` | ban | List | mask | Channel operators | | Bans users matching <mask> from joining the channel. | | `C` | noctcp | Switch | | Channel operators | noctcp | Enables blocking channel messages that contain CTCPs. | | `c` | blockcolor | Switch | | Channel operators | blockcolor | Enables blocking messages that contain IRC formatting codes. | | `D` | delayjoin | Switch | | Channel operators | delayjoin | Prevents users from receiving `JOIN` messages until the joining user speaks. | | `d` | delaymsg | Parameter | seconds | Channel operators | delaymsg | Prevents newly joined users from speaking until <seconds> seconds have passed. | -| `E` | repeat | Parameter | (~\|*)lines:seconds | Channel operators | repeat | Configures the messages that should be considered a repeat. If prefixed with ~ the messages are blocked. If prefixed with * then offending users are banned. If not prefixed then offending users are kicked. | -| `e` | banexception | List | mask | Channel operators | banexception | Exempts users matching <mask> from the `b` (ban) channel mode. +| `E` | repeat | Parameter | (~/*)lines:seconds | Channel operators | repeat | Configures the messages that should be considered a repeat. If prefixed with `~` the messages are blocked. If prefixed with `*` then offending users are banned. If not prefixed then offending users are kicked. | +| `e` | banexception | List | mask | Channel operators | banexception | Exempts users matching <mask> from the `b` (ban) channel mode. | | `F` | nickflood | Parameter | changes:seconds | Channel operators | nickflood | Prevents more than <changes> nickname changes in the last <seconds> seconds. | | `f` | flood | Parameter | (*)lines:seconds | Channel operators | messageflood | Kicks users who send more than <lines> messages in the last <seconds> seconds. If prefixed with * then offending users are also banned. | | `g` | filter | List | glob | Channel operators | chanfilter | Prevents users from sending messages that match <glob>. | @@ -72,7 +81,7 @@ InspIRCd supports 5 types of modes : | `X` | exemptchanops | List | restriction:mode | Channel operators | exemptchanops | Exempts users with the <mode> prefix mode or higher from <restriction>. | | `Y` | official-join | Prefix | nick | Server operators | ojoin | Grants channel official-join status to <nick>. | | `y` | operprefix | Prefix | nick | Server operators | operprefix | Grants channel operprefix status to <nick>. | -| `z` | sslonly | Switch | | Channel operators | sslmodes | Prevents users who are not connected using TLS (SSL) from joining the channel. | +| `z` | sslonly | Switch | | Channel operators | sslmodes | Prevents users who are not connected using TLS (SSL) from joining the channel. | ### User modes @@ -98,4 +107,3 @@ InspIRCd supports 5 types of modes : | `w` | wallops | Switch | | Anyone | | Enables receiving `WALLOPS` messages from server operators. | | `x` | cloak | Switch | | Anyone | cloaking | Enables hiding of the user's hostname. | | `z` | sslqueries | Switch | | Anyone | sslmodes | Prevents messages from being sent to or received from a user that is not connected using TLS (SSL). | - diff --git a/services/jupyter.md b/services/jupyter.md index d93a88f..ac3010b 100644 --- a/services/jupyter.md +++ b/services/jupyter.md @@ -1,29 +1,48 @@ # Jupyter notebook, édition et exécution de code python à distance. -https://jupyter.org/ + + + ## Utilisation par un.e adhérent.e sur zamok -On commence par créer le dossier "racine" de nos notebooks, normalement jupyter ne pourra pas accéder aux fichiers en dehors de ce dossier. -``` + +On commence par créer le dossier "racine" de nos notebooks, normalement +jupyter ne pourra pas accéder aux fichiers en dehors de ce dossier. + +```bash mkdir jupyter cd jupyter ``` -On va ensuite créer en environement virtuel python dans lequel il faut installer le package `notebook` ainsi que tous les packages nécessaires à l'exécution de notre code (par exemple `pandas`, `numpy` ou `matplotlib`). -``` + +On va ensuite créer en environement virtuel python dans lequel il faut +installer le package `notebook` ainsi que tous les packages nécessaires à +l'exécution de notre code (par exemple `pandas`, `numpy` ou `matplotlib`). + +```bash python3 -m venv env source env/bin/activate pip install notebook ``` -On peut ensuite lancer le serveur jupyter notebook avec: `jupyter notebook`._ + +On peut ensuite lancer le serveur jupyter notebook avec: `jupyter notebook`. Quelques lignes de logs devraient apparaitre dont: -``` + +```txt To access the server, open this file in a browser: file:///home/paulon/.local/share/jupyter/runtime/jpserver-3662553-open.html Or copy and paste one of these URLs: http://localhost:8888/tree?token=67c9b4d3cdf0fc24dc27d9cd8d3ffa1cc52a2bf7112dd7a5 http://127.0.0.1:8888/tree?token=67c9b4d3cdf0fc24dc27d9cd8d3ffa1cc52a2bf7112dd7a5 ``` -On peut donc maintenant faire du port forwarding avec ssh pour accéder depuis sa machine au port utilisé par jupyter sur zamok: -``` + +On peut donc maintenant faire du port forwarding avec ssh pour accéder depuis +sa machine au port utilisé par jupyter sur zamok : + +```bash ssh -L :localhost: zamok.crans.org ``` -On va partir du principe qu'on utilise le même port dans les deux cas, ici `8888` en faisant donc `ssh -L 8888:localhost:8888 zamok.crans.org`.\ -On peut alors juste copier coller l'adresse dans notre navigateur: et voilà! + +On va partir du principe qu'on utilise le même port dans les deux cas, ici +`8888` en faisant donc `ssh -L 8888:localhost:8888 zamok.crans.org`. + +On peut alors juste copier coller l'adresse dans notre navigateur : + +et voilà! diff --git a/services/linx.md b/services/linx.md index d1bd9c2..ae5e35a 100644 --- a/services/linx.md +++ b/services/linx.md @@ -1,21 +1,24 @@ # Linx + Linx est un logiciel d'hébèrgement temporaire et de partages de fichiers. ## Installation -Pour installer le logiciel, on commence par installer go sur le serveur, `apt -install golang`. Puis on télécharge l'une des -[https://github.com/andreimarcu/linx-server/releases](releases) du logiciel. -On peut enfin installer le logiciel en faisant `go install` sur la le fichier + +Pour installer le logiciel, on commence par installer go sur le serveur, +`apt install golang`. Puis on télécharge l'une des +[https://github.com/andreimarcu/linx-server/releases](releases) du logiciel. +On peut enfin installer le logiciel en faisant `go install` sur la le fichier téléchargé. ## Configuration -La configuration du logiciel est relativement peut et il est laissé à -l'utilisateur le choix de où il souhaite la placer. On propose ici de la mettre -dans `/etc/linx/server.conf`. Dans le fichier, on va préciser, l'adresse du -serveur, le port et l'ip à laquelle il va s'attacher, la taille maximale des + +La configuration du logiciel est relativement peut et il est laissé à +l'utilisateur le choix de où il souhaite la placer. On propose ici de la +mettre dans `/etc/linx/server.conf`. Dans le fichier, on va préciser, l'adresse +du serveur, le port et l'ip à laquelle il va s'attacher, la taille maximale des fichiers, leur temps de rétention et leur emplacements sur le disque. -``` +```txt bind = 172.16.10.119:8080 sitename = CRANS Linx siteurl = https://linx.crans.org/ @@ -25,15 +28,16 @@ filespath = /var/lib/linx/files/ metapath = /var/lib/linx/meta/ ``` -Pour vérifier que cela fonctionne, on peut maintenant lancé le logiciel en +Pour vérifier que cela fonctionne, on peut maintenant lancé le logiciel en faisant `linx-server -config /etc/systemd/system/linx-server.conf`. ## Service systemd -Pour que le logiciel puisse se lancer automatiquement au démarrage du serveur, -on va placer un fichier d'unit systemd dans + +Pour que le logiciel puisse se lancer automatiquement au démarrage du serveur, +on va placer un fichier d'unit systemd dans `/etc/systemd/system/linx-server.service`. -``` +```txt [Unit] Description=Linx After=network.target diff --git a/critical/mail/autoconfig.md b/services/mail/autoconfig.md similarity index 54% rename from critical/mail/autoconfig.md rename to services/mail/autoconfig.md index 48d6938..9b81c71 100644 --- a/critical/mail/autoconfig.md +++ b/services/mail/autoconfig.md @@ -3,9 +3,9 @@ Dans le protocole mail, la configuration du client mail est généralement laissé à la charge du client. C'est à lui de savoir à quels serveurs il souhaite se connecter, sur quels ports et en précisant le mécanisme ainsi que les -informations d'authentification. Cependant ces informations n'étant pas toujours -facilement accessible à l'utilisateur, thunderbird a mis en place une manière -externe par laquelle le client peut récupérer toutes les informations +informations d'authentification. Cependant ces informations n'étant pas +toujours facilement accessible à l'utilisateur, thunderbird a mis en place une +manière externe par laquelle le client peut récupérer toutes les informations nécessaires à sa configuration de tels sortes que l'utilisateur n'ait qu'à fournir son adresse mail et son mot de passe. @@ -14,17 +14,21 @@ fournir son adresse mail et son mot de passe. Attention, ce mécanisme de création de compte n'est pour le moment normalisé dans aucune RFC, c'est le client mail qui choisit sa propre implementation du mécanisme. Il est donc complètement possible que - 1. le client n'implémente pas du tout le mécanisme ou qu'il n'en implémente - qu'une partie - 2. deux clients différents n'aient pas la même implémentation du mécanisme + +1. le client n'implémente pas du tout le mécanisme ou qu'il n'en implémente + qu'une partie + +1. deux clients différents n'aient pas la même implémentation du mécanisme Quand on lui fournit une adresse mail de la forme `utilisateur@domain.tld`, le client va essayer de récupérer le contenu de l'uri suivante -`http://autoconfig.domain.tld/mail/config-v1.1.xml` qui est un fichier xml assez -simple qui décrit en quelques lignes une configuration que le client peut -adopter. Une référence complète de sa syntaxe est trouvable à l'adresse suivante : -`https://wiki.mozilla.org/Thunderbird:Autoconfiguration:ConfigFileFormat`. Voilà -une configuration minimale dans le cas du crans : +`http://autoconfig.domain.tld/mail/config-v1.1.xml` qui est un fichier xml +assez simple qui décrit en quelques lignes une configuration que le client +peut adopter. Une référence complète de sa syntaxe est trouvable à +l'adresse suivante : +. +Voilà une configuration minimale dans le cas du crans : + ```xml @@ -50,17 +54,19 @@ une configuration minimale dans le cas du crans : ``` Le fichier de configuration se lit assez bien, on dit à l'utilisateur de faire - - du smtp pour envoyer des mails en se connectant avec une connexion chiffrée - à `redisdead.crans.org` sur le port `465` et en utilisant la partie locale - de son adresse mail (le `user` dans `user@domain.tld`) comme nom - d'utilisateur et en utilisant le mode d'authentification ~~plain~~ LOGIN - (voir la suite) - - du imap pour recevoir les mails en se connectant avec une connexion STARTTLS - à `owl.crans.org` sur le port `993` et en utilisant la partie locale de son - adresse mail comme nom d'utilisateur et en utilisant le mode - d'authentification ~~plain~~ LOGIN -La plupart des clients mails interprète l'utilisation du mot clé `plain` comme -étant le méchanisme `login` du protocole SASL et non le méchanisme `plain` de ce -même protocole. Au crans, les deux méthodes d'authentification étant supporté, -cela ne pose pas de soucis. +* du smtp pour envoyer des mails en se connectant avec une connexion chiffrée + à `redisdead.crans.org` sur le port `465` et en utilisant la partie locale + de son adresse mail (le `user` dans `user@domain.tld`) comme nom + d'utilisateur et en utilisant le mode d'authentification ~~plain~~ LOGIN + (voir la suite) + +* du imap pour recevoir les mails en se connectant avec une connexion STARTTLS + à `owl.crans.org` sur le port `993` et en utilisant la partie locale de son + adresse mail comme nom d'utilisateur et en utilisant le mode + d'authentification ~~plain~~ LOGIN + +La plupart des clients mails interprète l'utilisation du mot clé `plain` +comme étant le méchanisme `login` du protocole SASL et non le méchanisme +`plain` de ce même protocole. Au crans, les deux méthodes d'authentification +étant supporté, cela ne pose pas de soucis. diff --git a/critical/mail/dovecot.md b/services/mail/dovecot.md similarity index 77% rename from critical/mail/dovecot.md rename to services/mail/dovecot.md index 9b41e1e..64a12f8 100644 --- a/critical/mail/dovecot.md +++ b/services/mail/dovecot.md @@ -1,65 +1,73 @@ # Dovecot -Dovecot est entre autre une implémentation de serveur IMAP, de serveur POP3 et -de serveur d'authentification SASL. Les deux premiers protocoles permettent à un -utilisateur de consulter ces mails (soit en les consultant sur le serveur pour -IMAP, soit en les téléchargeant localement pour POP3) tandis que le dernier sert -à authentifié l'utilisateur, authentification qui pourra être utilisé par -d'autre logiciels comme par exemple postfix pour vérifier l'idendité d'une -personne souhaitant envoyer un mail. + +Dovecot est entre autre une implémentation de serveur IMAP, de serveur POP3 et +de serveur d'authentification SASL. Les deux premiers protocoles permettent à +un utilisateur de consulter ces mails (soit en les consultant sur le serveur +pour IMAP, soit en les téléchargeant localement pour POP3) tandis que le +dernier sert à authentifié l'utilisateur, authentification qui pourra être +utilisé par d'autre logiciels comme par exemple postfix pour vérifier +l'idendité d'une personne souhaitant envoyer un mail. ## Installation -On tire les différents composants logiciels des repository debian : `sudo apt -install dovecot-imapd dovecot-ldap dovecot-pop3d dovecot-sieve` + +On tire les différents composants logiciels des repository debian : +`sudo apt install dovecot-imapd dovecot-ldap dovecot-pop3d dovecot-sieve`. ## Configuration -La configuration initiale packagée par debian est morcellée en une série de -fichier commentée dans `/etc/dovecot/conf.d` qui permette de segmenter la + +La configuration initiale packagée par debian est morcellée en une série de +fichier commentée dans `/etc/dovecot/conf.d` qui permette de segmenter la configuration en fonction des différents mécanismes du logiciel. ### 10-auth.conf -Ce fichier contrôle l'authentification des utilisateurs au serveur. On configure -dans le fichier directement les options de connexions puis en incluant des -fichiers 'auth-{{ mecanisme }}.conf.ext' on précise les différents bas -d'utilisateurs et de mot de passe à utiliser. -``` -# On autorise les clients à utiliser une authentification en claire car on -# configurera par la suite le fait que tous les échanges entre le client + +Ce fichier contrôle l'authentification des utilisateurs au serveur. On +configure dans le fichier directement les options de connexions puis en +incluant des fichiers `auth-{{ mecanisme }}.conf.ext` on précise les +différents bas d'utilisateurs et de mot de passe à utiliser. + +```txt +# On autorise les clients à utiliser une authentification en claire car on +# configurera par la suite le fait que tous les échanges entre le client # et le serveur soient chiffrées par TLS. disable_plaintext_auth = no # On configure deux méthodes d'authentification pour le client plain et login. auth_mechanisms = plain login -# On souhaite tirer les utilisateurs du ldap. On inclue donc le fichier de +# On souhaite tirer les utilisateurs du ldap. On inclue donc le fichier de # backend ldap qui va définir les bases d'utilisateurs et de mot de passes. !include auth-ldap.conf.ext ``` -Le fichier `auth-ldap.conf.ext` va lui même inclure le fichier de configuration +Le fichier `auth-ldap.conf.ext` va lui même inclure le fichier de configuration de connexion au ldap. -``` + +```txt # Addresse du serveur ldap uris = ldap://172.16.10.157/ -# Nom d'utilisateur et mot de passe utilisés pour s'authentifer auprès du +# Nom d'utilisateur et mot de passe utilisés pour s'authentifer auprès du # serveurs dn = cn=Utilisateurs,dc=crans,dc=org dnpass = "erdnaxe_aime_debian" # Base de noms en dessous de laquelle se trouve les utilisateurs dans le ldap base = cn=Utilisateurs,dc=crans,dc=org -# Les options de configurations user_filter et pass_filter permettent de filtrer +# Les options de configurations user_filter et pass_filter permettent de filtrer # les ojets ldap à inclure dans les bases d'utilisateurs et de mot de passes. user_filter = (&(objectClass=posixAccount)(uid=%u)) pass_filter = (&(objectClass=posixAccount)(uid=%u)) -# Les options de configurations user_attrs et pass_attrs permettent de savoir -# quels champs récupérer de l'objet ldap et d'altérer certains pour qu'ils +# Les options de configurations user_attrs et pass_attrs permettent de savoir +# quels champs récupérer de l'objet ldap et d'altérer certains pour qu'ils # correspondent mieux à l'installation de la machine. user_attrs = homeDirectory=home={{ dovecot.home_path }}/%u,uidNumber=uid,gidNumber=gid pass_attrs = uid=user,userPassword=password ``` ### 10-logging.conf -C'est le fichier de configuration qui gère l'écriture des logs du daemon. Il -permet de séléctionner quels événèments doivent être loggé et quels champs de + +C'est le fichier de configuration qui gère l'écriture des logs du daemon. Il +permet de séléctionner quels événèments doivent être loggé et quels champs de l'objet doivent être inclus dans les logs. -``` + +```txt plugin { mail_log_events = delete undelete expunge copy mailbox_delete mailbox_renam mail_log_fields = uid box msgid size @@ -68,9 +76,11 @@ log_timestamp = "%Y-%m-%d %H:%M:%S " ``` ### 10-mail.conf -Dans ce fichier de configuration on définit les boites mails avec lesquels -deovecot va travailler. -``` + +Dans ce fichier de configuration on définit les boites mails avec lesquels +dovecot va travailler. + +```txt # Emplacement des boites mails et des indexes de dovecot mail_location = maildir:~/Mail:INBOX=/var/mail/%u/:INDEX=/var/dovecot-indexes/%u # Structure initiale à donner à une boite mail @@ -79,29 +89,33 @@ namespace inbox { } # Nom du groupe gérant les boites mails mail_privileged_group = mail -# Listes de plugins génériques à charger. On inclue mail_plugins pour ajouter -# des plugins dans la liste et pas écraser le contenu actuel de la variable. Le -# plugin notify est une dépendance du plugin mail_log qui a été configuré dans +# Listes de plugins génériques à charger. On inclue mail_plugins pour ajouter +# des plugins dans la liste et pas écraser le contenu actuel de la variable. Le +# plugin notify est une dépendance du plugin mail_log qui a été configuré dans # le fichier 10-logging.conf mail_plugins = $mail_plugins mail_log notify # Limite le nombre de connections qu'un utilisateur peut réaliser au serveur mail_max_userip_connections = 15 ``` -TODO: documenter ce que font mail_log et notify; documenter la dernière ligne de -la conf + +TODO: documenter ce que font mail_log et notify; documenter la dernière ligne +de la conf. ### 10-master.conf -C'est le fichier de configuration principal de dovecot. C'est ici qu'on va -définir les différents services que proposeront notre installation. Au crans il -s'agit d'un serveur IMAP(s), d'un serveur POP3(s) et d'un serveur SASL. + +C'est le fichier de configuration principal de dovecot. C'est ici qu'on va +définir les différents services que proposeront notre installation. Au crans +il s'agit d'un serveur IMAP(s), d'un serveur POP3(s) et d'un serveur SASL. #### IMAP -La configuration du service se décompose en deux partie : le service -de connexion et d'authentification au daemon imap et la configuration imap. -``` + +La configuration du service se décompose en deux partie : le service de +connexion et d'authentification au daemon imap et la configuration imap. + +```txt service imap-login { -# Notre service écoute en clair sur le port 143 seulement sur le réseaux -# d'administration (pour les webmails) et il écoute en chiffré sur le 993 pour +# Notre service écoute en clair sur le port 143 seulement sur le réseaux +# d'administration (pour les webmails) et il écoute en chiffré sur le 993 pour # le reste du monde. inet_listener imap { address = 127.0.0.1, [::1], 172.16.10.126, [fd00::10:0:ff:fe01:2610] @@ -122,8 +136,10 @@ service imap { ``` #### POP3 + Le service pop3 se configure de manière analogue. -``` + +```txt service pop3-login { inet_listener pop3 { address = 127.0.0.1, [::1], 172.16.10.126, [fd00::10:0:ff:fe01:2610] @@ -143,10 +159,13 @@ service pop3 { ``` #### SASL -Pour le service d'authentification SASL, on souhaite qu'il ne soit accessible -qu'en local et en clair. On ne définit donc qu'un seul bloc d'écoute en local -sur le port `4242` (il n'y a pas de port réservé par l'IANA pour le protocole). -``` + +Pour le service d'authentification SASL, on souhaite qu'il ne soit accessible +qu'en local et en clair. On ne définit donc qu'un seul bloc d'écoute en local +sur le port `4242` (il n'y a pas de port réservé par l'IANA pour le +protocole). + +```txt service auth { client_limit = 1024 inet_listener { @@ -157,9 +176,11 @@ service auth { ``` ### 10-ssl.conf -Dans ce fichier on se contente de dire à dovecot où trouver nos certificats pour -les connextions chiffrées : -``` + +Dans ce fichier on se contente de dire à dovecot où trouver nos certificats +pour les connextions chiffrées : + +```txt ssl_cert = ` si vous souhaitez utiliser la commande `nft`, ou avec le morceau de configuration suivant : -``` +```txt table { [contenu de la table (chaînes)] } ``` - - ## Chaîne Une chaîne est caractérisée par : @@ -139,7 +133,6 @@ Une chaîne est caractérisée par : * Le nom de la chaîne - Lors de la création / utilisation d'une chaîne, il faut aussi décider ! * Le crochet NFTables concerné par la chaîne (input, output, ...) @@ -148,30 +141,27 @@ Lors de la création / utilisation d'une chaîne, il faut aussi décider ! * La priorité de la chaîne (filter (=0), srcnat (=-100), dstnat (=100)). - Une chaîne peut aussi avoir un verdict par défaut sur les paquet (accept, drop, reject [with MSG], ...). +Une chaîne peut être créée par la commande -Une chaîne peut être créée par la commande `nft add chain - '{ type hook priority -; [policy ;] }'`, ou par le morceau de -configuration textuelle suivant : - +```txt +nft add chain '{ type hook priority ; [policy ;] }' ``` + +ou par le morceau de configuration textuelle suivant : + +```txt chain { type hook priority ; policy ; [contenu de la chaîne] } ``` - ## Règle -Une règle est caractérisée par : - -* La chaîne dans laquelle elle est contenue. - +Une règle est caractérisée par la chaîne dans laquelle elle est contenue. Dans la définition d'une règle, il est possible d'indiquer : @@ -189,12 +179,13 @@ Dans la définition d'une règle, il est possible d'indiquer : * des actions, parmi lesquelles "compter les paquets" (`counter`), logger les paquets (`log prefix ...`). +Pour ajouter une règle, il est possible d'utiliser +```txt +nft add rule ''` +``` -Pour ajouter une règle, il est possible d'utiliser `nft add rule ''`, ou d'ajouter la règle -sur une ligne dans la configuration textuelle. - +ou d'ajouter la règle sur une ligne dans la configuration textuelle. ## Ensembles et applications @@ -207,48 +198,47 @@ sous-jacents luiel(de crapaud)-même. Un ensemble peut être : - * anonyme (eg: `{ A, B, C}`). Dans ce cas, l'ensemble est statique. +* anonyme (eg: `{A, B, C}`). Dans ce cas, l'ensemble est statique. - * nommé. Dans ce cas, l'ensemble peut être dynamique et avoir diverses options - et paramètres associés (eg: permettre de stocker des intervalles, associer - une durée de vie aux éléments (avec éventuellement un délai par défaut), - compter des paquets, une taille). +* nommé. Dans ce cas, l'ensemble peut être dynamique et avoir diverses options + et paramètres associés (eg: permettre de stocker des intervalles, associer + une durée de vie aux éléments (avec éventuellement un délai par défaut), + compter des paquets, une taille). - L'appartenance à un ensemble `E` est un critère valide noté `{...} @E` (sa - négation est notée `{...} != @E`). - L'ajout ou retrait d'un élément à un ensemble `E` est une action valide (si - l'ensemble n'est pas constant) et se note `(add|delete) @E {...}`. + L'appartenance à un ensemble `E` est un critère valide noté `{...} @E` (sa + négation est notée `{...} != @E`). + L'ajout ou retrait d'un élément à un ensemble `E` est une action valide (si + l'ensemble n'est pas constant) et se note `(add|delete) @E {...}`. - Dans un fichier de configuration, un ensemble est déclaré (dans une table) - par : - ``` - set { - type ; - } - ``` - Le type des éléments peut être donné explicitement ou à l'aide de `typeof - ...`, ou `...` est un critère valide (eg: `typeof tcp dport` est équivalent à - `type inet_service`). - Il est également possible de réaliser des produits cartésiens de types. Par - exemple, le type `ipv4_addr . inet_service` est le type des pairs d'adresse - IPv4 et des ports. + Dans un fichier de configuration, un ensemble est déclaré (dans une table) + par : - Il y a de nombreuses options utiles lors de la déclaration d'un ensemble : - - - Le nombre d'éléments max (`size `). La valeur par défaut est 65536. + ```txt + set { + type ; + } + ``` - - Les drapeaux (`flags ...`), dont `timeout` ou `intervals` + Le type des éléments peut être donné explicitement ou à l'aide de + `typeof ...`, ou `...` est un critère valide (eg: + `typeof tcp dport` est équivalent à `type inet_service`). - - Les éléments initiaux (`elements = { e0, ..., en }`) + Il est également possible de réaliser des produits cartésiens de types. Par + exemple, le type `ipv4_addr . inet_service` est le type des pairs d'adresse + IPv4 et des ports. + Il y a de nombreuses options utiles lors de la déclaration d'un ensemble : + * Le nombre d'éléments max (`size `). La valeur par défaut est 65536. + * Les drapeaux (`flags ...`), dont `timeout` ou `intervals` + + * Les éléments initiaux (`elements = { e0, ..., en }`) ### Applications TODO: `nft (add|...) map ...` - ## Interaction avec le pare-feu Il est souvent pratique d'ajuster les règles d'un pare-feu (ajout d'un service, @@ -256,11 +246,11 @@ de règles, réordonnancement des règles, ...). Un moyen naïf pour faire cela de réinitialiser le pare-feu et de charger un nouveau fichier de configuration. L'inconvénient est que cela : - * vide les ensembles et applications remplis dynamiquement +* vide les ensembles et applications remplis dynamiquement - * permet à des intrus d'établir des connections illicites si elles sont - initialisées durant la remise à zéro (moins important car la recharge d'un - fichier de configuration est rapide). +* permet à des intrus d'établir des connections illicites si elles sont + initialisées durant la remise à zéro (moins important car la recharge d'un + fichier de configuration est rapide). ### La commande `nft` @@ -268,50 +258,49 @@ La commande `nft` permet certes d'ajouter des tables, des chaînes et des règle dynamiquement, comme expliqué ci-dessus. Mais elle permet également de corriger des erreurs, ce qui peut être pratique par moments. - * Suppression ou remplacement d'une règle par une autre : +* Suppression ou remplacement d'une règle par une autre : - - Pour la suppression : `nft delete rule handle ` + * Pour la suppression : - - Pour le remplacement : `nft replace rule handle `. + ```bash + nft delete rule handle + ``` - __Cas d'usage :__ - - - si vous utilisez un ensemble anonyme pour gérer quels ports - sont ouverts aux nouvelles connections TCP, vous pouvez le mettre à jour - facilement. + * Pour le remplacement : - - si vous voulez qu'une règle filtrant les accès TCP permette aussi l'UDP, - vous pouvez par exemple souhaiter remplacer `tcp dport` par `meta l4proto - { tcp, udp} td dport` + ```bash + nft replace rule handle + ``` - * Ajout d'une règle à un endroit précis dans le pare-feu : - Cela peut être fait avec les règles - `nft rule handle - `. + __Cas d'usage :__ - `add` permet d'insérer la règle après la poignée spécifiée. Si aucune poignée + * si vous utilisez un ensemble anonyme pour gérer quels ports + sont ouverts aux nouvelles connections TCP, vous pouvez le mettre à jour + facilement. + + * si vous voulez qu'une règle filtrant les accès TCP permette aussi l'UDP, + vous pouvez par exemple souhaiter remplacer `tcp dport` par + `meta l4proto { tcp, udp} td dport` + +* Ajout d'une règle à un endroit précis dans le pare-feu : + Cela peut être fait avec les règles + `nft rule handle `. + + `add` permet d'insérer la règle après la poignée spécifiée. Si aucune poignée n'est spécifiée, la règle est ajoutée à la fin de la chaîne. - `insert` permet d'insérer la règle avant la poignée spécifiée. Si aucune - poignée n'est spécifiée, la règle est ajoutée au début de la chaîne. + `insert` permet d'insérer la règle avant la poignée spécifiée. Si aucune + poignée n'est spécifiée, la règle est ajoutée au début de la chaîne. - * Options pratiques (`nft -option_pratique ...`) : +* Options pratiques (`nft -option_pratique ...`) : - - `-t` permet de ne pas afficher le contenu des ensembles et applications + * `-t` permet de ne pas afficher le contenu des ensembles et applications dans la sortie de la commande qui suit - - - `-a` permet d'afficher les numéros de poignée - - - `-n` permet d'afficher les noms des services plutôt que les ports + * `-a` permet d'afficher les numéros de poignée + * `-n` permet d'afficher les noms des services plutôt que les ports (déconseillé car la fonction des ports dans les noms de service n'est pas injective) - - ## Journalisation et surveillance ### Journalisation @@ -322,32 +311,29 @@ est d'usage au Cr@ns de noter toutes les nouvelles connections. Cela peut être fait grâce à l'action `log prefix "..."`, ou `"..."` est le préfixe à utiliser dans le journal du système. - - ### Surveillance Il est possible de demander à NFTables d'afficher des messages de débogage, liés entre autre aux changements, retraits ou ajouts de règles, de tables, ... à l'aide de la commande `nft monitor` - * __Changements__ : +* __Changements__ - - Changements précis : `nft monotor ... + * Changements précis : `nft monotor ... `, où `...` peut être rien, `destroy` ou `add` selon si l'on veut tout entendre, n'entendre que les retraits ou les ajouts. - - - Changements quelconques : `nft monotor` pour tout entendre (y compris les + + * Changements quelconques : `nft monotor` pour tout entendre (y compris les parcours des paquets marqués décrits ci-dessous). - * __Débogage__ : - À des fins de débogage, il est parfois pratique de savoir par quelles règles - un paquet donné est passé et quelle verdict il a subit. À cette fin, NFTables - permet de marquer le paquet à l'aide de l'action `meta nftrace set 1`. - - Les événements internes de NFTables concernant ce paquet peuvent ensuite être - affichés avec la commande `nft monitor trace`. +* __Débogage__ + À des fins de débogage, il est parfois pratique de savoir par quelles règles + un paquet donné est passé et quelle verdict il a subit. À cette fin, NFTables + permet de marquer le paquet à l'aide de l'action `meta nftrace set 1`. + Les événements internes de NFTables concernant ce paquet peuvent ensuite être + affichés avec la commande `nft monitor trace`. ## Divers @@ -367,4 +353,3 @@ 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`. - diff --git a/services/networking/prefix_delegation.md b/services/networking/prefix_delegation.md new file mode 100644 index 0000000..ad6ae0b --- /dev/null +++ b/services/networking/prefix_delegation.md @@ -0,0 +1,31 @@ +# 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. + +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. + +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). + +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 +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 +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`. diff --git a/services/networking/radvd.md b/services/networking/radvd.md new file mode 100644 index 0000000..c723893 --- /dev/null +++ b/services/networking/radvd.md @@ -0,0 +1,91 @@ +# Radvd + +Radvd est une implementation du mécanisme d'autoconfiguration des adresses IP +en ipv6. Il permet au client de connaitre l'adresse du routeur et de se +construire lui même une adresse à partir du préfixe annoncé par le routeur +et de son adresse MAC. Des extensions du protocoles permettes aussi la +configuration des serveurs dns. + +## Principe + +### Adresse ipv6 et EUI-64 + +Il est possible pour un pair possédant une adresse MAC et un prefixe ipv6 de +taille au plus `/64` de construire une adresse ipv6. Cependant, rien n'assure +qu'elle soit unique à ce stade et il faudra par la suite le vérifier. Mais on +ne s'interesse ici qu'au processus de construction. + +De son adresse MAC (donnée à 48 bits), on dérive un identifiant de +l'interface sur le lien de 64 bits en insertant les 16 bits `FF:FE` au milieu +de l'adresse MAC puis on inverse le 7 ème bit. On peut ensuite suffixer cet +identifiant au préfixe dans lequel on chercher à construire notre addresse +ipv6. Ainsi `00:25:90:69:8c:74` devient `00:25:90:ff:fe:69:8c:74` puis +`02:25:90:ff:fe:69:8c:74` qui donne l'adresse `fd00::10:0225:90ff:fe69:8c74/64` +dans le prefixe `fd00:0:0:10::/64`. + +### Processus d'autoconfiguration complet + +Lorsqu'une machine configure une interface supportant l'ipv6 sur un lien, celle +ci va tenter de se crééer une premier adresse local au lien. Elle est donc +judicieusement appelé ip de lien locale. Pour cela, il va se contruire comme +expliquer précedemment une adresse dans le prefixe `fe80::/64`. Pour s'assurer +qu'elle est effectivement unique, il va envoyer au groupe ipv6 all-node +(`ff02::1`) qui comme son nom l'indique contient tous les nœuds si quelqu'un +utilise déjà l'adresse. Si c'est le cas, il ne poussera pas sa configuration +plus loin. Sinon après un délai sans réponse, il s'assignera l'adresse. + +Notre pair a donc maintenant une adresse sur le lien et il peut écouter les +annonces (judicieusement appelé routeur-advertissement ou RA) périodiques +qu'envoie le routeur au groupe all-node. S'il ne désire pas patienté jusqu'à +la prochaine annonce le client peut envoyer un routeur-sollicitation au groupe +all-routers. Dans ces annonces le routeur inclut entre autre le prefixe dans +lequel le client devrait prendre son adresse, son adresse de lien local ainsi +que des informations à propos des serveurs dns. Une fois ces informations +récupérées le client peut procéder aux dernières étape de configuration +de son interface réseaux en assignant l'adresse qu'il a construit à partir +du préfixe que lui a fourni le routeur (en vérifiant en amont son unicité +sur le lien) et en configurant la gateway à l'adresse de lien local du +routeur. + +## Installation + +On se contente de tirer le logiciel des repository debian +`sudo apt install radvd`. + +## Configuration + +La page de manuel détaillant les options de configurations de radvd est +consultable en utilisant `man 5 radvd.conf`. + +La configuration du logiciel se fait par bloc d'interface sur lesquel on va +publier nos RA. Dans un bloc on peut ensuite définir + +* des options génériques à propos de l'annonce comme par exemple l'intervalle + auquel notre routeur devrait publier des annonces ou le temps que la route + devrait être conservé par le client. +* les prefixes que le routeur va annoncer sur le lien et certaines options + associées +* les options de configurations du DNS + +Par exemple, le bloc suivant configure des annonces sur l'interface ens1 envoyé +toutes les 30 secondes avec comme préfixe `2a0c:700:12::/64`, `adh.crans.org` +comme liste de recherche pour les dns et `2a0c:700:12::ff:fe00:9912` comme +adresse du serveur dns. + +```txt +interface ens1 { + AdvSendAdvert on; + AdvDefaultPreference high; + MaxRtrAdvInterval 30; + + prefix 2a0c:700:12::/64 { + AdvRouterAddr on; + }; + + # La zone DNS + DNSSL adh.crans.org {}; + + # Les DNS récursifs + RDNSS 2a0c:700:12::ff:fe00:9912 {}; +}; +``` diff --git a/critical/networking/services/dhcp.md b/services/networking/services/dhcp.md similarity index 74% rename from critical/networking/services/dhcp.md rename to services/networking/services/dhcp.md index 4113062..fed15a6 100644 --- a/critical/networking/services/dhcp.md +++ b/services/networking/services/dhcp.md @@ -1,25 +1,29 @@ # 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 +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. ## Installation -Pour installer le logiciel, il faut cloner le répertoire git -`https://gitlab.crans.org/nounous/dhcp.git` . Actuellement la convention veut -que les services soient placé sous le chemin `/var/local/services/` mais rien ne -l'impose. Pour tourner le script a besoin du paquet `python3-jinja2`. Il faut -aussi crééer le dossier `generated` à la racine du dépot dans lequel seront + +Pour installer le logiciel, il faut cloner le répertoire git +. Actuellement la convention veut +que les services soient placé sous le chemin `/var/local/services/` mais rien ne +l'impose. Pour tourner le script a besoin du paquet `python3-jinja2`. Il faut +aussi crééer le dossier `generated` à la racine du dépot dans lequel seront stocker les fichiers de bails générer. ## Configuration + ### Re2o -Pour récupérer la liste des machines, le script a besoin de pouvoir parler à -l'API re2o. Pour ça on fournit au script les informations de connexions dans le + +Pour récupérer la liste des machines, le script a besoin de pouvoir parler à +l'API re2o. Pour ça on fournit au script les informations de connexions dans le fichier de configuration `re2o-config.ini` à la racine du dépot : -``` + +```txt [Re2o] hostname = 172.16.10.156 username = services @@ -27,14 +31,16 @@ password = ynerant_aime_le_php ``` ### dhcp.json -Dans le fichier de configuration `dhcp.json` aussi présent à la racine, on -réalise le reste de la configuration du logiciel. Une seule option est supporté -pour le moment : `extensions` qui permet de filtrer sur les extensions des + +Dans le fichier de configuration `dhcp.json` aussi présent à la racine, on +réalise le reste de la configuration du logiciel. Une seule option est supporté +pour le moment : `extensions` qui permet de filtrer sur les extensions des machines pour lesquels on souhaite exporter un fichier de bails : + ```json { - "extensions": [ - "adh.crans.org" - ] + "extensions": [ + "adh.crans.org" + ] } ``` diff --git a/services/networking/services/firewall.md b/services/networking/services/firewall.md new file mode 100644 index 0000000..70c1d42 --- /dev/null +++ b/services/networking/services/firewall.md @@ -0,0 +1,114 @@ +# Pare-feu + +Voir `/critical/networking/nftables.md` pour une documentation minimale sur +NFTables. + +Voici un pare-feu basique dans lequel des adhérants se trouvent derrière un +routeur : + +```txt +#!/usr/sbin/nft -f + +flush ruleset + +# +~~~~~~+ +# | IPV4 | +# +~~~~~~+ +define adh_prefix = 172.16.54.1 - 172.16.54.98 +define srv_prefix = 185.230.79.0/24 + +define nat_out = 185.230.79.37 + +# +~~~~~~+ +# | IPV6 | +# +~~~~~~+ +define adh_prefix6 = 2a0c:700:54::/64 + + +# définit les adresses utilisées par les adhérants +define adh4 = 100.66.0.0/16 ### Qu'est-ce que cette adresse ? + +# +~~~~~~~~~~~~~~+ +# | Filter table | +# +~~~~~~~~~~~~~~+ +table inet filter { + # Définiton des ports ouverts sur chaque machine + # (Utilise un mapping plutôt que des sets pour éviter uen complexité + # terrifiante en O(nm) et passer à O(n+m) \(\ddot\smile\)) + set authorized_in_forward_tcp4 { + type ipv4_addr . inet_service + flags interval + } + set authorized_in_forward_udp4 { + type ipv4_addr . inet_service + flags interval + } + set authorized_in_forward_tcp6 { + type ipv6_addr . inet_service + flags interval + } + set authorized_in_forward_udp6 { + type ipv6_addr . inet_service + flags interval + } + + chain input { + type filter hook input priority 0; policy drop; + + # Accept local traffic + meta iiftype loopback accept comment "allow from loopback" + + # Accepts existsing connections + ct state { related, established } accept + ct state invalid drop + + # Accept SSH and DHCP + meta l4proto { udp, tcp } th dport { ssh, 67 } ct state new accept + + # Accept ping + ip protocol icmp accept icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept + } + + chain forward { + type filter hook forward priority 0; policy drop; + + # Accept established and ping connnections + ct state { established, related } accept + ct state invalid drop + + # On log tout ce qui est neuf et qui passe + log prefix "FORWARD: " + ip protocol icmp accept icmpv6 type { nd-router-solicit, nd-router-advert, nd-neighbor-solicit, nd-router-advert, nd-neighbor-advert, echo-request, echo-reply } accept + + # Ouverture de ports pour les gens se trouvant derrière + ip daddr . tcp dport @authorized_in_forward_tcp4 accept + ip6 daddr . tcp dport @authorized_in_forward_udp4 accept + ip daddr . udp dport @authorized_in_forward_tcp6 accept + ip6 daddr . udp dport @authorized_in_forward_udp6 accept + + # Accepter toutes les connexions sortantes des clubs / adh et les logger + ip saddr $adh_prefix accept + ip6 saddr $adh_prefix6 accept + } +} + +# +~~~~~+ +# | NAT | +# +~~~~~+ +table inet loggonsTout { + chain prerouting { + type nat hook prerouting priority dstnat; + # On log ce qui est neuf + ct state new log prefix "LOGALL: " + } +} + +table ip nat { + chain postrouting { + type nat hook postrouting priority srcnat; + + # traffic des adhérants et des clubs ===> $nat_out (range) + ip saddr $adh_prefix snat to $nat_out persistent + } +} +``` diff --git a/services/re2o.md b/services/re2o.md index e9646d6..fcd49fa 100644 --- a/services/re2o.md +++ b/services/re2o.md @@ -1,6 +1,14 @@ # Re2o -Re2o est un système de gestion d'association réseau étudiante écrit en [Django](https://www.djangoproject.com/) un framework [Python](https://www.python.org/) permettant de développer facilement des sites webs interagissant avec une base de données ses sources sont disponibles 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). +Re2o est un système de gestion d'association réseau étudiante écrit en +[Django](https://www.djangoproject.com/) un framework +[Python](https://www.python.org/) permettant de développer facilement des +sites webs interagissant avec une base de données ses sources sont disponibles +sur le [GitLab FedeRez](https://gitlab.federez.net/re2o/re2o). -Il est déployé sur la VM `re2o` et est joignable en [HTTP](tools/http.md)(S) sur `intranet.crans.org`. +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). + +Il est déployé sur la VM `re2o` et est joignable en [HTTP](tools/http.md)(S) +sur `intranet.crans.org`. diff --git a/services/vsftpd.md b/services/vsftpd.md index bcfab01..0ebe62b 100644 --- a/services/vsftpd.md +++ b/services/vsftpd.md @@ -1,75 +1,88 @@ # VSFTPD -VSFTPD est une implémentation de serveur ftp connue pour être très sécurisée -(comme son nom, very secure FTP daemon, l'indique). Un serveur FTP est un -serveur d'échange de fichier un peu daté qui permet à des clients de récuperer -des fichiers d'un serveur, et de les y pousser. Aujourd'hui on lui préferait -l'utilisation de sftp qui utilise le protocole ssh comme support si le client a -besoin d'un accès en écriture au serveur ou simplement du protocole http/https -sinon. Cependant certaines technologies ainsi que des sysadmins vieillissant ne -savent pas faire autre chose que du ftp. C'est pour ça entre autre qu'on -continue de supporter le protocole à certains endroits dans l'infrastructure. + +VSFTPD est une implémentation de serveur ftp connue pour être très +sécurisée (comme son nom, very secure FTP daemon, l'indique). Un serveur FTP +est un serveur d'échange de fichier un peu daté qui permet à des clients de +récuperer des fichiers d'un serveur, et de les y pousser. Aujourd'hui on lui +préferait l'utilisation de sftp qui utilise le protocole ssh comme support si +le client a besoin d'un accès en écriture au serveur ou simplement du +protocole http/https sinon. Cependant certaines technologies ainsi que des +sysadmins vieillissant ne savent pas faire autre chose que du ftp. C'est pour +ça entre autre qu'on continue de supporter le protocole à certains endroits +dans l'infrastructure. ## Principe -Comme décrit plus tôt, le protocole FTP est un ancêtre de l'internet (la -première RFC qui le mentionne prédate l'utilisation de la stack TCP/IP). En -particulier il n'a initialement pas été prévu pour opérer à travers des parefeu -et des nats. C'est pourquoi aujourd'hui un serveur FTP peut fonctionner de deux -manières différentes : + +Comme décrit plus tôt, le protocole FTP est un ancêtre de l'internet (la +première RFC qui le mentionne prédate l'utilisation de la stack TCP/IP). En +particulier il n'a initialement pas été prévu pour opérer à travers des +pare-feu et des NAT. C'est pourquoi aujourd'hui un serveur FTP peut +fonctionner de deux manières différentes : ### FTP actif -Quand un client initie une connection avec un serveur FTP, il fournit au serveur -un numéro de port sur lequel le serveur pourra tenter de se connecter pour -procéder à l'échange de données. Cependant au moment où le client redirige le -serveur sur un autre port, rien ne permet d'affirmer que celui sera contactable -par le serveur (en fait de nos jours, si les deux machines ne sont pas sur le -même réseau local, il est quasiment certain que le serveur n'arrivera pas à -contacter le client). + +Quand un client initie une connection avec un serveur FTP, il fournit au +serveur un numéro de port sur lequel le serveur pourra tenter de se connecter +pour procéder à l'échange de données. Cependant au moment où le client +redirige le serveur sur un autre port, rien ne permet d'affirmer que celui +sera contactable par le serveur (en fait de nos jours, si les deux machines ne +sont pas sur le même réseau local, il est quasiment certain que le serveur +n'arrivera pas à contacter le client). ### FTP passif -Pour remedier à ça, le protocole ftp surporte maintenant un mode passif, où -c'est à la charge du serveur de rediriger l'utilisateur sur un port contactable -du serveur. + +Pour remedier à ça, le protocole ftp surporte maintenant un mode passif, où +c'est à la charge du serveur de rediriger l'utilisateur sur un port +contactable du serveur. ### Connexion au serveur -Pour se connecter à un serveur ftp un client peut le faire de manière anonyme -si le serveur lui permet. Mais il est possible de restreindre l'accès à une base -d'utilisateurs sécurisée par mot de passe. Cependant, le protocole ne prévoit -pas que le message soit chiffrée pendant le transfert. + +Pour se connecter à un serveur ftp un client peut le faire de manière anonyme +si le serveur lui permet. Mais il est possible de restreindre l'accès à une +base d'utilisateurs sécurisée par mot de passe. Cependant, le protocole ne +prévoit pas que le message soit chiffrée pendant le transfert. ### Support de TLS -Le support de TLS a été ajouté au protocole. Il est possible pour le client de -demander à l'initialisation de la connexion que celle-ci s'effectue de manière -chiffrée. Cela permet en particulier d'éviter de faire transiter des messages en -clair sur le réseau. + +Le support de TLS a été ajouté au protocole. Il est possible pour le client +de demander à l'initialisation de la connexion que celle-ci s'effectue de +manière chiffrée. Cela permet en particulier d'éviter de faire transiter des +messages en clair sur le réseau. ## Installation -On se contente de tirer le logiciels des dépots de logiciels de debian : `sudo -apt install vsftpd`. + +On se contente de tirer le logiciels des dépots de logiciels de debian : +`sudo apt install vsftpd`. ## Configuration -Munissez vous de votre `man 5 vsftpd.conf` préférée et d'un bon remontant parce -que mes ailleux c'est pas clair. + +Munissez vous de votre `man 5 vsftpd.conf` préférée et d'un bon remontant +parce que mes ailleux c'est pas clair. ### Configuration réseau -L'option `listen_ipv6=YES` permet de dire au daemon d'écouter **aussi** en ipv6. -Elle ne doit donc pas être utilisée avec l'option `listen=YES` qui ne ne -configurera qu'un socket ipv4. -Comme expliquer précedemment pour fonctionner de nos jours il est assez -fréquen qu'un serveur ftp doivent supporter le mode passif. -``` +L'option `listen_ipv6=YES` permet de dire au daemon d'écouter **aussi** en +ipv6. Elle ne doit donc pas être utilisée avec l'option `listen=YES` qui ne +ne configurera qu'un socket ipv4. + +Comme expliquer précedemment pour fonctionner de nos jours il est assez +fréquent qu'un serveur ftp doivent supporter le mode passif. + +```txt # Autorise le client à demander au serveur l'utilisation du mode passif pasv_enable=YES -# Configure la range de ports du serveurs vers l'un desquels le serveur pourra +# Configure la range de ports du serveurs vers l'un desquels le serveur pourra # rediriger le client pasv_min_port=45000 pasv_max_port=48000 ``` ### Configuration SSL -Il est possible de fournir à vsftpd un certificat et une clé privée pour qu'un -client puisse demander l'établissement d'une connexion chiffrée. -``` + +Il est possible de fournir à vsftpd un certificat et une clé privée pour +qu'un client puisse demander l'établissement d'une connexion chiffrée. + +```txt # Active le chiffrement ssl_enable=YES # Rensigne l'emplacement des certificats @@ -80,21 +93,25 @@ allow_anon_ssl=YES ``` ### Écriture des logs -On peut demander à vsftpd de logger les connexions, les téléchargements et les -téléversements au serveurs. -``` + +On peut demander à vsftpd de logger les connexions, les téléchargements et +les téléversements au serveurs. + +```txt xferlog_enable=YES ``` ### Configuration des utilisateurs -Ici la configuration des utilisateurs dépend principalement de ce que l'on -souhaite faire avec le serveur. Je couvrirais donc les deux cas d'utilisations -qu'on a au crans, le cas d'un mirroir de logiciel (donc accesible pour des -utilisateurs non privilégiés en lecture seule uniquement) et le cas d'un serveur -où une liste d'utilisateur peut venir déposer des fichiers. + +Ici la configuration des utilisateurs dépend principalement de ce que l'on +souhaite faire avec le serveur. Je couvrirais donc les deux cas d'utilisations +qu'on a au crans, le cas d'un mirroir de logiciel (donc accesible pour des +utilisateurs non privilégiés en lecture seule uniquement) et le cas d'un +serveur où une liste d'utilisateur peut venir déposer des fichiers. Pour notre premier cas d'utilisation, la configuration est triviale : -``` + +```txt # Autorise les utilisateurs anonymes à se connecter anonymous_enable=YES # Expose le dossier /pool/mirror/pub à ces utilisateurs en lecture seule @@ -102,10 +119,11 @@ anon_root=/pool/mirror/root ``` Pour le second, c'est un peu plus déclicat : -``` + +```txt # Autorise la connexion aux utilisateurs locaux (compte unix) local_enable=YES -# Restreint les utilisateurs qui peuvent se connecter à ceux présent dans +# Restreint les utilisateurs qui peuvent se connecter à ceux présent dans # /etc/vsftpd.user_list userlist_enable=YES userlist_deny=NO diff --git a/services/zamok.md b/services/zamok.md index 64a773b..35f46b9 100644 --- a/services/zamok.md +++ b/services/zamok.md @@ -4,9 +4,14 @@ ## Mais qui es-tu, zamok ? -De tout temps, l'homme a cherché à répondre à la question de sa genèse. Cette page n'aidera en aucun façon. Zamok, en Nouveau Criméen, ça veut dire château. Il paraît aussi que ça veut dire « Clef », mais j'ai pas trouvé dans quelle langue. +De tout temps, l'homme a cherché à répondre à la question de sa genèse. +Cette page n'aidera en aucun façon. Zamok, en Nouveau Criméen, ça veut dire +château. Il paraît aussi que ça veut dire « Clef », mais j'ai pas trouvé +dans quelle langue. -En tout cas, Zamok est la fidèle bécane (qui a changé cinq fois de boîte) qui permet aux adhérents geeks de se connecter à une machine tout le temps allumée pour discuter sur IRC et faire tourner à la sauvage ses algorithmes. +En tout cas, Zamok est la fidèle bécane (qui a changé cinq fois de boîte) +qui permet aux adhérents geeks de se connecter à une machine tout le temps +allumée pour discuter sur IRC et faire tourner à la sauvage ses algorithmes. Zamok héberge aussi les créations web des adhérents ou des clubs. @@ -14,12 +19,14 @@ Ah, et les mails sont triés dessus. ## Les services - * `ssh` permet d'obtenir un shell sur zamok, on peut alors avoir accès à différents services par ce biais (liste non exhaustive) : - * lecture de mails avec `mutt` - * utilisation de `latex` - * utilisation d'`emacs` et `gnus` - * conversion d'images avec `convert` - * différents shells Unix (dont `zsh`, `bash`, `tclsh`, `ksh`, `sh`) - * Un serveur web qui permet l'accès aux pages personnelles des adhérents. - * Un serveur MySQL pour les pages personnelles des adhérents - * C'est le serveur sur lequel les mails des comptes Cr@ns sont délivrés (procmail, spam assassin, etc) +* `ssh` permet d'obtenir un shell sur zamok, on peut alors avoir accès à + différents services par ce biais (liste non exhaustive) : + * lecture de mails avec `mutt` + * utilisation de `latex` + * utilisation d'`emacs` et `gnus` + * conversion d'images avec `convert` + * différents shells Unix (dont `zsh`, `bash`, `tclsh`, `ksh`, `sh`) +* Un serveur web qui permet l'accès aux pages personnelles des adhérents. +* Un serveur MySQL pour les pages personnelles des adhérents +* C'est le serveur sur lequel les mails des comptes Cr@ns sont délivrés + (procmail, spam assassin, etc) diff --git a/tools/dns.md b/tools/dns.md deleted file mode 100644 index 9a9b3ef..0000000 --- a/tools/dns.md +++ /dev/null @@ -1,104 +0,0 @@ -# DNS - -DNS (Domain Name System) est un protocole d'annuaire. Il utilises deux ports : - * Le port 53 en UDP pour la plupart des échanges. - * Le port 53 en TCP pour les échanges de grande taille (tels que du transfert de zone). - -DNS sert principalement à traduire les noms de domaines en adresse IP. - -C'est est un service hierarchisé dont le sommet est appelé la racine, et est représentée par un point (`.`). Chaque nom de domaine est découpé en plusieurs sous parties : - -Par exemple `zamok.crans.org` est un sous-domaine de `crans.org` lui-même sous-domaine de `org` qui est un sous-domaine de `.` (la racine). - -Il existe plusieurs types de serveurs DNS : - * Les serveurs Autoritaires, qui s'occupent de garder à jour le gros dictionnaire (ou annuaire) de la zone qu'ils gouvernent (par exemple `crans.org`, `crans.eu` ou `crans.fr`) - * Les serveurs Récursifs, qui s'occupent de faire des requêtes successives pour obtenir la valeur souhaitée, ils gardent très souvent en cache les informations récoltées, ce qui permet d'accélérer la réponse et d'éviter de surcharger les serveurs autoritaires. - -DNS permet d'associer des enregistrements (records) à des noms, ces enregistrements ont une classe et un type dont la liste est disponible [sur le site de l'IANA](https://www.iana.org/assignments/dns-parameters/dns-parameters.xhtml). - -La classe utilisée traditionnellement est la classe `IN` (pour internet), voici quelques types courants : - -| Type | Description | -|------|-------------| -| `A` | Adresse IPv4 | -| `AAAA` | Adresse IPv6 | -| `CNAME` | Alias vers un autre nom de domaine | -| `NS` | Nom d'un serveur DNS autoritaire | -| `MX` | Nom d'un serveur mail | - -Ainsi on a par exemple les enregistrements suivants dans la zone `crans.org`: -``` -zamok.crans.org. IN A 185.230.79.1 -perso.crans.org. IN CNAME hodaur.crans.org. -crans.org. IN NS silice.crans.org. -crans.org. IN MX 10 redisdead.crans.org. -``` - -Le 10 dans la valeur du champ MX est la priorité du serveur mail. - -## host - -Pour résoudre des noms de domaines la commande privilégiée est la commande `host` : -``` -benjamin@tiamat ~ $ host zamok.crans.org -zamok.crans.org has address 185.230.79.1 -zamok.crans.org has IPv6 address 2a0c:700:2:0:ec4:7aff:fe59:a1ad -``` - -``` -benjamin@tiamat ~ $ host crans.org -crans.org has address 185.230.79.10 -crans.org has IPv6 address 2a0c:700:2::ff:fe01:4502 -crans.org mail is handled by 10 redisdead.crans.org. -crans.org mail is handled by 15 sputnik.crans.org. -crans.org mail is handled by 25 freebox.crans.org. -``` - -## dig - -La commande `dig` permet d'effectuer des requêtes DNS plus complexes que `host`, la commande `dig -t TYPE @server name` est équivalente à la commande `host -vt TYPE name server`. `dig` peut prendre des options de requête plus qui modifient son comportement, en voici quelques exemples : - * `+short`: affiche uniquement la section de réponses de la requête et de manière compacte - * `+dnssec`: affiche également les résultats des requêtes pour les champs DNSSEC associés à la requête demandée - * `+rrcomments`: affiche des commentaires sur certains enregistrements - * `+https`: effectue une query DNS over HTTPS (DoH) - * `+trace`: fait les requêtes successives récursivement côté client afin de déterminer le résultat par exemple : `dig +trace @ns0.fdn.fr zamok.crans.org`: - ``` - . 47747 IN NS a.root-servers.net. - . 47747 IN NS b.root-servers.net. - . 47747 IN NS c.root-servers.net. - . 47747 IN NS d.root-servers.net. - . 47747 IN NS e.root-servers.net. - . 47747 IN NS f.root-servers.net. - . 47747 IN NS g.root-servers.net. - . 47747 IN NS h.root-servers.net. - . 47747 IN NS i.root-servers.net. - . 47747 IN NS j.root-servers.net. - . 47747 IN NS k.root-servers.net. - . 47747 IN NS l.root-servers.net. - . 47747 IN NS m.root-servers.net. - . 47747 IN RRSIG NS 8 0 518400 20220629170000 20220616160000 47671 . WGw6h2UFnKlJdCnApXM7dYkGuSpmRwokdwl0PzQMt0yUUG/Dumwpijn5 MEeOCxhoP29ni62JRMCGxgIirXVOHGfiMHDcx/dnv2gMnsr1OhQjPgwj hOu/NjZVkb612QW3b/i0mwDdjcEwRFQs9wzVZIBc4mPTFjocT2C2GlQc noLupUmliv38lfaPd+knrbhIUdwD8VEHDrzpDfdwR/kws+fWDjBcgUjA 77WzsA+FiwkqNvFIhQfMG+5CSXd0PpD3pPhdA6lCKa3l1AM4Cfnbtvj6 tuejEnNvbxsBaPOkiRz642/ysLV+fhXrP4U9BnWncUwe92NtFlZYRCHe a/D+yw== - ;; Received 525 bytes from 2001:910:800::12#53(ns0.fdn.fr) in 23 ms - - org. 172800 IN NS a0.org.afilias-nst.info. - org. 172800 IN NS a2.org.afilias-nst.info. - org. 172800 IN NS b0.org.afilias-nst.org. - org. 172800 IN NS b2.org.afilias-nst.org. - org. 172800 IN NS c0.org.afilias-nst.info. - org. 172800 IN NS d0.org.afilias-nst.org. - org. 86400 IN DS 26974 8 2 4FEDE294C53F438A158C41D39489CD78A86BEB0D8A0AEAFF14745C0D 16E1DE32 - org. 86400 IN RRSIG DS 8 1 86400 20220630050000 20220617040000 47671 . bKm4Ul/DPpqbqvF0gRS1Gzrmk9N0VU2Qa1dBIb/vbx6N+SEVK1wGpD20 BA6mdyFL2SOOuhEldC44N/cj401aLoli/9Bj71hdYl0XLcW/Hiq1xo2U 6Iqvfu4GwBGb36aLfce8DYEdnTtpbicXrFszx8dg2CAnFvCYLve6sA/r DOzs+K8LCsTi3cdOTuee3mEN1XC6SAfIrZDDtLEwZXiyxRAI7GbuM0i8 LCFHRa7YBlf8EOFNafkFsCi4qM4cHdnavVAxDH+gOeYnjVOd3yhezJb9 /hRBo3aIKGY1orjb+erQAOxhly26f8v2H/h0czKOXriNL7d4id8aa1fN qWiFeA== - ;; Received 781 bytes from 199.7.83.42#53(l.root-servers.net) in 27 ms - - crans.org. 3600 IN NS sputnik.crans.org. - crans.org. 3600 IN NS silice.crans.org. - crans.org. 3600 IN DS 40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2 - crans.org. 3600 IN RRSIG DS 8 2 3600 20220630152826 20220609142826 41346 org. EjZHR/kgXopDL/Rqw5wMWQn2AB2stt6eu0TtGHa2Gt1/LhOPraqNbXJq Ufg7VhcCRtY4DaZnp9wnBXzK9vdqUIIRMuNQoA6mEdj8qpjRajsjfPdT D87bU6h1OH5YghQAzi2N90LGgjlDqdB50xWIZHgMeLLH53nePcAcxpxE VA4= - ;; Received 358 bytes from 2001:500:e::1#53(a0.org.afilias-nst.info) in 243 ms - - zamok.crans.org. 3600 IN A 185.230.79.1 - zamok.crans.org. 3600 IN RRSIG A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5 - crans.org. 3600 IN NS silice.crans.org. - crans.org. 3600 IN NS sputnik.crans.org. - crans.org. 3600 IN RRSIG NS 14 2 3600 20220711101913 20220611094455 40871 crans.org. +BvWwsxxekrKHDFCXTL2d/pHP/2i75U6qah3Ee15SSDSQhjbnwCkI2+a Q6zGpnkwnSsB6HfRgoCbXp8r/rRzgAV7pGN06wPyejJRzkgRB+euSjbD tUmc8ODVxVWYH7iQ - ;; Received 1041 bytes from 2a0c:700:2::ff:fe01:4702#53(silice.crans.org) in 23 ms - ``` diff --git a/tools/dnssec.md b/tools/dnssec.md deleted file mode 100644 index de71c40..0000000 --- a/tools/dnssec.md +++ /dev/null @@ -1,59 +0,0 @@ -# DNSSEC - -DNSSEC (Domain Name System Security Extensions) est un ensemble d'extension de sécurité pour DNS. Il permet d'authentifier les données obtenues par le protocole DNS. - -Pour cela, chaque entrée du DNS est signée cryptographiquement avec une clef privée. La clef publique, elle-même publiée dans le DNS permet de vérifier les signatures. L'authenticité de la clef publique est assurée par la zone parente (via les enregistrements DS), dans laquelle elle est publiée. - -Ainsi, il suffit de faire confiance à la clef publique de la racine du DNS (et seulement de la racine) pour pouvoir établir une chaîne de confiance dans tous le DNS. - -Les enregistrements DNS associés au DNSSEC sont les suivants : - * `DNSKEY`: une clef publique servant à signer une zone - * `DS`: un hash de clef publique d'une zone fille (conceptuellement proche d'un GLUE record NS) - * `RRSIG`: une signature d'un enregistrement - * `NSEC`: un pointeur vers la prochaine entrée DNS signée (dans l'ordre alphabétique), celui sert à prouver l'absence d'un enregistrement - * `NSEC3`: une variante de `NSEC` où les entrées DNS sont hashées - * `NSEC3PARAM`: des informations servant à calculer les hash pour les enregistrements `NSEC3` - -## Exemples - -### DNSKEY - -On lance la commande `dig -t DNSKEY @silice.crans.org crans.org`: -``` -;; QUESTION SECTION: -;crans.org. IN DNSKEY - -;; ANSWER SECTION: -crans.org. 3600 IN DNSKEY 257 3 14 Db282t/1HUd5ccAnJ0BSaidrnseZEtG/8Cj9MbzYl/GbgGxA8msR/Dq8 KfIeobLwnZFF5277dhdzAAdfKAb/XclhHBqpDtaV+bvd21n8MLR3yhdI VsFAde/yOBFW28fV -crans.org. 3600 IN DNSKEY 256 3 14 4gBTKamW1QSNWNSWkR0qVswo+GcIV7cmKf6y4zuqlinDcvN0a5+ppqW2 almA4TF7vh7u9jH2/iwZVmHiikgpTiRzZJzga158/AlYTqE4pTK6zhin YlPz9w/PTSdOXMU6 -``` - -La zone `crans.org` possède deux clefs de signature : une KSK (Key Signing Key) et une ZSK (Zone Signing Key). - -### DS - -On lance la commande `dig -t DS @a0.org.afilias-nst.info crans.org`: -``` -;; QUESTION SECTION: -;crans.org. IN DS - -;; ANSWER SECTION: -crans.org. 3600 IN DS 40871 14 2 8E792BB11D64D2F109F4B80DE2E353266671E32BD897E39455701D77 77018EA2 -``` - -La zone `crans.org` a publié dans la zone `org` le hash d'une clef publique (la KSK). - -### RRSIG - -On lance la commande `dig -t RRSIG @silice.crans.org zamok.crans.org`: -``` -;; QUESTION SECTION: -;zamok.crans.org. IN RRSIG - -;; ANSWER SECTION: -zamok.crans.org. 3600 IN RRSIG A 14 3 3600 20220711091113 20220611082423 40871 crans.org. U5Ggkg82aIqPdO8HrJ9k793DQv0mykIKoh9PMRdNpwJSjrnOFmACdD4q YuPceZBpllJJHfhX5bsie8g/eYMPS39RZvoFUiMcw3SXdpJiE+/bOf89 5HZe3HkbveX/twx5 -zamok.crans.org. 3600 IN RRSIG AAAA 14 3 3600 20220711100552 20220611093221 40871 crans.org. 2XkmJYJbeKgXK0plIB/d1nnhQ6mXhubZu4k6jASlp9BumPy6WLRPUxR1 QhFV+gidKTVidsWL6faL28HH8j4pmxVGeIC50c5NOfaBa3nVTfeD+pUp MEhC0VwhBYnODuu9 -zamok.crans.org. 3600 IN RRSIG SSHFP 14 3 3600 20220711100552 20220611093221 40871 crans.org. nd/HiLy0qw3NMo2Lwn8P/J2h1UaXjGWAFYPCK5ISQWBILPE5iO+TdaXy uyOy4l4Dc9hdanzvKQFBuE9hG9gkr3KpmtCEFWtHlg6PAu7MIqXTzpbV 4kR2wjiuCLfmPq2W -``` - -`zamok.crans.org` possède trois enregistrements signés : ils sont de types `A`, `AAAA` et `SSHFP`. diff --git a/tools/gpg.md b/tools/gpg.md deleted file mode 100644 index bd9aa9a..0000000 --- a/tools/gpg.md +++ /dev/null @@ -1,25 +0,0 @@ -# GPG - -GPG (GNU Privacy Guard) est une implémentation libre et open source du protocole OpenPGP (Pretty Good Privacy), un protocole cryptographique permettant de signer, chiffrer et déchiffrer des documents (notamment des emails). - -# Clef - -Une clef GPG est une clé numérique qui permet d'être identifié de façon unique dans le monde numérique. - -Elle est composée de deux éléments : - * une clé privée protégée par une phrase clé qui permet d'éviter à une tierce personne d'utiliser cette clef si elle parvient à la voler - * une clé publique qui une fois distribuée et signée par son entourage, permet à celui-ci de vérifier que les messages que l'on signe le sont bien avec la clé privée associée à cette clé publique - -Elle peut être générée à l'aide d'une des commandes suivantes (selon le nombre d'option que vous souhaitez avoir) : - * `gpg --generate-key` - * `gpg --full-generate-key` - * `gpg --full-generate-key --expert` - -# Web of trust - -Le web of trust (ou toile de confiance en français) permet d'établir l'authenticité de l'appartenance d'une clef publique ; il est décentralisé : il n'a donc pas besoin d'autorité de certification. - -Voici les règles par défaut du web of trust d'OpenPGP, on estime que la clef publique appartient au bon propriétaire si : - * On a soi-même fait confiance à cette clef - * Une personne en qui on a totalement confiance a signé cette clef - * Trois personnes en qui on a partiellement confiance ont signé cette clef diff --git a/tools/http.md b/tools/http.md deleted file mode 100644 index 2e059ff..0000000 --- a/tools/http.md +++ /dev/null @@ -1,5 +0,0 @@ -# HTTP - -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. diff --git a/tools/ip.md b/tools/ip.md deleted file mode 100644 index b3beec4..0000000 --- a/tools/ip.md +++ /dev/null @@ -1,91 +0,0 @@ -# IP - -## Généralités - -IP (Internet Protocol) est le protocole principal de communication sur l'internet, actuellement deux versions sont en cours d'utilisation : IPv4 et IPv6. - -IP permet de transmettre des datagrammes d'un point à un autre. - -### Adressage - -Les adresses IP sont alloués avec la méthode du CIDR (Classless Inter-Domain Routing). Cette méthode consiste à noter une adresse au format `adresse/longueur_préfixe`, elle induit une attribution des IP par blocs. - -Les `n` bits (où `n` est la longueur du préfixe) les plus significatifs servent à identifier le réseau auquel l'adresse appartient. - -## IPv4 - -Une adresse IPv4 s'écrit sur 32 bits et utilise une notation décimale pointée (4 entiers séparés par des `.`), par exemple `192.168.0.1` est une adresse IPv4. - -De même `192.168.0.0/24` est un exemple de notation CIDR pour un sous-réseau IPv4. - -Dans un réseau local les adresses IPv4 peuvent être attribuées par le protocole DHCP ou configurées statiquement. - -À noter que dans un sous-réseau IPv4 la première et la dernière sont réservées respectivement pour identifier le réseau et effectuer du broadcast : 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 : -``` -iface eth0 inet static - broadcast - -``` - -Ceci permet d'utiliser des blocs d'adresses IPv4 d'une taille de préfixe égale à 31 afin d'interconnecter deux machines. - -### IPv4 privées - -Certains blocs d'adresses IPv4 sont réservés à des utilisations privées, celà signifie qu'ils ne sont pas annoncés sur l'internet. Ils sont spécifiés par la [RFC 1918](https://tools.ietf.org/html/rfc1918) et sont les suivants : - * `10.0.0.0/8` - * `172.16.0.0/12` - * `192.168.0.0/16` - -### IPv4 de lien local - -Un bloc d'IPv4 est réservé pour utilisation sur le réseau local, c'est à dire que ce bloc n'est normalement jamais routé, il s'agit du bloc `169.254.0.0/16`. - -### IPv4 multicast - -un bloc d'IPv4 est réservé pour du multicast, il s'agit du bloc `224.0.0.0/4`. - -## IPv6 - -Une adresse IPv6 s'écrit sur 128 bits et utilise une notation hexadécimale séparée par des `:` (deux-points), par exemple `2001:0db8:0000:0000:0000:0000:0000:0000` (on regroupe les octets par groupe de 2). - -Il existe également une notation compacte pour les adresses IPv6 : on peut omettre les 0 en début de bloc et remplacer la plus longue suite de blocs nuls par `::`, par exemple l'adresse précédente peut s'écrire `2001:db8::`. - -Ainsi `2001:db8::/32` est un exemple de notation CIDR pour un sous-réseau IPv6. - -Dans un réseau local les adresses IPv6 peuvent être attribuées par le protocole NDP, par le protocole DHCPv6 ou configurées statiquement. - -La liste des IPv6 attribuées est disponible [ici](https://www.iana.org/assignments/ipv6-address-space/ipv6-address-space.xhtml) et [là](https://www.iana.org/assignments/iana-ipv6-special-registry/iana-ipv6-special-registry.xhtml). - -Il n'y a pas de broadcast en IPv6 et la première adresse du bloc peut être utilisée sans risque. Le broadcast est remplacé par du multicast : tous les nœuds sur le réseau local répondent sur l'adresse `ff02::1`. - -### IPv6 uniques locales - -Un bloc d'adresses IPv6 est réservé pour des utilisations privées, c'est l'équivalent des blocs d'IPv4 privées. Il s'agit du bloc `fc00::/7` - -### IPv6 de lien local - -Un bloc d'IPv6 est réservé pour utilisation sur le réseau local, il s'agit du bloc `fe80::/10`. - -### IPv6 multicast - -Un bloc d'IPv6 est réservé pour du multicast, il s'agit du bloc `ff00::/8`. - -## ip - -Sous Linux la commande privilégiée pour consulter l'état de la configuration réseau est `ip` (fournie par la suite `iproute2`) voici quelques exemples de commandes : - -Afficher l'état des interfaces de la machine (adresses IP attribuées et leur sous-réseau) : -```bash -ip address -``` - -Afficher l'état des routes IPv4 de la machine : -```bash -ip route -``` - -Afficher l'état des routes IPv6 de la machine : -```bash -ip -6 route -``` diff --git a/tools/irc.md b/tools/irc.md deleted file mode 100644 index 96f5501..0000000 --- a/tools/irc.md +++ /dev/null @@ -1,19 +0,0 @@ -# IRC - -IRC (Internet Relay Chat) est un protocole de communication textuelle. C'est le protocole privilégié pour les discussions instantanées entre membres actifs. - -Sa version 2 est spécifiée par la [RFC 2812](https://tools.ietf.org/html/rfc2812), une [version 3](https://ircv3.net/) est en cours de développement. - -Il utilise 2 ports : - * Le port 6667 en TCP pour la communication en clair. - * Le port 6697 en TCP pour la communication chiffrée avec TLS. - -Il existe deux types d'entités dans le protocole IRC : les utilisateurs et les canaux. Un nom d'utilisateur (nick) commence obligatoirement par une lettre ou un des caractères spéciaux définis dans la RFC. Un nom de canal commence obligatoirement par un caractère `#`, `&`, `!` ou `+`, en pratique seul le `#` est implémenté de manière universelle. - -Le protocole IRC utilise des commandes, dans la plupart des clients il est possible d'envoyer une commande en entrant un `/` suivi de la commande dans le prompt du client. - -## Modes - -Il est possible d'attribuer des «flags» aux utilisateurs et aux canaux qui permettent de modifier leur comportement, ceux-ci s'appellent des modes, certains modes sont spécifiés dans la RFC mais la quasi-totalité des serveurs IRC implémentent d'autres modes pour ajouter des fonctionnalités au protocole. - -Ces modes sont manipulables avec la commande `MODE`, par exemple `MODE nick +w` pour ajouter le mode `w` à l'utilisateur `nick` ou `MODE #channel -t` pour retirer le mode `t` du canal `#channel`. diff --git a/tools/ldap.md b/tools/ldap.md deleted file mode 100644 index 4038c75..0000000 --- a/tools/ldap.md +++ /dev/null @@ -1,3 +0,0 @@ -# LDAP - -LDAP (Lightweight Directory Access Protocol) est un protocole d'accès à une base donnée arborescente (directory). Sa dernière version (version 3) est spécifiée dans la [RFC 4511](https://tools.ietf.org/html/rfc4511). diff --git a/tools/nfs.md b/tools/nfs.md deleted file mode 100644 index 94e3510..0000000 --- a/tools/nfs.md +++ /dev/null @@ -1,11 +0,0 @@ -# NFS - -NFS (Network File System) est un système de fichiers pouvant être monté à travers le réseau : le serveur NFS expose des parties de son arborescence qui peuvent être montées par les clients. - -NFS utilise le port 2049 en TCP et en UDP. - -Le système de fichier ZFS supporte nativement l'export NSF de tout ou partie de son arborescence, vous pouvez vous référer à la section *Partager un dataset en NFS* de la page ZFS pour savoir comment faire. - -## Version 4 - -La dernière version de NFS est la version 4.2 spécifiée par la [RFC 7862](https://tools.ietf.org/html/rfc7862). diff --git a/tools/ntp.md b/tools/ntp.md deleted file mode 100644 index 87c8dd3..0000000 --- a/tools/ntp.md +++ /dev/null @@ -1,5 +0,0 @@ -# NTP - -NTP (Network Time Protocol) est un protocole de synchronisation d'horloge, il utilise le port 123 en UDP. - -Sa version 4 est spécifiée par la [RFC 5905](https://tools.ietf.org/html/rfc5905). diff --git a/tools/smtp.md b/tools/smtp.md deleted file mode 100644 index 64d8ed4..0000000 --- a/tools/smtp.md +++ /dev/null @@ -1,6 +0,0 @@ -# SMTP - -SMTP (Simple Mail Transfer Protocol) est un protocol d'échange de courrier électronique. Il utilise 3 ports différents : - * Le port 25 en TCP (smtp) pour l'échange de mail entre serveurs. - * Le port 465 en TCP (submissions) pour la soumission de mail chiffrée par TLS. - * Le port 587 en TCP (submission) pour la soumission de mail en clair avec possibilité de chiffrement via la commande STARTTLS. diff --git a/tools/ssh.md b/tools/ssh.md deleted file mode 100644 index cbac24a..0000000 --- a/tools/ssh.md +++ /dev/null @@ -1,62 +0,0 @@ -# SSH - -SSH (Secure Shell) est un protocole permettant d'exécuter des commandes sur un serveur distant. Il utilise le port 22 en TCP. - -Sa version 2 est spécifiée par les RFC [4250](https://datatracker.ietf.org/doc/html/4250), [4251](https://datatracker.ietf.org/doc/html/4251), [4252](https://datatracker.ietf.org/doc/html/4252), [4253](https://datatracker.ietf.org/doc/html/4253) et [4254](https://datatracker.ietf.org/doc/html/4254). - -# OpenSSH - -Le client de prédilection pour utiliser SSH est le client de la suite OpenSSH (qui fourni également un serveur et d'autres utilitaires permettant de gérer les clefs cryptographiques), disponible dans le paquet Debian `openssh-client`. - -# Clefs SSH - -Vous pouvez générer des clefs cryptographiques permettant de vous authentifier directement sur le serveur distant (plutôt que par mot de passe) avec l'utilitaire `ssh-keygen` ainsi: - -``` -ssh-keygen -t ${TYPE} -b ${BITS} -``` - -Où `TYPE` peut être : - * `rsa` - * `ecdsa` (dans ce cas `BITS` doit valoir 256, 384 ou 521) - * `ed25519` (dans ce cas `BITS` doit valoir 256) - -`ssh-keygen` vous demande ensuite le chemin du fichier de clef ainsi que sa passphrase et génère une clef privée ainsi qu'une clef publique se terminant par `.pub`. - -Un autre utilitaire, `ssh-copy-id` permet de copier la clef sur le serveur distant par exemple : - -``` -ssh-copy-id -i ~/.ssh/id_ed25519.pub login@zamok.crans.org -``` - -Attention : il faut absolument garder la clef privée sur votre serveur et ne pas l'envoyer sur le serveur distant. - -# Exemples - -À la première connexion `ssh` demande s'il faut faire confiance à la clef du serveur : -``` -benjamin@om ~ $ ssh gitlab.crans.org -The authenticity of host 'gitlab.crans.org (185.230.79.14)' can't be established. -ECDSA key fingerprint is SHA256:StU+25vCTTs+opjyjMZTLvl+gvR+ViQWUkE1jRENnkQ. -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 (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 /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 par un mail d'un administrateur de confiance signé GPG. - * Utiliser des clefs stockées dans le [DNS](/tools/dns.md) et signées DNSSEC, ceci peut se faire en ajoutant l'option `-oVerifyHostKeyDNS=yes` à `ssh`. - -Une fois que vous vous êtes assuré de l'authenticité de la clef vous pouvez entrer `yes` dans le prompt ci-dessus. - -`ssh` vous demande ensuite votre mot de passe ou la passphrase de votre clef, entrez le et appuyez sur Entrée pour vous connecter, félicitations vous devriez avoir votre shell sur le serveur distant. - -# Exemple de conf ssh - -Après avoir `ssh-copy-id` sa clef public comme précisé plus haut on peut définir une conf qui permet d'aller sur nimporte quel serveur depuis votre machine via un `ProxyJump`. - -``` -Host *.adm.crans.org - User _usernounou - ProxyJump _usernounou@hodaur.crans.org -``` \ No newline at end of file diff --git a/tools/zfs.md b/tools/zfs.md deleted file mode 100644 index ef1e79a..0000000 --- a/tools/zfs.md +++ /dev/null @@ -1,144 +0,0 @@ -# ZFS - -## ZFS c'est quoi ? - -ZFS est un système de fichier avec plein de features natives, notamment de la gestion de volume, du RAID (RAID-Z), des snapshots, etc. - -> ZFS a été ouvert sous licence [CDDL](https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License) incompatible avec la GPL. Par conséquent, ZFS n'est pas supporté nativement par le noyau Linux. - -## Petit glossaire - - * RAID-Z#N: Le raid de ZFS. Le chiffre #N correspond au nombre de disques que l'on peut perdre (e.g. RAID-Z2 correspond à du RAID 6 classique). - * Pool: Une *pool* de stockage est le bloc de base de ZFS. C'est un ensemble logique de données. Une pool ZFS est composée d'un ou plusieurs *vdev*. - * Vdev: Un *vdev* (pour ''virtual device'') est un sous élément d'une pool. Un vdev peut contenir un ou plusieurs disques physiques. Dans le cas où plusieurs disques sont utilisés, les données sont étendues (*stripped*) sur tous les disques afin d'améliorer sa durée de vie. - * Dataset: *Dataset* est le terme générique pour désigner un volume de fichiers ZFS. Chaque dataset a un nom unique de la forme *Pool/Dataset*. La racine de la pool est techniquement un dataset aussi. Les dataset sont organisés comme des dossiers classique, avec une arborescence, et les enfants héritent des propriétés des parents. - -# Installation - -Il faut ajouter les dépots `contrib` de debian dans lesquels se trouvent les paquets installés ci-dessous. -Pour installer le module noyau ZFS sous Debian et les outils d'administration : -```bash -apt install linux-headers-amd64 -apt install zfs-dkms -``` -Il faut ensuite reboot pour loader le module zfs, puis : -```bash -apt install zfsutils-linux -``` -Cela installe aussi `zfs-zed` un daemon permettant de monitorer les pool ZFS. -Les headers du noyau doivent être installés à chaque mise à jour du noyau. - -## Créer une pool ZFS - -La première étape de création d'un filesystem ZFS est la création d'une pool. Une pool contient des vdev qui eux même contiennent des disques, la commande suivante permet de créer une pool de nom «pool» et montée dans `/pool` avec un vdev en RAIDZ-3 : -```bash -zpool create -f -m /pool pool raidz3 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03494499 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03563166 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03570970 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03575828 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03614378 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03626582 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03694920 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03704580 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03707506 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03731830 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734763 \ - ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734769 -``` -Les identifiants de disques peuvent être récupérés dans `/dev/disks/by-id/` - -L'état des pool peut-être consulté avec la commande -```bash -zpool status -``` - -## Créer un dataset - -Une fois la pool créée il est préférable de créer des datasets qui permettent une gestion plus fine de la pool. Pour cela on utilise la commande suivante qui créé un dataset du nom de «home» dans la pool «pool» : -```bash -zfs create pool/home -``` - -## Partager un dataset en NFS - -ZFS permet de partager un dataset en NFS pour cela il faut installer le paquet `nfs-kernel-server` : -```bash -apt install nfs-kernel-server -``` - -Le dataset «home» de la pool «pool» peut ensuite être partager ainsi : -```bash -zfs set sharenfs="no_root_squash,rw=@172.16.10.0/24" pool/home -``` -Cette commande partage le dataset au sous-réseau `172.16.10.0/24`, l'option `no_root_squash` permet au root du client NFS d'avoir tous les droits sur les fichiers du dataset. - -Il est également préférable d'activer les acl POSIX sur la pool, dans le cas contraire il peut y avoir des problèmes de permissions à la création de fichiers : -```bash -zfs set acltype=posixacl pool -``` - -## Détruire un dataset - -Pour détruire le dataset `pool/path` on utilise la commande -```bash -sudo zfs destroy pool/path -``` - -## Désactiver le sync - -Renvoyer une confirmation d'écriture sur le disque après chaque opération diminue énormément les performances du NFS. On peut dire à ZFS de mentir au NFS sur le retour des opérations sync(). Pour ça, on utilise la commande : -```bash -sudo zfs set sync=disabled pool/path -``` - -## Changer un disque - -Récupérer le guid du disque qu'on souhaite changer avec `zdb` (`zpool status` peut aider à récuperer le nom du disque concerné). Une fois que c'est fait on peut retirer le disque avec : ` zpool offline pool ${guid}` puis on remplace l'ancien disque par le nouveau : ` zpool replace pool ${guid} ${nouveau disque}`. Après ça, on peut monitorer la reconstruction avec `zpool status`. - -# Chiffrement - -ZFS permet de nativement chiffrer un dataset. Attention, il faut que ça soit fait à la **creation** du dataset. Ça ne peut pas se changer après. - -## Créer un dataset chiffré - -Pour créer un dataset chiffré il suffit de rajouter les options de chiffrement avec `encryption=on`. Il faut aussi spécifier le format de la clé (`raw, hex, passphrase`). Par défaut, la clé va être promptée, mais il est possible de la stocker sur le système de fichier, ou bien via une URL. L'option `encryption` permet aussi de spéficier l'algorithme de chiffrement à utiliser. - -Par exemple: - -```bash -sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase pool/dataset -``` - -Pour vérifier que tout va bien on peut récupérer la propriété de chiffrement : - -```bash -sudo zfs get encryption pool/dataset -``` - - -Pour changer la clé il suffit d'utiliser la commande suivante : - -```bash -sudo zfs key -c pool/dataset -``` - -qui va demander la nouvelle passphrase. - -Il est aussi possible de changer la source de la clé (pour aller chercher la clé dans un fichier par exemple). - - -## Monter/démonter un dataset chiffré - -Par défaut le dataset sera monté. Pour le démonter il suffit d'utiliser la commande `unmount`. Attention, la clé de chiffrement sera toujours chargée, et le dataset pourra être remonté sans redemander la clé. Pour ça, il faut décharger la clé : - -```bash -sudo zfs unmount pool/dataset && sudo zfs unload-key pool/dataset -``` - - -Pour remonter le dataset il faut alors recharger la clé : - -```bash -sudo zfs load-key pool/dataset && sudo zfs mount pool/dataset -```