#acl +All:read = Réunion du Collège Technique = <> * Date : ---(Samedi 32 novembre 2023)--- Samedi 2 décembre 2023 * Lieu : MB87 et Galène (https://galene.crans.org/group/IN/) * Début : 20h22 * Fin : 22h54 * https://pad.crans.org/p/Samedi02Decembre2023 == Présent⋅es == * [[WikiAplanos|Aplanos]] * Korenst1 * !GaBo * [[WikiHachino|Hachino]] * [[VanilleNiven|Vanille]] * !RedDiamond * [[WikiPigeonMoelleux|Pigeon Moelleux]] * [[WikiBleizi|bleizi]] (arrivée à 21h15) * Petit Gaga (???) (En post-Quill) == Ordre du jour == * Réplication de la BDD gitlab (car elle est créée par gitlab, voir avec shirenn) * [bleizi] rendre inactifs les compte que l'on arrive pas à contacter par mail * [bleizi] signer dkim les mails de re2o * [shirenn, bleizi et ds-ac] redirection des mails depuis zamok vers redisdead * [bleizi] crans OID https://www.iana.org/assignments/enterprise-numbers/?q=crans * [bleizi et shirenn] SPF pour les mails sur redisdead : retour sur la mise en place + est-ce qu'on est plus restrictif (drop des fails) ? * [Pigeon] Dovecot sieve pour le tri des mails dans les sous-dossiers pour tous les adhérent⋅e⋅s utilisant leur adresse mail crans * [bleizi] https://hosts.crans.org/ c'est quoi ? * [ds-ac] faire un mini tuto install Debian avec gpt-auto-generator + systemd-growfs-root pour les VMs adh * [ds-ac] mailman et spam from self : whitelists trop permissives ? * [Hachino] [Un peu HS] Le hotspot eduroam de l'ENS marche pas quand t'as une adresse/un compte hors ENS. :( (Testé avec Hachino et 20-100.) Quelle est la bonne façon de contacter la DSI pour leur en parler ? * [Hachino] Randomly, 20-100 vient de découvrir que la fonction "Ajouter un commentaire" de Framadate est cassée. Qué pasta ? Trucs à pas oublier : * Contacter la DSI pour du RADIUS * RALLUMER LES BACKUPS SUR NETNS, ZAMOK-MYSQL ET LINX == Dovecot sieve / Procmail == Possibilité de définir un sieve par utilisateur ? "Est-ce qu'on utilise Dovecot au Crans ?" --> Après recherches, oui, mais "il est planqué où ?" [Ça se voit que l'IN manque de gens là ?] Pigeon a trouvé, victoire ! "/etc/dovecot/conf.d/90-sieve.conf" Conclusion : * Vanille est choqué par le MOTD de Owl. À raison. * Les gens apprennent à proxy jump * on testera ça la prochaine fois qu'on casse les mails * !GaBo demande où sont les adultes. Réponse : nulle part. * ds-ac devait faire une VM sur l'infra de test et les membres actifs devaient faire des tests. Bon bah plus tard alors. * bleizi pose la question de l'expressivité de Dovecot. Pigeon affirme que Procmail est strictement moins puissant que Dovecot et donne l'exemple des messages d'absence/réponses automatiques/regex (Aplanos est très bruyemment contre les regex). ''On remarquera que le compte rendu n'est pas linéaire car certains points ont été abordés plusieurs fois'' == Point DSI == Les comptes non ENS ne fonctionnent pas sur eduroam. Hachino s'en charge. Un jour, insh'. 2ème étage, couloir 2[A-Z]82 d'après !GaBo et Pigeon. L'espoir est très très mince. :( == Point Regex == À l'aide == Point SCP (à l'intérieur du point Quill) == Après avoir bifurqué sur Quill, Pigeon en arrive à une murder SCP qu'il écrit avec Charsle. Korenst1 est perdu par ce qu'est SCP. S'ensuit une explication succincte de Pigeon. == Framadate == Pigeon vient de le vérifier : le bouton "Ajouter un commentaire" est un mensonge. Personne ne sait où sont les logs de framadate, on remet le point à la prochaine IN. == Les autres points == Il manque les gens qui les ont ajoutés à l'ODJ. Derp. Ce sera pour l'IN de décembre. Bon allez, on essaye quand même. == Point Pass == Pigeon explique le principe de GPG et de Pass. ''Puis bleizi arrive, c'est un miracle !'' == Points messages de Pigeon == * Aurore est très fortement sous l'eau, "plus que la DSI". 90% du taf est fait par Jeltz, 5% par Lucas "Tavary-Maujean" et 5% par Vincent Lafeychine. * Anim[ENS] se plaint de la qualité de service de Galène (vs Ghostream) et demande la résurrection de Ghostream. Pigeon sait faire et s'en occupera lui-même, vu sa proximité avec Anim[ENS] (au hasard). == Réplication BDD gitlab == On backup certains trucs de gitlab mais pas sa BDD. Elle n'est backup que pendant les MAJ gitlab (~1 fois/mois), il faudrait le faire automatiquement. Gitlab est un énorme pâté qui installe tout seul les paquets dont il a besoin (et possiblement sa BDD). On attend shirenn pour voir ça. == Comptes non contactables == On refuse de regarder le .forward des gens. Possibilité : envoyer un mail aux gens "hey, ton compte semble inactif, si tu réponds pas d'ici X mois [X entre 1 et 6], on va l'archiver". Rien d'urgent ceci dit. == Signature DKIM == Signature faite par le serveur mail (redisdead au crans). Les mails envoyés par Re2o ne sont pas signés par DKIM, donc en principe "suspects" (mais mieux vaut pas signés que mal signés). Peut-être qu'un jour les Gafam (Gmail en tête) vont mettre en place des politiques plus strictes et les mails pas signés DKIM partiront par défaut en spam. Gênant. Pour l'instant c'est pas le cas. Sont concernés notamment les mailall annuels et les mails de confirmation d'inscription. Les mails ne sont pas signés DKIM quand ça passe par Redisdead et faudrait enquêter pour savoir pourquoi. Gitlab envoie des mails signés DKIM, Owncloud non (mais franchement, pour OC on s'en tape). Personne de présent n'est volontaire pour regarder ça en profondeur. bleizi propose la bouteille à la mer sur #roots (aled). Retour de la bouteille à la mer post réunion : * ''Au lieu que re2o envoie les mails lui même tu fais un nullmailer qui lui dit que c'est un autre serveur qui envoie les mails ?'' (Otthorn) * ''la solution simple (et sale) c'est de faire du submission avec le compte de root'' (shirenn) * ''l'autre c'est de dire à opendkim que quand les mails viennent de l'ip du serveur de re2o il faut les signer'' (shirenn aussi) * ''Bah re2o pourrait pas juste avoir son propre compte mail et envoyer des mails comme tout le monde ?'' (Mikachu) == Mails Zamok -> Redisdead == Quand un mail arrive pour le Crans, il passe par Redisdead, normal. Puis ça passe par Zamok, qui stocke les mails des gens. Dans certains cas, les gens ont des .forward vers une adresse extérieure (serveur perso, Gmail, ça dépend). Ça fait beaucoup d'allers-retours. bleizi a oublié la conclusion de la réflexion, mais ça a l'air sous-optimal. C'est bien noté. Un des soucis : les headers s'empilent à chaque redirection. L'idée serait de faire en sorte que Redisdead, plutôt que Zamok, lise le .forward des gens. == Crans OID == Le nom n'est pas le bon sur le lien (Stéphane Glondu, wouhou). Tout le monde s'en tape, GG. En fait non, bleizi réfléchie à changer les infos, mais il faudrait voir qui reçoit les mail sur oid-admin@crans.org == Point 'hosts' == La génération du DNS est faite en regardant le LDAP et tous les trucs du LDAP sont dans ou=hosts. == Point SPF == SPF = Standard policy framework. Sert à faire de la sécurité sur les mails. Principe : vérifier que le Mail From et le serveur qui envoie le mail sont les mêmes. Il paraît que les usurpations c'est pas bien. On peut donner au DNS (par le LDAP) la liste des serveurs qui ont le droit d'envoyer des mails au nom du Crans. À la fin tu peux mettre un "All" pour dire que tout le monde a le droit, un "-All" pour nier le droit et un "~All" pour dire "c'est pas normal, mais on laisse passer quand même". Pigeon trouve un "~All" dans un champ txt. Les seuls serveurs enregistrés pour le Crans sont Redisdead et Soputnik, mais pas Zamok. Dans le txt, il y a deux IPv4 et deux IPv6 (on suppose que c'est Redisdead et Sputnik). Les MX sont bien eux. Si on lit les headers d'un mail récent du Crans, genre celui que Pigeon envoie exprès à bleizi dans la minute, on peut s'apercevoir qu'il s'agit d'un mail de Q. De qanon@crans.org, pardon. Quand c'est signé DKIM, on lit pas les SPF parce qu'on fait confiance. bleizi poste un exemple d'analyse SPF venant de chez shirenn. {{{ Authentication-Results: redisdead; spf=softfail (domain owner discourages use of this host) smtp.mailfrom=gmail.com (client-ip=REDACTED; helo=abys.se; envelope-from=shirenn@gmail.com; receiver=) }}} Proposition de nouvelle politique : si fail (hardfail, pas softfail), alors drop le mail. Est-ce qu'on veut implémenter ça ? Débat. L'idéal serait de laisser passer le mail en informant les destinataires, mais * personne de normalement constitué (même pas au Crans) ne lit les headers de ses mails; * scripter une modif du mail (type ajouter '[*** SPAM ***]' au début de l'objet) c'est techniquement chiant à faire, donc flemme. Par défaut, on laissera passer les mails quand même. Plus tard, quand SPF sera plus répandu et/ou que les Gafam imposeront leur loi, peut-être qu'on changera d'avis. Pigeon et Aplanos proposent de ressusciter la Stasi en censurant a priori tous les mails. La motion est rejetée à l'unanimité. == Hosts.crans.org == Ça héberge un Django en debug. Personne ne sait ce qu'il devrait y avoir à la place. Un ssh fait tomber sur Hodaur, mais c'est normal. On demandera à de vieilles nounous si elles savent. Il est probable que ce site ne serve à rien. ---- * CatégoriePagePublique