documentation/compte_rendus/2022_04_16.md

Réunion Inter Nounous

• Date : Samedi 16 Avril 2022
• Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
• Début : 20h03
• Fin : 21h43

Présents

• Vanille
• bleizi
• esum
• Pigeon Moelleux
• Ÿnérant
• shirenn
• ds-ac
• Otthorn

Ordre du Jour

• Suppression du domaine crans.ens-cachan.fr
• Mise en place des serveurs radius à Saclay
• Retour sur le déploiement d'OpenDMARC
• Point sur l'avancée du projet de backups
• Petite avalanche d'acronyme pour discuter des problèmes liés à ZFS

crans.ens-cachan.fr

Avec le décomissionnement progressif du nom de domaine ens-cachan.fr, la DSI a supprimé la zone crans.ens-cachan.fr qui nous était délégué. Celle-ci était de notre côté configuré pour se comporter comme un DNAME de crans.org et nous en avions de manière générale peut fait la promotion au cours des années. Sa suppression est donc sans grande incidence. Elle ne devrait créer qu'un petit nombre de liens morts rapidement réparable en substituant à crans.ens-cachan.fr la zone vers lequel le DNAME pointait (ici crans.org). On peut cependant noter que certains anciens, conscient de l'existence de ce DNAME avait décidé de l'utiliser dans leurs adresses mails. Il n'y a malheureusement pas grand chose que l'on puisse faire à ce propos.

Radius à Saclay

Radius Federez

Depuis le départ de Cachan, le crans n'exporte plus de serveur radius. Celui-ci permettait aux gens bénéficiant d'une connexion internet sur le campus de Cachan de pouvoir se connecter à internet sur les campus du réseau Federez. De plus le crans ne vendant plus à proprement parler de connexions internet à ces adhérents la question s'est posée de savoir,

1. S'il était encore pertinent d'avoir un serveur Radius ?
2. Si oui, qui devrions nous exporter dans celui-là ?

Un point important sur ces deux questions est le suivant, les gens qui par notre politique d'exportation se retrouveront dans le serveur radius, auront de fait accès à internet dans les résidences du campus (en particulier les résidences gérées par Aurore et ViaRézo). Dans le but de ne pas leur poser des problèmes économiques, il a été rappellé l'importance de ne pas proposer au crans une solution qui donnerait accès à leur connexion de manière plus avantageuse que ce qu'il propose. Ce constat nous a amené a réduire la liste potentielle des gens que nous exporteriont à une seule partie des gens bénéficiant des services d'hébèrgement de machines virtuelles. Ce nombre étant assez réduit, il a été décidé qu'il ne justifiait pas le deploiement d'un serveur Radius.

Radius associatif

Le running gag continue, il faut contacter l'administration.

OpenDMARC

Pour s'assurer de l'authenticité des mails entrant sur une partie de nos serveurs mails (pour le moment seulement redisdead et mailman), le logiciel OpenDMARC a été déployé. C'est une implémentation du protocole DMARC, protocole qui consiste à vérifier que soit le SPF, soit la signature DKIM du mail est valide. De plus, il permet aussi l'envoie de rapports DMARC au MX qui le demande. Cependant, pour envoyer ces rapports, le logiciel utilise une base de donnée mariadb et n'est pas compatible avec postgresql. De plus, la manière dont cette base de donnée est rempli a été décrite comme « assez chaotique », bref, il a été décidé de garder la validation OpenDMARC mais d'attendre qu'une solution plus propre existe pour l'envoi de rapport.

Backups

Le travail est presque finalisé pour le serveur de backups, on pourra d'ici peut l'envoyer chez via pour faire des premiers tests.

ZIL, ZLOG, ZFS

Derrière cette avalanche d'acronyme absconts se cache le problème qui a affecté cameron il y a peu. Le volume d'écriture demandé au serveur était devenu trop important quand comparé, non à la vitesse, mais au délai d'écriture de celui-ci. Les serveurs tentant d'acceder en écriture au nfs devait alors attendre longtemps avant de recevoir un acquittement générant ainsi de l'iowait sur ceux-ci, faisant monter en flèche leur charge et rendant inutilisable les services qu'ils hébergeaient. Une solution de fortune a été implémenté sur le serveur consistant à forcer l'envoi d'un acquittement dès la demande d'écriture sans attendre que celle-ci ait effectivement été faite. Bien que cela ait résolu le problème à cours terme, cette solution pourrait occasionner des pertes de données. Il faut donc trouver une solution plus pérenne que le simple mensonge sur les acquittements actuellement en place. Pour cela, il est possible de fournir à zfs un disque séparé (de préférence un ssd car on cherche ici au maximum à diminuer le temps d'écriture pris par le serveur) qui servira de cache d'écriture, l'acquitement n'étant envoyé du coup ni dès l'arrivée de la demande d'écriture, ni quand celui ci serait effectivement écrit sur le disque mais dans un état intermédiaire, à la fois plus sûre que la première solution et plus rapide que la deuxième. Le CT a voté pour l'achat de disques pour essayé de mettre en place cette solution.