Arnaud Daby-Seesaram
parent
8e88d026a3
commit
8a41feffbd
972
crans.texi
972
crans.texi
|
|
@ -55,6 +55,9 @@ The document was typeset with
|
||||||
|
|
||||||
@menu
|
@menu
|
||||||
* Comptes rendus::
|
* Comptes rendus::
|
||||||
|
* How-Tos::
|
||||||
|
* CONTRIBUTING::
|
||||||
|
* Tools::
|
||||||
* Index::
|
* Index::
|
||||||
@end menu
|
@end menu
|
||||||
|
|
||||||
|
|
@ -80,6 +83,7 @@ car le tri par date se fait plus simplement).
|
||||||
* CR Template::
|
* CR Template::
|
||||||
* 2024 01 13::
|
* 2024 01 13::
|
||||||
* 2024 06 22::
|
* 2024 06 22::
|
||||||
|
* 2024 08 29::
|
||||||
@end menu
|
@end menu
|
||||||
|
|
||||||
@node CR Template
|
@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
|
GaBo a été désigné grand gagnant de qui s'occupera de la documentation
|
||||||
d'Ansible.
|
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
|
@node Index
|
||||||
@unnumbered Index
|
@unnumbered Index
|
||||||
|
|
||||||
|
|
|
||||||
Loading…
Reference in New Issue