documentation/compte_rendus/2011_10_31.md

6.5 KiB

Réunion Nounous

  • Date : Jeudi 13 Octobre 2011
  • Lieu : Salle Condorcet
  • Début : 19h14
  • Fin : 21h34

Présents

  • Aurore Quelennec
  • Benjamin Aupetit
  • Daniel Stan
  • Judith Robson
  • Michel Blockelet
  • Nicolas Dandrimont
  • Olivier Iffrig
  • Raphaël Cauderlier
  • Steven Masfaraud
  • Sylvain Boilard
  • Valentin Samir
  • Vanessa Verbeke
  • Xavier Lagorce

Ordre du jour

Wifi

Nouvelles bornes

Les nouvelles bornes sont arrivées mais (petite) déception: le chipset wifi n'est pas le même... Iota a réussi à compiler une image pour ces bornes et à booter dessus, il n'y a pas de raison que le WiFi ne fonctionne pas. D'ailleurs, il y a de l'entropie. Il y en a 3 autres à tester, avis aux volontaires.

Les tests de portée sont à effectuer. Il faut voir si ça passe en ligne droite (dans un couloir ?) puis entre les étages (car on a que deux locaux techniques au G...)

Audit de la couverture actuelle

Il faut parcourir le campus afin de récupérer l'état de la couverture wifi. On peut aussi essayer de faire des stats pour voir où les gens se connectent.

Daniel s'occupe de l'extérieur. Raphaël s'occupe de cartographier où les gens se connectent. Steven s'occupe de l'intérieur.

Bornes sur le toit du bâtiment J

Les bornes sur le toit du bâtiment J et arrosant le bâtiment G n'arrosent pas le bâtiment G... En effet, le revêtement des fenêtres empêche la propagation des ondes wifi. Des clients sont toutefois connectés sur ces bornes, il faudrait donc les laisser.

On ne peut pas les laisser en l'état (car elles sont "mal" accrochées), on a le choix entre les fixer correctement, installer d'autres bornes (nanostation ?) qui devront elles aussi être fixées correctement, ou ne rien mettre.

On va attendre le résultat des tests de couverture.

Détection des réseaux pirates

Il y a deux semaines et demi, un réseau WEP de SSID "Cr@ns" a été détecté sur le campus, émis par plusieurs MACs différentes. Le réseau était annoncé moins d'une minute à chaque fois.

Raphaël essaie d'utiliser les bornes WiFi afin de détecter l'origine du réseau bizarre.

Workshop Scripts

Il n'a manifestement pas eu lieu. (On a trié des fiches d'adhésion/réadhésion.) On fait une première session jeudi 20 octobre pour vérifier le fonctionnement du nouveau binding LDAP et corriger les bugs manifestes.

Proxy

  • Caching des vidéos youtube : ce n'est pas possible facilement, il faudrait avoir un serveur Web "cache" à côté. De toute façon, le débit consommé n'est pas forcément si important que ça par rapport au reste du trafic.
  • (null)://toto : parfois, quand on charge une page, il arrive que le proxy retourne une erreur parce qu'elle essaie d'utiliser le protocole "(null)". C'est une erreur a priori liée au proxy transparent. Il faut que quelqu'un prenne ses petits doigts musclés et écrive un bug report.
  • Pages pour les gens déconnectés pour virus : Michel propose que la page de déconnexion apporte plus d'informations notamment quant au virus. Pour ce faire, on pourrait faire une section dans l'intranet où on pourrait mettre les logs de déconnexion et les instructions à suivre pour désinfecter.

Connexion des appartements de fonction

Le Cournot remarche, Iris ne marche plus. Il faut contacter la personne qui rencontre des problèmes afin de savoir ce qu'il en est. Il faudrait aussi en profiter pour leur dire de nous contacter directement et de nous tenir au courant quand ça refonctionne tout seul. On peut profiter de la campagne de réadhésion pour faire ça.

Impression

Daniel a modifié l'interface d'impression, entre autres pour la rendre plus stricte. Elle n'accepte plus les dimensions exotiques, ce afin d'éviter les affiches occupant 1/100e de la page.

On va utiliser le biniou d'adg qui se connecte à l'interface d'impression directe.

Problèmes avec l'imprimante

Il faut contacter print platinium pour

  • échanger les rouleaux
  • échanger l'imprimante
  • échanger de partenaire kof kof

DHCPv6

Personne ne s'est occupé de tester le DHCPv6. Il est décidé de le configurer en utilisant les adresses IP d'autoconfiguration, pour des questions de simplicité du firewall.

Questions diverses

Communication

Il faudrait faire, à chaque inter-nounou, ''vraiment'' faire un bilan de ce qui a été fait. Ça permettrait d'avoir une trace écrite.

Nicolas propose que chacun tienne un journal de bord, afin d'écrire au jour le jour ce que chacun a fait au Cr@ns. Ensuite, on fait une synthèse lors des internounous.

Mises à jour vers squeeze

Il faut continuer. Le support de sécurité de lenny s'arrête en février 2012.

Michel se propose d'encadrer les bonnes âmes voulant s'en charger. Aurore se porte volontaire.

Install-party

L'install-party campus aura lieu le 19 novembre. La vraie aura lieu le 14 janvier.

Il faut que quelqu'un pense à mettre à jour le netboot avant l'install-party (et non pendant...).

On peut graver des CD d'Ubuntu.

Réunion avec la DSI

Il faut prévoir rapidement une réunion avec la DSI, pour parler de :

  • Gigabit
  • Connexion des appartements
  • Rationnalisation de la connexion Cr@ns-ENS
  • WiFi

Le RTC est volontaire.

Inondation, comment redémarrer les serveurs

Premier problème : les nounous ne savent pas dans quel ordre redémarrer les serveurs. Deuxième problème : même avec une nounou qui sait dans quel ordre redémarrer les serveurs, un redémarrage prend une bonne heure, alors qu'il pourrait être beaucoup plus rapide.

Un ordre de redémarrage des serveurs doit être écrit, rapidement.

Une solution plus pérenne serait de décrire les dépendances entre services dans un init script lancé très tôt et qui attendrait de pouvoir se connecter aux services en question avant de continuer le boot. Un script de la même espèce que "attendre-vert", mais 2.0.

Une autre solution serait de faire un "maître d'orchestre" qui autorise les serveurs à booter séquentiellement.

Judith se porte volontaire.

Comment éviter les problèmes à base de 0.0.0.0

Un adhérent a décidé de mettre une adresse ip 0.0.0.0, ce qui a beaucoup perturbé la détection de conflits d'adresse ip de windows.

Michel voudrait qu'une adresse ip bidon soit mise en place, qui n'est pas vraiment utilisée, et qui soit utilisée pour détecter des comportements bizarres :

  • Si une machine répond aux requêtes ARP pour cette machine, elle se comporte bizarrement
  • Si une machine essaie de se connecter à l'ip bidon, la machine se comporte bizarrement