## page was renamed from ComptesRendusCrans/Jeudi5Février2015IN #acl +All:read <> = Réunion du Collège Technique = * Date : Jeudi 5 février 2015 * Lieu : Pavillon des Jardins * Début : 19h07 * Fin : 20h00 * Lien vers l'[[http://pad.crans.org/p/Jeudi5F%C3%A9vrier2015IN|etherpad associé]] ## Heu… <> <- Mais c'est de la merde cette macro ! Elle ne prend pas d'arguments donc elle ne résiste pas au renommage… (et en plus elle met un espace là où il ne devrait pas y en avoir) -- ZeldAurore <> ## L'espace a été corrigé (cf commit https://gitlab.crans.org/nounous/scripts/commit/60d7087c606084c5eb566a3578207b32148697ee ), mais le wiki n'avait pas été rechargé (done.) Supporter le renommage (par exemple en parsant "page was renamed from ComptesRendusCrans/Jeudi5Février2015IN" ou avec un argument) est une feature intéressante, patches welcome. -- WikiB2moo <> == 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 <> * 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.