documentation/compte_rendus/2016_01_14.md

165 lines
5.7 KiB
Markdown

# Réunion du Collège Technique
* Date : Jeudi 14 Janvier
* Lieu : Pavillon Des Jardins
* Début : 19h09
* Fin : 20h45
* <<Pad>>
## Présents
Gabriel Detraz
Charlie Jacomme
Rémi Oudin
Daniel Stan
Martin Bauw
Myriam Bégel
Emmanuel Arrighi
Оксана Андреевна
Hamza Dely
Renaud Taleroy
## Ordre du jour
### letsencrypt sur intranet
(wiki/wifi, gitlab, phabricator, etherpad, owncloud, zerobin, ... ?)
Daniel propose de passer à un système centralisé. Il n'y aurait plus qu'un seul
serveur nginx tournant sur une machine à part, et les autres sites webs
seraient servi sur adm. On ferait alors un certif commun pour tous les
sous-domaines correspondant à un service internet.
* Créer une vm (ssl.crans.org ? plopissecured.crans.org ? secure.crans.org ! )
* Passer toutes les sockets gunicorn etc pour diffuser sur adm.
* Set up nginx
On va faire une proof of concept pour un service mineur. (zerobin?)
Apprentis : Fardale
Nounous : Charlie
### Remplacement monit/... ? par icinga
Objectif : virer autostatus, pour cela, il faut attendre le déploiement
d'icinga sur l'ensemble des serveurs (wheezy + jessie),
### Migration des virtualiseurs
* On va commencer par fz (ou tenter)
Apprentis : Rémi
### Migration des ipv6 ?
Le tunnel quantic a l'air un peu plus efficace que l'ancien.
On va pas tester en prod. Par conséquent, il faut attendre d'avoir un firewall
qui peut gérer deux prefixe v6.
Soit on patch salement l'actuelle, soit on attend le nouveau firewall.
Chirac va voir si c'est faisable assez simplement sur l'ancien firewall en
testant sur vo, mais rien ne presse.
### lc_ldap 3 or not ?
Les gens ne sont pas d'accord.
Le débat ici tient en deux pans.
Le premier point est de savoir si on veut commencer à passer les scripts du
crans à python3. Le support de python 2.7 s'arrête en 2020, il y a donc
plusieurs optiques possible. 2020 est encore relativement loin, donc est-ce que
passer à python3 est si urgent ?
Par ailleurs, on sera à Saclay avant la fin du support de python 2.7, on peut
donc laisser à l'ares le soin de s'occuper de python3. Cependant, plus la date
se rapproche, plus les nouvelles versions de software telle que Django vont
tout simplement dropper python2, ce qui pourrait nous poser problème.
Enfin, la question est-elle pertinente sachant que l'on a toujours pas terminé
de passer totalement à lc_ldap et qu'on a encore ldap_crans qui traine ?
Le deuxième point concerne le devellopement d'un "nouveau" binding. PEB a
commencé à travailler dans son coin sur une version python 3 de lc_ldap où il
essaie de corriger au passage certains problèmes de son papa. Problème : à
deux ans du déménagement, est-il pertinent de lancer le crans dans le
developpement d'un nouveau binding. Certains pensent que si chaque asso bosse
dans son coin sur un nouveau binding, c'est de mauvaise augure pour
l'unification à Saclay où tout le monde préférera jouer dans son coin.
Cependant, nous sommes encore à deux ans au moins du déménagement, ce qui veut
dire que si l'on commence à bosser maintenant sur quelque chose tous ensemble,
ce ne sera pas les gens qui ont develloppé le soft qui l'utiliseront, et comme
d'habitude, tout sera recodé. Certains proposent donc de continuer à travailler
au crans pour essayer d'avoir un nouveau binding qui pourrait être proposer
comme brique de départ au projet commun de l'ares qui naitra d'ici un ou deux
ans. Cela implique évidemment que l'on soit capable de notre côté de boucler le
projet en environ un an. Mais le doute persiste concernant la collaboration
future des assos si on joue dans notre coin.
Là deuxième moitié du second point concerne le choix des technologies de
devellopement du nouveau binding. D'aucun dise que ldap ça envoie du boudin et
que sql reste loin derrière. Si il semble établie que les librairies utilisant
ldap pour l'auth sont bien plus robustes et éprouvées que celles pour sql, la
question des performances est cependant plus épineuse. On trouve beaucoup de
random post sans vrai benchmark. Un récent benchmark de Daniel montre que
django est un peu plus lent que ldap qui est lui meme plus lent que sql simple.
Par ailleurs, d'un point de vue facilité de dev, django reste loin devant. Par
suite, une idée peut être d'avoir un coeur de base ldap juste pour l'auth, et
une base annexe psql/django pour tout le reste des infos. Vouloir passer le
crans sur ce genre de binding est cependant beaucoup plus ambitieux que
de "juste" passer à lc_ldap 3, et comme dit précédement, mettre en place ce
genre de projet semble n'etre pertinent que si on peut le mener à bout d'ici un
an.
### Ethercalc : mise en prod et système d'auth
Ethercalc est prêt, mais il n'y a pas encore de système d'auth.
On pousse !
L'idée est de faire une auth côté nginx -> sur plopissecured.crans.org ?
### Baie de disque
Elle est baie-hate !!
Il y a plein de disque de 600go maintenant. Sauf que seul leurs 300 premiers Go
sont utilisés...
La baie ne supporte un extend que lorsqu'on ajoute un disque.
Option 1 :
* On fait du ménage sur les vm
* On save tout sur les homes
* On formatte et reconstruit la grappe vm
* On redrop les vm à leur place.
Option 2 :
* On desactive les deux disques de 600Go de la grappe vm
* Avec les deux spare+ les deux nouveaux de 600, on crée un nouveau raid.
* On commence à transférer les données.
* Dès qu'un disque est libre on le retire de l'ancienne grappe on et le rajoute
à la nouvelle avec un extend.
Option 3 :
* Faire mumuse avec slon
On y réfléchit !
Apprentis : Fardale, Rémi
### Traduction de l'intranet
Appel à bonne volonté.
<http://pad.crans.org/p/intranet-traduction>
Cf le pad pour qui fait quoi.
### Question diverse
* Qui veut des chips ?