Réunion du Collège Technique
- Date : Jeudi 14 Janvier
- Lieu : Pavillon Des Jardins
- Début : 19h09
- Fin : 20h45
Lien vers l'etherpad associé
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 ?