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