6.2 KiB
= Réunion Nounous =
- Date : Jeudi 26 avril 2012
- Lieu : 2B
- Début : 19h25
- Fin : 21h
== Présents ==
- Aurore Moisy-Mabille
- Daniel Stan
- Nicolas Dandrimont
- Olivier Iffrig
- Raphaël Cauderlier
- Yann Duplouy
== Ordre du jour == === Wiki === La mise à jour de niomniom a été effectuée. Les personnes ayant effectué la mise à jour n'étant pas présentes, difficile d'en dire plus. Un backup du wiki a été fait dans /usr/scripts (il pèse 800 Mo), il faut l'enlever.
=== Virtualisation === fy a été réinstallé, histoire que ce soit propre, et à peu près la même chose que sur fz. La migration à chaud ne marche pas très bien. fy est prêt à accueillir des domU. On va s'en servir pour mettre à jour fz en limitant le downtime.
=== Baie de disques === Il faudrait voir s'il est possible d'avoir quelques disques en plus, pour pouvoir faire des tests dans un premier temps, et ensuite servir de disques supplémentaires déjà branchés.
La nouvelle baie étant de la même famille que l'ancienne, le transvasage des disques de l'une à l'autre devrait être plug-and-play.
On va faire un workshop le 19 ou le 20 mai pour tester la nouvelle baie.
=== Nagios === Pierre-Elliott a passé pas mal de temps (avec Nicolas) pour configurer Nagios de manière raisonnable. La config est en cours, serveur par serveur. 4 ou 5 serveurs sont configurés.
Démo sur nagios.crans.org (login/mdp crans).
Nagios peut tester les services de « l'extérieur » en testant leur fonctionnement. Un module nagios-nrpe permet de tester les services depuis l'hôte. Ce dernier permet de faire des checkdisk, etc. (peu utile car munin le fait déjà).
L'implémentation des plugins munin est a priori faite, mais les résultats sont mitigés. (les plugins sont monitorés passivement, donc si pas de warning, ils sont notés comme "en attente", et les rares qui ont été monitorés sont en "unknown". Le passage des plugins munin a été uniquement mis en place pour vert.
Il faut trouver une solution alternative à la configuration actuelle pour récupérer les données de munin dans nagios. Un plugin nagios existe apparemment pour lire les fichiers rrd de munin. À creuser ?
vo:/localhome/becue/nagios contient quelques scripts et éléments au fur et à mesure de la config. La doc sera faite d'ici peu.
Il faut intégrer monit à nagios (c'est à dire, faire en sorte que les warnings de monit soient gérés par nagios, au niveau mail et interface web). Un plugin nagios existe déjà pour se connecter à un serveur monit distant, il faut donc voir à adapter la config de monit, ou à lancer le plugin en question via NRPE.
Il faudra aussi réfléchir à la "mise en production" des alertes mail de nagios sur roots@crans.org.
=== Wifi ===
Pas de réponse d'interprojekt pour le retour des bornes (qui ne sont pas les bonnes).
Certains adhérents ont constaté un problème de compatibilité entre leur carte réseau et le wifi n. Une désactivation du wifi 802.11n sur la carte niveau client a été faite pour régler le problème.
Il y a plusieurs possibilités sur la nature du problème. Cela peut-être dû à la largeur du canal utilisé pour le WiFi n (les canaux à 40MHz ne sont pas supportés par la carte, contrairement à ceux à 20MHz). Cela peut aussi être dû à un driver moisi (il permet de désactiver le 802.11n, donc il n'est pas si moisi que ça). On n'a pas constaté de problèmes lors des journées FedeRez, donc ça peut aussi être lié au WPA2-entreprise.
Pour résoudre ce problème particulier, plusieurs pistes :
- Désactivation du 802.11n côté client
- Avantage : débit maximal pour les clients qui le supportent
- Inconvénients : tests au câblage plus lourds, toutes les cartes ne le supportent peut-être pas...
- Dédoubler les SSID (Un ssid Cr@ns, un ssid Cr@ns-n)
- Avantage : débit max pour les clients qui le supportent, les vieux clients ont toujours du wifi g
- Inconvénients : confusion ?
- Réduire la largeur du canal
- Avantage : toujours du n
- Inconvénients : est-ce que ça règle vraiment le problème ?
- Désactiver le wifi 802.11n
- Avantage : On est sûrs que ça marchera partout
- Inconvénients : pas un meilleur débit (enfin toujours un meilleur débit que les wrt54g...)
Daniel a commencé à regarder pour le dédoublement des SSID, le reste est une modification triviale en termes de config d'OpenWRT et peut être testé en présence d'un-e cobaye.
Diomède sera réinstallée à la Kfêt, avec la config HT20 pour tester.
=== Ardoise virtuelle 0B ===
L'idée de base est que l'interface d'accès aux locaux ne fonctionnera jamais (les gens ne s'y inscriront jamais), Daniel propose de faire une interface physique sur laquelle les gens s'inscrivent pour prendre une clé, et qui consigne les accès directement dans la base.
On pourrait aussi envisager l'idée d'installer une armoire à clefs électronique un peu comme celle de l'ENS, qui ne permet de retirer que la clé pour laquelle on s'est inscrit. Celà forcerait les gens à s'inscrire.
Daniel s'occupe de faire ça et l'interface d'accès aux locaux, éventuellement avec un apprenti (Julien ?).
=== Babar ===
Il commence à en avoir plein la trompe. Olivier s'occupe de demander un devis à Anne pour plus de disques, selon le nombre de slots disponibles.
=== Ragnarok ===
Le nouveau serveur syslog est fonctionnel.
Reste à mettre la config de rsyslog sur tous les serveurs pour qu'ils y envoient leurs logs. Il faut faire attention à ne pas faire la modification à l'aveugle, par exemple sur les serveurs qui dépendent de leurs logs (komaz, par exemple).
Il faut aussi changer la config des switchs pour qu'ils envoient leurs logs à ragnarok et non à vo. Daniel s'en occupe.
Il faut configurer un frontend un peu plus sexy que psql. Yann s'occupe de recenser ce qui existe.
=== Questions diverses === ==== Inscription aux mailing-lists des vieilles nounous inactives ====
Plein de vieilles nounous + plein de spams = plein d'espace disque utilisé pour rien.
Plusieurs possibilités : virer les droits des gens; créer un droit "Vieux" qui reçoit juste certaines ML; ne rien faire et remplir /home.
Olivier envoie un mail à ces vieux pour leur demander ce qu'ils veulent toujours voir et pourquoi.