# Réunion Nounous * Date : Jeudi 4 avril 2013 * Lieu : Condorcet * Début : 19h30 * Fin : 21h34 ## Présents * Daniel Stan * Lucas Serrano * Pauline Pommeret * Raphaël-David Lasseri * Thomas Epalle * Valentin Samir * Vincent Guiraud * Vincent Le Gallic ## Ordre du jour ### Pénurie d'IPv4 Valentin a fait un petit ménage dans les IP wifis, nous sommes passés de 98% à 92% : C'est néanmoins préoccupant. 19 "personnes" sans aucuns droits possèdent plus de 5 machines, 42 en ont plus de 4 machines wifi. On peut supprimer les machines qui ne se sont pas connectées depuis un certain temps (en parsant les logs d'authentification wifi) ou donner des IP dynamiques en wifi. Lors du changement de bornes, la même IP serait attribuée. La deuxième option est plus difficile à mettre en place. La première solution est plus simple à mettre en place mais elle est moins efficace. Valentin pense que ça prendra 1h30 à une nounou, un apprenti peut être encadré pour faire le script. Qu'est ce qu'une machine sans activité ? Pour l'instant, c'est 1 an. On peut envisager d'envoyer un mail aux propriétaires des machines qui ne se sont pas connectées en wifi depuis {{{n}}} mois leur demandant s'ils souhaitent toujours conserver cette machine (par exemple en cas de stage de plusieurs mois). Lorsque la machine s'authentifie à freeradius, si elle n'a pas d'IP, elle bascule sur Cr@ns-accueil ("tu n'as pas d'IP attribuée, clique ici pour en obtenir une"). "Cela demande un travail non nul" (Daniel). L'ancien binding LDAP présuppose qu'une machine a une unique IP. Mettre une IP par défaut, c'est mal et ça prendra autant de temps que de patcher l'ancien binding. Est-ce qu'on s'accélère pour mettre en place l'IPv6-only sur le wifi ? Daniel suggère de partager le travail pour que ça aille plus vite : la partie création de machine sur l'intranet, le taggage de vlan sur les bornes et freeradius, le parefeu, etc. (NB: on en peut pas mettre les IPv6-only et les IPv4 et IPv6 sur le même réseau, sinon tout devient IPv6-only.) Il ne faut pas lancer le script qui supprime les IP avant que les adhérents aient la possibilité de récupérer une IP. Il faudra également envoyer un mail aux adhérents leur expliquant tout ça. Il faut faire un script qui lit les logs de l'authentification wifi et met à jour une base de données. Thomas, Lucas et Pauline sont motivés, Daniel se charge de les coacher, de les motiver et de les inspirer. ### Nouveau firewall Valentin a commencé à réécrire le firewall IPv4, en utilisant le nouveau binding (optimisation mémoire de lc_ldap à la clé \o/) en le remettant au propre. Il est conçu pour faciliter la mise à jour des blacklist et la gestion de la QoS (partage et limitation des débits). Il se génère aussi plus vite que l'ancien. Actuellement, il est assez sale et illisible, à cause des rajouts successif de petits bouts de-ci de-là depuis … longtemps. Il y a un pare-feu sur komaz mais aussi sur zamok par exemple (qui évite que les adhérents déconnectés puissent l'utiliser comme proxy) , et il faut les réécrire. Ce sera potentiellement plus simple. Il faut tester le nouveau pare-feu de komaz, à une heure où il n'y a pas trop de monde. Valentin est confiant, en particulier sur la vitesse de génération. {{{tc}}} (qui gère la QoS) ne plante pas. Si la documentation est correcte, il y aura (grosso modo) une seule règle de classification des paquets (par {{{tc}}}) au lieu de 7000, au prix d'une légère différence au niveau des règles de partage: le débit sera partagé par machine au lieu d'un partage par adhérent (ce qui est équivalent dans la majorité des cas). Il faut changer de pare-feu sous komaz avant le passage à {{{wheezy}}}, parce que l'ancien ne marchera plus ! A priori, sous {{{wheezy}}}, il n'y aura qu'à appliquer la configuration d'{{{iptables}}}, ce qui sera plus efficace que la façon de faire actuelle. ### WiFi #### Avancement La couverture wifi au H a été grandement amélioré avec l'ajout de 4 nouvelles bornes wifi. Le J est en cours de couverture (Ariane, Thomas, Vincent Guiraud et Raphaël-David continuent ce dimanche). Il reste le G, le C, et à terminer le A et B. Quitte à changer les bornes du C, il faudra changer le switch dans le local ménage/électrique du 5C (les switchs Dlink ne supportent pas le multicast). #### Tests de couverture au PdJ Il faut faire des tests de couverture au PdJ afin de prévoir le nombre de bornes à commander. Cela consiste à poser une borne et regarder jusqu'où on arrive à la capter. Il faut voir avec la DSI les modèles de bornes qu'elle compte acheter afin d'envisager une commande groupée. Daniel a un coup de cœur pour les Ubiquiti UniFi Long Range avec 2 antennes (même prix que les bornes actuelles mais plus puissantes). Si l'on achète des bornes, on pourrait en prévoir pour le plafond de la salle de conférence du PdJ (grande capacité d'utilisateurs). #### Parlons CROUS Un habitant du rdc du bâtiment M veut qu'on arrive à tirer un câble jusque chez lui et passer sur le brassage Cr@ns. Mais, c'est manifestement interdit. Il ne capte pas non plus sur le wifi chez lui. Au bâtiment H, un câble a été tiré à l'arrache par le CROUS il y a un peu plus d'un an. Cette personne est adhérente au CROUS, il faut lui suggérer d'appeler la hotline. Nous ne sommes, selon la charte Crans-CROUS-ENS, chargés que du brassage et pas de l'entretien des câbles et des prises. Effectivement, il s'agit de propriétés du CROUS. ### Miroirs #### Debian officiel Valentin et Raphaël-David sont passés à la DSI au sujet de la gestion du miroir Debian officiel de l'ENS. Il suffit donc d'envoyer un mail disant que l'on a changé de machines puis prévenir la DSI. Il faut faire disparaître webb.ens-cachan.fr dans les listes des miroirs. Il faut faire pointer {{{debian.ens-cachan.fr}}} vers notre miroir Debian. Les {{{iso}}} Debian prennent énormément de place, mais a priori nous ne sommes pas obligés de les avoir. (ouf !) Notre miroir supporte la charge, s'il est plébiscité on pourrait envisager de rajouter de la RAM à Charybde. Charybde ne sera plus bridé. #### VideoLAN Nous étions miroir de VidéoLAN par le passé, le dépôt vlc est d'ailleurs toujours synchronisé sur notre ftp. Ils demandent à faire revivre le partenariat. Le problème est qu'ils souhaiteraient une connectivité gigabit ce qui n'est actuellement pas le cas. On leur répond que nous sommes d'accord pour devenir miroir officiel dans la limite de nos moyens (bande passante limitée). ### Contrat Mécénat de Free Un contrat de mécénat a été passé avec la fondation d'entreprise Free, qui nous fournit gracieusement deux serveurs (Dell, 16 Go de RAM, 2To, Xeon E3 2.4GHz). Parmis les projets de ces serveurs : NFS des adhérents, virtualisation de machines pour les clubs, transcodage vers la TV]]. ### Renouvellement des serveurs TV Les serveurs TV actuels sont très vieux et meurent les uns après les autres. Une alternative à base de raspberry pi a été envisagée en vain. On s'oriente donc plutôt vers une solution similaire avec des tours récentes Il faut préparer un devis pour le jeudi 11 avril 2013]. Daniel s'en charge. ### Rencontre avec MiNET Il faudrait préparer des présentations sur ce que l'on fait au Cr@ns, ils le verront aussi de leur côté. On pourrait parler du service d'impression, séparation administratif et technique, fonctionnement général, nos perspectives et envies (demander à Gaétan, formation 1ères années). Au vu de la disponibilité générale et des autres évènements (samedi plateau le 20, journées des M2, interludes le week-end du 27), il est envisagé d'organiser cet événement dans l'après-midi du dimanche 21 avril. On demande la Kfet au BdE. ### Questions diverses #### Analyse AntiVirus des mails Pauline se demande pourquoi le Cr@ns n'analyse plus les mails en vue d'une détection de virus. Valentin répond que les virus par mail ont pratiquement disparut d'après les statistiques de scan d'amavis/clamav et les utilisateurs ont appris leur existence. #### Nagios Faut faire des tests. #### DomU de test Il est décidé de créer un domU sans adm où les apprentis sont root et peuvent faire des tests.