168 lines
6.8 KiB
Markdown
168 lines
6.8 KiB
Markdown
# 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.
|