218 lines
7.3 KiB
Markdown
218 lines
7.3 KiB
Markdown
# 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
|