Merge branch 'ajout_cr' into 'master'
Ajout cr See merge request nounous/documentation!17merge-requests/17/merge
korenstin
commit
45f92150ee
|
|
@ -0,0 +1,118 @@
|
|||
# Réunion IN
|
||||
|
||||
Ce jeudi 2 octobre a eu lieu une internounou.
|
||||
|
||||
## Présents
|
||||
|
||||
* Frédéric Pauget (Fred)
|
||||
* Manuel Sabban (M@nu)
|
||||
* Mathieu Segaud (Regala)
|
||||
* Nicolas Stransky (Nico)
|
||||
* Sandor Szakacs
|
||||
* Sébastien Li-Thiao-Te (Sayan)
|
||||
* Vincent Bernat (`Vince||`)
|
||||
* Vincent Hanquez (Tab)
|
||||
* Yves-Laurent Allaert (Manathan, ouvre-bouteille)
|
||||
|
||||
## Élection du RTC
|
||||
|
||||
Le seul candidat est Fred dont le programme est de synchroniser le
|
||||
travail de chacun. Fred est élu à l'unanimité des nounous présentes.
|
||||
|
||||
## Mailman
|
||||
|
||||
La nouvelle version de mailman est en Français et sera donc installée
|
||||
à la place de la version actuelle.
|
||||
|
||||
Pour simplifier l'accès à mailman, un virtual host lists.crans.org
|
||||
dans Apache. Quant à laisser toutes les listes dans un sous-domaine
|
||||
lists.crans.org, cela n'apporte pour le moment pas d'avantage étant
|
||||
donné que les noms ne sont pas en collision avec des noms réels.
|
||||
|
||||
Il serait souhaitable de préfixer le nom des mailing lists par la
|
||||
raison d'être de la liste (club-, ens-). Les listes actuelles seront
|
||||
éventuellement renommées avec la prochaine version de mailman. Les
|
||||
archives pouvant prendre trop de place, elles ne seront pas
|
||||
disponibles pour les ML non CRANS.
|
||||
|
||||
## Script d'inscription nounou et câbleur
|
||||
|
||||
La partie en Perl est à refaire. Il est également possible de
|
||||
synchroniser les listes avec les groupes grâce à mailman mais cela ne
|
||||
règle pas entièrement le problème (cf les alias batx).
|
||||
|
||||
## Site web
|
||||
|
||||
Certaines pages ne sont plus à jour. Il serait possible de recruter
|
||||
une personne pour s'occuper du site web. Certaines pages pourraient
|
||||
être générées dynamiquement (genre, liste des câbleurs). Un
|
||||
département de l'ENS pourrait mettre le site du CRANS comme projet ?
|
||||
Il s'agit seulement de trouver quelqu'un qui fait des mises à jour du
|
||||
site, ce qui peut être assez inintéressant pour un projet et assez
|
||||
inadapté.
|
||||
|
||||
## Moteur de recherche news
|
||||
|
||||
Les tac.* expireront au bout de 6 mois. Un moteur de recherche
|
||||
incrémental sur les news pourrait être installé, comme swish++ qui
|
||||
devra être interfacé avec le serveur web. Les newsgroups pourront être
|
||||
accessibles également via une interface web (avec mot de passe depuis
|
||||
l'extérieur). Reste à trouver quelqu'un pour le faire.
|
||||
|
||||
## Glasnost
|
||||
|
||||
Il refonctionne de nouveau, on continue de l'utiliser jusqu'à la
|
||||
prochaine upgrade qui foire pour le remplacer par un autre système de
|
||||
publication, style SPIP, même si celui-ci n'intègre pas de système de
|
||||
vote.
|
||||
|
||||
## Gestion du FTP
|
||||
|
||||
Le miroir Gentoo prend de plus en plus de place (plus de 33 Go, la
|
||||
partition est pleine), il faudrait regarder si on peut lui faire
|
||||
prendre moins de place. Il est possible de racheter un disque dur si
|
||||
besoin ou alors de virer le miroir Gentoo. Pour se fixer, il sera
|
||||
souhaitable de faire des statistiques.
|
||||
|
||||
## Scripts de gestions des adhérents
|
||||
|
||||
edit pourrait être modifié pour vérifier que les fichiers sont sous la
|
||||
bonne forme. L'édition à la main des fichiers sera interdite (plus de
|
||||
edit).
|
||||
|
||||
## Sayan nounou
|
||||
|
||||
Sayan a installé Tanek qui sert désormais de machine de
|
||||
sauvegarde. Pour le moment, seuls quelques fichiers systèmes sont
|
||||
sauvegardés. A terme, il sera possible de sauvegarder mails et homes,
|
||||
mais il faudra de nouveaux disques (2 nouveaux disques). Le site web
|
||||
n'est pas encore sauvé, les logs ne sont pas sauvegardés non plus et
|
||||
il faudrait le faire (squid + postfix). Sayan est passé nounou à
|
||||
l'unaminité.
|
||||
|
||||
## Switchs
|
||||
|
||||
Les switchs Dlink achetés l'an dernier s'avèrent en fait très chers
|
||||
comparés à ce qu'on trouve sur le marché, aussi bien chez Dlink que
|
||||
chez d'autres constructeurs. Par exemple, on trouve le Dlink DES 3226S
|
||||
à 490 euros HT, c'est la version manageable de ce qu'on a
|
||||
actuellement. Plus intéressant, 3Com fait le 4226T et 4228G tous les
|
||||
deux à 490 euros HT. Ils sont tous les deux 24 ports mais à la
|
||||
différence du Dlink intègrent deux ports gigabits cuivre. En
|
||||
contrepartie, ils n'ont pas l'agrégation de liens sur les ports
|
||||
normaux (mais on peut chaîner en gigabit).
|
||||
|
||||
Le 4226T est manageable et peut manager 3 4228G. Son fond de panier
|
||||
est de 8.8 GBps (comme le DLink). Le 4228G a un fond de panier plus
|
||||
élevé, la possibilité de mettre deux ports GIBC fibre mais n'est pas
|
||||
manageable (il dispose tout de fois d'une console série comme les
|
||||
Dlink que l'on a actuellement).
|
||||
|
||||
Dans le futur, on pourrait donc acheter une combinaison de ces switchs
|
||||
(ou encore du 4250T, version 48 ports, manageable, mais sans extension
|
||||
fibre optique) pour mettre dans les bâtiments. Cette possibilité sera
|
||||
étudiée plus en détails.
|
||||
|
||||
Cerise sur le gâteau, tous ces switchs supportent le multicast.
|
||||
|
||||
La réunion a pris fin vers 22h50.
|
||||
|
|
@ -0,0 +1,119 @@
|
|||
# Réunion IN
|
||||
|
||||
Le 27 novembre 2003 une internounou (réunion privée) s'est tenue.
|
||||
|
||||
Présents :
|
||||
|
||||
* Sébastien Li-Thiao-Té (Sayan)
|
||||
* Manuel Sabban (M@nu)
|
||||
* Yves-Laurent Allaert (Manathan)
|
||||
* Nicolas Sturmel (Personne)
|
||||
* Frédéric Pauget (Fred)
|
||||
|
||||
Excusés :
|
||||
|
||||
* Nicolas Salles (mo²)
|
||||
* Nicolas Stransky (Nico)
|
||||
* Mathieu Segaud (Régala)
|
||||
|
||||
## Bilan sur les switchs HP achétés et avenir
|
||||
|
||||
Bon fonctionnement des switchs au B. L'équipement va être poursuivi au
|
||||
G et par l'achat d'un backbone gigabit neuf.
|
||||
A terme les liaisons inter-bat seront Gigabit et toutes les prises
|
||||
manageables avec filtrage d'IP.
|
||||
|
||||
## Avenir de egon
|
||||
|
||||
L'utilisation de Egon en machine de test est satisfaisant : on ne
|
||||
change rien.
|
||||
|
||||
## Discussions sur le système de sauvegarde
|
||||
|
||||
Il y a un problème de sychronisation des homes plus particulièrement
|
||||
concernant les permissions sur les répertoires : la sauvegarde se fait
|
||||
en root sur zamok mais pas sur tanek ; il n'est pas possible de
|
||||
redonner les bonnes permissions.
|
||||
|
||||
Solution : sauvgardes sur zamok sans être root mais en étant un user
|
||||
'normal' appartenant aux groupes de users, les répertoires non
|
||||
lisibles par cet user seront ignorés.
|
||||
|
||||
Actuellement les mails, les news, le site web, les logs et confs des
|
||||
serveurs sont sauvegardés régulièrement. Le problème des homes va être
|
||||
résolus et seront donc sauvegardés.
|
||||
|
||||
## La détection de DHCP 'pirates' et de broswe master samba
|
||||
|
||||
La détection de DHCP est opérationelle, un test est effectué toutes
|
||||
les 10 minutes. Aucun DHCP pirate détecté.
|
||||
|
||||
Pour le cas des browse master samba, un premier test a montré que le
|
||||
browse master n'était quasiment jamais zamok. Mais que le nom du le
|
||||
nom du browse master obtenu ne correspondait pas aux entrées DNS.
|
||||
La solution envisagée est de construire une table de correspondance en
|
||||
demandant les noms samba à toutes les machines réseau. Une fois cette
|
||||
table construite il sera possible de savoir à quel utilisateur
|
||||
adresser le mail d'avertissement comme quoi sa machine est browse
|
||||
master à la place de zamok.
|
||||
|
||||
## Les virus
|
||||
|
||||
Il a été décidé de rechercher un antivirus de mail pouvant être
|
||||
installé au crans. Toutefois il devra être possible aux adhérents de
|
||||
désactiver se service pour leur compte ; celui-ci sera activé par
|
||||
défaut.
|
||||
|
||||
## Le PHP sur zamok
|
||||
|
||||
Il est décidé d'étudier la sécurité du PHP sur zamok et le cas échéant
|
||||
de restreindre son utilisation.
|
||||
|
||||
Digression : le mysql sur zamok : est-ce utile ? voir qui l'utilise et
|
||||
pourquoi ?
|
||||
|
||||
## Le corbeau
|
||||
|
||||
Les clubs sont actuellement exclus du corbeau et un nouveau corbeau
|
||||
est dans le nid : son cahier des charges est :
|
||||
|
||||
* Champ From valide depuis la zone crans (mail@crans)
|
||||
* prévoir une blacklist,
|
||||
* prévoir une modération du corbeau (lecture du message par
|
||||
* modérateur _avant_ publication)
|
||||
|
||||
## data.tar
|
||||
|
||||
Explications demandées sur roots.
|
||||
|
||||
## Les anciens comptes sur les machines (ménage dans les users et groupes)
|
||||
|
||||
Il sera procédé un ménage des comptes inutilisés selon la méthode des
|
||||
années précédents.
|
||||
|
||||
Un ménage des utilisateurs privilégiés est commencé :
|
||||
la liste des personnes ayant le droit d'édition des sites des clubs et du site
|
||||
de l'association à été réduite, si vous aviez les droits mais que le ménage ne
|
||||
vous a pas épargné et que vous en avez besoin, envoyer un mail à nounou. un
|
||||
ménage a été également effectué dans les administrateurs.
|
||||
|
||||
## moteur de recherche news
|
||||
|
||||
Le moteur est fonctionnel mis à part la visualisation des pièces
|
||||
jointes non texte. Ce point est en cours d'amélioration (surtout pour
|
||||
les images).
|
||||
Une fonctionnalité requise est également la lecture des messages
|
||||
signés pgp.
|
||||
|
||||
## Clés du B
|
||||
|
||||
Le président à laissé sa clef du 0B au nounous qui pourront mieux s'en
|
||||
servir en cas de problème.
|
||||
|
||||
## ptrace-kmod.c
|
||||
|
||||
(code permettant de passer root en exploitant une faille de sécurité)
|
||||
|
||||
Le fichier est postérieur à la mise à jour de zamok contre cette
|
||||
faille. Toutefois une demande d'explication pour la précense de ce
|
||||
fichier est requise.
|
||||
|
|
@ -0,0 +1,130 @@
|
|||
# Réunion IN
|
||||
|
||||
Ce soir, jeudi 11 mars 2004, a eu lieu au PdJ une internounou.
|
||||
|
||||
Présents :
|
||||
|
||||
* Arnaud Sternchüss (Schultzy)
|
||||
* Benoit Rozel
|
||||
* Charles Signorini
|
||||
* Christophe Calvès (Grand Tof)
|
||||
* Frédéric Pauget (Fred)
|
||||
* Manuel Sabban (M@nu)
|
||||
* Mathieu Bérard
|
||||
* Mathieu Ségaud (Regala)
|
||||
* Olivier Deleage (O-live)
|
||||
* Sandor Szakacs
|
||||
* Sébastien Barthélemy (Seb)
|
||||
* Sébastien Li-Thiao-Te (Sayan)
|
||||
* Vincent Bernat (`Vince||`)
|
||||
* Yohan Le Diraison (Ryo)
|
||||
|
||||
## Passage en testing ?
|
||||
|
||||
Sila étant aussi performant que Egon, Egon pourrait remplacer Sila,
|
||||
Sila serait passé en testing et en 2.6 et des tests seraient
|
||||
conduits. Une fois que Sila marchera bien en testing et avec un 2.6,
|
||||
il reprendra sa place. Egon sera passé en testing avant de remplacer
|
||||
Sila.
|
||||
|
||||
Pour résoudre les problemes de log actuels de Sila, son immobilisation
|
||||
pourrait servir également à revoir la taille des partitions.
|
||||
|
||||
Remplacement du FTP d'OpenBSD par ProFTPd.
|
||||
|
||||
## Wifi
|
||||
|
||||
Les bornes Linksys disposent de Linux et il y a sur le web beaucoup de
|
||||
pages expliquant comment le modifier pour divers besoins.
|
||||
|
||||
La borne pourrait être équipée de IPv6 + IPsec.
|
||||
|
||||
Linksys WP54G
|
||||
|
||||
## Switchs
|
||||
|
||||
Trois nouveaux switchs seraient commandés dont 1 pour le G. Les deux
|
||||
autres iraient au I en raison de sa position centrale, y compris de
|
||||
par sa topologie (les fibres pour le H, I et J y arrivent). Le seul
|
||||
hub qui reste actuellement est au M (en plus du PdJ). Le matériel
|
||||
inutilisé sera utilisé lors des installs party.
|
||||
|
||||
## Ménage sur les comptes administrateurs
|
||||
|
||||
Les personnes n'ayant pas répondu au dernier mail sur le sujet
|
||||
perdrons leurs comptes sur le serveur.
|
||||
|
||||
## Todo list
|
||||
|
||||
### Scripts d'adhésion
|
||||
|
||||
Il y a plus de vérifications qu'auparavant. Notamment, les noms des
|
||||
serveurs ne peuvent plus être pris. Il y a une cinquaintaine de
|
||||
personnes qui devraient avoir un compte sur zamok et n'en ont pas. Les
|
||||
autres problèmes actuels ont été passés en revue et les nouveaux
|
||||
scripts évitent tous ces cas. Le problème des conflits d'alias ont
|
||||
également été évoqués mais leur résolution n'a pas encore été trouvée.
|
||||
|
||||
Le filtrage par adresse des MAC sera mis en place. Que faire pour que
|
||||
les cableurs puissent venir tester rapidement ? On peut rediriger sur
|
||||
une page qui permet à l'utilisateur inconnu de s'identifier avec son
|
||||
compte zamok. Les cableurs pourront également ajouter des adresses
|
||||
temporairement (la leur).
|
||||
|
||||
### Moteur de recherche sur les news
|
||||
|
||||
Manathan a conçu un moteur de recherche sur les news qui est quasiment
|
||||
terminé. Il sera intégré sur zamok au site. Il ne sait pour le moment
|
||||
pas afficher les pièces jointes.
|
||||
|
||||
### Recherche des mots de passe faible
|
||||
|
||||
Le script est en place, mais il ne tourne pas en permanence.
|
||||
|
||||
(HS : WEI : la roue de la déconnexion (sur une idée de Schultzy))
|
||||
|
||||
L'idée d'un scan régulier (toutes les semaines ?) est gardée. La seule
|
||||
action est d'envoyer un mail.
|
||||
|
||||
### Browse master samba + DHCP
|
||||
|
||||
Le premier script utilise smbclient pour prévenir les adhérents et
|
||||
peut envoyer des mails. Le DHCP envoie des mails aux nounous (à Manu
|
||||
et Manathan). Ces scripts devraient être déplacées sur d'autres
|
||||
machines que celles de tests.
|
||||
|
||||
### Sécurisation Apache
|
||||
|
||||
Les scripts PHP des adhérents sont actuellement exécutés par un
|
||||
utilisateur dédié.
|
||||
|
||||
### Sécurisation PHP
|
||||
|
||||
Peut-on utiliser le safe mode sur zamok ?
|
||||
|
||||
### Chaines MAC-IP
|
||||
|
||||
Le lancement du firewall prend énormément de temps. Manu va ajouter le
|
||||
code nécessaire pour ajouter ou enlever une correspondance ce qui
|
||||
éviterait la construction entière de la chaîne de correspondance.
|
||||
|
||||
### Modération automatique des posts dans followup-to
|
||||
|
||||
À faire.
|
||||
|
||||
### Amavis
|
||||
|
||||
Une liste blanche devrait être mise en place. Mais en attendant,
|
||||
l'antivirus est gardé. Les râleurs peuvent toujours l'améliorer (mais
|
||||
le laisser fonctionnel).
|
||||
|
||||
### Ménage des comptes inutilisés
|
||||
|
||||
Sandor fera ça rapidement et documentera la procédure.
|
||||
|
||||
### Install Party
|
||||
|
||||
Une réunion sera organisée demain soir au 2B avec notamment la
|
||||
procédure d'installation.
|
||||
|
||||
La réunion s'est achevée à 21h30.
|
||||
|
|
@ -0,0 +1,138 @@
|
|||
# Réunion IN
|
||||
|
||||
Ce jeudi 6 mai 2004 s'est déroulée une réunion internounou au Krobot à 21h30.
|
||||
|
||||
## Présents
|
||||
|
||||
* Benoit Rozel
|
||||
* Fabien Millioz (Mit Mit)
|
||||
* Sébastien Li-Tao-The (Sayan)
|
||||
* Julien Ducarne (juliend)
|
||||
* Arnaud Sternchüss (Schultzy)
|
||||
* Yohan Le Diraison (Ryo)
|
||||
* Manuel Sabban (M@nu)
|
||||
* Mathieu Ségaud (Regala)
|
||||
* Frédéric Pauget (Fred)
|
||||
* Yves-Laurent Allaert (Manathan)
|
||||
* Vincent Bernat (`Vince||`)
|
||||
* Philippe Gambette (Freecorp)
|
||||
* Christophe Calvès (Grand Tof)
|
||||
* Olivier Deleage (O-live)
|
||||
* Clément Houtmann (ClemHout)
|
||||
* Charles Signorini
|
||||
|
||||
### Synchronisation
|
||||
|
||||
Un nouveau serveur de sauvegarde a été acheté il y a deux semaines. Il dispose
|
||||
de 1 To de disque dont environ 695 Go en RAID 5 pour les sauvegardes. Une
|
||||
sauvegarde journalière est effectuée de :
|
||||
|
||||
* {{{/etc}}}, {{{/boot}}}, le CVS, les paquets installés ce qui fait
|
||||
environ 3,6 Mo par jour
|
||||
* Le {{{/home}}}, les mails, les news, le wiki, jabber, les ML, le site
|
||||
web ; ce qui fait environ 30 Go par jour
|
||||
|
||||
On conserve les 3 derniers dimanche ainsi que la semaine en cours. La mise à
|
||||
jour se fait par rsync. Une fois par jour, la dernière sauvegarde est
|
||||
sauvegardée au cas pour éviter de perdre toute une semaine en cas de perte des
|
||||
données sur les serveurs d'origine.
|
||||
|
||||
### Situation de Debian
|
||||
|
||||
Les serveurs du CRANS sont passés en Debian/Testing qui devait devenir la
|
||||
prochaine stable assez rapidement. Cela a permis de mettre des 2.6 sur les
|
||||
serveurs. Debian ne suit pas la GPL mais dispose de son propre manifeste : la
|
||||
DFSG. Ce manifeste a été précisé récemment par un vote et le kernel, entre
|
||||
autres, est désormais considéré comme non libre. La Sarge pourrait donc être
|
||||
retardée d'un an par un tel changement. L'avenir de Debian est du coup assez
|
||||
mouvementé avec des développeurs qui partent.
|
||||
|
||||
Parmi les alternatives possibles, Open BSD pourrait être une solution. Il est
|
||||
toutefois beaucoup trop tôt pour s'avancer sur ce point.
|
||||
|
||||
### LDAP
|
||||
|
||||
LDAP est une sorte de base de données permettant de regrouper les informations
|
||||
sur les utilisateurs donc les adhérents avec de grandes facilités
|
||||
d'interrogation. Il fonctionne en architecture client/serveur, ce qui évitera
|
||||
d'avoir à transférer les différents fichiers par scp : chaque machine peut
|
||||
interroger elle-même la base. Par la suite, il serait aussi possible
|
||||
d'effectuer les authentifications par LDAP.
|
||||
|
||||
Migration :
|
||||
|
||||
* réécriture des scripts de câblage pour supporter LDAP (ce qui fera du bien de
|
||||
repartir sur une base plus récente)
|
||||
* réécriture des scripts de génération des fichiers de configuration (DNS,
|
||||
DHCP, etc)
|
||||
|
||||
La réécriture permettra aussi de documenter proprement ce qui est fait. Le fait
|
||||
que les informations soient centralisées facilitera grandement la recherche
|
||||
d'information : à un adhérent sera attaché toutes les informations qui le
|
||||
concerne dont l'upload, les virus, etc.
|
||||
|
||||
M@nu se propose pour l'interface GTK.
|
||||
|
||||
### Documentation
|
||||
|
||||
Chaque nounou qui fait quelque chose sur les serveurs doivent faire une
|
||||
documentation de préférence sur le wiki. Une autre tâche serait de documenter
|
||||
aussi l'existant quand on en a l'occasion. Une partie de la documentation sur
|
||||
zamok peut également migrer sur le wiki.
|
||||
|
||||
### Salle de réunion
|
||||
|
||||
Une salle a été demandée pour mettre Pegase mais celui-ci va atterrir au H
|
||||
quand les nouveaux switchs seront arrivés. Cette salle pourra donc servir de
|
||||
salle de réunion.
|
||||
|
||||
### Budget
|
||||
|
||||
Pour éviter d'avoir à demander au CA pour des achats mineurs (feutres, têtes de
|
||||
câble, tableau blanc, processeur), les nounous désirent avoir un budget fixe et
|
||||
un chéquier pour eux. Le CA se renseigne sur les solutions possibles. Ce point
|
||||
sera porté à l'OdJ de la réunion CA de lundi.
|
||||
|
||||
'''Moi j'ai du mal à présenter à moi-même les factures...''' -- ClemHout
|
||||
|
||||
### Videolan
|
||||
|
||||
Schultzy va prendre contact avec les types de Videolan. Il y a deux solutions :
|
||||
|
||||
* recevoir le flux de Centrale
|
||||
* encoder nous mêmes
|
||||
|
||||
Les nouveaux switchs facilitent la diffusion sur le campus, notamment grâce au
|
||||
multicast.
|
||||
|
||||
M@nu prendra également contact pour proposer d'héberger un miroir Videolan.
|
||||
|
||||
### Sécurisation PHP
|
||||
|
||||
Quelles sont les fonctionnalités voulues ?
|
||||
|
||||
* exécuter des scripts ne nous appartenant pas
|
||||
* avoir le droit d'exécuter des commandes arbitraires
|
||||
* autoriser l'ouverture d'URL
|
||||
* modification des fichiers par PHP ?
|
||||
|
||||
Sayan nous sortira les solutions disponibles.
|
||||
|
||||
### Synchronisation CA
|
||||
|
||||
Que doivent faire les nounous quand il y a un grand désaccord avec le CA, comme
|
||||
par exemple une divergence importante de point de vue sur le sort d'un
|
||||
adhérent ? Les demandes doivent être données clairement au CA de façon à ce
|
||||
qu'il n'y ait pas d'ambiguïté.
|
||||
|
||||
### Divers
|
||||
|
||||
* La blacklist sera accessible au câbleur sur le nouveau système
|
||||
* Un adhérent veut faire un forum sur zamok et demande l'autorisation et
|
||||
accepte la surveillance ; toutefois, les nounous n'ont pas le temps
|
||||
nécessaire pour ça et donc le forum est interdit.
|
||||
* Le miroir Gentoo est supprimé et personne ne s'est plaint
|
||||
* Le sondage sur le positionnement des bornes wifi avance tout doucement : le
|
||||
d'Alembert, la bibli et la Med sont bien placés.
|
||||
|
||||
La réunion a été levée à 23h40.
|
||||
|
|
@ -0,0 +1,82 @@
|
|||
# Réunion IN
|
||||
|
||||
Lundi 28 Février 2006 a eu lieu une réunion Internounou à la salle Condorcet
|
||||
à 19h30.
|
||||
|
||||
## Présents
|
||||
|
||||
* Brice Dubost
|
||||
* Charles Signorini
|
||||
* Cyril Cohen
|
||||
* Étienne Chové
|
||||
* François Bobot
|
||||
* Frédéric Pauget
|
||||
* Grégoire Détrez
|
||||
* Matthieu Segaud
|
||||
* Nicolas Salles
|
||||
* Romain Clément
|
||||
* Stéphane Glondu
|
||||
* Vincent Bernat
|
||||
* Xavier Pessoles
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
* Mise à jour de la CransNostalgie/TodoList
|
||||
* Élection d'un nouveau RTC
|
||||
|
||||
## Déconnexions pour upload et p2p
|
||||
|
||||
* Mise à jour des sanctions dans la base LDAP
|
||||
|
||||
| | Squid| Komaz | Radius et Ragnarok|
|
||||
|--------------------|------|-------|-------------------|
|
||||
| Upload Manuel | (./) | (./) | |
|
||||
| Upload automatique | (./) | (./) | |
|
||||
| Virus Manuel | | | (./) |
|
||||
| Virus automatique | (./) | | |
|
||||
| P2P Manuel | (./) | (./) | |
|
||||
| P2P Automatique | (./) | (./) | |
|
||||
| Mail invalide | (./) | | |
|
||||
| Warez | (./) | | |
|
||||
|
||||
## Installation de cfengine
|
||||
|
||||
Cfengine n'est pas capable de générer n'importe quels fichiers, en particulier
|
||||
pour Monit.
|
||||
Pour l'instant, Bilou continue à générer les fichiers de Monit.
|
||||
Rédaction de la liste des services à gérer par cfengine.
|
||||
|
||||
## Imprimante réseau
|
||||
|
||||
Problème de l'impression en Portrait / Paysage.
|
||||
Problème technologique : Bac de finition de l'imprimante.
|
||||
Question soumise au CA : Choix/Achat un bac de finition HP ?
|
||||
|
||||
## WiFi
|
||||
|
||||
Rien de neuf.
|
||||
Abandon du L2TP temporaire.
|
||||
Question au CA : Aller voir le CROUS pour déployer...
|
||||
|
||||
## Ménage du cimetière
|
||||
|
||||
Script sur vert : /etc/cron.daily/nettoie_cimetiere
|
||||
|
||||
## Suppression de WebDav
|
||||
|
||||
Solution trop compliquée à mettre en oeuvre pour le moment.
|
||||
|
||||
## Élection d'un nouveau RTC
|
||||
|
||||
Candidats :
|
||||
|
||||
* Stéphane
|
||||
* Bilou
|
||||
|
||||
Électeurs : 9
|
||||
|
||||
* Bilou : 5
|
||||
* Stéphane : 3
|
||||
* Nul : 1
|
||||
|
||||
Bilou est élu RTC.
|
||||
|
|
@ -0,0 +1,162 @@
|
|||
# Réunion IN
|
||||
|
||||
Réunion technique inter nounous.
|
||||
|
||||
## Réunion
|
||||
|
||||
### Horaires
|
||||
|
||||
* Date : Jeudi 1^er^ mars 2007
|
||||
* Début : 19h12
|
||||
* Fin : 20h36
|
||||
* Lieu : salle de conférence du Pavillon des Jardins
|
||||
|
||||
### Présents
|
||||
|
||||
* Alexandre Bos
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Brice Dubost
|
||||
* Frédéric Pauget
|
||||
* Grégoire Détrez
|
||||
* Jérémie Dimino
|
||||
* Stéphane Glondu
|
||||
* Vincent Bernat
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Mails invalides
|
||||
|
||||
Alexandre propose une gestion automatisée des mails invalides : quand il y aura
|
||||
un doute sur la validité d'une adresse mail, ou lors d'un changement d'adresse
|
||||
mail, un mail de confirmation (à la mailman) sera envoyé avec un lien. Si
|
||||
l'adresse n'est pas confirmée au bout d'une semaine, l'adhérent serait
|
||||
déconnecté avec une page explicative sur squid. Accepté à l'unanimité.
|
||||
|
||||
### Serveur de secours extérieur
|
||||
|
||||
Louer une baie pour y mettre notre propre serveur coûte cher et n'est pas
|
||||
forcément pratique. En revanche, louer un serveur ne coûte pas si
|
||||
cher (environ 50 € HT par mois) et OVH, par exemple, proposent des services
|
||||
intéressants (avec de bons échos). On louera donc un serveur dédié chez OVH.
|
||||
Accepté à l'unanimité.
|
||||
|
||||
### Compte d'impression pour tout le monde
|
||||
|
||||
Les adhérents ne sont pas encore tous au courant de l'existence du service
|
||||
d'impression, et il a été proposé de créer un compte d'office à tous les
|
||||
adhérents pour populariser ce service. Cela risque de charger un peu plus les
|
||||
câbleurs, les procédures de mot de passe peuvent être pénibles... Une idée de
|
||||
mot de passe généré ou de one-time password a été évoquée, mais
|
||||
abandonnée : l'adhérent lambda qui se verra imposé un mot de passe pour quelque
|
||||
chose dont il ne verra pas l'utilité dès son inscription oubliera très
|
||||
certainement son mot de passe (comme c'est souvent le cas actuellement) et
|
||||
devra de toute façon repasser à la Kfet. En fait, le service d'impression a été
|
||||
mis en production la rentrée dernière et n'était pas tout à fait opérationnel à
|
||||
l'automne 2006, mais on peut le considérer maintenant comme totalement
|
||||
opérationnel, et une campagne de pub plus poussée sera faite à la prochaine
|
||||
rentrée (lors du contact de masse avec les adhérents) afin que le service
|
||||
d'impression soit un peu plus connu.
|
||||
|
||||
Vote : 1 voix pour, 4 contre, 4 sans avis.
|
||||
|
||||
Pour les clubs : on donne la possibilité aux clubs d'imprimer avec leur
|
||||
compte (mais ce compte n'est créé qu'à la demande). Cela demande encore un peu
|
||||
de travail sur l'intranet.
|
||||
|
||||
### Solde impression / Note Kfet
|
||||
|
||||
La création d'une « note Crans » pour créditer les soldes d'impression est
|
||||
abandonnée vu les difficultés à récupérer des sous du BdE de manière générale.
|
||||
De plus, la rigueur de la gestion des notes Kfet ne correspond pas avec la
|
||||
politique générale du Crans en matière de sécurité.
|
||||
|
||||
En revanche, il a été envisagé de « vendre » du crédit au BdE afin qu'il le
|
||||
revende aux adhérents du Crans (du moment que le BdE « prépaye » le Crans). On
|
||||
pourrait donner une compensation (à négocier) en retour. C'est à discuter avec
|
||||
le BdE.
|
||||
|
||||
Si le BdE n'est pas d'accord, on en arrête là.
|
||||
|
||||
### Maintien d'Alexandre Bos au poste de nounou
|
||||
|
||||
Il s'agissait d'officialiser la nomination d'Alexandre Bos (qui s'est mis
|
||||
lui-même les droits nounou) au poste de nounou. Accepté à l'unanimité.
|
||||
|
||||
### Nouveaux serveurs
|
||||
|
||||
Stéphane a appelé Anne Cazalet ce matin ; un devis devrait être reçu avant la
|
||||
fin de semaine. Anne pourrait venir à la prochaine réunion CA.
|
||||
|
||||
## Impromptu
|
||||
|
||||
### Expiration de la garantie de Pegase
|
||||
|
||||
La garantie de Pegase vient d'expirer, Dell nous propose une extension
|
||||
à 700 € pour 2 ans de plus. De plus, Dell propose des offres de
|
||||
renouvellement (jusqu'à 75 % de réduction par rapport au site web). Attention
|
||||
aux problèmes rencontrés dans le passé avec Dell : adresses, paiement à
|
||||
l'avance, délais, etc. On n'étend pas la garantie, mais on jette un coup d'œil
|
||||
aux offres de renouvellement.
|
||||
|
||||
Notre nouveau contact chez Dell : Céline El Bouhali (04 99 75 65 84).
|
||||
|
||||
### SVN vs CVS
|
||||
|
||||
SVN a déjà été testé dans le passé pour le Crans et posait plus de problèmes
|
||||
que CVS (repository fragile, problème de droits, etc.). Pour les fichiers de
|
||||
configuration, CVS convient bien et sera conservé. Pour les scripts (en
|
||||
particulier les projets orthogonaux tels que l'intranet ou le wifi), un système
|
||||
de versionnement distribué pourra être adopté. Il faudra faire une étude de ces
|
||||
systèmes (Git/coGITo, Mercurial, etc.). Remarque : TLA est déjà utilisé pour le
|
||||
wifi. Brice et Grégoire regardent Git.
|
||||
|
||||
### Virtual Hosts pour pages perso
|
||||
|
||||
Il s'agit de rendre accessible les pages perso accessibles via des adresses qui
|
||||
commencent par autre chose que <http://perso.crans.org> (par exemple
|
||||
<http://www.example.com>). La gestion des virtual hosts en crans.org risque de
|
||||
polluer notre domaine et demande des précautions avec la gestion des conflits
|
||||
dans le DNS, tout cela pour un intérêt très faible. En revanche, les virtual
|
||||
hosts hors crans.org demandent un effort minime côté crans, et la configuration
|
||||
est déjà en place. On autorise donc les virtual hosts pour les noms de domaine
|
||||
hors crans.org, au cas par cas.
|
||||
|
||||
## CROUS
|
||||
|
||||
### Travaux sur les fibres
|
||||
|
||||
Aux dernières nouvelles, SCIC Habitat prend en charge la réparation en faisant
|
||||
appel à SPIE Communications. Les travaux commenceront lundi.
|
||||
|
||||
### Clés
|
||||
|
||||
Le CROUS a un exemplaire de toutes nos clés. En cas de réclamation de la part
|
||||
du CROUS, il faudra leur expliquer qu'on ne peut pas se permettre de distribuer
|
||||
des clés dès qu'ils perdent la leur et que d'ailleurs, le fait qu'ils perdent
|
||||
nos clés est inquiétant car l'assurance ne couvrent pas les clés perdues. En
|
||||
revanche, on leur laisse accéder à nos locaux quand ils veulent (dès qu'ils
|
||||
préviennent suffisamment à l'avance). Le cas de force majeure est une fausse
|
||||
excuse car de toute façon, les pompiers accèdent n'importe où sans même se
|
||||
soucier d'avoir les clés (cas de porte défoncée au C déjà rencontré).
|
||||
|
||||
### Locaux techniques 4I, 4H
|
||||
|
||||
Le CROUS va installer des serrures sur des armoires techniques au 4I et 4H afin
|
||||
que nous puissions y installer des switchs pour les bornes sur les toits.
|
||||
|
||||
### Problèmes électriques au bâtiment I
|
||||
|
||||
Le local de brassage est sur le même circuit électrique que les prises du
|
||||
couloir et des autres locaux techniques. Il faudra demander au CROUS un circuit
|
||||
électrique séparé (s'adresser à Victor) comme ils l'ont fait pour le M et le B.
|
||||
|
||||
## Brainstorming
|
||||
|
||||
* Refaire les scripts de gestion avec une base postgres : ça va pas forcément
|
||||
résoudre les problèmes, mais ça peut améliorier les performances et ça
|
||||
peut-être plus marrant plutôt que de déboguer des trucs... la vue ldap est
|
||||
lente... on attend, il y a autre chose à faire, mais en attendant, on peut
|
||||
profiler du python pour localiser les goulots d'étranglement
|
||||
* Avec les nouveaux serveurs, redondance de services (Heartbeat) (plus utile)
|
||||
* Interaction avec FedeRez ?
|
||||
|
|
@ -0,0 +1,42 @@
|
|||
# Réunion IN
|
||||
|
||||
Réunion inter-nounou du jeudi 15 Mars 2007. La réunion aura lieu vers 19 heures
|
||||
au PdJ.
|
||||
|
||||
Début : -- WikiSgnb <<DateTime(2007-03-15T18:17:04Z)>>
|
||||
Fin : -- WikiSgnb <<DateTime(2007-03-15T20:16:13Z)>>
|
||||
|
||||
Présents :
|
||||
|
||||
* Alexandre Bos
|
||||
* Augustin Parret-Fréaud
|
||||
* Étienne Chové
|
||||
* Jérémie Dimino
|
||||
* Romain Clément
|
||||
* Stéphane Glondu
|
||||
|
||||
Ordre du jour :
|
||||
|
||||
* Répartition des services sur les nouveaux serveurs : pas de nouveau truc,
|
||||
voir CransNostalgie/ChangementServeurs
|
||||
* Sauvegardes physiques (sur disque dur externe ou sur DVD) : l'idée est de
|
||||
sauvegarder sur un support non accessible logiciellement en cas de
|
||||
compromission de nos serveurs. Alexandre s'en charge.
|
||||
* Formulaire de pré-inscription en ligne, et éventuellement paiement en ligne
|
||||
via intranet.
|
||||
|
||||
Bilans (ou pas) :
|
||||
|
||||
* Mails invalides : en cours
|
||||
* Serveur de secours extérieur : serveur commandé
|
||||
* Note Kfet : essai d'une facturation a posteriori du BdE : on donne au BdE la
|
||||
possibilité de créditer les comptes impression, et on les facture tous les X
|
||||
jours (avec éventuellement une compensation)... en cas de problèmes
|
||||
particuliers, on annule le système... il faut l'accord du BdE
|
||||
* Compte impression pour les clubs
|
||||
* Git : on risque de se retrouver dans la même situation que le développement
|
||||
du wifi : seul Vincent savait se servir de tla, et l'utilisation d'un autre
|
||||
système de versionnement a rebuté les autres. Ou alors, on pourrait tout
|
||||
passer sous git, ainsi, ça forcera tout le monde a passer à git. On attend
|
||||
plus d'informations sur git (un séminaire technique, un tutoriel sur le wiki).
|
||||
* Travaux sur les fibres (./)
|
||||
|
|
@ -0,0 +1,129 @@
|
|||
# Réunion inter-nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 29 mars 2007
|
||||
* Début : -- WikiSgnb <<DateTime(2007-03-29T17:22:41Z)>>
|
||||
* Fin : -- WikiSgnb <<DateTime(2007-03-29T19:16:32Z)>>
|
||||
* Lieu : salle Condorcet
|
||||
|
||||
## Présents
|
||||
|
||||
* Alexandre Bos
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Jérémie Dimino
|
||||
* Stéphane Glondu
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Pénurie d'adresses IP wifi
|
||||
|
||||
Problème:: On va bientôt arriver à cours d'adresses IP pour les machines wifi
|
||||
des adhérents (il en reste 45).
|
||||
|
||||
Solutions possibles::
|
||||
|
||||
* On a trois /24 inutilisés (138.231.{145,146,147}); on pourrait déplacer le
|
||||
vlan adm (qui n'est de toute façon pas accessible directement depuis
|
||||
l'extérieur) dans une plage privée, et élargir le réseau wifi
|
||||
à 138.231.144.0/21 -> beaucoup de reconfiguration (switchs, serveurs).
|
||||
* On peut aussi laisser le vlan adm dans son /24, étendre le réseau wifi
|
||||
à 138.231.144.0/21, tout en continuant de réserver les 256 premières
|
||||
adresses pour le vlan adm -> solution la plus simple à mettre en œuvre et
|
||||
la plus raisonnable
|
||||
* Le réseau wifi est entièrement routé. Vous pouvez
|
||||
prendre 138.231.147.0/24 et ainsi de suite
|
||||
* Déplacer les bornes dans un des sous-réseaux inutilisés (les bornes ont-elles
|
||||
vraiment besoin d'être dans le même sous-réseau que les machines wifi ?)
|
||||
* Attribuer des IPs dynamiques -> il faudra maintenir des logs des
|
||||
correspondances MAC-IP, pour que, par exemple, les logs de squid soient utiles
|
||||
* Mettre les machines wifi dans un sous-réseau privé derrière un NAT
|
||||
* Restreindre le nombre de machines wifi pour les membres non actifs, mais de
|
||||
toute façon, il n'y a pas assez d'adresses IP (762) pour chaque adhérent (964)
|
||||
|
||||
### Mails de confirmation
|
||||
|
||||
Mise en œuvre::
|
||||
|
||||
* les liens qui ont été cliqués ont été logués par apache, ces logs seront
|
||||
utilisés pour mettre à jour la base LDAP pour ceux pour qui la page de
|
||||
confirmation n'aurait pas fonctionné
|
||||
* création d'un service (au sens de generate.py) pour mettre à jour la
|
||||
base -> élimine (façon de parler) les problèmes de locks
|
||||
* clarification : le spammage de la nuit dernière est le seul, il avait pour
|
||||
but d'initialiser le processus; à l'avenir, les mails ne seront envoyés que
|
||||
suite à un doute quant à la validité d'une adresse mail
|
||||
* pour les détenteurs de comptes crans : on pourrait exploiter le script de
|
||||
détection de comptes inactifs et envoyer le lien de confirmation directement
|
||||
dans le mail de détection d'inactivité -> utiliser mailconf pour confirmer
|
||||
aussi l'utilisation d'un compte crans
|
||||
|
||||
Choses à améliorer::
|
||||
|
||||
* encoder l'adresse mail dans l'adresse de retour
|
||||
* changer l'expéditeur (moi, j'ai rien contre
|
||||
disconnect -- -- WikiSgnb <<DateTime(2007-03-29T19:16:32Z)>>)
|
||||
* mettre un message plus explicatif
|
||||
|
||||
### Logs
|
||||
|
||||
État des lieux:: Parfois, quelqu'un de non-nounou a besoin de pouvoir accéder à
|
||||
certains logs. Par exemple, le bureau, pour voir l'utilisation des fichiers
|
||||
copyrightés, ou un apprenti, pour voir ou tester un script...
|
||||
|
||||
Discussion:: on abandonne le groupe logs et on gère les accès par ACL au cas
|
||||
par cas. Par contre, il faudrait trouver un moyen de centraliser et suivre
|
||||
l'attribution des ACLs, sinon on risque de se retrouver avec un tas de fichiers
|
||||
avec des ACLs « fantômes ». Solutions proposées :
|
||||
|
||||
* un script et/ou fichier de conf commité dans le CVS qui fixe les ACLs (voir
|
||||
si un tel système n'existe pas déjà)
|
||||
* effacer toutes les ACLs régulièrement
|
||||
|
||||
### Passage du Père Noël
|
||||
|
||||
On a reçu ce matin ce qui a été commandé le 13 mars, sauf 5 kits POE. Tout le
|
||||
contenu n'a pas encore été vérifié (en cours).
|
||||
|
||||
Impressions à chaud :
|
||||
|
||||
* Armoire : très classe
|
||||
* Disques durs : mignons tout plein
|
||||
* KVM IP : le client est une applet ActiveX. Quelqu'un a-t-il une solution ?
|
||||
* Il ne cause pas VNC ou rdesktop ? pas documenté en tout
|
||||
cas -- WikiSgnb <<DateTime(2007-03-29T22:07:54Z)>>
|
||||
* Baptême : le nouveau serveur 8 cœurs a été appelé « fx », approuvé à
|
||||
l'unanimité des personnes qui étaient d'accord.
|
||||
|
||||
Impressions diverses sur fx :
|
||||
|
||||
* le live-CD d'Ubuntu ne détecte que 3,2 Go de RAM (le BIOS en détecte
|
||||
bien 4 Go)
|
||||
* Normal, faut un noyau highmem avec support > 4 Go (sinon, le Go restant
|
||||
est pour le noyau)
|
||||
* le centre de contrôle de gnome n'affiche que 6 processeurs (bugreport à
|
||||
envoyer)
|
||||
* interface iLO 2 qui obsolète le KVM IP (applet Java cette fois-ci)
|
||||
* si c'est de l'IPMI, il y a les outils pour dans Debian
|
||||
|
||||
### OVH
|
||||
|
||||
Installé :
|
||||
|
||||
* VPN/CVS/cfengine
|
||||
|
||||
À faire :
|
||||
|
||||
* Correction de la base LDAP (quel est le problème ?)
|
||||
* Migration du common_etc vers cfengine en cours
|
||||
* Postfix
|
||||
* DNS
|
||||
* Backup sur Pegase
|
||||
* Munin/Monit
|
||||
* Fallback du VPN sur la connexion de secours
|
||||
|
||||
### Reporté à plus tard
|
||||
|
||||
* Todolist
|
||||
* Cableurs
|
||||
|
|
@ -0,0 +1,66 @@
|
|||
# Réunion Inter-nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 3 mai 2007
|
||||
* Début : 19:10
|
||||
* Fin : 19:49
|
||||
* Lieu : Pavillon des Jardins
|
||||
|
||||
## Présents
|
||||
|
||||
* Alexandre Bos
|
||||
* Augustin Parret-Fréaud
|
||||
* Cyril Cohen
|
||||
* Jérémie Dimino
|
||||
* Stéphane Glondu
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Alexandre
|
||||
|
||||
Mails de confirmation:: Pour éviter les problèmes de locks, on va utiliser des
|
||||
services (au sens generate.py) pour mettre à jour le champ dans la base.
|
||||
Alexandre attend plus d'informations au sujet des services.
|
||||
|
||||
CransAdministratif/PreInscription:: Script en PHP5/MySQL en cours de
|
||||
réalisation par Alexandre.
|
||||
|
||||
### CransNounous/TodoList
|
||||
|
||||
Backuppc sur ovh:: Augustin passe la sauvegarde sur cfengine avant de mettre en
|
||||
place la sauvegarde d'ovh.
|
||||
|
||||
Cfengine:: Augustin propose de regrouper toutes les classes dans un fichier
|
||||
cf.class. Cela simplifierait par exemple l'installation de services sur un
|
||||
nouveau serveur, etc. Adopté.
|
||||
|
||||
Problème de CransWifi sous Linux:: les clients sous Linux ne peuvent pas
|
||||
installer les dépendances nécessaires pour CransWifi à partir du portail
|
||||
captif. Solutions envisagées:
|
||||
|
||||
1. donner accès au ftp de sila
|
||||
1. mirrorer les fichiers dont dépend CransWifi sur ragnarok -> quels
|
||||
|
||||
paquets ? racoon et ipsec-tools
|
||||
Idéalement, il faudrait le faire pour toutes les distributions. Mais on ne
|
||||
s'occupera que de Debian et Ubuntu. On opte pour la seconde solution -> Cyril
|
||||
s'en charge (?)
|
||||
|
||||
Prétraitement arpwatch:: Stéphane a expliqué ses idées.
|
||||
|
||||
DVD admissibles:: On attend les vidéos de NumENS, et les documents de l'ENS.
|
||||
|
||||
### Bonus
|
||||
|
||||
Changement du système de versionnement:: Stéphane a présenté darcs. Cyril et
|
||||
Augustin ont l'air d'aimer. On laisse mûrir.
|
||||
|
||||
## Annonces
|
||||
|
||||
* Réunions :
|
||||
* Prochaine réunion inter-nounou : ../Jeudi31Mai2007
|
||||
* Prochaine réunion CA : ../Jeudi10Mai2007
|
||||
* Précédente réunion inter-nounou : ../Jeudi29Mars2007
|
||||
* Précédente réunion CA : ../Jeudi26Avril2007
|
||||
* Liste des CR : ComptesRendusCrans
|
||||
|
|
@ -0,0 +1,60 @@
|
|||
# Réunion inter-nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 31 juin 2007
|
||||
* Début : 19h30
|
||||
* Fin : 20h00
|
||||
* Lieu : PDJ
|
||||
|
||||
## Présents
|
||||
|
||||
* Alexandre Bos
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Jérémie Dimino
|
||||
* Stéphane Glondu
|
||||
|
||||
## Brouillon d'ordre du jour
|
||||
|
||||
### Etchisation : état des lieux
|
||||
|
||||
Rouge:: reste amavis à réparer... en attente...
|
||||
|
||||
Zamok:: pourquoi monit considère-t-il toujours qu'apache2 ne tourne pas ?
|
||||
|
||||
Pegase:: à faire (demain soir).
|
||||
|
||||
Proxy:: pourquoi faire passer les adresses en free.fr par ultra ne semble plus
|
||||
fonctionner ?
|
||||
|
||||
Autres remarques::
|
||||
|
||||
* l'occupation des /var de rouge et zamok a augmenté significativement
|
||||
* nscd a tendance à planter sur zamok -> cela explique les problèmes que les
|
||||
utilisateurs non privilégiés rencontrent ; cela pose aussi des problèmes de
|
||||
distribution de mails
|
||||
* pour plus du sûreté : faire en sorte qu'un dysfonctionnement de nscd ne
|
||||
pénalise pas (presque) tout le monde
|
||||
|
||||
### Pénurie d'adresses wifi
|
||||
|
||||
* À faire, pas dans les priorités.
|
||||
|
||||
### Porter CransWifi sous Windows Vista
|
||||
|
||||
* Il nous faut un Windows Vista...
|
||||
|
||||
### Mettre en place une inscription en ligne
|
||||
|
||||
* Problablement pas pour la prochaine rentrée.
|
||||
|
||||
### Permettre la connexion à la zone ENS uniquement aux normaliens
|
||||
|
||||
* Il faudrait demander à la DSI quels sites filtrer.
|
||||
|
||||
### Impression sur les comptes clubs
|
||||
|
||||
* En cours : chaque club a une liste de responsables impression qui peuvent
|
||||
imprimer sur son compte depuis l'intranet avec leur login. Pour l'instant, le
|
||||
système est opérationnel avec un seul responsable par club.
|
||||
|
|
@ -0,0 +1,62 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 25 octobre 2007
|
||||
* Début : -- WikiSgnb <<DateTime(2007-10-25T19:12:42Z)>>
|
||||
* Fin : -- WikiSgnb <<DateTime(2007-10-25T21:24:38Z)>>
|
||||
* Lieu : Au 2B
|
||||
|
||||
## Présents
|
||||
|
||||
* Alexandre Bos (via Skype) (Skype ça pue -- WikiDim)
|
||||
* Jérémie Dimino
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Pierre Chambart
|
||||
* Stéphane Glondu
|
||||
* Valérian Reithinger
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Déploiement de bcfg2
|
||||
|
||||
Déploiement initial toujours en cours par Jérémie.
|
||||
|
||||
### Point sur l'installation de fx
|
||||
|
||||
Pour pouvoir faire mumuse avec Xen sur fx, un compte avec tous les droits sudo
|
||||
a été créé pour Nicolas. Même si cela lui donne virtuellement les mêmes droits
|
||||
qu'une nounou, il n'en est pas une.
|
||||
|
||||
À court terme, il faudrait migrer ultra vers le domU secours, renommé titanic
|
||||
afin de se débarasser d'ultra. À installer et configurer:
|
||||
|
||||
* ldap
|
||||
* openvpn
|
||||
* squid
|
||||
|
||||
Alexandre s'en charge en prenant modèle sur ultra. On fait en sorte de
|
||||
minimiser l'utilisation du NFS sur titanic, donc on ne monte que les homes et
|
||||
le /var/lib/cvs, et on utilise un checkout pour /usr/scripts.
|
||||
|
||||
### Réorganisation de sila
|
||||
|
||||
On laisse les 100 derniers jours de logs sur sila, et on met les autres sur
|
||||
vert (fait -- WikiSgnb <<DateTime(2007-10-26T04:07:01Z)>>). Pas besoin de
|
||||
bidouiller avec les partitions, qui pose toutes sortes de problèmes pratiques.
|
||||
|
||||
### Fusion/évolution des quotas
|
||||
|
||||
Le quota passe à 600 Mo soft, 700 Mo hard. À part quelques nounous, ce quota
|
||||
n'est atteint par personne actuellement. Solution adoptée : les inbox sont
|
||||
dans /home/mail/login, et /var/mail est un lien symbolique vers /home/mail.
|
||||
|
||||
Fait. -- WikiSgnb <<DateTime(2007-10-26T04:07:01Z)>>
|
||||
|
||||
### Système de génération des fiches de déconnexion
|
||||
|
||||
Il faudrait un système comparable à mail_invalide, à savoir la génération de la
|
||||
page se fait lors de l'exécution d'un script. Intérêt: les dates dans la fiche
|
||||
correspondraient aux dates effectives de la déconnexion, et peuvent être donc
|
||||
adaptées si la distribution se fait en retard.
|
||||
|
|
@ -0,0 +1,70 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 8 novembre 2007
|
||||
* Début : -- WikiSgnb <<DateTime(2007-11-08T19:55:50Z)>>
|
||||
* Fin :
|
||||
* Lieu : au PdJ
|
||||
|
||||
## Présents
|
||||
|
||||
* Augustin Parret-Fréaud
|
||||
* Brice Dubost
|
||||
* Charles Vallantin-Dulac
|
||||
* François Bobot
|
||||
* Jean-Benoist Léger
|
||||
* Jérémie Dimino
|
||||
* Nicolas Dandrimont
|
||||
* Stéphane Glondu
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Déploiement de bcfg2
|
||||
|
||||
Jérémie fait des tests sur des domU de fx. Pour l'instant, on en est au minimum
|
||||
commun à tous les serveurs.
|
||||
|
||||
### Point sur l'installation de titanic
|
||||
|
||||
Alexandre n'est pas là. En attendant, il faudrait rebrancher ultra-adsl...
|
||||
|
||||
* Désolé, je révise (enfin je devrais) mon partiel de demain. Il y a
|
||||
essentiellement rien sur titanic. Le réseau est configuré convenablement,
|
||||
j'ai pas encore réussi à faire marcher le tunnel pour ovh. Il va falloir
|
||||
faire un proxy transparent pour le https, à moins qu'on veuille faire du nat.
|
||||
|
||||
### Système de génération des fiches de déconnexion
|
||||
|
||||
Voir point suivant.
|
||||
|
||||
### Vlan pour les personnes déconnectées
|
||||
|
||||
Le système de déconnexion avec prévention par fiche papier est trop
|
||||
contraignant. Il a été suggéré de mettre toutes les personnes déconnectées dans
|
||||
un vlan à part, une sorte de portail captif, dans lequel les adhérents pourront
|
||||
être notifiés par une page web de leur déconnexion. Ce vlan séparé pourrait
|
||||
aussi utilisé à d'autres fins.
|
||||
|
||||
Jben se penchera sur le problème après ses partiels.
|
||||
|
||||
### Install-party
|
||||
|
||||
Projet: on crée un vlan install-party, dans lequel on met un serveur (par
|
||||
exemple domU de fx) qui fera serveur tftp (pour faire des installs par le
|
||||
réseau), dhcp, routeur (avec éventuellement nat).
|
||||
|
||||
Autres supports d'installation: clefs usb à préparer, cdroms à graver. On
|
||||
privilégiera le boot par réseau. Attention aux Windows Vista, il faudra
|
||||
utiliser l'outil Windows pour le repartitionnement.
|
||||
|
||||
### Système de versionnement
|
||||
|
||||
On décide à l'unanimité de migrer vers darcs. Stéphane s'occupe de faire un
|
||||
tutorial sur le wiki pour le crans. On commence avec le /usr/scripts.
|
||||
|
||||
### Migration vers Postgresql
|
||||
|
||||
Brainstorming, cf CransNostalgie/MigrationPostgresql
|
||||
|
||||
À suivre
|
||||
|
|
@ -0,0 +1,76 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 22 novembre 2007
|
||||
* Début : -- WikiSgnb <<DateTime(2007-11-22T19:43:30Z)>>
|
||||
* Fin : -- WikiSgnb <<DateTime(2007-11-22T21:05:50Z)>>
|
||||
* Lieu : au PdJ
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Étienne Descamps
|
||||
* Jean-Benoist Léger
|
||||
* Jérémie Dimino
|
||||
* Nicolas Dandrimont
|
||||
* Romain Clément
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Bilan de l'Install-party
|
||||
|
||||
Cf réunion CA.
|
||||
|
||||
### Mise à disposition d'un serveur de boot par PXE
|
||||
|
||||
Accord de principe pour: on rajoute un champ dans la base, éditable par
|
||||
intranet et gest_crans. Ceux qui ont le champ adéquat booteront par le réseau.
|
||||
|
||||
Romain s'intéresse au problème et s'occupe de proposer un projet précis.
|
||||
|
||||
### Agrafeuse pour le service d'impression
|
||||
|
||||
Il y a des problèmes d'agrafage actuellement avec l'imprimante. Il faudrait
|
||||
contacter HP...
|
||||
|
||||
Augustin regarde avec l'ENS si ces derniers n'auraient pas un contrat de
|
||||
maintenance dont on pourrait bénéficier. Romain contacte Anne pour voir où on
|
||||
en est avec la garantie.
|
||||
|
||||
L'imprimante du 4J ne peut pas agrafer plus de 50 feuilles à la fois, ce qui
|
||||
est gênant pour les polycopiés. On pourrait mettre un agrafeuse digne de ce nom
|
||||
en libre service (pas pour l'embarquer...) dans la partie publique du 4J. Non,
|
||||
car c'est source de trop nombreux ennuis.
|
||||
|
||||
### Titanic
|
||||
|
||||
Jérémie continue la conf de titanic.
|
||||
|
||||
### Bcfg2
|
||||
|
||||
Jérémie n'a pas avancé.
|
||||
|
||||
### Système de gestion des problèmes
|
||||
|
||||
À partir des documents fournis par VIA, et d'idées jetées en vrac. Il faut se
|
||||
rapprocher plus de VIA pour étudier leur solution. On en reparle plus tard.
|
||||
|
||||
### IRC
|
||||
|
||||
Il faudrait faire un peu plus de pub pour l'IRC (en particulier le serveur de
|
||||
Rezosup).
|
||||
|
||||
### Migration PostgreSQL
|
||||
|
||||
Il faut étudier la base de VIA.
|
||||
|
||||
### Migration du www/wiki vers un domU
|
||||
|
||||
Stéphane propose d'utiliser Ocsigen à la place d'Apache afin de permettre aux
|
||||
développeurs (d'Ocsigen) de tester Ocsigen sur un « vrai » site. On veillera à
|
||||
conserver à côté une configuration fonctionnelle d'Apache afin de parer toute
|
||||
éventualité.
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 6 décembre 2007
|
||||
* Début : -- WikiSgnb <<DateTime(2007-12-06T19:46:33Z)>>
|
||||
* Fin : -- WikiSgnb <<DateTime(2007-12-06T21:57:00Z)>>
|
||||
* Lieu : au PdJ
|
||||
|
||||
## Présents
|
||||
|
||||
* Elsa Dupraz
|
||||
* Jean-Benoist Léger
|
||||
* Jérémie Dimino
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Pierre Chambart
|
||||
* Stéphane Glondu
|
||||
|
||||
## Réunion
|
||||
|
||||
### Suite des épisodes précédents
|
||||
|
||||
Mise à disposition d'un serveur de boot par PXE::
|
||||
Romain n'est pas là.
|
||||
|
||||
Problèmes avec l'imprimante::
|
||||
Il y a vraiment un problème d'agrafage ! Stéphane va essayer de constater le
|
||||
problème lui-même, puis recontacte Anne à ce sujet.
|
||||
|
||||
### Déploiements
|
||||
|
||||
#### Titanic
|
||||
|
||||
Selon Jérémie, le web de la connexion de secours devrait marcher théoriquement,
|
||||
mais aucun test n'a été réalisé.
|
||||
|
||||
#### Darcs
|
||||
|
||||
Suivi des modifications::
|
||||
|
||||
Jérémie a backporté darcs-monitor qui permet de suivre les modifications de la
|
||||
même manière qu'actuellement avec cvs-syncmail.
|
||||
|
||||
Stéphane a converti le /usr/scripts à darcs, mais a constaté que darcs monitor
|
||||
était vraiment trop lent lorsque le dépôt avait beaucoup de patches, ce qui est
|
||||
le cas pour /usr/scripts (> 3000 patches).
|
||||
|
||||
À défaut de trouver mieux, on s'orientera vers une solution maison.
|
||||
|
||||
Une fois ce système de notification mis en place, Stéphane s'occupe de migrer
|
||||
tout ce qu'il y a dans le CVS et de faire la doc sur le wiki.
|
||||
|
||||
#### Bcfg2
|
||||
|
||||
Jérémie a déjà backporté la version testing (plus de fonctionnalités). Il
|
||||
envisage de suivre une version plus récente car il souhaite utiliser des
|
||||
fonctionnalités récentes très intéressantes.
|
||||
|
||||
Jérémie s'occupe de documenter le système sur wiki.
|
||||
|
||||
Déjà fait: Postfix.
|
||||
|
||||
Darcs a été adopté pour le versionnement.
|
||||
|
||||
#### Gestion des adhérents
|
||||
|
||||
Système de gestion des problèmes::
|
||||
Tout le monde est convaincu que ce système sera à intégrer à la nouvelle base.
|
||||
|
||||
Support technique::
|
||||
Il faudrait former une délégation pour rendre visite à VIA à ce sujet.
|
||||
|
||||
PostgreSQL::
|
||||
Brainstorming à continuer.
|
||||
|
||||
#### Gestion des projets
|
||||
|
||||
Trac a été mentionné par Jérémie. Il semble fonctionnel et agréable et il est
|
||||
programmé en Python. Nicolas va l'installer sur un domU.
|
||||
|
||||
#### Site www/wiki
|
||||
|
||||
On s'orientera vers une implantation FastCGI de MoinMoin. Le module FastCGI
|
||||
d'Ocsigen est en cours de développement, donc quelques mois à attendre...
|
||||
|
||||
### Divers
|
||||
|
||||
Gestion des secrets::
|
||||
Jérémie propose de mettre tout ce qui est "sensible" (secrets,
|
||||
etc.) dans /etc/crans et de supprimer totalement la présence de fichiers de
|
||||
secrets dans les mêmes répertoires que les dépôts (ceci afin d'éviter de
|
||||
commiter des mots de passe accidentellement). Les mots de passe apparaissant
|
||||
dans les fichiers de conf que l'on souhaiterait versionnés seraient gérés par
|
||||
bcfg2.
|
||||
|
||||
IRC::
|
||||
Les avis sont partagés. On va mettre en place un serveur IRC privé sur le
|
||||
modèle des news dans un domU, en faire la pub, et voir ce qui se passe. Il
|
||||
faudrait aussi prévoir un moyen convivial d'y accéder, par exemple avec une
|
||||
interface web (exécutée côté client, style JS ou Java), dans le même style que
|
||||
l'interface SSH.
|
||||
|
||||
News::
|
||||
Il faudrait les migrer vers un domU, et fournir une interface comme pour IRC
|
||||
ci-dessus.
|
||||
|
||||
Aslvid::
|
||||
Ce serveur dort depuis plusieurs mois. Le proxy est actuellement un réel goulot
|
||||
d'étranglement sur le réseau. La discussion a fait apparaître comme évidente la
|
||||
nécessité de le mettre une machine dédiée. Aslvid semble approprié (les
|
||||
caractéristiques précises sont cependant à vérifier). À l'occasion, il a été
|
||||
rebaptisé ''sable'' (nom issu d'un brainstorming très poussé).
|
||||
|
||||
Il faudra vraisemblablement rajouter de la RAM à sable. Stéphane prospecte.
|
||||
Pour les disques (physiquement, 2 disques de 72 Go), on fait 30 Go de
|
||||
RAID1+LVM (pour système + logs) et le reste pour les spools + swap.
|
||||
|
||||
Ragnarok::
|
||||
Il faut le mettre à jour. Mathieu a donné quelques indications. On laisse un
|
||||
jeune s'en charger. À faire tôt le matin (après avoir dormi). Bien lire et
|
||||
suivre le release notes. On se donne rdv dimanche matin à 06:00 AM CEST (il
|
||||
faut être opérationnel, càd après avoir bien dormi) pour faire ça. Il y aura au
|
||||
moins Stéphane, Nicolas et Jean-Benoist.
|
||||
|
||||
### Attribution de nouveaux droits nounou
|
||||
|
||||
Les droits Nounou ont été attribués à Michel, Jean-Benoist et Nicolas.
|
||||
|
|
@ -0,0 +1,91 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 20 décembre 2007
|
||||
* Début : -- WikiSgnb <<DateTime(2007-12-20T19:32:46Z)>>
|
||||
* Fin : -- WikiSgnb <<DateTime(2007-12-20T20:57:53Z)>>
|
||||
* Lieu : au PdJ
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Jean-Benoist Léger
|
||||
* Jérémie Dimino
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Pierre Chambart
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Réunion
|
||||
|
||||
### Bilans
|
||||
|
||||
Problèmes avec l'imprimante::
|
||||
|
||||
Stéphane va essayer de constater le problème et de contacter HP.
|
||||
|
||||
Connexion de secours::
|
||||
|
||||
Théoriquement, le proxy et les mails fonctionnent sur la connexion de secours.
|
||||
On se donne rendez-vous le 6 janvier 2008 à 05:00 (date éventuellement à
|
||||
modifier) au 2B (si cette connexion de secours n'a pas été sollicitée d'ici
|
||||
là) pour la tester grandeur nature.
|
||||
|
||||
Bcfg2::
|
||||
|
||||
Jérémie va faire des pages wiki pour expliquer l'architecture CRANS afin que
|
||||
d'autres personnes que lui puissent faire quelque chose.
|
||||
|
||||
Effectué::
|
||||
|
||||
* Mise à jour de ragnarok vers OpenBSD 4.2
|
||||
* Migration de komaz sur une nouvelle machine
|
||||
* Transformation de l'ancien komaz un mirroir Debian local (nommé mdr)
|
||||
|
||||
En cours::
|
||||
|
||||
* Migration des confs CRANS vers Darcs
|
||||
* Installation de trac
|
||||
|
||||
En instance::
|
||||
|
||||
* Migration du www/wiki vers un domU (Stéphane)
|
||||
* Migration des news
|
||||
* Installation d'un serveur IRC
|
||||
|
||||
### Déploiements
|
||||
|
||||
#### Redondance des services
|
||||
|
||||
Routeur::
|
||||
|
||||
Augustin va se renseigner, mais pas tout de suite. Il a entendu parler
|
||||
de !HeartBeat...
|
||||
|
||||
Proxy::
|
||||
|
||||
L'interaction avec le proxy transparent n'est pas claire... À méditer.
|
||||
|
||||
#### Encodage
|
||||
|
||||
On passe tout en UTF-8. On fera le switch le 6 janvier (date éventuellement à
|
||||
modifier). On restera ensuite à l'affût pendant quelques heures pour réparer
|
||||
éventuellement ce qui est cassé (''a priori'', pas grand chose).
|
||||
|
||||
Une migration vers UTF-8 a déjà été faite dans le passé. Ça pourrait être
|
||||
intéressant que ceux qui étaient là signalent les problèmes qu'ils auraient
|
||||
rencontrés.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
Permanence nounou::
|
||||
|
||||
Augustin, Jérémie, Pierre, Nicolas, Stéphane ne seront pas à Paris (au
|
||||
moins) du 26 au 31 décembre (CCC). Pendant cette période, Michel restera en
|
||||
région parisienne, joignable par téléphone portable en cas de pépin. Ce serait
|
||||
bien qu'il y ait aussi quelqu'un d'autre. Stéphane laissera son trousseau de
|
||||
clés à la porterie de l'ENS avec une liste de noms de personnes habilitées à
|
||||
les emprunter.
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Mercredi 6 Février 2008
|
||||
* Début : -- WikiSgnb <<DateTime(2008-02-06T18:15:00Z)>>
|
||||
* Fin : -- WikiSgnb <<DateTime(2008-02-06T19:53:13Z)>>
|
||||
* Lieu : Condorcet
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* François Bobot
|
||||
* Jean-Benoist Léger
|
||||
* Jérémie Dimino
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Réunion
|
||||
|
||||
### Bilans
|
||||
|
||||
#### BdS
|
||||
|
||||
La paire de fibres utilisée par le BdS est défectueuse (après tests).
|
||||
Apparemment, une autre paire est libre. Si la seconde paire n'est pas libre, ou
|
||||
est défectueuse, la DSI nous propose des VLANs (il nous faut le VLAN par
|
||||
défaut, wifi (3) et hotspot (4)). Affaire à suivre (demain)...
|
||||
|
||||
Régler aussi le problème de la Kokarde.
|
||||
|
||||
En profiter aussi pour tâter le terrain concernant l'emprunt de machines pour
|
||||
les 10 ans.
|
||||
|
||||
#### OVH
|
||||
|
||||
Il faut le réinstaller:
|
||||
|
||||
* critique: MX secondaire, DNS secondaire, VPN, SQLgrey
|
||||
|
||||
Nicolas a été porté volontaire pour le faire.
|
||||
|
||||
#### Connexion de secours
|
||||
|
||||
Il faudrait rajouter dans la macro wiki autostatus le cas où le switch
|
||||
automatique a été désactivé. Xavier a été porté volontaire pour le faire.
|
||||
|
||||
#### Renouvellement de la freebox
|
||||
|
||||
Xavier a suggéré de renouveler notre freebox. Les autres présents n'en voient
|
||||
pas trop l'intérêt. On en reparle dans quelques années.
|
||||
|
||||
#### Serveur IRC
|
||||
|
||||
Il est opérationnel. Il reste encore quelques détails à tuner (mettre des
|
||||
services, limiter les connexions par IRC et CGI:IRC, ...). On attend un peu
|
||||
avant de faire la pub.
|
||||
|
||||
#### Switchs
|
||||
|
||||
Bâtiment A: deux switchs morts, remplacés avec ceux récupérés du G. HP a été
|
||||
contacté pour deux switchs. Un troisième marchotte et fera probablement l'objet
|
||||
d'un échange.
|
||||
|
||||
Point de détail soulevé par Augustin: quid de la garantie d'intervention sur
|
||||
site d'HP ? Selon Stéphane, cette garantie concernait les serveurs, mais
|
||||
personne n'est sûr.
|
||||
|
||||
Il semblerait que la limitation TFTP ait été corrigée dans une version récente
|
||||
du firmware. Jean-Benoist va se pencher de nouveau sur la mise en place du DHCP
|
||||
snooping et de la protection ARP.
|
||||
|
||||
#### BCfg2
|
||||
|
||||
Jérémie a écrit une doc sur le wiki: CransTechnique/Bcfg2. Jérémie coordonne
|
||||
les efforts.
|
||||
|
||||
#### Migration des news
|
||||
|
||||
Opérationnel, n'importe qui peut tester le nouveau serveur (newnews). Dans une
|
||||
semaine, si aucun problème ne se manifeste, Michel fera la migration
|
||||
définitive. Il regarde les différentes interfaces web que l'on pourrait
|
||||
proposer.
|
||||
|
||||
#### Divers
|
||||
|
||||
En cours::
|
||||
|
||||
* Migration des confs CRANS vers Darcs (Stéphane)
|
||||
|
||||
En instance::
|
||||
|
||||
* Problèmes avec l'imprimante: Michel a été porté volontaire pour s'en occuper
|
||||
* Demande d'un devis pour le nouveau sable (Stéphane)
|
||||
* Migration du www/wiki vers un domU (Stéphane)
|
||||
* Installation de nurpawiki (Stéphane)
|
||||
* Migration vers UTF-8
|
||||
|
||||
### Remarques diverses
|
||||
|
||||
#### Clefs du 4J
|
||||
|
||||
Il y a 2 clefs dans la nature. Parmi les présents, personne n'a d'idée de leur
|
||||
localisation.
|
||||
|
||||
#### Nouveaux droits nounou
|
||||
|
||||
Jérémie propose d'accorder les droits nounou à Antoine. Accepté à l'unanimité
|
||||
des présents.
|
||||
|
|
@ -0,0 +1,122 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 21 Février 2008
|
||||
* Début : -- WikiSgnb <<DateTime(2008-02-21T19:36:54Z)>>
|
||||
* Fin : -- WikiSgnb <<DateTime(2008-02-21T21:43:25Z)>>
|
||||
* Lieu : Pavillon des Jardins
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Charles Vallantin-Dulac
|
||||
* Jean-Benoist Léger
|
||||
* Jérémie Dimino
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Réunion
|
||||
|
||||
### BdS
|
||||
|
||||
La connexion du BdS a été coupée à cause d'une boucle au niveau des switchs de
|
||||
la DSI qui déconnectait le D'Alembert au niveau du backbone. Le problème est
|
||||
qu'actuellement, le réseau au D'Alembert et au Cournot sont mutuellement
|
||||
exclusifs. Le réseau du D'Alembert ayant plus d'utilisateurs, il est décidé de
|
||||
le privilégier.
|
||||
|
||||
### Coopération avec la DSI
|
||||
|
||||
Stuart a demandé une réunion pour faire une mise au point sur les différents
|
||||
VLANSsdu CRANS et de la DSI. À faire: lui envoyer les VLANs de l'ENS visibles
|
||||
au 0B et la liste de nos propres VLANs, et le plan de notre réseau.
|
||||
|
||||
### IRC
|
||||
|
||||
SolidIRCd ne répond pas à nos attentes. De nombreux vieux bugs non corrigés,
|
||||
base de code historique obsolète, il y a mieux actuellement. On va tester avec
|
||||
unreal.
|
||||
|
||||
### News
|
||||
|
||||
Le nouveau serveur semble fonctionner. Le feu est vert pour la migration. Ici,
|
||||
migration = rsync du /var/spool/news serveurs arrêtés.
|
||||
|
||||
### Switchs
|
||||
|
||||
Deux nouveaux switchs sont arrivés. Deux anciens sont partis. Deux autres sont
|
||||
en instance.
|
||||
|
||||
### Coupures de courant
|
||||
|
||||
Il faudrait configurer correctement les serveurs du 0B pour qu'ils s'éteignent
|
||||
au moment approprié. Bcfg2 semble approprié. Il faut s'arranger pour vert
|
||||
s'éteigne (proprement) en dernier.
|
||||
|
||||
### Serveurs
|
||||
|
||||
Tous les domUs devront être « documentés » sur la page de leur dom0. Il faut
|
||||
mettre à jour le wiki. Antoine s'en charge.
|
||||
|
||||
### Wiki/Site web
|
||||
|
||||
De nombreuses personnes présentes trouvent le wiki trop bordélique. Le mélange
|
||||
sous-arborescence/catégorie nuit à la clarté. Les catégories sont plus souples,
|
||||
il est proposé de tout migrer vers une architecture à base de catégories...
|
||||
reste à définir les catégories ! On en rediscute la prochaine fois. Tous les
|
||||
reponsables wiki seront invités.
|
||||
|
||||
### Imprimante
|
||||
|
||||
Intervention sur site par HP pour matériel hors garantie: 1435 € TTC.
|
||||
Garantie 3 mois. Le problème actuellement est que les incidents ne sont pas
|
||||
systématiques, et donc on n'a pas de moyen de reproduire avec certitude et de
|
||||
vérifier que la réparation est efficace... Il faut déterminer un protocole de
|
||||
test avec des résultats 100 % caractéristiques des problèmes de l'imprimante.
|
||||
|
||||
### Remplacement du proxy
|
||||
|
||||
* 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.
|
||||
* Deuxième devis avec processeur Xeon Quad Core.
|
||||
|
||||
### Clefs du 4J
|
||||
|
||||
Il y toujours deux clefs perdues. Plusieurs personnes se sont portées
|
||||
volontaires pour avoir une clefs du 4J (et les responsabilités qui vont avec).
|
||||
Il serait de bon goût de la part de certaines personnes qui ont une clefs du 4J
|
||||
et qui ne s'en servent plus de rendre leur clé. (En particulier, BarBichu va
|
||||
donner sa clé à Ryo)
|
||||
|
||||
### Diversification des VLANs
|
||||
|
||||
Jérémie fait remarquer qu'une machine sur le VLAN adm a trop de droits, et
|
||||
qu'il pourrait être judicieux de compartimenter certains services dans des
|
||||
VLANs séparés. Par exemple, Bcfg2 pourrait être utile même sur des machines qui
|
||||
ne sont pas sur le VLAN adm. Premier argument contre la multiplication de
|
||||
VLANs: la maintenabilité. Une autre solution serait de migrer les
|
||||
services « sûrs » (chiffrés) sur le VLAN normal et d'ainsi limiter le nombre de
|
||||
machines sur le VLAN adm. Le point négatif: le NFS. À suivre...
|
||||
|
||||
### Bilans divers
|
||||
|
||||
Fait::
|
||||
|
||||
* Macro autostatus
|
||||
* Migration des confs CRANS vers Darcs. Signaler tout oubli.
|
||||
|
||||
En cours::
|
||||
|
||||
* Bcfg2 (tout le monde)
|
||||
* OVH (Nicolas)
|
||||
* Jouvence (Elsa)
|
||||
|
||||
En instance::
|
||||
|
||||
* Migration du www/wiki vers un domU (Stéphane)
|
||||
* Installation de nurpawiki (Stéphane)
|
||||
* Migration vers UTF-8
|
||||
|
|
@ -0,0 +1,61 @@
|
|||
# Réunion nounous
|
||||
|
||||
* Date : Jeudi 8 mai 2008
|
||||
* Début : 20:42
|
||||
* Fin : 21:42
|
||||
* Lieu : Salle de conférences du Pavillon des Jardins
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Jean-Benoist Léger
|
||||
* Johan Grande
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Pierre Chambart
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Bilans des derniers incidents et de leur gestion
|
||||
|
||||
Mise à jour de l'IP d'ovh.crans.org::
|
||||
Suite à un changement de machine, l'IP d'ovh a changé (08/02/2008). La mise à
|
||||
jour a été faite dans les DNS du Crans, mais pas chez le registrar. Cet oubli
|
||||
est passé inaperçu pendant trois mois : sur toutes les machines extérieures
|
||||
testées, l'IP était à jour. On a donc remis ovh dans les MXs (29/04/2008).
|
||||
Stéphane s'est aperçu que l'IP n'était pas à jour sur certains serveurs et a
|
||||
retiré ovh des MXs (06/05/2008). De plus, l'ancienne IP a été réaffectée à une
|
||||
machine sur laquelle tourne aussi un serveur SMTP qui refusait nos mails. Cela
|
||||
a eu comme conséquence la « perte » (mais avec notification à l'expéditeur) des
|
||||
mails qui passaient par un serveur chez ovh qui avait toujours l'ancienne IP,
|
||||
entre le 29/04 et le 06/05.
|
||||
|
||||
TLS sur ovh.crans.org::
|
||||
Les certficats SSL manquaient suite à la réinstallation d'ovh, ce qui a eu pour
|
||||
conséquence l'échec systématique de la commande STARTTLS, sans conséquence pour
|
||||
la délivrance des mails.
|
||||
|
||||
Occupation mémoire de la base postgres de sqlgrey::
|
||||
Sqlgrey et le processus postgres associé consomment une quantité excessive de
|
||||
RAM (> 1 Go). On n'a aucune idée de la raison de ce comportement. Cela fait
|
||||
swapper rouge. Nicolas cherche toujours, mais le projet sqlgrey semble mort et
|
||||
est écrit en Perl. Il envisage de s'orienter vers une autre solution anti-spam.
|
||||
|
||||
### Installation de sable
|
||||
|
||||
Ça traîne. Nicolas va essayer de boucler ça ce week-end.
|
||||
|
||||
### Imprimante
|
||||
|
||||
Ça traîne. Jean-Benoist a été pingué sur l'affaire.
|
||||
|
||||
### Sémantique de la sanction bloq
|
||||
|
||||
La blackliste squid associée à la sanction bloq semble inutile : cette sanction
|
||||
provoque déjà la disparition de la machine du DNS, du DHCP, le bannissement au
|
||||
niveau du radius sur les switchs, etc... bref, la machine n'existe plus.
|
||||
Stéphane propose de supprimer cette blackliste. Cela nous allègera d'un message
|
||||
quotidien de cron sur sila.
|
||||
|
|
@ -0,0 +1,198 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 26 juin 2008
|
||||
* Début : 20h01
|
||||
* Fin : 22h18
|
||||
* Lieu : 2@B
|
||||
|
||||
## Présents
|
||||
|
||||
### Physiquement
|
||||
|
||||
* Augustin Parret-Fréaud
|
||||
* Charles Vallantin-Dulac
|
||||
* Jean-Benoist Leger
|
||||
* Nicolas Dandrimont
|
||||
* Xavier Lagorce
|
||||
|
||||
### À distance (gobby)
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Michel Blockelet
|
||||
* Vincent Thomas
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Redistribution des services de Rouge
|
||||
|
||||
Rouge est actuellement en train de crouler sous les connexions persistantes de
|
||||
certains clients mail, notamment concernant dovecot, il a donc été décidé de
|
||||
rééquilibrer les services sur différents serveurs sous-utilisés (p.e. sila) pour
|
||||
tenter de le décharger et par conséquent d'améliorer la qualité de service du
|
||||
Cr@ns.
|
||||
|
||||
#### Services redistribuables
|
||||
|
||||
* Bases de données de filtrage (-> Komaz). Augustin s'en occupera après
|
||||
le 18 juillet.
|
||||
* Jabber (-> le domU hébergeant le serveur irc avec éventuellement un serveur
|
||||
irc « de secours » sur mdr en cas de panne). Michel s'en occupe.
|
||||
* DNS principal sur sila ? On garderait rouge en secondaire... Nicolas s'en
|
||||
occupe.
|
||||
|
||||
#### Services à migrer si ça pose toujours problème
|
||||
|
||||
* La DB de greylisting... Changer de solution ? Changer de backend (MySQL ?) ?
|
||||
* Mettre le SMTP principal sur un autre serveur... ?
|
||||
* Mailman ?
|
||||
|
||||
Au final, il a été décidé de migrer DNS, base de filtrage et Jabber sur des
|
||||
autres serveurs, et de regarder l'état de la charge de rouge après migration.
|
||||
Si nécessaire, la migration d'autres services sera alors envisagée dans un
|
||||
second temps.
|
||||
|
||||
### WiFi en WPA2
|
||||
|
||||
Ce point n'a pas été abordé à cause de l'absence de Mathieu Segaud.
|
||||
|
||||
### Mise en place d'un VLAN de services gratuits par défaut
|
||||
|
||||
Suite aux nouveaux statuts, nous allons mettre en place un service de connexion
|
||||
gratuit.
|
||||
|
||||
Pour rappel, ce service de connexion permettra seulement l'accès au Web et aux
|
||||
ENT. Signature d'une charte après câblage à la Kfet (et inscription des
|
||||
machines)...
|
||||
Nous sommes en effet tenus de faire signer une charte selon notre convention
|
||||
avec la DSI. Il a été décidé de placer ces connexions derrière un NAT. Nous
|
||||
devons alors garder, de la même manière que pour le VLAN par défaut, une
|
||||
correspondance entre l'IP locale et le nom de la personne (pour
|
||||
responsabilisation). Il est donc choisi de placer ces machines sous une IP
|
||||
locale fixe.
|
||||
|
||||
Des modifications au schéma de la base LDAP sont à prévoir.
|
||||
|
||||
On ne permet pas de préinscription, cela pose en effet certains problèmes
|
||||
juridiques (connexions entre adhérents non contrôlées et non soumises à
|
||||
acceptation d'une charte).
|
||||
|
||||
Mise en place de ce système :
|
||||
|
||||
* Modification du script crans. J.Benoist s'en occupe.
|
||||
* Modification/adaptation de gen_confs des switchs pour placer les gens dans ce
|
||||
vlan. Idem.
|
||||
* Mise en place d'un DHCP. Trivial car identique au DHCP actuel, ça sera fait
|
||||
en même temps que la modif du script Crans.
|
||||
* Mise en place du NAT. Trivial aussi, Nicolas s'en occupe.
|
||||
|
||||
Il est décidé de ne fournir l'accès au web uniquement (ENT compris) (i.e. pas
|
||||
au réseau des adhérents payant) via les ports 80 et 443.
|
||||
|
||||
Ce service se limite à ceci, et nous reconsidérerons le panel des services dans
|
||||
l'éventualité d'un accord avec le CROUS.
|
||||
|
||||
### Raccordement des appartements de l'ENS
|
||||
|
||||
Une réunion a eu lieu avec Stuart !McLellan et Roland Abidos afin de mettre en
|
||||
place le raccordement des appartements de fonction de l'ENS. A priori, on
|
||||
passerait sur un VLAN dédié au niveau de l'ENS.
|
||||
Si une charte est signée, ils pourraient passer par RUBIS selon Stuart. A
|
||||
l'exception
|
||||
du Pavillon des Jardins et de la porterie, tous les bâtiments sont câblés et
|
||||
arrivent
|
||||
dans un local de brassage, avec des prises libres sur des
|
||||
switches !ProCurve (un Switch
|
||||
à rajouter probablement au Cournot). Il faudrait arranger un accès aux logs des
|
||||
switches concernés, ou _au mieux_ physique (passablement impossible).
|
||||
Problème de la TV par le réseau : le trafic des appartements passera via
|
||||
Multiprise_Wifi,
|
||||
un D-Link... Il faudrait voir à le (faire) changer par un procurve.
|
||||
L'accès ne sera ouvert qu'après la signature de la convention.
|
||||
|
||||
### Mise en place du VLAN déconnectés
|
||||
|
||||
La mise en place du VLAN déconnecté est retardée à cause de l’impossibilité des
|
||||
commutateurs à effectuer une mise sur VLan par serveur Radius, feature promise
|
||||
par HP il y a environ deux ans.
|
||||
|
||||
Une autre possibilité est de faire la mise en place par script, ce qui pose tout
|
||||
de même un problème pour les switchs non manageables du Pavillon des Jardins,
|
||||
ainsi
|
||||
que pour les trucs un peu sales faits pour régler certains problèmes de prises
|
||||
défectueuses...
|
||||
Il y aurait donc certains gens non déconnectables automatiquement, problème
|
||||
analogue
|
||||
aux désactivations de prise... Il y a aussi quelques erreurs dans la
|
||||
correspondance
|
||||
chambre <-> prise.
|
||||
|
||||
Actuellement les déconnectés ont uniquement une page sur squid, et ont toujours
|
||||
accès au réseau local. La mise en place de ce VLAN est donc nécessaire pour
|
||||
l'efficacité des sanctions... (la sanction bloq est trop brutale).
|
||||
|
||||
PdJ : on remplace les switches actuels (25 ports + Dlink "multiprise") par les
|
||||
switches 50 ports dormant au 2@B et 0@C. Nous referons un point pour la
|
||||
reconnexion
|
||||
éventuelle du bâtiment G (il en manquera certainement).
|
||||
|
||||
Michel se demande si l'on avait inclus le PDJ dans les services gratuits.
|
||||
Il regarde. C'est en effet très flou.
|
||||
|
||||
### Logs en tout genre de l'imprimante
|
||||
|
||||
Un script a été écrit pour récupérer les logs de l'imprimante (et ainsi avoir
|
||||
plus
|
||||
de pistes pour comprendre pourquoi elle bourre) rien de plus à dire là-dessus
|
||||
pour
|
||||
le moment, puisque l'imprimante n'a pas bourré depuis le lancement du script
|
||||
(Heisenbug).
|
||||
Il est aussi réalisé des logs de toutes les estimations en vue de réestimer
|
||||
les coûts de l'impression, qui sont passablement surévalués selon l'audit
|
||||
effectué
|
||||
récemment.
|
||||
|
||||
Il est confirmé par J.Benoist que l'intervention effectuée récemment n'a pas
|
||||
de rapport avec les bourrages, et que la garantie de 3 mois ne peut donc pas
|
||||
s'appliquer.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Présence de Nounous sur le campus pendant l'été
|
||||
|
||||
Il est rappelé la présence de la page CransVacances... Qui doit être remplie,
|
||||
ça ne coûte rien et ça évitera des coups de fil pour rien.
|
||||
|
||||
Des mails de rappel seront envoyés aux nounous qui *doivent* s'inscrire. Il sera
|
||||
également proposé aux apprentis, câbleurs et imprimeurs de s'inscrire afin de
|
||||
mieux
|
||||
évaluer la présence des gens sur le campus pendant l'été.
|
||||
|
||||
#### Trafic « geek » sur la ML Bureau
|
||||
|
||||
Il y a sur la mailing-list bureau du passage de mails de surveillance qui
|
||||
devraient
|
||||
plutôt aller sur une mailing list telle que disconnect, dans laquelle il
|
||||
faudrait
|
||||
d'ailleurs faire le ménage. J.Benoist s'en occupe.
|
||||
|
||||
#### État du 2@B
|
||||
|
||||
Le prochain qui met le 2@B en capharnaüm se fait crever les yeux par J.Benoist
|
||||
et couper les mains par Nicolas.
|
||||
|
||||
#### Perte ? de messages sur les news
|
||||
|
||||
Les vieux messages ont été purement et simplement perdus... Comment se fait-ce ?
|
||||
C'est assez bizarre, à priori le expire.ctl, fichier de conf du serveur nntp, a
|
||||
l'air correct :
|
||||
|
||||
---✂--- <<BR>>
|
||||
|
||||
crans.*:A:never:never:never <<BR>>
|
||||
tac.*:A:90:150:180 <<BR>>
|
||||
crans.cvs-checkins:A:30:45:60 <<BR>>
|
||||
|
||||
---✂---
|
||||
|
||||
En effet, les fora tac.* sont purgés au bout de 180 jours... Mais qu'en est-il
|
||||
de crans.* ? De plus amples investigations sont à faire.
|
||||
|
|
@ -0,0 +1,232 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 25 septembre 2008
|
||||
* Début : <<DateTime(2008-09-25T17:41:00Z)>>
|
||||
* Fin : <<DateTime(2008-09-25T21:27:40Z)>> (on a mangé entre temps...)
|
||||
* Lieu : Pavillon des Jardins
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin (adg)
|
||||
* Anne Cazalet (Anne Cazalet)
|
||||
* Augustin Parret-Fréaud (apf)
|
||||
* Benoit Barbot
|
||||
* Jérémie Dimino (dim)
|
||||
* Johan Grande (jojo)
|
||||
* Laurent Taylor (marn)
|
||||
* Mathieu Segaud (Regala)
|
||||
* Michel Blockelet (!AlphaTigrou)
|
||||
* Nicolas Dandrimont (olasd)
|
||||
* Pierre Chambart (Chicco)
|
||||
* Stéphane Glondu (sgnb)
|
||||
* Thomas Blanc (pat)
|
||||
* Vincent Maioli (Neseb)
|
||||
* Xavier Lagorce (lxir)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Point(s) Matériel
|
||||
|
||||
#### Remplacement de rouge
|
||||
|
||||
On a constaté de nombreux plantages de rouge. Or rouge étant toujours sous
|
||||
garantie, il serait bon de contacter le sav (rapidement, car celle-ci expire
|
||||
bientôt).
|
||||
|
||||
SAV HP : 0826 10 49 49
|
||||
|
||||
Penser à envoyer le numéro de série à Anne.
|
||||
|
||||
#### Remplacements de pegase, de vert
|
||||
|
||||
Les serveurs de données et de sauvegarde se font vieux, il faudrait penser
|
||||
à les renouveler.
|
||||
|
||||
Pour le remplacement de vert, on a considéré l'investissement dans un SAN/NAS/?,
|
||||
qui pourrait servir, en plus du stockage des données des adhérents, de stocker
|
||||
les données concernant les racines des domUs actuels et futurs.
|
||||
|
||||
On partirait a priori sur une solution avec une baie de disques extensible en
|
||||
fonction des besoins. La question porte alors sur le mode de raccordement des
|
||||
serveurs :
|
||||
|
||||
* [Fibre Channel](http://en.wikipedia.org/wiki/Fibre_Channel) :
|
||||
protocole spécifique séparé (performant, bien overkill et
|
||||
nécessite d'ouvrir les serveurs pour rajouter des cartes spécifiques)
|
||||
* export NFS (pollue la bande passante, mais vu que les serveurs sont
|
||||
branchés sur le backbone en gigabit, ce n'est pas limitant)
|
||||
|
||||
Disques SAS (Serial Attached SCSI). Baie de disques.
|
||||
|
||||
Pour le remplacement de pegase, un serveur "pas cher" avec 1 To de stockage
|
||||
efficace (en raid5).
|
||||
|
||||
* ML110 (Xeon 3065, 570€) + 3 * 500 Go (à 200€ chacun).
|
||||
|
||||
#### Remplacement de l'onduleur du 0B
|
||||
|
||||
2 onduleurs de 3kVA ou un seul onduleur de 5kVA, nécessitant une installation
|
||||
électrique particulière, donc accord du CROUS etc.
|
||||
|
||||
### WPA2
|
||||
|
||||
Connexion actuelle : équivalent des VPN professionnels. Les bornes ne font que
|
||||
transmettre le flux chiffré depuis et à ragnarok.
|
||||
|
||||
Intérêt : pouvoir utiliser le wifi avec *tous* les terminaux classiques (PC
|
||||
sous Vista --osef, PDA, Smartphones, etc.).
|
||||
|
||||
Connexion WPA : chiffrement sur la borne, et surtout toutes les connexions
|
||||
seront en clair sur les vlan 3 et 4, cela pose certains problèmes de sécurité.
|
||||
Sécurité "dans les airs", mais ce n'est pas chiffré sur le fil (entre la borne
|
||||
et ragnarok) (chiffrer sur le fil et dans les airs, c'est trop pour les bornes).
|
||||
Il sera toujours possible d'effectuer du chiffrement IPSEC au dessus du WPA.
|
||||
|
||||
Multi-SSID : il faut changer les bornes existant à l'ENS.
|
||||
|
||||
todo:
|
||||
|
||||
* Migrer les bornes actuelles sous Kamikaze 8
|
||||
* Faire des tests sur un réseau séparé
|
||||
* login/mdp: nom de machine/clef (ex-)ipsec
|
||||
* on ne fait plus (forcément) d'ipsec
|
||||
* Faire des tests de performance, trop de gens connectés en WPA, ça peut être
|
||||
très lourd. (2Mo/s max pour chaque borne)
|
||||
|
||||
### Point sur la mise en place de la connexion gratuite
|
||||
|
||||
* Elle est sur le VLAN 6.
|
||||
* IP privées 10.42.0.0/16 non routées, attribuées aléatoirement (log DHCP
|
||||
gardés).
|
||||
* Sable est le seul serveur sur ce VLAN, c'est lui qui fournit tous
|
||||
|
||||
les "services" : le proxy en 80 (port HTTP) et 443 (port HTTPS) (pas pour
|
||||
l'instant, à faire **vite**)
|
||||
|
||||
* Limitation à 1Mo/s pour l'ensemble des inscrits.
|
||||
* Il faut qu'il y ait des gens qui s'inscrivent afin d'avoir un minimum de
|
||||
crédibilité.
|
||||
|
||||
Le vlan 7, d'accueil, récupère toutes les machines qui ne sont pas enregistrées
|
||||
dans la base (ou qui se branchent quand Radius chie......). Il faudrait ajouter
|
||||
à la page proxy un commentaire : "si vous êtes déjà inscrit, débranchez et
|
||||
rebranchez votre cable".
|
||||
|
||||
Il faut faire une page wiki récapitulant les points techniques à ce propos.
|
||||
|
||||
### Retour de sila
|
||||
|
||||
Il est de retour, avec plein de disques...
|
||||
|
||||
On a remonté un FTP avec pour l'instant :
|
||||
|
||||
* une archive debian complète (un jour, on prendra la place du miroir de
|
||||
l'ENS...)
|
||||
* l'archive openbsd que l'on avait précédemment
|
||||
* un miroir de VLC
|
||||
|
||||
Il faut mettre de la QoS sur le FTP pour éviter de péter le réseau de l'ENS lors
|
||||
des mises à jour de VLC...
|
||||
|
||||
### Changement des disques durs de la ferme
|
||||
|
||||
Cet été, il a fait chaud (encore une fois). Les disques de la ferme sont
|
||||
fatigués,
|
||||
il faut les changer. Ils sont au 2@B en attendant que Michel s'en occupe
|
||||
(avec n apprentis, n > 1, si on rajoute un "e" ça ira plus vite elle connait
|
||||
déjà la Ferme avec Michel..., exact).
|
||||
|
||||
Mouton est mort, on va le mettre sur orbite. De toute façon il ne servait qu'aux
|
||||
annonces SAP, qui sont supportées maintenant nativement par MumuDVB, et donc
|
||||
nous n'avons plus besoin de minisapserver. Il faut déplacer la génération des
|
||||
vignettes sur MDR, le serveur qui réchauffe inutilement le 4@J actuellement.
|
||||
|
||||
### Passage des serveurs/domUs à Lenny
|
||||
|
||||
À priori, on peut effectuer la transition pour les paquets n'ayant pas de bugs
|
||||
RC (on va pas beaucoup avancer avec ça...)
|
||||
|
||||
Les serveurs actuellement sous lenny :
|
||||
|
||||
* sila
|
||||
* munin
|
||||
* o2
|
||||
* xmpp
|
||||
|
||||
Il n'y en a plus qu'une vingtaine à migrer ! On va commencer par la ferme, qui
|
||||
ne contient pas de service critique... MumuDVB n'est de toute façon pas un
|
||||
paquet
|
||||
Debian. Il faudra penser à demander à Braice de vérifier si les noyaux lenny
|
||||
sont
|
||||
bons.
|
||||
|
||||
Il faudra veiller à réécrire les fichiers de confs des logiciels qui changeront
|
||||
de version majeure. Les mettre dans BCfg2 aussi tant qu'à faire.
|
||||
(exemples : Radius, ...)
|
||||
|
||||
Ça parait être une occasion en or pour finaliser la migration en utf-8.
|
||||
il ne faut la faire qu'une fois...
|
||||
<http://munin.crans.org/association.crans.org/web.rouge-wiki_themes.html> *ahaha*.
|
||||
|
||||
Une page wiki devra être mise en place pour recenser les tests de mises à jour
|
||||
effectués.
|
||||
|
||||
### Organisation des séminaires techniques
|
||||
|
||||
Les séminaires seront organisés tous les mercredis soir à 20h, en salle
|
||||
Condorcet.
|
||||
|
||||
Le premier (le 1er octobre) sera consacré à une présentation technique globale
|
||||
du réseau.
|
||||
|
||||
Le séminaire TCP/IP du 8 octobre sera effectué par pat (non, l'autre).
|
||||
|
||||
Le 15 et le 22 octobre seront organisés des séminaires de présentation du
|
||||
système GNU/Linux, préliminaire à l'install-party du 8 Novembre.
|
||||
|
||||
Thèmes importants à traiter : switches, LDAP, BCfg2, Apache et les trucs HTTP,
|
||||
OpenBSD et PF, WiFi (Regala), Asterisk et le SIP (Re-Regala), XMPP, ...
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Jabber connecté à LDAP
|
||||
|
||||
Un nouveau serveur Jabber a été créé, xmpp.crans.org. Les comptes sur ce serveur
|
||||
sont en fait les comptes crans. Pour l'instant, tous les alias fonctionnent mais
|
||||
pointent sur des comptes (listes de contact) différents. Il faudrait faire en
|
||||
sorte que tous les alias pointent vers le même roster. Malheureusement, il n'y a
|
||||
pas de méthode standard pour ce faire, des investigations sont en cours.
|
||||
|
||||
Il y a des raisons pour avoir des comptes différents... C'est donc peut-être pas
|
||||
la peine de fusionner les alias. À voir.
|
||||
|
||||
#### Problème de la transparence avec l'imprimante
|
||||
|
||||
L'imprimante imprime parfois les zones transparentes avec un aplat de
|
||||
couleur (correspondant à la "couleur de transparence" du fichier), plutôt que
|
||||
du blanc.
|
||||
|
||||
À moins de flasher l'imprimante, après avoir modifié les sources du
|
||||
firmware (que nous n'avons pas) nous ne voyons pas ce que nous pouvons faire...
|
||||
|
||||
#### Connexion des appartements de l'ENS
|
||||
|
||||
On va faire passer cette connexion par un vlan particulier, qui nous permettra
|
||||
de filtrer le contenu qui passerait du réseau Campus au réseau Appartements.
|
||||
|
||||
#### Blocage de bittorrent
|
||||
|
||||
Des abus récents nous poussent à bloquer totalement le trafic bittorrent passant
|
||||
par komaz.
|
||||
|
||||
#### Commande de LiveCD GNU/Linux
|
||||
|
||||
<http://shipit.ubuntu.com/> ne fait que des envois personnels. Il faudrait
|
||||
rapidement faire une commande de liveCD chez Ikarios, parce que c'est pas cher.
|
||||
Commande de:
|
||||
|
||||
* 50 LiveCD kikoololbuntu i686
|
||||
* 50 LiveCD kikoololbuntu amd64
|
||||
* 20 Netinstall debian
|
||||
|
|
@ -0,0 +1,124 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Jeudi 9 Octobre 2008
|
||||
* Début : 20h12
|
||||
* Fin : -- WikiNicolasd <<DateTime(2008-10-09T20:12:30Z)>>
|
||||
* Lieu : Pavillon des Jardins
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Benoît Barbot
|
||||
* Jérémie Dimino
|
||||
* Johan Grande
|
||||
* `man 1 sort`
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
RAPPEL:: Les données d'accès au proxy sont des données *personnelles* des
|
||||
adhérents (logs de squid), et les Nounous n'ont à y accéder en aucun cas. Cela
|
||||
paraissait une évidence pour tout le monde, mais ça ne coûte rien de le
|
||||
rappeler.
|
||||
|
||||
### Pédalages de rouge dans la semoule
|
||||
|
||||
Ce week-end, il y a eu pas mal de problèmes au niveau du www/wiki, et lundi, par
|
||||
miracle, tout s'est remis à fonctionner... Redémarrer Apache les refaisait
|
||||
fonctionner, mais que pendant une vingtaine de minutes.
|
||||
|
||||
Appeler HP pour le SAV n'est possible que si l'on arrive à diagnostiquer un
|
||||
problème précis et reproductible, ce qui n'est pas le cas actuellement.
|
||||
|
||||
### Migration du www/wiki vers Lenny
|
||||
|
||||
Afin de régler ce problème, Antoine a commencé à regarder comment migrer le wiki
|
||||
vers un serveur sous lenny. Ce ne sera pas tâche aisée vu que c'est le paquet
|
||||
avec le plus de modifications locales pour le Cr@ns.
|
||||
|
||||
Howto:
|
||||
|
||||
* Installer apache2, apacheSSL, pythonmodrewrite (et allumer son cerveau)
|
||||
* sync-er le /var/local/wiki
|
||||
* il y a un lv sur fx qui s'appelle lvm-wiki (2,5/4Go)
|
||||
* copier les fichiers de conf de moinmoin (/etc/moin/*) (réfléchir un peu)
|
||||
* màj les scripts dans /usr/scripts/wiki-lenny
|
||||
* comprendre comment fonctionne le parser de moinmoin (un peu comme à chaque
|
||||
|
||||
màj)
|
||||
|
||||
Moinmoin et le serveur apache sont configurés sur <http://moise-wiki.crans.org>
|
||||
le temps qu'on fasse quelques bidouilles sur les plugins munin du crans (parce
|
||||
que le serveur a apache et est sous lenny).
|
||||
|
||||
### Connexion des appartements de l'ENS
|
||||
|
||||
Il a été décidé de placer ces appartements sur le même VLAN que le BdS (car ce
|
||||
VLAN circule déjà sur les équipements actifs de l'ENS). Il faudra mettre en
|
||||
place un firewall entre ce VLAN et le réseau (car le CA a décidé de filtrer le
|
||||
trafic). Ce réseau passera par la Freebox.
|
||||
|
||||
### Problèmes latents sur le réseau
|
||||
|
||||
#### Wifi
|
||||
|
||||
Le Wifi marche de façon plus ou moins aléatoire. Il faudrait rebooter la plupart
|
||||
des bornes (cf. autostatus bien rouge). Les bornes en zone CROUS devraient être
|
||||
rebootables par un apprenti qui n'aura pas le choix. Il parait judicieux, au vu
|
||||
de certains soucis de configuration de switchs, de vérifier sur quels vlans sont
|
||||
la prise de chaque borne down et de modifier la base ldap le cas échéant.
|
||||
Certaines bornes ne semblent pas revenir après un hard reboot; le stock de
|
||||
bornes du -1I étant fortement diminué, il faudrait voir avec Régala pour l'achat
|
||||
de nouvelles bornes.
|
||||
|
||||
#### Zamok et libnss-ldap
|
||||
|
||||
On suspecte que libnss-ldap faisait trop de requêtes sur vert, dépassant le
|
||||
nombre maximal de sockets sur vert.
|
||||
Libnss-ldapd résout ces problèmes par une séparation claire entre le code de la
|
||||
bibliothèque nss et la connexion au serveur ldap. Le nombre de sockets ouvertes
|
||||
est alors maitrisé, puisque la connexion se fait via un démon (nslcd), qui en
|
||||
outre garde un cache des données lors d'une défaillance du serveur LDAP.
|
||||
|
||||
C'est pour l'instant la solution utilisée sur zamok (et quelques serveurs sous
|
||||
lenny), et pour l'instant aucun problème n'a été constaté.
|
||||
|
||||
On va certainement passer rouge à cette solution, même si maintenant la charge
|
||||
sur le serveur LDAP de vert doit avoir fortement diminué.
|
||||
|
||||
#### Bizarreries de l'authentification radius
|
||||
|
||||
Il est constaté un nombre impressionnant de machines qui passent par erreur sur
|
||||
le vlan d'accueil. Le problème ne vient apparemment pas de radius, les logs sont
|
||||
OK. Il faudrait refaire de toute façon la redondance de radius et voir, si ça ne
|
||||
résout pas le problème, à ajouter une rustine par exemple à arpwatch pour
|
||||
désactiver/réactiver la prise si l'adhérent se retrouve par erreur sur le
|
||||
vlan 7.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Mise en place et tests du Wifi en WPA2
|
||||
|
||||
Pour réaliser les tests de WPA2, Régala va utiliser le VLAN 30, libre sur le
|
||||
réseau Cr@ns et le réseau ENS. En effet, on ne peut pas passer le firewall de
|
||||
ragnarok en clair sur le vlan 3 actuellement.
|
||||
|
||||
Il faut prévenir la DSI de l'utilisation de ce VLAN.
|
||||
|
||||
#### Problèmes avec les annonces SAP
|
||||
|
||||
Ça m'a l'air de ne pas fonctionner correctement. Braice ?
|
||||
|
||||
#### Limitation de bande passante sur le FTP
|
||||
|
||||
Jérémie n'a pas regardé depuis la dernière release de VLC, le réseau de l'ENS va
|
||||
bien avec les limitations actuelles par nombre d'utilisateurs connectés.
|
||||
|
||||
#### Migration à l'UTF-8
|
||||
|
||||
Il faut le faire, en évitant de migrer les services en APF-4242.
|
||||
La migration naturelle lennyesque continue.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Horaires
|
||||
|
||||
* Date : Mercredi 22 octobre 2008
|
||||
* Début : 19h54
|
||||
* Fin : -- WikiNicolasd <<DateTime(2008-10-22T19:08:28Z)>>
|
||||
* Lieu : Salle Condorcet
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Arnaud Deblonde
|
||||
* Benoît Barbot
|
||||
* Jérémie Dimino
|
||||
* Laurent Taylor
|
||||
* Michel Blockelet
|
||||
* Nicolas Bruot
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Huber
|
||||
* Pierre Chambart
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Passage progressif des serveurs à Lenny, et à l'UTF8
|
||||
|
||||
BOFH excuse #212:
|
||||
Of course it doesn't work. We've performed a software
|
||||
upgrade. -- WikiNicolasd <<DateTime(2008-10-21T12:41:49Z)>>
|
||||
|
||||
Indice : installer les devscripts des backports, utiliser rc-alert. Dans l'état
|
||||
actuel, on pourrait mettre à jour zamok. On peut aussi tout simplement copier
|
||||
le script qui nous intéresse. Il fonctionne sous etch.
|
||||
|
||||
### Migration du wiki
|
||||
|
||||
Deux choses sont à faire :
|
||||
|
||||
* refaire la conf du Cr@ns spécifique (droits spéciaux…)
|
||||
* refaire les macros qui ne passent pas à la version (aux deux versions en
|
||||
fait). Il y en a *beaucoup*.
|
||||
|
||||
Certaines syntaxes changent (par exemple, les macros passent sous
|
||||
forme {{{<<Macro>>}}} au lieu de {{{[[Macro]]}}}). Un wiki de test est en place
|
||||
sur munin.crans.org. Pour la migration définitive, on créera un domU (quand la
|
||||
nouvelle infrastructure sera mise en place).
|
||||
|
||||
### Compte rendu de l'intervention de l'électricien pour le 0@B
|
||||
|
||||
C'est demain.
|
||||
|
||||
### Wifi en WPA2 ?
|
||||
|
||||
Le log irc arrivera dans la soirée...
|
||||
|
||||
### WebRadio (Upload, multicast, branchement de la KoKarde…)
|
||||
|
||||
L'accès serait possible par login/mot de passe (comme les news). Le problème
|
||||
est que l'audio, c'est *gros* (genre 1 Mo/minute). Il paraitrait étonnant que
|
||||
la DSI accepte ce type d'upload. Comment font-ils chez VIA ?
|
||||
|
||||
La KoKarde sera câblée sur le vlan BdS/Appartements. Michel s'en occupe.
|
||||
|
||||
### Formulaire de précâblage en ligne
|
||||
|
||||
Ne pas oublier de réfléchir lorsqu'on configure apache.
|
||||
On devrait partir sur un truc en !CherryPy, un peu comme l'intranet. Xavier se
|
||||
porte volontaire.
|
||||
|
||||
Il ajoute d'ailleurs qu'en passant, il serait une bonne idée d'ajouter la case
|
||||
à cocher pour passer une prise sur le vlan install party. Il faudrait que les
|
||||
switchs soient configurés en conséquence, et que les
|
||||
images du vlan install party soient tenues à jour plus régulièrement que "quand
|
||||
on en a besoin".
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Venus
|
||||
|
||||
La carte réseau chie dans la compote de pomme. Il faut la changer (la carte
|
||||
réseau ou la câbleuse).
|
||||
|
||||
#### Réécriture des pages d'aide
|
||||
|
||||
* ''Globalement, rassembler toutes les pages d'aide aux adhérents à un endroit,
|
||||
kikoololiser l'autostatus, proposer un système de bug-report, etc. C'est
|
||||
juste une piqûre de rappel.''
|
||||
* Bonjour Michel -- WikiNicolasd <<DateTime(2008-10-21T16:39:54Z)>>
|
||||
|
||||
Les pages actuelles reflètent un peu le Cr@ns de 2005-2006... Sila est le
|
||||
proxy, zamok fournit tous les services, la base ldap est sur zamok etc.
|
||||
|
||||
Il faut mettre à jour et réorganiser les pages des arborescences :
|
||||
|
||||
* VieCrans/
|
||||
* CransTechnique/
|
||||
* CransAdministratif/
|
||||
|
||||
#### Câblage du personnel de l'ENS
|
||||
|
||||
Rien n'a changé depuis 15 jours. Michel a été porté volontaire.
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
# Réunion Nounous
|
||||
|
||||
## Lieu et horaires
|
||||
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Date : Jeudi 20 novembre 2008
|
||||
* Début : 19h51
|
||||
* Fin : 21h23
|
||||
|
||||
## Présents
|
||||
|
||||
* Augustin Parret-Fréaud
|
||||
* Johan Grande
|
||||
* Laurent Taylor
|
||||
* Michel Blockelet
|
||||
* Nicolas Bruot
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Huber
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Avancement de la mise à jour vers lenny
|
||||
|
||||
La mise à jour vers lenny a commencé (par oie) sur les serveurs de la ferme.
|
||||
Oie ne boote pas sur le kernel officiel, selon toute évidence à cause des
|
||||
options un peu foireuses qui permettent déjà que les cartes TV fonctionnent
|
||||
|
||||
Nicolas prévoit de bientôt mettre à jour egon, afin de tester la mise à jour de
|
||||
certains services comme LDAP, Postfix, PostgreSQL...
|
||||
|
||||
### Planification du remplacement de vert et de pegase
|
||||
|
||||
De nouveaux serveurs ont été commandés (on les recevra d'ici une dizaine de
|
||||
jours).
|
||||
|
||||
Il y a ainsi :
|
||||
|
||||
* fy : un nouveau dom0 (pour délester fx)
|
||||
* un nouveau "vert"
|
||||
|
||||
Et pour aller avec :
|
||||
|
||||
* une baie de disques iSCSI, avec deux buts principaux :
|
||||
* en cas de panne de certains serveurs, permettre à d'autres de toujours
|
||||
|
||||
accéder aux données
|
||||
|
||||
* éviter de gâcher de l'espace disque
|
||||
* un nouvel onduleur
|
||||
|
||||
On cherche une solution pour économiser sur l'installation électrique pour le
|
||||
branchement de l'onduleur, la solution proposée par Anne nous semblant vraiment
|
||||
très onéreuse.
|
||||
|
||||
Liste des services et données à migrer :
|
||||
|
||||
* Sur Pegase :
|
||||
* Backups de pegase... Il faut donc réinstaller backuppc.
|
||||
* Serveur RADIUS (attention à la mise à jour, la sémantique du fichier de
|
||||
conf change)
|
||||
* LDAP (en relation avec le point précédent)
|
||||
* Sur vert :
|
||||
* Le serveur NFS...
|
||||
* La base LDAP principale...
|
||||
* BCfg2
|
||||
* Le serveur DNS (slave de toutes les zones)
|
||||
* Sur le nouveau Dom0 :
|
||||
* un DomU www
|
||||
* ...
|
||||
|
||||
### Avancement de la migration du wiki
|
||||
|
||||
Il faut faire une double migration (passage à la v1.7 de MoinMoin, de Lenny, et
|
||||
passer à un DomU), ce qui augmente un peu la charge de travail.
|
||||
|
||||
Le calendrier ne fonctionne pas, MoinMoin semble détecter correctement les pages
|
||||
à afficher mais n'arrive pas à récupérer les informations dans ces dites pages.
|
||||
|
||||
Les catégories des pages ont aussi des problèmes de fonctionnement (plus ou
|
||||
moins aléatoires).
|
||||
|
||||
Antoine suggère que la migration est une bonne occasion pour faire un peu de
|
||||
ménage sur le wiki.
|
||||
|
||||
(Pourquoi est-ce qu'il ne faut pas faire indexer le wiki par google :
|
||||
VieEns/LesDépartements/DépartementAnglaises…)
|
||||
|
||||
Le séminaire technique sur le wiki sera dans 3 semaines.
|
||||
|
||||
### Avancement de la mise en place du WiFi en WPA2
|
||||
|
||||
Il est probable que Regala soit en train de flasher une borne au 2B en ce moment
|
||||
même... Apparemment non.
|
||||
|
||||
### « Formalisation » des droits WebMaster et FtpMaster
|
||||
|
||||
Il serait bon de mettre en place une procédure "automatique" (i.e. LDAPisée)
|
||||
d'attribution de ces droits.
|
||||
|
||||
### Attribution de nouveaux droits
|
||||
|
||||
Johan est ajouté au groupe mirror sur sila, pour pouvoir gérer les dizaines
|
||||
d'isos de distributions disponibles sur le FTP.
|
||||
|
||||
Nicolas propose d'ajouter les droits Nounou à Xavier, puisqu'il a montré un an
|
||||
durant son intérêt et sa motivation. Aucune des nounous présentes (et contactées
|
||||
précédemment) n'oppose son veto.
|
||||
|
||||
### Organisation de nouveaux séminaires techniques
|
||||
|
||||
Un séminaire sur MoinMoin sera organisé par Antoine dans 3 semaines.
|
||||
|
||||
Inscrivez vos disponibilités sur la
|
||||
page SéminairesTechniques, pour que votre avis
|
||||
compte si on les déplace... Il faudra pas venir se plaindre après.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Migration de mouton vers MDR
|
||||
|
||||
En principe, Michel a migré tous les services qu'il faut. Il attend la
|
||||
vérification de Braice.
|
||||
|
||||
Très bientôt, on aura enfin le silence au 4J...
|
||||
|
||||
#### Router advertisements IPv6
|
||||
|
||||
Olivier cherche une solution pour éviter que chaque machine qui se branche sur
|
||||
le réseau récupère 5 adresses IPv6 globales. Cela résoudrait -peut-être- les
|
||||
problèmes de connexion filaire sous Vista.
|
||||
|
||||
#### Machines extérieures en .crans.org
|
||||
|
||||
Des gens ont demandé la possibilité d'avoir des machines extérieures
|
||||
en .crans.org . Il faudrait mettre en place :
|
||||
|
||||
* Soit une zone spéciale (.vieux-con.crans.org ?)
|
||||
* Soit un domaine spécial (crans.eu ?)
|
||||
|
||||
Le domaine crans.eu est commandé chez ovh.
|
||||
|
|
@ -0,0 +1,123 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 15 janvier 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h45
|
||||
* Fin : 21h00
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoîne Durand-Gasselin
|
||||
* Johan Grande
|
||||
* Nicolas Dandrimont
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
* Vincent Maioli
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Câblage des appartements de l'ENS
|
||||
|
||||
La solution technique retenue est de placer les Appartements derrière un NAT,
|
||||
sur komaz.
|
||||
|
||||
Le filtrage peer2peer sera en place sur ce nat. Pour le comptage de l'upload,
|
||||
il faut trouver une solution qui prend en compte le NAT.
|
||||
|
||||
Pour ce qui est de la charte à faire signer à ces nouveaux connectés, la
|
||||
discussion est reportée au prochain CA.
|
||||
|
||||
### Automatisation de la mise en place des sauvegardes
|
||||
|
||||
La mise en place automatique est lourde à mettre en place, alors que
|
||||
l'opération pour un serveur consiste en la copie d'un fichier sur babar. Il
|
||||
suffit donc de ne pas oublier cette étape.
|
||||
|
||||
### « ToDo list » en cas de panne
|
||||
|
||||
Il parait difficile de faire une checklist des choses à vérifier en cas de
|
||||
panne, le nombre de serveurs et de services étant faramineux.
|
||||
|
||||
Il sera mis en place une page wiki contenant différents tutoriels, par exemple
|
||||
comment redémarrer le 0B en cas de panne, etc. Il faudra veiller à ce que les
|
||||
informations contenues dans cette page soient à jour en permanence.
|
||||
|
||||
Si les membres du CA sont prêts à mettre en place une liste de choses à faire
|
||||
en cas d'absence des Nounous, les Nounous sont prêtes à les aider, mais ne
|
||||
voient pas l'intérêt de la mettre en place en l'état actuel des choses.
|
||||
|
||||
### Bilan de l'installation des nouveaux serveurs
|
||||
|
||||
#### Slon
|
||||
|
||||
La nouvelle baie de disques est installée. Les données des !DomUs sont dessus.
|
||||
Il reste à déplacer les homes. Pour servir ces derniers, des tests vont être
|
||||
effectués sur un DomU.
|
||||
|
||||
#### Fy
|
||||
|
||||
Fy est installé, il va chercher sa racine sur la baie de disques. Tous
|
||||
les !DomUs sont dessus actuellement en attendant de réinstaller Fx.
|
||||
|
||||
#### Babar
|
||||
|
||||
Il est installé et fonctionnel. Il reste à le déplacer à son emplacement
|
||||
physique définitif.
|
||||
|
||||
Petit commentaire sur l'installation : Ne mettre qu'une partition / de 2 Go sur
|
||||
un disque de 250 était surprenant, considérant que les métadonnées de backuppc
|
||||
sont stockées dans un arbre de millions de petits fichiers dans /var. Que ne
|
||||
fut ma surprise quand j'ai constaté que la racine était pleine depuis plus
|
||||
d'une semaine...
|
||||
|
||||
### Récupération du crash de fx
|
||||
|
||||
Aucun test n'a été effectué depuis le crash. Les disques durs doivent être
|
||||
vérifiés (smart test etc.), en vue d'un échange en cas de problème.
|
||||
|
||||
Le DomU irc est toujours cassé, il faut le réinstaller.
|
||||
|
||||
### Avancement des mises à jour vers lenny
|
||||
|
||||
Tous les serveurs non critiques ont été migrés sous lenny. Pour les serveurs
|
||||
principaux restant, l'ordre retenu de migration est le suivant :
|
||||
|
||||
* komaz
|
||||
* sable
|
||||
* rouge
|
||||
* zamok
|
||||
|
||||
Ce qui advient de vert sera déterminé plus tard (selon les tests du NFS sur un
|
||||
domU).
|
||||
|
||||
### Projets en cours ou futurs
|
||||
|
||||
#### BCfg2
|
||||
|
||||
Petit à petit, le mail de statistiques BCfg2 se vide...
|
||||
|
||||
#### Formulaire de préinscription en ligne
|
||||
|
||||
Xavier commence à s'y mettre.
|
||||
|
||||
#### Détection des router-advertisements
|
||||
|
||||
Olivier fait semblant de réviser, le point est reporté à la prochaine réunion.
|
||||
|
||||
#### Bugs de l'intranet
|
||||
|
||||
* L'intranet perd la "connexion à l'imprimante" et n'arrive pas à la rétablir
|
||||
* Les paiements paypal doivent être validés manuellement
|
||||
|
||||
Il faudrait que quelqu'un avec des points de karma en cherrypy y regarde de
|
||||
plus près.
|
||||
|
||||
#### munin
|
||||
|
||||
Le domU munin a un gros souci d'i/o. Le service sera transféré sur pegase
|
||||
lorsque la migration des sauvegardes sera complète.
|
||||
|
||||
#### Modifications qui trainent
|
||||
|
||||
Il est rappelé que les modifications aux différents dépôts doivent être
|
||||
commitées rapidement...
|
||||
|
|
@ -0,0 +1,217 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 29 Janvier 2009
|
||||
* Lieu : PdJ
|
||||
* Début : 20h02
|
||||
* Fin : 21h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Arnaud Deblonde
|
||||
* Johan Grande
|
||||
* Michel Blockelet
|
||||
* Olivier Huber
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Suite du câblage des nouveaux appartements de l'ENS
|
||||
|
||||
Il serait bon d'avoir une idée de l'infrastructure avant que la DSI ne nous
|
||||
donne un numéro de VLAN. Idéalement, il serait bon d'être prêts rapidement.
|
||||
Nicolas semble avoir commencé à réfléchir à la question, et maintenant qu'il
|
||||
est en stage, il a plein de temps devant lui ! pour mettre tout celà en place :)
|
||||
|
||||
Il faudrait aussi adapter la base LDAP à ces nouveaux adhérents, et modifier les
|
||||
règles de filtrage d'upload (faudra voir si la solution en place marchera ootb).
|
||||
|
||||
En tout cas, il faudra soumettre ces nouveaux adhérents aux mêmes restrictions
|
||||
que ceux passant par RENATER, la connexion utilisée étant tout de même
|
||||
mutualisée.
|
||||
|
||||
### Attribution de nouveaux droits
|
||||
|
||||
On a un apprenti, Olivier Huber, qui a fait plein de trucs. Les nounous
|
||||
présentes sont favorables à sa nomination en tant que nounou (ça sera plus
|
||||
simple pour tout le monde).
|
||||
|
||||
D'ailleurs, ça me fait penser qu'on a un serveur sous OpenBSD 4.2 à mettre à
|
||||
jour ...
|
||||
|
||||
### Achat de matériel électrique
|
||||
|
||||
Pour le problème de retour de l'électricité au 0B, on prévoit d'acheter deux
|
||||
multiprises ssh. Ce n'est pas donné mais ce n'est pas non plus si cher que ça.
|
||||
On en reparlera à la prochaine réunion CA.
|
||||
|
||||
De plus, ça peut se révéler pratique.
|
||||
|
||||
### La ferme
|
||||
|
||||
Ces derniers temps, la ferme a connu beaucoup
|
||||
d'histoires (<http://www.amazon.fr/Braice-à-la-ferme-tome4/dp/2203101016/>).
|
||||
|
||||
Tout d'abord, mouton est mort; ses services ont été migrés sur mdr (qui
|
||||
s'appelle maintenant aussi vache.ferme), et quelques modifications ont été
|
||||
apportées aux scripts pour qu'ils fonctionnent avec la nouvelle version de
|
||||
MumuDVB.
|
||||
|
||||
Par ailleurs, Braice a remis les serveurs dans un état "stable", comme il nous
|
||||
l'explique :
|
||||
|
||||
"Avant, on utilisait des noyaux persos et un udev 054 compile statiquement avec
|
||||
la klibc. Le noyau actuel de etch ne supporte pas toutes les cartes, mais le
|
||||
2.6.24-etchnhalf si.
|
||||
|
||||
Il y a eu plusieurs problemes lors de la mise à jour :
|
||||
|
||||
* la migration de udev
|
||||
* le slash fait 180Mo
|
||||
|
||||
Ces deux problèmes sont désormais résolus sur les trois serveurs.
|
||||
|
||||
Ce qu'il reste a faire :
|
||||
|
||||
* Passer a lenny.
|
||||
* Utiliser un paquet debian pour mumudvb.
|
||||
* Utiliser les scripts d'init de mumu et monit au lieu de cron pour le
|
||||
surveiller.
|
||||
* Faire du ménage/tri dans les chaines sat.
|
||||
* Acheter une carte TNT pour les chaines HD.
|
||||
* Acheter des multiswitch :
|
||||
|
||||
<http://www.2galli.fr/boutique/fiche_produit.cfm?type=33&ref=P122ASAT&code_lg=lg_fr&pag=1&num=161>
|
||||
|
||||
### Wifi
|
||||
|
||||
#### WPA
|
||||
|
||||
Regala n'a pas le temps de s'occuper de déploiement de sa solution Wifi alors
|
||||
qu'elle fonctionne. Il cherche quelqu'un ayant le temps de s'en occuper. La
|
||||
plupart des informations nécessaires se trouvent sur le wiki :
|
||||
|
||||
<http://wiki.crans.org/WifiTechnique/WpaEnterprise>
|
||||
|
||||
Pour faciliter la migration chez les adhérents, il serait préférable de garder
|
||||
les deux systèmes (IPSec et WPA) en parallèle, au moins au début. Regala dit
|
||||
que les machines sur le réseau IPSec et le réseau WPA ne peuvent pas partager la
|
||||
même plage d'IPs, il faudra donc se pencher sur le problème.
|
||||
|
||||
Les choses à faire sont donc :
|
||||
|
||||
* Tester le système développé par Regala sur deux bornes
|
||||
* Documenter la chose pour les adhérents
|
||||
* Commencer le déploiement de bornes avec le WPA, sur un réseau Wifi séparé
|
||||
Cr@ns-WPA
|
||||
|
||||
Et on aura enfin la paix avec les Vista-users !
|
||||
|
||||
* Tu paries ?
|
||||
|
||||
#### Gestion des bornes
|
||||
|
||||
Xavier, a eu l'occasion d'effectuer quelques tests avec les bornes. Quand le
|
||||
userspace des bornes plante, elles continuent à pinger (donc ne sont pas
|
||||
détectées down par l'autostatus) mais ne fournissent plus de wifi.
|
||||
|
||||
Xavier va donc travailler sur un système de heart-beat pour améliorer la
|
||||
détection du plantage. Ainsi qu'un système de reboot matériel par le réseau.
|
||||
|
||||
Sinon, Michel et Xavier proposent que l'on monte les bornes dans des robots
|
||||
autonomes qui reviendraient au 2B pour qu'on leur fassent un câlin dès qu'elles
|
||||
sont plantées. Le problème, c'est qu'il y aura toujours une quinzaine de robots
|
||||
dès qu'on va au 2B. Et qu'ils risquent de se perdre dans les couloirs de l'ENS
|
||||
ou
|
||||
à la Kokarde...
|
||||
|
||||
### Asterisk/Mise en place de la téléphonie IP
|
||||
|
||||
Le projet traîne depuis un moment, et il commence à devenir un peu plus "urgent"
|
||||
de s'en occuper.
|
||||
|
||||
Ce qu'il faudrait faire :
|
||||
|
||||
* Mettre en place un serveur Asterisk bien sécurisé
|
||||
* A tester en interne d'abord
|
||||
* Mettre en place une interface utilisateur ergonomique (à peu près comme
|
||||
l'intranet ?!)
|
||||
* Trouver un fournisseur extérieur qui nous permette d'appeler *tous* les
|
||||
numéros du monde
|
||||
* Bien compter les communications de chacun (en particulier, débiter
|
||||
au *bon* tarif de la communication), et couper les communications quand la
|
||||
personne n'a plus d'argent sur son compte
|
||||
* Compte pré-payé (le même que pour l'impression ?)
|
||||
* Facture post-utilisation (dangereux)
|
||||
* Abonnement tous les mois (dangereux)
|
||||
* Trouver du hardware, qu'on pourrait vendre aux adhérents
|
||||
|
||||
A noter que Regala bosse dans ce domaine, il s'y connaît très bien; il sera donc
|
||||
de très bon conseil.
|
||||
|
||||
### Projets en cours ou futurs
|
||||
|
||||
#### Formulaire de préinscription en ligne
|
||||
|
||||
Xavier y travaille.
|
||||
|
||||
#### Détection des router-advertisements
|
||||
|
||||
Olivier a écrit un programme en C, qu'il faut encore un peu compléter. Il
|
||||
faudra aussi écrire un script en Python pour l'interfacer avec
|
||||
le reste du système du Cr@ns.
|
||||
|
||||
#### Réflexions sur l'IPv6
|
||||
|
||||
Problèmes:
|
||||
|
||||
* l'ENS ne nous fournit pas une connexion IPv6
|
||||
* nos switchs ne sont pas IPv6-aware (en tout cas pour le multicast)
|
||||
* nos serveurs ne sont pas IPv6-aware (le module IPv6 de etch est tout pourri)
|
||||
* Qui maîtrise IPv6
|
||||
|
||||
Il faudra quand même commencer à y réfléchir et à se renseigner dessus.
|
||||
|
||||
#### Bugs de l'intranet
|
||||
|
||||
L'intranet est buggé. Antoine va essayer de voir ce qu'il arrive à comprendre.
|
||||
Xavier émet l'hypothèse de recoder l'intranet.
|
||||
|
||||
#### L'imprimante et les marges des pdfs
|
||||
|
||||
On peut rajouter des features dans l'interface de l'intranet pour l'impression.
|
||||
Xavier et Nicolas ont l'air motivés.
|
||||
|
||||
#### Mise en place du service de boot PXE
|
||||
|
||||
* Documentation
|
||||
* Interface pour les adhérents, pour se mettre sur le VLAN 10
|
||||
* Filtrage de ce qui passe sur le VLAN 10, afin que les adhérents n'utilisent
|
||||
pas le VLAN pour faire des trucs mal
|
||||
* Mettre des rescue-cd ?
|
||||
|
||||
#### Réorganisation des services Pegase/Munin
|
||||
|
||||
* Il y a encore un serveur radius sur pegase. Il faut le réinstaller sur une
|
||||
autre machine, avant de réinstaller munin dessus. On va créer un serveur
|
||||
radius qu'on va mettre au 0B. On pensait plutôt à un domU. Dès que le serveur
|
||||
radius est installé, on fait des test, et ensuite on peut s'amuser avec
|
||||
pegase (qui ne sera pas renommé).
|
||||
* munin chie complètement ses I/O, on va l'installer sur une vraie machine:
|
||||
pegase.
|
||||
* Si y a des gens qui ont des idées pour la génération du fichier de conf de
|
||||
munin, ils priveront Nicolas du plaisir de peupler à la main les nodes.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### fx
|
||||
|
||||
* On va essayer de faire booter fx sur le reseau comme fy. Faudra trouver un
|
||||
soir
|
||||
|
||||
où on n'a rien à faire, et plein de bouteilles de coca
|
||||
|
||||
* Après, on s'amusera peut-être à faire du load-balancing.
|
||||
----
|
||||
|
||||
CatégorieCrans
|
||||
|
|
@ -0,0 +1,249 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 5 mars 2009
|
||||
* Lieu : PdJ
|
||||
* Début : 20h02
|
||||
* Fin : ????
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Arnaud Deblonde
|
||||
* Augustin Parret-Fréaud
|
||||
* Nicolas Bruot
|
||||
* Olivier Huber
|
||||
* Pierre Chambart
|
||||
* Roman Yurchak
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
Via Gobby :
|
||||
|
||||
* Brice Dubost
|
||||
* Mathieu Segaud
|
||||
* Michel Blockelet
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Bilan du câblage des appartements de l'ENS
|
||||
|
||||
Tout passe par Titanic et semble marcher.
|
||||
Le Squid a été configuré. Les règles de base du firewall sont appliquées.
|
||||
|
||||
Reste à faire :
|
||||
|
||||
* Du nettoyage dans annuaires.py
|
||||
* Ouvrir plus de ports et filtrer d'autres (p2p, toussa)
|
||||
* Firewall généré par firewall.py
|
||||
* Envoyer un mail pour organiser une réunion avec les personnels
|
||||
* S'occuper *vite* des logs de squid
|
||||
* Créer une page wiki expliquant comment ça marche
|
||||
|
||||
### Migration vers Lenny
|
||||
|
||||
#### Migration des services
|
||||
|
||||
Il faudrait faire une page wiki permettant de recenser les différents services
|
||||
qui doivent être migrés avant le passage à lenny. Si un apprenti veut par
|
||||
exemple configurer un domU imap, horde et migrer la configuration sous bcfg2.
|
||||
|
||||
Services critiques :
|
||||
|
||||
* freeradius
|
||||
* postfix
|
||||
* dns
|
||||
* horde
|
||||
* dovecot
|
||||
* ipp2p (pas dans les dépôts Debian mais ça se corrige, si quelqu'un a envie
|
||||
|
||||
de regarder dans les arcanes de kernel-package, surtout kpatch)
|
||||
|
||||
Voir `/usr/share/doc/<nom-du-paquet>/NEWS{,.Debian}` (sur une machine sous Lenny)
|
||||
pour des infos sur la migration.
|
||||
|
||||
Lire aussi les release-notes.
|
||||
Bien penser à mettre à jour le wiki.
|
||||
|
||||
#### Passage en UTF-8
|
||||
|
||||
Il serait de bon ton de profiter du passage à lenny pour migrer vers l'UTF-8.
|
||||
Les scripts de configuration ne devraient pas poser de problèmes, par contre
|
||||
les scripts de gestion possèdent des parties spécifiques à l'ISO (et donc
|
||||
affichent de l'ISO même en UTF-8).
|
||||
|
||||
Il pourrait y avoir des problèmes avec les noms de fichiers (dans les homes des
|
||||
adhérents).
|
||||
|
||||
#### Migration des homes sur la baie SAS
|
||||
|
||||
Maintenant qu'on sait bien utiliser la baie SAS, et qu'elle fonctionne bien,
|
||||
il faut décider d'un système de fichiers, a priori de l'ext3.
|
||||
|
||||
Pour l'ext4 on pourra migrer plus tard. (a priori pas de souci avec tune2fs,
|
||||
le futur e4defrag s'occupera sans doute de convertir en extents ce qu'il bouge
|
||||
mais suivant la taille effective des données sur le disque à migrer, il faudra
|
||||
se poser la question de dumper ou simplement upgrader le système de fichiers)
|
||||
|
||||
On pourra alors augmenter les quotas. Il faudrait décider de la taille accordée
|
||||
à la partition pour les homes et de la nouvelle taille des quotas.
|
||||
|
||||
Il faudrait aussi régler le problème de limite soft/hard avec postfix
|
||||
et dovecot.
|
||||
|
||||
#### Migration des services de rouge
|
||||
|
||||
On pourrait créer un domU pour chaque service de rouge (avec intégration dans
|
||||
bcfg2).
|
||||
|
||||
À terme, l'idée serait d'acheter n domO comme fx et fy.
|
||||
|
||||
On peut garder les serveurs actuels comme serveurs de secours (ou load
|
||||
balancing, cela permet de tester le secours en permanence).
|
||||
|
||||
* Benjamin se porte volontaire pour faire un domU avec dovecot et postfix à
|
||||
jour sous lenny.
|
||||
* Nicolas se porte volontaire pour faire un domU horde - roundcube.
|
||||
|
||||
### Asterisk
|
||||
|
||||
On peut mettre en place quelque chose rapidement, il suffit d'installer le
|
||||
paquet Debian. Et puis après on pourra commencer à faire des trucs plus fun
|
||||
avec LDAP (même si c'est configuré en 30 minutes). Il faudra ensuite déployer
|
||||
des faisceaux vers et depuis le réseau téléphonique commuté, mais avant cela
|
||||
il faudra écrire une gestion complète des temps de com.
|
||||
|
||||
Xavier et Roman se portent volontaires.
|
||||
|
||||
### WPA2
|
||||
|
||||
#### Ragnarok en 4.4
|
||||
|
||||
Olivier et WikiRegala s'en chargent après-demain.
|
||||
|
||||
#### Tests sur les bornes
|
||||
|
||||
Il faut que quelqu'un lise la doc du wiki et fasse des tests sur des bornes.
|
||||
Je commence à m'en occuper samedi midi. Des firmwares du SVN d'il y a 3 jours
|
||||
sont prêts (un avec un 2.6 et un avec un 2.4, le 2.4 étant le choix premier)
|
||||
|
||||
PAF s'en charge, s'il a des questions, WikiRegala pourra y répondre.
|
||||
|
||||
#### Haute disponibilité des bornes (avec un MONTE)
|
||||
|
||||
<http://en.wikipedia.org/wiki/The_Killer_Robot_Instability>
|
||||
|
||||
Le module est en cours de conception. Ca devrait être cool.
|
||||
|
||||
### Cameras
|
||||
|
||||
Malgré ce que Michel a touché, ça n'a manifestement pas amélioré le comportement
|
||||
de la caméra du 0B.
|
||||
|
||||
Maintenant que le CROUS compte utiliser sa clé du 0B, il faudrait qu'elle
|
||||
envoie
|
||||
des photos par mail.
|
||||
On pourrait échanger celle du 0B et celle du 2B. Ou tenter de réinstaller le
|
||||
système de la caméra du 0B.
|
||||
|
||||
Il faudra penser à réorienter la caméra dans une position où on voit vraiment
|
||||
quelque chose d'intéressant ...
|
||||
|
||||
### Intranet
|
||||
|
||||
On recherche un mainteneur pour l'intranet. Il y a des bugs à corriger et des
|
||||
fonctionnalités à ajouter.
|
||||
Soyons d'accord, on n'impose pas un quelconque langage pour les développements
|
||||
Web sophistiqués (à savoir avec gestion de session). On bannit néanmoins l'asp
|
||||
et le php.
|
||||
|
||||
On peut continuer sur la lancée actuelle de l'intranet, et tout faire en Python.
|
||||
Ca évite aux gens d'apprendre 50 langages différents pour maintenir les scripts
|
||||
au Cr@ns ... De plus ça permet l'intégration facile avec les autres scripts et
|
||||
librairies (ldap_crans.py ?). Ça serait dommage de jeter l'existant après tout
|
||||
ce qui a été fait. Par contre cela n'interdit pas de le nettoyer.
|
||||
|
||||
### Remettre fx en production
|
||||
|
||||
Il faut le faire booter sur Slon (la baie de disques).
|
||||
|
||||
La question ne se pose pas sur l'usage de xen, mais bien sur le fait qu'il
|
||||
faille configurer le BIOS de fx pour que celui-ci puisse booter depuis l'iSCSI
|
||||
(Jérémie s'en occupe)
|
||||
|
||||
Mathieu suggère d'essayer de préparer une possible nécessaire migration d'ici
|
||||
squeeze sachant que Red Hat bosse sur des solutions de gestion de plateforme de
|
||||
virt commune à toutes les solutions (vserver, openvz, xen et kvm) pour faciliter
|
||||
des migrations (Certaines versions de Fedora utilisaient Xen comme solution, la
|
||||
future Fedora 11 utilisera KVM). Le sujet est en pleine explosion, avec
|
||||
différents leaders de l'écosystème !OpenSource essayant d'imposer telle ou telle
|
||||
solution, telle ou telle interface de gestion... D'ailleurs, il pourrait être
|
||||
intéressant de préparer une telle interface, un tableau de bord pour gérer les
|
||||
domU à partir de l'intranet (gérer des droits nounous sur l'intranet ne devrait
|
||||
pas poser de problème, on peut même utiliser gpg)
|
||||
|
||||
### Munin
|
||||
|
||||
Munin est un domU, il souffre énormément (cf. graphes Munin). Il faudrait le
|
||||
mettre
|
||||
sur une machine dédiée.
|
||||
Pégase a l'air tout indiqué, il faudra quand même qu'on migre radius avant.
|
||||
|
||||
#### Génération de la conf de munin
|
||||
|
||||
Il faut automatiser la génération de la conf munin et de l'installation des
|
||||
plugins (et de la gestion correcte des encodages). (si migration vers UTF8 il
|
||||
y a, pas de "gestion incorrecte" des encodages :))
|
||||
|
||||
Il faudra rajouter dans bcfg2 la gestion de la conf pour les munin-node, et un
|
||||
script maison qui parsera les fichiers de conf de bcfg2.
|
||||
|
||||
### Webalizing
|
||||
|
||||
Ça fait depuis longtemps que ce qu'il y a sur rouge ne marche plus, mais on
|
||||
s'en soucie guère.
|
||||
|
||||
A noter qu'à l'époque où webalizer était utilisé, il avait tendance à occuper
|
||||
|
||||
*énormément* de ressources, et que certaines fois, il plantait et utilisait
|
||||
tout
|
||||
|
||||
le CPU pendant plusieurs heures ...
|
||||
|
||||
### Pré-Inscription
|
||||
|
||||
Il semblerait que le nouveau BDE ait accepté de mettre un module réseau sur
|
||||
le photocopieur de la Kfet (Geneviève en a discuté avec eux).
|
||||
|
||||
Il faut développer une application web d'inscription en ligne.
|
||||
Xavier s'est déjà porté volontaire pour regarder.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Backup physique
|
||||
|
||||
On compte mettre en place une copie des backups qui ne soit accessible
|
||||
qu'en lecture seule.
|
||||
|
||||
* Les bandes magnétiques sont la meilleure solution
|
||||
* il faut une idée de prix et de matériel, et que ça ne soit pas trop cher
|
||||
* On peut compter un système assez bien à environ 2000EUR (j'ai cru voir).
|
||||
|
||||
#### Egon
|
||||
|
||||
Il faut changer et réinstaller egon car son comportement est de plus en plus
|
||||
erratique.
|
||||
Proposition d'achat d'une nouvelle machine pour un budget de 1300EUR
|
||||
Proposition d'achat d'un écran 30" HP au prochain CA
|
||||
|
||||
#### Alimentation du 0B
|
||||
|
||||
Il y a actuellement un problème d'alimentation au 0B, lors de la mise
|
||||
sous tension, les alimentations des serveurs consomment un pic de
|
||||
courant qui fait disjoncter l'onduleur.
|
||||
|
||||
Deux solutions différentes sont proposés, une par Valérian basé sur des
|
||||
relais retardés et une seconde sur une multiprise ssh. La multiprise ssh
|
||||
présente l'avantage de permettre de manager à distance l'alimentation
|
||||
des serveurs.
|
||||
|
||||
On contactera toutefois Anne Cazalet avant d'effectuer un tel achat.
|
||||
|
|
@ -0,0 +1,183 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Lundi 6 avril 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : 21h57
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Benoît Barbot
|
||||
* Jérémie Dimino
|
||||
* Olivier Huber
|
||||
* Stéphane Glondu
|
||||
* Stéphane Murday
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Migration sous Lenny
|
||||
|
||||
Il reste sable, zamok, rouge et vert.
|
||||
|
||||
Sable : adg s'occupe de squid.
|
||||
Adg veut tester squid 3 sur egon (pour la mise en cache des vidéos).
|
||||
|
||||
On migre dans un premier temps vert sous Lenny, puis les homes vers slon, et
|
||||
enfin zamok vers Lenny.
|
||||
|
||||
### Rouge
|
||||
|
||||
On ne migrera pas rouge en tant que tel, on va séparer les différents services.
|
||||
Olivier a configuré rouge (avec un sysctl) pour qu'il reboote en cas de kernel
|
||||
panic.
|
||||
Il faut que quelqu'un migre les services mails sur un domU et les webmails sur
|
||||
owl.
|
||||
|
||||
### Toilettage de la configuration des switchs et mise à jour des firmwares
|
||||
|
||||
#### Vlan pour les switchs afin d'éviter de répandre le Vlan adm
|
||||
|
||||
Olivier va s'occuper de mettre en place un Vlan switchs afin d'éviter que le
|
||||
vlan adm
|
||||
soit partout. A terme, il ne se trouvera que sur les chemins entre le 2B, la
|
||||
ferme,
|
||||
le 0H et le 0B.
|
||||
|
||||
#### "Tagguage" des Vlan plus facile
|
||||
|
||||
SIGKOOL. Le principe est de rentrer la topologie du réseau dans le script de
|
||||
génération
|
||||
des switchs pour pouvoir tagguer entièrement les vlans jusqu'à une prise grâce
|
||||
à une
|
||||
seule commande.
|
||||
|
||||
#### Vlan isolement
|
||||
|
||||
Il faut juste mettre à jour la configuration des switchs et le tagguer sur tous
|
||||
les uplinks.
|
||||
|
||||
### Parler de l'architecture réseau
|
||||
|
||||
#### Intégration du nouveau point d'accès
|
||||
|
||||
On mettrait un serveur au G.
|
||||
|
||||
#### Bâtiment G
|
||||
|
||||
On a un local de brassage au 2e et 4e étage. Le CROUS pense mettre des gens
|
||||
début mai.
|
||||
|
||||
Et un local principal au sous-sol qui distribuerait la fibre vers les autres
|
||||
locaux
|
||||
par des liens !GigaBits.
|
||||
|
||||
On prendra des 2650.
|
||||
|
||||
#### Redondance
|
||||
|
||||
Il faudrait tirer une fibre entre le G et le J, il faut se renseigner pour en
|
||||
tirer une
|
||||
entre le H et C et il faut réparer la fibre défectueuse entre le I et le H.
|
||||
|
||||
### PostGreSQL
|
||||
|
||||
L'idée de départ était que ovh.crans.org continue à faire du greylisting
|
||||
lorsque le 0B
|
||||
est down. Une solution est que chaque serveur de mail ait sa propre base PgSQL,
|
||||
ces
|
||||
bases étant synchronisées entre elles.
|
||||
|
||||
[Bucardo](http://bucardo.org/) est un système de réplication
|
||||
multi-master (i.e. qui
|
||||
synchronise dans les deux sens entre plusieurs serveurs, contrairement à la
|
||||
plupart
|
||||
des softs qui ne synchronisent souvent que 1 master -> n slaves). Il gère très
|
||||
bien les
|
||||
conflits (de toute façon, ce n'est pas quelque chose de critique pour
|
||||
l'utilisation que
|
||||
l'on veut en faire).
|
||||
|
||||
Le problème est que Bucardo nécessite PgSQL ≥ 8.1, et que la base de rouge est
|
||||
en 7.4.
|
||||
Michel semble avoir trouver un moyen de dumper les bases et de migrer
|
||||
de 7.4 à 8.3.
|
||||
Il va créer un DomU PgSQL et y migrer toutes les bases (mail, filtrage, ...)
|
||||
|
||||
### Asterisk
|
||||
|
||||
La VoIP SIP fonctionne en interne. Une ligne SIP chez OVH a été souscrite.
|
||||
L'interfaçage est en cours.
|
||||
|
||||
Les adhérents seront contactés depuis l'extérieur par un numéro débouchant sur
|
||||
un
|
||||
standard. Un adhérent sera alors identifié par son aid.
|
||||
|
||||
En interne, il pourra être joint par son adresse mail canonique au Cr@ns ou par
|
||||
son aid. (On peut considérer le blocage sur demande du contact par adresse
|
||||
mail).
|
||||
|
||||
On peut mettre en place un système de conférence ainsi que des messageries
|
||||
vocales.
|
||||
|
||||
Il peut-être envisagé une période de test en charge pour les appels vers
|
||||
l'extérieur
|
||||
et l'intérieur. On pourrait alors ouvrir gratuitement les lignes téléphoniques
|
||||
pour
|
||||
tout le monde. Le CA doit décider s'il veut investir une somme pour cela.
|
||||
|
||||
Xavier se charge de regarder pour des téléphones physiques.
|
||||
|
||||
### Système de reboot des bornes wifi
|
||||
|
||||
Le PCB est terminé et sera commandé cette semaine, les composants ont déjà été
|
||||
commandés.
|
||||
|
||||
Les modules de test devraient être arrivés dans environ deux semaines.
|
||||
|
||||
### Connexion des personnels de l'ENS
|
||||
|
||||
Adg a commencé à écrire de la documentation technique sur le wiki. On leur
|
||||
donnera des
|
||||
informations sur l'intranet + accès à l'intranet de zamok.
|
||||
|
||||
Il faut aussi faire de la correspondance MAC-IP sur titanic et le firewall en
|
||||
général
|
||||
(stats sur le trafic, ...).
|
||||
|
||||
### Repo Darcs "béni" au crans
|
||||
|
||||
On se fixe comme discipline de ne pas laisser des choses non commitées dans les
|
||||
repos.
|
||||
Adg doit réparer *proprement* le repo scripts.
|
||||
|
||||
### Divers
|
||||
|
||||
#### Imprimante
|
||||
|
||||
Il faut trouver une méthode pour la débourrer en douceur. Par exemple, il faut
|
||||
installer
|
||||
une porte pour pouvoir sortir le bloc de finition.
|
||||
|
||||
#### Connexion en Gigabit à l'ENS
|
||||
|
||||
Il faut acheter une carte 10 GB fibre pour komaz. Il faut voir avec la DSI pour
|
||||
qu'ils
|
||||
nous branchent directement en fibre. Il faut garder le lien avec le transceiver.
|
||||
|
||||
#### Système de Ticketting/destruction d'O₂
|
||||
|
||||
Celui qui crée un truc qui plaît sur O₂ a gagné.
|
||||
|
||||
#### Partition nfs de softs & libs
|
||||
|
||||
On oublie.
|
||||
|
||||
#### Protéger le nfs à l'aide d'un VPN
|
||||
|
||||
Adg étudie la faisabilité.
|
||||
|
||||
#### Dépôts git du cr@ns
|
||||
|
||||
À voir plus tard.
|
||||
|
|
@ -0,0 +1,109 @@
|
|||
# Réunion
|
||||
|
||||
* Date : 04 Mai 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h55
|
||||
* Fin : <<DateTime(2009-05-04T20:26:02+0100)>>
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Damien Aza-Vallina
|
||||
* Jérémie Dimino
|
||||
* Mathieu Segaud
|
||||
* Olivier Huber
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
### Bilan sur les dernières migrations et les changement au niveau des
|
||||
|
||||
serveurs
|
||||
|
||||
Rouge est presque mort, il fait encore DHCP et TFTP pour le boot PXE.
|
||||
|
||||
Mais que va-t-il devenir ? pom pom pompommm
|
||||
|
||||
Il est trop tard pour rallonger sa garantie, par contre, c'est encore possible
|
||||
pour
|
||||
les serveurs les plus récents. Celà pourrait être intéressant de le faire, il
|
||||
faudrait
|
||||
chiffrer les extensions de garanties et proposer cela au CA.
|
||||
Il faut donc relever le SN/PN et le modèle des différents serveurs et les
|
||||
transmettre
|
||||
à Stéphane.
|
||||
|
||||
Il faut faire la mise à jour d'OpenBSD. Régala se propose si aucun apprenti
|
||||
n'est harponné
|
||||
pour le faire.
|
||||
|
||||
### l'IMAP est-il lent sur owl?
|
||||
|
||||
owl présente des problèmes d'IOs. Certaines personnes considèrent que cela le
|
||||
ralentit.
|
||||
|
||||
On pourrait tester openvz, avec owl... pour voir...
|
||||
|
||||
### Système de reboot des bornes
|
||||
|
||||
PCB reçu, prototype assemblé. Il fonctionne.
|
||||
|
||||
Un prototype en CMS va être conçu puis testé.
|
||||
|
||||
### Système de ticketing
|
||||
|
||||
"C'est plutôt cool" dixit Stéphane.
|
||||
"On s'en sert pas" dixit Antoine.
|
||||
"C'est pas incompatible, ça s'applique à moi" dixit Stéphane.
|
||||
"Il consomme beaucoup de RAM" dixit Stéphane
|
||||
|
||||
/me compte les points.
|
||||
|
||||
adg doit cliquer, il est pas content...
|
||||
|
||||
Conclusion : il faut s'en servir davantage.
|
||||
|
||||
### Protection du NFS à l'aide d'un VPN
|
||||
|
||||
Il faudrait tester NFSv4 ou mettre OpenVPN...
|
||||
|
||||
Il y a des points plus urgents à développer.
|
||||
|
||||
### Bilan sur la nouvelle base Pg
|
||||
|
||||
On reçoit des mails...
|
||||
Il faudrait installer munin dessus...
|
||||
|
||||
### Achat de matériel
|
||||
|
||||
* 16Go de ram pour chaque dom-0: +8Go pour fy +12Go pour fx
|
||||
* Il semble y avoir deux slots de libre sur fy
|
||||
* Prix des alimentations pour Fx.
|
||||
* Achat d'une carte d'une carte Gigabits pour Sila.
|
||||
|
||||
### Achat multiprise ssh
|
||||
|
||||
* Stéphane demande un devis à Anne pour les PDU.
|
||||
* Olivier se charge d'appeler la mge (Jeudi 7 Mai)
|
||||
|
||||
### Achats pour les chaînes TNT HD
|
||||
|
||||
* Olivier a trouvé un ampli à 8 sorties (référence AVN1716F KUBLER).
|
||||
|
||||
Il doit se charger de le commander rapidement.
|
||||
|
||||
### Déploiement du wifi en WPA2
|
||||
|
||||
Migration le week-end du 6-7 juin.
|
||||
|
||||
### Mise en place de l'inscription en ligne
|
||||
|
||||
Adg et Chicco ont commencé à regarder.
|
||||
|
||||
### Authentification LDAP sur le wiki
|
||||
|
||||
* Ça marche sur Vo
|
||||
|
||||
### Bugs de MoinMoin
|
||||
|
||||
"C'est pas des bugs, c'est des features"™
|
||||
Il y a des problèmes de caching.
|
||||
|
|
@ -0,0 +1,272 @@
|
|||
# Réunion
|
||||
|
||||
* Date : Lundi 25 mai 2009
|
||||
* Lieu : 2@B, clim powa®
|
||||
* Début : 20h00
|
||||
* Fin : 22h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Damien Aza-Vallina
|
||||
* Jérémie Dimino
|
||||
* Pierre Chambart
|
||||
* Xavier Lagorce
|
||||
|
||||
Par Gobby :
|
||||
|
||||
* Brice Dubost
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Imprimante canon
|
||||
|
||||
Adg a installé les drivers proprios (UFR) téléchargés sur le site du
|
||||
constructeur,
|
||||
mais c'est moche car il faut passer par une conversion PS. On passe par un
|
||||
binary pour convertir en postscript, ce qui fait que l'on a aucune idée de
|
||||
pourquoi ça ne marche pas. En plus certains pdf ne sont pas interprétables.
|
||||
|
||||
Actuellement la facturation se fait au nombre de pages, comme il avait été
|
||||
décidé en CA. Ce qui fait que tu enrichis le CRANS lorsque tu imprimes du
|
||||
monochrome en couleur. En effet, l'imprimante peut détecter une page n&b dans
|
||||
un doc couleur
|
||||
(voir CR des réunions CA au sujet de l'imprimante).
|
||||
|
||||
Si quelqu'un veut s'embêter à vérifier la colorisation de toutes les pages,
|
||||
il peut. Ne serait-il pas possible de le demander à l'imprimante ? En parsant
|
||||
l'interface web...
|
||||
|
||||
La mise en place du nouveau système de facturation a nécessité un retouche
|
||||
de l'intranet et des différents scripts d'impression. Antoine a profité
|
||||
pour faire le ménage parmi les scripts.
|
||||
|
||||
#### Wrapper de l'interface web en ocaml
|
||||
|
||||
Antoine a développé une petite application en OCaml, qui permet de soumettre
|
||||
le pdf à l'interface web et de sélectionner les options. Ce script fonctionne
|
||||
mais n'est pas encore tout à fait au point.
|
||||
|
||||
Xavier fait remarquer qu'il est dangereux de coder des scripts en OCaml. En
|
||||
effet le python a l'avantage d'être beaucoup plus simple et lisible (et ça
|
||||
fait moins peur aux nouveaux).
|
||||
De plus, ce problème a déjà été discuté en inter-nounou et l'assemblée avait
|
||||
tranché contre l'utilisation généralisée d'OCaml.
|
||||
|
||||
Pierre fait remarquer qu'en perl ça peut être pire.
|
||||
|
||||
Damien fait remarquer que dans environ 2 ans, l'imprimante sera changée.
|
||||
|
||||
#### Statistiques
|
||||
|
||||
Il serait bon d'envoyer des mails pour les consommables.
|
||||
|
||||
#### Utiliser le driver PCL
|
||||
|
||||
Antoine fait remarquer qu'on peut aussi investiguer sur l'éventuelle utilisation
|
||||
du driver pcl pour l'imprimante.
|
||||
|
||||
### État de migration des serv{eur,ice}s
|
||||
|
||||
Penser à installer le switch gigabit pour la baie iSCSI.
|
||||
|
||||
#### Vert
|
||||
|
||||
* /home se remplit (209/225GB) Une des raisons est le stockage des logs de
|
||||
squid sur cette partition (14GB)
|
||||
* Damien fait remarquer que cela risque d'être très problématique à la
|
||||
rentrée.
|
||||
* Si la croissance continue à ce rythme, /home sera plein à la mi-juillet.
|
||||
Il faut rapidement migrer /home sur la baie de disques iSCSI.
|
||||
* Migration de LDAP ou mise à jour ?
|
||||
* L'avis de Nicolas est que vert est un serveur obsolète, et que le mettre à
|
||||
jour à lenny n'avancera à rien. De plus, étant serveur LDAP principal et
|
||||
serveur NFS, un downtime serait très problématique pour l'ensemble des
|
||||
services.
|
||||
* Antoine propose d'effectuer la migration (de quoi ?) le samedi 14 à partir
|
||||
de minuit.
|
||||
* Laisser les homes en RO ? (soft bounce)
|
||||
* Configurer newldap en serveur LDAP primaire
|
||||
* Créer un domU home si les problèmes d'I/O sont réglés d'ici là (KVM semble
|
||||
prometteur), sinon, continuer à utiliser vert. (en attendant un serveur
|
||||
physique ?)
|
||||
|
||||
#### rouge
|
||||
|
||||
* SMTP principal
|
||||
* Il faut déplacer/dupliquer amavis/clamav sur redisdead avant de bouger
|
||||
mailman définitivement. Faire fonctionner l'authentification en envoi sur
|
||||
redisdead.
|
||||
* Mailman : Les fichiers de configuration de mailman ont été rsyncés sur
|
||||
redisdead, il faut:
|
||||
* Diminuer le TTL des DNS
|
||||
* Attendre (24h) (pendant ce temps, vérifier que mailman fonctionne sur
|
||||
redisdead)
|
||||
* Mettre une redirection sur rouge du trafic de lists.crans.org vers
|
||||
redisdead
|
||||
* Changer les alias lists.crans.org, smtp.crans.org, mailman.crans.org
|
||||
* Prévenir les adhérents qu'il faut utiliser smtp.crans.org pour envoyer des
|
||||
mails
|
||||
* Attendre que rouge ne reçoive plus de mails vers lists.crans.org
|
||||
* Faire tomber la guillotine
|
||||
* Ré-augmenter le TTL des DNS
|
||||
* ntp
|
||||
* dhcp
|
||||
|
||||
Nicolas est de toute évidence la personne le plus au courant de ce qu'il faut
|
||||
faire.
|
||||
|
||||
#### zamok
|
||||
|
||||
* etch -> lenny
|
||||
* Quelqu'un voit quelque chose qui casserait sur zamok lors d'une
|
||||
màj ? -> L'intranet ?
|
||||
* iso -> utf-8
|
||||
* Faire gaffe aux *noms* des fichiers dans les homes dans les adhérents
|
||||
* Résoudre les problèmes avec les scripts
|
||||
|
||||
#### Ragnarok
|
||||
|
||||
* Trial of the BSD Knights -> Games
|
||||
* Il faut inciter un apprenti à effectuer la migration.
|
||||
|
||||
#### Virtualisation
|
||||
|
||||
Munin a été migré sur fx dans kvm.
|
||||
|
||||
Quelques statistiques :
|
||||
|
||||
* <http://munin.crans.org/crans.org/munin.crans.org-munin_update.html>
|
||||
->munin-update prend plus de temps
|
||||
* <http://munin.crans.org/crans.org/munin.crans.org.html#System> -> pas
|
||||
d'I/O wait ...
|
||||
|
||||
Munin est un bon exemple pour pouvoir décider de la robustesse/efficacité
|
||||
d'une solution de virtualisation.
|
||||
|
||||
On va encore le laisser une petite semaine munin sur kvm pour pouvoir
|
||||
comparer. Si le test est concluant, une migration d'owl devra être effectuée
|
||||
pour confirmer les résultats (c'est en effet le domU qui est le plus chargé
|
||||
actuellement).
|
||||
|
||||
La solution actuelle de virtualisation n'est pas satisfaisante:
|
||||
|
||||
* Problèmes d'I/O
|
||||
* Échecs de migrations à chaud
|
||||
* xen n'est pas vraiment maintenu
|
||||
|
||||
Remarque: on n'utilise pas la virtualisation matérielle sur fy.
|
||||
|
||||
##### Tweaking
|
||||
|
||||
Dans les machines virtuelles kvm, l'ordonnancement des entrées sorties est fait
|
||||
par défaut par l'ordonnanceur CFQ. Il en est de même pour l'hôte/hyperviseur. De
|
||||
plus, les disques sont en iSCSI, un troisième ordonnancement est effectué par la
|
||||
baie de disques. Pour gagner en performances, il faut utiliser l'ordonnanceur
|
||||
''noop'' sur les VMs (ce qui est le cas sur munin depuis quelques heures). Il
|
||||
faudrait voir s'il ne serait pas avantageux de faire ceci sur les disques iSCSI
|
||||
sur l'hyperviseur. (Les VM xen en virtualisation logicielle utilisent déjà cet
|
||||
ordonnanceur par défaut). Règles UDEV sur fx et fy ?
|
||||
|
||||
### Cacher youtube
|
||||
|
||||
Ça ne marche *que* pour youtube. Il serait bon d'avoir des stats sur les
|
||||
requêtes pour le cache de squid
|
||||
(-> <http://munin.crans.org/crans.org/sable.crans.org.html#Squid> qui ne marche
|
||||
plus).
|
||||
Manifestement le cache ne tient pas très longtemps (ou bien ça ne marche
|
||||
plus ?).
|
||||
Il faut investiguer.
|
||||
|
||||
* Qu'est ce que c'est cette histoire de cacher
|
||||
youtube ? -- WikiPolo <<DateTime(2009-05-26T09:57:47+0100)>>
|
||||
|
||||
Adg voudrait pouvoir faire la même chose pour !DailyMotion, Deezer, ...
|
||||
Mais Pierre dit que : Deezer c'est assez moche, on avait essayé à Berlin...
|
||||
Il faut croire qu'il y a des données en plus pour identifier les connexions.
|
||||
J'ai un peu fait mumuse avec !DailyMotion, ça a l'air du même accabit.
|
||||
|
||||
### Vlan 21
|
||||
|
||||
#### MSN
|
||||
|
||||
* Ça n'a juste pas marché lorsque j'ai voulu essayer avec pidgin, bien que tous
|
||||
les ports eussent été ouverts.
|
||||
* Ce qui est bizarre c'est que j'ai eu des retours positifs dessus.
|
||||
|
||||
#### Wiki
|
||||
|
||||
ip_crans renvoie false sur l'ip de titanic.
|
||||
|
||||
#### Câblage d'un appartement du CROUS
|
||||
|
||||
Aucune limitation technique (à part le câblage physique)
|
||||
|
||||
#### Monitoring
|
||||
|
||||
La connexion marche. Il serait de faire des stats sur le trafic sur la
|
||||
connexion de la freeboîte. (En plugin munin ?)
|
||||
|
||||
### Câblage de la Kfet
|
||||
|
||||
Réalisé jeudi. Il faudra acheter et fixer des prises murales
|
||||
|
||||
### Wifi WPA2
|
||||
|
||||
On préfère garder la surprise pour le we du 7-8. (Vous êtes des malades)
|
||||
|
||||
### Interface d'inscription en ligne
|
||||
|
||||
Ce sera un patch du wiki (et ça ne sera même pas trop sale)
|
||||
|
||||
### Authentification sur moinmoin par la base ldap
|
||||
|
||||
* On autorise une double authentification (comme sur vo)
|
||||
* On rajoute un champ wikinom dans la base LDAP initialisé à !WikiPrénomNom (ou
|
||||
PrénomNom (ça me paraît être la base du wikinom))
|
||||
* Ce champ est modifiable par l'intranet.
|
||||
* Gros checking pour éviter les collisions. (Ce check ne peut se limiter à
|
||||
la base LDAP)
|
||||
-> Cette solution n'empêche en rien de continuer à utiliser les comptes
|
||||
MoinMoin.
|
||||
|
||||
Cependant il pourrait être judicieux de supprimer la création de comptes
|
||||
MoinMoin
|
||||
pour éviter les collisions.
|
||||
|
||||
Les homonymes pourront être gérés par une unicité dans la base LDAP.
|
||||
|
||||
L'authentification LDAP nécessite MoinMoin >1.8 (squeeze) (vu le niveau de
|
||||
patchage du paquet custom actuel, ce n'est pas vraiment un problème).
|
||||
|
||||
### Inventaire du matériel
|
||||
|
||||
Il faudra compter les switchs du 0C. Il faudra un jour faire du rangement.
|
||||
|
||||
### Achats de matériel
|
||||
|
||||
* La RAM a été commandée
|
||||
* Tant que la MGE n'aura pas été appelée, on ne statuera pas sur l'achat des PDU
|
||||
* A priori, MGE n'a pas été appelé (comme *promis* par Olivier le 5 mai)
|
||||
* Vérifier que les pdu font bien ce que l'on attendrait d'eux
|
||||
* Clim de la ferme
|
||||
* Damien a déposé le dossier de travaux auprès du CROUS
|
||||
* Damien a fait un devis auprès de notre prestataire de clim
|
||||
* Damien va faire un devis auprès du prestataire climatisation de l'ENS
|
||||
* Switchs du G (on ne sait pas)
|
||||
|
||||
### Motiver les apprentis
|
||||
|
||||
* Remplacer SQLGrey par un truc plus intéressant *kh* milter-greylist *kh*
|
||||
* **Asterisk** <- en cours à partir de la semaine prochaine
|
||||
* Préinscription
|
||||
* Migration openbsd (c'est chiant)
|
||||
* Taper l'incruste au dpt info avec chicco
|
||||
* IPv6 (lobbying de l'ENS ?)
|
||||
* Mangez avec les doigts comme tout le monde... ( avec la bouche ça suffit )
|
||||
* Faire des poupées vaudou albanel et riester (et lefebvre, gosselin)
|
||||
* Refaire des chiffons{{{^W}}}t-shirts firefox{{{^W}}}iceweasel
|
||||
* Fan inconditionnel des T-Shirts
|
||||
Iceweasel -- WikiAdg <<DateTime(2009-05-26T13:51:43+0100)>>
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 11 juin 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : -- WikiXhub <<DateTime(2009-06-11T20:45:04+0100)>>
|
||||
|
||||
## Présents
|
||||
|
||||
* Jérémie Dimino
|
||||
* Antoine Durand-Gasselin
|
||||
* Olivier Huber
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Vert is dead
|
||||
|
||||
On demande à acheter un fz (HP Proliant DL 360) qui servira soit pour de la
|
||||
virtualisation soit comme serveur classique.
|
||||
Cf demande sur tracker pour la liste des choses à acheter.
|
||||
|
||||
### Problèmes du bâtiment J
|
||||
|
||||
On y a passé une semaine, on a fait des trucs, mais depuis que la ferme ne
|
||||
diffuse plus, on n'a pas constaté de problème.
|
||||
Nous restons à l'écoute des adhérents.
|
||||
|
||||
### Migration des services de rouge
|
||||
|
||||
Cf tracker pour les services qui restent à migrer.
|
||||
|
||||
### MoinMoin
|
||||
|
||||
Adg va essayer de passer le plus vite possible à la 1.8.
|
||||
|
||||
### WiFi
|
||||
|
||||
Sous linux ça marche du tonnerre : la configuration est
|
||||
là : <https://wiki.crans.org/WiFi/SousLinux>
|
||||
Sous Mac Os : Xavier s'occupe de mettre la configuration sur le Wiki
|
||||
Sous Vista : ça ne marche pas pour l'instant
|
||||
|
||||
Les instructions sont sur le Wiki :
|
||||
<https://wiki.crans.org/WifiTechnique/FirmWare>
|
||||
|
||||
### Virtualisation au Cr@ns
|
||||
|
||||
On essaie de faire des tests supplémentaires avec plusieurs systèmes de
|
||||
virtualisation.
|
||||
|
||||
### Préinscription en ligne
|
||||
|
||||
Adg pose un lock. D'ici jeudi prochain on a une preview.
|
||||
|
||||
### Asterisk
|
||||
|
||||
On ne peut pas accéder à notre ligne depuis l'extérieur. Il faut régler les
|
||||
problèmes administratifs (il faut juste envoyer un courrier).
|
||||
|
||||
### Imprimante
|
||||
|
||||
Il faut passer zamok à lenny, peut-être essayer les driver pcl. Problèmes
|
||||
actuels :
|
||||
|
||||
* Certains pdf ne passent pas (mais ça marche avec l'interface web de
|
||||
l'imprimante)
|
||||
* L'agrafage en livret ne marche pas (déterminer la limite à partir de laquelle
|
||||
l'imprimante ne veut agrafer)
|
||||
|
||||
### Redondance et QoS
|
||||
|
||||
Le CA devrait fournir un cahier des charges clair.
|
||||
|
||||
### Serveur pour FeDeRez
|
||||
|
||||
On migre les dns de mdr autre part et on leur donne le serveur.
|
||||
|
||||
### Divers
|
||||
|
||||
La connexion à la Kfet ne marche pas.
|
||||
|
|
@ -0,0 +1,220 @@
|
|||
# Réunion
|
||||
|
||||
* Date : Jeudi 2 juillet 2009
|
||||
* Lieu : 2B (clim powa)
|
||||
* Début : 20h15 (asterisk powa)
|
||||
* Fin: -- WikiAdg <<DateTime(2009-07-02T21:59:34+0100)>>
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Damien Aza-Vallina
|
||||
* Nicolas Dandrimont (conférence VoIP)
|
||||
* Olivier Huber
|
||||
* Pierre Chambart
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Achats de matériels
|
||||
|
||||
* switch 0J (2810) devis (./) , achat (./)
|
||||
* switch 4j (2910) devis (./) , achat (./)
|
||||
* switch plafond2B (1800, le même que minigiga) devis {X} , achat {X}
|
||||
* disques: trop cher, on attend
|
||||
* modules ps/2: devis (./) , achat (./)
|
||||
* multiprises ssh: devis {X} , achat (./)
|
||||
* switchs du G: on attend encore un peu
|
||||
* chaises pour les locaux: 4 pas chères (./)
|
||||
* fz, devis {X} , achat (./) a priori
|
||||
* Pour les logs, des DD Sata sur slon ? Un serveur syslog ? autant que
|
||||
ca ? -> dans le chat)
|
||||
|
||||
### Dossiers avec la DSI
|
||||
|
||||
Il faut prendre rendez-vous avec la DSI pour aborder les points suivants:
|
||||
|
||||
* wifi :
|
||||
* Solutions que la DSI compte déployer ?
|
||||
* Intégration avec notre solution ?
|
||||
* Est-ce qu'on peut arrêter de diffuser ENS-Cachan ?
|
||||
* Elles sont passées où nos bornes en zone ENS ?
|
||||
* Faire marcher notre wifi en zone ENS (PDJ...)
|
||||
* gigabit (matos à acheter ?)
|
||||
* upload
|
||||
* miroir debian ?
|
||||
|
||||
### Rangement/Équipement des locaux
|
||||
|
||||
* Quand est-ce qu'on range le 0C ?
|
||||
Un jour.
|
||||
* Quand est-ce qu'on range la ferme ?
|
||||
Un jour. (ou peut-être une nuit)
|
||||
* de préférence la nuit.
|
||||
* Quand est-ce qu'on fait un inventaire.
|
||||
* On attend fin août quand il y aura plein de monde
|
||||
|
||||
### Organisation des différents projets et détermination de leur priorité
|
||||
|
||||
Il serait bon de mettre en place une liste claire des projets qui pourraient
|
||||
être effectués par des apprentis.
|
||||
|
||||
### Point sur les dossiers techniques
|
||||
|
||||
#### impression
|
||||
|
||||
Il y a des pdf qui buggent, ils restent donc actifs indéfiniment dans la
|
||||
lpq, bloquant les impressions. Supprimés de la lpq, un process fou continue
|
||||
de manger du cpu indéfiniment.
|
||||
|
||||
Solutions envisagées:
|
||||
|
||||
* Migrer zamok à lenny
|
||||
* Utiliser RPC
|
||||
* Utiliser un script OCaml pour soumettre les pdf par l'interface web
|
||||
|
||||
(cette solution a le défaut d'être vraiment lente, même quand on compile en
|
||||
natif)
|
||||
|
||||
* Backporter cups + quelques libs
|
||||
* Tester sur d'autres machines sous lenny (tenter d'autres machines)
|
||||
|
||||
##### Évolutions
|
||||
|
||||
* Facturer de manière plus juste (ne pas facturer les pages n/b comme de la
|
||||
couleur).
|
||||
* Du nupping.
|
||||
* Aperçu des pdf en direct (ajax powaaa)
|
||||
* rajouter les limites
|
||||
* débugger un peu le bouzin *ahem*
|
||||
|
||||
Projet proposable:
|
||||
termes d'accroche -> programmation web, Ajax, user-friendlyness, impression
|
||||
nounous pouvant encadrer -> adg (AT) crans (DOT) org
|
||||
|
||||
#### modules de reboot des bornes
|
||||
|
||||
Pas de méthode d'authentification sur les bornes. Les bornes seront isolées sur
|
||||
un vlan. On peut faire une OTP très sale.
|
||||
|
||||
Deuxième prototype d'ici une semaine et en CMS.
|
||||
|
||||
La doc quand ça sera terminé.......
|
||||
|
||||
#### déploiement du wifi
|
||||
|
||||
it works™ (bitches)
|
||||
|
||||
Les bornes diffusent l'ESSID Cr@ns en WPA2-Enterprise, et transmettent les
|
||||
requêtes radius à ragnarok. Radius sur ragnarok est configuré pour accepter
|
||||
les couples mac/[former]clef ipsec. Ça marche sur beaucoup d'OS très utilisés.
|
||||
|
||||
#### développement du wifi
|
||||
|
||||
-> rachat de bornes: lesquelles?
|
||||
* supportées par openWRT:
|
||||
<http://oldwiki.openwrt.org/TableOfHardware.html>
|
||||
* débit (chiffrement)
|
||||
* possibilité de diffuser plusieurs ssid
|
||||
* 802.11n ? .11a ça serait cool déjà
|
||||
* MIMO ?
|
||||
* NB: il y a des bornes qui ont des disques usb
|
||||
|
||||
##### Évolution
|
||||
|
||||
-> monitorer un peu mieux les bornes
|
||||
* faire joujou avec x-wrt
|
||||
* wiviz
|
||||
-> comprendre la conf de radius sur ragnarok
|
||||
-> nettoyer la conf de radius sur ragnarok
|
||||
|
||||
##### Blagues (ou pas)
|
||||
|
||||
-> projet de borne autonome (se manifester avant le rangement des locaux)
|
||||
|
||||
#### ipv6
|
||||
|
||||
Actuellement en place:
|
||||
|
||||
* un tunnel sur komaz
|
||||
* squid3 sur sable
|
||||
-> dégager des projets pour des apprentis.
|
||||
* firewall (projet à encadrer strictement)
|
||||
* réécrire proprement les scripts de comptage
|
||||
* négocier avec la DSI open-réseau
|
||||
* dhcp / router advertaïzement
|
||||
* igmp
|
||||
* les scripts ?! -> les scripts seront plus ou moins recodés dans leur
|
||||
intégralité.
|
||||
|
||||
#### features des switchs
|
||||
|
||||
##### DHCP pirates
|
||||
|
||||
* Protection contre les DHCP pirates
|
||||
|
||||
##### Détection des boucles
|
||||
|
||||
Les gens du point rencontre ont fait des boucles. Ça a mis down une partie du
|
||||
réseau. Il faudrait vérifier que la détection des boucles marche. On perd
|
||||
Jérémie,
|
||||
mais le problème devrait bientôt être résolu.
|
||||
done! *applause*
|
||||
|
||||
#### rouge
|
||||
|
||||
On migre rouge dès que possible. La source de rayons comiques s'est peut-être
|
||||
tarie.
|
||||
Peck est sur le campus pour de bon.
|
||||
|
||||
-> petit projet pour apprenti:
|
||||
générer un known_hosts potable et ranger les clefs.
|
||||
|
||||
#### vert
|
||||
|
||||
Une belle bête, qui pèse bien ses 42kg. On remarquera que vert a des
|
||||
ventilateurs
|
||||
rackables.
|
||||
|
||||
#### OpenStreetMap
|
||||
|
||||
Il faut voir *exactement* de combien de place et de débit ils ont besoin, et on
|
||||
décide en conséquence...
|
||||
|
||||
#### Corbeau
|
||||
|
||||
diffusion-crans.general@crans.org poste automatiquement sur crans.general
|
||||
seule brigitte.vidal@adm.ens-cachan.fr pourra poster. Si elle poste trop,
|
||||
on la déconnecte.
|
||||
|
||||
#### pegase
|
||||
|
||||
il est open
|
||||
munin me paraît être un excellent choix.
|
||||
|
||||
#### proxy
|
||||
|
||||
revoir la conf de zéro
|
||||
|
||||
#### VoIP
|
||||
|
||||
It works™.
|
||||
Il reste encore *plein* de trucs à faire.
|
||||
|
||||
Oh! tiens encore plein de programmation web à faire.
|
||||
|
||||
#### wiki
|
||||
|
||||
À mort Apache ! Mais bon, osef. Ocsigen avec WSGI (l'interface "CGI" mieux de
|
||||
Python) ? ocsigen powa ( ocsimore a une grosse bite )
|
||||
|
||||
#### zamok
|
||||
|
||||
l'idée serait de coller sur fzamok, l'impression, l'intranet,
|
||||
le webmail, l'imap, le pop, et, dans une machine virtuelle, le serveur des
|
||||
adhérents.
|
||||
niomniom resterait le serveur web du crans.
|
||||
|
||||
On casse zamok ? (upgrade)
|
||||
Bof.
|
||||
|
|
@ -0,0 +1,248 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 10 Septembre 2009
|
||||
* Lieu : PdJ
|
||||
* Début : 19h30
|
||||
* Fin : 21h35
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Johan Grande
|
||||
* Larissa Viraphong
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Huber
|
||||
* Raphaël Bonaque
|
||||
* Raphaël Cauderlier
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Présentations
|
||||
|
||||
Elles sont faites et mamie a trouvé le bon serveur sur lequel se connecter :)
|
||||
|
||||
### Bilan du câblage du bâtiment G (espérons...)
|
||||
|
||||
* Le bâtiment G a été relié avec un câble RJ-45 de 153m de long
|
||||
* Les switchs ont étés installés
|
||||
|
||||
La solution qui a été mise en place (le long RJ-45) ne marche pas très
|
||||
bien. Il faudra réussir à pérenniser la connexion, vu qu'il faudra
|
||||
nécessairement
|
||||
remettre une fibre optique. L'ancienne semble vraiment en trop mauvais état pour
|
||||
être utilisée. Il faut budgétiser le sertissage d'une nouvelle fibre, ainsi que
|
||||
sa pose (sachant que nous pourrions effectuer nous-même la pose de la fibre).
|
||||
|
||||
À priori, une bobine de 250m de fibre coûterait dans les 500 euros.
|
||||
L'utilisation de la fibre enroulée actuellement au -1I n'est pas envisageable,
|
||||
vu qu'elle est enroulée depuis plus de 5 ans.
|
||||
|
||||
La fibre connectant le 0G et le 2G est cassée dans la baie de brassage, il
|
||||
faudrait
|
||||
voir à la faire ressertir. Il faudrait aussi voir si sa réparation ne pourrait
|
||||
pas
|
||||
être prise en charge par une des (certainement nombreuses) assurances du CROUS
|
||||
pour
|
||||
les travaux dans le bâtiment G.
|
||||
|
||||
Connexion actuelle au G :
|
||||
batj-319 <-- 153m (cuivre) --> batg-025 0G <-> 4G en fibre et 4G <-> 2G en
|
||||
cuivre (cat6).
|
||||
|
||||
Restrictions :
|
||||
La télé est bloquée depuis batj-3. Il faut dire aux câbleurs de prévenir les
|
||||
gens
|
||||
pour utiliser leur connexion avec parcimonie (quand elle fonctionne).
|
||||
|
||||
### Recrutement - lancement des séminaires
|
||||
|
||||
Olivier propose que les apprentis fassent toujours les séminaires, mais qu'une
|
||||
nounou soit responsable de suivre le travail de l'apprenti et puisse servir de
|
||||
backup en cas de problème.
|
||||
|
||||
Une autre idée serait de faire des revues de code Python, afin d'améliorer les
|
||||
scripts en douceur et de permettre la transition.
|
||||
|
||||
Les nounous se chargent de mettre au point une liste de séminaires qui sera
|
||||
présentée à la prochaine internounou.
|
||||
|
||||
### État des lieux des serveurs
|
||||
|
||||
#### rouge : MX principal, serveur smtp et serveur mailman
|
||||
|
||||
(anciennement wiki, serveur web, serveur jabber, serveur imap, serveur pop,
|
||||
serveur ntp,
|
||||
serveur de kernel panic, serveur DHCP)
|
||||
|
||||
Il faut mettre fin à ses jours sous peu. Ne reste plus qu'à migrer les
|
||||
services mail.
|
||||
|
||||
#### zamok
|
||||
|
||||
Serveur des adhérents, serveur des pages perso, de l'intranet, délivrance des
|
||||
mails (procmail, forward, etc.)
|
||||
|
||||
Une proposition serait d'acheter un nouveau "gros" serveur (fz), sur lequel
|
||||
seraient
|
||||
rassemblés les services concernant les adhérents. Vu que les tests d'autres
|
||||
solutions de virtualisation n'ont pas été probants, ce serveur serait placé sous
|
||||
xen. Il faut budgetiser cette solution.
|
||||
|
||||
#### pegase
|
||||
|
||||
Ne fait plus rien, est éteint, mais fonctionne (et a plein de disques). Est une
|
||||
vieille brouette.
|
||||
|
||||
#### babar
|
||||
|
||||
Serveur de sauvegarde et de vidéosurveillance, fonctionne, est à jour.
|
||||
|
||||
#### sila
|
||||
|
||||
Serveur sFTP. Un peu ancestral, un peu de brique et de broque. Il faudrait
|
||||
demander
|
||||
un devis pour :
|
||||
|
||||
* Un serveur 1U ou 2U avec des gros disques
|
||||
* Un serveur 1U avec des petits disques et des gros disques pour la baie
|
||||
|
||||
Et choisir la solution la moins chère, pour remplacer sila en tant que FTP.
|
||||
|
||||
#### ragnarok
|
||||
|
||||
Serveur sous OpenBSD, serveur radius, routeur wifi, serveur web de
|
||||
wifi.crans.org
|
||||
|
||||
Il faut le mettre à jour vers OpenBSD 4.5 (comme tous les 6 mois). Peut-être que
|
||||
les fuites mémoire de {freeradius, Patches OpenBSD} seront corrigées.
|
||||
|
||||
#### Serveurs de la ferme
|
||||
|
||||
* vache (mdr) (dns de la zone TV) -- It works!™
|
||||
* canard
|
||||
* oie
|
||||
* lapin
|
||||
* dindon (prove)
|
||||
|
||||
Les serveurs fonctionnent, mais le multiswitch a cramé. On récupère la TNT en
|
||||
splittant le flux. On peut racheter un multiswitch, ce qui nous permettra de
|
||||
multiplier le nombre de cartes satellite.
|
||||
|
||||
#### fy
|
||||
|
||||
* Dom0 Xen
|
||||
|
||||
#### fx
|
||||
|
||||
* Serveur NFS (homes + /usr/scripts)
|
||||
|
||||
#### sable
|
||||
|
||||
Le proxy, serveur DNS principal, serveur DHCP, serveur radius, serveur de la
|
||||
connexion gratuite.
|
||||
|
||||
Il fonctionne malgré la grosse mise à jour de porc vers squid3.
|
||||
|
||||
### Investissements potentiels
|
||||
|
||||
* Nouveau contact pour Synaps : Nicolas va reprendre le contact avec Anne.
|
||||
|
||||
#### ftp
|
||||
|
||||
Cf. ci-dessus.
|
||||
|
||||
#### fz/zamok++
|
||||
|
||||
Le système imaginé avant les vacances, lors des problèmes d'I/O Xen, était
|
||||
d'acheter
|
||||
un serveur qui monterait les /homes, et les partagerait directement à tous les
|
||||
services qui en auraient besoin (i.e. les services adhérents de zamok + owl +
|
||||
niomniom).
|
||||
|
||||
Vu que les problèmes de Xen semblent réglés, placer les services des adhérents
|
||||
sur un DomU serait envisageable. On va voir avec Anne ce qu'elle propose comme
|
||||
bête de course.
|
||||
|
||||
#### monitoring
|
||||
|
||||
Il faudrait budgetiser un serveur "peu puissant" pour effectuer le monitoring
|
||||
séparément (munin, autostatus, ...). On pourrait y ajouter pour pas cher une
|
||||
centralisation des syslog (à l'aide de rsyslog).
|
||||
|
||||
#### Fibre
|
||||
|
||||
Cf. ci-dessus
|
||||
|
||||
#### Reboot de bornes
|
||||
|
||||
Voté au précédent CA (500€ de budget pour 10 modules) et cf ci-dessous.
|
||||
|
||||
#### Bornes wifi
|
||||
|
||||
Voté au précédent CA (500€ pour $n$ bornes de test)
|
||||
|
||||
### Projets en cours
|
||||
|
||||
#### bcfg2
|
||||
|
||||
Système de gestion de configuration des serveurs. Permet de centraliser les
|
||||
configurations redondantes.
|
||||
Comme puppet ou cfengine (mais en python).
|
||||
|
||||
Le passage de bcfg2 0.9 à 1.x nécessite python 2.6 (ou un module SSL backporté).
|
||||
|
||||
Il faudrait unfucker la configuration.
|
||||
|
||||
#### Reboot de bornes
|
||||
|
||||
It works, bitches !™
|
||||
|
||||
Un des modules a été détourné pour remplacer vigile pour la gestion du digicode.
|
||||
|
||||
Il faudra des doigts pour réaliser les 100 modules.
|
||||
|
||||
#### Impression
|
||||
|
||||
L'imprimante en elle-même marche très bien (beaucoup mieux que l'ancienne), mais
|
||||
les drivers de canon chient.
|
||||
|
||||
Par ailleurs, toutes les ~100 pages imprimées, si elles restent dans le bac,
|
||||
l'imprimante s'arrête et attend que quelqu'un les enlève du bac de sortie.
|
||||
C'est très gênant pour les grosses impressions de rentrée.
|
||||
|
||||
#### Intranet
|
||||
|
||||
C'est de l'AJAX avec !MochiKit. Adg s'est un peu penché dessus, et apparemment
|
||||
il va réussir à le migrer vers !CherryPy de lenny.
|
||||
|
||||
#### Téléphonie
|
||||
|
||||
Vous allez être mis en communication avec votre correspondant, merci de
|
||||
patienter quelques mois...
|
||||
|
||||
Le Crous a demandé à son FAI de s'occuper aussi d'un service de téléphonie sur
|
||||
IP, et voudrait qu'on ne soit pas en concurrence avec lui.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Répartition des clés
|
||||
|
||||
Michel aimerait avoir une clé du 0B. Il faut que Jérémie rende ses clefs du
|
||||
Cr@ns.
|
||||
|
||||
En particulier pour les clés du 4J, il faudrait essayer de savoir exactement où
|
||||
sont les clés, et récupérer celles des gens qui ne les utilisent plus...
|
||||
Comme tous les ans ?
|
||||
|
||||
Xavier pense développer, sur la même base que les modules de reboot et le
|
||||
digicode, des serrures RFID qui remplaceraient avantageusement les 16 clés du 4J
|
||||
qui se baladent dans la nature (et même, peut-être, des autres locaux
|
||||
associatifs ?).
|
||||
|
||||
#### Crous
|
||||
|
||||
Des discussions ont eu lieu avec le FAI, qui accepte de nous laisser gérer le
|
||||
routage, le filtrage et les logs.
|
||||
|
|
@ -0,0 +1,81 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : 22 Octobre 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : <<Date(2009-10-22T20:56:17+0200)>>
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Damien Aza-Vallina
|
||||
* Johan Grande
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Raphaël Bonaque
|
||||
* Raphaël Cauderlier
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Point technique sur la convention Cr@ns - CROUS
|
||||
|
||||
### Bâtiment G
|
||||
|
||||
#### Réseau Filaire
|
||||
|
||||
#### Couverture WiFi
|
||||
|
||||
On a mis des bornes sur le J, on a l'accord de principe de l'ENS pour arroser
|
||||
la façade ouest du G depuis le toit du Cournot.
|
||||
|
||||
#### Pont WiFi
|
||||
|
||||
Le cdcf c'est un pont chiffré: openWRT pourvoit un mode spécifique
|
||||
|
||||
### Ragnarok (maj, fuites de memoire)
|
||||
|
||||
Il *faut* mettre à jour Ragnarok.
|
||||
Il faudra vérifier radius et munin qui sont actuellement les générateurs
|
||||
d'occupation mémoire.
|
||||
|
||||
### Accès aux backups des homes des adhérents
|
||||
|
||||
Il faut y réfléchir avant la migration de zamok. Il faut réfléchir à :
|
||||
|
||||
* La réutilisation potentielle des uid (qu'un nouvel adhérent ne se retrouve
|
||||
|
||||
pas avec les backups d'un ancien dont le compte a été supprimé)
|
||||
|
||||
* A ce que l'espace de stockage ne soit pas virtuellement infini.
|
||||
|
||||
### Serveurs Free
|
||||
|
||||
Xavier se propose pour aller les chercher la semaine prochaine avec les gens
|
||||
intéressés. Ce sont des serveurs 1U, sans disques durs (on les ferait booter
|
||||
depuis le réseau).
|
||||
|
||||
### Organisation des séminaires techniques
|
||||
|
||||
On pourrait ajouter un séminaire sur le firewall prochainement, ou pas. Pour les
|
||||
séminaires suivants, il faudrait essayer d'encadrer un peu mieux et que les
|
||||
séminaires soient un peu moins abstraits.
|
||||
|
||||
### Projets Apprentis
|
||||
|
||||
* "recoder munin"
|
||||
* dns pour les vieux
|
||||
* VoIP (ou pas)
|
||||
* recoder l'intranet
|
||||
* faire des enregistrements pour un GlaDOS à la ferme
|
||||
* débugger la pute d'imprimante
|
||||
* IDS / monitoring
|
||||
* ... Ce qui vous plairait ?
|
||||
|
||||
### Installation de fz
|
||||
|
||||
* Les homes montés dans l'hôte, qui les distribuerait directement aux jails.
|
||||
(on partirait donc sur une architecture de jailing). On pourrait tester openvz
|
||||
et/ou vserver. On fera des tests sur fz, jusqu'à ce que ça semble stable et on
|
||||
procédera à la migration de zamok.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
# Réunion
|
||||
|
||||
* Date : 10 Décembre 2009
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : 21h35
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Dominique Delport
|
||||
* Jean-Benoist Leger
|
||||
* Jérémie Dimino
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Connexion de fortune bâtiment G
|
||||
|
||||
#### Couverture WiFi
|
||||
|
||||
Actuellement le batiment G est arrosé sur sa façade est. Il devrait
|
||||
être possible de s'arranger avec le dpt info pour installer des bornes
|
||||
au Cournot. Il faudrait étudier l'installation au sol de bornes avec des
|
||||
antennes Hyperlink (17dB, 120°, aucun bruit à l'arrière).
|
||||
|
||||
Les vitres du bâtiment G atténuent beaucoup le signal (quid de demander
|
||||
aux adhérents d'installer une antenne ?).
|
||||
|
||||
Avec la solution actuelle basée sur des linksys WRT54g on ne peut
|
||||
dépasser une quinzaine de clients par bornes. Les bornes bullet
|
||||
d'ubiquiti peuvent être un nouveau matériel intéressant vers lequel se
|
||||
tourner. Possibilité de pont wifi, support de beaucoup plus de clients.
|
||||
Ces bornes, nouvelles, utilisent le 802.11n, et permettent d'atteindre
|
||||
300Mb/s réel. Les prix sont tout à fait corrects (50-100€).
|
||||
|
||||
D'un point de vue légal, il devrait être tout à fait possible de
|
||||
respecter les réglementations en vigueur en matière d'émission
|
||||
hertzienne.
|
||||
|
||||
### Installation de fz
|
||||
|
||||
Utilisation d'une solution de containers (OpenVZ ou vserver...).
|
||||
|
||||
Il y aurait :
|
||||
|
||||
* Un container pour les adhérents
|
||||
* Un container pour les services mail
|
||||
* ...
|
||||
|
||||
### Déconnexion mail invalide
|
||||
|
||||
Michel n'est pas là pour nous en parler...
|
||||
|
||||
### Modifications de la base LDAP
|
||||
|
||||
#### Autorisation de la modification d'attributs dans le sous-arbre des
|
||||
|
||||
adhérents
|
||||
|
||||
Ceci permettrait de modifier plus proprement les données de l'adhérent
|
||||
depuis l'intranet, qui n'aurait plus à être lancé en tant que respbats.
|
||||
|
||||
Il faut étudier comment faire ça proprement avec les ACLs de LDAP (création
|
||||
d'une vue spécifique).
|
||||
|
||||
#### IPv6
|
||||
|
||||
On donne un /64 par machine (fixe) inscrite dans la base LDAP. Ceci sera fait à
|
||||
la demande (champ booléen dans la machine).
|
||||
|
||||
Le préfixe IPv6 est donné comme suit :
|
||||
[préfixe crans (n bits)]:[mid (p bits)]::/64
|
||||
|
||||
#### Cleanup Type de connexion
|
||||
|
||||
Ce champ permettrait de formaliser le champ "Connexion Gratuite / Appartements
|
||||
ENS / ..." qui est un peu mis de manière anarchique dans la base.
|
||||
|
||||
#### Compte wiki
|
||||
|
||||
Ceci permettrait de lier le compte Cr@ns et le compte Wiki, en permettant
|
||||
l'authentification directe via LDAP en gardant le WikiNom associé.
|
||||
|
||||
On n'imposerait pas de compte Cr@ns pour le compte Wiki.
|
||||
|
||||
#### VLAN Custom
|
||||
|
||||
Permettrait de stocker les VLAN a ajouter sur une prise pour la DSI... On va
|
||||
stocker ça dans annuaire.py.
|
||||
|
||||
### Modules de détection de mouvements
|
||||
|
||||
Il faut des paires de mains pour peupler les cartes. Ça serait à commencer à la
|
||||
fin de la semaine prochaine (mercredi ou jeudi), et à finir avant dimanche
|
||||
prochain.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
N/A
|
||||
|
|
@ -0,0 +1,181 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 14 Janvier 2010
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h40
|
||||
* Fin : -- WikiMichou <<DateTime(2010-01-14T22:26:17+0200)>>
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Augustin Parret-Fréaud
|
||||
* Jérémie Dimino
|
||||
* John-Eric Dufour
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Huber
|
||||
* Olivier Iffrig
|
||||
* Pierre Chambart
|
||||
* Raphaël Cauderlier
|
||||
* Stéphane Glondu
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Compte-rendu de l'intervention au bâtiment G
|
||||
|
||||
#### État des fibres
|
||||
|
||||
La connexion a été rétablie. On a un débit de 930Mb/s.
|
||||
On recevra les tests faits par les techniciens plus tard.
|
||||
|
||||
#### Configuration des switchs
|
||||
|
||||
Il y a un problème avec batg-0. Il a été remis dans sa configuration d'usine
|
||||
(sous laquelle il fonctionne).
|
||||
|
||||
#### Câblages physiques
|
||||
|
||||
Tous les gens qui ont demandé la connexion Cr@ns l'ont eue.
|
||||
|
||||
Il faudra câbler physiquement les gens quand la connexion Crous sera dans tous
|
||||
les bâtiments. Pour l'instant c'est les nounous qui le font le soir.
|
||||
Ça reste comme ça tant que c'est gérable.
|
||||
|
||||
#### Rangement des locaux
|
||||
|
||||
Il aura lieu samedi à 14h.
|
||||
|
||||
### Problèmes récurrents / maintenances
|
||||
|
||||
#### IMAP
|
||||
|
||||
L'imap chie dans la colle. On ne sait pas pourquoi. Apparemment le DomU swappe
|
||||
beaucoup. On lui rajoute un giga de ram et on voit si ça va mieux...
|
||||
|
||||
Récemment des homes n'étaient pas créés. Il faut surveiller ça.
|
||||
|
||||
#### Impression
|
||||
|
||||
Il y a des traces noires de pire en pire sur les impressions, personne
|
||||
ne s'en est vraiment occupé.
|
||||
|
||||
Jérémie les appelle demain.
|
||||
|
||||
#### Proxy
|
||||
|
||||
Des gens ont constaté des lenteurs et des erreurs sur le proxy.
|
||||
|
||||
Un des problèmes: ipv6 sur sable qui se choppe des annonces bizarres.
|
||||
En les retirant ça marche mieux. Le souci était le DNS, qui vient faire des
|
||||
requêtes d'adresses AAAA sur des serveurs racine en ipv6... *boom*
|
||||
|
||||
#### bata-3
|
||||
|
||||
[Chie](http://munin.crans.org/switchs.crans.org/bata3.adm-ping_bata_3_adm.html)
|
||||
|
||||
#### Bâtiment H ?
|
||||
|
||||
Il faudrait revenir vers les gens pour être sûrs que c'était bien le problème de
|
||||
proxy...
|
||||
|
||||
### Évolution des services
|
||||
|
||||
#### Intranet
|
||||
|
||||
Un nouvel intranet a commencé à voir le jour.
|
||||
Il est disponible sur <https://intranet2.crans.org> (pour l'instant, il n'y a
|
||||
que la gestion du câblage des prises).
|
||||
|
||||
C'est sur o2, dans /usr/local/django/intranet (dépôt darcs)
|
||||
|
||||
Il ne reste plus qu'à développer des applications...
|
||||
|
||||
#### Modifications de la base LDAP
|
||||
|
||||
* Remaniement des ACLs
|
||||
* Autorisation de la connexion des adhérents avec leur compte Cr@ns
|
||||
* Autorisation de la modification d'attributs dans le sous-arbre des
|
||||
adhérents
|
||||
* Modification des attributs
|
||||
* IPv6
|
||||
* Adresse IP : L'adresse IP(v4,6) d'une machine est calculée par le mid,
|
||||
il y aura un champ "adresse IPv6 custom en plus" pour les machines ne
|
||||
respectant pas la convention (voir
|
||||
le [[CransTechnique/PlanAdressage#Machines|plan d'adressage]] sur le
|
||||
wiki, les scripts ne sont pas encore adaptés (en cours par Stéphane))
|
||||
* Cleanup Type de connexion : chaîne de caractères dans adherent
|
||||
* adhérent gratuit/payant/personnel ENS/autres
|
||||
* la base n'est pas encore peuplée
|
||||
* Compte Wiki : chaîne dans le compte crans
|
||||
* mailInvalide : timestamp dans adherent (au lieu d'un booléen)
|
||||
* DNS IPv6 : ajout d'un champ booléen (par machine) pour activer le DNS
|
||||
IPv6 pour l'adresse sur le /64 du vlan par défaut.
|
||||
* DNS (crans.eu) : nouvelle arborescence contenant un nom, une adresse et un
|
||||
propriétaire (compte crans).
|
||||
* .crans.eu
|
||||
* .ipv6.crans.eu : sous-arbre spécial de délégations vers les serveurs
|
||||
DNS pour leur /64 ipv6
|
||||
|
||||
#### Installation de fz
|
||||
|
||||
Il faut le faire. Cf. le tracker.
|
||||
|
||||
#### Télévision
|
||||
|
||||
* Multiswitch...
|
||||
* Olivier l'installera avant de partir.
|
||||
* Il faut en profiter pour vérifier la qualité de réception, certaines
|
||||
cartes ont des problèmes.
|
||||
* Unicast pour diagnostiquer chez les adhérents se plaignant de problèmes de
|
||||
multicast
|
||||
* Transcoding pour faire de la télé over WiFi : à tester sur les serveurs de
|
||||
free, faut leur coller une carte TV
|
||||
* IPv6 ?
|
||||
* Satellite a <http://fr.kingofsat.net/pos-28.2E.php> : il faut voir avec le
|
||||
CROUS pour la pose d'une nouvelle antenne.
|
||||
|
||||
#### DNS
|
||||
|
||||
Il faudrait reprendre l'architecture DNS du Cr@ns. En effet, les serveurs DNS
|
||||
autoritaires et les serveurs de cache sont les mêmes.
|
||||
|
||||
Il faut séparer les serveurs cache et les serveurs autoritaires pour les zones
|
||||
Cr@ns.
|
||||
|
||||
Serveurs cache :
|
||||
|
||||
* sable
|
||||
* gordon
|
||||
* titanic (patte interne, requêtes DNS des appartements)
|
||||
|
||||
Serveurs primaires :
|
||||
|
||||
* sila : crans.org, crans.eu, *.in-addr.arpa (filaire), *.ip6.arpa (filaire),
|
||||
wifi.crans.org, *.in-addr.arpa (wifi), *.ip6.arpa (wifi)
|
||||
* mdr : tv.crans.org, *.in-addr.arpa (multicast)
|
||||
* sila : adm.crans.org, 136.231.10.in-addr.arpa
|
||||
|
||||
On fait un miroir des serveurs autoritaires sur :
|
||||
|
||||
* ovh (évidemment)
|
||||
* freebox (patte externe)
|
||||
|
||||
On pourra ajouter du DNSSec plus tard.
|
||||
|
||||
#### Wifi
|
||||
|
||||
* Achat de nouvelles bornes
|
||||
* On va faire les courses chez landanet
|
||||
* Déploiement
|
||||
|
||||
### FAI RUBIS
|
||||
|
||||
#### Organisation de la réunion Katy Tréca / Cr@ns
|
||||
|
||||
Une réunion a été fixée pour le mercredi 20 à 16h, probablement dans le bureau
|
||||
de Katy Tréca.
|
||||
|
||||
Nicolas mettra le compte-rendu de la réunion Berlinoise en ligne sous peu.
|
||||
|
||||
### Questions diverses
|
||||
|
|
@ -0,0 +1,137 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 5 mai 2011
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h10
|
||||
* Fin : 21h01
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Daniel Stan
|
||||
* Jérémie Dimino
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vincent Maioli
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Entrevue avec la DSI
|
||||
|
||||
Lundi 9 mai à 14h30 entrevue avec Stuart. Nicolas y va accompagné de Daniel et
|
||||
Valentin.
|
||||
|
||||
Ordre du jour :
|
||||
|
||||
* Gigabit
|
||||
* WiFi
|
||||
* Repeuplement du Cournot
|
||||
* Annonce du réseau Cr@ns sur les bornes aruba
|
||||
* Réinstallation de bornes à l'ENS
|
||||
* Connexion des Appartements
|
||||
* IPv6
|
||||
* Peer to peer
|
||||
|
||||
### WiFi
|
||||
|
||||
#### Mises à jour
|
||||
|
||||
Le WiFi doit être remis en état de marche correct pour la rentrée.
|
||||
|
||||
* SSID Multiples (n > 2)
|
||||
* IPv6
|
||||
* WiFi N
|
||||
|
||||
Points techniques
|
||||
|
||||
* OpenWRT
|
||||
* Firmware à jour
|
||||
* Firmware "universel" (configuration de la borne par DHCP)
|
||||
|
||||
Possibilités :
|
||||
|
||||
* Identification par compte Cr@ns, voire double authentification (compte Crans
|
||||
OU compte spécifique wifi)
|
||||
|
||||
À faire :
|
||||
|
||||
* Mise en place d'une infrastructure de test (vlan séparé, serveur radius
|
||||
séparé sur un domU, ...)
|
||||
* Tests de firmwares sur les bornes actuellement en train de prendre la
|
||||
poussière au 2B
|
||||
* Achat de nouvelles bornes (soit de tests si les bornes actuelles sont
|
||||
merdiques, soit en série)
|
||||
|
||||
Les tests vont commencer quand les gens voudront.
|
||||
|
||||
#### Repeuplement du Cournot
|
||||
|
||||
Les A0 veulent une borne en C411 (elle y est, il faut juste la router vers le
|
||||
réseau Crans).
|
||||
|
||||
Il faut demander à la DSI de router le vlan 3 au bon endroit.
|
||||
|
||||
#### Fixations des bornes du toit du J
|
||||
|
||||
Le feuillard en alu est acheté, il faut trouver les fixations qui n'étaient pas
|
||||
dans le même rayon.
|
||||
|
||||
Pour l'installation, il faut voir avec Isabelle (du CROUS).
|
||||
|
||||
### Connexion appartements
|
||||
|
||||
Il y a vraiment des bugs bizarroïdes. Quelques possibilités à évoquer avec
|
||||
Stuart :
|
||||
|
||||
* Passer les personnels directement sur la connexion Cr@ns. Cela règlerait de
|
||||
manière
|
||||
|
||||
avantageuse le problème du monitoring de la connexion.
|
||||
|
||||
* Multiplexer n freeboxes. La question : où les mettre, et si free va pas faire
|
||||
la gueule.
|
||||
|
||||
Il reste aussi à développer le système de load-balancing. Le point de sortie
|
||||
pourrait être une dedibox SC de chez online.net.
|
||||
|
||||
On verra ça lundi avec Stuart.
|
||||
|
||||
### Mises à jour de serveurs
|
||||
|
||||
Vincent a fait une mise à jour (mais d'un serveur qui sert à rien) \o/
|
||||
|
||||
Michel s'occupera de pgsql quand il aura la bonne idée de ne pas tomber malade.
|
||||
|
||||
fx sera mis à jour quand on migrera les /home.
|
||||
|
||||
Rappel : les domU mis à jour sont à migrer sur fz pendant leur mise à jour.
|
||||
|
||||
### IPv6
|
||||
|
||||
Il serait temps d'activer l'IPv6 de manière globale et automatique.
|
||||
|
||||
Ce qui est release critical :
|
||||
|
||||
* Filtrage des RA pirates (vieux et fait)
|
||||
* Firewall v6 (fait modulo port 80)
|
||||
* Désactiver le proxy transparent pour l'IPv6. On peut revoir à fournir un
|
||||
fichier de configuration de proxy si les gens le souhaitent (oh noes, they
|
||||
will never do it).
|
||||
* Adaptation des scripts (de surveillance)
|
||||
* Upload : fait, pas de déconnexion automatique mais le mail de stats est lu
|
||||
tous les jours.
|
||||
* P2P : il faut trouver une solution de level7 filtering compatible IPv6.
|
||||
Pas nécessaire immédiatement
|
||||
* DNSv6
|
||||
* Configuration de radvd et d'un DHCPv6 pour avoir un peu plus qu'un routeur
|
||||
sur IPv6.
|
||||
|
||||
### Questions Diverses
|
||||
|
||||
#### Problèmes de Webmail/dovecot
|
||||
|
||||
Dovecot avait du mal à cause d'une limite sur le nombre de fichiers ouverts.
|
||||
Ça a été réglé en augmentant la limite de fichiers ouverts par root.
|
||||
|
|
@ -0,0 +1,92 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 19 mai 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 20h07
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vincent Maioli
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Mises à jour
|
||||
|
||||
La mise à jour de fx doit être terminée. Ça sera fait samedi soir.
|
||||
|
||||
radius et xmpp ont été mis à jour.
|
||||
|
||||
Vincent s'occupera d'ovh d'ici la fin de semaine.
|
||||
|
||||
### Intranet 2
|
||||
|
||||
Daniel a avancé sur l'interface de gestion des accès. Ça ne sera pas prêt à être
|
||||
présenté demain, mais bientôt.
|
||||
|
||||
Cahier des charges :
|
||||
|
||||
* Enregistrement d'interventions
|
||||
* Édition des interventions futures
|
||||
* Listing des interventions par local
|
||||
|
||||
Voir avec C. Lebailly pour ce qu'ils veulent.
|
||||
|
||||
Futur :
|
||||
|
||||
* Interfaçage avec les caméras / détecteurs de mouvement
|
||||
* Badgeuse ?
|
||||
|
||||
### IPv6
|
||||
|
||||
Le DNS a été configuré, et un radvd a été mis en place sur komaz.
|
||||
|
||||
Ça marche bien sur les systèmes d'exploitation qui n'en ont rien à foutre de la
|
||||
vie privée de leurs utilisateurs (et qui gèrent bien IPv6).
|
||||
|
||||
Plusieurs possibilités sont envisageables :
|
||||
|
||||
* Mise en place d'un DHCPv6
|
||||
* Distribution d'adresses d'autoconfiguration
|
||||
* Suppression de la règle droppant les paquets qui font la correspondance
|
||||
MAC - IPv6
|
||||
* La règle qui fait le matching sur les adresses mac existe déjà. Il faut
|
||||
juste garder la correspondance entre les MAC et les IPv6 dans une base de
|
||||
données.
|
||||
|
||||
Il faut mettre en place un outil de monitoring, par exemple ndpmon, pour garder
|
||||
trace des associations MAC - IPv6.
|
||||
|
||||
Il faut évaluer les conséquences de mettre en place le DHCPv6, notamment sur la
|
||||
simplicité de configuration.
|
||||
|
||||
### WiFi
|
||||
|
||||
Ça n'a pas avancé depuis la dernière fois.
|
||||
|
||||
### Télévision
|
||||
|
||||
On va passer au 4J faire une vérification des branchements.
|
||||
|
||||
Pour les nouvelles cartes en USB, des tests ont été faits. Apparemment ça ne
|
||||
chauffe pas trop. Il faut maintenant tester avec une sheevaplug.
|
||||
|
||||
### Ajouts de droits
|
||||
|
||||
Nicolas propose d'ajouter les droits Nounou à Daniel et Valentin.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Fixations des bornes
|
||||
|
||||
Daniel est repassé à Casto et les trucs de fixation ont l'air de suxer. Daniel
|
||||
propose une solution alternative, mais qui est vraiment overkill pour seulement
|
||||
deux bornes (> 100 euros de tendeur)...
|
||||
|
||||
On réévaluera la nécessité de ces bornes quand la couverture intérieure du
|
||||
bâtiment G existera.
|
||||
|
|
@ -0,0 +1,109 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 15 septembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début de la réunion : 19h20
|
||||
* Fin : 20h06
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Aurore Quelennec
|
||||
* Benjamin Aupetit
|
||||
* Daniel Stan
|
||||
* Louis Bondaz
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Raphael Bonaque
|
||||
* Raphael Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vanessa Verbeke
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
Après un tour de table, on entame l'ordre du jour.
|
||||
|
||||
### Responsable Technique en Chef
|
||||
|
||||
Sur proposition du RTC sortant, le collège des Nounous approuve la nomination
|
||||
d'Olivier Iffrig comme nouveau Responsable Technique en Chef.
|
||||
|
||||
### Recrutement
|
||||
|
||||
Bienvenue aux nouveaux (-;
|
||||
Les droits apprenti leurs seront donnés à la fin de la réunion, après un
|
||||
discours sur ce que ces droits permettent de faire de mal, et lecture de la
|
||||
charte des membres actifs.
|
||||
|
||||
### Séminaires
|
||||
|
||||
On va tenter de reprendre le rythme précédent d'un séminaire par semaine.
|
||||
|
||||
| Date | Thème | Intervenant | Encadrant |
|
||||
|-----------------|----------------------------------|-------------|-------------------|
|
||||
| 4 octobre 2011 | Présentation du réseau Cr@ns | WikiIota | NicolasDandrimont |
|
||||
| 11 octobre 2011 | Réseaux, Ethernet, TCP/IP | WikiLxir | TotoPassoir |
|
||||
| | Le Shell, SSH | | WikiB2moo |
|
||||
| | Administration réseau sous Linux | | NicolasDandrimont |
|
||||
| | Python | | WikiIota |
|
||||
| | Les scripts du Cr@ns | | |
|
||||
| | WiFi | | |
|
||||
| | Firewall | | WikiNit |
|
||||
| | IPv6 | | NicolasDandrimont |
|
||||
| | La base LDAP | | |
|
||||
| | Virtualisation | | |
|
||||
| | Versionnement | | |
|
||||
| | Bcfg2 | | |
|
||||
| | Intranet 2 | | |
|
||||
| | DNS | | |
|
||||
| | TV + Multicast | | |
|
||||
| | GPG | | |
|
||||
| | Monitoring | | |
|
||||
| | Wiki | | |
|
||||
|
||||
### WiFi
|
||||
|
||||
Une séance de travail est prévue ce samedi 17 septembre à partir de 14h,
|
||||
venez au 2B. Les bornes actuelles se font de plus en plus vieilles, on envisage
|
||||
différentes bornes, mais elles ont besoin d'un firmware fonctionnel pour pouvoir
|
||||
être déployées.
|
||||
|
||||
Il faut d'abord considérer la mise à jour des bornes actuelles. "Il y a des
|
||||
chances
|
||||
que ça n'empire pas la situation."
|
||||
|
||||
### Nouvelle interface de gestion "gest_crans"
|
||||
|
||||
Olivier entreprend depuis un certain temps une mise à jour de l'outil gest_crans
|
||||
qui est le script que les câbleurs utilisent pour effectuer la gestion des
|
||||
adhérents.
|
||||
|
||||
Une idée envisagée est de passer à une interface client - serveur pour pouvoir
|
||||
faire plusieurs front-ends (intranet, script de gros geek, ...)
|
||||
|
||||
Olivier envisage de le faire tout simplement en HTTPS, avec un retour des
|
||||
données en JSON ou xml...
|
||||
|
||||
Valentin propose de faire une séance de travail sur le binding ldap afin de le
|
||||
rendre utilisable en conditions réelles. Elle aura lieu le 1er octobre.
|
||||
|
||||
### Connexion appartements
|
||||
|
||||
Ça marche mal. On a eu deux rapports de problème depuis le début du mois, encore
|
||||
non traités. Il faut prendre contact avec les habitants pour tester.
|
||||
|
||||
Olivier et Daniel sont volontaires pour s'en charger.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Configuration automatique du WiFi sous Windows
|
||||
|
||||
Valentin est en train d'investiguer netsh afin de proposer un outil automatique
|
||||
et graphique de configuration de la connexion WiFi sous Windows (XP, Vista, 7).
|
||||
|
||||
L'outil permettrait de configurer automatiquement la connexion WiFi sous ces OS,
|
||||
afin de simplifier le câblage des adhérents, et d'éviter les retours et la
|
||||
dégradation de l'expérience de câblage.
|
||||
|
|
@ -0,0 +1,98 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 29 Septembre 2011
|
||||
* Lieu : Amphi Condorcet
|
||||
* Début de la réunion : 19h21
|
||||
* Fin : 20h42
|
||||
|
||||
## Présents
|
||||
|
||||
* Benjamin Aupetit
|
||||
* Benjamin Schmitt
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Raphaël Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Xavier Lagorce
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### WiFi
|
||||
|
||||
Le workshop d'il y a 15 jours a été pas mal productif. On a des firmwares à peu
|
||||
près fonctionnels sur les deux types de bornes.
|
||||
|
||||
Pour les anciennes WRT54G:
|
||||
|
||||
* Multi SSID: impossible
|
||||
* Le reste fonctionne (sauf les bornes)
|
||||
* IPv6 non testé, pas de raison a priori que ca ne marche pas.
|
||||
|
||||
Pour les nouvelles:
|
||||
|
||||
* Tout marche, sauf...
|
||||
* récupérer de l'entropie sur la borne, car le réseau n'est pas une source sûre
|
||||
|
||||
d'entropie, et il n'y a pas d'autres sources disponibles. (urandom ou rng-tools)
|
||||
Ce problème est soluble (comme le café), et la mise en place ne devrait donc pas
|
||||
poser de problème majeur à partir de là.
|
||||
|
||||
Il faut maintenant faire des tests de couverture (genre au G), puis faire des
|
||||
devis pour le CA, assez rapidement, et aussi trouver où on peut les poser.
|
||||
|
||||
On propose un devis pour le CA de la semaine prochaine afin d'acheter des pico
|
||||
et nanostations qui ont le même chipset que les bullet dans un form factor
|
||||
vachement plus cool, pour tester.
|
||||
|
||||
### Séminaires
|
||||
|
||||
Le premier est mardi, les apprentis doivent venir et s'inscrire pour les
|
||||
suivants.
|
||||
|
||||
### Connexion des appartements
|
||||
|
||||
La connexion de la porterie a été rétablie. Le switch a bloupé.
|
||||
|
||||
La connexion au cournot est bugguée du côté DSI, selon les diagnostics d'Olivier
|
||||
(le vlan 21 sort de multiprise_wifi, et n'arrive manifestement pas au cournot).
|
||||
|
||||
Il faut relancer la DSI, Olivier s'en occupe.
|
||||
|
||||
### Déconnexion P2P
|
||||
|
||||
On a reçu un mail (forwardé) de la DSI nous informant d'un trafic bittorrent
|
||||
provenant d'une ip Cr@ns (celle d'un adhérent). Le mail provient d'une société
|
||||
américaine.
|
||||
|
||||
Les nounous font déjà leur possible pour bloquer le trafic bittorent. Les
|
||||
sanctions envers l'adhérent sont à décider par le CA.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Workshop scripts
|
||||
|
||||
La séance prévue Samedi prochain est déplacée au 08/10 pour cause
|
||||
d'indisponibilité générale.
|
||||
|
||||
#### Association MAC-IPv6
|
||||
|
||||
Récupérer les NA ne serait pas optimal pour faire cette association (risque
|
||||
d'usurpation), il serait bon de trouver une autre solution ou un colmatage.
|
||||
|
||||
On teste le DHCPv6.
|
||||
|
||||
#### Bornes du toit du J
|
||||
|
||||
Ca fait longtemps que l'on a promis au CROUS de mieux les fixer. On regarde si
|
||||
ce sont des habitants du G ou du J qui les utilisent.
|
||||
|
||||
#### Workshops
|
||||
|
||||
Le format des workshops permet d'avancer sur les services, mais permet-il la
|
||||
formation des nouveaux ?
|
||||
Daniel propose de lancer des "petits projets" sur des modules de l'intranet 2,
|
||||
qui permettent de toucher au LDAP, etc, tout en étant indépendants.
|
||||
|
|
@ -0,0 +1,190 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 13 Octobre 2011
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h14
|
||||
* Fin : 21h34
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Quelennec
|
||||
* Benjamin Aupetit
|
||||
* Daniel Stan
|
||||
* Judith Robson
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Raphaël Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vanessa Verbeke
|
||||
* Xavier Lagorce
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Wifi
|
||||
|
||||
#### Nouvelles bornes
|
||||
|
||||
Les nouvelles bornes sont arrivées mais (petite) déception: le chipset wifi
|
||||
n'est pas le même... Iota a réussi à compiler une image pour ces bornes et à
|
||||
booter dessus, il n'y a pas de raison que le WiFi ne fonctionne pas. D'ailleurs,
|
||||
il y a de l'entropie. Il y en a 3 autres à tester, avis aux volontaires.
|
||||
|
||||
Les tests de portée sont à effectuer. Il faut voir si ça passe en ligne droite
|
||||
(dans un couloir ?) puis entre les étages (car on a que deux locaux techniques
|
||||
au G...)
|
||||
|
||||
#### Audit de la couverture actuelle
|
||||
|
||||
Il faut parcourir le campus afin de récupérer l'état de la couverture wifi.
|
||||
On peut aussi essayer de faire des stats pour voir où les gens se connectent.
|
||||
|
||||
Daniel s'occupe de l'extérieur. Raphaël s'occupe de cartographier où les gens
|
||||
se connectent. Steven s'occupe de l'intérieur.
|
||||
|
||||
#### Bornes sur le toit du bâtiment J
|
||||
|
||||
Les bornes sur le toit du bâtiment J et arrosant le bâtiment G n'arrosent pas
|
||||
le bâtiment G... En effet, le revêtement des fenêtres empêche la propagation
|
||||
des ondes wifi. Des clients sont toutefois connectés sur ces bornes,
|
||||
il faudrait donc les laisser.
|
||||
|
||||
On ne peut pas les laisser en l'état (car elles sont "mal" accrochées), on a le
|
||||
choix entre les fixer correctement, installer d'autres bornes (nanostation ?)
|
||||
qui devront elles aussi être fixées correctement, ou ne rien mettre.
|
||||
|
||||
On va attendre le résultat des tests de couverture.
|
||||
|
||||
#### Détection des réseaux pirates
|
||||
|
||||
Il y a deux semaines et demi, un réseau WEP de SSID "Cr@ns" a été détecté sur le
|
||||
campus, émis par plusieurs MACs différentes. Le réseau était annoncé moins d'une
|
||||
minute à chaque fois.
|
||||
|
||||
Raphaël essaie d'utiliser les bornes WiFi afin de détecter l'origine du réseau
|
||||
bizarre.
|
||||
|
||||
### Workshop Scripts
|
||||
|
||||
Il n'a manifestement pas eu lieu. (On a trié des fiches d'adhésion/réadhésion.)
|
||||
On fait une première session jeudi 20 octobre pour vérifier le fonctionnement du
|
||||
nouveau binding LDAP et corriger les bugs manifestes.
|
||||
|
||||
### Proxy
|
||||
|
||||
* Caching des vidéos youtube : ce n'est pas possible facilement, il faudrait
|
||||
avoir un serveur Web "cache" à côté. De toute façon, le débit consommé n'est
|
||||
pas forcément si important que ça par rapport au reste du trafic.
|
||||
* (null)://toto : parfois, quand on charge une page, il arrive que le proxy
|
||||
retourne une erreur parce qu'elle essaie d'utiliser le protocole "(null)".
|
||||
C'est une erreur a priori liée au proxy transparent. Il faut que quelqu'un
|
||||
prenne ses petits doigts musclés et écrive un bug report.
|
||||
* Pages pour les gens déconnectés pour virus : Michel propose que la page de
|
||||
déconnexion apporte plus d'informations notamment quant au virus. Pour ce
|
||||
faire, on pourrait faire une section dans l'intranet où on pourrait mettre
|
||||
les logs de déconnexion et les instructions à suivre pour désinfecter.
|
||||
|
||||
### Connexion des appartements de fonction
|
||||
|
||||
Le Cournot remarche, Iris ne marche plus.
|
||||
Il faut contacter la personne qui rencontre des problèmes afin de savoir ce
|
||||
qu'il en est. Il faudrait aussi en profiter pour leur dire de nous contacter
|
||||
directement et de nous tenir au courant quand ça refonctionne tout seul.
|
||||
On peut profiter de la campagne de réadhésion pour faire ça.
|
||||
|
||||
### Impression
|
||||
|
||||
Daniel a modifié l'interface d'impression, entre autres pour la rendre plus
|
||||
stricte. Elle n'accepte plus les dimensions exotiques, ce afin d'éviter les
|
||||
affiches occupant 1/100e de la page.
|
||||
|
||||
On va utiliser le biniou d'adg qui se connecte à l'interface d'impression
|
||||
directe.
|
||||
|
||||
#### Problèmes avec l'imprimante
|
||||
|
||||
Il faut contacter print platinium pour
|
||||
|
||||
* échanger les rouleaux
|
||||
* échanger l'imprimante
|
||||
* échanger de partenaire *kof* *kof*
|
||||
|
||||
### DHCPv6
|
||||
|
||||
Personne ne s'est occupé de tester le DHCPv6. Il est décidé de le configurer en
|
||||
utilisant les adresses IP d'autoconfiguration, pour des questions de simplicité
|
||||
du firewall.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Communication
|
||||
|
||||
Il faudrait faire, à chaque inter-nounou, ''vraiment'' faire un bilan de ce qui
|
||||
a été fait. Ça permettrait d'avoir une trace écrite.
|
||||
|
||||
Nicolas propose que chacun tienne un journal de bord, afin d'écrire au jour le
|
||||
jour ce que chacun a fait au Cr@ns. Ensuite, on fait une synthèse lors des
|
||||
internounous.
|
||||
|
||||
#### Mises à jour vers squeeze
|
||||
|
||||
Il faut continuer. Le support de sécurité de lenny s'arrête en février 2012.
|
||||
|
||||
Michel se propose d'encadrer les bonnes âmes voulant s'en charger. Aurore se
|
||||
porte volontaire.
|
||||
|
||||
#### Install-party
|
||||
|
||||
L'install-party campus aura lieu le 19 novembre. La vraie aura lieu le 14
|
||||
janvier.
|
||||
|
||||
Il faut que quelqu'un pense à mettre à jour le netboot avant l'install-party (et
|
||||
non pendant...).
|
||||
|
||||
On peut graver des CD d'Ubuntu.
|
||||
|
||||
#### Réunion avec la DSI
|
||||
|
||||
Il faut prévoir rapidement une réunion avec la DSI, pour parler de :
|
||||
|
||||
* Gigabit
|
||||
* Connexion des appartements
|
||||
* Rationnalisation de la connexion Cr@ns-ENS
|
||||
* WiFi
|
||||
|
||||
Le RTC est volontaire.
|
||||
|
||||
#### Inondation, comment redémarrer les serveurs
|
||||
|
||||
Premier problème : les nounous ne savent pas dans quel ordre redémarrer les
|
||||
serveurs. Deuxième problème : même avec une nounou qui sait dans quel ordre
|
||||
redémarrer les serveurs, un redémarrage prend une bonne heure, alors qu'il
|
||||
pourrait être beaucoup plus rapide.
|
||||
|
||||
Un ordre de redémarrage des serveurs doit être écrit, rapidement.
|
||||
|
||||
Une solution plus pérenne serait de décrire les dépendances entre services dans
|
||||
un init script lancé très tôt et qui attendrait de pouvoir se connecter aux
|
||||
services en question avant de continuer le boot. Un script de la même espèce que
|
||||
"attendre-vert", mais 2.0.
|
||||
|
||||
Une autre solution serait de faire un "maître d'orchestre" qui autorise les
|
||||
serveurs à booter séquentiellement.
|
||||
|
||||
Judith se porte volontaire.
|
||||
|
||||
#### Comment éviter les problèmes à base de 0.0.0.0
|
||||
|
||||
Un adhérent a décidé de mettre une adresse ip 0.0.0.0, ce qui a beaucoup
|
||||
perturbé la détection de conflits d'adresse ip de windows.
|
||||
|
||||
Michel voudrait qu'une adresse ip bidon soit mise en place, qui n'est pas
|
||||
vraiment
|
||||
utilisée, et qui soit utilisée pour détecter des comportements bizarres :
|
||||
|
||||
* Si une machine répond aux requêtes ARP pour cette machine, elle se comporte
|
||||
bizarrement
|
||||
* Si une machine essaie de se connecter à l'ip bidon, la machine se comporte
|
||||
bizarrement
|
||||
|
|
@ -0,0 +1,176 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 3 novembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h19
|
||||
* Fin : 21h08
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Raphaël Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Valentin Samir
|
||||
* Vanessa Verbeke
|
||||
* Vincent Maïoli
|
||||
* Xavier Lagorce
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Encadrement des apprentis
|
||||
|
||||
Selon le règlement intérieur du Cr@ns, chaque apprenti doit avoir une Nounou qui
|
||||
l'encadre et qui est responsable de lui.
|
||||
|
||||
Les absents ayant toujours tort, on va assigner des encadrants de force :
|
||||
|
||||
* Benjamin A. sera encadré par Nicolas D.
|
||||
* Julien sera encadré par Raphaël
|
||||
* Sylvain sera encadré par Olivier
|
||||
* Yann sera encadré par Valentin
|
||||
* Johan sera encadré par Michel
|
||||
* Jonathan sera encadré par Raphaël
|
||||
* Vincent L.G. sera encadré par Daniel
|
||||
* Steven sera encadré par Nicolas D.
|
||||
* Aurore MM. sera encadré par Raphaël
|
||||
* Luc sera encadré par Vincent M.
|
||||
* Aurore Q. sera encadrée par Michel
|
||||
* Judith sera encadrée par Michel
|
||||
* Vanessa sera encadrée par Xavier
|
||||
* Larissa sera encadrée par Olivier
|
||||
* Pierre-Elliott sera encadré par Daniel
|
||||
|
||||
### STEF
|
||||
|
||||
Un représentant du STEF est venu il y a 2 semaines à la réunion CA pour proposer
|
||||
au Cr@ns de participer à leur cycle de séminaires en faisant une présentation,
|
||||
par exemple sur le logiciel libre.
|
||||
|
||||
Il n'y a pas de volontaires.
|
||||
|
||||
### Astreintes des nounous
|
||||
|
||||
Chaque jour ouvré, les Nounous sont d'astreinte pour aider les câbleurs en cas
|
||||
de problème. On a fini de remplir le planning de permanences.
|
||||
|
||||
### Munin
|
||||
|
||||
Dyson a été mis à jour vers squeeze grâce à Vincent et Sylvain. La config de
|
||||
munin a été copiée sur Dyson, qui a fonctionné 24h avant de planter...
|
||||
Apparement, cela ne marchait pas beaucoup plus vite (problème de config ?) que
|
||||
sur le DomU.
|
||||
|
||||
On peut regarder soit du côté de munin 2 qui serait plus efficace, soit on peut
|
||||
essayer de reprendre à zéro, en prenant peut-être un autre outil de monitoring.
|
||||
|
||||
### Recrudescence du peer-to-peer
|
||||
|
||||
On a reçu ces derniers temps plusieurs mails de la DSI à propos de machines
|
||||
faisant du p2p, ce qui a mis en évidence un problème au niveau du firewall, dû à
|
||||
deux problèmes : la partition de /var/log était plein, ce qui empêchait les
|
||||
scripts de voir qui fait du p2p; et au niveau du firewall, les paquets n'étaient
|
||||
pas bloqués.
|
||||
|
||||
Pour ce qui s'agit des logs du syslog refiltrés derrière, on réfléchit à une
|
||||
solution pour ne pas avoir à écrire des logs.
|
||||
|
||||
Olivier s'occupe d'envoyer un mail à la DSI.
|
||||
|
||||
### WiFi
|
||||
|
||||
#### Audit de la couverture
|
||||
|
||||
Raphaël et Steven se sont baladés dans le bâtiment B pour chercher les zones
|
||||
d'ombre. C'est surtout à l'aile du 3e étage que la couverture est mauvaise.
|
||||
|
||||
Daniel a commencé à coder une interface en Open Layers pour afficher et
|
||||
enregistrer les données de couverture.
|
||||
|
||||
#### Mise à jour des bornes
|
||||
|
||||
Nicolas a fait un firmware à jour qui fonctionne pour les anciennes bornes, et
|
||||
qui règle le problème du cache des authentifications ratées. Il faudrait le
|
||||
déployer sur toutes les bornes.
|
||||
|
||||
#### Configuration automatique des bornes
|
||||
|
||||
Avant, les bornes récupéraient automatiquement leur configuration. On peut
|
||||
profiter de la mise à jour à faire pour se pencher sur le sujet.
|
||||
|
||||
### Script de détection des déménagements
|
||||
|
||||
/usr/scripts/surveillance/demenagement.py à remettre en marche sur les serveurs
|
||||
radius.
|
||||
|
||||
### Choses à faire au Cr@ns
|
||||
|
||||
Il y a plein de choses à faire au Cr@ns, et les jeunes ne se motivent pas trop
|
||||
pour se pencher dessus, parfois par manque de connaissances.
|
||||
|
||||
Olivier propose de faire une liste des choses à faire sous forme d'arbre. Ça
|
||||
rejoint l'idée de faire un recensement de tous les services sur chacun des
|
||||
serveurs.
|
||||
|
||||
Les choses à faire ne sont pas forcément de nouveaux services à mettre en place,
|
||||
mais aussi des petits problèmes au jour le jour à régler, ce qui est souvent
|
||||
fait par les mêmes personnes. Il faudrait que les plus jeunes se sentent plus
|
||||
impliqués.
|
||||
|
||||
Le problème du tracker est qu'il est trop complexe, et accessible principalement
|
||||
par l'interface web, et aussi par mail. Nicolas propose d'utiliser debbugs.
|
||||
|
||||
Ça peut aussi être bien d'avoir un bot IRC permettant de signaler facilement via
|
||||
IRC les bugs (et d'enregistrer les dernières lignes).
|
||||
|
||||
Bug n°2 : Il faudrait mettre à jour l'ensemble des documentations disponibles
|
||||
sur le Wiki.
|
||||
|
||||
Par ailleurs, pour les gros projets, il faut que les apprentis soient mieux
|
||||
encadrés, quitte à ce que la Nounou s'implique dans le projet et y participe.
|
||||
|
||||
### DHCPv6
|
||||
|
||||
Sylvain s'est penché sur la question, et n'a trouvé aucun serveur DHCPv6 qui
|
||||
fasse de l'EUI64 (ce qui paraît logique en soi). Deux solutions sont possibles :
|
||||
|
||||
* Générer un fichier de configuration statique, comme pour l'IPv4
|
||||
* Recoder un serveur DHCPv6, qui filtre les machines à qui elle donne des IPs
|
||||
(cette solution est celle préconisée par Sylvain)
|
||||
|
||||
### Utilisation du 2B
|
||||
|
||||
On a constaté qu'au 2B, il y a souvent du monde, mais très peu de productivité
|
||||
dans l'air. L'idée est d'établir des règles. Dans un premier temps, on va en
|
||||
discuter, et les appliquer si nécessaire.
|
||||
|
||||
L'idée est néanmoins de poser des "grands principes" par écrit, et de voir si la
|
||||
situation s'améliore. On pourrait passer aux règles si aucune amélioration n'est
|
||||
constatée, mais ce n'est pas la première chose à faire.
|
||||
|
||||
Les afficher au 2B en A4 quelque part.
|
||||
|
||||
On veut garder le 2B dans un état propre (tout est relatif)... pas trop sale.
|
||||
|
||||
On va écrire des grands principes d'utilisation du 2B, deadline : la prochaine
|
||||
inter-nounous.
|
||||
|
||||
### Workshop Scripts
|
||||
|
||||
Il n'a pas vraiment eu lieu, mais des gens se sont penchés sur les scripts.
|
||||
Vincent a commencé à documenter les scripts. Valentin s'est penché sur la base
|
||||
LDAP, d'une part pour l'optimisation des méthodes qui prennent du temps, et
|
||||
d'autre part sur la cohérence des données entre la base réelle et les checks
|
||||
faits par le binding. Les commits sont sur git.crans.org .
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Séminaire OCaml / Ocsigen
|
||||
|
||||
Dr. Chicco a proposé d'organiser un séminaire sur OCaml et Ocsigen, et voulait
|
||||
savoir si il y avait des personnes intéressées. On peut voir pour en faire un
|
||||
(ou plusieurs) séminaire(s) "grand public", de même qu'avec LaTeX, etc. À faire
|
||||
de préférence avant les départs en stage.
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 17 novembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h08
|
||||
* Fin : 20h50
|
||||
|
||||
## Présents
|
||||
|
||||
* Anne Cazalet
|
||||
* Aurore Moisy-Mabille
|
||||
* Benjamin Aupetit
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vanessa Verbeke
|
||||
* Xavier Lagorce
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Synaps System
|
||||
|
||||
Anne Cazalet est présente pour rencontrer la nouvelle équipe (RTC, bureau).
|
||||
On en profite pour discuter des prochains investissements de l'association en
|
||||
termes de matériel (remplacement de la caméra du 0B, renouvellement des
|
||||
garanties,
|
||||
renouvellement du backbone, ...)
|
||||
|
||||
### Câblage des chambres
|
||||
|
||||
#### Prises défectueuses
|
||||
|
||||
Plusieurs chambres du campus (environ 3) ont des problèmes matériels de câblage
|
||||
(prises arrachées, ...). En dehors de la question de ce que le Cr@ns doit faire
|
||||
à ce propos, il reste que des adhérents n'ont pas de connexion (et le Crous ne
|
||||
le fera pas), et il s'agit de petits travaux. Il est plus agréable de le faire à
|
||||
2 personnes, et c'est réalisable par des apprentis/câbleurs/...
|
||||
|
||||
#### Câblage vers le CROUS
|
||||
|
||||
Daniel a été contacté directement par MyStream Mardi pour des soucis de câblage
|
||||
des clients MyStream, qui n'étaient pas branchés sur les bons switchs : il ne
|
||||
faudrait pas les câbler sur les switchs marqués "Master". Ceci n'étant écrit
|
||||
nulle part, Daniel a demandé un plan de brassage pour chaque bâtiment. Il a
|
||||
aussi demandé s'il était possible d'éteindre les switchs non utilisés (problème
|
||||
de ventilation au M par exemple). Une réponse était annoncée pour Mercredi, il
|
||||
n'y a toujours rien.
|
||||
|
||||
### WiFi
|
||||
|
||||
C'est l'occasion de faire un point.
|
||||
Olivier indique que tout semble marcher a priori, mais qu'une batterie de tests
|
||||
est à faire pour s'en assurer. Il faut aussi les configurer totalement pour les
|
||||
adapter au réseau Cr@ns.
|
||||
|
||||
Daniel a réussi a flasher des anciennes bornes marquées comme HS, elles
|
||||
marchaient. Puis elles ne marchaient plus. Il recherche.
|
||||
|
||||
### Séminaires
|
||||
|
||||
Nicolas se demande comment améliorer/remplacer de façon bénéfique les
|
||||
séminaires. Il soulève le problème de l'attention du public en séminaire.
|
||||
Question ouverte.
|
||||
|
||||
### Apprentis
|
||||
|
||||
Il est proposé la mise en place d'une liste des compétences nécessaires au bon
|
||||
exercice de la fonction de nounou (administration système, réseau, ...).
|
||||
|
||||
Cette liste sera mise en place collégialement et classée par ordre de pertinence
|
||||
par la suite.
|
||||
|
||||
### Proxy
|
||||
|
||||
Après une rapide étude, Squid semble n'être pas très utile.
|
||||
|
||||
* logging: ca marche, mais on peut le faire ailleurs
|
||||
* mise en cache: ce serait bien, mais c'est pas extraordinaire
|
||||
* deconnexion soft: il suffit de mettre une regle dans le firewall pour
|
||||
rediriger les adherents vers une page de l'intranet
|
||||
* ca complique la QoS: c'est pour ça qu'il faut le brûler
|
||||
|
||||
Daniel demande des nombres pour finir de juger de l'utilité de Squid.
|
||||
Nicolas fait remarquer qu'empiriquement, ça marche mieux quand Squid est down.
|
||||
|
||||
Valentin s'en occupe.
|
||||
|
||||
### Firewall Ipv6
|
||||
|
||||
ip6tables-restore v1.4.8: Couldn't load
|
||||
target `BLACKLIST_SRC':/lib/xtables/libip6t_BLACKLIST_SRC.so: cannot open
|
||||
shared object file: No such file or directory
|
||||
|
||||
On ne sait pas qui brûler. Le script qui génère le firewall va être remis à son
|
||||
état précédent grâce à darcs par Daniel.
|
||||
|
||||
### Réunion avec la DSI
|
||||
|
||||
Hier a eu lieu une réunion avec Stuart, Daniel, Valentin, Olivier, Sabrina,
|
||||
Vincent M. Stuart a présenté les prochains projets de l'école (renouvellement de
|
||||
matériel, ..., virer IRTS à long terme).
|
||||
|
||||
Stuart va demander un devis à Orange pour laisser au personnel le choix entre le
|
||||
Cr@ns et Orange, car la qualité n'est pas suffisante à son goût.
|
||||
|
||||
Stuart a contourné le sujet du Gigabit.
|
||||
|
||||
Il a été question du traffic shaping. Il faut tester ça sur le réseau du Cr@ns
|
||||
pour démontrer à la DSI que l'on peut le faire nous même et qu'IRTS est donc
|
||||
inutile.
|
||||
|
||||
On est censé pouvoir acceder à l'interface de demande de travaux. C'est à
|
||||
tester.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Vlan accueil
|
||||
|
||||
Daniel propose que l'intranet soit accessible depuis le vlan accueil, pour que
|
||||
l'adherent puisse ajouter lui même sa nouvelle machine.
|
||||
|
||||
#### Switchs
|
||||
|
||||
Les switchs ne sont pas à l'heure, c'est donc que le serveur NTP est mal
|
||||
indiqué.
|
||||
Il faut réparer ça.
|
||||
|
||||
Il existe une pile de switchs garantis à vie qui sont HS, à côté de vo. Il faut
|
||||
les mettre à jour et contacter HP pour les faire remplacer. Pour cela, il faut
|
||||
prévoir une journée.
|
||||
|
||||
Benjamin s'en occupe.
|
||||
|
||||
#### Install-Party
|
||||
|
||||
Le boot PXE est à jour.
|
||||
|
||||
L'IP est après-demain, venez !
|
||||
|
||||
#### Mise à jour des bornes
|
||||
|
||||
Daniel a testé l'image compilée par Nicolas avec backfire et le driver libre,
|
||||
pour les linksys : ca à l'air de bien marcher. Comme les nouvelles bornes, il
|
||||
faut finir de les configurer et les tester.
|
||||
|
||||
C'est l'occasion de déployer un système pour que les bornes récupèrent leur
|
||||
configuration toutes seules, rebootent régulièrement et se mettent à l'heure.
|
||||
|
||||
Daniel propose aussi que les bornes arrêtent de diffuser le SSID Cr@ns quand
|
||||
elles n'ont pas de réseau et qu'elles diffusent à la place un SSID de debug
|
||||
pour qu'on puisse encore s'y connecter.
|
||||
|
||||
#### Imprimante
|
||||
|
||||
Michel a tenté de les contacter Mercredi pour qu'un technicien passe, mais il
|
||||
n'a eu aucun interlocuteur.
|
||||
|
||||
On peut leur demander de changer l'imprimante car cela fait 2 ans et demi qu'on
|
||||
l'a. Il faut voir si c'est utile.
|
||||
|
||||
Le rouleau des feuilles A3 pose problème, il faudrait demander à ce qu'il soit
|
||||
changé.
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 1er Decembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h17
|
||||
* Fin : 20h27
|
||||
|
||||
## Présents
|
||||
|
||||
* Benjamin Aupetit
|
||||
* Daniel Stan
|
||||
* Michel Blockelet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Xavier Lagorce
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### DSI-Cr@ns
|
||||
|
||||
#### Connexion des appartements
|
||||
|
||||
La DSI a rebasculé la connexion des appartements de fonction vers la connexion
|
||||
Cr@ns, après l'avoir mise sur la connexion publique ENS sans nous prévenir.
|
||||
|
||||
#### Lien Gigabit
|
||||
|
||||
Il faut négocier avec la DSI pour avoir un lien Gigabit rapidement. Cela
|
||||
permettrait
|
||||
un accès plus rapide aux ENT.
|
||||
|
||||
#### Chambres au Pavillon des Jardins
|
||||
|
||||
La DSI nous demande si c'est possible de câbler certaines chambres du PdJ sur le
|
||||
réseau public de l'ENS. Il faut demander à la DSI pourquoi, sachant que les
|
||||
visiteurs
|
||||
en question (chercheurs, ...) ont toujours été connectés grâcieusement au réseau
|
||||
du Cr@ns si leur durée de séjour était raisonnable (<= 1 mois en général).
|
||||
|
||||
#### Plans du réseau
|
||||
|
||||
Il faut demander à la DSI une interconnexion rationnelle (i.e. une seule fibre
|
||||
et pas 2 dont une reliée à un switch quelconque au d'Alembert Centre).
|
||||
|
||||
Le plan du réseau du Cr@ns n'a pas été mis à jour suite à la mise en étoile des
|
||||
bâtiments. Daniel va s'en occuper.
|
||||
|
||||
### Maintenance générale
|
||||
|
||||
#### Mise à jour vers squeeze
|
||||
|
||||
Il ne reste plus que quelques serveurs à mettre à jour, il faut le faire.
|
||||
Michel va voir avec Aurore pour finir ça.
|
||||
|
||||
#### Bcfg2
|
||||
|
||||
Plein de fichiers de config sont désynchronisés avec le serveur Bcfg2.
|
||||
|
||||
Il faut remotiver les gens à mettre la config dans bcfg2 et pas sur chaque
|
||||
serveur, et aussi à packager des trucs existants :
|
||||
|
||||
* {{{/etc/cron.d/CRANS}}}
|
||||
* {{{/etc/init.d/purge_les_locks_nfs_connard}}}
|
||||
* ...?
|
||||
|
||||
#### Scripts
|
||||
|
||||
Le nouveau binding ldap est utilisable a priori. Il est possible de s'en servir
|
||||
pour écrire de nouveaux scripts, ou nettoyer des scripts existants.
|
||||
|
||||
#### Divers
|
||||
|
||||
### Monitoring
|
||||
|
||||
#### Monitoring des serveurs
|
||||
|
||||
Munin ne marche toujours pas. La situation n'a pas évolué depuis la dernière
|
||||
réunion, il faut que quelqu'un prenne ses petits pieds et aille au 0B appuyer
|
||||
sur un bouton pour redémarrer dyson. Daniel s'en charge.
|
||||
|
||||
#### Utilisation du réseau
|
||||
|
||||
It's over 9000%.
|
||||
Nicolas a
|
||||
fait [une weathermap qui marche](http://perso.crans.org/dandrimont/weathermap/weathermap.png)
|
||||
avec MRTG. MRTG récupère les données en SNMP sur komaz et le backbone toutes les
|
||||
5 minutes et les met dans un fichier pour munin, et un script PHP dessine le
|
||||
graphe.
|
||||
|
||||
Benjamin se propose pour rendre tout ça plus joli et plus complet (switchs dans
|
||||
les bâtiments, ...).
|
||||
|
||||
#### Firewall
|
||||
|
||||
Valentin a fait plein de modifications sur le firewall dernièrement. En faisant
|
||||
des modifications pour détecter les trackers bittorrent en http, il s'est rendu
|
||||
compte que le filtre ipp2p n'était pas utilisé correctement (les paquets
|
||||
détectés
|
||||
sont en effet assez souvent dans des paquets au cours de connexion et pas dans
|
||||
les paquets d'initiation). Le filtre a été mis au bon endroit et plus de gens
|
||||
ont été déconnectés.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### P2P
|
||||
|
||||
Utilisation de OpenDPI à la place de ipp2p. La documentation est très éparse.
|
||||
On regarde si ca vaut le coup.
|
||||
|
||||
#### Formation interne
|
||||
|
||||
La liste de compétences suggérée la semaine dernière doit toujours être mise en
|
||||
place. Il est décidé de faire cela collégialement sur gobby (fichier
|
||||
"competences").
|
||||
|
||||
Les nounous et anciennes nounous sont vivement incitées à contribuer à ce
|
||||
document.
|
||||
|
||||
#### Squid
|
||||
|
||||
Squid est maintenant bypassé sur sable, hormis pour les déconnexions soft. Il
|
||||
reste ce problème, ainsi que la connexion de secours qui ne fonctionne plus
|
||||
automatiquement.
|
||||
|
||||
#### Repas Federez
|
||||
|
||||
C'est Samedi, 12h30, venez.
|
||||
|
||||
#### Imprimante
|
||||
|
||||
Pas d'avancées depuis 15 jours...
|
||||
Elle fait des traces moches, ça devient urgent de changer les tambours.
|
||||
|
|
@ -0,0 +1,196 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 15 Décembre 2011
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h16
|
||||
* Fin : 20h51
|
||||
|
||||
## Présents
|
||||
|
||||
* Antoine Durand-Gasselin
|
||||
* Benjamin Aupetit
|
||||
* Daniel Stan
|
||||
* Melissa Verbeke
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vanessa Verbeke
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### DSI-Cr@ns
|
||||
|
||||
Augustin et Olivier ont eu une réunion avec Sabrina Louison-François de la DSI,
|
||||
pour prévoir la simplification de l'interconnexion entre le réseau du Cr@ns et
|
||||
le réseau de l'ENS.
|
||||
|
||||
Cette opération aura lieu en semaine 52, a priori le 30/12. Daniel et Nicolas
|
||||
seront
|
||||
présents.
|
||||
|
||||
L'interconnexion retenue sera faite à l'aide d'un switch du côté ENS,
|
||||
interconnecté
|
||||
au backbone par l'actuelle fibre komaz<->irts. Cette connexion sera en gigabit,
|
||||
et fera passer les vlan 3 (wifi), 4 (wifi
|
||||
ens), 10 (évènementiel), 21 (appartements)
|
||||
et le vlan des serveurs DSI, auquel komaz pourra accéder. L'interconnexion avec
|
||||
le réseau de l'ens sera assurée via le nouveau switch bato-1.
|
||||
|
||||
L'actuelle fibre Multiprise_wifi<->D'Alembert-Centre serait alors inutilisée.
|
||||
|
||||
### Achat de matériel
|
||||
|
||||
#### Carte contrôleur baie de disques
|
||||
|
||||
La baie de disque étant un élément central de l'infrastructure du Cr@ns, il a
|
||||
été
|
||||
proposé lors de la dernière réunion d'investir dans une carte de contrôle
|
||||
supplémentaire.
|
||||
|
||||
La carte de contrôle actuelle étant bientôt en fin de vie, deux solutions
|
||||
s'offrent à nous :
|
||||
|
||||
* Acheter une nouvelle carte identique à l'actuelle
|
||||
* Ou acheter deux nouvelles cartes, récentes (garantie 3 ans au maximum)
|
||||
|
||||
Une décision raisonnable ne pourra être prise que lorsque les coûts des deux
|
||||
options auront été estimés.
|
||||
|
||||
#### Renouvellement du backbone
|
||||
|
||||
Notre backbone se fait vieux (2003). Anne nous proposera une offre dans le
|
||||
courant
|
||||
de la semaine prochaine. Une reprise de l'ancien est possible pour diminuer le
|
||||
coût du changement.
|
||||
|
||||
### Monitoring
|
||||
|
||||
Munin "refonctionne". Le graphing se traine le cul.
|
||||
|
||||
Il faut évaluer munin-2, qui serait apparemment over 9000 fois mieux que la
|
||||
version
|
||||
1.4 (CGI et graphing plus rapide, récupération des données plus légère, ...).
|
||||
|
||||
Une possibilité toujours en l'air est d'installer un outil du type de nagios,
|
||||
qui permettrait de regrouper en un coup d'oeil autostatus, monit et munin.
|
||||
Olivier
|
||||
propose d'encadrer ce projet. Vanessa est volontaire.
|
||||
|
||||
### Serveurs
|
||||
|
||||
#### Running gag : rouge
|
||||
|
||||
L'age de rouge est strictement croissant. Sa seule fonctionnalité pertinente est
|
||||
MX principal. Il y a du filtrage de contenu (amavis) et un serveur
|
||||
smtp (postfix).
|
||||
|
||||
Ces services devaient être migrés sur redisdead, mais les nounous ont peur que
|
||||
la charge due à amavis le fasse s'écrouler.
|
||||
|
||||
Étapes de la migration :
|
||||
|
||||
* Configurer amavis sur redisdead
|
||||
* Configurer l'authentification des clients
|
||||
* Vérifier que tout ça tient la charge
|
||||
* Modifier les DNS
|
||||
* Jeter rouge du 6B
|
||||
|
||||
#### Mises à jour vers squeeze
|
||||
|
||||
La fin de vie de lenny aura lieu, comme à chaque release de Debian, un an après
|
||||
la release de squeeze... Soit le 6 février 2012.
|
||||
|
||||
Il reste à migrer zamok, gordon et 3 domU (titanic, ldap, niomniom). Ceci en
|
||||
supposant
|
||||
que le point précédent, qui n'a été attribué à personne, va s'effectuer par
|
||||
magie.
|
||||
|
||||
##### niomniom
|
||||
|
||||
adg se propose pour encadrer la mise à jour du wiki. Steven se porte volontaire.
|
||||
|
||||
##### "vert"
|
||||
|
||||
La mise à jour de LDAP va être passionnante : la conversion automatique vers le
|
||||
nouveau format de configuration fonctionne de manière quantique.
|
||||
|
||||
Le nouveau format de configuration est en fait un annuaire LDAP, ce qui permet
|
||||
la modification et la synchronisation sans downtime des configurations et
|
||||
schémas.
|
||||
L'ancien format de configuration en fichiers plats n'est plus disponible dans la
|
||||
version squeeze de slapd.
|
||||
|
||||
À prendre en compte avant de faire la mise à jour :
|
||||
|
||||
* éviter que les mails ne bouncent à cause d'un utilisateur
|
||||
inexistant (soft_bounce = yes dans la configuration de postfix)
|
||||
* s'assurer que tous les services arrivent toujours à se connecter à la base
|
||||
ldap (postfix, dovecot, intranet, authentification...)
|
||||
* s'assurer du bon fonctionnement de la réplication
|
||||
|
||||
Il y a une config de réplicat correcte sur sable, il est envisageable de la
|
||||
convertir en config de master pour l'utiliser sur vert sans trop de dommages.
|
||||
|
||||
##### titanic
|
||||
|
||||
Deux points importants :
|
||||
|
||||
* connexion des appartements
|
||||
* connexion de secours
|
||||
|
||||
Ces deux services étant morts actuellement, faire la mise à jour de titanic ne
|
||||
devrait
|
||||
pas avoir trop d'impact...
|
||||
|
||||
##### gordon
|
||||
|
||||
Cf. plus bas.
|
||||
|
||||
### Maintenance générale
|
||||
|
||||
Le RTC se porte volontaire pour améliorer la configuration de logcheck, afin
|
||||
qu'il
|
||||
reçoive plus de mails avec des logs et moins de mails d'erreur.
|
||||
|
||||
Il est évoqué la possibilité de mettre en place un serveur syslog centralisé.
|
||||
Avant de se lancer là dessus, il faut planifier proprement comment seront
|
||||
stockés
|
||||
les logs. Il faut aussi penser à la durée de rétention des logs...
|
||||
|
||||
### WiFi
|
||||
|
||||
Les mises à jour des bornes vers backfire ont été faites. Il faut mettre à jour
|
||||
gordon. Cela permettra aussi d'utiliser les nouvelles fonctionnalités de
|
||||
freeradius,
|
||||
en particulier les possibilités de logging (client<->borne etc.).
|
||||
|
||||
Cette mise à jour doit être faite avec le plus grand soin, car la config de
|
||||
freeradius
|
||||
est une bête poilue, surtout pour le wifi, avec une configuration pour les
|
||||
postes
|
||||
linux et une pour les clients windows.
|
||||
|
||||
Les nouvelles bornes reçues (pico/nano)station fonctionneraient out of the
|
||||
box...
|
||||
Les gens ayant testé ça mardi ont eu la flemme de faire make, parce qu'ils
|
||||
avaient
|
||||
faim et/ou soif. iota propose de s'en occuper après la réunion.
|
||||
|
||||
### Ajout de droits
|
||||
|
||||
nounous.append("Sylvain")
|
||||
commit()
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Vacances
|
||||
|
||||
Remplissez la page idoine, merci. Il faut des clés du 0B proches du campus à
|
||||
tout
|
||||
moment.
|
||||
|
||||
#### Mises à jour de switchs Gigabit
|
||||
|
||||
Benjamin est volontaire.
|
||||
|
|
@ -0,0 +1,140 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 12 Janvier 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 21h01
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Raphaël Cauderlier
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Achat de nouveau matériel
|
||||
|
||||
#### Backbone
|
||||
|
||||
#### Carte de contrôle pour la baie de disques
|
||||
|
||||
### Interconnexion DSI-Cr@ns
|
||||
|
||||
La nouvelle interconnexion est en place depuis le 29 décembre. Olivier fait un
|
||||
schéma de l'ancienne interconnexion au tableau, avec IRTS.
|
||||
|
||||
En résumé :
|
||||
|
||||
* Un nouveau switch bato-1 à l'autocom, qui fait l'interconnexion entre
|
||||
* le backbone (vlan 1, 2, 3, 4, 10, 21, 1132 - zrt)
|
||||
* le réseau de l'ENS (vlan 3, 4, 10, 21, 1132 - zrt)
|
||||
* le Pavillon des Jardins (vlan 1, 2, 3, 4, 10?, 21)
|
||||
* les appartements de la porterie (vlan 1, 2 - pour bato-1, 21)
|
||||
* Nouvelle interconnexion 0B - Autocom: 3 paires de fibre, dont une pour le
|
||||
bâtiment G en direct, une pour bato-1, et une libre (branchée sur bato-1 à
|
||||
l'autocom)
|
||||
* Suppression de l'interconnexion 0B - d'Alembert Centre qui était foireuse et
|
||||
génératrice de boucles difficiles à débugguer
|
||||
|
||||
#### Traffic Shaping
|
||||
|
||||
L'agrément RENATER de l'ENS étant pour 100Mb/s, le Cr@ns a mis en place du
|
||||
traffic
|
||||
shaping pour limiter son débit entrant et sortant.
|
||||
|
||||
La QoS est désactivée pour le trafic vers le réseau ENS dans le pare-feu.
|
||||
|
||||
Il faut réfléchir à une méthode pour shaper le trafic dynamiquement (n Mb/s la
|
||||
journée, p Mb/s la nuit). Valentin propose de modifier config.py pour que le
|
||||
débit max dépende de l'heure, et un cron pour régénérer la chaîne MANGLE qui
|
||||
assigne les classes au trafic.
|
||||
|
||||
Il va mettre le cron en place rapidement, ce qui permettra de toute façon de
|
||||
régénérer les classes de QoS de temps en temps. Apparemment il y aurait déjà un
|
||||
cron de ce type en place.
|
||||
|
||||
### Migration des /home
|
||||
|
||||
Les /home ont été migrés aussi le 29 décembre, quitte à avoir une interruption
|
||||
de service...
|
||||
|
||||
La partition était en place, il suffisait de désactiver les services, un dernier
|
||||
rsync et de remplacer la partition dans le fstab.
|
||||
|
||||
### Logs
|
||||
|
||||
Une partition assez volumineuse vient d'être libérée. Une idée serait de s'en
|
||||
servir pour centraliser les logs des serveurs et des domU.
|
||||
|
||||
À cette fin, il serait possible de réutiliser un serveur physique inutilisé, par
|
||||
exemple ragnarok.
|
||||
|
||||
Sylvain regarde ce dont on a besoin précisément d'ici la prochaine réunion.
|
||||
|
||||
### Bornes wifi PicoStation
|
||||
|
||||
Adg a une config qui devrait marcher. Olivier l'a flashée sur une borne, ça
|
||||
fonctionne, il faut attendre assez longtemps que ça reboote.
|
||||
|
||||
Reste à faire :
|
||||
|
||||
* vlan (pour pouvoir remettre des bornes en zone ENS)
|
||||
* multi-ssid
|
||||
* tests de portée
|
||||
* tests de débit/charge
|
||||
|
||||
Sur les wrt54g:
|
||||
<http://wiki.openwrt.org/_detail/toh/linksys/wrt54_internal_architecture.png?id=toh%3Alinksys%3Awrt54gi>
|
||||
|
||||
Olivier envisage de faire des trucs là dessus samedi.
|
||||
|
||||
### Monitoring
|
||||
|
||||
Munin a été migré sur dyson il y a quelques temps, la génération des graphes
|
||||
est lente, mais fonctionne. Une nouvelle version de munin va sortir (elle est
|
||||
en bêta stable depuis un an). La génération des graphes a été optimisée et on
|
||||
peut zoomer sur les graphes en temps réel. Le protocole de communiation a aussi
|
||||
été amélioré :
|
||||
avant, le serveur munin contactait tous les noeuds leur demandant de générer
|
||||
les données ; maintenant, les serveurs ont un agent qui génère les données en
|
||||
continu. La première phase serait de mettre à jour munin sur le serveur (c'est
|
||||
backwards-compatible). Nicolas a fait un backport. Il faut ensuite vérifier si
|
||||
ça fonctionne, si c'est rapide.
|
||||
|
||||
Si tout ça se passe bien, il y a moyen de faire des trucs marrants sur les
|
||||
clients.
|
||||
|
||||
### Questions Diverses
|
||||
|
||||
#### Load balancing DNS
|
||||
|
||||
Valentin propose de configurer le DHCP de telle manière à annoncer
|
||||
alternativement sila et sable en serveur DNS.
|
||||
|
||||
Il faut mettre en place du monitoring de bind (via munin qui fonctionne, par
|
||||
exemple)
|
||||
pour voir si c'est vraiment nécessaire.
|
||||
|
||||
#### TFTP sur sable
|
||||
|
||||
Il faut le mettre sur une partition séparée, pour éviter de remplir le /var de
|
||||
sable...
|
||||
|
||||
Le proxy transparent ayant été dégagé, plein d'espace disque est disponible.
|
||||
Il serait aussi potentiellement intéressant de mettre un RAID. Sinon, Valentin
|
||||
se porte volontaire pour faire la réinstall de sable from scratch si un disque
|
||||
plante.
|
||||
|
||||
#### batp-3
|
||||
|
||||
Il est allumé, il ne ventile plus, il clignote rouge. Il faut appeler HP pour
|
||||
le faire échanger.
|
||||
|
||||
#### Imprimante
|
||||
|
||||
Nicolas trouve que Print Platinium est désespérant
|
||||
|
|
@ -0,0 +1,144 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 26 janvier 2012
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h16
|
||||
* Fin : 20h35
|
||||
|
||||
## Présents
|
||||
|
||||
* Anne Cazalet
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
|
||||
## Présent par internet
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Daniel Stan
|
||||
* Raphaël Cauderlier
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Achat de matériel
|
||||
|
||||
Anne Cazalet nous fait ses propositions sur les éléments que nous avions
|
||||
demandé.
|
||||
|
||||
#### Imprimante
|
||||
|
||||
Anne Cazalet nous propose une imprimante HP CM6030 ou CM6040 en achat comptant,
|
||||
et va aussi communiquer nos coordonnées à un prestataire de leasing avec des
|
||||
imprimantes Xerox (Alex Panahi), afin que nous puissions comparer les deux
|
||||
propositions.
|
||||
L'imprimante coûterait environ 9000€ (prix public).
|
||||
|
||||
#### Onduleur
|
||||
|
||||
L'onduleur est en fin de garantie, Anne va nous envoyer une proposition pour
|
||||
la prolonger, c'est à dire ajouter un an + un an, et par la suite envisager de
|
||||
passer
|
||||
sous un contrat de maintenance pièces - sans batteries - incluses.
|
||||
|
||||
#### Carte de contrôle pour la baie de disques
|
||||
|
||||
Le contrôleur de la baie de disques est obsolète. On peut éventuellement
|
||||
en trouver un reconditionné ou en pièces détachées.
|
||||
|
||||
Une autre solution serait de changer le chassis, et d'utiliser des nouveaux
|
||||
contrôleurs. Les disques sont heureusement compatibles. Coût public 6550 euros
|
||||
contrôleurs inclus (prévoir une remise ~20%), sans prendre en compte un échange
|
||||
éventuel (d'après une simulation, environ 600 euros seraient récupérables).
|
||||
|
||||
#### Backbone
|
||||
|
||||
Pas de proposition mise à jour, nous avions envisagé un chassis 5406, avec deux
|
||||
modules
|
||||
|
||||
* 12 ports SFP + 12 ports Ethernet 10/100/1000
|
||||
* 24 ports 10/100/1000 Ethernet
|
||||
|
||||
### Imprimante
|
||||
|
||||
Il faudrait se débarrasser de Print Platinium. On pourrait ensuite acheter une
|
||||
imprimante ou en louer une selon l'offre qui va nous être proposée.
|
||||
|
||||
À considérer :
|
||||
|
||||
* Délai d'intervention du technicien
|
||||
* Durée du contrat, évidemment
|
||||
* Durée de vie des consommables (nb de pages par cartouche)
|
||||
* Tarifs si la consommation prévue est dépassée ?
|
||||
* Considérations sur le prix des impressions (A4 vs. A3, noir vs. couleur)
|
||||
|
||||
Dans tous les cas, il faut relancer le technicien de PP pour le changement des
|
||||
tambours... Il faut poker PEB.
|
||||
|
||||
### Caméra
|
||||
|
||||
La nouvelle caméra a été installée, et l'assureur du CROUS n'envisage pas de
|
||||
rembourser l'ancienne, parce qu'apparemment le plastique ne rouille pas quand il
|
||||
se fait inonder.
|
||||
|
||||
### Serveur de logs
|
||||
|
||||
Le disque de ragnarok semble mort, il faut un volontaire pour aller acheter deux
|
||||
disques SATA de capacité respectable (≥ 1 To) chez nos amis de Montgallet, afin
|
||||
de mettre en place un RAID et de pouvoir voir venir. PEB s'était porté
|
||||
volontaire
|
||||
sur IRC.
|
||||
|
||||
Il faut absolument penser aux backups sur ce serveur. La procédure complète
|
||||
d'installation pourra être détaillée sur le wiki.
|
||||
|
||||
### Bug tracker
|
||||
|
||||
Olivier a fait en sorte que les mails envoyés vers xxx@bugs.crans.org arrivent
|
||||
sur le serveur idoine. Il y a manifestement un bug dans la config de postfix.
|
||||
|
||||
Il faudrait reprendre la configuration mail qui a été faite pour
|
||||
tracker.crans.org, qui fait en sorte que les mails y arrivent.
|
||||
|
||||
Il faut définir quels "packages" on met en place, et quels mainteneurs (même si
|
||||
juste roots@crans.org semble adapté).
|
||||
|
||||
Nicolas envisageait quelque chose du style un package par serveur + un package
|
||||
par service important (WiFi, impression, intranet, ...). Olivier est d'accord.
|
||||
|
||||
Il y a plusieurs aspects sur lesquels on pourrait travailler:
|
||||
|
||||
* Un suivi des mails envoyés par monit, munin, ... pour les transformer en
|
||||
tickets.
|
||||
* Un bot IRC pour notifier des bugs, et enregistrer une partie des
|
||||
conversations.
|
||||
|
||||
### Séminaires
|
||||
|
||||
Vu la grande présence apprentiesque à cette réunion, les séminaires sont
|
||||
relancés pour dans 10 jours.
|
||||
|
||||
### Bornes Wifi
|
||||
|
||||
Il faut que les nouvelles bornes soient déployées le 15 mars. À faire :
|
||||
|
||||
* Finalisation de la config
|
||||
* Chiffrage et vote pour le budget du projet
|
||||
* Déploiement
|
||||
|
||||
#### Redémarrage des bornes
|
||||
|
||||
Certaines bornes ont besoin d'un redémarrage de temps en temps. On va mettre en
|
||||
place un script qui les redémarre une fois par jour, par exemple
|
||||
à (3 + rand(0, 1))h du matin.
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### Quid d'un web-nntp
|
||||
|
||||
### Nit m'a montré ce qu'il avait fait, c'est cool.
|
||||
|
||||
Yann et Valentin ont l'air motivés pour mettre une solution en place.
|
||||
|
|
@ -0,0 +1,143 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 9 février 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h23
|
||||
* Fin :21h05
|
||||
|
||||
## Présents
|
||||
|
||||
* Benjamin Aupetit
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Bonaque
|
||||
* Raphaël Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vanessa Verbeke
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Achat de matériel
|
||||
|
||||
Le C.A. a accordé le budget nécessaire pour le backbone et la baie de disques.
|
||||
La commande a été passée, et les livraisons devraient se faire sous peu. Le
|
||||
chassis est un chassis de six modules au lieu de quatre actuellement, il faudra
|
||||
donc faire de la place.
|
||||
|
||||
### Imprimante
|
||||
|
||||
Qualis fait une offre de leasing sur une imprimante Xerox (7535) qui semble
|
||||
intéressante.
|
||||
Le bac de sortie est vraisemblablement du mauvais coté, ce qui est problématique
|
||||
pour accéder aux bacs de chargement. On pourrait faire des travaux pour échanger
|
||||
la porte et l'espace de sortie du papier.
|
||||
|
||||
Il serait bien aussi d'installer une vraie climatisation, il faut obtenir
|
||||
l'autorisation de Lebailly pour pouvoir faire les travaux. Benjamin s'en occupe.
|
||||
|
||||
### Mises à jour des serveurs
|
||||
|
||||
Youpi ! Gordon est à jour !!
|
||||
Il reste à mettre à jour :
|
||||
|
||||
* titanic, Vincent s'en charge avec Daniel et Valentin (maj de squid en même
|
||||
|
||||
temps pour faire marcher proprement la connexion de secours)
|
||||
|
||||
* niomniom, Steven s'en charge avec adg
|
||||
* vert, Olivier s'en charge avec Nicolas
|
||||
* fy
|
||||
* zamok :
|
||||
Le / est trop petit, il faudrait utiliser le deuxième disque dur. On va en
|
||||
profiter pour repartitionner comme il faut. Daniel s'en charge avec Olivier.
|
||||
* rouge (s'en débarrasser ?)
|
||||
|
||||
### Dyson
|
||||
|
||||
Dyson est sous squeeze, il faut que la personne qui l'a mis à jour mette à jour
|
||||
bcfg2.
|
||||
|
||||
Pierre-Elliott s'occupe de mettre à jour munin avec Nicolas, pour que la
|
||||
génération
|
||||
des graphes mette moins de deux heures.
|
||||
|
||||
### Wifi
|
||||
|
||||
Daniel a installé deux bornes au G, elles ne fonctionnent pas pour l'instant,
|
||||
il va investiguer.
|
||||
|
||||
Daniel a commencé le développement de scripts permettant une connexion SSH de
|
||||
masse sur les bornes wifi, afin d'effectuer des déploiements simples (scripts,
|
||||
...).
|
||||
|
||||
Il faut chiffrer le renouvellement du parc de bornes wifi pour le prochain CA.
|
||||
Cela implique de faire des tests de portée, de finir la configuration,
|
||||
et de comparer avec les tests de couverture qui ont été faits.
|
||||
Olivier et Raphaël vont voir ça ce week-end, appel aux apprentis motivés.
|
||||
|
||||
Un dépot opkg va être mirroré sur sila par websync.
|
||||
|
||||
### Switchs
|
||||
|
||||
PEB a testé les switchs qui sont entreposés au 2B.
|
||||
|
||||
Il faut changer bata-3.
|
||||
|
||||
Il serait très appréciable que les switchs défectueux soient changés en moins de
|
||||
quatre jours, par exemple par les nounous d'astreinte inscrites sur le wiki.
|
||||
Daniel et PEB s'en chargent ce soir.
|
||||
|
||||
### Séminaires
|
||||
|
||||
Les séminaires sont programmés jusqu'à mars.
|
||||
|
||||
### Séances de travail
|
||||
|
||||
L'objectif est d'avoir un ou deux apprentis encadrés par une ou deux nounous,
|
||||
pour réaliser une tâche sur un sujet précis.
|
||||
|
||||
#### Wifi
|
||||
|
||||
Encadré par Harry et Iota.
|
||||
À faire : cf supra.
|
||||
|
||||
#### Scripts
|
||||
|
||||
Encadré par iota
|
||||
|
||||
Pour l'instant : passage des scripts en utf-8-safe, Vincent et Pierre-Elliott
|
||||
sont candidats pour se faire victimiser.
|
||||
|
||||
#### Maintenance des services
|
||||
|
||||
Encadré par iota.
|
||||
|
||||
Tâches : Passer en revue tous les mails d'erreurs des divers services.
|
||||
|
||||
#### Monitoring
|
||||
|
||||
Encadré par Nicolas et Olivier. Victimes : Pierre-Elliott et Vincent.
|
||||
|
||||
Première tâche : mise à jour de munin.
|
||||
|
||||
#### Intranet 2
|
||||
|
||||
À voir à moyen terme.
|
||||
Encadré par Daniel et Nicolas.
|
||||
|
||||
#### Firewall
|
||||
|
||||
Encadré par Valentin
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### Prêt de matériel pour une LAN
|
||||
|
||||
Il y a une soirée jeux vidéo demain, les organisateurs demandent si on peut
|
||||
leur prêter du matériel : des câbles et des multiprises. Daniel sera là-bas et
|
||||
s'en charge.
|
||||
|
|
@ -0,0 +1,104 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 23 février 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 20h20
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliot Becue
|
||||
* Raphaël Cauderlier
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Imprimante
|
||||
|
||||
Elle fonctionne, mais n'agrafe pas quand on imprime avec lpr, la syntaxe a
|
||||
dû changer.
|
||||
PEB va voir ce qu'il en est.
|
||||
|
||||
PEB a remis en place la plaque au niveau de la fenêtre, afin d'éviter d'autres
|
||||
visiteurs à plumes, il faudrait la fixer de manière un peu plus efficace.
|
||||
|
||||
### Wifi
|
||||
|
||||
Des tests ont été faits au G et au M. Il faut une borne par couloir au M, et 2
|
||||
par étage au G.
|
||||
Il faut calculer les longueurs de câble et le nombre total de bornes d'ici jeudi
|
||||
prochain.
|
||||
|
||||
Vesta est dans la med en ce moment. Certaines personnes ont quelques soucis
|
||||
avec.
|
||||
|
||||
Daniel a avancé sur la carte des bornes.
|
||||
|
||||
### Télévision
|
||||
|
||||
Il avait été proposé d'utiliser des cartes ARM pour la TV. Sylvain voudrait
|
||||
demander l'avis du CA et des nounous.
|
||||
|
||||
<http://blog.einval.com/2011/09/05>
|
||||
<http://shop.digital-devices.de/epages/62357162.sf/en_GB/?ObjectPath=/Shops/62357162/Products/191203>
|
||||
|
||||
Le budget restant sur ce qui avait été voté en CA est de l'ordre de 100 euros.
|
||||
|
||||
Il faut évaluer cette solution vs. une solution à base d'un serveur classique.
|
||||
Sylvain s'en charge.
|
||||
|
||||
### Séminaires
|
||||
|
||||
return -ENOAPPRENTIS; Toutefois, PEB prend le sujet monitoring.
|
||||
|
||||
### Zamok
|
||||
|
||||
La mise à jour a été faite au forceps. Une machine du labo de Drébon pourrait
|
||||
nous être offerte, on pourrait en faire le nouveau serveur des adhérents.
|
||||
|
||||
### Backbone
|
||||
|
||||
Il a été remplacé dans la nuit de vendredi à samedi dernier. Cela a occasionné
|
||||
une coupure des services entre 1h30 et 3h. Lors du redémarrage
|
||||
des services, l'UDP sur komaz a cordialement décidé de nous chier dans les
|
||||
bottes.
|
||||
Ce problème n'est toujours pas expliqué ni réglé. Le tunnel IPv6 étant en UDP,
|
||||
l'IPv6 est actuellement mort. Il ''faut'' régler le problème rapidement.
|
||||
|
||||
Le remplacement s'est fait sans prévention sur les news de la coupure des
|
||||
services.
|
||||
Le CA va probablement rappeler au collège des responsables techniques que les
|
||||
mises à jour de services critiques doivent être annoncées et effectuées à
|
||||
l'horaire annoncé, ou reportées.
|
||||
|
||||
### Planification des séances de travail
|
||||
|
||||
Une séance de travail sur le monitoring est prévue ce week-end, probablement
|
||||
samedi après-midi. Nicolas, Pierre-Elliott et Vincent Le Gallic y travailleront.
|
||||
|
||||
Olivier va organiser des séances de travail sur les scripts, notamment pour
|
||||
gérer
|
||||
proprement l'encodage et pour utiliser le nouveau binding LDAP. On prévoit une
|
||||
séance le 3 ou le 4 mars.
|
||||
|
||||
## Mises à jour
|
||||
|
||||
### Mise à jour de titanic
|
||||
|
||||
La mise à jour de titanic aura lieu dimanche matin, Olivier se charge de
|
||||
prévenir
|
||||
la DSI, qui informera les personnels.
|
||||
|
||||
### Mise à jour de vert (ldap)
|
||||
|
||||
La mise à jour sera faite dimanche 4 mars au matin. Tous les services seront
|
||||
coupés pendant la mise à jour. Olivier fait l'annonce.
|
||||
|
||||
## Questions Diverses
|
||||
|
||||
N/A
|
||||
|
|
@ -0,0 +1,99 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 15 mars 2012
|
||||
* Lieu : Amphithéâtre Tocqueville
|
||||
* Début : 19h15
|
||||
* Fin : 20h12
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Quelennec
|
||||
* Daniel Stan
|
||||
* Julien Baste
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Ιffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Séminaires
|
||||
|
||||
'On laisse tomber les séminaires après celui sur le monitoring.
|
||||
Il serait peut être bien de planifier des séminaires LateX pour janvier de
|
||||
l'année prochaîne.
|
||||
|
||||
### Wifi
|
||||
|
||||
Une !PicoStation M2 HP a été achetée. Elle marche out of the box avec l'image
|
||||
pour !NanoStation. Daniel l'a mise à la Kfêt pour la tester en situation réelle.
|
||||
On va prendre des {Pico,Nano}Station M2 et quelques !NanoStation M5 pour les
|
||||
lieux très fréquentés. Il faut établir un budget à soumettre au CA. Olivier
|
||||
s'occupe de ça ce WE, avis aux intéressés.
|
||||
|
||||
Valentin a créé un petit exécutable pour implanter les profils wifi sur les
|
||||
postes Windows Vista et 7 (et peut-être 8, TODO ce soir). Valentin s'occupe
|
||||
d'en faire la pub auprès des câbleurs.
|
||||
|
||||
### Intranet
|
||||
|
||||
Julien a repris ce qui avait été fait sur l'intranet. On a ouvert un port pour
|
||||
qu'il puisse continuer à travailler dessus pendant son stage. Appel aux gens
|
||||
motivés pour se joindre à lui.
|
||||
|
||||
L'objectif principal est de répliquer la fonctionnalité de l'intranet actuel.
|
||||
|
||||
### Mises à jour de serveurs
|
||||
|
||||
#### vert
|
||||
|
||||
Vert a été mis à jour. Il est possible de mettre à jour les ACL sur la base
|
||||
LDAP pour permettre aux utilisateurs de modifier ce qui les concerne, pour
|
||||
faire des logs dans la base, ...
|
||||
On va commencer à voir ça ce soir.
|
||||
|
||||
#### Niomniom
|
||||
|
||||
Il faut voir avec adg pour faire ça au plus vite. PEB est volontaire.
|
||||
|
||||
#### Zamok
|
||||
|
||||
Il faut se débarrasser de zamok, On l'a bien vu ces derniers temps (mis à genoux
|
||||
par le driver de l'imprimante). Nicolas propose d'utiliser l'actuel fx pour
|
||||
enfin mettre à jour matériellement zamok.
|
||||
|
||||
Reste à réfléchir à quel serveur utiliser pour faire le partage NFS. Plusieurs
|
||||
choix s'offrent à nous :
|
||||
|
||||
* Effectuer les exports NFS depuis le nouveau zamok.
|
||||
* Avantage : simplicité
|
||||
* Inconvénient : si un adhérent fait de la merde, les exports NFS sont perdus
|
||||
* Utiliser un serveur actuel pour faire les exports NFS. Les candidats :
|
||||
* Vieux zamok
|
||||
* Un serveur free
|
||||
* Sable ?
|
||||
* Investir dans un nouveau serveur pour faire les exports NFS :
|
||||
* Avantage : c'est un serveur neuf...
|
||||
* Inconvénient : c'est un peu cher...
|
||||
|
||||
Le vainqueur serait apparemment le serveur free.
|
||||
|
||||
L'interaction serveur free <-> nouvelle baie de disques sera testée au 2B avant
|
||||
la mise à jour effective.
|
||||
|
||||
### Baie de disques
|
||||
|
||||
La nouvelle baie de disques est arrivée. On va l'installer en même temps qu'on
|
||||
fera la migration de zamok. Ce n'est pas pressé.
|
||||
|
||||
### Départs en stage
|
||||
|
||||
Il faut que les gens qui partent en stage mettent à jour CransVacances.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Plan du réseau
|
||||
|
||||
Daniel a mis à jour le plan, il faut le vérifier.
|
||||
Il faudrait faire un deuxième plan au niveau logique pour montrer les VLANs.
|
||||
|
|
@ -0,0 +1,143 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 29 mars 2012
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h17
|
||||
* Fin : 20h13
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Aurore Quelennec
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Sylvain Boilard
|
||||
* Vanessa Verbeke
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### État du 2B
|
||||
|
||||
Le 2B a été nettoyé par Morgane et Daniel. Le RTC souhaite que le 2B reste
|
||||
dans cet état là. Pour le reste, il faudra lui redonner un coup de propre
|
||||
régulièrement.
|
||||
|
||||
Le matériel a été rangé (organisation qui invite de nouvelles suggestions)
|
||||
|
||||
### Debbugs
|
||||
|
||||
Debbugs a été mis en place. Site web: <http://bugs.crans.org/> (pour soumettre
|
||||
un bug : submit@bugs.crans.org). C'est initialement le tracker de bugs de debian,
|
||||
et chaque paquet debian a sa liste de bugs. Comme le crans n'a pas de paquets
|
||||
au sens debianesque, on pourrait créer plusieurs "paquets" crans correspondant
|
||||
à des services. Actuellement, on a un seul paquet "crans".
|
||||
|
||||
On pourrait organiser les paquets par services.
|
||||
|
||||
Noms ASCII.
|
||||
|
||||
* scripts
|
||||
* ldap_crans
|
||||
* mail
|
||||
* firewall
|
||||
* intranet (+ impression)
|
||||
* intranet2
|
||||
* zamok (= accès shell, pages perso)
|
||||
* wifi
|
||||
* wiki
|
||||
* cablage (= prises défectueuses)
|
||||
* tele
|
||||
* crans (= autres)
|
||||
|
||||
#### Possibilités d'évolution
|
||||
|
||||
* Bot IRC (création de tickets directement sur irc)
|
||||
* Frontend web de soumission utilisable par les adhérents (sur l'intranet2)
|
||||
|
||||
### Matériel
|
||||
|
||||
#### Wifi
|
||||
|
||||
Harry, Daniel et Olivier ont parcouru les bâtiments pour trouver où câbler les
|
||||
bornes. Le compte-rendu sera mis sur le wiki à l'occasion. En bref, une pico
|
||||
par étage au A, B, C. H, I, J, dans les locaux à côté de la cage d'ascenseur.
|
||||
|
||||
Dans le G, il y a des placards où on peut faire passer des câbles entre les
|
||||
étages.
|
||||
L'idée est de placer une nano par étage, en alternance (en terme de position).
|
||||
|
||||
Le M n'a pas été fait, car on avait pas le badge, mais vu les tests le 16
|
||||
février, il faut une nano par aile, donc deux par étage.
|
||||
Attention aux 100m de câble, et à sertir les paires dans le bon sens...
|
||||
|
||||
Les longueurs de câbles seront données sur le wiki. (Daniel s'en charge)
|
||||
|
||||
On pourra réfléchir, une fois l'installation faite, à prêter des bornes à des
|
||||
adhérents pour "patcher" la couverture dans leur chambre, sous caution.
|
||||
|
||||
#### Onduleurs
|
||||
|
||||
Olivier s'occupe de faire faire des devis pour remplacer les onduleurs morts
|
||||
(0A, 2B, -1I), Pierre-Elliott et Nicolas s'occuperont d'aller voir les onduleurs
|
||||
pour savoir lesquels marchent.
|
||||
|
||||
#### Clim 0B
|
||||
|
||||
Pierre-Elliott s'occupe d'appeler LTC pour faire la révision annuelle de la
|
||||
clim.
|
||||
|
||||
### Mises à jour
|
||||
|
||||
#### TV
|
||||
|
||||
La version en production de MuMuDVB était bugguée avec les nouvelles versions de
|
||||
VLC. Olivier a effectué la mise à jour du binaire sur les serveurs cet
|
||||
après-midi.
|
||||
|
||||
#### Wiki
|
||||
|
||||
Adg est prêt à encadrer un apprenti pour faire cette mise à jour, avec le
|
||||
prérequis
|
||||
que l'apprenti en question soit un peu culturé sur apache2 (i.e. sache déjà
|
||||
lancer moinmoin avec wsgi). Vanessa va voir avec Steven s'il veut toujours
|
||||
s'en occuper, sinon, Pierre-Elliott est volontaire (après ses écrits du concours
|
||||
3A).Steven est volontaire (il va envoyer un mail à Olivier).
|
||||
|
||||
### Séances de travail
|
||||
|
||||
#### Ragnarok
|
||||
|
||||
Ragnarok est désormais bien monté (deux disques durs d'1To en RAID1). Olivier
|
||||
se propose d'encadrer le workshop, qui aura lieu le 7 avril.
|
||||
|
||||
#### Nagios
|
||||
|
||||
Quand le workshop monitoring a été effectué, on a parlé de re-tester Nagios
|
||||
Pierre-Elliott est motivé pour lire les 400 pages de doc de Nagios et prendre
|
||||
des notes sur le wiki. Ensuite, on fera une réunion pour en parler, et on
|
||||
essaiera de faire un workshop avec une Mamie pour trouver comment implémenter
|
||||
au mieux le module.
|
||||
|
||||
#### Wiki
|
||||
|
||||
Il faut le réordonner tant d'un point de vue "VieCrans" que du point de vue
|
||||
technique. Pour la partie VieCrans, Morgane était volontaire pour diriger cette
|
||||
réorganisation.
|
||||
|
||||
Il faudrait faire plusieurs workshops pour cela. Nicolas demande si ça vaut le
|
||||
coup de dédier du temps à faire ''uniquement'' ça.
|
||||
|
||||
On pourrait essayer d'appliquer un tag sur les pages pour dater la dernière fois
|
||||
que la véracité des informations a été vérifiée.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Spoofing adresses mac
|
||||
|
||||
Un certain nombre d'adhérents reçoivent des mails d'avertissement pour upload
|
||||
sans avoir été connectés depuis la veille. Pierre-Elliott va dresser une petite
|
||||
liste
|
||||
des adhérents qui prétendent cela, et on essayera de voir si une prise commune à
|
||||
tous ces adhérents est identifiable.
|
||||
|
|
@ -0,0 +1,162 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 12 avril 2012
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h13
|
||||
* Fin : 20h10
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Daniel Stan
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Sylvain Boilard
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Ragnarok
|
||||
|
||||
Nicolas, Olivier, Pierre-Elliott et Yann ont mis en place un serveur rsyslog (en
|
||||
RELP) sur ragnarok qui enregistre ses logs dans une base PostgreSQL en local.
|
||||
Ça fonctionne, on a mis whatsupdoc en client pour l'instant, il faut voir ce
|
||||
qu'on fait des serveurs qui utilisent syslog-ng. On va regarder un peu plus en
|
||||
détails, mais la solution qui semble la plus pratique est de remplacer
|
||||
syslog-ng
|
||||
par rsyslog.
|
||||
|
||||
Il faut aussi documenter le tout sur le wiki.
|
||||
|
||||
### Niomniom
|
||||
|
||||
Steven et Antoine Durand-Gasselin ont travaillé là dessus lundi, pour voir ce
|
||||
qu'il se passait, et si ça marchait. A priori, tout fonctionne, la mise à jour
|
||||
est prévue samedi à 14h, les pages devraient rester consultables (duplicata des
|
||||
pages le temps de la MaJ). La modification de la page d'accueil du wiki est à
|
||||
faire le plus tôt possible pour prévenir tout le monde.
|
||||
|
||||
Steven songe à faire une doc pour la MàJ du wiki qui soit plus accessible à tous
|
||||
que celle d'Antoine pour les novices.
|
||||
|
||||
### Serveurs de virtualisation
|
||||
|
||||
#### Fy
|
||||
|
||||
Après la mise à jour du wiki, il n'y aura plus aucun domU sur Fy (les domu
|
||||
étant migrés pendant la mise à jour). Il faudra donc le mettre à jour, on peut
|
||||
le faire dans la foulée. On pourra alors penser à répartir la charge des domU
|
||||
entre les deux serveurs Fy et Fz.
|
||||
Raphaël rappelle l'idée de fournir des domU aux clubs. Fz avait à l'origine été
|
||||
acheté dans le but d'héberger un nouveau serveur pour les adhérents.
|
||||
|
||||
#### Fx
|
||||
|
||||
Lors d'une précédente internounou, Nicolas avait souligné que Fx est
|
||||
sous-utilisé, et qu'il faudrait songer à utiliser une machine free comme NFS, et
|
||||
du coup employer Fx soit comme un nouveau zamok, soit comme un serveur pour les
|
||||
clubs.
|
||||
|
||||
#### Machines pour clubs
|
||||
|
||||
Raphaël propose de créer une interface pour les clubs leur permettant de créer
|
||||
une machine virtuelle qu'ils pourraient utiliser à l'envi. On pourra rediscuter
|
||||
de ce point après les mises à jour.
|
||||
|
||||
### Wifi
|
||||
|
||||
Les nouvelles bornes sont arrivées. Il faut des personnes pour poser les bornes
|
||||
et effectuer les cablâges nécessaires.
|
||||
Il faut s'assurer d'avoir un firmware fonctionnel. La connexion sous windows
|
||||
avec ce firmware semble problématique en l'état. Une étude est à mener sur ce
|
||||
point.
|
||||
|
||||
Liste des bâtiments où on pourrait intervenir sans délai :
|
||||
|
||||
* Le A (en partie)
|
||||
* Le B
|
||||
* Le C
|
||||
* La Med
|
||||
* La Kfet
|
||||
|
||||
On récupèrera à l'occasion d'anciennes bornes, que l'on peut mettre à
|
||||
disposition
|
||||
des anciens adhérents qui veulent les placer dans leur chambre pour patcher la
|
||||
connexion wifi, vu qu'elles font switch, il n'y a pas de problème niveau
|
||||
câblage.
|
||||
On demandera une caution qui sera fixée par le C.A. Il faudra déménager la borne
|
||||
dans la chambre de l'adhérent, et donner l'accès au VLAN wifi.
|
||||
|
||||
Vu le nombre de bornes, il est nécessaire de former des gens pour flasher les
|
||||
bornes.
|
||||
Les bornes seront flashées lorsque des gens sachant le faire seront à
|
||||
disposition,
|
||||
du coup toute personne intéressée pourra profiter d'un éventuel workshop. (sans
|
||||
que cela n'entraîne une affluence trop forte au 2B). On fera des wokshops durant
|
||||
le WE, vendredi soir, samedi selon l'avancement des mises à jour, dimanche.
|
||||
|
||||
### Liste de compétences des apprentis
|
||||
|
||||
Vanessa a demandé que l'on établisse une liste de compétences nécessaires aux
|
||||
apprentis pour qu'ils puissent éventuellement devenir nounous. Ce point avait
|
||||
déjà été traité, et un premier document avait été créé, il a été mis à jour,
|
||||
et une version sera proposée sur le wiki d'ici jeudi.
|
||||
|
||||
### Baie de disques
|
||||
|
||||
Pierre-Elliott a discuté avec Jérémie concernant la baie de disques en vue de la
|
||||
mise à jour matérielle. Elle est de la même famille que la baie actuelle, il y a
|
||||
des chances que ce soit plug-and-play. Dans tous les cas, c'est suffisamment
|
||||
lourd pour qu'on attende l'été avant de s'en charger.
|
||||
|
||||
### LTC
|
||||
|
||||
Pierre-Elliott a contacté LTC, ils proposent de passer le mardi 24 avril à 8h
|
||||
pour la maintenance de la climatisation du 0B. Pierre-Elliott et Olivier sont
|
||||
disponibles pour les accueillir.
|
||||
|
||||
### Nagios
|
||||
|
||||
Pierre-Elliott va tenter d'essayer de proposer une documentation sur le wiki, et
|
||||
appelle les gens qui ont des questions à les poser, ensuite on pourra mettre ça
|
||||
en place, à la place de monit et en complément de munin.
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### Multiples adresses MAC
|
||||
|
||||
Un adhérent rencontre un problème de multiples adresses macs dans sa chambre.
|
||||
Lorsqu'il branche son ordinateur, le switch voit en moyenne 8 adresses mac, et
|
||||
du coup, il n'a pas accès à Internet.
|
||||
|
||||
On va essayer de faire en sorte qu'il puisse se connecter, et chercher des
|
||||
vraies solutions en parallèle.
|
||||
Solutions proposées :
|
||||
|
||||
* Désactiver temporairement l'authentification RADIUS sur la prise
|
||||
* N'autoriser que sa vraie MAC sur sa prise
|
||||
|
||||
### Vérification mac prises
|
||||
|
||||
Daniel s'inquiétait du fait que quelqu'un puisse spoofer des adresses mac
|
||||
d'adhérents pour faire de l'upload, un script s'occupe désormais de logguer
|
||||
ces informations, pour que le cas échéant on le sache.
|
||||
|
||||
### Installeur Debian
|
||||
|
||||
L'installeur Debian présent sur le FTP du Cr@ns (et sur le netboot) est cassé,
|
||||
il ne reconnait pas les disques durs (et potentiellement pas le reste non plus).
|
||||
Il faut essayer de trouver une solution. A priori, c'est un problème indépendant
|
||||
du Cr@ns, mais il existe des images censées corriger ça. Affaire à suivre.
|
||||
|
||||
### IMAP
|
||||
|
||||
Apparemment, Roundcube plante en essayant de s'abonner à des dossiers IMAP, et
|
||||
icedove/thunderbird semble également rencontrer quelques difficultés (à
|
||||
vérifier).
|
||||
Il est possible que dovecot rencontre pas mal de soucis en ce moment, Antoine
|
||||
Durand-Gasselin a suggéré de refaire la configuration de dovecot pour régler la
|
||||
panne.
|
||||
|
|
@ -0,0 +1,168 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 26 avril 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h25
|
||||
* Fin : 21h
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Raphaël Cauderlier
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Wiki
|
||||
|
||||
La mise à jour de niomniom a été effectuée. Les personnes ayant effectué la
|
||||
mise à jour n'étant pas présentes, difficile d'en dire plus. Un backup du
|
||||
wiki a été fait dans /usr/scripts (il pèse 800 Mo), il faut l'enlever.
|
||||
|
||||
### Virtualisation
|
||||
|
||||
fy a été réinstallé, histoire que ce soit propre, et à peu près la même chose
|
||||
que sur fz. La migration à chaud ne marche pas très bien. fy est prêt à
|
||||
accueillir des domU. On va s'en servir pour mettre à jour fz en limitant le
|
||||
downtime.
|
||||
|
||||
### Baie de disques
|
||||
|
||||
Il faudrait voir s'il est possible d'avoir quelques disques en plus, pour
|
||||
pouvoir faire des tests dans un premier temps, et ensuite servir de disques
|
||||
supplémentaires déjà branchés.
|
||||
|
||||
La nouvelle baie étant de la même famille que l'ancienne, le transvasage des
|
||||
disques de l'une à l'autre devrait être plug-and-play.
|
||||
|
||||
On va faire un workshop le 19 ou le 20 mai pour tester la nouvelle baie.
|
||||
|
||||
### Nagios
|
||||
|
||||
Pierre-Elliott a passé pas mal de temps (avec Nicolas) pour configurer Nagios de
|
||||
manière raisonnable. La config est en cours, serveur par
|
||||
serveur. 4 ou 5 serveurs
|
||||
sont configurés.
|
||||
|
||||
Démo sur nagios.crans.org (login/mdp crans).
|
||||
|
||||
Nagios peut tester les services de « l'extérieur » en testant leur
|
||||
fonctionnement.
|
||||
Un module nagios-nrpe permet de tester les services depuis l'hôte. Ce dernier
|
||||
permet de faire des checkdisk, etc. (peu utile car munin le fait déjà).
|
||||
|
||||
L'implémentation des plugins munin est a priori faite, mais les résultats sont
|
||||
mitigés. (les plugins sont monitorés passivement, donc si pas de warning, ils
|
||||
sont notés comme "en attente", et les rares qui ont été monitorés sont en
|
||||
"unknown". Le passage des plugins munin a été uniquement mis en place pour vert.
|
||||
|
||||
Il faut trouver une solution alternative à la configuration actuelle pour
|
||||
récupérer
|
||||
les données de munin dans nagios. Un plugin nagios existe apparemment pour lire
|
||||
les fichiers rrd de munin. À creuser ?
|
||||
|
||||
vo:/localhome/becue/nagios contient quelques scripts et éléments au fur et à
|
||||
mesure de la config. La doc sera faite d'ici peu.
|
||||
|
||||
Il faut intégrer monit à nagios (c'est à dire, faire en sorte que les warnings
|
||||
de monit soient gérés par nagios, au niveau mail et interface web).
|
||||
Un plugin nagios existe déjà pour se connecter à un serveur monit distant, il
|
||||
faut donc voir à adapter la config de monit, ou à lancer le plugin en question
|
||||
via NRPE.
|
||||
|
||||
Il faudra aussi réfléchir à la "mise en production" des alertes mail de nagios
|
||||
sur
|
||||
roots@crans.org.
|
||||
|
||||
### Wifi
|
||||
|
||||
Pas de réponse d'interprojekt pour le retour des bornes (qui ne sont pas les
|
||||
bonnes).
|
||||
|
||||
Certains adhérents ont constaté un problème de compatibilité entre leur carte
|
||||
réseau et le wifi n. Une désactivation du wifi 802.11n sur la carte niveau
|
||||
client a été faite pour régler le problème.
|
||||
|
||||
Il y a plusieurs possibilités sur la nature du problème. Cela peut-être
|
||||
dû à la largeur du canal utilisé pour le WiFi n (les canaux à 40MHz ne sont pas
|
||||
supportés par la carte, contrairement à ceux à 20MHz). Cela peut aussi être dû
|
||||
à un driver moisi (il permet de désactiver le 802.11n, donc il n'est pas si
|
||||
moisi que ça). On n'a pas constaté de problèmes lors des journées FedeRez,
|
||||
donc ça peut aussi être lié au WPA2-entreprise.
|
||||
|
||||
Pour résoudre ce problème particulier, plusieurs pistes :
|
||||
|
||||
* Désactivation du 802.11n côté client
|
||||
* Avantage : débit maximal pour les clients qui le supportent
|
||||
* Inconvénients : tests au câblage plus lourds, toutes les cartes ne le
|
||||
|
||||
supportent peut-être pas...
|
||||
|
||||
* Dédoubler les SSID (Un ssid Cr@ns, un ssid Cr@ns-n)
|
||||
* Avantage : débit max pour les clients qui le supportent, les vieux clients
|
||||
ont toujours du wifi g
|
||||
* Inconvénients : confusion ?
|
||||
* Réduire la largeur du canal
|
||||
* Avantage : toujours du n
|
||||
* Inconvénients : est-ce que ça règle vraiment le problème ?
|
||||
* Désactiver le wifi 802.11n
|
||||
* Avantage : On est sûrs que ça marchera partout
|
||||
* Inconvénients : pas un meilleur débit (enfin toujours un meilleur débit que
|
||||
|
||||
les wrt54g...)
|
||||
|
||||
Daniel a commencé à regarder pour le dédoublement des SSID, le reste est une
|
||||
modification triviale en termes de config d'OpenWRT et peut être testé en
|
||||
présence
|
||||
d'un-e cobaye.
|
||||
|
||||
Diomède sera réinstallée à la Kfêt, avec la config HT20 pour tester.
|
||||
|
||||
### Ardoise virtuelle 0B
|
||||
|
||||
L'idée de base est que l'interface d'accès aux locaux ne fonctionnera jamais
|
||||
(les gens ne s'y inscriront jamais), Daniel propose de faire une interface
|
||||
physique sur laquelle les gens s'inscrivent pour prendre une clé, et qui
|
||||
consigne les accès directement dans la base.
|
||||
|
||||
On pourrait aussi envisager l'idée d'installer une armoire à clefs électronique
|
||||
un peu comme celle de l'ENS, qui ne permet de retirer que la clé pour laquelle
|
||||
on s'est inscrit. Celà forcerait les gens à s'inscrire.
|
||||
|
||||
Daniel s'occupe de faire ça et l'interface d'accès aux locaux, éventuellement
|
||||
avec un apprenti (Julien ?).
|
||||
|
||||
### Babar
|
||||
|
||||
Il commence à en avoir plein la trompe. Olivier s'occupe de demander un devis à
|
||||
Anne pour plus de disques, selon le nombre de slots disponibles.
|
||||
|
||||
### Ragnarok
|
||||
|
||||
Le nouveau serveur syslog est fonctionnel.
|
||||
|
||||
Reste à mettre la config de rsyslog sur tous les serveurs pour qu'ils y envoient
|
||||
leurs logs. Il faut faire attention à ne pas faire la modification à l'aveugle,
|
||||
par exemple sur les serveurs qui dépendent de leurs logs (komaz, par exemple).
|
||||
|
||||
Il faut aussi changer la config des switchs pour qu'ils envoient leurs logs
|
||||
à ragnarok et non à vo. Daniel s'en occupe.
|
||||
|
||||
Il faut configurer un frontend un peu plus sexy que psql. Yann s'occupe de
|
||||
recenser ce qui existe.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Inscription aux mailing-lists des vieilles nounous inactives
|
||||
|
||||
Plein de vieilles nounous + plein de spams = plein d'espace disque utilisé pour
|
||||
rien.
|
||||
|
||||
Plusieurs possibilités : virer les droits des gens; créer un droit "Vieux" qui
|
||||
reçoit juste certaines ML; ne rien faire et remplir /home.
|
||||
|
||||
Olivier envoie un mail à ces vieux pour leur demander ce qu'ils veulent toujours
|
||||
voir et pourquoi.
|
||||
|
|
@ -0,0 +1,115 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 10 avril 2012
|
||||
* Lieu : Hall du bâtiment B
|
||||
* Début : 19h35
|
||||
* Fin : 20h35
|
||||
|
||||
## Présents
|
||||
|
||||
* Aurore Moisy-Mabille
|
||||
* Morgane Jançon
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pierre Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Sylvain Boilard
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Ajout de droits
|
||||
|
||||
nounous.append(PEB)
|
||||
|
||||
### Logs
|
||||
|
||||
Ragnarok fonctionne, et les logs sont bien reçus. Pour l'instant, on a
|
||||
whatsupdoc, niomniom, vert, redisdead, ragnarok, gordon, et quatre switches
|
||||
(bata-n n in {0, 1, 2, 4}).
|
||||
|
||||
Il faut faire attention lors du passage vers rsyslog pour komaz.
|
||||
|
||||
Ce n'est pas très long à faire, il s'agit juste de retirer syslogng sur les
|
||||
serveurs où il est installé, puis mettre rsyslog et faire un bcfg2. Il faut
|
||||
surtout trouver le temps.
|
||||
|
||||
Yann se charge de trouver un frontend potable. Dans le pire des cas, un
|
||||
frontend sera développé sous django.
|
||||
|
||||
### Baie de disques
|
||||
|
||||
Anne devrait envoyer un devis pour des disques supplémentaires d'ici demain.
|
||||
Un workshop est prévu le 26, sous réserve d'obtention des disques d'ici là.
|
||||
|
||||
### Virtualisation
|
||||
|
||||
La migration à chaud d'un dom0 à l'autre ne fonctionne pas. Les domU ont été
|
||||
déplacés sur fy afin de pouvoir mettre à jour fz sans souci (le noyau a quelques
|
||||
mises à jour de sécurité de retard). On verra ce que ça donne par la suite.
|
||||
|
||||
On peut utiliser ytrap-llatsni pour tester.
|
||||
|
||||
### Wifi
|
||||
|
||||
On va pouvoir renvoyer 30 des 33 !PicoStation à Inter Projekt, les trois
|
||||
suivantes seront utilisées malgré tout. Il faudra payer les frais de port, et
|
||||
on risque d'avoir du mal à couper aux 15%.
|
||||
|
||||
Après l'aller-retour des bornes, il faudra du monde pour déployer le tout.
|
||||
On prévoit ça pour le 2 juin.
|
||||
|
||||
### Clim 0B
|
||||
|
||||
La clim est en rade, la situation est devenue critique dans l’après-midi.
|
||||
Le technicien de LTC passe demain, il faut que quelqu’un soit là pour
|
||||
l’accueillir. PEB et Morgane sont disponibles, fonction de l'emploi du temps
|
||||
du premier, on fera signe à la seconde.
|
||||
|
||||
Il faudra aussi faire (un peu) attention cette nuit.
|
||||
|
||||
### Mise à jour de rouge
|
||||
|
||||
''A priori'', virtualiser rouge si on conserve Amavis, ça semble
|
||||
problématique (trop
|
||||
de ressources exigées). L'idée qui semble retenue est de passer le filtrage sur
|
||||
zamok, que l'on passerait sur fx (qui est toujours sous utilisé).
|
||||
|
||||
À faire en même temps que les tests sur la baie de disques (ou plutôt quand
|
||||
ceux-ci seront concluants).
|
||||
|
||||
### RAID
|
||||
|
||||
Le RAID sur ragnarok et sila nous ont envoyé une erreur "!DegradedArray". Elle
|
||||
a été corrigée.
|
||||
|
||||
La commande en question : {{{mdadm --manage /dev/mdX --add /dev/sdYZ}}} où mdX
|
||||
est l'array, et sdYZ le disque qui en a disparu (à trouver dans dmesg, il est
|
||||
écrit "md: kicking non-fresh sdXY from array!"
|
||||
|
||||
On va refaire un séminaire sur la gestion de disques (RAID, LVM) l'an prochain.
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### Limite de détection de virus
|
||||
|
||||
La limite de détection des floods est un peu basse (genre ouvrir safari avec 15
|
||||
onglets ça peut dépasser les limites de flood), il est donc suggéré de la
|
||||
monter à 20 détections de 150 connexions par seconde pour l'instant.
|
||||
|
||||
### Problèmes de mots de passe
|
||||
|
||||
Les mots de passe de deux apprentis ont apparemment changé dans la nuit de mardi
|
||||
à mercredi. On a strictement rien trouvé dans les logs. Il faut mettre en place
|
||||
le système de logs LDAP. (qui est en place sur LDAP test sur vo).
|
||||
|
||||
Olivier et Nicolas essaieront de s'en occuper sous peu. PEB viendra voir, pour
|
||||
rédiger de la doc.
|
||||
|
||||
### Firewall IPv6
|
||||
|
||||
Le démarrage du firewall IPv6 a été cassé par une mise à jour de config.py
|
||||
(disparition de main_proxy ou whatever). À corriger par quelqu'un qui a
|
||||
déjà touché à ce script...
|
||||
|
||||
On demandera à Valentin et Daniel de regarder.
|
||||
|
|
@ -0,0 +1,111 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 24 mai 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h10
|
||||
* Fin : 20h36
|
||||
|
||||
## Présents
|
||||
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Sylvain Boilard
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Sila
|
||||
|
||||
Il fait de la merde avec ses disques. C'est pas la faute des disques, ni de la
|
||||
carte SATA. On va utiliser vo comme miroir Debian temporaire, en attendant
|
||||
d'avoir
|
||||
une vraie solution, à choisir parmi :
|
||||
|
||||
* Acheter un nouveau serveur
|
||||
* Utiliser l'ancienne baie de disques et un serveur quelconque, une fois que la
|
||||
nouvelle aura pris le relais, ça implique d'acheter des disques pour la baie.
|
||||
|
||||
On part plutôt sur l'achat d'une nouvelle machine, un devis va être demandé à
|
||||
Anne
|
||||
et sera proposé au prochain C.A., avec les 2 possibilités.
|
||||
|
||||
### Wifi
|
||||
|
||||
#### MAJ de Windows 7
|
||||
|
||||
On constate que beaucoup d'adhérents n'arrivent plus à se connecter au wifi,
|
||||
une mise à jour de Windows 7 pourrait en être la cause. Cependant, certains avec
|
||||
une version à jour y arrivent encore. Il faudrait faire des tests :
|
||||
|
||||
* Est-ce que ça marche avec CransWifi ?
|
||||
* Est-ce que ça marche avec une configuration manuelle ?
|
||||
* Qu'est-ce qu'il y a dans les logs ?
|
||||
|
||||
PEB va envoyer un mail aux câbleurs pour qu'ils nous donnent un coup de main.
|
||||
|
||||
#### Picostations
|
||||
|
||||
Les pico sont arrivées en Pologne, on attend des nouvelles d'!InterProjekt.
|
||||
|
||||
### Workshops
|
||||
|
||||
#### Baie de disques
|
||||
|
||||
Il n'aura pas lieu ce WE, contrairement à ce qui a été prévu. On garde ça sous
|
||||
le
|
||||
coude, selon l'évolution de la commande de disques (devis, approbation ou non du
|
||||
CA, livraison).
|
||||
|
||||
#### Logs
|
||||
|
||||
Il faut passer les serveurs utilisant syslog-ng à rsyslog. Attention à komaz,
|
||||
car
|
||||
on a besoin de parser les logs. On fait ça ce WE. Appel aux apprentis motivés.
|
||||
|
||||
#### Wiki
|
||||
|
||||
L'idée est de remanier le wiki. Raphaël propose de fusionner CransNounous et
|
||||
CransTechnique. Réécrire la doc pour ce qui manque. Voir comment on gère la
|
||||
centralisation
|
||||
de la doc proposée dans le cadre de FedeRez.
|
||||
On prévoit un workshop ce WE, on peut en discuter d'ici là.
|
||||
|
||||
### Cranspasswords
|
||||
|
||||
Nicolas a commencé la réécriture d'un script cranspasswords, et Daniel a
|
||||
continué.
|
||||
Le script est actuellement en test sur vo dans /home/dstan/cranspasswords/
|
||||
(c'est un dépôt git). Le serveur est finalisé (cranspasswords-server) mais
|
||||
il reste quelques fonctions à implémenter côté client (le script qui doit être
|
||||
copié sur chaque machine de nounou).
|
||||
|
||||
Le principe: le serveur stocke plusieurs fichiers json. Chacun contenant:
|
||||
|
||||
* Une liste de rôles
|
||||
* Le mot de passe gpg chiffré avec l'ensemble des clés de toutes les personnes
|
||||
décrites par les rôles
|
||||
|
||||
Pour mettre à jour, il faut donc chiffrer à nouveau avec toutes les clés
|
||||
publiques
|
||||
correspondantes, et ceci s'effectue sur le client.
|
||||
|
||||
Pour l'instant, on peut lister les fichiers, voir et éditer les mots de passes.
|
||||
(du coup, pour l'utilisation basique ça serait bon.) Il faut implémenter la
|
||||
modification des rôles d'un fichier, la création et la suppression, qui se fait
|
||||
pour le moment à la main. Et la regénération des fichiers lors du changement
|
||||
des bénéficiaires d'un rôle. Le plus propre serait d'intégrer ça à LDAP.
|
||||
|
||||
Next step: que tout le monde ait une clé, et idéalement, convertir aussi les
|
||||
membres du CA/Bureau, pour la trésorerie par ex. Des rôles différents sont
|
||||
disponibles en lecture et écriture.
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### Kenobi, tu fais chier
|
||||
|
||||
On veut mettre fz à jour, donc on le migre sur fy.
|
||||
|
||||
### o2
|
||||
|
||||
Il semblerait qu'o2 ne sache pas envoyer des mails correctement. À étudier.
|
||||
|
|
@ -0,0 +1,89 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 06 juin 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h20
|
||||
* Fin : 20h33
|
||||
|
||||
## Présents
|
||||
|
||||
* Julien Baste
|
||||
* Kévin Viard
|
||||
* Morgane Jançon
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Sylvain Boilard (19h50)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Remplacement de sila
|
||||
|
||||
Le remplaçant de sila est arrivé. Il s'appellera charybde. PEB va encadrer son
|
||||
installation. Appel aux gens motivés.
|
||||
|
||||
### Migration à chaud des DomU
|
||||
|
||||
Olivier et PEB ont fait des tests de migration samedi. Ça marche. Ils en ont
|
||||
profité pour mettre à jour les dom0.
|
||||
Il y avait des soucis après la mise à jour de fz, il prenait toute la RAM par
|
||||
défaut, on a modifié /etc/default/grub, pour rajouter la mention sur la quantité
|
||||
de RAM que le dom0 a le droit d'utiliser (512 MB).
|
||||
|
||||
### Disques pour la baie
|
||||
|
||||
Olivier avait contacté Anne pour demander des disques pour la baie, car pour
|
||||
l'instant on a pas de disques de spare, il voulait des devis.
|
||||
|
||||
Plusieurs disques ont été proposés (dont du S-ATA), en 15 000 rpm, on peut
|
||||
monter à 600 Go, à 505 € HT l'unité. Sinon on a du SAS en 7 200 rpm à 305 €
|
||||
pour 1 To, 460 € pour 2 To, et 775 € pour 3 To, le tout hors taxe, et par unité.
|
||||
|
||||
On proposera un devis au C.A., après avoir pris le temps d'en discuter.
|
||||
|
||||
L'idée pour rester homogène serait de prendre les 600 Go à 15 000 rpm.
|
||||
|
||||
### Identification sur les news
|
||||
|
||||
Le conseil d'administration a demandé un audit auprès du collège des nounous
|
||||
concernant une éventuelle limitation d'accès en écriture sur les news. Raphaël
|
||||
est prêt à faire des tests, il installera inn2 sur vo.
|
||||
|
||||
A priori, il sera peut-être nécessaire d'interfacer LDAP et inn2, mais il n'est
|
||||
pas certain que ce soit facile.
|
||||
|
||||
### Clés usb
|
||||
|
||||
Un projet de clefs usb pour remplacer les t-shirts Cr@ns offerts lors de
|
||||
l'adhésion a été lancé, il a été demandé aux nounous de proposer des éléments
|
||||
à mettre dessus avant la rentrée.
|
||||
|
||||
Un LiveCD ubuntu a été proposé, ou bien framakey, une suite de logiciels libres.
|
||||
Il est peut-être possible de mettre les deux.
|
||||
|
||||
Kévin suggère de mettre putty sur ces clefs, pour que les utilisateurs de
|
||||
Windows aient un opérateur ssh accessible.
|
||||
|
||||
On peut sinon proposer notre propre suite logicielle pour ces clefs.
|
||||
|
||||
### Wiki
|
||||
|
||||
Raphaël a proposé de fusionner CransTechnique et CransNounous, il faut lister
|
||||
les pages concernées, les catégoriser, puis enfin, il faudra déplacer tout ça.
|
||||
|
||||
Déplacer les pages pourrait flinguer leur historique d'édition, il faudra
|
||||
vérifier cela avant de commencer à faire les opérations, ces historiques étant
|
||||
utiles. On se demande aussi s'il faut clairement séparer les parties
|
||||
administratives et techniques en termes d'architecture.
|
||||
|
||||
Raphaël voudrait avoir un retour concernant les idées qu'il a proposées.
|
||||
|
||||
Premier workshop lundi 11 au soir, à partir de 19h30.
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### Cranspasswords
|
||||
|
||||
Daniel demande aux nounous qui ne se sont pas encore inscrites dessus de le
|
||||
faire.
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 28 Juin 2012
|
||||
* Lieu : 2B
|
||||
* Début : 19h25
|
||||
* Fin : 20h47
|
||||
|
||||
## Présents
|
||||
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Sylvain Boilard
|
||||
|
||||
## Avancées
|
||||
|
||||
### Serveur FTP
|
||||
|
||||
Pierre-Elliott et Pauline ont installé charybde, le serveur FTP a été remis en
|
||||
route, ainsi que le miroir Debian et le serveur DNS. Daniel a remis en place les
|
||||
dépôts Git et gitweb. Reste à remettre darcsweb et le miroir opkg.
|
||||
Pierre-Elliott se charge de darcsweb.
|
||||
|
||||
### Carte des bornes Wifi
|
||||
|
||||
Daniel a mis en place une nouvelle carte des bornes sur l'intranet2
|
||||
<https://intranet2.crans.org/wifimap/>
|
||||
|
||||
Le but à terme est de pouvoir éditer les bornes directement depuis la carte
|
||||
(position, ssid disponibles etc.), voire afficher les ssid "pirates" qui
|
||||
pourraient être diffusés dans les alentours.
|
||||
|
||||
### Mises à jour
|
||||
|
||||
Quand on fait les mises à jour des serveurs, on lit correctement la liste des
|
||||
paquets qui vont être impactés, et surtout on teste _tous_ les services après
|
||||
la mise à jour.
|
||||
|
||||
## Projets
|
||||
|
||||
### SOGo
|
||||
|
||||
Vincent Le Gallic s'occupe de mettre en place SOGo, encadré par Pierre-Elliott.
|
||||
La partie
|
||||
authentification, client mail fonctionne, reste à voir pour les contacts et les
|
||||
agendas.
|
||||
|
||||
### Baie de disques
|
||||
|
||||
Deux disques ont été commandés pour la baie, ils arriveront... Bientôt.
|
||||
On va faire des tests dès que les disques seront arrivés. Olivier se chargera
|
||||
d'encadrer un éventuel apprenti motivé.
|
||||
|
||||
### Impression
|
||||
|
||||
Daniel a plusieurs suggestions pour améliorer le service d'impression, notamment
|
||||
une surveillance automatique de la fin des tâches.
|
||||
|
||||
Il faut également permettre aux adhérents d'annuler leur tâches non encore
|
||||
imprimées (avec crédit), ce qui faciliterait aussi la vie des imprimeurs en cas
|
||||
de bourrage et d'annulation de jobs en masse.
|
||||
|
||||
Il y a aussi l'interface écrite par Antoine Durand-Gasselin pour remplacer le
|
||||
driver foireux que l'on pourrait mettre en place, ou le module CUPS.
|
||||
|
||||
Vincent a l'air intéressé, mais il a déjà plein de choses dans sa fifo.
|
||||
|
||||
Avis aux autres apprentis...
|
||||
|
||||
### Miroir OpenWRT
|
||||
|
||||
Il y avait un dépôt opkg sur sila, on va essayer de faire un vrai miroir sur
|
||||
charybde. Il semblerait qu'il n'y ait pas de serveur rsync public chez
|
||||
OpenWRT, on va leur envoyer un mail pour demander. Raphaël s'occupe du mail et
|
||||
victimisera un apprenti pour écrire le script.
|
||||
|
||||
### Logs
|
||||
|
||||
#### Logs sur komaz
|
||||
|
||||
Il s'agit de remplacer syslog-ng par rsyslog qui a été choisi pour les logs
|
||||
centralisés. Le "problème", c'est qu'il y a des règles spéciales pour écrire
|
||||
les logs du firewall dans des fichiers séparés, qui sont "tail -F"és par des
|
||||
scripts (filtrage_firewall.py) qui vont écrire les infos dans la base de
|
||||
données pgsql de déconnexion.
|
||||
|
||||
Il suffit de réécrire la règle qui marche actuellement pour syslog-ng de façon à
|
||||
ce qu'elle marche pour rsyslog.
|
||||
|
||||
Pierre-Elliott s'ennuie ce soir, il regardera ça.
|
||||
|
||||
#### Anciens logs
|
||||
|
||||
La question est de savoir quoi faire des actuels logs "fichiers". Nicolas pense
|
||||
que tant qu'il n'y a pas de méthode plus simple qu'un select sur la base pour
|
||||
accéder aux logs dans pgsql, il vaut mieux les garder. *silent ping*
|
||||
|
||||
#### Frontend
|
||||
|
||||
Daniel propose d'écrire un nouveau script qui contacterait la base PGSQL pour
|
||||
faire les SELECT qui vont bien.
|
||||
|
||||
Daniel avait aussi fait un prototype dans l'interface d'administration de django
|
||||
|
||||
Enfin, Yann est censé regarder les frontends existants.
|
||||
|
||||
#### Purge de la base
|
||||
|
||||
La table des logs contient environ 60 millions d'entrées, les requêtes
|
||||
effectuées dessus impliquant des champs indexés, tout se passe merveilleusement
|
||||
bien, mais si la base doit être lue intégralement, les requêtes deviennent
|
||||
sensiblement plus lentes.
|
||||
|
||||
L'idée est de créer une seconde table qui contiendrait les données sur une durée
|
||||
d'un an, et la première servirait aux données sur un délai raisonnable. On
|
||||
placerait sur la table court terme un trigger qui copierait les données type
|
||||
mail.log, auth.log, radius, les logs des switches, etc. dans la base long terme.
|
||||
Deux scripts s'exécuteraient tous les jours pour virer les données périmées.
|
||||
|
||||
Pierre-Elliott proposera à Kévin Viard.
|
||||
|
||||
#### Logs des switchs / bornes Wifi
|
||||
|
||||
Il faut aller dire aux switchs d'envoyer leurs logs sur ragnarok. De même pour
|
||||
les bornes wifi.
|
||||
|
||||
## Questions diverses
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 06 septembre 2012
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h12
|
||||
* Fin : 21h20
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Steven Masfaraud
|
||||
* Valentin Samir
|
||||
* Vincent Guiraud
|
||||
* Vincent Le Gallic
|
||||
* Yann Duplouy
|
||||
|
||||
## Bilan des vacances
|
||||
|
||||
### Onduleur
|
||||
|
||||
Pulsar nous a lâché durant l'été, le module électronique était défaillant.
|
||||
Eaton nous en a renvoyé un, qu'on a mis en place durant la grosse mise à jour
|
||||
le 9 août.
|
||||
|
||||
Nicolas Dandrimont a proposé qu'on tire une seconde alimentation au 0B pour
|
||||
servir de relais, ondulée ou non, depuis le local TGBT.
|
||||
|
||||
Il faut attendre la fin de la rentrée, et éventuellement se faire une idée des
|
||||
comptes, pour faire des devis.
|
||||
|
||||
### Remplacement de la baie de disques
|
||||
|
||||
La baie de disques a enfin été remplacée, la migration s'est faite sans aucun
|
||||
souci, et les scripts d'interface ont été refaits.
|
||||
|
||||
L'ancienne baie est toujours rackée au 0B.
|
||||
|
||||
À long terme, il faudrait remplacer les cinq disques de 300 Go restants par des
|
||||
disques de 600 Go, voire plus s'il en existe d'ici là.
|
||||
|
||||
### Changement de serveur NFS
|
||||
|
||||
On a profité des changements massifs pour remplacer le nfs par une machine
|
||||
free (daath).
|
||||
|
||||
À long terme, remplacer daath par une machine sous garantie ne serait pas
|
||||
aberrant.
|
||||
|
||||
### Remplacement de zamok
|
||||
|
||||
Zamok a quitté son bel habit moisi pour aller dans celui de fx, qui venait de
|
||||
se faire mettre au chômage technique.
|
||||
|
||||
Ça swappe moins, ça a huit coeurs, 16 Go de RAM, et ça se tourne un peu les
|
||||
pouces, sauf quand spamassassin tourne.
|
||||
|
||||
### Suppression d'un MX
|
||||
|
||||
On a catapulté rouge dans le nether, parce que redisdead suffit.
|
||||
|
||||
freebox en profitait pour envoyer des mails, ce qui n'était pas normal. Par
|
||||
ailleurs, freebox.crans.org est blacklisté par un serveur mail.
|
||||
|
||||
### Ragnarok
|
||||
|
||||
Le serveur de logs est mort, il était déjà mort quand il gérait le wifi.
|
||||
Conclusion, on va arrêter de l'utiliser.
|
||||
|
||||
Il faut cependant le remplacer, dans un délai rapide. On va temporairement
|
||||
spoofer sur vo.
|
||||
|
||||
Une demande de devis pour un serveur (idéalement rackable) supportant le SATA
|
||||
sera faite. On le mettra au 0H s'il n'est pas rackable.
|
||||
|
||||
### Webmails
|
||||
|
||||
Vire-t-on horde ? Telle est la question.
|
||||
|
||||
L'idée est de rediriger webmail.crans.org vers une page d'informations listant
|
||||
les webmails disponibles.
|
||||
|
||||
SOGo marche, mais certaines implémentations restent à faire. Pour l'instant,
|
||||
mieux vaut proposer roundcube, et se donner quelques mois pour que Vincent
|
||||
s'occupe de SOGo.
|
||||
|
||||
## Projets
|
||||
|
||||
### Séminaires (non techniques)
|
||||
|
||||
Steven demande s'il est envisageable de faire des séminaires basiques sur
|
||||
l'utilisation des services du Crans.
|
||||
|
||||
Il trouve que les séminaires ont été réalisés jusqu'alors ne sont pas assez
|
||||
pédagogues. Certains s'y connaissent (la plupart des apprentis avaient de
|
||||
bonnes bases), et la majorité des personnes arrivant sur le campus n'ont pas
|
||||
forcément les compétences nécessaires.
|
||||
|
||||
Il suggère de rajouter, en plus des séminaires techniques, un certain nombre de
|
||||
séminaires grand public pour présenter l'utilisation des services du Cr@ns, de
|
||||
Linux, ou de LaTeX par exemple.
|
||||
|
||||
Pierre-Elliott rappelle que lors d'une réunion aux alentours de juin, un ou
|
||||
deux séminaires sur LaTeX avaient été prévus vers décembre.
|
||||
|
||||
* Présentation des services pour les adhérents (tv, mail, news, irc, gobby, …)
|
||||
* Installation de Linux
|
||||
* LaTeX (à prévoir vers décembre, faire de la pub auprès des départements)
|
||||
|
||||
### Séminaires
|
||||
|
||||
Une liste d'idées de séminaires a été ajoutée sur le wiki, donnez vos idées.
|
||||
Deadline : jeudi 4 octobre.
|
||||
Certains séminaires seront organisés sous la forme d'un atelier, notamment
|
||||
shell, python, GPG, réseau ?
|
||||
|
||||
### Ménage câbleurs/apprentis
|
||||
|
||||
Une liste des apprentis inconnus au bataillon a été faite. Olivier va s'occuper
|
||||
du ménage.
|
||||
|
||||
### WiFi
|
||||
|
||||
Valentin a fait un très joli logiciel pour le WiFi sous Windows Vista et Seven.
|
||||
|
||||
Il faudrait entamer un dossier à présenter au CROUS, pour installer le WiFi au
|
||||
G et au M.
|
||||
|
||||
!InterProjekt est en rupture de stock pour les bornes reparties en Pologne...
|
||||
On attend et on croise les doigts de pied.
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### Comptage upload ipv6 et extensions de vie privée
|
||||
|
||||
La connectivité ipv6 est actuellement proposée au Crans. Le comptage d'upload
|
||||
est par MAC-IP en ipv4 et 6. L'idée est d'autoriser les extensions de vie
|
||||
privée (attribuer une IP aléatoire), pour éviter qu'on puisse identifier les
|
||||
adhérents (leur adresse mac).
|
||||
|
||||
On souhaite rajouter au comptage d'upload les adresses mac des adhérents, pour
|
||||
que l'attribution aléatoire d'adresse soit possible. Valentin a commencé à
|
||||
faire des choses, il nous en dira plus au fil du temps.
|
||||
|
||||
### dnssec récursif
|
||||
|
||||
Valentin voudrait importer la clef de l'IANA dans bind pour que nos DNS
|
||||
puissent valider du DNSsec.
|
||||
|
|
@ -0,0 +1,103 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Mardi 2 octobre
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h
|
||||
* Fin :
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lilian Besson
|
||||
* Lucas Serrano
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Bonaque
|
||||
* Raphaël Cauderlier
|
||||
* Valentin Samir
|
||||
* Vincent Guiraud
|
||||
* Vincent Le Gallic
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Séminaires
|
||||
|
||||
Olivier explique aux apprentis l'intérêt général des séminaires, les apprentis
|
||||
peuvent y trouver une bonne occasion de découvrir un thème particulier.
|
||||
|
||||
On prévoit un premier séminaire le 16 octobre (présentation des services) qui
|
||||
sera davantage ciblé pour les adhérents tandis que le séminaire du 23 sera à
|
||||
destination des apprentis.
|
||||
|
||||
### Onduleurs
|
||||
|
||||
Plus d'onduleur au J, A, I, M, 2B. Des devis ont été reçus pour les remplacer.
|
||||
Pour 4 switchs, on arrive à 687€ HT
|
||||
Pour le bâtiment M (8 switchs): 857€ HT
|
||||
|
||||
Le problème de la température dans les locaux J et M se pose. On va demander
|
||||
de nouveaux devis pour des onduleurs non rackables (moins chers).
|
||||
|
||||
### Serveur de remplacement pour ragnarok
|
||||
|
||||
Pas de nouvelles pour un serveur de remplacement. Le standard pour les disques
|
||||
semble avoir changé chez HP. À vérifier.
|
||||
|
||||
On reste en attendant sur une config temporaire sur vo pour récupérer les logs.
|
||||
|
||||
### Réflexion sur la continuité des services "à vie" du Cr@ns
|
||||
|
||||
(pendant/après le déménagement de l'école)
|
||||
|
||||
Ce point vient d'une rencontre avec Barbich' au resto de l'X
|
||||
Avec les discussions en cours pour la migration à Saclay, plusieurs questions
|
||||
se posent sur la continuité des services du Cr@ns, si l'association ne dispose
|
||||
pas de matériel sur le nouveau site. L'idée est de proposer un schéma de
|
||||
migration
|
||||
des services vers un hébergement à long terme.
|
||||
|
||||
On en rediscute avant décembre avec Cyril Cohen (qui avait soulevé ce point).
|
||||
|
||||
### Mailing Lists
|
||||
|
||||
PE suggère de faire le ménage parmi les mailing lists. On peut regarder
|
||||
l'ancienneté
|
||||
des archives afin de déterminer si elles sont toujours utilisées. Pour les MLs
|
||||
non archivées, on peut envoyer un message pour demander s'il y a toujours de la
|
||||
vie.
|
||||
|
||||
Raphaël Cauderlier propose de synchroniser les clubs et leurs mailing-lists.
|
||||
On peut aussi donner un moyen simple d'aliaser le mail du club avec leur
|
||||
mailing-list.
|
||||
|
||||
Lilian et Lucas sont motivés pour regarder ça avec Daniel.
|
||||
|
||||
### Promotion nounou
|
||||
|
||||
Le collège technique nomme Vincent nounou. Du coup, il va falloir refaire un
|
||||
double de la boîte à clé et de l'armoire serveur (PE s'en charge.)
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Imprimante
|
||||
|
||||
Il se passe deux trois trucs tout de même
|
||||
Une planche a été mise pour fermer la fenêtre. Conséquemment, la porte ne se
|
||||
claque plus. Il faut trouver un groom avec plus de force.
|
||||
|
||||
Pauline a discuté avec le CROUS pour avoir les plans, ou au moins le cahier des
|
||||
charges, du 4J et est allée demander les plans au service de l'urbanisme de la
|
||||
mairie.
|
||||
|
||||
#### Personnel ENS
|
||||
|
||||
Ca fonctionne toujours aussi bien, Valentin à rajouté le routage du multicaste.
|
||||
On envisage de placer directement les personnels sur le vlan adhérent, et de
|
||||
voir ce qui arrive.
|
||||
|
||||
#### Organisation du collège technique
|
||||
|
||||
Pauline a posé plusieurs questions, un résumé d'ici peu.
|
||||
|
|
@ -0,0 +1,195 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Mardi 30 octobre 2012
|
||||
* Lieu : 2B
|
||||
* Début : 18h30
|
||||
* Fin : 22h07
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lilian Besson
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Bornes Wifi
|
||||
|
||||
Les !PicoStations sont arrivées.
|
||||
|
||||
* On a un problème : avec les anciennes comme avec les nouvelles bornes, il
|
||||
arrive qu'au bout d'un temps aléatoire les utilisateurs n'arrivent pas à
|
||||
aller plus loin que le DHCP. Une solution proposée est de faire un script qui
|
||||
monitore ça, et qui relance ce qu'il faut ("wifi" semble suffire, mais on
|
||||
peut décider selon les cas de rebooter la borne). De plus, hostapd semble
|
||||
segfaulter sur certaines bornes, il est suggéré d'installer monit sur les
|
||||
bornes, à voir si c'est suffisant. Daniel et Valentin vont voir ce qu'ils
|
||||
peuvent faire.
|
||||
* Pour le flashage : il faut des volontaires. On fera ça au fur et à mesure,
|
||||
appel aux intéressés.
|
||||
* Feature potentiellement intéressante des nouvelles bornes : il serait
|
||||
possible de faire de l'authentification Pre-Shared-Key avec une clé
|
||||
différente par MAC. Revers de la médaille : on ne peut plus valider le
|
||||
certificat radius, donc possibilités de bornes pirates. Il pourrait y avoir
|
||||
d'autres problèmes de sécurité si la borne connait le mot de passe en clair
|
||||
de l'utilisateur.
|
||||
* Étant donné qu'on va pouvoir recycler les anciennes bornes, il serait
|
||||
intéressant d'essayer de faire fonctionner la dernière version d'OpenWRT
|
||||
dessus. On va voir au cas par cas ce qu'on peut récupérer.
|
||||
* En attendant d'avoir une réponse du CROUS pour l'installation de nouvelles
|
||||
bornes, on peut déjà remplacer les anciennes bornes dans les faux-plafonds
|
||||
par des nouvelles. Ça implique de ressertir les câbles PoE maison. Avis aux
|
||||
intéressés.
|
||||
* On n'a toujours pas les plans des bâtiments, donc pour l'instant le dossier
|
||||
pour le CROUS est en attente
|
||||
|
||||
### Logs
|
||||
|
||||
#### Serveur
|
||||
|
||||
* On a reçu un devis de la part de notre fournisseur : même gamme que fx, fy et
|
||||
sable. Cela fait peut-être un peu overkill, surtout que l'on est en train de
|
||||
migrer les services qui sont sur sable. Le serveur est a
|
||||
priori 100% modulaire, mais cher.
|
||||
* Pas de SATA sur sable, mais du SAS, vu qu'on est en train de migrer les
|
||||
services de sables vers des domU, il pourrait être envisageable d'acheter des
|
||||
disques SAS et d'utiliser sable comme serveur de log.
|
||||
|
||||
On va demander des précisions/des nouveaux devis pour les différentes solutions
|
||||
suivantes :
|
||||
|
||||
* Acheter le serveur (2500€ + éventuellement les disques → 3120€)
|
||||
* Demander un serveur moins cher mais rackable (disques inclus)
|
||||
* Utiliser sable en demandant seulement des disques SAS
|
||||
* Extension de garantie pour sable ?
|
||||
|
||||
Il faut réfléchir à l'espace disque nécessaire.
|
||||
Olivier s'occupera ensuite de demander les devis.
|
||||
|
||||
#### DomU pour les consulter
|
||||
|
||||
Daniel a créé un DomU de log qui récupère ceux de gordon (afin d'avoir des
|
||||
données dans la base). Yann va configurer un frontend sur cette machine.
|
||||
|
||||
#### Envoi des logs
|
||||
|
||||
Vu que ragnarok n'est plus, et qu'on a des soucis pour récupérer les logs sur
|
||||
vo,
|
||||
on désactive cette fonctionnalité.
|
||||
|
||||
Seuls gordon (et donc les bornes WiFi) et news envoient leurs logs au domU, on
|
||||
va rajouter quelques serveurs supplémentaires pour avoir une petite base de
|
||||
données
|
||||
qui reste représentative, ceci afin de développer et tester le frontend.
|
||||
|
||||
#### Logs d'Apache
|
||||
|
||||
Apache n'utilise pas syslog. Il faut interfacer Apache avec syslog. On peut dire
|
||||
à Apache d'envoyer ses logs à un programme externe. Valentin s'en charge.
|
||||
|
||||
### DHCP
|
||||
|
||||
Valentin a créé un DomU (dhcp) centralisant tous les dhcp. Il a donc une patte
|
||||
sur tous nos VLAN sur lequel le service est présent (adhérent, wifi, accueil,
|
||||
isolement, appartement, install party).
|
||||
|
||||
Les switchs ont été reconfigurés pour le dhcp snooping, désormais sur tous les
|
||||
vlans. Seul bata-3 n'a pas été reconfiguré car il semble mal configuré pour
|
||||
un réglage à distance. Une fois que ce problème sera réglé et après
|
||||
vérification,
|
||||
on pourra couper les anciens services (sur sable, gordon, titanic). Pour
|
||||
l'instant,
|
||||
les serveurs fonctionnent en parallèle.
|
||||
|
||||
### Réunion avec la DSI
|
||||
|
||||
Il faut organiser une réunion avec la DSI.
|
||||
|
||||
Ordre du jour :
|
||||
|
||||
* Réunion périodiques ? (nouvelles têtes, coucou c'est nous)
|
||||
* Personnels NATés sur Renater
|
||||
* Plans du réseau
|
||||
* Gigabit
|
||||
* Clef placard (On a une clef du placard qui emprisonne ilona, mais elle est
|
||||
endommagée. On peut leur demander la leur pour faire un double.)
|
||||
* IPv6 (Rubis il est méchant)
|
||||
* Étoiler le PDJ. (minigiga.new() → 0P)
|
||||
* conf bato-1 (agrégation des deux fibres disponibles) : accès à l'autocom
|
||||
nécessaire
|
||||
|
||||
### Passage de LDAP à PostgreSQL
|
||||
|
||||
Vincent Le Gallic a remis ça sur la table. Pourquoi ça a été abandonné ? Mis
|
||||
à part le boulot niveau scripts crans, pourquoi pourrait-on ne pas vouloir y
|
||||
retourner ?
|
||||
|
||||
Premièrement parce qu'on ne peut pas "mettre à part" le boulot au niveau des
|
||||
scripts : personne ne les améliore pour LDAP, je ne vois pas pourquoi ça serait
|
||||
plus facile de les refaire from scratch...
|
||||
|
||||
Deuxièmement parce que l'intégration de LDAP à tous les services est
|
||||
éprouvée (authentification, radius wifi, postfix, dovecot, apache...),
|
||||
contrairement à celle de postgresql (libnss-pgsql avait tendance à segfaulter
|
||||
aléatoirement)
|
||||
|
||||
Troisièmement parce qu'il y a des choses plus utiles et plus intéressantes à
|
||||
faire. Notre fonctionnement autour de LDAP est correct, pourquoi repartir de
|
||||
zéro ?
|
||||
-- NicolasDandrimont <<DateTime(2012-10-30T11:50:52+0200)>>
|
||||
Les réplicat SQL ont tendance à se désynchroniser et ne pas toujours super
|
||||
bien fonctionner.
|
||||
|
||||
On oublie ce point pour l'instant, au vu des réponses, un jour… peut-être…
|
||||
|
||||
### Switchs du bâtiment G
|
||||
|
||||
## Daniel propose d'enlever des switchs inutiles au bâtiment G
|
||||
|
||||
batg-2 et batg-7 pourraient être libérés pour remplacer des switchs en fault,
|
||||
en mettant des adhérents sur les switches gigabit. Il faudrait d'ailleurs faire
|
||||
jouer la garantie des switches défectueux. Ou les mettre à la poubelle/donner.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### DNSSEC
|
||||
|
||||
Valentin a activé la validation DNSSEC sur les résolveurs DNS du Cr@ns. Ça
|
||||
marche.
|
||||
|
||||
Le point suivant serait de signer la zone Cr@ns. (Valentin propose aux
|
||||
apprentis présents (hint : ∅))
|
||||
Ça consiste à faire des tests.
|
||||
Attention : il faudra penser à pusher la clé publique chaque année.
|
||||
|
||||
#### PXE
|
||||
|
||||
Valentin veut migrer le PXE de sable vers charybde.
|
||||
|
||||
#### Ménage Baie de disque
|
||||
|
||||
Pierre-Elliott fera le ménage dans la baie de disques.
|
||||
|
||||
#### DomU routage
|
||||
|
||||
Valentin, toujours dans son idée de nettoyer sable des services, pour l'utiliser
|
||||
à d'autres fins, souhaite créer un domU de routage spécialisé pour les
|
||||
VLANs appartement, isolement, accueil, etc…
|
||||
On y mettrait aussi un serveur web pour servir les pages de déconnexion et finir
|
||||
(lentement) de démanteler squid.
|
||||
|
||||
#### lc_ldap
|
||||
|
||||
Il faut finir de coder lc_ldap et le documenter (pas forcément dans cet ordre).
|
||||
Sont motivés : Pierre-Elliott, Vincent, Olivier.
|
||||
|
||||
#### Mails superflus
|
||||
|
||||
Vincent propose de passer en revue tous les mails reçus par les nounous afin
|
||||
d'alléger le débit de mails. Olivier regardera avec Vincent.
|
||||
|
|
@ -0,0 +1,84 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 15 novembre 2012
|
||||
* Lieu : Salle Condorcet puis Fonteneau (à partir de 20h)
|
||||
* Début : 19h23
|
||||
* Fin : 21h04
|
||||
|
||||
## Présents
|
||||
|
||||
* Anne Cazalet (Synaps)
|
||||
* Ariane Soret
|
||||
* Daniel Stan
|
||||
* Lilian Besson
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Raphaël-David Lasseri
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Serveur de logs
|
||||
|
||||
Anne nous présente le serveur présent dans le dernier devis. Pas de
|
||||
compatibilité
|
||||
possible avec les anciens disques durs. On partirait sur des nouveaux disques
|
||||
durs
|
||||
SAS (4*300G). C'est un serveur milieu de gamme.
|
||||
|
||||
### Garanties
|
||||
|
||||
Un point est fait sur les garanties des serveurs (date d'expiration,
|
||||
renouvellement)...
|
||||
|
||||
Cf. [[CatégorieCrans/LesServeurs]].
|
||||
|
||||
### Autour de LDAP
|
||||
|
||||
PEB a commencé à manipuler la base LDAP de test (en particulier avec la config
|
||||
qui est désormais une base LDAP). Il sait désormais modifier le schéma à la
|
||||
volée. Le but à terme et de travailler sur lc_ldap et de documenter à la fois
|
||||
le fonctionnement de ce script et de slapd et ses utilitaires.
|
||||
|
||||
A priori, le howto sera prêt pour le séminaire ldap, mais sûrement pas le
|
||||
binding.
|
||||
|
||||
### Wifi
|
||||
|
||||
Il faut définir une date de workshop flashage, au moins pour les bâtiments A, B,
|
||||
C. et envoyer un mail. On essaie d'en faire une dimanche prochain, si motivé,
|
||||
avis aux volontaires (apprentis).
|
||||
|
||||
Pierre-Elliott, Daniel et Ariane sont passés voir le directeur de la résidence
|
||||
qui nous a affirmé que le Crous de Créteil était favorable
|
||||
au projet WiFi. Pauline souhaiterait un accord écrit pour éviter tout problème.
|
||||
En attendant, il leur a proposé de rencontrer rapidement le responsable
|
||||
patrimoine vendredi 16 lors de sa rencontre avec le Bde.
|
||||
|
||||
### Install Party
|
||||
|
||||
On installe Ubuntu par défaut. Si Debian, faire attention, l'installeur est
|
||||
toujours (partiellement) pété.
|
||||
Le plus grand dilemme réside dans le choix de l'interface graphique : Unity,
|
||||
Gnome,
|
||||
ou Xfce ?
|
||||
|
||||
Pauline propose que des gens soient dédiés à la présentation de différentes
|
||||
distributions/interfaces et soulève le problème de pédagogie des nounous. Elle
|
||||
préférerait que les installés soient davantage assistés dans leurs installations
|
||||
plutôt qu'une nounou s'occupe de tout. Il est en effet proposé de présenter une
|
||||
distribution Linux (celle de l'encadrant) pendant l'installation.
|
||||
|
||||
Le PXE est accessible depuis peu (merci Valentin) sur le vlan accueil, donc
|
||||
sans enregistrer l'ordinateur. Il faudrait donc obtenir ce réseau en untagged
|
||||
à la Kfet.
|
||||
|
||||
### Nounou encadrante
|
||||
|
||||
Mettre à jour la page CransNounous, à défaut de précisions, la nounou encadrante
|
||||
est celle qui a donné les droits.
|
||||
|
|
@ -0,0 +1,143 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 29 Novembre
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h22
|
||||
* Fin : 21h26
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Florian Tilquin
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Raphaël Cauderlier
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vincent Le-Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Quotas
|
||||
|
||||
Les quotas sont maintenant fonctionnels à travers NFS. Si la limite "soft" est
|
||||
dépassée, un mail est envoyé (par jour). Si la limite hard du quota
|
||||
est dépassée, l'appel système write retourne une erreur. On mettrait 2Go en
|
||||
limite soft et 2Go + e (e~=200Mo) de limite hard. Pierre-Elliott
|
||||
suggère d'activer les quotas sur zamok pour les adhérents.
|
||||
|
||||
Les quotas traversent le NFS, il faudrait mettre en application lesdits
|
||||
quotas sur tous les comptes, puis éventuellement lever ceux des membres actifs,
|
||||
quitte à définir des conditions.
|
||||
Il faut également tester si gest_crans les applique bien quelle que soit la
|
||||
méthode de création de compte crans.
|
||||
|
||||
### Wifi
|
||||
|
||||
On a commencé au A, il faut continuer, le CROUS étant d'accord pour la pose.
|
||||
État du flashage : au moins la moitié des Pico Stations et des Nano Stations
|
||||
du M ont été flashées.
|
||||
Des Pico Stations ont été posées aux 2, 4 et 6ème étages du bâtiment A.
|
||||
Valentin a commandé un tire-câble pour commencer à câbler au M.
|
||||
Il reste du travail, on va faire ça au fur et à mesure, quand on aura des
|
||||
apprentis motivés. On propose un framadate :
|
||||
<http://framadate.org/rmcll82zw6p3fw75>
|
||||
|
||||
### Réunion DSI
|
||||
|
||||
Gaetan, Raphaël, Morgane et Olivier ont rencontré la DSI (Stuart Mc``Lellan et
|
||||
Jocelyn Viallon) le 19 novembre.
|
||||
|
||||
#### Débit
|
||||
|
||||
L'ENS a un argrément gigabit avec Renater. Dans un premier temps, l'ENS nous
|
||||
autorise l'utilisation de 500Mbit/s entre 19h et 6h30. Komaz a l'air de souffrir
|
||||
par moments. En revanche, (cf graphes munin) on ne sature pas (après quelques
|
||||
minutes de load élevé). On va demander si on peut être débridés le week-end.
|
||||
|
||||
#### Câblage du PdJ
|
||||
|
||||
On peut avoir accès au sous-sol du PdJ, il faut décider du switch et de la date.
|
||||
|
||||
Daniel propose un
|
||||
HP 1910-8G (JG348A) <http://h10010.www1.hp.com/wwpc/fr/fr/sm/WF06b/12883-12883-4172267-4172281-4172281-4218346-5257664.html?dnr=1>
|
||||
|
||||
Il a l'air d'avoir toutes les fonctionnalités nécessaires (IGMP + MLD snooping,
|
||||
vlans). Le seul inconvénient est le management http(s)-only.
|
||||
|
||||
On proposera le devis au C.A..
|
||||
|
||||
#### Eduroam au PdJ
|
||||
|
||||
Le C.A. a accepté la demande de la DSI concernant la diffusion d'eduroam au
|
||||
pavillon des jardins. Il nous faudra le mot de passe radius de l'E.N.S. pour le
|
||||
faire, et installer quelques picostations au PdJ.
|
||||
|
||||
Il faudra ouvrir un VLAN pour cela.
|
||||
|
||||
#### Réunions Crans/DSI/DSI des dpts/labos
|
||||
|
||||
La DSI avait proposé qu'on participe à leur réunion de mardi dernier. Mais on a
|
||||
pas été recontactés. Olivier va leur envoyer un email pour plannifier la
|
||||
réunion suivante.
|
||||
|
||||
#### Miroir debian de l'E.N.S.
|
||||
|
||||
L'école voudrait nous confier la gestion de son miroir debian officiel.
|
||||
|
||||
#### IPv6
|
||||
|
||||
Le Crans est prêt, Rubis est prêt, l'E.N.S. non, pour des raisons
|
||||
administratives
|
||||
apparemment.
|
||||
|
||||
### Surveillance de la correspondance MAC / chambre
|
||||
|
||||
Suite à la détection d'un spoofeur de MAC de longue date. Valentin et Daniel
|
||||
envisagent de passer à une authentification par mot de passe sur le réseau
|
||||
filaire.
|
||||
Pierre-Elliott va bientôt mettre en place un script de surveillance utilisant
|
||||
les données fournies par les switchs (en snmp). Dans tous les cas, il faut
|
||||
un script de surveillance plus efficace que "déménagement non déclaré".
|
||||
|
||||
### Monitoring du climat du 4J
|
||||
|
||||
Olivier a fait une mini station météo qui se trouve au 4J pour surveiller
|
||||
l'évolution de l'humidité et de la température.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Remplacement switches HP
|
||||
|
||||
On a remplacé 4 switches défectueux au niveau de HP. Pierre-Elliott recommencera
|
||||
dans un mois avec les suivants.
|
||||
|
||||
#### club-bde@zamok /usr/sbin/rssh
|
||||
|
||||
Vincent demande si on peut changer le shell du bde sur zamok.
|
||||
Parce backup-manager uploade des fichiers de backups sur le home Cr@ns du bde
|
||||
mais il ne peut pas les supprimer parce qu'un ssh lui est refusé.
|
||||
|
||||
En fait c'est --(impossible)-- compliqué.
|
||||
|
||||
#### Switch manageable à la Kfêt
|
||||
|
||||
À faire s'il nous en reste. Le remplacement des switchs en fault dans les
|
||||
bâtiments
|
||||
reste prioritaire.
|
||||
|
||||
#### Ldap
|
||||
|
||||
olcLogging: il n'est pas possible de laisser les logs dans la même
|
||||
racine que les données logguées. Cela va compliquer l'implémentation de lc_ldap.
|
||||
On rappelle que la base ldap est censée stocker les chaînes en utf-8.
|
||||
So``Go et le champ mail : notre champ mail contient uniquement
|
||||
l'utilisateur (sans
|
||||
@crans.org). Normalement, la sémantique de ce champ est une adresse mail
|
||||
complète
|
||||
ce qui fait planter So``Go. Il faudrait donc changer cette valeur, et faire
|
||||
attention
|
||||
à tous les services que l'on risque de casser, ou utiliser un autre champ, ce
|
||||
qui
|
||||
produira une redondance dans les données. Des tests restent à faire.
|
||||
|
|
@ -0,0 +1,127 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 13 Décembre 2012
|
||||
* Lieu : Salle Condorcet
|
||||
* Début : 19h25
|
||||
* Fin :
|
||||
|
||||
## Présents
|
||||
|
||||
* Aymeric Labatut
|
||||
* Daniel Stan
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Serveur de logs
|
||||
|
||||
Thot est installé (wheezy), et reçoit des données de tous les serveurs. Il faut
|
||||
voir si on souhaite modifier les requêtes d'insertion SQL, et donc la base de
|
||||
données.
|
||||
La priorité : définir la structure de base de données qu'on veut, pour pouvoir
|
||||
écrire
|
||||
les requêtes qu'on veut et qu'on mette le système en service.
|
||||
|
||||
Les services sur pgsql (comptage d'upload, filtrage firewall, correspondance
|
||||
mac-prise)
|
||||
seront migrés sur thot.
|
||||
Valentin fait remarquer qu'il peut être bien de conserver un réplicat de la
|
||||
correspondance mac-prise, nécessaire à l'authentification radius.
|
||||
|
||||
### Prochaine Debian stable
|
||||
|
||||
Wheezy est bientôt dans les bacs.
|
||||
|
||||
#### Repackaging de Bcfg2
|
||||
|
||||
Le nouveau bcfg2 n'est pas compatible avec l'ancien, on a donc tout migré vers
|
||||
la
|
||||
nouvelle version.
|
||||
|
||||
À savoir : les balises !ConfigFile, Directory, Symlink sont devenues Path, les
|
||||
scripts
|
||||
python ont leur propre balise Python.
|
||||
|
||||
Reste à remettre en service bcfg2-repo-validate (utilisé par darcs).
|
||||
|
||||
#### Passage sous wheezy des serveurs du crans
|
||||
|
||||
A priori, pas avant que wheezy soit la nouvelle stable, mais il serait bien
|
||||
d'en discuter un peu avant.
|
||||
|
||||
Il faudra faire attention à
|
||||
|
||||
* dovecot
|
||||
* radius (l'appel de scripts externes est déprécié)
|
||||
* moinmoin (les patches vont bouder)
|
||||
* iscsi (sur les dom0 et le nfs)
|
||||
* portmap est déprécié (passage à rpcbind),
|
||||
|
||||
il peut être envisagé de mettre à jour daath en dernier pour éviter les clashes
|
||||
|
||||
Dans tous les cas, il va falloir se farcir les changelogs.
|
||||
|
||||
### Script mac_prises
|
||||
|
||||
On avait fait un script qui listait les adresses macs connectées dans chaque
|
||||
chambre, il faut ajouter des choses pour limiter au maximum le spoof non
|
||||
repérable.
|
||||
|
||||
Par exemple, cela vaut-il le coup que thot stocke en base de données le triplet
|
||||
(mac, date, prise(s)), et qu'on bosse avec ce genre de données ?
|
||||
|
||||
On va mettre une page sur le wiki pour des suggestions, et essayer de discuter
|
||||
avec
|
||||
le C.A., pour obtenir un réel cahier des charges. Après on commencera.
|
||||
|
||||
### Installation des nouvelles bornes wifi
|
||||
|
||||
Quelques bornes ont été placées au M, d'autres au A, il faut continuer, et
|
||||
trouver
|
||||
des apprentis motivés !
|
||||
|
||||
### Lien Gigabit vers l'extérieur
|
||||
|
||||
Prochainement, une réunion avec la DSI pour parler gigabit le weekend, et
|
||||
éventuellement augmenter un peu en journée.
|
||||
|
||||
### TV
|
||||
|
||||
Daniel a testé la diffusion de la TV avec un Raspberry Pi. Ça lag, à voir si
|
||||
c'est
|
||||
parce que ça capte mal ou parce que manifestement l'USB et l'Ethernet passent
|
||||
par
|
||||
le même bus sur la carte.
|
||||
Les serveurs free n'étaient, à l'époque où ils ont été reçus, pas compatibles
|
||||
avec
|
||||
les cartes, il faudrait voir pour quelle raison.
|
||||
Il faudrait réfléchir à d'autres solutions.
|
||||
|
||||
Quid de l'amplification des signaux TNT ?
|
||||
|
||||
#### HD
|
||||
|
||||
Vu que la HD n'est pas supportée par tous les PC, et que "c'est l'avenir", on
|
||||
pourrait
|
||||
imaginer baisser la résolution pour que les gens qui n'ont pas une machine assez
|
||||
puissante puissent quand même regarder la TV. Problème : ça demande de la
|
||||
puissance
|
||||
de calcul... À voir si on a envie de le faire.
|
||||
|
||||
Dans un premier temps, on pourrait passer le flux TV d'une chaîne vers malloc
|
||||
ou une autre machine pour faire des tests de transcodage.
|
||||
|
||||
### Divers
|
||||
|
||||
#### Imprimante
|
||||
|
||||
On va appeler Thomas Hocine pour lui dire que le service après-vente ne
|
||||
respecte pas vraiment les
|
||||
clients, et que par conséquent, le C.A. s'interroge vraiment sur la pertinence
|
||||
de signer
|
||||
le contrat.
|
||||
|
|
@ -0,0 +1,223 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 10 janvier 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h16
|
||||
* Fin : 21h36
|
||||
|
||||
## Présents
|
||||
|
||||
* Ariane Soret
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Olivier Iffrig
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Bonaque
|
||||
* Raphaël Cauderlier
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Gmail
|
||||
|
||||
Depuis mi-décembre, Gmail refuse de récupérer les mails depuis les serveurs
|
||||
dont il ne reconnaît pas la validité de l'autorité de certification, CACert
|
||||
faisant partie des autorités non reconnues
|
||||
Depuis le 12/12/12, Gmail a changé sa politique de vérification des certificats
|
||||
SSL, CAcert ne fait plus partie des autorités de certification reconnues comme
|
||||
"de confiance" et les utilisateurs ne peuvent pas changer ce comportement.
|
||||
|
||||
Les adhérents Cr@ns ne peuvent donc plus relever leurs mails Cr@ns sur leur
|
||||
boîte Gmail.
|
||||
|
||||
La situation et la marche à suivre pour les adhérents sont ici :
|
||||
<https://wiki.crans.org/VieCrans/GMailSucks>
|
||||
|
||||
Le Cr@ns pourrait proposer un autre serveur imap avec un certificat d'une autre
|
||||
autorité.
|
||||
En dehors du problème idéologique et de "flemme", cette solution implique tout
|
||||
de même de continuer à encourager les adhérent à donner leur mot de passe Cr@ns
|
||||
à Google.
|
||||
|
||||
L'avis général semble être plutôt de rester dans la situation actuelle.
|
||||
Daniel (avec un apprenti [les absents, levez la main]) va tout de même essayer
|
||||
de mettre en place un serveur imap alternatif.
|
||||
|
||||
Valentin soulève la question d'un mot de passe alternatif (optionnel) permettant
|
||||
de s'authentifier sur les serveurs mail / imap / ... seulement.
|
||||
À voir si c'est possible.
|
||||
|
||||
### SIP
|
||||
|
||||
Le SIP (Session Initiation Protocol) est un protocole de signalement
|
||||
permettant de mettre en relation deux pairs. Il est principalement
|
||||
utilisé dans le cadre de la téléphonie sur Internet (Voix sur IP).
|
||||
|
||||
{{{asterisk}}} a été ressuscité et le Cr@ns possède une ligne SIP chez OVH.
|
||||
Le service a donc été mis en place et est maintenant disponible pour les
|
||||
adhérents.
|
||||
Modulo l'installation d'un client SIP et une connexion internet,
|
||||
les adhérents peuvent donc téléphoner. Dans un premier temps entre comptes SIP
|
||||
Cr@ns, mais il y a également une passerelle vers l'extérieur.
|
||||
|
||||
L'interface sur l'intranet2 permet l'inscription, la gestion de sa configuration
|
||||
(mot de passe, code perso de la messagerie, se masquer dans l'annuaire), un
|
||||
annuaire…
|
||||
|
||||
Pour les utilisateurs, c'est en test : <https://intranet2.crans.org/voip/>
|
||||
|
||||
Reste à faire :
|
||||
|
||||
* Documentation technique
|
||||
* Documentation d'utilisation (Yann s'occupe d'Android, iOS ?)
|
||||
* Facturation de la passerelle (prix coûtant? On utilise le compte impression?)
|
||||
* Service d'impression ? (notification des impressions, dictée du digicode)
|
||||
* Numéro unique vers la Nounou d'astreinte ?
|
||||
|
||||
Bref, il y a plein de possibilités.
|
||||
|
||||
### DNS
|
||||
|
||||
#### DNSSEC
|
||||
|
||||
DNSsec est une extension du protocole DNS qui permet de signer numériquement
|
||||
les réponses des requêtes DNS.
|
||||
|
||||
Elle (l'extension) a été mise en place par Valentin sur le domaine
|
||||
{{{crans.eu}}}.
|
||||
|
||||
À terme, il serait bien de signer {{{crans.org}}}
|
||||
|
||||
Il n'est pas possible pour un serveur de répondre qu'il a effectuer une
|
||||
validation
|
||||
dnssec s'il est autoritaire pour la réponse.
|
||||
Il pourrait être bien de séparer DNS récursif et autoritaires.
|
||||
|
||||
#### Renouvellement nom de domaine
|
||||
|
||||
{{{crans.fr}}} expire dans une cinquantaine de jours. Il ''faut'' le renouveler.
|
||||
Olivier s'en occupe.
|
||||
|
||||
#### Champs DNS
|
||||
|
||||
Valentin a rajouté un champ TXT dans les réponses DNS des bornes wifi,
|
||||
qui contient : {{{"LOC %f,%f" % (latitude, longitude)}}}.
|
||||
|
||||
Il désirerait aussi rajouter un champ SSHFP pour pouvoir transmettre les
|
||||
fingerprints SSH des serveurs. Combiné à DNSSEC, cela permettrait de s'assurer
|
||||
de l'absence de Man in the Middle quand on se connecte à un serveur en SSH.
|
||||
|
||||
À étudier plus profondément.
|
||||
|
||||
### Documentation Sphinx
|
||||
|
||||
Olivier a mis en place de quoi documenter le nouveau binding LDAP avec Sphinx
|
||||
C'est une librairie pour python qui permet de générer automatiquement de la
|
||||
documentation.
|
||||
|
||||
Olivier l'a mise en place pour {{{lc_ldap}}}. C'est beau, il faut continuer.
|
||||
|
||||
### Wifi
|
||||
|
||||
Le bâtiment M est couvert sur tous les étages sauf le 4ème et le 5ème Nord.
|
||||
Le bâtiment A est couvert aux étages pairs.
|
||||
Le reste est à faire.
|
||||
|
||||
On va fixer un rendez-vous régulier, par exemple le dimanche une fois tous les
|
||||
quinze jours.
|
||||
|
||||
### IRC
|
||||
|
||||
Dancer-ircd, le daemon IRC actuel, ne semble plus très maintenu et manque de
|
||||
features, principalement un support de SSL et de l'ipv6.
|
||||
On souhaiterait donc changer de daemon pour quelque chose de plus moderne.
|
||||
|
||||
UnrealIRCd semble bien mais n'est pas package pour Debian (voir
|
||||
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130>)
|
||||
|
||||
daemons packages sous squeeze :
|
||||
|
||||
* dancer-ircd
|
||||
* inspircd
|
||||
* ircd-hybrid
|
||||
* ircd-irc2
|
||||
* ircd-ircu
|
||||
* ircd-ratbox
|
||||
* ngircd
|
||||
|
||||
Supportant SSL d'apres
|
||||
<https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons>
|
||||
|
||||
* inspircd
|
||||
* ircd-hybrid
|
||||
* ircd-ratbox
|
||||
* ngircd
|
||||
|
||||
Supportant l'IPv6 d’après la même page: tous
|
||||
|
||||
inspircd ftw ?
|
||||
|
||||
Pierre-Elliott va se pencher sur inspircd qui a l'air packagé, supportant SSL,
|
||||
IPv6 et pas trop "pain in the ass" à configurer.
|
||||
|
||||
Il faudra contre-annoncer pour dire que finalement on ne fera pas de changement
|
||||
Dimanche.
|
||||
|
||||
### Mail
|
||||
|
||||
#### Champ mail dans la base LDAP
|
||||
|
||||
Le champ mail a été modifié dans la base LDAP pour pouvoir être utilisé
|
||||
par !SoGo
|
||||
(c'est-à-dire que l'on enregistre dans tous les cas une adresse mail, et non le
|
||||
login lorsque l'adhérent a un compte Cr@ns). PE avait effectué dans un premier
|
||||
temps la modification sur son propre compte afin de chasser les bugs dans les
|
||||
scripts qui supposaient manipuler un login (et non une adresse mail).
|
||||
|
||||
#### Réécriture des en-têtes mail
|
||||
|
||||
Pendant un certain moment, dans les mails envoyés et reçus, toutes les adresses
|
||||
mails envoyées et reçues étaient automatiquement remplacées par
|
||||
Prenom.Nom@crans.org (''i.e.'' l'alias canonique). Cette réécriture a été
|
||||
désormais
|
||||
désactivée, ce qui a posé des problèmes pour déterminer le destinataire final
|
||||
du mail et il a fallu corriger après coup les filtres de recherches dans
|
||||
la configuration postfix.
|
||||
|
||||
Ceci explique quelques dysfonctionnements dans l'acheminement des mails pendant
|
||||
environ une semaine.
|
||||
|
||||
### Tests de configuration des services
|
||||
|
||||
Suite à ces problèmes, iota propose la mise en place de serveurs alternatifs
|
||||
afin de tester les configurations de services critiques.
|
||||
PEB a remplacé les adresses mail dans la base LDAP par leur version avec
|
||||
@crans.org. On a en même temps supprimé la réécriture d'en-tête des emails.
|
||||
Cela a malheureusement engendré des bugs, et la perte de mails.
|
||||
|
||||
De manière générale, il faut faire attention lorsqu'on touche à des services
|
||||
critiques en place dont on ne maîtrise pas la façon dont ils loguent
|
||||
(dovecot, postfix), bien lire la doc, et surtout demander aux développeurs
|
||||
des services si on a un doute concernant une fonctionnalité.
|
||||
|
||||
### Bug tracking, projets
|
||||
|
||||
On a deux bug trackers, debbugs (<http://bugs.crans.org>) et
|
||||
redmine (<https://tracker.crans.org>), plus éventuellement des todolists sur le
|
||||
wiki.
|
||||
L'idée est de se décider sur lequel on utilise. On garde redmine.
|
||||
|
||||
Raphaël propose également d'utiliser une catégorie wiki !CategorieProjetEnCours.
|
||||
|
||||
### Passage à Git
|
||||
|
||||
Deux outils de versionnement présente plusieurs inconvénients :
|
||||
|
||||
* Plus de commandes à connaître, et risque de s'embrouiller
|
||||
* Nos dépôts darcs ne sont pas à jour.
|
||||
|
||||
On se propose de passer nos dépôts darcs sous git.
|
||||
Vincent et Daniel s'en occupent et encadreront Pauline.
|
||||
|
|
@ -0,0 +1,109 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : 24 Janvier 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h27
|
||||
* Fin : 21h17
|
||||
|
||||
## Présents
|
||||
|
||||
* Ariane Soret
|
||||
* Daniel Stan
|
||||
* Olivier Iffrig
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Raphaël-David Lasseri
|
||||
* Sylvain Boilard
|
||||
* Thomas Epalle
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
* Yann Duplouy
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Script d'impression par l'interface web
|
||||
|
||||
L'impression par le driver de l'imprimante sur {{{zamok}}} pose certains
|
||||
problèmes
|
||||
qui sont évités quand on fait des impressions manuelles, c'est pourquoi il avait
|
||||
été proposé d'automatiser l'impression par l'interface web de l'imprimante de
|
||||
manière à ne plus avoir à se servir du driver.
|
||||
|
||||
Ce travail peut être fait par un apprenti. Ariane est motivée. Vincent encadre.
|
||||
|
||||
### Groupe fuse sur zamok
|
||||
|
||||
Valentin propose d'autoriser les utilisateurs à utiliser fuse sur zamok. On
|
||||
évitera d'autoriser la lecture aux autres utilisateurs que le propriétaire
|
||||
(potentiels problèmes d'upload par apache, updatedb, etc)
|
||||
|
||||
On ajoute le groupe fuse à ldap pour y mettre tous les utilisateurs
|
||||
|
||||
### Identification des machines dans l'annuaire LDAP
|
||||
|
||||
cf. mail de PEB sur nounous@ du 23 janvier à 05:56
|
||||
Actuellement un mid est associé, par le biais d'une fonction inversible à une
|
||||
adresse ip.
|
||||
Cela force la réutilisation des mid au cours des ans et est gênant pour
|
||||
l'identifiaction d'une machine sur le long terme. Il est proposé de rendre le
|
||||
mid strictement croissant et le remplacer par un rid.
|
||||
Il sera également utilisé pour attribuer un préfixe ipv6 aux machines.
|
||||
De plus, il devient possible de libérer les adresses ips tout en gardant dans la
|
||||
base de donnée les adresses mac des machines (avant, il fallait absoluement
|
||||
supprimer
|
||||
la machine pour libérer le mid et l'ip associé)
|
||||
|
||||
Il est proposé de garder une plage de mid libre de 1 à 4096 par exemple pour les
|
||||
machines crans (serveurs, adm, bornes wifi, …)
|
||||
puis de commencer à utiliser de façon continue les mid à partir de là.
|
||||
|
||||
### Documentation des scripts
|
||||
|
||||
Olivier a commencé à ajouter une documentation sphinx au nouveau binding LDAP.
|
||||
Reste la question du serveur web.
|
||||
Il pourait être bien de remplacer l'apache de niomniom par nginx ; à des fins de
|
||||
test, on pourrait faire tourner nginx sur un autre port en parallèle d'apache,
|
||||
le temps de porter la configuration d'apache sous nginx.
|
||||
|
||||
### Recâblage du PdJ
|
||||
|
||||
Le switch est arrivé.
|
||||
C'est fait, modulo utilisation du gbic intégré: il nous faut plus de jarretières
|
||||
optiques (brassage <-> gbic).
|
||||
Le plan de câblage sera prochainement mis à jour.
|
||||
|
||||
### Routage du WiFi
|
||||
|
||||
On a commencé à vider gordon de ses services : eap pour l'auth wpa2 et
|
||||
routage direct via komaz (résout les prob liés au routage)
|
||||
log direct via thot, dns sur les serveurs du vlan adhérent.
|
||||
|
||||
### Démission du RTC
|
||||
|
||||
Olivier déménage et démissionne de son poste de RTC. Valentin prend la
|
||||
succession.
|
||||
|
||||
## Question Diverses
|
||||
|
||||
### Séparation des dns récursif et autoritaires
|
||||
|
||||
Valentin est en train de faire la configuration adéquate.
|
||||
De plus, la déléguation du reverse dns des ips allouées au crans par l'ens n'est
|
||||
propagée correctement. En effet sur les 4 NS parent, un seul d'entre eux
|
||||
(ariane.ens-cachant.fr) délègue les plages vers les NS du crans.
|
||||
|
||||
### Incident Matinal
|
||||
|
||||
Suite sans doute à un incident de communication entre fz et la baie de disque,
|
||||
les domu présents sur icelui n'ont plus été en mesure d'assurer leurs services
|
||||
respectifs. Vert étant parmis eux, cela a affecté l'ensemble des serveurs du
|
||||
crans.
|
||||
Les domu ont été migrés vers fy. Komaz, zamok, sable,… ont été redémarrés.
|
||||
|
||||
### Augmentation du débit le week-end
|
||||
|
||||
Cf mail sur dsi-crans puis Nounou, la DSI est d'accord pour accorder une
|
||||
augmentation du débit le week-end à 500Mbit/s. Cette augmentation sera valable
|
||||
du vendredi 20h30 au lundi 6h00.
|
||||
|
||||
* le mail disait 20h. -- ZeldAurore <<DateTime(2013-01-25T12:59:56+0200)>>
|
||||
|
|
@ -0,0 +1,148 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 7 Février
|
||||
* Lieu : devant le Condorcet
|
||||
* Début : 20h08
|
||||
* Fin : 22h25
|
||||
|
||||
## Présents
|
||||
|
||||
* Ariane Soret
|
||||
* Daniel Stan
|
||||
* Pierre-Elliott Bécue
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vincent Guiraud
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Mac/Prise
|
||||
|
||||
Pierre-Elliott a continué à coder mac-prise en utilisant une base postgres.
|
||||
Il compte le nombre de mac pour une chambre donnée sur plusieurs intervalles
|
||||
(2 min, 30 min, 1 jour). Il y a plusieurs heuristiques qui donnent des
|
||||
valeurs différentes ("très suspect", "suspect") plus ou moins fonction du
|
||||
nombre de fois qu'une même mac apparaît dans le réseau et du nombre de mac
|
||||
apparaissant sur une prise et du temps.
|
||||
|
||||
Il est suggéré de ne pas tenir compte des macs inconnues qui pourraient être
|
||||
récupérée (mac virtuelle, jamais enregistrées), si le script devient trop
|
||||
verbeux.
|
||||
|
||||
Pour l'instant, il est en test sur une ml du même nom, et sera mis en prod
|
||||
après quelques réglages.
|
||||
|
||||
Le script effectue de nombreux appel à ldap, il est donc envisagé de mettre un
|
||||
réplicat sur thot.
|
||||
|
||||
### Passage à Git
|
||||
|
||||
Le dépôt /usr/scripts est migré. (il ne faut plus record sur darcs)
|
||||
Il faut supprimer les mail de darcs whatnews et avoir avoir un équivalent pour
|
||||
git.
|
||||
Le dépot bare se trouve sur git.crans.org qui est public, il faudrait vérifier
|
||||
qu'il n'y a pas de mot de passe recordé dedans au cas où (grep).
|
||||
|
||||
On peut migrer bcfg2 n'importe quand. Il faut finir de tout recorder avant.
|
||||
|
||||
Il reste à trouver un joli hook pour les mails (genre modifs non
|
||||
commitées/pushées)
|
||||
voire une vérif d'intégrité : vérifier que le dépot bare et de prod aient la
|
||||
même HEAD.
|
||||
|
||||
### WiFi
|
||||
|
||||
#### Ipv6
|
||||
|
||||
On annonce un slash ipv6 en wifi, ça marche. (Parce que Daniel a une machine
|
||||
ipv6 only chez lui)
|
||||
|
||||
#### Freecwmp
|
||||
|
||||
freecwmp, implémentation du protocole CWMP pour openwrt destiné à contrôler à
|
||||
distance des équipement divers, dont nos bornes wifi.
|
||||
Trois élèves du département informatique ont travaillé sur un projet autour de
|
||||
ce protocole, et se disent qu'il serait pratique de l'utiliser pour configurer
|
||||
nos bornes avec et de garder le moins de configuration possible dans la branche
|
||||
openwrt du crans afin de faciliter son maintien.
|
||||
|
||||
Le serveur de configuration est actuellement en cours d'écriture comme une
|
||||
application django.
|
||||
|
||||
#### Arpej'
|
||||
|
||||
Arpej (aka résidence Volti) est une résidence privée mitoyenne au campus où de
|
||||
nombreux élèves de l'ENS logent.
|
||||
Elsa Perdrix à rappelé qu'il y avait eu autrefois un projet de faire un pont
|
||||
wifi pour relier le bâtiment au réseau.
|
||||
Il y a normalement encore une borne sur le toit du d'Alembert pour ça. Quand à
|
||||
celle de l'Arpej'…
|
||||
|
||||
Daniel fait remarquer que cela ajoute une charge de travail supplémentaire sur
|
||||
les membres actifs et que la viabilité à long terme d'un pont wifi est
|
||||
incertaine.
|
||||
|
||||
Il faudrait voir à nouveau avec l'ENS s'il existe un tunnel jusqu'à
|
||||
l'Arpej' pour
|
||||
tirer une fibre.
|
||||
|
||||
#### Pdj
|
||||
|
||||
La dsi aimerait bien qu'on diffuse eduroam au PDJ pour les chercheur visiteur.
|
||||
Pour ça il faut des bornes :
|
||||
|
||||
* Combien ?
|
||||
* On les mets où ?
|
||||
|
||||
Il faut faire des tests de couverture, faire un dossier et demander un budget
|
||||
au CA.
|
||||
Pour mettre des bornes dans les faux plafonds il faut l'accord de la DGS.
|
||||
|
||||
On essaiera de faire les tests ce week-end.
|
||||
|
||||
### Firewall
|
||||
|
||||
#### Comptage Upload
|
||||
|
||||
Il faut adapter le comptage d'upload à l'ipv6 pour pouvoir compter par mac, et
|
||||
éventuellement faire évoluer la déconnexion.
|
||||
Actuellement il y a un petit programme qui rempli une table d'association
|
||||
mac-ip, il est envisageable d'effectuer une jointure.
|
||||
|
||||
Un autre problème est que pour compter directement par mac, il faudrait compter
|
||||
sur l'interface interieure, et qu'alors, on comptera également du traffic
|
||||
potentiellement rejeté par le firewall.
|
||||
|
||||
#### Filtrage p2p
|
||||
|
||||
le filtrage p2p devient **vraiment** obsolète, avec de plus en plus de faux
|
||||
positif,
|
||||
Valentin voudrait s'en débarrasser.
|
||||
Il faut demander à la dsi si on peut le jetter.
|
||||
Le problème est l'adhérent faisant du piratage : C'est la dsi qui reçoit les
|
||||
lettres des ayant droits et cela pose un problème de réputation de l'École.
|
||||
|
||||
Il est envisageable de continuer de bloquer ce que l'on détecte mais de ne plus
|
||||
déconnecter les gens.
|
||||
|
||||
/!\ Il faut discuter de ce point au prochain CA
|
||||
|
||||
#### Déconnection pour upload
|
||||
|
||||
Actuellement les adhérents dépassant 4Go/24h de téléchargement se font
|
||||
déconnecter pour 24h.
|
||||
Il est proposé de juste brider la vitesse de ceux dépassant la limite.
|
||||
|
||||
Il faut définir à quel point.
|
||||
On peut penser les mettre derrière la freebox puisqu'elle ne sert plus à rien
|
||||
en temps normal
|
||||
|
||||
/!\ Il faut discuter de ce point au prochain CA
|
||||
|
||||
### Réunion DSI
|
||||
|
||||
* Réverse dns
|
||||
* filtrage p2p
|
||||
* upload
|
||||
* eduroam au Pdj : mdp du serveur radius, voir comment on fait…
|
||||
* null route sur le /16
|
||||
|
|
@ -0,0 +1,128 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 7 mars 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h42
|
||||
* Fin : 21h42
|
||||
|
||||
## Présents
|
||||
|
||||
* Ariane Soret
|
||||
* Daniel Stan
|
||||
* Olivier Iffrig
|
||||
* Sylvain Boilard
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Réunion DSI
|
||||
|
||||
Valentin et Daniel sont passés voir la DSI la semaine dernière (suite à la
|
||||
découverte par Sabrina d'une borne wifi).
|
||||
Les gens du Léonard de Vinci veulent du wifi, elle voulait donc voir si on
|
||||
pouvait remettre les anciennes bornes, ou même des nouvelles.
|
||||
On leur a d'ailleurs prêté le lendemain une pico pour leur montrer à quoi elles
|
||||
ressemblent.
|
||||
|
||||
La DSI veut à terme pouvoir jeter les wifi ouvert et ne laisser que eduroam.
|
||||
Puis utiliser un outils comme !PacketFence pour effectuer de la délégation vers
|
||||
les labo/dpt pour les autorisations d'accès.
|
||||
|
||||
Nous avons été invités à la réunion des DSI des divers département du lendemain.
|
||||
Parmi les points évoqués, le fait de scanner le home des adhérents à la
|
||||
recherche de virus semble une bonne idée.
|
||||
|
||||
### Documentation
|
||||
|
||||
Il ''FAUT'' mettre à jour les lien vers les pages wiki déplacées. Une idée des
|
||||
pages concernées peut s'obtenir à l'aide du listing des pages
|
||||
orphelines : <https://wiki.crans.org/OrphanedPages>
|
||||
Le plus simple étant d'effectuer une recherche sur le nom de l'ancienne page et
|
||||
de modifier les résultats trouvés.
|
||||
|
||||
Une restructuration du Wiki a été entamée par Pauline, il reste aussi à
|
||||
documenter de nombreux services.
|
||||
Avis aux nounous (et apprentis) ayant installé un de ces services non
|
||||
documentés.
|
||||
|
||||
Côté doc Sphinx : il faut l'utiliser, documenter ce qui ne l'est pas. (make
|
||||
coverage, make html).
|
||||
par exemple, la liste des objets non documenté
|
||||
dans {{{lc_ldap}}} : <http://doc.crans.org/lc_ldap/coverage.html>
|
||||
|
||||
### Instabilité de la connexion
|
||||
|
||||
Des problèmes de connexions de faible durée ont eu lieu la semaine dernière.
|
||||
Rien à signaler sur le réseau du Cr@ns,
|
||||
cela vient vraisemblablement du lien Renater, cf
|
||||
<http://pasillo.renater.fr/TICKETS/historique-tickets.incidents.html>
|
||||
|
||||
### Résidence Jacques Restignat
|
||||
|
||||
Ariane a rappelé le gérant de la résidence aujourd'hui. Il n'a pas encore
|
||||
acheté de borne WiFi (il pensait le faire lui-même).
|
||||
Un devis a été demandé chez Orange.
|
||||
|
||||
La question de la connexion à Internet elle-même n'a pas été rediscutée mais
|
||||
doit être étudiée.
|
||||
|
||||
### CAS
|
||||
|
||||
Il reste à synchroniser les comptes Wiki et LDAP (la gestion sur l'intranet est
|
||||
OK) pour pouvoir mettre le CAS sur le Wiki.
|
||||
Les webmail SOGo et Horde restent aussi à faire (la DSI nous a conseillé pour
|
||||
SOGo).
|
||||
|
||||
### Logs Ldap / generate
|
||||
|
||||
Il devient de plus en plus urgent de journaliser les modifications effectuées
|
||||
via le nouveau binding lc_ldap.
|
||||
On pensait utiliser olcAccess avec un attribut last_modifier sur chaque objet
|
||||
pour savoir qui a fait la modification. Ainsi, on
|
||||
peut utiliser une connexion cn=admin tout en maintenant une trace des auteurs
|
||||
des modifications.
|
||||
|
||||
Il serait alors possible de lire la base de log pour generate (en se souvenant
|
||||
de l'endroit où on s'était arrêté).
|
||||
|
||||
Il faudrait également revoir le système de lock qui actuellement entre en
|
||||
conflit avec un certain nombre d'exécution
|
||||
automatique de scripts. En effet, le système actuel semble être ennuyant pour
|
||||
les utilisateurs, et peu efficace pour la
|
||||
sûreté des scripts (un objet locké provoque un arrêt complet du script, pour
|
||||
exception non rattrapée même dans un cron).
|
||||
On pourrait utiliser un système plus souple de vérification, au moment de la
|
||||
modification, si une modification a eu lieu depuis la lecture de
|
||||
l'objet.
|
||||
|
||||
### Migration vers git
|
||||
|
||||
Les dépôts bcfg2 et usr-scripts sont passés sur git. Les hooks de notification
|
||||
irc et mails sont fonctionnels.
|
||||
Il faut migrer les dépôts usr-scripts des serveurs n'ayant pas de NFS (ovh et
|
||||
les dom0).
|
||||
Il reste également à passer les dépôts des /etc/ des serveurs sous git. Ceci
|
||||
permettrait de gérer les permissions sur les fichiers.
|
||||
|
||||
La question est de savoir si ces dépôts sont considérés privés ou si on évite
|
||||
de mettre des mots de passes sensibles dedans.
|
||||
On peut aussi, quitte à éviter les mots de passes en clair, abandonner le
|
||||
versionnement des /etc/ et utiliser uniquement
|
||||
la génération des configurations via bcfg2.
|
||||
|
||||
### Solution de partage de fichiers
|
||||
|
||||
Le BDE et les associations partenaires ont demandé un espace de travail pour le
|
||||
groupe de travail sur la convention de vie étudiante.
|
||||
Il n'ont pas de cahier des charges précis, on peut leur proposer :
|
||||
|
||||
* Un wiki sur une page perso club (Aurore MM. est en train de voir ce qu'elle
|
||||
peut tirer de !DokuWiki)
|
||||
* Etherpad
|
||||
* [SparkleShare](http://sparkleshare.org/)
|
||||
|
||||
### SPAM
|
||||
|
||||
On se fait plus spammer qu'avant.
|
||||
Il a été émis l'idée que le greylisting pourrait chier dans la colle. À voir.
|
||||
|
|
@ -0,0 +1,233 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 4 avril 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h30
|
||||
* Fin : 21h34
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Pauline Pommeret
|
||||
* Raphaël-David Lasseri
|
||||
* Thomas Epalle
|
||||
* Valentin Samir
|
||||
* Vincent Guiraud
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Pénurie d'IPv4
|
||||
|
||||
Valentin a fait un petit ménage dans les IP wifis, nous sommes passés
|
||||
de 98% à 92% :
|
||||
<http://munin.crans.org/association.crans.org/adresses-ip/index.html>
|
||||
|
||||
C'est néanmoins préoccupant.
|
||||
|
||||
19 "personnes" sans aucuns droits possèdent plus de 5 machines, 42 en ont plus
|
||||
de 4 machines wifi.
|
||||
|
||||
On peut supprimer les machines qui ne se sont pas connectées depuis un certain
|
||||
temps (en parsant les logs d'authentification wifi) ou donner des IP dynamiques
|
||||
en wifi.
|
||||
Lors du changement de bornes, la même IP serait attribuée. La deuxième option
|
||||
est plus difficile à mettre en place.
|
||||
|
||||
La première solution est plus simple à mettre en place mais elle est moins
|
||||
efficace. Valentin pense que ça prendra 1h30 à
|
||||
une nounou, un apprenti peut être encadré pour faire le script.
|
||||
Qu'est ce qu'une machine sans activité ? Pour l'instant, c'est 1 an. On peut
|
||||
envisager d'envoyer un mail aux propriétaires des
|
||||
machines qui ne se sont pas connectées en wifi depuis {{{n}}} mois leur
|
||||
demandant s'ils souhaitent toujours conserver cette machine
|
||||
(par exemple en cas de stage de plusieurs mois).
|
||||
|
||||
Lorsque la machine s'authentifie à freeradius, si elle n'a pas d'IP, elle
|
||||
bascule sur Cr@ns-accueil ("tu n'as pas d'IP attribuée, clique ici pour en
|
||||
obtenir une"). "Cela demande un travail non nul" (Daniel). L'ancien
|
||||
binding LDAP présuppose qu'une machine a une unique IP.
|
||||
Mettre une IP par défaut, c'est mal et ça prendra autant de temps que de
|
||||
patcher l'ancien binding.
|
||||
|
||||
Est-ce qu'on s'accélère pour mettre en place
|
||||
l'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'intranet, le taggage de vlan sur
|
||||
les bornes et freeradius, le parefeu, etc.
|
||||
|
||||
(NB: on en peut pas mettre les IPv6-only et
|
||||
les IPv4 et IPv6 sur le même réseau, sinon
|
||||
tout devient IPv6-only.)
|
||||
|
||||
Il ne faut pas lancer le script qui supprime les IP avant que les adhérents
|
||||
aient la possibilité de récupérer une IP.
|
||||
Il faudra également envoyer un mail aux adhérents leur expliquant tout ça.
|
||||
|
||||
Il faut faire un script qui lit les logs de l'authentification wifi et met à
|
||||
jour une base de données.
|
||||
|
||||
Thomas, Lucas et Pauline sont motivés, Daniel se charge de les coacher, de les
|
||||
motiver et de les inspirer.
|
||||
|
||||
### Nouveau firewall
|
||||
|
||||
Valentin a commencé à réécrire le firewall IPv4, en utilisant le nouveau
|
||||
binding (optimisation mémoire de lc_ldap à la
|
||||
clé \o/) en le
|
||||
remettant au propre. Il est conçu pour faciliter la mise à jour des blacklist
|
||||
et la gestion de la QoS (partage et limitation des débits). Il se
|
||||
génère aussi plus vite que l'ancien.
|
||||
Actuellement, il est assez sale et illisible, à cause des rajouts successif de
|
||||
petits bouts de-ci de-là depuis … longtemps.
|
||||
|
||||
Il y a un pare-feu
|
||||
sur komaz mais aussi
|
||||
sur 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 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 komaz avant le passage
|
||||
à {{{wheezy}}}, parce que l'ancien ne marchera plus !
|
||||
|
||||
A priori, sous {{{wheezy}}}, il n'y aura qu'à appliquer la configuration
|
||||
d'{{{iptables}}}, ce qui sera plus efficace que la façon de faire
|
||||
actuelle.
|
||||
|
||||
### WiFi
|
||||
|
||||
#### Avancement
|
||||
|
||||
La couverture wifi au H a été grandement amélioré avec l'ajout de 4 nouvelles
|
||||
bornes wifi.
|
||||
Le J est en cours de couverture (Ariane, Thomas, Vincent Guiraud et
|
||||
Raphaël-David continuent ce dimanche).
|
||||
|
||||
Il reste le G, le C, et à terminer le A et B. Quitte à changer les bornes du C,
|
||||
il faudra changer le switch dans le local ménage/électrique
|
||||
du 5C (les switchs Dlink ne supportent pas le multicast).
|
||||
|
||||
#### Tests de couverture au PdJ
|
||||
|
||||
Il faut faire des tests de couverture au PdJ afin de prévoir le nombre de
|
||||
bornes à commander. Cela consiste à poser une borne et regarder jusqu'où on
|
||||
arrive à la capter.
|
||||
|
||||
Il faut voir avec la DSI les modèles de bornes qu'elle compte acheter afin
|
||||
d'envisager une commande groupée.
|
||||
|
||||
Daniel a un coup de cœur pour les Ubiquiti UniFi Long Range
|
||||
avec 2 antennes (même prix que les bornes actuelles mais plus puissantes).
|
||||
|
||||
Si l'on achète des bornes, on pourrait en prévoir pour le plafond de la salle
|
||||
de conférence du PdJ (grande capacité d'utilisateurs).
|
||||
|
||||
#### Parlons CROUS
|
||||
|
||||
Un habitant du rdc du bâtiment M veut qu'on arrive à tirer un câble jusque chez
|
||||
lui et passer sur le brassage Cr@ns. Mais, c'est manifestement interdit. Il ne
|
||||
capte pas non plus sur le wifi chez lui.
|
||||
|
||||
Au bâtiment H, un câble a été tiré à l'arrache par le CROUS il y a un peu plus
|
||||
d'un an. Cette personne est adhérente au CROUS,
|
||||
il faut lui suggérer d'appeler la hotline.
|
||||
|
||||
Nous ne sommes, selon la charte Crans-CROUS-ENS, chargés que du brassage et pas
|
||||
de l'entretien des câbles et des prises.
|
||||
Effectivement, il s'agit de propriétés du CROUS.
|
||||
|
||||
### Miroirs
|
||||
|
||||
#### Debian officiel
|
||||
|
||||
Valentin et Raphaël-David sont passés à la DSI au sujet de la gestion du miroir
|
||||
Debian officiel de l'ENS. Il suffit donc d'envoyer un
|
||||
mail disant que l'on a changé de machines puis prévenir la DSI. Il faut faire
|
||||
disparaître webb.ens-cachan.fr dans les listes des
|
||||
miroirs.
|
||||
|
||||
Il faut faire pointer {{{debian.ens-cachan.fr}}} vers notre miroir Debian.
|
||||
|
||||
Les {{{iso}}} Debian prennent énormément de place, mais a priori nous ne sommes
|
||||
pas obligés de les avoir. (ouf !)
|
||||
|
||||
Notre miroir supporte la charge, s'il est plébiscité on pourrait envisager de
|
||||
rajouter de la RAM à Charybde.
|
||||
|
||||
Charybde ne sera plus bridé.
|
||||
|
||||
#### VideoLAN
|
||||
|
||||
Nous étions miroir de VidéoLAN par le passé, le dépôt vlc est d'ailleurs
|
||||
toujours synchronisé sur notre ftp. Ils demandent à faire
|
||||
revivre le partenariat. Le problème est qu'ils souhaiteraient une
|
||||
connectivité gigabit ce qui n'est actuellement pas le cas. On leur
|
||||
répond que nous sommes d'accord pour devenir miroir officiel dans la limite de
|
||||
nos moyens (bande passante
|
||||
limitée).
|
||||
|
||||
### Contrat Mécénat de Free
|
||||
|
||||
Un contrat de mécénat a été passé avec la fondation d'entreprise Free, qui nous
|
||||
fournit gracieusement deux serveurs
|
||||
(Dell, 16 Go de RAM, 2To, Xeon E3 2.4GHz).
|
||||
|
||||
Parmis les projets de ces serveurs : NFS des adhérents, virtualisation de
|
||||
machines pour les clubs, transcodage vers la 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 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 jeudi 11 avril 2013].
|
||||
Daniel s'en charge.
|
||||
|
||||
### Rencontre avec MiNET
|
||||
|
||||
Il faudrait préparer des présentations sur ce que l'on fait au Cr@ns, ils le
|
||||
verront aussi de leur côté.
|
||||
|
||||
On pourrait parler du service d'impression, séparation administratif et
|
||||
technique, fonctionnement général, nos perspectives et
|
||||
envies (demander à Gaétan, formation 1ères années).
|
||||
|
||||
Au vu de la disponibilité générale et des autres évènements (samedi plateau
|
||||
le 20, journées des M2, interludes le week-end du 27),
|
||||
il est envisagé d'organiser cet événement dans l'après-midi du
|
||||
dimanche 21 avril.
|
||||
|
||||
On demande la Kfet au BdE.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Analyse AntiVirus des mails
|
||||
|
||||
Pauline se demande pourquoi le Cr@ns n'analyse plus les mails en vue d'une
|
||||
détection de virus.
|
||||
Valentin répond que les virus par mail ont pratiquement disparut d'après les
|
||||
statistiques de scan d'amavis/clamav et les
|
||||
utilisateurs ont appris leur existence.
|
||||
|
||||
#### Nagios
|
||||
|
||||
Faut faire des tests.
|
||||
|
||||
#### DomU de test
|
||||
|
||||
Il est décidé de créer
|
||||
un domU sans adm où les apprentis sont root et peuvent faire des tests.
|
||||
|
|
@ -0,0 +1,152 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : 18 Avril 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h22
|
||||
* Fin : 21h21
|
||||
|
||||
## Présents
|
||||
|
||||
* Ariane Soret
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Valentin Samir
|
||||
* Pierre-Elliott Becue
|
||||
* Raphaël-David Lasseri
|
||||
* Thomas Épalle
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Serveurs Free
|
||||
|
||||
Il sont au 2B, il y en a 2, des 1U avec des kits de rackages.
|
||||
Ils sont neufs.
|
||||
|
||||
* L'un va être utilisé pour remplacer le serveur NFS actuel.
|
||||
* On va essayer de tester la carte TV dans l'autre, mais à priori, il n'y a pas
|
||||
assez de port PCIe dedans pour que ça soit intéressant. Il pourrait également
|
||||
être utilisé pour proposer des VM aux clubs.
|
||||
|
||||
Il est marqué dans le contrat de mettre sur le [site](http://www.crans.org) un
|
||||
logo de la Fondation Free.
|
||||
|
||||
### Intranet 2
|
||||
|
||||
#### Gestion des prises / Chambres
|
||||
|
||||
Valentin a commencé à développer un module pour l'intranet2, pour les accès
|
||||
prises/chambres.
|
||||
L'idée est de n'autoriser une machine à se connecter que dans une liste de
|
||||
chambres fournie par l'adhérent sur l'intranet.
|
||||
Il reste à l'interfacer avec radius, et à voir s'il est actif par défaut.
|
||||
Il est envisageable de tout préparer techniquement puis d'envoyer un mail à
|
||||
tous les adhérents pour les prévenir d'une date d'activation.
|
||||
Pierre-Elliott soulève qu'il ne lui semble pas acceptable d'imposer à ceux
|
||||
souhaitant accéder en filaire à Internet depuis une autre chambre que la leur
|
||||
d'avoir un compte Crans.
|
||||
Il est rappelé qu'il est également possible d'utiliser de
|
||||
l’authentification 802.1x. !MiNet l'utilise et ne semble pas rencontrer de
|
||||
problèmes particulier On le leur demandera ce week-end.
|
||||
La liste des chambres autorisées est actuellement dans la base pgsql switch.
|
||||
Pierre-Elliott à suggéré de rajouter un champ ldap
|
||||
multivalué {{{PriseAutorisee}}} par exemple. Cela à l'avantage de garder autant
|
||||
que faire se peut les données des adhérents dans une seule base de donnée et
|
||||
facilite ainsi sa gestion.
|
||||
|
||||
#### Migration
|
||||
|
||||
Il faut migrer vers l'intranet2 le plus rapidement
|
||||
possible : l'intranet 1 devient de plus en plus obsolète. Par exemple, il ne
|
||||
fonctionne pas sous IE10 (ce qui empêche les adhérents d'enregistrer eux même
|
||||
un nouveau PC sous Windows 8 qu'ils viennent d'acheter)
|
||||
Valentin a commencé à "copier" le module «Mes machines», il manque la création
|
||||
des machines (a priori possible avec le nouveau binding) et la suppression (pas
|
||||
encore implémenté dans le binding)
|
||||
Il manque un module pour imprimer, pour recharger son compte impression via
|
||||
paypal et pour gérer ses infos personnelles (monCompte) en ce qui concerne les
|
||||
adhérents lambda.
|
||||
Pierre-Elliott soulève qu'il ne lui semble pas acceptable de donner des
|
||||
commissions à une entreprise à chaque rechargement de compte impression et
|
||||
propose de supprimer (ou trouver une alternative à) la fonctionnalité.
|
||||
Les autres modules (digicodes, gestion des factures) doivent également migrer,
|
||||
mais comme cela ne concerne actuellement que les membre actifs, c'est un peu
|
||||
moins urgent.
|
||||
Daniel propose la mise en place d'une base pgsql pour la gestion des digicodes.
|
||||
|
||||
### Binding Ldap
|
||||
|
||||
Tous type d'objets est créable et modifiable (sauf l'objet facture).
|
||||
|
||||
#### Suppression
|
||||
|
||||
Il reste à implémenter la suppression : notamment la
|
||||
fonction "cimetière" permettant d'annuler une suppression en dumpant les donnée
|
||||
depuis la base de donnée vers un autre support.
|
||||
Actuellement (dans l'ancien binding) c'est un pickle de
|
||||
l'objet {{{python}}} correspondant écrit dans un fichier
|
||||
dans {{{/home/cimetiere/}}}.
|
||||
Il est envisagé de stocker une représentation plus lisible du ldif ldap
|
||||
correspondant (ini, json, …), sans doute dans un fichier.
|
||||
|
||||
#### Logs et historique
|
||||
|
||||
Pour les logs : accesslog + champ lastmodify pour savoir qui à fait la
|
||||
modification : La base ldap log elle même toutes les modifications.
|
||||
Pour l'historique : accesslog à l'air compliqué à parser du coup peut être
|
||||
garder le système actuel ou bien faire une base d'historique à coté.
|
||||
Le système actuel à l'inconvénient de faire grandir arbitrairement la taille
|
||||
d'un adhérent/d'une machine dans la base ldap ce qui alourdit sa manipulation
|
||||
via le binding.
|
||||
De plus, une fois l'objet détruit (par exemple, un adhérent détruit sa machine
|
||||
via l'intranet) son historique est détruit dans la foulée alors qu'on pourrait
|
||||
souhaiter le conserver.
|
||||
|
||||
#### Possibilité de préinscription ?
|
||||
|
||||
Avec des ordinateurs en libre service à la rentrée, ça irait peut être plus
|
||||
vite ?
|
||||
C'est faisable, mais est-ce que ça aurait vraiment un intérêt réel ?
|
||||
|
||||
### Passage à wheezy des serveurs mails
|
||||
|
||||
Pour se débarrasser des spams, postfix s'est doté d'un nouveau
|
||||
module : postscreen. Il n'est pas disponible sous squeeze, et de toute façon,
|
||||
wheezy approche de la release.
|
||||
Pierre-Elliott propose de les mettre à jour au 2B avec des apprentis après
|
||||
avoir envoyer un mail aux adhérents concerné pour les prévenir de l'instabilité
|
||||
du service mail durant la mise à jour.
|
||||
|
||||
### Routes sur titanic
|
||||
|
||||
Bah on ne peut pas parler à freebox en zone crans et on ne peut pas parler à
|
||||
titanic hors zone crans.
|
||||
Au vu des règles de routage, c'est normal.
|
||||
Il est possible de faire en sorte que ça marche via des {{{ip rules}}}, mais ça
|
||||
n'est pas vraiment important.
|
||||
|
||||
### Pare-feu, limitation upload
|
||||
|
||||
C'est en place, toutes les déconnexions pour upload sont dans une classe
|
||||
où l'upload est limité.
|
||||
Il faut remettre au propre l'échelle des sanctions en cas d'abus.
|
||||
|
||||
### Zone crans et wiki
|
||||
|
||||
Le kludge actuel ne semble plus fonctionner. A priori, il est possible
|
||||
d'obtenir le même résultat proprement en écrivant un module d'authentification
|
||||
Moinmoin <http://moinmo.in/HelpOnAuthentication>
|
||||
Vincent veut bien jeter un oeil. Lucas aussi.
|
||||
|
||||
### Install Party, mise en ligne des vidéo
|
||||
|
||||
Les fichiers audios des confs sont sur le site de l'install
|
||||
party (mp3 mono 32kbps).
|
||||
Qu'est ce qu'on fait avec les vidéos ?
|
||||
L'idée était de faire un gros carré avec les slides, un petit avec la vidéo et
|
||||
le son.
|
||||
|
||||
### Une machine pour les apprentis
|
||||
|
||||
Le domu pour les apprentis a été créé.
|
||||
Une formation pour se connecter au serveur est donnée en direct par Valentin.
|
||||
|
|
@ -0,0 +1,133 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 2 mai 2013
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h21
|
||||
* Fin : 20h40
|
||||
|
||||
## Présents
|
||||
|
||||
* Lucas Serrano
|
||||
* Nicolas Dandrimont
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Changement de NFS
|
||||
|
||||
Le serveur 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 zbee pour désactiver
|
||||
le protocole v4. C'est maintenant fait.
|
||||
|
||||
Sinon, on me souffle dans l'oreillette
|
||||
que charybde a un NFS pour PXE. Donc
|
||||
au dist-upgrade, il faudra faire attention.
|
||||
Babar a également un
|
||||
serveur 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 kdell.
|
||||
|
||||
Son interfaçage avec la baie de disque n'est pas compatible avec l'utilisation
|
||||
faite actuellement au Cr@ns.
|
||||
|
||||
Pierre-Elliott fait remarque que changer l'architecture demanderait alors
|
||||
beaucoup de temps pour assez peu de résultat. En effet, il faudrait revoir
|
||||
complètement la gestion des disques des machines virtuelles : actuellement elles
|
||||
montent des disques (virtuels) entier, il faudrait plutôt qu'elles montent des
|
||||
partitions.
|
||||
|
||||
Ce dernier point serait de toute façon une bonne chose et résoudrait sans
|
||||
doutes les quelques problèmes de migration que l'on rencontre.
|
||||
|
||||
#### Virtualisation pour les clubs
|
||||
|
||||
À terme, une fois les tests terminés, il faudra décider si on offre un service
|
||||
de virtualisation pour les clubs.
|
||||
Valentin fait remarquer que l'avantage d'avoir une solution compatible avec la
|
||||
virtualisation actuelle permettrait de pouvoir migrer des machines virtuelles
|
||||
vers kdell en cas de problèmes sur un
|
||||
autre dom0.
|
||||
|
||||
### Câblage de personnel CROUS
|
||||
|
||||
cf ../Jeudi25Avril2013
|
||||
|
||||
### Dist-upgrades
|
||||
|
||||
La release c'est (après) demain.
|
||||
Tous les membres actifs sont invités à lire
|
||||
les [release notes](http://www.debian.org/releases/wheezy/amd64/release-notes/index.fr.html)
|
||||
et la page CransTechnique/AdminSystème/DistUpgrade (potentiellement à
|
||||
compléter).
|
||||
|
||||
Il faut planifier les mise à jour des machines entrainant une interruption de
|
||||
service et prévenir à l'avance sur CransIncidents et sur les news.
|
||||
|
||||
Parmi celles-ci :
|
||||
|
||||
* komaz
|
||||
* redisdead
|
||||
* radius
|
||||
* dhcp
|
||||
* xmpp (super important !!1)
|
||||
* zamok
|
||||
|
||||
zamok sera mis à jour lundi 6 mai
|
||||
en même temps qu'on réparera le home des
|
||||
adhérents. (envoi de mail ce soir)
|
||||
|
||||
Les mise à jour sont programmées à partir du week-end du 18-19 mai pour avoir
|
||||
des apprentis disponibles.
|
||||
|
||||
### Ajout de droits
|
||||
|
||||
Sur proposition de Vincent, les droits nounou ont été attribués à Lucas Serrano
|
||||
et Pauline Pommeret.
|
||||
|
||||
Valentin fait la partie chiante où il faut taper son mot de passe {{{sudo}}}.
|
||||
|
||||
### Divers
|
||||
|
||||
#### Caméras
|
||||
|
||||
Il faut diagnostiquer pourquoi celle du 2B fait des histoires pour prendre des
|
||||
photos et les envoyer sur [[CransTechnique/LesServeurs/ServeurBabar|babar]].
|
||||
Idem celle du 0B envoie des mails de manière aléatoire, il faut voir si ça n'est
|
||||
pas juste un problème de configuration.
|
||||
|
||||
#### Alimentation et KVM
|
||||
|
||||
Le CA a donné son accord sur le principe pour l'achat d'une alimentation
|
||||
rackable, et
|
||||
pour celui d'un KVM. Il faudrait avant cela tester un clavier.
|
||||
|
||||
Pierre-Elliott se charge du KVM. Valentin s'occupe de l'alimentation, et des
|
||||
« petits consommables » (têtes RJ45 & co).
|
||||
|
||||
Nicolas dit qu'il a croisé une alimentation similaire à pika et chu, elle doit
|
||||
se trouver dans un des locaux techniques.
|
||||
|
||||
#### autoconf wifi
|
||||
|
||||
Valentin a nettoyé le code de son script. Les sources et le script pour
|
||||
cross-compiler se trouvent dans {{{/usr/scripts/src/autoconf-wifi}}}.
|
||||
|
||||
L'exécutable servi pour Windows est signé, avec la commande décrite dans
|
||||
la source. Ce n'est pas absolument nécessaire de faire ça.
|
||||
|
||||
Attention, le fichier est symlinké depuis le serveur {{{ftp}}}.
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
# Réunion Nounous
|
||||
|
||||
* Date : Jeudi 16 mai 2013
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h32
|
||||
* Fin : 21h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Raphaël Cauderlier
|
||||
* Vincent Le Gallic
|
||||
* Lucas Serrano
|
||||
* Valentin Samir
|
||||
* Pierre-Elliott Bécue
|
||||
* Ariane Soret
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Avancement binding LDAP
|
||||
|
||||
Valentin affirme que le nouveau binding fonctionne, id est il est possible de :
|
||||
|
||||
* créer des objets
|
||||
* modifier des objets
|
||||
* supprimer des objets (avec un cimetière)
|
||||
* ressusciter des objets depuis le cimetière
|
||||
* programmation des services à reconfigurer
|
||||
* Il faudrait peut-être revoir le système des arguments passés aux services
|
||||
|
||||
à redémarrer, celui actuel ne permettant pas beaucoup de flexibilité.
|
||||
Il manque :
|
||||
|
||||
* Une gestion des accès concurrents
|
||||
* Les logs (support partiel de l'ancienne méthode via l'attribut historique)
|
||||
|
||||
Penser à migrer les scripts qu'on veut garder de l'ancien binding vers le
|
||||
nouveau.
|
||||
|
||||
Vincent a séparé les objets ldap du binding dans un autre fichier.
|
||||
Ajouté un module shortcuts pour se binder en admin, readonly, autre, ….
|
||||
|
||||
Le fait que le package, le module principal et la classe du binding portent le
|
||||
même
|
||||
nom est problématique. Il faudrait penser à un renommage.
|
||||
|
||||
Vincent s'occupera du renommage, Pierre-Elliott de l'accès concurrent.
|
||||
|
||||
### Avancement Intranet2
|
||||
|
||||
L'application "Mes Machines" sur le nouvel intranet est en production et est
|
||||
utilisé. (L'ancien commençait à avoir du mal sur les nouveaux navigateurs.)
|
||||
|
||||
L'association compte Cr@ns<->WikiNom a quelques problèmes d'encodage (cf mail)
|
||||
Il reste à réaliser un outil de création de compte Wiki (pour compenser le
|
||||
script qui ne marche pas sur zamok).
|
||||
|
||||
Dans les applications à migrer rapidement : une application "mon compte" et
|
||||
une application d'impression (lancement) et le rechargement de solde via paypal
|
||||
et note Kfet.
|
||||
|
||||
Il pourrait être bien de migrer la gestion des digicodes en les stockant
|
||||
dans une base de donnée (au lieu de créer un fichier dans
|
||||
/usr/scripts/var/digicode) avis aux apprentis !
|
||||
|
||||
### Serveur TV
|
||||
|
||||
La carte 4 tuners a été testée dans le pc d'un membre actif.
|
||||
Ça fait 20 jours que ça marche.
|
||||
|
||||
Il faut acheter au moins une deuxième carte pour couvrir tous les multiplex et
|
||||
une tour avec suffisamment de PCIe (au moins 4) et de ventilo pour refroidir
|
||||
les cartes.
|
||||
(faire un panier sur un site de vente en ligne).
|
||||
|
||||
Valentin s'en occupe.
|
||||
|
||||
Il faudrait réfléchir à rationaliser également le satellite.
|
||||
|
||||
### CAS
|
||||
|
||||
Le wiki a été (partiellement) CASsifié.
|
||||
|
||||
Il reste sogo, horde et nagios.
|
||||
Il faut installer pam_cas sur le serveur imap pour cela (Argh).
|
||||
|
||||
### WiFi
|
||||
|
||||
Il reste des choses à faire ! Prochaine séance de pose de bornes ? :)
|
||||
|
||||
Il faut acheter les bornes de test (Daniel se charge de faire le panier) dont
|
||||
le budget
|
||||
a été voté au précédent CA.
|
||||
|
||||
Il faudrait compter le nombre de bornes à acheter pour compléter la couverture
|
||||
(PdJ, RdC H I J) (possiblement avec les fat max 100 clients).
|
||||
|
||||
Il faut poser les bornes au G, C, A, B.
|
||||
|
||||
Daniel propose de faire une séance ce week-end pour wifier le bâtiment C.
|
||||
On se retrouve samedi après le petit dèj (début 14h).
|
||||
|
||||
### Mise a jour des serveurs
|
||||
|
||||
* komaz : 25/05/2013
|
||||
* sable : 2{5,6}/05/2013
|
||||
* vert : 01/06/2013 (penser à couper 1 réplicat pour avoir un backup)
|
||||
* charybde : 01/06/2013
|
||||
* gordon -> à transformer en domu
|
||||
* news : 15/06/2013
|
||||
* niomniom : 15/06/2013
|
||||
* titanic : 22/06/2013
|
||||
* dhcp : 22/06/2013
|
||||
* eap : juillet
|
||||
* irc : juillet
|
||||
* redisdead : juillet
|
||||
* ovh : juillet
|
||||
* owl : juillet
|
||||
* sogo : en même temps que owl
|
||||
|
||||
### Adhérent au M qui spoofe
|
||||
|
||||
Un adhérent a spoofé l'ip de zamok. Il prétend ne pas être au courant,
|
||||
il semble qu'il l'ait fait involontairement. Comme il a une freebox, il a
|
||||
été déconnecté au niveau du Crans.
|
||||
|
||||
!ToDoList.append("déconnecter automatiquement les prises où on voit une MAC
|
||||
spoofant
|
||||
une IP de serveur ?")
|
||||
|
||||
### Flaw in linux kernel
|
||||
|
||||
Hier un mail a été reçu parlant d'une faille découverte récemment.
|
||||
Zamok y étant vulnérable, Pierre-Elliott lui a appliqué un patch.
|
||||
|
||||
### D(r)ivers
|
||||
|
||||
* On a reçu 3 écrans et des claviers. C'est cool. Daniel dit que certaines
|
||||
|
||||
touches d'un clavier ne marchent pas. Il suffit de les renvoyer (les claviers,
|
||||
pas les touches).
|
||||
|
|
@ -0,0 +1,105 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 30 Mai 2013
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h30
|
||||
* Fin :
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### TV
|
||||
|
||||
Une nouvelle machine a été reçue et montée lundi, la seconde carte TV lui a été
|
||||
adjointe
|
||||
mercredi.
|
||||
Elle diffuse toute la TNT sauf le dernier Multiplex que l'on ne capte
|
||||
apparemment pas.
|
||||
Pour l'instant ça marche bien ! (il est même probable que ça soit toujours le
|
||||
cas demain)
|
||||
Il faut prévoir un ménage du 4J, et renommer TNT_test en TNT.
|
||||
|
||||
Il faudrait également passer la configuration de la TV dans bcfg2, avis à un
|
||||
apprenti/ignorant motivé.
|
||||
|
||||
Daniel demande s'il est possible de rajouter des cartes dans {{{cochon}}}, par
|
||||
exemple,
|
||||
le satellite. À priori c'est possible.
|
||||
|
||||
### WiFi
|
||||
|
||||
Daniel a commandé 12 Unifi et 2 nano M5. Ça devrait arriver d'ici lundi. Des
|
||||
tests seront
|
||||
à faire sur les bornes Unity, Daniel propose d'aider un curieux à comprendre
|
||||
comment les
|
||||
flasher, après avoir trouvé le firmware qui convient.
|
||||
|
||||
### Mise à jour de serveurs
|
||||
|
||||
#### Gordon
|
||||
|
||||
Un nouveau DNS récursif a été mis en place, une machine virtuelle du nom
|
||||
de {{{nem}}} sur
|
||||
kdell. C'était une occasion de tester Proxmox sur de la prod.
|
||||
|
||||
#### Dhcp de secours
|
||||
|
||||
Une machine supplémentaire a été créée pour le dhcp, elle s'appelle {{{isc}}},
|
||||
et tourne sur
|
||||
kdell.
|
||||
|
||||
#### Futures mises à jour
|
||||
|
||||
Il faudrait planifier les mises à jour de serveurs encore non listés.
|
||||
|
||||
* eap : 2 juillet
|
||||
* irc : 2 juillet
|
||||
* redisdead : 2 juillet
|
||||
* ovh : 2 juillet
|
||||
* owl : 10 juillet
|
||||
* sogo : 10 juillet
|
||||
* xmpp : 10 juillet (à 14h, pour faire chier les vieux)
|
||||
* asterisk : 10 juillet
|
||||
|
||||
Au moins vert et charybde samedi matin, il faudrait faire du teasing, qu'un
|
||||
apprenti (voire
|
||||
plus, soyons fous) vienne.
|
||||
|
||||
### Virtualisation
|
||||
|
||||
Proxmox est installé sur kdell et sur vo, il faut s'assurer qu'il existe des
|
||||
outils en
|
||||
command line pour lancer les machines virtuelles, et éventuellement pour
|
||||
accéder en console
|
||||
à celles-ci.
|
||||
Il faut documenter l'appli si on veut passer de xen à proxmox. Entres autres
|
||||
pour la gestion
|
||||
des disques.
|
||||
|
||||
#### Ntp sous proxmox
|
||||
|
||||
A l'air de fonctionner.
|
||||
|
||||
### Évolution du nouveau binding
|
||||
|
||||
Le nouveau binding est en « tout unicode » (enfin presque), et les locks sont à
|
||||
peu près
|
||||
en place.
|
||||
|
||||
Une composante bijective a été extraite des dictionnaires rid, NETs, prefix de
|
||||
config.py
|
||||
|
||||
### Pénurie des ipv4
|
||||
|
||||
Un script a été pondu, il n'a pas encore éclos, il faudrait s'occuper de mettre
|
||||
en place le
|
||||
v6-only en parallèle.
|
||||
|
||||
Il faudrait presser la DSI pour l'ipv6.
|
||||
|
|
@ -0,0 +1,87 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 13 Juin 2013
|
||||
* Lieu : Fonteneau ou Tocqueville
|
||||
* Début : 19h18
|
||||
* Fin : 20h53
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Raphaël Cauderlier
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Carte Satellite
|
||||
|
||||
Elle est arrivé, elle est rouge dans son carton.
|
||||
|
||||
Il faut l'installer relativement rapidement sachant qu'il n'y a plus de chaînes
|
||||
satellite diffusées en ce moment.
|
||||
|
||||
Histoire de faire les choses correctement, il faut écrire des règles udev pour
|
||||
déterminiser l'ordre d'attribution interface <-> carte.
|
||||
|
||||
Il serrait également interessant d'écrire un initscript permettant de n'agir
|
||||
que sur une seule instance de mumudvb.
|
||||
|
||||
### Climatisation 0B
|
||||
|
||||
LTC est passé lundi matin, il a nettoyé l'évacuation à l'extérieur qui était
|
||||
pleine de pigeon et de guano. Les résultats ne sont pas merveilleux.
|
||||
Il faut les rappeler pour qu'ils repassent.
|
||||
|
||||
Daniel se charge de les rappeler.
|
||||
|
||||
### Notification d'infraction au copyright
|
||||
|
||||
La DSI nous a transféré un mail (parmi plusieurs) à propos de violation de
|
||||
copyright.
|
||||
On a transmis aux adhérents concernés. Apparemment ça leur suffit pas.
|
||||
|
||||
Pierre-Elliott écrit un mail pour la DSI explicitant que l'on n'y peut pas
|
||||
grand chose.
|
||||
|
||||
### Nouvelles bornes WiFi
|
||||
|
||||
Une première borne du nouveau modèle (!UniFi) a été placée au B.
|
||||
|
||||
Daniel a commencé à remplir des pages wiki sur la façon de les flasher.
|
||||
|
||||
Bâtiments restants : G, C, A, PdJ.
|
||||
|
||||
Appel aux apprentis pour flasher, poser, tirer des câbles.
|
||||
|
||||
### CAS, déconnexion
|
||||
|
||||
Maintenant, quand on clique sur "se déconnecter" on est globalement déconnecté
|
||||
des services suivants : wiki, roundcube, webnews.
|
||||
|
||||
Ce serait pas mal de l'implémenter pour les autres services.
|
||||
|
||||
Un apprenti peut être encadré sur le sujet.
|
||||
|
||||
Valentin se charge de rajouter
|
||||
sur [[CransTechnique/ServicesMineurs/CentralAuthenticationService]] les paths
|
||||
des différentes conf
|
||||
(serveurside et clientside)
|
||||
|
||||
### Mise à jour de serveurs
|
||||
|
||||
News et Niomniom sont à mettre à jour samedi à partir de 9h30.
|
||||
Appels aux apprentis disponibles.
|
||||
|
||||
Valentin enverra un mail de rappel sur nounou@crans.org d'ici ce soir.
|
||||
|
||||
Valentin propose une fois encore d'écrire un module d'autentification pour
|
||||
gérer le hack de la zone Crans de MoinMoin.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Imprimante
|
||||
|
||||
Un technicien est venu réparer l'imprimante. Jusque là, elle remarche. Elle
|
||||
boure relativement souvent. Il faudra également recommander du papier.
|
||||
|
|
@ -0,0 +1,252 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Lundi 23 septembre 2013
|
||||
* Lieu : Espace Condorcet
|
||||
* Début : 19h25
|
||||
* Fin : 20h49
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Florian Marconi
|
||||
* Jean-Paul Giraud-Ferrandi
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël-David Lasseri
|
||||
* Valentin Samir
|
||||
* Vincent Guiraud
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Présentation
|
||||
|
||||
On effectue rapidement un tour de table pour se présenter.
|
||||
Pierre-Elliott rappelle les divers postes que peuvent occuper des membres
|
||||
actifs et que l'investissement temporel est à géométrie variable.
|
||||
|
||||
### Garantie renouvelée
|
||||
|
||||
La garantie de {{{zamok}}} ayant expiré, le C.A. a voté durant l'été par email
|
||||
le
|
||||
renouvellement de la garantie, qui a été appliqué.
|
||||
|
||||
Vincent recevra la facture.
|
||||
|
||||
L'extension de garantie court jusqu'au 03/09/2014.
|
||||
|
||||
### Politique sur les infractions au copyright
|
||||
|
||||
Problème réglé : en gros, la DSI nous envoie des mails de la part d'ayants
|
||||
droit mentionnant des IPs Crans.
|
||||
|
||||
La politique a donc été définie en accord avec la DSI : on ne sanctionne pas
|
||||
les adhérents, on transmet les mails que l'on reçoit aux adhérents.
|
||||
Si des demandes d'ayants droit deviennent insistantes, les rediriger vers les
|
||||
instances compétentes.
|
||||
|
||||
### Politique sur les comptes compromis
|
||||
|
||||
Il arrive que des comptes crans soit compromis, ''id est'' que les identifiants
|
||||
du compte leakent.
|
||||
|
||||
Outre les problèmes concernant la vie privée du propriétaire du compte, il a
|
||||
été observé que des spambots envoyaient des milliers de mails via ces comptes.
|
||||
|
||||
Pour ce qui est des spams, Pierre-Elliott propose une solution à partir
|
||||
des "politiques" de postfix.
|
||||
Cela est faisable en pas trop longtemps. Avis à des personnes motivées.
|
||||
|
||||
Moralement, si un compte est compromis il faudrait complètement le
|
||||
désactiver (via l'ajout d'un attribut LDAP), et pas uniquement bloquer l'envoi
|
||||
de mail.
|
||||
Un débat a lieu sur la meilleur manière de communiquer un nouveau mot de passe.
|
||||
|
||||
Manières de contacter un adhérent dont le compte est compromis (et désactivé):
|
||||
|
||||
* Physiquement à la Kfet
|
||||
* Mail alternatif (attribut mailExt)
|
||||
* Adresse postale (ne plus mettre de EXT sans adresse)
|
||||
* Téléphone
|
||||
* Au cas par cas (?)
|
||||
|
||||
Pierre-Elliott modifiera la base LDAP pour l'attribut "compte désactivé", si
|
||||
possible gérable via blacklist, ou un peu comme mail_invalide.
|
||||
|
||||
### Gestion des certificats
|
||||
|
||||
PEB a contacté !CaCert pour créer un compte à l'association pour gérer le
|
||||
domaine {{{crans.org}}}.
|
||||
|
||||
Le système de !CaCert repose sur un réseau de confiance : des gens "de
|
||||
confiance" assurent d'autres gens, et ainsi de suite.
|
||||
Il y a un système de points qui permet de donner plus ou moins de possibilités
|
||||
aux gens plus ou moins assurés.
|
||||
|
||||
Un compte organisation peut nommer des administrateurs (des assureurs) qui
|
||||
pourront ensuite émettre des certificats pour le domaine.
|
||||
|
||||
Actuellement, le domaine {{{crans.org}}} est enregistré sur le compte personnel
|
||||
de Stéphane Glondu, ce qui oblige de passer systématiquement par lui pour les
|
||||
renouvellement ou les nouveaux certificats.
|
||||
Cela est devenu relativement pénible autant pour lui que pour nous. C'est
|
||||
pourquoi Pierre-Elliott a entrepris les démarches pour ouvrir un compte
|
||||
organisation au nom du Crans.
|
||||
|
||||
### Migration vers proxmox
|
||||
|
||||
Les machines virtuelles du Crans sont hébergées sous le virtualiseur Xen.
|
||||
Il y a quelques problèmes lors de la migration de machines virtuelles entre
|
||||
deux virtualiseurs.
|
||||
|
||||
Pierre-Elliott a installé Proxmox sur {{{kdell}}} et sur {{{vo}}} pour tester,
|
||||
et celui-ci a plus ou moins fait preuve de sans faute par rapport à nos
|
||||
exigences.
|
||||
|
||||
Proxmox, c'est un noyau Linux modifié pour virtualiser des machines sous kvm ou
|
||||
OpenVZ. En sus, il y a une interface web kikoo.
|
||||
|
||||
Globalement, Proxmox est plus adapté à nos besoins, Pierre-Elliott a testé la
|
||||
migration des machines depuis XEN vers Proxmax, cela fonctionne, et est
|
||||
documenté.
|
||||
Un certain nombre de migrations ont été effectuées.
|
||||
|
||||
Il faudrait effectuer les suivantes. L'idéal étant que des gens découvrent.
|
||||
|
||||
### Déploiement du wifi
|
||||
|
||||
Daniel a placé une borne wifi par étage au PDJ (au niveau du local technique).
|
||||
|
||||
Il reste à tirer des câbles au niveau des faux plafonds.
|
||||
Un étage sur deux une au milieu, pour les autres deux sur les côtés.
|
||||
|
||||
Les bâtiments C, A, G et le PDJ restent à câbler.
|
||||
Un des problème est le manque d'accessibilité aux locaux, notamment au C.
|
||||
Il faut des gens motivés pour faire tout ça, c'est long et chiant, mais c'est
|
||||
indispensable qu'on finisse cette année, ou du moins avant qu'on parte à Saclay.
|
||||
|
||||
Dernier détail : le VLAN 3 n'est plus propagé dans les locaux de l'ENS, il
|
||||
faudrait faire signe à la DSI pour essayer de comprendre pourquoi, après avoir
|
||||
mené quelques tests.
|
||||
|
||||
### Mails automatiques
|
||||
|
||||
Valentin a commencé un peu de templating avec Jinja2, il faudrait remplir ces
|
||||
mails dans les diverses langes qu'on pratique.
|
||||
|
||||
Une fois cela fait, on pourrait songer à un champ LDAP pour demander aux
|
||||
adhérents leur langue préférée.
|
||||
|
||||
Il faut prolonger ce travail, et le rendre utilisable, si possible avant la
|
||||
prochaine rentrée. Avis aux amateurs.
|
||||
|
||||
### Point lc_ldap
|
||||
|
||||
{{{lc_ldap}}} est presque fini, il faut juste s'occuper de ces histoires
|
||||
d'historique, et des factures.
|
||||
|
||||
On a aussi des erreurs, probablement dues aux locks, il faut investiguer pour
|
||||
améliorer le système.
|
||||
Globalement, les erreurs sont "!LockedByYou", ce qui tend à laisser croire que
|
||||
dans un cas précis, quand on annule une modif, les locks ne sont pas levés.
|
||||
|
||||
Pour l'historique, il s'agit de travailler avec {{{cn=log}}}, ce qui avait été
|
||||
commencé par adg.
|
||||
Sinon, le système d'historique (quitte à les mettre à côté ou en
|
||||
sous-objet) actuel + {{{cn=log}}}, mais sans parsage.
|
||||
|
||||
L'idéal serait quand même de travailler avec {{{cn=log}}}. Une alternative est
|
||||
de créer un objet fils de chaque objet, qui contiendrait l'historique.
|
||||
|
||||
Pour les factures, il faut juste écrire le code.
|
||||
|
||||
### Divers intranet2
|
||||
|
||||
* Création de compte wiki (pour l'instant on ne sait que linker les comptes)
|
||||
* Génération de {{{.procmailrc}}} (il s'agit de migrer l'appli de l'intranet1,
|
||||
et de faire ce qui est proposé dans le tracker (règles de filtrage))
|
||||
* Gestion de !MonCompte (idem qu'au dessus)
|
||||
* Gestion des factures (cf point {{{lc_ldap}}})
|
||||
* Digicode / Impression (ça avait été commencé, il faut juste finir, il s'agit
|
||||
aussi de porter l'appli de l'intranet1)
|
||||
|
||||
### Multicast : radio et satellite
|
||||
|
||||
Valentin a ajouté des chaînes de radio via http sur l'offre TV, qui semble
|
||||
fonctionner.
|
||||
|
||||
Il y a un comportement anormal des switches qui fait qu'en cas de poll pour
|
||||
trouver des abonnés,
|
||||
les réponses ne reviennent pas toujours à cochon malgré son statut de routeur
|
||||
multicast.
|
||||
|
||||
Il y a normalement des chaînes de radio sur le satellites mais {{{mumudvb}}} ne
|
||||
veut pas les diffuser.
|
||||
|
||||
Il y a une interface web pour la télévision sur
|
||||
<http://intranet2.crans.org/tv>.
|
||||
|
||||
### VLAN dynamiques en wifi
|
||||
|
||||
Daniel a travaillé sur le basculement dynamique en wifi entre les
|
||||
VLANs. (accueil & co)
|
||||
|
||||
Sur le filaire, c'est déjà fait, les switches interrogent radius pour choisir
|
||||
le VLAN sur lequel placer les machines.
|
||||
En wifi, c'était un peu plus compliqué. Mais à la suite de divers tests et
|
||||
flashages de bornes, il a trouvé quelque chose qui fonctionne.
|
||||
|
||||
Il faut donc modifier les confs radius sur {{{eap}}} et {{{pea}}} pour mettre
|
||||
ça en prod après avoir flashé les bornes avec la nouvelle !OpenWRT.
|
||||
|
||||
On prévoit également de mettre en place le failover pour {{{eap}}} et {{{pea}}}.
|
||||
|
||||
Bref, ça marche, il faut des apprentis motivés pour apprendre tout ça et
|
||||
implémenter le truc. (soyons consensuels). Raphaël-David a déjà commence, mais
|
||||
il veut des coupaings.
|
||||
|
||||
### Point cranspassword
|
||||
|
||||
Vincent étant absent, on se limitera aux remarques de Daniel.
|
||||
Il faut s'assurer que les clefs GPG des gens sont toujours à jour, et non
|
||||
expirées.
|
||||
|
||||
* Ouais, j'étais pas là, my bad.
|
||||
|
||||
. Pour ce qui est des détails techniques d'un point de vue {{{git}}}, il faut
|
||||
soit se placer sur la branche {{{0.1}}} et ne plus se soucier de rien (le
|
||||
serveur sur {{{vert}}} est en {{{0.1}}}), soit rester sur {{{master}}} mais
|
||||
être prêt à puller les mises à jour quand il y en a. Le serveur
|
||||
sur {{{ovh}}} est sur {{{master}}} (mais en readonly)
|
||||
. Pour le faire marcher, on peut maintenant utiliser le
|
||||
Makefile (sur {{{master}}}). {{{make install}}} pour installer le client. Ça a
|
||||
pour effet de :
|
||||
|
||||
* mettre de la conf dans {{{~/.config/cranspasswords}}}
|
||||
* installer le script {{{cranspasswords}}} dans {{{~/bin}}}, qu'il faut donc
|
||||
avoir dans son {{{$PATH}}}
|
||||
|
||||
. La vérification de confiance et d'expiration des clés est implémentée, et il
|
||||
propose même d'ignorer une clé au moment où on chiffre si elle pose problème.
|
||||
. J'oublie ptêt des trucs, mais normalement la doc
|
||||
est [[CransTechnique/ScriptsCrans/CransPasswords|là]] -- [[Wiki20-100]] <<DateTime(2013-09-28T01:37:06+0200)>>
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Séminaires
|
||||
|
||||
Date de début des séminaires ?
|
||||
Le 1er ou le 8 octobre, à confirmer par email, et pensez à faire de la vraie
|
||||
pub, parce que les séminaires, c'est le bien.
|
||||
|
||||
Valentin voudrait qu'on commence GPG en octobre, ce qui est judicieux.
|
||||
|
||||
Si cela convient aux intervenants, le premier mois sera donc "intro par
|
||||
Valentin" -> "Unix par lolasd" -> "le shell par #Random" -> "Gépégé".
|
||||
|
||||
#### Reconfiguration des switches
|
||||
|
||||
Tous les switchs ont la nouvelle configuration faite par Daniel vendredi soir.
|
||||
|
||||
#### Forum des assoces
|
||||
|
||||
Daniel propose de tenir le stand, et veut de la compagnie.
|
||||
|
|
@ -0,0 +1,95 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 03 Octobre 2013
|
||||
* Lieu : Pavillon des Jardin
|
||||
* Début : 19h07
|
||||
* Fin : 19h57
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Pauline Pommeret
|
||||
* Thomas Espitau
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Programmation WiFi
|
||||
|
||||
Daniel veut fixer une date pour les bornes du C : il n'y a qu'a resertir les
|
||||
câbles.
|
||||
Il serait de bon ton de changer en même temps le switch du 5C (bac-4) sur lequel
|
||||
sont branchées les bornes.
|
||||
|
||||
On programme ça samedi en début d'après-midi (après le petit déjeuner).
|
||||
|
||||
### Projecteur
|
||||
|
||||
Pour la tenue de ses réunions hebdomadaires, le Crans aurait besoin d'un vidéo
|
||||
projecteur.
|
||||
Il serait aussi utile pour les petites conférences exceptionnelles.
|
||||
|
||||
Le collège technique estime qu'une résolution supérieure ou égale à de l'HD
|
||||
ready (1080x720) serait une bonne chose.
|
||||
|
||||
Comme il s'agit d'un projecteur pour utiliser en environnement lumineux (pas
|
||||
dans le noir pour regarder un film), il faut que sa luminosité soit suffisante.
|
||||
|
||||
Il faut un contraste suffisant pour voir les couleur du fond de gobby. (Assez
|
||||
violent à mon goût à avoir quand même).
|
||||
|
||||
Avoir une connectique VGA et HDMI.
|
||||
|
||||
Diode VS lampe : la première a une durée de vie bien plus grande (au
|
||||
moins 10 fois plus) mais ''a priori'' une luminosité plus faible.
|
||||
Daniel demande s'il faudrait également acheter un écran
|
||||
portatif (entre 60 et 160€).
|
||||
|
||||
### Système de paiement
|
||||
|
||||
Actuellement l'adhésion se fait par année scolaire.
|
||||
Valentin propose des (ré)adhésions par année glissante.
|
||||
Cela permettra d'éviter les gros rushs de réadhésion à la rentrée.
|
||||
|
||||
Vincent rappelle qu'il faut scripter l'envoi de mails. Valentin dit qu'il faut
|
||||
ajouter un champ avec la date d'adhésion/réadhésion (et laisser un mois pour la
|
||||
carte d'étudiant).
|
||||
|
||||
Une fois implémentée, cette solution pourra être proposée au CA (et soumise à
|
||||
validation).
|
||||
|
||||
## Question diverses
|
||||
|
||||
### Cranspasswords
|
||||
|
||||
Vincent n'était pas là lors de la dernière internounou.
|
||||
Il n'a pas grand chose à ajouter.
|
||||
|
||||
* Pour ce qui est des détails techniques d'un point de vue {{{git}}}, il faut
|
||||
soit se placer sur la branche {{{0.1}}} et ne plus se soucier de rien (le
|
||||
serveur sur {{{vert}}} est en {{{0.1}}}), soit rester sur {{{master}}} mais
|
||||
être prêt à ''puller'' les mises à jour quand il y en a. Le serveur
|
||||
sur {{{ovh}}} est sur {{{master}}} (mais en readonly).
|
||||
|
||||
. Pour le faire marcher, on peut maintenant utiliser le
|
||||
Makefile (sur {{{master}}}). {{{make install}}} pour installer le client. Ça a
|
||||
pour effet de :
|
||||
|
||||
* mettre de la conf dans {{{~/.config/cranspasswords}}}
|
||||
* installer le script {{{cranspasswords}}} dans {{{~/bin}}}, qu'il faut donc
|
||||
avoir dans son {{{$PATH}}}
|
||||
|
||||
. La vérification de confiance et d'expiration des clés est implémentée, et il
|
||||
propose même d'ignorer une clé au moment où on chiffre si elle pose problème.
|
||||
|
||||
### Matériel séminaire
|
||||
|
||||
On se propose d'enregistrer et de filmer les séminaires.
|
||||
|
||||
Pour cela, on demande un micro-cravate, Valentin en trouve 4 + récepteurs
|
||||
à 200€, cela semble honnête (sonovente.com), en promotion.
|
||||
|
||||
Une caméra serait également pratique, une discussion va être lancée sur
|
||||
nounou@, il y a forcément quelqu'un de compétent (bref c'est remis à Plüthaar).
|
||||
|
|
@ -0,0 +1,193 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 17 octobre 2013
|
||||
* Lieu : Pavillon des Jardin
|
||||
* Début : 19h15
|
||||
* Fin : 21h13
|
||||
|
||||
## Présents
|
||||
|
||||
* Ariane Soret
|
||||
* Daniel Stan
|
||||
* Jordan Delorme
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël-David Lasseri
|
||||
* Théo Winterhalter
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Pont WiFi
|
||||
|
||||
Lucas à mis en œuvre un pont wifi entre deux nano.
|
||||
À la base, cela était pour relier l'Arpej (mais il n'y a plus personne).
|
||||
|
||||
Ça marche. On a un débit asymétrique :
|
||||
|
||||
* AP -> client : 40 Mbps
|
||||
* client -> AP : 90 Mbps
|
||||
|
||||
Un test de distance à été effectué entre le I et le J, cela semble concluant. Il
|
||||
reste à tester sur une longue distance (de l'ordre 500m).
|
||||
Une collocation sur la colline de Cachan est partante pour acheter une paire de
|
||||
bornes et être raccordée au réseau si le test longue distance est concluant.
|
||||
L'autre extrémité sera sur la terrasse du bâtiment C.
|
||||
|
||||
{{{#!wiki caution
|
||||
On notera qu'il ne faut pas bridger les interfaces des '''deux''' bornes
|
||||
sur leur interface filaire. Ça fait une boucle. Le réseau aime pas ça. Du tout.
|
||||
|
||||
Une note à ce sujet a été rajoutée sur une des deux bornes.
|
||||
}}}
|
||||
|
||||
### Policyd sur redisdead
|
||||
|
||||
''Résumé des épisodes précédents : Il est arrivé plusieurs fois au cours des
|
||||
derniers
|
||||
mois qu'un mot de passe d'un compte Cr@ns soit compromis et qu'un botnet
|
||||
l'utilise
|
||||
pour envoyer du spam.''
|
||||
|
||||
Une limite de mail par minute par IP émettrice était déjà en place, mais les
|
||||
botnet
|
||||
deviennent intelligents, ils utilisent plusieurs IPs.
|
||||
La dernière occurrence a eu lieu Vendredi dernier.
|
||||
|
||||
Valentin a mis en place sur notre SMTP un plugin postfix (policyd, version clue
|
||||
bringer)
|
||||
qui permet de restreindre les politiques d'accès par utilisateur authentifié.
|
||||
|
||||
La configuration est dans une base de données sur {{{thot}}}.
|
||||
Pour la faire/modifier, il y a un joli
|
||||
cliquodrome : <https://redisdead.adm.crans.org/policyd/>,
|
||||
l'authentification se fait par compte Cr@ns.
|
||||
Les limitations de quotas mises en place sont :
|
||||
|
||||
* 500 mails par utilisateur par 24h
|
||||
* 1Go de données par utilisateur par 24h
|
||||
|
||||
Policyd permet également de faire du greylisting.
|
||||
La question de dropper postgreysql se pose, histoire d'avoir un seul daemon pour
|
||||
faire les deux.
|
||||
|
||||
### lc_ldap
|
||||
|
||||
#### factures
|
||||
|
||||
Valentin a fait en sorte que les factures soient utilisables avec {{{lc_ldap}}}.
|
||||
|
||||
* objectClass=facture
|
||||
* fid (identifiant unique)
|
||||
* modePaiement (paypal, pour l'instant)
|
||||
* article (qu'est-ce qui a été payé)
|
||||
* recuPaiement (on décide de mettre AAAA-MM-JJ, correspondrait à cocher
|
||||
paiement AAAA)
|
||||
* historique (ce qui est arrivé dans cette facture au cours de l'histoire)
|
||||
* ToDo <https://tracker.crans.org/issues/224> : rajouter un champ pour
|
||||
validation par le trésorier
|
||||
|
||||
(cf controle+p)
|
||||
|
||||
#### Comptes compromis
|
||||
|
||||
Il faudrait rajouter un champ LDAP pour marquer un compte comme compromis et
|
||||
vérifier
|
||||
son absence dans ce qui utilise les comptes LDAP.
|
||||
(envoi de mails, connexion à zamok, laisser l'intranet ?)
|
||||
|
||||
<https://tracker.crans.org/issues/223>
|
||||
|
||||
#### Blackliste pour les gens qui ont pas payé
|
||||
|
||||
Pour les adhérents n'ayant pas payé pour l'année en cours, une
|
||||
pseudo-blackliste a été rajoutée.
|
||||
Il n'y a donc pas besoin de vérifier qu'un adhérent a payé, juste qu'il n'a pas
|
||||
de blackliste.
|
||||
|
||||
Un des effets a été que les anciens adhérents (qui n'ont pas réadhéré)
|
||||
pouvaient toujours se connecter à {{{zamok}}}, mais plus en sortir.
|
||||
Valentin a patché pour rétablir la situation précédente.
|
||||
|
||||
Pour l'instant, il n'y a pas eu d'abus constaté, on laisse ça comme ça.
|
||||
Il sera toujours temps de revenir en arrière si on constate des abus.
|
||||
|
||||
### Mail rappel carte étudiant
|
||||
|
||||
Il faut l'envoyer. Ce serait bien d'écrire le template jinja
|
||||
(cf {{{/usr/scripts/gestion/mail/}}}).
|
||||
Pierre-Elliott et Raphaël-David se chargent de reprendre celui de l'année
|
||||
précédente.
|
||||
|
||||
Il pourrait être judicieux d'en profiter pour le croner.
|
||||
|
||||
### Rappel env de dev sur vo
|
||||
|
||||
Valentin rappelle qu'il y a un environnement de développement pour tester
|
||||
le webnews et l'intranet sur {{{vo}}}.
|
||||
|
||||
A priori, respbats a les droits d'écriture, les apprentis peuvent donc tester.
|
||||
Ça permet de «tester en prod». Si "ça marche pas"™, frapper la nounou la plus
|
||||
proche.
|
||||
|
||||
Une fois les tests concluant, demander à une nounou de pusher.
|
||||
|
||||
### Imprimante
|
||||
|
||||
Lucas et Daniel ont tourné les feuille de π/2rad sans les bacs de l'imprimante.
|
||||
Du
|
||||
coup, deux modes d'agrafages ont été supprimé (sur le coté long, type sauce).
|
||||
En résultat, l'imprimante ne bourre presque plus.
|
||||
|
||||
Il serait bien qu'une alerte soit envoyée aux imprimeurs lorsque quelqu'un
|
||||
lance une grosse impression.
|
||||
|
||||
### Tunnel IPv6
|
||||
|
||||
<http://tunnelbroker.net/>
|
||||
Il est possible a priori d'avoir la sortie du tunnel sur Paris (au lieu de
|
||||
Marseille).
|
||||
Valentin a constaté de meilleurs débits.
|
||||
|
||||
Problème : il faut changer le set d'IP.
|
||||
|
||||
La configuration a aussi l'air d'être plus facile à mettre en place.
|
||||
Un tunnel de test a été mis en place sur {{{vo}}}.
|
||||
|
||||
On pourrait également mettre un autre tunnel spécialement pour le miroir Debian.
|
||||
|
||||
### Question diverses
|
||||
|
||||
#### Bridage adhérent
|
||||
|
||||
Daniel propose que, après les 24h de déconnexion pour upload,
|
||||
les adhérents soient obligés de cliquer sur un liens envoyé dans le mail de
|
||||
déconnexion pour être débridés.
|
||||
Tout le monde est d'accord.
|
||||
|
||||
On transmettra au CA.
|
||||
|
||||
#### Vidéo aux 15 ans
|
||||
|
||||
Ariane a à la main une caméra achetée chez Darty.
|
||||
Pierre-Elliott s'occupe de faire en sorte de récupérer les flux slide, camera,
|
||||
et probablement son régie sur son PC pour les mixer en direct.
|
||||
De là, il sera probablement possible de proposer un streaming en direct.
|
||||
|
||||
Il n'y a qu'une prise Ethernet au Villon, (dans le placard). Un câble sera tiré
|
||||
jusqu'aux ateliers.
|
||||
|
||||
#### Espace de stockage et FedeRez
|
||||
|
||||
FedeRez a demandé plus de place sur {{{baldrick}}} pour que les serveurs
|
||||
puissent
|
||||
se backuper les uns les autres.
|
||||
Leur allouer 50Go n'est pas un problème, mais soulève la question d'acheter des
|
||||
disques
|
||||
de 600Go pour remplacer les disques de 300Go de la baie des domU, pour faire de
|
||||
la virtualisation
|
||||
pour les clubs.
|
||||
|
||||
Un devis a déjà été transmis au CA il y a un certain temps.
|
||||
Il faudrait avoir son aval sur la question.
|
||||
|
|
@ -0,0 +1,35 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : 31 Octobre 2013
|
||||
* Lieu : 2B
|
||||
* Début : 19h10
|
||||
* Fin : 19h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Valentin Samir
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Pont Wifi
|
||||
|
||||
Il relie le bâtiment B et une collocation rue des Vignes à Cachan (~600 m).
|
||||
Très bonne synchro et très bon RTT. Les débits obtenus sont plutôt prometteurs
|
||||
au vu des réglages précaires.
|
||||
Valentin a regardé rapidement le tagging dynamique des vlans sur un bridge (par
|
||||
exemple sur la borne du toit du B``) et n'a rien trouvé. Le plus simple serait
|
||||
d'acheminer le vlan adh via ces bornes sans authentification radius.
|
||||
|
||||
/!\ Nous avons emprunté le câble de la borne du 6B (Busiris) pour réaliser le
|
||||
câblage du pont, il faudra donc retirer un câble pour cette borne.
|
||||
|
||||
### Disque Dur Baie de Disque
|
||||
|
||||
Le CA a prévalidé un ordre de grandeur de prix (entre 2500 et 3000€). On
|
||||
demandera un devis à Anne, notre fournisseur, lors de son retour de vacances.
|
||||
|
||||
### Questions Diverses
|
||||
|
||||
Aucune.
|
||||
|
|
@ -0,0 +1,187 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 14 Novembre 2013
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h11
|
||||
* Fin : 21h20
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Raphaël-David Lasseri
|
||||
* Valentin Samir
|
||||
* Vincent Le Gallic
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Wifi
|
||||
|
||||
#### Pose de borne
|
||||
|
||||
Des bornes wifi ont été placées aux étages 3, 4 et 5 du G, orientées vers
|
||||
l'extérieur. Ça marche du tonnerre de Brest ! On a quasiment plus de câble, or
|
||||
il nous reste des bâtiments à couvrir (A, PdJ, une partie du G)
|
||||
|
||||
Initialement, une seule borne (!NanoM2Loco) était prévue par étage, avec les
|
||||
nombreuses bornes de test, on s'est permis d'en placer deux par étage.
|
||||
Pour couvrir le RDC, le 1er et le 2ème, il est nécessaire de rajouter deux
|
||||
bornes
|
||||
supplémentaires.
|
||||
|
||||
Il faut faire les comptes de ce qu'il nous reste (Unifi + Pico), pour finir la
|
||||
couverture prévue au A et PDJ, pour relancer une commande si nécessaire.
|
||||
|
||||
On fait un devis pour le prochain CA pour des bobines de câbles et des bornes.
|
||||
|
||||
#### Taggage dynamique
|
||||
|
||||
L'idée est de placer les client wifi sur des VLANs différents au moment de
|
||||
l'authentification.
|
||||
Côté radius, un script python permet d'assigner un VLAN à chaque machine, en
|
||||
fonction de différents critères (blacklist, présence d'ipv4). Ça marche.
|
||||
|
||||
Coté borne, c'est correctement configuré sur OpenWRT et hostapd. À la connexion,
|
||||
le client est bien placé sur la bonne interface. Mais un bug fait que de temps
|
||||
en temps, pour certains clients (sur les réauthentifications par exemple), le
|
||||
broadcast/multicast ne passe plus. Ce qui empêche les requête ARP, NPD et/ou
|
||||
les RA de passer.
|
||||
Sinon, ça marche.
|
||||
Les images de bornes flashées en ce moment sont configurées pour. Pour l'activer
|
||||
en production, il n'y a qu'à faire une modification coté serveur radius.
|
||||
|
||||
#### VLAN radin
|
||||
|
||||
Maintenant, c'est un vlan ipv6, il y a des RA et un nat64 qui marchent. Il faut
|
||||
ajouter un comptage d'upload (qui comprend un log mac_ip) et un log de qui
|
||||
contacte quoi quand.
|
||||
Pour les logs, il faut soit envoyer le flux ailleurs pour stockage, soit
|
||||
utiliser dyson (monitoring avec un mirroring de port) comme cela avait été
|
||||
prévu initialement.
|
||||
|
||||
### Imprimante
|
||||
|
||||
#### Envoi de mails
|
||||
|
||||
Lucas a fait un script qui envoie des mails quand l'imprimante est bourrée.
|
||||
Le script est pour l'instant stateless, il faudrait lui ajouter une mémoire
|
||||
pour qu'il ne spamme pas comme un cochon.
|
||||
|
||||
#### Appli intranet2
|
||||
|
||||
Daniel a une appli pas finie pour l'intranet2, mais ça avance. L'idée était de
|
||||
faire ça de manière modulaire pour avoir dans django la liste des impressions et
|
||||
l'état actuel, et avoir l'historique via reversion qui conserverait les
|
||||
états successifs.
|
||||
Hélas reversion semble bugguer et ça pète les couilles de Daniel.
|
||||
De plus, pour interfacer cela facilement avec tout, il a implémenté une file
|
||||
de convergence : où on enfile les tâches à imprimer, et où les trucs qui
|
||||
impriment viennent chercher leur document à imprimer.
|
||||
|
||||
On pourait ajouter une étape intermédiaire à l'impression : la
|
||||
compatibilisation :
|
||||
|
||||
1. On upload un pdf
|
||||
1. Il se compatibilise, on est notifié qu'il l'est
|
||||
1. On lance l'impression depuis la liste des documents compatibilisés
|
||||
|
||||
On peut penser à avoir un aperçu du document compatibilisé pour se rendre
|
||||
compte que les vidéos, ça ne marche pas en pdf 1.2.
|
||||
|
||||
#### Papier de l'imprimante
|
||||
|
||||
Ariane, lors de la dernière commande de papier, a pris du papier blanc moins
|
||||
cher.
|
||||
Ça a l'air de marcher, du coup, ça pourrait être cool de le garder.
|
||||
À noter qu'il serait moins blanc que l'ancien, mais en fait, on ne voit pas
|
||||
vraiment la différence.
|
||||
|
||||
#### «Mise à jour» du 4J
|
||||
|
||||
La desserte pour ranger le papier au 4J a été installée, ça marche pas trop mal,
|
||||
il y a un peu moins de papiers imprimés partout.
|
||||
|
||||
Daniel et Valentin ont débarrassé le 4J des
|
||||
vieilleries ({{{mdr}}}, {{{oie}}}, {{{canard}}}, vieilles batteries, etc).
|
||||
On y a également migré tout un tas de livres qui étaient au 2B, du coup il y a
|
||||
de la lecture au 4J pour ceux qui s'ennuient.
|
||||
|
||||
Avant de se lancer dans la commande d'un canap, on va proposer au BdE de
|
||||
récupérer deux des ex-sièges espace Condorcet. Ils feraient un bon test de
|
||||
canapé, et pour l'instant, à la Kfet, ils sont en train de mourir à petit feu.
|
||||
|
||||
### Sip
|
||||
|
||||
On est passé de la version {{{svn}}} à la version packagée dans jessie (à coup
|
||||
de
|
||||
pinning). Ça marche mieux et on n'aura plus à recompiler à la main le tout à
|
||||
chaque màj.
|
||||
|
||||
Il y a une api (et une commande {{{sip_message}}} sur zamok) pour envoyer des
|
||||
IM via python en appelant {{{/usr/scripts/sip/asterisk.py/Sms.send(dst, msg,
|
||||
src)}}}.
|
||||
|
||||
### Mails
|
||||
|
||||
caca clueringer et ipv6 -> il FAUT un remplaçant peut être est-ce possible
|
||||
avec anvil
|
||||
Il semblerait que la version actuelle de policyd ait des problèmes avec l'ipv6,
|
||||
qui vient d'être activée pour l'envoi sur smtp.crans.org.
|
||||
Du coup, clubringer a été désactivé et il n'y a plus de limite du
|
||||
nombre/quantité
|
||||
de mails envoyés par utilisateur authentifié. Ça ne doit pas durer, donc soit
|
||||
utiliser la version 2.1 de policyd qui a l'air de marcher, soit voir si c'est
|
||||
possible avec anvil (à première vue, non).
|
||||
|
||||
### Adaptateur USB-ethernet
|
||||
|
||||
Le trendnet est bien. Il marche out of the box, il faut juste trouver une
|
||||
solution pour mettre un éventuel driver à disposition pour les windows users.
|
||||
|
||||
On choisit le modèle Trendnet TU2-ET100 Adaptateur USB 2.0 Ethernet 10/100.
|
||||
|
||||
### Politique stockage des mots de passe des scripts
|
||||
|
||||
On veux diviser secrets.py pour le rendre plus facilement utilisable et
|
||||
modulable (droits d'accès différents) :
|
||||
|
||||
* faire plein de petits fichiers
|
||||
* laisser tout au même endroit et lancer un autre programme en faisant
|
||||
sudo (avec un NOPASS)
|
||||
|
||||
La solution à coup de sudo est préférée, au grand dam de Valentin.
|
||||
|
||||
### Nouvelles déconnexions
|
||||
|
||||
Deux nouvelles blacklist ont été mise en place : une pour carte invalide et une
|
||||
pour paiement. '''Il ne faut plus mettre un bloq pour ces cas-là.'''
|
||||
|
||||
On va également demander au C.A. s'il on peut arrêter de demander le certif de
|
||||
scolarité/carte d'étudiant après la première adhésion.
|
||||
|
||||
### Nom de domaines
|
||||
|
||||
On se demande s'il ne serait pas bien que les noms de domaine genre
|
||||
vo.crans.org fournissent l'ipv4 associée à la machine, mais aussi l'ipv6.
|
||||
|
||||
Le problème de la saturation du lien se pose. Pour l'instant, il vaut mieux
|
||||
pousser l'ENS à mettre en place l'ipv6.
|
||||
|
||||
Si on le fait, il faudrait sans doute mettre en place le domaine .v4.crans.org,
|
||||
analogue à .v6.crans.org.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Perms du jeudi
|
||||
|
||||
La perm est trop souvent désertée le Jeudi soir lorsqu'il y a Internounou ou CA
|
||||
(c'est-à-dire, souvent). On propose donc de passer les horaires de perm du Jeudi
|
||||
à 18h-19h.
|
||||
|
||||
Il faut soumettre ça au CA, et mettre à jour les affiches/wiki.
|
||||
|
||||
#### Devis
|
||||
|
||||
Xen vers proxox migration dur dur, achat serveur ?
|
||||
Dyson weak weak, achat seveur ?
|
||||
|
|
@ -0,0 +1,97 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 28 Novembre 2013
|
||||
* Lieu : Salle Condorcet (bât d'Alembert)
|
||||
* Début : 19h00
|
||||
* Fin : ''avant 22h''
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Valentin Samir
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Imprimante
|
||||
|
||||
Dans l'ordre : bourrage papier répétitif sur le bac 1, puis blocage en erreur
|
||||
SAV.
|
||||
Print Platinium à demander de confirmer le passage du technique, a priori, il
|
||||
n'est pas passé.
|
||||
Il faut renvoyer un mail a Print Platinium.
|
||||
|
||||
### Vente de matériel / consommable
|
||||
|
||||
Depuis 1 an nous vendons des câbles Ethernet. Ceci était fait de manière
|
||||
informelle. Nous vendons desormais d'autres consommables et
|
||||
matériels (adaptateur USB/Ethernet, boudins de reliure, etc.). Un nouveau menu
|
||||
a été créé dans gest_crans pour cela. Il permet pour l'instant de compabiliser
|
||||
les ventes d'adaptateur et de câbles. Il faut l'utiliser pour toutes ventes.
|
||||
Il faut maintenant rajouter les autres items proposés à la vente.
|
||||
|
||||
whos affiche la liste des factures d'un adherent. Pour consulter une facture en
|
||||
détail, il vaut mieux utiliser whos_lc.
|
||||
|
||||
### lc_ldap
|
||||
|
||||
A priori tout fonctionne (factures, ressucite_lc, pretty printing). Il faut
|
||||
tester intensivement lc_ldap avant de faire la migration complète.
|
||||
Il faudrait peut-être refaire l'affichage de l'item chambre qui est pour
|
||||
l'instant importé de whos.
|
||||
|
||||
### PXE boot
|
||||
|
||||
Valentin a ajouté la dernière ubuntu. Ça serait bien qu'un apprentis voient
|
||||
comment on fait pour le mettre a jour.
|
||||
|
||||
### Nouveaux disques dur
|
||||
|
||||
Les nouveaux disques SAS 2To pour la baie de disque sont arrivés. Ils sont
|
||||
installé dans l'ancienne baie de disque.
|
||||
Il faudrait savoir comment on les partitionne :
|
||||
Pierre-Elliott a suggéré de fragmenter les homes, une partition par lettre de
|
||||
l'alphabet, comme ça c'est plus facile pour faire des fsck.
|
||||
Il est proposé de faire un volume logique sur la baie, de mettre un LVM dedans
|
||||
et de faire une partition sur le LVM par lettre.
|
||||
|
||||
On utiliserait 4To des nouveaux disques pour les home (reste 2To de spare)
|
||||
. les 600Go pour les VM du crans
|
||||
. les 300Go pour les clubs
|
||||
|
||||
On laisserait les $HOME dans /home/login et on mettrait un lien lien
|
||||
symbolique /home/login -> /home-adh/l/login sur les machines où /home est monté
|
||||
en entier, et on tweekerait les script shell de autofs sur les autres.
|
||||
|
||||
Daniel propose de créer la nouvelle arboressence sur l'ancienne partition (avec
|
||||
les liens symboliques). Cela devrait être rapide (il faut déplacer les dossiers
|
||||
des home). Puis de faire des rsync vers les nouvelles partitions.
|
||||
|
||||
### Wifi
|
||||
|
||||
Bobine de cable reçue, séance au G samedi.
|
||||
|
||||
### Enregistrement événementiel
|
||||
|
||||
Valentin a mis les conférences des 15 ans, de l'install party 2013, des journée
|
||||
fédérez 2013 et quelques autres sur <http://video.crans.org> (le logiciel
|
||||
s'appel mediadrop)
|
||||
Les fichiers multimédia sont sur <http://ftp.crans.org>, on rentre juste les
|
||||
liens dans mediadrop. Pour faire du streaming efficace, on utilise du rtmp en
|
||||
plus des liens http normaux.
|
||||
|
||||
### Etherpad-lite
|
||||
|
||||
Valentin a mis la conf au propre et l'a mis dans monit avec un init script.
|
||||
<http://pad.crans.org/>
|
||||
Ça marche bien, par contre, la plupart des plugins qui ont l'air utile sont
|
||||
relativement caca (memory leak et cie).
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Serveur pour la virtualisation
|
||||
|
||||
Pierre-Elliott voudrait dimensionner un serveur de virtualisation a peut près
|
||||
comme fz (~16Go de ram, pas de disque dur, des portS ethernet) avec idéalement
|
||||
un proc avec 12 à 16 coeurs logiques. Le montant du prix serait de l'ordre
|
||||
de 4000€.
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date :Jeudi 9 janvier 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h25
|
||||
* Fin : 20h55
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Valentin Samir
|
||||
* Jordan Delorme
|
||||
* Pierre-Elliott Bécue
|
||||
* Ariane Soret
|
||||
* Lucas Serrano
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### CACert
|
||||
|
||||
Le domaine crans.org à été migré du compte de Stéphane Glondu vers le compte du
|
||||
crans. Les certificats ont donc été révoqués puis recréés.
|
||||
Tous les administrateurs déclarés à CACert peuvent émettre des certificats pour
|
||||
les domaines enregistrés au crans.
|
||||
|
||||
### Authentification par certificat
|
||||
|
||||
Il serait intéressant de permettre aux gens de se connecter à certains services
|
||||
avec une authentification par certificat.
|
||||
Par exemple pour le wifi, vu que l'on utilise déjà les mots de passe wifi comme
|
||||
un certificat.
|
||||
Ça serait cool d'avoir aussi de l'auth par certificat en imap. Dovecot ne
|
||||
permet pas nativement d'ajouter de l'authentification par certificat
|
||||
parallèlement à une authentification par mot de passe (uniquement comme
|
||||
authentification supplémentaire). Ça serait possible de le faire en utilisant
|
||||
la méthode d'authentification via script custom, ça n'est pas très propre. Une
|
||||
solution plus propre serait de mettre un second serveur imap qui ne ferait que
|
||||
de l'authentification par certificat.
|
||||
|
||||
Postfix gère bien l'auth par certificat, donc si on décide de mettre ça en
|
||||
place ça ne devrait pas poser de problème.
|
||||
|
||||
Idéalement, il y aurait une interface sur l'intranet permettant de générer des
|
||||
certificats pour divers choses.
|
||||
L'idée serait donc d'avoir une bdd centralisant les certificats et leurs usages
|
||||
possibles.
|
||||
|
||||
### Dns menteur ?
|
||||
|
||||
Valentin a mis une zone de response-policy (db.loppsi.crans.org) pour mentir
|
||||
plus proprement sur le dns. Pour le moment, c'est utilisé pour renvoyer vers
|
||||
les miroirs locaux depuis les vlans accueil et événement.
|
||||
Ça serait plus propre d'utiliser cette zone à la place de db.fake (qui est une
|
||||
fausse zone racine) pour le vlan accueil.
|
||||
|
||||
### IPv6
|
||||
|
||||
ne pas laisser passer le /32 de google semble bien le soulager
|
||||
Le /32 de Google a été puni en IPv6 pour des raisons techniques (limitation de
|
||||
bande passante alors que l'IPv6 est utilisé préférentiellement).
|
||||
Lucas affirme que la diminution de trafic n'est pas lié uniquement aux serveurs
|
||||
google, mais est un effet secondaire dû au fait que les gens n'ont plus d'accès
|
||||
à un moteur de recherche et arrêtent donc de s'en servir.
|
||||
|
||||
Il est cependant peu probable que Microsoft se tire une balle dans le pied en
|
||||
bloquant l'ipv4 quand il y a une v6 active, vu que tous ses sites sont en
|
||||
v4 (dont bing…). Des tests seront menés sur vo ce soir, et on essaiera
|
||||
d'adopter une attitude pertinente.
|
||||
|
||||
### Radio
|
||||
|
||||
Valentin a mis des jolies n'images sur <https://intranet2.crans.org/tv/>, et
|
||||
un serveur icecast sur Cochon pour relayer la radio.
|
||||
|
||||
Valentin voudrait ouvrir le port icecast de cochon pour diffuser la radio vers
|
||||
l'extérieur (ça prend pas énormément de bande passante), dans l'ensemble,
|
||||
l'idée semble intéressante, il faut juste s'assurer que c'est licite.
|
||||
|
||||
### Impression
|
||||
|
||||
Certaines personnes semblent parvenir à imprimer N copies d'un document en n'en
|
||||
payant qu'une seule. Comme ils ne le souhaitent pas vraiment et nous non plus,
|
||||
on cherche une solution.
|
||||
Ce problème serait dû au fait que l'intranet thread et donc ne gère pas
|
||||
correctement les accès concurrents.
|
||||
|
||||
On pense mettre une barrière au bon endroit pour s'assurer que rien ne plante.
|
||||
L'alternative est de finir l'appli impression sur l'intranet2.
|
||||
|
||||
### Remplacement disque Fy
|
||||
|
||||
C'est fait. Le disque pété est (probablement) parti vers HP. Le disque pas pété
|
||||
est en place, et fonctionne.
|
||||
|
||||
### Virtualiseur
|
||||
|
||||
Un devis à été demandé, il devrait bientôt être disponible.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Nous ? (C'est le goût ?)
|
||||
|
||||
Le collège technique accueille trois nouvelles nounous : Raphaël-David, Ariane
|
||||
et Jordan.
|
||||
|
||||
On précise au passage que la quantité de travail à fournir est laissée à
|
||||
l'appréciation des sus-nommés.
|
||||
Le fait d'être nounou n'engage pas les personnes à s'investir, mais leur donne
|
||||
plus d'opportunités quant à leur engagement.
|
||||
|
||||
On essaiera de prendre un peu de temps d'ici la semaine prochaine pour
|
||||
présenter certaines des « obligations » des nounous (techniques).
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : jeudi 23 janvier 2014
|
||||
* Lieu : salle Condorcet, bâtiment d'Alembert
|
||||
* Début : 19h25
|
||||
* Fin : 20h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Aymeric Labatut
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël Cauderlier
|
||||
* Valentin Samir
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Be friendly
|
||||
|
||||
Il est suggéré d'accroître la visibilité de
|
||||
<https://wiki.crans.org/Cr%C3%A9erUnCompteWiki> pour la création de compte wiki
|
||||
De manière générale, il faudrait faire une page BienvenueAuCrans ou un truc
|
||||
du genre qui pointe vers tous les trucs qu'un nouvel
|
||||
arrivant pourrait vouloir apprendre pour profiter de nos services. Plein de
|
||||
pages d'explication gagneraient en visibilité.
|
||||
<http://git.crans.org/?p=usr-scripts.git;a=commit;h=f657e57a0> ? -- nit
|
||||
|
||||
Il a été soulevé le fait que la création d'un compte Wiki n'était pas triviale
|
||||
pour tout le monde. Un lien vers la page idoine a été ajouté depuis la page de
|
||||
connexion.
|
||||
Il faut faire plus de promotion de nos services pour les nouveaux adhérents,
|
||||
notamment la création d'une page wiki (CransPratique ?)
|
||||
pour les nouveaux adhérents.
|
||||
|
||||
* Merci ! -- WikiCandy <<DateTime(2014-01-23T20:50:21Z)>>
|
||||
|
||||
### Nouvelle grappe de disque dur
|
||||
|
||||
Le RAID6 est fait, il faut configurer la baie de disques slon pour qu'elle soit
|
||||
connectée aussi au switch iscsi. Puis on pourra commencer la migration des
|
||||
homes (enfin, leur copie).
|
||||
|
||||
PEB commencera ça d'ici une petite semaine, mais si quelqu'un est intéressé,
|
||||
qu'il fasse signe.
|
||||
|
||||
### DNS
|
||||
|
||||
Plusieurs choses. Première rotation des KSK (key signing key dnssec) pour
|
||||
crans.eu. On a eu une petite co(q)uille avec bind, mais on l'a réglée.
|
||||
|
||||
Les clefs ECDSA sont aussi prises en charge maintenant dans le DNS.
|
||||
L'algorithme ecdsa a été ajouté dans le fichier /etc/ssh/sshd_config sur les
|
||||
serveurs.
|
||||
Les serveurs ne disposant pas de clef ecdsa envoient des warning.
|
||||
La commande pour générer une telle clef est :
|
||||
sudo /usr/bin/ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -b 521 -t ecdsa -N ""
|
||||
|
||||
Le collège des nounous présentes décide collégialement dans la bonne humeur
|
||||
d'activer l'ipv6 sur les noms de domaine par défaut.
|
||||
Par souci de compatibilité, en plus des zones v6 (qui sont ipv6 only), des
|
||||
zones v4 seront alors créées (qui seront ipv4 only).
|
||||
|
||||
Actuellement seules les machines ayant l'attribut ldap dnsipv6=TRUE ont de
|
||||
l'ipv6 dans leur nom de domaine. Valentin propose de l'utiliser à partir de
|
||||
maintenant comme suit : seules les machines avec l'attribut ldap dnsipv6=FALSE
|
||||
garderont un nom de domaine ipv4 only.
|
||||
|
||||
Les machines concernées seraient :
|
||||
|
||||
* charybde (pour éviter de faire passer le ftp à traver le tunnel ipv6)
|
||||
|
||||
Comme le script actuel de génération des zones des dns est vieillisant, il
|
||||
serait bien d'adopter ces modifications en écrivant un nouveau script, dans un
|
||||
style plus fonctionnel, utilisant lc_ldap.
|
||||
|
||||
### Nouveau virtualiseur
|
||||
|
||||
Son nom est ft.
|
||||
Le nouveau virtualiseur est arrivé, a été installé, et s'appelle ft. On l'a
|
||||
foutu au 0B, et on a viré malloc, daath et gordon. Niveau alimentations on est
|
||||
à poil, faudrait racheter une pdu (oui, un truc qu'on visse dans l'armoire à
|
||||
l'arrière).
|
||||
|
||||
Il marche bien, proxmox est installé, la migration marche, il est connecté à la
|
||||
baie de disques, et il est FAT. (pas 32)
|
||||
|
||||
Il n'a que 16 Go de RAM sur les 300 potentiels qu'il peut avoir. On achètera
|
||||
peut-être quelques barrettes de 8 Go.
|
||||
|
||||
Sinon, l'onduleur est sollicité à 67 % de sa puissance maximale.
|
||||
|
||||
Il est possible que ses batteries soient déficientes. Il faudrait donc faire
|
||||
des tests, sachant que l'onduleur est censé tenir 40 min au moins.
|
||||
|
||||
### Nouvelles bornes
|
||||
|
||||
Say hello to Demodocos, pour le bâtiment Leonard de Vinci !
|
||||
Jordy aimerait poser encore d'autres bornes (3 serait appréciable) au Leonard
|
||||
de Vinci, car il n'y a strictement rien.
|
||||
De plus, ''hel'' ne marche pas : un technicien va la rebooter électriquement au
|
||||
cas où.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Et pour l'écran de vo
|
||||
|
||||
Le rétroéclairage ne fonctionne plus. Valentin propose qu'on achète un écran
|
||||
de 30 pouces. PEB dit qu'il est pour si on achète un nouveau vo avec une GPU
|
||||
suffisante.
|
||||
|
||||
Plus sérieusement, on se propose de racheter un écran de la même gamme de
|
||||
qualité (que celui-ci avait en 2008).
|
||||
|
|
@ -0,0 +1,135 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 6 février 2014
|
||||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||||
* Début : 19h00
|
||||
* Fin : 20h30
|
||||
|
||||
## Présents
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Interfaçage de cranspassword avec ldap
|
||||
|
||||
On a rajouté un attribut gpgMail (en plus du gpgFingerprint) dans la base ldap.
|
||||
Il est fonctionnel dans le nouveau binding, mais pas encore dispo dans
|
||||
gest_crans.
|
||||
Daniel a écrit un script qui génère la configuration de cranspassword serveur à
|
||||
partir de la base ldap (en se servant des attributs droits, gpgFingerPrint et
|
||||
gpgMail).
|
||||
Pour le moment, la base a été peuplée (pour l'attribut gpgMail) pour tous les
|
||||
gens qui avaient donné une fingerprint.
|
||||
|
||||
Il sera bientôt mis en production.
|
||||
Question : modifie-t-on la configuration de manière automatique (via un cron)
|
||||
ou requiert-on une intervention humaine pour confirmer les modifications de
|
||||
droits ? On décide de garder un système de confirmation avant d'appliquer les
|
||||
modifications (à la bcfg2) pour rendre la chose failproof.
|
||||
|
||||
Todo : écrire une application sur l'intranet2 (dans mon compte) pour enregistrer
|
||||
les fingerprint/mail.
|
||||
|
||||
### apt-key
|
||||
|
||||
Le crans possède un dépôt custom pour les paquets qu'il crée pour lui même (par
|
||||
exemple bcfg2).
|
||||
Ces paquets sont alors signés par une nounou (avec sa clef gpg). Aussi, faut-il
|
||||
installer ces clefs sur les serveurs dans la configuration d'apt pour pouvoir
|
||||
installer les paquets sans warning.
|
||||
Les clefs sont dans bcfg2.
|
||||
Rappel: il y a un
|
||||
script {{{/usr/scripts/gestion/tools/apt-keys-crans.py}}} pour mettre à
|
||||
jour les clefs sur bcfg2.
|
||||
|
||||
Pour le moment il est exécuté manuellement. Valentin propose de le croner et de
|
||||
retirer les fichier générer du dépôt git de bcfg2.
|
||||
|
||||
Pas d'objection cinglante.
|
||||
|
||||
### Génération du dns
|
||||
|
||||
Valentin a réécrit le script bind.py de génération du DNS. C'est moins
|
||||
monolithique, plus POO et ça utilise lc_ldap.
|
||||
Changement notable : Les machines ont leur IPv6 d'annoncée par défaut par leur
|
||||
nom de domaine.
|
||||
|
||||
* {{{nom.v4}}} retourne seulement l'IPv4.
|
||||
* {{{nom.v6}}} seulement l'IPv6.
|
||||
|
||||
Il y a une case à cocher dans l'intranet2 dans l'application machines pour
|
||||
désactiver ou réactiver ce comportement.
|
||||
|
||||
Deux trois problèmes:
|
||||
|
||||
* {{{freebox}}} et {{{ovh}}} ont des IPv6 erronées dans la base
|
||||
ldap (IPv6 locales) -> plus joignables une fois annoncée dans le DNS
|
||||
* {{{zbee}}} -> pour des raisons de NFS qui essayait de se monter en IPv6 à
|
||||
travers le pare-feu
|
||||
* munin -> les acl des nodes n'autorisaient pas l'IPv6 (connexion refused) ce
|
||||
qui empêchait le fallback IPv4
|
||||
|
||||
### IPv6
|
||||
|
||||
Daniel a reregardé Huricann-Electrics : le plan était d'adhérer à Gitoyen pour
|
||||
pouvoir lui demander un numéro d'AS (Autonomous System) et des IPv6.
|
||||
Niveau coût il faudrait payer l'adhésion à Gitoyen (entre 100 et 200€) plus des
|
||||
frais
|
||||
administratifs (entre 200 et 300€).
|
||||
Pierre-Elliott fait remarquer qu'on adhère à FedeRez pour un prix plus élevé.
|
||||
Niveau administratif, il faut étudier la question (demander au CA).
|
||||
|
||||
Valentin fait remarquer que quand bien même, avoir ses propres IPs serait bien
|
||||
sympathique, il faut s'assurer de pouvoir les utiliser le jour où l'ENS passe
|
||||
en IPv6. Aujourd'hui pour annoncer ses propres IPs via H-E, le tunnel de sortie
|
||||
se trouve à Londres au lieu de Paris. Ce qui fait passer le RTT de 1ms à 8ms.
|
||||
|
||||
### CaCert et clubs
|
||||
|
||||
L'idée est de générer des certificats SSL !CaCert pour les machines de clubs
|
||||
qui en font la demande.
|
||||
|
||||
Sur le principe ok. Seul problème : si la machine est détruite, le certificat
|
||||
existe toujours alors que le domaine peut être utilisé par quelqu'un d'autre.
|
||||
|
||||
Soit on révoque directement les certificats quand la machine disparaît, via
|
||||
une API (qui n'a pas l'air dispo pour l'instant
|
||||
sur CaCert.
|
||||
|
||||
Soit on empêche les opérations sur les machines qui ont toujours un certificat
|
||||
valide.
|
||||
|
||||
API à étudier : <http://wiki.cacert.org/Software/IntegrationInterface>
|
||||
<http://wiki.cacert.org/SubRoot>
|
||||
|
||||
Il serait bien d'avoir une interface sur l'intranet2 (étendre l'interface de
|
||||
machine)
|
||||
pour permettre de faire des demandes de certificats (et si l'API de !CaCert ne
|
||||
marche pas,
|
||||
une interface pour y répondre manuellement).
|
||||
|
||||
### Digicode
|
||||
|
||||
Lucas a rajouté une option sur l'app digicode pour créer des codes. Ça a l'air
|
||||
de marcher.
|
||||
|
||||
Reste plus qu'à migrer le tout.
|
||||
|
||||
### Édition .forward
|
||||
|
||||
Raphaël-David a fait un script pour éditer des {{{.forward}}}. Reste à régler
|
||||
le problème de droits d'exécution du script (qui s’exécute en root pour
|
||||
l'instant).
|
||||
Il pourrait être envisagé de donner le droit au groupe respbats d’exécuter le
|
||||
script en temps que n'importe qui du groupe user et de le lancer en temps que
|
||||
l'user dont on veut éditer le .forward (cf ce qui est actuellement fait pour
|
||||
l'intranet1).
|
||||
|
||||
### ft
|
||||
|
||||
Il est installé au 0B physiquement et logiciellement. Ça marche.
|
||||
Il ne reste qu'à finir les migrations depuis Xen.
|
||||
|
||||
### Wifi
|
||||
|
||||
La DSI abandonne le ssid ENS Cachan. On arrête donc définitivement de le
|
||||
diffuser.
|
||||
|
|
@ -0,0 +1,141 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : 20 février 2014
|
||||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||||
* Début : 19h19
|
||||
* Fin : 21h00
|
||||
|
||||
## Présents
|
||||
|
||||
* Ariane Soret
|
||||
* Aymeric Labatut
|
||||
* Daniel Stan
|
||||
* Lucas Serrano
|
||||
* Jordan Delorme
|
||||
* Raphaël-David Lasseri
|
||||
* Riwan Kherouf
|
||||
* Valentin Samir
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Digicode
|
||||
|
||||
Lucas a mis en place le nouveau digicode_server et gen_code sur intranet2 et
|
||||
sur asterisk.
|
||||
Pour générer un code à partir de l'intranet2, il faut accéder à l'interface
|
||||
admin de django.
|
||||
Sinon, on peut toujours en générer sur l'intranet1…
|
||||
|
||||
### lc_ldap
|
||||
|
||||
Valentin a surchargé les attributs de lc_ldap pour permettre une comparaison
|
||||
plus simple (et fonctionnelle) entre des objets ldap.
|
||||
L'égalité fonctionne de façon sémantique sur les objets et les attributs comme
|
||||
on pourrait s'y attendre (du coup {{{'club' in
|
||||
club['objectClass']}}} fonctionne).
|
||||
Les attributs peuvent être instanciés par leur type python correspondant (au
|
||||
lieu de juste des unicodes).
|
||||
Si deux attributs sont égaux, ils ont le même hash (cf. set et hashtable).
|
||||
Les attributs pythons des attributs ldap Attr sont directement accessibles
|
||||
comme des attributs d'Attr.
|
||||
Les {{{machines['historique'].append()}}} fonctionnent comme on pourrait s'y
|
||||
attendre et plein d'autres bonnes choses !
|
||||
|
||||
D'une manière générale, si on a besoin d’accéder à {{{attrs}}} sur
|
||||
les !CransLdapObject ou à {{{value}}} sur les Attr,
|
||||
c'est qu'il manque, sans doute, une méthode à écrire ou surcharger quelque part.
|
||||
|
||||
### Enregistrement automatique des adresses MAC
|
||||
|
||||
Daniel arrive à faire de l'authentification radius pour le WPA2 sans utiliser
|
||||
le module radius dédié à cela mais en utilisant un script python.
|
||||
Lors de l'authentification d'un client sur une borne, la borne met en relation
|
||||
radius et le client, et radius l'authentifie avant de renvoyer le résultat à la
|
||||
borne.
|
||||
|
||||
Une idée en utilisant un script custom serait de pouvoir ne fournir aux
|
||||
adhérents, lors de l'enregistrement d'une nouvelle machine wifi, que le nom
|
||||
d'utilisateur et le mot de passe. Puis de remplir l'adresse mac de la machine
|
||||
seulement lors de la première authentification réussie en utilisant celle de la
|
||||
première machine qui s'authentifie.
|
||||
|
||||
Les gens présents ont l'air assez enthousiastes pour le wifi. Une option
|
||||
similaire en filaire reste à discussion.
|
||||
|
||||
Il serait également bien que la première fois que l'adresse mac est
|
||||
enregistrée, comme la machine vient de se connecter, qu'elle puisse accéder à
|
||||
internet. Pour le dhcp, la mise à jour est déjà instantanée. Il manque la mise
|
||||
à jour du pare-feu, au moins celui de komaz.
|
||||
|
||||
Valentin propose une solution à partir d'une clef ssh n'ayant que le droit de
|
||||
trigger l'appel à generate en s'inspirant
|
||||
de [[CransTechnique/AdminRéseau/CommunicationsParSshEntreLesServeurs]].
|
||||
Nicolas aurait parlé d'une solution rabbitmq qui pourrait à terme remplacer le
|
||||
système maison generate.
|
||||
|
||||
### intranet2
|
||||
|
||||
#### Création de compte wiki
|
||||
|
||||
Fait.
|
||||
|
||||
#### Gestion des clefs ssh
|
||||
|
||||
Valentin a ajouté la possibilité de remplacer les attributs sshFingerprint de
|
||||
ses propres machines. Ils sont alors publiés dans le DNS du crans.
|
||||
|
||||
### DNS
|
||||
|
||||
#### TLSA
|
||||
|
||||
Valentin rappelle brièvement que TLSA est un enregistrement DNS permettant de
|
||||
vérifier la validité d'une clef publique du standard x509 via le DNS.
|
||||
|
||||
Pour pouvoir permettre aux adhérents de publier, dans le DNS de leur machine,
|
||||
leur certificat, il faudrait ajouter un nouvel objet ldap enfant des objets
|
||||
machines (n'a pas de sens en LDAP) qui aurait en attribut :
|
||||
|
||||
* name : les noms de domaine pour lesquels le certificat est
|
||||
utilisé (multivalué)
|
||||
* port : les ports sur lesquels le certificat est utilisé (multivalué)
|
||||
* proto : tcp ou udp (multivalué)
|
||||
* cert : quelque chose représentant le certificat (monovalué)
|
||||
* certtype : le type d'enregistrement ; 0 = CA pinning, 1 = cert
|
||||
pinning, 2 = self trusted CA, 3 = self trusted cert (monovalué)
|
||||
* reftype : 0 = plain cert, 1 = sha256, 2 = sha512 (monovalué)
|
||||
|
||||
À voir si on veut utiliser l'objet pour gérer les certificats d'une manière
|
||||
générale…
|
||||
|
||||
#### Blocage via response policy zone
|
||||
|
||||
Valentin avait lors de l'install party précédente mis en place un DNS menteur
|
||||
renvoyant archive.ubuntu vers
|
||||
le miroir local.
|
||||
Récemment il a étendu le rôle du DNS menteur à la zone crans pour empêcher les
|
||||
IP utilisés par
|
||||
Teredo (tunnel v6 propre aux machines sous windows) de contacter le DNS et
|
||||
ainsi de faire de l'IPv6 pirate.
|
||||
Théoriquement la future présence de RA pirates sur le réseau ne serait donc
|
||||
plus fortuite
|
||||
(en tout cas beaucoup moins).
|
||||
|
||||
### Remplacement de ovh
|
||||
|
||||
Une nouvelle machine est prête pour remplacer ovh : soyouz.
|
||||
''A priori'', Valentin a fini sa configuration. Il faut juste modifier les
|
||||
enregistrements du dns (MX et NS et glue record) pour remplacer ovh.
|
||||
le TLSSTART en smtp ne marche pas, il faudrait juste mettre une paire de clefs.
|
||||
|
||||
On va rendre ovh, il faudrait donc prendre le temps de shred les disques en
|
||||
rescue mode.
|
||||
|
||||
### Question diverse
|
||||
|
||||
#### Migration XEN -> Proxmox
|
||||
|
||||
Daniel propose de faire une séance migration samedi après-midi (tôt pour ne pas
|
||||
concurrencer la LAN A♡).
|
||||
Les volontaires ne lèvent pas tous le doigt en même temps.
|
||||
Daniel annonce donc une « petite » maintenance sur CransIncidents et sur les
|
||||
news.
|
||||
|
|
@ -0,0 +1,196 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 13 mars 2014
|
||||
* Lieu : Salle de conférence du Pavillon de Jardins
|
||||
* Début : 19h22
|
||||
* Fin : 21h12
|
||||
|
||||
## Présents
|
||||
|
||||
* Jordan Delorme
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Gestion des certificats
|
||||
|
||||
Valentin a proposé de mettre tous les certificats SSL crans et les clefs
|
||||
privées associés (possiblement chiffrées) dans ldap et d'utiliser un fuse pour
|
||||
générer automatiquement les fichiers de certificats dont ont besoin les
|
||||
différents services directement à partir de ldap.
|
||||
|
||||
Les certificats pourraient ensuite être gérés par {{{bcfg2}}}, une màj des
|
||||
certifs consisterait à mettre le nouveau en raw dans LDAP et de run
|
||||
un {{{bcfg2}}} wherever needed.
|
||||
|
||||
Pierre-Elliott est contre la présence des clés privées dans LDAP si on ne lui
|
||||
donne pas une bonne raison (et lui-même n'en voit pas). Il faudrait quelqu'un
|
||||
de motivé par le projet parce que ça risque de ne pas être simple.
|
||||
|
||||
Dans l'idée {{{bcfg2}}}, Vincent pense qu'il va falloir gérer les différents
|
||||
formats de certificats. Est-ce qu'on ne pourrait pas faire
|
||||
comme {{{secrets.py}}} ou {{{secrets_new.py}}} ? Problème : actuellement, tout
|
||||
va sur tous les serveurs.
|
||||
|
||||
On attend d'y voir plus clair et d'avoir les idées de Valentin sur le sujet.
|
||||
|
||||
### Multicast filtering
|
||||
|
||||
Sur le réseau les Apple utilisent un protocole foireux, mDNS.
|
||||
|
||||
Le principe est d'annoncer les services des autres machines sur le réseau, même
|
||||
quand elles en ont disparu (passage en veille). Pour cela, elles spoofent l'IP
|
||||
de la machine éteinte. C'est '''mal''', et ça fait beugler {{{arpwatch}}}. On
|
||||
en a eu marre, Ping a demandé aux switchs de dropper le mDNS.
|
||||
|
||||
Problème, ça ne marche que sur les switchs Gigabits et le backbone.
|
||||
Techniquement ça resterait possible entre deux personnes d'un même étage,
|
||||
mais ''a priori'', le multicast n'est transmis qu'une fois qu'il a atteint le
|
||||
querier, à savoir le backbone, qui sait dropper, donc on est sauvés.
|
||||
Bonne nouvelle, on a '''beaucoup''' moins de spam sur flip-flop, et tout ce qui
|
||||
reste est normalement des vrais cas de spoof (ou des changements légitimes
|
||||
d'adresse MAC suite à un câblage).
|
||||
|
||||
### Virtualisation
|
||||
|
||||
#### Xen => Proxmox
|
||||
|
||||
La migration c'est fini. \o/
|
||||
Les vieux disques ont été supprimés. Il faut faire attention car les serveurs
|
||||
ont tendance à paniquer lorsque l'on supprime leurs vieux disques.
|
||||
|
||||
Nouvelles features :
|
||||
|
||||
* Pierre-Elliott est en train de développer des utilitaires en command line
|
||||
pour créer des VM plus facilement. L'objectif idéal serait d'avoir un seul
|
||||
script à lancer, mais si déjà, avec quelques scripts tout faits, on s'en sort…
|
||||
* Les VM utilisent des disques virtIO, qui ont des temps d'accès beaucoup plus
|
||||
courts que les émulations de IDE/SATA/SCSI. Du coup ça juste marche mieux.
|
||||
* Les filesystems (qui étaient en ext3 sur les vieilles vm) sont en ext4.
|
||||
* Proxmox utilise les fonctionnalités VTx with extended pages des procos intel,
|
||||
ce qui permet aux vm de fonctionner en real mode. C'est pas trivial à définir
|
||||
mais en gros, le gain de perf est vraiment élevé.
|
||||
* PEB a fait une conf manuelle qui est dans {{{bcfg2}}} pour l'ISCSI.
|
||||
Maintenant, quand les hosts démarrent, ils ne vont plus attendre 2 minutes
|
||||
toutes les interfaces des baies. Sur les interfaces non branchées, ils
|
||||
n'attendent que 15 secondes.
|
||||
* Le cluster est composé de fz, ft et kdell. fz et ft sont fat, et kdell se
|
||||
défend. Du fait de l'utilisation des features VTx with extended pages des
|
||||
procos, fy est useless. (Son proco ne les supporte pas, ce qui fait que les
|
||||
vm migrées depuis l'un des trois autres sur fy, elles freezent en
|
||||
utilisant 100% d'un cœur.)
|
||||
|
||||
Ce qui nous mène à : « quid de fy ? »
|
||||
|
||||
PEB va essayer de documenter le wiki, parce que chez Proxmox, ils sont
|
||||
clairement avares en infos sur certains points de fonctionnement des clusters.
|
||||
|
||||
Entre autres, il a tweaké le {{{/etc/hosts}}} des hosts Proxmox pour que leur
|
||||
nom « canonique » (celui sans le (.adm)?.crans.org) pointe vers leur IP adm,
|
||||
car c'est avec ce nom que le cluster choisit ses IP. On remercie entre autres
|
||||
les gars de chez Proxmox qui précisent pas ça sur la page « créer un cluster ».
|
||||
|
||||
Pour info, Proxmox vend un service (sous forme de licence) d'aide et de je sais
|
||||
pas trop quoi, à un prix modeste : une trentaine d'euros par cœur par mois. Et
|
||||
bien entendu, TOUS les hosts DOIVENT avoir la MÊME licence.
|
||||
|
||||
#### Avenir de fy
|
||||
|
||||
{{{fy}}} ne servant à rien et étant vraiment fat, il faut se demander ce qu'on
|
||||
en fait. Dyson est complètement à la ramasse en ce qui concerne le monitoring,
|
||||
et komaz commence à se faire un peu vieux.
|
||||
|
||||
Entre les deux, celui qui fitterait probablement le mieux serait dyson.
|
||||
D'autant plus que la garantie de fy expire, et qu'un routeur non garanti, c'est
|
||||
pas cool.
|
||||
|
||||
##### Avenir de komaz/dyson
|
||||
|
||||
Il semblerait bon de racheter un nouveau routeur, pour des raisons de garantie,
|
||||
en plus, il serait bénéfique qu'il fasse le comptage d'upload lui-même, pour
|
||||
décharger le serveur de logs (cf point suivant).
|
||||
|
||||
S'il est dimensionné correctement, ça passera sans problème. Valentin avait
|
||||
suggéré qu'on pourrait améliorer le comptage d'upload pour décharger la base
|
||||
postgres. À voir aussi.
|
||||
|
||||
Ping évoque le SSD, ça pourrait être intéressant pour le futur komaz. Pour
|
||||
thot, il faut y réfléchir. Pour dyson c'est pas utile.
|
||||
|
||||
Passer dyson sur fy semble pas mal.
|
||||
|
||||
#### Elastic search ftw ?
|
||||
|
||||
Logstash l'utilise comme backend. Logstash est paraît-il très bien. On a testé
|
||||
les limites de rsyslog-pgsql. Il faudrait tester, quitte à migrer les db
|
||||
postgres sur des VM.
|
||||
|
||||
Avis aux amateurs pour tester elasticsearch.
|
||||
|
||||
### Application des nouveaux statuts
|
||||
|
||||
PEB a commencé à recoder la moitié de {{{gest_crans}}} et {{{ldap_crans}}} pour
|
||||
qu'on puisse appliquer les adhésions glissantes. Des tests seront faits ce
|
||||
weekend ou le suivant. Il faut prévenir les câbleurs, et leur empêcher
|
||||
l'utilisation de gest_crans durant les tests.
|
||||
|
||||
Les modifs sont sur la branche {{{peb}}} du dépôt de prod. Faites gaffe à pas
|
||||
checkout dessus.
|
||||
|
||||
### Services/Generate
|
||||
|
||||
Nicolas a parlé de {{{rabbitmq}}} comme système pour dispatcher des
|
||||
messages/informations à d'autres machines, en remplacement de generate/services
|
||||
qui marche mal, en 15 min. PEB a testé sur des trucs kikoo, c'est rigolo. On a
|
||||
installé une vm {{{civet}}} qui servirait de serveur rabbitmq. D'autres tests
|
||||
sont à venir, et les curieux peuvent query PEB.
|
||||
|
||||
### Gestion des homes
|
||||
|
||||
PEB a créé 27 disques logiques sur la baie, olasd trouve que ce n'est pas
|
||||
adapté, quid des autres ?
|
||||
|
||||
* Le problème des quotas n'a pas encore été soulevé, 27 filesystems ça veut
|
||||
dire 27 quotas différents. Mais ça peut se régler en se disant que toto
|
||||
passoir ne peut écrire que dans son home.
|
||||
* /home/mail => ln -s /home/mail/user/ /home/user/Mail/INBOX
|
||||
|
||||
. Attention NFS n'exporte pas les liens symboliques comme on le
|
||||
veut. (zbee != zamok)
|
||||
|
||||
### Wifi au PdJ
|
||||
|
||||
La DSI nous a chié au visage pour le tirage des câbles pour nos bornes au PdJ.
|
||||
Donc on devra en tirer nous-même.
|
||||
|
||||
Envoie-t-on un mail courroucé à la DSI ?
|
||||
|
||||
* Owi owi -- [[Wiki20-100]]
|
||||
|
||||
### Migration de git
|
||||
|
||||
Le dépôt {{{git}}} a été viré de charybde. Ça permet de puller/pusher sans
|
||||
attendre des heures qu'il ait fini avec ses IO ftp. Maintenant,
|
||||
contactez {{{geet}}}.
|
||||
|
||||
Vire-t-on les miroirs OpenBSD ?
|
||||
|
||||
### Paquet pour ajout de certificats sur Mac
|
||||
|
||||
Jordy et Ping ont travaillé sur un paquet pour importer les certificats
|
||||
nécessaires pour nos pages. Ce paquet pourrait être l'occasion de modifier le
|
||||
comportement mDNS de Bonjour pour éviter les problèmes posés quelques points au
|
||||
dessus. Ça sera, a priori, bientôt terminé.
|
||||
|
||||
### Le RTC est malade :(
|
||||
|
||||
Valentin semble malade depuis presque deux semaines. Il risque de rentrer chez
|
||||
lui pour quelques temps. Les nounous souhaitent lui témoigner leur soutien et
|
||||
lui souhaitent un prompt rétablissement.
|
||||
|
||||
Pierre-Elliott et Daniel s'occuperont de contacter Anne en cas de besoin durant
|
||||
l'absence de celui-ci (demandes de devis et autre). On lui demandera de nous
|
||||
mettre en copie des mails qu'elle lui envoie (renouvellement de
|
||||
garanties & cie).
|
||||
|
|
@ -0,0 +1,106 @@
|
|||
# InterNounous
|
||||
|
||||
* Date : Jeudi 27 mars 2014
|
||||
* Lieu : Salle de conf au Pavillon des Jardins
|
||||
* Heure : 19h33
|
||||
* Fin : 21h00
|
||||
|
||||
## Présents
|
||||
|
||||
* Aymeric Labatut
|
||||
* Daniel Stan
|
||||
* Jordan Delorme
|
||||
* Lucas Serrano
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
## OdJ
|
||||
|
||||
### GitLab et migration des dépôts git
|
||||
|
||||
Pierre-Elliott a commencé à mettre en place gitlab
|
||||
|
||||
Démo
|
||||
|
||||
1. Aller sur <http://gitlab.crans.org>
|
||||
1. Se loguer avec son compte ldap (CAS ??)
|
||||
|
||||
But : Plus d'acl sur les dépôts. Ça marche aussi avec des comptes locaux (≠ non
|
||||
crans).
|
||||
Le https est maintenant par défaut. L'intérêt est d'accroître la visibilité des
|
||||
dépôts git du Crans et gérer des pull request.
|
||||
Question : quid de gitweb (<http://git.crans.org>) pour l'instant, on le
|
||||
garde (tant que ça marche).
|
||||
|
||||
Il faut ajouter une clé ssh dans son profil gitlab, pour pouvoir ensuite se
|
||||
connecter en tant que l'utilisateur git.
|
||||
Comme tout passe par l'utilisateur git sur le serveur, les modifications,
|
||||
commits et pushes en prod seront sensiblement
|
||||
plus complexes à faire, sauf à forwarder son agent, ou à s'ajouter une clef ssh.
|
||||
|
||||
### Nouvelles bornes WiFi
|
||||
|
||||
On a reçu les nouvelles bornes WiFi au nombre de 12.
|
||||
|
||||
Le modèle reçu a été mis à jour, le système de fixation a changé.
|
||||
Et surtout, on a des injecteurs avec bouton reset (bien pratique quand accéder
|
||||
physiquement à la borne est compliqué).
|
||||
|
||||
Lucas a flashé 3 bornes dans le but de les mettre au bâtiment A. Il faut se
|
||||
faire une séance posage de bornes avec les apprentis.
|
||||
On propose le week-end du 4 Avril.
|
||||
Reste également : le Pavillon des Jardins. On se demande s'il ne vaudrait pas
|
||||
mieux mettre les bornes en dehors des faux-plafonds (qui sont
|
||||
métalliques). À étudier et à discuter avec M Burgun…
|
||||
|
||||
Jordy a posé 4 bornes au DGM, en attente de brassage de vlan côté DSI. (Link,
|
||||
agenor, polynice, ulysse). On attend encore leur inscription sur
|
||||
la <https://intranet2.crans.org/wifimap|WiFiMap> !
|
||||
|
||||
### Nouveau routeur
|
||||
|
||||
Pas encore reçu de devis. L'idée serait de remplacer komaz par un truc un peu
|
||||
plus costaud.
|
||||
|
||||
A priori :
|
||||
<http://store.hp.com/FranceStore/Merch/Product.aspx?id=668812-421&opt=&sel=BSRV#merch-tech-specs>
|
||||
(Vérifier que le contrôleur réseau 4 ports a bien une capacité de switching
|
||||
de 1Gigabit par port et non 1Gigabit au total)
|
||||
|
||||
### Homes des adhérents
|
||||
|
||||
Pierre-Elliott avait créé un lvm par lettre de l'alphabet (+ 1 pour les logs).
|
||||
Une ancienne nounou trouve que ça fait beaucoup. L'intérêt serait de
|
||||
fractionner les sauvegardes, et de récupérer plus facilement d'un crash sur un
|
||||
des fs.
|
||||
|
||||
Reste le problème de la migration…
|
||||
|
||||
### Sécurisation de /usr/scripts
|
||||
|
||||
Pierre-Elliott propose que chaque serveur clone /usr/scripts, avec un cron qui
|
||||
vérifie également la connectivité du nfs. En cas de soucis, il ferait un
|
||||
mount -o bind
|
||||
|
||||
Il faut trouver une solution avec /usr/scripts/var/
|
||||
|
||||
* monit (quasi ok)
|
||||
* numeros_disponibles -> voué à disparaître
|
||||
* fichiers d'impression -> censés être dans le home des adhérents
|
||||
* […]
|
||||
|
||||
Avis à apprenti et nounou motivés
|
||||
|
||||
### CACert
|
||||
|
||||
CaCert a été retiré de Debian
|
||||
<https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=718434>
|
||||
|
||||
Question :
|
||||
|
||||
1. Le ticket soulève des problèmes de sécurité dans le code de CACert, a-t-on
|
||||
peur ?
|
||||
1. Quelle alternative à ce CA ?
|
||||
1. Que faire si on migre ? Aka migre-t-on tout sur un CA commercial ou
|
||||
laisse-t-on le WiFi sur !CaCert ?
|
||||
|
||||
On ne prend pas de décision maintenant.
|
||||
|
|
@ -0,0 +1,199 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 10 avril 2014
|
||||
* Lieu : Condorcet
|
||||
* Début : 19h30
|
||||
* Fin : 21h15
|
||||
|
||||
## Présents
|
||||
|
||||
* Pierre-Elliott Becue
|
||||
* Jordan Delorme
|
||||
* Vincent Le Gallic
|
||||
* Lucas Serrano
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### HeartBleed (OpenSSL)
|
||||
|
||||
On ne rappelle pas les faits : ils sont suffisament détaillés sur le net.
|
||||
Tous les certificats accessibles depuis l'extérieur du campus ont été
|
||||
renouvelés sauf redisdead.
|
||||
|
||||
* j'imagine que le renouvellement des clefs privées est sous entendu, ça serait
|
||||
bien de remettre le TLSA un peu partout (via {{{gest_crans_lc}}} par
|
||||
exemple), le certificat de sogo est révoqué, quid des clefs du openVPN
|
||||
soyouz-komaz-titanic qui donne accès à
|
||||
adm -- ValentinSamir <<DateTime(2014-04-11T01:35:09+0200)>>
|
||||
|
||||
Pierre-Elliott a plus ou moins écrit une page Wiki pour informer les adhérents
|
||||
de la faille de sécurité.
|
||||
Lien de la page : HeartBleed
|
||||
|
||||
Il faut encore renouveler les certificats de :
|
||||
|
||||
* Redisdead (x2)
|
||||
* XMPP
|
||||
* O2
|
||||
* Asterix
|
||||
* Wifi
|
||||
* News
|
||||
* Tracker
|
||||
|
||||
### QR codes
|
||||
|
||||
Le BDE/Gala souhaiterait savoir si le Cr@ns peut éditer les QR codes en plus de
|
||||
les imprimer.
|
||||
|
||||
Y'a plein de lib python pour faire des QRCode. Il faudrait faire un site web
|
||||
pour les organisateurs du gala.
|
||||
On peut utiliser l'interface d'admin d'une appli django.
|
||||
|
||||
On manque pas mal d'infos sur le cahier des charges :
|
||||
|
||||
* Est-ce qu'on doit permettre le paiement en ligne ?
|
||||
* Comment ça se passe pour les bipper le soir du gala ?
|
||||
|
||||
On va demander de plus amples précisions au gala.
|
||||
|
||||
Daphné, membre du bureau du gala 2015 a précisé à Pierre-Elliott le cahier des
|
||||
charges pendant qu'il allait chercher son linge (ah bah bravo).
|
||||
L'idée serait d'avoir un site dédié à la gestion des préventes en ligne, donc
|
||||
l'édition des billets avec QR code, le stockage des informations personnelles
|
||||
des acheteurs, et l'interface de paiement en ligne.
|
||||
|
||||
* Pour le paiement, elle se mettra en relation avec le crédit mutuel ;
|
||||
* Pour l'édition des pdf billets/whatever, on peut le faire.
|
||||
* Pour les scanettes de QRCode, il faut trouver un endroit où en acheter/louer,
|
||||
pour faire des tests
|
||||
|
||||
et voir combien ça coûte.
|
||||
|
||||
Pierre-Elliott la recontactera par mail pour établir une roadmap.
|
||||
Une deadline courte devra être faite pour le site pour que le gala puisse se
|
||||
retourner librement
|
||||
si on est pas assez efficaces.
|
||||
|
||||
### Virtualisation
|
||||
|
||||
Le BdE trouverait confortable de virtualiser ses serveurs : tous sauf
|
||||
videosurveillance.
|
||||
|
||||
Vincent trouve gênant de prendre maintenant une décision engageant les nounous
|
||||
à venir et les BdE à
|
||||
venir de rendre ''techniquement'' accessible aux nounous la base de données du
|
||||
BDE de manière irréversible.
|
||||
Ceci serait valable quel que soit le club/assoce qu'on virtualise.
|
||||
|
||||
On pourrait modifier notre charte de membre actif en précisant qu'on héberge
|
||||
des serveurs contenant potentiellement des données d'adhérents non Cr@ns.
|
||||
Pour les clubs, il est possible de préciser dans le formulaire de création de
|
||||
club que leurs données sont stockées dans un serveur du Cr@ns, ou alors créer
|
||||
un formulaire de création de machine virtuelle pour que chaque parti soit
|
||||
conscient des enjeux.
|
||||
|
||||
Vincent veut bien s'occuper d'écrire un formulaire de création de machine
|
||||
virtuelle, il demandera conseil à Matthieu Bach.
|
||||
|
||||
### Droits apprentis
|
||||
|
||||
La problématique soulevée est que les câbleurs/apprentis ne peuvent pas
|
||||
répondre aux demandes des adhérents
|
||||
concernant leur blocage pour upload.
|
||||
|
||||
Vincent croyait que c'était possible aux apprentis, et a donc fait une
|
||||
modification dans le sudoers, qui a été annulée
|
||||
par Pierre-Elliott depuis.
|
||||
|
||||
Actuellement, la question est donc de savoir si les apprentis devraient avoir
|
||||
ce genre de droit. (exécuter analyse.py, ou autres scripts du style)
|
||||
|
||||
Vincent souligne que les apprentis ont accepté la même charte de membre actif
|
||||
que les nounous et sont donc soumis
|
||||
aux mêmes règles. Par ailleurs, supprimer de la fonctionnalité au nom de la
|
||||
sécurité n'est pas une solution. Enfin, les adhérents
|
||||
qui demandaient des réponses sur disconnect@ n'avaient pas forcément une
|
||||
réponse avant l'expiration des logs.
|
||||
|
||||
* il y a un dump des logs d'{{{analyse.py}}} lors de la déconnexion
|
||||
dans {{{/usr/scripts/var/analyse/IP-TIME.txt}}}, il faudrait d'ailleurs y
|
||||
faire le ménage -- ValentinSamir <<DateTime(2014-04-11T01:35:09+0200)>>
|
||||
|
||||
Premièrement, on peut augmenter la durée de vie des logs d'upload.
|
||||
|
||||
Il est envisagé de créer un droit supplémentaire "Disconnect" permettant aux
|
||||
apprentis à qui on le donnerait de pouvoir répondre aux
|
||||
adhérents sur disconnect@ et de lancer {{{analyse.py}}}. Il faudrait qu'il ne
|
||||
soit pas donné dès l'accession au statut d'apprenti.
|
||||
Dans la même idée, une version spéciale "nouveau câbleur" du whos pourrait être
|
||||
proposé pour filtrer certaines données a priori
|
||||
sensibles lors d'un câblage.
|
||||
|
||||
### Charte des MA
|
||||
|
||||
Pierre-Elliott propose qu'on édite une charte spécifique à signer pour les
|
||||
nounous (ce qui permettrait de faire une
|
||||
page wiki au passage pour résumer les droits (et leur moyen d'application) des
|
||||
nounous), spécifique à leurs nouvelles
|
||||
attributions. Cela servirait en plus de piqûre de rappel lors de l'ajout de
|
||||
droit.
|
||||
|
||||
### IRC
|
||||
|
||||
Il y a actuellement sur #roots des non-MA. Ça pose problème quand on doit
|
||||
parler de données privées d'adhérents : on n'a pas de channel "privé".
|
||||
Si un adhérent doit évoquer des informations personnelles sur #crans, il sera
|
||||
alors invité à rejoindre #roots.
|
||||
|
||||
Les non-membres actifs actuellement présents sur #roots vont être invités à
|
||||
quitter le channel.
|
||||
|
||||
### Câbleuse
|
||||
|
||||
On se propose de mettre la carcasse de oie à la Kfet après l'avoir transformée
|
||||
en câbleuse, branchée à l'imprimante thermique.
|
||||
Si on souhaite installer une interface graphique pour que la câbleuse puisse
|
||||
être utilisée par les permanenciers BDE pour la note
|
||||
en dehors des horaires de permanences Cr@ns, oie est vite gavée. Une solution
|
||||
serait d'installer XFCE ou awesome.
|
||||
|
||||
On a pas de réponse de BdE sur cette possibilité de câbleuse, l'encombrement du
|
||||
bar ou la possibilité de mettre un écran.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Convention Cr@ns-CROUS
|
||||
|
||||
Il faut en parler en CA, mais en gros, une réunion doit être organisée avant
|
||||
l'été, de façon à
|
||||
l'actualiser, voire, la resigner.
|
||||
|
||||
En vrac, les points à discuter :
|
||||
|
||||
* Fiche câblage
|
||||
* Locaux sensibles
|
||||
* Access points (WIFI)
|
||||
|
||||
En bonus (non lié à la convention)
|
||||
|
||||
* Livret d'accueil du CROUS
|
||||
|
||||
#### Manque d'IP
|
||||
|
||||
On va demander à Daniel s'il peut remettre en service son système de ménage
|
||||
automatisé. Aussi bien pour le wifi que le filaire.
|
||||
|
||||
#### Ressuscite
|
||||
|
||||
{{{ressuscite.py}}} est cassé, encore…
|
||||
Vincent a ressuscité récemment un adhérent en plongeant encore les mains dans
|
||||
le cambouis, il en a marre, il va mettre dans {{{/usr/scripts/utils/}}} un truc
|
||||
pour
|
||||
dumper un adhérent du cimetière et y'aura plus qu'à faire un coup de
|
||||
shelldap. (gruik)
|
||||
|
||||
* Il ne faudrait plus supprimer des entrées de la base de donnée que
|
||||
avec {{{lc_ldap}}}. {{{chambre_vide.py}}} ou l'intranet2 pour les machines
|
||||
et {{{gest_crans_lc}}} pour les adhérents par
|
||||
exemple. {{{ressucite_lc}}} bien que basique fonctionne a
|
||||
priori -- ValentinSamir <<DateTime(2014-04-11T01:35:09+0200)>>
|
||||
|
|
@ -0,0 +1,167 @@
|
|||
# Internounous
|
||||
|
||||
* Date : Jeudi 8 mai 2014
|
||||
* Lieu : Salle de conférence du Pavillon de Jardins
|
||||
* Début : 19h13
|
||||
* Fin : 21h14
|
||||
|
||||
## Présents
|
||||
|
||||
* Adam Heriban
|
||||
* Daniel Stan
|
||||
* Pauline Pommeret
|
||||
* Pierre-Elliott Bécue
|
||||
* Vincent Le Gallic (arrivée à 19h33)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Nouveau RTC
|
||||
|
||||
En l'absence de Valentin Samir qui semble devoir faire face à d'autres
|
||||
obligations, Daniel Stan s'est porté volontaire
|
||||
pour assurer le rôle de RTC. Son initiative a été approuvée par le CT, et c'est
|
||||
désormais officiel. Félicitations Daniel !
|
||||
|
||||
La question de la récupération des clefs de Valentin (clef 0B et coffre en
|
||||
particulier) se pose. Daniel va essayer de le
|
||||
contacter par divers moyens afin d'en discuter avec lui.
|
||||
|
||||
### CransClefs
|
||||
|
||||
Il faut vraiment que les MA mettent à jour VieCrans/CransClefs, elle n'est
|
||||
manifestement pas à jour, et cela devient problématique.
|
||||
Il faut rappeler au trésorier actuel que c'est de son ressort et qu'il doit
|
||||
veiller à ce que les détenteurs des clefs soient
|
||||
identifiés, quitte à ce que des cautions soient encaissées.
|
||||
|
||||
Il est demandé à Vincent Guiraud de vérifier la présence de clefs 2B dans le
|
||||
coffre. La réponse est non (il n'y a pas de clefs).
|
||||
|
||||
Il faudra penser, pour les années à venir, à dire aux personnes partant en
|
||||
stage de le dire sur la page VieCrans/CransVacances
|
||||
et à rendre leurs clefs avant de partir.
|
||||
|
||||
Une clef du disjoncteur du 0M nous a été confiée par le CROUS et est
|
||||
actuellement au 2B, faute d'avoir
|
||||
pu fournir une clef 0B à Jordan Delorme. Cela commence sérieusement à être
|
||||
problématique. Il faut demander au CA
|
||||
de voter un budget pour réaliser la copie de 2 jeux de clefs 0B.
|
||||
|
||||
### Blocage du /64 wifi sur Wikipedia
|
||||
|
||||
On a découvert le 4 mai qu'un ou des adhérents auraient poussé des admins de
|
||||
Wikipédia à bloquer le /64 wifi de manière à ce que
|
||||
les adhérents du Crans ne puissent ni créer de compte ni éditer de page.
|
||||
|
||||
L'administrateur de wikipedia ne souhaite pas lever le blocage tant qu'il n'est
|
||||
pas en mesure de différencier 2 utilisateurs venant
|
||||
de chez nous, et par là même de bloquer uniquement celui qu'il considère comme
|
||||
vandale. En effet, le fonctionnement de l'IPv6
|
||||
au crans laisse le choix à la machine d'un suffixe aléatoire (extension de vie
|
||||
privée) dans le même /64. Nous sommes donc les seuls
|
||||
à connaître la correspondance entre une IPv6 et une machine du réseau (pour
|
||||
comptage d'upload), et ceci de manière volontaire
|
||||
(il s'agit d'un des buts du système d'extension de vie privée).
|
||||
|
||||
Que faire ?
|
||||
D'un côté, on peut se soucier des conséquences pour les autres adhérents :
|
||||
|
||||
* Ne rien faire
|
||||
* Bloquer la plage IPv6 de Wikipedia pour forcer l'IPv4 (comme pour google), la
|
||||
plage IPv4 n'est pas bloquée et ne risque pas de l'être (chaque adhérent
|
||||
étant clairement identifiable)
|
||||
* Implémenter un routage plus fin de l'IPv6
|
||||
|
||||
La deuxième solution pose des problèmes d'altération du réseau. En l'état
|
||||
actuel, nous n'avons pas de raison valable pour
|
||||
suivre la démarche de Wikipedia dans la violation de la neutralité du réseau.
|
||||
De plus, le blocage actuel est peu sévère et les
|
||||
rares adhérents impactés ont des alternatives pour l'accès à Wikipedia, comme
|
||||
la désactivation de l'IPv6 (envoyer un mail ? message
|
||||
sur autostatus ?)
|
||||
|
||||
La dernière solution (se référer à [[CransTechnique/PlanAdressage#IPv6]]) est
|
||||
de toute façon un projet de longue date sur lequel il faut
|
||||
se pencher. L'idée est d'allouer à chaque machine un /64 distinct. Il faut
|
||||
regarder de la doc du côté de DHCPv6 et de délégation
|
||||
et implémenter cela en parallèle de la solution actuelle.
|
||||
|
||||
Du côté de l'adhérent accusé pour wikipedia, nous n'avons pas constaté d'abus
|
||||
ni de nuisance sur le réseau que nous pouvons lui imputer.
|
||||
|
||||
On décide de ne rien faire pour le moment et d'analyser la solution d'adressage
|
||||
v6. On avisera en temps utile. Le CA tient à en
|
||||
discuter lors de sa prochaine réunion pour l'aspect administratif de ce
|
||||
problème. Une tentative de contact a été prise par le CA,
|
||||
et s'est pour l'instant avérée infructueuse.
|
||||
|
||||
### Comptage upload et avertissements
|
||||
|
||||
Le CA souhaiterait que les mails d'avertissement pour upload à 300Mo soient
|
||||
moins agressifs et plus pédagogues.
|
||||
De plus 300Mo semble une limite très facilement atteignable de nos jours avec
|
||||
les technologies actuellement
|
||||
présentes sur Internet.
|
||||
|
||||
Pierre-Elliott souhaite conserver cette limite basse afin de laisser aux
|
||||
adhérents le temps de réagir lors de la réception
|
||||
d'une alerte. Une limite plus haute, en cas d'upload rapide, ne permettrait pas
|
||||
d'avertir l'adhérent d'un comportement
|
||||
anormal de sa machine avant qu'il ne soit effectivement déconnecté.
|
||||
|
||||
Cependant, plusieurs adhérents ont exprimé leur volonté de ne plus recevoir ce
|
||||
mail d'alerte.
|
||||
|
||||
Raphaël Bonaque (irc) est volontaire pour rajouter un champs sur
|
||||
l'intranet (lié à ldap ? pg ?) pour choisir à partir de quel seuil
|
||||
un adhérent souhaite recevoir son mail d'avertissement pour upload. Cela
|
||||
demande peu de modifications dans notre système
|
||||
de comptage d'upload et permettrait aux adhérents ne plus recevoir ce mail ou
|
||||
de configurer à quel moment ils souhaitent
|
||||
le recevoir.
|
||||
|
||||
### Impression
|
||||
|
||||
Le devis d'Open concernant leur imprimante Xerox nous a permis de soulever un
|
||||
problème important : l'imprimante a sa sortie sur
|
||||
la droite, tandis que la notre sort à gauche. Ça demanderait donc un
|
||||
réaménagement du 4J, à voir avec des mesures et
|
||||
éventuellement donner une date à Open pour qu'ils passent voir le local.
|
||||
|
||||
Pas de trace de compatibilité Linux sur la Ricoh proposée par AMP.
|
||||
|
||||
### DSI-Crans
|
||||
|
||||
Pierre-Elliott a créé une ML d'alerte utilisable par la DSI afin d'éviter de
|
||||
spammer tous ses membres à la moindre alerte nous concernant
|
||||
sur dsi-crans. root@ est abonné directement.
|
||||
|
||||
Préparation d'une future réunion ? Potentiellement à l'OdJ
|
||||
|
||||
* Autorisation d'un deuxième routeur crans dans la zone zrt (nouveau komaz)
|
||||
* Demande d'un petit /24 pour des tests nat64 ?
|
||||
* Tout ce que vous estimerez pertinent (demander au CA, notamment pour Saclay)
|
||||
|
||||
### Projets en cours
|
||||
|
||||
Pierre-Elliott a fait un peu de ménage dans le tracker, il y a des projets pour
|
||||
les apprentis, avis aux personnes motivées !
|
||||
|
||||
Pauline souhaite que les tâches réalisables par un apprenti (en
|
||||
autonomie) soient davantage mises en valeurs.
|
||||
|
||||
Il faut faire quelque chose de toutes ces tâches (renouvellement des
|
||||
certificats, KSK, etc) qui produisent beaucoup de bruit.
|
||||
Pour les certificats, on a ce qu'il faut automatiquement avec check_cert,
|
||||
Pierre-Elliott va essayer de faire un programme du même genre
|
||||
pour DNSSEC.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Binding Ldap
|
||||
|
||||
Pierre-Elliott s'est lancé dans la réécriture de certains scripts de gestion
|
||||
s'appuyant sur ldap_crans pour les porter sur lc_ldap. Il
|
||||
a également commencé une implémentation de generate basée sur rabbitmq.
|
||||
Pour l'instant, il s'est penché sur dhcp, ça marche, il faut continuer. Il
|
||||
attend des reviews.
|
||||
|
|
@ -0,0 +1,93 @@
|
|||
# Réunion inter-nounous
|
||||
|
||||
* Date : Jeudi 22 mai 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 20h41
|
||||
|
||||
## Présents
|
||||
|
||||
* Jordan Delorme
|
||||
* Lucas Serrano
|
||||
* Daniel Stan
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Imprimante
|
||||
|
||||
On choisit la Xerox, au vu de la compatibilité douteuse de la Ricoh. Un
|
||||
réaménagement du 4J s'avère nécessaire, mais peu compliqué à gérer : on
|
||||
s'oriente vers
|
||||
un agrandissement de la sortie ou un changement (sur l'autre côté du mur), dans
|
||||
les deux cas en rebouchant l'ancien.
|
||||
|
||||
On pense faire une expédition, après accord CA, dans un magasin de construction
|
||||
pour acheter des plaques de plâtres et des parpaings (pour l'onduleur).
|
||||
|
||||
Le binding de la nouvelle imprimante (CUPS+lp) est déjà (presque) prêt, on se
|
||||
servirai de celui de l'ancienne imprimante, en adaptant les options proprio
|
||||
d'agrafage et cie.
|
||||
|
||||
### QRCode (Gala)
|
||||
|
||||
Pierre-Elliott a discuté avec l'équipe gala, pour se mettre d'accord sur les
|
||||
deadlines et les besoins du gala.
|
||||
Actuellement le prestataire privé coûte environ 1200€, pour la mise en place du
|
||||
site et la taxe sur les billets.
|
||||
|
||||
Le Cr@ns aimerait leur fournir ce service à la place. L'idée serait d'acheter
|
||||
les scanettes de QRCode et de voir
|
||||
avec leur banque pour la mise en place du service de paiement en ligne.
|
||||
|
||||
Pierre-Elliott est motivé pour s'occuper de ce projet en collaboration avec le
|
||||
Gala. Daniel l'aidera.
|
||||
|
||||
Cahier des charges :
|
||||
|
||||
* Site en django de gestion de QRCodes ;
|
||||
* Formulaire pour acheter un/des billets avec paiement en ligne et
|
||||
validation de transaction ;
|
||||
* Envoi de mail en cas de succès avec lien pour récupérer le billet ;
|
||||
* Lien générant des pdf et les stockant (pour téléchargement futur) ;
|
||||
* Administration : validation manuelle de ticket en cas d'échec après renvoi
|
||||
post-paiement ; interface de suppression de ticket nominatif ; édition et
|
||||
suppression de ticket pour souche en masse ;
|
||||
* Appli python qui après scan de code barre/QRCode renvoie sur le site avec une
|
||||
bonne url pour valider le billet (id + hash)
|
||||
|
||||
### Avancement du WiFi
|
||||
|
||||
Le Pavillon des Jardins est presque entièrement câblé. Il reste le 4^ème^ étage.
|
||||
|
||||
NB (post CR) : le dernier étage a été câblé deux jours plus tard.
|
||||
|
||||
### Rabbit MQ
|
||||
|
||||
Le principe choisi est le suivant : le(s) binding(s) notifient le serveur
|
||||
RabbitMQ d'une modification ldap avec une "modlist" (ou assimilé) en argument.
|
||||
Un script démon sur RabbitMQ lit cette file d'attente et dispatche (en fonction
|
||||
du modlist) la modification aux files d'attente des services concernés.
|
||||
|
||||
### Binding Ldap pour les adhésions glissantes
|
||||
|
||||
Ça marche, mais ça s'intègre mal à gest_crans … On travaille encore dessus pour
|
||||
arriver à selectionner des adhérents à jour de cotisation à partir
|
||||
de ses factures.
|
||||
|
||||
## Bilan todolist
|
||||
|
||||
Pour résumer les trucs à faire prochainement :
|
||||
|
||||
Pas prioritaire :
|
||||
|
||||
* Adhésions glissantes (fin juillet, début août)
|
||||
* Messaging via Rabbit MQ (pas tout de suite)
|
||||
* câbleuse (dépendant de RabbitMQ)
|
||||
|
||||
Urgents :
|
||||
|
||||
* lc_ldap : locks sur un objet (actuellement, locks uniquement sur une valeur
|
||||
donnée d'un type donné)
|
||||
* Imprimante
|
||||
* Site du Gala
|
||||
|
|
@ -0,0 +1,90 @@
|
|||
# Réunion inter-nounous
|
||||
|
||||
* Date : Jeudi 5 juin 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h30
|
||||
* Fin : 20h38
|
||||
|
||||
## Présents
|
||||
|
||||
* Adam Heriban
|
||||
* Daniel Stan
|
||||
* Florian Marconi
|
||||
* Jean-Baptiste Guyon
|
||||
* Jordan Delorme (arrivé à 19h45)
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Imprimante
|
||||
|
||||
On s'oriente sur le week-end du 5-6 juillet pour installer la nouvelle
|
||||
imprimante et faire les travaux. Daniel présente une nouvelle
|
||||
organisation possible du 4J et les éléments à acheter. Pour le problème de la
|
||||
fixation de l'imprimante (pour éviter de pouvoir
|
||||
rentrer dans la pièce en la poussant), on pense utiliser une barre en metal au
|
||||
niveau du sol.
|
||||
|
||||
On demande à la menuiz' si ils disposent d'une disqueuse adaptée, sinon, on
|
||||
s'oriente vers la location. Ils sont d'accord,
|
||||
et sont même prêts à nous aider, en revanche on devra acheter un disque à
|
||||
plâtre.
|
||||
|
||||
### Réseau au point rencontre
|
||||
|
||||
Le BDE voudrait du filaire au point rencontre. De préférence, ils voudraient le
|
||||
vlan adhérent, afin de disposer aussi
|
||||
des services TV. Pour l'instant, la demande de travaux a été effectuée pour le
|
||||
vlan 10, on avisera pour leur
|
||||
fournir les services supplémentaires quand il sera effectivement brassé.
|
||||
|
||||
### CNS Conseil
|
||||
|
||||
Deux représentants de CNS Conseil aimeraient bien savoir si le collège
|
||||
technique est d'accord pour ouvrir partiellement le réseau wifi pour le
|
||||
CRA (congrès régional d'automne).
|
||||
A priori 200~300 personnes. Ils souhaitent le soutien du Crans pour fournir un
|
||||
réseau WiFi.
|
||||
Date : novembre.
|
||||
|
||||
Amphi utilisés :
|
||||
|
||||
* Tocqueville
|
||||
* Curie
|
||||
* Fonteneau
|
||||
* Condorcet
|
||||
* Villon
|
||||
|
||||
Au niveau matériel, nous avons suffisamment de bornes supplémentaires. En
|
||||
revanche, elles ne sont pas installées dans le d'Alembert.
|
||||
C'est l'occasion d'en remettre, car les bornes du d'Alembert n'ont pas été
|
||||
changées (anciens modèles).
|
||||
De plus, on commence à avoir des demandes d'élèves du dpt EEA.
|
||||
|
||||
Il faut cependant l'accord de la DSI pour diffuser le réseau, donc il faudra
|
||||
préciser dans le dossier de CNS Conseil que la couverture WiFi sera réalisée
|
||||
avec l'accord de la DSI.
|
||||
|
||||
### QRCode (Gala)
|
||||
|
||||
Il faut faire le site. Deadline : 15 juillet. Histoire que le staff Gala puisse
|
||||
le tester avant les vacances.
|
||||
|
||||
### Séminaires 14-15
|
||||
|
||||
Remarques sur les séminaires de l'an passé : peu de motivation à l'organisation
|
||||
des séminaires. Il faut que les nounous motivent davantage leurs apprentis. On
|
||||
met à jour en live la liste des apprentis avec leur encadrants. Avis aux
|
||||
nounous qui se sont vues affectées des apprentis !
|
||||
|
||||
Il faut que les gens qui n'ont pas encore uploadé leur slides pensent à le
|
||||
faire ASAP.
|
||||
Il faudrait que les nounous fassent/fignolent leurs séminaires
|
||||
classés "nounou", qu'elles puissent ainsi à partir de la rentrée se concentrer
|
||||
sur l'encadrement de
|
||||
séminaires apprentis.
|
||||
|
||||
Pauline n'est pas là, mais voici un début de programme de séminaires pour
|
||||
l'année prochaine :
|
||||
[La liste des séminaires (faits ou à
|
||||
faire)](CransTechnique/CransApprentis/SeminairesTechniques/2013-2014#Contenu_des_s.2BAOk-minaires)
|
||||
|
|
@ -0,0 +1,118 @@
|
|||
# Réunion inter-nounous
|
||||
|
||||
* Date : Jeudi 19 juin 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h52
|
||||
* Fin : 21h10
|
||||
|
||||
## Présents
|
||||
|
||||
* Adam Heriban
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont (arrivé à 20h10)
|
||||
* Pierre-Elliott Bécue (arrivé à 20h20)
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Internet pour admissibles
|
||||
|
||||
Pour le PR, le vlan n'est toujours pas présent sur la prise. On va mettre un
|
||||
switch dlink à disposition du BDE. La DSI a dit s'occuper du vlan demain matin,
|
||||
sinon on leur fournira un NAT via une machine sur le vlan3 (qui lui est
|
||||
présent).
|
||||
|
||||
Il faudra qu'on discute de ça à la réunion DSI, qu'on ait un fonctionnement
|
||||
plus efficace à l'avenir.
|
||||
|
||||
On se propose d'enregistrer des machines WiFi temporaires pour les admissibles,
|
||||
à l'aide de la fonctionnalité de MAC `<automatique>` qui remplit automatiquement
|
||||
la MAC d'une machine à la première connexion avec le
|
||||
bon '''login'''/mdp. À voir sur quel compte on enregistre ça.
|
||||
On propose le compte du BDE (il faudrait leur en parler (en cas de déco, c'est
|
||||
le BDE qui prend)) ou un compte dédié pour ça.
|
||||
|
||||
Daniel a commencé un script pour inscrire à la volée N machines (avec N grand),
|
||||
on imprimerait alors plein de logins/mdp pour les filer aux admissibles.
|
||||
Toutes les semaines, on supprime les machines et on recommence.
|
||||
|
||||
### Comptage d'upload
|
||||
|
||||
PEB a commencé à configurer pmacct sur le nouveau routeur, en stockant dans une
|
||||
base
|
||||
pgsql locale.
|
||||
|
||||
* Le schéma est un peu modifié, donc les scripts de déco/stats/analyse doivent
|
||||
être réécrits.
|
||||
* On loggue tout ce qui passe sur l'interface crans.
|
||||
* On a les MACs '''et''' les IPs.
|
||||
* On compte pour la déconnexion pour upload le traffic qui sort du /16 de
|
||||
l'ENS.
|
||||
* Comme on a l'info mac '''et''' IP, on peut émuler le filtrage mac-ip.
|
||||
* Comme on a l'info mac, plus besoin de correspondance EUI64<->Extension de vie
|
||||
privée en IPv6.
|
||||
|
||||
On va probablement mettre deux trois filtres pcap pour alléger la base du
|
||||
traffic interne
|
||||
(wifi <->filaire, ça passe par komaz).
|
||||
|
||||
Problème : les cas "bâtards" de machines ayant plusieurs entrées dans la base
|
||||
ldap
|
||||
avec la même adresse MAC.
|
||||
|
||||
On envisage d'utiliser ce système pour conserver l'historique du parefeu,
|
||||
plutôt que d'utiliser
|
||||
le target LOG d'iptables. Cela diminuerait la taille occupée par les logs du
|
||||
parefeu, car on
|
||||
aurait des infos agrégées sur 1 min.
|
||||
|
||||
### Logs centralisés
|
||||
|
||||
Quand l'étape précédente sera terminée, on aura un peu plus de place sur thot.
|
||||
PEB envisage
|
||||
d'installer une base elasticsearch avec logstash pour stocker les logs
|
||||
centralisés.
|
||||
|
||||
On ne sait pas encore combien de place ça va prendre. ''A priori'', plus de
|
||||
place (x2) que des logs
|
||||
textes.
|
||||
|
||||
### Màj du Firewall
|
||||
|
||||
Un peu plus de paramètres dans config.py et une fonction pour mettre à jour le
|
||||
test
|
||||
mac-ip incrémentalement.
|
||||
|
||||
Il faudrait recoder un parefeu IPv6, pour régler ces problèmes de màj, et
|
||||
éventuellement en
|
||||
profiter pour en faire un parefeu IPv4-v6 unique.
|
||||
|
||||
### Civet de lapin
|
||||
|
||||
Sur toutes les machines, un démon : trigger.py qui importe (depuis config) les
|
||||
services gérés
|
||||
par la machine courante.
|
||||
|
||||
Scénario typique :
|
||||
|
||||
* Quand le binding ldap modifie un objet, il envoie un message avec une clé de
|
||||
routage « trigger.event » et en donnée le dn, les ldiff avant et après
|
||||
modification.
|
||||
* Civet reçoit le message, il compare les deux ldiff et dispatche sur un
|
||||
échangeur dédié à un service donné (clé de routage spécifique).
|
||||
|
||||
Si plusieurs serveurs implantent le même service, ils possèdent chacun leur
|
||||
file d'attente
|
||||
qui s'associe à l'échangeur.
|
||||
|
||||
### Réunion DSI
|
||||
|
||||
Vendredi 27 juin à 16h.
|
||||
|
||||
### Babar
|
||||
|
||||
Il atteint ses limites. PE regarde pour augmenter l'espacement des sauvegardes
|
||||
des
|
||||
serveurs ayant des services similaires. On se renseigne en parallèle des
|
||||
solutions
|
||||
alternatives (NAS, solution proprio… ?).
|
||||
|
|
@ -0,0 +1,210 @@
|
|||
# Réunion inter-nounous
|
||||
|
||||
* Date : Jeudi 3 juillet 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 18h47
|
||||
* Fin : 20h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Anne Cazalet
|
||||
* Daniel Stan
|
||||
* Nicolas Dandrimont
|
||||
* Olivier Iffrig
|
||||
* Stéphane Glondu
|
||||
* Vincent Le Gallic
|
||||
* Pierre-Elliott Bécue
|
||||
* Pauline Pommeret
|
||||
* Kévin Moisy-Mabille
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Comptage d'upload
|
||||
|
||||
Pierre-Elliott a refondu le comptage de l'upload à base de pmacct.
|
||||
C'est maintenant envoyé au nouveau routeur{{{odlyd^Wkomaz2}}} (pas encore en
|
||||
prod au niveau routage).
|
||||
|
||||
Niveau consommation de ressources, le load average est passé de 2 à 0.5.
|
||||
Maintenant qu'on a atteint
|
||||
la durée de rotate (5 jours), la base fait 90Go.
|
||||
|
||||
* {{{deconnexion.py}}} (= punir les méchants) a été adapté, il s'exécute ~aussi
|
||||
rapidement
|
||||
* {{{analyse.py}}} (= voir combien les méchants ont uploadé et vers où) a été
|
||||
recodé, on peut
|
||||
|
||||
maintenant demander l'upload par '''adhérent'''.
|
||||
|
||||
{{{#!wiki tip
|
||||
analyse.py est lancé automatiquement à chaque fois que quelqu'un se fait
|
||||
déconnecter. Les résultats atterrisent
|
||||
dans `/usr/scripts/var/analyse/AAAA_MM_JJ_HH_MM_SS_(aid|cid)_<aid ou cid>.txt`
|
||||
}}}
|
||||
|
||||
### Réunion avec la DSI
|
||||
|
||||
Lundi dernier, Pierre-Elliott, Jordan et Daniel ont rencontré la DSI en les
|
||||
personnes de Stuart !McLellan,
|
||||
Jocelyn Viallon et Vivien Frenot.
|
||||
|
||||
#### Saclay
|
||||
|
||||
On leur a parlé de là où on en est pour le fameux "dossier Saclay", qui est en
|
||||
cours de rédaction, de ce qu'on est prêt à faire.
|
||||
|
||||
Nous, on préfèrerais continuer à collaborer avec eux, sachant qu'on est prêt à
|
||||
faire autrement si besoin.
|
||||
Ils sont aussi d'avis de continuer à travailler main dans la main, parce qu'ils
|
||||
pensent que l'école se doit de
|
||||
fournir l'accès Internet à ses étudiants, mais préfèrent que ce ne soit pas à
|
||||
eux de s'en occuper.
|
||||
Stuart pense qu'on est plus efficace et qu'on coûte moins cher qu'un
|
||||
prestataire privé.
|
||||
|
||||
De notre côté, on aimerait que l'école supporte notre projet sur la scène de
|
||||
Saclay.
|
||||
Il '''''faut''''' terminer le dossier, qu'il soit tout beau tout propre et
|
||||
pensé en collaboration avec les autres
|
||||
assos (notamment Aurore). Pierre-Elliott et Ariane ont bien avancé, mais il y a
|
||||
encore beaucoup de travail.
|
||||
|
||||
Anne Cazalet est prête à nous faire un/des devis pour une grosse quantité de
|
||||
matériel,
|
||||
pour qu'on puisse dire dans le dossier "regardez, on sait combien ça nous
|
||||
coûtera".
|
||||
On la recontactera dès qu'on aura une idée des quantités (une fois qu'on aura
|
||||
fait notre inventaire).
|
||||
|
||||
Stuart a parlé de nous au directeur de la DSI de la FCS (Fédération de
|
||||
Coopération Scientifique)
|
||||
François de Castelbajac, destiné à piloter les projets des DSI des différentes
|
||||
écoles/labo du projet Saclay.
|
||||
|
||||
Dossier à envoyer d'ici la fin du week-end.
|
||||
|
||||
#### Comptage d'upload et débit en journée
|
||||
|
||||
Un point a été fait sur les limitations.
|
||||
|
||||
Pour le débit en journée, ils ont peur de plomber les visoconférences dont les
|
||||
départements ont besoin.
|
||||
On utilise actuellement 100Mbit/s sur le 1Gb/s que l'école a.
|
||||
|
||||
En journée, on a négocié 150Mbit/s, pour voir ce que ça donne.
|
||||
En soirée, on reste à 500 (ça ne sature pas).
|
||||
|
||||
Pour la limitation d'upload, ce qui les gêne surtout, c'est l'image de l'école
|
||||
vis à vis des téléchargement illicites,
|
||||
surtout quand les mails viennent du CERT de Renater.
|
||||
Ils sont contents parce qu'ils reçoivent moins de mails d'ayant droits, Nicolas
|
||||
pense que Renater
|
||||
les {{{> /dev/null}}}.
|
||||
|
||||
Du coup, on passe la limite d'upload à 8Gio/24h, histoire que ce soit quand
|
||||
même pas complètement open,
|
||||
notamment à cause des gens qui uploadent sans trop le savoir (virus, cacaoweb
|
||||
for the win).
|
||||
Point de vue implémentation, y'a rien à faire de plus, Pierre-Elliott l'a déjà
|
||||
modifié dans le pare-feu.
|
||||
|
||||
La DSI est intéressée par nos solutions de qos (tc sous linux) pour
|
||||
leurs "problèmes" de visioconf.
|
||||
|
||||
#### Miroir Debian / IPv6
|
||||
|
||||
L'ENS est toujours intéressée par l'idée d'un miroir Debian commun.
|
||||
|
||||
En revanche, l'IPv6 est quasiment obligatoire pour apparaître dans cette liste.
|
||||
Pour l'instant, ça coince au niveau
|
||||
du matériel du réseau de collecte (Rubis). De notre côté, on propose d'acheter
|
||||
une machine plus
|
||||
puissante et/ou laisser tomber le RAID 5 logiciel actuellement en place.
|
||||
|
||||
#### Ports
|
||||
|
||||
Sur le firewall, on bloque par défaut les ports des machines des adhérents en
|
||||
entrée.
|
||||
La DSI ne le savait pas, mais trouve que c'est une bonne idée (on protège des
|
||||
adhérents qui ont l'habitude d'avoir une box entre eux et le monde).
|
||||
|
||||
Ils ne voient aucun inconvénient à ce qu'on ouvre des ports quand ça nous
|
||||
chante, même sans les prévenir, mais ils apprécient beaucoup qu'on les
|
||||
prévienne.
|
||||
Donc on va continuer à le faire, parce que ça nous coûte pas grand chose, que
|
||||
c'est toujours cool de faire plaisir à la DSI pour pas cher, et que ça
|
||||
responsabilise un peu l'ouverture d'un port.
|
||||
|
||||
### Filtrage mails
|
||||
|
||||
C'est un projet à plus long terme pour le filtrage des spams. On réinstallerait
|
||||
amavis sur tous les MX
|
||||
sans utiliser les fonctions de filtrage virus. On activerait le filtrage de
|
||||
spam assassin. L'idée serait
|
||||
ensuite d'utiliser les fonctions de quarantaine pour n'envoyer qu'un seul mail
|
||||
par jours pour tous
|
||||
les mails étiquettés "spam" en attente de modération.
|
||||
|
||||
Voir du côté de Maia Mailguard. Avis à apprenti intéressé, contacter PEB.
|
||||
|
||||
### Disque de nols
|
||||
|
||||
Un disque de nols (notre baie de disques) de 600Go nous a lâché.
|
||||
Il y avait deux disques de remplacement qui attendaient de prendre sa place,
|
||||
donc pour l'instant, pas d'interruption de service.
|
||||
|
||||
Anne nous a envoyé un numéro de téléphone à contacter pour faire valoir la
|
||||
garantie.
|
||||
|
||||
Il nous manque certains numéros de
|
||||
série (cf [[CatégorieCrans/LesServeurs|ci]]), on va voir avec Anne pour les
|
||||
récupérer.
|
||||
Il est possible qu'on ait besoin des numéros de séries des '''contrôleurs'''.
|
||||
|
||||
### Migration des homes
|
||||
|
||||
En été, c'est là que les adhérents se servent le moins de leurs home. Les
|
||||
migrer nécessite une interruption de service.
|
||||
|
||||
Plus de place, plus
|
||||
compartimenté ([[CransTechnique/PanthéonServeurs/ServeurBabar|babar]] nous
|
||||
remercie),
|
||||
ce sera cool, mais la copie de tout ça va prendre plusieurs heures.
|
||||
|
||||
Il va falloir qu'on fasse des choses sioux parce
|
||||
que {{{/home/a/ablabla}}} risque d'être le nouveau chemin
|
||||
pour {{{/home/ablabla}}}.
|
||||
|
||||
Pas encore de date fixée, mais avant la rentrée.
|
||||
|
||||
### Machines virtuelles pour les clubs/l'événementiel
|
||||
|
||||
On a des demandes (pot vieux, Gala) pour une machine virtuelle. On peut déjà
|
||||
allouer de la place sur l'ancien
|
||||
stockage.
|
||||
|
||||
Si ce crash-test se passe bien, on considérera toute demande de virtualisation
|
||||
de la part d'autres clubs.
|
||||
Penser à rappeler que :
|
||||
|
||||
* on se garde le droit de refuser une vm pour cause d'utilisation de ressources
|
||||
ou d'usage illicite
|
||||
* les nounous restent virtuellement root sur la machine hébergée, l'accès sans
|
||||
accord leur restant moralement et légalement interdit
|
||||
|
||||
Il faut avancer le projet Gala (mi-juillet).
|
||||
|
||||
### Imprimante
|
||||
|
||||
Discussion avec Anne sur ce que proposerait HP en termes de contrats de
|
||||
maintenance, et de
|
||||
« l'engagement » de XeroX.
|
||||
|
||||
Laser Jet Enterprise Flow M800 series
|
||||
|
||||
Extensions de garantie:
|
||||
|
||||
* 4h
|
||||
* Le lendemain
|
||||
|
||||
## Il est 20h. Paris s'éveille (or something). Sergio nous attend il fait faim.
|
||||
|
|
@ -0,0 +1,172 @@
|
|||
# Réunion du collège technique
|
||||
|
||||
* Date : Jeudi 11 septembre
|
||||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||||
* Début : 19h00
|
||||
* Fin : 21h01
|
||||
|
||||
## Présents
|
||||
|
||||
* Clément Ringeade
|
||||
* Daniel Stan
|
||||
* Jordan Delorme
|
||||
* William Babonnaud
|
||||
* Myriam Begel
|
||||
* Glen Mével
|
||||
* Adam Heriban
|
||||
* Colisson Léo (alias !TobiasBora)
|
||||
* Pierre-Elliott Bécue
|
||||
* Raphaël-David Lasseri
|
||||
* Germain Haessig
|
||||
* Florian Marconi
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Migration routeur et homes
|
||||
|
||||
On a migré le routeur et les homes vers une nouvelle grappe de disques (des
|
||||
disques de 2To au lieu des 600Go). On a ensuite permuté les disques pour mettre
|
||||
les 2To dans la baie encore garantie ({{{nols}}}). Malheureusement, cela a
|
||||
entraîné une perte de données (problèmes de disques ayant le même identifiant,
|
||||
probablement), et les disques arrivants ont été squeezés. Il a fallu
|
||||
recommencer la copie de données, mais rien n'a été perdu.
|
||||
|
||||
Il faut tester le système de secours (quand le réseau du crans tombe, il faut
|
||||
faire en sorte que le serveur titanic ouvre son tunnel vpn vers ovh pour
|
||||
assurer une connectivité entre le serveur et le réseau du Crans). Glen est
|
||||
volontaire pour jouer avec le vpn (encadré par Daniel.)
|
||||
|
||||
Quota : à refaire. Pour l'instant, tout le monde peut utiliser autant d'espace
|
||||
qu'il le veut. Il devrait être limité à 10Go. Léo Colisson se propose pour le
|
||||
faire.
|
||||
|
||||
### Nouvelle imprimante
|
||||
|
||||
Elle est au 4J et elle marche !
|
||||
Toutefois les impressions WEI l'ont laissé exsangue, presque à court de toner
|
||||
et de tambour. Le contrat SPS a été signé mercredi. Pas de nouvelle pour
|
||||
l'instant.
|
||||
On espère recevoir un toner pour mardi.
|
||||
|
||||
Pour l'instant, le binding avec l'intranet n'est pas prêt (mais presque). Le
|
||||
soucis, c'est que pour l'instant, il semble falloir installer le driver sur le
|
||||
serveur qui
|
||||
lance l'impression (même en partage d'imprimante cups). Soit on essaie de
|
||||
trouver un paquet hplip venant de Jessie, soit on installe la lib à la main sur
|
||||
o2 (serveur de l'intranet2) ce qui nécessite de finir l'application
|
||||
d'impression sur l'intranet2. On verra ça ce week-end.
|
||||
|
||||
Pour l'instant, on ne comprend pas le snmp de cette imprimante. Vincent G. a
|
||||
commencé à parser la page d'administration pour récupérer les infos
|
||||
pertinentes. On écrira un plugin munin à partir de ça.
|
||||
|
||||
Il faut également réécrire le script de notification de fin d'impression.
|
||||
William est volontaire.
|
||||
|
||||
Il nous manque une fonctionnalité de couverture (piochée depuis un autre
|
||||
bac) pour la Sauce. Le seul driver supportant cette fonction (à notre
|
||||
connaissance) est dispo
|
||||
sur Windows® (sic), et en recto simple. On peut soit créer une VM sous
|
||||
Windows®, soit on leur file une vieille machine sous Windows®…
|
||||
|
||||
### Serveur de backup
|
||||
|
||||
Anne propose un devis <http://perso.crans.org/dstan/anne> de 4020 € TTC, Pierre
|
||||
Elliott regarde pour un serveur acheté ailleurs en sachant que l'avantage
|
||||
principal d'HP serait le care pack garantissant l'intervention ou le
|
||||
remplacement dans les 24h.
|
||||
Il faudra demander au CA de voter un budget pour un "simple" ordi à monter si
|
||||
ça ne suffit pas on avisera pour une solution pro.
|
||||
|
||||
### Ft's powerup
|
||||
|
||||
Devis de ~1100 pour un deuxième Xeon 6cœur + 8Go de RAM. A priori, on les
|
||||
prendra.
|
||||
|
||||
### OwnCloud
|
||||
|
||||
Raphaël fait une démo à partir de la machine virtuelle qu'il vient d'installer.
|
||||
|
||||
Où stocker les données d'un utilisateur :
|
||||
|
||||
* Un espace à part (sur la vm)
|
||||
* Le home de l'adhérent
|
||||
* Un sous-dossier du home de l'adhérent
|
||||
|
||||
Vu les contraintes (dossier qui doit être accessible en écriture par un groupe
|
||||
spécifique), on s'oriente vers le partage d'un sous-dossier de l'espace perso
|
||||
d'un adhérent.
|
||||
|
||||
-- Il y a un petit hack qui consiste à monter le home de l'adhérent en tant
|
||||
que "Stockage externe" dans owncloud pour s'affranchir des problèmes de
|
||||
droit (www-data qui ne peut pas écrire en tant que l'adhérent), c'est de la
|
||||
théorie, je ne sais pas si ça marche en pratique
|
||||
|
||||
### Sanction upload
|
||||
|
||||
La limitation pour upload ne reconnecte plus automatiquement l'adhérent
|
||||
après 24h : désormais, il faut cliquer sur un lien qui renvoie vers une
|
||||
application de l'intranet2, pour confirmer que les programmes consommateurs en
|
||||
upload ont été réglés correctement.
|
||||
Tout ceci dans un but de responsabilisation. En cas de clic après les 24h, la
|
||||
personne est reconnectée immédiatement. Pour l'instant, peu de clic et aucune
|
||||
plainte, l'upload des personnes sanctionnées n'a pas l'air de leur manquer.
|
||||
|
||||
L'appli est modulaire et tout le monde est invité à coder d'autres
|
||||
modules (chambres invalides etc.)
|
||||
|
||||
### Bilan (technique) de la rentrée
|
||||
|
||||
Adhésions glissantes : ça s'est bien passé (globalement). Il manque des
|
||||
fonctions pour afficher les factures en détail.
|
||||
Il faut pouvoir enregistrer une réadhésion à partir de la date de fin
|
||||
d'adhésion.
|
||||
|
||||
Enregistrement des mac : ça marche plutôt bien, modulo des problèmes liés à des
|
||||
collisions de mid (sic) vive les locks !
|
||||
|
||||
Ticketteuse : Sur {{{oie}}} à la Kfet, marche bien (modulo présence de
|
||||
rouleau…) elle permet d'imprimer des tickets avec les mots de passes des
|
||||
machines wifi de l'adhérent, mais aussi de générer et imprimer un mot de passe
|
||||
pour le compte crans de l'adhérent.
|
||||
|
||||
* Il faut defucker le script de mails de bienvenue.
|
||||
* Faire un mail-all de réadhésion et imaginer une solution plus pérenne à
|
||||
partir de l'année prochaine.
|
||||
* Générer des liens pour les réponses aux mails de déménagements non déclarés
|
||||
|
||||
### Pont(s) WiFi
|
||||
|
||||
On tire un câble du 0B au 6B pour réalimenter la borne WiFi du faux plafond.
|
||||
Son câble étant utilisé par le pont WiFi.
|
||||
Si cela n'a pas lieu, on rebranchera l'ancienne borne du 6B pour les adhérents
|
||||
du dernier étage (le WiFi a été reporté
|
||||
comme instable à cet étage, la borne étant éteinte).
|
||||
Il faut aussi finaliser la configuration du pont WiFi, avec un truc propre.
|
||||
|
||||
Pour Arpej/Volti, il faut s'occuper de remettre la borne en service en haut du
|
||||
d'Alembert, contacter la DSI et STL (pour l'accès).
|
||||
|
||||
### Install Party Campus
|
||||
|
||||
PEB propose une Install Party (coté campus) le 20 Septembre.
|
||||
|
||||
### Prochains séminaires/ateliers
|
||||
|
||||
Mardi prochain, on fera un séminaire pour les câbleurs. Remplissons le planning
|
||||
des prochains jours
|
||||
<https://wiki.crans.org/CransTechnique/CransApprentis/SeminairesTechniques/2014-2015>
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### SageMath
|
||||
|
||||
C'est une bibliothèque (☺) Python orientée calcul formel. Il faut réfléchir,
|
||||
toutefois c'est assez gourmand en ressources.
|
||||
À tester sur une vm.
|
||||
|
||||
#### Switch Krobot
|
||||
|
||||
Germain demande s'il est possible de récupérer un switch pour le Krobot, le
|
||||
leur fait trop de bruit.
|
||||
Il s'occupe de faire valoir les garanties de ces switchs.
|
||||
|
|
@ -0,0 +1,32 @@
|
|||
# Réunion du collège technique
|
||||
|
||||
* Date : Jeudi 25 septembre
|
||||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||||
* Début : 19h00
|
||||
* Fin :
|
||||
|
||||
## Présents
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Perte de perf sur ft
|
||||
|
||||
### Service d'impression
|
||||
|
||||
## Des rendus qui marchent bof, des blocages idiots
|
||||
|
||||
## pleins de solutions
|
||||
|
||||
### Serveur de backup
|
||||
|
||||
### OwnCloud
|
||||
|
||||
### WiFi
|
||||
|
||||
## On s'est remotivé pour poser des bornes, alors autant continuer !
|
||||
|
||||
### Prochains séminaires/ateliers
|
||||
|
||||
## Quid de mardi prochain ?
|
||||
|
||||
### Questions diverses
|
||||
|
|
@ -0,0 +1,112 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 9 octobre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h15
|
||||
* Fin : 20h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Nicolas Dandrimont
|
||||
* Thomas Blanc
|
||||
* William Babonnaud
|
||||
* Emmanuel Arrighi
|
||||
* Gabriel Detraz
|
||||
* Myriam Begel
|
||||
* Julien Christophe
|
||||
* Raphael Lasseri
|
||||
* Pierre Elliot Bécue
|
||||
* Daniel Stan
|
||||
* Jordan Delorme (arrivée 19h35)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Soirée Crans
|
||||
|
||||
Côté anim, Raphaël David proposait d'utiliser les spare bornes WiFi, surtout en
|
||||
utilisant les leds. Le but
|
||||
serait de coder un petit jeu qui utiliserait les leds. Avis aux volontaires.
|
||||
Il y a aussi un jungle speed fait maison (par Aurore).
|
||||
|
||||
De son côté, le krobot fait une démo : le robot arrive à lancer des balles.
|
||||
|
||||
### Câblage WiFi au M
|
||||
|
||||
Câblage ce samedi aprem', rdv à la fin du petit dej' à la Kfet (vers 14h30).
|
||||
|
||||
### Contact avec les adhérents
|
||||
|
||||
Selon Thomas, nounou@ serait assimilé à une ML privée, ainsi que ca@ (pour le
|
||||
bureau). De notre point de vue,
|
||||
on peut envisager de renommer nounou pour affirmer son caractère public, et
|
||||
rediriger le mail nounou@ vers
|
||||
la ML roots@ (apprentis et nounous seuls sont abonnés).
|
||||
Nicolas soulève l'avantage de l'entraide sur une ML publique.
|
||||
Vu le bruit sur roots@, on laisse en l'état pour le moment, mais on rappelle
|
||||
aux modérateurs de ne pas laisser passer de données privées (rediriger ces
|
||||
mails sur une ML privée.)
|
||||
|
||||
Mails de disconnect :
|
||||
|
||||
* Le nom de la ml : on propose "avertissement" en tant qu'expéditeur des mails
|
||||
auto (alias).
|
||||
* Le contenu du mail : il commence par les sanctions, se répète et se veut
|
||||
agressif.
|
||||
|
||||
Thomas veut bien réécrire cela (et apprendre à utiliser git au passage) et
|
||||
jettera un œil aux autres mails du dossier.
|
||||
|
||||
### Impression
|
||||
|
||||
On met en prod le script de notification d'impression terminée ce soir.
|
||||
|
||||
Ce qui reste à faire :
|
||||
|
||||
* une interface sur l'intranet 2 (Julien est partant pour faire du django)
|
||||
* il faut écrire un driver en pcl (beaucoup de plaintes au sujet de plantages
|
||||
avec le driver hp…).
|
||||
|
||||
### Gala
|
||||
|
||||
Si ça vous intéresse de faire du django, feel free to join.
|
||||
|
||||
### Renouvellement de garanties
|
||||
|
||||
Trois devis de renouvellement (1 an chacun) pour :
|
||||
|
||||
* fz : on prend (c'est un serveur vital)
|
||||
* babar : pas la peine (les disques durs ne sont pas compris dans la garantie)
|
||||
* fy (munin) : on prend, ça sert toujours
|
||||
|
||||
On proposera donc les deux devis intéressants au CA.
|
||||
|
||||
### Monitoring
|
||||
|
||||
Rappel sur l'existence de munin.crans.org et autostatus.crans.org et le
|
||||
nettoyage à faire par les nounous.
|
||||
|
||||
### Permutation séminaires/CA/IN
|
||||
|
||||
Superposition: No.
|
||||
On fait un Doo^W framadate pour demander aux apprentis ce qu'ils en pensent.
|
||||
|
||||
### Prochains séminaires
|
||||
|
||||
Mardi prochain : séminaire Debian par Nicolas.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Pont WiFi
|
||||
|
||||
Sous réserve que la déclaration à l'ARCEP avance, pas de problème du point de
|
||||
vue technique, un câble est présent en plus. On verra pour faire une commande
|
||||
groupée de borne. On pense commander des nanobeam M5 (qui ont l'air d'être une
|
||||
évolution des nanoM5 utilisées actuellement.)
|
||||
|
||||
<http://landashop.com/catalog/ubnt-nanobeam-nbem519-5ghz-19dbi-dual-p-3163.html>
|
||||
|
||||
#### Comptes inactifs
|
||||
|
||||
Raphaël se lance dans la réécriture de gestion des comptes inactifs. Il propose
|
||||
un effacement des anciens comptes au bout de 3 avertissements, mensuels.
|
||||
À suivre.
|
||||
|
|
@ -0,0 +1,131 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 23 octobre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h15
|
||||
* Fin : 20h20
|
||||
|
||||
## Présents
|
||||
|
||||
* Thomas Epalle
|
||||
* Raphaël-David Lasseri
|
||||
* Myriam Begel
|
||||
* Jordan Delorme
|
||||
* Daniel Stan
|
||||
* Pierre-Elliott Bécue (19:30)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Retour sur le dernier spoofeur
|
||||
|
||||
Le spoofeur devait passer à la maison de l'étudiant lundi pour vérifier des
|
||||
traces de changement spontanées d'adresse mac. Raphaël-David
|
||||
a consulté le journal des évènements de windows, et cela confirme nos logs, il
|
||||
s'agit bien de sa machine qui a usurpé les macs d'autres
|
||||
adhérents.
|
||||
Raphaël a également installé un antivirus qui a trouvé une dizaine de virus dès
|
||||
l'installation. On n'a pas envie de perdre davantage de temps
|
||||
là dessus. Il se pose la question de savoir si on prévient les personnes
|
||||
spoofées, on demandera au CA. A priori, l'usurpation d'adresse
|
||||
MAC (et d'IP) n'induit pas nécessairement une usurpation d'identité, d'autant
|
||||
plus que nos logs confirment les faits, et l'adhérent a
|
||||
reconnu publiquement le problème (même s'il met en cause un "ami".)
|
||||
|
||||
On décide de ne pas perdre davantage de temps sur ce problème que l'on laisse à
|
||||
la discrétion du CA.
|
||||
|
||||
### Comptes inactifs
|
||||
|
||||
Les sources ne sont pas encore prêtes.
|
||||
Pour l'instant, les logs sont parsés sur zamok et owl, et le script met à jour
|
||||
l'attribut LDAP de dernière connexion en fonction.
|
||||
Raphaël se demande si on doit poursuivre sur ce fonctionnement à base de cron.
|
||||
On poursuit ce fonctionnement en centralisant les
|
||||
logs sur thot, y compris ceux du CAS, s'ils sont exploitables facilement. En
|
||||
vrai, il faudrait surveiller la totalité des services du Cr@ns
|
||||
sauf que tous les programmes n'utilisent pas syslog.
|
||||
Will be ready soon.
|
||||
|
||||
### Monitoring, envoi de SMS
|
||||
|
||||
L'adaptateur HDMI-VGA est reçu : le but est de brancher une raspberry pi pour
|
||||
afficher un dash board sur l'écran en rab que l'on possède au 2B. Cet écran est
|
||||
censé s'allumer en cas d'alerte. Il faut voir la forme à donner aux
|
||||
informations qui s'affichent : un dump d'autostatus…
|
||||
|
||||
La clé GSM n'est pas encore reçue. Fonctionnement du système de notification
|
||||
par SMS en deux étapes :
|
||||
|
||||
* Munin (par exemple, lors d'un warning ou error) va recevoir comme instruction
|
||||
de lancer un script (et non un mail) qui contient l'API de Free. Un SMS est
|
||||
donc envoyé sur la ligne Free.
|
||||
* Sur un serveur (le même que Munin, par exemple) auquel est branché la clé
|
||||
GSM, le paquet gammu-smsd se charge de gérer la carte SIM (envoi, stockage et
|
||||
réception de SMS). Le fichier de configuration permet notamment de lancer un
|
||||
script à la réception d'un SMS, de lire le contenu et de lancer des
|
||||
commandes (c'est la base du fonctionnement) et de ne lire/recevoir que des
|
||||
SMS venant de certains numéros (très important pour ne pas que tout le monde
|
||||
puisse lancer des commandes).
|
||||
|
||||
Il est possible d'interfacer Asterisk avec l'ensemble. Ainsi, la personne
|
||||
pourrait recevoir un message SIP s'il est connecté sur ce service, ou un SMS
|
||||
s'il ne l'est pas.
|
||||
Dans un premier temps, on peut tester ça sur vo pour voir la réactivité de
|
||||
l'ensemble, la sécurité qu'il y a… Jordan se charge d'installer ça sur vo et de
|
||||
faire une page explicative sur le Wiki.
|
||||
Pierre-Elliott demande si le forfait Free à 0 euros est viable sur le long
|
||||
terme, et si les conditions d'utilisations ont été lues. Ce n'est pas le cas,
|
||||
et comme tout fournisseur téléphonique, nous n'avons pas de visibilité à long
|
||||
terme. S'il y'a un changement dans les conditions d'utilisations, nous
|
||||
prendrons le temps de considérer ça.
|
||||
|
||||
### Optimisation WiFi
|
||||
|
||||
Ping s'est rendu compte sur sa borne sous OpenWRT que le mode routage donnait
|
||||
de meilleures performances que le mode bridge (lorsqu'on fait du NAT).
|
||||
|
||||
Hypothèse : les paquets ARP, lorsqu'on fait du routage, ne sont pas transmis à
|
||||
tout le monde. On gagne du temps si on filtre les paquets ARP (paquets whohas),
|
||||
et en les droppant.
|
||||
|
||||
Supposition : on ne peut pas spoofer les adresses MAC en WiFi. En utilisant
|
||||
ebtables pour filtrer les requêtes ARP whohas, on accepte juste les requêtes
|
||||
d'IP existantes.
|
||||
|
||||
En terme de débits, un gain de 20% a été remarqué. Cela mérite notre attention
|
||||
pour le réseau du Cr@ns.
|
||||
Ping va regarder ça côté Cr@ns : une difficulté est de faire des règles
|
||||
dynamiques car on ne sait pas à l'avance qui va se connecter, son adresse IP…
|
||||
Attention : cela permet de n'optimiser que l'IPv4. Par défaut, tout le monde se
|
||||
connecte en IPv6 (dual stack).
|
||||
|
||||
### Migration vers gitlab
|
||||
|
||||
/usr/script a été pushé vers gitlab : le push "à l'ancienne" n'est plus
|
||||
possible.
|
||||
Pour pusher, il faut modifier le remote :
|
||||
|
||||
* mettre comme remote l'URL git@gilab.crans.org:nounous/scripts.git [mettre une
|
||||
clé publique SSH avant sur Gitlab et penser à faire la config SSH associée]
|
||||
* mettre comme remote l'URL <https://gitlab.crans.org/nounous/scripts.git> (pas
|
||||
de config, mais lorsqu'on push, il faut se réauthentifier avec son login/mdp
|
||||
traditionnels)
|
||||
|
||||
L'ancien git peut toujours être lu sur git.crans.org (à coup de symlink). Il
|
||||
peut être utile de le garder comme vitrine pour nos scripts.
|
||||
|
||||
### Les caprices de lc_ldap
|
||||
|
||||
Lc_ldap met un temps fou à charger l'ensemble des adhérents/machines en
|
||||
écriture. En plus, souvent, il se vautre lamentablement. Pierre-Elliott propose
|
||||
de tweaker un peu l'instanciation des objets pour ne faire les sanity checks
|
||||
que lorsqu'on modifie des données, pas lorsqu'on les importe de la base (auquel
|
||||
cas, on admet qu'elles sont valides).
|
||||
On le laisse s'amuser avec ça.
|
||||
|
||||
### Divers
|
||||
|
||||
#### Carte étudiant
|
||||
|
||||
Il faut envoyer un mail aux adhérents. Étant en période de vacances, on va
|
||||
probablement donner quelques jours supplémentaires pour délivrer le document.
|
||||
|
|
@ -0,0 +1,150 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 6 novembre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h00
|
||||
* Fin : 20h22
|
||||
|
||||
## Présents
|
||||
|
||||
* Myriam Bégel
|
||||
* Gabriel Detraz
|
||||
* Daniel Stan
|
||||
* Raphael David Lasseri
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### État du 2B
|
||||
|
||||
L'expertise du collège technique a été requise sur la question de
|
||||
l'accumulation des déchets dans la poubelle du 2B. Les nounous
|
||||
confirment : celle-ci est pleine à craquer et un ménage imminent du 2B est
|
||||
nécessaire.
|
||||
(no comment.)
|
||||
|
||||
### Système d'impression
|
||||
|
||||
Pour résumer :
|
||||
|
||||
* La vm "cups" a été créée, elle tourne mais pas encore de configuration du
|
||||
tout dessus
|
||||
* Le driver pcl est en cours d'écriture, Daniel fournira un draft qui
|
||||
implémentera 1/2 options et laissera les autres implémentations aux apprentis
|
||||
* Le script de notification fonctionne \o/
|
||||
|
||||
À faire :
|
||||
|
||||
* Bcfg2
|
||||
* Installer cups
|
||||
* Finir le driver
|
||||
* Un script de recrédit pour les jobs foirés (avec mail de notification pour
|
||||
cela)
|
||||
|
||||
### Environnement de test des scripts
|
||||
|
||||
Daniel a commencé a modifié /usr/scripts pour permettre au dépôt d'être cloné
|
||||
ailleurs que dans /usr/scripts
|
||||
et utilisé depuis un autre dossier. Le script indiqué dans le shabang se charge
|
||||
également d'indiquer
|
||||
quelques variables d'environnement pour passer en mode test. Work in progress,
|
||||
mais il veut bien
|
||||
des feedbacks.
|
||||
|
||||
Tout cela sera résumé sur
|
||||
<https://wiki.crans.org/CransTechnique/ConventionsUtiles/ScriptsPython>
|
||||
|
||||
### Màj d'OpenWrt
|
||||
|
||||
La nouvelle version d'!OpenWrt est sortie en juillet (Barrier Breaker), Daniel
|
||||
suggère de recommencer
|
||||
from scratch pour voir ce qu'on garde comme modification par rapport à
|
||||
upstream, et repartir sur des
|
||||
bases saines.
|
||||
|
||||
* Rendre la borne manageable en ipv6 (idéalement, virer l'ipv4 complètement)
|
||||
* Multicast (il paraît que ça marche mieux cf changelog)
|
||||
* Vlans Dynamiques (il faut voir si ça marche mieux)
|
||||
|
||||
On va bientôt avoir de nouvelles bornes (a priori) pour pouvoir commencer des
|
||||
tests. Avis aux volontaires.
|
||||
On va également remplacer une petite picostation d'un bâtiment pour faire
|
||||
cobaye, on la remplacera
|
||||
par une unifi (qui est moins robuste aux tests intensifs).
|
||||
|
||||
### "Modems" Wifi d'appoint
|
||||
|
||||
Il est envisagé de déployer des points wifi secondaires chez l'adhérent. Le
|
||||
principe est simple : l'adhérent
|
||||
reçoit contre caution une borne flashée par nos soins, dans le but de servir de
|
||||
point d'accès Wifi,
|
||||
et éventuellement filaire.
|
||||
Ce point se comporte comme une borne classique, le principe étant que
|
||||
l'adhérent et ses voisins puissent
|
||||
s'y connecter. Le but étant que ce soit le plus transparent possible. Cela
|
||||
résoudrait en partie le problème
|
||||
des zones blanches de couverture wifi.
|
||||
|
||||
Cependant, il n'est pas encore établi si la désactivation de radius est
|
||||
nécessaire pour faire passer le vlan
|
||||
adh non tagué et le vlan 3 tagué en direction de la chambre de l'adhérent,
|
||||
l'idéal étant que ça ne le soit pas.
|
||||
D'autres détails, tels que la présence du mot de passe en clair dans la conf
|
||||
des bornes méritent l'attention.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Un point sur le nouveau script de comptes inactifs
|
||||
|
||||
Ça buggue, ça buggue, ça buggue. Il faut discuter des délais avant suppression
|
||||
du compte. On demandera (en partie)
|
||||
au CA. Il est envisagé une suppression auto au bout d'un an d'inactivité (après
|
||||
envoi de 4 messages).
|
||||
|
||||
#### Serveur de backup
|
||||
|
||||
PEB propose ceci :
|
||||
<http://pad.crans.org/p/serveur_backup>
|
||||
{{{
|
||||
|
||||
## Carte mère
|
||||
|
||||
* <http://www.rue-montgallet.com/prix/acheter,asus-z87-pro,789193> ou
|
||||
<http://www.rue-montgallet.com/prix/acheter,asus-z87-expert,788729>
|
||||
* ~ 150 € à ~ 200 €
|
||||
|
||||
## RAM
|
||||
|
||||
* <http://www.rue-montgallet.com/prix/acheter,g.skill-ripjaws-x-ddr3-1600-cl7-8go-2x4go,743095>
|
||||
* ~100 €
|
||||
|
||||
## Processeur
|
||||
|
||||
Haswell
|
||||
|
||||
* <http://www.rue-montgallet.com/prix/acheter,intel-core-i5-4690k-3.5ghz,799815>
|
||||
* ~200 €
|
||||
|
||||
## Boîtier
|
||||
|
||||
* <htttp://www.rue-montgallet.com/prix/acheter,cooler-master-silencio-rc-550-650w,753033>
|
||||
* ~150 €
|
||||
|
||||
## Disques Durs
|
||||
|
||||
1 disque pour l'OS (je propose SSD) et 6 HDD (2 To, 7.2krpm) pour les backups
|
||||
Suggestion : <http://www.rue-montgallet.com/prix/acheter,seagate-3to-7200-rpm-s-ata-iii-64mo-st3000dm001,755875>
|
||||
(moins cher des 7200RPM))
|
||||
|
||||
* HDD : <http://www.rue-montgallet.com/prix/acheter,seagate-2to-constellation-cs-st2000nc000,791833>
|
||||
* ~ 800 €
|
||||
* SSD : <http://www.rue-montgallet.com/prix/acheter,samsung-64go-830-series,761747>
|
||||
* ~ 100 €
|
||||
|
||||
## Budget
|
||||
|
||||
Environ 1 600 €. Les prix étant indiqués sur montgallet, il faut compter une
|
||||
marge de 10%, donc ~1800 €.
|
||||
}}}
|
||||
|
||||
On se demande l'intérêt d'un ssd pour l'OS. Mais why not. Un peu plus d'info
|
||||
sur le setup ne serait pas de refus.
|
||||
|
|
@ -0,0 +1,151 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 20 novembre 2014
|
||||
* Lieu : Pavillon Des Jardins
|
||||
* Début : 19h16
|
||||
* Fin : 20h21
|
||||
|
||||
## Présents
|
||||
|
||||
* Daniel Stan
|
||||
* Gabriel Detraz
|
||||
* Pierre-Elliott Bécue
|
||||
* Nicolas Dandrimont
|
||||
* Raphaël-David Lasseri
|
||||
* Thomas Epalle
|
||||
* Vincent Le Gallic
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Récapitulatif du matériel vacant
|
||||
|
||||
L'association grifon nous a contacté le 17/11/2014 afin de savoir si elle
|
||||
pouvait récupérer une partie de notre
|
||||
matériel réseau inutilisé à savoir 2~3 switchs procurve et un serveur (un vieux
|
||||
dell). PE avait soulevé le
|
||||
problème de turn-over sur le matériel. Il voulait aussi conserver un serveur
|
||||
pour faire des tests.
|
||||
|
||||
Au niveau serveur, on a 4 (ou 5?) serveurs dell sous les bras, on peut
|
||||
facilement s'en débarrasser d'un.
|
||||
|
||||
Pour les switchs, tous nos spares sont faulty, il faut faire jouer la garantie,
|
||||
remplacer les faulty présents dans
|
||||
les bâtiments, puis refaire jouer la garantie. On aurait alors 5 switchs
|
||||
hp "neufs", il faut faire un inventaire
|
||||
complet d'abord, mais sur le principe nous sommes d'accord pour céder deux
|
||||
switchs (un 26 ports et un 48 ?).
|
||||
|
||||
Il faudra en profiter aussi profiter du changement d'un switch pour passer
|
||||
l'aspirateur dans le local et
|
||||
ainsi éviter que les switchs s'encrassent trop vite (c'est a priori le problème
|
||||
actuel.)
|
||||
|
||||
### WiFi
|
||||
|
||||
#### Mise à jour vers BB
|
||||
|
||||
Gabriel, Lucas et Daniel ont commencé à adapter les modifications Crans sur la
|
||||
nouvelle version
|
||||
d'!OpenWrt.
|
||||
|
||||
* Nouvelle clé ssh (sur fy, /etc/crans/secrets/ parce que /usr/scripts/gestion
|
||||
c'était nul)
|
||||
* Vlan dynamiques : ça buggue toujours autant (à investiguer)
|
||||
* Management en Ipv6
|
||||
|
||||
Pour ce dernier point, on a créé un préfixe (ULA), un slash d'ip locale
|
||||
probablement globalement
|
||||
unique: fd:a8:5d34:a228/48, annoncé par odlyd.
|
||||
|
||||
Détails :
|
||||
|
||||
* fd : préfixe pour les IPs "ULA"
|
||||
* a8:5d34:a228 : tiré aléatoirement une fois pour ce réseau WiFi
|
||||
* c04 : mid de la machine qui route (3074 = odlyd.wifi), pour suivre la même
|
||||
convention que nos /48 publics.
|
||||
-> ça donne un /64 dans lequel sont toutes les bornes (et les machines Wifi,
|
||||
par effet de bord. Elle s'en servent pas, vu qu'elles savent qu'il n'y a pas
|
||||
Internet derrière).
|
||||
|
||||
Les bornes et machines prennent une IP supplémentaire dans ce /64. Pour les
|
||||
services, on a une IP canonique
|
||||
pour éviter de changer la configuration en cas de changement de machine.
|
||||
|
||||
* eap: fda8:5d34:a228:c04:7261:6469:7573:3031 (les 64 derniers bits
|
||||
codent "radius01")
|
||||
* pea: fda8:5d34:a228:c04:7261:6469:7573:3032 ("radius02")
|
||||
* thot: fda8:5d34:a228:c04:7379:736c:6f67:3031 ("syslog01")
|
||||
|
||||
Il y a des prob avec syslog qui marche de temps en temps (pour l'envoi vers
|
||||
thot), tester avec rsyslog. Il
|
||||
reste à faire des tests, bcfg2 sur les serveurs, firewall v6.
|
||||
|
||||
#### Nouvelles bornes
|
||||
|
||||
Les uap pro sont en test, pour l'instant, il se passe des trucs étranges avec
|
||||
openwrt.
|
||||
(pertes de paquets ? load balancing foireux entre les deux fréquences ?)
|
||||
|
||||
Ràs sur les unifi standard, sinon les couleurs des leds qui
|
||||
changent (inacceptable !)
|
||||
|
||||
#### Point sur les bornes du d'Alembert
|
||||
|
||||
On a notre réponse: deux bornes brassées sur notre switch (dlink) au d'Alembert
|
||||
centre. Il faut envisager
|
||||
de remplacer le dlink par un manageable. On verra pour les demandes de
|
||||
couverture en particulier,
|
||||
à part le Villon (Point rencontre, etc), on n'a peu de (aucune ?) demandes.
|
||||
|
||||
#### Pont(s)
|
||||
|
||||
(Côté administratif, la déclaration du Crans en tant qu'opérateur a bien été
|
||||
reçue.)
|
||||
Les intéressés ne sont pas présents. Un mail a été envoyé à la STL pour aller
|
||||
inspecter les anciennes bornes
|
||||
du toit du d'Alembert (vers Arpej). Pas de nouvelles pour l'instant.
|
||||
|
||||
#### Management ssh
|
||||
|
||||
Raphaël propose à des apprentis de recoder des bouts de wifi_new avec une lib
|
||||
ssh : paramiko voir
|
||||
fabric. Avis aux volontaires.
|
||||
|
||||
#### Freeradius et mdp custom
|
||||
|
||||
Il serait possible d'enregistrer un mdp radius différent sur chaque borne. Il
|
||||
faudrait coder une
|
||||
authentification particulière sur freeradius pour cela. Daniel voit comment
|
||||
faire cela, mais il recrute
|
||||
un apprenti pour le faire (buzzwords: python, ldap, freeradius).
|
||||
|
||||
### Rabbit Mq (manger du lapin nuit-il au développement du râble ?)
|
||||
|
||||
[interlude explicative]
|
||||
On réfléchit à une manière d'implanter les dépendances sur les services.
|
||||
|
||||
Idée : faire un séminaire pour expliquer AMQP dans le détail puis discuter de
|
||||
notre utilisation au Crans.
|
||||
|
||||
### Prochains séminaires
|
||||
|
||||
<https://wiki.crans.org/CransTechnique/CransApprentis/SeminairesTechniques/2014-2015>
|
||||
|
||||
On a booké les séminaires de la semaine prochaine et de la suivante. Avis pour
|
||||
la suite, PE veut bien parler d'AMQP.
|
||||
|
||||
### OwnCloud
|
||||
|
||||
Php (module pgsql ?) n'aime pas l'ipv6. Il va plus vite maintenant.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
#### Réservation salles
|
||||
|
||||
On s'est aperçus ce soir que notre réservation du PdJ le jeudi soir n'est plus
|
||||
d'actualité.
|
||||
Peut-être que quand le CA est passé le Vendredi soir, la réservation du jeudi a
|
||||
été totalement dropée ?
|
||||
Il faut voir ça avec la responsable ENS, histoire qu'on se le fasse pas piquer.
|
||||
On fouette le CA.
|
||||
|
|
@ -0,0 +1,73 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 04 décembre 2014
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h20
|
||||
* Fin : 19h56
|
||||
|
||||
## Présents
|
||||
|
||||
* Gabriel Détraz
|
||||
* Raphaël-David Lasseri
|
||||
* Pierre-Elliott Bécue
|
||||
* Daniel Stan (20h01)
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### WiFi
|
||||
|
||||
Gabriel signale que la barre des 80 bornes posées à été franchie. Il compte en
|
||||
poser encore deux avant les vacances.
|
||||
Il reste encore quelques problèmes concernant les logs, le fait que la borne
|
||||
n'ai plus qu'une adresse v6 est mal géré à la fois à l'envoi par la borne
|
||||
et à l'arrivée par rsyslog...
|
||||
Daniel regarde.
|
||||
|
||||
### Factures
|
||||
|
||||
PEB apporte quelques précisions concernant les attributs des factures :
|
||||
|
||||
* recuPaiement est censé être modifiable par tous, pour permettre par exemple,
|
||||
au câbleur de modifier cet attribut (cas d'un adhérent partant sans payer)
|
||||
* controle : Permet au trésorier de "locker" la facture et de la
|
||||
valider/devalider.
|
||||
|
||||
### gest_crans_lc
|
||||
|
||||
Valentin à continuer à bosser dessus, toutefois dans l'état le script reste
|
||||
difficilement accessible à un utilisateur débutant en Python, il faut le
|
||||
continuer à le proprifier dans les semaines et mois à venir.
|
||||
|
||||
### lc_ldap
|
||||
|
||||
Actuellement, il y a deux fonctions qu'il est intéressant d'appeler avant de
|
||||
sauvegarder un objet dans la base ldap :
|
||||
|
||||
* validate_change() qu'il s'occupe de maintenir de la cohérence entre les
|
||||
attributs (rid, ipv6, ipv4, et autre)
|
||||
* history_gen() qui génère l'historique des modifications
|
||||
|
||||
Il pourrait être bien de les faire appeler par défaut par la méthode save(),
|
||||
tout en le laissant désactivable au cas par cas :
|
||||
save(validate_change=False, history_gen=False) comme validate_change semble
|
||||
idempotente, ça n'est pas grave vis à vis de ceux qui l'appel déjà à la main,
|
||||
pour history_gen, ça va mettre des lignes en double (modulo la date).
|
||||
Ce sera fait.
|
||||
|
||||
### Propreté des serveurs
|
||||
|
||||
Il faut proprifier autostatus et munin. (Rapide et simple à faire)
|
||||
Pour bcfg2 c'est un peu plus risqué.
|
||||
PEB à commencer à faire du ménage dans /usr/scripts il reste encore plusieurs
|
||||
scripts à trier.
|
||||
|
||||
### Soyouz
|
||||
|
||||
Soyouz coûte actuellement ~500€ par an chez OVH, le collège technique considère
|
||||
qu'il est important de garder ce serveur pour l'année à venir.
|
||||
|
||||
### Questions diverses
|
||||
|
||||
### Repas FedeRez
|
||||
|
||||
C'est mardi...
|
||||
|
|
@ -0,0 +1,101 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 8 janvier 2015
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h12
|
||||
* Fin : 19h56
|
||||
|
||||
## Présents
|
||||
|
||||
* Gabriel Détraz
|
||||
* Raphaël-David Lasseri
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Serveur de backups
|
||||
|
||||
Omnomnom est en marche, il backup les homes des adhérents \o/
|
||||
|
||||
Il reste à lui trouver une place sur le campus.
|
||||
|
||||
Les présents décident de l'installer au 0H, à faire un soir entre deux backups.
|
||||
|
||||
### Mise à jour vers Barrier Breaker (bornes wifi)
|
||||
|
||||
Gabriel rappelle que getlogwifi est maintenant un démon qui sert à ouvrir des
|
||||
connexions SSH vers toutes les bornes et d'en récupérer les logs.
|
||||
|
||||
Il reste à faire en sorte que ce script renvoie les logs directement vers
|
||||
rsyslog et non pas dans un fichier (sic) comme c'est le cas actuellement.
|
||||
|
||||
### Bornes Unifi 5Ghz
|
||||
|
||||
Il semblerait que l'attribution d'une IP via une connexion 5GHz soit très
|
||||
lente…
|
||||
Il faut investiguer.
|
||||
|
||||
### Kludge des Ipv4 Wifi
|
||||
|
||||
Cf
|
||||
<http://git.crans.org/?p=usr-scripts.git;a=commitdiff;h=275934c23c944a2fe711a29bed71b4020833929b>
|
||||
|
||||
But de la manœuvre : beaucoup (~2000 ?) de machines inscrites en WiFi, avec
|
||||
souvent des mac restées en `automatique` donc jamais vraiment utilisées. Le
|
||||
système voulait en revanche que l'ipv4 soit assignée à l'avance, ce qui nous
|
||||
saturait notre slash ipv4 WiFi.
|
||||
|
||||
Daniel a donc rapidement patché ldap_crans et cie pour autoriser l'absence
|
||||
d'ipv4
|
||||
sur une machine, et fait en sorte que l'ipv4 soit assignée à la première
|
||||
connexion (dans freeradius), en même temps que la mac. Plus précisément, la
|
||||
machine n'a pas de champs
|
||||
ldap "ipHostNumber" ("`automatique`" posait problème),
|
||||
ni de champ ldap "rid". On assigne un rid valide à la machine, et l'ipv4 est
|
||||
calculée à partir de là.
|
||||
|
||||
Pour l'instant, ça marche, même s'il ne s'agit pas d'une solution
|
||||
totalement pérenne.
|
||||
|
||||
Par contre, Daniel est formellement contre l'effacement systématique
|
||||
de machines
|
||||
jamais connectées : il pense que cela nous sera bien trop coûteux de déboguer
|
||||
les connexions WiFi d'adhérents qui essayeront de rentrer des logins qui
|
||||
n'existent plus. En plus, ça polluera encore l'image du WiFi en tant que
|
||||
service
|
||||
"qui marche pas"®©.
|
||||
|
||||
Pierre-Elliott et Raphaël préfèrent détruire les machines WiFi qui restent
|
||||
inactives pendant
|
||||
plus de 3 mois quitte à envoyer un mail aux adhérents concernés.
|
||||
|
||||
### Câbleuse 2.1
|
||||
|
||||
Daniel bidouille une nouvelle version de la câbleuse/ticketteuse à base de rpi
|
||||
au
|
||||
format compact (découpé avec amour, à la perceuse, dans une boite de Ferrero),
|
||||
stay tuned.
|
||||
Un des objectifs est d'avoir quelque chose de résilient aux pannes de courant
|
||||
de la Kfet'.
|
||||
De la doc va venir, aussi.
|
||||
|
||||
### Remarques diverses
|
||||
|
||||
#### Passage à Jessie
|
||||
|
||||
On ne va pas tarder à dist-upgrade il faudra trouver des motivés et annoncer
|
||||
les mises à jour
|
||||
des services critiques.
|
||||
|
||||
#### Binding ldap
|
||||
|
||||
Django a un module d'administration ldap (django-ldapdb
|
||||
<https://github.com/jlaine/django-ldapdb>).
|
||||
Ça simplifierait grandement la gestion des attributs et des logs et cela
|
||||
permettrait surtout d'avoir
|
||||
un binding maintenu, plus simple à comprendre et plus léger. En plus, on
|
||||
pourrait facilement adapter
|
||||
une interface web pour le câblage.
|
||||
|
||||
Aucune urgence mais il serait intéressant de réfléchir un peu à cette piste et
|
||||
continuer à se renseigner.
|
||||
|
|
@ -0,0 +1,127 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 22 janvier 2015
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h14
|
||||
* Fin : 20h30
|
||||
|
||||
## Présents
|
||||
|
||||
* Raphaël-David Lasseri
|
||||
* Emmanuel Arrighi
|
||||
* William Babonnaud
|
||||
* Gabriel Detraz
|
||||
* Hamza Dely
|
||||
* Daniel Stan
|
||||
* Gaétan Facchinetti
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Préparation de l'Install Party
|
||||
|
||||
* Le Netboot fonctionne-t-il ? Il faut vérifier et sur le vlan évènement et sur
|
||||
adhérent.
|
||||
* Possibilité du portage du netboot en efi ? (on essaie ce
|
||||
soir : <https://wiki.ubuntu.com/UEFI/PXE-netboot-install> )
|
||||
* ''A priori'', les distributions disponibles sont à jour.
|
||||
* Il faut prévoir des clés usb en rab pour les uefi secure boot si jamais on
|
||||
n'arrive pas à les désactiver.
|
||||
* Les vlans : a priori ils sont bons et vérifiés en taggued sur toutes les
|
||||
prises. Les switches ont été configurés et sont ok.
|
||||
|
||||
### Achat de bornes Wifi
|
||||
|
||||
Gabriel propose de racheter deux boites de 3 bornes (Unifi standard). Résumé
|
||||
des besoins : une pour le bâtiment B, pour remplacement, et 3 autres au M. Le
|
||||
reste sera dispo pour remplacement, en appoint.
|
||||
|
||||
(Sans les frais de port)
|
||||
|
||||
* IP : 432€
|
||||
* landashop : 465€
|
||||
|
||||
### Omnomnom
|
||||
|
||||
Pierre-Elliott a oublié d'acheter un disque dur de rechange. On propose ça au
|
||||
CA, avec un ventilo supplémentaire pour la tour (histoire d'être sûr).
|
||||
|
||||
* Disque : 220 € (<http://www.rue-montgallet.com/prix/acheter,seagate-3to-7200-rpm-s-ata-iii-64mo-st3000dm001,755875>)
|
||||
* Ventilo : 15 - 20 €.
|
||||
|
||||
### Migration sous barrier breaker
|
||||
|
||||
Petit problème mineur lors de la migration : on a oublié d'activer l'option
|
||||
d'atheros pour avoir les canaux
|
||||
spécifique à l'Europe ETSI (canaux 12 et 13).
|
||||
|
||||
On a re-flashé une partie des bornes, mais pas toutes. Celles du G, C,
|
||||
d'Alembert, H et PDJ ont toutes le firmware patché.
|
||||
|
||||
À voir ce qu'on fait du canal 13, pour l'instant, on l'a mis en test à la
|
||||
Kfet (lieu de passage de tout
|
||||
nouveau venu), histoire de faire des tests.
|
||||
|
||||
Bug détecté avec les nouvelles unifi au reboot, moins présent après passage à
|
||||
barrier breaker, à investiguer.
|
||||
|
||||
### Switches
|
||||
|
||||
On a reçu 3 switches 24 ports et 2 switches 48 ports. Les switches de
|
||||
remplacement sont des 2620 neufs, du coup c'est cool. Gabriel fera une seconde
|
||||
session.
|
||||
|
||||
### Coupure électrique
|
||||
|
||||
Le mercredi 21 janvier, la ville a rebooté, le campus aussi. Le CROUS a
|
||||
souffert au niveau du TGBT (Tableau Général Basse Tension), du coup ça a pris
|
||||
plus de 45 minutes à revenir, et on a perdu le 0B.
|
||||
|
||||
On s'est rendus compte de deux détails, premièrement, la gestion de l'ISCSI et
|
||||
du montage des disques des homes sur zbee, ça marche pas. PEB est sur le coup
|
||||
en utilisant udev et en rajoutant des nofail en option sur le montage des home.
|
||||
Le deuxième problème est la default via foireuse d'odlyd au boot. Il parle en
|
||||
utilisant son IP côté ENS, du coup les réponses qui lui sont destinées sont
|
||||
droppées, aiccu et vpn n'y arrivent pas, du coup. Normalement, une règle
|
||||
post-up dans interfaces corrige la route.
|
||||
|
||||
/usr/scripts ne s'est pas monté partout, le wiki ne s'est pas bien démarré, et
|
||||
idem pour l'imapproxy de SOGo. À surveiller, mais le reboot était fait
|
||||
à la hache, ça n'a sûrement pas aidé.
|
||||
|
||||
Trucs à prévoir pour la prochaine fois :
|
||||
|
||||
* Séquence de coupure automatique annoncée par pulsar
|
||||
* Retrouver le mdp de pulsar pour accomplir la tâche précédente (sic)
|
||||
* Vérifier la default route sur odlyd
|
||||
* Désactiver l'auto-reboot après coupure, sur les serveurs
|
||||
* Vérifier la signalétique des disjoncteurs (« arrivée onduleur ou pas ? »)
|
||||
* Les bornes wifi qui ont décidé de snobber radius (un wifi down; wifi up les a
|
||||
calmé), ainsi que NTP.
|
||||
|
||||
### Kludge kvm
|
||||
|
||||
On compte acheter deux trois adaptateurs
|
||||
usb-ps2 (<http://bit.ly/17YtjeC>) compatibles kvm pour dépanner, entre autre
|
||||
le kvm du 0B, celui du 0H.
|
||||
|
||||
## Questions diverses
|
||||
|
||||
### CransPasswords
|
||||
|
||||
Pierre-Elliott a commencé a modifier la base pour la rendre indépendante de
|
||||
ssh, et de sudo dans le but de ne plus avoir besoin d'un utilisateur sur le
|
||||
serveur.
|
||||
|
||||
### Délégation de sous-domaines et machine exté
|
||||
|
||||
On a eu une demande d'adhérent pour inscrire un ndd en .crans.org vers une IP
|
||||
extérieure, voire déléguer le sous-domaine à l'adhérent.
|
||||
|
||||
Techniquement faisable, mais les binding ne sont pas prévus pour, pour le
|
||||
moment. On peut :
|
||||
|
||||
* Inscrire des machines (rid spéciales)
|
||||
* Développer une appli sur l'intranet2 pour cela (pour crans.eu, pour ne pas
|
||||
mélanger avec crans.org)
|
||||
|
||||
On retient la solution 2, pour tester (django-ldapdb ou pgsql ?)
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
# Réunion du Collège Technique
|
||||
|
||||
* Date : Jeudi 5 février 2015
|
||||
* Lieu : Pavillon des Jardins
|
||||
* Début : 19h07
|
||||
* Fin : 20h00
|
||||
* Lien vers l'[etherpad
|
||||
associé](http://pad.crans.org/p/Jeudi5F%C3%A9vrier2015IN)
|
||||
|
||||
## Présents
|
||||
|
||||
* Raphaël-David Lasseri
|
||||
* Gabriel Detraz
|
||||
* Myriam Bégel
|
||||
* Emmanuel Arrighi
|
||||
* Daniel Stan
|
||||
* Pierre-Elliott Bécue
|
||||
|
||||
## Ordre du jour
|
||||
|
||||
### Nouveaux switchs 2620
|
||||
|
||||
Les 3 procurves 2620 ont été installés durant la coupure au PDJ et bâtiment J,
|
||||
en remplacement de batp-0, 2 et batj-0.
|
||||
Il faudra mettre à jour la base ldap. L'échange des 3 anciens défectueux a
|
||||
commencé : ils sont arrivés aujourd'hui.
|
||||
|
||||
Il reste cependant quelques questions :
|
||||
|
||||
* Que dit HP du problème avec le dhcp snooping ?
|
||||
* Pas encore de réponse, pour le moment on reconfigure sans (et on le remet
|
||||
à la main une fois le switch booté)
|
||||
* Gestion des switchs restants
|
||||
|
||||
Au terme des échanges, si on reçoit effectivement des 2620, les switchs
|
||||
disponibles et fonctionnels seront donc :
|
||||
|
||||
* trois 2620 48 ports ou assimilés envoyés par hp.
|
||||
* deux 2620 24 ports
|
||||
* deux 2626 24 ports
|
||||
|
||||
Décision ayant été prise d'envoyer 2 ou 3 switchs à Grifon, on envisage de leur
|
||||
envoyer un 2626-24 et un 2650-48 ports.
|
||||
|
||||
On pourrait mettre un 2626 au Krobot, le dlink s'y trouvant se comportant de
|
||||
manière erratique, on peut aussi leur
|
||||
prêter (sous caution) un des petits TP-Link sur lesquels on bosse en ce moment.
|
||||
Ce serait l'occasion de finaliser
|
||||
ce projet.
|
||||
|
||||
Reste la med : on pourrait y mettre soit un 2620-24 (batb-5), soit un petit
|
||||
switch manageable ou pas, pas trop cher.
|
||||
Vu qu'un 2620 est déjà installé (batb-5) et qu'il nous en reste plusieurs, on
|
||||
peut le laisser.
|
||||
|
||||
Manageable :
|
||||
|
||||
* <http://www.senetic.fr/product/J9802A?gclid=Cj0KEQiAuremBRCbtr-1qJnKi-4BEiQAh0x08K8BAtSiJQIde3KAP66T4B71418jBs8db9VquPZVWHsaApEW8P8HAQ>
|
||||
* <http://www.ldlc.com/fiche/PB00157997.html>
|
||||
|
||||
Non manageable :
|
||||
|
||||
* <http://www.amazon.fr/D-Link-DGS-108-boîtier-Gigabit-Ethernet/dp/B0074CDCN4/ref=sr_1_6?ie=UTF8&qid=1422798674&sr=8-6&keywords=switch>
|
||||
|
||||
Il y aurait alors deux 2620-48, un 2620-24 et un 2626 pour les install partys
|
||||
et autres évènements.
|
||||
|
||||
### Bornes au DeVinci
|
||||
|
||||
Gabriel, Alexis et Florian ont fait le tour des bornes avec Cédric Cheveaux
|
||||
dans le DGM. Deux Wrt54g, les 2 dernières du parc encore actives, ont été
|
||||
changées.
|
||||
|
||||
Demodocos et Ulysse étaient plantées, elles ont été rebootées. Ce ne sont pas
|
||||
des bullets, mais d'"anciennes" Pico2. Attention au firmware (et driver
|
||||
wifi) à utiliser. Pour rappel, il faut utiliser ath5k sur architecture atheros.
|
||||
|
||||
Il reste une dépouille au DGC à récupérer, et une borne à brasser
|
||||
correctement (polynice.)
|
||||
|
||||
### IPs dynamiques en WiFi
|
||||
|
||||
À l'heure actuelle, il reste 37 IPs wifi disponibles, + 88 IPs de bornes Wifi
|
||||
qui seront libérées bientôt (fonctionnement en ipv6-only.)
|
||||
Trop de machines à inscrire en WiFi, et en général, pas besoin d'IP fixe.
|
||||
|
||||
Bilan de ce qu'on a besoin de modifier :
|
||||
|
||||
* Plage de rid dédiés aux machines à IP dynamiques
|
||||
* Réserver la plage de rid du pool (pour éviter de l'utiliser à autre chose)
|
||||
* Utiliser l'ancienne plage des bornes
|
||||
* Modifier parefeu v4 (filtre mac-ip -> filtre mac)
|
||||
* Rien à faire dans le parefeu v6 (woot)
|
||||
* Dhcp
|
||||
* Et du DNS à la volée ?
|
||||
* Kikooo mais pourquoi pas
|
||||
* Il y a aura déjà de l'ipv6 dans le ndd
|
||||
|
||||
Le vlan 6 (avec taggage dynamique) a toujours du mal à cohabiter sur les
|
||||
bornes… (snif)
|
||||
|
||||
### Bilan des dernières coupures de courant
|
||||
|
||||
Les problèmes à l'extinction :
|
||||
|
||||
* Des serveurs avec le mauvais mdp root (réglé)
|
||||
* Acpi non dispo sur plusieurs vm et machines fixes (c'est mis dans bcfg2)
|
||||
* Les serveurs non-crans ont pour certaines le même problème (osm, rezosup),
|
||||
c'est plus problématique car on n'y a pas accès, on contacte les proprio en
|
||||
question
|
||||
* Il faut régler pulsar pour lancer des ordres d'extinction, il dispose d'une
|
||||
fonction d'envoi de trappe snmp
|
||||
* Faire gaffe à ce qui est ondulé au 2B (sic)
|
||||
|
||||
Au boot :
|
||||
|
||||
* Les machines qui s'allument toutes seules au 0B, mais aussi au 4J (cochon qui
|
||||
essaie de monter le NFS alors qu'on veut que personne n'y touche…)
|
||||
* C'est dégueulasse les CR du
|
||||
crans… -- WikiCandy <<DateTime(2015-02-09T17:10:51Z)>>
|
||||
* Rejoncter la deuxième sortie (sur 3) a provoqué un appel de courant trop
|
||||
important, ce qui a fait rebooté à nouveau les serveurs
|
||||
* Le wake-on-lan des serveurs distants (babar et omnomnom) a bien marché
|
||||
|
||||
Il serait aussi préférable d'onduler correctement le 4J, afin de protéger
|
||||
l'imprimante et le serveur de diffusion des surtensions.
|
||||
Some files were not shown because too many files have changed in this diff Show More
Loading…
Reference in New Issue