Arnaud Daby-Seesaram
parent
8e88d026a3
commit
8a41feffbd
972
crans.texi
972
crans.texi
|
|
@ -55,6 +55,9 @@ The document was typeset with
|
|||
|
||||
@menu
|
||||
* Comptes rendus::
|
||||
* How-Tos::
|
||||
* CONTRIBUTING::
|
||||
* Tools::
|
||||
* Index::
|
||||
@end menu
|
||||
|
||||
|
|
@ -80,6 +83,7 @@ car le tri par date se fait plus simplement).
|
|||
* CR Template::
|
||||
* 2024 01 13::
|
||||
* 2024 06 22::
|
||||
* 2024 08 29::
|
||||
@end menu
|
||||
|
||||
@node CR Template
|
||||
|
|
@ -403,6 +407,974 @@ Il faut mettre à jour. (On le fera vers juste après l’IN)
|
|||
GaBo a été désigné grand gagnant de qui s'occupera de la documentation
|
||||
d'Ansible.
|
||||
|
||||
@node 2024 08 29
|
||||
@section IN du jeudi 29 août 2024
|
||||
|
||||
@table @asis
|
||||
@item Date
|
||||
jeudi 29 août 2024
|
||||
@item Lieu
|
||||
MB87 et Galène (@url{https://galene.crans.org/group/CA})
|
||||
@item Début
|
||||
18h58
|
||||
@item Fin
|
||||
21h
|
||||
@end table
|
||||
|
||||
@subheading Présent·es
|
||||
|
||||
@itemize
|
||||
@item
|
||||
@url{https://wiki.crans.org/WikiBleizi, bleizi}
|
||||
@item
|
||||
@url{https://wiki.crans.org/WikiPigeonMoelleux, Pigeon Moelleux}
|
||||
@item
|
||||
GaBo
|
||||
@item
|
||||
@url{https://wiki.crans.org/VanilleNiven, vanille}
|
||||
@item
|
||||
korenst1
|
||||
@item
|
||||
Lzebulon
|
||||
@item
|
||||
Shinigami
|
||||
@item
|
||||
@url{https://wiki.crans.org/WikiHachino, Hachino}
|
||||
@item
|
||||
underscore_j
|
||||
@item
|
||||
RDB
|
||||
@item
|
||||
Otthorn
|
||||
@end itemize
|
||||
|
||||
@subheading Ordre du jour
|
||||
|
||||
@subsection Rapide compte-rendu de ce qu'il s'est passé cet été
|
||||
|
||||
Ottorn, lzebulon ont créé une vm collabora. Conséquence : découverte de
|
||||
mauvaises configurations problème entre ansible et les scripts qui sont
|
||||
dépréciés.
|
||||
|
||||
Mise à jour de gitlab
|
||||
|
||||
Au milieu de l'été. pb entre owncloud et nextcloud. impossibilité
|
||||
d'écrire (indépendant du reste). esum a résolu le pb. Owncloud a ensuite
|
||||
perdu sa conf ldap. Nextcloud a fini d'être configuré (paramêtre de
|
||||
partage et les mails (envoi de mail automatique pour les
|
||||
événements)). Nextcloud marche bien. Pub pour nextcloud possible.
|
||||
|
||||
pb avec Onlyoffice. Beaucoup de difficulté. Onlyoffice est packagé dans
|
||||
apt. Pas possible d'installer onlyoffice comme ça. On doit le faire à la
|
||||
main. Donc ce n'est pas ansibelisable. Il n'est pas possible d'utiliser
|
||||
onlyoffice sur téléphone (firefox) et limité à 20 connexions en même
|
||||
temps. du coup, est-ce qu'on utilise Collabora ou Onlyoffice ?
|
||||
|
||||
Du coup on peut passer sur collabora qui n'a pas ces problèmes. Sinon
|
||||
Otthorn a trouvé la variable à modifier.
|
||||
|
||||
@verbatim
|
||||
server/Common/sources/constant.js
|
||||
exports.LICENSE_CONNECTIONS = 20;
|
||||
@end verbatim
|
||||
|
||||
@subsection état sur les serveurs de backup
|
||||
|
||||
2 serveurs de backups. ft éteint par VR car fait trop de bruit. Mais il
|
||||
marche et permet de faire Peut-être la poussière ou les ventilos sont
|
||||
cassés. Bref, il faudra probablement faire qch. On ne sait pas si l'ilo
|
||||
marche. Mais il est possible de relancer les backups.
|
||||
|
||||
specs du serveurs chez viarezo :
|
||||
@url{https://wiki.crans.org/CransNostalgie/CransTechnique/LesServeurs/ServeurFt}
|
||||
|
||||
Pour thot : le serveur s'éteint spontanément après le démarrage. c'est
|
||||
probablement à cause de la sonde de température
|
||||
|
||||
On remet ft puis on réinstalle thot
|
||||
|
||||
Il existe plus simple que borg. Est-ce qu'on ne passerait pas sur truc
|
||||
plus récent. mais on garde borg pour le moment. Sinon on peut utiliser
|
||||
restic.
|
||||
|
||||
On s'assure que ft remarche avant de faire thot (moins urgent)
|
||||
|
||||
@quotation Pigeon
|
||||
``IL FAUT REDÉMARRER AU PLUS VITE LES SERVEURS DE BACKUP''
|
||||
@end quotation
|
||||
|
||||
Tealc : on n'arrive pas à ajouter les disques donc pk on y arriverait
|
||||
avec thot ?
|
||||
|
||||
Backup chez aurore ? -> Pas forcément une bonne idée car il y a peu de
|
||||
membre actif chez eux.
|
||||
|
||||
Chez Tuxae ? -> c'est possible on a l'accord du président.
|
||||
|
||||
Chez un hebergeur ? -> glacier. Pas chère pour écrire mais payer pour
|
||||
récupérer les données.
|
||||
|
||||
ft urgent et une fois fonctionnel, on commence sur thot. On peut aussi
|
||||
chiffrer les disques nativement avec zfs.
|
||||
|
||||
@subsection Cephiroth
|
||||
|
||||
Le point ne bouge toujours pas. GaBo cherche la facture (c'est faux).
|
||||
|
||||
@subsection Serveur matrix
|
||||
|
||||
De plus en plus de demande pour avoir une alternative libre à discord, whatsapp@dots{}
|
||||
|
||||
|
||||
Mastodon -> pas adapté
|
||||
Zulipe -> pas adapté
|
||||
Mattermost -> pas adapté
|
||||
Matrix -> faire de la pédagogie. Pas le temps de faire le support
|
||||
technique ? Il est possible de faire des vocaux. Il faut présenter ça
|
||||
aux gens mais iels auront besoin d'une passphrase et ou une clef de
|
||||
récupération.
|
||||
|
||||
Connexion ldap (note, crans ou les deux ?) <-> matrix possible mais
|
||||
est-ce que le serveur est possible de gérer plus de connexions. En
|
||||
principal, obligation de mettre le ldap du crans. Possibilité d'utiliser
|
||||
la note via Oauth... Les alias ça change. On doit conserver le
|
||||
pk. Potentiellement, on peut ajouter un préfix (genre "note_").
|
||||
|
||||
Ou alors, 2 instances de matrix, une pour chaque ldap. L'une est au bde mais le crans s'en occupe.
|
||||
Migrer SQLite à PostgreSQL.
|
||||
Si on migre le bde, il faut que se soit très stable.
|
||||
Est-ce qu'il est possible d'avoir de la redondance sur le serveur matrix ? a priori oui... mais peut-être pas intégrer pas défaut à matrix.
|
||||
matrix.crans.org juste un relai (bridge irc/matrix) pour la réinstallation, il faut demander à Erdnaxe.
|
||||
|
||||
On garde le serveur matrix tel quel (quitte à augmenter les perfs). migre de SQLite à PostgreSQL. LDAP crans en priorité.
|
||||
On met element
|
||||
chat.crans.org (facile à retenir)
|
||||
FAIRE DE LA PUB !
|
||||
|
||||
5 secondes sur Mastodon selon pigeon (c'est (déjà) perdu) mais moi je pense que la vérité est toute autre...
|
||||
Retirer la condition "cephirot.date < mastodon.date".
|
||||
Ajouter l'affirmation "Constellation.state == Cephiroth.state"
|
||||
|
||||
@subsection Reprise des séminaires hebdomadaires
|
||||
|
||||
On en parle Samedi (31 août (2024 je précise car oui je vous vois à lire
|
||||
ce point moulte années plutard !))
|
||||
|
||||
@subsection état de l'imprimante
|
||||
|
||||
bref : ça marche pas
|
||||
|
||||
L'imprimante a été déplacée mais impossible de communiquer avec
|
||||
l'imprimante. Il faudra se poser avec des personnes de la DSI pour
|
||||
résoudre le pb. Mais dire ce qu'on a fait, il est possible que ça
|
||||
avance. pigeon pense pouvoir s'en charger mais il ne connait pas ce
|
||||
qu'il y a autour de l'imprimante.
|
||||
|
||||
On essaie de s'en occuper assez rapidement (bleizi et pigeonmoelleux)
|
||||
|
||||
@subsection mettre les clés gpg dans le pass
|
||||
|
||||
pb de rétention des clefs gpg. pigeon a "pillé" à bleizi les clefs.
|
||||
potentiellement signer les clefs gpg des nounous.
|
||||
|
||||
Remettre de l'ordre dans le pass. thot renommé en surface sans raison (a
|
||||
priori).
|
||||
|
||||
Pour la prochaine IN, garder le pass avec gpg ou passer sur sops ou
|
||||
autre... Sinon, demander aux vielles nounous (peb, pollion) si iels
|
||||
veulent garder leurs droits nounous (ça ressemble à une invitation à
|
||||
partir...). Pour les autres, on propose de rajouter les clefs gpg dans
|
||||
le pass.
|
||||
|
||||
@subsection Quand est-ce qu'on redémarre tous les serveurs qui en ont besoin
|
||||
|
||||
Près de 400 jours qu'il tourne. (pas de coupure estivale). Pas possible
|
||||
de la faire avant les prochaines vacances. En profiter pour refaire le
|
||||
cablage. Une réunion de préparation de la réparation. (redémarrage et
|
||||
brassage)-> prochain IN
|
||||
|
||||
@subsection Chronolgie TODO list
|
||||
|
||||
@table @asis
|
||||
@item Très urgent
|
||||
@itemize
|
||||
@item
|
||||
Backup ft (commencé à faire les backup)
|
||||
@itemize
|
||||
@item
|
||||
1/2 qui non important (genre voyager et helloworld)
|
||||
@item
|
||||
par ordre d'importance (genre mailman)
|
||||
@end itemize
|
||||
@item
|
||||
d'ici là samedi rangement, inté, séminaires
|
||||
@item
|
||||
Cephiroth (garantie go GaBo)
|
||||
@item
|
||||
puis on s'occupe de thot
|
||||
@end itemize
|
||||
|
||||
@item on est déjà dans qq semaines
|
||||
@itemize
|
||||
@item
|
||||
onlyoffice (la limite)
|
||||
@item
|
||||
bleizi, pigeon -> imprimante
|
||||
@item
|
||||
les clefs gpg dans le passe (demander à pollion et peb, s'ils veulent
|
||||
rester nounous)
|
||||
@item
|
||||
enlever les vielles nounous (charlie, peb ? et pollion ?)
|
||||
@end itemize
|
||||
|
||||
@item Le mois prochain
|
||||
@itemize
|
||||
@item
|
||||
prévénir tout le monde que les serveurs du crans sont down
|
||||
@item
|
||||
Backup tealc sur zéphir/cameron
|
||||
@item
|
||||
inventaire et commander des disques d'avances (un disque en rab
|
||||
compatible pour chacun des serveurs)
|
||||
@item
|
||||
coupure : recabler, (vérifier l'étiqueteuse)
|
||||
@item
|
||||
PASSER LA POOL EN 4096
|
||||
@item
|
||||
réinstaller tealc
|
||||
@end itemize
|
||||
|
||||
@item Après
|
||||
@itemize
|
||||
@item
|
||||
voir matrix
|
||||
@item
|
||||
rediscuter de mastodon
|
||||
@item
|
||||
Nix
|
||||
@end itemize
|
||||
|
||||
@item Jamais
|
||||
@itemize
|
||||
@item
|
||||
Constellation
|
||||
@item
|
||||
Ceph
|
||||
@end itemize
|
||||
@end table
|
||||
|
||||
@node How-Tos
|
||||
@chapter How-Tos
|
||||
|
||||
Cette section contient les ``how to'' (tutoriels) du Crans concernant
|
||||
des tâches techniques demandant des connaissances généralement sur
|
||||
plusieurs parties de l'infrastructure.
|
||||
|
||||
Si vous souhaitez que d'autres soient ajoutés, n'hésitez pas à vous
|
||||
réferrer à @ref{CONTRIBUTING}.
|
||||
|
||||
|
||||
@menu
|
||||
* Changer de pseudo: Changer de pseudo. @
|
||||
|
||||
Comment faire pour changer le nom d'utilisateur (pseudonyme) d'un⋅e
|
||||
utilisateur⋅rice. Cela peut être utile par exemple lors d'un changement
|
||||
d'état civil.
|
||||
|
||||
* Creer VM adherent: Creer VM adherent. @
|
||||
|
||||
Comment faire pour créer une VM pour un⋅e adhérent⋅e.
|
||||
|
||||
* La suppression d'un⋅e utilisateurice:: @
|
||||
|
||||
Comment supprimer un⋅e utilisateur⋅rice ainsi que toutes ses données.
|
||||
|
||||
* Comment devenir nounou ?:: guide pour les nouvelles nounous !
|
||||
@end menu
|
||||
|
||||
@node Changer de pseudo
|
||||
@section Changer de pseudo
|
||||
|
||||
Le pseudo est l'identifiant unique permettant de s'authentifier sur
|
||||
l'ensemble des services du Crans. Pour diverses raisons dont il n'est
|
||||
pas question de juger, un⋅e utilisateur⋅rice peut vouloir changer de
|
||||
pseudo. C'est pénible mais faisable : respecter la volonté de
|
||||
l'utilisateur⋅rice dans ce cas est important. Ce petit guide est là pour
|
||||
rappeler tout ce qu'il ne faut pas oublier.
|
||||
|
||||
@subsection Re2o
|
||||
|
||||
Il faut bien un début, c'est sur l'intranet qu'on commence par renommer
|
||||
quelqu'un⋅e. Il suffit d'éditer le profil et de changer le pseudo.
|
||||
|
||||
Ne pas oublier d'aller contrôler le LDAP sur @code{yson-partou} pour
|
||||
s'assurer que l'ancien compte a bien été supprimé. Pour cela, faire un
|
||||
@code{sudo shelldap} sur @code{yson-partou}, puis taper
|
||||
@code{cn=Utilisateurs} et s'assurer que @code{cat cn=ancienpseudo} ne
|
||||
renvoie rien.
|
||||
|
||||
@subsection Zamok
|
||||
|
||||
Le plus évident, il faut déplacer le home ainsi que les mails.
|
||||
|
||||
Si le pseudo vient à l'instant d'être modifié, il suffit de faire un
|
||||
@code{sudo mv /home/@{ancienpseudo,nouveaupseudo@}}, sinon avec l'accord
|
||||
de la personne on peut faire un @code{rsync -ar
|
||||
/home/@{ancienpseudo,nouveaupseudo@}/}, ce qui va copier le contenu de
|
||||
l'ancien home dans le nouveau, mais attention au remplacement de
|
||||
données. L'ancien home peut ensuite être supprimé.
|
||||
|
||||
De la même manière, il faut renommer @file{/var/mail/ancienpseudo} en
|
||||
@file{/var/mail/nouveaupseudo}, ou déplacer le contenu et supprimer
|
||||
l'ancien dossier.
|
||||
|
||||
@subsection Backups
|
||||
|
||||
Étape non pressante, mais on peut se rendre sur @code{backup-ft} et
|
||||
@code{backup-thot} pour déplacer
|
||||
@file{/backup/borg-adh/home/ancienpseudo} en
|
||||
@file{/backup/borg-adh/home/nouveaupseudo}, si ce n'est pas trop
|
||||
tard. Si le nouveau dossier est déjà créé, alors on peut attendre
|
||||
quelques jours voire quelques mois au cas où pour supprimer l'ancien
|
||||
dossier inutile.
|
||||
|
||||
À faire avec précaution. Mais à faire puisqu'on ne garde pas des backups
|
||||
éternellement. Pas pour des raisons de place mais pour des raisons de
|
||||
non-conservation de données personnelles.
|
||||
|
||||
@subsection Gitlab
|
||||
|
||||
S'il n'y a pas d'ancien compte, il n'y a rien à faire.
|
||||
|
||||
S'il y a un ancien compte ET un nouveau compte, c'est pénible. Il faut
|
||||
transférer les appartenances de projet d'un compte à l'autre. Ce cas ne
|
||||
s'étant pour l'instant pas présenté, il sera à détailler à terme.
|
||||
|
||||
On se place dans l'hypothèse où l'on veut renommer un ancien compte. On
|
||||
commence par se rendre dans l'interface d'administration de Gitlab,
|
||||
section utilisateurs : @url{https://gitlab.crans.org/admin/users}.
|
||||
|
||||
Si la personne s'est reconnectée avec son nouveau pseudo SANS AUCUNE
|
||||
CONTRIBUTION, alors on peut supprimer librement ce nouveau compte. On se
|
||||
rend ensuite dans les paramètres de l'ancien compte, on clique sur
|
||||
``Éditer'' et on remplace le pseudo. Inutile de remplacer nom et adresse
|
||||
mail, ces champs sont importés par LDAP.
|
||||
|
||||
Ensuite, on se rend dans l'onglet ``Identités'', et on met à jour
|
||||
l'identifiant LDAP. Normalement, la personne peut désormais se connecter
|
||||
en n'ayant perdu ni projets ni commits, et son adresse mail ainsi que
|
||||
son nom seront mis à jour à sa prochaine connexion.
|
||||
|
||||
@subsection Owncloud
|
||||
|
||||
Deux cas à considérer : l'utilisateur⋅rice s'est servi⋅e des agendas
|
||||
Owncloud ou non. Dans le premier cas, c'est pénible et cette
|
||||
documentation sera mise à jour afin de détailler comment exporter et
|
||||
réimporter les calendriers.
|
||||
|
||||
Si l'utilisateurice n'a pas utilisé d'application externe et uniquement
|
||||
le téléversement de fichiers, il suffit simplement de se rendre dans
|
||||
l'interface d'administration, section utilisateur⋅rices :
|
||||
@url{https://owncloud.crans.org/settings/users}, puis de chercher
|
||||
l'ancien compte et de simplement le supprimer. Les données étant montées
|
||||
sur Zamok, seul le home local inutile sera supprimé.
|
||||
|
||||
@subsection Mailman
|
||||
|
||||
On commence par se rendre dans @url{https://lists.crans.org/admin/,
|
||||
Django-Admin}.
|
||||
|
||||
S'il n'y a pas d'ancien compte, aucune question à se poser.
|
||||
|
||||
S'il y a un nouveau compte inutile, on le supprime.
|
||||
|
||||
S'il n'y a pas de nouveau compte, on peut changer le pseudo Mailman si
|
||||
souhaité, mais l'important est surtout d'aller dans les connexions
|
||||
sociales et de changer le pseudo utilisé pour lier le compte Mailman.
|
||||
|
||||
@subsection Wiki
|
||||
|
||||
Si la connexion par le CAS est configurée, il faut penser à @code{mv
|
||||
/var/local/wiki/assowiki/@{ancienpseudo,nouveaupseudo@}}. Concerne a
|
||||
priori peu de monde.
|
||||
|
||||
@subsection The Lounge
|
||||
|
||||
Si on tient à ne pas perdre sa connexion WebIRC (si concernée), on peut
|
||||
aller sur Zamok et @code{mv
|
||||
/etc/thelounge/users/@{ancienpseudo,nouveaupseudo@}.json} Il y a aussi
|
||||
des fichiers de d'historiques des messages que l'on peut supprimer
|
||||
@code{rm /etc/thelounge/logs/@{pseudo@}} et @code{rm
|
||||
/etc/thelounge/logs/@{pseudo@}.sqlite3} ou remommer.
|
||||
|
||||
@node Creer VM adherent
|
||||
@section Création de machine virtuelle pour les adhérent⋅es
|
||||
|
||||
Le crans propose un système de locations de vms dont vous pouvez
|
||||
retrouver les tarifs dans les annexes des statuts de l'association. En
|
||||
voici un récapitulatif ici, mais attention celui-ci peut ne pas être à
|
||||
jour et seul ce qui est marqué dans les statuts fait foi.
|
||||
|
||||
@multitable @columnfractions .5 .5
|
||||
@headitem Article @tab Tarifs
|
||||
@item
|
||||
Service minimal
|
||||
@tab 10€
|
||||
@item
|
||||
Connexion Internet
|
||||
@tab 30€
|
||||
@item
|
||||
Cœeur additionnel
|
||||
@tab 5€
|
||||
@item
|
||||
2GB de RAM additionnel
|
||||
@tab 5€
|
||||
@item
|
||||
Disque additionnel (par tranche de 16G)
|
||||
@tab 1€
|
||||
@end multitable
|
||||
|
||||
Le service minimal comprend :
|
||||
@itemize
|
||||
@item
|
||||
n disque de 8H
|
||||
@item
|
||||
un cœur
|
||||
@item
|
||||
2G de ram
|
||||
@end itemize
|
||||
|
||||
Tous les services sont proposés pour une durée de 1 an.
|
||||
|
||||
@subsection Utilisateur⋅ices
|
||||
|
||||
La documentation pour les utilisateur⋅ices se trouvent sur le
|
||||
@url{https://wiki.crans.org/VieCrans/VPS, wiki}.
|
||||
|
||||
@subsection Nounous et apprenti⋅es
|
||||
|
||||
@subsubsection Facturation
|
||||
|
||||
Quand cela est possible, privilégier la note. Sinon, voir avec un⋅e
|
||||
trésorier⋅ère pour d'autres méthodes (espèces, virement, @dots{}).
|
||||
|
||||
@subsubsection LDAP
|
||||
|
||||
Quand un⋅e adhérent⋅e vous demande de lui créer une vm, il faut au
|
||||
préalable læ rajouter dans le ldap des adhérent⋅es (qui n'est pas le
|
||||
même que le ldap re2o).
|
||||
|
||||
Celui ci se situe sur flirt et à la structure suivante :
|
||||
|
||||
@verbatim
|
||||
ou=users
|
||||
├── cn=toto
|
||||
└── cn=titi
|
||||
ou=clubs
|
||||
└── o=rover
|
||||
ou=hosts
|
||||
├── cn=voyager
|
||||
└── cn=curiosity
|
||||
@end verbatim
|
||||
|
||||
Pour référence ma configuration @code{shelldap} pour me connecter au
|
||||
ldap est la suivante :
|
||||
|
||||
@verbatim
|
||||
# +---------------------------------+
|
||||
# | Connexion à flirt.adm.crans.org |
|
||||
# +---------------------------------+
|
||||
server: ldaps://flirt.adm.crans.org/
|
||||
promptpass: yes
|
||||
binddn: cn=admin,dc=adh,dc=crans,dc=org
|
||||
basedn: dc=adh,dc=crans,dc=org
|
||||
@end verbatim
|
||||
|
||||
et le mot de passe est disponible dans le password-store sous
|
||||
@code{ldap-adh}.
|
||||
|
||||
@subsubsection Utilisateur⋅ices
|
||||
|
||||
Les objets utilisateur⋅ices dispose des champs suivants :
|
||||
|
||||
@verbatim
|
||||
dn: cn=toto,ou=users,dc=adh,dc=crans,dc=org
|
||||
objectClass: inetOrgPerson
|
||||
objectClass: organizationalPerson
|
||||
objectClass: person
|
||||
objectClass: top
|
||||
cn: toto
|
||||
description: birthDate:1998-01-08
|
||||
description: birthLocation:Cachan
|
||||
description: membershipStart:20xx-xx-xx
|
||||
description: membershipEnd:20xx-xx-xx
|
||||
description: re2oId:xxxxx
|
||||
givenName: Toto
|
||||
mail: nobody [AT] crans [DOT] org
|
||||
postalAddress: 60 rue camille desmoulins, 94230, Cachan
|
||||
sn: Passoir
|
||||
telephoneNumber: +336xxxxxxxx
|
||||
userPassword: {CRYPT}$6$…
|
||||
@end verbatim
|
||||
|
||||
Le script @code{addadherent} du repo
|
||||
@url{https://gitlab.crans.org/nounous/crans-ldap, crans-ldap} permet
|
||||
néanmoins de configurer la plupart des informations à renseigner :
|
||||
|
||||
@verbatim
|
||||
[ _shirenn@flirt ] $ ./addadherent --re2o-id xxxxx toto
|
||||
Prénom: Toto
|
||||
NOM: Passoir
|
||||
Adresse email: nobody [AT] crans [DOT] org
|
||||
Adresse: 60 avenue camille desmoulins, 94230, Cachan
|
||||
Numéro de téléphone: +33600000000
|
||||
Date de naissance (YYYY-MM-DD): 1998-01-08
|
||||
Lieu de naissance: Cachan
|
||||
@end verbatim
|
||||
|
||||
Cela rajoutera automatiquement la date de début d'adhésion mais pas
|
||||
celle de fin d'adhésion, celle-ci doit être rajoutée à la main en
|
||||
utilisant votre client ldap favori.
|
||||
|
||||
@subsubsection Club
|
||||
|
||||
Les clubs sont des objets ldap très simple qui ne contiennent que le nom
|
||||
des adhérent⋅es qui gèrent le club :
|
||||
|
||||
@verbatim
|
||||
dn: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
|
||||
objectClass: organization
|
||||
objectClass: top
|
||||
description: toto
|
||||
o: rover
|
||||
@end verbatim
|
||||
|
||||
Similairement, un script permet de rajouter ces informations
|
||||
automatiquement au ldap :
|
||||
|
||||
@verbatim
|
||||
[ _shirenn@flirt ]$ ./addclub rover
|
||||
Pseudo du responsable: toto
|
||||
Pseudo du responsable: titi
|
||||
Pseudo du responsable:
|
||||
@end verbatim
|
||||
|
||||
@subsubsection Machines
|
||||
|
||||
Les machines sont des objets ldap qui répertorient des informations sur
|
||||
leur configuration et leurs propriétaires :
|
||||
|
||||
@verbatim
|
||||
dn: cn=curiosity,ou=hosts,dc=adh,dc=crans,dc=org
|
||||
objectClass: top
|
||||
objectClass: device
|
||||
objectClass: ipHost
|
||||
objectClass: ieee802Device
|
||||
cn: curiosity
|
||||
description: ip.icmp.in,ip.icmp.out,ip6.icmpv6.in,ip6.icmpv6.out,ip.tcp.out:0-65535,ip6.tcp.out:0-65535,ip.udp.out:0-65535,ip6.udp.out:0-65535,ip.tcp.in:22,ip6.tcp.in:22
|
||||
ipHostNumber: 185.230.78.199
|
||||
macAddress: 02:a0:00:01:99:12
|
||||
owner: o=rover,ou=clubs,dc=adh,dc=crans,dc=org
|
||||
serialNumber: 199
|
||||
@end verbatim
|
||||
|
||||
Le script @code{addadherenthost} crée la machine dans le ldap
|
||||
|
||||
@verbatim
|
||||
[ _shirenn@flirt ]$ ./addadherenthost --ip 185.230.78.199 --mac
|
||||
02:a0:00:01:99:02 --vmid 199 --club rover curiosity
|
||||
@end verbatim
|
||||
|
||||
|
||||
Le part-feu par défaut laisse passer tous les paquets icmp, tous les
|
||||
paquets en sortie et ne laisse rentrer que le port 22 en tcp, en ip
|
||||
legacy et en ipv6.
|
||||
|
||||
Une fois l'adhérent⋅e ou le club et la machine rajoutée dans le
|
||||
ldap. Les scripts devraient mettre à jour la configuration du parefeu,
|
||||
du dhcp et de proxmox.
|
||||
|
||||
@subsubsection Proxmox
|
||||
|
||||
Il faut maintenant aller sur le cluster constitué de gulp, odlyd et
|
||||
stitch pour créer la machine virtuelle. C'est du clic clic dans proxmox,
|
||||
vous êtes assez grand⋅es pour savoir lire des menus. (Par contre faites
|
||||
bien attention à créer les disques sur la pool @code{vm}).
|
||||
|
||||
Ensuite, deux possibilités, soit l'adhérent⋅e vous a juste demandé de
|
||||
créer la machine virtuelle et à ce moment là c'est fini et iel peut
|
||||
aller la configurer seul⋅e (c.f. section suivante), soit iel vous a
|
||||
demandé si vous pouviez lui installer une distribution de son choix.
|
||||
|
||||
Vous pouvez alors lui demander une clé publique ssh, et après avoir
|
||||
installé la vm, vous la déposez dans @file{/root/.ssh/authorized_keys}
|
||||
(en faisant attention à créer le @file{.ssh} avec les bonnes permissions
|
||||
@code{mkdir -m 0700 /root/.ssh}) et vous supprimez les mots de passe que
|
||||
vous avez rentrer pendant l'installation @code{passwd -d root}).
|
||||
|
||||
@node La suppression d'un⋅e utilisateurice
|
||||
@section La suppression d'un⋅e utilisateurice
|
||||
|
||||
Pour diverses raisons dont il n'est pas question de juger, un⋅e
|
||||
utilisateur⋅rice peut vouloir supprimer son compte Crans et les données
|
||||
associées. En particulier cela peut rentrer dans le cadre du
|
||||
@url{https://www.cnil.fr/fr/reglement-europeen-protection-donnees/,
|
||||
RGPD}. Il y a certaines informations qu'il faut garder une durée
|
||||
minimale, mais les autres doivent être supprimées à la demande de
|
||||
l'utilisateurice. C'est pénible mais faisable : respecter la volonté de
|
||||
l'utilisateur⋅rice dans ce cas est important. Ce petit guide est là pour
|
||||
rappeler tout ce qu'il ne faut pas oublier.
|
||||
|
||||
@subsection La demande de suppression
|
||||
|
||||
Il faut s'assurer que c'est bien la bonne personne qui fait la
|
||||
demande. En cas de doute, on peut demander une preuve d'identité (pièce
|
||||
d'identité, mail depuis l'adresse mail crans@dots{}). Ensuite, on peut
|
||||
vérifier que la personne à bien compris ce que la suppression de compte
|
||||
impliquait : la perte de toutes les données non sauvegardées par
|
||||
l'utilisateurice, ne plus avoir accès aux services qui nécessite un
|
||||
compte crans@dots{} Selon ce qui est demandé (et ce qu'on a le droit de
|
||||
faire), le compte peut être seulement archivé, on peut supprimer les
|
||||
données liées au compte (en totalité ou partie), voire les données d'un
|
||||
service non-lié à un compte crans (wiki@dots{}). Si la personne est
|
||||
encore adhérente, elle va probablement devoir démissionner de
|
||||
l'association.
|
||||
|
||||
@subsection Re2o
|
||||
|
||||
Il faut bien un début, c'est sur l'intranet qu'on commence par
|
||||
supprimer/archiver quelqu'un⋅e.
|
||||
|
||||
@subsubsection Archiver sur Re2o
|
||||
|
||||
Si la personne à une facture/adhésion de moins de 10 ans, on ne peut pas
|
||||
supprimer le compte. Dans ce cas-là, ou si c'est ce que préfère
|
||||
l'utilisateurice, on archive le compte : dans le profil, il faut changer
|
||||
l'état de "Actif⋅ves" à "Complétement archivé⋅es". On peut
|
||||
éventuellement supprimer certaines informations (bannissement,
|
||||
établissement@dots{}) mais on doit garder les informations de contact et
|
||||
les factures/adhésions de moins de 10 ans.
|
||||
|
||||
On peut repasser au bout des 10 ans pour tout supprimer (ça serait bien
|
||||
d'avoir un truc automatique ou que l'utilisateurice nous le rappelle).
|
||||
|
||||
@subsubsection Supprimer sur Re2o
|
||||
|
||||
Il faut aller dans l'interface d'administration
|
||||
@url{https://re2o.crans.org/admin/users/user/} et supprimer l'user. Il
|
||||
va falloir supprimer les objets protégés avant, django vous dira
|
||||
lesquels.
|
||||
|
||||
Ne pas oublier d'aller contrôler le LDAP sur @code{yson-partou} pour
|
||||
s'assurer que le compte a bien été supprimé. Pour cela, faire un
|
||||
@code{sudo shelldap} sur @code{yson-partou}, puis taper
|
||||
@code{cn=Utilisateurs} et s'assurer que @code{cat cn=@{pseudo@}} ne
|
||||
renvoie rien.
|
||||
|
||||
@subsection Zamok
|
||||
|
||||
Le plus évident, il faut supprimer le home ainsi que les mails.
|
||||
|
||||
Il suffit de faire un @code{sudo rm -rf /home/@{pseudo@}}, pour
|
||||
supprimer le home. De même pour les mails dans
|
||||
@file{/var/mail/@{pseudo@}}.
|
||||
|
||||
@subsection Backups
|
||||
|
||||
Étape non pressante, mais on peut se rendre sur @code{backup-ft} et
|
||||
@code{backup-thot} pour supprimer
|
||||
@file{/backup/borg-adh/home/@{pseudo@}}.
|
||||
|
||||
À faire avec précaution. Mais à faire puisqu'on ne garde pas des backups
|
||||
éternellement. Pas pour des raisons de place mais pour des raisons de
|
||||
non-conservation de données personnelles (même si les backup ne sont pas
|
||||
concernées par le RGPD).
|
||||
|
||||
@subsection Gitlab
|
||||
|
||||
S'il n'y a pas de compte, il n'y a rien à faire.
|
||||
|
||||
On se place dans l'hypothèse où l'on veut supprimer un compte. On
|
||||
commence par se rendre dans l'interface d'administration de Gitlab,
|
||||
section utilisateurs : @url{https://gitlab.crans.org/admin/users}. On
|
||||
se rend dans les paramètres du compte, on clique sur "Administration des
|
||||
utilisateur" puis sur "Supprimer un compte utilisateur" ou "Supprimer un
|
||||
compte utilisateur et ses contributions". Dans le deuxième cas, il faut
|
||||
faire attention surtout s'il y a des contributions à des projets
|
||||
partagés (comme ceux du crans).
|
||||
|
||||
@subsection Owncloud
|
||||
|
||||
Il suffit simplement de se rendre dans l'interface d'administration,
|
||||
section utilisateurices :
|
||||
@url{https://owncloud.crans.org/settings/users}, puis de chercher le
|
||||
compte et de simplement le supprimer.
|
||||
|
||||
@subsection Mailman
|
||||
|
||||
On commence par se rendre dans @url{https://lists.crans.org/admin/,
|
||||
Django-Admin}.
|
||||
|
||||
S'il n'y a pas de compte, aucune question à se poser.
|
||||
|
||||
S'il y a un compte, on le supprime.
|
||||
|
||||
Potentiellement, la personne est présente sur mailman de manière
|
||||
non-liée à son éventuel compte crans. Dans ce cas, il va falloir faire
|
||||
du ménage avec l'adresse mail et donc de l'aide de l'utilisateurice qui
|
||||
va devoir indiquer son adresse et les ML qu'iel reçoit/administre. Ça
|
||||
peut être un peu les bazar si il y a plusieurs adresses non-liées. Si la
|
||||
personne est lae dernièr⋅e propriétaire d'une liste, il faudra soit la
|
||||
supprimer soit lui trouver un⋅e nouvelleau propriétaire (c'est pas
|
||||
obligatoire mais alors c'est @email{root@@crans.org} le propriétaire par
|
||||
défaut, ce qui n'est pas une solution durable).
|
||||
|
||||
@subsection Wiki
|
||||
|
||||
Si la connexion par le CAS est configurée, il faut penser à @code{rm
|
||||
/var/local/wiki/assowiki/@{pseudo@}}. Concerne a priori peu de monde.
|
||||
|
||||
Si la personne le demande, on peut supprimer son compte wiki et les
|
||||
pages qui concernent son compte (page perso@dots{}), historique
|
||||
compris. Pour cela il faut aller sur @code{kiwi} et supprimer le dossier
|
||||
contenant la page. Cela peut concerner des personnes n'ayant pas de
|
||||
compte crans, mais il faudra le WikiNom.
|
||||
|
||||
@subsubsection The Lounge
|
||||
|
||||
S’il y a eu une utilisation de WebIRC, on peut aller sur Zamok et
|
||||
@code{rm /etc/thelounge/users/@{pseudo@}.json} (configuration), @code{rm
|
||||
/etc/thelounge/logs/@{pseudo@}} et @code{rm
|
||||
/etc/thelounge/logs/@{pseudo@}.sqlite3} (pour l'historique des
|
||||
messages).
|
||||
|
||||
@subsubsection Autres données
|
||||
|
||||
Il y a probablement des données personnelles qui trainent ailleurs, il
|
||||
faudra mettre à jour cette page si on en trouve. Par exemple, pour les
|
||||
membres actif⋅ves qui ont un compte underscore ou les utilisateurices
|
||||
qui ont (eu) une VM (perso ou de club).
|
||||
|
||||
@subsubsection Données hébergées mais pas administrée par le Crans
|
||||
|
||||
Le Crans héberge des VM pour les clubs (note, serveur photos, bdd
|
||||
med@dots{}) qui peuvent contenir des données personnelles. La personne
|
||||
devra aller voir les admins de ces services pour supprimer les données.
|
||||
|
||||
@node Comment devenir nounou ?
|
||||
@section Comment devenir nounou ?
|
||||
|
||||
Bonjour jeune apprenti⋅e, tu regardes sûrement avec des yeux pleins
|
||||
d'étoiles tes ainé⋅es qui actuellement disposent des droits suprêmes sur
|
||||
l'infrastructure du Crans. Ce petit document est là pour t'expliquer
|
||||
comment toi aussi un jour tu pourras devenir l'un⋅e d'elleux. Et quand
|
||||
il sera temps et que tu commenceras à t'encrouter, comment tu pourras
|
||||
rendre tes droits.
|
||||
|
||||
Déjà commençons par une question un peu conne mais néanmoins légitime
|
||||
``Qui "mérite" d'être nounou ?'' Premièrement, devenir nounou @b{N'EST
|
||||
PAS} une question de compétence. Pas besoin de connaître
|
||||
l'infrastructure par cœur, tous les fichiers de conf, être un pro d'apt,
|
||||
d'ansible et de la couche 2. Tout ce qu'on attend d'une nouvelle nounou
|
||||
c'est d'être capable de ne pas faire n'importe quoi avec ces
|
||||
droits. Devenir nounou ce n'est pas avoir fini son apprentissage mais
|
||||
bien la deuxième étape de celui-ci où on commence à mettre les mains
|
||||
dans le camboui. Et ça ça présuppose seulement qu'on va pas causer du
|
||||
tort en utilisant ces droits.
|
||||
|
||||
Détaillons-les un peu ces droits, ce qu'il permette de faire et qu'est
|
||||
ce qu'on entend par « causer du tort ». En devenant nounou, vous
|
||||
débloquez les accès à toute l'infrastructure. Techniquement, il n'y a
|
||||
plus de fichiers que vous ne pouvez pas voir, modifier ou supprimer et
|
||||
ce sur toutes les machines du Crans. De même, on chiffre pour vous tous
|
||||
les mots de passe qui ont trait au technique du Crans. Ce sont des
|
||||
droits très extensifs. D'où la possibilité de faire une erreur de
|
||||
manipulation. Normalement tout est fait dans l'infrastructure pour
|
||||
limiter la casse possible. On a de la redondance où c'est possible et
|
||||
nécessaire, on fait des backups quotidiennes à la fois des données
|
||||
utilisateur⋅rices mais aussi des données d'administration. Cependant,
|
||||
tout ça ne change pas le fait qu'une mauvaise commande rentrée dans
|
||||
votre shell peut rendre le Crans hors ligne pour quelques heures ou
|
||||
supprimer de manière irreversible des données. Quand vous devenez
|
||||
nounou, on vous fait confiance pour éviter ce genre de choses au
|
||||
maximum. Après les erreurs ça arrive toujours. La personne qui écrit ces
|
||||
lignes en a fait un certain nombre avec des conséquences diverses. Ce
|
||||
qui compte ce n'est pas de ne pas en faire du tout, c'est d'en faire
|
||||
peu, d'apprendre de celles-ci et de s'assurer qu'elles ne sont pas
|
||||
irréversibles.
|
||||
|
||||
Il y a aussi quelque chose qu'il faut souligner. Et normalement quand
|
||||
vous deviendrez nounou vous allez le voir assez fréquement (à chaque
|
||||
fois que vous faîtes un sudo pour la première fois sur une machine) :
|
||||
|
||||
@verbatim
|
||||
We trust you have received the usual lecture from the local System
|
||||
Administrator. It usually boils down to these three things:
|
||||
|
||||
#1) Respect the privacy of others.
|
||||
#2) Think before you type.
|
||||
#3) With great power comes great responsibility.
|
||||
@end verbatim
|
||||
|
||||
|
||||
Ce court texte résume bien ce que je veux aborder ici. Les droits que
|
||||
vous vous voyez confier sont une intrusion phénoménale dans la vie
|
||||
privée des gens. Si vous voulez une métaphore, vous pouvez voir ça comme
|
||||
si les adhérent⋅es du Crans vous avait donné la clé de leur maison pour
|
||||
que vous puissiez réparer quand il y a une fuite d'eau, mais pas pour
|
||||
que vous fouillez dans le bureau pour voir leurs papiers. Beaucoup de
|
||||
nos adhérent⋅es utilisent les outils qu'on met à leur disposition pour
|
||||
organiser une partie de leur vie, que ce soit d'utiliser l'adresse mail
|
||||
qui leur est fournie ou stocker des données dans leur Owncloud, et nous
|
||||
en sommes très heureux⋅ses. La charte que vous avez signé en devenant
|
||||
apprenti⋅e mentionne déjà ces problématiques mais il est important que
|
||||
ce soit très clair. @emph{Vous ne pouvez consulter ou diffuser les
|
||||
données personnelles d'un⋅e adhérent⋅e qu'avec son consentement
|
||||
explicite.} On a parfois tendance à l'ENS à faire des abus de droits une
|
||||
blague, ce n'est pas le cas au Crans !
|
||||
|
||||
Bon maintenant que ces clarifications et rappels ont été faits, on va
|
||||
pour passer aux choses plus intéréssantes : comment on se donne ces
|
||||
droits (et dans la marge, comment on se les retire) ?
|
||||
|
||||
@subsection Rentre dans le cercle
|
||||
|
||||
Le groupe des superadministrateur⋅rices au Crans est le groupe
|
||||
nounou. On va donc faire un petit tour dans le ldap et sous
|
||||
ou=groups,cn=_nounou on rajoute les uids correspondant au⋅x personne⋅s
|
||||
qu'on souhaite ajouter. Voilà, vous avez normalement:tm: les accès root
|
||||
sur toutes les machines du Crans. Cependant, vous allez peut-être
|
||||
constater qu'il y a certaines machines où cela ne fonctionne pas. C'est
|
||||
sûrement dû à ces (conneries) de replicat ldap. Il faut à ce moment là
|
||||
aller faire un tour dessus pour forcer la resynchro (@pxref{LDAP}).
|
||||
|
||||
@subsection Give me the password
|
||||
|
||||
Vous avez @b{50} nouveaux mot de passes. Il est maintenant nécessaire de
|
||||
rechiffrer le pass pour vous. C'est un peu chiant mais on s'y
|
||||
fait. Voilà la procédure:
|
||||
|
||||
@enumerate
|
||||
@item
|
||||
On se souvient du hash de commit courant : @code{HASH=$(git rev-parse
|
||||
HEAD)}
|
||||
@item
|
||||
On ajoute toutes les personnes concernées dans le groupe nounou dans le
|
||||
fichier @file{.groups.yml} du store et on commit ces changements
|
||||
@code{git commit -m toto1234}.
|
||||
@item
|
||||
On rechiffre tous les fichiers à rechiffrer @code{cat .last_group.json |
|
||||
jq -r '. | with_entries( select(.value | any( .== "nounou"))) | keys[]'
|
||||
| xargs pass rans reencrypt}
|
||||
@item
|
||||
On supprime tous les commits inutiles : @code{git reset --soft $HASH;
|
||||
git commit -m 'Coucou les ami⋅es'}
|
||||
@item
|
||||
On vérifie que ça marche et on push :)
|
||||
@end enumerate
|
||||
|
||||
Petit point pour quand on retire des droits au gens. Là où pour tous les
|
||||
autres droits, quand vous les retirez à quelqu'un⋅e bah iel les a plus,
|
||||
ce n'est pas le cas pour les mots de passe. Il reste dans l'historique
|
||||
de git un moment où la personne qui perds ces droits à toujours les mots
|
||||
de passes chiffrées pour elle. On choisit généralement de s'en
|
||||
tamponner l'oreille avec une babouche. Cependant, il peut y avoir
|
||||
certains moments où on veut effectivement retirer complètement à
|
||||
quelqu'un⋅e la possibilité d'utiliser un mot de passe. Dans ce cas il
|
||||
faut le changer :(
|
||||
|
||||
@subsection Thank you for your services
|
||||
|
||||
Au Crans on a @b{plein} de services. Certains sont gentils et écoutent
|
||||
directement le ldap pour savoir qui a des droits, d'autres s'en foutent
|
||||
et ils faut se rajouter dans les admins à la main. Petite liste ci
|
||||
dessous.
|
||||
|
||||
@subsubsection Gitlab
|
||||
|
||||
Il faut aller dans la zone d'administration, puis dans la liste
|
||||
d'utilisateur⋅ices et changez le profil de l'utilisateur⋅ice de regular
|
||||
à admin.
|
||||
|
||||
@subsubsection Mailman
|
||||
|
||||
Il faut se connecter normalement au logiciel, puis allez dans la section
|
||||
admin @url{https://lists.crans.org/admin}, dans la sous page
|
||||
utilisateur⋅rices, on peut rechercher les personnes concernées pour leur
|
||||
donner les deux statuts admin (accès à la zone d'administration) et
|
||||
superutilisateur (bypass tous les checks de droits).
|
||||
|
||||
@subsubsection Owncloud
|
||||
|
||||
Il faut aller dans la zone d'administration et rajouter les
|
||||
utilisateur⋅ices au groupe d'administration.
|
||||
|
||||
@subsubsection Re2o
|
||||
|
||||
Oh lad, j'espère que ça aussi ça existe plus. Il faut aller dans la
|
||||
section gestion des groupes et rajouter les personnes aux groupes
|
||||
nounous et au groupe superutilisateur⋅rice.
|
||||
|
||||
@subsubsection Kiwi
|
||||
|
||||
On édite le fichier de conf du wiki sous @file{/etc/moin/mywiki.py} et
|
||||
on rajoute son compte wiki dans la liste des administrateur⋅rices.
|
||||
|
||||
@subsubsection IRC
|
||||
|
||||
On édite le fichier @file{/etc/inspircd/opers.conf} pour rajouter un
|
||||
bloc suivant
|
||||
|
||||
@verbatim
|
||||
<oper
|
||||
name=<nick>
|
||||
password="<pass-hash>"
|
||||
hash="sha256"
|
||||
host="*"
|
||||
type="Deity"
|
||||
fingerprint="<fingerprint certificat>"
|
||||
autologin="on"
|
||||
>
|
||||
@end verbatim
|
||||
|
||||
|
||||
Où le hash du mot de passe peut être obtenu en envoyant @code{/quote
|
||||
mkpasswd hmac-sha256 <password>}. Pour rendre les changements effectifs
|
||||
on reload le service inspircd (tips, la manière la plus rapide de perdre
|
||||
ses droits est de restart le serveur plutôt que de le reload ^^).
|
||||
|
||||
@subsubsection Mails
|
||||
|
||||
Il faut maintenant vous rajouter en alias de
|
||||
@email{root@@crans.org}. C'est le début du spam. Pour ce faire,
|
||||
rendez-vous sur le dépôt Gitlab @code{mail-aliases}, et ajoutez votre
|
||||
pseudo Crans sur la bonne ligne dans les bons fichiers, en face de
|
||||
@code{root:}. Pensez ensuite à mettre à jour le dépôt pour le service
|
||||
@code{mail}, et enfin mettez bien à jour @code{redisdead},
|
||||
@code{sputnik} et surtout @code{zamok} dans le dossier
|
||||
@file{/var/local/services/mail}. Enfin, pensez bien à filtrer les mails
|
||||
arrivant à l'adresse @email{root@@crans.org} sur votre client.
|
||||
|
||||
Voilà, tu as maintenant gagné le droit de t'ajouter ou de te retirer de
|
||||
@url{<https://wiki.crans.org/CransNounous} !
|
||||
|
||||
@node CONTRIBUTING
|
||||
@chapter Contributing
|
||||
|
||||
TODO.
|
||||
|
||||
@node Tools
|
||||
@chapter Tools
|
||||
|
||||
@menu
|
||||
* LDAP::
|
||||
@end menu
|
||||
|
||||
@node LDAP
|
||||
@section LDAP
|
||||
|
||||
TODO.
|
||||
|
||||
@node Index
|
||||
@unnumbered Index
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue