Les CR...
korenstin
parent
1196ff9552
commit
b76d44be69
|
|
@ -0,0 +1,117 @@
|
|||
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.
|
||||
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
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.
|
||||
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
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.
|
||||
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
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.
|
||||
|
||||
|
|
@ -0,0 +1,67 @@
|
|||
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.
|
||||
|
||||
|
|
@ -0,0 +1,99 @@
|
|||
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 ?
|
||||
|
||||
|
|
@ -0,0 +1,26 @@
|
|||
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 (./)
|
||||
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,54 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,52 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,48 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,58 @@
|
|||
= Réunion Nounous =
|
||||
== Horaires ==
|
||||
'''Date :''' Jeudi 8 novembre 2007
|
||||
|
||||
'''Début :''' -- WikiSgnb <<DateTime(2007-11-08T19:55:50Z)>>
|
||||
|
||||
'''Fin :''' @SIGN@
|
||||
|
||||
'''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
|
||||
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
= 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é.
|
||||
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,178 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,44 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,169 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,211 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
= 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...
|
||||
|
||||
|
|
@ -0,0 +1,186 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,231 @@
|
|||
= 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 ===
|
||||
'''It works, bitches!'''
|
||||
|
||||
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.
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,214 @@
|
|||
= 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)>>
|
||||
|
|
@ -0,0 +1,72 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,198 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,218 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,161 @@
|
|||
= 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 ===
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,94 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,173 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,174 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,157 @@
|
|||
= 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é.
|
||||
|
||||
|
|
@ -0,0 +1,123 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,164 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,121 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,132 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,136 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,96 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,127 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,151 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
= 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 ==
|
||||
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,142 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,200 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
= 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)>>
|
||||
|
|
@ -0,0 +1,120 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,153 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,110 @@
|
|||
= 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}}}.
|
||||
|
||||
|
|
@ -0,0 +1,125 @@
|
|||
= 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).
|
||||
|
||||
|
|
@ -0,0 +1,88 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,75 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,184 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,68 @@
|
|||
= 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).
|
||||
|
||||
|
|
@ -0,0 +1,164 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,24 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,143 @@
|
|||
= 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 ?
|
||||
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
= 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€.
|
||||
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
= 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).
|
||||
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
= 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).
|
||||
|
||||
|
|
@ -0,0 +1,102 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,116 @@
|
|||
= 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).
|
||||
|
|
@ -0,0 +1,83 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
= 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)>>
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,65 @@
|
|||
= 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
|
||||
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
= 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)]]
|
||||
|
||||
|
|
@ -0,0 +1,80 @@
|
|||
= 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… ?).
|
||||
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,29 @@
|
|||
= 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 ===
|
||||
|
||||
|
|
@ -0,0 +1,86 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
= 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.
|
||||
|
|
@ -0,0 +1,46 @@
|
|||
= 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...
|
||||
|
|
@ -0,0 +1,77 @@
|
|||
= 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.
|
||||
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
= 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 ?)
|
||||
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
= 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.
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue