documentation/compte_rendus/2014_10_23.md

132 lines
5.6 KiB
Markdown

# 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.