diff --git a/compte_rendus/2003_10_02.md b/compte_rendus/2003_10_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..d4208212eb661ba2bd77f524e3dd345b33e9e241
--- /dev/null
+++ b/compte_rendus/2003_10_02.md
@@ -0,0 +1,118 @@
+# Réunion IN
+
+Ce jeudi 2 octobre a eu lieu une internounou.
+
+## Présents
+
+* Frédéric Pauget (Fred)
+* Manuel Sabban (M@nu)
+* Mathieu Segaud (Regala)
+* Nicolas Stransky (Nico)
+* Sandor Szakacs
+* Sébastien Li-Thiao-Te (Sayan)
+* Vincent Bernat (Vince||)
+* Vincent Hanquez (Tab)
+* Yves-Laurent Allaert (Manathan, ouvre-bouteille)
+
+## Élection du RTC
+
+Le seul candidat est Fred dont le programme est de synchroniser le
+travail de chacun. Fred est élu à l'unanimité des nounous présentes.
+
+## Mailman
+
+La nouvelle version de mailman est en Français et sera donc installée
+Ã la place de la version actuelle.
+
+Pour simplifier l'accès à mailman, un virtual host lists.crans.org
+dans Apache. Quant à laisser toutes les listes dans un sous-domaine
+lists.crans.org, cela n'apporte pour le moment pas d'avantage étant
+donné que les noms ne sont pas en collision avec des noms réels.
+
+Il serait souhaitable de préfixer le nom des mailing lists par la
+raison d'être de la liste (club-, ens-). Les listes actuelles seront
+éventuellement renommées avec la prochaine version de mailman. Les
+archives pouvant prendre trop de place, elles ne seront pas
+disponibles pour les ML non CRANS.
+
+## Script d'inscription nounou et câbleur
+
+La partie en Perl est à refaire. Il est également possible de
+synchroniser les listes avec les groupes grâce à mailman mais cela ne
+règle pas entièrement le problème (cf les alias batx).
+
+## Site web
+
+Certaines pages ne sont plus à jour. Il serait possible de recruter
+une personne pour s'occuper du site web. Certaines pages pourraient
+être générées dynamiquement (genre, liste des câbleurs). Un
+département de l'ENS pourrait mettre le site du CRANS comme projet ?
+Il s'agit seulement de trouver quelqu'un qui fait des mises à jour du
+site, ce qui peut être assez inintéressant pour un projet et assez
+inadapté.
+
+## Moteur de recherche news
+
+Les tac.* expireront au bout de 6 mois. Un moteur de recherche
+incrémental sur les news pourrait être installé, comme swish++ qui
+devra être interfacé avec le serveur web. Les newsgroups pourront être
+accessibles également via une interface web (avec mot de passe depuis
+l'extérieur). Reste à trouver quelqu'un pour le faire.
+
+## Glasnost
+
+Il refonctionne de nouveau, on continue de l'utiliser jusqu'Ã la
+prochaine upgrade qui foire pour le remplacer par un autre système de
+publication, style SPIP, même si celui-ci n'intègre pas de système de
+vote.
+
+## Gestion du FTP
+
+Le miroir Gentoo prend de plus en plus de place (plus de 33 Go, la
+partition est pleine), il faudrait regarder si on peut lui faire
+prendre moins de place. Il est possible de racheter un disque dur si
+besoin ou alors de virer le miroir Gentoo. Pour se fixer, il sera
+souhaitable de faire des statistiques.
+
+## Scripts de gestions des adhérents
+
+edit pourrait être modifié pour vérifier que les fichiers sont sous la
+bonne forme. L'édition à la main des fichiers sera interdite (plus de
+edit).
+
+## Sayan nounou
+
+Sayan a installé Tanek qui sert désormais de machine de
+sauvegarde. Pour le moment, seuls quelques fichiers systèmes sont
+sauvegardés. A terme, il sera possible de sauvegarder mails et homes,
+mais il faudra de nouveaux disques (2 nouveaux disques). Le site web
+n'est pas encore sauvé, les logs ne sont pas sauvegardés non plus et
+il faudrait le faire (squid + postfix). Sayan est passé nounou Ã
+l'unaminité.
+
+## Switchs
+
+Les switchs Dlink achetés l'an dernier s'avèrent en fait très chers
+comparés à ce qu'on trouve sur le marché, aussi bien chez Dlink que
+chez d'autres constructeurs. Par exemple, on trouve le Dlink DES 3226S
+Ã 490 euros HT, c'est la version manageable de ce qu'on a
+actuellement. Plus intéressant, 3Com fait le 4226T et 4228G tous les
+deux à 490 euros HT. Ils sont tous les deux 24 ports mais à la
+différence du Dlink intègrent deux ports gigabits cuivre. En
+contrepartie, ils n'ont pas l'agrégation de liens sur les ports
+normaux (mais on peut chaîner en gigabit).
+
+Le 4226T est manageable et peut manager 3 4228G. Son fond de panier
+est de 8.8 GBps (comme le DLink). Le 4228G a un fond de panier plus
+élevé, la possibilité de mettre deux ports GIBC fibre mais n'est pas
+manageable (il dispose tout de fois d'une console série comme les
+Dlink que l'on a actuellement).
+
+Dans le futur, on pourrait donc acheter une combinaison de ces switchs
+(ou encore du 4250T, version 48 ports, manageable, mais sans extension
+fibre optique) pour mettre dans les bâtiments. Cette possibilité sera
+étudiée plus en détails.
+
+Cerise sur le gâteau, tous ces switchs supportent le multicast.
+
+La réunion a pris fin vers 22h50.
diff --git a/compte_rendus/2003_11_27.md b/compte_rendus/2003_11_27.md
new file mode 100644
index 0000000000000000000000000000000000000000..72caaa745ab472d9b2b5a5f27da1b9b915473d98
--- /dev/null
+++ b/compte_rendus/2003_11_27.md
@@ -0,0 +1,119 @@
+# Réunion IN
+
+Le 27 novembre 2003 une internounou (réunion privée) s'est tenue.
+
+Présents :
+
+* Sébastien Li-Thiao-Té (Sayan)
+* Manuel Sabban (M@nu)
+* Yves-Laurent Allaert (Manathan)
+* Nicolas Sturmel (Personne)
+* Frédéric Pauget (Fred)
+
+Excusés :
+
+* Nicolas Salles (mo²)
+* Nicolas Stransky (Nico)
+* Mathieu Segaud (Régala)
+
+## Bilan sur les switchs HP achétés et avenir
+
+Bon fonctionnement des switchs au B. L'équipement va être poursuivi au
+G et par l'achat d'un backbone gigabit neuf.
+A terme les liaisons inter-bat seront Gigabit et toutes les prises
+manageables avec filtrage d'IP.
+
+## Avenir de egon
+
+L'utilisation de Egon en machine de test est satisfaisant : on ne
+change rien.
+
+## Discussions sur le système de sauvegarde
+
+Il y a un problème de sychronisation des homes plus particulièrement
+concernant les permissions sur les répertoires : la sauvegarde se fait
+en root sur zamok mais pas sur tanek ; il n'est pas possible de
+redonner les bonnes permissions.
+
+Solution : sauvgardes sur zamok sans être root mais en étant un user
+'normal' appartenant aux groupes de users, les répertoires non
+lisibles par cet user seront ignorés.
+
+Actuellement les mails, les news, le site web, les logs et confs des
+serveurs sont sauvegardés régulièrement. Le problème des homes va être
+résolus et seront donc sauvegardés.
+
+## La détection de DHCP 'pirates' et de broswe master samba
+
+La détection de DHCP est opérationelle, un test est effectué toutes
+les 10 minutes. Aucun DHCP pirate détecté.
+
+Pour le cas des browse master samba, un premier test a montré que le
+browse master n'était quasiment jamais zamok. Mais que le nom du le
+nom du browse master obtenu ne correspondait pas aux entrées DNS.
+La solution envisagée est de construire une table de correspondance en
+demandant les noms samba à toutes les machines réseau. Une fois cette
+table construite il sera possible de savoir à quel utilisateur
+adresser le mail d'avertissement comme quoi sa machine est browse
+master à la place de zamok.
+
+## Les virus
+
+Il a été décidé de rechercher un antivirus de mail pouvant être
+installé au crans. Toutefois il devra être possible aux adhérents de
+désactiver se service pour leur compte ; celui-ci sera activé par
+défaut.
+
+## Le PHP sur zamok
+
+Il est décidé d'étudier la sécurité du PHP sur zamok et le cas échéant
+de restreindre son utilisation.
+
+Digression : le mysql sur zamok : est-ce utile ? voir qui l'utilise et
+pourquoi ?
+
+## Le corbeau
+
+Les clubs sont actuellement exclus du corbeau et un nouveau corbeau
+est dans le nid : son cahier des charges est :
+
+* Champ From valide depuis la zone crans (mail@crans)
+* prévoir une blacklist,
+* prévoir une modération du corbeau (lecture du message par
+* modérateur _avant_ publication)
+
+## data.tar
+
+Explications demandées sur roots.
+
+## Les anciens comptes sur les machines (ménage dans les users et groupes)
+
+Il sera procédé un ménage des comptes inutilisés selon la méthode des
+années précédents.
+
+Un ménage des utilisateurs privilégiés est commencé :
+la liste des personnes ayant le droit d'édition des sites des clubs et du site
+de l'association à été réduite, si vous aviez les droits mais que le ménage ne
+vous a pas épargné et que vous en avez besoin, envoyer un mail à nounou. un
+ménage a été également effectué dans les administrateurs.
+
+## moteur de recherche news
+
+Le moteur est fonctionnel mis à part la visualisation des pièces
+jointes non texte. Ce point est en cours d'amélioration (surtout pour
+les images).
+Une fonctionnalité requise est également la lecture des messages
+signés pgp.
+
+## Clés du B
+
+Le président à laissé sa clef du 0B au nounous qui pourront mieux s'en
+servir en cas de problème.
+
+## ptrace-kmod.c
+
+(code permettant de passer root en exploitant une faille de sécurité)
+
+Le fichier est postérieur à la mise à jour de zamok contre cette
+faille. Toutefois une demande d'explication pour la précense de ce
+fichier est requise.
diff --git a/compte_rendus/2004_03_11.md b/compte_rendus/2004_03_11.md
new file mode 100644
index 0000000000000000000000000000000000000000..412bc61cae8761628da20df38eabf6ee8ff3765d
--- /dev/null
+++ b/compte_rendus/2004_03_11.md
@@ -0,0 +1,130 @@
+# Réunion IN
+
+Ce soir, jeudi 11 mars 2004, a eu lieu au PdJ une internounou.
+
+Présents :
+
+* Arnaud Sternchüss (Schultzy)
+* Benoit Rozel
+* Charles Signorini
+* Christophe Calvès (Grand Tof)
+* Frédéric Pauget (Fred)
+* Manuel Sabban (M@nu)
+* Mathieu Bérard
+* Mathieu Ségaud (Regala)
+* Olivier Deleage (O-live)
+* Sandor Szakacs
+* Sébastien Barthélemy (Seb)
+* Sébastien Li-Thiao-Te (Sayan)
+* Vincent Bernat (Vince||)
+* Yohan Le Diraison (Ryo)
+
+## Passage en testing ?
+
+Sila étant aussi performant que Egon, Egon pourrait remplacer Sila,
+Sila serait passé en testing et en 2.6 et des tests seraient
+conduits. Une fois que Sila marchera bien en testing et avec un 2.6,
+il reprendra sa place. Egon sera passé en testing avant de remplacer
+Sila.
+
+Pour résoudre les problemes de log actuels de Sila, son immobilisation
+pourrait servir également à revoir la taille des partitions.
+
+Remplacement du FTP d'OpenBSD par ProFTPd.
+
+## Wifi
+
+Les bornes Linksys disposent de Linux et il y a sur le web beaucoup de
+pages expliquant comment le modifier pour divers besoins.
+
+La borne pourrait être équipée de IPv6 + IPsec.
+
+Linksys WP54G
+
+## Switchs
+
+Trois nouveaux switchs seraient commandés dont 1 pour le G. Les deux
+autres iraient au I en raison de sa position centrale, y compris de
+par sa topologie (les fibres pour le H, I et J y arrivent). Le seul
+hub qui reste actuellement est au M (en plus du PdJ). Le matériel
+inutilisé sera utilisé lors des installs party.
+
+## Ménage sur les comptes administrateurs
+
+Les personnes n'ayant pas répondu au dernier mail sur le sujet
+perdrons leurs comptes sur le serveur.
+
+## Todo list
+
+### Scripts d'adhésion
+
+Il y a plus de vérifications qu'auparavant. Notamment, les noms des
+serveurs ne peuvent plus être pris. Il y a une cinquaintaine de
+personnes qui devraient avoir un compte sur zamok et n'en ont pas. Les
+autres problèmes actuels ont été passés en revue et les nouveaux
+scripts évitent tous ces cas. Le problème des conflits d'alias ont
+également été évoqués mais leur résolution n'a pas encore été trouvée.
+
+Le filtrage par adresse des MAC sera mis en place. Que faire pour que
+les cableurs puissent venir tester rapidement ? On peut rediriger sur
+une page qui permet à l'utilisateur inconnu de s'identifier avec son
+compte zamok. Les cableurs pourront également ajouter des adresses
+temporairement (la leur).
+
+### Moteur de recherche sur les news
+
+Manathan a conçu un moteur de recherche sur les news qui est quasiment
+terminé. Il sera intégré sur zamok au site. Il ne sait pour le moment
+pas afficher les pièces jointes.
+
+### Recherche des mots de passe faible
+
+Le script est en place, mais il ne tourne pas en permanence.
+
+(HS : WEI : la roue de la déconnexion (sur une idée de Schultzy))
+
+L'idée d'un scan régulier (toutes les semaines ?) est gardée. La seule
+action est d'envoyer un mail.
+
+### Browse master samba + DHCP
+
+Le premier script utilise smbclient pour prévenir les adhérents et
+peut envoyer des mails. Le DHCP envoie des mails aux nounous (Ã Manu
+et Manathan). Ces scripts devraient être déplacées sur d'autres
+machines que celles de tests.
+
+### Sécurisation Apache
+
+Les scripts PHP des adhérents sont actuellement exécutés par un
+utilisateur dédié.
+
+### Sécurisation PHP
+
+Peut-on utiliser le safe mode sur zamok ?
+
+### Chaines MAC-IP
+
+Le lancement du firewall prend énormément de temps. Manu va ajouter le
+code nécessaire pour ajouter ou enlever une correspondance ce qui
+éviterait la construction entière de la chaîne de correspondance.
+
+### Modération automatique des posts dans followup-to
+
+À faire.
+
+### Amavis
+
+Une liste blanche devrait être mise en place. Mais en attendant,
+l'antivirus est gardé. Les râleurs peuvent toujours l'améliorer (mais
+le laisser fonctionnel).
+
+### Ménage des comptes inutilisés
+
+Sandor fera ça rapidement et documentera la procédure.
+
+### Install Party
+
+Une réunion sera organisée demain soir au 2B avec notamment la
+procédure d'installation.
+
+La réunion s'est achevée à 21h30.
diff --git a/compte_rendus/2004_05_06.md b/compte_rendus/2004_05_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..7e39cd29ef67fb4c12ba8edff5b45c71d063fe61
--- /dev/null
+++ b/compte_rendus/2004_05_06.md
@@ -0,0 +1,138 @@
+# Réunion IN
+
+Ce jeudi 6 mai 2004 s'est déroulée une réunion internounou au Krobot à 21h30.
+
+## Présents
+
+* Benoit Rozel
+* Fabien Millioz (Mit Mit)
+* Sébastien Li-Tao-The (Sayan)
+* Julien Ducarne (juliend)
+* Arnaud Sternchüss (Schultzy)
+* Yohan Le Diraison (Ryo)
+* Manuel Sabban (M@nu)
+* Mathieu Ségaud (Regala)
+* Frédéric Pauget (Fred)
+* Yves-Laurent Allaert (Manathan)
+* Vincent Bernat (Vince||)
+* Philippe Gambette (Freecorp)
+* Christophe Calvès (Grand Tof)
+* Olivier Deleage (O-live)
+* Clément Houtmann (ClemHout)
+* Charles Signorini
+
+### Synchronisation
+
+Un nouveau serveur de sauvegarde a été acheté il y a deux semaines. Il dispose
+de 1 To de disque dont environ 695 Go en RAID 5 pour les sauvegardes. Une
+sauvegarde journalière est effectuée de :
+
+* {{{/etc}}}, {{{/boot}}}, le CVS, les paquets installés ce qui fait
+ environ 3,6 Mo par jour
+* Le {{{/home}}}, les mails, les news, le wiki, jabber, les ML, le site
+ web ; ce qui fait environ 30 Go par jour
+
+On conserve les 3 derniers dimanche ainsi que la semaine en cours. La mise Ã
+jour se fait par rsync. Une fois par jour, la dernière sauvegarde est
+sauvegardée au cas pour éviter de perdre toute une semaine en cas de perte des
+données sur les serveurs d'origine.
+
+### Situation de Debian
+
+Les serveurs du CRANS sont passés en Debian/Testing qui devait devenir la
+prochaine stable assez rapidement. Cela a permis de mettre des 2.6 sur les
+serveurs. Debian ne suit pas la GPL mais dispose de son propre manifeste : la
+DFSG. Ce manifeste a été précisé récemment par un vote et le kernel, entre
+autres, est désormais considéré comme non libre. La Sarge pourrait donc être
+retardée d'un an par un tel changement. L'avenir de Debian est du coup assez
+mouvementé avec des développeurs qui partent.
+
+Parmi les alternatives possibles, Open BSD pourrait être une solution. Il est
+toutefois beaucoup trop tôt pour s'avancer sur ce point.
+
+### LDAP
+
+LDAP est une sorte de base de données permettant de regrouper les informations
+sur les utilisateurs donc les adhérents avec de grandes facilités
+d'interrogation. Il fonctionne en architecture client/serveur, ce qui évitera
+d'avoir à transférer les différents fichiers par scp : chaque machine peut
+interroger elle-même la base. Par la suite, il serait aussi possible
+d'effectuer les authentifications par LDAP.
+
+Migration :
+
+* réécriture des scripts de câblage pour supporter LDAP (ce qui fera du bien de
+ repartir sur une base plus récente)
+* réécriture des scripts de génération des fichiers de configuration (DNS,
+ DHCP, etc)
+
+La réécriture permettra aussi de documenter proprement ce qui est fait. Le fait
+que les informations soient centralisées facilitera grandement la recherche
+d'information : à un adhérent sera attaché toutes les informations qui le
+concerne dont l'upload, les virus, etc.
+
+M@nu se propose pour l'interface GTK.
+
+### Documentation
+
+Chaque nounou qui fait quelque chose sur les serveurs doivent faire une
+documentation de préférence sur le wiki. Une autre tâche serait de documenter
+aussi l'existant quand on en a l'occasion. Une partie de la documentation sur
+zamok peut également migrer sur le wiki.
+
+### Salle de réunion
+
+Une salle a été demandée pour mettre Pegase mais celui-ci va atterrir au H
+quand les nouveaux switchs seront arrivés. Cette salle pourra donc servir de
+salle de réunion.
+
+### Budget
+
+Pour éviter d'avoir à demander au CA pour des achats mineurs (feutres, têtes de
+câble, tableau blanc, processeur), les nounous désirent avoir un budget fixe et
+un chéquier pour eux. Le CA se renseigne sur les solutions possibles. Ce point
+sera porté à l'OdJ de la réunion CA de lundi.
+
+'''Moi j'ai du mal à présenter à moi-même les factures...''' -- ClemHout
+
+### Videolan
+
+Schultzy va prendre contact avec les types de Videolan. Il y a deux solutions :
+
+* recevoir le flux de Centrale
+* encoder nous mêmes
+
+Les nouveaux switchs facilitent la diffusion sur le campus, notamment grâce au
+multicast.
+
+M@nu prendra également contact pour proposer d'héberger un miroir Videolan.
+
+### Sécurisation PHP
+
+Quelles sont les fonctionnalités voulues ?
+
+* exécuter des scripts ne nous appartenant pas
+* avoir le droit d'exécuter des commandes arbitraires
+* autoriser l'ouverture d'URL
+* modification des fichiers par PHP ?
+
+Sayan nous sortira les solutions disponibles.
+
+### Synchronisation CA
+
+Que doivent faire les nounous quand il y a un grand désaccord avec le CA, comme
+par exemple une divergence importante de point de vue sur le sort d'un
+adhérent ? Les demandes doivent être données clairement au CA de façon à ce
+qu'il n'y ait pas d'ambiguïté.
+
+### Divers
+
+* La blacklist sera accessible au câbleur sur le nouveau système
+* Un adhérent veut faire un forum sur zamok et demande l'autorisation et
+ accepte la surveillance ; toutefois, les nounous n'ont pas le temps
+ nécessaire pour ça et donc le forum est interdit.
+* Le miroir Gentoo est supprimé et personne ne s'est plaint
+* Le sondage sur le positionnement des bornes wifi avance tout doucement : le
+ d'Alembert, la bibli et la Med sont bien placés.
+
+La réunion a été levée à 23h40.
diff --git a/compte_rendus/2006_02_28.md b/compte_rendus/2006_02_28.md
new file mode 100644
index 0000000000000000000000000000000000000000..163afd9083471b24173722664e0d82c15c6024c3
--- /dev/null
+++ b/compte_rendus/2006_02_28.md
@@ -0,0 +1,81 @@
+# Réunion IN
+
+Lundi 28 Février 2006 a eu lieu une réunion Internounou à la salle Condorcet
+Ã 19h30.
+
+## Présents
+
+* Brice Dubost
+* Charles Signorini
+* Cyril Cohen
+* Étienne Chové
+* François Bobot
+* Frédéric Pauget
+* Grégoire Détrez
+* Matthieu Segaud
+* Nicolas Salles
+* Romain Clément
+* Stéphane Glondu
+* Vincent Bernat
+* Xavier Pessoles
+
+## Ordre du jour
+
+* Mise à jour de la CransNostalgie/TodoList
+* Élection d'un nouveau RTC
+
+## Déconnexions pour upload et p2p
+
+* Mise à jour des sanctions dans la base LDAP
+
+|| || Squid|| Komaz || Radius et Ragnarok||
+|| Upload Manuel || (./) || (./) || ||
+|| Upload automatique || (./) || (./) || ||
+|| Virus Manuel || || || (./) ||
+|| Virus automatique || (./) || || ||
+|| P2P Manuel || (./) || (./) || ||
+|| P2P Automatique || (./) || (./) || ||
+|| Mail invalide || (./) || || ||
+|| Warez || (./) || || ||
+
+## Installation de cfengine
+
+Cfengine n'est pas capable de générer n'importe quels fichiers, en particulier
+pour Monit.
+Pour l'instant, Bilou continue à générer les fichiers de Monit.
+Rédaction de la liste des services à gérer par cfengine.
+
+## Imprimante réseau
+
+Problème de l'impression en Portrait / Paysage.
+Problème technologique : Bac de finition de l'imprimante.
+Question soumise au CA : Choix/Achat un bac de finition HP ?
+
+## WiFi
+
+Rien de neuf.
+Abandon du L2TP temporaire.
+Question au CA : Aller voir le CROUS pour déployer...
+
+## Ménage du cimetière
+
+Script sur vert : /etc/cron.daily/nettoie_cimetiere
+
+## Suppression de WebDav
+
+Solution trop compliquée à mettre en oeuvre pour le moment.
+
+## Élection d'un nouveau RTC
+
+Candidats :
+
+* Stéphane
+* Bilou
+
+Électeurs : 9
+
+* Bilou : 5
+* Stéphane : 3
+* Nul : 1
+
+Bilou est élu RTC.
diff --git a/compte_rendus/2007_03_01.md b/compte_rendus/2007_03_01.md
new file mode 100644
index 0000000000000000000000000000000000000000..575043f22cf784d1ee6a09175307db92f298f9b4
--- /dev/null
+++ b/compte_rendus/2007_03_01.md
@@ -0,0 +1,162 @@
+# Réunion IN
+
+Réunion technique inter nounous.
+
+## Réunion
+
+### Horaires
+
+* Date : Jeudi 1^er^ mars 2007
+* Début : 19h12
+* Fin : 20h36
+* Lieu : salle de conférence du Pavillon des Jardins
+
+### Présents
+
+* Alexandre Bos
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Brice Dubost
+* Frédéric Pauget
+* Grégoire Détrez
+* Jérémie Dimino
+* Stéphane Glondu
+* Vincent Bernat
+
+## Ordre du jour
+
+### Mails invalides
+
+Alexandre propose une gestion automatisée des mails invalides : quand il y aura
+un doute sur la validité d'une adresse mail, ou lors d'un changement d'adresse
+mail, un mail de confirmation (à la mailman) sera envoyé avec un lien. Si
+l'adresse n'est pas confirmée au bout d'une semaine, l'adhérent serait
+déconnecté avec une page explicative sur squid. Accepté à l'unanimité.
+
+### Serveur de secours extérieur
+
+Louer une baie pour y mettre notre propre serveur coûte cher et n'est pas
+forcément pratique. En revanche, louer un serveur ne coûte pas si
+cher (environ 50 € HT par mois) et OVH, par exemple, proposent des services
+intéressants (avec de bons échos). On louera donc un serveur dédié chez OVH.
+Accepté à l'unanimité.
+
+### Compte d'impression pour tout le monde
+
+Les adhérents ne sont pas encore tous au courant de l'existence du service
+d'impression, et il a été proposé de créer un compte d'office à tous les
+adhérents pour populariser ce service. Cela risque de charger un peu plus les
+câbleurs, les procédures de mot de passe peuvent être pénibles... Une idée de
+mot de passe généré ou de one-time password a été évoquée, mais
+abandonnée : l'adhérent lambda qui se verra imposé un mot de passe pour quelque
+chose dont il ne verra pas l'utilité dès son inscription oubliera très
+certainement son mot de passe (comme c'est souvent le cas actuellement) et
+devra de toute façon repasser à la Kfet. En fait, le service d'impression a été
+mis en production la rentrée dernière et n'était pas tout à fait opérationnel Ã
+l'automne 2006, mais on peut le considérer maintenant comme totalement
+opérationnel, et une campagne de pub plus poussée sera faite à la prochaine
+rentrée (lors du contact de masse avec les adhérents) afin que le service
+d'impression soit un peu plus connu.
+
+Vote : 1 voix pour, 4 contre, 4 sans avis.
+
+Pour les clubs : on donne la possibilité aux clubs d'imprimer avec leur
+compte (mais ce compte n'est créé qu'à la demande). Cela demande encore un peu
+de travail sur l'intranet.
+
+### Solde impression / Note Kfet
+
+La création d'une « note Crans » pour créditer les soldes d'impression est
+abandonnée vu les difficultés à récupérer des sous du BdE de manière générale.
+De plus, la rigueur de la gestion des notes Kfet ne correspond pas avec la
+politique générale du Crans en matière de sécurité.
+
+En revanche, il a été envisagé de « vendre » du crédit au BdE afin qu'il le
+revende aux adhérents du Crans (du moment que le BdE « prépaye » le Crans). On
+pourrait donner une compensation (à négocier) en retour. C'est à discuter avec
+le BdE.
+
+Si le BdE n'est pas d'accord, on en arrête là .
+
+### Maintien d'Alexandre Bos au poste de nounou
+
+Il s'agissait d'officialiser la nomination d'Alexandre Bos (qui s'est mis
+lui-même les droits nounou) au poste de nounou. Accepté à l'unanimité.
+
+### Nouveaux serveurs
+
+Stéphane a appelé Anne Cazalet ce matin ; un devis devrait être reçu avant la
+fin de semaine. Anne pourrait venir à la prochaine réunion CA.
+
+## Impromptu
+
+### Expiration de la garantie de Pegase
+
+La garantie de Pegase vient d'expirer, Dell nous propose une extension
+à 700 € pour 2 ans de plus. De plus, Dell propose des offres de
+renouvellement (jusqu'à 75 % de réduction par rapport au site web). Attention
+aux problèmes rencontrés dans le passé avec Dell : adresses, paiement Ã
+l'avance, délais, etc. On n'étend pas la garantie, mais on jette un coup d'œil
+aux offres de renouvellement.
+
+Notre nouveau contact chez Dell : Céline El Bouhali (04 99 75 65 84).
+
+### SVN vs CVS
+
+SVN a déjà été testé dans le passé pour le Crans et posait plus de problèmes
+que CVS (repository fragile, problème de droits, etc.). Pour les fichiers de
+configuration, CVS convient bien et sera conservé. Pour les scripts (en
+particulier les projets orthogonaux tels que l'intranet ou le wifi), un système
+de versionnement distribué pourra être adopté. Il faudra faire une étude de ces
+systèmes (Git/coGITo, Mercurial, etc.). Remarque : TLA est déjà utilisé pour le
+wifi. Brice et Grégoire regardent Git.
+
+### Virtual Hosts pour pages perso
+
+Il s'agit de rendre accessible les pages perso accessibles via des adresses qui
+commencent par autre chose que http://perso.crans.org (par exemple
+http://www.example.com). La gestion des virtual hosts en crans.org risque de
+polluer notre domaine et demande des précautions avec la gestion des conflits
+dans le DNS, tout cela pour un intérêt très faible. En revanche, les virtual
+hosts hors crans.org demandent un effort minime côté crans, et la configuration
+est déjà en place. On autorise donc les virtual hosts pour les noms de domaine
+hors crans.org, au cas par cas.
+
+## CROUS
+
+### Travaux sur les fibres
+
+Aux dernières nouvelles, SCIC Habitat prend en charge la réparation en faisant
+appel à SPIE Communications. Les travaux commenceront lundi.
+
+### Clés
+
+Le CROUS a un exemplaire de toutes nos clés. En cas de réclamation de la part
+du CROUS, il faudra leur expliquer qu'on ne peut pas se permettre de distribuer
+des clés dès qu'ils perdent la leur et que d'ailleurs, le fait qu'ils perdent
+nos clés est inquiétant car l'assurance ne couvrent pas les clés perdues. En
+revanche, on leur laisse accéder à nos locaux quand ils veulent (dès qu'ils
+préviennent suffisamment à l'avance). Le cas de force majeure est une fausse
+excuse car de toute façon, les pompiers accèdent n'importe où sans même se
+soucier d'avoir les clés (cas de porte défoncée au C déjà rencontré).
+
+### Locaux techniques 4I, 4H
+
+Le CROUS va installer des serrures sur des armoires techniques au 4I et 4H afin
+que nous puissions y installer des switchs pour les bornes sur les toits.
+
+### Problèmes électriques au bâtiment I
+
+Le local de brassage est sur le même circuit électrique que les prises du
+couloir et des autres locaux techniques. Il faudra demander au CROUS un circuit
+électrique séparé (s'adresser à Victor) comme ils l'ont fait pour le M et le B.
+
+## Brainstorming
+
+* Refaire les scripts de gestion avec une base postgres : ça va pas forcément
+ résoudre les problèmes, mais ça peut améliorier les performances et ça
+ peut-être plus marrant plutôt que de déboguer des trucs... la vue ldap est
+ lente... on attend, il y a autre chose à faire, mais en attendant, on peut
+ profiler du python pour localiser les goulots d'étranglement
+* Avec les nouveaux serveurs, redondance de services (Heartbeat) (plus utile)
+* Interaction avec FedeRez ?
diff --git a/compte_rendus/2007_03_15.md b/compte_rendus/2007_03_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..943ac2ce288588a78c334c7b97545cede4da4b6f
--- /dev/null
+++ b/compte_rendus/2007_03_15.md
@@ -0,0 +1,42 @@
+# Réunion IN
+
+Réunion inter-nounou du jeudi 15 Mars 2007. La réunion aura lieu vers 19 heures
+au PdJ.
+
+Début : -- WikiSgnb <<DateTime(2007-03-15T18:17:04Z)>>
+Fin : -- WikiSgnb <<DateTime(2007-03-15T20:16:13Z)>>
+
+Présents :
+
+* Alexandre Bos
+* Augustin Parret-Fréaud
+* Étienne Chové
+* Jérémie Dimino
+* Romain Clément
+* Stéphane Glondu
+
+Ordre du jour :
+
+* Répartition des services sur les nouveaux serveurs : pas de nouveau truc,
+ voir CransNostalgie/ChangementServeurs
+* Sauvegardes physiques (sur disque dur externe ou sur DVD) : l'idée est de
+ sauvegarder sur un support non accessible logiciellement en cas de
+ compromission de nos serveurs. Alexandre s'en charge.
+* Formulaire de pré-inscription en ligne, et éventuellement paiement en ligne
+ via intranet.
+
+Bilans (ou pas) :
+
+* Mails invalides : en cours
+* Serveur de secours extérieur : serveur commandé
+* Note Kfet : essai d'une facturation a posteriori du BdE : on donne au BdE la
+ possibilité de créditer les comptes impression, et on les facture tous les X
+ jours (avec éventuellement une compensation)... en cas de problèmes
+ particuliers, on annule le système... il faut l'accord du BdE
+* Compte impression pour les clubs
+* Git : on risque de se retrouver dans la même situation que le développement
+ du wifi : seul Vincent savait se servir de tla, et l'utilisation d'un autre
+ système de versionnement a rebuté les autres. Ou alors, on pourrait tout
+ passer sous git, ainsi, ça forcera tout le monde a passer à git. On attend
+ plus d'informations sur git (un séminaire technique, un tutoriel sur le wiki).
+* Travaux sur les fibres (./)
diff --git a/compte_rendus/2007_03_29.md b/compte_rendus/2007_03_29.md
new file mode 100644
index 0000000000000000000000000000000000000000..989b955fc028925511cd06c7afdcf6541168c8ed
--- /dev/null
+++ b/compte_rendus/2007_03_29.md
@@ -0,0 +1,129 @@
+# Réunion inter-nounous
+
+### Horaires
+
+* Date : Jeudi 29 mars 2007
+* Début : -- WikiSgnb <<DateTime(2007-03-29T17:22:41Z)>>
+* Fin : -- WikiSgnb <<DateTime(2007-03-29T19:16:32Z)>>
+* Lieu : salle Condorcet
+
+### Présents
+
+* Alexandre Bos
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Jérémie Dimino
+* Stéphane Glondu
+
+## Ordre du jour
+
+### Pénurie d'adresses IP wifi
+
+Problème:: On va bientôt arriver à cours d'adresses IP pour les machines wifi
+des adhérents (il en reste 45).
+
+Solutions possibles::
+
+* On a trois /24 inutilisés (138.231.{145,146,147}); on pourrait déplacer le
+ vlan adm (qui n'est de toute façon pas accessible directement depuis
+ l'extérieur) dans une plage privée, et élargir le réseau wifi
+ Ã 138.231.144.0/21 -> beaucoup de reconfiguration (switchs, serveurs).
+ * On peut aussi laisser le vlan adm dans son /24, étendre le réseau wifi
+ à 138.231.144.0/21, tout en continuant de réserver les 256 premières
+ adresses pour le vlan adm -> solution la plus simple à mettre en œuvre et
+ la plus raisonnable
+ * Le réseau wifi est entièrement routé. Vous pouvez
+ prendre 138.231.147.0/24 et ainsi de suite
+* Déplacer les bornes dans un des sous-réseaux inutilisés (les bornes ont-elles
+ vraiment besoin d'être dans le même sous-réseau que les machines wifi ?)
+* Attribuer des IPs dynamiques -> il faudra maintenir des logs des
+ correspondances MAC-IP, pour que, par exemple, les logs de squid soient utiles
+* Mettre les machines wifi dans un sous-réseau privé derrière un NAT
+* Restreindre le nombre de machines wifi pour les membres non actifs, mais de
+ toute façon, il n'y a pas assez d'adresses IP (762) pour chaque adhérent (964)
+
+### Mails de confirmation
+
+Mise en Å“uvre::
+
+* les liens qui ont été cliqués ont été logués par apache, ces logs seront
+ utilisés pour mettre à jour la base LDAP pour ceux pour qui la page de
+ confirmation n'aurait pas fonctionné
+* création d'un service (au sens de generate.py) pour mettre à jour la
+ base -> élimine (façon de parler) les problèmes de locks
+* clarification : le spammage de la nuit dernière est le seul, il avait pour
+ but d'initialiser le processus; à l'avenir, les mails ne seront envoyés que
+ suite à un doute quant à la validité d'une adresse mail
+* pour les détenteurs de comptes crans : on pourrait exploiter le script de
+ détection de comptes inactifs et envoyer le lien de confirmation directement
+ dans le mail de détection d'inactivité -> utiliser mailconf pour confirmer
+ aussi l'utilisation d'un compte crans
+
+Choses à améliorer::
+
+* encoder l'adresse mail dans l'adresse de retour
+* changer l'expéditeur (moi, j'ai rien contre
+ disconnect -- -- WikiSgnb <<DateTime(2007-03-29T19:16:32Z)>>)
+* mettre un message plus explicatif
+
+### Logs
+
+État des lieux:: Parfois, quelqu'un de non-nounou a besoin de pouvoir accéder Ã
+certains logs. Par exemple, le bureau, pour voir l'utilisation des fichiers
+copyrightés, ou un apprenti, pour voir ou tester un script...
+
+Discussion:: on abandonne le groupe logs et on gère les accès par ACL au cas
+par cas. Par contre, il faudrait trouver un moyen de centraliser et suivre
+l'attribution des ACLs, sinon on risque de se retrouver avec un tas de fichiers
+avec des ACLs « fantômes ». Solutions proposées :
+
+* un script et/ou fichier de conf commité dans le CVS qui fixe les ACLs (voir
+ si un tel système n'existe pas déjà )
+* effacer toutes les ACLs régulièrement
+
+### Passage du Père Noël
+
+On a reçu ce matin ce qui a été commandé le 13 mars, sauf 5 kits POE. Tout le
+contenu n'a pas encore été vérifié (en cours).
+
+Impressions à chaud :
+
+* Armoire : très classe
+* Disques durs : mignons tout plein
+* KVM IP : le client est une applet ActiveX. Quelqu'un a-t-il une solution ?
+ * Il ne cause pas VNC ou rdesktop ? pas documenté en tout
+ cas -- WikiSgnb <<DateTime(2007-03-29T22:07:54Z)>>
+* Baptême : le nouveau serveur 8 cÅ“urs a été appelé « fx », approuvé Ã
+ l'unanimité des personnes qui étaient d'accord.
+
+Impressions diverses sur fx :
+
+* le live-CD d'Ubuntu ne détecte que 3,2 Go de RAM (le BIOS en détecte
+ bien 4 Go)
+ * Normal, faut un noyau highmem avec support > 4 Go (sinon, le Go restant
+ est pour le noyau)
+* le centre de contrôle de gnome n'affiche que 6 processeurs (bugreport Ã
+ envoyer)
+* interface iLO 2 qui obsolète le KVM IP (applet Java cette fois-ci)
+ * si c'est de l'IPMI, il y a les outils pour dans Debian
+
+### OVH
+
+Installé :
+
+* VPN/CVS/cfengine
+
+À faire :
+
+* Correction de la base LDAP (quel est le problème ?)
+* Migration du common_etc vers cfengine en cours
+* Postfix
+* DNS
+* Backup sur Pegase
+* Munin/Monit
+* Fallback du VPN sur la connexion de secours
+
+### Reporté à plus tard
+
+* Todolist
+* Cableurs
diff --git a/compte_rendus/2007_04_03.md b/compte_rendus/2007_04_03.md
new file mode 100644
index 0000000000000000000000000000000000000000..cb14ebaf81f7855c17052c9aa4b3f530827858e8
--- /dev/null
+++ b/compte_rendus/2007_04_03.md
@@ -0,0 +1,64 @@
+# Réunion Inter-nounous
+
+### Horaires
+
+* Date : Jeudi 3 mai 2007
+* Début : 19:10
+* Fin : 19:49
+* Lieu : Pavillon des Jardins
+
+### Présents
+
+* Alexandre Bos
+* Augustin Parret-Fréaud
+* Cyril Cohen
+* Jérémie Dimino
+* Stéphane Glondu
+
+## Ordre du jour
+
+### Alexandre
+
+Mails de confirmation:: Pour éviter les problèmes de locks, on va utiliser des
+services (au sens generate.py) pour mettre à jour le champ dans la base.
+Alexandre attend plus d'informations au sujet des services.
+
+CransAdministratif/PreInscription:: Script en PHP5/MySQL en cours de
+réalisation par Alexandre.
+
+### CransNounous/TodoList
+
+Backuppc sur ovh:: Augustin passe la sauvegarde sur cfengine avant de mettre en
+place la sauvegarde d'ovh.
+
+Cfengine:: Augustin propose de regrouper toutes les classes dans un fichier
+cf.class. Cela simplifierait par exemple l'installation de services sur un
+nouveau serveur, etc. Adopté.
+
+Problème de CransWifi sous Linux:: les clients sous Linux ne peuvent pas
+installer les dépendances nécessaires pour CransWifi à partir du portail
+captif. Solutions envisagées:
+1. donner accès au ftp de sila
+1. mirrorer les fichiers dont dépend CransWifi sur ragnarok -> quels
+paquets ? racoon et ipsec-tools
+Idéalement, il faudrait le faire pour toutes les distributions. Mais on ne
+s'occupera que de Debian et Ubuntu. On opte pour la seconde solution -> Cyril
+s'en charge (?)
+
+Prétraitement arpwatch:: Stéphane a expliqué ses idées.
+
+DVD admissibles:: On attend les vidéos de NumENS, et les documents de l'ENS.
+
+### Bonus
+
+Changement du système de versionnement:: Stéphane a présenté darcs. Cyril et
+Augustin ont l'air d'aimer. On laisse mûrir.
+
+## Annonces
+
+* Réunions :
+ * Prochaine réunion inter-nounou : ../Jeudi31Mai2007
+ * Prochaine réunion CA : ../Jeudi10Mai2007
+ * Précédente réunion inter-nounou : ../Jeudi29Mars2007
+ * Précédente réunion CA : ../Jeudi26Avril2007
+ * Liste des CR : ComptesRendusCrans
diff --git a/compte_rendus/2007_05_31.md b/compte_rendus/2007_05_31.md
new file mode 100644
index 0000000000000000000000000000000000000000..c1e33b4dcec16e7f0c7815c19774f03a3ac01456
--- /dev/null
+++ b/compte_rendus/2007_05_31.md
@@ -0,0 +1,60 @@
+# Réunion inter-nounous
+
+### Horaires
+
+* Date : Jeudi 31 juin 2007
+* Début : 19h30
+* Fin : 20h00
+* Lieu : PDJ
+
+### Présents
+
+* Alexandre Bos
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Jérémie Dimino
+* Stéphane Glondu
+
+## Brouillon d'ordre du jour
+
+### Etchisation : état des lieux
+
+Rouge:: reste amavis à réparer... en attente...
+
+Zamok:: pourquoi monit considère-t-il toujours qu'apache2 ne tourne pas ?
+
+Pegase:: Ã faire (demain soir).
+
+Proxy:: pourquoi faire passer les adresses en free.fr par ultra ne semble plus
+fonctionner ?
+
+Autres remarques::
+
+* l'occupation des /var de rouge et zamok a augmenté significativement
+* nscd a tendance à planter sur zamok -> cela explique les problèmes que les
+ utilisateurs non privilégiés rencontrent ; cela pose aussi des problèmes de
+ distribution de mails
+* pour plus du sûreté : faire en sorte qu'un dysfonctionnement de nscd ne
+ pénalise pas (presque) tout le monde
+
+### Pénurie d'adresses wifi
+
+* À faire, pas dans les priorités.
+
+### Porter CransWifi sous Windows Vista
+
+* Il nous faut un Windows Vista...
+
+### Mettre en place une inscription en ligne
+
+* Problablement pas pour la prochaine rentrée.
+
+### Permettre la connexion à la zone ENS uniquement aux normaliens
+
+* Il faudrait demander à la DSI quels sites filtrer.
+
+### Impression sur les comptes clubs
+
+* En cours : chaque club a une liste de responsables impression qui peuvent
+ imprimer sur son compte depuis l'intranet avec leur login. Pour l'instant, le
+ système est opérationnel avec un seul responsable par club.
diff --git a/compte_rendus/2007_10_25.md b/compte_rendus/2007_10_25.md
new file mode 100644
index 0000000000000000000000000000000000000000..99744304a3338d243c37bc362e89e543fc7b351b
--- /dev/null
+++ b/compte_rendus/2007_10_25.md
@@ -0,0 +1,62 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 25 octobre 2007
+* Début : -- WikiSgnb <<DateTime(2007-10-25T19:12:42Z)>>
+* Fin : -- WikiSgnb <<DateTime(2007-10-25T21:24:38Z)>>
+* Lieu : Au 2B
+
+### Présents
+
+* Alexandre Bos (via Skype) (Skype ça pue -- WikiDim)
+* Jérémie Dimino
+* Michel Blockelet
+* Nicolas Dandrimont
+* Pierre Chambart
+* Stéphane Glondu
+* Valérian Reithinger
+
+## Ordre du jour
+
+### Déploiement de bcfg2
+
+Déploiement initial toujours en cours par Jérémie.
+
+### Point sur l'installation de fx
+
+Pour pouvoir faire mumuse avec Xen sur fx, un compte avec tous les droits sudo
+a été créé pour Nicolas. Même si cela lui donne virtuellement les mêmes droits
+qu'une nounou, il n'en est pas une.
+
+À court terme, il faudrait migrer ultra vers le domU secours, renommé titanic
+afin de se débarasser d'ultra. À installer et configurer:
+
+* ldap
+* openvpn
+* squid
+
+Alexandre s'en charge en prenant modèle sur ultra. On fait en sorte de
+minimiser l'utilisation du NFS sur titanic, donc on ne monte que les homes et
+le /var/lib/cvs, et on utilise un checkout pour /usr/scripts.
+
+### Réorganisation de sila
+
+On laisse les 100 derniers jours de logs sur sila, et on met les autres sur
+vert (fait -- WikiSgnb <<DateTime(2007-10-26T04:07:01Z)>>). Pas besoin de
+bidouiller avec les partitions, qui pose toutes sortes de problèmes pratiques.
+
+### Fusion/évolution des quotas
+
+Le quota passe à 600 Mo soft, 700 Mo hard. À part quelques nounous, ce quota
+n'est atteint par personne actuellement. Solution adoptée : les inbox sont
+dans /home/mail/login, et /var/mail est un lien symbolique vers /home/mail.
+
+Fait. -- WikiSgnb <<DateTime(2007-10-26T04:07:01Z)>>
+
+### Système de génération des fiches de déconnexion
+
+Il faudrait un système comparable à mail_invalide, à savoir la génération de la
+page se fait lors de l'exécution d'un script. Intérêt: les dates dans la fiche
+correspondraient aux dates effectives de la déconnexion, et peuvent être donc
+adaptées si la distribution se fait en retard.
diff --git a/compte_rendus/2007_11_08.md b/compte_rendus/2007_11_08.md
new file mode 100644
index 0000000000000000000000000000000000000000..9c8dbdb1a56e21ddb7b8caf785ccdea56fb2c340
--- /dev/null
+++ b/compte_rendus/2007_11_08.md
@@ -0,0 +1,70 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 8 novembre 2007
+* Début : -- WikiSgnb <<DateTime(2007-11-08T19:55:50Z)>>
+* Fin :
+* Lieu : au PdJ
+
+### Présents
+
+* Augustin Parret-Fréaud
+* Brice Dubost
+* Charles Vallantin-Dulac
+* François Bobot
+* Jean-Benoist Léger
+* Jérémie Dimino
+* Nicolas Dandrimont
+* Stéphane Glondu
+
+## Ordre du jour
+
+### Déploiement de bcfg2
+
+Jérémie fait des tests sur des domU de fx. Pour l'instant, on en est au minimum
+commun à tous les serveurs.
+
+### Point sur l'installation de titanic
+
+Alexandre n'est pas là . En attendant, il faudrait rebrancher ultra-adsl...
+
+* Désolé, je révise (enfin je devrais) mon partiel de demain. Il y a
+ essentiellement rien sur titanic. Le réseau est configuré convenablement,
+ j'ai pas encore réussi à faire marcher le tunnel pour ovh. Il va falloir
+ faire un proxy transparent pour le https, Ã moins qu'on veuille faire du nat.
+
+### Système de génération des fiches de déconnexion
+
+Voir point suivant.
+
+### Vlan pour les personnes déconnectées
+
+Le système de déconnexion avec prévention par fiche papier est trop
+contraignant. Il a été suggéré de mettre toutes les personnes déconnectées dans
+un vlan à part, une sorte de portail captif, dans lequel les adhérents pourront
+être notifiés par une page web de leur déconnexion. Ce vlan séparé pourrait
+aussi utilisé à d'autres fins.
+
+Jben se penchera sur le problème après ses partiels.
+
+### Install-party
+
+Projet: on crée un vlan install-party, dans lequel on met un serveur (par
+exemple domU de fx) qui fera serveur tftp (pour faire des installs par le
+réseau), dhcp, routeur (avec éventuellement nat).
+
+Autres supports d'installation: clefs usb à préparer, cdroms à graver. On
+privilégiera le boot par réseau. Attention aux Windows Vista, il faudra
+utiliser l'outil Windows pour le repartitionnement.
+
+### Système de versionnement
+
+On décide à l'unanimité de migrer vers darcs. Stéphane s'occupe de faire un
+tutorial sur le wiki pour le crans. On commence avec le /usr/scripts.
+
+### Migration vers Postgresql
+
+Brainstorming, cf CransNostalgie/MigrationPostgresql
+
+À suivre
diff --git a/compte_rendus/2007_11_22.md b/compte_rendus/2007_11_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..a4108d7ed90b758aa0fa5197c822b0cf5aafa1c9
--- /dev/null
+++ b/compte_rendus/2007_11_22.md
@@ -0,0 +1,76 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 22 novembre 2007
+* Début : -- WikiSgnb <<DateTime(2007-11-22T19:43:30Z)>>
+* Fin : -- WikiSgnb <<DateTime(2007-11-22T21:05:50Z)>>
+* Lieu : au PdJ
+
+### Présents
+
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Étienne Descamps
+* Jean-Benoist Léger
+* Jérémie Dimino
+* Nicolas Dandrimont
+* Romain Clément
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Bilan de l'Install-party
+
+Cf réunion CA.
+
+### Mise à disposition d'un serveur de boot par PXE
+
+Accord de principe pour: on rajoute un champ dans la base, éditable par
+intranet et gest_crans. Ceux qui ont le champ adéquat booteront par le réseau.
+
+Romain s'intéresse au problème et s'occupe de proposer un projet précis.
+
+### Agrafeuse pour le service d'impression
+
+Il y a des problèmes d'agrafage actuellement avec l'imprimante. Il faudrait
+contacter HP...
+
+Augustin regarde avec l'ENS si ces derniers n'auraient pas un contrat de
+maintenance dont on pourrait bénéficier. Romain contacte Anne pour voir où on
+en est avec la garantie.
+
+L'imprimante du 4J ne peut pas agrafer plus de 50 feuilles à la fois, ce qui
+est gênant pour les polycopiés. On pourrait mettre un agrafeuse digne de ce nom
+en libre service (pas pour l'embarquer...) dans la partie publique du 4J. Non,
+car c'est source de trop nombreux ennuis.
+
+### Titanic
+
+Jérémie continue la conf de titanic.
+
+### Bcfg2
+
+Jérémie n'a pas avancé.
+
+### Système de gestion des problèmes
+
+À partir des documents fournis par VIA, et d'idées jetées en vrac. Il faut se
+rapprocher plus de VIA pour étudier leur solution. On en reparle plus tard.
+
+### IRC
+
+Il faudrait faire un peu plus de pub pour l'IRC (en particulier le serveur de
+Rezosup).
+
+### Migration PostgreSQL
+
+Il faut étudier la base de VIA.
+
+### Migration du www/wiki vers un domU
+
+Stéphane propose d'utiliser Ocsigen à la place d'Apache afin de permettre aux
+développeurs (d'Ocsigen) de tester Ocsigen sur un « vrai » site. On veillera Ã
+conserver à côté une configuration fonctionnelle d'Apache afin de parer toute
+éventualité.
diff --git a/compte_rendus/2007_12_06.md b/compte_rendus/2007_12_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..1b079f7b6185675d4d34be76dcae4e9d91a61423
--- /dev/null
+++ b/compte_rendus/2007_12_06.md
@@ -0,0 +1,128 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 6 décembre 2007
+* Début : -- WikiSgnb <<DateTime(2007-12-06T19:46:33Z)>>
+* Fin : -- WikiSgnb <<DateTime(2007-12-06T21:57:00Z)>>
+* Lieu : au PdJ
+
+### Présents
+
+* Elsa Dupraz
+* Jean-Benoist Léger
+* Jérémie Dimino
+* Michel Blockelet
+* Nicolas Dandrimont
+* Pierre Chambart
+* Stéphane Glondu
+
+## Réunion
+
+### Suite des épisodes précédents
+
+Mise à disposition d'un serveur de boot par PXE::
+Romain n'est pas là .
+
+Problèmes avec l'imprimante::
+Il y a vraiment un problème d'agrafage ! Stéphane va essayer de constater le
+problème lui-même, puis recontacte Anne à ce sujet.
+
+### Déploiements
+
+#### Titanic
+
+Selon Jérémie, le web de la connexion de secours devrait marcher théoriquement,
+mais aucun test n'a été réalisé.
+
+#### Darcs
+
+Suivi des modifications::
+
+Jérémie a backporté darcs-monitor qui permet de suivre les modifications de la
+même manière qu'actuellement avec cvs-syncmail.
+
+Stéphane a converti le /usr/scripts à darcs, mais a constaté que darcs monitor
+était vraiment trop lent lorsque le dépôt avait beaucoup de patches, ce qui est
+le cas pour /usr/scripts (> 3000 patches).
+
+À défaut de trouver mieux, on s'orientera vers une solution maison.
+
+Une fois ce système de notification mis en place, Stéphane s'occupe de migrer
+tout ce qu'il y a dans le CVS et de faire la doc sur le wiki.
+
+#### Bcfg2
+
+Jérémie a déjà backporté la version testing (plus de fonctionnalités). Il
+envisage de suivre une version plus récente car il souhaite utiliser des
+fonctionnalités récentes très intéressantes.
+
+Jérémie s'occupe de documenter le système sur wiki.
+
+Déjà fait: Postfix.
+
+Darcs a été adopté pour le versionnement.
+
+#### Gestion des adhérents
+
+Système de gestion des problèmes::
+Tout le monde est convaincu que ce système sera à intégrer à la nouvelle base.
+
+Support technique::
+Il faudrait former une délégation pour rendre visite à VIA à ce sujet.
+
+PostgreSQL::
+Brainstorming à continuer.
+
+#### Gestion des projets
+
+Trac a été mentionné par Jérémie. Il semble fonctionnel et agréable et il est
+programmé en Python. Nicolas va l'installer sur un domU.
+
+#### Site www/wiki
+
+On s'orientera vers une implantation FastCGI de MoinMoin. Le module FastCGI
+d'Ocsigen est en cours de développement, donc quelques mois à attendre...
+
+### Divers
+
+Gestion des secrets::
+Jérémie propose de mettre tout ce qui est "sensible" (secrets,
+etc.) dans /etc/crans et de supprimer totalement la présence de fichiers de
+secrets dans les mêmes répertoires que les dépôts (ceci afin d'éviter de
+commiter des mots de passe accidentellement). Les mots de passe apparaissant
+dans les fichiers de conf que l'on souhaiterait versionnés seraient gérés par
+bcfg2.
+
+IRC::
+Les avis sont partagés. On va mettre en place un serveur IRC privé sur le
+modèle des news dans un domU, en faire la pub, et voir ce qui se passe. Il
+faudrait aussi prévoir un moyen convivial d'y accéder, par exemple avec une
+interface web (exécutée côté client, style JS ou Java), dans le même style que
+l'interface SSH.
+
+News::
+Il faudrait les migrer vers un domU, et fournir une interface comme pour IRC
+ci-dessus.
+
+Aslvid::
+Ce serveur dort depuis plusieurs mois. Le proxy est actuellement un réel goulot
+d'étranglement sur le réseau. La discussion a fait apparaître comme évidente la
+nécessité de le mettre une machine dédiée. Aslvid semble approprié (les
+caractéristiques précises sont cependant à vérifier). À l'occasion, il a été
+rebaptisé ''sable'' (nom issu d'un brainstorming très poussé).
+
+Il faudra vraisemblablement rajouter de la RAM à sable. Stéphane prospecte.
+Pour les disques (physiquement, 2 disques de 72 Go), on fait 30 Go de
+RAID1+LVM (pour système + logs) et le reste pour les spools + swap.
+
+Ragnarok::
+Il faut le mettre à jour. Mathieu a donné quelques indications. On laisse un
+jeune s'en charger. À faire tôt le matin (après avoir dormi). Bien lire et
+suivre le release notes. On se donne rdv dimanche matin à 06:00 AM CEST (il
+faut être opérationnel, cà d après avoir bien dormi) pour faire ça. Il y aura au
+moins Stéphane, Nicolas et Jean-Benoist.
+
+### Attribution de nouveaux droits nounou
+
+Les droits Nounou ont été attribués à Michel, Jean-Benoist et Nicolas.
diff --git a/compte_rendus/2007_12_20.md b/compte_rendus/2007_12_20.md
new file mode 100644
index 0000000000000000000000000000000000000000..ca46c4873cff4b46016dd7ef3f431bbda4ac5f70
--- /dev/null
+++ b/compte_rendus/2007_12_20.md
@@ -0,0 +1,91 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 20 décembre 2007
+* Début : -- WikiSgnb <<DateTime(2007-12-20T19:32:46Z)>>
+* Fin : -- WikiSgnb <<DateTime(2007-12-20T20:57:53Z)>>
+* Lieu : au PdJ
+
+### Présents
+
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Jean-Benoist Léger
+* Jérémie Dimino
+* Michel Blockelet
+* Nicolas Dandrimont
+* Pierre Chambart
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Réunion
+
+### Bilans
+
+Problèmes avec l'imprimante::
+
+Stéphane va essayer de constater le problème et de contacter HP.
+
+Connexion de secours::
+
+Théoriquement, le proxy et les mails fonctionnent sur la connexion de secours.
+On se donne rendez-vous le 6 janvier 2008 à 05:00 (date éventuellement Ã
+modifier) au 2B (si cette connexion de secours n'a pas été sollicitée d'ici
+là ) pour la tester grandeur nature.
+
+Bcfg2::
+
+Jérémie va faire des pages wiki pour expliquer l'architecture CRANS afin que
+d'autres personnes que lui puissent faire quelque chose.
+
+Effectué::
+
+* Mise à jour de ragnarok vers OpenBSD 4.2
+* Migration de komaz sur une nouvelle machine
+* Transformation de l'ancien komaz un mirroir Debian local (nommé mdr)
+
+En cours::
+
+* Migration des confs CRANS vers Darcs
+* Installation de trac
+
+En instance::
+
+* Migration du www/wiki vers un domU (Stéphane)
+* Migration des news
+* Installation d'un serveur IRC
+
+### Déploiements
+
+#### Redondance des services
+
+Routeur::
+
+Augustin va se renseigner, mais pas tout de suite. Il a entendu parler
+de !HeartBeat...
+
+Proxy::
+
+L'interaction avec le proxy transparent n'est pas claire... À méditer.
+
+#### Encodage
+
+On passe tout en UTF-8. On fera le switch le 6 janvier (date éventuellement Ã
+modifier). On restera ensuite à l'affût pendant quelques heures pour réparer
+éventuellement ce qui est cassé (''a priori'', pas grand chose).
+
+Une migration vers UTF-8 a déjà été faite dans le passé. Ça pourrait être
+intéressant que ceux qui étaient là signalent les problèmes qu'ils auraient
+rencontrés.
+
+### Questions diverses
+
+Permanence nounou::
+
+Augustin, Jérémie, Pierre, Nicolas, Stéphane ne seront pas à Paris (au
+moins) du 26 au 31 décembre (CCC). Pendant cette période, Michel restera en
+région parisienne, joignable par téléphone portable en cas de pépin. Ce serait
+bien qu'il y ait aussi quelqu'un d'autre. Stéphane laissera son trousseau de
+clés à la porterie de l'ENS avec une liste de noms de personnes habilitées Ã
+les emprunter.
diff --git a/compte_rendus/2008_02_06.md b/compte_rendus/2008_02_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..39204890f58d14b6eacddabb51d97dee6dd17d53
--- /dev/null
+++ b/compte_rendus/2008_02_06.md
@@ -0,0 +1,112 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Mercredi 6 Février 2008
+* Début : -- WikiSgnb <<DateTime(2008-02-06T18:15:00Z)>>
+* Fin : -- WikiSgnb <<DateTime(2008-02-06T19:53:13Z)>>
+* Lieu : Condorcet
+
+### Présents
+
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* François Bobot
+* Jean-Benoist Léger
+* Jérémie Dimino
+* Michel Blockelet
+* Nicolas Dandrimont
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Réunion
+
+### Bilans
+
+#### BdS
+
+La paire de fibres utilisée par le BdS est défectueuse (après tests).
+Apparemment, une autre paire est libre. Si la seconde paire n'est pas libre, ou
+est défectueuse, la DSI nous propose des VLANs (il nous faut le VLAN par
+défaut, wifi (3) et hotspot (4)). Affaire à suivre (demain)...
+
+Régler aussi le problème de la Kokarde.
+
+En profiter aussi pour tâter le terrain concernant l'emprunt de machines pour
+les 10 ans.
+
+#### OVH
+
+Il faut le réinstaller:
+
+* critique: MX secondaire, DNS secondaire, VPN, SQLgrey
+
+Nicolas a été porté volontaire pour le faire.
+
+#### Connexion de secours
+
+Il faudrait rajouter dans la macro wiki autostatus le cas où le switch
+automatique a été désactivé. Xavier a été porté volontaire pour le faire.
+
+#### Renouvellement de la freebox
+
+Xavier a suggéré de renouveler notre freebox. Les autres présents n'en voient
+pas trop l'intérêt. On en reparle dans quelques années.
+
+#### Serveur IRC
+
+Il est opérationnel. Il reste encore quelques détails à tuner (mettre des
+services, limiter les connexions par IRC et CGI:IRC, ...). On attend un peu
+avant de faire la pub.
+
+#### Switchs
+
+Bâtiment A: deux switchs morts, remplacés avec ceux récupérés du G. HP a été
+contacté pour deux switchs. Un troisième marchotte et fera probablement l'objet
+d'un échange.
+
+Point de détail soulevé par Augustin: quid de la garantie d'intervention sur
+site d'HP ? Selon Stéphane, cette garantie concernait les serveurs, mais
+personne n'est sûr.
+
+Il semblerait que la limitation TFTP ait été corrigée dans une version récente
+du firmware. Jean-Benoist va se pencher de nouveau sur la mise en place du DHCP
+snooping et de la protection ARP.
+
+#### BCfg2
+
+Jérémie a écrit une doc sur le wiki: CransTechnique/Bcfg2. Jérémie coordonne
+les efforts.
+
+#### Migration des news
+
+Opérationnel, n'importe qui peut tester le nouveau serveur (newnews). Dans une
+semaine, si aucun problème ne se manifeste, Michel fera la migration
+définitive. Il regarde les différentes interfaces web que l'on pourrait
+proposer.
+
+#### Divers
+
+En cours::
+
+* Migration des confs CRANS vers Darcs (Stéphane)
+
+En instance::
+
+* Problèmes avec l'imprimante: Michel a été porté volontaire pour s'en occuper
+* Demande d'un devis pour le nouveau sable (Stéphane)
+* Migration du www/wiki vers un domU (Stéphane)
+* Installation de nurpawiki (Stéphane)
+* Migration vers UTF-8
+
+### Remarques diverses
+
+#### Clefs du 4J
+
+Il y a 2 clefs dans la nature. Parmi les présents, personne n'a d'idée de leur
+localisation.
+
+#### Nouveaux droits nounou
+
+Jérémie propose d'accorder les droits nounou à Antoine. Accepté à l'unanimité
+des présents.
diff --git a/compte_rendus/2008_02_21.md b/compte_rendus/2008_02_21.md
new file mode 100644
index 0000000000000000000000000000000000000000..8f10fbb177b74be13aed7318228b69ad7effba7e
--- /dev/null
+++ b/compte_rendus/2008_02_21.md
@@ -0,0 +1,122 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 21 Février 2008
+* Début : -- WikiSgnb <<DateTime(2008-02-21T19:36:54Z)>>
+* Fin : -- WikiSgnb <<DateTime(2008-02-21T21:43:25Z)>>
+* Lieu : Pavillon des Jardins
+
+### Présents
+
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Charles Vallantin-Dulac
+* Jean-Benoist Léger
+* Jérémie Dimino
+* Michel Blockelet
+* Nicolas Dandrimont
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Réunion
+
+### BdS
+
+La connexion du BdS a été coupée à cause d'une boucle au niveau des switchs de
+la DSI qui déconnectait le D'Alembert au niveau du backbone. Le problème est
+qu'actuellement, le réseau au D'Alembert et au Cournot sont mutuellement
+exclusifs. Le réseau du D'Alembert ayant plus d'utilisateurs, il est décidé de
+le privilégier.
+
+### Coopération avec la DSI
+
+Stuart a demandé une réunion pour faire une mise au point sur les différents
+VLANSsdu CRANS et de la DSI. À faire: lui envoyer les VLANs de l'ENS visibles
+au 0B et la liste de nos propres VLANs, et le plan de notre réseau.
+
+### IRC
+
+SolidIRCd ne répond pas à nos attentes. De nombreux vieux bugs non corrigés,
+base de code historique obsolète, il y a mieux actuellement. On va tester avec
+unreal.
+
+### News
+
+Le nouveau serveur semble fonctionner. Le feu est vert pour la migration. Ici,
+migration = rsync du /var/spool/news serveurs arrêtés.
+
+### Switchs
+
+Deux nouveaux switchs sont arrivés. Deux anciens sont partis. Deux autres sont
+en instance.
+
+### Coupures de courant
+
+Il faudrait configurer correctement les serveurs du 0B pour qu'ils s'éteignent
+au moment approprié. Bcfg2 semble approprié. Il faut s'arranger pour vert
+s'éteigne (proprement) en dernier.
+
+### Serveurs
+
+Tous les domUs devront être « documentés » sur la page de leur dom0. Il faut
+mettre à jour le wiki. Antoine s'en charge.
+
+### Wiki/Site web
+
+De nombreuses personnes présentes trouvent le wiki trop bordélique. Le mélange
+sous-arborescence/catégorie nuit à la clarté. Les catégories sont plus souples,
+il est proposé de tout migrer vers une architecture à base de catégories...
+reste à définir les catégories ! On en rediscute la prochaine fois. Tous les
+reponsables wiki seront invités.
+
+### Imprimante
+
+Intervention sur site par HP pour matériel hors garantie: 1435 € TTC.
+Garantie 3 mois. Le problème actuellement est que les incidents ne sont pas
+systématiques, et donc on n'a pas de moyen de reproduire avec certitude et de
+vérifier que la réparation est efficace... Il faut déterminer un protocole de
+test avec des résultats 100 % caractéristiques des problèmes de l'imprimante.
+
+### Remplacement du proxy
+
+* [[attachment:sable.pdf|Premier devis]] pour sable. Il s'agit de la même
+ machine que komaz (Opteron Dual Core 2,2 GHz), avec 2 Go de RAM.
+* [[attachment:sable2.pdf|Deuxième devis]] avec processeur Xeon Quad Core.
+
+### Clefs du 4J
+
+Il y toujours deux clefs perdues. Plusieurs personnes se sont portées
+volontaires pour avoir une clefs du 4J (et les responsabilités qui vont avec).
+Il serait de bon goût de la part de certaines personnes qui ont une clefs du 4J
+et qui ne s'en servent plus de rendre leur clé. (En particulier, BarBichu va
+donner sa clé à Ryo)
+
+### Diversification des VLANs
+
+Jérémie fait remarquer qu'une machine sur le VLAN adm a trop de droits, et
+qu'il pourrait être judicieux de compartimenter certains services dans des
+VLANs séparés. Par exemple, Bcfg2 pourrait être utile même sur des machines qui
+ne sont pas sur le VLAN adm. Premier argument contre la multiplication de
+VLANs: la maintenabilité. Une autre solution serait de migrer les
+services « sûrs » (chiffrés) sur le VLAN normal et d'ainsi limiter le nombre de
+machines sur le VLAN adm. Le point négatif: le NFS. À suivre...
+
+### Bilans divers
+
+Fait::
+
+* Macro autostatus
+* Migration des confs CRANS vers Darcs. Signaler tout oubli.
+
+En cours::
+
+* Bcfg2 (tout le monde)
+* OVH (Nicolas)
+* Jouvence (Elsa)
+
+En instance::
+
+* Migration du www/wiki vers un domU (Stéphane)
+* Installation de nurpawiki (Stéphane)
+* Migration vers UTF-8
diff --git a/compte_rendus/2008_05_08.md b/compte_rendus/2008_05_08.md
new file mode 100644
index 0000000000000000000000000000000000000000..063c655e4dcd01640f2148c4c818e95bbd25a6da
--- /dev/null
+++ b/compte_rendus/2008_05_08.md
@@ -0,0 +1,61 @@
+# Réunion nounous
+
+* Date : Jeudi 8 mai 2008
+* Début : 20:42
+* Fin : 21:42
+* Lieu : Salle de conférences du Pavillon des Jardins
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Jean-Benoist Léger
+* Johan Grande
+* Michel Blockelet
+* Nicolas Dandrimont
+* Pierre Chambart
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Bilans des derniers incidents et de leur gestion
+
+Mise à jour de l'IP d'ovh.crans.org::
+Suite à un changement de machine, l'IP d'ovh a changé (08/02/2008). La mise Ã
+jour a été faite dans les DNS du Crans, mais pas chez le registrar. Cet oubli
+est passé inaperçu pendant trois mois : sur toutes les machines extérieures
+testées, l'IP était à jour. On a donc remis ovh dans les MXs (29/04/2008).
+Stéphane s'est aperçu que l'IP n'était pas à jour sur certains serveurs et a
+retiré ovh des MXs (06/05/2008). De plus, l'ancienne IP a été réaffectée à une
+machine sur laquelle tourne aussi un serveur SMTP qui refusait nos mails. Cela
+a eu comme conséquence la « perte » (mais avec notification à l'expéditeur) des
+mails qui passaient par un serveur chez ovh qui avait toujours l'ancienne IP,
+entre le 29/04 et le 06/05.
+
+TLS sur ovh.crans.org::
+Les certficats SSL manquaient suite à la réinstallation d'ovh, ce qui a eu pour
+conséquence l'échec systématique de la commande STARTTLS, sans conséquence pour
+la délivrance des mails.
+
+Occupation mémoire de la base postgres de sqlgrey::
+Sqlgrey et le processus postgres associé consomment une quantité excessive de
+RAM (> 1 Go). On n'a aucune idée de la raison de ce comportement. Cela fait
+swapper rouge. Nicolas cherche toujours, mais le projet sqlgrey semble mort et
+est écrit en Perl. Il envisage de s'orienter vers une autre solution anti-spam.
+
+### Installation de sable
+
+Ça traîne. Nicolas va essayer de boucler ça ce week-end.
+
+### Imprimante
+
+Ça traîne. Jean-Benoist a été pingué sur l'affaire.
+
+### Sémantique de la sanction bloq
+
+La blackliste squid associée à la sanction bloq semble inutile : cette sanction
+provoque déjà la disparition de la machine du DNS, du DHCP, le bannissement au
+niveau du radius sur les switchs, etc... bref, la machine n'existe plus.
+Stéphane propose de supprimer cette blackliste. Cela nous allègera d'un message
+quotidien de cron sur sila.
diff --git a/compte_rendus/2008_05_26.md b/compte_rendus/2008_05_26.md
new file mode 100644
index 0000000000000000000000000000000000000000..402cf921177ae7840a461edfd329560701980665
--- /dev/null
+++ b/compte_rendus/2008_05_26.md
@@ -0,0 +1,198 @@
+# Réunion Nounous
+
+* Date : Jeudi 26 juin 2008
+* Début : 20h01
+* Fin : 22h18
+* Lieu : 2@B
+
+## Présents
+
+### Physiquement
+
+* Augustin Parret-Fréaud
+* Charles Vallantin-Dulac
+* Jean-Benoist Leger
+* Nicolas Dandrimont
+* Xavier Lagorce
+
+### À distance (gobby)
+
+* Antoine Durand-Gasselin
+* Michel Blockelet
+* Vincent Thomas
+
+## Ordre du jour
+
+### Redistribution des services de Rouge
+
+Rouge est actuellement en train de crouler sous les connexions persistantes de
+certains clients mail, notamment concernant dovecot, il a donc été décidé de
+rééquilibrer les services sur différents serveurs sous-utilisés (p.e. sila) pour
+tenter de le décharger et par conséquent d'améliorer la qualité de service du
+Cr@ns.
+
+#### Services redistribuables
+
+* Bases de données de filtrage (-> Komaz). Augustin s'en occupera après
+ le 18 juillet.
+* Jabber (-> le domU hébergeant le serveur irc avec éventuellement un serveur
+ irc « de secours » sur mdr en cas de panne). Michel s'en occupe.
+* DNS principal sur sila ? On garderait rouge en secondaire... Nicolas s'en
+ occupe.
+
+#### Services à migrer si ça pose toujours problème
+
+* La DB de greylisting... Changer de solution ? Changer de backend (MySQL ?) ?
+* Mettre le SMTP principal sur un autre serveur... ?
+* Mailman ?
+
+Au final, il a été décidé de migrer DNS, base de filtrage et Jabber sur des
+autres serveurs, et de regarder l'état de la charge de rouge après migration.
+Si nécessaire, la migration d'autres services sera alors envisagée dans un
+second temps.
+
+### WiFi en WPA2
+
+Ce point n'a pas été abordé à cause de l'absence de Mathieu Segaud.
+
+### Mise en place d'un VLAN de services gratuits par défaut
+
+Suite aux nouveaux statuts, nous allons mettre en place un service de connexion
+gratuit.
+
+Pour rappel, ce service de connexion permettra seulement l'accès au Web et aux
+ENT. Signature d'une charte après câblage à la Kfet (et inscription des
+machines)...
+Nous sommes en effet tenus de faire signer une charte selon notre convention
+avec la DSI. Il a été décidé de placer ces connexions derrière un NAT. Nous
+devons alors garder, de la même manière que pour le VLAN par défaut, une
+correspondance entre l'IP locale et le nom de la personne (pour
+responsabilisation). Il est donc choisi de placer ces machines sous une IP
+locale fixe.
+
+Des modifications au schéma de la base LDAP sont à prévoir.
+
+On ne permet pas de préinscription, cela pose en effet certains problèmes
+juridiques (connexions entre adhérents non contrôlées et non soumises Ã
+acceptation d'une charte).
+
+Mise en place de ce système :
+
+* Modification du script crans. J.Benoist s'en occupe.
+* Modification/adaptation de gen_confs des switchs pour placer les gens dans ce
+ vlan. Idem.
+* Mise en place d'un DHCP. Trivial car identique au DHCP actuel, ça sera fait
+ en même temps que la modif du script Crans.
+* Mise en place du NAT. Trivial aussi, Nicolas s'en occupe.
+
+Il est décidé de ne fournir l'accès au web uniquement (ENT compris) (i.e. pas
+au réseau des adhérents payant) via les ports 80 et 443.
+
+Ce service se limite à ceci, et nous reconsidérerons le panel des services dans
+l'éventualité d'un accord avec le CROUS.
+
+### Raccordement des appartements de l'ENS
+
+Une réunion a eu lieu avec Stuart !McLellan et Roland Abidos afin de mettre en
+place le raccordement des appartements de fonction de l'ENS. A priori, on
+passerait sur un VLAN dédié au niveau de l'ENS.
+Si une charte est signée, ils pourraient passer par RUBIS selon Stuart. A
+l'exception
+du Pavillon des Jardins et de la porterie, tous les bâtiments sont câblés et
+arrivent
+dans un local de brassage, avec des prises libres sur des
+switches !ProCurve (un Switch
+à rajouter probablement au Cournot). Il faudrait arranger un accès aux logs des
+switches concernés, ou _au mieux_ physique (passablement impossible).
+Problème de la TV par le réseau : le trafic des appartements passera via
+Multiprise_Wifi,
+un D-Link... Il faudrait voir à le (faire) changer par un procurve.
+L'accès ne sera ouvert qu'après la signature de la convention.
+
+### Mise en place du VLAN déconnectés
+
+La mise en place du VLAN déconnecté est retardée à cause de l’impossibilité des
+commutateurs à effectuer une mise sur VLan par serveur Radius, feature promise
+par HP il y a environ deux ans.
+
+Une autre possibilité est de faire la mise en place par script, ce qui pose tout
+de même un problème pour les switchs non manageables du Pavillon des Jardins,
+ainsi
+que pour les trucs un peu sales faits pour régler certains problèmes de prises
+défectueuses...
+Il y aurait donc certains gens non déconnectables automatiquement, problème
+analogue
+aux désactivations de prise... Il y a aussi quelques erreurs dans la
+correspondance
+chambre <-> prise.
+
+Actuellement les déconnectés ont uniquement une page sur squid, et ont toujours
+accès au réseau local. La mise en place de ce VLAN est donc nécessaire pour
+l'efficacité des sanctions... (la sanction bloq est trop brutale).
+
+PdJ : on remplace les switches actuels (25 ports + Dlink "multiprise") par les
+switches 50 ports dormant au 2@B et 0@C. Nous referons un point pour la
+reconnexion
+éventuelle du bâtiment G (il en manquera certainement).
+
+Michel se demande si l'on avait inclus le PDJ dans les services gratuits.
+Il regarde. C'est en effet très flou.
+
+### Logs en tout genre de l'imprimante
+
+Un script a été écrit pour récupérer les logs de l'imprimante (et ainsi avoir
+plus
+de pistes pour comprendre pourquoi elle bourre) rien de plus à dire là -dessus
+pour
+le moment, puisque l'imprimante n'a pas bourré depuis le lancement du script
+(Heisenbug).
+Il est aussi réalisé des logs de toutes les estimations en vue de réestimer
+les coûts de l'impression, qui sont passablement surévalués selon l'audit
+effectué
+récemment.
+
+Il est confirmé par J.Benoist que l'intervention effectuée récemment n'a pas
+de rapport avec les bourrages, et que la garantie de 3 mois ne peut donc pas
+s'appliquer.
+
+### Questions diverses
+
+#### Présence de Nounous sur le campus pendant l'été
+
+Il est rappelé la présence de la page CransVacances... Qui doit être remplie,
+ça ne coûte rien et ça évitera des coups de fil pour rien.
+
+Des mails de rappel seront envoyés aux nounous qui *doivent* s'inscrire. Il sera
+également proposé aux apprentis, câbleurs et imprimeurs de s'inscrire afin de
+mieux
+évaluer la présence des gens sur le campus pendant l'été.
+
+#### Trafic « geek » sur la ML Bureau
+
+Il y a sur la mailing-list bureau du passage de mails de surveillance qui
+devraient
+plutôt aller sur une mailing list telle que disconnect, dans laquelle il
+faudrait
+d'ailleurs faire le ménage. J.Benoist s'en occupe.
+
+#### État du 2@B
+
+Le prochain qui met le 2@B en capharnaüm se fait crever les yeux par J.Benoist
+et couper les mains par Nicolas.
+
+#### Perte ? de messages sur les news
+
+Les vieux messages ont été purement et simplement perdus... Comment se fait-ce ?
+C'est assez bizarre, Ã priori le expire.ctl, fichier de conf du serveur nntp, a
+l'air correct :
+
+---✂--- <<BR>>
+
+crans.*:A:never:never:never <<BR>>
+tac.*:A:90:150:180 <<BR>>
+crans.cvs-checkins:A:30:45:60 <<BR>>
+
+---✂---
+
+En effet, les fora tac.* sont purgés au bout de 180 jours... Mais qu'en est-il
+de crans.* ? De plus amples investigations sont à faire.
diff --git a/compte_rendus/2008_09_25.md b/compte_rendus/2008_09_25.md
new file mode 100644
index 0000000000000000000000000000000000000000..3964729fdc8c0ed85025807a5d0d2fcf29fc42a3
--- /dev/null
+++ b/compte_rendus/2008_09_25.md
@@ -0,0 +1,232 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 25 septembre 2008
+* Début : <<DateTime(2008-09-25T17:41:00Z)>>
+* Fin : <<DateTime(2008-09-25T21:27:40Z)>> (on a mangé entre temps...)
+* Lieu : Pavillon des Jardins
+
+### Présents
+
+* Antoine Durand-Gasselin (adg)
+* Anne Cazalet (Anne Cazalet)
+* Augustin Parret-Fréaud (apf)
+* Benoit Barbot
+* Jérémie Dimino (dim)
+* Johan Grande (jojo)
+* Laurent Taylor (marn)
+* Mathieu Segaud (Regala)
+* Michel Blockelet (!AlphaTigrou)
+* Nicolas Dandrimont (olasd)
+* Pierre Chambart (Chicco)
+* Stéphane Glondu (sgnb)
+* Thomas Blanc (pat)
+* Vincent Maioli (Neseb)
+* Xavier Lagorce (lxir)
+
+## Ordre du jour
+
+### Point(s) Matériel
+
+#### Remplacement de rouge
+
+On a constaté de nombreux plantages de rouge. Or rouge étant toujours sous
+garantie, il serait bon de contacter le sav (rapidement, car celle-ci expire
+bientôt).
+
+SAV HP : 0826 10 49 49
+
+Penser à envoyer le numéro de série à Anne.
+
+#### Remplacements de pegase, de vert
+
+Les serveurs de données et de sauvegarde se font vieux, il faudrait penser
+Ã les renouveler.
+
+Pour le remplacement de vert, on a considéré l'investissement dans un SAN/NAS/?,
+qui pourrait servir, en plus du stockage des données des adhérents, de stocker
+les données concernant les racines des domUs actuels et futurs.
+
+On partirait a priori sur une solution avec une baie de disques extensible en
+fonction des besoins. La question porte alors sur le mode de raccordement des
+serveurs :
+
+* [[http://en.wikipedia.org/wiki/Fibre_Channel|Fibre Channel]] :
+ protocole spécifique séparé (performant, bien overkill et
+ nécessite d'ouvrir les serveurs pour rajouter des cartes spécifiques)
+* export NFS (pollue la bande passante, mais vu que les serveurs sont
+ branchés sur le backbone en gigabit, ce n'est pas limitant)
+
+Disques SAS (Serial Attached SCSI). Baie de disques.
+
+Pour le remplacement de pegase, un serveur "pas cher" avec 1 To de stockage
+efficace (en raid5).
+
+* ML110 (Xeon 3065, 570€) + 3 * 500 Go (à 200€ chacun).
+
+#### Remplacement de l'onduleur du 0B
+
+2 onduleurs de 3kVA ou un seul onduleur de 5kVA, nécessitant une installation
+électrique particulière, donc accord du CROUS etc.
+
+### WPA2
+
+Connexion actuelle : équivalent des VPN professionnels. Les bornes ne font que
+transmettre le flux chiffré depuis et à ragnarok.
+
+Intérêt : pouvoir utiliser le wifi avec *tous* les terminaux classiques (PC
+sous Vista --osef, PDA, Smartphones, etc.).
+
+Connexion WPA : chiffrement sur la borne, et surtout toutes les connexions
+seront en clair sur les vlan 3 et 4, cela pose certains problèmes de sécurité.
+Sécurité "dans les airs", mais ce n'est pas chiffré sur le fil (entre la borne
+et ragnarok) (chiffrer sur le fil et dans les airs, c'est trop pour les bornes).
+Il sera toujours possible d'effectuer du chiffrement IPSEC au dessus du WPA.
+
+Multi-SSID : il faut changer les bornes existant à l'ENS.
+
+todo:
+
+* Migrer les bornes actuelles sous Kamikaze 8
+* Faire des tests sur un réseau séparé
+* login/mdp: nom de machine/clef (ex-)ipsec
+ * on ne fait plus (forcément) d'ipsec
+* Faire des tests de performance, trop de gens connectés en WPA, ça peut être
+ très lourd. (2Mo/s max pour chaque borne)
+
+### Point sur la mise en place de la connexion gratuite
+
+* Elle est sur le VLAN 6.
+* IP privées 10.42.0.0/16 non routées, attribuées aléatoirement (log DHCP
+ gardés).
+* Sable est le seul serveur sur ce VLAN, c'est lui qui fournit tous
+
+les "services" : le proxy en 80 (port HTTP) et 443 (port HTTPS) (pas pour
+l'instant, Ã faire **vite**)
+
+* Limitation à 1Mo/s pour l'ensemble des inscrits.
+* Il faut qu'il y ait des gens qui s'inscrivent afin d'avoir un minimum de
+ crédibilité.
+
+Le vlan 7, d'accueil, récupère toutes les machines qui ne sont pas enregistrées
+dans la base (ou qui se branchent quand Radius chie......). Il faudrait ajouter
+à la page proxy un commentaire : "si vous êtes déjà inscrit, débranchez et
+rebranchez votre cable".
+
+Il faut faire une page wiki récapitulant les points techniques à ce propos.
+
+### Retour de sila
+
+Il est de retour, avec plein de disques...
+
+On a remonté un FTP avec pour l'instant :
+
+* une archive debian complète (un jour, on prendra la place du miroir de
+ l'ENS...)
+* l'archive openbsd que l'on avait précédemment
+* un miroir de VLC
+
+Il faut mettre de la QoS sur le FTP pour éviter de péter le réseau de l'ENS lors
+des mises à jour de VLC...
+
+### Changement des disques durs de la ferme
+
+Cet été, il a fait chaud (encore une fois). Les disques de la ferme sont
+fatigués,
+il faut les changer. Ils sont au 2@B en attendant que Michel s'en occupe
+(avec n apprentis, n > 1, si on rajoute un "e" ça ira plus vite elle connait
+déjà la Ferme avec Michel..., exact).
+
+Mouton est mort, on va le mettre sur orbite. De toute façon il ne servait qu'aux
+annonces SAP, qui sont supportées maintenant nativement par MumuDVB, et donc
+nous n'avons plus besoin de minisapserver. Il faut déplacer la génération des
+vignettes sur MDR, le serveur qui réchauffe inutilement le 4@J actuellement.
+
+### Passage des serveurs/domUs à Lenny
+
+À priori, on peut effectuer la transition pour les paquets n'ayant pas de bugs
+RC (on va pas beaucoup avancer avec ça...)
+
+Les serveurs actuellement sous lenny :
+
+* sila
+* munin
+* o2
+* xmpp
+
+Il n'y en a plus qu'une vingtaine à migrer ! On va commencer par la ferme, qui
+ne contient pas de service critique... MumuDVB n'est de toute façon pas un
+paquet
+Debian. Il faudra penser à demander à Braice de vérifier si les noyaux lenny
+sont
+bons.
+
+Il faudra veiller à réécrire les fichiers de confs des logiciels qui changeront
+de version majeure. Les mettre dans BCfg2 aussi tant qu'Ã faire.
+(exemples : Radius, ...)
+
+Ça parait être une occasion en or pour finaliser la migration en utf-8.
+il ne faut la faire qu'une fois...
+http://munin.crans.org/association.crans.org/web.rouge-wiki_themes.html *ahaha*.
+
+Une page wiki devra être mise en place pour recenser les tests de mises à jour
+effectués.
+
+### Organisation des séminaires techniques
+
+Les séminaires seront organisés tous les mercredis soir à 20h, en salle
+Condorcet.
+
+Le premier (le 1er octobre) sera consacré à une présentation technique globale
+du réseau.
+
+Le séminaire TCP/IP du 8 octobre sera effectué par pat (non, l'autre).
+
+Le 15 et le 22 octobre seront organisés des séminaires de présentation du
+système GNU/Linux, préliminaire à l'install-party du 8 Novembre.
+
+Thèmes importants à traiter : switches, LDAP, BCfg2, Apache et les trucs HTTP,
+OpenBSD et PF, WiFi (Regala), Asterisk et le SIP (Re-Regala), XMPP, ...
+
+### Questions diverses
+
+#### Jabber connecté à LDAP
+
+Un nouveau serveur Jabber a été créé, xmpp.crans.org. Les comptes sur ce serveur
+sont en fait les comptes crans. Pour l'instant, tous les alias fonctionnent mais
+pointent sur des comptes (listes de contact) différents. Il faudrait faire en
+sorte que tous les alias pointent vers le même roster. Malheureusement, il n'y a
+pas de méthode standard pour ce faire, des investigations sont en cours.
+
+Il y a des raisons pour avoir des comptes différents... C'est donc peut-être pas
+la peine de fusionner les alias. À voir.
+
+#### Problème de la transparence avec l'imprimante
+
+L'imprimante imprime parfois les zones transparentes avec un aplat de
+couleur (correspondant à la "couleur de transparence" du fichier), plutôt que
+du blanc.
+
+À moins de flasher l'imprimante, après avoir modifié les sources du
+firmware (que nous n'avons pas) nous ne voyons pas ce que nous pouvons faire...
+
+#### Connexion des appartements de l'ENS
+
+On va faire passer cette connexion par un vlan particulier, qui nous permettra
+de filtrer le contenu qui passerait du réseau Campus au réseau Appartements.
+
+#### Blocage de bittorrent
+
+Des abus récents nous poussent à bloquer totalement le trafic bittorrent passant
+par komaz.
+
+#### Commande de LiveCD GNU/Linux
+
+http://shipit.ubuntu.com/ ne fait que des envois personnels. Il faudrait
+rapidement faire une commande de liveCD chez Ikarios, parce que c'est pas cher.
+Commande de:
+
+* 50 LiveCD kikoololbuntu i686
+* 50 LiveCD kikoololbuntu amd64
+* 20 Netinstall debian
diff --git a/compte_rendus/2008_10_09.md b/compte_rendus/2008_10_09.md
new file mode 100644
index 0000000000000000000000000000000000000000..a200fbdfbe0789e2286b7ff3d0f3f836fc56e953
--- /dev/null
+++ b/compte_rendus/2008_10_09.md
@@ -0,0 +1,124 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Jeudi 9 Octobre 2008
+* Début : 20h12
+* Fin : -- WikiNicolasd <<DateTime(2008-10-09T20:12:30Z)>>
+* Lieu : Pavillon des Jardins
+
+### Présents
+
+* Antoine Durand-Gasselin
+* Benoît Barbot
+* Jérémie Dimino
+* Johan Grande
+* `man 1 sort`
+* Michel Blockelet
+* Nicolas Dandrimont
+* Xavier Lagorce
+
+## Ordre du jour
+
+RAPPEL:: Les données d'accès au proxy sont des données *personnelles* des
+adhérents (logs de squid), et les Nounous n'ont à y accéder en aucun cas. Cela
+paraissait une évidence pour tout le monde, mais ça ne coûte rien de le
+rappeler.
+
+### Pédalages de rouge dans la semoule
+
+Ce week-end, il y a eu pas mal de problèmes au niveau du www/wiki, et lundi, par
+miracle, tout s'est remis à fonctionner... Redémarrer Apache les refaisait
+fonctionner, mais que pendant une vingtaine de minutes.
+
+Appeler HP pour le SAV n'est possible que si l'on arrive à diagnostiquer un
+problème précis et reproductible, ce qui n'est pas le cas actuellement.
+
+### Migration du www/wiki vers Lenny
+
+Afin de régler ce problème, Antoine a commencé à regarder comment migrer le wiki
+vers un serveur sous lenny. Ce ne sera pas tâche aisée vu que c'est le paquet
+avec le plus de modifications locales pour le Cr@ns.
+
+Howto:
+
+* Installer apache2, apacheSSL, pythonmodrewrite (et allumer son cerveau)
+* sync-er le /var/local/wiki
+ * il y a un lv sur fx qui s'appelle lvm-wiki (2,5/4Go)
+* copier les fichiers de conf de moinmoin (/etc/moin/*) (réfléchir un peu)
+* mà j les scripts dans /usr/scripts/wiki-lenny
+ * comprendre comment fonctionne le parser de moinmoin (un peu comme à chaque
+
+mà j)
+
+Moinmoin et le serveur apache sont configurés sur http://moise-wiki.crans.org
+le temps qu'on fasse quelques bidouilles sur les plugins munin du crans (parce
+que le serveur a apache et est sous lenny).
+
+### Connexion des appartements de l'ENS
+
+Il a été décidé de placer ces appartements sur le même VLAN que le BdS (car ce
+VLAN circule déjà sur les équipements actifs de l'ENS). Il faudra mettre en
+place un firewall entre ce VLAN et le réseau (car le CA a décidé de filtrer le
+trafic). Ce réseau passera par la Freebox.
+
+### Problèmes latents sur le réseau
+
+#### Wifi
+
+Le Wifi marche de façon plus ou moins aléatoire. Il faudrait rebooter la plupart
+des bornes (cf. autostatus bien rouge). Les bornes en zone CROUS devraient être
+rebootables par un apprenti qui n'aura pas le choix. Il parait judicieux, au vu
+de certains soucis de configuration de switchs, de vérifier sur quels vlans sont
+la prise de chaque borne down et de modifier la base ldap le cas échéant.
+Certaines bornes ne semblent pas revenir après un hard reboot; le stock de
+bornes du -1I étant fortement diminué, il faudrait voir avec Régala pour l'achat
+de nouvelles bornes.
+
+#### Zamok et libnss-ldap
+
+On suspecte que libnss-ldap faisait trop de requêtes sur vert, dépassant le
+nombre maximal de sockets sur vert.
+Libnss-ldapd résout ces problèmes par une séparation claire entre le code de la
+bibliothèque nss et la connexion au serveur ldap. Le nombre de sockets ouvertes
+est alors maitrisé, puisque la connexion se fait via un démon (nslcd), qui en
+outre garde un cache des données lors d'une défaillance du serveur LDAP.
+
+C'est pour l'instant la solution utilisée sur zamok (et quelques serveurs sous
+lenny), et pour l'instant aucun problème n'a été constaté.
+
+On va certainement passer rouge à cette solution, même si maintenant la charge
+sur le serveur LDAP de vert doit avoir fortement diminué.
+
+#### Bizarreries de l'authentification radius
+
+Il est constaté un nombre impressionnant de machines qui passent par erreur sur
+le vlan d'accueil. Le problème ne vient apparemment pas de radius, les logs sont
+OK. Il faudrait refaire de toute façon la redondance de radius et voir, si ça ne
+résout pas le problème, à ajouter une rustine par exemple à arpwatch pour
+désactiver/réactiver la prise si l'adhérent se retrouve par erreur sur le
+vlan 7.
+
+### Questions diverses
+
+#### Mise en place et tests du Wifi en WPA2
+
+Pour réaliser les tests de WPA2, Régala va utiliser le VLAN 30, libre sur le
+réseau Cr@ns et le réseau ENS. En effet, on ne peut pas passer le firewall de
+ragnarok en clair sur le vlan 3 actuellement.
+
+Il faut prévenir la DSI de l'utilisation de ce VLAN.
+
+#### Problèmes avec les annonces SAP
+
+Ça m'a l'air de ne pas fonctionner correctement. Braice ?
+
+#### Limitation de bande passante sur le FTP
+
+Jérémie n'a pas regardé depuis la dernière release de VLC, le réseau de l'ENS va
+bien avec les limitations actuelles par nombre d'utilisateurs connectés.
+
+#### Migration à l'UTF-8
+
+Il faut le faire, en évitant de migrer les services en APF-4242.
+La migration naturelle lennyesque continue.
diff --git a/compte_rendus/2008_10_22.md b/compte_rendus/2008_10_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..58bfa8a84821790ea47fe986ba4878e5d44eca7a
--- /dev/null
+++ b/compte_rendus/2008_10_22.md
@@ -0,0 +1,103 @@
+# Réunion Nounous
+
+### Horaires
+
+* Date : Mercredi 22 octobre 2008
+* Début : 19h54
+* Fin : -- WikiNicolasd <<DateTime(2008-10-22T19:08:28Z)>>
+* Lieu : Salle Condorcet
+
+### Présents
+
+* Antoine Durand-Gasselin
+* Arnaud Deblonde
+* Benoît Barbot
+* Jérémie Dimino
+* Laurent Taylor
+* Michel Blockelet
+* Nicolas Bruot
+* Nicolas Dandrimont
+* Olivier Huber
+* Pierre Chambart
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Passage progressif des serveurs à Lenny, et à l'UTF8
+
+BOFH excuse #212:
+Of course it doesn't work. We've performed a software
+upgrade. -- WikiNicolasd <<DateTime(2008-10-21T12:41:49Z)>>
+
+Indice : installer les devscripts des backports, utiliser rc-alert. Dans l'état
+actuel, on pourrait mettre à jour zamok. On peut aussi tout simplement copier
+le script qui nous intéresse. Il fonctionne sous etch.
+
+### Migration du wiki
+
+Deux choses sont à faire :
+
+* refaire la conf du Cr@ns spécifique (droits spéciaux…)
+* refaire les macros qui ne passent pas à la version (aux deux versions en
+ fait). Il y en a *beaucoup*.
+
+Certaines syntaxes changent (par exemple, les macros passent sous
+forme {{{<<Macro>>}}} au lieu de {{{[[Macro]]}}}). Un wiki de test est en place
+sur munin.crans.org. Pour la migration définitive, on créera un domU (quand la
+nouvelle infrastructure sera mise en place).
+
+### Compte rendu de l'intervention de l'électricien pour le 0@B
+
+C'est demain.
+
+### Wifi en WPA2 ?
+
+Le log irc arrivera dans la soirée...
+
+### WebRadio (Upload, multicast, branchement de la KoKarde…)
+
+L'accès serait possible par login/mot de passe (comme les news). Le problème
+est que l'audio, c'est *gros* (genre 1 Mo/minute). Il paraitrait étonnant que
+la DSI accepte ce type d'upload. Comment font-ils chez VIA ?
+
+La KoKarde sera câblée sur le vlan BdS/Appartements. Michel s'en occupe.
+
+### Formulaire de précâblage en ligne
+
+Ne pas oublier de réfléchir lorsqu'on configure apache.
+On devrait partir sur un truc en !CherryPy, un peu comme l'intranet. Xavier se
+porte volontaire.
+
+Il ajoute d'ailleurs qu'en passant, il serait une bonne idée d'ajouter la case
+Ã cocher pour passer une prise sur le vlan install party. Il faudrait que les
+switchs soient configurés en conséquence, et que les
+images du vlan install party soient tenues à jour plus régulièrement que "quand
+on en a besoin".
+
+### Questions diverses
+
+#### Venus
+
+La carte réseau chie dans la compote de pomme. Il faut la changer (la carte
+réseau ou la câbleuse).
+
+#### Réécriture des pages d'aide
+
+* ''Globalement, rassembler toutes les pages d'aide aux adhérents à un endroit,
+ kikoololiser l'autostatus, proposer un système de bug-report, etc. C'est
+ juste une piqûre de rappel.''
+ * Bonjour Michel -- WikiNicolasd <<DateTime(2008-10-21T16:39:54Z)>>
+
+Les pages actuelles reflètent un peu le Cr@ns de 2005-2006... Sila est le
+proxy, zamok fournit tous les services, la base ldap est sur zamok etc.
+
+Il faut mettre à jour et réorganiser les pages des arborescences :
+
+* VieCrans/
+* CransTechnique/
+* CransAdministratif/
+
+#### Câblage du personnel de l'ENS
+
+Rien n'a changé depuis 15 jours. Michel a été porté volontaire.
diff --git a/compte_rendus/2008_11_20.md b/compte_rendus/2008_11_20.md
new file mode 100644
index 0000000000000000000000000000000000000000..af627d242bc37470d0a912c8b784b4840ebcb108
--- /dev/null
+++ b/compte_rendus/2008_11_20.md
@@ -0,0 +1,141 @@
+# Réunion Nounous
+
+## Lieu et horaires
+
+* Lieu : Pavillon des Jardins
+* Date : Jeudi 20 novembre 2008
+* Début : 19h51
+* Fin : 21h23
+
+## Présents
+
+* Augustin Parret-Fréaud
+* Johan Grande
+* Laurent Taylor
+* Michel Blockelet
+* Nicolas Bruot
+* Nicolas Dandrimont
+* Olivier Huber
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Avancement de la mise à jour vers lenny
+
+La mise à jour vers lenny a commencé (par oie) sur les serveurs de la ferme.
+Oie ne boote pas sur le kernel officiel, selon toute évidence à cause des
+options un peu foireuses qui permettent déjà que les cartes TV fonctionnent
+
+Nicolas prévoit de bientôt mettre à jour egon, afin de tester la mise à jour de
+certains services comme LDAP, Postfix, PostgreSQL...
+
+### Planification du remplacement de vert et de pegase
+
+De nouveaux serveurs ont été commandés (on les recevra d'ici une dizaine de
+jours).
+
+Il y a ainsi :
+
+* fy : un nouveau dom0 (pour délester fx)
+* un nouveau "vert"
+
+Et pour aller avec :
+
+* une baie de disques iSCSI, avec deux buts principaux :
+ * en cas de panne de certains serveurs, permettre à d'autres de toujours
+
+accéder aux données
+
+* éviter de gâcher de l'espace disque
+* un nouvel onduleur
+
+On cherche une solution pour économiser sur l'installation électrique pour le
+branchement de l'onduleur, la solution proposée par Anne nous semblant vraiment
+très onéreuse.
+
+Liste des services et données à migrer :
+
+* Sur Pegase :
+ * Backups de pegase... Il faut donc réinstaller backuppc.
+ * Serveur RADIUS (attention à la mise à jour, la sémantique du fichier de
+ conf change)
+ * LDAP (en relation avec le point précédent)
+* Sur vert :
+ * Le serveur NFS...
+ * La base LDAP principale...
+ * BCfg2
+ * Le serveur DNS (slave de toutes les zones)
+* Sur le nouveau Dom0 :
+ * un DomU www
+ * ...
+
+### Avancement de la migration du wiki
+
+Il faut faire une double migration (passage à la v1.7 de MoinMoin, de Lenny, et
+passer à un DomU), ce qui augmente un peu la charge de travail.
+
+Le calendrier ne fonctionne pas, MoinMoin semble détecter correctement les pages
+à afficher mais n'arrive pas à récupérer les informations dans ces dites pages.
+
+Les catégories des pages ont aussi des problèmes de fonctionnement (plus ou
+moins aléatoires).
+
+Antoine suggère que la migration est une bonne occasion pour faire un peu de
+ménage sur le wiki.
+
+(Pourquoi est-ce qu'il ne faut pas faire indexer le wiki par google :
+VieEns/LesDépartements/DépartementAnglaises…)
+
+Le séminaire technique sur le wiki sera dans 3 semaines.
+
+### Avancement de la mise en place du WiFi en WPA2
+
+Il est probable que Regala soit en train de flasher une borne au 2B en ce moment
+même... Apparemment non.
+
+### « Formalisation » des droits WebMaster et FtpMaster
+
+Il serait bon de mettre en place une procédure "automatique" (i.e. LDAPisée)
+d'attribution de ces droits.
+
+### Attribution de nouveaux droits
+
+Johan est ajouté au groupe mirror sur sila, pour pouvoir gérer les dizaines
+d'isos de distributions disponibles sur le FTP.
+
+Nicolas propose d'ajouter les droits Nounou à Xavier, puisqu'il a montré un an
+durant son intérêt et sa motivation. Aucune des nounous présentes (et contactées
+précédemment) n'oppose son veto.
+
+### Organisation de nouveaux séminaires techniques
+
+Un séminaire sur MoinMoin sera organisé par Antoine dans 3 semaines.
+
+Inscrivez vos disponibilités sur la
+page [[CransTechnique/CransApprentis/SeminairesTechniques|SéminairesTechniques]], pour que votre avis
+compte si on les déplace... Il faudra pas venir se plaindre après.
+
+### Questions diverses
+
+#### Migration de mouton vers MDR
+
+En principe, Michel a migré tous les services qu'il faut. Il attend la
+vérification de Braice.
+
+Très bientôt, on aura enfin le silence au 4J...
+
+#### Router advertisements IPv6
+
+Olivier cherche une solution pour éviter que chaque machine qui se branche sur
+le réseau récupère 5 adresses IPv6 globales. Cela résoudrait -peut-être- les
+problèmes de connexion filaire sous Vista.
+
+#### Machines extérieures en .crans.org
+
+Des gens ont demandé la possibilité d'avoir des machines extérieures
+en .crans.org . Il faudrait mettre en place :
+
+* Soit une zone spéciale (.vieux-con.crans.org ?)
+* Soit un domaine spécial (crans.eu ?)
+
+Le domaine crans.eu est commandé chez ovh.
diff --git a/compte_rendus/2009_01_15.md b/compte_rendus/2009_01_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..4d218ce8f454f4688891072d023c55682099837e
--- /dev/null
+++ b/compte_rendus/2009_01_15.md
@@ -0,0 +1,123 @@
+# Réunion Nounous
+
+* Date : Jeudi 15 janvier 2009
+* Lieu : Pavillon des Jardins
+* Début : 19h45
+* Fin : 21h00
+
+## Présents
+
+* Antoîne Durand-Gasselin
+* Johan Grande
+* Nicolas Dandrimont
+* Stéphane Glondu
+* Xavier Lagorce
+* Vincent Maioli
+
+## Ordre du jour
+
+### Câblage des appartements de l'ENS
+
+La solution technique retenue est de placer les Appartements derrière un NAT,
+sur komaz.
+
+Le filtrage peer2peer sera en place sur ce nat. Pour le comptage de l'upload,
+il faut trouver une solution qui prend en compte le NAT.
+
+Pour ce qui est de la charte à faire signer à ces nouveaux connectés, la
+discussion est reportée au prochain CA.
+
+### Automatisation de la mise en place des sauvegardes
+
+La mise en place automatique est lourde à mettre en place, alors que
+l'opération pour un serveur consiste en la copie d'un fichier sur babar. Il
+suffit donc de ne pas oublier cette étape.
+
+### « ToDo list » en cas de panne
+
+Il parait difficile de faire une checklist des choses à vérifier en cas de
+panne, le nombre de serveurs et de services étant faramineux.
+
+Il sera mis en place une page wiki contenant différents tutoriels, par exemple
+comment redémarrer le 0B en cas de panne, etc. Il faudra veiller à ce que les
+informations contenues dans cette page soient à jour en permanence.
+
+Si les membres du CA sont prêts à mettre en place une liste de choses à faire
+en cas d'absence des Nounous, les Nounous sont prêtes à les aider, mais ne
+voient pas l'intérêt de la mettre en place en l'état actuel des choses.
+
+### Bilan de l'installation des nouveaux serveurs
+
+#### Slon
+
+La nouvelle baie de disques est installée. Les données des !DomUs sont dessus.
+Il reste à déplacer les homes. Pour servir ces derniers, des tests vont être
+effectués sur un DomU.
+
+#### Fy
+
+Fy est installé, il va chercher sa racine sur la baie de disques. Tous
+les !DomUs sont dessus actuellement en attendant de réinstaller Fx.
+
+#### Babar
+
+Il est installé et fonctionnel. Il reste à le déplacer à son emplacement
+physique définitif.
+
+Petit commentaire sur l'installation : Ne mettre qu'une partition / de 2 Go sur
+un disque de 250 était surprenant, considérant que les métadonnées de backuppc
+sont stockées dans un arbre de millions de petits fichiers dans /var. Que ne
+fut ma surprise quand j'ai constaté que la racine était pleine depuis plus
+d'une semaine...
+
+### Récupération du crash de fx
+
+Aucun test n'a été effectué depuis le crash. Les disques durs doivent être
+vérifiés (smart test etc.), en vue d'un échange en cas de problème.
+
+Le DomU irc est toujours cassé, il faut le réinstaller.
+
+### Avancement des mises à jour vers lenny
+
+Tous les serveurs non critiques ont été migrés sous lenny. Pour les serveurs
+principaux restant, l'ordre retenu de migration est le suivant :
+
+* komaz
+* sable
+* rouge
+* zamok
+
+Ce qui advient de vert sera déterminé plus tard (selon les tests du NFS sur un
+domU).
+
+### Projets en cours ou futurs
+
+#### BCfg2
+
+Petit à petit, le mail de statistiques BCfg2 se vide...
+
+#### Formulaire de préinscription en ligne
+
+Xavier commence à s'y mettre.
+
+#### Détection des router-advertisements
+
+Olivier fait semblant de réviser, le point est reporté à la prochaine réunion.
+
+#### Bugs de l'intranet
+
+* L'intranet perd la "connexion à l'imprimante" et n'arrive pas à la rétablir
+* Les paiements paypal doivent être validés manuellement
+
+Il faudrait que quelqu'un avec des points de karma en cherrypy y regarde de
+plus près.
+
+#### munin
+
+Le domU munin a un gros souci d'i/o. Le service sera transféré sur pegase
+lorsque la migration des sauvegardes sera complète.
+
+#### Modifications qui trainent
+
+Il est rappelé que les modifications aux différents dépôts doivent être
+commitées rapidement...
diff --git a/compte_rendus/2009_01_29.md b/compte_rendus/2009_01_29.md
new file mode 100644
index 0000000000000000000000000000000000000000..9621f69713aed8a505970bd7fa5b15d27ea0e22a
--- /dev/null
+++ b/compte_rendus/2009_01_29.md
@@ -0,0 +1,217 @@
+# 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/|http://www.amazon.fr/Braice-Ã -la-ferme-tome4]]).
+
+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
diff --git a/compte_rendus/2009_03_05.md b/compte_rendus/2009_03_05.md
new file mode 100644
index 0000000000000000000000000000000000000000..13425ad97817253e3cccec30e79788948453070b
--- /dev/null
+++ b/compte_rendus/2009_03_05.md
@@ -0,0 +1,249 @@
+# 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.
diff --git a/compte_rendus/2009_04_06.md b/compte_rendus/2009_04_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..0c732b47020ff7b79b7dcffc454c140328d563a1
--- /dev/null
+++ b/compte_rendus/2009_04_06.md
@@ -0,0 +1,183 @@
+# Réunion Nounous
+
+* Date : Lundi 6 avril 2009
+* Lieu : Pavillon des Jardins
+* Début : 19h30
+* Fin : 21h57
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Benoît Barbot
+* Jérémie Dimino
+* Olivier Huber
+* Stéphane Glondu
+* Stéphane Murday
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Migration sous Lenny
+
+Il reste sable, zamok, rouge et vert.
+
+Sable : adg s'occupe de squid.
+Adg veut tester squid 3 sur egon (pour la mise en cache des vidéos).
+
+On migre dans un premier temps vert sous Lenny, puis les homes vers slon, et
+enfin zamok vers Lenny.
+
+### Rouge
+
+On ne migrera pas rouge en tant que tel, on va séparer les différents services.
+Olivier a configuré rouge (avec un sysctl) pour qu'il reboote en cas de kernel
+panic.
+Il faut que quelqu'un migre les services mails sur un domU et les webmails sur
+owl.
+
+### Toilettage de la configuration des switchs et mise à jour des firmwares
+
+#### Vlan pour les switchs afin d'éviter de répandre le Vlan adm
+
+Olivier va s'occuper de mettre en place un Vlan switchs afin d'éviter que le
+vlan adm
+soit partout. A terme, il ne se trouvera que sur les chemins entre le 2B, la
+ferme,
+le 0H et le 0B.
+
+#### "Tagguage" des Vlan plus facile
+
+SIGKOOL. Le principe est de rentrer la topologie du réseau dans le script de
+génération
+des switchs pour pouvoir tagguer entièrement les vlans jusqu'à une prise grâce
+Ã une
+seule commande.
+
+#### Vlan isolement
+
+Il faut juste mettre à jour la configuration des switchs et le tagguer sur tous
+les uplinks.
+
+### Parler de l'architecture réseau
+
+#### Intégration du nouveau point d'accès
+
+On mettrait un serveur au G.
+
+#### Bâtiment G
+
+On a un local de brassage au 2e et 4e étage. Le CROUS pense mettre des gens
+début mai.
+
+Et un local principal au sous-sol qui distribuerait la fibre vers les autres
+locaux
+par des liens !GigaBits.
+
+On prendra des 2650.
+
+#### Redondance
+
+Il faudrait tirer une fibre entre le G et le J, il faut se renseigner pour en
+tirer une
+entre le H et C et il faut réparer la fibre défectueuse entre le I et le H.
+
+### PostGreSQL
+
+L'idée de départ était que ovh.crans.org continue à faire du greylisting
+lorsque le 0B
+est down. Une solution est que chaque serveur de mail ait sa propre base PgSQL,
+ces
+bases étant synchronisées entre elles.
+
+[[http://bucardo.org/|Bucardo]] est un système de réplication
+multi-master (i.e. qui
+synchronise dans les deux sens entre plusieurs serveurs, contrairement à la
+plupart
+des softs qui ne synchronisent souvent que 1 master -> n slaves). Il gère très
+bien les
+conflits (de toute façon, ce n'est pas quelque chose de critique pour
+l'utilisation que
+l'on veut en faire).
+
+Le problème est que Bucardo nécessite PgSQL ≥ 8.1, et que la base de rouge est
+en 7.4.
+Michel semble avoir trouver un moyen de dumper les bases et de migrer
+de 7.4 Ã 8.3.
+Il va créer un DomU PgSQL et y migrer toutes les bases (mail, filtrage, ...)
+
+### Asterisk
+
+La VoIP SIP fonctionne en interne. Une ligne SIP chez OVH a été souscrite.
+L'interfaçage est en cours.
+
+Les adhérents seront contactés depuis l'extérieur par un numéro débouchant sur
+un
+standard. Un adhérent sera alors identifié par son aid.
+
+En interne, il pourra être joint par son adresse mail canonique au Cr@ns ou par
+son aid. (On peut considérer le blocage sur demande du contact par adresse
+mail).
+
+On peut mettre en place un système de conférence ainsi que des messageries
+vocales.
+
+Il peut-être envisagé une période de test en charge pour les appels vers
+l'extérieur
+et l'intérieur. On pourrait alors ouvrir gratuitement les lignes téléphoniques
+pour
+tout le monde. Le CA doit décider s'il veut investir une somme pour cela.
+
+Xavier se charge de regarder pour des téléphones physiques.
+
+### Système de reboot des bornes wifi
+
+Le PCB est terminé et sera commandé cette semaine, les composants ont déjà été
+commandés.
+
+Les modules de test devraient être arrivés dans environ deux semaines.
+
+### Connexion des personnels de l'ENS
+
+Adg a commencé à écrire de la documentation technique sur le wiki. On leur
+donnera des
+informations sur l'intranet + accès à l'intranet de zamok.
+
+Il faut aussi faire de la correspondance MAC-IP sur titanic et le firewall en
+général
+(stats sur le trafic, ...).
+
+### Repo Darcs "béni" au crans
+
+On se fixe comme discipline de ne pas laisser des choses non commitées dans les
+repos.
+Adg doit réparer *proprement* le repo scripts.
+
+### Divers
+
+#### Imprimante
+
+Il faut trouver une méthode pour la débourrer en douceur. Par exemple, il faut
+installer
+une porte pour pouvoir sortir le bloc de finition.
+
+#### Connexion en Gigabit à l'ENS
+
+Il faut acheter une carte 10 GB fibre pour komaz. Il faut voir avec la DSI pour
+qu'ils
+nous branchent directement en fibre. Il faut garder le lien avec le transceiver.
+
+#### Système de Ticketting/destruction d'O₂
+
+Celui qui crée un truc qui plaît sur O₂ a gagné.
+
+#### Partition nfs de softs & libs
+
+On oublie.
+
+#### Protéger le nfs à l'aide d'un VPN
+
+Adg étudie la faisabilité.
+
+#### Dépôts git du cr@ns
+
+À voir plus tard.
diff --git a/compte_rendus/2009_05_04.md b/compte_rendus/2009_05_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..a2770d0363e9882cd86ce02b3d07d47904d8948c
--- /dev/null
+++ b/compte_rendus/2009_05_04.md
@@ -0,0 +1,108 @@
+# Réunion
+
+* Date : 04 Mai 2009
+* Lieu : Pavillon des Jardins
+* Début : 19h55
+* Fin : <<DateTime(2009-05-04T20:26:02+0100)>>
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Damien Aza-Vallina
+* Jérémie Dimino
+* Mathieu Segaud
+* Olivier Huber
+* Stéphane Glondu
+* Xavier Lagorce
+
+### Bilan sur les dernières migrations et les changement au niveau des
+serveurs
+
+Rouge est presque mort, il fait encore DHCP et TFTP pour le boot PXE.
+
+Mais que va-t-il devenir ? pom pom pompommm
+
+Il est trop tard pour rallonger sa garantie, par contre, c'est encore possible
+pour
+les serveurs les plus récents. Celà pourrait être intéressant de le faire, il
+faudrait
+chiffrer les extensions de garanties et proposer cela au CA.
+Il faut donc relever le SN/PN et le modèle des différents serveurs et les
+transmettre
+à Stéphane.
+
+Il faut faire la mise à jour d'OpenBSD. Régala se propose si aucun apprenti
+n'est harponné
+pour le faire.
+
+### l'IMAP est-il lent sur owl?
+
+owl présente des problèmes d'IOs. Certaines personnes considèrent que cela le
+ralentit.
+
+On pourrait tester openvz, avec owl... pour voir...
+
+### Système de reboot des bornes
+
+PCB reçu, prototype assemblé. Il fonctionne.
+
+Un prototype en CMS va être conçu puis testé.
+
+### Système de ticketing
+
+"C'est plutôt cool" dixit Stéphane.
+"On s'en sert pas" dixit Antoine.
+"C'est pas incompatible, ça s'applique à moi" dixit Stéphane.
+"Il consomme beaucoup de RAM" dixit Stéphane
+
+/me compte les points.
+
+adg doit cliquer, il est pas content...
+
+Conclusion : il faut s'en servir davantage.
+
+### Protection du NFS Ã l'aide d'un VPN
+
+Il faudrait tester NFSv4 ou mettre OpenVPN...
+
+Il y a des points plus urgents à développer.
+
+### Bilan sur la nouvelle base Pg
+
+On reçoit des mails...
+Il faudrait installer munin dessus...
+
+### Achat de matériel
+
+* 16Go de ram pour chaque dom-0: +8Go pour fy +12Go pour fx
+ * Il semble y avoir deux slots de libre sur fy
+* Prix des alimentations pour Fx.
+* Achat d'une carte d'une carte Gigabits pour Sila.
+
+### Achat multiprise ssh
+
+* Stéphane demande un devis à Anne pour les PDU.
+* Olivier se charge d'appeler la mge (Jeudi 7 Mai)
+
+### Achats pour les chaînes TNT HD
+
+* Olivier a trouvé un ampli à 8 sorties (référence AVN1716F KUBLER).
+
+Il doit se charger de le commander rapidement.
+
+### Déploiement du wifi en WPA2
+
+Migration le week-end du 6-7 juin.
+
+### Mise en place de l'inscription en ligne
+
+Adg et Chicco ont commencé à regarder.
+
+### Authentification LDAP sur le wiki
+
+* Ça marche sur Vo
+
+### Bugs de MoinMoin
+
+"C'est pas des bugs, c'est des features"â„¢
+Il y a des problèmes de caching.
diff --git a/compte_rendus/2009_05_25.md b/compte_rendus/2009_05_25.md
new file mode 100644
index 0000000000000000000000000000000000000000..f7a6e04d6439870ab914e251c096356b44b27c52
--- /dev/null
+++ b/compte_rendus/2009_05_25.md
@@ -0,0 +1,271 @@
+# Réunion
+
+* Date : Lundi 25 mai 2009
+* Lieu : 2@B, clim powa®
+* Début : 20h00
+* Fin : 22h30
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Damien Aza-Vallina
+* Jérémie Dimino
+* Pierre Chambart
+* Xavier Lagorce
+
+Par Gobby :
+
+* Brice Dubost
+* Michel Blockelet
+* Nicolas Dandrimont
+
+## Ordre du jour
+
+### Imprimante canon
+
+Adg a installé les drivers proprios (UFR) téléchargés sur le site du
+constructeur,
+mais c'est moche car il faut passer par une conversion PS. On passe par un
+binary pour convertir en postscript, ce qui fait que l'on a aucune idée de
+pourquoi ça ne marche pas. En plus certains pdf ne sont pas interprétables.
+
+Actuellement la facturation se fait au nombre de pages, comme il avait été
+décidé en CA. Ce qui fait que tu enrichis le CRANS lorsque tu imprimes du
+monochrome en couleur. En effet, l'imprimante peut détecter une page n&b dans
+un doc couleur
+(voir CR des réunions CA au sujet de l'imprimante).
+
+Si quelqu'un veut s'embêter à vérifier la colorisation de toutes les pages,
+il peut. Ne serait-il pas possible de le demander à l'imprimante ? En parsant
+l'interface web...
+
+La mise en place du nouveau système de facturation a nécessité un retouche
+de l'intranet et des différents scripts d'impression. Antoine a profité
+pour faire le ménage parmi les scripts.
+
+#### Wrapper de l'interface web en ocaml
+
+Antoine a développé une petite application en OCaml, qui permet de soumettre
+le pdf à l'interface web et de sélectionner les options. Ce script fonctionne
+mais n'est pas encore tout à fait au point.
+
+Xavier fait remarquer qu'il est dangereux de coder des scripts en OCaml. En
+effet le python a l'avantage d'être beaucoup plus simple et lisible (et ça
+fait moins peur aux nouveaux).
+De plus, ce problème a déjà été discuté en inter-nounou et l'assemblée avait
+tranché contre l'utilisation généralisée d'OCaml.
+
+Pierre fait remarquer qu'en perl ça peut être pire.
+
+Damien fait remarquer que dans environ 2 ans, l'imprimante sera changée.
+
+#### Statistiques
+
+Il serait bon d'envoyer des mails pour les consommables.
+
+#### Utiliser le driver PCL
+
+Antoine fait remarquer qu'on peut aussi investiguer sur l'éventuelle utilisation
+du driver pcl pour l'imprimante.
+
+### État de migration des serv{eur,ice}s
+
+Penser à installer le switch gigabit pour la baie iSCSI.
+
+#### Vert
+
+* /home se remplit (209/225GB) Une des raisons est le stockage des logs de
+ squid sur cette partition (14GB)
+ * Damien fait remarquer que cela risque d'être très problématique à la
+ rentrée.
+ * Si la croissance continue à ce rythme, /home sera plein à la mi-juillet.
+ Il faut rapidement migrer /home sur la baie de disques iSCSI.
+* Migration de LDAP ou mise à jour ?
+ * L'avis de Nicolas est que vert est un serveur obsolète, et que le mettre Ã
+ jour à lenny n'avancera à rien. De plus, étant serveur LDAP principal et
+ serveur NFS, un downtime serait très problématique pour l'ensemble des
+ services.
+ * Antoine propose d'effectuer la migration (de quoi ?) le samedi 14 Ã partir
+ de minuit.
+* Laisser les homes en RO ? (soft bounce)
+* Configurer newldap en serveur LDAP primaire
+* Créer un domU home si les problèmes d'I/O sont réglés d'ici là (KVM semble
+ prometteur), sinon, continuer à utiliser vert. (en attendant un serveur
+ physique ?)
+
+#### rouge
+
+* SMTP principal
+ * Il faut déplacer/dupliquer amavis/clamav sur redisdead avant de bouger
+ mailman définitivement. Faire fonctionner l'authentification en envoi sur
+ redisdead.
+* Mailman : Les fichiers de configuration de mailman ont été rsyncés sur
+ redisdead, il faut:
+ * Diminuer le TTL des DNS
+ * Attendre (24h) (pendant ce temps, vérifier que mailman fonctionne sur
+ redisdead)
+ * Mettre une redirection sur rouge du trafic de lists.crans.org vers
+ redisdead
+ * Changer les alias lists.crans.org, smtp.crans.org, mailman.crans.org
+ * Prévenir les adhérents qu'il faut utiliser smtp.crans.org pour envoyer des
+ mails
+ * Attendre que rouge ne reçoive plus de mails vers lists.crans.org
+ * Faire tomber la guillotine
+ * Ré-augmenter le TTL des DNS
+* ntp
+* dhcp
+
+Nicolas est de toute évidence la personne le plus au courant de ce qu'il faut
+faire.
+
+#### zamok
+
+* etch -> lenny
+ * Quelqu'un voit quelque chose qui casserait sur zamok lors d'une
+ mà j ? -> L'intranet ?
+* iso -> utf-8
+ * Faire gaffe aux *noms* des fichiers dans les homes dans les adhérents
+ * Résoudre les problèmes avec les scripts
+
+#### Ragnarok
+
+* Trial of the BSD Knights -> Games
+ * Il faut inciter un apprenti à effectuer la migration.
+
+#### Virtualisation
+
+Munin a été migré sur fx dans kvm.
+
+Quelques statistiques :
+
+* http://munin.crans.org/crans.org/munin.crans.org-munin_update.html -> munin-update prend plus de temps
+* http://munin.crans.org/crans.org/munin.crans.org.html#System -> pas d'I/O
+ wait ...
+
+Munin est un bon exemple pour pouvoir décider de la robustesse/efficacité
+d'une solution de virtualisation.
+
+On va encore le laisser une petite semaine munin sur kvm pour pouvoir
+comparer. Si le test est concluant, une migration d'owl devra être effectuée
+pour confirmer les résultats (c'est en effet le domU qui est le plus chargé
+actuellement).
+
+La solution actuelle de virtualisation n'est pas satisfaisante:
+
+* Problèmes d'I/O
+* Échecs de migrations à chaud
+* xen n'est pas vraiment maintenu
+
+Remarque: on n'utilise pas la virtualisation matérielle sur fy.
+
+##### Tweaking
+
+Dans les machines virtuelles kvm, l'ordonnancement des entrées sorties est fait
+par défaut par l'ordonnanceur CFQ. Il en est de même pour l'hôte/hyperviseur. De
+plus, les disques sont en iSCSI, un troisième ordonnancement est effectué par la
+baie de disques. Pour gagner en performances, il faut utiliser l'ordonnanceur
+''noop'' sur les VMs (ce qui est le cas sur munin depuis quelques heures). Il
+faudrait voir s'il ne serait pas avantageux de faire ceci sur les disques iSCSI
+sur l'hyperviseur. (Les VM xen en virtualisation logicielle utilisent déjà cet
+ordonnanceur par défaut). Règles UDEV sur fx et fy ?
+
+### Cacher youtube
+
+Ça ne marche *que* pour youtube. Il serait bon d'avoir des stats sur les
+requêtes pour le cache de squid
+(-> http://munin.crans.org/crans.org/sable.crans.org.html#Squid qui ne marche
+plus).
+Manifestement le cache ne tient pas très longtemps (ou bien ça ne marche
+plus ?).
+Il faut investiguer.
+
+* Qu'est ce que c'est cette histoire de cacher
+ youtube ? -- WikiPolo <<DateTime(2009-05-26T09:57:47+0100)>>
+
+Adg voudrait pouvoir faire la même chose pour !DailyMotion, Deezer, ...
+Mais Pierre dit que : Deezer c'est assez moche, on avait essayé à Berlin...
+Il faut croire qu'il y a des données en plus pour identifier les connexions.
+J'ai un peu fait mumuse avec !DailyMotion, ça a l'air du même accabit.
+
+### Vlan 21
+
+#### MSN
+
+* Ça n'a juste pas marché lorsque j'ai voulu essayer avec pidgin, bien que tous
+ les ports eussent été ouverts.
+* Ce qui est bizarre c'est que j'ai eu des retours positifs dessus.
+
+#### Wiki
+
+ip_crans renvoie false sur l'ip de titanic.
+
+#### Câblage d'un appartement du CROUS
+
+Aucune limitation technique (à part le câblage physique)
+
+#### Monitoring
+
+La connexion marche. Il serait de faire des stats sur le trafic sur la
+connexion de la freeboîte. (En plugin munin ?)
+
+### Câblage de la Kfet
+
+Réalisé jeudi. Il faudra acheter et fixer des prises murales
+
+### Wifi WPA2
+
+On préfère garder la surprise pour le we du 7-8. (Vous êtes des malades)
+
+### Interface d'inscription en ligne
+
+Ce sera un patch du wiki (et ça ne sera même pas trop sale)
+
+### Authentification sur moinmoin par la base ldap
+
+* On autorise une double authentification (comme sur vo)
+* On rajoute un champ wikinom dans la base LDAP initialisé à !WikiPrénomNom (ou
+ PrénomNom (ça me paraît être la base du wikinom))
+* Ce champ est modifiable par l'intranet.
+ * Gros checking pour éviter les collisions. (Ce check ne peut se limiter Ã
+ la base LDAP)
+ -> Cette solution n'empêche en rien de continuer à utiliser les comptes
+ MoinMoin.
+
+Cependant il pourrait être judicieux de supprimer la création de comptes
+MoinMoin
+pour éviter les collisions.
+
+Les homonymes pourront être gérés par une unicité dans la base LDAP.
+
+L'authentification LDAP nécessite MoinMoin >1.8 (squeeze) (vu le niveau de
+patchage du paquet custom actuel, ce n'est pas vraiment un problème).
+
+### Inventaire du matériel
+
+Il faudra compter les switchs du 0C. Il faudra un jour faire du rangement.
+
+### Achats de matériel
+
+* La RAM a été commandée
+* Tant que la MGE n'aura pas été appelée, on ne statuera pas sur l'achat des PDU
+ * A priori, MGE n'a pas été appelé (comme *promis* par Olivier le 5 mai)
+ * Vérifier que les pdu font bien ce que l'on attendrait d'eux
+* Clim de la ferme
+ * Damien a déposé le dossier de travaux auprès du CROUS
+ * Damien a fait un devis auprès de notre prestataire de clim
+ * Damien va faire un devis auprès du prestataire climatisation de l'ENS
+* Switchs du G (on ne sait pas)
+
+### Motiver les apprentis
+
+* Remplacer SQLGrey par un truc plus intéressant *kh* milter-greylist *kh*
+* **Asterisk** <- en cours à partir de la semaine prochaine
+* Préinscription
+* Migration openbsd (c'est chiant)
+* Taper l'incruste au dpt info avec chicco
+* IPv6 (lobbying de l'ENS ?)
+* Mangez avec les doigts comme tout le monde... ( avec la bouche ça suffit )
+* Faire des poupées vaudou albanel et riester (et lefebvre, gosselin)
+* Refaire des chiffons{{{^W}}}t-shirts firefox{{{^W}}}iceweasel
+ * Fan inconditionnel des T-Shirts
+ Iceweasel -- WikiAdg <<DateTime(2009-05-26T13:51:43+0100)>>
diff --git a/compte_rendus/2009_06_11.md b/compte_rendus/2009_06_11.md
new file mode 100644
index 0000000000000000000000000000000000000000..cf17e00362660bdf4243c992249fcb60bc8075d3
--- /dev/null
+++ b/compte_rendus/2009_06_11.md
@@ -0,0 +1,81 @@
+# Réunion Nounous
+
+* Date : Jeudi 11 juin 2009
+* Lieu : Pavillon des Jardins
+* Début : 19h30
+* Fin : -- WikiXhub <<DateTime(2009-06-11T20:45:04+0100)>>
+
+### Présents
+
+* Jérémie Dimino
+* Antoine Durand-Gasselin
+* Olivier Huber
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Vert is dead
+
+On demande à acheter un fz (HP Proliant DL 360) qui servira soit pour de la
+virtualisation soit comme serveur classique.
+Cf demande sur tracker pour la liste des choses à acheter.
+
+### Problèmes du bâtiment J
+
+On y a passé une semaine, on a fait des trucs, mais depuis que la ferme ne
+diffuse plus, on n'a pas constaté de problème.
+Nous restons à l'écoute des adhérents.
+
+### Migration des services de rouge
+
+Cf tracker pour les services qui restent à migrer.
+
+### MoinMoin
+
+Adg va essayer de passer le plus vite possible à la 1.8.
+
+### WiFi
+
+Sous linux ça marche du tonnerre : la configuration est
+là : https://wiki.crans.org/WiFi/SousLinux
+Sous Mac Os : Xavier s'occupe de mettre la configuration sur le Wiki
+Sous Vista : ça ne marche pas pour l'instant
+
+Les instructions sont sur le Wiki :
+https://wiki.crans.org/WifiTechnique/FirmWare
+
+### Virtualisation au Cr@ns
+
+On essaie de faire des tests supplémentaires avec plusieurs systèmes de
+virtualisation.
+
+### Préinscription en ligne
+
+Adg pose un lock. D'ici jeudi prochain on a une preview.
+
+### Asterisk
+
+On ne peut pas accéder à notre ligne depuis l'extérieur. Il faut régler les
+problèmes administratifs (il faut juste envoyer un courrier).
+
+### Imprimante
+
+Il faut passer zamok à lenny, peut-être essayer les driver pcl. Problèmes
+actuels :
+
+* Certains pdf ne passent pas (mais ça marche avec l'interface web de
+ l'imprimante)
+* L'agrafage en livret ne marche pas (déterminer la limite à partir de laquelle
+ l'imprimante ne veut agrafer)
+
+### Redondance et QoS
+
+Le CA devrait fournir un cahier des charges clair.
+
+### Serveur pour FeDeRez
+
+On migre les dns de mdr autre part et on leur donne le serveur.
+
+### Divers
+
+La connexion à la Kfet ne marche pas.
diff --git a/compte_rendus/2009_07_02.md b/compte_rendus/2009_07_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5c49bf407014100442d4eb8dc28986cabe366a2
--- /dev/null
+++ b/compte_rendus/2009_07_02.md
@@ -0,0 +1,220 @@
+# Réunion
+
+* Date : Jeudi 2 juillet 2009
+* Lieu : 2B (clim powa)
+* Début : 20h15 (asterisk powa)
+* Fin: -- WikiAdg <<DateTime(2009-07-02T21:59:34+0100)>>
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Damien Aza-Vallina
+* Nicolas Dandrimont (conférence VoIP)
+* Olivier Huber
+* Pierre Chambart
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Achats de matériels
+
+* switch 0J (2810) devis (./) , achat (./)
+* switch 4j (2910) devis (./) , achat (./)
+* switch plafond2B (1800, le même que minigiga) devis {X} , achat {X}
+* disques: trop cher, on attend
+* modules ps/2: devis (./) , achat (./)
+* multiprises ssh: devis {X} , achat (./)
+* switchs du G: on attend encore un peu
+* chaises pour les locaux: 4 pas chères (./)
+* fz, devis {X} , achat (./) a priori
+* Pour les logs, des DD Sata sur slon ? Un serveur syslog ? autant que
+ ca ? -> dans le chat)
+
+### Dossiers avec la DSI
+
+Il faut prendre rendez-vous avec la DSI pour aborder les points suivants:
+
+* wifi :
+ * Solutions que la DSI compte déployer ?
+ * Intégration avec notre solution ?
+ * Est-ce qu'on peut arrêter de diffuser ENS-Cachan ?
+ * Elles sont passées où nos bornes en zone ENS ?
+ * Faire marcher notre wifi en zone ENS (PDJ...)
+* gigabit (matos à acheter ?)
+* upload
+* miroir debian ?
+
+### Rangement/Équipement des locaux
+
+* Quand est-ce qu'on range le 0C ?
+ Un jour.
+* Quand est-ce qu'on range la ferme ?
+ Un jour. (ou peut-être une nuit)
+ * de préférence la nuit.
+* Quand est-ce qu'on fait un inventaire.
+ * On attend fin août quand il y aura plein de monde
+
+### Organisation des différents projets et détermination de leur priorité
+
+Il serait bon de mettre en place une liste claire des projets qui pourraient
+être effectués par des apprentis.
+
+### Point sur les dossiers techniques
+
+#### impression
+
+Il y a des pdf qui buggent, ils restent donc actifs indéfiniment dans la
+lpq, bloquant les impressions. Supprimés de la lpq, un process fou continue
+de manger du cpu indéfiniment.
+
+Solutions envisagées:
+
+* Migrer zamok à lenny
+* Utiliser RPC
+* Utiliser un script OCaml pour soumettre les pdf par l'interface web
+
+(cette solution a le défaut d'être vraiment lente, même quand on compile en
+natif)
+
+* Backporter cups + quelques libs
+* Tester sur d'autres machines sous lenny (tenter d'autres machines)
+
+##### Évolutions
+
+* Facturer de manière plus juste (ne pas facturer les pages n/b comme de la
+ couleur).
+* Du nupping.
+* Aperçu des pdf en direct (ajax powaaa)
+* rajouter les limites
+* débugger un peu le bouzin *ahem*
+
+Projet proposable:
+termes d'accroche -> programmation web, Ajax, user-friendlyness, impression
+nounous pouvant encadrer -> adg (AT) crans (DOT) org
+
+#### modules de reboot des bornes
+
+Pas de méthode d'authentification sur les bornes. Les bornes seront isolées sur
+un vlan. On peut faire une OTP très sale.
+
+Deuxième prototype d'ici une semaine et en CMS.
+
+La doc quand ça sera terminé.......
+
+#### déploiement du wifi
+
+it worksâ„¢ (bitches)
+
+Les bornes diffusent l'ESSID Cr@ns en WPA2-Enterprise, et transmettent les
+requêtes radius à ragnarok. Radius sur ragnarok est configuré pour accepter
+les couples mac/[former]clef ipsec. Ça marche sur beaucoup d'OS très utilisés.
+
+#### développement du wifi
+
+ -> rachat de bornes: lesquelles?
+ * supportées par openWRT:
+ http://oldwiki.openwrt.org/TableOfHardware.html
+ * débit (chiffrement)
+ * possibilité de diffuser plusieurs ssid
+ * 802.11n ? .11a ça serait cool déjÃ
+ * MIMO ?
+ * NB: il y a des bornes qui ont des disques usb
+
+##### Évolution
+
+ -> monitorer un peu mieux les bornes
+ * faire joujou avec x-wrt
+ * wiviz
+ -> comprendre la conf de radius sur ragnarok
+ -> nettoyer la conf de radius sur ragnarok
+
+##### Blagues (ou pas)
+
+ -> projet de borne autonome (se manifester avant le rangement des locaux)
+
+#### ipv6
+
+Actuellement en place:
+
+* un tunnel sur komaz
+* squid3 sur sable
+ -> dégager des projets pour des apprentis.
+ * firewall (projet à encadrer strictement)
+ * réécrire proprement les scripts de comptage
+ * négocier avec la DSI open-réseau
+ * dhcp / router advertaïzement
+ * igmp
+ * les scripts ?! -> les scripts seront plus ou moins recodés dans leur
+ intégralité.
+
+#### features des switchs
+
+##### DHCP pirates
+
+* Protection contre les DHCP pirates
+
+##### Détection des boucles
+
+Les gens du point rencontre ont fait des boucles. Ça a mis down une partie du
+réseau. Il faudrait vérifier que la détection des boucles marche. On perd
+Jérémie,
+mais le problème devrait bientôt être résolu.
+done! *applause*
+
+#### rouge
+
+On migre rouge dès que possible. La source de rayons comiques s'est peut-être
+tarie.
+Peck est sur le campus pour de bon.
+
+ -> petit projet pour apprenti:
+ générer un known_hosts potable et ranger les clefs.
+
+#### vert
+
+Une belle bête, qui pèse bien ses 42kg. On remarquera que vert a des
+ventilateurs
+rackables.
+
+#### OpenStreetMap
+
+Il faut voir *exactement* de combien de place et de débit ils ont besoin, et on
+décide en conséquence...
+
+#### Corbeau
+
+diffusion-crans.general@crans.org poste automatiquement sur crans.general
+seule brigitte.vidal@adm.ens-cachan.fr pourra poster. Si elle poste trop,
+on la déconnecte.
+
+#### pegase
+
+il est open
+munin me paraît être un excellent choix.
+
+#### proxy
+
+revoir la conf de zéro
+
+#### VoIP
+
+It worksâ„¢.
+Il reste encore *plein* de trucs à faire.
+
+Oh! tiens encore plein de programmation web à faire.
+
+#### wiki
+
+À mort Apache ! Mais bon, osef. Ocsigen avec WSGI (l'interface "CGI" mieux de
+Python) ? ocsigen powa ( ocsimore a une grosse bite )
+
+#### zamok
+
+l'idée serait de coller sur fzamok, l'impression, l'intranet,
+le webmail, l'imap, le pop, et, dans une machine virtuelle, le serveur des
+adhérents.
+niomniom resterait le serveur web du crans.
+
+On casse zamok ? (upgrade)
+Bof.
diff --git a/compte_rendus/2009_09_10.md b/compte_rendus/2009_09_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..e0e285e210944c190067ae879480f0c85c6d7677
--- /dev/null
+++ b/compte_rendus/2009_09_10.md
@@ -0,0 +1,248 @@
+# Réunion Nounous
+
+* Date : Jeudi 10 Septembre 2009
+* Lieu : PdJ
+* Début : 19h30
+* Fin : 21h35
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Johan Grande
+* Larissa Viraphong
+* Michel Blockelet
+* Nicolas Dandrimont
+* Olivier Huber
+* Raphaël Bonaque
+* Raphaël Cauderlier
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Présentations
+
+Elles sont faites et mamie a trouvé le bon serveur sur lequel se connecter :)
+
+### Bilan du câblage du bâtiment G (espérons...)
+
+* Le bâtiment G a été relié avec un câble RJ-45 de 153m de long
+* Les switchs ont étés installés
+
+La solution qui a été mise en place (le long RJ-45) ne marche pas très
+bien. Il faudra réussir à pérenniser la connexion, vu qu'il faudra
+nécessairement
+remettre une fibre optique. L'ancienne semble vraiment en trop mauvais état pour
+être utilisée. Il faut budgétiser le sertissage d'une nouvelle fibre, ainsi que
+sa pose (sachant que nous pourrions effectuer nous-même la pose de la fibre).
+
+À priori, une bobine de 250m de fibre coûterait dans les 500 euros.
+L'utilisation de la fibre enroulée actuellement au -1I n'est pas envisageable,
+vu qu'elle est enroulée depuis plus de 5 ans.
+
+La fibre connectant le 0G et le 2G est cassée dans la baie de brassage, il
+faudrait
+voir à la faire ressertir. Il faudrait aussi voir si sa réparation ne pourrait
+pas
+être prise en charge par une des (certainement nombreuses) assurances du CROUS
+pour
+les travaux dans le bâtiment G.
+
+Connexion actuelle au G :
+batj-319 <-- 153m (cuivre) --> batg-025 0G <-> 4G en fibre et 4G <-> 2G en
+cuivre (cat6).
+
+Restrictions :
+La télé est bloquée depuis batj-3. Il faut dire aux câbleurs de prévenir les
+gens
+pour utiliser leur connexion avec parcimonie (quand elle fonctionne).
+
+### Recrutement - lancement des séminaires
+
+Olivier propose que les apprentis fassent toujours les séminaires, mais qu'une
+nounou soit responsable de suivre le travail de l'apprenti et puisse servir de
+backup en cas de problème.
+
+Une autre idée serait de faire des revues de code Python, afin d'améliorer les
+scripts en douceur et de permettre la transition.
+
+Les nounous se chargent de mettre au point une liste de séminaires qui sera
+présentée à la prochaine internounou.
+
+### État des lieux des serveurs
+
+#### rouge : MX principal, serveur smtp et serveur mailman
+
+(anciennement wiki, serveur web, serveur jabber, serveur imap, serveur pop,
+serveur ntp,
+serveur de kernel panic, serveur DHCP)
+
+Il faut mettre fin à ses jours sous peu. Ne reste plus qu'à migrer les
+services mail.
+
+#### zamok
+
+Serveur des adhérents, serveur des pages perso, de l'intranet, délivrance des
+mails (procmail, forward, etc.)
+
+Une proposition serait d'acheter un nouveau "gros" serveur (fz), sur lequel
+seraient
+rassemblés les services concernant les adhérents. Vu que les tests d'autres
+solutions de virtualisation n'ont pas été probants, ce serveur serait placé sous
+xen. Il faut budgetiser cette solution.
+
+#### pegase
+
+Ne fait plus rien, est éteint, mais fonctionne (et a plein de disques). Est une
+vieille brouette.
+
+#### babar
+
+Serveur de sauvegarde et de vidéosurveillance, fonctionne, est à jour.
+
+#### sila
+
+Serveur sFTP. Un peu ancestral, un peu de brique et de broque. Il faudrait
+demander
+un devis pour :
+
+* Un serveur 1U ou 2U avec des gros disques
+* Un serveur 1U avec des petits disques et des gros disques pour la baie
+
+Et choisir la solution la moins chère, pour remplacer sila en tant que FTP.
+
+#### ragnarok
+
+Serveur sous OpenBSD, serveur radius, routeur wifi, serveur web de
+wifi.crans.org
+
+Il faut le mettre à jour vers OpenBSD 4.5 (comme tous les 6 mois). Peut-être que
+les fuites mémoire de {freeradius, Patches OpenBSD} seront corrigées.
+
+#### Serveurs de la ferme
+
+* vache (mdr) (dns de la zone TV) -- It works!â„¢
+* canard
+* oie
+* lapin
+* dindon (prove)
+
+Les serveurs fonctionnent, mais le multiswitch a cramé. On récupère la TNT en
+splittant le flux. On peut racheter un multiswitch, ce qui nous permettra de
+multiplier le nombre de cartes satellite.
+
+#### fy
+
+* Dom0 Xen
+
+#### fx
+
+* Serveur NFS (homes + /usr/scripts)
+
+#### sable
+
+Le proxy, serveur DNS principal, serveur DHCP, serveur radius, serveur de la
+connexion gratuite.
+
+Il fonctionne malgré la grosse mise à jour de porc vers squid3.
+
+### Investissements potentiels
+
+* Nouveau contact pour Synaps : Nicolas va reprendre le contact avec Anne.
+
+#### ftp
+
+Cf. ci-dessus.
+
+#### fz/zamok++
+
+Le système imaginé avant les vacances, lors des problèmes d'I/O Xen, était
+d'acheter
+un serveur qui monterait les /homes, et les partagerait directement à tous les
+services qui en auraient besoin (i.e. les services adhérents de zamok + owl +
+niomniom).
+
+Vu que les problèmes de Xen semblent réglés, placer les services des adhérents
+sur un DomU serait envisageable. On va voir avec Anne ce qu'elle propose comme
+bête de course.
+
+#### monitoring
+
+Il faudrait budgetiser un serveur "peu puissant" pour effectuer le monitoring
+séparément (munin, autostatus, ...). On pourrait y ajouter pour pas cher une
+centralisation des syslog (Ã l'aide de rsyslog).
+
+#### Fibre
+
+Cf. ci-dessus
+
+#### Reboot de bornes
+
+Voté au précédent CA (500€ de budget pour 10 modules) et cf ci-dessous.
+
+#### Bornes wifi
+
+Voté au précédent CA (500€ pour $n$ bornes de test)
+
+### Projets en cours
+
+#### bcfg2
+
+Système de gestion de configuration des serveurs. Permet de centraliser les
+configurations redondantes.
+Comme puppet ou cfengine (mais en python).
+
+Le passage de bcfg2 0.9 à 1.x nécessite python 2.6 (ou un module SSL backporté).
+
+Il faudrait unfucker la configuration.
+
+#### Reboot de bornes
+
+It works, bitches !â„¢
+
+Un des modules a été détourné pour remplacer vigile pour la gestion du digicode.
+
+Il faudra des doigts pour réaliser les 100 modules.
+
+#### Impression
+
+L'imprimante en elle-même marche très bien (beaucoup mieux que l'ancienne), mais
+les drivers de canon chient.
+
+Par ailleurs, toutes les ~100 pages imprimées, si elles restent dans le bac,
+l'imprimante s'arrête et attend que quelqu'un les enlève du bac de sortie.
+C'est très gênant pour les grosses impressions de rentrée.
+
+#### Intranet
+
+C'est de l'AJAX avec !MochiKit. Adg s'est un peu penché dessus, et apparemment
+il va réussir à le migrer vers !CherryPy de lenny.
+
+#### Téléphonie
+
+Vous allez être mis en communication avec votre correspondant, merci de
+patienter quelques mois...
+
+Le Crous a demandé à son FAI de s'occuper aussi d'un service de téléphonie sur
+IP, et voudrait qu'on ne soit pas en concurrence avec lui.
+
+### Questions diverses
+
+#### Répartition des clés
+
+Michel aimerait avoir une clé du 0B. Il faut que Jérémie rende ses clefs du
+Cr@ns.
+
+En particulier pour les clés du 4J, il faudrait essayer de savoir exactement où
+sont les clés, et récupérer celles des gens qui ne les utilisent plus...
+Comme tous les ans ?
+
+Xavier pense développer, sur la même base que les modules de reboot et le
+digicode, des serrures RFID qui remplaceraient avantageusement les 16 clés du 4J
+qui se baladent dans la nature (et même, peut-être, des autres locaux
+associatifs ?).
+
+#### Crous
+
+Des discussions ont eu lieu avec le FAI, qui accepte de nous laisser gérer le
+routage, le filtrage et les logs.
diff --git a/compte_rendus/2009_10_22.md b/compte_rendus/2009_10_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..2adafebeb1c844d9908e90d41855bba273e3d88f
--- /dev/null
+++ b/compte_rendus/2009_10_22.md
@@ -0,0 +1,81 @@
+# Réunion Nounous
+
+* Date : 22 Octobre 2009
+* Lieu : Pavillon des Jardins
+* Début : 19h30
+* Fin : <<Date(2009-10-22T20:56:17+0200)>>
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Damien Aza-Vallina
+* Johan Grande
+* Michel Blockelet
+* Nicolas Dandrimont
+* Raphaël Bonaque
+* Raphaël Cauderlier
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Point technique sur la convention Cr@ns - CROUS
+
+### Bâtiment G
+
+#### Réseau Filaire
+
+#### Couverture WiFi
+
+On a mis des bornes sur le J, on a l'accord de principe de l'ENS pour arroser
+la façade ouest du G depuis le toit du Cournot.
+
+#### Pont WiFi
+
+Le cdcf c'est un pont chiffré: openWRT pourvoit un mode spécifique
+
+### Ragnarok (maj, fuites de memoire)
+
+Il *faut* mettre à jour Ragnarok.
+Il faudra vérifier radius et munin qui sont actuellement les générateurs
+d'occupation mémoire.
+
+### Accès aux backups des homes des adhérents
+
+Il faut y réfléchir avant la migration de zamok. Il faut réfléchir à :
+
+* La réutilisation potentielle des uid (qu'un nouvel adhérent ne se retrouve
+
+pas avec les backups d'un ancien dont le compte a été supprimé)
+
+* A ce que l'espace de stockage ne soit pas virtuellement infini.
+
+### Serveurs Free
+
+Xavier se propose pour aller les chercher la semaine prochaine avec les gens
+intéressés. Ce sont des serveurs 1U, sans disques durs (on les ferait booter
+depuis le réseau).
+
+### Organisation des séminaires techniques
+
+On pourrait ajouter un séminaire sur le firewall prochainement, ou pas. Pour les
+séminaires suivants, il faudrait essayer d'encadrer un peu mieux et que les
+séminaires soient un peu moins abstraits.
+
+### Projets Apprentis
+
+* "recoder munin"
+* dns pour les vieux
+* VoIP (ou pas)
+* recoder l'intranet
+* faire des enregistrements pour un GlaDOS Ã la ferme
+* débugger la pute d'imprimante
+* IDS / monitoring
+* ... Ce qui vous plairait ?
+
+### Installation de fz
+
+* Les homes montés dans l'hôte, qui les distribuerait directement aux jails.
+ (on partirait donc sur une architecture de jailing). On pourrait tester openvz
+ et/ou vserver. On fera des tests sur fz, jusqu'à ce que ça semble stable et on
+ procédera à la migration de zamok.
diff --git a/compte_rendus/2009_12_10.md b/compte_rendus/2009_12_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..8b3b03f60c57aefba8b1aced3871800249c4c0b6
--- /dev/null
+++ b/compte_rendus/2009_12_10.md
@@ -0,0 +1,102 @@
+# Réunion
+
+* Date : 10 Décembre 2009
+* Lieu : Pavillon des Jardins
+* Début : 19h30
+* Fin : 21h35
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Dominique Delport
+* Jean-Benoist Leger
+* Jérémie Dimino
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Connexion de fortune bâtiment G
+
+#### Couverture WiFi
+
+Actuellement le batiment G est arrosé sur sa façade est. Il devrait
+être possible de s'arranger avec le dpt info pour installer des bornes
+au Cournot. Il faudrait étudier l'installation au sol de bornes avec des
+antennes Hyperlink (17dB, 120°, aucun bruit à l'arrière).
+
+Les vitres du bâtiment G atténuent beaucoup le signal (quid de demander
+aux adhérents d'installer une antenne ?).
+
+Avec la solution actuelle basée sur des linksys WRT54g on ne peut
+dépasser une quinzaine de clients par bornes. Les bornes bullet
+d'ubiquiti peuvent être un nouveau matériel intéressant vers lequel se
+tourner. Possibilité de pont wifi, support de beaucoup plus de clients.
+Ces bornes, nouvelles, utilisent le 802.11n, et permettent d'atteindre
+300Mb/s réel. Les prix sont tout à fait corrects (50-100€).
+
+D'un point de vue légal, il devrait être tout à fait possible de
+respecter les réglementations en vigueur en matière d'émission
+hertzienne.
+
+### Installation de fz
+
+Utilisation d'une solution de containers (OpenVZ ou vserver...).
+
+Il y aurait :
+
+* Un container pour les adhérents
+* Un container pour les services mail
+* ...
+
+### Déconnexion mail invalide
+
+Michel n'est pas là pour nous en parler...
+
+### Modifications de la base LDAP
+
+#### Autorisation de la modification d'attributs dans le sous-arbre des
+adhérents
+
+Ceci permettrait de modifier plus proprement les données de l'adhérent
+depuis l'intranet, qui n'aurait plus à être lancé en tant que respbats.
+
+Il faut étudier comment faire ça proprement avec les ACLs de LDAP (création
+d'une vue spécifique).
+
+#### IPv6
+
+On donne un /64 par machine (fixe) inscrite dans la base LDAP. Ceci sera fait Ã
+la demande (champ booléen dans la machine).
+
+Le préfixe IPv6 est donné comme suit :
+[préfixe crans (n bits)]:[mid (p bits)]::/64
+
+#### Cleanup Type de connexion
+
+Ce champ permettrait de formaliser le champ "Connexion Gratuite / Appartements
+ENS / ..." qui est un peu mis de manière anarchique dans la base.
+
+#### Compte wiki
+
+Ceci permettrait de lier le compte Cr@ns et le compte Wiki, en permettant
+l'authentification directe via LDAP en gardant le WikiNom associé.
+
+On n'imposerait pas de compte Cr@ns pour le compte Wiki.
+
+#### VLAN Custom
+
+Permettrait de stocker les VLAN a ajouter sur une prise pour la DSI... On va
+stocker ça dans annuaire.py.
+
+### Modules de détection de mouvements
+
+Il faut des paires de mains pour peupler les cartes. Ça serait à commencer à la
+fin de la semaine prochaine (mercredi ou jeudi), et à finir avant dimanche
+prochain.
+
+### Questions diverses
+
+N/A
diff --git a/compte_rendus/2010_01_14.md b/compte_rendus/2010_01_14.md
new file mode 100644
index 0000000000000000000000000000000000000000..81af30e04e41dcc22bcf12a82a757782e2f1fe2e
--- /dev/null
+++ b/compte_rendus/2010_01_14.md
@@ -0,0 +1,181 @@
+# Réunion Nounous
+
+* Date : Jeudi 14 Janvier 2010
+* Lieu : Pavillon des Jardins
+* Début : 19h40
+* Fin : -- WikiMichou <<DateTime(2010-01-14T22:26:17+0200)>>
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Augustin Parret-Fréaud
+* Jérémie Dimino
+* John-Eric Dufour
+* Michel Blockelet
+* Nicolas Dandrimont
+* Olivier Huber
+* Olivier Iffrig
+* Pierre Chambart
+* Raphaël Cauderlier
+* Stéphane Glondu
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Compte-rendu de l'intervention au bâtiment G
+
+#### État des fibres
+
+La connexion a été rétablie. On a un débit de 930Mb/s.
+On recevra les tests faits par les techniciens plus tard.
+
+#### Configuration des switchs
+
+Il y a un problème avec batg-0. Il a été remis dans sa configuration d'usine
+(sous laquelle il fonctionne).
+
+#### Câblages physiques
+
+Tous les gens qui ont demandé la connexion Cr@ns l'ont eue.
+
+Il faudra câbler physiquement les gens quand la connexion Crous sera dans tous
+les bâtiments. Pour l'instant c'est les nounous qui le font le soir.
+Ça reste comme ça tant que c'est gérable.
+
+#### Rangement des locaux
+
+Il aura lieu samedi à 14h.
+
+### Problèmes récurrents / maintenances
+
+#### IMAP
+
+L'imap chie dans la colle. On ne sait pas pourquoi. Apparemment le DomU swappe
+beaucoup. On lui rajoute un giga de ram et on voit si ça va mieux...
+
+Récemment des homes n'étaient pas créés. Il faut surveiller ça.
+
+#### Impression
+
+Il y a des traces noires de pire en pire sur les impressions, personne
+ne s'en est vraiment occupé.
+
+Jérémie les appelle demain.
+
+#### Proxy
+
+Des gens ont constaté des lenteurs et des erreurs sur le proxy.
+
+Un des problèmes: ipv6 sur sable qui se choppe des annonces bizarres.
+En les retirant ça marche mieux. Le souci était le DNS, qui vient faire des
+requêtes d'adresses AAAA sur des serveurs racine en ipv6... *boom*
+
+#### bata-3
+
+[[http://munin.crans.org/switchs.crans.org/bata3.adm-ping_bata_3_adm.html|Chie]]
+
+#### Bâtiment H ?
+
+Il faudrait revenir vers les gens pour être sûrs que c'était bien le problème de
+proxy...
+
+### Évolution des services
+
+#### Intranet
+
+Un nouvel intranet a commencé à voir le jour.
+Il est disponible sur https://intranet2.crans.org (pour l'instant, il n'y a que
+la gestion du câblage des prises).
+
+C'est sur o2, dans /usr/local/django/intranet (dépôt darcs)
+
+Il ne reste plus qu'à développer des applications...
+
+#### Modifications de la base LDAP
+
+* Remaniement des ACLs
+ * Autorisation de la connexion des adhérents avec leur compte Cr@ns
+ * Autorisation de la modification d'attributs dans le sous-arbre des
+ adhérents
+* Modification des attributs
+ * IPv6
+ * Adresse IP : L'adresse IP(v4,6) d'une machine est calculée par le mid,
+ il y aura un champ "adresse IPv6 custom en plus" pour les machines ne
+ respectant pas la convention (voir
+ le [[CransTechnique/PlanAdressage#Machines|plan d'adressage]] sur le
+ wiki, les scripts ne sont pas encore adaptés (en cours par Stéphane))
+ * Cleanup Type de connexion : chaîne de caractères dans adherent
+ * adhérent gratuit/payant/personnel ENS/autres
+ * la base n'est pas encore peuplée
+ * Compte Wiki : chaîne dans le compte crans
+ * mailInvalide : timestamp dans adherent (au lieu d'un booléen)
+ * DNS IPv6 : ajout d'un champ booléen (par machine) pour activer le DNS
+ IPv6 pour l'adresse sur le /64 du vlan par défaut.
+ * DNS (crans.eu) : nouvelle arborescence contenant un nom, une adresse et un
+ propriétaire (compte crans).
+ * .crans.eu
+ * .ipv6.crans.eu : sous-arbre spécial de délégations vers les serveurs
+ DNS pour leur /64 ipv6
+
+#### Installation de fz
+
+Il faut le faire. Cf. le tracker.
+
+#### Télévision
+
+* Multiswitch...
+ * Olivier l'installera avant de partir.
+ * Il faut en profiter pour vérifier la qualité de réception, certaines
+ cartes ont des problèmes.
+* Unicast pour diagnostiquer chez les adhérents se plaignant de problèmes de
+ multicast
+* Transcoding pour faire de la télé over WiFi : à tester sur les serveurs de
+ free, faut leur coller une carte TV
+* IPv6 ?
+* Satellite a http://fr.kingofsat.net/pos-28.2E.php : il faut voir avec le
+ CROUS pour la pose d'une nouvelle antenne.
+
+#### DNS
+
+Il faudrait reprendre l'architecture DNS du Cr@ns. En effet, les serveurs DNS
+autoritaires et les serveurs de cache sont les mêmes.
+
+Il faut séparer les serveurs cache et les serveurs autoritaires pour les zones
+Cr@ns.
+
+Serveurs cache :
+
+* sable
+* gordon
+* titanic (patte interne, requêtes DNS des appartements)
+
+Serveurs primaires :
+
+* sila : crans.org, crans.eu, *.in-addr.arpa (filaire), *.ip6.arpa (filaire),
+ wifi.crans.org, *.in-addr.arpa (wifi), *.ip6.arpa (wifi)
+* mdr : tv.crans.org, *.in-addr.arpa (multicast)
+* sila : adm.crans.org, 136.231.10.in-addr.arpa
+
+On fait un miroir des serveurs autoritaires sur :
+
+* ovh (évidemment)
+* freebox (patte externe)
+
+On pourra ajouter du DNSSec plus tard.
+
+#### Wifi
+
+* Achat de nouvelles bornes
+ * On va faire les courses chez landanet
+* Déploiement
+
+### FAI RUBIS
+
+#### Organisation de la réunion Katy Tréca / Cr@ns
+
+Une réunion a été fixée pour le mercredi 20 à 16h, probablement dans le bureau
+de Katy Tréca.
+
+Nicolas mettra le compte-rendu de la réunion Berlinoise en ligne sous peu.
+
+### Questions diverses
diff --git a/compte_rendus/2011_05_05.md b/compte_rendus/2011_05_05.md
new file mode 100644
index 0000000000000000000000000000000000000000..e849d41be713ad8c145efd539e80455102ffb7a8
--- /dev/null
+++ b/compte_rendus/2011_05_05.md
@@ -0,0 +1,137 @@
+# Réunion Nounous
+
+* Date : Jeudi 5 mai 2011
+* Lieu : Salle Condorcet
+* Début : 19h10
+* Fin : 21h01
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Daniel Stan
+* Jérémie Dimino
+* Michel Blockelet
+* Nicolas Dandrimont
+* Sylvain Boilard
+* Valentin Samir
+* Vincent Maioli
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Entrevue avec la DSI
+
+Lundi 9 mai à 14h30 entrevue avec Stuart. Nicolas y va accompagné de Daniel et
+Valentin.
+
+Ordre du jour :
+
+* Gigabit
+* WiFi
+ * Repeuplement du Cournot
+ * Annonce du réseau Cr@ns sur les bornes aruba
+ * Réinstallation de bornes à l'ENS
+* Connexion des Appartements
+* IPv6
+* Peer to peer
+
+### WiFi
+
+#### Mises à jour
+
+Le WiFi doit être remis en état de marche correct pour la rentrée.
+
+* SSID Multiples (n > 2)
+* IPv6
+* WiFi N
+
+Points techniques
+
+* OpenWRT
+* Firmware à jour
+* Firmware "universel" (configuration de la borne par DHCP)
+
+Possibilités :
+
+* Identification par compte Cr@ns, voire double authentification (compte Crans
+ OU compte spécifique wifi)
+
+À faire :
+
+* Mise en place d'une infrastructure de test (vlan séparé, serveur radius
+ séparé sur un domU, ...)
+* Tests de firmwares sur les bornes actuellement en train de prendre la
+ poussière au 2B
+* Achat de nouvelles bornes (soit de tests si les bornes actuelles sont
+ merdiques, soit en série)
+
+Les tests vont commencer quand les gens voudront.
+
+#### Repeuplement du Cournot
+
+Les A0 veulent une borne en C411 (elle y est, il faut juste la router vers le
+réseau Crans).
+
+Il faut demander à la DSI de router le vlan 3 au bon endroit.
+
+#### Fixations des bornes du toit du J
+
+Le feuillard en alu est acheté, il faut trouver les fixations qui n'étaient pas
+dans le même rayon.
+
+Pour l'installation, il faut voir avec Isabelle (du CROUS).
+
+### Connexion appartements
+
+Il y a vraiment des bugs bizarroïdes. Quelques possibilités à évoquer avec
+Stuart :
+
+* Passer les personnels directement sur la connexion Cr@ns. Cela règlerait de
+ manière
+
+avantageuse le problème du monitoring de la connexion.
+
+* Multiplexer n freeboxes. La question : où les mettre, et si free va pas faire
+ la gueule.
+
+Il reste aussi à développer le système de load-balancing. Le point de sortie
+pourrait être une dedibox SC de chez online.net.
+
+On verra ça lundi avec Stuart.
+
+### Mises à jour de serveurs
+
+Vincent a fait une mise à jour (mais d'un serveur qui sert à rien) \o/
+
+Michel s'occupera de pgsql quand il aura la bonne idée de ne pas tomber malade.
+
+fx sera mis à jour quand on migrera les /home.
+
+Rappel : les domU mis à jour sont à migrer sur fz pendant leur mise à jour.
+
+### IPv6
+
+Il serait temps d'activer l'IPv6 de manière globale et automatique.
+
+Ce qui est release critical :
+
+* Filtrage des RA pirates (vieux et fait)
+* Firewall v6 (fait modulo port 80)
+ * Désactiver le proxy transparent pour l'IPv6. On peut revoir à fournir un
+ fichier de configuration de proxy si les gens le souhaitent (oh noes, they
+ will never do it).
+* Adaptation des scripts (de surveillance)
+ * Upload : fait, pas de déconnexion automatique mais le mail de stats est lu
+ tous les jours.
+ * P2P : il faut trouver une solution de level7 filtering compatible IPv6.
+ Pas nécessaire immédiatement
+* DNSv6
+* Configuration de radvd et d'un DHCPv6 pour avoir un peu plus qu'un routeur
+ sur IPv6.
+
+### Questions Diverses
+
+#### Problèmes de Webmail/dovecot
+
+Dovecot avait du mal à cause d'une limite sur le nombre de fichiers ouverts.
+Ça a été réglé en augmentant la limite de fichiers ouverts par root.
diff --git a/compte_rendus/2011_05_19.md b/compte_rendus/2011_05_19.md
new file mode 100644
index 0000000000000000000000000000000000000000..7867808c4016d2319e14cf45db2867dc3725e459
--- /dev/null
+++ b/compte_rendus/2011_05_19.md
@@ -0,0 +1,92 @@
+# Réunion Nounous
+
+* Date : Jeudi 19 mai 2011
+* Lieu : Pavillon des Jardins
+* Début : 19h20
+* Fin : 20h07
+
+## Présents
+
+* Daniel Stan
+* Michel Blockelet
+* Nicolas Dandrimont
+* Sylvain Boilard
+* Valentin Samir
+* Vincent Maioli
+
+## Ordre du jour
+
+### Mises à jour
+
+La mise à jour de fx doit être terminée. Ça sera fait samedi soir.
+
+radius et xmpp ont été mis à jour.
+
+Vincent s'occupera d'ovh d'ici la fin de semaine.
+
+### Intranet 2
+
+Daniel a avancé sur l'interface de gestion des accès. Ça ne sera pas prêt à être
+présenté demain, mais bientôt.
+
+Cahier des charges :
+
+* Enregistrement d'interventions
+* Édition des interventions futures
+* Listing des interventions par local
+
+Voir avec C. Lebailly pour ce qu'ils veulent.
+
+Futur :
+
+* Interfaçage avec les caméras / détecteurs de mouvement
+* Badgeuse ?
+
+### IPv6
+
+Le DNS a été configuré, et un radvd a été mis en place sur komaz.
+
+Ça marche bien sur les systèmes d'exploitation qui n'en ont rien à foutre de la
+vie privée de leurs utilisateurs (et qui gèrent bien IPv6).
+
+Plusieurs possibilités sont envisageables :
+
+* Mise en place d'un DHCPv6
+ * Distribution d'adresses d'autoconfiguration
+* Suppression de la règle droppant les paquets qui font la correspondance
+ MAC - IPv6
+ * La règle qui fait le matching sur les adresses mac existe déjà . Il faut
+ juste garder la correspondance entre les MAC et les IPv6 dans une base de
+ données.
+
+Il faut mettre en place un outil de monitoring, par exemple ndpmon, pour garder
+trace des associations MAC - IPv6.
+
+Il faut évaluer les conséquences de mettre en place le DHCPv6, notamment sur la
+simplicité de configuration.
+
+### WiFi
+
+Ça n'a pas avancé depuis la dernière fois.
+
+### Télévision
+
+On va passer au 4J faire une vérification des branchements.
+
+Pour les nouvelles cartes en USB, des tests ont été faits. Apparemment ça ne
+chauffe pas trop. Il faut maintenant tester avec une sheevaplug.
+
+### Ajouts de droits
+
+Nicolas propose d'ajouter les droits Nounou à Daniel et Valentin.
+
+### Questions diverses
+
+#### Fixations des bornes
+
+Daniel est repassé à Casto et les trucs de fixation ont l'air de suxer. Daniel
+propose une solution alternative, mais qui est vraiment overkill pour seulement
+deux bornes (> 100 euros de tendeur)...
+
+On réévaluera la nécessité de ces bornes quand la couverture intérieure du
+bâtiment G existera.
diff --git a/compte_rendus/2011_09_15.md b/compte_rendus/2011_09_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..dc99a7adf4880103a05e884419d5bd51edf6b42f
--- /dev/null
+++ b/compte_rendus/2011_09_15.md
@@ -0,0 +1,110 @@
+# Réunion Nounous
+
+* Date : Jeudi 15 septembre 2011
+* Lieu : Pavillon des Jardins
+* Début de la réunion : 19h20
+* Fin : 20h06
+
+## Présents
+
+* Aurore Moisy-Mabille
+* Aurore Quelennec
+* Benjamin Aupetit
+* Daniel Stan
+* Louis Bondaz
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Raphael Bonaque
+* Raphael Cauderlier
+* Steven Masfaraud
+* Sylvain Boilard
+* Valentin Samir
+* Vanessa Verbeke
+* Yann Duplouy
+
+## Ordre du jour
+
+Après un tour de table, on entame l'ordre du jour.
+
+### Responsable Technique en Chef
+
+Sur proposition du RTC sortant, le collège des Nounous approuve la nomination
+d'Olivier Iffrig comme nouveau Responsable Technique en Chef.
+
+### Recrutement
+
+Bienvenue aux nouveaux (-;
+Les droits apprenti leurs seront donnés à la fin de la réunion, après un
+discours sur ce que ces droits permettent de faire de mal, et lecture de la
+charte des membres actifs.
+
+### Séminaires
+
+On va tenter de reprendre le rythme précédent d'un séminaire par semaine.
+
+||<tablestyle="text-align: center"> '''Date''' || '''Thème''' || '''Intervenant''' || '''Encadrant''' ||
+|| 4 octobre 2011 || Présentation du réseau
+Cr@ns || WikiIota || NicolasDandrimont ||
+|| 11 octobre 2011 || Réseaux, Ethernet, TCP/IP || WikiLxir || !TotoPassoir ||
+|| || Le Shell, SSH || || WikiB2moo ||
+|| || Administration réseau sous
+Linux || || NicolasDandrimont ||
+|| || Python || || WikiIota ||
+|| || Les scripts du Cr@ns || || ||
+|| || WiFi || || ||
+|| || Firewall || || WikiNit ||
+|| || IPv6 || || NicolasDandrimont ||
+|| || La base LDAP || || ||
+|| || Virtualisation || || ||
+|| || Versionnement || || ||
+|| || Bcfg2 || || ||
+|| || Intranet 2 || || ||
+|| || DNS || || ||
+|| || TV + Multicast || || ||
+|| || GPG || || ||
+|| || Monitoring || || ||
+|| || Wiki || || ||
+
+### WiFi
+
+Une séance de travail est prévue ce samedi 17 septembre à partir de 14h,
+venez au 2B. Les bornes actuelles se font de plus en plus vieilles, on envisage
+différentes bornes, mais elles ont besoin d'un firmware fonctionnel pour pouvoir
+être déployées.
+
+Il faut d'abord considérer la mise à jour des bornes actuelles. "Il y a des
+chances
+que ça n'empire pas la situation."
+
+### Nouvelle interface de gestion "gest_crans"
+
+Olivier entreprend depuis un certain temps une mise à jour de l'outil gest_crans
+qui est le script que les câbleurs utilisent pour effectuer la gestion des
+adhérents.
+
+Une idée envisagée est de passer à une interface client - serveur pour pouvoir
+faire plusieurs front-ends (intranet, script de gros geek, ...)
+
+Olivier envisage de le faire tout simplement en HTTPS, avec un retour des
+données en JSON ou xml...
+
+Valentin propose de faire une séance de travail sur le binding ldap afin de le
+rendre utilisable en conditions réelles. Elle aura lieu le 1er octobre.
+
+### Connexion appartements
+
+Ça marche mal. On a eu deux rapports de problème depuis le début du mois, encore
+non traités. Il faut prendre contact avec les habitants pour tester.
+
+Olivier et Daniel sont volontaires pour s'en charger.
+
+### Questions diverses
+
+#### Configuration automatique du WiFi sous Windows
+
+Valentin est en train d'investiguer netsh afin de proposer un outil automatique
+et graphique de configuration de la connexion WiFi sous Windows (XP, Vista, 7).
+
+L'outil permettrait de configurer automatiquement la connexion WiFi sous ces OS,
+afin de simplifier le câblage des adhérents, et d'éviter les retours et la
+dégradation de l'expérience de câblage.
diff --git a/compte_rendus/2011_09_29.md b/compte_rendus/2011_09_29.md
new file mode 100644
index 0000000000000000000000000000000000000000..61217f357562350ff3b0a811f7920432c9b1504f
--- /dev/null
+++ b/compte_rendus/2011_09_29.md
@@ -0,0 +1,98 @@
+# Réunion Nounous
+
+* Date : Jeudi 29 Septembre 2011
+* Lieu : Amphi Condorcet
+* Début de la réunion : 19h21
+* Fin : 20h42
+
+## Présents
+
+* Benjamin Aupetit
+* Benjamin Schmitt
+* Daniel Stan
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Raphaël Cauderlier
+* Steven Masfaraud
+* Sylvain Boilard
+* Valentin Samir
+* Xavier Lagorce
+* Yann Duplouy
+
+## Ordre du jour
+
+### WiFi
+
+Le workshop d'il y a 15 jours a été pas mal productif. On a des firmwares à peu
+près fonctionnels sur les deux types de bornes.
+
+Pour les anciennes WRT54G:
+
+* Multi SSID: impossible
+* Le reste fonctionne (sauf les bornes)
+* IPv6 non testé, pas de raison a priori que ca ne marche pas.
+
+Pour les nouvelles:
+
+* Tout marche, sauf...
+* récupérer de l'entropie sur la borne, car le réseau n'est pas une source sûre
+
+d'entropie, et il n'y a pas d'autres sources disponibles. (urandom ou rng-tools)
+Ce problème est soluble (comme le café), et la mise en place ne devrait donc pas
+poser de problème majeur à partir de là .
+
+Il faut maintenant faire des tests de couverture (genre au G), puis faire des
+devis pour le CA, assez rapidement, et aussi trouver où on peut les poser.
+
+On propose un devis pour le CA de la semaine prochaine afin d'acheter des pico
+et nanostations qui ont le même chipset que les bullet dans un form factor
+vachement plus cool, pour tester.
+
+### Séminaires
+
+Le premier est mardi, les apprentis doivent venir et s'inscrire pour les
+suivants.
+
+### Connexion des appartements
+
+La connexion de la porterie a été rétablie. Le switch a bloupé.
+
+La connexion au cournot est bugguée du côté DSI, selon les diagnostics d'Olivier
+(le vlan 21 sort de multiprise_wifi, et n'arrive manifestement pas au cournot).
+
+Il faut relancer la DSI, Olivier s'en occupe.
+
+### Déconnexion P2P
+
+On a reçu un mail (forwardé) de la DSI nous informant d'un trafic bittorrent
+provenant d'une ip Cr@ns (celle d'un adhérent). Le mail provient d'une société
+américaine.
+
+Les nounous font déjà leur possible pour bloquer le trafic bittorent. Les
+sanctions envers l'adhérent sont à décider par le CA.
+
+### Questions diverses
+
+#### Workshop scripts
+
+La séance prévue Samedi prochain est déplacée au 08/10 pour cause
+d'indisponibilité générale.
+
+#### Association MAC-IPv6
+
+Récupérer les NA ne serait pas optimal pour faire cette association (risque
+d'usurpation), il serait bon de trouver une autre solution ou un colmatage.
+
+On teste le DHCPv6.
+
+#### Bornes du toit du J
+
+Ca fait longtemps que l'on a promis au CROUS de mieux les fixer. On regarde si
+ce sont des habitants du G ou du J qui les utilisent.
+
+#### Workshops
+
+Le format des workshops permet d'avancer sur les services, mais permet-il la
+formation des nouveaux ?
+Daniel propose de lancer des "petits projets" sur des modules de l'intranet 2,
+qui permettent de toucher au LDAP, etc, tout en étant indépendants.
diff --git a/compte_rendus/2011_10_31.md b/compte_rendus/2011_10_31.md
new file mode 100644
index 0000000000000000000000000000000000000000..a577812e1cfe1c01a271420595b83cb7d9e339a4
--- /dev/null
+++ b/compte_rendus/2011_10_31.md
@@ -0,0 +1,190 @@
+# Réunion Nounous
+
+* Date : Jeudi 13 Octobre 2011
+* Lieu : Salle Condorcet
+* Début : 19h14
+* Fin : 21h34
+
+## Présents
+
+* Aurore Quelennec
+* Benjamin Aupetit
+* Daniel Stan
+* Judith Robson
+* Michel Blockelet
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Raphaël Cauderlier
+* Steven Masfaraud
+* Sylvain Boilard
+* Valentin Samir
+* Vanessa Verbeke
+* Xavier Lagorce
+
+## Ordre du jour
+
+### Wifi
+
+#### Nouvelles bornes
+
+Les nouvelles bornes sont arrivées mais (petite) déception: le chipset wifi
+n'est pas le même... Iota a réussi à compiler une image pour ces bornes et Ã
+booter dessus, il n'y a pas de raison que le WiFi ne fonctionne pas. D'ailleurs,
+il y a de l'entropie. Il y en a 3 autres à tester, avis aux volontaires.
+
+Les tests de portée sont à effectuer. Il faut voir si ça passe en ligne droite
+(dans un couloir ?) puis entre les étages (car on a que deux locaux techniques
+au G...)
+
+#### Audit de la couverture actuelle
+
+Il faut parcourir le campus afin de récupérer l'état de la couverture wifi.
+On peut aussi essayer de faire des stats pour voir où les gens se connectent.
+
+Daniel s'occupe de l'extérieur. Raphaël s'occupe de cartographier où les gens
+se connectent. Steven s'occupe de l'intérieur.
+
+#### Bornes sur le toit du bâtiment J
+
+Les bornes sur le toit du bâtiment J et arrosant le bâtiment G n'arrosent pas
+le bâtiment G... En effet, le revêtement des fenêtres empêche la propagation
+des ondes wifi. Des clients sont toutefois connectés sur ces bornes,
+il faudrait donc les laisser.
+
+On ne peut pas les laisser en l'état (car elles sont "mal" accrochées), on a le
+choix entre les fixer correctement, installer d'autres bornes (nanostation ?)
+qui devront elles aussi être fixées correctement, ou ne rien mettre.
+
+On va attendre le résultat des tests de couverture.
+
+#### Détection des réseaux pirates
+
+Il y a deux semaines et demi, un réseau WEP de SSID "Cr@ns" a été détecté sur le
+campus, émis par plusieurs MACs différentes. Le réseau était annoncé moins d'une
+minute à chaque fois.
+
+Raphaël essaie d'utiliser les bornes WiFi afin de détecter l'origine du réseau
+bizarre.
+
+### Workshop Scripts
+
+Il n'a manifestement pas eu lieu. (On a trié des fiches d'adhésion/réadhésion.)
+On fait une première session jeudi 20 octobre pour vérifier le fonctionnement du
+nouveau binding LDAP et corriger les bugs manifestes.
+
+### Proxy
+
+* Caching des vidéos youtube : ce n'est pas possible facilement, il faudrait
+ avoir un serveur Web "cache" à côté. De toute façon, le débit consommé n'est
+ pas forcément si important que ça par rapport au reste du trafic.
+* (null)://toto : parfois, quand on charge une page, il arrive que le proxy
+ retourne une erreur parce qu'elle essaie d'utiliser le protocole "(null)".
+ C'est une erreur a priori liée au proxy transparent. Il faut que quelqu'un
+ prenne ses petits doigts musclés et écrive un bug report.
+* Pages pour les gens déconnectés pour virus : Michel propose que la page de
+ déconnexion apporte plus d'informations notamment quant au virus. Pour ce
+ faire, on pourrait faire une section dans l'intranet où on pourrait mettre
+ les logs de déconnexion et les instructions à suivre pour désinfecter.
+
+### Connexion des appartements de fonction
+
+Le Cournot remarche, Iris ne marche plus.
+Il faut contacter la personne qui rencontre des problèmes afin de savoir ce
+qu'il en est. Il faudrait aussi en profiter pour leur dire de nous contacter
+directement et de nous tenir au courant quand ça refonctionne tout seul.
+On peut profiter de la campagne de réadhésion pour faire ça.
+
+### Impression
+
+Daniel a modifié l'interface d'impression, entre autres pour la rendre plus
+stricte. Elle n'accepte plus les dimensions exotiques, ce afin d'éviter les
+affiches occupant 1/100e de la page.
+
+On va utiliser le biniou d'adg qui se connecte à l'interface d'impression
+directe.
+
+#### Problèmes avec l'imprimante
+
+Il faut contacter print platinium pour
+
+* échanger les rouleaux
+* échanger l'imprimante
+* échanger de partenaire *kof* *kof*
+
+### DHCPv6
+
+Personne ne s'est occupé de tester le DHCPv6. Il est décidé de le configurer en
+utilisant les adresses IP d'autoconfiguration, pour des questions de simplicité
+du firewall.
+
+### Questions diverses
+
+#### Communication
+
+Il faudrait faire, Ã chaque inter-nounou, ''vraiment'' faire un bilan de ce qui
+a été fait. Ça permettrait d'avoir une trace écrite.
+
+Nicolas propose que chacun tienne un journal de bord, afin d'écrire au jour le
+jour ce que chacun a fait au Cr@ns. Ensuite, on fait une synthèse lors des
+internounous.
+
+#### Mises à jour vers squeeze
+
+Il faut continuer. Le support de sécurité de lenny s'arrête en février 2012.
+
+Michel se propose d'encadrer les bonnes âmes voulant s'en charger. Aurore se
+porte volontaire.
+
+#### Install-party
+
+L'install-party campus aura lieu le 19 novembre. La vraie aura lieu le 14
+janvier.
+
+Il faut que quelqu'un pense à mettre à jour le netboot avant l'install-party (et
+non pendant...).
+
+On peut graver des CD d'Ubuntu.
+
+#### Réunion avec la DSI
+
+Il faut prévoir rapidement une réunion avec la DSI, pour parler de :
+
+* Gigabit
+* Connexion des appartements
+* Rationnalisation de la connexion Cr@ns-ENS
+* WiFi
+
+Le RTC est volontaire.
+
+#### Inondation, comment redémarrer les serveurs
+
+Premier problème : les nounous ne savent pas dans quel ordre redémarrer les
+serveurs. Deuxième problème : même avec une nounou qui sait dans quel ordre
+redémarrer les serveurs, un redémarrage prend une bonne heure, alors qu'il
+pourrait être beaucoup plus rapide.
+
+Un ordre de redémarrage des serveurs doit être écrit, rapidement.
+
+Une solution plus pérenne serait de décrire les dépendances entre services dans
+un init script lancé très tôt et qui attendrait de pouvoir se connecter aux
+services en question avant de continuer le boot. Un script de la même espèce que
+"attendre-vert", mais 2.0.
+
+Une autre solution serait de faire un "maître d'orchestre" qui autorise les
+serveurs à booter séquentiellement.
+
+Judith se porte volontaire.
+
+#### Comment éviter les problèmes à base de 0.0.0.0
+
+Un adhérent a décidé de mettre une adresse ip 0.0.0.0, ce qui a beaucoup
+perturbé la détection de conflits d'adresse ip de windows.
+
+Michel voudrait qu'une adresse ip bidon soit mise en place, qui n'est pas
+vraiment
+utilisée, et qui soit utilisée pour détecter des comportements bizarres :
+
+* Si une machine répond aux requêtes ARP pour cette machine, elle se comporte
+ bizarrement
+* Si une machine essaie de se connecter à l'ip bidon, la machine se comporte
+ bizarrement
diff --git a/compte_rendus/2011_11_03.md b/compte_rendus/2011_11_03.md
new file mode 100644
index 0000000000000000000000000000000000000000..642a0d96a768f39ea085ed4be9114977253117bb
--- /dev/null
+++ b/compte_rendus/2011_11_03.md
@@ -0,0 +1,176 @@
+# Réunion Nounous
+
+* Date : Jeudi 3 novembre 2011
+* Lieu : Pavillon des Jardins
+* Début : 19h19
+* Fin : 21h08
+
+## Présents
+
+* Daniel Stan
+* Michel Blockelet
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Raphaël Cauderlier
+* Steven Masfaraud
+* Valentin Samir
+* Vanessa Verbeke
+* Vincent Maïoli
+* Xavier Lagorce
+* Yann Duplouy
+
+## Ordre du jour
+
+### Encadrement des apprentis
+
+Selon le règlement intérieur du Cr@ns, chaque apprenti doit avoir une Nounou qui
+l'encadre et qui est responsable de lui.
+
+Les absents ayant toujours tort, on va assigner des encadrants de force :
+
+* Benjamin A. sera encadré par Nicolas D.
+* Julien sera encadré par Raphaël
+* Sylvain sera encadré par Olivier
+* Yann sera encadré par Valentin
+* Johan sera encadré par Michel
+* Jonathan sera encadré par Raphaël
+* Vincent L.G. sera encadré par Daniel
+* Steven sera encadré par Nicolas D.
+* Aurore MM. sera encadré par Raphaël
+* Luc sera encadré par Vincent M.
+* Aurore Q. sera encadrée par Michel
+* Judith sera encadrée par Michel
+* Vanessa sera encadrée par Xavier
+* Larissa sera encadrée par Olivier
+* Pierre-Elliott sera encadré par Daniel
+
+### STEF
+
+Un représentant du STEF est venu il y a 2 semaines à la réunion CA pour proposer
+au Cr@ns de participer à leur cycle de séminaires en faisant une présentation,
+par exemple sur le logiciel libre.
+
+Il n'y a pas de volontaires.
+
+### Astreintes des nounous
+
+Chaque jour ouvré, les Nounous sont d'astreinte pour aider les câbleurs en cas
+de problème. On a fini de remplir le planning de permanences.
+
+### Munin
+
+Dyson a été mis à jour vers squeeze grâce à Vincent et Sylvain. La config de
+munin a été copiée sur Dyson, qui a fonctionné 24h avant de planter...
+Apparement, cela ne marchait pas beaucoup plus vite (problème de config ?) que
+sur le DomU.
+
+On peut regarder soit du côté de munin 2 qui serait plus efficace, soit on peut
+essayer de reprendre à zéro, en prenant peut-être un autre outil de monitoring.
+
+### Recrudescence du peer-to-peer
+
+On a reçu ces derniers temps plusieurs mails de la DSI à propos de machines
+faisant du p2p, ce qui a mis en évidence un problème au niveau du firewall, dû Ã
+deux problèmes : la partition de /var/log était plein, ce qui empêchait les
+scripts de voir qui fait du p2p; et au niveau du firewall, les paquets n'étaient
+pas bloqués.
+
+Pour ce qui s'agit des logs du syslog refiltrés derrière, on réfléchit à une
+solution pour ne pas avoir à écrire des logs.
+
+Olivier s'occupe d'envoyer un mail à la DSI.
+
+### WiFi
+
+#### Audit de la couverture
+
+Raphaël et Steven se sont baladés dans le bâtiment B pour chercher les zones
+d'ombre. C'est surtout à l'aile du 3e étage que la couverture est mauvaise.
+
+Daniel a commencé à coder une interface en Open Layers pour afficher et
+enregistrer les données de couverture.
+
+#### Mise à jour des bornes
+
+Nicolas a fait un firmware à jour qui fonctionne pour les anciennes bornes, et
+qui règle le problème du cache des authentifications ratées. Il faudrait le
+déployer sur toutes les bornes.
+
+#### Configuration automatique des bornes
+
+Avant, les bornes récupéraient automatiquement leur configuration. On peut
+profiter de la mise à jour à faire pour se pencher sur le sujet.
+
+### Script de détection des déménagements
+
+/usr/scripts/surveillance/demenagement.py à remettre en marche sur les serveurs
+radius.
+
+### Choses à faire au Cr@ns
+
+Il y a plein de choses à faire au Cr@ns, et les jeunes ne se motivent pas trop
+pour se pencher dessus, parfois par manque de connaissances.
+
+Olivier propose de faire une liste des choses à faire sous forme d'arbre. Ça
+rejoint l'idée de faire un recensement de tous les services sur chacun des
+serveurs.
+
+Les choses à faire ne sont pas forcément de nouveaux services à mettre en place,
+mais aussi des petits problèmes au jour le jour à régler, ce qui est souvent
+fait par les mêmes personnes. Il faudrait que les plus jeunes se sentent plus
+impliqués.
+
+Le problème du tracker est qu'il est trop complexe, et accessible principalement
+par l'interface web, et aussi par mail. Nicolas propose d'utiliser debbugs.
+
+Ça peut aussi être bien d'avoir un bot IRC permettant de signaler facilement via
+IRC les bugs (et d'enregistrer les dernières lignes).
+
+Bug n°2 : Il faudrait mettre à jour l'ensemble des documentations disponibles
+sur le Wiki.
+
+Par ailleurs, pour les gros projets, il faut que les apprentis soient mieux
+encadrés, quitte à ce que la Nounou s'implique dans le projet et y participe.
+
+### DHCPv6
+
+Sylvain s'est penché sur la question, et n'a trouvé aucun serveur DHCPv6 qui
+fasse de l'EUI64 (ce qui paraît logique en soi). Deux solutions sont possibles :
+
+* Générer un fichier de configuration statique, comme pour l'IPv4
+* Recoder un serveur DHCPv6, qui filtre les machines à qui elle donne des IPs
+ (cette solution est celle préconisée par Sylvain)
+
+### Utilisation du 2B
+
+On a constaté qu'au 2B, il y a souvent du monde, mais très peu de productivité
+dans l'air. L'idée est d'établir des règles. Dans un premier temps, on va en
+discuter, et les appliquer si nécessaire.
+
+L'idée est néanmoins de poser des "grands principes" par écrit, et de voir si la
+situation s'améliore. On pourrait passer aux règles si aucune amélioration n'est
+constatée, mais ce n'est pas la première chose à faire.
+
+Les afficher au 2B en A4 quelque part.
+
+On veut garder le 2B dans un état propre (tout est relatif)... pas trop sale.
+
+On va écrire des grands principes d'utilisation du 2B, deadline : la prochaine
+inter-nounous.
+
+### Workshop Scripts
+
+Il n'a pas vraiment eu lieu, mais des gens se sont penchés sur les scripts.
+Vincent a commencé à documenter les scripts. Valentin s'est penché sur la base
+LDAP, d'une part pour l'optimisation des méthodes qui prennent du temps, et
+d'autre part sur la cohérence des données entre la base réelle et les checks
+faits par le binding. Les commits sont sur git.crans.org .
+
+### Questions diverses
+
+#### Séminaire OCaml / Ocsigen
+
+Dr. Chicco a proposé d'organiser un séminaire sur OCaml et Ocsigen, et voulait
+savoir si il y avait des personnes intéressées. On peut voir pour en faire un
+(ou plusieurs) séminaire(s) "grand public", de même qu'avec LaTeX, etc. À faire
+de préférence avant les départs en stage.
diff --git a/compte_rendus/2011_11_17.md b/compte_rendus/2011_11_17.md
new file mode 100644
index 0000000000000000000000000000000000000000..98cd7385a155d384701b8bf50510972c028c23e1
--- /dev/null
+++ b/compte_rendus/2011_11_17.md
@@ -0,0 +1,168 @@
+# Réunion Nounous
+
+* Date : Jeudi 17 novembre 2011
+* Lieu : Pavillon des Jardins
+* Début : 19h08
+* Fin : 20h50
+
+## Présents
+
+* Anne Cazalet
+* Aurore Moisy-Mabille
+* Benjamin Aupetit
+* Daniel Stan
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Steven Masfaraud
+* Sylvain Boilard
+* Valentin Samir
+* Vanessa Verbeke
+* Xavier Lagorce
+* Yann Duplouy
+
+## Ordre du jour
+
+### Synaps System
+
+Anne Cazalet est présente pour rencontrer la nouvelle équipe (RTC, bureau).
+On en profite pour discuter des prochains investissements de l'association en
+termes de matériel (remplacement de la caméra du 0B, renouvellement des
+garanties,
+renouvellement du backbone, ...)
+
+### Câblage des chambres
+
+#### Prises défectueuses
+
+Plusieurs chambres du campus (environ 3) ont des problèmes matériels de câblage
+(prises arrachées, ...). En dehors de la question de ce que le Cr@ns doit faire
+à ce propos, il reste que des adhérents n'ont pas de connexion (et le Crous ne
+le fera pas), et il s'agit de petits travaux. Il est plus agréable de le faire Ã
+2 personnes, et c'est réalisable par des apprentis/câbleurs/...
+
+#### Câblage vers le CROUS
+
+Daniel a été contacté directement par MyStream Mardi pour des soucis de câblage
+des clients MyStream, qui n'étaient pas branchés sur les bons switchs : il ne
+faudrait pas les câbler sur les switchs marqués "Master". Ceci n'étant écrit
+nulle part, Daniel a demandé un plan de brassage pour chaque bâtiment. Il a
+aussi demandé s'il était possible d'éteindre les switchs non utilisés (problème
+de ventilation au M par exemple). Une réponse était annoncée pour Mercredi, il
+n'y a toujours rien.
+
+### WiFi
+
+C'est l'occasion de faire un point.
+Olivier indique que tout semble marcher a priori, mais qu'une batterie de tests
+est à faire pour s'en assurer. Il faut aussi les configurer totalement pour les
+adapter au réseau Cr@ns.
+
+Daniel a réussi a flasher des anciennes bornes marquées comme HS, elles
+marchaient. Puis elles ne marchaient plus. Il recherche.
+
+### Séminaires
+
+Nicolas se demande comment améliorer/remplacer de façon bénéfique les
+séminaires. Il soulève le problème de l'attention du public en séminaire.
+Question ouverte.
+
+### Apprentis
+
+Il est proposé la mise en place d'une liste des compétences nécessaires au bon
+exercice de la fonction de nounou (administration système, réseau, ...).
+
+Cette liste sera mise en place collégialement et classée par ordre de pertinence
+par la suite.
+
+### Proxy
+
+Après une rapide étude, Squid semble n'être pas très utile.
+
+* logging: ca marche, mais on peut le faire ailleurs
+* mise en cache: ce serait bien, mais c'est pas extraordinaire
+* deconnexion soft: il suffit de mettre une regle dans le firewall pour
+ rediriger les adherents vers une page de l'intranet
+* ca complique la QoS: c'est pour ça qu'il faut le brûler
+
+Daniel demande des nombres pour finir de juger de l'utilité de Squid.
+Nicolas fait remarquer qu'empiriquement, ça marche mieux quand Squid est down.
+
+Valentin s'en occupe.
+
+### Firewall Ipv6
+
+ip6tables-restore v1.4.8: Couldn't load
+target `BLACKLIST_SRC':/lib/xtables/libip6t_BLACKLIST_SRC.so: cannot open
+shared object file: No such file or directory
+
+On ne sait pas qui brûler. Le script qui génère le firewall va être remis à son
+état précédent grâce à darcs par Daniel.
+
+### Réunion avec la DSI
+
+Hier a eu lieu une réunion avec Stuart, Daniel, Valentin, Olivier, Sabrina,
+Vincent M. Stuart a présenté les prochains projets de l'école (renouvellement de
+matériel, ..., virer IRTS à long terme).
+
+Stuart va demander un devis à Orange pour laisser au personnel le choix entre le
+Cr@ns et Orange, car la qualité n'est pas suffisante à son goût.
+
+Stuart a contourné le sujet du Gigabit.
+
+Il a été question du traffic shaping. Il faut tester ça sur le réseau du Cr@ns
+pour démontrer à la DSI que l'on peut le faire nous même et qu'IRTS est donc
+inutile.
+
+On est censé pouvoir acceder à l'interface de demande de travaux. C'est Ã
+tester.
+
+### Questions diverses
+
+#### Vlan accueil
+
+Daniel propose que l'intranet soit accessible depuis le vlan accueil, pour que
+l'adherent puisse ajouter lui même sa nouvelle machine.
+
+#### Switchs
+
+Les switchs ne sont pas à l'heure, c'est donc que le serveur NTP est mal
+indiqué.
+Il faut réparer ça.
+
+Il existe une pile de switchs garantis à vie qui sont HS, à côté de vo. Il faut
+les mettre à jour et contacter HP pour les faire remplacer. Pour cela, il faut
+prévoir une journée.
+
+Benjamin s'en occupe.
+
+#### Install-Party
+
+Le boot PXE est à jour.
+
+L'IP est après-demain, venez !
+
+#### Mise à jour des bornes
+
+Daniel a testé l'image compilée par Nicolas avec backfire et le driver libre,
+pour les linksys : ca à l'air de bien marcher. Comme les nouvelles bornes, il
+faut finir de les configurer et les tester.
+
+C'est l'occasion de déployer un système pour que les bornes récupèrent leur
+configuration toutes seules, rebootent régulièrement et se mettent à l'heure.
+
+Daniel propose aussi que les bornes arrêtent de diffuser le SSID Cr@ns quand
+elles n'ont pas de réseau et qu'elles diffusent à la place un SSID de debug
+pour qu'on puisse encore s'y connecter.
+
+#### Imprimante
+
+Michel a tenté de les contacter Mercredi pour qu'un technicien passe, mais il
+n'a eu aucun interlocuteur.
+
+On peut leur demander de changer l'imprimante car cela fait 2 ans et demi qu'on
+l'a. Il faut voir si c'est utile.
+
+Le rouleau des feuilles A3 pose problème, il faudrait demander à ce qu'il soit
+changé.
diff --git a/compte_rendus/2011_12_01.md b/compte_rendus/2011_12_01.md
new file mode 100644
index 0000000000000000000000000000000000000000..66b322f57e3304077bfe95c9f3849e45f1b67391
--- /dev/null
+++ b/compte_rendus/2011_12_01.md
@@ -0,0 +1,136 @@
+# Réunion Nounous
+
+* Date : Jeudi 1er Decembre 2011
+* Lieu : Pavillon des Jardins
+* Début : 19h17
+* Fin : 20h27
+
+## Présents
+
+* Benjamin Aupetit
+* Daniel Stan
+* Michel Blockelet
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Sylvain Boilard
+* Valentin Samir
+* Xavier Lagorce
+* Yann Duplouy
+
+## Ordre du jour
+
+### DSI-Cr@ns
+
+#### Connexion des appartements
+
+La DSI a rebasculé la connexion des appartements de fonction vers la connexion
+Cr@ns, après l'avoir mise sur la connexion publique ENS sans nous prévenir.
+
+#### Lien Gigabit
+
+Il faut négocier avec la DSI pour avoir un lien Gigabit rapidement. Cela
+permettrait
+un accès plus rapide aux ENT.
+
+#### Chambres au Pavillon des Jardins
+
+La DSI nous demande si c'est possible de câbler certaines chambres du PdJ sur le
+réseau public de l'ENS. Il faut demander à la DSI pourquoi, sachant que les
+visiteurs
+en question (chercheurs, ...) ont toujours été connectés grâcieusement au réseau
+du Cr@ns si leur durée de séjour était raisonnable (<= 1 mois en général).
+
+#### Plans du réseau
+
+Il faut demander à la DSI une interconnexion rationnelle (i.e. une seule fibre
+et pas 2 dont une reliée à un switch quelconque au d'Alembert Centre).
+
+Le plan du réseau du Cr@ns n'a pas été mis à jour suite à la mise en étoile des
+bâtiments. Daniel va s'en occuper.
+
+### Maintenance générale
+
+#### Mise à jour vers squeeze
+
+Il ne reste plus que quelques serveurs à mettre à jour, il faut le faire.
+Michel va voir avec Aurore pour finir ça.
+
+#### Bcfg2
+
+Plein de fichiers de config sont désynchronisés avec le serveur Bcfg2.
+
+Il faut remotiver les gens à mettre la config dans bcfg2 et pas sur chaque
+serveur, et aussi à packager des trucs existants :
+
+* {{{/etc/cron.d/CRANS}}}
+* {{{/etc/init.d/purge_les_locks_nfs_connard}}}
+* ...?
+
+#### Scripts
+
+Le nouveau binding ldap est utilisable a priori. Il est possible de s'en servir
+pour écrire de nouveaux scripts, ou nettoyer des scripts existants.
+
+#### Divers
+
+### Monitoring
+
+#### Monitoring des serveurs
+
+Munin ne marche toujours pas. La situation n'a pas évolué depuis la dernière
+réunion, il faut que quelqu'un prenne ses petits pieds et aille au 0B appuyer
+sur un bouton pour redémarrer dyson. Daniel s'en charge.
+
+#### Utilisation du réseau
+
+It's over 9000%.
+Nicolas a
+fait [[http://perso.crans.org/dandrimont/weathermap/weathermap.png|une
+weathermap qui marche]]
+avec MRTG. MRTG récupère les données en SNMP sur komaz et le backbone toutes les
+5 minutes et les met dans un fichier pour munin, et un script PHP dessine le
+graphe.
+
+Benjamin se propose pour rendre tout ça plus joli et plus complet (switchs dans
+les bâtiments, ...).
+
+#### Firewall
+
+Valentin a fait plein de modifications sur le firewall dernièrement. En faisant
+des modifications pour détecter les trackers bittorrent en http, il s'est rendu
+compte que le filtre ipp2p n'était pas utilisé correctement (les paquets
+détectés
+sont en effet assez souvent dans des paquets au cours de connexion et pas dans
+les paquets d'initiation). Le filtre a été mis au bon endroit et plus de gens
+ont été déconnectés.
+
+### Questions diverses
+
+#### P2P
+
+Utilisation de OpenDPI à la place de ipp2p. La documentation est très éparse.
+On regarde si ca vaut le coup.
+
+#### Formation interne
+
+La liste de compétences suggérée la semaine dernière doit toujours être mise en
+place. Il est décidé de faire cela collégialement sur gobby (fichier
+"competences").
+
+Les nounous et anciennes nounous sont vivement incitées à contribuer à ce
+document.
+
+#### Squid
+
+Squid est maintenant bypassé sur sable, hormis pour les déconnexions soft. Il
+reste ce problème, ainsi que la connexion de secours qui ne fonctionne plus
+automatiquement.
+
+#### Repas Federez
+
+C'est Samedi, 12h30, venez.
+
+#### Imprimante
+
+Pas d'avancées depuis 15 jours...
+Elle fait des traces moches, ça devient urgent de changer les tambours.
diff --git a/compte_rendus/2011_12_15.md b/compte_rendus/2011_12_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..842a8ca7815594a40508a4f2f25feb3a379444ec
--- /dev/null
+++ b/compte_rendus/2011_12_15.md
@@ -0,0 +1,196 @@
+# Réunion Nounous
+
+* Date : Jeudi 15 Décembre 2011
+* Lieu : Pavillon des Jardins
+* Début : 19h16
+* Fin : 20h51
+
+## Présents
+
+* Antoine Durand-Gasselin
+* Benjamin Aupetit
+* Daniel Stan
+* Melissa Verbeke
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Steven Masfaraud
+* Sylvain Boilard
+* Valentin Samir
+* Vanessa Verbeke
+
+## Ordre du jour
+
+### DSI-Cr@ns
+
+Augustin et Olivier ont eu une réunion avec Sabrina Louison-François de la DSI,
+pour prévoir la simplification de l'interconnexion entre le réseau du Cr@ns et
+le réseau de l'ENS.
+
+Cette opération aura lieu en semaine 52, a priori le 30/12. Daniel et Nicolas
+seront
+présents.
+
+L'interconnexion retenue sera faite à l'aide d'un switch du côté ENS,
+interconnecté
+au backbone par l'actuelle fibre komaz<->irts. Cette connexion sera en gigabit,
+et fera passer les vlan 3 (wifi), 4 (wifi
+ens), 10 (évènementiel), 21 (appartements)
+et le vlan des serveurs DSI, auquel komaz pourra accéder. L'interconnexion avec
+le réseau de l'ens sera assurée via le nouveau switch bato-1.
+
+L'actuelle fibre Multiprise_wifi<->D'Alembert-Centre serait alors inutilisée.
+
+### Achat de matériel
+
+#### Carte contrôleur baie de disques
+
+La baie de disque étant un élément central de l'infrastructure du Cr@ns, il a
+été
+proposé lors de la dernière réunion d'investir dans une carte de contrôle
+supplémentaire.
+
+La carte de contrôle actuelle étant bientôt en fin de vie, deux solutions
+s'offrent à nous :
+
+* Acheter une nouvelle carte identique à l'actuelle
+* Ou acheter deux nouvelles cartes, récentes (garantie 3 ans au maximum)
+
+Une décision raisonnable ne pourra être prise que lorsque les coûts des deux
+options auront été estimés.
+
+#### Renouvellement du backbone
+
+Notre backbone se fait vieux (2003). Anne nous proposera une offre dans le
+courant
+de la semaine prochaine. Une reprise de l'ancien est possible pour diminuer le
+coût du changement.
+
+### Monitoring
+
+Munin "refonctionne". Le graphing se traine le cul.
+
+Il faut évaluer munin-2, qui serait apparemment over 9000 fois mieux que la
+version
+1.4 (CGI et graphing plus rapide, récupération des données plus légère, ...).
+
+Une possibilité toujours en l'air est d'installer un outil du type de nagios,
+qui permettrait de regrouper en un coup d'oeil autostatus, monit et munin.
+Olivier
+propose d'encadrer ce projet. Vanessa est volontaire.
+
+### Serveurs
+
+#### Running gag : rouge
+
+L'age de rouge est strictement croissant. Sa seule fonctionnalité pertinente est
+MX principal. Il y a du filtrage de contenu (amavis) et un serveur
+smtp (postfix).
+
+Ces services devaient être migrés sur redisdead, mais les nounous ont peur que
+la charge due à amavis le fasse s'écrouler.
+
+Étapes de la migration :
+
+* Configurer amavis sur redisdead
+* Configurer l'authentification des clients
+* Vérifier que tout ça tient la charge
+* Modifier les DNS
+* Jeter rouge du 6B
+
+#### Mises à jour vers squeeze
+
+La fin de vie de lenny aura lieu, comme à chaque release de Debian, un an après
+la release de squeeze... Soit le 6 février 2012.
+
+Il reste à migrer zamok, gordon et 3 domU (titanic, ldap, niomniom). Ceci en
+supposant
+que le point précédent, qui n'a été attribué à personne, va s'effectuer par
+magie.
+
+##### niomniom
+
+adg se propose pour encadrer la mise à jour du wiki. Steven se porte volontaire.
+
+##### "vert"
+
+La mise à jour de LDAP va être passionnante : la conversion automatique vers le
+nouveau format de configuration fonctionne de manière quantique.
+
+Le nouveau format de configuration est en fait un annuaire LDAP, ce qui permet
+la modification et la synchronisation sans downtime des configurations et
+schémas.
+L'ancien format de configuration en fichiers plats n'est plus disponible dans la
+version squeeze de slapd.
+
+À prendre en compte avant de faire la mise à jour :
+
+* éviter que les mails ne bouncent à cause d'un utilisateur
+ inexistant (soft_bounce = yes dans la configuration de postfix)
+* s'assurer que tous les services arrivent toujours à se connecter à la base
+ ldap (postfix, dovecot, intranet, authentification...)
+* s'assurer du bon fonctionnement de la réplication
+
+Il y a une config de réplicat correcte sur sable, il est envisageable de la
+convertir en config de master pour l'utiliser sur vert sans trop de dommages.
+
+##### titanic
+
+Deux points importants :
+
+* connexion des appartements
+* connexion de secours
+
+Ces deux services étant morts actuellement, faire la mise à jour de titanic ne
+devrait
+pas avoir trop d'impact...
+
+##### gordon
+
+Cf. plus bas.
+
+### Maintenance générale
+
+Le RTC se porte volontaire pour améliorer la configuration de logcheck, afin
+qu'il
+reçoive plus de mails avec des logs et moins de mails d'erreur.
+
+Il est évoqué la possibilité de mettre en place un serveur syslog centralisé.
+Avant de se lancer là dessus, il faut planifier proprement comment seront
+stockés
+les logs. Il faut aussi penser à la durée de rétention des logs...
+
+### WiFi
+
+Les mises à jour des bornes vers backfire ont été faites. Il faut mettre à jour
+gordon. Cela permettra aussi d'utiliser les nouvelles fonctionnalités de
+freeradius,
+en particulier les possibilités de logging (client<->borne etc.).
+
+Cette mise à jour doit être faite avec le plus grand soin, car la config de
+freeradius
+est une bête poilue, surtout pour le wifi, avec une configuration pour les
+postes
+linux et une pour les clients windows.
+
+Les nouvelles bornes reçues (pico/nano)station fonctionneraient out of the
+box...
+Les gens ayant testé ça mardi ont eu la flemme de faire make, parce qu'ils
+avaient
+faim et/ou soif. iota propose de s'en occuper après la réunion.
+
+### Ajout de droits
+
+nounous.append("Sylvain")
+commit()
+
+### Questions diverses
+
+#### Vacances
+
+Remplissez la page idoine, merci. Il faut des clés du 0B proches du campus Ã
+tout
+moment.
+
+#### Mises à jour de switchs Gigabit
+
+Benjamin est volontaire.
diff --git a/compte_rendus/2012_01_12.md b/compte_rendus/2012_01_12.md
new file mode 100644
index 0000000000000000000000000000000000000000..30904ae0fb89dc1c7a0f5a320cf98674694240c4
--- /dev/null
+++ b/compte_rendus/2012_01_12.md
@@ -0,0 +1,140 @@
+# Réunion Nounous
+
+* Date : Jeudi 12 Janvier 2012
+* Lieu : Pavillon des Jardins
+* Début : 19h20
+* Fin : 21h01
+
+## Présents
+
+* Daniel Stan
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Raphaël Cauderlier
+* Sylvain Boilard
+* Valentin Samir
+* Yann Duplouy
+
+## Ordre du jour
+
+### Achat de nouveau matériel
+
+#### Backbone
+
+#### Carte de contrôle pour la baie de disques
+
+### Interconnexion DSI-Cr@ns
+
+La nouvelle interconnexion est en place depuis le 29 décembre. Olivier fait un
+schéma de l'ancienne interconnexion au tableau, avec IRTS.
+
+En résumé :
+
+* Un nouveau switch bato-1 Ã l'autocom, qui fait l'interconnexion entre
+ * le backbone (vlan 1, 2, 3, 4, 10, 21, 1132 - zrt)
+ * le réseau de l'ENS (vlan 3, 4, 10, 21, 1132 - zrt)
+ * le Pavillon des Jardins (vlan 1, 2, 3, 4, 10?, 21)
+ * les appartements de la porterie (vlan 1, 2 - pour bato-1, 21)
+* Nouvelle interconnexion 0B - Autocom: 3 paires de fibre, dont une pour le
+ bâtiment G en direct, une pour bato-1, et une libre (branchée sur bato-1 Ã
+ l'autocom)
+* Suppression de l'interconnexion 0B - d'Alembert Centre qui était foireuse et
+ génératrice de boucles difficiles à débugguer
+
+#### Traffic Shaping
+
+L'agrément RENATER de l'ENS étant pour 100Mb/s, le Cr@ns a mis en place du
+traffic
+shaping pour limiter son débit entrant et sortant.
+
+La QoS est désactivée pour le trafic vers le réseau ENS dans le pare-feu.
+
+Il faut réfléchir à une méthode pour shaper le trafic dynamiquement (n Mb/s la
+journée, p Mb/s la nuit). Valentin propose de modifier config.py pour que le
+débit max dépende de l'heure, et un cron pour régénérer la chaîne MANGLE qui
+assigne les classes au trafic.
+
+Il va mettre le cron en place rapidement, ce qui permettra de toute façon de
+régénérer les classes de QoS de temps en temps. Apparemment il y aurait déjà un
+cron de ce type en place.
+
+### Migration des /home
+
+Les /home ont été migrés aussi le 29 décembre, quitte à avoir une interruption
+de service...
+
+La partition était en place, il suffisait de désactiver les services, un dernier
+rsync et de remplacer la partition dans le fstab.
+
+### Logs
+
+Une partition assez volumineuse vient d'être libérée. Une idée serait de s'en
+servir pour centraliser les logs des serveurs et des domU.
+
+À cette fin, il serait possible de réutiliser un serveur physique inutilisé, par
+exemple ragnarok.
+
+Sylvain regarde ce dont on a besoin précisément d'ici la prochaine réunion.
+
+### Bornes wifi PicoStation
+
+Adg a une config qui devrait marcher. Olivier l'a flashée sur une borne, ça
+fonctionne, il faut attendre assez longtemps que ça reboote.
+
+Reste à faire :
+
+* vlan (pour pouvoir remettre des bornes en zone ENS)
+* multi-ssid
+* tests de portée
+* tests de débit/charge
+
+Sur les wrt54g:
+http://wiki.openwrt.org/_detail/toh/linksys/wrt54_internal_architecture.png?id=toh%3Alinksys%3Awrt54g
+
+Olivier envisage de faire des trucs là dessus samedi.
+
+### Monitoring
+
+Munin a été migré sur dyson il y a quelques temps, la génération des graphes
+est lente, mais fonctionne. Une nouvelle version de munin va sortir (elle est
+en bêta stable depuis un an). La génération des graphes a été optimisée et on
+peut zoomer sur les graphes en temps réel. Le protocole de communiation a aussi
+été amélioré :
+avant, le serveur munin contactait tous les noeuds leur demandant de générer
+les données ; maintenant, les serveurs ont un agent qui génère les données en
+continu. La première phase serait de mettre à jour munin sur le serveur (c'est
+backwards-compatible). Nicolas a fait un backport. Il faut ensuite vérifier si
+ça fonctionne, si c'est rapide.
+
+Si tout ça se passe bien, il y a moyen de faire des trucs marrants sur les
+clients.
+
+### Questions Diverses
+
+#### Load balancing DNS
+
+Valentin propose de configurer le DHCP de telle manière à annoncer
+alternativement sila et sable en serveur DNS.
+
+Il faut mettre en place du monitoring de bind (via munin qui fonctionne, par
+exemple)
+pour voir si c'est vraiment nécessaire.
+
+#### TFTP sur sable
+
+Il faut le mettre sur une partition séparée, pour éviter de remplir le /var de
+sable...
+
+Le proxy transparent ayant été dégagé, plein d'espace disque est disponible.
+Il serait aussi potentiellement intéressant de mettre un RAID. Sinon, Valentin
+se porte volontaire pour faire la réinstall de sable from scratch si un disque
+plante.
+
+#### batp-3
+
+Il est allumé, il ne ventile plus, il clignote rouge. Il faut appeler HP pour
+le faire échanger.
+
+#### Imprimante
+
+Nicolas trouve que Print Platinium est désespérant
diff --git a/compte_rendus/2012_01_26.md b/compte_rendus/2012_01_26.md
new file mode 100644
index 0000000000000000000000000000000000000000..c568982551f45721532e62bea46c350260c4fa8b
--- /dev/null
+++ b/compte_rendus/2012_01_26.md
@@ -0,0 +1,144 @@
+# Réunion Nounous
+
+* Date : Jeudi 26 janvier 2012
+* Lieu : Condorcet
+* Début : 19h16
+* Fin : 20h35
+
+## Présents
+
+* Anne Cazalet
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Steven Masfaraud
+* Sylvain Boilard
+
+###== Présent par internet
+
+### * Aurore Moisy-Mabille
+### * Daniel Stan
+### * Raphaël Cauderlier
+### * Valentin Samir
+### * Vincent Le Gallic
+### * Yann Duplouy
+
+## Ordre du jour
+
+### Achat de matériel
+
+Anne Cazalet nous fait ses propositions sur les éléments que nous avions
+demandé.
+
+#### Imprimante
+
+Anne Cazalet nous propose une imprimante HP CM6030 ou CM6040 en achat comptant,
+et va aussi communiquer nos coordonnées à un prestataire de leasing avec des
+imprimantes Xerox (Alex Panahi), afin que nous puissions comparer les deux
+propositions.
+L'imprimante coûterait environ 9000€ (prix public).
+
+#### Onduleur
+
+L'onduleur est en fin de garantie, Anne va nous envoyer une proposition pour
+la prolonger, c'est à dire ajouter un an + un an, et par la suite envisager de
+passer
+sous un contrat de maintenance pièces - sans batteries - incluses.
+
+#### Carte de contrôle pour la baie de disques
+
+Le contrôleur de la baie de disques est obsolète. On peut éventuellement
+en trouver un reconditionné ou en pièces détachées.
+
+Une autre solution serait de changer le chassis, et d'utiliser des nouveaux
+contrôleurs. Les disques sont heureusement compatibles. Coût public 6550 euros
+contrôleurs inclus (prévoir une remise ~20%), sans prendre en compte un échange
+éventuel (d'après une simulation, environ 600 euros seraient récupérables).
+
+#### Backbone
+
+Pas de proposition mise à jour, nous avions envisagé un chassis 5406, avec deux
+modules
+
+* 12 ports SFP + 12 ports Ethernet 10/100/1000
+* 24 ports 10/100/1000 Ethernet
+
+### Imprimante
+
+Il faudrait se débarrasser de Print Platinium. On pourrait ensuite acheter une
+imprimante ou en louer une selon l'offre qui va nous être proposée.
+
+À considérer :
+
+* Délai d'intervention du technicien
+* Durée du contrat, évidemment
+* Durée de vie des consommables (nb de pages par cartouche)
+* Tarifs si la consommation prévue est dépassée ?
+* Considérations sur le prix des impressions (A4 vs. A3, noir vs. couleur)
+
+Dans tous les cas, il faut relancer le technicien de PP pour le changement des
+tambours... Il faut poker PEB.
+
+### Caméra
+
+La nouvelle caméra a été installée, et l'assureur du CROUS n'envisage pas de
+rembourser l'ancienne, parce qu'apparemment le plastique ne rouille pas quand il
+se fait inonder.
+
+### Serveur de logs
+
+Le disque de ragnarok semble mort, il faut un volontaire pour aller acheter deux
+disques SATA de capacité respectable (≥ 1 To) chez nos amis de Montgallet, afin
+de mettre en place un RAID et de pouvoir voir venir. PEB s'était porté
+volontaire
+sur IRC.
+
+Il faut absolument penser aux backups sur ce serveur. La procédure complète
+d'installation pourra être détaillée sur le wiki.
+
+### Bug tracker
+
+Olivier a fait en sorte que les mails envoyés vers xxx@bugs.crans.org arrivent
+sur le serveur idoine. Il y a manifestement un bug dans la config de postfix.
+
+Il faudrait reprendre la configuration mail qui a été faite pour
+tracker.crans.org, qui fait en sorte que les mails y arrivent.
+
+Il faut définir quels "packages" on met en place, et quels mainteneurs (même si
+juste roots@crans.org semble adapté).
+
+Nicolas envisageait quelque chose du style un package par serveur + un package
+par service important (WiFi, impression, intranet, ...). Olivier est d'accord.
+
+Il y a plusieurs aspects sur lesquels on pourrait travailler:
+
+* Un suivi des mails envoyés par monit, munin, ... pour les transformer en
+ tickets.
+* Un bot IRC pour notifier des bugs, et enregistrer une partie des
+ conversations.
+
+### Séminaires
+
+Vu la grande présence apprentiesque à cette réunion, les séminaires sont
+relancés pour dans 10 jours.
+
+### Bornes Wifi
+
+Il faut que les nouvelles bornes soient déployées le 15 mars. À faire :
+
+* Finalisation de la config
+* Chiffrage et vote pour le budget du projet
+* Déploiement
+
+#### Redémarrage des bornes
+
+Certaines bornes ont besoin d'un redémarrage de temps en temps. On va mettre en
+place un script qui les redémarre une fois par jour, par exemple
+Ã (3 + rand(0, 1))h du matin.
+
+## Questions diverses
+
+### Quid d'un web-nntp
+
+### Nit m'a montré ce qu'il avait fait, c'est cool.
+
+Yann et Valentin ont l'air motivés pour mettre une solution en place.
diff --git a/compte_rendus/2012_02_09.md b/compte_rendus/2012_02_09.md
new file mode 100644
index 0000000000000000000000000000000000000000..0fa0d985201bb3e6424fa6f13ee16c8d7f87dae0
--- /dev/null
+++ b/compte_rendus/2012_02_09.md
@@ -0,0 +1,143 @@
+# Réunion Nounous
+
+* Date : Jeudi 9 février 2012
+* Lieu : Pavillon des Jardins
+* Début : 19h23
+* Fin :21h05
+
+## Présents
+
+* Benjamin Aupetit
+* Daniel Stan
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pierre-Elliott Bécue
+* Raphaël Bonaque
+* Raphaël Cauderlier
+* Steven Masfaraud
+* Sylvain Boilard
+* Valentin Samir
+* Vanessa Verbeke
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Achat de matériel
+
+Le C.A. a accordé le budget nécessaire pour le backbone et la baie de disques.
+La commande a été passée, et les livraisons devraient se faire sous peu. Le
+chassis est un chassis de six modules au lieu de quatre actuellement, il faudra
+donc faire de la place.
+
+### Imprimante
+
+Qualis fait une offre de leasing sur une imprimante Xerox (7535) qui semble
+intéressante.
+Le bac de sortie est vraisemblablement du mauvais coté, ce qui est problématique
+pour accéder aux bacs de chargement. On pourrait faire des travaux pour échanger
+la porte et l'espace de sortie du papier.
+
+Il serait bien aussi d'installer une vraie climatisation, il faut obtenir
+l'autorisation de Lebailly pour pouvoir faire les travaux. Benjamin s'en occupe.
+
+### Mises à jour des serveurs
+
+Youpi ! Gordon est à jour !!
+Il reste à mettre à jour :
+
+* titanic, Vincent s'en charge avec Daniel et Valentin (maj de squid en même
+
+temps pour faire marcher proprement la connexion de secours)
+
+* niomniom, Steven s'en charge avec adg
+* vert, Olivier s'en charge avec Nicolas
+* fy
+* zamok :
+ Le / est trop petit, il faudrait utiliser le deuxième disque dur. On va en
+ profiter pour repartitionner comme il faut. Daniel s'en charge avec Olivier.
+* rouge (s'en débarrasser ?)
+
+### Dyson
+
+Dyson est sous squeeze, il faut que la personne qui l'a mis à jour mette à jour
+bcfg2.
+
+Pierre-Elliott s'occupe de mettre à jour munin avec Nicolas, pour que la
+génération
+des graphes mette moins de deux heures.
+
+### Wifi
+
+Daniel a installé deux bornes au G, elles ne fonctionnent pas pour l'instant,
+il va investiguer.
+
+Daniel a commencé le développement de scripts permettant une connexion SSH de
+masse sur les bornes wifi, afin d'effectuer des déploiements simples (scripts,
+...).
+
+Il faut chiffrer le renouvellement du parc de bornes wifi pour le prochain CA.
+Cela implique de faire des tests de portée, de finir la configuration,
+et de comparer avec les tests de couverture qui ont été faits.
+Olivier et Raphaël vont voir ça ce week-end, appel aux apprentis motivés.
+
+Un dépot opkg va être mirroré sur sila par websync.
+
+### Switchs
+
+PEB a testé les switchs qui sont entreposés au 2B.
+
+Il faut changer bata-3.
+
+Il serait très appréciable que les switchs défectueux soient changés en moins de
+quatre jours, par exemple par les nounous d'astreinte inscrites sur le wiki.
+Daniel et PEB s'en chargent ce soir.
+
+### Séminaires
+
+Les séminaires sont programmés jusqu'à mars.
+
+### Séances de travail
+
+L'objectif est d'avoir un ou deux apprentis encadrés par une ou deux nounous,
+pour réaliser une tâche sur un sujet précis.
+
+#### Wifi
+
+Encadré par Harry et Iota.
+À faire : cf supra.
+
+#### Scripts
+
+Encadré par iota
+
+Pour l'instant : passage des scripts en utf-8-safe, Vincent et Pierre-Elliott
+sont candidats pour se faire victimiser.
+
+#### Maintenance des services
+
+Encadré par iota.
+
+Tâches : Passer en revue tous les mails d'erreurs des divers services.
+
+#### Monitoring
+
+Encadré par Nicolas et Olivier. Victimes : Pierre-Elliott et Vincent.
+
+Première tâche : mise à jour de munin.
+
+#### Intranet 2
+
+À voir à moyen terme.
+Encadré par Daniel et Nicolas.
+
+#### Firewall
+
+Encadré par Valentin
+
+## Questions diverses
+
+### Prêt de matériel pour une LAN
+
+Il y a une soirée jeux vidéo demain, les organisateurs demandent si on peut
+leur prêter du matériel : des câbles et des multiprises. Daniel sera là -bas et
+s'en charge.
diff --git a/compte_rendus/2012_02_23.md b/compte_rendus/2012_02_23.md
new file mode 100644
index 0000000000000000000000000000000000000000..8eca982bc341f493c6cb199a576d498879837f05
--- /dev/null
+++ b/compte_rendus/2012_02_23.md
@@ -0,0 +1,104 @@
+# Réunion Nounous
+
+* Date : Jeudi 23 février 2012
+* Lieu : Pavillon des Jardins
+* Début : 19h20
+* Fin : 20h20
+
+## Présents
+
+* Aurore Moisy-Mabille
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pierre-Elliot Becue
+* Raphaël Cauderlier
+* Sylvain Boilard
+* Valentin Samir
+* Yann Duplouy
+
+## Ordre du jour
+
+### Imprimante
+
+Elle fonctionne, mais n'agrafe pas quand on imprime avec lpr, la syntaxe a
+dû changer.
+PEB va voir ce qu'il en est.
+
+PEB a remis en place la plaque au niveau de la fenêtre, afin d'éviter d'autres
+visiteurs à plumes, il faudrait la fixer de manière un peu plus efficace.
+
+### Wifi
+
+Des tests ont été faits au G et au M. Il faut une borne par couloir au M, et 2
+par étage au G.
+Il faut calculer les longueurs de câble et le nombre total de bornes d'ici jeudi
+prochain.
+
+Vesta est dans la med en ce moment. Certaines personnes ont quelques soucis
+avec.
+
+Daniel a avancé sur la carte des bornes.
+
+### Télévision
+
+Il avait été proposé d'utiliser des cartes ARM pour la TV. Sylvain voudrait
+demander l'avis du CA et des nounous.
+
+[[http://blog.einval.com/2011/09/05]]
+[[http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/62357162/Products/191203]]
+
+Le budget restant sur ce qui avait été voté en CA est de l'ordre de 100 euros.
+
+Il faut évaluer cette solution vs. une solution à base d'un serveur classique.
+Sylvain s'en charge.
+
+### Séminaires
+
+return -ENOAPPRENTIS; Toutefois, PEB prend le sujet monitoring.
+
+### Zamok
+
+La mise à jour a été faite au forceps. Une machine du labo de Drébon pourrait
+nous être offerte, on pourrait en faire le nouveau serveur des adhérents.
+
+### Backbone
+
+Il a été remplacé dans la nuit de vendredi à samedi dernier. Cela a occasionné
+une coupure des services entre 1h30 et 3h. Lors du redémarrage
+des services, l'UDP sur komaz a cordialement décidé de nous chier dans les
+bottes.
+Ce problème n'est toujours pas expliqué ni réglé. Le tunnel IPv6 étant en UDP,
+l'IPv6 est actuellement mort. Il ''faut'' régler le problème rapidement.
+
+Le remplacement s'est fait sans prévention sur les news de la coupure des
+services.
+Le CA va probablement rappeler au collège des responsables techniques que les
+mises à jour de services critiques doivent être annoncées et effectuées Ã
+l'horaire annoncé, ou reportées.
+
+### Planification des séances de travail
+
+Une séance de travail sur le monitoring est prévue ce week-end, probablement
+samedi après-midi. Nicolas, Pierre-Elliott et Vincent Le Gallic y travailleront.
+
+Olivier va organiser des séances de travail sur les scripts, notamment pour
+gérer
+proprement l'encodage et pour utiliser le nouveau binding LDAP. On prévoit une
+séance le 3 ou le 4 mars.
+
+## Mises à jour
+
+### Mise à jour de titanic
+
+La mise à jour de titanic aura lieu dimanche matin, Olivier se charge de
+prévenir
+la DSI, qui informera les personnels.
+
+### Mise à jour de vert (ldap)
+
+La mise à jour sera faite dimanche 4 mars au matin. Tous les services seront
+coupés pendant la mise à jour. Olivier fait l'annonce.
+
+## Questions Diverses
+
+N/A
diff --git a/compte_rendus/2012_03_15.md b/compte_rendus/2012_03_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..580f3dd310df66e788cd1ca86020ebb0b4d29354
--- /dev/null
+++ b/compte_rendus/2012_03_15.md
@@ -0,0 +1,99 @@
+# Réunion Nounous
+
+* Date : Jeudi 15 mars 2012
+* Lieu : Amphithéâtre Tocqueville
+* Début : 19h15
+* Fin : 20h12
+
+## Présents
+
+* Aurore Quelennec
+* Daniel Stan
+* Julien Baste
+* Nicolas Dandrimont
+* Olivier Ιffrig
+* Pierre-Elliott Bécue
+* Sylvain Boilard
+* Valentin Samir
+
+## Ordre du jour
+
+### Séminaires
+
+'On laisse tomber les séminaires après celui sur le monitoring.
+Il serait peut être bien de planifier des séminaires LateX pour janvier de
+l'année prochaîne.
+
+### Wifi
+
+Une !PicoStation M2 HP a été achetée. Elle marche out of the box avec l'image
+pour !NanoStation. Daniel l'a mise à la Kfêt pour la tester en situation réelle.
+On va prendre des {Pico,Nano}Station M2 et quelques !NanoStation M5 pour les
+lieux très fréquentés. Il faut établir un budget à soumettre au CA. Olivier
+s'occupe de ça ce WE, avis aux intéressés.
+
+Valentin a créé un petit exécutable pour implanter les profils wifi sur les
+postes Windows Vista et 7 (et peut-être 8, TODO ce soir). Valentin s'occupe
+d'en faire la pub auprès des câbleurs.
+
+### Intranet
+
+Julien a repris ce qui avait été fait sur l'intranet. On a ouvert un port pour
+qu'il puisse continuer à travailler dessus pendant son stage. Appel aux gens
+motivés pour se joindre à lui.
+
+L'objectif principal est de répliquer la fonctionnalité de l'intranet actuel.
+
+### Mises à jour de serveurs
+
+#### vert
+
+Vert a été mis à jour. Il est possible de mettre à jour les ACL sur la base
+LDAP pour permettre aux utilisateurs de modifier ce qui les concerne, pour
+faire des logs dans la base, ...
+On va commencer à voir ça ce soir.
+
+#### Niomniom
+
+Il faut voir avec adg pour faire ça au plus vite. PEB est volontaire.
+
+#### Zamok
+
+Il faut se débarrasser de zamok, On l'a bien vu ces derniers temps (mis à genoux
+par le driver de l'imprimante). Nicolas propose d'utiliser l'actuel fx pour
+enfin mettre à jour matériellement zamok.
+
+Reste à réfléchir à quel serveur utiliser pour faire le partage NFS. Plusieurs
+choix s'offrent à nous :
+
+* Effectuer les exports NFS depuis le nouveau zamok.
+ * Avantage : simplicité
+ * Inconvénient : si un adhérent fait de la merde, les exports NFS sont perdus
+* Utiliser un serveur actuel pour faire les exports NFS. Les candidats :
+ * Vieux zamok
+ * Un serveur free
+ * Sable ?
+* Investir dans un nouveau serveur pour faire les exports NFS :
+ * Avantage : c'est un serveur neuf...
+ * Inconvénient : c'est un peu cher...
+
+Le vainqueur serait apparemment le serveur free.
+
+L'interaction serveur free <-> nouvelle baie de disques sera testée au 2B avant
+la mise à jour effective.
+
+### Baie de disques
+
+La nouvelle baie de disques est arrivée. On va l'installer en même temps qu'on
+fera la migration de zamok. Ce n'est pas pressé.
+
+### Départs en stage
+
+Il faut que les gens qui partent en stage mettent à jour CransVacances.
+
+### Questions diverses
+
+#### Plan du réseau
+
+Daniel a mis à jour le plan, il faut le vérifier.
+Il faudrait faire un deuxième plan au niveau logique pour montrer les VLANs.
diff --git a/compte_rendus/2012_03_29.md b/compte_rendus/2012_03_29.md
new file mode 100644
index 0000000000000000000000000000000000000000..15d23053f13a61048c511e4bd18dbf276e60951c
--- /dev/null
+++ b/compte_rendus/2012_03_29.md
@@ -0,0 +1,143 @@
+# Réunion Nounous
+
+* Date : Jeudi 29 mars 2012
+* Lieu : Condorcet
+* Début : 19h17
+* Fin : 20h13
+
+## Présents
+
+* Aurore Moisy-Mabille
+* Aurore Quelennec
+* Daniel Stan
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pierre-Elliott Bécue
+* Sylvain Boilard
+* Vanessa Verbeke
+
+## Ordre du jour
+
+### État du 2B
+
+Le 2B a été nettoyé par Morgane et Daniel. Le RTC souhaite que le 2B reste
+dans cet état là . Pour le reste, il faudra lui redonner un coup de propre
+régulièrement.
+
+Le matériel a été rangé (organisation qui invite de nouvelles suggestions)
+
+### Debbugs
+
+Debbugs a été mis en place. Site web: http://bugs.crans.org/ (pour soumettre un
+bug: submit@bugs.crans.org). C'est initialement le tracker de bugs de debian,
+et chaque paquet debian a sa liste de bugs. Comme le crans n'a pas de paquets
+au sens debianesque, on pourrait créer plusieurs "paquets" crans correspondant
+Ã des services. Actuellement, on a un seul paquet "crans".
+
+On pourrait organiser les paquets par services.
+
+Noms ASCII.
+
+* scripts
+* ldap_crans
+* mail
+* firewall
+* intranet (+ impression)
+* intranet2
+* zamok (= accès shell, pages perso)
+* wifi
+* wiki
+* cablage (= prises défectueuses)
+* tele
+* crans (= autres)
+
+#### Possibilités d'évolution
+
+* Bot IRC (création de tickets directement sur irc)
+* Frontend web de soumission utilisable par les adhérents (sur l'intranet2)
+
+### Matériel
+
+#### Wifi
+
+Harry, Daniel et Olivier ont parcouru les bâtiments pour trouver où câbler les
+bornes. Le compte-rendu sera mis sur le wiki à l'occasion. En bref, une pico
+par étage au A, B, C. H, I, J, dans les locaux à côté de la cage d'ascenseur.
+
+Dans le G, il y a des placards où on peut faire passer des câbles entre les
+étages.
+L'idée est de placer une nano par étage, en alternance (en terme de position).
+
+Le M n'a pas été fait, car on avait pas le badge, mais vu les tests le 16
+février, il faut une nano par aile, donc deux par étage.
+Attention aux 100m de câble, et à sertir les paires dans le bon sens...
+
+Les longueurs de câbles seront données sur le wiki. (Daniel s'en charge)
+
+On pourra réfléchir, une fois l'installation faite, à prêter des bornes à des
+adhérents pour "patcher" la couverture dans leur chambre, sous caution.
+
+#### Onduleurs
+
+Olivier s'occupe de faire faire des devis pour remplacer les onduleurs morts
+(0A, 2B, -1I), Pierre-Elliott et Nicolas s'occuperont d'aller voir les onduleurs
+pour savoir lesquels marchent.
+
+#### Clim 0B
+
+Pierre-Elliott s'occupe d'appeler LTC pour faire la révision annuelle de la
+clim.
+
+### Mises à jour
+
+#### TV
+
+La version en production de MuMuDVB était bugguée avec les nouvelles versions de
+VLC. Olivier a effectué la mise à jour du binaire sur les serveurs cet
+après-midi.
+
+#### Wiki
+
+Adg est prêt à encadrer un apprenti pour faire cette mise à jour, avec le
+prérequis
+que l'apprenti en question soit un peu culturé sur apache2 (i.e. sache déjÃ
+lancer moinmoin avec wsgi). Vanessa va voir avec Steven s'il veut toujours
+s'en occuper, sinon, Pierre-Elliott est volontaire (après ses écrits du concours
+3A).Steven est volontaire (il va envoyer un mail à Olivier).
+
+### Séances de travail
+
+#### Ragnarok
+
+Ragnarok est désormais bien monté (deux disques durs d'1To en RAID1). Olivier
+se propose d'encadrer le workshop, qui aura lieu le 7 avril.
+
+#### Nagios
+
+Quand le workshop monitoring a été effectué, on a parlé de re-tester Nagios
+Pierre-Elliott est motivé pour lire les 400 pages de doc de Nagios et prendre
+des notes sur le wiki. Ensuite, on fera une réunion pour en parler, et on
+essaiera de faire un workshop avec une Mamie pour trouver comment implémenter
+au mieux le module.
+
+#### Wiki
+
+Il faut le réordonner tant d'un point de vue "VieCrans" que du point de vue
+technique. Pour la partie VieCrans, Morgane était volontaire pour diriger cette
+réorganisation.
+
+Il faudrait faire plusieurs workshops pour cela. Nicolas demande si ça vaut le
+coup de dédier du temps à faire ''uniquement'' ça.
+
+On pourrait essayer d'appliquer un tag sur les pages pour dater la dernière fois
+que la véracité des informations a été vérifiée.
+
+### Questions diverses
+
+#### Spoofing adresses mac
+
+Un certain nombre d'adhérents reçoivent des mails d'avertissement pour upload
+sans avoir été connectés depuis la veille. Pierre-Elliott va dresser une petite
+liste
+des adhérents qui prétendent cela, et on essayera de voir si une prise commune Ã
+tous ces adhérents est identifiable.
diff --git a/compte_rendus/2012_04_12.md b/compte_rendus/2012_04_12.md
new file mode 100644
index 0000000000000000000000000000000000000000..8c7d8195f0ce03a5a8f8e3b65024aae9c9f6e21d
--- /dev/null
+++ b/compte_rendus/2012_04_12.md
@@ -0,0 +1,162 @@
+# Réunion Nounous
+
+* Date : Jeudi 12 avril 2012
+* Lieu : Condorcet
+* Début : 19h13
+* Fin : 20h10
+
+## Présents
+
+* Aurore Moisy-Mabille
+* Daniel Stan
+* Olivier Iffrig
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Steven Masfaraud
+* Sylvain Boilard
+* Yann Duplouy
+
+## Ordre du jour
+
+### Ragnarok
+
+Nicolas, Olivier, Pierre-Elliott et Yann ont mis en place un serveur rsyslog (en
+RELP) sur ragnarok qui enregistre ses logs dans une base PostgreSQL en local.
+Ça fonctionne, on a mis whatsupdoc en client pour l'instant, il faut voir ce
+qu'on fait des serveurs qui utilisent syslog-ng. On va regarder un peu plus en
+détails, mais la solution qui semble la plus pratique est de remplacer
+syslog-ng
+par rsyslog.
+
+Il faut aussi documenter le tout sur le wiki.
+
+### Niomniom
+
+Steven et Antoine Durand-Gasselin ont travaillé là dessus lundi, pour voir ce
+qu'il se passait, et si ça marchait. A priori, tout fonctionne, la mise à jour
+est prévue samedi à 14h, les pages devraient rester consultables (duplicata des
+pages le temps de la MaJ). La modification de la page d'accueil du wiki est Ã
+faire le plus tôt possible pour prévenir tout le monde.
+
+Steven songe à faire une doc pour la Mà J du wiki qui soit plus accessible à tous
+que celle d'Antoine pour les novices.
+
+### Serveurs de virtualisation
+
+#### Fy
+
+Après la mise à jour du wiki, il n'y aura plus aucun domU sur Fy (les domu
+étant migrés pendant la mise à jour). Il faudra donc le mettre à jour, on peut
+le faire dans la foulée. On pourra alors penser à répartir la charge des domU
+entre les deux serveurs Fy et Fz.
+Raphaël rappelle l'idée de fournir des domU aux clubs. Fz avait à l'origine été
+acheté dans le but d'héberger un nouveau serveur pour les adhérents.
+
+#### Fx
+
+Lors d'une précédente internounou, Nicolas avait souligné que Fx est
+sous-utilisé, et qu'il faudrait songer à utiliser une machine free comme NFS, et
+du coup employer Fx soit comme un nouveau zamok, soit comme un serveur pour les
+clubs.
+
+#### Machines pour clubs
+
+Raphaël propose de créer une interface pour les clubs leur permettant de créer
+une machine virtuelle qu'ils pourraient utiliser à l'envi. On pourra rediscuter
+de ce point après les mises à jour.
+
+### Wifi
+
+Les nouvelles bornes sont arrivées. Il faut des personnes pour poser les bornes
+et effectuer les cablâges nécessaires.
+Il faut s'assurer d'avoir un firmware fonctionnel. La connexion sous windows
+avec ce firmware semble problématique en l'état. Une étude est à mener sur ce
+point.
+
+Liste des bâtiments où on pourrait intervenir sans délai :
+
+* Le A (en partie)
+* Le B
+* Le C
+* La Med
+* La Kfet
+
+On récupèrera à l'occasion d'anciennes bornes, que l'on peut mettre Ã
+disposition
+des anciens adhérents qui veulent les placer dans leur chambre pour patcher la
+connexion wifi, vu qu'elles font switch, il n'y a pas de problème niveau
+câblage.
+On demandera une caution qui sera fixée par le C.A. Il faudra déménager la borne
+dans la chambre de l'adhérent, et donner l'accès au VLAN wifi.
+
+Vu le nombre de bornes, il est nécessaire de former des gens pour flasher les
+bornes.
+Les bornes seront flashées lorsque des gens sachant le faire seront Ã
+disposition,
+du coup toute personne intéressée pourra profiter d'un éventuel workshop. (sans
+que cela n'entraîne une affluence trop forte au 2B). On fera des wokshops durant
+le WE, vendredi soir, samedi selon l'avancement des mises à jour, dimanche.
+
+### Liste de compétences des apprentis
+
+Vanessa a demandé que l'on établisse une liste de compétences nécessaires aux
+apprentis pour qu'ils puissent éventuellement devenir nounous. Ce point avait
+déjà été traité, et un premier document avait été créé, il a été mis à jour,
+et une version sera proposée sur le wiki d'ici jeudi.
+
+### Baie de disques
+
+Pierre-Elliott a discuté avec Jérémie concernant la baie de disques en vue de la
+mise à jour matérielle. Elle est de la même famille que la baie actuelle, il y a
+des chances que ce soit plug-and-play. Dans tous les cas, c'est suffisamment
+lourd pour qu'on attende l'été avant de s'en charger.
+
+### LTC
+
+Pierre-Elliott a contacté LTC, ils proposent de passer le mardi 24 avril à 8h
+pour la maintenance de la climatisation du 0B. Pierre-Elliott et Olivier sont
+disponibles pour les accueillir.
+
+### Nagios
+
+Pierre-Elliott va tenter d'essayer de proposer une documentation sur le wiki, et
+appelle les gens qui ont des questions à les poser, ensuite on pourra mettre ça
+en place, à la place de monit et en complément de munin.
+
+## Questions diverses
+
+### Multiples adresses MAC
+
+Un adhérent rencontre un problème de multiples adresses macs dans sa chambre.
+Lorsqu'il branche son ordinateur, le switch voit en moyenne 8 adresses mac, et
+du coup, il n'a pas accès à Internet.
+
+On va essayer de faire en sorte qu'il puisse se connecter, et chercher des
+vraies solutions en parallèle.
+Solutions proposées :
+
+* Désactiver temporairement l'authentification RADIUS sur la prise
+* N'autoriser que sa vraie MAC sur sa prise
+
+### Vérification mac prises
+
+Daniel s'inquiétait du fait que quelqu'un puisse spoofer des adresses mac
+d'adhérents pour faire de l'upload, un script s'occupe désormais de logguer
+ces informations, pour que le cas échéant on le sache.
+
+### Installeur Debian
+
+L'installeur Debian présent sur le FTP du Cr@ns (et sur le netboot) est cassé,
+il ne reconnait pas les disques durs (et potentiellement pas le reste non plus).
+Il faut essayer de trouver une solution. A priori, c'est un problème indépendant
+du Cr@ns, mais il existe des images censées corriger ça. Affaire à suivre.
+
+### IMAP
+
+Apparemment, Roundcube plante en essayant de s'abonner à des dossiers IMAP, et
+icedove/thunderbird semble également rencontrer quelques difficultés (Ã
+vérifier).
+Il est possible que dovecot rencontre pas mal de soucis en ce moment, Antoine
+Durand-Gasselin a suggéré de refaire la configuration de dovecot pour régler la
+panne.
diff --git a/compte_rendus/2012_04_26.md b/compte_rendus/2012_04_26.md
new file mode 100644
index 0000000000000000000000000000000000000000..b0ba93f373226eff4c52ecb04608d15cfcf7e4b9
--- /dev/null
+++ b/compte_rendus/2012_04_26.md
@@ -0,0 +1,168 @@
+# Réunion Nounous
+
+* Date : Jeudi 26 avril 2012
+* Lieu : 2B
+* Début : 19h25
+* Fin : 21h
+
+## Présents
+
+* Aurore Moisy-Mabille
+* Daniel Stan
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Raphaël Cauderlier
+* Yann Duplouy
+
+## Ordre du jour
+
+### Wiki
+
+La mise à jour de niomniom a été effectuée. Les personnes ayant effectué la
+mise à jour n'étant pas présentes, difficile d'en dire plus. Un backup du
+wiki a été fait dans /usr/scripts (il pèse 800 Mo), il faut l'enlever.
+
+### Virtualisation
+
+fy a été réinstallé, histoire que ce soit propre, et à peu près la même chose
+que sur fz. La migration à chaud ne marche pas très bien. fy est prêt Ã
+accueillir des domU. On va s'en servir pour mettre à jour fz en limitant le
+downtime.
+
+### Baie de disques
+
+Il faudrait voir s'il est possible d'avoir quelques disques en plus, pour
+pouvoir faire des tests dans un premier temps, et ensuite servir de disques
+supplémentaires déjà branchés.
+
+La nouvelle baie étant de la même famille que l'ancienne, le transvasage des
+disques de l'une à l'autre devrait être plug-and-play.
+
+On va faire un workshop le 19 ou le 20 mai pour tester la nouvelle baie.
+
+### Nagios
+
+Pierre-Elliott a passé pas mal de temps (avec Nicolas) pour configurer Nagios de
+manière raisonnable. La config est en cours, serveur par
+serveur. 4 ou 5 serveurs
+sont configurés.
+
+Démo sur nagios.crans.org (login/mdp crans).
+
+Nagios peut tester les services de « l'extérieur » en testant leur
+fonctionnement.
+Un module nagios-nrpe permet de tester les services depuis l'hôte. Ce dernier
+permet de faire des checkdisk, etc. (peu utile car munin le fait déjà ).
+
+L'implémentation des plugins munin est a priori faite, mais les résultats sont
+mitigés. (les plugins sont monitorés passivement, donc si pas de warning, ils
+sont notés comme "en attente", et les rares qui ont été monitorés sont en
+"unknown". Le passage des plugins munin a été uniquement mis en place pour vert.
+
+Il faut trouver une solution alternative à la configuration actuelle pour
+récupérer
+les données de munin dans nagios. Un plugin nagios existe apparemment pour lire
+les fichiers rrd de munin. À creuser ?
+
+vo:/localhome/becue/nagios contient quelques scripts et éléments au fur et Ã
+mesure de la config. La doc sera faite d'ici peu.
+
+Il faut intégrer monit à nagios (c'est à dire, faire en sorte que les warnings
+de monit soient gérés par nagios, au niveau mail et interface web).
+Un plugin nagios existe déjà pour se connecter à un serveur monit distant, il
+faut donc voir à adapter la config de monit, ou à lancer le plugin en question
+via NRPE.
+
+Il faudra aussi réfléchir à la "mise en production" des alertes mail de nagios
+sur
+roots@crans.org.
+
+### Wifi
+
+Pas de réponse d'interprojekt pour le retour des bornes (qui ne sont pas les
+bonnes).
+
+Certains adhérents ont constaté un problème de compatibilité entre leur carte
+réseau et le wifi n. Une désactivation du wifi 802.11n sur la carte niveau
+client a été faite pour régler le problème.
+
+Il y a plusieurs possibilités sur la nature du problème. Cela peut-être
+dû à la largeur du canal utilisé pour le WiFi n (les canaux à 40MHz ne sont pas
+supportés par la carte, contrairement à ceux à 20MHz). Cela peut aussi être dû
+à un driver moisi (il permet de désactiver le 802.11n, donc il n'est pas si
+moisi que ça). On n'a pas constaté de problèmes lors des journées FedeRez,
+donc ça peut aussi être lié au WPA2-entreprise.
+
+Pour résoudre ce problème particulier, plusieurs pistes :
+
+* Désactivation du 802.11n côté client
+ * Avantage : débit maximal pour les clients qui le supportent
+ * Inconvénients : tests au câblage plus lourds, toutes les cartes ne le
+
+supportent peut-être pas...
+
+* Dédoubler les SSID (Un ssid Cr@ns, un ssid Cr@ns-n)
+ * Avantage : débit max pour les clients qui le supportent, les vieux clients
+ ont toujours du wifi g
+ * Inconvénients : confusion ?
+* Réduire la largeur du canal
+ * Avantage : toujours du n
+ * Inconvénients : est-ce que ça règle vraiment le problème ?
+* Désactiver le wifi 802.11n
+ * Avantage : On est sûrs que ça marchera partout
+ * Inconvénients : pas un meilleur débit (enfin toujours un meilleur débit que
+
+les wrt54g...)
+
+Daniel a commencé à regarder pour le dédoublement des SSID, le reste est une
+modification triviale en termes de config d'OpenWRT et peut être testé en
+présence
+d'un-e cobaye.
+
+Diomède sera réinstallée à la Kfêt, avec la config HT20 pour tester.
+
+### Ardoise virtuelle 0B
+
+L'idée de base est que l'interface d'accès aux locaux ne fonctionnera jamais
+(les gens ne s'y inscriront jamais), Daniel propose de faire une interface
+physique sur laquelle les gens s'inscrivent pour prendre une clé, et qui
+consigne les accès directement dans la base.
+
+On pourrait aussi envisager l'idée d'installer une armoire à clefs électronique
+un peu comme celle de l'ENS, qui ne permet de retirer que la clé pour laquelle
+on s'est inscrit. Celà forcerait les gens à s'inscrire.
+
+Daniel s'occupe de faire ça et l'interface d'accès aux locaux, éventuellement
+avec un apprenti (Julien ?).
+
+### Babar
+
+Il commence à en avoir plein la trompe. Olivier s'occupe de demander un devis Ã
+Anne pour plus de disques, selon le nombre de slots disponibles.
+
+### Ragnarok
+
+Le nouveau serveur syslog est fonctionnel.
+
+Reste à mettre la config de rsyslog sur tous les serveurs pour qu'ils y envoient
+leurs logs. Il faut faire attention à ne pas faire la modification à l'aveugle,
+par exemple sur les serveurs qui dépendent de leurs logs (komaz, par exemple).
+
+Il faut aussi changer la config des switchs pour qu'ils envoient leurs logs
+à ragnarok et non à vo. Daniel s'en occupe.
+
+Il faut configurer un frontend un peu plus sexy que psql. Yann s'occupe de
+recenser ce qui existe.
+
+### Questions diverses
+
+#### Inscription aux mailing-lists des vieilles nounous inactives
+
+Plein de vieilles nounous + plein de spams = plein d'espace disque utilisé pour
+rien.
+
+Plusieurs possibilités : virer les droits des gens; créer un droit "Vieux" qui
+reçoit juste certaines ML; ne rien faire et remplir /home.
+
+Olivier envoie un mail à ces vieux pour leur demander ce qu'ils veulent toujours
+voir et pourquoi.
diff --git a/compte_rendus/2012_05_10.md b/compte_rendus/2012_05_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..08931ccc5bfb12c585b8ad7cef33975315f1d795
--- /dev/null
+++ b/compte_rendus/2012_05_10.md
@@ -0,0 +1,115 @@
+# Réunion Nounous
+
+* Date : Jeudi 10 avril 2012
+* Lieu : Hall du bâtiment B
+* Début : 19h35
+* Fin : 20h35
+
+## Présents
+
+* Aurore Moisy-Mabille
+* Morgane Jançon
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pierre Elliott Bécue
+* Raphaël Cauderlier
+* Sylvain Boilard
+* Yann Duplouy
+
+## Ordre du jour
+
+### Ajout de droits
+
+nounous.append(PEB)
+
+### Logs
+
+Ragnarok fonctionne, et les logs sont bien reçus. Pour l'instant, on a
+whatsupdoc, niomniom, vert, redisdead, ragnarok, gordon, et quatre switches
+(bata-n n in {0, 1, 2, 4}).
+
+Il faut faire attention lors du passage vers rsyslog pour komaz.
+
+Ce n'est pas très long à faire, il s'agit juste de retirer syslogng sur les
+serveurs où il est installé, puis mettre rsyslog et faire un bcfg2. Il faut
+surtout trouver le temps.
+
+Yann se charge de trouver un frontend potable. Dans le pire des cas, un
+frontend sera développé sous django.
+
+### Baie de disques
+
+Anne devrait envoyer un devis pour des disques supplémentaires d'ici demain.
+Un workshop est prévu le 26, sous réserve d'obtention des disques d'ici là .
+
+### Virtualisation
+
+La migration à chaud d'un dom0 à l'autre ne fonctionne pas. Les domU ont été
+déplacés sur fy afin de pouvoir mettre à jour fz sans souci (le noyau a quelques
+mises à jour de sécurité de retard). On verra ce que ça donne par la suite.
+
+On peut utiliser ytrap-llatsni pour tester.
+
+### Wifi
+
+On va pouvoir renvoyer 30 des 33 !PicoStation à Inter Projekt, les trois
+suivantes seront utilisées malgré tout. Il faudra payer les frais de port, et
+on risque d'avoir du mal à couper aux 15%.
+
+Après l'aller-retour des bornes, il faudra du monde pour déployer le tout.
+On prévoit ça pour le 2 juin.
+
+### Clim 0B
+
+La clim est en rade, la situation est devenue critique dans l’après-midi.
+Le technicien de LTC passe demain, il faut que quelqu’un soit là pour
+l’accueillir. PEB et Morgane sont disponibles, fonction de l'emploi du temps
+du premier, on fera signe à la seconde.
+
+Il faudra aussi faire (un peu) attention cette nuit.
+
+### Mise à jour de rouge
+
+''A priori'', virtualiser rouge si on conserve Amavis, ça semble
+problématique (trop
+de ressources exigées). L'idée qui semble retenue est de passer le filtrage sur
+zamok, que l'on passerait sur fx (qui est toujours sous utilisé).
+
+À faire en même temps que les tests sur la baie de disques (ou plutôt quand
+ceux-ci seront concluants).
+
+### RAID
+
+Le RAID sur ragnarok et sila nous ont envoyé une erreur "!DegradedArray". Elle
+a été corrigée.
+
+La commande en question : {{{mdadm --manage /dev/mdX --add /dev/sdYZ}}} où mdX
+est l'array, et sdYZ le disque qui en a disparu (Ã trouver dans dmesg, il est
+écrit "md: kicking non-fresh sdXY from array!"
+
+On va refaire un séminaire sur la gestion de disques (RAID, LVM) l'an prochain.
+
+## Questions diverses
+
+### Limite de détection de virus
+
+La limite de détection des floods est un peu basse (genre ouvrir safari avec 15
+onglets ça peut dépasser les limites de flood), il est donc suggéré de la
+monter à 20 détections de 150 connexions par seconde pour l'instant.
+
+### Problèmes de mots de passe
+
+Les mots de passe de deux apprentis ont apparemment changé dans la nuit de mardi
+à mercredi. On a strictement rien trouvé dans les logs. Il faut mettre en place
+le système de logs LDAP. (qui est en place sur LDAP test sur vo).
+
+Olivier et Nicolas essaieront de s'en occuper sous peu. PEB viendra voir, pour
+rédiger de la doc.
+
+### Firewall IPv6
+
+Le démarrage du firewall IPv6 a été cassé par une mise à jour de config.py
+(disparition de main_proxy ou whatever). À corriger par quelqu'un qui a
+déjà touché à ce script...
+
+On demandera à Valentin et Daniel de regarder.
diff --git a/compte_rendus/2012_05_24.md b/compte_rendus/2012_05_24.md
new file mode 100644
index 0000000000000000000000000000000000000000..d10b629f01139fc34cd83108dfdfc6808c53d053
--- /dev/null
+++ b/compte_rendus/2012_05_24.md
@@ -0,0 +1,111 @@
+# Réunion Nounous
+
+* Date : Jeudi 24 mai 2012
+* Lieu : 2B
+* Début : 19h10
+* Fin : 20h36
+
+## Présents
+
+* Olivier Iffrig
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Sylvain Boilard
+* Yann Duplouy
+
+## Ordre du jour
+
+### Sila
+
+Il fait de la merde avec ses disques. C'est pas la faute des disques, ni de la
+carte SATA. On va utiliser vo comme miroir Debian temporaire, en attendant
+d'avoir
+une vraie solution, Ã choisir parmi :
+
+* Acheter un nouveau serveur
+* Utiliser l'ancienne baie de disques et un serveur quelconque, une fois que la
+ nouvelle aura pris le relais, ça implique d'acheter des disques pour la baie.
+
+On part plutôt sur l'achat d'une nouvelle machine, un devis va être demandé Ã
+Anne
+et sera proposé au prochain C.A., avec les 2 possibilités.
+
+### Wifi
+
+#### MAJ de Windows 7
+
+On constate que beaucoup d'adhérents n'arrivent plus à se connecter au wifi,
+une mise à jour de Windows 7 pourrait en être la cause. Cependant, certains avec
+une version à jour y arrivent encore. Il faudrait faire des tests :
+
+* Est-ce que ça marche avec CransWifi ?
+* Est-ce que ça marche avec une configuration manuelle ?
+* Qu'est-ce qu'il y a dans les logs ?
+
+PEB va envoyer un mail aux câbleurs pour qu'ils nous donnent un coup de main.
+
+#### Picostations
+
+Les pico sont arrivées en Pologne, on attend des nouvelles d'!InterProjekt.
+
+### Workshops
+
+#### Baie de disques
+
+Il n'aura pas lieu ce WE, contrairement à ce qui a été prévu. On garde ça sous
+le
+coude, selon l'évolution de la commande de disques (devis, approbation ou non du
+CA, livraison).
+
+#### Logs
+
+Il faut passer les serveurs utilisant syslog-ng à rsyslog. Attention à komaz,
+car
+on a besoin de parser les logs. On fait ça ce WE. Appel aux apprentis motivés.
+
+#### Wiki
+
+L'idée est de remanier le wiki. Raphaël propose de fusionner CransNounous et
+CransTechnique. Réécrire la doc pour ce qui manque. Voir comment on gère la
+centralisation
+de la doc proposée dans le cadre de FedeRez.
+On prévoit un workshop ce WE, on peut en discuter d'ici là .
+
+### Cranspasswords
+
+Nicolas a commencé la réécriture d'un script cranspasswords, et Daniel a
+continué.
+Le script est actuellement en test sur vo dans /home/dstan/cranspasswords/
+(c'est un dépôt git). Le serveur est finalisé (cranspasswords-server) mais
+il reste quelques fonctions à implémenter côté client (le script qui doit être
+copié sur chaque machine de nounou).
+
+Le principe: le serveur stocke plusieurs fichiers json. Chacun contenant:
+
+* Une liste de rôles
+* Le mot de passe gpg chiffré avec l'ensemble des clés de toutes les personnes
+ décrites par les rôles
+
+Pour mettre à jour, il faut donc chiffrer à nouveau avec toutes les clés
+publiques
+correspondantes, et ceci s'effectue sur le client.
+
+Pour l'instant, on peut lister les fichiers, voir et éditer les mots de passes.
+(du coup, pour l'utilisation basique ça serait bon.) Il faut implémenter la
+modification des rôles d'un fichier, la création et la suppression, qui se fait
+pour le moment à la main. Et la regénération des fichiers lors du changement
+des bénéficiaires d'un rôle. Le plus propre serait d'intégrer ça à LDAP.
+
+Next step: que tout le monde ait une clé, et idéalement, convertir aussi les
+membres du CA/Bureau, pour la trésorerie par ex. Des rôles différents sont
+disponibles en lecture et écriture.
+
+## Questions diverses
+
+### Kenobi, tu fais chier
+
+On veut mettre fz à jour, donc on le migre sur fy.
+
+### o2
+
+Il semblerait qu'o2 ne sache pas envoyer des mails correctement. À étudier.
diff --git a/compte_rendus/2012_06_07.md b/compte_rendus/2012_06_07.md
new file mode 100644
index 0000000000000000000000000000000000000000..d83f5c732508d95b6176b53ea70951b67f83e998
--- /dev/null
+++ b/compte_rendus/2012_06_07.md
@@ -0,0 +1,89 @@
+# Réunion Nounous
+
+* Date : Jeudi 06 juin 2012
+* Lieu : 2B
+* Début : 19h20
+* Fin : 20h33
+
+## Présents
+
+* Julien Baste
+* Kévin Viard
+* Morgane Jançon
+* Olivier Iffrig
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Sylvain Boilard (19h50)
+
+## Ordre du jour
+
+### Remplacement de sila
+
+Le remplaçant de sila est arrivé. Il s'appellera charybde. PEB va encadrer son
+installation. Appel aux gens motivés.
+
+### Migration à chaud des DomU
+
+Olivier et PEB ont fait des tests de migration samedi. Ça marche. Ils en ont
+profité pour mettre à jour les dom0.
+Il y avait des soucis après la mise à jour de fz, il prenait toute la RAM par
+défaut, on a modifié /etc/default/grub, pour rajouter la mention sur la quantité
+de RAM que le dom0 a le droit d'utiliser (512 MB).
+
+### Disques pour la baie
+
+Olivier avait contacté Anne pour demander des disques pour la baie, car pour
+l'instant on a pas de disques de spare, il voulait des devis.
+
+Plusieurs disques ont été proposés (dont du S-ATA), en 15 000 rpm, on peut
+monter à 600 Go, à 505 € HT l'unité. Sinon on a du SAS en 7 200 rpm à 305 €
+pour 1 To, 460 € pour 2 To, et 775 € pour 3 To, le tout hors taxe, et par unité.
+
+On proposera un devis au C.A., après avoir pris le temps d'en discuter.
+
+L'idée pour rester homogène serait de prendre les 600 Go à 15 000 rpm.
+
+### Identification sur les news
+
+Le conseil d'administration a demandé un audit auprès du collège des nounous
+concernant une éventuelle limitation d'accès en écriture sur les news. Raphaël
+est prêt à faire des tests, il installera inn2 sur vo.
+
+A priori, il sera peut-être nécessaire d'interfacer LDAP et inn2, mais il n'est
+pas certain que ce soit facile.
+
+### Clés usb
+
+Un projet de clefs usb pour remplacer les t-shirts Cr@ns offerts lors de
+l'adhésion a été lancé, il a été demandé aux nounous de proposer des éléments
+à mettre dessus avant la rentrée.
+
+Un LiveCD ubuntu a été proposé, ou bien framakey, une suite de logiciels libres.
+Il est peut-être possible de mettre les deux.
+
+Kévin suggère de mettre putty sur ces clefs, pour que les utilisateurs de
+Windows aient un opérateur ssh accessible.
+
+On peut sinon proposer notre propre suite logicielle pour ces clefs.
+
+### Wiki
+
+Raphaël a proposé de fusionner CransTechnique et CransNounous, il faut lister
+les pages concernées, les catégoriser, puis enfin, il faudra déplacer tout ça.
+
+Déplacer les pages pourrait flinguer leur historique d'édition, il faudra
+vérifier cela avant de commencer à faire les opérations, ces historiques étant
+utiles. On se demande aussi s'il faut clairement séparer les parties
+administratives et techniques en termes d'architecture.
+
+Raphaël voudrait avoir un retour concernant les idées qu'il a proposées.
+
+Premier workshop lundi 11 au soir, Ã partir de 19h30.
+
+## Questions diverses
+
+### Cranspasswords
+
+Daniel demande aux nounous qui ne se sont pas encore inscrites dessus de le
+faire.
diff --git a/compte_rendus/2012_06_28.md b/compte_rendus/2012_06_28.md
new file mode 100644
index 0000000000000000000000000000000000000000..940c96983e3794c892be0e2ab75bb37543624599
--- /dev/null
+++ b/compte_rendus/2012_06_28.md
@@ -0,0 +1,128 @@
+# Réunion Nounous
+
+* Date : Jeudi 28 Juin 2012
+* Lieu : 2B
+* Début : 19h25
+* Fin : 20h47
+
+## Présents
+
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Sylvain Boilard
+
+## Avancées
+
+### Serveur FTP
+
+Pierre-Elliott et Pauline ont installé charybde, le serveur FTP a été remis en
+route, ainsi que le miroir Debian et le serveur DNS. Daniel a remis en place les
+dépôts Git et gitweb. Reste à remettre darcsweb et le miroir opkg.
+Pierre-Elliott se charge de darcsweb.
+
+### Carte des bornes Wifi
+
+Daniel a mis en place une nouvelle carte des bornes sur l'intranet2
+https://intranet2.crans.org/wifimap/
+
+Le but à terme est de pouvoir éditer les bornes directement depuis la carte
+(position, ssid disponibles etc.), voire afficher les ssid "pirates" qui
+pourraient être diffusés dans les alentours.
+
+### Mises à jour
+
+Quand on fait les mises à jour des serveurs, on lit correctement la liste des
+paquets qui vont être impactés, et surtout on teste _tous_ les services après
+la mise à jour.
+
+## Projets
+
+### SOGo
+
+Vincent Le Gallic s'occupe de mettre en place SOGo, encadré par Pierre-Elliott.
+La partie
+authentification, client mail fonctionne, reste à voir pour les contacts et les
+agendas.
+
+### Baie de disques
+
+Deux disques ont été commandés pour la baie, ils arriveront... Bientôt.
+On va faire des tests dès que les disques seront arrivés. Olivier se chargera
+d'encadrer un éventuel apprenti motivé.
+
+### Impression
+
+Daniel a plusieurs suggestions pour améliorer le service d'impression, notamment
+une surveillance automatique de la fin des tâches.
+
+Il faut également permettre aux adhérents d'annuler leur tâches non encore
+imprimées (avec crédit), ce qui faciliterait aussi la vie des imprimeurs en cas
+de bourrage et d'annulation de jobs en masse.
+
+Il y a aussi l'interface écrite par Antoine Durand-Gasselin pour remplacer le
+driver foireux que l'on pourrait mettre en place, ou le module CUPS.
+
+Vincent a l'air intéressé, mais il a déjà plein de choses dans sa fifo.
+
+Avis aux autres apprentis...
+
+### Miroir OpenWRT
+
+Il y avait un dépôt opkg sur sila, on va essayer de faire un vrai miroir sur
+charybde. Il semblerait qu'il n'y ait pas de serveur rsync public chez
+OpenWRT, on va leur envoyer un mail pour demander. Raphaël s'occupe du mail et
+victimisera un apprenti pour écrire le script.
+
+### Logs
+
+#### Logs sur komaz
+
+Il s'agit de remplacer syslog-ng par rsyslog qui a été choisi pour les logs
+centralisés. Le "problème", c'est qu'il y a des règles spéciales pour écrire
+les logs du firewall dans des fichiers séparés, qui sont "tail -F"és par des
+scripts (filtrage_firewall.py) qui vont écrire les infos dans la base de
+données pgsql de déconnexion.
+
+Il suffit de réécrire la règle qui marche actuellement pour syslog-ng de façon Ã
+ce qu'elle marche pour rsyslog.
+
+Pierre-Elliott s'ennuie ce soir, il regardera ça.
+
+#### Anciens logs
+
+La question est de savoir quoi faire des actuels logs "fichiers". Nicolas pense
+que tant qu'il n'y a pas de méthode plus simple qu'un select sur la base pour
+accéder aux logs dans pgsql, il vaut mieux les garder. *silent ping*
+
+#### Frontend
+
+Daniel propose d'écrire un nouveau script qui contacterait la base PGSQL pour
+faire les SELECT qui vont bien.
+
+Daniel avait aussi fait un prototype dans l'interface d'administration de django
+
+Enfin, Yann est censé regarder les frontends existants.
+
+#### Purge de la base
+
+La table des logs contient environ 60 millions d'entrées, les requêtes
+effectuées dessus impliquant des champs indexés, tout se passe merveilleusement
+bien, mais si la base doit être lue intégralement, les requêtes deviennent
+sensiblement plus lentes.
+
+L'idée est de créer une seconde table qui contiendrait les données sur une durée
+d'un an, et la première servirait aux données sur un délai raisonnable. On
+placerait sur la table court terme un trigger qui copierait les données type
+mail.log, auth.log, radius, les logs des switches, etc. dans la base long terme.
+Deux scripts s'exécuteraient tous les jours pour virer les données périmées.
+
+Pierre-Elliott proposera à Kévin Viard.
+
+#### Logs des switchs / bornes Wifi
+
+Il faut aller dire aux switchs d'envoyer leurs logs sur ragnarok. De même pour
+les bornes wifi.
+
+## Questions diverses
diff --git a/compte_rendus/2012_09_06.md b/compte_rendus/2012_09_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..58c99c87513cb9ca1bfa29d2cd6f89e74b44e07d
--- /dev/null
+++ b/compte_rendus/2012_09_06.md
@@ -0,0 +1,150 @@
+# Réunion Nounous
+
+* Date : Jeudi 06 septembre 2012
+* Lieu : Pavillon des Jardins
+* Début : 19h12
+* Fin : 21h20
+
+## Présents
+
+* Daniel Stan
+* Olivier Iffrig
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Steven Masfaraud
+* Valentin Samir
+* Vincent Guiraud
+* Vincent Le Gallic
+* Yann Duplouy
+
+## Bilan des vacances
+
+### Onduleur
+
+Pulsar nous a lâché durant l'été, le module électronique était défaillant.
+Eaton nous en a renvoyé un, qu'on a mis en place durant la grosse mise à jour
+le 9 août.
+
+Nicolas Dandrimont a proposé qu'on tire une seconde alimentation au 0B pour
+servir de relais, ondulée ou non, depuis le local TGBT.
+
+Il faut attendre la fin de la rentrée, et éventuellement se faire une idée des
+comptes, pour faire des devis.
+
+### Remplacement de la baie de disques
+
+La baie de disques a enfin été remplacée, la migration s'est faite sans aucun
+souci, et les scripts d'interface ont été refaits.
+
+L'ancienne baie est toujours rackée au 0B.
+
+À long terme, il faudrait remplacer les cinq disques de 300 Go restants par des
+disques de 600 Go, voire plus s'il en existe d'ici là .
+
+### Changement de serveur NFS
+
+On a profité des changements massifs pour remplacer le nfs par une machine
+free (daath).
+
+À long terme, remplacer daath par une machine sous garantie ne serait pas
+aberrant.
+
+### Remplacement de zamok
+
+Zamok a quitté son bel habit moisi pour aller dans celui de fx, qui venait de
+se faire mettre au chômage technique.
+
+Ça swappe moins, ça a huit coeurs, 16 Go de RAM, et ça se tourne un peu les
+pouces, sauf quand spamassassin tourne.
+
+### Suppression d'un MX
+
+On a catapulté rouge dans le nether, parce que redisdead suffit.
+
+freebox en profitait pour envoyer des mails, ce qui n'était pas normal. Par
+ailleurs, freebox.crans.org est blacklisté par un serveur mail.
+
+### Ragnarok
+
+Le serveur de logs est mort, il était déjà mort quand il gérait le wifi.
+Conclusion, on va arrêter de l'utiliser.
+
+Il faut cependant le remplacer, dans un délai rapide. On va temporairement
+spoofer sur vo.
+
+Une demande de devis pour un serveur (idéalement rackable) supportant le SATA
+sera faite. On le mettra au 0H s'il n'est pas rackable.
+
+### Webmails
+
+Vire-t-on horde ? Telle est la question.
+
+L'idée est de rediriger webmail.crans.org vers une page d'informations listant
+les webmails disponibles.
+
+SOGo marche, mais certaines implémentations restent à faire. Pour l'instant,
+mieux vaut proposer roundcube, et se donner quelques mois pour que Vincent
+s'occupe de SOGo.
+
+## Projets
+
+### Séminaires (non techniques)
+
+Steven demande s'il est envisageable de faire des séminaires basiques sur
+l'utilisation des services du Crans.
+
+Il trouve que les séminaires ont été réalisés jusqu'alors ne sont pas assez
+pédagogues. Certains s'y connaissent (la plupart des apprentis avaient de
+bonnes bases), et la majorité des personnes arrivant sur le campus n'ont pas
+forcément les compétences nécessaires.
+
+Il suggère de rajouter, en plus des séminaires techniques, un certain nombre de
+séminaires grand public pour présenter l'utilisation des services du Cr@ns, de
+Linux, ou de LaTeX par exemple.
+
+Pierre-Elliott rappelle que lors d'une réunion aux alentours de juin, un ou
+deux séminaires sur LaTeX avaient été prévus vers décembre.
+
+* Présentation des services pour les adhérents (tv, mail, news, irc, gobby, …)
+* Installation de Linux
+* LaTeX (à prévoir vers décembre, faire de la pub auprès des départements)
+
+### Séminaires
+
+Une liste d'idées de séminaires a été ajoutée sur le wiki, donnez vos idées.
+Deadline : jeudi 4 octobre.
+Certains séminaires seront organisés sous la forme d'un atelier, notamment
+shell, python, GPG, réseau ?
+
+### Ménage câbleurs/apprentis
+
+Une liste des apprentis inconnus au bataillon a été faite. Olivier va s'occuper
+du ménage.
+
+### WiFi
+
+Valentin a fait un très joli logiciel pour le WiFi sous Windows Vista et Seven.
+
+Il faudrait entamer un dossier à présenter au CROUS, pour installer le WiFi au
+G et au M.
+
+!InterProjekt est en rupture de stock pour les bornes reparties en Pologne...
+On attend et on croise les doigts de pied.
+
+## Questions diverses
+
+### Comptage upload ipv6 et extensions de vie privée
+
+La connectivité ipv6 est actuellement proposée au Crans. Le comptage d'upload
+est par MAC-IP en ipv4 et 6. L'idée est d'autoriser les extensions de vie
+privée (attribuer une IP aléatoire), pour éviter qu'on puisse identifier les
+adhérents (leur adresse mac).
+
+On souhaite rajouter au comptage d'upload les adresses mac des adhérents, pour
+que l'attribution aléatoire d'adresse soit possible. Valentin a commencé Ã
+faire des choses, il nous en dira plus au fil du temps.
+
+### dnssec récursif
+
+Valentin voudrait importer la clef de l'IANA dans bind pour que nos DNS
+puissent valider du DNSsec.
diff --git a/compte_rendus/2012_10_02.md b/compte_rendus/2012_10_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..3d3783e5db77c76b7a9bb8646d1553ceef867a4b
--- /dev/null
+++ b/compte_rendus/2012_10_02.md
@@ -0,0 +1,102 @@
+# Réunion Nounous
+
+* Date : Mardi 2 octobre
+* Lieu : Salle Condorcet
+* Début : 19h
+* Fin :
+
+## Présents
+
+* Daniel Stan
+* Lilian Besson
+* Lucas Serrano
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Raphaël Bonaque
+* Raphaël Cauderlier
+* Valentin Samir
+* Vincent Guiraud
+* Vincent Le Gallic
+* Yann Duplouy
+
+## Ordre du jour
+
+### Séminaires
+
+Olivier explique aux apprentis l'intérêt général des séminaires, les apprentis
+peuvent y trouver une bonne occasion de découvrir un thème particulier.
+
+On prévoit un premier séminaire le 16 octobre (présentation des services) qui
+sera davantage ciblé pour les adhérents tandis que le séminaire du 23 sera Ã
+destination des apprentis.
+
+### Onduleurs
+
+Plus d'onduleur au J, A, I, M, 2B. Des devis ont été reçus pour les remplacer.
+Pour 4 switchs, on arrive à 687€ HT
+Pour le bâtiment M (8 switchs): 857€ HT
+
+Le problème de la température dans les locaux J et M se pose. On va demander
+de nouveaux devis pour des onduleurs non rackables (moins chers).
+
+### Serveur de remplacement pour ragnarok
+
+Pas de nouvelles pour un serveur de remplacement. Le standard pour les disques
+semble avoir changé chez HP. À vérifier.
+
+On reste en attendant sur une config temporaire sur vo pour récupérer les logs.
+
+### Réflexion sur la continuité des services "à vie" du Cr@ns pendant/après le
+déménagement de l'école
+
+## Ce point vient d'une rencontre avec Barbich' au resto de l'X
+Avec les discussions en cours pour la migration à Saclay, plusieurs questions
+se posent sur la continuité des services du Cr@ns, si l'association ne dispose
+pas de matériel sur le nouveau site. L'idée est de proposer un schéma de
+migration
+des services vers un hébergement à long terme.
+
+On en rediscute avant décembre avec Cyril Cohen (qui avait soulevé ce point).
+
+### Mailing Lists
+
+PE suggère de faire le ménage parmi les mailing lists. On peut regarder
+l'ancienneté
+des archives afin de déterminer si elles sont toujours utilisées. Pour les MLs
+non archivées, on peut envoyer un message pour demander s'il y a toujours de la
+vie.
+
+Raphaël Cauderlier propose de synchroniser les clubs et leurs mailing-lists.
+On peut aussi donner un moyen simple d'aliaser le mail du club avec leur
+mailing-list.
+
+Lilian et Lucas sont motivés pour regarder ça avec Daniel.
+
+### Promotion nounou
+
+Le collège technique nomme Vincent nounou. Du coup, il va falloir refaire un
+double de la boîte à clé et de l'armoire serveur (PE s'en charge.)
+
+### Questions diverses
+
+#### Imprimante
+
+## Il se passe deux trois trucs tout de même
+Une planche a été mise pour fermer la fenêtre. Conséquemment, la porte ne se
+claque plus. Il faut trouver un groom avec plus de force.
+
+Pauline a discuté avec le CROUS pour avoir les plans, ou au moins le cahier des
+charges, du 4J et est allée demander les plans au service de l'urbanisme de la
+mairie.
+
+#### Personnel ENS
+
+Ca fonctionne toujours aussi bien, Valentin à rajouté le routage du multicaste.
+On envisage de placer directement les personnels sur le vlan adhérent, et de
+voir ce qui arrive.
+
+#### Organisation du collège technique
+
+Pauline a posé plusieurs questions, un résumé d'ici peu.
diff --git a/compte_rendus/2012_10_30.md b/compte_rendus/2012_10_30.md
new file mode 100644
index 0000000000000000000000000000000000000000..0fd91cac30448daa8f41b527d49df0de5ec193d3
--- /dev/null
+++ b/compte_rendus/2012_10_30.md
@@ -0,0 +1,193 @@
+# Réunion Nounous
+
+* Date : Mardi 30 octobre 2012
+* Lieu : 2B
+* Début : 18h30
+* Fin : 22h07
+
+## Présents
+
+* Daniel Stan
+* Lilian Besson
+* Olivier Iffrig
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Valentin Samir
+* Vincent Le Gallic
+* Yann Duplouy
+
+## Ordre du jour
+
+### Bornes Wifi
+
+Les !PicoStations sont arrivées.
+
+* On a un problème : avec les anciennes comme avec les nouvelles bornes, il
+ arrive qu'au bout d'un temps aléatoire les utilisateurs n'arrivent pas Ã
+ aller plus loin que le DHCP. Une solution proposée est de faire un script qui
+ monitore ça, et qui relance ce qu'il faut ("wifi" semble suffire, mais on
+ peut décider selon les cas de rebooter la borne). De plus, hostapd semble
+ segfaulter sur certaines bornes, il est suggéré d'installer monit sur les
+ bornes, Ã voir si c'est suffisant. Daniel et Valentin vont voir ce qu'ils
+ peuvent faire.
+* Pour le flashage : il faut des volontaires. On fera ça au fur et à mesure,
+ appel aux intéressés.
+* Feature potentiellement intéressante des nouvelles bornes : il serait
+ possible de faire de l'authentification Pre-Shared-Key avec une clé
+ différente par MAC. Revers de la médaille : on ne peut plus valider le
+ certificat radius, donc possibilités de bornes pirates. Il pourrait y avoir
+ d'autres problèmes de sécurité si la borne connait le mot de passe en clair
+ de l'utilisateur.
+* Étant donné qu'on va pouvoir recycler les anciennes bornes, il serait
+ intéressant d'essayer de faire fonctionner la dernière version d'OpenWRT
+ dessus. On va voir au cas par cas ce qu'on peut récupérer.
+* En attendant d'avoir une réponse du CROUS pour l'installation de nouvelles
+ bornes, on peut déjà remplacer les anciennes bornes dans les faux-plafonds
+ par des nouvelles. Ça implique de ressertir les câbles PoE maison. Avis aux
+ intéressés.
+* On n'a toujours pas les plans des bâtiments, donc pour l'instant le dossier
+ pour le CROUS est en attente
+
+### Logs
+
+#### Serveur
+
+* On a reçu un devis de la part de notre fournisseur : même gamme que fx, fy et
+ sable. Cela fait peut-être un peu overkill, surtout que l'on est en train de
+ migrer les services qui sont sur sable. Le serveur est a
+ priori 100% modulaire, mais cher.
+* Pas de SATA sur sable, mais du SAS, vu qu'on est en train de migrer les
+ services de sables vers des domU, il pourrait être envisageable d'acheter des
+ disques SAS et d'utiliser sable comme serveur de log.
+
+On va demander des précisions/des nouveaux devis pour les différentes solutions
+suivantes :
+
+* Acheter le serveur (2500€ + éventuellement les disques → 3120€)
+* Demander un serveur moins cher mais rackable (disques inclus)
+* Utiliser sable en demandant seulement des disques SAS
+ * Extension de garantie pour sable ?
+
+Il faut réfléchir à l'espace disque nécessaire.
+Olivier s'occupera ensuite de demander les devis.
+
+#### DomU pour les consulter
+
+Daniel a créé un DomU de log qui récupère ceux de gordon (afin d'avoir des
+données dans la base). Yann va configurer un frontend sur cette machine.
+
+#### Envoi des logs
+
+Vu que ragnarok n'est plus, et qu'on a des soucis pour récupérer les logs sur
+vo,
+on désactive cette fonctionnalité.
+
+Seuls gordon (et donc les bornes WiFi) et news envoient leurs logs au domU, on
+va rajouter quelques serveurs supplémentaires pour avoir une petite base de
+données
+qui reste représentative, ceci afin de développer et tester le frontend.
+
+#### Logs d'Apache
+
+Apache n'utilise pas syslog. Il faut interfacer Apache avec syslog. On peut dire
+à Apache d'envoyer ses logs à un programme externe. Valentin s'en charge.
+
+### DHCP
+
+Valentin a créé un DomU (dhcp) centralisant tous les dhcp. Il a donc une patte
+sur tous nos VLAN sur lequel le service est présent (adhérent, wifi, accueil,
+isolement, appartement, install party).
+
+Les switchs ont été reconfigurés pour le dhcp snooping, désormais sur tous les
+vlans. Seul bata-3 n'a pas été reconfiguré car il semble mal configuré pour
+un réglage à distance. Une fois que ce problème sera réglé et après
+vérification,
+on pourra couper les anciens services (sur sable, gordon, titanic). Pour
+l'instant,
+les serveurs fonctionnent en parallèle.
+
+### Réunion avec la DSI
+
+Il faut organiser une réunion avec la DSI.
+
+Ordre du jour :
+
+* Réunion périodiques ? (nouvelles têtes, coucou c'est nous)
+* Personnels NATés sur Renater
+* Plans du réseau
+* Gigabit
+* Clef placard (On a une clef du placard qui emprisonne ilona, mais elle est
+ endommagée. On peut leur demander la leur pour faire un double.)
+* IPv6 (Rubis il est méchant)
+* Étoiler le PDJ. (minigiga.new() → 0P)
+* conf bato-1 (agrégation des deux fibres disponibles) : accès à l'autocom
+ nécessaire
+
+### Passage de LDAP Ã PostgreSQL
+
+## Vincent Le Gallic a remis ça sur la table. Pourquoi ça a été abandonné ? Mis
+Ã part le boulot niveau scripts crans, pourquoi pourrait-on ne pas vouloir y
+retourner ?
+##
+## Premièrement parce qu'on ne peut pas "mettre à part" le boulot au niveau des
+scripts : personne ne les améliore pour LDAP, je ne vois pas pourquoi ça serait
+plus facile de les refaire from scratch...
+## Deuxièmement parce que l'intégration de LDAP à tous les services est
+éprouvée (authentification, radius wifi, postfix, dovecot, apache...),
+contrairement à celle de postgresql (libnss-pgsql avait tendance à segfaulter
+aléatoirement)
+## Troisièmement parce qu'il y a des choses plus utiles et plus intéressantes Ã
+faire. Notre fonctionnement autour de LDAP est correct, pourquoi repartir de
+zéro ?
+## -- NicolasDandrimont <<DateTime(2012-10-30T11:50:52+0200)>>
+## Les réplicat SQL ont tendance à se désynchroniser et ne pas toujours super
+bien fonctionner.
+
+On oublie ce point pour l'instant, au vu des réponses, un jour… peut-être…
+
+### Switchs du bâtiment G
+
+## Daniel propose d'enlever des switchs inutiles au bâtiment G
+
+batg-2 et batg-7 pourraient être libérés pour remplacer des switchs en fault,
+en mettant des adhérents sur les switches gigabit. Il faudrait d'ailleurs faire
+jouer la garantie des switches défectueux. Ou les mettre à la poubelle/donner.
+
+### Questions diverses
+
+#### DNSSEC
+
+Valentin a activé la validation DNSSEC sur les résolveurs DNS du Cr@ns. Ça
+marche.
+
+Le point suivant serait de signer la zone Cr@ns. (Valentin propose aux
+apprentis présents (hint : ∅))
+Ça consiste à faire des tests.
+Attention : il faudra penser à pusher la clé publique chaque année.
+
+#### PXE
+
+Valentin veut migrer le PXE de sable vers charybde.
+
+#### Ménage Baie de disque
+
+Pierre-Elliott fera le ménage dans la baie de disques.
+
+#### DomU routage
+
+Valentin, toujours dans son idée de nettoyer sable des services, pour l'utiliser
+à d'autres fins, souhaite créer un domU de routage spécialisé pour les
+VLANs appartement, isolement, accueil, etc…
+On y mettrait aussi un serveur web pour servir les pages de déconnexion et finir
+(lentement) de démanteler squid.
+
+#### lc_ldap
+
+Il faut finir de coder lc_ldap et le documenter (pas forcément dans cet ordre).
+Sont motivés : Pierre-Elliott, Vincent, Olivier.
+
+#### Mails superflus
+
+Vincent propose de passer en revue tous les mails reçus par les nounous afin
+d'alléger le débit de mails. Olivier regardera avec Vincent.
diff --git a/compte_rendus/2012_11_15.md b/compte_rendus/2012_11_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..274027ff2c1b38de9c6f2cc5bbee973182515a75
--- /dev/null
+++ b/compte_rendus/2012_11_15.md
@@ -0,0 +1,84 @@
+# Réunion Nounous
+
+* Date : Jeudi 15 novembre 2012
+* Lieu : Salle Condorcet puis Fonteneau (Ã partir de 20h)
+* Début : 19h23
+* Fin : 21h04
+
+## Présents
+
+* Anne Cazalet (Synaps)
+* Ariane Soret
+* Daniel Stan
+* Lilian Besson
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Raphaël-David Lasseri
+* Valentin Samir
+* Vincent Le Gallic
+* Yann Duplouy
+
+## Ordre du jour
+
+### Serveur de logs
+
+Anne nous présente le serveur présent dans le dernier devis. Pas de
+compatibilité
+possible avec les anciens disques durs. On partirait sur des nouveaux disques
+durs
+SAS (4*300G). C'est un serveur milieu de gamme.
+
+### Garanties
+
+Un point est fait sur les garanties des serveurs (date d'expiration,
+renouvellement)...
+
+Cf. [[CatégorieCrans/LesServeurs]].
+
+### Autour de LDAP
+
+PEB a commencé à manipuler la base LDAP de test (en particulier avec la config
+qui est désormais une base LDAP). Il sait désormais modifier le schéma à la
+volée. Le but à terme et de travailler sur lc_ldap et de documenter à la fois
+le fonctionnement de ce script et de slapd et ses utilitaires.
+
+A priori, le howto sera prêt pour le séminaire ldap, mais sûrement pas le
+binding.
+
+### Wifi
+
+Il faut définir une date de workshop flashage, au moins pour les bâtiments A, B,
+C. et envoyer un mail. On essaie d'en faire une dimanche prochain, si motivé,
+avis aux volontaires (apprentis).
+
+Pierre-Elliott, Daniel et Ariane sont passés voir le directeur de la résidence
+qui nous a affirmé que le Crous de Créteil était favorable
+au projet WiFi. Pauline souhaiterait un accord écrit pour éviter tout problème.
+En attendant, il leur a proposé de rencontrer rapidement le responsable
+patrimoine vendredi 16 lors de sa rencontre avec le Bde.
+
+### Install Party
+
+On installe Ubuntu par défaut. Si Debian, faire attention, l'installeur est
+toujours (partiellement) pété.
+Le plus grand dilemme réside dans le choix de l'interface graphique : Unity,
+Gnome,
+ou Xfce ?
+
+Pauline propose que des gens soient dédiés à la présentation de différentes
+distributions/interfaces et soulève le problème de pédagogie des nounous. Elle
+préférerait que les installés soient davantage assistés dans leurs installations
+plutôt qu'une nounou s'occupe de tout. Il est en effet proposé de présenter une
+distribution Linux (celle de l'encadrant) pendant l'installation.
+
+Le PXE est accessible depuis peu (merci Valentin) sur le vlan accueil, donc
+sans enregistrer l'ordinateur. Il faudrait donc obtenir ce réseau en untagged
+Ã la Kfet.
+
+### Nounou encadrante
+
+Mettre à jour la page CransNounous, à défaut de précisions, la nounou encadrante
+est celle qui a donné les droits.
diff --git a/compte_rendus/2012_11_29.md b/compte_rendus/2012_11_29.md
new file mode 100644
index 0000000000000000000000000000000000000000..6785f256ad4058d9645215b7c23380870f2acc3c
--- /dev/null
+++ b/compte_rendus/2012_11_29.md
@@ -0,0 +1,145 @@
+# Réunion Nounous
+
+* Date : Jeudi 29 Novembre
+* Lieu : Condorcet
+* Début : 19h22
+* Fin : 21h26
+
+## Présents
+
+* Daniel Stan
+* Florian Tilquin
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Pauline Pommeret
+* Raphaël Cauderlier
+* Sylvain Boilard
+* Valentin Samir
+* Vincent Le-Gallic
+
+## Ordre du jour
+
+### Quotas
+
+Les quotas sont maintenant fonctionnels à travers NFS. Si la limite "soft" est
+dépassée, un mail est envoyé (par jour). Si la limite hard du quota
+est dépassée, l'appel système write retourne une erreur. On mettrait 2Go en
+limite soft et 2Go + e (e~=200Mo) de limite hard. Pierre-Elliott
+suggère d'activer les quotas sur zamok pour les adhérents.
+
+## Les quotas traversent le NFS, il faudrait mettre en application lesdits
+quotas
+## sur _tous_ les comptes, puis éventuellement lever ceux des membres actifs,
+## quitte à définir des conditions.
+## Il faut également tester si gest_crans les applique bien quelle que soit la
+## méthode de création de compte crans.
+
+### Wifi
+
+On a commencé au A, il faut continuer, le CROUS étant d'accord pour la pose.
+État du flashage : au moins la moitié des Pico``Stations et des Nano``Stations
+du M
+ont été flashées.
+Des Pico``Stations ont été posées aux 2, 4 et 6ème étages du bâtiment A.
+Valentin a commandé un tire-câble pour commencer à câbler au M.
+Il reste du travail, on va faire ça au fur et à mesure, quand on aura des
+apprentis motivés. On propose un framadate :
+http://framadate.org/rmcll82zw6p3fw75
+
+### Réunion DSI
+
+Gaetan, Raphaël, Morgane et Olivier ont rencontré la DSI (Stuart Mc``Lellan et
+Jocelyn Viallon) le 19 novembre.
+
+#### Débit
+
+L'ENS a un argrément gigabit avec Renater. Dans un premier temps, l'ENS nous
+autorise l'utilisation de 500Mbit/s entre 19h et 6h30. Komaz a l'air de souffrir
+par moments. En revanche, (cf graphes munin) on ne sature pas (après quelques
+minutes de load élevé). On va demander si on peut être débridés le week-end.
+
+#### Câblage du PdJ
+
+On peut avoir accès au sous-sol du PdJ, il faut décider du switch et de la date.
+
+Daniel propose un
+HP 1910-8G (JG348A) http://h10010.www1.hp.com/wwpc/fr/fr/sm/WF06b/12883-12883-4172267-4172281-4172281-4218346-5257664.html?dnr=1
+
+Il a l'air d'avoir toutes les fonctionnalités nécessaires (IGMP + MLD snooping,
+vlans). Le seul inconvénient est le management http(s)-only.
+
+On proposera le devis au C.A..
+
+#### Eduroam au PdJ
+
+Le C.A. a accepté la demande de la DSI concernant la diffusion d'eduroam au
+pavillon des jardins. Il nous faudra le mot de passe radius de l'E.N.S. pour le
+faire, et installer quelques picostations au PdJ.
+
+Il faudra ouvrir un VLAN pour cela.
+
+#### Réunions Crans/DSI/DSI des dpts/labos
+
+La DSI avait proposé qu'on participe à leur réunion de mardi dernier. Mais on a
+pas été recontactés. Olivier va leur envoyer un email pour plannifier la
+réunion suivante.
+
+#### Miroir debian de l'E.N.S.
+
+L'école voudrait nous confier la gestion de son miroir debian officiel.
+
+#### IPv6
+
+Le Crans est prêt, Rubis est prêt, l'E.N.S. non, pour des raisons
+administratives
+apparemment.
+
+### Surveillance de la correspondance MAC / chambre
+
+Suite à la détection d'un spoofeur de MAC de longue date. Valentin et Daniel
+envisagent de passer à une authentification par mot de passe sur le réseau
+filaire.
+Pierre-Elliott va bientôt mettre en place un script de surveillance utilisant
+les données fournies par les switchs (en snmp). Dans tous les cas, il faut
+un script de surveillance plus efficace que "déménagement non déclaré".
+
+### Monitoring du climat du 4J
+
+Olivier a fait une mini station météo qui se trouve au 4J pour surveiller
+l'évolution de l'humidité et de la température.
+
+### Questions diverses
+
+#### Remplacement switches HP
+
+On a remplacé 4 switches défectueux au niveau de HP. Pierre-Elliott recommencera
+dans un mois avec les suivants.
+
+#### club-bde@zamok /usr/sbin/rssh
+
+Vincent demande si on peut changer le shell du bde sur zamok.
+Parce backup-manager uploade des fichiers de backups sur le home Cr@ns du bde
+mais il ne peut pas les supprimer parce qu'un ssh lui est refusé.
+
+En fait c'est --(impossible)-- compliqué.
+
+#### Switch manageable à la Kfêt
+
+À faire s'il nous en reste. Le remplacement des switchs en fault dans les
+bâtiments
+reste prioritaire.
+
+#### Ldap
+
+olcLogging: il n'est pas possible de laisser les logs dans la même
+racine que les données logguées. Cela va compliquer l'implémentation de lc_ldap.
+On rappelle que la base ldap est censée stocker les chaînes en utf-8.
+So``Go et le champ mail : notre champ mail contient uniquement
+l'utilisateur (sans
+@crans.org). Normalement, la sémantique de ce champ est une adresse mail
+complète
+ce qui fait planter So``Go. Il faudrait donc changer cette valeur, et faire
+attention
+Ã tous les services que l'on risque de casser, ou utiliser un autre champ, ce
+qui
+produira une redondance dans les données. Des tests restent à faire.
diff --git a/compte_rendus/2012_12_13.md b/compte_rendus/2012_12_13.md
new file mode 100644
index 0000000000000000000000000000000000000000..cfbfc37790f2fa3bf19a4848cc72fddae9c4b84b
--- /dev/null
+++ b/compte_rendus/2012_12_13.md
@@ -0,0 +1,127 @@
+# Réunion Nounous
+
+* Date : Jeudi 13 Décembre 2012
+* Lieu : Salle Condorcet
+* Début : 19h25
+* Fin :
+
+## Présents
+
+* Aymeric Labatut
+* Daniel Stan
+* Olivier Iffrig
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Sylvain Boilard
+* Valentin Samir
+* Yann Duplouy
+
+## Ordre du jour
+
+### Serveur de logs
+
+Thot est installé (wheezy), et reçoit des données de tous les serveurs. Il faut
+voir si on souhaite modifier les requêtes d'insertion SQL, et donc la base de
+données.
+La priorité : définir la structure de base de données qu'on veut, pour pouvoir
+écrire
+les requêtes qu'on veut et qu'on mette le système en service.
+
+Les services sur pgsql (comptage d'upload, filtrage firewall, correspondance
+mac-prise)
+seront migrés sur thot.
+Valentin fait remarquer qu'il peut être bien de conserver un réplicat de la
+correspondance mac-prise, nécessaire à l'authentification radius.
+
+### Prochaine Debian stable
+
+Wheezy est bientôt dans les bacs.
+
+#### Repackaging de Bcfg2
+
+Le nouveau bcfg2 n'est pas compatible avec l'ancien, on a donc tout migré vers
+la
+nouvelle version.
+
+À savoir : les balises !ConfigFile, Directory, Symlink sont devenues Path, les
+scripts
+python ont leur propre balise Python.
+
+Reste à remettre en service bcfg2-repo-validate (utilisé par darcs).
+
+#### Passage sous wheezy des serveurs du crans
+
+A priori, pas avant que wheezy soit la nouvelle stable, mais il serait bien
+d'en discuter un peu avant.
+
+Il faudra faire attention Ã
+
+* dovecot
+* radius (l'appel de scripts externes est déprécié)
+* moinmoin (les patches vont bouder)
+* iscsi (sur les dom0 et le nfs)
+* portmap est déprécié (passage à rpcbind),
+
+il peut être envisagé de mettre à jour daath en dernier pour éviter les clashes
+
+Dans tous les cas, il va falloir se farcir les changelogs.
+
+### Script mac_prises
+
+On avait fait un script qui listait les adresses macs connectées dans chaque
+chambre, il faut ajouter des choses pour limiter au maximum le spoof non
+repérable.
+
+Par exemple, cela vaut-il le coup que thot stocke en base de données le triplet
+(mac, date, prise(s)), et qu'on bosse avec ce genre de données ?
+
+On va mettre une page sur le wiki pour des suggestions, et essayer de discuter
+avec
+le C.A., pour obtenir un réel cahier des charges. Après on commencera.
+
+### Installation des nouvelles bornes wifi
+
+Quelques bornes ont été placées au M, d'autres au A, il faut continuer, et
+trouver
+des apprentis motivés !
+
+### Lien Gigabit vers l'extérieur
+
+Prochainement, une réunion avec la DSI pour parler gigabit le weekend, et
+éventuellement augmenter un peu en journée.
+
+### TV
+
+Daniel a testé la diffusion de la TV avec un Raspberry Pi. Ça lag, à voir si
+c'est
+parce que ça capte mal ou parce que manifestement l'USB et l'Ethernet passent
+par
+le même bus sur la carte.
+Les serveurs free n'étaient, à l'époque où ils ont été reçus, pas compatibles
+avec
+les cartes, il faudrait voir pour quelle raison.
+Il faudrait réfléchir à d'autres solutions.
+
+Quid de l'amplification des signaux TNT ?
+
+#### HD
+
+Vu que la HD n'est pas supportée par tous les PC, et que "c'est l'avenir", on
+pourrait
+imaginer baisser la résolution pour que les gens qui n'ont pas une machine assez
+puissante puissent quand même regarder la TV. Problème : ça demande de la
+puissance
+de calcul... À voir si on a envie de le faire.
+
+Dans un premier temps, on pourrait passer le flux TV d'une chaîne vers malloc
+ou une autre machine pour faire des tests de transcodage.
+
+### Divers
+
+#### Imprimante
+
+On va appeler Thomas Hocine pour lui dire que le service après-vente ne
+respecte pas vraiment les
+clients, et que par conséquent, le C.A. s'interroge vraiment sur la pertinence
+de signer
+le contrat.
diff --git a/compte_rendus/2013_01_10.md b/compte_rendus/2013_01_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..249be7b1ddfac371704177263e887ccaca4e7fd1
--- /dev/null
+++ b/compte_rendus/2013_01_10.md
@@ -0,0 +1,223 @@
+# Réunion Nounous
+
+* Date : Jeudi 10 janvier 2013
+* Lieu : Condorcet
+* Début : 19h16
+* Fin : 21h36
+
+## Présents
+
+* Ariane Soret
+* Daniel Stan
+* Lucas Serrano
+* Olivier Iffrig
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Raphaël Bonaque
+* Raphaël Cauderlier
+* Valentin Samir
+* Vincent Le Gallic
+* Yann Duplouy
+
+## Ordre du jour
+
+### Gmail
+
+### Depuis mi-décembre, Gmail refuse de récupérer les mails depuis les serveurs
+### dont il ne reconnaît pas la validité de l'autorité de certification, CACert
+### faisant partie des autorités non reconnues
+Depuis le 12/12/12, Gmail a changé sa politique de vérification des certificats
+SSL, CAcert ne fait plus partie des autorités de certification reconnues comme
+"de confiance" et les utilisateurs ne peuvent pas changer ce comportement.
+
+Les adhérents Cr@ns ne peuvent donc plus relever leurs mails Cr@ns sur leur
+boîte Gmail.
+
+La situation et la marche à suivre pour les adhérents sont ici :
+https://wiki.crans.org/VieCrans/GMailSucks
+
+Le Cr@ns pourrait proposer un autre serveur imap avec un certificat d'une autre
+autorité.
+En dehors du problème idéologique et de "flemme", cette solution implique tout
+de même de continuer à encourager les adhérent à donner leur mot de passe Cr@ns
+Ã Google.
+
+L'avis général semble être plutôt de rester dans la situation actuelle.
+Daniel (avec un apprenti [les absents, levez la main]) va tout de même essayer
+de mettre en place un serveur imap alternatif.
+
+Valentin soulève la question d'un mot de passe alternatif (optionnel) permettant
+de s'authentifier sur les serveurs mail / imap / ... seulement.
+À voir si c'est possible.
+
+### SIP
+
+Le SIP (Session Initiation Protocol) est un protocole de signalement
+permettant de mettre en relation deux pairs. Il est principalement
+utilisé dans le cadre de la téléphonie sur Internet (Voix sur IP).
+
+{{{asterisk}}} a été ressuscité et le Cr@ns possède une ligne SIP chez OVH.
+Le service a donc été mis en place et est maintenant disponible pour les
+adhérents.
+Modulo l'installation d'un client SIP et une connexion internet,
+les adhérents peuvent donc téléphoner. Dans un premier temps entre comptes SIP
+Cr@ns, mais il y a également une passerelle vers l'extérieur.
+
+L'interface sur l'intranet2 permet l'inscription, la gestion de sa configuration
+(mot de passe, code perso de la messagerie, se masquer dans l'annuaire), un
+annuaire…
+
+Pour les utilisateurs, c'est en test : https://intranet2.crans.org/voip/
+
+Reste à faire :
+
+* Documentation technique
+* Documentation d'utilisation (Yann s'occupe d'Android, iOS ?)
+* Facturation de la passerelle (prix coûtant? On utilise le compte impression?)
+* Service d'impression ? (notification des impressions, dictée du digicode)
+* Numéro unique vers la Nounou d'astreinte ?
+
+Bref, il y a plein de possibilités.
+
+### DNS
+
+#### DNSSEC
+
+DNSsec est une extension du protocole DNS qui permet de signer numériquement
+les réponses des requêtes DNS.
+
+Elle (l'extension) a été mise en place par Valentin sur le domaine
+{{{crans.eu}}}.
+
+À terme, il serait bien de signer {{{crans.org}}}
+
+Il n'est pas possible pour un serveur de répondre qu'il a effectuer une
+validation
+dnssec s'il est autoritaire pour la réponse.
+Il pourrait être bien de séparer DNS récursif et autoritaires.
+
+#### Renouvellement nom de domaine
+
+{{{crans.fr}}} expire dans une cinquantaine de jours. Il ''faut'' le renouveler.
+Olivier s'en occupe.
+
+#### Champs DNS
+
+Valentin a rajouté un champ TXT dans les réponses DNS des bornes wifi,
+qui contient : {{{"LOC %f,%f" % (latitude, longitude)}}}.
+
+Il désirerait aussi rajouter un champ SSHFP pour pouvoir transmettre les
+fingerprints SSH des serveurs. Combiné à DNSSEC, cela permettrait de s'assurer
+de l'absence de Man in the Middle quand on se connecte à un serveur en SSH.
+
+À étudier plus profondément.
+
+### Documentation Sphinx
+
+### Olivier a mis en place de quoi documenter le nouveau binding LDAP avec Sphinx
+C'est une librairie pour python qui permet de générer automatiquement de la
+documentation.
+
+Olivier l'a mise en place pour {{{lc_ldap}}}. C'est beau, il faut continuer.
+
+### Wifi
+
+Le bâtiment M est couvert sur tous les étages sauf le 4ème et le 5ème Nord.
+Le bâtiment A est couvert aux étages pairs.
+Le reste est à faire.
+
+On va fixer un rendez-vous régulier, par exemple le dimanche une fois tous les
+quinze jours.
+
+### IRC
+
+Dancer-ircd, le daemon IRC actuel, ne semble plus très maintenu et manque de
+features, principalement un support de SSL et de l'ipv6.
+On souhaiterait donc changer de daemon pour quelque chose de plus moderne.
+
+UnrealIRCd semble bien mais n'est pas package pour Debian (voir
+http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130)
+
+daemons packages sous squeeze :
+
+* dancer-ircd
+* inspircd
+* ircd-hybrid
+* ircd-irc2
+* ircd-ircu
+* ircd-ratbox
+* ngircd
+
+Supportant SSL d'apres
+https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons
+
+* inspircd
+* ircd-hybrid
+* ircd-ratbox
+* ngircd
+
+Supportant l'IPv6 d’après la même page: tous
+
+inspircd ftw ?
+
+Pierre-Elliott va se pencher sur inspircd qui a l'air packagé, supportant SSL,
+IPv6 et pas trop "pain in the ass" Ã configurer.
+
+Il faudra contre-annoncer pour dire que finalement on ne fera pas de changement
+Dimanche.
+
+### Mail
+
+#### Champ mail dans la base LDAP
+
+Le champ mail a été modifié dans la base LDAP pour pouvoir être utilisé
+par !SoGo
+(c'est-Ã -dire que l'on enregistre dans tous les cas une adresse mail, et non le
+login lorsque l'adhérent a un compte Cr@ns). PE avait effectué dans un premier
+temps la modification sur son propre compte afin de chasser les bugs dans les
+scripts qui supposaient manipuler un login (et non une adresse mail).
+
+#### Réécriture des en-têtes mail
+
+Pendant un certain moment, dans les mails envoyés et reçus, toutes les adresses
+mails envoyées et reçues étaient automatiquement remplacées par
+Prenom.Nom@crans.org (''i.e.'' l'alias canonique). Cette réécriture a été
+désormais
+désactivée, ce qui a posé des problèmes pour déterminer le destinataire final
+du mail et il a fallu corriger après coup les filtres de recherches dans
+la configuration postfix.
+
+Ceci explique quelques dysfonctionnements dans l'acheminement des mails pendant
+environ une semaine.
+
+### Tests de configuration des services
+
+Suite à ces problèmes, iota propose la mise en place de serveurs alternatifs
+afin de tester les configurations de services critiques.
+PEB a remplacé les adresses mail dans la base LDAP par leur version avec
+@crans.org. On a en même temps supprimé la réécriture d'en-tête des emails.
+Cela a malheureusement engendré des bugs, et la perte de mails.
+
+De manière générale, il faut faire attention lorsqu'on touche à des services
+critiques en place dont on ne maîtrise pas la façon dont ils loguent
+(dovecot, postfix), bien lire la doc, et surtout demander aux développeurs
+des services si on a un doute concernant une fonctionnalité.
+
+### Bug tracking, projets
+
+On a deux bug trackers, debbugs (http://bugs.crans.org) et
+redmine (https://tracker.crans.org), plus éventuellement des todolists sur le
+wiki.
+L'idée est de se décider sur lequel on utilise. On garde redmine.
+
+Raphaël propose également d'utiliser une catégorie wiki !CategorieProjetEnCours.
+
+### Passage à Git
+
+Deux outils de versionnement présente plusieurs inconvénients :
+
+* Plus de commandes à connaître, et risque de s'embrouiller
+* Nos dépôts darcs ne sont pas à jour.
+
+On se propose de passer nos dépôts darcs sous git.
+Vincent et Daniel s'en occupent et encadreront Pauline.
diff --git a/compte_rendus/2013_01_24.md b/compte_rendus/2013_01_24.md
new file mode 100644
index 0000000000000000000000000000000000000000..f0d21f50e890ffa4546b162585842cb3c8affbb0
--- /dev/null
+++ b/compte_rendus/2013_01_24.md
@@ -0,0 +1,109 @@
+# Réunion Nounous
+
+* Date : 24 Janvier 2013
+* Lieu : Condorcet
+* Début : 19h27
+* Fin : 21h17
+
+## Présents
+
+* Ariane Soret
+* Daniel Stan
+* Olivier Iffrig
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Raphaël-David Lasseri
+* Sylvain Boilard
+* Thomas Epalle
+* Valentin Samir
+* Vincent Le Gallic
+* Yann Duplouy
+
+## Ordre du jour
+
+### Script d'impression par l'interface web
+
+L'impression par le driver de l'imprimante sur {{{zamok}}} pose certains
+problèmes
+qui sont évités quand on fait des impressions manuelles, c'est pourquoi il avait
+été proposé d'automatiser l'impression par l'interface web de l'imprimante de
+manière à ne plus avoir à se servir du driver.
+
+Ce travail peut être fait par un apprenti. Ariane est motivée. Vincent encadre.
+
+### Groupe fuse sur zamok
+
+Valentin propose d'autoriser les utilisateurs à utiliser fuse sur zamok. On
+évitera d'autoriser la lecture aux autres utilisateurs que le propriétaire
+(potentiels problèmes d'upload par apache, updatedb, etc)
+
+On ajoute le groupe fuse à ldap pour y mettre tous les utilisateurs
+
+### Identification des machines dans l'annuaire LDAP
+
+## cf. mail de PEB sur nounous@ du 23 janvier à 05:56
+Actuellement un mid est associé, par le biais d'une fonction inversible à une
+adresse ip.
+Cela force la réutilisation des mid au cours des ans et est gênant pour
+l'identifiaction d'une machine sur le long terme. Il est proposé de rendre le
+mid strictement croissant et le remplacer par un rid.
+Il sera également utilisé pour attribuer un préfixe ipv6 aux machines.
+De plus, il devient possible de libérer les adresses ips tout en gardant dans la
+base de donnée les adresses mac des machines (avant, il fallait absoluement
+supprimer
+la machine pour libérer le mid et l'ip associé)
+
+Il est proposé de garder une plage de mid libre de 1 à 4096 par exemple pour les
+machines crans (serveurs, adm, bornes wifi, …)
+puis de commencer à utiliser de façon continue les mid à partir de là .
+
+### Documentation des scripts
+
+Olivier a commencé à ajouter une documentation sphinx au nouveau binding LDAP.
+Reste la question du serveur web.
+Il pourait être bien de remplacer l'apache de niomniom par nginx ; à des fins de
+test, on pourrait faire tourner nginx sur un autre port en parallèle d'apache,
+le temps de porter la configuration d'apache sous nginx.
+
+### Recâblage du PdJ
+
+Le switch est arrivé.
+C'est fait, modulo utilisation du gbic intégré: il nous faut plus de jarretières
+optiques (brassage <-> gbic).
+Le plan de câblage sera prochainement mis à jour.
+
+### Routage du WiFi
+
+On a commencé à vider gordon de ses services : eap pour l'auth wpa2 et
+routage direct via komaz (résout les prob liés au routage)
+log direct via thot, dns sur les serveurs du vlan adhérent.
+
+### Démission du RTC
+
+Olivier déménage et démissionne de son poste de RTC. Valentin prend la
+succession.
+
+## Question Diverses
+
+### Séparation des dns récursif et autoritaires
+
+Valentin est en train de faire la configuration adéquate.
+De plus, la déléguation du reverse dns des ips allouées au crans par l'ens n'est
+propagée correctement. En effet sur les 4 NS parent, un seul d'entre eux
+(ariane.ens-cachant.fr) délègue les plages vers les NS du crans.
+
+### Incident Matinal
+
+Suite sans doute à un incident de communication entre fz et la baie de disque,
+les domu présents sur icelui n'ont plus été en mesure d'assurer leurs services
+respectifs. Vert étant parmis eux, cela a affecté l'ensemble des serveurs du
+crans.
+Les domu ont été migrés vers fy. Komaz, zamok, sable,… ont été redémarrés.
+
+### Augmentation du débit le week-end
+
+Cf mail sur dsi-crans puis Nounou, la DSI est d'accord pour accorder une
+augmentation du débit le week-end à 500Mbit/s. Cette augmentation sera valable
+du vendredi 20h30 au lundi 6h00.
+
+* le mail disait 20h. -- ZeldAurore <<DateTime(2013-01-25T12:59:56+0200)>>
diff --git a/compte_rendus/2013_02_07.md b/compte_rendus/2013_02_07.md
new file mode 100644
index 0000000000000000000000000000000000000000..4d901c815e2b4dac924116081c07ff4b469adad5
--- /dev/null
+++ b/compte_rendus/2013_02_07.md
@@ -0,0 +1,148 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 7 Février
+* Lieu : devant le Condorcet
+* Début : 20h08
+* Fin : 22h25
+
+## Présents
+
+* Ariane Soret
+* Daniel Stan
+* Pierre-Elliott Bécue
+* Sylvain Boilard
+* Valentin Samir
+* Vincent Guiraud
+
+## Ordre du jour
+
+### Mac/Prise
+
+Pierre-Elliott a continué à coder mac-prise en utilisant une base postgres.
+Il compte le nombre de mac pour une chambre donnée sur plusieurs intervalles
+(2 min, 30 min, 1 jour). Il y a plusieurs heuristiques qui donnent des
+valeurs différentes ("très suspect", "suspect") plus ou moins fonction du
+nombre de fois qu'une même mac apparaît dans le réseau et du nombre de mac
+apparaissant sur une prise et du temps.
+
+Il est suggéré de ne pas tenir compte des macs inconnues qui pourraient être
+récupérée (mac virtuelle, jamais enregistrées), si le script devient trop
+verbeux.
+
+Pour l'instant, il est en test sur une ml du même nom, et sera mis en prod
+après quelques réglages.
+
+Le script effectue de nombreux appel à ldap, il est donc envisagé de mettre un
+réplicat sur thot.
+
+### Passage à Git
+
+Le dépôt /usr/scripts est migré. (il ne faut plus record sur darcs)
+Il faut supprimer les mail de darcs whatnews et avoir avoir un équivalent pour
+git.
+Le dépot bare se trouve sur git.crans.org qui est public, il faudrait vérifier
+qu'il n'y a pas de mot de passe recordé dedans au cas où (grep).
+
+On peut migrer bcfg2 n'importe quand. Il faut finir de tout recorder avant.
+
+Il reste à trouver un joli hook pour les mails (genre modifs non
+commitées/pushées)
+voire une vérif d'intégrité : vérifier que le dépot bare et de prod aient la
+même HEAD.
+
+### WiFi
+
+#### Ipv6
+
+On annonce un slash ipv6 en wifi, ça marche. (Parce que Daniel a une machine
+ipv6 only chez lui)
+
+#### Freecwmp
+
+freecwmp, implémentation du protocole CWMP pour openwrt destiné à contrôler Ã
+distance des équipement divers, dont nos bornes wifi.
+Trois élèves du département informatique ont travaillé sur un projet autour de
+ce protocole, et se disent qu'il serait pratique de l'utiliser pour configurer
+nos bornes avec et de garder le moins de configuration possible dans la branche
+openwrt du crans afin de faciliter son maintien.
+
+Le serveur de configuration est actuellement en cours d'écriture comme une
+application django.
+
+#### Arpej'
+
+Arpej (aka résidence Volti) est une résidence privée mitoyenne au campus où de
+nombreux élèves de l'ENS logent.
+Elsa Perdrix à rappelé qu'il y avait eu autrefois un projet de faire un pont
+wifi pour relier le bâtiment au réseau.
+Il y a normalement encore une borne sur le toit du d'Alembert pour ça. Quand Ã
+celle de l'Arpej'…
+
+Daniel fait remarquer que cela ajoute une charge de travail supplémentaire sur
+les membres actifs et que la viabilité à long terme d'un pont wifi est
+incertaine.
+
+Il faudrait voir à nouveau avec l'ENS s'il existe un tunnel jusqu'Ã
+l'Arpej' pour
+tirer une fibre.
+
+#### Pdj
+
+La dsi aimerait bien qu'on diffuse eduroam au PDJ pour les chercheur visiteur.
+Pour ça il faut des bornes :
+
+* Combien ?
+* On les mets où ?
+
+Il faut faire des tests de couverture, faire un dossier et demander un budget
+au CA.
+Pour mettre des bornes dans les faux plafonds il faut l'accord de la DGS.
+
+On essaiera de faire les tests ce week-end.
+
+### Firewall
+
+#### Comptage Upload
+
+Il faut adapter le comptage d'upload à l'ipv6 pour pouvoir compter par mac, et
+éventuellement faire évoluer la déconnexion.
+Actuellement il y a un petit programme qui rempli une table d'association
+mac-ip, il est envisageable d'effectuer une jointure.
+
+Un autre problème est que pour compter directement par mac, il faudrait compter
+sur l'interface interieure, et qu'alors, on comptera également du traffic
+potentiellement rejeté par le firewall.
+
+#### Filtrage p2p
+
+le filtrage p2p devient **vraiment** obsolète, avec de plus en plus de faux
+positif,
+Valentin voudrait s'en débarrasser.
+Il faut demander à la dsi si on peut le jetter.
+Le problème est l'adhérent faisant du piratage : C'est la dsi qui reçoit les
+lettres des ayant droits et cela pose un problème de réputation de l'École.
+
+Il est envisageable de continuer de bloquer ce que l'on détecte mais de ne plus
+déconnecter les gens.
+
+/!\ Il faut discuter de ce point au prochain CA
+
+#### Déconnection pour upload
+
+Actuellement les adhérents dépassant 4Go/24h de téléchargement se font
+déconnecter pour 24h.
+Il est proposé de juste brider la vitesse de ceux dépassant la limite.
+
+Il faut définir à quel point.
+On peut penser les mettre derrière la freebox puisqu'elle ne sert plus à rien
+en temps normal
+
+/!\ Il faut discuter de ce point au prochain CA
+
+### Réunion DSI
+
+* Réverse dns
+* filtrage p2p
+* upload
+* eduroam au Pdj : mdp du serveur radius, voir comment on fait…
+* null route sur le /16
diff --git a/compte_rendus/2013_03_07.md b/compte_rendus/2013_03_07.md
new file mode 100644
index 0000000000000000000000000000000000000000..cc4be3ac68895ac21c9e3e75ac6df1912494b34c
--- /dev/null
+++ b/compte_rendus/2013_03_07.md
@@ -0,0 +1,128 @@
+# Réunion Nounous
+
+* Date : Jeudi 7 mars 2013
+* Lieu : Condorcet
+* Début : 19h42
+* Fin : 21h42
+
+## Présents
+
+* Ariane Soret
+* Daniel Stan
+* Olivier Iffrig
+* Sylvain Boilard
+* Valentin Samir
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Réunion DSI
+
+Valentin et Daniel sont passés voir la DSI la semaine dernière (suite à la
+découverte par Sabrina d'une borne wifi).
+Les gens du Léonard de Vinci veulent du wifi, elle voulait donc voir si on
+pouvait remettre les anciennes bornes, ou même des nouvelles.
+On leur a d'ailleurs prêté le lendemain une pico pour leur montrer à quoi elles
+ressemblent.
+
+La DSI veut à terme pouvoir jeter les wifi ouvert et ne laisser que eduroam.
+Puis utiliser un outils comme !PacketFence pour effectuer de la délégation vers
+les labo/dpt pour les autorisations d'accès.
+
+Nous avons été invités à la réunion des DSI des divers département du lendemain.
+Parmi les points évoqués, le fait de scanner le home des adhérents à la
+recherche de virus semble une bonne idée.
+
+### Documentation
+
+Il ''FAUT'' mettre à jour les lien vers les pages wiki déplacées. Une idée des
+pages concernées peut s'obtenir
+Ã l'aide du listing des pages orphelines : https://wiki.crans.org/OrphanedPages
+Le plus simple étant d'effectuer une recherche sur le nom de l'ancienne page et
+de modifier les résultats trouvés.
+
+Une restructuration du Wiki a été entamée par Pauline, il reste aussi Ã
+documenter de nombreux services.
+Avis aux nounous (et apprentis) ayant installé un de ces services non
+documentés.
+
+Côté doc Sphinx : il faut l'utiliser, documenter ce qui ne l'est pas. (make
+coverage, make html).
+par exemple, la liste des objets non documenté
+dans {{{lc_ldap}}} : http://doc.crans.org/lc_ldap/coverage.html
+
+### Instabilité de la connexion
+
+Des problèmes de connexions de faible durée ont eu lieu la semaine dernière.
+Rien à signaler sur le réseau du Cr@ns,
+cela vient vraisemblablement du lien Renater, cf
+http://pasillo.renater.fr/TICKETS/historique-tickets.incidents.html
+
+### Résidence Jacques Restignat
+
+Ariane a rappelé le gérant de la résidence aujourd'hui. Il n'a pas encore
+acheté de borne WiFi (il pensait le faire lui-même).
+Un devis a été demandé chez Orange.
+
+La question de la connexion à Internet elle-même n'a pas été rediscutée mais
+doit être étudiée.
+
+### CAS
+
+Il reste à synchroniser les comptes Wiki et LDAP (la gestion sur l'intranet est
+OK) pour pouvoir mettre le CAS sur le Wiki.
+Les webmail SOGo et Horde restent aussi à faire (la DSI nous a conseillé pour
+SOGo).
+
+### Logs Ldap / generate
+
+Il devient de plus en plus urgent de journaliser les modifications effectuées
+via le nouveau binding lc_ldap.
+On pensait utiliser olcAccess avec un attribut last_modifier sur chaque objet
+pour savoir qui a fait la modification. Ainsi, on
+peut utiliser une connexion cn=admin tout en maintenant une trace des auteurs
+des modifications.
+
+Il serait alors possible de lire la base de log pour generate (en se souvenant
+de l'endroit où on s'était arrêté).
+
+Il faudrait également revoir le système de lock qui actuellement entre en
+conflit avec un certain nombre d'exécution
+automatique de scripts. En effet, le système actuel semble être ennuyant pour
+les utilisateurs, et peu efficace pour la
+sûreté des scripts (un objet locké provoque un arrêt complet du script, pour
+exception non rattrapée même dans un cron).
+On pourrait utiliser un système plus souple de vérification, au moment de la
+modification, si une modification a eu lieu depuis la lecture de
+l'objet.
+
+### Migration vers git
+
+Les dépôts bcfg2 et usr-scripts sont passés sur git. Les hooks de notification
+irc et mails sont fonctionnels.
+Il faut migrer les dépôts usr-scripts des serveurs n'ayant pas de NFS (ovh et
+les dom0).
+Il reste également à passer les dépôts des /etc/ des serveurs sous git. Ceci
+permettrait de gérer les permissions sur les fichiers.
+
+La question est de savoir si ces dépôts sont considérés privés ou si on évite
+de mettre des mots de passes sensibles dedans.
+On peut aussi, quitte à éviter les mots de passes en clair, abandonner le
+versionnement des /etc/ et utiliser uniquement
+la génération des configurations via bcfg2.
+
+### Solution de partage de fichiers
+
+Le BDE et les associations partenaires ont demandé un espace de travail pour le
+groupe de travail sur la convention de vie étudiante.
+Il n'ont pas de cahier des charges précis, on peut leur proposer :
+
+* Un wiki sur une page perso club (Aurore MM. est en train de voir ce qu'elle
+ peut tirer de !DokuWiki)
+* Etherpad
+* [[http://sparkleshare.org/|SparkleShare]]
+
+### SPAM
+
+On se fait plus spammer qu'avant.
+Il a été émis l'idée que le greylisting pourrait chier dans la colle. À voir.
diff --git a/compte_rendus/2013_04_04.md b/compte_rendus/2013_04_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..ad613b41c35d7bf2de173a87485a784f709c549a
--- /dev/null
+++ b/compte_rendus/2013_04_04.md
@@ -0,0 +1,241 @@
+# Réunion Nounous
+
+* Date : Jeudi 4 avril 2013
+* Lieu : Condorcet
+* Début : 19h30
+* Fin : 21h34
+
+## Présents
+
+* Daniel Stan
+* Lucas Serrano
+* Pauline Pommeret
+* Raphaël-David Lasseri
+* Thomas Epalle
+* Valentin Samir
+* Vincent Guiraud
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Pénurie d'IPv4
+
+Valentin a fait un petit ménage dans les IP wifis, nous sommes passés
+de 98% Ã 92% :
+http://munin.crans.org/association.crans.org/adresses-ip/index.html
+
+C'est néanmoins préoccupant.
+
+19 "personnes" sans aucuns droits possèdent plus de 5 machines, 42 en ont plus
+de 4 machines wifi.
+
+On peut supprimer les machines qui ne se sont pas connectées depuis un certain
+temps (en parsant les logs d'authentification wifi) ou donner des IP dynamiques
+en wifi.
+Lors du changement de bornes, la même IP serait attribuée. La deuxième option
+est plus difficile à mettre en place.
+
+La première solution est plus simple à mettre en place mais elle est moins
+efficace. Valentin pense que ça prendra 1h30 Ã
+une nounou, un apprenti peut être encadré pour faire le script.
+Qu'est ce qu'une machine sans activité ? Pour l'instant, c'est 1 an. On peut
+envisager d'envoyer un mail aux propriétaires des
+machines qui ne se sont pas connectées en wifi depuis {{{n}}} mois leur
+demandant s'ils souhaitent toujours conserver cette machine
+(par exemple en cas de stage de plusieurs mois).
+
+Lorsque la machine s'authentifie à freeradius, si elle n'a pas d'IP, elle
+bascule sur Cr@ns-accueil ("tu n'as pas d'IP attribuée, clique ici pour en
+obtenir une"). "Cela demande un travail non nul" (Daniel). L'ancien
+binding LDAP présuppose qu'une machine a une unique IP.
+Mettre une IP par défaut, c'est mal et ça prendra autant de temps que de
+patcher l'ancien binding.
+
+Est-ce qu'on s'accélère pour mettre en place
+l'[[CransTechnique/AdminRéseau/IpV6|IPv6]]-only sur le wifi ?
+Daniel suggère de partager le travail pour que ça aille plus vite : la partie
+création de machine sur
+l'[[CransTechnique/ServicesMineurs/IntraNet*|intranet]], le taggage de vlan sur
+les bornes et [[CransTechnique/Services/RaDius|freeradius]],
+le [[CransTechnique/Services/FireWall|parefeu]], etc.
+
+(NB: on en peut pas mettre les [[CransTechnique/AdminRéseau/IpV6|IPv6]]-only et
+les IPv4 et [[CransTechnique/AdminRéseau/IpV6|IPv6]] sur le même réseau, sinon
+tout devient [[CransTechnique/AdminRéseau/IpV6|IPv6]]-only.)
+
+Il ne faut pas lancer le script qui supprime les IP avant que les adhérents
+aient la possibilité de récupérer une IP.
+Il faudra également envoyer un mail aux adhérents leur expliquant tout ça.
+
+Il faut faire un script qui lit les logs de l'authentification wifi et met Ã
+jour une base de données.
+
+Thomas, Lucas et Pauline sont motivés, Daniel se charge de les coacher, de les
+motiver et de les inspirer.
+
+### Nouveau firewall
+
+Valentin a commencé à réécrire le firewall IPv4, en utilisant le nouveau
+binding (optimisation mémoire de [[http://doc.crans.org/lc_ldap/|lc_ldap]] à la
+clé \o/) en le
+remettant au propre. Il est conçu pour faciliter la mise à jour des blacklist
+et la gestion de la QoS (partage et limitation des débits). Il se
+génère aussi plus vite que l'ancien.
+Actuellement, il est assez sale et illisible, Ã cause des rajouts successif de
+petits bouts de-ci de-là depuis … longtemps.
+
+Il y a un pare-feu
+sur [[CransTechnique/PanthéonServeurs/ServeurKomaz|komaz]] mais aussi
+sur [[CransTechnique/LesServeurs/ServeurZamok|zamok]] par exemple (qui évite
+que les adhérents déconnectés puissent
+l'utiliser comme proxy) , et il faut les réécrire. Ce sera potentiellement plus
+simple.
+
+Il faut tester le nouveau pare-feu
+de [[CransTechnique/PanthéonServeurs/ServeurKomaz|komaz]], à une heure où il
+n'y a pas trop de monde. Valentin est confiant, en particulier sur la vitesse
+de génération. {{{tc}}} (qui gère la QoS) ne plante pas.
+Si la documentation est correcte, il y aura (grosso modo) une seule règle de
+classification des paquets (par {{{tc}}}) au lieu de 7000,
+au prix d'une légère différence au niveau des règles de partage: le débit sera
+partagé par machine au lieu d'un partage par adhérent
+(ce qui est équivalent dans la majorité des cas).
+
+Il faut changer de pare-feu
+sous [[CransTechnique/PanthéonServeurs/ServeurKomaz|komaz]] avant le passage
+Ã {{{wheezy}}}, parce que l'ancien ne marchera plus !
+
+A priori, sous {{{wheezy}}}, il n'y aura qu'Ã appliquer la configuration
+d'{{{iptables}}}, ce qui sera plus efficace que la façon de faire
+actuelle.
+
+### WiFi
+
+#### Avancement
+
+La couverture wifi au H a été grandement amélioré avec l'ajout de 4 nouvelles
+bornes wifi.
+Le J est en cours de couverture (Ariane, Thomas, Vincent Guiraud et
+Raphaël-David continuent ce dimanche).
+
+Il reste le G, le C, et à terminer le A et B. Quitte à changer les bornes du C,
+il faudra changer le switch dans le local ménage/électrique
+du 5C (les [[CransTechnique/AutreMatériel/PourquoiSwitchsHP|switchs Dlink ne
+supportent pas le multicast]]).
+
+#### Tests de couverture au PdJ
+
+Il faut faire des tests de couverture au PdJ afin de prévoir le nombre de
+bornes à commander. Cela consiste à poser une borne et regarder jusqu'où on
+arrive à la capter.
+
+Il faut voir avec la DSI les modèles de bornes qu'elle compte acheter afin
+d'envisager une commande groupée.
+
+Daniel a un coup de cœur pour les Ubiquiti !UniFi Long Range
+avec 2 antennes (même prix que les bornes actuelles mais plus puissantes).
+
+Si l'on achète des bornes, on pourrait en prévoir pour le plafond de la salle
+de conférence du PdJ (grande capacité d'utilisateurs).
+
+#### Parlons CROUS
+
+Un habitant du rdc du bâtiment M veut qu'on arrive à tirer un câble jusque chez
+lui et passer sur le brassage Cr@ns. Mais, c'est manifestement interdit. Il ne
+capte pas non plus sur le wifi chez lui.
+
+Au bâtiment H, un câble a été tiré à l'arrache par le CROUS il y a un peu plus
+d'un an. Cette personne est adhérente au CROUS,
+il faut lui suggérer d'appeler la hotline.
+
+Nous ne sommes, selon la charte Crans-CROUS-ENS, chargés que du brassage et pas
+de l'entretien des câbles et des prises.
+Effectivement, il s'agit de propriétés du CROUS.
+
+### Miroirs
+
+#### Debian officiel
+
+Valentin et Raphaël-David sont passés à la DSI au sujet de la gestion du miroir
+Debian officiel de l'ENS. Il suffit donc d'envoyer un
+mail disant que l'on a changé de machines puis prévenir la DSI. Il faut faire
+disparaître webb.ens-cachan.fr dans les listes des
+miroirs.
+
+Il faut faire pointer {{{debian.ens-cachan.fr}}} vers notre miroir Debian.
+
+Les {{{iso}}} Debian prennent énormément de place, mais a priori nous ne sommes
+pas obligés de les avoir. (ouf !)
+
+Notre miroir supporte la charge, s'il est plébiscité on pourrait envisager de
+rajouter de la RAM Ã [[CransTechnique/LesServeurs/ServeurCharybde|Charybde]].
+
+[[CransTechnique/LesServeurs/ServeurCharybde|Charybde]] ne sera plus bridé.
+
+#### VideoLAN
+
+Nous étions miroir de VidéoLAN par le passé, le dépôt vlc est d'ailleurs
+toujours synchronisé sur notre ftp. Ils demandent à faire
+revivre le partenariat. Le problème est qu'ils souhaiteraient une
+connectivité gigabit ce qui n'est actuellement pas le cas. On leur
+répond que nous sommes d'accord pour devenir miroir officiel dans la limite de
+nos moyens (bande passante
+limitée).
+
+### Contrat Mécénat de Free
+
+Un contrat de mécénat a été passé avec la fondation d'entreprise Free, qui nous
+fournit gracieusement deux serveurs
+(Dell, 16 Go de RAM, 2To, Xeon E3 2.4GHz).
+
+Parmis les projets de ces serveurs : [[CransTechnique/Services/NfS|NFS]] des
+adhérents, [[CransTechnique/Services/Virtualisation|virtualisation]] de
+machines pour les clubs, transcodage vers
+la [[CransTechnique/ServicesMineurs/TV|TV]].
+
+### Renouvellement des serveurs TV
+
+Les serveurs TV actuels sont très vieux et meurent les uns après les autres.
+Une alternative à base de [[http://fr.wikipedia.org/wiki/Raspberry_Pi|raspberry
+pi]] a été
+envisagée en vain. On s'oriente donc plutôt vers une solution similaire avec
+des tours récentes
+
+Il faut préparer un devis pour le [[../Jeudi11Avril2013|jeudi 11 avril 2013]].
+Daniel s'en charge.
+
+### Rencontre avec MiNET
+
+Il faudrait préparer des présentations sur ce que l'on fait au Cr@ns, ils le
+verront aussi de leur côté.
+
+On pourrait parler du service d'impression, séparation administratif et
+technique, fonctionnement général, nos perspectives et
+envies (demander à Gaétan, formation 1ères années).
+
+Au vu de la disponibilité générale et des autres évènements (samedi plateau
+le 20, journées des M2, interludes le week-end du 27),
+il est envisagé d'organiser cet événement dans l'après-midi du
+dimanche 21 avril.
+
+On demande la Kfet au BdE.
+
+### Questions diverses
+
+#### Analyse AntiVirus des mails
+
+Pauline se demande pourquoi le Cr@ns n'analyse plus les mails en vue d'une
+détection de virus.
+Valentin répond que les virus par mail ont pratiquement disparut d'après les
+statistiques de scan d'amavis/clamav et les
+utilisateurs ont appris leur existence.
+
+#### Nagios
+
+Faut faire des tests.
+
+#### DomU de test
+
+Il est décidé de créer
+un [[CransTechnique/Services/Virtualisation/CreerUnDomu|domU]] sans adm où les
+apprentis sont root et peuvent faire des tests.
diff --git a/compte_rendus/2013_04_18.md b/compte_rendus/2013_04_18.md
new file mode 100644
index 0000000000000000000000000000000000000000..84012d885d9d31bded82baeaeee2fd0d0225e456
--- /dev/null
+++ b/compte_rendus/2013_04_18.md
@@ -0,0 +1,153 @@
+# Réunion Nounous
+
+* Date : 18 Avril 2013
+* Lieu : Condorcet
+* Début : 19h22
+* Fin : 21h21
+
+## Présents
+
+* Ariane Soret
+* Daniel Stan
+* Lucas Serrano
+* Valentin Samir
+* Pierre-Elliott Becue
+* Raphaël-David Lasseri
+* Thomas Épalle
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Serveurs Free
+
+Il sont au 2B, il y en a 2, des 1U avec des kits de rackages.
+Ils sont neufs.
+
+* L'un va être utilisé pour remplacer le serveur NFS actuel.
+* On va essayer de tester la carte TV dans l'autre, mais à priori, il n'y a pas
+ assez de port PCIe dedans pour que ça soit intéressant. Il pourrait également
+ être utilisé pour proposer des VM aux clubs.
+
+Il est marqué dans le contrat de mettre sur le [[http://www.crans.org|site]] un
+logo de la Fondation Free.
+
+### Intranet 2
+
+#### Gestion des prises / Chambres
+
+Valentin a commencé à développer un module pour l'intranet2, pour les accès
+prises/chambres.
+L'idée est de n'autoriser une machine à se connecter que dans une liste de
+chambres fournie par l'adhérent sur l'intranet.
+Il reste à l'interfacer avec radius, et à voir s'il est actif par défaut.
+Il est envisageable de tout préparer techniquement puis d'envoyer un mail Ã
+tous les adhérents pour les prévenir d'une date d'activation.
+Pierre-Elliott soulève qu'il ne lui semble pas acceptable d'imposer à ceux
+souhaitant accéder en filaire à Internet depuis une autre chambre que la leur
+d'avoir un compte Crans.
+Il est rappelé qu'il est également possible d'utiliser de
+l’authentification 802.1x. !MiNet l'utilise et ne semble pas rencontrer de
+problèmes particulier On le leur demandera ce week-end.
+La liste des chambres autorisées est actuellement dans la base pgsql switch.
+Pierre-Elliott à suggéré de rajouter un champ ldap
+multivalué {{{PriseAutorisee}}} par exemple. Cela à l'avantage de garder autant
+que faire se peut les données des adhérents dans une seule base de donnée et
+facilite ainsi sa gestion.
+
+#### Migration
+
+Il faut migrer vers l'intranet2 le plus rapidement
+possible : l'intranet 1 devient de plus en plus obsolète. Par exemple, il ne
+fonctionne pas sous IE10 (ce qui empêche les adhérents d'enregistrer eux même
+un nouveau PC sous Windows 8 qu'ils viennent d'acheter)
+Valentin a commencé à "copier" le module «Mes machines», il manque la création
+des machines (a priori possible avec le nouveau binding) et la suppression (pas
+encore implémenté dans le binding)
+Il manque un module pour imprimer, pour recharger son compte impression via
+paypal et pour gérer ses infos personnelles (monCompte) en ce qui concerne les
+adhérents lambda.
+Pierre-Elliott soulève qu'il ne lui semble pas acceptable de donner des
+commissions à une entreprise à chaque rechargement de compte impression et
+propose de supprimer (ou trouver une alternative à ) la fonctionnalité.
+Les autres modules (digicodes, gestion des factures) doivent également migrer,
+mais comme cela ne concerne actuellement que les membre actifs, c'est un peu
+moins urgent.
+Daniel propose la mise en place d'une base pgsql pour la gestion des digicodes.
+
+### Binding Ldap
+
+Tous type d'objets est créable et modifiable (sauf l'objet facture).
+
+#### Suppression
+
+Il reste à implémenter la suppression : notamment la
+fonction "cimetière" permettant d'annuler une suppression en dumpant les donnée
+depuis la base de donnée vers un autre support.
+Actuellement (dans l'ancien binding) c'est un pickle de
+l'objet {{{python}}} correspondant écrit dans un fichier
+dans {{{/home/cimetiere/}}}.
+Il est envisagé de stocker une représentation plus lisible du ldif ldap
+correspondant (ini, json, …), sans doute dans un fichier.
+
+#### Logs et historique
+
+Pour les logs : accesslog + champ lastmodify pour savoir qui à fait la
+modification : La base ldap log elle même toutes les modifications.
+Pour l'historique : accesslog à l'air compliqué à parser du coup peut être
+garder le système actuel ou bien faire une base d'historique à coté.
+Le système actuel à l'inconvénient de faire grandir arbitrairement la taille
+d'un adhérent/d'une machine dans la base ldap ce qui alourdit sa manipulation
+via le binding.
+De plus, une fois l'objet détruit (par exemple, un adhérent détruit sa machine
+via l'intranet) son historique est détruit dans la foulée alors qu'on pourrait
+souhaiter le conserver.
+
+#### Possibilité de préinscription ?
+
+Avec des ordinateurs en libre service à la rentrée, ça irait peut être plus
+vite ?
+C'est faisable, mais est-ce que ça aurait vraiment un intérêt réel ?
+
+### Passage à wheezy des serveurs mails
+
+Pour se débarrasser des spams, postfix s'est doté d'un nouveau
+module : postscreen. Il n'est pas disponible sous squeeze, et de toute façon,
+wheezy approche de la release.
+Pierre-Elliott propose de les mettre à jour au 2B avec des apprentis après
+avoir envoyer un mail aux adhérents concerné pour les prévenir de l'instabilité
+du service mail durant la mise à jour.
+
+### Routes sur titanic
+
+Bah on ne peut pas parler à freebox en zone crans et on ne peut pas parler Ã
+titanic hors zone crans.
+Au vu des règles de routage, c'est normal.
+Il est possible de faire en sorte que ça marche via des {{{ip rules}}}, mais ça
+n'est pas vraiment important.
+
+### Pare-feu, limitation upload
+
+C'est en place, toutes les déconnexions pour upload sont dans une classe
+où l'upload est limité.
+Il faut remettre au propre l'échelle des sanctions en cas d'abus.
+
+### Zone crans et wiki
+
+Le kludge actuel ne semble plus fonctionner. A priori, il est possible
+d'obtenir le même résultat proprement en écrivant un module d'authentification
+Moinmoin
+http://moinmo.in/HelpOnAuthentication
+Vincent veut bien jeter un oeil. Lucas aussi.
+
+### Install Party, mise en ligne des vidéo
+
+Les fichiers audios des confs sont sur le site de l'install
+party (mp3 mono 32kbps).
+Qu'est ce qu'on fait avec les vidéos ?
+L'idée était de faire un gros carré avec les slides, un petit avec la vidéo et
+le son.
+
+### Une machine pour les apprentis
+
+Le domu pour les apprentis a été créé.
+Une formation pour se connecter au serveur est donnée en direct par Valentin.
diff --git a/compte_rendus/2013_05_02.md b/compte_rendus/2013_05_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..decf4bb2af664a5dfc79ab9dfb74a960fa808033
--- /dev/null
+++ b/compte_rendus/2013_05_02.md
@@ -0,0 +1,133 @@
+# Réunion Nounous
+
+* Date : Jeudi 2 mai 2013
+* Lieu : Pavillon des Jardins
+* Début : 19h21
+* Fin : 20h40
+
+## Présents
+
+* Lucas Serrano
+* Nicolas Dandrimont
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Valentin Samir
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Changement de NFS
+
+Le serveur [[CransTechnique/Services/NfS|NFS]] a été changé. Pour une raison
+encore
+obscure, le nfsv4 était actif alors qu'il n'aurait pas dû l'être, ce qui a créé
+un certain nombre de bugs, dont des problèmes de permissions dans les homes.
+
+Il fallait
+modifier {{{/etc/default/nfs-kernel-server}}} sur [[CransTechnique/LesServeurs/ServeurZbee|zbee]] pour désactiver
+le protocole v4. C'est maintenant fait.
+
+Sinon, on me souffle dans l'oreillette
+que [[CransTechnique/LesServeurs/ServeurCharybde|charybde]] a
+un [[CransTechnique/Services/NfS|NFS]] pour
+le [[CransTechnique/ServicesMineurs/PXE|PXE]]. Donc
+au dist-upgrade, il faudra faire attention.
+[[CransTechnique/LesServeurs/ServeurBabar|Babar]] a également un
+serveur [[CransTechnique/Services/NfS|NFS]] pour exporter les photos des
+caméras (qui ne
+marchent plus).
+
+### Virtualisation
+
+#### Proxmox
+
+Suite à la réunion avec MiNET, Pierre-Elliott a testé Proxmox,
+sur [[CransTechnique/PanthéonServeurs/ServeurKdell|kdell]].
+
+Son interfaçage avec la baie de disque n'est pas compatible avec l'utilisation
+faite actuellement au Cr@ns.
+
+Pierre-Elliott fait remarque que changer l'architecture demanderait alors
+beaucoup de temps pour assez peu de résultat. En effet, il faudrait revoir
+complètement la gestion des disques des machines virtuelles : actuellement elles
+montent des disques (virtuels) entier, il faudrait plutôt qu'elles montent des
+partitions.
+
+Ce dernier point serait de toute façon une bonne chose et résoudrait sans
+doutes les quelques problèmes de migration que l'on rencontre.
+
+#### Virtualisation pour les clubs
+
+À terme, une fois les tests terminés, il faudra décider si on offre un service
+de virtualisation pour les clubs.
+Valentin fait remarquer que l'avantage d'avoir une solution compatible avec la
+virtualisation actuelle permettrait de pouvoir migrer des machines virtuelles
+vers kdell en cas de problèmes sur un
+autre [[CransTechnique/Services/Virtualisation|dom0]].
+
+### Câblage de personnel CROUS
+
+cf ../Jeudi25Avril2013
+
+### Dist-upgrades
+
+La release c'est (après) demain.
+Tous les membres actifs sont invités à lire
+les [[http://www.debian.org/releases/wheezy/amd64/release-notes/index.fr.html|release notes]] et la page CransTechnique/AdminSystème/DistUpgrade (potentiellement à compléter).
+
+Il faut planifier les mise à jour des machines entrainant une interruption de
+service et prévenir à l'avance sur CransIncidents et sur les news.
+
+Parmi celles-ci :
+
+* [[CransTechnique/PanthéonServeurs/ServeurKomaz|komaz]]
+* [[CransTechnique/LesServeurs/ServeursF*#Utilis.2BAOk-s|redisdead]]
+* [[CransTechnique/LesServeurs/ServeursF*|radius]]
+* [[CransTechnique/LesServeurs/ServeursF*|dhcp]]
+* [[CransTechnique/LesServeurs/ServeursF*|xmpp]] (super important !!1)
+* [[CransTechnique/LesServeurs/ServeurZamok|zamok]]
+
+[[CransTechnique/LesServeurs/ServeurZamok|zamok]] sera mis à jour lundi 6 mai
+en même temps qu'on réparera le home des
+adhérents. (envoi de mail ce soir)
+
+Les mise à jour sont programmées à partir du week-end du 18-19 mai pour avoir
+des apprentis disponibles.
+
+### Ajout de droits
+
+Sur proposition de Vincent, les droits nounou ont été attribués à Lucas Serrano
+et Pauline Pommeret.
+
+Valentin fait la partie chiante où il faut taper son mot de passe {{{sudo}}}.
+
+### Divers
+
+#### Caméras
+
+Il faut diagnostiquer pourquoi celle du 2B fait des histoires pour prendre des
+photos et les envoyer sur [[CransTechnique/LesServeurs/ServeurBabar|babar]].
+Idem celle du 0B envoie des mails de manière aléatoire, il faut voir si ça n'est
+pas juste un problème de configuration.
+
+#### Alimentation et KVM
+
+Le CA a donné son accord sur le principe pour l'achat d'une alimentation
+rackable, et
+pour celui d'un KVM. Il faudrait avant cela tester un clavier.
+
+Pierre-Elliott se charge du KVM. Valentin s'occupe de l'alimentation, et des
+« petits consommables » (têtes RJ45 & co).
+
+Nicolas dit qu'il a croisé une alimentation similaire à pika et chu, elle doit
+se trouver dans un des locaux techniques.
+
+#### autoconf wifi
+
+Valentin a nettoyé le code de son script. Les sources et le script pour
+cross-compiler se trouvent dans {{{/usr/scripts/src/autoconf-wifi}}}.
+
+L'exécutable servi pour Windows est signé, avec la commande décrite dans
+la source. Ce n'est pas absolument nécessaire de faire ça.
+
+Attention, le fichier est symlinké depuis le serveur {{{ftp}}}.
diff --git a/compte_rendus/2013_05_16.md b/compte_rendus/2013_05_16.md
new file mode 100644
index 0000000000000000000000000000000000000000..dd0dc4c5a4129c05c08ddad6e2a77b5f79b356a4
--- /dev/null
+++ b/compte_rendus/2013_05_16.md
@@ -0,0 +1,141 @@
+# Réunion Nounous
+
+* Date : Jeudi 16 mai 2013
+* Lieu : Pavillon des Jardins
+* Début : 19h32
+* Fin : 21h30
+
+## Présents
+
+* Daniel Stan
+* Raphaël Cauderlier
+* Vincent Le Gallic
+* Lucas Serrano
+* Valentin Samir
+* Pierre-Elliott Bécue
+* Ariane Soret
+
+## Ordre du jour
+
+### Avancement binding LDAP
+
+Valentin affirme que le nouveau binding fonctionne, id est il est possible de :
+
+* créer des objets
+* modifier des objets
+* supprimer des objets (avec un cimetière)
+* ressusciter des objets depuis le cimetière
+* programmation des services à reconfigurer
+ * Il faudrait peut-être revoir le système des arguments passés aux services
+
+à redémarrer, celui actuel ne permettant pas beaucoup de flexibilité.
+Il manque :
+
+* Une gestion des accès concurrents
+* Les logs (support partiel de l'ancienne méthode via l'attribut historique)
+
+Penser à migrer les scripts qu'on veut garder de l'ancien binding vers le
+nouveau.
+
+Vincent a séparé les objets ldap du binding dans un autre fichier.
+Ajouté un module shortcuts pour se binder en admin, readonly, autre, ….
+
+Le fait que le package, le module principal et la classe du binding portent le
+même
+nom est problématique. Il faudrait penser à un renommage.
+
+Vincent s'occupera du renommage, Pierre-Elliott de l'accès concurrent.
+
+### Avancement Intranet2
+
+L'application "Mes Machines" sur le nouvel intranet est en production et est
+utilisé. (L'ancien commençait à avoir du mal sur les nouveaux navigateurs.)
+
+L'association compte Cr@ns<->WikiNom a quelques problèmes d'encodage (cf mail)
+Il reste à réaliser un outil de création de compte Wiki (pour compenser le
+script qui ne marche pas sur zamok).
+
+Dans les applications à migrer rapidement : une application "mon compte" et
+une application d'impression (lancement) et le rechargement de solde via paypal
+et note Kfet.
+
+Il pourrait être bien de migrer la gestion des digicodes en les stockant
+dans une base de donnée (au lieu de créer un fichier dans
+/usr/scripts/var/digicode) avis aux apprentis !
+
+### Serveur TV
+
+La carte 4 tuners a été testée dans le pc d'un membre actif.
+Ça fait 20 jours que ça marche.
+
+Il faut acheter au moins une deuxième carte pour couvrir tous les multiplex et
+une tour avec suffisamment de PCIe (au moins 4) et de ventilo pour refroidir
+les cartes.
+(faire un panier sur un site de vente en ligne).
+
+Valentin s'en occupe.
+
+Il faudrait réfléchir à rationaliser également le satellite.
+
+### CAS
+
+Le wiki a été (partiellement) CASsifié.
+
+Il reste sogo, horde et nagios.
+Il faut installer pam_cas sur le serveur imap pour cela (Argh).
+
+### WiFi
+
+Il reste des choses à faire ! Prochaine séance de pose de bornes ? :)
+
+Il faut acheter les bornes de test (Daniel se charge de faire le panier) dont
+le budget
+a été voté au précédent CA.
+
+Il faudrait compter le nombre de bornes à acheter pour compléter la couverture
+(PdJ, RdC H I J) (possiblement avec les fat max 100 clients).
+
+Il faut poser les bornes au G, C, A, B.
+
+Daniel propose de faire une séance ce week-end pour wifier le bâtiment C.
+On se retrouve samedi après le petit dèj (début 14h).
+
+### Mise a jour des serveurs
+
+* komaz : 25/05/2013
+* sable : 2{5|6}/05/2013
+* vert : 01/06/2013 (penser à couper 1 réplicat pour avoir un backup)
+* charybde : 01/06/2013
+* gordon -> Ã transformer en domu
+* news : 15/06/2013
+* niomniom : 15/06/2013
+* titanic : 22/06/2013
+* dhcp : 22/06/2013
+* eap : juillet
+* irc : juillet
+* redisdead : juillet
+* ovh : juillet
+* owl : juillet
+* sogo : en même temps que owl
+
+### Adhérent au M qui spoofe
+
+Un adhérent a spoofé l'ip de zamok. Il prétend ne pas être au courant,
+il semble qu'il l'ait fait involontairement. Comme il a une freebox, il a
+été déconnecté au niveau du Crans.
+
+!ToDoList.append("déconnecter automatiquement les prises où on voit une MAC
+spoofant
+une IP de serveur ?")
+
+### Flaw in linux kernel
+
+Hier un mail a été reçu parlant d'une faille découverte récemment.
+Zamok y étant vulnérable, Pierre-Elliott lui a appliqué un patch.
+
+### D(r)ivers
+
+* On a reçu 3 écrans et des claviers. C'est cool. Daniel dit que certaines
+
+touches d'un clavier ne marchent pas. Il suffit de les renvoyer (les claviers,
+pas les touches).
diff --git a/compte_rendus/2013_05_30.md b/compte_rendus/2013_05_30.md
new file mode 100644
index 0000000000000000000000000000000000000000..81e6a4d37e73d5123b7ce415ca99806e2c9f2f4f
--- /dev/null
+++ b/compte_rendus/2013_05_30.md
@@ -0,0 +1,105 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 30 Mai 2013
+* Lieu : Pavillon Des Jardins
+* Début : 19h30
+* Fin :
+
+## Présents
+
+* Daniel Stan
+* Lucas Serrano
+* Pierre-Elliott Bécue
+* Valentin Samir
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### TV
+
+Une nouvelle machine a été reçue et montée lundi, la seconde carte TV lui a été
+adjointe
+mercredi.
+Elle diffuse toute la TNT sauf le dernier Multiplex que l'on ne capte
+apparemment pas.
+Pour l'instant ça marche bien ! (il est même probable que ça soit toujours le
+cas demain)
+Il faut prévoir un ménage du 4J, et renommer TNT_test en TNT.
+
+Il faudrait également passer la configuration de la TV dans bcfg2, avis à un
+apprenti/ignorant motivé.
+
+Daniel demande s'il est possible de rajouter des cartes dans {{{cochon}}}, par
+exemple,
+le satellite. À priori c'est possible.
+
+### WiFi
+
+Daniel a commandé 12 Unifi et 2 nano M5. Ça devrait arriver d'ici lundi. Des
+tests seront
+à faire sur les bornes Unity, Daniel propose d'aider un curieux à comprendre
+comment les
+flasher, après avoir trouvé le firmware qui convient.
+
+### Mise à jour de serveurs
+
+#### Gordon
+
+Un nouveau DNS récursif a été mis en place, une machine virtuelle du nom
+de {{{nem}}} sur
+kdell. C'était une occasion de tester Proxmox sur de la prod.
+
+#### Dhcp de secours
+
+Une machine supplémentaire a été créée pour le dhcp, elle s'appelle {{{isc}}},
+et tourne sur
+kdell.
+
+#### Futures mises à jour
+
+Il faudrait planifier les mises à jour de serveurs encore non listés.
+
+* eap : 2 juillet
+* irc : 2 juillet
+* redisdead : 2 juillet
+* ovh : 2 juillet
+* owl : 10 juillet
+* sogo : 10 juillet
+* xmpp : 10 juillet (Ã 14h, pour faire chier les vieux)
+* asterisk : 10 juillet
+
+Au moins vert et charybde samedi matin, il faudrait faire du teasing, qu'un
+apprenti (voire
+plus, soyons fous) vienne.
+
+### Virtualisation
+
+Proxmox est installé sur kdell et sur vo, il faut s'assurer qu'il existe des
+outils en
+command line pour lancer les machines virtuelles, et éventuellement pour
+accéder en console
+Ã celles-ci.
+Il faut documenter l'appli si on veut passer de xen à proxmox. Entres autres
+pour la gestion
+des disques.
+
+#### Ntp sous proxmox
+
+A l'air de fonctionner.
+
+### Évolution du nouveau binding
+
+Le nouveau binding est en « tout unicode » (enfin presque), et les locks sont Ã
+peu près
+en place.
+
+Une composante bijective a été extraite des dictionnaires rid, NETs, prefix de
+config.py
+
+### Pénurie des ipv4
+
+Un script a été pondu, il n'a pas encore éclos, il faudrait s'occuper de mettre
+en place le
+v6-only en parallèle.
+
+Il faudrait presser la DSI pour l'ipv6.
diff --git a/compte_rendus/2013_06_13.md b/compte_rendus/2013_06_13.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5766e34d5226fd47c3400d86ac01c2fa6b3146d
--- /dev/null
+++ b/compte_rendus/2013_06_13.md
@@ -0,0 +1,87 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 13 Juin 2013
+* Lieu : Fonteneau ou Tocqueville
+* Début : 19h18
+* Fin : 20h53
+
+## Présents
+
+* Daniel Stan
+* Lucas Serrano
+* Raphaël Cauderlier
+* Valentin Samir
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Carte Satellite
+
+Elle est arrivé, elle est rouge dans son carton.
+
+Il faut l'installer relativement rapidement sachant qu'il n'y a plus de chaînes
+satellite diffusées en ce moment.
+
+Histoire de faire les choses correctement, il faut écrire des règles udev pour
+déterminiser l'ordre d'attribution interface <-> carte.
+
+Il serrait également interessant d'écrire un initscript permettant de n'agir
+que sur une seule instance de mumudvb.
+
+### Climatisation 0B
+
+LTC est passé lundi matin, il a nettoyé l'évacuation à l'extérieur qui était
+pleine de pigeon et de guano. Les résultats ne sont pas merveilleux.
+Il faut les rappeler pour qu'ils repassent.
+
+Daniel se charge de les rappeler.
+
+### Notification d'infraction au copyright
+
+La DSI nous a transféré un mail (parmi plusieurs) à propos de violation de
+copyright.
+On a transmis aux adhérents concernés. Apparemment ça leur suffit pas.
+
+Pierre-Elliott écrit un mail pour la DSI explicitant que l'on n'y peut pas
+grand chose.
+
+### Nouvelles bornes WiFi
+
+Une première borne du nouveau modèle (!UniFi) a été placée au B.
+
+Daniel a commencé à remplir des pages wiki sur la façon de les flasher.
+
+Bâtiments restants : G, C, A, PdJ.
+
+Appel aux apprentis pour flasher, poser, tirer des câbles.
+
+### CAS, déconnexion
+
+Maintenant, quand on clique sur "se déconnecter" on est globalement déconnecté
+des services suivants : wiki, roundcube, webnews.
+
+Ce serait pas mal de l'implémenter pour les autres services.
+
+Un apprenti peut être encadré sur le sujet.
+
+Valentin se charge de rajouter
+sur [[CransTechnique/ServicesMineurs/CentralAuthenticationService]] les paths
+des différentes conf
+(serveurside et clientside)
+
+### Mise à jour de serveurs
+
+News et Niomniom sont à mettre à jour samedi à partir de 9h30.
+Appels aux apprentis disponibles.
+
+Valentin enverra un mail de rappel sur nounou@crans.org d'ici ce soir.
+
+Valentin propose une fois encore d'écrire un module d'autentification pour
+gérer le hack de la zone Crans de MoinMoin.
+
+### Questions diverses
+
+#### Imprimante
+
+Un technicien est venu réparer l'imprimante. Jusque là , elle remarche. Elle
+boure relativement souvent. Il faudra également recommander du papier.
diff --git a/compte_rendus/2013_09_23.md b/compte_rendus/2013_09_23.md
new file mode 100644
index 0000000000000000000000000000000000000000..654c078aa500bf436762f331b934fe8a0d75fa2d
--- /dev/null
+++ b/compte_rendus/2013_09_23.md
@@ -0,0 +1,251 @@
+# Réunion du Collège Technique
+
+* Date : Lundi 23 septembre 2013
+* Lieu : Espace Condorcet
+* Début : 19h25
+* Fin : 20h49
+
+## Présents
+
+* Daniel Stan
+* Florian Marconi
+* Jean-Paul Giraud-Ferrandi
+* Lucas Serrano
+* Pierre-Elliott Bécue
+* Raphaël-David Lasseri
+* Valentin Samir
+* Vincent Guiraud
+
+## Ordre du jour
+
+### Présentation
+
+On effectue rapidement un tour de table pour se présenter.
+Pierre-Elliott rappelle les divers postes que peuvent occuper des membres
+actifs et que l'investissement temporel est à géométrie variable.
+
+### Garantie renouvelée
+
+La garantie de {{{zamok}}} ayant expiré, le C.A. a voté durant l'été par email
+le
+renouvellement de la garantie, qui a été appliqué.
+
+Vincent recevra la facture.
+
+L'extension de garantie court jusqu'au 03/09/2014.
+
+### Politique sur les infractions au copyright
+
+Problème réglé : en gros, la DSI nous envoie des mails de la part d'ayants
+droit mentionnant des IPs Crans.
+
+La politique a donc été définie en accord avec la DSI : on ne sanctionne pas
+les adhérents, on transmet les mails que l'on reçoit aux adhérents.
+Si des demandes d'ayants droit deviennent insistantes, les rediriger vers les
+instances compétentes.
+
+### Politique sur les comptes compromis
+
+Il arrive que des comptes crans soit compromis, ''id est'' que les identifiants
+du compte leakent.
+
+Outre les problèmes concernant la vie privée du propriétaire du compte, il a
+été observé que des spambots envoyaient des milliers de mails via ces comptes.
+
+Pour ce qui est des spams, Pierre-Elliott propose une solution à partir
+des "politiques" de postfix.
+Cela est faisable en pas trop longtemps. Avis à des personnes motivées.
+
+Moralement, si un compte est compromis il faudrait complètement le
+désactiver (via l'ajout d'un attribut LDAP), et pas uniquement bloquer l'envoi
+de mail.
+Un débat a lieu sur la meilleur manière de communiquer un nouveau mot de passe.
+
+Manières de contacter un adhérent dont le compte est compromis (et désactivé):
+
+* Physiquement à la Kfet
+* Mail alternatif (attribut mailExt)
+* Adresse postale (ne plus mettre de EXT sans adresse)
+* Téléphone
+* Au cas par cas (?)
+
+Pierre-Elliott modifiera la base LDAP pour l'attribut "compte désactivé", si
+possible gérable via blacklist, ou un peu comme mail_invalide.
+
+### Gestion des certificats
+
+PEB a contacté !CaCert pour créer un compte à l'association pour gérer le
+domaine {{{crans.org}}}.
+
+Le système de !CaCert repose sur un réseau de confiance : des gens "de
+confiance" assurent d'autres gens, et ainsi de suite.
+Il y a un système de points qui permet de donner plus ou moins de possibilités
+aux gens plus ou moins assurés.
+
+Un compte organisation peut nommer des administrateurs (des assureurs) qui
+pourront ensuite émettre des certificats pour le domaine.
+
+Actuellement, le domaine {{{crans.org}}} est enregistré sur le compte personnel
+de Stéphane Glondu, ce qui oblige de passer systématiquement par lui pour les
+renouvellement ou les nouveaux certificats.
+Cela est devenu relativement pénible autant pour lui que pour nous. C'est
+pourquoi Pierre-Elliott a entrepris les démarches pour ouvrir un compte
+organisation au nom du Crans.
+
+### Migration vers proxmox
+
+Les machines virtuelles du Crans sont hébergées sous le virtualiseur Xen.
+Il y a quelques problèmes lors de la migration de machines virtuelles entre
+deux virtualiseurs.
+
+Pierre-Elliott a installé Proxmox sur {{{kdell}}} et sur {{{vo}}} pour tester,
+et celui-ci a plus ou moins fait preuve de sans faute par rapport à nos
+exigences.
+
+Proxmox, c'est un noyau Linux modifié pour virtualiser des machines sous kvm ou
+OpenVZ. En sus, il y a une interface web kikoo.
+
+Globalement, Proxmox est plus adapté à nos besoins, Pierre-Elliott a testé la
+migration des machines depuis XEN vers Proxmax, cela fonctionne, et est
+documenté.
+Un certain nombre de migrations ont été effectuées.
+
+Il faudrait effectuer les suivantes. L'idéal étant que des gens découvrent.
+
+### Déploiement du wifi
+
+Daniel a placé une borne wifi par étage au PDJ (au niveau du local technique).
+
+Il reste à tirer des câbles au niveau des faux plafonds.
+Un étage sur deux une au milieu, pour les autres deux sur les côtés.
+
+Les bâtiments C, A, G et le PDJ restent à câbler.
+Un des problème est le manque d'accessibilité aux locaux, notamment au C.
+Il faut des gens motivés pour faire tout ça, c'est long et chiant, mais c'est
+indispensable qu'on finisse cette année, ou du moins avant qu'on parte à Saclay.
+
+Dernier détail : le VLAN 3 n'est plus propagé dans les locaux de l'ENS, il
+faudrait faire signe à la DSI pour essayer de comprendre pourquoi, après avoir
+mené quelques tests.
+
+### Mails automatiques
+
+Valentin a commencé un peu de templating avec Jinja2, il faudrait remplir ces
+mails dans les diverses langes qu'on pratique.
+
+Une fois cela fait, on pourrait songer à un champ LDAP pour demander aux
+adhérents leur langue préférée.
+
+Il faut prolonger ce travail, et le rendre utilisable, si possible avant la
+prochaine rentrée. Avis aux amateurs.
+
+### Point lc_ldap
+
+{{{lc_ldap}}} est presque fini, il faut juste s'occuper de ces histoires
+d'historique, et des factures.
+
+On a aussi des erreurs, probablement dues aux locks, il faut investiguer pour
+améliorer le système.
+Globalement, les erreurs sont "!LockedByYou", ce qui tend à laisser croire que
+dans un cas précis, quand on annule une modif, les locks ne sont pas levés.
+
+Pour l'historique, il s'agit de travailler avec {{{cn=log}}}, ce qui avait été
+commencé par adg.
+Sinon, le système d'historique (quitte à les mettre à côté ou en
+sous-objet) actuel + {{{cn=log}}}, mais sans parsage.
+
+L'idéal serait quand même de travailler avec {{{cn=log}}}. Une alternative est
+de créer un objet fils de chaque objet, qui contiendrait l'historique.
+
+Pour les factures, il faut juste écrire le code.
+
+### Divers intranet2
+
+* Création de compte wiki (pour l'instant on ne sait que linker les comptes)
+* Génération de {{{.procmailrc}}} (il s'agit de migrer l'appli de l'intranet1,
+ et de faire ce qui est proposé dans le tracker (règles de filtrage))
+* Gestion de !MonCompte (idem qu'au dessus)
+* Gestion des factures (cf point {{{lc_ldap}}})
+* Digicode / Impression (ça avait été commencé, il faut juste finir, il s'agit
+ aussi de porter l'appli de l'intranet1)
+
+### Multicast : radio et satellite
+
+Valentin a ajouté des chaînes de radio via http sur l'offre TV, qui semble
+fonctionner.
+
+Il y a un comportement anormal des switches qui fait qu'en cas de poll pour
+trouver des abonnés,
+les réponses ne reviennent pas toujours à cochon malgré son statut de routeur
+multicast.
+
+Il y a normalement des chaînes de radio sur le satellites mais {{{mumudvb}}} ne
+veut pas les diffuser.
+
+Il y a une interface web pour la télévision sur http://intranet2.crans.org/tv.
+
+### VLAN dynamiques en wifi
+
+Daniel a travaillé sur le basculement dynamique en wifi entre les
+VLANs. (accueil & co)
+
+Sur le filaire, c'est déjà fait, les switches interrogent radius pour choisir
+le VLAN sur lequel placer les machines.
+En wifi, c'était un peu plus compliqué. Mais à la suite de divers tests et
+flashages de bornes, il a trouvé quelque chose qui fonctionne.
+
+Il faut donc modifier les confs radius sur {{{eap}}} et {{{pea}}} pour mettre
+ça en prod après avoir flashé les bornes avec la nouvelle !OpenWRT.
+
+On prévoit également de mettre en place le failover pour {{{eap}}} et {{{pea}}}.
+
+Bref, ça marche, il faut des apprentis motivés pour apprendre tout ça et
+implémenter le truc. (soyons consensuels). Raphaël-David a déjà commence, mais
+il veut des coupaings.
+
+### Point cranspassword
+
+Vincent étant absent, on se limitera aux remarques de Daniel.
+Il faut s'assurer que les clefs GPG des gens sont toujours à jour, et non
+expirées.
+
+* Ouais, j'étais pas là , my bad.
+
+. Pour ce qui est des détails techniques d'un point de vue {{{git}}}, il faut
+soit se placer sur la branche {{{0.1}}} et ne plus se soucier de rien (le
+serveur sur {{{vert}}} est en {{{0.1}}}), soit rester sur {{{master}}} mais
+être prêt à puller les mises à jour quand il y en a. Le serveur
+sur {{{ovh}}} est sur {{{master}}} (mais en readonly)
+. Pour le faire marcher, on peut maintenant utiliser le
+Makefile (sur {{{master}}}). {{{make install}}} pour installer le client. Ça a
+pour effet de :
+
+* mettre de la conf dans {{{~/.config/cranspasswords}}}
+* installer le script {{{cranspasswords}}} dans {{{~/bin}}}, qu'il faut donc
+ avoir dans son {{{$PATH}}}
+
+. La vérification de confiance et d'expiration des clés est implémentée, et il
+propose même d'ignorer une clé au moment où on chiffre si elle pose problème.
+. J'oublie ptêt des trucs, mais normalement la doc
+est [[CransTechnique/ScriptsCrans/CransPasswords|là ]] -- [[Wiki20-100]] <<DateTime(2013-09-28T01:37:06+0200)>>
+
+### Questions diverses
+
+#### Séminaires
+
+Date de début des séminaires ?
+Le 1er ou le 8 octobre, à confirmer par email, et pensez à faire de la vraie
+pub, parce que les séminaires, c'est le bien.
+
+Valentin voudrait qu'on commence GPG en octobre, ce qui est judicieux.
+
+Si cela convient aux intervenants, le premier mois sera donc "intro par
+Valentin" -> "Unix par lolasd" -> "le shell par #Random" -> "Gépégé".
+
+#### Reconfiguration des switches
+
+Tous les switchs ont la nouvelle configuration faite par Daniel vendredi soir.
+
+#### Forum des assoces
+
+Daniel propose de tenir le stand, et veut de la compagnie.
diff --git a/compte_rendus/2013_10_03.md b/compte_rendus/2013_10_03.md
new file mode 100644
index 0000000000000000000000000000000000000000..4ab7443f2de54ce71895bd5728a96b306b2134e9
--- /dev/null
+++ b/compte_rendus/2013_10_03.md
@@ -0,0 +1,95 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 03 Octobre 2013
+* Lieu : Pavillon des Jardin
+* Début : 19h07
+* Fin : 19h57
+
+## Présents
+
+* Daniel Stan
+* Lucas Serrano
+* Pauline Pommeret
+* Thomas Espitau
+* Valentin Samir
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Programmation WiFi
+
+Daniel veut fixer une date pour les bornes du C : il n'y a qu'a resertir les
+câbles.
+Il serait de bon ton de changer en même temps le switch du 5C (bac-4) sur lequel
+sont branchées les bornes.
+
+On programme ça samedi en début d'après-midi (après le petit déjeuner).
+
+### Projecteur
+
+Pour la tenue de ses réunions hebdomadaires, le Crans aurait besoin d'un vidéo
+projecteur.
+Il serait aussi utile pour les petites conférences exceptionnelles.
+
+Le collège technique estime qu'une résolution supérieure ou égale à de l'HD
+ready (1080x720) serait une bonne chose.
+
+Comme il s'agit d'un projecteur pour utiliser en environnement lumineux (pas
+dans le noir pour regarder un film), il faut que sa luminosité soit suffisante.
+
+Il faut un contraste suffisant pour voir les couleur du fond de gobby. (Assez
+violent à mon goût à avoir quand même).
+
+Avoir une connectique VGA et HDMI.
+
+Diode VS lampe : la première a une durée de vie bien plus grande (au
+moins 10 fois plus) mais ''a priori'' une luminosité plus faible.
+Daniel demande s'il faudrait également acheter un écran
+portatif (entre 60 et 160€).
+
+### Système de paiement
+
+Actuellement l'adhésion se fait par année scolaire.
+Valentin propose des (ré)adhésions par année glissante.
+Cela permettra d'éviter les gros rushs de réadhésion à la rentrée.
+
+Vincent rappelle qu'il faut scripter l'envoi de mails. Valentin dit qu'il faut
+ajouter un champ avec la date d'adhésion/réadhésion (et laisser un mois pour la
+carte d'étudiant).
+
+Une fois implémentée, cette solution pourra être proposée au CA (et soumise Ã
+validation).
+
+## Question diverses
+
+### Cranspasswords
+
+Vincent n'était pas là lors de la dernière internounou.
+Il n'a pas grand chose à ajouter.
+
+* Pour ce qui est des détails techniques d'un point de vue {{{git}}}, il faut
+ soit se placer sur la branche {{{0.1}}} et ne plus se soucier de rien (le
+ serveur sur {{{vert}}} est en {{{0.1}}}), soit rester sur {{{master}}} mais
+ être prêt à ''puller'' les mises à jour quand il y en a. Le serveur
+ sur {{{ovh}}} est sur {{{master}}} (mais en readonly).
+
+. Pour le faire marcher, on peut maintenant utiliser le
+Makefile (sur {{{master}}}). {{{make install}}} pour installer le client. Ça a
+pour effet de :
+
+* mettre de la conf dans {{{~/.config/cranspasswords}}}
+* installer le script {{{cranspasswords}}} dans {{{~/bin}}}, qu'il faut donc
+ avoir dans son {{{$PATH}}}
+
+. La vérification de confiance et d'expiration des clés est implémentée, et il
+propose même d'ignorer une clé au moment où on chiffre si elle pose problème.
+
+### Matériel séminaire
+
+On se propose d'enregistrer et de filmer les séminaires.
+
+Pour cela, on demande un micro-cravate, Valentin en trouve 4 + récepteurs
+à 200€, cela semble honnête (sonovente.com), en promotion.
+
+Une caméra serait également pratique, une discussion va être lancée sur
+nounou@, il y a forcément quelqu'un de compétent (bref c'est remis à Plüthaar).
diff --git a/compte_rendus/2013_10_17.md b/compte_rendus/2013_10_17.md
new file mode 100644
index 0000000000000000000000000000000000000000..0e5a2e3fb48aaf8eb0f47dea3c54d8dd48ed6584
--- /dev/null
+++ b/compte_rendus/2013_10_17.md
@@ -0,0 +1,196 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 17 octobre 2013
+* Lieu : Pavillon des Jardin
+* Début : 19h15
+* Fin : 21h13
+
+## Présents
+
+* Ariane Soret
+* Daniel Stan
+* Jordan Delorme
+* Lucas Serrano
+* Pierre-Elliott Bécue
+* Raphaël-David Lasseri
+* Théo Winterhalter
+* Valentin Samir
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Pont WiFi
+
+Lucas à mis en œuvre un pont wifi entre deux nano.
+À la base, cela était pour relier l'Arpej (mais il n'y a plus personne).
+
+Ça marche. On a un débit asymétrique :
+
+* AP -> client : 40 Mbps
+* client -> AP : 90 Mbps
+
+Un test de distance à été effectué entre le I et le J, cela semble concluant. Il
+reste à tester sur une longue distance (de l'ordre 500m).
+Une collocation sur la colline de Cachan est partante pour acheter une paire de
+bornes et être raccordée au réseau si le test longue distance est concluant.
+L'autre extrémité sera sur la terrasse du bâtiment C.
+
+{{{#!wiki caution
+On notera qu'il ne faut pas bridger les interfaces des '''deux''' bornes
+sur leur interface filaire. Ça fait une boucle. Le réseau aime pas ça. Du tout.
+
+Une note à ce sujet a été rajoutée sur une des deux bornes.
+}}}
+
+### Policyd sur redisdead
+
+''Résumé des épisodes précédents : Il est arrivé plusieurs fois au cours des
+derniers
+mois qu'un mot de passe d'un compte Cr@ns soit compromis et qu'un botnet
+l'utilise
+pour envoyer du spam.''
+
+Une limite de mail par minute par IP émettrice était déjà en place, mais les
+botnet
+deviennent intelligents, ils utilisent plusieurs IPs.
+La dernière occurrence a eu lieu Vendredi dernier.
+
+Valentin a mis en place sur notre SMTP un plugin postfix (policyd, version clue
+bringer)
+qui permet de restreindre les politiques d'accès par utilisateur authentifié.
+
+La configuration est dans une base de données sur {{{thot}}}.
+Pour la faire/modifier, il y a un joli
+cliquodrome : [[https://redisdead.adm.crans.org/policyd/]],
+l'authentification se fait par compte Cr@ns.
+Les limitations de quotas mises en place sont :
+
+* 500 mails par utilisateur par 24h
+* 1Go de données par utilisateur par 24h
+
+Policyd permet également de faire du greylisting.
+La question de dropper postgreysql se pose, histoire d'avoir un seul daemon pour
+faire les deux.
+
+### lc_ldap
+
+#### factures
+
+Valentin a fait en sorte que les factures soient utilisables avec {{{lc_ldap}}}.
+
+* objectClass=facture
+ * fid (identifiant unique)
+ * modePaiement (paypal, pour l'instant)
+ * article (qu'est-ce qui a été payé)
+ * recuPaiement (on décide de mettre AAAA-MM-JJ, correspondrait à cocher
+ paiement AAAA)
+ * historique (ce qui est arrivé dans cette facture au cours de l'histoire)
+ * !ToDo https://tracker.crans.org/issues/224 : rajouter un champ pour
+ validation par le trésorier
+
+(cf controle+p)
+
+#### Comptes compromis
+
+Il faudrait rajouter un champ LDAP pour marquer un compte comme compromis et
+vérifier
+son absence dans ce qui utilise les comptes LDAP.
+(envoi de mails, connexion à zamok, laisser l'intranet ?)
+
+https://tracker.crans.org/issues/223
+
+#### Blackliste pour les gens qui ont pas payé
+
+Pour les adhérents n'ayant pas payé pour l'année en cours, une
+pseudo-blackliste a été rajoutée.
+Il n'y a donc pas besoin de vérifier qu'un adhérent a payé, juste qu'il n'a pas
+de blackliste.
+
+Un des effets a été que les anciens adhérents (qui n'ont pas réadhéré)
+pouvaient toujours se connecter à {{{zamok}}}, mais plus en sortir.
+Valentin a patché pour rétablir la situation précédente.
+
+Pour l'instant, il n'y a pas eu d'abus constaté, on laisse ça comme ça.
+Il sera toujours temps de revenir en arrière si on constate des abus.
+
+### Mail rappel carte étudiant
+
+Il faut l'envoyer. Ce serait bien d'écrire le template jinja
+(cf {{{/usr/scripts/gestion/mail/}}}).
+Pierre-Elliott et Raphaël-David se chargent de reprendre celui de l'année
+précédente.
+
+Il pourrait être judicieux d'en profiter pour le croner.
+
+### Rappel env de dev sur vo
+
+Valentin rappelle qu'il y a un environnement de développement pour tester
+le webnews et l'intranet sur {{{vo}}}.
+
+A priori, respbats a les droits d'écriture, les apprentis peuvent donc tester.
+Ça permet de «tester en prod». Si "ça marche pas"™, frapper la nounou la plus
+proche.
+
+Une fois les tests concluant, demander à une nounou de pusher.
+
+##Â Silent ping Aurore.
+### Thanks ! -- Zelda
+
+### Imprimante
+
+Lucas et Daniel ont tourné les feuille de π/2rad sans les bacs de l'imprimante.
+Du
+coup, deux modes d'agrafages ont été supprimé (sur le coté long, type sauce).
+En résultat, l'imprimante ne bourre presque plus.
+
+Il serait bien qu'une alerte soit envoyée aux imprimeurs lorsque quelqu'un
+lance une grosse impression.
+
+### Tunnel IPv6
+
+http://tunnelbroker.net/
+Il est possible a priori d'avoir la sortie du tunnel sur Paris (au lieu de
+Marseille).
+Valentin a constaté de meilleurs débits.
+
+Problème : il faut changer le set d'IP.
+
+La configuration a aussi l'air d'être plus facile à mettre en place.
+Un tunnel de test a été mis en place sur {{{vo}}}.
+
+On pourrait également mettre un autre tunnel spécialement pour le miroir Debian.
+
+### Question diverses
+
+#### Bridage adhérent
+
+Daniel propose que, après les 24h de déconnexion pour upload,
+les adhérents soient obligés de cliquer sur un liens envoyé dans le mail de
+déconnexion pour être débridés.
+Tout le monde est d'accord.
+
+On transmettra au CA.
+
+#### Vidéo aux 15 ans
+
+Ariane a à la main une caméra achetée chez Darty.
+Pierre-Elliott s'occupe de faire en sorte de récupérer les flux slide, camera,
+et probablement son régie sur son PC pour les mixer en direct.
+De là , il sera probablement possible de proposer un streaming en direct.
+
+Il n'y a qu'une prise Ethernet au Villon, (dans le placard). Un câble sera tiré
+jusqu'aux ateliers.
+
+#### Espace de stockage et FedeRez
+
+FedeRez a demandé plus de place sur {{{baldrick}}} pour que les serveurs
+puissent
+se backuper les uns les autres.
+Leur allouer 50Go n'est pas un problème, mais soulève la question d'acheter des
+disques
+de 600Go pour remplacer les disques de 300Go de la baie des domU, pour faire de
+la virtualisation
+pour les clubs.
+
+Un devis a déjà été transmis au CA il y a un certain temps.
+Il faudrait avoir son aval sur la question.
diff --git a/compte_rendus/2013_10_31.md b/compte_rendus/2013_10_31.md
new file mode 100644
index 0000000000000000000000000000000000000000..f9f73e4950b190ad7c71a1fb02ef1a361d873df4
--- /dev/null
+++ b/compte_rendus/2013_10_31.md
@@ -0,0 +1,35 @@
+# Réunion du Collège Technique
+
+* Date : 31 Octobre 2013
+* Lieu : 2B
+* Début : 19h10
+* Fin : 19h30
+
+## Présents
+
+* Valentin Samir
+* Lucas Serrano
+* Pierre-Elliott Bécue
+
+## Ordre du jour
+
+### Pont Wifi
+
+Il relie le bâtiment B et une collocation rue des Vignes à Cachan (~600 m).
+Très bonne synchro et très bon RTT. Les débits obtenus sont plutôt prometteurs
+au vu des réglages précaires.
+Valentin a regardé rapidement le tagging dynamique des vlans sur un bridge (par
+exemple sur la borne du toit du B``) et n'a rien trouvé. Le plus simple serait
+d'acheminer le vlan adh via ces bornes sans authentification radius.
+
+/!\ Nous avons emprunté le câble de la borne du 6B (Busiris) pour réaliser le
+câblage du pont, il faudra donc retirer un câble pour cette borne.
+
+### Disque Dur Baie de Disque
+
+Le CA a prévalidé un ordre de grandeur de prix (entre 2500 et 3000€). On
+demandera un devis à Anne, notre fournisseur, lors de son retour de vacances.
+
+### Questions Diverses
+
+Aucune.
diff --git a/compte_rendus/2013_11_14.md b/compte_rendus/2013_11_14.md
new file mode 100644
index 0000000000000000000000000000000000000000..b23ee82a645d3ecaf925f31a34ba7be5b30fe58d
--- /dev/null
+++ b/compte_rendus/2013_11_14.md
@@ -0,0 +1,186 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 14 Novembre 2013
+* Lieu : Condorcet
+* Début : 19h11
+* Fin : 21h20
+
+## Présents
+
+* Daniel Stan
+* Lucas Serrano
+* Raphaël-David Lasseri
+* Valentin Samir
+* Vincent Le Gallic
+* Pierre-Elliott Bécue
+
+## Ordre du jour
+
+### Wifi
+
+#### Pose de borne
+
+Des bornes wifi ont été placées aux étages 3, 4 et 5 du G, orientées vers
+l'extérieur. Ça marche du tonnerre de Brest ! On a quasiment plus de câble, or
+il nous reste des bâtiments à couvrir (A, PdJ, une partie du G)
+
+Initialement, une seule borne (!NanoM2Loco) était prévue par étage, avec les
+nombreuses bornes de test, on s'est permis d'en placer deux par étage.
+Pour couvrir le RDC, le 1er et le 2ème, il est nécessaire de rajouter deux
+bornes
+supplémentaires.
+
+Il faut faire les comptes de ce qu'il nous reste (Unifi + Pico), pour finir la
+couverture prévue au A et PDJ, pour relancer une commande si nécessaire.
+
+On fait un devis pour le prochain CA pour des bobines de câbles et des bornes.
+
+#### Taggage dynamique
+
+L'idée est de placer les client wifi sur des VLANs différents au moment de
+l'authentification.
+Côté radius, un script python permet d'assigner un VLAN à chaque machine, en
+fonction de différents critères (blacklist, présence d'ipv4). Ça marche.
+
+Coté borne, c'est correctement configuré sur OpenWRT et hostapd. À la connexion,
+le client est bien placé sur la bonne interface. Mais un bug fait que de temps
+en temps, pour certains clients (sur les réauthentifications par exemple), le
+broadcast/multicast ne passe plus. Ce qui empêche les requête ARP, NPD et/ou
+les RA de passer.
+Sinon, ça marche.
+Les images de bornes flashées en ce moment sont configurées pour. Pour l'activer
+en production, il n'y a qu'à faire une modification coté serveur radius.
+
+#### VLAN radin
+
+Maintenant, c'est un vlan ipv6, il y a des RA et un nat64 qui marchent. Il faut
+ajouter un comptage d'upload (qui comprend un log mac_ip) et un log de qui
+contacte quoi quand.
+Pour les logs, il faut soit envoyer le flux ailleurs pour stockage, soit
+utiliser dyson (monitoring avec un mirroring de port) comme cela avait été
+prévu initialement.
+
+### Imprimante
+
+#### Envoi de mails
+
+Lucas a fait un script qui envoie des mails quand l'imprimante est bourrée.
+Le script est pour l'instant stateless, il faudrait lui ajouter une mémoire
+pour qu'il ne spamme pas comme un cochon.
+
+#### Appli intranet2
+
+Daniel a une appli pas finie pour l'intranet2, mais ça avance. L'idée était de
+faire ça de manière modulaire pour avoir dans django la liste des impressions et
+l'état actuel, et avoir l'historique via reversion qui conserverait les
+états successifs.
+Hélas reversion semble bugguer et ça pète les couilles de Daniel.
+De plus, pour interfacer cela facilement avec tout, il a implémenté une file
+de convergence : où on enfile les tâches à imprimer, et où les trucs qui
+impriment viennent chercher leur document à imprimer.
+
+On pourait ajouter une étape intermédiaire à l'impression : la
+compatibilisation :
+1. On upload un pdf
+1. Il se compatibilise, on est notifié qu'il l'est
+1. On lance l'impression depuis la liste des documents compatibilisés
+
+On peut penser à avoir un aperçu du document compatibilisé pour se rendre
+compte que les vidéos, ça ne marche pas en pdf 1.2.
+
+#### Papier de l'imprimante
+
+Ariane, lors de la dernière commande de papier, a pris du papier blanc moins
+cher.
+Ça a l'air de marcher, du coup, ça pourrait être cool de le garder.
+À noter qu'il serait moins blanc que l'ancien, mais en fait, on ne voit pas
+vraiment la différence.
+
+#### «Mise à jour» du 4J
+
+La desserte pour ranger le papier au 4J a été installée, ça marche pas trop mal,
+il y a un peu moins de papiers imprimés partout.
+
+Daniel et Valentin ont débarrassé le 4J des
+vieilleries ({{{mdr}}}, {{{oie}}}, {{{canard}}}, vieilles batteries, etc).
+On y a également migré tout un tas de livres qui étaient au 2B, du coup il y a
+de la lecture au 4J pour ceux qui s'ennuient.
+
+Avant de se lancer dans la commande d'un canap, on va proposer au BdE de
+récupérer deux des ex-sièges espace Condorcet. Ils feraient un bon test de
+canapé, et pour l'instant, à la Kfet, ils sont en train de mourir à petit feu.
+
+### Sip
+
+On est passé de la version {{{svn}}} à la version packagée dans jessie (à coup
+de
+pinning). Ça marche mieux et on n'aura plus à recompiler à la main le tout Ã
+chaque mà j.
+
+Il y a une api (et une commande {{{sip_message}}} sur zamok) pour envoyer des
+IM via python en appelant {{{/usr/scripts/sip/asterisk.py/Sms.send(dst, msg,
+src)}}}.
+
+### Mails
+
+#### caca clueringer et ipv6 -> il FAUT un remplaçant peut être est-ce possible
+avec anvil
+Il semblerait que la version actuelle de policyd ait des problèmes avec l'ipv6,
+qui vient d'être activée pour l'envoi sur smtp.crans.org.
+Du coup, clubringer a été désactivé et il n'y a plus de limite du
+nombre/quantité
+de mails envoyés par utilisateur authentifié. Ça ne doit pas durer, donc soit
+utiliser la version 2.1 de policyd qui a l'air de marcher, soit voir si c'est
+possible avec anvil (à première vue, non).
+
+### Adaptateur USB-ethernet
+
+Le trendnet est bien. Il marche out of the box, il faut juste trouver une
+solution pour mettre un éventuel driver à disposition pour les windows users.
+
+On choisit le modèle Trendnet TU2-ET100 Adaptateur USB 2.0 Ethernet 10/100.
+
+### Politique stockage des mots de passe des scripts
+
+On veux diviser secrets.py pour le rendre plus facilement utilisable et
+modulable (droits d'accès différents) :
+
+* faire plein de petits fichiers
+* laisser tout au même endroit et lancer un autre programme en faisant
+ sudo (avec un NOPASS)
+
+La solution à coup de sudo est préférée, au grand dam de Valentin.
+
+### Nouvelles déconnexions
+
+Deux nouvelles blacklist ont été mise en place : une pour carte invalide et une
+pour paiement. '''Il ne faut plus mettre un bloq pour ces cas-là .'''
+
+On va également demander au C.A. s'il on peut arrêter de demander le certif de
+scolarité/carte d'étudiant après la première adhésion.
+
+### Nom de domaines
+
+On se demande s'il ne serait pas bien que les noms de domaine genre
+vo.crans.org fournissent l'ipv4 associée à la machine, mais aussi l'ipv6.
+
+Le problème de la saturation du lien se pose. Pour l'instant, il vaut mieux
+pousser l'ENS Ã mettre en place l'ipv6.
+
+Si on le fait, il faudrait sans doute mettre en place le domaine .v4.crans.org,
+analogue à .v6.crans.org.
+
+### Questions diverses
+
+#### Perms du jeudi
+
+La perm est trop souvent désertée le Jeudi soir lorsqu'il y a Internounou ou CA
+(c'est-Ã -dire, souvent). On propose donc de passer les horaires de perm du Jeudi
+Ã 18h-19h.
+
+Il faut soumettre ça au CA, et mettre à jour les affiches/wiki.
+
+#### Devis
+
+Xen vers proxox migration dur dur, achat serveur ?
+Dyson weak weak, achat seveur ?
diff --git a/compte_rendus/2013_11_28.md b/compte_rendus/2013_11_28.md
new file mode 100644
index 0000000000000000000000000000000000000000..5ba0344c1d2e2c8a8752c8c6b6266e5afd09762f
--- /dev/null
+++ b/compte_rendus/2013_11_28.md
@@ -0,0 +1,97 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 28 Novembre 2013
+* Lieu : Salle Condorcet (bât d'Alembert)
+* Début : 19h00
+* Fin : ''avant 22h''
+
+## Présents
+
+* Daniel Stan
+* Lucas Serrano
+* Valentin Samir
+
+## Ordre du jour
+
+### Imprimante
+
+Dans l'ordre : bourrage papier répétitif sur le bac 1, puis blocage en erreur
+SAV.
+Print Platinium à demander de confirmer le passage du technique, a priori, il
+n'est pas passé.
+Il faut renvoyer un mail a Print Platinium.
+
+### Vente de matériel / consommable
+
+Depuis 1 an nous vendons des câbles Ethernet. Ceci était fait de manière
+informelle. Nous vendons desormais d'autres consommables et
+matériels (adaptateur USB/Ethernet, boudins de reliure, etc.). Un nouveau menu
+a été créé dans gest_crans pour cela. Il permet pour l'instant de compabiliser
+les ventes d'adaptateur et de câbles. Il faut l'utiliser pour toutes ventes.
+Il faut maintenant rajouter les autres items proposés à la vente.
+
+whos affiche la liste des factures d'un adherent. Pour consulter une facture en
+détail, il vaut mieux utiliser whos_lc.
+
+### lc_ldap
+
+A priori tout fonctionne (factures, ressucite_lc, pretty printing). Il faut
+tester intensivement lc_ldap avant de faire la migration complète.
+Il faudrait peut-être refaire l'affichage de l'item chambre qui est pour
+l'instant importé de whos.
+
+### PXE boot
+
+Valentin a ajouté la dernière ubuntu. Ça serait bien qu'un apprentis voient
+comment on fait pour le mettre a jour.
+
+### Nouveaux disques dur
+
+Les nouveaux disques SAS 2To pour la baie de disque sont arrivés. Ils sont
+installé dans l'ancienne baie de disque.
+Il faudrait savoir comment on les partitionne :
+Pierre-Elliott a suggéré de fragmenter les homes, une partition par lettre de
+l'alphabet, comme ça c'est plus facile pour faire des fsck.
+Il est proposé de faire un volume logique sur la baie, de mettre un LVM dedans
+et de faire une partition sur le LVM par lettre.
+
+On utiliserait 4To des nouveaux disques pour les home (reste 2To de spare)
+. les 600Go pour les VM du crans
+. les 300Go pour les clubs
+
+On laisserait les $HOME dans /home/login et on mettrait un lien lien
+symbolique /home/login -> /home-adh/l/login sur les machines où /home est monté
+en entier, et on tweekerait les script shell de autofs sur les autres.
+
+Daniel propose de créer la nouvelle arboressence sur l'ancienne partition (avec
+les liens symboliques). Cela devrait être rapide (il faut déplacer les dossiers
+des home). Puis de faire des rsync vers les nouvelles partitions.
+
+### Wifi
+
+Bobine de cable reçue, séance au G samedi.
+
+### Enregistrement événementiel
+
+Valentin a mis les conférences des 15 ans, de l'install party 2013, des journée
+fédérez 2013 et quelques autres sur http://video.crans.org (le logiciel s'appel
+mediadrop)
+Les fichiers multimédia sont sur http://ftp.crans.org, on rentre juste les
+liens dans mediadrop. Pour faire du streaming efficace, on utilise du rtmp en
+plus des liens http normaux.
+
+### Etherpad-lite
+
+Valentin a mis la conf au propre et l'a mis dans monit avec un init script.
+http://pad.crans.org/
+Ça marche bien, par contre, la plupart des plugins qui ont l'air utile sont
+relativement caca (memory leak et cie).
+
+### Questions diverses
+
+#### Serveur pour la virtualisation
+
+Pierre-Elliott voudrait dimensionner un serveur de virtualisation a peut près
+comme fz (~16Go de ram, pas de disque dur, des portS ethernet) avec idéalement
+un proc avec 12 Ã 16 coeurs logiques. Le montant du prix serait de l'ordre
+de 4000€.
diff --git a/compte_rendus/2014_01_09.md b/compte_rendus/2014_01_09.md
new file mode 100644
index 0000000000000000000000000000000000000000..f5c3b17a1ddfe4e1ca5be15d2f756ce83ea25cf4
--- /dev/null
+++ b/compte_rendus/2014_01_09.md
@@ -0,0 +1,112 @@
+# Réunion du Collège Technique
+
+* Date :Jeudi 9 janvier 2014
+* Lieu : Pavillon des Jardins
+* Début : 19h25
+* Fin : 20h55
+
+## Présents
+
+* Daniel Stan
+* Valentin Samir
+* Jordan Delorme
+* Pierre-Elliott Bécue
+* Ariane Soret
+* Lucas Serrano
+
+## Ordre du jour
+
+### CACert
+
+Le domaine crans.org à été migré du compte de Stéphane Glondu vers le compte du
+crans. Les certificats ont donc été révoqués puis recréés.
+Tous les administrateurs déclarés à CACert peuvent émettre des certificats pour
+les domaines enregistrés au crans.
+
+### Authentification par certificat
+
+Il serait intéressant de permettre aux gens de se connecter à certains services
+avec une authentification par certificat.
+Par exemple pour le wifi, vu que l'on utilise déjà les mots de passe wifi comme
+un certificat.
+Ça serait cool d'avoir aussi de l'auth par certificat en imap. Dovecot ne
+permet pas nativement d'ajouter de l'authentification par certificat
+parallèlement à une authentification par mot de passe (uniquement comme
+authentification supplémentaire). Ça serait possible de le faire en utilisant
+la méthode d'authentification via script custom, ça n'est pas très propre. Une
+solution plus propre serait de mettre un second serveur imap qui ne ferait que
+de l'authentification par certificat.
+
+Postfix gère bien l'auth par certificat, donc si on décide de mettre ça en
+place ça ne devrait pas poser de problème.
+
+Idéalement, il y aurait une interface sur l'intranet permettant de générer des
+certificats pour divers choses.
+L'idée serait donc d'avoir une bdd centralisant les certificats et leurs usages
+possibles.
+
+### Dns menteur ?
+
+Valentin a mis une zone de response-policy (db.loppsi.crans.org) pour mentir
+plus proprement sur le dns. Pour le moment, c'est utilisé pour renvoyer vers
+les miroirs locaux depuis les vlans accueil et événement.
+Ça serait plus propre d'utiliser cette zone à la place de db.fake (qui est une
+fausse zone racine) pour le vlan accueil.
+
+### IPv6
+
+## ne pas laisser passer le /32 de google semble bien le soulager
+Le /32 de Google a été puni en IPv6 pour des raisons techniques (limitation de
+bande passante alors que l'IPv6 est utilisé préférentiellement).
+Lucas affirme que la diminution de trafic n'est pas lié uniquement aux serveurs
+google, mais est un effet secondaire dû au fait que les gens n'ont plus d'accès
+à un moteur de recherche et arrêtent donc de s'en servir.
+
+Il est cependant peu probable que Microsoft se tire une balle dans le pied en
+bloquant l'ipv4 quand il y a une v6 active, vu que tous ses sites sont en
+v4 (dont bing…). Des tests seront menés sur vo ce soir, et on essaiera
+d'adopter une attitude pertinente.
+
+### Radio
+
+Valentin a mis des jolies n'images sur [[https://intranet2.crans.org/tv/]], et
+un serveur icecast sur Cochon pour relayer la radio.
+
+Valentin voudrait ouvrir le port icecast de cochon pour diffuser la radio vers
+l'extérieur (ça prend pas énormément de bande passante), dans l'ensemble,
+l'idée semble intéressante, il faut juste s'assurer que c'est licite.
+
+### Impression
+
+Certaines personnes semblent parvenir à imprimer N copies d'un document en n'en
+payant qu'une seule. Comme ils ne le souhaitent pas vraiment et nous non plus,
+on cherche une solution.
+Ce problème serait dû au fait que l'intranet thread et donc ne gère pas
+correctement les accès concurrents.
+
+On pense mettre une barrière au bon endroit pour s'assurer que rien ne plante.
+L'alternative est de finir l'appli impression sur l'intranet2.
+
+### Remplacement disque Fy
+
+C'est fait. Le disque pété est (probablement) parti vers HP. Le disque pas pété
+est en place, et fonctionne.
+
+### Virtualiseur
+
+Un devis à été demandé, il devrait bientôt être disponible.
+
+### Questions diverses
+
+#### Nous ? (C'est le goût ?)
+
+Le collège technique accueille trois nouvelles nounous : Raphaël-David, Ariane
+et Jordan.
+
+On précise au passage que la quantité de travail à fournir est laissée Ã
+l'appréciation des sus-nommés.
+Le fait d'être nounou n'engage pas les personnes à s'investir, mais leur donne
+plus d'opportunités quant à leur engagement.
+
+On essaiera de prendre un peu de temps d'ici la semaine prochaine pour
+présenter certaines des « obligations » des nounous (techniques).
diff --git a/compte_rendus/2014_01_23.md b/compte_rendus/2014_01_23.md
new file mode 100644
index 0000000000000000000000000000000000000000..e92dba945e90e5a64249b11d5064e73e1a88afa7
--- /dev/null
+++ b/compte_rendus/2014_01_23.md
@@ -0,0 +1,112 @@
+# Réunion du Collège Technique
+
+* Date : jeudi 23 janvier 2014
+* Lieu : salle Condorcet, bâtiment d'Alembert
+* Début : 19h25
+* Fin : 20h30
+
+## Présents
+
+* Aymeric Labatut
+* Lucas Serrano
+* Pierre-Elliott Bécue
+* Raphaël Cauderlier
+* Valentin Samir
+
+## Ordre du jour
+
+### Be friendly
+
+##Il est suggéré d'accroître la visibilité de
+https://wiki.crans.org/Cr%C3%A9erUnCompteWiki pour la création de compte wiki
+##De manière générale, il faudrait faire une page BienvenueAuCrans ou un truc
+du genre qui pointe vers tous les trucs qu'un nouvel
+##arrivant pourrait vouloir apprendre pour profiter de nos services. Plein de
+pages d'explication gagneraient en visibilité.
+## http://git.crans.org/?p=usr-scripts.git;a=commit;h=f657e57a0 ? -- nit
+
+Il a été soulevé le fait que la création d'un compte Wiki n'était pas triviale
+pour tout le monde. Un lien vers la page idoine a été ajouté depuis la page de
+connexion.
+Il faut faire plus de promotion de nos services pour les nouveaux adhérents,
+notamment la création d'une page wiki (CransPratique ?)
+pour les nouveaux adhérents.
+
+* Merci ! -- WikiCandy <<DateTime(2014-01-23T20:50:21Z)>>
+
+### Nouvelle grappe de disque dur
+
+Le RAID6 est fait, il faut configurer la baie de disques slon pour qu'elle soit
+connectée aussi au switch iscsi. Puis on pourra commencer la migration des
+homes (enfin, leur copie).
+
+PEB commencera ça d'ici une petite semaine, mais si quelqu'un est intéressé,
+qu'il fasse signe.
+
+### DNS
+
+Plusieurs choses. Première rotation des KSK (key signing key dnssec) pour
+crans.eu. On a eu une petite co(q)uille avec bind, mais on l'a réglée.
+
+Les clefs ECDSA sont aussi prises en charge maintenant dans le DNS.
+L'algorithme ecdsa a été ajouté dans le fichier /etc/ssh/sshd_config sur les
+serveurs.
+Les serveurs ne disposant pas de clef ecdsa envoient des warning.
+La commande pour générer une telle clef est :
+sudo /usr/bin/ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -b 521 -t ecdsa -N ""
+
+Le collège des nounous présentes décide collégialement dans la bonne humeur
+d'activer l'ipv6 sur les noms de domaine par défaut.
+Par souci de compatibilité, en plus des zones v6 (qui sont ipv6 only), des
+zones v4 seront alors créées (qui seront ipv4 only).
+
+Actuellement seules les machines ayant l'attribut ldap dnsipv6=TRUE ont de
+l'ipv6 dans leur nom de domaine. Valentin propose de l'utiliser à partir de
+maintenant comme suit : seules les machines avec l'attribut ldap dnsipv6=FALSE
+garderont un nom de domaine ipv4 only.
+
+Les machines concernées seraient :
+
+* charybde (pour éviter de faire passer le ftp à traver le tunnel ipv6)
+
+Comme le script actuel de génération des zones des dns est vieillisant, il
+serait bien d'adopter ces modifications en écrivant un nouveau script, dans un
+style plus fonctionnel, utilisant lc_ldap.
+
+### Nouveau virtualiseur
+
+Son nom est ft.
+Le nouveau virtualiseur est arrivé, a été installé, et s'appelle ft. On l'a
+foutu au 0B, et on a viré malloc, daath et gordon. Niveau alimentations on est
+Ã poil, faudrait racheter une pdu (oui, un truc qu'on visse dans l'armoire Ã
+l'arrière).
+
+Il marche bien, proxmox est installé, la migration marche, il est connecté à la
+baie de disques, et il est FAT. (pas 32)
+
+Il n'a que 16 Go de RAM sur les 300 potentiels qu'il peut avoir. On achètera
+peut-être quelques barrettes de 8 Go.
+
+Sinon, l'onduleur est sollicité à 67 % de sa puissance maximale.
+
+Il est possible que ses batteries soient déficientes. Il faudrait donc faire
+des tests, sachant que l'onduleur est censé tenir 40 min au moins.
+
+### Nouvelles bornes
+
+Say hello to Demodocos, pour le bâtiment Leonard de Vinci !
+Jordy aimerait poser encore d'autres bornes (3 serait appréciable) au Leonard
+de Vinci, car il n'y a strictement rien.
+De plus, ''hel'' ne marche pas : un technicien va la rebooter électriquement au
+cas où.
+
+### Questions diverses
+
+#### Et pour l'écran de vo
+
+Le rétroéclairage ne fonctionne plus. Valentin propose qu'on achète un écran
+de 30 pouces. PEB dit qu'il est pour si on achète un nouveau vo avec une GPU
+suffisante.
+
+Plus sérieusement, on se propose de racheter un écran de la même gamme de
+qualité (que celui-ci avait en 2008).
diff --git a/compte_rendus/2014_02_06.md b/compte_rendus/2014_02_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..3ab335c1889965a0571068c0735ca47be1207b05
--- /dev/null
+++ b/compte_rendus/2014_02_06.md
@@ -0,0 +1,135 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 6 février 2014
+* Lieu : Salle de conférence du Pavillon des Jardins
+* Début : 19h00
+* Fin : 20h30
+
+## Présents
+
+## Ordre du jour
+
+### Interfaçage de cranspassword avec ldap
+
+On a rajouté un attribut gpgMail (en plus du gpgFingerprint) dans la base ldap.
+Il est fonctionnel dans le nouveau binding, mais pas encore dispo dans
+gest_crans.
+Daniel a écrit un script qui génère la configuration de cranspassword serveur Ã
+partir de la base ldap (en se servant des attributs droits, gpgFingerPrint et
+gpgMail).
+Pour le moment, la base a été peuplée (pour l'attribut gpgMail) pour tous les
+gens qui avaient donné une fingerprint.
+
+Il sera bientôt mis en production.
+Question : modifie-t-on la configuration de manière automatique (via un cron)
+ou requiert-on une intervention humaine pour confirmer les modifications de
+droits ? On décide de garder un système de confirmation avant d'appliquer les
+modifications (Ã la bcfg2) pour rendre la chose failproof.
+
+Todo : écrire une application sur l'intranet2 (dans mon compte) pour enregistrer
+les fingerprint/mail.
+
+### apt-key
+
+Le crans possède un dépôt custom pour les paquets qu'il crée pour lui même (par
+exemple bcfg2).
+Ces paquets sont alors signés par une nounou (avec sa clef gpg). Aussi, faut-il
+installer ces clefs sur les serveurs dans la configuration d'apt pour pouvoir
+installer les paquets sans warning.
+Les clefs sont dans bcfg2.
+Rappel: il y a un
+script {{{/usr/scripts/gestion/tools/apt-keys-crans.py}}} pour mettre Ã
+jour les clefs sur bcfg2.
+
+Pour le moment il est exécuté manuellement. Valentin propose de le croner et de
+retirer les fichier générer du dépôt git de bcfg2.
+
+Pas d'objection cinglante.
+
+### Génération du dns
+
+Valentin a réécrit le script bind.py de génération du DNS. C'est moins
+monolithique, plus POO et ça utilise lc_ldap.
+Changement notable : Les machines ont leur IPv6 d'annoncée par défaut par leur
+nom de domaine.
+
+* {{{nom.v4}}} retourne seulement l'IPv4.
+* {{{nom.v6}}} seulement l'IPv6.
+
+Il y a une case à cocher dans l'intranet2 dans l'application machines pour
+désactiver ou réactiver ce comportement.
+
+Deux trois problèmes:
+
+* {{{freebox}}} et {{{ovh}}} ont des IPv6 erronées dans la base
+ ldap (IPv6 locales) -> plus joignables une fois annoncée dans le DNS
+* {{{zbee}}} -> pour des raisons de NFS qui essayait de se monter en IPv6 Ã
+ travers le pare-feu
+* munin -> les acl des nodes n'autorisaient pas l'IPv6 (connexion refused) ce
+ qui empêchait le fallback IPv4
+
+### IPv6
+
+Daniel a reregardé Huricann-Electrics : le plan était d'adhérer à Gitoyen pour
+pouvoir lui demander un numéro d'AS (Autonomous System) et des IPv6.
+Niveau coût il faudrait payer l'adhésion à Gitoyen (entre 100 et 200€) plus des
+frais
+administratifs (entre 200 et 300€).
+Pierre-Elliott fait remarquer qu'on adhère à FedeRez pour un prix plus élevé.
+Niveau administratif, il faut étudier la question (demander au CA).
+
+Valentin fait remarquer que quand bien même, avoir ses propres IPs serait bien
+sympathique, il faut s'assurer de pouvoir les utiliser le jour où l'ENS passe
+en IPv6. Aujourd'hui pour annoncer ses propres IPs via H-E, le tunnel de sortie
+se trouve à Londres au lieu de Paris. Ce qui fait passer le RTT de 1ms à 8ms.
+
+### CaCert et clubs
+
+L'idée est de générer des certificats SSL !CaCert pour les machines de clubs
+qui en font la demande.
+
+Sur le principe ok. Seul problème : si la machine est détruite, le certificat
+existe toujours alors que le domaine peut être utilisé par quelqu'un d'autre.
+
+Soit on révoque directement les certificats quand la machine disparaît, via
+une API (qui n'a pas l'air dispo pour l'instant
+sur [[CransTechnique/CaCert|CaCert]]).
+
+Soit on empêche les opérations sur les machines qui ont toujours un certificat
+valide.
+
+API à étudier : http://wiki.cacert.org/Software/IntegrationInterface
+http://wiki.cacert.org/SubRoot
+
+Il serait bien d'avoir une interface sur l'intranet2 (étendre l'interface de
+machine)
+pour permettre de faire des demandes de certificats (et si l'API de !CaCert ne
+marche pas,
+une interface pour y répondre manuellement).
+
+### Digicode
+
+Lucas a rajouté une option sur l'app digicode pour créer des codes. Ça a l'air
+de marcher.
+
+Reste plus qu'Ã migrer le tout.
+
+### Édition .forward
+
+Raphaël-David a fait un script pour éditer des {{{.forward}}}. Reste à régler
+le problème de droits d'exécution du script (qui s’exécute en root pour
+l'instant).
+Il pourrait être envisagé de donner le droit au groupe respbats d’exécuter le
+script en temps que n'importe qui du groupe user et de le lancer en temps que
+l'user dont on veut éditer le .forward (cf ce qui est actuellement fait pour
+l'intranet1).
+
+### ft
+
+Il est installé au 0B physiquement et logiciellement. Ça marche.
+Il ne reste qu'Ã finir les migrations depuis Xen.
+
+### Wifi
+
+La DSI abandonne le ssid ENS Cachan. On arrête donc définitivement de le
+diffuser.
diff --git a/compte_rendus/2014_02_20.md b/compte_rendus/2014_02_20.md
new file mode 100644
index 0000000000000000000000000000000000000000..794999ee2e8a6a9e13ac144502af70fb28a8f53b
--- /dev/null
+++ b/compte_rendus/2014_02_20.md
@@ -0,0 +1,141 @@
+# Réunion du Collège Technique
+
+* Date : 20 février 2014
+* Lieu : Salle de conférence du Pavillon des Jardins
+* Début : 19h19
+* Fin : 21h00
+
+## Présents
+
+* Ariane Soret
+* Aymeric Labatut
+* Daniel Stan
+* Lucas Serrano
+* Jordan Delorme
+* Raphaël-David Lasseri
+* Riwan Kherouf
+* Valentin Samir
+
+## Ordre du jour
+
+### Digicode
+
+Lucas a mis en place le nouveau digicode_server et gen_code sur intranet2 et
+sur asterisk.
+Pour générer un code à partir de l'intranet2, il faut accéder à l'interface
+admin de django.
+Sinon, on peut toujours en générer sur l'intranet1…
+
+### lc_ldap
+
+Valentin a surchargé les attributs de lc_ldap pour permettre une comparaison
+plus simple (et fonctionnelle) entre des objets ldap.
+L'égalité fonctionne de façon sémantique sur les objets et les attributs comme
+on pourrait s'y attendre (du coup {{{'club' in
+club['objectClass']}}} fonctionne).
+Les attributs peuvent être instanciés par leur type python correspondant (au
+lieu de juste des unicodes).
+Si deux attributs sont égaux, ils ont le même hash (cf. set et hashtable).
+Les attributs pythons des attributs ldap Attr sont directement accessibles
+comme des attributs d'Attr.
+Les {{{machines['historique'].append()}}} fonctionnent comme on pourrait s'y
+attendre et plein d'autres bonnes choses !
+
+D'une manière générale, si on a besoin d’accéder à {{{attrs}}} sur
+les !CransLdapObject ou à {{{value}}} sur les Attr,
+c'est qu'il manque, sans doute, une méthode à écrire ou surcharger quelque part.
+
+### Enregistrement automatique des adresses MAC
+
+Daniel arrive à faire de l'authentification radius pour le WPA2 sans utiliser
+le module radius dédié à cela mais en utilisant un script python.
+Lors de l'authentification d'un client sur une borne, la borne met en relation
+radius et le client, et radius l'authentifie avant de renvoyer le résultat à la
+borne.
+
+Une idée en utilisant un script custom serait de pouvoir ne fournir aux
+adhérents, lors de l'enregistrement d'une nouvelle machine wifi, que le nom
+d'utilisateur et le mot de passe. Puis de remplir l'adresse mac de la machine
+seulement lors de la première authentification réussie en utilisant celle de la
+première machine qui s'authentifie.
+
+Les gens présents ont l'air assez enthousiastes pour le wifi. Une option
+similaire en filaire reste à discussion.
+
+Il serait également bien que la première fois que l'adresse mac est
+enregistrée, comme la machine vient de se connecter, qu'elle puisse accéder Ã
+internet. Pour le dhcp, la mise à jour est déjà instantanée. Il manque la mise
+Ã jour du pare-feu, au moins celui de komaz.
+
+Valentin propose une solution à partir d'une clef ssh n'ayant que le droit de
+trigger l'appel à generate en s'inspirant
+de [[CransTechnique/AdminRéseau/CommunicationsParSshEntreLesServeurs]].
+Nicolas aurait parlé d'une solution rabbitmq qui pourrait à terme remplacer le
+système maison generate.
+
+### intranet2
+
+#### Création de compte wiki
+
+Fait.
+
+#### Gestion des clefs ssh
+
+Valentin a ajouté la possibilité de remplacer les attributs sshFingerprint de
+ses propres machines. Ils sont alors publiés dans le DNS du crans.
+
+### DNS
+
+#### TLSA
+
+Valentin rappelle brièvement que TLSA est un enregistrement DNS permettant de
+vérifier la validité d'une clef publique du standard x509 via le DNS.
+
+Pour pouvoir permettre aux adhérents de publier, dans le DNS de leur machine,
+leur certificat, il faudrait ajouter un nouvel objet ldap enfant des objets
+machines (n'a pas de sens en LDAP) qui aurait en attribut :
+
+* name : les noms de domaine pour lesquels le certificat est
+ utilisé (multivalué)
+* port : les ports sur lesquels le certificat est utilisé (multivalué)
+* proto : tcp ou udp (multivalué)
+* cert : quelque chose représentant le certificat (monovalué)
+* certtype : le type d'enregistrement ; 0 = CA pinning, 1 = cert
+ pinning, 2 = self trusted CA, 3 = self trusted cert (monovalué)
+* reftype : 0 = plain cert, 1 = sha256, 2 = sha512 (monovalué)
+
+À voir si on veut utiliser l'objet pour gérer les certificats d'une manière
+générale…
+
+#### Blocage via response policy zone
+
+Valentin avait lors de l'install party précédente mis en place un DNS menteur
+renvoyant archive.ubuntu vers
+le miroir local.
+Récemment il a étendu le rôle du DNS menteur à la zone crans pour empêcher les
+IP utilisés par
+Teredo (tunnel v6 propre aux machines sous windows) de contacter le DNS et
+ainsi de faire de l'IPv6 pirate.
+Théoriquement la future présence de RA pirates sur le réseau ne serait donc
+plus fortuite
+(en tout cas beaucoup moins).
+
+### Remplacement de ovh
+
+Une nouvelle machine est prête pour remplacer ovh : soyouz.
+''A priori'', Valentin a fini sa configuration. Il faut juste modifier les
+enregistrements du dns (MX et NS et glue record) pour remplacer ovh.
+le TLSSTART en smtp ne marche pas, il faudrait juste mettre une paire de clefs.
+
+On va rendre ovh, il faudrait donc prendre le temps de shred les disques en
+rescue mode.
+
+### Question diverse
+
+#### Migration XEN -> Proxmox
+
+Daniel propose de faire une séance migration samedi après-midi (tôt pour ne pas
+concurrencer la LAN A♡).
+Les volontaires ne lèvent pas tous le doigt en même temps.
+Daniel annonce donc une « petite » maintenance sur CransIncidents et sur les
+news.
diff --git a/compte_rendus/2014_03_13.md b/compte_rendus/2014_03_13.md
new file mode 100644
index 0000000000000000000000000000000000000000..3658d3ef74900499588f2237b9a35e4fd76df696
--- /dev/null
+++ b/compte_rendus/2014_03_13.md
@@ -0,0 +1,196 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 13 mars 2014
+* Lieu : Salle de conférence du Pavillon de Jardins
+* Début : 19h22
+* Fin : 21h12
+
+## Présents
+
+* Jordan Delorme
+* Lucas Serrano
+* Pierre-Elliott Bécue
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Gestion des certificats
+
+Valentin a proposé de mettre tous les certificats SSL crans et les clefs
+privées associés (possiblement chiffrées) dans ldap et d'utiliser un fuse pour
+générer automatiquement les fichiers de certificats dont ont besoin les
+différents services directement à partir de ldap.
+
+Les certificats pourraient ensuite être gérés par {{{bcfg2}}}, une mà j des
+certifs consisterait à mettre le nouveau en raw dans LDAP et de run
+un {{{bcfg2}}} wherever needed.
+
+Pierre-Elliott est contre la présence des clés privées dans LDAP si on ne lui
+donne pas une bonne raison (et lui-même n'en voit pas). Il faudrait quelqu'un
+de motivé par le projet parce que ça risque de ne pas être simple.
+
+Dans l'idée {{{bcfg2}}}, Vincent pense qu'il va falloir gérer les différents
+formats de certificats. Est-ce qu'on ne pourrait pas faire
+comme {{{secrets.py}}} ou {{{secrets_new.py}}} ? Problème : actuellement, tout
+va sur tous les serveurs.
+
+On attend d'y voir plus clair et d'avoir les idées de Valentin sur le sujet.
+
+### Multicast filtering
+
+Sur le réseau les Apple utilisent un protocole foireux, mDNS.
+
+Le principe est d'annoncer les services des autres machines sur le réseau, même
+quand elles en ont disparu (passage en veille). Pour cela, elles spoofent l'IP
+de la machine éteinte. C'est '''mal''', et ça fait beugler {{{arpwatch}}}. On
+en a eu marre, Ping a demandé aux switchs de dropper le mDNS.
+
+Problème, ça ne marche que sur les switchs Gigabits et le backbone.
+Techniquement ça resterait possible entre deux personnes d'un même étage,
+mais ''a priori'', le multicast n'est transmis qu'une fois qu'il a atteint le
+querier, à savoir le backbone, qui sait dropper, donc on est sauvés.
+Bonne nouvelle, on a '''beaucoup''' moins de spam sur flip-flop, et tout ce qui
+reste est normalement des vrais cas de spoof (ou des changements légitimes
+d'adresse MAC suite à un câblage).
+
+### Virtualisation
+
+#### Xen => Proxmox
+
+La migration c'est fini. \o/
+Les vieux disques ont été supprimés. Il faut faire attention car les serveurs
+ont tendance à paniquer lorsque l'on supprime leurs vieux disques.
+
+Nouvelles features :
+
+* Pierre-Elliott est en train de développer des utilitaires en command line
+ pour créer des VM plus facilement. L'objectif idéal serait d'avoir un seul
+ script à lancer, mais si déjà , avec quelques scripts tout faits, on s'en sort…
+* Les VM utilisent des disques virtIO, qui ont des temps d'accès beaucoup plus
+ courts que les émulations de IDE/SATA/SCSI. Du coup ça juste marche mieux.
+* Les filesystems (qui étaient en ext3 sur les vieilles vm) sont en ext4.
+* Proxmox utilise les fonctionnalités VTx with extended pages des procos intel,
+ ce qui permet aux vm de fonctionner en real mode. C'est pas trivial à définir
+ mais en gros, le gain de perf est vraiment élevé.
+* PEB a fait une conf manuelle qui est dans {{{bcfg2}}} pour l'ISCSI.
+ Maintenant, quand les hosts démarrent, ils ne vont plus attendre 2 minutes
+ toutes les interfaces des baies. Sur les interfaces non branchées, ils
+ n'attendent que 15 secondes.
+* Le cluster est composé de fz, ft et kdell. fz et ft sont fat, et kdell se
+ défend. Du fait de l'utilisation des features VTx with extended pages des
+ procos, fy est useless. (Son proco ne les supporte pas, ce qui fait que les
+ vm migrées depuis l'un des trois autres sur fy, elles freezent en
+ utilisant 100% d'un cœur.)
+
+Ce qui nous mène à : « quid de fy ? »
+
+PEB va essayer de documenter le wiki, parce que chez Proxmox, ils sont
+clairement avares en infos sur certains points de fonctionnement des clusters.
+
+Entre autres, il a tweaké le {{{/etc/hosts}}} des hosts Proxmox pour que leur
+nom « canonique » (celui sans le (.adm)?.crans.org) pointe vers leur IP adm,
+car c'est avec ce nom que le cluster choisit ses IP. On remercie entre autres
+les gars de chez Proxmox qui précisent pas ça sur la page « créer un cluster ».
+
+Pour info, Proxmox vend un service (sous forme de licence) d'aide et de je sais
+pas trop quoi, à un prix modeste : une trentaine d'euros par cœur par mois. Et
+bien entendu, TOUS les hosts DOIVENT avoir la MÊME licence.
+
+#### Avenir de fy
+
+{{{fy}}} ne servant à rien et étant vraiment fat, il faut se demander ce qu'on
+en fait. Dyson est complètement à la ramasse en ce qui concerne le monitoring,
+et komaz commence à se faire un peu vieux.
+
+Entre les deux, celui qui fitterait probablement le mieux serait dyson.
+D'autant plus que la garantie de fy expire, et qu'un routeur non garanti, c'est
+pas cool.
+
+##### Avenir de komaz/dyson
+
+Il semblerait bon de racheter un nouveau routeur, pour des raisons de garantie,
+en plus, il serait bénéfique qu'il fasse le comptage d'upload lui-même, pour
+décharger le serveur de logs (cf point suivant).
+
+S'il est dimensionné correctement, ça passera sans problème. Valentin avait
+suggéré qu'on pourrait améliorer le comptage d'upload pour décharger la base
+postgres. À voir aussi.
+
+Ping évoque le SSD, ça pourrait être intéressant pour le futur komaz. Pour
+thot, il faut y réfléchir. Pour dyson c'est pas utile.
+
+Passer dyson sur fy semble pas mal.
+
+#### Elastic search ftw ?
+
+Logstash l'utilise comme backend. Logstash est paraît-il très bien. On a testé
+les limites de rsyslog-pgsql. Il faudrait tester, quitte à migrer les db
+postgres sur des VM.
+
+Avis aux amateurs pour tester elasticsearch.
+
+### Application des nouveaux statuts
+
+PEB a commencé à recoder la moitié de {{{gest_crans}}} et {{{ldap_crans}}} pour
+qu'on puisse appliquer les adhésions glissantes. Des tests seront faits ce
+weekend ou le suivant. Il faut prévenir les câbleurs, et leur empêcher
+l'utilisation de gest_crans durant les tests.
+
+Les modifs sont sur la branche {{{peb}}} du dépôt de prod. Faites gaffe à pas
+checkout dessus.
+
+### Services/Generate
+
+Nicolas a parlé de {{{rabbitmq}}} comme système pour dispatcher des
+messages/informations à d'autres machines, en remplacement de generate/services
+qui marche mal, en 15 min. PEB a testé sur des trucs kikoo, c'est rigolo. On a
+installé une vm {{{civet}}} qui servirait de serveur rabbitmq. D'autres tests
+sont à venir, et les curieux peuvent query PEB.
+
+### Gestion des homes
+
+PEB a créé 27 disques logiques sur la baie, olasd trouve que ce n'est pas
+adapté, quid des autres ?
+
+* Le problème des quotas n'a pas encore été soulevé, 27 filesystems ça veut
+ dire 27 quotas différents. Mais ça peut se régler en se disant que toto
+ passoir ne peut écrire que dans son home.
+* /home/mail => ln -s /home/mail/user/ /home/user/Mail/INBOX
+
+. Attention NFS n'exporte pas les liens symboliques comme on le
+veut. (zbee != zamok)
+
+### Wifi au PdJ
+
+La DSI nous a chié au visage pour le tirage des câbles pour nos bornes au PdJ.
+Donc on devra en tirer nous-même.
+
+Envoie-t-on un mail courroucé à la DSI ?
+
+* Owi owi -- [[Wiki20-100]]
+
+### Migration de git
+
+Le dépôt {{{git}}} a été viré de charybde. Ça permet de puller/pusher sans
+attendre des heures qu'il ait fini avec ses IO ftp. Maintenant,
+contactez {{{geet}}}.
+
+Vire-t-on les miroirs OpenBSDÂ ?
+
+### Paquet pour ajout de certificats sur Mac
+
+Jordy et Ping ont travaillé sur un paquet pour importer les certificats
+nécessaires pour nos pages. Ce paquet pourrait être l'occasion de modifier le
+comportement mDNS de Bonjour pour éviter les problèmes posés quelques points au
+dessus. Ça sera, a priori, bientôt terminé.
+
+### Le RTC est malade :(
+
+Valentin semble malade depuis presque deux semaines. Il risque de rentrer chez
+lui pour quelques temps. Les nounous souhaitent lui témoigner leur soutien et
+lui souhaitent un prompt rétablissement.
+
+Pierre-Elliott et Daniel s'occuperont de contacter Anne en cas de besoin durant
+l'absence de celui-ci (demandes de devis et autre). On lui demandera de nous
+mettre en copie des mails qu'elle lui envoie (renouvellement de
+garanties & cie).
diff --git a/compte_rendus/2014_03_27.md b/compte_rendus/2014_03_27.md
new file mode 100644
index 0000000000000000000000000000000000000000..0f942b88a2f60f22288ba063dee1a94370a2e9b8
--- /dev/null
+++ b/compte_rendus/2014_03_27.md
@@ -0,0 +1,104 @@
+# InterNounous
+
+* Date : Jeudi 27 mars 2014
+* Lieu : Salle de conf au Pavillon des Jardins
+* Heure : 19h33
+* Fin : 21h00
+
+## Présents
+
+* Aymeric Labatut
+* Daniel Stan
+* Jordan Delorme
+* Lucas Serrano
+* Pierre-Elliott Bécue
+
+## OdJ
+
+### GitLab et migration des dépôts git
+
+Pierre-Elliott a commencé à mettre en place gitlab
+
+Démo
+1. Aller sur http://gitlab.crans.org
+1. Se loguer avec son compte ldap (CAS ??)
+
+But : Plus d'acl sur les dépôts. Ça marche aussi avec des comptes locaux (≠non
+crans).
+Le https est maintenant par défaut. L'intérêt est d'accroître la visibilité des
+dépôts git du Crans et gérer des pull request.
+Question : quid de gitweb (http://git.crans.org ) pour l'instant, on le
+garde (tant que ça marche).
+
+Il faut ajouter une clé ssh dans son profil gitlab, pour pouvoir ensuite se
+connecter en tant que l'utilisateur git.
+Comme tout passe par l'utilisateur git sur le serveur, les modifications,
+commits et pushes en prod seront sensiblement
+plus complexes à faire, sauf à forwarder son agent, ou à s'ajouter une clef ssh.
+
+### Nouvelles bornes WiFi
+
+On a reçu les nouvelles bornes WiFi au nombre de 12.
+
+Le modèle reçu a été mis à jour, le système de fixation a changé.
+Et surtout, on a des injecteurs avec bouton reset (bien pratique quand accéder
+physiquement à la borne est compliqué).
+
+Lucas a flashé 3 bornes dans le but de les mettre au bâtiment A. Il faut se
+faire une séance posage de bornes avec les apprentis.
+On propose le week-end du 4 Avril.
+Reste également : le Pavillon des Jardins. On se demande s'il ne vaudrait pas
+mieux mettre les bornes en dehors des faux-plafonds (qui sont
+métalliques). À étudier et à discuter avec M Burgun…
+
+Jordy a posé 4 bornes au DGM, en attente de brassage de vlan côté DSI. (Link,
+agenor, polynice, ulysse). On attend encore leur inscription sur
+la [[https://intranet2.crans.org/wifimap|WiFiMap]] !
+
+### Nouveau routeur
+
+Pas encore reçu de devis. L'idée serait de remplacer komaz par un truc un peu
+plus costaud.
+
+A priori :
+http://store.hp.com/FranceStore/Merch/Product.aspx?id=668812-421&opt=&sel=BSRV#merch-tech-specs
+(Vérifier que le contrôleur réseau 4 ports a bien une capacité de switching
+de 1Gigabit par port et non 1Gigabit au total)
+
+### Homes des adhérents
+
+Pierre-Elliott avait créé un lvm par lettre de l'alphabet (+ 1 pour les logs).
+Une ancienne nounou trouve que ça fait beaucoup. L'intérêt serait de
+fractionner les sauvegardes, et de récupérer plus facilement d'un crash sur un
+des fs.
+
+Reste le problème de la migration…
+
+### Sécurisation de /usr/scripts
+
+Pierre-Elliott propose que chaque serveur clone /usr/scripts, avec un cron qui
+vérifie également la connectivité du nfs. En cas de soucis, il ferait un
+mount -o bind
+
+Il faut trouver une solution avec /usr/scripts/var/
+
+* monit (quasi ok)
+* numeros_disponibles -> voué à disparaître
+* fichiers d'impression -> censés être dans le home des adhérents
+* […]
+
+Avis à apprenti et nounou motivés
+
+### CACert
+
+!CaCert a été retiré de Debian
+https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434
+
+Question :
+1. Le ticket soulève des problèmes de sécurité dans le code de CACert, a-t-on
+peur ?
+1. Quelle alternative à ce CA ?
+1. Que faire si on migre ? Aka migre-t-on tout sur un CA commercial ou
+laisse-t-on le WiFi sur !CaCert ?
+
+On ne prend pas de décision maintenant.
diff --git a/compte_rendus/2014_04_10.md b/compte_rendus/2014_04_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..f93abbd8e8014dacaa66a5e5207645092abc6aba
--- /dev/null
+++ b/compte_rendus/2014_04_10.md
@@ -0,0 +1,199 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 10 avril 2014
+* Lieu : Condorcet
+* Début : 19h30
+* Fin : 21h15
+
+## Présents
+
+* Pierre-Elliott Becue
+* Jordan Delorme
+* Vincent Le Gallic
+* Lucas Serrano
+
+## Ordre du jour
+
+### HeartBleed (OpenSSL)
+
+On ne rappelle pas les faits : ils sont suffisament détaillés sur le net.
+Tous les certificats accessibles depuis l'extérieur du campus ont été
+renouvelés sauf redisdead.
+
+* j'imagine que le renouvellement des clefs privées est sous entendu, ça serait
+ bien de remettre le TLSA un peu partout (via {{{gest_crans_lc}}} par
+ exemple), le certificat de sogo est révoqué, quid des clefs du openVPN
+ soyouz-komaz-titanic qui donne accès Ã
+ adm -- ValentinSamir <<DateTime(2014-04-11T01:35:09+0200)>>
+
+Pierre-Elliott a plus ou moins écrit une page Wiki pour informer les adhérents
+de la faille de sécurité.
+Lien de la page : HeartBleed
+
+Il faut encore renouveler les certificats de :
+
+* Redisdead (x2)
+* XMPP
+* O2
+* Asterix
+* Wifi
+* News
+* Tracker
+
+### QR codes
+
+Le BDE/Gala souhaiterait savoir si le Cr@ns peut éditer les QR codes en plus de
+les imprimer.
+
+Y'a plein de lib python pour faire des QRCode. Il faudrait faire un site web
+pour les organisateurs du gala.
+On peut utiliser l'interface d'admin d'une appli django.
+
+On manque pas mal d'infos sur le cahier des charges :
+
+* Est-ce qu'on doit permettre le paiement en ligne ?
+* Comment ça se passe pour les bipper le soir du gala ?
+
+On va demander de plus amples précisions au gala.
+
+Daphné, membre du bureau du gala 2015 a précisé à Pierre-Elliott le cahier des
+charges pendant qu'il allait chercher son linge (ah bah bravo).
+L'idée serait d'avoir un site dédié à la gestion des préventes en ligne, donc
+l'édition des billets avec QR code, le stockage des informations personnelles
+des acheteurs, et l'interface de paiement en ligne.
+
+* Pour le paiement, elle se mettra en relation avec le crédit mutuel ;
+* Pour l'édition des pdf billets/whatever, on peut le faire.
+* Pour les scanettes de QRCode, il faut trouver un endroit où en acheter/louer,
+ pour faire des tests
+
+et voir combien ça coûte.
+
+Pierre-Elliott la recontactera par mail pour établir une roadmap.
+Une deadline courte devra être faite pour le site pour que le gala puisse se
+retourner librement
+si on est pas assez efficaces.
+
+### Virtualisation
+
+Le BdE trouverait confortable de virtualiser ses serveurs : tous sauf
+videosurveillance.
+
+Vincent trouve gênant de prendre maintenant une décision engageant les nounous
+Ã venir et les BdE Ã
+venir de rendre ''techniquement'' accessible aux nounous la base de données du
+BDE de manière irréversible.
+Ceci serait valable quel que soit le club/assoce qu'on virtualise.
+
+On pourrait modifier notre charte de membre actif en précisant qu'on héberge
+des serveurs contenant potentiellement des données d'adhérents non Cr@ns.
+Pour les clubs, il est possible de préciser dans le formulaire de création de
+club que leurs données sont stockées dans un serveur du Cr@ns, ou alors créer
+un formulaire de création de machine virtuelle pour que chaque parti soit
+conscient des enjeux.
+
+Vincent veut bien s'occuper d'écrire un formulaire de création de machine
+virtuelle, il demandera conseil à Matthieu Bach.
+
+### Droits apprentis
+
+La problématique soulevée est que les câbleurs/apprentis ne peuvent pas
+répondre aux demandes des adhérents
+concernant leur blocage pour upload.
+
+Vincent croyait que c'était possible aux apprentis, et a donc fait une
+modification dans le sudoers, qui a été annulée
+par Pierre-Elliott depuis.
+
+Actuellement, la question est donc de savoir si les apprentis devraient avoir
+ce genre de droit. (exécuter analyse.py, ou autres scripts du style)
+
+Vincent souligne que les apprentis ont accepté la même charte de membre actif
+que les nounous et sont donc soumis
+aux mêmes règles. Par ailleurs, supprimer de la fonctionnalité au nom de la
+sécurité n'est pas une solution. Enfin, les adhérents
+qui demandaient des réponses sur disconnect@ n'avaient pas forcément une
+réponse avant l'expiration des logs.
+
+* il y a un dump des logs d'{{{analyse.py}}} lors de la déconnexion
+ dans {{{/usr/scripts/var/analyse/IP-TIME.txt}}}, il faudrait d'ailleurs y
+ faire le ménage -- ValentinSamir <<DateTime(2014-04-11T01:35:09+0200)>>
+
+Premièrement, on peut augmenter la durée de vie des logs d'upload.
+
+Il est envisagé de créer un droit supplémentaire "Disconnect" permettant aux
+apprentis à qui on le donnerait de pouvoir répondre aux
+adhérents sur disconnect@ et de lancer {{{analyse.py}}}. Il faudrait qu'il ne
+soit pas donné dès l'accession au statut d'apprenti.
+Dans la même idée, une version spéciale "nouveau câbleur" du whos pourrait être
+proposé pour filtrer certaines données a priori
+sensibles lors d'un câblage.
+
+### Charte des MA
+
+Pierre-Elliott propose qu'on édite une charte spécifique à signer pour les
+nounous (ce qui permettrait de faire une
+page wiki au passage pour résumer les droits (et leur moyen d'application) des
+nounous), spécifique à leurs nouvelles
+attributions. Cela servirait en plus de piqûre de rappel lors de l'ajout de
+droit.
+
+### IRC
+
+Il y a actuellement sur #roots des non-MA. Ça pose problème quand on doit
+parler de données privées d'adhérents : on n'a pas de channel "privé".
+Si un adhérent doit évoquer des informations personnelles sur #crans, il sera
+alors invité à rejoindre #roots.
+
+Les non-membres actifs actuellement présents sur #roots vont être invités Ã
+quitter le channel.
+
+### Câbleuse
+
+On se propose de mettre la carcasse de oie à la Kfet après l'avoir transformée
+en câbleuse, branchée à l'imprimante thermique.
+Si on souhaite installer une interface graphique pour que la câbleuse puisse
+être utilisée par les permanenciers BDE pour la note
+en dehors des horaires de permanences Cr@ns, oie est vite gavée. Une solution
+serait d'installer XFCE ou awesome.
+
+On a pas de réponse de BdE sur cette possibilité de câbleuse, l'encombrement du
+bar ou la possibilité de mettre un écran.
+
+### Questions diverses
+
+#### Convention Cr@ns-CROUS
+
+Il faut en parler en CA, mais en gros, une réunion doit être organisée avant
+l'été, de façon Ã
+l'actualiser, voire, la resigner.
+
+En vrac, les points à discuter :
+
+* Fiche câblage
+* Locaux sensibles
+* Access points (WIFI)
+
+En bonus (non lié à la convention)
+
+* Livret d'accueil du CROUS
+
+#### Manque d'IP
+
+On va demander à Daniel s'il peut remettre en service son système de ménage
+automatisé. Aussi bien pour le wifi que le filaire.
+
+#### Ressuscite
+
+{{{ressuscite.py}}} est cassé, encore…
+Vincent a ressuscité récemment un adhérent en plongeant encore les mains dans
+le cambouis, il en a marre, il va mettre dans {{{/usr/scripts/utils/}}} un truc
+pour
+dumper un adhérent du cimetière et y'aura plus qu'à faire un coup de
+shelldap. (gruik)
+
+* Il ne faudrait plus supprimer des entrées de la base de donnée que
+ avec {{{lc_ldap}}}. {{{chambre_vide.py}}} ou l'intranet2 pour les machines
+ et {{{gest_crans_lc}}} pour les adhérents par
+ exemple. {{{ressucite_lc}}} bien que basique fonctionne a
+ priori -- ValentinSamir <<DateTime(2014-04-11T01:35:09+0200)>>
diff --git a/compte_rendus/2014_05_08.md b/compte_rendus/2014_05_08.md
new file mode 100644
index 0000000000000000000000000000000000000000..f7cbdbf9eea4d07a6c6940512b1cc2bacadc7059
--- /dev/null
+++ b/compte_rendus/2014_05_08.md
@@ -0,0 +1,167 @@
+# Internounous
+
+* Date : Jeudi 8 mai 2014
+* Lieu : Salle de conférence du Pavillon de Jardins
+* Début : 19h13
+* Fin : 21h14
+
+## Présents
+
+* Adam Heriban
+* Daniel Stan
+* Pauline Pommeret
+* Pierre-Elliott Bécue
+* Vincent Le Gallic (arrivée à 19h33)
+
+## Ordre du jour
+
+### Nouveau RTC
+
+En l'absence de Valentin Samir qui semble devoir faire face à d'autres
+obligations, Daniel Stan s'est porté volontaire
+pour assurer le rôle de RTC. Son initiative a été approuvée par le CT, et c'est
+désormais officiel. Félicitations Daniel !
+
+La question de la récupération des clefs de Valentin (clef 0B et coffre en
+particulier) se pose. Daniel va essayer de le
+contacter par divers moyens afin d'en discuter avec lui.
+
+### CransClefs
+
+Il faut vraiment que les MA mettent à jour VieCrans/CransClefs, elle n'est
+manifestement pas à jour, et cela devient problématique.
+Il faut rappeler au trésorier actuel que c'est de son ressort et qu'il doit
+veiller à ce que les détenteurs des clefs soient
+identifiés, quitte à ce que des cautions soient encaissées.
+
+Il est demandé à Vincent Guiraud de vérifier la présence de clefs 2B dans le
+coffre. La réponse est non (il n'y a pas de clefs).
+
+Il faudra penser, pour les années à venir, à dire aux personnes partant en
+stage de le dire sur la page VieCrans/CransVacances
+et à rendre leurs clefs avant de partir.
+
+Une clef du disjoncteur du 0M nous a été confiée par le CROUS et est
+actuellement au 2B, faute d'avoir
+pu fournir une clef 0B à Jordan Delorme. Cela commence sérieusement à être
+problématique. Il faut demander au CA
+de voter un budget pour réaliser la copie de 2 jeux de clefs 0B.
+
+### Blocage du /64 wifi sur Wikipedia
+
+On a découvert le 4 mai qu'un ou des adhérents auraient poussé des admins de
+Wikipédia à bloquer le /64 wifi de manière à ce que
+les adhérents du Crans ne puissent ni créer de compte ni éditer de page.
+
+L'administrateur de wikipedia ne souhaite pas lever le blocage tant qu'il n'est
+pas en mesure de différencier 2 utilisateurs venant
+de chez nous, et par là même de bloquer uniquement celui qu'il considère comme
+vandale. En effet, le fonctionnement de l'IPv6
+au crans laisse le choix à la machine d'un suffixe aléatoire (extension de vie
+privée) dans le même /64. Nous sommes donc les seuls
+à connaître la correspondance entre une IPv6 et une machine du réseau (pour
+comptage d'upload), et ceci de manière volontaire
+(il s'agit d'un des buts du système d'extension de vie privée).
+
+Que faire ?
+D'un côté, on peut se soucier des conséquences pour les autres adhérents :
+
+* Ne rien faire
+* Bloquer la plage IPv6 de Wikipedia pour forcer l'IPv4 (comme pour google), la
+ plage IPv4 n'est pas bloquée et ne risque pas de l'être (chaque adhérent
+ étant clairement identifiable)
+* Implémenter un routage plus fin de l'IPv6
+
+La deuxième solution pose des problèmes d'altération du réseau. En l'état
+actuel, nous n'avons pas de raison valable pour
+suivre la démarche de Wikipedia dans la violation de la neutralité du réseau.
+De plus, le blocage actuel est peu sévère et les
+rares adhérents impactés ont des alternatives pour l'accès à Wikipedia, comme
+la désactivation de l'IPv6 (envoyer un mail ? message
+sur autostatus ?)
+
+La dernière solution (se référer à [[CransTechnique/PlanAdressage#IPv6]]) est
+de toute façon un projet de longue date sur lequel il faut
+se pencher. L'idée est d'allouer à chaque machine un /64 distinct. Il faut
+regarder de la doc du côté de DHCPv6 et de délégation
+et implémenter cela en parallèle de la solution actuelle.
+
+Du côté de l'adhérent accusé pour wikipedia, nous n'avons pas constaté d'abus
+ni de nuisance sur le réseau que nous pouvons lui imputer.
+
+On décide de ne rien faire pour le moment et d'analyser la solution d'adressage
+v6. On avisera en temps utile. Le CA tient à en
+discuter lors de sa prochaine réunion pour l'aspect administratif de ce
+problème. Une tentative de contact a été prise par le CA,
+et s'est pour l'instant avérée infructueuse.
+
+### Comptage upload et avertissements
+
+Le CA souhaiterait que les mails d'avertissement pour upload à 300Mo soient
+moins agressifs et plus pédagogues.
+De plus 300Mo semble une limite très facilement atteignable de nos jours avec
+les technologies actuellement
+présentes sur Internet.
+
+Pierre-Elliott souhaite conserver cette limite basse afin de laisser aux
+adhérents le temps de réagir lors de la réception
+d'une alerte. Une limite plus haute, en cas d'upload rapide, ne permettrait pas
+d'avertir l'adhérent d'un comportement
+anormal de sa machine avant qu'il ne soit effectivement déconnecté.
+
+Cependant, plusieurs adhérents ont exprimé leur volonté de ne plus recevoir ce
+mail d'alerte.
+
+Raphaël Bonaque (irc) est volontaire pour rajouter un champs sur
+l'intranet (lié à ldap ? pg ?) pour choisir à partir de quel seuil
+un adhérent souhaite recevoir son mail d'avertissement pour upload. Cela
+demande peu de modifications dans notre système
+de comptage d'upload et permettrait aux adhérents ne plus recevoir ce mail ou
+de configurer à quel moment ils souhaitent
+le recevoir.
+
+### Impression
+
+Le devis d'Open concernant leur imprimante Xerox nous a permis de soulever un
+problème important : l'imprimante a sa sortie sur
+la droite, tandis que la notre sort à gauche. Ça demanderait donc un
+réaménagement du 4J, à voir avec des mesures et
+éventuellement donner une date à Open pour qu'ils passent voir le local.
+
+Pas de trace de compatibilité Linux sur la Ricoh proposée par AMP.
+
+### DSI-Crans
+
+Pierre-Elliott a créé une ML d'alerte utilisable par la DSI afin d'éviter de
+spammer tous ses membres à la moindre alerte nous concernant
+sur dsi-crans. root@ est abonné directement.
+
+Préparation d'une future réunion ? Potentiellement à l'OdJ
+
+* Autorisation d'un deuxième routeur crans dans la zone zrt (nouveau komaz)
+* Demande d'un petit /24 pour des tests nat64 ?
+* Tout ce que vous estimerez pertinent (demander au CA, notamment pour Saclay)
+
+### Projets en cours
+
+Pierre-Elliott a fait un peu de ménage dans le tracker, il y a des projets pour
+les apprentis, avis aux personnes motivées !
+
+Pauline souhaite que les tâches réalisables par un apprenti (en
+autonomie) soient davantage mises en valeurs.
+
+Il faut faire quelque chose de toutes ces tâches (renouvellement des
+certificats, KSK, etc) qui produisent beaucoup de bruit.
+Pour les certificats, on a ce qu'il faut automatiquement avec check_cert,
+Pierre-Elliott va essayer de faire un programme du même genre
+pour DNSSEC.
+
+### Questions diverses
+
+#### Binding Ldap
+
+Pierre-Elliott s'est lancé dans la réécriture de certains scripts de gestion
+s'appuyant sur ldap_crans pour les porter sur lc_ldap. Il
+a également commencé une implémentation de generate basée sur rabbitmq.
+Pour l'instant, il s'est penché sur dhcp, ça marche, il faut continuer. Il
+attend des reviews.
diff --git a/compte_rendus/2014_05_22.md b/compte_rendus/2014_05_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..0156d904d2901ec2add6255ba128360b16bdd188
--- /dev/null
+++ b/compte_rendus/2014_05_22.md
@@ -0,0 +1,93 @@
+# Réunion inter-nounous
+
+* Date : Jeudi 22 mai 2014
+* Lieu : Pavillon des Jardins
+* Début : 19h20
+* Fin : 20h41
+
+## Présents
+
+* Jordan Delorme
+* Lucas Serrano
+* Daniel Stan
+* Pierre-Elliott Bécue
+
+## Ordre du jour
+
+### Imprimante
+
+On choisit la Xerox, au vu de la compatibilité douteuse de la Ricoh. Un
+réaménagement du 4J s'avère nécessaire, mais peu compliqué à gérer : on
+s'oriente vers
+un agrandissement de la sortie ou un changement (sur l'autre côté du mur), dans
+les deux cas en rebouchant l'ancien.
+
+On pense faire une expédition, après accord CA, dans un magasin de construction
+pour acheter des plaques de plâtres et des parpaings (pour l'onduleur).
+
+Le binding de la nouvelle imprimante (CUPS+lp) est déjà (presque) prêt, on se
+servirai de celui de l'ancienne imprimante, en adaptant les options proprio
+d'agrafage et cie.
+
+### QRCode (Gala)
+
+Pierre-Elliott a discuté avec l'équipe gala, pour se mettre d'accord sur les
+deadlines et les besoins du gala.
+Actuellement le prestataire privé coûte environ 1200€, pour la mise en place du
+site et la taxe sur les billets.
+
+Le Cr@ns aimerait leur fournir ce service à la place. L'idée serait d'acheter
+les scanettes de QRCode et de voir
+avec leur banque pour la mise en place du service de paiement en ligne.
+
+Pierre-Elliott est motivé pour s'occuper de ce projet en collaboration avec le
+Gala. Daniel l'aidera.
+
+Cahier des charges :
+
+* Site en django de gestion de QRCodes ;
+ * Formulaire pour acheter un/des billets avec paiement en ligne et
+ validation de transaction ;
+ * Envoi de mail en cas de succès avec lien pour récupérer le billet ;
+ * Lien générant des pdf et les stockant (pour téléchargement futur) ;
+ * Administration : validation manuelle de ticket en cas d'échec après renvoi
+ post-paiement ; interface de suppression de ticket nominatif ; édition et
+ suppression de ticket pour souche en masse ;
+* Appli python qui après scan de code barre/QRCode renvoie sur le site avec une
+ bonne url pour valider le billet (id + hash)
+
+### Avancement du WiFi
+
+Le Pavillon des Jardins est presque entièrement câblé. Il reste le 4^ème^ étage.
+
+NB (post CR) : le dernier étage a été câblé deux jours plus tard.
+
+### Rabbit MQ
+
+Le principe choisi est le suivant : le(s) binding(s) notifient le serveur
+RabbitMQ d'une modification ldap avec une "modlist" (ou assimilé) en argument.
+Un script démon sur RabbitMQ lit cette file d'attente et dispatche (en fonction
+du modlist) la modification aux files d'attente des services concernés.
+
+### Binding Ldap pour les adhésions glissantes
+
+Ça marche, mais ça s'intègre mal à gest_crans … On travaille encore dessus pour
+arriver à selectionner des adhérents à jour de cotisation à partir
+de ses factures.
+
+## Bilan todolist
+
+Pour résumer les trucs à faire prochainement :
+
+Pas prioritaire :
+
+* Adhésions glissantes (fin juillet, début août)
+* Messaging via Rabbit MQ (pas tout de suite)
+* câbleuse (dépendant de RabbitMQ)
+
+Urgents :
+
+* lc_ldap : locks sur un objet (actuellement, locks uniquement sur une valeur
+ donnée d'un type donné)
+* Imprimante
+* Site du Gala
diff --git a/compte_rendus/2014_06_05.md b/compte_rendus/2014_06_05.md
new file mode 100644
index 0000000000000000000000000000000000000000..b41063a7a721a898f56d9a6b7e574022052f9866
--- /dev/null
+++ b/compte_rendus/2014_06_05.md
@@ -0,0 +1,89 @@
+# Réunion inter-nounous
+
+* Date : Jeudi 5 juin 2014
+* Lieu : Pavillon des Jardins
+* Début : 19h30
+* Fin : 20h38
+
+## Présents
+
+* Adam Heriban
+* Daniel Stan
+* Florian Marconi
+* Jean-Baptiste Guyon
+* Jordan Delorme (arrivé à 19h45)
+* Pierre-Elliott Bécue
+
+## Ordre du jour
+
+### Imprimante
+
+On s'oriente sur le week-end du 5-6 juillet pour installer la nouvelle
+imprimante et faire les travaux. Daniel présente une nouvelle
+organisation possible du 4J et les éléments à acheter. Pour le problème de la
+fixation de l'imprimante (pour éviter de pouvoir
+rentrer dans la pièce en la poussant), on pense utiliser une barre en metal au
+niveau du sol.
+
+On demande à la menuiz' si ils disposent d'une disqueuse adaptée, sinon, on
+s'oriente vers la location. Ils sont d'accord,
+et sont même prêts à nous aider, en revanche on devra acheter un disque Ã
+plâtre.
+
+### Réseau au point rencontre
+
+Le BDE voudrait du filaire au point rencontre. De préférence, ils voudraient le
+vlan adhérent, afin de disposer aussi
+des services TV. Pour l'instant, la demande de travaux a été effectuée pour le
+vlan 10, on avisera pour leur
+fournir les services supplémentaires quand il sera effectivement brassé.
+
+### CNS Conseil
+
+Deux représentants de CNS Conseil aimeraient bien savoir si le collège
+technique est d'accord pour ouvrir partiellement le réseau wifi pour le
+CRA (congrès régional d'automne).
+A priori 200~300 personnes. Ils souhaitent le soutien du Crans pour fournir un
+réseau WiFi.
+Date : novembre.
+
+Amphi utilisés :
+
+* Tocqueville
+* Curie
+* Fonteneau
+* Condorcet
+* Villon
+
+Au niveau matériel, nous avons suffisamment de bornes supplémentaires. En
+revanche, elles ne sont pas installées dans le d'Alembert.
+C'est l'occasion d'en remettre, car les bornes du d'Alembert n'ont pas été
+changées (anciens modèles).
+De plus, on commence à avoir des demandes d'élèves du dpt EEA.
+
+Il faut cependant l'accord de la DSI pour diffuser le réseau, donc il faudra
+préciser dans le dossier de CNS Conseil que la couverture WiFi sera réalisée
+avec l'accord de la DSI.
+
+### QRCode (Gala)
+
+Il faut faire le site. Deadline : 15 juillet. Histoire que le staff Gala puisse
+le tester avant les vacances.
+
+### Séminaires 14-15
+
+Remarques sur les séminaires de l'an passé : peu de motivation à l'organisation
+des séminaires. Il faut que les nounous motivent davantage leurs apprentis. On
+met à jour en live la liste des apprentis avec leur encadrants. Avis aux
+nounous qui se sont vues affectées des apprentis !
+
+Il faut que les gens qui n'ont pas encore uploadé leur slides pensent à le
+faire ASAP.
+Il faudrait que les nounous fassent/fignolent leurs séminaires
+classés "nounou", qu'elles puissent ainsi à partir de la rentrée se concentrer
+sur l'encadrement de
+séminaires apprentis.
+
+Pauline n'est pas là , mais voici un début de programme de séminaires pour
+l'année prochaine :
+[[CransTechnique/CransApprentis/SeminairesTechniques/2013-2014#Contenu_des_s.2BAOk-minaires|La liste des séminaires (faits ou à faire)]]
diff --git a/compte_rendus/2014_06_19.md b/compte_rendus/2014_06_19.md
new file mode 100644
index 0000000000000000000000000000000000000000..5718e32b1305cbddff7e9ac251347fcda0d9832d
--- /dev/null
+++ b/compte_rendus/2014_06_19.md
@@ -0,0 +1,118 @@
+# Réunion inter-nounous
+
+* Date : Jeudi 19 juin 2014
+* Lieu : Pavillon des Jardins
+* Début : 19h52
+* Fin : 21h10
+
+## Présents
+
+* Adam Heriban
+* Daniel Stan
+* Nicolas Dandrimont (arrivé à 20h10)
+* Pierre-Elliott Bécue (arrivé à 20h20)
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Internet pour admissibles
+
+Pour le PR, le vlan n'est toujours pas présent sur la prise. On va mettre un
+switch dlink à disposition du BDE. La DSI a dit s'occuper du vlan demain matin,
+sinon on leur fournira un NAT via une machine sur le vlan3 (qui lui est
+présent).
+
+Il faudra qu'on discute de ça à la réunion DSI, qu'on ait un fonctionnement
+plus efficace à l'avenir.
+
+On se propose d'enregistrer des machines WiFi temporaires pour les admissibles,
+à l'aide de la fonctionnalité de MAC <automatique> qui remplit automatiquement
+la MAC d'une machine à la première connexion avec le
+bon '''login'''/mdp. À voir sur quel compte on enregistre ça.
+On propose le compte du BDE (il faudrait leur en parler (en cas de déco, c'est
+le BDE qui prend)) ou un compte dédié pour ça.
+
+Daniel a commencé un script pour inscrire à la volée N machines (avec N grand),
+on imprimerait alors plein de logins/mdp pour les filer aux admissibles.
+Toutes les semaines, on supprime les machines et on recommence.
+
+### Comptage d'upload
+
+PEB a commencé à configurer pmacct sur le nouveau routeur, en stockant dans une
+base
+pgsql locale.
+
+* Le schéma est un peu modifié, donc les scripts de déco/stats/analyse doivent
+ être réécrits.
+* On loggue tout ce qui passe sur l'interface crans.
+ * On a les MACs '''et''' les IPs.
+ * On compte pour la déconnexion pour upload le traffic qui sort du /16 de
+ l'ENS.
+* Comme on a l'info mac '''et''' IP, on peut émuler le filtrage mac-ip.
+* Comme on a l'info mac, plus besoin de correspondance EUI64<->Extension de vie
+ privée en IPv6.
+
+On va probablement mettre deux trois filtres pcap pour alléger la base du
+traffic interne
+(wifi <->filaire, ça passe par komaz).
+
+Problème : les cas "bâtards" de machines ayant plusieurs entrées dans la base
+ldap
+avec la même adresse MAC.
+
+On envisage d'utiliser ce système pour conserver l'historique du parefeu,
+plutôt que d'utiliser
+le target LOG d'iptables. Cela diminuerait la taille occupée par les logs du
+parefeu, car on
+aurait des infos agrégées sur 1 min.
+
+### Logs centralisés
+
+Quand l'étape précédente sera terminée, on aura un peu plus de place sur thot.
+PEB envisage
+d'installer une base elasticsearch avec logstash pour stocker les logs
+centralisés.
+
+On ne sait pas encore combien de place ça va prendre. ''A priori'', plus de
+place (x2) que des logs
+textes.
+
+### MÃ j du Firewall
+
+Un peu plus de paramètres dans config.py et une fonction pour mettre à jour le
+test
+mac-ip incrémentalement.
+
+Il faudrait recoder un parefeu IPv6, pour régler ces problèmes de mà j, et
+éventuellement en
+profiter pour en faire un parefeu IPv4-v6 unique.
+
+### Civet de lapin
+
+Sur toutes les machines, un démon : trigger.py qui importe (depuis config) les
+services gérés
+par la machine courante.
+
+Scénario typique :
+
+* Quand le binding ldap modifie un objet, il envoie un message avec une clé de
+ routage « trigger.event » et en donnée le dn, les ldiff avant et après
+ modification.
+* Civet reçoit le message, il compare les deux ldiff et dispatche sur un
+ échangeur dédié à un service donné (clé de routage spécifique).
+
+Si plusieurs serveurs implantent le même service, ils possèdent chacun leur
+file d'attente
+qui s'associe à l'échangeur.
+
+### Réunion DSI
+
+Vendredi 27 juin à 16h.
+
+### Babar
+
+Il atteint ses limites. PE regarde pour augmenter l'espacement des sauvegardes
+des
+serveurs ayant des services similaires. On se renseigne en parallèle des
+solutions
+alternatives (NAS, solution proprio… ?).
diff --git a/compte_rendus/2014_07_03.md b/compte_rendus/2014_07_03.md
new file mode 100644
index 0000000000000000000000000000000000000000..1d0b4826903fe8a0c94e6e560f02101ff19b2e8c
--- /dev/null
+++ b/compte_rendus/2014_07_03.md
@@ -0,0 +1,210 @@
+# Réunion inter-nounous
+
+* Date : Jeudi 3 juillet 2014
+* Lieu : Pavillon des Jardins
+* Début : 18h47
+* Fin : 20h30
+
+## Présents
+
+* Anne Cazalet
+* Daniel Stan
+* Nicolas Dandrimont
+* Olivier Iffrig
+* Stéphane Glondu
+* Vincent Le Gallic
+* Pierre-Elliott Bécue
+* Pauline Pommeret
+* Kévin Moisy-Mabille
+
+## Ordre du jour
+
+### Comptage d'upload
+
+Pierre-Elliott a refondu le comptage de l'upload à base de pmacct.
+C'est maintenant envoyé au nouveau routeur{{{odlyd^Wkomaz2}}} (pas encore en
+prod au niveau routage).
+
+Niveau consommation de ressources, le load average est passé de 2 à 0.5.
+Maintenant qu'on a atteint
+la durée de rotate (5 jours), la base fait 90Go.
+
+* {{{deconnexion.py}}} (= punir les méchants) a été adapté, il s'exécute ~aussi
+ rapidement
+* {{{analyse.py}}} (= voir combien les méchants ont uploadé et vers où) a été
+ recodé, on peut
+
+maintenant demander l'upload par '''adhérent'''.
+
+{{{#!wiki tip
+analyse.py est lancé automatiquement à chaque fois que quelqu'un se fait
+déconnecter. Les résultats atterrisent
+dans /usr/scripts/var/analyse/AAAA_MM_JJ_HH_MM_SS_(aid|cid)_<aid ou cid>.txt
+}}}
+
+### Réunion avec la DSI
+
+Lundi dernier, Pierre-Elliott, Jordan et Daniel ont rencontré la DSI en les
+personnes de Stuart !McLellan,
+Jocelyn Viallon et Vivien Frenot.
+
+#### Saclay
+
+On leur a parlé de là où on en est pour le fameux "dossier Saclay", qui est en
+cours de rédaction, de ce qu'on est prêt à faire.
+
+Nous, on préfèrerais continuer à collaborer avec eux, sachant qu'on est prêt Ã
+faire autrement si besoin.
+Ils sont aussi d'avis de continuer à travailler main dans la main, parce qu'ils
+pensent que l'école se doit de
+fournir l'accès Internet à ses étudiants, mais préfèrent que ce ne soit pas Ã
+eux de s'en occuper.
+Stuart pense qu'on est plus efficace et qu'on coûte moins cher qu'un
+prestataire privé.
+
+De notre côté, on aimerait que l'école supporte notre projet sur la scène de
+Saclay.
+Il '''''faut''''' terminer le dossier, qu'il soit tout beau tout propre et
+pensé en collaboration avec les autres
+assos (notamment Aurore). Pierre-Elliott et Ariane ont bien avancé, mais il y a
+encore beaucoup de travail.
+
+Anne Cazalet est prête à nous faire un/des devis pour une grosse quantité de
+matériel,
+pour qu'on puisse dire dans le dossier "regardez, on sait combien ça nous
+coûtera".
+On la recontactera dès qu'on aura une idée des quantités (une fois qu'on aura
+fait notre inventaire).
+
+Stuart a parlé de nous au directeur de la DSI de la FCS (Fédération de
+Coopération Scientifique)
+François de Castelbajac, destiné à piloter les projets des DSI des différentes
+écoles/labo du projet Saclay.
+
+Dossier à envoyer d'ici la fin du week-end.
+
+#### Comptage d'upload et débit en journée
+
+Un point a été fait sur les limitations.
+
+Pour le débit en journée, ils ont peur de plomber les visoconférences dont les
+départements ont besoin.
+On utilise actuellement 100Mbit/s sur le 1Gb/s que l'école a.
+
+En journée, on a négocié 150Mbit/s, pour voir ce que ça donne.
+En soirée, on reste à 500 (ça ne sature pas).
+
+Pour la limitation d'upload, ce qui les gêne surtout, c'est l'image de l'école
+vis à vis des téléchargement illicites,
+surtout quand les mails viennent du CERT de Renater.
+Ils sont contents parce qu'ils reçoivent moins de mails d'ayant droits, Nicolas
+pense que Renater
+les {{{> /dev/null}}}.
+
+Du coup, on passe la limite d'upload à 8Gio/24h, histoire que ce soit quand
+même pas complètement open,
+notamment à cause des gens qui uploadent sans trop le savoir (virus, cacaoweb
+for the win).
+Point de vue implémentation, y'a rien à faire de plus, Pierre-Elliott l'a déjÃ
+modifié dans le pare-feu.
+
+La DSI est intéressée par nos solutions de qos (tc sous linux) pour
+leurs "problèmes" de visioconf.
+
+#### Miroir Debian / IPv6
+
+L'ENS est toujours intéressée par l'idée d'un miroir Debian commun.
+
+En revanche, l'IPv6 est quasiment obligatoire pour apparaître dans cette liste.
+Pour l'instant, ça coince au niveau
+du matériel du réseau de collecte (Rubis). De notre côté, on propose d'acheter
+une machine plus
+puissante et/ou laisser tomber le RAID 5 logiciel actuellement en place.
+
+#### Ports
+
+Sur le firewall, on bloque par défaut les ports des machines des adhérents en
+entrée.
+La DSI ne le savait pas, mais trouve que c'est une bonne idée (on protège des
+adhérents qui ont l'habitude d'avoir une box entre eux et le monde).
+
+Ils ne voient aucun inconvénient à ce qu'on ouvre des ports quand ça nous
+chante, même sans les prévenir, mais ils apprécient beaucoup qu'on les
+prévienne.
+Donc on va continuer à le faire, parce que ça nous coûte pas grand chose, que
+c'est toujours cool de faire plaisir à la DSI pour pas cher, et que ça
+responsabilise un peu l'ouverture d'un port.
+
+### Filtrage mails
+
+C'est un projet à plus long terme pour le filtrage des spams. On réinstallerait
+amavis sur tous les MX
+sans utiliser les fonctions de filtrage virus. On activerait le filtrage de
+spam assassin. L'idée serait
+ensuite d'utiliser les fonctions de quarantaine pour n'envoyer qu'un seul mail
+par jours pour tous
+les mails étiquettés "spam" en attente de modération.
+
+Voir du côté de Maia Mailguard. Avis à apprenti intéressé, contacter PEB.
+
+### Disque de nols
+
+Un disque de nols (notre baie de disques) de 600Go nous a lâché.
+Il y avait deux disques de remplacement qui attendaient de prendre sa place,
+donc pour l'instant, pas d'interruption de service.
+
+Anne nous a envoyé un numéro de téléphone à contacter pour faire valoir la
+garantie.
+
+Il nous manque certains numéros de
+série (cf [[CatégorieCrans/LesServeurs|ci]]), on va voir avec Anne pour les
+récupérer.
+Il est possible qu'on ait besoin des numéros de séries des '''contrôleurs'''.
+
+### Migration des homes
+
+En été, c'est là que les adhérents se servent le moins de leurs home. Les
+migrer nécessite une interruption de service.
+
+Plus de place, plus
+compartimenté ([[CransTechnique/PanthéonServeurs/ServeurBabar|babar]] nous
+remercie),
+ce sera cool, mais la copie de tout ça va prendre plusieurs heures.
+
+Il va falloir qu'on fasse des choses sioux parce
+que {{{/home/a/ablabla}}} risque d'être le nouveau chemin
+pour {{{/home/ablabla}}}.
+
+Pas encore de date fixée, mais avant la rentrée.
+
+### Machines virtuelles pour les clubs/l'événementiel
+
+On a des demandes (pot vieux, Gala) pour une machine virtuelle. On peut déjÃ
+allouer de la place sur l'ancien
+stockage.
+
+Si ce crash-test se passe bien, on considérera toute demande de virtualisation
+de la part d'autres clubs.
+Penser à rappeler que :
+
+* on se garde le droit de refuser une vm pour cause d'utilisation de ressources
+ ou d'usage illicite
+* les nounous restent virtuellement root sur la machine hébergée, l'accès sans
+ accord leur restant moralement et légalement interdit
+
+Il faut avancer le projet Gala (mi-juillet).
+
+### Imprimante
+
+## Discussion avec Anne sur ce que proposerait HP en termes de contrats de
+maintenance, et de
+« l'engagement » de XeroX.
+
+Laser Jet Enterprise Flow M800 series
+
+Extensions de garantie:
+
+* 4h
+* Le lendemain
+
+## Il est 20h. Paris s'éveille (or something). Sergio nous attend il fait faim.
diff --git a/compte_rendus/2014_09_11.md b/compte_rendus/2014_09_11.md
new file mode 100644
index 0000000000000000000000000000000000000000..576cc2ce59ff94aa7101900d4a04b8ba5bd4fda2
--- /dev/null
+++ b/compte_rendus/2014_09_11.md
@@ -0,0 +1,172 @@
+# Réunion du collège technique
+
+* Date : Jeudi 11 septembre
+* Lieu : Salle de conférence du Pavillon des Jardins
+* Début : 19h00
+* Fin : 21h01
+
+## Présents
+
+* Clément Ringeade
+* Daniel Stan
+* Jordan Delorme
+* William Babonnaud
+* Myriam Begel
+* Glen Mével
+* Adam Heriban
+* Colisson Léo (alias !TobiasBora)
+* Pierre-Elliott Bécue
+* Raphaël-David Lasseri
+* Germain Haessig
+* Florian Marconi
+
+## Ordre du jour
+
+### Migration routeur et homes
+
+On a migré le routeur et les homes vers une nouvelle grappe de disques (des
+disques de 2To au lieu des 600Go). On a ensuite permuté les disques pour mettre
+les 2To dans la baie encore garantie ({{{nols}}}). Malheureusement, cela a
+entraîné une perte de données (problèmes de disques ayant le même identifiant,
+probablement), et les disques arrivants ont été squeezés. Il a fallu
+recommencer la copie de données, mais rien n'a été perdu.
+
+Il faut tester le système de secours (quand le réseau du crans tombe, il faut
+faire en sorte que le serveur titanic ouvre son tunnel vpn vers ovh pour
+assurer une connectivité entre le serveur et le réseau du Crans). Glen est
+volontaire pour jouer avec le vpn (encadré par Daniel.)
+
+Quota : à refaire. Pour l'instant, tout le monde peut utiliser autant d'espace
+qu'il le veut. Il devrait être limité à 10Go. Léo Colisson se propose pour le
+faire.
+
+### Nouvelle imprimante
+
+Elle est au 4J et elle marche !
+Toutefois les impressions WEI l'ont laissé exsangue, presque à court de toner
+et de tambour. Le contrat SPS a été signé mercredi. Pas de nouvelle pour
+l'instant.
+On espère recevoir un toner pour mardi.
+
+Pour l'instant, le binding avec l'intranet n'est pas prêt (mais presque). Le
+soucis, c'est que pour l'instant, il semble falloir installer le driver sur le
+serveur qui
+lance l'impression (même en partage d'imprimante cups). Soit on essaie de
+trouver un paquet hplip venant de Jessie, soit on installe la lib à la main sur
+o2 (serveur de l'intranet2) ce qui nécessite de finir l'application
+d'impression sur l'intranet2. On verra ça ce week-end.
+
+Pour l'instant, on ne comprend pas le snmp de cette imprimante. Vincent G. a
+commencé à parser la page d'administration pour récupérer les infos
+pertinentes. On écrira un plugin munin à partir de ça.
+
+Il faut également réécrire le script de notification de fin d'impression.
+William est volontaire.
+
+Il nous manque une fonctionnalité de couverture (piochée depuis un autre
+bac) pour la Sauce. Le seul driver supportant cette fonction (Ã notre
+connaissance) est dispo
+sur Windows® (sic), et en recto simple. On peut soit créer une VM sous
+Windows®, soit on leur file une vieille machine sous Windows®…
+
+### Serveur de backup
+
+Anne propose un devis http://perso.crans.org/dstan/anne de 4020 € TTC, Pierre
+Elliott regarde pour un serveur acheté ailleurs en sachant que l'avantage
+principal d'HP serait le care pack garantissant l'intervention ou le
+remplacement dans les 24h.
+Il faudra demander au CA de voter un budget pour un "simple" ordi à monter si
+ça ne suffit pas on avisera pour une solution pro.
+
+### Ft's powerup
+
+Devis de ~1100 pour un deuxième Xeon 6cœur + 8Go de RAM. A priori, on les
+prendra.
+
+### OwnCloud
+
+Raphaël fait une démo à partir de la machine virtuelle qu'il vient d'installer.
+
+Où stocker les données d'un utilisateur :
+
+* Un espace à part (sur la vm)
+* Le home de l'adhérent
+* Un sous-dossier du home de l'adhérent
+
+Vu les contraintes (dossier qui doit être accessible en écriture par un groupe
+spécifique), on s'oriente vers le partage d'un sous-dossier de l'espace perso
+d'un adhérent.
+
+-- Il y a un petit hack qui consiste à monter le home de l'adhérent en tant
+ que "Stockage externe" dans owncloud pour s'affranchir des problèmes de
+ droit (www-data qui ne peut pas écrire en tant que l'adhérent), c'est de la
+ théorie, je ne sais pas si ça marche en pratique
+
+### Sanction upload
+
+La limitation pour upload ne reconnecte plus automatiquement l'adhérent
+après 24h : désormais, il faut cliquer sur un lien qui renvoie vers une
+application de l'intranet2, pour confirmer que les programmes consommateurs en
+upload ont été réglés correctement.
+Tout ceci dans un but de responsabilisation. En cas de clic après les 24h, la
+personne est reconnectée immédiatement. Pour l'instant, peu de clic et aucune
+plainte, l'upload des personnes sanctionnées n'a pas l'air de leur manquer.
+
+L'appli est modulaire et tout le monde est invité à coder d'autres
+modules (chambres invalides etc.)
+
+### Bilan (technique) de la rentrée
+
+Adhésions glissantes : ça s'est bien passé (globalement). Il manque des
+fonctions pour afficher les factures en détail.
+Il faut pouvoir enregistrer une réadhésion à partir de la date de fin
+d'adhésion.
+
+Enregistrement des mac : ça marche plutôt bien, modulo des problèmes liés à des
+collisions de mid (sic) vive les locks !
+
+Ticketteuse : Sur {{{oie}}} à la Kfet, marche bien (modulo présence de
+rouleau…) elle permet d'imprimer des tickets avec les mots de passes des
+machines wifi de l'adhérent, mais aussi de générer et imprimer un mot de passe
+pour le compte crans de l'adhérent.
+
+* Il faut defucker le script de mails de bienvenue.
+* Faire un mail-all de réadhésion et imaginer une solution plus pérenne Ã
+ partir de l'année prochaine.
+* Générer des liens pour les réponses aux mails de déménagements non déclarés
+
+### Pont(s) WiFi
+
+On tire un câble du 0B au 6B pour réalimenter la borne WiFi du faux plafond.
+Son câble étant utilisé par le pont WiFi.
+Si cela n'a pas lieu, on rebranchera l'ancienne borne du 6B pour les adhérents
+du dernier étage (le WiFi a été reporté
+comme instable à cet étage, la borne étant éteinte).
+Il faut aussi finaliser la configuration du pont WiFi, avec un truc propre.
+
+Pour Arpej/Volti, il faut s'occuper de remettre la borne en service en haut du
+d'Alembert, contacter la DSI et STL (pour l'accès).
+
+### Install Party Campus
+
+PEB propose une Install Party (coté campus) le 20 Septembre.
+
+### Prochains séminaires/ateliers
+
+Mardi prochain, on fera un séminaire pour les câbleurs. Remplissons le planning
+des prochains jours
+https://wiki.crans.org/CransTechnique/CransApprentis/SeminairesTechniques/2014-2015
+
+### Questions diverses
+
+#### SageMath
+
+C'est une bibliothèque (☺) Python orientée calcul formel. Il faut réfléchir,
+toutefois c'est assez gourmand en ressources.
+À tester sur une vm.
+
+#### Switch Krobot
+
+Germain demande s'il est possible de récupérer un switch pour le Krobot, le
+leur fait trop de bruit.
+Il s'occupe de faire valoir les garanties de ces switchs.
diff --git a/compte_rendus/2014_09_25.md b/compte_rendus/2014_09_25.md
new file mode 100644
index 0000000000000000000000000000000000000000..3652aea79c52c37d478a61d17b9e0c66e97f75de
--- /dev/null
+++ b/compte_rendus/2014_09_25.md
@@ -0,0 +1,31 @@
+# Réunion du collège technique
+
+* Date : Jeudi 25 septembre
+* Lieu : Salle de conférence du Pavillon des Jardins
+* Début : 19h00
+* Fin :
+
+## Présents
+
+## Ordre du jour
+
+### Perte de perf sur ft
+
+### Service d'impression
+
+## Des rendus qui marchent bof, des blocages idiots
+## pleins de solutions
+
+### Serveur de backup
+
+### OwnCloud
+
+### WiFi
+
+## On s'est remotivé pour poser des bornes, alors autant continuer !
+
+### Prochains séminaires/ateliers
+
+## Quid de mardi prochain ?
+
+### Questions diverses
diff --git a/compte_rendus/2014_10_09.md b/compte_rendus/2014_10_09.md
new file mode 100644
index 0000000000000000000000000000000000000000..75abec389edb9d2de9836664d95956e8cd884751
--- /dev/null
+++ b/compte_rendus/2014_10_09.md
@@ -0,0 +1,112 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 9 octobre 2014
+* Lieu : Pavillon Des Jardins
+* Début : 19h15
+* Fin : 20h30
+
+## Présents
+
+* Nicolas Dandrimont
+* Thomas Blanc
+* William Babonnaud
+* Emmanuel Arrighi
+* Gabriel Detraz
+* Myriam Begel
+* Julien Christophe
+* Raphael Lasseri
+* Pierre Elliot Bécue
+* Daniel Stan
+* Jordan Delorme (arrivée 19h35)
+
+## Ordre du jour
+
+### Soirée Crans
+
+Côté anim, Raphaël David proposait d'utiliser les spare bornes WiFi, surtout en
+utilisant les leds. Le but
+serait de coder un petit jeu qui utiliserait les leds. Avis aux volontaires.
+Il y a aussi un jungle speed fait maison (par Aurore).
+
+De son côté, le krobot fait une démo : le robot arrive à lancer des balles.
+
+### Câblage WiFi au M
+
+Câblage ce samedi aprem', rdv à la fin du petit dej' à la Kfet (vers 14h30).
+
+### Contact avec les adhérents
+
+Selon Thomas, nounou@ serait assimilé à une ML privée, ainsi que ca@ (pour le
+bureau). De notre point de vue,
+on peut envisager de renommer nounou pour affirmer son caractère public, et
+rediriger le mail nounou@ vers
+la ML roots@ (apprentis et nounous seuls sont abonnés).
+Nicolas soulève l'avantage de l'entraide sur une ML publique.
+Vu le bruit sur roots@, on laisse en l'état pour le moment, mais on rappelle
+aux modérateurs de ne pas laisser passer de données privées (rediriger ces
+mails sur une ML privée.)
+
+Mails de disconnect :
+
+* Le nom de la ml : on propose "avertissement" en tant qu'expéditeur des mails
+ auto (alias).
+* Le contenu du mail : il commence par les sanctions, se répète et se veut
+ agressif.
+
+Thomas veut bien réécrire cela (et apprendre à utiliser git au passage) et
+jettera un Å“il aux autres mails du dossier.
+
+### Impression
+
+On met en prod le script de notification d'impression terminée ce soir.
+
+Ce qui reste à faire :
+
+* une interface sur l'intranet 2 (Julien est partant pour faire du django)
+* il faut écrire un driver en pcl (beaucoup de plaintes au sujet de plantages
+ avec le driver hp…).
+
+### Gala
+
+Si ça vous intéresse de faire du django, feel free to join.
+
+### Renouvellement de garanties
+
+Trois devis de renouvellement (1 an chacun) pour :
+
+* fz : on prend (c'est un serveur vital)
+* babar : pas la peine (les disques durs ne sont pas compris dans la garantie)
+* fy (munin) : on prend, ça sert toujours
+
+On proposera donc les deux devis intéressants au CA.
+
+### Monitoring
+
+Rappel sur l'existence de munin.crans.org et autostatus.crans.org et le
+nettoyage à faire par les nounous.
+
+### Permutation séminaires/CA/IN
+
+Superposition: No.
+On fait un Doo^W framadate pour demander aux apprentis ce qu'ils en pensent.
+
+### Prochains séminaires
+
+Mardi prochain : séminaire Debian par Nicolas.
+
+### Questions diverses
+
+#### Pont WiFi
+
+Sous réserve que la déclaration à l'ARCEP avance, pas de problème du point de
+vue technique, un câble est présent en plus. On verra pour faire une commande
+groupée de borne. On pense commander des nanobeam M5 (qui ont l'air d'être une
+évolution des nanoM5 utilisées actuellement.)
+
+http://landashop.com/catalog/ubnt-nanobeam-nbem519-5ghz-19dbi-dual-p-3163.html
+
+#### Comptes inactifs
+
+Raphaël se lance dans la réécriture de gestion des comptes inactifs. Il propose
+un effacement des anciens comptes au bout de 3 avertissements, mensuels.
+À suivre.
diff --git a/compte_rendus/2014_10_23.md b/compte_rendus/2014_10_23.md
new file mode 100644
index 0000000000000000000000000000000000000000..bcf6ea93ef0c8f6bbf253b0f2fb9401fdcc0fd83
--- /dev/null
+++ b/compte_rendus/2014_10_23.md
@@ -0,0 +1,131 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 23 octobre 2014
+* Lieu : Pavillon Des Jardins
+* Début : 19h15
+* Fin : 20h20
+
+## Présents
+
+* Thomas Epalle
+* Raphaël-David Lasseri
+* Myriam Begel
+* Jordan Delorme
+* Daniel Stan
+* Pierre-Elliott Bécue (19:30)
+
+## Ordre du jour
+
+### Retour sur le dernier spoofeur
+
+Le spoofeur devait passer à la maison de l'étudiant lundi pour vérifier des
+traces de changement spontanées d'adresse mac. Raphaël-David
+a consulté le journal des évènements de windows, et cela confirme nos logs, il
+s'agit bien de sa machine qui a usurpé les macs d'autres
+adhérents.
+Raphaël a également installé un antivirus qui a trouvé une dizaine de virus dès
+l'installation. On n'a pas envie de perdre davantage de temps
+là dessus. Il se pose la question de savoir si on prévient les personnes
+spoofées, on demandera au CA. A priori, l'usurpation d'adresse
+MAC (et d'IP) n'induit pas nécessairement une usurpation d'identité, d'autant
+plus que nos logs confirment les faits, et l'adhérent a
+reconnu publiquement le problème (même s'il met en cause un "ami".)
+
+On décide de ne pas perdre davantage de temps sur ce problème que l'on laisse Ã
+la discrétion du CA.
+
+### Comptes inactifs
+
+Les sources ne sont pas encore prêtes.
+Pour l'instant, les logs sont parsés sur zamok et owl, et le script met à jour
+l'attribut LDAP de dernière connexion en fonction.
+Raphaël se demande si on doit poursuivre sur ce fonctionnement à base de cron.
+On poursuit ce fonctionnement en centralisant les
+logs sur thot, y compris ceux du CAS, s'ils sont exploitables facilement. En
+vrai, il faudrait surveiller la totalité des services du Cr@ns
+sauf que tous les programmes n'utilisent pas syslog.
+Will be ready soon.
+
+### Monitoring, envoi de SMS
+
+L'adaptateur HDMI-VGA est reçu : le but est de brancher une raspberry pi pour
+afficher un dash board sur l'écran en rab que l'on possède au 2B. Cet écran est
+censé s'allumer en cas d'alerte. Il faut voir la forme à donner aux
+informations qui s'affichent : un dump d'autostatus…
+
+La clé GSM n'est pas encore reçue. Fonctionnement du système de notification
+par SMS en deux étapes :
+
+* Munin (par exemple, lors d'un warning ou error) va recevoir comme instruction
+ de lancer un script (et non un mail) qui contient l'API de Free. Un SMS est
+ donc envoyé sur la ligne Free.
+* Sur un serveur (le même que Munin, par exemple) auquel est branché la clé
+ GSM, le paquet gammu-smsd se charge de gérer la carte SIM (envoi, stockage et
+ réception de SMS). Le fichier de configuration permet notamment de lancer un
+ script à la réception d'un SMS, de lire le contenu et de lancer des
+ commandes (c'est la base du fonctionnement) et de ne lire/recevoir que des
+ SMS venant de certains numéros (très important pour ne pas que tout le monde
+ puisse lancer des commandes).
+
+Il est possible d'interfacer Asterisk avec l'ensemble. Ainsi, la personne
+pourrait recevoir un message SIP s'il est connecté sur ce service, ou un SMS
+s'il ne l'est pas.
+Dans un premier temps, on peut tester ça sur vo pour voir la réactivité de
+l'ensemble, la sécurité qu'il y a… Jordan se charge d'installer ça sur vo et de
+faire une page explicative sur le Wiki.
+Pierre-Elliott demande si le forfait Free à 0 euros est viable sur le long
+terme, et si les conditions d'utilisations ont été lues. Ce n'est pas le cas,
+et comme tout fournisseur téléphonique, nous n'avons pas de visibilité à long
+terme. S'il y'a un changement dans les conditions d'utilisations, nous
+prendrons le temps de considérer ça.
+
+### Optimisation WiFi
+
+Ping s'est rendu compte sur sa borne sous OpenWRT que le mode routage donnait
+de meilleures performances que le mode bridge (lorsqu'on fait du NAT).
+
+Hypothèse : les paquets ARP, lorsqu'on fait du routage, ne sont pas transmis Ã
+tout le monde. On gagne du temps si on filtre les paquets ARP (paquets whohas),
+et en les droppant.
+
+Supposition : on ne peut pas spoofer les adresses MAC en WiFi. En utilisant
+ebtables pour filtrer les requêtes ARP whohas, on accepte juste les requêtes
+d'IP existantes.
+
+En terme de débits, un gain de 20% a été remarqué. Cela mérite notre attention
+pour le réseau du Cr@ns.
+Ping va regarder ça côté Cr@ns : une difficulté est de faire des règles
+dynamiques car on ne sait pas à l'avance qui va se connecter, son adresse IP…
+Attention : cela permet de n'optimiser que l'IPv4. Par défaut, tout le monde se
+connecte en IPv6 (dual stack).
+
+### Migration vers gitlab
+
+/usr/script a été pushé vers gitlab : le push "à l'ancienne" n'est plus
+possible.
+Pour pusher, il faut modifier le remote :
+
+* mettre comme remote l'URL git@gilab.crans.org:nounous/scripts.git [mettre une
+ clé publique SSH avant sur Gitlab et penser à faire la config SSH associée]
+* mettre comme remote l'URL https://gitlab.crans.org/nounous/scripts.git (pas
+ de config, mais lorsqu'on push, il faut se réauthentifier avec son login/mdp
+ traditionnels)
+
+L'ancien git peut toujours être lu sur git.crans.org (à coup de symlink). Il
+peut être utile de le garder comme vitrine pour nos scripts.
+
+### Les caprices de lc_ldap
+
+Lc_ldap met un temps fou à charger l'ensemble des adhérents/machines en
+écriture. En plus, souvent, il se vautre lamentablement. Pierre-Elliott propose
+de tweaker un peu l'instanciation des objets pour ne faire les sanity checks
+que lorsqu'on modifie des données, pas lorsqu'on les importe de la base (auquel
+cas, on admet qu'elles sont valides).
+On le laisse s'amuser avec ça.
+
+### Divers
+
+#### Carte étudiant
+
+Il faut envoyer un mail aux adhérents. Étant en période de vacances, on va
+probablement donner quelques jours supplémentaires pour délivrer le document.
diff --git a/compte_rendus/2014_11_06.md b/compte_rendus/2014_11_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..ac6485038d57d7d3e5ffed42180f3d24368384f3
--- /dev/null
+++ b/compte_rendus/2014_11_06.md
@@ -0,0 +1,149 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 6 novembre 2014
+* Lieu : Pavillon Des Jardins
+* Début : 19h00
+* Fin : 20h22
+
+### Présents
+
+* Myriam Bégel
+* Gabriel Detraz
+* Daniel Stan
+* Raphael David Lasseri
+
+### Ordre du jour
+
+### État du 2B
+
+L'expertise du collège technique a été requise sur la question de
+l'accumulation des déchets dans la poubelle du 2B. Les nounous
+confirment : celle-ci est pleine à craquer et un ménage imminent du 2B est
+nécessaire.
+(no comment.)
+
+### Système d'impression
+
+Pour résumer :
+
+* La vm "cups" a été créée, elle tourne mais pas encore de configuration du
+ tout dessus
+* Le driver pcl est en cours d'écriture, Daniel fournira un draft qui
+ implémentera 1/2 options et laissera les autres implémentations aux apprentis
+* Le script de notification fonctionne \o/
+
+À faire :
+
+* Bcfg2
+* Installer cups
+* Finir le driver
+* Un script de recrédit pour les jobs foirés (avec mail de notification pour
+ cela)
+
+### Environnement de test des scripts
+
+Daniel a commencé a modifié /usr/scripts pour permettre au dépôt d'être cloné
+ailleurs que dans /usr/scripts
+et utilisé depuis un autre dossier. Le script indiqué dans le shabang se charge
+également d'indiquer
+quelques variables d'environnement pour passer en mode test. Work in progress,
+mais il veut bien
+des feedbacks.
+
+Tout cela sera résumé sur
+https://wiki.crans.org/CransTechnique/ConventionsUtiles/ScriptsPython
+
+### MÃ j d'OpenWrt
+
+La nouvelle version d'!OpenWrt est sortie en juillet (Barrier Breaker), Daniel
+suggère de recommencer
+from scratch pour voir ce qu'on garde comme modification par rapport Ã
+upstream, et repartir sur des
+bases saines.
+
+* Rendre la borne manageable en ipv6 (idéalement, virer l'ipv4 complètement)
+* Multicast (il paraît que ça marche mieux cf changelog)
+* Vlans Dynamiques (il faut voir si ça marche mieux)
+
+On va bientôt avoir de nouvelles bornes (a priori) pour pouvoir commencer des
+tests. Avis aux volontaires.
+On va également remplacer une petite picostation d'un bâtiment pour faire
+cobaye, on la remplacera
+par une unifi (qui est moins robuste aux tests intensifs).
+
+### "Modems" Wifi d'appoint
+
+Il est envisagé de déployer des points wifi secondaires chez l'adhérent. Le
+principe est simple : l'adhérent
+reçoit contre caution une borne flashée par nos soins, dans le but de servir de
+point d'accès Wifi,
+et éventuellement filaire.
+Ce point se comporte comme une borne classique, le principe étant que
+l'adhérent et ses voisins puissent
+s'y connecter. Le but étant que ce soit le plus transparent possible. Cela
+résoudrait en partie le problème
+des zones blanches de couverture wifi.
+
+Cependant, il n'est pas encore établi si la désactivation de radius est
+nécessaire pour faire passer le vlan
+adh non tagué et le vlan 3 tagué en direction de la chambre de l'adhérent,
+l'idéal étant que ça ne le soit pas.
+D'autres détails, tels que la présence du mot de passe en clair dans la conf
+des bornes méritent l'attention.
+
+### Questions diverses
+
+#### Un point sur le nouveau script de comptes inactifs
+
+Ça buggue, ça buggue, ça buggue. Il faut discuter des délais avant suppression
+du compte. On demandera (en partie)
+au CA. Il est envisagé une suppression auto au bout d'un an d'inactivité (après
+envoi de 4 messages).
+
+#### Serveur de backup
+
+PEB propose ceci :
+http://pad.crans.org/p/serveur_backup
+{{{
+
+## Carte mère
+
+* http://www.rue-montgallet.com/prix/acheter,asus-z87-pro,789193 ou
+ http://www.rue-montgallet.com/prix/acheter,asus-z87-expert,788729
+ * ~ 150 € à ~ 200 €
+
+## RAM
+
+* http://www.rue-montgallet.com/prix/acheter,g.skill-ripjaws-x-ddr3-1600-cl7-8go-2x4go,743095
+* ~100 €
+
+## Processeur
+
+Haswell
+
+* http://www.rue-montgallet.com/prix/acheter,intel-core-i5-4690k-3.5ghz,799815
+* ~200 €
+
+## Boîtier
+
+* htttp://www.rue-montgallet.com/prix/acheter,cooler-master-silencio-rc-550-650w,753033
+* ~150 €
+
+## Disques Durs
+
+1 disque pour l'OS (je propose SSD) et 6 HDD (2 To, 7.2krpm) pour les backups
+Suggestion : http://www.rue-montgallet.com/prix/acheter,seagate-3to-7200-rpm-s-ata-iii-64mo-st3000dm001,755875 (moins cher des 7200RPM))
+
+* HDD : http://www.rue-montgallet.com/prix/acheter,seagate-2to-constellation-cs-st2000nc000,791833
+* ~ 800 €
+* SSD : http://www.rue-montgallet.com/prix/acheter,samsung-64go-830-series,761747
+* ~ 100 €
+
+## Budget
+
+Environ 1 600 €. Les prix étant indiqués sur montgallet, il faut compter une
+marge de 10%, donc ~1800 €.
+}}}
+
+On se demande l'intérêt d'un ssd pour l'OS. Mais why not. Un peu plus d'info
+sur le setup ne serait pas de refus.
diff --git a/compte_rendus/2014_11_20.md b/compte_rendus/2014_11_20.md
new file mode 100644
index 0000000000000000000000000000000000000000..0823bded727fa6e9f224959133c1dbdd52b58843
--- /dev/null
+++ b/compte_rendus/2014_11_20.md
@@ -0,0 +1,151 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 20 novembre 2014
+* Lieu : Pavillon Des Jardins
+* Début : 19h16
+* Fin : 20h21
+
+## Présents
+
+* Daniel Stan
+* Gabriel Detraz
+* Pierre-Elliott Bécue
+* Nicolas Dandrimont
+* Raphaël-David Lasseri
+* Thomas Epalle
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Récapitulatif du matériel vacant
+
+L'association grifon nous a contacté le 17/11/2014 afin de savoir si elle
+pouvait récupérer une partie de notre
+matériel réseau inutilisé à savoir 2~3 switchs procurve et un serveur (un vieux
+dell). PE avait soulevé le
+problème de turn-over sur le matériel. Il voulait aussi conserver un serveur
+pour faire des tests.
+
+Au niveau serveur, on a 4 (ou 5?) serveurs dell sous les bras, on peut
+facilement s'en débarrasser d'un.
+
+Pour les switchs, tous nos spares sont faulty, il faut faire jouer la garantie,
+remplacer les faulty présents dans
+les bâtiments, puis refaire jouer la garantie. On aurait alors 5 switchs
+hp "neufs", il faut faire un inventaire
+complet d'abord, mais sur le principe nous sommes d'accord pour céder deux
+switchs (un 26 ports et un 48 ?).
+
+Il faudra en profiter aussi profiter du changement d'un switch pour passer
+l'aspirateur dans le local et
+ainsi éviter que les switchs s'encrassent trop vite (c'est a priori le problème
+actuel.)
+
+### WiFi
+
+#### Mise à jour vers BB
+
+Gabriel, Lucas et Daniel ont commencé à adapter les modifications Crans sur la
+nouvelle version
+d'!OpenWrt.
+
+* Nouvelle clé ssh (sur fy, /etc/crans/secrets/ parce que /usr/scripts/gestion
+ c'était nul)
+* Vlan dynamiques : ça buggue toujours autant (à investiguer)
+* Management en Ipv6
+
+Pour ce dernier point, on a créé un préfixe (ULA), un slash d'ip locale
+probablement globalement
+unique: fd:a8:5d34:a228/48, annoncé par odlyd.
+
+Détails :
+
+* fd : préfixe pour les IPs "ULA"
+* a8:5d34:a228 : tiré aléatoirement une fois pour ce réseau WiFi
+* c04 : mid de la machine qui route (3074 = odlyd.wifi), pour suivre la même
+ convention que nos /48 publics.
+ -> ça donne un /64 dans lequel sont toutes les bornes (et les machines Wifi,
+ par effet de bord. Elle s'en servent pas, vu qu'elles savent qu'il n'y a pas
+ Internet derrière).
+
+Les bornes et machines prennent une IP supplémentaire dans ce /64. Pour les
+services, on a une IP canonique
+pour éviter de changer la configuration en cas de changement de machine.
+
+* eap: fda8:5d34:a228:c04:7261:6469:7573:3031 (les 64 derniers bits
+ codent "radius01")
+* pea: fda8:5d34:a228:c04:7261:6469:7573:3032 ("radius02")
+* thot: fda8:5d34:a228:c04:7379:736c:6f67:3031 ("syslog01")
+
+Il y a des prob avec syslog qui marche de temps en temps (pour l'envoi vers
+thot), tester avec rsyslog. Il
+reste à faire des tests, bcfg2 sur les serveurs, firewall v6.
+
+#### Nouvelles bornes
+
+Les uap pro sont en test, pour l'instant, il se passe des trucs étranges avec
+openwrt.
+(pertes de paquets ? load balancing foireux entre les deux fréquences ?)
+
+RÃ s sur les unifi standard, sinon les couleurs des leds qui
+changent (inacceptable !)
+
+#### Point sur les bornes du d'Alembert
+
+On a notre réponse: deux bornes brassées sur notre switch (dlink) au d'Alembert
+centre. Il faut envisager
+de remplacer le dlink par un manageable. On verra pour les demandes de
+couverture en particulier,
+Ã part le Villon (Point rencontre, etc), on n'a peu de (aucune ?) demandes.
+
+#### Pont(s)
+
+(Côté administratif, la déclaration du Crans en tant qu'opérateur a bien été
+reçue.)
+Les intéressés ne sont pas présents. Un mail a été envoyé à la STL pour aller
+inspecter les anciennes bornes
+du toit du d'Alembert (vers Arpej). Pas de nouvelles pour l'instant.
+
+#### Management ssh
+
+Raphaël propose à des apprentis de recoder des bouts de wifi_new avec une lib
+ssh : paramiko voir
+fabric. Avis aux volontaires.
+
+#### Freeradius et mdp custom
+
+Il serait possible d'enregistrer un mdp radius différent sur chaque borne. Il
+faudrait coder une
+authentification particulière sur freeradius pour cela. Daniel voit comment
+faire cela, mais il recrute
+un apprenti pour le faire (buzzwords: python, ldap, freeradius).
+
+### Rabbit Mq (manger du lapin nuit-il au développement du râble ?)
+
+[interlude explicative]
+On réfléchit à une manière d'implanter les dépendances sur les services.
+
+Idée : faire un séminaire pour expliquer AMQP dans le détail puis discuter de
+notre utilisation au Crans.
+
+### Prochains séminaires
+
+https://wiki.crans.org/CransTechnique/CransApprentis/SeminairesTechniques/2014-2015
+
+On a booké les séminaires de la semaine prochaine et de la suivante. Avis pour
+la suite, PE veut bien parler d'AMQP.
+
+### OwnCloud
+
+Php (module pgsql ?) n'aime pas l'ipv6. Il va plus vite maintenant.
+
+### Questions diverses
+
+#### Réservation salles
+
+On s'est aperçus ce soir que notre réservation du PdJ le jeudi soir n'est plus
+d'actualité.
+Peut-être que quand le CA est passé le Vendredi soir, la réservation du jeudi a
+été totalement dropée ?
+Il faut voir ça avec la responsable ENS, histoire qu'on se le fasse pas piquer.
+On fouette le CA.
diff --git a/compte_rendus/2014_12_04.md b/compte_rendus/2014_12_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..50852e1aa0a53b7cc0e52e1a8f867c0fbf8eb3bb
--- /dev/null
+++ b/compte_rendus/2014_12_04.md
@@ -0,0 +1,73 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 04 décembre 2014
+* Lieu : Pavillon des Jardins
+* Début : 19h20
+* Fin : 19h56
+
+## Présents
+
+* Gabriel Détraz
+* Raphaël-David Lasseri
+* Pierre-Elliott Bécue
+* Daniel Stan (20h01)
+
+## Ordre du jour
+
+### WiFi
+
+Gabriel signale que la barre des 80 bornes posées à été franchie. Il compte en
+poser encore deux avant les vacances.
+Il reste encore quelques problèmes concernant les logs, le fait que la borne
+n'ai plus qu'une adresse v6 est mal géré à la fois à l'envoi par la borne
+et à l'arrivée par rsyslog...
+Daniel regarde.
+
+### Factures
+
+PEB apporte quelques précisions concernant les attributs des factures :
+
+* recuPaiement est censé être modifiable par tous, pour permettre par exemple,
+ au câbleur de modifier cet attribut (cas d'un adhérent partant sans payer)
+* controle : Permet au trésorier de "locker" la facture et de la
+ valider/devalider.
+
+### gest_crans_lc
+
+Valentin à continuer à bosser dessus, toutefois dans l'état le script reste
+difficilement accessible à un utilisateur débutant en Python, il faut le
+continuer à le proprifier dans les semaines et mois à venir.
+
+### lc_ldap
+
+Actuellement, il y a deux fonctions qu'il est intéressant d'appeler avant de
+sauvegarder un objet dans la base ldap :
+
+* validate_change() qu'il s'occupe de maintenir de la cohérence entre les
+ attributs (rid, ipv6, ipv4, et autre)
+* history_gen() qui génère l'historique des modifications
+
+Il pourrait être bien de les faire appeler par défaut par la méthode save(),
+tout en le laissant désactivable au cas par cas :
+save(validate_change=False, history_gen=False) comme validate_change semble
+idempotente, ça n'est pas grave vis à vis de ceux qui l'appel déjà à la main,
+pour history_gen, ça va mettre des lignes en double (modulo la date).
+Ce sera fait.
+
+### Propreté des serveurs
+
+Il faut proprifier autostatus et munin. (Rapide et simple à faire)
+Pour bcfg2 c'est un peu plus risqué.
+PEB à commencer à faire du ménage dans /usr/scripts il reste encore plusieurs
+scripts à trier.
+
+### Soyouz
+
+Soyouz coûte actuellement ~500€ par an chez OVH, le collège technique considère
+qu'il est important de garder ce serveur pour l'année à venir.
+
+### Questions diverses
+
+### Repas FedeRez
+
+C'est mardi...
diff --git a/compte_rendus/2015_01_08.md b/compte_rendus/2015_01_08.md
new file mode 100644
index 0000000000000000000000000000000000000000..31ee94ecfd18f20dc18363a1f231026fe3e3d49c
--- /dev/null
+++ b/compte_rendus/2015_01_08.md
@@ -0,0 +1,101 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 8 janvier 2015
+* Lieu : Pavillon des Jardins
+* Début : 19h12
+* Fin : 19h56
+
+## Présents
+
+* Gabriel Détraz
+* Raphaël-David Lasseri
+* Pierre-Elliott Bécue
+
+## Ordre du jour
+
+### Serveur de backups
+
+Omnomnom est en marche, il backup les homes des adhérents \o/
+
+Il reste à lui trouver une place sur le campus.
+
+Les présents décident de l'installer au 0H, à faire un soir entre deux backups.
+
+### Mise à jour vers Barrier Breaker (bornes wifi)
+
+Gabriel rappelle que getlogwifi est maintenant un démon qui sert à ouvrir des
+connexions SSH vers toutes les bornes et d'en récupérer les logs.
+
+Il reste à faire en sorte que ce script renvoie les logs directement vers
+rsyslog et non pas dans un fichier (sic) comme c'est le cas actuellement.
+
+### Bornes Unifi 5Ghz
+
+Il semblerait que l'attribution d'une IP via une connexion 5GHz soit très
+lente…
+Il faut investiguer.
+
+### Kludge des Ipv4 Wifi
+
+Cf
+http://git.crans.org/?p=usr-scripts.git;a=commitdiff;h=275934c23c944a2fe711a29bed71b4020833929b
+
+But de la manœuvre : beaucoup (~2000 ?) de machines inscrites en WiFi, avec
+souvent des mac restées en <automatique> donc jamais vraiment utilisées. Le
+système voulait en revanche que l'ipv4 soit assignée à l'avance, ce qui nous
+saturait notre slash ipv4 WiFi.
+
+Daniel a donc rapidement patché ldap_crans et cie pour autoriser l'absence
+d'ipv4
+sur une machine, et fait en sorte que l'ipv4 soit assignée à la première
+connexion (dans freeradius), en même temps que la mac. Plus précisément, la
+machine n'a pas de champs
+ldap "ipHostNumber" ("<automatique>" posait problème),
+ni de champ ldap "rid". On assigne un rid valide à la machine, et l'ipv4 est
+calculée à partir de là .
+
+Pour l'instant, ça marche, même s'il ne s'agit pas d'une solution
+totalement pérenne.
+
+Par contre, Daniel est formellement contre l'effacement systématique
+de machines
+jamais connectées : il pense que cela nous sera bien trop coûteux de déboguer
+les connexions WiFi d'adhérents qui essayeront de rentrer des logins qui
+n'existent plus. En plus, ça polluera encore l'image du WiFi en tant que
+service
+"qui marche pas"®©.
+
+Pierre-Elliott et Raphaël préfèrent détruire les machines WiFi qui restent
+inactives pendant
+plus de 3 mois quitte à envoyer un mail aux adhérents concernés.
+
+### Câbleuse 2.1
+
+Daniel bidouille une nouvelle version de la câbleuse/ticketteuse à base de rpi
+au
+format compact (découpé avec amour, à la perceuse, dans une boite de Ferrero),
+stay tuned.
+Un des objectifs est d'avoir quelque chose de résilient aux pannes de courant
+de la Kfet'.
+De la doc va venir, aussi.
+
+### Remarques diverses
+
+#### Passage à Jessie
+
+On ne va pas tarder à dist-upgrade il faudra trouver des motivés et annoncer
+les mises à jour
+des services critiques.
+
+#### Binding ldap
+
+Django a un module d'administration ldap (django-ldapdb
+https://github.com/jlaine/django-ldapdb).
+Ça simplifierait grandement la gestion des attributs et des logs et cela
+permettrait surtout d'avoir
+un binding maintenu, plus simple à comprendre et plus léger. En plus, on
+pourrait facilement adapter
+une interface web pour le câblage.
+
+Aucune urgence mais il serait intéressant de réfléchir un peu à cette piste et
+continuer à se renseigner.
diff --git a/compte_rendus/2015_01_22.md b/compte_rendus/2015_01_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..e2d7e53685dbfdb727c40eb75a1a9868571a76d3
--- /dev/null
+++ b/compte_rendus/2015_01_22.md
@@ -0,0 +1,127 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 22 janvier 2015
+* Lieu : Pavillon des Jardins
+* Début : 19h14
+* Fin : 20h30
+
+## Présents
+
+* Raphaël-David Lasseri
+* Emmanuel Arrighi
+* William Babonnaud
+* Gabriel Detraz
+* Hamza Dely
+* Daniel Stan
+* Gaétan Facchinetti
+
+## Ordre du jour
+
+### Préparation de l'Install Party
+
+* Le Netboot fonctionne-t-il ? Il faut vérifier et sur le vlan évènement et sur
+ adhérent.
+* Possibilité du portage du netboot en efi ? (on essaie ce
+ soir : https://wiki.ubuntu.com/UEFI/PXE-netboot-install )
+* ''A priori'', les distributions disponibles sont à jour.
+* Il faut prévoir des clés usb en rab pour les uefi secure boot si jamais on
+ n'arrive pas à les désactiver.
+* Les vlans : a priori ils sont bons et vérifiés en taggued sur toutes les
+ prises. Les switches ont été configurés et sont ok.
+
+### Achat de bornes Wifi
+
+Gabriel propose de racheter deux boites de 3 bornes (Unifi standard). Résumé
+des besoins : une pour le bâtiment B, pour remplacement, et 3 autres au M. Le
+reste sera dispo pour remplacement, en appoint.
+
+(Sans les frais de port)
+
+* IP : 432€
+* landashop : 465€
+
+### Omnomnom
+
+Pierre-Elliott a oublié d'acheter un disque dur de rechange. On propose ça au
+CA, avec un ventilo supplémentaire pour la tour (histoire d'être sûr).
+
+* Disque : 220 € (http://www.rue-montgallet.com/prix/acheter,seagate-3to-7200-rpm-s-ata-iii-64mo-st3000dm001,755875)
+* Ventilo : 15 - 20 €.
+
+### Migration sous barrier breaker
+
+Petit problème mineur lors de la migration : on a oublié d'activer l'option
+d'atheros pour avoir les canaux
+spécifique à l'Europe ETSI (canaux 12 et 13).
+
+On a re-flashé une partie des bornes, mais pas toutes. Celles du G, C,
+d'Alembert, H et PDJ ont toutes le firmware patché.
+
+À voir ce qu'on fait du canal 13, pour l'instant, on l'a mis en test à la
+Kfet (lieu de passage de tout
+nouveau venu), histoire de faire des tests.
+
+Bug détecté avec les nouvelles unifi au reboot, moins présent après passage Ã
+barrier breaker, Ã investiguer.
+
+### Switches
+
+On a reçu 3 switches 24 ports et 2 switches 48 ports. Les switches de
+remplacement sont des 2620 neufs, du coup c'est cool. Gabriel fera une seconde
+session.
+
+### Coupure électrique
+
+Le mercredi 21 janvier, la ville a rebooté, le campus aussi. Le CROUS a
+souffert au niveau du TGBT (Tableau Général Basse Tension), du coup ça a pris
+plus de 45 minutes à revenir, et on a perdu le 0B.
+
+On s'est rendus compte de deux détails, premièrement, la gestion de l'ISCSI et
+du montage des disques des homes sur zbee, ça marche pas. PEB est sur le coup
+en utilisant udev et en rajoutant des nofail en option sur le montage des home.
+Le deuxième problème est la default via foireuse d'odlyd au boot. Il parle en
+utilisant son IP côté ENS, du coup les réponses qui lui sont destinées sont
+droppées, aiccu et vpn n'y arrivent pas, du coup. Normalement, une règle
+post-up dans interfaces corrige la route.
+
+/usr/scripts ne s'est pas monté partout, le wiki ne s'est pas bien démarré, et
+idem pour l'imapproxy de SOGo. À surveiller, mais le reboot était fait
+à la hache, ça n'a sûrement pas aidé.
+
+Trucs à prévoir pour la prochaine fois :
+
+* Séquence de coupure automatique annoncée par pulsar
+* Retrouver le mdp de pulsar pour accomplir la tâche précédente (sic)
+* Vérifier la default route sur odlyd
+* Désactiver l'auto-reboot après coupure, sur les serveurs
+* Vérifier la signalétique des disjoncteurs (« arrivée onduleur ou pas ? »)
+* Les bornes wifi qui ont décidé de snobber radius (un wifi down; wifi up les a
+ calmé), ainsi que NTP.
+
+### Kludge kvm
+
+On compte acheter deux trois adaptateurs
+usb-ps2 ([[http://bit.ly/17YtjeC]]) compatibles kvm pour dépanner, entre autre
+le kvm du 0B, celui du 0H.
+
+## Questions diverses
+
+### CransPasswords
+
+Pierre-Elliott a commencé a modifier la base pour la rendre indépendante de
+ssh, et de sudo dans le but de ne plus avoir besoin d'un utilisateur sur le
+serveur.
+
+### Délégation de sous-domaines et machine exté
+
+On a eu une demande d'adhérent pour inscrire un ndd en .crans.org vers une IP
+extérieure, voire déléguer le sous-domaine à l'adhérent.
+
+Techniquement faisable, mais les binding ne sont pas prévus pour, pour le
+moment. On peut :
+
+* Inscrire des machines (rid spéciales)
+* Développer une appli sur l'intranet2 pour cela (pour crans.eu, pour ne pas
+ mélanger avec crans.org)
+
+On retient la solution 2, pour tester (django-ldapdb ou pgsql ?)
diff --git a/compte_rendus/2015_02_05.md b/compte_rendus/2015_02_05.md
new file mode 100644
index 0000000000000000000000000000000000000000..64411e00a3650aa0e6e3d0f7e11c2a6c68c8b509
--- /dev/null
+++ b/compte_rendus/2015_02_05.md
@@ -0,0 +1,131 @@
+# 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… <<Pad>> <- 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 <<DateTime(2015-02-19T09:49:21+0100)>>
+## 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 <<DateTime(2015-02-19T10:14:06+0100)>>
+
+## 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.
diff --git a/compte_rendus/2015_02_19.md b/compte_rendus/2015_02_19.md
new file mode 100644
index 0000000000000000000000000000000000000000..369f6e40fcef27e358c378bde819bc00a4b4748a
--- /dev/null
+++ b/compte_rendus/2015_02_19.md
@@ -0,0 +1,105 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 19 février 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h08
+* Fin : 19h48 !!!!
+* <<Pad>>
+
+## Présents
+
+* Raphaël-David Lasseri
+* Gabriel Detraz
+* Jordan Delorme
+* Daniel Stan
+* Hamza Dely
+
+## Ordre du jour
+
+### Ponts WiFi
+
+On a installé le point d'accès 5Ghz vers Arpej, sur le toit du d'Alembert, la
+DSI et le STL ont été particulièrement serviable.
+Le VLAN3 est diffusé sur le pont. Détaggué à l'arrivée pour brancher le routeur
+d'Adam, d'autres points d'accès en réception sont prévus
+(avec le protocole !AirMax) côté Arpej. Pour l'instant, ça marche avec un seul.
+L'arrivée du pont est censée connecter un point d'accès
+WiFi classique, avec point d'accès appartenant au Crans. Il faut
+potentiellement se pencher sur l'utilisation de mots de passe
+Radius dédiés à ces points d'accès. On pourrait les renseigner dans la base
+Ldap, (appel à apprenti(s)).
+Côté PDJ, c'est le vlan 1 qui est diffusé, on envisage de remplacer par le 3.
+
+Il y a plusieurs solutions pour faire passer le vlan adhérent via un tunnel, il
+vaut mieux laisser le choix à la discrétion des utilisateurs.
+
+La STL nous a demandé de protéger les câbles présents sur le toit avec une
+gaine. Il faut finir cette installation rapidement !
+
+### Routeurs individuels
+
+Pour le moment, le setup retenu pour les routeurs individuels, est de les
+authentifier sur le vlan 1 en non taggué, c'est une nécessité
+pour faire marcher la connexion filaire de l'adhérent sans toucher à la conf du
+switch (trop lourd). On peut essayer de faire passer
+le vlan 3 à travers du pppoe. Ce protocole semble plus léger que du vpn,
+supporté par openwrt, et la MTU n'est pas trop réduite (on
+pourra activer les jumbo frames au passage…)
+On commencera donc à faire des test utilisant PPPoE.
+
+### Festival de robotique de Cachan
+
+Odile Malezieux nous a demandé d'évaluer les possibilités d'une couverture
+internet du Gymnase à l'occasion du Festival de robotique de Cachan
+qui aura visiblement lieu début juin.
+Dans l'état actuel la DSI à un dédoubleur tel/eth au niveau du Gymnase.
+De notre coté la seule solution semble être l'installation d'un
+pont (again \o/) pour couvrir le Gymnase, temporairement.
+Du coup il faudrait poser une borne sur le toit du 6B ou du PdJ.
+À faire en mai
+
+### Router Advertisement
+
+Ramond est installé sur apprentis. Il a déjà chopé une machine qui faisait des
+RA. Radius a été patché pour rejeter les machines
+ayant une blacklist isolement, tant que le taggage dynamique ne marche pas.
+
+Le script de déconnexion appelé par ramond place la blacklist directement sur
+la machine. Idéalement, il faudrait tester la
+fonction qui refresh l'authentification de la chambre (pour forcer la
+réallocation de vlan.)
+
+À continuer/finir…
+
+### Sanction upload
+
+Un/des abus de droit pour lever des blacklists pour upload ont été perpétrés
+par une Nounou (sniff…)
+L'abus de droit étant caractérisé. Il faudrait préciser à l'avenir dans le RI
+la définition précise de l'abus de droit.
+Toutefois la Nounou en question n'est pas considéré comme "dangereuse" pour
+l'association. Par conséquent le Collège Technique ne juge pas nécessaire
+de retirer les droits "Nounou" au concerné.
+Il est du ressort du CA de décider des suites exactes à donner.
+
+### Imprimante thermique
+
+La boite de Ferrero abrite enfin une Raspberry Pi et la jumelle de l'imprimante
+thermique. Tout marche, il reste à chiffrer la carte SD.
+Raphaël et Hamza s'en occuperont.
+Puis direction Kfet.
+
+### Questions diverses
+
+#### Suppression des comptes inactifs
+
+Raphaël s'occupe de finaliser l'histoire des crons simultanés et d'ici une
+semaine d'envoyer la première vague de mails.
+
+### Droits Nounous
+
+nounous.append(u'Detraz')
+Un rappel de bon sens agricole est tenu au récipiendaire.
+Longue Vie au Collège Technique (qui vient de prendre un sacré coup de jeune)
+
+Aou Aou Aou !
diff --git a/compte_rendus/2015_03_05.md b/compte_rendus/2015_03_05.md
new file mode 100644
index 0000000000000000000000000000000000000000..b23f2d5d360489ca61f24bc8479dacf97f019444
--- /dev/null
+++ b/compte_rendus/2015_03_05.md
@@ -0,0 +1,104 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 5 mars 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h15
+* Fin : 20h10
+* <<Pad>>
+
+## Présents
+
+* Emmanuel Arrighi
+* Myriam Begel
+* Gabriel Detraz
+* Hamza Dely
+* Daniel Stan
+* Raphaël-David Lasseri
+* Nolwenn Bruneel
+
+## Ordre du jour
+
+### Miroir ftp
+
+## En racheter un ? Faire le ménage ?
+Charybde est à 86% (total 3.3To) d'utilisation sur /pubftp et il reste ~200Go
+non alloué sur le lvm. Quid des anciennes versions de Debian/Ubuntu ? OpenBSD.
+On en rediscute avec l'avis d'autres nounous (les seules présentes étant bien
+partantes pour virer BSD et cie…).
+
+BSD n'est pas un besoin absolu, on pourrait dropper. En revanche la saturation
+des disques de Charybde d'un point de vue load est réelle.
+
+### Rationalisation Radius
+
+Actuellement, on possède deux serveurs radius pour le filaire : radius et
+sable (en backup).
+Pour le WiFi, on a eap et pea (en backup, mais backup non fonctionnel, donc
+tests).
+
+L'idée serait de fusionner les services radius WiFi et filaire, en mettant tout
+sur deux VM (radius et eap). Un des intérêts est de rationaliser la conf de
+sable.
+
+Le travail sur la gestion dynamique des mots de passe en fonction des
+NAS (switchs et bornes) est presque fini.
+On prévoit de migrer vers ce système aux alentours du week-end du 14.
+
+### AMQP
+
+Trigger n'a pas bougé récemment, si ce n'est que Pierre-Elliott s'est
+débarrassé du problème de mail de redirection en confiant cette
+fonctionnalité à mailExt. Via gest_crans, ça ne change pas grand chose, sauf
+qu'il y a une nouvelle option quand on modifie un adhérent.
+
+Techniquement, il faut encore que l'on réfléchisse à l'histoire d'enchaînement
+des services. '''A priori''' un "gestionnaire d'événements" serait la
+façon la plus propre de faire.
+
+Generate fonctionnant à peu près pour l'instant, on n'est pas dans l'urgence.
+Les gens qui veulent mettre de nouveaux services non chaînés en place
+peuvent se référer aux DHCP/Firewall qui ont été implantés.
+
+Côté test, ce serait bien d'avoir une copie disponible quelque part pour tester
+les nouveaux services, une fois les premiers mis en place. On va faire
+ça sur {{{apprenti}}}. Avis aux volontaires : c'est
+dans {{{/usr/scripts/{cmb,gestion/trigger} }}}
+
+CMB n'a pas besoin d'être modifié '''a priori''', c'est un module de
+message-broking très simple. Les tests sont faisables directement sur les
+serveurs
+fournissant les services, dans la mesure où on pose comme racine /tmp. Il
+faudra juste faire la conf à la fin. De toute façon, il vaut mieux contacter
+PEB pour en discuter avec lui.
+
+### etckeeper
+
+C'est un joli petit programme qui conserve un dépôt git du /etc/. Ça marche
+bien sur vo, on continue à l'installer à deux trois autres endroits pour tester.
+
+### Intranet
+
+Gabriel et Hamza ont commencé à travailler sur la partie "monCompte" sur
+l'intranet2. Reste à migrer :
+
+* l'impression
+* l'affichage des quotas (Hamza)
+* Paypal
+
+Pour ce dernier, on pourrait s'en débarasser et passer à un paiement par
+CB ? Également possible : le rechargement par note. Demander au CA !
+(https://www.comnpay.com/offres.html ?)
+
+### Ticket
+
+Hamza a fini l'impression des factures (cf git). Il ne reste plus qu'Ã chiffrer
+la carte SD et d'installer la nouvelle câbleuse (oison^W rasputin) à la Kfet !
+
+### Ra2.py
+
+Ramond tourne sur fy, il surveille le réseau (tous les vlans), appelle ra2.py
+si besoin est (pose une blackliste).
+
+### CAS
+
+Raphaël nous a fait regarder les logs du CAS, on a bien rigolé.
diff --git a/compte_rendus/2015_03_19.md b/compte_rendus/2015_03_19.md
new file mode 100644
index 0000000000000000000000000000000000000000..439bd8c50513684cfb1e5c0ad48d583d88b761f2
--- /dev/null
+++ b/compte_rendus/2015_03_19.md
@@ -0,0 +1,105 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 19 mars 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h08
+* Fin : 20h30
+* <<Pad>>
+
+## Présents
+
+* Myriam Bégel
+* Hamza Dely
+* Emmanuel Arrighi
+* Gabriel Detraz
+* Jordan Delorme
+
+## Ordre du jour
+
+### Virtualisation et clubs
+
+Résumé de la situation des virtualiseurs :
+
+* ft : quasi neuf, 1 an (donc sous garantie), très puissant
+* kdell : serveur par free (donc pas sous garantie, ''a priori''), moyen
+ puissant
+* fz: fin de vie, encore 1 an de garantie, moyen puissant++
+
+Clairement, on a encore beaucoup de marge. On pourra commencer à envisager le
+rachat si fz ne passe plus en garantie en novembre prochain.
+
+Pour les clubs, le système à base de proxmox est fonctionnel : on peut créer
+des groupes et compagnie pour administrer uniquement un sous-ensemble de
+machines. La
+création d'une vm n'est cependant pas automatique et il faudra faire appel Ã
+une nounou. Comme on ne connaît pas la demande exacte, et qu'il y a
+énormément de latitude sur les ressources allouées à une vm (\epsilon -> \huge
+beaucoup), il est envisagé de traiter les demandes au cas par cas, lors
+d'une IN par exemple.
+
+### Quota
+
+Il est suggéré de monter l'espace disque des adhérents à 20Go. Compte tenu de
+l'espace disque disponible assez élevé, cette mesure ne conduira pas à un
+remplissage des disques dans l'immédiat.
+
+### Rabbit MQ et environnement de test
+
+Ça fonctionne avec rasputin (la nouvelle ticketteuse) pour l'environnement de
+test. Gabriel a des questions sur le fonctionnement de trigger.
+
+On va commencer à tester sur une branche de test de lc_ldap, pour envoyer les
+messages à apprentis (au lieu de civet) et voir si le parser se comporte bien…
+
+### Intranet2
+
+* Mon compte : ça marche. (Le css est toujours un peu moche, mais ça va
+ s'arranger)
+
+Il reste à migrer :
+
+* Quota (Gabriel est sur le coup)
+* Impression
+* Pages perso
+* Rajouter la création de digicode dans l'intranet2
+
+Une fois ceci fait, on pourra se débarrasser de l'intranet et migrer facilement
+zamok sur jessie. Il faut se
+pencher activement sur le portage de l'intranet2 pour django 1.7,
+voire 1.8 (qui ne va pas tarder.)
+
+Trucs qui cassent (non exhaustif)Â :
+
+* manage.py
+* l'archi des apps
+* settings.py ?
+
+Bref, ça avance !
+
+### Firewalls
+
+Il y aurait moyen de recoder le pare-feu IPv6 de manière plus intelligente,
+notamment en utilisant les ipset mac-based
+qui sortent sur le noyau linux de Jessie. À terme on pourrait carrément
+fusionner les deux pare-feux (gérer
+toutes les Blacklists ensemble, etc.)
+
+### Festival robotique
+
+Le 1er festival de robotique de Cachan a lieu dans le gymnase de l'ENS du 1er
+au 8 juin. Les organisateurs souhaiteraient pouvoir bénéficier d'une connexion
+internet pour une dizaine de personne.
+On s'est fait relancer par Odile.
+
+La DSI ne veut pas nous prêter de l'ethernet, car la seule connexion rj45 est
+câblée très particulièrement. Il nous
+reste donc les options suivantes :
+
+* Tirer un câble depuis le DGC (en face)
+* Pont WiFi depuis le PdJ (Ã tester)
+
+Bref, il faut aller faire du repérage. On verra ça jeudi prochain.
+
+### IP
+
+On fixe la Key signing party pour midi.
diff --git a/compte_rendus/2015_04_02.md b/compte_rendus/2015_04_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..5be8a018e8abc6644ac89ec48e491b6b38284dd5
--- /dev/null
+++ b/compte_rendus/2015_04_02.md
@@ -0,0 +1,125 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 2 avril
+* Lieu : Pavillon Des Jardins
+* Début : 19h00
+* Fin : 20h43
+
+## Présents
+
+* Daniel Stan
+* Gabriel Detraz
+* Hamza Dely
+* Myriam Begel
+* Pierre-Elliott Bécue
+
+## Ordre du jour
+
+### Intranet
+
+## Refondre un plugin et faire un copy/paste c'est pas très très compatible.
+## PEP8
+
+De nouvelles apps ont été portées par Gabriel :
+
+* quota
+* mon compte
+* pages perso
+
+Il reste à faire :
+
+* l'appli d'impression
+* paypal (ou pas)
+
+Pour le moment, on se fixe comme objectif d'avoir une interface
+de *lancement* des impressions, à partir des fichiers présents dans le home. On
+verra plus tard pour les fonctionnalités plus compliquées.
+
+Il va falloir vérifier la fonction solde dans lc_ldap (sic).
+
+Pour paypal, des services de paiement par CB alternatifs existent, par exemple
+https://www.comnpay.com/integration.html, Ã celui qui veut prendre le projet de
+choisir… (sous réserve d'accord du CA.)
+
+### Montage NFS des homes
+
+Résumé des changements :
+
+* {{{o2}}} a besoin des homes montés pour accéder aux quotas immédiatement ;
+* {{{zamok}}}, {{{dovecot}}}, {{{omnomnom}}} les montent quand ils en ont
+ besoin (par lettre).
+
+On peut monter les lettres sur o2 une à une… ça règlera le problème des homes
+pas montées pour les quota. (Ça a été fait durant l'IN.)
+
+### Feduroam
+
+Principe : proxy radius qui peut rediriger les requêtes de connexion vers un
+serveur en fonction d'informations de l'utilisateur. Ici, on redirigerait des
+requêtes d'auth vers des serveurs radius d'autres associations (Via, Rézo ?)
+
+Ça fonctionne, de notre côté. On attend des nouvelles de leur côté. Et il reste
+l'histoire de l'allocation de l'IP : pour le moment, les macs des machines ne
+sont pas connues, donc même avec adresses IPs dynamiques, il faut laisser
+passer la mac dans le parefeu.
+
+Il faut aussi se pencher sur les questions administratives…
+(on va dire que le choix du nom du ssid est … federez)
+
+### Révision plan adressage
+
+Des mises à jours de config.py ont été faites pour mieux correspondre Ã
+https://wiki.crans.org/CransTechnique/PlanAdressage.
+
+Pas de nouvelles suggestions pour le moment.
+
+### Upload
+
+PEB a mis en place un comptage incrémental pour {{{deconnexion.py}}} (le script
+qui compte l'upload, installe les blackliste, et avertit
+les adhérents). Pour éviter les dérives, un recomptage est fait tous les
+jours (à minuit), même si pour l'instant, la dérive est très faible.
+
+Bonus : on peut désormais faire afficher le quota d'upload courant par
+adhérent. Risques : les adhérents qui veulent
+flirter avec la limite. On peut aussi laisser un flou, par exemple, on s'arrête
+Ã 4Go (et plus d'avertissement plus loin.)
+
+### Alertes SMS
+
+L'alerte SMS fonctionne, en test sur zamok. Voir la doc
+https://wiki.crans.org/CransTechnique/ServicesMineurs/GammuSms
+
+Pour l'instant, le script vérifie la présence du mot clé "[SMS]" dans le
+subject.
+
+### Droits vieilles nounous
+
+PEB est contre leur retrait de droits s'il n'est pas possible de le leur
+rendre, et
+il ne faut pas oublier qu'en cas de pépin, ça veut aussi dire que ceux qui sont
+encore susceptibles d'intervenir ne le pourront plus forcément.
+
+Le principe est de retirer les droits nounous d'anciens qui ne s'en servent
+plus régulièrement.
+Pour répondre au point précédent, il est possible de laisser une commande
+accessibles (via
+un droit spécifique) pour les récupérer en cas de besoin.
+
+### Questions dîtes "verses"
+
+#### Bcfg2
+
+PEB a commencé à refondre le plugin Bcfg2 écrit par Jérémie. Ça devrait pas
+être très long,
+ensuite, à moyen terme, faudrait se débarrasser des sucres du plugin. Perso,
+ils ne le dérangent
+pas trop, et "facilitent" parfois la lecture, mais sont sans doute "dangereux".
+
+À suivre.
+
+#### Saclay
+
+Un dossier est présent dans gitlab, pour nous vanter dans tous les sens. Ce
+dossier devrait être
+prêt pour mi-avril. Avis aux volontaires.
diff --git a/compte_rendus/2015_05_07.md b/compte_rendus/2015_05_07.md
new file mode 100644
index 0000000000000000000000000000000000000000..7871e1e856309e7e9d7d8f675a3dc3d5421f73db
--- /dev/null
+++ b/compte_rendus/2015_05_07.md
@@ -0,0 +1,164 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 7 mai 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h14
+* Fin : 20h36
+* <<Pad>>
+
+## Présents
+
+* Hamza Dely
+* Gabriel Detraz
+* Emmanuel Arrighi
+* Daniel Stan
+* Raphaël-David Lasseri
+* Pierre-Elliott Bécue
+* Raphaël Bonaque
+
+## Ordre du jour
+
+### Federez WiFi
+
+* Le système fonctionne en ce qui concerne le Cr@ns, dans les deux sens.
+* Le Principe : une demande d'authentification federez-wifi a un suffixe
+ en @federez.crans par exemple, et est acheminée par le système de proxy
+ radius vers le serveur de l'école d'origine.
+
+* Il reste des problèmes sur la réception dans les autres assos, au niveau de
+ la modification de l'identifiant pour retirer le suffixe. En effet,
+ l'utilisation du module python au Cr@ns n'a pas permis de déceler ce problème
+ plus tôt.
+* La doc et le monitoring sont
+ disponibles : https://wiki.federez.net/admin:services:wifi-federez et
+ https://wiki.federez.net/admin:services:wifi-federez:monitoring
+
+Pour terminer, il faut :
+
+* Mise en place d'un nouveau vlan, d'un nouveau /d'ip natées (donc, demander Ã
+ la dsi les id vlans disponibles), le plus simple comme solution vu les
+ scripts dont on dispose actuellement)
+
+État du système (au 12/05/15):
+
+. Iresam :
+. bal -> iresam : prb sur les id à l'arrivée, comment retirer le
+suffix / iresam -> ext : réglé
+
+. Crans :
+.bal -> crans : ok / crans -> bal : ok
+
+. rezo-metz :
+. bal -> metz : ils ont un suffixe, pas de soucis (maj : c'était inexact mais
+sans incidence) / metz -> bal : réglé
+
+. gif :
+. bal -> gif : prb d'id à l'arrivée / gif-> bal : réglé
+
+### Couverture du gymnase
+
+« Ils ont froid. »
+
+Le festival de robotique nous a relancé. Daniel a fait du repérage hier, et a
+constaté que la DSI
+va installer un switch 8 ports poe avant fin mai. Ils nous proposent de nous
+réserver un port.
+Un câble devra être tiré depuis le local technique vers le lieu d'installation
+de notre borne.
+Un mail sur dsi crans a eu lieu à ce propos, Sabrina propose de nous réserver
+un part sur le switch,
+Gabriel lui répondra sur le sujet de la configuration des locaux, de l'accès
+entre le gymnase et
+le local notamment.
+
+On envisage d'installer une borne Unifi Pro, ce qui permet d'avoir un port en
+plus pour rajouter
+des accès filaire au besoin, et s'alimenter directement en PoE.
+
+### Bcfg2
+
+Pierre-Elliott a recodé le plugin from scratch. Il a laissé les sucres "@" mais
+a retiré les "export" (''a priori'',
+seul le main.cf du bundle postfix.)
+
+Deux trois tests à faire encore avant de packager pour jessie. Le client de
+wheezy ne fonctionne
+pas avec le serveur jessie. On peut tester avec vo en tant que client (il
+faudra le migrer).
+
+Il va y avoir du ménage à faire dans les Metadata (groups surtout, en ce moment
+soyouz essaie
+de monter des trucs en NFS…).
+
+### Mise à jour vers Jessie
+
+Elle est sortie !
+
+On va commencer à indiquer des dates là -dedans.
+[[CransTechnique/AdminSystème/DistUpgrade#Serveurs_non_migrés]]
+
+Penser aussi à évaluer la difficulté de la mise à jour. On va commencer par vo,
+et puis on verra pour les autres,
+suivant disponibilités des nounous.
+
+Vo upgradé permettra d'avancer dans la migration de l'intranet et de tester
+bcfg2-client (ce qui serait
+bien avant de continuer avec les upgrades.)
+
+### Intranet
+
+Hamza et Gabriel ont bien travaillé :
+
+* Rechargement solde impression : com'n'pay, le contrat est en cours
+ d'activation
+* Impression : l'application fonctionne, sauf l'envoi de mail, car cups sur
+ o2 formate mal le jobname (On trouve pas pourquoi.)
+* La programmation du driver PCL a avancé, il faut finir (en résolvant les bugs
+ que l'on a décelé jusque là …)
+* Gestion des clubs : impersonate ? Les apps plantaient quand on se connectait
+ en tant que club.
+
+. impersonate est un plugin django pour se faire passer pour un autre
+utilisateur. On peut alors
+spécifier qui a le droit d'impersonifier qui.
+. Prob 1 : PIP (beurk)
+. Prob 2 : l'absence de traçabilité.
+. L'autre solution est d'intégrer ces fonctionnalités dans les
+applications. <-- ça serait plus propre non ? Oui. Hamza et Gabriel vont
+s'occuper chacun de leur app et on verra si ça marche.
+
+### Switchs PoE
+
+Intervention de PEB : « J'ai eu Anne au téléphone… qui me rappelle. »
+Ceci était une intervention de PEB.
+
+Le plan est d'acquérir des switchs gigabit PoE (actif), un par bâtiment, afin
+d'alimenter et
+de pouvoir redémarrer les bornes WiFi à distance. Il faudra également acheter
+des spliter
+(une centaine ?) pour toutes les bornes sauf les UAP Pro (qui le font en natif.)
+
+Les switchs gigabit remplacerait les étoiles actuelles.
+
+À voir suivant le prix, notamment acheter 100 splitter qui pourrait couter dans
+les 1000 à 2000 euros à lui seul.
+
+### Ponts WiFi
+
+PDJ : le printemps est arrivé. On va voir si on peut accéder au toit avec
+l'accord de la STL.
+
+Parallèlement, on envisage de tunneler le réseau ethernet "filaire" au travers
+du réseau WiFi.
+D'une part, pour les bornes d'appoint à placer chez les adhérents, cela
+permettrait de n'assigner qu'un
+seul vlan lors de la connexion de la borne WiFi (cela permettra de garder le
+système d'auth
+automatique par mac via radius, sur les switchs des chambres.)
+D'autre part, cela permettra de normaliser le système de ponts actuels : les
+ponts feront transiter
+le vlan 3 et à l'arrivée, une borne d'appoint pourra dé-encapsuler le vlan
+filaire, si les gens
+en veulent.
+
+Pour l'instant, ce projet n'est pas prioritaire, on s'en occupera cet été.
diff --git a/compte_rendus/2015_05_26.md b/compte_rendus/2015_05_26.md
new file mode 100644
index 0000000000000000000000000000000000000000..2c7c9004a1eb53b60d0ce9c1878a7b0253a2742f
--- /dev/null
+++ b/compte_rendus/2015_05_26.md
@@ -0,0 +1,167 @@
+# Réunion du Collège Technique
+
+* Date : Mardi 26 mai 2015
+* Lieu : Condorcet
+* Début : 19h25
+* Fin : 20h23
+* <<Pad>>
+
+## Présents
+
+* Daniel STAN
+* Gabriel Detraz (via $Kype)
+* Pierre-Elliott Bécue
+* Hamza Dely
+
+## Ordre du jour
+
+### Événement robotique
+
+Daniel propose un rdv avec la DSI demain ou jeudi matin. Avis aux volontaires
+qui voudraient l'accompagner. Comme l'UAP Pro n'a pas encore été commandée, on
+compte utiliser celle du 2B en attendant de refaire une commande cf Jeudi
+prochain. L'intérêt d'une UAP Pro est d'avoir le poe actif intégré (le switch
+dsi est poe compatible) et de proposer un port ethernet supplémentaire pour
+pouvoir étendre le réseau si besoin.
+
+### Point rencontre
+
+La DSI a répondu à Pierre-Elliott, ils ont un souci avec la fourniture de
+machines car il semblerait qu'ils doivent identifier les gens utilisant les
+machines.
+Pierre-Elliott leur a proposé de les faire passer par le réseau Crans, il
+faudrait voir si on veut mettre un portail captif sur le port 80 pour obliger
+les gens
+Ã fournir login/MDP.
+
+Parallèlement, il faut s'intéresser aux mots de passe wifi jetables. Il
+faudrait également pouvoir savoir qui s'en sert, car si un jour on a une
+requête,
+et qu'on a pas de réponse, on se fera vraiment emmerder.
+
+On pourrait fournir un mini-formulaire à remplir par l'admissible en échange de
+tickets WiFi fournis par le BDE.
+
+Niveau imprimante on peut en fournir une (Hyjal) si le BDE le souhaite.
+
+Ne pas oublier la charge supplémentaire pour le BDE à l'ouverture/fermeture du
+PR vis-à -vis du matériel mis à disposition (ordinateurs, imprimante, etc.).
+À voir avec le BDE.
+
+### Virtualisation BDE
+
+Le BDE est partant pour virtualiser. Besoins :
+
+* Deux VMs
+ * Une avec 20 Go de stockage, un ou deux cœurs, et 1 Go de RAM
+ * Une avec 8 Go de stockage, un cœur et 512 Mo de RAM.
+
+Usage : serveur web et test. Les nounous sont d'accord.
+
+### Ponts WiFi
+
+Le pont WiFi vers le coteau est mort. Ouranos semble avoir des problèmes de
+flashage. Les intéressés sont sur le coup. On ne comprend pas pourquoi le fs
+est corrompu.
+
+Un reflash semble nécessaire, vu l'état de mort cérébrale de la borne.
+Remplacer par nanom5 ? Il est nécessaire d'intervenir sur le toit.
+
+### FedeRez WiFi
+
+Ça marche, cool.
+
+Le vlan 12 a été mis en place côté campus. Le SSID en revanche n'est pas
+diffusé sur toutes les bornes.
+On va parler à la DSI de la propagation du vlan 12 côté ENS via DT.
+
+https://wiki.federez.net/admin:services:wifi-federez
+
+### Discourse
+
+On a installé une vm.
+
+C'est une super fucking application Ruby On Rails qui tourne dans un container
+docker à la con sur une VM appelée… Discourse. Scourse
+
+Le soft en lui-même est moderne, et pas mal d'un point de vue ergonomie.
+Cependant, il pose des soucis divers et variés.
+
+Problèmes rencontrés :
+
+* Vie privée (les admins ont accès aux messages privés) ;
+* Facilité de lecture, l'agencement des posts est pas terrible ;
+* Certaines personnes ne savent pas filtrer par catégorie, mais bon, ça c'est
+ la couche 8.
+
+### Renouvellements de garanties
+
+* Charybde : 168 € HT
+* Pulsar : 865 € HT
+
+Pulsar on veut. Charybde on s'interroge. Pour l'instant, on laisse de côté
+Charybde, car il n'est pas si vital, et nous avions déjà un projet de miroir
+commun avec la DSI.
+
+Pour charybde, on va poker la DSI, et on va voir.
+
+### Switch PoE
+
+8 k€ pour 9 gigabit 24 ports (les 2530) POE.
+
+À noter qu'il faut rajouter à la dépense l'achat de splitter PoE et
+éventuellement des gbic si les actuels ne sont pas compatibles.
+À voir en CA.
+
+### Virtualisation
+
+Pierre-Elliott veut toujours son virtualiseur. Pour le moment, le besoin ne se
+fait sentir. Fz passe hors garantie en novembre, on pourra voir à ce moment lÃ
+pour acheter un truc plus gros.
+
+### Disques pour les VM
+
+En parallèle, on envisage d'échanger le stockage des vm pour utiliser les
+disques de 600Go. L'idée est de débrancher un disque de 300 Go, et de mettre
+un 600 Ã la place.
+À essayer… après avoir lu la doc.
+
+### dist-upgrades
+
+asterisk ça s'est bien passé.
+discourse est déjà sous Jessie.
+
+#### Freeradius
+
+Y a des trucs qui segfaultent.
+Après investigation, le problème semble complexe : le phénomène de segfault ne
+survient pas après clean install et appel au backend python. On investigue
+avant de bugreport.
+
+#### Bcfg2
+
+Mise à jour faite, on a créé une nouvelle VM, le paquet est à jour avec le
+plugin. Il avait des soucis de {{{print}}}, qui ne sont pas thread-safe, et il
+est probable que
+le fonctionnement interne du serveur ait changé aussi.
+
+{{{print}}} ne fait donc plus rien, et on a mis une fonction out() et _out() en
+place pour remplacer.
+
+La nouvelle VM sera renommée sous peu.
+
+### Couacs update.sh
+
+Lors des derniers update.sh, qui apparemment ont tous eu lieu sur fz, les homes
+se remontaient en partie en read-only. fz présentait d'autres anomalies
+relatives aux disques. On l'a rebooté. Comme c'est la première fois que cela
+survient, on va pour l'instant garder l'Å“il.
+
+### Coupure annuelle
+
+Chérie, ça va couper. Il faudra être vigilant.
+
+On prévoit une maintenance d'une journée du local et d'une certaine quantité de
+services ou autre. On va fixer une date (fin juillet~août, voir crans
+vacances) et une liste de trucs à faire (ranger 0B, migrer disques vm,
+dist-upgrade routeur, ldap.) Si ça vous intéresse, manifestez-vous !
diff --git a/compte_rendus/2015_09_03.md b/compte_rendus/2015_09_03.md
new file mode 100644
index 0000000000000000000000000000000000000000..f24d4f5b7ade52b0dc316f5c27ffea0116cd5eae
--- /dev/null
+++ b/compte_rendus/2015_09_03.md
@@ -0,0 +1,85 @@
+# Réunion du Collège Technique
+
+* Date : le jeudi 3 septembre 2015
+* Lieu : Pavillon des Jardins
+* Début : 19h00
+* Fin : 20h13
+
+## Présents
+
+* Gabriel Detraz
+* Daniel Stan
+* Lucas Serrano
+* Raphael David Lasseri
+* Emmanuel Arrighi
+* Myriam Begel
+* Hamza Dely
+* Charlie Jacomme
+* Jordan Delorme (arrivée à 19h29*)
+* Pierre Elliott Bécue (idem)
+* Ariane Soret (arrivée à 19h15)
+* Nombreux nouveaux adhérents
+
+## Ordre du jour
+
+### Intranet
+
+La restylisation est finie ! Que faire maintenant ? (traductions ? gest_crans ?)
+Lucas a changé le style de l'intranet et a fait en sorte qu'il s'adapte Ã
+toutes les résolutions d'écran. Il nous montre la structure des différentes
+parties et fait un topo sur les bonnes pratiques à avoir.
+
+Il a retravaillé les templates, et surtout les classes css.
+
+Il mettra les slides sur le wiki.
+
+### Gest_crans
+
+Présentation de gest_crans aux adhérents peu familier de cet outil. On présente
+également quelques nouvelles features, en particulier les factures et
+l'impression de tickets.
+
+C'est un vieux code qui va devoir être réécrit car il est assez dur Ã
+comprendre. PE se propose pour commencer un squelette pour qu'ensuite tout le
+monde puisse travailler dessus.
+
+### Mises à jour Debian
+
+https://wiki.crans.org/CransTechnique/AdminSyst%C3%A8me/DistUpgrade
+Les mises à jour avancent mais il en reste un paquet à faire. Les intéressés et
+surtout les nouveaux peuvent sonner une nounou pour en faire. De nombreux
+serveurs peuvent en effet être coupés sans interruption de services pour les
+adhérents et peuvent donc être mis à jour n'importe quand !
+
+### Séminaires
+
+https://wiki.crans.org/CransTechnique/CransApprentis/SeminairesTechniques/2015-2016
+Raphaël rappelle le principe des séminaires jusqu'à maintenant et propose une
+nouvelle organisation.
+
+#### Refonte
+
+Cf mail @nounous
+
+Tilgaht propose 4 séminaires de bases : Shell/SSH - Cr@ns - Réseau - Python.
+Cela permettrait d'avoir les bases pour commencer à travailler vraiment.
+
+Les séminaires seraient ensuite plus orientés workshops pour que les gens
+soient actifs.
+Il pourrait également y avoir des workshops plus personnalisés avec 1 nounous
+pour 3 apprentis par exemple.
+
+Pour ne pas casser les séminaires ouverts à tous, il pourrait y avoir un
+séminaire grand public par mois sur des thématiques plus ou moins techniques
+mais un peu plus déconnecté du Cr@ns.
+
+PE pense qu'il serait pertinent de faire un séminaire GNU/Linux avant le
+séminaire Shell/SSH.
+
+L'install Party sera organisée le week-end du 26-27 septembre (malheureusement
+en même temps que le K-WEI). Le 1er séminaire aura donc lieu le mardi qui suit.
+Prenez note !
+
+### Nomination de nounou
+
+Hamza Dely est nommé nounou, bravo à lui !
diff --git a/compte_rendus/2015_09_17.md b/compte_rendus/2015_09_17.md
new file mode 100644
index 0000000000000000000000000000000000000000..71de294300d1c73d6072f24e6db1e4ed51cb0f7e
--- /dev/null
+++ b/compte_rendus/2015_09_17.md
@@ -0,0 +1,154 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 17 septembre
+* Lieu : Pavillon Des Jardins
+* Début : 19h00
+* Fin : 20h30
+
+## Présents
+
+* Lucas Serrano
+* Gabriel Détraz
+* Myriam Begel
+* Emmanuel Arrighi
+* Mathilde Espinasse
+* Rémi Oudin
+* Aliaume Lopez
+* Hamza Dely
+* Martin ??
+* Pierre Elliot Bécue
+
+## Ordre du jour
+
+### Aménagements 4J
+
+On a racheté un onduleur en urgence (voté en CA) suite aux problèmes de
+disjoncteur.
+L'onduleur est manageable en ethernet (quasar.adm.crans.org).
+
+La clim est hors circuit de l'onduleur, car trop gourmande. Vu son état, il
+serait temps de la changer.
+
+Cahier des charges :
+
+* mémoire (reprise du mode d'avant coupure)
+* mettre l'accent sur le coté déshumidificateur (pour le papier)
+
+Quid également du digicode et clés 4J ?
+On va proposer un devis pour changer le canon de la deuxième porte (trop de
+clés perdues).
+
+### Kfet
+
+Le panneau de brassage ainsi que la boîte sont arrivés. Mais c'est plus lourd
+que prévu. On regarde avec un membre du bde pour faire une installation
+raisonnable (mur en plâtre). On attend de ses nouvelles lundi ou mardi.
+
+Concernant le switch PoE, on ne connait pas pour l'instant les besoins exacts
+du bde, en nombre de caméras/câbles à tirer.
+Lors du dernier CA, l'achat du switch a été repoussé, dans l'idée d'acheter du
+matériel plus récent compatible PoE gigabit. Finalement, vu le peu de nouvelles
+et l'usage prévu (bornes + camera), un 100Mbit/s PoE
+paraît un bon compromis niveau prix.
+
+En attendant, on a installé un 100Mbit/s non poe. Switchs2.py a été mis à jour
+pour gérer les prises, depuis la base de données (et aussi générer un schéma de
+câblage.)
+
+Une deuxième borne (unifi simple) a été rajoutée, suite à des problèmes lors de
+l'entrée pot et les deux bornes sont désormais fixées "solidement" dans le mur.
+
+### FreeRadius
+
+Gabriel et Daniel ont corrigé le problème de segfault sous jessie. Plus
+exactement, il n'est plus possible d'instancier plusieurs fois le module
+python (cela mène à un segfault.)
+
+Il faut aussi reporter le bug. On peut donc entamer les mises à jour des
+serveurs radius restants, c'est-Ã -dire radius puis, si tout se passe bien, eap.
+
+Aliaume est partant pour un dist-upgrade ! \o/ Rémi aussi si besoin !
+
+### Ticketteuse
+
+Beaucoup de cafouillages ces derniers temps. Hamza vient d'en refixer une à la
+kfet. Les mots de passe ont été mis dans cranspasswords, cette fois.
+Il reste à mettre la clé ssh (pour la déchiffrer) quelque
+part : dans /etc/crans/secrets (et ultérieurement dans cpasswords ?).
+
+La deuxième ticketteuse marche mais la carte SD n'est pas encore chiffrée, et
+il faut lui trouver un nouveau boitier.
+
+### Intranet
+
+Gabriel montre sa nouvelle feature d'édition de .forward.
+Quelques probs de compte/impressions ces derniers temps.
+(cf commits d'aujourd'hui.)
+
+Lucas n'est pas très fan de l'édition arbitraire du .forward. Il préférerait
+avoir une option pour rentrer un champ mail.
+
+Attention : réorganisation imminente du dépôt suivant les versions récentes de
+django.
+Lucas et Daniel vont s'occuper du déplacement des dossiers et fichiers,
+attention aux merges !
+
+### Asterisk
+
+La machine virtuelle "asterisk" va mal. Il a été proposé de recommencer une
+installation à partir zero. Pour info, ce serveur héberge un
+programme "asterisk"
+fournissant un service de voip (protocole sip) aux adhérents.
+
+Ce serait donc l'occasion de faire le ménage et d'en apprendre plus sur la voip.
+
+Plusieurs projets apprentis :
+
+* Créer une vm en compagnie d'une nounou (idefisk)
+* Examiner la conf d'asterisk et la cloner (idefisk)
+
+On remet à plus tard, mais si quelqu'un veut bien s'y pencher, qu'il fasse
+signe ;)
+
+### Impression
+
+Cela fonctionne mieux, mais ça cafouille quand quelqu'un lance une grosse
+impression, la file d'attente est bloquée. Il faut implémenter la gestion de
+file avec des ordonnanceurs.
+Cela se passe sur le serveurs {{{cups.crans.org}}}.
+
+Gabriel a rajouté une info sur le statut de l'imprimante sur l'intranet.
+
+Liste de projets (éventuellement pour apprentis) :
+
+* Permettre les impressions de plusieurs fichiers en même temps (projet django)
+* Imprimantes virtuelles sur cups (cf slides) (+ écriture de deux ordonnanceurs)
+* Écrire un nouveau printer_watch qui prévient des pannes de l'imprimante.
+
+### Questions diverses
+
+#### Tracker
+
+Le tracker.crans.org. Quid du truc de FedeRez ? Ie phabricator ? On essaie
+d'installer ça.
+
+On a potentiellement d'autres adhérents intéressés (la sauce par ex).
+
+#### VM Inutiles
+
+* Discourse -> On garde un peu, histoire de voir si le CA est prêt à faire de
+ la comm' là -dessus. Il faut voir si on est motivé pour un nouveau web news
+ pour essayer de redynamiser les news.
+* Tracker ? -> On efface ? Ça ne marche clairement pas, faisons le ménage dans
+ les tickets puis on le vire (comme ça, pas d'upgrade à gérer).
+
+#### Local de brassage du -1I
+
+La clé du -1I semble avoir été changée, une nouvelle fois, et nous n'avons pas
+été prévenu. On ira voir le Crous dès que possible (demain matin).
+
+[Mise à jour du vendredi 18 : le technicien crous nous a donné la nouvelle clé]
+
+#### Slides
+
+[[attachment:adaptations-de-freeradius-pour-debian-jessie.pdf]]
diff --git a/compte_rendus/2015_10_01.md b/compte_rendus/2015_10_01.md
new file mode 100644
index 0000000000000000000000000000000000000000..b23cb9d0cf4fcad2ebe56c6b988d3e1efd0f74c5
--- /dev/null
+++ b/compte_rendus/2015_10_01.md
@@ -0,0 +1,116 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 1er octobre 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h13
+* Fin : 20h05
+* <<Pad>>
+
+## Présents
+
+* Mathilde Espinasse
+* Hamza Dely
+* Aliaume Lopez
+* Rémi Oudin
+* Aurélien Pascal
+* Lucas Serrano
+* Daniel Stan
+
+## Ordre du jour
+
+### Mailman
+
+Pleins de bounces ce mois-ci. On a signalé à l'ENS que notre serveur n'est pas
+considéré de confiance par le relai renater, ce qui est problématique... On a
+aussi contacté laposte.net pour qu'ils arrêtent de filtrer nos mails.
+
+PEB proposait de ne plus envoyer de rappel mensuel. On pense tous que c'est
+inutile (le rappel) donc ok, c'est fait.
+
+Il faut se pencher aussi sur dkim, aussi.
+
+### Sens de l'art
+
+Aurélien souhaite pour les sens de l'art d'avoir une vm pour héberger le site
+web des sens de l'art. Vu la maintenance
+nécessaire, on envisageait de faire pot commun avec le gala qui a déjà un
+système du genre pour la dernière édition. En
+l'absence de réponse du gala, on va faire comme ça (accord de principe du
+gala.) Le site promotionnel sera en place
+d'ici jeudi prochain (pour la soirée associée).
+
+Les sda, c'est du 24 au 29/11.
+
+Reste le choix la méthode de paiement… Mais c'est le staff sda qui va s'en
+occuper.
+
+### Parefeu
+
+On a commencé à regarder le parefeu. Hamza va nous en parler plus.
+Voici un plan (cahier des charges prévu) : http://pad.crans.org/p/FirewallNew
+
+Reste à s'occuper des limitations de débits.
+
+### Intranet
+
+Daniel a commencé à réoganiser les dossiers pour être compatible avec les
+nouvelles normes de Django sur le rangement des apps.
+Ça a l'air de fonctionner et de merge sans trop de problème. Cf
+branche "reorganisation" sur le gitlab pour ceux qui sont
+curieux.
+
+Ping a commencé à écrire des fonctions pour les template (templatetags). To be
+continued.
+
+### Impression
+
+Charlie s'est occupé de proprifier la gestion de l'impression au Crans. (Il
+n'est malheureusement pas présent pour en parler)
+
+{{{
+22:25:03 Charlie | Nounou : vu qu'il y a Internounou demain, petit résumé de
+nos expériences sur cups avec Jordy :
+22:25:15 Charlie | Actuellement le système d'impression est tel que suit :
+22:25:17 Charlie | 1)l'intranet fait un "lp", qui met le job en queue sur o2.
+22:25:19 Charlie | 2) cups_o2 envoie les jobs de sa queue 1 par 1 Ã
+cups_cups (il se comporte comme si cups_cups était une imprimante)
+22:25:21 Charlie | 3) cups_cups envoie les jobs à l'imprimante
+22:25:23 Charlie | Parfois, des jobs fail sur la queue de cups_cups avec
+l'exception "Exception: operation for Array object attempted on object of wrong
+type" d'origine inconnu. Cependant, cups_cups ne dit pas à o2 que le job a
+fail. Du coup, cups_o2 attend
+| indéfiniment la fin de la tache envoyé et n'envoit plus aucun jobs Ã
+cups_cups.
+22:25:25 Charlie | Une première chose que je propose est de supprimer
+l'intermédiaire cups_o2 avec la proposition de daniel : mettre un client.conf
+contenant "ServerName 10.231.136.50:631". Tester sur vo, ça marche bien, lors
+de "lp" ou "lpstat" tout se passe comme si
+| on était sur cups_cups.
+22:25:27 Charlie | Par ailleurs, on a aussi testé avec Jordy de dupliquer
+l'imprimante MFPM880 et de mettre les deux dans une classe. Cela nous a permit
+de découvrir que le job qui buggé précédement bug sur une seul des deux
+imprimantes. Oui, alors que c'est la même
+| imprimante la même conf copié collé. cf le printers.conf de vo, si quelqu'un
+arrive à élucider ce mystère.
+22:25:29 Charlie | Enfin, on sait pas pourquoi ça bug, mais dupliquer x fois
+la conf de l'imprimante et créer une classe semble être une solution. »
+}}}
+Bref, si des personnes sont motivées pour regarder avec Charlie et Jordy …
+
+Léo Colisson est partant pour se pencher sur le monitoring de l'imprimante en
+snmp.
+
+### Questions diverses
+
+#### Guinness is good
+
+Un ancien membre actif a exprimé sa haine d'Apple sur l'ordi d'un nouveau
+membre actif. Ils sont a priori en train de lancer une procédure auprès de son
+assurance, mais le Crans (de par son assurance) prendra en charge si ça se
+passe mal avec l'assurance dudit ancien membre actif.
+
+#### Séminaire
+
+"Techniquement" ça se passe mardi prochain. C'est Daniel qui présentera le
+réseau et les services du Crans.
+Au condorcet à 19h avant le pot.
diff --git a/compte_rendus/2015_10_15.md b/compte_rendus/2015_10_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..26022c2b5a8e694eb8a9c4efd7863898b81cf27d
--- /dev/null
+++ b/compte_rendus/2015_10_15.md
@@ -0,0 +1,141 @@
+# Réunion du Collège Technique
+
+* Date : 15 octobre 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h06
+* Fin : 20h34
+* <<Pad>>
+
+## Présents
+
+* Charlie Jacomme
+* Hamza Dely
+* Mathilde Espinasse
+* Vincent Le Gallic
+* Rémi Oudin
+* Aliaume Lopez
+* Lucas Serrano
+* Daniel Stan
+* Jordan Delorme en duplex de chez le doc (merci)
+* Emmanuel Arrighi
+* Pierre-Elliott Bécue (depuis son super réseau LTE à Bordeaux)
+
+## Ordre du jour
+
+### Intranet
+
+Chirac a « dumpé sur la gueule » de Charlie le projet intranet câblage. Ce
+dernier se pose tout de même des questions sur le cahier des charges.
+
+Premier objectif : un câblage comme sur gest_crans, on verra plus tard pour les
+pré-adhésions et cie.
+
+Autre problème, on trouve que c'est trop facile d'accéder à l'appli câblage
+pour une personne mal intentionnée qui aurait accès à l'intranet d'un MA.
+Deux solutions : soit faire un autre projet django, soit faire un
+mode "admin" où le MA doit retaper son mot de passe au début.
+Charlie souligne également que le problème existe également sur les pages
+d'admin de l'intranet.
+
+Daniel a fait un script pour pouvoir faire fonctionner l'intranet sur sa
+machine perso. Il s'appelle testing.sh et se trouve dans /usr/scripts.
+Il en fait démonstration à l'audience.
+
+On a présenté deux trois modifs de la branche reorganisation, ça semble
+convenir à tout le monde. [à détailler]
+
+Ping a présenté sa nouvelle appli de surveillance de l'imprimante, via snmp.
+
+### Séminaires
+
+La semaine prochaine (20/10/2015), séminaire shell, par Pauline. On le coupe en
+deux parce que c'est quand même un gros morceau et qu'on veut le faire en
+interactif (s'arrêter de faire défiler plein de slides pour laisser tout le
+monde pianoter sur son terminal).
+Donc le tome 2 sera après les vacances (le 2/11, à confirmer).
+
+### Phabricator
+
+* Présentation de l'avancement du projet
+* Définition d'un cahier des charges
+
+https://phabricator.crans.org (à ouvrir de l'extérieur) [ça marche pas de
+l'extérieur]
+
+### Pose de borne WiFi bâtiment A
+
+Le WiFi dans le bâtiment A semble ne pas couvrir de nombreuses chambres en fin
+de couloir.
+
+Les chambres du fond ne captent pas. Emmanuel est motivé pour tirer des câbles,
+si c'est le cas, on voit pas de soucis à racheter des AP.
+Il y a aussi un projet de routeur d'appoint dans les chambres qui est resté en
+suspend. Avis à volontaire (quelles tâches sont nécessaires ?)
+
+Il y a des problèmes pour capter à l'entrée du pot, on envisage d'échanger les
+deux AP ou sinon de changer le ssid tous les mardi soirs le temps du pot pour
+ne laisser que les membres bde connectés.
+
+Ping propose de monitorer beaucoup plus de paramètres sur munin (débit de
+synchro, pertes de paquets).
+Autre projet : passage à CC sur les points d'accès.
+Pour l'un comme pour l'autre, avis à apprentis motivés.
+
+### Projet virtualisation
+
+Un apprenti est motivé pour s'investir dans la virtualisation. Pierre-Elliott
+est motivé pour l'encadrer. Il voudrait donc relancer l'idée d'acheter un
+virtualiseur,
+dans le but d'avoir une infra avec deux machines récentes et puissantes, fz,
+qui tient bien la route, et soit d'enlever kdell pour l'utiliser à autre chose,
+soit le
+garder dans le cluster.
+
+On vise un truc de l'ordre de ft, et on retire kdell.
+
+Il est évoqué de migrer les services de sable (DNS master) qui n'est plus sous
+garantie, soit sur kdell, soit sur une vm.
+
+L'idée est aussi que si les CPU se tournent régulièrement les pouces, la RAM
+est belle et bien consommée, donc on est large, mais pas ultra large. On ne
+sait pas combien. ft: 12/32Go de RAM.
+fz: 12/16Go de RAM
+kdell: 16/16Go
+On voit sur 16Go de RAM.
+
+On va également renouveler la garantie de fz.
+
+### Machine pour FedeRez
+
+Pierre-Elliott avait pour projet de proposer que le Crans achète un serveur, et
+en fournisse gratuitement l'accès à FedeRez. L'idée est que leurs besoins en
+espace de stockage est relativement élevé, et finalement, outre deux VM,
+FedeRez ne dispose que d'un serveur en location chez OVH. Avoir un serveur
+dédié physiquement accessible dans une des assoces adhérentes ne serait
+peut-être pas si mal.
+En particulier, il y a un manque de redondance dans le stockage des données.
+FedeRez va contacter les autres associations pour savoir ce qui pourrait se
+faire en termes de redondance.
+
+Ils veulent : "some stuff". Pour l'instant, on s'oriente sur sable (une fois
+qu'il sera migré).
+
+Un grand merci de la part de FedeRez.
+
+### Questions diverses
+
+#### Année et établissement d'étude dans la BDD
+
+L'année d'étude n'est pas utile, on pense jamais, ni la section (et ce n'est
+jamais normalisé). Si quelqu'un veut bien les retirer, il est le bienvu.
+L'établissement est le seul qui peut vraiment servir, on le garde.
+
+Petit ménage à faire (plus utile) :
+
+* Virer l'attribut paiement
+* Cartes d'étudiants
+
+#### Switchs
+
+FedeRez a reçu une propositon de don de switchs Gigabit. Ils seraient gratuits
+modulo les frais de ports. Il faut voir avec la datasheet.
diff --git a/compte_rendus/2015_11_12.md b/compte_rendus/2015_11_12.md
new file mode 100644
index 0000000000000000000000000000000000000000..d5f6f8ee07f4a152dd63a5483a9a08ee1ca653f4
--- /dev/null
+++ b/compte_rendus/2015_11_12.md
@@ -0,0 +1,175 @@
+# InterNounou
+
+* Date : 12 novembre 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h06
+* Fin : 20h30
+
+## Présents
+
+* Anne Cazalet
+* Pierre-Elliott Bécue
+* Gabriel Detraz
+* Hamza Dely
+* Myriam Bégel
+* Mathilde Espinasse
+* Rémi Oudin
+* Magalie Vetter
+* Adam Heriban
+* Jonathan Cailliez
+* Jordan Delorme
+* Vincent Le Gallic
+* Emmanuel Arrighi
+
+## Ordre du jour
+
+## Point sur les problèmes d'ambiance au CT
+
+Daniel a souhaité revenir sur le mail émanant d'une membre active sur
+nounou@ qui dénonçait des attitudes sexistes et
+transphobes au sein du collège technique. Il s'est excusé pour cette ambiance
+délètere dont il est responsable.
+Un ancien membre actif lui a transmis une synthèse de textes de loi concernant
+ces agressions ainsi que les peines
+encourues. Il n'est évidemment pas pertinent d'en arriver à se retourner
+judiciairement contre nos membres actifs,
+mais une analyse rapide nous montre que les comportements décrits dans le mail
+initial sont assimilables à du
+harcèlement sexuel, tel que défini dans la loi. Ainsi, nous ne pouvons que
+confirmer la gravité des situations
+qui y sont décrites.
+
+Gabriel a rappelé qu'un projet de code conduite, dont la forme (charte, texte
+séparé), est en cours d'étude
+par Mathilde et Rémi (cf dernière réunion CA). Même si le collège technique
+n'est pas habilité à mettre en place ce texte, il est important
+qu'il exprime son avis. Daniel pense que ce projet est une bonne idée,
+notamment parce qu'il permet de fournir
+une base saine, qui facilitera la dénonciation des attitudes inacceptables. De
+plus, les exemples de codes
+de conduite proposés (Julia, Rust, FreeBSD) lui semblaient adaptés.
+
+## Propositions concernant les séminaires
+
+On rappelle aux nounous, mais aussi au public en général qu'il faut être
+civilisés et lever la main avant de poser une
+question ou introduire une remarque plutôt que d'interrompre l'orateur.
+Idéalement, on pourrait proposer un chairman, chargé de distribuer les
+questions et protéger le temps
+de parole. De plus, il est facilement envisageable de nommer un responsable
+différent à chaque séminaire.
+
+Au niveau de l'organisation générale des séminaires, il s'est avéré que les
+deux volontaires en début d'année
+n'ont que trop peu de temps pour pouvoir en consacrer à cette tâche. Lucas
+Serrano (absent lors de la réunion)
+semble cependant motivé pour prendre la relève et encadrer tout cela.
+
+Côté thématiques :
+Est-ce qu'on commence à faire des workshop en parallèle des séminaires pour
+avoir davantage de pratique ?
+Certains apprentis présents ont exprimé leur volonté de réaliser des projets et
+d'appliquer d'avantage leur
+connaissance.
+
+On prévoit les activités ci-dessous pour les jours qui suivent :
+
+* Samedi aprem/soir : MÃ j pgsql (thot)
+* Dimanche : workshop virtualisation
+* Mardi : bornes WiFi et passage à CC (format workshop) par Gabriel
+* Mardi prochain (en 8) : enchaîner sur un vrai séminaire. Certains sont déjÃ
+ prêts (impressions, git, python 2, etc)
+
+Pour le reste, il y a phabricator qui recense des tickets de projet en cours,
+et nous encourageons les apprentis
+à contacter une/des nounous pour se lancer dans la résolution d'un ticket qui
+leur semble intéressant.
+
+## Évolution du conseil technique
+
+Charlie est promu nounou. Félicitations.
+
+Daniel commence à se trouver un peu vieux pour assumer le poste de RTC.
+Aux jeunes d'en discuter entre eux et avec les vieux, avec Daniel... On fait le
+point dans deux semaines.
+
+Parmi les projets, on a également envie de faire un script pour enlever les
+droits aux vieilles nounous, afin
+de ne pas laisser des failles potentielles au nom de gens qu'on ne connait même
+plus. L'idée est qu'ils
+pourraient, en cas de besoin, se redonner les droits (typiquement sudo
+give_me_back_my_rights qui serait
+dans le sudoer file, ou un accès au mot de passe root).
+
+## Câblage sur l'intranet
+
+Développée par Charlie et Chirac, l'app est en beta.
+Il reste deux trois petits trucs à régler notamment la cosmétique (logo), et
+les gestions des droits django/ldap.
+Les fonctionnalités supportés sont grosso-modo ce que les câbleurs peuvent
+faire depuis gest_crans.
+
+Gabriel est chaud pour gest_crans_lc. On émet des réserves quant à sa
+maintenabilité. On essaie de
+mettre gest_crans_lc en default pour les cableurs (avec possibilité d'utiliser
+l'ancien).
+
+## Monitoring
+
+Les services sur fy ne sont pas maintenus. Quelle fiabilité attend-on du
+monitoring ?
+
+## Phabricator
+
+Phabricator (tracker.crans.org) est ouvert à tous. Hamza se demande comment
+gérer les projets ouverts par les autres.
+Daniel est d'avis de laisser chaque propriétaire s'occuper de sa gestion, sans
+ingérance.
+
+Il reste à faire de la comm' autour de ce service (sur l'intranet, la
+sauce, … ?) ;) ;)
+
+## Mise à jour de thot (pgsql)
+
+DU programmé samedi, de nombreuses personnes ont fait part de leur intérêt
+suite au mail de Chirac sur nounous.
+(Laloutre, Jack, Mathilde, Rémi)
+
+http://pad.crans.org/p/thot
+
+PE a un projet de plus longue date pour une page de status.
+
+## VM BdE
+
+Toujours dans le but de réduire le nombre de machines entreposées dans le local
+serveurs BdE, Hamza voudrait savoir si le Crans pouvait héberger une nouvelle
+VM pour remplacer le serveur de test du BdE (mail du 23/10 sur nounou).
+
+Il veut ~15-20 Go de disque dur, 1 Go de RAM, 1 cœur. L'usage prévu est
+principalement le développement de la note et autres projets BdE (digicode ...).
+
+C'est acté.
+
+## Questions diverses
+
+### Future webradio
+
+Freq[ENS], nouveau club webradio voudrait demander une VM et diffuser une
+webradio vers l'extérieur (donc ouverture de ports, upload).
+Daniel suggère d'utiliser OVH, qui est déjà hors campus, si on a des problèmes
+d'upload.
+
+Pierre-Elliott rappelle que le maintien d'une VM est à la charge du club.
+
+### Agreg EEA
+
+Il y a du GNU/linux et réseau au programme de l'agreg EEA depuis cette année.
+Adam souhaiterait savoir s'il y a moyen de faire des séminaires de rattrapage
+sur ces
+domaines pour ceux qui sont déjà largués en cours. Les slides sont déjà là ,
+donc il y a toujours moyen que des nounous refassent les présentations avec un
+effort peu important.
+
+On demande à ce que les questions déjà posées aux agregs précédentes nous
+soient fournies et que les EEA se mettent d'accord pour un créneau horaire.
+Adam s'en charge.
diff --git a/compte_rendus/2015_12_03.md b/compte_rendus/2015_12_03.md
new file mode 100644
index 0000000000000000000000000000000000000000..d7ef6cc4b8f32cfeaf5b5b79dd388a47ac24fb68
--- /dev/null
+++ b/compte_rendus/2015_12_03.md
@@ -0,0 +1,198 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 3 décembre 2015
+* Lieu : Pavillon Des Jardins
+* Début : 19h12
+* Fin : 20h47
+* <<Pad>>
+
+## Présents
+
+* Hamza Dely
+* Charlie Jacomme
+* Vincent Le Gallic
+* Rémi Oudin
+* Daniel Stan
+
+## Ordre du jour
+
+### Beta let's encrypt
+
+Vo utilise maintenant un certif let's encrypt, tout semble fonctionner.
+Cependant, tout n'est pas encore packetté dans Debian stable. On pourrait
+essayer d'attendre les backports.
+
+Une fois le certif en place, il faut ensuite peupler la base ldap. L'idée
+serait de le faire par cron, juste après une exécution de letsencrypt (ou dans
+un plugin shell) pour mettre à jour la base (et donc tout ce qui est en dépend,
+genre les dns).
+
+C'est un bon projet pour apprentis. Featuring : LDAP ("base de données" du
+Crans) et son binding au Crans {{{lc_ldap}}}, Python (langage de scripts), SSL
+et génération de certificats, cron (exécution planifiée de taches périodiques).
+
+On verra plus tard pour le déploiement sur le WiFi. Idéalement, on peut
+commencer à tester déjà sur FedeRez-WiFi.
+
+### Intranet (câblage)
+
+Tout semble traité ici :
+http://pad.crans.org/p/cablage_lc
+Nous avons mis en place le full-login, pour l'instant ça semble marcher, modulo
+timeout (à creuser), et la couleur, qui déplaît à 20-100.
+
+Il faut que le bouton full-login soit plus visible, et mettre un message pour
+prévenir les users membres actifs.
+
+* Rendre la page de statut de l'imprimante accessible pour tous
+* Ajouter la gestion des imprimeurs et du respo club depuis le menu club.
+* Une fois que c'est traité, on se lance dans une beta sur l'intranet de prod
+
+### Gest_crans_lc
+
+Toutes les fonctions de gest_crans ont été portées (même impression de ticket),
+Ã l'exception de la gestion des clubs.
+
+C'est dans la tdl de Chirac.
+
+http://pad.crans.org/p/cablage_lc
+
+Merci de faire remarques et bug report ici. Il faut finir vite la gestion des
+clubs (!).
+
+* Peut-être un problème de gestion des mails ext (?).
+
+### Routeur fail-over
+
+Le principe : cf schéma tableau du 2B
+
+[[attachment:IMG_0996.jpg]]
+## ^--- Y U NO HORIZONTAL PHOTO ?
+
+Keepalived permet de partager une Ip sur 2 machines .
+
+Chirac a testé ce week end. L'idée est que la gateway annoncée par les dhcp ne
+soit plus 138.236.136.4 ou .148.4 mais 136.19.
+
+Cette ip serait partagée entre komaz et odlyd, avec odlyd en master et komaz en
+backup.
+Par défaut, odlyd possède l'IP 136.19. Si il tombe, le daemon keepalived de
+komaz s'en aperçoit, et komaz prend l'IP 136.19, donc devient la gateway.
+
+Le problème principal concerne quagga, il faut éviter que les 2 routeurs
+annoncent les mêmes routes sur zrt (OSPF, les routeurs de ZRT annoncent les
+routes, et on est les seuls a part la dsi a en avoir 2...), pour éviter du
+shitstorm.
+
+La doc quagga suggère de faire un système où quagga n'est lancé que sur le
+routeur master :
+
+http://wiki.kogite.fr/index.php/Quagga:_installation-paramétrage#Failover_avec_keepalived_.28vrrp.29
+
+NB : ici ca concerne BGP mais c'est pareil avec OSPF.
+
+Questions :
+
+* On propose d'utiliser 138.231.136.6 (tchu-pi, il peut sauter) ou
+ mieux : 138.231.136.254 (qui est plutôt canonique, (dernière IP du slash *des
+ serveurs*))
+* Comment keepalived de komaz détermine que odlyd est "tombé" ?
+
+. Les 2 keepalived se parlent via leurs IP adm. À creuser pour savoir comment
+ils diagnostiquent le "c'est tombé".
+
+* Comment ça se passe quand il ressuscite ?
+
+. Soit le ressuscité reprend la main, soit il reste en attente jusqu'à ce que
+l'autre tombe.
+
+* On suggère de brancher titanic en 3ème routeur de fallback pour la connexion
+ de secours.
+ * Ça permettrait de se passer du {{{secours.py}}} de sable qui teste la
+ connectivité vers l'extérieur. Quand elle lâche, il prévient les autres
+ serveurs (via le NFS). Effet : odlyd redirige le trafic HTTP vers
+ titanic (proxy); sur les DNS, ça a pour effet qu'ils envoient leur
+ requêtes DNS à titanic et non plus via leur gateway habituelle.
+
+. Attention, le {{{secours.py}}} de soyouz pour relancer le VPN via freebox et
+non plus la connexion ENS reste nécessaire.
+
+* Comment ça se passe pour la priorité des routeurs ? Ça se règle dans la conf
+ de keepalived.
+* Penser ajouter un firewall sur titanic qui bazarde tout sauf le HTTP.
+ Attention aux connexion SSH entrantes '''prioritaires''' pour les nounous.
+* Modéliser cela sur marionet
+* Faire ses tests dessus
+
+Autre système de secours (orthogonal au problème précédent) : mettre une patte
+ipv6 aux serveurs sur le vlan de la freebox.
+
+### Machine virtuelle Frekens
+
+Le club Frek[ENS], fraîchement créé, voudrait mettre en place une webradio, et
+demande pour ce faire à créer une webradio.
+
+À faire :
+
+* Inscrire Frek[ENS] en tant que club Crans
+* Mettre en place le !WordPress (ou whatever) sur la page perso du club
+* Si un jour, le club veut se mettre à faire du podcast, on rediscutera
+ ouverture de ports
+* Si l'install de wordpress est impossible/trop compliquée sur les pages perso,
+ on peut envisager de créer une vm
+
+Se pose le problème de dissociation du quota d'upload, a priori, on ne sait pas
+quelle quantité d'upload sera générée. On avisera si l'upload de zamok explose,
+sachant qu'il est toujours possible de savoir quel est le trafic généré par une
+page perso via les logs apache.
+
+### Séminaires
+
+Suite au sondage à la fin du dernier séminaire, il y a des demandes pour un
+workshop Python orienté objet, LDAP théorique, LDAP pratique.
+A priori, Ping serait motivé pour faire un atelier mardi sur python orienté
+objet.
+Chirac voudrait faire un atelier {{{lc_ldap}}}.
+Daniel propose de faire une présentation des scripts du Crans sous forme
+d'atelier le 15/12 et expliquer comment on peut faire pour bidouiller chez soi.
+
+### Virtualisation
+
+Stitch est racké. Il est branché à la baie (prendre une IP différente de celle
+des autres virtualiseurs, c'est mieux).
+Ils vont tester proxmox 4, la migration de vm et le grub-install.
+
+### VM pour l'Ares
+
+L'ARES (Association Réseaux Enfaitonensaitrien Saclay), nouvellement fondée,
+demande une VM.
+
+Usage :
+
+* site internet
+* serveur mail
+* archive (de quoi, on ne sait pas trop…)
+* accès ldap centralisé (projet)
+
+Entre 6 et 10 Go d'espace disque, 256-500 Mo de ram et 1 cœurs devraient
+suffire.
+
+On tranche sur 8 Go de disque et 512 Mo de RAM.
+
+### Question diverses
+
+#### Routeur
+
+Il a plus de RAM ou… c'est autre chose ?
+
+#### Nols
+
+Maintenance pendant les vacances de Noël ?
+
+#### Crans Vacances
+
+Remplir la page wiki !!
+
+#### RTC
+
+Charlie veut bien prendre la succession.
diff --git a/compte_rendus/2015_12_17.md b/compte_rendus/2015_12_17.md
new file mode 100644
index 0000000000000000000000000000000000000000..e741592e69176299551d1f848248ca59004ec4eb
--- /dev/null
+++ b/compte_rendus/2015_12_17.md
@@ -0,0 +1,127 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 17 décembre
+* Lieu : Pavillon Des Jardins
+* Début : 19h15
+* <<Pad>>
+
+## Présents
+
+* Myriam Begel
+* Rémi Oudin
+* Daniel Stan
+* Charlie Jacomme
+* Hamza Dely
+
+## Ordre du jour
+
+### Icinga
+
+Pour remplacer autostatus qui est vieux, moche et à un certain nombre de
+limitations, dely a mis en test Icinga (icinga2.crans.org).
+C'est un service de monitoring qui possède déjà un bon nombre de plugin
+préexistant (hpjd pour l'imprimante, backuppc, proxmox), les plugins pouvant
+s'écrire à la main en python comme pour munin. De plus, les plugins nagios sont
+compatibles.
+
+Icinga permet de redémarrer depuis le site de rédémarrer des services, d'où les
+login required.
+
+* Munin met en place automatiquement pour un serveur tout ce qu'il faut, est-ce
+ qu'icinga peut faire pareille ?
+
+On vise un déploiement des fichiers de conf pour chaque host grâce à bcfg2.
+
+Il faudra mettre une tache sur phabricator et voir qui est intéressé.
+
+### Mise au point DU
+
+On a actuellement deux cluster proxmox différents avec uniquement stitch sous
+jessie.
+On envisage de migrer les autres virtualiseurs, en prenant soin à chaque fois
+d'être sur que le serveur migré marche avant de toucher aux autres.
+Daniel doute de la pertinence de faire d'autres migrations vu l'état des
+migrations déjà en cours et jamais finies (cochon).
+
+On envisage de tenter de migrer fz à la rentrée, une fois que cochon sera
+rétabli (cf point suivant)
+
+### Cochon
+
+Il faut tenter de compiler un noyau jessie à la main. Si ça échoue, on remet
+sous wheezy.
+
+### Il faut sauver le soldat Odlyd (Routeur Fail-over)
+
+Daniel propose de profiter de la coupure lundi prochain pour un memtest. Si il
+y a du monde pour aider, il testera avant si le routeur fail-over fonctionne
+bien.
+On a par ailleurs vu un comportement bizarre au niveau du scheduler, mais pas
+d'explications. Si le memtest voit le problème, on renvoit la barette à HP.
+La carte réseau aurait aussi des problèmes sur munin... (cable foireux ?)
+
+Sinon ? On verra le cas échéant.
+
+### Firmware update de Nols
+
+Charlie est possiblement chaud pour une maintenance la deuxième semaine, si
+d'autres personnes sont présentes ?
+Si Daniel se motive et qu'il y a plus de nounous, peut-être lundi
+prochain (21/12) Ã midi.
+On envisage aussi de swapper les disques de 300Go et de 600Go.
+
+### Modules de generate avec lc_ldap
+
+Il faut profiter de la migration pour repenser les scripts et leur refaire une
+beauté et pas se contenter d'un copié collé basique.
+On va créer une branche git pour faire tout ça.
+
+### whos_lc
+
+Un certains nombre de différence d'utilisation existe par rapport au précédent,
+la mise en prod aurait mérité une discussion.
+Lors d'un changement de script, une bonne idée est de mettre une disclaimer
+dans le script lui même.
+On s'interroge sur la confidentialité de la chambre ? Si l'utilisateur est en
+chambre invalide, que ce passe-t-il ?
+
+Il faudrait dire que le numéro de tél et l'adresse sont censurés sur
+l'affichage normal, pour pas qu'on perde 5 min à les chercher.
+
+### Demande de transfert des ip
+
+Demander à la dsi de nous transférer les ip, du point de vue du ripe.
+
+https://www.ripe.net/manage-ips-and-asns/resource-transfers-and-mergers/transfers/legacy-resources
+
+Pour cela, il faut un numéro d'AS et s'inscrire au Ripe (payant). La DSI de
+l'ENS va peut-être bientôt associer ses adresses à celles des autres écoles, il
+faudrait le faire avant si on veut les avoir.
+
+D'un point de vue technique, on deviendrait obligé d'annoncer nous même nos
+routes. Cela parait compliqué aujourd'hui.
+
+Ce qu'il nous faut est une promesse de nous les garder de côté en vu du
+déménagement à Saclay plutôt que de nous les donner de suite.
+
+### Futur : être un opérateur ?
+
+Il faut donc annoncer ses routes soit même, avoir un numéro d'AS et ripe...
+Huricane Electrics propose un service permettant de tunneler sa connection
+ipv6 et de la faire sortir "au milieu de l'internet" où on peut faire du bgp.
+
+On pourrait beta tester ça au cr@ns avant ARES.
+
+Qui serait intéressé par le projet ? Pour info, l'ARES envisage son inscription
+en tant que LIR.
+
+### Upload
+
+munin.crans.org/crans.org/odlyd.crans.org/if_ens.html
+Passage à 12Go ?
+
+Approuvé !
+
+### Questions Diverses
+
+* Commander une carte de contrôle pour Pulsar
diff --git a/compte_rendus/2016_01_14.md b/compte_rendus/2016_01_14.md
new file mode 100644
index 0000000000000000000000000000000000000000..b75f2e3fde5bd62c8ae308a2a6ac213078f918ac
--- /dev/null
+++ b/compte_rendus/2016_01_14.md
@@ -0,0 +1,163 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 14 Janvier
+* Lieu : Pavillon Des Jardins
+* Début : 19h09
+* Fin : 20h45
+* <<Pad>>
+
+## Présents
+
+Gabriel Detraz
+Charlie Jacomme
+Rémi Oudin
+Daniel Stan
+Martin Bauw
+Myriam Bégel
+Emmanuel Arrighi
+ОкÑана Ðндреевна
+Hamza Dely
+Renaud Taleroy
+
+## Ordre du jour
+
+### letsencrypt sur intranet, wiki/wifi, gitlab, phabricator, etherpad,
+owncloud, zerobin ... ?
+
+Daniel propose de passer à un système centralisé. Il n'y aurait plus qu'un seul
+serveur nginx tournant sur une machine à part, et les autres sites webs
+seraient servi sur adm. On ferait alors un certif commun pour tous les
+sous-domaines correspondant à un service internet.
+
+* Créer une vm (ssl.crans.org ? plopissecured.crans.org ? secure.crans.org ! )
+* Passer toutes les sockets gunicorn etc pour diffuser sur adm.
+* Set up nginx
+
+On va faire une proof of concept pour un service mineur. (zerobin?)
+
+Apprentis : Fardale
+Nounous : Charlie
+
+### Remplacement monit/... ? par icinga
+
+Objectif : virer autostatus, pour cela, il faut attendre le déploiement
+d'icinga sur l'ensemble des serveurs (wheezy + jessie),
+
+### Migration des virtualiseurs
+
+* On va commencer par fz (ou tenter)
+
+Apprentis : Rémi
+
+### Migration des ipv6 ?
+
+Le tunnel quantic a l'air un peu plus efficace que l'ancien.
+
+On va pas tester en prod. Par conséquent, il faut attendre d'avoir un firewall
+qui peut gérer deux prefixe v6.
+
+Soit on patch salement l'actuelle, soit on attend le nouveau firewall.
+
+Chirac va voir si c'est faisable assez simplement sur l'ancien firewall en
+testant sur vo, mais rien ne presse.
+
+### lc_ldap 3 or not ?
+
+Les gens ne sont pas d'accord.
+
+Le débat ici tient en deux pans.
+
+Le premier point est de savoir si on veut commencer à passer les scripts du
+crans à python3. Le support de python 2.7 s'arrête en 2020, il y a donc
+plusieurs optiques possible. 2020 est encore relativement loin, donc est-ce que
+passer à python3 est si urgent ?
+Par ailleurs, on sera à Saclay avant la fin du support de python 2.7, on peut
+donc laisser à l'ares le soin de s'occuper de python3. Cependant, plus la date
+se rapproche, plus les nouvelles versions de software telle que Django vont
+tout simplement dropper python2, ce qui pourrait nous poser problème.
+Enfin, la question est-elle pertinente sachant que l'on a toujours pas terminé
+de passer totalement à lc_ldap et qu'on a encore ldap_crans qui traine ?
+
+Le deuxième point concerne le devellopement d'un "nouveau" binding. PEB a
+commencé à travailler dans son coin sur une version python 3 de lc_ldap où il
+essaie de corriger au passage certains problèmes de son papa. Problème : Ã
+deux ans du déménagement, est-il pertinent de lancer le crans dans le
+developpement d'un nouveau binding. Certains pensent que si chaque asso bosse
+dans son coin sur un nouveau binding, c'est de mauvaise augure pour
+l'unification à Saclay où tout le monde préférera jouer dans son coin.
+Cependant, nous sommes encore à deux ans au moins du déménagement, ce qui veut
+dire que si l'on commence à bosser maintenant sur quelque chose tous ensemble,
+ce ne sera pas les gens qui ont develloppé le soft qui l'utiliseront, et comme
+d'habitude, tout sera recodé. Certains proposent donc de continuer à travailler
+au crans pour essayer d'avoir un nouveau binding qui pourrait être proposer
+comme brique de départ au projet commun de l'ares qui naitra d'ici un ou deux
+ans. Cela implique évidemment que l'on soit capable de notre côté de boucler le
+projet en environ un an. Mais le doute persiste concernant la collaboration
+future des assos si on joue dans notre coin.
+
+Là deuxième moitié du second point concerne le choix des technologies de
+devellopement du nouveau binding. D'aucun dise que ldap ça envoie du boudin et
+que sql reste loin derrière. Si il semble établie que les librairies utilisant
+ldap pour l'auth sont bien plus robustes et éprouvées que celles pour sql, la
+question des performances est cependant plus épineuse. On trouve beaucoup de
+random post sans vrai benchmark. Un récent benchmark de Daniel montre que
+django est un peu plus lent que ldap qui est lui meme plus lent que sql simple.
+Par ailleurs, d'un point de vue facilité de dev, django reste loin devant. Par
+suite, une idée peut être d'avoir un coeur de base ldap juste pour l'auth, et
+une base annexe psql/django pour tout le reste des infos. Vouloir passer le
+crans sur ce genre de binding est cependant beaucoup plus ambitieux que
+de "juste" passer à lc_ldap 3, et comme dit précédement, mettre en place ce
+genre de projet semble n'etre pertinent que si on peut le mener à bout d'ici un
+an.
+
+### Ethercalc : mise en prod et système d'auth
+
+Ethercalc est prêt, mais il n'y a pas encore de système d'auth.
+
+On pousse !
+
+L'idée est de faire une auth côté nginx -> sur plopissecured.crans.org ?
+
+### Baie de disque
+
+Elle est baie-hate !!
+
+Il y a plein de disque de 600go maintenant. Sauf que seul leurs 300 premiers Go
+sont utilisés...
+
+La baie ne supporte un extend que lorsqu'on ajoute un disque.
+
+Option 1 :
+
+* On fait du ménage sur les vm
+* On save tout sur les homes
+* On formatte et reconstruit la grappe vm
+* On redrop les vm à leur place.
+
+Option 2 :
+
+* On desactive les deux disques de 600Go de la grappe vm
+* Avec les deux spare+ les deux nouveaux de 600, on crée un nouveau raid.
+* On commence à transférer les données.
+* Dès qu'un disque est libre on le retire de l'ancienne grappe on et le rajoute
+ Ã la nouvelle avec un extend.
+
+Option 3 :
+
+* Faire mumuse avec slon
+
+On y réfléchit !
+
+Apprentis : Fardale, Rémi
+
+### Traduction de l'intranet
+
+Appel à bonne volonté.
+
+http://pad.crans.org/p/intranet-traduction
+
+Cf le pad pour qui fait quoi.
+
+### Question diverse
+
+* Qui veut des chips ?
diff --git a/compte_rendus/2016_02_11.md b/compte_rendus/2016_02_11.md
new file mode 100644
index 0000000000000000000000000000000000000000..72de33e72c9fc576cae5f89b0316eb87266ec269
--- /dev/null
+++ b/compte_rendus/2016_02_11.md
@@ -0,0 +1,166 @@
+# Réunion du Collège Technique
+
+* Date :
+* Lieu : PdJ
+* Début : 19h07
+* Fin : 21h30
+* <<Pad>>
+
+## Présents
+
+* Daniel Stan
+* Hamza Dely
+* Martin Bauw
+* Mathilde Espinasse
+* Rémi Oudin
+* Lucas Serrano
+* Gabriel Detraz
+* Charlie Jacomme
+* Pierre Elliott Bécue
+
+## Ordre du jour
+
+### Avancement de la traduction
+
+Avec la traduction, modifier/ corriger une typo devient un peu plus compliqué,
+il faut penser à modifier tous les fichiers de trad et à les re-générer.
+
+On attend un dernier commit et on pousse en prod ! Il n'y a pas d'autres
+grosses branches, donc il n'y aura pas trop de merge.
+
+Ping est chaud pour faire un truc joli pour le choix des langues.
+
+Un problème majeur est apparu lors de la traduction : crans ou cr@ns ??? (Crans)
+
+On passe au vote, pour la typo "Crans" :
+
+* 6 pour
+* 2 contre
+
+La typographie "Crans" est adoptée par le CT.
+
+### Maintenance pendant les vacances
+
+Deux points importants :
+
+* Migration de vm capitales (vert) sur le cluster jessie.
+* Firmware upgrade de la baie.
+
+Samedi 20 février, maintenance et coupure générale, à partir de 10h jusqu'a si
+possible fin de journée. (Présent : Daniel, Hamza, Peb, Charlie, ... ?)
+
+Penser le 16/17 février à vérifier les backups.
+
+On essaie de faire un max de trucs, selon comment ça se passe.
+
+D'ici là , il faut quelqu'un avec une Fedora/Red Hat.
+
+### Discourse (scourse)â„¢
+
+On propose que plus personne n'ait les droits admin par défault. Quelques
+nounous seront des nounous "référentes", qui auront un compte admin
+en "<user>-admin".
+
+Référents :
+
+* Ping
+* Becue
+* Charlie
+* Jordy
+
+Les nounous ne sont donc pas censées se donner les droits admin de manière
+unilatérale.
+
+### IP adh
+
+On propose d'augmenter le nombre de machines filaires à deux par adhérent. Cela
+implique de mettre le script de nettoyage des machines inutilisées (attention Ã
+épargner les clubs) en place.
+
+Il faut modifier l'intranet, gest_crans et le binding.
+
+Modification : Chirac + Guinness
+
+### Planning Permanences
+
+Des nounous d'astreintes ont remplis certains créneaux vide.
+
+### Let's encrypt
+
+Ça marche sur zero2, le cert global est prêt, on enchaine ?
+
+On lance pour discourse, (scourse)â„¢, zero, pad, calc.
+
+On va s'occuper des sites les uns après les autres :
+
+* Donner l'alias site.crans.org à bakdaur, après l'avoir retiré à la machine.
+* Rajouter un fichier de conf nginx à bakdaur pour qu'il proxypass
+ site.crans.org vers site.adm.crans.org
+* Faire émettre site.crans.org sur site.adm.crans.org
+
+Il faut faire attention à la factorisation des fichiers de conf nginx.
+
+### Installation de bornes wifi SDA
+
+Diane souhaiterait disposer d'un câble éthernet (pour leur TPE) et de Wifi (les
+caissiers vont avoir des PCs pour accéder à la note Kfet), le tout au niveau
+des caisses du Gala (à l'intérieur).
+NB: les sENS de l'Art auront lieu le samedi 19 mars.
+
+Il faut qu'ils voient avec le BDE pour avoir la note. Il n'y a a priori pas de
+problème, il faut juste quelqu'un qui soit présent.
+
+### Serveur virtuel de Test
+
+Ping veut que le crans mette à disposition 2 serveurs virtuels pour faire des
+tests.
+
+Le prochain qui a besoin créera la vm.
+
+### "Vert !"
+
+* Quand est-ce qu'on mange ?
+* Rémi est désormais Nounou, plein de bonheur à lui. Mouhahah.
+
+```txt
+ `-.`'.-'
+ `-. .-'.
+ `-. -./\.- .-'
+ -. /_|\ .-
+ `-. `/____\' .-'.
+ `-. -./.-""-.\.- '
+ `-. /< (()) >\ .-'
+ - .`/__`-..-'__\' .-
+ ,...`-./___|____|___\.-'.,.
+ ,-' ,` . . ', `-,
+ ,-' ________________ `-,
+ ,'/____|_____|_____\
+ / /__|_____|_____|___\
+ / /|_____|_____|_____|_\
+ ' /____|_____|_____|_____\
+ .' /__|_____|_____|_____|___\
+ ,' /|_____|_____|_____|_____|_\
+,,---''--...___...--'''--.. /../____|_____|_____|_____|_____\ ..--```--...___...--``---,,
+ '../__|_____|_____|_____|_____|___\
+ \ ) '.:/|_____|_____|_____|_____|_____|_\ ( /
+ )\ / ) ,':./____|_____|_____|_____|_____|_____\ ( \ /(
+ / / ( ( /:../__|_____|_____|_____|_____|_____|___\ ) ) \ \
+ | | \ \ /.../|_____|_____|_____|_____|_____|_____|_\ / / | |
+ .-.\ \ \ \ '..:/____|_____|_____|_____|_____|_____|_____\ / / / /.-.
+(= )\ `._.' | \:./ _ _ ___ ____ ____ _ _ _ _ _ _ _ ___\ | `._.' /( =)
+ \ (_) ) \./ |\/| |__) |___ |___ |___ _X_ _X_ \/ _|_ \ ( (_) /
+ \ `----' """""""""""""""""""""""""""""""""""""""""""""""" `----' /
+ \ ____\__ __ __ _ __ _ _ __ ________ _____ __/____ /
+ \ (=\ \ (_ |_ |V||_)|_ |_) |_|(_ / | | |_ | / /-) /
+ \_)_\ \ __)|__| || |__| \ | |__)\___|__|_ | _|_ / /_(_/
+ \ \ / /
+ ) ) _ _ ( (
+ ( (,-' `-..__ __..-' `-,) )
+ \_.-'' ``-..____ ____..-'' ``-._/
+ `-._ ``--...____...--'' _.-'
+ `-.._ _..-'
+ `-..__ __..-'
+ ``-..____ ____..-''
+ ``--...____...--''
+
+```
diff --git a/compte_rendus/2016_03_10.md b/compte_rendus/2016_03_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..48cecd62ab8a83851aa39c93af672b7671b0bdbc
--- /dev/null
+++ b/compte_rendus/2016_03_10.md
@@ -0,0 +1,249 @@
+# Réunion du Collège Technique
+
+* Date :
+* Lieu : PdJ
+* Début : 19h00
+* Fin : 20h36
+* <<Pad>>
+
+## Présents
+
+* Hamza Dely
+* Vincent Legallic
+* Martin Bauw
+* Lucas Serrano
+* Mathilde Espinasse
+* Rémi Oudin
+* Gabriel Detraz
+* Daniel Stan
+* Charlie Jacomme
+
+## Ordre du jour
+
+### SDA : bornes
+
+Les Sens de l'Art voudraient des bornes
+Wifi (cf [[ComptesRendusCrans/Jeudi11Fevrier2016|précédente IN]]), Hamza et
+Martin s'en occuperont.
+
+### Redondance ou augmentation des risques
+
+On débriefe un peu les échecs de Vendredi et Samedi dernier.
+
+La constatation générale est que notre archi n'est pas réellement "redondée".
+En effet, si on passe de 1 à 3 serveurs qui font "la même chose", si c'est bien
+fait, on passe les chances d'échecs à /3,
+alors que si quand un seul merde les 3 foirent, on passe à *3.
+
+Actuellement, nous avons en théorie de redondés : les virtualiseurs, le DNS, le
+LDAP, l'auto radius.
+Sauf que force est de constaté que dans plusieurs cas, en fait, il suffit qu'un
+seul merde pour que tous merdent.
+Exemples constatés :
+
+* 1 virtualiseur seul considère qu'il n'a pas le quorum : ça marche pas
+ * Pour régler ça, le quorum a été passé à 1 pendant le reboot.
+
+. Cela signifie qu'un virtualiseur pourrait être coupé des
+autres (''brainsplit'') et penser qu'il est le cluster alors que le cluster est
+formé par les deux autres, et donc lancer des VMs sans savoir qu'elles sont
+déjà lancées sur l'autre.
+. On va remettre le quorum à 2 pour éviter les ''brainsplit''.
+
+Stratégie :
+
+* Remettre le quorum à 2 et 1 voix chacun pour les virtualiseurs.
+* Remettre en place le rsync permettant d'avoir un beau cranspasswords à jour
+ sur {{{soyouz}}}
+* Dumper régulièrement la partie doc du wiki pour le servir en statique
+ sur {{{soyouz}}}
+ * En fait "la partie doc du wiki" c'est pas défini. On propose de dumper le
+ tout (sans les PJs), voir combien ça pèse…
+* Mettre à jour la doc [[CransTechnique/CransNounous/RedémarrerLe0B|Comment
+ rebooter le 0B]], et '''l'imprimer, la plastifier et la placarder au 0B'''
+* Déplacer vert sur thot
+
+On propose de plus de mettre en place un serveur qui fasse tout (radius,
+routage, dhcp, ldap-readonly, dns physique), type "on l'allume, et ça marche"
+{{{komaz}}} est d'abord proposer, mais sable semble plus pertinent pour cela,
+une fois que son activité actuelle aura été virtualise (Remi et Mathilde
+s'occupe de la virtualisation).
+
+On met {{{keepalived}}} sur sable, il peut ainsi redonder/alléger la charge des
+autres. Manuellement, en cas de merde, on lui donne une grosse priorité et il
+prend la main sur tout le monde et assume le boulot.
+
+À propos de {{{keepalived}}}, on a eu le problème que {{{eap}}} ne marchait
+pas pour l'auth wifi, mais {{{pea}}} pouvait pas prendre la main parce
+que {{{eap}}} a son keepalived qui tourne toujours.
+
+* => écrire un vrai script de test de fonctionnalité du serveur radius (qui
+ simule une *vraie* authentification)
+
+Ping fait remarquer qu'il existe [[http://www.linux-ha.org/wiki/Main_Page|Linux
+High Availability]] qui peut faire à peu près la meme chose que keepalived mais
+en monitorant des services.
+À voir si ça peut piquer les IPs tout comme keepalived. Ping regarde si ça fait
+ce qu'on veut.
+
+### La baie
+
+Les échanges de Charlie avec HP :
+https://lists.crans.org/private/roots/2016-March/288827.html
+https://lists.crans.org/private/roots/2016-March/288767.html
+
+Une fois qu'on aura master {{{sable}}}, on prévoira une nouvelle coupure et on
+fera les firmware upgrades.
+(On pourra en profiter pour tester toutes nos histoires de failover.)
+
+Pour que les firmware upgrades "tombent en marche", il faut les lancer depuis
+vo...
+
+On propose de renommer la baie "rezina". Motion acceptée à l'unanimité.
+
+### KVM
+
+Brancher/débrancher/faire des acrobaties derrière l'armoire serveurs n'est pas
+toujours très pratique.
+
+Il faut commencer par tester si le KVM marche encore, il faut changer l'alim.
+Ensuite, il faudra acheter des jolis adaptateurs.
+
+Hamza a un peu regardé ce qu'on peut acheter. Il faudra commander et tenter de
+brancher.
+
+### Serveur pour FedeRez
+
+FedeRez a pour projet de proposer de la virtu pour les associations membres. Il
+avait été suggéré de préter kdell en novembre.
+Ce serait bien que du coup FedeRez s'engage à migrer baldrick sur cette
+nouvelle machine physique dans un délai raisonnable
+(baldrick prend beaucoup de place disque sur notre baie, et ça deviendrait
+injustifié si machine physique à côté).
+
+Pas d'objection, Ã valider par le CA.
+
+### Ménage au 0B
+
+L'armoire contient encore {{{dyson}}}, coquille vide à basarder.
+
+Migrer {{{dyson}}} au 0C (il a été shreddé).
+
+Quid de {{{osm1}}} et {{{osm3}}} ?
+OSM a pas encore décidé de ce qu'il en font. Les relancer
+
+### Ménage au 0C
+
+Prévenir les respo-info BDE quand on ira à la déchetterie, ils ont des
+carcasses de leur côté aussi.
+
+Pour le toner, le contrat conibi c'est fait, se bouger le cul.
+
+### Ménage au 4J
+
+Faut (re)envoyer des mails à HP pour avoir des étiquettes de retour pour le
+toner.
+Comme HP n'en envoie qu'une à la fois, il faudrait croner le mail de demande.
+
+### Internet au RU
+
+Le CROUS voudrait qu'on desserve le RU.
+
+On peut pas fournir un accès wifi à tout le monde (légalement), donc on peut
+leur proposer de voir avec l'ENS pour eduroam.
+Servir eduroam ne serait en théorie pas trop compliqué sur nos bornes, on a
+juste besoin des identifiants.
+
+Si le CROUS veut autre chose que du Cr@ns (pour les adhérents) et du
+eduroam (pour ceux qui l'ont), Ã eux de voir avec l'ENS.
+
+On est pas d'accord pour tirer les câbles car cela représente un temps assez
+considérable. On voudrait également qu'ils payent le matériel nécessaire a
+l'installation.
+On pourrait leur faire un devis.
+
+Gabriel répondra ça à Benjamin DUBOURGEAT (contact au CROUS qui a fait cette
+demande).
+
+### Cache Steam
+
+Fardale souhaiterai si possible mettre en place un cache steam, blizzard, riot,
+ea sur le campus.
+Ce qui nous permettrait d'économiser de la bande passante et de fournir un
+meilleur débit aux adhérents quand ils cherchent à contacter steam.
+
+Page vers la mise en place
+du [[https://developer.valvesoftware.com/wiki/SteamPipe|cache Steam]].
+https://blog.multiplay.co.uk/2014/04/lancache-dynamically-caching-game-installs-at-lans-using-nginx/
+https://trac.resel.fr/wiki/Doc/Howto/InstallCache#no1
+
+Ce serait gourmand en espace disque (~1To d'après Fardale).
+D'un point de vue compatibilité avec les objets de l'association, ce n'est pas
+très clair, du coup, on préfère faire ça avec du matos de récup (disques
+changés, un des serveurs OSM ou {{{komaz}}}).
+
+En tout état de cause, ce n'est pas un point urgent.
+On n'est pas vraiment contre le principe, mais la consolidation de l'archi
+actuelle est prioritaire.
+
+### Imprimante
+
+Le PJL arrive.
+Daniel voudrait aussi qu'on puisse choisir l'imprimante vers laquelle imprimer
+depuis l'intranet.
+
+### Let's Explode all the things
+
+https://crans.org marche pas ce soir.
+
+Vérifier que les IP réelles sont bien forwardées par bakdaur/frontdaur au vrai
+serveur derrière.
+Ça, c'est fait pour tout le monde.
+
+Il faut que cette IP forwardées soient comprises par le serveur cible.
+À vérifier.
+
+### Discourse et le monde extérieur
+
+Il faudrait investiguer les moyens d'auth pour savoir si on peut limiter
+l'accès au campus.
+
+#### Install Party
+
+* Certains PXE ne fonctionnent pas. Debian et Ubuntu fonctionnent, mais les
+ autres non
+* Qui sera là quand ? https://ethercalc.crans.org/xr5ltkuwpf
+
+### Jabber
+
+Fardale aimerai suivre les IN sur Jabber.
+Quelqu'un installera jabber pour la prochaine fois.
+
+### Questions diverses
+
+#### Promouvoir un autre client IRC ?
+
+Actuellement, la commande "irc" sur zamok lance irssi.
+[[Wiki20-100|20-100]] suggère de remplacer ça par weechat.
+
+Pourquoi ?
+
+* Parce qu'il propose pleins de trucs mieux (subjectif)
+* Parce qu'il est plus noob-friendly (un peu plus
+ objectif (cf /help, /set *recherche*…))
+* Mais surtout parce qu'un nombre écrasant de cranseux l'utilise et peut donc
+ aider à répondre aux questions des débutants.
+
+Accessoirement, un certain nombre de jeunes a récemment découvert IRC et trouvé
+ça rigolo, ce serait pas mal de surfer sur la vague et de leur faire une
+comm' sur le sujet comme Jordy l'a fait pour discourse.
+Il serait alors de bon ton de prévenir sur les news & discourse, mais aussi
+sans doute par mail les utilisateurs fréquents de zamok, dont on peut avoir la
+liste (même en tant que simple adhérent) grâce à quelques {{{last}}} bien
+sentis…
+
+Daniel suggère que ça fasse carrément le screen (ou le rattache si il existe
+déjà ).
+20-100 s'en occupe.
+
+Vote : Pour a l'unanimité moins deux abstentions.
diff --git a/compte_rendus/2016_03_24.md b/compte_rendus/2016_03_24.md
new file mode 100644
index 0000000000000000000000000000000000000000..3e7b2cb1bc4d36a4b1e535f2c20f4f35bb93b9bc
--- /dev/null
+++ b/compte_rendus/2016_03_24.md
@@ -0,0 +1,92 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 24 Mars 2016
+* Lieu : PdJ
+* Début : 19h00
+* Fin : 19h59
+
+## Présents
+
+* Mathilde Espinasse
+* Kévin Le Run
+* Lucas Serrano
+* Martin Bauw
+* Daniel Stan
+* Rémi Oudin
+* Gabriel Detraz
+* Renaud Taleroy
+
+## Ordre du jour
+
+### Serveur pour FedeRez
+
+La précédente réunion technique avait évoqué le prêt de kdell et non un don. Le
+CA s'étant réuni par la suite a voté un don, Daniel était présent à cette
+réunion et s'excuse platement pour le malentendu …
+Étant donné que le serveur nous a été donné par la fondation free et ne nous a
+jamais rien coûté. De plus, une seule nounou semble depuis s'être exprimée
+contre ce don, mais le motif du refus n'était pas technique. On propose donc de
+céder le serveur, ce qui est acté à l'unanimité des nounous présentes.
+
+### Impression
+
+Daniel fait une démo de l'utilisation du driver via un proxy sur vo et une
+connexion sur le serveur cups.
+Au début ça avait l'air de marcher mais on constaté quelques plantages (tout de
+même très rares).
+
+Le basculement de driver s'effectue très facilement à l'aide du systèmes de
+classes de cups : il suffit de changer les imprimantes activées dans la
+classe "MFPM-880". En cas de pépin, on peut donc revenir en arrière pour
+certaines impressions.
+Nom de l'imprimante avec le nouveau driver : MFP-PCL.
+Si besoin on peut remettre l'ancien driver : imprimante MFPM880-1.
+
+Prochaine étape: Créer plusieurs imprimantes "physique" (au sens de cups) et
+les mettre dans la même classe virtuelle, et faire du load balancing.
+Une autre idée : envoyer les impressions A3 en plusieurs exemplaires une à une,
+en vérifiant avant chaque envoi qu'il reste du papier A3. Ceci permettrait
+d'éviter de bloquer l'imprimante sur un défaut de papier A3 (->phabricator).
+
+### Pages perso
+
+On a mis en production une modification de l'application de création de bdd
+mysql sur zamok pour les pages personnelles des adhérents. Cette mise à jour
+permet la gestion des bases de données des pages perso des clubs.
+
+Problème : les bases de données étaient précédemment gérées à la main et il
+faut renormaliser les noms actuels : https://pad.crans.org/p/mysql on va
+contacter les adhérents/clubs dont le nom de base de données ne correspond pas
+au login Crans.
+
+### Oison
+
+Oison ne veut imprimer que lorsqu'elle est dans la mauvaise pièce (« Printers
+are sent from hell »). Problème de faux contact ? Relancer le démon après
+chaque "rebranchage" Ethernet ? Problème à investiguer (Rémi s'en occupe).
+
+### Questions diverses
+
+#### Phabricator
+
+Les tâches sont par défaut publiques, on se demande si ça se règle …
+
+#### Etherpadtex
+
+Rémi propose de rajouter une feature au pad pour faire du \LaTeX, à essayer …
+
+#### Mots de passe mailing-lists
+
+On profite de la réunion pour briefer les apprentis sur l'usage de
+cranspasswords pour les mots de passes MlBureau/MLCa.
+
+## Signing Party
+
+On profite de la réunion pour réaliser les signatures des nouvelles clés PGP
+des apprentis.
+
+## Réunion technique ARES
+
+Chirac propose une réunion technique pour le projet ARES. Elle aura lieu cette
+fois-ci à Cachan: un sondage sur le choix de la
+date : https://framadate.org/s4MFcUXSqniyfeWT
diff --git a/compte_rendus/2016_04_21.md b/compte_rendus/2016_04_21.md
new file mode 100644
index 0000000000000000000000000000000000000000..0a452d7466be54163b7e62d36ee22c1792a9f81a
--- /dev/null
+++ b/compte_rendus/2016_04_21.md
@@ -0,0 +1,141 @@
+# Réunion du Collège Technique
+
+* Date : 21 Avril 2016
+* Lieu : Pavillon-Des-Jardins
+* Début : 19h13
+* Fin : 20h11
+* <<Pad>>
+
+## Présents
+
+* Lucas Serrano
+* Martin Bauw
+* Daniel Stan
+* Gabriel Détraz (via Jitsi)
+* Hamza Dely
+
+## Ordre du jour
+
+### Jitsi-meet
+
+Jitsi-meet est un service de visioconf (à la "hangout"®©) qui fonctionne avec
+la techno webRTC. Lucas a fait des tests sur
+
+test1.crans.org, et a eu l'occasion de tester pendant 1h30, 8 participants, le
+serveur a généré un peu plus de 13Go d'upload.
+
+* Est-ce que tout le monde était en HD ? --> On sait pas, mais la qualité n'est
+ pas réglable
+* Est-ce qu'on peut configurer plusieurs relais (le but était d'avoir un point
+ de sortie hors crans, chez ovh pour le traffic à destination d'ip extérieure
+ au campus) ? --> problème ouvert
+* truc cool : le chiffrement est activé
+
+Petits bugs :
+
+* remplit les logs (très verbeux)
+* marche pas sur la machine de Daniel (ni iceweasel) --> Ã diagnostiquer
+
+--> Restreindre les accès en whitelistant les ip federez ? (à l'intérieur du
+ réseau Renater, afin de justifier une excemption d'upload pour la
+ machine) -- Compliqué mais faisable
+
+#> En profiter pour mettre au point un moyen pour partager automatiquement des
+données entre assos. Au moins lisible, éventuellement inscriptible par des
+scripts ?. (Y'a des apprentis à FedeRez/l'ARES ?)
+
+--> VM Crans ou ARES ? Nayef suggère de mettre ca sur des vm ARES, Ping suggère
+ lui d'avoir 3 noeud sur chaque campus.
+ --> pourquoi pas, si un apprenti du crans -- Blupon tu es engagé -- est
+ impliqué et qu'on applique les limitations exprimées plus haut, du moins
+ dans un premier temps.
+ --> on verra plus tard pour les histoires de pont …
+
+Il faut aussi documenter l'install.
+
+### Zamok v5
+
+Zamok sort de garantie en septembre prochain, probablement non renouvelable.
+Hamza propose donc de faire un devis pour un nouveau serveur. La question,
+c'est : veut-on un serveur des adhérents plus puissant ou pas ?
+
+* Poser la questions aux adhérents utilisateurs ?
+* Utiliser un autre serveur, sable est proposé, mais il va aussi sortir de
+ garantie, et on le réserve déjà comme routeur/système tout en un de
+ secours (lui mettre tous les services de zamok le rendra plus trop système de
+ secours …)
+
+On envisage de prendre un modèle équivalent en puissance (ie, pas une bête de
+course) et de rester sur un fonctionnement fair-use, ie si un adhérent a besoin
+de ressources, l'autoriser si l'usage ne nuit pas au fonctionnement global du
+serveur (autres utilisateurs, délivrance de mails et pages perso).
+
+Pour l'ex-zamok, du coup, on pourrait : le mettre dans le cluster de
+virtualisation même si il n'est plus sous garantie ?
+Si on tente ça, penser à vérifier que le jeu d'instructions est
+compatible… Quelle utilité sachant qu'on a enlevé kdell ? Moar
+power ! À creuser.
+
+### Cartographie du réseau pour optimiser la gestion des fréquences WiFi
+
+But : remapper les fréquences WiFi des bornes pour qu'elles arrêtent de se
+marcher sur les pieds.
+Daniel et Martin sont sur le coup.
+
+### Babar
+
+Babar a brûlé il y a 10 jours, nous avons acheté un nouveau serveur HP dans
+l'urgence. Contrairement à nos craintes les nouveaux emplacements disques sont
+compatibles, Hamza le ré-installe (seul le disque système a péri).
+
+Bienvenue donc
+Ã [[https://fr.wikipedia.org/wiki/Babar#Autres_personnages|zephir]] !
+
+### Charybde
+
+Le disque système SSD a été installé avec succès, le RAID (avec les
+données) n'a pas été refait (donc pas de miroir à reconstruire). Niveau
+performance, plus de latence au niveau du système, donc c'est pas mal.
+
+### CAS
+
+Valentin et Myriam (pas présents) ont prévu de migrer le CAS en utilisant leur
+implémentation custom en Django (pour remplacer l'actuel tomcat en Java), nous
+n'avons pas plus l'info là -dessus. De la documentation serait la bienvenue.
+
+Le cas semble avoir été mis à jour sous jessie (il semble bien se porter).
+
+### Questions diverses
+
+#### routes
+
+Les routes IPv6 (de zamok, essentiellement, mais comme c'est surtout à lui
+qu'on se connecte, c'est surtout chez lui qu'on constate le problème) ça marche
+en fonction de la pluie et du beau temps.
+Il semblerait que ce problème n'existe qu'au boot.
+20-100 n'est pas convaincu. Il essayera d'investiguer la prochaine fois qu'il
+rencontrera le problème.
+
+#### April fool's prank part 3: odlyd ?
+
+Le technicien a réussi à nous remplacer la bonne carte mère sur le bon serveur.
+Deux jours plus tard, le routeur a de nouveau subi un kernel panic.
+L'assitance nous propose le remplacement du cpu demain vendredi 22 avril. On
+essaiera de réveiller Hamza pour s'occuper du routeur fallback.
+Il faut vraiment relire le contrat de maintenance afin de savoir ce qu'on est
+réellement en mesure d'exiger d'HP.
+
+#### MÃ j de la baie ?
+
+Personne n'est disponible dans l'immédiat pour s'en occuper. Le système de
+secours sur sable n'est pas encore fini (ce qui permettrait de shutdown la baie
+de disque en coupant les services, mais pas Internet)
+
+Ça en est ou ?
+Guiness et Mathilde ont créé la machine virtuelle destinée à héberger à terme
+le dns principal (pour pouvoir en libérer sable), il reste à configurer ledit
+serveur dns, puis à faire la migration des zones.
+Attention, ça voudra dire que les seuls DNS primaires non virtuels seront
+soyouz et freebox. En cas de boot from scratch, on a hardocdé les IPs
+nécessaires, mais on peut avoir besoin d'autre chose…
+Ça rassurerait 20-100 qu'on ait un DNS primaire physique.
diff --git a/compte_rendus/2016_09_01.md b/compte_rendus/2016_09_01.md
new file mode 100644
index 0000000000000000000000000000000000000000..4df34fab461b6ace9cad3f2c20397a988fe3ba71
--- /dev/null
+++ b/compte_rendus/2016_09_01.md
@@ -0,0 +1,370 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 1er septembre 2016
+* Lieu : Pavillon des Jardins
+* Début : 19h00
+* Fin : 22H05
+* <<Pad>>
+
+## Présents
+
+* Hamza Dely
+* Gabriel Detraz
+* Charlie Jacomme
+* Daniel Stan
+* Myriam Bégel
+* Mathilde Espinasse
+* Renaud Taleroy
+* Lucas Serrano
+* Younesse Kaddar
+* Emmanuel Arrighi
+* Rémi Oudin
+* Vincent Legallic (arrivé à 19h13)
+* Michaël Paulon
+
+## Ordre du jour
+
+### État des lieux et stabilité
+
+Le 0B est safe aux inondations de 15cm. Tout est surélevé. Les serveurs
+critiques sont sous Jessie, il n'y a plus de problème. Odlyd semble réparé, il
+n'y a plus eu de KP depuis plusieurs mois.
+La clim a été réparée une nouvelle fois, on espère qu'elle va bien et que c'est
+enfin fini. Dernière bonne nouvelle, sable est quasiment prêt en fallback
+master.
+La solution est qu'il spoofe toutes les ip (dns, dhcp, etc.) Il faut encore
+proprifier la conf éventuellement, mais ça semble en bonne voie.
+
+Daniel propose de se pencher vers Keepalived. De cette manière, il se charge de
+vérifier si les services fonctionnent, et si ce n'est pas le cas, il prend le
+relais. C'est également l'ocassion de vérifier toutes les configurations de
+keepalived pour chaque service et s'assurer que le switch se fait bien
+également pour les serveurs de redondances.
+
+#### NFS
+
+Beaucoup de problème et de stabilité et de sécurité proviennent du nfs.
+
+Le NFS est le système de fichier sur le
+réseau (https://en.wikipedia.org/wiki/Network_File_System). Certains dépôts
+comme {{{/usr/scripts}}} sont partagés par le nfs, et c'est potentiellement
+dangereux puisque si le nfs tombe, on perd tous nos scripts.
+Ce qui s'est passé le 28 : une commande foireuse suite à un énième remontage en
+ro d'un home a coupé nfs-kernel serveur, il nous a été impossible de le
+relancer. Cela a provoqué une panique en chaine sur zamok en premier, avec tous
+les users qui essayaient d'accéder à leur home ; le moindre ls tournait en
+boucle.
+
+Seul un reboot de zbee, avec une mauvaise surprise habituelle (grub-rescue) a
+permis de relancer le nfs. Il a fallu entre autres rebooter zamok ; l'intranet
+également (qui accède aux home et a lui aussi paniqué).
+Les autres serveurs n'ont pas besoin des home, ils n'ont pas paniqué ; mais le
+dhcp et le radius ont planté du fait de l'absence de usr/scripts… Ce qui est
+très problématique, la coupure aurait pu être plus indolore sans cela. Seul
+odlyd a continué à router normalement, les règles du parefeu sont restées en
+place jusqu'à ce que usr/scripts revienne, bon point de ce coté là .
+
+Il existe actuellement 3 exports nfs : les homes, la virtu
+et {{{/usr/scripts}}}.
+
+##### /usr/scripts
+
+L’intérêt du /usr/scripts over nfs est très limité ; l’expérience prouve qu'un
+git pull fait par monit avec alerte si cela foire fonctionne très bien, ironie
+du sort, sur zbee lui même !
+Je propose donc d'abandonner /usr/scripts over nfs, et de mettre le dépot en
+dur sur les serveurs. Il ne pèse pas très lourd, 50 megas à tout casser.
+
+On gagne énormément en stabilité ; à titre d'exemple, en cas de plantage de
+zbee le 28, le réseau aurait entièrement continué de fonctionner (dhcp, radius
+etc) ; seul les mails et zamok auraient été impactés à cause du plantage de
+l'export des home. On renforce également très fortement la sécurité.
+
+La plupart des fichiers qui pèsent sont surement inutiles dans
+usr/scripts (fichiers de logs des bornes). Alors on autorise monit à git pull Ã
+chaque commit.
+
+La décision est validée par le CT.
+
+Ping propose une autre solution qui passerait par bcfg2 pour éviter d'avoir
+tous les scripts partout et de ne plus savoir qui doit être où. Cependant, ça
+demande beaucoup de travail, et on ne gagne pas forcément beaucoup en
+stabilité. La question pourra être réabordé dans le futur une fois que
+le /usr/scripts sera safe.
+
+##### les Homes
+
+C'est de loin le plus problématique sur le nfs. À moyen terme, il convient de
+réévaluer la pertinence des home sur la baie qui est plus que limité.
+
+Chirac propose donc d'acquérir ou de constituer 2 nas, fonctionnant avec ceph,
+ce qui permettra au passage de tester cette technologie qui semble mature et
+robuste, et de migrer ensuite l'ensemble des home dans cette grappe de nas.
+
+Charlie imagine un NAS logiciel. Dans ce cas, on peut prendre du SATA, et donc
+prendre des gros disques, avec du RAID logiciel. Chirac remarque que
+ceph + raid5 se fait facilement.
+
+Charlie demandera un devis à Anne. Ping fait remarquer qu'au pire, elle peut
+Anne-uler.
+## Oh god… -- ZeldAurore <<DateTime(2016-09-02T11:52:00+0200)>>
+
+###### La virtualisation
+
+On peut la laisser à moyen terme dans la baie, et réévaluer la situation en
+temps voulu. Il est à noter que proxmox gère nativement ceph, si on souhaite
+fonctionner là aussi avec une grappe de nas. Auquel cas il sera pertinent de
+pas recommencer les mêmes erreurs, et de séparer le stockage des adhérents de
+la virtualisation…
+
+Pour la virtualisation, on verra plus tard après avoir testé avec les Home.
+
+#### Ram pour virtualiser
+
+Il est apparu qu'on ne pouvait mettre toutes les vm sur un seul virtualiseur
+par manque de ram, ce qui est un peu bête. Chirac propose d'acheter 32 gigas de
+ram pour stitch, idem pour ft, vu le prix que cela coute, l'investissement vaut
+le coup. À ce moment là le réseau pourra tourner entièrement avec un seul
+virtualiseur up (stitch ou ft).
+
+En mettre 32Gb sur les deux virtualiseurs est un peu overkill. L'objectif est
+de pouvoir faire tourner toutes les VMs sur le même serveur. Actuellement les
+VMs sont un peu maigres en RAM, ça permettrait de resizer pour éviter que les
+VMs se bloquent quand une upgrade prend plein de RAM.
+
+Daniel propose de lister les VM vraiment vitales. On regarde les besoins en
+RAM, quitte à modifier, et on considère que c'est le minimum sur le
+virtualiseur principal. Les VMs de redondance iraient sur les autres
+virtualiseurs, quitte à les éteindre en cas d'urgence.
+
+Hamza se charge de faire le calcul : Il faut 18Go de RAM pour faire tourner les
+VMs critiques. Charlie demandera un devis à Anne.
+
+Ping remarque qu'il faudrait mettre 1Go minimal en RAM max (et 512 en mini) sur
+les VMs, en dessous on en a moins qu'une Raspberry Pi. Charlie se propose pour
+faire ça.
+
+#### Redondance
+
+Les VMs redondantes. Quand on a éteint des VMs quand le 0B
+chauffait (24/08/2016), y'a eu un certain nombre d'incompréhensions, au moins
+de ma part sur lesquelles étaient redondantes. Est-ce que 2 VMs censées l'être
+le son vraiment (ie y'en a pas une des 2 qui ''en fait'', fait un truc en
+plus) ? Exemple typique : un des 2 serveurs radius fait en fait Federez-Wifi
+en plus.
+{{{
+#roots, 24/08/2016
+16:54:42 &tudor | si vous voulez un protocole (en général), l'idée que je
+suggère c'est de garder les vm de redondance (pea, isc) ou inutiles sur le
+virtualiseur le moins puissant
+16:54:54 &tudor | et de l'éteindre au premier pépin}}}
+keepalived : je prétends que sa config pour les trucs qu'il est censé failover
+n'a pas été testée. Prove me wrong :)
+
+Il faut mettre à jour la page wiki sur les VMs redondées, savoir qui fait quoi
+exactement. La mise en place de Keepalived sur sable permettra de faire une PoC
+sur tous les services.
+
+### Planification installation zamok
+
+Si le CA est gentil, on aura un nouveau zamok à installer. Où, quand, qui et
+comment ? Warning : wild problems may appear everywhere…
+
+Update : le CA est gentil :)
+
+Il va falloir l'installer puisque le CA est gentil.
+
+Un des problèmes est que le digicode est sur zamok. Charlie propose de tuer ce
+vieux service et de passer au nouveau digicode (à finir et à patcher). Le
+nouveau service coûte grand max 150€.
+
+Charlie peut proposer un devis pour le CA. Un prototype marche avec des trucs
+sales, mais du coup on peut faire marcher avec un truc propre. Le système au 2B
+est quasiment fini.
+
+Par contre, il faut vraiment s'y mettre pour le finir, et pas le laisser
+traîner.
+
+Avoir le digicode prendra malgré tout 2-3 mois, on attendrait donc pour mettre
+zamok en prod. On prend donc le temps de le reconfigurer from scratch.
+.
+http://git.crans.org/?p=rebootModule.git;a=commitdiff;h=36043453a6ac7f79dae42858b4642cdb761143fe
+↑ Ce commit prétend qu'on peut changer l'IP/MAC du serveur digicode avec le
+digicode actuel. (Le digicode n'est donc pas bloquant pour changer
+zamok). -- Daniel
+
+Accessoirement, ce serait bien de faire un dump des paquets installés sur Zamok
+et de trier ceux qu'on garde et ceux qu'on jette.
+apt-mark showmanual ?
+.
+https://www.debian.org/releases/stable/amd64/release-notes/ch-upgrading.fr.html#package-status
+
+#### Apt-dater
+
+C'est en place, cela juste marche. Démo prévue (Chirac). On peut abaisser le
+niveau de vérification pour que ce soit encore plus pratique, mais attention
+danger.
+
+Il faut les répartir en groupes (critique, autres, services…). La config est
+dans /root/.config/apt-dater/hosts.conf pour les groupes. Il faudrait que ça
+soit généré automatiquement par bcfg2 (voir pour la création de services.py
+pour un exemple)
+
+Il faudrait aussi gérer le cas des serveurs/VMs marqués en unknown.
+
+### KVM
+
+Pendant le stage de Hamza, on a reçu le module kvm usb, ça marche. On a pas
+d'alim qui fonctionne, il faut en racheter une, ainsi que la dizaine de modules
+kvm nécessaires.
+
+### policyd-rate-limit
+
+Il y a eu des problèmes de spams par des vieux comptes inutilisés. Il n'y avait
+pas de limitations du nombre de mails si on changeait d'ip. Plein de serveurs
+nous ont blacklisté pendant un temps.
+
+Nit a développé un script pour gérer ce problème. Si la limite est dépassée,
+postfix envoie une erreur smtp qui correspond à des limites dépassées.
+
+Mailman ne semble pas impacté par policyd-rate-limit.
+
+On peut fixer une limite par jour (genre 500 mails).
+
+Hamza propose de s'en charger.
+
+Il faut aussi créer une campagne de changement de mot de passe (projet
+apprentis).
+
+#### Ethercalc
+
+Suite au reboot du 2 août, il semble que ethercalc n'avait pas redémarré. Nit a
+fait un redémarrage par la suite, mais à la main.
+
+Renaud avait fait un init script, il faut juste le retrouver. Il s'en charge
+pour la prochaine IN. Il écrira aussi la doc nécessaire pour comprendre son
+installation.
+
+#### Autres problèmes
+
+Idées en vrac :
+
+-- [[Wiki20-100]] <<DateTime(2016-08-26T16:58:34+0200)>>
+* Contacts pour la maintenance :
+
+.{{{
+From: Gabriel Detraz <detraz@crans.org>
+Date: Tue, 2 Aug 2016 20:47:45 +0200
+Cc: nounou@lists.crans.org
+Pour information, j’ai envoyé le mail de la maintenance au adhérents, mais
+également aux clubs qui disposaient d’un contact valide.Par conséquent, FedeRez
+et l’ARES pour ne citer qu’elles ont automatiquement reçu le mail prévenant de
+la coupure. Si ce n’est pas le cas de rezosup ou osm, il faut simplement mettre
+à jour les informations de contact dans la base de données.
+}}}
+
+Charlie va regarder pour aller voir. 20-100 va regarder dans la base de données
+si ils sont bien à jour.
+
+Il faut créer un club rezosup, et le faire adhérer pour longtemps. Charlie s'en
+charge avec 20-100.
+
+* Les autres trucs redondants. La dernière fois j'ai demandé ce qu'il en était
+ du fameux quorum des virtualiseurs quand on reboote. C'est peut-être un
+ problème réglé (ou WONTFIX) mais je ne sais honnêtement pas, et ça peut pas
+ faire de mal de la rafraîchir dans la mémoire de tout le monde.
+
+On avait déjà vu ce point. Le quorum est à 2, et en cas d'urgence, il faut
+aller le modifier à 1 dans /etc/pve/corosync.conf
+
+* !MailMan : j'ai pas encore eu droit au code que PEB a fait tourner pour fix
+ l'encodage. Je voudrais réussir à tester mon
+ script {{{redisdead:/var/lib/mailman/bin/isthereencodingfail.py}}} avec un
+ Vrai Positif pour être sûr qu'il teste bien ce que je pense qu'il teste.
+
+Il reste quelques MLs qui ont des problèmes d'encodage sur l'inteface web : les
+MLs dont les adhésions sont générées automatiquement (ex respbats, roots).
+
+### Auth.py
+
+Couac avec la période de sursis, les 2A se sont fait massivement envoyer bouler
+par auth.py et placer sur le vlan accueil, réglé par
+Chirac (involontairement) et PEB. Cela ne devrait plus se reproduire. Bug
+également avec le bloq dans auth.py, ce qui explique bien des bugs rencontrés
+ces derniers mois…
+
+Détails : la période de sursis était évaluée au moment du lancement de auth.py
+Ã partir de config.py, or auth.py tourne depuis plusieurs semaines, parfois des
+mois sans être relancé. À partir de maintenant, la période de sursis est une
+méthode dans config.py qui est chargée à chaque check de has_access (methode
+lc_ldap qui évalue si un port/machine a accès ou non).
+
+Fixed par PEB, qui a transformé les mesures de temps en méthode, et qui sont
+donc exécutées au moment du test, et non au moment ou on lance auth.py
+
+### Questions diverses
+
+#### Virer SpamAssasin de MailMan
+
+C'est un projet au long court, il faut pas se précipiter, mais ça pourrait être
+pas mal d'y réfléchir. Il pète config_list, il rend la modération relou (les
+spams n'atteignent pas le filtre discard_these_nonmembers), il considère que
+les mails des caméras sont du spam. Il faudrait d'abord sonder un peu les
+utilisateurs de ML pour savoir si il leur sert.
+
+#> On regarde les datas et on en reparle plus tard
+
+#### Services.py et bcfg2
+
+"Quand on modifie services.py, il faut appliquer bcfg2 sur tous les serveurs
+pour mettre à jour services.py"
+Faux, c'est automatique.
+
+Autre exemple : ssh_known_hosts.
+
+#### Température 0B
+
+Google préconise 23°C, il faudra passer pour remonter, et changer les réglages
+munin pour éviter de l'avoir en "Problem"
+
+Un devis est passé pour une clim de secours, sans que cela soit une mauvaise
+idée, et étant données les prestations de la société actuelle, on peut troller
+sur la pertinence du truc.
+3400 €, douche comprise.
+
+On en reparle dans 2 semaines, après y avoir bien réfléchi.
+
+#### Page d'accueil
+
+Il faut trouver où mettre la page d'accueil créée par Myriam
+
+Pour dans 2 semaines, il faut que Myriam vienne faire une démo avant la mise en
+prod. Et on met le point plus haut dans l'ODJ.
+
+#### Mises à jour
+
+Rappel : les mises à jour consistent à lancer dist-upgrade, puis à vérifier
+après que tout marche…
+
+(la deuxième étape est --(aussi)-- plus importante que la première, il ne
+suffit pas de cocher la mise à jour comme "faite"…)
+
+Daniel est fâché à cause de ce qu'il s'est passé. Il rappelle la présence de
+systèmes de monitoring qui n'ont pas été vérifiés, voire des serveurs qui n'ont
+pas été rallumés.
+
+20-100 rappelle qu'il faut regarder les changelogs (qui sont obligés d'être
+affichés en cas de DU). Il faut les lire et les appliquer.
+
+Il faut vérifier que tout tourne à la fin aussi. Genre, utiliser le service qui
+a été mis à jour, ou qui a du être redémarré.
+
+#### Vieilles nounous
+
+Le droit existe, la suite ?
+
+On finit le script, et on revoit ça après : On veut éviter que des bots
+puissent juste exécuter le script et obtenir les droits roots en cas de compte
+corrompu. Du coup, une solution est proposée qui serait de poser une question
+secrète avant de rendre les droits. Par exemple : Quelle était
+ta "maman" ? Quelle était ta nounou préférée ?.
diff --git a/compte_rendus/2016_09_15.md b/compte_rendus/2016_09_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..70b3ff595d6046f5e502eb5521643b5ba146521f
--- /dev/null
+++ b/compte_rendus/2016_09_15.md
@@ -0,0 +1,106 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 15 septembre 2016
+* Lieu : Pavillon des Jardins
+* Début : 19h47
+* Fin : 20h55
+* <<Pad>>
+
+## Présents
+
+* 3 invités du Rézo : Shaka, Julien et Julien
+* Vincent Le Gallic
+* Rémi Oudin
+* Gabriel Detraz
+* Myriam Begel
+* Mathilde Espinasse
+* Charlie Jacomme
+* Michaël Paulon
+* Steeven Janny
+
+## Ordre du jour
+
+### Page d'accueil du Crans
+
+Myriam a fait du boulot, il y a juste quelques élément à recentrer. On pousse
+sur o2, et on va commencer par faire de la com, puis on verra si on fait un
+mode portail captif à la première connexion.
+
+Rémi va s'en occuper avec Myriam.
+
+### Achat d'une clim de secours
+
+Suite aux récents problèmes, l'idée d'une clim de secours a été amené. Il faut
+compter 3400€.
+
+Personne n'est convaincu de la réelle nécessité, il n'y en a pas eu besoin
+historiquement, et faire toute l'installation pour deux ans pourrait être
+overkill. Il y a certes eu une grosse série de problèmes (merci PEB d'avoir
+géré), mais maintenant qu'il est réglé cela devrait aller. Si d'autres
+personnes sont pour on pourra en rediscuter.
+
+### Digicode
+
+Le devis est de 70,40€, https://phabricator.crans.org/T115
+
+On est parti, on envoie ça au CA.
+
+### Serveur NAS
+
+On va pouvoir continuer la discussion, de solution concrète et de prix.
+
+Après discussion avec Anne, on va contacter le SAV avec elle et elle va nous
+aider à faire escalader le dossier. On reparlera du NAS dans un mois si échec.
+
+Rémi serait dispo pour gérer ça avec Anne, ce sera fait dans le courant de la
+semaine prochaine.
+
+### Trucs cassés
+
+* Ça fait plus d'une semaine que le [[http://irc.crans.org/web/|web irc]] est
+ cassé depuis le campus.
+
+Des problèmes quantiques à résoudre, il va falloir étudier la question
+
+* Idem pour [[https://intranet-dev.crans.org/|l'intranet de dev]], ce qui est
+ gênant pour les apprentis développant pour l'intranet --> Réparé par Chirac
+ hier.
+
+/!\ Attention, un effet pervers des gens qui tunnellent pour développer est
+qu'ils font souvent les migrations sans faire attention à être sous la bonne
+version de django ! Du coup, le tunnelling est fortement déconseillé si c'est
+pas bien fait.
+
+Il faudrait faire un check des différentes manières de faire tourner un
+intranet local, voir si on peut simplifier.
+
+### Achat de bornes
+
+Il n'y a plus de bornes en rab, Chirac suggère d'acheter 5 uap ac normales.
+
+https://www.senetic.fr/product/UAP-AC-LITE-5
+
+C'est validé pour 5. Envoi du devis au CA par Chirac.
+
+### Ram pour Stitch
+
+Le devis est d'environ 540€.
+
+Les gens sont pour, Charlie envoi le devis en CA.
+
+### Trucs useless
+
+Le gitweb, tudor propose de le démanteler et de s'en débarrasser.
+
+Ça a été annoncé 2 fois sans réaction par un apprentis qui n'ayant pas accés au
+log sur le serveur irc n'a pas pu aller plus loin.
+
+Des questions sont là : est-ce qu'on peut puller le git en http ? est-ce qu'on
+peut mapper les vieux dépôts vers gitlab, soit par redirection soit à la
+mano (attention à ne rien oublier).
+
+Charlie regardera ça d'ici la prochaine IN.
+
+### Nettoyage de printemps
+
+https://pad.crans.org/p/m%C3%A9nage
diff --git a/compte_rendus/2016_11_10.md b/compte_rendus/2016_11_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..5fc75c447ee96af77b72e9d6ec434101caa378a9
--- /dev/null
+++ b/compte_rendus/2016_11_10.md
@@ -0,0 +1,133 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 10 novembre 2016
+* Lieu : Pavillon des Jardins
+* Début : 19h00
+* Fin : 20h42
+* <<Pad>>
+
+## Présents
+
+* Fardale
+* Téou
+* Chirac
+* Dely
+
+## Ordre du jour
+
+Hamza a ammené des kinder délices, Hamza est gentil.
+
+### IPv6
+
+Il semble qu'il faille quitter sixxs, quelle est le plan de bataille ?
+
+Une idée est de commencer à utiliser le préfixe ares. L'avantage principal est
+qu'on pourra changer relativement facilement de provider tunnel IPv6 sans avoir
+besoin de rechanger toutes les adresses. Le désavantage est que ça crée une
+couche de complexité supplémentaire.
+Chirac indique que la configuration de {{{quagga}}} est easy, {{{mars}}} est
+d'ailleurs en proof of concept.
+Le pire qui puisse arriver est qu'on ait plus d'IPv6.
+
+Charlie, Chirac et Hamza votent pour utiliser le préfixe Ares.
+
+* Step 1 : tester le tunnel bgp HE
+* Step 2 : changer config.py, la BDD, et tous les trucs hardcodés qu'on trouve
+* Step 3 : réactiver le DNS IPv6
+
+Chirac fait la step 1, tache phabricator incoming.
+
+### Gros projets en cours
+
+Un petit tour de table pour voir où on en est sur le master backup, le
+monitoring, le firewall, la migration vers lc_ldap et d'autres trucs que
+j'oublie.
+
+Charlie :
+
+* Full master backup : Configuration stable du DHCP/DNS/radius/routeur sur
+ sable. Là , Il essaie de bien comprendre comment marche omapi…
+* Digicode : Il reste un peu de code à faire + comprendre comment le bidule qui
+ est actuellement en place marche (quel fil fait quoi ???)
+
+Dely :
+
+* Zamokv5 : La step1 est done, le plan de guerre est en place.
+* Firewall : Hamza attend toujours des retours sur le code, Guiness a commencer
+ Ã relire, mais faudrait qu'on se bouge les fesses.
+
+Il va le mettre en place sur sable, et on pourra faire des tests et faire
+mumuse.
+
+* Icinga : Le core du truc est en place, toutes les fonctions basiques
+ d'autostatus tournent sur icinga, mais il en manque encore quelques unes.
+
+On pousse icinga en prod, et on va essayer de rajouter les quelques plugins qui
+manquent le plus vite possible pour nuke autostatus.
+
+* KVM : Tout est commandé, ça arrive.
+
+Chirac :
+
+* Ipv6 et BGP : en cours, c'est tout frais.
+* DU de moinmoin : il faut faire un test sur soyouz des modules qui posent
+ problèmes, puis passer à l'action.
+
+### Services critiques et mineurs
+
+Une question à se poser est : est-ce qu'il y a au moins une nounou jeune
+capable de s'occuper des services critiques ? Il s'agirait de vérifier ça, et
+de pallier à d'éventuels trous.
+La même question se pose pour les services mineurs, mais en moins grave.
+
+Services upper dupper critiques :
+
+* Routage (Hamza et Chirac)
+* DHCP (Chirac et Charlie)
+* Radius (Chirac++, Hamza et Charlie +-)
+* DNS (Charlie++, Hamza +-)
+* ldap (Chirac et Hamza)
+* mail SMTP (Hamza++, Charlie +-)
+
+Services critiques, mais pas trop, enfin, y a internet quoi :
+
+* NFS (On utilise le script magique, et on a déjà monté des servs nfs à petite
+ échelle, par contre, iscsi, on est caca)
+* Gitlab (Chirac)
+* Bcfg2 (Y a un plugin custom, Hamza voit en gros)
+* Intranet (On a tous bouffé du python/django)
+* Irc (On y connait rien…)
+* Mail IMAP (On y connait rien)
+* Cas (C'est du Django, ok)
+* Webmail (Roundcube est packagé, c'est ok. Horde, on sait pas.)
+* Wiki (Charlie a refait une install sur soyouz, mais attention au plugin
+ custom)
+* Page perso (C'est apache, on connait pas)
+* Proxy Frontdaur (C'est ok)
+* Let's encrypt (Chirac et Charlie))
+* Thot, pqsl (On connait)
+* Tunnel soyouz (Hamza)
+* Backups (Hamza et Charlie)
+* Jabber (???)
+* Virtualisation (Ok)
+* Rabbitmq (On sait pas, Hamza a une vague idée)
+* Quota (Prout)
+
+Hamza : Apache et page perso
+Charlie : va bouffer du nfs et iscsi, et retravailler le mail SMTP
+Chirac : Mail Imap
+
+Guiness et la Loutre : bim sanction, z'avez qu'a pas être absent, jabber et irc
+et quota
+
+### Sogo ???
+
+Sogo est devenu payant pour les release prod, on a plus que les nightly builds.
+Il faut maintenant un beau support contract, qu'ils aillent *********
+On annonce une interruption de service pour dans un mois.
+
+### Augmentation des quotas pour les clubs
+
+Le club salsa est par exemple un peu à l'étroit. On sait pas ce qu'on peut
+faire avec quota, et faut savoir le faire marcher. Hamza et Fardale jettent un
+coup d’œil, mais pas trop loin pour pouvoir le récupérer quand même.
diff --git a/compte_rendus/2016_12_08.md b/compte_rendus/2016_12_08.md
new file mode 100644
index 0000000000000000000000000000000000000000..9244df293dd8e7fee6f71b8abe71c731b91d8cc1
--- /dev/null
+++ b/compte_rendus/2016_12_08.md
@@ -0,0 +1,84 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 8 décembre 2016
+* Lieu : Pavillon des Jardins
+* Début : 19h00
+* Fin : 20h00
+* <<Pad>>
+
+## Présents
+
+* Hamza Dely
+* Gabriel Detraz
+* Rémi Oudin
+* Kévin Le Run
+* Charlie Jacomme
+* Nathanël Gross--Humbert
+
+## Ordre du jour
+
+Hamza a amené un Kinder Bueno, Hamza est gentil.
+
+### IPv6
+
+Lance-t-on le bousin ?
+
+On peut en effet facilement créer un tunnel BGP chez HE. On est d'accord pour y
+passer, on lance donc l'opération.
+https://phabricator.crans.org/T136
+En première occurence, on ne s'occupe pas du plan d'adressage, et on modifie
+juste rapidement les préfixes.
+
+### Fails réseaux récents
+
+A priori, c'était pas notre faute \o/
+
+### Vlan 4
+
+Tous les switchs sont maintenant dans un vlan à part. Ils restent des choses Ã
+gérer, telles que les requêtes snmp pour le câblage.
+
+Les différentes solutions pour qu'on puisse avoir whos qui parle aux switchs :
+
+* Zamok prend une pate sur vlan4, un peu chiant vis à vis du firewall
+* Router le vlan 4 à partir d'odlyd, même problème.
+* Utiliser une clé ssh qui peux exécuter des commandes spécifiques sur thot.
+* Changer de serveur de cablage, thot, créer une vm ?
+
+Les logs sont déjà centralisés sur thot, y donner l'accès aux cableurs peux
+être intéressants.
+
+On décide donc de passer à la dernière options, le cablage se fera désormais
+sur thot.
+https://phabricator.crans.org/T137
+
+### Seconde intercalaire
+
+Faut-il faire quelque chose pour les serveurs ? Et pour le ntp ?
+
+ntp et tzdata sont (probablement) Ã jour, on fait confiance pour les serveurs.
+https://www.eecis.udel.edu/~mills/leap.html
+
+Par contre, l'imprimante......
+## L'imprimante a ntp de configuré, « It should be fine. » -- DS
+
+### Achat switchs
+
+Batp4, switch 8 ports non manageable. Minigiga a le même problème.
+Il faut aussi remplacer le switch de la med qui est parti au RU.
+
+Pour optimiser les switch, on va acheter un switchs qui fait du giga pour le
+mettre à la Kfet, et balancer le switchs Kfet à la med.
+
+Pour batp4 et minigiga, Chirac propose de le remplacer par un 2530-8G, qui
+coûte 474€. Batp-4 semble vraiment avoir besoin d'être changé, pour minigiga,
+c'est plus optionnel.
+
+Pour la Kfet, on partirait sur un 2920-24G POE, qui coûte ~1200€
+
+On demande un budget de 2000€ au CA.
+
+### KVM
+
+On s'est fait avoir, on a rien eu de livré et on s'est fait rembourser. Faut
+re-rechercher avec le budget du CA qui est toujours dans la course.
diff --git a/compte_rendus/2017_01_05.md b/compte_rendus/2017_01_05.md
new file mode 100644
index 0000000000000000000000000000000000000000..5d3a390d9b18ff3197bd5ec2297f0fa8afdd4b42
--- /dev/null
+++ b/compte_rendus/2017_01_05.md
@@ -0,0 +1,175 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 5 janvier
+* Lieu : Pavillon des Jardins
+* Début : 19h14
+* Fin : 20h10
+* <<Pad>>
+
+## Présents
+
+* Emmanuel Arrighi
+* Kévin Le Run
+* Michaël Paulon
+* Rémi Oudin
+* Daniel Stan
+* Martin Bauw
+* Vincent Le Gallic
+
+## Ordre du jour
+
+### Droits par défaut sur les homes
+
+Quelles devrait-être les droits par défauts sur les homes ?
+Y-a-t'il d'autres problèmes à régler ?
+
+Les droits par défaut sur les homes créés ont toujours été 755, jusqu'Ã
+récemment.
+Cela signifie que n'importe qui peut traverser ce home. Il s'avère que certains
+anciens
+ont décidé de changer ce droit par défaut, pour 700. Ceci empêche en
+particulier les
+pages perso de fonctionner, mais s'ils n'en ont pas, c'est leur droit. Il se
+trouve qu'un
+vieux a constaté que les droits sur son dossier www puis plus tard son home ont
+été changés (remis en 755), ce qui n'est pas quelque chose acceptable (il n'a
+pas
+été prévenu et s'est donc retrouvé avec des infos potentiellement privées
+dévoilées
+sur zamok).
+
+On ne sait pas de quand ça date, plusieurs hypothèses sont possibles (mise en
+place
+d'owncloud, migration des homes lors du split par lettre, erreur de manip d'une
+nounou),
+et l'intervalle fourni par le vieux en question est plus que large.
+
+Suite à la discussion sur #roots, PEB a déjà commité le changement de la
+création
+de nouveaux homes en 701 par défaut. D'un commun accord, tout le monde se rend
+compte que les adhérents pensent souvent à tort que leur home est par défaut
+privé, donc autant le rendre privé. Pourquoi 701 et pas 700: le bit à 1 pour
+others permet
+au serveur web sur zamok de traverser le dossier afin d'accéder au sous-dossier
+www (pages perso).
+Les droits sur le reste des homes déjà créés n'ont pas été changés suite au
+signalement (même si le vieux en question s'est occupé de son cas).
+
+* Mon avis sur la question est de
+
+changer tous les droits des homes en 701, par principe de précaution. On peut
+ensuite notifier les adhérents où le changement a été nécessaire (et pas avant,
+ce serait pas très responsable). Les quelques adhérents que ça dérange peuvent
+de toute façon revenir en arrière une fois le mail reçu (le mail devrait
+indiquer
+la procédure pour changer/vérifier les droits).
+Ça cassera peut-être *temporairement* des scripts à eux (mais je n'y crois
+pas), mais au moins, ça ne risque pas de dévoiler des données. -- WikiB2moo
+
+* Perso, je suis ravi que mon home soit accessible, mais ça me dérangera pas de
+ faire un bête chmod le jour où je recevrai le
+ mail. -- [[Chirac]] <<DateTime(2017-03-11T05:56:20Z)>>^W -- [[Wiki20-100]]
+
+20-100 fait remarquer qu'il ne faut pas toucher aux homes des clubs, qui sont
+traités d'une manière différente.
+
+Il faudra vérifier le commit de PEB pour voir s'il modifie les droits sur les
+homes clubs, sur les archives, les logs…
+
+On va passer les home des adhérents en 701 (uniquement la racine, pas tout…) et
+on fait gaffe aux clubs, logs, impressions…
+
+* Et par contre le fait que les clubs puissent voir tout ce qu'il y a dans les
+ www des adhérents, c'est pas
+ corrigé ? -- ZeldAurore <<DateTime(2017-03-16T18:40:51+0200)>>
+
+### Attaque DDOS
+
+Il faudrait s'assurer que tout le monde sait comment la détecter et quoi faire.
+Par ailleurs, il faudrait prévoir des moyens de communications de fallback, et
+des outils de gestion de crise.
+
+20-100 propose l'IRC !RezoSup (comme le screen hors campus est rare, un client
+web peut tout à fait faire l'affaire), Charlie a des réticences.
+Il est indispensable que ce ne soit pas une solution ad hoc implémentée par
+dessus la jambe par 2 cranseux, mais un truc fiable qui sera pas en rade le
+jour où le Crans le sera.
+On peut envisager un serveur IRC sur soyouz…
+On peut mettre le mode historique au chan, ce qui règle le problème du backlog
+et du screen.
+On choisit de prendre le chan {{{ #roots }}}
+
+* Daniel pense que le problème n'est pas dans un manque d'outil, mais un
+ problème humain. À la question "qui est responsable pendant les
+ vacances" (posées deux fois), il n'a obtenu aucune réponse. Il semblerait que
+ toutes les nounous soient parties en vacances sans se poser cette
+ question (la page CransVacances n'existait même pas). Le problème du ddos
+ avait été remarqué par Hamza dès le dimanche soir :
+
+{{{
+01:57:28 &dely | 138.231.$x.$y
+01:57:42* &dely | Cette machine s'est faite flooder salement
+}}}
+Le problème, c'est qu'Hamza n'allait pas bien et est parti faire autre chose,
+et personne n'a souhaité prendre le relai pour investiguer davantage.
+D'autre part, les outils de monitoring indiquent un grand trafic entrant, le
+graphe munin est un exemple
+criant: https://munin.crans.org/crans.org/odlyd.crans.org/if_ens.html
+https://cloud.tudo.re/index.php/s/bRv2NOwnzVZPy5j
+https://cloud.tudo.re/index.php/s/C1qb5XslpY8qEnL
+Malheureusement, les nounous ne consultent que trop peu ces monitorings, et ne
+se posent plus de question lors d'une nouvelle alerte (trop de faux positifs
+ou d'alertes non critiques qui *trainent* [cf certs sur soyouz et
+titanic : https://phabricator.crans.org/T142]). Bref, Ã quoi bon chercher de
+nouveaux outils quand les actuels ne sont pas utilisés…
+
+* Je suis d'accord avec cette remarque. Je pense que la désignation officielle
+ d'un moyen de comm' de backup ne résout pas tout mais serait utile en cas de
+ blackout. -- [[Wiki20-100]]
+* Il est indéniable que la communication n'est pas le seul problème, mais ça Ã
+ au moins l'intérêt d'être un problème qu'on peux régler assez facilement,
+ juste en se mettant d'accord. -- Charlie
+
+Il faut fix les routes de la freebox (ssh zamok depuis la freebox se fait
+refused).
+(FX-ilo est down, il faudra réparer ça. Ça date du changement de switch ilo.)
+
+On va aussi mettre à jour le wiki et envoyer un mail récapitulant les
+procédures.
+
+#### autostatus
+
+Il faudrait faire un effort collectif pour mieux utiliser les systèmes de
+monitoring (autostatus.crans.org, munin.crans.org) et clear tout pour que ça
+devienne propre à nouveau.
+
+Autostatus devrait être tout vert(/ouvert ?).
+
+### Taches phabricator
+
+Petit point des taches pour savoir où on en est (zamok, ipv6, câblage sur thot…)
+
+* zamokv5 : Planification en cours de la partie 2. Harcèlement des jeunes.
+* IPv6 : Hamza a fait la demande de tunnel. Chirac doit fournir un LoA de
+ l'ARES. Il faut finir ça au plus vite.
+* Câblage sur thot. Portage en cours, script de recherche dans les logs sur
+ thot.
+
+### Prise défectueuse
+
+sur nounou@ :
+{{{
+On 02/01/2017 13:17, $prénom $nom wrote:
+> Salut !
+> Je vous recontacte au sujet de ma prise éthernet défectueuse.
+> Je suis disponible cette après-midi, et tous les soirs de la semaine, ainsi
+que le weekend prochain.
+> Merci et bonne année !
+> $prénom $nom (bâtiment $b, chambre $room)
+}}}
+
+Blupon est intéressé pour apprendre, quelqu'un pour l'accompagner ?
+NB : il y a une deuxième demande sur respbats@ (au bât M iirc)
+
+Blupon, Mikachu, Fardale se synchronisent pour gérer ça.
+À voir s'il reste suffisamment de prises femelles non serties.
diff --git a/compte_rendus/2017_02_02.md b/compte_rendus/2017_02_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..aef357206dcdd1bbb5148bd324228bb191b96c20
--- /dev/null
+++ b/compte_rendus/2017_02_02.md
@@ -0,0 +1,128 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 2 février
+* Lieu : Pavillon des Jardins
+* Début : 19h16
+* Fin : 20h02
+
+## Présents
+
+* Clément Turck
+* Myriam Bégel
+* Rémi Oudin
+* Gabriel Détraz
+* Hamza Dély
+* Charlie Jacomme
+
+## Ordre du jour
+
+### Point sur les dernières opérations
+
+Firmware upgrade de la baie, des switchs, et j'en oublie. Qu'est-ce qui s'est
+bien passé, mal passé, qu'est-ce qui aurait pu mieux se passer.
+
+#### Baie
+
+Elle a été mise à jour… avec un Windows connecté sur un adm untagged par un
+switch programmé à l'arrache. Bref. Ça a marché. On n'en parlera plus jamais.
+
+Des opérations ont été faites sur la baie sans que l'on rencontre de remount en
+read-only, donc on a peut-être réglé nos problèmes.
+
+Il y a par contre toujours le problème du boot de zbee qui est caca, mais on a
+rien réussi à y faire. Il faut faire gaffe quand on reboot, une solution est de
+réinstaller zbee, mais ça fait potentiellement une grosse interruption de
+service. Ça peut attendre des vacances.
+
+#### Switchs
+
+Ils sont tous passés sur le nouveau VLAN qui est isolé, le 4. Ils ne sont
+visibles que depuis Thot, Fy, eap, pea, radius, sable. Ils ont aussi été
+firmware upgradés.
+
+Il y a un joli script pour faire les firmware upgrade et les majs de conf sur
+les switchs, /usr/scripts/gestion/majswitchs2.py
+
+Le câblage devra se faire par suite sur Thot.
+
+### Zamok v5
+
+Il reste les pages perso à conf, puis il va falloir planifier la grosse
+migration !
+Le portage des paquets a été long, mais c'est fait.
+Il reste les pages persos, dont la configuration est actuellement moisie.
+Hamza et Rémi investiguent.
+
+### IPv6
+
+La LoA a été faite, le tunnel est ouvert, il faut régler tout ça sur odlyd. On
+profiterait des vacances pour faire ça. On va essayer le premier week-end des
+vacances. Attention à la conf du daemon bgp (pas de redistribute
+OSPF) + modification de tous les trucs qui trainent, les IPs harcodés…
+
+* Ça veut dire quoi LoA ? -- ZeldAurore <<DateTime(2017-03-20T17:18:14+0200)>>
+
+### VPN par freebox en permanence
+
+Est-ce qu'on veut que le VPN pour soyouz soit en permanence branché sur
+titanic, ou que ce soit sur odlyd en permanence et sur titanic uniquement en
+fallback ?
+
+On garde en fixe sur titanic. On va pouvoir supprimer des scripts devenus
+inutiles.
+
+### Switchs - 2
+
+Donc, le switch acheté pour la Kfet est overkill, on pourrait plutôt le mettre
+au M, et acheter un 2530 (620euros). Le problème est qu'il faut des
+convertisseurs pour les bornes du M, soit 20 Ã un vingtaine d'euros.
+Celui de la Kfet ainsi remplacé irait au 5C.
+
+On demande 1400 euros au CA.
+
+### Charybde
+
+Les disques de charybde recommencent à faire des leurs, ça devient un peu
+récurrent… Ce serait peut-être pertinent d'avoir des disques en rab, ou de
+prendre des disques un peu plus solides ?
+
+On va racheter 5 disques de 2To, de meilleure qualité. Il faut faire une
+enquête sur Internet, Guinness est dessus.
+
+### Plan d'Investissement d'Avenir ARES
+
+Défendre un projet au CROUS avec un financement sur 10 ans semble être l'un des
+derniers moyen de s'implanter au CROUS Ã Saclay. Ce projet devrait s'inscrire
+dans un cadre plus gros que "juste" fournir l'accès à Internet.
+Un petit brainstorm sur l'ensemble des choses qu'on peux proposer pourrait
+servir.
+
+* domotique
+* système de note : compte pour payer plein de choses sur le campus (laverie,
+ CROUS, RU…)
+* Accès et réservation des locaux
+* Y-a-t'il de la place à la laverie ?
+
+### Gâteau
+
+C'était un mensonge :DDD
+
+Mais il y a une surprise, des nouvelles nounous !
+
+Nous proposons donc à Bernie' et Myriam de devenir nounous.
+
+Iels acceptent.
+
+Bernie fait un discours :
+Il appelle son coiffeur avant, qu'iel le recoiffe. Il refuse qu'on touche à ses
+cheveux, belle confiance envers Guinness, ça promet…
+
+### Mail pour les home
+
+Rédaction !?
+A vos avis :
+https://pad.crans.org/p/mail_home
+
+### Jap
+
+Guinness nous a trahi !!!!!
diff --git a/compte_rendus/2017_03_02.md b/compte_rendus/2017_03_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..00d9db5c8cd8057471001878245879070d5ecbb4
--- /dev/null
+++ b/compte_rendus/2017_03_02.md
@@ -0,0 +1,28 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 2 mars 2017
+* Lieu : 2B
+* Début : 20h00
+* Fin : 20h52
+* <<Pad>>
+
+## Présents
+
+## Ordre du jour
+
+### Old Baie
+
+Whatdowedowithit ???
+
+On la donne à une association dans le besoin, donnée "as is". Chirac diffuse
+l'offre auprès de ses partenaires.
+
+### Rezo Sup
+
+Nous estimons que la fiabilité du service proposé par le Crans n'est pas
+suffisamment élevée pour s'engager auprès d'un groupe extérieur de personnes
+sur ce genre de service.
+Nous souhaitons par ailleurs pouvoir nous concentrer sur améliorer la qualité
+des services que nous proposons actuellement, plutôt que d'éparpiller nos
+efforts.
+Nous encourageons fortement FedeRez à se porter candidat avec son dédié.
diff --git a/compte_rendus/2017_04_06.md b/compte_rendus/2017_04_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..a6f4f930b856f8ed3bf477836858dc01eb38ce0e
--- /dev/null
+++ b/compte_rendus/2017_04_06.md
@@ -0,0 +1,112 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 6 avril 2017
+* Lieu : 2B
+* Début : 19h12
+* Fin : 22h04
+* <<Pad>>
+
+## Présents
+
+* Charlie Jacomme
+* Gabriel Détraz
+* Rémi Oudin
+
+## Ordre du jour
+
+### Changement du mot de passe root et du mot de passe LDAP
+
+Ça fait longtemps que ça n'a pas été fait, je pense que ça serait une bonne
+chose de le faire.
+
+PS 1 : jben m'a dit qu'il connaissait le mot de passe du LDAP, donc ça
+fait *vraiment* longtemps que ça n'a pas été fait...
+
+PS 2 : En plus le mot de passe root est super chiant à taper
+
+1) Mot de passe root, c'est easy, on fait ça de suite
+
+C'est fait.
+
+Pour être sûr que toutes les nounous sont aux courants, le nouveau mot de passe
+est donc :
+!Pr0uTtot0
+
+2) Mot de passe LDAP, easy aussi
+
+C'est fait. C'était très long...
+
+### Achat de switch/bornes
+
+Toujours dans l'esprit d'améliorer la couverture wifi, on continue la réflexion
+sur l'achat de switch et de bornes.
+Il est à noter que la borne installée au 2B fonctionne, il n'y aurait donc pas
+de problème avec les UAP AC Pro en générale, mais juste celle de la Kfet.
+
+* C'est l'image de la borne, ou c'est le matériel physique ? -> matériel
+ d'après Hamza
+ On ne sait pas trop, il faudrait tenter de reflash la borne pour fixer la
+ question.
+
+On souhaite remplacer les anciennes pico station qui sont totalement outdated
+par des UAP AC Pro, il en faudrait donc une vingtaine. (2800€)
+
+Pour les toits, il faudrait acheter environ 5 nano
+stations (80 euros/borne, 400€). Remarque : faire attention à ne pas se faire
+refourguer des bornes avec bug matériel
+
+Lorsque l'on remplace une pico par une UAC, il faut soit mettre une adaptateur
+POE actif, soit carrément remplacer le switch par un switch POE. La seconde
+méthode, plus couteuse, à l'avantage de permettre de reboot les bornes Ã
+distances.
+
+Les H,I,J seraient les principaux problèmes, on pourrait faire l'achat
+de 3 switchs : 3 x 800 = 2400€
+
+On demanderait donc un budget autour d'environ 5800€ pour améliorer la
+couverture wifi du crans.
+## 5k8€, c'est pas 5.8k€ ! 5k8€ ça veut
+dire 5008€ ! -- ZeldAurore <<DateTime(2017-05-05T11:51:31+0200)>>
+
+### Maintenance du nœud IRC
+
+Suite à l'internounous du 10/11/2016, il avait été décidé que Rémi s'occuperait
+de InspIRCd et du nœud IRC. Il demande donc à devenir IRCOp pour pouvoir
+s'occuper du nœud.
+
+La demande est bien évidemment validé.
+
+### Machines de FedeRez
+
+Il semblerait qu'une des machines de FedeRez (hébergée sur Kdell) envoie
+beaucoup de données.
+
+Elle n'a donc a priori pas d'exceptions dans le comptage.
+Il faudrait peut-être décider si on doit en mettre un ou pas
+non ? :-° -- Guinness
+
+On exempte donc kdell et octogon du comptage d'upload : Kdell gère les backups
+et octogon le gitlab.
+
+### Support
+
+PEB avait installer un redmine il y a environ un an. Le projet est en friche,
+et la vm, abandonnée, on la supprime.
+
+### Odlyd et ses défaillances
+
+xtables--addons n'est pas dans les backports, ce qui nous bloque dans les mises
+à jour du noyau d'odlyd. C'est un problème car les symboles de debugage de
+cette version du noyau ne sont pas packagé, et donc pour le moment les crash
+kdump sont inexploitable.
+Il faut trouver une solution, l'une de celles envisagées est de passer sous
+stretch. Folie pure ?
+L'autre est de continuer à repackager à chaque fois, ce qui n'est pas vraiment
+une solution très maintenable.
+
+### Generate et firewall
+
+Il faudrait faire une passe finale de reviewing, puis ce serait bien de les
+mettre en prod.
+On essaie de tous regarder ça d'ici l'internounous prochaine, à la fin de
+l'internounous, la décision sera prise.
diff --git a/compte_rendus/2017_05_04.md b/compte_rendus/2017_05_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..8c382b7f16115624f5e62d585129a463e62746c6
--- /dev/null
+++ b/compte_rendus/2017_05_04.md
@@ -0,0 +1,77 @@
+# Réunion du Collège Technique
+
+* Date :
+* Lieu : 2B
+* Début : 19h03
+* Fin :
+* <<Pad>>
+
+## Présents
+
+## Ordre du jour
+
+### Routeur
+
+Un problème de soft a été mis en évidence, plusieurs idées ont été proposés.
+Routage ipv6 sur une vm, achat d'un vrai serveur capable d'assurer la charge de
+full master backup...
+
+Routage ipv6 sur une vm. Prévoir assez d'espace disque pour les crashs et le
+logall.
+
+sable rame du cul, il faut comprendre pourquoi.
+
+#> mesurer le debit ()
+
+migrer le service de sable sur un autre serveur physique ?
+
+* reutilisation d'un serveur existant plutot que l'achat d'un nouveau ?
+
+### Monitoring
+
+Icinga2 a été déployé, grafana a été proposé. Quelle est notre objectif finale ?
+
+Il semblerait que les deux peuvent à la fois remplacer autostatus et grafana,
+il faudra se décider un jour.
+
+Il y actuellement trop de problèmes de confs d'icinga2, ça crée un max d'alerte
+boggus non pertinente et ça noie les vraies problèmes.
+
+Donc :
+
+* Hamza essaie de régler un max de fausses alertes
+* Dès que c'est fait on down autostatus
+* En parallèle, Mikachu avance sur grafana.
+
+### Charydbe, disque
+
+http://www.ldlc.com/fiche/PB00148466.html
+
+Chirac propose de prendre des disques plus grand (4T), de ce genre là :
+http://www.ldlc.com/fiche/PB00217787.html
+http://www.ldlc.com/fiche/PB00190297.html
+
+On balance un devis de 1300€ au CA.
+
+### Renouvellement de la garantie de pulsar, batterie fatigué
+
+On considère que le renouvellement de garantie n'est pas nécessairement
+pertinent, au vu de l'âge de la bête.
+On envisage à long ou moyen termes de le remplacer.
+
+### openWRT
+
+L'état de dev d'openWRT est douteux, les core developpeur sont partis faire
+mumuse avec LEDE.
+Il faut suivre l'évolution de l'affaire, et envisager de passer à LEDE
+
+### Code review
+
+Objectif, regarder le nouveau firewall et generate
+
+Dès que possible, on le test, sur ipv6.
+
+### Gateaux
+
+Pas de gateaux, tant pis.
+Mais Mikachu et Fardale sont nommés nounous ! :D
diff --git a/compte_rendus/2017_06_08.md b/compte_rendus/2017_06_08.md
new file mode 100644
index 0000000000000000000000000000000000000000..b8ad002f7cbf1c7cb197628b5957d69a26fe4389
--- /dev/null
+++ b/compte_rendus/2017_06_08.md
@@ -0,0 +1,195 @@
+# Réunion du Conseil d'Administration et du Conseil Technique
+
+* Date : Jeudi 8 juin 2017
+* Lieu : Pavillon des Jardins
+* Début : 19h03
+* Fin : 20h 33
+
+Présents :
+
+* Gabriel Detraz
+* Michael Paulon (procuration de Rémi Oudin)
+* Nicolas Gasnier
+* Rémy Garnier
+* Charlie Jacomme
+* Emmanuel Arrighi (arrivé à 19h04)
+* Florent Marconi
+
+Exilés (mais toujours présents dans nos cœurs) :
+
+* Mathilde Espinasse
+* Rémi Oudin
+
+### Ordre du jour
+
+#### Budget 2B
+
+On propose un budget de 500€ pour le 2B. Ce point sera soumis au vote du CA.Les
+nounous demandent plus de budget et remarquent que le 2B est sale et qu'il
+faudrait le ranger.
+
+* Pour : 4
+* Contre : 0
+* Abstentions : 0
+
+Le Budget est donc approuvé à l'unanimité des votants.
+
+#### Point rentrée
+
+Il faudra modifier et remettre à jour les livrets CRANS (et les
+réimprimer) : il faut fixer une deadline pour la version finale (15 août),
+commandes de consommables à faire pour la rentrée .
+La rentrée Crous à lieu du 29 au 30 août
+
+Il reste environ 280 câbles. Nicolas propose d'en commander. Le budget serait
+d'environ 2€ par câble
+pour 1000 câbles. (https://www.maison-du-cable.com/Prix/Cable-RJ45-Cat5e-U-UTP-5M-6646.html (câble blanc))
+Stockage au 0A.
+On propose un budget de 2000€ pour les câbles. Ce point sera soumis au vote du
+CA.
+
+* Pour : 4
+* Contre : 0
+* Abstentions : 0
+
+Le Budget est donc approuvé à l'unanimité des votants.
+
+Étude du choix des goodies pour la rentrée. Les propositions sont :
+
+* Stickers (environ 800€ les 5000). Voir avec FedeRez pour leur fournisseur. On
+ propose aussi des stickers avec la possibilité de mettre les login dessus.
+ chez FedeRez : fournisseur Camaloon
+* Clés USB :
+ * Mauvaise expérience et potentiellement assez cher.
+ * Difficile d'en avoir de bonne qualité pour un budget raisonnable.
+ * En donner à la fin des séminaires avec les slides dessus?
+* Des peluches !
+
+Quand les distribuer ?
+
+* À la rentrée ?
+* À la soirée CRANS ? A priori oui pour les peluches. Proposer des goodies Ã
+ distribuer à la soirée permet d'en commander une plus petite quantité, et de
+ quand même inonder le campus de goodies stylé.
+
+Accord de principe pour des peluches et des stickers. Budget à fixer au
+prochain CA.
+
+#### Point WEI
+
+Fixer une deadline pour les versions à imprimer des livrets WEI.
+Les livrets envoyés après cette date seront facturés.
+Idée : 1 septembre deadline, 10 septembre on imprime plus rien.
+Décision finale :
+
+* 15 aout pour le livret BDE, Ã partir du 1er septembre on imprime plus.
+* 5 septembre pour les livrets bus, après le 10 septembre on fait rien du tout.
+
+Faites beaucoup de comm' auprès du BDE pour que l'info arrive jusqu'aux bus :)
+
+Réfléchir à l'animation. Twister sur clavier ? Pourquoi on a des buts de
+water-polo ?
+Nettoyer le Twister pour l'utiliser.
+
+#### Communication externe
+
+On propose une mise à jour de la charte graphique du Crans.
+
+* Nouveau logo : EkstaProd et proposer à Pensil)
+ * Deadline : 30 juillet.
+ * Charte graphique :
+ * garder l'arobase ?
+ * prise RJ45 ?
+ * Finalement pas de contraintes imposées.
+* Création d'un site web, statique (utilisation d'outils non libres ?).
+ * Objectifs :
+ * Com externe
+ * Information rapide et FAQ pour les gens ne pouvant pas utiliser le wiki
+ * Dissociation wiki. Minimiser le nombre d'interaction vers le wiki.
+ * Centraliser les infos essentielles
+ * Newsletter
+
+Un nouveau site web, qui un peu dans l'idée de la page d'accueil de Myriam,
+serait cependant plus orienté vers les gens extérieur et/ou qui y connaissent
+pas grand chose. Donc, une présentation rapide du Crans, une FAQ, les infos
+essentielles/news (ça marche, ça marche pas, les événements, etc). Il faut
+aussi qu'il permette d'afficher les communications faites sur facebook/twitter…
+
+#### Modernisation des adhésions
+
+Étude du fait de rendre obligatoire la création d'un compte Crans.
+Création d'office pour éviter les problèmes de paiement (accès au données,
+problème légaux) et les problèmes de présence aux permanences
+Avancer sur l'archivage des comptes non utilisés
+On décide de créer automatiquement un compte crans à l'inscription.
+
+Une proposition, permettre aux gens d'adhérer totalement en ligne. Cela
+n'empêche de tenir les perms rentrée crous pour rester le premier contact
+des 1A.
+Pour la réadhésion plutôt que l'adhésion? Difficulté pour trouver des câbleurs
+en août. Possibilité d'activation temporaire.
+Faire ça depuis une prise ? Problème de validation du statut d'étudiant et des
+noms.
+Possibilité d'adhérer que pour le Wifi? Réduction effective des charges des
+permanences? Question de la nécessité du contrôle d'identité.
+Faire la réadhésion par Internet est plutôt simple, la première adhésion pose
+plusieurs problèmes (contrôle de l'identité).
+
+On décide de créer un nouveau système pour les réadhésions. Pour les nouvelles
+adhésions, on propose de tester un outil pour les vacances.
+
+* Objectif pour la rentrée : Avoir le système de réadhésion qui
+ fonctionne + modifier le mail de fin d'adhésion
+* Objectif plus long terme : Pouvoir, par exemple lors des vacances, proposer
+ aux gens d'adhérer totalement en ligne.
+
+Limiter le nombre de permanences (en particulier le midi)
+3 permanences fixes (lundi, mercredi et vendredi soir) et on essaie de les
+tenir. Non. On les tient. Point.
+Perm officiel le midi? Un système de prise de rendez-vous pour les gens qui ne
+peuvent pas venir le soir.
+Difficulté avec le vendredi soir
+Faire des flyers pour le CROUS pour donner les heures de permanence et
+l'adresse mail de contact au cas où.
+Politique random pour les vacances.
+
+#### Portail captif
+
+Création d'un portail captif pouvant être réutilisé suivant les
+évènements(installs partys, conférences, PR…).
+Il en existe déjà , à faire nous même ou pas ? Gabriel s'en charge.
+
+#### Les 20 ans du Cr@ns
+
+:: https://pad.crans.org/p/20Ans
+:: Fusion journée Federez (soirée)
+:: Recenser les idées.
+:: Demander une subvention CVE pour la sécurité.
+:: Remplir le pad d'idées.
+
+#### Textiles
+
+:: Relancer une commande de textiles.
+:: On attend le logo.
+
+#### Le droit mailing
+
+On garde le droit modérateur (à l'origine pour modérer les News) et on
+l'autorise à créer des ML.
+
+#### Divers
+
+:: On demande un badge du portail au CROUS.
+:: Permanences PR : aléatoires en fonction des disponibilités.
+:: On relance la commande des disques WD RED pour Charybde : déja fait.
+:: Croissants AGO : Nicolas rembourse les croissants.
+
+#### Remarques
+
+* PEB a fait remarquer que changer les barillet du 2B reste pertinent, il
+ semblerait qu'il y ait des clés qui aient disparu avec des membres actifs aux
+ alentours de 2012. On a retrouvé les MA ou les clés ? Il semblerait que non.
+* Charlie sera absent de la fin de cette réunion jusqu'au 1er juillet.
+ Contactable par téléphone ou mail en cas d'urgence, il sera sinon en train de
+ siroter un cocktail sur une plage de sable blanc. Ou en train d'essayer
+ d'avoir l'agreg, Au choix.
diff --git a/compte_rendus/2017_09_28.md b/compte_rendus/2017_09_28.md
new file mode 100644
index 0000000000000000000000000000000000000000..6c2203c11d5fa3c07e258e06b961237b00bd0420
--- /dev/null
+++ b/compte_rendus/2017_09_28.md
@@ -0,0 +1,162 @@
+# Réunion du Collège Technique
+
+* Date : Jeudi 28 septembre 2017
+* Lieu : Pavillon des Jardins
+* Début : 19h00
+* Fin : 21h00
+* <<Pad>>
+
+## Présents
+
+* Gabriel Détraz
+* Charlie Jacomme
+* Clément Turck
+* Maxime Bombar
+* Nathanël Gross--Humbert
+* Zéphyr Salvy
+* Thomas Bauvent
+* Nicolas Gasnier
+* Gabriel Le Bouder
+* Hamza Dely
+* Raymon Zhang
+
+## Ordre du jour
+
+### Présentation générale
+
+Charlie fait une présentation du collège technique et de son utilité. Il
+rappelle qu'il ne faut pas avoir peur des discussions techniques et de poser
+des questions.
+
+### Freeradius 3.0
+
+Hamza a remis intégralement à neuf le système freeradius et nous l'a présenté.
+
+Première nouveauté, implémentation de la reconnexion dynamique. Ça marche pour
+les bornes, et pour 1/3 des switchs.
+Deuxième nouveauté, les vlans dynamiques qui permettent de rediriger quelqu'un
+là où elle est censé être.
+Troisième nouveauté, en cas de base en RO, freeradius ne meurt pas, et on ne
+perd pas tout le réseau.
+
+On lance les tests sur le bâtiment I.
+
+### New switches
+
+Avoir quelques switchs neuf de rab, pour remplacer en cas de besoin.
+
+On a un stack de vieux switchs au 2B, ça pourrait être pertinent d'avoir des
+switchs plus récents qui supportent des protocoles plus récents.
+Sur le parc :
+
+* 16 2650
+* 5 2626
+
+On remplace les 5 2626 par les 2910, et on aura 3 nouveaux switchs (si le CA
+est gentil) de roulement.
+
+### 802.1ad
+
+La techno nous permettrait de propager tous nos vlans côté ENS en les fourrant
+dans un seul. Magie ?
+
+On verra plus tard. Hamza envoie un mail.
+
+### Mail et blacklist
+
+Comment éviter de se faire blacklister par des hébergeurs de mail ? Remise en
+mode slow ?
+
+On pourrait essayer de configurer une limite par heure et par journée sur
+policyd.
+Est-ce qu'il est possible de désactiver le compte SMTP d'un mec qui spam, de
+manière temporaire.
+
+Rappel de la campagne de changement de mot de passe. => Zéphyr, Gabriel et
+Thomas sont motivés pour s'en charger, encadrés par Bernie et Charlie.
+
+### Garanties
+
+Fz et Thot sortent de garantie en décembre. Renouvellement ?
+
+* Thot, y a pas de question, oui on renouvelle
+* Pour fz, vu son âge on hésite, une option serait de le laisser continuer
+ tranquillement son rôle de fallback dans le cluster, et de le remplacer le
+ jour où il meurt. Hamza dit que si on laisse ça comme ça, quand fz mourra, on
+ aura la flemme de racheter un serveur.
+
+Donc, si on a la flemme, Hamza pourra dire "je vous l'avais bien dit". En
+attendant, on renouvelle pas.
+
+### Ménages
+
+Trop de ML qui servent à rien. Destruction !
+
+https://zero.crans.org/?1ca91a8ddda337fd#OgA0bP/VB++Tuq8641WC9a4J8s7pyBOap+jTKOXFS2c
+
+Zéroième étape, on augmente la taille de redisdead.
+
+Première étape, on contact les modérateurs de MLs trop vieilles pour savoir si
+ils sont en vie.
+
+### Volume de backups
+
+Zéphir est à 80% d'usage de disque, avec une croissance de 25% sur 1 an. On ne
+tiendra donc plus un an avec /a priori/.
+Deux possibilités, on augmente l'espace de stockage, ou alors on réduit la
+durée sur laquelle on backup.
+Any thoughts ?
+
+On réduit violemment le nombre de back up, genre par 2, mais en gardant un
+back-up de 6 mois.
+
+À voir si backuppc propose pas un autre algo de compression.
+
+Charlie regarde.
+
+### Futur du Crans
+
+#### Fibre
+
+On veut prendre une fibre indépendante de RENATER, pour se préparer à quand ils
+seront plus là . Plusieurs demandes de devis ont été faites, on s'interroge sur
+les questions de la qualité de la connexion.
+Qu'est ce que c'est ti qu'on veux:
+
+* GTR 24/24 7/7
+* 1gb/sec
+* port 10gb
+
+Il faut éplucher les contrats. Comment se renseigner sur leur service de
+qualité ? -> FedeRez ?
+
+#### Infra
+
+Le Crans doit simplifier son infra pour se pérenniser et doit devenir
+indépendant d'un point de vue fibre. Cela implique des grosses décisions
+technique, et de ne pas faire n'importe quoi.
+La fibre, c'est facile. Le reste de l'infra, on sait pas quoi faire, ou plutôt
+ou n'est pas tous d'accord. Il y a des conditions inamovibles, on ne mettra PAS
+un truc bancales en prod, si on pousse quelque chose, ce sera un beau produit
+finit. Pour le reste, on verra.
+
+### Responsabilités
+
+Rappel sur le bon usage des droits Crans.
+Chirac avait renommé une machine d'adhérent pour pouvoir en donner le nom à un
+serveur Crans. Il reconnait que c'était une bêtise. Si l'acte est moralement
+répréhensible, cela reste en pratique sans conséquence, il y a donc simplement
+un avertissement qui est émis.
+
+On en profite pour rappeler les petites erreurs de ce genre que l'on peut
+faire, sans toujours s'en rendre compte.
+
+* whokfet
+* whos
+* IRCop
+* Upload depuis vo.
+* ménage câbleur sauvage
+* Blacklist de quelqu'un qu'on aime pas
+* ...
+
+Bref, un grand pouvoir implique de grandes responsabilités.
diff --git a/compte_rendus/2017_11_22.md b/compte_rendus/2017_11_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..98f80ee1eea214ed9ebb65286e92d935e31a03a6
--- /dev/null
+++ b/compte_rendus/2017_11_22.md
@@ -0,0 +1,194 @@
+# Réunion du Collège Technique
+
+* Date : 22/11/17
+* Lieu : 5A
+* Début : 19h06
+* Fin : 21h17
+* <<Pad>>
+
+## Présents
+
+* Gabriel Détraz
+* Maxime Bombar
+* Martin Bauw
+* Gabriel Le Bouder
+* Rémi Oudin
+* Michael Paulon
+* Benjamin Graillot
+* Charlie Jacomme
+* Hamza Dely
+* Nicolas Gasnier
+
+## Starring
+
+* PEB
+
+## Ordre du jour
+
+### Signature du contrat pour la fibre
+
+Le contrat est signé, vive le contrat !
+
+### Onduleur is tired
+
+On avait dit il y a un moment qu'on laissait l'onduleur dans son état actuel,
+i.e.
+qu'on ne changeait pas ses batteries ni ne prolongeait sa garantie. Ça commence
+Ã faire un petit moment, il est temps de resoulever la question.
+
+On décide de faire une demande de devis pour renouveler l'onduleur. On va faire
+des demandes pour des intensités de sortie de 2kVA, 2.5kVA et 3kVA. On garde
+45 minutes d'autonomie.
+
+### Renouvellements garantie
+
+Fz et thot arrivent au bout, est-ce qu'on prolonge ?
+Pour FZ on ne renouvelle pas.
+Pour Thot on avait déja validé à la dernière IN, on envoie ça au vote du CA.
+
+### Fy ou "De l'art de la PLS"
+
+Ce bon vieux Fy commence à avoir du mal avec le monitoring, il faudra peut être
+revoir la façon dont on gère le monitoring et/ou penser à déléguer certaines
+taches
+à des VMs. (ça éviterai aussi de perdre tout le monitoring quand Fy plante)
+
+Finalement, il semblerait que Fy ne soit pas tant que cela en PLS, nous passons
+donc au point suivant.
+
+### La nouvelle fibre is coming
+
+Il faudrait réfléchir au plan d'attaque pour quand la fibre sera là , dans les
+grands lignes au moins.
+
+Chirac s'occupe de la partie administrative et pose de la fibre.
+
+Ce qui a été fait :
+
+* rendez-vous avec le responsable patrimoine Crous
+* prise de contact avec la mairie
+
+Ce qu'il reste à faire :
+
+* déterminer le point d'entrée de la nouvelle fibre et le point de raccordement
+ Ã l'infra actuelle -> 0B
+* si c'est le 0B, investir dans un module 10 gig fibre ou cuivre suivant ce que
+ le routeur juniper délivrera. -> oui, il faudra un module 10Giga pour le
+ backbone. Il faut se renseigner sur
+ la connectique du provider.
+* idem avec la carte réseau d'odlyd et de sable -> cf au dessus
+* planifier le déploiement de nouveaux vlans etc d'abord pour du test, en lien
+ avec re2o ? -> re2o est en phase de tests, on va pas prévoir de l'utiliser dès
+ maintenant.
+* suggestion, basculer le wifi federez sur la nouvelle fibre assez
+ rapidement (facile à faire, indépendant de lc_ldap et de la bdd crans
+ actuelle) -> On pourrait potentiellement switcher tous le wifi.
+
+Suite à des problèmes de configuration de Munin, on a pas la proprtion de BP
+utilisé pour le filaire vs le wifi. Il faut fixe la conf, pour avoir des stats
+sur l'utilisation en BP du wifi.
+
+Selon, il faudrait voir si c'est pertinent de mettre dans un premier temps
+uniquement les machines wifi sur la nouvelle fibre.
+
+* envisager le système de nat à mettre en place en ipv4, proposition : nat par
+ plage de 1000 ports sur ip publique par ip privée derrière; ce qui donne au
+ maximum 65000 ip privée (on a de quoi faire) -> Comme premier plan, si c'est
+ pertinent vis a vis de la BP
+
+Remarque générale : est-ce que ça relance l'idée du miroir debian commun avec
+l'ENS, car cela libère l'utilisation de la fibre principale.
+
+### Re2o
+
+Concernant la période d'essai re2o, il faudrait qu'on se fixe quelques petites
+tâches à faire dessus pour avancer.
+
+Ce qui a été fait côté projet :
+
+* réunion de cadrage, le CR a été envoyé sur nounous des principaux dev
+* projet migré sur le gitlab de federez, avec de la CI. De nouveaux dev se sont
+ rajoutés.
+* politique de review obligatoire par un set de dev avant merge de nouveaux
+ commits sur master
+
+Ce qui a été fait coté Crans :
+
+* mise en place d'une instance de test sur re2o-server et re2o-ldap
+* tests de migration de la bdd (à peu près 70%) des données, manquant encore
+ l'historique
+
+Ce qui reste à faire :
+
+* auditer les manques fonctionnels de re2o pour le crans
+* envisager des améliorations et les classer par ordre de priorité, de
+ l'important lié au fonctionnel au cosmétique non prioritaire
+
+Après beaucoup de discussion autour de re2o, de l'option de faire évoluer
+l'infra et de l'avenir du crans en générale, 3 questions ont été posé aux
+présents.
+4 sont pour bosser sur re2o en collaborant avec tous les campus
+1 est pour avoir au final au crans un fork re2o
+7 sont pour evolution de l'infra actuelle
+
+Conclusion : On laisse tomber la période d'essai re2o, on lance l'évolution Ã
+fond.
+
+Premier objectifs faisable sans trop discuter :
+
+* brûler ldap_crans (cf code review pour guiness)
+* Documenter ce qui ne l'est pas
+
+### Switchs
+
+Chirac a demandé à Anne une cotation pour 20 switchs soit 2530-48G
+soit 2930-48G, pour éradiquer les 2650 qu'il reste (16). Il espère avoir des
+résultats pour l'IN.
+
+Possibilité 1 : commande de 20 nouveaux switchs 2530-48G ou 2930-48G
+
+Possibilité 2 : plus économique, racheter les 2910-al de ex supelec rezo.
+Avantage, ils valent 100-200 euros à l'argus, sont garantis à vie, et vu qu'on
+a déjà pas mal de 2910-al, cela garde la cohérence dans les différents modèles
+qu'on a.
+
+Problème, ils n'en ont que 9 - 48 ports donc il faudra compléter avec des neufs.
+
+On demande au CA d'acheter 16 switchs 2530-48G, pour environ 14k€
+
+### Politique de modification des comptes
+
+Fardale avait envoyé un mail sur le sujet qui a soulevé quelques réactions mais
+ce n'est pas allé plus loin. Il faudrait finir de répondre à cette question.
+(Si je n'ai pas le temps de développer ce point il pourra être ignoré)
+
+#> Ce genre de modifications semble engager d'un point de vue légal le CA. On
+propose que le CA voit en premier et décide du concept, le CT dira si c'est
+possible ou non.
+
+### Internet aux SDA
+
+Il faut répondre à Olympio sur la question d'internet au SDA. Je pense que
+c'est un oui, mais vu qu'il y a une IN autant que ça soit validé par tous.
+
+#> Charlie présent, mais potentiellement occupé. Bernie est potentiellement
+disponible, mais ne peut s'engager tout de suite. Des peut-êtres du côté de
+Pollion, Boudy, Mikachu.
+
+Bref, on dit oui.
+
+### Discourse
+
+Nous décidons à l'unanimité de dire au revoir à Discourse, qui n'aura pas su
+s’implanter avec succès sur le campus.
+
+Attention, il faut faire un back-up !
+
+### Cake
+
+There will be a cake. I swear !
+
+## The Cake is a lie
+
+Il n'y a finalement pas eu de gateau, le RTC est un vil menteur.
+Par contre, bienvenue à Boudy, Blupon et Pollion parmis les nounous !!!
diff --git a/compte_rendus/2017_12_20.md b/compte_rendus/2017_12_20.md
new file mode 100644
index 0000000000000000000000000000000000000000..782dd6842042011b43d0d36c315b766042864751
--- /dev/null
+++ b/compte_rendus/2017_12_20.md
@@ -0,0 +1,145 @@
+# Réunion du Collège Technique
+
+* Date : 20 décembre 2017
+* Lieu : Maison de l'Étudiant
+* Début : 18h00
+* Fin : 19h42
+* <<Pad>>
+
+## Présents
+
+* Blupon
+* Boudy
+* Charlie
+* Chirac
+* Esum
+* Pollion
+* Fardale (auditeur libre)
+* Gasnier (arrivé à 18h11)
+* Bernie' (arrivé à 18h14)
+* Grizzly (arrivé à 18h28)
+
+## Ordre du jour
+
+### Soyouz
+
+Renouvellement ? Upgrade ?
+
+Personne n'aura le temps de le changer d'ici le 31.
+
+Par contre, on change le renouvellement qui était annuel pour le passer Ã
+trimestriel. Ceci permet à une personne intéressée pour le changer de ne pas
+attendre un an.
+
+Si quelqu'un trouve une meilleur offre il est le bienvenu.
+
+### Upgrade de vo
+
+Certaines personnes veulent changer Vo.
+
+Le point est repoussé car les demandeurs ne sont pas présents.
+
+### Point fibre
+
+Où on en est, qu'est ce qui reste à faire ?
+
+La visite a été faite avec Adriatel le sous-traitant de Zayo : la
+galerie/couloir TGBT derrière le B et aller jusqu'au H ne pose aucun problème,
+mais il n'est pas évident de comment rejoindre la rue.
+Ils vont repasser avec une aiguille pour tester.
+
+Ils ont jusqu'a fin février pour faire leur magie.
+
+### Évolution de l'infra
+
+Moult tâches phabricator ont été créées, il s'agit alors de détailler un peu le
+plan de bataille.
+
+Tout le monde peut s'attaquer au wiki : https://phabricator.crans.org/T234
+On a mis une petite sémantique de où va quoi.
+
+On s'interroge sur une génération automatique de doc à partir de docstring pour
+le code.
+
+Les points priotaires :
+
+* Avoir un wiki à jour et documenté
+* Élimination de autostatus (celà requiert une page publique icinga)
+* Brûler ldap_crans
+* Gros remplacements de vieux switchs pendant les vacances qui viennent (Chirac
+ crée une tâche phabricator)
+* Revoir et compléter l'environnement de test (magnifiquement commencé par
+ tudor)
+
+### Bornes
+
+#### Firmware
+
+Des bornes sous openwrt ont de nombreux bug, le firmware propriétaire semble
+régler le problème. Il faut prendre une décision sur notre course d'action.
+
+Les bornes en question sont au M et G. Il y a des nanostations, des AP lite ont
+été posées (ENS, quelques CROUS), il y a eu ensuite un gros achat de UAP AC
+Pro. Ça a marché pendant 6 mois, puis ça a commencé à tomber. Les UAP AC Pro et
+UAP Ac light posent problème : openWRT crash souvent, LEDE un peu moins mais
+toujours, et unifi semble tenir la charge. Il nous faut faire attentioin car
+sur les AP tout court, on peut les briquer en passant à unifi.
+
+Nous devons choisir de déployer le firmware proprio avec ou sans le controleur
+unifi, uniquement sur les uap ac pro, light ou sur toutes celles compatibles.
+
+#> On passe les UAP AC Pro et UAP AC light sur le firmware proprio et le
+controlleur.
+
+#> On laisse les AP et les nanostations sous openwrt, mais on peut tenter de
+les mettre sur le controlleur si c'est pas trop galère, pour pouvoir voir
+l'état de toutes les bornes au meme endroit et reboot.
+
+#### Nouvelle convention de nommage des bornes
+
+#> On adopte les nouveaux noms : etageBatiment-numero, exemple 5a-01
+
+Nous sommes pour changer petit à petit les noms des anciennes vers la nouvelle
+convention, tout en gardant les anciens noms comme alias.
+
+#### Objectifs en terme de couverture
+
+#> Les résidences sont notre priorité : on veut remplir les trous actuelles,
+donc G au bout et M au milieu. Un premier objectif est 2 bornes par étage.
+
+Ce serait bien de savoir si elles sont directionnelles ou pas, pour optimiser
+la pose.
+
+Une fois les nouveaux switchs posés, on commandera plus de UAP AC pro, et c'est
+parti mon kiki.
+
+Il faudra peut-être refaire le trou du M (pour passer les câbles dans le local).
+
+### Divers
+
+* The lounge, un interface web irc ?
+ * Point positif : peut faire venir des gens sur IRC. Le Webirc actuel
+ n'attire personne.
+ * Point négatif: service en plus, est-ce stable ? Il faut que les gens
+ testent : Guinness aurait eu des soucis avec, et en plus c'est du react js
+ * The lounge semble ne pas relancer les connexions au serveur quand il est
+ reboot. Et il semble planter de temps en temps à Prologin
+
+. => Ok pour lancer the lounge, on nuke webirc, et on croise les doigts
+.Il faudra attendre que le patch ldap soit dans la version stable
+
+* Les news
+
+.Fardale bloque sur du design pour les nouvelles webnews et les webnews php
+risque de casser avec le passage à stretch. Qu'est-ce qu'on fait ? nuke it ?
+.Il tournait en dev sur vo, il faut l'y remettre.
+.=> ASAP, on sort le django webnews et on nuke le webnews php.
+
+* Recovery de mdp avec soit code de confirmation par SMS, déclenchable par
+ l'user ou un MA (proposition CA)
+
+.Pour les SMS, soit on utilise un dongle qui marche pas, soit une API en ligne.
+.L'API en ligne a l'air une bonne idée.
+.On va créer une tâche phabricator (ça fait comme si on était en train de
+résoudre le truc !), avec si possible apprentis, et sinon nounous, mais y a pas
+d'urgence.
diff --git a/compte_rendus/2018_02_22.md b/compte_rendus/2018_02_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..162a9fcaa04777294f12fb97d1999b016a01a8d2
--- /dev/null
+++ b/compte_rendus/2018_02_22.md
@@ -0,0 +1,175 @@
+# Réunion du Collège Technique
+
+* Date : 22/02/18
+* Lieu : Pavillon des Jardins
+* Début : 19h00
+* Fin :
+* <<Pad>>
+
+## Présents
+
+* Charlie Jacomme
+* Gabriel Detraz
+* Arthur Grisel Davy
+* Gabriel Le Bouder
+* Benjamin Graillot
+* Nicolas Gasnier
+* Martin Bauw
+
+## Ordre du jour
+
+### Renouvellement Garanties
+
+Deux garanties à renouveller, Nols et ft.
+
+On renouvelle Nols, mais la question devra se poser avant l'an prochain de son
+remplacement.
+
+On renouvelle ft.
+
+### Tortilla au gwacamole
+
+Charlie en veut une
+
+### Module Backone
+
+Le switch Zayo est branché sur le backbone en 1G pour le moment. On a une
+prise 10G, dont on voudrait pouvoir profiter, mais sans urgence.
+
+Options : changer le bckbone, acheter un switch, acheter un module pour le
+backbone actuel.
+
+ -> Le backbone est toujours en garantie, Ã vie. Il nous suffit amplement pour
+ les années à venir, on ne le changera pas.
+ -> Le switch rajoute un point de failure, qui n'apparait pas nécéssaire, car
+ il jouerait le meme role que le module, environ au meme prix.
+ -> on demande un module backbone, avec ou sans urgence, selon si le
+ branchement 1G fonctionne.
+
+### Nouvelle fibre
+
+C'est posé !!! Elle a été tirée, et arrive jusqu'au 0B, où un routeur de
+Zayo ( un ciena 3930 ) la récupère et nous la redonne.
+
+On a demandé un numéro d'AS, pour que Zayo l'annonce.
+
+On passe tout l'ipv6 et le wifi dessus ?
+
+On peux passer assez facilement l'ipv6, car c'est routé de manière
+indépendante. Il faut mettre à jour la conf de la VM ipv6, changer le prefix de
+toutes les machines crans, et s'occuper de l'ipv6 côté DNS.
+
+On pourrait à terme passer le wifi aussi dessus, sachant que a priori les gens
+en wifi n'ont pas besoin d'ipv4 public. Les machines wifi auraient donc des
+adresses ipv4 privées sur le réseau, NATées statiquement sur des ports de
+nos 1024 adresses publiques.
+
+On propose de n'utiliser que le premier /24 de notre /22 pour le wifi, on
+pourra potentiellement y passer le filaire plus tard.
+
+#> on lance les opérations pour l'ipv6, federez et vlan appart
+
+##> on réfléchi pour le wifi, si le nat statique nous va, et on validera ça la
+prochaine fois.
+
+### Renouvellement des switchs du G
+
+Ils ne gèrent pas l'ipv6, c'est leur problème. Ils sont au nombre de 4.
+
+Par ailleurs, le spare qui était prévu a été posé au PdJ, donc on a plus de
+spare.
+
+On propose l'achat de 5 switchs Gigabit, les 2530 48G de la dernière fois
+
+#> devis chez senetic, budget de 4/5k €
+
+### New ssid wifi
+
+Des appareils ne supportent pas WPA2-entreprise, une idée à base d'un nouvel
+ssid va être proposé.
+
+Fardale: J'ai l'impression que ça complexifie de manière non négligeable
+l'infra actuel. Je pense que c'est une idée intéressante mais vu la complexité
+que ça apporte par rapport au gain
+(on vend des routeurs pour les gens qui en ont besoin) je pense que pour
+l'instant ça n'est pas intéressant et qu'il y a d'autre truc Ã
+régler/voir/revoir avant.
+
+Mikachu: est également contre pour le niveau de complexité ajouté.
+
+RQ post réu de la part de Tudor : par le passé, les gens qui avaient ce genre
+de soucis partageaient leur connexion filaire via WiFi avec un ordinateur (la
+plupart des OS savent le faire nativement, ou avec des softs gratuits
+type "connectify" ®© sur Windows).
+
+Les choses à faire sont :
+
+* créer un ssid WPA caché sur le controlleur
+* hacker les scripts radius pour qu'ils répondent ce qu'il faut.
+* Faire de la pub, sinon beaucoup de gens ne sauront pas que c'est possible.
+ -> cf la confition section sur wifi.crans.org
+
+Mais les gens déjà adhérent ne vont pas sur wifi.crans.org.
+
+ -> je suis pas sur que ça mérite un mail_all
+
+Non mais un message sur twitter, un message dans la sauce, une footnote de la
+ml événement par exemple
+
+Conditions pour la mise en place :
+
+* une section sur wifi.crans.org qui explique comment faire
+* que la modification radius ne prennent pas plus de 3 lignes
+* que la modification soit documentée
+
+#> Bon, ça nous coûte rien (ou pas grand chose), et ça pourra servir à des
+adhérents. Feu.
+
+### Chiffrement des backups
+
+Il faut que quelqu'un s'en charge. Pour les homes il reste à tester ce qui se
+passe avec backuppc si la partition n'est pas monté au reboot et faire que ça
+marche proprement puis basculer sur la partition chiffrée.
+
+Pour les VM il faut faire comme pour les homes.
+
+#> Oui, il faut que quelqu'un s'en charge si quelqu'un est motivé
+
+Stocker la clé dans cpasswords, et demander à backuppc de chiffrer ?
+
+### Pose des bornes WiFi
+
+Belle perf ce week-end, 7 bornes de posées en 3 heures !
+
+Il faut plus de bornes aux H, I et J
+
+#> On demande 4 packs de 5, et une bobine en plus.
+
+### The lounge
+
+C'est en prod avec 2 instances, une publique sur irc.crans.org/web/ et une
+privée sur webirc.crans.org.
+Des remarques ?
+
+It works, its great. Et en plus c'est joli.
+
+#> Everything is awesome, et y a déjà des gens qui l'utilisent :D
+
+### Wiki2.0
+
+Benjamin se propose de passer le wiki du crans sous moin 2.0, il est
+actuellement sous moin 1.9.
+Moinmoin 2.0 n'est pas dans les dépots debian
+https://tracker.debian.org/pkg/moin
+
+C'est précoce. La première priorité est déjà de passer sous
+stretch => attnetion, y a des plugins crans qui décèdent, notamment la partie
+sur l'auth. -> on peut faire des tests sur soyouz et wiki2.
+
+### Questions diverses
+
+* Le webnews django est de nouveau en beta sur vo webnews-dev.crans.org. \o/
+
+Faites des retours.
+
+ -> Visuellement c'est cool.
diff --git a/compte_rendus/2018_03_15.md b/compte_rendus/2018_03_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..ac5c8b8c7fbc734a664d1aa83504f49a1c1fb3e2
--- /dev/null
+++ b/compte_rendus/2018_03_15.md
@@ -0,0 +1,248 @@
+# Réunion du Collège Technique
+
+* Date : 15/03/18
+* Lieu : Condorcet
+* Début : 19h48
+* Fin : 21h45
+* <<Pad>>
+
+## Présents
+
+* Charlie Jacomme
+* Gabriel Le Bouder
+* Nicolas Gasnier
+* Martin Bauw
+* Maxime Bombar
+* Benjamin Graillot
+* Lev-Arcady Sellem
+* Antoine Bernard
+* Arthur Grisel-Davy
+* Michael Paulon
+* Gabriel Detraz
+
+## Ordre du jour
+
+### Divers
+
+* Du gateau ! Pour fêter les 20 ans ?
+ Le Crans a 20 ans, Charlie en a 24, du gateau !!!
+* J'ai validé prog1 \o/
+ Encore plus de gateau !!!
+
+J'ai menti, y a pas de gateau. Par contre, on accueil [[Grizzly]] et ArCas dans
+le cercle des nounous.
+
+### Point sur la fibre
+
+Plan de déploiement.
+
+La fibre est en place, des essais sont en cours mais on n'a pas encore la
+satisfaction totale quant à son utilisation. Potentiellement des erreurs de
+routage. Une présentation plus approfondie sera faite.
+
+Benjamin propose un plan d'adressage IP : https://pad.crans.org/p/PlanIP
+
+##> On rediscute de cette partie à une futur IN, on veut se concentrer sur le
+wifi aujourd´hui
+
+Module 10Gb backbone reçu, installé avec également la carte rézo sur odlyd, on
+fait du gros speed test. Ça fonctionne, mais pour le moment on a un peu trop de
+route, car on recoit tout, et avec un seul transitaire c'est un peu inutile. Il
+faudrait passer à une default route chez zayo pour simplifier, et calmer le
+daemon bgp.
+
+#> Y nous faudrait un calendrier de déploiement
+ASAP, dès qu'on aura un peu mieux vu pourquoi des routes disparaissent.
+
+#> Est-ce qu'il faut prévenir les gens qu'on les change ?
+Il faut prévenir les gens qui ont un port ouvert sur leur machine wifi. Le
+reste, on balance.
+
+Par ailleurs, les applis ens ne sont plus dispo avec le réseau du Crans.
+
+On propose de mettre en place, si la conf est pas trop dégueu, un double NAT,
+un pour contacter l'ENS et un pour le reste du monde, avec les defaults route
+qui vont bien.
+Mikachu est plutot contre à cause de la complexité de conf, la moitié des gens
+ont pas d'avis, et le reste est plutot pour. On tente ça.
+
+On rappel que les gens vont garder des addresses ipv6 publiques.
+
+### WPA2
+
+tudor souligne qu'avoir un mot de passe identique pour tout le monde pose des
+soucis et que la solution acceptée devait utiliser le radius.
+Il faudrait changer ça sinon il faut nuker le SSID.
+
+Tudor: De manière surprenante, je ne trouve pas de doc claire à ce sujet pour
+unifi-controller, mais des gens en parlent ici:
+https://community.ubnt.com/t5/UniFi-Wireless/Unifi-AP-support-mac-based-authentication/td-p/2232766
+ou
+là : https://community.ubnt.com/t5/UniFi-Wireless/What-does-Radius-MAC-authentication-do/td-p/2126890
+l'option semble présente dans l'unifi controller en prod au crans.
+Ok, my bad, ça authentifie tout le monde avec le même mot de passe. La feature
+recherchée s'appelle parfois PPSK (*private* pre-shared key), et pas mal de
+gens se plaignent qu'elle n'existe pas (cf
+https://www.reddit.com/r/Ubiquiti/comments/79yhhd/does_ubiquiti_have_any_plan_to_implement_wpa2ppsk/ par exemple).
+Feature request
+officielle: https://community.ubnt.com/t5/UniFi-Feature-Requests/Private-WPA-keys/idi-p/626751
+côté hostapd (utilisé en interne par openwrt et unifi-os), la feature existe
+bel et bien:
+"wpa_psk_radius" dans https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf
+Il faut juste modifier le serveur radius pour qu'il renvoie le mdp en clair
+vers la borne (chose qu'il ne fait pas habituellement).
+
+#> Une majorité de nounous pensent que c'est un problème de sécurité.
+
+#> 2 nounous tiennent à ce réseau
+
+ -> elles trouvent une solution plus sécurisé, ou alors dans un mois on le nuke.
+
+### bcfg2
+
+Actuellement, au Cr@ns est utilisé le paquet bcfg2 (un peu customisé pour nos
+usages persos) pour gérer les config des serveurs. Cependant, le paquet se fait
+vieux. Il faudrait peut-être envisager de trouver un autre gestionnaire.
+Une alternative pas mal peut etre ansible qui est aussi en python et il me
+semble est uttilisé dans d'autres assos de Federez.
+
+Question aux vieux: pourquoi bcfg2 ?
+
+ -> parce que ça marchait, et que c'était en python.
+
+Des options : ansible, salt, autres ?
+
+Mikachu et Pollion regardent un peu en détails comment ils fonctionnent, pour
+voir quelle option est la plus crédible, et la plus facilement portable pour
+nous.
+
+### Autostatus
+
+On se propose de se débarasser entièrement d'autostatus pour le remplacer par
+icinga.
+
+Il y a status.crans.org, icinga2-guest.crans, et icinga2.crans.org, on peut
+nuker autostatus
+
+C'est validé au vote.
+
+### Augmentation du nombre de MACs par prise
+
+Actuellement la limite est de 2 pour les prises des chambres et de 5 pour les
+clubs, cette limite est parfois atteinte au Club Jeux Vidéo et au club Serv[ENS]
+
+#> on passe la limite club à 30
+
+### MÃ J du wiki
+
+Benjamin propose de créer une vm pour mettre à jour le wiki vers stretch
+
+ -> oui, c'est cool
+
+### Conditions de mise en prod du webnews
+
+Le webnews "marche" mais n'est pas équivalent en feature par rapport à l'ancien
+et il n'a pas été testé sauf que vu l'activité des news il ne sera clairement
+jamais beaucoup testé. Du coup Fardale souhaiterait un cahier des charges Ã
+remplir pour le mettre en prod.
+
+* Pouvoir lire des news
+* Pouvoir écrire des nouveaux postes
+* Pouvoir répondre
+
+C'est tout have fun.
+
+* Je trouve ça un peu léger pour une mise en prod, je rajoute
+ ma !WishList :-) -- 20-100
+ * Affichage par thread
+ * Possibilité de marquer volontairement un message comme non lu(/lu)
+ * Cross-post (possibiité d'envoyer le même post sur plusieurs groupes)
+ * FU2 (lors d'un cross-post, on précise dans le champ Followup-To sur quel
+ groupe (unique) les réponses sont attendues; cela signifie qu'on attend du
+ client qu'il honore lesdit FU2)
+ * [Facultatif] On peut penser à une feature qui suggère automatiquement
+ en signature "FU2 <groupe>", modifiable pas l'utilisateur. Mais c'est
+ du bonus.
+ * *PAS* de possibilité de supprimer les messages non envoyés avec le
+ webnews
+ * [Facultatif] Possibilité de supprimer ses propres messages envoyés avec le
+ webnews
+ * [Facultatif] …et ceux envoyés avec l'ancien webnews
+ * [Facultatif] Permettre à une liste de modérateurs de supprimer d'autres
+ messages que les leurs. Éventuellement distinguer la liste des modérateurs
+ pour chaque groupe.
+ * [Facultatif] Gestion des abonnements : pouvoir ne suivre que certains
+ groupes
+ * [Très Facultatif] Gestion de headers custom. Indispensable pour poster sur
+ crans.crans.annonces. Mais on peut tout à fait décider de limiter ces
+ posts à un client Thunderbird/Emacs/slrn…
+
+### Pérennité des services du Crans
+
+Pensons-nous pouvoir garantir le maintien d'un certain nombre de service pour x
+années ?
+
+ -> mail Crans, ce serait bien de pouvoir dire, on les préserve pour au
+ moins 10 ans.
+ Le CT demande au CA de mettre de coté de l'argent, 10K dédiés à maintenir les
+ mails le plus longtemps possible.
+ Cet argent nous permettrait notamment de garantir de pouvoir prévenir au
+ moins deux ans à l'avance de la coupure des mails.
+ -> On envisage à nouveau la migration vers re2o. pros & cons ?
+
+Le constat est que depuis la décision d'abandonner la période d'essai re2o il y
+a 4 mois, rien n'a bougé. La solution re2o semble plus tenter et motiver la
+plupart des nounous présentes.
+
+On tente l'aventure re2o :
+on fait un fork, on essaie de programmer de manière vraiment modulaire, on
+documente, on test.
+
+Deadline d'ici 1 mois : avoir déployé un joli vlan avec une simu de re2o, dhcp,
+dns, radius
+Deadline d'ici 3 mois : avoir rajouté tout ce qu'il fallait pour pouvoir
+déployer
+Deadline d'ici 4 mois : avoir fait des tests de manière extensive, et prendre
+une semaine pour faire le déploiement final.
+
+#> Attention, pas de déploiement si ce n'est pas au niveau, et strictement
+beaucoup mieux que ce qu'on a aujourd'hui.
+
+Si on arrive à faire tout ça, on pourra se poser la question de refusionner
+avec la branche master federez.
+
+On valide le plan, à l'unanimité moins une voix, qui s'en fouiche.
+
+https://gitlab.federez.net/federez/re2o.git
+
+### Renews les clef gpg pour le dépôt custom
+
+Et faire une page wiki sur comment faire
+un
+tuto : https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/
+
+Pollion jete un coup d'oeil.
+
+### MÃ J des Serveurs
+
+En parlant de pérénité des services, il faut parler mails. En parlant de mails,
+il serait intéressant de planifier une interruption de services pour mettre Ã
+jour redisdead et owl. btw il semble y avoir une faille de sécurité dans
+dovecot jusqu'Ã la version de
+stretch-backports : https://www.cvedetails.com/cve/CVE-2017-15132/
+https://tracker.debian.org/pkg/dovecot
+
+On va faire un petit sondage, pour voir des gens dispos dans deux semaines,
+pour pouvoir annoncer la date une semaine avant.
+Si possible entre 23h et 7h00
+On fait une liste de MaJ à faire, avec un ordre de priorité. On en fait pas
+plus de deux en parallèles, et on passe à la suivante que quand les précédentes
+ont étaient vraiment finalisé.
+
+* Faites gaffe, mettre à jour redisdead, ça signifie mettre à jour mailman. Ça
+ se fait, hein, mais tête froide et sans précipitation. (Vérifiez bien que les
+ MLs marchent après coup, pas juste que les mails (non-ML) passent.) -- 20-100
+
+Bisous, c'est fini <3
+
+Du coup, on fait une mini GPG signing party avec les nouveaux !
diff --git a/compte_rendus/2018_04_06.md b/compte_rendus/2018_04_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..c529599782dcff0edd8c33e754f75461d534bdf8
--- /dev/null
+++ b/compte_rendus/2018_04_06.md
@@ -0,0 +1,91 @@
+# Réunion développement re2o
+
+Présents :
+
+* Chirac
+* Charlie
+* Grizzly
+* Esum
+
+A noter que la réunion n’a pas durée très longtemps à cause du départ de
+Charlie :
+
+### Point sur ce qui a été fait niveau infra
+
+* mise en place de re2o-server, vm avec un serveur web apache de dev et bdd sur
+ thot (postgresl)
+* mise en place de re2o-ldap, contenant le ldap de re2o
+* mise en place de re2o-services, contenant les services dhcp, dns notamment.
+* import de la bdd actuel avec un script d’import bien avancé, permettant de
+ faire des tests ( presque tout passe, sauf les serveurs disposant de la même
+ mac sur plusieurs
+ VLAN : https://gitlab.crans.org/nounous/scripts/blob/master/re2o/import_crans.py )
+
+Ces vm sont sur adh/adm.
+
+Charlie suggère de rajouter l’embryon de parefeu sur services, de créer des
+vlans dédiés en dehors de adm avec des id élevés ( > 30 ? ); enfin de tester
+sur ces vlan un mini réseau, avec également la vm re2o-services qui servirait
+de routeur. Tout le monde semble d’accord là dessus.
+
+### Ce qui a été fait niveau dev
+
+* factorisation du système de gestion des acl
+* portages de scripts divers mais essentiels ( chsh, chgpass, unifi-ap-sync,
+ dernière connexion) via des commandes django et des appels aux forms et aux
+ validations des models
+* enregistrement de l’emplacement des switchs et génération de la map de la
+ topologie du réseau
+* affichage pretty des switchs (equivalent de swicths2 pretty)
+* fonction de ménage cableur
+* possibilité d’éditer la liste des shells sans passer par le /admin
+* model borne wifi spécifique
+
+Ces taches ont une criticité diverse. Sur le reste, il faut avancer dans le
+code, on fait grosso modo la liste des chantiers. En critique/prioritaire, il y
+a :
+
+* firewall, à partir de l’embyron présent dans re2o (nftable ? )
+* generation de la conf des switchs, code modulaire permettant de générer de la
+ conf pour d’autre modèles que des hp. Voir une solution existante ?
+* adherent : gestion de la creation des homes, Ã inclure dans re2o-tools
+
+Enfin, on a débattu un peu sur la sécurité. Dans re2o, il n’y a qu’un seul
+login/mdp pour tout.
+Avantages :
+
+* plus simple pour les users à comprendre et à retenir comme système
+* permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de
+ son compte crans en entier à un « ami »
+
+Inconvénient :
+
+* le mdp est le même partout, cela peut poser un problème de sécu en
+ particulier pour les admin.
+
+On identifie les fonctions sensibles : il s’agit de l’accès web re2o, et des
+accès serveurs (sudo en particulier).
+L’autre problème concerne la phase transitoire, il va falloir gérer les mdp
+legacy des machines, mais il « suffira » de tweaker un peu auth.py au moins
+temporairement pour ça.
+
+Plusieurs solutions possibles :
+
+Avoir un second compte; on est tous d’accord pour dire que les gens ne s’y
+tiendront pas, cette solution semble trop pénible.
+
+Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en place
+un second mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas
+satisfaisant d’après Charlie, cela n’augmente pas la sécurité, en effet c’est
+toujours le même mot de passe entre l’accès serveur, l’accès gitlab ou l’accès
+mail, mais surtout les accès serveurs sudo qui sont la pièce critique, comme
+actuellement au CRANS.
+
+On peut forcer l’authentification par clef ssh pour les admin, comme ça si un
+mot de passe est compromis, les accès serveurs ne le sont pas. Problème : cela
+ne résout pas le problème de l’accès re2o-web qui serait toujours le même mot
+de passe.
+
+On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe
+pour les admin permettant de récupérer leurs droits sur re2o-web, ce qui permet
+de couvrir à peu près tout. Le débat reste ouvert.
diff --git a/compte_rendus/2018_05_16.md b/compte_rendus/2018_05_16.md
new file mode 100644
index 0000000000000000000000000000000000000000..7ae91beb68b8b44779f378387b0ff02af071cc81
--- /dev/null
+++ b/compte_rendus/2018_05_16.md
@@ -0,0 +1,152 @@
+# Réunion du Collège Technique
+
+* Date : Mercredi 16 mai 2018
+* Lieu : Kfet
+* Début : 19h00
+* Fin : 20h40
+* <<Pad>>
+
+## Présents
+
+* Grizzly
+* Chirac
+* Charlie
+* Boudy
+* Blupon
+* Mikachu
+* Esum
+* Poult
+* 20-100
+* Pollion
+* Fardale
+* Gasnier (19h21)
+
+## Ordre du jour
+
+### Devis
+
+On a un devis pour le nouveau serveur, la ram pour ft et les disques de la
+baie, Ã valider.
+
+On valide le devis pour le nouveau serveur 4900€ TTC, 600€ TTC de RAM pour ft.
+
+Pour les disques, il faut du SAS v2 2To, Anne peut pas les prendre, on les
+prends sur ldlc. On commence par en prendre un.
+
+### Multicast wifi
+
+Le Multicast wifi pose des problèmes de perf, il faut envisager de bloquer le
+multicast entre WLAN/LAN.
+[[https://help.ubnt.com/hc/en-us/articles/115001529267-UniFi-Managing-Broadcast-Traffic]]
+[[https://sysctl-explorer.net/net/ipv4/proxy_arp_pvlan/]]
+
+On commence par le mettre à la Kfet pour tester, et on passe à l'échelle si ça
+marche.
+
+### Parefeu
+
+Présentation et plan d'attaques.
+
+* Le pare feu génère un set de règle indifférement v4/v6, puis traite ce qui
+ doit être particulier.
+* Le parefeu de Nit devait rattraper plein d'erreur, par construction et Ã
+ cause d'ipset, qui était notamment nécéssaire pour le filtrage mac/ip.
+ Aujourd'hui, on a le dhcp snooping et le radius qui check le mac/ip, on est
+ plus sur que ça vaille le coup de le faire dans le parefeu.
+* Il y a des vieilles blackliste paiement qui traine, c'est par très pertinent.
+ Le pb est qu'il y a la période de blacklist paiement
+* Sur zamok, les blacklist hard sont bloqué en input, on peut le retirer.
+
+Vu qu'il n'y as plus de filtrage mac/ip, on peut juste régénerer quand on ouvre
+des ports. Il y a un fonction delinblacklisthard dans le parefeu, qu'il
+faudrait appeller quand on retire une bl. On peut aussi regen le parefeu plus
+régulièrement.
+
+Attention, le pare feu a laissé "parfois" passer la note de test. C'est chelou,
+et on sait pas d'où ça vient...
+
+Deux grosse étapes:
+
+* Il faut faire un cahier des charges sur le wiki. Chirac propose un premier
+ cahier des charges.
+* Debuguer la partie v4 du nouveau pare feu, et unifier. Ça peut-être pertinent
+ de faire des tests sur sable avec le nouveau pare feu.
+
+### Fin de la migration des ipv4 ?
+
+Il y a encore 27 machines fixes avec des ip Crans-ENS.
+
+* Il faut poker OSM (esum), federez (?) et respo-info (Grizzly) pour finir.
+
+### Problèmes de VLAN
+
+Actuellement les switches ne peuvent détaguer qu'un seul vlan sur leurs prises,
+ce qui posent des problèmes lorsqu'un adhérent ou un club branche à la fois des
+machines à ip publique et des machines à ip privée dans sa chambre/local.
+
+Chirac propose d'utiliser une fonctionnalité des switches pour détager
+plusieurs
+vlan ([[http://h22208.www2.hpe.com/eginfolib/networking/docs/switches/RA/15-18/5998-8151_ra_2620_asg/content/ch06s13.html]]) mais cela casse plus ou moins le broadcast (qui pose problème pour les ip v6), mais cela n'a pas fonctionné lors de la mise en prod (ou bien ça n'était pas activé ?).
+
+* une possibilité serait de mettre les ip privées et publiques sur le même vlan.
+* une autre de mettre des switchs manageables à servens, etc (mais là on doit
+ le faire pour toutes les chambres)
+
+Options :
+1. fusion des vlans
+1. switchs manageable à la Kfet et a servens, et par défault un personne qui a
+une machine publique a toutes ses machines publiques
+1. dhcpv6
+1. vlan tagged sur les prises
+
+On envoie le vlan ip publique en tagged
+
+### Certificat wildcard
+
+Benjamin propose d'utiliser un certificat wildcard pour les services webs,
+c'est possible d'utiliser un challenge
+DNS (voir [[https://certbot.eff.org/docs/using.html#manual]]) en tirant le
+paquet ([[https://packages.debian.org/stretch-backports/certbot]]) depuis
+stretch-backports et d'écrire un script pour l'automatiser.
+
+On le garde en tête, re2o ?
+
+### Mise à jour des serveurs
+
+#### Mise en prod de kiwi ?
+
+On met kiwi en prod, (il faut vérifier que la création de compte wiki
+fonctionne en ip pub et privé), on migre juste le wiki en laissant tourner
+niomniom. On annonce un downtime une semaine à l'avance avec un bandeau sur le
+wiki. Il faudra aussi remettre en place le rsync vers soyouz pour wiki2.
+
+#### Mise à jour de redisdead
+
+Maintenant que le feu de la migration est passée, on aura peut-être du temps
+pour terminer les upgrade. Faut-il prévoir une interruption de service ?
+
+Il faut le faire, et prévenir les gens. On est pas particulièrement pressé, on
+essayera de prévoir une maintenance, ptet faire en même temps que odlyd2 et
+owl, omnomnom, zephir.
+
+### Problèmes de connexion
+
+Des gens ont fait remonter des pb de connexions. On ne sait pas pourquoi, il
+faut trouver des moyens de diagnosatiquer. On parle de pb de pings, de pb de
+paquets perdus.
+On a déjà augmenté les coeurs de ipv6-zayo, ça a amélioré un peu le ping en v6.
+
+La limite de débit retiré pourrait être une piste, mais l'uplink serait saturé
+en GB, ce qui n'est pas le cas.
+
+Des questions de QOS, etc.
+
+Bref, on sait pas ce qu'il se passe, il faut trouver des moyens d'investiguer.
+
+### Questions re2o
+
+* Mot de passe unique (cf mails @nounous)
+* problème du .forward
+* créer compte wiki
+
+Repoussé à la prochaine fois.
diff --git a/compte_rendus/2018_06_19.md b/compte_rendus/2018_06_19.md
new file mode 100644
index 0000000000000000000000000000000000000000..199d32330270bd84e5b9c90f8a361d5f3a1860fb
--- /dev/null
+++ b/compte_rendus/2018_06_19.md
@@ -0,0 +1,118 @@
+# Réunion du Collège Technique
+
+* Date : Mardi 19 juin 2018
+* Lieu : 2B
+* Début : 19h22
+* Fin : 20h10
+* <<Pad>>
+
+## Présents
+
+* Blupon
+* Boudy (va bosser)
+* Charlie
+* Chibrac
+* Esum
+* Gasnier
+
+## Ordre du jour
+
+* Création de comptes wiki
+* .forward
+* Le CAS
+* Mot de passe unique
+* ARPEJ
+
+## Créer compte wiki
+
+Quelle est la bonne manière d'interfacer le compte re2o avec le compte wiki ?
+
+https://phabricator.crans.org/T293
+
+On remarque que c'est ptet pas release critical, mais pouvoir se logguer sur le
+wiki via le cas semble tout de meme pratique.
+
+## Problème du .forward
+
+Ce serait bien de ne plus avoir à écrire dans les homes des gens pour le
+.forward. Le mail de redirection serait idéalement stocké dans la BDD, et
+postfix pourrait taper directement dedans. Il y a le problème des gens qui
+veulent conserver un .forward custom (procmail)
+
+https://phabricator.crans.org/T295
+
+## Le CAS
+
+Que va devenir le CAS avec re2o ?
+
+Est-ce qu'on prévoit de le faire fonctionner avec re2o ?
+
+Est-ce qu'on le garde uniquement pour quelques services ou pas ?
+
+re2o ne change rien pour le CAS, on exporte toujours la base ldap. On peut, si
+on veut, permettre le login re2o via le cas, mais c'est le seul point.
+
+## Mot de passe unique
+
+Dans re2o, il n’y a qu’un seul login/mdp pour tout, et donc les machines wifi.
+
+Avantages :
+
+* plus simple pour les users à comprendre et à retenir comme système
+* permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de
+ son compte crans en entier à un « ami ».
+
+Inconvénients :
+
+* le mdp est le même partout, cela peut poser un problème de sécu en
+ particulier pour les admin, qui ont accès aux serveurs + serveur web
+* la phase transitoire, il va falloir gérer les mdp legacy des machines, mais
+ il « suffira » de tweaker un peu auth.py au moins temporairement pour ça.
+
+La grande question est : est-ce que cela pose un véritable problème de
+sécurité, ou est-ce que je fais parler ma paranoïa actuellement ?
+
+Si oui, il faut trouver une solution :
+
+* Avoir un second compte; mais ça semble pénible, est-ce que les gens le
+ feront ? Cela dit, pour les nounous, si on a un compte avec que sudo, pas de
+ mails, etc, et un autre pour tout le reste, on a pas vraiment le choix…
+* Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en
+ place un second mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas
+ satisfaisant d’après Charlie, cela n’augmente pas la sécurité, en effet c’est
+ toujours le même mot de passe entre l’accès serveur, l’accès gitlab ou
+ l’accès mail, mais surtout les accès serveurs sudo qui sont la pièce
+ critique, comme actuellement au CRANS.
+* Forcer l’authentification par clef ssh pour les admin, comme ça si un mot de
+ passe est compromis, les accès serveurs ne le sont pas. Problème : cela ne
+ résout pas le problème de l’accès re2o-web qui serait toujours le même mot de
+ passe. Par aileurs, en cas d'urgence, c'est balot de ne pas pouvoir réparer
+ le crans juste parce qu'on a pas son propre pc sous la main.
+* Faire taper ailleurs que dans la base ldap la commande sudo, pour pouvoir
+ avoir un autre mdp (c'est possible simplement ?), et pareille sur re2o-web.
+
+. --> dans man 5 sudoers il y a le flag `rootpw' qui permet de prompter le mot
+de passe de root plutôt que celui de l'utilisateur.
+. (il y a aussi `runaspw` et `targetpw` qui ont des comportements du même type)
+. Sinon ça peut se faire avec un module PAM, c'est un peu chiant mais ça peut
+s'écrire en python.
+
+On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe
+pour les admin permettant de récupérer leurs droits sur re2o-web, ce qui permet
+de couvrir à peu près tout.
+
+Il y aura un problème à la transition, car les machines enregistré ne seront
+pas sur le système du single password. On pense mettre côté auth.py une table
+had oc contenant toutes les exceptions, que l'on fera disparaitre à terme, mais
+pas en même temps que la rentrée. On peut envisager de faire disparatitres les
+exceptions au fur et à mesure, genre tiers par tiers, pour ne pas avoir trop de
+monde en même temps dont les machines wifi ne marchent plus.
+
+On propose de mettre en place un système à deux mot de passes. Le premier est
+pour le compte classique, le second permet d'accéder à tous ce qui demande des
+droits (ssh, re2o).
+
+## Arpej
+
+Il n'y aura pas d'ARPEJ d'ici le 2 juillet, et entre le 3 et 11 aout. À part
+ça, feu.
diff --git a/compte_rendus/2018_09_11.md b/compte_rendus/2018_09_11.md
new file mode 100644
index 0000000000000000000000000000000000000000..74ebc5bc1771b641a2435fe7a9bac75d9c7f3b53
--- /dev/null
+++ b/compte_rendus/2018_09_11.md
@@ -0,0 +1,223 @@
+# Réunion du Collège Technique
+
+* Date : Mardi 11 septembre 2018
+* Lieu : Condorcet
+* Début : 19h00
+* Fin : 21h15
+* <<Pad>>
+
+## Présents
+
+* Charlie !
+* Chirac
+* Fardale
+* Blupon
+* Bernie', «en chemin» à 19h06 (arrivé à 19h50)
+* Mikachu
+* Benjamin
+* Hamza
+* Grizzly
+* Gauthier
+* Émile
+* Ed Pi
+* Antoine
+* David
+* Erdnaxe
+* Pollion
+* Zéphyr
+* Gasnier
+* Boudy (arrivé à 19h50)
+* Arcas (arrivé à 19h50)
+
+## Ordre du jour
+
+### Points triviaux
+
+* Le dépôt bcfg2 est en public et il y a le mail de JL (entre autres) dessus…
+ * Il est en privé, c'est réglé, LOL
+* La TV ne marche toujours pas…
+ * Il faut faire des tests...
+
+. Pollion, Fardale et Mikachu
+
+* Il faut renouveler(?) la clé GPG du miroir jessie...
+ * Non, on passe à stretch
+
+### Débrief de la migration
+
+Comment ça s'est passé, de quoi on en content, de quoi on est pas content.
+Pendant une semaine, début août, il y a eu la grande migration.<<FootNote(Merci
+Ã Grizzly, Boudy, esum, Chibrac, coeur coeur coeur)>>
+
+Y a eu des problèmes, y a rien eu de dramatique. Y a pas de perte de données,
+internet a pas été coupé trop longtemps. On espère ne pas avoir planté trop de
+mines. Par contre, on a cassé plein de sides trucs (DNSSEC, quota, comptage
+d'upload, wiki page perso, authentification wiki...)
+
+Fardale : le côté dommage de la migration, c'est que des choses ont du être
+finies pendant. Les délais et contraintes sont compris, mais ça a rajouté des
+problèmes.
+
+Il nous a probablement manqué une ou deux semaines. Quoi qu'il arrive, on
+aurait pas été capable d'anticiper tous les problèmes.
+
+Bottom line : maintenant, on a re2o.
+
+#> on dev dans le cadre d'un projet partagé par plusieurs assos
+
+C'est classe, et/mais ça rajoute des contraintes, et des dépendances externes.
+
+A terme, notre instance en prod doit juste suivre la branche master, i.e les
+release.
+
+Reste-t-il d'autres choses à faire ?
+
+* problème de wifi intermittent (est-ce nouveau? )
+ * Oui, c'est nouveau. Ça concerne pas tout le monde...
+ * Il faut faire du debug
+ * il faut quelqu'un sur le campus, pour faire un rapport complet.
+ * quelles bornes, tcpdump, que dit la borne quand ça arrive ? etc
+ * c'est en théorie faisable par un apprenti, ne pas hésiter à harceler
+ une nounoue, ils sont là pour ça
+
+* investiguer les problème de mails qui disparaissent ?
+
+* quota
+ * il faut remettre les quota à jours ?
+ * il faut reboot zamok, semba ?
+ * il faut désarchiver le script alias, et mettre dans le path le logsearch
+* parefeu sur zamok
+ * y a une tache phabricator, le problème concerne l'accès à adm
+
+ * pare-feu partout : arrêtez de DROPer des trucs légitimes
+ légitimes = refused drop au lieu de reject sur certains paquets
+
+ * ssh2 en 443 vers zamok
+
+* refactor formulaire inscription
+ * Grizzly est dessus. On demande pas la gpg fingerprint ou la chambre Ã
+ l'adhésion
+ * Je certifie ne pas avoir de compte crans
+ * Mineur ? Transférez au CA.
+
+* comnpay fait des factures invalides. Le crans ne récupère pas l'info de
+ comnpay. C'est réglé <3
+ * 3dsecure, est activé pour les cartes étrangères. Sad reacts only.
+ * Paypal ? Grosse commission ? Oui.
+
+À partir de maintenant, on ne peut soumettre que des problèmes déjà réglés en
+IN. Voilà . Prout.
+
+* synchro des MLs automatiques
+ * Oh LOL, mailman 3
+
+### Les idées futures ?
+
+* remettre l'ipv6 sur un serveur physique ?
+ * on pourrait tenter de remettre l'ipv6 sur odlyd, puis de le passer en main.
+
+[Nomination de nounou, ça mérite bien un point au CR, nan ?]
+
+* Pour avoir avec succès répondu à une question piège, esum est nommé Nounou.
+ Yeah !!! (bon, c'est aussi parce qu'il a fait plein de trucs. Mais surtout
+ parce qu'il a répondu à la question)
+
+* Créer un certificat racine autosigné et déployer des certificats sur bcfg2 et
+ gitlab.adm…
+ * Deux options, un certifs LE (génération un peu embêtante), ou un autosigné.
+ * celui qui fait fera comme il veut, Mikachu peut donner des conseils
+ utiles
+
+* Générer un certificat wildcard pour les serveurs https
+ * en fait, on fait ça, c'est bien
+
+* crans.ens-cachan.fr a disparu. Do we care ?
+ * Non -> mail d'apf à Sabrina, à suivre...
+ * Ce serait cool qu'on supporte encore ça pour les adresses mails.
+
+### Don de vieux matos ?
+
+cf .
+https://wiki.crans.org/ComptesRendusCrans/Mardi28Aout2018#Don_de_vieux_serveurs
+On a voté en CA pour donner des vieux serveurs avec approbation du CT, est-ce
+qu'on valide ?
+
+* Ok
+* OSM on s'en fouiche.
+* Sable, il faut le wipper de manière propre avant de le donner. Faisons un
+ backup avant
+ * Fardale est cahdu
+
+## Petites idées (d'un câbleur)
+
+* Défaillance du lundi 10 septembre, qu'est-ce qui s'est passé ? Qu'est-ce qui
+ l'a causé ?
+ * bcfg2, thot , pgsql PLS, radius dead, restart, OKLM.
+
+. Chirac : "C'est ma faute"
+
+* Envoie de mail via PHP qui résulte en une erreur MSFRF2612, problème de conf
+ SMTP automatique ?
+ * J'ai aucune idée de ce que ça veut dire.
+* Problème de configuration de Apache qui se croit en HTTP bien qu'il soit en
+ HTTPS...
+ Exemple : https://perso.crans.org/erdnaxe/phpMyAdmin-4.8.3-all-languages/
+ * dans l'idéal, il faudrait ptet passer les pages perso en proxifier. On va
+ invoquer les vieux.
+* Autoriser qqu qui n'a pas un mail @crans.org à accéder à Phabricator
+ * si il a pas un mail @crans.org, on l'aime pas.
+
+* on a pas de reverse DNS en public sur l'ENS, la délégation n'est plus bien
+ définie.
+ * il faut demander à la DSI, vite.
+
+## Bilan RTC
+
+Voici donc que je fusse RTC pendant 3 ans. Je n'ai évidemment pas fait ce qui
+suit seul, bien loin s'en faut, mais au cours de ces 3 ans (ouais, un peu
+moins, c'était depuis le 3 décembre 2015), il y a eu quelques changements, dont
+je suis plutôt content. Merci les copaings !
+
+Il y a maintenant :
+
+* des services redondés sur serveurs virtuels et physiques par paires
+* un Full Master Backup, capable de gérer seul le réseau
+* des certificats let's encrypt, via une centrilisation de l'https, avec des
+ jolies confs https pareilles partout
+* plus de bornes wifi, et branchées sur des switches POE
+* une nouvelle fibre en plus, indépendante de l'ENS
+* un logiciel de gestion en projet commun inter écoles
+* phabricator, un système *utilisé* de gestion des tâches.
+* un backup externe du wiki
+
+Il n'y a plus :
+
+* des scripts essentiels codé par des gens dont plus aucune nounou active ne
+ connait le visage
+* des scripts capitaux montés en NFS
+* une migration partielle, avec un vieux binding encore plus ou moins utilisé Ã
+ des endroits
+* les perms d'inscriptions sous peuplées et pas assez tenues (y a encore des
+ perms, mais bien plus légères)
+* des références complétement outdated sur des pages wiki de serveurs ou
+ services critiques.
+* de système de communication intra campus vraiment utilisé et géré par le crans
+
+Ce qu'il manque pour un monde plein de paillette (aka, ma liste au père noel):
+
+* DNSSEC
+ * Benjamin s'en occupe, on fait ça après octobre.
+* Redondance psql
+* Tout le monde sur des ips et la fibre zayo, avec fallback sur l'ens via bgp
+ multi homing en cas de pépin moi je te soutiens charlie <3
+* une imprimante qui brule
+* une réinscpection à la loupe de re2o pour éviter les mauvaises surprises.
+* porter l'appli wiki (d'une manière cool, genre, y a t'il vraiment besoin de
+ qqch dans re2o ?)
+* porter l'appli page perso
+* toutes les machines sous stretch
+* ansible <3
+
+Pollion est le nouveau RTC <3 <3 <3
+
+Son gateau était bon, et open source
diff --git a/compte_rendus/2018_10_17.md b/compte_rendus/2018_10_17.md
new file mode 100644
index 0000000000000000000000000000000000000000..91925e74129baeb2d3f8b5b623da7ea877e580d3
--- /dev/null
+++ b/compte_rendus/2018_10_17.md
@@ -0,0 +1,244 @@
+# Réunion du Collège Technique
+
+* Date : Mercredi 17 Octobre 2018
+* Lieu : Condorcet
+* Début : 20h00
+* Fin : 22h20
+* <<Pad>>
+
+## Présents
+
+* Pollion
+* Grizzly
+* PAC
+* Gasnier
+* Chirac
+* Mikachu
+* Emile
+* Edpibu
+* Fardale (via jitsi, et il a marché !)
+* Arcas
+* Erdnaxe (arrivée 20h13, départ 21h50)
+* Boudy (arrivée 20h30)
+* Quentin Petitjean (arrivée un peu avant 21h)
+
+## Ordre du jour
+
+### Renouvellement garanties
+
+Stitch et Thot arrivent en fin de garantie
+les 4/11/2018 et 07/12/2018 respectivement.
+Thot date de 2012, on ne renouvelle. On passera temporairement sur vulcain s'il
+nous lâche
+Stitch : On renouvelle !
+
+### Problèmes rencontrés
+
+Ces derniers temps on a rencontré quelques soucis, qui ont pu être réglés,
+d'autres non. Ce n'est pas forcément totalement dû à la migration mais on
+surveille.
+
+#### Routage
+
+On a subit des pertes de routes BGP mais ça semble s'être calmé. On
+sondera [[ CransTechnique/ServicesMineurs/Icinga2 | icinga]].
+
+#### Instabilité Wifi
+
+Gros problème sous MacOS, on a désactivé le fastroaming, ça a réglé beaucoup de
+cas mais certains adhérents ont toujours le problème. Faudrait vraiment
+chercher. Gasnier signale en particulier des broken pipes en ssh, ou lors
+d'envois massifs de mails mais ça ne se voit pas trop dans le reste des
+cas (youtube etc...)
+
+#### Perte de paquets
+
+Avec !FastRoaming au bout de quelques minutes on était connectés mais plus
+rien, ou ping abérant, connexions ssh qui mettent 1000 ans, mais ça a été réglé.
+
+#### Scams mails (rejet redirection ens)
+
+Arnaque identique dans pas mal d'autres organisations.
+
+On a forcé l'authentification. Ça pose aussi des problèmes...
+Anti-spam au crans ?
+
+On décide de bloquer sur tous les serveurs mail, on débloquera quand on aura
+mis en place un truc comme DNSBL (Proposition de Mikachu).
+[[ https://phabricator.crans.org/T412 | Tache phab associée.]]
+
+#### DNS
+
+Il semblerait que l'on ait perdu la délégation de crans.ens-cachan.fr et
+clubs.ens-cachan.fr. On a envoyé des mails à la DSI, sans réponse. On ira les
+voir en personne pour leur demander. On en profitera pour leur demander de
+déployer le VLAN 22 au bon endroit, ainsi que de whitelister notre /22.
+On fera une liste de ce qu'il faut leur demander.
+
+* Mikachu : Est-ce que crans.eu et crans.fr sont générés par re2o correctement ?
+* Chirac : Oui c'est un probleme connu, faut faire du code dans re2o.
+* Chirac se porte volontaire pour piloter quelqu'un dessus, il marquera ça sur
+ une tâche phab.
+
+#### DHCP
+
+* Le service est régulièrement en failed sur le serveur dhcp et il faut
+ supprimer le pidfile pour redémarrer le service. ---> On va checker les bugs
+ report debian, On propose de faire un unitfile qui fait le taf.
+* Machine qui prend mauvaise ip ---> Il faudra regarder, ça semble n'être que
+ des cas isolés.
+* Passerelle mal detectee sur W10 (au moins 3 cas) en filaire --> Notre expert
+ bug report (aka Gasnier) signale que certaines machines sous W10 ne
+ trouvaient pas la passerelle. Il gardait en mémoire la passerelle de
+ switches. On peut peut-être spécifier le / d'ip que les switches prennent.
+
+Le workaround était de mettre la passerelle à la main. Ça marchera plus
+ailleurs, mais c'est plus notre problème /o\
+
+### Wiki en RO
+
+Fardale avait essayé de voir, mais ne savait pas d'où ça venait. On demandera
+aux adhérents concernés si c'est tombé en marche.
+
+### Probleme d'attribution des chambres
+
+Portail captif qui marche pas partout. On a envoyé un mail aux adhérents
+concernés. Beaucoup d'adhérents ont répondu.
+
+Proposition : Les adhérents demandent une chambre, et un cableur vérifie ?
+
+Projet apprenti ?
+On fera une tâche phabricator.
+
+### Switch
+
+Bata-0 aurait apparemment un soucis ? Il va falloir regarder.
+
+### Mails de cron
+
+Les mails de cron (1344 le 9 octobre par exemple) : on prévoit un moment pour
+réparer un peu tout ce merdier ?
+
+* Fardale a réparé une grosse partie des mails liés à bcfg2 (soucis de
+ génération de conf, apparemment réglés, sauf la radio --> Osef On va drop la
+ radio).
+* 2eme vague de cron : adhérent qui est en double dans aliases.db sur
+ redisdead, soyouz, freebox, zamok, titanic.....
+--> Boudy s'en occupe. De quoi ?!
+
+ * Fardale : Le bug vient de l'intranet ou pas ?
+ * aid=2127 d'après le fichiers aliases de postfix son compte a été détruit
+ en 2014 mais il apparait comme actif sur l'intranet, du coup ça pose des
+ soucis car la redirection apparait 2 fois dans le fichier aliases et
+ postfix se plaint.
+ * TODO : régler le problème en scannant les users qui auraient du etre
+ supprimés; et se débarasser le cas échéant des doublons.
+* 3eme type de mail : Erreurs 500 de l'API --> Ça coïncide avec logrotate. Nit
+ a proposé une solution, à tester. On décale le logrotate de 10 minutes pour
+ voir si c'est vraiment lié.
+
+### Problèmes sur Icinga
+
+* {{{/var/log/spool}}} de ft se remplit, les logs n'arrivent pas sur thot
+ * Fardale a regardé, mais ne sait pas trop d'où ça vient. Problèmes dans les
+ confs (Erreurs de syntaxe ?). Quantité énorme de logs, 1Go en 3 jours. Ca
+ a l'air d'être le cas uniquement sur ft.
+ * Chibrac: C'est un probleme de proxmox.
+* ntp sur soyouz --> Fait exprès ou pas ? Soucis dans la génération de la conf.
+ Sombre histoire d'(ip-)typage.
+
+TODO : Refaire le script, vérifier qu'un soucis similaire n'existe pas dans
+d'autres endroits.
+
+### Doc
+
+* IL FAUT FAIRE DE LA DOC sur ce qui a été fait, notamment au moment de la
+ migration. CF la tâche phab [[ https://phabricator.crans.org/T234 | mise Ã
+ jour wiki ]].
+* Gasnier souligne qu'il va falloir une doc très claire en prévision de la
+ reprise du réseau par des inconnus après le départ de l'ENS vers la lointaine
+ saclay
+
+### TV
+
+La TV ? Le cochon est vivant ?
+Boarf, il survit, mais le courant au J fait de la grosse merde. L'onduleur
+commute en permanence....
+On tâche phab et on regarde après.
+
+### Bilans
+
+* Poses de nouvelles bornes. On a enfin du wifi dans certains lieux reculés du
+ G. On est au chomage technique car on n'a pas reçu les bornes. Il faut les
+ appeler, mais il faut quelqu'un qui parle Allemand. Ou on attend.
+* Nouveau
+ système [[ CransTechnique/AutreMatériel/AjouterUnSwitch#A3_-_Provision_de_la_config | provisioning de configuration des switchs ]]. Ça semble marcher, c'est cool, Chirac dit que c'est documenté, on le croit. Boudy : On sait où il habite, on a son numéro si ça marche pas. Mikachu: Au pire on lui casse les genoux.
+* Bilan sur la detection de mac + web redirect --> ça marche ... presque
+ partout. Pas de web redirect, pas de web redirect. A partir de ce WE tous les
+ switches du campus pourront en faire. Tous ? Non un certain nombres
+ d'irreductibles ne font pas de web redirect...
+* interface d'impression --> Elle est prête, je finis de vérifier les bugs,
+ mais normalement elle devrait être lancée ce weekend. Soucis d'ergonomie, Je
+ vais suivre les conseils des experts tels qu'edpibu ou Grizzly.
+* Où en est le firewall ? --> Le fw marche mais n'est pas satisfaisant pour
+ Chibrac. Le rezo metz est en train de dev un truc avec Nftables. On verra
+ pour le déployer au crans, mais faut pas que ça casse des trucs.
+
+Actuellement il juste marche.
+
+### Ménage
+
+* Chibrac dit qu'il faut faire du ménage dans les profils de port (renommage,
+ fusion etc).
+* Pollion: Il faudrait faire ça aussi pour les noms des vlans ...
+
+### Projets
+
+* Apprentis : https://pad.crans.org/p/nounous_encadrantes
+* Recablage de qqs chambres au C: 0C ou 5C ? Notre respo tech préféré se
+ propose pour aider des gens à recabler. On commande une armoire de brassage,
+ on fait ça proprement dans une semaine.
+* Cr@ns-Open --> Grizzly et chirac regardent, si des apprenti.e.s sont
+ motivé.e.s ,pour les rejoindre, qu'ils parlent maintenant, ou se taisent
+ jusqu'Ã leur prochaine intervention.
+* Machines Legacy --> On droppe à la rentrée des vacances de la Toussaint.
+* Boudy : Le compte Crans qu'on utilise depuis tout le temps, il faut qu'on se
+ crée un autre compte qui aura les droits. Car le mot de passe pour se
+ connecter en wifi ou les mails (c'était déjà le cas avant, ça veut pas dire
+ que c'était mieux) c'est le même que celui pour être root sur les serveurs.
+ On envisage de changer ça.
+ * PAC: Propose une authentification 2FA --> C'est pas con.
+ * Erdnaxe : Toutes les nounou doivent avoir une Yubikey. Même gdm le
+ supporte !
+ ---> Et sur tel on fait quoi ?
+
+https://puri.sm/products/librem-key/
+On demande à Charlie ce qu'il en pense.
+
+### DNSSEC
+
+--> Benjamin, Boudy intéressés. Pour les tests on signera d'autres zones comme
+ crans.fr et crans.eu. ça implique de réparer la génération de ces zones !!
+
+Liste non exhaustive de projets :
+
+* Mailman3
+* Ajout automatique aux ml suivant les droits
+* ssh2
+* système de ticket ?
+* ansible <3 erdnaxe
+* Changement système de virtualisation. Vers la fin de Proxmox ? -> Oulà on a
+ d'autres chats à fouetter avant. Et les remplaçants potentiels se bousculent
+ pas au portillon.
+* webnews
+* faire des qrcode/tag nfc pour automatiquement conf le wifi des adhérent (des
+ trucs récents permettent de supporter WPA2-Entrep. sur ce genre de conf)
+
+### Mises à jour
+
+stretch (zephir et omnomnom ; et news :P )
+
+* chiffrement des backups, et de la clef de chiffrement !
+
+Fardale dit que la partition pour les homes des adhérents est déjà faite,
+suffit de chiffrer.
diff --git a/compte_rendus/2019_01_14.md b/compte_rendus/2019_01_14.md
new file mode 100644
index 0000000000000000000000000000000000000000..52edee095479157c526900ed94ded1dd96bf0da9
--- /dev/null
+++ b/compte_rendus/2019_01_14.md
@@ -0,0 +1,389 @@
+# Réunion du Collège Technique
+
+* Date : Lundi 14 Janvier 2019
+* Lieu : 2B
+* Début : 18:47
+* Fin : 21:01
+* <<Pad>>
+
+### Présents
+
+* esum
+* Chibrac
+* Erdnaxe
+* Edpibu
+* elkmaennchen
+* Boudy
+* Pollion
+* Fardale (en visio)
+* Mikachu (arrivée vers 20h15)
+
+## Ordre du Jour
+
+### Bilan des activités crans de ces dernières semaines
+
+On fait un rapide bilan pour que tout le monde soit au fait de ce qu'il se
+passe en ce moment niveau technique.
+
+* On n'a toujours pas d'imprimante.
+
+. Mais on a fait des tests en snmp on récupère plein d'info, Pollion finit ses
+oraux blancs et s'y remet à partir de vendredi.
+. Erdnaxe propose de se renseigner plus sur Icinga pour avoir un meilleur
+monitoring de l'imprimante.
+
+* Autre truc cool, on a remis DNSSEC au crans. Chibrac rappelle qu'il y a des
+ vieux fichiers localement sur silice, on fera le nettoyage.
+
+* Buster freeze bientôt, Boudy fait remarquer qu'on a encore des serveurs sous
+ Jessie...
+
+. Apprentis intéressés ?
+
+* On a fait plein de ménage dans les mails de cron, c'est moins la guerre.
+* Mirroring du dépot re2o upstream au crans, du coup toutes les instances du
+ crans pullent depuis le crans et sont à jour.
+* On a augmenté le nombre de connexions simultanées à la bdd et on a fait le
+ ménage des restes de pg 9.1 et 9.4 qui traînaient sur thot.
+* ça ne règle pas tous les soucis, il reste encore des services qui
+ plantent (exemple erreur 500 sur l'API pour mail-server ...)
+
+* Grâce à Boudy un problème sur les home avait été soulevé : Les home en
+ majuscule posaient soucis. (les vieux diront que c'était mieux avant et
+ qu'ils l'avaient dit mais ....) Il a été réglé.
+
+. Il faudra regarder le script des homes suite au renommage....
+
+* Soucis avec unifi, chibrac regarde il s'en porte garant devant témoin,
+ c'était son idée.
+
+. Erdnaxe aimerait bien (dans un monde idéal) avoir un prof crans pour ça,
+surtout qu'il y a de l'intégration Incinga-Unifi à faire je pense
+
+* On a réglé le soucis des noms des logs du fw sur le nfs.
+ * Odlyd possède une partition à part pour le {{{/var/log}}}, ça peut être
+ cool de faire pareil pour gulp. En plus il y a plein de place
+ dans {{{/var/log}}} sur odlyd. Il faut aussi mettre en place un rsylog
+ pour envoyer les logs d'odlyd vers {{{/home/log}}}. Comment ça marchait
+ avant avec sable ???
+
+ * Fardale soulève le fait qu'il y aurait un soucis avec rsyslog sur thot.
+ Pas mal de vm ont des soucis : Leur {{{/var/log/spool}}} se remplit ....
+ ce sont les fichiers en attente d'être envoyé sur thot....
+
+. Il renseigne tout sur https://pad.crans.org/p/RsysLogMarchePas
+
+* On a aussi migré le gitlab vers le paquet omnibus.
+
+* re2o des choses ont changé, le crans a activement participé au dev de 2.7,
+ qui arrive soon.
+
+### Certificat SSL cassé
+
+https://irc.crans.org/web et il n'y a pas de redirection HTTP > HTTPS
+
+* c'est normal, le port 443 est utilisé par le serveur irc
+* il pourrait être derrière le proxy ?!
+* possible mais c'était pour ne pas changer l'url
+
+Voir le Wiki sur la centralisation
+HTTPS : https://wiki.crans.org/CransTechnique/Chiffrement/CentralisationHttps
+
+Fardale explique pourquoi c'est comme ça, on laisse comme ça, c'est normal.
+
+### Petite pause
+
+Chirac fait une démo de mise à jour de borne, il casse internet, à cause de lui
+l'IN fait une pause de 10 min.
+
+### Parefeu
+
+Zamok: l'accès au vlan adm depuis zamok est restreint par une série de reject.
+Du coup il existe une race condition. Si un compte est crée et que le parefeu
+n'est pas régénéré ce compte aura accès au vlan adm.
+Question : Pourquoi un tel mode de fonctionnement ?
+Proposition : Fonctionner sur un mode de whitelist.
+
+* ça semble pertinent surtout que ça va aussi drastiquement réduire le nombre
+ de règles à parcourir (on va passer de plusieurs milliers à quelques 100aines
+ au pire)
+* Chibrac dit que c'est à cause du NFS que c'était la merde, Erdnaxe pense que
+ c'est un faux problème.
+
+Faut regarder mais tout le monde sauf Chirac trouve ça pertinent....
+
+Par ailleurs, les services re2o de régénération du parefeu plantent salement.
+On en a déjà parlé, mais il faudrait régler ça soon.
+
+### Mail
+
+https://lists.crans.org/admin/ est accessible depuis l'extérieur.
+Pourquoi ? Actuellement on peut scanner les addresses mails des admins, c'est
+chiant. Pollion propose de le dissimuler comme listinfo.
+
+* Mikachu plussoie
+* ça semble simple, Pollion regarde avec sa croziflette après l'IN.
+
+On envoie trop de spam.
+
+* quand on aura fait le ménage dessus, ce serait pertinent une alerte icinga
+ qui affiche la taille de la mailq (si elle existe pas déjà ). comme ça quand
+ elle est trop grande une nounou peut regarder et réparer et/ou aller
+ gentiment blacklister les comptes qui font nawak
+* On a archivé les 3 comptes qui posent problèmes.
+
+. L'archivage :
+
+* Chibrac : Il faut qu'on parle de ce qu'on veut.
+* Fardale : Il faut que Archivage soit un super-set de désactiver.
+* Actuellement :
+ * Désactiver : Actuellement t'es plus dans le LDAP.
+ * Archivage : Desactiver + ça supprime ça libère les IP .
+* Ce qu'on veut :
+ * Désactiver : On veut garder dans le LDAP mais passer shadowExpire=0.
+ * Archivage : On veut supprimer de LDAP + supprimer en plus les home. On
+ veut garder le minimum légal.
+
+On reçoit trop de spam
+
+* on a mis en place des trucs.
+* Benjamin : Il y a un bot qui s'appelle peb qui périodiquement BL des IP.
+
+en cas de redirection @ens-cachan.fr -> @crans.org avec mail avec from
+en @crans.org se fait jeter par redisdead car il n'est pas authentifié.
+
+Question : Quelqu'un a une solution ? Une idée pour chercher ça ?
+
+* On propose de WL l'ENS, et on regarde ce que font les autres.
+
+### VLAN Pub
+
+Il faut passer le vlan pub (aka adh) en tagged comme on l'avait suggéré à une
+IN en Avril/Mai/Juin 2018, je ne me souviens plus. Qui est chaud pour
+aider ? Des apprentis ?
+
+Bon, en fait Chibrac crache le morceau, c'est un peu plus compliqué que prévu
+...... Il faut changer auth.py ....
+Les apprentis font un séminaire sur les switches, puis freeradius.
+
+### Migration
+
+Il faut finir la migration entammée l'an dernier. Benjamin a envoyé un mail Ã
+rezosup concernant leur vm, des nouvelles ?
+
+* Non. On les relance...
+
+Il faut déplacer les IP publiques des serveurs sur le VLAN dmz, pour unifier un
+peu tout ce bordel.
+
+* On groupe tout ça avec les services, on fera une réu bientôt.
+
+### mailman3
+
+Contextualisation: Actuellement on utilise au crans Mailman comme moteur de
+mailing list. Une nouvelle version très différente et améliorée arrive avec
+Debian Buster. Actuellement il existe une vm mailman3 mais elle a été recyclée
+à partir d'un ancien routeur v6 et c'est pénible de faire le nettoyage. On
+cherche donc un (ou plusieurs !!) apprenti pour nuker définitivement cette VM,
+installer une nouvelle VM et faire joujou avec mailman3.
+
+* Erdnaxe veux bien le faire à partir du vendredi 25, mais je fais déjà des VM
+ donc autant que quelqu'un se forme
+* Pollion veut bien encadrer.
+
+### Services à nuker
+
+On propose de se débarrasser des services suivants :
+
+* Limesurvey --> Chibrac est contre le nuker, le reste est pour --> On nuke,
+ et Federez peut se faire un LS
+* Ethercalc --> Ok on nuke sauf si quelqu'un se réveille et rale du fond de sa
+ cave.
+* ligne de VoIP --> On continue de payer la ligne sur le vieux compte OVH. On
+ nuke !!!!!!!
+
+Plus violent :
+
+* Horde > !NextCloud intègre un client Mail, est-ce qu'Owncloud aussi ?
+ * Pollion : Pour avoir fait des tests sur des instances
+ différentes, !NextCloud est vraiment trop gourmand en ressources par
+ rapport à Owncloud, et ce dernier nous suffit amplement. Je ne suis pas
+ certain qu'il faille en changer.
+ * Mikachu : Je +1, j'ai fait l'erreur d'installer Nextcloud au bureau, je
+ vais surement changer pour owncloud, ça consomme une quantité hallucinante
+ de ressources.
+ * erdnaxe : est-ce que l'on connait la raison ? La base de code paraît
+ pourtant similaire ? Après Owncloud doit surement intégrer un client mail
+ similaire à celui de !NextCloud, non ?
+ * Mikachu : normalement les plugins nextcloud/owncloud
+ étaient (sont?) compatibles et sinon après une recherche rapide il y a
+ ça : https://marketplace.owncloud.com/apps/rainloop
+ * erdnaxe : Rainloop est une application équivalente à Horde/Roundcube, mais
+ qui apporte une facilité d'installation car elle se met directement
+ dans !OwnCloud.
+
+* Jabber
+ * Pollion | Plop, je sais que c'est un running gag mais il y a encore des
+ gens qui utilisent le
+ * Pollion | jabber du crans ?
+ * peb | ça arrive, mais de moins en moins
+ * peb | perso je m'en sers occasionnellement
+ * erdnaxe : qu'est-ce que Jabber apporte en plus de Jitsi/IRC ? Tout le
+ monde est sur Discord (mauvais argument, mais malheuresement de plus en
+ plus vrai)...
+ * Il tourne tout seul --> On garde
+
+### Plan de déménagement
+
+Avenir des services : mutualisation crans-aurore oui / non
+Si oui, comment démanager les services à Orsay/Saclay ? Et dans quel ordre.
+
+* On fera une Réu pour ça, on en discute par mails.
+
+### Icinga2 (Propositions d'Erdnaxe)
+
+* Virer la colonne "apt" car il y a "package" ?
+* association.crans.org ? Utilité ?
+ * https://icinga2-guest.crans.org/icingaweb2/monitoring/list/servicegrid?problems&limit=60%2C60
+* Faire un recensement des serveurs que l'on allumera plus jamais
+ * https://icinga2-guest.crans.org/icingaweb2/monitoring/list/hosts?host_problem=1&sort=host_severity
+* Faire le point avec Mikachu pour savoir si Graphana+Icinga2 est toujours une
+ bonne idée vis-à -vis de Munin
+* Mettre des raspberry pi sur Icinga et les brancher en amont des onduleurs
+ pour être informé des coupures élec
+ * Mikachu : tous nos onduleurs savent pas parler le SNMP sur l'internet
+ mondial et globalisé ?
+ * Erdnaxe : L'idée est de monitorer si le rpi est allumé ou non (en
+ branchant son alimentation sur une prise non alimenté par l'onduleur)
+ * Mikachu : oui j'ai bien compris, la question est: l'onduleur ne sait pas
+ parler le SNMP pour dire si oui ou non il est allimenté ?
+ * Erdnaxe : on m'a dit que nos onduleurs étaient pour la plupart « non
+ monitorables » donc je suppose que non
+ * Mikachu : ouki, dans ce cas je suis plutôt d'accord, modulo prendre un
+ truc peut être moins overkill qu'un pi (un pi 1 ou un random clone chinois)
+ * Erdnaxe : Un pauvre uControlleur avec une interface Ethernet pourrait
+ passer (ESP8266 bidouillé...) mais faudrait un client Icinga.
+ * Mikachu : si ça amuse quelqu'un ce serait coolish, je serais curieux
+ d'apprendre, mais j'aurais surement que le temps de regarder de loin :) et
+ tu sais pas faire parler le snmp à ton uC ?
+ * Erdnaxe : https://github.com/1sw/Agentuino Il y a un truc pour les
+ uControlleurs qui sont sur le Framework Arduino
+* https://status.crans.org/icinga2 > Pourquoi ne pas utiliser
+ https://cachethq.io/ qui est fait pour ? -> J'ai une très mauvaise expérience
+ avec à Federez, il est pas possible de l'interfacer avec un système de
+ scripting; l'api put/delete etc qui doit permettre cela
+ est (était ? ) totalement buggée + non packagé dans debian (Ã
+ l'époque ?) -> Dans ce cas remplacer le dashboard (qui est déjà composé
+ d'iframes) par une page Wiki (avec les iframes comme il faut) ?
+ * Mikachu : sinon tu parlais de se servir de grafana, on doit pouvoir faire
+ des dashboards dans ce style avec grafana (avec ensuite des liens fancy
+ vers des pages plus détaillées etc. ça peut être joli, mais faut prendre
+ le temps de le déployer et de le configurer (et de scripter la conf
+ auto (ansible mon amie :D)
+ * Erdnaxe : Je veux bien faire un rôle Ansible (surtout que je commence Ã
+ bien le manipuler avec ce que j'ai fait à Aurore) mais est-ce que je le
+ traduis ensuite en BCFG2 pour ne pas avoir deux systèmes au crans ?
+ * Mikachu : boarf, tu peux faire une maquette fonctionelle avec ansible et
+ on la déploiera en prod quand on passera à ansible :)
+ * Erdnaxe : Passer le crans à Ansible sera plus facile que prévu vu que j'ai
+ traduit déjà quelques trucs pour Aurore.
+ https://gitlab.federez.net/erdnaxe/ansible-aurore
+ * Mikachu : tu peux mettre ça public ? (pour l'instant il faut un compte sur
+ le gitlab d'aurore pour y accéder)
+
+### Wifi qui bogue (Propositions d'Erdnaxe)
+
+Constaté le soir
+
+Ça n'a pas l'air normal
+ça : https://munin.crans.org/crans.org/thot.crans.org/wifi_auth.html
+
+C'est l'occasion pour mieux monitorer les bornes avec
+Icinga-Unifi ? https://munin.crans.org/wifi-day.html
+
+* Erdnaxe : J'ai commencé des tests, la borne est toujours visible mais refuse
+ les connexions. Est-ce que l'on peut monitorer le lien Radius-Point
+ d'Accès ? Personnellement le wifi normal est inutilisable dans ma chambre le
+ soir et je suis loin d'être le seul dans la même frustration, du coup j'ai
+ mon propre AP.
+
+### ft.crans.org pas du tout à l'heure (Propositions d'Erdnaxe)
+
+On a essayé de fix avec un décalage progressif mais il continue à dériver
+
+* le 01/01/2019 vers 9h il a 296.11 secondes d'avance
+* le 01/01/2019 vers 15h il a 308.08 secondes d'avance
+* le 14/01/2019 vers 18h il a 869.49 secondes d'avance, ça empire donc...
+* Mikachu : Il sait pas parler le NTP correctement ft ? en lui faisant faire
+ des query plus souvent pour rester à l'heure ? (je sais pas comment on
+ configure le daemon NTP, ce que je dis est peut être con :))
+* Erdnaxe : Bah de ce que j'ai compris on a une conf NTP client qui a pour but
+ de le faire converger progressivement vers la bonne heure pour ne pas tout
+ casser.
+* Fardale s'en occupe
+
+### Remises à plat de l'infra (Propositions d'Erdnaxe)
+
+Qu'est ce qu'est oidentd ?
+Pourquoi on monitore le fait qu'il soit présent sur tous les serveurs ?
+
+* C'est un relicat du temps où il servait à l'auth pour les connexions à la
+ bdd (cf https://en.wikipedia.org/wiki/Ident_protocol ), c'est plus très utile
+ maintenant. -> cf
+ pg_hba.conf : https://gitlab.crans.org/nounous/bcfg2/blob/master/Python/etc/postgresql/9.6/main/pg_hba.conf partout où il y a écrit ident, et une péletée de services s'en servent : etherpad, roundcube, imap, sqlgrey, horde, mediadrop, icinga, django_cas
+* c'est pas la priorité du siècle.
+
+Conteneur "sitesweb"
+Est-ce bien un conteneur non privilégié ?
+
+* Erdnaxe dit que s'il n'est pas privilégié ça pose des soucis si faille de
+ sécu. Pollion veut bien un petit résumé de ce qu'il a dit + le lien vers le
+ wiki d'Aurore.
+* Explications ici : https://wiki.auro.re/technique:serveurs:conteneur
+
+On se met à faire des conteneurs au crans ?
+
+On pourrait faire un conteneur template re2o-test et ainsi proposer beaucoup
+d'instances ?
+
+* Actuellement au crans c'est bagdad sur le virtu, on peut pas trop faire ça.
+
+### Wiki crans (Erdnaxe)
+
+Séparation partie technique / Partie vie à l'ENS ?
+
+* Mikachu : hein ? faire 2 wiki ? pourquoi maintenir 2 trucs plutot qu'un ?
+* Fardale : la partie technique, c'est tout ce qu'il y a sous
+ CransTechnique (si tout le monde respecte les conventions)
+* Pollion : Non.
+
+Erdnaxe peut se chauffer pour faire un thême crans / ENS ?
+
+* Mikachu : go for it, c'est du frontend, ça peut rien casser, au pire les gens
+ pourront se servir de celui qu'ils veulent.
+
+### Service de boot PXE (Erdnaxe)
+
+Est-ce que qqu le maintient ?
+
+* Mikachu : des gens qui "apprennent" sur le tas quand ça casse. En règle
+ générale c'est un truc qui se maintient assez bien tout seul, sauf quand des
+ gens font mumuse avec les plans d'addressage, dhcp, vlans etc. (en gros sur
+ un réseau de prod "stable" ça casse ~jamais)
+* Erdnaxe : mais il faut update les iso à un moment ? ou on utilise un service
+ externe ?
+* Mikachu : euh je me demande si c'est pas synchro avec le ftp, à vérifier.
+
+. je viens de voir que le script de {{{/usr/scripts}}} pour le pxe a été bougé
+dans archives .... faut vraiment creuser le sujet, bon point erdnaxe.
+https://github.com/antonym/netboot.xyz ? -> Avant d'en déployer un nouveau,
+faire complétement le ménage..
+
+* Pollion : Oui
+
+### Site du Crans (Erdnaxe)
+
+Est-ce que ça gène quelqu'un si Erdnaxe auto-formate tout le code violemment
+pour faciliter les futures contributions ? (problèmes de tab / 4 espaces)
+
+* Pollion : Go for it, bro.
diff --git a/compte_rendus/2019_02_04.md b/compte_rendus/2019_02_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..b92c0db5ccf31eeac1d963929a09bc41a2a644fc
--- /dev/null
+++ b/compte_rendus/2019_02_04.md
@@ -0,0 +1,246 @@
+# Réunion du Collège Technique
+
+* Date : Lundi 04 Février 2019
+* Lieu : Salle de Conférence du Pavillon Des Jardins
+* Début : 18:41
+* Fin : 21:52
+* <<Pad>>
+
+### Présents
+
+* Erdnaxe
+* Edpibu (jusqu'Ã 19h)
+* Elkmaennchen
+* Pollion
+* Fardale (via Jitsi)
+* Boudy
+* Esum
+* !MisterKraft (parti à 19h54)
+* Baptiste Chanus
+* !OursPolaire (18h49)
+
+## Ordre du Jour
+
+### Dans collège technique, il y a collège
+
+J'ai pas trop d'inspiration sur le titre de cette section pour l'instant, mais
+j'ai quelques trucs à dire.
+Il faut tenir au courant de ce qu'on fait et ne pas faire les trucs dans son
+coin à l'arrache (coucou chirac même si t'es pas là )
+
+* Message sur #roots, ou sur les MLs nounou/apprentis, et utiliser phabricator.
+
+### Bilan des activités crans de ces dernières semaines
+
+Toujours pas d'imprimante, personne n'a eu le temps de vraiment s'en occuper.
+
+API re2o : Il y a une issue en cours pour faire du ménage dans l'API, et
+essayer de voir ce qui bloque et pourquoi on a encore des erreurs 500.
+Erdnaxe s'intéresse au problème, Pollion lui a filé un shell root dans un
+screen.
+> voir la gestion des tokens dans l'API : voir re2o-error.log.1 en cherchant api
+> user_id: 20074
+
+Création d'un ssid Cr@ns-5g pour diffuser le 5GHz et ainsi le séparer
+du 2.4 GHz. Ça fait une semaine, on peut lancer de la com dessus, et prévenir
+les adhérents qu'ils le capteront moins fort mais auront un meilleurs débit. Ça
+peut aider à résoudre les soucis d'instabilité qu'on avait avant.
+
+* [[https://cdn.discordapp.com/attachments/387967637940076545/539584015305277451/unknown.png]]
+* [[https://cdn.discordapp.com/attachments/387967637940076545/539584086658908161/unknown.png]]
+
+On fait un rapide bilan pour que tout le monde soit au fait de ce qu'il se
+passe en ce moment niveau technique.
+
+Retours sur la dernière IN, trucs qui ont été faits, pas faits.
+
+### Logs
+
+Ce qu'on veut, ce qu'on ne veut pas, ce qui est important, ce dont on se fout.
+Il pourrait être bon de revoir un peu le système de log, avec les problèmes
+d'envoi de log sur thot par exemple (spool qui explose) (ce est peut être lié
+au problème d'ipv6 sur les serveurs)
+
+### Stockage, partition, wtf ?
+
+Pendant ce temps /home-adh/logs et /home-adh/mail se remplissent sur zbee…
+{{{
+/dev/sdaj1 630G 577G 22G 97% /home-adh/mail
+/dev/sdcv1 296G 275G 6,0G 98% /home-adh/logs
+}}}
+
+--> On a 1 T de
+ libre {{{/dev/mapper/lvm-stock 1008G 72M 957G 1% /stock}}}
+
+Pollion propose de repartitionner tout ça.
+
+* Dans un premier temps on bouge les vieux logs sur zbee de toute façon eux
+ sont déjà backuppés et zbee a de la place.
+* On propose d'exporter le disque de zbee dans home-logs de façon permanente.
+ Il faut réécrire le script de rotation des logs du fw : Si home-logs est
+ monté, on l'envoie sur home-logs, sinon on le garde sur le routeur (pour
+ éviter les soucis en cas de crash du disque de zbee).
+ * A faire pendant la grosse maintenance à prévoir.
+* Les mails se remplissent
+ * peb propose de supprimer les comptes mails inactifs qui consomment de
+ l'espace disque
+* Partition de gulp : Actuellement gulp est partitionné à la zob, et a vraiment
+ plein de place libre non allouée.
+ * On va essayer de rétablir un fonctionnement normal, et ça règlera des
+ soucis de logs.
+* Logs sur Odlyd. Quand c'est lui qui route, comme il n'a pas le NFS, il ne
+ rotate pas ses logs (cf tes mails).
+ * Soit on monte le nfs sur Odlyd
+ * Soit on rsync de temps en temps les logs d'Odlyd.
+
+. ==> On va rsync de temps en temps.
+
+Dans la grosse maintenance on va repartionner gulp et vérifier que keepalived
+marche bien.
+
+### Futurs projets, répartition des tâches
+
+Pour les apprentis : Je rappelle que vous pouvez aller voir sur Phabricator
+pour voir si une tâche vous intéresse et vous pouvez demander à n'importe
+quelle nounou de vous encadrer.
+
+Pollion propose de se poser un Week-end, et de faire quelques petites tâches.
+Par exemple le week-end du 09 ou du 16.
+
+* Mise à jour de serveurs : Les serveurs de backups sont toujours sous Jessie,
+ il serait temps de faire le DU. En lien
+ avec : https://phabricator.crans.org/T178
+ * Esum veut bien s'en occuper.
+* Thelounge3 est enfin sorti. Fardale souhaite l'installer. Ça serait cool que
+ des apprentis y participent, surtout ceux qui utilisent thelounge :). (ça
+ amène plein de feature cool, comme les logs écrits dans un fichier en cas de
+ déconnection)
+ * erdnaxe est intéressé. Je note qu'il faut que je le fasse.
+* Mailman3 : Mailman est le moteur de Mailing List qu'on utilise au Crans. Une
+ nouvelle version sort avec Buster, on veut faire une installation propre
+ avant sur une nouvelle vm, pour préparer la migration. Ça sera l'occasion de
+ parler de mails et peut intéresser les apprentis qui souhaitaient se
+ renseigner dessus.
+ * En l'absence de réponses d'apprentis, Pollion et Esum veulent s'en
+ occuper, ils renverront des mails sur les MLs apprentis et nounous avant
+ pour être sûr.
+* Nuker l'ancienne vm IPV6 (actuellement mailman3). Va avec le point précédent,
+ et ça sera l'occasion de voir comment marche la virtualisation au crans.
+ * idem
+* Liens wiki - re2o : https://phabricator.crans.org/T293
+ * Le wiki est old, c'est pas urgent. On a d'autres trucs à faire.
+* Gros passage de doc, les gens qui savent svp documentez. Je regarde
+ particulièrement Chirac .... Et quand je dis doc c'est pas une copie du code,
+ une doc c'est un truc qui explique : "Si tu veux tel résultat, tu fais
+ ça". Je ne pense pas forcément à re2o uniquement, mais aussi aux reliquats
+ de l'ancienne infra. Exemple de pages pas à jour :
+ * [[CransTechnique/Services/RaDius/AttributionVlan]]
+ * [[https://wiki.crans.org/CransTechnique/AdminSyst%C3%A8me/RoutageFailover]]
+* Migration des derniers serveurs en zone
+ ENS. [[https://phabricator.crans.org/T323}}
+ * On a une quinzaine de serveurs qui doivent garder une ip publique, on les
+ met sur un vlan à part (exemple dmz, avec un autre nom parce que c'est pas
+ une dmz). Les autres serveurs sont sur adm, et certains serveurs ont
+ besoin d'avoir Internet (comme owncloud ou tracker) on les met sur un
+ range d'ip avec internet (aka fil mais pour les serveurs).
+ * Fardale propose de faire un VLAN séparé
+* Réflexion vers Ansible : Erdnaxe ? Après le gala et Prologin, je prépare un
+ séminaire. Chirac a dit que les séminaires ça n'apprend pas grand chose aux
+ autres.
+ * Oui mais non, un séminaire c'est pratique pour que tout le monde soit au
+ courant de ce qu'il se passe.
+ * Erdnaxe est chaud pour un séminaire Ansible \o/
+* mise à jours des noyaux des virtualiseurs /!\ terrain miné
+ * voir
+ https://forum.proxmox.com/threads/pve-kernel-4-15-17-comes-with-high-and-unstable-disk-latency.44217/ pour le problème que l'on rencontre actuellement
+ * On fait un test sur un virtualiseur, et on verra...
+* Changement de soyouz (il existe des serveurs moins cher et mieux chez ovh) si
+ ça motive quelqu'un, on peut le migrer sur un nouveau serveur ovh et c'est
+ cool car ça fait plein de truc différent soyouz (mail, wiki2, tunnel tinc,
+ dns)
+ * https://www.soyoustart.com/fr/serveurs-essential/ c'est pas beaucoup moins
+ cher ni substantiellement mieux.
+ * On fait une tâche phab dans idée, ou todo, c'est pas urgentissime.
+* réparer les certificats letsencrypt
+
+. passage à un certif pour *.crans.org ?
+
+* Pour l'instant c'est aussi une idée, pas ultra urgent.
+* ajouter la gestion de la bdd mysql de zamok sur re2o ?
+ * c'est la bdd des pages persos. On reporte à la prochaine IN.
+* régler: [Django] ERROR (EXTERNAL IP): Invalid HTTP_HOST header: 'www.hp.com'.
+ You may need to add 'www.hp.com' to ALLOWED_HOSTS.
+ * {{{['*']}}} dans ALLOWED_HOSTS ?
+* voir le souci de lvm sur zbee:
+
+. il n'y a
+pas {{{global_filter = [ "r|/dev/zd.*|", "r|/dev/mapper/pve-.*|", "a|/dev/mapper/mpath.*|", "a|/dev/sd.*|" ]}}}
+. je vous laisse vérifier que le mettre en oeuvre dans /etc/lvm/lvm.conf sur
+zbee ne pètera rien
+A mettre dans la conf.
+
+### Séminaires
+
+Quels sont les futurs séminaires ? Allez les apprentis faites pas vos timides :p
+
+* Le séminaire BGP est en cours de préparation. ETA ~ 1 mois. \o/
+* Edpibu : Séminaire Switch
+* Elkmaenchen : Séminaire Freeradius
+* Erdnaxe : Séminaire Ansible
+* Vulcain : Séminaire DHCP
+* Séminaire Sécu du web dans une semaine.
+
+### Est-ce que je peux commiter dans BCFG ? (erdnaxe)
+
+Je fais une branche ?
+
+* Ouais go
+
+### Utilisation de la radio crans
+
+Peut-on y accéder ?
+
+* On a déjà décidé de le supprimer, ça n'a juste pas été encore fait.
+
+### On nuke le service de SMS ?
+
+gammu, on l'utilise ? Qui veut des SMS ?
+
+* L'AMAP par exemple ! une extension de la note 2018 pour commander a distance ?
+* C'était un projet, mais c'est un peu en plan, si vous voulez le reprendre go
+ for it.
+
+### IPV6
+
+Certain serveurs n'ont pas leur ipv6 sur certaine interface (exemple ft sur adm
+je l'ai ajouté à la main)
+
+* dans le cas de ft on avait oublié de changer l'ip quand on est passé de HE
+ aux ip ripe.
+* [[https://icinga2.crans.org/icingaweb2/monitoring/list/services?service_problem=1&(service=%2Aping6%2A|service_display_name=%2Aping6%2A)&sort=service_severity&dir=desc]]
+* Ok, faut voir.
+
+### Les comptes clubs sur zamok
+
+* On réfléchit, on reporte à la prochaine IN, pour l'instant on laisse comme ça.
+
+### Monitoring
+
+Ce qu'on veut, ce qu'on ne veut pas, ce qui est important, ce qui peut attendre
+https://phabricator.crans.org/T433
+
+* On reporte.
+
+### Serveur matrix
+
+Eh ! Eh ! On installe un serveur matrix ?
+
+* du calme, du calme, c'est cool, mais ça pourrait plus un truc à tester Ã
+ servens avant nan ? ;) (où ça des conflits d'intérêts ? je vois pas :p)
+* Si des gens sont chaud on peut tester mais c'est pas urgent.
+
+### Virer association.crans.org d'Icinga et/ou le monitoring de l'imprimante
+
+Car toutes les règles de ces services sont cassées
+
+* On reporte à la prochaine IN.
diff --git a/compte_rendus/2019_04_16.md b/compte_rendus/2019_04_16.md
new file mode 100644
index 0000000000000000000000000000000000000000..1f4dde157d2a357964f07b744241d1f541540761
--- /dev/null
+++ b/compte_rendus/2019_04_16.md
@@ -0,0 +1,264 @@
+# Réunion du Collège Technique
+
+* Date : Mardi 16 Avril 2019
+* Lieu : Amphi Tocqueville
+* Début : 19:15
+* Fin : 21:55
+* <<Pad>>
+
+### Présents
+
+* [[WikiFardale|Fardale]] (via jitsi)
+* Edgar Pierre "edpibu" BURKHART
+* Solal "[[SolalNathan|Otthorn]]" NATHAN (nous quitte à 21h07)
+* Romain "Vulcain" Thibert
+* "[[WikiErdnaxe|erdnaxe]]"
+* Gauthier "Elkmaennchen" CROSIO (disparu à 19h50)
+* Émile Siboulet
+* Arthur "[[Grizzly]]" GRISEL-DAVY
+* Benjamin "[[Benjamin|Esum]]" GRAILLOT
+* Maxime "[[WikiPollion|Pollion]]" BOMBAR
+* Michaël "[[WikiMikachu|Mikachu]]" Paulon
+
+## Ordre du Jour
+
+### Bilan des différents trucs mis en place et lignes directrices des futurs
+projets
+
+#### GitLab CI
+
+Installé
+par [[PaC|PAC]] sur [[CransTechnique/LesServeurs/ServeurVulcain|vulcain]].
+[[PaC|PAC]] n'est pas là on passe ce point.
+
+#### Prometheus et Ansible
+
+Déployé par [[WikiErdnaxe|Erdnaxe]] et [[Grizzly|OursPolaire]]
+
+Déploiement du serveur principal sur une VM. L'installation s'est bien passée,
+mais la création de VM est déjà une aventure. Mise à jour de l'iso dans
+proxmox. [[WikiFardale|Fardale]] suggérait d'utiliser
+le [[CransTechnique/ServicesMineurs/PXE|PXE]].
+
+Petite interlude d'explication sur
+le [[CransTechnique/ServicesMineurs/PXE|PXE]], [[CransTechnique/LesServeurs/ServeurCharybde|charybde]] etc.
+
+Linkage vers la page wiki: [[CransTechnique/ServicesMineurs/PXE]].
+
+Playbooks Ansible:
+
+* Monter LDAP sur une VM fraîche (testé et ça marche ./)
+* Déploiement de Prometheus (testé et ça marche ./)
+* Déploiement des nodes (pas encore testé)
+
+Objectif: On continue à déployer les nodes, on continue à tester, déploiement
+de grafana
+
+{{{[digression]}}}
+
+Création de VM: Discussion sur un [[CransTechnique/Services/DHCP|DHCP]] sur
+adm, pour le moment on estime qu'on n'a pas besoin de ça…
+
+Erdnaxe propose de se documenter sur terraform (https://www.terraform.io/) qui
+permettrait de faire tout ça automagiquement.
+
+{{{[/digression]}}}
+
+Actuellement Prometheus monitore uniquement Prometheus, déploiement des nodes
+ce WE, test du playbook ansible.
+
+Quand tout sera stable et que ça marchera bien on migrera tout ça
+sur [[CransTechnique/LesServeurs/ServeurFy|fy]]. (en
+réinstallant [[CransTechnique/LesServeurs/ServeurFy|fy]] :) )
+
+* [[WikiFardale|Fardale]]: attention [[CransTechnique/LesServeurs/ServeurFy|fy]] est déjà un peu charger il me semble.
+
+#### Mailman 3
+
+Il n'y a pas grand chose à dire en fait.
+
+[[Benjamin|Esum]] a installé la VM sous Buster, elle marche. Il faut la
+configurer avec Ansible. Entre temps mailman3 n'a pas encore été installé parce
+que soucis sur soucis ça a donné une impossibilité de se logguer.
+On poursuit dans cette direction, on déploie petit à petit.
+
+* Elkmaennchen et le CT Aurore intéressés
+
+A priori Via est en train de déployer un mailman3 aussi mais
+d'après [[WikiErdnaxe|Erdnaxe]] ils en chient sur quelques points. Il serait
+interessant de les contacter pour ne pas tomber dans les mêmes pièges.
+
+#### Cr@ns-5g
+
+Historique rapide: Depuis N mois les adhérents avec des Mac ont des soucis de
+wifi (Broken pipe, instabilité wifi etc). On savait pas trop d'où ça venait, on
+avait essayé plein de trucs sans succès.
+
+On a décidé à une dernière IN de séparer les SSID 2.4 GHz, 5 GHz. On n'a pas
+trop de retours dessus, puis une mise à jour du controlleur Unifi est arrivé,
+Chibrac avait dit qu'il gérait mieux la gestion 2.4/5 et a donc refusionné les
+SSID. Idem, on ne sait pas trop s'il y a eu une amélioration, mais il y a ~un
+mois pas mal d'adhérents sont venus dire que le Crans ne marchait plus. On a
+resplitté, et à présent les adhérents avec des devices Apple (Iphones,
+MacOS & co) ne parviennent plus à se connecter sur le SSID Crans (2.4 GHz) par
+contre le SSID Cr@ns-5g (5 GHz) marche parfaitement. Pour le moment on ne sait
+pas exactement d'où ça vient, et on se contente de ça pour l'instant.
+
+On fait un dashboard grafana pour afficher le nombre d'user mac sur le 2.4G
+et 5G ?
+
+En fait il y a déjà un truc du même genre sur le contrôleur Unifi
+
+[[WikiMikachu|Mikachu]]: Une explication au problème qui s'est passé après
+la 2^ème^ séparation des SSID, une mise à jour de MacOS est arrivée récemment
+et dans les release notes ils disent avoir améliorer la gestion du Wifi. Mika
+pense qu'ils utilisent une sorte de cache pour mémoriser que des réseaux font
+du 5GHz, et comme Crans ne fait plus de 5 les devices Apple pourraient ne pas
+vouloir s'y connecter. Who knows ?
+
+[[WikiErdnaxe|Erdnaxe]]: Aux journées Federez [[WikiErdnaxe|Erdnaxe]] a
+rencontré d'autres assos avec exactement les mêmes symptômes et leur a
+conseillé de faire comme nous. Pas de retour pour l'instant.
+
+[[WikiMikachu|Mikachu]]: Apparemment les soucis Mac/Unifi sont connus, Mika
+rapporte d'autres cas qu'il a pu voir dans sa boîte.
+
+#### Micro-code et Virtualiseurs
+
+Fait par [[WikiFardale|Fardale]].
+
+Le microcode est un firmware tournant sur le cpu, qui peut être mis à jour via
+des paquets debian. Le paquet modifie la séquence de boot pour mettre à jour le
+firmware au prochain reboot.
+
+Pour intel les fimrwares ont été mis à jour pour alléger les fix de metldown et
+spectre.
+
+Le microcode a été déployé sur tous les serveurs physiques, il n'attend qu'un
+reboot pour être activé.
+[[CransTechnique/LesServeurs/ServeurFz|fz]] tourne avec le microcode mis à jour.
+
+Testé sur [[CransTechnique/LesServeurs/ServeurFt|ft]] la migration des VM
+de [[CransTechnique/LesServeurs/ServeurStitch|stitch]] (qui n'a pas le
+microcode installé + Ancien noyau) n'a pas fonctionnée (VM éteintes Ã
+l'arrivée) alors que cela n'avait pas posé de problème lors du test
+de [[CransTechnique/LesServeurs/ServeurFz|fz]] (VM migrées
+de [[CransTechnique/LesServeurs/ServeurFt|ft]] vers [[CransTechnique/LesServeurs/ServeurFt|fz]])…
+
+Après la catastrophe grosses lenteurs, prompt qui n'apparaît plus
+etc, [[WikiFardale|Fardale]] a dû se connecter en root, commenter la ligne dans
+grub et rebooter [[CransTechnique/LesServeurs/ServeurFt|ft]]. Une fois le
+reboot terminé les lenteurs avaient disparu.
+[[Benjamin|Esum]] propose de désactiver les patches contre Spectre et
+Meltdown (proposé aussi sur le forum sur lequel Peb avait posté il y a un an).
+
+Bon dans tous les cas on va devoir attendre une grosse maintenance pour faire
+ça, on pourra voir ce qu'il se passe quand on migrera vers Buster, et/ou en
+Juillet-Août.
+
+[[WikiFardale|Fardale]]: Sinon il est peut être interessant de passer sur un
+noyau plus récent qui améliore les patch meltdown et spectre.
+
+### Proposition d'achat de matériel
+
+Il y a aussi ce petit problème de switch de la baie qu'est pas très important
+mais faut quand même…
+
+* https://www.senetic.fr/product/J9774A * 2 (ou 3 histoire d'avoir du spare et
+ de pouvoir le prêter à S&L) 380€
+* https://www.senetic.fr/product/J9979A 90€
+* https://www.senetic.fr/product/JL258A 500€
+* ou `<troll>`https://www.senetic.fr/product/JH329A (moins cher et moins de
+ latence !)`</troll>` 50€
+* ou racheter des alims.
+
+On explique à tout le monde comment fonctionne la
+baie, [[CransTechnique/Services/NfS/OpenIscsi|iSCSI]], [[CransTechnique/LesServeurs/ServeurZbee|zbee]] & co. On rappelle que le 3 Février le Switch est tombé, et du coup ça a coupé tout le réseau. Pas cool. Actuellement c'est un Aruba 48 ports de Spare qui est branché, on va proposer au CA quelques modèles pour racheter un switch.
+
+Le CT propose ce modèle au CA: https://www.senetic.fr/product/J9979A
+
+On propose d'en acheter 2 (pour redonder) + 1 de spare, et puis au pire un
+switch 8 ports c'est toujours utile.
+
+On propose aussi au CA de racheter des Alims pour les switches qu'on a mais qui
+ont perdu leurs alims. [[Grizzly|OursPolaire]] s'en occupe.
+
+### Projet
+
+Matrix a l'air de bien marcher, et toute la conf (ou presque) est déjà sous
+Ansible. On en déploie un au crans ?
+
+Bon personne n'est vraiment chaud et puis c'est maintenir deux trucs pour pas
+grand chose. On peut par contre faire de la pub pour le Matrix d'Aurore.
+
+[[WikiFardale|Fardale]]: je peux déployer ça, je l'ai déjà fait sur un serveur
+perso si besoin.
+
+### Mises à jour
+
+Buster arrive, Jessie-updates et Jessie-backports ont été droppés des miroirs
+debian (et du coup du crans).
+On termine la mise à jour des serveurs de backup ?
+
+Vulcain est chaud à distance on lui filera tous les droits dessus
+évidemment, [[Benjamin|Esum]] veut bien superviser sur place.
+
+### knot
+
+Transition de knot vers bind.
+
+Il y a des trucs chiants avec knot, on veut les views de bind (split
+horizon [[CransTechnique/Services/DnS|DNS]]) que knot n'implémente pas.
+[[Benjamin|Esum]] demande donc au CT (avant de déployer).
+
+[[WikiErdnaxe|Erdnaxe]] serait aussi intéressé, on en profiterait pour déployer
+la conf avec Ansible pour avancer la
+transition [[CransTechnique/Services/Bcfg2|Bcfg2]] vers Ansible.
+
+Le CT n'y voit pas d'inconvénient mais on ne veut pas de downtime.
+
+### Lenteurs
+
+Pourquoi que c'est lent le crans ?
+
+* Symptomes: les ssh mettent 10000 ans à aboutir, le wiki est lent…
+* Causes possibles:
+ * Latence/soucis d'IO: comment on debug ça ?
+ * Savoir si le soucis vient
+ de [[CransTechnique/LesServeurs/ServeurZbee|zbee]] ou de la baie ?
+ * [[WikiFardale|Fardale]]: voir les graphes munin ou les ajouter si il
+ n'y en a pas assez
+ * Problèmes de DNS (récursif ou résolution récursive sur les domaines
+ crans); qui expliquerait assez bien les latences (dont ssh)
+ * [[WikiFardale|Fardale]]: mais ça n'explique pas les ralentissement sur
+ les homes
+ * [[CransTechnique/LesServeurs/ServeurZbee|zbee]] swap depuis quelque jours
+ * [[WikiFardale|Fardale]]: un serveur qui swap c'est normal, après à voir
+ si ça a augmenté brusquement ou non.
+ * Les
+ fichiers [[CransTechnique/Services/DnS|DNS]] de [[CransTechnique/LesServeurs/Virtuels/ServeurSilice|silice]] échoue à se mettre à jour depuis quelques jours.
+ * La partition pour les mails de la baie est pleine à 99% . Fear
+ * La latence des disks
+ de [[CransTechnique/LesServeurs/Virtuels/ServeurSilice|silice]] a explosé
+ depuis quelques jours. C'est le cas de plusieurs VM. C'est synchronisé
+ avec [[CransTechnique/LesServeurs/ServeurStitch|stitch]]. Les autre virtu
+ ont pas ce comportement. Il faut casser la gueule
+ Ã [[CransTechnique/LesServeurs/ServeurStitch|stitch]].
+ * https://munin.crans.org/crans.org/stitch.crans.org/diskstats_latency/index.html
+
+### Routage
+
+Bon en fait on a des soucis de routage v4… On a des boucles sur le réseau…
+
+Va falloir investiguer…
+
+[[Benjamin|Esum]] et [[WikiMikachu|Mikachu]] veulent reprendre le routage et le
+parefeu.
+[[WikiFardale|Fardale]] aussi est motivé pour aider sur ça.
+
+### Gâteau
+
+[[WikiErdnaxe|Erdnaxe]] a accepté de devenir Nounou et a apporté des
+biscuits ([[https://orteil.dashnet.org/cookieclicker|ðŸª]]).
+
+Bravo à lui !
diff --git a/compte_rendus/2019_06_04.md b/compte_rendus/2019_06_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..d80c3d93a8695a6748ae1ba42437c4d1be8f7f14
--- /dev/null
+++ b/compte_rendus/2019_06_04.md
@@ -0,0 +1,327 @@
+# Réunion du Collège Technique
+
+* Date : Mardi 04 Juin 2019
+* Début : 19h52
+* Fin : 21h57
+* Lieu : 2B
+* <<Pad>>
+
+### Présents
+
+* Esum
+* Mikachu
+* Erdnaxe
+* Vulcain
+* Pollion
+* 20-100
+* Solal
+* Raida
+* PAC
+
+## Ordre du Jour
+
+### Liste de tête des choses à faire
+
+* Pare-feu
+* IP Zayo
+* Soyouz2
+* Routage
+* Baie
+
+### Maintenance baie
+
+Il faut changer le switch temporaire de la baie de disques par les petits
+switchs qu'on a achetés
+Il faudrait essayer d'avoir le maximum de gens pour le faire, ce serait
+formateur d'avoir des gens et de faire des choses en même temps
+
+On la fait quand ? En juillet ?
+
+Pollion est dispo à partir de début juillet (genre >= 5 Juillet)
+
+Quid des mails ?
+solution temporaire de esum: virer les % réservés à root dans la
+partition /var/mail (qu'on devrait virer partout, ça sert ~à rien sur des
+partitions où root a pas à écrire)
+solution à long terme: agrandir la partition lors de la maintenance de la baie
+
+### Apparté RENATER
+
+Ça a coupé, on a été avertis, les gens se demandent qui sont sur la ML
+DSI-Cr@ns. Il s'avère que c'est plein de gens random dont des dinosaures. Oups,
+on rajoute le bureau.
+
+### soyouz2
+
+Quand est-ce que les apprentis sont dispo ? Ce serait bien de l'installer avant
+cet été.
+Je suis libre dans la semaine
+Vulcain, Raida, Benjamin sont chauds pour l'installer et tout déployer avec
+Ansible.
+
+### Mettre à jour les serveurs de backup
+
+{{{omnomnom}}} et {{{zephyr}}}
+ASAP, Pollion et Vulcain s'en occupe après ses oraux sauf si vous voulez vous
+en charger avant.
+
+### Titanic
+
+Achevez le. Il est à l'agonie et le rapelle un peu de temps en temps, le pont
+il fait des choses cheloues.
+Est-ce qu'il faudrait pas le réinstaller ? Si on le fait, il faudrait le faire
+en même temps que soyouz2.
+
+Pollion explique ce que fait titanic : il fait passer un minimum vital via la
+Freebox. Mais cette feature a été laissée tombée il y a longtemps, ça n'est pas
+vraiment utile.
+Le gros intérêt est pour les membres actifs de rentrer sur le campus via la
+freebox quand les autres routes (Renater, Zayo) tombent.
+
+Une nouvelle VM a été créée pour que les apprentis jouent avec, et tentent une
+installation en coordination avec soyouz2 (= Spoutnik). Ce serveur s'appelle
+Boeing.
+
+### Cableuse
+
+Pas grand chose à dire à part qu'elle marche et que on va sûrement la mettre Ã
+la Kfet avec Windows 10 / Ubuntu 18.04 en dual boot (Erdnaxe : "Je voulais
+brûler Windows avec /dev/null mais on m'a convaincu que des câbleurs en aurait
+besoin et puis on a une licence")
+Elle fait beaucoup de bruit, quasiment autant que le bruit ambiant Kfet d'un
+jour calme. Si les gens l'utilisent beaucoup, il faudra ptetre investir dans un
+vrai ventilo >8€.
+
+Erdnaxe il a tout réparé, Erdnaxe il est trop bien, on aime Erdnaxe.
+Elle est à disposition des câbleurs.
+
+### Prometheus et fy
+
+Monitoring des bornes et des switchs, notamment.
+
+Besoin d'un coup de main sur les MIBs SNMP mais sinon avec un peu de temps tout
+y sera.
+Est-ce que l'on formatte fy à terme sur buster avec Prometheus ? +1 pour le
+formatage une fois qu'on a une POC de Prometheus qui fait bien tout ce qu'on
+veut :)
+
+Et on reinstalle quoi dessus ? Que prometheus.
+Le souci du stockage qui grossit à l'infini a été résolu ? A priori, avec
+prometheus 2 (donc sous buster), c'est mieux géré, il droppe ce qui est plus
+vieux que $jours (mais il ne sait pas faire de downsampling (= sur les données
+plus anciennes, ne garder que des tendances et pas toutes les données)
+Est-ce qu'on peut avoir des mails plus utiles ? Changer le template HTML des
+mails ferait qu'on divergerait d'une install classique. Essayer de les passer
+en raw text ?
+
+##> envoyer le monitoring sur un channel IRC, plutôt ? Du coup erdnaxe fera un
+chan #monitoring accessible pour tout le monde (munin l'est, grafana aussi).
+Éviter d'y discuter
+Ça en est où niveau parité d'utilisation avec les solutions éxistantes ?
+
+* A priori, tout ce que fait munin, prometeus sait le faire. Sauf l'historique.
+
+Est-ce qu'on a une page alerte comme dans munin ?
+
+On peut avoir le CAS pour se loguer sur grafana ? Ce serait cool parceque ça
+permet de faire du Single Sign On, grafana le supporte par le proxy.
+
+On peut peut-être continuer à garder Munin s'il fait du downsampling, et que
+les vieux s'en servent ça peut aider à proposer un diagnostic non ?
+
+### Knot
+
+Il y a eu des soucis avec Knot depuis qu'il a été mis en place, et il
+semblerait que certaines feature de Bind ne soient pas supportées correctement.
+
+Proposition : Revenir à Bind. Des gens sont motivés pour le faire, donc
+pourquoi pas. On fera ça dans l'été, il n'y a pas urgence.
+
+### RFC2136 avec knot/bind
+
+On pourrait utiliser certbot en wildcard avec cette RFC.
+On pourrait réécrire le service re2o DNS pour utiliser cette RFC.
+On pourrait drop le service re2o DNS et laisser le serveur DHCP remplir le DNS
+quand un client se connecte avec cette RFC.
+On pourrait expérimenter des choses fun quoi... avec cette RFC.
+
+Marrant, mais pas urgent. On le rajoute dans la file d'attente mais avec une
+priority low
+On envoie un mail.
+
+Mika met en garde, on peut perdre des trucs au reboot, faut voir.
+
+### Mailman 3
+
+Faut motiver qqun dessus mais c'est critique et stressant.
+Pendant l'été
+TOUT PENDANT L'ETE !
+On peut faire plein de choses pendant l'été.
+
+### Proxmox et le stockage
+
+Est-ce qu'on essaie de faire un truc plus propre ? pourquoi s'embeter avec du
+LVM et pas faire gentiment du qcow2 ?
+(proposition: on exporte la baie en iscsi et on fait juste des disques
+qcow2 dedans, pas besoin de lvm, pas besoin de quoi que ce soit de relou...)
+
+##> Erdnaxe : ça semble + maintenable que la solution actuelle donc je suis pour.
+
+Attention à ne pas mettre trop de trucs en place en même temps tout de même.
+Chaque chose en son temps.
+
+Voir le tableau des stockages supportés
+ici : https://pve.proxmox.com/wiki/Storage
+
+Certains types de stockage ont été testés sur la baie de Servens, comme prétest
+avant le Crans. Cours résumé ici :
+
+Qu'est-ce qui a été testé à servens ?
+ZFS over iSCSI
+ZFS puis export en NFS de pools zfs
+ZFS puis export en iscsi de volumes lvm dans la pool
+
+Question : Pourquoi ne pas faire directement du iSCSI
+
+* Parcequ'on avait envie de s'amuser avec ZFS
+
+Erdnaxe propose du Ceph en achetant du stockage, mais c'est plutot une solution
+pour Aurore ça…
+Mikachu précise que bien que Ceph semble interessant, c'est seulement dans le
+cas où il y a plusieurs serveurs de stockage, et accessoirement avec une baie
+comme la notre, il faut mettre un serveur en plus si on veut faire plus que
+juste exporter en iscsi
+
+Erdnaxe répond qu'on pourrait mettre des disques dans chaque virtu et faire du
+ceph dessus (l'idée est de garder la baie que pour les mails/homes)
+
+Mikachu : Euh ça semble relou/20, ça veut dire que la mort d'un virtu implique
+aussi la mort d'une partie de ton stockage, mais ça peut se faire, je sais
+qu'en général les gens aiment bien séparer le compute (des hyperviseurs avec
+peu de disque et beaucoup de cpu/ram) et le storage (des baies avec plein de
+disques (et des ssd potentiellement pour faire du cache) et pas beaucoup de
+cpu/ram)
+oh ok :)
+
+On coupe court à cette discussion : Ça ne sert pas à grand chose dans ces
+conditions. Il vaut mieux faire un thread sur la ML nounou@ pour que les gens
+aient le temps de regarder pour donner leur avis.
+
+Lien vers l'issue phabricator : https://phabricator.crans.org/T434
+
+### Runner gitlab
+
+Ça en est ou ? Ça semble tourner sur {{{vulcain}}} mais on n'en fait pas la
+pub. Est-ce que le souci d'espace disque a été résolu ?
+Il suffit de pull une deuxième image LaTeX différente pour saturer la CI.
+Normalement la ci est censée faire le ménage dans les images peu utilisées mais
+c'est pas trop le cas.
+Après je trouve que l'on a été radin sur l'espace disque ici.
+Solution :
+Augmenter un peu le /var/docker
+Mettre un cron qui `docker image prune` régulièrement. Erdnaxe propose de
+chercher ce que fait Gitlab, car pour le moment il crashe quand ça sature
+plutôt que de nettoyer.
+
+### Migration des serveurs sur les ip RIPE
+
+Un certain nombre de serveurs sont encore sur le / d'ip de l'ENS. Ça serait
+bien de tout passer sur les IP Crans
+sur 185.230.79.0/24 (voir [[https://phabricator.crans.org/T323|l'issue
+phabricator]]), vlan qui a été nommé DMZ l'an dernier.
+
+On rappelle ce qu'est une DMZ : Il s'agit plus d'un sous-réseau séparé du
+réseau local. On y met les machines qui doivent être accessibles depuis
+Internet, mais qui sont susceptibles d'être attaquées, et n'ont pas besoin
+d'avoir un pied sur le réseau local.
+
+Actuellement Adm est le contraire d'une DMZ : Il s'agit d'un VLAN
+d'administration sur lequel on a mis tous les serveurs crans. Les ip derrière
+ADM ne sont pas accessibles depuis Internet.
+
+A-t-on vraiment envie de faire une DMZ ?
+
+### Mise en avant des services crans et statistique d'utilisation
+
+On a plein de service cool mais souvent aucune pub n'est faite pour et on ne
+sait pas ce que les gens utilisent ou pas. Ça serait cool de regarder pour
+faire des stats sur ça réfléchir à la mise en avant de service. Du maintien ou
+non de service (coucou les news)
+
+Erdnaxe dit que pour la plupart des services on peut facilement exporter
+l'utilisation s'ils sont derrière un nginx (prometheus).
+
+Réponse : Alors non ça ne fait pas tout, mais ça sera déjà un début, par
+exemple tu peux vouloir avoir le nombre de pad créé et ça je ne pense pas que
+le fait qu'il soit derrière nginx t'aide.
+
+Erdnaxe : Gitlab exporte de base en prometheus, django a un module pour
+
+esum rappelle aussi que l'on peut faire des livrets
+On envoie ce problème au CA
+
+### Séminaires à la rentrée
+
+Git le retour , Django, howtobasic du Crans (PAC, qui n'as pas encore choisi)
+
+##> Django Contrib (erdnaxe) mais ptetre trop avancé pour un premier séminaire
+il faut commencer par python puis django peut être
+
+Pour la rentrée il vaut mieux des séminaires faciles : Introduction à Linux,
+shell, ssh, comment marche le crans, internet c'est magique ? Le !BaBa de la
+sécurité & co. Python basique ça rentre dans les séminaires de rentrée oui.
+Après vu que Pac part en germanie on peut aussi faire d'autre types de
+séminaires
+
+### Ansible
+
+On fait le bilan d'Ansible. Ce qui a déjà été fait, quelle est la prochaine
+étape.
+
+Erdnaxe, avec l'aide d'autres membres du CT, a mis en place un certain nombre
+de playbooks Ansible. L'objectif à court terme est de remplacer BCFG2 qui
+viellit un peu.
+
+Actuellement c'est toujours plus ou moins en phase de test, et seuls les
+serveurs les plus récents ont été mis en place avec Ansible. Peu de gens sont
+formés pour l'instant.
+
+On propose d'avancer durant l'été dessus, ça serait cool de faire une
+transition depuis BCFG2.
+
+### Le portail captif
+
+Le portail captif fonctionne au Villon.
+
+### Le Wifi
+
+Chirac a mis à jour les bornes et ça a cassé le wifi.
+
+Bilan :
+
+* Le SNMP ne marche toujours pas dans les nouvelles versions du coup monitoring
+ is not coming !
+* Le Wifi a violemment diminué de portée.
+* Il faut bidouiller pour pouvoir se reconnecter.
+
+On rappelle aux nounous que c'est bien de faire des tests avant de mettre Ã
+jour des services assez critiques comme les bornes. Surtout quand une simple
+recherche sur la mise à jour indique une forte instabilité. Pour les bornes par
+exemple, celle du 2b est entre autre là pour ça. Par ailleurs, il faut vérifier
+que tout fonctionne correctement après la mise à jour.
+
+On rappelle aussi qu'il faut arrêter de rager dès que quelqu'un fait quelque
+chose qui casse un truc ; ça peut arriver. On rappelle (encore une fois) aux
+gens qui ont l'habitude de casser des trucs qu'il faut se coordonner avec le
+reste de l'équipe technique et ne pas tout faire seul dans son coin. Personne
+n'est infaillible.
+
+On va donc downgrade vers une mise à jour stable pour récupérer un meilleur
+wifi.
+
+### Commission achat Crans - AURORE
+
+Le CT doit désigner 2 membres pour le représenter à la commission achat
+crans-AURORE.
+
+Ce sera Mikachu et Erdnaxe
diff --git a/compte_rendus/2019_09_30.md b/compte_rendus/2019_09_30.md
new file mode 100644
index 0000000000000000000000000000000000000000..837d381110f8416784f806c787acaa91ed33eac6
--- /dev/null
+++ b/compte_rendus/2019_09_30.md
@@ -0,0 +1,463 @@
+# Réunion du Collège Technique
+
+* Date : 30 Septembre 2019
+* Début : 19h
+* Fin : 21h25
+* Lieu : Salle de conf du PDJ
+* <<Pad>>
+
+## Présents
+
+* Mikachu
+* Krokmou
+* Erdnaxe
+* Pollion
+* Esum
+* Vulcain
+* Elkmaennchen
+
+### Des gentils première année
+
+* h@chi.no
+* !TinyLinux
+* Aka
+* Charles
+* Batablu
+* Tinette
+* Armand2
+
+## Manger
+
+Sarcozy se propose de nous ramener des pâtes de la soirée C4, donc on accepte
+et on commande des pâtes.
+
+## Ordre du Jour
+
+On commence par faire un bilan des derniers événements
+
+## Incidents et autres interruptions de services
+
+### Crash de thot le 21 Juillet 2019
+
+Pollion a tenté un changement de disque dur de Thot. À cause de l'agencement
+non protestant des disques (RAID logiciel sur 4 RAID0 gérés par une carte
+propriétaire HP) thot a crashé. On l'a réinstallé.
+Mais pas trop le choix sur les Gen7-, on a gardé un truc de vieux sur les
+Gen8+ alors que le mode HBA sur une carte Raid HP aurait pu éviter ça.
+Le Raid logiciel c'est coool et je suis de l'avis que Raid bien fait
+logiciel > Raid matériel « boîte noir déconnante »
+
+Pour plus d'informations, allez
+lire : https://wiki.crans.org/CransTechnique/MaintenancesEtIncidents/20Juillet2019
+
+On manque de compétences sur ces sujets, mais aller tester à ServENS est une
+bonne idée et c'est ce que Pollion a fait !
+
+Faire un séminaire sur le stockage ? RAID, ZFS, NFS, iSCSI ... ? -- Mikachu,
+qui se propose pour le faire un jour ==> Cool.
+
+### Tocardise de Pollion
+
+En bossant sur les radius, Pollion n'est apperçu qu'Odlyd n'était pas du tout
+dans la conf des switches. Il a donc décidé de le rajouter. Pour ça il a voulu
+utiliser le script re2o de provisionning des switches.
+
+Après une rapide discussion sur la non documentation de ce script, il a essayé
+de le modifier pour le rendre plus fonctionnel, avec un menu d'aide et
+notamment un dry-run. Bon, il avait une erreur dans son script et il s'est
+planté, il a lancé le provisionning en mode normal au lieu de dry-run. Résultat
+des courses, il y a eu une petite confusion sur les conf des switches du
+batiment M. En voulant réparer son erreur, il s'est rendu compte que plein de
+switches étaient mal enregistrés dans la BDD (un arping ne donnait pas la bonne
+MAC, donc soit c'était un problème de switch mal enregistrés, soit c'était une
+permutation de conf). Dans le doute, il faut prendre la pire situation, donc il
+s'est tappé une visite de la plupart des locaux techniques avec un cable série
+pour vérifier ça à 2h du mat.... Ça lui apprendra.
+En plus, les switches du RU n'ont pas réussi à reboot tout seul, mais comme
+c'était les vacances le RU était fermé. C'est réglé.
+Faudrait monitorer les switches (erdnaxe ?).
+
+### Inondation du -1I --> Coupure
+
+On ne pouvait pas faire grand chose. L'eau chaude du I, J, H était aussi down.
+Je pense que les gens sont plus intéressés par l'eau chaude que internet (enfin
+quoique...).
+
+### Maintenance d'Août 2019
+
+On a profité qu'il n'y ait plus d'électricité pendant un après-midi. On avait
+prévenu les adhérents via un mailall.
+
+Ce qui était prévu :
+
+* Changement du Switch de la baie
+* Agrandissement de {{{/var/mail}}}
+* Fin de la migration vers le subnet 185.230.76.0/22 (à nous, pas à l'ENS)
+
+vulcain à croisé la DSI et chez eux c'est la guerre :
+/!\ ON PERD NOS IP LE 15 OCTOBRE. AAAAAAAH !!!! DE TOUTES FACONS DEBUT NOVEMBRE
+YA PLUS DIPV4 !!!! C'EST LA FIN DU MMONDE !!!!! AAAAAAHHHHHHHHAAAAAAHHHHH !!!!
+
+* Mise à jour de la baie
+* Mise à jour du bios des virtualiseurs
+* Mise à jour du backbone
+
+Ce qui a été fait :
+
+* Changement du Switch de la baie
+* Agrandissement de {{{/var/mail}}}
+* Mise à jour de la baie --> IMPOSSIBLE
+* Vérification des failovers, radius, postgresql (qui n'avait pas sa partition
+ montée lol)...
+
+>> On n'a pas réparé le soucis avec le routage des IPv4 publiques Cr@ns. <<
+
+##> Faut trouver une solution et réparer.
+
+Pour les détails, voir le paragraphe suivant (quelle cohérence \o/)
+
+## Retour sur les décisions de la dernière IN
+
+[[ComptesRendusCrans/Mardi04Juin2019 | dernière IN]]
+
+On va annoncer les points dans le même ordre
+
+## Maintenance baie
+
+Le switch a été changé.
+
+## Quid des mails ?
+
+On a agrandi {{{/var/mail/}}} et on a viré les % réservés à root dans cette
+partition.
+
+On attribue un coeur en plus à redisdead pour qu'il arrête de crier à chaque
+fois qu'il fait une compression ?
+
+Je doute que ça règle le soucis, il va jsute prendre 100% de 2cpu
+pendant ~2fois moins longtemps
+On limite les performances dispo pour le process ?
+On rallonge le temps passé à 100% avant de lancer une alerte ? -> pas con (oui
+je sais o:) :D)
+
+ -> ça représente ~5min
+
+erdnaxe vient de monter l'alerte à >10mn. On passe à 15mn si ça ne suffit pas.
+On le met dans Ansible.
+
+## Sputnik (Soyouz2) https://lutim.crans.org/rKdWLFev/7gU52JVF.jpeg
+
+erdnaxe n'a pas trop envie d'être seul devant Soyouz2, en vrai le minimum
+syndical a été installé. Il faut maintenant tout migrer.
+En réalité le taf à faire ici correspond à une migration BCFG2 -> Ansible.
+
+C'est un projet parfait pour un apprenti : https://phabricator.crans.org/T443
+et des apprentis sont motivés, c'est cool --> Hachino, !TinyLinux, Batablu (si
+d'autres apprentis sont motivés, feel free to join !)
+
+erdnaxe par contre est ultra volontaire pour former des codeurs Ansible et
+relire des MR.
+
+En parlant de wiki on nous signale des soucis, Hachino dit que de façon très
+bizarre, il lui arrive de changer de theme, erdnaxe dit qu'il a déjà eu le
+soucis, on ira regarder.
+
+## Mettre à jour les serveurs de backup
+
+{{{omnomnom}}} et {{{zephyr}}} ont enfin été migrés sous Stretch par Vulcain,
+encadré par Pollion. Et ce, avant la release de Buster eheh.
+et les webnews ? Nope.
+
+## Titanic
+
+Il y avait un gros soucis avec le DNS, problèmes de permissions and co. Le DNS
+était à genoux sur tous les serveurs, les zones ne se généraient plus depuis
+des mois. Ça cassait DNSSec mais puisque personne ne valide ça n'embêtait
+personne, et vu que Silice et Soyouz sont surdimensionnés, ils n'avaient pas le
+problème de perf. Pollion a corrigé tout ça, Titanic n'est plus du tout Ã
+genoux, et DNSSec marche \o/
+
+## Boeing
+
+Pour remplacer titanic, c'est en pratique la même tache que Soyouz2.
+
+## Prometheus et fy
+
+Actuellement les problèmes de monitoring sont envoyés sur un chan irc
+idoine[^ça veut dire quoi ?] : #monitoring.
+
+LE MONITORING EST CLEAN ! et ouaip le crans n'a jamais aussi été propre (On
+parle bien d'un bot d'esum fait tourner de son côté qui est utilisé pour plein
+d'autre truc et non documenté ?)
+
+Le monitoring des bornes a bien été mis en place. Ça a pas mal spammé quand le
+controlleur a été coupé un moment pendant les vacances mais c'est revenu à la
+normale. On continue le monitoring à fond cette année. Des volontaires ?
+
+[[http://lutim.crans.org/IGaYWBqh/fA9qZePT.png]]
+
+Problème de la persistance sur 25jours. Censé être trivial à fix
+dans {{{/etc/default/prometheus}}}, mais erdnaxe est un tocard et à fail la
+dernière fois qu'il a tenté de changer ça (j'ai ptetre juste oublié de restart
+le service avec la fatigue)
+Niveau espace disque la VM risque d'etre limite pour contenir 1an, mais l'algo
+de compression a des surprises et il se pourrait que ça marche au final. Il
+faudrait récupérer moins d'info inutiles en SNMP pour nettoyer la bdd
+prometheus.
+
+Grafana utilise le CAS ?
+Non mais il faudrait. Il faut définir dans NGINX le fait d'aller chercher le
+CAS et de passer le nom d'utilisateur en variable.
+
+Réinstallation de fy ?
+On backup quoi ? munin
+On réinstalle juste prometheus ?
+
+Ok pour la réinstallation, on backup munin je pense que ça suffit.
+
+QUESTION IMPORTANTE POUR FAIRE AVANCER/MOTIVER ERDNAXE :
+Prometheus et les serveurs sous Stretch => est-ce que l'on prend le paquet de
+backport qui monitore en plus Systemd et APT (et donc qui remplace monit et
+munin entièrement de ce que j'ai vu) ?
+
+##> It's a go.
+
+Dans le dernier épisode :
+
+Est-ce que l'on formatte fy à terme sur buster avec Prometheus ? +1 pour le
+formatage une fois qu'on a une POC de Prometheus qui fait bien tout ce qu'on
+veut :)
+On va tester le downslampling sur la vm et quand tout marchera bien, fy fera du
+monitoring.
+
+Et on reinstalle quoi dessus ? Que prometheus.
+Le souci du stockage qui grossit à l'infini a été résolu ? A priori, avec
+prometheus 2 (donc sous buster), c'est mieux géré, il droppe ce qui est plus
+vieux que $jours (mais il ne sait pas faire de downsampling (= sur les données
+plus anciennes, ne garder que des tendances et pas toutes les données)
+
+On peut peut-être continuer à garder Munin s'il fait du downsampling, et que
+les vieux s'en servent ça peut aider à proposer un diagnostic non ?
+
+Bah, du graphage sans historique, c'est pas très utile, parce que ça permet pas
+de répondre aux questions du type
+"Ce disque s'est rempli, mais est-ce que c'est symptomatique d'un
+problème (=> le régler; virer le garbage généré), ou une inflation normale
+résultant d'une tendance globale longue durée et on vient seulement d'atteindre
+la barre (=> agrandir le disque) ?"
+Historique sans downsampling, c'est mieux que pas d'historique du tout (on n'a
+pas besoin de garder les précisions sur la durée), mais ça va vite poser des
+problèmes d'espace disque et de perf pour tracer les graphes (si je te demande
+de tracer le graphe sur 1 an et que tu dois compiler 1 data/min sur un an, tu
+vas en chier).
+Donc bah sans solution correcte à tout ça, jeter munin me paraît
+dangereux. -> prometheus ne renvoie pas tout heuresement
+D'un autre côté, au fur et à mesure que vous renouvelez certains morceaux de
+l'infrastructure, si vous les ajoutez pas à munin, il finira effectivement par
+ne plus remplir son purpose.
+
+Conclusion : On fait par ordre de priorité : Downsampling avec
+Prometheus > Couper les munin nodes > Formattage de fy et reinstallation.
+
+## Knot
+
+Résumé du dernier épisode :
+
+Il y a eu des soucis avec Knot depuis qu'il a été mis en place, et il
+semblerait que certaines feature de Bind ne soient pas supportées correctement.
+Proposition : Revenir à Bind. Des gens sont motivés pour le faire, donc
+pourquoi pas. On fera ça dans l'été, il n'y a pas urgence.
+
+##> On n'a pas eu le temps de le faire pendant l'été, il faudra toucher le
+service et du ansible....
+
+## RFC2136 avec knot/bind
+
+Résumé du dernier épisode :
+
+On pourrait utiliser certbot en wildcard avec cette RFC.
+0+On pourrait réécrire le service re2o DNS pour utiliser cette RFC.
+On pourrait drop le service re2o DNS et laisser le serveur DHCP remplir le DNS
+quand un client se connecte avec cette RFC.
+On pourrait expérimenter des choses fun quoi... avec cette RFC.
+
+Marrant, mais pas urgent. On le rajoute dans la file d'attente mais avec une
+priority low
+On envoie un mail.
+
+Mika met en garde, on peut perdre des trucs au reboot, faut voir.
+
+On en rediscute, car on a envie de faire un certificat wildcard.
+
+## Mailman 3
+
+LOL !
+
+Résumé du dernier épisode :
+Faut motiver qqun dessus mais c'est critique et stressant.
+Pendant l'été
+TOUT PENDANT L'ETE !
+On peut faire plein de choses pendant l'été.
+
+--> On a présenté mailman aux 1A, mais la migration n'est pas une priorité, on
+ ne s'est pas attardé dessus.
+
+## Migration des serveurs sur les ip RIPE
+
+Parler de la maintenance d'Août.
+
+Résumé du dernier épisode :
+
+Un certain nombre de serveurs sont encore sur le / d'ip de l'ENS. Ça serait
+bien de tout passer sur les IP Crans
+sur 185.230.79.0/24 (voir [[https://phabricator.crans.org/T323|l'issue
+phabricator]]), vlan qui a été nommé DMZ l'an dernier.
+
+On rappelle ce qu'est une DMZ : Il s'agit plus d'un sous-réseau séparé du
+réseau local. On y met les machines qui doivent être accessibles depuis
+Internet, mais qui sont susceptibles d'être attaquées, et n'ont pas besoin
+d'avoir un pied sur le réseau local.
+
+Actuellement Adm est le contraire d'une DMZ : Il s'agit d'un VLAN
+d'administration sur lequel on a mis tous les serveurs crans. Les ip derrière
+ADM ne sont pas accessibles depuis Internet.
+
+A-t-on vraiment envie de faire une DMZ ?
+
+On a migré en srv.
+
+################################################################################################################################
+
+Cool on a donc bien avancé.
+
+################################################################################################################################
+
+## Lutim
+
+Projet d'apprenti fait par Vulcain, encadré principalement par esum.
+C'est un pastebin pour des images, c'est cool ; un nouveau service.
+
+Vulcain a mis en place un nouveau service.
+Ça a l'air de bien marcher. On peut faire de la pub sur la page d'accueil de
+l'intranet.
+
+## Services framadate
+
+Projets d'apprentis, apparemment frama ferme des projets, ça peut etre
+pertinent de lancer un apprenti sur un projet des services frama qui
+ferment. À voir.
+
+## Les backups
+
+Lien avec le crash de Thot susmensionné, les backups des bdd étaient mal faits,
+Pollion a mis en place un réplicat postgres en RO sur Odlyd. C'est déjà mieux.
+
+Chiffrement des backups : Ça n'a toujours pas été fait, mais ça peut se faire
+soon. Fardale toujours intéressé pour aider même si ça fait ~1an et demi qu'il
+en parle ?
+(Fardale a mis en place un serveur chiffré récement donc a à nouveau charger
+les données en mémoire, ça ne durera pas éternellement)
+
+## Carte Raid sur thot, ou comment changer un disque ?
+
+Erdnaxe a expliqué rapidement son idée de HBA :
+Il existe une méthode pour pouvoir passer outre la carte raid et envoyer
+directement les disques au noyau
+linux (https://fr.wikipedia.org/wiki/Contr%C3%B4leur_h%C3%B4te_de_bus) accessible via une mise à jour du bios à partir des HP Gen8, donc accessible pour thot.
+
+On a encore un serveur de test, on va essayer de mettre ça en place et on
+envisage une nouvelle install de thot sous ce mode si ça marche bien.
+
+## DHCP
+
+Lors de la migration vers re2o, le serveur DHCP primary a été passé
+sur [[CransTechnique/LesServeurs/ServeurOdlyd|odlyd]] alors que le secondary a
+été passé sur la vm [[CransTechnique/LesServeurs/Virtuels/ServeurDhcp|dhcp]].
+La personne qui a fait ça est "Votre Nom <Vous@exemple.com>" cf commit
+dece79374f94b64c3a79dfd9e8c54d03e3afb936 sur BCFG2. Anyway, qu'est-ce qu'on
+fait ? On change ?
+
+On décide de revert et de changer.
+
+Dans tous les cas, penser à changer la page wiki
+https://wiki.crans.org/CransTechnique/LesServeurs/Virtuels/ServeurDhcp
+
+## Ansible
+
+Il faut continuer, on fera une IN spécial Ansible pour lister tout ce qu'on
+doit faire avec.
+
+Il existe un serveur qui est sous buster et non sous ansible.
+
+## Les disques cassés dans le 0b
+
+Quid du disque orange de la baie ? --> On les rachete, pour la baie pas de
+soucis pour changer, pour gulp ça va être probablement le même soucis que pour
+thot. On annoncera une petite interruption de services et on passera sous
+Buster à la toussaint.
+
+## Séminaires édition 2019-2020
+
+« Wow » beaucoup de jeunes au premier séminaire (salle de conf du Pavillon des
+jard rempli au 3/4).
+L'ambiance est VRAIMENT cool, y a parfois à manger en plus.
+faut continuer comme ça et faire son max pour faire vivre les
+séminaires ! C'est pas si difficile de faire venir des gens et faire de la pub
+si on s'y prend à beaucoup.
+C'est une des grandes forces du Cr@ns et c'est qqch qui continuera d'exister
+après le déménagement donc autant mettre l'énergie ici. Et c'est aussi un peu
+le coeur de l'assos :
+$$ \frac{\mathrm d \text{séminaires}}{\mathrm d t} > 0 \implies \frac{\mathrm
+d \text{gens compétants}}{\mathrm d t} > 0 \implies \frac{\mathrm d \text{vie
+de l'assos}}{\mathrm d t} > 0 $$
+
+## SATIE + Crans
+
+PAC et erdnaxe ont vu deux personnes du SATIE. Après long étallement de cahier
+des charges d'un projet qu'ils veulent organiser, il semblerait qu'un
+Matrix (non fédéré) + !EtherPad leur convient parfaitement.
+On est en train d'installer une instance de test pour leur faire tester.
+Deadlines ?
+Ça peut être un chouette début de projet, ils ont clairement pas le même
+background en info que nous et du coup ils n'imaginent pas forcément qu'une
+solution à un de leur besoin existe.
+On peut leur apporter des solutions qui (on l'espère) vont ptetre beaucoup les
+aider.
+Il faudrait faire idem dans LURPA / LMT...
+
+On peut avoir le cahier des charges ? Ils devront adhérents au Crans ? Qui
+finance ? (Les adhérents n'ont pas à financer un projet pour des non
+adhérents + si le crans perd la gestion de la connection il lui faudra d'autre
+source de revenu)
+
+On laisse au CA
+
+## KWEI
+
+On a ouvert le portail captif au KWEI, allez voir le monitoring si vous voulez
+voir l'utilisation.
+Ok, ça marchait, on remettra ça pour l'install Party. C'est la nouvelle version
+de fête du slip. En plus c'est monitoré.
+Erdnaxe va documenter tout ça :) !
+
+## NGINX qui reverse Apache cassait des choses
+
+!PhpMyAdmin pleurait et Wordpress redirigeait à l'infini car Apache se croyait
+en HTTP Ã cause du reverse proxy NGINX.
+Solution ! On dit à NGINX d'ajouter un header pour dire à son poto Apache qu'il
+est en HTTPS.
+Et ça marche ! Son&Lumens ont enfin leur Wordpress fonctionnel, erdnaxe pense
+également en parler au BDS (ils souhaitaient déménager leur wordpress à une
+époque).
+
+## Module NGINX de certbot
+
+Bah en fait avec ça un certif wildcard ce n'est plus si pertinent...
+Genre vraiment `certbot renew --nginx` c'est la folie.
+Est-ce que l'on passe dessus à la place du module standalone/webroot ?
+
+Le mieux c'est de faire du wildcard, donc on reste comme ça.
+
+## Fin de l'IN
+
+Bon, Sarcozy n'est pas venu avec les pâtes donc on a faim...
diff --git a/compte_rendus/2019_10_21.md b/compte_rendus/2019_10_21.md
new file mode 100644
index 0000000000000000000000000000000000000000..42779ab6ca26fba6f66d8d5700ba3c0391221bd1
--- /dev/null
+++ b/compte_rendus/2019_10_21.md
@@ -0,0 +1,225 @@
+# Réunion du Collège Technique
+
+* Date : 21 octobre 2019
+* Début : 19:11
+* Fin : 21h04
+* Lieu : Salle de conférence du Pavillon des Jardins
+* <<Pad>>
+* Jitsi : https://jitsi.crans.org/IN
+
+Présents:
+
+* Solal
+* Charlie
+* Edpibu
+* Elkmaenchen
+* Hachino
+* !TinyLinux
+* 2 1A (Déso j'ai oublié vos noms).
+* Mikachu
+* Vulcain
+* Erdnaxe
+* Pollion
+* Thybal
+
+### Bilan réunion avec la DSI
+
+https://pad.crans.org/p/ReunionDsiCrans
+
+La fibre vers le G passe par l'ENS : Une fibre entre le B et l'autocom, une
+jarretière fibre, et la fibre repart vers le G.
+L'ENS doit vider tous les bâtiments d'ici fin avril, a priori y compris
+l'autocom. Il va falloir trouver une solution pour le bâtiment G.
+Ce qu'ils veulent faire c'est tirer une fibre entre l'arrivée de RENATER et le
+bâtiment De Vinci.
+Ils ont eu une réunion avec un presta pour tirer cette fibre, et
+ont /normalement/ proposé de rerouter notre fibre vers le De Vinci.
+Ce n'est pas encore clair qui va payer, on verra plus tard (avant de faire des
+travaux évidemment).
+
+Fardale s'interroge du bien fondé de tout ceci : On a notre contrat fibre
+jusqu'Ã la fin du premier trimestre 2021. Donc jusqu'Ã ce moment on paye la
+fibre. Pour l'instant on a envie de continuer à fournir le Crans, y compris au
+G (et pourquoi pas De Vinci).
+
+Quoi qu'il arrive, on veut garder internet au G.
+
+Plusieurs solutions :
+
+* Soit on fait un pont radio
+* Soit on tire une fibre dans les souterrains.
+
+La DSI est très intéressée par continuer à bosser avec nous, y compris sur
+Saclay (Pas encore défini); ils nous ont proposé une demi baie sur Saclay.
+
+Ils ont proposé de nous faire rejoindre les discussions d'un comité "Métier" en
+cours de création.
+
+Autre point : Démontage du matos de la DSI. Fin Avril, tout doit être vide, en
+particulier les bornes, switches, serveurs etc .... Et nous proposent de
+récupérer pas mal de matos (y compris les switches top of rack de la mort qui
+tue ou les serveurs Dell pas trop vieux et qui ne ressemblent pas à une
+étagère.)
+
+Ils nous ont proposé qu'on aille démonter le matos, ils vont voir avec la DAI
+pour nous filer certains accès.
+
+L'idée c'est pas forcément de garder ces bornes mais de les refiler à d'autres
+asso (Aurore, et autre ...)
+
+Charlie : Le don de matos a été promis par la DSI ou validé par la
+DGS ? --> Pour l'instant ça a juste été évoqué par la DSI, mais ils veulent se
+charger de voir tous les services (DGS, DAI etc ...) et reviennent vers nous.
+
+Vulcain : A priori ceci a été évoqué par Mazé devant Tavernier et ils avaient
+l'air chauds --> ça leur évite de signer des chèques à moult presta.
+
+Migration des IP : On se fixe en objectif de finir tout ça avant la fin de
+l'année (Civile)
+On a commencé à faire des migrations à la va vite car on a commencé à perdre
+nos routes par l'ENS le 15 Octobre, date qui avait été évoquée dans un couloir
+par la DSI à vulcain (voir le CR de la dernière IN.)
+
+### Bilan Install Party
+
+#### Le réseau
+
+On a eu un léger soucis de réseau : On avait demandé à la DSI s'ils pouvaient
+brasser toutes les prises du PDJ avec nos VLANs. Résultat, on a perdu les deux
+seules qui marchaient ....
+On a tout de même pu s'en sortir avec le wifi.
+
+~13 interfaces enregistrés pendant l'IP (sans compter ceux qui était déjà au
+Kwei)
+16 utilisateurs, 24 machines (IP + Kwei)
+Le portail captif a super bien marché, mais Mikachu a fait la remarque qu'une
+attaqueIPoverDNS était possible puisque ça n'avait pas été envisagé. On a
+testé, ça marche.
+
+#### Portail Captif
+
+Faudrait un projet d'apprenti qui reprenne le portail captif (déjà bien nettoyé
+récemment) avec :
+
+* nftables pour remplacer iptables et ipset
+* laisser passer que le 80, 443 et 53 vers la VM quand l'utilisateur n'est pas
+ register
+* mettre en place un bind9 débile avec juste une règle /#/IP LOCALE
+
+Ça sera l'occasion de revoir le portail captif d'auto enregistrement en filaire
+afin d'unifier tout ça.
+
+Erdnaxe se propose pour encadrer cette tâche.
+
+On va faire une tâche phabricator <<FootNote(Frapper WikiPollion s'il n'a pas
+indiqué la tâche phabricator ici.)>>.
+
+#### Installations
+
+Erdnaxe évoque l'idée
+d'utiliser [[https://github.com/antonym/netboot.xyz | netboot.xyz]]. Il avait
+essayé mais avait eu des problèmes. C'était potentiellement un soucis de MTU.
+De toute façon, On n'a pas envie de contacter l'extérieur ...
+
+### Bilan Séminaires
+
+Séminaires faits : Introduction au Crans, Shell, Python basique. Ça s'est bien
+passé, et les gens en redemandent !
+On a envoyé notre liste de séminaire à !ViaRézo, eux nous ont envoyé les leurs.
+Ils veulent juste que l'on ne les spamme pas trop d'apprenti (genre moins
+de 50), a priori ça passera.
+
+Prochain séminaire sera sur le réseau basique et le routage !
+
+### Pages persos
+
+phpMyAdmin a été remis au crans. On va probablement remettre en place une appli
+page perso.
+
+--> Projet apprenti https://phabricator.crans.org/T345
+
+### Conf Apache de Zamok
+
+Install-party.crans.org a été migré vers club-crans.
+
+### Point Interfaces
+
+Depuis Stretch les interfaces sont nommées à partir de leur emplacement
+physique, on a envie de normaliser de cette nomenclature.
+Erdnaxe propose d'utiliser pour cela la mécanique de systemd qui permet de
+renommer les interfaces, et de faire gérer tout ça par Ansible.
+Esum parle brièvement de la possibilité de créer des alias.
+
+##> On décide donc de nommer les interfaces ethN avec N VlanID + des alias adm,
+srv...
+
+### IPv4, IPv6, Plan d'Adressage
+
+#### Mettre des RA pour les serveurs
+
+On parle des Router Advertisement. À une époque, il semblerait qu'on avait tout
+désactivé parce que les machines sous Windows 7 pouvaient générer des faux RA
+sur le réseau.
+Maintenant, la protection mise en place sur les switchs et le fait qu'on n'ait
+presque plus de Windows 7 nous poussent à réviser cette décision et de
+simplifier la configuration de l'IPv6 des serveurs.
+
+erdnaxe propose de faire du semistatique : on fixe l'adresse IPv6 puis
+l'interface récupère tout le reste en auto comme une grande personne.
+
+Ça a déjà été mis en place sur certains serveurs, et ça marche bien. Aucun
+problème. On fait donc ça.
+
+#### IPv6 et les adhérants
+
+À l'heure actuelle, quelqu'un qui renatte derrière le crans n'a pas d'IPv6. Par
+exemple, un routeur TP-link d'un adhérent ne peut pas filer d'ipv6 (il a mois
+d'un /64).
+
+En réfléchissant à ça Mikachu s'est rendu compte que le plan d'adressage
+v4/v6 était pas fou fou.
+
+#### Plan d'adressage
+
+Mikachu nous dit qu'on ne respecte pas tout à fait les normes dans le plan
+d'addressage : Apparemment, on n'est pas censé faire comme ça pour le nat en
+IPv4 en tant que FAI.
+Il propose de plus de donner un /50 d'IPv6 aux adhérants afin de régler le
+soucis évoqué au dessus.
+
+Ok soit, pour le moment c'est pas urgent, mais on pourra l'envisager plus tard.
+
+### Monitoring
+
+Conformément à la décision de la dernière IN, le paquet prometheus qui monitore
+systemd a été installé. /!\ Il n'avait pas vu le fail de mailman.
+
+Le monitoring a pas mal été amélioré, on a droppé plein de choses
+legacy (notamment des vieux services systemd).
+
+##> https://lutim.crans.org/2fJq5s6j/8V4gXbIK.png
+
+erdnaxe a viré de la veille conf ISCSI, et avec Mikachu ils ont viré des
+gateway fantomatiques.
+
+En parlant de systemd, Mikachu parle de networking.
+
+### Ménage d'hiver
+
+Renommer vulcain => on le renomme "gateau"
+
+Virer VM cups ? civet ? (c'est pas comme si un RabbitMQ était complexe Ã
+installer…)
+Pourquoi pas, de toute façon on peut les réinstaller si besoin.
+
+Autre Ménage (synchronisation auto sur les ML à remettre entre autre ....)
+Oui on va faire ça.
+
+### Point disques
+
+Les disques de gulp sont garantis.
+Pour la baie, le CA a donné <Des SOUS>
+
+## Gâteau
+
+On a eu du gâteau. Bienvenue à Vulcain !
diff --git a/compte_rendus/2019_12_09.md b/compte_rendus/2019_12_09.md
new file mode 100644
index 0000000000000000000000000000000000000000..8ac437b4b4cb81302eab9863524fa89714050aef
--- /dev/null
+++ b/compte_rendus/2019_12_09.md
@@ -0,0 +1,254 @@
+# Réunion du Collège Technique
+
+* Date : 09 Décembre 2019
+* Début : 19:11
+* Fin :
+* Lieu : Salle de conférence du Pavillon des Jardins
+* <<Pad>>
+* Jitsi : https://jitsi.crans.org/IN
+
+Présents:
+
+* Raida
+* Hamza \o/
+* Hachino
+* Edpibu
+* Mikachu
+* Vulcain
+* Erdnaxe
+* Pollion
+* Fardale (par Jitsi, à l'aéroport, quel dévouement)
+* Solal
+* Benjamin (par Jitsi/Discord)
+* Krokmou
+* !TinyLinux
+
+## Garantie Onduleur 0B
+
+La garantie expire le 18, est-ce qu'on renouvelle ?
+
+Pollion a contacté Anne pour avoir un devis, mais pas de réponse à ce jour.
+On est tous d'accord sur le renouvellement de la garantie. Mikachu émet des
+réserves, si le prix de la garantie est trop élevé (au dessus 2k€ on commence Ã
+vraiment se poser des questions).
+
+Pollion va essayer d'appeler Anne, ça sera peut-être mieux.
+
+## State of the CRANS
+
+### Passage au module nginx pour le certificat sur bakdaur et sur Redisdead
+
+* grosse simplification de la conf, pas mal de lignes en moins
+* la pipeline pour ajouter/enlever un site n'a pas changé
+
+Erdnaxe met en garde : Ne pas trop tenter l'installateur qui est un peu
+instable, mais l'authentificateur marche.
+
+On fait la remarque que de toute façon à moyen terme on va utiliser le DNS et
+faire du certificat wildcard.
+Mikachu a fait un role ansible qui marche avec Bind pour un certif wildcard en
+challenge dns.
+https://gitlab.crans.org/paulon/ansible/blob/master/roles/nginx-reverse-proxy/tasks/main.yml
+https://gitlab.crans.org/paulon/ansible/blob/master/roles/bind/templates/named.conf.local.j2
+
+On revient sur l'idée de !DynDNS de tudor/erdnaxe. Il y a maintenant une RFC
+pour dnssec avec !DynDns.
+
+Mika dit que ce n'est pas forcément une bonne idée. Pollion est d'accord, ce
+n'est plus utile. Mention rejetée.
+
+### Panne Windows 8/8.1/10 Radius EAP
+
+* Le 07/12/2019 Ã 17h30 le cert !CaCert expire (date de 2017)
+* Génération d'un nouveau cert avec bakdaur et le domaine wifi.crans.org (qui
+ redirige vers le wiki maintenant)
+
+Il faut copier le cert sur tous les radius automatiquement (TODO) et changer la
+conf pour pointer dessus (déjà fait seulement sur radius.adm.crans.org).
+
+On a drop le WiFi sous Windows 7 avec ça... mais Windows 7 n'est plus supporté
+fin Janvier 2020.
+erdnaxe propose une upgrade gratuite vers Win10 (juste avoir la clé USB avec
+l'installer quoi) ou Ubuntu/Debian aux gens qui se plaignent.
+
+Ok, on peut même en faire la pub, on fait une décharge comme aux Install-Party.
+On propose des rdv aux gens.
+
+Oui enfin c'est long un upgrade faut avoir le temps -- Benjamin
+
+Effectivement oui, mais on décide officiellement de dropper le wifi pour
+Windows 7, et si le cableur est motivé d'upgrade. Sinon on leur dit de faire du
+filaire.
+
+Sinon on update le script pour les Windows 7 pour ajouter le certif racine de
+LE ? -- Fardale
+
+Alors oui on peut aussi upgrade le script, mais le support de windows 7 pose
+d'autres soucis.
+On peut mettre le script pour configurer les W8 et W10 mais bon, pour eux c'est
+beaucoup plus facile.
+
+https://letsencrypt.org/2019/04/15/transitioning-to-isrg-root.html
+
+### Changement du mode d'acquisition d'une ipv6 sur les machines
+
+* maintenant c'est du ipv6 semi-statique : l'ip est statique, le reste est
+ récup par un RA (dns, mtu, routeur...)
+* on s'est rendu compte que le DNS n'était pas annoncé sur le filiaire adh en
+ ipv6
+* la conf radvd a totalement été nettoyée, cf /etc/radvd.conf sur
+ ipv6-zayo (drop des trucs deprecated). On peut la rendre encore plus concise
+ en sous-entendant les prefixes avec ::/64.
+
+. On pourrait le faire avec un commentaire.
+
+* Sauf que les commentaires peuvent devenir faux avec une maj, alors que les
+ options explicites non -- Fardale
+* Oui fin si tu mets le fichier de conf à jour, tu mets aussi à jour les
+ commentaires...
+* Une maj des options par défaut par une maj du paquet
+* Bonne remarque Fardale --> On met nos options explicitement...
+
+### Problème de routage ipv6
+
+En Novembre 2019, on a eu un gros problème de routage ipv6, vers certains
+AS (par exemple vers ovh, scaleway, mais google/Facebook marchaient)
+
+On a ouvert un ticket chez zayo, mais ils nous ont fait la remarque "Chez nous
+ça marche" (ie entre un point de leur infra et nous ça marchait, entre un point
+de leur infra et les AS sus-mentionnés ça marchait).
+
+De notre côté, en faisant des tests avec !TcpDump, on voyait les paquets
+arriver, ils repartaient chez Zayo et n'arrivaient jamais à l'autre bout.
+
+On a finalement réussi à contacter le Peering Manager Europe de Zayo via
+Twitter, et c'est là qu'ils ont commencé à nous écouter.
+
+Finalement, l'OS de leur routeurs de bordures faisait n'import quoi. Ils ont
+fait une mise à jour. Maintenant ça marche.
+
+Ça a aussi permis de régler un soucis dont le Crans n'était pas au
+courant : Crans-Aurore en v4 ne marchait pas, depuis l'upgrade de Zayo ça
+marche.
+
+### Installation de prometheus sur fyre
+
+* Backup complète de fy
+* Update des firmwares avec un SPP HP de 2014 pour Gen5
+* Changement des disques avec 6*128G de HDD en RAID6
+* Installation de Buster puis provisionnement de grafana, prometheus et NinjaBot
+* Changement d'ip et de nom de fy->fyre
+* Suppression de munin-node et icinga sur tous les serveurs. Playbook Ansible
+ temporaire spécialement pour ça.
+* Suppression de pleins d'alias relatif à munin et Icinga
+
+fyre n'est plus serveur ntp ou replicat ldap
+
+Il faut peut-être virer le munin-status nginx des serveurs où il traine
+
+Le paquet prometheus-postfix est arrivé dans debian. Faudrait l'installer mais
+c'est pas encore backporté
+
+### Migrations d'ip
+
+On a pas mal avancé dans les migrations des IP ENS-->Zayo, on finit ça d'ici la
+rentrée début Janvier. A priori c'est très transparent donc cool. Les seuls
+soucis qu'on a eu c'est les ouvertures de ports dans le Parefeu qu'on a oublié.
+
+## Autorisation du protocole 6in4
+
+Mikachu propose d'autoriser le 6in4 sur les ip publiques au moins, ça
+permettrait auxadhérents de monter leur propre tunnel HE par exemple
+
+Pour les IP Natées, modulo écrire un script custom, le parefeu ne peut pas trop
+tracer à quelle IP est attribuée le tunnel.
+
+Pollion dit que si Mikachu a envie de bosser là dessus et de toucher au
+Parefeu, tant qu'il ne casse rien, go.
+
+## Retirer l'ipv6 sur adm
+
+Esum veut retirer l'ipv6 sur adm, mais bof.
+
+Du coup on peut peut-être passé sur un slash privé en fd0c::
+
+Ouais ok pourquoi pas, mais c'est pas urgent...
+
+## Devis fibre optique
+
+Il faut revoir le devis fibre de la DSI et leur en reproposer un cohérent avec
+notrebesoin, Ã savoir 0B into De Vinci
+
+On va les voir à la fin de la semaine.
+
+## vo
+
+Budget de 100€ pour vo voté par le CA pour changer des trucs dans VO.
+
+Des parties de VO sont au bout de leur vie, mais son CPU, sa CM sont bons.
+Mikachu veut juste changer le GPU et une alim à pas cher. Edpibu vend son alim,
+Mikachu a un GPU à vendre. Démerdez-vous avec le CA.
+
+On a l'alim d'edpibu pour 20 €.
+
+## Bilan des switchs 100Mb/s
+
+Combien en reste-il ? Peut-on finir de mettre le parc en Gigabit ?
+
+Il en reste 8, dont 3 au PDJ (démontés dans 3 mois ?).
+Est-ce pertinent d'investir maintenant alors qu'on ne sait pas si le CRANS
+existera encore à la rentrée ? Ca me semble pertinent de le faire, si on se
+donne pour objectif de maintenir le réseau sur Cachan au minimum jusqu'à la
+rentrée 2021.
+
+Alors oui on peut réflechir, on budgétise tout ça, on en reparle à la prochaine
+IN.
+
+## clubs.crans.org
+
+cf mail sur nounou@
+
+On move les fichiers servis dans ~/www/ ? Fusion avec perso.crans.org ?
+
+Plus personne n'utilise zamok en hébergement de sites qui pointe dessus en
+CNAME car ça a été cassé avec la centralisation HTTPS.
+
+Uniformiser c'est la vie. -- Fardale
+
+On en rediscute après le pot vieux qui est concerné par ça.
+
+## Site crans.org poussiereux
+
+Prototype rapide mkdocs https://perso.crans.org/erdnaxe/site-crans/ (juste la
+homepage et la page de connexion a été faite, mais après c'est du markdown)
+
+Pourquoi pas, si ça amuse des gens de faire du front, parlez-en en CA.
+
+!TinyLinux veut bien participer, avec Erdnaxe.
+
+> Il faut quoi qu'il arrive virer les ref à un service d'impression et
+commenter sur Windows 7 et le WiFi
+Ok
+
+### Dist-Upgrades
+
+On peut faire des DU pendant les vacances ou avant, il faut voir si des
+apprentis sont chauds pour participer. En passant sous Buster il faut faire un
+peu de Ansible.
+
+### Ansible
+
+On rappelle Ansible, cf le séminaire de la semaine dernière (Quel timing
+incroyable !)
+Lorsque l'on fait un DU, il faut migrer les confs de bcfg2 Ã Ansible.
+
+On fait la liste des trucs à faire.
+
+### Python2to3
+
+Il ne reste plus grand chose en python2, le plus gros soucis c'est freeradius.
+Les dev upstreams sont réticents à fournir un module python3. Pollion fait la
+remarque qu'il existe un rlm_rest, mais il n'est pas documenté (cf les fixme
+dans la doc). Mikachu va relire la discussion sur l'issue github, visiblement
+Pollion est out of date, depuis fin Octobre un module compatible
+python3 commence à sortir, ça mérite un test.
diff --git a/compte_rendus/2020_03_10.md b/compte_rendus/2020_03_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..3275dfeda268e8a0729635f23b2fddab41c41924
--- /dev/null
+++ b/compte_rendus/2020_03_10.md
@@ -0,0 +1,179 @@
+# Réunion du Collège Technique
+
+* Date : 10 Mars 2020
+* Début : 19:15
+* Fin : 21:18
+* Lieu : 2B
+* <<Pad>>
+* Jitsi : https://jitsi.crans.org/IN
+
+Présents:
+
+* Hachino
+* Vulcain
+* Erdnaxe
+* Pollion
+* Benjamin
+* Sarcozy
+* Ÿnerant
+* Kaj
+* Elkmaennchen
+* Charles
+* Fardale (Jitsi)
+
+## Point apprentis
+
+Il y a pas mal de nouveaux apprentis, c'est très cool. On rappelle les
+séminaires du lundi soir
+Répondez au [[ https://framadate.org/diffusionCrans | Framadate ]].
+
+Prochain séminaire la semaine prochaine probablement, ce sera un séminaire Git
+
+Problème du PdJ qui ferme 31 mars, Elkmaennchen ira voir Trouslard pour la
+Lika, il en profitera pour trouver une salle pour le Crans aussi. On envisage
+fortement d'aller sur Saclay.
+
+Pollion propose d'automatiser le forward info-dsi vers les apprentis avec
+Zentrum. <- c'est amusant comme idée, mais faut faire attention, zentrum est
+pas encore très stable, j'ai d'ailleurs vu passer encore une erreur que j'ai
+pas réussi à reproduire et j'ai supprimé par erreur le mail impliqué :(
+
+### Démémagement
+
+On lâche le PDJ le 31 Mars, mais on n'a pas de nouvelles de la part de l'ENS
+donc on va les relancer (vulcain).
+
+On a 4 switchs et une 10zaine de bornes.
+
+#### Point du bâtiment G
+
+Fibre actuelle passe par l'ENS et revient vers le G.
+La DSI nous a pas recontacter ! Il faut les relancer pour le matériel et
+démontage. Vulcain va ping Pascal :
+
+{{{
+vulcain@lui-même$ ping pascal
+No route to host
+}}}
+
+Avec le départ de l'ENS, ça va couper Internet. Pollion propose au CT de
+réaliser un pont wifi.
+
+* Vulcain propose un pont filaire <3
+ * On a les photos sur comment faire en plus
+* Solution proposée par Chirac : le CROUS a des paires de fibres non utilisées.
+ * C'est a priori une bonne idée, Pollion va contacter David Da Silva
+
+Le pont !WiFi peut faire backup. Mais problème de boucle réseau à éviter.
+
+### Avenir du CRANS 2.0 et Migration
+
+* Ce qu'on garde, et ce qu'on bouge, on en a déjà parlé, et on n'a toujours pas
+ de nouvelles de la DSI. Vulcain va les relancer.
+ * Pour rappel, la proposition se
+ trouve [[ https://pad.crans.org/p/survie_crans | ici ]].
+* WikiPollion rappelle aux apprentis l'histoire des IP ENS et des migrations.
+ * Il reste à migrer charybde vers une nouvelle ip publique. On migre aussi
+ les mirroirs en http au lieu de ftp.
+* Il faut aussi renommer tous les serveurs qui contiennent {{{.dmz.crans.org}}}.
+
+La liste des serveurs qui ont besoin d'internet se
+trouve [[ https://pad.crans.org/p/ip | sur ce pad ]].
+
+On dispose de 3 types de serveur :
+1. serveur avec une ip publique
+1. serveur avec une ip natée (qui a internet)
+1. serveur sans internet
+
+* On a fait la liste sur le pad. Pollion et Mikachu relancent Rezosup.
+* ON BRÛLE MEDIADROP avec un apprenti.
+* On ne maintient plus !LimeSurvey.
+
+On rappelle aussi qu'il reste soyouz à migrer pour enfin s'en débarasser et
+arrêter de payer les deux serveurs chez ovh : Soyouz et Sputnik. On fait le
+point sur ce qui n'est pas encore dans Ansible :
+
+* le wiki
+* la fin du DNS
+* NTP
+* Réplicat LDAP/Postgres
+* Postgres de manière générale....
+
+À vérifier.
+
+Ce qui a été mis :
+
+* Les mails sont ansiblisés
+* Wireguard
+
+Sarco est chaud pour toucher à ça, il peut demander à qui il veut, et erdnaxe
+veut brûler des choses.
+
+### Upgrade re2o
+
+erdnaxe a un fichier qui a exactement les commandes pour DU qu'il a fait sur
+re2o-test.
+Ça marche bien et ça ne prend pas plus que 20mn.
+
+Feu vert pour le migrer ce week-end (Plot twist, on n'a pas pu, c'était le
+week-end du début du confinement).
+
+{{{#!wiki caution
+Il faut upgrade toutes les instances de re2o. (sur les radius, bcfg2, et zamok
+et thot)
+}}}
+
+### DU
+
+On brûle aptdater, Ansible le remplace.
+
+#### Gulp
+
+Keepalived ansibleisé, toujours le pb des interfaces.
+On fait le point sur les trucs qui restent pour gulp, on finit d'Ansibleiser.
+
+Mais c'est pas vraiment urgent, puisque à priori gulp va devenir un
+Virtualiseur sur Saclay
+
+#### Zamok
+
+Client nfs ansibleisé, on va brûler le fstab.local, on utilise systemd-mount.
+Les paquets installés sont ansibleisés.
+Les mails sont ansibleisés.
+
+Il faut vérifier les ldap scripts (type chsh, passwd etc ...)
+
+Pour zamok, il va falloir prévoir une maintenance : Les gens vont perdre leurs
+screen.
+On peut le faire pendant les vacances scolaires (6 Avril -->)
+
+### Questions diverses
+
+* Faire quelque chose pour les gens qui lancent {{{find
+ . -name \.[A-Za-z]*}}} sur leurs mail (ce qui fait lagger zamok et zbee)
+ * On liste les gens qui utilisent ça, on leur envoie un mail pour leur
+ rappeler avec un timeout d'un mois à la fin duquel on change le script
+ comme des animaux dans leur home.
+* Backup charybde ? Est-ce que l'on ne ferait pas un ftp "données à ne pas
+ backup" et un ftp "on backup" ?
+ * Suffit de le rajouter dans les backups avec le site de backuppc.
+* Erdnaxe : Qu'est-ce qui nous oblige une MTU de 1496 ? Ça pose problème avec
+ les logiciels comme Docker auquel faut forcer 1496 Ã la place du 1500.
+ Peut-on passer sur 1500 ?
+ * Le problème était avec un vieux switch CRANS au niveau de la baie meso
+ DSI. D'après Chirac, ce switch a été démonté en 2018. On ne sait pas s'il
+ y a toujours des soucis avec l'interco DSI-CRANS qui pourrait en avoir
+ besoin, on ne sait pas ce qu'il se passerait si les switchs de la DSI et
+ leur routeur pioneer voyaient des trames de 1504 octets
+ arriver (1500 + 4 octets du tag vlan zrt 1132) au lieu de 1500.
+ * Toujours est-il que ce n'est absolument pas urgent, les gens affectés
+ savent ce qu'ils font normalement, et c'est vraiment pas le bon moment
+ pour se rajouter du boulot.
+* Erdnaxe se pose la question de mettre un split à 128 plutot que 255 dans le
+ failover DHCP (en test à Aurore).
+ * On n'a pas de charge, on verra quand on passera le dhcp sous buster avec
+ Ansible.
+* WPA perso sur le wifi avec config.properties maintenant qu'erdnaxe l'a
+ réparé. Est-ce que l'on le veut ?
+ * Erdnaxe fait des tests, on en rediscute à la prochaine IN. Mais bon ...
+ Est-ce que l'on a vraiment envie de ça ?
diff --git a/compte_rendus/2020_05_09.md b/compte_rendus/2020_05_09.md
new file mode 100644
index 0000000000000000000000000000000000000000..3e68e52ec0befd6c8b6c358e560c06bb3834d34e
--- /dev/null
+++ b/compte_rendus/2020_05_09.md
@@ -0,0 +1,282 @@
+# Réunion du Collège Technique
+
+* Date : 09 Mai 2020
+* Début : 14:07
+* Fin : 19h16 (ouais c'était un peu long)
+* Lieu : En visio
+* <<Pad>>
+* Jitsi : https://jitsi.crans.org/confINement
+
+Présents:
+
+* erdnaxe
+* Esum
+* shirenn
+* Hachino
+* Pollion
+* Vulcain
+* TinyLinux
+* Mikachu
+* Krokmou
+* Vite fait au début
+* Ÿnérant (là chez PA)
+* PAC
+* Thybal
+
+## Un jitsi scalable
+
+https://github.com/jitsi/jitsi-meet/blob/master/doc/scalable-installation.md
+
+On a augmenté la ram de Jitsi à 4G, ça a l'air de mieux tenir. On vient de se
+rendre compte que jitsi a publié un topo pour faire passer tout ça à l'echelle.
+
+« The Jitsi-Meet server will generally not have that much load (unless you have
+many) conferences going at the same time. A 4 CPU, 8 GB machine will probably
+be fine.
+The videobridges will have more load. 4 or 8 CPU with 8 GB RAM seems to be a
+good configuration. »
+
+Est-ce qu'on upgrade encore ? Est-ce qu'on tente d'avoir plusieurs videobridges?
+
+'''''Erdnaxe''''' : Java11 va probablement réparer des choses.
+
+'''''Hachino''''': - Pourquoi on a envie d'augmenter la puissance ?
+
+* On a envie de garder ce service car il est cool, et en l'état il se
+ met(tait) Ã crasher au bout d'une vingtaine de minutes.
+
+'''''TLinux''''' : Pourquoi certaines personnes n'entendent pas les autres ?
+
+* Ça fait partie des bugs qu'on a observés, et c'est potentiellement lié au
+ manque de ressources (en particulier à la RAM). On espère que ça va être fixé.
+
+'''''Mikachu''''' : Si le serveur peut pas être mis à jour vers java11 il va
+falloir trouver une solution pour pouvoir quand même mettre à jour vers Buster,
+ou alors dropper le service.
+
+On ansible-ise jitsi ? oui
+On tente un passage sous buster malgré la jvm ? oui, sur une nouvelle vm Ã
+créer pour l'occasion.
+
+'''Conclusion :'''
+
+* On va garder la vm jitsi actuelle
+* En parallèle on déploie un videobridge satellite sous buster pour tester.
+* À terme on aurait un jitsi-meet et des petits videobridges satellites.
+
+Vulcain est intéressé. Il regardera avec Pollion.
+
+## Désactiver UPNP sur les switches
+
+Erdnaxe : Si on ouvre vlc sur le campus (en filaire), on s'apperçoit qu'on peut
+voir les fichiers multimedia de certains adhérents aussi branchés en filaire.
+C'est un truc par défaut fait par Windows lorsque l'utilisateur a coché réseau
+privé.
+C'est pénible.
+
+Exemple :
+https://auro.re/_matrix/media/r0/download/auro.re/jgDmrbRwrscMqpdrnMiHayft
+
+Problème aussi des imprimantes réseaux.
+
+Attaques utilisant UPNP
+https://community.arubanetworks.com/t5/Wired-Intelligent-Edge-Campus/Switch-Configuration-To-Prevent-SSDP-Attacks-On-The-Servers-NAS/ta-p/522657
+
+On peut visiblement aussi désactiver mDNS sur les switches et ça a l'air de
+régler le soucis UPNP.
+
+erdnaxe s'occupe de regarder ça pour le switch de sa chambre et on en
+rediscutera.
+
+## Quelques points sur l'avancée du crans
+
+### Du monitoring
+
+--> Grafana + #monitoring alertes de prometheus.
+
+On monitore maintenant le dhcp avec l'exporteur mtail
+On s'est rendu compte que certaines machines qui appartenaient à des adhérents
+en manque de connexion/adhésion, mais qui ne s'étaient pas débranchées,
+continuaient à faire des requêtes dhcp mais n'obtenaient évidemment aucune ip
+et ne faisaient que flooder. Il a suffi de forcer la déconnexion de la prise
+pour ça. ---> Il faut regarder si on ne peut pas demander aux switches de
+forcer un challenge radius tous les X temps ...
+Il manque la conf radius dans mtail, ça serait bien
+On continue à déployer des nouveaux exporteurs etc ... Venez sur #monitoring.
+
+Pour
+prometheus : https://wiki.crans.org/CransTechnique/ServicesMineurs/Prometheus#Mais_dis_donc_Jamy_comment_.2BAOc-a_marche_.3F
+
+Krokmou est intéressé par regarder pour éventuellement rajouter des nouveaux
+exporteurs.
+Pollion propose de monitorer l'état des dépots git.
+
+### cranspasswords 3.0
+
+Pour l'instant c'est encore une version beta. Il reste des bugs, mais on se
+rapproche d'un truc qui marche bien. On continue de tester.
+
+### Des motds
+
+Sur les machines qu'on gère avec Ansible, on indique les services dans le motd.
+On propose de rationaliser un peu tout ça, de mettre les services en
+bas, '''APRÈS''' le dessin et de tout rendre modulaire.
+
+### Des dist-upgrade
+
+Quelle belle transition !
+
+On a pas mal avancé dans les mises à jour vers Buster. On ne lâche rien.
+Pour suivre les DU, on a la page wiki idoine
+https://wiki.crans.org/CransTechnique/AdminSyst%C3%A8me/DistUpgrade
+
+### Du ansible
+
+* Quand on DU un serveur, on le passe en même temps de BCFG2 à Ansible. On en
+ profite pour faire des raffraîchissement de la conf et virer les vieux trucs
+ legacy.
+* On déploie un header sur les fichiers gérés par ansible. Pour remplacer les
+ appels de BCFG2 à la base de donnée re2o, Pollion a développé un lookup
+ plugin dans le dépot ansible qui permet d'interroger l'API, et qui met les
+ résultats en cache afin d'accélérer tout ça. C'est en cours de relecture, et
+ ça sera mergé après.
+* https://pad.crans.org/p/ansible_todo
+* On va remplacer les lineinfile par un déploiement complet avec des
+ templates. Ça permet de savoir exactement les options qu'on veut. Si les
+ fichiers proposent des include, on garde évidemment la version des dépots
+ officiels.
+* Fusion des playbooks, utilisation des tags et import_playbook. Avec les tags
+ on peut limiter à un petit playbook.
+
+### Du wildcard
+
+On a déployé *.adm.crans.org (pour gitlab.adm.crans.org) et *.crans.org
+On pourrait mettre certbot sur toutes les VM et ne pas faire de wildcard mais
+bien un challenge DNS-01
+
+On a 4 options :
+1. On copie le wildcard du proxy partout
+1. On crée un wildcard sur chaque serveur avec un challenge DNS --> Nécessite
+la clé privée TSIG sur tous les serveurs mais pas de conf à écrire
+1. On crée un certificat nominatif par serveur avec challenge DNS --> Nécessite
+une clef privée TSIG pour _acme-challenge.nom_serveur(.adm).crans.org pour
+chaque serveur
+1. On fait du challenge HTTP --> pas possible sur adm. (enfin si mais c'est
+chiant et on a pas envie)
+
+On est tous d'accord que pour les MX on veut passer à un challenge DNS. On a un
+petit débat :
+
+* Pollion veut mettre le wildcard sur les autres services : On copie le
+ wildcard du proxy. --> Option 1)
+* Benjamin n'aime pas l'idée de rsync, 4) là où c'est posssible
+ et 2) sinon ( 2) pour les serveurs sur adm)
+* erdnaxe: vu la facilité du challenge HTTP-01 avec nginx, autant utiliser ça
+ où on peut, là où il y a déjà NGINX, sinon standalone avec le serveur dans
+ certbot
+* Mikachu: Pas trop de préférences entre 1 et 2 mis à part que 2 il n'y a pas
+ de conf à écrire.
+* Krokmou : (3, trop chiant -) 1 - 2 - 4
+* Hachino commence à comprendre, un peu. On va dire que le couplage 4-2 de Coq
+ a l'air pas mal. Mais au pire mon vote n'est pas éclairé. .-.
+* TinyLinux : cf. Hachino
+* Vulcain: plutôt 2 pour la facilité de déploiement et de maintien
+
+Finalement, on part sur l'option 2.
+
+### Bind vs knot
+
+Bind marche mieux et permet de faire des wildcard et des vues DNS mais c'est Ã
+faire. [[ https://phabricator.crans.org/T444 | Tâche Phabricator ]].
+
+* Il reste knot uniquement sur titanic et soyouz le temps de les virer
+* boeing et sputnik tourneront sous bind
+* Il faut aussi remettre en place DNSSEC
+
+### Framadate
+
+* Shirenn et Erdnaxe ont installé un nouveau serveur : ```voyager``` sur lequel
+ ils ont mis en place un Framadate. Pollion et Mikachu ont trouvé des
+ problèmes avec Postgres et PHP7.3. On propose d'arrêter d'utiliser la vieille
+ version 1.2alpha et de passer à la 1.1.10 mais cela nécessite d'utiliser
+ mysql (en local).
+* Le README/wiki est flou sur la question de la version de PHP compatible
+
+'''Que fait-on ?'''
+Shirenn teste mysql et si ça ne marche pas on brûle le service
+peut-être un framaform à venir si framadate marche bien
+
+### Divers
+
+On a DU les proxy sous buster qui ajoute le support de TLSv1.3, ça semble très
+bien marcher.
+
+## Idées
+
+Remplacer les services re2o par un nouveau dépot ansible-services, qui
+utiliserait le lookup, et des template jinja pour générer les configurations :
+alias mail
+dns
+dhcp
+firewall
+Même les switches potentiellement ? Il faudrait un connection_plugin pour
+envoyer la conf en http mais pourquoi pas
+Pas la peine, Ansible For Network Automation fournit un plugin d'Aruba nommé
+aruba_config qui applique une conf via SSH.
+Shirenn est en train de tester, on a un soucis avec les commentaires mais sinon
+ça marche
+
+Ça résoudrait le soucis des erreurs 500 sur l'API, puisqu'il n'y aurait plus
+d'invalidation de token
+Déploiement par otis (la vm qui scribe tout) régulièrement via un cron.
+
+Encore mieux, si on mettait en place du MQTT ou des webhooks :p
+
+--> Benjamin : On crée une app dans re2o avec des signaux qui envoie à un
+ serveur MQTT (sur Otis ?) les changements quand il y en a eu.
+ * On rajoute en plus une commande manage.py qui permet de faire un
+ full-regen de la conf.
+--> Mikachu soulève le problème suivant :
+ * D'une manière ou d'une autre, un service peut ne pas recevoir le message
+ et il faut qu'il puisse recevoir la conf complète à intervalles réguliers,
+ fasse un diff avec ce qu'il a, et prenne la vraie conf le cas échéans. Si
+ jamais il y a eu un diff, c'est qu'il y a eu un soucis et il envoie un
+ mail pour que les nounous regardent.
+
+C'est la commande manage.py qui est appelée à intervalles réguliers (toutes les
+heures par exemple).
+
+Conclusion:
+On va tenter un concept où nos services sont regroupés dans un unique dépot
+avec tous les scripts de regen. On utilise potentiellement des template jinja
+pour proprifier. Ils écoutent la file MQTT et appliquent leur conf.
+
+## Liste des trucs à faire
+
+On prend chaque serveur un par un dans
+https://wiki.crans.org/CransTechnique/AdminSyst%C3%A8me/DistUpgrade et on
+dresse une liste, y compris avec des gens motivés.
+
+Collegialement moins erdnaxe qui s'est barré faire du servens (oui je
+rage <3 <<FootNote(C'était pour une bonne cause, c'était pour installer Plop
+Linux pendant un temps dt -- WikiYnerant)>>) :
+
+* On utilise les host_vars, c'est très propre, et on track les trucs locaux.
+* En plus on ne se sert pas des alias interfaces.
+
+## Point déménagement
+
+Update, déménagement le 25 Mai des locaux crous par le BdE. On est d'accord que
+ça ne nous concerne pas ? On n'est effectivement pas concernés
+
+Pollion doit recontacter le Crous de Créteil, le confinement a tout de même
+retardé la chose.
+
+Le confinement a violemment bougé le calendrier, il faut voir avec la DSI pour
+tout un tas de trucs :
+La demi baie
+Le matos de récup
+Le démontage de nos bornes
+Révision du calendrier de déménagement --> Point du bâtiment G devient critique
+actuellement.
+EPF ? Autre ? Ulmites ?
diff --git a/compte_rendus/2020_07_24.md b/compte_rendus/2020_07_24.md
new file mode 100644
index 0000000000000000000000000000000000000000..676693174eba9bbfba0f47097b51c645404a073b
--- /dev/null
+++ b/compte_rendus/2020_07_24.md
@@ -0,0 +1,143 @@
+# Réunion du Collège Technique
+
+* Date : 24 Juillet 2020
+* Début : 19h15, commencé par une signing-party gpg, IN à proprement
+ parler 20h00
+* Fin : 22h30
+* Lieu : 2B + en visio
+* <<Pad>>
+* Jitsi : https://jitsi.crans.org/IN
+
+Présents:
+
+* 20-100
+* Erdnaxe
+* Esum
+* Hachino
+* Mikachu
+* Pollion
+* Shirenn
+* Solal
+
+### Un problème de clim !
+
+Devis
+Le technicien semble avoir fixé la fuite jeudi 23 juillet, après N tentatives
+de LTC.
+On a envie de changer de prestataire.
+
+### Bilan de ce qui a été fait et reste à faire
+
+#### Monitoring radius
+
+On monitore certains types de connexion radius en parsant les logs, et ça passe
+par prometheus. Il faut un peu l'améliorer, mais c'est cool.
+
+#### cpasswords 2.0
+
+Odlyd a toujours son ip ens et ça pose soucis. Le nouveau cpassword est encore
+en beta test, mais c'est cool.
+
+#### Ansible
+
+Beaucoup de choses ont été faites sur Ansible, mais il faut rationaliser la
+conf. On va écrire un !HowToAnsible <<FootNote(Si c'est un encore un lien
+cassé, tapper sur le RTC (mais avec amour <3))>> pour le crans et créer une
+convention. Attention, quand on passera à Ansible 2.10 il faudra penser Ã
+appeler les collections. ça sera dans le !HowTo.
+
+#### Framadate
+
+On a mis un framadate au crans, il marchotte, on le laisse vivre comme ça.
+Mikachu dit qu'il y a des notions cool dans phabricator pour faire des sondage
+etc. ça ferai de la pub pour nos services. Pourquoi pas.
+
+#### Postfix et dovecot
+
+On a droppé cyrus pour l'auth sasl. C'était encore en test pour l'instant,
+Pollion va le mettre dans l'Ansible et le sortir de test.
+
+#### Pad
+
+Shirenn propose de passer au nouveau thème, on verra mais pourquoi pas.
+
+### Coupure de l'ENS
+
+L'ENS est partie, quelques difficultés de communication, le G n'a pas été
+coupé (mais le RU oui) : On passe maitenant par une fibre du Crous entre le 0B
+et le 0G.
+
+Il faut finir de faire le ménage dans les ip ENS.
+
+### Récupération de matos
+
+On a récupéré N trucs de l'ENS :
+4 Arista 10 Gb 24 ports de l'infini. L'objectif est d'en utiliser que deux.
+2 Baies de disque !SuperMicro 2U (128 G de Ram). On va réutiliser de la ram
+pour les hyperviseurs.
+2 Baies 4U qu'on va laisser de côté pour l'instant.
+Chacune des baies venait avec des carte 10G
+
+Et une palanquée de disques.
+https://pad.iiv.re/p/survie_crans
+
+C'est super cool. Ça va nous permettre d'upgrade vraiment l'infra :D !! (Voir
+point suivant).
+
+### Future infra
+
+On va jeter les vieux serveurs qui servent de chauffage.
+
+Mikachu fait une présentation globale de la POC de la nouvelle infra
+actuellement en test au 2B depuis
+
+Regarder : Est-ce que l'on peut mettre des nice-levels dans le Proxmox pour
+éviter de surcharger les VM de routage ?
+
+20-100 indique qu'en cas de keepalived sur des vms, le firewall datacenter de
+Proxmox 6 considère certains paquets comme invalides et ça fout la merde + très
+difficile à débuguer .... Il a rencontré ça au taf ...
+Idée : mettre radvb sur les 3 VMs de routage sans keepalived et avec des
+métriques différentes pour le routage ipv6.
+
+#### Projet de LDAP nounous
+
+Esum présente le LDAP nounous :
+
+* envie de cacher les hosts
+* passwd hash de façon faible, on va utiliser un script
+* on conseille ldapvi
+* on peut se loger en tant que soi avec les bons droits
+* log en LDIF
+
+Esum présente aussi le routage et le plan d'adressage. On se pose la question
+de regrouper le wifi et filaire. À part pour la TV on ne voit pas de contre
+indication. On va faire le test, mais dans l'optique de tout simplifier ça nous
+semble une bonne idée.
+
+### Virer les vieux switches 100M
+
+On va faire la liste et voir pour changer ces switchs avec le matos. Il serait
+intéressant d'avoir le campus en Gigabit.
+
+### Configuration des switches
+
+Erdnaxe et Shirenn ont regardé comment automatiser la configuration des
+switches. L'idée était au début d'utiliser Ansible, mais en fait c'est l'Enfer.
+On va réécrire un script tout joli et tout propre. Erdnaxe propose de mettre en
+place LLDP, c'est pratique pour débugguer. Pourquoi pas ?
+
+### Cloud-Init Proxmox
+
+Cloud-init est une techno qui vient d'!OpenStack qui permet à un provider cloud
+pour monter un truc en même temps que la vm pour la provisionner. C'est très
+pratique et ça a fait ses fruits. On fera un script pour automatiser la
+création de vm ! Problème c'est long à booter et on veut pas que les gens
+fassent de la merde non versionnée. On propose de supprimer le paquet
+cloud-init après l'installation pour éviter ça.
+
+https://wiki.crans.org/CransTechnique/Services/Virtualisation/CreerUneVM
+
+### Gateau
+
+Shirenn est nommé nounou, bravo à lui !
diff --git a/compte_rendus/2020_12_21.md b/compte_rendus/2020_12_21.md
new file mode 100644
index 0000000000000000000000000000000000000000..c9e718b0b1e381b2af7d04f6d24c1804ce8c776c
--- /dev/null
+++ b/compte_rendus/2020_12_21.md
@@ -0,0 +1,142 @@
+# Réunion du Collège Technique
+
+* Date : 21 décembre 2020
+* Début : 17:17
+* Fin : 18h58
+* Lieu : En visio et à la Kolok
+* <<Pad>>
+* Jitsi : https://jitsi.crans.org/Lundi21Decembre2020
+
+Présents:
+
+* erdnaxe
+* shirenn
+* PAC
+* Pollion
+* Mikachu
+* Solal
+* Ÿnerant
+* esum
+
+On a un peu avancé, mais c'est vrai que les confinements ne nous ont pas trop
+fait de cadeau.
+
+### Planification de la migration
+
+#### Mise en place des vms de routage
+
+* Pare-feu (nftables) --> Le parefeu marche. Il faut faire la migration de re2o
+ ou mettre une patte à re2o sur la nouvelle infra.
+
+Pour faciliter la migration, on va commencer par mettre une patte à re2o sur la
+nouvelle infra, et on va commencer par migrer les machines avec ip publique.
+Il faut passer sur master sur le script de génération du parefeu, afin de
+parler à re2o, et rajouter une ligne pour le hack sur la proxy ARP.
+Il faut aussi mettre en place rsyslog. On discute de où on met les logs.
+On va les mettre sur tealc dans une pool /pool/logs.
+Il faut donc adapter le role rsyslogd et logrotate.
+
+* La question de l'ipv6, comment ça marche actuellement sur la nouvelle
+ infra (@Esum)
+
+tout marche bien c'est cool. Il y a juste un bridge entre ipv6-zayo et
+routeur-sam, avec un vlan spécifique pour l'interco. Mais c'est du hack
+temporaire, ça sautera à la fin de la migration.
+
+#### radius
+
+Le radius marche, il faut juste mettre en place rsyslog.
+
+#### dhcp
+
+Il est en place, on vérifie quand même que ça marche, mais de mémoire cet été
+c'était le cas. Il faut juste faire attention à ne pas utiliser dhcp-failover
+car ça ne supporte que 2 serveurs et nous on en veut 3.
+
+#### dns recursif
+
+Ok
+dns autoritaire https://gitlab.crans.org/nounous/dns
+Parfait
+
+#### Migration des dernières vm
+
+* IRC --> On propose de DU zamok vers bullseye, comme ça on aura un serveur des
+ adhérents à jour et erdnaxe sera content.
+* Rezosup (@Mika et @Esum) --> Ils vont migrer cette vm bientôt, et ça ira très
+ bien.
+* Bde et Gala (@Pollion, @nanaxe et @Vulcain) --> Gala c'est fait, il faudra
+ juste rechanger l'interface quand on aura migré les IP publiques adhérents.
+ Pour le Bde, bah Pollion a laissé jusqu'au 26 décembre au BdE pour faire
+ quelque chose de cette VM. Pac et Ynerant s'en occupent. On propose d'offrir
+ un dump de la vm note sur une clé usb crans à 20-100.
+* Matrix-eea (@nanaxe, @PAC) --> erdnaxe la brule mais avant : backup !
+* Redisdead, owncloud, owl --> redisdead change d'infra mais garde une pate sur
+ l'ancienne. Profiter de l'Interruption de Service ou alors commencer par
+ finir d'installer sputnik.
+ * Mikachu veut se taper une chouette ce soir.
+ * Pour owncloud et owl, on peut les installer sur une vm sur la nouvelle
+ infra et faire des tests avec Cameron (la baie des homes), en écrivant un
+ role pour owl, car c'est pas encore fait. Mais il faut attendre la
+ migration finale pour passer ça en prod.
+* Sauvegarder tout le reste (dans une pool sur Zephir ?)
+ * On va faire une pool cimetière. RIP les vieilles vms.
+
+#### Migration de zamok
+
+On va le DU vers bullseye.
+On va rajouter des disques dans Zamok dans l'objectif d'héberger des petites
+images podman, pour un futur projet.
+
+### Plan de la migration
+
+1. Migration des home:
+Il faut prévoir une interruption de services.
+Il faut :
+
+* Être certain que les services qui parlent aux home tournent : En gros
+ owncloud et owl, + le nouveau serveur irc.
+* DU Zamok vers bullseye.
+* Refaire un rsync des home, mais ça devrait aller assez vite.
+* Et finir de setup le nfs sur zamok.
+
+2. Migration du réseau.
+
+* Il faut migrer les switches. Ça veut globalement dire appliquer le script le
+ Mikachu.
+* Il faut migrer les bornes. Pollion et Esum ont fait des tests pour migrer une
+ borne [[ https://wiki.crans.org/CransTechnique/ControleurUnifi#Changement_de_controleur | c'est facile ]].
+
+En bonus, on a testé avec un controlleur unifi sur buster.
+
+Par contre ce qu'on dit c'est que cette migration sera faite dans un second
+temps.
+
+#### Choix des dates
+
+1. Migration des home, lundi 28 Décembre.
+1. Migration du réseau le week-end du 2/3 janvier.
+
+### Post-Migration
+
+#### Nettoyage de Vo et caillassage des serveurs
+
+Backup des trucs qui trainent et stockage.
+
+#### Après la migration, la DOC et ansible
+
+Ce serait pas mal qu'à un moment après la migration, on puisse run ansible sans
+rien cassé
+Écrire toute la doc et archiver la doc de l'ancienne infra
+
+#### Chiffrement des disques
+
+On en reparle plus tard, mais il va falloir un autre rsync pour chiffrer la
+pool ZFS sur cameron. Pour les backups, c'est fait avec borg.
+
+### GATEAU !!!!
+
+1. Le CT s'agrandit, avec l'arrivée de PAC. Bravo à lui !
+1. Ce n'est pas encore tout à fait officiel (je ne veux pas laisser un crans
+instable), mais Pollion va rendre les rênes du CT et shirenn a accepté de
+reprendre cette charge. Merci à lui et bonne chance !
diff --git a/compte_rendus/2021_02_16.md b/compte_rendus/2021_02_16.md
new file mode 100644
index 0000000000000000000000000000000000000000..d834f90bc8f1552cc739397f9c1bc989a35db5ea
--- /dev/null
+++ b/compte_rendus/2021_02_16.md
@@ -0,0 +1,176 @@
+# Réunion IN
+
+## Réunion du Collège Technique
+
+* Date : 16 Février 2021
+* Début : 20h15
+* Fin : 23h15
+* Lieu : Partout
+* <<Pad>>
+* Jitsi : https://jitsi.crans.org/IN
+
+Présents:
+
+* Esum
+* Ÿnerant
+* shirenn
+* Pollion
+* Vanille
+* PAC
+* Nicomarg
+* Sarcozy
+* TinyLinux
+* Mikachu
+* Sun
+* erdnaxe
+* Solal
+
+### Accueil des nouveaux amis
+
+Bonjour les nouveaux amis. Le Crans c'est cool. Mangez-en --> Les
+nouveaux ? ---> Ouiiii. shirenn et Ÿnerant ont fait une présentation de l'infra
+aux nouveaux. C'est cool. Et ils sont motivés !
+
+### News, Jabber, TV
+
+#### Jabber - (aka xmpp)
+
+Globalement personne ne s'en sert, ou presque, et surtout le Crans ne peut/veut
+plus le maintenir. Il est backuppé, donc s'il le faut il peut être rallumé et
+les données ne sont pas perdues.
+
+#### News
+
+Avis beaucoup plus mitigé, Pollion estime que l'historique des news apporte un
+regard sur l'histoire moderne de Cachan. La vm est éteinte pour l'instant car
+elle n'a jamais été mise à jour depuis Jessie. Un projet un jour, les mettre en
+statique quelque part ? Remettre en place un autre
+webnews ? https://gitlab.crans.org/nounous/django-webnews. Esum: Le protocole
+est mort de toute façon ....
+
+#### TV
+
+On a abandonné la TV en multicast, on a laissé la TV en unicast. C'était un
+projet cool, mais dans l'optique où on veut laisser le Campus à l'EPF (et oui,
+on a des repreneurs !!), on n'a pas spécialement envie de laisser tourner une
+mine (ou une ferme). En plus ça n'a plus beaucoup d'intérêt à l'heure où la
+plupart des chaînes diffusent en direct sur leur page web. On va arrêter d'en
+faire la pub, et à terme l'arrêter.
+
+### Bilan de la migration
+
+On a viré les 20 ans d'empilement de scotch au Crans. L'idée qui semble assez
+réussie était de simplifier au maximum l'infra, et on a des repreneurs !! (oui,
+je me répète mais c'est cool). On va espérer que le Crans survive. Il reste
+encore un soucis reporté par les utilisateurs de PS4. C'est vraiment très
+bizarre et on n'a pas vraiment d'idée sur comment régler ça...
+
+Il faut vraiment terminer de configurer les routeurs de backups parce que lÃ
+c'est pas fait. Keepalive pas encore fini de gérer. TODO !!
+
+Il ne reste plus que le Backbone à remplacer par le deuxième Arista, mais le
+couvre feu nous avait mis des bâtons dans les roues pour terminer la
+maintenance.
+
+Update: Fait le Lundi 22 Février 2021
+
+### Backups
+
+On pose la question de savoir par quel VLAN on fait passer les backups: Adm ou
+directement SAN ? On décide de laisser SAN confiné au 0B et de continuer sur
+ADM. On discute de backups offsite. On envisage Aurore et/ou Sputnik, mais pour
+le moment Sputnik est down depuis ce matin ....
+
+### Convention pour les interfaces (interfaces.d, yay or nay ?)
+
+On discute d'une convention pour la configuration des interfaces et du réseau.
+Pollion, Esum et shirenn sont pour garder la séparation des interfaces dans
+interfaces.d. Mikachu dit qu'il aime bien un fichier monolithique qui contient
+tout. On vote, on garde interfaces.d
+
+### Bornes wifi qui arrivent en fin de vie.
+
+https://community.ui.com/questions/Select-UniFi-Access-Point-AP-Models-Obsoletion-Date-March-1-2021/65487283-ce9d-49f4-85b9-b6aa54659ef7
+
+Le controlleur se plaint qu'il y a des bornes qui deviennent EOL. On ne pourra
+pas mà j le controlleur après le 1er Mars. Elles ne seront plus configurables.
+On propose de garder le changement de bornes sous le coude pour introduire les
+EPF dans le monde du FAI associatif.
+
+### Vieux Switches 100M
+
+Même chose qu'au dessus, on en fait un projet EPF.
+
+### Windows 7
+
+Pollion propose de virer le support TLS <1.2 des RADIUS ce qui aurait pour
+conséquence de dropper le support de Windows 7. Benjamin est pour. On fait un
+encart plus visible sur la page du Crans, et on invite les gens à passer sous
+Windows 10. Ceux qui ont encore Bref, on est tous d'accord.
+
+### Pass
+
+On souhaite avoir un logiciel un peu plus mature. On reste temporairement
+sur !CransPasswords (avec le serveur de esum). erdnaxe va debug reencrypt avec
+Pollion sur pass-group.
+
+### Ansible
+
+#### Header
+
+Shirenn n'est pas content du header qui change tout le temps. Benjamin a trouvé
+un compromis: Le header ne va changer que si le fichier en question est
+modifié. Pollion trouve ça cool ce nouveau fonctionnement. shirenn est toujours
+pas trop content du résultat, mais finalement on accepte le nouveau header.
+
+#### Playbook All
+
+On décider de remplacer le playbook {{{all.yml}}} par un script bash qui va
+lancer ansible en check_mode sur tous les serveurs. On est tous pour.
+
+#### Fichiers statiques
+
+Les fichiers statiques sont partouts, on va faire des symlinks, et les
+regrouper en un seul endroit.
+
+#### Branche
+
+Ça fait un an que notre ansible tourne dans la branche newinfra. Maintenant que
+la migration est terminée on va renommer en master (Après les MR).
+
+#### Action_plugins
+
+Erdnaxe propose de déplacer les action_plugin dans les roles. Mais on a des
+trucs relativement génériques, sauf l'action plugin du wiki, mais bon .... On
+décide de garder à la racine.
+
+#### Port Forwarding
+
+Le LDAP CT n'écoute qu'en local sur tealc. On doit faire du port forwarding
+pour s'y connecter. C'est nécessaire pour certains playbooks
+comme {{{root.yml}}}. Erdnaxe propose d'automatiser de faire le port forwarding
+pour le ldap au moment de lancer Ansible. Il va regarder comment faire.
+
+#### Inventaire
+
+Erdnaxe propose d'utiliser le LDAP comme inventaire ... Mais bon ça ne sert Ã
+rien car on a de toute façon les host_vars. On décide de garder le
+fonctionnement actuel.
+
+### Nginx et Gitlab
+
+Ynerant propose d'utiliser le nginx du paquet omnibus de Gitlab et de mettre un
+nginx tout simple sur Gitlab pour gérer les multi
+domaines ({{{gitlab.crans.org}}} et {{{gitlab.adm.crans.org}}}). L'idée est de
+simplifier au maximum le nginx et pouvoir utiliser le rôle générique qui est en
+cours d'écriture, et laisser Gitlab gérer sa merde.
+
+### Être nounou, de la légitimité au savoir faire.
+
+Idée : séparation CT/ancien CT, avec mandat de 4 ans dans le
+CT "jeunes" (ie 4 ans nounou). Hachino se colle à la rédaction en express avant
+l'AG.
+
+### Gateau, mais chacun chez soi
+
+Bravo à Ÿnérant ! \o/
diff --git a/compte_rendus/2021_03_20.md b/compte_rendus/2021_03_20.md
new file mode 100644
index 0000000000000000000000000000000000000000..dcffbda4c48217510d8beee9d2cc8fd087e9ec32
--- /dev/null
+++ b/compte_rendus/2021_03_20.md
@@ -0,0 +1,140 @@
+# Réunion du Conseil Technique
+
+Lieu: https://jitsi.crans.org/IN
+
+Date: Samedi 20 Mars 2021
+
+Présent:
+
+* Ynérant
+* ds-ac
+* Ifugao
+* Esum
+* Sarcozy
+* Solal
+* nanaxe
+* Vanille
+* shirenn
+* Pollion
+* Hachino
+
+Ordre du jour :
+
+* Mailman3 : Est-ce-qu'on migre et si oui, quand / comment ?
+* On abordera aussi le BL de free
+* Petit point sur les services qu'on a mis en place récemment ou qu'on souhaite
+ mettre en place dans le futur ? (framadate, hedgedoc, bbb, linx, belenios,
+ galene, tmpad, nitter)
+* Weechat créée des processus zombies qui peut à terme empécher les
+ utilisateurs à se connecter sur zamok
+* Déménagement : Comment migrer quoi et comment ? Comment maintenir avec le
+ materiel minimal l'infra à Cachan ?
+* !AutoPerso : discussion sur l'hébèrgement des pages persos sur zamok
+* !AutoBackup : backuper séparement les données des différents utilisateurs
+* Script de création de VMs : quelques améliorations
+
+## Mise au point sur les services
+
+Les nouveaux services :
+
+* Framadate (maintenable, à peu près dev par Framasoft) : Il faut fixer la
+ backup de la base de données MySQL avec Borg et le mot de passe administrateur
+* !HedgeDoc : Bug du conteneur qui restart en boucle si la base PostgreSQL est
+ non contactable.
+ On aimerait la regrouper sur kenobi.
+* !BigBlueButton : on drop, trop lourd et douloureux à maintenir
+* Galène : On veut associer un compte ldap à des salles de visio-conférence.
+ Patch dans Galène pour garder l'ordre des gens. Bug de son lors du partage
+ vidéo webm. Pour le support de l'OBS on s'en tape pour le moment.
+ On est très positif, erdnaxe pourra potentiellement faire un séminaire. ds-ac
+ est potentiellement intéressé pour bosser sur Galène avec nanaxe. On ne
+ l'annonce pas aux adh, c'est surtout pour du test pour le moment.
+* linx : On pourrait augmenter la persistence à 1 mois.
+ Client linx avec curl pour automatiser l'upload du presse-papier, des
+ screenshots...
+ On garde et on le maintient.
+* tmp-etherpad : les pads sont persistants par défaut, on retrouve ainsi des
+ antiquités. tmpad.crans.org est en place, ça marche.
+ Page qui propose entre les 2 instances sur la page d'accueil.
+ Proposition : texte blanc sur la popup verte.
+* belenios : Installé proprement, on souhaite garder.
+ On souhaite documenter pour réaliser une élection.
+ [[CransTechnique/ServicesMineurs/Belenios#Utilisation]]
+ Un admin ne peut pas supprimer un vote car il y a un tallycounter chiffré.
+
+Les services que l'on droppe :
+
+* La TV (cochon)
+* Invidious, Bibliogram, Nitter, Searx : On n'en veut pas ou on drop.
+ Controverse vis-Ã -vis de l'objectif du Crans. Il ressort que l'on a envie de
+ converger vers un fournisseur cloud plutôt que de logiciels tel que Nitter.
+
+## AutoPerso
+
+Par défaut on met du Apache2 + PHP pour rétrocompatible
+
+On crée une VM de test sur lequel on a un NGINX qui forward vers des .socket
+par user.
+
+On veut que ça soit passable.
+
+## Mailman3
+
+Mailman3 par rapport à Mailman2 :
+
+* L'interface web est plus utilisable, il y a de vrais comptes.
+* Hypperkitty est exploitable et lisible.
+
+Il faut modérer les mails avant la migration.
+La migration prend entre 2-3h pour les listes, et les archives 2-3 jours.
+
+Il faut envoyer un mail à *-owner@lists.crans.org
+
+Certaines ML n'ont pas d'admin ni de modérateurs. On fait au cas par cas.
+
+Proposition de solution pour la non-modération :
+
+* si mail reste en modération pendant 6 mois, on envoie
+ aux -owner@lists.crans.org et on supprime.
+* en plus on ajoute "si vous voulez gardez votre ML, vous avez N mois pour nous
+ répondre"
+* on envoie un mail la dernière semaine avant de supprimer à la liste
+
+Convention de
+nommage : [[https://wiki.crans.org/CransTechnique/ConventionsUtiles/NomsML]].
+On passe les noms de ML en lowercase
+
+On aimerait avoir 2 MX et 2 SMTP (la sortie) bien séparés. Ainsi si on se fait
+blacklisté par les listes de diffusion on ne casse pas les courriers normaux.
+
+Il faut vérifier abuse, trouble, postmaster@ redirige vers root@
+
+Date de la migration : nuit du 11 avril au 12 avril
+
+## Mail vers les adhérents
+
+On ne fait rien pour HaveIBeenPwned, mais dans un mailall où on indique les
+services que l'on arrête on rappelera qu'il faut changer son mot de passe.
+
+Il faut aussi faire un mail propre et concis disant seulement que l'on arrête
+Internet pour les gens sur campus. (+ des affiches ?)
+
+## Weechat
+
+On a potentiellement un mauvais script qui tue weechat.
+On invite les utilisateurs de Weechat de comparer leurs scripts.
+
+ps -aux | grep weechat | awk '{print $1}' | sort | uniq -c | sort -n
+
+## Nounou à la retraite
+
+Blupon, Bernie, Detraz et Grizzly ne veulent plus être nounou.
+
+Certaines autres nounous souhaitent d'être mis à jour sur l'infra. On attend le
+déménagement à Saclay.
+
+## Début du déménagement à Saclay
+
+On commence à réfléchir mais on pense laisser Gulp à Cachan pour le routage
+pendant le déménagement du cluster.
+On mettra sur Gulp : Controleur Unifi, routage, re2o, wireguard (?).
diff --git a/compte_rendus/2021_04_24.md b/compte_rendus/2021_04_24.md
new file mode 100644
index 0000000000000000000000000000000000000000..997dfa3b1442270fb03f4987a1d90f438d7ad0ed
--- /dev/null
+++ b/compte_rendus/2021_04_24.md
@@ -0,0 +1,131 @@
+# Réunion du Collège Technique
+
+* Date : Samedi 24 Avril 2021
+* Lieu : https://galene.crans.org/group/IN
+* Début : 15h00
+* Fin : 17h15
+* https://pad.crans.org/p/Samedi24Avril2021
+
+## Présents
+
+* shirenn
+* ynerant
+* esum
+* erdnaxe (sporadiquement)
+* solal
+* vanille
+* ds-ac
+* ifugao
+
+## Compte Rendu
+
+### Déménagement à Saclay − Scission de l'infrastructure
+
+#### Cachan − Installation de gulp
+
+Gulp est le denier serveur du crans qui restera à Cachan, il va devoir assurer
+l'accès à internet de tout le campus à lui tout seul. On va commencer par
+installer à blanc tout ce qui est nécessaire pour le routage et on fera ensuite
+la migration peu à peu (on peut se permettre de la faire switch à switch ce qui
+évitera une coupure globale). On a fait le choix de garder l'instance de re2o Ã
+Cachan sur toute la fin de la migration et sa bdd sera garder en local à même
+sur l'hyperviseur. On détaille ensuite l'ensemble des taches à faire pour
+configurer le serveur :
+
+* Installation de PostGreSQL et migration de la base de données re2o (shirenn)
+* Installation d'une vm de routage :
+ * Installation du pare-feu et du nat (ds-ac encadré par esum)
+ * Installation du radius (vanille encadré par ynerant)
+ * Installation du dhcp et ra (ifugao encadré par shirenn)
+ * Installation du dns recursif (solal)
+ * Installation d'un pair BGP (ds-ac encadré par shirenn)
+* Installation d'une vm re2o et du ldap associé (shirenn, please send help
+ Pollion)
+* Installation d'un controlleur unifi (solal encadré par ÿnérant)
+
+On effectuera ensuite une première migration pour basculer le routage de toute
+l'infra derrière gulp en faisant du BGP entre routeur-{sam,daniel,jack} et gulp
+et une autre session BGP entre gulp et zayo.
+
+Puis on pourra migrer switch par switch l'infrastructure vers gulp.
+
+#### Saclay − Odlyd
+
+ds-ac va installer Odlyd avec ÿnérant sous proxmox pour pouvoir faire des tests
+avec Aurore et Via d'échanges de routes.
+
+#### Saclay − Déménagement du reste de l'infrastructure
+
+Camion, tchou tchou, et normalement, il n'y a rien à configurer à part changer
+l'ip de pair de la session BGP.
+
+##### Les blabla d'un vieux
+
+Mikachu conseille pour les alim électriques de choisir deux couleurs de cables,
+une pour la voie ondulée et une pour la voie non ondulée
+Mikachu conseille aussi d'acheter des cables ethernet et/ou des fibres de
+couleurs permettant de les distinguer
+
+#### Achats de matériel pour le déménagement
+
+Le CT propose l'achat de materiel suivant au CA :
+
+* Un mail a été envoyé à la DSI de l'ens et de paris-saclay pour voir ce qu'il
+ faut acheter en terme de sfp + fibre
+* On voudrait en plus acheter quelques paires de sfp 10G pour pouvoir être large
+* Le cluster actuel est un peu limité en ram, on voudrait acheter quelques
+ barettes de RAM pour pallier à ce problème : 12*16GiB
+
+### Discussion sur la documentation
+
+La documentation est actuellement un peu en fouillis. Il y a des élèments
+manquants et des choses plus du tout à jour. On voudrait aussi déplacer la
+documentation technique sur un wiki à part. On propose de commencer pour le
+moment par s'abstraire de l'engine qu'on va utiliser au profit d'un répot git
+avec des fichiers markdowns. On réfléchira ensuite à comment le mettre en forme.
+
+Un des principaux objectifs de cette nouvelle documentation est de bien
+segmenter la différence entre les idées (protocoles, etc …) et les
+implémentations (logiciels). Un autre point sur lequel on veut insister et
+l'importance de certains services par rapport à d'autres. Certains dont on veut
+assurer la pérénité par rapport à d'autres qui seraient moins important. À ces
+fins, on propose de restructurer la doc de la manière suivante :
+
+* Outils :
+ * Dans cette section, on rassemble tous les outils utilisés et les
+ descriptions de certains protocoles utilisés
+ * Exemple d'outils : TLS, APT, debian, rsync, ssh, …
+ * Exemple de connaissances : IP, Firewall, NAT, DHCP, …
+ * Mais aussi quelques trucs et astuces de techniciens :
+ * Acheter un disque
+* Infrastructure :
+ * Ici on décrit l'infrastructure dans sa globalité, pour faire simple ce que
+ le Cr@ns met à disposition du Cr@ns.
+ * Par exemple: LDAP administration, NFS, Plan IP & VLAN, matériel technique,
+ Postgresql
+* Services Critiques : ce qui ne doit pas être discontinué et avoir l'uptime le
+ plus élevé possible. On a établi une liste exhaustive :
+ * Réseaux (pare feu & NAT)
+ * Mail (serveur imap & smtp, webmail, mailman (+CAS))
+ * Gitlab
+ * Owncloud
+ * pad
+ * wiki technique (actuellement sur kiwi tant qu'on a pas migré)
+ * zamok (pages perso, etc …)
+ * IRC
+* Services Mineurs : Tout le reste
+ * Linx
+ * Framadate
+ * Tracker
+ * …
+
+### Retour sur la Migration de Mailman 3
+
+Actuellement, les mails de rappels de modérations sont envoyés
+par {{{nounou[AT]lists.crans.org}}} alors qu'avant les mails venaient
+de {{{${ml}-bounces[AT]lists.crans.org}}}. C'est un comportement qu'on
+souhaiterait conserver, ynerant va investiguer. Et sinon les mails de
+verification d'adresse mail sont envoyé
+depuis {{{nounou[AT]lists.crans.org}}} comme c'était le cas avant et on s'est
+demandé si on ne préfèrerait pas qu'il provienne
+de {{{noreply[AT]lists.crans.org}}}.
diff --git a/compte_rendus/2021_12_17.md b/compte_rendus/2021_12_17.md
new file mode 100644
index 0000000000000000000000000000000000000000..29cab1e60f761b84d8bdf2e4db3456a1c8c835b1
--- /dev/null
+++ b/compte_rendus/2021_12_17.md
@@ -0,0 +1,88 @@
+# Réunion du Collège Technique
+
+* Date : Vendredi 17 Décembre 2021
+* Lieu : Galène (https://galene.crans.org/group/CA) et MB84
+* Début : 20h04
+* Fin : 21:22
+* https://pad.crans.org/p/Vendredi17Decembre2021
+
+## Présents
+
+* [[WikiYnerant|Ÿnérant]]
+* [[VanilleNiven|Vanille]]
+* [[WikiShirenn|shirenn]]
+* [[SolalNathan|Solal]]
+* [[Benjamin|Esum]]
+* [[DsAc|ds-ac]]
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+
+## Ordre du jour
+
+### Réseau
+
+* Federez utilisent '''17''' IP publiques de notre réseau. Sans
+ doute 8 seraient suffisantes ?
+
+On va les contacter pour réduire leur consommation.
+
+* Un peu trop de switch sur le vlan 11. On supprime le vlan 11 et on les
+ déplace sur adm.
+
+### Bind/Unbound
+
+Arnaud a installé unbound mais n'a pas encore fait des tests de comparaison
+avec bind.
+
+### Constellation
+
+Que veut-on que constellation fasse ?
+
+* Gérer les adhésions
+* Gérer les alias mail
+* Acheter des trucs
+* Exporter un LDAP
+
+Qu'est-ce qu'on veut importer
+
+* Les adhérents et leurs infos
+* Les factures : exporter les factures en pdf
+* Les alias mail
+* Les whitelists/blacklists
+
+### Machines virtuelles des adhérents
+
+Tout a été fait il faut communiquer aux adhérents et aux clubs.
+
+### SPAM
+
+* Comment ça s'est produit : un mdp a leak, un spammeur l'a récupéré
+* Failles :
+ * Horde refuse d'utiliser submission, ignore les ports, et est difficile Ã
+ configurer.
+ Allons-nous brûler Horde ?
+ * Re2o ne flush pas les comptes donc on ne peut que difficilement lock un
+ compte en urgence
+* Mitigation :
+ * Outlook nous a enfin déban
+* Sécurité :
+ * tous les mails doivent être envoyés via submission pour qu'une rate limit
+ soit implémentée
+ * authentification renforcée pour envoi de messages est implémentée et sera
+ mise au point à la rentrée
+
+### Impression
+
+L'administration n'a pas l'air au courant qu'on va proposer de l'impression.
+Imprimante achetée avec succès. Quelques tests faits, un frontend implémenté
+pour faire des commandes.
+Feature pour rendre les impressions plus secure : au moment de la commande,
+choisir un code à 6 chiffres et le taper pour lancer l'impression.
+Bientôt: tests de LDAP puis configuration de l'imprimante
+
+Discuter des modalités de payement avec le BDE.
+
+### DSI
+
+Routeur 2754 : on va contacter la DSI par DT, attention à la procédure qui a
+changé récemment.
+Serveurs : demande de deuxième accès électrique.
diff --git a/compte_rendus/2022_04_16.md b/compte_rendus/2022_04_16.md
new file mode 100644
index 0000000000000000000000000000000000000000..763fbd1005f1f0455fff4856fcdf4b190f36103e
--- /dev/null
+++ b/compte_rendus/2022_04_16.md
@@ -0,0 +1,106 @@
+# Réunion Inter Nounous
+
+* Date : Samedi 16 Avril 2022
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
+* Début : 20h03
+* Fin : 21h43
+
+## Présents
+
+* Vanille
+* bleizi
+* esum
+* Pigeon Moelleux
+* Ÿnérant
+* shirenn
+* ds-ac
+* Otthorn
+
+## Ordre du Jour
+
+* Suppression du domaine crans.ens-cachan.fr
+* Mise en place des serveurs radius à Saclay
+* Retour sur le déploiement d'OpenDMARC
+* Point sur l'avancée du projet de backups
+* Petite avalanche d'acronyme pour discuter des problèmes liés à ZFS
+
+### crans.ens-cachan.fr
+
+Avec le décomissionnement progressif du nom de domaine ens-cachan.fr, la DSI a
+supprimé la zone crans.ens-cachan.fr qui nous était délégué. Celle-ci était de
+notre côté configuré pour se comporter comme un DNAME de crans.org et nous en
+avions de manière générale peut fait la promotion au cours des années. Sa
+suppression est donc sans grande incidence. Elle ne devrait créer qu'un petit
+nombre de liens morts rapidement réparable en substituant à crans.ens-cachan.fr
+la zone vers lequel le DNAME pointait (ici crans.org). On peut cependant noter
+que certains anciens, conscient de l'existence de ce DNAME avait décidé de
+l'utiliser dans leurs adresses mails. Il n'y a malheureusement pas grand chose
+que l'on puisse faire à ce propos.
+
+### Radius à Saclay
+
+#### Radius Federez
+
+Depuis le départ de Cachan, le crans n'exporte plus de serveur radius. Celui-ci
+permettait aux gens bénéficiant d'une connexion internet sur le campus de
+Cachan de pouvoir se connecter à internet sur les campus du réseau Federez. De
+plus le crans ne vendant plus à proprement parler de connexions internet à ces
+adhérents la question s'est posée de savoir,
+1. S'il était encore pertinent d'avoir un serveur Radius ?
+2. Si oui, qui devrions nous exporter dans celui-là ?
+
+Un point important sur ces deux questions est le suivant, les gens qui par
+notre politique d'exportation se retrouveront dans le serveur radius, auront de
+fait accès à internet dans les résidences du campus (en particulier les
+résidences gérées par Aurore et ViaRézo). Dans le but de ne pas leur poser des
+problèmes économiques, il a été rappellé l'importance de ne pas proposer au
+crans une solution qui donnerait accès à leur connexion de manière plus
+avantageuse que ce qu'il propose. Ce constat nous a amené a réduire la liste
+potentielle des gens que nous exporteriont à une seule partie des gens
+bénéficiant des services d'hébèrgement de machines virtuelles. Ce nombre étant
+assez réduit, il a été décidé qu'il ne justifiait pas le deploiement d'un
+serveur Radius.
+
+#### Radius associatif
+
+Le running gag continue, il faut contacter l'administration.
+
+### OpenDMARC
+
+Pour s'assurer de l'authenticité des mails entrant sur une partie de nos
+serveurs mails (pour le moment seulement redisdead et mailman), le logiciel
+OpenDMARC a été déployé. C'est une implémentation du protocole DMARC, protocole
+qui consiste à vérifier que soit le SPF, soit la signature DKIM du mail est
+valide. De plus, il permet aussi l'envoie de rapports DMARC au MX qui le
+demande. Cependant, pour envoyer ces rapports, le logiciel utilise une base de
+donnée mariadb et n'est pas compatible avec postgresql. De plus, la manière
+dont cette base de donnée est rempli a été décrite comme « assez chaotique »,
+bref, il a été décidé de garder la validation OpenDMARC mais d'attendre qu'une
+solution plus propre existe pour l'envoi de rapport.
+
+### Backups
+
+Le travail est presque finalisé pour le serveur de backups, on pourra d'ici
+peut l'envoyer chez via pour faire des premiers tests.
+
+### ZIL, ZLOG, ZFS
+
+Derrière cette avalanche d'acronyme absconts se cache le problème qui a affecté
+cameron il y a peu. Le volume d'écriture demandé au serveur était devenu trop
+important quand comparé, non à la vitesse, mais au délai d'écriture de
+celui-ci. Les serveurs tentant d'acceder en écriture au nfs devait alors
+attendre longtemps avant de recevoir un acquittement générant ainsi de l'iowait
+sur ceux-ci, faisant monter en flèche leur charge et rendant inutilisable les
+services qu'ils hébergeaient. Une solution de fortune a été implémenté sur le
+serveur consistant à forcer l'envoi d'un acquittement dès la demande d'écriture
+sans attendre que celle-ci ait effectivement été faite. Bien que cela ait
+résolu le problème à cours terme, cette solution pourrait occasionner des
+pertes de données. Il faut donc trouver une solution plus pérenne que le simple
+mensonge sur les acquittements actuellement en place. Pour cela, il est
+possible de fournir à zfs un disque séparé (de préférence un ssd car on cherche
+ici au maximum à diminuer le temps d'écriture pris par le serveur) qui servira
+de cache d'écriture, l'acquitement n'étant envoyé du coup ni dès l'arrivée de
+la demande d'écriture, ni quand celui ci serait effectivement écrit sur le
+disque mais dans un état intermédiaire, à la fois plus sûre que la première
+solution et plus rapide que la deuxième. Le CT a voté pour l'achat de disques
+pour essayé de mettre en place cette solution.
diff --git a/compte_rendus/2022_11_13.md b/compte_rendus/2022_11_13.md
new file mode 100644
index 0000000000000000000000000000000000000000..e83adfe1a0a2799aac757bd08842a36e05c93f49
--- /dev/null
+++ b/compte_rendus/2022_11_13.md
@@ -0,0 +1,138 @@
+# IN du 13 novemebre 2022
+
+## Présents
+
+ * Pigeon Moelleux (secrétaire par intérim)
+Â * Chiaroush
+Â * Hachino
+Â * aplanos
+Â * esum
+Â * shirenn
+Â * vanille
+Â * ynerant
+Â * erdnax
+Â * bleizi
+Â * otthorn
+
+## Propositions projets apprentis
+
+Â * Tester sympa pour potentiel remplacement de mailman3 (nyaaa comme nom de
+VM) (ynerant)
+ * Dégager la centralisation des logs sur tealc (shirenn + pigeonmoelleux)
+ * Créer un serveur de monitoring de test pour faire des tests sans polluer la
+bdd de prod (shirenn + bleizi)
+Â * Migrer les bases postgresql sur une VM (chiaroush + shirenn + esum)
+Â * Installer un kanboard ((otthorn))
+Â * Installer un keyserver sur un (autre) LDAP (pigeonmoelleux + aeltheos)
+Â * unattended-upgrades (bleizi)
+ * Dépôt APT pour !TheLounge
+Â * Infra de test (ds-ac)
+Â * Constellation (n'existe pas) (shirenn)
+ * Intégration de Prometheus et Ceph (aplanos)
+
+## Licence sur le dépot Ansible
+
+MIT
+
+On va demander aux concernés la permission : vulcain, grizzly et Fardale
+
+Normalement c'est ok
+
+## Pages persos
+
+On prévoit de brûler Apache un jour -> Nginx (il y a des failles partout)
+Par la même occasion, plus de PHP
+
+<pseudo>.perso.crans.org à la place de perso.crans.org/<pseudo> ?
+
+## Centralisation des logs sur tealc
+
+C'était vu comme une avancée à une époque.
+Ne sert à rien ?
+
+Conclusion : on le dégage.
+
+## Monitoring
+
+On déplace le monitoring de l'imprimante car on voit plus le reste !
+
+ -> #monitoring/imprimante
+
+## Hello world
+
+Ghostscript sur hello world (des fichiers de plusieurs GB)
+
+Problème confié à ynérant
+
+Des id note qui font crash /print
+
+## ldap-adm
+
+Changement de nom
+
+## Impression
+
+https://pad.crans.org/p/PrintersAreACVE
+
+bleizi se charge d'acheter de l'encre noire
+
+## Adopte un pingouin
+
+L'admin est prévenue : on attend leur validation.
+Il faut prévenir le Yang.
+
+## 25 ans du Crans
+
+On verra plus tard
+
+## Ceph
+
+Système de fichiers distribué sur le réseau, avec redondance
+
+Plusieurs serveurs auront les mêmes données de manière intelligente pour
+pouvoir accepter de la perte
+
+''Fait de la magie''
+
+### Achat 3e serveur de stockage
+
+On va débourser de la moula :
+Environ 2 000€ HT + 1000€ de
+disques (https://tenor.com/view/la-cite-de-peur-combien-gif-18570725).
+Voir en CA combien on est prêt à débourser
+
+https://gitlab.crans.org/nounous/documentation/-/blob/ceph/infrastructure/ceph.md
+
+### Version shirenn
+
+On met les serveurs de stockage sous Debian
+
+On fait des trucs que j'ai pas eu le temps de noter
+
++ On fait des trucs avec les VLAN et du DNAT
+
++ Ajouter deux moniteurs
+
+### Version esum
+
+Déployer ceph uniquement sur les serveurs de stockage
+
+Installer proxmox sur ces serveurs (jolie interface)
+
+Plus simple d'utilisation
+
+Même trucs fait avec les VLAN que shirenn
+
+(J'avoue j'ai pas trop compris la différence)
+
+### Questionnements majeurs
+
+Debian ou proxmox ?
+
+Les clusters proxmox doivent ils faire partie du cluster ceph ?
+
+Combien de FS ? (1 ou 4)
+
+''Insérer discussions techniques complexes''
+
+''Insérer combat shirenn vs esum''
diff --git a/compte_rendus/2023_01_07.md b/compte_rendus/2023_01_07.md
new file mode 100644
index 0000000000000000000000000000000000000000..1213f019efe4af82d9a874366dee041fb9433253
--- /dev/null
+++ b/compte_rendus/2023_01_07.md
@@ -0,0 +1,114 @@
+# Réunion du Collège Technique
+
+* Date : Samedi 7 Janvier 2023
+* Lieu : Galène (https://galene.crans.org/group/IN)
+* Début : 22h
+* Fin : 23h55
+* https://pad.crans.org/p/Samedi7Janvier2023
+
+## Présent⋅e⋅s
+
+* [[DsAc|ds-ac]]
+* [[WikiAplanos|aplanos]]
+* [[WikiBleizi|bleizi]]
+* esum
+* Otthorn
+* [[PigeonMoelleux|Pigeon Moelleux]]
+* shirenn
+* vanille
+
+## Planning des IN et des CAs
+
+Le CA a proposé que le planning des INs / CAs soit le suivant. Un samedi soir
+sur deux, une fois IN et l'autre fois CA. Cela semble satisfaire tout le monde.
+Un frama sera envoyé pout fixer l'horaire.
+
+## Infra de test
+
+Arnaud --(a rien foutu)-- fait des petites choses et j'ai pas suivi ce qu'il a
+dit au début.
+
+* ecilis : plan d'utiliser knot mais il faut modifier le script ldap pour que
+ la délégation ne marche pas
+* plan de rajouter un ldap parcélaire :
+* projet de stocker les certificats dedans
+ projet d'apprentis
+
+## Faille de sécurité du Crans
+
+''Vous pouvez circulez, tout se passe bien ici''
+
+ -> projet d'apprentis (et de moins apprentis (et de moinmoins
+ apprentis<<FootNote(C'est celleux qui apprennent à utiliser le
+ wiki)>>)) filtrer les chemins
+
+## Summers et fluxx
+
+Ce sont des VMs.
+
+fluxx -> Système de streaming (https://stream.crans.org <3)
+
+Conclusion : on garde
+
+Summers -> On ne sait pas à quoi elle sert ...
+
+Conclusion : on brûle
+
+## Ftp
+
+On en a à deux endroits :
+
+* Le FTP du crans
+* Le miroir (http://eclat.crans.org)
+
+Supprimer le support ?
+
+Oui
+
+## Tealc et sam vont chez le médecin
+
+Il faut racheter des disques pour tealc et sam.
+
+## Ceph
+
+''Débat entre esum et shirenn incoming''
+
+Faire une migration petit format
+
+Zbee -> utilisation pour la migration en RAID ? / Plutôt utiliser du ceph ?
+
+Date précise à la prochaine IN
+
+## Unattended upgrade
+
+Des tests ont été fait par shirenn et bleizi
+Il faut discuter des paramètres :
+
+* Reboot après MAJ du kernel ? Si oui avec quelles exceptions ?
+ * Oui pour certains, et on utilise "need-reboot" avec prometheus pour les
+ autres
+* Restart des services ? Si oui avec quelles exceptions ?
+ * Oui au maximum (pas IRC par exemple) : liste exhaustive à définir
+
+## Mail 25 ans du Crans
+
+On enverra un mail demain (presque aujourd'hui)
+
+On annonce :
+
+* L'immolation par le feu de horde
+* Nouveau système pour https://perso.crans.org/<pseudo>
+
+''Une certaine sh***nn voulant rester anonyme aurait dit : 'Le PHP c'est trop
+bien' ''
+
+* Date des 25 ans
+
+## HaveIBeenPwned
+
+On envoie des messages sur IRC et on évite les mails all (sauf si
+concerne '''beaucoup''' de monde).
+
+## Mastodon
+
+Mise en place après la migration sur ceph
diff --git a/compte_rendus/2023_02_04.md b/compte_rendus/2023_02_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..7b27d5998e10d42bc590617f592a1ee3e7a646bd
--- /dev/null
+++ b/compte_rendus/2023_02_04.md
@@ -0,0 +1,69 @@
+# Réunion Inter Nounous
+
+* Date : Samedi 4 Février 2023
+* Lieu : MB85 et Galène (https://galene.crans.org/group/IN)
+* Début : 20h15
+* Fin : 21h45
+
+## Présents
+
+* [[VanilleNiven|Vanille]]
+* [[DsAc|ds-ac]]
+* [[WikiBleizi|Bleizi]]
+* [[PigeonMoelleux|Pigeon Moelleux]]
+* [[WikiShirenn|shirenn]]
+* [[SolalNathan|Otthorn]]
+
+### Routage avec Aurore
+
+3 routeurs Crans, 2 routeurs Aurore
+
+En permanence un unique lien Aurore-Crans; délai sur la clôture quand on change
+de routeur.
+
+Jeltz + shirenn + Ds-ac vont taffer.
+
+Setup de routage avec aurore, donner des ips uniques sur le lien pour maximiser
+l'uptime et réduire les potentiels problèmes de coupures
+
+### Séminaires
+
+Point sur les séminaires
+
+* peu de public mais ok
+* dèche de présentateurs
+
+Sujets qui mijotent:
+
+* Pare-feu & routage par ds-ac (Jeudi 16 Février)
+* virtualisation
+* ipv6 par Chiara
+
+Fonds pour grignoter après la fin du séminaire ?
+
+### Présence sur campus
+
+Pas trop technique mais je sais pas où le mettre : en fin d'année on risque de
+ne plus avoir grand-monde sur le campus et ça peut poser souci pour intervenir,
+par exemple sur l'imprimante. Exemple bête, mais comment le nouveau BDE compte
+imprimer ses GdR ? EDIT : Je suis con, ce sont les livrets WEI qui sont
+imprimés par le Crans habituellement, donc on s'en tape
+
+Plus généralement, quid d'une éventuelle intervention hardware pendant les
+départs en stage ?
+
+Solal est sur le campus la majorité du temps.
+
+### Redondance de rate-limit
+
+Plusieurs rate-limits, est-ce que celle de Postfix est redondante ? => non
+
+### mailing list sans proprio
+
+On envoie un mail pour trouver unâ‹…e proprio et on supprime au bou d'un mois
+sans réponse (ou on supprime direct si c'est pas possible de trouver un⋅e
+proprio légitime)
+
+### Site de la SoNo
+
+site sono => on va le faire doucement
diff --git a/compte_rendus/2023_03_04.md b/compte_rendus/2023_03_04.md
new file mode 100644
index 0000000000000000000000000000000000000000..7fc0bd0c59416a05d958fa64557ff3521e8f5ba7
--- /dev/null
+++ b/compte_rendus/2023_03_04.md
@@ -0,0 +1,71 @@
+# Réunion du Collège Technique
+
+* Date : Samedi 4 Mars 2023
+* Lieu : MB85 et Galène (https://galene.crans.org/group/CA)
+* Début : 16h00
+* Fin : ~17h00
+* Pad: https://pad.crans.org/p/Samedi04Mars2023
+
+## Présents
+
+* [[VanilleNiven|Vanille]]
+* [[WikiShirenn|shirenn]]
+* [[DsAc|ds-ac]]
+* [[WikiAeltheos|Aeltheos]]
+* [[WikiBleizi|bleizi]]
+* [[SolalNathan|Solal]]
+* [[Benjamin|esum]]
+
+## Ordre du jour
+
+### DKIM
+
+Observation: beaucoup de signatures DKIM sur un seul mail. Mailman signe le
+même mail à de multiples reprises. De plus mailman.crans.org semble signer pour
+crans.org ? Il ne devrait même pas avoir de clé.
+
+Cause du problème (identifiée pendant la séance): il y avait des bypass pour
+auto-signer les mails transférés en interne, cela produisait des mails
+avec 3 signatures dont la 3ème était automanique pour des mails envoyés depuis
+une ML.
+
+Solution (implémentée pendant la séance): ne pas faire passer en interne les
+mails concernés.
+
+### Kea
+
+Suggestion d'utiliser Kea (https://packages.debian.org/bookworm/kea) pour
+remplacer notre actuel serveur DHCP qui est déprécié. Kea n'est pas encore en
+production.
+
+Le mode de configuration a été examiné pendant la séance et semble à première
+vue gérable et propre. Si nous migrons il est envisagé de (1) automatiser la
+migration et (2) s'y prendre à l'avance pour avoir une transition sans délai.
+
+### Suppression d'utilisateurs
+
+Suite au mail annuel il y a eu 17 demandes de suppression de compte.
+
+Elles sont traitées manuellement mais il est discuté la possibilité de
+permettre aux utilisateurs de supprimer eux-même leur compte.
+En attendant il s'agit de garantir que la documentation des choses à supprimer
+et comment est Ã
+jour: https://gitlab.crans.org/nounous/documentation/-/blob/master/howto/delete_user.md
+
+NOTE: impossible de supprimer certaines informations de facturation
+avant 10 ans.
+
+NOTE: s'assurer que les demandes de justification d'identité passent par un
+canal privé plutôt que la ML de support technique.
+
+### VoIP
+
+Un utilisateur nous a demandé ce qui était advenu de
+VoIP (cf: [[VieCrans/UtiliserVoIP]].
+Nous confirmons que ce service a été désactivé il y a un certain temps pour
+cause de non usage et il n'est pas envisagé de le réactiver.
+
+### Servers: murozond et nozdormu
+
+Demande d'ajout de ces serveurs aux racks de ServENS.
+Approuvée à l'unanimité.
diff --git a/compte_rendus/2023_04_01.md b/compte_rendus/2023_04_01.md
new file mode 100644
index 0000000000000000000000000000000000000000..e402cd7ef3f54fbeeb36d2eb78f293c626ae1fb3
--- /dev/null
+++ b/compte_rendus/2023_04_01.md
@@ -0,0 +1,61 @@
+# Réunion Inter Nounous
+
+* Date : Samedi 04 Avril 2023
+* Lieu : MB85 et Galène (https://galene.crans.org/group/CA)
+* Début : 12h00
+* Fin : 13h15
+
+## Présents
+
+* [[DsAc|ds-ac]]
+* [[WikiBleizi|bleizi]]
+* [[Benjamin|esum]]
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* [[SolalNathan|Otthorn]]
+* [[VanilleNiven|Vanille]]
+
+## Ordre du Jour
+
+* users externes sur gitlab
+* ceph
+* formation aux outils du crans pour le nouveau BDE
+* description du crans sur agenda du libre
+
+### Users externes sur gitlab
+
+Suite à un user voulant ajouter quelqu'un d'externe sur un de ses projets
+''Discussion en cours''
+On accepte les users externes après mail aux nounous avec pour
+pseudo "<pseudo>_external"
+Gitlab a été upgrade
+
+### Ceph
+
+On attend la livraison des disques, et on attend la commande des disques
+Si on reçoit les disques la semaine prochaine, on peut faire la migration dans
+quelques semaines (21-22 avril ?)
+Il faudra : setup le serveur + fix les disques de tealc et cameron + remplacer
+les disques avec des secteurs deffectueux
+Commande : 17 disques (15 de 2To et 2 de 3To)
+
+### Changer le disque de sam
+
+bleizi fait ça cet aprem
+
+### Formation Crans
+
+On enverra un mail au BdE pour faire venir tout le monde
+
+### Agenda du libre
+
+Changer ;
+
+* adresse mail : contact@crans.org
+* description : à peu près "Le Crans est une association à but non lucratif
+ fournissant des services informatiques reposants sur des logiciels libres aux
+ étudiants et associations de l'ENS Paris-Saclay."
+
+### WireGuard
+
+Fournir un VPN à tous les adhérents par wireguard
+Projet apprenti (s'il y en a ? :sob:)
diff --git a/compte_rendus/2023_04_29.md b/compte_rendus/2023_04_29.md
new file mode 100644
index 0000000000000000000000000000000000000000..7daea1470d10639da5ff88de7f69947ddd3b2f92
--- /dev/null
+++ b/compte_rendus/2023_04_29.md
@@ -0,0 +1,63 @@
+# Réunion Inter Nounous
+
+* Date : Samedi 29 Avril 2023
+* Lieu : MB85 et Galène (https://galene.crans.org/group/CA)
+* Début : 13h00
+* Fin : 15h10
+
+## Présents
+
+* [[WikiBleizi|bleizi]]
+* [[SolalNathan|Otthorn]]
+* [[WikiShirenn|shirenn]]
+* [[VanilleNiven|Vanille]]
+* lzebulon
+
+## Ordre du Jour
+
+* ceph
+ Installé
+ surcoût de vis pour fixer les disques
+ carte réseau pas compatible
+* [infra de test] retour sur le projet Certdap
+ https://pad.crans.org/p/projet-cerdap
+ LDAP créé avec 3 apprenti.es
+* [infra de test] Droits et apprenti·es
+ Donner les droits d'écriture aux apprenti.es ? Pb: l'infra apprentis sur
+ laquelle les apprentis sont roots est isolée, celle-ci non
+* Mettre en place une instance Overleaf au Crans ?
+ Overleaf rendu open récemment: https://github.com/overleaf/overleaf
+ Voir https://plmlatex.math.cnrs.fr/ qui est l'analogue CNRS. Obstacles de
+ scalabilité ? À voir.
+* Framaform
+ ça marche très bien chez framaform, c'est pas vraiment nécessaire de
+ l'importer
+* Ménage dans les ML
+ Considérées utiles / périmées : -> c'est bleizi qui supprime
+ * achats-crans
+ * apprenti-es
+ * aurore-crans (garder les archives)
+ * blahblahlist
+ * bureau
+ * ca
+ * conduct? → En attente de la réponse de Pollion
+ * crous-crans (garder les archives)
+ * disconnect (brûler les archives)
+ * dsi-crans (garder les archives)
+ * federez (hors de notre contrôle)
+ * fin-de-connexion-imminente (pas d'archives)
+ * technique
+ * install-party
+ * mailman (bruler d'archives)
+ * moderateurs (brûler les archives)
+ * nounous
+ * orga-25ans
+ * paiements (garder les archives + aliaser sur tresorerie)
+ * paypal (brûler les archives)
+ * ripe → Ping Pollion
+ * roots
+ * test
+ * tresorerie
+ * urgent → jéjé kraft envoie mail → c'est pas le crans
+* Problèmes IPv6 récents → non. (vérifier à la couche 8)
+* https://unit.nginx.org -> prochaine IN
diff --git a/compte_rendus/2023_05_27.md b/compte_rendus/2023_05_27.md
new file mode 100644
index 0000000000000000000000000000000000000000..a334dd5bd5e1b2ebafa3b839062909bea5e2a8c0
--- /dev/null
+++ b/compte_rendus/2023_05_27.md
@@ -0,0 +1,50 @@
+# Réunion Inter Nounous
+
+* Date : Samedi 27 Mai 2023
+* Lieu : MB87 et Galène (https://galene.crans.org/group/CA)
+* Début : 21h10
+* Fin : 22h30
+
+## Présents
+
+* [[SolalNathan|Otthorn]]
+* [[VanilleNiven|Vanille]]
+* lzebulon
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* [[WikiAeltheos|Aeltheos]]
+* Chiaroush
+* [[DsAc|ds-ac]]
+
+## Ordre du Jour
+
+* Retour sur le changement de disque de tealc
+* Questions diverses
+
+## Changement de disque de tealc
+
+Le disque a été modifé mais n'a pas été intégré à la pool ZFS.
+Il faut utiliser `zpool replace` et tout sera bon.
+Tout a été réglé en direct.
+Problème : il a fallu spécifier le paramètre "ashift" à la main
+
+(Not so) fun fact:
+
+Seul un paramètre ashift est valide
+
+#> zpool aurait pu nous en dire plus, genre "attention, pas le bon ashift
+gnagnagna, si tu veux faire caca, ajouter XXX Ã la ligne de commande."
+
+## Questions diverses
+
+### Mastodon
+
+On attend la migration de Ceph pour en parler
+
+### VPN adhérent
+
+Debian + Wireguard + Interface web
+Sera fait un WE prochain en vocal sur galène
+
+### Information sur l'avancement des projets
+
+Wiki ?
diff --git a/compte_rendus/2023_06_24.md b/compte_rendus/2023_06_24.md
new file mode 100644
index 0000000000000000000000000000000000000000..8b3fb6fa69b4780b277b5723f7f3c8776e3ed2fd
--- /dev/null
+++ b/compte_rendus/2023_06_24.md
@@ -0,0 +1,158 @@
+# Réunion Inter Nounous
+
+* Date : Samedi 24 Juin 2023
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
+* Début : 15h00
+* Fin : 17h00
+
+### Présents
+
+* [[VanilleNiven|Vanille]]
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* [[WikiBleizi|bleizi]]
+* [[DsAc|ds-ac]]
+* [[Benjamin|esum]]
+* lzebulon
+* [[WikiAplanos|Aplanos]]
+
+### Ordre du Jour
+
+* Belenios
+ * mise à jour de 1.15 à 2.1 ?
+ * on est très (trop ?) bien référencé, donc on a reçu un mail de qqun (pas
+ du tout membre) qui voulais faire une élection
+* Discussion autout de la prochaine IP
+ * En faire une petite en septembre ou attendre les 25ans ?
+ * Motivation : certain·es profs / chargé·es de TD aimeraient que leurs
+ élèves soient un peu plus à l'aise sur leurs machines et cela permettrait
+ probablement de discuter des 25ans (et donc ne pas se retrouver sans jeunes
+* Idée à discuter concernant les IPs: faire le séminaire "Bases d'Unix, Bash,
+ SSH" le matin
+* Que faire des VMs en fin de vie ? On les débranche ou on les met sous
+ perfusion pour le reste de leur vie ?
+* Cancel !ChanServ --(+ ptdr comment on est une divinité sur IRC ?)--
+* Migration à bookworm https://ethercalc.crans.org/6jbvxvfw0sxu
+ * J[ds-ac]'ai vu une VM hung sur un prompt lié à bookworm ; c'est normal ?
+* Migration à NixOS de certains services ?
+* Une première VM sous Guix ?
+ * Question : comment ajouter une VM au LDAP sans faire crier Prometheus
+* suite office sur owncloud
+ * https://owncloud.crans.org/apps/market/#/app/onlyoffice
+ * https://owncloud.crans.org/apps/market/#/app/richdocuments
+ * https://sandstorm.io/ (proposition d'ethercalc like avec option pour
+ read-only)
+* Le Crans n'est pas listé comme fournisseur d'ethercalc sur le site Chatons
+* Envoyer un mail à !ViaRezo à propos du peering BGP
+* Problèmes récents au niveau des crons
+* Point Ceph
+* rezel qui peut pas se connecter à proxmox
+* xmpp
+
+### Belenios
+
+* On a reçu un mail de qqn qui n'est pas lié au Crans souhaitant administrer
+ une élection sur belenios.
+* Il faut changer le message d'accueil pour bien spécifier que ce service est
+ réservé aux adhérents du crans à la 2e ligne.
+
+(2ème ligne dit "si vous n'avez pas de compte contactez-nous", ça sous-entend
+que n'importe qui peut obtenir un compte juste en nous contactant...)
+
+* + On en profite pour faire une MAJ (de belenios et de la VM)
+
+### Install Party
+
+* Faire install party et/ou séminaires bash, Unix et SSH vers fin septembre
+* On prévient les départements, en particulier EEA et info et on demande de
+ faire de la pub
+
+### VM adhérents
+
+On tue les VMs en fin de vie
+
+* VM adhérent: mail, brûler.
+* 1 mois après la fin de l'adhésion : on l'éteint
+* 2 mois après la fin de l'adhésion : on supprime le disque
+
+### ChanServ
+
+--(Il est en sursis.)--
+
+https://libera.chat/guides/certfp
+
+### Bookworm
+
+* Bullseye est mort. Longue vie à Bookworm !
+* Proxmox : https://pve.proxmox.com/wiki/Upgrade_from_7_to_8
+ * Normalement les upgrades devraient bien se passer
+ * D'abord les services, puis les proxmox et on attend ceph pour les stockages
+ * Proxmox : les mettre à niveau un par un.
+
+### NixOS & Guix
+
+On teste de passer qq services sur NixOS car c'est plus simple à prendre en
+main que Ansible
+
+* NixOS
+ * Gitlab
+ * IRC
+ * Zero
+ * Ethercalc ?
+ * Roundcube
+ * !NextCloud ?
+ *Avec !OnlyOffice ?
+* Guix
+ * Non : pas plus de deux OS au Cr@ns => Nix plutôt que Guix (nombre de
+ paquets disponibles).
+
+### Owncloud, NextCloud
+
+* On passe sur !NextCloud ?
+* Est-ce que la migration se fait bien du point de vue utilisateur ?
+* On garde les deux un moment puis on coupe Owncloud au bout d'un moment.
+* On intègre !OnlyOffice avec, et on invite les gens à migrer de ethercalc
+
+### Ethercalc
+
+[Cf Owncloud/NextCloud]
+
+* Pour être un chaton, il faudrait chiffrer tous les disques.
+* Les disques de stockage de Cephiroth sont maintenant chiffrés
+* On va devoir camper en SQ39 pour faire des trucs
+* On est pas obligé d'être listé comme un chaton à la vue des contraintes que
+ cela génère
+
+### BGP ViaRézo
+
+bleizi s'est désigné pour envoyer un mail pour dire que tout est cassé
+
+### Cron
+
+Caca --(créé et)-- résolu par shirenn (''merci <3'')
+
+### Ceph
+
+''Ça commence à faire longtemps qu'on en parle, ça arrive bientôt''
+
+* L'intégration de ceph sous NixOS est pas encore très mature donc on va rester
+ pour l'instant sur debian
+* Cephiroth est installé avec les paquets ceph
+* Il faudrait installer au moins un autre serveur au cluster pour que Cephiroth
+ ne soit plus en état "dégradé"
+* Il faudra migrer les disques des VM crans sur ceph -> ... -> intégrer tealc
+ au cluster
+
+### Rezel
+
+* On a migré leur VM et elle est toute cassée, et ils ont pas accès Ã
+ l'interface proxmox.
+* On leur crée un compte adhérent gratuitement, on leur reset leur MDP par mail
+ puis ils peuvent faire ça en passant par zamok.
+
+### xmpp
+
+* Question d'un ancien pour savoir si on avait un serveur XMPP
+* Il y a autant d'utilisateurs de xmpp que de Guix -> donc non
+ ''Ça veut dire que je [ds-ac] ne suis plus tout seul à utiliser Guix au
+ Cr@ns ?''
+ ''Yes, trop bien !''
diff --git a/compte_rendus/2023_09_23.md b/compte_rendus/2023_09_23.md
new file mode 100644
index 0000000000000000000000000000000000000000..f1dbf8863bcd026d48e30456eae364d662ea559f
--- /dev/null
+++ b/compte_rendus/2023_09_23.md
@@ -0,0 +1,178 @@
+# Réunion IN
+
+## Réunion nounou
+
+* Date : Samedi 23 Septembre 2023
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
+* Début : 17h00
+* Fin : 18h53
+
+### Présent⋅es
+
+* [[WikiAeltheos|aeltheos]]
+* [[WikiAplanos|Aplanos]]
+* [[WikiBleizi|bleizi]]
+* [[DsAc|ds-ac]]
+* [[Esum|esum]]
+* !GaBo
+* [[WikiHachino|Hachino]]
+* hugoooo
+* lzebulon
+* Shinigami
+* [[WikiShirenn|shirenn]]
+* [[VanilleNiven|Vanille]]
+
+Et les 1A alors ? Ils existent et on les apprécie beaucoup. Vive la jeunesse.
+
+### Ordre du Jour
+
+* problèmes matériels
+ * RAM de tealc
+ * disque de thot -> 2TB SAS HP
+* réparations/améliorations logicielles
+ * authentification sur pve-adh
+ * privilèges de lecture de mails sur zamok
+ * gitlab
+ * backups plus économes
+ * modération de la ML CA
+* amélioration de la documentation et du logging
+ * regrouper les mails de Cron (*ahem* j'ai 23224 mails non lus de Cron dans
+ ma boîte mail...)
+ * lister proprement les services selon le critère "est-ce que c'est ok de
+ les éteindre et redémarrer"
+ * point sur la coupure de tous les services forcée par l'ENS
+ * accueil des nouveaux et nouvelles
+ * succession prochaine du CT
+* divers
+ https://zero.crans.org/?a3ae6af57d8cece0#3PA9Fg8ydKcrvWwcdPW2L5EbEjjSabowvWPXWWeDLKmJ
+ home, vanille, aplanos
+
+### Accueil des nouveaux et nouvelles
+
+Tour de table pour que tout le monde se présente. Tout le monde est jeune,
+c'est parfait.
+
+### Tealc
+
+Erreur de RAM -> Redémarrage -> Réparé #!DansLeDouteReboot
+
+### Disque de thot
+
+Il faut un disque HP de 2To en SAS
+
+sam a aussi des smart error sur un disque, prendre un HP 1TB
+
+je (aeltheos) passerais une liste des reférence.
+
+### Authentification sur pve-adh
+
+Modifications faites sur le script -> Permettre d'avoir des tokens d'API (en
+discussion) et corriger qq droits d'accès
+
+### Lecture des mails sur zamok
+
+Tout le monde peut lire sur mailq (au pire, tout le monde peut savoir qui a
+communiqué avec qui)
+
+Correction cf https://www.postfix.org/postconf.5.html#authorized_mailq_users
+
+esum s'en occupe
+
+Ça marche pas, tristesse.
+
+### gitlab
+
+Reporté à quand Otthorn sera lÃ
+
+Mise à jour 16.4 par bleizi
+
+### backups
+
+Reporté à quand Otthorn sera lÃ
+
+### Modération de la ML CA
+
+Actuellement pas de modération pour les mails du Crans
+
+On passe en modération
+
+Suggestion : signaler sur signal-spam => non.
+
+### Regrouper les mails de cron
+
+Globalement non
+
+Il faut filtrer les mails
+
+Ceux qui lisent pas tous leurs mails sont cancels
+
+### Lister les services à redémarrer
+
+Cf. https://pad.crans.org/p/Samedi23Septembre2023_aux
+
+### Point sur la coupure de tous les services forcée par l'ENS
+
+RAS.
+
+### accueil des nouveaux et nouvelles
+
+Coucou !
+
+aeltheos
+
+* projet Ceph
+* HA sur les services critiques postgresql / openldap
+
+esum, shirenn, aeltheos, pigeonmoelleux
+
+* ansible -> nixos + utiliser des flakes
+
+Question : toutes les parties de nos configurations et fichiers Ansible qui
+vont chercher dans le LDAP/le pass/les variables d'hôte sont récupérées quelque
+part
+
+Réponse : c'est pas l'heure. Pour le moment, l'idée est juste d'avoir un
+playbook root fonctionnel (pun intended haha <3)
+
+shirenn, aeltheos
+
+* upgrade debian : bullseye -> bookworm
+* playbook root -> crans
+
+ds-ac, aeltheos, (vanille? : c'est lui qui a déployé radius il me semble)
+
+* Routeur 27-54
+
+vanille
+
+* Constellation <3 -_- mais si tu es motivé ! je t'assure !
+* L'imprimante du Crans ? Elle charge des docs identiques N fois au lieu de les
+ charger 1 fois + copier l'instruction "imprimer". C'est très con. Entre
+ autres joyeusetés à améliorer (on parle même pas du statut de la BU ou de
+ l'imprimante post-Lumen, ni de celle de Cachan).
+
+### succession prochaine du CT
+
+Rappel:
+
+Au Cr@ns (enfin au CT (Conseil Technique) du Cr@ns), il y a :
+
+* des apprentis
+* des nounous (qui prennent soin des serveurs (et des apprentis))
+* une nounou particulière : la maman des serveurs
+
+La maman est président·e du CT.
+
+Un·e apprenti·e peut devenir nounou. Cela se fait souvent après un projet
+encadré.
+
+La maman va mourir, trouvons quelqu'un pour adopter ses petits. #Bambi
+
+### divers
+
+DsAc veut pousser pour du DANE pour certbot :
+Crochets d'authentification pour Certbot :
+scripts en bash → garder des scripts en Python.
+
+home, vanille, aplanos :
+Il y avait un pb d'UID dans le LDAP. C'est corrigé.
diff --git a/compte_rendus/2023_10_21.md b/compte_rendus/2023_10_21.md
new file mode 100644
index 0000000000000000000000000000000000000000..3b0d932660a1db1faad0665ae9229c1ba6516792
--- /dev/null
+++ b/compte_rendus/2023_10_21.md
@@ -0,0 +1,154 @@
+# Réunion nounou
+
+* Date : Samedi 21 Octobre 2023
+* Lieu : 1N82 et Jitsi (https://meet.jit.si/oskour-the-crans-is-dying)
+* Début : 18h10
+* Fin : 19h35
+
+### Présent⋅es
+
+* [[WikiAplanos|Aplanos]]
+* [[WikiBleizi|bleizi]]
+* [[DsAc|ds-ac]]
+* [[Esum|esum]]
+* !GaBo
+* [[WikiHachino|Hachino]]
+* lzebulon
+* [[VanilleNiven|Vanille]]
+* !RedDiamond
+* [[WikiSerenilink|Serenilink]]
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+
+### Ordre du jour
+
+* pb de connexion
+* pb de mot de passe/clé ssh
+* discussion fail2ban / crowdsec pour gitlab
+* passer le mà j en « je fais que les updates de sécu »
+* mailman avec le module sieve (pour les filtres mails)
+* Projets apprentis:
+ * WG : permettre aux gens de se faire un bloc de config de WG
+ * Galène : front-end pour parler LDAP : autoriser la création de
+ groupes "frais" (la personne créant le groupe est "créateurice" et peut
+ supprimer le groupe, modif les options, ...)
+* [ds-ac] Questions aux nixien·nes :
+ * y a-t-il un équivalent à "guix deploy" dans nix, et est-ce qu'on a une
+ chance de l'intégrer avec Proxmox ? Si oui, est-ce que unattended-upgrades
+ est impacté ?
+ * comment étendre Nix, au sens définir des fonctions maison, qui peuvent
+ être impures (e.g. pour lookup dans un ldap lors du (re)déploiement d'une
+ machine) ?
+* [Pigeon Moelleux] BdE et Intel Unite
+* [ds-ac] esum: quels changements sur IRC (réduction du spam)
+
+### Problèmes de connexion
+
+LE CRANS EST DOWN ! Longue vie au Cr@ns !
+
+On timeout dans tous les sens ! Mais c'est pas notre faute !
+Aurore répare le problème bientôt.
+
+Sputnik est utilisé pour faire transiter le web (à la place de hodaur)
+
+Mailq a été augmenté à 10 jours pour pas perdre de mails.
+
+Activation du slow sur le postfix de mailman3
+
+On enverra un mail all quand tout sera réglé
+
+Revoir la communication d'erreurs
+
+### Problèmes de mots de passe / clef SSH
+
+Des mots de passe ont fuité sur le gitlab
+
+Les mots de passe ont été changés par esum et shirenn
+
+Le pass a été rechiffré plusieurs fois
+
+### Discussion fail2ban / crowdsec pour gitlab
+
+On demandera à Solal quand on le verra.
+
+### Passer les MAJ en "Je fais que les updates de sécu"
+
+Est-ce qu'on le fait ?
+
+On attend que shirenn soit là pour en parler.
+
+### Roundcube avec le module sieve
+
+Demande de transformer la façon dont on gère les mails (étendre la gestion de
+dovecot)
+
+ds-ac pop un serveur mail sur test.crans.org
+
+''Je vais l'appeler : mx47.test.crans.org''
+
+Faire attention aux logs des tests
+
+### Projets apprentis
+
+#### WG : permettre aux gens de se faire un bloc de config de WG
+
+esum a un ancien petit projet en Django pour gérer du Wireguard à distance par
+les adhérent⋅e⋅s
+
+Django app
+
+* le front-end gère la partie "qui a le droit de faire quoi?"
+* subprocess -> utiliser `wg-tools` pour parler à WG
+
+#### Galène
+
+Front-end pour parler LDAP : autoriser la création de groupes "frais" (la
+personne créant le groupe est "créateurice" et peut supprimer le groupe, modif
+les options, ...)
+
+Problème : comment contrôler les accès aux salles + comment gérer les conflits
+entre salles ?
+
+Regarder avec les sous-groupes
+
+Django app
+
+* le front-end gère la partie "qui a le droit de faire quoi"
+* modifier un LDAP d'auth pour Galène derrière
+
+#### Wiki
+
+Connecter la Note au wiki
+
+Qui veut faire du Python 2 ?
+
+Aucun wiki ne correspond à nos attentes pour l'instant
+
+Ça ne réglera aucun problème au niveau intérêt des gens pour le wiki
+
+#### Intel Unite
+
+Refaire un Intel Unite version Crans ?
+
+Demander le cahier des charges au préalable
+
+Peut-être faire un hackathon ?
+
+On va demander à Erdnaxe si ce qu'il en pense.
+
+Si l'ENS nous demande, on va y réfléchir un peu, pour le BdE on dit non.
+
+### Nix
+
+#### NixOS deploy
+
+Équivalent de guix deploy : demander à aeltheos
+Serveur de cache au Crans
+
+#### Utilisations de fichiers hors config
+
+Il vaudrait mieux mettre tout dans la config nix quitte à changer un peu notre
+infra
+
+### Spam sur IRC
+
+On n'y peut pas grand chose (et il y a genre ~1 bot par semaine).
diff --git a/compte_rendus/2023_12_02.md b/compte_rendus/2023_12_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..db60b97fa45b24fb22424b8e1ac1211a7df17e3f
--- /dev/null
+++ b/compte_rendus/2023_12_02.md
@@ -0,0 +1,246 @@
+# Réunion du Collège Technique
+
+* Date : Samedi 2 décembre 2023
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN/)
+* Début : 20h22
+* Fin : 22h54
+* https://pad.crans.org/p/Samedi02Decembre2023
+
+## Présent⋅es
+
+* [[WikiAplanos|Aplanos]]
+* Korenst1
+* !GaBo
+* [[WikiHachino|Hachino]]
+* [[VanilleNiven|Vanille]]
+* !RedDiamond
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* [[WikiBleizi|bleizi]] (arrivée à 21h15)
+* Petit Gaga (???) (En post-Quill)
+
+## Ordre du jour
+
+* Réplication de la BDD gitlab (car elle est créée par gitlab, voir avec
+ shirenn)
+* [bleizi] rendre inactifs les compte que l'on arrive pas à contacter par mail
+* [bleizi] signer dkim les mails de re2o
+* [shirenn, bleizi et ds-ac] redirection des mails depuis zamok vers redisdead
+* [bleizi] crans OID
+ https://www.iana.org/assignments/enterprise-numbers/?q=crans
+* [bleizi et shirenn] SPF pour les mails sur redisdead : retour sur la mise en
+ place + est-ce qu'on est plus restrictif (drop des fails) ?
+* [Pigeon] Dovecot sieve pour le tri des mails dans les sous-dossiers pour tous
+ les adhérent⋅e⋅s utilisant leur adresse mail crans
+* [bleizi] https://hosts.crans.org/ c'est quoi ?
+* [ds-ac] faire un mini tuto install Debian avec
+ gpt-auto-generator + systemd-growfs-root pour les VMs adh
+* [ds-ac] mailman et spam from self : whitelists trop permissives ?
+* [Hachino] [Un peu HS] Le hotspot eduroam de l'ENS marche pas quand t'as une
+ adresse/un compte hors ENS. :( (Testé avec Hachino et 20-100.) Quelle est la
+ bonne façon de contacter la DSI pour leur en parler ?
+* [Hachino] Randomly, 20-100 vient de découvrir que la fonction "Ajouter un
+ commentaire" de Framadate est cassée. Qué pasta ?
+
+Trucs à pas oublier :
+
+* Contacter la DSI pour du RADIUS
+* RALLUMER LES BACKUPS SUR NETNS, ZAMOK-MYSQL ET LINX
+
+## Dovecot sieve / Procmail
+
+Possibilité de définir un sieve par utilisateur ?
+
+"Est-ce qu'on utilise Dovecot au Crans ?" --> Après recherches, oui, mais "il
+est planqué où ?" [Ça se voit que l'IN manque de gens là ?]
+
+Pigeon a trouvé, victoire ! "/etc/dovecot/conf.d/90-sieve.conf"
+
+Conclusion :
+
+* Vanille est choqué par le MOTD de Owl. À raison.
+* Les gens apprennent à proxy jump
+* on testera ça la prochaine fois qu'on casse les mails
+* !GaBo demande où sont les adultes. Réponse : nulle part.
+* ds-ac devait faire une VM sur l'infra de test et les membres actifs devaient
+ faire des tests. Bon bah plus tard alors.
+* bleizi pose la question de l'expressivité de Dovecot. Pigeon affirme que
+ Procmail est strictement moins puissant que Dovecot et donne l'exemple des
+ messages d'absence/réponses automatiques/regex (Aplanos est très bruyemment
+ contre les regex).
+
+''On remarquera que le compte rendu n'est pas linéaire car certains points ont
+été abordés plusieurs fois''
+
+## Point DSI
+
+Les comptes non ENS ne fonctionnent pas sur eduroam.
+
+Hachino s'en charge. Un jour, insh'. 2ème étage, couloir 2[A-Z]82 d'après !GaBo
+et Pigeon.
+
+L'espoir est très très mince. :(
+
+## Point Regex
+
+À l'aide
+
+## Point SCP (à l'intérieur du point Quill)
+
+Après avoir bifurqué sur Quill, Pigeon en arrive à une murder SCP qu'il écrit
+avec Charsle. Korenst1 est perdu par ce qu'est SCP.
+
+S'ensuit une explication succincte de Pigeon.
+
+## Framadate
+
+Pigeon vient de le vérifier : le bouton "Ajouter un commentaire" est un
+mensonge.
+
+Personne ne sait où sont les logs de framadate, on remet le point à la
+prochaine IN.
+
+## Les autres points
+
+Il manque les gens qui les ont ajoutés à l'ODJ. Derp. Ce sera pour l'IN de
+décembre. Bon allez, on essaye quand même.
+
+## Point Pass
+
+Pigeon explique le principe de GPG et de Pass.
+
+''Puis bleizi arrive, c'est un miracle !''
+
+## Points messages de Pigeon
+
+* Aurore est très fortement sous l'eau, "plus que la DSI". 90% du taf est fait
+ par Jeltz, 5% par Lucas "Tavary-Maujean" et 5% par Vincent Lafeychine.
+* Anim[ENS] se plaint de la qualité de service de Galène (vs Ghostream) et
+ demande la résurrection de Ghostream. Pigeon sait faire et s'en occupera
+ lui-même, vu sa proximité avec Anim[ENS] (au hasard).
+
+## Réplication BDD gitlab
+
+On backup certains trucs de gitlab mais pas sa BDD. Elle n'est backup que
+pendant les MAJ gitlab (~1 fois/mois), il faudrait le faire automatiquement.
+
+Gitlab est un énorme pâté qui installe tout seul les paquets dont il a
+besoin (et possiblement sa BDD).
+
+On attend shirenn pour voir ça.
+
+## Comptes non contactables
+
+On refuse de regarder le .forward des gens.
+
+Possibilité : envoyer un mail aux gens "hey, ton compte semble inactif, si tu
+réponds pas d'ici X mois [X entre 1 et 6], on va l'archiver". Rien d'urgent
+ceci dit.
+
+## Signature DKIM
+
+Signature faite par le serveur mail (redisdead au crans).
+
+Les mails envoyés par Re2o ne sont pas signés par DKIM, donc en
+principe "suspects" (mais mieux vaut pas signés que mal signés).
+
+Peut-être qu'un jour les Gafam (Gmail en tête) vont mettre en place des
+politiques plus strictes et les mails pas signés DKIM partiront par défaut en
+spam. Gênant. Pour l'instant c'est pas le cas. Sont concernés notamment les
+mailall annuels et les mails de confirmation d'inscription.
+
+Les mails ne sont pas signés DKIM quand ça passe par Redisdead et faudrait
+enquêter pour savoir pourquoi.
+Gitlab envoie des mails signés DKIM, Owncloud non (mais franchement, pour OC on
+s'en tape).
+
+Personne de présent n'est volontaire pour regarder ça en profondeur. bleizi
+propose la bouteille à la mer sur #roots (aled).
+
+Retour de la bouteille à la mer post réunion :
+
+* ''Au lieu que re2o envoie les mails lui même tu fais un nullmailer qui lui
+ dit que c'est un autre serveur qui envoie les mails ?'' (Otthorn)
+* ''la solution simple (et sale) c'est de faire du submission avec le compte de
+ root'' (shirenn)
+* ''l'autre c'est de dire à opendkim que quand les mails viennent de l'ip du
+ serveur de re2o il faut les signer'' (shirenn aussi)
+* ''Bah re2o pourrait pas juste avoir son propre compte mail et envoyer des
+ mails comme tout le monde ?'' (Mikachu)
+
+## Mails Zamok -> Redisdead
+
+Quand un mail arrive pour le Crans, il passe par Redisdead, normal. Puis ça
+passe par Zamok, qui stocke les mails des gens. Dans certains cas, les gens ont
+des .forward vers une adresse extérieure (serveur perso, Gmail, ça dépend). Ça
+fait beaucoup d'allers-retours. bleizi a oublié la conclusion de la réflexion,
+mais ça a l'air sous-optimal. C'est bien noté.
+
+Un des soucis : les headers s'empilent à chaque redirection.
+
+L'idée serait de faire en sorte que Redisdead, plutôt que Zamok, lise le
+.forward des gens.
+
+## Crans OID
+
+Le nom n'est pas le bon sur le lien (Stéphane Glondu, wouhou). Tout le monde
+s'en tape, GG.
+
+En fait non, bleizi réfléchie à changer les infos, mais il faudrait voir qui
+reçoit les mail sur oid-admin@crans.org
+
+## Point 'hosts'
+
+La génération du DNS est faite en regardant le LDAP et tous les trucs du LDAP
+sont dans ou=hosts.
+
+## Point SPF
+
+SPF = Standard policy framework. Sert à faire de la sécurité sur les mails.
+
+Principe : vérifier que le Mail From et le serveur qui envoie le mail sont les
+mêmes. Il paraît que les usurpations c'est pas bien.
+
+On peut donner au DNS (par le LDAP) la liste des serveurs qui ont le droit
+d'envoyer des mails au nom du Crans. À la fin tu peux mettre un "All" pour dire
+que tout le monde a le droit, un "-All" pour nier le droit et un "~All" pour
+dire "c'est pas normal, mais on laisse passer quand même".
+
+Pigeon trouve un "~All" dans un champ txt. Les seuls serveurs enregistrés pour
+le Crans sont Redisdead et Soputnik, mais pas Zamok.
+Dans le txt, il y a deux IPv4 et deux IPv6 (on suppose que c'est Redisdead et
+Sputnik). Les MX sont bien eux.
+
+Si on lit les headers d'un mail récent du Crans, genre celui que Pigeon envoie
+exprès à bleizi dans la minute, on peut s'apercevoir qu'il s'agit d'un mail de
+Q. De qanon@crans.org, pardon. Quand c'est signé DKIM, on lit pas les SPF parce
+qu'on fait confiance.
+
+bleizi poste un exemple d'analyse SPF venant de chez shirenn.
+
+{{{
+Authentication-Results: redisdead; spf=softfail (domain owner discourages use
+of this
+host) smtp.mailfrom=gmail.com (client-ip=REDACTED; helo=abys.se; envelope-from=shirenn@gmail.com; receiver=<UNKNOWN>)
+}}}
+
+Proposition de nouvelle politique : si fail (hardfail, pas softfail), alors
+drop le mail. Est-ce qu'on veut implémenter ça ? Débat. L'idéal serait de
+laisser passer le mail en informant les destinataires, mais
+
+* personne de normalement constitué (même pas au Crans) ne lit les headers de
+ ses mails;
+* scripter une modif du mail (type ajouter '[*** SPAM ***]' au début de
+ l'objet) c'est techniquement chiant à faire, donc flemme.
+
+Par défaut, on laissera passer les mails quand même. Plus tard, quand SPF sera
+plus répandu et/ou que les Gafam imposeront leur loi, peut-être qu'on changera
+d'avis.
+
+Pigeon et Aplanos proposent de ressusciter la Stasi en censurant a priori tous
+les mails. La motion est rejetée à l'unanimité.
+
+## Hosts.crans.org
+
+Ça héberge un Django en debug. Personne ne sait ce qu'il devrait y avoir à la
+place. Un ssh fait tomber sur Hodaur, mais c'est normal. On demandera à de
+vieilles nounous si elles savent. Il est probable que ce site ne serve à rien.
diff --git a/compte_rendus/2024_02_10.md b/compte_rendus/2024_02_10.md
new file mode 100644
index 0000000000000000000000000000000000000000..3d53f43fdbcfe6cccbcfdea0e493d0350231207a
--- /dev/null
+++ b/compte_rendus/2024_02_10.md
@@ -0,0 +1,126 @@
+# Réunion IN
+
+* Date : Samedi 10 Février 2024
+* Lieu : MB87 et Galène (https://galene.crans.org/group/CA)
+* Début : 15h17
+* Fin : 18h41
+
+## Présent⋅es
+
+* [[WikiBleizi|bleizi]]
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* !GaBo
+* [[DsAc|ds-ac]]
+* Chiaroush
+* [[WikiHachino|Hachino]]
+* [[Esum|esum]]
+* Korenst1
+* lzebulon
+* RDB
+* Milo
+* Emett
+
+### DNS et DNSSEC
+
+ds-ac fait une présentation aux apprenti⋅es en l'absence de shirenn
+
+### Mailman
+
+#### Spams
+
+On voit plus tard.
+
+#### Faux comptes
+
+Il y a apparemment des faux comptes, il faudrait peut-être les supprimer.
+Ce sont apparemment des non-membres.
+Ce sont des personnes ban donc il ne faut à priori pas les supprimer.
+
+#### Thème
+
+Le thème de mailman est cassé, il faudrait le changer/réparer.
+On demandera à Solal.
+
+### Belenios
+
+Il faut brûler la VM et réinstaller bélénios depuis 0.
+Ce n'est pas grave car il n'y a aucune donnée sauvegardée sur bélénios.
+
+### DANE
+
+ds-ac fait une présentation avec plein de trucs sur la sécurité des mails
+
+### ds-ac
+
+ds-ac fait une présentation rapide de tous ses points à l'ordre du jour.
+
+### systemd
+
+Re-centralisation des logs ?
+Il faudra demander à shirenn pourquoi la décentralisation des logs.
+
+### Ajout security.txt
+
+Après quelques minutes de discussion, on s'est accordé sur le fait qu'on
+ajouterait pas de security.txt (contrairement à internet.nl, google, amazon,
+...).
+## Je suis curieux d'entendre les arguments des 2 côtés, c'est possible de
+détailler ?
+Pour :
+
+* il serait possible de nous signaler des failles de manière standardisée
+
+Contre :
+
+* on a rien à offrir pour la découverte de nos failles (contrairement aux GAFAM
+ cités précédemment)
+* ça partage une/des adresses à un endroit facilement trouvable par des bots
+* si vraiment qq'un veut nous contacter, c'est pas si compliqué que ça de
+ trouver une adresse
+* ça demande un peu de travail à mettre en place
+
+### Mails
+
+(J'ai l'impression que ça casse toutes les heures à ce stade.)
+Petite explication par ds-ac de ce qu'est le smuggling, et de pourquoi c'est
+dangereux et comment ça a été réglé.
+Le problème n'est pas encore réglé sur zamok.
+
+### Gitlab
+
+On est ok pour installer les gitlab-pages. Ce sera fait dans quelques semaines
+avec des apprentiâ‹…eâ‹…s.
+Pour les runners, ça a l'air d'être bon d'une manière générale : pas besoin
+d'en rajouter.
+
+Nouvelle mise à jour : est-ce qu'on force le 2FA pour les admins (nounous) ?
+Globalement pour : ça a été activé.
+Finalement, on l'a désactivé, on en reparlera entre les nounous.
+
+### Infra de test
+
+Il faut un VLAN dédié pour :
+
+* ne pas avoir à s'inscrire dans l'infra de déploiement du crans quand on fait
+ une VM (LDAP, ...),
+* éviter que les VMs aient un accès à adm.
+
+NB : que faire des "home" nounous ?
+On mettra la VM apprentiâ‹…eâ‹…s dans ce VLAN de tests.
+
+### Mailman
+
+On interdit à tout le monde sauf à mailman et sputnik d'envoyer des mails pour
+lists.crans.org.
+
+#> ajouter "-all" Ã notre champ SPF (TXT lists.crans.org)
+
+### NixOS
+
+Pigeon Moelleux décrivait ce qui a été fait sur NixOS au Crans le mois dernier.
+Il a également été décidé que le git NixOS ne serait pas public.
+
+### Zero
+
+On mettra à jour le zero avec des changements gittés à partir du dépôt
+original en faisant des rebase pour mettre à jour.
diff --git a/compte_rendus/2024_03_02.md b/compte_rendus/2024_03_02.md
new file mode 100644
index 0000000000000000000000000000000000000000..c0080fdda29153a1916d4b275cfbb33b7702896f
--- /dev/null
+++ b/compte_rendus/2024_03_02.md
@@ -0,0 +1,101 @@
+# Réunion du Collège Technique
+
+* Date : Samedi 2 Mars 2024
+* Lieu : MB87 et Galène (https://galene.crans.org/group/CA)
+* Début : 13h37
+* Fin : 16h00
+
+## Présents
+
+* [[WikiBleizi|bleizi]]
+* !GaBo
+* [[DsAc|ds-ac]]
+* Chiaroush
+* [[VanilleNiven|vanille]]
+* Shinigami
+* [[WikiHachino|Hachino]]
+* Korenst1
+* [[WikiLzebulon|lzebulon]]
+* shirenn
+
+## Ordre du jour
+
+* Nouvelles nounous
+* Réparation de Cephiroth
+* Moyen de contact indépendant du Crans
+* Nombre maximum d'alias mail sur Re2o
+* Le Wiki n'affiche pas correctement certaines images
+* Question sur les patches Nix
+
+## Réunion
+
+### Nouvelles nounous
+
+Les membres suivants sont déterminés aptes à devenir nounous:
+
+* gabo
+* korenstin
+* lzebulon
+
+Cela sera officialisé à une occasion prochaine.
+
+### Cephiroth
+
+(Point soulevé par bleizi)
+
+Il y a de la casse, consulter l'égilibilité de la garantie.
+(facture sur tresorerie le 28/12/2022)
+
+### Moyen de contact
+
+(Point soulevé par bleizi, suite à un signalement adhérent)
+
+Particulièrement suite à une coupure de service indépendante de nous (problème
+technique chez Aurore) qui a rendu plusieurs services (dont les
+mails) indisponibles pendant un temps, un adhérent a émis une suggestion qui
+avait déjà été envisagée il y a longtemps: avoir une présence sur
+Facebook/Mastodon/assimilé pour annoncer de tels évènements lorsqu'il sont
+détectés et que nous n'avons pas eu le temps de les annoncer en avance.
+
+Plusieurs obstacles sont relevés, dont principalement le fait qu'avoir un tel
+compte nécessite pour qu'il soit utile que
+
+* les utilisateur.ices soient au courant de son existence
+* il y ait une activité fréquence (annoncer les autres évènements tels que
+ séminaires et install parties)
+
+Bref cela nécessite un investissement régulier.
+Le manque de motivation est jugé principal facteur bloquant et nous considérons
+que modulo une mise à jour l'existence de la page https://status.crans.org est
+une solution suffisante et beaucoup moins contraignante.
+
+### Nombre maximum d'alias
+
+(Point soulevé par bleizi, suite à un signalement adhérent)
+
+Reçue une plainte que le nombre maximum d'alias mail réservables par une
+personne (15) est insuffisant.
+Nous n'adhérons pas à ce point de vue, surtout parce que chaque alias est un
+point en moins disponible dans l'espace des pseudos valides.
+
+Si l'objectif est de pouvoir utiliser des adresses mail "jetables", une
+solution envisageable pour peu qu'un membre trouve le temps de l'implémenter
+serait de réserver un préfixe jetable, et par exemple garder le cap de 15 alias
+standards mais 1000 alias parmi les adresses qui commencent par "u_".
+
+### Chargement des images sur Wiki
+
+(Point soulevé par korenstin)
+
+Certaines images ne chargent pas.
+Le nombre est fixé mais les images spécifiques ne sont pas déterministes.
+Le problème est identifier comme venant du paramètre "burst limit" (défini dans
+nginx/sites-enabled/wiki pour faire face à un scraper), maintenant augmenté
+de 10 Ã 100.
+
+### Patches Nix
+
+(Point soulevé par ds-ac)
+
+En l'absence de personnes qui connaissent bien Nix, cette question est
+repoussée à la prochaine IN.
diff --git a/compte_rendus/2024_04_06.md b/compte_rendus/2024_04_06.md
new file mode 100644
index 0000000000000000000000000000000000000000..bd84536b1d2c395de08691f5a6fde4084c8789cb
--- /dev/null
+++ b/compte_rendus/2024_04_06.md
@@ -0,0 +1,97 @@
+# Réunion IN
+
+* Date : Samedi 06 Avril 2024
+* Lieu : MB87 et Galène (https://galene.crans.org/group/CA)
+* Début : 14h25
+* Fin : 17h27
+
+## Présent⋅es
+
+* [[WikiBleizi|bleizi]]
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* !GaBo
+* [[DsAc|ds-ac]]
+* [[WikiHachino|Hachino]]
+* lzebulon
+* shirenn
+* Vanille
+* [[WikiAeltheos|aeltheos]]
+* Shinigami
+* [[WikiShirenn|shirenn]]
+* [[WikiRDB|RDB]]
+
+## Cephiroth
+
+Ça a pas avancé.
+
+C'est toujours cassé, il ne boot pas du tout. Il faut le renvoyer en récupérant
+la carte réseau et les disques.
+
+## Miroirs
+
+Ils envoient des mails. C'est un problème logiciel : il faudrait augmenter une
+limite pour une fois, puis tout remarchera.
+
+## Ft
+
+Serveur de backup chez !ViaRezo : il est cassé. --(On)-- !GaBo va envoyer un
+mail.
+
+## Postfix
+
+Il faut mettre à jour postfix sur zamok et sputnik.
+
+NB : les settings par défaut fixent le pb de sécu mentionné il y a 3 mois (il
+faudra peut être retirer des options ajoutées en janvier).
+
+## Grafts
+
+Guix -> Grafts -> Gestionnaire de packages fonctionnel (ne dépend que des
+entrées déclarées).
+
+Pas besoin de world build en utilisant des caches -> on aura pas de maj (pas
+les substituts) pendant qq jours.
+
+## Unattended upgrades
+
+L'intégration dans Nix ne nous intéresse pas, car elle est faite pour gérer les
+paquet apt (et si on utilise apt, on est avec debian et pas avec NixOS).
+
+## Documentation
+
+IL FAUT FAIRE DE LA DOC.
+
+On héberge un wiki engine sur une VM NixOS.
+
+Projet apprenti/jeune nounou.
+
+Penser à faire un !HowToDocumentation (fait par Pigeon) avec un nombre maximal
+de caractères par ligne.
+
+## NextCloud
+
+Applications à mettre : Fichier, photo, activité, agenda, contact,
+audio-player, annonce, tache, onlyoffice (mais on a pas encore de backend)
+
+Applications pas à mettre (pour le moment, à demander à des
+utilateurices/vieux) : deck (kanban), cospend, notes
+
+## Matrix
+
+Aeltheos at Chiaroush veulent faire un projet apprentis sur Matrix avec
+NixOS -> OK, si il y a pas de pub du service et qu'il y a une documentation
+détaillée, plus pour voir comment faire et faire de la doc que d'avoir un
+nouveau service.
+
+## Faire pop des VM
+
+aeltheos essaiera de faire un script pour aller écrire dans le LDAP.
+
+Pigeon Moelleux se chargera de la documentation.
+
+## Mises à jour de sécurité sous NixOS
+
+Gitlab action qui met automatiquement à jour la flake ?
+
+On fera une VM qui build tous les dérivations nix et qui se chargera des remote
+build.
diff --git a/compte_rendus/2024_05_11.md b/compte_rendus/2024_05_11.md
new file mode 100644
index 0000000000000000000000000000000000000000..7a5469e81e970222c4916925aa965f3a91440b8c
--- /dev/null
+++ b/compte_rendus/2024_05_11.md
@@ -0,0 +1,99 @@
+# Réunion IN
+
+* Date : Samedi 11 Mai 2024
+* Lieu : MB87 et Galène (https://galene.crans.org/group/CA)
+* Début : 13h58
+* Fin : 16h25
+
+### Présent⋅es
+
+* [[WikiBleizi|bleizi]]
+* Chiaroush
+* [[DsAc|ds-ac]]
+* floflobouf
+* !GaBo
+* [[WikiHachino|Hachino]]
+* Korenst1
+* Otthorn
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* [[WikiShirenn|shirenn]]
+
+#### Discussion autour du DHCP
+
+Présentation de shirenn (merci !)
+
+#### Tiers listes de spam
+
+L'idée est de faire une tiers liste de spam.
+
+shirenn propose de le faire lorsqu'il y aura (enfin) un antispam
+
+#### Où sont les disques ?
+
+Il faudrait acheter des disques.
+Ça fait plus de 8 mois, faut se grouiller !
+Il faut juste transmettre la liste des références des disques à acheter.
+
+#### Fyre remplis beaucoup ces disques
+
+Disques pleins car logs ne sont jamais effacés. (actuellement ~250Go de logs et
+sauvegardes)
+
+Est-ce une feature ou un bug ?
+Ce qui pose la question : Est-ce qu'on ajoute des disques ou on corrige se
+problème ?
+
+Une limitation de taille disque à la taille actuelle du disque sera
+instaurée -> 200 Go.
+
+Ottorn et !GaBo s'en chargent juste après l'IN (<< c'est une seule ligne >>).
+
+#### Mail de rappel lors de la fin de l'adhésion
+
+Ce serait pratique !
+Il y avait un envoi de mail lors de fin de connexion mais pas en fin
+d''''adhésion'''. À Cachan adhésion == connexion mais ce n'est plus le cas.
+Donc on n'y avait pas pensé.
+
+Peut-être pas pris nativement. Si c'est pas le cas il faudra aller coder un
+truc.
+
+#### Appli mobile nextcloud et dossier pour les 30Go
+
+Il n'est pas (facilement) possible de se connecter à Nextcloud avec l'appli
+mobile. PigeonMoelleux règle le problème (en direct) -> Problème réglé
+
+Par défaut, le dossier courant ne peut contenir que 50Mo. Est-il possible de se
+placer dans le dossier de 30 Go ? Probablement pas faisable mais un README a
+été écrit par défaut pour expliquer ce qu'il faut faire. Qui lit les
+README ? Sur Nextcloud, le README est affiché en gros sur la page d'accueil.
+
+#### Ajout de SPF sur mailman && durcissement de la politique sur les fails
+
+On est actuellement cool sur les fails. (Un peu trop...)
+
+Le risque est qu'un serveur n'ayant pas mis un SRS pourrait drop un mail qui ne
+devrait pas l'être.
+
+Est-ce qu'on drop les mails qui échouent les SPF ?
+
+* pour Mailman -> les fails seront drop
+* pour Redisdead -> il y a déjà un en-tête pour dire que le mail à fail, et on
+ ne change pas ça pour le moment
+
+#### Retour sur NextCloud et OnlyOffice (ou collabora)
+
+Il y a un mois installation, Nextcloud a été déployé au crans mais il restait
+encore quelques configurations (il manquait encore autofs).
+
+Actuellement, il es possible d'utiliser agenda, calendrier... sur nextcloud
+mais il manque un éditeur de documents. Le quel installer ? Onlyoffice ou
+Colabora ? Telle est la question !
+
+Pas de différence a priori entre les deux (Collabora et onlyoffice sont
+compatible avec microsoft office et libre office).
+
+* Avantage de collabora : mis à jour plus rapidement (d'où l'utilisation Ã
+ Aurore)
+* Avantage d'Onlyoffice : continuité avec les services de l'ENS (qui utilise
+ aussi Onlyoffice)
diff --git a/compte_rendus/2024_09_22.md b/compte_rendus/2024_09_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..92dbb39567657426f8f9909e582a8bca9b831717
--- /dev/null
+++ b/compte_rendus/2024_09_22.md
@@ -0,0 +1,209 @@
+# Réunion IN
+
+* Date : Dimanche 22 Septembre 2024
+* Lieu : MB85 et Galène (https://galene.crans.org/group/CA)
+* Début : 14h34
+* Fin : 17h21
+
+### Participantâ‹…es
+
+* [[WikiAeltheos|aeltheos]]
+* [[WikiChiaroush|Chiaroush]]
+* DsAc
+* [[WikiGabo|GaBo]]
+* [[WikiHachino|Hachino]]
+* [[WikiKorenstin|korenst1]]
+* Louis
+* Lyes
+* [[WikiLzebulon|Lzebulon]]
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* [[WikiRDB|RDB]]
+* rigobert9
+* Sergey
+* Shinigami
+
+### Ordre du jour
+
+* [Lzebulon] Présentation rapide de l'infrastructure pour les nouvelleaux
+* [Lzebulon] Point sur l'avancement de la chronologie définie à la précédente IN
+* [ds-ac] Discussion Cybermois 2024 ou 2025
+* [Gabo]Organisation des Journée Federez
+* [ds-ac + Pigeon] discussion documentation
+* [ds-ac] relancer la discussion "serveur mail utilisable" vs. "arrêter les
+ spams et opérations de phishing"
+* [bleizi + aeltheos] Imprimante
+* [Pigeon] Problèmes disques
+* [Lzebulon] coupure des vacances de la Toussaint
+* [Pigeon] Vaultwarden
+* [ds-ac] proposition de modif séminaire : LaTeX + Typst + Texinfo
+
+## Présentation rapide de l'infrastructure pour les nouvelleaux
+
+Rapide présentation de l'infrastructure.
+
+Récapitulatif de ce qui a été présenté :
+
+Le crans est un fournisseur de services.
+Il occupe 2 salles : MB87 et SQ39 -> salle des serveurs
+
+Baie de serveurs :
+
+* serveur photos
+* serveurs au crans
+* partie louée à serv[ens]
+
+Les serveurs du crans :
+
+* cephirot (qui est actuellement pété)
+* thot (qui est actuellement pété)
+* cameron
+* baie d'hyperviseurs (sam/daniel/jack (adm) et stytch/gulp/olvyd(pété) (adh))
+* zamok
+
+Présentation de ssh (et zamok)
+
+Serveur PAS Ã l'ens :
+
+* Ã OVH
+* Ã viarezo (routeur-ft)
+
+## Récupération de serveur à Paris
+
+[[WikiAeltheos|aeltheos]] ou [[WikiLzebulon|Lzebulon]] demande les specs avant
+de prendre une décision lors de la prochaine IN.
+
+## point sur l'avancement de la chronologie définie à la précédente IN
+
+* les backups refonctionnent (et en particulier à Viarezo remarche)
+* Intégration : Succès
+* Onlyoffice : déployé mais on veut changer pour collabora
+* avancée de l'imprimante : Il semble qu'il y ait un switch (telco-sw-1) entre
+ les serveurs et la DSI. La DSI donne probablement les bons vlans à ce switch.
+ Mais le switch nous donne lui uniquement 2751 (renater) en UNTAG. Il faut
+ voir avec la DSI pour configurer ce switch.
+* cephiroth : Il faut acheter un nouveau contrôleur
+ SAS (cf [[/Dimanche22Septembre2024CA | CA]])
+
+## Discussion Cybermois 2024 ou 2025
+
+Proposer des événements de sensibilisation à la cyber sécurité ou à la bonne
+gestion des outils informatiques (pour tousâ‹…tes)
+
+L’évènement a lieu en octobre.
+
+2024 -> c'est un peu court
+
+2025 -> c'est possible
+
+L'événement pourrait être ouvert au personne extérieur. Il faudra demander Ã
+l'ENS.
+
+On peut enregistrer des événements qui sont partout en France.
+L'organisation sera à voir avec le nouveau bureau...
+
+Il faudra prévoir d'inviter des intervenant⋅es. Potentiellement demander à la
+présidente de l'April.
+
+On peut organiser des conférences, jeux, ateliers bref tout est possible.
+
+On peut demander à l'ENS pour valider de la diffusion des savoirs.
+
+## Organiser les journées federez
+
+Il faudrait trouver des logements et c'est compliqué, ou alors demander de
+l'aide de viarezo
+
+L'idée a été abandonnée.
+
+## Discussion documentation
+
+Rappel : Documentation imprécise et lacunaire. Donc projet de refonte de la
+documentation.
+
+#> v2 de la doc https://gitlab.crans.org/nounous/documentation/
+
+Proposition de ds-ac :
+
+* faire une grosse page de documentation avec des cross reférences (possibilité
+ de faire plusieurs fichiers mais les cross références sont meilleures
+ lorsqu'il y a tout dans le même fichiers).
+* c'est du .texi (Texinfo)
+* génération d'une table des matières
+* différent de markdown mais pas plus compliqué
+* possibilité de faire des références vers d'autres manuels
+
+ds-ac va créer une autre branche avec la documentation en texi
+
+But documentation : lisible avec bat, cat, less
+
+PigeonMoelleux propose la création d'une documentation à destination des
+utilisateurâ‹…ices pour expliquer par exemple comment synchroniser des
+calendriers, connecter sont compte crans avec thunderbird.
+Proposition d'utiliser mdmux pour cela.
+
+Pour de la doc jolie :
+
+Proposition pour faire un wiki comme Aurore (https://wiki.auro.re/fr/tech)
+
+autre proposition de ds-ac -> quarto
+
+Licence Creative Commons ou BY-NC-SA (peut être sans NC)
+
+## relancer la discussion "serveur mail utilisable" vs. "arrêter les spams et
+opérations de phishing"
+
+Le serveur mail du crans c'est une passoire à spam
+ds-ac propose d'être plus restrictif en applicant les conditions de google
+
+Est-ce qu'on devient plus restrictif ? (typiquement les mails qui sont de nous
+à nous même)
+
+drop les mails ou créer un dossier spam :
+
+* dossier spam est plus difficile à mettre en spam
+* soit taggé
+
+il faudra annoncer au gensâ‹…tes que les mails sont potentiellement frauduleux.
+
+Lyes et ds-ac vont s'en occuper.
+
+## Problèmes disques
+
+Jack a été changé
+
+Tealc ne râle plus depuis qu'aeltheos s'en occuper
+On a encore des erreurs smartctl et des pools zfs bloquées
+
+Gabo va incessamment sous peu acheter des disques de secours et un contrôleur
+SAS.
+
+* achat de câble de SATA
+* acheter qch qui peut faire du SAS
+
+## coupure des vacances de la toussaint
+
+Tealc ne va pas bien, les serveurs n'ont pas été redémarrés pendant l'été et le
+câble management est vraiment à refaire...
+Il faut redémarrer les serveur soit couper le crans pendant 2 jours
+
+## Vaultwarden
+
+De nombreuses personne demandent si le crans propose des gestionnaires de mots
+de passe.
+Bitwarden et Vaultwarden sont les deux self-hostés.
+Héberger cela pose des question de sécurité...
+
+* Le crans deviendrait une source plus intéressantes d'attaque
+* Si on le fait, on ne fait pas de récupération et on a un audit (non officiel)
+* Si une personne perd son master password, elle ne pourra pas récupérer ses
+ mdp, et on le dit clairement
+
+Le crans va l'implémenter avec nixos / ansible
+
+## Proposition de modification des séminaires : LaTeX+Typst+Texinfo / ajouter
+séminaire QUIC?
+
+Il y a déjà séminaire LaTeX et Typst
+ds-ac propose de faire un séminaire texinfo (en séminaire interne)
+ds-ac propose aussi de faire (ou d'encadrer) un séminaire QUIC (au second
+semestre)
diff --git a/compte_rendus/2024_11_16.md b/compte_rendus/2024_11_16.md
new file mode 100644
index 0000000000000000000000000000000000000000..2973ee297f2bf63a51fa95e8fafba2e2d98c2900
--- /dev/null
+++ b/compte_rendus/2024_11_16.md
@@ -0,0 +1,354 @@
+# Réunion IN
+
+* Date : Samedi 16 Novembre 2024
+* Lieu : MB85 et Galène (https://galene.crans.org/group/IN)
+* Début : 14h34
+* Fin : 17h21
+
+### Participantâ‹…es
+
+* [[WikiBleizi|bleizi]]
+* Emett
+* [[WikiGabo|GaBo]]
+* korenst1
+* Lzebulon
+* Otthorn
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* Rigobert
+
+### Ordre du jour
+
+* [Pigeon] trier l'ordre du jour (avec un tri topologique)
+* [Lzebulon] (on est plus à un point pret) viarezo, on doit reconnecter je
+ crois ->^? sfp
+* [Hachino] (Possiblement HS) Problèmes d'envois de la ML Événements vers
+ certains domaines (<Robin>@laposte.net et <Clara>@gmx.fr). Réputation mail ?
+* [Lzebulon, korenstin] sudo apprentiâ‹…eâ‹…s sur machine apprenti
+* [Pigeon] Possible sans trop de soucis mais il faut alors pas monter les
+ home_nounous -> le but était justement de discuter de ce point ! (genre
+ ajouter dans ansible une exception à la vm apprenti pour dire "bah non en
+ fait... on ne veut pas les home_nounous")
+* [Hachino, 30 oct. 10h30] Nextcloud est encore plus lent que d'habitude, au
+ point qu'il n'est pas arrivé à ouvrir un dossier < 5 Mo avec une dizaine de
+ PDF. Owncloud idem est devenu super lent (mais il sert tous les fichiers).
+ Sur OC, quand je lis un PDF dans le navigateur et que je fais "retour", je
+ suis renvoyé dans mon /home au lieu du dossier courant. EDIT : tiens, une
+ heure plus tard ça semble un peu plus fluide et l'erreur de retour a disparu ?
+* augmenter le nombre de cpu/ram de la vm + augmenter le nombre de
+ pm.children_max (php-fpm) ?
+* [Lzebulon] nettoyage de zamok : virer podman ? autres trucs ? possibilité de
+ faire un sondage pour savoir ce que les adhérent.e.s ont besoin pour virer ce
+ qui est inutile ?
+* [Pigeon] nix sur zamok ? (Pas NixOS, juste le package manager)
+* [Pigeon] Documentation adh : docmost ?
+* [Lzebulon] update etherpad : 1.8.18 -> 2.2.6 ? (breaking changes
+ https://github.com/ether/etherpad-lite/releases/tag/v2.0.0 : npm -> pnpm)
+* [Lzebulon] comment ca fonctionne policyd-rate-limit/comment debug quand
+ quelqu'un se plainds
+* [Lzebulon] (peu important) redite.crans.org semble cassé (mais j'ai pas
+ regarde) -> redite n'est qu'une vm pour présenter nixos à des anciens
+ apprentis (merci aeltheos d'ailleurs !)
+* [Lzebulon] Blackbox probe failed souvent sur owncloud
+* [Lzebulon] onlyoffice est cassé je sais pas pourquoi
+* [bleizi] SPF fail
+* [Lzebulon] si zamok est down/postfix mal monte, et redisdead est up -> perte
+ de mail ? : possibilite de se passer de zamok pour la reception des
+ mails ? (comme c'est le cas pour nextcloud)
+* [Pigeon] getty@ttyS0
+* [Lzebulon, korenstin] Point imprimante
+* [Hachino] Charlie dit qu'on ne peut pas envoyer plusieurs fichiers Ã
+ l'imprimante et les faire imprimer en une fois.
+* [aeltheos, lzebulon] serveurs à paris
+* [Lzebulon] je ne sais pas à quoi fait référence ce point -> il y a ~1 mois
+ qn (sur le discord med surement) à transmis un msg à propos de la
+ disponibilité (par un don) de serveur d'une certaine asso. Le but était que
+ qn les contacts (toi ou aeltheos) pour demander les specs
+* [Hachino] Jitsi semble bien cassé : je viens d'essayer de faire une visio
+ avec quelqu'un et chaque fois que l'un rentrait, l'autre était déconnecté. En
+ boucle. On a fini par utiliser celui d'Aurore à la place.
+* [korenstin] les scripts python ne possèdent pas de requirements et ne sont
+ pas dans des venv
+* [korenstin] Point ansible ?
+* [korenstin] Que fait on de trinity ?
+ * [Pigeon] Installation Matrix prochainement ? Debian ou NixOS ?
+ * Même question (cà d que fait-on de ... ?) pour les vms inactives sur
+ proxmox (éteinte) ? tealch, kameron, otter, daneel, listenup, gougle,
+ ceph{0, 1, 2}, test-debian-postfix (x2), aeris
+ * Suppression dans le ldap ? (constellation-dev, dsi??, excalibur, horst,
+ idrac-zbee, ilo-charybde, karst, passerelle, rodney, zephir)
+* [korenstin] Organisation des machines (physiques et virtuelles) dans la
+ documentation (qu'est-ce qu'on met ? qu'est-ce qu'on ne met pas ? fichiers Ã
+ part ? tout dans le qui est qui ?)
+* [Pigeon] Indiquer dans la doc quelles VM/machines on peut redémarrer sans
+ causer d'apocalypse
+* [lzebulon, pigeonmoelleux, korenstin] ft ne marche toujours pas... pas de
+ doc, imcompréhensible
+ aka : pour se connecter à routeur ft il faut passer par backup ft...,
+ certaines machines ping ft mais pas toutes et pas toujours
+* [Pigeon] Présentation restic
+* [Pigeon] l'ipv6 ne fonctionne pas sur thot
+
+### trier l'ordre du jour (avec un tri topologique)
+
+Pigeonmoelleux s'est amusé !
+
+### (on est plus à un point pret) viarezo, on doit reconnecter je
+crois ->^? sfp
+
+Tout fonctionne, le vlan passe.
+VR -> pb avec le switch et depuis et il y a eu des pb.
+on verra quand on aura de nouveau SFP
+
+### (Possiblement HS) Problèmes d'envois de la ML Événements vers certains
+domaines (laposte.net et gmx.fr). Réputation mail ?
+
+L'une des personnes en question n'était pas inscrite sur la ML et la poste est
+sensible.
+
+### sudo apprentiâ‹…eâ‹…s sur machine apprenti
+
+Le but de la VM c'est de permettre le sudo pour les apprentiâ‹…es
+Cependant les home_nounous sont montés.
+Les home_nounous sont à démonter et la vm n'aura plus de backup borg à cause
+d'une clé ssh
+
+Pour les hash des mots de passe dans /etc/shadow : on va leur faire confiance
+pour ça (en faite il n'y a que le mot de passe root).
+
+Sinon, mettre un autre mot de passe root root
+
+### Nextcloud est encore plus lent que d'habitude, au point qu'il n'est pas
+arrivé à ouvrir un dossier < 5 Mo avec une dizaine de PDF. Owncloud idem est
+devenu super lent (mais il sert tous les fichiers). Sur OC, quand je lis un PDF
+dans le navigateur et que je fais "retour", je suis renvoyé dans mon /home au
+lieu du dossier courant.
+
+Nextcloud est lent, mais plus que d'habitude ?
+Le nombre de php a été augmenté sur Owncloud.
+Sinon, peut-être qu'il faut augmenter la RAM, le stockage...
+
+ou alors encourager à utiliser des alternatives (dav, ou autre client)
+
+### nettoyage de zamok : virer podman ? autres trucs ? possibilité de faire un
+sondage pour savoir ce que les adhérent.e.s ont besoin pour virer ce qui est
+inutile ?
+
+retirer des outils qui sont encore là comme podman qui semble utilisé par
+personne (qui était utilisé par ynerant et erdnaxe)
+
+Erreur systemctl : prometheus, dhcp-server, postfix, smartmontools n'ont pas
+d'user configurer (probablement à cause de la coupure)
+
+On ne sait pas pour smart, isc.
+
+### nix sur zamok ? (Pas NixOS, juste le package manager)
+
+Tout le monde pourrait installer n'importe quoi (dans /nix/).
+Il faudrait donc augmenter la mémoire (qui a 250 Go de disponible et qui a des
+disques libres). On peut ajouter un disque pour /nix et nix optimize/garbage
+régulièrement)
+Soit :
+
+* /nix est local sur zamok -> juste pour zamok (sur cameron) et un pour le
+ reste du crans
+* /nix commun pour le crans (risquer)
+
+Pas d'opposition ferme
+
+### Documentation adh : docmost ?
+
+Facile à écrire (exemple config pour thunderbird).
+on continuera à chercher plus tard (ne prend pas en charge l'interconnexion
+avec le ldap).
+Pas de connexion nécessaire pour lire la doc.
+Import possible avec le markdown.
+
+Un certain nombre de demande pour découvrir les différents services du crans
+avis mitigé...
+
+### update etherpad : 1.8.18 -> 2.2.6 ?
+
+Il y a une version majeure d'écart...
+Est-ce que la migration se passe bien -> ça à l'air... (pas l'air d'y avoir de
+breaking change)
+Comment s'est installé et on met à jour ? -> le repo est clone depuis le github
+de etherpad.
+
+### Comment ça fonctionne policyd-rate-limit/comment debug quand quelqu'un se
+plainds
+
+Permet de limiter nombre de mails envoyés.
+Il vérifie que les utilisateurs n'otn pas atteint un quota (par IP et user)
+
+Il y a aussi une limite dans postfix
+policyd-rate-limit -> possède une db on sait pas où
+
+si qn se plaint, on ne fait rien, ça partira en 24h
+(envoyer un mail à PEB)
+
+### (peu important) redite.crans.org semble cassé (mais j'ai pas regarde)
+
+Ça marche très bien ! point suivant.
+
+### Blackbox probe failed souvent sur owncloud
+
+On sait pas pk, on sait pas ce que c'est.
+C'est quand on utilise un service et qu'il renvoie une erreur 502 (comme
+nextcloud, roundcube, ownloud, wiki)
+
+ -> c'est un exporter prometheus qui peut servir à ça mais aussi d'autre chose
+
+### onlyoffice est cassé je sais pas pourquoi
+
+Ça ne marche plus...
+Le lien symbolique (pour nginx) avait disparu...
+
+### SPF fail
+
+On peut se dire qu'on drop les mails qui fail
+
+Est-ce qu'on accepte ou refuse les hard et/ou soft fail ?
+Si soft fail : on doit le laisser passer sauf si on a un autre critère de rejet
+Si hard fail : on peut les bloquer (mais pas obligé)
+
+Proposition en cas de SPF fail :
+
+* sur redisdead, on augmente le score de spam s'il y a un anti spam, sinon on
+ fait rien
+* sur mailman, on installe SPF, on drop le mail en cas de fail (mais pas de
+ soft fail)
+
+redisdead : les mails sont rejetés si sans nom de domaine associé,
+score > 4 byebye (c'est pas clair)
+
+### Si zamok est down/postfix mal monte, et redisdead est up -> perte de
+mail ? : possibilité de se passer de zamok pour la réception des mails ? (comme
+c'est le cas pour Nextcloud)
+
+On perd des mails
+redisdead essaye d'écrire sur zamok et donc, si les disques sont inaccessibles,
+on perd des mails.
+La raison était de pouvoir avoir ses propres filtres de mails
+
+Sinon faire le filtre sur direct sur redisdead.
+Il ne devrait pas perdre des mails quand même si zamok est down.
+
+Le problème vient probablement du serveur mail de zamok...
+
+Juste faire attention quand on redémarre
+
+Rajouter un ordre dans l’exécution dans systemctl ?
+D'où vient le pb de montage ?
+dire à postfix d'écrire dans un autre dossier si inaccessible
+On attend ceph
+
+### getty@ttyS0
+
+Ça fail bcp et un problème de droit encore (visiblement)
+
+### Point imprimante (ca refonctionne (merci aeltheos et lzebulon) mais pas la
+couleur (rien de nouveau -> si le scan !))
+
+Ça marche, juste pas le magenta (problème avec la buse magenta)
+Si on veut de la couleur on peut essayer de refaire fonctionner l'autre
+imprimante -> Otthorn ne pense pas, il y avait le pb avec le finisher,
+software, contrat avec HP et encres hyper chères. C'était une machine à gaz.
+
+### On ne peut pas envoyer plusieurs fichiers à l'imprimante et les faire
+imprimer en une fois.
+
+Le site a été développé vite et mal, il peut être intéressant de le dev
+mieux.... (c'est pas urgent)
+
+### serveurs à paris
+
+pas contacté
+
+### Jitsi semble bien cassé : je viens d'essayer de faire une visio avec
+quelqu'un et chaque fois que l'un rentrait, l'autre était déconnecté. En
+boucle. On a fini par utiliser celui d'Aurore à la place.
+
+pigeonmoelleux semble avoir résolu le problème.
+Jitsi n'est pas à jour...
+c'est sur apt -> probablement des breaking change
+
+### les scripts python ne possèdent pas de requirements et ne sont pas dans des
+venv
+
+Les scripts ont cassé car ni venv ni requirements.
+On peut le faire mais probablement la flemme.
+
+### Point ansible ?
+
+Pas d'apprentiâ‹…es
+
+### Que fait on de trinity ? et d'autre vm
+
+Trinity, on garde
+
+Même question (cà d que fait-on de ;
+
+* tealch
+* kameron
+* otter
+* daneel
+* listenup
+* gougle
+* ceph{0, 1, 2} (potentiellement on garde)
+* test-debian-postfix (x2)
+* aeris
+* one
+
+On demande à ds-ac pour savoir si on peut les brûler
+
+Suppression dans le ldap ?
+
+* constellation-dev
+* zamok-tmtc -> supprimer
+
+dsi -> il faut se renseigner
+
+### Organisation des machines (physiques et virtuelles) dans la
+documentation (qu'est-ce qu'on met ? qu'est-ce qu'on ne met pas ? fichiers Ã
+part ? tout dans le qui est qui ?)
+
+Pas ansible
+
+vlan, suffixe IP=ID
+
+Indiquer les machines que l'on peut redémarrer sans problème.
+
+Fichier à part détailler pour les machines physiques.
+
+On met dans le pad IN les trucs qui ont été fait en quatrième vitesse/non
+documenter/pas ansible/pas de nixos
+
+### ft ne marche toujours pas... pas de doc, imcompréhensible
+
+Plus de backup actuellement :
+thot : pb de boot, disque, on a tout réinstaller sur nixos (avec restic)
+ft : ne marche plus depuis qu'il est revenu (depuis VR) (avec borg)
+
+ft ne répond plus.
+VR a éteint ft sans nous le dire. Tout a été relancé et tout refonctionnait. VR
+ré-éteint ft. ft a été ramené chez nous.
+Pb chez nous, ça ne refonctionne pas et c'est incompréhensible.
+
+Sur ft, il a 2 vm (proxmox) routeur-ft, backup-ft.
+routeur-ft a un vpn vers boeing. On ne comprend rien au fonctionnement.
+On ne sait pas régler le problème.
+
+On dit : on supprime proxmox et vm, on met tout sur ft
+
+Si on devait réinstaller ft, on aura pas besoin de tout réinstaller.
+On garde backup-ft mais on supprimer routeur-ft
+
+où on met ft ? peut être pas à VR
+
+### Présentation restic
+
+Thot ne supporte pas l'uefi et on a installé uefi
+Restic et borg sont des bakcups incrémentales. Plus de détail dans la
+documentation.
+
+### L'ipv6 ne fonctionne pas sur thot
diff --git a/compte_rendus/2024_12_15.md b/compte_rendus/2024_12_15.md
new file mode 100644
index 0000000000000000000000000000000000000000..b712c7eb7520079699668cba3b689c6f4288bf50
--- /dev/null
+++ b/compte_rendus/2024_12_15.md
@@ -0,0 +1,115 @@
+# Réunion IN
+
+* Date : Dimanche 15 Décembre 2024
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
+* Début : 14h14
+* Fin : 15h10
+
+### présent⋅es
+
+* [[WikiBleizi|bleizi]]
+* WikiPigeonMoelleux
+* korenst1
+* Hachino
+* Igolta
+* Lyes
+* Lzebulon
+
+## ordre du jour
+
+* high availability proxmox pour les services importants : residead, ecilis,
+ romanesco, les ldaps, les db (quand elles seront sur vm), autres ?
+* les backups sous restic sont déployées sur toutes les machines (debian)
+* A quoi servent les disques durs dans l'armoir ?
+* ft est de nouveau joignable
+* disque dur de daniel changer
+* apprentix et livre déployer
+* hijacking d'un des deux kanban dispo sur le gitlab ou création d'un nouveau
+* je sais plus si on en a parlé : mirror repo nixos sur git2
+* archivage de certains repo : Ghostream, django-webnews, bcfg2
+* Matrix
+
+### les backups sous restic sont déployées sur toutes les machines (debian)
+
+Il n'y a pas assez de place pour backuper le cameron. il faut passer en
+raidz2 (car l'un des emplacements disques est cassé).
+
+Pas backuper :
+
+* kiwi : crashe tout le temps (pb de version probablement)
+* re2o-dev : c'est pas grave
+
+Prune semble ne pas fonctionner : Ã debugger
+
+### Matrix
+
+Trinity possède synapse.
+
+Opération :
+
+* déplacer synapse sans perte de données
+
+2 types de connexion :
+
+* LDAP du crans
+* Oauth2 avec la note (peut-être conflits)
+
+Si conflit : mettre pseudo note_[pseudo] ou _[pseudo]
+
+### A quoi servent les disques durs dans l'armoir
+
+Les disque sont (normalement) shred et peuvent être compatible avec les
+serveurs (et utilisable, voire donnable).
+
+### Disque dur de daniel changer, changement pool en ashift 12
+
+Changement des pool en ashift 12 -> plus tard
+
+### apprentix et livre déployés
+
+Il y a un problème de config nixos. Il faudra faire une pull request sur github
+
+### ft est de nouveau joignable
+
+Ça marche ! (La configuration des VLAN était différente entre les switchs
+Arceus et Carapuce)
+
+Il est temps de décider de déplacer des backups à l'extérieur.
+
+Il faudrait changer le ventilos sur ft.
+
+### High availability proxmox pour les services importants (attendre ceph ?)
+
+Est-ce qu'on le setup pour : redisdead, silice, romanesco, hodaur, les ldaps,
+les db (quand elles seront sur vm), autres ?
+
+Les db sont sur des machines physiques (tealc en théorie)
+
+Les ldaps sont déjà répliqué (sur toutes les machines physiques).
+
+Demander à Aeltheos pour ce qui est de ceph.
+
+### Hijacking d'un des deux kanban dispo sur le gitlab ou création d'un
+nouveau
+
+Création d'un kanban pour suivre ce qu'il y a à faire au crans et suivre
+l'avancement.
+
+### mirror le repo nixos sur git2
+
+OUI !
+
+### archivage de certains repo
+
+Archiver :
+
+* Ghostream
+* django-webnews
+* bcfg2
+
+### imprimante encres
+
+Réferences :
+
+* encres : https://www.tonerpartenaire.fr/lexmark-x-952-series/Alternative-Lexmark-X950X2KG-Toner-noir.html
+* waste : https://www.tonerpartenaire.fr/c950x76g/Original-Lexmark-C950X76G-Collecteurs-de-toner.html
diff --git a/compte_rendus/2025_01_19.md b/compte_rendus/2025_01_19.md
new file mode 100644
index 0000000000000000000000000000000000000000..f1bac65d0308d835c57e69bad10ce527e599e87a
--- /dev/null
+++ b/compte_rendus/2025_01_19.md
@@ -0,0 +1,105 @@
+= Réunion IN =
+
+* Date : Dimanche 19 Janvier 2025
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
+* Début : 17h30
+* Fin : 18h45
+
+=== présent⋅es ===
+
+* antonin
+* [[WikiBleizi|bleizi]]
+* Chiaroush
+* ds-ac
+* Gabo
+* korenst1
+* Lzebulon
+* Lyes
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* viadezo1er (Président de Federez, ancien de ViaRézo)
+
+=== Ordre du jour ===
+
+* podman fail, que fait-on ? suppression ?
+* centralisation de la configuration du dns (dans le LDAP)
+* ferle (VM a disposition du RIPE) est éteinte et grub panic quand elle demarre
+* borgmatic plante régulièrment à cause de ProtectSystem=full
+* spamassassin : semble configurer pour chaque utilisateurâ‹…ices -> pourrait-on
+ proposer une configuration par défaut ?
+* Déploiement nouvelle infrastructure Matrix
+* vulnérabilité rsync sur mirror ?
+* le kanban mentionné à la dernière IN est en place
+* quels sont les conditions pour une alternative à moinmoin...
+* sops -> agenix
+* Serveur de build Nix
+
+== Podman ==
+
+Déjà désinstallé
+
+== Centralisation du DNS ==
+
+Le DNS est configuré dans le LDAP adh et adm (les deux à la fois). Dans le LDAP
+adm, les alias des VMs définis à plusieurs endroits (notamment hodaur).
+
+On range mieux + [faire de la documentation](https://gitlab.crans.org/nounous/documentation/-/issues/13)
+
+== ferle ==
+
+VM à disposition du RIPE. Elle grub-panic lorsqu'elle démarre. Il faudrait les
+contacter par mail / voir dans leur documentation si on peut réinstaller la VM.
+
+Pigeon Moelleux est délégué pour s'en charger.
+
+== Borgmatic ==
+
+Crash de borgmatic à cause de l'option systemd ProtectSystem=full.
+Modifier le fichier directement poserais des problèmes lors des mises à jour de
+borgmatic. Il est possible de créer un nouveau fichier systemd dans /etc pour
+overwrite la configuration.
+
+== Spamassassin ==
+
+Configuration par utilisateurice -> on valide et on met un message indiquant de
+la documentation.
+
+== Vulnérabilité rsync sur tealc ==
+
+On est pas impacté car on a une version antérieure à celle mise en cause.
+Il faudrait mettre tout à jour, mais ça demanderait de tout redémarrer.
+
+== Matrix ==
+
+Ça avance (déploiement très prochainement).
+
+== Kanban ==
+
+Meilleure visibilité de ce qu'il y a à faire au Crans
+(https://gitlab.crans.org/nounous/kanban/)
+
+== Wiki ==
+
+Moinmoin -> python 2 donc on aimerait migrer
+Quels sont les critères à remplir pour une potentielle migration sur un autre
+service ?
+
+== Gestion des secrets sur NixOS ==
+
+Age -> SSH / Sops -> GPG
+Age -> plus simple à configurer
+On passe sur age -> on mettra les clefs SSH des gens qui veulent.
+
+== Serveur de build nix ==
+
+On va checker Hydra (https://wiki.nixos.org/wiki/Hydra).
+On fera une VM un peu boostée.
+
+== Zero bin ==
+
+Zero a été mis à jour par ds-ac.
+Enfin assez mal : le template est à revoir.
+
+== belenios ==
+
+Déjà packagé en nix par Lzebulon
+Lyes s'est porté volontaire pour faire le service systemd.
diff --git a/compte_rendus/2025_02_22.md b/compte_rendus/2025_02_22.md
new file mode 100644
index 0000000000000000000000000000000000000000..99507d69e280256cfacf96ce9cb7eb507d05f339
--- /dev/null
+++ b/compte_rendus/2025_02_22.md
@@ -0,0 +1,192 @@
+= Réunion IN =
+
+* Date : Samedi 22 Février 2025
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
+* Début : 16h
+* Fin : 18h30
+
+=== Présent⋅es ===
+
+* [[WikiBleizi|bleizi]]
+* Chiaroush
+* Erdnaxe
+* Gabo
+* Hachino
+* korenst1
+* Lyes
+* Ohime
+* [[WikiPigeonMoelleux|Pigeon Moelleux]]
+* [[WikiRDB|RDB]]
+
+== Ordre du jour ==
+
+* Quie faire de vieilles ML ? 25ans@, respbats@ ? Brûler ?
+* suppression de rsyslog
+* AptObsolete, que peut-on supprimer dans les packets en question ?
+* Qemu-guest-agent (option non activée sur de nombreuses vm mais le paquet est
+ installé sur toute), au prochain redémarrage, les activons-nous ?
+* getty@ttyS0 fail car on n'a pas rajouté les ports séries dans l'interface de
+ proxmox (les rajouter au redémarrage des serveurs / nixos)
+* openipmi fail sur routeur-daniel, mais ne semble pas installé sur sur
+ routeur-jack et routeur-sam... pourquoi ? doit-on le désinstaller ? (question
+ similaire pour hodaur, ce n'est pas dans ansible)
+* retour sur le problème serveur du 11 février
+* Rachat de nouveaux serveurs ? Un Gen10 se trouve à 400-600 € pièce et les Gen8
+ du Crans datent de 2012-2015.
+* MAJ de Nextcloud -> passage sur NixOS pour que ce soit plus simple à maintenir
+ ou on reste sur debian ?
+* Setup d'un serveur de build pour NixOS
+* Fin de mise en place Matrix -> Il y a un problème dans la précédente
+ configuration du bridge, que fait-on ?
+* Remettre en marche Belenios avant l'AG BDE ?
+* wiki (historique de modification)
+* excalidraw
+
+=== Que faire de vieilles ML ? 25ans@, respbats@ ? Brûler ? ===
+
+La ML respbats pourrait être encore utilisée de rare fois.
+
+Pour 25ans, la décision est de conserver les mails mais de drop tout les
+nouveaux mails. Pour respbat, on ne change rien (ou alors suppression des
+ancienâ‹…nes responsables).
+
+=== suppression de rsyslog ===
+
+Aujourd'hui, on n'utilise plus rsyslog mais on utilise journald. Si rsyslog est
+utilisé quelque part, on peut remplacer par journald.
+
+=== AptObsolete, que peut-on supprimer dans les packets en question ? ===
+
+On a des logs sur roots/logs de services qui se plaignent de services qu'ils ont
+des paquets installés orphelins/obsolete.
+
+Sur Galène, il y a avait probablement un paquet orphelin qui servait à quelque
+chose. On peut donc les supprimer et si ça casse quelque chose, on réparera.
+
+Erdnaxe signale que orphelin signifie plus de source APT. Il dit qu'il faut
+faire gaffe avant suppression à ce que ça ne soit pas "juste" une source APT
+virée quelque part. (Exemple avec Docker : ajout source, apt install docker,
+virer source et Docker devient orphelin, pourtant on a pas envie de le
+supprimer.)
+
+=== Qemu-guest-agent ===
+
+qemu-guest-agent est un logiciel qui permet une communication entre proxmox et
+la vm et remonter des métadonnées (usage CPU, etc). Cependant, Il s'agit aussi
+d'une back door car permet l'execution de commande en root.
+
+Puisqu'il s'agit d'une fail de sécurité, on désactive l'option sur promox et on
+le retire de ansible.
+
+=== getty@ttyS0 fail ===
+
+ttyS0 permet d'avoir un terminal série sur proxmox typiquement un terminal avec
+copier-coller.
+
+On le rajoute lors du redémarrage des serveurs sur toutes les vm et sur nixos.
+
+=== openipmi fail ===
+
+Ce serait une dépendance de exporter-prometheus.
+S'il n'a pas de dépendance, on peut supprimer le paquet.
+
+=== Retour sur le problème serveur du 11 février ===
+
+Il y a eu des erreurs avant mais un crash est arrivé le 11 février vers 15h
+(Wiki a eu un bug). Les serveurs ont été utilisé à 100%. Tealc a visiblement eu
+un problème de cpu et ne répondait plus. Toutes les vms attendaient tealc qui ne
+répondait pas.
+
+Après discussion, les serveurs ont été poweroff ou éteint violemment. Lors du
+redémarrage, sam a refusé de redémarrer à cause de 2 ventilateurs
+dysfonctionnels qui ont donc été changés.
+
+=== Rachat de nouveaux serveurs ? ===
+
+L'infra du crans est viellissante et on a l'argent. Proposition d'achat de
+nouveau serveur pour renouveler l'infra/avoir un serveur de secours. Pour les
+vielles versions, les pièces sont moins chères.
+
+Les gros ssd commencent à être rentables.
+
+Des études seront menées afin de déterminer le budget et la procédure qui sera
+suivie pour la transition. (visiblement 100€ pour un ssd de 2 To)
+
+=== MAJ de Nextcloud -> passage sur NixOS ou on reste sur debian ? ===
+
+Nextcloud a quelques(=2) mises à jour majeure de retard. Nextcloud est
+actuellement sur debian mais c'est pénible à mettre à jour et installer à la
+main. Sur nixos, les mises à jour sont beaucoup plus simple.
+
+Soit on ne fait pas les mises à jours (mauvaise idée), soit on ansibelise, soit
+on passe sur nixos.
+
+Sur nixos, on peut copier-coller la configuration de debian.
+
+Plus agréable vs plus sécurisé ? Si des personnes sont intéressés, on peut
+mettre en place de l'OIDC
+
+Projet apprentis :
+
+* pour uniformiser la page d'identification.
+* script de mise à jour ou passage sur nixos ?
+
+Le passage sur nixos est privilégié.
+
+La migration sera effectué lorsqu'il y aura des apprentis et des gens motivés
+
+=== Setup d'un serveur de build pour NixOS ===
+
+On peut mettre le serveur de build sur cephiroth directement (pas sur des vm).
+Le serveur de build permettra d'optimiser les build en ne recompilant pas tout
+et en utilisant la puissance de calculs sur le serveur de build.
+
+Proposition d'utiliser hydra et cachix. Alternative, dire au serveur de rebuild
+la conf d'un autre serveur, dans ce cas rien à faire à part de la doc
+(pigeonmoelleux s'en chagre).
+
+=== Fin de mise en place Matrix -> Il y a un problème dans la précédente
+configuration du bridge, que fait-on ? ===
+
+2 choses à mettre en place :
+
+* client web (element)
+* connexion en OIDC par note kfet
+
+Lzebulon et pigeonmoelleux ont regardé la configuration de matrix et il faut
+changer le bridge irc/matrix. Le serveur matrix a été pensé pour faire
+uniquement du bridge donc le namespace (nom de channel gérer par le bridge) des
+serveurs matrix doivent être des salons irc. Ils proposent de remapper les noms
+des salons irc sur matrix mais tout les salons sont déjà mappé sur matrix et
+donc pigeonmoelleux a drop les noms des salons mais les anciens salons existent
+encore. La chose la plus simple à faire est de drop la base de données de
+matrix. Cela signifie que tout l'historique sera perdu. (ce qui n'est pas un
+problème car ni en prod ni beaucoup utilisé). Les personnes que ça dérangerait
+seront potentiellement les personnes de Aurore. On préviendra les membres de
+Aurore.
+
+Les administrateurâ‹…ices seront les nounous.
+
+=== Remettre en marche Belenios avant l'AG BDE ? ===
+
+c'est compliqué :
+
+* Soit remet debian avec ansible : c'est compliqué, pas à jour et la compilation
+ ne marche pas.
+* Soit on passe sur nixos : Est en train de se faire packager sur nixos par
+ Lzebulon/Lyes
+
+=== Wiki (historique de modification) ===
+
+La page modification récente a été cassée et devrait refonctionner mais
+visiblement ne fonctionne pas dans certains cas.
+
+Est-ce que le crans décide de mettre en place WikiStalk ?
+
+On peut garder WikiStalk et on le met sur zamok.
+
+=== Escalidraw ===
+
+https://excalidraw.com/
+
+Pas primordiale mais pas d'objection.
diff --git a/compte_rendus/2025_03_16.md b/compte_rendus/2025_03_16.md
new file mode 100644
index 0000000000000000000000000000000000000000..e24584e1a96ffb0e1dd5594b0351b3da879a75dd
--- /dev/null
+++ b/compte_rendus/2025_03_16.md
@@ -0,0 +1,49 @@
+= Réunion IN =
+
+* Date : Dimanche 16 Mars 2025
+* Lieu : MB87 et Galène (https://galene.crans.org/group/IN)
+* Début : 10h33
+* Fin : 11h15
+
+=== Présent⋅es ===
+
+* Lzebulon
+* Lyes
+* korenst1
+* Pigeon
+* Chiaroush
+* Pyjacpp
+* Romain
+
+== Ordre du jour ==
+
+* Gâteau
+* Incident imprimante
+* Matrix
+
+== Gâteau (entre 10h05 et 10h15) ==
+
+Lyes est maintenant Nounous.
+
+=== Incident imprimante ===
+
+On reçoit des mails dès qu'une personne se connecte, il y a donc des erreurs.
+
+Lzebulon suppose que le problème vient de l'oauth (ce à quoi Lzebulon est d'accord)
+
+Ducoup il faut trouver le temps de debug (contacter korenst1 qui adore Django)
+
+Pour l'issue : https://gitlab.crans.org/nounous/django-printer/-/issues/9
+
+=== Matrix ===
+
+Le déploiement est pratiquement fini.
+On peut se connecter sur element.crans.org (ou sur n'importe quel client avec le serveur matrix.crans.org)
+
+Pour laisser la possibilité aux gens de se connecter avec la note, on attends le merge de https://gitlab.crans.org/bde/nk20/-/merge_requests/293
+
+== Fin de l'IN ==
+
+On reparle de projet apprenti·e·s
+
+Et Lzebulon propose de relancer la machine des présentations techniques en début d'IN.