169 lines
6.1 KiB
Markdown
169 lines
6.1 KiB
Markdown
# 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.
|