texinfo: remove translated MD files.
Arnaud Daby-Seesaram
parent
fa21704515
commit
293e6e1eff
|
|
@ -1,91 +0,0 @@
|
|||
# Réunion IN
|
||||
|
||||
* Date : Samedi 13 Janvier 2024
|
||||
* Lieu : MB87 et Galène (<https://galene.crans.org/group/IN>)
|
||||
* Début : 13h32
|
||||
* Fin : 15h32
|
||||
|
||||
## Présent⋅es
|
||||
|
||||
* [bleizi](https://wiki.crans.org/WikiBleizi)
|
||||
* [Pigeon Moelleux](https://wiki.crans.org/WikiPigeonMoelleux)
|
||||
* GaBo
|
||||
* [vanille](https://wiki.crans.org/VanilleNiven)
|
||||
* [Otthorn](https://wiki.crans.org/SolalNathan)
|
||||
* [Hachino](https://wiki.crans.org/WikiHachino)
|
||||
* [esum](https://wiki.crans.org/Esum)
|
||||
* Korenst1
|
||||
* shirenn
|
||||
* Floflo
|
||||
* RDB
|
||||
* lzebulon
|
||||
* [Aplanos](https://wiki.crans.org/WikiAplanos)
|
||||
* Abidos
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
* Présentation SRS et fix `mailman` (spam, SPF, comptes bizarres)
|
||||
* Point sur les DistUpgrades des VM
|
||||
* Discussions avec la DSI (imprimante, eduroam, radius dans les locaux
|
||||
associatifs)
|
||||
* État de la DGNum (Crans à Ulm)
|
||||
* Autres remarques diverses
|
||||
|
||||
### Guix
|
||||
|
||||
Le conseil technique s'est prononcé lors d'une séance précédente contre la
|
||||
mise en place de test Guix et a approuvé uniquement le fait de tester Nix. Les
|
||||
tests d'intégration Guix de l'infrastructure du Crans sont de facto une perte
|
||||
de temps et devraient être interrompus.
|
||||
|
||||
### Désinscription mailing lists
|
||||
|
||||
Un email de plainte a levé des doutes sur le bon fonctionnement du mécanisme
|
||||
de désinscription de `lists.crans.org`. Des tests ont été réalisés en
|
||||
direct par un membre et ont confirmé que l'échec de la procédure n'est pas
|
||||
de la faute du Crans.
|
||||
|
||||
## SRS
|
||||
|
||||
`shirenn` a présenté la motivation et le fonctionnement de
|
||||
[SRS](https://en.wikipedia.org/wiki/Sender_Rewriting_Scheme) pour nos
|
||||
redirections de mails. Il a été identifié en direct que cela est lié
|
||||
directement aux problèmes récents de surabondance d'emails "Successful Mail
|
||||
Delivery Report" sur `root@crans.org` lorsqu'un accusé de réception est
|
||||
demandé.
|
||||
|
||||
Étant donné l'importance de ne pas perdre d'emails et la relative fragilité
|
||||
du système il est décidé de ne pas immédiatement supprimer ces reports,
|
||||
mais lorsque nous serons plus certains de la robustesse de SRS nous
|
||||
envisagerons de retirer `root` des récipients.
|
||||
|
||||
## Mailman
|
||||
|
||||
Nous observons des mails acceptés qui ne sont visiblement pas conformes à la
|
||||
whitelist mise en place. L'abondance de problèmes avec mailman en général
|
||||
nous mène à envisager la migration à [sympa](https://www.sympa.community/).
|
||||
|
||||
Cela pourra faire l'objet d'un projet apprentis, pour lequel lzebulon, RDB,
|
||||
Korenst1 et GaBo se disent motivés.
|
||||
|
||||
## DU (distrib upgrade)
|
||||
|
||||
Tout casse à chaque fois qu'on DU un serveur.
|
||||
On va passer soon^{TM} sur NixOS.
|
||||
|
||||
## DSI: eduroam
|
||||
|
||||
La DSI a accepté de mettre à jour une pratique obsolète concernant la
|
||||
connexion au wifi eduroam dans l'enceinte de l'ENS Paris-Saclay qui empêchait
|
||||
auparavant la connexion aux élèves de l'ENSAE. L'accès est rétabli.
|
||||
|
||||
## DSI: wifi Crans
|
||||
|
||||
Pascal -- membre de la DSI de l'ENS Paris-Saclay -- est maintenant un contact
|
||||
du Crans. Cela nous donne l'opportunité de ressusciter le projet de wifi Crans
|
||||
dans l'ENS, sans toutefois être une priorité.
|
||||
|
||||
Il sera important de contacter Aurore au préalable pour distuter du volume que
|
||||
l'association peut gérer.
|
||||
|
||||
Sur le plan technique, OpenRadius est envisagé.
|
||||
|
|
@ -1,86 +0,0 @@
|
|||
# Réunion IN
|
||||
|
||||
* Date : Samedi 22 Juin 2024
|
||||
* Lieu : MB87 et Galène (https://galene.crans.org/group/CA)
|
||||
* Début : 14h23 - reprise à 15h20
|
||||
* Fin : 16h07
|
||||
|
||||
## Présent⋅es
|
||||
|
||||
* GaBo
|
||||
* [Chiaroush](https://wiki.crans.org/WikiChiaroush)
|
||||
* [vanille](https://wiki.crans.org/VanilleNiven)
|
||||
* lzebulon
|
||||
* Otthorn
|
||||
* [RDB](https://wiki.crans.org/WikiRDB)
|
||||
* [bleizi](https://wiki.crans.org/WikiBleizi)
|
||||
* [Aplanos](https://wiki.crans.org/WikiAplanos)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
* Clé usb d’installation de 128go avec ventoy ou équivalent pour les installations
|
||||
* commande des disques (si pas fait d’ici là, rappeler GaBo) (ou le faire en live)
|
||||
* [GaBo] Ansible est trop vieux (drop de support de certain plugin, peut pas relancer les playbooks. Marche encore avec ansible_2_14)
|
||||
* [Otthorn] ssh -L 1636:tealc.adm.crans.org:636 tealc.adm.crans.org pas le bon LDAP, faut utiliser wall-e
|
||||
* [Otthorn] Action deny sur WikiMoinMoin
|
||||
* [Lzebulon] Point sur les backups : ne semble pas fonctionner (backup-{thot,ft} non contactable)
|
||||
* VM Collabora
|
||||
* [Gabo] Ecriture du guide pour faire des VM dans la documentation
|
||||
* Owncloud : soucis de LDAP
|
||||
* Gitlab : à mettre à jour au plus vite (on est en 16.1)
|
||||
|
||||
### Clé USB d'installation 128 go Ventoy
|
||||
|
||||
(En référence à une conversation du 16 Mai 2024)
|
||||
Une seule clé avec plusieurs ISO plutôt que clés nombreuses avec distros différents -> Problèmes de sécurité, mais intéressant pour les nounous
|
||||
Le logiciel proposé (Ventoy) est plutôt répandu/réputé mais pas terrible. Problèmes de sécurité entre-autre.
|
||||
On propose de faire minimaliste sans utiliser le logiciel Ventoy. Ce serait intéressant parce que ça nous épargnerait le trousseau de clés (qui a été perdu il paraît), à discuter au prochain CA.
|
||||
GaBo propose de partir sur 5 clés de 128 go -> 1 clé / Nounous présentes sur le plateau.
|
||||
GaBo propose 64 go. 128 go lui paraît overkill. Pas de différence trop grande en terme de prix -> On part sur du 128 go.
|
||||
En Install Party, on fait rarement plus de 5 installs en parallèle.
|
||||
(Prendre en compte qu'il y a toujours une clé qui est perdue...)
|
||||
|
||||
Projet apprenti rigolo de créer un script qui génère les clés (mettre tel OS sur une clé).
|
||||
|
||||
|
||||
### Commande des disques
|
||||
|
||||
Les disques sont commandés et arrivés !
|
||||
Il reste les ventilos.
|
||||
GaBo a payé avec sa carte, il attend le remboursement de la part du Trésorier (Macéo) pour procéder à l'achat des ventilos.
|
||||
|
||||
Avons-nous prévu un moment pour installer les nouveaux disques ? <- On en a discuté dans le point disques du CA.
|
||||
|
||||
|
||||
### Ansible
|
||||
|
||||
On a plein de version de retard (on est en 2.14 et la version actuelle est la 10).
|
||||
https://endoflife.date/ansible
|
||||
Il faudrais mette ça à jour : plugin LDAP et README en particulier et peut-être le plugin pass. On eput essayer de faire en même temps que l'install de Colabora
|
||||
|
||||
### WikiMoinMoin
|
||||
|
||||
On a des soucis avec l'action "deny" qui ne permettait de voir une page privée. Otthorn a fait un proof au concept de l'erreur. Il a réactivé deny, c'est bon. Mais on sait pas pourquoi ça avit été désactivé il y a longtemps.
|
||||
|
||||
### Backups
|
||||
|
||||
Faut se bouger pour aller voir VR en vrai à une de leurs permanences. C'est peut-être juste l'ethernet qui est débranchée. (Et potentiellement aussi changer pour un cable qui fonctionne)
|
||||
|
||||
Faire les backups correctement (comme l’a indiqué Otthorn, en excluant les trucs reliés à postgress et utilisé le hook conçu pour)
|
||||
voir dans la config ansible
|
||||
|
||||
### Colabora
|
||||
|
||||
(Pigeon : Si vous arrivez à setup colabora hésitez pas, onlyoffice c'est chiant je comprends rien à comment ça fonctionne)
|
||||
|
||||
### Owncloud
|
||||
|
||||
La config a disparu par magie (À enquêter)
|
||||
|
||||
### GitLab
|
||||
|
||||
Il faut mettre à jour. (On le fera vers juste après l’IN)
|
||||
|
||||
### Documentation
|
||||
|
||||
GaBo a été désigné grand gagnant de qui s'occupera de la documentation d'Ansible.
|
||||
|
|
@ -1,166 +0,0 @@
|
|||
# Réunion IN
|
||||
|
||||
* Date : Jeudi 29 Août 2024
|
||||
* Lieu : MB87 et Galène (https://galene.crans.org/group/CA)
|
||||
* Début : 18h58
|
||||
* Fin : 21h
|
||||
|
||||
## Présent⋅es
|
||||
|
||||
* [bleizi](https://wiki.crans.org/WikiBleizi)
|
||||
* [Pigeon Moelleux](https://wiki.crans.org/WikiPigeonMoelleux)
|
||||
* GaBo
|
||||
* [vanille](https://wiki.crans.org/VanilleNiven)
|
||||
* korenst1
|
||||
* Lzebulon
|
||||
* Shinigami
|
||||
* [Hachino](https://wiki.crans.org/WikiHachino)
|
||||
* underscore_j
|
||||
* RDB
|
||||
* Otthorn
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Rapide compte-rendu de ce qu'il s'est passé cet été
|
||||
Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de mauvaises configurations
|
||||
problème entre ansible et les scripts qui sont dépréciés.
|
||||
|
||||
Mise à jour de gitlab
|
||||
|
||||
Au milieu de l'été. pb entre owncloud et nextcloud. impossibilité d'écrire (indépendant du reste). esum a résolu le pb. Owncloud a ensuite perdu sa conf ldap.
|
||||
Nextcloud a fini d'être configuré (paramêtre de partage et les mails (envoi de mail automatique pour les événements)). Nextcloud marche bien.
|
||||
Pub pour nextcloud possible.
|
||||
|
||||
pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé dans apt. Pas possible d'installer onlyoffice comme ça. On doit le faire à la main. Donc ce n'est pas ansibelisable.
|
||||
Il n'est pas possible d'utiliser onlyoffice sur téléphone (firefox) et limité à 20 connexions en même temps. du coup, est-ce qu'on utilise Collabora ou Onlyoffice ?
|
||||
|
||||
Du coup on peut passer sur collabora qui n'a pas ces problèmes.
|
||||
Sinon Otthorn a trouvé la variable à modifier.
|
||||
|
||||
```
|
||||
server/Common/sources/constant.js
|
||||
exports.LICENSE_CONNECTIONS = 20;
|
||||
```
|
||||
|
||||
### état sur les serveurs de backup
|
||||
2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais il marche et permet de faire
|
||||
Peut-être la poussière ou les ventilos sont cassés. Bref, il faudra probablement faire qch.
|
||||
On ne sait pas si l'ilo marche. Mais il est possible de relancer les backups.
|
||||
|
||||
specs du serveurs chez viarezo : https://wiki.crans.org/CransNostalgie/CransTechnique/LesServeurs/ServeurFt
|
||||
|
||||
Pour thot : le serveur s'éteint spontanément après le démarrage. c'est probablement à cause de la sonde de température
|
||||
|
||||
On remet ft puis on réinstalle thot
|
||||
|
||||
Il existe plus simple que borg. Est-ce qu'on ne passerait pas sur truc plus récent. mais on garde borg pour le moment. Sinon on peut utiliser restic.
|
||||
|
||||
On s'assure que ft remarche avant de faire thot (moins urgent)
|
||||
|
||||
Pigeon : "IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP"
|
||||
|
||||
Tealc : on n'arrive pas à ajouter les disques donc pk on y arriverait avec thot ?
|
||||
|
||||
|
||||
|
||||
Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu de membre actif chez eux.
|
||||
|
||||
Chez Tuxae ? -> c'est possible on a l'accord du président.
|
||||
|
||||
Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer pour récupérer les données.
|
||||
|
||||
ft urgent et une fois fonctionnel, on commence sur thot. On peut aussi chiffrer les disques nativement avec zfs.
|
||||
|
||||
### Cephiroth
|
||||
Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux).
|
||||
|
||||
### Serveur matrix
|
||||
De plus en plus de demande pour avoir une alternative libre à discord, whatsapp....
|
||||
|
||||
|
||||
Mastodon -> pas adapté
|
||||
Zulipe -> pas adapté
|
||||
Mattermost -> pas adapté
|
||||
Matrix -> faire de la pédagogie. Pas le temps de faire le support technique ? Il est possible de faire des vocaux. Il faut présenter ça aux gens mais iels auront besoin d'une passphrase et ou une clef de récupération.
|
||||
|
||||
Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais est-ce que le serveur est possible de gérer plus de connexions.
|
||||
En principal, obligation de mettre le ldap du crans. Possibilité d'utiliser la note via Oauth...
|
||||
Les alias ça change. On doit conserver le pk. Potentiellement, on peut ajouter un préfix (genre "note_").
|
||||
|
||||
Ou alors, 2 instances de matrix, une pour chaque ldap. L'une est au bde mais le crans s'en occupe.
|
||||
Migrer SQLite à PostgreSQL.
|
||||
Si on migre le bde, il faut que se soit très stable.
|
||||
Est-ce qu'il est possible d'avoir de la redondance sur le serveur matrix ? a priori oui... mais peut-être pas intégrer pas défaut à matrix.
|
||||
matrix.crans.org juste un relai (bridge irc/matrix) pour la réinstallation, il faut demander à Erdnaxe.
|
||||
|
||||
On garde le serveur matrix tel quel (quitte à augmenter les perfs). migre de SQLite à PostgreSQL. LDAP crans en priorité.
|
||||
On met element
|
||||
chat.crans.org (facile à retenir)
|
||||
FAIRE DE LA PUB !
|
||||
|
||||
5 secondes sur Mastodon selon pigeon (c'est (déjà) perdu) mais moi je pense que la vérité est toute autre...
|
||||
Retirer la condition "cephirot.date < mastodon.date".
|
||||
Ajouter l'affirmation "Constellation.state == Cephiroth.state"
|
||||
|
||||
### Reprise des séminaires hebdomadaires
|
||||
|
||||
On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire ce point moulte années plutard !))
|
||||
|
||||
### état de l'imprimante
|
||||
|
||||
bref : ça marche pas
|
||||
|
||||
L'imprimante a été déplacée mais impossible de communiquer avec l'imprimante.
|
||||
Il faudra se poser avec des personnes de la DSI pour résoudre le pb. Mais dire ce qu'on a fait, il est possible que ça avance.
|
||||
pigeon pense pouvoir s'en charger mais il ne connait pas ce qu'il y a autour de l'imprimante.
|
||||
|
||||
On essaie de s'en occuper assez rapidement (bleizi et pigeonmoelleux)
|
||||
|
||||
### mettre les clés gpg dans le pass
|
||||
pb de rétention des clefs gpg. pigeon a "pillé" à bleizi les clefs.
|
||||
potentiellement signer les clefs gpg des nounous.
|
||||
|
||||
Remettre de l'ordre dans le pass. thot renommé en surface sans raison (a priori).
|
||||
|
||||
Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou autre...
|
||||
Sinon, demander aux vielles nounous (peb, pollion) si iels veulent garder leurs droits nounous (ça ressemble à une invitation à partir...).
|
||||
Pour les autres, on propose de rajouter les clefs gpg dans le pass.
|
||||
|
||||
### Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin
|
||||
Près de 400 jours qu'il tourne. (pas de coupure estivale).
|
||||
Pas possible de la faire avant les prochaines vacances. En profiter pour refaire le cablage.
|
||||
Une réunion de préparation de la réparation.
|
||||
(redémarrage et brassage)-> prochain IN
|
||||
|
||||
### Chronolgie TODO list
|
||||
|
||||
Très urgent :
|
||||
- Backup ft (commencé à faire les backup)
|
||||
- 1/2 qui non important (genre voyager et helloworld)
|
||||
- par ordre d'importance (genre mailman)
|
||||
- d'ici là samedi rangement, inté, séminaires
|
||||
- Cephiroth (garantie go GaBo)
|
||||
- puis on s'occupe de thot
|
||||
|
||||
on est déjà dans qq semaines :
|
||||
- onlyoffice (la limite)
|
||||
- bleizi, pigeon -> imprimante
|
||||
- les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent rester nounous)
|
||||
- enlever les vielles nounous (charlie, peb ? et pollion ?)
|
||||
|
||||
Le mois prochain :
|
||||
- prévénir tout le monde que les serveurs du crans sont down
|
||||
- Backup tealc sur zéphir/cameron
|
||||
- inventaire et commander des disques d'avances (un disque en rab compatible pour chacun des serveurs)
|
||||
- coupure : recabler, (vérifier l'étiqueteuse)
|
||||
- PASSER LA POOL EN 4096
|
||||
- réinstaller tealc
|
||||
|
||||
Après :
|
||||
- voir matrix
|
||||
- rediscuter de mastodon
|
||||
- Nix
|
||||
|
||||
Jamais :
|
||||
- Constellation
|
||||
- Ceph
|
||||
|
|
@ -1,20 +0,0 @@
|
|||
# Comptes-rendus
|
||||
|
||||
## Présentation
|
||||
|
||||
Ce dossier contient l'ensemble des comptes-rendus des IN.
|
||||
|
||||
Les IN, ou Inter-Nounous, sont les réunions techniques des membres
|
||||
actifs⋅ves du Crans. Celle-ci sont publiques et sont organisées tous les
|
||||
mois. Celles-ci sont annoncées sur IRC et sur les ML
|
||||
apprenti-es@lists.crans.org et nounou@crans.org.
|
||||
|
||||
## Organisation
|
||||
|
||||
Chaque fichier de ce dossier est le compte-rendu d'une réunion technique. Vous
|
||||
pouvez trouver un template de compte-rendu dans le fichier
|
||||
[`TEMPLATE.md`](TEMPLATE.md) si nécessaire. La seule contrainte pour ce
|
||||
dossier est le nom des fichiers. Les comptes-rendus sont identifiés par la
|
||||
date de la réunion : pour une réunion du JJ/MM/AAAA, le fichier devra se
|
||||
nommer `AAAA_MM_JJ.md` (et non `JJ_MM_AAAA.md` car le tri par date se fait plus
|
||||
simplement).
|
||||
|
|
@ -1,34 +0,0 @@
|
|||
# Réunion IN
|
||||
|
||||
* Date :
|
||||
* Lieu(x) :
|
||||
* Heure de début :
|
||||
* Heure de fin :
|
||||
|
||||
## Présent⋅es
|
||||
|
||||
* [Nounou 1](https://wiki.crans.org/CransNounous)
|
||||
* [Apprentie 1](https://wiki.crans.org/CransTechnique/CransApprentis)
|
||||
* [Apprenti 2](https://wiki.crans.org/CransTechnique/CransApprentis)
|
||||
* [Nounou 2](https://wiki.crans.org/CransNounous)
|
||||
* Personne sans page wiki
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
* [Nounou 1] Point 1
|
||||
* [Nounou 2] Point 2
|
||||
* Sous-point 1
|
||||
* Sous-point 2
|
||||
* [Apprentie 1] Point 3
|
||||
* [Nounou 1] Point 4
|
||||
* [Apprenti 2] Point 5
|
||||
|
||||
### Point 1
|
||||
|
||||
Détails et résumé des discussions du point 1
|
||||
|
||||
### Point 2
|
||||
|
||||
Détails et résumé des discussions du point 2
|
||||
|
||||
...
|
||||
|
|
@ -1,24 +0,0 @@
|
|||
# How To : les tutos techniques
|
||||
|
||||
## Présentation
|
||||
|
||||
Ce dossier contient les "how to" (tutoriels) du Crans concernant des tâches
|
||||
techniques demandant des connaissances généralement sur plusieurs parties de
|
||||
l'infrastructure.
|
||||
|
||||
Si vous souhaitez que d'autres soient ajoutés, n'hésitez pas à vous
|
||||
réferrer [au CONTRIBUTING.md](../CONTRIBUTING.md).
|
||||
|
||||
## Organisation
|
||||
|
||||
* [Changer de pseudo](changer_de_pseudo.md) : comment faire pour changer le
|
||||
nom d'utilisateur (pseudonyme) d'un⋅e utilisateur⋅rice. Cela peut être
|
||||
utile par exemple lors d'un changement d'état civil.
|
||||
|
||||
* [Créer une VM pour les adhérent⋅es](creer_vm_adherent.md) : comment
|
||||
faire pour créer une VM pour un⋅e adhérent⋅e.
|
||||
|
||||
* [Devenir nounou](devenir_nounou.md) : guide pour les nouvelles nounous !
|
||||
|
||||
* [Supprimer un⋅e utilisateur⋅rice](supprimet_utilisateur.md) : comment
|
||||
supprimer un⋅e utilisateur⋅rice ainsi que toutes ses données.
|
||||
|
|
@ -1,108 +0,0 @@
|
|||
# Changement de pseudo
|
||||
|
||||
Le pseudo est l'identifiant unique permettant de s'authentifier sur l'ensemble
|
||||
des services du Crans. Pour diverses raisons dont il n'est pas question de
|
||||
juger, un⋅e utilisateur⋅rice peut vouloir changer de pseudo. C'est pénible
|
||||
mais faisable : respecter la volonté de l'utilisateur⋅rice dans ce cas est
|
||||
important. Ce petit guide est là pour rappeler tout ce qu'il ne faut pas
|
||||
oublier.
|
||||
|
||||
## Re2o
|
||||
|
||||
Il faut bien un début, c'est sur l'intranet qu'on commence par renommer
|
||||
quelqu'un⋅e. Il suffit d'éditer le profil et de changer le pseudo.
|
||||
|
||||
Ne pas oublier d'aller contrôler le LDAP sur `yson-partou` pour s'assurer que
|
||||
l'ancien compte a bien été supprimé. Pour cela, faire un `sudo shelldap` sur
|
||||
`yson-partou`, puis taper `cn=Utilisateurs` et s'assurer que
|
||||
`cat cn=ancienpseudo` ne renvoie rien.
|
||||
|
||||
## Zamok
|
||||
|
||||
Le plus évident, il faut déplacer le home ainsi que les mails.
|
||||
|
||||
Si le pseudo vient à l'instant d'être modifié, il suffit de faire un
|
||||
`sudo mv /home/{ancienpseudo,nouveaupseudo}`, sinon avec l'accord de la
|
||||
personne on peut faire un `rsync -ar /home/{ancienpseudo,nouveaupseudo}/`, ce
|
||||
qui va copier le contenu de l'ancien home dans le nouveau, mais attention au
|
||||
remplacement de données. L'ancien home peut ensuite être supprimé.
|
||||
|
||||
De la même manière, il faut renommer `/var/mail/ancienpseudo`
|
||||
en`/var/mail/nouveaupseudo`, ou déplacer le contenu et supprimer l'ancien
|
||||
dossier.
|
||||
|
||||
## Backups
|
||||
|
||||
Étape non pressante, mais on peut se rendre sur `backup-ft` et `backup-thot`
|
||||
pour déplacer `/backup/borg-adh/home/ancienpseudo` en
|
||||
`/backup/borg-adh/home/nouveaupseudo`, si ce n'est pas trop tard. Si le nouveau
|
||||
dossier est déjà créé, alors on peut attendre quelques jours voire quelques
|
||||
mois au cas où pour supprimer l'ancien dossier inutile.
|
||||
|
||||
À faire avec précaution. Mais à faire puisqu'on ne garde pas des backups
|
||||
éternellement. Pas pour des raisons de place mais pour des raisons de
|
||||
non-conservation de données personnelles.
|
||||
|
||||
## Gitlab
|
||||
|
||||
S'il n'y a pas d'ancien compte, il n'y a rien à faire.
|
||||
|
||||
S'il y a un ancien compte ET un nouveau compte, c'est pénible. Il faut
|
||||
transférer les appartenances de projet d'un compte à l'autre. Ce cas ne
|
||||
s'étant pour l'instant pas présenté, il sera à détailler à terme.
|
||||
|
||||
On se place dans l'hypothèse où l'on veut renommer un ancien compte. On
|
||||
commence par se rendre dans l'interface d'administration de Gitlab, section
|
||||
utilisateurs :
|
||||
[https://gitlab.crans.org/admin/users](https://gitlab.crans.org/admin/users).
|
||||
|
||||
Si la personne s'est reconnectée avec son nouveau pseudo SANS AUCUNE
|
||||
CONTRIBUTION, alors on peut supprimer librement ce nouveau compte. On se rend
|
||||
ensuite dans les paramètres de l'ancien compte, on clique sur « Éditer » et
|
||||
on remplace le pseudo. Inutile de remplacer nom et adresse mail, ces champs
|
||||
sont importés par LDAP.
|
||||
|
||||
Ensuite, on se rend dans l'onglet « Identités », et on met à jour
|
||||
l'identifiant LDAP. Normalement, la personne peut désormais se connecter en
|
||||
n'ayant perdu ni projets ni commits, et son adresse mail ainsi que son nom
|
||||
seront mis à jour à sa prochaine connexion.
|
||||
|
||||
## Owncloud
|
||||
|
||||
Deux cas à considérer : l'utilisateur⋅rice s'est servi⋅e des agendas
|
||||
Owncloud ou non. Dans le premier cas, c'est pénible et cette documentation
|
||||
sera mise à jour afin de détailler comment exporter et réimporter les
|
||||
calendriers.
|
||||
|
||||
Si l'utilisateurice n'a pas utilisé d'application externe et uniquement le
|
||||
téléversement de fichiers, il suffit simplement de se rendre dans l'interface
|
||||
d'administration, section utilisateur⋅rices :
|
||||
[https://owncloud.crans.org/settings/users](https://owncloud.crans.org/settings/users),
|
||||
puis de chercher l'ancien compte et de simplement le supprimer. Les données
|
||||
étant montées sur Zamok, seul le home local inutile sera supprimé.
|
||||
|
||||
## Mailman
|
||||
|
||||
On commence par se rendre dans [Django-Admin](https://lists.crans.org/admin/).
|
||||
|
||||
S'il n'y a pas d'ancien compte, aucune question à se poser.
|
||||
|
||||
S'il y a un nouveau compte inutile, on le supprime.
|
||||
|
||||
S'il n'y a pas de nouveau compte, on peut changer le pseudo Mailman si
|
||||
souhaité, mais l'important est surtout d'aller dans les connexions sociales et
|
||||
de changer le pseudo utilisé pour lier le compte Mailman.
|
||||
|
||||
## Wiki
|
||||
|
||||
Si la connexion par le CAS est configurée, il faut penser à
|
||||
`mv /var/local/wiki/assowiki/{ancienpseudo,nouveaupseudo}`. Concerne a priori
|
||||
peu de monde.
|
||||
|
||||
## The Lounge
|
||||
|
||||
Si on tient à ne pas perdre sa connexion WebIRC (si concernée), on peut aller
|
||||
sur Zamok et `mv /etc/thelounge/users/{ancienpseudo,nouveaupseudo}.json`. Il y
|
||||
a aussi des fichiers de d'historiques des messages que l'on peut supprimer
|
||||
`rm /etc/thelounge/logs/{pseudo}` et `rm /etc/thelounge/logs/{pseudo}.sqlite3`
|
||||
ou remommer.
|
||||
|
|
@ -1,185 +0,0 @@
|
|||
# Création de machine virtuelle pour les adhérent⋅es
|
||||
|
||||
Le crans propose un système de locations de vms dont vous pouvez retrouver les
|
||||
tarifs dans les annexes des statuts de l'association. En voici un
|
||||
récapitulatif ici, mais attention celui-ci peut ne pas être à jour et seul
|
||||
ce qui est marqué dans les statuts fait foi.
|
||||
|
||||
| Article | Tarifs |
|
||||
|:---------------------------------------:|:------:|
|
||||
| Service minimal | 10€ |
|
||||
| Connexion internet | 30€ |
|
||||
| Cœur additionnel | 5€ |
|
||||
| 2GB de RAM additionnel | 5€ |
|
||||
| Disque additionnel (par tranche de 16G) | 1€ |
|
||||
|
||||
Le service minimal comprend :
|
||||
|
||||
* un disque de 8G
|
||||
* un cœur
|
||||
* 2G de ram
|
||||
|
||||
Tous les services sont proposés pour une durée de 1 an.
|
||||
|
||||
## Utilisateur⋅ices
|
||||
|
||||
La documentation pour les utilisateur⋅ices se trouvent sur le
|
||||
[wiki](https://wiki.crans.org/VieCrans/VPS).
|
||||
|
||||
## Nounous et apprenti⋅es
|
||||
|
||||
### Facturation
|
||||
|
||||
Quand cela est possible, privilégier la note. Sinon, voir avec un⋅e
|
||||
trésorier⋅ère pour d'autres méthodes (espèces, virement, ...).
|
||||
|
||||
### LDAP
|
||||
|
||||
Quand un⋅e adhérent⋅e vous demande de lui créer une vm, il faut au
|
||||
préalable læ rajouter dans le ldap des adhérent⋅es (qui n'est pas le même
|
||||
que le ldap re2o).
|
||||
|
||||
Celui ci se situe sur flirt et à la structure suivante:
|
||||
|
||||
```txt
|
||||
ou=users
|
||||
├── cn=toto
|
||||
└── cn=titi
|
||||
ou=clubs
|
||||
└── o=rover
|
||||
ou=hosts
|
||||
├── cn=voyager
|
||||
└── cn=curiosity
|
||||
```
|
||||
|
||||
Pour référence ma configuration `shelldap` pour me connecter au ldap est la
|
||||
suivante :
|
||||
|
||||
```txt
|
||||
# +---------------------------------+
|
||||
# | Connexion à flirt.adm.crans.org |
|
||||
# +---------------------------------+
|
||||
server: ldaps://flirt.adm.crans.org/
|
||||
promptpass: yes
|
||||
binddn: cn=admin,dc=adh,dc=crans,dc=org
|
||||
basedn: dc=adh,dc=crans,dc=org
|
||||
```
|
||||
|
||||
et le mot de passe est disponible dans le password-store sous `ldap-adh`.
|
||||
|
||||
#### Utilisateur⋅ices
|
||||
|
||||
Les objets utilisateur⋅ices dispose des champs suivants :
|
||||
|
||||
```txt
|
||||
dn: cn=toto,ou=users,dc=adh,dc=crans,dc=org
|
||||
objectClass: inetOrgPerson
|
||||
objectClass: organizationalPerson
|
||||
objectClass: person
|
||||
objectClass: top
|
||||
cn: toto
|
||||
description: birthDate:1998-01-08
|
||||
description: birthLocation:Cachan
|
||||
description: membershipStart:20xx-xx-xx
|
||||
description: membershipEnd:20xx-xx-xx
|
||||
description: re2oId:xxxxx
|
||||
givenName: Toto
|
||||
mail: nobody [AT] crans [DOT] org
|
||||
postalAddress: 60 rue camille desmoulins, 94230, Cachan
|
||||
sn: Passoir
|
||||
telephoneNumber: +336xxxxxxxx
|
||||
userPassword: {CRYPT}$6$…
|
||||
```
|
||||
|
||||
Le script `addadherent` du repo
|
||||
[crans-ldap](https://gitlab.crans.org/nounous/crans-ldap) permet néanmoins de
|
||||
configurer la plupart des informations à renseigner :
|
||||
|
||||
```bash
|
||||
[ _shirenn@flirt ] $ ./addadherent --re2o-id xxxxx toto
|
||||
Prénom: Toto
|
||||
NOM: Passoir
|
||||
Adresse email: nobody [AT] crans [DOT] org
|
||||
Adresse: 60 avenue camille desmoulins, 94230, Cachan
|
||||
Numéro de téléphone: +33600000000
|
||||
Date de naissance (YYYY-MM-DD): 1998-01-08
|
||||
Lieu de naissance: Cachan
|
||||
```
|
||||
|
||||
Cela rajoutera automatiquement la date de début d'adhésion mais pas celle de
|
||||
fin d'adhésion, celle-ci doit être rajoutée à la main en utilisant votre
|
||||
client ldap favori.
|
||||
|
||||
#### Club
|
||||
|
||||
Les clubs sont des objets ldap très simple qui ne contiennent que le nom des
|
||||
adhérent⋅es qui gèrent le club :
|
||||
|
||||
```txt
|
||||
dn: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
|
||||
objectClass: organization
|
||||
objectClass: top
|
||||
description: toto
|
||||
o: rover
|
||||
```
|
||||
|
||||
Similairement, un script permet de rajouter ces informations automatiquement au
|
||||
ldap :
|
||||
|
||||
```txt
|
||||
[ _shirenn@flirt ]$ ./addclub rover
|
||||
Pseudo du responsable: toto
|
||||
Pseudo du responsable: titi
|
||||
Pseudo du responsable:
|
||||
```
|
||||
|
||||
#### Machines
|
||||
|
||||
Les machines sont des objets ldap qui répertorient des informations sur leur
|
||||
configuration et leurs propriétaires :
|
||||
|
||||
```txt
|
||||
dn: cn=curiosity,ou=hosts,dc=adh,dc=crans,dc=org
|
||||
objectClass: top
|
||||
objectClass: device
|
||||
objectClass: ipHost
|
||||
objectClass: ieee802Device
|
||||
cn: curiosity
|
||||
description: ip.icmp.in,ip.icmp.out,ip6.icmpv6.in,ip6.icmpv6.out,ip.tcp.out:0-65535,ip6.tcp.out:0-65535,ip.udp.out:0-65535,ip6.udp.out:0-65535,ip.tcp.in:22,ip6.tcp.in:22
|
||||
ipHostNumber: 185.230.78.199
|
||||
macAddress: 02:a0:00:01:99:12
|
||||
owner: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
|
||||
serialNumber: 199
|
||||
```
|
||||
|
||||
Le script `addadherenthost` crée la machine dans le ldap
|
||||
|
||||
```txt
|
||||
[ _shirenn@flirt ]$ ./addadherenthost --ip 185.230.78.199 --mac
|
||||
02:a0:00:01:99:02 --vmid 199 --club rover curiosity
|
||||
```
|
||||
|
||||
Le part-feu par défaut laisse passer tous les paquets icmp, tous les paquets en
|
||||
sortie et ne laisse rentrer que le port 22 en tcp, en ip legacy et en ipv6.
|
||||
|
||||
Une fois l'adhérent⋅e ou le club et la machine rajoutée dans le ldap. Les
|
||||
scripts devraient mettre à jour la configuration du parefeu, du dhcp et de
|
||||
proxmox.
|
||||
|
||||
### Proxmox
|
||||
|
||||
Il faut maintenant aller sur le cluster constitué de gulp, odlyd et stitch
|
||||
pour créer la machine virtuelle. C'est du clic clic dans proxmox, vous êtes
|
||||
assez grand⋅es pour savoir lire des menus. (Par contre faites bien attention
|
||||
à créer les disques sur la pool `vm`).
|
||||
|
||||
Ensuite, deux possibilités, soit l'adhérent⋅e vous a juste demandé de
|
||||
créer la machine virtuelle et à ce moment là c'est fini et iel peut aller la
|
||||
configurer seul⋅e (c.f. section suivante), soit iel vous a demandé si vous
|
||||
pouviez lui installer une distribution de son choix.
|
||||
|
||||
Vous pouvez alors lui demander une clé publique ssh, et après avoir installé
|
||||
la vm, vous la déposez dans `/root/.ssh/authorized_keys` (en faisant attention
|
||||
à créer le `.ssh` avec les bonnes permissions `mkdir -m 0700 /root/.ssh`) et
|
||||
vous supprimez les mots de passe que vous avez rentrer pendant l'installation
|
||||
`passwd -d root`).
|
||||
|
|
@ -1,173 +0,0 @@
|
|||
# Comment devenir nounou ?
|
||||
|
||||
Bonjour jeune apprenti⋅e, tu regardes sûrement avec des yeux pleins d'étoiles
|
||||
tes ainé⋅es qui actuellement disposent des droits suprêmes sur l'infrastructure
|
||||
du Crans. Ce petit document est là pour t'expliquer comment toi aussi un jour tu
|
||||
pourras devenir l'un⋅e d'elleux. Et quand il sera temps et que tu commenceras à
|
||||
t'encrouter, comment tu pourras rendre tes droits.
|
||||
|
||||
Déjà commençons par une question un peu conne mais néanmoins légitime « Qui
|
||||
"mérite" d'être nounou ? » Premièrement, devenir nounou **N'EST PAS** une
|
||||
question de compétence. Pas besoin de connaître l'infrastructure par cœur, tous
|
||||
les fichiers de conf, être un pro d'apt, d'ansible et de la couche 2. Tout ce
|
||||
qu'on attend d'une nouvelle nounou c'est d'être capable de ne pas faire
|
||||
n'importe quoi avec ces droits. Devenir nounou ce n'est pas avoir fini son
|
||||
apprentissage mais bien la deuxième étape de celui-ci où on commence à mettre
|
||||
les mains dans le camboui. Et ça ça présuppose seulement qu'on va pas causer du
|
||||
tort en utilisant ces droits.
|
||||
|
||||
Détaillons-les un peu ces droits, ce qu'il permette de faire et qu'est ce qu'on
|
||||
entend par « causer du tort ». En devenant nounou, vous débloquez les accès à
|
||||
toute l'infrastructure. Techniquement, il n'y a plus de fichiers que vous ne
|
||||
pouvez pas voir, modifier ou supprimer et ce sur toutes les machines du Crans.
|
||||
De même, on chiffre pour vous tous les mots de passe qui ont trait au technique
|
||||
du Crans. Ce sont des droits très extensifs. D'où la possibilité de faire une
|
||||
erreur de manipulation. Normalement tout est fait dans l'infrastructure pour
|
||||
limiter la casse possible. On a de la redondance où c'est possible et
|
||||
nécessaire, on fait des backups quotidiennes à la fois des données utilisateur⋅rices
|
||||
mais aussi des données d'administration. Cependant, tout ça ne change pas le
|
||||
fait qu'une mauvaise commande rentrée dans votre shell peut rendre le
|
||||
Crans hors ligne pour quelques heures ou supprimer de manière irreversible des
|
||||
données. Quand vous devenez nounou, on vous fait confiance pour éviter ce genre
|
||||
de choses au maximum. Après les erreurs ça arrive toujours. La personne qui
|
||||
écrit ces lignes en a fait un certain nombre avec des conséquences diverses.
|
||||
Ce qui compte ce n'est pas de ne pas en faire du tout, c'est d'en faire peu,
|
||||
d'apprendre de celles-ci et de s'assurer qu'elles ne sont pas irréversibles.
|
||||
|
||||
Il y a aussi quelque chose qu'il faut souligner. Et normalement quand vous
|
||||
deviendrez nounou vous allez le voir assez fréquement (à chaque fois que vous
|
||||
faîtes un sudo pour la première fois sur une machine) :
|
||||
|
||||
```txt
|
||||
We trust you have received the usual lecture from the local System
|
||||
Administrator. It usually boils down to these three things:
|
||||
|
||||
#1) Respect the privacy of others.
|
||||
#2) Think before you type.
|
||||
#3) With great power comes great responsibility.
|
||||
```
|
||||
|
||||
Ce court texte résume bien ce que je veux aborder ici. Les droits que vous vous
|
||||
voyez confier sont une intrusion phénoménale dans la vie privée des gens. Si
|
||||
vous voulez une métaphore, vous pouvez voir ça comme si les adhérent⋅es du Crans
|
||||
vous avait donné la clé de leur maison pour que vous puissiez réparer quand il y
|
||||
a une fuite d'eau, mais pas pour que vous fouillez dans le bureau pour voir leurs
|
||||
papiers. Beaucoup de nos adhérent⋅es utilisent les outils qu'on met à leur
|
||||
disposition pour organiser une partie de leur vie, que ce soit d'utiliser
|
||||
l'adresse mail qui leur est fournie ou stocker des données dans leur Owncloud,
|
||||
et nous en sommes très heureux⋅ses. La charte que vous avez signé en devenant
|
||||
apprenti⋅e mentionne déjà ces problématiques mais il est important que ce soit
|
||||
très clair. **Vous ne pouvez consulter ou diffuser les données personnelles
|
||||
d'un⋅e adhérent⋅e qu'avec son consentement explicite.** On a parfois tendance à
|
||||
l'ENS à faire des abus de droits une blague, ce n'est pas le cas au Crans !
|
||||
|
||||
Bon maintenant que ces clarifications et rappels ont été faits, on va pour
|
||||
passer aux choses plus intéréssantes : comment on se donne ces droits (et dans la
|
||||
marge, comment on se les retire) ?
|
||||
|
||||
## Rentre dans le cercle
|
||||
|
||||
Le groupe des superadministrateur⋅rices au Crans est le groupe nounou. On va donc
|
||||
faire un petit tour dans le ldap et sous ou=groups,cn=_nounou on rajoute les
|
||||
uids correspondant au⋅x personne⋅s qu'on souhaite ajouter. Voilà, vous avez
|
||||
normalement:tm: les accès root sur toutes les machines du Crans. Cependant,
|
||||
vous allez peut-être constater qu'il y a certaines machines où cela ne
|
||||
fonctionne pas. C'est sûrement dû à ces ~~conneries~~ de replicat ldap. Il faut
|
||||
à ce moment là aller faire un tour dessus pour forcer la resynchro (c.f.
|
||||
`tools/ldap.md`).
|
||||
|
||||
## Give me the password
|
||||
|
||||
Vous avez *50* nouveaux mot de passes. Il est maintenant nécessaire de
|
||||
rechiffrer le pass pour vous. C'est un peu chiant mais on s'y fait. Voilà la
|
||||
procédure:
|
||||
|
||||
1. On se souvient du hash de commit courant :
|
||||
`HASH=$(git rev-parse HEAD)`
|
||||
1. On ajoute toutes les personnes concernées dans le groupe nounou dans le
|
||||
fichier `.groups.yml` du store et on commit ces changements `git commit -m
|
||||
toto1234`.
|
||||
1. On rechiffre tous les fichiers à rechiffrer
|
||||
`cat .last_group.json | jq -r '. | with_entries( select(.value | any( .==
|
||||
"nounou"))) | keys[]' | xargs pass rans reencrypt`
|
||||
1. On supprime tous les commits inutiles :
|
||||
`git reset --soft $HASH; git commit -m 'Coucou les ami⋅es'`
|
||||
1. On vérifie que ça marche et on push :)
|
||||
|
||||
Petit point pour quand on retire des droits au gens. Là où pour tous les autres
|
||||
droits, quand vous les retirez à quelqu'un⋅e bah iel les a plus, ce n'est pas le
|
||||
cas pour les mots de passe. Il reste dans l'historique de git un moment où la
|
||||
personne qui perds ces droits à toujours les mots de passes chiffrées pour elle.
|
||||
On choisit généralement de s'en tamponner l'oreille avec une babouche.
|
||||
Cependant, il peut y avoir certains moments où on veut effectivement retirer
|
||||
complètement à quelqu'un⋅e la possibilité d'utiliser un mot de passe. Dans ce
|
||||
cas il faut le changer :(
|
||||
|
||||
## Thank you for your services
|
||||
|
||||
Au Crans on a **plein** de services. Certains sont gentils et écoutent
|
||||
directement le ldap pour savoir qui a des droits, d'autres s'en foutent et ils
|
||||
faut se rajouter dans les admins à la main. Petite liste ci dessous.
|
||||
|
||||
### Gitlab
|
||||
|
||||
Il faut aller dans la zone d'administration, puis dans la liste
|
||||
d'utilisateur⋅ices et changez le profil de l'utilisateur⋅ice de regular à admin.
|
||||
|
||||
### Mailman
|
||||
|
||||
Il faut se connecter normalement au logiciel, puis allez dans la section admin
|
||||
<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
|
||||
|
||||
```txt
|
||||
<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> !
|
||||
|
|
@ -1,139 +0,0 @@
|
|||
# La suppression d'un⋅e utilisateurice
|
||||
|
||||
Pour diverses raisons dont il n'est pas question de juger, un⋅e
|
||||
utilisateur⋅rice peut vouloir supprimer son compte Crans et les données
|
||||
associées. En particulier cela peut rentrer dans le cadre du
|
||||
[RGPD](https://www.cnil.fr/fr/reglement-europeen-protection-donnees/). Il y a
|
||||
certaines informations qu'il faut garder une durée minimale, mais les autres
|
||||
doivent être supprimées à la demande de l'utilisateurice. C'est pénible
|
||||
mais faisable : respecter la volonté de l'utilisateur⋅rice dans ce cas est
|
||||
important. Ce petit guide est là pour rappeler tout ce qu'il ne faut pas
|
||||
oublier.
|
||||
|
||||
## La demande de suppression
|
||||
|
||||
Il faut s'assurer que c'est bien la bonne personne qui fait la demande. En cas
|
||||
de doute, on peut demander une preuve d'identité (pièce d'identité, mail
|
||||
depuis l'adresse mail crans...). Ensuite, on peut vérifier que la personne à
|
||||
bien compris ce que la suppression de compte impliquait : la perte de toutes
|
||||
les données non sauvegardées par l'utilisateurice, ne plus avoir accès aux
|
||||
services qui nécessite un compte crans... Selon ce qui est demandé (et ce
|
||||
qu'on a le droit de faire), le compte peut être seulement archivé, on peut
|
||||
supprimer les données liées au compte (en totalité ou partie), voire les
|
||||
données d'un service non-lié à un compte crans (wiki...). Si la personne
|
||||
est encore adhérente, elle va probablement devoir démissionner de
|
||||
l'association.
|
||||
|
||||
## Re2o
|
||||
|
||||
Il faut bien un début, c'est sur l'intranet qu'on commence par
|
||||
supprimer/archiver quelqu'un⋅e.
|
||||
|
||||
### Archiver sur Re2o
|
||||
|
||||
Si la personne à une facture/adhésion de moins de 10 ans, on ne peut pas
|
||||
supprimer le compte. Dans ce cas-là, ou si c'est ce que préfère
|
||||
l'utilisateurice, on archive le compte : dans le profil, il faut changer
|
||||
l'état de "Actif⋅ves" à "Complétement archivé⋅es". On peut
|
||||
éventuellement supprimer certaines informations (bannissement,
|
||||
établissement...) mais on doit garder les informations de contact et les
|
||||
factures/adhésions de moins de 10 ans.
|
||||
|
||||
On peut repasser au bout des 10 ans pour tout supprimer (ça serait bien
|
||||
d'avoir un truc automatique ou que l'utilisateurice nous le rappelle).
|
||||
|
||||
### Supprimer sur Re2o
|
||||
|
||||
Il faut aller dans l'interface d'administration
|
||||
<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](https://gitlab.crans.org/admin/users).
|
||||
On se rend dans les paramètres du compte, on clique sur "Administration des
|
||||
utilisateur" puis sur "Supprimer un compte utilisateur" ou "Supprimer un
|
||||
compte utilisateur et ses contributions". Dans le deuxième cas, il faut faire
|
||||
attention surtout s'il y a des contributions à des projets partagés (comme
|
||||
ceux du crans).
|
||||
|
||||
## Owncloud
|
||||
|
||||
Il suffit simplement de se rendre dans l'interface d'administration, section
|
||||
utilisateurices :
|
||||
[https://owncloud.crans.org/settings/users](https://owncloud.crans.org/settings/users),
|
||||
puis de chercher le compte et de simplement le supprimer.
|
||||
|
||||
## Mailman
|
||||
|
||||
On commence par se rendre dans [Django-Admin](https://lists.crans.org/admin/).
|
||||
|
||||
S'il n'y a pas de compte, aucune question à se poser.
|
||||
|
||||
S'il y a un compte, on le supprime.
|
||||
|
||||
Potentiellement, la personne est présente sur mailman de manière non-liée à
|
||||
son éventuel compte crans. Dans ce cas, il va falloir faire du ménage avec
|
||||
l'adresse mail et donc de l'aide de l'utilisateurice qui va devoir indiquer son
|
||||
adresse et les ML qu'iel reçoit/administre. Ça peut être un peu les bazar
|
||||
si il y a plusieurs adresses non-liées. Si la personne est lae dernièr⋅e
|
||||
propriétaire d'une liste, il faudra soit la supprimer soit lui trouver un⋅e
|
||||
nouvelleau propriétaire (c'est pas obligatoire mais alors c'est root@crans.org
|
||||
le propriétaire par défaut, ce qui n'est pas une solution durable).
|
||||
|
||||
## Wiki
|
||||
|
||||
Si la connexion par le CAS est configurée, il faut penser à
|
||||
`rm /var/local/wiki/assowiki/{pseudo}`. Concerne a priori peu de monde.
|
||||
|
||||
Si la personne le demande, on peut supprimer son compte wiki et les pages qui
|
||||
concernent son compte (page perso...), historique compris. Pour cela il faut
|
||||
aller sur `kiwi` et supprimer le dossier contenant la page. Cela peut concerner
|
||||
des personnes n'ayant pas de compte crans, mais il faudra le WikiNom.
|
||||
|
||||
## The Lounge
|
||||
|
||||
S’il y a eu une utilisation de WebIRC, on peut aller sur Zamok et
|
||||
`rm /etc/thelounge/users/{pseudo}.json` (configuration),
|
||||
`rm /etc/thelounge/logs/{pseudo}` et `rm /etc/thelounge/logs/{pseudo}.sqlite3`
|
||||
(pour l'historique des messages).
|
||||
|
||||
## Autres données
|
||||
|
||||
Il y a probablement des données personnelles qui trainent ailleurs, il faudra
|
||||
mettre à jour cette page si on en trouve. Par exemple, pour les membres
|
||||
actif⋅ves qui ont un compte underscore ou les utilisateurices qui ont (eu) une
|
||||
VM (perso ou de club).
|
||||
|
||||
## Données hébergées mais pas administrée par le Crans
|
||||
|
||||
Le Crans héberge des VM pour les clubs (note, serveur photos, bdd med...) qui
|
||||
peuvent contenir des données personnelles. La personne devra aller voir les
|
||||
admins de ces services pour supprimer les données.
|
||||
|
|
@ -1,15 +0,0 @@
|
|||
# Logiciels
|
||||
|
||||
## Présentation
|
||||
|
||||
Ce dossier contient une présentation de plusieurs outils logiciels utilisés
|
||||
par le Crans.
|
||||
|
||||
Le but n'est pas de réexpliquer l'entièreté des fonctionnalités, mais
|
||||
simplement d'avoir une explication de ce que l'on parle pour avoir des bases
|
||||
de compréhension.
|
||||
|
||||
## Organisation
|
||||
|
||||
L'organisation est la même que décrite dans [le fichier `README.md` du
|
||||
dossier parent](../README.md).
|
||||
|
|
@ -1,61 +0,0 @@
|
|||
# APT
|
||||
|
||||
APT (pour Advanced Package Tool) est un des gestionnaires de paquets de
|
||||
[Debian](https://www.debian.org/). Il dispose d'une interface en CLI, voici
|
||||
quelques exemples de commandes :
|
||||
|
||||
| commande | description |
|
||||
|----------|-------------|
|
||||
| `apt install package` | Installe `package` |
|
||||
| `apt search package` | Recherche `package` |
|
||||
| `apt list` | Liste les paquets |
|
||||
| `apt list --installed` | Liste les paquets installés |
|
||||
| `apt remove package` | Désinstalle `package`, sans supprimer sa configuration |
|
||||
| `apt purge package` | Purge `package`, i.e. désinstalle et supprime sa configuration |
|
||||
| `apt depends package` | Liste les dépendances de `package` |
|
||||
| `apt rdepends package` | Liste les paquets dépendants de `package` |
|
||||
| `apt policy package` | Affiche les informations de priorité pour `package` |
|
||||
| `apt show package` | Affiche les informations de `package` |
|
||||
| `apt update` | Met à jour les listes de paquets |
|
||||
| `apt upgrade` | Met à jour les paquets |
|
||||
|
||||
Un paquet Debian va placer des fichiers dans `/bin/`, `/usr/` par exemple. Il
|
||||
faut donc avoir les droits administrateurs pour installer, mettre à jour ou
|
||||
supprimer un paquet. Il n'est pas possible d'installer un paquet APT pour
|
||||
seulement un utilisateur.
|
||||
|
||||
## Les sources de paquets
|
||||
|
||||
APT est en réalité une interface au dessus de DPKG (Debian PacKaGe) qui va
|
||||
simplifier le téléchargement et l'installation de paquets en les
|
||||
synchronisant de sources de paquets.
|
||||
|
||||
Les sources de paquets sont définies dans `/etc/apt/source.list` et dans le
|
||||
dossier `/etc/apt/source.list.d/`. Un système Debian classique au Crans
|
||||
devrait avoir les sources suivantes :
|
||||
|
||||
```txt
|
||||
# Paquets principaux de Debian Buster
|
||||
deb https://ftps.crans.org/debian buster main
|
||||
|
||||
# Paquets "volatiles" pour avoir des mises à jour un peu plus régulièrement
|
||||
deb https://ftps.crans.org/debian buster-updates main
|
||||
|
||||
# Paquets apportant les mises à jour de sécurité
|
||||
deb https://ftps.crans.org/debian-security buster/updates main
|
||||
```
|
||||
|
||||
Si on souhaite également synchroniser la liste des sources de paquets pour
|
||||
potentiellement les reconstruire, on peut dupliquer chaque ligne en substituant
|
||||
`deb` par `deb-src`.
|
||||
|
||||
## Vérifier l'état de santé des paquets systèmes Debian
|
||||
|
||||
Debian fournit un outil nommé `debsums` (Debian Checksum) pour vérifier que
|
||||
les fichiers installés par les paquets Debian n'ont pas été altérés. Un
|
||||
fichier d'un paquet peut être altéré soit par un virus ou un administrateur
|
||||
chaotique qui écrase ses exécutables, soit quand il s'agit de changer sa
|
||||
configuration.
|
||||
|
||||
Pour lister rapidement la liste des fichiers de configuration changés :
|
||||
`debsums -ce`.
|
||||
|
|
@ -1,44 +0,0 @@
|
|||
# GPG
|
||||
|
||||
GPG (GNU Privacy Guard) est une implémentation libre et open source du
|
||||
protocole OpenPGP (Pretty Good Privacy), un protocole cryptographique
|
||||
permettant de signer, chiffrer et déchiffrer des documents (notamment des
|
||||
emails).
|
||||
|
||||
## Clef
|
||||
|
||||
Une clef GPG est une clé numérique qui permet d'être identifié de façon
|
||||
unique dans le monde numérique.
|
||||
|
||||
Elle est composée de deux éléments :
|
||||
|
||||
* une clé privée protégée par une phrase clé qui permet d'éviter à une
|
||||
tierce personne d'utiliser cette clef si elle parvient à la voler
|
||||
|
||||
* une clé publique qui une fois distribuée et signée par son entourage,
|
||||
permet à celui-ci de vérifier que les messages que l'on signe le sont bien
|
||||
avec la clé privée associée à cette clé publique.
|
||||
|
||||
Elle peut être générée à l'aide d'une des commandes suivantes (selon le
|
||||
nombre d'option que vous souhaitez avoir) :
|
||||
|
||||
* `gpg --generate-key`
|
||||
|
||||
* `gpg --full-generate-key`
|
||||
|
||||
* `gpg --full-generate-key --expert`
|
||||
|
||||
## Web of trust
|
||||
|
||||
Le web of trust (ou toile de confiance en français) permet d'établir
|
||||
l'authenticité de l'appartenance d'une clef publique ; il est décentralisé :
|
||||
il n'a donc pas besoin d'autorité de certification.
|
||||
|
||||
Voici les règles par défaut du web of trust d'OpenPGP, on estime que la clef
|
||||
publique appartient au bon propriétaire si :
|
||||
|
||||
* On a soi-même fait confiance à cette clef
|
||||
|
||||
* Une personne en qui on a totalement confiance a signé cette clef
|
||||
|
||||
* Trois personnes en qui on a partiellement confiance ont signé cette clef
|
||||
|
|
@ -1,100 +0,0 @@
|
|||
# SSH
|
||||
|
||||
SSH (Secure Shell) est un protocole permettant d'exécuter des commandes sur un
|
||||
serveur distant. Il utilise le port 22 en TCP.
|
||||
|
||||
Sa version 2 est spécifiée par les RFC
|
||||
[4250](https://datatracker.ietf.org/doc/html/4250),
|
||||
[4251](https://datatracker.ietf.org/doc/html/4251),
|
||||
[4252](https://datatracker.ietf.org/doc/html/4252),
|
||||
[4253](https://datatracker.ietf.org/doc/html/4253) et
|
||||
[4254](https://datatracker.ietf.org/doc/html/4254).
|
||||
|
||||
## OpenSSH
|
||||
|
||||
Le client de prédilection pour utiliser SSH est le client de la suite OpenSSH
|
||||
(qui fourni également un serveur et d'autres utilitaires permettant de gérer
|
||||
les clefs cryptographiques), disponible dans le paquet Debian `openssh-client`.
|
||||
|
||||
## Clefs SSH
|
||||
|
||||
Vous pouvez générer des clefs cryptographiques permettant de vous
|
||||
authentifier directement sur le serveur distant (plutôt que par mot de passe)
|
||||
avec l'utilitaire `ssh-keygen` ainsi :
|
||||
|
||||
```bash
|
||||
ssh-keygen -t ${TYPE} -b ${BITS}
|
||||
```
|
||||
|
||||
Où `TYPE` peut être :
|
||||
|
||||
* `rsa`
|
||||
|
||||
* `ecdsa` (dans ce cas `BITS` doit valoir 256, 384 ou 521)
|
||||
|
||||
* `ed25519` (dans ce cas `BITS` doit valoir 256)
|
||||
|
||||
`ssh-keygen` vous demande ensuite le chemin du fichier de clef ainsi que sa
|
||||
passphrase et génère une clef privée ainsi qu'une clef publique se terminant
|
||||
par `.pub`.
|
||||
|
||||
Un autre utilitaire, `ssh-copy-id` permet de copier la clef sur le serveur
|
||||
distant par exemple :
|
||||
|
||||
```bash
|
||||
ssh-copy-id -i ~/.ssh/id_ed25519.pub login@zamok.crans.org
|
||||
```
|
||||
|
||||
Attention : il faut absolument garder la clef privée sur votre serveur et ne
|
||||
pas l'envoyer sur le serveur distant.
|
||||
|
||||
## Exemples
|
||||
|
||||
À la première connexion `ssh` demande s'il faut faire confiance à la clef du
|
||||
serveur :
|
||||
|
||||
```bash
|
||||
benjamin@om ~ $ ssh gitlab.crans.org
|
||||
The authenticity of host 'gitlab.crans.org (185.230.79.14)' can't be
|
||||
established.
|
||||
ECDSA key fingerprint is SHA256:StU+25vCTTs+opjyjMZTLvl+gvR+ViQWUkE1jRENnkQ.
|
||||
Are you sure you want to continue connecting (yes/no/[fingerprint])?
|
||||
```
|
||||
|
||||
Il est de bon usage de confirmer l'authenticité de cette clef afin de ne pas
|
||||
être vulnérable aux attaque de type Man in the Middle. Pour celà il y a une
|
||||
solution : l'administrateur du serveur doit vous confirmer l'empreinte
|
||||
(fingerprint) de la clef par un moyen sécurisé. Voici une liste non
|
||||
exhaustive de moyens plus ou moins sécurisés :
|
||||
|
||||
* Si vous êtes vous-même l'administrateur du serveur la commande `for key in
|
||||
/etc/ssh/ssh_host_*.pub; do ssh-keygen -lf ${key}; done` sur le serveur pour
|
||||
afficher les empreintes de vos clefs.
|
||||
|
||||
* Se faire confirmer la clef oralement par l'administrateur.
|
||||
|
||||
* Se faire confirmer la clef par un mail d'un administrateur de confiance
|
||||
signé GPG.
|
||||
|
||||
* Utiliser des clefs stockées dans le [DNS](/tools/dns.md) et signées
|
||||
DNSSEC, ceci peut se faire en ajoutant l'option `-oVerifyHostKeyDNS=yes` à
|
||||
`ssh`.
|
||||
|
||||
Une fois que vous vous êtes assuré de l'authenticité de la clef vous pouvez
|
||||
entrer `yes` dans le prompt ci-dessus.
|
||||
|
||||
`ssh` vous demande ensuite votre mot de passe ou la passphrase de votre clef,
|
||||
entrez le et appuyez sur Entrée pour vous connecter, félicitations vous
|
||||
devriez avoir votre shell sur le serveur distant.
|
||||
|
||||
## Exemple de conf ssh
|
||||
|
||||
Après avoir `ssh-copy-id` sa clef public comme précisé plus haut on peut
|
||||
définir une conf qui permet d'aller sur nimporte quel serveur depuis votre
|
||||
machine via un `ProxyJump`.
|
||||
|
||||
```txt
|
||||
Host *.adm.crans.org
|
||||
User _usernounou
|
||||
ProxyJump _usernounou@hodaur.crans.org
|
||||
```
|
||||
|
|
@ -1,64 +0,0 @@
|
|||
# Systemd
|
||||
|
||||
Systemd est une suite logiciel pour systèmes GNU/Linux. Cette suite logiciel
|
||||
fournit de nombreuses fonctionnalités, notamment pour configurer son OS et
|
||||
suivre les *daemon*\ s actifs et leurs journaux.
|
||||
|
||||
Ce document décrit *certaines* fonctionnalités de Systemd bien choisies,
|
||||
lesquelles sont jugées intéressantes pour l'administration système ou pour
|
||||
utilisateurices. Il sera sans doute découpé en plusieurs morceaux s'il devient
|
||||
trop long.
|
||||
|
||||
|
||||
## Unités de configuration: un format unifiant.
|
||||
|
||||
### Services.
|
||||
|
||||
### Minuteurs.
|
||||
|
||||
### (Auto)mount.
|
||||
|
||||
|
||||
## Configuration Réseau.
|
||||
|
||||
### Obtenir des adresses IPs.
|
||||
|
||||
### Configuration DNS (récursif).
|
||||
|
||||
|
||||
## Journalisation.
|
||||
|
||||
### Lecture des journaux: les bases.
|
||||
|
||||
### Espaces de noms.
|
||||
|
||||
### Partage de journaux entre machines.
|
||||
|
||||
|
||||
## Aspect pratique (pour utilisateurices)
|
||||
|
||||
### Chiffrement de disque.
|
||||
|
||||
### Chargeur d'amorçage.
|
||||
|
||||
|
||||
## Conteneurisation et virtualisation.
|
||||
|
||||
### Conteneurisation.
|
||||
|
||||
### Virtualisation.
|
||||
|
||||
|
||||
## Gestion des secrets.
|
||||
|
||||
|
||||
## Trucs et astuces.
|
||||
|
||||
### Systèmes dynamiques: gestion des erreurs dans les services.
|
||||
|
||||
### Administration à distance.
|
||||
|
||||
<!-- LocalWords: IPs virtualisation utilisateurices Journalisation daemon
|
||||
<!-- LocalWords: Systemd Linux
|
||||
-->
|
||||
-->
|
||||
|
|
@ -1,201 +0,0 @@
|
|||
# ZFS
|
||||
|
||||
## ZFS c'est quoi ?
|
||||
|
||||
ZFS est un système de fichier avec plein de features natives, notamment de la
|
||||
gestion de volume, du RAID (RAID-Z), des snapshots, etc.
|
||||
|
||||
> ZFS a été ouvert sous licence
|
||||
> [CDDL](https://en.wikipedia.org/wiki/Common_Development_and_Distribution_License)
|
||||
> incompatible avec la GPL. Par conséquent, ZFS n'est pas supporté nativement
|
||||
> par le noyau Linux.
|
||||
|
||||
## Petit glossaire
|
||||
|
||||
* RAID-Z#N: Le raid de ZFS. Le chiffre #N correspond au nombre de disques que
|
||||
l'on peut perdre (e.g. RAID-Z2 correspond à du RAID 6 classique).
|
||||
|
||||
* Pool: Une *pool* de stockage est le bloc de base de ZFS. C'est un ensemble
|
||||
logique de données. Une pool ZFS est composée d'un ou plusieurs *vdev*.
|
||||
|
||||
* Vdev: Un *vdev* (pour ''virtual device'') est un sous élément d'une pool.
|
||||
Un vdev peut contenir un ou plusieurs disques physiques. Dans le cas où
|
||||
plusieurs disques sont utilisés, les données sont étendues (*stripped*) sur
|
||||
tous les disques afin d'améliorer sa durée de vie.
|
||||
|
||||
* Dataset: *Dataset* est le terme générique pour désigner un volume de
|
||||
fichiers ZFS. Chaque dataset a un nom unique de la forme *Pool/Dataset*. La
|
||||
racine de la pool est techniquement un dataset aussi. Les dataset sont
|
||||
organisés comme des dossiers classique, avec une arborescence, et les enfants
|
||||
héritent des propriétés des parents.
|
||||
|
||||
## Installation
|
||||
|
||||
Il faut ajouter les dépots `contrib` de debian dans lesquels se trouvent les
|
||||
paquets installés ci-dessous.
|
||||
|
||||
Pour installer le module noyau ZFS sous Debian et les outils d'administration :
|
||||
|
||||
```bash
|
||||
apt install linux-headers-amd64
|
||||
apt install zfs-dkms
|
||||
```
|
||||
|
||||
Il faut ensuite reboot pour loader le module zfs, puis :
|
||||
|
||||
```bash
|
||||
apt install zfsutils-linux
|
||||
```
|
||||
|
||||
Cela installe aussi `zfs-zed` un daemon permettant de monitorer les pool ZFS.
|
||||
Les headers du noyau doivent être installés à chaque mise à jour du noyau.
|
||||
|
||||
## Créer une pool ZFS
|
||||
|
||||
La première étape de création d'un filesystem ZFS est la création d'une
|
||||
pool. Une pool contient des vdev qui eux même contiennent des disques, la
|
||||
commande suivante permet de créer une pool de nom «pool» et montée dans
|
||||
`/pool` avec un vdev en RAIDZ-3 :
|
||||
|
||||
```bash
|
||||
zpool create -f -m /pool pool raidz3 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03494499 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03563166 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03570970 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03575828 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03614378 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03626582 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03694920 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03704580 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03707506 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03731830 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734763 \
|
||||
ata-WDC_WD2003FYYS-02W0B0_WD-WMAY03734769
|
||||
```
|
||||
|
||||
Les identifiants de disques peuvent être récupérés dans `/dev/disks/by-id/`.
|
||||
|
||||
L'état des pool peut-être consulté avec la commande :
|
||||
|
||||
```bash
|
||||
zpool status
|
||||
```
|
||||
|
||||
## Créer un dataset
|
||||
|
||||
Une fois la pool créée il est préférable de créer des datasets qui
|
||||
permettent une gestion plus fine de la pool. Pour cela on utilise la commande
|
||||
suivante qui créé un dataset du nom de «home» dans la pool «pool» :
|
||||
|
||||
```bash
|
||||
zfs create pool/home
|
||||
```
|
||||
|
||||
## Partager un dataset en NFS
|
||||
|
||||
ZFS permet de partager un dataset en NFS pour cela il faut installer le paquet
|
||||
`nfs-kernel-server` :
|
||||
|
||||
```bash
|
||||
apt install nfs-kernel-server
|
||||
```
|
||||
|
||||
Le dataset «home» de la pool «pool» peut ensuite être partager ainsi :
|
||||
|
||||
```bash
|
||||
zfs set sharenfs="no_root_squash,rw=@172.16.10.0/24" pool/home
|
||||
```
|
||||
|
||||
Cette commande partage le dataset au sous-réseau `172.16.10.0/24`, l'option
|
||||
`no_root_squash` permet au root du client NFS d'avoir tous les droits sur les
|
||||
fichiers du dataset.
|
||||
|
||||
Il est également préférable d'activer les acl POSIX sur la pool, dans le cas
|
||||
contraire il peut y avoir des problèmes de permissions à la création de
|
||||
fichiers :
|
||||
|
||||
```bash
|
||||
zfs set acltype=posixacl pool
|
||||
```
|
||||
|
||||
## Détruire un dataset
|
||||
|
||||
Pour détruire le dataset `pool/path` on utilise la commande :
|
||||
|
||||
```bash
|
||||
sudo zfs destroy pool/path
|
||||
```
|
||||
|
||||
## Désactiver le sync
|
||||
|
||||
Renvoyer une confirmation d'écriture sur le disque après chaque opération
|
||||
diminue énormément les performances du NFS. On peut dire à ZFS de mentir au
|
||||
NFS sur le retour des opérations sync(). Pour ça, on utilise la commande :
|
||||
|
||||
```bash
|
||||
sudo zfs set sync=disabled pool/path
|
||||
```
|
||||
|
||||
## Changer un disque
|
||||
|
||||
Récupérer le guid du disque qu'on souhaite changer avec `zdb` (`zpool status`
|
||||
peut aider à récuperer le nom du disque concerné). Une fois que c'est fait
|
||||
on peut retirer le disque avec : `zpool offline pool ${guid}` puis on remplace
|
||||
l'ancien disque par le nouveau :
|
||||
`zpool replace pool ${guid} ${nouveau disque}`.
|
||||
Après ça, on peut monitorer la reconstruction avec `zpool status`.
|
||||
|
||||
## Chiffrement
|
||||
|
||||
ZFS permet de nativement chiffrer un dataset. Attention, il faut que ça soit
|
||||
fait à la **creation** du dataset. Ça ne peut pas se changer après.
|
||||
|
||||
### Créer un dataset chiffré
|
||||
|
||||
Pour créer un dataset chiffré il suffit de rajouter les options de
|
||||
chiffrement avec `encryption=on`. Il faut aussi spécifier le format de la clé
|
||||
(`raw, hex, passphrase`). Par défaut, la clé va être promptée, mais il est
|
||||
possible de la stocker sur le système de fichier, ou bien via une URL.
|
||||
L'option `encryption` permet aussi de spéficier l'algorithme de chiffrement à
|
||||
utiliser.
|
||||
|
||||
Par exemple:
|
||||
|
||||
```bash
|
||||
sudo zfs create -o encryption=aes-256-gcm -o keyformat=passphrase pool/dataset
|
||||
```
|
||||
|
||||
Pour vérifier que tout va bien on peut récupérer la propriété de
|
||||
chiffrement :
|
||||
|
||||
```bash
|
||||
sudo zfs get encryption pool/dataset
|
||||
```
|
||||
|
||||
Pour changer la clé il suffit d'utiliser la commande suivante :
|
||||
|
||||
```bash
|
||||
sudo zfs key -c pool/dataset
|
||||
```
|
||||
|
||||
qui va demander la nouvelle passphrase.
|
||||
|
||||
Il est aussi possible de changer la source de la clé (pour aller chercher la
|
||||
clé dans un fichier par exemple).
|
||||
|
||||
### Monter/démonter un dataset chiffré
|
||||
|
||||
Par défaut le dataset sera monté. Pour le démonter il suffit d'utiliser la
|
||||
commande `unmount`. Attention, la clé de chiffrement sera toujours chargée,
|
||||
et le dataset pourra être remonté sans redemander la clé. Pour ça, il faut
|
||||
décharger la clé :
|
||||
|
||||
```bash
|
||||
sudo zfs unmount pool/dataset && sudo zfs unload-key pool/dataset
|
||||
```
|
||||
|
||||
Pour remonter le dataset il faut alors recharger la clé :
|
||||
|
||||
```bash
|
||||
sudo zfs load-key pool/dataset && sudo zfs mount pool/dataset
|
||||
```
|
||||
Loading…
Reference in New Issue