638 lines
30 KiB
Markdown
638 lines
30 KiB
Markdown
# Réunion IN
|
|
|
|
* Date : Dimanche 26 juillet 2025
|
|
* Lieu : Galène
|
|
* Début : 14h02
|
|
* Fin : 18h18
|
|
|
|
## présent⋅es
|
|
|
|
Lzebulon
|
|
Hachino
|
|
Rigobert
|
|
Itsukushimu (invité par Hachino, SysAdmin dans une boîte,
|
|
présent pour parler du setup Ceph)
|
|
Lyes
|
|
Pigeon Moelleux
|
|
Pyjacpp
|
|
EnzoHenry
|
|
RDB
|
|
|
|
## Ordre du jour
|
|
|
|
[Hachino] INFO : l'imprimante imprime ! \o\ \o| |o| |o/ /o/
|
|
[korenstin] INFO : modification des scripts pour le DNS et le firewall
|
|
afin de permettre au club de ne plus avoir de membre avec une connexion
|
|
internet valide
|
|
[Hachino] INFO : passage des rejets respbats@ en /ignore à la place
|
|
(cf paramètres de la ML > Acceptation de message)
|
|
[Hachino] Templates mailman, le retour : ajout du lien de modération dans `list:admin:notice:pending`
|
|
(les rappels quotidiens de modération)
|
|
Cf <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/templates.html#templated-texts>
|
|
[Hachino] Nous avons un invité qui accepte de nous partager ses connaissances
|
|
en Ceph (point à passer en premier ou dès qu'il est là)
|
|
[Jeltz] Federez souhaite une VM légère, à usage interne
|
|
[Hachino] Review des issues sur le Nounous/Documentation ?
|
|
Certaines ont l'air en pratique résolues (`ansible`).
|
|
[Hachino] Limiter la taille que peut prendre journalctl ?
|
|
Jitsi râle sur son espace disque et /var/log/journal occupe 1,6 Go, à coups de
|
|
72 Mo/fichier.
|
|
Il suffirait d'ajouter SystemMaxUse=7d (ou autre durée < 14d) pour calmer le problème.
|
|
Gitzly idem.
|
|
Cas de Gitzly : probablement des restes des runners sur le repo NixOS
|
|
(d'après Lzebulon) (pour /journal),
|
|
[Pigeon] Mise à jour galène (RPZ Hachino en AGO pile à ce moment) (b;___;)b
|
|
-> on active les nouvelles options un peu sympa ?
|
|
Deux potentiellement peuvent être intéressantes : LDAP et background blur
|
|
[Hachino] Le callback sur lists.crans.org et Anubis
|
|
"regle" mais c'est moche
|
|
[Lzebulon] OIDC
|
|
keycloack ?
|
|
zitadel, authelia, authentik ?
|
|
j'ai oublie le nom mais Lyes a trouve un truc
|
|
dev interne d'une app ? modif du cas ?
|
|
[Lzebulon]
|
|
coupure ete pour mise à niveau + test fonction de redondance des routeurs :
|
|
proposition : fin juillet ou fin aout mais avant septembre
|
|
[Lzebulon] bon, euh, ceph ?
|
|
[Lzebulon] ca serait bien de faire avant la rentrée (rentrée = 1er septembre) :
|
|
collabora/onlyoffice (pour pouvoir faire une demo à l'amphi de rentrée x)
|
|
nextcloud ajout integration roundcube (integration officiel, du moins pub
|
|
sur leur site officiel)
|
|
[Rigobert] Sinon, dans un souci de modularité, serveur DAV ?
|
|
boulot partage du CA/IN :
|
|
tour des sites, mise à jour des info : on peut retirer qu'on ne fournit
|
|
plus de réseau à Cachan ?
|
|
actualiser services sur intranet.crans.org :
|
|
remplace owncloud par nextcloud ? (pareil sur crans.org ?)
|
|
mise à jour sur wiki.crans.org ou attente de mediawiki ?
|
|
debut plan Seminaire (je dis ca alors que je pourrai pas etre present en
|
|
presentiel x)
|
|
enregistrer/diffuser en direct sur galene/jitsi/peer.tube ?
|
|
matrix
|
|
connection de synapse à jitsi pour permettre des appels videos/audio
|
|
serveur notice : <https://element-hq.github.io/synapse/latest/server_notices.html>
|
|
Documentation utilisateurice
|
|
[Pigeon] -> À partir du moment où on se décide de quoi déployer,
|
|
je peux en faire des paquets sur tous les services du Crans
|
|
Il faudrait faire la liste des services prioritaires sur lesquels faire de la doc
|
|
Exemples donnés : Matrix, Nextcloud, Mail
|
|
[Lzebulon] debut reflexion projet de l'année prochaine :
|
|
ceph ?
|
|
oidc
|
|
peertube
|
|
full CI/CD/Builder nixos
|
|
mise à jour debian/proxmox
|
|
isc-dhcp deprecie
|
|
dovecot change config (<https://www.debian.org/releases/trixie/release-notes/issues.en.html#dovecot-configuration-changes>)
|
|
openldap (je sais pas si ca change quelque chose j'ai pas plus check) (<https://www.debian.org/releases/trixie/release-notes/issues.en.html#openldap-tls-now-provided-by-openssl>)
|
|
potentiel probleme de changement de nom d'interface reseau avec la mise à jour proxmox
|
|
[Rigobert] <https://gitlab.aliens-lyon.fr/AliENS/old-permit>
|
|
[Rigobert] Crab.fit
|
|
[Rigobert] Mattermost / Taiga pour Kanban pour les assos
|
|
[censured] aka le projet mort vivant mais qui mets du temps à mourir
|
|
[Pigeon] Le fait qu'on en parle encore relève du miracle/nécromancie
|
|
[Lzebulon] improve security <https://developer.mozilla.org/en-US/observatory>
|
|
[Pigeon] Configuration peertube
|
|
Proposition d'infrastructure :
|
|
1 VM (peertube) qui contient que le serveur avec le client web
|
|
n VM (peertube-runnner-X) qui vont faire le transcodage pour ne pas surcharger peertube
|
|
On peut facilement en ajouter/retirer donc c'est pratique de faire comme ça
|
|
n = 2 me paraît être un début largement suffisant
|
|
Stockage ? Pool sur ceph (lol) ou sur cameron me paraît adapté
|
|
cameron, mais limite d'upload par user -> Oui évidemment
|
|
Backups
|
|
Backuper de la vidéo c'est environ équivalent à juste copier le fichier, faire
|
|
des backups différentielles ne fait gagner quasiment aucune place
|
|
(On en ferait quand même mais c'est pour prévoir l'espace disque nécessaire)
|
|
[Lzebulon] dhcpd en fin de vie : <https://www.isc.org/dhcp/>
|
|
-> maintenant c'est kea ? & stork (interface monitoring kea & bind) ?
|
|
demande de refaire/modifier le script pour donnée accès à internet
|
|
[Lz] reverse proxy et nixos
|
|
[Lzebulon] sputnik git2.crans.org : gitea (MIT) -> forgejo (GPLv3+) ?
|
|
ou au moins mise à jour
|
|
[Lzebulon] moyen de tracker la version nixpkgs de la flake utilise pour chaque
|
|
vm nixos (dashboard grafana) ?
|
|
interet : savoir quel serveur mettre a jour
|
|
[Lzebulon] imap recherche textuel longue : dovecot fts plugin
|
|
|
|
## Présentation de Itsukushimu, en parlant de Ceph
|
|
|
|
A installé tout seul un cluster dans sa boîte, puisque l'ancien cluster devait
|
|
passer de version 10 à 18
|
|
Le plus difficile est d'atteindre les specs minimales pour faire tourner Ceph
|
|
(disque augmente => besoins en RAM et CPU augmentent)
|
|
10G minimum en connexion interne, 1G c'est non
|
|
Les devs se sont concentrés sur le SSD, il faut au moins faire de l'hybride pour
|
|
passer Loadbalancing probablement à prévoir (non mis en place pour l'instant)
|
|
|
|
Présentation de Lzebulon de l'infra :
|
|
2 clusers, 3 hyperviseurs
|
|
Chaque cluster a un serveur de stockage dédié dans lesquels sont stockées les VMs
|
|
Actuellement, Full HDD avec NFS
|
|
Une machine achetée pour faire du Ceph est en attente, avec plein de stockage,
|
|
quasi vierge
|
|
On voudrait rajouter Ceph au-dessus des deux serveurs de stockage déjà remplis
|
|
-> C'est assez pour le quorum
|
|
|
|
-> Tous les trucs de Ceph sont logiciels,
|
|
les points d'entrée sont les service monitors (il en faut minimum 3 pour le quorum)
|
|
-> Les OSD sont les unités de stockage, chaque Daemon utilise un disque entier
|
|
crush map = carte de l'infra par ceph
|
|
osd = unité de stockage, disque = osd, le démon utilise un disque entier pour y
|
|
stocker de la donnée
|
|
service manager donne accès à plein de services variés : dashboard, api,
|
|
metrology, gestion plugins divers, etc
|
|
|
|
Répartition des données : quand un client arrive sur le monitor,
|
|
le monitor prend la donnée, la découpe, les met dans des placement groups et en
|
|
suivant l'algo de la crush map, il va répartir les placement groups sur tel osd
|
|
ou tel autre.
|
|
Nous, dans la manière dont est config le stockage,
|
|
le placement group est répliqué deux fois, trois fois, etc.
|
|
Stockage effectif != stockage réel.
|
|
|
|
2-3 trucs à savoir : le poids pour un disque calculé par un algo de Ceph
|
|
(c'est une préférence, basée sur la taille).
|
|
Gros disque => gros poids => Ceph va plutôt stocker sur celui-là.
|
|
Mieux d'avoir des disques uniformes.
|
|
|
|
Specs à respecter : même pour un petit workload, le minmum vital c'est 4 Go RAM/osd
|
|
(ici, 4 Go/disque). Ça pique sa grand-mère.
|
|
Ensuite, service monitor et autres vont auss iconsommer de la mémoire.
|
|
Pas forcément beaucoup (surtout le monitor), mais il faut prévoir du rab.
|
|
Environ 4 Go pour le monitor.
|
|
|
|
Les specs et modèles du hardware du Crans, pas très uniforme
|
|
(donc risque de ralentir le tout) : <https://gitlab.crans.org/nounous/documentation/-/blob/master/infrastructure/machines/serveurs.md>.
|
|
En effet, Ceph peut être très demandeur en CPU, deuxième bottleneck après le SSD.
|
|
|
|
Possibilité : hybride. Un SSD pour plusieurs OSD, qui va héberger
|
|
(me manque des choses) le dbdevice,, le WAL, etc. Bien quand full SSD = trop cher.
|
|
Si hybride, mieux vaut mettre un SSD qui va gérer au max 4 OSD.
|
|
Le dbdevice est obligatoirement sur le même serveur que l'OSD.
|
|
Au niveau applicatif, dans /var/lib/ceph/cluster-id/osd-id, si tu fais `ll`,
|
|
t'auras deux points de montage de /dev (des volumes LVM) :
|
|
le dbdevice et l'osd lui-même pour héberger les données.
|
|
|
|
Si des gens sont plus orientés dev, la techno pour les metadata c'est bluestore,
|
|
basé sur rocksdb.
|
|
|
|
Autre recommandation, même si il est assez vieux ça reste vrai sur la partie
|
|
hardware : <https://yourcmc.ru/wiki/Ceph_performance>
|
|
Faire attention toutefois sur la partie "bluestore/filestore", elle ne tient plus
|
|
(trop datée). Ceph s'est beaucoup amélioré depuis sur ces sujets.
|
|
Question de Lz : comment o ntombe sur un Wiki en russe ?
|
|
Réponse d'Itsu : quand t'as lu la doc officielle, faut chercher par toi-même.
|
|
"Google fu".
|
|
Commencé à bosser dessus en juillet 2023, le cluster est devenu viable à la fin
|
|
de 2024, 1 an et demi de taf (avec d'autres choses à côté au taf, genre l'hyperviseur).
|
|
beaucoup de temps de debug, à comprendre les fondamentaux.
|
|
|
|
Sur la migration des données, ça dépend si tout le NFS est plein ou si on a de
|
|
la place en rab. On peut migrer les données au fur et à mesure, un disque à la fois.
|
|
Pigeon : on a 20 To de libres sur cameron (un des serveurs cephables),
|
|
plus cephiroth et tealc
|
|
Combien de disques contient un serveur de stockage ? Normalement 10-12.
|
|
Lyes : l'idée de Ceph est que ça soit totalement distribué,
|
|
mais comment un autre serveur accès à Ceph ?
|
|
C'est une question de base, pour comprendre.
|
|
Itsu : t'as trois manières d'accéder à Ceph pour stocker des données.
|
|
|
|
* La plus "hyperviseur-friendly" : rbd, rados block device.
|
|
|
|
Quand tu instancies ta VM, tu lui dis de se connecter à telle pool,
|
|
tel nom d'image et écrire les donénes dans une image rbd.
|
|
Elle est dispatchée sur les différents serveurs.
|
|
|
|
* On la fera probablement pas, mais cephfs.
|
|
|
|
Plus lourd à mettre en place : pool dédié à cephfs, puis aux metadata de cephfs
|
|
et il est recommandé d'être full SSD.
|
|
Monté comme un share NFS.
|
|
|
|
* Pas VM friendly, le rados-getaway, pour faire du stockage objet
|
|
|
|
(façon Amazon S3/MinIO).
|
|
Bien pour du git, mais pour de l'hébergement de VM pur, c'est pas adapté.
|
|
Nextcloud, c'est compatible ? À voir, mais de toute façon ça demande du SSD.
|
|
Et il faut tester en conditions réelles.
|
|
Ceph fournit un dashboard Grafana complet et très bien fait.
|
|
|
|
Itsu : j'ai jamais fait de proxmox avec du Ceph,
|
|
donc faut voir dans la doc comment ça s'intègre avec rbd.
|
|
Est-ce que le proxmox va directement instancier les images ou est-ce qu'il faut
|
|
les plugger sur la VM ? C'est à regarder.
|
|
Lz : normalement ça s'intègre bien, c'est la façon standard de faire du stockage
|
|
distribué sous Proxmox.
|
|
|
|
Lyes : autre question, on avait comme projet de changer l'OS des machines de stockage.
|
|
Itsu : conseille Ubuntu 22.
|
|
Lyes : on avait en tête NixOS
|
|
Itsu : toujours Ubuntu 22. Parce que c'est testé.
|
|
Ceph est encore en train d'essayer de le faire marcher sur Ubuntu 24.
|
|
Chaque daemon est dans un Docker.
|
|
Ça semble un peu hasardeux, mais ça change la vie pour la MCO du cluster
|
|
et les mises à jour. Pour avoir tenté une upgrade de version à l'ancienne
|
|
vs une upgrade de 17 à 18 puis 19, ça n'a rien à voir, le jour et la nuit.
|
|
Autre truc, il faut être dans un environnement maîtrisé quand on fait de la prod.
|
|
Des distribs annexes pour du lab etc, ok, pour du socle infra, c'est vital de
|
|
respecter à le lettre les recos du provider.
|
|
Surtout que, truc tout bête, ça utilise Docker mais pas la dernière version.
|
|
On a envie d'utiliser docker-ce à la place.
|
|
|
|
Faut faire gaffe : potentiellement, Ceph utilise des features dépréciées de
|
|
Docker, supprimées dans la dernière version !
|
|
De manière générale, faire gaffe aux dépendances. Pourquoi Ubuntu ?
|
|
Pour des raisons de version de kernel
|
|
Avec de grosses pincettes, vérifiez bien, je crois que Ubuntu 22 avec les
|
|
proposed ou les backports, a un kernel plus récent que les backports de
|
|
Debian 12. Jamais sid en prod.
|
|
|
|
Ubuntu vs Debian ? Debien 12 a un kernel en 6.1, qui commence à se faire vieux
|
|
(la 13 arrive).
|
|
Même le 6.8 ça commence à dater.
|
|
En ce moment, le dev du kernel Linux a explosé
|
|
(dans le bon sens, plein de features cools ajoutées en core).
|
|
Lyes : avantage de NixOS : conf déclarative.
|
|
Itsu : documentez. À fond. je me suis fait suer à faire uen doc de taré pour que
|
|
quand je pars du taf, n'importe qui peut réinstancier un cluster. Et Ansible.
|
|
Lyes : on en a un, mais à chaque fois on dévie.
|
|
Itsu : au taf on a fait une CI/CD avec Ansible exec toutes les 30 min.
|
|
Si quelqu'un fait une modif à la main, il se fait taper sur les doigts.
|
|
Je sais que vous êtes associatifs, je suis un peu par dessus la jambe aussi,
|
|
mais quand on fait du socle, tu veux zéro dérive.
|
|
Sans Puppet/Ansible avec CI/CD, c'est compliqué pour la perénnité.
|
|
je comprends l'argument pour la perennité de NixOS, il est valide.
|
|
Cependant, en pensée "loi de Murphy", sur un compo critique, tu veux éviter
|
|
le moindre risque qu'il te pète entre les mains.
|
|
Qu'est-ce qu'on peut faire pour ça ?
|
|
Problème de micro de Pigeon, oupsi.
|
|
Pigeon (revenu) : pour le passage de Ansible à NixOS,
|
|
je suis celui qui a le plus vu la transition.
|
|
La transition s'est faite assez difficilement, avec perte totale de connaissance.
|
|
Le creux était l'année dernière, plus personne savait comment fonctionnait Ansible
|
|
et l'infra en général, tous les gens qui savaient étaient partis.
|
|
On s'est dit qu'on allait toucher le moins possible à ce qui existe déjà,
|
|
documenter au max et plein de trous dans l'Ansiblisation,
|
|
avec des scripts maisons pas documentés et pas reproductibles.
|
|
Quelques personnes très intéressées par NixOS pour la reproductibilité,
|
|
le principe de mutatiblité.
|
|
Dans Ansible, même ce qui était écrit dans la conf n'était pas réellement déployé.
|
|
Itsu : Ansible sert à déployer, pas à maintenir en conditions, c'est le boulot
|
|
de Puppet. Mais Puppet "au secours, pfffff" (dixit).
|
|
On est passés au taf à Ansible pour l'IaC, en le détournant un peu.
|
|
Pigeon : Ansible est peut-être un peu trop gros pour nos besoins.
|
|
Réécrire toute une conf Ansible pour un exemplaire de chaque service, c'est un peu
|
|
pénible. Je suis pas certain qu'il soit une bonne idée de mettre Ceph sur NixOS.
|
|
Je préfère plutôt Debian à Ubuntu si possible.
|
|
Itsu : en vrai ça peut peut-être se faire, mais regardez bien le kernel.
|
|
Lyes : Ceph et les dépendances ?
|
|
Itsu : pour le kernel, histoires de perfs.
|
|
Dépendances qui pourraient casser : Docker. Version 27 sur Ubuntu 22,
|
|
dernière version 28.xx, plein de fonctionnalités dépréciées en 27
|
|
supprimées en 28.
|
|
T'es pas sûr que ton cluster démarre si t'as pas la bonne version.
|
|
Lyes : Ceph sur NixOS semble marcher directement sur le système, ce qui est terrifiant.
|
|
Itsu : est-ce que tu sais déployer les composants de ceph et créer un cluster
|
|
sur NixOS ? Teste avec trois machines et regarde.
|
|
Si ça marche et que tu garantis stabilité et fonctionnement, pourquoi pas.
|
|
Lz : mise à jour ?
|
|
Itsu : normalement fait par ceph-adm, qui instancie l'orchestrateur,
|
|
provisionne les osd, etc.
|
|
Mieux qu'à l'époque où il fallait installer à la main ceph-manager, ceph-rbd, etc.
|
|
Je déconseille complètement NixOS, ça complexifie les choses et
|
|
neuf chances sur dix que ça se transforme en legacy.
|
|
Avec ceph-adm, on peut le faire en batch :
|
|
si il y a trop de workload, on va le faire osd par osd, un par un tranquillement.
|
|
Lz : cycle de mise à jour ?
|
|
Itsu : au bon vouloir des devs, pas régulier genre un fois par an.
|
|
Regardez le site officiel, la doc est bonne et les annonces de versions
|
|
y sont faites. (Calendrier des versions 17 à 19).
|
|
J'ai attendu 19.2.1 pour faire les migrations, pour laisser passer la première vague.
|
|
Première install en 17, upgrade en 18, trash et reprise en 18, upgrade en 19.
|
|
Lyes : si on part avec Docker, comment on sait quelel version est compatible ?
|
|
Itsu : Ceph est dev pour tourner sur des distribs.
|
|
Ceph 19 a été testé sur Ubuntu 20, 22 et ....
|
|
(voir ce lien : <https://docs.ceph.com/en/latest/start/os-recommendations/>)
|
|
Platform = install manuelle, container = passage par Docker,
|
|
recommande la deuxième option
|
|
Lyes : on configure comment, avec ceph-adm ?
|
|
Itsu : la doc officielle, tu vas pouvoir config par le dashboard en partie.
|
|
Ce que tu peux faire en GUI, tu peux le faire (et dix fois plus encore) en CLI.
|
|
Prometheus + Grafana directement intégré dans ceph-adm, par des iframes.
|
|
On utilise un petit logiciel contenairisé, prom2twillio (?),
|
|
qui permet d'envoyer les alertes à nos téls d'astreinte
|
|
Itsu : si vous avez besoin d'aide pour la conf, je peux donner un coup de main
|
|
rapide si ça bloque, si il faut rentrer dans le détail.
|
|
Pour les SSD, prenez des enterprise-grade, un ou deux SSD de journalisation,
|
|
il faut qu'il ait des condensateurs (enterprise-grade uniquement).
|
|
Quand t'as une coupure de courant, il a le temps d'aller commit ses écritures
|
|
dans les cellules.
|
|
Sorte de mini-onduleur, si on veut. Les SSD ont un petit cache en écriture,
|
|
quand tu le désactives sur les vesions entreprise-grade, les perfs augmentent.
|
|
Un type explique ça sur un Wiki, à lire.
|
|
Itsu : vous auriez 8 disques par serveur, donc 24 disques et 6 SSD
|
|
si j'ai bien compris. Il faut essayer d'avoir le même nombre d'osd par serveur,
|
|
même nombre de disques, même taille de stockage,
|
|
sinon déséquilibre dans la répartition des données.
|
|
Un déséquilibre ça peut potentiellement engranger des problèmes de stabilité et
|
|
d'intégrité si on perd un noeud. La crush map essaye d'être le plus efficace possible.
|
|
Si on a 10 disques+10+40 sur le troisième serveur. Dans ce genre de cas,
|
|
on peut avoir des données répliquées sur le même serveur, un peu con si on le perd.
|
|
Lyes : des configs déjà prêtes d'Ansible pour Ceph ?
|
|
Itsu : non, dépréciées.
|
|
Conseille le bootstrap à la main et de vous casser les dents dessus,
|
|
c'est en faisant qu'on apprend.
|
|
Comprendre comment les choses s'intègrent les unes avec les autres.
|
|
Je vais ptet faire une présentation, celle de mon chef d'il y a des années.
|
|
Pas très à jour, mais pour les concepts ça ira. Je pourrai vous partager des
|
|
sortes de confs, des exemples que j'ai faits de mon côté pour le maintien en conditions.
|
|
(Petite blague sur openStack)
|
|
Itsu : par contre, openNebula... (?)
|
|
(Présentation rapide)
|
|
MON : cerbère, ...
|
|
OSD : object storage device, vérifie son état et remonte au MON, stocke la donnée.
|
|
On peut avoir plusieurs OSD sur un disque dur, mais c'est de la folie furieuse.
|
|
Personne ne fait ça, jamais.
|
|
Ceph MDS, metadata software. MDS utilisé pour le stockage FS,
|
|
sauvegarde toutes les infos
|
|
Ceph MGR : version Kraken nouveau daemon qu ifournit du monitoring supplémentaire,
|
|
interface pour le monit externe.
|
|
Si les services managers tombent, en théorie c'ets pas grave, les deux les plus
|
|
critiques c'est MON et OSD.
|
|
Ceph RGW gateway, permet de faire du stockage objet
|
|
Specs minimales montrées plus trop à jour
|
|
Recommandé de séparer les réseaux : cloisonnement accès/réplications,
|
|
permet de libérer "accès" pour les accès clients,
|
|
jumbo frame mandatory en plus du 10G
|
|
Ceph autodimensionne la partition e nfonction de la taille de l'OSD.
|
|
5% de la taille de l'OSD réservée à ... un truc nécessaire aux metadata
|
|
Un placement groupe contient des fragments de données.
|
|
Contacte le MON, le MON contacte la pool et la CRUSH map rentre en jeu.
|
|
Premier passage pour savoir si on assigne à l'objet à un PG ou si on en crée
|
|
un novueau, la crush map refait un passage et regarde dans quel OSD il peut
|
|
stocker le PG. En fonction du nombre de réplicats (k),
|
|
le PG va être écrit sur k autres OSD.
|
|
Rebalancing : si on rajoute un OSD, le crush map remappe les PG sur les osd
|
|
CRUSH : controlled replication under scalable hashing Je l'ai jamais touchée,
|
|
juste extraite une fois pour la lire, mais comme on a une iso-config sur nos trois
|
|
neouds, la crush map était déjà configurée
|
|
Ceph permet la substitution : si un disque tombe,
|
|
la crush map va automatiquement en chercher un autre, qui marche,
|
|
pour jouer son rôle, en gardant le statut "master" ou "replica"
|
|
La crush map fonctionne avec des arbres (au sens des graphes)
|
|
Exemple tout bête dans lequel on peut modifier une crush map :
|
|
quand on a un cluster mixte, avec des HDD, on exclut les HDD du calcul.
|
|
Une crush map = un fichier de config en gros, avec une syntaxe propre.
|
|
En principe, avec une seule salle et trois serveurs, on devrait pas avoir à y toucher,
|
|
c'est pour la culture.
|
|
Pour l'exemple "pas de HDD", ça se fait avec une ruleset, faut aller lire la doc.
|
|
`ceph osd tree` permet de voir l'infra
|
|
Crush map = format binaire, faut décompiler/recompiler pour la changer
|
|
(lire la doc)
|
|
Reste une partie sur l'auth, mais pas très importante maintenant
|
|
|
|
L'essentiel est dit, je peux passer faire une review de la conf
|
|
ou aider ponctuellement à la construction.
|
|
Si pas de stockage objet et bon cloisonnement,
|
|
on peut supprimer les mitigations anti-Spectre/meltdown pour gagner en perfs.
|
|
On l'a fait au taf, en virt c'est une catastrophe.
|
|
Pas avec des serveurs à l'extérieur, là c'est non.
|
|
Truc marrant : rien qu'avec le Nextcloud côté user, sans les mitigations,
|
|
tu peux accéder à l'hyperviseur.
|
|
Critère : pas d'accès à l'extérieur, pas d'acceptation de connexion depuis Internet.
|
|
C'est trop dangereux.
|
|
|
|
Pensez à mettre une passe sur les mises à jour firmware etc avant de passer à Ceph,
|
|
firmware carte réseau idem.
|
|
|
|
Contact possible par Discord (username pas dur). Au pire Hachino peut faire le
|
|
lien sans problème.
|
|
|
|
## INFO : l'imprimante imprime ! \o\ \o| |o| |o/ /o/
|
|
|
|
Lzebulon ne coupe plus le switch quand il le configure, deuxième victoire. Applaudissements.
|
|
Pigeon : envisageable de guider à distance quelqu'un qui est dans la salle serveurs,
|
|
parce que j'habite loin. Lz pourrait aussi.
|
|
|
|
## INFO : modification des scripts pour le DNS et le firewall
|
|
|
|
Afin de permettre au club de ne plus avoir de membre avec une connexion internet
|
|
valide
|
|
|
|
## INFO : passage des rejets respbats@ en /ignore à la place
|
|
|
|
(cf paramètres de la ML > Acceptation de message)
|
|
|
|
## Templates mailman, le retour
|
|
|
|
Demande d'ajout du lien de modération dans `list:admin:notice:pending`
|
|
(les rappels quotidiens de modération)
|
|
|
|
Cf <https://docs.mailman3.org/projects/mailman/en/latest/src/mailman/rest/docs/templates.html#templated-texts>
|
|
Hachino : je demande parce que j'ai pas les droits pour le faire moi-même ;_;
|
|
|
|
## Federez souhaite une VM légère, à usage interne (un DNS)
|
|
|
|
Voudraient les utiliser pour nottament déployer une suite numérique.
|
|
Faut-il faire adhérer Fédérez ? Et leur faire payer la VM ?
|
|
À revoir en CA, avis informel : tout le monde est pour
|
|
|
|
## Review des issues sur le Nounous/Documentation ?
|
|
|
|
Certaines ont l'air en pratique résolues (`ansible`)
|
|
|
|
Hachino : Certaines issues ne sont-elles pas déjà finies, et à fermer ?
|
|
Exemple 1 : <https://gitlab.crans.org/nounous/documentation/-/issues/8>
|
|
Exemple 2 : <https://gitlab.crans.org/nounous/documentation/-/issues/6>
|
|
débat sur séparation ou non
|
|
|
|
## Limiter la taille que peut prendre journalctl ?
|
|
|
|
Jitsi râle sur son espace disque et /var/log/journal occupe 1,6 Go,
|
|
à coups de 72 Mo/fichier.
|
|
Il suffirait d'ajouter SystemMaxUse=7d (ou autre durée < 14d) pour calmer le problème.
|
|
Gitzly idem
|
|
|
|
Cas de Gitzly : probablement des restes des runners sur le repo NixOS
|
|
(d'après Lzebulon) (pour /journal)
|
|
Lzebulon : Y-a-t-il des durées minimales à garder certains de ces fichiers ?
|
|
On est pas FAI sur cette partie, donc pas d'obligations
|
|
Limiter à une semaine semble raisonnable.
|
|
|
|
## Mise à jour galène (RPZ Hachino en AGO pile à ce moment) (b;___;)b
|
|
|
|
-> on active les nouvelles options un peu sympa ?
|
|
|
|
Deux potentiellement peuvent être intéressantes : LDAP et background blur
|
|
Galène est packaged et maintenu sur Nix par Erdnaxe.
|
|
La transcription est powered par Whisper, qui marche plutôt bien même sur CPU,
|
|
truc construit par OpenAI Open source mais sans les données d'entraînement
|
|
|
|
Les deux points sont acceptés.
|
|
|
|
Jitsi est beaucoup utilisé ! (Ça fait plaisir !) 44 confs depuis le 29 juin,
|
|
soit 1,5/jour
|
|
|
|
## Le callback sur lists.crans.org et Anubis
|
|
|
|
"réglé" mais c'est moche
|
|
Fix horrible mis en place par Lzebulon, par reverse engineering de mailman :
|
|
pour passer en https, il fallait désactiver un switch demandant de passer en https
|
|
(à l'aide, pas pigé le reste) (lzebulon non plus)
|
|
|
|
Le fix ne pose heureusement pas beaucoup de problème, puisque toutes les requêtes
|
|
concernées sont internes au Crans.
|
|
|
|
## OIDC
|
|
|
|
keycloack ?
|
|
zitadel, authelia, authentik ?
|
|
j'ai oublie le nom mais Lyes a trouve un truc <- dex
|
|
dev interne d'une app ? modif du cas ?
|
|
OIDC est un CAS, mais avec des protocoles plus récents.
|
|
Lyes a trouvé Dex (<https://github.com/dexidp/dex>), qui semble plutôt propre
|
|
et qu'il testera.
|
|
Il semble plus léger que Keycloak, le serveur de Pigeon utilise authentik
|
|
qui prend plusieurs Go de RAM (écrit entièrement en python).
|
|
Son fonctionnement : on lui donne un Oauth2, il sort un LDAP.
|
|
Le Crans veut remplacer le CAS par l'OIDC, car le CAS actuel n'est plus supporté
|
|
par personne.
|
|
Oauth2 suit un standard, l'OIDC (un superset), qui est supporté par Matrix, Django
|
|
(la note), et tout un tas de logiciels récents.
|
|
Il ne supplante pas pour autant LDAP.
|
|
|
|
## Coupure ete pour mise à niveau + test fonction de redondance des routeurs
|
|
|
|
Proposition : fin juillet ou fin aout mais avant septembre
|
|
|
|
Lyes : fin juillet chui pas là et fin août y a tjr pas le RER B
|
|
Quand est-ce qu'on peut la faire ? Et qui s'en occupe ?
|
|
Avoir le RER B qui fonctionne serait pas mal, mais il ne recommence à fonctionner
|
|
qu'au 27 août, date à laquelle la plupart des nounous sont disponibles.
|
|
|
|
Ça attendra décembre ou toussaint
|
|
|
|
## Bon, euh, ceph ?
|
|
|
|
Déjà fait
|
|
|
|
## Ca serait bien de faire avant la rentrée (rentrée = 1er septembre)
|
|
|
|
Classé ici par importance.
|
|
|
|
## Crucial
|
|
|
|
Collabora/Onlyoffice (le choix est laisssé à la personne qui va implanter)
|
|
Mettre à jour les clubs qui ont leur sites
|
|
Enlever : Krobot
|
|
Ajouter : Nekorale
|
|
Enlever les informations pratiques concernant Cachan
|
|
Sur intranet.crans.org :
|
|
Enlever owncloud, place à NextCloud
|
|
Attente de Mediawiki pour changer les trucs concernant les wikis
|
|
Sur intranet.crans.org et services.crans.org
|
|
Matrix (une fois les moultes discussions avec le BDE) et PeerTube (de même)
|
|
Vaultwarden (une fois assez de remarques défensives présentes ?)
|
|
Dire que l'imprimante fonctionne
|
|
|
|
=## Moins prioritaire=
|
|
Nextcloud ajout intégration roundcube (intégration officielle,
|
|
permet de mettre roundcube dans une iframe sur le site NextCloud)
|
|
Plus quelques niceties comme le partage de document
|
|
Objectifs proposés par Rigo : synchronisation des contacts et des agendas
|
|
[Rigobert] Sinon, dans un souci de modularité, serveur DAV ?
|
|
|
|
## Frozen
|
|
|
|
Il reste l'une de nos imprimantes sur le campus de Cachan
|
|
|
|
boulot partage du CA/IN :
|
|
debut plan Seminaire
|
|
(je dis ca alors que je pourrai pas etre present en presentiel x)
|
|
enregistrer/diffuser en direct sur galene/jitsi/peer.tube ?
|
|
matrix
|
|
connection de synapse à jitsi pour permettre des appels videos/audio <- ouiiiiiiiiiiiiii
|
|
serveur notice : <https://element-hq.github.io/synapse/latest/server_notices.html>
|
|
mjolnir
|
|
notification report
|
|
Documentation utilisateurice
|
|
[Pigeon] -> À partir du moment où on se décide de quoi déployer,
|
|
je peux en faire des paquets sur tous les services du Crans
|
|
Il faudrait faire la liste des services prioritaires sur lesquels faire de la doc
|
|
matrix
|
|
nextcloud
|
|
mail
|
|
À faire sur le wiki ? Mediawiki ? Mediawiki sera-t-il là à temps ?
|
|
|
|
## sputnik git2.crans.org
|
|
|
|
gitea (MIT) -> forgejo (GPLv3+) ? ou au moins mise à jour
|
|
on est d'accord
|
|
|
|
## Tracker la version nixpkgs de la flake utilise pour chaque vm nixos
|
|
|
|
Par un dashboard grafana.
|
|
|
|
interet : savoir quel serveur mettre a jour
|
|
|
|
`nix flake metadata --json /etc/nixos/ | jq '.locks.nodes.nixpkgs.locked.lastModified'`
|
|
|
|
## imap recherche textuel longue : dovecot fts plugin
|
|
|
|
<https://doc.dovecot.org/2.4.1/core/plugins/fts.html#fts-full-text-search-plugin-fts>
|
|
|
|
## Début reflexion projet de l'année prochaine
|
|
|
|
[Rigobert] <https://gitlab.aliens-lyon.fr/AliENS/old-permit> <- c'est pas ça : <https://gitlab.aliens-lyon.fr/AliENS/permit>
|
|
[Hachino] J'ai contacté un AliENS-ien sur #federez à l'instant,
|
|
ils l'ont packagé dans NixOS en bonus.
|
|
C'est du Keycloak/oidc, ils sont
|
|
"sous l'eau mais chauds pour aider à faire des modifs"
|
|
et l'idée que le logiciel soit adopté chez nous suscite l'enthousiasme.
|
|
Lien d'un vieux planning, pour voir l'UI : <https://permit.aliens-lyon.fr/planning/shared?token=A7cWlGgprIP9GLWQjqRfvgr72UUWxltAr_0IWrm46ZY>
|
|
[Rigobert] Crab.fit <- +1 de Lyes (<https://crab.fit/>) y a <https://meet.dgnum.eu/>
|
|
[Rigobert] Mattermost <- Matrix ? / Taiga (<https://taiga.io/>) pour Kanban pour
|
|
les assos / Deck pour nextcloud / Planka (dont intégration nextcloud ?)
|
|
ceph ? <- oui
|
|
oidc <- oui
|
|
peertube
|
|
full CI/CD/Builder nixos
|
|
mise à jour debian/proxmox
|
|
isc-dhcp deprecie
|
|
dovecot change config (<https://www.debian.org/releases/trixie/release-notes/issues.en.html#dovecot-configuration-changes>)
|
|
openldap (je sais pas si ca change quelque chose j'ai pas plus check) (<https://www.debian.org/releases/trixie/release-notes/issues.en.html#openldap-tls-now-provided-by-openssl>)
|
|
potentiel probleme de changement de nom d'interface reseau avec la mise à jour proxmox
|
|
[censured] aka le projet mort vivant mais qui mets du temps à mourir
|
|
[Pigeon] Le fait qu'on en parle encore relève du miracle/nécromancie
|
|
|
|
## dhcpd en fin de vie : <https://www.isc.org/dhcp/>
|
|
|
|
-> maintenant c'est kea ? & stork (interface monitoring kea & bind) ?
|
|
demande de refaire/modifier le script pour donnée accès à internet
|
|
|
|
## Configuration peertube
|
|
|
|
Proposition d'infrastructure :
|
|
1 VM (peertube) qui contient que le serveur avec le client web
|
|
n VM (peertube-runnner-X) qui vont faire le transcodage pour ne pas surcharger peertube
|
|
On peut facilement en ajouter/retirer donc c'est pratique de faire comme ça
|
|
n = 2 me paraît être un début largement suffisant
|
|
Stockage ? Pool sur ceph (lol) ou sur cameron me paraît adapté
|
|
cameron, mais limite d'upload par user -> Oui évidemment
|
|
Backups
|
|
Backuper de la vidéo c'est environ équivalent à juste copier le fichier,
|
|
faire des backups différentielles ne fait gagner quasiment aucune place
|
|
(On en ferait quand même mais c'est pour prévoir l'espace disque nécessaire)
|
|
|
|
Stockage : 10G (au debut, avisera apres)
|
|
|
|
backup : que les fichiers originaux si possible
|
|
|
|
## Improve security <https://developer.mozilla.org/en-US/observatory>
|
|
|
|
## reverse proxy et nixos
|
|
|
|
18h19, fin de l'IN
|