30 KiB
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