196 lines
6.4 KiB
Markdown
196 lines
6.4 KiB
Markdown
# Réunion du Collège Technique
|
|
|
|
* Date : Jeudi 3 décembre 2015
|
|
* Lieu : Pavillon Des Jardins
|
|
* Début : 19h12
|
|
* Fin : 20h47
|
|
* <<Pad>>
|
|
|
|
## Présents
|
|
|
|
* Hamza Dely
|
|
* Charlie Jacomme
|
|
* Vincent Le Gallic
|
|
* Rémi Oudin
|
|
* Daniel Stan
|
|
|
|
## Ordre du jour
|
|
|
|
### Beta let's encrypt
|
|
|
|
Vo utilise maintenant un certif let's encrypt, tout semble fonctionner.
|
|
Cependant, tout n'est pas encore packetté dans Debian stable. On pourrait
|
|
essayer d'attendre les backports.
|
|
|
|
Une fois le certif en place, il faut ensuite peupler la base ldap. L'idée
|
|
serait de le faire par cron, juste après une exécution de letsencrypt (ou dans
|
|
un plugin shell) pour mettre à jour la base (et donc tout ce qui est en dépend,
|
|
genre les dns).
|
|
|
|
C'est un bon projet pour apprentis. Featuring : LDAP ("base de données" du
|
|
Crans) et son binding au Crans {{{lc_ldap}}}, Python (langage de scripts), SSL
|
|
et génération de certificats, cron (exécution planifiée de taches périodiques).
|
|
|
|
On verra plus tard pour le déploiement sur le WiFi. Idéalement, on peut
|
|
commencer à tester déjà sur FedeRez-WiFi.
|
|
|
|
### Intranet (câblage)
|
|
|
|
Tout semble traité ici :
|
|
<http://pad.crans.org/p/cablage_lc>
|
|
Nous avons mis en place le full-login, pour l'instant ça semble marcher, modulo
|
|
timeout (à creuser), et la couleur, qui déplaît à 20-100.
|
|
|
|
Il faut que le bouton full-login soit plus visible, et mettre un message pour
|
|
prévenir les users membres actifs.
|
|
|
|
* Rendre la page de statut de l'imprimante accessible pour tous
|
|
* Ajouter la gestion des imprimeurs et du respo club depuis le menu club.
|
|
* Une fois que c'est traité, on se lance dans une beta sur l'intranet de prod
|
|
|
|
### Gest_crans_lc
|
|
|
|
Toutes les fonctions de gest_crans ont été portées (même impression de ticket),
|
|
à l'exception de la gestion des clubs.
|
|
|
|
C'est dans la tdl de Chirac.
|
|
|
|
<http://pad.crans.org/p/cablage_lc>
|
|
|
|
Merci de faire remarques et bug report ici. Il faut finir vite la gestion des
|
|
clubs (!).
|
|
|
|
* Peut-être un problème de gestion des mails ext (?).
|
|
|
|
### Routeur fail-over
|
|
|
|
Le principe : cf schéma tableau du 2B
|
|
|
|
Keepalived permet de partager une Ip sur 2 machines .
|
|
|
|
Chirac a testé ce week end. L'idée est que la gateway annoncée par les dhcp ne
|
|
soit plus 138.236.136.4 ou .148.4 mais 136.19.
|
|
|
|
Cette ip serait partagée entre komaz et odlyd, avec odlyd en master et komaz en
|
|
backup.
|
|
Par défaut, odlyd possède l'IP 136.19. Si il tombe, le daemon keepalived de
|
|
komaz s'en aperçoit, et komaz prend l'IP 136.19, donc devient la gateway.
|
|
|
|
Le problème principal concerne quagga, il faut éviter que les 2 routeurs
|
|
annoncent les mêmes routes sur zrt (OSPF, les routeurs de ZRT annoncent les
|
|
routes, et on est les seuls a part la dsi a en avoir 2...), pour éviter du
|
|
shitstorm.
|
|
|
|
La doc quagga suggère de faire un système où quagga n'est lancé que sur le
|
|
routeur master :
|
|
|
|
<http://wiki.kogite.fr/index.php/Quagga:_installation-paramétrage#Failover_avec_keepalived_.28vrrp.29>
|
|
|
|
NB : ici ca concerne BGP mais c'est pareil avec OSPF.
|
|
|
|
Questions :
|
|
|
|
* On propose d'utiliser 138.231.136.6 (tchu-pi, il peut sauter) ou
|
|
mieux : 138.231.136.254 (qui est plutôt canonique, (dernière IP du slash *des
|
|
serveurs*))
|
|
* Comment keepalived de komaz détermine que odlyd est "tombé" ?
|
|
|
|
. Les 2 keepalived se parlent via leurs IP adm. À creuser pour savoir comment
|
|
ils diagnostiquent le "c'est tombé".
|
|
|
|
* Comment ça se passe quand il ressuscite ?
|
|
|
|
. Soit le ressuscité reprend la main, soit il reste en attente jusqu'à ce que
|
|
l'autre tombe.
|
|
|
|
* On suggère de brancher titanic en 3ème routeur de fallback pour la connexion
|
|
de secours.
|
|
* Ça permettrait de se passer du {{{secours.py}}} de sable qui teste la
|
|
connectivité vers l'extérieur. Quand elle lâche, il prévient les autres
|
|
serveurs (via le NFS). Effet : odlyd redirige le trafic HTTP vers
|
|
titanic (proxy); sur les DNS, ça a pour effet qu'ils envoient leur
|
|
requêtes DNS à titanic et non plus via leur gateway habituelle.
|
|
|
|
. Attention, le {{{secours.py}}} de soyouz pour relancer le VPN via freebox et
|
|
non plus la connexion ENS reste nécessaire.
|
|
|
|
* Comment ça se passe pour la priorité des routeurs ? Ça se règle dans la conf
|
|
de keepalived.
|
|
* Penser ajouter un firewall sur titanic qui bazarde tout sauf le HTTP.
|
|
Attention aux connexion SSH entrantes '''prioritaires''' pour les nounous.
|
|
* Modéliser cela sur marionet
|
|
* Faire ses tests dessus
|
|
|
|
Autre système de secours (orthogonal au problème précédent) : mettre une patte
|
|
ipv6 aux serveurs sur le vlan de la freebox.
|
|
|
|
### Machine virtuelle Frekens
|
|
|
|
Le club Frek[ENS], fraîchement créé, voudrait mettre en place une webradio, et
|
|
demande pour ce faire à créer une webradio.
|
|
|
|
À faire :
|
|
|
|
* Inscrire Frek[ENS] en tant que club Crans
|
|
* Mettre en place le !WordPress (ou whatever) sur la page perso du club
|
|
* Si un jour, le club veut se mettre à faire du podcast, on rediscutera
|
|
ouverture de ports
|
|
* Si l'install de wordpress est impossible/trop compliquée sur les pages perso,
|
|
on peut envisager de créer une vm
|
|
|
|
Se pose le problème de dissociation du quota d'upload, a priori, on ne sait pas
|
|
quelle quantité d'upload sera générée. On avisera si l'upload de zamok explose,
|
|
sachant qu'il est toujours possible de savoir quel est le trafic généré par une
|
|
page perso via les logs apache.
|
|
|
|
### Séminaires
|
|
|
|
Suite au sondage à la fin du dernier séminaire, il y a des demandes pour un
|
|
workshop Python orienté objet, LDAP théorique, LDAP pratique.
|
|
A priori, Ping serait motivé pour faire un atelier mardi sur python orienté
|
|
objet.
|
|
Chirac voudrait faire un atelier {{{lc_ldap}}}.
|
|
Daniel propose de faire une présentation des scripts du Crans sous forme
|
|
d'atelier le 15/12 et expliquer comment on peut faire pour bidouiller chez soi.
|
|
|
|
### Virtualisation
|
|
|
|
Stitch est racké. Il est branché à la baie (prendre une IP différente de celle
|
|
des autres virtualiseurs, c'est mieux).
|
|
Ils vont tester proxmox 4, la migration de vm et le grub-install.
|
|
|
|
### VM pour l'Ares
|
|
|
|
L'ARES (Association Réseaux Enfaitonensaitrien Saclay), nouvellement fondée,
|
|
demande une VM.
|
|
|
|
Usage :
|
|
|
|
* site internet
|
|
* serveur mail
|
|
* archive (de quoi, on ne sait pas trop…)
|
|
* accès ldap centralisé (projet)
|
|
|
|
Entre 6 et 10 Go d'espace disque, 256-500 Mo de ram et 1 cœurs devraient
|
|
suffire.
|
|
|
|
On tranche sur 8 Go de disque et 512 Mo de RAM.
|
|
|
|
### Question diverses
|
|
|
|
#### Routeur
|
|
|
|
Il a plus de RAM ou… c'est autre chose ?
|
|
|
|
#### Nols
|
|
|
|
Maintenance pendant les vacances de Noël ?
|
|
|
|
#### Crans Vacances
|
|
|
|
Remplir la page wiki !!
|
|
|
|
#### RTC
|
|
|
|
Charlie veut bien prendre la succession.
|