108 lines
5.0 KiB
Markdown
108 lines
5.0 KiB
Markdown
# 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 ?
|
|
1. 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.
|