174 lines
6.5 KiB
Markdown
174 lines
6.5 KiB
Markdown
= 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
|
|
|