documentation/crans.texi

\input texinfo   @c -*-texinfo-*-
@c %**start of header
@setfilename crans.info
@settitle Documentation du Cr@@ns: infrastructure et outils.
@c %**end of header
@copying
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 @copyright{} 2021-2024 Arnaud Daby-Seesaram@*
Copyright @copyright{} 2023-2024 bleizi <bleizi@@crans.org>@*
Copyright @copyright{} 2024 korenstin <korenstin@@crans.org> @*
Copyright @copyright{} 2024 Lzebulon <lzebulon@@crans.org>@*
Copyright @copyright{} 2023-2024 Otthorn <otthorn@@crans.org>@*
Copyright @copyright{} 2023-2024 pigeonmoelleux <pigeonmoelleux@@crans.org>@*
Copyright @copyright{} 2023 Michaël Paulon <paulon@@crans.org>@*
Copyright @copyright{} 2024 Neven Villani <vanille@@crans.org>@*
Copyright @copyright{} 2021-2023 shirenn <shirenn@@crans.org>@*
Copyright @copyright{} 2021-2022 Emmy D'ANELLO <ynerant@@crans.org>@*
Copyright @copyright{} 2021-2022 Benjamin Graillot <graillot@@crans.org>@*
Copyright @copyright{} 2021 Alexandre Iooss <erdnaxe@@crans.org>@*
Copyright @copyright{} 2022 Maxime Bombar <bombar@@crans.org>@*

@quotation
TODO: information concernant la licence@dots{}
@end quotation

The document was typeset with
@uref{https://www.gnu.org/software/texinfo/, GNU Texinfo}.

@end copying

@dircategory Le Cr@@ns
@direntry
* Crans: (crans). Documentation de l'infra du Cr@@ns et de nos outils.
@end direntry

@titlepage
@title Documentation du Cr@@ns
@subtitle Documentation du Cr@@ns
@author Les nounous <nounou@@crans.org>
@page
@vskip 0pt plus 1filll
@insertcopying
@end titlepage

@c Output the table of the contents at the beginning.
@contents

@node Top
@top Documentation du Cr@@ns

@menu
* Comptes rendus::
* How-Tos::
* CONTRIBUTING::
* Tools::
* Index::
@end menu

@node Comptes rendus
@chapter 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
@email{apprenti-es@@lists.crans.org} et @email{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
(@pxref{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 @code{AAAA MM JJ} (et non @code{JJ MM AAAA}
car le tri par date se fait plus simplement).

@menu
* CR Template::
* 2024 01 13::
* 2024 06 22::
* 2024 08 29::
@end menu

@node CR Template
@section Réunion IN

@table @asis
@item Date
@dots{}
@item Lieu(x)
@dots{}
@item Heure de début
@dots{}
@item Heure de fin
@dots{}
@end table

@subheading Présent·es

@itemize
@item
@url{https://wiki.crans.org/CransNounous, Nounou 1}
@item
@url{https://wiki.crans.org/CransApprentis, Apprentie 1}
@item
@url{https://wiki.crans.org/CransApprentis, Apprenti 2}
@item
@url{https://wiki.crans.org/CransNounous, Nounou 2}
@item
Personne sans page wiki
@end itemize

@subheading Ordre du jour

@itemize
@item
[Nounou 1] Point 1
@item
[Nounou 2] Point 2
@itemize
@item
Sous-point 1
@item
Sous-point 2
@end itemize
@item
[Apprentie 1] Point 3
@item
[Nounou 1] Point 4
@item
[Apprenti 2] Point 5
@end itemize

@subsection Point 1

Détails et résumé des discussions du point 1

@subsection Point 2

Détails et résumé des discussions du point 2

@noindent
@dots{}

@node 2024 01 13
@section IN du samedi 13 janvier 2024

@table @asis
@item Date
Samedi 13 janvier 2024
@item Lieu
MB87 et Galène (@url{https://galene.crans.org/group/IN})
@item Début
13h32
@item Fin
15h32
@end table

@subheading Présent·es

@itemize
@item
@url{https://wiki.crans.org/WikiBleizi, bleizi}
@item
@url{https://wiki.crans.org/WikiPigeonMoelleux, Pigeon Moelleux}
@item
GaBo
@item
@url{https://wiki.crans.org/VanilleNiven, vanille}
@item
@url{https://wiki.crans.org/SolalNathan, Otthorn}
@item
@url{https://wiki.crans.org/WikiHachino, Hachino}
@item
@url{https://wiki.crans.org/Esum, esum}
@item
Korenst1
@item
shirenn
@item
Floflo
@item
RDB
@item
lzebulon
@item
@url{https://wiki.crans.org/WikiAplanos, Aplanos}
@item
Abidos
@end itemize

@subheading Ordre du Jour

@itemize
@item
Présentation SRS et fix `mailman` (spam, SPF, comptes bizarres)
@item
Point sur les DistUpgrades des VM
@item
Discussions avec la DSI (imprimante, eduroam, radius dans les locaux
associatifs)
@item
État de la DGNum (Crans à Ulm)
@item
Autres remarques diverses
@end itemize

@subsection 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.

@subsection Désinscription mailing lists

Un email de plainte a levé des doutes sur le bon fonctionnement du
mécanisme de désinscription de @code{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.

@subsection SRS

@code{shirenn} a présenté la motivation et le fonctionnement de
@url{https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme, SRS} 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 @email{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 @code{root} des récipients.

@subsection 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 à
@url{https://www.sympa.community/, sympa}.

Cela pourra faire l'objet d'un projet apprentis, pour lequel lzebulon,
RDB, Korenst1 et GaBo se disent motivés.

@subsection DU (distrib upgrade)

Tout casse à chaque fois qu'on DU un serveur.  On va passer soon@sup{TM}
sur NixOS.

@subsection 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.

@subsection 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é.

@node 2024 06 22
@section IN du samedi 22 juin 2024

@table @asis
@item Date
Samedi 22 juin 2024
@item Lieu
MB87 et Galène (@url{https://galene.crans.org/group/CA})
@item Début
14h23 --- reprise à 15h20
@item Fin
16h07
@end table

@subheading Présent·es

@itemize
@item
GaBo
@item
@url{https://wiki.crans.org/WikiChiaroush, Chiaroush}
@item
@url{https://wiki.crans.org/VanilleNiven, vanille}
@item
lzebulon
@item
Otthorn
@item
@url{https://wiki.crans.org/WikiRDB, RDB}
@item
@url{https://wiki.crans.org/WikiBleizi, bleizi}
@item
@url{https://wiki.crans.org/WikiAplanos, Aplanos}
@end itemize

@subheading Ordre du jour

@itemize
@item
Clé usb d’installation de 128go avec ventoy ou équivalent pour les
installations
@item
commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le faire
en live)
@item
[GaBo] Ansible est trop vieux (drop de support de certain plugin, peut
pas relancer les playbooks. Marche encore avec ansible_2_14)
@item
[Otthorn] @code{ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org}
pas le bon LDAP, faut utiliser wall-e
@item
[Otthorn] Action deny sur WikiMoinMoin
@item
[Lzebulon] Point sur les backups : ne semble pas fonctionner
(backup-@{thot,ft@} non contactable)
@item
VM Collabora
@item
[Gabo] Ecriture du guide pour faire des VM dans la documentation
@item
Owncloud : soucis de LDAP
@item
Gitlab : à mettre à jour au plus vite (on est en 16.1)
@end itemize

@subsection 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é).

@subsection 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.

@subsection Ansible

On a plein de version de retard (on est en 2.14 et la version actuelle
est la 10).  @url{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

@subsection 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.

@subsection 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

@subsection Colabora

(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c'est
chiant je comprends rien à comment ça fonctionne)

@subsection Owncloud

La config a disparu par magie  (À enquêter)

@subsection GitLab

Il faut mettre à jour. (On le fera vers juste après l’IN)

@subsection Documentation

GaBo a été désigné grand gagnant de qui s'occupera de la documentation
d'Ansible.

@node 2024 08 29
@section IN du jeudi 29 août 2024

@table @asis
@item Date
jeudi 29 août 2024
@item Lieu
MB87 et Galène (@url{https://galene.crans.org/group/CA})
@item Début
18h58
@item Fin
21h
@end table

@subheading Présent·es

@itemize
@item
@url{https://wiki.crans.org/WikiBleizi, bleizi}
@item
@url{https://wiki.crans.org/WikiPigeonMoelleux, Pigeon Moelleux}
@item
GaBo
@item
@url{https://wiki.crans.org/VanilleNiven, vanille}
@item
korenst1
@item
Lzebulon
@item
Shinigami
@item
@url{https://wiki.crans.org/WikiHachino, Hachino}
@item
underscore_j
@item
RDB
@item
Otthorn
@end itemize

@subheading Ordre du jour

@subsection 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.

@verbatim
server/Common/sources/constant.js
exports.LICENSE_CONNECTIONS = 20;
@end verbatim

@subsection é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 :
@url{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)

@quotation Pigeon
``IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP''
@end quotation

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.

@subsection Cephiroth

Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux).

@subsection Serveur matrix

De plus en plus de demande pour avoir une alternative libre à discord, whatsapp@dots{}


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"

@subsection 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 !))

@subsection é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)

@subsection 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.

@subsection 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

@subsection Chronolgie TODO list

@table @asis
@item Très urgent
@itemize
@item
Backup ft (commencé à faire les backup)
@itemize
@item
1/2 qui non important (genre voyager et helloworld)
@item
par ordre d'importance (genre mailman)
@end itemize
@item
d'ici là samedi rangement, inté, séminaires
@item
Cephiroth (garantie go GaBo)
@item
puis on s'occupe de thot
@end itemize

@item on est déjà dans qq semaines
@itemize
@item
onlyoffice (la limite)
@item
bleizi, pigeon -> imprimante
@item
les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent
rester nounous)
@item
enlever les vielles nounous (charlie, peb ? et pollion ?)
@end itemize

@item Le mois prochain
@itemize
@item
prévénir tout le monde que les serveurs du crans sont down
@item
Backup tealc sur zéphir/cameron
@item
inventaire et commander des disques d'avances (un disque en rab
compatible pour chacun des serveurs)
@item
coupure : recabler, (vérifier l'étiqueteuse)
@item
PASSER LA POOL EN 4096
@item
réinstaller tealc
@end itemize

@item Après
@itemize
@item
voir matrix
@item
rediscuter de mastodon
@item
Nix
@end itemize

@item Jamais
@itemize
@item
Constellation
@item
Ceph
@end itemize
@end table

@node How-Tos
@chapter 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 à @ref{CONTRIBUTING}.


@menu
* Changer de pseudo: Changer de pseudo.  @

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.

* Creer VM adherent: Creer VM adherent.  @

Comment faire pour créer une VM pour un⋅e adhérent⋅e.

* La suppression d'un⋅e utilisateurice::  @

Comment supprimer un⋅e utilisateur⋅rice ainsi que toutes ses données.

* Comment devenir nounou ?::    guide pour les nouvelles nounous !
@end menu

@node Changer de pseudo
@section 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.

@subsection 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 @code{yson-partou} pour
s'assurer que l'ancien compte a bien été supprimé. Pour cela, faire un
@code{sudo shelldap} sur @code{yson-partou}, puis taper
@code{cn=Utilisateurs} et s'assurer que @code{cat cn=ancienpseudo} ne
renvoie rien.

@subsection 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
@code{sudo mv /home/@{ancienpseudo,nouveaupseudo@}}, sinon avec l'accord
de la personne on peut faire un @code{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 @file{/var/mail/ancienpseudo} en
@file{/var/mail/nouveaupseudo}, ou déplacer le contenu et supprimer
l'ancien dossier.

@subsection Backups

Étape non pressante, mais on peut se rendre sur @code{backup-ft} et
@code{backup-thot} pour déplacer
@file{/backup/borg-adh/home/ancienpseudo} en
@file{/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.

@subsection 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 : @url{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.

@subsection 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 :
@url{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é.

@subsection Mailman

On commence par se rendre dans @url{https://lists.crans.org/admin/,
Django-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.

@subsection Wiki

Si la connexion par le CAS est configurée, il faut penser à @code{mv
/var/local/wiki/assowiki/@{ancienpseudo,nouveaupseudo@}}. Concerne a
priori peu de monde.

@subsection The Lounge

Si on tient à ne pas perdre sa connexion WebIRC (si concernée), on peut
aller sur Zamok et @code{mv
/etc/thelounge/users/@{ancienpseudo,nouveaupseudo@}.json} Il y a aussi
des fichiers de d'historiques des messages que l'on peut supprimer
@code{rm /etc/thelounge/logs/@{pseudo@}} et @code{rm
/etc/thelounge/logs/@{pseudo@}.sqlite3} ou remommer.

@node Creer VM adherent
@section 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.

@multitable @columnfractions .5 .5
@headitem Article @tab Tarifs
@item
Service minimal
@tab 10€
@item
Connexion Internet
@tab 30€
@item
Cœeur additionnel
@tab 5€
@item
2GB de RAM additionnel
@tab 5€
@item
Disque additionnel (par tranche de 16G)
@tab 1€
@end multitable

Le service minimal comprend :
@itemize
@item
n disque de 8H
@item
un cœur
@item
2G de ram
@end itemize

Tous les services sont proposés pour une durée de 1 an.

@subsection Utilisateur⋅ices

La documentation pour les utilisateur⋅ices se trouvent sur le
@url{https://wiki.crans.org/VieCrans/VPS, wiki}.

@subsection Nounous et apprenti⋅es

@subsubsection 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, @dots{}).

@subsubsection 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 :

@verbatim
ou=users
├── cn=toto
└── cn=titi
ou=clubs
└── o=rover
ou=hosts
├── cn=voyager
└── cn=curiosity
@end verbatim

Pour référence ma configuration @code{shelldap} pour me connecter au
ldap est la suivante :

@verbatim
# +---------------------------------+
# | 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
@end verbatim

et le mot de passe est disponible dans le password-store sous
@code{ldap-adh}.

@subsubsection Utilisateur⋅ices

Les objets utilisateur⋅ices dispose des champs suivants :

@verbatim
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$…
@end verbatim

Le script @code{addadherent} du repo
@url{https://gitlab.crans.org/nounous/crans-ldap, crans-ldap} permet
néanmoins de configurer la plupart des informations à renseigner :

@verbatim
[ _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
@end verbatim

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.

@subsubsection 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 :

@verbatim
dn: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
objectClass: organization
objectClass: top
description: toto
o: rover
@end verbatim

Similairement, un script permet de rajouter ces informations
automatiquement au ldap :

@verbatim
[ _shirenn@flirt ]$ ./addclub rover
Pseudo du responsable: toto
Pseudo du responsable: titi
Pseudo du responsable:
@end verbatim

@subsubsection Machines

Les machines sont des objets ldap qui répertorient des informations sur
leur configuration et leurs propriétaires :

@verbatim
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
@end verbatim

Le script @code{addadherenthost} crée la machine dans le ldap

@verbatim
[ _shirenn@flirt ]$ ./addadherenthost --ip 185.230.78.199 --mac
02:a0:00:01:99:02 --vmid 199 --club rover curiosity
@end verbatim


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.

@subsubsection 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 @code{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 @file{/root/.ssh/authorized_keys}
(en faisant attention à créer le @file{.ssh} avec les bonnes permissions
@code{mkdir -m 0700 /root/.ssh}) et vous supprimez les mots de passe que
vous avez rentrer pendant l'installation @code{passwd -d root}).

@node La suppression d'un⋅e utilisateurice
@section 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
@url{https://www.cnil.fr/fr/reglement-europeen-protection-donnees/,
RGPD}. 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.

@subsection 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@dots{}). 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@dots{} 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@dots{}). Si la personne est
encore adhérente, elle va probablement devoir démissionner de
l'association.

@subsection Re2o

Il faut bien un début, c'est sur l'intranet qu'on commence par
supprimer/archiver quelqu'un⋅e.

@subsubsection 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@dots{}) 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).

@subsubsection Supprimer sur Re2o

Il faut aller dans l'interface d'administration
@url{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 @code{yson-partou} pour
s'assurer que le compte a bien été supprimé. Pour cela, faire un
@code{sudo shelldap} sur @code{yson-partou}, puis taper
@code{cn=Utilisateurs} et s'assurer que @code{cat cn=@{pseudo@}} ne
renvoie rien.

@subsection Zamok

Le plus évident, il faut supprimer le home ainsi que les mails.

Il suffit de faire un @code{sudo rm -rf /home/@{pseudo@}}, pour
supprimer le home. De même pour les mails dans
@file{/var/mail/@{pseudo@}}.

@subsection Backups

Étape non pressante, mais on peut se rendre sur @code{backup-ft} et
@code{backup-thot} pour supprimer
@file{/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).

@subsection 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 : @url{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).

@subsection Owncloud

Il suffit simplement de se rendre dans l'interface d'administration,
section utilisateurices :
@url{https://owncloud.crans.org/settings/users}, puis de chercher le
compte et de simplement le supprimer.

@subsection Mailman

On commence par se rendre dans @url{https://lists.crans.org/admin/,
Django-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 @email{root@@crans.org} le propriétaire par
défaut, ce qui n'est pas une solution durable).

@subsection Wiki

Si la connexion par le CAS est configurée, il faut penser à @code{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@dots{}), historique
compris. Pour cela il faut aller sur @code{kiwi} et supprimer le dossier
contenant la page. Cela peut concerner des personnes n'ayant pas de
compte crans, mais il faudra le WikiNom.

@subsubsection The Lounge

S’il y a eu une utilisation de WebIRC, on peut aller sur Zamok et
@code{rm /etc/thelounge/users/@{pseudo@}.json} (configuration), @code{rm
/etc/thelounge/logs/@{pseudo@}} et @code{rm
/etc/thelounge/logs/@{pseudo@}.sqlite3} (pour l'historique des
messages).

@subsubsection 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).

@subsubsection 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@dots{}) qui peuvent contenir des données personnelles. La personne
devra aller voir les admins de ces services pour supprimer les données.

@node Comment devenir nounou ?
@section 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 @b{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) :

@verbatim
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.
@end verbatim


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. @emph{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) ?

@subsection 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 (@pxref{LDAP}).

@subsection Give me the password

Vous avez @b{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:

@enumerate
@item
On se souvient du hash de commit courant : @code{HASH=$(git rev-parse
HEAD)}
@item
On ajoute toutes les personnes concernées dans le groupe nounou dans le
fichier @file{.groups.yml} du store et on commit ces changements
@code{git commit -m toto1234}.
@item
On rechiffre tous les fichiers à rechiffrer @code{cat .last_group.json |
jq -r '. | with_entries( select(.value | any( .== "nounou"))) | keys[]'
| xargs pass rans reencrypt}
@item
On supprime tous les commits inutiles : @code{git reset --soft $HASH;
git commit -m 'Coucou les ami⋅es'}
@item
On vérifie que ça marche et on push :)
@end enumerate

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

@subsection Thank you for your services

Au Crans on a @b{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.

@subsubsection 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.

@subsubsection Mailman

Il faut se connecter normalement au logiciel, puis allez dans la section
admin @url{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).

@subsubsection Owncloud

Il faut aller dans la zone d'administration et rajouter les
utilisateur⋅ices au groupe d'administration.

@subsubsection 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.

@subsubsection Kiwi

On édite le fichier de conf du wiki sous @file{/etc/moin/mywiki.py} et
on rajoute son compte wiki dans la liste des administrateur⋅rices.

@subsubsection IRC

On édite le fichier @file{/etc/inspircd/opers.conf} pour rajouter un
bloc suivant

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


Où le hash du mot de passe peut être obtenu en envoyant @code{/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 ^^).

@subsubsection Mails

Il faut maintenant vous rajouter en alias de
@email{root@@crans.org}. C'est le début du spam. Pour ce faire,
rendez-vous sur le dépôt Gitlab @code{mail-aliases}, et ajoutez votre
pseudo Crans sur la bonne ligne dans les bons fichiers, en face de
@code{root:}.  Pensez ensuite à mettre à jour le dépôt pour le service
@code{mail}, et enfin mettez bien à jour @code{redisdead},
@code{sputnik} et surtout @code{zamok} dans le dossier
@file{/var/local/services/mail}. Enfin, pensez bien à filtrer les mails
arrivant à l'adresse @email{root@@crans.org} sur votre client.

Voilà, tu as maintenant gagné le droit de t'ajouter ou de te retirer de
@url{<https://wiki.crans.org/CransNounous} !

@node CONTRIBUTING
@chapter Contributing

TODO.

@node Tools
@chapter Tools

@menu
* Logiciels::
* OS::
* Protocoles::
@end menu

@node Logiciels
@section 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.

@menu
* APT::
* GPG::
* SSH::
* ZFS::
* Systemd::
@end menu

@node APT
@subsection APT

APT (pour Advanced Package Tool) est un des gestionnaires de paquets de
@uref{https://www.debian.org/,Debian}. Il dispose d'une interface en
CLI, voici quelques exemples de commandes :

@multitable @columnfractions .5 .5
@headitem commande @tab description
@item @code{apt install package}
@tab Installe @code{package}
@item @code{apt search package}
@tab Recherche @code{package}
@item @code{apt list}
@tab Liste les paquets
@item @code{apt list --installed}
@tab Liste les paquets installés
@item @code{apt remove package}
@tab Désinstalle @code{package}, sans supprimer sa configuration
@item @code{apt purge package}
@tab Purge @code{package}, @i{i.e.}@: désinstalle et supprime sa
configuration
@item @code{apt depends package}
@tab Liste les dépendances de @code{package}
@item @code{apt rdepends package}
@tab Liste les paquets dépendants de @code{package}
@item @code{apt policy package}
@tab Affiche les informations de priorité pour @code{package}
@item @code{apt show package}
@tab Affiche les informations de @code{package}
@item @code{apt update}
@tab Met à jour les listes de paquets
@item @code{apt upgrade}
@tab Met à jour les paquets
@end multitable

Un paquet Debian va placer des fichiers dans @file{/bin/}, @file{/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.

@subsubsection 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 @file{/etc/apt/source.list} et
dans le dossier @file{/etc/apt/source.list.d/}. Un système Debian
classique au Crans devrait avoir les sources suivantes :

@verbatim
# 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
@end verbatim

Si on souhaite également synchroniser la liste des sources de paquets
pour potentiellement les reconstruire, on peut dupliquer chaque ligne en
substituant @code{deb} par @code{deb-src}.

@subsubsection Vérifier l'état de santé des paquets systèmes Debian

Debian fournit un outil nommé @code{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 :
@code{debsums -ce}.

@node GPG
@subsection GPG

TODO.

@node SSH
@subsection SSH

TODO.

@node ZFS
@subsection ZFS

TODO.

@node Systemd
@subsection Systemd

TODO.

@node OS
@section OS

@node Protocoles
@section Protocoles

@menu
* LDAP::
@end menu

@node LDAP
@subsection LDAP

TODO.

@node Index
@unnumbered Index

@printindex cp

@bye

@c  LocalWords:  Guix