quelques linters
parent
b76d44be69
commit
c384d79c07
|
@ -2,15 +2,15 @@ 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)
|
||||
* 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 ==
|
||||
|
||||
|
@ -114,4 +114,3 @@ fibre optique) pour mettre dans les bâtiments. Cette possibilité sera
|
|||
Cerise sur le gâteau, tous ces switchs supportent le multicast.
|
||||
|
||||
La réunion a pris fin vers 22h50.
|
||||
|
||||
|
|
|
@ -1,16 +1,18 @@
|
|||
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)
|
||||
|
||||
* 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)
|
||||
|
||||
* Nicolas Salles (mo²)
|
||||
* Nicolas Stransky (Nico)
|
||||
* Mathieu Segaud (Régala)
|
||||
|
||||
== Bilan sur les switchs HP achétés et avenir ==
|
||||
|
||||
|
@ -72,10 +74,11 @@ pourquoi ?
|
|||
|
||||
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)
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -87,7 +90,10 @@ 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.
|
||||
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 ==
|
||||
|
||||
|
@ -103,9 +109,9 @@ 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.
|
||||
|
||||
|
|
|
@ -1,21 +1,21 @@
|
|||
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)
|
||||
|
||||
* 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 ? =
|
||||
|
||||
|
@ -126,4 +126,3 @@ 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.
|
||||
|
||||
|
|
|
@ -2,60 +2,94 @@ 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
|
||||
* 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
|
||||
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 :
|
||||
|
||||
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.
|
||||
* {{{/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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
* 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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
||||
|
@ -63,10 +97,11 @@ Pour éviter d'avoir à demander au CA pour des achats mineurs (feutres, têtes
|
|||
|
||||
Schultzy va prendre contact avec les types de Videolan. Il y a deux solutions :
|
||||
|
||||
* recevoir le flux de Centrale
|
||||
* encoder nous mêmes
|
||||
* recevoir le flux de Centrale
|
||||
* encoder nous mêmes
|
||||
|
||||
Les nouveaux switchs facilitent la diffusion sur le campus, notamment grâce au multicast.
|
||||
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.
|
||||
|
||||
|
@ -74,23 +109,28 @@ M@nu prendra également contact pour proposer d'héberger un miroir Videolan.
|
|||
|
||||
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 ?
|
||||
* 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é.
|
||||
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 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.
|
||||
|
||||
|
|
|
@ -1,26 +1,31 @@
|
|||
Lundi 28 Février 2006 a eu lieu une réunion Internounou à la salle Condorcet à 19h30.
|
||||
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
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* Mise à jour des sanctions dans la base LDAP
|
||||
|
||||
|| || Squid|| Komaz || Radius et Ragnarok||
|
||||
|| Upload Manuel || (./) || (./) || ||
|
||||
|| Upload automatique || (./) || (./) || ||
|
||||
|
@ -31,37 +36,44 @@ Lundi 28 Février 2006 a eu lieu une réunion Internounou à la salle Condorcet
|
|||
|| Mail invalide || (./) || || ||
|
||||
|| Warez || (./) || || ||
|
||||
|
||||
|
||||
== Installation de cfengine ==
|
||||
Cfengine n'est pas capable de générer n'importe quels fichiers, en particulier pour Monit.
|
||||
|
||||
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
|
||||
|
||||
* Stéphane
|
||||
* Bilou
|
||||
|
||||
Électeurs : 9
|
||||
* Bilou : 5
|
||||
* Stéphane : 3
|
||||
* Nul : 1
|
||||
|
||||
* Bilou : 5
|
||||
* Stéphane : 3
|
||||
* Nul : 1
|
||||
|
||||
Bilou est élu RTC.
|
||||
|
||||
|
|
|
@ -13,87 +13,151 @@ Réunion technique inter nounous.
|
|||
'''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
|
||||
|
||||
* 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é.
|
||||
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é.
|
||||
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.
|
||||
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.
|
||||
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é.
|
||||
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.
|
||||
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é.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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é).
|
||||
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.
|
||||
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.
|
||||
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 ?
|
||||
|
||||
* 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 ?
|
||||
|
|
|
@ -1,26 +1,40 @@
|
|||
Réunion inter-nounou du jeudi 15 Mars 2007. La réunion aura lieu vers 19 heures au PdJ.
|
||||
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
|
||||
|
||||
* 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.
|
||||
|
||||
* 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 (./)
|
||||
|
||||
* 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 (./)
|
||||
|
|
|
@ -12,80 +12,121 @@
|
|||
|
||||
== Présents ==
|
||||
|
||||
* Alexandre Bos
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Jérémie Dimino
|
||||
* Stéphane Glondu
|
||||
* 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)
|
||||
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
|
||||
Mise en œuvre::
|
||||
|
||||
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
|
||||
* 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...
|
||||
É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
|
||||
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).
|
||||
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.
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* Todolist
|
||||
* Cableurs
|
||||
|
|
|
@ -11,44 +11,57 @@
|
|||
'''Lieu :''' Pavillon des Jardins
|
||||
|
||||
== Présents ==
|
||||
* Alexandre Bos
|
||||
* Augustin Parret-Fréaud
|
||||
* Cyril Cohen
|
||||
* Jérémie Dimino
|
||||
* Stéphane Glondu
|
||||
|
||||
* 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.
|
||||
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.
|
||||
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é.
|
||||
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 (?)
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
||||
* 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
|
||||
|
|
|
@ -12,41 +12,52 @@
|
|||
|
||||
== Présents ==
|
||||
|
||||
* Alexandre Bos
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Jérémie Dimino
|
||||
* Stéphane Glondu
|
||||
* 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...
|
||||
Rouge:: reste amavis à réparer... en attente...
|
||||
|
||||
Zamok:: pourquoi monit considère-t-il toujours qu'apache2 ne tourne pas ?
|
||||
Zamok:: pourquoi monit considère-t-il toujours qu'apache2 ne tourne pas ?
|
||||
|
||||
Pegase:: à faire (demain soir).
|
||||
Pegase:: à faire (demain soir).
|
||||
|
||||
Proxy:: pourquoi faire passer les adresses en free.fr par ultra ne semble plus fonctionner ?
|
||||
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
|
||||
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.
|
||||
|
||||
* À faire, pas dans les priorités.
|
||||
|
||||
== Porter CransWifi sous Windows Vista ==
|
||||
* Il nous faut un Windows Vista...
|
||||
|
||||
* Il nous faut un Windows Vista...
|
||||
|
||||
== Mettre en place une inscription en ligne ==
|
||||
* Problablement pas pour la prochaine rentrée.
|
||||
|
||||
* Problablement pas pour la prochaine rentrée.
|
||||
|
||||
== Permettre la connexion à la zone ENS uniquement aux normaliens ==
|
||||
* Il faudrait demander à la DSI quels sites filtrer.
|
||||
|
||||
* 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.
|
||||
|
||||
* 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.
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Horaires ==
|
||||
|
||||
'''Date :''' Jeudi 25 octobre 2007
|
||||
|
||||
'''Début :''' -- WikiSgnb <<DateTime(2007-10-25T19:12:42Z)>>
|
||||
|
@ -9,13 +11,14 @@
|
|||
'''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
|
||||
|
||||
* 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 =
|
||||
|
||||
|
@ -25,24 +28,38 @@ 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.
|
||||
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.
|
||||
À 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Horaires ==
|
||||
|
||||
'''Date :''' Jeudi 8 novembre 2007
|
||||
|
||||
'''Début :''' -- WikiSgnb <<DateTime(2007-11-08T19:55:50Z)>>
|
||||
|
@ -10,25 +12,30 @@
|
|||
|
||||
== 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
|
||||
* 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.
|
||||
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.
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -36,23 +43,31 @@ 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.
|
||||
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).
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Horaires ==
|
||||
|
||||
'''Date :''' Jeudi 22 novembre 2007
|
||||
|
||||
'''Début :''' -- WikiSgnb <<DateTime(2007-11-22T19:43:30Z)>>
|
||||
|
@ -10,15 +12,15 @@
|
|||
|
||||
== 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
|
||||
* 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 =
|
||||
|
||||
|
@ -28,17 +30,24 @@ 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.
|
||||
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...
|
||||
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.
|
||||
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.
|
||||
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 ==
|
||||
|
||||
|
@ -50,11 +59,13 @@ 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.
|
||||
À 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).
|
||||
Il faudrait faire un peu plus de pub pour l'IRC (en particulier le serveur de
|
||||
Rezosup).
|
||||
|
||||
== Migration PostgreSQL ==
|
||||
|
||||
|
@ -62,5 +73,7 @@ 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é.
|
||||
|
||||
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é.
|
||||
|
|
|
@ -1,6 +1,7 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Horaires ==
|
||||
|
||||
'''Date :''' Jeudi 6 décembre 2007
|
||||
|
||||
'''Début :''' -- WikiSgnb <<DateTime(2007-12-06T19:46:33Z)>>
|
||||
|
@ -11,45 +12,53 @@
|
|||
|
||||
== Présents ==
|
||||
|
||||
* Elsa Dupraz
|
||||
* Jean-Benoist Léger
|
||||
* Jérémie Dimino
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Pierre Chambart
|
||||
* Stéphane Glondu
|
||||
* 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.
|
||||
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é.
|
||||
|
||||
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::
|
||||
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.
|
||||
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).
|
||||
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.
|
||||
À 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.
|
||||
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 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.
|
||||
|
||||
|
@ -59,43 +68,64 @@ 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.
|
||||
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.
|
||||
Support technique::
|
||||
Il faudrait former une délégation pour rendre visite à VIA à ce sujet.
|
||||
|
||||
PostgreSQL::
|
||||
Brainstorming à continuer.
|
||||
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.
|
||||
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...
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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é).
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
|
|
|
@ -2,79 +2,90 @@
|
|||
|
||||
== 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
|
||||
* '''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
|
||||
|
||||
* 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::
|
||||
Problèmes avec l'imprimante::
|
||||
|
||||
Stéphane va essayer de constater le problème et de contacter HP.
|
||||
Stéphane va essayer de constater le problème et de contacter HP.
|
||||
|
||||
Connexion de secours::
|
||||
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.
|
||||
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::
|
||||
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.
|
||||
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é::
|
||||
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)
|
||||
* 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::
|
||||
En cours::
|
||||
|
||||
* Migration des confs CRANS vers Darcs
|
||||
* Installation de trac
|
||||
* Migration des confs CRANS vers Darcs
|
||||
* Installation de trac
|
||||
|
||||
En instance::
|
||||
En instance::
|
||||
|
||||
* Migration du www/wiki vers un domU (Stéphane)
|
||||
* Migration des news
|
||||
* Installation d'un serveur IRC
|
||||
* Migration du www/wiki vers un domU (Stéphane)
|
||||
* Migration des news
|
||||
* Installation d'un serveur IRC
|
||||
|
||||
== Déploiements ==
|
||||
|
||||
=== Redondance des services ===
|
||||
|
||||
Routeur::
|
||||
Routeur::
|
||||
|
||||
Augustin va se renseigner, mais pas tout de suite. Il a entendu parler de !HeartBeat...
|
||||
Augustin va se renseigner, mais pas tout de suite. Il a entendu parler
|
||||
de !HeartBeat...
|
||||
|
||||
Proxy::
|
||||
Proxy::
|
||||
|
||||
L'interaction avec le proxy transparent n'est pas claire... À méditer.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
|
|
@ -2,22 +2,22 @@
|
|||
|
||||
== 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
|
||||
* '''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
|
||||
* 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 =
|
||||
|
||||
|
@ -25,68 +25,88 @@
|
|||
|
||||
=== 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)...
|
||||
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.
|
||||
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
|
||||
|
||||
* 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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::
|
||||
En cours::
|
||||
|
||||
* Migration des confs CRANS vers Darcs (Stéphane)
|
||||
* Migration des confs CRANS vers Darcs (Stéphane)
|
||||
|
||||
En instance::
|
||||
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
|
||||
* 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.
|
||||
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.
|
||||
|
||||
Jérémie propose d'accorder les droits nounou à Antoine. Accepté à l'unanimité
|
||||
des présents.
|
||||
|
|
|
@ -1,178 +1,122 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
|
||||
|
||||
== Horaires ==
|
||||
|
||||
|
||||
|
||||
* '''Date :''' Jeudi 21 Février 2008
|
||||
|
||||
* '''Début :''' -- WikiSgnb <<DateTime(2008-02-21T19:36:54Z)>>
|
||||
|
||||
* '''Fin :''' -- WikiSgnb <<DateTime(2008-02-21T21:43:25Z)>>
|
||||
|
||||
* '''Lieu :''' Pavillon des Jardins
|
||||
|
||||
|
||||
* '''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
|
||||
|
||||
|
||||
* 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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
|
||||
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.
|
||||
|
||||
* [[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)
|
||||
|
||||
|
||||
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...
|
||||
|
||||
|
||||
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.
|
||||
|
||||
Fait::
|
||||
En cours::
|
||||
|
||||
* Bcfg2 (tout le monde)
|
||||
* OVH (Nicolas)
|
||||
* Jouvence (Elsa)
|
||||
|
||||
En instance::
|
||||
|
||||
* 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
|
||||
|
||||
* Migration du www/wiki vers un domU (Stéphane)
|
||||
* Installation de nurpawiki (Stéphane)
|
||||
* Migration vers UTF-8
|
||||
|
|
|
@ -1,34 +1,48 @@
|
|||
= Réunion nounous =
|
||||
|
||||
* Date : Jeudi 8 mai 2008
|
||||
* Début : 20:42
|
||||
* Fin : 21:42
|
||||
* Lieu : Salle de conférences du Pavillon des Jardins
|
||||
* 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
|
||||
* 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.
|
||||
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.
|
||||
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.
|
||||
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 ===
|
||||
|
||||
|
@ -40,5 +54,8 @@
|
|||
|
||||
=== 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.
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,27 +1,30 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 26 juin 2008
|
||||
* Début : 20h01
|
||||
* Fin : 22h18
|
||||
* Lieu : 2@B
|
||||
* 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
|
||||
|
||||
* Augustin Parret-Fréaud
|
||||
* Charles Vallantin-Dulac
|
||||
* Jean-Benoist Leger
|
||||
* Nicolas Dandrimont
|
||||
* Xavier Lagorce
|
||||
|
||||
=== À distance (gobby) ===
|
||||
* Antoine Durand-Gasselin
|
||||
* Michel Blockelet
|
||||
* Vincent Thomas
|
||||
|
||||
* 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
|
||||
|
@ -29,14 +32,19 @@ tenter de le décharger et par conséquent d'améliorer la qualité de service d
|
|||
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.
|
||||
|
||||
* 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 ?
|
||||
|
||||
* 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.
|
||||
|
@ -69,10 +77,13 @@ 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.
|
||||
|
||||
* 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.
|
||||
|
@ -85,25 +96,34 @@ l'éventualité d'un accord avec le CROUS.
|
|||
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
|
||||
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,
|
||||
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
|
||||
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
|
||||
|
@ -111,7 +131,8 @@ 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
|
||||
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.
|
||||
|
@ -119,12 +140,15 @@ 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
|
||||
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é
|
||||
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
|
||||
|
@ -134,17 +158,21 @@ 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
|
||||
é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
|
||||
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 ====
|
||||
|
@ -159,11 +187,12 @@ 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.
|
||||
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Horaires ==
|
||||
|
||||
'''Date :''' Jeudi 25 septembre 2008
|
||||
|
||||
'''Début :''' <<DateTime(2008-09-25T17:41:00Z)>>
|
||||
|
@ -9,25 +11,27 @@
|
|||
'''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)
|
||||
|
||||
* 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
|
||||
|
@ -38,7 +42,6 @@ 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
|
||||
|
@ -49,19 +52,21 @@ 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)
|
||||
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).
|
||||
* ML110 (Xeon 3065, 570€) + 3 * 500 Go (à 200€ chacun).
|
||||
|
||||
=== Remplacement de l'onduleur du 0B ===
|
||||
|
||||
|
@ -85,21 +90,27 @@ 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)
|
||||
|
||||
* 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é.
|
||||
* 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
|
||||
|
@ -113,18 +124,22 @@ Il faut faire une page wiki récapitulant les points techniques à ce propos.
|
|||
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
|
||||
|
||||
* 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,
|
||||
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).
|
||||
(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
|
||||
|
@ -137,14 +152,17 @@ vignettes sur MDR, le serveur qui réchauffe inutilement le 4@J actuellement.
|
|||
RC (on va pas beaucoup avancer avec ça...)
|
||||
|
||||
Les serveurs actuellement sous lenny :
|
||||
* sila
|
||||
* munin
|
||||
* o2
|
||||
* xmpp
|
||||
|
||||
* 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
|
||||
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
|
||||
|
@ -160,7 +178,8 @@ effectués.
|
|||
|
||||
== Organisation des séminaires techniques ==
|
||||
|
||||
Les séminaires seront organisés tous les mercredis soir à 20h, en salle Condorcet.
|
||||
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.
|
||||
|
@ -174,6 +193,7 @@ 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
|
||||
|
@ -186,9 +206,13 @@ Il y a des raisons pour avoir des comptes différents... C'est donc peut-être p
|
|||
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...
|
||||
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 ===
|
||||
|
||||
|
@ -205,7 +229,7 @@ par komaz.
|
|||
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
|
||||
|
||||
* 50 LiveCD kikoololbuntu i686
|
||||
* 50 LiveCD kikoololbuntu amd64
|
||||
* 20 Netinstall debian
|
||||
|
|
|
@ -1,5 +1,7 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Horaires ==
|
||||
|
||||
'''Date :''' Jeudi 9 Octobre 2008
|
||||
|
||||
'''Début :''' 20h12
|
||||
|
@ -9,20 +11,25 @@
|
|||
'''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
|
||||
|
||||
* 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.
|
||||
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.
|
||||
|
@ -37,26 +44,31 @@ 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)
|
||||
|
||||
* 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
|
||||
|
@ -91,6 +103,7 @@ 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
|
||||
|
@ -112,4 +125,3 @@ bien avec les limitations actuelles par nombre d'utilisateurs connectés.
|
|||
|
||||
Il faut le faire, en évitant de migrer les services en APF-4242.
|
||||
La migration naturelle lennyesque continue.
|
||||
|
||||
|
|
|
@ -1,6 +1,7 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Horaires ==
|
||||
|
||||
'''Date :''' Mercredi 22 octobre 2008
|
||||
|
||||
'''Début :''' 19h54
|
||||
|
@ -11,35 +12,43 @@
|
|||
|
||||
== 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
|
||||
* 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.
|
||||
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*.
|
||||
* 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).
|
||||
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 ==
|
||||
|
||||
|
@ -51,37 +60,47 @@ 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 ?
|
||||
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.
|
||||
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".
|
||||
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).
|
||||
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)>>
|
||||
* ''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.
|
||||
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/
|
||||
|
||||
* VieCrans/
|
||||
* CransTechnique/
|
||||
* CransAdministratif/
|
||||
|
||||
=== Câblage du personnel de l'ENS ===
|
||||
|
||||
Rien n'a changé depuis 15 jours. Michel a été porté volontaire.
|
||||
|
||||
|
|
|
@ -1,24 +1,27 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
== Lieu et horaires ==
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Date : Jeudi 20 novembre 2008
|
||||
* Début : 19h51
|
||||
* Fin : 21h23
|
||||
|
||||
* 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
|
||||
* 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
|
||||
|
@ -26,37 +29,43 @@ 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"
|
||||
|
||||
* 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
|
||||
|
||||
* 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 :
|
||||
|
||||
* 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)
|
||||
* 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 :
|
||||
* Sur vert :
|
||||
* Le serveur NFS...
|
||||
* La base LDAP principale...
|
||||
* BCfg2
|
||||
* Le serveur DNS (slave de toutes les zones)
|
||||
* Sur le nouveau Dom0 :
|
||||
* Sur le nouveau Dom0 :
|
||||
* un DomU www
|
||||
* ...
|
||||
|
||||
|
@ -102,10 +111,12 @@ précédemment) n'oppose son veto.
|
|||
|
||||
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
|
||||
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
|
||||
|
@ -123,8 +134,8 @@ problèmes de connexion filaire sous Vista.
|
|||
|
||||
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 ?)
|
||||
|
||||
* Soit une zone spéciale (.vieux-con.crans.org ?)
|
||||
* Soit un domaine spécial (crans.eu ?)
|
||||
|
||||
Le domaine crans.eu est commandé chez ovh.
|
||||
|
||||
|
|
|
@ -1,84 +1,123 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 15 janvier 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h45
|
||||
* Fin : 21h00
|
||||
* 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
|
||||
* 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.
|
||||
La solution technique retenue est de placer les Appartements derrière un NAT,
|
||||
sur komaz.
|
||||
|
||||
Pour ce qui est de la charte à faire signer à ces nouveaux connectés, la discussion est reportée au prochain CA.
|
||||
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.
|
||||
|
||||
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.
|
||||
Il parait difficile de faire une checklist des choses à vérifier en cas de
|
||||
panne, le nombre de serveurs et de services étant faramineux.
|
||||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
||||
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...
|
||||
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.
|
||||
|
||||
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
|
||||
Tous les serveurs non critiques ont été migrés sous lenny. Pour les serveurs
|
||||
principaux restant, l'ordre retenu de migration est le suivant :
|
||||
|
||||
Ce qui advient de vert sera déterminé plus tard (selon les tests du NFS sur un domU).
|
||||
* 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.
|
||||
* 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.
|
||||
|
||||
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...
|
||||
|
||||
Il est rappelé que les modifications aux différents dépôts doivent être
|
||||
commitées rapidement...
|
||||
|
|
|
@ -1,19 +1,21 @@
|
|||
= Réunion Nounous =
|
||||
* Date : Jeudi 29 Janvier 2009
|
||||
* Lieu : PdJ
|
||||
* Début : 20h02
|
||||
* Fin : 21h30
|
||||
|
||||
* 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
|
||||
* 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
|
||||
|
@ -37,8 +39,8 @@ 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.
|
||||
|
@ -47,7 +49,8 @@ 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]]).
|
||||
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é
|
||||
|
@ -62,23 +65,28 @@ 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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 :
|
||||
|
@ -91,12 +99,15 @@ que les machines sur le réseau IPSec et le réseau WPA ne peuvent pas partager
|
|||
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
|
||||
|
||||
* 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 ?
|
||||
|
||||
* Tu paries ?
|
||||
|
||||
==== Gestion des bornes ====
|
||||
|
||||
|
@ -110,77 +121,97 @@ 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
|
||||
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
|
||||
|
||||
* 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
|
||||
|
||||
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
|
||||
|
||||
* 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 ?
|
||||
|
||||
* 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.
|
||||
|
||||
|
||||
* 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
|
||||
|
||||
==== 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
|
||||
|
|
|
@ -1,54 +1,63 @@
|
|||
= Réunion Nounous =
|
||||
* Date : Jeudi 5 mars 2009
|
||||
* Lieu : PdJ
|
||||
* Début : 20h02
|
||||
* Fin : ????
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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)
|
||||
|
@ -57,7 +66,6 @@ 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.
|
||||
|
@ -94,8 +102,9 @@ bcfg2).
|
|||
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.
|
||||
* 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 ===
|
||||
|
||||
|
@ -110,17 +119,19 @@ 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.
|
||||
|
@ -130,7 +141,8 @@ Le module est en cours de conception. Ca devrait être cool.
|
|||
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
|
||||
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.
|
||||
|
@ -138,7 +150,6 @@ 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
|
||||
|
@ -153,7 +164,6 @@ 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).
|
||||
|
@ -175,11 +185,13 @@ 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
|
||||
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 :))
|
||||
|
@ -188,14 +200,19 @@ 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
|
||||
|
||||
*é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).
|
||||
|
||||
|
@ -203,17 +220,20 @@ 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
|
||||
|
||||
* 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).
|
||||
* 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.
|
||||
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
|
||||
|
||||
|
|
|
@ -1,129 +1,183 @@
|
|||
= Réunion Nounous =
|
||||
* Date : Lundi 6 avril 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : 21h57
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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.
|
||||
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,
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
[[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.
|
||||
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
|
||||
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).
|
||||
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.
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
À voir plus tard.
|
||||
|
|
|
@ -1,39 +1,44 @@
|
|||
= Réunion =
|
||||
|
||||
* Date : 04 Mai 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h55
|
||||
* Fin : <<DateTime(2009-05-04T20:26:02+0100)>>
|
||||
* 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
|
||||
* 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 ===
|
||||
=== 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
|
||||
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
|
||||
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é
|
||||
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.
|
||||
owl présente des problèmes d'IOs. Certaines personnes considèrent que cela le
|
||||
ralentit.
|
||||
|
||||
On pourrait tester openvz, avec owl... pour voir...
|
||||
|
||||
|
@ -69,20 +74,21 @@ 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.
|
||||
* 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)
|
||||
* 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.
|
||||
* 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 ===
|
||||
|
||||
|
@ -94,7 +100,7 @@ Adg et Chicco ont commencé à regarder.
|
|||
|
||||
=== Authentification LDAP sur le wiki ===
|
||||
|
||||
* Ça marche sur Vo
|
||||
* Ça marche sur Vo
|
||||
|
||||
=== Bugs de MoinMoin ===
|
||||
|
||||
|
|
|
@ -1,32 +1,38 @@
|
|||
= Réunion =
|
||||
|
||||
* Date : Lundi 25 mai 2009
|
||||
* Lieu : 2@B, clim powa®
|
||||
* Début : 20h00
|
||||
* Fin : 22h30
|
||||
* 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
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Damien Aza-Vallina
|
||||
* Jérémie Dimino
|
||||
* Pierre Chambart
|
||||
* Xavier Lagorce
|
||||
|
||||
Par Gobby :
|
||||
* Brice Dubost
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
|
||||
* 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,
|
||||
|
||||
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
|
||||
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,
|
||||
|
@ -54,60 +60,87 @@ 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 ?)
|
||||
|
||||
* /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.
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
|
||||
* 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 ...
|
||||
|
||||
* 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.
|
||||
|
@ -118,13 +151,15 @@ 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
|
||||
|
||||
* 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
|
||||
|
@ -135,13 +170,17 @@ 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 ?).
|
||||
(-> 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)>>
|
||||
* 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...
|
||||
|
@ -149,36 +188,51 @@ 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.
|
||||
|
||||
* Ç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 ?)
|
||||
|
||||
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
|
||||
* 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.
|
||||
|
@ -187,28 +241,31 @@ 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)
|
||||
|
||||
* 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)>>
|
||||
|
||||
* 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)>>
|
||||
|
|
|
@ -1,26 +1,29 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 11 juin 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : -- WikiXhub <<DateTime(2009-06-11T20:45:04+0100)>>
|
||||
* 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
|
||||
* 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.
|
||||
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.
|
||||
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 ==
|
||||
|
@ -33,7 +36,8 @@ 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 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
|
||||
|
||||
|
@ -42,7 +46,8 @@ https://wiki.crans.org/WifiTechnique/FirmWare
|
|||
|
||||
== Virtualisation au Cr@ns ==
|
||||
|
||||
On essaie de faire des tests supplémentaires avec plusieurs systèmes de virtualisation.
|
||||
On essaie de faire des tests supplémentaires avec plusieurs systèmes de
|
||||
virtualisation.
|
||||
|
||||
== Préinscription en ligne ==
|
||||
|
||||
|
@ -50,13 +55,18 @@ 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).
|
||||
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)
|
||||
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 ==
|
||||
|
||||
|
@ -69,4 +79,3 @@ On migre les dns de mdr autre part et on leur donne le serveur.
|
|||
== Divers ==
|
||||
|
||||
La connexion à la Kfet ne marche pas.
|
||||
|
||||
|
|
|
@ -1,93 +1,106 @@
|
|||
= 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)>>
|
||||
|
||||
* 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
|
||||
|
||||
* 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)
|
||||
|
||||
== 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 :
|
||||
|
||||
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 ?
|
||||
* 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 ?
|
||||
* 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
|
||||
* 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.
|
||||
|
||||
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.
|
||||
|
||||
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)
|
||||
|
||||
* 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*
|
||||
* 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
|
||||
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.
|
||||
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.
|
||||
|
||||
La doc quand ça sera terminé.......
|
||||
Deuxième prototype d'ici une semaine et en CMS.
|
||||
|
||||
La doc quand ça sera terminé.......
|
||||
|
||||
=== déploiement du wifi ===
|
||||
|
||||
|
@ -98,63 +111,70 @@ 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:
|
||||
|
||||
-> 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
|
||||
* 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
|
||||
-> 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)
|
||||
|
||||
-> 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é.
|
||||
* 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
|
||||
|
||||
* 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,
|
||||
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.
|
||||
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.
|
||||
-> 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
|
||||
Une belle bête, qui pèse bien ses 42kg. On remarquera que vert a des
|
||||
ventilateurs
|
||||
rackables.
|
||||
|
||||
=== OpenStreetMap ===
|
||||
|
@ -186,13 +206,15 @@ 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 )
|
||||
À 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.
|
||||
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.
|
||||
On casse zamok ? (upgrade)
|
||||
Bof.
|
||||
|
|
|
@ -1,34 +1,37 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 10 Septembre 2009
|
||||
* Lieu : PdJ
|
||||
* Début : 19h30
|
||||
* Fin : 21h35
|
||||
* 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
|
||||
* 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
|
||||
|
||||
* 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
|
||||
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).
|
||||
|
@ -37,16 +40,21 @@ sa pose (sachant que nous pourrions effectuer nous-même la pose de la fibre).
|
|||
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
|
||||
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).
|
||||
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
|
||||
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 ===
|
||||
|
@ -62,65 +70,85 @@ 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)
|
||||
|
||||
(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
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
* 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
|
||||
|
||||
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)
|
||||
|
||||
* 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
|
||||
|
||||
* Dom0 Xen
|
||||
|
||||
==== fx ====
|
||||
* Serveur NFS (homes + /usr/scripts)
|
||||
|
||||
* Serveur NFS (homes + /usr/scripts)
|
||||
|
||||
==== sable ====
|
||||
Le proxy, serveur DNS principal, serveur DHCP, serveur radius, serveur de la connexion gratuite.
|
||||
|
||||
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.
|
||||
|
||||
* Nouveau contact pour Synaps : Nicolas va reprendre le contact avec Anne.
|
||||
|
||||
==== ftp ====
|
||||
|
||||
|
@ -128,7 +156,8 @@ Cf. ci-dessus.
|
|||
|
||||
==== fz/zamok++ ====
|
||||
|
||||
Le système imaginé avant les vacances, lors des problèmes d'I/O Xen, était d'acheter
|
||||
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).
|
||||
|
@ -156,7 +185,9 @@ Voté au précédent CA (500€ de budget pour 10 modules) et cf ci-dessous.
|
|||
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).
|
||||
|
@ -195,8 +226,8 @@ 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
|
||||
|
@ -215,4 +246,3 @@ associatifs ?).
|
|||
|
||||
Des discussions ont eu lieu avec le FAI, qui accepte de nous laisser gérer le
|
||||
routage, le filtrage et les logs.
|
||||
|
||||
|
|
|
@ -1,27 +1,30 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : 22 Octobre 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : <<Date(2009-10-22T20:56:17+0200)>>
|
||||
* 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
|
||||
* 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
|
||||
|
@ -40,9 +43,12 @@ 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.
|
||||
|
||||
* 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 ===
|
||||
|
||||
|
@ -58,18 +64,18 @@ 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 ?
|
||||
* "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.
|
||||
* 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.
|
||||
|
|
|
@ -1,24 +1,25 @@
|
|||
= Réunion =
|
||||
|
||||
* Date : 10 Décembre 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : 21h35
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
@ -45,9 +46,10 @@ hertzienne.
|
|||
Utilisation d'une solution de containers (OpenVZ ou vserver...).
|
||||
|
||||
Il y aurait :
|
||||
* Un container pour les adhérents
|
||||
* Un container pour les services mail
|
||||
* ...
|
||||
|
||||
* Un container pour les adhérents
|
||||
* Un container pour les services mail
|
||||
* ...
|
||||
|
||||
=== Déconnexion mail invalide ===
|
||||
|
||||
|
@ -55,38 +57,46 @@ 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 ====
|
||||
==== 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).
|
||||
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).
|
||||
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.
|
||||
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é.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
||||
N/A
|
||||
|
|
|
@ -1,23 +1,24 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 14 Janvier 2010
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h40
|
||||
* Fin : -- WikiMichou <<DateTime(2010-01-14T22:26:17+0200)>>
|
||||
* 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
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -92,21 +93,29 @@ 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
|
||||
* 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 ====
|
||||
|
||||
|
@ -114,47 +123,58 @@ 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.
|
||||
* 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 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.
|
||||
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)
|
||||
|
||||
* 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
|
||||
|
||||
* 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)
|
||||
|
||||
* 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
|
||||
* 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.
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,80 +1,101 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 5 mai 2011
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h10
|
||||
* Fin : 21h01
|
||||
* 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
|
||||
* 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.
|
||||
Lundi 9 mai à 14h30 entrevue avec Stuart. Nicolas y va accompagné de Daniel et
|
||||
Valentin.
|
||||
|
||||
Ordre du jour :
|
||||
* Gigabit
|
||||
* WiFi
|
||||
|
||||
* 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
|
||||
* 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
|
||||
* SSID Multiples (n > 2)
|
||||
* IPv6
|
||||
* WiFi N
|
||||
|
||||
Points techniques
|
||||
* OpenWRT
|
||||
* Firmware à jour
|
||||
* Firmware "universel" (configuration de la borne par DHCP)
|
||||
|
||||
* 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)
|
||||
|
||||
* 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)
|
||||
|
||||
* 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).
|
||||
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.
|
||||
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 :
|
||||
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.
|
||||
* 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.
|
||||
|
||||
|
@ -94,17 +115,23 @@ 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.
|
||||
* 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.
|
||||
|
||||
|
|
|
@ -1,18 +1,18 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 19 mai 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 20h07
|
||||
* 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
|
||||
* Daniel Stan
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vincent Maioli
|
||||
|
||||
== Ordre du jour ==
|
||||
|
||||
|
@ -30,15 +30,17 @@ Daniel a avancé sur l'interface de gestion des accès. Ça ne sera pas prêt à
|
|||
présenté demain, mais bientôt.
|
||||
|
||||
Cahier des charges :
|
||||
* Enregistrement d'interventions
|
||||
* Édition des interventions futures
|
||||
* Listing des interventions par local
|
||||
|
||||
* 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 ?
|
||||
|
||||
* Interfaçage avec les caméras / détecteurs de mouvement
|
||||
* Badgeuse ?
|
||||
|
||||
=== IPv6 ===
|
||||
|
||||
|
@ -49,14 +51,19 @@ 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.
|
||||
* 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 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.
|
||||
Il faut évaluer les conséquences de mettre en place le DHCPv6, notamment sur la
|
||||
simplicité de configuration.
|
||||
|
||||
=== WiFi ===
|
||||
|
||||
|
@ -66,16 +73,20 @@ Il faut évaluer les conséquences de mettre en place le DHCPv6, notamment sur l
|
|||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
|
|
@ -1,29 +1,29 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 15 septembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début de la réunion : 19h20
|
||||
* Fin : 20h06
|
||||
* 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
|
||||
|
||||
* 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 ==
|
||||
|
@ -34,17 +34,21 @@ 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.
|
||||
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 ||
|
||||
|| 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 ||
|
||||
|| || Administration réseau sous
|
||||
Linux || || NicolasDandrimont ||
|
||||
|| || Python || || WikiIota ||
|
||||
|| || Les scripts du Cr@ns || || ||
|
||||
|| || WiFi || || ||
|
||||
|
@ -68,7 +72,8 @@ 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
|
||||
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" ==
|
||||
|
@ -103,4 +108,3 @@ 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.
|
||||
|
||||
|
|
|
@ -1,38 +1,42 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 29 Septembre 2011
|
||||
* Lieu : Amphi Condorcet
|
||||
* Début de la réunion : 19h21
|
||||
* Fin : 20h42
|
||||
* 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
|
||||
* 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.
|
||||
|
||||
* 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
|
||||
|
||||
* 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à.
|
||||
|
@ -46,7 +50,8 @@ vachement plus cool, pour tester.
|
|||
|
||||
== Séminaires ==
|
||||
|
||||
Le premier est mardi, les apprentis doivent venir et s'inscrire pour les suivants.
|
||||
Le premier est mardi, les apprentis doivent venir et s'inscrire pour les
|
||||
suivants.
|
||||
|
||||
== Connexion des appartements ==
|
||||
|
||||
|
@ -91,4 +96,3 @@ 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.
|
||||
|
||||
|
|
|
@ -1,29 +1,32 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 13 Octobre 2011
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h14
|
||||
* Fin : 21h34
|
||||
* 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
|
||||
|
||||
* 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,
|
||||
|
@ -34,6 +37,7 @@ Les tests de portée sont à effectuer. Il faut voir si ça passe en ligne droit
|
|||
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.
|
||||
|
||||
|
@ -70,9 +74,17 @@ 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.
|
||||
* 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 ==
|
||||
|
||||
|
@ -94,9 +106,10 @@ directe.
|
|||
=== Problèmes avec l'imprimante ===
|
||||
|
||||
Il faut contacter print platinium pour
|
||||
* échanger les rouleaux
|
||||
* échanger l'imprimante
|
||||
* échanger de partenaire *kof* *kof*
|
||||
|
||||
* échanger les rouleaux
|
||||
* échanger l'imprimante
|
||||
* échanger de partenaire *kof* *kof*
|
||||
|
||||
== DHCPv6 ==
|
||||
|
||||
|
@ -105,6 +118,7 @@ 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
|
||||
|
@ -134,10 +148,11 @@ 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
|
||||
|
||||
* Gigabit
|
||||
* Connexion des appartements
|
||||
* Rationnalisation de la connexion Cr@ns-ENS
|
||||
* WiFi
|
||||
|
||||
Le RTC est volontaire.
|
||||
|
||||
|
@ -165,9 +180,11 @@ Judith se porte volontaire.
|
|||
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
|
||||
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
|
||||
|
||||
* 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
|
||||
|
|
|
@ -1,45 +1,48 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 3 novembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h19
|
||||
* Fin : 21h08
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -78,6 +81,7 @@ 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
|
||||
|
@ -97,8 +101,6 @@ déployer sur toutes les 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
|
||||
|
@ -127,7 +129,6 @@ 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.
|
||||
|
||||
|
@ -135,9 +136,10 @@ encadrés, quitte à ce que la Nounou s'implique dans le projet et y participe.
|
|||
|
||||
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)
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -165,10 +167,10 @@ 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.
|
||||
|
||||
|
|
|
@ -1,26 +1,26 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 17 novembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h08
|
||||
* Fin : 20h50
|
||||
* 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
|
||||
* 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 =
|
||||
|
||||
|
@ -28,10 +28,10 @@
|
|||
|
||||
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,
|
||||
termes de matériel (remplacement de la caméra du 0B, renouvellement des
|
||||
garanties,
|
||||
renouvellement du backbone, ...)
|
||||
|
||||
|
||||
== Câblage des chambres ==
|
||||
|
||||
=== Prises défectueuses ===
|
||||
|
@ -79,10 +79,12 @@ 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
|
||||
|
||||
* 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.
|
||||
|
@ -91,7 +93,9 @@ 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
|
||||
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.
|
||||
|
@ -111,7 +115,8 @@ Il a été question du traffic shaping. Il faut tester ça sur le réseau du Cr@
|
|||
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.
|
||||
On est censé pouvoir acceder à l'interface de demande de travaux. C'est à
|
||||
tester.
|
||||
|
||||
== Questions diverses ==
|
||||
|
||||
|
@ -122,7 +127,8 @@ 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é.
|
||||
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
|
||||
|
@ -139,11 +145,16 @@ 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.
|
||||
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.
|
||||
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.
|
||||
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 ===
|
||||
|
||||
|
@ -153,5 +164,5 @@ 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é.
|
||||
|
||||
Le rouleau des feuilles A3 pose problème, il faudrait demander à ce qu'il soit
|
||||
changé.
|
||||
|
|
|
@ -1,24 +1,26 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 1er Decembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h17
|
||||
* Fin : 20h27
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
@ -26,13 +28,15 @@ 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
|
||||
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
|
||||
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).
|
||||
|
||||
|
@ -45,6 +49,7 @@ Le plan du réseau du Cr@ns n'a pas été mis à jour suite à la mise en étoil
|
|||
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.
|
||||
|
@ -56,9 +61,10 @@ 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}}}
|
||||
* ...?
|
||||
|
||||
* {{{/etc/cron.d/CRANS}}}
|
||||
* {{{/etc/init.d/purge_les_locks_nfs_connard}}}
|
||||
* ...?
|
||||
|
||||
=== Scripts ===
|
||||
|
||||
|
@ -68,6 +74,7 @@ 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
|
||||
|
@ -77,7 +84,9 @@ 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]]
|
||||
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.
|
||||
|
@ -89,7 +98,8 @@ les bâtiments, ...).
|
|||
|
||||
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
|
||||
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.
|
||||
|
@ -98,7 +108,8 @@ ont été déconnectés.
|
|||
|
||||
=== P2P ===
|
||||
|
||||
Utilisation de OpenDPI à la place de ipp2p. La documentation est très éparse. On regarde si ca vaut le coup.
|
||||
Utilisation de OpenDPI à la place de ipp2p. La documentation est très éparse.
|
||||
On regarde si ca vaut le coup.
|
||||
|
||||
=== Formation interne ===
|
||||
|
||||
|
@ -106,11 +117,14 @@ La liste de compétences suggérée la semaine dernière doit toujours être mis
|
|||
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.
|
||||
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.
|
||||
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 ===
|
||||
|
||||
|
@ -120,4 +134,3 @@ C'est Samedi, 12h30, venez.
|
|||
|
||||
Pas d'avancées depuis 15 jours...
|
||||
Elle fait des traces moches, ça devient urgent de changer les tambours.
|
||||
|
||||
|
|
|
@ -1,21 +1,22 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 15 Décembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h16
|
||||
* Fin : 20h51
|
||||
* 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
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Benjamin Aupetit
|
||||
* Daniel Stan
|
||||
* Melissa Verbeke
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vanessa Verbeke
|
||||
|
||||
= Ordre du jour =
|
||||
|
||||
|
@ -25,12 +26,15 @@ 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
|
||||
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é
|
||||
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 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.
|
||||
|
||||
|
@ -40,55 +44,68 @@ L'actuelle fibre Multiprise_wifi<->D'Alembert-Centre serait alors inutilisée.
|
|||
|
||||
=== 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 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 :
|
||||
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)
|
||||
* 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.
|
||||
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
|
||||
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
|
||||
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).
|
||||
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
|
||||
|
||||
* 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.
|
||||
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 ====
|
||||
|
||||
|
@ -100,14 +117,18 @@ La mise à jour de LDAP va être passionnante : la conversion automatique vers
|
|||
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.
|
||||
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
|
||||
|
||||
* é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.
|
||||
|
@ -115,36 +136,46 @@ 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
|
||||
* 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
|
||||
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
|
||||
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,
|
||||
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
|
||||
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
|
||||
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 ==
|
||||
|
@ -155,10 +186,11 @@ commit()
|
|||
== Questions diverses ==
|
||||
|
||||
=== Vacances ===
|
||||
Remplissez la page idoine, merci. Il faut des clés du 0B proches du campus à tout
|
||||
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,22 +1,26 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 12 Janvier 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 21h01
|
||||
* 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
|
||||
|
||||
* 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 ==
|
||||
|
@ -26,17 +30,21 @@ 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
|
||||
* 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
|
||||
* 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
|
||||
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.
|
||||
|
@ -74,10 +82,11 @@ 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
|
||||
|
||||
* 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
|
||||
|
@ -87,17 +96,28 @@ 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.
|
||||
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.
|
||||
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.
|
||||
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)
|
||||
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 ===
|
||||
|
@ -118,4 +138,3 @@ le faire échanger.
|
|||
=== Imprimante ===
|
||||
|
||||
Nicolas trouve que Print Platinium est désespérant
|
||||
|
||||
|
|
|
@ -1,19 +1,20 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 26 janvier 2012
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h16
|
||||
* Fin : 20h35
|
||||
* Date : Jeudi 26 janvier 2012
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h16
|
||||
* Fin : 20h35
|
||||
|
||||
= Présents =
|
||||
|
||||
* Anne Cazalet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Anne Cazalet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
|
||||
##== Présent par internet ==
|
||||
|
||||
## * Aurore Moisy-Mabille
|
||||
## * Daniel Stan
|
||||
## * Raphaël Cauderlier
|
||||
|
@ -22,21 +23,25 @@
|
|||
## * Yann Duplouy
|
||||
|
||||
= Ordre du jour =
|
||||
|
||||
== Achat de matériel ==
|
||||
|
||||
Anne Cazalet nous fait ses propositions sur les éléments que nous avions demandé.
|
||||
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.
|
||||
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
|
||||
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 ===
|
||||
|
@ -51,10 +56,11 @@ contrôleurs inclus (prévoir une remise ~20%), sans prendre en compte un échan
|
|||
|
||||
=== Backbone ===
|
||||
|
||||
Pas de proposition mise à jour, nous avions envisagé un chassis 5406, avec deux modules
|
||||
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
|
||||
* 12 ports SFP + 12 ports Ethernet 10/100/1000
|
||||
* 24 ports 10/100/1000 Ethernet
|
||||
|
||||
== Imprimante ==
|
||||
|
||||
|
@ -63,11 +69,11 @@ 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)
|
||||
* 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.
|
||||
|
@ -82,7 +88,8 @@ se fait inonder.
|
|||
|
||||
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
|
||||
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
|
||||
|
@ -103,8 +110,11 @@ 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.
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -115,18 +125,20 @@ relancés pour dans 10 jours.
|
|||
|
||||
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
|
||||
* 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.
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,24 +1,24 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 9 février 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h23
|
||||
* Fin :21h05
|
||||
* 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
|
||||
* 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 =
|
||||
|
||||
|
@ -31,7 +31,8 @@ donc faire de la place.
|
|||
|
||||
== Imprimante ==
|
||||
|
||||
Qualis fait une offre de leasing sur une imprimante Xerox (7535) qui semble intéressante.
|
||||
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.
|
||||
|
@ -43,25 +44,30 @@ l'autorisation de Lebailly pour pouvoir faire les travaux. Benjamin s'en occupe.
|
|||
|
||||
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 ?)
|
||||
|
||||
* 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
|
||||
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.
|
||||
|
||||
|
@ -77,6 +83,7 @@ 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.
|
||||
|
@ -128,9 +135,9 @@ Encadré par Daniel et Nicolas.
|
|||
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.
|
||||
|
||||
|
|
|
@ -1,25 +1,27 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 23 février 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 20h20
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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
|
||||
|
@ -32,7 +34,8 @@ 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.
|
||||
Vesta est dans la med en ce moment. Certaines personnes ont quelques soucis
|
||||
avec.
|
||||
|
||||
Daniel a avancé sur la carte des bornes.
|
||||
|
||||
|
@ -62,11 +65,13 @@ nous être offerte, on pourrait en faire le nouveau serveur des adhérents.
|
|||
|
||||
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.
|
||||
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 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.
|
||||
|
@ -76,21 +81,24 @@ l'horaire annoncé, ou reportées.
|
|||
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
|
||||
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 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
|
||||
|
||||
|
|
|
@ -1,27 +1,31 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 15 mars 2012
|
||||
* Lieu : Amphithéâtre Tocqueville
|
||||
* Début : 19h15
|
||||
* Fin : 20h12
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
@ -33,6 +37,7 @@ 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.
|
||||
|
@ -40,6 +45,7 @@ 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
|
||||
|
@ -48,9 +54,11 @@ 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.
|
||||
|
@ -58,14 +66,14 @@ 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.
|
||||
* 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 :
|
||||
* 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 :
|
||||
* Investir dans un nouveau serveur pour faire les exports NFS :
|
||||
* Avantage : c'est un serveur neuf...
|
||||
* Inconvénient : c'est un peu cher...
|
||||
|
||||
|
@ -75,14 +83,17 @@ 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.
|
||||
|
||||
|
|
|
@ -1,19 +1,20 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 29 mars 2012
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h17
|
||||
* Fin : 20h13
|
||||
* 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
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Aurore Quelennec
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Sylvain Boilard
|
||||
* Vanessa Verbeke
|
||||
|
||||
= Ordre du jour =
|
||||
|
||||
|
@ -37,32 +38,34 @@ 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)
|
||||
* 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)
|
||||
* 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.
|
||||
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
|
||||
|
@ -75,31 +78,42 @@ On pourra réfléchir, une fois l'installation faite, à prêter des bornes à d
|
|||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
|
||||
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
|
||||
|
@ -107,6 +121,7 @@ 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.
|
||||
|
@ -122,6 +137,7 @@ que la véracité des informations a été vérifiée.
|
|||
=== 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
|
||||
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.
|
||||
|
|
|
@ -1,28 +1,32 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 12 avril 2012
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h13
|
||||
* Fin : 20h10
|
||||
* 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
|
||||
|
||||
* 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
|
||||
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.
|
||||
|
@ -39,7 +43,9 @@ Steven songe à faire une doc pour la MàJ du wiki qui soit plus accessible à t
|
|||
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
|
||||
|
@ -68,23 +74,26 @@ 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
|
||||
* 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
|
||||
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.
|
||||
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,
|
||||
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.
|
||||
|
@ -116,6 +125,7 @@ appelle les gens qui ont des questions à les poser, ensuite on pourra mettre ç
|
|||
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.
|
||||
|
@ -125,8 +135,9 @@ 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
|
||||
|
||||
* Désactiver temporairement l'authentification RADIUS sur la prise
|
||||
* N'autoriser que sa vraie MAC sur sa prise
|
||||
|
||||
== Vérification mac prises ==
|
||||
|
||||
|
@ -144,8 +155,8 @@ 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).
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,31 +1,36 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 26 avril 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h25
|
||||
* Fin : 21h
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
|
@ -36,13 +41,16 @@ 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
|
||||
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.
|
||||
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à).
|
||||
|
||||
|
@ -51,7 +59,8 @@ 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
|
||||
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 ?
|
||||
|
||||
|
@ -64,7 +73,8 @@ 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
|
||||
Il faudra aussi réfléchir à la "mise en production" des alertes mail de nagios
|
||||
sur
|
||||
roots@crans.org.
|
||||
|
||||
=== Wifi ===
|
||||
|
@ -84,24 +94,29 @@ 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
|
||||
|
||||
* 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)
|
||||
|
||||
* 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
|
||||
* 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
|
||||
* 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
|
||||
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.
|
||||
|
@ -140,6 +155,7 @@ 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
|
||||
|
@ -150,4 +166,3 @@ 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.
|
||||
|
||||
|
|
|
@ -1,25 +1,29 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 10 avril 2012
|
||||
* Lieu : Hall du bâtiment B
|
||||
* Début : 19h35
|
||||
* Fin : 20h35
|
||||
* 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
|
||||
|
||||
* 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}).
|
||||
|
@ -34,10 +38,12 @@ 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.
|
||||
|
@ -45,6 +51,7 @@ 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%.
|
||||
|
@ -53,6 +60,7 @@ 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
|
||||
|
@ -62,7 +70,8 @@ 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
|
||||
''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é).
|
||||
|
||||
|
@ -81,6 +90,7 @@ est l'array, et sdYZ le disque qui en a disparu (à trouver dans dmesg, il est
|
|||
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
|
||||
|
@ -103,4 +113,3 @@ Le démarrage du firewall IPv6 a été cassé par une mise à jour de config.py
|
|||
déjà touché à ce script...
|
||||
|
||||
On demandera à Valentin et Daniel de regarder.
|
||||
|
||||
|
|
|
@ -1,72 +1,93 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 24 mai 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h10
|
||||
* Fin : 20h36
|
||||
* 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
|
||||
|
||||
* 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
|
||||
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.
|
||||
* 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
|
||||
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 ?
|
||||
|
||||
* 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
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
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é.
|
||||
|
||||
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
|
||||
|
||||
* 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.
|
||||
|
@ -80,9 +101,11 @@ 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.
|
||||
|
||||
Il semblerait qu'o2 ne sache pas envoyer des mails correctement. À étudier.
|
||||
|
|
|
@ -1,26 +1,30 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 06 juin 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h20
|
||||
* Fin : 20h33
|
||||
* 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)
|
||||
|
||||
* 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
|
||||
|
@ -28,6 +32,7 @@ défaut, on a modifié /etc/default/grub, pour rajouter la mention sur la quanti
|
|||
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.
|
||||
|
||||
|
@ -40,6 +45,7 @@ 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.
|
||||
|
@ -76,7 +82,8 @@ 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.
|
||||
|
||||
Daniel demande aux nounous qui ne se sont pas encore inscrites dessus de le
|
||||
faire.
|
||||
|
|
|
@ -1,27 +1,29 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 28 Juin 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h25
|
||||
* Fin : 20h47
|
||||
* 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
|
||||
* 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/
|
||||
|
||||
|
@ -39,7 +41,8 @@ la mise à jour.
|
|||
|
||||
=== SOGo ===
|
||||
|
||||
Vincent Le Gallic s'occupe de mettre en place SOGo, encadré par Pierre-Elliott. La partie
|
||||
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.
|
||||
|
||||
|
@ -123,4 +126,3 @@ Il faut aller dire aux switchs d'envoyer leurs logs sur ragnarok. De même pour
|
|||
les bornes wifi.
|
||||
|
||||
== Questions diverses ==
|
||||
|
||||
|
|
|
@ -1,115 +1,150 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 06 septembre 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h12
|
||||
* Fin : 21h20
|
||||
* 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
|
||||
* 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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à.
|
||||
À 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).
|
||||
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.
|
||||
À 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.
|
||||
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.
|
||||
Ç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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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 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.
|
||||
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.
|
||||
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)
|
||||
* 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 ?
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
!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).
|
||||
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.
|
||||
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.
|
||||
|
||||
Valentin voudrait importer la clef de l'IANA dans bind pour que nos DNS
|
||||
puissent valider du DNSsec.
|
||||
|
|
|
@ -1,36 +1,39 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Mardi 2 octobre
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h
|
||||
* Fin :
|
||||
* 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
|
||||
* 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.
|
||||
|
||||
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
|
||||
|
@ -39,23 +42,28 @@ 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 ===
|
||||
=== 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
|
||||
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é
|
||||
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.
|
||||
|
@ -72,7 +80,9 @@ 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.
|
||||
|
@ -90,4 +100,3 @@ voir ce qui arrive.
|
|||
==== Organisation du collège technique ====
|
||||
|
||||
Pauline a posé plusieurs questions, un résumé d'ici peu.
|
||||
|
||||
|
|
|
@ -1,43 +1,73 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Mardi 30 octobre 2012
|
||||
* Lieu : 2B
|
||||
* Début : 18h30
|
||||
* Fin : 22h07
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
* 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 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 ?
|
||||
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.
|
||||
|
@ -49,11 +79,13 @@ 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,
|
||||
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
|
||||
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 ====
|
||||
|
@ -69,35 +101,53 @@ 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,
|
||||
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
|
||||
|
||||
* 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 ?
|
||||
|
||||
## 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 ?
|
||||
## 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.
|
||||
## 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,
|
||||
|
@ -108,9 +158,11 @@ jouer la garantie des switches défectueux. Ou les mettre à la poubelle/donner.
|
|||
|
||||
==== DNSSEC ====
|
||||
|
||||
Valentin a activé la validation DNSSEC sur les résolveurs DNS du Cr@ns. Ça marche.
|
||||
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 : ∅))
|
||||
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.
|
||||
|
||||
|
@ -139,4 +191,3 @@ Sont motivés : Pierre-Elliott, Vincent, Olivier.
|
|||
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,35 +1,40 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 15 novembre 2012
|
||||
* Lieu : Salle Condorcet puis Fonteneau (à partir de 20h)
|
||||
* Début : 19h23
|
||||
* Fin : 21h04
|
||||
* 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
|
||||
|
||||
* 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
|
||||
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)...
|
||||
Un point est fait sur les garanties des serveurs (date d'expiration,
|
||||
renouvellement)...
|
||||
|
||||
Cf. [[CatégorieCrans/LesServeurs]].
|
||||
|
||||
|
@ -40,9 +45,11 @@ 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.
|
||||
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).
|
||||
|
@ -54,9 +61,11 @@ 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,
|
||||
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
|
||||
|
@ -70,6 +79,6 @@ 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.
|
||||
|
||||
|
|
|
@ -1,39 +1,44 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 29 Novembre
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h22
|
||||
* Fin : 21h26
|
||||
* 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
|
||||
|
||||
* 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
|
||||
## 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
|
||||
É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.
|
||||
|
@ -42,10 +47,12 @@ 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
|
||||
|
@ -55,7 +62,8 @@ minutes de load élevé). On va demander si on peut être débridés le week-end
|
|||
|
||||
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
|
||||
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.
|
||||
|
@ -73,27 +81,32 @@ 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.
|
||||
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
|
||||
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.
|
||||
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.
|
||||
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 ===
|
||||
|
||||
|
@ -103,6 +116,7 @@ On a remplacé 4 switches défectueux au niveau de HP. Pierre-Elliott recommence
|
|||
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é.
|
||||
|
@ -111,16 +125,21 @@ 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
|
||||
À 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
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,30 +1,34 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 13 Décembre 2012
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h25
|
||||
* Fin :
|
||||
* 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
|
||||
|
||||
* 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
|
||||
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)
|
||||
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.
|
||||
|
@ -35,71 +39,89 @@ 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
|
||||
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
|
||||
À 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.
|
||||
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
|
||||
* 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.
|
||||
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
|
||||
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
|
||||
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.
|
||||
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
|
||||
|
||||
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 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
|
||||
|
||||
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
|
||||
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.
|
||||
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
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,26 +1,28 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 10 janvier 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h16
|
||||
* Fin : 21h36
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
@ -49,6 +51,7 @@ 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).
|
||||
|
@ -66,17 +69,20 @@ 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 ?
|
||||
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.
|
||||
|
||||
|
@ -85,15 +91,18 @@ Elle (l'extension) a été mise en place par Valentin sur le domaine
|
|||
|
||||
À 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
|
||||
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)}}}.
|
||||
|
||||
|
@ -104,14 +113,15 @@ 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.
|
||||
|
@ -120,6 +130,7 @@ 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.
|
||||
|
@ -128,19 +139,22 @@ 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
|
||||
* 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
|
||||
|
||||
|
@ -153,8 +167,11 @@ 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
|
||||
|
||||
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
|
||||
|
@ -164,7 +181,8 @@ scripts qui supposaient manipuler un login (et non une adresse 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
|
||||
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.
|
||||
|
@ -173,6 +191,7 @@ 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
|
||||
|
@ -185,16 +204,20 @@ critiques en place dont on ne maîtrise pas la façon dont ils loguent
|
|||
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.
|
||||
|
||||
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.
|
||||
|
||||
* 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.
|
||||
|
||||
|
|
|
@ -1,27 +1,30 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : 24 Janvier 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h27
|
||||
* Fin : 21h17
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
||||
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.
|
||||
|
@ -29,6 +32,7 @@ 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)
|
||||
|
@ -36,6 +40,7 @@ Valentin propose d'autoriser les utilisateurs à utiliser fuse sur zamok. On
|
|||
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.
|
||||
|
@ -44,7 +49,8 @@ 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
|
||||
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
|
||||
|
@ -52,6 +58,7 @@ 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
|
||||
|
@ -59,34 +66,44 @@ 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.
|
||||
|
||||
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.
|
||||
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)>>
|
||||
|
||||
* le mail disait 20h. -- ZeldAurore <<DateTime(2013-01-25T12:59:56+0200)>>
|
||||
|
|
|
@ -1,20 +1,23 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 7 Février
|
||||
* Lieu : devant le Condorcet
|
||||
* Début : 20h08
|
||||
* Fin : 22h25
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
@ -35,21 +38,27 @@ 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.
|
||||
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.
|
||||
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)
|
||||
|
||||
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
|
||||
|
@ -62,22 +71,31 @@ 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'…
|
||||
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.
|
||||
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
|
||||
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.
|
||||
* 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.
|
||||
|
@ -85,36 +103,46 @@ 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.
|
||||
|
||||
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.
|
||||
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,
|
||||
|
||||
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.
|
||||
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 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
|
||||
/!\ 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.
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
* Réverse dns
|
||||
* filtrage p2p
|
||||
* upload
|
||||
* eduroam au Pdj : mdp du serveur radius, voir comment on fait…
|
||||
* null route sur le /16
|
||||
|
|
|
@ -1,88 +1,128 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 7 mars 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h42
|
||||
* Fin : 21h42
|
||||
* 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
|
||||
* 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
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
|
||||
|
||||
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.
|
||||
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.
|
||||
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
|
||||
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
|
||||
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).
|
||||
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.
|
||||
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).
|
||||
|
||||
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 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 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
|
||||
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
|
||||
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.
|
||||
|
||||
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]]
|
||||
|
||||
* 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.
|
||||
|
||||
|
|
|
@ -1,153 +1,241 @@
|
|||
= Réunion Nounous =
|
||||
|
||||
* Date : Jeudi 4 avril 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h30
|
||||
* Fin : 21h34
|
||||
* 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
|
||||
|
||||
* 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% :
|
||||
|
||||
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.
|
||||
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.
|
||||
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 à
|
||||
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
|
||||
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.
|
||||
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.
|
||||
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.)
|
||||
(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 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.
|
||||
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.
|
||||
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
|
||||
|
||||
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.
|
||||
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 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
|
||||
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 !
|
||||
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
|
||||
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]]).
|
||||
==== 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.
|
||||
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.
|
||||
|
||||
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).
|
||||
Il faut voir avec la DSI les modèles de bornes qu'elle compte acheter afin
|
||||
d'envisager une commande groupée.
|
||||
|
||||
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).
|
||||
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,
|
||||
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.
|
||||
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
|
||||
|
||||
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 !)
|
||||
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]].
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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]].
|
||||
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.
|
||||
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
|
||||
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.
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,75 +1,153 @@
|
|||
= Réunion Nounous =
|
||||
* Date : 18 Avril 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h22
|
||||
* Fin : 21h21
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
|
||||
* 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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 ?
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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é.
|
||||
|
||||
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
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,38 +1,51 @@
|
|||
= Réunion Nounous =
|
||||
* Date : Jeudi 2 mai 2013
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h21
|
||||
* Fin : 20h40
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
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
|
||||
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
|
||||
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
|
||||
[[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.
|
||||
=== 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
|
||||
|
@ -40,13 +53,17 @@ complètement la gestion des disques des machines virtuelles : actuellement elle
|
|||
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.
|
||||
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]].
|
||||
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 ==
|
||||
|
||||
|
@ -55,26 +72,32 @@ 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).
|
||||
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.
|
||||
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
|
||||
* [[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.
|
||||
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.
|
||||
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}}}.
|
||||
|
||||
|
@ -89,7 +112,8 @@ 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
|
||||
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
|
||||
|
@ -107,4 +131,3 @@ 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}}}.
|
||||
|
||||
|
|
|
@ -1,39 +1,47 @@
|
|||
= Réunion Nounous =
|
||||
* Date : Jeudi 16 mai 2013
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h32
|
||||
* Fin : 21h30
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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
|
||||
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.
|
||||
|
@ -61,7 +69,8 @@ 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.
|
||||
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.
|
||||
|
@ -76,9 +85,11 @@ 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
|
||||
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
|
||||
|
@ -90,21 +101,22 @@ 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
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -112,14 +124,18 @@ 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
|
||||
!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).
|
||||
|
||||
* 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).
|
||||
|
|
|
@ -1,72 +1,86 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 30 Mai 2013
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h30
|
||||
* Fin :
|
||||
* 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
|
||||
* 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
|
||||
|
||||
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)
|
||||
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é.
|
||||
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,
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
* 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
|
||||
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
|
||||
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
|
||||
Il faut documenter l'appli si on veut passer de xen à proxmox. Entres autres
|
||||
pour la gestion
|
||||
des disques.
|
||||
|
||||
==== Ntp sous proxmox ====
|
||||
|
@ -75,14 +89,17 @@ 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
|
||||
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
|
||||
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
|
||||
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.
|
||||
|
|
|
@ -1,22 +1,22 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 13 Juin 2013
|
||||
* Lieu : Fonteneau ou Tocqueville
|
||||
* Début : 19h18
|
||||
* Fin : 20h53
|
||||
* 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
|
||||
* 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
|
||||
|
@ -29,6 +29,7 @@ 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.
|
||||
|
@ -36,12 +37,16 @@ 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
@ -51,6 +56,7 @@ 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.
|
||||
|
||||
|
@ -58,18 +64,24 @@ 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
|
||||
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.
|
||||
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.
|
||||
|
||||
Un technicien est venu réparer l'imprimante. Jusque là, elle remarche. Elle
|
||||
boure relativement souvent. Il faudra également recommander du papier.
|
||||
|
|
|
@ -1,29 +1,33 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Lundi 23 septembre 2013
|
||||
* Lieu : Espace Condorcet
|
||||
* Début : 19h25
|
||||
* Fin : 20h49
|
||||
|
||||
* 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
|
||||
* 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.
|
||||
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
|
||||
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.
|
||||
|
@ -32,54 +36,78 @@ 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
* 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}}}.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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é.
|
||||
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.
|
||||
|
@ -93,87 +121,126 @@ 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
{{{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.
|
||||
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.
|
||||
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.
|
||||
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)
|
||||
* 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.
|
||||
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 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 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)
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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)>>
|
||||
* 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.
|
||||
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é".
|
||||
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 ====
|
||||
|
||||
|
|
|
@ -1,20 +1,23 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Jeudi 03 Octobre 2013
|
||||
* Lieu : Pavillon des Jardin
|
||||
* Début : 19h07
|
||||
* Fin : 19h57
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
|
@ -23,19 +26,26 @@ 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
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).
|
||||
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€).
|
||||
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 ===
|
||||
|
||||
|
@ -43,26 +53,43 @@ 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).
|
||||
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).
|
||||
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.
|
||||
* 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).
|
||||
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).
|
||||
|
|
|
@ -1,19 +1,21 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Jeudi 17 octobre 2013
|
||||
* Lieu : Pavillon des Jardin
|
||||
* Début : 19h15
|
||||
* Fin : 21h13
|
||||
|
||||
* 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
|
||||
|
||||
* 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 ==
|
||||
|
||||
|
@ -23,8 +25,9 @@ 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
|
||||
|
||||
* 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).
|
||||
|
@ -39,53 +42,67 @@ sur leur interface filaire. Ça fait une boucle. Le réseau aime pas ça. Du tou
|
|||
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
|
||||
|
||||
''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
|
||||
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)
|
||||
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/]],
|
||||
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
|
||||
|
||||
* 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)
|
||||
* 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
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
|
@ -97,18 +114,22 @@ 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.
|
||||
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.
|
||||
Ç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.
|
||||
|
||||
|
@ -116,7 +137,9 @@ Une fois les tests concluant, demander à une nounou de pusher.
|
|||
### Thanks ! -- Zelda
|
||||
|
||||
=== Imprimante ===
|
||||
Lucas et Daniel ont tourné les feuille de π/2rad sans les bacs de l'imprimante. Du
|
||||
|
||||
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.
|
||||
|
||||
|
@ -124,8 +147,10 @@ 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).
|
||||
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.
|
||||
|
@ -136,7 +161,9 @@ 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.
|
||||
|
@ -145,20 +172,25 @@ 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.
|
||||
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.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,24 +1,35 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : 31 Octobre 2013
|
||||
* Lieu : 2B
|
||||
* Début : 19h10
|
||||
* Fin : 19h30
|
||||
|
||||
* Date : 31 Octobre 2013
|
||||
* Lieu : 2B
|
||||
* Début : 19h10
|
||||
* Fin : 19h30
|
||||
|
||||
== Présents ==
|
||||
* Valentin Samir
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
* 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.
|
||||
=== 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.
|
||||
|
||||
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.
|
||||
|
||||
Aucune.
|
||||
|
|
|
@ -1,27 +1,33 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Jeudi 14 Novembre 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h11
|
||||
* Fin : 21h20
|
||||
|
||||
* 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
|
||||
|
||||
* 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
|
||||
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
|
||||
|
@ -30,106 +36,144 @@ 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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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 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.
|
||||
|
||||
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).
|
||||
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.
|
||||
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
|
||||
|
||||
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)}}}.
|
||||
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é
|
||||
|
||||
#### 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.
|
||||
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)
|
||||
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
|
@ -140,4 +184,3 @@ Il faut soumettre ça au CA, et mettre à jour les affiches/wiki.
|
|||
|
||||
Xen vers proxox migration dur dur, achat serveur ?
|
||||
Dyson weak weak, achat seveur ?
|
||||
|
||||
|
|
|
@ -1,65 +1,97 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 28 Novembre 2013
|
||||
* Lieu : Salle Condorcet (bât d'Alembert)
|
||||
* Début : 19h00
|
||||
* Fin : ''avant 22h''
|
||||
* 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
|
||||
|
||||
* 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é.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
. 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
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€.
|
||||
|
||||
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€.
|
||||
|
|
|
@ -1,73 +1,112 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date :Jeudi 9 janvier 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h25
|
||||
* Fin : 20h55
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
## 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 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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).
|
||||
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).
|
||||
|
|
|
@ -1,76 +1,112 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : jeudi 23 janvier 2014
|
||||
* Lieu : salle Condorcet, bâtiment d'Alembert
|
||||
* Début : 19h25
|
||||
* Fin : 20h30
|
||||
|
||||
* 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
|
||||
* 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é.
|
||||
|
||||
##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 ?)
|
||||
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)>>
|
||||
|
||||
* 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).
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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).
|
||||
|
||||
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.
|
||||
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.
|
||||
* 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).
|
||||
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 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.
|
||||
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.
|
||||
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ù.
|
||||
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).
|
||||
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).
|
||||
|
|
|
@ -1,17 +1,22 @@
|
|||
= 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
|
||||
|
||||
* 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.
|
||||
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).
|
||||
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.
|
||||
|
||||
|
@ -25,13 +30,15 @@ Todo : écrire une application sur l'intranet2 (dans mon compte) pour enregistre
|
|||
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 à
|
||||
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
|
||||
|
@ -41,23 +48,32 @@ 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.
|
||||
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.
|
||||
|
||||
Il y a une case à cocher dans l'intranet2 dans l'application machines pour désactiver ou réactiver ce comportement.
|
||||
* {{{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
|
||||
|
||||
* {{{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
|
||||
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).
|
||||
|
@ -68,35 +84,52 @@ 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.
|
||||
|
||||
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]]).
|
||||
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.
|
||||
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,
|
||||
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.
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
|
||||
La DSI abandonne le ssid ENS Cachan. On arrête donc définitivement de le
|
||||
diffuser.
|
||||
|
|
|
@ -1,93 +1,141 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : 20 février 2014
|
||||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||||
* Début : 19h19
|
||||
* Fin : 21h00
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
|
||||
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,
|
||||
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.
|
||||
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.
|
||||
|
||||
Les gens présents ont l'air assez enthousiastes pour le wifi. Une option similaire en filaire reste à discussion.
|
||||
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.
|
||||
|
||||
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.
|
||||
Les gens présents ont l'air assez enthousiastes pour le wifi. Une option
|
||||
similaire en filaire reste à discussion.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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é)
|
||||
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.
|
||||
|
||||
À voir si on veut utiliser l'objet pour gérer les certificats d'une manière générale…
|
||||
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
|
||||
|
||||
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
|
||||
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.
|
||||
''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.
|
||||
|
||||
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♡).
|
||||
|
||||
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.
|
||||
Daniel annonce donc une « petite » maintenance sur CransIncidents et sur les
|
||||
news.
|
||||
|
|
|
@ -1,116 +1,196 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Jeudi 13 mars 2014
|
||||
* Lieu : Salle de conférence du Pavillon de Jardins
|
||||
* Début : 19h22
|
||||
* Fin : 21h12
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
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).
|
||||
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.
|
||||
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.)
|
||||
|
||||
* 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.
|
||||
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 ».
|
||||
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.
|
||||
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.
|
||||
{{{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.
|
||||
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).
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
PEB a créé 27 disques logiques sur la baie, olasd trouve que ce n'est pas
|
||||
adapté, quid des autres ?
|
||||
|
||||
* /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)
|
||||
* 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.
|
||||
|
||||
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]]
|
||||
|
||||
* 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}}}.
|
||||
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é.
|
||||
|
||||
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.
|
||||
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).
|
||||
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).
|
||||
|
|
|
@ -1,17 +1,17 @@
|
|||
= InterNounous =
|
||||
|
||||
* Date : Jeudi 27 mars 2014
|
||||
* Lieu : Salle de conf au Pavillon des Jardins
|
||||
* Heure : 19h33
|
||||
* Fin : 21h00
|
||||
* 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
|
||||
* Aymeric Labatut
|
||||
* Daniel Stan
|
||||
* Jordan Delorme
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
= OdJ =
|
||||
|
||||
|
@ -20,15 +20,20 @@
|
|||
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 ??)
|
||||
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).
|
||||
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
|
||||
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 ==
|
||||
|
@ -36,48 +41,64 @@ plus complexes à faire, sauf à forwarder son agent, ou à s'ajouter une clef s
|
|||
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é).
|
||||
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.
|
||||
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…
|
||||
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]] !
|
||||
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.
|
||||
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)
|
||||
(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.
|
||||
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
|
||||
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
|
||||
* […]
|
||||
|
||||
* 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
|
||||
!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 ?
|
||||
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.
|
||||
|
||||
|
|
|
@ -1,131 +1,199 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 10 avril 2014
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h30
|
||||
* Fin : 21h15
|
||||
* Date : Jeudi 10 avril 2014
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h30
|
||||
* Fin : 21h15
|
||||
|
||||
== Présents ==
|
||||
* Pierre-Elliott Becue
|
||||
* Jordan Delorme
|
||||
* Vincent Le Gallic
|
||||
* Lucas Serrano
|
||||
|
||||
* 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)>>
|
||||
Tous les certificats accessibles depuis l'extérieur du campus ont été
|
||||
renouvelés sauf redisdead.
|
||||
|
||||
Pierre-Elliott a plus ou moins écrit une page Wiki pour informer les adhérents de la faille de sécurité.
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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 ?
|
||||
|
||||
* 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
|
||||
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.
|
||||
* 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
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
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
|
||||
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)
|
||||
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)>>
|
||||
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
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
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 à
|
||||
|
||||
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)
|
||||
|
||||
* Fiche câblage
|
||||
* Locaux sensibles
|
||||
* Access points (WIFI)
|
||||
|
||||
En bonus (non lié à la convention)
|
||||
* Livret d'accueil du CROUS
|
||||
|
||||
* 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.
|
||||
|
||||
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)>>
|
||||
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)>>
|
||||
|
|
|
@ -1,115 +1,167 @@
|
|||
= Internounous =
|
||||
* Date : Jeudi 8 mai 2014
|
||||
* Lieu : Salle de conférence du Pavillon de Jardins
|
||||
* Début : 19h13
|
||||
* Fin : 21h14
|
||||
|
||||
* 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)
|
||||
* 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
|
||||
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
|
||||
|
||||
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 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
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
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
|
||||
* 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
|
||||
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.
|
||||
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,
|
||||
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
|
||||
|
||||
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
|
||||
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.
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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)
|
||||
|
||||
* 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.
|
||||
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 !
|
||||
|
||||
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
|
||||
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.
|
||||
|
||||
=== 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.
|
||||
|
|
|
@ -1,65 +1,93 @@
|
|||
= Réunion inter-nounous =
|
||||
|
||||
* Date : Jeudi 22 mai 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 20h41
|
||||
* 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
|
||||
|
||||
* 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).
|
||||
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.
|
||||
|
||||
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.
|
||||
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
|
||||
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.
|
||||
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)
|
||||
|
||||
* 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.
|
||||
|
||||
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
|
||||
|
||||
Ç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)
|
||||
|
||||
* 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
|
||||
|
||||
* lc_ldap : locks sur un objet (actuellement, locks uniquement sur une valeur
|
||||
donnée d'un type donné)
|
||||
* Imprimante
|
||||
* Site du Gala
|
||||
|
|
|
@ -1,62 +1,89 @@
|
|||
= Réunion inter-nounous =
|
||||
|
||||
* Date : Jeudi 5 juin 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : 20h38
|
||||
* 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
|
||||
|
||||
* 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 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.
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
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).
|
||||
* 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.
|
||||
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.
|
||||
|
||||
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
|
||||
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 :
|
||||
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)]]
|
||||
|
||||
|
|
|
@ -1,80 +1,118 @@
|
|||
= Réunion inter-nounous =
|
||||
|
||||
* Date : Jeudi 19 juin 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h52
|
||||
* Fin : 21h10
|
||||
* 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
|
||||
|
||||
* 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).
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
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
|
||||
* 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… ?).
|
||||
|
||||
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… ?).
|
||||
|
|
|
@ -1,150 +1,210 @@
|
|||
= Réunion inter-nounous =
|
||||
|
||||
* Date : Jeudi 3 juillet 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 18h47
|
||||
* Fin : 20h30
|
||||
* 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
|
||||
|
||||
* 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).
|
||||
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
|
||||
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'''.
|
||||
* {{{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
|
||||
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,
|
||||
|
||||
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é.
|
||||
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.
|
||||
|
||||
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.
|
||||
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é.
|
||||
|
||||
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).
|
||||
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.
|
||||
|
||||
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.
|
||||
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.
|
||||
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,
|
||||
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
|
||||
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.
|
||||
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.
|
||||
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
|
||||
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.
|
||||
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
|
||||
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.
|
||||
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.
|
||||
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 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.
|
||||
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),
|
||||
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}}}.
|
||||
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
|
||||
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.
|
||||
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
|
||||
|
||||
* 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
|
||||
## 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
|
||||
|
||||
* 4h
|
||||
* Le lendemain
|
||||
|
||||
## Il est 20h. Paris s'éveille (or something). Sergio nous attend il fait faim.
|
||||
|
||||
|
|
|
@ -1,98 +1,151 @@
|
|||
= Réunion du collège technique =
|
||||
|
||||
* Date : Jeudi 11 septembre
|
||||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||||
* Début : 19h00
|
||||
* Fin : 21h01
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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.)
|
||||
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.
|
||||
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.
|
||||
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, 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.
|
||||
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 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®…
|
||||
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.
|
||||
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.
|
||||
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
|
||||
* 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.
|
||||
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.)
|
||||
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.
|
||||
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 !
|
||||
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.
|
||||
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
|
||||
* 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é
|
||||
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).
|
||||
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 ===
|
||||
|
||||
|
@ -100,16 +153,20 @@ 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
|
||||
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.
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,17 +1,18 @@
|
|||
= Réunion du collège technique =
|
||||
|
||||
* Date : Jeudi 25 septembre
|
||||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||||
* Début : 19h00
|
||||
* Fin :
|
||||
* 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
|
||||
|
||||
|
@ -20,10 +21,11 @@
|
|||
=== OwnCloud ===
|
||||
|
||||
=== WiFi ===
|
||||
|
||||
## On s'est remotivé pour poser des bornes, alors autant continuer !
|
||||
|
||||
=== Prochains séminaires/ateliers ===
|
||||
|
||||
## Quid de mardi prochain ?
|
||||
|
||||
=== Questions diverses ===
|
||||
|
||||
|
|
|
@ -1,70 +1,89 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 9 octobre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h15
|
||||
* Fin : 20h30
|
||||
* 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)
|
||||
|
||||
* 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
|
||||
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
|
||||
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.)
|
||||
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.
|
||||
|
||||
* 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…).
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
|
||||
Rappel sur l'existence de munin.crans.org et autostatus.crans.org et le
|
||||
nettoyage à faire par les nounous.
|
||||
|
||||
=== Permutation séminaires/CA/IN ===
|
||||
|
||||
|
@ -72,15 +91,22 @@ 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.)
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,70 +1,131 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 23 octobre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h15
|
||||
* Fin : 20h20
|
||||
* 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)
|
||||
|
||||
* 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
|
||||
|
||||
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
|
||||
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.
|
||||
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
|
||||
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.
|
||||
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.
|
||||
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).
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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).
|
||||
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.
|
||||
|
||||
/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.
|
||||
|
||||
* 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).
|
||||
|
||||
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.
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,112 +1,149 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 6 novembre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h00
|
||||
* Fin : 20h22
|
||||
* 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
|
||||
* 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.
|
||||
|
||||
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/
|
||||
|
||||
* 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)
|
||||
|
||||
* 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
|
||||
|
||||
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
|
||||
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
|
||||
|
||||
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)
|
||||
* 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
|
||||
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,
|
||||
|
||||
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
|
||||
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.
|
||||
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).
|
||||
|
||||
Ç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 €
|
||||
* 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 €
|
||||
* 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 €
|
||||
* 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 €
|
||||
* 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 €
|
||||
|
||||
* 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 €.
|
||||
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.
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,90 +1,123 @@
|
|||
= Réunion du Collège Technique =
|
||||
|
||||
* Date : Jeudi 20 novembre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h16
|
||||
* Fin : 20h21
|
||||
* 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
|
||||
* 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.
|
||||
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.
|
||||
|
||||
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 ?).
|
||||
Au niveau serveur, on a 4 (ou 5?) serveurs dell sous les bras, on peut
|
||||
facilement s'en débarrasser d'un.
|
||||
|
||||
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.)
|
||||
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
|
||||
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
|
||||
* 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
|
||||
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
|
||||
* 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")
|
||||
* 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
|
||||
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.
|
||||
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 !)
|
||||
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,
|
||||
|
||||
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
|
||||
|
||||
(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
|
||||
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
|
||||
|
||||
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 ?) ===
|
||||
|
@ -92,9 +125,11 @@ un apprenti pour le faire (buzzwords: python, ldap, freeradius).
|
|||
[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.
|
||||
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
|
||||
|
@ -107,6 +142,10 @@ 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.
|
||||
|
||||
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.
|
||||
|
|
|
@ -1,46 +1,73 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Jeudi 04 décembre 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 19h56
|
||||
|
||||
* 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)
|
||||
|
||||
* 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
|
||||
|
||||
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.
|
||||
|
||||
* 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.
|
||||
|
||||
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).
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
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...
|
||||
|
|
|
@ -1,13 +1,15 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Jeudi 8 janvier 2015
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h12
|
||||
* Fin : 19h56
|
||||
|
||||
* 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
|
||||
|
||||
* Gabriel Détraz
|
||||
* Raphaël-David Lasseri
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
== Ordre du jour ==
|
||||
|
||||
|
@ -20,58 +22,80 @@ 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.
|
||||
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 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
|
||||
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
|
||||
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),
|
||||
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
|
||||
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
|
||||
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
|
||||
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'.
|
||||
|
||||
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
|
||||
|
||||
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
|
||||
|
||||
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.
|
||||
|
||||
Aucune urgence mais il serait intéressant de réfléchir un peu à cette piste et
|
||||
continuer à se renseigner.
|
||||
|
|
|
@ -1,87 +1,127 @@
|
|||
= Réunion du Collège Technique =
|
||||
* Date : Jeudi 22 janvier 2015
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h14
|
||||
* Fin : 20h30
|
||||
|
||||
* 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
|
||||
* 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.
|
||||
* 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.
|
||||
|
||||
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€
|
||||
|
||||
* 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 €.
|
||||
|
||||
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
|
||||
|
||||
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é.
|
||||
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
|
||||
À 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.
|
||||
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.
|
||||
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.
|
||||
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.
|
||||
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
|
||||
/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.
|
||||
|
||||
* 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.
|
||||
|
||||
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.
|
||||
|
||||
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 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 ?)
|
||||
|
||||
|
|
|
@ -1,44 +1,64 @@
|
|||
= 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)>>
|
||||
|
||||
* 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
|
||||
|
||||
* 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.
|
||||
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
|
||||
* 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
|
||||
|
||||
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.
|
||||
Au terme des échanges, si on reçoit effectivement des 2620, les switchs
|
||||
disponibles et fonctionnels seront donc :
|
||||
|
||||
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
|
||||
* 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.
|
||||
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
|
||||
|
@ -47,47 +67,65 @@ Vu qu'un 2620 est déjà installé (batb-5) et qu'il nous en reste plusieurs, on
|
|||
## 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.
|
||||
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.
|
||||
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
|
||||
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.)
|
||||
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.)
|
||||
|
||||
À 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)
|
||||
* 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)
|
||||
|
||||
* 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.
|
||||
* 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