Wiki de FedeRez

Cette page est en lecture seule. Vous pouvez afficher le texte source, mais ne pourrez pas le modifier. Contactez votre administrateur si vous pensez qu'il s'agit d'une erreur.
====== Première édition ======
===== FedeRez =====
==== Bureau 2013/04/09 ====
Une première réunion du bureau a eu lieu le 9 Avril en utilisant Google Hangout. La présidente, après plusieurs problèmes a pu nous rejoindre.

Les points abordés lors cette réunions étaient:
  * Retour sur l'AG
  * Relance des différents membres
  * Mise en place de l'équipe Technique
  * Migration banque
  * Intégration de la RH

Il a été décidé lors ce cette réunion de la mise en place d'un deuxième événement annuel, aux alentours d'Halloween pour pouvoir présenter plus tôt dans l'année Federez aux nouveaux arrivants dans nos assos respectives, et d'alterner des événements Paris / Province.

De plus, afin d'éviter les trolls et des blocages pour la mise en place de solutions, il a été décidé que toute proposition n'ayant pas reçu de remarque constructive au bout d'une semaine sera mise en place.

==== Equipe Technique ====
L'[[federez:admin|équipe technique]] de FedeRez est toujours en action pour remonter un SI pour FedeRez efficace et stable.

Ces derniers mois deux des trois serveurs de FedeRez tombèrent en rade, l'un d'entre-eux emportant le serveur LDAP ainsi que son interface web maison dans sa chute.

Depuis lors, le [[federez:services:ldap|LDAP]] a été remis en place et une [[https://ldap.federez.net/|nouvelle interface d'administration]] a été créée from scratch par bbc.

Afin de mieux gérer les pertes de serveurs potentielles, un [[federez:services:backup|système de sauvegarde]] proposé par zertrin est en cours de mise en place.

D'autre part, Nit s'occupe actuellement d'implémenter DNSSEC pour les domaines de FedeRez.

===== Aurore =====
  * développement d'une interface de gestion d'utilisateurs
Nous sommes en train de réaliser un panel d'admin pour gérer les connexions internet de toutes les résidences composant Aurore. Ainsi, cela permet une harmonisation de toutes les infrastructures et permettra de faciliter l'administration par les bureaux des associations en début d'année.
  * projet de bornes WiFi
  * réalisation d'une convention tripartite CROUS - DI Paris-Sud - Aurore
  * passage sur un proxy transparent
  * augmentation de la bande passante

===== Cr@ns =====
Concernant l'architecture du Réseau au Crans, le Crans fournit internet
à 1200 chambres sur le campus du CROUS de Cachan, pour mener à bien
cette tâche, nous possédons à peu près 20 machines physiques, 22
machines virtuelles, un dédié ovh et une freebox.

Voici les machines critiques au fonctionnement en service minimum du Crans.

Random :
  * Une soixantaine de switchs, dont un coeur de réseau au doux nom de backbone.
  * nols : baie de disques iSCSI

Serveurs :
 [u] : virtuelle
 [c] : critique

  * zbee : serveur nfs [c]
  * fy : dom0 sous xen (migration possible des domu vers fz) [c]
  * fz : dom0 sous xen (migration possible des domu vers fy) [c]
  * vert/ldap : serveur ldap [cu]
  * thot : serveur postgresql (logs + upload + prises/chambres + intranet2 (django). [c]
  * radius : serveur radius filaire [cu]
  * dhcp : serveur dhcp [u]
  * eap : serveur radius wifi, réplica LDAP [cu]
  * komaz : routeur [c]
  * sable : dns primaire, serveur radius secondaire, réplica LDAP [c]
  * charybde : résolveur récursif, ftp, PXE [c]
  * babar : serveur de backups, réplica LDAP [c]

Voici également un récapitulatif (non nécessairement exhaustif) des services :

  * Internet (filaire et wifi)
  * (Web)Mails
  * Intranet{1,2}
  * Impression à prix presque coûtant
  * (Web)news
  * (Web)IRC
  * Wiki
  * Mailing-lists
  * VoIP
  * Jabber
  * (Web)TV par le réseau
  * ...

Parlons maintenant des événements du mois d'avril : le dimanche 21 avril, nous avons rencontré l'association MiNET nous venant tout droit de Télécom SudParis, Aurore, venant d'Orsay, Arise, venant d'Evry, et
Rézo, de Supélec.

Ces associations ont pu profiter d'un barbecue maison, puis nous avons profité de l'après midi pour se présenter et parler de nos associations, ainsi que de technique.

MiNET a pu nous présenter leur service d'administration des adhérents, géré via un Intranet (powered by Ruby on Rails), et ils ont pu également nous présenter Proxmox VE, un hyperviseur hybride, permettant de lancer en parallèle des machines kvm et OpenVZ. Leurs disques étaient stockés sur un NAS, sur des partitions ZFS, partagées en NFS.

Cela nous a poussés à faire quelques tests de virtualisation. En effet, le Crans utilise Xen depuis 2008 en tant qu'hyperviseur. À la suite de l'entrevue avec MiNET, nous avons essayé Proxmox sur un serveur qui vient de nous être donné par la Fondation Free (il s'appelle kdell).

Il nous est apparu que Proxmox était loin d'être la solution idéale pour les besoins du Crans. Les machines OpenVZ sont pour nous une plus une fonctionnalité qu'un besoin, et la communication entre proxmox et notre baie de disque est limitée au minimum syndical. Sans compter que la version wheezy de proxmox semble encore victime d'instabilités gênantes.

KVM a en revanche retenu notre attention, nous essayerons de savoir s'il peut être plus adapté que XEN, qui semble parfois s’essouffler quant à son développement.

Au rang des évolutions, la politique de contrôle de l'upload a été récemment modifiée. Précédemment, lorsqu'un adhérent dépassait 4Go d'upload sur 24h glissantes, il était déconnecté automatiquement pour une durée de 24h (avec déconnexion manuelle pour 15 jours en cas de double-récidive).


Comme les limitations en débit montant ont été réhaussées par notre DSI, cette déconnexion a été remplacé par un bridage : l'adhérent voit son débit montant placé dans une classe de QoS à plus faible priorité.

Il s'agissait simplement de créer une classe TC limitant le débit à 30 Ko/s, et de placer dynamiquement les machines des adhérents ayant trop uploadé dedans. (ces machines étant groupées dans un IPSet)

Nous en avons profité pour réécrire un firewall IPv4 propre. En essayant de pousser à "l'extérieur" les données variables (typiquement les différents types de déconnexions sont réalisés à l'aide d'IPSets, qui peuvent-être manipulés dynamiquement).


Concernant les API de binding avec les bases LDAP, celle Cr@ns-made que nous utilisons pour nous interfacer avec notre annuaire s'essouffle et on a bien entamé son recodage complet.

Une fois terminé (ou presque), il permettra de porter sur notre nouvel intranet (django) la gestion des comptes des adhérents et donc de mettre définitivement à la poubelle notre ancien intranet (cherrypy, buggué, incompatible avec IE 10 notamment).

Ce binding (http://git.crans.org/?p=lc_ldap.git;a=summary) pourrait être également utilisé pour la gestion du LDAP de FedeRez, non sans un certain nombre de modifications.


NFS : La fondation free étant gentille, nous avons obtenu un second serveur, au doux nom de zbee, nous en avons donc profité pour changer de serveur NFS et au passage, passer celui-ci à Wheezy.

Détail à savoirs si vous avez l'intention de faire le même upgrade :

  * Le comportement par défaut sous wheezy est d'utiliser NFSv4 (ce qui pourrit les communications entre les serveurs, ceux sous wheezy tentant du nfsv4 même si la config n'est pas faite, et ceux sous squeeze n'ayant pas les bons mappings UID/GID)
  * De fait, IDMAPD est activé de force, ce qui a pour effet que la résolution des uid/gid est faite sur le serveur et non pas le client. De nombreux problèmes en ont résulté chez nous justement parce que le serveur n'avait pas les noms de groupes ou d'utilisateurs.

En forçant le NFSv3, on peut contourner le problème. Il suffit pour cela de rajouter l'option "--no-nfs-version 4" à la variable RPCNFSDCOUNT dans le fichier /etc/default/nfs-kernel-server.


Postfix et les spams :

Postfix sous squeeze commence à être clairement dépassé en ce qui concerne les spams. Nous avons entamé des tests sur postscreen, une des nouvelles options de postfix, pour voir à quel point il élimine de façon juste des spams.

Les RBLs seuls ne semblent pas pertinents non plus, soit ils blacklistent les quelquechose-box, soit il est trop facile d'y ajouter des ip.


Enfin, la TV : on a commencé à explorer de nouvelles solutions de diffusion de la TV, car notre matériel actuel se fait très vieillissant (Pentium 4 1Ghz, 256Mo de RAM…). Pour l'instant, on a commandé une carte 4 tuner TNT (TBS6284 DVB-T).

Fonctionnement impecable sur linux (http://linuxtv.org/wiki/index.php/TBS6284 ) même si ce n'est pas
opensource. Avis aux amateurs.

En revanche, pas de trace du multiplex R8, d'autres personnes dans la même situation ?

Le but à terme est de remplacer tous nos serveurs (« la ferme ») de diffusion par un unique, gros, serveur. Avec deux cartes DVB-T, on couvrirait déjà toutes les chaînes de la TNT.

Les admin de MiNET nous ont fait remarquer qu'ils ont eu des problèmes au delà de 7 tuners (prob de udev ?). Il semblerait que ce soit une option du driver.


Un peu d'administratif pour finir, nous avons eu des contacts récents avec SCE. Manifestement, ils sont en pleine refonte des statuts et en cours de changement d'organisation suite à des cafouillages (comprendre : SCE a été associé à une campagne politique, ça passe mal auprès des institutions).

Le dossier écrit après consultation de BR, Via, Aurore, Rezo et du Cr@ns a été transmis à la nouvelle équipe en cours de formation.

Ils ont besoin de bras, donc si vous avez du temps à consacrer à SCE ou des questions, envoyez un mail à pommeret@crans.org (je transmettrais, c'est pas encore très structuré).


Concernant Le Cr@ns et le libre, selon ses statuts, le Cr@ns à pour mission de défendre le logiciel libre, entre autres.

Concrètement, cela passe par :
  * une install-party pour le campus
  * une install-party plus ouverte vers l'extérieur (celle de l'ENS)
  * une adhésion à l'April
  * des séminaires de formation (techniques et grands publics) pour les adhérents mais surtout les "apprentis"
  * une tentative d'infiltration de l'ENS pour former les futures premières années au logiciel libre (en cours)

On infiltre l'ENS, et on vous tient au courant !

===== ECLAIR =====
==== Problèmes actuels ====
  * Pas de convention avec l'école et l'association des élèves. Légalement si on a un problème avec les données des étudiants, personne n'est vraiment responsable. Comme c'est notre matériel, c'est nous qui serons jugés responsables.
  * Manque de connaissances juridiques vis à vis de la CNIL (pour le cloud, pour les accès aux informations privées des élèves dans l'intranet).
  * Manque d'effectifs : nous sommes 6 membres dits actifs, dont seulement la moitié participe à la maintenance et aux projets.

===== INP-net =====
Projet en cours :

  * Deux nouveaux serveurs de fichiers, avec les caractéristiques suivantes :
    * Réplication avec DRBD
    * Du LVM sur le DRBD
    * Du NFSv4
    * Du FTP (vsFTPd, avec plusieurs vIP et conf associée, lancé par xinetd)
    * Corosync pour gérer tous ça
Il reste un petit peu de conf de Corosync, et 2, 3 bricoles puis passer ça en prod.

  * Création de la première VM sur notre serveur en datacenter. Voici une liste des services devant être mis en place :
    * Serveur mail secondaire (pour le moment seulement backup)
    * LDAP secondaire
    * MySQL secondaire
    * Portail web secondaire
    * DNS

===== I-Resam =====
  * Mise en place d'un serveur redondant pour le Firewall
  * Projet de réécriture du Firewall en python
  * Le projet de remplacement des switchs de la résidence avance lentement mais sûrement
  * Des élections vont être mises en place pour me remplacer en temps que président de l'association suite à ma démission
  * Diverses évolutions de notre site de gestion de membres

===== Maiznet =====
C'est plutôt calme ce dernier mois, les premières années sont revenus de stage début avril et prennent le rythme. Le grand changement, c'est la 3ème ligne ADSL qui a été mise en service. On a eu une petite difficulté car on a 2 adresses IP avec la même passerelle. Du coup, on a jonglé avec les tables de routages virtuelles (setfib sous FreeBSD) et IPFW.

En parallèle, le serveur TV est en cours de migration par un première année. Le projet est presque fini.

Les projets à venir, c'est :
  * La mise en production du LDAP. L'outil est fonctionnel depuis un moment, mais on cherche à le faire mettre en production par un 1A, histoire de le former au passage.
  * L'amélioration du monitoring. Quelques scripts pour monitorer le temps de réponse du DNS, la migration de l'outil existant (Zenoss) sur un nouveau serveur
  * Le test d'un outil pour enregistrer la TNT sur un serveur. Le système doit être interfacé à notre site web. Il est censé être développé depuis un moment, mais celui qui a pris le projet en charge reste très mystérieux sur son avancement, en dehors du fait qu'il avance.

===== ResEl =====
On a quelques projets en cours mais qui n'avancent pas spécialement :
  * QoS : contrôler le débit alloué à un user et donc ne pas avoir de partage par netflow/ip, utiliser tc et htb à l'air d'être une bonne piste, à voir les lags que celà provoquerait d'avoir autant de classes que d'user (à priori la latence augmente assez rapidement d'après certains sites), tout cela pour éviter que quelqu'un n'ouvre 50k connections pour dl plus vite et ne s'approprie toute la bande passante
  * Réplication des données et AoE : Nous disposons actuellement d'un serveur contenant toutes les données pour les VMs, sachant que la plupart des services y ont recourt il est primordial que ces données ne soient pas perdues, ce qui serait le cas si le serveur actuel lachait. Un serveur a donc été acheté, il reste la réplication des données à faire via un lien dédié entre les deux serveurs ainsi qu'un load balancing sur l'AoE
  * NAS : Les sites de club occupent pas mal de place sur le NAS actuel (qui est presque plein), un NAS dédié allègerait la charge du NAS actuel et libèrerait de la place pour nos services. Bref un achat a étudier: quel chassis ? quelle capacité ? quels disques ?

D'autres projets moins urgents sont aussi de la partie, refonte du site web, passerelle ssh pour les utilisateurs ...

===== Supélec Rézo Gif =====
Nous avons plusieurs projets en cours qui avancent chacun à leur vitesse :
  * Refonte du site web pour les adhérents
Développement d'un nouveau site en Symfony2 (framework écrit en PHP), en remplacement de l'ancien site, qui devient impossible à maintenir. Le site permet aux adhérents de gérer des mailings, leurs adresses MAC enregistrées et leur profil sur le trombinoscope et de consulter le calendrier des événements, entre autres.
  * Mise à jour de notre interface d'administration en Ruby On Rails
Migration vers Ruby 2 et Ruby On Rails 4.
  * Mise en place d'un LDAP
L'objectif est d'uniformiser les accès serveurs et .htaccess et d'en simplifier la gestion.
  * Archivage de la mailing de Supélec Rézo à des fins de conservation de l'information pour les générations futures

Également, nous avons en vue dans un futur proche l'organisation d'une install party à Supélec.

===== Supélec Rézo Metz =====
Quelques projets qui n'ont pas beaucoup avancé, entre les examens et les vacances…

Pour commencer,les projets finis récemment :
  * la mise en place du LACP entre la plupart de nos switches. Les principaux liens sont désormais en 3 Gb/s (il fallait faire des épissures sur certaine fibres optiques);
  * le rétablissement de la TV par TNT (10 tuners : 2 carte DVB-T2 TBS6284 et une vieille Hauppauge Nova-T 500 Dual DVB-T ) et la mise en place d'un serveur qui diffuse des chaînes du satellite (12 tuners : 3 cartes DVB-S2 TBS6985).

Ensuite, toujours en projet :
  * la migration et la virtualisation (avec Xen) de la plupart de nos serveurs pour passer à Wheezy;
  * la limitation de débit (car on est censé ne pas dépasser les 100 Mb/s (connexion fournie par Renater)).
  * monitoring : recherche de la solution la plus confortable...

===== VIA Centrale Réseaux =====
Pour ce premier rapport d'activité, afin de mettre en perspective les différents projets que nous avons (ceux-si sont indiqués **EN GRAS**, voici un résumé de la situation à VIA Centrale Réseaux. Nos principaux domaines d’activités sont classifiés en plusieurs catégories ou secteurs :

=== Secteur réseau (appelé “Secteur Diff”) ===
//(ici un petit aperçu : [[http://people.via.ecp.fr/~er11/VIA/plan_reseau/schema-reseau_full.png]])//

C'est historiquement notre "coeur de métier" principal, fournir un accès à Internet à nos 1200 membres. En voici les principaux éléments marquants :
  * 25 routeurs, avec un coeur de réseau BlackDiamond (**projet de renouvellement de ce coeur de réseau**)
  * 15 switchs pour le réseau Wifi formé de 69 bornes avec authentification par Radius
  * 8192 IP publiques (**+ 256 à récupérer**)  : une IP publique est attribuée par adresse MAC, les adresses MAC sont associées à des comptes pour chaque membre. Les IP sont attribuées dans des VLANs, en se basant sur une base de topologie. Cette gestion est assurée par un système que nous avons développé, et qui permet de gérer aussi les cotisations, les connexions/décos, les licences de produits Microsoft, les impressions, les logs de connexion...
  * Systèmes de redondances par une gestion manuelle des VLANs, routage manuel de certains VLANs
  * Gestion du parc de bornes Wifi par une interface Unifi
  * Réseau cuivré parallèle (AOB) pour le management des routeurs (backups des confs, configuration, surveillance de l’état des routeurs, …)
  * Système de surveillance des correspondances numéro de port/adresse MAC (tables ARP) afin d’identifier le spoofing (**à développer davantage**)
  * Monitoring du traffic avec MRTG ([[http://mrtg.via.ecp.fr/]]) , ainsi qu’une Weathermap ([[http://mrtg.via.ecp.fr/weathermap]])
  * Monitoring de l’état des machines avec Icinga avec interfaçage avec Munin pour les alertes mails/IRC
  * Passerelle IPv6 (**projet : avec un nouveau coeur de réseau, on pourra davantage intégrer l'IPv6 sur notre réseau**)
  * Système de bascule vers l’ADSL en cas de coupure de fibre (par modification de règles OSPF sur notre coeur de réseau)
  * **Projet de prendre sa propre fibre pour faire du délestage**


=== Secteur des machines Linux (appelé “Secteur Root”) ===

Au cours de ces dernières années, ce secteur s'est considérablement développé, voici ces principales caractéristiques :
  * Cluster de virtualisation (3 noeuds) sous qemu-kvm, avec réplication par GlusterFS de la conf, utilisation de CLVM avec des volumes iSCSI multipathés sur des SAN avec réplication par DRBD en primary/primary sur du RAID5 matériel : tous nos services sont virtualisés afin d’obtenir une haute disponiblité.
  * Autre machine de virtualisation
  * Système maison de gestions simplifiée de MV (création, migration, ... ) : kvm-wrapper
  * **Projet de virtualisation pour associations** (OpenStack ?)

Nous avons choisi de profiter au maximum de la virtualisation pour séparer nos services, en utilisant une MV par service, par exemple :
  * 2 serveurs DNS, 2 serveurs mails, 1 serveur DHCP, 2 serveurs NTP, 1 serveur RADIUS, serveur de collaboration Pad, 1 serveur d’archives de ML, 1 serveur Git/SVN, 1 Wiki, 1 serveur IRC, 1 serveur Federez, 1 serveur Apache, serveurs LDAP avec réplications, ...
  * Serveur des élèves MyECP : site Web (Symfony) qui propose un ensemble d’outils permettant de contribuer à la vie associative, de gérer les membres grâce à des BDD, LDAP, ...
  * Serveur pour un système de création/gestion de Sites persos avec BDD MySQL pour les membres (en **projet de migration pour une intégration à notre serveur des élèves MyECP**)
  * Service d’impression à distance pour les membres, en cours de redéveloppement
  * Service de ML avec l’interface SYMPA
  * Système d’authentification par CAS
  * Miroirs pour les distributions Linux, noyaux, VideoLAN, ... : http://ftp.via.ecp.fr/
  * Serveur de backups quotidiens et incrémentaux
  * Plateforme de gestion de projet : Redmine
  * Plateforme de monitoring des machines : Munin
  * Divers sites Web (hors MyECP) : le Wiki de VIA, sites de formations, site de VIA, ...

Outre les quelques projets d’améliorations cités ci-dessus, nous avons comme autres projets :

  * **Projet “SMS-UI”** (commencé) : pour envoyer des alertes SMS (monitoring, messages aux membres, …)
  * Début d’un projet de test en “grandeur nature” de la **nouvelle technologie WebRTC** en vue d’une intégration sur notre serveur des élèves, en partenariat avec une startup
  * Projet à venir en élaboration : mise en place d’un **système de Cloud** qui permettra à chaque membre d’avoir une “session” (sous forme de bureau) sur un serveur central (ou distribué), permettant d’accéder à diverses ressources (Vidéos, cours en ligne, sites Web, …)

=== Secteur Firewall ===

Pour la sécurité des membres et de nos serveurs, ainsi que pour le décompte des quotas :

  * Firewall avec règles de sécurités spécifiques à chaque service
  * Surveillance du P2P, mais totalement inefficace...
  * Système de quotas pour les membres
  * **Nouveau système d’accounting** avec diminution du débit en fonction de la consommation, de la disponibilité etc (projet réalisé mais non achevé)

=== Secteur des machines sous Windows (appelé “Secteur NT”) ===

  * Active Directory avec système de réplication : utilisé historiquement pour la gestion des membres, des licences... mais en abandon progressif malheureusement !
  * Partenariat Microsoft pour les licences
  * Site interne de téléchargement de logiciels gratuits et Microsoft, avec gestion des licences


=== Secteur VideoLAN pour la diffusion de la télévision sur le campus ===

  * Diffusion par multicast/annonces SAP de la TNT/Satellite/Radio (depuis la création de VLC à VIA) et diffusion de vidéos en direct : dvblast/minisapserver et vlc
  * **Développement** d'un système de gestion des serveurs de diffusion et des multiplex à diffuser : dvblmgr
  * Audiences des flux Multicast (**en cours d’amélioration**) : RRD des annonces SAP, audiences
  * **Projet de Vidéo à la Demande**

En ce qui concerne notre avenir à Saclay, nous cherchons à **établir des relations avec l'École**, afin de rester un acteur principal à Centrale dans le domaine de l'informatique, du réseau, de l'innovation... et conserver nos domaines d'activité à Saclay.