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