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