Documentation du Cr@ns.

Normalement, je n'ai oublié personne, mais n'hésitez pas à vous rajouter si nécessaire (ou retirer des doublons ou dead-names que j'aurais loupé).

Copyright © 2021-2024 Arnaud Daby-Seesaram

Copyright © 2023-2024 bleizi <bleizi@crans.org>

Copyright © 2024 korenstin <korenstin@crans.org>

Copyright © 2024 Lzebulon <lzebulon@crans.org>

Copyright © 2023-2024 Otthorn <otthorn@crans.org>

Copyright © 2023-2024 pigeonmoelleux <pigeonmoelleux@crans.org>

Copyright © 2023 Michaël Paulon <paulon@crans.org>

Copyright © 2024 Neven Villani <vanille@crans.org>

Copyright © 2021-2023 shirenn <shirenn@crans.org>

Copyright © 2021-2022 Emmy D'ANELLO <ynerant@crans.org>

Copyright © 2021-2022 Benjamin Graillot <graillot@crans.org>

Copyright © 2021 Alexandre Iooss <erdnaxe@crans.org>

Copyright © 2022 Maxime Bombar <bombar@crans.org>

     TODO: information concernant la licence...

The document was typeset with GNU Texinfo (https://www.gnu.org/software/texinfo/).

Documentation du Cr@ns
**********************

Comptes rendus de réunion
*************************

Cette section 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.

Chaque sous-section est le compte-rendu d'une réunion technique. Vous pouvez trouver un template de compte-rendu dans sous-section TEMPLATE (see CR Template) si nécessaire. La seule contrainte pour cette section est le nom des sous-sections. Les comptes-rendus sont identifiés par la date de la réunion : pour une réunion du JJ/MM/AAAA, la sous-section devra se nommer AAAA MM JJ (et non JJ MM AAAA car le tri par date se fait plus simplement).

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/CransApprentis)

  * Apprenti 2 (https://wiki.crans.org/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

...

IN du samedi 13 janvier 2024
============================

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 soonTM 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é.

IN du samedi 22 juin 2024
=========================

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.

IN du jeudi 29 août 2024
========================

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)

     ``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

How-Tos
*******

Cette section contient les ``how to'' (tutoriels) du Crans concernant des tâches techniques demandant des connaissances généralement sur plusieurs parties de l'infrastructure.

Si vous souhaitez que d'autres soient ajoutés, n'hésitez pas à vous réferrer à CONTRIBUTING.

Changer de pseudo
=================

Le pseudo est l'identifiant unique permettant de s'authentifier sur l'ensemble des services du Crans. Pour diverses raisons dont il n'est pas question de juger, un⋅e utilisateur⋅rice peut vouloir changer de pseudo. C'est pénible mais faisable : respecter la volonté de l'utilisateur⋅rice dans ce cas est important. Ce petit guide est là pour rappeler tout ce qu'il ne faut pas oublier.

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.

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, 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.

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œeur additionnel
5€

2GB de RAM additionnel
5€

Disque additionnel (par tranche de 16G)
1€

Le service minimal comprend :

  * n disque de 8H

  * 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 :

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 :

# +---------------------------------+
# | 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 :

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 :

[ _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 :

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 :

[ _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 :

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

[ _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).

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 https://re2o.crans.org/admin/users/user/ et supprimer l'user. Il va falloir supprimer les objets protégés avant, django vous dira lesquels.

Ne pas oublier d'aller contrôler le LDAP sur 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.  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, 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.

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) :

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 (see LDAP).

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)

 2. 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.

 3. On rechiffre tous les fichiers à rechiffrer cat .last_group.json |
     jq -r '. | with_entries( select(.value | any( .== "nounou"))) | keys[]'
     | xargs pass rans reencrypt

 4. On supprime tous les commits inutiles : git reset --soft $HASH; git commit -m 'Coucou les ami⋅es'

 5. 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 https://lists.crans.org/admin, dans la sous page utilisateur⋅rices, on peut rechercher les personnes concernées pour leur donner les deux statuts admin (accès à la zone d'administration) et superutilisateur (bypass tous les checks de droits).

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

<oper
    name=<nick>
    password="<pass-hash>"
    hash="sha256"
    host="*"
    type="Deity"
    fingerprint="<fingerprint certificat>"
    autologin="on"
>

Où le hash du mot de passe peut être obtenu en envoyant /quote mkpasswd hmac-sha256 <password>. Pour rendre les changements effectifs on reload le service inspircd (tips, la manière la plus rapide de perdre ses droits est de restart le serveur plutôt que de le reload ^^).

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 <https://wiki.crans.org/CransNounous !

Contributing
************

TODO.

Tools
*****

Logiciels
=========

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.

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 :

# 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.

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

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

     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 (see DNS) 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

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 :

apt install linux-headers-amd64
apt install zfs-dkms

Il faut ensuite reboot pour loader le module zfs, puis :

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 :

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 :

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» :

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 :

apt install nfs-kernel-server

Le dataset «home» de la pool «pool» peut ensuite être partager ainsi :

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 :

zfs set acltype=posixacl pool

Détruire un dataset
...................

Pour détruire le dataset pool/path on utilise la commande :

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 :

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:

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 :

sudo zfs get encryption pool/dataset

Pour changer la clé il suffit d'utiliser la commande suivante :

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é :

sudo zfs unmount pool/dataset && sudo zfs unload-key pool/dataset

Pour remonter le dataset il faut alors recharger la clé :

sudo zfs load-key pool/dataset && sudo zfs mount pool/dataset

Systemd
-------

TODO.

OS
==

Protocoles
==========

LDAP
----

TODO.

DNS
---

TODO.