documentation/compte_rendus/2009_03_05.md

Réunion Nounous

• Date : Jeudi 5 mars 2009
• Lieu : PdJ
• Début : 20h02
• Fin : ????

Présents

• Antoine Durand-Gasselin
• Arnaud Deblonde
• Augustin Parret-Fréaud
• Nicolas Bruot
• Olivier Huber
• Pierre Chambart
• Roman Yurchak
• Stéphane Glondu
• Xavier Lagorce

Via Gobby :

• Brice Dubost
• Mathieu Segaud
• Michel Blockelet

Ordre du jour

Bilan du câblage des appartements de l'ENS

Tout passe par Titanic et semble marcher. Le Squid a été configuré. Les règles de base du firewall sont appliquées.

Reste à faire :

• Du nettoyage dans annuaires.py
• Ouvrir plus de ports et filtrer d'autres (p2p, toussa)
• Firewall généré par firewall.py
• Envoyer un mail pour organiser une réunion avec les personnels
• S'occuper vite des logs de squid
• Créer une page wiki expliquant comment ça marche

Migration vers Lenny

Migration des services

Il faudrait faire une page wiki permettant de recenser les différents services qui doivent être migrés avant le passage à lenny. Si un apprenti veut par exemple configurer un domU imap, horde et migrer la configuration sous bcfg2.

Services critiques :

• freeradius
• postfix
• dns
• horde
• dovecot
• ipp2p (pas dans les dépôts Debian mais ça se corrige, si quelqu'un a envie

de regarder dans les arcanes de kernel-package, surtout kpatch)

Voir /usr/share/doc/<nom-du-paquet>/NEWS{,.Debian} (sur une machine sous Lenny) pour des infos sur la migration.

Lire aussi les release-notes. Bien penser à mettre à jour le wiki.

Passage en UTF-8

Il serait de bon ton de profiter du passage à lenny pour migrer vers l'UTF-8. Les scripts de configuration ne devraient pas poser de problèmes, par contre les scripts de gestion possèdent des parties spécifiques à l'ISO (et donc affichent de l'ISO même en UTF-8).

Il pourrait y avoir des problèmes avec les noms de fichiers (dans les homes des adhérents).

Migration des homes sur la baie SAS

Maintenant qu'on sait bien utiliser la baie SAS, et qu'elle fonctionne bien, il faut décider d'un système de fichiers, a priori de l'ext3.

Pour l'ext4 on pourra migrer plus tard. (a priori pas de souci avec tune2fs, le futur e4defrag s'occupera sans doute de convertir en extents ce qu'il bouge mais suivant la taille effective des données sur le disque à migrer, il faudra se poser la question de dumper ou simplement upgrader le système de fichiers)

On pourra alors augmenter les quotas. Il faudrait décider de la taille accordée à la partition pour les homes et de la nouvelle taille des quotas.

Il faudrait aussi régler le problème de limite soft/hard avec postfix et dovecot.

Migration des services de rouge

On pourrait créer un domU pour chaque service de rouge (avec intégration dans bcfg2).

À terme, l'idée serait d'acheter n domO comme fx et fy.

On peut garder les serveurs actuels comme serveurs de secours (ou load balancing, cela permet de tester le secours en permanence).

• Benjamin se porte volontaire pour faire un domU avec dovecot et postfix à jour sous lenny.
• Nicolas se porte volontaire pour faire un domU horde - roundcube.

Asterisk

On peut mettre en place quelque chose rapidement, il suffit d'installer le paquet Debian. Et puis après on pourra commencer à faire des trucs plus fun avec LDAP (même si c'est configuré en 30 minutes). Il faudra ensuite déployer des faisceaux vers et depuis le réseau téléphonique commuté, mais avant cela il faudra écrire une gestion complète des temps de com.

Xavier et Roman se portent volontaires.

WPA2

Ragnarok en 4.4

Olivier et WikiRegala s'en chargent après-demain.

Tests sur les bornes

Il faut que quelqu'un lise la doc du wiki et fasse des tests sur des bornes. Je commence à m'en occuper samedi midi. Des firmwares du SVN d'il y a 3 jours sont prêts (un avec un 2.6 et un avec un 2.4, le 2.4 étant le choix premier)

PAF s'en charge, s'il a des questions, WikiRegala pourra y répondre.

Haute disponibilité des bornes (avec un MONTE)

http://en.wikipedia.org/wiki/The_Killer_Robot_Instability

Le module est en cours de conception. Ca devrait être cool.

Cameras

Malgré ce que Michel a touché, ça n'a manifestement pas amélioré le comportement de la caméra du 0B.

Maintenant que le CROUS compte utiliser sa clé du 0B, il faudrait qu'elle envoie des photos par mail. On pourrait échanger celle du 0B et celle du 2B. Ou tenter de réinstaller le système de la caméra du 0B.

Il faudra penser à réorienter la caméra dans une position où on voit vraiment quelque chose d'intéressant ...

Intranet

On recherche un mainteneur pour l'intranet. Il y a des bugs à corriger et des fonctionnalités à ajouter. Soyons d'accord, on n'impose pas un quelconque langage pour les développements Web sophistiqués (à savoir avec gestion de session). On bannit néanmoins l'asp et le php.

On peut continuer sur la lancée actuelle de l'intranet, et tout faire en Python. Ca évite aux gens d'apprendre 50 langages différents pour maintenir les scripts au Cr@ns ... De plus ça permet l'intégration facile avec les autres scripts et librairies (ldap_crans.py ?). Ça serait dommage de jeter l'existant après tout ce qui a été fait. Par contre cela n'interdit pas de le nettoyer.

Remettre fx en production

Il faut le faire booter sur Slon (la baie de disques).

La question ne se pose pas sur l'usage de xen, mais bien sur le fait qu'il faille configurer le BIOS de fx pour que celui-ci puisse booter depuis l'iSCSI (Jérémie s'en occupe)

Mathieu suggère d'essayer de préparer une possible nécessaire migration d'ici squeeze sachant que Red Hat bosse sur des solutions de gestion de plateforme de virt commune à toutes les solutions (vserver, openvz, xen et kvm) pour faciliter des migrations (Certaines versions de Fedora utilisaient Xen comme solution, la future Fedora 11 utilisera KVM). Le sujet est en pleine explosion, avec différents leaders de l'écosystème !OpenSource essayant d'imposer telle ou telle solution, telle ou telle interface de gestion... D'ailleurs, il pourrait être intéressant de préparer une telle interface, un tableau de bord pour gérer les domU à partir de l'intranet (gérer des droits nounous sur l'intranet ne devrait pas poser de problème, on peut même utiliser gpg)

Munin

Munin est un domU, il souffre énormément (cf. graphes Munin). Il faudrait le mettre sur une machine dédiée. Pégase a l'air tout indiqué, il faudra quand même qu'on migre radius avant.

Génération de la conf de munin

Il faut automatiser la génération de la conf munin et de l'installation des plugins (et de la gestion correcte des encodages). (si migration vers UTF8 il y a, pas de "gestion incorrecte" des encodages :))

Il faudra rajouter dans bcfg2 la gestion de la conf pour les munin-node, et un script maison qui parsera les fichiers de conf de bcfg2.

Webalizing

Ça fait depuis longtemps que ce qu'il y a sur rouge ne marche plus, mais on s'en soucie guère.

A noter qu'à l'époque où webalizer était utilisé, il avait tendance à occuper

énormément de ressources, et que certaines fois, il plantait et utilisait tout

le CPU pendant plusieurs heures ...

Pré-Inscription

Il semblerait que le nouveau BDE ait accepté de mettre un module réseau sur le photocopieur de la Kfet (Geneviève en a discuté avec eux).

Il faut développer une application web d'inscription en ligne. Xavier s'est déjà porté volontaire pour regarder.

Questions diverses

Backup physique

On compte mettre en place une copie des backups qui ne soit accessible qu'en lecture seule.

• Les bandes magnétiques sont la meilleure solution
  • il faut une idée de prix et de matériel, et que ça ne soit pas trop cher
    • On peut compter un système assez bien à environ 2000EUR (j'ai cru voir).

Egon

Il faut changer et réinstaller egon car son comportement est de plus en plus erratique. Proposition d'achat d'une nouvelle machine pour un budget de 1300EUR Proposition d'achat d'un écran 30" HP au prochain CA

Alimentation du 0B

Il y a actuellement un problème d'alimentation au 0B, lors de la mise sous tension, les alimentations des serveurs consomment un pic de courant qui fait disjoncter l'onduleur.

Deux solutions différentes sont proposés, une par Valérian basé sur des relais retardés et une seconde sur une multiprise ssh. La multiprise ssh présente l'avantage de permettre de manager à distance l'alimentation des serveurs.

On contactera toutefois Anne Cazalet avant d'effectuer un tel achat.