diff --git a/compte_rendus/2024_01_13.md b/compte_rendus/2024_01_13.md deleted file mode 100644 index 48d0707..0000000 --- a/compte_rendus/2024_01_13.md +++ /dev/null @@ -1,91 +0,0 @@ -# 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/2024_06_22.md b/compte_rendus/2024_06_22.md deleted file mode 100644 index 46e42ac..0000000 --- a/compte_rendus/2024_06_22.md +++ /dev/null @@ -1,86 +0,0 @@ -# Réunion IN - - * Date : Samedi 22 Juin 2024 - * Lieu : MB87 et Galène (https://galene.crans.org/group/CA) - * Début : 14h23 - reprise à 15h20 - * Fin : 16h07 - -## Présent⋅es - -* GaBo -* [Chiaroush](https://wiki.crans.org/WikiChiaroush) -* [vanille](https://wiki.crans.org/VanilleNiven) -* lzebulon -* Otthorn -* [RDB](https://wiki.crans.org/WikiRDB) -* [bleizi](https://wiki.crans.org/WikiBleizi) -* [Aplanos](https://wiki.crans.org/WikiAplanos) - -## Ordre du jour - -* Clé usb d’installation de 128go avec ventoy ou équivalent pour les installations -* commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le faire en live) -* [GaBo] Ansible est trop vieux (drop de support de certain plugin, peut pas relancer les playbooks. Marche encore avec ansible_2_14) -* [Otthorn] ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org pas le bon LDAP, faut utiliser wall-e -* [Otthorn] Action deny sur WikiMoinMoin -* [Lzebulon] Point sur les backups : ne semble pas fonctionner (backup-{thot,ft} non contactable) -* VM Collabora -* [Gabo] Ecriture du guide pour faire des VM dans la documentation -* Owncloud : soucis de LDAP -* Gitlab : à mettre à jour au plus vite (on est en 16.1) - -### Clé USB d'installation 128 go Ventoy - -(En référence à une conversation du 16 Mai 2024) -Une seule clé avec plusieurs ISO plutôt que clés nombreuses avec distros différents -> Problèmes de sécurité, mais intéressant pour les nounous -Le logiciel proposé (Ventoy) est plutôt répandu/réputé mais pas terrible. Problèmes de sécurité entre-autre. -On propose de faire minimaliste sans utiliser le logiciel Ventoy. Ce serait intéressant parce que ça nous épargnerait le trousseau de clés (qui a été perdu il paraît), à discuter au prochain CA. -GaBo propose de partir sur 5 clés de 128 go -> 1 clé / Nounous présentes sur le plateau. -GaBo propose 64 go. 128 go lui paraît overkill. Pas de différence trop grande en terme de prix -> On part sur du 128 go. -En Install Party, on fait rarement plus de 5 installs en parallèle. -(Prendre en compte qu'il y a toujours une clé qui est perdue...) - -Projet apprenti rigolo de créer un script qui génère les clés (mettre tel OS sur une clé). - - -### Commande des disques - -Les disques sont commandés et arrivés ! -Il reste les ventilos. -GaBo a payé avec sa carte, il attend le remboursement de la part du Trésorier (Macéo) pour procéder à l'achat des ventilos. - -Avons-nous prévu un moment pour installer les nouveaux disques ? <- On en a discuté dans le point disques du CA. - - -### Ansible - -On a plein de version de retard (on est en 2.14 et la version actuelle est la 10). -https://endoflife.date/ansible -Il faudrais mette ça à jour : plugin LDAP et README en particulier et peut-être le plugin pass. On eput essayer de faire en même temps que l'install de Colabora - -### WikiMoinMoin - -On a des soucis avec l'action "deny" qui ne permettait de voir une page privée. Otthorn a fait un proof au concept de l'erreur. Il a réactivé deny, c'est bon. Mais on sait pas pourquoi ça avit été désactivé il y a longtemps. - -### Backups - -Faut se bouger pour aller voir VR en vrai à une de leurs permanences. C'est peut-être juste l'ethernet qui est débranchée. (Et potentiellement aussi changer pour un cable qui fonctionne) - -Faire les backups correctement (comme l’a indiqué Otthorn, en excluant les trucs reliés à postgress et utilisé le hook conçu pour) -voir dans la config ansible - -### Colabora - -(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c'est chiant je comprends rien à comment ça fonctionne) - -### Owncloud - -La config a disparu par magie (À enquêter) - -### GitLab - -Il faut mettre à jour. (On le fera vers juste après l’IN) - -### Documentation - -GaBo a été désigné grand gagnant de qui s'occupera de la documentation d'Ansible. \ No newline at end of file diff --git a/compte_rendus/2024_08_29.md b/compte_rendus/2024_08_29.md deleted file mode 100644 index 8832f1f..0000000 --- a/compte_rendus/2024_08_29.md +++ /dev/null @@ -1,166 +0,0 @@ -# Réunion IN - -* Date : Jeudi 29 Août 2024 -* Lieu : MB87 et Galène (https://galene.crans.org/group/CA) -* Début : 18h58 -* Fin : 21h - -## Présent⋅es - -* [bleizi](https://wiki.crans.org/WikiBleizi) -* [Pigeon Moelleux](https://wiki.crans.org/WikiPigeonMoelleux) -* GaBo -* [vanille](https://wiki.crans.org/VanilleNiven) -* korenst1 -* Lzebulon -* Shinigami -* [Hachino](https://wiki.crans.org/WikiHachino) -* underscore_j -* RDB -* Otthorn - -## Ordre du jour - -### Rapide compte-rendu de ce qu'il s'est passé cet été -Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de mauvaises configurations -problème entre ansible et les scripts qui sont dépréciés. - -Mise à jour de gitlab - -Au milieu de l'été. pb entre owncloud et nextcloud. impossibilité d'écrire (indépendant du reste). esum a résolu le pb. Owncloud a ensuite perdu sa conf ldap. -Nextcloud a fini d'être configuré (paramêtre de partage et les mails (envoi de mail automatique pour les événements)). Nextcloud marche bien. -Pub pour nextcloud possible. - -pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé dans apt. Pas possible d'installer onlyoffice comme ça. On doit le faire à la main. Donc ce n'est pas ansibelisable. -Il n'est pas possible d'utiliser onlyoffice sur téléphone (firefox) et limité à 20 connexions en même temps. du coup, est-ce qu'on utilise Collabora ou Onlyoffice ? - -Du coup on peut passer sur collabora qui n'a pas ces problèmes. -Sinon Otthorn a trouvé la variable à modifier. - -``` -server/Common/sources/constant.js -exports.LICENSE_CONNECTIONS = 20; -``` - -### état sur les serveurs de backup -2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais il marche et permet de faire -Peut-être la poussière ou les ventilos sont cassés. Bref, il faudra probablement faire qch. -On ne sait pas si l'ilo marche. Mais il est possible de relancer les backups. - -specs du serveurs chez viarezo : https://wiki.crans.org/CransNostalgie/CransTechnique/LesServeurs/ServeurFt - -Pour thot : le serveur s'éteint spontanément après le démarrage. c'est probablement à cause de la sonde de température - -On remet ft puis on réinstalle thot - -Il existe plus simple que borg. Est-ce qu'on ne passerait pas sur truc plus récent. mais on garde borg pour le moment. Sinon on peut utiliser restic. - -On s'assure que ft remarche avant de faire thot (moins urgent) - -Pigeon : "IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP" - -Tealc : on n'arrive pas à ajouter les disques donc pk on y arriverait avec thot ? - - - -Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu de membre actif chez eux. - -Chez Tuxae ? -> c'est possible on a l'accord du président. - -Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer pour récupérer les données. - -ft urgent et une fois fonctionnel, on commence sur thot. On peut aussi chiffrer les disques nativement avec zfs. - -### Cephiroth -Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux). - -### Serveur matrix -De plus en plus de demande pour avoir une alternative libre à discord, whatsapp.... - - -Mastodon -> pas adapté -Zulipe -> pas adapté -Mattermost -> pas adapté -Matrix -> faire de la pédagogie. Pas le temps de faire le support technique ? Il est possible de faire des vocaux. Il faut présenter ça aux gens mais iels auront besoin d'une passphrase et ou une clef de récupération. - -Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais est-ce que le serveur est possible de gérer plus de connexions. -En principal, obligation de mettre le ldap du crans. Possibilité d'utiliser la note via Oauth... -Les alias ça change. On doit conserver le pk. Potentiellement, on peut ajouter un préfix (genre "note_"). - -Ou alors, 2 instances de matrix, une pour chaque ldap. L'une est au bde mais le crans s'en occupe. -Migrer SQLite à PostgreSQL. -Si on migre le bde, il faut que se soit très stable. -Est-ce qu'il est possible d'avoir de la redondance sur le serveur matrix ? a priori oui... mais peut-être pas intégrer pas défaut à matrix. -matrix.crans.org juste un relai (bridge irc/matrix) pour la réinstallation, il faut demander à Erdnaxe. - -On garde le serveur matrix tel quel (quitte à augmenter les perfs). migre de SQLite à PostgreSQL. LDAP crans en priorité. -On met element -chat.crans.org (facile à retenir) -FAIRE DE LA PUB ! - -5 secondes sur Mastodon selon pigeon (c'est (déjà) perdu) mais moi je pense que la vérité est toute autre... -Retirer la condition "cephirot.date < mastodon.date". -Ajouter l'affirmation "Constellation.state == Cephiroth.state" - -### Reprise des séminaires hebdomadaires - -On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire ce point moulte années plutard !)) - -### état de l'imprimante - -bref : ça marche pas - -L'imprimante a été déplacée mais impossible de communiquer avec l'imprimante. -Il faudra se poser avec des personnes de la DSI pour résoudre le pb. Mais dire ce qu'on a fait, il est possible que ça avance. -pigeon pense pouvoir s'en charger mais il ne connait pas ce qu'il y a autour de l'imprimante. - -On essaie de s'en occuper assez rapidement (bleizi et pigeonmoelleux) - -### mettre les clés gpg dans le pass -pb de rétention des clefs gpg. pigeon a "pillé" à bleizi les clefs. -potentiellement signer les clefs gpg des nounous. - -Remettre de l'ordre dans le pass. thot renommé en surface sans raison (a priori). - -Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou autre... -Sinon, demander aux vielles nounous (peb, pollion) si iels veulent garder leurs droits nounous (ça ressemble à une invitation à partir...). -Pour les autres, on propose de rajouter les clefs gpg dans le pass. - -### Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin -Près de 400 jours qu'il tourne. (pas de coupure estivale). -Pas possible de la faire avant les prochaines vacances. En profiter pour refaire le cablage. -Une réunion de préparation de la réparation. -(redémarrage et brassage)-> prochain IN - -### Chronolgie TODO list - -Très urgent : - - Backup ft (commencé à faire les backup) - - 1/2 qui non important (genre voyager et helloworld) - - par ordre d'importance (genre mailman) - - d'ici là samedi rangement, inté, séminaires - - Cephiroth (garantie go GaBo) - - puis on s'occupe de thot - -on est déjà dans qq semaines : - - onlyoffice (la limite) - - bleizi, pigeon -> imprimante - - les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent rester nounous) - - enlever les vielles nounous (charlie, peb ? et pollion ?) - -Le mois prochain : - - prévénir tout le monde que les serveurs du crans sont down - - Backup tealc sur zéphir/cameron - - inventaire et commander des disques d'avances (un disque en rab compatible pour chacun des serveurs) - - coupure : recabler, (vérifier l'étiqueteuse) - - PASSER LA POOL EN 4096 - - réinstaller tealc - -Après : - - voir matrix - - rediscuter de mastodon - - Nix - -Jamais : - - Constellation - - Ceph \ No newline at end of file diff --git a/compte_rendus/README.md b/compte_rendus/README.md deleted file mode 100644 index 2c45d10..0000000 --- a/compte_rendus/README.md +++ /dev/null @@ -1,20 +0,0 @@ -# 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 deleted file mode 100644 index 688960d..0000000 --- a/compte_rendus/TEMPLATE.md +++ /dev/null @@ -1,34 +0,0 @@ -# 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/howto/README.md b/howto/README.md deleted file mode 100644 index ae773ab..0000000 --- a/howto/README.md +++ /dev/null @@ -1,24 +0,0 @@ -# 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/changer_de_pseudo.md b/howto/changer_de_pseudo.md deleted file mode 100644 index 7818277..0000000 --- a/howto/changer_de_pseudo.md +++ /dev/null @@ -1,108 +0,0 @@ -# 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 : 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 -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. - -## 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. - -## Backups - -Étape non pressante, mais on peut se rendre sur `backup-ft` et `backup-thot` -pour déplacer `/backup/borg-adh/home/ancienpseudo` en -`/backup/borg-adh/home/nouveaupseudo`, si ce n'est pas trop tard. Si le nouveau -dossier est déjà créé, alors on peut attendre quelques jours voire quelques -mois au cas où pour supprimer l'ancien dossier inutile. - -À faire avec précaution. Mais à faire puisqu'on ne garde pas des backups -éternellement. Pas pour des raisons de place mais pour des raisons de -non-conservation de données personnelles. - -## Gitlab - -S'il n'y a pas d'ancien compte, il n'y a rien à faire. - -S'il y a un ancien compte ET un nouveau compte, c'est pénible. Il faut -transférer les appartenances de projet d'un compte à l'autre. Ce cas ne -s'étant pour l'instant pas présenté, il sera à détailler à terme. - -On se place dans l'hypothèse où l'on veut renommer un ancien compte. On -commence par se rendre dans l'interface d'administration de Gitlab, section -utilisateurs : -[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 -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. - -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/). - -S'il n'y a pas d'ancien compte, aucune question à se poser. - -S'il y a un nouveau compte inutile, on le supprime. - -S'il n'y a pas de nouveau compte, on peut changer le pseudo Mailman si -souhaité, mais l'important est surtout d'aller dans les connexions sociales et -de changer le pseudo utilisé pour lier le compte Mailman. - -## 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. - -## 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. diff --git a/howto/creer_vm_adherent.md b/howto/creer_vm_adherent.md deleted file mode 100644 index cf39fcc..0000000 --- a/howto/creer_vm_adherent.md +++ /dev/null @@ -1,185 +0,0 @@ -# Création de machine virtuelle pour les adhérent⋅es - -Le crans propose un système de locations de vms dont vous pouvez retrouver les -tarifs dans les annexes des statuts de l'association. En voici un -récapitulatif ici, mais attention celui-ci peut ne pas être à jour et seul -ce qui est marqué dans les statuts fait foi. - -| Article | Tarifs | -|:---------------------------------------:|:------:| -| Service minimal | 10€ | -| Connexion internet | 30€ | -| Cœur additionnel | 5€ | -| 2GB de RAM additionnel | 5€ | -| Disque additionnel (par tranche de 16G) | 1€ | - -Le service minimal comprend : - -* 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 - -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). - -Celui ci se situe sur flirt et à la structure suivante: - -```txt -ou=users -├── cn=toto -└── cn=titi -ou=clubs -└── o=rover -ou=hosts -├── cn=voyager -└── cn=curiosity -``` - -Pour référence ma configuration `shelldap` pour me connecter au ldap est la -suivante : - -```txt -# +---------------------------------+ -# | Connexion à flirt.adm.crans.org | -# +---------------------------------+ -server: ldaps://flirt.adm.crans.org/ -promptpass: yes -binddn: cn=admin,dc=adh,dc=crans,dc=org -basedn: dc=adh,dc=crans,dc=org -``` - -et le mot de passe est disponible dans le password-store sous `ldap-adh`. - -#### 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 -objectClass: person -objectClass: top -cn: toto -description: birthDate:1998-01-08 -description: birthLocation:Cachan -description: membershipStart:20xx-xx-xx -description: membershipEnd:20xx-xx-xx -description: re2oId:xxxxx -givenName: Toto -mail: nobody [AT] crans [DOT] org -postalAddress: 60 rue camille desmoulins, 94230, Cachan -sn: Passoir -telephoneNumber: +336xxxxxxxx -userPassword: {CRYPT}$6$… -``` - -Le script `addadherent` du repo -[crans-ldap](https://gitlab.crans.org/nounous/crans-ldap) permet néanmoins de -configurer la plupart des informations à renseigner : - -```bash -[ _shirenn@flirt ] $ ./addadherent --re2o-id xxxxx toto -Prénom: Toto -NOM: Passoir -Adresse email: nobody [AT] crans [DOT] org -Adresse: 60 avenue camille desmoulins, 94230, Cachan -Numéro de téléphone: +33600000000 -Date de naissance (YYYY-MM-DD): 1998-01-08 -Lieu de naissance: Cachan -``` - -Cela rajoutera automatiquement la date de début d'adhésion mais pas celle de -fin d'adhésion, celle-ci doit être rajoutée à la main en utilisant votre -client ldap favori. - -#### 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 -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 -objectClass: ipHost -objectClass: ieee802Device -cn: curiosity -description: ip.icmp.in,ip.icmp.out,ip6.icmpv6.in,ip6.icmpv6.out,ip.tcp.out:0-65535,ip6.tcp.out:0-65535,ip.udp.out:0-65535,ip6.udp.out:0-65535,ip.tcp.in:22,ip6.tcp.in:22 -ipHostNumber: 185.230.78.199 -macAddress: 02:a0:00:01:99:12 -owner: o=rover,ou=clubs,dc=adh,dc=crans,dc=org -serialNumber: 199 -``` - -Le script `addadherenthost` crée la machine dans le ldap - -```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 -sortie et ne laisse rentrer que le port 22 en tcp, en ip legacy et en ipv6. - -Une fois l'adhérent⋅e ou le club et la machine rajoutée dans le ldap. Les -scripts devraient mettre à jour la configuration du parefeu, du dhcp et de -proxmox. - -### Proxmox - -Il faut maintenant aller sur le cluster constitué de gulp, odlyd et stitch -pour créer la machine virtuelle. C'est du clic clic dans proxmox, vous êtes -assez grand⋅es pour savoir lire des menus. (Par contre faites bien attention -à créer les disques sur la pool `vm`). - -Ensuite, deux possibilités, soit l'adhérent⋅e vous a juste demandé de -créer la machine virtuelle et à ce moment là c'est fini et iel peut aller la -configurer seul⋅e (c.f. section suivante), soit iel vous a demandé si vous -pouviez lui installer une distribution de son choix. - -Vous pouvez alors lui demander une clé publique ssh, et après avoir installé -la vm, vous la déposez dans `/root/.ssh/authorized_keys` (en faisant attention -à créer le `.ssh` avec les bonnes permissions `mkdir -m 0700 /root/.ssh`) et -vous supprimez les mots de passe que vous avez rentrer pendant l'installation -`passwd -d root`). diff --git a/howto/devenir_nounou.md b/howto/devenir_nounou.md deleted file mode 100644 index 8bf9682..0000000 --- a/howto/devenir_nounou.md +++ /dev/null @@ -1,173 +0,0 @@ -# Comment devenir nounou ? - -Bonjour jeune apprenti⋅e, tu regardes sûrement avec des yeux pleins d'étoiles -tes ainé⋅es qui actuellement disposent des droits suprêmes sur l'infrastructure -du Crans. Ce petit document est là pour t'expliquer comment toi aussi un jour tu -pourras devenir l'un⋅e d'elleux. Et quand il sera temps et que tu commenceras à -t'encrouter, comment tu pourras rendre tes droits. - -Déjà commençons par une question un peu conne mais néanmoins légitime « Qui -"mérite" d'être nounou ? » Premièrement, devenir nounou **N'EST PAS** une -question de compétence. Pas besoin de connaître l'infrastructure par cœur, tous -les fichiers de conf, être un pro d'apt, d'ansible et de la couche 2. Tout ce -qu'on attend d'une nouvelle nounou c'est d'être capable de ne pas faire -n'importe quoi avec ces droits. Devenir nounou ce n'est pas avoir fini son -apprentissage mais bien la deuxième étape de celui-ci où on commence à mettre -les mains dans le camboui. Et ça ça présuppose seulement qu'on va pas causer du -tort en utilisant ces droits. - -Détaillons-les un peu ces droits, ce qu'il permette de faire et qu'est ce qu'on -entend par « causer du tort ». En devenant nounou, vous débloquez les accès à -toute l'infrastructure. Techniquement, il n'y a plus de fichiers que vous ne -pouvez pas voir, modifier ou supprimer et ce sur toutes les machines du Crans. -De même, on chiffre pour vous tous les mots de passe qui ont trait au technique -du Crans. Ce sont des droits très extensifs. D'où la possibilité de faire une -erreur de manipulation. Normalement tout est fait dans l'infrastructure pour -limiter la casse possible. On a de la redondance où c'est possible et -nécessaire, on fait des backups quotidiennes à la fois des données utilisateur⋅rices -mais aussi des données d'administration. Cependant, tout ça ne change pas le -fait qu'une mauvaise commande rentrée dans votre shell peut rendre le -Crans hors ligne pour quelques heures ou supprimer de manière irreversible des -données. Quand vous devenez nounou, on vous fait confiance pour éviter ce genre -de choses au maximum. Après les erreurs ça arrive toujours. La personne qui -écrit ces lignes en a fait un certain nombre avec des conséquences diverses. -Ce qui compte ce n'est pas de ne pas en faire du tout, c'est d'en faire peu, -d'apprendre de celles-ci et de s'assurer qu'elles ne sont pas irréversibles. - -Il y a aussi quelque chose qu'il faut souligner. Et normalement quand vous -deviendrez nounou vous allez le voir assez fréquement (à chaque fois que vous -faîtes un sudo pour la première fois sur une machine) : - -```txt -We trust you have received the usual lecture from the local System -Administrator. It usually boils down to these three things: - - #1) Respect the privacy of others. - #2) Think before you type. - #3) With great power comes great responsibility. -``` - -Ce court texte résume bien ce que je veux aborder ici. Les droits que vous vous -voyez confier sont une intrusion phénoménale dans la vie privée des gens. Si -vous voulez une métaphore, vous pouvez voir ça comme si les adhérent⋅es du Crans -vous avait donné la clé de leur maison pour que vous puissiez réparer quand il y -a une fuite d'eau, mais pas pour que vous fouillez dans le bureau pour voir leurs -papiers. Beaucoup de nos adhérent⋅es utilisent les outils qu'on met à leur -disposition pour organiser une partie de leur vie, que ce soit d'utiliser -l'adresse mail qui leur est fournie ou stocker des données dans leur Owncloud, -et nous en sommes très heureux⋅ses. La charte que vous avez signé en devenant -apprenti⋅e mentionne déjà ces problématiques mais il est important que ce soit -très clair. **Vous ne pouvez consulter ou diffuser les données personnelles -d'un⋅e adhérent⋅e qu'avec son consentement explicite.** On a parfois tendance à -l'ENS à faire des abus de droits une blague, ce n'est pas le cas au Crans ! - -Bon maintenant que ces clarifications et rappels ont été faits, on va pour -passer aux choses plus intéréssantes : comment on se donne ces droits (et dans la -marge, comment on se les retire) ? - -## Rentre dans le cercle - -Le groupe des superadministrateur⋅rices au Crans est le groupe nounou. On va donc -faire un petit tour dans le ldap et sous ou=groups,cn=_nounou on rajoute les -uids correspondant au⋅x personne⋅s qu'on souhaite ajouter. Voilà, vous avez -normalement:tm: les accès root sur toutes les machines du Crans. Cependant, -vous allez peut-être constater qu'il y a certaines machines où cela ne -fonctionne pas. C'est sûrement dû à ces ~~conneries~~ de replicat ldap. Il faut -à ce moment là aller faire un tour dessus pour forcer la resynchro (c.f. -`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: - - 1. On se souvient du hash de commit courant : - `HASH=$(git rev-parse HEAD)` - 1. On ajoute toutes les personnes concernées dans le groupe nounou dans le - fichier `.groups.yml` du store et on commit ces changements `git commit -m - toto1234`. - 1. On rechiffre tous les fichiers à rechiffrer - `cat .last_group.json | jq -r '. | with_entries( select(.value | any( .== - "nounou"))) | keys[]' | xargs pass rans reencrypt` - 1. On supprime tous les commits inutiles : - `git reset --soft $HASH; git commit -m 'Coucou les ami⋅es'` - 1. On vérifie que ça marche et on push :) - -Petit point pour quand on retire des droits au gens. Là où pour tous les autres -droits, quand vous les retirez à quelqu'un⋅e bah iel les a plus, ce n'est pas le -cas pour les mots de passe. Il reste dans l'historique de git un moment où la -personne qui perds ces droits à toujours les mots de passes chiffrées pour elle. -On choisit généralement de s'en tamponner l'oreille avec une babouche. -Cependant, il peut y avoir certains moments où on veut effectivement retirer -complètement à quelqu'un⋅e la possibilité d'utiliser un mot de passe. Dans ce -cas il faut le changer :( - -## 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 -, 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⋅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="" - hash="sha256" - host="*" - type="Deity" - fingerprint="" - autologin="on" -> -``` - -Où le hash du mot de passe peut être obtenu en envoyant -`/quote mkpasswd hmac-sha256 `. Pour rendre les changements effectifs -on reload le service inspircd (tips, la manière la plus rapide de perdre ses -droits est de restart le serveur plutôt que de le reload ^^). - -### Mails - -Il faut maintenant vous rajouter en alias de root@crans.org. C'est le début du -spam. Pour ce faire, rendez-vous sur le dépôt Gitlab `mail-aliases`, et ajoutez -votre pseudo Crans sur la bonne ligne dans les bons fichiers, en face de `root:`. -Pensez ensuite à mettre à jour le dépôt pour le service `mail`, et enfin mettez -bien à jour `redisdead`, `sputnik` et surtout `zamok` dans le dossier -`/var/local/services/mail`. Enfin, pensez bien à filtrer les mails arrivant à -l'adresse `root@crans.org` sur votre client. - -Voilà, tu as maintenant gagné le droit de t'ajouter ou de te retirer de - ! diff --git a/howto/supprimer_utilisateur.md b/howto/supprimer_utilisateur.md deleted file mode 100644 index 4db2da9..0000000 --- a/howto/supprimer_utilisateur.md +++ /dev/null @@ -1,139 +0,0 @@ -# La suppression d'un⋅e utilisateurice - -Pour diverses raisons dont il n'est pas question de juger, un⋅e -utilisateur⋅rice peut vouloir supprimer son compte Crans et les données -associées. En particulier cela peut rentrer dans le cadre du -[RGPD](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/). Il y a -certaines informations qu'il faut garder une durée minimale, mais les autres -doivent être supprimées à la demande de l'utilisateurice. C'est pénible -mais faisable : respecter la volonté de l'utilisateur⋅rice dans ce cas est -important. Ce petit guide est là pour rappeler tout ce qu'il ne faut pas -oublier. - -## La demande de suppression - -Il faut s'assurer que c'est bien la bonne personne qui fait la demande. En cas -de doute, on peut demander une preuve d'identité (pièce d'identité, mail -depuis l'adresse mail crans...). Ensuite, on peut vérifier que la personne à -bien compris ce que la suppression de compte impliquait : la perte de toutes -les données non sauvegardées par l'utilisateurice, ne plus avoir accès aux -services qui nécessite un compte crans... Selon ce qui est demandé (et ce -qu'on a le droit de faire), le compte peut être seulement archivé, on peut -supprimer les données liées au compte (en totalité ou partie), voire les -données d'un service non-lié à un compte crans (wiki...). Si la personne -est encore adhérente, elle va probablement devoir démissionner de -l'association. - -## Re2o - -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. - -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 - 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. - -## 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}`. - -## Backups - -Étape non pressante, mais on peut se rendre sur `backup-ft` et `backup-thot` -pour supprimer `/backup/borg-adh/home/{pseudo}`. - -À faire avec précaution. Mais à faire puisqu'on ne garde pas des backups -éternellement. Pas pour des raisons de place mais pour des raisons de -non-conservation de données personnelles (même si les backup ne sont pas -concernées par le RGPD). - -## 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 -: -[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). - -## Owncloud - -Il suffit simplement de se rendre dans l'interface d'administration, section -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/). - -S'il n'y a pas de compte, aucune question à se poser. - -S'il y a un compte, on le supprime. - -Potentiellement, la personne est présente sur mailman de manière non-liée à -son éventuel compte crans. Dans ce cas, il va falloir faire du ménage avec -l'adresse mail et donc de l'aide de l'utilisateurice qui va devoir indiquer son -adresse et les ML qu'iel reçoit/administre. Ça peut être un peu les bazar -si il y a plusieurs adresses non-liées. Si la personne est lae dernièr⋅e -propriétaire d'une liste, il faudra soit la supprimer soit lui trouver un⋅e -nouvelleau propriétaire (c'est pas obligatoire mais alors c'est 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 personne le demande, on peut supprimer son compte wiki et les pages qui -concernent son compte (page perso...), historique compris. Pour cela il faut -aller sur `kiwi` et supprimer le dossier contenant la page. Cela peut concerner -des personnes n'ayant pas de compte crans, mais il faudra le WikiNom. - -## The Lounge - -S’il y a eu une utilisation de WebIRC, on peut aller sur Zamok et -`rm /etc/thelounge/users/{pseudo}.json` (configuration), -`rm /etc/thelounge/logs/{pseudo}` et `rm /etc/thelounge/logs/{pseudo}.sqlite3` -(pour l'historique des messages). - -## 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). - -## 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. diff --git a/outils/logiciels/README.md b/outils/logiciels/README.md deleted file mode 100644 index b881a59..0000000 --- a/outils/logiciels/README.md +++ /dev/null @@ -1,15 +0,0 @@ -# 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/outils/logiciels/apt.md b/outils/logiciels/apt.md deleted file mode 100644 index dbb3d69..0000000 --- a/outils/logiciels/apt.md +++ /dev/null @@ -1,61 +0,0 @@ -# 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 : - -| commande | description | -|----------|-------------| -| `apt install package` | Installe `package` | -| `apt search package` | Recherche `package` | -| `apt list` | Liste les paquets | -| `apt list --installed` | Liste les paquets installés | -| `apt remove package` | Désinstalle `package`, sans supprimer sa configuration | -| `apt purge package` | Purge `package`, i.e. désinstalle et supprime sa configuration | -| `apt depends package` | Liste les dépendances de `package` | -| `apt rdepends package` | Liste les paquets dépendants de `package` | -| `apt policy package` | Affiche les informations de priorité pour `package` | -| `apt show package` | Affiche les informations de `package` | -| `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. - -## 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. - -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 - -# Paquets "volatiles" pour avoir des mises à jour un peu plus régulièrement -deb https://ftps.crans.org/debian buster-updates main - -# Paquets apportant les mises à jour de sécurité -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`. - -## 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. - -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 deleted file mode 100644 index 1f27cc8..0000000 --- a/outils/logiciels/gpg.md +++ /dev/null @@ -1,44 +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/outils/logiciels/ssh.md b/outils/logiciels/ssh.md deleted file mode 100644 index 7c2b824..0000000 --- a/outils/logiciels/ssh.md +++ /dev/null @@ -1,100 +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 : - -```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/outils/logiciels/systemd.md b/outils/logiciels/systemd.md deleted file mode 100644 index 8ffbe7b..0000000 --- a/outils/logiciels/systemd.md +++ /dev/null @@ -1,64 +0,0 @@ -# Systemd - -Systemd est une suite logiciel pour systèmes GNU/Linux. Cette suite logiciel -fournit de nombreuses fonctionnalités, notamment pour configurer son OS et -suivre les *daemon*\ s actifs et leurs journaux. - -Ce document décrit *certaines* fonctionnalités de Systemd bien choisies, -lesquelles sont jugées intéressantes pour l'administration système ou pour -utilisateurices. Il sera sans doute découpé en plusieurs morceaux s'il devient -trop long. - - -## Unités de configuration: un format unifiant. - -### Services. - -### Minuteurs. - -### (Auto)mount. - - -## Configuration Réseau. - -### Obtenir des adresses IPs. - -### Configuration DNS (récursif). - - -## Journalisation. - -### Lecture des journaux: les bases. - -### Espaces de noms. - -### Partage de journaux entre machines. - - -## Aspect pratique (pour utilisateurices) - -### Chiffrement de disque. - -### Chargeur d'amorçage. - - -## Conteneurisation et virtualisation. - -### Conteneurisation. - -### Virtualisation. - - -## Gestion des secrets. - - -## Trucs et astuces. - -### Systèmes dynamiques: gestion des erreurs dans les services. - -### Administration à distance. - - - --> diff --git a/outils/logiciels/zfs.md b/outils/logiciels/zfs.md deleted file mode 100644 index adc6d59..0000000 --- a/outils/logiciels/zfs.md +++ /dev/null @@ -1,201 +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 -```