documentation/compte_rendus/2015_02_05.md

127 lines
4.5 KiB
Markdown

# Réunion du Collège Technique
* Date : Jeudi 5 février 2015
* Lieu : Pavillon des Jardins
* Début : 19h07
* Fin : 20h00
* Lien vers l'[etherpad
associé](http://pad.crans.org/p/Jeudi5F%C3%A9vrier2015IN)
## Présents
* Raphaël-David Lasseri
* Gabriel Detraz
* Myriam Bégel
* Emmanuel Arrighi
* Daniel Stan
* Pierre-Elliott Bécue
## Ordre du jour
### Nouveaux switchs 2620
Les 3 procurves 2620 ont été installés durant la coupure au PDJ et bâtiment J,
en remplacement de batp-0, 2 et batj-0.
Il faudra mettre à jour la base ldap. L'échange des 3 anciens défectueux a
commencé : ils sont arrivés aujourd'hui.
Il reste cependant quelques questions :
* Que dit HP du problème avec le dhcp snooping ?
* Pas encore de réponse, pour le moment on reconfigure sans (et on le remet
à la main une fois le switch booté)
* Gestion des switchs restants
Au terme des échanges, si on reçoit effectivement des 2620, les switchs
disponibles et fonctionnels seront donc :
* trois 2620 48 ports ou assimilés envoyés par hp.
* deux 2620 24 ports
* deux 2626 24 ports
Décision ayant été prise d'envoyer 2 ou 3 switchs à Grifon, on envisage de leur
envoyer un 2626-24 et un 2650-48 ports.
On pourrait mettre un 2626 au Krobot, le dlink s'y trouvant se comportant de
manière erratique, on peut aussi leur
prêter (sous caution) un des petits TP-Link sur lesquels on bosse en ce moment.
Ce serait l'occasion de finaliser
ce projet.
Reste la med : on pourrait y mettre soit un 2620-24 (batb-5), soit un petit
switch manageable ou pas, pas trop cher.
Vu qu'un 2620 est déjà installé (batb-5) et qu'il nous en reste plusieurs, on
peut le laisser.
Manageable :
* <http://www.senetic.fr/product/J9802A?gclid=Cj0KEQiAuremBRCbtr-1qJnKi-4BEiQAh0x08K8BAtSiJQIde3KAP66T4B71418jBs8db9VquPZVWHsaApEW8P8HAQ>
* <http://www.ldlc.com/fiche/PB00157997.html>
Non manageable :
* <http://www.amazon.fr/D-Link-DGS-108-boîtier-Gigabit-Ethernet/dp/B0074CDCN4/ref=sr_1_6?ie=UTF8&qid=1422798674&sr=8-6&keywords=switch>
Il y aurait alors deux 2620-48, un 2620-24 et un 2626 pour les install partys
et autres évènements.
### Bornes au DeVinci
Gabriel, Alexis et Florian ont fait le tour des bornes avec Cédric Cheveaux
dans le DGM. Deux Wrt54g, les 2 dernières du parc encore actives, ont été
changées.
Demodocos et Ulysse étaient plantées, elles ont été rebootées. Ce ne sont pas
des bullets, mais d'"anciennes" Pico2. Attention au firmware (et driver
wifi) à utiliser. Pour rappel, il faut utiliser ath5k sur architecture atheros.
Il reste une dépouille au DGC à récupérer, et une borne à brasser
correctement (polynice.)
### IPs dynamiques en WiFi
À l'heure actuelle, il reste 37 IPs wifi disponibles, + 88 IPs de bornes Wifi
qui seront libérées bientôt (fonctionnement en ipv6-only.)
Trop de machines à inscrire en WiFi, et en général, pas besoin d'IP fixe.
Bilan de ce qu'on a besoin de modifier :
* Plage de rid dédiés aux machines à IP dynamiques
* Réserver la plage de rid du pool (pour éviter de l'utiliser à autre chose)
* Utiliser l'ancienne plage des bornes
* Modifier parefeu v4 (filtre mac-ip -> filtre mac)
* Rien à faire dans le parefeu v6 (woot)
* Dhcp
* Et du DNS à la volée ?
* Kikooo mais pourquoi pas
* Il y a aura déjà de l'ipv6 dans le ndd
Le vlan 6 (avec taggage dynamique) a toujours du mal à cohabiter sur les
bornes… (snif)
### Bilan des dernières coupures de courant
Les problèmes à l'extinction :
* Des serveurs avec le mauvais mdp root (réglé)
* Acpi non dispo sur plusieurs vm et machines fixes (c'est mis dans bcfg2)
* Les serveurs non-crans ont pour certaines le même problème (osm, rezosup),
c'est plus problématique car on n'y a pas accès, on contacte les proprio en
question
* Il faut régler pulsar pour lancer des ordres d'extinction, il dispose d'une
fonction d'envoi de trappe snmp
* Faire gaffe à ce qui est ondulé au 2B (sic)
Au boot :
* Les machines qui s'allument toutes seules au 0B, mais aussi au 4J (cochon qui
essaie de monter le NFS alors qu'on veut que personne n'y touche…)
* C'est dégueulasse les CR du
crans… -- WikiCandy <<DateTime(2015-02-09T17:10:51Z)>>
* Rejoncter la deuxième sortie (sur 3) a provoqué un appel de courant trop
important, ce qui a fait rebooté à nouveau les serveurs
* Le wake-on-lan des serveurs distants (babar et omnomnom) a bien marché
Il serait aussi préférable d'onduler correctement le 4J, afin de protéger
l'imprimante et le serveur de diffusion des surtensions.