documentation/compte_rendus/2009_01_29.md

Réunion Nounous

• Date : Jeudi 29 Janvier 2009
• Lieu : PdJ
• Début : 20h02
• Fin : 21h30

Présents

• Antoine Durand-Gasselin
• Arnaud Deblonde
• Johan Grande
• Michel Blockelet
• Olivier Huber
• Xavier Lagorce

Ordre du jour

Suite du câblage des nouveaux appartements de l'ENS

Il serait bon d'avoir une idée de l'infrastructure avant que la DSI ne nous donne un numéro de VLAN. Idéalement, il serait bon d'être prêts rapidement. Nicolas semble avoir commencé à réfléchir à la question, et maintenant qu'il est en stage, il a plein de temps devant lui ! pour mettre tout celà en place :)

Il faudrait aussi adapter la base LDAP à ces nouveaux adhérents, et modifier les règles de filtrage d'upload (faudra voir si la solution en place marchera ootb).

En tout cas, il faudra soumettre ces nouveaux adhérents aux mêmes restrictions que ceux passant par RENATER, la connexion utilisée étant tout de même mutualisée.

Attribution de nouveaux droits

On a un apprenti, Olivier Huber, qui a fait plein de trucs. Les nounous présentes sont favorables à sa nomination en tant que nounou (ça sera plus simple pour tout le monde).

D'ailleurs, ça me fait penser qu'on a un serveur sous OpenBSD 4.2 à mettre à jour ...

Achat de matériel électrique

Pour le problème de retour de l'électricité au 0B, on prévoit d'acheter deux multiprises ssh. Ce n'est pas donné mais ce n'est pas non plus si cher que ça. On en reparlera à la prochaine réunion CA.

De plus, ça peut se révéler pratique.

La ferme

Ces derniers temps, la ferme a connu beaucoup d'histoires (http://www.amazon.fr/Braice-à-la-ferme-tome4/dp/2203101016/).

Tout d'abord, mouton est mort; ses services ont été migrés sur mdr (qui s'appelle maintenant aussi vache.ferme), et quelques modifications ont été apportées aux scripts pour qu'ils fonctionnent avec la nouvelle version de MumuDVB.

Par ailleurs, Braice a remis les serveurs dans un état "stable", comme il nous l'explique :

"Avant, on utilisait des noyaux persos et un udev 054 compile statiquement avec la klibc. Le noyau actuel de etch ne supporte pas toutes les cartes, mais le 2.6.24-etchnhalf si.

Il y a eu plusieurs problemes lors de la mise à jour :

• la migration de udev
• le slash fait 180Mo

Ces deux problèmes sont désormais résolus sur les trois serveurs.

Ce qu'il reste a faire :

• Passer a lenny.
• Utiliser un paquet debian pour mumudvb.
• Utiliser les scripts d'init de mumu et monit au lieu de cron pour le surveiller.
• Faire du ménage/tri dans les chaines sat.
• Acheter une carte TNT pour les chaines HD.
• Acheter des multiswitch :

http://www.2galli.fr/boutique/fiche_produit.cfm?type=33&ref=P122ASAT&code_lg=lg_fr&pag=1&num=161

Wifi

WPA

Regala n'a pas le temps de s'occuper de déploiement de sa solution Wifi alors qu'elle fonctionne. Il cherche quelqu'un ayant le temps de s'en occuper. La plupart des informations nécessaires se trouvent sur le wiki :

http://wiki.crans.org/WifiTechnique/WpaEnterprise

Pour faciliter la migration chez les adhérents, il serait préférable de garder les deux systèmes (IPSec et WPA) en parallèle, au moins au début. Regala dit que les machines sur le réseau IPSec et le réseau WPA ne peuvent pas partager la même plage d'IPs, il faudra donc se pencher sur le problème.

Les choses à faire sont donc :

• Tester le système développé par Regala sur deux bornes
• Documenter la chose pour les adhérents
• Commencer le déploiement de bornes avec le WPA, sur un réseau Wifi séparé Cr@ns-WPA

Et on aura enfin la paix avec les Vista-users !

• Tu paries ?

Gestion des bornes

Xavier, a eu l'occasion d'effectuer quelques tests avec les bornes. Quand le userspace des bornes plante, elles continuent à pinger (donc ne sont pas détectées down par l'autostatus) mais ne fournissent plus de wifi.

Xavier va donc travailler sur un système de heart-beat pour améliorer la détection du plantage. Ainsi qu'un système de reboot matériel par le réseau.

Sinon, Michel et Xavier proposent que l'on monte les bornes dans des robots autonomes qui reviendraient au 2B pour qu'on leur fassent un câlin dès qu'elles sont plantées. Le problème, c'est qu'il y aura toujours une quinzaine de robots dès qu'on va au 2B. Et qu'ils risquent de se perdre dans les couloirs de l'ENS ou à la Kokarde...

Asterisk/Mise en place de la téléphonie IP

Le projet traîne depuis un moment, et il commence à devenir un peu plus "urgent" de s'en occuper.

Ce qu'il faudrait faire :

• Mettre en place un serveur Asterisk bien sécurisé
  • A tester en interne d'abord
• Mettre en place une interface utilisateur ergonomique (à peu près comme l'intranet ?!)
• Trouver un fournisseur extérieur qui nous permette d'appeler tous les numéros du monde
• Bien compter les communications de chacun (en particulier, débiter au bon tarif de la communication), et couper les communications quand la personne n'a plus d'argent sur son compte
  • Compte pré-payé (le même que pour l'impression ?)
  • Facture post-utilisation (dangereux)
  • Abonnement tous les mois (dangereux)
• Trouver du hardware, qu'on pourrait vendre aux adhérents

A noter que Regala bosse dans ce domaine, il s'y connaît très bien; il sera donc de très bon conseil.

Projets en cours ou futurs

Formulaire de préinscription en ligne

Xavier y travaille.

Détection des router-advertisements

Olivier a écrit un programme en C, qu'il faut encore un peu compléter. Il faudra aussi écrire un script en Python pour l'interfacer avec le reste du système du Cr@ns.

Réflexions sur l'IPv6

Problèmes:

• l'ENS ne nous fournit pas une connexion IPv6
• nos switchs ne sont pas IPv6-aware (en tout cas pour le multicast)
• nos serveurs ne sont pas IPv6-aware (le module IPv6 de etch est tout pourri)
• Qui maîtrise IPv6

Il faudra quand même commencer à y réfléchir et à se renseigner dessus.

Bugs de l'intranet

L'intranet est buggé. Antoine va essayer de voir ce qu'il arrive à comprendre. Xavier émet l'hypothèse de recoder l'intranet.

L'imprimante et les marges des pdfs

On peut rajouter des features dans l'interface de l'intranet pour l'impression. Xavier et Nicolas ont l'air motivés.

Mise en place du service de boot PXE

• Documentation
• Interface pour les adhérents, pour se mettre sur le VLAN 10
• Filtrage de ce qui passe sur le VLAN 10, afin que les adhérents n'utilisent pas le VLAN pour faire des trucs mal
• Mettre des rescue-cd ?

Réorganisation des services Pegase/Munin

• Il y a encore un serveur radius sur pegase. Il faut le réinstaller sur une autre machine, avant de réinstaller munin dessus. On va créer un serveur radius qu'on va mettre au 0B. On pensait plutôt à un domU. Dès que le serveur radius est installé, on fait des test, et ensuite on peut s'amuser avec pegase (qui ne sera pas renommé).
• munin chie complètement ses I/O, on va l'installer sur une vraie machine: pegase.
• Si y a des gens qui ont des idées pour la génération du fichier de conf de munin, ils priveront Nicolas du plaisir de peupler à la main les nodes.

Questions diverses

fx

• On va essayer de faire booter fx sur le reseau comme fy. Faudra trouver un soir

où on n'a rien à faire, et plein de bouteilles de coca

• Après, on s'amusera peut-être à faire du load-balancing.

---

CatégorieCrans