documentation/compte_rendus/2014_05_08.md

Internounous

• Date : Jeudi 8 mai 2014
• Lieu : Salle de conférence du Pavillon de Jardins
• Début : 19h13
• Fin : 21h14

Présents

• Adam Heriban
• Daniel Stan
• Pauline Pommeret
• Pierre-Elliott Bécue
• Vincent Le Gallic (arrivée à 19h33)

Ordre du jour

Nouveau RTC

En l'absence de Valentin Samir qui semble devoir faire face à d'autres obligations, Daniel Stan s'est porté volontaire pour assurer le rôle de RTC. Son initiative a été approuvée par le CT, et c'est désormais officiel. Félicitations Daniel !

La question de la récupération des clefs de Valentin (clef 0B et coffre en particulier) se pose. Daniel va essayer de le contacter par divers moyens afin d'en discuter avec lui.

CransClefs

Il faut vraiment que les MA mettent à jour VieCrans/CransClefs, elle n'est manifestement pas à jour, et cela devient problématique. Il faut rappeler au trésorier actuel que c'est de son ressort et qu'il doit veiller à ce que les détenteurs des clefs soient identifiés, quitte à ce que des cautions soient encaissées.

Il est demandé à Vincent Guiraud de vérifier la présence de clefs 2B dans le coffre. La réponse est non (il n'y a pas de clefs).

Il faudra penser, pour les années à venir, à dire aux personnes partant en stage de le dire sur la page VieCrans/CransVacances et à rendre leurs clefs avant de partir.

Une clef du disjoncteur du 0M nous a été confiée par le CROUS et est actuellement au 2B, faute d'avoir pu fournir une clef 0B à Jordan Delorme. Cela commence sérieusement à être problématique. Il faut demander au CA de voter un budget pour réaliser la copie de 2 jeux de clefs 0B.

Blocage du /64 wifi sur Wikipedia

On a découvert le 4 mai qu'un ou des adhérents auraient poussé des admins de Wikipédia à bloquer le /64 wifi de manière à ce que les adhérents du Crans ne puissent ni créer de compte ni éditer de page.

L'administrateur de wikipedia ne souhaite pas lever le blocage tant qu'il n'est pas en mesure de différencier 2 utilisateurs venant de chez nous, et par là même de bloquer uniquement celui qu'il considère comme vandale. En effet, le fonctionnement de l'IPv6 au crans laisse le choix à la machine d'un suffixe aléatoire (extension de vie privée) dans le même /64. Nous sommes donc les seuls à connaître la correspondance entre une IPv6 et une machine du réseau (pour comptage d'upload), et ceci de manière volontaire (il s'agit d'un des buts du système d'extension de vie privée).

Que faire ? D'un côté, on peut se soucier des conséquences pour les autres adhérents :

• Ne rien faire
• Bloquer la plage IPv6 de Wikipedia pour forcer l'IPv4 (comme pour google), la plage IPv4 n'est pas bloquée et ne risque pas de l'être (chaque adhérent étant clairement identifiable)
• Implémenter un routage plus fin de l'IPv6

La deuxième solution pose des problèmes d'altération du réseau. En l'état actuel, nous n'avons pas de raison valable pour suivre la démarche de Wikipedia dans la violation de la neutralité du réseau. De plus, le blocage actuel est peu sévère et les rares adhérents impactés ont des alternatives pour l'accès à Wikipedia, comme la désactivation de l'IPv6 (envoyer un mail ? message sur autostatus ?)

La dernière solution (se référer à CransTechnique/PlanAdressage#IPv6) est de toute façon un projet de longue date sur lequel il faut se pencher. L'idée est d'allouer à chaque machine un /64 distinct. Il faut regarder de la doc du côté de DHCPv6 et de délégation et implémenter cela en parallèle de la solution actuelle.

Du côté de l'adhérent accusé pour wikipedia, nous n'avons pas constaté d'abus ni de nuisance sur le réseau que nous pouvons lui imputer.

On décide de ne rien faire pour le moment et d'analyser la solution d'adressage v6. On avisera en temps utile. Le CA tient à en discuter lors de sa prochaine réunion pour l'aspect administratif de ce problème. Une tentative de contact a été prise par le CA, et s'est pour l'instant avérée infructueuse.

Comptage upload et avertissements

Le CA souhaiterait que les mails d'avertissement pour upload à 300Mo soient moins agressifs et plus pédagogues. De plus 300Mo semble une limite très facilement atteignable de nos jours avec les technologies actuellement présentes sur Internet.

Pierre-Elliott souhaite conserver cette limite basse afin de laisser aux adhérents le temps de réagir lors de la réception d'une alerte. Une limite plus haute, en cas d'upload rapide, ne permettrait pas d'avertir l'adhérent d'un comportement anormal de sa machine avant qu'il ne soit effectivement déconnecté.

Cependant, plusieurs adhérents ont exprimé leur volonté de ne plus recevoir ce mail d'alerte.

Raphaël Bonaque (irc) est volontaire pour rajouter un champs sur l'intranet (lié à ldap ? pg ?) pour choisir à partir de quel seuil un adhérent souhaite recevoir son mail d'avertissement pour upload. Cela demande peu de modifications dans notre système de comptage d'upload et permettrait aux adhérents ne plus recevoir ce mail ou de configurer à quel moment ils souhaitent le recevoir.

Impression

Le devis d'Open concernant leur imprimante Xerox nous a permis de soulever un problème important : l'imprimante a sa sortie sur la droite, tandis que la notre sort à gauche. Ça demanderait donc un réaménagement du 4J, à voir avec des mesures et éventuellement donner une date à Open pour qu'ils passent voir le local.

Pas de trace de compatibilité Linux sur la Ricoh proposée par AMP.

DSI-Crans

Pierre-Elliott a créé une ML d'alerte utilisable par la DSI afin d'éviter de spammer tous ses membres à la moindre alerte nous concernant sur dsi-crans. root@ est abonné directement.

Préparation d'une future réunion ? Potentiellement à l'OdJ

• Autorisation d'un deuxième routeur crans dans la zone zrt (nouveau komaz)
• Demande d'un petit /24 pour des tests nat64 ?
• Tout ce que vous estimerez pertinent (demander au CA, notamment pour Saclay)

Projets en cours

Pierre-Elliott a fait un peu de ménage dans le tracker, il y a des projets pour les apprentis, avis aux personnes motivées !

Pauline souhaite que les tâches réalisables par un apprenti (en autonomie) soient davantage mises en valeurs.

Il faut faire quelque chose de toutes ces tâches (renouvellement des certificats, KSK, etc) qui produisent beaucoup de bruit. Pour les certificats, on a ce qu'il faut automatiquement avec check_cert, Pierre-Elliott va essayer de faire un programme du même genre pour DNSSEC.

Questions diverses

Binding Ldap

Pierre-Elliott s'est lancé dans la réécriture de certains scripts de gestion s'appuyant sur ldap_crans pour les porter sur lc_ldap. Il a également commencé une implémentation de generate basée sur rabbitmq. Pour l'instant, il s'est penché sur dhcp, ça marche, il faut continuer. Il attend des reviews.