diff --git a/compte_rendus/2003_10_02.md b/compte_rendus/2003_10_02.md new file mode 100644 index 0000000..2e23f8e --- /dev/null +++ b/compte_rendus/2003_10_02.md @@ -0,0 +1,118 @@ +# Réunion IN + +Ce jeudi 2 octobre a eu lieu une internounou. + +## Présents + +* Frédéric Pauget (Fred) +* Manuel Sabban (M@nu) +* Mathieu Segaud (Regala) +* Nicolas Stransky (Nico) +* Sandor Szakacs +* Sébastien Li-Thiao-Te (Sayan) +* Vincent Bernat (`Vince||`) +* Vincent Hanquez (Tab) +* Yves-Laurent Allaert (Manathan, ouvre-bouteille) + +## Élection du RTC + +Le seul candidat est Fred dont le programme est de synchroniser le +travail de chacun. Fred est élu à l'unanimité des nounous présentes. + +## Mailman + +La nouvelle version de mailman est en Français et sera donc installée +à la place de la version actuelle. + +Pour simplifier l'accès à mailman, un virtual host lists.crans.org +dans Apache. Quant à laisser toutes les listes dans un sous-domaine +lists.crans.org, cela n'apporte pour le moment pas d'avantage étant +donné que les noms ne sont pas en collision avec des noms réels. + +Il serait souhaitable de préfixer le nom des mailing lists par la +raison d'être de la liste (club-, ens-). Les listes actuelles seront +éventuellement renommées avec la prochaine version de mailman. Les +archives pouvant prendre trop de place, elles ne seront pas +disponibles pour les ML non CRANS. + +## Script d'inscription nounou et câbleur + +La partie en Perl est à refaire. Il est également possible de +synchroniser les listes avec les groupes grâce à mailman mais cela ne +règle pas entièrement le problème (cf les alias batx). + +## Site web + +Certaines pages ne sont plus à jour. Il serait possible de recruter +une personne pour s'occuper du site web. Certaines pages pourraient +être générées dynamiquement (genre, liste des câbleurs). Un +département de l'ENS pourrait mettre le site du CRANS comme projet ? +Il s'agit seulement de trouver quelqu'un qui fait des mises à jour du +site, ce qui peut être assez inintéressant pour un projet et assez +inadapté. + +## Moteur de recherche news + +Les tac.* expireront au bout de 6 mois. Un moteur de recherche +incrémental sur les news pourrait être installé, comme swish++ qui +devra être interfacé avec le serveur web. Les newsgroups pourront être +accessibles également via une interface web (avec mot de passe depuis +l'extérieur). Reste à trouver quelqu'un pour le faire. + +## Glasnost + +Il refonctionne de nouveau, on continue de l'utiliser jusqu'à la +prochaine upgrade qui foire pour le remplacer par un autre système de +publication, style SPIP, même si celui-ci n'intègre pas de système de +vote. + +## Gestion du FTP + +Le miroir Gentoo prend de plus en plus de place (plus de 33 Go, la +partition est pleine), il faudrait regarder si on peut lui faire +prendre moins de place. Il est possible de racheter un disque dur si +besoin ou alors de virer le miroir Gentoo. Pour se fixer, il sera +souhaitable de faire des statistiques. + +## Scripts de gestions des adhérents + +edit pourrait être modifié pour vérifier que les fichiers sont sous la +bonne forme. L'édition à la main des fichiers sera interdite (plus de +edit). + +## Sayan nounou + +Sayan a installé Tanek qui sert désormais de machine de +sauvegarde. Pour le moment, seuls quelques fichiers systèmes sont +sauvegardés. A terme, il sera possible de sauvegarder mails et homes, +mais il faudra de nouveaux disques (2 nouveaux disques). Le site web +n'est pas encore sauvé, les logs ne sont pas sauvegardés non plus et +il faudrait le faire (squid + postfix). Sayan est passé nounou à +l'unaminité. + +## Switchs + +Les switchs Dlink achetés l'an dernier s'avèrent en fait très chers +comparés à ce qu'on trouve sur le marché, aussi bien chez Dlink que +chez d'autres constructeurs. Par exemple, on trouve le Dlink DES 3226S +à 490 euros HT, c'est la version manageable de ce qu'on a +actuellement. Plus intéressant, 3Com fait le 4226T et 4228G tous les +deux à 490 euros HT. Ils sont tous les deux 24 ports mais à la +différence du Dlink intègrent deux ports gigabits cuivre. En +contrepartie, ils n'ont pas l'agrégation de liens sur les ports +normaux (mais on peut chaîner en gigabit). + +Le 4226T est manageable et peut manager 3 4228G. Son fond de panier +est de 8.8 GBps (comme le DLink). Le 4228G a un fond de panier plus +élevé, la possibilité de mettre deux ports GIBC fibre mais n'est pas +manageable (il dispose tout de fois d'une console série comme les +Dlink que l'on a actuellement). + +Dans le futur, on pourrait donc acheter une combinaison de ces switchs +(ou encore du 4250T, version 48 ports, manageable, mais sans extension +fibre optique) pour mettre dans les bâtiments. Cette possibilité sera +étudiée plus en détails. + +Cerise sur le gâteau, tous ces switchs supportent le multicast. + +La réunion a pris fin vers 22h50. diff --git a/compte_rendus/2003_11_27.md b/compte_rendus/2003_11_27.md new file mode 100644 index 0000000..72caaa7 --- /dev/null +++ b/compte_rendus/2003_11_27.md @@ -0,0 +1,119 @@ +# Réunion IN + +Le 27 novembre 2003 une internounou (réunion privée) s'est tenue. + +Présents : + +* Sébastien Li-Thiao-Té (Sayan) +* Manuel Sabban (M@nu) +* Yves-Laurent Allaert (Manathan) +* Nicolas Sturmel (Personne) +* Frédéric Pauget (Fred) + +Excusés : + +* Nicolas Salles (mo²) +* Nicolas Stransky (Nico) +* Mathieu Segaud (Régala) + +## Bilan sur les switchs HP achétés et avenir + +Bon fonctionnement des switchs au B. L'équipement va être poursuivi au +G et par l'achat d'un backbone gigabit neuf. +A terme les liaisons inter-bat seront Gigabit et toutes les prises +manageables avec filtrage d'IP. + +## Avenir de egon + +L'utilisation de Egon en machine de test est satisfaisant : on ne +change rien. + +## Discussions sur le système de sauvegarde + +Il y a un problème de sychronisation des homes plus particulièrement +concernant les permissions sur les répertoires : la sauvegarde se fait +en root sur zamok mais pas sur tanek ; il n'est pas possible de +redonner les bonnes permissions. + +Solution : sauvgardes sur zamok sans être root mais en étant un user +'normal' appartenant aux groupes de users, les répertoires non +lisibles par cet user seront ignorés. + +Actuellement les mails, les news, le site web, les logs et confs des +serveurs sont sauvegardés régulièrement. Le problème des homes va être +résolus et seront donc sauvegardés. + +## La détection de DHCP 'pirates' et de broswe master samba + +La détection de DHCP est opérationelle, un test est effectué toutes +les 10 minutes. Aucun DHCP pirate détecté. + +Pour le cas des browse master samba, un premier test a montré que le +browse master n'était quasiment jamais zamok. Mais que le nom du le +nom du browse master obtenu ne correspondait pas aux entrées DNS. +La solution envisagée est de construire une table de correspondance en +demandant les noms samba à toutes les machines réseau. Une fois cette +table construite il sera possible de savoir à quel utilisateur +adresser le mail d'avertissement comme quoi sa machine est browse +master à la place de zamok. + +## Les virus + +Il a été décidé de rechercher un antivirus de mail pouvant être +installé au crans. Toutefois il devra être possible aux adhérents de +désactiver se service pour leur compte ; celui-ci sera activé par +défaut. + +## Le PHP sur zamok + +Il est décidé d'étudier la sécurité du PHP sur zamok et le cas échéant +de restreindre son utilisation. + +Digression : le mysql sur zamok : est-ce utile ? voir qui l'utilise et +pourquoi ? + +## Le corbeau + +Les clubs sont actuellement exclus du corbeau et un nouveau corbeau +est dans le nid : son cahier des charges est : + +* Champ From valide depuis la zone crans (mail@crans) +* prévoir une blacklist, +* prévoir une modération du corbeau (lecture du message par +* modérateur _avant_ publication) + +## data.tar + +Explications demandées sur roots. + +## Les anciens comptes sur les machines (ménage dans les users et groupes) + +Il sera procédé un ménage des comptes inutilisés selon la méthode des +années précédents. + +Un ménage des utilisateurs privilégiés est commencé : +la liste des personnes ayant le droit d'édition des sites des clubs et du site +de l'association à été réduite, si vous aviez les droits mais que le ménage ne +vous a pas épargné et que vous en avez besoin, envoyer un mail à nounou. un +ménage a été également effectué dans les administrateurs. + +## moteur de recherche news + +Le moteur est fonctionnel mis à part la visualisation des pièces +jointes non texte. Ce point est en cours d'amélioration (surtout pour +les images). +Une fonctionnalité requise est également la lecture des messages +signés pgp. + +## Clés du B + +Le président à laissé sa clef du 0B au nounous qui pourront mieux s'en +servir en cas de problème. + +## ptrace-kmod.c + +(code permettant de passer root en exploitant une faille de sécurité) + +Le fichier est postérieur à la mise à jour de zamok contre cette +faille. Toutefois une demande d'explication pour la précense de ce +fichier est requise. diff --git a/compte_rendus/2004_03_11.md b/compte_rendus/2004_03_11.md new file mode 100644 index 0000000..26a3426 --- /dev/null +++ b/compte_rendus/2004_03_11.md @@ -0,0 +1,130 @@ +# Réunion IN + +Ce soir, jeudi 11 mars 2004, a eu lieu au PdJ une internounou. + +Présents : + +* Arnaud Sternchüss (Schultzy) +* Benoit Rozel +* Charles Signorini +* Christophe Calvès (Grand Tof) +* Frédéric Pauget (Fred) +* Manuel Sabban (M@nu) +* Mathieu Bérard +* Mathieu Ségaud (Regala) +* Olivier Deleage (O-live) +* Sandor Szakacs +* Sébastien Barthélemy (Seb) +* Sébastien Li-Thiao-Te (Sayan) +* Vincent Bernat (`Vince||`) +* Yohan Le Diraison (Ryo) + +## Passage en testing ? + +Sila étant aussi performant que Egon, Egon pourrait remplacer Sila, +Sila serait passé en testing et en 2.6 et des tests seraient +conduits. Une fois que Sila marchera bien en testing et avec un 2.6, +il reprendra sa place. Egon sera passé en testing avant de remplacer +Sila. + +Pour résoudre les problemes de log actuels de Sila, son immobilisation +pourrait servir également à revoir la taille des partitions. + +Remplacement du FTP d'OpenBSD par ProFTPd. + +## Wifi + +Les bornes Linksys disposent de Linux et il y a sur le web beaucoup de +pages expliquant comment le modifier pour divers besoins. + +La borne pourrait être équipée de IPv6 + IPsec. + +Linksys WP54G + +## Switchs + +Trois nouveaux switchs seraient commandés dont 1 pour le G. Les deux +autres iraient au I en raison de sa position centrale, y compris de +par sa topologie (les fibres pour le H, I et J y arrivent). Le seul +hub qui reste actuellement est au M (en plus du PdJ). Le matériel +inutilisé sera utilisé lors des installs party. + +## Ménage sur les comptes administrateurs + +Les personnes n'ayant pas répondu au dernier mail sur le sujet +perdrons leurs comptes sur le serveur. + +## Todo list + +### Scripts d'adhésion + +Il y a plus de vérifications qu'auparavant. Notamment, les noms des +serveurs ne peuvent plus être pris. Il y a une cinquaintaine de +personnes qui devraient avoir un compte sur zamok et n'en ont pas. Les +autres problèmes actuels ont été passés en revue et les nouveaux +scripts évitent tous ces cas. Le problème des conflits d'alias ont +également été évoqués mais leur résolution n'a pas encore été trouvée. + +Le filtrage par adresse des MAC sera mis en place. Que faire pour que +les cableurs puissent venir tester rapidement ? On peut rediriger sur +une page qui permet à l'utilisateur inconnu de s'identifier avec son +compte zamok. Les cableurs pourront également ajouter des adresses +temporairement (la leur). + +### Moteur de recherche sur les news + +Manathan a conçu un moteur de recherche sur les news qui est quasiment +terminé. Il sera intégré sur zamok au site. Il ne sait pour le moment +pas afficher les pièces jointes. + +### Recherche des mots de passe faible + +Le script est en place, mais il ne tourne pas en permanence. + +(HS : WEI : la roue de la déconnexion (sur une idée de Schultzy)) + +L'idée d'un scan régulier (toutes les semaines ?) est gardée. La seule +action est d'envoyer un mail. + +### Browse master samba + DHCP + +Le premier script utilise smbclient pour prévenir les adhérents et +peut envoyer des mails. Le DHCP envoie des mails aux nounous (à Manu +et Manathan). Ces scripts devraient être déplacées sur d'autres +machines que celles de tests. + +### Sécurisation Apache + +Les scripts PHP des adhérents sont actuellement exécutés par un +utilisateur dédié. + +### Sécurisation PHP + +Peut-on utiliser le safe mode sur zamok ? + +### Chaines MAC-IP + +Le lancement du firewall prend énormément de temps. Manu va ajouter le +code nécessaire pour ajouter ou enlever une correspondance ce qui +éviterait la construction entière de la chaîne de correspondance. + +### Modération automatique des posts dans followup-to + +À faire. + +### Amavis + +Une liste blanche devrait être mise en place. Mais en attendant, +l'antivirus est gardé. Les râleurs peuvent toujours l'améliorer (mais +le laisser fonctionnel). + +### Ménage des comptes inutilisés + +Sandor fera ça rapidement et documentera la procédure. + +### Install Party + +Une réunion sera organisée demain soir au 2B avec notamment la +procédure d'installation. + +La réunion s'est achevée à 21h30. diff --git a/compte_rendus/2004_05_06.md b/compte_rendus/2004_05_06.md new file mode 100644 index 0000000..cdf9e6d --- /dev/null +++ b/compte_rendus/2004_05_06.md @@ -0,0 +1,138 @@ +# Réunion IN + +Ce jeudi 6 mai 2004 s'est déroulée une réunion internounou au Krobot à 21h30. + +## Présents + +* Benoit Rozel +* Fabien Millioz (Mit Mit) +* Sébastien Li-Tao-The (Sayan) +* Julien Ducarne (juliend) +* Arnaud Sternchüss (Schultzy) +* Yohan Le Diraison (Ryo) +* Manuel Sabban (M@nu) +* Mathieu Ségaud (Regala) +* Frédéric Pauget (Fred) +* Yves-Laurent Allaert (Manathan) +* Vincent Bernat (`Vince||`) +* Philippe Gambette (Freecorp) +* Christophe Calvès (Grand Tof) +* Olivier Deleage (O-live) +* Clément Houtmann (ClemHout) +* Charles Signorini + +### Synchronisation + +Un nouveau serveur de sauvegarde a été acheté il y a deux semaines. Il dispose +de 1 To de disque dont environ 695 Go en RAID 5 pour les sauvegardes. Une +sauvegarde journalière est effectuée de : + +* {{{/etc}}}, {{{/boot}}}, le CVS, les paquets installés ce qui fait + environ 3,6 Mo par jour +* Le {{{/home}}}, les mails, les news, le wiki, jabber, les ML, le site + web ; ce qui fait environ 30 Go par jour + +On conserve les 3 derniers dimanche ainsi que la semaine en cours. La mise à +jour se fait par rsync. Une fois par jour, la dernière sauvegarde est +sauvegardée au cas pour éviter de perdre toute une semaine en cas de perte des +données sur les serveurs d'origine. + +### Situation de Debian + +Les serveurs du CRANS sont passés en Debian/Testing qui devait devenir la +prochaine stable assez rapidement. Cela a permis de mettre des 2.6 sur les +serveurs. Debian ne suit pas la GPL mais dispose de son propre manifeste : la +DFSG. Ce manifeste a été précisé récemment par un vote et le kernel, entre +autres, est désormais considéré comme non libre. La Sarge pourrait donc être +retardée d'un an par un tel changement. L'avenir de Debian est du coup assez +mouvementé avec des développeurs qui partent. + +Parmi les alternatives possibles, Open BSD pourrait être une solution. Il est +toutefois beaucoup trop tôt pour s'avancer sur ce point. + +### LDAP + +LDAP est une sorte de base de données permettant de regrouper les informations +sur les utilisateurs donc les adhérents avec de grandes facilités +d'interrogation. Il fonctionne en architecture client/serveur, ce qui évitera +d'avoir à transférer les différents fichiers par scp : chaque machine peut +interroger elle-même la base. Par la suite, il serait aussi possible +d'effectuer les authentifications par LDAP. + +Migration : + +* réécriture des scripts de câblage pour supporter LDAP (ce qui fera du bien de + repartir sur une base plus récente) +* réécriture des scripts de génération des fichiers de configuration (DNS, + DHCP, etc) + +La réécriture permettra aussi de documenter proprement ce qui est fait. Le fait +que les informations soient centralisées facilitera grandement la recherche +d'information : à un adhérent sera attaché toutes les informations qui le +concerne dont l'upload, les virus, etc. + +M@nu se propose pour l'interface GTK. + +### Documentation + +Chaque nounou qui fait quelque chose sur les serveurs doivent faire une +documentation de préférence sur le wiki. Une autre tâche serait de documenter +aussi l'existant quand on en a l'occasion. Une partie de la documentation sur +zamok peut également migrer sur le wiki. + +### Salle de réunion + +Une salle a été demandée pour mettre Pegase mais celui-ci va atterrir au H +quand les nouveaux switchs seront arrivés. Cette salle pourra donc servir de +salle de réunion. + +### Budget + +Pour éviter d'avoir à demander au CA pour des achats mineurs (feutres, têtes de +câble, tableau blanc, processeur), les nounous désirent avoir un budget fixe et +un chéquier pour eux. Le CA se renseigne sur les solutions possibles. Ce point +sera porté à l'OdJ de la réunion CA de lundi. + +'''Moi j'ai du mal à présenter à moi-même les factures...''' -- ClemHout + +### Videolan + +Schultzy va prendre contact avec les types de Videolan. Il y a deux solutions : + +* recevoir le flux de Centrale +* encoder nous mêmes + +Les nouveaux switchs facilitent la diffusion sur le campus, notamment grâce au +multicast. + +M@nu prendra également contact pour proposer d'héberger un miroir Videolan. + +### Sécurisation PHP + +Quelles sont les fonctionnalités voulues ? + +* exécuter des scripts ne nous appartenant pas +* avoir le droit d'exécuter des commandes arbitraires +* autoriser l'ouverture d'URL +* modification des fichiers par PHP ? + +Sayan nous sortira les solutions disponibles. + +### Synchronisation CA + +Que doivent faire les nounous quand il y a un grand désaccord avec le CA, comme +par exemple une divergence importante de point de vue sur le sort d'un +adhérent ? Les demandes doivent être données clairement au CA de façon à ce +qu'il n'y ait pas d'ambiguïté. + +### Divers + +* La blacklist sera accessible au câbleur sur le nouveau système +* Un adhérent veut faire un forum sur zamok et demande l'autorisation et + accepte la surveillance ; toutefois, les nounous n'ont pas le temps + nécessaire pour ça et donc le forum est interdit. +* Le miroir Gentoo est supprimé et personne ne s'est plaint +* Le sondage sur le positionnement des bornes wifi avance tout doucement : le + d'Alembert, la bibli et la Med sont bien placés. + +La réunion a été levée à 23h40. diff --git a/compte_rendus/2006_02_28.md b/compte_rendus/2006_02_28.md new file mode 100644 index 0000000..22a94ef --- /dev/null +++ b/compte_rendus/2006_02_28.md @@ -0,0 +1,82 @@ +# Réunion IN + +Lundi 28 Février 2006 a eu lieu une réunion Internounou à la salle Condorcet +à 19h30. + +## Présents + +* Brice Dubost +* Charles Signorini +* Cyril Cohen +* Étienne Chové +* François Bobot +* Frédéric Pauget +* Grégoire Détrez +* Matthieu Segaud +* Nicolas Salles +* Romain Clément +* Stéphane Glondu +* Vincent Bernat +* Xavier Pessoles + +## Ordre du jour + +* Mise à jour de la CransNostalgie/TodoList +* Élection d'un nouveau RTC + +## Déconnexions pour upload et p2p + +* Mise à jour des sanctions dans la base LDAP + +| | Squid| Komaz | Radius et Ragnarok| +|--------------------|------|-------|-------------------| +| Upload Manuel | (./) | (./) | | +| Upload automatique | (./) | (./) | | +| Virus Manuel | | | (./) | +| Virus automatique | (./) | | | +| P2P Manuel | (./) | (./) | | +| P2P Automatique | (./) | (./) | | +| Mail invalide | (./) | | | +| Warez | (./) | | | + +## Installation de cfengine + +Cfengine n'est pas capable de générer n'importe quels fichiers, en particulier +pour Monit. +Pour l'instant, Bilou continue à générer les fichiers de Monit. +Rédaction de la liste des services à gérer par cfengine. + +## Imprimante réseau + +Problème de l'impression en Portrait / Paysage. +Problème technologique : Bac de finition de l'imprimante. +Question soumise au CA : Choix/Achat un bac de finition HP ? + +## WiFi + +Rien de neuf. +Abandon du L2TP temporaire. +Question au CA : Aller voir le CROUS pour déployer... + +## Ménage du cimetière + +Script sur vert : /etc/cron.daily/nettoie_cimetiere + +## Suppression de WebDav + +Solution trop compliquée à mettre en oeuvre pour le moment. + +## Élection d'un nouveau RTC + +Candidats : + +* Stéphane +* Bilou + +Électeurs : 9 + +* Bilou : 5 +* Stéphane : 3 +* Nul : 1 + +Bilou est élu RTC. diff --git a/compte_rendus/2007_03_01.md b/compte_rendus/2007_03_01.md new file mode 100644 index 0000000..8f11403 --- /dev/null +++ b/compte_rendus/2007_03_01.md @@ -0,0 +1,162 @@ +# Réunion IN + +Réunion technique inter nounous. + +## Réunion + +### Horaires + +* Date : Jeudi 1^er^ mars 2007 +* Début : 19h12 +* Fin : 20h36 +* Lieu : salle de conférence du Pavillon des Jardins + +### Présents + +* Alexandre Bos +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Brice Dubost +* Frédéric Pauget +* Grégoire Détrez +* Jérémie Dimino +* Stéphane Glondu +* Vincent Bernat + +## Ordre du jour + +### Mails invalides + +Alexandre propose une gestion automatisée des mails invalides : quand il y aura +un doute sur la validité d'une adresse mail, ou lors d'un changement d'adresse +mail, un mail de confirmation (à la mailman) sera envoyé avec un lien. Si +l'adresse n'est pas confirmée au bout d'une semaine, l'adhérent serait +déconnecté avec une page explicative sur squid. Accepté à l'unanimité. + +### Serveur de secours extérieur + +Louer une baie pour y mettre notre propre serveur coûte cher et n'est pas +forcément pratique. En revanche, louer un serveur ne coûte pas si +cher (environ 50 € HT par mois) et OVH, par exemple, proposent des services +intéressants (avec de bons échos). On louera donc un serveur dédié chez OVH. +Accepté à l'unanimité. + +### Compte d'impression pour tout le monde + +Les adhérents ne sont pas encore tous au courant de l'existence du service +d'impression, et il a été proposé de créer un compte d'office à tous les +adhérents pour populariser ce service. Cela risque de charger un peu plus les +câbleurs, les procédures de mot de passe peuvent être pénibles... Une idée de +mot de passe généré ou de one-time password a été évoquée, mais +abandonnée : l'adhérent lambda qui se verra imposé un mot de passe pour quelque +chose dont il ne verra pas l'utilité dès son inscription oubliera très +certainement son mot de passe (comme c'est souvent le cas actuellement) et +devra de toute façon repasser à la Kfet. En fait, le service d'impression a été +mis en production la rentrée dernière et n'était pas tout à fait opérationnel à +l'automne 2006, mais on peut le considérer maintenant comme totalement +opérationnel, et une campagne de pub plus poussée sera faite à la prochaine +rentrée (lors du contact de masse avec les adhérents) afin que le service +d'impression soit un peu plus connu. + +Vote : 1 voix pour, 4 contre, 4 sans avis. + +Pour les clubs : on donne la possibilité aux clubs d'imprimer avec leur +compte (mais ce compte n'est créé qu'à la demande). Cela demande encore un peu +de travail sur l'intranet. + +### Solde impression / Note Kfet + +La création d'une « note Crans » pour créditer les soldes d'impression est +abandonnée vu les difficultés à récupérer des sous du BdE de manière générale. +De plus, la rigueur de la gestion des notes Kfet ne correspond pas avec la +politique générale du Crans en matière de sécurité. + +En revanche, il a été envisagé de « vendre » du crédit au BdE afin qu'il le +revende aux adhérents du Crans (du moment que le BdE « prépaye » le Crans). On +pourrait donner une compensation (à négocier) en retour. C'est à discuter avec +le BdE. + +Si le BdE n'est pas d'accord, on en arrête là. + +### Maintien d'Alexandre Bos au poste de nounou + +Il s'agissait d'officialiser la nomination d'Alexandre Bos (qui s'est mis +lui-même les droits nounou) au poste de nounou. Accepté à l'unanimité. + +### Nouveaux serveurs + +Stéphane a appelé Anne Cazalet ce matin ; un devis devrait être reçu avant la +fin de semaine. Anne pourrait venir à la prochaine réunion CA. + +## Impromptu + +### Expiration de la garantie de Pegase + +La garantie de Pegase vient d'expirer, Dell nous propose une extension +à 700 € pour 2 ans de plus. De plus, Dell propose des offres de +renouvellement (jusqu'à 75 % de réduction par rapport au site web). Attention +aux problèmes rencontrés dans le passé avec Dell : adresses, paiement à +l'avance, délais, etc. On n'étend pas la garantie, mais on jette un coup d'œil +aux offres de renouvellement. + +Notre nouveau contact chez Dell : Céline El Bouhali (04 99 75 65 84). + +### SVN vs CVS + +SVN a déjà été testé dans le passé pour le Crans et posait plus de problèmes +que CVS (repository fragile, problème de droits, etc.). Pour les fichiers de +configuration, CVS convient bien et sera conservé. Pour les scripts (en +particulier les projets orthogonaux tels que l'intranet ou le wifi), un système +de versionnement distribué pourra être adopté. Il faudra faire une étude de ces +systèmes (Git/coGITo, Mercurial, etc.). Remarque : TLA est déjà utilisé pour le +wifi. Brice et Grégoire regardent Git. + +### Virtual Hosts pour pages perso + +Il s'agit de rendre accessible les pages perso accessibles via des adresses qui +commencent par autre chose que (par exemple +). La gestion des virtual hosts en crans.org risque de +polluer notre domaine et demande des précautions avec la gestion des conflits +dans le DNS, tout cela pour un intérêt très faible. En revanche, les virtual +hosts hors crans.org demandent un effort minime côté crans, et la configuration +est déjà en place. On autorise donc les virtual hosts pour les noms de domaine +hors crans.org, au cas par cas. + +## CROUS + +### Travaux sur les fibres + +Aux dernières nouvelles, SCIC Habitat prend en charge la réparation en faisant +appel à SPIE Communications. Les travaux commenceront lundi. + +### Clés + +Le CROUS a un exemplaire de toutes nos clés. En cas de réclamation de la part +du CROUS, il faudra leur expliquer qu'on ne peut pas se permettre de distribuer +des clés dès qu'ils perdent la leur et que d'ailleurs, le fait qu'ils perdent +nos clés est inquiétant car l'assurance ne couvrent pas les clés perdues. En +revanche, on leur laisse accéder à nos locaux quand ils veulent (dès qu'ils +préviennent suffisamment à l'avance). Le cas de force majeure est une fausse +excuse car de toute façon, les pompiers accèdent n'importe où sans même se +soucier d'avoir les clés (cas de porte défoncée au C déjà rencontré). + +### Locaux techniques 4I, 4H + +Le CROUS va installer des serrures sur des armoires techniques au 4I et 4H afin +que nous puissions y installer des switchs pour les bornes sur les toits. + +### Problèmes électriques au bâtiment I + +Le local de brassage est sur le même circuit électrique que les prises du +couloir et des autres locaux techniques. Il faudra demander au CROUS un circuit +électrique séparé (s'adresser à Victor) comme ils l'ont fait pour le M et le B. + +## Brainstorming + +* Refaire les scripts de gestion avec une base postgres : ça va pas forcément + résoudre les problèmes, mais ça peut améliorier les performances et ça + peut-être plus marrant plutôt que de déboguer des trucs... la vue ldap est + lente... on attend, il y a autre chose à faire, mais en attendant, on peut + profiler du python pour localiser les goulots d'étranglement +* Avec les nouveaux serveurs, redondance de services (Heartbeat) (plus utile) +* Interaction avec FedeRez ? diff --git a/compte_rendus/2007_03_15.md b/compte_rendus/2007_03_15.md new file mode 100644 index 0000000..943ac2c --- /dev/null +++ b/compte_rendus/2007_03_15.md @@ -0,0 +1,42 @@ +# Réunion IN + +Réunion inter-nounou du jeudi 15 Mars 2007. La réunion aura lieu vers 19 heures +au PdJ. + +Début : -- WikiSgnb <> +Fin : -- WikiSgnb <> + +Présents : + +* Alexandre Bos +* Augustin Parret-Fréaud +* Étienne Chové +* Jérémie Dimino +* Romain Clément +* Stéphane Glondu + +Ordre du jour : + +* Répartition des services sur les nouveaux serveurs : pas de nouveau truc, + voir CransNostalgie/ChangementServeurs +* Sauvegardes physiques (sur disque dur externe ou sur DVD) : l'idée est de + sauvegarder sur un support non accessible logiciellement en cas de + compromission de nos serveurs. Alexandre s'en charge. +* Formulaire de pré-inscription en ligne, et éventuellement paiement en ligne + via intranet. + +Bilans (ou pas) : + +* Mails invalides : en cours +* Serveur de secours extérieur : serveur commandé +* Note Kfet : essai d'une facturation a posteriori du BdE : on donne au BdE la + possibilité de créditer les comptes impression, et on les facture tous les X + jours (avec éventuellement une compensation)... en cas de problèmes + particuliers, on annule le système... il faut l'accord du BdE +* Compte impression pour les clubs +* Git : on risque de se retrouver dans la même situation que le développement + du wifi : seul Vincent savait se servir de tla, et l'utilisation d'un autre + système de versionnement a rebuté les autres. Ou alors, on pourrait tout + passer sous git, ainsi, ça forcera tout le monde a passer à git. On attend + plus d'informations sur git (un séminaire technique, un tutoriel sur le wiki). +* Travaux sur les fibres (./) diff --git a/compte_rendus/2007_03_29.md b/compte_rendus/2007_03_29.md new file mode 100644 index 0000000..58ea020 --- /dev/null +++ b/compte_rendus/2007_03_29.md @@ -0,0 +1,129 @@ +# Réunion inter-nounous + +## Horaires + +* Date : Jeudi 29 mars 2007 +* Début : -- WikiSgnb <> +* Fin : -- WikiSgnb <> +* Lieu : salle Condorcet + +## Présents + +* Alexandre Bos +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Jérémie Dimino +* Stéphane Glondu + +## Ordre du jour + +### Pénurie d'adresses IP wifi + +Problème:: On va bientôt arriver à cours d'adresses IP pour les machines wifi +des adhérents (il en reste 45). + +Solutions possibles:: + +* On a trois /24 inutilisés (138.231.{145,146,147}); on pourrait déplacer le + vlan adm (qui n'est de toute façon pas accessible directement depuis + l'extérieur) dans une plage privée, et élargir le réseau wifi + à 138.231.144.0/21 -> beaucoup de reconfiguration (switchs, serveurs). + * On peut aussi laisser le vlan adm dans son /24, étendre le réseau wifi + à 138.231.144.0/21, tout en continuant de réserver les 256 premières + adresses pour le vlan adm -> solution la plus simple à mettre en œuvre et + la plus raisonnable + * Le réseau wifi est entièrement routé. Vous pouvez + prendre 138.231.147.0/24 et ainsi de suite +* Déplacer les bornes dans un des sous-réseaux inutilisés (les bornes ont-elles + vraiment besoin d'être dans le même sous-réseau que les machines wifi ?) +* Attribuer des IPs dynamiques -> il faudra maintenir des logs des + correspondances MAC-IP, pour que, par exemple, les logs de squid soient utiles +* Mettre les machines wifi dans un sous-réseau privé derrière un NAT +* Restreindre le nombre de machines wifi pour les membres non actifs, mais de + toute façon, il n'y a pas assez d'adresses IP (762) pour chaque adhérent (964) + +### Mails de confirmation + +Mise en œuvre:: + +* les liens qui ont été cliqués ont été logués par apache, ces logs seront + utilisés pour mettre à jour la base LDAP pour ceux pour qui la page de + confirmation n'aurait pas fonctionné +* création d'un service (au sens de generate.py) pour mettre à jour la + base -> élimine (façon de parler) les problèmes de locks +* clarification : le spammage de la nuit dernière est le seul, il avait pour + but d'initialiser le processus; à l'avenir, les mails ne seront envoyés que + suite à un doute quant à la validité d'une adresse mail +* pour les détenteurs de comptes crans : on pourrait exploiter le script de + détection de comptes inactifs et envoyer le lien de confirmation directement + dans le mail de détection d'inactivité -> utiliser mailconf pour confirmer + aussi l'utilisation d'un compte crans + +Choses à améliorer:: + +* encoder l'adresse mail dans l'adresse de retour +* changer l'expéditeur (moi, j'ai rien contre + disconnect -- -- WikiSgnb <>) +* mettre un message plus explicatif + +### Logs + +État des lieux:: Parfois, quelqu'un de non-nounou a besoin de pouvoir accéder à +certains logs. Par exemple, le bureau, pour voir l'utilisation des fichiers +copyrightés, ou un apprenti, pour voir ou tester un script... + +Discussion:: on abandonne le groupe logs et on gère les accès par ACL au cas +par cas. Par contre, il faudrait trouver un moyen de centraliser et suivre +l'attribution des ACLs, sinon on risque de se retrouver avec un tas de fichiers +avec des ACLs « fantômes ». Solutions proposées : + +* un script et/ou fichier de conf commité dans le CVS qui fixe les ACLs (voir + si un tel système n'existe pas déjà) +* effacer toutes les ACLs régulièrement + +### Passage du Père Noël + +On a reçu ce matin ce qui a été commandé le 13 mars, sauf 5 kits POE. Tout le +contenu n'a pas encore été vérifié (en cours). + +Impressions à chaud : + +* Armoire : très classe +* Disques durs : mignons tout plein +* KVM IP : le client est une applet ActiveX. Quelqu'un a-t-il une solution ? + * Il ne cause pas VNC ou rdesktop ? pas documenté en tout + cas -- WikiSgnb <> +* Baptême : le nouveau serveur 8 cœurs a été appelé « fx », approuvé à + l'unanimité des personnes qui étaient d'accord. + +Impressions diverses sur fx : + +* le live-CD d'Ubuntu ne détecte que 3,2 Go de RAM (le BIOS en détecte + bien 4 Go) + * Normal, faut un noyau highmem avec support > 4 Go (sinon, le Go restant + est pour le noyau) +* le centre de contrôle de gnome n'affiche que 6 processeurs (bugreport à + envoyer) +* interface iLO 2 qui obsolète le KVM IP (applet Java cette fois-ci) + * si c'est de l'IPMI, il y a les outils pour dans Debian + +### OVH + +Installé : + +* VPN/CVS/cfengine + +À faire : + +* Correction de la base LDAP (quel est le problème ?) +* Migration du common_etc vers cfengine en cours +* Postfix +* DNS +* Backup sur Pegase +* Munin/Monit +* Fallback du VPN sur la connexion de secours + +### Reporté à plus tard + +* Todolist +* Cableurs diff --git a/compte_rendus/2007_04_03.md b/compte_rendus/2007_04_03.md new file mode 100644 index 0000000..de1fc98 --- /dev/null +++ b/compte_rendus/2007_04_03.md @@ -0,0 +1,66 @@ +# Réunion Inter-nounous + +## Horaires + +* Date : Jeudi 3 mai 2007 +* Début : 19:10 +* Fin : 19:49 +* Lieu : Pavillon des Jardins + +## Présents + +* Alexandre Bos +* Augustin Parret-Fréaud +* Cyril Cohen +* Jérémie Dimino +* Stéphane Glondu + +## Ordre du jour + +### Alexandre + +Mails de confirmation:: Pour éviter les problèmes de locks, on va utiliser des +services (au sens generate.py) pour mettre à jour le champ dans la base. +Alexandre attend plus d'informations au sujet des services. + +CransAdministratif/PreInscription:: Script en PHP5/MySQL en cours de +réalisation par Alexandre. + +### CransNounous/TodoList + +Backuppc sur ovh:: Augustin passe la sauvegarde sur cfengine avant de mettre en +place la sauvegarde d'ovh. + +Cfengine:: Augustin propose de regrouper toutes les classes dans un fichier +cf.class. Cela simplifierait par exemple l'installation de services sur un +nouveau serveur, etc. Adopté. + +Problème de CransWifi sous Linux:: les clients sous Linux ne peuvent pas +installer les dépendances nécessaires pour CransWifi à partir du portail +captif. Solutions envisagées: + +1. donner accès au ftp de sila +1. mirrorer les fichiers dont dépend CransWifi sur ragnarok -> quels + +paquets ? racoon et ipsec-tools +Idéalement, il faudrait le faire pour toutes les distributions. Mais on ne +s'occupera que de Debian et Ubuntu. On opte pour la seconde solution -> Cyril +s'en charge (?) + +Prétraitement arpwatch:: Stéphane a expliqué ses idées. + +DVD admissibles:: On attend les vidéos de NumENS, et les documents de l'ENS. + +### Bonus + +Changement du système de versionnement:: Stéphane a présenté darcs. Cyril et +Augustin ont l'air d'aimer. On laisse mûrir. + +## Annonces + +* Réunions : + * Prochaine réunion inter-nounou : ../Jeudi31Mai2007 + * Prochaine réunion CA : ../Jeudi10Mai2007 + * Précédente réunion inter-nounou : ../Jeudi29Mars2007 + * Précédente réunion CA : ../Jeudi26Avril2007 + * Liste des CR : ComptesRendusCrans diff --git a/compte_rendus/2007_05_31.md b/compte_rendus/2007_05_31.md new file mode 100644 index 0000000..483a4da --- /dev/null +++ b/compte_rendus/2007_05_31.md @@ -0,0 +1,60 @@ +# Réunion inter-nounous + +## Horaires + +* Date : Jeudi 31 juin 2007 +* Début : 19h30 +* Fin : 20h00 +* Lieu : PDJ + +## Présents + +* Alexandre Bos +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Jérémie Dimino +* Stéphane Glondu + +## Brouillon d'ordre du jour + +### Etchisation : état des lieux + +Rouge:: reste amavis à réparer... en attente... + +Zamok:: pourquoi monit considère-t-il toujours qu'apache2 ne tourne pas ? + +Pegase:: à faire (demain soir). + +Proxy:: pourquoi faire passer les adresses en free.fr par ultra ne semble plus +fonctionner ? + +Autres remarques:: + +* l'occupation des /var de rouge et zamok a augmenté significativement +* nscd a tendance à planter sur zamok -> cela explique les problèmes que les + utilisateurs non privilégiés rencontrent ; cela pose aussi des problèmes de + distribution de mails +* pour plus du sûreté : faire en sorte qu'un dysfonctionnement de nscd ne + pénalise pas (presque) tout le monde + +### Pénurie d'adresses wifi + +* À faire, pas dans les priorités. + +### Porter CransWifi sous Windows Vista + +* Il nous faut un Windows Vista... + +### Mettre en place une inscription en ligne + +* Problablement pas pour la prochaine rentrée. + +### Permettre la connexion à la zone ENS uniquement aux normaliens + +* Il faudrait demander à la DSI quels sites filtrer. + +### Impression sur les comptes clubs + +* En cours : chaque club a une liste de responsables impression qui peuvent + imprimer sur son compte depuis l'intranet avec leur login. Pour l'instant, le + système est opérationnel avec un seul responsable par club. diff --git a/compte_rendus/2007_10_25.md b/compte_rendus/2007_10_25.md new file mode 100644 index 0000000..15b6ef0 --- /dev/null +++ b/compte_rendus/2007_10_25.md @@ -0,0 +1,62 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 25 octobre 2007 +* Début : -- WikiSgnb <> +* Fin : -- WikiSgnb <> +* Lieu : Au 2B + +## Présents + +* Alexandre Bos (via Skype) (Skype ça pue -- WikiDim) +* Jérémie Dimino +* Michel Blockelet +* Nicolas Dandrimont +* Pierre Chambart +* Stéphane Glondu +* Valérian Reithinger + +## Ordre du jour + +### Déploiement de bcfg2 + +Déploiement initial toujours en cours par Jérémie. + +### Point sur l'installation de fx + +Pour pouvoir faire mumuse avec Xen sur fx, un compte avec tous les droits sudo +a été créé pour Nicolas. Même si cela lui donne virtuellement les mêmes droits +qu'une nounou, il n'en est pas une. + +À court terme, il faudrait migrer ultra vers le domU secours, renommé titanic +afin de se débarasser d'ultra. À installer et configurer: + +* ldap +* openvpn +* squid + +Alexandre s'en charge en prenant modèle sur ultra. On fait en sorte de +minimiser l'utilisation du NFS sur titanic, donc on ne monte que les homes et +le /var/lib/cvs, et on utilise un checkout pour /usr/scripts. + +### Réorganisation de sila + +On laisse les 100 derniers jours de logs sur sila, et on met les autres sur +vert (fait -- WikiSgnb <>). Pas besoin de +bidouiller avec les partitions, qui pose toutes sortes de problèmes pratiques. + +### Fusion/évolution des quotas + +Le quota passe à 600 Mo soft, 700 Mo hard. À part quelques nounous, ce quota +n'est atteint par personne actuellement. Solution adoptée : les inbox sont +dans /home/mail/login, et /var/mail est un lien symbolique vers /home/mail. + +Fait. -- WikiSgnb <> + +### Système de génération des fiches de déconnexion + +Il faudrait un système comparable à mail_invalide, à savoir la génération de la +page se fait lors de l'exécution d'un script. Intérêt: les dates dans la fiche +correspondraient aux dates effectives de la déconnexion, et peuvent être donc +adaptées si la distribution se fait en retard. diff --git a/compte_rendus/2007_11_08.md b/compte_rendus/2007_11_08.md new file mode 100644 index 0000000..7f32545 --- /dev/null +++ b/compte_rendus/2007_11_08.md @@ -0,0 +1,70 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 8 novembre 2007 +* Début : -- WikiSgnb <> +* Fin : +* Lieu : au PdJ + +## Présents + +* Augustin Parret-Fréaud +* Brice Dubost +* Charles Vallantin-Dulac +* François Bobot +* Jean-Benoist Léger +* Jérémie Dimino +* Nicolas Dandrimont +* Stéphane Glondu + +## Ordre du jour + +### Déploiement de bcfg2 + +Jérémie fait des tests sur des domU de fx. Pour l'instant, on en est au minimum +commun à tous les serveurs. + +### Point sur l'installation de titanic + +Alexandre n'est pas là. En attendant, il faudrait rebrancher ultra-adsl... + +* Désolé, je révise (enfin je devrais) mon partiel de demain. Il y a + essentiellement rien sur titanic. Le réseau est configuré convenablement, + j'ai pas encore réussi à faire marcher le tunnel pour ovh. Il va falloir + faire un proxy transparent pour le https, à moins qu'on veuille faire du nat. + +### Système de génération des fiches de déconnexion + +Voir point suivant. + +### Vlan pour les personnes déconnectées + +Le système de déconnexion avec prévention par fiche papier est trop +contraignant. Il a été suggéré de mettre toutes les personnes déconnectées dans +un vlan à part, une sorte de portail captif, dans lequel les adhérents pourront +être notifiés par une page web de leur déconnexion. Ce vlan séparé pourrait +aussi utilisé à d'autres fins. + +Jben se penchera sur le problème après ses partiels. + +### Install-party + +Projet: on crée un vlan install-party, dans lequel on met un serveur (par +exemple domU de fx) qui fera serveur tftp (pour faire des installs par le +réseau), dhcp, routeur (avec éventuellement nat). + +Autres supports d'installation: clefs usb à préparer, cdroms à graver. On +privilégiera le boot par réseau. Attention aux Windows Vista, il faudra +utiliser l'outil Windows pour le repartitionnement. + +### Système de versionnement + +On décide à l'unanimité de migrer vers darcs. Stéphane s'occupe de faire un +tutorial sur le wiki pour le crans. On commence avec le /usr/scripts. + +### Migration vers Postgresql + +Brainstorming, cf CransNostalgie/MigrationPostgresql + +À suivre diff --git a/compte_rendus/2007_11_22.md b/compte_rendus/2007_11_22.md new file mode 100644 index 0000000..aa938a9 --- /dev/null +++ b/compte_rendus/2007_11_22.md @@ -0,0 +1,76 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 22 novembre 2007 +* Début : -- WikiSgnb <> +* Fin : -- WikiSgnb <> +* Lieu : au PdJ + +## Présents + +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Étienne Descamps +* Jean-Benoist Léger +* Jérémie Dimino +* Nicolas Dandrimont +* Romain Clément +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Bilan de l'Install-party + +Cf réunion CA. + +### Mise à disposition d'un serveur de boot par PXE + +Accord de principe pour: on rajoute un champ dans la base, éditable par +intranet et gest_crans. Ceux qui ont le champ adéquat booteront par le réseau. + +Romain s'intéresse au problème et s'occupe de proposer un projet précis. + +### Agrafeuse pour le service d'impression + +Il y a des problèmes d'agrafage actuellement avec l'imprimante. Il faudrait +contacter HP... + +Augustin regarde avec l'ENS si ces derniers n'auraient pas un contrat de +maintenance dont on pourrait bénéficier. Romain contacte Anne pour voir où on +en est avec la garantie. + +L'imprimante du 4J ne peut pas agrafer plus de 50 feuilles à la fois, ce qui +est gênant pour les polycopiés. On pourrait mettre un agrafeuse digne de ce nom +en libre service (pas pour l'embarquer...) dans la partie publique du 4J. Non, +car c'est source de trop nombreux ennuis. + +### Titanic + +Jérémie continue la conf de titanic. + +### Bcfg2 + +Jérémie n'a pas avancé. + +### Système de gestion des problèmes + +À partir des documents fournis par VIA, et d'idées jetées en vrac. Il faut se +rapprocher plus de VIA pour étudier leur solution. On en reparle plus tard. + +### IRC + +Il faudrait faire un peu plus de pub pour l'IRC (en particulier le serveur de +Rezosup). + +### Migration PostgreSQL + +Il faut étudier la base de VIA. + +### Migration du www/wiki vers un domU + +Stéphane propose d'utiliser Ocsigen à la place d'Apache afin de permettre aux +développeurs (d'Ocsigen) de tester Ocsigen sur un « vrai » site. On veillera à +conserver à côté une configuration fonctionnelle d'Apache afin de parer toute +éventualité. diff --git a/compte_rendus/2007_12_06.md b/compte_rendus/2007_12_06.md new file mode 100644 index 0000000..4f55969 --- /dev/null +++ b/compte_rendus/2007_12_06.md @@ -0,0 +1,128 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 6 décembre 2007 +* Début : -- WikiSgnb <> +* Fin : -- WikiSgnb <> +* Lieu : au PdJ + +## Présents + +* Elsa Dupraz +* Jean-Benoist Léger +* Jérémie Dimino +* Michel Blockelet +* Nicolas Dandrimont +* Pierre Chambart +* Stéphane Glondu + +## Réunion + +### Suite des épisodes précédents + +Mise à disposition d'un serveur de boot par PXE:: +Romain n'est pas là. + +Problèmes avec l'imprimante:: +Il y a vraiment un problème d'agrafage ! Stéphane va essayer de constater le +problème lui-même, puis recontacte Anne à ce sujet. + +### Déploiements + +#### Titanic + +Selon Jérémie, le web de la connexion de secours devrait marcher théoriquement, +mais aucun test n'a été réalisé. + +#### Darcs + +Suivi des modifications:: + +Jérémie a backporté darcs-monitor qui permet de suivre les modifications de la +même manière qu'actuellement avec cvs-syncmail. + +Stéphane a converti le /usr/scripts à darcs, mais a constaté que darcs monitor +était vraiment trop lent lorsque le dépôt avait beaucoup de patches, ce qui est +le cas pour /usr/scripts (> 3000 patches). + +À défaut de trouver mieux, on s'orientera vers une solution maison. + +Une fois ce système de notification mis en place, Stéphane s'occupe de migrer +tout ce qu'il y a dans le CVS et de faire la doc sur le wiki. + +#### Bcfg2 + +Jérémie a déjà backporté la version testing (plus de fonctionnalités). Il +envisage de suivre une version plus récente car il souhaite utiliser des +fonctionnalités récentes très intéressantes. + +Jérémie s'occupe de documenter le système sur wiki. + +Déjà fait: Postfix. + +Darcs a été adopté pour le versionnement. + +#### Gestion des adhérents + +Système de gestion des problèmes:: +Tout le monde est convaincu que ce système sera à intégrer à la nouvelle base. + +Support technique:: +Il faudrait former une délégation pour rendre visite à VIA à ce sujet. + +PostgreSQL:: +Brainstorming à continuer. + +#### Gestion des projets + +Trac a été mentionné par Jérémie. Il semble fonctionnel et agréable et il est +programmé en Python. Nicolas va l'installer sur un domU. + +#### Site www/wiki + +On s'orientera vers une implantation FastCGI de MoinMoin. Le module FastCGI +d'Ocsigen est en cours de développement, donc quelques mois à attendre... + +### Divers + +Gestion des secrets:: +Jérémie propose de mettre tout ce qui est "sensible" (secrets, +etc.) dans /etc/crans et de supprimer totalement la présence de fichiers de +secrets dans les mêmes répertoires que les dépôts (ceci afin d'éviter de +commiter des mots de passe accidentellement). Les mots de passe apparaissant +dans les fichiers de conf que l'on souhaiterait versionnés seraient gérés par +bcfg2. + +IRC:: +Les avis sont partagés. On va mettre en place un serveur IRC privé sur le +modèle des news dans un domU, en faire la pub, et voir ce qui se passe. Il +faudrait aussi prévoir un moyen convivial d'y accéder, par exemple avec une +interface web (exécutée côté client, style JS ou Java), dans le même style que +l'interface SSH. + +News:: +Il faudrait les migrer vers un domU, et fournir une interface comme pour IRC +ci-dessus. + +Aslvid:: +Ce serveur dort depuis plusieurs mois. Le proxy est actuellement un réel goulot +d'étranglement sur le réseau. La discussion a fait apparaître comme évidente la +nécessité de le mettre une machine dédiée. Aslvid semble approprié (les +caractéristiques précises sont cependant à vérifier). À l'occasion, il a été +rebaptisé ''sable'' (nom issu d'un brainstorming très poussé). + +Il faudra vraisemblablement rajouter de la RAM à sable. Stéphane prospecte. +Pour les disques (physiquement, 2 disques de 72 Go), on fait 30 Go de +RAID1+LVM (pour système + logs) et le reste pour les spools + swap. + +Ragnarok:: +Il faut le mettre à jour. Mathieu a donné quelques indications. On laisse un +jeune s'en charger. À faire tôt le matin (après avoir dormi). Bien lire et +suivre le release notes. On se donne rdv dimanche matin à 06:00 AM CEST (il +faut être opérationnel, càd après avoir bien dormi) pour faire ça. Il y aura au +moins Stéphane, Nicolas et Jean-Benoist. + +### Attribution de nouveaux droits nounou + +Les droits Nounou ont été attribués à Michel, Jean-Benoist et Nicolas. diff --git a/compte_rendus/2007_12_20.md b/compte_rendus/2007_12_20.md new file mode 100644 index 0000000..b22e178 --- /dev/null +++ b/compte_rendus/2007_12_20.md @@ -0,0 +1,91 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 20 décembre 2007 +* Début : -- WikiSgnb <> +* Fin : -- WikiSgnb <> +* Lieu : au PdJ + +## Présents + +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Jean-Benoist Léger +* Jérémie Dimino +* Michel Blockelet +* Nicolas Dandrimont +* Pierre Chambart +* Stéphane Glondu +* Xavier Lagorce + +## Réunion + +### Bilans + +Problèmes avec l'imprimante:: + +Stéphane va essayer de constater le problème et de contacter HP. + +Connexion de secours:: + +Théoriquement, le proxy et les mails fonctionnent sur la connexion de secours. +On se donne rendez-vous le 6 janvier 2008 à 05:00 (date éventuellement à +modifier) au 2B (si cette connexion de secours n'a pas été sollicitée d'ici +là) pour la tester grandeur nature. + +Bcfg2:: + +Jérémie va faire des pages wiki pour expliquer l'architecture CRANS afin que +d'autres personnes que lui puissent faire quelque chose. + +Effectué:: + +* Mise à jour de ragnarok vers OpenBSD 4.2 +* Migration de komaz sur une nouvelle machine +* Transformation de l'ancien komaz un mirroir Debian local (nommé mdr) + +En cours:: + +* Migration des confs CRANS vers Darcs +* Installation de trac + +En instance:: + +* Migration du www/wiki vers un domU (Stéphane) +* Migration des news +* Installation d'un serveur IRC + +### Déploiements + +#### Redondance des services + +Routeur:: + +Augustin va se renseigner, mais pas tout de suite. Il a entendu parler +de !HeartBeat... + +Proxy:: + +L'interaction avec le proxy transparent n'est pas claire... À méditer. + +#### Encodage + +On passe tout en UTF-8. On fera le switch le 6 janvier (date éventuellement à +modifier). On restera ensuite à l'affût pendant quelques heures pour réparer +éventuellement ce qui est cassé (''a priori'', pas grand chose). + +Une migration vers UTF-8 a déjà été faite dans le passé. Ça pourrait être +intéressant que ceux qui étaient là signalent les problèmes qu'ils auraient +rencontrés. + +### Questions diverses + +Permanence nounou:: + +Augustin, Jérémie, Pierre, Nicolas, Stéphane ne seront pas à Paris (au +moins) du 26 au 31 décembre (CCC). Pendant cette période, Michel restera en +région parisienne, joignable par téléphone portable en cas de pépin. Ce serait +bien qu'il y ait aussi quelqu'un d'autre. Stéphane laissera son trousseau de +clés à la porterie de l'ENS avec une liste de noms de personnes habilitées à +les emprunter. diff --git a/compte_rendus/2008_02_06.md b/compte_rendus/2008_02_06.md new file mode 100644 index 0000000..d5e526d --- /dev/null +++ b/compte_rendus/2008_02_06.md @@ -0,0 +1,112 @@ +# Réunion Nounous + +## Horaires + +* Date : Mercredi 6 Février 2008 +* Début : -- WikiSgnb <> +* Fin : -- WikiSgnb <> +* Lieu : Condorcet + +## Présents + +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* François Bobot +* Jean-Benoist Léger +* Jérémie Dimino +* Michel Blockelet +* Nicolas Dandrimont +* Stéphane Glondu +* Xavier Lagorce + +## Réunion + +### Bilans + +#### BdS + +La paire de fibres utilisée par le BdS est défectueuse (après tests). +Apparemment, une autre paire est libre. Si la seconde paire n'est pas libre, ou +est défectueuse, la DSI nous propose des VLANs (il nous faut le VLAN par +défaut, wifi (3) et hotspot (4)). Affaire à suivre (demain)... + +Régler aussi le problème de la Kokarde. + +En profiter aussi pour tâter le terrain concernant l'emprunt de machines pour +les 10 ans. + +#### OVH + +Il faut le réinstaller: + +* critique: MX secondaire, DNS secondaire, VPN, SQLgrey + +Nicolas a été porté volontaire pour le faire. + +#### Connexion de secours + +Il faudrait rajouter dans la macro wiki autostatus le cas où le switch +automatique a été désactivé. Xavier a été porté volontaire pour le faire. + +#### Renouvellement de la freebox + +Xavier a suggéré de renouveler notre freebox. Les autres présents n'en voient +pas trop l'intérêt. On en reparle dans quelques années. + +#### Serveur IRC + +Il est opérationnel. Il reste encore quelques détails à tuner (mettre des +services, limiter les connexions par IRC et CGI:IRC, ...). On attend un peu +avant de faire la pub. + +#### Switchs + +Bâtiment A: deux switchs morts, remplacés avec ceux récupérés du G. HP a été +contacté pour deux switchs. Un troisième marchotte et fera probablement l'objet +d'un échange. + +Point de détail soulevé par Augustin: quid de la garantie d'intervention sur +site d'HP ? Selon Stéphane, cette garantie concernait les serveurs, mais +personne n'est sûr. + +Il semblerait que la limitation TFTP ait été corrigée dans une version récente +du firmware. Jean-Benoist va se pencher de nouveau sur la mise en place du DHCP +snooping et de la protection ARP. + +#### BCfg2 + +Jérémie a écrit une doc sur le wiki: CransTechnique/Bcfg2. Jérémie coordonne +les efforts. + +#### Migration des news + +Opérationnel, n'importe qui peut tester le nouveau serveur (newnews). Dans une +semaine, si aucun problème ne se manifeste, Michel fera la migration +définitive. Il regarde les différentes interfaces web que l'on pourrait +proposer. + +#### Divers + +En cours:: + +* Migration des confs CRANS vers Darcs (Stéphane) + +En instance:: + +* Problèmes avec l'imprimante: Michel a été porté volontaire pour s'en occuper +* Demande d'un devis pour le nouveau sable (Stéphane) +* Migration du www/wiki vers un domU (Stéphane) +* Installation de nurpawiki (Stéphane) +* Migration vers UTF-8 + +### Remarques diverses + +#### Clefs du 4J + +Il y a 2 clefs dans la nature. Parmi les présents, personne n'a d'idée de leur +localisation. + +#### Nouveaux droits nounou + +Jérémie propose d'accorder les droits nounou à Antoine. Accepté à l'unanimité +des présents. diff --git a/compte_rendus/2008_02_21.md b/compte_rendus/2008_02_21.md new file mode 100644 index 0000000..bead43e --- /dev/null +++ b/compte_rendus/2008_02_21.md @@ -0,0 +1,122 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 21 Février 2008 +* Début : -- WikiSgnb <> +* Fin : -- WikiSgnb <> +* Lieu : Pavillon des Jardins + +## Présents + +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Charles Vallantin-Dulac +* Jean-Benoist Léger +* Jérémie Dimino +* Michel Blockelet +* Nicolas Dandrimont +* Stéphane Glondu +* Xavier Lagorce + +## Réunion + +### BdS + +La connexion du BdS a été coupée à cause d'une boucle au niveau des switchs de +la DSI qui déconnectait le D'Alembert au niveau du backbone. Le problème est +qu'actuellement, le réseau au D'Alembert et au Cournot sont mutuellement +exclusifs. Le réseau du D'Alembert ayant plus d'utilisateurs, il est décidé de +le privilégier. + +### Coopération avec la DSI + +Stuart a demandé une réunion pour faire une mise au point sur les différents +VLANSsdu CRANS et de la DSI. À faire: lui envoyer les VLANs de l'ENS visibles +au 0B et la liste de nos propres VLANs, et le plan de notre réseau. + +### IRC + +SolidIRCd ne répond pas à nos attentes. De nombreux vieux bugs non corrigés, +base de code historique obsolète, il y a mieux actuellement. On va tester avec +unreal. + +### News + +Le nouveau serveur semble fonctionner. Le feu est vert pour la migration. Ici, +migration = rsync du /var/spool/news serveurs arrêtés. + +### Switchs + +Deux nouveaux switchs sont arrivés. Deux anciens sont partis. Deux autres sont +en instance. + +### Coupures de courant + +Il faudrait configurer correctement les serveurs du 0B pour qu'ils s'éteignent +au moment approprié. Bcfg2 semble approprié. Il faut s'arranger pour vert +s'éteigne (proprement) en dernier. + +### Serveurs + +Tous les domUs devront être « documentés » sur la page de leur dom0. Il faut +mettre à jour le wiki. Antoine s'en charge. + +### Wiki/Site web + +De nombreuses personnes présentes trouvent le wiki trop bordélique. Le mélange +sous-arborescence/catégorie nuit à la clarté. Les catégories sont plus souples, +il est proposé de tout migrer vers une architecture à base de catégories... +reste à définir les catégories ! On en rediscute la prochaine fois. Tous les +reponsables wiki seront invités. + +### Imprimante + +Intervention sur site par HP pour matériel hors garantie: 1435 € TTC. +Garantie 3 mois. Le problème actuellement est que les incidents ne sont pas +systématiques, et donc on n'a pas de moyen de reproduire avec certitude et de +vérifier que la réparation est efficace... Il faut déterminer un protocole de +test avec des résultats 100 % caractéristiques des problèmes de l'imprimante. + +### Remplacement du proxy + +* Premier devis pour sable. Il s'agit de la même + machine que komaz (Opteron Dual Core 2,2 GHz), avec 2 Go de RAM. +* Deuxième devis avec processeur Xeon Quad Core. + +### Clefs du 4J + +Il y toujours deux clefs perdues. Plusieurs personnes se sont portées +volontaires pour avoir une clefs du 4J (et les responsabilités qui vont avec). +Il serait de bon goût de la part de certaines personnes qui ont une clefs du 4J +et qui ne s'en servent plus de rendre leur clé. (En particulier, BarBichu va +donner sa clé à Ryo) + +### Diversification des VLANs + +Jérémie fait remarquer qu'une machine sur le VLAN adm a trop de droits, et +qu'il pourrait être judicieux de compartimenter certains services dans des +VLANs séparés. Par exemple, Bcfg2 pourrait être utile même sur des machines qui +ne sont pas sur le VLAN adm. Premier argument contre la multiplication de +VLANs: la maintenabilité. Une autre solution serait de migrer les +services « sûrs » (chiffrés) sur le VLAN normal et d'ainsi limiter le nombre de +machines sur le VLAN adm. Le point négatif: le NFS. À suivre... + +### Bilans divers + +Fait:: + +* Macro autostatus +* Migration des confs CRANS vers Darcs. Signaler tout oubli. + +En cours:: + +* Bcfg2 (tout le monde) +* OVH (Nicolas) +* Jouvence (Elsa) + +En instance:: + +* Migration du www/wiki vers un domU (Stéphane) +* Installation de nurpawiki (Stéphane) +* Migration vers UTF-8 diff --git a/compte_rendus/2008_05_08.md b/compte_rendus/2008_05_08.md new file mode 100644 index 0000000..063c655 --- /dev/null +++ b/compte_rendus/2008_05_08.md @@ -0,0 +1,61 @@ +# Réunion nounous + +* Date : Jeudi 8 mai 2008 +* Début : 20:42 +* Fin : 21:42 +* Lieu : Salle de conférences du Pavillon des Jardins + +## Présents + +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Jean-Benoist Léger +* Johan Grande +* Michel Blockelet +* Nicolas Dandrimont +* Pierre Chambart +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Bilans des derniers incidents et de leur gestion + +Mise à jour de l'IP d'ovh.crans.org:: +Suite à un changement de machine, l'IP d'ovh a changé (08/02/2008). La mise à +jour a été faite dans les DNS du Crans, mais pas chez le registrar. Cet oubli +est passé inaperçu pendant trois mois : sur toutes les machines extérieures +testées, l'IP était à jour. On a donc remis ovh dans les MXs (29/04/2008). +Stéphane s'est aperçu que l'IP n'était pas à jour sur certains serveurs et a +retiré ovh des MXs (06/05/2008). De plus, l'ancienne IP a été réaffectée à une +machine sur laquelle tourne aussi un serveur SMTP qui refusait nos mails. Cela +a eu comme conséquence la « perte » (mais avec notification à l'expéditeur) des +mails qui passaient par un serveur chez ovh qui avait toujours l'ancienne IP, +entre le 29/04 et le 06/05. + +TLS sur ovh.crans.org:: +Les certficats SSL manquaient suite à la réinstallation d'ovh, ce qui a eu pour +conséquence l'échec systématique de la commande STARTTLS, sans conséquence pour +la délivrance des mails. + +Occupation mémoire de la base postgres de sqlgrey:: +Sqlgrey et le processus postgres associé consomment une quantité excessive de +RAM (> 1 Go). On n'a aucune idée de la raison de ce comportement. Cela fait +swapper rouge. Nicolas cherche toujours, mais le projet sqlgrey semble mort et +est écrit en Perl. Il envisage de s'orienter vers une autre solution anti-spam. + +### Installation de sable + +Ça traîne. Nicolas va essayer de boucler ça ce week-end. + +### Imprimante + +Ça traîne. Jean-Benoist a été pingué sur l'affaire. + +### Sémantique de la sanction bloq + +La blackliste squid associée à la sanction bloq semble inutile : cette sanction +provoque déjà la disparition de la machine du DNS, du DHCP, le bannissement au +niveau du radius sur les switchs, etc... bref, la machine n'existe plus. +Stéphane propose de supprimer cette blackliste. Cela nous allègera d'un message +quotidien de cron sur sila. diff --git a/compte_rendus/2008_05_26.md b/compte_rendus/2008_05_26.md new file mode 100644 index 0000000..402cf92 --- /dev/null +++ b/compte_rendus/2008_05_26.md @@ -0,0 +1,198 @@ +# Réunion Nounous + +* Date : Jeudi 26 juin 2008 +* Début : 20h01 +* Fin : 22h18 +* Lieu : 2@B + +## Présents + +### Physiquement + +* Augustin Parret-Fréaud +* Charles Vallantin-Dulac +* Jean-Benoist Leger +* Nicolas Dandrimont +* Xavier Lagorce + +### À distance (gobby) + +* Antoine Durand-Gasselin +* Michel Blockelet +* Vincent Thomas + +## Ordre du jour + +### Redistribution des services de Rouge + +Rouge est actuellement en train de crouler sous les connexions persistantes de +certains clients mail, notamment concernant dovecot, il a donc été décidé de +rééquilibrer les services sur différents serveurs sous-utilisés (p.e. sila) pour +tenter de le décharger et par conséquent d'améliorer la qualité de service du +Cr@ns. + +#### Services redistribuables + +* Bases de données de filtrage (-> Komaz). Augustin s'en occupera après + le 18 juillet. +* Jabber (-> le domU hébergeant le serveur irc avec éventuellement un serveur + irc « de secours » sur mdr en cas de panne). Michel s'en occupe. +* DNS principal sur sila ? On garderait rouge en secondaire... Nicolas s'en + occupe. + +#### Services à migrer si ça pose toujours problème + +* La DB de greylisting... Changer de solution ? Changer de backend (MySQL ?) ? +* Mettre le SMTP principal sur un autre serveur... ? +* Mailman ? + +Au final, il a été décidé de migrer DNS, base de filtrage et Jabber sur des +autres serveurs, et de regarder l'état de la charge de rouge après migration. +Si nécessaire, la migration d'autres services sera alors envisagée dans un +second temps. + +### WiFi en WPA2 + +Ce point n'a pas été abordé à cause de l'absence de Mathieu Segaud. + +### Mise en place d'un VLAN de services gratuits par défaut + +Suite aux nouveaux statuts, nous allons mettre en place un service de connexion +gratuit. + +Pour rappel, ce service de connexion permettra seulement l'accès au Web et aux +ENT. Signature d'une charte après câblage à la Kfet (et inscription des +machines)... +Nous sommes en effet tenus de faire signer une charte selon notre convention +avec la DSI. Il a été décidé de placer ces connexions derrière un NAT. Nous +devons alors garder, de la même manière que pour le VLAN par défaut, une +correspondance entre l'IP locale et le nom de la personne (pour +responsabilisation). Il est donc choisi de placer ces machines sous une IP +locale fixe. + +Des modifications au schéma de la base LDAP sont à prévoir. + +On ne permet pas de préinscription, cela pose en effet certains problèmes +juridiques (connexions entre adhérents non contrôlées et non soumises à +acceptation d'une charte). + +Mise en place de ce système : + +* Modification du script crans. J.Benoist s'en occupe. +* Modification/adaptation de gen_confs des switchs pour placer les gens dans ce + vlan. Idem. +* Mise en place d'un DHCP. Trivial car identique au DHCP actuel, ça sera fait + en même temps que la modif du script Crans. +* Mise en place du NAT. Trivial aussi, Nicolas s'en occupe. + +Il est décidé de ne fournir l'accès au web uniquement (ENT compris) (i.e. pas +au réseau des adhérents payant) via les ports 80 et 443. + +Ce service se limite à ceci, et nous reconsidérerons le panel des services dans +l'éventualité d'un accord avec le CROUS. + +### Raccordement des appartements de l'ENS + +Une réunion a eu lieu avec Stuart !McLellan et Roland Abidos afin de mettre en +place le raccordement des appartements de fonction de l'ENS. A priori, on +passerait sur un VLAN dédié au niveau de l'ENS. +Si une charte est signée, ils pourraient passer par RUBIS selon Stuart. A +l'exception +du Pavillon des Jardins et de la porterie, tous les bâtiments sont câblés et +arrivent +dans un local de brassage, avec des prises libres sur des +switches !ProCurve (un Switch +à rajouter probablement au Cournot). Il faudrait arranger un accès aux logs des +switches concernés, ou _au mieux_ physique (passablement impossible). +Problème de la TV par le réseau : le trafic des appartements passera via +Multiprise_Wifi, +un D-Link... Il faudrait voir à le (faire) changer par un procurve. +L'accès ne sera ouvert qu'après la signature de la convention. + +### Mise en place du VLAN déconnectés + +La mise en place du VLAN déconnecté est retardée à cause de l’impossibilité des +commutateurs à effectuer une mise sur VLan par serveur Radius, feature promise +par HP il y a environ deux ans. + +Une autre possibilité est de faire la mise en place par script, ce qui pose tout +de même un problème pour les switchs non manageables du Pavillon des Jardins, +ainsi +que pour les trucs un peu sales faits pour régler certains problèmes de prises +défectueuses... +Il y aurait donc certains gens non déconnectables automatiquement, problème +analogue +aux désactivations de prise... Il y a aussi quelques erreurs dans la +correspondance +chambre <-> prise. + +Actuellement les déconnectés ont uniquement une page sur squid, et ont toujours +accès au réseau local. La mise en place de ce VLAN est donc nécessaire pour +l'efficacité des sanctions... (la sanction bloq est trop brutale). + +PdJ : on remplace les switches actuels (25 ports + Dlink "multiprise") par les +switches 50 ports dormant au 2@B et 0@C. Nous referons un point pour la +reconnexion +éventuelle du bâtiment G (il en manquera certainement). + +Michel se demande si l'on avait inclus le PDJ dans les services gratuits. +Il regarde. C'est en effet très flou. + +### Logs en tout genre de l'imprimante + +Un script a été écrit pour récupérer les logs de l'imprimante (et ainsi avoir +plus +de pistes pour comprendre pourquoi elle bourre) rien de plus à dire là-dessus +pour +le moment, puisque l'imprimante n'a pas bourré depuis le lancement du script +(Heisenbug). +Il est aussi réalisé des logs de toutes les estimations en vue de réestimer +les coûts de l'impression, qui sont passablement surévalués selon l'audit +effectué +récemment. + +Il est confirmé par J.Benoist que l'intervention effectuée récemment n'a pas +de rapport avec les bourrages, et que la garantie de 3 mois ne peut donc pas +s'appliquer. + +### Questions diverses + +#### Présence de Nounous sur le campus pendant l'été + +Il est rappelé la présence de la page CransVacances... Qui doit être remplie, +ça ne coûte rien et ça évitera des coups de fil pour rien. + +Des mails de rappel seront envoyés aux nounous qui *doivent* s'inscrire. Il sera +également proposé aux apprentis, câbleurs et imprimeurs de s'inscrire afin de +mieux +évaluer la présence des gens sur le campus pendant l'été. + +#### Trafic « geek » sur la ML Bureau + +Il y a sur la mailing-list bureau du passage de mails de surveillance qui +devraient +plutôt aller sur une mailing list telle que disconnect, dans laquelle il +faudrait +d'ailleurs faire le ménage. J.Benoist s'en occupe. + +#### État du 2@B + +Le prochain qui met le 2@B en capharnaüm se fait crever les yeux par J.Benoist +et couper les mains par Nicolas. + +#### Perte ? de messages sur les news + +Les vieux messages ont été purement et simplement perdus... Comment se fait-ce ? +C'est assez bizarre, à priori le expire.ctl, fichier de conf du serveur nntp, a +l'air correct : + +---✂--- <
> + +crans.*:A:never:never:never <
> +tac.*:A:90:150:180 <
> +crans.cvs-checkins:A:30:45:60 <
> + +---✂--- + +En effet, les fora tac.* sont purgés au bout de 180 jours... Mais qu'en est-il +de crans.* ? De plus amples investigations sont à faire. diff --git a/compte_rendus/2008_09_25.md b/compte_rendus/2008_09_25.md new file mode 100644 index 0000000..7125c34 --- /dev/null +++ b/compte_rendus/2008_09_25.md @@ -0,0 +1,232 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 25 septembre 2008 +* Début : <> +* Fin : <> (on a mangé entre temps...) +* Lieu : Pavillon des Jardins + +## Présents + +* Antoine Durand-Gasselin (adg) +* Anne Cazalet (Anne Cazalet) +* Augustin Parret-Fréaud (apf) +* Benoit Barbot +* Jérémie Dimino (dim) +* Johan Grande (jojo) +* Laurent Taylor (marn) +* Mathieu Segaud (Regala) +* Michel Blockelet (!AlphaTigrou) +* Nicolas Dandrimont (olasd) +* Pierre Chambart (Chicco) +* Stéphane Glondu (sgnb) +* Thomas Blanc (pat) +* Vincent Maioli (Neseb) +* Xavier Lagorce (lxir) + +## Ordre du jour + +### Point(s) Matériel + +#### Remplacement de rouge + +On a constaté de nombreux plantages de rouge. Or rouge étant toujours sous +garantie, il serait bon de contacter le sav (rapidement, car celle-ci expire +bientôt). + +SAV HP : 0826 10 49 49 + +Penser à envoyer le numéro de série à Anne. + +#### Remplacements de pegase, de vert + +Les serveurs de données et de sauvegarde se font vieux, il faudrait penser +à les renouveler. + +Pour le remplacement de vert, on a considéré l'investissement dans un SAN/NAS/?, +qui pourrait servir, en plus du stockage des données des adhérents, de stocker +les données concernant les racines des domUs actuels et futurs. + +On partirait a priori sur une solution avec une baie de disques extensible en +fonction des besoins. La question porte alors sur le mode de raccordement des +serveurs : + +* [Fibre Channel](http://en.wikipedia.org/wiki/Fibre_Channel) : + protocole spécifique séparé (performant, bien overkill et + nécessite d'ouvrir les serveurs pour rajouter des cartes spécifiques) +* export NFS (pollue la bande passante, mais vu que les serveurs sont + branchés sur le backbone en gigabit, ce n'est pas limitant) + +Disques SAS (Serial Attached SCSI). Baie de disques. + +Pour le remplacement de pegase, un serveur "pas cher" avec 1 To de stockage +efficace (en raid5). + +* ML110 (Xeon 3065, 570€) + 3 * 500 Go (à 200€ chacun). + +#### Remplacement de l'onduleur du 0B + +2 onduleurs de 3kVA ou un seul onduleur de 5kVA, nécessitant une installation +électrique particulière, donc accord du CROUS etc. + +### WPA2 + +Connexion actuelle : équivalent des VPN professionnels. Les bornes ne font que +transmettre le flux chiffré depuis et à ragnarok. + +Intérêt : pouvoir utiliser le wifi avec *tous* les terminaux classiques (PC +sous Vista --osef, PDA, Smartphones, etc.). + +Connexion WPA : chiffrement sur la borne, et surtout toutes les connexions +seront en clair sur les vlan 3 et 4, cela pose certains problèmes de sécurité. +Sécurité "dans les airs", mais ce n'est pas chiffré sur le fil (entre la borne +et ragnarok) (chiffrer sur le fil et dans les airs, c'est trop pour les bornes). +Il sera toujours possible d'effectuer du chiffrement IPSEC au dessus du WPA. + +Multi-SSID : il faut changer les bornes existant à l'ENS. + +todo: + +* Migrer les bornes actuelles sous Kamikaze 8 +* Faire des tests sur un réseau séparé +* login/mdp: nom de machine/clef (ex-)ipsec + * on ne fait plus (forcément) d'ipsec +* Faire des tests de performance, trop de gens connectés en WPA, ça peut être + très lourd. (2Mo/s max pour chaque borne) + +### Point sur la mise en place de la connexion gratuite + +* Elle est sur le VLAN 6. +* IP privées 10.42.0.0/16 non routées, attribuées aléatoirement (log DHCP + gardés). +* Sable est le seul serveur sur ce VLAN, c'est lui qui fournit tous + +les "services" : le proxy en 80 (port HTTP) et 443 (port HTTPS) (pas pour +l'instant, à faire **vite**) + +* Limitation à 1Mo/s pour l'ensemble des inscrits. +* Il faut qu'il y ait des gens qui s'inscrivent afin d'avoir un minimum de + crédibilité. + +Le vlan 7, d'accueil, récupère toutes les machines qui ne sont pas enregistrées +dans la base (ou qui se branchent quand Radius chie......). Il faudrait ajouter +à la page proxy un commentaire : "si vous êtes déjà inscrit, débranchez et +rebranchez votre cable". + +Il faut faire une page wiki récapitulant les points techniques à ce propos. + +### Retour de sila + +Il est de retour, avec plein de disques... + +On a remonté un FTP avec pour l'instant : + +* une archive debian complète (un jour, on prendra la place du miroir de + l'ENS...) +* l'archive openbsd que l'on avait précédemment +* un miroir de VLC + +Il faut mettre de la QoS sur le FTP pour éviter de péter le réseau de l'ENS lors +des mises à jour de VLC... + +### Changement des disques durs de la ferme + +Cet été, il a fait chaud (encore une fois). Les disques de la ferme sont +fatigués, +il faut les changer. Ils sont au 2@B en attendant que Michel s'en occupe +(avec n apprentis, n > 1, si on rajoute un "e" ça ira plus vite elle connait +déjà la Ferme avec Michel..., exact). + +Mouton est mort, on va le mettre sur orbite. De toute façon il ne servait qu'aux +annonces SAP, qui sont supportées maintenant nativement par MumuDVB, et donc +nous n'avons plus besoin de minisapserver. Il faut déplacer la génération des +vignettes sur MDR, le serveur qui réchauffe inutilement le 4@J actuellement. + +### Passage des serveurs/domUs à Lenny + +À priori, on peut effectuer la transition pour les paquets n'ayant pas de bugs +RC (on va pas beaucoup avancer avec ça...) + +Les serveurs actuellement sous lenny : + +* sila +* munin +* o2 +* xmpp + +Il n'y en a plus qu'une vingtaine à migrer ! On va commencer par la ferme, qui +ne contient pas de service critique... MumuDVB n'est de toute façon pas un +paquet +Debian. Il faudra penser à demander à Braice de vérifier si les noyaux lenny +sont +bons. + +Il faudra veiller à réécrire les fichiers de confs des logiciels qui changeront +de version majeure. Les mettre dans BCfg2 aussi tant qu'à faire. +(exemples : Radius, ...) + +Ça parait être une occasion en or pour finaliser la migration en utf-8. +il ne faut la faire qu'une fois... + *ahaha*. + +Une page wiki devra être mise en place pour recenser les tests de mises à jour +effectués. + +### Organisation des séminaires techniques + +Les séminaires seront organisés tous les mercredis soir à 20h, en salle +Condorcet. + +Le premier (le 1er octobre) sera consacré à une présentation technique globale +du réseau. + +Le séminaire TCP/IP du 8 octobre sera effectué par pat (non, l'autre). + +Le 15 et le 22 octobre seront organisés des séminaires de présentation du +système GNU/Linux, préliminaire à l'install-party du 8 Novembre. + +Thèmes importants à traiter : switches, LDAP, BCfg2, Apache et les trucs HTTP, +OpenBSD et PF, WiFi (Regala), Asterisk et le SIP (Re-Regala), XMPP, ... + +### Questions diverses + +#### Jabber connecté à LDAP + +Un nouveau serveur Jabber a été créé, xmpp.crans.org. Les comptes sur ce serveur +sont en fait les comptes crans. Pour l'instant, tous les alias fonctionnent mais +pointent sur des comptes (listes de contact) différents. Il faudrait faire en +sorte que tous les alias pointent vers le même roster. Malheureusement, il n'y a +pas de méthode standard pour ce faire, des investigations sont en cours. + +Il y a des raisons pour avoir des comptes différents... C'est donc peut-être pas +la peine de fusionner les alias. À voir. + +#### Problème de la transparence avec l'imprimante + +L'imprimante imprime parfois les zones transparentes avec un aplat de +couleur (correspondant à la "couleur de transparence" du fichier), plutôt que +du blanc. + +À moins de flasher l'imprimante, après avoir modifié les sources du +firmware (que nous n'avons pas) nous ne voyons pas ce que nous pouvons faire... + +#### Connexion des appartements de l'ENS + +On va faire passer cette connexion par un vlan particulier, qui nous permettra +de filtrer le contenu qui passerait du réseau Campus au réseau Appartements. + +#### Blocage de bittorrent + +Des abus récents nous poussent à bloquer totalement le trafic bittorrent passant +par komaz. + +#### Commande de LiveCD GNU/Linux + + ne fait que des envois personnels. Il faudrait +rapidement faire une commande de liveCD chez Ikarios, parce que c'est pas cher. +Commande de: + +* 50 LiveCD kikoololbuntu i686 +* 50 LiveCD kikoololbuntu amd64 +* 20 Netinstall debian diff --git a/compte_rendus/2008_10_09.md b/compte_rendus/2008_10_09.md new file mode 100644 index 0000000..62721e0 --- /dev/null +++ b/compte_rendus/2008_10_09.md @@ -0,0 +1,124 @@ +# Réunion Nounous + +## Horaires + +* Date : Jeudi 9 Octobre 2008 +* Début : 20h12 +* Fin : -- WikiNicolasd <> +* Lieu : Pavillon des Jardins + +## Présents + +* Antoine Durand-Gasselin +* Benoît Barbot +* Jérémie Dimino +* Johan Grande +* `man 1 sort` +* Michel Blockelet +* Nicolas Dandrimont +* Xavier Lagorce + +## Ordre du jour + +RAPPEL:: Les données d'accès au proxy sont des données *personnelles* des +adhérents (logs de squid), et les Nounous n'ont à y accéder en aucun cas. Cela +paraissait une évidence pour tout le monde, mais ça ne coûte rien de le +rappeler. + +### Pédalages de rouge dans la semoule + +Ce week-end, il y a eu pas mal de problèmes au niveau du www/wiki, et lundi, par +miracle, tout s'est remis à fonctionner... Redémarrer Apache les refaisait +fonctionner, mais que pendant une vingtaine de minutes. + +Appeler HP pour le SAV n'est possible que si l'on arrive à diagnostiquer un +problème précis et reproductible, ce qui n'est pas le cas actuellement. + +### Migration du www/wiki vers Lenny + +Afin de régler ce problème, Antoine a commencé à regarder comment migrer le wiki +vers un serveur sous lenny. Ce ne sera pas tâche aisée vu que c'est le paquet +avec le plus de modifications locales pour le Cr@ns. + +Howto: + +* Installer apache2, apacheSSL, pythonmodrewrite (et allumer son cerveau) +* sync-er le /var/local/wiki + * il y a un lv sur fx qui s'appelle lvm-wiki (2,5/4Go) +* copier les fichiers de conf de moinmoin (/etc/moin/*) (réfléchir un peu) +* màj les scripts dans /usr/scripts/wiki-lenny + * comprendre comment fonctionne le parser de moinmoin (un peu comme à chaque + +màj) + +Moinmoin et le serveur apache sont configurés sur +le temps qu'on fasse quelques bidouilles sur les plugins munin du crans (parce +que le serveur a apache et est sous lenny). + +### Connexion des appartements de l'ENS + +Il a été décidé de placer ces appartements sur le même VLAN que le BdS (car ce +VLAN circule déjà sur les équipements actifs de l'ENS). Il faudra mettre en +place un firewall entre ce VLAN et le réseau (car le CA a décidé de filtrer le +trafic). Ce réseau passera par la Freebox. + +### Problèmes latents sur le réseau + +#### Wifi + +Le Wifi marche de façon plus ou moins aléatoire. Il faudrait rebooter la plupart +des bornes (cf. autostatus bien rouge). Les bornes en zone CROUS devraient être +rebootables par un apprenti qui n'aura pas le choix. Il parait judicieux, au vu +de certains soucis de configuration de switchs, de vérifier sur quels vlans sont +la prise de chaque borne down et de modifier la base ldap le cas échéant. +Certaines bornes ne semblent pas revenir après un hard reboot; le stock de +bornes du -1I étant fortement diminué, il faudrait voir avec Régala pour l'achat +de nouvelles bornes. + +#### Zamok et libnss-ldap + +On suspecte que libnss-ldap faisait trop de requêtes sur vert, dépassant le +nombre maximal de sockets sur vert. +Libnss-ldapd résout ces problèmes par une séparation claire entre le code de la +bibliothèque nss et la connexion au serveur ldap. Le nombre de sockets ouvertes +est alors maitrisé, puisque la connexion se fait via un démon (nslcd), qui en +outre garde un cache des données lors d'une défaillance du serveur LDAP. + +C'est pour l'instant la solution utilisée sur zamok (et quelques serveurs sous +lenny), et pour l'instant aucun problème n'a été constaté. + +On va certainement passer rouge à cette solution, même si maintenant la charge +sur le serveur LDAP de vert doit avoir fortement diminué. + +#### Bizarreries de l'authentification radius + +Il est constaté un nombre impressionnant de machines qui passent par erreur sur +le vlan d'accueil. Le problème ne vient apparemment pas de radius, les logs sont +OK. Il faudrait refaire de toute façon la redondance de radius et voir, si ça ne +résout pas le problème, à ajouter une rustine par exemple à arpwatch pour +désactiver/réactiver la prise si l'adhérent se retrouve par erreur sur le +vlan 7. + +### Questions diverses + +#### Mise en place et tests du Wifi en WPA2 + +Pour réaliser les tests de WPA2, Régala va utiliser le VLAN 30, libre sur le +réseau Cr@ns et le réseau ENS. En effet, on ne peut pas passer le firewall de +ragnarok en clair sur le vlan 3 actuellement. + +Il faut prévenir la DSI de l'utilisation de ce VLAN. + +#### Problèmes avec les annonces SAP + +Ça m'a l'air de ne pas fonctionner correctement. Braice ? + +#### Limitation de bande passante sur le FTP + +Jérémie n'a pas regardé depuis la dernière release de VLC, le réseau de l'ENS va +bien avec les limitations actuelles par nombre d'utilisateurs connectés. + +#### Migration à l'UTF-8 + +Il faut le faire, en évitant de migrer les services en APF-4242. +La migration naturelle lennyesque continue. diff --git a/compte_rendus/2008_10_22.md b/compte_rendus/2008_10_22.md new file mode 100644 index 0000000..0ad7cb2 --- /dev/null +++ b/compte_rendus/2008_10_22.md @@ -0,0 +1,103 @@ +# Réunion Nounous + +## Horaires + +* Date : Mercredi 22 octobre 2008 +* Début : 19h54 +* Fin : -- WikiNicolasd <> +* Lieu : Salle Condorcet + +## Présents + +* Antoine Durand-Gasselin +* Arnaud Deblonde +* Benoît Barbot +* Jérémie Dimino +* Laurent Taylor +* Michel Blockelet +* Nicolas Bruot +* Nicolas Dandrimont +* Olivier Huber +* Pierre Chambart +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Passage progressif des serveurs à Lenny, et à l'UTF8 + +BOFH excuse #212: +Of course it doesn't work. We've performed a software +upgrade. -- WikiNicolasd <> + +Indice : installer les devscripts des backports, utiliser rc-alert. Dans l'état +actuel, on pourrait mettre à jour zamok. On peut aussi tout simplement copier +le script qui nous intéresse. Il fonctionne sous etch. + +### Migration du wiki + +Deux choses sont à faire : + +* refaire la conf du Cr@ns spécifique (droits spéciaux…) +* refaire les macros qui ne passent pas à la version (aux deux versions en + fait). Il y en a *beaucoup*. + +Certaines syntaxes changent (par exemple, les macros passent sous +forme {{{<>}}} au lieu de {{{[[Macro]]}}}). Un wiki de test est en place +sur munin.crans.org. Pour la migration définitive, on créera un domU (quand la +nouvelle infrastructure sera mise en place). + +### Compte rendu de l'intervention de l'électricien pour le 0@B + +C'est demain. + +### Wifi en WPA2 ? + +Le log irc arrivera dans la soirée... + +### WebRadio (Upload, multicast, branchement de la KoKarde…) + +L'accès serait possible par login/mot de passe (comme les news). Le problème +est que l'audio, c'est *gros* (genre 1 Mo/minute). Il paraitrait étonnant que +la DSI accepte ce type d'upload. Comment font-ils chez VIA ? + +La KoKarde sera câblée sur le vlan BdS/Appartements. Michel s'en occupe. + +### Formulaire de précâblage en ligne + +Ne pas oublier de réfléchir lorsqu'on configure apache. +On devrait partir sur un truc en !CherryPy, un peu comme l'intranet. Xavier se +porte volontaire. + +Il ajoute d'ailleurs qu'en passant, il serait une bonne idée d'ajouter la case +à cocher pour passer une prise sur le vlan install party. Il faudrait que les +switchs soient configurés en conséquence, et que les +images du vlan install party soient tenues à jour plus régulièrement que "quand +on en a besoin". + +### Questions diverses + +#### Venus + +La carte réseau chie dans la compote de pomme. Il faut la changer (la carte +réseau ou la câbleuse). + +#### Réécriture des pages d'aide + +* ''Globalement, rassembler toutes les pages d'aide aux adhérents à un endroit, + kikoololiser l'autostatus, proposer un système de bug-report, etc. C'est + juste une piqûre de rappel.'' + * Bonjour Michel -- WikiNicolasd <> + +Les pages actuelles reflètent un peu le Cr@ns de 2005-2006... Sila est le +proxy, zamok fournit tous les services, la base ldap est sur zamok etc. + +Il faut mettre à jour et réorganiser les pages des arborescences : + +* VieCrans/ +* CransTechnique/ +* CransAdministratif/ + +#### Câblage du personnel de l'ENS + +Rien n'a changé depuis 15 jours. Michel a été porté volontaire. diff --git a/compte_rendus/2008_11_20.md b/compte_rendus/2008_11_20.md new file mode 100644 index 0000000..866cf44 --- /dev/null +++ b/compte_rendus/2008_11_20.md @@ -0,0 +1,141 @@ +# Réunion Nounous + +## Lieu et horaires + +* Lieu : Pavillon des Jardins +* Date : Jeudi 20 novembre 2008 +* Début : 19h51 +* Fin : 21h23 + +## Présents + +* Augustin Parret-Fréaud +* Johan Grande +* Laurent Taylor +* Michel Blockelet +* Nicolas Bruot +* Nicolas Dandrimont +* Olivier Huber +* Xavier Lagorce + +## Ordre du jour + +### Avancement de la mise à jour vers lenny + +La mise à jour vers lenny a commencé (par oie) sur les serveurs de la ferme. +Oie ne boote pas sur le kernel officiel, selon toute évidence à cause des +options un peu foireuses qui permettent déjà que les cartes TV fonctionnent + +Nicolas prévoit de bientôt mettre à jour egon, afin de tester la mise à jour de +certains services comme LDAP, Postfix, PostgreSQL... + +### Planification du remplacement de vert et de pegase + +De nouveaux serveurs ont été commandés (on les recevra d'ici une dizaine de +jours). + +Il y a ainsi : + +* fy : un nouveau dom0 (pour délester fx) +* un nouveau "vert" + +Et pour aller avec : + +* une baie de disques iSCSI, avec deux buts principaux : + * en cas de panne de certains serveurs, permettre à d'autres de toujours + +accéder aux données + +* éviter de gâcher de l'espace disque +* un nouvel onduleur + +On cherche une solution pour économiser sur l'installation électrique pour le +branchement de l'onduleur, la solution proposée par Anne nous semblant vraiment +très onéreuse. + +Liste des services et données à migrer : + +* Sur Pegase : + * Backups de pegase... Il faut donc réinstaller backuppc. + * Serveur RADIUS (attention à la mise à jour, la sémantique du fichier de + conf change) + * LDAP (en relation avec le point précédent) +* Sur vert : + * Le serveur NFS... + * La base LDAP principale... + * BCfg2 + * Le serveur DNS (slave de toutes les zones) +* Sur le nouveau Dom0 : + * un DomU www + * ... + +### Avancement de la migration du wiki + +Il faut faire une double migration (passage à la v1.7 de MoinMoin, de Lenny, et +passer à un DomU), ce qui augmente un peu la charge de travail. + +Le calendrier ne fonctionne pas, MoinMoin semble détecter correctement les pages +à afficher mais n'arrive pas à récupérer les informations dans ces dites pages. + +Les catégories des pages ont aussi des problèmes de fonctionnement (plus ou +moins aléatoires). + +Antoine suggère que la migration est une bonne occasion pour faire un peu de +ménage sur le wiki. + +(Pourquoi est-ce qu'il ne faut pas faire indexer le wiki par google : +VieEns/LesDépartements/DépartementAnglaises…) + +Le séminaire technique sur le wiki sera dans 3 semaines. + +### Avancement de la mise en place du WiFi en WPA2 + +Il est probable que Regala soit en train de flasher une borne au 2B en ce moment +même... Apparemment non. + +### « Formalisation » des droits WebMaster et FtpMaster + +Il serait bon de mettre en place une procédure "automatique" (i.e. LDAPisée) +d'attribution de ces droits. + +### Attribution de nouveaux droits + +Johan est ajouté au groupe mirror sur sila, pour pouvoir gérer les dizaines +d'isos de distributions disponibles sur le FTP. + +Nicolas propose d'ajouter les droits Nounou à Xavier, puisqu'il a montré un an +durant son intérêt et sa motivation. Aucune des nounous présentes (et contactées +précédemment) n'oppose son veto. + +### Organisation de nouveaux séminaires techniques + +Un séminaire sur MoinMoin sera organisé par Antoine dans 3 semaines. + +Inscrivez vos disponibilités sur la +page SéminairesTechniques, pour que votre avis +compte si on les déplace... Il faudra pas venir se plaindre après. + +### Questions diverses + +#### Migration de mouton vers MDR + +En principe, Michel a migré tous les services qu'il faut. Il attend la +vérification de Braice. + +Très bientôt, on aura enfin le silence au 4J... + +#### Router advertisements IPv6 + +Olivier cherche une solution pour éviter que chaque machine qui se branche sur +le réseau récupère 5 adresses IPv6 globales. Cela résoudrait -peut-être- les +problèmes de connexion filaire sous Vista. + +#### Machines extérieures en .crans.org + +Des gens ont demandé la possibilité d'avoir des machines extérieures +en .crans.org . Il faudrait mettre en place : + +* Soit une zone spéciale (.vieux-con.crans.org ?) +* Soit un domaine spécial (crans.eu ?) + +Le domaine crans.eu est commandé chez ovh. diff --git a/compte_rendus/2009_01_15.md b/compte_rendus/2009_01_15.md new file mode 100644 index 0000000..4d218ce --- /dev/null +++ b/compte_rendus/2009_01_15.md @@ -0,0 +1,123 @@ +# Réunion Nounous + +* Date : Jeudi 15 janvier 2009 +* Lieu : Pavillon des Jardins +* Début : 19h45 +* Fin : 21h00 + +## Présents + +* Antoîne Durand-Gasselin +* Johan Grande +* Nicolas Dandrimont +* Stéphane Glondu +* Xavier Lagorce +* Vincent Maioli + +## Ordre du jour + +### Câblage des appartements de l'ENS + +La solution technique retenue est de placer les Appartements derrière un NAT, +sur komaz. + +Le filtrage peer2peer sera en place sur ce nat. Pour le comptage de l'upload, +il faut trouver une solution qui prend en compte le NAT. + +Pour ce qui est de la charte à faire signer à ces nouveaux connectés, la +discussion est reportée au prochain CA. + +### Automatisation de la mise en place des sauvegardes + +La mise en place automatique est lourde à mettre en place, alors que +l'opération pour un serveur consiste en la copie d'un fichier sur babar. Il +suffit donc de ne pas oublier cette étape. + +### « ToDo list » en cas de panne + +Il parait difficile de faire une checklist des choses à vérifier en cas de +panne, le nombre de serveurs et de services étant faramineux. + +Il sera mis en place une page wiki contenant différents tutoriels, par exemple +comment redémarrer le 0B en cas de panne, etc. Il faudra veiller à ce que les +informations contenues dans cette page soient à jour en permanence. + +Si les membres du CA sont prêts à mettre en place une liste de choses à faire +en cas d'absence des Nounous, les Nounous sont prêtes à les aider, mais ne +voient pas l'intérêt de la mettre en place en l'état actuel des choses. + +### Bilan de l'installation des nouveaux serveurs + +#### Slon + +La nouvelle baie de disques est installée. Les données des !DomUs sont dessus. +Il reste à déplacer les homes. Pour servir ces derniers, des tests vont être +effectués sur un DomU. + +#### Fy + +Fy est installé, il va chercher sa racine sur la baie de disques. Tous +les !DomUs sont dessus actuellement en attendant de réinstaller Fx. + +#### Babar + +Il est installé et fonctionnel. Il reste à le déplacer à son emplacement +physique définitif. + +Petit commentaire sur l'installation : Ne mettre qu'une partition / de 2 Go sur +un disque de 250 était surprenant, considérant que les métadonnées de backuppc +sont stockées dans un arbre de millions de petits fichiers dans /var. Que ne +fut ma surprise quand j'ai constaté que la racine était pleine depuis plus +d'une semaine... + +### Récupération du crash de fx + +Aucun test n'a été effectué depuis le crash. Les disques durs doivent être +vérifiés (smart test etc.), en vue d'un échange en cas de problème. + +Le DomU irc est toujours cassé, il faut le réinstaller. + +### Avancement des mises à jour vers lenny + +Tous les serveurs non critiques ont été migrés sous lenny. Pour les serveurs +principaux restant, l'ordre retenu de migration est le suivant : + +* komaz +* sable +* rouge +* zamok + +Ce qui advient de vert sera déterminé plus tard (selon les tests du NFS sur un +domU). + +### Projets en cours ou futurs + +#### BCfg2 + +Petit à petit, le mail de statistiques BCfg2 se vide... + +#### Formulaire de préinscription en ligne + +Xavier commence à s'y mettre. + +#### Détection des router-advertisements + +Olivier fait semblant de réviser, le point est reporté à la prochaine réunion. + +#### Bugs de l'intranet + +* L'intranet perd la "connexion à l'imprimante" et n'arrive pas à la rétablir +* Les paiements paypal doivent être validés manuellement + +Il faudrait que quelqu'un avec des points de karma en cherrypy y regarde de +plus près. + +#### munin + +Le domU munin a un gros souci d'i/o. Le service sera transféré sur pegase +lorsque la migration des sauvegardes sera complète. + +#### Modifications qui trainent + +Il est rappelé que les modifications aux différents dépôts doivent être +commitées rapidement... diff --git a/compte_rendus/2009_01_29.md b/compte_rendus/2009_01_29.md new file mode 100644 index 0000000..5fa9b29 --- /dev/null +++ b/compte_rendus/2009_01_29.md @@ -0,0 +1,217 @@ +# Réunion Nounous + +* Date : Jeudi 29 Janvier 2009 +* Lieu : PdJ +* Début : 20h02 +* Fin : 21h30 + +## Présents + +* Antoine Durand-Gasselin +* Arnaud Deblonde +* Johan Grande +* Michel Blockelet +* Olivier Huber +* Xavier Lagorce + +## Ordre du jour + +### Suite du câblage des nouveaux appartements de l'ENS + +Il serait bon d'avoir une idée de l'infrastructure avant que la DSI ne nous +donne un numéro de VLAN. Idéalement, il serait bon d'être prêts rapidement. +Nicolas semble avoir commencé à réfléchir à la question, et maintenant qu'il +est en stage, il a plein de temps devant lui ! pour mettre tout celà en place :) + +Il faudrait aussi adapter la base LDAP à ces nouveaux adhérents, et modifier les +règles de filtrage d'upload (faudra voir si la solution en place marchera ootb). + +En tout cas, il faudra soumettre ces nouveaux adhérents aux mêmes restrictions +que ceux passant par RENATER, la connexion utilisée étant tout de même +mutualisée. + +### Attribution de nouveaux droits + +On a un apprenti, Olivier Huber, qui a fait plein de trucs. Les nounous +présentes sont favorables à sa nomination en tant que nounou (ça sera plus +simple pour tout le monde). + +D'ailleurs, ça me fait penser qu'on a un serveur sous OpenBSD 4.2 à mettre à +jour ... + +### Achat de matériel électrique + +Pour le problème de retour de l'électricité au 0B, on prévoit d'acheter deux +multiprises ssh. Ce n'est pas donné mais ce n'est pas non plus si cher que ça. +On en reparlera à la prochaine réunion CA. + +De plus, ça peut se révéler pratique. + +### La ferme + +Ces derniers temps, la ferme a connu beaucoup +d'histoires (). + +Tout d'abord, mouton est mort; ses services ont été migrés sur mdr (qui +s'appelle maintenant aussi vache.ferme), et quelques modifications ont été +apportées aux scripts pour qu'ils fonctionnent avec la nouvelle version de +MumuDVB. + +Par ailleurs, Braice a remis les serveurs dans un état "stable", comme il nous +l'explique : + +"Avant, on utilisait des noyaux persos et un udev 054 compile statiquement avec +la klibc. Le noyau actuel de etch ne supporte pas toutes les cartes, mais le +2.6.24-etchnhalf si. + +Il y a eu plusieurs problemes lors de la mise à jour : + +* la migration de udev +* le slash fait 180Mo + +Ces deux problèmes sont désormais résolus sur les trois serveurs. + +Ce qu'il reste a faire : + +* Passer a lenny. +* Utiliser un paquet debian pour mumudvb. +* Utiliser les scripts d'init de mumu et monit au lieu de cron pour le + surveiller. +* Faire du ménage/tri dans les chaines sat. +* Acheter une carte TNT pour les chaines HD. +* Acheter des multiswitch : + + + +### Wifi + +#### WPA + +Regala n'a pas le temps de s'occuper de déploiement de sa solution Wifi alors +qu'elle fonctionne. Il cherche quelqu'un ayant le temps de s'en occuper. La +plupart des informations nécessaires se trouvent sur le wiki : + + + +Pour faciliter la migration chez les adhérents, il serait préférable de garder +les deux systèmes (IPSec et WPA) en parallèle, au moins au début. Regala dit +que les machines sur le réseau IPSec et le réseau WPA ne peuvent pas partager la +même plage d'IPs, il faudra donc se pencher sur le problème. + +Les choses à faire sont donc : + +* Tester le système développé par Regala sur deux bornes +* Documenter la chose pour les adhérents +* Commencer le déploiement de bornes avec le WPA, sur un réseau Wifi séparé + Cr@ns-WPA + +Et on aura enfin la paix avec les Vista-users ! + +* Tu paries ? + +#### Gestion des bornes + +Xavier, a eu l'occasion d'effectuer quelques tests avec les bornes. Quand le +userspace des bornes plante, elles continuent à pinger (donc ne sont pas +détectées down par l'autostatus) mais ne fournissent plus de wifi. + +Xavier va donc travailler sur un système de heart-beat pour améliorer la +détection du plantage. Ainsi qu'un système de reboot matériel par le réseau. + +Sinon, Michel et Xavier proposent que l'on monte les bornes dans des robots +autonomes qui reviendraient au 2B pour qu'on leur fassent un câlin dès qu'elles +sont plantées. Le problème, c'est qu'il y aura toujours une quinzaine de robots +dès qu'on va au 2B. Et qu'ils risquent de se perdre dans les couloirs de l'ENS +ou +à la Kokarde... + +### Asterisk/Mise en place de la téléphonie IP + +Le projet traîne depuis un moment, et il commence à devenir un peu plus "urgent" +de s'en occuper. + +Ce qu'il faudrait faire : + +* Mettre en place un serveur Asterisk bien sécurisé + * A tester en interne d'abord +* Mettre en place une interface utilisateur ergonomique (à peu près comme + l'intranet ?!) +* Trouver un fournisseur extérieur qui nous permette d'appeler *tous* les + numéros du monde +* Bien compter les communications de chacun (en particulier, débiter + au *bon* tarif de la communication), et couper les communications quand la + personne n'a plus d'argent sur son compte + * Compte pré-payé (le même que pour l'impression ?) + * Facture post-utilisation (dangereux) + * Abonnement tous les mois (dangereux) +* Trouver du hardware, qu'on pourrait vendre aux adhérents + +A noter que Regala bosse dans ce domaine, il s'y connaît très bien; il sera donc +de très bon conseil. + +### Projets en cours ou futurs + +#### Formulaire de préinscription en ligne + +Xavier y travaille. + +#### Détection des router-advertisements + +Olivier a écrit un programme en C, qu'il faut encore un peu compléter. Il +faudra aussi écrire un script en Python pour l'interfacer avec +le reste du système du Cr@ns. + +#### Réflexions sur l'IPv6 + +Problèmes: + +* l'ENS ne nous fournit pas une connexion IPv6 +* nos switchs ne sont pas IPv6-aware (en tout cas pour le multicast) +* nos serveurs ne sont pas IPv6-aware (le module IPv6 de etch est tout pourri) +* Qui maîtrise IPv6 + +Il faudra quand même commencer à y réfléchir et à se renseigner dessus. + +#### Bugs de l'intranet + +L'intranet est buggé. Antoine va essayer de voir ce qu'il arrive à comprendre. +Xavier émet l'hypothèse de recoder l'intranet. + +#### L'imprimante et les marges des pdfs + +On peut rajouter des features dans l'interface de l'intranet pour l'impression. +Xavier et Nicolas ont l'air motivés. + +#### Mise en place du service de boot PXE + +* Documentation +* Interface pour les adhérents, pour se mettre sur le VLAN 10 +* Filtrage de ce qui passe sur le VLAN 10, afin que les adhérents n'utilisent + pas le VLAN pour faire des trucs mal +* Mettre des rescue-cd ? + +#### Réorganisation des services Pegase/Munin + +* Il y a encore un serveur radius sur pegase. Il faut le réinstaller sur une + autre machine, avant de réinstaller munin dessus. On va créer un serveur + radius qu'on va mettre au 0B. On pensait plutôt à un domU. Dès que le serveur + radius est installé, on fait des test, et ensuite on peut s'amuser avec + pegase (qui ne sera pas renommé). +* munin chie complètement ses I/O, on va l'installer sur une vraie machine: + pegase. +* Si y a des gens qui ont des idées pour la génération du fichier de conf de + munin, ils priveront Nicolas du plaisir de peupler à la main les nodes. + +### Questions diverses + +#### fx + +* On va essayer de faire booter fx sur le reseau comme fy. Faudra trouver un + soir + +où on n'a rien à faire, et plein de bouteilles de coca + +* Après, on s'amusera peut-être à faire du load-balancing. + ---- + +CatégorieCrans diff --git a/compte_rendus/2009_03_05.md b/compte_rendus/2009_03_05.md new file mode 100644 index 0000000..3500f19 --- /dev/null +++ b/compte_rendus/2009_03_05.md @@ -0,0 +1,249 @@ +# Réunion Nounous + +* Date : Jeudi 5 mars 2009 +* Lieu : PdJ +* Début : 20h02 +* Fin : ???? + +## Présents + +* Antoine Durand-Gasselin +* Arnaud Deblonde +* Augustin Parret-Fréaud +* Nicolas Bruot +* Olivier Huber +* Pierre Chambart +* Roman Yurchak +* Stéphane Glondu +* Xavier Lagorce + +Via Gobby : + +* Brice Dubost +* Mathieu Segaud +* Michel Blockelet + +## Ordre du jour + +### Bilan du câblage des appartements de l'ENS + +Tout passe par Titanic et semble marcher. +Le Squid a été configuré. Les règles de base du firewall sont appliquées. + +Reste à faire : + +* Du nettoyage dans annuaires.py +* Ouvrir plus de ports et filtrer d'autres (p2p, toussa) +* Firewall généré par firewall.py +* Envoyer un mail pour organiser une réunion avec les personnels +* S'occuper *vite* des logs de squid +* Créer une page wiki expliquant comment ça marche + +### Migration vers Lenny + +#### Migration des services + +Il faudrait faire une page wiki permettant de recenser les différents services +qui doivent être migrés avant le passage à lenny. Si un apprenti veut par +exemple configurer un domU imap, horde et migrer la configuration sous bcfg2. + +Services critiques : + +* freeradius +* postfix +* dns +* horde +* dovecot +* ipp2p (pas dans les dépôts Debian mais ça se corrige, si quelqu'un a envie + +de regarder dans les arcanes de kernel-package, surtout kpatch) + +Voir `/usr/share/doc//NEWS{,.Debian}` (sur une machine sous Lenny) +pour des infos sur la migration. + +Lire aussi les release-notes. +Bien penser à mettre à jour le wiki. + +#### Passage en UTF-8 + +Il serait de bon ton de profiter du passage à lenny pour migrer vers l'UTF-8. +Les scripts de configuration ne devraient pas poser de problèmes, par contre +les scripts de gestion possèdent des parties spécifiques à l'ISO (et donc +affichent de l'ISO même en UTF-8). + +Il pourrait y avoir des problèmes avec les noms de fichiers (dans les homes des +adhérents). + +#### Migration des homes sur la baie SAS + +Maintenant qu'on sait bien utiliser la baie SAS, et qu'elle fonctionne bien, +il faut décider d'un système de fichiers, a priori de l'ext3. + +Pour l'ext4 on pourra migrer plus tard. (a priori pas de souci avec tune2fs, +le futur e4defrag s'occupera sans doute de convertir en extents ce qu'il bouge +mais suivant la taille effective des données sur le disque à migrer, il faudra +se poser la question de dumper ou simplement upgrader le système de fichiers) + +On pourra alors augmenter les quotas. Il faudrait décider de la taille accordée +à la partition pour les homes et de la nouvelle taille des quotas. + +Il faudrait aussi régler le problème de limite soft/hard avec postfix +et dovecot. + +#### Migration des services de rouge + +On pourrait créer un domU pour chaque service de rouge (avec intégration dans +bcfg2). + +À terme, l'idée serait d'acheter n domO comme fx et fy. + +On peut garder les serveurs actuels comme serveurs de secours (ou load +balancing, cela permet de tester le secours en permanence). + +* Benjamin se porte volontaire pour faire un domU avec dovecot et postfix à + jour sous lenny. +* Nicolas se porte volontaire pour faire un domU horde - roundcube. + +### Asterisk + +On peut mettre en place quelque chose rapidement, il suffit d'installer le +paquet Debian. Et puis après on pourra commencer à faire des trucs plus fun +avec LDAP (même si c'est configuré en 30 minutes). Il faudra ensuite déployer +des faisceaux vers et depuis le réseau téléphonique commuté, mais avant cela +il faudra écrire une gestion complète des temps de com. + +Xavier et Roman se portent volontaires. + +### WPA2 + +#### Ragnarok en 4.4 + +Olivier et WikiRegala s'en chargent après-demain. + +#### Tests sur les bornes + +Il faut que quelqu'un lise la doc du wiki et fasse des tests sur des bornes. +Je commence à m'en occuper samedi midi. Des firmwares du SVN d'il y a 3 jours +sont prêts (un avec un 2.6 et un avec un 2.4, le 2.4 étant le choix premier) + +PAF s'en charge, s'il a des questions, WikiRegala pourra y répondre. + +#### Haute disponibilité des bornes (avec un MONTE) + + + +Le module est en cours de conception. Ca devrait être cool. + +### Cameras + +Malgré ce que Michel a touché, ça n'a manifestement pas amélioré le comportement +de la caméra du 0B. + +Maintenant que le CROUS compte utiliser sa clé du 0B, il faudrait qu'elle +envoie +des photos par mail. +On pourrait échanger celle du 0B et celle du 2B. Ou tenter de réinstaller le +système de la caméra du 0B. + +Il faudra penser à réorienter la caméra dans une position où on voit vraiment +quelque chose d'intéressant ... + +### Intranet + +On recherche un mainteneur pour l'intranet. Il y a des bugs à corriger et des +fonctionnalités à ajouter. +Soyons d'accord, on n'impose pas un quelconque langage pour les développements +Web sophistiqués (à savoir avec gestion de session). On bannit néanmoins l'asp +et le php. + +On peut continuer sur la lancée actuelle de l'intranet, et tout faire en Python. +Ca évite aux gens d'apprendre 50 langages différents pour maintenir les scripts +au Cr@ns ... De plus ça permet l'intégration facile avec les autres scripts et +librairies (ldap_crans.py ?). Ça serait dommage de jeter l'existant après tout +ce qui a été fait. Par contre cela n'interdit pas de le nettoyer. + +### Remettre fx en production + +Il faut le faire booter sur Slon (la baie de disques). + +La question ne se pose pas sur l'usage de xen, mais bien sur le fait qu'il +faille configurer le BIOS de fx pour que celui-ci puisse booter depuis l'iSCSI +(Jérémie s'en occupe) + +Mathieu suggère d'essayer de préparer une possible nécessaire migration d'ici +squeeze sachant que Red Hat bosse sur des solutions de gestion de plateforme de +virt commune à toutes les solutions (vserver, openvz, xen et kvm) pour faciliter +des migrations (Certaines versions de Fedora utilisaient Xen comme solution, la +future Fedora 11 utilisera KVM). Le sujet est en pleine explosion, avec +différents leaders de l'écosystème !OpenSource essayant d'imposer telle ou telle +solution, telle ou telle interface de gestion... D'ailleurs, il pourrait être +intéressant de préparer une telle interface, un tableau de bord pour gérer les +domU à partir de l'intranet (gérer des droits nounous sur l'intranet ne devrait +pas poser de problème, on peut même utiliser gpg) + +### Munin + +Munin est un domU, il souffre énormément (cf. graphes Munin). Il faudrait le +mettre +sur une machine dédiée. +Pégase a l'air tout indiqué, il faudra quand même qu'on migre radius avant. + +#### Génération de la conf de munin + +Il faut automatiser la génération de la conf munin et de l'installation des +plugins (et de la gestion correcte des encodages). (si migration vers UTF8 il +y a, pas de "gestion incorrecte" des encodages :)) + +Il faudra rajouter dans bcfg2 la gestion de la conf pour les munin-node, et un +script maison qui parsera les fichiers de conf de bcfg2. + +### Webalizing + +Ça fait depuis longtemps que ce qu'il y a sur rouge ne marche plus, mais on +s'en soucie guère. + +A noter qu'à l'époque où webalizer était utilisé, il avait tendance à occuper + +*énormément* de ressources, et que certaines fois, il plantait et utilisait + tout + +le CPU pendant plusieurs heures ... + +### Pré-Inscription + +Il semblerait que le nouveau BDE ait accepté de mettre un module réseau sur +le photocopieur de la Kfet (Geneviève en a discuté avec eux). + +Il faut développer une application web d'inscription en ligne. +Xavier s'est déjà porté volontaire pour regarder. + +### Questions diverses + +#### Backup physique + +On compte mettre en place une copie des backups qui ne soit accessible +qu'en lecture seule. + +* Les bandes magnétiques sont la meilleure solution + * il faut une idée de prix et de matériel, et que ça ne soit pas trop cher + * On peut compter un système assez bien à environ 2000EUR (j'ai cru voir). + +#### Egon + +Il faut changer et réinstaller egon car son comportement est de plus en plus +erratique. +Proposition d'achat d'une nouvelle machine pour un budget de 1300EUR +Proposition d'achat d'un écran 30" HP au prochain CA + +#### Alimentation du 0B + +Il y a actuellement un problème d'alimentation au 0B, lors de la mise +sous tension, les alimentations des serveurs consomment un pic de +courant qui fait disjoncter l'onduleur. + +Deux solutions différentes sont proposés, une par Valérian basé sur des +relais retardés et une seconde sur une multiprise ssh. La multiprise ssh +présente l'avantage de permettre de manager à distance l'alimentation +des serveurs. + +On contactera toutefois Anne Cazalet avant d'effectuer un tel achat. diff --git a/compte_rendus/2009_04_06.md b/compte_rendus/2009_04_06.md new file mode 100644 index 0000000..84cc4f0 --- /dev/null +++ b/compte_rendus/2009_04_06.md @@ -0,0 +1,183 @@ +# Réunion Nounous + +* Date : Lundi 6 avril 2009 +* Lieu : Pavillon des Jardins +* Début : 19h30 +* Fin : 21h57 + +## Présents + +* Antoine Durand-Gasselin +* Benoît Barbot +* Jérémie Dimino +* Olivier Huber +* Stéphane Glondu +* Stéphane Murday +* Xavier Lagorce + +## Ordre du jour + +### Migration sous Lenny + +Il reste sable, zamok, rouge et vert. + +Sable : adg s'occupe de squid. +Adg veut tester squid 3 sur egon (pour la mise en cache des vidéos). + +On migre dans un premier temps vert sous Lenny, puis les homes vers slon, et +enfin zamok vers Lenny. + +### Rouge + +On ne migrera pas rouge en tant que tel, on va séparer les différents services. +Olivier a configuré rouge (avec un sysctl) pour qu'il reboote en cas de kernel +panic. +Il faut que quelqu'un migre les services mails sur un domU et les webmails sur +owl. + +### Toilettage de la configuration des switchs et mise à jour des firmwares + +#### Vlan pour les switchs afin d'éviter de répandre le Vlan adm + +Olivier va s'occuper de mettre en place un Vlan switchs afin d'éviter que le +vlan adm +soit partout. A terme, il ne se trouvera que sur les chemins entre le 2B, la +ferme, +le 0H et le 0B. + +#### "Tagguage" des Vlan plus facile + +SIGKOOL. Le principe est de rentrer la topologie du réseau dans le script de +génération +des switchs pour pouvoir tagguer entièrement les vlans jusqu'à une prise grâce +à une +seule commande. + +#### Vlan isolement + +Il faut juste mettre à jour la configuration des switchs et le tagguer sur tous +les uplinks. + +### Parler de l'architecture réseau + +#### Intégration du nouveau point d'accès + +On mettrait un serveur au G. + +#### Bâtiment G + +On a un local de brassage au 2e et 4e étage. Le CROUS pense mettre des gens +début mai. + +Et un local principal au sous-sol qui distribuerait la fibre vers les autres +locaux +par des liens !GigaBits. + +On prendra des 2650. + +#### Redondance + +Il faudrait tirer une fibre entre le G et le J, il faut se renseigner pour en +tirer une +entre le H et C et il faut réparer la fibre défectueuse entre le I et le H. + +### PostGreSQL + +L'idée de départ était que ovh.crans.org continue à faire du greylisting +lorsque le 0B +est down. Une solution est que chaque serveur de mail ait sa propre base PgSQL, +ces +bases étant synchronisées entre elles. + +[Bucardo](http://bucardo.org/) est un système de réplication +multi-master (i.e. qui +synchronise dans les deux sens entre plusieurs serveurs, contrairement à la +plupart +des softs qui ne synchronisent souvent que 1 master -> n slaves). Il gère très +bien les +conflits (de toute façon, ce n'est pas quelque chose de critique pour +l'utilisation que +l'on veut en faire). + +Le problème est que Bucardo nécessite PgSQL ≥ 8.1, et que la base de rouge est +en 7.4. +Michel semble avoir trouver un moyen de dumper les bases et de migrer +de 7.4 à 8.3. +Il va créer un DomU PgSQL et y migrer toutes les bases (mail, filtrage, ...) + +### Asterisk + +La VoIP SIP fonctionne en interne. Une ligne SIP chez OVH a été souscrite. +L'interfaçage est en cours. + +Les adhérents seront contactés depuis l'extérieur par un numéro débouchant sur +un +standard. Un adhérent sera alors identifié par son aid. + +En interne, il pourra être joint par son adresse mail canonique au Cr@ns ou par +son aid. (On peut considérer le blocage sur demande du contact par adresse +mail). + +On peut mettre en place un système de conférence ainsi que des messageries +vocales. + +Il peut-être envisagé une période de test en charge pour les appels vers +l'extérieur +et l'intérieur. On pourrait alors ouvrir gratuitement les lignes téléphoniques +pour +tout le monde. Le CA doit décider s'il veut investir une somme pour cela. + +Xavier se charge de regarder pour des téléphones physiques. + +### Système de reboot des bornes wifi + +Le PCB est terminé et sera commandé cette semaine, les composants ont déjà été +commandés. + +Les modules de test devraient être arrivés dans environ deux semaines. + +### Connexion des personnels de l'ENS + +Adg a commencé à écrire de la documentation technique sur le wiki. On leur +donnera des +informations sur l'intranet + accès à l'intranet de zamok. + +Il faut aussi faire de la correspondance MAC-IP sur titanic et le firewall en +général +(stats sur le trafic, ...). + +### Repo Darcs "béni" au crans + +On se fixe comme discipline de ne pas laisser des choses non commitées dans les +repos. +Adg doit réparer *proprement* le repo scripts. + +### Divers + +#### Imprimante + +Il faut trouver une méthode pour la débourrer en douceur. Par exemple, il faut +installer +une porte pour pouvoir sortir le bloc de finition. + +#### Connexion en Gigabit à l'ENS + +Il faut acheter une carte 10 GB fibre pour komaz. Il faut voir avec la DSI pour +qu'ils +nous branchent directement en fibre. Il faut garder le lien avec le transceiver. + +#### Système de Ticketting/destruction d'O₂ + +Celui qui crée un truc qui plaît sur O₂ a gagné. + +#### Partition nfs de softs & libs + +On oublie. + +#### Protéger le nfs à l'aide d'un VPN + +Adg étudie la faisabilité. + +#### Dépôts git du cr@ns + +À voir plus tard. diff --git a/compte_rendus/2009_05_04.md b/compte_rendus/2009_05_04.md new file mode 100644 index 0000000..d137011 --- /dev/null +++ b/compte_rendus/2009_05_04.md @@ -0,0 +1,109 @@ +# Réunion + +* Date : 04 Mai 2009 +* Lieu : Pavillon des Jardins +* Début : 19h55 +* Fin : <> + +## Présents + +* Antoine Durand-Gasselin +* Damien Aza-Vallina +* Jérémie Dimino +* Mathieu Segaud +* Olivier Huber +* Stéphane Glondu +* Xavier Lagorce + +### Bilan sur les dernières migrations et les changement au niveau des + +serveurs + +Rouge est presque mort, il fait encore DHCP et TFTP pour le boot PXE. + +Mais que va-t-il devenir ? pom pom pompommm + +Il est trop tard pour rallonger sa garantie, par contre, c'est encore possible +pour +les serveurs les plus récents. Celà pourrait être intéressant de le faire, il +faudrait +chiffrer les extensions de garanties et proposer cela au CA. +Il faut donc relever le SN/PN et le modèle des différents serveurs et les +transmettre +à Stéphane. + +Il faut faire la mise à jour d'OpenBSD. Régala se propose si aucun apprenti +n'est harponné +pour le faire. + +### l'IMAP est-il lent sur owl? + +owl présente des problèmes d'IOs. Certaines personnes considèrent que cela le +ralentit. + +On pourrait tester openvz, avec owl... pour voir... + +### Système de reboot des bornes + +PCB reçu, prototype assemblé. Il fonctionne. + +Un prototype en CMS va être conçu puis testé. + +### Système de ticketing + +"C'est plutôt cool" dixit Stéphane. +"On s'en sert pas" dixit Antoine. +"C'est pas incompatible, ça s'applique à moi" dixit Stéphane. +"Il consomme beaucoup de RAM" dixit Stéphane + +/me compte les points. + +adg doit cliquer, il est pas content... + +Conclusion : il faut s'en servir davantage. + +### Protection du NFS à l'aide d'un VPN + +Il faudrait tester NFSv4 ou mettre OpenVPN... + +Il y a des points plus urgents à développer. + +### Bilan sur la nouvelle base Pg + +On reçoit des mails... +Il faudrait installer munin dessus... + +### Achat de matériel + +* 16Go de ram pour chaque dom-0: +8Go pour fy +12Go pour fx + * Il semble y avoir deux slots de libre sur fy +* Prix des alimentations pour Fx. +* Achat d'une carte d'une carte Gigabits pour Sila. + +### Achat multiprise ssh + +* Stéphane demande un devis à Anne pour les PDU. +* Olivier se charge d'appeler la mge (Jeudi 7 Mai) + +### Achats pour les chaînes TNT HD + +* Olivier a trouvé un ampli à 8 sorties (référence AVN1716F KUBLER). + +Il doit se charger de le commander rapidement. + +### Déploiement du wifi en WPA2 + +Migration le week-end du 6-7 juin. + +### Mise en place de l'inscription en ligne + +Adg et Chicco ont commencé à regarder. + +### Authentification LDAP sur le wiki + +* Ça marche sur Vo + +### Bugs de MoinMoin + +"C'est pas des bugs, c'est des features"™ +Il y a des problèmes de caching. diff --git a/compte_rendus/2009_05_25.md b/compte_rendus/2009_05_25.md new file mode 100644 index 0000000..d9cf57a --- /dev/null +++ b/compte_rendus/2009_05_25.md @@ -0,0 +1,272 @@ +# Réunion + +* Date : Lundi 25 mai 2009 +* Lieu : 2@B, clim powa® +* Début : 20h00 +* Fin : 22h30 + +## Présents + +* Antoine Durand-Gasselin +* Damien Aza-Vallina +* Jérémie Dimino +* Pierre Chambart +* Xavier Lagorce + +Par Gobby : + +* Brice Dubost +* Michel Blockelet +* Nicolas Dandrimont + +## Ordre du jour + +### Imprimante canon + +Adg a installé les drivers proprios (UFR) téléchargés sur le site du +constructeur, +mais c'est moche car il faut passer par une conversion PS. On passe par un +binary pour convertir en postscript, ce qui fait que l'on a aucune idée de +pourquoi ça ne marche pas. En plus certains pdf ne sont pas interprétables. + +Actuellement la facturation se fait au nombre de pages, comme il avait été +décidé en CA. Ce qui fait que tu enrichis le CRANS lorsque tu imprimes du +monochrome en couleur. En effet, l'imprimante peut détecter une page n&b dans +un doc couleur +(voir CR des réunions CA au sujet de l'imprimante). + +Si quelqu'un veut s'embêter à vérifier la colorisation de toutes les pages, +il peut. Ne serait-il pas possible de le demander à l'imprimante ? En parsant +l'interface web... + +La mise en place du nouveau système de facturation a nécessité un retouche +de l'intranet et des différents scripts d'impression. Antoine a profité +pour faire le ménage parmi les scripts. + +#### Wrapper de l'interface web en ocaml + +Antoine a développé une petite application en OCaml, qui permet de soumettre +le pdf à l'interface web et de sélectionner les options. Ce script fonctionne +mais n'est pas encore tout à fait au point. + +Xavier fait remarquer qu'il est dangereux de coder des scripts en OCaml. En +effet le python a l'avantage d'être beaucoup plus simple et lisible (et ça +fait moins peur aux nouveaux). +De plus, ce problème a déjà été discuté en inter-nounou et l'assemblée avait +tranché contre l'utilisation généralisée d'OCaml. + +Pierre fait remarquer qu'en perl ça peut être pire. + +Damien fait remarquer que dans environ 2 ans, l'imprimante sera changée. + +#### Statistiques + +Il serait bon d'envoyer des mails pour les consommables. + +#### Utiliser le driver PCL + +Antoine fait remarquer qu'on peut aussi investiguer sur l'éventuelle utilisation +du driver pcl pour l'imprimante. + +### État de migration des serv{eur,ice}s + +Penser à installer le switch gigabit pour la baie iSCSI. + +#### Vert + +* /home se remplit (209/225GB) Une des raisons est le stockage des logs de + squid sur cette partition (14GB) + * Damien fait remarquer que cela risque d'être très problématique à la + rentrée. + * Si la croissance continue à ce rythme, /home sera plein à la mi-juillet. + Il faut rapidement migrer /home sur la baie de disques iSCSI. +* Migration de LDAP ou mise à jour ? + * L'avis de Nicolas est que vert est un serveur obsolète, et que le mettre à + jour à lenny n'avancera à rien. De plus, étant serveur LDAP principal et + serveur NFS, un downtime serait très problématique pour l'ensemble des + services. + * Antoine propose d'effectuer la migration (de quoi ?) le samedi 14 à partir + de minuit. +* Laisser les homes en RO ? (soft bounce) +* Configurer newldap en serveur LDAP primaire +* Créer un domU home si les problèmes d'I/O sont réglés d'ici là (KVM semble + prometteur), sinon, continuer à utiliser vert. (en attendant un serveur + physique ?) + +#### rouge + +* SMTP principal + * Il faut déplacer/dupliquer amavis/clamav sur redisdead avant de bouger + mailman définitivement. Faire fonctionner l'authentification en envoi sur + redisdead. +* Mailman : Les fichiers de configuration de mailman ont été rsyncés sur + redisdead, il faut: + * Diminuer le TTL des DNS + * Attendre (24h) (pendant ce temps, vérifier que mailman fonctionne sur + redisdead) + * Mettre une redirection sur rouge du trafic de lists.crans.org vers + redisdead + * Changer les alias lists.crans.org, smtp.crans.org, mailman.crans.org + * Prévenir les adhérents qu'il faut utiliser smtp.crans.org pour envoyer des + mails + * Attendre que rouge ne reçoive plus de mails vers lists.crans.org + * Faire tomber la guillotine + * Ré-augmenter le TTL des DNS +* ntp +* dhcp + +Nicolas est de toute évidence la personne le plus au courant de ce qu'il faut +faire. + +#### zamok + +* etch -> lenny + * Quelqu'un voit quelque chose qui casserait sur zamok lors d'une + màj ? -> L'intranet ? +* iso -> utf-8 + * Faire gaffe aux *noms* des fichiers dans les homes dans les adhérents + * Résoudre les problèmes avec les scripts + +#### Ragnarok + +* Trial of the BSD Knights -> Games + * Il faut inciter un apprenti à effectuer la migration. + +#### Virtualisation + +Munin a été migré sur fx dans kvm. + +Quelques statistiques : + +* + ->munin-update prend plus de temps +* -> pas + d'I/O wait ... + +Munin est un bon exemple pour pouvoir décider de la robustesse/efficacité +d'une solution de virtualisation. + +On va encore le laisser une petite semaine munin sur kvm pour pouvoir +comparer. Si le test est concluant, une migration d'owl devra être effectuée +pour confirmer les résultats (c'est en effet le domU qui est le plus chargé +actuellement). + +La solution actuelle de virtualisation n'est pas satisfaisante: + +* Problèmes d'I/O +* Échecs de migrations à chaud +* xen n'est pas vraiment maintenu + +Remarque: on n'utilise pas la virtualisation matérielle sur fy. + +##### Tweaking + +Dans les machines virtuelles kvm, l'ordonnancement des entrées sorties est fait +par défaut par l'ordonnanceur CFQ. Il en est de même pour l'hôte/hyperviseur. De +plus, les disques sont en iSCSI, un troisième ordonnancement est effectué par la +baie de disques. Pour gagner en performances, il faut utiliser l'ordonnanceur +''noop'' sur les VMs (ce qui est le cas sur munin depuis quelques heures). Il +faudrait voir s'il ne serait pas avantageux de faire ceci sur les disques iSCSI +sur l'hyperviseur. (Les VM xen en virtualisation logicielle utilisent déjà cet +ordonnanceur par défaut). Règles UDEV sur fx et fy ? + +### Cacher youtube + +Ça ne marche *que* pour youtube. Il serait bon d'avoir des stats sur les +requêtes pour le cache de squid +(-> qui ne marche +plus). +Manifestement le cache ne tient pas très longtemps (ou bien ça ne marche +plus ?). +Il faut investiguer. + +* Qu'est ce que c'est cette histoire de cacher + youtube ? -- WikiPolo <> + +Adg voudrait pouvoir faire la même chose pour !DailyMotion, Deezer, ... +Mais Pierre dit que : Deezer c'est assez moche, on avait essayé à Berlin... +Il faut croire qu'il y a des données en plus pour identifier les connexions. +J'ai un peu fait mumuse avec !DailyMotion, ça a l'air du même accabit. + +### Vlan 21 + +#### MSN + +* Ça n'a juste pas marché lorsque j'ai voulu essayer avec pidgin, bien que tous + les ports eussent été ouverts. +* Ce qui est bizarre c'est que j'ai eu des retours positifs dessus. + +#### Wiki + +ip_crans renvoie false sur l'ip de titanic. + +#### Câblage d'un appartement du CROUS + +Aucune limitation technique (à part le câblage physique) + +#### Monitoring + +La connexion marche. Il serait de faire des stats sur le trafic sur la +connexion de la freeboîte. (En plugin munin ?) + +### Câblage de la Kfet + +Réalisé jeudi. Il faudra acheter et fixer des prises murales + +### Wifi WPA2 + +On préfère garder la surprise pour le we du 7-8. (Vous êtes des malades) + +### Interface d'inscription en ligne + +Ce sera un patch du wiki (et ça ne sera même pas trop sale) + +### Authentification sur moinmoin par la base ldap + +* On autorise une double authentification (comme sur vo) +* On rajoute un champ wikinom dans la base LDAP initialisé à !WikiPrénomNom (ou + PrénomNom (ça me paraît être la base du wikinom)) +* Ce champ est modifiable par l'intranet. + * Gros checking pour éviter les collisions. (Ce check ne peut se limiter à + la base LDAP) + -> Cette solution n'empêche en rien de continuer à utiliser les comptes + MoinMoin. + +Cependant il pourrait être judicieux de supprimer la création de comptes +MoinMoin +pour éviter les collisions. + +Les homonymes pourront être gérés par une unicité dans la base LDAP. + +L'authentification LDAP nécessite MoinMoin >1.8 (squeeze) (vu le niveau de +patchage du paquet custom actuel, ce n'est pas vraiment un problème). + +### Inventaire du matériel + +Il faudra compter les switchs du 0C. Il faudra un jour faire du rangement. + +### Achats de matériel + +* La RAM a été commandée +* Tant que la MGE n'aura pas été appelée, on ne statuera pas sur l'achat des PDU + * A priori, MGE n'a pas été appelé (comme *promis* par Olivier le 5 mai) + * Vérifier que les pdu font bien ce que l'on attendrait d'eux +* Clim de la ferme + * Damien a déposé le dossier de travaux auprès du CROUS + * Damien a fait un devis auprès de notre prestataire de clim + * Damien va faire un devis auprès du prestataire climatisation de l'ENS +* Switchs du G (on ne sait pas) + +### Motiver les apprentis + +* Remplacer SQLGrey par un truc plus intéressant *kh* milter-greylist *kh* +* **Asterisk** <- en cours à partir de la semaine prochaine +* Préinscription +* Migration openbsd (c'est chiant) +* Taper l'incruste au dpt info avec chicco +* IPv6 (lobbying de l'ENS ?) +* Mangez avec les doigts comme tout le monde... ( avec la bouche ça suffit ) +* Faire des poupées vaudou albanel et riester (et lefebvre, gosselin) +* Refaire des chiffons{{{^W}}}t-shirts firefox{{{^W}}}iceweasel + * Fan inconditionnel des T-Shirts + Iceweasel -- WikiAdg <> diff --git a/compte_rendus/2009_06_11.md b/compte_rendus/2009_06_11.md new file mode 100644 index 0000000..c92cc88 --- /dev/null +++ b/compte_rendus/2009_06_11.md @@ -0,0 +1,81 @@ +# Réunion Nounous + +* Date : Jeudi 11 juin 2009 +* Lieu : Pavillon des Jardins +* Début : 19h30 +* Fin : -- WikiXhub <> + +## Présents + +* Jérémie Dimino +* Antoine Durand-Gasselin +* Olivier Huber +* Xavier Lagorce + +## Ordre du jour + +### Vert is dead + +On demande à acheter un fz (HP Proliant DL 360) qui servira soit pour de la +virtualisation soit comme serveur classique. +Cf demande sur tracker pour la liste des choses à acheter. + +### Problèmes du bâtiment J + +On y a passé une semaine, on a fait des trucs, mais depuis que la ferme ne +diffuse plus, on n'a pas constaté de problème. +Nous restons à l'écoute des adhérents. + +### Migration des services de rouge + +Cf tracker pour les services qui restent à migrer. + +### MoinMoin + +Adg va essayer de passer le plus vite possible à la 1.8. + +### WiFi + +Sous linux ça marche du tonnerre : la configuration est +là : +Sous Mac Os : Xavier s'occupe de mettre la configuration sur le Wiki +Sous Vista : ça ne marche pas pour l'instant + +Les instructions sont sur le Wiki : + + +### Virtualisation au Cr@ns + +On essaie de faire des tests supplémentaires avec plusieurs systèmes de +virtualisation. + +### Préinscription en ligne + +Adg pose un lock. D'ici jeudi prochain on a une preview. + +### Asterisk + +On ne peut pas accéder à notre ligne depuis l'extérieur. Il faut régler les +problèmes administratifs (il faut juste envoyer un courrier). + +### Imprimante + +Il faut passer zamok à lenny, peut-être essayer les driver pcl. Problèmes +actuels : + +* Certains pdf ne passent pas (mais ça marche avec l'interface web de + l'imprimante) +* L'agrafage en livret ne marche pas (déterminer la limite à partir de laquelle + l'imprimante ne veut agrafer) + +### Redondance et QoS + +Le CA devrait fournir un cahier des charges clair. + +### Serveur pour FeDeRez + +On migre les dns de mdr autre part et on leur donne le serveur. + +### Divers + +La connexion à la Kfet ne marche pas. diff --git a/compte_rendus/2009_07_02.md b/compte_rendus/2009_07_02.md new file mode 100644 index 0000000..93bc277 --- /dev/null +++ b/compte_rendus/2009_07_02.md @@ -0,0 +1,220 @@ +# Réunion + +* Date : Jeudi 2 juillet 2009 +* Lieu : 2B (clim powa) +* Début : 20h15 (asterisk powa) +* Fin: -- WikiAdg <> + +## Présents + +* Antoine Durand-Gasselin +* Damien Aza-Vallina +* Nicolas Dandrimont (conférence VoIP) +* Olivier Huber +* Pierre Chambart +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Achats de matériels + +* switch 0J (2810) devis (./) , achat (./) +* switch 4j (2910) devis (./) , achat (./) +* switch plafond2B (1800, le même que minigiga) devis {X} , achat {X} +* disques: trop cher, on attend +* modules ps/2: devis (./) , achat (./) +* multiprises ssh: devis {X} , achat (./) +* switchs du G: on attend encore un peu +* chaises pour les locaux: 4 pas chères (./) +* fz, devis {X} , achat (./) a priori +* Pour les logs, des DD Sata sur slon ? Un serveur syslog ? autant que + ca ? -> dans le chat) + +### Dossiers avec la DSI + +Il faut prendre rendez-vous avec la DSI pour aborder les points suivants: + +* wifi : + * Solutions que la DSI compte déployer ? + * Intégration avec notre solution ? + * Est-ce qu'on peut arrêter de diffuser ENS-Cachan ? + * Elles sont passées où nos bornes en zone ENS ? + * Faire marcher notre wifi en zone ENS (PDJ...) +* gigabit (matos à acheter ?) +* upload +* miroir debian ? + +### Rangement/Équipement des locaux + +* Quand est-ce qu'on range le 0C ? + Un jour. +* Quand est-ce qu'on range la ferme ? + Un jour. (ou peut-être une nuit) + * de préférence la nuit. +* Quand est-ce qu'on fait un inventaire. + * On attend fin août quand il y aura plein de monde + +### Organisation des différents projets et détermination de leur priorité + +Il serait bon de mettre en place une liste claire des projets qui pourraient +être effectués par des apprentis. + +### Point sur les dossiers techniques + +#### impression + +Il y a des pdf qui buggent, ils restent donc actifs indéfiniment dans la +lpq, bloquant les impressions. Supprimés de la lpq, un process fou continue +de manger du cpu indéfiniment. + +Solutions envisagées: + +* Migrer zamok à lenny +* Utiliser RPC +* Utiliser un script OCaml pour soumettre les pdf par l'interface web + +(cette solution a le défaut d'être vraiment lente, même quand on compile en +natif) + +* Backporter cups + quelques libs +* Tester sur d'autres machines sous lenny (tenter d'autres machines) + +##### Évolutions + +* Facturer de manière plus juste (ne pas facturer les pages n/b comme de la + couleur). +* Du nupping. +* Aperçu des pdf en direct (ajax powaaa) +* rajouter les limites +* débugger un peu le bouzin *ahem* + +Projet proposable: +termes d'accroche -> programmation web, Ajax, user-friendlyness, impression +nounous pouvant encadrer -> adg (AT) crans (DOT) org + +#### modules de reboot des bornes + +Pas de méthode d'authentification sur les bornes. Les bornes seront isolées sur +un vlan. On peut faire une OTP très sale. + +Deuxième prototype d'ici une semaine et en CMS. + +La doc quand ça sera terminé....... + +#### déploiement du wifi + +it works™ (bitches) + +Les bornes diffusent l'ESSID Cr@ns en WPA2-Enterprise, et transmettent les +requêtes radius à ragnarok. Radius sur ragnarok est configuré pour accepter +les couples mac/[former]clef ipsec. Ça marche sur beaucoup d'OS très utilisés. + +#### développement du wifi + + -> rachat de bornes: lesquelles? + * supportées par openWRT: + + * débit (chiffrement) + * possibilité de diffuser plusieurs ssid + * 802.11n ? .11a ça serait cool déjà + * MIMO ? + * NB: il y a des bornes qui ont des disques usb + +##### Évolution + + -> monitorer un peu mieux les bornes + * faire joujou avec x-wrt + * wiviz + -> comprendre la conf de radius sur ragnarok + -> nettoyer la conf de radius sur ragnarok + +##### Blagues (ou pas) + + -> projet de borne autonome (se manifester avant le rangement des locaux) + +#### ipv6 + +Actuellement en place: + +* un tunnel sur komaz +* squid3 sur sable + -> dégager des projets pour des apprentis. + * firewall (projet à encadrer strictement) + * réécrire proprement les scripts de comptage + * négocier avec la DSI open-réseau + * dhcp / router advertaïzement + * igmp + * les scripts ?! -> les scripts seront plus ou moins recodés dans leur + intégralité. + +#### features des switchs + +##### DHCP pirates + +* Protection contre les DHCP pirates + +##### Détection des boucles + +Les gens du point rencontre ont fait des boucles. Ça a mis down une partie du +réseau. Il faudrait vérifier que la détection des boucles marche. On perd +Jérémie, +mais le problème devrait bientôt être résolu. +done! *applause* + +#### rouge + +On migre rouge dès que possible. La source de rayons comiques s'est peut-être +tarie. +Peck est sur le campus pour de bon. + + -> petit projet pour apprenti: + générer un known_hosts potable et ranger les clefs. + +#### vert + +Une belle bête, qui pèse bien ses 42kg. On remarquera que vert a des +ventilateurs +rackables. + +#### OpenStreetMap + +Il faut voir *exactement* de combien de place et de débit ils ont besoin, et on +décide en conséquence... + +#### Corbeau + +diffusion-crans.general@crans.org poste automatiquement sur crans.general +seule brigitte.vidal@adm.ens-cachan.fr pourra poster. Si elle poste trop, +on la déconnecte. + +#### pegase + +il est open +munin me paraît être un excellent choix. + +#### proxy + +revoir la conf de zéro + +#### VoIP + +It works™. +Il reste encore *plein* de trucs à faire. + +Oh! tiens encore plein de programmation web à faire. + +#### wiki + +À mort Apache ! Mais bon, osef. Ocsigen avec WSGI (l'interface "CGI" mieux de +Python) ? ocsigen powa ( ocsimore a une grosse bite ) + +#### zamok + +l'idée serait de coller sur fzamok, l'impression, l'intranet, +le webmail, l'imap, le pop, et, dans une machine virtuelle, le serveur des +adhérents. +niomniom resterait le serveur web du crans. + +On casse zamok ? (upgrade) +Bof. diff --git a/compte_rendus/2009_09_10.md b/compte_rendus/2009_09_10.md new file mode 100644 index 0000000..e0e285e --- /dev/null +++ b/compte_rendus/2009_09_10.md @@ -0,0 +1,248 @@ +# Réunion Nounous + +* Date : Jeudi 10 Septembre 2009 +* Lieu : PdJ +* Début : 19h30 +* Fin : 21h35 + +## Présents + +* Antoine Durand-Gasselin +* Johan Grande +* Larissa Viraphong +* Michel Blockelet +* Nicolas Dandrimont +* Olivier Huber +* Raphaël Bonaque +* Raphaël Cauderlier +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Présentations + +Elles sont faites et mamie a trouvé le bon serveur sur lequel se connecter :) + +### Bilan du câblage du bâtiment G (espérons...) + +* Le bâtiment G a été relié avec un câble RJ-45 de 153m de long +* Les switchs ont étés installés + +La solution qui a été mise en place (le long RJ-45) ne marche pas très +bien. Il faudra réussir à pérenniser la connexion, vu qu'il faudra +nécessairement +remettre une fibre optique. L'ancienne semble vraiment en trop mauvais état pour +être utilisée. Il faut budgétiser le sertissage d'une nouvelle fibre, ainsi que +sa pose (sachant que nous pourrions effectuer nous-même la pose de la fibre). + +À priori, une bobine de 250m de fibre coûterait dans les 500 euros. +L'utilisation de la fibre enroulée actuellement au -1I n'est pas envisageable, +vu qu'elle est enroulée depuis plus de 5 ans. + +La fibre connectant le 0G et le 2G est cassée dans la baie de brassage, il +faudrait +voir à la faire ressertir. Il faudrait aussi voir si sa réparation ne pourrait +pas +être prise en charge par une des (certainement nombreuses) assurances du CROUS +pour +les travaux dans le bâtiment G. + +Connexion actuelle au G : +batj-319 <-- 153m (cuivre) --> batg-025 0G <-> 4G en fibre et 4G <-> 2G en +cuivre (cat6). + +Restrictions : +La télé est bloquée depuis batj-3. Il faut dire aux câbleurs de prévenir les +gens +pour utiliser leur connexion avec parcimonie (quand elle fonctionne). + +### Recrutement - lancement des séminaires + +Olivier propose que les apprentis fassent toujours les séminaires, mais qu'une +nounou soit responsable de suivre le travail de l'apprenti et puisse servir de +backup en cas de problème. + +Une autre idée serait de faire des revues de code Python, afin d'améliorer les +scripts en douceur et de permettre la transition. + +Les nounous se chargent de mettre au point une liste de séminaires qui sera +présentée à la prochaine internounou. + +### État des lieux des serveurs + +#### rouge : MX principal, serveur smtp et serveur mailman + +(anciennement wiki, serveur web, serveur jabber, serveur imap, serveur pop, +serveur ntp, +serveur de kernel panic, serveur DHCP) + +Il faut mettre fin à ses jours sous peu. Ne reste plus qu'à migrer les +services mail. + +#### zamok + +Serveur des adhérents, serveur des pages perso, de l'intranet, délivrance des +mails (procmail, forward, etc.) + +Une proposition serait d'acheter un nouveau "gros" serveur (fz), sur lequel +seraient +rassemblés les services concernant les adhérents. Vu que les tests d'autres +solutions de virtualisation n'ont pas été probants, ce serveur serait placé sous +xen. Il faut budgetiser cette solution. + +#### pegase + +Ne fait plus rien, est éteint, mais fonctionne (et a plein de disques). Est une +vieille brouette. + +#### babar + +Serveur de sauvegarde et de vidéosurveillance, fonctionne, est à jour. + +#### sila + +Serveur sFTP. Un peu ancestral, un peu de brique et de broque. Il faudrait +demander +un devis pour : + +* Un serveur 1U ou 2U avec des gros disques +* Un serveur 1U avec des petits disques et des gros disques pour la baie + +Et choisir la solution la moins chère, pour remplacer sila en tant que FTP. + +#### ragnarok + +Serveur sous OpenBSD, serveur radius, routeur wifi, serveur web de +wifi.crans.org + +Il faut le mettre à jour vers OpenBSD 4.5 (comme tous les 6 mois). Peut-être que +les fuites mémoire de {freeradius, Patches OpenBSD} seront corrigées. + +#### Serveurs de la ferme + +* vache (mdr) (dns de la zone TV) -- It works!™ +* canard +* oie +* lapin +* dindon (prove) + +Les serveurs fonctionnent, mais le multiswitch a cramé. On récupère la TNT en +splittant le flux. On peut racheter un multiswitch, ce qui nous permettra de +multiplier le nombre de cartes satellite. + +#### fy + +* Dom0 Xen + +#### fx + +* Serveur NFS (homes + /usr/scripts) + +#### sable + +Le proxy, serveur DNS principal, serveur DHCP, serveur radius, serveur de la +connexion gratuite. + +Il fonctionne malgré la grosse mise à jour de porc vers squid3. + +### Investissements potentiels + +* Nouveau contact pour Synaps : Nicolas va reprendre le contact avec Anne. + +#### ftp + +Cf. ci-dessus. + +#### fz/zamok++ + +Le système imaginé avant les vacances, lors des problèmes d'I/O Xen, était +d'acheter +un serveur qui monterait les /homes, et les partagerait directement à tous les +services qui en auraient besoin (i.e. les services adhérents de zamok + owl + +niomniom). + +Vu que les problèmes de Xen semblent réglés, placer les services des adhérents +sur un DomU serait envisageable. On va voir avec Anne ce qu'elle propose comme +bête de course. + +#### monitoring + +Il faudrait budgetiser un serveur "peu puissant" pour effectuer le monitoring +séparément (munin, autostatus, ...). On pourrait y ajouter pour pas cher une +centralisation des syslog (à l'aide de rsyslog). + +#### Fibre + +Cf. ci-dessus + +#### Reboot de bornes + +Voté au précédent CA (500€ de budget pour 10 modules) et cf ci-dessous. + +#### Bornes wifi + +Voté au précédent CA (500€ pour $n$ bornes de test) + +### Projets en cours + +#### bcfg2 + +Système de gestion de configuration des serveurs. Permet de centraliser les +configurations redondantes. +Comme puppet ou cfengine (mais en python). + +Le passage de bcfg2 0.9 à 1.x nécessite python 2.6 (ou un module SSL backporté). + +Il faudrait unfucker la configuration. + +#### Reboot de bornes + +It works, bitches !™ + +Un des modules a été détourné pour remplacer vigile pour la gestion du digicode. + +Il faudra des doigts pour réaliser les 100 modules. + +#### Impression + +L'imprimante en elle-même marche très bien (beaucoup mieux que l'ancienne), mais +les drivers de canon chient. + +Par ailleurs, toutes les ~100 pages imprimées, si elles restent dans le bac, +l'imprimante s'arrête et attend que quelqu'un les enlève du bac de sortie. +C'est très gênant pour les grosses impressions de rentrée. + +#### Intranet + +C'est de l'AJAX avec !MochiKit. Adg s'est un peu penché dessus, et apparemment +il va réussir à le migrer vers !CherryPy de lenny. + +#### Téléphonie + +Vous allez être mis en communication avec votre correspondant, merci de +patienter quelques mois... + +Le Crous a demandé à son FAI de s'occuper aussi d'un service de téléphonie sur +IP, et voudrait qu'on ne soit pas en concurrence avec lui. + +### Questions diverses + +#### Répartition des clés + +Michel aimerait avoir une clé du 0B. Il faut que Jérémie rende ses clefs du +Cr@ns. + +En particulier pour les clés du 4J, il faudrait essayer de savoir exactement où +sont les clés, et récupérer celles des gens qui ne les utilisent plus... +Comme tous les ans ? + +Xavier pense développer, sur la même base que les modules de reboot et le +digicode, des serrures RFID qui remplaceraient avantageusement les 16 clés du 4J +qui se baladent dans la nature (et même, peut-être, des autres locaux +associatifs ?). + +#### Crous + +Des discussions ont eu lieu avec le FAI, qui accepte de nous laisser gérer le +routage, le filtrage et les logs. diff --git a/compte_rendus/2009_10_22.md b/compte_rendus/2009_10_22.md new file mode 100644 index 0000000..2adafeb --- /dev/null +++ b/compte_rendus/2009_10_22.md @@ -0,0 +1,81 @@ +# Réunion Nounous + +* Date : 22 Octobre 2009 +* Lieu : Pavillon des Jardins +* Début : 19h30 +* Fin : <> + +## Présents + +* Antoine Durand-Gasselin +* Damien Aza-Vallina +* Johan Grande +* Michel Blockelet +* Nicolas Dandrimont +* Raphaël Bonaque +* Raphaël Cauderlier +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Point technique sur la convention Cr@ns - CROUS + +### Bâtiment G + +#### Réseau Filaire + +#### Couverture WiFi + +On a mis des bornes sur le J, on a l'accord de principe de l'ENS pour arroser +la façade ouest du G depuis le toit du Cournot. + +#### Pont WiFi + +Le cdcf c'est un pont chiffré: openWRT pourvoit un mode spécifique + +### Ragnarok (maj, fuites de memoire) + +Il *faut* mettre à jour Ragnarok. +Il faudra vérifier radius et munin qui sont actuellement les générateurs +d'occupation mémoire. + +### Accès aux backups des homes des adhérents + +Il faut y réfléchir avant la migration de zamok. Il faut réfléchir à : + +* La réutilisation potentielle des uid (qu'un nouvel adhérent ne se retrouve + +pas avec les backups d'un ancien dont le compte a été supprimé) + +* A ce que l'espace de stockage ne soit pas virtuellement infini. + +### Serveurs Free + +Xavier se propose pour aller les chercher la semaine prochaine avec les gens +intéressés. Ce sont des serveurs 1U, sans disques durs (on les ferait booter +depuis le réseau). + +### Organisation des séminaires techniques + +On pourrait ajouter un séminaire sur le firewall prochainement, ou pas. Pour les +séminaires suivants, il faudrait essayer d'encadrer un peu mieux et que les +séminaires soient un peu moins abstraits. + +### Projets Apprentis + +* "recoder munin" +* dns pour les vieux +* VoIP (ou pas) +* recoder l'intranet +* faire des enregistrements pour un GlaDOS à la ferme +* débugger la pute d'imprimante +* IDS / monitoring +* ... Ce qui vous plairait ? + +### Installation de fz + +* Les homes montés dans l'hôte, qui les distribuerait directement aux jails. + (on partirait donc sur une architecture de jailing). On pourrait tester openvz + et/ou vserver. On fera des tests sur fz, jusqu'à ce que ça semble stable et on + procédera à la migration de zamok. diff --git a/compte_rendus/2009_12_10.md b/compte_rendus/2009_12_10.md new file mode 100644 index 0000000..488f3d8 --- /dev/null +++ b/compte_rendus/2009_12_10.md @@ -0,0 +1,103 @@ +# Réunion + +* Date : 10 Décembre 2009 +* Lieu : Pavillon des Jardins +* Début : 19h30 +* Fin : 21h35 + +## Présents + +* Antoine Durand-Gasselin +* Dominique Delport +* Jean-Benoist Leger +* Jérémie Dimino +* Nicolas Dandrimont +* Olivier Iffrig +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Connexion de fortune bâtiment G + +#### Couverture WiFi + +Actuellement le batiment G est arrosé sur sa façade est. Il devrait +être possible de s'arranger avec le dpt info pour installer des bornes +au Cournot. Il faudrait étudier l'installation au sol de bornes avec des +antennes Hyperlink (17dB, 120°, aucun bruit à l'arrière). + +Les vitres du bâtiment G atténuent beaucoup le signal (quid de demander +aux adhérents d'installer une antenne ?). + +Avec la solution actuelle basée sur des linksys WRT54g on ne peut +dépasser une quinzaine de clients par bornes. Les bornes bullet +d'ubiquiti peuvent être un nouveau matériel intéressant vers lequel se +tourner. Possibilité de pont wifi, support de beaucoup plus de clients. +Ces bornes, nouvelles, utilisent le 802.11n, et permettent d'atteindre +300Mb/s réel. Les prix sont tout à fait corrects (50-100€). + +D'un point de vue légal, il devrait être tout à fait possible de +respecter les réglementations en vigueur en matière d'émission +hertzienne. + +### Installation de fz + +Utilisation d'une solution de containers (OpenVZ ou vserver...). + +Il y aurait : + +* Un container pour les adhérents +* Un container pour les services mail +* ... + +### Déconnexion mail invalide + +Michel n'est pas là pour nous en parler... + +### Modifications de la base LDAP + +#### Autorisation de la modification d'attributs dans le sous-arbre des + +adhérents + +Ceci permettrait de modifier plus proprement les données de l'adhérent +depuis l'intranet, qui n'aurait plus à être lancé en tant que respbats. + +Il faut étudier comment faire ça proprement avec les ACLs de LDAP (création +d'une vue spécifique). + +#### IPv6 + +On donne un /64 par machine (fixe) inscrite dans la base LDAP. Ceci sera fait à +la demande (champ booléen dans la machine). + +Le préfixe IPv6 est donné comme suit : +[préfixe crans (n bits)]:[mid (p bits)]::/64 + +#### Cleanup Type de connexion + +Ce champ permettrait de formaliser le champ "Connexion Gratuite / Appartements +ENS / ..." qui est un peu mis de manière anarchique dans la base. + +#### Compte wiki + +Ceci permettrait de lier le compte Cr@ns et le compte Wiki, en permettant +l'authentification directe via LDAP en gardant le WikiNom associé. + +On n'imposerait pas de compte Cr@ns pour le compte Wiki. + +#### VLAN Custom + +Permettrait de stocker les VLAN a ajouter sur une prise pour la DSI... On va +stocker ça dans annuaire.py. + +### Modules de détection de mouvements + +Il faut des paires de mains pour peupler les cartes. Ça serait à commencer à la +fin de la semaine prochaine (mercredi ou jeudi), et à finir avant dimanche +prochain. + +### Questions diverses + +N/A diff --git a/compte_rendus/2010_01_14.md b/compte_rendus/2010_01_14.md new file mode 100644 index 0000000..eb89105 --- /dev/null +++ b/compte_rendus/2010_01_14.md @@ -0,0 +1,181 @@ +# Réunion Nounous + +* Date : Jeudi 14 Janvier 2010 +* Lieu : Pavillon des Jardins +* Début : 19h40 +* Fin : -- WikiMichou <> + +## Présents + +* Antoine Durand-Gasselin +* Augustin Parret-Fréaud +* Jérémie Dimino +* John-Eric Dufour +* Michel Blockelet +* Nicolas Dandrimont +* Olivier Huber +* Olivier Iffrig +* Pierre Chambart +* Raphaël Cauderlier +* Stéphane Glondu +* Xavier Lagorce + +## Ordre du jour + +### Compte-rendu de l'intervention au bâtiment G + +#### État des fibres + +La connexion a été rétablie. On a un débit de 930Mb/s. +On recevra les tests faits par les techniciens plus tard. + +#### Configuration des switchs + +Il y a un problème avec batg-0. Il a été remis dans sa configuration d'usine +(sous laquelle il fonctionne). + +#### Câblages physiques + +Tous les gens qui ont demandé la connexion Cr@ns l'ont eue. + +Il faudra câbler physiquement les gens quand la connexion Crous sera dans tous +les bâtiments. Pour l'instant c'est les nounous qui le font le soir. +Ça reste comme ça tant que c'est gérable. + +#### Rangement des locaux + +Il aura lieu samedi à 14h. + +### Problèmes récurrents / maintenances + +#### IMAP + +L'imap chie dans la colle. On ne sait pas pourquoi. Apparemment le DomU swappe +beaucoup. On lui rajoute un giga de ram et on voit si ça va mieux... + +Récemment des homes n'étaient pas créés. Il faut surveiller ça. + +#### Impression + +Il y a des traces noires de pire en pire sur les impressions, personne +ne s'en est vraiment occupé. + +Jérémie les appelle demain. + +#### Proxy + +Des gens ont constaté des lenteurs et des erreurs sur le proxy. + +Un des problèmes: ipv6 sur sable qui se choppe des annonces bizarres. +En les retirant ça marche mieux. Le souci était le DNS, qui vient faire des +requêtes d'adresses AAAA sur des serveurs racine en ipv6... *boom* + +#### bata-3 + +[Chie](http://munin.crans.org/switchs.crans.org/bata3.adm-ping_bata_3_adm.html) + +#### Bâtiment H ? + +Il faudrait revenir vers les gens pour être sûrs que c'était bien le problème de +proxy... + +### Évolution des services + +#### Intranet + +Un nouvel intranet a commencé à voir le jour. +Il est disponible sur (pour l'instant, il n'y a +que la gestion du câblage des prises). + +C'est sur o2, dans /usr/local/django/intranet (dépôt darcs) + +Il ne reste plus qu'à développer des applications... + +#### Modifications de la base LDAP + +* Remaniement des ACLs + * Autorisation de la connexion des adhérents avec leur compte Cr@ns + * Autorisation de la modification d'attributs dans le sous-arbre des + adhérents +* Modification des attributs + * IPv6 + * Adresse IP : L'adresse IP(v4,6) d'une machine est calculée par le mid, + il y aura un champ "adresse IPv6 custom en plus" pour les machines ne + respectant pas la convention (voir + le [[CransTechnique/PlanAdressage#Machines|plan d'adressage]] sur le + wiki, les scripts ne sont pas encore adaptés (en cours par Stéphane)) + * Cleanup Type de connexion : chaîne de caractères dans adherent + * adhérent gratuit/payant/personnel ENS/autres + * la base n'est pas encore peuplée + * Compte Wiki : chaîne dans le compte crans + * mailInvalide : timestamp dans adherent (au lieu d'un booléen) + * DNS IPv6 : ajout d'un champ booléen (par machine) pour activer le DNS + IPv6 pour l'adresse sur le /64 du vlan par défaut. + * DNS (crans.eu) : nouvelle arborescence contenant un nom, une adresse et un + propriétaire (compte crans). + * .crans.eu + * .ipv6.crans.eu : sous-arbre spécial de délégations vers les serveurs + DNS pour leur /64 ipv6 + +#### Installation de fz + +Il faut le faire. Cf. le tracker. + +#### Télévision + +* Multiswitch... + * Olivier l'installera avant de partir. + * Il faut en profiter pour vérifier la qualité de réception, certaines + cartes ont des problèmes. +* Unicast pour diagnostiquer chez les adhérents se plaignant de problèmes de + multicast +* Transcoding pour faire de la télé over WiFi : à tester sur les serveurs de + free, faut leur coller une carte TV +* IPv6 ? +* Satellite a : il faut voir avec le + CROUS pour la pose d'une nouvelle antenne. + +#### DNS + +Il faudrait reprendre l'architecture DNS du Cr@ns. En effet, les serveurs DNS +autoritaires et les serveurs de cache sont les mêmes. + +Il faut séparer les serveurs cache et les serveurs autoritaires pour les zones +Cr@ns. + +Serveurs cache : + +* sable +* gordon +* titanic (patte interne, requêtes DNS des appartements) + +Serveurs primaires : + +* sila : crans.org, crans.eu, *.in-addr.arpa (filaire), *.ip6.arpa (filaire), + wifi.crans.org, *.in-addr.arpa (wifi), *.ip6.arpa (wifi) +* mdr : tv.crans.org, *.in-addr.arpa (multicast) +* sila : adm.crans.org, 136.231.10.in-addr.arpa + +On fait un miroir des serveurs autoritaires sur : + +* ovh (évidemment) +* freebox (patte externe) + +On pourra ajouter du DNSSec plus tard. + +#### Wifi + +* Achat de nouvelles bornes + * On va faire les courses chez landanet +* Déploiement + +### FAI RUBIS + +#### Organisation de la réunion Katy Tréca / Cr@ns + +Une réunion a été fixée pour le mercredi 20 à 16h, probablement dans le bureau +de Katy Tréca. + +Nicolas mettra le compte-rendu de la réunion Berlinoise en ligne sous peu. + +### Questions diverses diff --git a/compte_rendus/2011_05_05.md b/compte_rendus/2011_05_05.md new file mode 100644 index 0000000..e849d41 --- /dev/null +++ b/compte_rendus/2011_05_05.md @@ -0,0 +1,137 @@ +# Réunion Nounous + +* Date : Jeudi 5 mai 2011 +* Lieu : Salle Condorcet +* Début : 19h10 +* Fin : 21h01 + +## Présents + +* Antoine Durand-Gasselin +* Daniel Stan +* Jérémie Dimino +* Michel Blockelet +* Nicolas Dandrimont +* Sylvain Boilard +* Valentin Samir +* Vincent Maioli +* Xavier Lagorce + +## Ordre du jour + +### Entrevue avec la DSI + +Lundi 9 mai à 14h30 entrevue avec Stuart. Nicolas y va accompagné de Daniel et +Valentin. + +Ordre du jour : + +* Gigabit +* WiFi + * Repeuplement du Cournot + * Annonce du réseau Cr@ns sur les bornes aruba + * Réinstallation de bornes à l'ENS +* Connexion des Appartements +* IPv6 +* Peer to peer + +### WiFi + +#### Mises à jour + +Le WiFi doit être remis en état de marche correct pour la rentrée. + +* SSID Multiples (n > 2) +* IPv6 +* WiFi N + +Points techniques + +* OpenWRT +* Firmware à jour +* Firmware "universel" (configuration de la borne par DHCP) + +Possibilités : + +* Identification par compte Cr@ns, voire double authentification (compte Crans + OU compte spécifique wifi) + +À faire : + +* Mise en place d'une infrastructure de test (vlan séparé, serveur radius + séparé sur un domU, ...) +* Tests de firmwares sur les bornes actuellement en train de prendre la + poussière au 2B +* Achat de nouvelles bornes (soit de tests si les bornes actuelles sont + merdiques, soit en série) + +Les tests vont commencer quand les gens voudront. + +#### Repeuplement du Cournot + +Les A0 veulent une borne en C411 (elle y est, il faut juste la router vers le +réseau Crans). + +Il faut demander à la DSI de router le vlan 3 au bon endroit. + +#### Fixations des bornes du toit du J + +Le feuillard en alu est acheté, il faut trouver les fixations qui n'étaient pas +dans le même rayon. + +Pour l'installation, il faut voir avec Isabelle (du CROUS). + +### Connexion appartements + +Il y a vraiment des bugs bizarroïdes. Quelques possibilités à évoquer avec +Stuart : + +* Passer les personnels directement sur la connexion Cr@ns. Cela règlerait de + manière + +avantageuse le problème du monitoring de la connexion. + +* Multiplexer n freeboxes. La question : où les mettre, et si free va pas faire + la gueule. + +Il reste aussi à développer le système de load-balancing. Le point de sortie +pourrait être une dedibox SC de chez online.net. + +On verra ça lundi avec Stuart. + +### Mises à jour de serveurs + +Vincent a fait une mise à jour (mais d'un serveur qui sert à rien) \o/ + +Michel s'occupera de pgsql quand il aura la bonne idée de ne pas tomber malade. + +fx sera mis à jour quand on migrera les /home. + +Rappel : les domU mis à jour sont à migrer sur fz pendant leur mise à jour. + +### IPv6 + +Il serait temps d'activer l'IPv6 de manière globale et automatique. + +Ce qui est release critical : + +* Filtrage des RA pirates (vieux et fait) +* Firewall v6 (fait modulo port 80) + * Désactiver le proxy transparent pour l'IPv6. On peut revoir à fournir un + fichier de configuration de proxy si les gens le souhaitent (oh noes, they + will never do it). +* Adaptation des scripts (de surveillance) + * Upload : fait, pas de déconnexion automatique mais le mail de stats est lu + tous les jours. + * P2P : il faut trouver une solution de level7 filtering compatible IPv6. + Pas nécessaire immédiatement +* DNSv6 +* Configuration de radvd et d'un DHCPv6 pour avoir un peu plus qu'un routeur + sur IPv6. + +### Questions Diverses + +#### Problèmes de Webmail/dovecot + +Dovecot avait du mal à cause d'une limite sur le nombre de fichiers ouverts. +Ça a été réglé en augmentant la limite de fichiers ouverts par root. diff --git a/compte_rendus/2011_05_19.md b/compte_rendus/2011_05_19.md new file mode 100644 index 0000000..7867808 --- /dev/null +++ b/compte_rendus/2011_05_19.md @@ -0,0 +1,92 @@ +# Réunion Nounous + +* Date : Jeudi 19 mai 2011 +* Lieu : Pavillon des Jardins +* Début : 19h20 +* Fin : 20h07 + +## Présents + +* Daniel Stan +* Michel Blockelet +* Nicolas Dandrimont +* Sylvain Boilard +* Valentin Samir +* Vincent Maioli + +## Ordre du jour + +### Mises à jour + +La mise à jour de fx doit être terminée. Ça sera fait samedi soir. + +radius et xmpp ont été mis à jour. + +Vincent s'occupera d'ovh d'ici la fin de semaine. + +### Intranet 2 + +Daniel a avancé sur l'interface de gestion des accès. Ça ne sera pas prêt à être +présenté demain, mais bientôt. + +Cahier des charges : + +* Enregistrement d'interventions +* Édition des interventions futures +* Listing des interventions par local + +Voir avec C. Lebailly pour ce qu'ils veulent. + +Futur : + +* Interfaçage avec les caméras / détecteurs de mouvement +* Badgeuse ? + +### IPv6 + +Le DNS a été configuré, et un radvd a été mis en place sur komaz. + +Ça marche bien sur les systèmes d'exploitation qui n'en ont rien à foutre de la +vie privée de leurs utilisateurs (et qui gèrent bien IPv6). + +Plusieurs possibilités sont envisageables : + +* Mise en place d'un DHCPv6 + * Distribution d'adresses d'autoconfiguration +* Suppression de la règle droppant les paquets qui font la correspondance + MAC - IPv6 + * La règle qui fait le matching sur les adresses mac existe déjà. Il faut + juste garder la correspondance entre les MAC et les IPv6 dans une base de + données. + +Il faut mettre en place un outil de monitoring, par exemple ndpmon, pour garder +trace des associations MAC - IPv6. + +Il faut évaluer les conséquences de mettre en place le DHCPv6, notamment sur la +simplicité de configuration. + +### WiFi + +Ça n'a pas avancé depuis la dernière fois. + +### Télévision + +On va passer au 4J faire une vérification des branchements. + +Pour les nouvelles cartes en USB, des tests ont été faits. Apparemment ça ne +chauffe pas trop. Il faut maintenant tester avec une sheevaplug. + +### Ajouts de droits + +Nicolas propose d'ajouter les droits Nounou à Daniel et Valentin. + +### Questions diverses + +#### Fixations des bornes + +Daniel est repassé à Casto et les trucs de fixation ont l'air de suxer. Daniel +propose une solution alternative, mais qui est vraiment overkill pour seulement +deux bornes (> 100 euros de tendeur)... + +On réévaluera la nécessité de ces bornes quand la couverture intérieure du +bâtiment G existera. diff --git a/compte_rendus/2011_09_15.md b/compte_rendus/2011_09_15.md new file mode 100644 index 0000000..294a8af --- /dev/null +++ b/compte_rendus/2011_09_15.md @@ -0,0 +1,109 @@ +# Réunion Nounous + +* Date : Jeudi 15 septembre 2011 +* Lieu : Pavillon des Jardins +* Début de la réunion : 19h20 +* Fin : 20h06 + +## Présents + +* Aurore Moisy-Mabille +* Aurore Quelennec +* Benjamin Aupetit +* Daniel Stan +* Louis Bondaz +* Nicolas Dandrimont +* Olivier Iffrig +* Raphael Bonaque +* Raphael Cauderlier +* Steven Masfaraud +* Sylvain Boilard +* Valentin Samir +* Vanessa Verbeke +* Yann Duplouy + +## Ordre du jour + +Après un tour de table, on entame l'ordre du jour. + +### Responsable Technique en Chef + +Sur proposition du RTC sortant, le collège des Nounous approuve la nomination +d'Olivier Iffrig comme nouveau Responsable Technique en Chef. + +### Recrutement + +Bienvenue aux nouveaux (-; +Les droits apprenti leurs seront donnés à la fin de la réunion, après un +discours sur ce que ces droits permettent de faire de mal, et lecture de la +charte des membres actifs. + +### Séminaires + +On va tenter de reprendre le rythme précédent d'un séminaire par semaine. + +| Date | Thème | Intervenant | Encadrant | +|-----------------|----------------------------------|-------------|-------------------| +| 4 octobre 2011 | Présentation du réseau Cr@ns | WikiIota | NicolasDandrimont | +| 11 octobre 2011 | Réseaux, Ethernet, TCP/IP | WikiLxir | TotoPassoir | +| | Le Shell, SSH | | WikiB2moo | +| | Administration réseau sous Linux | | NicolasDandrimont | +| | Python | | WikiIota | +| | Les scripts du Cr@ns | | | +| | WiFi | | | +| | Firewall | | WikiNit | +| | IPv6 | | NicolasDandrimont | +| | La base LDAP | | | +| | Virtualisation | | | +| | Versionnement | | | +| | Bcfg2 | | | +| | Intranet 2 | | | +| | DNS | | | +| | TV + Multicast | | | +| | GPG | | | +| | Monitoring | | | +| | Wiki | | | + +### WiFi + +Une séance de travail est prévue ce samedi 17 septembre à partir de 14h, +venez au 2B. Les bornes actuelles se font de plus en plus vieilles, on envisage +différentes bornes, mais elles ont besoin d'un firmware fonctionnel pour pouvoir +être déployées. + +Il faut d'abord considérer la mise à jour des bornes actuelles. "Il y a des +chances +que ça n'empire pas la situation." + +### Nouvelle interface de gestion "gest_crans" + +Olivier entreprend depuis un certain temps une mise à jour de l'outil gest_crans +qui est le script que les câbleurs utilisent pour effectuer la gestion des +adhérents. + +Une idée envisagée est de passer à une interface client - serveur pour pouvoir +faire plusieurs front-ends (intranet, script de gros geek, ...) + +Olivier envisage de le faire tout simplement en HTTPS, avec un retour des +données en JSON ou xml... + +Valentin propose de faire une séance de travail sur le binding ldap afin de le +rendre utilisable en conditions réelles. Elle aura lieu le 1er octobre. + +### Connexion appartements + +Ça marche mal. On a eu deux rapports de problème depuis le début du mois, encore +non traités. Il faut prendre contact avec les habitants pour tester. + +Olivier et Daniel sont volontaires pour s'en charger. + +### Questions diverses + +#### Configuration automatique du WiFi sous Windows + +Valentin est en train d'investiguer netsh afin de proposer un outil automatique +et graphique de configuration de la connexion WiFi sous Windows (XP, Vista, 7). + +L'outil permettrait de configurer automatiquement la connexion WiFi sous ces OS, +afin de simplifier le câblage des adhérents, et d'éviter les retours et la +dégradation de l'expérience de câblage. diff --git a/compte_rendus/2011_09_29.md b/compte_rendus/2011_09_29.md new file mode 100644 index 0000000..61217f3 --- /dev/null +++ b/compte_rendus/2011_09_29.md @@ -0,0 +1,98 @@ +# Réunion Nounous + +* Date : Jeudi 29 Septembre 2011 +* Lieu : Amphi Condorcet +* Début de la réunion : 19h21 +* Fin : 20h42 + +## Présents + +* Benjamin Aupetit +* Benjamin Schmitt +* Daniel Stan +* Nicolas Dandrimont +* Olivier Iffrig +* Raphaël Cauderlier +* Steven Masfaraud +* Sylvain Boilard +* Valentin Samir +* Xavier Lagorce +* Yann Duplouy + +## Ordre du jour + +### WiFi + +Le workshop d'il y a 15 jours a été pas mal productif. On a des firmwares à peu +près fonctionnels sur les deux types de bornes. + +Pour les anciennes WRT54G: + +* Multi SSID: impossible +* Le reste fonctionne (sauf les bornes) +* IPv6 non testé, pas de raison a priori que ca ne marche pas. + +Pour les nouvelles: + +* Tout marche, sauf... +* récupérer de l'entropie sur la borne, car le réseau n'est pas une source sûre + +d'entropie, et il n'y a pas d'autres sources disponibles. (urandom ou rng-tools) +Ce problème est soluble (comme le café), et la mise en place ne devrait donc pas +poser de problème majeur à partir de là. + +Il faut maintenant faire des tests de couverture (genre au G), puis faire des +devis pour le CA, assez rapidement, et aussi trouver où on peut les poser. + +On propose un devis pour le CA de la semaine prochaine afin d'acheter des pico +et nanostations qui ont le même chipset que les bullet dans un form factor +vachement plus cool, pour tester. + +### Séminaires + +Le premier est mardi, les apprentis doivent venir et s'inscrire pour les +suivants. + +### Connexion des appartements + +La connexion de la porterie a été rétablie. Le switch a bloupé. + +La connexion au cournot est bugguée du côté DSI, selon les diagnostics d'Olivier +(le vlan 21 sort de multiprise_wifi, et n'arrive manifestement pas au cournot). + +Il faut relancer la DSI, Olivier s'en occupe. + +### Déconnexion P2P + +On a reçu un mail (forwardé) de la DSI nous informant d'un trafic bittorrent +provenant d'une ip Cr@ns (celle d'un adhérent). Le mail provient d'une société +américaine. + +Les nounous font déjà leur possible pour bloquer le trafic bittorent. Les +sanctions envers l'adhérent sont à décider par le CA. + +### Questions diverses + +#### Workshop scripts + +La séance prévue Samedi prochain est déplacée au 08/10 pour cause +d'indisponibilité générale. + +#### Association MAC-IPv6 + +Récupérer les NA ne serait pas optimal pour faire cette association (risque +d'usurpation), il serait bon de trouver une autre solution ou un colmatage. + +On teste le DHCPv6. + +#### Bornes du toit du J + +Ca fait longtemps que l'on a promis au CROUS de mieux les fixer. On regarde si +ce sont des habitants du G ou du J qui les utilisent. + +#### Workshops + +Le format des workshops permet d'avancer sur les services, mais permet-il la +formation des nouveaux ? +Daniel propose de lancer des "petits projets" sur des modules de l'intranet 2, +qui permettent de toucher au LDAP, etc, tout en étant indépendants. diff --git a/compte_rendus/2011_10_31.md b/compte_rendus/2011_10_31.md new file mode 100644 index 0000000..a577812 --- /dev/null +++ b/compte_rendus/2011_10_31.md @@ -0,0 +1,190 @@ +# Réunion Nounous + +* Date : Jeudi 13 Octobre 2011 +* Lieu : Salle Condorcet +* Début : 19h14 +* Fin : 21h34 + +## Présents + +* Aurore Quelennec +* Benjamin Aupetit +* Daniel Stan +* Judith Robson +* Michel Blockelet +* Nicolas Dandrimont +* Olivier Iffrig +* Raphaël Cauderlier +* Steven Masfaraud +* Sylvain Boilard +* Valentin Samir +* Vanessa Verbeke +* Xavier Lagorce + +## Ordre du jour + +### Wifi + +#### Nouvelles bornes + +Les nouvelles bornes sont arrivées mais (petite) déception: le chipset wifi +n'est pas le même... Iota a réussi à compiler une image pour ces bornes et à +booter dessus, il n'y a pas de raison que le WiFi ne fonctionne pas. D'ailleurs, +il y a de l'entropie. Il y en a 3 autres à tester, avis aux volontaires. + +Les tests de portée sont à effectuer. Il faut voir si ça passe en ligne droite +(dans un couloir ?) puis entre les étages (car on a que deux locaux techniques +au G...) + +#### Audit de la couverture actuelle + +Il faut parcourir le campus afin de récupérer l'état de la couverture wifi. +On peut aussi essayer de faire des stats pour voir où les gens se connectent. + +Daniel s'occupe de l'extérieur. Raphaël s'occupe de cartographier où les gens +se connectent. Steven s'occupe de l'intérieur. + +#### Bornes sur le toit du bâtiment J + +Les bornes sur le toit du bâtiment J et arrosant le bâtiment G n'arrosent pas +le bâtiment G... En effet, le revêtement des fenêtres empêche la propagation +des ondes wifi. Des clients sont toutefois connectés sur ces bornes, +il faudrait donc les laisser. + +On ne peut pas les laisser en l'état (car elles sont "mal" accrochées), on a le +choix entre les fixer correctement, installer d'autres bornes (nanostation ?) +qui devront elles aussi être fixées correctement, ou ne rien mettre. + +On va attendre le résultat des tests de couverture. + +#### Détection des réseaux pirates + +Il y a deux semaines et demi, un réseau WEP de SSID "Cr@ns" a été détecté sur le +campus, émis par plusieurs MACs différentes. Le réseau était annoncé moins d'une +minute à chaque fois. + +Raphaël essaie d'utiliser les bornes WiFi afin de détecter l'origine du réseau +bizarre. + +### Workshop Scripts + +Il n'a manifestement pas eu lieu. (On a trié des fiches d'adhésion/réadhésion.) +On fait une première session jeudi 20 octobre pour vérifier le fonctionnement du +nouveau binding LDAP et corriger les bugs manifestes. + +### Proxy + +* Caching des vidéos youtube : ce n'est pas possible facilement, il faudrait + avoir un serveur Web "cache" à côté. De toute façon, le débit consommé n'est + pas forcément si important que ça par rapport au reste du trafic. +* (null)://toto : parfois, quand on charge une page, il arrive que le proxy + retourne une erreur parce qu'elle essaie d'utiliser le protocole "(null)". + C'est une erreur a priori liée au proxy transparent. Il faut que quelqu'un + prenne ses petits doigts musclés et écrive un bug report. +* Pages pour les gens déconnectés pour virus : Michel propose que la page de + déconnexion apporte plus d'informations notamment quant au virus. Pour ce + faire, on pourrait faire une section dans l'intranet où on pourrait mettre + les logs de déconnexion et les instructions à suivre pour désinfecter. + +### Connexion des appartements de fonction + +Le Cournot remarche, Iris ne marche plus. +Il faut contacter la personne qui rencontre des problèmes afin de savoir ce +qu'il en est. Il faudrait aussi en profiter pour leur dire de nous contacter +directement et de nous tenir au courant quand ça refonctionne tout seul. +On peut profiter de la campagne de réadhésion pour faire ça. + +### Impression + +Daniel a modifié l'interface d'impression, entre autres pour la rendre plus +stricte. Elle n'accepte plus les dimensions exotiques, ce afin d'éviter les +affiches occupant 1/100e de la page. + +On va utiliser le biniou d'adg qui se connecte à l'interface d'impression +directe. + +#### Problèmes avec l'imprimante + +Il faut contacter print platinium pour + +* échanger les rouleaux +* échanger l'imprimante +* échanger de partenaire *kof* *kof* + +### DHCPv6 + +Personne ne s'est occupé de tester le DHCPv6. Il est décidé de le configurer en +utilisant les adresses IP d'autoconfiguration, pour des questions de simplicité +du firewall. + +### Questions diverses + +#### Communication + +Il faudrait faire, à chaque inter-nounou, ''vraiment'' faire un bilan de ce qui +a été fait. Ça permettrait d'avoir une trace écrite. + +Nicolas propose que chacun tienne un journal de bord, afin d'écrire au jour le +jour ce que chacun a fait au Cr@ns. Ensuite, on fait une synthèse lors des +internounous. + +#### Mises à jour vers squeeze + +Il faut continuer. Le support de sécurité de lenny s'arrête en février 2012. + +Michel se propose d'encadrer les bonnes âmes voulant s'en charger. Aurore se +porte volontaire. + +#### Install-party + +L'install-party campus aura lieu le 19 novembre. La vraie aura lieu le 14 +janvier. + +Il faut que quelqu'un pense à mettre à jour le netboot avant l'install-party (et +non pendant...). + +On peut graver des CD d'Ubuntu. + +#### Réunion avec la DSI + +Il faut prévoir rapidement une réunion avec la DSI, pour parler de : + +* Gigabit +* Connexion des appartements +* Rationnalisation de la connexion Cr@ns-ENS +* WiFi + +Le RTC est volontaire. + +#### Inondation, comment redémarrer les serveurs + +Premier problème : les nounous ne savent pas dans quel ordre redémarrer les +serveurs. Deuxième problème : même avec une nounou qui sait dans quel ordre +redémarrer les serveurs, un redémarrage prend une bonne heure, alors qu'il +pourrait être beaucoup plus rapide. + +Un ordre de redémarrage des serveurs doit être écrit, rapidement. + +Une solution plus pérenne serait de décrire les dépendances entre services dans +un init script lancé très tôt et qui attendrait de pouvoir se connecter aux +services en question avant de continuer le boot. Un script de la même espèce que +"attendre-vert", mais 2.0. + +Une autre solution serait de faire un "maître d'orchestre" qui autorise les +serveurs à booter séquentiellement. + +Judith se porte volontaire. + +#### Comment éviter les problèmes à base de 0.0.0.0 + +Un adhérent a décidé de mettre une adresse ip 0.0.0.0, ce qui a beaucoup +perturbé la détection de conflits d'adresse ip de windows. + +Michel voudrait qu'une adresse ip bidon soit mise en place, qui n'est pas +vraiment +utilisée, et qui soit utilisée pour détecter des comportements bizarres : + +* Si une machine répond aux requêtes ARP pour cette machine, elle se comporte + bizarrement +* Si une machine essaie de se connecter à l'ip bidon, la machine se comporte + bizarrement diff --git a/compte_rendus/2011_11_03.md b/compte_rendus/2011_11_03.md new file mode 100644 index 0000000..9078700 --- /dev/null +++ b/compte_rendus/2011_11_03.md @@ -0,0 +1,176 @@ +# Réunion Nounous + +* Date : Jeudi 3 novembre 2011 +* Lieu : Pavillon des Jardins +* Début : 19h19 +* Fin : 21h08 + +## Présents + +* Daniel Stan +* Michel Blockelet +* Nicolas Dandrimont +* Olivier Iffrig +* Raphaël Cauderlier +* Steven Masfaraud +* Valentin Samir +* Vanessa Verbeke +* Vincent Maïoli +* Xavier Lagorce +* Yann Duplouy + +## Ordre du jour + +### Encadrement des apprentis + +Selon le règlement intérieur du Cr@ns, chaque apprenti doit avoir une Nounou qui +l'encadre et qui est responsable de lui. + +Les absents ayant toujours tort, on va assigner des encadrants de force : + +* Benjamin A. sera encadré par Nicolas D. +* Julien sera encadré par Raphaël +* Sylvain sera encadré par Olivier +* Yann sera encadré par Valentin +* Johan sera encadré par Michel +* Jonathan sera encadré par Raphaël +* Vincent L.G. sera encadré par Daniel +* Steven sera encadré par Nicolas D. +* Aurore MM. sera encadré par Raphaël +* Luc sera encadré par Vincent M. +* Aurore Q. sera encadrée par Michel +* Judith sera encadrée par Michel +* Vanessa sera encadrée par Xavier +* Larissa sera encadrée par Olivier +* Pierre-Elliott sera encadré par Daniel + +### STEF + +Un représentant du STEF est venu il y a 2 semaines à la réunion CA pour proposer +au Cr@ns de participer à leur cycle de séminaires en faisant une présentation, +par exemple sur le logiciel libre. + +Il n'y a pas de volontaires. + +### Astreintes des nounous + +Chaque jour ouvré, les Nounous sont d'astreinte pour aider les câbleurs en cas +de problème. On a fini de remplir le planning de permanences. + +### Munin + +Dyson a été mis à jour vers squeeze grâce à Vincent et Sylvain. La config de +munin a été copiée sur Dyson, qui a fonctionné 24h avant de planter... +Apparement, cela ne marchait pas beaucoup plus vite (problème de config ?) que +sur le DomU. + +On peut regarder soit du côté de munin 2 qui serait plus efficace, soit on peut +essayer de reprendre à zéro, en prenant peut-être un autre outil de monitoring. + +### Recrudescence du peer-to-peer + +On a reçu ces derniers temps plusieurs mails de la DSI à propos de machines +faisant du p2p, ce qui a mis en évidence un problème au niveau du firewall, dû à +deux problèmes : la partition de /var/log était plein, ce qui empêchait les +scripts de voir qui fait du p2p; et au niveau du firewall, les paquets n'étaient +pas bloqués. + +Pour ce qui s'agit des logs du syslog refiltrés derrière, on réfléchit à une +solution pour ne pas avoir à écrire des logs. + +Olivier s'occupe d'envoyer un mail à la DSI. + +### WiFi + +#### Audit de la couverture + +Raphaël et Steven se sont baladés dans le bâtiment B pour chercher les zones +d'ombre. C'est surtout à l'aile du 3e étage que la couverture est mauvaise. + +Daniel a commencé à coder une interface en Open Layers pour afficher et +enregistrer les données de couverture. + +#### Mise à jour des bornes + +Nicolas a fait un firmware à jour qui fonctionne pour les anciennes bornes, et +qui règle le problème du cache des authentifications ratées. Il faudrait le +déployer sur toutes les bornes. + +#### Configuration automatique des bornes + +Avant, les bornes récupéraient automatiquement leur configuration. On peut +profiter de la mise à jour à faire pour se pencher sur le sujet. + +### Script de détection des déménagements + +/usr/scripts/surveillance/demenagement.py à remettre en marche sur les serveurs +radius. + +### Choses à faire au Cr@ns + +Il y a plein de choses à faire au Cr@ns, et les jeunes ne se motivent pas trop +pour se pencher dessus, parfois par manque de connaissances. + +Olivier propose de faire une liste des choses à faire sous forme d'arbre. Ça +rejoint l'idée de faire un recensement de tous les services sur chacun des +serveurs. + +Les choses à faire ne sont pas forcément de nouveaux services à mettre en place, +mais aussi des petits problèmes au jour le jour à régler, ce qui est souvent +fait par les mêmes personnes. Il faudrait que les plus jeunes se sentent plus +impliqués. + +Le problème du tracker est qu'il est trop complexe, et accessible principalement +par l'interface web, et aussi par mail. Nicolas propose d'utiliser debbugs. + +Ça peut aussi être bien d'avoir un bot IRC permettant de signaler facilement via +IRC les bugs (et d'enregistrer les dernières lignes). + +Bug n°2 : Il faudrait mettre à jour l'ensemble des documentations disponibles +sur le Wiki. + +Par ailleurs, pour les gros projets, il faut que les apprentis soient mieux +encadrés, quitte à ce que la Nounou s'implique dans le projet et y participe. + +### DHCPv6 + +Sylvain s'est penché sur la question, et n'a trouvé aucun serveur DHCPv6 qui +fasse de l'EUI64 (ce qui paraît logique en soi). Deux solutions sont possibles : + +* Générer un fichier de configuration statique, comme pour l'IPv4 +* Recoder un serveur DHCPv6, qui filtre les machines à qui elle donne des IPs + (cette solution est celle préconisée par Sylvain) + +### Utilisation du 2B + +On a constaté qu'au 2B, il y a souvent du monde, mais très peu de productivité +dans l'air. L'idée est d'établir des règles. Dans un premier temps, on va en +discuter, et les appliquer si nécessaire. + +L'idée est néanmoins de poser des "grands principes" par écrit, et de voir si la +situation s'améliore. On pourrait passer aux règles si aucune amélioration n'est +constatée, mais ce n'est pas la première chose à faire. + +Les afficher au 2B en A4 quelque part. + +On veut garder le 2B dans un état propre (tout est relatif)... pas trop sale. + +On va écrire des grands principes d'utilisation du 2B, deadline : la prochaine +inter-nounous. + +### Workshop Scripts + +Il n'a pas vraiment eu lieu, mais des gens se sont penchés sur les scripts. +Vincent a commencé à documenter les scripts. Valentin s'est penché sur la base +LDAP, d'une part pour l'optimisation des méthodes qui prennent du temps, et +d'autre part sur la cohérence des données entre la base réelle et les checks +faits par le binding. Les commits sont sur git.crans.org . + +### Questions diverses + +#### Séminaire OCaml / Ocsigen + +Dr. Chicco a proposé d'organiser un séminaire sur OCaml et Ocsigen, et voulait +savoir si il y avait des personnes intéressées. On peut voir pour en faire un +(ou plusieurs) séminaire(s) "grand public", de même qu'avec LaTeX, etc. À faire +de préférence avant les départs en stage. diff --git a/compte_rendus/2011_11_17.md b/compte_rendus/2011_11_17.md new file mode 100644 index 0000000..98cd738 --- /dev/null +++ b/compte_rendus/2011_11_17.md @@ -0,0 +1,168 @@ +# Réunion Nounous + +* Date : Jeudi 17 novembre 2011 +* Lieu : Pavillon des Jardins +* Début : 19h08 +* Fin : 20h50 + +## Présents + +* Anne Cazalet +* Aurore Moisy-Mabille +* Benjamin Aupetit +* Daniel Stan +* Nicolas Dandrimont +* Olivier Iffrig +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Steven Masfaraud +* Sylvain Boilard +* Valentin Samir +* Vanessa Verbeke +* Xavier Lagorce +* Yann Duplouy + +## Ordre du jour + +### Synaps System + +Anne Cazalet est présente pour rencontrer la nouvelle équipe (RTC, bureau). +On en profite pour discuter des prochains investissements de l'association en +termes de matériel (remplacement de la caméra du 0B, renouvellement des +garanties, +renouvellement du backbone, ...) + +### Câblage des chambres + +#### Prises défectueuses + +Plusieurs chambres du campus (environ 3) ont des problèmes matériels de câblage +(prises arrachées, ...). En dehors de la question de ce que le Cr@ns doit faire +à ce propos, il reste que des adhérents n'ont pas de connexion (et le Crous ne +le fera pas), et il s'agit de petits travaux. Il est plus agréable de le faire à +2 personnes, et c'est réalisable par des apprentis/câbleurs/... + +#### Câblage vers le CROUS + +Daniel a été contacté directement par MyStream Mardi pour des soucis de câblage +des clients MyStream, qui n'étaient pas branchés sur les bons switchs : il ne +faudrait pas les câbler sur les switchs marqués "Master". Ceci n'étant écrit +nulle part, Daniel a demandé un plan de brassage pour chaque bâtiment. Il a +aussi demandé s'il était possible d'éteindre les switchs non utilisés (problème +de ventilation au M par exemple). Une réponse était annoncée pour Mercredi, il +n'y a toujours rien. + +### WiFi + +C'est l'occasion de faire un point. +Olivier indique que tout semble marcher a priori, mais qu'une batterie de tests +est à faire pour s'en assurer. Il faut aussi les configurer totalement pour les +adapter au réseau Cr@ns. + +Daniel a réussi a flasher des anciennes bornes marquées comme HS, elles +marchaient. Puis elles ne marchaient plus. Il recherche. + +### Séminaires + +Nicolas se demande comment améliorer/remplacer de façon bénéfique les +séminaires. Il soulève le problème de l'attention du public en séminaire. +Question ouverte. + +### Apprentis + +Il est proposé la mise en place d'une liste des compétences nécessaires au bon +exercice de la fonction de nounou (administration système, réseau, ...). + +Cette liste sera mise en place collégialement et classée par ordre de pertinence +par la suite. + +### Proxy + +Après une rapide étude, Squid semble n'être pas très utile. + +* logging: ca marche, mais on peut le faire ailleurs +* mise en cache: ce serait bien, mais c'est pas extraordinaire +* deconnexion soft: il suffit de mettre une regle dans le firewall pour + rediriger les adherents vers une page de l'intranet +* ca complique la QoS: c'est pour ça qu'il faut le brûler + +Daniel demande des nombres pour finir de juger de l'utilité de Squid. +Nicolas fait remarquer qu'empiriquement, ça marche mieux quand Squid est down. + +Valentin s'en occupe. + +### Firewall Ipv6 + +ip6tables-restore v1.4.8: Couldn't load +target `BLACKLIST_SRC':/lib/xtables/libip6t_BLACKLIST_SRC.so: cannot open +shared object file: No such file or directory + +On ne sait pas qui brûler. Le script qui génère le firewall va être remis à son +état précédent grâce à darcs par Daniel. + +### Réunion avec la DSI + +Hier a eu lieu une réunion avec Stuart, Daniel, Valentin, Olivier, Sabrina, +Vincent M. Stuart a présenté les prochains projets de l'école (renouvellement de +matériel, ..., virer IRTS à long terme). + +Stuart va demander un devis à Orange pour laisser au personnel le choix entre le +Cr@ns et Orange, car la qualité n'est pas suffisante à son goût. + +Stuart a contourné le sujet du Gigabit. + +Il a été question du traffic shaping. Il faut tester ça sur le réseau du Cr@ns +pour démontrer à la DSI que l'on peut le faire nous même et qu'IRTS est donc +inutile. + +On est censé pouvoir acceder à l'interface de demande de travaux. C'est à +tester. + +### Questions diverses + +#### Vlan accueil + +Daniel propose que l'intranet soit accessible depuis le vlan accueil, pour que +l'adherent puisse ajouter lui même sa nouvelle machine. + +#### Switchs + +Les switchs ne sont pas à l'heure, c'est donc que le serveur NTP est mal +indiqué. +Il faut réparer ça. + +Il existe une pile de switchs garantis à vie qui sont HS, à côté de vo. Il faut +les mettre à jour et contacter HP pour les faire remplacer. Pour cela, il faut +prévoir une journée. + +Benjamin s'en occupe. + +#### Install-Party + +Le boot PXE est à jour. + +L'IP est après-demain, venez ! + +#### Mise à jour des bornes + +Daniel a testé l'image compilée par Nicolas avec backfire et le driver libre, +pour les linksys : ca à l'air de bien marcher. Comme les nouvelles bornes, il +faut finir de les configurer et les tester. + +C'est l'occasion de déployer un système pour que les bornes récupèrent leur +configuration toutes seules, rebootent régulièrement et se mettent à l'heure. + +Daniel propose aussi que les bornes arrêtent de diffuser le SSID Cr@ns quand +elles n'ont pas de réseau et qu'elles diffusent à la place un SSID de debug +pour qu'on puisse encore s'y connecter. + +#### Imprimante + +Michel a tenté de les contacter Mercredi pour qu'un technicien passe, mais il +n'a eu aucun interlocuteur. + +On peut leur demander de changer l'imprimante car cela fait 2 ans et demi qu'on +l'a. Il faut voir si c'est utile. + +Le rouleau des feuilles A3 pose problème, il faudrait demander à ce qu'il soit +changé. diff --git a/compte_rendus/2011_12_01.md b/compte_rendus/2011_12_01.md new file mode 100644 index 0000000..94cff04 --- /dev/null +++ b/compte_rendus/2011_12_01.md @@ -0,0 +1,135 @@ +# Réunion Nounous + +* Date : Jeudi 1er Decembre 2011 +* Lieu : Pavillon des Jardins +* Début : 19h17 +* Fin : 20h27 + +## Présents + +* Benjamin Aupetit +* Daniel Stan +* Michel Blockelet +* Nicolas Dandrimont +* Olivier Iffrig +* Sylvain Boilard +* Valentin Samir +* Xavier Lagorce +* Yann Duplouy + +## Ordre du jour + +### DSI-Cr@ns + +#### Connexion des appartements + +La DSI a rebasculé la connexion des appartements de fonction vers la connexion +Cr@ns, après l'avoir mise sur la connexion publique ENS sans nous prévenir. + +#### Lien Gigabit + +Il faut négocier avec la DSI pour avoir un lien Gigabit rapidement. Cela +permettrait +un accès plus rapide aux ENT. + +#### Chambres au Pavillon des Jardins + +La DSI nous demande si c'est possible de câbler certaines chambres du PdJ sur le +réseau public de l'ENS. Il faut demander à la DSI pourquoi, sachant que les +visiteurs +en question (chercheurs, ...) ont toujours été connectés grâcieusement au réseau +du Cr@ns si leur durée de séjour était raisonnable (<= 1 mois en général). + +#### Plans du réseau + +Il faut demander à la DSI une interconnexion rationnelle (i.e. une seule fibre +et pas 2 dont une reliée à un switch quelconque au d'Alembert Centre). + +Le plan du réseau du Cr@ns n'a pas été mis à jour suite à la mise en étoile des +bâtiments. Daniel va s'en occuper. + +### Maintenance générale + +#### Mise à jour vers squeeze + +Il ne reste plus que quelques serveurs à mettre à jour, il faut le faire. +Michel va voir avec Aurore pour finir ça. + +#### Bcfg2 + +Plein de fichiers de config sont désynchronisés avec le serveur Bcfg2. + +Il faut remotiver les gens à mettre la config dans bcfg2 et pas sur chaque +serveur, et aussi à packager des trucs existants : + +* {{{/etc/cron.d/CRANS}}} +* {{{/etc/init.d/purge_les_locks_nfs_connard}}} +* ...? + +#### Scripts + +Le nouveau binding ldap est utilisable a priori. Il est possible de s'en servir +pour écrire de nouveaux scripts, ou nettoyer des scripts existants. + +#### Divers + +### Monitoring + +#### Monitoring des serveurs + +Munin ne marche toujours pas. La situation n'a pas évolué depuis la dernière +réunion, il faut que quelqu'un prenne ses petits pieds et aille au 0B appuyer +sur un bouton pour redémarrer dyson. Daniel s'en charge. + +#### Utilisation du réseau + +It's over 9000%. +Nicolas a +fait [une weathermap qui marche](http://perso.crans.org/dandrimont/weathermap/weathermap.png) +avec MRTG. MRTG récupère les données en SNMP sur komaz et le backbone toutes les +5 minutes et les met dans un fichier pour munin, et un script PHP dessine le +graphe. + +Benjamin se propose pour rendre tout ça plus joli et plus complet (switchs dans +les bâtiments, ...). + +#### Firewall + +Valentin a fait plein de modifications sur le firewall dernièrement. En faisant +des modifications pour détecter les trackers bittorrent en http, il s'est rendu +compte que le filtre ipp2p n'était pas utilisé correctement (les paquets +détectés +sont en effet assez souvent dans des paquets au cours de connexion et pas dans +les paquets d'initiation). Le filtre a été mis au bon endroit et plus de gens +ont été déconnectés. + +### Questions diverses + +#### P2P + +Utilisation de OpenDPI à la place de ipp2p. La documentation est très éparse. +On regarde si ca vaut le coup. + +#### Formation interne + +La liste de compétences suggérée la semaine dernière doit toujours être mise en +place. Il est décidé de faire cela collégialement sur gobby (fichier +"competences"). + +Les nounous et anciennes nounous sont vivement incitées à contribuer à ce +document. + +#### Squid + +Squid est maintenant bypassé sur sable, hormis pour les déconnexions soft. Il +reste ce problème, ainsi que la connexion de secours qui ne fonctionne plus +automatiquement. + +#### Repas Federez + +C'est Samedi, 12h30, venez. + +#### Imprimante + +Pas d'avancées depuis 15 jours... +Elle fait des traces moches, ça devient urgent de changer les tambours. diff --git a/compte_rendus/2011_12_15.md b/compte_rendus/2011_12_15.md new file mode 100644 index 0000000..842a8ca --- /dev/null +++ b/compte_rendus/2011_12_15.md @@ -0,0 +1,196 @@ +# Réunion Nounous + +* Date : Jeudi 15 Décembre 2011 +* Lieu : Pavillon des Jardins +* Début : 19h16 +* Fin : 20h51 + +## Présents + +* Antoine Durand-Gasselin +* Benjamin Aupetit +* Daniel Stan +* Melissa Verbeke +* Nicolas Dandrimont +* Olivier Iffrig +* Steven Masfaraud +* Sylvain Boilard +* Valentin Samir +* Vanessa Verbeke + +## Ordre du jour + +### DSI-Cr@ns + +Augustin et Olivier ont eu une réunion avec Sabrina Louison-François de la DSI, +pour prévoir la simplification de l'interconnexion entre le réseau du Cr@ns et +le réseau de l'ENS. + +Cette opération aura lieu en semaine 52, a priori le 30/12. Daniel et Nicolas +seront +présents. + +L'interconnexion retenue sera faite à l'aide d'un switch du côté ENS, +interconnecté +au backbone par l'actuelle fibre komaz<->irts. Cette connexion sera en gigabit, +et fera passer les vlan 3 (wifi), 4 (wifi +ens), 10 (évènementiel), 21 (appartements) +et le vlan des serveurs DSI, auquel komaz pourra accéder. L'interconnexion avec +le réseau de l'ens sera assurée via le nouveau switch bato-1. + +L'actuelle fibre Multiprise_wifi<->D'Alembert-Centre serait alors inutilisée. + +### Achat de matériel + +#### Carte contrôleur baie de disques + +La baie de disque étant un élément central de l'infrastructure du Cr@ns, il a +été +proposé lors de la dernière réunion d'investir dans une carte de contrôle +supplémentaire. + +La carte de contrôle actuelle étant bientôt en fin de vie, deux solutions +s'offrent à nous : + +* Acheter une nouvelle carte identique à l'actuelle +* Ou acheter deux nouvelles cartes, récentes (garantie 3 ans au maximum) + +Une décision raisonnable ne pourra être prise que lorsque les coûts des deux +options auront été estimés. + +#### Renouvellement du backbone + +Notre backbone se fait vieux (2003). Anne nous proposera une offre dans le +courant +de la semaine prochaine. Une reprise de l'ancien est possible pour diminuer le +coût du changement. + +### Monitoring + +Munin "refonctionne". Le graphing se traine le cul. + +Il faut évaluer munin-2, qui serait apparemment over 9000 fois mieux que la +version +1.4 (CGI et graphing plus rapide, récupération des données plus légère, ...). + +Une possibilité toujours en l'air est d'installer un outil du type de nagios, +qui permettrait de regrouper en un coup d'oeil autostatus, monit et munin. +Olivier +propose d'encadrer ce projet. Vanessa est volontaire. + +### Serveurs + +#### Running gag : rouge + +L'age de rouge est strictement croissant. Sa seule fonctionnalité pertinente est +MX principal. Il y a du filtrage de contenu (amavis) et un serveur +smtp (postfix). + +Ces services devaient être migrés sur redisdead, mais les nounous ont peur que +la charge due à amavis le fasse s'écrouler. + +Étapes de la migration : + +* Configurer amavis sur redisdead +* Configurer l'authentification des clients +* Vérifier que tout ça tient la charge +* Modifier les DNS +* Jeter rouge du 6B + +#### Mises à jour vers squeeze + +La fin de vie de lenny aura lieu, comme à chaque release de Debian, un an après +la release de squeeze... Soit le 6 février 2012. + +Il reste à migrer zamok, gordon et 3 domU (titanic, ldap, niomniom). Ceci en +supposant +que le point précédent, qui n'a été attribué à personne, va s'effectuer par +magie. + +##### niomniom + +adg se propose pour encadrer la mise à jour du wiki. Steven se porte volontaire. + +##### "vert" + +La mise à jour de LDAP va être passionnante : la conversion automatique vers le +nouveau format de configuration fonctionne de manière quantique. + +Le nouveau format de configuration est en fait un annuaire LDAP, ce qui permet +la modification et la synchronisation sans downtime des configurations et +schémas. +L'ancien format de configuration en fichiers plats n'est plus disponible dans la +version squeeze de slapd. + +À prendre en compte avant de faire la mise à jour : + +* éviter que les mails ne bouncent à cause d'un utilisateur + inexistant (soft_bounce = yes dans la configuration de postfix) +* s'assurer que tous les services arrivent toujours à se connecter à la base + ldap (postfix, dovecot, intranet, authentification...) +* s'assurer du bon fonctionnement de la réplication + +Il y a une config de réplicat correcte sur sable, il est envisageable de la +convertir en config de master pour l'utiliser sur vert sans trop de dommages. + +##### titanic + +Deux points importants : + +* connexion des appartements +* connexion de secours + +Ces deux services étant morts actuellement, faire la mise à jour de titanic ne +devrait +pas avoir trop d'impact... + +##### gordon + +Cf. plus bas. + +### Maintenance générale + +Le RTC se porte volontaire pour améliorer la configuration de logcheck, afin +qu'il +reçoive plus de mails avec des logs et moins de mails d'erreur. + +Il est évoqué la possibilité de mettre en place un serveur syslog centralisé. +Avant de se lancer là dessus, il faut planifier proprement comment seront +stockés +les logs. Il faut aussi penser à la durée de rétention des logs... + +### WiFi + +Les mises à jour des bornes vers backfire ont été faites. Il faut mettre à jour +gordon. Cela permettra aussi d'utiliser les nouvelles fonctionnalités de +freeradius, +en particulier les possibilités de logging (client<->borne etc.). + +Cette mise à jour doit être faite avec le plus grand soin, car la config de +freeradius +est une bête poilue, surtout pour le wifi, avec une configuration pour les +postes +linux et une pour les clients windows. + +Les nouvelles bornes reçues (pico/nano)station fonctionneraient out of the +box... +Les gens ayant testé ça mardi ont eu la flemme de faire make, parce qu'ils +avaient +faim et/ou soif. iota propose de s'en occuper après la réunion. + +### Ajout de droits + +nounous.append("Sylvain") +commit() + +### Questions diverses + +#### Vacances + +Remplissez la page idoine, merci. Il faut des clés du 0B proches du campus à +tout +moment. + +#### Mises à jour de switchs Gigabit + +Benjamin est volontaire. diff --git a/compte_rendus/2012_01_12.md b/compte_rendus/2012_01_12.md new file mode 100644 index 0000000..d2eeb62 --- /dev/null +++ b/compte_rendus/2012_01_12.md @@ -0,0 +1,140 @@ +# Réunion Nounous + +* Date : Jeudi 12 Janvier 2012 +* Lieu : Pavillon des Jardins +* Début : 19h20 +* Fin : 21h01 + +## Présents + +* Daniel Stan +* Nicolas Dandrimont +* Olivier Iffrig +* Raphaël Cauderlier +* Sylvain Boilard +* Valentin Samir +* Yann Duplouy + +## Ordre du jour + +### Achat de nouveau matériel + +#### Backbone + +#### Carte de contrôle pour la baie de disques + +### Interconnexion DSI-Cr@ns + +La nouvelle interconnexion est en place depuis le 29 décembre. Olivier fait un +schéma de l'ancienne interconnexion au tableau, avec IRTS. + +En résumé : + +* Un nouveau switch bato-1 à l'autocom, qui fait l'interconnexion entre + * le backbone (vlan 1, 2, 3, 4, 10, 21, 1132 - zrt) + * le réseau de l'ENS (vlan 3, 4, 10, 21, 1132 - zrt) + * le Pavillon des Jardins (vlan 1, 2, 3, 4, 10?, 21) + * les appartements de la porterie (vlan 1, 2 - pour bato-1, 21) +* Nouvelle interconnexion 0B - Autocom: 3 paires de fibre, dont une pour le + bâtiment G en direct, une pour bato-1, et une libre (branchée sur bato-1 à + l'autocom) +* Suppression de l'interconnexion 0B - d'Alembert Centre qui était foireuse et + génératrice de boucles difficiles à débugguer + +#### Traffic Shaping + +L'agrément RENATER de l'ENS étant pour 100Mb/s, le Cr@ns a mis en place du +traffic +shaping pour limiter son débit entrant et sortant. + +La QoS est désactivée pour le trafic vers le réseau ENS dans le pare-feu. + +Il faut réfléchir à une méthode pour shaper le trafic dynamiquement (n Mb/s la +journée, p Mb/s la nuit). Valentin propose de modifier config.py pour que le +débit max dépende de l'heure, et un cron pour régénérer la chaîne MANGLE qui +assigne les classes au trafic. + +Il va mettre le cron en place rapidement, ce qui permettra de toute façon de +régénérer les classes de QoS de temps en temps. Apparemment il y aurait déjà un +cron de ce type en place. + +### Migration des /home + +Les /home ont été migrés aussi le 29 décembre, quitte à avoir une interruption +de service... + +La partition était en place, il suffisait de désactiver les services, un dernier +rsync et de remplacer la partition dans le fstab. + +### Logs + +Une partition assez volumineuse vient d'être libérée. Une idée serait de s'en +servir pour centraliser les logs des serveurs et des domU. + +À cette fin, il serait possible de réutiliser un serveur physique inutilisé, par +exemple ragnarok. + +Sylvain regarde ce dont on a besoin précisément d'ici la prochaine réunion. + +### Bornes wifi PicoStation + +Adg a une config qui devrait marcher. Olivier l'a flashée sur une borne, ça +fonctionne, il faut attendre assez longtemps que ça reboote. + +Reste à faire : + +* vlan (pour pouvoir remettre des bornes en zone ENS) +* multi-ssid +* tests de portée +* tests de débit/charge + +Sur les wrt54g: + + +Olivier envisage de faire des trucs là dessus samedi. + +### Monitoring + +Munin a été migré sur dyson il y a quelques temps, la génération des graphes +est lente, mais fonctionne. Une nouvelle version de munin va sortir (elle est +en bêta stable depuis un an). La génération des graphes a été optimisée et on +peut zoomer sur les graphes en temps réel. Le protocole de communiation a aussi +été amélioré : +avant, le serveur munin contactait tous les noeuds leur demandant de générer +les données ; maintenant, les serveurs ont un agent qui génère les données en +continu. La première phase serait de mettre à jour munin sur le serveur (c'est +backwards-compatible). Nicolas a fait un backport. Il faut ensuite vérifier si +ça fonctionne, si c'est rapide. + +Si tout ça se passe bien, il y a moyen de faire des trucs marrants sur les +clients. + +### Questions Diverses + +#### Load balancing DNS + +Valentin propose de configurer le DHCP de telle manière à annoncer +alternativement sila et sable en serveur DNS. + +Il faut mettre en place du monitoring de bind (via munin qui fonctionne, par +exemple) +pour voir si c'est vraiment nécessaire. + +#### TFTP sur sable + +Il faut le mettre sur une partition séparée, pour éviter de remplir le /var de +sable... + +Le proxy transparent ayant été dégagé, plein d'espace disque est disponible. +Il serait aussi potentiellement intéressant de mettre un RAID. Sinon, Valentin +se porte volontaire pour faire la réinstall de sable from scratch si un disque +plante. + +#### batp-3 + +Il est allumé, il ne ventile plus, il clignote rouge. Il faut appeler HP pour +le faire échanger. + +#### Imprimante + +Nicolas trouve que Print Platinium est désespérant diff --git a/compte_rendus/2012_01_26.md b/compte_rendus/2012_01_26.md new file mode 100644 index 0000000..c0ebe32 --- /dev/null +++ b/compte_rendus/2012_01_26.md @@ -0,0 +1,144 @@ +# Réunion Nounous + +* Date : Jeudi 26 janvier 2012 +* Lieu : Condorcet +* Début : 19h16 +* Fin : 20h35 + +## Présents + +* Anne Cazalet +* Nicolas Dandrimont +* Olivier Iffrig +* Steven Masfaraud +* Sylvain Boilard + +## Présent par internet + +* Aurore Moisy-Mabille +* Daniel Stan +* Raphaël Cauderlier +* Valentin Samir +* Vincent Le Gallic +* Yann Duplouy + +## Ordre du jour + +### Achat de matériel + +Anne Cazalet nous fait ses propositions sur les éléments que nous avions +demandé. + +#### Imprimante + +Anne Cazalet nous propose une imprimante HP CM6030 ou CM6040 en achat comptant, +et va aussi communiquer nos coordonnées à un prestataire de leasing avec des +imprimantes Xerox (Alex Panahi), afin que nous puissions comparer les deux +propositions. +L'imprimante coûterait environ 9000€ (prix public). + +#### Onduleur + +L'onduleur est en fin de garantie, Anne va nous envoyer une proposition pour +la prolonger, c'est à dire ajouter un an + un an, et par la suite envisager de +passer +sous un contrat de maintenance pièces - sans batteries - incluses. + +#### Carte de contrôle pour la baie de disques + +Le contrôleur de la baie de disques est obsolète. On peut éventuellement +en trouver un reconditionné ou en pièces détachées. + +Une autre solution serait de changer le chassis, et d'utiliser des nouveaux +contrôleurs. Les disques sont heureusement compatibles. Coût public 6550 euros +contrôleurs inclus (prévoir une remise ~20%), sans prendre en compte un échange +éventuel (d'après une simulation, environ 600 euros seraient récupérables). + +#### Backbone + +Pas de proposition mise à jour, nous avions envisagé un chassis 5406, avec deux +modules + +* 12 ports SFP + 12 ports Ethernet 10/100/1000 +* 24 ports 10/100/1000 Ethernet + +### Imprimante + +Il faudrait se débarrasser de Print Platinium. On pourrait ensuite acheter une +imprimante ou en louer une selon l'offre qui va nous être proposée. + +À considérer : + +* Délai d'intervention du technicien +* Durée du contrat, évidemment +* Durée de vie des consommables (nb de pages par cartouche) +* Tarifs si la consommation prévue est dépassée ? +* Considérations sur le prix des impressions (A4 vs. A3, noir vs. couleur) + +Dans tous les cas, il faut relancer le technicien de PP pour le changement des +tambours... Il faut poker PEB. + +### Caméra + +La nouvelle caméra a été installée, et l'assureur du CROUS n'envisage pas de +rembourser l'ancienne, parce qu'apparemment le plastique ne rouille pas quand il +se fait inonder. + +### Serveur de logs + +Le disque de ragnarok semble mort, il faut un volontaire pour aller acheter deux +disques SATA de capacité respectable (≥ 1 To) chez nos amis de Montgallet, afin +de mettre en place un RAID et de pouvoir voir venir. PEB s'était porté +volontaire +sur IRC. + +Il faut absolument penser aux backups sur ce serveur. La procédure complète +d'installation pourra être détaillée sur le wiki. + +### Bug tracker + +Olivier a fait en sorte que les mails envoyés vers xxx@bugs.crans.org arrivent +sur le serveur idoine. Il y a manifestement un bug dans la config de postfix. + +Il faudrait reprendre la configuration mail qui a été faite pour +tracker.crans.org, qui fait en sorte que les mails y arrivent. + +Il faut définir quels "packages" on met en place, et quels mainteneurs (même si +juste roots@crans.org semble adapté). + +Nicolas envisageait quelque chose du style un package par serveur + un package +par service important (WiFi, impression, intranet, ...). Olivier est d'accord. + +Il y a plusieurs aspects sur lesquels on pourrait travailler: + +* Un suivi des mails envoyés par monit, munin, ... pour les transformer en + tickets. +* Un bot IRC pour notifier des bugs, et enregistrer une partie des + conversations. + +### Séminaires + +Vu la grande présence apprentiesque à cette réunion, les séminaires sont +relancés pour dans 10 jours. + +### Bornes Wifi + +Il faut que les nouvelles bornes soient déployées le 15 mars. À faire : + +* Finalisation de la config +* Chiffrage et vote pour le budget du projet +* Déploiement + +#### Redémarrage des bornes + +Certaines bornes ont besoin d'un redémarrage de temps en temps. On va mettre en +place un script qui les redémarre une fois par jour, par exemple +à (3 + rand(0, 1))h du matin. + +## Questions diverses + +### Quid d'un web-nntp + +### Nit m'a montré ce qu'il avait fait, c'est cool. + +Yann et Valentin ont l'air motivés pour mettre une solution en place. diff --git a/compte_rendus/2012_02_09.md b/compte_rendus/2012_02_09.md new file mode 100644 index 0000000..0fa0d98 --- /dev/null +++ b/compte_rendus/2012_02_09.md @@ -0,0 +1,143 @@ +# Réunion Nounous + +* Date : Jeudi 9 février 2012 +* Lieu : Pavillon des Jardins +* Début : 19h23 +* Fin :21h05 + +## Présents + +* Benjamin Aupetit +* Daniel Stan +* Nicolas Dandrimont +* Olivier Iffrig +* Pierre-Elliott Bécue +* Raphaël Bonaque +* Raphaël Cauderlier +* Steven Masfaraud +* Sylvain Boilard +* Valentin Samir +* Vanessa Verbeke +* Vincent Le Gallic + +## Ordre du jour + +### Achat de matériel + +Le C.A. a accordé le budget nécessaire pour le backbone et la baie de disques. +La commande a été passée, et les livraisons devraient se faire sous peu. Le +chassis est un chassis de six modules au lieu de quatre actuellement, il faudra +donc faire de la place. + +### Imprimante + +Qualis fait une offre de leasing sur une imprimante Xerox (7535) qui semble +intéressante. +Le bac de sortie est vraisemblablement du mauvais coté, ce qui est problématique +pour accéder aux bacs de chargement. On pourrait faire des travaux pour échanger +la porte et l'espace de sortie du papier. + +Il serait bien aussi d'installer une vraie climatisation, il faut obtenir +l'autorisation de Lebailly pour pouvoir faire les travaux. Benjamin s'en occupe. + +### Mises à jour des serveurs + +Youpi ! Gordon est à jour !! +Il reste à mettre à jour : + +* titanic, Vincent s'en charge avec Daniel et Valentin (maj de squid en même + +temps pour faire marcher proprement la connexion de secours) + +* niomniom, Steven s'en charge avec adg +* vert, Olivier s'en charge avec Nicolas +* fy +* zamok : + Le / est trop petit, il faudrait utiliser le deuxième disque dur. On va en + profiter pour repartitionner comme il faut. Daniel s'en charge avec Olivier. +* rouge (s'en débarrasser ?) + +### Dyson + +Dyson est sous squeeze, il faut que la personne qui l'a mis à jour mette à jour +bcfg2. + +Pierre-Elliott s'occupe de mettre à jour munin avec Nicolas, pour que la +génération +des graphes mette moins de deux heures. + +### Wifi + +Daniel a installé deux bornes au G, elles ne fonctionnent pas pour l'instant, +il va investiguer. + +Daniel a commencé le développement de scripts permettant une connexion SSH de +masse sur les bornes wifi, afin d'effectuer des déploiements simples (scripts, +...). + +Il faut chiffrer le renouvellement du parc de bornes wifi pour le prochain CA. +Cela implique de faire des tests de portée, de finir la configuration, +et de comparer avec les tests de couverture qui ont été faits. +Olivier et Raphaël vont voir ça ce week-end, appel aux apprentis motivés. + +Un dépot opkg va être mirroré sur sila par websync. + +### Switchs + +PEB a testé les switchs qui sont entreposés au 2B. + +Il faut changer bata-3. + +Il serait très appréciable que les switchs défectueux soient changés en moins de +quatre jours, par exemple par les nounous d'astreinte inscrites sur le wiki. +Daniel et PEB s'en chargent ce soir. + +### Séminaires + +Les séminaires sont programmés jusqu'à mars. + +### Séances de travail + +L'objectif est d'avoir un ou deux apprentis encadrés par une ou deux nounous, +pour réaliser une tâche sur un sujet précis. + +#### Wifi + +Encadré par Harry et Iota. +À faire : cf supra. + +#### Scripts + +Encadré par iota + +Pour l'instant : passage des scripts en utf-8-safe, Vincent et Pierre-Elliott +sont candidats pour se faire victimiser. + +#### Maintenance des services + +Encadré par iota. + +Tâches : Passer en revue tous les mails d'erreurs des divers services. + +#### Monitoring + +Encadré par Nicolas et Olivier. Victimes : Pierre-Elliott et Vincent. + +Première tâche : mise à jour de munin. + +#### Intranet 2 + +À voir à moyen terme. +Encadré par Daniel et Nicolas. + +#### Firewall + +Encadré par Valentin + +## Questions diverses + +### Prêt de matériel pour une LAN + +Il y a une soirée jeux vidéo demain, les organisateurs demandent si on peut +leur prêter du matériel : des câbles et des multiprises. Daniel sera là-bas et +s'en charge. diff --git a/compte_rendus/2012_02_23.md b/compte_rendus/2012_02_23.md new file mode 100644 index 0000000..41ce64f --- /dev/null +++ b/compte_rendus/2012_02_23.md @@ -0,0 +1,104 @@ +# Réunion Nounous + +* Date : Jeudi 23 février 2012 +* Lieu : Pavillon des Jardins +* Début : 19h20 +* Fin : 20h20 + +## Présents + +* Aurore Moisy-Mabille +* Nicolas Dandrimont +* Olivier Iffrig +* Pierre-Elliot Becue +* Raphaël Cauderlier +* Sylvain Boilard +* Valentin Samir +* Yann Duplouy + +## Ordre du jour + +### Imprimante + +Elle fonctionne, mais n'agrafe pas quand on imprime avec lpr, la syntaxe a +dû changer. +PEB va voir ce qu'il en est. + +PEB a remis en place la plaque au niveau de la fenêtre, afin d'éviter d'autres +visiteurs à plumes, il faudrait la fixer de manière un peu plus efficace. + +### Wifi + +Des tests ont été faits au G et au M. Il faut une borne par couloir au M, et 2 +par étage au G. +Il faut calculer les longueurs de câble et le nombre total de bornes d'ici jeudi +prochain. + +Vesta est dans la med en ce moment. Certaines personnes ont quelques soucis +avec. + +Daniel a avancé sur la carte des bornes. + +### Télévision + +Il avait été proposé d'utiliser des cartes ARM pour la TV. Sylvain voudrait +demander l'avis du CA et des nounous. + + + + +Le budget restant sur ce qui avait été voté en CA est de l'ordre de 100 euros. + +Il faut évaluer cette solution vs. une solution à base d'un serveur classique. +Sylvain s'en charge. + +### Séminaires + +return -ENOAPPRENTIS; Toutefois, PEB prend le sujet monitoring. + +### Zamok + +La mise à jour a été faite au forceps. Une machine du labo de Drébon pourrait +nous être offerte, on pourrait en faire le nouveau serveur des adhérents. + +### Backbone + +Il a été remplacé dans la nuit de vendredi à samedi dernier. Cela a occasionné +une coupure des services entre 1h30 et 3h. Lors du redémarrage +des services, l'UDP sur komaz a cordialement décidé de nous chier dans les +bottes. +Ce problème n'est toujours pas expliqué ni réglé. Le tunnel IPv6 étant en UDP, +l'IPv6 est actuellement mort. Il ''faut'' régler le problème rapidement. + +Le remplacement s'est fait sans prévention sur les news de la coupure des +services. +Le CA va probablement rappeler au collège des responsables techniques que les +mises à jour de services critiques doivent être annoncées et effectuées à +l'horaire annoncé, ou reportées. + +### Planification des séances de travail + +Une séance de travail sur le monitoring est prévue ce week-end, probablement +samedi après-midi. Nicolas, Pierre-Elliott et Vincent Le Gallic y travailleront. + +Olivier va organiser des séances de travail sur les scripts, notamment pour +gérer +proprement l'encodage et pour utiliser le nouveau binding LDAP. On prévoit une +séance le 3 ou le 4 mars. + +## Mises à jour + +### Mise à jour de titanic + +La mise à jour de titanic aura lieu dimanche matin, Olivier se charge de +prévenir +la DSI, qui informera les personnels. + +### Mise à jour de vert (ldap) + +La mise à jour sera faite dimanche 4 mars au matin. Tous les services seront +coupés pendant la mise à jour. Olivier fait l'annonce. + +## Questions Diverses + +N/A diff --git a/compte_rendus/2012_03_15.md b/compte_rendus/2012_03_15.md new file mode 100644 index 0000000..580f3dd --- /dev/null +++ b/compte_rendus/2012_03_15.md @@ -0,0 +1,99 @@ +# Réunion Nounous + +* Date : Jeudi 15 mars 2012 +* Lieu : Amphithéâtre Tocqueville +* Début : 19h15 +* Fin : 20h12 + +## Présents + +* Aurore Quelennec +* Daniel Stan +* Julien Baste +* Nicolas Dandrimont +* Olivier Ιffrig +* Pierre-Elliott Bécue +* Sylvain Boilard +* Valentin Samir + +## Ordre du jour + +### Séminaires + +'On laisse tomber les séminaires après celui sur le monitoring. +Il serait peut être bien de planifier des séminaires LateX pour janvier de +l'année prochaîne. + +### Wifi + +Une !PicoStation M2 HP a été achetée. Elle marche out of the box avec l'image +pour !NanoStation. Daniel l'a mise à la Kfêt pour la tester en situation réelle. +On va prendre des {Pico,Nano}Station M2 et quelques !NanoStation M5 pour les +lieux très fréquentés. Il faut établir un budget à soumettre au CA. Olivier +s'occupe de ça ce WE, avis aux intéressés. + +Valentin a créé un petit exécutable pour implanter les profils wifi sur les +postes Windows Vista et 7 (et peut-être 8, TODO ce soir). Valentin s'occupe +d'en faire la pub auprès des câbleurs. + +### Intranet + +Julien a repris ce qui avait été fait sur l'intranet. On a ouvert un port pour +qu'il puisse continuer à travailler dessus pendant son stage. Appel aux gens +motivés pour se joindre à lui. + +L'objectif principal est de répliquer la fonctionnalité de l'intranet actuel. + +### Mises à jour de serveurs + +#### vert + +Vert a été mis à jour. Il est possible de mettre à jour les ACL sur la base +LDAP pour permettre aux utilisateurs de modifier ce qui les concerne, pour +faire des logs dans la base, ... +On va commencer à voir ça ce soir. + +#### Niomniom + +Il faut voir avec adg pour faire ça au plus vite. PEB est volontaire. + +#### Zamok + +Il faut se débarrasser de zamok, On l'a bien vu ces derniers temps (mis à genoux +par le driver de l'imprimante). Nicolas propose d'utiliser l'actuel fx pour +enfin mettre à jour matériellement zamok. + +Reste à réfléchir à quel serveur utiliser pour faire le partage NFS. Plusieurs +choix s'offrent à nous : + +* Effectuer les exports NFS depuis le nouveau zamok. + * Avantage : simplicité + * Inconvénient : si un adhérent fait de la merde, les exports NFS sont perdus +* Utiliser un serveur actuel pour faire les exports NFS. Les candidats : + * Vieux zamok + * Un serveur free + * Sable ? +* Investir dans un nouveau serveur pour faire les exports NFS : + * Avantage : c'est un serveur neuf... + * Inconvénient : c'est un peu cher... + +Le vainqueur serait apparemment le serveur free. + +L'interaction serveur free <-> nouvelle baie de disques sera testée au 2B avant +la mise à jour effective. + +### Baie de disques + +La nouvelle baie de disques est arrivée. On va l'installer en même temps qu'on +fera la migration de zamok. Ce n'est pas pressé. + +### Départs en stage + +Il faut que les gens qui partent en stage mettent à jour CransVacances. + +### Questions diverses + +#### Plan du réseau + +Daniel a mis à jour le plan, il faut le vérifier. +Il faudrait faire un deuxième plan au niveau logique pour montrer les VLANs. diff --git a/compte_rendus/2012_03_29.md b/compte_rendus/2012_03_29.md new file mode 100644 index 0000000..1f19d9c --- /dev/null +++ b/compte_rendus/2012_03_29.md @@ -0,0 +1,143 @@ +# Réunion Nounous + +* Date : Jeudi 29 mars 2012 +* Lieu : Condorcet +* Début : 19h17 +* Fin : 20h13 + +## Présents + +* Aurore Moisy-Mabille +* Aurore Quelennec +* Daniel Stan +* Nicolas Dandrimont +* Olivier Iffrig +* Pierre-Elliott Bécue +* Sylvain Boilard +* Vanessa Verbeke + +## Ordre du jour + +### État du 2B + +Le 2B a été nettoyé par Morgane et Daniel. Le RTC souhaite que le 2B reste +dans cet état là. Pour le reste, il faudra lui redonner un coup de propre +régulièrement. + +Le matériel a été rangé (organisation qui invite de nouvelles suggestions) + +### Debbugs + +Debbugs a été mis en place. Site web: (pour soumettre +un bug : submit@bugs.crans.org). C'est initialement le tracker de bugs de debian, +et chaque paquet debian a sa liste de bugs. Comme le crans n'a pas de paquets +au sens debianesque, on pourrait créer plusieurs "paquets" crans correspondant +à des services. Actuellement, on a un seul paquet "crans". + +On pourrait organiser les paquets par services. + +Noms ASCII. + +* scripts +* ldap_crans +* mail +* firewall +* intranet (+ impression) +* intranet2 +* zamok (= accès shell, pages perso) +* wifi +* wiki +* cablage (= prises défectueuses) +* tele +* crans (= autres) + +#### Possibilités d'évolution + +* Bot IRC (création de tickets directement sur irc) +* Frontend web de soumission utilisable par les adhérents (sur l'intranet2) + +### Matériel + +#### Wifi + +Harry, Daniel et Olivier ont parcouru les bâtiments pour trouver où câbler les +bornes. Le compte-rendu sera mis sur le wiki à l'occasion. En bref, une pico +par étage au A, B, C. H, I, J, dans les locaux à côté de la cage d'ascenseur. + +Dans le G, il y a des placards où on peut faire passer des câbles entre les +étages. +L'idée est de placer une nano par étage, en alternance (en terme de position). + +Le M n'a pas été fait, car on avait pas le badge, mais vu les tests le 16 +février, il faut une nano par aile, donc deux par étage. +Attention aux 100m de câble, et à sertir les paires dans le bon sens... + +Les longueurs de câbles seront données sur le wiki. (Daniel s'en charge) + +On pourra réfléchir, une fois l'installation faite, à prêter des bornes à des +adhérents pour "patcher" la couverture dans leur chambre, sous caution. + +#### Onduleurs + +Olivier s'occupe de faire faire des devis pour remplacer les onduleurs morts +(0A, 2B, -1I), Pierre-Elliott et Nicolas s'occuperont d'aller voir les onduleurs +pour savoir lesquels marchent. + +#### Clim 0B + +Pierre-Elliott s'occupe d'appeler LTC pour faire la révision annuelle de la +clim. + +### Mises à jour + +#### TV + +La version en production de MuMuDVB était bugguée avec les nouvelles versions de +VLC. Olivier a effectué la mise à jour du binaire sur les serveurs cet +après-midi. + +#### Wiki + +Adg est prêt à encadrer un apprenti pour faire cette mise à jour, avec le +prérequis +que l'apprenti en question soit un peu culturé sur apache2 (i.e. sache déjà +lancer moinmoin avec wsgi). Vanessa va voir avec Steven s'il veut toujours +s'en occuper, sinon, Pierre-Elliott est volontaire (après ses écrits du concours +3A).Steven est volontaire (il va envoyer un mail à Olivier). + +### Séances de travail + +#### Ragnarok + +Ragnarok est désormais bien monté (deux disques durs d'1To en RAID1). Olivier +se propose d'encadrer le workshop, qui aura lieu le 7 avril. + +#### Nagios + +Quand le workshop monitoring a été effectué, on a parlé de re-tester Nagios +Pierre-Elliott est motivé pour lire les 400 pages de doc de Nagios et prendre +des notes sur le wiki. Ensuite, on fera une réunion pour en parler, et on +essaiera de faire un workshop avec une Mamie pour trouver comment implémenter +au mieux le module. + +#### Wiki + +Il faut le réordonner tant d'un point de vue "VieCrans" que du point de vue +technique. Pour la partie VieCrans, Morgane était volontaire pour diriger cette +réorganisation. + +Il faudrait faire plusieurs workshops pour cela. Nicolas demande si ça vaut le +coup de dédier du temps à faire ''uniquement'' ça. + +On pourrait essayer d'appliquer un tag sur les pages pour dater la dernière fois +que la véracité des informations a été vérifiée. + +### Questions diverses + +#### Spoofing adresses mac + +Un certain nombre d'adhérents reçoivent des mails d'avertissement pour upload +sans avoir été connectés depuis la veille. Pierre-Elliott va dresser une petite +liste +des adhérents qui prétendent cela, et on essayera de voir si une prise commune à +tous ces adhérents est identifiable. diff --git a/compte_rendus/2012_04_12.md b/compte_rendus/2012_04_12.md new file mode 100644 index 0000000..8c7d819 --- /dev/null +++ b/compte_rendus/2012_04_12.md @@ -0,0 +1,162 @@ +# Réunion Nounous + +* Date : Jeudi 12 avril 2012 +* Lieu : Condorcet +* Début : 19h13 +* Fin : 20h10 + +## Présents + +* Aurore Moisy-Mabille +* Daniel Stan +* Olivier Iffrig +* Pauline Pommeret +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Steven Masfaraud +* Sylvain Boilard +* Yann Duplouy + +## Ordre du jour + +### Ragnarok + +Nicolas, Olivier, Pierre-Elliott et Yann ont mis en place un serveur rsyslog (en +RELP) sur ragnarok qui enregistre ses logs dans une base PostgreSQL en local. +Ça fonctionne, on a mis whatsupdoc en client pour l'instant, il faut voir ce +qu'on fait des serveurs qui utilisent syslog-ng. On va regarder un peu plus en +détails, mais la solution qui semble la plus pratique est de remplacer +syslog-ng +par rsyslog. + +Il faut aussi documenter le tout sur le wiki. + +### Niomniom + +Steven et Antoine Durand-Gasselin ont travaillé là dessus lundi, pour voir ce +qu'il se passait, et si ça marchait. A priori, tout fonctionne, la mise à jour +est prévue samedi à 14h, les pages devraient rester consultables (duplicata des +pages le temps de la MaJ). La modification de la page d'accueil du wiki est à +faire le plus tôt possible pour prévenir tout le monde. + +Steven songe à faire une doc pour la MàJ du wiki qui soit plus accessible à tous +que celle d'Antoine pour les novices. + +### Serveurs de virtualisation + +#### Fy + +Après la mise à jour du wiki, il n'y aura plus aucun domU sur Fy (les domu +étant migrés pendant la mise à jour). Il faudra donc le mettre à jour, on peut +le faire dans la foulée. On pourra alors penser à répartir la charge des domU +entre les deux serveurs Fy et Fz. +Raphaël rappelle l'idée de fournir des domU aux clubs. Fz avait à l'origine été +acheté dans le but d'héberger un nouveau serveur pour les adhérents. + +#### Fx + +Lors d'une précédente internounou, Nicolas avait souligné que Fx est +sous-utilisé, et qu'il faudrait songer à utiliser une machine free comme NFS, et +du coup employer Fx soit comme un nouveau zamok, soit comme un serveur pour les +clubs. + +#### Machines pour clubs + +Raphaël propose de créer une interface pour les clubs leur permettant de créer +une machine virtuelle qu'ils pourraient utiliser à l'envi. On pourra rediscuter +de ce point après les mises à jour. + +### Wifi + +Les nouvelles bornes sont arrivées. Il faut des personnes pour poser les bornes +et effectuer les cablâges nécessaires. +Il faut s'assurer d'avoir un firmware fonctionnel. La connexion sous windows +avec ce firmware semble problématique en l'état. Une étude est à mener sur ce +point. + +Liste des bâtiments où on pourrait intervenir sans délai : + +* Le A (en partie) +* Le B +* Le C +* La Med +* La Kfet + +On récupèrera à l'occasion d'anciennes bornes, que l'on peut mettre à +disposition +des anciens adhérents qui veulent les placer dans leur chambre pour patcher la +connexion wifi, vu qu'elles font switch, il n'y a pas de problème niveau +câblage. +On demandera une caution qui sera fixée par le C.A. Il faudra déménager la borne +dans la chambre de l'adhérent, et donner l'accès au VLAN wifi. + +Vu le nombre de bornes, il est nécessaire de former des gens pour flasher les +bornes. +Les bornes seront flashées lorsque des gens sachant le faire seront à +disposition, +du coup toute personne intéressée pourra profiter d'un éventuel workshop. (sans +que cela n'entraîne une affluence trop forte au 2B). On fera des wokshops durant +le WE, vendredi soir, samedi selon l'avancement des mises à jour, dimanche. + +### Liste de compétences des apprentis + +Vanessa a demandé que l'on établisse une liste de compétences nécessaires aux +apprentis pour qu'ils puissent éventuellement devenir nounous. Ce point avait +déjà été traité, et un premier document avait été créé, il a été mis à jour, +et une version sera proposée sur le wiki d'ici jeudi. + +### Baie de disques + +Pierre-Elliott a discuté avec Jérémie concernant la baie de disques en vue de la +mise à jour matérielle. Elle est de la même famille que la baie actuelle, il y a +des chances que ce soit plug-and-play. Dans tous les cas, c'est suffisamment +lourd pour qu'on attende l'été avant de s'en charger. + +### LTC + +Pierre-Elliott a contacté LTC, ils proposent de passer le mardi 24 avril à 8h +pour la maintenance de la climatisation du 0B. Pierre-Elliott et Olivier sont +disponibles pour les accueillir. + +### Nagios + +Pierre-Elliott va tenter d'essayer de proposer une documentation sur le wiki, et +appelle les gens qui ont des questions à les poser, ensuite on pourra mettre ça +en place, à la place de monit et en complément de munin. + +## Questions diverses + +### Multiples adresses MAC + +Un adhérent rencontre un problème de multiples adresses macs dans sa chambre. +Lorsqu'il branche son ordinateur, le switch voit en moyenne 8 adresses mac, et +du coup, il n'a pas accès à Internet. + +On va essayer de faire en sorte qu'il puisse se connecter, et chercher des +vraies solutions en parallèle. +Solutions proposées : + +* Désactiver temporairement l'authentification RADIUS sur la prise +* N'autoriser que sa vraie MAC sur sa prise + +### Vérification mac prises + +Daniel s'inquiétait du fait que quelqu'un puisse spoofer des adresses mac +d'adhérents pour faire de l'upload, un script s'occupe désormais de logguer +ces informations, pour que le cas échéant on le sache. + +### Installeur Debian + +L'installeur Debian présent sur le FTP du Cr@ns (et sur le netboot) est cassé, +il ne reconnait pas les disques durs (et potentiellement pas le reste non plus). +Il faut essayer de trouver une solution. A priori, c'est un problème indépendant +du Cr@ns, mais il existe des images censées corriger ça. Affaire à suivre. + +### IMAP + +Apparemment, Roundcube plante en essayant de s'abonner à des dossiers IMAP, et +icedove/thunderbird semble également rencontrer quelques difficultés (à +vérifier). +Il est possible que dovecot rencontre pas mal de soucis en ce moment, Antoine +Durand-Gasselin a suggéré de refaire la configuration de dovecot pour régler la +panne. diff --git a/compte_rendus/2012_04_26.md b/compte_rendus/2012_04_26.md new file mode 100644 index 0000000..b0ba93f --- /dev/null +++ b/compte_rendus/2012_04_26.md @@ -0,0 +1,168 @@ +# Réunion Nounous + +* Date : Jeudi 26 avril 2012 +* Lieu : 2B +* Début : 19h25 +* Fin : 21h + +## Présents + +* Aurore Moisy-Mabille +* Daniel Stan +* Nicolas Dandrimont +* Olivier Iffrig +* Raphaël Cauderlier +* Yann Duplouy + +## Ordre du jour + +### Wiki + +La mise à jour de niomniom a été effectuée. Les personnes ayant effectué la +mise à jour n'étant pas présentes, difficile d'en dire plus. Un backup du +wiki a été fait dans /usr/scripts (il pèse 800 Mo), il faut l'enlever. + +### Virtualisation + +fy a été réinstallé, histoire que ce soit propre, et à peu près la même chose +que sur fz. La migration à chaud ne marche pas très bien. fy est prêt à +accueillir des domU. On va s'en servir pour mettre à jour fz en limitant le +downtime. + +### Baie de disques + +Il faudrait voir s'il est possible d'avoir quelques disques en plus, pour +pouvoir faire des tests dans un premier temps, et ensuite servir de disques +supplémentaires déjà branchés. + +La nouvelle baie étant de la même famille que l'ancienne, le transvasage des +disques de l'une à l'autre devrait être plug-and-play. + +On va faire un workshop le 19 ou le 20 mai pour tester la nouvelle baie. + +### Nagios + +Pierre-Elliott a passé pas mal de temps (avec Nicolas) pour configurer Nagios de +manière raisonnable. La config est en cours, serveur par +serveur. 4 ou 5 serveurs +sont configurés. + +Démo sur nagios.crans.org (login/mdp crans). + +Nagios peut tester les services de « l'extérieur » en testant leur +fonctionnement. +Un module nagios-nrpe permet de tester les services depuis l'hôte. Ce dernier +permet de faire des checkdisk, etc. (peu utile car munin le fait déjà). + +L'implémentation des plugins munin est a priori faite, mais les résultats sont +mitigés. (les plugins sont monitorés passivement, donc si pas de warning, ils +sont notés comme "en attente", et les rares qui ont été monitorés sont en +"unknown". Le passage des plugins munin a été uniquement mis en place pour vert. + +Il faut trouver une solution alternative à la configuration actuelle pour +récupérer +les données de munin dans nagios. Un plugin nagios existe apparemment pour lire +les fichiers rrd de munin. À creuser ? + +vo:/localhome/becue/nagios contient quelques scripts et éléments au fur et à +mesure de la config. La doc sera faite d'ici peu. + +Il faut intégrer monit à nagios (c'est à dire, faire en sorte que les warnings +de monit soient gérés par nagios, au niveau mail et interface web). +Un plugin nagios existe déjà pour se connecter à un serveur monit distant, il +faut donc voir à adapter la config de monit, ou à lancer le plugin en question +via NRPE. + +Il faudra aussi réfléchir à la "mise en production" des alertes mail de nagios +sur +roots@crans.org. + +### Wifi + +Pas de réponse d'interprojekt pour le retour des bornes (qui ne sont pas les +bonnes). + +Certains adhérents ont constaté un problème de compatibilité entre leur carte +réseau et le wifi n. Une désactivation du wifi 802.11n sur la carte niveau +client a été faite pour régler le problème. + +Il y a plusieurs possibilités sur la nature du problème. Cela peut-être +dû à la largeur du canal utilisé pour le WiFi n (les canaux à 40MHz ne sont pas +supportés par la carte, contrairement à ceux à 20MHz). Cela peut aussi être dû +à un driver moisi (il permet de désactiver le 802.11n, donc il n'est pas si +moisi que ça). On n'a pas constaté de problèmes lors des journées FedeRez, +donc ça peut aussi être lié au WPA2-entreprise. + +Pour résoudre ce problème particulier, plusieurs pistes : + +* Désactivation du 802.11n côté client + * Avantage : débit maximal pour les clients qui le supportent + * Inconvénients : tests au câblage plus lourds, toutes les cartes ne le + +supportent peut-être pas... + +* Dédoubler les SSID (Un ssid Cr@ns, un ssid Cr@ns-n) + * Avantage : débit max pour les clients qui le supportent, les vieux clients + ont toujours du wifi g + * Inconvénients : confusion ? +* Réduire la largeur du canal + * Avantage : toujours du n + * Inconvénients : est-ce que ça règle vraiment le problème ? +* Désactiver le wifi 802.11n + * Avantage : On est sûrs que ça marchera partout + * Inconvénients : pas un meilleur débit (enfin toujours un meilleur débit que + +les wrt54g...) + +Daniel a commencé à regarder pour le dédoublement des SSID, le reste est une +modification triviale en termes de config d'OpenWRT et peut être testé en +présence +d'un-e cobaye. + +Diomède sera réinstallée à la Kfêt, avec la config HT20 pour tester. + +### Ardoise virtuelle 0B + +L'idée de base est que l'interface d'accès aux locaux ne fonctionnera jamais +(les gens ne s'y inscriront jamais), Daniel propose de faire une interface +physique sur laquelle les gens s'inscrivent pour prendre une clé, et qui +consigne les accès directement dans la base. + +On pourrait aussi envisager l'idée d'installer une armoire à clefs électronique +un peu comme celle de l'ENS, qui ne permet de retirer que la clé pour laquelle +on s'est inscrit. Celà forcerait les gens à s'inscrire. + +Daniel s'occupe de faire ça et l'interface d'accès aux locaux, éventuellement +avec un apprenti (Julien ?). + +### Babar + +Il commence à en avoir plein la trompe. Olivier s'occupe de demander un devis à +Anne pour plus de disques, selon le nombre de slots disponibles. + +### Ragnarok + +Le nouveau serveur syslog est fonctionnel. + +Reste à mettre la config de rsyslog sur tous les serveurs pour qu'ils y envoient +leurs logs. Il faut faire attention à ne pas faire la modification à l'aveugle, +par exemple sur les serveurs qui dépendent de leurs logs (komaz, par exemple). + +Il faut aussi changer la config des switchs pour qu'ils envoient leurs logs +à ragnarok et non à vo. Daniel s'en occupe. + +Il faut configurer un frontend un peu plus sexy que psql. Yann s'occupe de +recenser ce qui existe. + +### Questions diverses + +#### Inscription aux mailing-lists des vieilles nounous inactives + +Plein de vieilles nounous + plein de spams = plein d'espace disque utilisé pour +rien. + +Plusieurs possibilités : virer les droits des gens; créer un droit "Vieux" qui +reçoit juste certaines ML; ne rien faire et remplir /home. + +Olivier envoie un mail à ces vieux pour leur demander ce qu'ils veulent toujours +voir et pourquoi. diff --git a/compte_rendus/2012_05_10.md b/compte_rendus/2012_05_10.md new file mode 100644 index 0000000..08931cc --- /dev/null +++ b/compte_rendus/2012_05_10.md @@ -0,0 +1,115 @@ +# Réunion Nounous + +* Date : Jeudi 10 avril 2012 +* Lieu : Hall du bâtiment B +* Début : 19h35 +* Fin : 20h35 + +## Présents + +* Aurore Moisy-Mabille +* Morgane Jançon +* Nicolas Dandrimont +* Olivier Iffrig +* Pierre Elliott Bécue +* Raphaël Cauderlier +* Sylvain Boilard +* Yann Duplouy + +## Ordre du jour + +### Ajout de droits + +nounous.append(PEB) + +### Logs + +Ragnarok fonctionne, et les logs sont bien reçus. Pour l'instant, on a +whatsupdoc, niomniom, vert, redisdead, ragnarok, gordon, et quatre switches +(bata-n n in {0, 1, 2, 4}). + +Il faut faire attention lors du passage vers rsyslog pour komaz. + +Ce n'est pas très long à faire, il s'agit juste de retirer syslogng sur les +serveurs où il est installé, puis mettre rsyslog et faire un bcfg2. Il faut +surtout trouver le temps. + +Yann se charge de trouver un frontend potable. Dans le pire des cas, un +frontend sera développé sous django. + +### Baie de disques + +Anne devrait envoyer un devis pour des disques supplémentaires d'ici demain. +Un workshop est prévu le 26, sous réserve d'obtention des disques d'ici là. + +### Virtualisation + +La migration à chaud d'un dom0 à l'autre ne fonctionne pas. Les domU ont été +déplacés sur fy afin de pouvoir mettre à jour fz sans souci (le noyau a quelques +mises à jour de sécurité de retard). On verra ce que ça donne par la suite. + +On peut utiliser ytrap-llatsni pour tester. + +### Wifi + +On va pouvoir renvoyer 30 des 33 !PicoStation à Inter Projekt, les trois +suivantes seront utilisées malgré tout. Il faudra payer les frais de port, et +on risque d'avoir du mal à couper aux 15%. + +Après l'aller-retour des bornes, il faudra du monde pour déployer le tout. +On prévoit ça pour le 2 juin. + +### Clim 0B + +La clim est en rade, la situation est devenue critique dans l’après-midi. +Le technicien de LTC passe demain, il faut que quelqu’un soit là pour +l’accueillir. PEB et Morgane sont disponibles, fonction de l'emploi du temps +du premier, on fera signe à la seconde. + +Il faudra aussi faire (un peu) attention cette nuit. + +### Mise à jour de rouge + +''A priori'', virtualiser rouge si on conserve Amavis, ça semble +problématique (trop +de ressources exigées). L'idée qui semble retenue est de passer le filtrage sur +zamok, que l'on passerait sur fx (qui est toujours sous utilisé). + +À faire en même temps que les tests sur la baie de disques (ou plutôt quand +ceux-ci seront concluants). + +### RAID + +Le RAID sur ragnarok et sila nous ont envoyé une erreur "!DegradedArray". Elle +a été corrigée. + +La commande en question : {{{mdadm --manage /dev/mdX --add /dev/sdYZ}}} où mdX +est l'array, et sdYZ le disque qui en a disparu (à trouver dans dmesg, il est +écrit "md: kicking non-fresh sdXY from array!" + +On va refaire un séminaire sur la gestion de disques (RAID, LVM) l'an prochain. + +## Questions diverses + +### Limite de détection de virus + +La limite de détection des floods est un peu basse (genre ouvrir safari avec 15 +onglets ça peut dépasser les limites de flood), il est donc suggéré de la +monter à 20 détections de 150 connexions par seconde pour l'instant. + +### Problèmes de mots de passe + +Les mots de passe de deux apprentis ont apparemment changé dans la nuit de mardi +à mercredi. On a strictement rien trouvé dans les logs. Il faut mettre en place +le système de logs LDAP. (qui est en place sur LDAP test sur vo). + +Olivier et Nicolas essaieront de s'en occuper sous peu. PEB viendra voir, pour +rédiger de la doc. + +### Firewall IPv6 + +Le démarrage du firewall IPv6 a été cassé par une mise à jour de config.py +(disparition de main_proxy ou whatever). À corriger par quelqu'un qui a +déjà touché à ce script... + +On demandera à Valentin et Daniel de regarder. diff --git a/compte_rendus/2012_05_24.md b/compte_rendus/2012_05_24.md new file mode 100644 index 0000000..d10b629 --- /dev/null +++ b/compte_rendus/2012_05_24.md @@ -0,0 +1,111 @@ +# Réunion Nounous + +* Date : Jeudi 24 mai 2012 +* Lieu : 2B +* Début : 19h10 +* Fin : 20h36 + +## Présents + +* Olivier Iffrig +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Sylvain Boilard +* Yann Duplouy + +## Ordre du jour + +### Sila + +Il fait de la merde avec ses disques. C'est pas la faute des disques, ni de la +carte SATA. On va utiliser vo comme miroir Debian temporaire, en attendant +d'avoir +une vraie solution, à choisir parmi : + +* Acheter un nouveau serveur +* Utiliser l'ancienne baie de disques et un serveur quelconque, une fois que la + nouvelle aura pris le relais, ça implique d'acheter des disques pour la baie. + +On part plutôt sur l'achat d'une nouvelle machine, un devis va être demandé à +Anne +et sera proposé au prochain C.A., avec les 2 possibilités. + +### Wifi + +#### MAJ de Windows 7 + +On constate que beaucoup d'adhérents n'arrivent plus à se connecter au wifi, +une mise à jour de Windows 7 pourrait en être la cause. Cependant, certains avec +une version à jour y arrivent encore. Il faudrait faire des tests : + +* Est-ce que ça marche avec CransWifi ? +* Est-ce que ça marche avec une configuration manuelle ? +* Qu'est-ce qu'il y a dans les logs ? + +PEB va envoyer un mail aux câbleurs pour qu'ils nous donnent un coup de main. + +#### Picostations + +Les pico sont arrivées en Pologne, on attend des nouvelles d'!InterProjekt. + +### Workshops + +#### Baie de disques + +Il n'aura pas lieu ce WE, contrairement à ce qui a été prévu. On garde ça sous +le +coude, selon l'évolution de la commande de disques (devis, approbation ou non du +CA, livraison). + +#### Logs + +Il faut passer les serveurs utilisant syslog-ng à rsyslog. Attention à komaz, +car +on a besoin de parser les logs. On fait ça ce WE. Appel aux apprentis motivés. + +#### Wiki + +L'idée est de remanier le wiki. Raphaël propose de fusionner CransNounous et +CransTechnique. Réécrire la doc pour ce qui manque. Voir comment on gère la +centralisation +de la doc proposée dans le cadre de FedeRez. +On prévoit un workshop ce WE, on peut en discuter d'ici là. + +### Cranspasswords + +Nicolas a commencé la réécriture d'un script cranspasswords, et Daniel a +continué. +Le script est actuellement en test sur vo dans /home/dstan/cranspasswords/ +(c'est un dépôt git). Le serveur est finalisé (cranspasswords-server) mais +il reste quelques fonctions à implémenter côté client (le script qui doit être +copié sur chaque machine de nounou). + +Le principe: le serveur stocke plusieurs fichiers json. Chacun contenant: + +* Une liste de rôles +* Le mot de passe gpg chiffré avec l'ensemble des clés de toutes les personnes + décrites par les rôles + +Pour mettre à jour, il faut donc chiffrer à nouveau avec toutes les clés +publiques +correspondantes, et ceci s'effectue sur le client. + +Pour l'instant, on peut lister les fichiers, voir et éditer les mots de passes. +(du coup, pour l'utilisation basique ça serait bon.) Il faut implémenter la +modification des rôles d'un fichier, la création et la suppression, qui se fait +pour le moment à la main. Et la regénération des fichiers lors du changement +des bénéficiaires d'un rôle. Le plus propre serait d'intégrer ça à LDAP. + +Next step: que tout le monde ait une clé, et idéalement, convertir aussi les +membres du CA/Bureau, pour la trésorerie par ex. Des rôles différents sont +disponibles en lecture et écriture. + +## Questions diverses + +### Kenobi, tu fais chier + +On veut mettre fz à jour, donc on le migre sur fy. + +### o2 + +Il semblerait qu'o2 ne sache pas envoyer des mails correctement. À étudier. diff --git a/compte_rendus/2012_06_07.md b/compte_rendus/2012_06_07.md new file mode 100644 index 0000000..d83f5c7 --- /dev/null +++ b/compte_rendus/2012_06_07.md @@ -0,0 +1,89 @@ +# Réunion Nounous + +* Date : Jeudi 06 juin 2012 +* Lieu : 2B +* Début : 19h20 +* Fin : 20h33 + +## Présents + +* Julien Baste +* Kévin Viard +* Morgane Jançon +* Olivier Iffrig +* Pauline Pommeret +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Sylvain Boilard (19h50) + +## Ordre du jour + +### Remplacement de sila + +Le remplaçant de sila est arrivé. Il s'appellera charybde. PEB va encadrer son +installation. Appel aux gens motivés. + +### Migration à chaud des DomU + +Olivier et PEB ont fait des tests de migration samedi. Ça marche. Ils en ont +profité pour mettre à jour les dom0. +Il y avait des soucis après la mise à jour de fz, il prenait toute la RAM par +défaut, on a modifié /etc/default/grub, pour rajouter la mention sur la quantité +de RAM que le dom0 a le droit d'utiliser (512 MB). + +### Disques pour la baie + +Olivier avait contacté Anne pour demander des disques pour la baie, car pour +l'instant on a pas de disques de spare, il voulait des devis. + +Plusieurs disques ont été proposés (dont du S-ATA), en 15 000 rpm, on peut +monter à 600 Go, à 505 € HT l'unité. Sinon on a du SAS en 7 200 rpm à 305 € +pour 1 To, 460 € pour 2 To, et 775 € pour 3 To, le tout hors taxe, et par unité. + +On proposera un devis au C.A., après avoir pris le temps d'en discuter. + +L'idée pour rester homogène serait de prendre les 600 Go à 15 000 rpm. + +### Identification sur les news + +Le conseil d'administration a demandé un audit auprès du collège des nounous +concernant une éventuelle limitation d'accès en écriture sur les news. Raphaël +est prêt à faire des tests, il installera inn2 sur vo. + +A priori, il sera peut-être nécessaire d'interfacer LDAP et inn2, mais il n'est +pas certain que ce soit facile. + +### Clés usb + +Un projet de clefs usb pour remplacer les t-shirts Cr@ns offerts lors de +l'adhésion a été lancé, il a été demandé aux nounous de proposer des éléments +à mettre dessus avant la rentrée. + +Un LiveCD ubuntu a été proposé, ou bien framakey, une suite de logiciels libres. +Il est peut-être possible de mettre les deux. + +Kévin suggère de mettre putty sur ces clefs, pour que les utilisateurs de +Windows aient un opérateur ssh accessible. + +On peut sinon proposer notre propre suite logicielle pour ces clefs. + +### Wiki + +Raphaël a proposé de fusionner CransTechnique et CransNounous, il faut lister +les pages concernées, les catégoriser, puis enfin, il faudra déplacer tout ça. + +Déplacer les pages pourrait flinguer leur historique d'édition, il faudra +vérifier cela avant de commencer à faire les opérations, ces historiques étant +utiles. On se demande aussi s'il faut clairement séparer les parties +administratives et techniques en termes d'architecture. + +Raphaël voudrait avoir un retour concernant les idées qu'il a proposées. + +Premier workshop lundi 11 au soir, à partir de 19h30. + +## Questions diverses + +### Cranspasswords + +Daniel demande aux nounous qui ne se sont pas encore inscrites dessus de le +faire. diff --git a/compte_rendus/2012_06_28.md b/compte_rendus/2012_06_28.md new file mode 100644 index 0000000..23f1e96 --- /dev/null +++ b/compte_rendus/2012_06_28.md @@ -0,0 +1,128 @@ +# Réunion Nounous + +* Date : Jeudi 28 Juin 2012 +* Lieu : 2B +* Début : 19h25 +* Fin : 20h47 + +## Présents + +* Nicolas Dandrimont +* Olivier Iffrig +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Sylvain Boilard + +## Avancées + +### Serveur FTP + +Pierre-Elliott et Pauline ont installé charybde, le serveur FTP a été remis en +route, ainsi que le miroir Debian et le serveur DNS. Daniel a remis en place les +dépôts Git et gitweb. Reste à remettre darcsweb et le miroir opkg. +Pierre-Elliott se charge de darcsweb. + +### Carte des bornes Wifi + +Daniel a mis en place une nouvelle carte des bornes sur l'intranet2 + + +Le but à terme est de pouvoir éditer les bornes directement depuis la carte +(position, ssid disponibles etc.), voire afficher les ssid "pirates" qui +pourraient être diffusés dans les alentours. + +### Mises à jour + +Quand on fait les mises à jour des serveurs, on lit correctement la liste des +paquets qui vont être impactés, et surtout on teste _tous_ les services après +la mise à jour. + +## Projets + +### SOGo + +Vincent Le Gallic s'occupe de mettre en place SOGo, encadré par Pierre-Elliott. +La partie +authentification, client mail fonctionne, reste à voir pour les contacts et les +agendas. + +### Baie de disques + +Deux disques ont été commandés pour la baie, ils arriveront... Bientôt. +On va faire des tests dès que les disques seront arrivés. Olivier se chargera +d'encadrer un éventuel apprenti motivé. + +### Impression + +Daniel a plusieurs suggestions pour améliorer le service d'impression, notamment +une surveillance automatique de la fin des tâches. + +Il faut également permettre aux adhérents d'annuler leur tâches non encore +imprimées (avec crédit), ce qui faciliterait aussi la vie des imprimeurs en cas +de bourrage et d'annulation de jobs en masse. + +Il y a aussi l'interface écrite par Antoine Durand-Gasselin pour remplacer le +driver foireux que l'on pourrait mettre en place, ou le module CUPS. + +Vincent a l'air intéressé, mais il a déjà plein de choses dans sa fifo. + +Avis aux autres apprentis... + +### Miroir OpenWRT + +Il y avait un dépôt opkg sur sila, on va essayer de faire un vrai miroir sur +charybde. Il semblerait qu'il n'y ait pas de serveur rsync public chez +OpenWRT, on va leur envoyer un mail pour demander. Raphaël s'occupe du mail et +victimisera un apprenti pour écrire le script. + +### Logs + +#### Logs sur komaz + +Il s'agit de remplacer syslog-ng par rsyslog qui a été choisi pour les logs +centralisés. Le "problème", c'est qu'il y a des règles spéciales pour écrire +les logs du firewall dans des fichiers séparés, qui sont "tail -F"és par des +scripts (filtrage_firewall.py) qui vont écrire les infos dans la base de +données pgsql de déconnexion. + +Il suffit de réécrire la règle qui marche actuellement pour syslog-ng de façon à +ce qu'elle marche pour rsyslog. + +Pierre-Elliott s'ennuie ce soir, il regardera ça. + +#### Anciens logs + +La question est de savoir quoi faire des actuels logs "fichiers". Nicolas pense +que tant qu'il n'y a pas de méthode plus simple qu'un select sur la base pour +accéder aux logs dans pgsql, il vaut mieux les garder. *silent ping* + +#### Frontend + +Daniel propose d'écrire un nouveau script qui contacterait la base PGSQL pour +faire les SELECT qui vont bien. + +Daniel avait aussi fait un prototype dans l'interface d'administration de django + +Enfin, Yann est censé regarder les frontends existants. + +#### Purge de la base + +La table des logs contient environ 60 millions d'entrées, les requêtes +effectuées dessus impliquant des champs indexés, tout se passe merveilleusement +bien, mais si la base doit être lue intégralement, les requêtes deviennent +sensiblement plus lentes. + +L'idée est de créer une seconde table qui contiendrait les données sur une durée +d'un an, et la première servirait aux données sur un délai raisonnable. On +placerait sur la table court terme un trigger qui copierait les données type +mail.log, auth.log, radius, les logs des switches, etc. dans la base long terme. +Deux scripts s'exécuteraient tous les jours pour virer les données périmées. + +Pierre-Elliott proposera à Kévin Viard. + +#### Logs des switchs / bornes Wifi + +Il faut aller dire aux switchs d'envoyer leurs logs sur ragnarok. De même pour +les bornes wifi. + +## Questions diverses diff --git a/compte_rendus/2012_09_06.md b/compte_rendus/2012_09_06.md new file mode 100644 index 0000000..58c99c8 --- /dev/null +++ b/compte_rendus/2012_09_06.md @@ -0,0 +1,150 @@ +# Réunion Nounous + +* Date : Jeudi 06 septembre 2012 +* Lieu : Pavillon des Jardins +* Début : 19h12 +* Fin : 21h20 + +## Présents + +* Daniel Stan +* Olivier Iffrig +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Steven Masfaraud +* Valentin Samir +* Vincent Guiraud +* Vincent Le Gallic +* Yann Duplouy + +## Bilan des vacances + +### Onduleur + +Pulsar nous a lâché durant l'été, le module électronique était défaillant. +Eaton nous en a renvoyé un, qu'on a mis en place durant la grosse mise à jour +le 9 août. + +Nicolas Dandrimont a proposé qu'on tire une seconde alimentation au 0B pour +servir de relais, ondulée ou non, depuis le local TGBT. + +Il faut attendre la fin de la rentrée, et éventuellement se faire une idée des +comptes, pour faire des devis. + +### Remplacement de la baie de disques + +La baie de disques a enfin été remplacée, la migration s'est faite sans aucun +souci, et les scripts d'interface ont été refaits. + +L'ancienne baie est toujours rackée au 0B. + +À long terme, il faudrait remplacer les cinq disques de 300 Go restants par des +disques de 600 Go, voire plus s'il en existe d'ici là. + +### Changement de serveur NFS + +On a profité des changements massifs pour remplacer le nfs par une machine +free (daath). + +À long terme, remplacer daath par une machine sous garantie ne serait pas +aberrant. + +### Remplacement de zamok + +Zamok a quitté son bel habit moisi pour aller dans celui de fx, qui venait de +se faire mettre au chômage technique. + +Ça swappe moins, ça a huit coeurs, 16 Go de RAM, et ça se tourne un peu les +pouces, sauf quand spamassassin tourne. + +### Suppression d'un MX + +On a catapulté rouge dans le nether, parce que redisdead suffit. + +freebox en profitait pour envoyer des mails, ce qui n'était pas normal. Par +ailleurs, freebox.crans.org est blacklisté par un serveur mail. + +### Ragnarok + +Le serveur de logs est mort, il était déjà mort quand il gérait le wifi. +Conclusion, on va arrêter de l'utiliser. + +Il faut cependant le remplacer, dans un délai rapide. On va temporairement +spoofer sur vo. + +Une demande de devis pour un serveur (idéalement rackable) supportant le SATA +sera faite. On le mettra au 0H s'il n'est pas rackable. + +### Webmails + +Vire-t-on horde ? Telle est la question. + +L'idée est de rediriger webmail.crans.org vers une page d'informations listant +les webmails disponibles. + +SOGo marche, mais certaines implémentations restent à faire. Pour l'instant, +mieux vaut proposer roundcube, et se donner quelques mois pour que Vincent +s'occupe de SOGo. + +## Projets + +### Séminaires (non techniques) + +Steven demande s'il est envisageable de faire des séminaires basiques sur +l'utilisation des services du Crans. + +Il trouve que les séminaires ont été réalisés jusqu'alors ne sont pas assez +pédagogues. Certains s'y connaissent (la plupart des apprentis avaient de +bonnes bases), et la majorité des personnes arrivant sur le campus n'ont pas +forcément les compétences nécessaires. + +Il suggère de rajouter, en plus des séminaires techniques, un certain nombre de +séminaires grand public pour présenter l'utilisation des services du Cr@ns, de +Linux, ou de LaTeX par exemple. + +Pierre-Elliott rappelle que lors d'une réunion aux alentours de juin, un ou +deux séminaires sur LaTeX avaient été prévus vers décembre. + +* Présentation des services pour les adhérents (tv, mail, news, irc, gobby, …) +* Installation de Linux +* LaTeX (à prévoir vers décembre, faire de la pub auprès des départements) + +### Séminaires + +Une liste d'idées de séminaires a été ajoutée sur le wiki, donnez vos idées. +Deadline : jeudi 4 octobre. +Certains séminaires seront organisés sous la forme d'un atelier, notamment +shell, python, GPG, réseau ? + +### Ménage câbleurs/apprentis + +Une liste des apprentis inconnus au bataillon a été faite. Olivier va s'occuper +du ménage. + +### WiFi + +Valentin a fait un très joli logiciel pour le WiFi sous Windows Vista et Seven. + +Il faudrait entamer un dossier à présenter au CROUS, pour installer le WiFi au +G et au M. + +!InterProjekt est en rupture de stock pour les bornes reparties en Pologne... +On attend et on croise les doigts de pied. + +## Questions diverses + +### Comptage upload ipv6 et extensions de vie privée + +La connectivité ipv6 est actuellement proposée au Crans. Le comptage d'upload +est par MAC-IP en ipv4 et 6. L'idée est d'autoriser les extensions de vie +privée (attribuer une IP aléatoire), pour éviter qu'on puisse identifier les +adhérents (leur adresse mac). + +On souhaite rajouter au comptage d'upload les adresses mac des adhérents, pour +que l'attribution aléatoire d'adresse soit possible. Valentin a commencé à +faire des choses, il nous en dira plus au fil du temps. + +### dnssec récursif + +Valentin voudrait importer la clef de l'IANA dans bind pour que nos DNS +puissent valider du DNSsec. diff --git a/compte_rendus/2012_10_02.md b/compte_rendus/2012_10_02.md new file mode 100644 index 0000000..054ce3e --- /dev/null +++ b/compte_rendus/2012_10_02.md @@ -0,0 +1,103 @@ +# Réunion Nounous + +* Date : Mardi 2 octobre +* Lieu : Salle Condorcet +* Début : 19h +* Fin : + +## Présents + +* Daniel Stan +* Lilian Besson +* Lucas Serrano +* Nicolas Dandrimont +* Olivier Iffrig +* Pauline Pommeret +* Pierre-Elliott Bécue +* Raphaël Bonaque +* Raphaël Cauderlier +* Valentin Samir +* Vincent Guiraud +* Vincent Le Gallic +* Yann Duplouy + +## Ordre du jour + +### Séminaires + +Olivier explique aux apprentis l'intérêt général des séminaires, les apprentis +peuvent y trouver une bonne occasion de découvrir un thème particulier. + +On prévoit un premier séminaire le 16 octobre (présentation des services) qui +sera davantage ciblé pour les adhérents tandis que le séminaire du 23 sera à +destination des apprentis. + +### Onduleurs + +Plus d'onduleur au J, A, I, M, 2B. Des devis ont été reçus pour les remplacer. +Pour 4 switchs, on arrive à 687€ HT +Pour le bâtiment M (8 switchs): 857€ HT + +Le problème de la température dans les locaux J et M se pose. On va demander +de nouveaux devis pour des onduleurs non rackables (moins chers). + +### Serveur de remplacement pour ragnarok + +Pas de nouvelles pour un serveur de remplacement. Le standard pour les disques +semble avoir changé chez HP. À vérifier. + +On reste en attendant sur une config temporaire sur vo pour récupérer les logs. + +### Réflexion sur la continuité des services "à vie" du Cr@ns + +(pendant/après le déménagement de l'école) + +Ce point vient d'une rencontre avec Barbich' au resto de l'X +Avec les discussions en cours pour la migration à Saclay, plusieurs questions +se posent sur la continuité des services du Cr@ns, si l'association ne dispose +pas de matériel sur le nouveau site. L'idée est de proposer un schéma de +migration +des services vers un hébergement à long terme. + +On en rediscute avant décembre avec Cyril Cohen (qui avait soulevé ce point). + +### Mailing Lists + +PE suggère de faire le ménage parmi les mailing lists. On peut regarder +l'ancienneté +des archives afin de déterminer si elles sont toujours utilisées. Pour les MLs +non archivées, on peut envoyer un message pour demander s'il y a toujours de la +vie. + +Raphaël Cauderlier propose de synchroniser les clubs et leurs mailing-lists. +On peut aussi donner un moyen simple d'aliaser le mail du club avec leur +mailing-list. + +Lilian et Lucas sont motivés pour regarder ça avec Daniel. + +### Promotion nounou + +Le collège technique nomme Vincent nounou. Du coup, il va falloir refaire un +double de la boîte à clé et de l'armoire serveur (PE s'en charge.) + +### Questions diverses + +#### Imprimante + +Il se passe deux trois trucs tout de même +Une planche a été mise pour fermer la fenêtre. Conséquemment, la porte ne se +claque plus. Il faut trouver un groom avec plus de force. + +Pauline a discuté avec le CROUS pour avoir les plans, ou au moins le cahier des +charges, du 4J et est allée demander les plans au service de l'urbanisme de la +mairie. + +#### Personnel ENS + +Ca fonctionne toujours aussi bien, Valentin à rajouté le routage du multicaste. +On envisage de placer directement les personnels sur le vlan adhérent, et de +voir ce qui arrive. + +#### Organisation du collège technique + +Pauline a posé plusieurs questions, un résumé d'ici peu. diff --git a/compte_rendus/2012_10_30.md b/compte_rendus/2012_10_30.md new file mode 100644 index 0000000..cc5ed0a --- /dev/null +++ b/compte_rendus/2012_10_30.md @@ -0,0 +1,195 @@ +# Réunion Nounous + +* Date : Mardi 30 octobre 2012 +* Lieu : 2B +* Début : 18h30 +* Fin : 22h07 + +## Présents + +* Daniel Stan +* Lilian Besson +* Olivier Iffrig +* Pauline Pommeret +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Valentin Samir +* Vincent Le Gallic +* Yann Duplouy + +## Ordre du jour + +### Bornes Wifi + +Les !PicoStations sont arrivées. + +* On a un problème : avec les anciennes comme avec les nouvelles bornes, il + arrive qu'au bout d'un temps aléatoire les utilisateurs n'arrivent pas à + aller plus loin que le DHCP. Une solution proposée est de faire un script qui + monitore ça, et qui relance ce qu'il faut ("wifi" semble suffire, mais on + peut décider selon les cas de rebooter la borne). De plus, hostapd semble + segfaulter sur certaines bornes, il est suggéré d'installer monit sur les + bornes, à voir si c'est suffisant. Daniel et Valentin vont voir ce qu'ils + peuvent faire. +* Pour le flashage : il faut des volontaires. On fera ça au fur et à mesure, + appel aux intéressés. +* Feature potentiellement intéressante des nouvelles bornes : il serait + possible de faire de l'authentification Pre-Shared-Key avec une clé + différente par MAC. Revers de la médaille : on ne peut plus valider le + certificat radius, donc possibilités de bornes pirates. Il pourrait y avoir + d'autres problèmes de sécurité si la borne connait le mot de passe en clair + de l'utilisateur. +* Étant donné qu'on va pouvoir recycler les anciennes bornes, il serait + intéressant d'essayer de faire fonctionner la dernière version d'OpenWRT + dessus. On va voir au cas par cas ce qu'on peut récupérer. +* En attendant d'avoir une réponse du CROUS pour l'installation de nouvelles + bornes, on peut déjà remplacer les anciennes bornes dans les faux-plafonds + par des nouvelles. Ça implique de ressertir les câbles PoE maison. Avis aux + intéressés. +* On n'a toujours pas les plans des bâtiments, donc pour l'instant le dossier + pour le CROUS est en attente + +### Logs + +#### Serveur + +* On a reçu un devis de la part de notre fournisseur : même gamme que fx, fy et + sable. Cela fait peut-être un peu overkill, surtout que l'on est en train de + migrer les services qui sont sur sable. Le serveur est a + priori 100% modulaire, mais cher. +* Pas de SATA sur sable, mais du SAS, vu qu'on est en train de migrer les + services de sables vers des domU, il pourrait être envisageable d'acheter des + disques SAS et d'utiliser sable comme serveur de log. + +On va demander des précisions/des nouveaux devis pour les différentes solutions +suivantes : + +* Acheter le serveur (2500€ + éventuellement les disques → 3120€) +* Demander un serveur moins cher mais rackable (disques inclus) +* Utiliser sable en demandant seulement des disques SAS + * Extension de garantie pour sable ? + +Il faut réfléchir à l'espace disque nécessaire. +Olivier s'occupera ensuite de demander les devis. + +#### DomU pour les consulter + +Daniel a créé un DomU de log qui récupère ceux de gordon (afin d'avoir des +données dans la base). Yann va configurer un frontend sur cette machine. + +#### Envoi des logs + +Vu que ragnarok n'est plus, et qu'on a des soucis pour récupérer les logs sur +vo, +on désactive cette fonctionnalité. + +Seuls gordon (et donc les bornes WiFi) et news envoient leurs logs au domU, on +va rajouter quelques serveurs supplémentaires pour avoir une petite base de +données +qui reste représentative, ceci afin de développer et tester le frontend. + +#### Logs d'Apache + +Apache n'utilise pas syslog. Il faut interfacer Apache avec syslog. On peut dire +à Apache d'envoyer ses logs à un programme externe. Valentin s'en charge. + +### DHCP + +Valentin a créé un DomU (dhcp) centralisant tous les dhcp. Il a donc une patte +sur tous nos VLAN sur lequel le service est présent (adhérent, wifi, accueil, +isolement, appartement, install party). + +Les switchs ont été reconfigurés pour le dhcp snooping, désormais sur tous les +vlans. Seul bata-3 n'a pas été reconfiguré car il semble mal configuré pour +un réglage à distance. Une fois que ce problème sera réglé et après +vérification, +on pourra couper les anciens services (sur sable, gordon, titanic). Pour +l'instant, +les serveurs fonctionnent en parallèle. + +### Réunion avec la DSI + +Il faut organiser une réunion avec la DSI. + +Ordre du jour : + +* Réunion périodiques ? (nouvelles têtes, coucou c'est nous) +* Personnels NATés sur Renater +* Plans du réseau +* Gigabit +* Clef placard (On a une clef du placard qui emprisonne ilona, mais elle est + endommagée. On peut leur demander la leur pour faire un double.) +* IPv6 (Rubis il est méchant) +* Étoiler le PDJ. (minigiga.new() → 0P) +* conf bato-1 (agrégation des deux fibres disponibles) : accès à l'autocom + nécessaire + +### Passage de LDAP à PostgreSQL + +Vincent Le Gallic a remis ça sur la table. Pourquoi ça a été abandonné ? Mis +à part le boulot niveau scripts crans, pourquoi pourrait-on ne pas vouloir y +retourner ? + +Premièrement parce qu'on ne peut pas "mettre à part" le boulot au niveau des +scripts : personne ne les améliore pour LDAP, je ne vois pas pourquoi ça serait +plus facile de les refaire from scratch... + +Deuxièmement parce que l'intégration de LDAP à tous les services est +éprouvée (authentification, radius wifi, postfix, dovecot, apache...), +contrairement à celle de postgresql (libnss-pgsql avait tendance à segfaulter +aléatoirement) + +Troisièmement parce qu'il y a des choses plus utiles et plus intéressantes à +faire. Notre fonctionnement autour de LDAP est correct, pourquoi repartir de +zéro ? +-- NicolasDandrimont <> +Les réplicat SQL ont tendance à se désynchroniser et ne pas toujours super +bien fonctionner. + +On oublie ce point pour l'instant, au vu des réponses, un jour… peut-être… + +### Switchs du bâtiment G + +## Daniel propose d'enlever des switchs inutiles au bâtiment G + +batg-2 et batg-7 pourraient être libérés pour remplacer des switchs en fault, +en mettant des adhérents sur les switches gigabit. Il faudrait d'ailleurs faire +jouer la garantie des switches défectueux. Ou les mettre à la poubelle/donner. + +### Questions diverses + +#### DNSSEC + +Valentin a activé la validation DNSSEC sur les résolveurs DNS du Cr@ns. Ça +marche. + +Le point suivant serait de signer la zone Cr@ns. (Valentin propose aux +apprentis présents (hint : ∅)) +Ça consiste à faire des tests. +Attention : il faudra penser à pusher la clé publique chaque année. + +#### PXE + +Valentin veut migrer le PXE de sable vers charybde. + +#### Ménage Baie de disque + +Pierre-Elliott fera le ménage dans la baie de disques. + +#### DomU routage + +Valentin, toujours dans son idée de nettoyer sable des services, pour l'utiliser +à d'autres fins, souhaite créer un domU de routage spécialisé pour les +VLANs appartement, isolement, accueil, etc… +On y mettrait aussi un serveur web pour servir les pages de déconnexion et finir +(lentement) de démanteler squid. + +#### lc_ldap + +Il faut finir de coder lc_ldap et le documenter (pas forcément dans cet ordre). +Sont motivés : Pierre-Elliott, Vincent, Olivier. + +#### Mails superflus + +Vincent propose de passer en revue tous les mails reçus par les nounous afin +d'alléger le débit de mails. Olivier regardera avec Vincent. diff --git a/compte_rendus/2012_11_15.md b/compte_rendus/2012_11_15.md new file mode 100644 index 0000000..274027f --- /dev/null +++ b/compte_rendus/2012_11_15.md @@ -0,0 +1,84 @@ +# Réunion Nounous + +* Date : Jeudi 15 novembre 2012 +* Lieu : Salle Condorcet puis Fonteneau (à partir de 20h) +* Début : 19h23 +* Fin : 21h04 + +## Présents + +* Anne Cazalet (Synaps) +* Ariane Soret +* Daniel Stan +* Lilian Besson +* Nicolas Dandrimont +* Olivier Iffrig +* Pauline Pommeret +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Raphaël-David Lasseri +* Valentin Samir +* Vincent Le Gallic +* Yann Duplouy + +## Ordre du jour + +### Serveur de logs + +Anne nous présente le serveur présent dans le dernier devis. Pas de +compatibilité +possible avec les anciens disques durs. On partirait sur des nouveaux disques +durs +SAS (4*300G). C'est un serveur milieu de gamme. + +### Garanties + +Un point est fait sur les garanties des serveurs (date d'expiration, +renouvellement)... + +Cf. [[CatégorieCrans/LesServeurs]]. + +### Autour de LDAP + +PEB a commencé à manipuler la base LDAP de test (en particulier avec la config +qui est désormais une base LDAP). Il sait désormais modifier le schéma à la +volée. Le but à terme et de travailler sur lc_ldap et de documenter à la fois +le fonctionnement de ce script et de slapd et ses utilitaires. + +A priori, le howto sera prêt pour le séminaire ldap, mais sûrement pas le +binding. + +### Wifi + +Il faut définir une date de workshop flashage, au moins pour les bâtiments A, B, +C. et envoyer un mail. On essaie d'en faire une dimanche prochain, si motivé, +avis aux volontaires (apprentis). + +Pierre-Elliott, Daniel et Ariane sont passés voir le directeur de la résidence +qui nous a affirmé que le Crous de Créteil était favorable +au projet WiFi. Pauline souhaiterait un accord écrit pour éviter tout problème. +En attendant, il leur a proposé de rencontrer rapidement le responsable +patrimoine vendredi 16 lors de sa rencontre avec le Bde. + +### Install Party + +On installe Ubuntu par défaut. Si Debian, faire attention, l'installeur est +toujours (partiellement) pété. +Le plus grand dilemme réside dans le choix de l'interface graphique : Unity, +Gnome, +ou Xfce ? + +Pauline propose que des gens soient dédiés à la présentation de différentes +distributions/interfaces et soulève le problème de pédagogie des nounous. Elle +préférerait que les installés soient davantage assistés dans leurs installations +plutôt qu'une nounou s'occupe de tout. Il est en effet proposé de présenter une +distribution Linux (celle de l'encadrant) pendant l'installation. + +Le PXE est accessible depuis peu (merci Valentin) sur le vlan accueil, donc +sans enregistrer l'ordinateur. Il faudrait donc obtenir ce réseau en untagged +à la Kfet. + +### Nounou encadrante + +Mettre à jour la page CransNounous, à défaut de précisions, la nounou encadrante +est celle qui a donné les droits. diff --git a/compte_rendus/2012_11_29.md b/compte_rendus/2012_11_29.md new file mode 100644 index 0000000..81f12f1 --- /dev/null +++ b/compte_rendus/2012_11_29.md @@ -0,0 +1,143 @@ +# Réunion Nounous + +* Date : Jeudi 29 Novembre +* Lieu : Condorcet +* Début : 19h22 +* Fin : 21h26 + +## Présents + +* Daniel Stan +* Florian Tilquin +* Nicolas Dandrimont +* Olivier Iffrig +* Pauline Pommeret +* Raphaël Cauderlier +* Sylvain Boilard +* Valentin Samir +* Vincent Le-Gallic + +## Ordre du jour + +### Quotas + +Les quotas sont maintenant fonctionnels à travers NFS. Si la limite "soft" est +dépassée, un mail est envoyé (par jour). Si la limite hard du quota +est dépassée, l'appel système write retourne une erreur. On mettrait 2Go en +limite soft et 2Go + e (e~=200Mo) de limite hard. Pierre-Elliott +suggère d'activer les quotas sur zamok pour les adhérents. + +Les quotas traversent le NFS, il faudrait mettre en application lesdits +quotas sur tous les comptes, puis éventuellement lever ceux des membres actifs, +quitte à définir des conditions. +Il faut également tester si gest_crans les applique bien quelle que soit la +méthode de création de compte crans. + +### Wifi + +On a commencé au A, il faut continuer, le CROUS étant d'accord pour la pose. +État du flashage : au moins la moitié des Pico Stations et des Nano Stations +du M ont été flashées. +Des Pico Stations ont été posées aux 2, 4 et 6ème étages du bâtiment A. +Valentin a commandé un tire-câble pour commencer à câbler au M. +Il reste du travail, on va faire ça au fur et à mesure, quand on aura des +apprentis motivés. On propose un framadate : + + +### Réunion DSI + +Gaetan, Raphaël, Morgane et Olivier ont rencontré la DSI (Stuart Mc``Lellan et +Jocelyn Viallon) le 19 novembre. + +#### Débit + +L'ENS a un argrément gigabit avec Renater. Dans un premier temps, l'ENS nous +autorise l'utilisation de 500Mbit/s entre 19h et 6h30. Komaz a l'air de souffrir +par moments. En revanche, (cf graphes munin) on ne sature pas (après quelques +minutes de load élevé). On va demander si on peut être débridés le week-end. + +#### Câblage du PdJ + +On peut avoir accès au sous-sol du PdJ, il faut décider du switch et de la date. + +Daniel propose un +HP 1910-8G (JG348A) + +Il a l'air d'avoir toutes les fonctionnalités nécessaires (IGMP + MLD snooping, +vlans). Le seul inconvénient est le management http(s)-only. + +On proposera le devis au C.A.. + +#### Eduroam au PdJ + +Le C.A. a accepté la demande de la DSI concernant la diffusion d'eduroam au +pavillon des jardins. Il nous faudra le mot de passe radius de l'E.N.S. pour le +faire, et installer quelques picostations au PdJ. + +Il faudra ouvrir un VLAN pour cela. + +#### Réunions Crans/DSI/DSI des dpts/labos + +La DSI avait proposé qu'on participe à leur réunion de mardi dernier. Mais on a +pas été recontactés. Olivier va leur envoyer un email pour plannifier la +réunion suivante. + +#### Miroir debian de l'E.N.S. + +L'école voudrait nous confier la gestion de son miroir debian officiel. + +#### IPv6 + +Le Crans est prêt, Rubis est prêt, l'E.N.S. non, pour des raisons +administratives +apparemment. + +### Surveillance de la correspondance MAC / chambre + +Suite à la détection d'un spoofeur de MAC de longue date. Valentin et Daniel +envisagent de passer à une authentification par mot de passe sur le réseau +filaire. +Pierre-Elliott va bientôt mettre en place un script de surveillance utilisant +les données fournies par les switchs (en snmp). Dans tous les cas, il faut +un script de surveillance plus efficace que "déménagement non déclaré". + +### Monitoring du climat du 4J + +Olivier a fait une mini station météo qui se trouve au 4J pour surveiller +l'évolution de l'humidité et de la température. + +### Questions diverses + +#### Remplacement switches HP + +On a remplacé 4 switches défectueux au niveau de HP. Pierre-Elliott recommencera +dans un mois avec les suivants. + +#### club-bde@zamok /usr/sbin/rssh + +Vincent demande si on peut changer le shell du bde sur zamok. +Parce backup-manager uploade des fichiers de backups sur le home Cr@ns du bde +mais il ne peut pas les supprimer parce qu'un ssh lui est refusé. + +En fait c'est --(impossible)-- compliqué. + +#### Switch manageable à la Kfêt + +À faire s'il nous en reste. Le remplacement des switchs en fault dans les +bâtiments +reste prioritaire. + +#### Ldap + +olcLogging: il n'est pas possible de laisser les logs dans la même +racine que les données logguées. Cela va compliquer l'implémentation de lc_ldap. +On rappelle que la base ldap est censée stocker les chaînes en utf-8. +So``Go et le champ mail : notre champ mail contient uniquement +l'utilisateur (sans +@crans.org). Normalement, la sémantique de ce champ est une adresse mail +complète +ce qui fait planter So``Go. Il faudrait donc changer cette valeur, et faire +attention +à tous les services que l'on risque de casser, ou utiliser un autre champ, ce +qui +produira une redondance dans les données. Des tests restent à faire. diff --git a/compte_rendus/2012_12_13.md b/compte_rendus/2012_12_13.md new file mode 100644 index 0000000..cfbfc37 --- /dev/null +++ b/compte_rendus/2012_12_13.md @@ -0,0 +1,127 @@ +# Réunion Nounous + +* Date : Jeudi 13 Décembre 2012 +* Lieu : Salle Condorcet +* Début : 19h25 +* Fin : + +## Présents + +* Aymeric Labatut +* Daniel Stan +* Olivier Iffrig +* Pauline Pommeret +* Pierre-Elliott Bécue +* Sylvain Boilard +* Valentin Samir +* Yann Duplouy + +## Ordre du jour + +### Serveur de logs + +Thot est installé (wheezy), et reçoit des données de tous les serveurs. Il faut +voir si on souhaite modifier les requêtes d'insertion SQL, et donc la base de +données. +La priorité : définir la structure de base de données qu'on veut, pour pouvoir +écrire +les requêtes qu'on veut et qu'on mette le système en service. + +Les services sur pgsql (comptage d'upload, filtrage firewall, correspondance +mac-prise) +seront migrés sur thot. +Valentin fait remarquer qu'il peut être bien de conserver un réplicat de la +correspondance mac-prise, nécessaire à l'authentification radius. + +### Prochaine Debian stable + +Wheezy est bientôt dans les bacs. + +#### Repackaging de Bcfg2 + +Le nouveau bcfg2 n'est pas compatible avec l'ancien, on a donc tout migré vers +la +nouvelle version. + +À savoir : les balises !ConfigFile, Directory, Symlink sont devenues Path, les +scripts +python ont leur propre balise Python. + +Reste à remettre en service bcfg2-repo-validate (utilisé par darcs). + +#### Passage sous wheezy des serveurs du crans + +A priori, pas avant que wheezy soit la nouvelle stable, mais il serait bien +d'en discuter un peu avant. + +Il faudra faire attention à + +* dovecot +* radius (l'appel de scripts externes est déprécié) +* moinmoin (les patches vont bouder) +* iscsi (sur les dom0 et le nfs) +* portmap est déprécié (passage à rpcbind), + +il peut être envisagé de mettre à jour daath en dernier pour éviter les clashes + +Dans tous les cas, il va falloir se farcir les changelogs. + +### Script mac_prises + +On avait fait un script qui listait les adresses macs connectées dans chaque +chambre, il faut ajouter des choses pour limiter au maximum le spoof non +repérable. + +Par exemple, cela vaut-il le coup que thot stocke en base de données le triplet +(mac, date, prise(s)), et qu'on bosse avec ce genre de données ? + +On va mettre une page sur le wiki pour des suggestions, et essayer de discuter +avec +le C.A., pour obtenir un réel cahier des charges. Après on commencera. + +### Installation des nouvelles bornes wifi + +Quelques bornes ont été placées au M, d'autres au A, il faut continuer, et +trouver +des apprentis motivés ! + +### Lien Gigabit vers l'extérieur + +Prochainement, une réunion avec la DSI pour parler gigabit le weekend, et +éventuellement augmenter un peu en journée. + +### TV + +Daniel a testé la diffusion de la TV avec un Raspberry Pi. Ça lag, à voir si +c'est +parce que ça capte mal ou parce que manifestement l'USB et l'Ethernet passent +par +le même bus sur la carte. +Les serveurs free n'étaient, à l'époque où ils ont été reçus, pas compatibles +avec +les cartes, il faudrait voir pour quelle raison. +Il faudrait réfléchir à d'autres solutions. + +Quid de l'amplification des signaux TNT ? + +#### HD + +Vu que la HD n'est pas supportée par tous les PC, et que "c'est l'avenir", on +pourrait +imaginer baisser la résolution pour que les gens qui n'ont pas une machine assez +puissante puissent quand même regarder la TV. Problème : ça demande de la +puissance +de calcul... À voir si on a envie de le faire. + +Dans un premier temps, on pourrait passer le flux TV d'une chaîne vers malloc +ou une autre machine pour faire des tests de transcodage. + +### Divers + +#### Imprimante + +On va appeler Thomas Hocine pour lui dire que le service après-vente ne +respecte pas vraiment les +clients, et que par conséquent, le C.A. s'interroge vraiment sur la pertinence +de signer +le contrat. diff --git a/compte_rendus/2013_01_10.md b/compte_rendus/2013_01_10.md new file mode 100644 index 0000000..090ffe4 --- /dev/null +++ b/compte_rendus/2013_01_10.md @@ -0,0 +1,223 @@ +# Réunion Nounous + +* Date : Jeudi 10 janvier 2013 +* Lieu : Condorcet +* Début : 19h16 +* Fin : 21h36 + +## Présents + +* Ariane Soret +* Daniel Stan +* Lucas Serrano +* Olivier Iffrig +* Pauline Pommeret +* Pierre-Elliott Bécue +* Raphaël Bonaque +* Raphaël Cauderlier +* Valentin Samir +* Vincent Le Gallic +* Yann Duplouy + +## Ordre du jour + +### Gmail + +Depuis mi-décembre, Gmail refuse de récupérer les mails depuis les serveurs +dont il ne reconnaît pas la validité de l'autorité de certification, CACert +faisant partie des autorités non reconnues +Depuis le 12/12/12, Gmail a changé sa politique de vérification des certificats +SSL, CAcert ne fait plus partie des autorités de certification reconnues comme +"de confiance" et les utilisateurs ne peuvent pas changer ce comportement. + +Les adhérents Cr@ns ne peuvent donc plus relever leurs mails Cr@ns sur leur +boîte Gmail. + +La situation et la marche à suivre pour les adhérents sont ici : + + +Le Cr@ns pourrait proposer un autre serveur imap avec un certificat d'une autre +autorité. +En dehors du problème idéologique et de "flemme", cette solution implique tout +de même de continuer à encourager les adhérent à donner leur mot de passe Cr@ns +à Google. + +L'avis général semble être plutôt de rester dans la situation actuelle. +Daniel (avec un apprenti [les absents, levez la main]) va tout de même essayer +de mettre en place un serveur imap alternatif. + +Valentin soulève la question d'un mot de passe alternatif (optionnel) permettant +de s'authentifier sur les serveurs mail / imap / ... seulement. +À voir si c'est possible. + +### SIP + +Le SIP (Session Initiation Protocol) est un protocole de signalement +permettant de mettre en relation deux pairs. Il est principalement +utilisé dans le cadre de la téléphonie sur Internet (Voix sur IP). + +{{{asterisk}}} a été ressuscité et le Cr@ns possède une ligne SIP chez OVH. +Le service a donc été mis en place et est maintenant disponible pour les +adhérents. +Modulo l'installation d'un client SIP et une connexion internet, +les adhérents peuvent donc téléphoner. Dans un premier temps entre comptes SIP +Cr@ns, mais il y a également une passerelle vers l'extérieur. + +L'interface sur l'intranet2 permet l'inscription, la gestion de sa configuration +(mot de passe, code perso de la messagerie, se masquer dans l'annuaire), un +annuaire… + +Pour les utilisateurs, c'est en test : + +Reste à faire : + +* Documentation technique +* Documentation d'utilisation (Yann s'occupe d'Android, iOS ?) +* Facturation de la passerelle (prix coûtant? On utilise le compte impression?) +* Service d'impression ? (notification des impressions, dictée du digicode) +* Numéro unique vers la Nounou d'astreinte ? + +Bref, il y a plein de possibilités. + +### DNS + +#### DNSSEC + +DNSsec est une extension du protocole DNS qui permet de signer numériquement +les réponses des requêtes DNS. + +Elle (l'extension) a été mise en place par Valentin sur le domaine +{{{crans.eu}}}. + +À terme, il serait bien de signer {{{crans.org}}} + +Il n'est pas possible pour un serveur de répondre qu'il a effectuer une +validation +dnssec s'il est autoritaire pour la réponse. +Il pourrait être bien de séparer DNS récursif et autoritaires. + +#### Renouvellement nom de domaine + +{{{crans.fr}}} expire dans une cinquantaine de jours. Il ''faut'' le renouveler. +Olivier s'en occupe. + +#### Champs DNS + +Valentin a rajouté un champ TXT dans les réponses DNS des bornes wifi, +qui contient : {{{"LOC %f,%f" % (latitude, longitude)}}}. + +Il désirerait aussi rajouter un champ SSHFP pour pouvoir transmettre les +fingerprints SSH des serveurs. Combiné à DNSSEC, cela permettrait de s'assurer +de l'absence de Man in the Middle quand on se connecte à un serveur en SSH. + +À étudier plus profondément. + +### Documentation Sphinx + +Olivier a mis en place de quoi documenter le nouveau binding LDAP avec Sphinx +C'est une librairie pour python qui permet de générer automatiquement de la +documentation. + +Olivier l'a mise en place pour {{{lc_ldap}}}. C'est beau, il faut continuer. + +### Wifi + +Le bâtiment M est couvert sur tous les étages sauf le 4ème et le 5ème Nord. +Le bâtiment A est couvert aux étages pairs. +Le reste est à faire. + +On va fixer un rendez-vous régulier, par exemple le dimanche une fois tous les +quinze jours. + +### IRC + +Dancer-ircd, le daemon IRC actuel, ne semble plus très maintenu et manque de +features, principalement un support de SSL et de l'ipv6. +On souhaiterait donc changer de daemon pour quelque chose de plus moderne. + +UnrealIRCd semble bien mais n'est pas package pour Debian (voir +) + +daemons packages sous squeeze : + +* dancer-ircd +* inspircd +* ircd-hybrid +* ircd-irc2 +* ircd-ircu +* ircd-ratbox +* ngircd + +Supportant SSL d'apres + + +* inspircd +* ircd-hybrid +* ircd-ratbox +* ngircd + +Supportant l'IPv6 d’après la même page: tous + +inspircd ftw ? + +Pierre-Elliott va se pencher sur inspircd qui a l'air packagé, supportant SSL, +IPv6 et pas trop "pain in the ass" à configurer. + +Il faudra contre-annoncer pour dire que finalement on ne fera pas de changement +Dimanche. + +### Mail + +#### Champ mail dans la base LDAP + +Le champ mail a été modifié dans la base LDAP pour pouvoir être utilisé +par !SoGo +(c'est-à-dire que l'on enregistre dans tous les cas une adresse mail, et non le +login lorsque l'adhérent a un compte Cr@ns). PE avait effectué dans un premier +temps la modification sur son propre compte afin de chasser les bugs dans les +scripts qui supposaient manipuler un login (et non une adresse mail). + +#### Réécriture des en-têtes mail + +Pendant un certain moment, dans les mails envoyés et reçus, toutes les adresses +mails envoyées et reçues étaient automatiquement remplacées par +Prenom.Nom@crans.org (''i.e.'' l'alias canonique). Cette réécriture a été +désormais +désactivée, ce qui a posé des problèmes pour déterminer le destinataire final +du mail et il a fallu corriger après coup les filtres de recherches dans +la configuration postfix. + +Ceci explique quelques dysfonctionnements dans l'acheminement des mails pendant +environ une semaine. + +### Tests de configuration des services + +Suite à ces problèmes, iota propose la mise en place de serveurs alternatifs +afin de tester les configurations de services critiques. +PEB a remplacé les adresses mail dans la base LDAP par leur version avec +@crans.org. On a en même temps supprimé la réécriture d'en-tête des emails. +Cela a malheureusement engendré des bugs, et la perte de mails. + +De manière générale, il faut faire attention lorsqu'on touche à des services +critiques en place dont on ne maîtrise pas la façon dont ils loguent +(dovecot, postfix), bien lire la doc, et surtout demander aux développeurs +des services si on a un doute concernant une fonctionnalité. + +### Bug tracking, projets + +On a deux bug trackers, debbugs () et +redmine (), plus éventuellement des todolists sur le +wiki. +L'idée est de se décider sur lequel on utilise. On garde redmine. + +Raphaël propose également d'utiliser une catégorie wiki !CategorieProjetEnCours. + +### Passage à Git + +Deux outils de versionnement présente plusieurs inconvénients : + +* Plus de commandes à connaître, et risque de s'embrouiller +* Nos dépôts darcs ne sont pas à jour. + +On se propose de passer nos dépôts darcs sous git. +Vincent et Daniel s'en occupent et encadreront Pauline. diff --git a/compte_rendus/2013_01_24.md b/compte_rendus/2013_01_24.md new file mode 100644 index 0000000..a007081 --- /dev/null +++ b/compte_rendus/2013_01_24.md @@ -0,0 +1,109 @@ +# Réunion Nounous + +* Date : 24 Janvier 2013 +* Lieu : Condorcet +* Début : 19h27 +* Fin : 21h17 + +## Présents + +* Ariane Soret +* Daniel Stan +* Olivier Iffrig +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Raphaël-David Lasseri +* Sylvain Boilard +* Thomas Epalle +* Valentin Samir +* Vincent Le Gallic +* Yann Duplouy + +## Ordre du jour + +### Script d'impression par l'interface web + +L'impression par le driver de l'imprimante sur {{{zamok}}} pose certains +problèmes +qui sont évités quand on fait des impressions manuelles, c'est pourquoi il avait +été proposé d'automatiser l'impression par l'interface web de l'imprimante de +manière à ne plus avoir à se servir du driver. + +Ce travail peut être fait par un apprenti. Ariane est motivée. Vincent encadre. + +### Groupe fuse sur zamok + +Valentin propose d'autoriser les utilisateurs à utiliser fuse sur zamok. On +évitera d'autoriser la lecture aux autres utilisateurs que le propriétaire +(potentiels problèmes d'upload par apache, updatedb, etc) + +On ajoute le groupe fuse à ldap pour y mettre tous les utilisateurs + +### Identification des machines dans l'annuaire LDAP + +cf. mail de PEB sur nounous@ du 23 janvier à 05:56 +Actuellement un mid est associé, par le biais d'une fonction inversible à une +adresse ip. +Cela force la réutilisation des mid au cours des ans et est gênant pour +l'identifiaction d'une machine sur le long terme. Il est proposé de rendre le +mid strictement croissant et le remplacer par un rid. +Il sera également utilisé pour attribuer un préfixe ipv6 aux machines. +De plus, il devient possible de libérer les adresses ips tout en gardant dans la +base de donnée les adresses mac des machines (avant, il fallait absoluement +supprimer +la machine pour libérer le mid et l'ip associé) + +Il est proposé de garder une plage de mid libre de 1 à 4096 par exemple pour les +machines crans (serveurs, adm, bornes wifi, …) +puis de commencer à utiliser de façon continue les mid à partir de là. + +### Documentation des scripts + +Olivier a commencé à ajouter une documentation sphinx au nouveau binding LDAP. +Reste la question du serveur web. +Il pourait être bien de remplacer l'apache de niomniom par nginx ; à des fins de +test, on pourrait faire tourner nginx sur un autre port en parallèle d'apache, +le temps de porter la configuration d'apache sous nginx. + +### Recâblage du PdJ + +Le switch est arrivé. +C'est fait, modulo utilisation du gbic intégré: il nous faut plus de jarretières +optiques (brassage <-> gbic). +Le plan de câblage sera prochainement mis à jour. + +### Routage du WiFi + +On a commencé à vider gordon de ses services : eap pour l'auth wpa2 et +routage direct via komaz (résout les prob liés au routage) +log direct via thot, dns sur les serveurs du vlan adhérent. + +### Démission du RTC + +Olivier déménage et démissionne de son poste de RTC. Valentin prend la +succession. + +## Question Diverses + +### Séparation des dns récursif et autoritaires + +Valentin est en train de faire la configuration adéquate. +De plus, la déléguation du reverse dns des ips allouées au crans par l'ens n'est +propagée correctement. En effet sur les 4 NS parent, un seul d'entre eux +(ariane.ens-cachant.fr) délègue les plages vers les NS du crans. + +### Incident Matinal + +Suite sans doute à un incident de communication entre fz et la baie de disque, +les domu présents sur icelui n'ont plus été en mesure d'assurer leurs services +respectifs. Vert étant parmis eux, cela a affecté l'ensemble des serveurs du +crans. +Les domu ont été migrés vers fy. Komaz, zamok, sable,… ont été redémarrés. + +### Augmentation du débit le week-end + +Cf mail sur dsi-crans puis Nounou, la DSI est d'accord pour accorder une +augmentation du débit le week-end à 500Mbit/s. Cette augmentation sera valable +du vendredi 20h30 au lundi 6h00. + +* le mail disait 20h. -- ZeldAurore <> diff --git a/compte_rendus/2013_02_07.md b/compte_rendus/2013_02_07.md new file mode 100644 index 0000000..4d901c8 --- /dev/null +++ b/compte_rendus/2013_02_07.md @@ -0,0 +1,148 @@ +# Réunion du Collège Technique + +* Date : Jeudi 7 Février +* Lieu : devant le Condorcet +* Début : 20h08 +* Fin : 22h25 + +## Présents + +* Ariane Soret +* Daniel Stan +* Pierre-Elliott Bécue +* Sylvain Boilard +* Valentin Samir +* Vincent Guiraud + +## Ordre du jour + +### Mac/Prise + +Pierre-Elliott a continué à coder mac-prise en utilisant une base postgres. +Il compte le nombre de mac pour une chambre donnée sur plusieurs intervalles +(2 min, 30 min, 1 jour). Il y a plusieurs heuristiques qui donnent des +valeurs différentes ("très suspect", "suspect") plus ou moins fonction du +nombre de fois qu'une même mac apparaît dans le réseau et du nombre de mac +apparaissant sur une prise et du temps. + +Il est suggéré de ne pas tenir compte des macs inconnues qui pourraient être +récupérée (mac virtuelle, jamais enregistrées), si le script devient trop +verbeux. + +Pour l'instant, il est en test sur une ml du même nom, et sera mis en prod +après quelques réglages. + +Le script effectue de nombreux appel à ldap, il est donc envisagé de mettre un +réplicat sur thot. + +### Passage à Git + +Le dépôt /usr/scripts est migré. (il ne faut plus record sur darcs) +Il faut supprimer les mail de darcs whatnews et avoir avoir un équivalent pour +git. +Le dépot bare se trouve sur git.crans.org qui est public, il faudrait vérifier +qu'il n'y a pas de mot de passe recordé dedans au cas où (grep). + +On peut migrer bcfg2 n'importe quand. Il faut finir de tout recorder avant. + +Il reste à trouver un joli hook pour les mails (genre modifs non +commitées/pushées) +voire une vérif d'intégrité : vérifier que le dépot bare et de prod aient la +même HEAD. + +### WiFi + +#### Ipv6 + +On annonce un slash ipv6 en wifi, ça marche. (Parce que Daniel a une machine +ipv6 only chez lui) + +#### Freecwmp + +freecwmp, implémentation du protocole CWMP pour openwrt destiné à contrôler à +distance des équipement divers, dont nos bornes wifi. +Trois élèves du département informatique ont travaillé sur un projet autour de +ce protocole, et se disent qu'il serait pratique de l'utiliser pour configurer +nos bornes avec et de garder le moins de configuration possible dans la branche +openwrt du crans afin de faciliter son maintien. + +Le serveur de configuration est actuellement en cours d'écriture comme une +application django. + +#### Arpej' + +Arpej (aka résidence Volti) est une résidence privée mitoyenne au campus où de +nombreux élèves de l'ENS logent. +Elsa Perdrix à rappelé qu'il y avait eu autrefois un projet de faire un pont +wifi pour relier le bâtiment au réseau. +Il y a normalement encore une borne sur le toit du d'Alembert pour ça. Quand à +celle de l'Arpej'… + +Daniel fait remarquer que cela ajoute une charge de travail supplémentaire sur +les membres actifs et que la viabilité à long terme d'un pont wifi est +incertaine. + +Il faudrait voir à nouveau avec l'ENS s'il existe un tunnel jusqu'à +l'Arpej' pour +tirer une fibre. + +#### Pdj + +La dsi aimerait bien qu'on diffuse eduroam au PDJ pour les chercheur visiteur. +Pour ça il faut des bornes : + +* Combien ? +* On les mets où ? + +Il faut faire des tests de couverture, faire un dossier et demander un budget +au CA. +Pour mettre des bornes dans les faux plafonds il faut l'accord de la DGS. + +On essaiera de faire les tests ce week-end. + +### Firewall + +#### Comptage Upload + +Il faut adapter le comptage d'upload à l'ipv6 pour pouvoir compter par mac, et +éventuellement faire évoluer la déconnexion. +Actuellement il y a un petit programme qui rempli une table d'association +mac-ip, il est envisageable d'effectuer une jointure. + +Un autre problème est que pour compter directement par mac, il faudrait compter +sur l'interface interieure, et qu'alors, on comptera également du traffic +potentiellement rejeté par le firewall. + +#### Filtrage p2p + +le filtrage p2p devient **vraiment** obsolète, avec de plus en plus de faux +positif, +Valentin voudrait s'en débarrasser. +Il faut demander à la dsi si on peut le jetter. +Le problème est l'adhérent faisant du piratage : C'est la dsi qui reçoit les +lettres des ayant droits et cela pose un problème de réputation de l'École. + +Il est envisageable de continuer de bloquer ce que l'on détecte mais de ne plus +déconnecter les gens. + +/!\ Il faut discuter de ce point au prochain CA + +#### Déconnection pour upload + +Actuellement les adhérents dépassant 4Go/24h de téléchargement se font +déconnecter pour 24h. +Il est proposé de juste brider la vitesse de ceux dépassant la limite. + +Il faut définir à quel point. +On peut penser les mettre derrière la freebox puisqu'elle ne sert plus à rien +en temps normal + +/!\ Il faut discuter de ce point au prochain CA + +### Réunion DSI + +* Réverse dns +* filtrage p2p +* upload +* eduroam au Pdj : mdp du serveur radius, voir comment on fait… +* null route sur le /16 diff --git a/compte_rendus/2013_03_07.md b/compte_rendus/2013_03_07.md new file mode 100644 index 0000000..ec5acc6 --- /dev/null +++ b/compte_rendus/2013_03_07.md @@ -0,0 +1,128 @@ +# Réunion Nounous + +* Date : Jeudi 7 mars 2013 +* Lieu : Condorcet +* Début : 19h42 +* Fin : 21h42 + +## Présents + +* Ariane Soret +* Daniel Stan +* Olivier Iffrig +* Sylvain Boilard +* Valentin Samir +* Vincent Le Gallic + +## Ordre du jour + +### Réunion DSI + +Valentin et Daniel sont passés voir la DSI la semaine dernière (suite à la +découverte par Sabrina d'une borne wifi). +Les gens du Léonard de Vinci veulent du wifi, elle voulait donc voir si on +pouvait remettre les anciennes bornes, ou même des nouvelles. +On leur a d'ailleurs prêté le lendemain une pico pour leur montrer à quoi elles +ressemblent. + +La DSI veut à terme pouvoir jeter les wifi ouvert et ne laisser que eduroam. +Puis utiliser un outils comme !PacketFence pour effectuer de la délégation vers +les labo/dpt pour les autorisations d'accès. + +Nous avons été invités à la réunion des DSI des divers département du lendemain. +Parmi les points évoqués, le fait de scanner le home des adhérents à la +recherche de virus semble une bonne idée. + +### Documentation + +Il ''FAUT'' mettre à jour les lien vers les pages wiki déplacées. Une idée des +pages concernées peut s'obtenir à l'aide du listing des pages +orphelines : +Le plus simple étant d'effectuer une recherche sur le nom de l'ancienne page et +de modifier les résultats trouvés. + +Une restructuration du Wiki a été entamée par Pauline, il reste aussi à +documenter de nombreux services. +Avis aux nounous (et apprentis) ayant installé un de ces services non +documentés. + +Côté doc Sphinx : il faut l'utiliser, documenter ce qui ne l'est pas. (make +coverage, make html). +par exemple, la liste des objets non documenté +dans {{{lc_ldap}}} : + +### Instabilité de la connexion + +Des problèmes de connexions de faible durée ont eu lieu la semaine dernière. +Rien à signaler sur le réseau du Cr@ns, +cela vient vraisemblablement du lien Renater, cf + + +### Résidence Jacques Restignat + +Ariane a rappelé le gérant de la résidence aujourd'hui. Il n'a pas encore +acheté de borne WiFi (il pensait le faire lui-même). +Un devis a été demandé chez Orange. + +La question de la connexion à Internet elle-même n'a pas été rediscutée mais +doit être étudiée. + +### CAS + +Il reste à synchroniser les comptes Wiki et LDAP (la gestion sur l'intranet est +OK) pour pouvoir mettre le CAS sur le Wiki. +Les webmail SOGo et Horde restent aussi à faire (la DSI nous a conseillé pour +SOGo). + +### Logs Ldap / generate + +Il devient de plus en plus urgent de journaliser les modifications effectuées +via le nouveau binding lc_ldap. +On pensait utiliser olcAccess avec un attribut last_modifier sur chaque objet +pour savoir qui a fait la modification. Ainsi, on +peut utiliser une connexion cn=admin tout en maintenant une trace des auteurs +des modifications. + +Il serait alors possible de lire la base de log pour generate (en se souvenant +de l'endroit où on s'était arrêté). + +Il faudrait également revoir le système de lock qui actuellement entre en +conflit avec un certain nombre d'exécution +automatique de scripts. En effet, le système actuel semble être ennuyant pour +les utilisateurs, et peu efficace pour la +sûreté des scripts (un objet locké provoque un arrêt complet du script, pour +exception non rattrapée même dans un cron). +On pourrait utiliser un système plus souple de vérification, au moment de la +modification, si une modification a eu lieu depuis la lecture de +l'objet. + +### Migration vers git + +Les dépôts bcfg2 et usr-scripts sont passés sur git. Les hooks de notification +irc et mails sont fonctionnels. +Il faut migrer les dépôts usr-scripts des serveurs n'ayant pas de NFS (ovh et +les dom0). +Il reste également à passer les dépôts des /etc/ des serveurs sous git. Ceci +permettrait de gérer les permissions sur les fichiers. + +La question est de savoir si ces dépôts sont considérés privés ou si on évite +de mettre des mots de passes sensibles dedans. +On peut aussi, quitte à éviter les mots de passes en clair, abandonner le +versionnement des /etc/ et utiliser uniquement +la génération des configurations via bcfg2. + +### Solution de partage de fichiers + +Le BDE et les associations partenaires ont demandé un espace de travail pour le +groupe de travail sur la convention de vie étudiante. +Il n'ont pas de cahier des charges précis, on peut leur proposer : + +* Un wiki sur une page perso club (Aurore MM. est en train de voir ce qu'elle + peut tirer de !DokuWiki) +* Etherpad +* [SparkleShare](http://sparkleshare.org/) + +### SPAM + +On se fait plus spammer qu'avant. +Il a été émis l'idée que le greylisting pourrait chier dans la colle. À voir. diff --git a/compte_rendus/2013_04_04.md b/compte_rendus/2013_04_04.md new file mode 100644 index 0000000..0f56453 --- /dev/null +++ b/compte_rendus/2013_04_04.md @@ -0,0 +1,233 @@ +# 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. diff --git a/compte_rendus/2013_04_18.md b/compte_rendus/2013_04_18.md new file mode 100644 index 0000000..667365a --- /dev/null +++ b/compte_rendus/2013_04_18.md @@ -0,0 +1,152 @@ +# Réunion Nounous + +* Date : 18 Avril 2013 +* Lieu : Condorcet +* Début : 19h22 +* Fin : 21h21 + +## Présents + +* Ariane Soret +* Daniel Stan +* Lucas Serrano +* Valentin Samir +* Pierre-Elliott Becue +* Raphaël-David Lasseri +* Thomas Épalle +* Vincent Le Gallic + +## Ordre du jour + +### Serveurs Free + +Il sont au 2B, il y en a 2, des 1U avec des kits de rackages. +Ils sont neufs. + +* L'un va être utilisé pour remplacer le serveur NFS actuel. +* On va essayer de tester la carte TV dans l'autre, mais à priori, il n'y a pas + assez de port PCIe dedans pour que ça soit intéressant. Il pourrait également + être utilisé pour proposer des VM aux clubs. + +Il est marqué dans le contrat de mettre sur le [site](http://www.crans.org) un +logo de la Fondation Free. + +### Intranet 2 + +#### Gestion des prises / Chambres + +Valentin a commencé à développer un module pour l'intranet2, pour les accès +prises/chambres. +L'idée est de n'autoriser une machine à se connecter que dans une liste de +chambres fournie par l'adhérent sur l'intranet. +Il reste à l'interfacer avec radius, et à voir s'il est actif par défaut. +Il est envisageable de tout préparer techniquement puis d'envoyer un mail à +tous les adhérents pour les prévenir d'une date d'activation. +Pierre-Elliott soulève qu'il ne lui semble pas acceptable d'imposer à ceux +souhaitant accéder en filaire à Internet depuis une autre chambre que la leur +d'avoir un compte Crans. +Il est rappelé qu'il est également possible d'utiliser de +l’authentification 802.1x. !MiNet l'utilise et ne semble pas rencontrer de +problèmes particulier On le leur demandera ce week-end. +La liste des chambres autorisées est actuellement dans la base pgsql switch. +Pierre-Elliott à suggéré de rajouter un champ ldap +multivalué {{{PriseAutorisee}}} par exemple. Cela à l'avantage de garder autant +que faire se peut les données des adhérents dans une seule base de donnée et +facilite ainsi sa gestion. + +#### Migration + +Il faut migrer vers l'intranet2 le plus rapidement +possible : l'intranet 1 devient de plus en plus obsolète. Par exemple, il ne +fonctionne pas sous IE10 (ce qui empêche les adhérents d'enregistrer eux même +un nouveau PC sous Windows 8 qu'ils viennent d'acheter) +Valentin a commencé à "copier" le module «Mes machines», il manque la création +des machines (a priori possible avec le nouveau binding) et la suppression (pas +encore implémenté dans le binding) +Il manque un module pour imprimer, pour recharger son compte impression via +paypal et pour gérer ses infos personnelles (monCompte) en ce qui concerne les +adhérents lambda. +Pierre-Elliott soulève qu'il ne lui semble pas acceptable de donner des +commissions à une entreprise à chaque rechargement de compte impression et +propose de supprimer (ou trouver une alternative à) la fonctionnalité. +Les autres modules (digicodes, gestion des factures) doivent également migrer, +mais comme cela ne concerne actuellement que les membre actifs, c'est un peu +moins urgent. +Daniel propose la mise en place d'une base pgsql pour la gestion des digicodes. + +### Binding Ldap + +Tous type d'objets est créable et modifiable (sauf l'objet facture). + +#### Suppression + +Il reste à implémenter la suppression : notamment la +fonction "cimetière" permettant d'annuler une suppression en dumpant les donnée +depuis la base de donnée vers un autre support. +Actuellement (dans l'ancien binding) c'est un pickle de +l'objet {{{python}}} correspondant écrit dans un fichier +dans {{{/home/cimetiere/}}}. +Il est envisagé de stocker une représentation plus lisible du ldif ldap +correspondant (ini, json, …), sans doute dans un fichier. + +#### Logs et historique + +Pour les logs : accesslog + champ lastmodify pour savoir qui à fait la +modification : La base ldap log elle même toutes les modifications. +Pour l'historique : accesslog à l'air compliqué à parser du coup peut être +garder le système actuel ou bien faire une base d'historique à coté. +Le système actuel à l'inconvénient de faire grandir arbitrairement la taille +d'un adhérent/d'une machine dans la base ldap ce qui alourdit sa manipulation +via le binding. +De plus, une fois l'objet détruit (par exemple, un adhérent détruit sa machine +via l'intranet) son historique est détruit dans la foulée alors qu'on pourrait +souhaiter le conserver. + +#### Possibilité de préinscription ? + +Avec des ordinateurs en libre service à la rentrée, ça irait peut être plus +vite ? +C'est faisable, mais est-ce que ça aurait vraiment un intérêt réel ? + +### Passage à wheezy des serveurs mails + +Pour se débarrasser des spams, postfix s'est doté d'un nouveau +module : postscreen. Il n'est pas disponible sous squeeze, et de toute façon, +wheezy approche de la release. +Pierre-Elliott propose de les mettre à jour au 2B avec des apprentis après +avoir envoyer un mail aux adhérents concerné pour les prévenir de l'instabilité +du service mail durant la mise à jour. + +### Routes sur titanic + +Bah on ne peut pas parler à freebox en zone crans et on ne peut pas parler à +titanic hors zone crans. +Au vu des règles de routage, c'est normal. +Il est possible de faire en sorte que ça marche via des {{{ip rules}}}, mais ça +n'est pas vraiment important. + +### Pare-feu, limitation upload + +C'est en place, toutes les déconnexions pour upload sont dans une classe +où l'upload est limité. +Il faut remettre au propre l'échelle des sanctions en cas d'abus. + +### Zone crans et wiki + +Le kludge actuel ne semble plus fonctionner. A priori, il est possible +d'obtenir le même résultat proprement en écrivant un module d'authentification +Moinmoin +Vincent veut bien jeter un oeil. Lucas aussi. + +### Install Party, mise en ligne des vidéo + +Les fichiers audios des confs sont sur le site de l'install +party (mp3 mono 32kbps). +Qu'est ce qu'on fait avec les vidéos ? +L'idée était de faire un gros carré avec les slides, un petit avec la vidéo et +le son. + +### Une machine pour les apprentis + +Le domu pour les apprentis a été créé. +Une formation pour se connecter au serveur est donnée en direct par Valentin. diff --git a/compte_rendus/2013_05_02.md b/compte_rendus/2013_05_02.md new file mode 100644 index 0000000..dd19b36 --- /dev/null +++ b/compte_rendus/2013_05_02.md @@ -0,0 +1,133 @@ +# Réunion Nounous + +* Date : Jeudi 2 mai 2013 +* Lieu : Pavillon des Jardins +* Début : 19h21 +* Fin : 20h40 + +## Présents + +* Lucas Serrano +* Nicolas Dandrimont +* Pauline Pommeret +* Pierre-Elliott Bécue +* Valentin Samir +* Vincent Le Gallic + +## Ordre du jour + +### Changement de NFS + +Le serveur NFS a été changé. Pour une raison +encore +obscure, le nfsv4 était actif alors qu'il n'aurait pas dû l'être, ce qui a créé +un certain nombre de bugs, dont des problèmes de permissions dans les homes. + +Il fallait +modifier {{{/etc/default/nfs-kernel-server}}} sur zbee pour désactiver +le protocole v4. C'est maintenant fait. + +Sinon, on me souffle dans l'oreillette +que charybde a un NFS pour PXE. Donc +au dist-upgrade, il faudra faire attention. +Babar a également un +serveur NFS pour exporter les photos des +caméras (qui ne +marchent plus). + +### Virtualisation + +#### Proxmox + +Suite à la réunion avec MiNET, Pierre-Elliott a testé Proxmox, +sur kdell. + +Son interfaçage avec la baie de disque n'est pas compatible avec l'utilisation +faite actuellement au Cr@ns. + +Pierre-Elliott fait remarque que changer l'architecture demanderait alors +beaucoup de temps pour assez peu de résultat. En effet, il faudrait revoir +complètement la gestion des disques des machines virtuelles : actuellement elles +montent des disques (virtuels) entier, il faudrait plutôt qu'elles montent des +partitions. + +Ce dernier point serait de toute façon une bonne chose et résoudrait sans +doutes les quelques problèmes de migration que l'on rencontre. + +#### Virtualisation pour les clubs + +À terme, une fois les tests terminés, il faudra décider si on offre un service +de virtualisation pour les clubs. +Valentin fait remarquer que l'avantage d'avoir une solution compatible avec la +virtualisation actuelle permettrait de pouvoir migrer des machines virtuelles +vers kdell en cas de problèmes sur un +autre dom0. + +### Câblage de personnel CROUS + +cf ../Jeudi25Avril2013 + +### Dist-upgrades + +La release c'est (après) demain. +Tous les membres actifs sont invités à lire +les [release notes](http://www.debian.org/releases/wheezy/amd64/release-notes/index.fr.html) +et la page CransTechnique/AdminSystème/DistUpgrade (potentiellement à +compléter). + +Il faut planifier les mise à jour des machines entrainant une interruption de +service et prévenir à l'avance sur CransIncidents et sur les news. + +Parmi celles-ci : + +* komaz +* redisdead +* radius +* dhcp +* xmpp (super important !!1) +* zamok + +zamok sera mis à jour lundi 6 mai +en même temps qu'on réparera le home des +adhérents. (envoi de mail ce soir) + +Les mise à jour sont programmées à partir du week-end du 18-19 mai pour avoir +des apprentis disponibles. + +### Ajout de droits + +Sur proposition de Vincent, les droits nounou ont été attribués à Lucas Serrano +et Pauline Pommeret. + +Valentin fait la partie chiante où il faut taper son mot de passe {{{sudo}}}. + +### Divers + +#### Caméras + +Il faut diagnostiquer pourquoi celle du 2B fait des histoires pour prendre des +photos et les envoyer sur [[CransTechnique/LesServeurs/ServeurBabar|babar]]. +Idem celle du 0B envoie des mails de manière aléatoire, il faut voir si ça n'est +pas juste un problème de configuration. + +#### Alimentation et KVM + +Le CA a donné son accord sur le principe pour l'achat d'une alimentation +rackable, et +pour celui d'un KVM. Il faudrait avant cela tester un clavier. + +Pierre-Elliott se charge du KVM. Valentin s'occupe de l'alimentation, et des +« petits consommables » (têtes RJ45 & co). + +Nicolas dit qu'il a croisé une alimentation similaire à pika et chu, elle doit +se trouver dans un des locaux techniques. + +#### autoconf wifi + +Valentin a nettoyé le code de son script. Les sources et le script pour +cross-compiler se trouvent dans {{{/usr/scripts/src/autoconf-wifi}}}. + +L'exécutable servi pour Windows est signé, avec la commande décrite dans +la source. Ce n'est pas absolument nécessaire de faire ça. + +Attention, le fichier est symlinké depuis le serveur {{{ftp}}}. diff --git a/compte_rendus/2013_05_16.md b/compte_rendus/2013_05_16.md new file mode 100644 index 0000000..6034fd8 --- /dev/null +++ b/compte_rendus/2013_05_16.md @@ -0,0 +1,141 @@ +# Réunion Nounous + +* Date : Jeudi 16 mai 2013 +* Lieu : Pavillon des Jardins +* Début : 19h32 +* Fin : 21h30 + +## Présents + +* Daniel Stan +* Raphaël Cauderlier +* Vincent Le Gallic +* Lucas Serrano +* Valentin Samir +* Pierre-Elliott Bécue +* Ariane Soret + +## Ordre du jour + +### Avancement binding LDAP + +Valentin affirme que le nouveau binding fonctionne, id est il est possible de : + +* créer des objets +* modifier des objets +* supprimer des objets (avec un cimetière) +* ressusciter des objets depuis le cimetière +* programmation des services à reconfigurer + * Il faudrait peut-être revoir le système des arguments passés aux services + +à redémarrer, celui actuel ne permettant pas beaucoup de flexibilité. +Il manque : + +* Une gestion des accès concurrents +* Les logs (support partiel de l'ancienne méthode via l'attribut historique) + +Penser à migrer les scripts qu'on veut garder de l'ancien binding vers le +nouveau. + +Vincent a séparé les objets ldap du binding dans un autre fichier. +Ajouté un module shortcuts pour se binder en admin, readonly, autre, …. + +Le fait que le package, le module principal et la classe du binding portent le +même +nom est problématique. Il faudrait penser à un renommage. + +Vincent s'occupera du renommage, Pierre-Elliott de l'accès concurrent. + +### Avancement Intranet2 + +L'application "Mes Machines" sur le nouvel intranet est en production et est +utilisé. (L'ancien commençait à avoir du mal sur les nouveaux navigateurs.) + +L'association compte Cr@ns<->WikiNom a quelques problèmes d'encodage (cf mail) +Il reste à réaliser un outil de création de compte Wiki (pour compenser le +script qui ne marche pas sur zamok). + +Dans les applications à migrer rapidement : une application "mon compte" et +une application d'impression (lancement) et le rechargement de solde via paypal +et note Kfet. + +Il pourrait être bien de migrer la gestion des digicodes en les stockant +dans une base de donnée (au lieu de créer un fichier dans +/usr/scripts/var/digicode) avis aux apprentis ! + +### Serveur TV + +La carte 4 tuners a été testée dans le pc d'un membre actif. +Ça fait 20 jours que ça marche. + +Il faut acheter au moins une deuxième carte pour couvrir tous les multiplex et +une tour avec suffisamment de PCIe (au moins 4) et de ventilo pour refroidir +les cartes. +(faire un panier sur un site de vente en ligne). + +Valentin s'en occupe. + +Il faudrait réfléchir à rationaliser également le satellite. + +### CAS + +Le wiki a été (partiellement) CASsifié. + +Il reste sogo, horde et nagios. +Il faut installer pam_cas sur le serveur imap pour cela (Argh). + +### WiFi + +Il reste des choses à faire ! Prochaine séance de pose de bornes ? :) + +Il faut acheter les bornes de test (Daniel se charge de faire le panier) dont +le budget +a été voté au précédent CA. + +Il faudrait compter le nombre de bornes à acheter pour compléter la couverture +(PdJ, RdC H I J) (possiblement avec les fat max 100 clients). + +Il faut poser les bornes au G, C, A, B. + +Daniel propose de faire une séance ce week-end pour wifier le bâtiment C. +On se retrouve samedi après le petit dèj (début 14h). + +### Mise a jour des serveurs + +* komaz : 25/05/2013 +* sable : 2{5,6}/05/2013 +* vert : 01/06/2013 (penser à couper 1 réplicat pour avoir un backup) +* charybde : 01/06/2013 +* gordon -> à transformer en domu +* news : 15/06/2013 +* niomniom : 15/06/2013 +* titanic : 22/06/2013 +* dhcp : 22/06/2013 +* eap : juillet +* irc : juillet +* redisdead : juillet +* ovh : juillet +* owl : juillet +* sogo : en même temps que owl + +### Adhérent au M qui spoofe + +Un adhérent a spoofé l'ip de zamok. Il prétend ne pas être au courant, +il semble qu'il l'ait fait involontairement. Comme il a une freebox, il a +été déconnecté au niveau du Crans. + +!ToDoList.append("déconnecter automatiquement les prises où on voit une MAC +spoofant +une IP de serveur ?") + +### Flaw in linux kernel + +Hier un mail a été reçu parlant d'une faille découverte récemment. +Zamok y étant vulnérable, Pierre-Elliott lui a appliqué un patch. + +### D(r)ivers + +* On a reçu 3 écrans et des claviers. C'est cool. Daniel dit que certaines + +touches d'un clavier ne marchent pas. Il suffit de les renvoyer (les claviers, +pas les touches). diff --git a/compte_rendus/2013_05_30.md b/compte_rendus/2013_05_30.md new file mode 100644 index 0000000..81e6a4d --- /dev/null +++ b/compte_rendus/2013_05_30.md @@ -0,0 +1,105 @@ +# Réunion du Collège Technique + +* Date : Jeudi 30 Mai 2013 +* Lieu : Pavillon Des Jardins +* Début : 19h30 +* Fin : + +## Présents + +* Daniel Stan +* Lucas Serrano +* Pierre-Elliott Bécue +* Valentin Samir +* Vincent Le Gallic + +## Ordre du jour + +### TV + +Une nouvelle machine a été reçue et montée lundi, la seconde carte TV lui a été +adjointe +mercredi. +Elle diffuse toute la TNT sauf le dernier Multiplex que l'on ne capte +apparemment pas. +Pour l'instant ça marche bien ! (il est même probable que ça soit toujours le +cas demain) +Il faut prévoir un ménage du 4J, et renommer TNT_test en TNT. + +Il faudrait également passer la configuration de la TV dans bcfg2, avis à un +apprenti/ignorant motivé. + +Daniel demande s'il est possible de rajouter des cartes dans {{{cochon}}}, par +exemple, +le satellite. À priori c'est possible. + +### WiFi + +Daniel a commandé 12 Unifi et 2 nano M5. Ça devrait arriver d'ici lundi. Des +tests seront +à faire sur les bornes Unity, Daniel propose d'aider un curieux à comprendre +comment les +flasher, après avoir trouvé le firmware qui convient. + +### Mise à jour de serveurs + +#### Gordon + +Un nouveau DNS récursif a été mis en place, une machine virtuelle du nom +de {{{nem}}} sur +kdell. C'était une occasion de tester Proxmox sur de la prod. + +#### Dhcp de secours + +Une machine supplémentaire a été créée pour le dhcp, elle s'appelle {{{isc}}}, +et tourne sur +kdell. + +#### Futures mises à jour + +Il faudrait planifier les mises à jour de serveurs encore non listés. + +* eap : 2 juillet +* irc : 2 juillet +* redisdead : 2 juillet +* ovh : 2 juillet +* owl : 10 juillet +* sogo : 10 juillet +* xmpp : 10 juillet (à 14h, pour faire chier les vieux) +* asterisk : 10 juillet + +Au moins vert et charybde samedi matin, il faudrait faire du teasing, qu'un +apprenti (voire +plus, soyons fous) vienne. + +### Virtualisation + +Proxmox est installé sur kdell et sur vo, il faut s'assurer qu'il existe des +outils en +command line pour lancer les machines virtuelles, et éventuellement pour +accéder en console +à celles-ci. +Il faut documenter l'appli si on veut passer de xen à proxmox. Entres autres +pour la gestion +des disques. + +#### Ntp sous proxmox + +A l'air de fonctionner. + +### Évolution du nouveau binding + +Le nouveau binding est en « tout unicode » (enfin presque), et les locks sont à +peu près +en place. + +Une composante bijective a été extraite des dictionnaires rid, NETs, prefix de +config.py + +### Pénurie des ipv4 + +Un script a été pondu, il n'a pas encore éclos, il faudrait s'occuper de mettre +en place le +v6-only en parallèle. + +Il faudrait presser la DSI pour l'ipv6. diff --git a/compte_rendus/2013_06_13.md b/compte_rendus/2013_06_13.md new file mode 100644 index 0000000..f5766e3 --- /dev/null +++ b/compte_rendus/2013_06_13.md @@ -0,0 +1,87 @@ +# Réunion du Collège Technique + +* Date : Jeudi 13 Juin 2013 +* Lieu : Fonteneau ou Tocqueville +* Début : 19h18 +* Fin : 20h53 + +## Présents + +* Daniel Stan +* Lucas Serrano +* Raphaël Cauderlier +* Valentin Samir +* Vincent Le Gallic + +## Ordre du jour + +### Carte Satellite + +Elle est arrivé, elle est rouge dans son carton. + +Il faut l'installer relativement rapidement sachant qu'il n'y a plus de chaînes +satellite diffusées en ce moment. + +Histoire de faire les choses correctement, il faut écrire des règles udev pour +déterminiser l'ordre d'attribution interface <-> carte. + +Il serrait également interessant d'écrire un initscript permettant de n'agir +que sur une seule instance de mumudvb. + +### Climatisation 0B + +LTC est passé lundi matin, il a nettoyé l'évacuation à l'extérieur qui était +pleine de pigeon et de guano. Les résultats ne sont pas merveilleux. +Il faut les rappeler pour qu'ils repassent. + +Daniel se charge de les rappeler. + +### Notification d'infraction au copyright + +La DSI nous a transféré un mail (parmi plusieurs) à propos de violation de +copyright. +On a transmis aux adhérents concernés. Apparemment ça leur suffit pas. + +Pierre-Elliott écrit un mail pour la DSI explicitant que l'on n'y peut pas +grand chose. + +### Nouvelles bornes WiFi + +Une première borne du nouveau modèle (!UniFi) a été placée au B. + +Daniel a commencé à remplir des pages wiki sur la façon de les flasher. + +Bâtiments restants : G, C, A, PdJ. + +Appel aux apprentis pour flasher, poser, tirer des câbles. + +### CAS, déconnexion + +Maintenant, quand on clique sur "se déconnecter" on est globalement déconnecté +des services suivants : wiki, roundcube, webnews. + +Ce serait pas mal de l'implémenter pour les autres services. + +Un apprenti peut être encadré sur le sujet. + +Valentin se charge de rajouter +sur [[CransTechnique/ServicesMineurs/CentralAuthenticationService]] les paths +des différentes conf +(serveurside et clientside) + +### Mise à jour de serveurs + +News et Niomniom sont à mettre à jour samedi à partir de 9h30. +Appels aux apprentis disponibles. + +Valentin enverra un mail de rappel sur nounou@crans.org d'ici ce soir. + +Valentin propose une fois encore d'écrire un module d'autentification pour +gérer le hack de la zone Crans de MoinMoin. + +### Questions diverses + +#### Imprimante + +Un technicien est venu réparer l'imprimante. Jusque là, elle remarche. Elle +boure relativement souvent. Il faudra également recommander du papier. diff --git a/compte_rendus/2013_09_23.md b/compte_rendus/2013_09_23.md new file mode 100644 index 0000000..7458dc8 --- /dev/null +++ b/compte_rendus/2013_09_23.md @@ -0,0 +1,252 @@ +# Réunion du Collège Technique + +* Date : Lundi 23 septembre 2013 +* Lieu : Espace Condorcet +* Début : 19h25 +* Fin : 20h49 + +## Présents + +* Daniel Stan +* Florian Marconi +* Jean-Paul Giraud-Ferrandi +* Lucas Serrano +* Pierre-Elliott Bécue +* Raphaël-David Lasseri +* Valentin Samir +* Vincent Guiraud + +## Ordre du jour + +### Présentation + +On effectue rapidement un tour de table pour se présenter. +Pierre-Elliott rappelle les divers postes que peuvent occuper des membres +actifs et que l'investissement temporel est à géométrie variable. + +### Garantie renouvelée + +La garantie de {{{zamok}}} ayant expiré, le C.A. a voté durant l'été par email +le +renouvellement de la garantie, qui a été appliqué. + +Vincent recevra la facture. + +L'extension de garantie court jusqu'au 03/09/2014. + +### Politique sur les infractions au copyright + +Problème réglé : en gros, la DSI nous envoie des mails de la part d'ayants +droit mentionnant des IPs Crans. + +La politique a donc été définie en accord avec la DSI : on ne sanctionne pas +les adhérents, on transmet les mails que l'on reçoit aux adhérents. +Si des demandes d'ayants droit deviennent insistantes, les rediriger vers les +instances compétentes. + +### Politique sur les comptes compromis + +Il arrive que des comptes crans soit compromis, ''id est'' que les identifiants +du compte leakent. + +Outre les problèmes concernant la vie privée du propriétaire du compte, il a +été observé que des spambots envoyaient des milliers de mails via ces comptes. + +Pour ce qui est des spams, Pierre-Elliott propose une solution à partir +des "politiques" de postfix. +Cela est faisable en pas trop longtemps. Avis à des personnes motivées. + +Moralement, si un compte est compromis il faudrait complètement le +désactiver (via l'ajout d'un attribut LDAP), et pas uniquement bloquer l'envoi +de mail. +Un débat a lieu sur la meilleur manière de communiquer un nouveau mot de passe. + +Manières de contacter un adhérent dont le compte est compromis (et désactivé): + +* Physiquement à la Kfet +* Mail alternatif (attribut mailExt) +* Adresse postale (ne plus mettre de EXT sans adresse) +* Téléphone +* Au cas par cas (?) + +Pierre-Elliott modifiera la base LDAP pour l'attribut "compte désactivé", si +possible gérable via blacklist, ou un peu comme mail_invalide. + +### Gestion des certificats + +PEB a contacté !CaCert pour créer un compte à l'association pour gérer le +domaine {{{crans.org}}}. + +Le système de !CaCert repose sur un réseau de confiance : des gens "de +confiance" assurent d'autres gens, et ainsi de suite. +Il y a un système de points qui permet de donner plus ou moins de possibilités +aux gens plus ou moins assurés. + +Un compte organisation peut nommer des administrateurs (des assureurs) qui +pourront ensuite émettre des certificats pour le domaine. + +Actuellement, le domaine {{{crans.org}}} est enregistré sur le compte personnel +de Stéphane Glondu, ce qui oblige de passer systématiquement par lui pour les +renouvellement ou les nouveaux certificats. +Cela est devenu relativement pénible autant pour lui que pour nous. C'est +pourquoi Pierre-Elliott a entrepris les démarches pour ouvrir un compte +organisation au nom du Crans. + +### Migration vers proxmox + +Les machines virtuelles du Crans sont hébergées sous le virtualiseur Xen. +Il y a quelques problèmes lors de la migration de machines virtuelles entre +deux virtualiseurs. + +Pierre-Elliott a installé Proxmox sur {{{kdell}}} et sur {{{vo}}} pour tester, +et celui-ci a plus ou moins fait preuve de sans faute par rapport à nos +exigences. + +Proxmox, c'est un noyau Linux modifié pour virtualiser des machines sous kvm ou +OpenVZ. En sus, il y a une interface web kikoo. + +Globalement, Proxmox est plus adapté à nos besoins, Pierre-Elliott a testé la +migration des machines depuis XEN vers Proxmax, cela fonctionne, et est +documenté. +Un certain nombre de migrations ont été effectuées. + +Il faudrait effectuer les suivantes. L'idéal étant que des gens découvrent. + +### Déploiement du wifi + +Daniel a placé une borne wifi par étage au PDJ (au niveau du local technique). + +Il reste à tirer des câbles au niveau des faux plafonds. +Un étage sur deux une au milieu, pour les autres deux sur les côtés. + +Les bâtiments C, A, G et le PDJ restent à câbler. +Un des problème est le manque d'accessibilité aux locaux, notamment au C. +Il faut des gens motivés pour faire tout ça, c'est long et chiant, mais c'est +indispensable qu'on finisse cette année, ou du moins avant qu'on parte à Saclay. + +Dernier détail : le VLAN 3 n'est plus propagé dans les locaux de l'ENS, il +faudrait faire signe à la DSI pour essayer de comprendre pourquoi, après avoir +mené quelques tests. + +### Mails automatiques + +Valentin a commencé un peu de templating avec Jinja2, il faudrait remplir ces +mails dans les diverses langes qu'on pratique. + +Une fois cela fait, on pourrait songer à un champ LDAP pour demander aux +adhérents leur langue préférée. + +Il faut prolonger ce travail, et le rendre utilisable, si possible avant la +prochaine rentrée. Avis aux amateurs. + +### Point lc_ldap + +{{{lc_ldap}}} est presque fini, il faut juste s'occuper de ces histoires +d'historique, et des factures. + +On a aussi des erreurs, probablement dues aux locks, il faut investiguer pour +améliorer le système. +Globalement, les erreurs sont "!LockedByYou", ce qui tend à laisser croire que +dans un cas précis, quand on annule une modif, les locks ne sont pas levés. + +Pour l'historique, il s'agit de travailler avec {{{cn=log}}}, ce qui avait été +commencé par adg. +Sinon, le système d'historique (quitte à les mettre à côté ou en +sous-objet) actuel + {{{cn=log}}}, mais sans parsage. + +L'idéal serait quand même de travailler avec {{{cn=log}}}. Une alternative est +de créer un objet fils de chaque objet, qui contiendrait l'historique. + +Pour les factures, il faut juste écrire le code. + +### Divers intranet2 + +* Création de compte wiki (pour l'instant on ne sait que linker les comptes) +* Génération de {{{.procmailrc}}} (il s'agit de migrer l'appli de l'intranet1, + et de faire ce qui est proposé dans le tracker (règles de filtrage)) +* Gestion de !MonCompte (idem qu'au dessus) +* Gestion des factures (cf point {{{lc_ldap}}}) +* Digicode / Impression (ça avait été commencé, il faut juste finir, il s'agit + aussi de porter l'appli de l'intranet1) + +### Multicast : radio et satellite + +Valentin a ajouté des chaînes de radio via http sur l'offre TV, qui semble +fonctionner. + +Il y a un comportement anormal des switches qui fait qu'en cas de poll pour +trouver des abonnés, +les réponses ne reviennent pas toujours à cochon malgré son statut de routeur +multicast. + +Il y a normalement des chaînes de radio sur le satellites mais {{{mumudvb}}} ne +veut pas les diffuser. + +Il y a une interface web pour la télévision sur +. + +### VLAN dynamiques en wifi + +Daniel a travaillé sur le basculement dynamique en wifi entre les +VLANs. (accueil & co) + +Sur le filaire, c'est déjà fait, les switches interrogent radius pour choisir +le VLAN sur lequel placer les machines. +En wifi, c'était un peu plus compliqué. Mais à la suite de divers tests et +flashages de bornes, il a trouvé quelque chose qui fonctionne. + +Il faut donc modifier les confs radius sur {{{eap}}} et {{{pea}}} pour mettre +ça en prod après avoir flashé les bornes avec la nouvelle !OpenWRT. + +On prévoit également de mettre en place le failover pour {{{eap}}} et {{{pea}}}. + +Bref, ça marche, il faut des apprentis motivés pour apprendre tout ça et +implémenter le truc. (soyons consensuels). Raphaël-David a déjà commence, mais +il veut des coupaings. + +### Point cranspassword + +Vincent étant absent, on se limitera aux remarques de Daniel. +Il faut s'assurer que les clefs GPG des gens sont toujours à jour, et non +expirées. + +* Ouais, j'étais pas là, my bad. + +. Pour ce qui est des détails techniques d'un point de vue {{{git}}}, il faut +soit se placer sur la branche {{{0.1}}} et ne plus se soucier de rien (le +serveur sur {{{vert}}} est en {{{0.1}}}), soit rester sur {{{master}}} mais +être prêt à puller les mises à jour quand il y en a. Le serveur +sur {{{ovh}}} est sur {{{master}}} (mais en readonly) +. Pour le faire marcher, on peut maintenant utiliser le +Makefile (sur {{{master}}}). {{{make install}}} pour installer le client. Ça a +pour effet de : + +* mettre de la conf dans {{{~/.config/cranspasswords}}} +* installer le script {{{cranspasswords}}} dans {{{~/bin}}}, qu'il faut donc + avoir dans son {{{$PATH}}} + +. La vérification de confiance et d'expiration des clés est implémentée, et il +propose même d'ignorer une clé au moment où on chiffre si elle pose problème. +. J'oublie ptêt des trucs, mais normalement la doc +est [[CransTechnique/ScriptsCrans/CransPasswords|là]] -- [[Wiki20-100]] <> + +### Questions diverses + +#### Séminaires + +Date de début des séminaires ? +Le 1er ou le 8 octobre, à confirmer par email, et pensez à faire de la vraie +pub, parce que les séminaires, c'est le bien. + +Valentin voudrait qu'on commence GPG en octobre, ce qui est judicieux. + +Si cela convient aux intervenants, le premier mois sera donc "intro par +Valentin" -> "Unix par lolasd" -> "le shell par #Random" -> "Gépégé". + +#### Reconfiguration des switches + +Tous les switchs ont la nouvelle configuration faite par Daniel vendredi soir. + +#### Forum des assoces + +Daniel propose de tenir le stand, et veut de la compagnie. diff --git a/compte_rendus/2013_10_03.md b/compte_rendus/2013_10_03.md new file mode 100644 index 0000000..4ab7443 --- /dev/null +++ b/compte_rendus/2013_10_03.md @@ -0,0 +1,95 @@ +# Réunion du Collège Technique + +* Date : Jeudi 03 Octobre 2013 +* Lieu : Pavillon des Jardin +* Début : 19h07 +* Fin : 19h57 + +## Présents + +* Daniel Stan +* Lucas Serrano +* Pauline Pommeret +* Thomas Espitau +* Valentin Samir +* Vincent Le Gallic + +## Ordre du jour + +### Programmation WiFi + +Daniel veut fixer une date pour les bornes du C : il n'y a qu'a resertir les +câbles. +Il serait de bon ton de changer en même temps le switch du 5C (bac-4) sur lequel +sont branchées les bornes. + +On programme ça samedi en début d'après-midi (après le petit déjeuner). + +### Projecteur + +Pour la tenue de ses réunions hebdomadaires, le Crans aurait besoin d'un vidéo +projecteur. +Il serait aussi utile pour les petites conférences exceptionnelles. + +Le collège technique estime qu'une résolution supérieure ou égale à de l'HD +ready (1080x720) serait une bonne chose. + +Comme il s'agit d'un projecteur pour utiliser en environnement lumineux (pas +dans le noir pour regarder un film), il faut que sa luminosité soit suffisante. + +Il faut un contraste suffisant pour voir les couleur du fond de gobby. (Assez +violent à mon goût à avoir quand même). + +Avoir une connectique VGA et HDMI. + +Diode VS lampe : la première a une durée de vie bien plus grande (au +moins 10 fois plus) mais ''a priori'' une luminosité plus faible. +Daniel demande s'il faudrait également acheter un écran +portatif (entre 60 et 160€). + +### Système de paiement + +Actuellement l'adhésion se fait par année scolaire. +Valentin propose des (ré)adhésions par année glissante. +Cela permettra d'éviter les gros rushs de réadhésion à la rentrée. + +Vincent rappelle qu'il faut scripter l'envoi de mails. Valentin dit qu'il faut +ajouter un champ avec la date d'adhésion/réadhésion (et laisser un mois pour la +carte d'étudiant). + +Une fois implémentée, cette solution pourra être proposée au CA (et soumise à +validation). + +## Question diverses + +### Cranspasswords + +Vincent n'était pas là lors de la dernière internounou. +Il n'a pas grand chose à ajouter. + +* Pour ce qui est des détails techniques d'un point de vue {{{git}}}, il faut + soit se placer sur la branche {{{0.1}}} et ne plus se soucier de rien (le + serveur sur {{{vert}}} est en {{{0.1}}}), soit rester sur {{{master}}} mais + être prêt à ''puller'' les mises à jour quand il y en a. Le serveur + sur {{{ovh}}} est sur {{{master}}} (mais en readonly). + +. Pour le faire marcher, on peut maintenant utiliser le +Makefile (sur {{{master}}}). {{{make install}}} pour installer le client. Ça a +pour effet de : + +* mettre de la conf dans {{{~/.config/cranspasswords}}} +* installer le script {{{cranspasswords}}} dans {{{~/bin}}}, qu'il faut donc + avoir dans son {{{$PATH}}} + +. La vérification de confiance et d'expiration des clés est implémentée, et il +propose même d'ignorer une clé au moment où on chiffre si elle pose problème. + +### Matériel séminaire + +On se propose d'enregistrer et de filmer les séminaires. + +Pour cela, on demande un micro-cravate, Valentin en trouve 4 + récepteurs +à 200€, cela semble honnête (sonovente.com), en promotion. + +Une caméra serait également pratique, une discussion va être lancée sur +nounou@, il y a forcément quelqu'un de compétent (bref c'est remis à Plüthaar). diff --git a/compte_rendus/2013_10_17.md b/compte_rendus/2013_10_17.md new file mode 100644 index 0000000..f3911d7 --- /dev/null +++ b/compte_rendus/2013_10_17.md @@ -0,0 +1,193 @@ +# Réunion du Collège Technique + +* Date : Jeudi 17 octobre 2013 +* Lieu : Pavillon des Jardin +* Début : 19h15 +* Fin : 21h13 + +## Présents + +* Ariane Soret +* Daniel Stan +* Jordan Delorme +* Lucas Serrano +* Pierre-Elliott Bécue +* Raphaël-David Lasseri +* Théo Winterhalter +* Valentin Samir +* Vincent Le Gallic + +## Ordre du jour + +### Pont WiFi + +Lucas à mis en œuvre un pont wifi entre deux nano. +À la base, cela était pour relier l'Arpej (mais il n'y a plus personne). + +Ça marche. On a un débit asymétrique : + +* AP -> client : 40 Mbps +* client -> AP : 90 Mbps + +Un test de distance à été effectué entre le I et le J, cela semble concluant. Il +reste à tester sur une longue distance (de l'ordre 500m). +Une collocation sur la colline de Cachan est partante pour acheter une paire de +bornes et être raccordée au réseau si le test longue distance est concluant. +L'autre extrémité sera sur la terrasse du bâtiment C. + +{{{#!wiki caution +On notera qu'il ne faut pas bridger les interfaces des '''deux''' bornes +sur leur interface filaire. Ça fait une boucle. Le réseau aime pas ça. Du tout. + +Une note à ce sujet a été rajoutée sur une des deux bornes. +}}} + +### Policyd sur redisdead + +''Résumé des épisodes précédents : Il est arrivé plusieurs fois au cours des +derniers +mois qu'un mot de passe d'un compte Cr@ns soit compromis et qu'un botnet +l'utilise +pour envoyer du spam.'' + +Une limite de mail par minute par IP émettrice était déjà en place, mais les +botnet +deviennent intelligents, ils utilisent plusieurs IPs. +La dernière occurrence a eu lieu Vendredi dernier. + +Valentin a mis en place sur notre SMTP un plugin postfix (policyd, version clue +bringer) +qui permet de restreindre les politiques d'accès par utilisateur authentifié. + +La configuration est dans une base de données sur {{{thot}}}. +Pour la faire/modifier, il y a un joli +cliquodrome : , +l'authentification se fait par compte Cr@ns. +Les limitations de quotas mises en place sont : + +* 500 mails par utilisateur par 24h +* 1Go de données par utilisateur par 24h + +Policyd permet également de faire du greylisting. +La question de dropper postgreysql se pose, histoire d'avoir un seul daemon pour +faire les deux. + +### lc_ldap + +#### factures + +Valentin a fait en sorte que les factures soient utilisables avec {{{lc_ldap}}}. + +* objectClass=facture + * fid (identifiant unique) + * modePaiement (paypal, pour l'instant) + * article (qu'est-ce qui a été payé) + * recuPaiement (on décide de mettre AAAA-MM-JJ, correspondrait à cocher + paiement AAAA) + * historique (ce qui est arrivé dans cette facture au cours de l'histoire) + * ToDo : rajouter un champ pour + validation par le trésorier + +(cf controle+p) + +#### Comptes compromis + +Il faudrait rajouter un champ LDAP pour marquer un compte comme compromis et +vérifier +son absence dans ce qui utilise les comptes LDAP. +(envoi de mails, connexion à zamok, laisser l'intranet ?) + + + +#### Blackliste pour les gens qui ont pas payé + +Pour les adhérents n'ayant pas payé pour l'année en cours, une +pseudo-blackliste a été rajoutée. +Il n'y a donc pas besoin de vérifier qu'un adhérent a payé, juste qu'il n'a pas +de blackliste. + +Un des effets a été que les anciens adhérents (qui n'ont pas réadhéré) +pouvaient toujours se connecter à {{{zamok}}}, mais plus en sortir. +Valentin a patché pour rétablir la situation précédente. + +Pour l'instant, il n'y a pas eu d'abus constaté, on laisse ça comme ça. +Il sera toujours temps de revenir en arrière si on constate des abus. + +### Mail rappel carte étudiant + +Il faut l'envoyer. Ce serait bien d'écrire le template jinja +(cf {{{/usr/scripts/gestion/mail/}}}). +Pierre-Elliott et Raphaël-David se chargent de reprendre celui de l'année +précédente. + +Il pourrait être judicieux d'en profiter pour le croner. + +### Rappel env de dev sur vo + +Valentin rappelle qu'il y a un environnement de développement pour tester +le webnews et l'intranet sur {{{vo}}}. + +A priori, respbats a les droits d'écriture, les apprentis peuvent donc tester. +Ça permet de «tester en prod». Si "ça marche pas"™, frapper la nounou la plus +proche. + +Une fois les tests concluant, demander à une nounou de pusher. + +### Imprimante + +Lucas et Daniel ont tourné les feuille de π/2rad sans les bacs de l'imprimante. +Du +coup, deux modes d'agrafages ont été supprimé (sur le coté long, type sauce). +En résultat, l'imprimante ne bourre presque plus. + +Il serait bien qu'une alerte soit envoyée aux imprimeurs lorsque quelqu'un +lance une grosse impression. + +### Tunnel IPv6 + + +Il est possible a priori d'avoir la sortie du tunnel sur Paris (au lieu de +Marseille). +Valentin a constaté de meilleurs débits. + +Problème : il faut changer le set d'IP. + +La configuration a aussi l'air d'être plus facile à mettre en place. +Un tunnel de test a été mis en place sur {{{vo}}}. + +On pourrait également mettre un autre tunnel spécialement pour le miroir Debian. + +### Question diverses + +#### Bridage adhérent + +Daniel propose que, après les 24h de déconnexion pour upload, +les adhérents soient obligés de cliquer sur un liens envoyé dans le mail de +déconnexion pour être débridés. +Tout le monde est d'accord. + +On transmettra au CA. + +#### Vidéo aux 15 ans + +Ariane a à la main une caméra achetée chez Darty. +Pierre-Elliott s'occupe de faire en sorte de récupérer les flux slide, camera, +et probablement son régie sur son PC pour les mixer en direct. +De là, il sera probablement possible de proposer un streaming en direct. + +Il n'y a qu'une prise Ethernet au Villon, (dans le placard). Un câble sera tiré +jusqu'aux ateliers. + +#### Espace de stockage et FedeRez + +FedeRez a demandé plus de place sur {{{baldrick}}} pour que les serveurs +puissent +se backuper les uns les autres. +Leur allouer 50Go n'est pas un problème, mais soulève la question d'acheter des +disques +de 600Go pour remplacer les disques de 300Go de la baie des domU, pour faire de +la virtualisation +pour les clubs. + +Un devis a déjà été transmis au CA il y a un certain temps. +Il faudrait avoir son aval sur la question. diff --git a/compte_rendus/2013_10_31.md b/compte_rendus/2013_10_31.md new file mode 100644 index 0000000..f9f73e4 --- /dev/null +++ b/compte_rendus/2013_10_31.md @@ -0,0 +1,35 @@ +# Réunion du Collège Technique + +* Date : 31 Octobre 2013 +* Lieu : 2B +* Début : 19h10 +* Fin : 19h30 + +## Présents + +* Valentin Samir +* Lucas Serrano +* Pierre-Elliott Bécue + +## Ordre du jour + +### Pont Wifi + +Il relie le bâtiment B et une collocation rue des Vignes à Cachan (~600 m). +Très bonne synchro et très bon RTT. Les débits obtenus sont plutôt prometteurs +au vu des réglages précaires. +Valentin a regardé rapidement le tagging dynamique des vlans sur un bridge (par +exemple sur la borne du toit du B``) et n'a rien trouvé. Le plus simple serait +d'acheminer le vlan adh via ces bornes sans authentification radius. + +/!\ Nous avons emprunté le câble de la borne du 6B (Busiris) pour réaliser le +câblage du pont, il faudra donc retirer un câble pour cette borne. + +### Disque Dur Baie de Disque + +Le CA a prévalidé un ordre de grandeur de prix (entre 2500 et 3000€). On +demandera un devis à Anne, notre fournisseur, lors de son retour de vacances. + +### Questions Diverses + +Aucune. diff --git a/compte_rendus/2013_11_14.md b/compte_rendus/2013_11_14.md new file mode 100644 index 0000000..2829668 --- /dev/null +++ b/compte_rendus/2013_11_14.md @@ -0,0 +1,187 @@ +# Réunion du Collège Technique + +* Date : Jeudi 14 Novembre 2013 +* Lieu : Condorcet +* Début : 19h11 +* Fin : 21h20 + +## Présents + +* Daniel Stan +* Lucas Serrano +* Raphaël-David Lasseri +* Valentin Samir +* Vincent Le Gallic +* Pierre-Elliott Bécue + +## Ordre du jour + +### Wifi + +#### Pose de borne + +Des bornes wifi ont été placées aux étages 3, 4 et 5 du G, orientées vers +l'extérieur. Ça marche du tonnerre de Brest ! On a quasiment plus de câble, or +il nous reste des bâtiments à couvrir (A, PdJ, une partie du G) + +Initialement, une seule borne (!NanoM2Loco) était prévue par étage, avec les +nombreuses bornes de test, on s'est permis d'en placer deux par étage. +Pour couvrir le RDC, le 1er et le 2ème, il est nécessaire de rajouter deux +bornes +supplémentaires. + +Il faut faire les comptes de ce qu'il nous reste (Unifi + Pico), pour finir la +couverture prévue au A et PDJ, pour relancer une commande si nécessaire. + +On fait un devis pour le prochain CA pour des bobines de câbles et des bornes. + +#### Taggage dynamique + +L'idée est de placer les client wifi sur des VLANs différents au moment de +l'authentification. +Côté radius, un script python permet d'assigner un VLAN à chaque machine, en +fonction de différents critères (blacklist, présence d'ipv4). Ça marche. + +Coté borne, c'est correctement configuré sur OpenWRT et hostapd. À la connexion, +le client est bien placé sur la bonne interface. Mais un bug fait que de temps +en temps, pour certains clients (sur les réauthentifications par exemple), le +broadcast/multicast ne passe plus. Ce qui empêche les requête ARP, NPD et/ou +les RA de passer. +Sinon, ça marche. +Les images de bornes flashées en ce moment sont configurées pour. Pour l'activer +en production, il n'y a qu'à faire une modification coté serveur radius. + +#### VLAN radin + +Maintenant, c'est un vlan ipv6, il y a des RA et un nat64 qui marchent. Il faut +ajouter un comptage d'upload (qui comprend un log mac_ip) et un log de qui +contacte quoi quand. +Pour les logs, il faut soit envoyer le flux ailleurs pour stockage, soit +utiliser dyson (monitoring avec un mirroring de port) comme cela avait été +prévu initialement. + +### Imprimante + +#### Envoi de mails + +Lucas a fait un script qui envoie des mails quand l'imprimante est bourrée. +Le script est pour l'instant stateless, il faudrait lui ajouter une mémoire +pour qu'il ne spamme pas comme un cochon. + +#### Appli intranet2 + +Daniel a une appli pas finie pour l'intranet2, mais ça avance. L'idée était de +faire ça de manière modulaire pour avoir dans django la liste des impressions et +l'état actuel, et avoir l'historique via reversion qui conserverait les +états successifs. +Hélas reversion semble bugguer et ça pète les couilles de Daniel. +De plus, pour interfacer cela facilement avec tout, il a implémenté une file +de convergence : où on enfile les tâches à imprimer, et où les trucs qui +impriment viennent chercher leur document à imprimer. + +On pourait ajouter une étape intermédiaire à l'impression : la +compatibilisation : + +1. On upload un pdf +1. Il se compatibilise, on est notifié qu'il l'est +1. On lance l'impression depuis la liste des documents compatibilisés + +On peut penser à avoir un aperçu du document compatibilisé pour se rendre +compte que les vidéos, ça ne marche pas en pdf 1.2. + +#### Papier de l'imprimante + +Ariane, lors de la dernière commande de papier, a pris du papier blanc moins +cher. +Ça a l'air de marcher, du coup, ça pourrait être cool de le garder. +À noter qu'il serait moins blanc que l'ancien, mais en fait, on ne voit pas +vraiment la différence. + +#### «Mise à jour» du 4J + +La desserte pour ranger le papier au 4J a été installée, ça marche pas trop mal, +il y a un peu moins de papiers imprimés partout. + +Daniel et Valentin ont débarrassé le 4J des +vieilleries ({{{mdr}}}, {{{oie}}}, {{{canard}}}, vieilles batteries, etc). +On y a également migré tout un tas de livres qui étaient au 2B, du coup il y a +de la lecture au 4J pour ceux qui s'ennuient. + +Avant de se lancer dans la commande d'un canap, on va proposer au BdE de +récupérer deux des ex-sièges espace Condorcet. Ils feraient un bon test de +canapé, et pour l'instant, à la Kfet, ils sont en train de mourir à petit feu. + +### Sip + +On est passé de la version {{{svn}}} à la version packagée dans jessie (à coup +de +pinning). Ça marche mieux et on n'aura plus à recompiler à la main le tout à +chaque màj. + +Il y a une api (et une commande {{{sip_message}}} sur zamok) pour envoyer des +IM via python en appelant {{{/usr/scripts/sip/asterisk.py/Sms.send(dst, msg, +src)}}}. + +### Mails + +caca clueringer et ipv6 -> il FAUT un remplaçant peut être est-ce possible +avec anvil +Il semblerait que la version actuelle de policyd ait des problèmes avec l'ipv6, +qui vient d'être activée pour l'envoi sur smtp.crans.org. +Du coup, clubringer a été désactivé et il n'y a plus de limite du +nombre/quantité +de mails envoyés par utilisateur authentifié. Ça ne doit pas durer, donc soit +utiliser la version 2.1 de policyd qui a l'air de marcher, soit voir si c'est +possible avec anvil (à première vue, non). + +### Adaptateur USB-ethernet + +Le trendnet est bien. Il marche out of the box, il faut juste trouver une +solution pour mettre un éventuel driver à disposition pour les windows users. + +On choisit le modèle Trendnet TU2-ET100 Adaptateur USB 2.0 Ethernet 10/100. + +### Politique stockage des mots de passe des scripts + +On veux diviser secrets.py pour le rendre plus facilement utilisable et +modulable (droits d'accès différents) : + +* faire plein de petits fichiers +* laisser tout au même endroit et lancer un autre programme en faisant + sudo (avec un NOPASS) + +La solution à coup de sudo est préférée, au grand dam de Valentin. + +### Nouvelles déconnexions + +Deux nouvelles blacklist ont été mise en place : une pour carte invalide et une +pour paiement. '''Il ne faut plus mettre un bloq pour ces cas-là.''' + +On va également demander au C.A. s'il on peut arrêter de demander le certif de +scolarité/carte d'étudiant après la première adhésion. + +### Nom de domaines + +On se demande s'il ne serait pas bien que les noms de domaine genre +vo.crans.org fournissent l'ipv4 associée à la machine, mais aussi l'ipv6. + +Le problème de la saturation du lien se pose. Pour l'instant, il vaut mieux +pousser l'ENS à mettre en place l'ipv6. + +Si on le fait, il faudrait sans doute mettre en place le domaine .v4.crans.org, +analogue à .v6.crans.org. + +### Questions diverses + +#### Perms du jeudi + +La perm est trop souvent désertée le Jeudi soir lorsqu'il y a Internounou ou CA +(c'est-à-dire, souvent). On propose donc de passer les horaires de perm du Jeudi +à 18h-19h. + +Il faut soumettre ça au CA, et mettre à jour les affiches/wiki. + +#### Devis + +Xen vers proxox migration dur dur, achat serveur ? +Dyson weak weak, achat seveur ? diff --git a/compte_rendus/2013_11_28.md b/compte_rendus/2013_11_28.md new file mode 100644 index 0000000..03ba2b9 --- /dev/null +++ b/compte_rendus/2013_11_28.md @@ -0,0 +1,97 @@ +# Réunion du Collège Technique + +* Date : Jeudi 28 Novembre 2013 +* Lieu : Salle Condorcet (bât d'Alembert) +* Début : 19h00 +* Fin : ''avant 22h'' + +## Présents + +* Daniel Stan +* Lucas Serrano +* Valentin Samir + +## Ordre du jour + +### Imprimante + +Dans l'ordre : bourrage papier répétitif sur le bac 1, puis blocage en erreur +SAV. +Print Platinium à demander de confirmer le passage du technique, a priori, il +n'est pas passé. +Il faut renvoyer un mail a Print Platinium. + +### Vente de matériel / consommable + +Depuis 1 an nous vendons des câbles Ethernet. Ceci était fait de manière +informelle. Nous vendons desormais d'autres consommables et +matériels (adaptateur USB/Ethernet, boudins de reliure, etc.). Un nouveau menu +a été créé dans gest_crans pour cela. Il permet pour l'instant de compabiliser +les ventes d'adaptateur et de câbles. Il faut l'utiliser pour toutes ventes. +Il faut maintenant rajouter les autres items proposés à la vente. + +whos affiche la liste des factures d'un adherent. Pour consulter une facture en +détail, il vaut mieux utiliser whos_lc. + +### lc_ldap + +A priori tout fonctionne (factures, ressucite_lc, pretty printing). Il faut +tester intensivement lc_ldap avant de faire la migration complète. +Il faudrait peut-être refaire l'affichage de l'item chambre qui est pour +l'instant importé de whos. + +### PXE boot + +Valentin a ajouté la dernière ubuntu. Ça serait bien qu'un apprentis voient +comment on fait pour le mettre a jour. + +### Nouveaux disques dur + +Les nouveaux disques SAS 2To pour la baie de disque sont arrivés. Ils sont +installé dans l'ancienne baie de disque. +Il faudrait savoir comment on les partitionne : +Pierre-Elliott a suggéré de fragmenter les homes, une partition par lettre de +l'alphabet, comme ça c'est plus facile pour faire des fsck. +Il est proposé de faire un volume logique sur la baie, de mettre un LVM dedans +et de faire une partition sur le LVM par lettre. + +On utiliserait 4To des nouveaux disques pour les home (reste 2To de spare) +. les 600Go pour les VM du crans +. les 300Go pour les clubs + +On laisserait les $HOME dans /home/login et on mettrait un lien lien +symbolique /home/login -> /home-adh/l/login sur les machines où /home est monté +en entier, et on tweekerait les script shell de autofs sur les autres. + +Daniel propose de créer la nouvelle arboressence sur l'ancienne partition (avec +les liens symboliques). Cela devrait être rapide (il faut déplacer les dossiers +des home). Puis de faire des rsync vers les nouvelles partitions. + +### Wifi + +Bobine de cable reçue, séance au G samedi. + +### Enregistrement événementiel + +Valentin a mis les conférences des 15 ans, de l'install party 2013, des journée +fédérez 2013 et quelques autres sur (le logiciel +s'appel mediadrop) +Les fichiers multimédia sont sur , on rentre juste les +liens dans mediadrop. Pour faire du streaming efficace, on utilise du rtmp en +plus des liens http normaux. + +### Etherpad-lite + +Valentin a mis la conf au propre et l'a mis dans monit avec un init script. + +Ça marche bien, par contre, la plupart des plugins qui ont l'air utile sont +relativement caca (memory leak et cie). + +### Questions diverses + +#### Serveur pour la virtualisation + +Pierre-Elliott voudrait dimensionner un serveur de virtualisation a peut près +comme fz (~16Go de ram, pas de disque dur, des portS ethernet) avec idéalement +un proc avec 12 à 16 coeurs logiques. Le montant du prix serait de l'ordre +de 4000€. diff --git a/compte_rendus/2014_01_09.md b/compte_rendus/2014_01_09.md new file mode 100644 index 0000000..a4a5d12 --- /dev/null +++ b/compte_rendus/2014_01_09.md @@ -0,0 +1,112 @@ +# Réunion du Collège Technique + +* Date :Jeudi 9 janvier 2014 +* Lieu : Pavillon des Jardins +* Début : 19h25 +* Fin : 20h55 + +## Présents + +* Daniel Stan +* Valentin Samir +* Jordan Delorme +* Pierre-Elliott Bécue +* Ariane Soret +* Lucas Serrano + +## Ordre du jour + +### CACert + +Le domaine crans.org à été migré du compte de Stéphane Glondu vers le compte du +crans. Les certificats ont donc été révoqués puis recréés. +Tous les administrateurs déclarés à CACert peuvent émettre des certificats pour +les domaines enregistrés au crans. + +### Authentification par certificat + +Il serait intéressant de permettre aux gens de se connecter à certains services +avec une authentification par certificat. +Par exemple pour le wifi, vu que l'on utilise déjà les mots de passe wifi comme +un certificat. +Ça serait cool d'avoir aussi de l'auth par certificat en imap. Dovecot ne +permet pas nativement d'ajouter de l'authentification par certificat +parallèlement à une authentification par mot de passe (uniquement comme +authentification supplémentaire). Ça serait possible de le faire en utilisant +la méthode d'authentification via script custom, ça n'est pas très propre. Une +solution plus propre serait de mettre un second serveur imap qui ne ferait que +de l'authentification par certificat. + +Postfix gère bien l'auth par certificat, donc si on décide de mettre ça en +place ça ne devrait pas poser de problème. + +Idéalement, il y aurait une interface sur l'intranet permettant de générer des +certificats pour divers choses. +L'idée serait donc d'avoir une bdd centralisant les certificats et leurs usages +possibles. + +### Dns menteur ? + +Valentin a mis une zone de response-policy (db.loppsi.crans.org) pour mentir +plus proprement sur le dns. Pour le moment, c'est utilisé pour renvoyer vers +les miroirs locaux depuis les vlans accueil et événement. +Ça serait plus propre d'utiliser cette zone à la place de db.fake (qui est une +fausse zone racine) pour le vlan accueil. + +### IPv6 + +ne pas laisser passer le /32 de google semble bien le soulager +Le /32 de Google a été puni en IPv6 pour des raisons techniques (limitation de +bande passante alors que l'IPv6 est utilisé préférentiellement). +Lucas affirme que la diminution de trafic n'est pas lié uniquement aux serveurs +google, mais est un effet secondaire dû au fait que les gens n'ont plus d'accès +à un moteur de recherche et arrêtent donc de s'en servir. + +Il est cependant peu probable que Microsoft se tire une balle dans le pied en +bloquant l'ipv4 quand il y a une v6 active, vu que tous ses sites sont en +v4 (dont bing…). Des tests seront menés sur vo ce soir, et on essaiera +d'adopter une attitude pertinente. + +### Radio + +Valentin a mis des jolies n'images sur , et +un serveur icecast sur Cochon pour relayer la radio. + +Valentin voudrait ouvrir le port icecast de cochon pour diffuser la radio vers +l'extérieur (ça prend pas énormément de bande passante), dans l'ensemble, +l'idée semble intéressante, il faut juste s'assurer que c'est licite. + +### Impression + +Certaines personnes semblent parvenir à imprimer N copies d'un document en n'en +payant qu'une seule. Comme ils ne le souhaitent pas vraiment et nous non plus, +on cherche une solution. +Ce problème serait dû au fait que l'intranet thread et donc ne gère pas +correctement les accès concurrents. + +On pense mettre une barrière au bon endroit pour s'assurer que rien ne plante. +L'alternative est de finir l'appli impression sur l'intranet2. + +### Remplacement disque Fy + +C'est fait. Le disque pété est (probablement) parti vers HP. Le disque pas pété +est en place, et fonctionne. + +### Virtualiseur + +Un devis à été demandé, il devrait bientôt être disponible. + +### Questions diverses + +#### Nous ? (C'est le goût ?) + +Le collège technique accueille trois nouvelles nounous : Raphaël-David, Ariane +et Jordan. + +On précise au passage que la quantité de travail à fournir est laissée à +l'appréciation des sus-nommés. +Le fait d'être nounou n'engage pas les personnes à s'investir, mais leur donne +plus d'opportunités quant à leur engagement. + +On essaiera de prendre un peu de temps d'ici la semaine prochaine pour +présenter certaines des « obligations » des nounous (techniques). diff --git a/compte_rendus/2014_01_23.md b/compte_rendus/2014_01_23.md new file mode 100644 index 0000000..b632ace --- /dev/null +++ b/compte_rendus/2014_01_23.md @@ -0,0 +1,112 @@ +# Réunion du Collège Technique + +* Date : jeudi 23 janvier 2014 +* Lieu : salle Condorcet, bâtiment d'Alembert +* Début : 19h25 +* Fin : 20h30 + +## Présents + +* Aymeric Labatut +* Lucas Serrano +* Pierre-Elliott Bécue +* Raphaël Cauderlier +* Valentin Samir + +## Ordre du jour + +### Be friendly + +Il est suggéré d'accroître la visibilité de + pour la création de compte wiki +De manière générale, il faudrait faire une page BienvenueAuCrans ou un truc +du genre qui pointe vers tous les trucs qu'un nouvel +arrivant pourrait vouloir apprendre pour profiter de nos services. Plein de +pages d'explication gagneraient en visibilité. + ? -- nit + +Il a été soulevé le fait que la création d'un compte Wiki n'était pas triviale +pour tout le monde. Un lien vers la page idoine a été ajouté depuis la page de +connexion. +Il faut faire plus de promotion de nos services pour les nouveaux adhérents, +notamment la création d'une page wiki (CransPratique ?) +pour les nouveaux adhérents. + +* Merci ! -- WikiCandy <> + +### Nouvelle grappe de disque dur + +Le RAID6 est fait, il faut configurer la baie de disques slon pour qu'elle soit +connectée aussi au switch iscsi. Puis on pourra commencer la migration des +homes (enfin, leur copie). + +PEB commencera ça d'ici une petite semaine, mais si quelqu'un est intéressé, +qu'il fasse signe. + +### DNS + +Plusieurs choses. Première rotation des KSK (key signing key dnssec) pour +crans.eu. On a eu une petite co(q)uille avec bind, mais on l'a réglée. + +Les clefs ECDSA sont aussi prises en charge maintenant dans le DNS. +L'algorithme ecdsa a été ajouté dans le fichier /etc/ssh/sshd_config sur les +serveurs. +Les serveurs ne disposant pas de clef ecdsa envoient des warning. +La commande pour générer une telle clef est : +sudo /usr/bin/ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key -b 521 -t ecdsa -N "" + +Le collège des nounous présentes décide collégialement dans la bonne humeur +d'activer l'ipv6 sur les noms de domaine par défaut. +Par souci de compatibilité, en plus des zones v6 (qui sont ipv6 only), des +zones v4 seront alors créées (qui seront ipv4 only). + +Actuellement seules les machines ayant l'attribut ldap dnsipv6=TRUE ont de +l'ipv6 dans leur nom de domaine. Valentin propose de l'utiliser à partir de +maintenant comme suit : seules les machines avec l'attribut ldap dnsipv6=FALSE +garderont un nom de domaine ipv4 only. + +Les machines concernées seraient : + +* charybde (pour éviter de faire passer le ftp à traver le tunnel ipv6) + +Comme le script actuel de génération des zones des dns est vieillisant, il +serait bien d'adopter ces modifications en écrivant un nouveau script, dans un +style plus fonctionnel, utilisant lc_ldap. + +### Nouveau virtualiseur + +Son nom est ft. +Le nouveau virtualiseur est arrivé, a été installé, et s'appelle ft. On l'a +foutu au 0B, et on a viré malloc, daath et gordon. Niveau alimentations on est +à poil, faudrait racheter une pdu (oui, un truc qu'on visse dans l'armoire à +l'arrière). + +Il marche bien, proxmox est installé, la migration marche, il est connecté à la +baie de disques, et il est FAT. (pas 32) + +Il n'a que 16 Go de RAM sur les 300 potentiels qu'il peut avoir. On achètera +peut-être quelques barrettes de 8 Go. + +Sinon, l'onduleur est sollicité à 67 % de sa puissance maximale. + +Il est possible que ses batteries soient déficientes. Il faudrait donc faire +des tests, sachant que l'onduleur est censé tenir 40 min au moins. + +### Nouvelles bornes + +Say hello to Demodocos, pour le bâtiment Leonard de Vinci ! +Jordy aimerait poser encore d'autres bornes (3 serait appréciable) au Leonard +de Vinci, car il n'y a strictement rien. +De plus, ''hel'' ne marche pas : un technicien va la rebooter électriquement au +cas où. + +### Questions diverses + +#### Et pour l'écran de vo + +Le rétroéclairage ne fonctionne plus. Valentin propose qu'on achète un écran +de 30 pouces. PEB dit qu'il est pour si on achète un nouveau vo avec une GPU +suffisante. + +Plus sérieusement, on se propose de racheter un écran de la même gamme de +qualité (que celui-ci avait en 2008). diff --git a/compte_rendus/2014_02_06.md b/compte_rendus/2014_02_06.md new file mode 100644 index 0000000..f402373 --- /dev/null +++ b/compte_rendus/2014_02_06.md @@ -0,0 +1,135 @@ +# Réunion du Collège Technique + +* Date : Jeudi 6 février 2014 +* Lieu : Salle de conférence du Pavillon des Jardins +* Début : 19h00 +* Fin : 20h30 + +## Présents + +## Ordre du jour + +### Interfaçage de cranspassword avec ldap + +On a rajouté un attribut gpgMail (en plus du gpgFingerprint) dans la base ldap. +Il est fonctionnel dans le nouveau binding, mais pas encore dispo dans +gest_crans. +Daniel a écrit un script qui génère la configuration de cranspassword serveur à +partir de la base ldap (en se servant des attributs droits, gpgFingerPrint et +gpgMail). +Pour le moment, la base a été peuplée (pour l'attribut gpgMail) pour tous les +gens qui avaient donné une fingerprint. + +Il sera bientôt mis en production. +Question : modifie-t-on la configuration de manière automatique (via un cron) +ou requiert-on une intervention humaine pour confirmer les modifications de +droits ? On décide de garder un système de confirmation avant d'appliquer les +modifications (à la bcfg2) pour rendre la chose failproof. + +Todo : écrire une application sur l'intranet2 (dans mon compte) pour enregistrer +les fingerprint/mail. + +### apt-key + +Le crans possède un dépôt custom pour les paquets qu'il crée pour lui même (par +exemple bcfg2). +Ces paquets sont alors signés par une nounou (avec sa clef gpg). Aussi, faut-il +installer ces clefs sur les serveurs dans la configuration d'apt pour pouvoir +installer les paquets sans warning. +Les clefs sont dans bcfg2. +Rappel: il y a un +script {{{/usr/scripts/gestion/tools/apt-keys-crans.py}}} pour mettre à +jour les clefs sur bcfg2. + +Pour le moment il est exécuté manuellement. Valentin propose de le croner et de +retirer les fichier générer du dépôt git de bcfg2. + +Pas d'objection cinglante. + +### Génération du dns + +Valentin a réécrit le script bind.py de génération du DNS. C'est moins +monolithique, plus POO et ça utilise lc_ldap. +Changement notable : Les machines ont leur IPv6 d'annoncée par défaut par leur +nom de domaine. + +* {{{nom.v4}}} retourne seulement l'IPv4. +* {{{nom.v6}}} seulement l'IPv6. + +Il y a une case à cocher dans l'intranet2 dans l'application machines pour +désactiver ou réactiver ce comportement. + +Deux trois problèmes: + +* {{{freebox}}} et {{{ovh}}} ont des IPv6 erronées dans la base + ldap (IPv6 locales) -> plus joignables une fois annoncée dans le DNS +* {{{zbee}}} -> pour des raisons de NFS qui essayait de se monter en IPv6 à + travers le pare-feu +* munin -> les acl des nodes n'autorisaient pas l'IPv6 (connexion refused) ce + qui empêchait le fallback IPv4 + +### IPv6 + +Daniel a reregardé Huricann-Electrics : le plan était d'adhérer à Gitoyen pour +pouvoir lui demander un numéro d'AS (Autonomous System) et des IPv6. +Niveau coût il faudrait payer l'adhésion à Gitoyen (entre 100 et 200€) plus des +frais +administratifs (entre 200 et 300€). +Pierre-Elliott fait remarquer qu'on adhère à FedeRez pour un prix plus élevé. +Niveau administratif, il faut étudier la question (demander au CA). + +Valentin fait remarquer que quand bien même, avoir ses propres IPs serait bien +sympathique, il faut s'assurer de pouvoir les utiliser le jour où l'ENS passe +en IPv6. Aujourd'hui pour annoncer ses propres IPs via H-E, le tunnel de sortie +se trouve à Londres au lieu de Paris. Ce qui fait passer le RTT de 1ms à 8ms. + +### CaCert et clubs + +L'idée est de générer des certificats SSL !CaCert pour les machines de clubs +qui en font la demande. + +Sur le principe ok. Seul problème : si la machine est détruite, le certificat +existe toujours alors que le domaine peut être utilisé par quelqu'un d'autre. + +Soit on révoque directement les certificats quand la machine disparaît, via +une API (qui n'a pas l'air dispo pour l'instant +sur CaCert. + +Soit on empêche les opérations sur les machines qui ont toujours un certificat +valide. + +API à étudier : + + +Il serait bien d'avoir une interface sur l'intranet2 (étendre l'interface de +machine) +pour permettre de faire des demandes de certificats (et si l'API de !CaCert ne +marche pas, +une interface pour y répondre manuellement). + +### Digicode + +Lucas a rajouté une option sur l'app digicode pour créer des codes. Ça a l'air +de marcher. + +Reste plus qu'à migrer le tout. + +### Édition .forward + +Raphaël-David a fait un script pour éditer des {{{.forward}}}. Reste à régler +le problème de droits d'exécution du script (qui s’exécute en root pour +l'instant). +Il pourrait être envisagé de donner le droit au groupe respbats d’exécuter le +script en temps que n'importe qui du groupe user et de le lancer en temps que +l'user dont on veut éditer le .forward (cf ce qui est actuellement fait pour +l'intranet1). + +### ft + +Il est installé au 0B physiquement et logiciellement. Ça marche. +Il ne reste qu'à finir les migrations depuis Xen. + +### Wifi + +La DSI abandonne le ssid ENS Cachan. On arrête donc définitivement de le +diffuser. diff --git a/compte_rendus/2014_02_20.md b/compte_rendus/2014_02_20.md new file mode 100644 index 0000000..794999e --- /dev/null +++ b/compte_rendus/2014_02_20.md @@ -0,0 +1,141 @@ +# Réunion du Collège Technique + +* Date : 20 février 2014 +* Lieu : Salle de conférence du Pavillon des Jardins +* Début : 19h19 +* Fin : 21h00 + +## Présents + +* Ariane Soret +* Aymeric Labatut +* Daniel Stan +* Lucas Serrano +* Jordan Delorme +* Raphaël-David Lasseri +* Riwan Kherouf +* Valentin Samir + +## Ordre du jour + +### Digicode + +Lucas a mis en place le nouveau digicode_server et gen_code sur intranet2 et +sur asterisk. +Pour générer un code à partir de l'intranet2, il faut accéder à l'interface +admin de django. +Sinon, on peut toujours en générer sur l'intranet1… + +### lc_ldap + +Valentin a surchargé les attributs de lc_ldap pour permettre une comparaison +plus simple (et fonctionnelle) entre des objets ldap. +L'égalité fonctionne de façon sémantique sur les objets et les attributs comme +on pourrait s'y attendre (du coup {{{'club' in +club['objectClass']}}} fonctionne). +Les attributs peuvent être instanciés par leur type python correspondant (au +lieu de juste des unicodes). +Si deux attributs sont égaux, ils ont le même hash (cf. set et hashtable). +Les attributs pythons des attributs ldap Attr sont directement accessibles +comme des attributs d'Attr. +Les {{{machines['historique'].append()}}} fonctionnent comme on pourrait s'y +attendre et plein d'autres bonnes choses ! + +D'une manière générale, si on a besoin d’accéder à {{{attrs}}} sur +les !CransLdapObject ou à {{{value}}} sur les Attr, +c'est qu'il manque, sans doute, une méthode à écrire ou surcharger quelque part. + +### Enregistrement automatique des adresses MAC + +Daniel arrive à faire de l'authentification radius pour le WPA2 sans utiliser +le module radius dédié à cela mais en utilisant un script python. +Lors de l'authentification d'un client sur une borne, la borne met en relation +radius et le client, et radius l'authentifie avant de renvoyer le résultat à la +borne. + +Une idée en utilisant un script custom serait de pouvoir ne fournir aux +adhérents, lors de l'enregistrement d'une nouvelle machine wifi, que le nom +d'utilisateur et le mot de passe. Puis de remplir l'adresse mac de la machine +seulement lors de la première authentification réussie en utilisant celle de la +première machine qui s'authentifie. + +Les gens présents ont l'air assez enthousiastes pour le wifi. Une option +similaire en filaire reste à discussion. + +Il serait également bien que la première fois que l'adresse mac est +enregistrée, comme la machine vient de se connecter, qu'elle puisse accéder à +internet. Pour le dhcp, la mise à jour est déjà instantanée. Il manque la mise +à jour du pare-feu, au moins celui de komaz. + +Valentin propose une solution à partir d'une clef ssh n'ayant que le droit de +trigger l'appel à generate en s'inspirant +de [[CransTechnique/AdminRéseau/CommunicationsParSshEntreLesServeurs]]. +Nicolas aurait parlé d'une solution rabbitmq qui pourrait à terme remplacer le +système maison generate. + +### intranet2 + +#### Création de compte wiki + +Fait. + +#### Gestion des clefs ssh + +Valentin a ajouté la possibilité de remplacer les attributs sshFingerprint de +ses propres machines. Ils sont alors publiés dans le DNS du crans. + +### DNS + +#### TLSA + +Valentin rappelle brièvement que TLSA est un enregistrement DNS permettant de +vérifier la validité d'une clef publique du standard x509 via le DNS. + +Pour pouvoir permettre aux adhérents de publier, dans le DNS de leur machine, +leur certificat, il faudrait ajouter un nouvel objet ldap enfant des objets +machines (n'a pas de sens en LDAP) qui aurait en attribut : + +* name : les noms de domaine pour lesquels le certificat est + utilisé (multivalué) +* port : les ports sur lesquels le certificat est utilisé (multivalué) +* proto : tcp ou udp (multivalué) +* cert : quelque chose représentant le certificat (monovalué) +* certtype : le type d'enregistrement ; 0 = CA pinning, 1 = cert + pinning, 2 = self trusted CA, 3 = self trusted cert (monovalué) +* reftype : 0 = plain cert, 1 = sha256, 2 = sha512 (monovalué) + +À voir si on veut utiliser l'objet pour gérer les certificats d'une manière +générale… + +#### Blocage via response policy zone + +Valentin avait lors de l'install party précédente mis en place un DNS menteur +renvoyant archive.ubuntu vers +le miroir local. +Récemment il a étendu le rôle du DNS menteur à la zone crans pour empêcher les +IP utilisés par +Teredo (tunnel v6 propre aux machines sous windows) de contacter le DNS et +ainsi de faire de l'IPv6 pirate. +Théoriquement la future présence de RA pirates sur le réseau ne serait donc +plus fortuite +(en tout cas beaucoup moins). + +### Remplacement de ovh + +Une nouvelle machine est prête pour remplacer ovh : soyouz. +''A priori'', Valentin a fini sa configuration. Il faut juste modifier les +enregistrements du dns (MX et NS et glue record) pour remplacer ovh. +le TLSSTART en smtp ne marche pas, il faudrait juste mettre une paire de clefs. + +On va rendre ovh, il faudrait donc prendre le temps de shred les disques en +rescue mode. + +### Question diverse + +#### Migration XEN -> Proxmox + +Daniel propose de faire une séance migration samedi après-midi (tôt pour ne pas +concurrencer la LAN A♡). +Les volontaires ne lèvent pas tous le doigt en même temps. +Daniel annonce donc une « petite » maintenance sur CransIncidents et sur les +news. diff --git a/compte_rendus/2014_03_13.md b/compte_rendus/2014_03_13.md new file mode 100644 index 0000000..3658d3e --- /dev/null +++ b/compte_rendus/2014_03_13.md @@ -0,0 +1,196 @@ +# Réunion du Collège Technique + +* Date : Jeudi 13 mars 2014 +* Lieu : Salle de conférence du Pavillon de Jardins +* Début : 19h22 +* Fin : 21h12 + +## Présents + +* Jordan Delorme +* Lucas Serrano +* Pierre-Elliott Bécue +* Vincent Le Gallic + +## Ordre du jour + +### Gestion des certificats + +Valentin a proposé de mettre tous les certificats SSL crans et les clefs +privées associés (possiblement chiffrées) dans ldap et d'utiliser un fuse pour +générer automatiquement les fichiers de certificats dont ont besoin les +différents services directement à partir de ldap. + +Les certificats pourraient ensuite être gérés par {{{bcfg2}}}, une màj des +certifs consisterait à mettre le nouveau en raw dans LDAP et de run +un {{{bcfg2}}} wherever needed. + +Pierre-Elliott est contre la présence des clés privées dans LDAP si on ne lui +donne pas une bonne raison (et lui-même n'en voit pas). Il faudrait quelqu'un +de motivé par le projet parce que ça risque de ne pas être simple. + +Dans l'idée {{{bcfg2}}}, Vincent pense qu'il va falloir gérer les différents +formats de certificats. Est-ce qu'on ne pourrait pas faire +comme {{{secrets.py}}} ou {{{secrets_new.py}}} ? Problème : actuellement, tout +va sur tous les serveurs. + +On attend d'y voir plus clair et d'avoir les idées de Valentin sur le sujet. + +### Multicast filtering + +Sur le réseau les Apple utilisent un protocole foireux, mDNS. + +Le principe est d'annoncer les services des autres machines sur le réseau, même +quand elles en ont disparu (passage en veille). Pour cela, elles spoofent l'IP +de la machine éteinte. C'est '''mal''', et ça fait beugler {{{arpwatch}}}. On +en a eu marre, Ping a demandé aux switchs de dropper le mDNS. + +Problème, ça ne marche que sur les switchs Gigabits et le backbone. +Techniquement ça resterait possible entre deux personnes d'un même étage, +mais ''a priori'', le multicast n'est transmis qu'une fois qu'il a atteint le +querier, à savoir le backbone, qui sait dropper, donc on est sauvés. +Bonne nouvelle, on a '''beaucoup''' moins de spam sur flip-flop, et tout ce qui +reste est normalement des vrais cas de spoof (ou des changements légitimes +d'adresse MAC suite à un câblage). + +### Virtualisation + +#### Xen => Proxmox + +La migration c'est fini. \o/ +Les vieux disques ont été supprimés. Il faut faire attention car les serveurs +ont tendance à paniquer lorsque l'on supprime leurs vieux disques. + +Nouvelles features : + +* Pierre-Elliott est en train de développer des utilitaires en command line + pour créer des VM plus facilement. L'objectif idéal serait d'avoir un seul + script à lancer, mais si déjà, avec quelques scripts tout faits, on s'en sort… +* Les VM utilisent des disques virtIO, qui ont des temps d'accès beaucoup plus + courts que les émulations de IDE/SATA/SCSI. Du coup ça juste marche mieux. +* Les filesystems (qui étaient en ext3 sur les vieilles vm) sont en ext4. +* Proxmox utilise les fonctionnalités VTx with extended pages des procos intel, + ce qui permet aux vm de fonctionner en real mode. C'est pas trivial à définir + mais en gros, le gain de perf est vraiment élevé. +* PEB a fait une conf manuelle qui est dans {{{bcfg2}}} pour l'ISCSI. + Maintenant, quand les hosts démarrent, ils ne vont plus attendre 2 minutes + toutes les interfaces des baies. Sur les interfaces non branchées, ils + n'attendent que 15 secondes. +* Le cluster est composé de fz, ft et kdell. fz et ft sont fat, et kdell se + défend. Du fait de l'utilisation des features VTx with extended pages des + procos, fy est useless. (Son proco ne les supporte pas, ce qui fait que les + vm migrées depuis l'un des trois autres sur fy, elles freezent en + utilisant 100% d'un cœur.) + +Ce qui nous mène à : « quid de fy ? » + +PEB va essayer de documenter le wiki, parce que chez Proxmox, ils sont +clairement avares en infos sur certains points de fonctionnement des clusters. + +Entre autres, il a tweaké le {{{/etc/hosts}}} des hosts Proxmox pour que leur +nom « canonique » (celui sans le (.adm)?.crans.org) pointe vers leur IP adm, +car c'est avec ce nom que le cluster choisit ses IP. On remercie entre autres +les gars de chez Proxmox qui précisent pas ça sur la page « créer un cluster ». + +Pour info, Proxmox vend un service (sous forme de licence) d'aide et de je sais +pas trop quoi, à un prix modeste : une trentaine d'euros par cœur par mois. Et +bien entendu, TOUS les hosts DOIVENT avoir la MÊME licence. + +#### Avenir de fy + +{{{fy}}} ne servant à rien et étant vraiment fat, il faut se demander ce qu'on +en fait. Dyson est complètement à la ramasse en ce qui concerne le monitoring, +et komaz commence à se faire un peu vieux. + +Entre les deux, celui qui fitterait probablement le mieux serait dyson. +D'autant plus que la garantie de fy expire, et qu'un routeur non garanti, c'est +pas cool. + +##### Avenir de komaz/dyson + +Il semblerait bon de racheter un nouveau routeur, pour des raisons de garantie, +en plus, il serait bénéfique qu'il fasse le comptage d'upload lui-même, pour +décharger le serveur de logs (cf point suivant). + +S'il est dimensionné correctement, ça passera sans problème. Valentin avait +suggéré qu'on pourrait améliorer le comptage d'upload pour décharger la base +postgres. À voir aussi. + +Ping évoque le SSD, ça pourrait être intéressant pour le futur komaz. Pour +thot, il faut y réfléchir. Pour dyson c'est pas utile. + +Passer dyson sur fy semble pas mal. + +#### Elastic search ftw ? + +Logstash l'utilise comme backend. Logstash est paraît-il très bien. On a testé +les limites de rsyslog-pgsql. Il faudrait tester, quitte à migrer les db +postgres sur des VM. + +Avis aux amateurs pour tester elasticsearch. + +### Application des nouveaux statuts + +PEB a commencé à recoder la moitié de {{{gest_crans}}} et {{{ldap_crans}}} pour +qu'on puisse appliquer les adhésions glissantes. Des tests seront faits ce +weekend ou le suivant. Il faut prévenir les câbleurs, et leur empêcher +l'utilisation de gest_crans durant les tests. + +Les modifs sont sur la branche {{{peb}}} du dépôt de prod. Faites gaffe à pas +checkout dessus. + +### Services/Generate + +Nicolas a parlé de {{{rabbitmq}}} comme système pour dispatcher des +messages/informations à d'autres machines, en remplacement de generate/services +qui marche mal, en 15 min. PEB a testé sur des trucs kikoo, c'est rigolo. On a +installé une vm {{{civet}}} qui servirait de serveur rabbitmq. D'autres tests +sont à venir, et les curieux peuvent query PEB. + +### Gestion des homes + +PEB a créé 27 disques logiques sur la baie, olasd trouve que ce n'est pas +adapté, quid des autres ? + +* Le problème des quotas n'a pas encore été soulevé, 27 filesystems ça veut + dire 27 quotas différents. Mais ça peut se régler en se disant que toto + passoir ne peut écrire que dans son home. +* /home/mail => ln -s /home/mail/user/ /home/user/Mail/INBOX + +. Attention NFS n'exporte pas les liens symboliques comme on le +veut. (zbee != zamok) + +### Wifi au PdJ + +La DSI nous a chié au visage pour le tirage des câbles pour nos bornes au PdJ. +Donc on devra en tirer nous-même. + +Envoie-t-on un mail courroucé à la DSI ? + +* Owi owi -- [[Wiki20-100]] + +### Migration de git + +Le dépôt {{{git}}} a été viré de charybde. Ça permet de puller/pusher sans +attendre des heures qu'il ait fini avec ses IO ftp. Maintenant, +contactez {{{geet}}}. + +Vire-t-on les miroirs OpenBSD ? + +### Paquet pour ajout de certificats sur Mac + +Jordy et Ping ont travaillé sur un paquet pour importer les certificats +nécessaires pour nos pages. Ce paquet pourrait être l'occasion de modifier le +comportement mDNS de Bonjour pour éviter les problèmes posés quelques points au +dessus. Ça sera, a priori, bientôt terminé. + +### Le RTC est malade :( + +Valentin semble malade depuis presque deux semaines. Il risque de rentrer chez +lui pour quelques temps. Les nounous souhaitent lui témoigner leur soutien et +lui souhaitent un prompt rétablissement. + +Pierre-Elliott et Daniel s'occuperont de contacter Anne en cas de besoin durant +l'absence de celui-ci (demandes de devis et autre). On lui demandera de nous +mettre en copie des mails qu'elle lui envoie (renouvellement de +garanties & cie). diff --git a/compte_rendus/2014_03_27.md b/compte_rendus/2014_03_27.md new file mode 100644 index 0000000..a65bdc1 --- /dev/null +++ b/compte_rendus/2014_03_27.md @@ -0,0 +1,106 @@ +# InterNounous + +* Date : Jeudi 27 mars 2014 +* Lieu : Salle de conf au Pavillon des Jardins +* Heure : 19h33 +* Fin : 21h00 + +## Présents + +* Aymeric Labatut +* Daniel Stan +* Jordan Delorme +* Lucas Serrano +* Pierre-Elliott Bécue + +## OdJ + +### GitLab et migration des dépôts git + +Pierre-Elliott a commencé à mettre en place gitlab + +Démo + +1. Aller sur +1. Se loguer avec son compte ldap (CAS ??) + +But : Plus d'acl sur les dépôts. Ça marche aussi avec des comptes locaux (≠ non +crans). +Le https est maintenant par défaut. L'intérêt est d'accroître la visibilité des +dépôts git du Crans et gérer des pull request. +Question : quid de gitweb () pour l'instant, on le +garde (tant que ça marche). + +Il faut ajouter une clé ssh dans son profil gitlab, pour pouvoir ensuite se +connecter en tant que l'utilisateur git. +Comme tout passe par l'utilisateur git sur le serveur, les modifications, +commits et pushes en prod seront sensiblement +plus complexes à faire, sauf à forwarder son agent, ou à s'ajouter une clef ssh. + +### Nouvelles bornes WiFi + +On a reçu les nouvelles bornes WiFi au nombre de 12. + +Le modèle reçu a été mis à jour, le système de fixation a changé. +Et surtout, on a des injecteurs avec bouton reset (bien pratique quand accéder +physiquement à la borne est compliqué). + +Lucas a flashé 3 bornes dans le but de les mettre au bâtiment A. Il faut se +faire une séance posage de bornes avec les apprentis. +On propose le week-end du 4 Avril. +Reste également : le Pavillon des Jardins. On se demande s'il ne vaudrait pas +mieux mettre les bornes en dehors des faux-plafonds (qui sont +métalliques). À étudier et à discuter avec M Burgun… + +Jordy a posé 4 bornes au DGM, en attente de brassage de vlan côté DSI. (Link, +agenor, polynice, ulysse). On attend encore leur inscription sur +la ! + +### Nouveau routeur + +Pas encore reçu de devis. L'idée serait de remplacer komaz par un truc un peu +plus costaud. + +A priori : + +(Vérifier que le contrôleur réseau 4 ports a bien une capacité de switching +de 1Gigabit par port et non 1Gigabit au total) + +### Homes des adhérents + +Pierre-Elliott avait créé un lvm par lettre de l'alphabet (+ 1 pour les logs). +Une ancienne nounou trouve que ça fait beaucoup. L'intérêt serait de +fractionner les sauvegardes, et de récupérer plus facilement d'un crash sur un +des fs. + +Reste le problème de la migration… + +### Sécurisation de /usr/scripts + +Pierre-Elliott propose que chaque serveur clone /usr/scripts, avec un cron qui +vérifie également la connectivité du nfs. En cas de soucis, il ferait un +mount -o bind + +Il faut trouver une solution avec /usr/scripts/var/ + +* monit (quasi ok) +* numeros_disponibles -> voué à disparaître +* fichiers d'impression -> censés être dans le home des adhérents +* […] + +Avis à apprenti et nounou motivés + +### CACert + +CaCert a été retiré de Debian + + +Question : + +1. Le ticket soulève des problèmes de sécurité dans le code de CACert, a-t-on + peur ? +1. Quelle alternative à ce CA ? +1. Que faire si on migre ? Aka migre-t-on tout sur un CA commercial ou + laisse-t-on le WiFi sur !CaCert ? + +On ne prend pas de décision maintenant. diff --git a/compte_rendus/2014_04_10.md b/compte_rendus/2014_04_10.md new file mode 100644 index 0000000..f93abbd --- /dev/null +++ b/compte_rendus/2014_04_10.md @@ -0,0 +1,199 @@ +# Réunion du Collège Technique + +* Date : Jeudi 10 avril 2014 +* Lieu : Condorcet +* Début : 19h30 +* Fin : 21h15 + +## Présents + +* Pierre-Elliott Becue +* Jordan Delorme +* Vincent Le Gallic +* Lucas Serrano + +## Ordre du jour + +### HeartBleed (OpenSSL) + +On ne rappelle pas les faits : ils sont suffisament détaillés sur le net. +Tous les certificats accessibles depuis l'extérieur du campus ont été +renouvelés sauf redisdead. + +* j'imagine que le renouvellement des clefs privées est sous entendu, ça serait + bien de remettre le TLSA un peu partout (via {{{gest_crans_lc}}} par + exemple), le certificat de sogo est révoqué, quid des clefs du openVPN + soyouz-komaz-titanic qui donne accès à + adm -- ValentinSamir <> + +Pierre-Elliott a plus ou moins écrit une page Wiki pour informer les adhérents +de la faille de sécurité. +Lien de la page : HeartBleed + +Il faut encore renouveler les certificats de : + +* Redisdead (x2) +* XMPP +* O2 +* Asterix +* Wifi +* News +* Tracker + +### QR codes + +Le BDE/Gala souhaiterait savoir si le Cr@ns peut éditer les QR codes en plus de +les imprimer. + +Y'a plein de lib python pour faire des QRCode. Il faudrait faire un site web +pour les organisateurs du gala. +On peut utiliser l'interface d'admin d'une appli django. + +On manque pas mal d'infos sur le cahier des charges : + +* Est-ce qu'on doit permettre le paiement en ligne ? +* Comment ça se passe pour les bipper le soir du gala ? + +On va demander de plus amples précisions au gala. + +Daphné, membre du bureau du gala 2015 a précisé à Pierre-Elliott le cahier des +charges pendant qu'il allait chercher son linge (ah bah bravo). +L'idée serait d'avoir un site dédié à la gestion des préventes en ligne, donc +l'édition des billets avec QR code, le stockage des informations personnelles +des acheteurs, et l'interface de paiement en ligne. + +* Pour le paiement, elle se mettra en relation avec le crédit mutuel ; +* Pour l'édition des pdf billets/whatever, on peut le faire. +* Pour les scanettes de QRCode, il faut trouver un endroit où en acheter/louer, + pour faire des tests + +et voir combien ça coûte. + +Pierre-Elliott la recontactera par mail pour établir une roadmap. +Une deadline courte devra être faite pour le site pour que le gala puisse se +retourner librement +si on est pas assez efficaces. + +### Virtualisation + +Le BdE trouverait confortable de virtualiser ses serveurs : tous sauf +videosurveillance. + +Vincent trouve gênant de prendre maintenant une décision engageant les nounous +à venir et les BdE à +venir de rendre ''techniquement'' accessible aux nounous la base de données du +BDE de manière irréversible. +Ceci serait valable quel que soit le club/assoce qu'on virtualise. + +On pourrait modifier notre charte de membre actif en précisant qu'on héberge +des serveurs contenant potentiellement des données d'adhérents non Cr@ns. +Pour les clubs, il est possible de préciser dans le formulaire de création de +club que leurs données sont stockées dans un serveur du Cr@ns, ou alors créer +un formulaire de création de machine virtuelle pour que chaque parti soit +conscient des enjeux. + +Vincent veut bien s'occuper d'écrire un formulaire de création de machine +virtuelle, il demandera conseil à Matthieu Bach. + +### Droits apprentis + +La problématique soulevée est que les câbleurs/apprentis ne peuvent pas +répondre aux demandes des adhérents +concernant leur blocage pour upload. + +Vincent croyait que c'était possible aux apprentis, et a donc fait une +modification dans le sudoers, qui a été annulée +par Pierre-Elliott depuis. + +Actuellement, la question est donc de savoir si les apprentis devraient avoir +ce genre de droit. (exécuter analyse.py, ou autres scripts du style) + +Vincent souligne que les apprentis ont accepté la même charte de membre actif +que les nounous et sont donc soumis +aux mêmes règles. Par ailleurs, supprimer de la fonctionnalité au nom de la +sécurité n'est pas une solution. Enfin, les adhérents +qui demandaient des réponses sur disconnect@ n'avaient pas forcément une +réponse avant l'expiration des logs. + +* il y a un dump des logs d'{{{analyse.py}}} lors de la déconnexion + dans {{{/usr/scripts/var/analyse/IP-TIME.txt}}}, il faudrait d'ailleurs y + faire le ménage -- ValentinSamir <> + +Premièrement, on peut augmenter la durée de vie des logs d'upload. + +Il est envisagé de créer un droit supplémentaire "Disconnect" permettant aux +apprentis à qui on le donnerait de pouvoir répondre aux +adhérents sur disconnect@ et de lancer {{{analyse.py}}}. Il faudrait qu'il ne +soit pas donné dès l'accession au statut d'apprenti. +Dans la même idée, une version spéciale "nouveau câbleur" du whos pourrait être +proposé pour filtrer certaines données a priori +sensibles lors d'un câblage. + +### Charte des MA + +Pierre-Elliott propose qu'on édite une charte spécifique à signer pour les +nounous (ce qui permettrait de faire une +page wiki au passage pour résumer les droits (et leur moyen d'application) des +nounous), spécifique à leurs nouvelles +attributions. Cela servirait en plus de piqûre de rappel lors de l'ajout de +droit. + +### IRC + +Il y a actuellement sur #roots des non-MA. Ça pose problème quand on doit +parler de données privées d'adhérents : on n'a pas de channel "privé". +Si un adhérent doit évoquer des informations personnelles sur #crans, il sera +alors invité à rejoindre #roots. + +Les non-membres actifs actuellement présents sur #roots vont être invités à +quitter le channel. + +### Câbleuse + +On se propose de mettre la carcasse de oie à la Kfet après l'avoir transformée +en câbleuse, branchée à l'imprimante thermique. +Si on souhaite installer une interface graphique pour que la câbleuse puisse +être utilisée par les permanenciers BDE pour la note +en dehors des horaires de permanences Cr@ns, oie est vite gavée. Une solution +serait d'installer XFCE ou awesome. + +On a pas de réponse de BdE sur cette possibilité de câbleuse, l'encombrement du +bar ou la possibilité de mettre un écran. + +### Questions diverses + +#### Convention Cr@ns-CROUS + +Il faut en parler en CA, mais en gros, une réunion doit être organisée avant +l'été, de façon à +l'actualiser, voire, la resigner. + +En vrac, les points à discuter : + +* Fiche câblage +* Locaux sensibles +* Access points (WIFI) + +En bonus (non lié à la convention) + +* Livret d'accueil du CROUS + +#### Manque d'IP + +On va demander à Daniel s'il peut remettre en service son système de ménage +automatisé. Aussi bien pour le wifi que le filaire. + +#### Ressuscite + +{{{ressuscite.py}}} est cassé, encore… +Vincent a ressuscité récemment un adhérent en plongeant encore les mains dans +le cambouis, il en a marre, il va mettre dans {{{/usr/scripts/utils/}}} un truc +pour +dumper un adhérent du cimetière et y'aura plus qu'à faire un coup de +shelldap. (gruik) + +* Il ne faudrait plus supprimer des entrées de la base de donnée que + avec {{{lc_ldap}}}. {{{chambre_vide.py}}} ou l'intranet2 pour les machines + et {{{gest_crans_lc}}} pour les adhérents par + exemple. {{{ressucite_lc}}} bien que basique fonctionne a + priori -- ValentinSamir <> diff --git a/compte_rendus/2014_05_08.md b/compte_rendus/2014_05_08.md new file mode 100644 index 0000000..f7cbdbf --- /dev/null +++ b/compte_rendus/2014_05_08.md @@ -0,0 +1,167 @@ +# Internounous + +* Date : Jeudi 8 mai 2014 +* Lieu : Salle de conférence du Pavillon de Jardins +* Début : 19h13 +* Fin : 21h14 + +## Présents + +* Adam Heriban +* Daniel Stan +* Pauline Pommeret +* Pierre-Elliott Bécue +* Vincent Le Gallic (arrivée à 19h33) + +## Ordre du jour + +### Nouveau RTC + +En l'absence de Valentin Samir qui semble devoir faire face à d'autres +obligations, Daniel Stan s'est porté volontaire +pour assurer le rôle de RTC. Son initiative a été approuvée par le CT, et c'est +désormais officiel. Félicitations Daniel ! + +La question de la récupération des clefs de Valentin (clef 0B et coffre en +particulier) se pose. Daniel va essayer de le +contacter par divers moyens afin d'en discuter avec lui. + +### CransClefs + +Il faut vraiment que les MA mettent à jour VieCrans/CransClefs, elle n'est +manifestement pas à jour, et cela devient problématique. +Il faut rappeler au trésorier actuel que c'est de son ressort et qu'il doit +veiller à ce que les détenteurs des clefs soient +identifiés, quitte à ce que des cautions soient encaissées. + +Il est demandé à Vincent Guiraud de vérifier la présence de clefs 2B dans le +coffre. La réponse est non (il n'y a pas de clefs). + +Il faudra penser, pour les années à venir, à dire aux personnes partant en +stage de le dire sur la page VieCrans/CransVacances +et à rendre leurs clefs avant de partir. + +Une clef du disjoncteur du 0M nous a été confiée par le CROUS et est +actuellement au 2B, faute d'avoir +pu fournir une clef 0B à Jordan Delorme. Cela commence sérieusement à être +problématique. Il faut demander au CA +de voter un budget pour réaliser la copie de 2 jeux de clefs 0B. + +### Blocage du /64 wifi sur Wikipedia + +On a découvert le 4 mai qu'un ou des adhérents auraient poussé des admins de +Wikipédia à bloquer le /64 wifi de manière à ce que +les adhérents du Crans ne puissent ni créer de compte ni éditer de page. + +L'administrateur de wikipedia ne souhaite pas lever le blocage tant qu'il n'est +pas en mesure de différencier 2 utilisateurs venant +de chez nous, et par là même de bloquer uniquement celui qu'il considère comme +vandale. En effet, le fonctionnement de l'IPv6 +au crans laisse le choix à la machine d'un suffixe aléatoire (extension de vie +privée) dans le même /64. Nous sommes donc les seuls +à connaître la correspondance entre une IPv6 et une machine du réseau (pour +comptage d'upload), et ceci de manière volontaire +(il s'agit d'un des buts du système d'extension de vie privée). + +Que faire ? +D'un côté, on peut se soucier des conséquences pour les autres adhérents : + +* Ne rien faire +* Bloquer la plage IPv6 de Wikipedia pour forcer l'IPv4 (comme pour google), la + plage IPv4 n'est pas bloquée et ne risque pas de l'être (chaque adhérent + étant clairement identifiable) +* Implémenter un routage plus fin de l'IPv6 + +La deuxième solution pose des problèmes d'altération du réseau. En l'état +actuel, nous n'avons pas de raison valable pour +suivre la démarche de Wikipedia dans la violation de la neutralité du réseau. +De plus, le blocage actuel est peu sévère et les +rares adhérents impactés ont des alternatives pour l'accès à Wikipedia, comme +la désactivation de l'IPv6 (envoyer un mail ? message +sur autostatus ?) + +La dernière solution (se référer à [[CransTechnique/PlanAdressage#IPv6]]) est +de toute façon un projet de longue date sur lequel il faut +se pencher. L'idée est d'allouer à chaque machine un /64 distinct. Il faut +regarder de la doc du côté de DHCPv6 et de délégation +et implémenter cela en parallèle de la solution actuelle. + +Du côté de l'adhérent accusé pour wikipedia, nous n'avons pas constaté d'abus +ni de nuisance sur le réseau que nous pouvons lui imputer. + +On décide de ne rien faire pour le moment et d'analyser la solution d'adressage +v6. On avisera en temps utile. Le CA tient à en +discuter lors de sa prochaine réunion pour l'aspect administratif de ce +problème. Une tentative de contact a été prise par le CA, +et s'est pour l'instant avérée infructueuse. + +### Comptage upload et avertissements + +Le CA souhaiterait que les mails d'avertissement pour upload à 300Mo soient +moins agressifs et plus pédagogues. +De plus 300Mo semble une limite très facilement atteignable de nos jours avec +les technologies actuellement +présentes sur Internet. + +Pierre-Elliott souhaite conserver cette limite basse afin de laisser aux +adhérents le temps de réagir lors de la réception +d'une alerte. Une limite plus haute, en cas d'upload rapide, ne permettrait pas +d'avertir l'adhérent d'un comportement +anormal de sa machine avant qu'il ne soit effectivement déconnecté. + +Cependant, plusieurs adhérents ont exprimé leur volonté de ne plus recevoir ce +mail d'alerte. + +Raphaël Bonaque (irc) est volontaire pour rajouter un champs sur +l'intranet (lié à ldap ? pg ?) pour choisir à partir de quel seuil +un adhérent souhaite recevoir son mail d'avertissement pour upload. Cela +demande peu de modifications dans notre système +de comptage d'upload et permettrait aux adhérents ne plus recevoir ce mail ou +de configurer à quel moment ils souhaitent +le recevoir. + +### Impression + +Le devis d'Open concernant leur imprimante Xerox nous a permis de soulever un +problème important : l'imprimante a sa sortie sur +la droite, tandis que la notre sort à gauche. Ça demanderait donc un +réaménagement du 4J, à voir avec des mesures et +éventuellement donner une date à Open pour qu'ils passent voir le local. + +Pas de trace de compatibilité Linux sur la Ricoh proposée par AMP. + +### DSI-Crans + +Pierre-Elliott a créé une ML d'alerte utilisable par la DSI afin d'éviter de +spammer tous ses membres à la moindre alerte nous concernant +sur dsi-crans. root@ est abonné directement. + +Préparation d'une future réunion ? Potentiellement à l'OdJ + +* Autorisation d'un deuxième routeur crans dans la zone zrt (nouveau komaz) +* Demande d'un petit /24 pour des tests nat64 ? +* Tout ce que vous estimerez pertinent (demander au CA, notamment pour Saclay) + +### Projets en cours + +Pierre-Elliott a fait un peu de ménage dans le tracker, il y a des projets pour +les apprentis, avis aux personnes motivées ! + +Pauline souhaite que les tâches réalisables par un apprenti (en +autonomie) soient davantage mises en valeurs. + +Il faut faire quelque chose de toutes ces tâches (renouvellement des +certificats, KSK, etc) qui produisent beaucoup de bruit. +Pour les certificats, on a ce qu'il faut automatiquement avec check_cert, +Pierre-Elliott va essayer de faire un programme du même genre +pour DNSSEC. + +### Questions diverses + +#### Binding Ldap + +Pierre-Elliott s'est lancé dans la réécriture de certains scripts de gestion +s'appuyant sur ldap_crans pour les porter sur lc_ldap. Il +a également commencé une implémentation de generate basée sur rabbitmq. +Pour l'instant, il s'est penché sur dhcp, ça marche, il faut continuer. Il +attend des reviews. diff --git a/compte_rendus/2014_05_22.md b/compte_rendus/2014_05_22.md new file mode 100644 index 0000000..0156d90 --- /dev/null +++ b/compte_rendus/2014_05_22.md @@ -0,0 +1,93 @@ +# Réunion inter-nounous + +* Date : Jeudi 22 mai 2014 +* Lieu : Pavillon des Jardins +* Début : 19h20 +* Fin : 20h41 + +## Présents + +* Jordan Delorme +* Lucas Serrano +* Daniel Stan +* Pierre-Elliott Bécue + +## Ordre du jour + +### Imprimante + +On choisit la Xerox, au vu de la compatibilité douteuse de la Ricoh. Un +réaménagement du 4J s'avère nécessaire, mais peu compliqué à gérer : on +s'oriente vers +un agrandissement de la sortie ou un changement (sur l'autre côté du mur), dans +les deux cas en rebouchant l'ancien. + +On pense faire une expédition, après accord CA, dans un magasin de construction +pour acheter des plaques de plâtres et des parpaings (pour l'onduleur). + +Le binding de la nouvelle imprimante (CUPS+lp) est déjà (presque) prêt, on se +servirai de celui de l'ancienne imprimante, en adaptant les options proprio +d'agrafage et cie. + +### QRCode (Gala) + +Pierre-Elliott a discuté avec l'équipe gala, pour se mettre d'accord sur les +deadlines et les besoins du gala. +Actuellement le prestataire privé coûte environ 1200€, pour la mise en place du +site et la taxe sur les billets. + +Le Cr@ns aimerait leur fournir ce service à la place. L'idée serait d'acheter +les scanettes de QRCode et de voir +avec leur banque pour la mise en place du service de paiement en ligne. + +Pierre-Elliott est motivé pour s'occuper de ce projet en collaboration avec le +Gala. Daniel l'aidera. + +Cahier des charges : + +* Site en django de gestion de QRCodes ; + * Formulaire pour acheter un/des billets avec paiement en ligne et + validation de transaction ; + * Envoi de mail en cas de succès avec lien pour récupérer le billet ; + * Lien générant des pdf et les stockant (pour téléchargement futur) ; + * Administration : validation manuelle de ticket en cas d'échec après renvoi + post-paiement ; interface de suppression de ticket nominatif ; édition et + suppression de ticket pour souche en masse ; +* Appli python qui après scan de code barre/QRCode renvoie sur le site avec une + bonne url pour valider le billet (id + hash) + +### Avancement du WiFi + +Le Pavillon des Jardins est presque entièrement câblé. Il reste le 4^ème^ étage. + +NB (post CR) : le dernier étage a été câblé deux jours plus tard. + +### Rabbit MQ + +Le principe choisi est le suivant : le(s) binding(s) notifient le serveur +RabbitMQ d'une modification ldap avec une "modlist" (ou assimilé) en argument. +Un script démon sur RabbitMQ lit cette file d'attente et dispatche (en fonction +du modlist) la modification aux files d'attente des services concernés. + +### Binding Ldap pour les adhésions glissantes + +Ça marche, mais ça s'intègre mal à gest_crans … On travaille encore dessus pour +arriver à selectionner des adhérents à jour de cotisation à partir +de ses factures. + +## Bilan todolist + +Pour résumer les trucs à faire prochainement : + +Pas prioritaire : + +* Adhésions glissantes (fin juillet, début août) +* Messaging via Rabbit MQ (pas tout de suite) +* câbleuse (dépendant de RabbitMQ) + +Urgents : + +* lc_ldap : locks sur un objet (actuellement, locks uniquement sur une valeur + donnée d'un type donné) +* Imprimante +* Site du Gala diff --git a/compte_rendus/2014_06_05.md b/compte_rendus/2014_06_05.md new file mode 100644 index 0000000..c61af85 --- /dev/null +++ b/compte_rendus/2014_06_05.md @@ -0,0 +1,90 @@ +# Réunion inter-nounous + +* Date : Jeudi 5 juin 2014 +* Lieu : Pavillon des Jardins +* Début : 19h30 +* Fin : 20h38 + +## Présents + +* Adam Heriban +* Daniel Stan +* Florian Marconi +* Jean-Baptiste Guyon +* Jordan Delorme (arrivé à 19h45) +* Pierre-Elliott Bécue + +## Ordre du jour + +### Imprimante + +On s'oriente sur le week-end du 5-6 juillet pour installer la nouvelle +imprimante et faire les travaux. Daniel présente une nouvelle +organisation possible du 4J et les éléments à acheter. Pour le problème de la +fixation de l'imprimante (pour éviter de pouvoir +rentrer dans la pièce en la poussant), on pense utiliser une barre en metal au +niveau du sol. + +On demande à la menuiz' si ils disposent d'une disqueuse adaptée, sinon, on +s'oriente vers la location. Ils sont d'accord, +et sont même prêts à nous aider, en revanche on devra acheter un disque à +plâtre. + +### Réseau au point rencontre + +Le BDE voudrait du filaire au point rencontre. De préférence, ils voudraient le +vlan adhérent, afin de disposer aussi +des services TV. Pour l'instant, la demande de travaux a été effectuée pour le +vlan 10, on avisera pour leur +fournir les services supplémentaires quand il sera effectivement brassé. + +### CNS Conseil + +Deux représentants de CNS Conseil aimeraient bien savoir si le collège +technique est d'accord pour ouvrir partiellement le réseau wifi pour le +CRA (congrès régional d'automne). +A priori 200~300 personnes. Ils souhaitent le soutien du Crans pour fournir un +réseau WiFi. +Date : novembre. + +Amphi utilisés : + +* Tocqueville +* Curie +* Fonteneau +* Condorcet +* Villon + +Au niveau matériel, nous avons suffisamment de bornes supplémentaires. En +revanche, elles ne sont pas installées dans le d'Alembert. +C'est l'occasion d'en remettre, car les bornes du d'Alembert n'ont pas été +changées (anciens modèles). +De plus, on commence à avoir des demandes d'élèves du dpt EEA. + +Il faut cependant l'accord de la DSI pour diffuser le réseau, donc il faudra +préciser dans le dossier de CNS Conseil que la couverture WiFi sera réalisée +avec l'accord de la DSI. + +### QRCode (Gala) + +Il faut faire le site. Deadline : 15 juillet. Histoire que le staff Gala puisse +le tester avant les vacances. + +### Séminaires 14-15 + +Remarques sur les séminaires de l'an passé : peu de motivation à l'organisation +des séminaires. Il faut que les nounous motivent davantage leurs apprentis. On +met à jour en live la liste des apprentis avec leur encadrants. Avis aux +nounous qui se sont vues affectées des apprentis ! + +Il faut que les gens qui n'ont pas encore uploadé leur slides pensent à le +faire ASAP. +Il faudrait que les nounous fassent/fignolent leurs séminaires +classés "nounou", qu'elles puissent ainsi à partir de la rentrée se concentrer +sur l'encadrement de +séminaires apprentis. + +Pauline n'est pas là, mais voici un début de programme de séminaires pour +l'année prochaine : +[La liste des séminaires (faits ou à +faire)](CransTechnique/CransApprentis/SeminairesTechniques/2013-2014#Contenu_des_s.2BAOk-minaires) diff --git a/compte_rendus/2014_06_19.md b/compte_rendus/2014_06_19.md new file mode 100644 index 0000000..4d5a83f --- /dev/null +++ b/compte_rendus/2014_06_19.md @@ -0,0 +1,118 @@ +# Réunion inter-nounous + +* Date : Jeudi 19 juin 2014 +* Lieu : Pavillon des Jardins +* Début : 19h52 +* Fin : 21h10 + +## Présents + +* Adam Heriban +* Daniel Stan +* Nicolas Dandrimont (arrivé à 20h10) +* Pierre-Elliott Bécue (arrivé à 20h20) +* Vincent Le Gallic + +## Ordre du jour + +### Internet pour admissibles + +Pour le PR, le vlan n'est toujours pas présent sur la prise. On va mettre un +switch dlink à disposition du BDE. La DSI a dit s'occuper du vlan demain matin, +sinon on leur fournira un NAT via une machine sur le vlan3 (qui lui est +présent). + +Il faudra qu'on discute de ça à la réunion DSI, qu'on ait un fonctionnement +plus efficace à l'avenir. + +On se propose d'enregistrer des machines WiFi temporaires pour les admissibles, +à l'aide de la fonctionnalité de MAC `` qui remplit automatiquement +la MAC d'une machine à la première connexion avec le +bon '''login'''/mdp. À voir sur quel compte on enregistre ça. +On propose le compte du BDE (il faudrait leur en parler (en cas de déco, c'est +le BDE qui prend)) ou un compte dédié pour ça. + +Daniel a commencé un script pour inscrire à la volée N machines (avec N grand), +on imprimerait alors plein de logins/mdp pour les filer aux admissibles. +Toutes les semaines, on supprime les machines et on recommence. + +### Comptage d'upload + +PEB a commencé à configurer pmacct sur le nouveau routeur, en stockant dans une +base +pgsql locale. + +* Le schéma est un peu modifié, donc les scripts de déco/stats/analyse doivent + être réécrits. +* On loggue tout ce qui passe sur l'interface crans. + * On a les MACs '''et''' les IPs. + * On compte pour la déconnexion pour upload le traffic qui sort du /16 de + l'ENS. +* Comme on a l'info mac '''et''' IP, on peut émuler le filtrage mac-ip. +* Comme on a l'info mac, plus besoin de correspondance EUI64<->Extension de vie + privée en IPv6. + +On va probablement mettre deux trois filtres pcap pour alléger la base du +traffic interne +(wifi <->filaire, ça passe par komaz). + +Problème : les cas "bâtards" de machines ayant plusieurs entrées dans la base +ldap +avec la même adresse MAC. + +On envisage d'utiliser ce système pour conserver l'historique du parefeu, +plutôt que d'utiliser +le target LOG d'iptables. Cela diminuerait la taille occupée par les logs du +parefeu, car on +aurait des infos agrégées sur 1 min. + +### Logs centralisés + +Quand l'étape précédente sera terminée, on aura un peu plus de place sur thot. +PEB envisage +d'installer une base elasticsearch avec logstash pour stocker les logs +centralisés. + +On ne sait pas encore combien de place ça va prendre. ''A priori'', plus de +place (x2) que des logs +textes. + +### Màj du Firewall + +Un peu plus de paramètres dans config.py et une fonction pour mettre à jour le +test +mac-ip incrémentalement. + +Il faudrait recoder un parefeu IPv6, pour régler ces problèmes de màj, et +éventuellement en +profiter pour en faire un parefeu IPv4-v6 unique. + +### Civet de lapin + +Sur toutes les machines, un démon : trigger.py qui importe (depuis config) les +services gérés +par la machine courante. + +Scénario typique : + +* Quand le binding ldap modifie un objet, il envoie un message avec une clé de + routage « trigger.event » et en donnée le dn, les ldiff avant et après + modification. +* Civet reçoit le message, il compare les deux ldiff et dispatche sur un + échangeur dédié à un service donné (clé de routage spécifique). + +Si plusieurs serveurs implantent le même service, ils possèdent chacun leur +file d'attente +qui s'associe à l'échangeur. + +### Réunion DSI + +Vendredi 27 juin à 16h. + +### Babar + +Il atteint ses limites. PE regarde pour augmenter l'espacement des sauvegardes +des +serveurs ayant des services similaires. On se renseigne en parallèle des +solutions +alternatives (NAS, solution proprio… ?). diff --git a/compte_rendus/2014_07_03.md b/compte_rendus/2014_07_03.md new file mode 100644 index 0000000..b169706 --- /dev/null +++ b/compte_rendus/2014_07_03.md @@ -0,0 +1,210 @@ +# Réunion inter-nounous + +* Date : Jeudi 3 juillet 2014 +* Lieu : Pavillon des Jardins +* Début : 18h47 +* Fin : 20h30 + +## Présents + +* Anne Cazalet +* Daniel Stan +* Nicolas Dandrimont +* Olivier Iffrig +* Stéphane Glondu +* Vincent Le Gallic +* Pierre-Elliott Bécue +* Pauline Pommeret +* Kévin Moisy-Mabille + +## Ordre du jour + +### Comptage d'upload + +Pierre-Elliott a refondu le comptage de l'upload à base de pmacct. +C'est maintenant envoyé au nouveau routeur{{{odlyd^Wkomaz2}}} (pas encore en +prod au niveau routage). + +Niveau consommation de ressources, le load average est passé de 2 à 0.5. +Maintenant qu'on a atteint +la durée de rotate (5 jours), la base fait 90Go. + +* {{{deconnexion.py}}} (= punir les méchants) a été adapté, il s'exécute ~aussi + rapidement +* {{{analyse.py}}} (= voir combien les méchants ont uploadé et vers où) a été + recodé, on peut + +maintenant demander l'upload par '''adhérent'''. + +{{{#!wiki tip +analyse.py est lancé automatiquement à chaque fois que quelqu'un se fait +déconnecter. Les résultats atterrisent +dans `/usr/scripts/var/analyse/AAAA_MM_JJ_HH_MM_SS_(aid|cid)_.txt` +}}} + +### Réunion avec la DSI + +Lundi dernier, Pierre-Elliott, Jordan et Daniel ont rencontré la DSI en les +personnes de Stuart !McLellan, +Jocelyn Viallon et Vivien Frenot. + +#### Saclay + +On leur a parlé de là où on en est pour le fameux "dossier Saclay", qui est en +cours de rédaction, de ce qu'on est prêt à faire. + +Nous, on préfèrerais continuer à collaborer avec eux, sachant qu'on est prêt à +faire autrement si besoin. +Ils sont aussi d'avis de continuer à travailler main dans la main, parce qu'ils +pensent que l'école se doit de +fournir l'accès Internet à ses étudiants, mais préfèrent que ce ne soit pas à +eux de s'en occuper. +Stuart pense qu'on est plus efficace et qu'on coûte moins cher qu'un +prestataire privé. + +De notre côté, on aimerait que l'école supporte notre projet sur la scène de +Saclay. +Il '''''faut''''' terminer le dossier, qu'il soit tout beau tout propre et +pensé en collaboration avec les autres +assos (notamment Aurore). Pierre-Elliott et Ariane ont bien avancé, mais il y a +encore beaucoup de travail. + +Anne Cazalet est prête à nous faire un/des devis pour une grosse quantité de +matériel, +pour qu'on puisse dire dans le dossier "regardez, on sait combien ça nous +coûtera". +On la recontactera dès qu'on aura une idée des quantités (une fois qu'on aura +fait notre inventaire). + +Stuart a parlé de nous au directeur de la DSI de la FCS (Fédération de +Coopération Scientifique) +François de Castelbajac, destiné à piloter les projets des DSI des différentes +écoles/labo du projet Saclay. + +Dossier à envoyer d'ici la fin du week-end. + +#### Comptage d'upload et débit en journée + +Un point a été fait sur les limitations. + +Pour le débit en journée, ils ont peur de plomber les visoconférences dont les +départements ont besoin. +On utilise actuellement 100Mbit/s sur le 1Gb/s que l'école a. + +En journée, on a négocié 150Mbit/s, pour voir ce que ça donne. +En soirée, on reste à 500 (ça ne sature pas). + +Pour la limitation d'upload, ce qui les gêne surtout, c'est l'image de l'école +vis à vis des téléchargement illicites, +surtout quand les mails viennent du CERT de Renater. +Ils sont contents parce qu'ils reçoivent moins de mails d'ayant droits, Nicolas +pense que Renater +les {{{> /dev/null}}}. + +Du coup, on passe la limite d'upload à 8Gio/24h, histoire que ce soit quand +même pas complètement open, +notamment à cause des gens qui uploadent sans trop le savoir (virus, cacaoweb +for the win). +Point de vue implémentation, y'a rien à faire de plus, Pierre-Elliott l'a déjà +modifié dans le pare-feu. + +La DSI est intéressée par nos solutions de qos (tc sous linux) pour +leurs "problèmes" de visioconf. + +#### Miroir Debian / IPv6 + +L'ENS est toujours intéressée par l'idée d'un miroir Debian commun. + +En revanche, l'IPv6 est quasiment obligatoire pour apparaître dans cette liste. +Pour l'instant, ça coince au niveau +du matériel du réseau de collecte (Rubis). De notre côté, on propose d'acheter +une machine plus +puissante et/ou laisser tomber le RAID 5 logiciel actuellement en place. + +#### Ports + +Sur le firewall, on bloque par défaut les ports des machines des adhérents en +entrée. +La DSI ne le savait pas, mais trouve que c'est une bonne idée (on protège des +adhérents qui ont l'habitude d'avoir une box entre eux et le monde). + +Ils ne voient aucun inconvénient à ce qu'on ouvre des ports quand ça nous +chante, même sans les prévenir, mais ils apprécient beaucoup qu'on les +prévienne. +Donc on va continuer à le faire, parce que ça nous coûte pas grand chose, que +c'est toujours cool de faire plaisir à la DSI pour pas cher, et que ça +responsabilise un peu l'ouverture d'un port. + +### Filtrage mails + +C'est un projet à plus long terme pour le filtrage des spams. On réinstallerait +amavis sur tous les MX +sans utiliser les fonctions de filtrage virus. On activerait le filtrage de +spam assassin. L'idée serait +ensuite d'utiliser les fonctions de quarantaine pour n'envoyer qu'un seul mail +par jours pour tous +les mails étiquettés "spam" en attente de modération. + +Voir du côté de Maia Mailguard. Avis à apprenti intéressé, contacter PEB. + +### Disque de nols + +Un disque de nols (notre baie de disques) de 600Go nous a lâché. +Il y avait deux disques de remplacement qui attendaient de prendre sa place, +donc pour l'instant, pas d'interruption de service. + +Anne nous a envoyé un numéro de téléphone à contacter pour faire valoir la +garantie. + +Il nous manque certains numéros de +série (cf [[CatégorieCrans/LesServeurs|ci]]), on va voir avec Anne pour les +récupérer. +Il est possible qu'on ait besoin des numéros de séries des '''contrôleurs'''. + +### Migration des homes + +En été, c'est là que les adhérents se servent le moins de leurs home. Les +migrer nécessite une interruption de service. + +Plus de place, plus +compartimenté ([[CransTechnique/PanthéonServeurs/ServeurBabar|babar]] nous +remercie), +ce sera cool, mais la copie de tout ça va prendre plusieurs heures. + +Il va falloir qu'on fasse des choses sioux parce +que {{{/home/a/ablabla}}} risque d'être le nouveau chemin +pour {{{/home/ablabla}}}. + +Pas encore de date fixée, mais avant la rentrée. + +### Machines virtuelles pour les clubs/l'événementiel + +On a des demandes (pot vieux, Gala) pour une machine virtuelle. On peut déjà +allouer de la place sur l'ancien +stockage. + +Si ce crash-test se passe bien, on considérera toute demande de virtualisation +de la part d'autres clubs. +Penser à rappeler que : + +* on se garde le droit de refuser une vm pour cause d'utilisation de ressources + ou d'usage illicite +* les nounous restent virtuellement root sur la machine hébergée, l'accès sans + accord leur restant moralement et légalement interdit + +Il faut avancer le projet Gala (mi-juillet). + +### Imprimante + +Discussion avec Anne sur ce que proposerait HP en termes de contrats de +maintenance, et de +« l'engagement » de XeroX. + +Laser Jet Enterprise Flow M800 series + +Extensions de garantie: + +* 4h +* Le lendemain + +## Il est 20h. Paris s'éveille (or something). Sergio nous attend il fait faim. diff --git a/compte_rendus/2014_09_11.md b/compte_rendus/2014_09_11.md new file mode 100644 index 0000000..0573b38 --- /dev/null +++ b/compte_rendus/2014_09_11.md @@ -0,0 +1,172 @@ +# Réunion du collège technique + +* Date : Jeudi 11 septembre +* Lieu : Salle de conférence du Pavillon des Jardins +* Début : 19h00 +* Fin : 21h01 + +## Présents + +* Clément Ringeade +* Daniel Stan +* Jordan Delorme +* William Babonnaud +* Myriam Begel +* Glen Mével +* Adam Heriban +* Colisson Léo (alias !TobiasBora) +* Pierre-Elliott Bécue +* Raphaël-David Lasseri +* Germain Haessig +* Florian Marconi + +## Ordre du jour + +### Migration routeur et homes + +On a migré le routeur et les homes vers une nouvelle grappe de disques (des +disques de 2To au lieu des 600Go). On a ensuite permuté les disques pour mettre +les 2To dans la baie encore garantie ({{{nols}}}). Malheureusement, cela a +entraîné une perte de données (problèmes de disques ayant le même identifiant, +probablement), et les disques arrivants ont été squeezés. Il a fallu +recommencer la copie de données, mais rien n'a été perdu. + +Il faut tester le système de secours (quand le réseau du crans tombe, il faut +faire en sorte que le serveur titanic ouvre son tunnel vpn vers ovh pour +assurer une connectivité entre le serveur et le réseau du Crans). Glen est +volontaire pour jouer avec le vpn (encadré par Daniel.) + +Quota : à refaire. Pour l'instant, tout le monde peut utiliser autant d'espace +qu'il le veut. Il devrait être limité à 10Go. Léo Colisson se propose pour le +faire. + +### Nouvelle imprimante + +Elle est au 4J et elle marche ! +Toutefois les impressions WEI l'ont laissé exsangue, presque à court de toner +et de tambour. Le contrat SPS a été signé mercredi. Pas de nouvelle pour +l'instant. +On espère recevoir un toner pour mardi. + +Pour l'instant, le binding avec l'intranet n'est pas prêt (mais presque). Le +soucis, c'est que pour l'instant, il semble falloir installer le driver sur le +serveur qui +lance l'impression (même en partage d'imprimante cups). Soit on essaie de +trouver un paquet hplip venant de Jessie, soit on installe la lib à la main sur +o2 (serveur de l'intranet2) ce qui nécessite de finir l'application +d'impression sur l'intranet2. On verra ça ce week-end. + +Pour l'instant, on ne comprend pas le snmp de cette imprimante. Vincent G. a +commencé à parser la page d'administration pour récupérer les infos +pertinentes. On écrira un plugin munin à partir de ça. + +Il faut également réécrire le script de notification de fin d'impression. +William est volontaire. + +Il nous manque une fonctionnalité de couverture (piochée depuis un autre +bac) pour la Sauce. Le seul driver supportant cette fonction (à notre +connaissance) est dispo +sur Windows® (sic), et en recto simple. On peut soit créer une VM sous +Windows®, soit on leur file une vieille machine sous Windows®… + +### Serveur de backup + +Anne propose un devis de 4020 € TTC, Pierre +Elliott regarde pour un serveur acheté ailleurs en sachant que l'avantage +principal d'HP serait le care pack garantissant l'intervention ou le +remplacement dans les 24h. +Il faudra demander au CA de voter un budget pour un "simple" ordi à monter si +ça ne suffit pas on avisera pour une solution pro. + +### Ft's powerup + +Devis de ~1100 pour un deuxième Xeon 6cœur + 8Go de RAM. A priori, on les +prendra. + +### OwnCloud + +Raphaël fait une démo à partir de la machine virtuelle qu'il vient d'installer. + +Où stocker les données d'un utilisateur : + +* Un espace à part (sur la vm) +* Le home de l'adhérent +* Un sous-dossier du home de l'adhérent + +Vu les contraintes (dossier qui doit être accessible en écriture par un groupe +spécifique), on s'oriente vers le partage d'un sous-dossier de l'espace perso +d'un adhérent. + +-- Il y a un petit hack qui consiste à monter le home de l'adhérent en tant + que "Stockage externe" dans owncloud pour s'affranchir des problèmes de + droit (www-data qui ne peut pas écrire en tant que l'adhérent), c'est de la + théorie, je ne sais pas si ça marche en pratique + +### Sanction upload + +La limitation pour upload ne reconnecte plus automatiquement l'adhérent +après 24h : désormais, il faut cliquer sur un lien qui renvoie vers une +application de l'intranet2, pour confirmer que les programmes consommateurs en +upload ont été réglés correctement. +Tout ceci dans un but de responsabilisation. En cas de clic après les 24h, la +personne est reconnectée immédiatement. Pour l'instant, peu de clic et aucune +plainte, l'upload des personnes sanctionnées n'a pas l'air de leur manquer. + +L'appli est modulaire et tout le monde est invité à coder d'autres +modules (chambres invalides etc.) + +### Bilan (technique) de la rentrée + +Adhésions glissantes : ça s'est bien passé (globalement). Il manque des +fonctions pour afficher les factures en détail. +Il faut pouvoir enregistrer une réadhésion à partir de la date de fin +d'adhésion. + +Enregistrement des mac : ça marche plutôt bien, modulo des problèmes liés à des +collisions de mid (sic) vive les locks ! + +Ticketteuse : Sur {{{oie}}} à la Kfet, marche bien (modulo présence de +rouleau…) elle permet d'imprimer des tickets avec les mots de passes des +machines wifi de l'adhérent, mais aussi de générer et imprimer un mot de passe +pour le compte crans de l'adhérent. + +* Il faut defucker le script de mails de bienvenue. +* Faire un mail-all de réadhésion et imaginer une solution plus pérenne à + partir de l'année prochaine. +* Générer des liens pour les réponses aux mails de déménagements non déclarés + +### Pont(s) WiFi + +On tire un câble du 0B au 6B pour réalimenter la borne WiFi du faux plafond. +Son câble étant utilisé par le pont WiFi. +Si cela n'a pas lieu, on rebranchera l'ancienne borne du 6B pour les adhérents +du dernier étage (le WiFi a été reporté +comme instable à cet étage, la borne étant éteinte). +Il faut aussi finaliser la configuration du pont WiFi, avec un truc propre. + +Pour Arpej/Volti, il faut s'occuper de remettre la borne en service en haut du +d'Alembert, contacter la DSI et STL (pour l'accès). + +### Install Party Campus + +PEB propose une Install Party (coté campus) le 20 Septembre. + +### Prochains séminaires/ateliers + +Mardi prochain, on fera un séminaire pour les câbleurs. Remplissons le planning +des prochains jours + + +### Questions diverses + +#### SageMath + +C'est une bibliothèque (☺) Python orientée calcul formel. Il faut réfléchir, +toutefois c'est assez gourmand en ressources. +À tester sur une vm. + +#### Switch Krobot + +Germain demande s'il est possible de récupérer un switch pour le Krobot, le +leur fait trop de bruit. +Il s'occupe de faire valoir les garanties de ces switchs. diff --git a/compte_rendus/2014_09_25.md b/compte_rendus/2014_09_25.md new file mode 100644 index 0000000..8812bc4 --- /dev/null +++ b/compte_rendus/2014_09_25.md @@ -0,0 +1,32 @@ +# Réunion du collège technique + +* Date : Jeudi 25 septembre +* Lieu : Salle de conférence du Pavillon des Jardins +* Début : 19h00 +* Fin : + +## Présents + +## Ordre du jour + +### Perte de perf sur ft + +### Service d'impression + +## Des rendus qui marchent bof, des blocages idiots + +## pleins de solutions + +### Serveur de backup + +### OwnCloud + +### WiFi + +## On s'est remotivé pour poser des bornes, alors autant continuer ! + +### Prochains séminaires/ateliers + +## Quid de mardi prochain ? + +### Questions diverses diff --git a/compte_rendus/2014_10_09.md b/compte_rendus/2014_10_09.md new file mode 100644 index 0000000..7dbce4c --- /dev/null +++ b/compte_rendus/2014_10_09.md @@ -0,0 +1,112 @@ +# Réunion du Collège Technique + +* Date : Jeudi 9 octobre 2014 +* Lieu : Pavillon Des Jardins +* Début : 19h15 +* Fin : 20h30 + +## Présents + +* Nicolas Dandrimont +* Thomas Blanc +* William Babonnaud +* Emmanuel Arrighi +* Gabriel Detraz +* Myriam Begel +* Julien Christophe +* Raphael Lasseri +* Pierre Elliot Bécue +* Daniel Stan +* Jordan Delorme (arrivée 19h35) + +## Ordre du jour + +### Soirée Crans + +Côté anim, Raphaël David proposait d'utiliser les spare bornes WiFi, surtout en +utilisant les leds. Le but +serait de coder un petit jeu qui utiliserait les leds. Avis aux volontaires. +Il y a aussi un jungle speed fait maison (par Aurore). + +De son côté, le krobot fait une démo : le robot arrive à lancer des balles. + +### Câblage WiFi au M + +Câblage ce samedi aprem', rdv à la fin du petit dej' à la Kfet (vers 14h30). + +### Contact avec les adhérents + +Selon Thomas, nounou@ serait assimilé à une ML privée, ainsi que ca@ (pour le +bureau). De notre point de vue, +on peut envisager de renommer nounou pour affirmer son caractère public, et +rediriger le mail nounou@ vers +la ML roots@ (apprentis et nounous seuls sont abonnés). +Nicolas soulève l'avantage de l'entraide sur une ML publique. +Vu le bruit sur roots@, on laisse en l'état pour le moment, mais on rappelle +aux modérateurs de ne pas laisser passer de données privées (rediriger ces +mails sur une ML privée.) + +Mails de disconnect : + +* Le nom de la ml : on propose "avertissement" en tant qu'expéditeur des mails + auto (alias). +* Le contenu du mail : il commence par les sanctions, se répète et se veut + agressif. + +Thomas veut bien réécrire cela (et apprendre à utiliser git au passage) et +jettera un œil aux autres mails du dossier. + +### Impression + +On met en prod le script de notification d'impression terminée ce soir. + +Ce qui reste à faire : + +* une interface sur l'intranet 2 (Julien est partant pour faire du django) +* il faut écrire un driver en pcl (beaucoup de plaintes au sujet de plantages + avec le driver hp…). + +### Gala + +Si ça vous intéresse de faire du django, feel free to join. + +### Renouvellement de garanties + +Trois devis de renouvellement (1 an chacun) pour : + +* fz : on prend (c'est un serveur vital) +* babar : pas la peine (les disques durs ne sont pas compris dans la garantie) +* fy (munin) : on prend, ça sert toujours + +On proposera donc les deux devis intéressants au CA. + +### Monitoring + +Rappel sur l'existence de munin.crans.org et autostatus.crans.org et le +nettoyage à faire par les nounous. + +### Permutation séminaires/CA/IN + +Superposition: No. +On fait un Doo^W framadate pour demander aux apprentis ce qu'ils en pensent. + +### Prochains séminaires + +Mardi prochain : séminaire Debian par Nicolas. + +### Questions diverses + +#### Pont WiFi + +Sous réserve que la déclaration à l'ARCEP avance, pas de problème du point de +vue technique, un câble est présent en plus. On verra pour faire une commande +groupée de borne. On pense commander des nanobeam M5 (qui ont l'air d'être une +évolution des nanoM5 utilisées actuellement.) + + + +#### Comptes inactifs + +Raphaël se lance dans la réécriture de gestion des comptes inactifs. Il propose +un effacement des anciens comptes au bout de 3 avertissements, mensuels. +À suivre. diff --git a/compte_rendus/2014_10_23.md b/compte_rendus/2014_10_23.md new file mode 100644 index 0000000..ec8bd33 --- /dev/null +++ b/compte_rendus/2014_10_23.md @@ -0,0 +1,131 @@ +# 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 (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. diff --git a/compte_rendus/2014_11_06.md b/compte_rendus/2014_11_06.md new file mode 100644 index 0000000..f12256c --- /dev/null +++ b/compte_rendus/2014_11_06.md @@ -0,0 +1,150 @@ +# Réunion du Collège Technique + +* Date : Jeudi 6 novembre 2014 +* Lieu : Pavillon Des Jardins +* Début : 19h00 +* Fin : 20h22 + +## Présents + +* Myriam Bégel +* Gabriel Detraz +* Daniel Stan +* Raphael David Lasseri + +## Ordre du jour + +### État du 2B + +L'expertise du collège technique a été requise sur la question de +l'accumulation des déchets dans la poubelle du 2B. Les nounous +confirment : celle-ci est pleine à craquer et un ménage imminent du 2B est +nécessaire. +(no comment.) + +### Système d'impression + +Pour résumer : + +* La vm "cups" a été créée, elle tourne mais pas encore de configuration du + tout dessus +* Le driver pcl est en cours d'écriture, Daniel fournira un draft qui + implémentera 1/2 options et laissera les autres implémentations aux apprentis +* Le script de notification fonctionne \o/ + +À faire : + +* Bcfg2 +* Installer cups +* Finir le driver +* Un script de recrédit pour les jobs foirés (avec mail de notification pour + cela) + +### Environnement de test des scripts + +Daniel a commencé a modifié /usr/scripts pour permettre au dépôt d'être cloné +ailleurs que dans /usr/scripts +et utilisé depuis un autre dossier. Le script indiqué dans le shabang se charge +également d'indiquer +quelques variables d'environnement pour passer en mode test. Work in progress, +mais il veut bien +des feedbacks. + +Tout cela sera résumé sur + + +### Màj d'OpenWrt + +La nouvelle version d'!OpenWrt est sortie en juillet (Barrier Breaker), Daniel +suggère de recommencer +from scratch pour voir ce qu'on garde comme modification par rapport à +upstream, et repartir sur des +bases saines. + +* Rendre la borne manageable en ipv6 (idéalement, virer l'ipv4 complètement) +* Multicast (il paraît que ça marche mieux cf changelog) +* Vlans Dynamiques (il faut voir si ça marche mieux) + +On va bientôt avoir de nouvelles bornes (a priori) pour pouvoir commencer des +tests. Avis aux volontaires. +On va également remplacer une petite picostation d'un bâtiment pour faire +cobaye, on la remplacera +par une unifi (qui est moins robuste aux tests intensifs). + +### "Modems" Wifi d'appoint + +Il est envisagé de déployer des points wifi secondaires chez l'adhérent. Le +principe est simple : l'adhérent +reçoit contre caution une borne flashée par nos soins, dans le but de servir de +point d'accès Wifi, +et éventuellement filaire. +Ce point se comporte comme une borne classique, le principe étant que +l'adhérent et ses voisins puissent +s'y connecter. Le but étant que ce soit le plus transparent possible. Cela +résoudrait en partie le problème +des zones blanches de couverture wifi. + +Cependant, il n'est pas encore établi si la désactivation de radius est +nécessaire pour faire passer le vlan +adh non tagué et le vlan 3 tagué en direction de la chambre de l'adhérent, +l'idéal étant que ça ne le soit pas. +D'autres détails, tels que la présence du mot de passe en clair dans la conf +des bornes méritent l'attention. + +### Questions diverses + +#### Un point sur le nouveau script de comptes inactifs + +Ça buggue, ça buggue, ça buggue. Il faut discuter des délais avant suppression +du compte. On demandera (en partie) +au CA. Il est envisagé une suppression auto au bout d'un an d'inactivité (après +envoi de 4 messages). + +#### Serveur de backup + +PEB propose ceci : + +{{{ + +## Carte mère + +* ou + + * ~ 150 € à ~ 200 € + +## RAM + +* +* ~100 € + +## Processeur + +Haswell + +* +* ~200 € + +## Boîtier + +* +* ~150 € + +## Disques Durs + +1 disque pour l'OS (je propose SSD) et 6 HDD (2 To, 7.2krpm) pour les backups + Suggestion : + (moins cher des 7200RPM)) + +* HDD : +* ~ 800 € +* SSD : +* ~ 100 € + +## Budget + +Environ 1 600 €. Les prix étant indiqués sur montgallet, il faut compter une +marge de 10%, donc ~1800 €. +}}} + +On se demande l'intérêt d'un ssd pour l'OS. Mais why not. Un peu plus d'info +sur le setup ne serait pas de refus. diff --git a/compte_rendus/2014_11_20.md b/compte_rendus/2014_11_20.md new file mode 100644 index 0000000..9d767b9 --- /dev/null +++ b/compte_rendus/2014_11_20.md @@ -0,0 +1,151 @@ +# Réunion du Collège Technique + +* Date : Jeudi 20 novembre 2014 +* Lieu : Pavillon Des Jardins +* Début : 19h16 +* Fin : 20h21 + +## Présents + +* Daniel Stan +* Gabriel Detraz +* Pierre-Elliott Bécue +* Nicolas Dandrimont +* Raphaël-David Lasseri +* Thomas Epalle +* Vincent Le Gallic + +## Ordre du jour + +### Récapitulatif du matériel vacant + +L'association grifon nous a contacté le 17/11/2014 afin de savoir si elle +pouvait récupérer une partie de notre +matériel réseau inutilisé à savoir 2~3 switchs procurve et un serveur (un vieux +dell). PE avait soulevé le +problème de turn-over sur le matériel. Il voulait aussi conserver un serveur +pour faire des tests. + +Au niveau serveur, on a 4 (ou 5?) serveurs dell sous les bras, on peut +facilement s'en débarrasser d'un. + +Pour les switchs, tous nos spares sont faulty, il faut faire jouer la garantie, +remplacer les faulty présents dans +les bâtiments, puis refaire jouer la garantie. On aurait alors 5 switchs +hp "neufs", il faut faire un inventaire +complet d'abord, mais sur le principe nous sommes d'accord pour céder deux +switchs (un 26 ports et un 48 ?). + +Il faudra en profiter aussi profiter du changement d'un switch pour passer +l'aspirateur dans le local et +ainsi éviter que les switchs s'encrassent trop vite (c'est a priori le problème +actuel.) + +### WiFi + +#### Mise à jour vers BB + +Gabriel, Lucas et Daniel ont commencé à adapter les modifications Crans sur la +nouvelle version +d'!OpenWrt. + +* Nouvelle clé ssh (sur fy, /etc/crans/secrets/ parce que /usr/scripts/gestion + c'était nul) +* Vlan dynamiques : ça buggue toujours autant (à investiguer) +* Management en Ipv6 + +Pour ce dernier point, on a créé un préfixe (ULA), un slash d'ip locale +probablement globalement +unique: fd:a8:5d34:a228/48, annoncé par odlyd. + +Détails : + +* fd : préfixe pour les IPs "ULA" +* a8:5d34:a228 : tiré aléatoirement une fois pour ce réseau WiFi +* c04 : mid de la machine qui route (3074 = odlyd.wifi), pour suivre la même + convention que nos /48 publics. + -> ça donne un /64 dans lequel sont toutes les bornes (et les machines Wifi, + par effet de bord. Elle s'en servent pas, vu qu'elles savent qu'il n'y a pas + Internet derrière). + +Les bornes et machines prennent une IP supplémentaire dans ce /64. Pour les +services, on a une IP canonique +pour éviter de changer la configuration en cas de changement de machine. + +* eap: fda8:5d34:a228:c04:7261:6469:7573:3031 (les 64 derniers bits + codent "radius01") +* pea: fda8:5d34:a228:c04:7261:6469:7573:3032 ("radius02") +* thot: fda8:5d34:a228:c04:7379:736c:6f67:3031 ("syslog01") + +Il y a des prob avec syslog qui marche de temps en temps (pour l'envoi vers +thot), tester avec rsyslog. Il +reste à faire des tests, bcfg2 sur les serveurs, firewall v6. + +#### Nouvelles bornes + +Les uap pro sont en test, pour l'instant, il se passe des trucs étranges avec +openwrt. +(pertes de paquets ? load balancing foireux entre les deux fréquences ?) + +Ràs sur les unifi standard, sinon les couleurs des leds qui +changent (inacceptable !) + +#### Point sur les bornes du d'Alembert + +On a notre réponse: deux bornes brassées sur notre switch (dlink) au d'Alembert +centre. Il faut envisager +de remplacer le dlink par un manageable. On verra pour les demandes de +couverture en particulier, +à part le Villon (Point rencontre, etc), on n'a peu de (aucune ?) demandes. + +#### Pont(s) + +(Côté administratif, la déclaration du Crans en tant qu'opérateur a bien été +reçue.) +Les intéressés ne sont pas présents. Un mail a été envoyé à la STL pour aller +inspecter les anciennes bornes +du toit du d'Alembert (vers Arpej). Pas de nouvelles pour l'instant. + +#### Management ssh + +Raphaël propose à des apprentis de recoder des bouts de wifi_new avec une lib +ssh : paramiko voir +fabric. Avis aux volontaires. + +#### Freeradius et mdp custom + +Il serait possible d'enregistrer un mdp radius différent sur chaque borne. Il +faudrait coder une +authentification particulière sur freeradius pour cela. Daniel voit comment +faire cela, mais il recrute +un apprenti pour le faire (buzzwords: python, ldap, freeradius). + +### Rabbit Mq (manger du lapin nuit-il au développement du râble ?) + +[interlude explicative] +On réfléchit à une manière d'implanter les dépendances sur les services. + +Idée : faire un séminaire pour expliquer AMQP dans le détail puis discuter de +notre utilisation au Crans. + +### Prochains séminaires + + + +On a booké les séminaires de la semaine prochaine et de la suivante. Avis pour +la suite, PE veut bien parler d'AMQP. + +### OwnCloud + +Php (module pgsql ?) n'aime pas l'ipv6. Il va plus vite maintenant. + +### Questions diverses + +#### Réservation salles + +On s'est aperçus ce soir que notre réservation du PdJ le jeudi soir n'est plus +d'actualité. +Peut-être que quand le CA est passé le Vendredi soir, la réservation du jeudi a +été totalement dropée ? +Il faut voir ça avec la responsable ENS, histoire qu'on se le fasse pas piquer. +On fouette le CA. diff --git a/compte_rendus/2014_12_04.md b/compte_rendus/2014_12_04.md new file mode 100644 index 0000000..50852e1 --- /dev/null +++ b/compte_rendus/2014_12_04.md @@ -0,0 +1,73 @@ +# Réunion du Collège Technique + +* Date : Jeudi 04 décembre 2014 +* Lieu : Pavillon des Jardins +* Début : 19h20 +* Fin : 19h56 + +## Présents + +* Gabriel Détraz +* Raphaël-David Lasseri +* Pierre-Elliott Bécue +* Daniel Stan (20h01) + +## Ordre du jour + +### WiFi + +Gabriel signale que la barre des 80 bornes posées à été franchie. Il compte en +poser encore deux avant les vacances. +Il reste encore quelques problèmes concernant les logs, le fait que la borne +n'ai plus qu'une adresse v6 est mal géré à la fois à l'envoi par la borne +et à l'arrivée par rsyslog... +Daniel regarde. + +### Factures + +PEB apporte quelques précisions concernant les attributs des factures : + +* recuPaiement est censé être modifiable par tous, pour permettre par exemple, + au câbleur de modifier cet attribut (cas d'un adhérent partant sans payer) +* controle : Permet au trésorier de "locker" la facture et de la + valider/devalider. + +### gest_crans_lc + +Valentin à continuer à bosser dessus, toutefois dans l'état le script reste +difficilement accessible à un utilisateur débutant en Python, il faut le +continuer à le proprifier dans les semaines et mois à venir. + +### lc_ldap + +Actuellement, il y a deux fonctions qu'il est intéressant d'appeler avant de +sauvegarder un objet dans la base ldap : + +* validate_change() qu'il s'occupe de maintenir de la cohérence entre les + attributs (rid, ipv6, ipv4, et autre) +* history_gen() qui génère l'historique des modifications + +Il pourrait être bien de les faire appeler par défaut par la méthode save(), +tout en le laissant désactivable au cas par cas : +save(validate_change=False, history_gen=False) comme validate_change semble +idempotente, ça n'est pas grave vis à vis de ceux qui l'appel déjà à la main, +pour history_gen, ça va mettre des lignes en double (modulo la date). +Ce sera fait. + +### Propreté des serveurs + +Il faut proprifier autostatus et munin. (Rapide et simple à faire) +Pour bcfg2 c'est un peu plus risqué. +PEB à commencer à faire du ménage dans /usr/scripts il reste encore plusieurs +scripts à trier. + +### Soyouz + +Soyouz coûte actuellement ~500€ par an chez OVH, le collège technique considère +qu'il est important de garder ce serveur pour l'année à venir. + +### Questions diverses + +### Repas FedeRez + +C'est mardi... diff --git a/compte_rendus/2015_01_08.md b/compte_rendus/2015_01_08.md new file mode 100644 index 0000000..4b09ca4 --- /dev/null +++ b/compte_rendus/2015_01_08.md @@ -0,0 +1,101 @@ +# Réunion du Collège Technique + +* Date : Jeudi 8 janvier 2015 +* Lieu : Pavillon des Jardins +* Début : 19h12 +* Fin : 19h56 + +## Présents + +* Gabriel Détraz +* Raphaël-David Lasseri +* Pierre-Elliott Bécue + +## Ordre du jour + +### Serveur de backups + +Omnomnom est en marche, il backup les homes des adhérents \o/ + +Il reste à lui trouver une place sur le campus. + +Les présents décident de l'installer au 0H, à faire un soir entre deux backups. + +### Mise à jour vers Barrier Breaker (bornes wifi) + +Gabriel rappelle que getlogwifi est maintenant un démon qui sert à ouvrir des +connexions SSH vers toutes les bornes et d'en récupérer les logs. + +Il reste à faire en sorte que ce script renvoie les logs directement vers +rsyslog et non pas dans un fichier (sic) comme c'est le cas actuellement. + +### Bornes Unifi 5Ghz + +Il semblerait que l'attribution d'une IP via une connexion 5GHz soit très +lente… +Il faut investiguer. + +### Kludge des Ipv4 Wifi + +Cf + + +But de la manœuvre : beaucoup (~2000 ?) de machines inscrites en WiFi, avec +souvent des mac restées en `automatique` donc jamais vraiment utilisées. Le +système voulait en revanche que l'ipv4 soit assignée à l'avance, ce qui nous +saturait notre slash ipv4 WiFi. + +Daniel a donc rapidement patché ldap_crans et cie pour autoriser l'absence +d'ipv4 +sur une machine, et fait en sorte que l'ipv4 soit assignée à la première +connexion (dans freeradius), en même temps que la mac. Plus précisément, la +machine n'a pas de champs +ldap "ipHostNumber" ("`automatique`" posait problème), +ni de champ ldap "rid". On assigne un rid valide à la machine, et l'ipv4 est +calculée à partir de là. + +Pour l'instant, ça marche, même s'il ne s'agit pas d'une solution +totalement pérenne. + +Par contre, Daniel est formellement contre l'effacement systématique +de machines +jamais connectées : il pense que cela nous sera bien trop coûteux de déboguer +les connexions WiFi d'adhérents qui essayeront de rentrer des logins qui +n'existent plus. En plus, ça polluera encore l'image du WiFi en tant que +service +"qui marche pas"®©. + +Pierre-Elliott et Raphaël préfèrent détruire les machines WiFi qui restent +inactives pendant +plus de 3 mois quitte à envoyer un mail aux adhérents concernés. + +### Câbleuse 2.1 + +Daniel bidouille une nouvelle version de la câbleuse/ticketteuse à base de rpi +au +format compact (découpé avec amour, à la perceuse, dans une boite de Ferrero), +stay tuned. +Un des objectifs est d'avoir quelque chose de résilient aux pannes de courant +de la Kfet'. +De la doc va venir, aussi. + +### Remarques diverses + +#### Passage à Jessie + +On ne va pas tarder à dist-upgrade il faudra trouver des motivés et annoncer +les mises à jour +des services critiques. + +#### Binding ldap + +Django a un module d'administration ldap (django-ldapdb +). +Ça simplifierait grandement la gestion des attributs et des logs et cela +permettrait surtout d'avoir +un binding maintenu, plus simple à comprendre et plus léger. En plus, on +pourrait facilement adapter +une interface web pour le câblage. + +Aucune urgence mais il serait intéressant de réfléchir un peu à cette piste et +continuer à se renseigner. diff --git a/compte_rendus/2015_01_22.md b/compte_rendus/2015_01_22.md new file mode 100644 index 0000000..74ff58d --- /dev/null +++ b/compte_rendus/2015_01_22.md @@ -0,0 +1,127 @@ +# Réunion du Collège Technique + +* Date : Jeudi 22 janvier 2015 +* Lieu : Pavillon des Jardins +* Début : 19h14 +* Fin : 20h30 + +## Présents + +* Raphaël-David Lasseri +* Emmanuel Arrighi +* William Babonnaud +* Gabriel Detraz +* Hamza Dely +* Daniel Stan +* Gaétan Facchinetti + +## Ordre du jour + +### Préparation de l'Install Party + +* Le Netboot fonctionne-t-il ? Il faut vérifier et sur le vlan évènement et sur + adhérent. +* Possibilité du portage du netboot en efi ? (on essaie ce + soir : ) +* ''A priori'', les distributions disponibles sont à jour. +* Il faut prévoir des clés usb en rab pour les uefi secure boot si jamais on + n'arrive pas à les désactiver. +* Les vlans : a priori ils sont bons et vérifiés en taggued sur toutes les + prises. Les switches ont été configurés et sont ok. + +### Achat de bornes Wifi + +Gabriel propose de racheter deux boites de 3 bornes (Unifi standard). Résumé +des besoins : une pour le bâtiment B, pour remplacement, et 3 autres au M. Le +reste sera dispo pour remplacement, en appoint. + +(Sans les frais de port) + +* IP : 432€ +* landashop : 465€ + +### Omnomnom + +Pierre-Elliott a oublié d'acheter un disque dur de rechange. On propose ça au +CA, avec un ventilo supplémentaire pour la tour (histoire d'être sûr). + +* Disque : 220 € () +* Ventilo : 15 - 20 €. + +### Migration sous barrier breaker + +Petit problème mineur lors de la migration : on a oublié d'activer l'option +d'atheros pour avoir les canaux +spécifique à l'Europe ETSI (canaux 12 et 13). + +On a re-flashé une partie des bornes, mais pas toutes. Celles du G, C, +d'Alembert, H et PDJ ont toutes le firmware patché. + +À voir ce qu'on fait du canal 13, pour l'instant, on l'a mis en test à la +Kfet (lieu de passage de tout +nouveau venu), histoire de faire des tests. + +Bug détecté avec les nouvelles unifi au reboot, moins présent après passage à +barrier breaker, à investiguer. + +### Switches + +On a reçu 3 switches 24 ports et 2 switches 48 ports. Les switches de +remplacement sont des 2620 neufs, du coup c'est cool. Gabriel fera une seconde +session. + +### Coupure électrique + +Le mercredi 21 janvier, la ville a rebooté, le campus aussi. Le CROUS a +souffert au niveau du TGBT (Tableau Général Basse Tension), du coup ça a pris +plus de 45 minutes à revenir, et on a perdu le 0B. + +On s'est rendus compte de deux détails, premièrement, la gestion de l'ISCSI et +du montage des disques des homes sur zbee, ça marche pas. PEB est sur le coup +en utilisant udev et en rajoutant des nofail en option sur le montage des home. +Le deuxième problème est la default via foireuse d'odlyd au boot. Il parle en +utilisant son IP côté ENS, du coup les réponses qui lui sont destinées sont +droppées, aiccu et vpn n'y arrivent pas, du coup. Normalement, une règle +post-up dans interfaces corrige la route. + +/usr/scripts ne s'est pas monté partout, le wiki ne s'est pas bien démarré, et +idem pour l'imapproxy de SOGo. À surveiller, mais le reboot était fait +à la hache, ça n'a sûrement pas aidé. + +Trucs à prévoir pour la prochaine fois : + +* Séquence de coupure automatique annoncée par pulsar +* Retrouver le mdp de pulsar pour accomplir la tâche précédente (sic) +* Vérifier la default route sur odlyd +* Désactiver l'auto-reboot après coupure, sur les serveurs +* Vérifier la signalétique des disjoncteurs (« arrivée onduleur ou pas ? ») +* Les bornes wifi qui ont décidé de snobber radius (un wifi down; wifi up les a + calmé), ainsi que NTP. + +### Kludge kvm + +On compte acheter deux trois adaptateurs +usb-ps2 () compatibles kvm pour dépanner, entre autre +le kvm du 0B, celui du 0H. + +## Questions diverses + +### CransPasswords + +Pierre-Elliott a commencé a modifier la base pour la rendre indépendante de +ssh, et de sudo dans le but de ne plus avoir besoin d'un utilisateur sur le +serveur. + +### Délégation de sous-domaines et machine exté + +On a eu une demande d'adhérent pour inscrire un ndd en .crans.org vers une IP +extérieure, voire déléguer le sous-domaine à l'adhérent. + +Techniquement faisable, mais les binding ne sont pas prévus pour, pour le +moment. On peut : + +* Inscrire des machines (rid spéciales) +* Développer une appli sur l'intranet2 pour cela (pour crans.eu, pour ne pas + mélanger avec crans.org) + +On retient la solution 2, pour tester (django-ldapdb ou pgsql ?) diff --git a/compte_rendus/2015_02_05.md b/compte_rendus/2015_02_05.md new file mode 100644 index 0000000..c418ea9 --- /dev/null +++ b/compte_rendus/2015_02_05.md @@ -0,0 +1,126 @@ +# Réunion du Collège Technique + +* Date : Jeudi 5 février 2015 +* Lieu : Pavillon des Jardins +* Début : 19h07 +* Fin : 20h00 +* Lien vers l'[etherpad + associé](http://pad.crans.org/p/Jeudi5F%C3%A9vrier2015IN) + +## Présents + +* Raphaël-David Lasseri +* Gabriel Detraz +* Myriam Bégel +* Emmanuel Arrighi +* Daniel Stan +* Pierre-Elliott Bécue + +## Ordre du jour + +### Nouveaux switchs 2620 + +Les 3 procurves 2620 ont été installés durant la coupure au PDJ et bâtiment J, +en remplacement de batp-0, 2 et batj-0. +Il faudra mettre à jour la base ldap. L'échange des 3 anciens défectueux a +commencé : ils sont arrivés aujourd'hui. + +Il reste cependant quelques questions : + +* Que dit HP du problème avec le dhcp snooping ? + * Pas encore de réponse, pour le moment on reconfigure sans (et on le remet + à la main une fois le switch booté) +* Gestion des switchs restants + +Au terme des échanges, si on reçoit effectivement des 2620, les switchs +disponibles et fonctionnels seront donc : + +* trois 2620 48 ports ou assimilés envoyés par hp. +* deux 2620 24 ports +* deux 2626 24 ports + +Décision ayant été prise d'envoyer 2 ou 3 switchs à Grifon, on envisage de leur +envoyer un 2626-24 et un 2650-48 ports. + +On pourrait mettre un 2626 au Krobot, le dlink s'y trouvant se comportant de +manière erratique, on peut aussi leur +prêter (sous caution) un des petits TP-Link sur lesquels on bosse en ce moment. +Ce serait l'occasion de finaliser +ce projet. + +Reste la med : on pourrait y mettre soit un 2620-24 (batb-5), soit un petit +switch manageable ou pas, pas trop cher. +Vu qu'un 2620 est déjà installé (batb-5) et qu'il nous en reste plusieurs, on +peut le laisser. + +Manageable : + +* +* + +Non manageable : + +* + +Il y aurait alors deux 2620-48, un 2620-24 et un 2626 pour les install partys +et autres évènements. + +### Bornes au DeVinci + +Gabriel, Alexis et Florian ont fait le tour des bornes avec Cédric Cheveaux +dans le DGM. Deux Wrt54g, les 2 dernières du parc encore actives, ont été +changées. + +Demodocos et Ulysse étaient plantées, elles ont été rebootées. Ce ne sont pas +des bullets, mais d'"anciennes" Pico2. Attention au firmware (et driver +wifi) à utiliser. Pour rappel, il faut utiliser ath5k sur architecture atheros. + +Il reste une dépouille au DGC à récupérer, et une borne à brasser +correctement (polynice.) + +### IPs dynamiques en WiFi + +À l'heure actuelle, il reste 37 IPs wifi disponibles, + 88 IPs de bornes Wifi +qui seront libérées bientôt (fonctionnement en ipv6-only.) +Trop de machines à inscrire en WiFi, et en général, pas besoin d'IP fixe. + +Bilan de ce qu'on a besoin de modifier : + +* Plage de rid dédiés aux machines à IP dynamiques +* Réserver la plage de rid du pool (pour éviter de l'utiliser à autre chose) + * Utiliser l'ancienne plage des bornes +* Modifier parefeu v4 (filtre mac-ip -> filtre mac) +* Rien à faire dans le parefeu v6 (woot) +* Dhcp +* Et du DNS à la volée ? + * Kikooo mais pourquoi pas + * Il y a aura déjà de l'ipv6 dans le ndd + +Le vlan 6 (avec taggage dynamique) a toujours du mal à cohabiter sur les +bornes… (snif) + +### Bilan des dernières coupures de courant + +Les problèmes à l'extinction : + +* Des serveurs avec le mauvais mdp root (réglé) +* Acpi non dispo sur plusieurs vm et machines fixes (c'est mis dans bcfg2) +* Les serveurs non-crans ont pour certaines le même problème (osm, rezosup), + c'est plus problématique car on n'y a pas accès, on contacte les proprio en + question +* Il faut régler pulsar pour lancer des ordres d'extinction, il dispose d'une + fonction d'envoi de trappe snmp +* Faire gaffe à ce qui est ondulé au 2B (sic) + +Au boot : + +* Les machines qui s'allument toutes seules au 0B, mais aussi au 4J (cochon qui + essaie de monter le NFS alors qu'on veut que personne n'y touche…) + * C'est dégueulasse les CR du + crans… -- WikiCandy <> +* Rejoncter la deuxième sortie (sur 3) a provoqué un appel de courant trop + important, ce qui a fait rebooté à nouveau les serveurs +* Le wake-on-lan des serveurs distants (babar et omnomnom) a bien marché + +Il serait aussi préférable d'onduler correctement le 4J, afin de protéger +l'imprimante et le serveur de diffusion des surtensions. diff --git a/compte_rendus/2015_02_19.md b/compte_rendus/2015_02_19.md new file mode 100644 index 0000000..369f6e4 --- /dev/null +++ b/compte_rendus/2015_02_19.md @@ -0,0 +1,105 @@ +# Réunion du Collège Technique + +* Date : Jeudi 19 février 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h08 +* Fin : 19h48 !!!! +* <> + +## Présents + +* Raphaël-David Lasseri +* Gabriel Detraz +* Jordan Delorme +* Daniel Stan +* Hamza Dely + +## Ordre du jour + +### Ponts WiFi + +On a installé le point d'accès 5Ghz vers Arpej, sur le toit du d'Alembert, la +DSI et le STL ont été particulièrement serviable. +Le VLAN3 est diffusé sur le pont. Détaggué à l'arrivée pour brancher le routeur +d'Adam, d'autres points d'accès en réception sont prévus +(avec le protocole !AirMax) côté Arpej. Pour l'instant, ça marche avec un seul. +L'arrivée du pont est censée connecter un point d'accès +WiFi classique, avec point d'accès appartenant au Crans. Il faut +potentiellement se pencher sur l'utilisation de mots de passe +Radius dédiés à ces points d'accès. On pourrait les renseigner dans la base +Ldap, (appel à apprenti(s)). +Côté PDJ, c'est le vlan 1 qui est diffusé, on envisage de remplacer par le 3. + +Il y a plusieurs solutions pour faire passer le vlan adhérent via un tunnel, il +vaut mieux laisser le choix à la discrétion des utilisateurs. + +La STL nous a demandé de protéger les câbles présents sur le toit avec une +gaine. Il faut finir cette installation rapidement ! + +### Routeurs individuels + +Pour le moment, le setup retenu pour les routeurs individuels, est de les +authentifier sur le vlan 1 en non taggué, c'est une nécessité +pour faire marcher la connexion filaire de l'adhérent sans toucher à la conf du +switch (trop lourd). On peut essayer de faire passer +le vlan 3 à travers du pppoe. Ce protocole semble plus léger que du vpn, +supporté par openwrt, et la MTU n'est pas trop réduite (on +pourra activer les jumbo frames au passage…) +On commencera donc à faire des test utilisant PPPoE. + +### Festival de robotique de Cachan + +Odile Malezieux nous a demandé d'évaluer les possibilités d'une couverture +internet du Gymnase à l'occasion du Festival de robotique de Cachan +qui aura visiblement lieu début juin. +Dans l'état actuel la DSI à un dédoubleur tel/eth au niveau du Gymnase. +De notre coté la seule solution semble être l'installation d'un +pont (again \o/) pour couvrir le Gymnase, temporairement. +Du coup il faudrait poser une borne sur le toit du 6B ou du PdJ. +À faire en mai + +### Router Advertisement + +Ramond est installé sur apprentis. Il a déjà chopé une machine qui faisait des +RA. Radius a été patché pour rejeter les machines +ayant une blacklist isolement, tant que le taggage dynamique ne marche pas. + +Le script de déconnexion appelé par ramond place la blacklist directement sur +la machine. Idéalement, il faudrait tester la +fonction qui refresh l'authentification de la chambre (pour forcer la +réallocation de vlan.) + +À continuer/finir… + +### Sanction upload + +Un/des abus de droit pour lever des blacklists pour upload ont été perpétrés +par une Nounou (sniff…) +L'abus de droit étant caractérisé. Il faudrait préciser à l'avenir dans le RI +la définition précise de l'abus de droit. +Toutefois la Nounou en question n'est pas considéré comme "dangereuse" pour +l'association. Par conséquent le Collège Technique ne juge pas nécessaire +de retirer les droits "Nounou" au concerné. +Il est du ressort du CA de décider des suites exactes à donner. + +### Imprimante thermique + +La boite de Ferrero abrite enfin une Raspberry Pi et la jumelle de l'imprimante +thermique. Tout marche, il reste à chiffrer la carte SD. +Raphaël et Hamza s'en occuperont. +Puis direction Kfet. + +### Questions diverses + +#### Suppression des comptes inactifs + +Raphaël s'occupe de finaliser l'histoire des crons simultanés et d'ici une +semaine d'envoyer la première vague de mails. + +### Droits Nounous + +nounous.append(u'Detraz') +Un rappel de bon sens agricole est tenu au récipiendaire. +Longue Vie au Collège Technique (qui vient de prendre un sacré coup de jeune) + +Aou Aou Aou ! diff --git a/compte_rendus/2015_03_05.md b/compte_rendus/2015_03_05.md new file mode 100644 index 0000000..afa2df7 --- /dev/null +++ b/compte_rendus/2015_03_05.md @@ -0,0 +1,105 @@ +# Réunion du Collège Technique + +* Date : Jeudi 5 mars 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h15 +* Fin : 20h10 +* <> + +## Présents + +* Emmanuel Arrighi +* Myriam Begel +* Gabriel Detraz +* Hamza Dely +* Daniel Stan +* Raphaël-David Lasseri +* Nolwenn Bruneel + +## Ordre du jour + +### Miroir ftp + +## En racheter un ? Faire le ménage ? + +Charybde est à 86% (total 3.3To) d'utilisation sur /pubftp et il reste ~200Go +non alloué sur le lvm. Quid des anciennes versions de Debian/Ubuntu ? OpenBSD. +On en rediscute avec l'avis d'autres nounous (les seules présentes étant bien +partantes pour virer BSD et cie…). + +BSD n'est pas un besoin absolu, on pourrait dropper. En revanche la saturation +des disques de Charybde d'un point de vue load est réelle. + +### Rationalisation Radius + +Actuellement, on possède deux serveurs radius pour le filaire : radius et +sable (en backup). +Pour le WiFi, on a eap et pea (en backup, mais backup non fonctionnel, donc +tests). + +L'idée serait de fusionner les services radius WiFi et filaire, en mettant tout +sur deux VM (radius et eap). Un des intérêts est de rationaliser la conf de +sable. + +Le travail sur la gestion dynamique des mots de passe en fonction des +NAS (switchs et bornes) est presque fini. +On prévoit de migrer vers ce système aux alentours du week-end du 14. + +### AMQP + +Trigger n'a pas bougé récemment, si ce n'est que Pierre-Elliott s'est +débarrassé du problème de mail de redirection en confiant cette +fonctionnalité à mailExt. Via gest_crans, ça ne change pas grand chose, sauf +qu'il y a une nouvelle option quand on modifie un adhérent. + +Techniquement, il faut encore que l'on réfléchisse à l'histoire d'enchaînement +des services. '''A priori''' un "gestionnaire d'événements" serait la +façon la plus propre de faire. + +Generate fonctionnant à peu près pour l'instant, on n'est pas dans l'urgence. +Les gens qui veulent mettre de nouveaux services non chaînés en place +peuvent se référer aux DHCP/Firewall qui ont été implantés. + +Côté test, ce serait bien d'avoir une copie disponible quelque part pour tester +les nouveaux services, une fois les premiers mis en place. On va faire +ça sur {{{apprenti}}}. Avis aux volontaires : c'est +dans {{{/usr/scripts/{cmb,gestion/trigger} }}} + +CMB n'a pas besoin d'être modifié '''a priori''', c'est un module de +message-broking très simple. Les tests sont faisables directement sur les +serveurs +fournissant les services, dans la mesure où on pose comme racine /tmp. Il +faudra juste faire la conf à la fin. De toute façon, il vaut mieux contacter +PEB pour en discuter avec lui. + +### etckeeper + +C'est un joli petit programme qui conserve un dépôt git du /etc/. Ça marche +bien sur vo, on continue à l'installer à deux trois autres endroits pour tester. + +### Intranet + +Gabriel et Hamza ont commencé à travailler sur la partie "monCompte" sur +l'intranet2. Reste à migrer : + +* l'impression +* l'affichage des quotas (Hamza) +* Paypal + +Pour ce dernier, on pourrait s'en débarasser et passer à un paiement par +CB ? Également possible : le rechargement par note. Demander au CA ! +( ?) + +### Ticket + +Hamza a fini l'impression des factures (cf git). Il ne reste plus qu'à chiffrer +la carte SD et d'installer la nouvelle câbleuse (oison^W rasputin) à la Kfet ! + +### Ra2.py + +Ramond tourne sur fy, il surveille le réseau (tous les vlans), appelle ra2.py +si besoin est (pose une blackliste). + +### CAS + +Raphaël nous a fait regarder les logs du CAS, on a bien rigolé. diff --git a/compte_rendus/2015_03_19.md b/compte_rendus/2015_03_19.md new file mode 100644 index 0000000..439bd8c --- /dev/null +++ b/compte_rendus/2015_03_19.md @@ -0,0 +1,105 @@ +# Réunion du Collège Technique + +* Date : Jeudi 19 mars 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h08 +* Fin : 20h30 +* <> + +## Présents + +* Myriam Bégel +* Hamza Dely +* Emmanuel Arrighi +* Gabriel Detraz +* Jordan Delorme + +## Ordre du jour + +### Virtualisation et clubs + +Résumé de la situation des virtualiseurs : + +* ft : quasi neuf, 1 an (donc sous garantie), très puissant +* kdell : serveur par free (donc pas sous garantie, ''a priori''), moyen + puissant +* fz: fin de vie, encore 1 an de garantie, moyen puissant++ + +Clairement, on a encore beaucoup de marge. On pourra commencer à envisager le +rachat si fz ne passe plus en garantie en novembre prochain. + +Pour les clubs, le système à base de proxmox est fonctionnel : on peut créer +des groupes et compagnie pour administrer uniquement un sous-ensemble de +machines. La +création d'une vm n'est cependant pas automatique et il faudra faire appel à +une nounou. Comme on ne connaît pas la demande exacte, et qu'il y a +énormément de latitude sur les ressources allouées à une vm (\epsilon -> \huge +beaucoup), il est envisagé de traiter les demandes au cas par cas, lors +d'une IN par exemple. + +### Quota + +Il est suggéré de monter l'espace disque des adhérents à 20Go. Compte tenu de +l'espace disque disponible assez élevé, cette mesure ne conduira pas à un +remplissage des disques dans l'immédiat. + +### Rabbit MQ et environnement de test + +Ça fonctionne avec rasputin (la nouvelle ticketteuse) pour l'environnement de +test. Gabriel a des questions sur le fonctionnement de trigger. + +On va commencer à tester sur une branche de test de lc_ldap, pour envoyer les +messages à apprentis (au lieu de civet) et voir si le parser se comporte bien… + +### Intranet2 + +* Mon compte : ça marche. (Le css est toujours un peu moche, mais ça va + s'arranger) + +Il reste à migrer : + +* Quota (Gabriel est sur le coup) +* Impression +* Pages perso +* Rajouter la création de digicode dans l'intranet2 + +Une fois ceci fait, on pourra se débarrasser de l'intranet et migrer facilement +zamok sur jessie. Il faut se +pencher activement sur le portage de l'intranet2 pour django 1.7, +voire 1.8 (qui ne va pas tarder.) + +Trucs qui cassent (non exhaustif) : + +* manage.py +* l'archi des apps +* settings.py ? + +Bref, ça avance ! + +### Firewalls + +Il y aurait moyen de recoder le pare-feu IPv6 de manière plus intelligente, +notamment en utilisant les ipset mac-based +qui sortent sur le noyau linux de Jessie. À terme on pourrait carrément +fusionner les deux pare-feux (gérer +toutes les Blacklists ensemble, etc.) + +### Festival robotique + +Le 1er festival de robotique de Cachan a lieu dans le gymnase de l'ENS du 1er +au 8 juin. Les organisateurs souhaiteraient pouvoir bénéficier d'une connexion +internet pour une dizaine de personne. +On s'est fait relancer par Odile. + +La DSI ne veut pas nous prêter de l'ethernet, car la seule connexion rj45 est +câblée très particulièrement. Il nous +reste donc les options suivantes : + +* Tirer un câble depuis le DGC (en face) +* Pont WiFi depuis le PdJ (à tester) + +Bref, il faut aller faire du repérage. On verra ça jeudi prochain. + +### IP + +On fixe la Key signing party pour midi. diff --git a/compte_rendus/2015_04_02.md b/compte_rendus/2015_04_02.md new file mode 100644 index 0000000..5efcc22 --- /dev/null +++ b/compte_rendus/2015_04_02.md @@ -0,0 +1,125 @@ +# Réunion du Collège Technique + +* Date : Jeudi 2 avril +* Lieu : Pavillon Des Jardins +* Début : 19h00 +* Fin : 20h43 + +## Présents + +* Daniel Stan +* Gabriel Detraz +* Hamza Dely +* Myriam Begel +* Pierre-Elliott Bécue + +## Ordre du jour + +### Intranet + +Refondre un plugin et faire un copy/paste c'est pas très très compatible. +PEP8 + +De nouvelles apps ont été portées par Gabriel : + +* quota +* mon compte +* pages perso + +Il reste à faire : + +* l'appli d'impression +* paypal (ou pas) + +Pour le moment, on se fixe comme objectif d'avoir une interface +de *lancement* des impressions, à partir des fichiers présents dans le home. On +verra plus tard pour les fonctionnalités plus compliquées. + +Il va falloir vérifier la fonction solde dans lc_ldap (sic). + +Pour paypal, des services de paiement par CB alternatifs existent, par exemple +, à celui qui veut prendre le projet de +choisir… (sous réserve d'accord du CA.) + +### Montage NFS des homes + +Résumé des changements : + +* {{{o2}}} a besoin des homes montés pour accéder aux quotas immédiatement ; +* {{{zamok}}}, {{{dovecot}}}, {{{omnomnom}}} les montent quand ils en ont + besoin (par lettre). + +On peut monter les lettres sur o2 une à une… ça règlera le problème des homes +pas montées pour les quota. (Ça a été fait durant l'IN.) + +### Feduroam + +Principe : proxy radius qui peut rediriger les requêtes de connexion vers un +serveur en fonction d'informations de l'utilisateur. Ici, on redirigerait des +requêtes d'auth vers des serveurs radius d'autres associations (Via, Rézo ?) + +Ça fonctionne, de notre côté. On attend des nouvelles de leur côté. Et il reste +l'histoire de l'allocation de l'IP : pour le moment, les macs des machines ne +sont pas connues, donc même avec adresses IPs dynamiques, il faut laisser +passer la mac dans le parefeu. + +Il faut aussi se pencher sur les questions administratives… +(on va dire que le choix du nom du ssid est … federez) + +### Révision plan adressage + +Des mises à jours de config.py ont été faites pour mieux correspondre à +. + +Pas de nouvelles suggestions pour le moment. + +### Upload + +PEB a mis en place un comptage incrémental pour {{{deconnexion.py}}} (le script +qui compte l'upload, installe les blackliste, et avertit +les adhérents). Pour éviter les dérives, un recomptage est fait tous les +jours (à minuit), même si pour l'instant, la dérive est très faible. + +Bonus : on peut désormais faire afficher le quota d'upload courant par +adhérent. Risques : les adhérents qui veulent +flirter avec la limite. On peut aussi laisser un flou, par exemple, on s'arrête +à 4Go (et plus d'avertissement plus loin.) + +### Alertes SMS + +L'alerte SMS fonctionne, en test sur zamok. Voir la doc + + +Pour l'instant, le script vérifie la présence du mot clé "[SMS]" dans le +subject. + +### Droits vieilles nounous + +PEB est contre leur retrait de droits s'il n'est pas possible de le leur +rendre, et +il ne faut pas oublier qu'en cas de pépin, ça veut aussi dire que ceux qui sont +encore susceptibles d'intervenir ne le pourront plus forcément. + +Le principe est de retirer les droits nounous d'anciens qui ne s'en servent +plus régulièrement. +Pour répondre au point précédent, il est possible de laisser une commande +accessibles (via +un droit spécifique) pour les récupérer en cas de besoin. + +### Questions dîtes "verses" + +#### Bcfg2 + +PEB a commencé à refondre le plugin Bcfg2 écrit par Jérémie. Ça devrait pas +être très long, +ensuite, à moyen terme, faudrait se débarrasser des sucres du plugin. Perso, +ils ne le dérangent +pas trop, et "facilitent" parfois la lecture, mais sont sans doute "dangereux". + +À suivre. + +#### Saclay + +Un dossier est présent dans gitlab, pour nous vanter dans tous les sens. Ce +dossier devrait être +prêt pour mi-avril. Avis aux volontaires. diff --git a/compte_rendus/2015_05_07.md b/compte_rendus/2015_05_07.md new file mode 100644 index 0000000..0cc3748 --- /dev/null +++ b/compte_rendus/2015_05_07.md @@ -0,0 +1,164 @@ +# Réunion du Collège Technique + +* Date : Jeudi 7 mai 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h14 +* Fin : 20h36 +* <> + +## Présents + +* Hamza Dely +* Gabriel Detraz +* Emmanuel Arrighi +* Daniel Stan +* Raphaël-David Lasseri +* Pierre-Elliott Bécue +* Raphaël Bonaque + +## Ordre du jour + +### Federez WiFi + +* Le système fonctionne en ce qui concerne le Cr@ns, dans les deux sens. +* Le Principe : une demande d'authentification federez-wifi a un suffixe + en @federez.crans par exemple, et est acheminée par le système de proxy + radius vers le serveur de l'école d'origine. + +* Il reste des problèmes sur la réception dans les autres assos, au niveau de + la modification de l'identifiant pour retirer le suffixe. En effet, + l'utilisation du module python au Cr@ns n'a pas permis de déceler ce problème + plus tôt. +* La doc et le monitoring sont + disponibles : et + + +Pour terminer, il faut : + +* Mise en place d'un nouveau vlan, d'un nouveau /d'ip natées (donc, demander à + la dsi les id vlans disponibles), le plus simple comme solution vu les + scripts dont on dispose actuellement) + +État du système (au 12/05/15): + +. Iresam : +. bal -> iresam : prb sur les id à l'arrivée, comment retirer le +suffix / iresam -> ext : réglé + +. Crans : +.bal -> crans : ok / crans -> bal : ok + +. rezo-metz : +. bal -> metz : ils ont un suffixe, pas de soucis (maj : c'était inexact mais +sans incidence) / metz -> bal : réglé + +. gif : +. bal -> gif : prb d'id à l'arrivée / gif-> bal : réglé + +### Couverture du gymnase + +« Ils ont froid. » + +Le festival de robotique nous a relancé. Daniel a fait du repérage hier, et a +constaté que la DSI +va installer un switch 8 ports poe avant fin mai. Ils nous proposent de nous +réserver un port. +Un câble devra être tiré depuis le local technique vers le lieu d'installation +de notre borne. +Un mail sur dsi crans a eu lieu à ce propos, Sabrina propose de nous réserver +un part sur le switch, +Gabriel lui répondra sur le sujet de la configuration des locaux, de l'accès +entre le gymnase et +le local notamment. + +On envisage d'installer une borne Unifi Pro, ce qui permet d'avoir un port en +plus pour rajouter +des accès filaire au besoin, et s'alimenter directement en PoE. + +### Bcfg2 + +Pierre-Elliott a recodé le plugin from scratch. Il a laissé les sucres "@" mais +a retiré les "export" (''a priori'', +seul le main.cf du bundle postfix.) + +Deux trois tests à faire encore avant de packager pour jessie. Le client de +wheezy ne fonctionne +pas avec le serveur jessie. On peut tester avec vo en tant que client (il +faudra le migrer). + +Il va y avoir du ménage à faire dans les Metadata (groups surtout, en ce moment +soyouz essaie +de monter des trucs en NFS…). + +### Mise à jour vers Jessie + +Elle est sortie ! + +On va commencer à indiquer des dates là-dedans. +[[CransTechnique/AdminSystème/DistUpgrade#Serveurs_non_migrés]] + +Penser aussi à évaluer la difficulté de la mise à jour. On va commencer par vo, +et puis on verra pour les autres, +suivant disponibilités des nounous. + +Vo upgradé permettra d'avancer dans la migration de l'intranet et de tester +bcfg2-client (ce qui serait +bien avant de continuer avec les upgrades.) + +### Intranet + +Hamza et Gabriel ont bien travaillé : + +* Rechargement solde impression : com'n'pay, le contrat est en cours + d'activation +* Impression : l'application fonctionne, sauf l'envoi de mail, car cups sur + o2 formate mal le jobname (On trouve pas pourquoi.) +* La programmation du driver PCL a avancé, il faut finir (en résolvant les bugs + que l'on a décelé jusque là…) +* Gestion des clubs : impersonate ? Les apps plantaient quand on se connectait + en tant que club. + +. impersonate est un plugin django pour se faire passer pour un autre +utilisateur. On peut alors +spécifier qui a le droit d'impersonifier qui. +. Prob 1 : PIP (beurk) +. Prob 2 : l'absence de traçabilité. +. L'autre solution est d'intégrer ces fonctionnalités dans les +applications. <-- ça serait plus propre non ? Oui. Hamza et Gabriel vont +s'occuper chacun de leur app et on verra si ça marche. + +### Switchs PoE + +Intervention de PEB : « J'ai eu Anne au téléphone… qui me rappelle. » +Ceci était une intervention de PEB. + +Le plan est d'acquérir des switchs gigabit PoE (actif), un par bâtiment, afin +d'alimenter et +de pouvoir redémarrer les bornes WiFi à distance. Il faudra également acheter +des spliter +(une centaine ?) pour toutes les bornes sauf les UAP Pro (qui le font en natif.) + +Les switchs gigabit remplacerait les étoiles actuelles. + +À voir suivant le prix, notamment acheter 100 splitter qui pourrait couter dans +les 1000 à 2000 euros à lui seul. + +### Ponts WiFi + +PDJ : le printemps est arrivé. On va voir si on peut accéder au toit avec +l'accord de la STL. + +Parallèlement, on envisage de tunneler le réseau ethernet "filaire" au travers +du réseau WiFi. +D'une part, pour les bornes d'appoint à placer chez les adhérents, cela +permettrait de n'assigner qu'un +seul vlan lors de la connexion de la borne WiFi (cela permettra de garder le +système d'auth +automatique par mac via radius, sur les switchs des chambres.) +D'autre part, cela permettra de normaliser le système de ponts actuels : les +ponts feront transiter +le vlan 3 et à l'arrivée, une borne d'appoint pourra dé-encapsuler le vlan +filaire, si les gens +en veulent. + +Pour l'instant, ce projet n'est pas prioritaire, on s'en occupera cet été. diff --git a/compte_rendus/2015_05_26.md b/compte_rendus/2015_05_26.md new file mode 100644 index 0000000..cb27ecd --- /dev/null +++ b/compte_rendus/2015_05_26.md @@ -0,0 +1,167 @@ +# Réunion du Collège Technique + +* Date : Mardi 26 mai 2015 +* Lieu : Condorcet +* Début : 19h25 +* Fin : 20h23 +* <> + +## Présents + +* Daniel STAN +* Gabriel Detraz (via $Kype) +* Pierre-Elliott Bécue +* Hamza Dely + +## Ordre du jour + +### Événement robotique + +Daniel propose un rdv avec la DSI demain ou jeudi matin. Avis aux volontaires +qui voudraient l'accompagner. Comme l'UAP Pro n'a pas encore été commandée, on +compte utiliser celle du 2B en attendant de refaire une commande cf Jeudi +prochain. L'intérêt d'une UAP Pro est d'avoir le poe actif intégré (le switch +dsi est poe compatible) et de proposer un port ethernet supplémentaire pour +pouvoir étendre le réseau si besoin. + +### Point rencontre + +La DSI a répondu à Pierre-Elliott, ils ont un souci avec la fourniture de +machines car il semblerait qu'ils doivent identifier les gens utilisant les +machines. +Pierre-Elliott leur a proposé de les faire passer par le réseau Crans, il +faudrait voir si on veut mettre un portail captif sur le port 80 pour obliger +les gens +à fournir login/MDP. + +Parallèlement, il faut s'intéresser aux mots de passe wifi jetables. Il +faudrait également pouvoir savoir qui s'en sert, car si un jour on a une +requête, +et qu'on a pas de réponse, on se fera vraiment emmerder. + +On pourrait fournir un mini-formulaire à remplir par l'admissible en échange de +tickets WiFi fournis par le BDE. + +Niveau imprimante on peut en fournir une (Hyjal) si le BDE le souhaite. + +Ne pas oublier la charge supplémentaire pour le BDE à l'ouverture/fermeture du +PR vis-à-vis du matériel mis à disposition (ordinateurs, imprimante, etc.). +À voir avec le BDE. + +### Virtualisation BDE + +Le BDE est partant pour virtualiser. Besoins : + +* Deux VMs + * Une avec 20 Go de stockage, un ou deux cœurs, et 1 Go de RAM + * Une avec 8 Go de stockage, un cœur et 512 Mo de RAM. + +Usage : serveur web et test. Les nounous sont d'accord. + +### Ponts WiFi + +Le pont WiFi vers le coteau est mort. Ouranos semble avoir des problèmes de +flashage. Les intéressés sont sur le coup. On ne comprend pas pourquoi le fs +est corrompu. + +Un reflash semble nécessaire, vu l'état de mort cérébrale de la borne. +Remplacer par nanom5 ? Il est nécessaire d'intervenir sur le toit. + +### FedeRez WiFi + +Ça marche, cool. + +Le vlan 12 a été mis en place côté campus. Le SSID en revanche n'est pas +diffusé sur toutes les bornes. +On va parler à la DSI de la propagation du vlan 12 côté ENS via DT. + + + +### Discourse + +On a installé une vm. + +C'est une super fucking application Ruby On Rails qui tourne dans un container +docker à la con sur une VM appelée… Discourse. Scourse + +Le soft en lui-même est moderne, et pas mal d'un point de vue ergonomie. +Cependant, il pose des soucis divers et variés. + +Problèmes rencontrés : + +* Vie privée (les admins ont accès aux messages privés) ; +* Facilité de lecture, l'agencement des posts est pas terrible ; +* Certaines personnes ne savent pas filtrer par catégorie, mais bon, ça c'est + la couche 8. + +### Renouvellements de garanties + +* Charybde : 168 € HT +* Pulsar : 865 € HT + +Pulsar on veut. Charybde on s'interroge. Pour l'instant, on laisse de côté +Charybde, car il n'est pas si vital, et nous avions déjà un projet de miroir +commun avec la DSI. + +Pour charybde, on va poker la DSI, et on va voir. + +### Switch PoE + +8 k€ pour 9 gigabit 24 ports (les 2530) POE. + +À noter qu'il faut rajouter à la dépense l'achat de splitter PoE et +éventuellement des gbic si les actuels ne sont pas compatibles. +À voir en CA. + +### Virtualisation + +Pierre-Elliott veut toujours son virtualiseur. Pour le moment, le besoin ne se +fait sentir. Fz passe hors garantie en novembre, on pourra voir à ce moment là +pour acheter un truc plus gros. + +### Disques pour les VM + +En parallèle, on envisage d'échanger le stockage des vm pour utiliser les +disques de 600Go. L'idée est de débrancher un disque de 300 Go, et de mettre +un 600 à la place. +À essayer… après avoir lu la doc. + +### dist-upgrades + +asterisk ça s'est bien passé. +discourse est déjà sous Jessie. + +#### Freeradius + +Y a des trucs qui segfaultent. +Après investigation, le problème semble complexe : le phénomène de segfault ne +survient pas après clean install et appel au backend python. On investigue +avant de bugreport. + +#### Bcfg2 + +Mise à jour faite, on a créé une nouvelle VM, le paquet est à jour avec le +plugin. Il avait des soucis de {{{print}}}, qui ne sont pas thread-safe, et il +est probable que +le fonctionnement interne du serveur ait changé aussi. + +{{{print}}} ne fait donc plus rien, et on a mis une fonction out() et _out() en +place pour remplacer. + +La nouvelle VM sera renommée sous peu. + +### Couacs update.sh + +Lors des derniers update.sh, qui apparemment ont tous eu lieu sur fz, les homes +se remontaient en partie en read-only. fz présentait d'autres anomalies +relatives aux disques. On l'a rebooté. Comme c'est la première fois que cela +survient, on va pour l'instant garder l'œil. + +### Coupure annuelle + +Chérie, ça va couper. Il faudra être vigilant. + +On prévoit une maintenance d'une journée du local et d'une certaine quantité de +services ou autre. On va fixer une date (fin juillet~août, voir crans +vacances) et une liste de trucs à faire (ranger 0B, migrer disques vm, +dist-upgrade routeur, ldap.) Si ça vous intéresse, manifestez-vous ! diff --git a/compte_rendus/2015_09_03.md b/compte_rendus/2015_09_03.md new file mode 100644 index 0000000..53ff645 --- /dev/null +++ b/compte_rendus/2015_09_03.md @@ -0,0 +1,85 @@ +# Réunion du Collège Technique + +* Date : le jeudi 3 septembre 2015 +* Lieu : Pavillon des Jardins +* Début : 19h00 +* Fin : 20h13 + +## Présents + +* Gabriel Detraz +* Daniel Stan +* Lucas Serrano +* Raphael David Lasseri +* Emmanuel Arrighi +* Myriam Begel +* Hamza Dely +* Charlie Jacomme +* Jordan Delorme (arrivée à 19h29*) +* Pierre Elliott Bécue (idem) +* Ariane Soret (arrivée à 19h15) +* Nombreux nouveaux adhérents + +## Ordre du jour + +### Intranet + +La restylisation est finie ! Que faire maintenant ? (traductions ? gest_crans ?) +Lucas a changé le style de l'intranet et a fait en sorte qu'il s'adapte à +toutes les résolutions d'écran. Il nous montre la structure des différentes +parties et fait un topo sur les bonnes pratiques à avoir. + +Il a retravaillé les templates, et surtout les classes css. + +Il mettra les slides sur le wiki. + +### Gest_crans + +Présentation de gest_crans aux adhérents peu familier de cet outil. On présente +également quelques nouvelles features, en particulier les factures et +l'impression de tickets. + +C'est un vieux code qui va devoir être réécrit car il est assez dur à +comprendre. PE se propose pour commencer un squelette pour qu'ensuite tout le +monde puisse travailler dessus. + +### Mises à jour Debian + + +Les mises à jour avancent mais il en reste un paquet à faire. Les intéressés et +surtout les nouveaux peuvent sonner une nounou pour en faire. De nombreux +serveurs peuvent en effet être coupés sans interruption de services pour les +adhérents et peuvent donc être mis à jour n'importe quand ! + +### Séminaires + + +Raphaël rappelle le principe des séminaires jusqu'à maintenant et propose une +nouvelle organisation. + +#### Refonte + +Cf mail @nounous + +Tilgaht propose 4 séminaires de bases : Shell/SSH - Cr@ns - Réseau - Python. +Cela permettrait d'avoir les bases pour commencer à travailler vraiment. + +Les séminaires seraient ensuite plus orientés workshops pour que les gens +soient actifs. +Il pourrait également y avoir des workshops plus personnalisés avec 1 nounous +pour 3 apprentis par exemple. + +Pour ne pas casser les séminaires ouverts à tous, il pourrait y avoir un +séminaire grand public par mois sur des thématiques plus ou moins techniques +mais un peu plus déconnecté du Cr@ns. + +PE pense qu'il serait pertinent de faire un séminaire GNU/Linux avant le +séminaire Shell/SSH. + +L'install Party sera organisée le week-end du 26-27 septembre (malheureusement +en même temps que le K-WEI). Le 1er séminaire aura donc lieu le mardi qui suit. +Prenez note ! + +### Nomination de nounou + +Hamza Dely est nommé nounou, bravo à lui ! diff --git a/compte_rendus/2015_09_17.md b/compte_rendus/2015_09_17.md new file mode 100644 index 0000000..71de294 --- /dev/null +++ b/compte_rendus/2015_09_17.md @@ -0,0 +1,154 @@ +# Réunion du Collège Technique + +* Date : Jeudi 17 septembre +* Lieu : Pavillon Des Jardins +* Début : 19h00 +* Fin : 20h30 + +## Présents + +* Lucas Serrano +* Gabriel Détraz +* Myriam Begel +* Emmanuel Arrighi +* Mathilde Espinasse +* Rémi Oudin +* Aliaume Lopez +* Hamza Dely +* Martin ?? +* Pierre Elliot Bécue + +## Ordre du jour + +### Aménagements 4J + +On a racheté un onduleur en urgence (voté en CA) suite aux problèmes de +disjoncteur. +L'onduleur est manageable en ethernet (quasar.adm.crans.org). + +La clim est hors circuit de l'onduleur, car trop gourmande. Vu son état, il +serait temps de la changer. + +Cahier des charges : + +* mémoire (reprise du mode d'avant coupure) +* mettre l'accent sur le coté déshumidificateur (pour le papier) + +Quid également du digicode et clés 4J ? +On va proposer un devis pour changer le canon de la deuxième porte (trop de +clés perdues). + +### Kfet + +Le panneau de brassage ainsi que la boîte sont arrivés. Mais c'est plus lourd +que prévu. On regarde avec un membre du bde pour faire une installation +raisonnable (mur en plâtre). On attend de ses nouvelles lundi ou mardi. + +Concernant le switch PoE, on ne connait pas pour l'instant les besoins exacts +du bde, en nombre de caméras/câbles à tirer. +Lors du dernier CA, l'achat du switch a été repoussé, dans l'idée d'acheter du +matériel plus récent compatible PoE gigabit. Finalement, vu le peu de nouvelles +et l'usage prévu (bornes + camera), un 100Mbit/s PoE +paraît un bon compromis niveau prix. + +En attendant, on a installé un 100Mbit/s non poe. Switchs2.py a été mis à jour +pour gérer les prises, depuis la base de données (et aussi générer un schéma de +câblage.) + +Une deuxième borne (unifi simple) a été rajoutée, suite à des problèmes lors de +l'entrée pot et les deux bornes sont désormais fixées "solidement" dans le mur. + +### FreeRadius + +Gabriel et Daniel ont corrigé le problème de segfault sous jessie. Plus +exactement, il n'est plus possible d'instancier plusieurs fois le module +python (cela mène à un segfault.) + +Il faut aussi reporter le bug. On peut donc entamer les mises à jour des +serveurs radius restants, c'est-à-dire radius puis, si tout se passe bien, eap. + +Aliaume est partant pour un dist-upgrade ! \o/ Rémi aussi si besoin ! + +### Ticketteuse + +Beaucoup de cafouillages ces derniers temps. Hamza vient d'en refixer une à la +kfet. Les mots de passe ont été mis dans cranspasswords, cette fois. +Il reste à mettre la clé ssh (pour la déchiffrer) quelque +part : dans /etc/crans/secrets (et ultérieurement dans cpasswords ?). + +La deuxième ticketteuse marche mais la carte SD n'est pas encore chiffrée, et +il faut lui trouver un nouveau boitier. + +### Intranet + +Gabriel montre sa nouvelle feature d'édition de .forward. +Quelques probs de compte/impressions ces derniers temps. +(cf commits d'aujourd'hui.) + +Lucas n'est pas très fan de l'édition arbitraire du .forward. Il préférerait +avoir une option pour rentrer un champ mail. + +Attention : réorganisation imminente du dépôt suivant les versions récentes de +django. +Lucas et Daniel vont s'occuper du déplacement des dossiers et fichiers, +attention aux merges ! + +### Asterisk + +La machine virtuelle "asterisk" va mal. Il a été proposé de recommencer une +installation à partir zero. Pour info, ce serveur héberge un +programme "asterisk" +fournissant un service de voip (protocole sip) aux adhérents. + +Ce serait donc l'occasion de faire le ménage et d'en apprendre plus sur la voip. + +Plusieurs projets apprentis : + +* Créer une vm en compagnie d'une nounou (idefisk) +* Examiner la conf d'asterisk et la cloner (idefisk) + +On remet à plus tard, mais si quelqu'un veut bien s'y pencher, qu'il fasse +signe ;) + +### Impression + +Cela fonctionne mieux, mais ça cafouille quand quelqu'un lance une grosse +impression, la file d'attente est bloquée. Il faut implémenter la gestion de +file avec des ordonnanceurs. +Cela se passe sur le serveurs {{{cups.crans.org}}}. + +Gabriel a rajouté une info sur le statut de l'imprimante sur l'intranet. + +Liste de projets (éventuellement pour apprentis) : + +* Permettre les impressions de plusieurs fichiers en même temps (projet django) +* Imprimantes virtuelles sur cups (cf slides) (+ écriture de deux ordonnanceurs) +* Écrire un nouveau printer_watch qui prévient des pannes de l'imprimante. + +### Questions diverses + +#### Tracker + +Le tracker.crans.org. Quid du truc de FedeRez ? Ie phabricator ? On essaie +d'installer ça. + +On a potentiellement d'autres adhérents intéressés (la sauce par ex). + +#### VM Inutiles + +* Discourse -> On garde un peu, histoire de voir si le CA est prêt à faire de + la comm' là-dessus. Il faut voir si on est motivé pour un nouveau web news + pour essayer de redynamiser les news. +* Tracker ? -> On efface ? Ça ne marche clairement pas, faisons le ménage dans + les tickets puis on le vire (comme ça, pas d'upgrade à gérer). + +#### Local de brassage du -1I + +La clé du -1I semble avoir été changée, une nouvelle fois, et nous n'avons pas +été prévenu. On ira voir le Crous dès que possible (demain matin). + +[Mise à jour du vendredi 18 : le technicien crous nous a donné la nouvelle clé] + +#### Slides + +[[attachment:adaptations-de-freeradius-pour-debian-jessie.pdf]] diff --git a/compte_rendus/2015_10_01.md b/compte_rendus/2015_10_01.md new file mode 100644 index 0000000..dc2a842 --- /dev/null +++ b/compte_rendus/2015_10_01.md @@ -0,0 +1,116 @@ +# Réunion du Collège Technique + +* Date : Jeudi 1er octobre 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h13 +* Fin : 20h05 +* <> + +## Présents + +* Mathilde Espinasse +* Hamza Dely +* Aliaume Lopez +* Rémi Oudin +* Aurélien Pascal +* Lucas Serrano +* Daniel Stan + +## Ordre du jour + +### Mailman + +Pleins de bounces ce mois-ci. On a signalé à l'ENS que notre serveur n'est pas +considéré de confiance par le relai renater, ce qui est problématique... On a +aussi contacté laposte.net pour qu'ils arrêtent de filtrer nos mails. + +PEB proposait de ne plus envoyer de rappel mensuel. On pense tous que c'est +inutile (le rappel) donc ok, c'est fait. + +Il faut se pencher aussi sur dkim, aussi. + +### Sens de l'art + +Aurélien souhaite pour les sens de l'art d'avoir une vm pour héberger le site +web des sens de l'art. Vu la maintenance +nécessaire, on envisageait de faire pot commun avec le gala qui a déjà un +système du genre pour la dernière édition. En +l'absence de réponse du gala, on va faire comme ça (accord de principe du +gala.) Le site promotionnel sera en place +d'ici jeudi prochain (pour la soirée associée). + +Les sda, c'est du 24 au 29/11. + +Reste le choix la méthode de paiement… Mais c'est le staff sda qui va s'en +occuper. + +### Parefeu + +On a commencé à regarder le parefeu. Hamza va nous en parler plus. +Voici un plan (cahier des charges prévu) : + +Reste à s'occuper des limitations de débits. + +### Intranet + +Daniel a commencé à réoganiser les dossiers pour être compatible avec les +nouvelles normes de Django sur le rangement des apps. +Ça a l'air de fonctionner et de merge sans trop de problème. Cf +branche "reorganisation" sur le gitlab pour ceux qui sont +curieux. + +Ping a commencé à écrire des fonctions pour les template (templatetags). To be +continued. + +### Impression + +Charlie s'est occupé de proprifier la gestion de l'impression au Crans. (Il +n'est malheureusement pas présent pour en parler) + +{{{ +22:25:03 Charlie | Nounou : vu qu'il y a Internounou demain, petit résumé de +nos expériences sur cups avec Jordy : +22:25:15 Charlie | Actuellement le système d'impression est tel que suit : +22:25:17 Charlie | 1)l'intranet fait un "lp", qui met le job en queue sur o2. +22:25:19 Charlie | 2) cups_o2 envoie les jobs de sa queue 1 par 1 à +cups_cups (il se comporte comme si cups_cups était une imprimante) +22:25:21 Charlie | 3) cups_cups envoie les jobs à l'imprimante +22:25:23 Charlie | Parfois, des jobs fail sur la queue de cups_cups avec +l'exception "Exception: operation for Array object attempted on object of wrong +type" d'origine inconnu. Cependant, cups_cups ne dit pas à o2 que le job a +fail. Du coup, cups_o2 attend +| indéfiniment la fin de la tache envoyé et n'envoit plus aucun jobs à +cups_cups. +22:25:25 Charlie | Une première chose que je propose est de supprimer +l'intermédiaire cups_o2 avec la proposition de daniel : mettre un client.conf +contenant "ServerName 10.231.136.50:631". Tester sur vo, ça marche bien, lors +de "lp" ou "lpstat" tout se passe comme si +| on était sur cups_cups. +22:25:27 Charlie | Par ailleurs, on a aussi testé avec Jordy de dupliquer +l'imprimante MFPM880 et de mettre les deux dans une classe. Cela nous a permit +de découvrir que le job qui buggé précédement bug sur une seul des deux +imprimantes. Oui, alors que c'est la même +| imprimante la même conf copié collé. cf le printers.conf de vo, si quelqu'un +arrive à élucider ce mystère. +22:25:29 Charlie | Enfin, on sait pas pourquoi ça bug, mais dupliquer x fois +la conf de l'imprimante et créer une classe semble être une solution. » +}}} +Bref, si des personnes sont motivées pour regarder avec Charlie et Jordy … + +Léo Colisson est partant pour se pencher sur le monitoring de l'imprimante en +snmp. + +### Questions diverses + +#### Guinness is good + +Un ancien membre actif a exprimé sa haine d'Apple sur l'ordi d'un nouveau +membre actif. Ils sont a priori en train de lancer une procédure auprès de son +assurance, mais le Crans (de par son assurance) prendra en charge si ça se +passe mal avec l'assurance dudit ancien membre actif. + +#### Séminaire + +"Techniquement" ça se passe mardi prochain. C'est Daniel qui présentera le +réseau et les services du Crans. +Au condorcet à 19h avant le pot. diff --git a/compte_rendus/2015_10_15.md b/compte_rendus/2015_10_15.md new file mode 100644 index 0000000..3be93de --- /dev/null +++ b/compte_rendus/2015_10_15.md @@ -0,0 +1,141 @@ +# Réunion du Collège Technique + +* Date : 15 octobre 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h06 +* Fin : 20h34 +* <> + +## Présents + +* Charlie Jacomme +* Hamza Dely +* Mathilde Espinasse +* Vincent Le Gallic +* Rémi Oudin +* Aliaume Lopez +* Lucas Serrano +* Daniel Stan +* Jordan Delorme en duplex de chez le doc (merci) +* Emmanuel Arrighi +* Pierre-Elliott Bécue (depuis son super réseau LTE à Bordeaux) + +## Ordre du jour + +### Intranet + +Chirac a « dumpé sur la gueule » de Charlie le projet intranet câblage. Ce +dernier se pose tout de même des questions sur le cahier des charges. + +Premier objectif : un câblage comme sur gest_crans, on verra plus tard pour les +pré-adhésions et cie. + +Autre problème, on trouve que c'est trop facile d'accéder à l'appli câblage +pour une personne mal intentionnée qui aurait accès à l'intranet d'un MA. +Deux solutions : soit faire un autre projet django, soit faire un +mode "admin" où le MA doit retaper son mot de passe au début. +Charlie souligne également que le problème existe également sur les pages +d'admin de l'intranet. + +Daniel a fait un script pour pouvoir faire fonctionner l'intranet sur sa +machine perso. Il s'appelle testing.sh et se trouve dans /usr/scripts. +Il en fait démonstration à l'audience. + +On a présenté deux trois modifs de la branche reorganisation, ça semble +convenir à tout le monde. [à détailler] + +Ping a présenté sa nouvelle appli de surveillance de l'imprimante, via snmp. + +### Séminaires + +La semaine prochaine (20/10/2015), séminaire shell, par Pauline. On le coupe en +deux parce que c'est quand même un gros morceau et qu'on veut le faire en +interactif (s'arrêter de faire défiler plein de slides pour laisser tout le +monde pianoter sur son terminal). +Donc le tome 2 sera après les vacances (le 2/11, à confirmer). + +### Phabricator + +* Présentation de l'avancement du projet +* Définition d'un cahier des charges + + (à ouvrir de l'extérieur) [ça marche pas de +l'extérieur] + +### Pose de borne WiFi bâtiment A + +Le WiFi dans le bâtiment A semble ne pas couvrir de nombreuses chambres en fin +de couloir. + +Les chambres du fond ne captent pas. Emmanuel est motivé pour tirer des câbles, +si c'est le cas, on voit pas de soucis à racheter des AP. +Il y a aussi un projet de routeur d'appoint dans les chambres qui est resté en +suspend. Avis à volontaire (quelles tâches sont nécessaires ?) + +Il y a des problèmes pour capter à l'entrée du pot, on envisage d'échanger les +deux AP ou sinon de changer le ssid tous les mardi soirs le temps du pot pour +ne laisser que les membres bde connectés. + +Ping propose de monitorer beaucoup plus de paramètres sur munin (débit de +synchro, pertes de paquets). +Autre projet : passage à CC sur les points d'accès. +Pour l'un comme pour l'autre, avis à apprentis motivés. + +### Projet virtualisation + +Un apprenti est motivé pour s'investir dans la virtualisation. Pierre-Elliott +est motivé pour l'encadrer. Il voudrait donc relancer l'idée d'acheter un +virtualiseur, +dans le but d'avoir une infra avec deux machines récentes et puissantes, fz, +qui tient bien la route, et soit d'enlever kdell pour l'utiliser à autre chose, +soit le +garder dans le cluster. + +On vise un truc de l'ordre de ft, et on retire kdell. + +Il est évoqué de migrer les services de sable (DNS master) qui n'est plus sous +garantie, soit sur kdell, soit sur une vm. + +L'idée est aussi que si les CPU se tournent régulièrement les pouces, la RAM +est belle et bien consommée, donc on est large, mais pas ultra large. On ne +sait pas combien. ft: 12/32Go de RAM. +fz: 12/16Go de RAM +kdell: 16/16Go +On voit sur 16Go de RAM. + +On va également renouveler la garantie de fz. + +### Machine pour FedeRez + +Pierre-Elliott avait pour projet de proposer que le Crans achète un serveur, et +en fournisse gratuitement l'accès à FedeRez. L'idée est que leurs besoins en +espace de stockage est relativement élevé, et finalement, outre deux VM, +FedeRez ne dispose que d'un serveur en location chez OVH. Avoir un serveur +dédié physiquement accessible dans une des assoces adhérentes ne serait +peut-être pas si mal. +En particulier, il y a un manque de redondance dans le stockage des données. +FedeRez va contacter les autres associations pour savoir ce qui pourrait se +faire en termes de redondance. + +Ils veulent : "some stuff". Pour l'instant, on s'oriente sur sable (une fois +qu'il sera migré). + +Un grand merci de la part de FedeRez. + +### Questions diverses + +#### Année et établissement d'étude dans la BDD + +L'année d'étude n'est pas utile, on pense jamais, ni la section (et ce n'est +jamais normalisé). Si quelqu'un veut bien les retirer, il est le bienvu. +L'établissement est le seul qui peut vraiment servir, on le garde. + +Petit ménage à faire (plus utile) : + +* Virer l'attribut paiement +* Cartes d'étudiants + +#### Switchs + +FedeRez a reçu une propositon de don de switchs Gigabit. Ils seraient gratuits +modulo les frais de ports. Il faut voir avec la datasheet. diff --git a/compte_rendus/2015_11_12.md b/compte_rendus/2015_11_12.md new file mode 100644 index 0000000..4f672cc --- /dev/null +++ b/compte_rendus/2015_11_12.md @@ -0,0 +1,175 @@ +# InterNounou + +* Date : 12 novembre 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h06 +* Fin : 20h30 + +## Présents + +* Anne Cazalet +* Pierre-Elliott Bécue +* Gabriel Detraz +* Hamza Dely +* Myriam Bégel +* Mathilde Espinasse +* Rémi Oudin +* Magalie Vetter +* Adam Heriban +* Jonathan Cailliez +* Jordan Delorme +* Vincent Le Gallic +* Emmanuel Arrighi + +## Ordre du jour + +## Point sur les problèmes d'ambiance au CT + +Daniel a souhaité revenir sur le mail émanant d'une membre active sur +nounou@ qui dénonçait des attitudes sexistes et +transphobes au sein du collège technique. Il s'est excusé pour cette ambiance +délètere dont il est responsable. +Un ancien membre actif lui a transmis une synthèse de textes de loi concernant +ces agressions ainsi que les peines +encourues. Il n'est évidemment pas pertinent d'en arriver à se retourner +judiciairement contre nos membres actifs, +mais une analyse rapide nous montre que les comportements décrits dans le mail +initial sont assimilables à du +harcèlement sexuel, tel que défini dans la loi. Ainsi, nous ne pouvons que +confirmer la gravité des situations +qui y sont décrites. + +Gabriel a rappelé qu'un projet de code conduite, dont la forme (charte, texte +séparé), est en cours d'étude +par Mathilde et Rémi (cf dernière réunion CA). Même si le collège technique +n'est pas habilité à mettre en place ce texte, il est important +qu'il exprime son avis. Daniel pense que ce projet est une bonne idée, +notamment parce qu'il permet de fournir +une base saine, qui facilitera la dénonciation des attitudes inacceptables. De +plus, les exemples de codes +de conduite proposés (Julia, Rust, FreeBSD) lui semblaient adaptés. + +## Propositions concernant les séminaires + +On rappelle aux nounous, mais aussi au public en général qu'il faut être +civilisés et lever la main avant de poser une +question ou introduire une remarque plutôt que d'interrompre l'orateur. +Idéalement, on pourrait proposer un chairman, chargé de distribuer les +questions et protéger le temps +de parole. De plus, il est facilement envisageable de nommer un responsable +différent à chaque séminaire. + +Au niveau de l'organisation générale des séminaires, il s'est avéré que les +deux volontaires en début d'année +n'ont que trop peu de temps pour pouvoir en consacrer à cette tâche. Lucas +Serrano (absent lors de la réunion) +semble cependant motivé pour prendre la relève et encadrer tout cela. + +Côté thématiques : +Est-ce qu'on commence à faire des workshop en parallèle des séminaires pour +avoir davantage de pratique ? +Certains apprentis présents ont exprimé leur volonté de réaliser des projets et +d'appliquer d'avantage leur +connaissance. + +On prévoit les activités ci-dessous pour les jours qui suivent : + +* Samedi aprem/soir : Màj pgsql (thot) +* Dimanche : workshop virtualisation +* Mardi : bornes WiFi et passage à CC (format workshop) par Gabriel +* Mardi prochain (en 8) : enchaîner sur un vrai séminaire. Certains sont déjà + prêts (impressions, git, python 2, etc) + +Pour le reste, il y a phabricator qui recense des tickets de projet en cours, +et nous encourageons les apprentis +à contacter une/des nounous pour se lancer dans la résolution d'un ticket qui +leur semble intéressant. + +## Évolution du conseil technique + +Charlie est promu nounou. Félicitations. + +Daniel commence à se trouver un peu vieux pour assumer le poste de RTC. +Aux jeunes d'en discuter entre eux et avec les vieux, avec Daniel... On fait le +point dans deux semaines. + +Parmi les projets, on a également envie de faire un script pour enlever les +droits aux vieilles nounous, afin +de ne pas laisser des failles potentielles au nom de gens qu'on ne connait même +plus. L'idée est qu'ils +pourraient, en cas de besoin, se redonner les droits (typiquement sudo +give_me_back_my_rights qui serait +dans le sudoer file, ou un accès au mot de passe root). + +## Câblage sur l'intranet + +Développée par Charlie et Chirac, l'app est en beta. +Il reste deux trois petits trucs à régler notamment la cosmétique (logo), et +les gestions des droits django/ldap. +Les fonctionnalités supportés sont grosso-modo ce que les câbleurs peuvent +faire depuis gest_crans. + +Gabriel est chaud pour gest_crans_lc. On émet des réserves quant à sa +maintenabilité. On essaie de +mettre gest_crans_lc en default pour les cableurs (avec possibilité d'utiliser +l'ancien). + +## Monitoring + +Les services sur fy ne sont pas maintenus. Quelle fiabilité attend-on du +monitoring ? + +## Phabricator + +Phabricator (tracker.crans.org) est ouvert à tous. Hamza se demande comment +gérer les projets ouverts par les autres. +Daniel est d'avis de laisser chaque propriétaire s'occuper de sa gestion, sans +ingérance. + +Il reste à faire de la comm' autour de ce service (sur l'intranet, la +sauce, … ?) ;) ;) + +## Mise à jour de thot (pgsql) + +DU programmé samedi, de nombreuses personnes ont fait part de leur intérêt +suite au mail de Chirac sur nounous. +(Laloutre, Jack, Mathilde, Rémi) + + + +PE a un projet de plus longue date pour une page de status. + +## VM BdE + +Toujours dans le but de réduire le nombre de machines entreposées dans le local +serveurs BdE, Hamza voudrait savoir si le Crans pouvait héberger une nouvelle +VM pour remplacer le serveur de test du BdE (mail du 23/10 sur nounou). + +Il veut ~15-20 Go de disque dur, 1 Go de RAM, 1 cœur. L'usage prévu est +principalement le développement de la note et autres projets BdE (digicode ...). + +C'est acté. + +## Questions diverses + +### Future webradio + +Freq[ENS], nouveau club webradio voudrait demander une VM et diffuser une +webradio vers l'extérieur (donc ouverture de ports, upload). +Daniel suggère d'utiliser OVH, qui est déjà hors campus, si on a des problèmes +d'upload. + +Pierre-Elliott rappelle que le maintien d'une VM est à la charge du club. + +### Agreg EEA + +Il y a du GNU/linux et réseau au programme de l'agreg EEA depuis cette année. +Adam souhaiterait savoir s'il y a moyen de faire des séminaires de rattrapage +sur ces +domaines pour ceux qui sont déjà largués en cours. Les slides sont déjà là, +donc il y a toujours moyen que des nounous refassent les présentations avec un +effort peu important. + +On demande à ce que les questions déjà posées aux agregs précédentes nous +soient fournies et que les EEA se mettent d'accord pour un créneau horaire. +Adam s'en charge. diff --git a/compte_rendus/2015_12_03.md b/compte_rendus/2015_12_03.md new file mode 100644 index 0000000..8d3afcb --- /dev/null +++ b/compte_rendus/2015_12_03.md @@ -0,0 +1,195 @@ +# Réunion du Collège Technique + +* Date : Jeudi 3 décembre 2015 +* Lieu : Pavillon Des Jardins +* Début : 19h12 +* Fin : 20h47 +* <> + +## 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 : + +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. + + + +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 : + + + +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. diff --git a/compte_rendus/2015_12_17.md b/compte_rendus/2015_12_17.md new file mode 100644 index 0000000..fa3df5d --- /dev/null +++ b/compte_rendus/2015_12_17.md @@ -0,0 +1,127 @@ +# Réunion du Collège Technique + +* Date : Jeudi 17 décembre +* Lieu : Pavillon Des Jardins +* Début : 19h15 +* <> + +## Présents + +* Myriam Begel +* Rémi Oudin +* Daniel Stan +* Charlie Jacomme +* Hamza Dely + +## Ordre du jour + +### Icinga + +Pour remplacer autostatus qui est vieux, moche et à un certain nombre de +limitations, dely a mis en test Icinga (icinga2.crans.org). +C'est un service de monitoring qui possède déjà un bon nombre de plugin +préexistant (hpjd pour l'imprimante, backuppc, proxmox), les plugins pouvant +s'écrire à la main en python comme pour munin. De plus, les plugins nagios sont +compatibles. + +Icinga permet de redémarrer depuis le site de rédémarrer des services, d'où les +login required. + +* Munin met en place automatiquement pour un serveur tout ce qu'il faut, est-ce + qu'icinga peut faire pareille ? + +On vise un déploiement des fichiers de conf pour chaque host grâce à bcfg2. + +Il faudra mettre une tache sur phabricator et voir qui est intéressé. + +### Mise au point DU + +On a actuellement deux cluster proxmox différents avec uniquement stitch sous +jessie. +On envisage de migrer les autres virtualiseurs, en prenant soin à chaque fois +d'être sur que le serveur migré marche avant de toucher aux autres. +Daniel doute de la pertinence de faire d'autres migrations vu l'état des +migrations déjà en cours et jamais finies (cochon). + +On envisage de tenter de migrer fz à la rentrée, une fois que cochon sera +rétabli (cf point suivant) + +### Cochon + +Il faut tenter de compiler un noyau jessie à la main. Si ça échoue, on remet +sous wheezy. + +### Il faut sauver le soldat Odlyd (Routeur Fail-over) + +Daniel propose de profiter de la coupure lundi prochain pour un memtest. Si il +y a du monde pour aider, il testera avant si le routeur fail-over fonctionne +bien. +On a par ailleurs vu un comportement bizarre au niveau du scheduler, mais pas +d'explications. Si le memtest voit le problème, on renvoit la barette à HP. +La carte réseau aurait aussi des problèmes sur munin... (cable foireux ?) + +Sinon ? On verra le cas échéant. + +### Firmware update de Nols + +Charlie est possiblement chaud pour une maintenance la deuxième semaine, si +d'autres personnes sont présentes ? +Si Daniel se motive et qu'il y a plus de nounous, peut-être lundi +prochain (21/12) à midi. +On envisage aussi de swapper les disques de 300Go et de 600Go. + +### Modules de generate avec lc_ldap + +Il faut profiter de la migration pour repenser les scripts et leur refaire une +beauté et pas se contenter d'un copié collé basique. +On va créer une branche git pour faire tout ça. + +### whos_lc + +Un certains nombre de différence d'utilisation existe par rapport au précédent, +la mise en prod aurait mérité une discussion. +Lors d'un changement de script, une bonne idée est de mettre une disclaimer +dans le script lui même. +On s'interroge sur la confidentialité de la chambre ? Si l'utilisateur est en +chambre invalide, que ce passe-t-il ? + +Il faudrait dire que le numéro de tél et l'adresse sont censurés sur +l'affichage normal, pour pas qu'on perde 5 min à les chercher. + +### Demande de transfert des ip + +Demander à la dsi de nous transférer les ip, du point de vue du ripe. + + + +Pour cela, il faut un numéro d'AS et s'inscrire au Ripe (payant). La DSI de +l'ENS va peut-être bientôt associer ses adresses à celles des autres écoles, il +faudrait le faire avant si on veut les avoir. + +D'un point de vue technique, on deviendrait obligé d'annoncer nous même nos +routes. Cela parait compliqué aujourd'hui. + +Ce qu'il nous faut est une promesse de nous les garder de côté en vu du +déménagement à Saclay plutôt que de nous les donner de suite. + +### Futur : être un opérateur ? + +Il faut donc annoncer ses routes soit même, avoir un numéro d'AS et ripe... +Huricane Electrics propose un service permettant de tunneler sa connection +ipv6 et de la faire sortir "au milieu de l'internet" où on peut faire du bgp. + +On pourrait beta tester ça au cr@ns avant ARES. + +Qui serait intéressé par le projet ? Pour info, l'ARES envisage son inscription +en tant que LIR. + +### Upload + +munin.crans.org/crans.org/odlyd.crans.org/if_ens.html +Passage à 12Go ? + +Approuvé ! + +### Questions Diverses + +* Commander une carte de contrôle pour Pulsar diff --git a/compte_rendus/2016_01_14.md b/compte_rendus/2016_01_14.md new file mode 100644 index 0000000..8f31257 --- /dev/null +++ b/compte_rendus/2016_01_14.md @@ -0,0 +1,164 @@ +# Réunion du Collège Technique + +* Date : Jeudi 14 Janvier +* Lieu : Pavillon Des Jardins +* Début : 19h09 +* Fin : 20h45 +* <> + +## Présents + +Gabriel Detraz +Charlie Jacomme +Rémi Oudin +Daniel Stan +Martin Bauw +Myriam Bégel +Emmanuel Arrighi +Оксана Андреевна +Hamza Dely +Renaud Taleroy + +## Ordre du jour + +### letsencrypt sur intranet + +(wiki/wifi, gitlab, phabricator, etherpad, owncloud, zerobin, ... ?) + +Daniel propose de passer à un système centralisé. Il n'y aurait plus qu'un seul +serveur nginx tournant sur une machine à part, et les autres sites webs +seraient servi sur adm. On ferait alors un certif commun pour tous les +sous-domaines correspondant à un service internet. + +* Créer une vm (ssl.crans.org ? plopissecured.crans.org ? secure.crans.org ! ) +* Passer toutes les sockets gunicorn etc pour diffuser sur adm. +* Set up nginx + +On va faire une proof of concept pour un service mineur. (zerobin?) + +Apprentis : Fardale +Nounous : Charlie + +### Remplacement monit/... ? par icinga + +Objectif : virer autostatus, pour cela, il faut attendre le déploiement +d'icinga sur l'ensemble des serveurs (wheezy + jessie), + +### Migration des virtualiseurs + +* On va commencer par fz (ou tenter) + +Apprentis : Rémi + +### Migration des ipv6 ? + +Le tunnel quantic a l'air un peu plus efficace que l'ancien. + +On va pas tester en prod. Par conséquent, il faut attendre d'avoir un firewall +qui peut gérer deux prefixe v6. + +Soit on patch salement l'actuelle, soit on attend le nouveau firewall. + +Chirac va voir si c'est faisable assez simplement sur l'ancien firewall en +testant sur vo, mais rien ne presse. + +### lc_ldap 3 or not ? + +Les gens ne sont pas d'accord. + +Le débat ici tient en deux pans. + +Le premier point est de savoir si on veut commencer à passer les scripts du +crans à python3. Le support de python 2.7 s'arrête en 2020, il y a donc +plusieurs optiques possible. 2020 est encore relativement loin, donc est-ce que +passer à python3 est si urgent ? +Par ailleurs, on sera à Saclay avant la fin du support de python 2.7, on peut +donc laisser à l'ares le soin de s'occuper de python3. Cependant, plus la date +se rapproche, plus les nouvelles versions de software telle que Django vont +tout simplement dropper python2, ce qui pourrait nous poser problème. +Enfin, la question est-elle pertinente sachant que l'on a toujours pas terminé +de passer totalement à lc_ldap et qu'on a encore ldap_crans qui traine ? + +Le deuxième point concerne le devellopement d'un "nouveau" binding. PEB a +commencé à travailler dans son coin sur une version python 3 de lc_ldap où il +essaie de corriger au passage certains problèmes de son papa. Problème : à +deux ans du déménagement, est-il pertinent de lancer le crans dans le +developpement d'un nouveau binding. Certains pensent que si chaque asso bosse +dans son coin sur un nouveau binding, c'est de mauvaise augure pour +l'unification à Saclay où tout le monde préférera jouer dans son coin. +Cependant, nous sommes encore à deux ans au moins du déménagement, ce qui veut +dire que si l'on commence à bosser maintenant sur quelque chose tous ensemble, +ce ne sera pas les gens qui ont develloppé le soft qui l'utiliseront, et comme +d'habitude, tout sera recodé. Certains proposent donc de continuer à travailler +au crans pour essayer d'avoir un nouveau binding qui pourrait être proposer +comme brique de départ au projet commun de l'ares qui naitra d'ici un ou deux +ans. Cela implique évidemment que l'on soit capable de notre côté de boucler le +projet en environ un an. Mais le doute persiste concernant la collaboration +future des assos si on joue dans notre coin. + +Là deuxième moitié du second point concerne le choix des technologies de +devellopement du nouveau binding. D'aucun dise que ldap ça envoie du boudin et +que sql reste loin derrière. Si il semble établie que les librairies utilisant +ldap pour l'auth sont bien plus robustes et éprouvées que celles pour sql, la +question des performances est cependant plus épineuse. On trouve beaucoup de +random post sans vrai benchmark. Un récent benchmark de Daniel montre que +django est un peu plus lent que ldap qui est lui meme plus lent que sql simple. +Par ailleurs, d'un point de vue facilité de dev, django reste loin devant. Par +suite, une idée peut être d'avoir un coeur de base ldap juste pour l'auth, et +une base annexe psql/django pour tout le reste des infos. Vouloir passer le +crans sur ce genre de binding est cependant beaucoup plus ambitieux que +de "juste" passer à lc_ldap 3, et comme dit précédement, mettre en place ce +genre de projet semble n'etre pertinent que si on peut le mener à bout d'ici un +an. + +### Ethercalc : mise en prod et système d'auth + +Ethercalc est prêt, mais il n'y a pas encore de système d'auth. + +On pousse ! + +L'idée est de faire une auth côté nginx -> sur plopissecured.crans.org ? + +### Baie de disque + +Elle est baie-hate !! + +Il y a plein de disque de 600go maintenant. Sauf que seul leurs 300 premiers Go +sont utilisés... + +La baie ne supporte un extend que lorsqu'on ajoute un disque. + +Option 1 : + +* On fait du ménage sur les vm +* On save tout sur les homes +* On formatte et reconstruit la grappe vm +* On redrop les vm à leur place. + +Option 2 : + +* On desactive les deux disques de 600Go de la grappe vm +* Avec les deux spare+ les deux nouveaux de 600, on crée un nouveau raid. +* On commence à transférer les données. +* Dès qu'un disque est libre on le retire de l'ancienne grappe on et le rajoute + à la nouvelle avec un extend. + +Option 3 : + +* Faire mumuse avec slon + +On y réfléchit ! + +Apprentis : Fardale, Rémi + +### Traduction de l'intranet + +Appel à bonne volonté. + + + +Cf le pad pour qui fait quoi. + +### Question diverse + +* Qui veut des chips ? diff --git a/compte_rendus/2016_02_11.md b/compte_rendus/2016_02_11.md new file mode 100644 index 0000000..fffd6a5 --- /dev/null +++ b/compte_rendus/2016_02_11.md @@ -0,0 +1,166 @@ +# Réunion du Collège Technique + +* Date : +* Lieu : PdJ +* Début : 19h07 +* Fin : 21h30 +* <> + +## Présents + +* Daniel Stan +* Hamza Dely +* Martin Bauw +* Mathilde Espinasse +* Rémi Oudin +* Lucas Serrano +* Gabriel Detraz +* Charlie Jacomme +* Pierre Elliott Bécue + +## Ordre du jour + +### Avancement de la traduction + +Avec la traduction, modifier/ corriger une typo devient un peu plus compliqué, +il faut penser à modifier tous les fichiers de trad et à les re-générer. + +On attend un dernier commit et on pousse en prod ! Il n'y a pas d'autres +grosses branches, donc il n'y aura pas trop de merge. + +Ping est chaud pour faire un truc joli pour le choix des langues. + +Un problème majeur est apparu lors de la traduction : crans ou cr@ns ??? (Crans) + +On passe au vote, pour la typo "Crans" : + +* 6 pour +* 2 contre + +La typographie "Crans" est adoptée par le CT. + +### Maintenance pendant les vacances + +Deux points importants : + +* Migration de vm capitales (vert) sur le cluster jessie. +* Firmware upgrade de la baie. + +Samedi 20 février, maintenance et coupure générale, à partir de 10h jusqu'a si +possible fin de journée. (Présent : Daniel, Hamza, Peb, Charlie, ... ?) + +Penser le 16/17 février à vérifier les backups. + +On essaie de faire un max de trucs, selon comment ça se passe. + +D'ici là, il faut quelqu'un avec une Fedora/Red Hat. + +### Discourse (scourse)™ + +On propose que plus personne n'ait les droits admin par défault. Quelques +nounous seront des nounous "référentes", qui auront un compte admin +en `-admin`. + +Référents : + +* Ping +* Becue +* Charlie +* Jordy + +Les nounous ne sont donc pas censées se donner les droits admin de manière +unilatérale. + +### IP adh + +On propose d'augmenter le nombre de machines filaires à deux par adhérent. Cela +implique de mettre le script de nettoyage des machines inutilisées (attention à +épargner les clubs) en place. + +Il faut modifier l'intranet, gest_crans et le binding. + +Modification : Chirac + Guinness + +### Planning Permanences + +Des nounous d'astreintes ont remplis certains créneaux vide. + +### Let's encrypt + +Ça marche sur zero2, le cert global est prêt, on enchaine ? + +On lance pour discourse, (scourse)™, zero, pad, calc. + +On va s'occuper des sites les uns après les autres : + +* Donner l'alias site.crans.org à bakdaur, après l'avoir retiré à la machine. +* Rajouter un fichier de conf nginx à bakdaur pour qu'il proxypass + site.crans.org vers site.adm.crans.org +* Faire émettre site.crans.org sur site.adm.crans.org + +Il faut faire attention à la factorisation des fichiers de conf nginx. + +### Installation de bornes wifi SDA + +Diane souhaiterait disposer d'un câble éthernet (pour leur TPE) et de Wifi (les +caissiers vont avoir des PCs pour accéder à la note Kfet), le tout au niveau +des caisses du Gala (à l'intérieur). +NB: les sENS de l'Art auront lieu le samedi 19 mars. + +Il faut qu'ils voient avec le BDE pour avoir la note. Il n'y a a priori pas de +problème, il faut juste quelqu'un qui soit présent. + +### Serveur virtuel de Test + +Ping veut que le crans mette à disposition 2 serveurs virtuels pour faire des +tests. + +Le prochain qui a besoin créera la vm. + +### "Vert !" + +* Quand est-ce qu'on mange ? +* Rémi est désormais Nounou, plein de bonheur à lui. Mouhahah. + +```txt + `-.`'.-' + `-. .-'. + `-. -./\.- .-' + -. /_|\ .- + `-. `/____\' .-'. + `-. -./.-""-.\.- ' + `-. /< (()) >\ .-' + - .`/__`-..-'__\' .- + ,...`-./___|____|___\.-'.,. + ,-' ,` . . ', `-, + ,-' ________________ `-, + ,'/____|_____|_____\ + / /__|_____|_____|___\ + / /|_____|_____|_____|_\ + ' /____|_____|_____|_____\ + .' /__|_____|_____|_____|___\ + ,' /|_____|_____|_____|_____|_\ +,,---''--...___...--'''--.. /../____|_____|_____|_____|_____\ ..--```--...___...--``---,, + '../__|_____|_____|_____|_____|___\ + \ ) '.:/|_____|_____|_____|_____|_____|_\ ( / + )\ / ) ,':./____|_____|_____|_____|_____|_____\ ( \ /( + / / ( ( /:../__|_____|_____|_____|_____|_____|___\ ) ) \ \ + | | \ \ /.../|_____|_____|_____|_____|_____|_____|_\ / / | | + .-.\ \ \ \ '..:/____|_____|_____|_____|_____|_____|_____\ / / / /.-. +(= )\ `._.' | \:./ _ _ ___ ____ ____ _ _ _ _ _ _ _ ___\ | `._.' /( =) + \ (_) ) \./ |\/| |__) |___ |___ |___ _X_ _X_ \/ _|_ \ ( (_) / + \ `----' """""""""""""""""""""""""""""""""""""""""""""""" `----' / + \ ____\__ __ __ _ __ _ _ __ ________ _____ __/____ / + \ (=\ \ (_ |_ |V||_)|_ |_) |_|(_ / | | |_ | / /-) / + \_)_\ \ __)|__| || |__| \ | |__)\___|__|_ | _|_ / /_(_/ + \ \ / / + ) ) _ _ ( ( + ( (,-' `-..__ __..-' `-,) ) + \_.-'' ``-..____ ____..-'' ``-._/ + `-._ ``--...____...--'' _.-' + `-.._ _..-' + `-..__ __..-' + ``-..____ ____..-'' + ``--...____...--'' + +``` diff --git a/compte_rendus/2016_03_10.md b/compte_rendus/2016_03_10.md new file mode 100644 index 0000000..c5d4a95 --- /dev/null +++ b/compte_rendus/2016_03_10.md @@ -0,0 +1,249 @@ +# Réunion du Collège Technique + +* Date : +* Lieu : PdJ +* Début : 19h00 +* Fin : 20h36 +* <> + +## Présents + +* Hamza Dely +* Vincent Legallic +* Martin Bauw +* Lucas Serrano +* Mathilde Espinasse +* Rémi Oudin +* Gabriel Detraz +* Daniel Stan +* Charlie Jacomme + +## Ordre du jour + +### SDA : bornes + +Les Sens de l'Art voudraient des bornes +Wifi (cf [précédente IN](./2016_02_11.md)), Hamza et +Martin s'en occuperont. + +### Redondance ou augmentation des risques + +On débriefe un peu les échecs de Vendredi et Samedi dernier. + +La constatation générale est que notre archi n'est pas réellement "redondée". +En effet, si on passe de 1 à 3 serveurs qui font "la même chose", si c'est bien +fait, on passe les chances d'échecs à /3, +alors que si quand un seul merde les 3 foirent, on passe à *3. + +Actuellement, nous avons en théorie de redondés : les virtualiseurs, le DNS, le +LDAP, l'auto radius. +Sauf que force est de constaté que dans plusieurs cas, en fait, il suffit qu'un +seul merde pour que tous merdent. +Exemples constatés : + +* 1 virtualiseur seul considère qu'il n'a pas le quorum : ça marche pas + * Pour régler ça, le quorum a été passé à 1 pendant le reboot. + +. Cela signifie qu'un virtualiseur pourrait être coupé des +autres (''brainsplit'') et penser qu'il est le cluster alors que le cluster est +formé par les deux autres, et donc lancer des VMs sans savoir qu'elles sont +déjà lancées sur l'autre. +. On va remettre le quorum à 2 pour éviter les ''brainsplit''. + +Stratégie : + +* Remettre le quorum à 2 et 1 voix chacun pour les virtualiseurs. +* Remettre en place le rsync permettant d'avoir un beau cranspasswords à jour + sur {{{soyouz}}} +* Dumper régulièrement la partie doc du wiki pour le servir en statique + sur {{{soyouz}}} + * En fait "la partie doc du wiki" c'est pas défini. On propose de dumper le + tout (sans les PJs), voir combien ça pèse… +* Mettre à jour la doc Comment rebooter le 0B, et '''l'imprimer, la plastifier + et la placarder au 0B''' +* Déplacer vert sur thot + +On propose de plus de mettre en place un serveur qui fasse tout (radius, +routage, dhcp, ldap-readonly, dns physique), type "on l'allume, et ça marche" +{{{komaz}}} est d'abord proposer, mais sable semble plus pertinent pour cela, +une fois que son activité actuelle aura été virtualise (Remi et Mathilde +s'occupe de la virtualisation). + +On met {{{keepalived}}} sur sable, il peut ainsi redonder/alléger la charge des +autres. Manuellement, en cas de merde, on lui donne une grosse priorité et il +prend la main sur tout le monde et assume le boulot. + +À propos de {{{keepalived}}}, on a eu le problème que {{{eap}}} ne marchait +pas pour l'auth wifi, mais {{{pea}}} pouvait pas prendre la main parce +que {{{eap}}} a son keepalived qui tourne toujours. + +* => écrire un vrai script de test de fonctionnalité du serveur radius (qui + simule une *vraie* authentification) + +Ping fait remarquer qu'il existe [Linux High +Availability](http://www.linux-ha.org/wiki/Main_Page) qui peut faire à peu près +la meme chose que keepalived mais en monitorant des services. +À voir si ça peut piquer les IPs tout comme keepalived. Ping regarde si ça fait +ce qu'on veut. + +### La baie + +Les échanges de Charlie avec HP : + + + +Une fois qu'on aura master {{{sable}}}, on prévoira une nouvelle coupure et on +fera les firmware upgrades. +(On pourra en profiter pour tester toutes nos histoires de failover.) + +Pour que les firmware upgrades "tombent en marche", il faut les lancer depuis +vo... + +On propose de renommer la baie "rezina". Motion acceptée à l'unanimité. + +### KVM + +Brancher/débrancher/faire des acrobaties derrière l'armoire serveurs n'est pas +toujours très pratique. + +Il faut commencer par tester si le KVM marche encore, il faut changer l'alim. +Ensuite, il faudra acheter des jolis adaptateurs. + +Hamza a un peu regardé ce qu'on peut acheter. Il faudra commander et tenter de +brancher. + +### Serveur pour FedeRez + +FedeRez a pour projet de proposer de la virtu pour les associations membres. Il +avait été suggéré de préter kdell en novembre. +Ce serait bien que du coup FedeRez s'engage à migrer baldrick sur cette +nouvelle machine physique dans un délai raisonnable +(baldrick prend beaucoup de place disque sur notre baie, et ça deviendrait +injustifié si machine physique à côté). + +Pas d'objection, à valider par le CA. + +### Ménage au 0B + +L'armoire contient encore {{{dyson}}}, coquille vide à basarder. + +Migrer {{{dyson}}} au 0C (il a été shreddé). + +Quid de {{{osm1}}} et {{{osm3}}} ? +OSM a pas encore décidé de ce qu'il en font. Les relancer + +### Ménage au 0C + +Prévenir les respo-info BDE quand on ira à la déchetterie, ils ont des +carcasses de leur côté aussi. + +Pour le toner, le contrat conibi c'est fait, se bouger le cul. + +### Ménage au 4J + +Faut (re)envoyer des mails à HP pour avoir des étiquettes de retour pour le +toner. +Comme HP n'en envoie qu'une à la fois, il faudrait croner le mail de demande. + +### Internet au RU + +Le CROUS voudrait qu'on desserve le RU. + +On peut pas fournir un accès wifi à tout le monde (légalement), donc on peut +leur proposer de voir avec l'ENS pour eduroam. +Servir eduroam ne serait en théorie pas trop compliqué sur nos bornes, on a +juste besoin des identifiants. + +Si le CROUS veut autre chose que du Cr@ns (pour les adhérents) et du +eduroam (pour ceux qui l'ont), à eux de voir avec l'ENS. + +On est pas d'accord pour tirer les câbles car cela représente un temps assez +considérable. On voudrait également qu'ils payent le matériel nécessaire a +l'installation. +On pourrait leur faire un devis. + +Gabriel répondra ça à Benjamin DUBOURGEAT (contact au CROUS qui a fait cette +demande). + +### Cache Steam + +Fardale souhaiterai si possible mettre en place un cache steam, blizzard, riot, +ea sur le campus. +Ce qui nous permettrait d'économiser de la bande passante et de fournir un +meilleur débit aux adhérents quand ils cherchent à contacter steam. + +Page vers la mise en place +du [cache Steam](https://developer.valvesoftware.com/wiki/SteamPipe). + + + +Ce serait gourmand en espace disque (~1To d'après Fardale). +D'un point de vue compatibilité avec les objets de l'association, ce n'est pas +très clair, du coup, on préfère faire ça avec du matos de récup (disques +changés, un des serveurs OSM ou {{{komaz}}}). + +En tout état de cause, ce n'est pas un point urgent. +On n'est pas vraiment contre le principe, mais la consolidation de l'archi +actuelle est prioritaire. + +### Imprimante + +Le PJL arrive. +Daniel voudrait aussi qu'on puisse choisir l'imprimante vers laquelle imprimer +depuis l'intranet. + +### Let's Explode all the things + + marche pas ce soir. + +Vérifier que les IP réelles sont bien forwardées par bakdaur/frontdaur au vrai +serveur derrière. +Ça, c'est fait pour tout le monde. + +Il faut que cette IP forwardées soient comprises par le serveur cible. +À vérifier. + +### Discourse et le monde extérieur + +Il faudrait investiguer les moyens d'auth pour savoir si on peut limiter +l'accès au campus. + +#### Install Party + +* Certains PXE ne fonctionnent pas. Debian et Ubuntu fonctionnent, mais les + autres non +* Qui sera là quand ? + +### Jabber + +Fardale aimerai suivre les IN sur Jabber. +Quelqu'un installera jabber pour la prochaine fois. + +### Questions diverses + +#### Promouvoir un autre client IRC ? + +Actuellement, la commande "irc" sur zamok lance irssi. +20-100 suggère de remplacer ça par weechat. + +Pourquoi ? + +* Parce qu'il propose pleins de trucs mieux (subjectif) +* Parce qu'il est plus noob-friendly (un peu plus + objectif (cf /help, /set *recherche*…)) +* Mais surtout parce qu'un nombre écrasant de cranseux l'utilise et peut donc + aider à répondre aux questions des débutants. + +Accessoirement, un certain nombre de jeunes a récemment découvert IRC et trouvé +ça rigolo, ce serait pas mal de surfer sur la vague et de leur faire une +comm' sur le sujet comme Jordy l'a fait pour discourse. +Il serait alors de bon ton de prévenir sur les news & discourse, mais aussi +sans doute par mail les utilisateurs fréquents de zamok, dont on peut avoir la +liste (même en tant que simple adhérent) grâce à quelques {{{last}}} bien +sentis… + +Daniel suggère que ça fasse carrément le screen (ou le rattache si il existe +déjà). +20-100 s'en occupe. + +Vote : Pour a l'unanimité moins deux abstentions. diff --git a/compte_rendus/2016_03_24.md b/compte_rendus/2016_03_24.md new file mode 100644 index 0000000..a2a9c48 --- /dev/null +++ b/compte_rendus/2016_03_24.md @@ -0,0 +1,92 @@ +# Réunion du Collège Technique + +* Date : Jeudi 24 Mars 2016 +* Lieu : PdJ +* Début : 19h00 +* Fin : 19h59 + +## Présents + +* Mathilde Espinasse +* Kévin Le Run +* Lucas Serrano +* Martin Bauw +* Daniel Stan +* Rémi Oudin +* Gabriel Detraz +* Renaud Taleroy + +## Ordre du jour + +### Serveur pour FedeRez + +La précédente réunion technique avait évoqué le prêt de kdell et non un don. Le +CA s'étant réuni par la suite a voté un don, Daniel était présent à cette +réunion et s'excuse platement pour le malentendu … +Étant donné que le serveur nous a été donné par la fondation free et ne nous a +jamais rien coûté. De plus, une seule nounou semble depuis s'être exprimée +contre ce don, mais le motif du refus n'était pas technique. On propose donc de +céder le serveur, ce qui est acté à l'unanimité des nounous présentes. + +### Impression + +Daniel fait une démo de l'utilisation du driver via un proxy sur vo et une +connexion sur le serveur cups. +Au début ça avait l'air de marcher mais on constaté quelques plantages (tout de +même très rares). + +Le basculement de driver s'effectue très facilement à l'aide du systèmes de +classes de cups : il suffit de changer les imprimantes activées dans la +classe "MFPM-880". En cas de pépin, on peut donc revenir en arrière pour +certaines impressions. +Nom de l'imprimante avec le nouveau driver : MFP-PCL. +Si besoin on peut remettre l'ancien driver : imprimante MFPM880-1. + +Prochaine étape: Créer plusieurs imprimantes "physique" (au sens de cups) et +les mettre dans la même classe virtuelle, et faire du load balancing. +Une autre idée : envoyer les impressions A3 en plusieurs exemplaires une à une, +en vérifiant avant chaque envoi qu'il reste du papier A3. Ceci permettrait +d'éviter de bloquer l'imprimante sur un défaut de papier A3 (->phabricator). + +### Pages perso + +On a mis en production une modification de l'application de création de bdd +mysql sur zamok pour les pages personnelles des adhérents. Cette mise à jour +permet la gestion des bases de données des pages perso des clubs. + +Problème : les bases de données étaient précédemment gérées à la main et il +faut renormaliser les noms actuels : on va +contacter les adhérents/clubs dont le nom de base de données ne correspond pas +au login Crans. + +### Oison + +Oison ne veut imprimer que lorsqu'elle est dans la mauvaise pièce (« Printers +are sent from hell »). Problème de faux contact ? Relancer le démon après +chaque "rebranchage" Ethernet ? Problème à investiguer (Rémi s'en occupe). + +### Questions diverses + +#### Phabricator + +Les tâches sont par défaut publiques, on se demande si ça se règle … + +#### Etherpadtex + +Rémi propose de rajouter une feature au pad pour faire du \LaTeX, à essayer … + +#### Mots de passe mailing-lists + +On profite de la réunion pour briefer les apprentis sur l'usage de +cranspasswords pour les mots de passes MlBureau/MLCa. + +## Signing Party + +On profite de la réunion pour réaliser les signatures des nouvelles clés PGP +des apprentis. + +## Réunion technique ARES + +Chirac propose une réunion technique pour le projet ARES. Elle aura lieu cette +fois-ci à Cachan: un sondage sur le choix de la +date : diff --git a/compte_rendus/2016_04_21.md b/compte_rendus/2016_04_21.md new file mode 100644 index 0000000..b6cce8c --- /dev/null +++ b/compte_rendus/2016_04_21.md @@ -0,0 +1,141 @@ +# Réunion du Collège Technique + +* Date : 21 Avril 2016 +* Lieu : Pavillon-Des-Jardins +* Début : 19h13 +* Fin : 20h11 +* <> + +## Présents + +* Lucas Serrano +* Martin Bauw +* Daniel Stan +* Gabriel Détraz (via Jitsi) +* Hamza Dely + +## Ordre du jour + +### Jitsi-meet + +Jitsi-meet est un service de visioconf (à la "hangout"®©) qui fonctionne avec +la techno webRTC. Lucas a fait des tests sur + +test1.crans.org, et a eu l'occasion de tester pendant 1h30, 8 participants, le +serveur a généré un peu plus de 13Go d'upload. + +* Est-ce que tout le monde était en HD ? --> On sait pas, mais la qualité n'est + pas réglable +* Est-ce qu'on peut configurer plusieurs relais (le but était d'avoir un point + de sortie hors crans, chez ovh pour le traffic à destination d'ip extérieure + au campus) ? --> problème ouvert +* truc cool : le chiffrement est activé + +Petits bugs : + +* remplit les logs (très verbeux) +* marche pas sur la machine de Daniel (ni iceweasel) --> à diagnostiquer + +--> Restreindre les accès en whitelistant les ip federez ? (à l'intérieur du + réseau Renater, afin de justifier une excemption d'upload pour la + machine) -- Compliqué mais faisable + +> En profiter pour mettre au point un moyen pour partager automatiquement des +données entre assos. Au moins lisible, éventuellement inscriptible par des +scripts ?. (Y'a des apprentis à FedeRez/l'ARES ?) + +--> VM Crans ou ARES ? Nayef suggère de mettre ca sur des vm ARES, Ping suggère + lui d'avoir 3 noeud sur chaque campus. + --> pourquoi pas, si un apprenti du crans -- Blupon tu es engagé -- est + impliqué et qu'on applique les limitations exprimées plus haut, du moins + dans un premier temps. + --> on verra plus tard pour les histoires de pont … + +Il faut aussi documenter l'install. + +### Zamok v5 + +Zamok sort de garantie en septembre prochain, probablement non renouvelable. +Hamza propose donc de faire un devis pour un nouveau serveur. La question, +c'est : veut-on un serveur des adhérents plus puissant ou pas ? + +* Poser la questions aux adhérents utilisateurs ? +* Utiliser un autre serveur, sable est proposé, mais il va aussi sortir de + garantie, et on le réserve déjà comme routeur/système tout en un de + secours (lui mettre tous les services de zamok le rendra plus trop système de + secours …) + +On envisage de prendre un modèle équivalent en puissance (ie, pas une bête de +course) et de rester sur un fonctionnement fair-use, ie si un adhérent a besoin +de ressources, l'autoriser si l'usage ne nuit pas au fonctionnement global du +serveur (autres utilisateurs, délivrance de mails et pages perso). + +Pour l'ex-zamok, du coup, on pourrait : le mettre dans le cluster de +virtualisation même si il n'est plus sous garantie ? +Si on tente ça, penser à vérifier que le jeu d'instructions est +compatible… Quelle utilité sachant qu'on a enlevé kdell ? Moar +power ! À creuser. + +### Cartographie du réseau pour optimiser la gestion des fréquences WiFi + +But : remapper les fréquences WiFi des bornes pour qu'elles arrêtent de se +marcher sur les pieds. +Daniel et Martin sont sur le coup. + +### Babar + +Babar a brûlé il y a 10 jours, nous avons acheté un nouveau serveur HP dans +l'urgence. Contrairement à nos craintes les nouveaux emplacements disques sont +compatibles, Hamza le ré-installe (seul le disque système a péri). + +Bienvenue donc +à [zephir](https://fr.wikipedia.org/wiki/Babar#Autres_personnages) ! + +### Charybde + +Le disque système SSD a été installé avec succès, le RAID (avec les +données) n'a pas été refait (donc pas de miroir à reconstruire). Niveau +performance, plus de latence au niveau du système, donc c'est pas mal. + +### CAS + +Valentin et Myriam (pas présents) ont prévu de migrer le CAS en utilisant leur +implémentation custom en Django (pour remplacer l'actuel tomcat en Java), nous +n'avons pas plus l'info là-dessus. De la documentation serait la bienvenue. + +Le cas semble avoir été mis à jour sous jessie (il semble bien se porter). + +### Questions diverses + +#### routes + +Les routes IPv6 (de zamok, essentiellement, mais comme c'est surtout à lui +qu'on se connecte, c'est surtout chez lui qu'on constate le problème) ça marche +en fonction de la pluie et du beau temps. +Il semblerait que ce problème n'existe qu'au boot. +20-100 n'est pas convaincu. Il essayera d'investiguer la prochaine fois qu'il +rencontrera le problème. + +#### April fool's prank part 3: odlyd ? + +Le technicien a réussi à nous remplacer la bonne carte mère sur le bon serveur. +Deux jours plus tard, le routeur a de nouveau subi un kernel panic. +L'assitance nous propose le remplacement du cpu demain vendredi 22 avril. On +essaiera de réveiller Hamza pour s'occuper du routeur fallback. +Il faut vraiment relire le contrat de maintenance afin de savoir ce qu'on est +réellement en mesure d'exiger d'HP. + +#### Màj de la baie ? + +Personne n'est disponible dans l'immédiat pour s'en occuper. Le système de +secours sur sable n'est pas encore fini (ce qui permettrait de shutdown la baie +de disque en coupant les services, mais pas Internet) + +Ça en est ou ? +Guiness et Mathilde ont créé la machine virtuelle destinée à héberger à terme +le dns principal (pour pouvoir en libérer sable), il reste à configurer ledit +serveur dns, puis à faire la migration des zones. +Attention, ça voudra dire que les seuls DNS primaires non virtuels seront +soyouz et freebox. En cas de boot from scratch, on a hardocdé les IPs +nécessaires, mais on peut avoir besoin d'autre chose… +Ça rassurerait 20-100 qu'on ait un DNS primaire physique. diff --git a/compte_rendus/2016_09_01.md b/compte_rendus/2016_09_01.md new file mode 100644 index 0000000..fc46a92 --- /dev/null +++ b/compte_rendus/2016_09_01.md @@ -0,0 +1,365 @@ +# Réunion du Collège Technique + +* Date : Jeudi 1er septembre 2016 +* Lieu : Pavillon des Jardins +* Début : 19h00 +* Fin : 22H05 +* <> + +## Présents + +* Hamza Dely +* Gabriel Detraz +* Charlie Jacomme +* Daniel Stan +* Myriam Bégel +* Mathilde Espinasse +* Renaud Taleroy +* Lucas Serrano +* Younesse Kaddar +* Emmanuel Arrighi +* Rémi Oudin +* Vincent Legallic (arrivé à 19h13) +* Michaël Paulon + +## Ordre du jour + +### État des lieux et stabilité + +Le 0B est safe aux inondations de 15cm. Tout est surélevé. Les serveurs +critiques sont sous Jessie, il n'y a plus de problème. Odlyd semble réparé, il +n'y a plus eu de KP depuis plusieurs mois. +La clim a été réparée une nouvelle fois, on espère qu'elle va bien et que c'est +enfin fini. Dernière bonne nouvelle, sable est quasiment prêt en fallback +master. +La solution est qu'il spoofe toutes les ip (dns, dhcp, etc.) Il faut encore +proprifier la conf éventuellement, mais ça semble en bonne voie. + +Daniel propose de se pencher vers Keepalived. De cette manière, il se charge de +vérifier si les services fonctionnent, et si ce n'est pas le cas, il prend le +relais. C'est également l'ocassion de vérifier toutes les configurations de +keepalived pour chaque service et s'assurer que le switch se fait bien +également pour les serveurs de redondances. + +#### NFS + +Beaucoup de problème et de stabilité et de sécurité proviennent du nfs. + +Le NFS est le système de fichier sur le +réseau (). Certains dépôts +comme {{{/usr/scripts}}} sont partagés par le nfs, et c'est potentiellement +dangereux puisque si le nfs tombe, on perd tous nos scripts. +Ce qui s'est passé le 28 : une commande foireuse suite à un énième remontage en +ro d'un home a coupé nfs-kernel serveur, il nous a été impossible de le +relancer. Cela a provoqué une panique en chaine sur zamok en premier, avec tous +les users qui essayaient d'accéder à leur home ; le moindre ls tournait en +boucle. + +Seul un reboot de zbee, avec une mauvaise surprise habituelle (grub-rescue) a +permis de relancer le nfs. Il a fallu entre autres rebooter zamok ; l'intranet +également (qui accède aux home et a lui aussi paniqué). +Les autres serveurs n'ont pas besoin des home, ils n'ont pas paniqué ; mais le +dhcp et le radius ont planté du fait de l'absence de usr/scripts… Ce qui est +très problématique, la coupure aurait pu être plus indolore sans cela. Seul +odlyd a continué à router normalement, les règles du parefeu sont restées en +place jusqu'à ce que usr/scripts revienne, bon point de ce coté là. + +Il existe actuellement 3 exports nfs : les homes, la virtu +et {{{/usr/scripts}}}. + +##### /usr/scripts + +L’intérêt du /usr/scripts over nfs est très limité ; l’expérience prouve qu'un +git pull fait par monit avec alerte si cela foire fonctionne très bien, ironie +du sort, sur zbee lui même ! +Je propose donc d'abandonner /usr/scripts over nfs, et de mettre le dépot en +dur sur les serveurs. Il ne pèse pas très lourd, 50 megas à tout casser. + +On gagne énormément en stabilité ; à titre d'exemple, en cas de plantage de +zbee le 28, le réseau aurait entièrement continué de fonctionner (dhcp, radius +etc) ; seul les mails et zamok auraient été impactés à cause du plantage de +l'export des home. On renforce également très fortement la sécurité. + +La plupart des fichiers qui pèsent sont surement inutiles dans +usr/scripts (fichiers de logs des bornes). Alors on autorise monit à git pull à +chaque commit. + +La décision est validée par le CT. + +Ping propose une autre solution qui passerait par bcfg2 pour éviter d'avoir +tous les scripts partout et de ne plus savoir qui doit être où. Cependant, ça +demande beaucoup de travail, et on ne gagne pas forcément beaucoup en +stabilité. La question pourra être réabordé dans le futur une fois que +le /usr/scripts sera safe. + +##### les Homes + +C'est de loin le plus problématique sur le nfs. À moyen terme, il convient de +réévaluer la pertinence des home sur la baie qui est plus que limité. + +Chirac propose donc d'acquérir ou de constituer 2 nas, fonctionnant avec ceph, +ce qui permettra au passage de tester cette technologie qui semble mature et +robuste, et de migrer ensuite l'ensemble des home dans cette grappe de nas. + +Charlie imagine un NAS logiciel. Dans ce cas, on peut prendre du SATA, et donc +prendre des gros disques, avec du RAID logiciel. Chirac remarque que +ceph + raid5 se fait facilement. + +Charlie demandera un devis à Anne. Ping fait remarquer qu'au pire, elle peut +Anne-uler. + +###### La virtualisation + +On peut la laisser à moyen terme dans la baie, et réévaluer la situation en +temps voulu. Il est à noter que proxmox gère nativement ceph, si on souhaite +fonctionner là aussi avec une grappe de nas. Auquel cas il sera pertinent de +pas recommencer les mêmes erreurs, et de séparer le stockage des adhérents de +la virtualisation… + +Pour la virtualisation, on verra plus tard après avoir testé avec les Home. + +#### Ram pour virtualiser + +Il est apparu qu'on ne pouvait mettre toutes les vm sur un seul virtualiseur +par manque de ram, ce qui est un peu bête. Chirac propose d'acheter 32 gigas de +ram pour stitch, idem pour ft, vu le prix que cela coute, l'investissement vaut +le coup. À ce moment là le réseau pourra tourner entièrement avec un seul +virtualiseur up (stitch ou ft). + +En mettre 32Gb sur les deux virtualiseurs est un peu overkill. L'objectif est +de pouvoir faire tourner toutes les VMs sur le même serveur. Actuellement les +VMs sont un peu maigres en RAM, ça permettrait de resizer pour éviter que les +VMs se bloquent quand une upgrade prend plein de RAM. + +Daniel propose de lister les VM vraiment vitales. On regarde les besoins en +RAM, quitte à modifier, et on considère que c'est le minimum sur le +virtualiseur principal. Les VMs de redondance iraient sur les autres +virtualiseurs, quitte à les éteindre en cas d'urgence. + +Hamza se charge de faire le calcul : Il faut 18Go de RAM pour faire tourner les +VMs critiques. Charlie demandera un devis à Anne. + +Ping remarque qu'il faudrait mettre 1Go minimal en RAM max (et 512 en mini) sur +les VMs, en dessous on en a moins qu'une Raspberry Pi. Charlie se propose pour +faire ça. + +#### Redondance + +Les VMs redondantes. Quand on a éteint des VMs quand le 0B +chauffait (24/08/2016), y'a eu un certain nombre d'incompréhensions, au moins +de ma part sur lesquelles étaient redondantes. Est-ce que 2 VMs censées l'être +le son vraiment (ie y'en a pas une des 2 qui ''en fait'', fait un truc en +plus) ? Exemple typique : un des 2 serveurs radius fait en fait Federez-Wifi +en plus. + +16:54:42 &tudor : si vous voulez un protocole (en général), l'idée que je +suggère c'est de garder les vm de redondance (pea, isc) ou inutiles sur le +virtualiseur le moins puissant +16:54:54 &tudor : et de l'éteindre au premier pépin + +keepalived : je prétends que sa config pour les trucs qu'il est censé failover +n'a pas été testée. Prove me wrong :) + +Il faut mettre à jour la page wiki sur les VMs redondées, savoir qui fait quoi +exactement. La mise en place de Keepalived sur sable permettra de faire une PoC +sur tous les services. + +### Planification installation zamok + +Si le CA est gentil, on aura un nouveau zamok à installer. Où, quand, qui et +comment ? Warning : wild problems may appear everywhere… + +Update : le CA est gentil :) + +Il va falloir l'installer puisque le CA est gentil. + +Un des problèmes est que le digicode est sur zamok. Charlie propose de tuer ce +vieux service et de passer au nouveau digicode (à finir et à patcher). Le +nouveau service coûte grand max 150€. + +Charlie peut proposer un devis pour le CA. Un prototype marche avec des trucs +sales, mais du coup on peut faire marcher avec un truc propre. Le système au 2B +est quasiment fini. + +Par contre, il faut vraiment s'y mettre pour le finir, et pas le laisser +traîner. + +Avoir le digicode prendra malgré tout 2-3 mois, on attendrait donc pour mettre +zamok en prod. On prend donc le temps de le reconfigurer from scratch. +. + +↑ Ce commit prétend qu'on peut changer l'IP/MAC du serveur digicode avec le +digicode actuel. (Le digicode n'est donc pas bloquant pour changer +zamok). -- Daniel + +Accessoirement, ce serait bien de faire un dump des paquets installés sur Zamok +et de trier ceux qu'on garde et ceux qu'on jette. +apt-mark showmanual ? + + +#### Apt-dater + +C'est en place, cela juste marche. Démo prévue (Chirac). On peut abaisser le +niveau de vérification pour que ce soit encore plus pratique, mais attention +danger. + +Il faut les répartir en groupes (critique, autres, services…). La config est +dans /root/.config/apt-dater/hosts.conf pour les groupes. Il faudrait que ça +soit généré automatiquement par bcfg2 (voir pour la création de services.py +pour un exemple) + +Il faudrait aussi gérer le cas des serveurs/VMs marqués en unknown. + +### KVM + +Pendant le stage de Hamza, on a reçu le module kvm usb, ça marche. On a pas +d'alim qui fonctionne, il faut en racheter une, ainsi que la dizaine de modules +kvm nécessaires. + +### policyd-rate-limit + +Il y a eu des problèmes de spams par des vieux comptes inutilisés. Il n'y avait +pas de limitations du nombre de mails si on changeait d'ip. Plein de serveurs +nous ont blacklisté pendant un temps. + +Nit a développé un script pour gérer ce problème. Si la limite est dépassée, +postfix envoie une erreur smtp qui correspond à des limites dépassées. + +Mailman ne semble pas impacté par policyd-rate-limit. + +On peut fixer une limite par jour (genre 500 mails). + +Hamza propose de s'en charger. + +Il faut aussi créer une campagne de changement de mot de passe (projet +apprentis). + +#### Ethercalc + +Suite au reboot du 2 août, il semble que ethercalc n'avait pas redémarré. Nit a +fait un redémarrage par la suite, mais à la main. + +Renaud avait fait un init script, il faut juste le retrouver. Il s'en charge +pour la prochaine IN. Il écrira aussi la doc nécessaire pour comprendre son +installation. + +#### Autres problèmes + +Idées en vrac : + +* Contacts pour la maintenance : + +From: Gabriel Detraz +Date: Tue, 2 Aug 2016 20:47:45 +0200 +Cc: nounou@lists.crans.org +Pour information, j’ai envoyé le mail de la maintenance au adhérents, mais +également aux clubs qui disposaient d’un contact valide.Par conséquent, FedeRez +et l’ARES pour ne citer qu’elles ont automatiquement reçu le mail prévenant de +la coupure. Si ce n’est pas le cas de rezosup ou osm, il faut simplement mettre +à jour les informations de contact dans la base de données. + +Charlie va regarder pour aller voir. 20-100 va regarder dans la base de données +si ils sont bien à jour. + +Il faut créer un club rezosup, et le faire adhérer pour longtemps. Charlie s'en +charge avec 20-100. + +* Les autres trucs redondants. La dernière fois j'ai demandé ce qu'il en était + du fameux quorum des virtualiseurs quand on reboote. C'est peut-être un + problème réglé (ou WONTFIX) mais je ne sais honnêtement pas, et ça peut pas + faire de mal de la rafraîchir dans la mémoire de tout le monde. + +On avait déjà vu ce point. Le quorum est à 2, et en cas d'urgence, il faut +aller le modifier à 1 dans /etc/pve/corosync.conf + +* !MailMan : j'ai pas encore eu droit au code que PEB a fait tourner pour fix + l'encodage. Je voudrais réussir à tester mon + script {{{redisdead:/var/lib/mailman/bin/isthereencodingfail.py}}} avec un + Vrai Positif pour être sûr qu'il teste bien ce que je pense qu'il teste. + +Il reste quelques MLs qui ont des problèmes d'encodage sur l'inteface web : les +MLs dont les adhésions sont générées automatiquement (ex respbats, roots). + +### Auth.py + +Couac avec la période de sursis, les 2A se sont fait massivement envoyer bouler +par auth.py et placer sur le vlan accueil, réglé par +Chirac (involontairement) et PEB. Cela ne devrait plus se reproduire. Bug +également avec le bloq dans auth.py, ce qui explique bien des bugs rencontrés +ces derniers mois… + +Détails : la période de sursis était évaluée au moment du lancement de auth.py +à partir de config.py, or auth.py tourne depuis plusieurs semaines, parfois des +mois sans être relancé. À partir de maintenant, la période de sursis est une +méthode dans config.py qui est chargée à chaque check de has_access (methode +lc_ldap qui évalue si un port/machine a accès ou non). + +Fixed par PEB, qui a transformé les mesures de temps en méthode, et qui sont +donc exécutées au moment du test, et non au moment ou on lance auth.py + +### Questions diverses + +#### Virer SpamAssasin de MailMan + +C'est un projet au long court, il faut pas se précipiter, mais ça pourrait être +pas mal d'y réfléchir. Il pète config_list, il rend la modération relou (les +spams n'atteignent pas le filtre discard_these_nonmembers), il considère que +les mails des caméras sont du spam. Il faudrait d'abord sonder un peu les +utilisateurs de ML pour savoir si il leur sert. + +> On regarde les datas et on en reparle plus tard + +#### Services.py et bcfg2 + +"Quand on modifie services.py, il faut appliquer bcfg2 sur tous les serveurs +pour mettre à jour services.py" +Faux, c'est automatique. + +Autre exemple : ssh_known_hosts. + +#### Température 0B + +Google préconise 23°C, il faudra passer pour remonter, et changer les réglages +munin pour éviter de l'avoir en "Problem" + +Un devis est passé pour une clim de secours, sans que cela soit une mauvaise +idée, et étant données les prestations de la société actuelle, on peut troller +sur la pertinence du truc. +3400 €, douche comprise. + +On en reparle dans 2 semaines, après y avoir bien réfléchi. + +#### Page d'accueil + +Il faut trouver où mettre la page d'accueil créée par Myriam + +Pour dans 2 semaines, il faut que Myriam vienne faire une démo avant la mise en +prod. Et on met le point plus haut dans l'ODJ. + +#### Mises à jour + +Rappel : les mises à jour consistent à lancer dist-upgrade, puis à vérifier +après que tout marche… + +(la deuxième étape est --(aussi)-- plus importante que la première, il ne +suffit pas de cocher la mise à jour comme "faite"…) + +Daniel est fâché à cause de ce qu'il s'est passé. Il rappelle la présence de +systèmes de monitoring qui n'ont pas été vérifiés, voire des serveurs qui n'ont +pas été rallumés. + +20-100 rappelle qu'il faut regarder les changelogs (qui sont obligés d'être +affichés en cas de DU). Il faut les lire et les appliquer. + +Il faut vérifier que tout tourne à la fin aussi. Genre, utiliser le service qui +a été mis à jour, ou qui a du être redémarré. + +#### Vieilles nounous + +Le droit existe, la suite ? + +On finit le script, et on revoit ça après : On veut éviter que des bots +puissent juste exécuter le script et obtenir les droits roots en cas de compte +corrompu. Du coup, une solution est proposée qui serait de poser une question +secrète avant de rendre les droits. Par exemple : Quelle était +ta "maman" ? Quelle était ta nounou préférée ?. diff --git a/compte_rendus/2016_09_15.md b/compte_rendus/2016_09_15.md new file mode 100644 index 0000000..6a4af53 --- /dev/null +++ b/compte_rendus/2016_09_15.md @@ -0,0 +1,106 @@ +# Réunion du Collège Technique + +* Date : Jeudi 15 septembre 2016 +* Lieu : Pavillon des Jardins +* Début : 19h47 +* Fin : 20h55 +* <> + +## Présents + +* 3 invités du Rézo : Shaka, Julien et Julien +* Vincent Le Gallic +* Rémi Oudin +* Gabriel Detraz +* Myriam Begel +* Mathilde Espinasse +* Charlie Jacomme +* Michaël Paulon +* Steeven Janny + +## Ordre du jour + +### Page d'accueil du Crans + +Myriam a fait du boulot, il y a juste quelques élément à recentrer. On pousse +sur o2, et on va commencer par faire de la com, puis on verra si on fait un +mode portail captif à la première connexion. + +Rémi va s'en occuper avec Myriam. + +### Achat d'une clim de secours + +Suite aux récents problèmes, l'idée d'une clim de secours a été amené. Il faut +compter 3400€. + +Personne n'est convaincu de la réelle nécessité, il n'y en a pas eu besoin +historiquement, et faire toute l'installation pour deux ans pourrait être +overkill. Il y a certes eu une grosse série de problèmes (merci PEB d'avoir +géré), mais maintenant qu'il est réglé cela devrait aller. Si d'autres +personnes sont pour on pourra en rediscuter. + +### Digicode + +Le devis est de 70,40€, + +On est parti, on envoie ça au CA. + +### Serveur NAS + +On va pouvoir continuer la discussion, de solution concrète et de prix. + +Après discussion avec Anne, on va contacter le SAV avec elle et elle va nous +aider à faire escalader le dossier. On reparlera du NAS dans un mois si échec. + +Rémi serait dispo pour gérer ça avec Anne, ce sera fait dans le courant de la +semaine prochaine. + +### Trucs cassés + +* Ça fait plus d'une semaine que le [wab irc](http://irc.crans.org/web/) est + cassé depuis le campus. + +Des problèmes quantiques à résoudre, il va falloir étudier la question + +* Idem pour [l'intranet de dev](https://intranet-dev.crans.org/), ce qui est + gênant pour les apprentis développant pour l'intranet --> Réparé par Chirac + hier. + +/!\ Attention, un effet pervers des gens qui tunnellent pour développer est +qu'ils font souvent les migrations sans faire attention à être sous la bonne +version de django ! Du coup, le tunnelling est fortement déconseillé si c'est +pas bien fait. + +Il faudrait faire un check des différentes manières de faire tourner un +intranet local, voir si on peut simplifier. + +### Achat de bornes + +Il n'y a plus de bornes en rab, Chirac suggère d'acheter 5 uap ac normales. + + + +C'est validé pour 5. Envoi du devis au CA par Chirac. + +### Ram pour Stitch + +Le devis est d'environ 540€. + +Les gens sont pour, Charlie envoi le devis en CA. + +### Trucs useless + +Le gitweb, tudor propose de le démanteler et de s'en débarrasser. + +Ça a été annoncé 2 fois sans réaction par un apprentis qui n'ayant pas accés au +log sur le serveur irc n'a pas pu aller plus loin. + +Des questions sont là : est-ce qu'on peut puller le git en http ? est-ce qu'on +peut mapper les vieux dépôts vers gitlab, soit par redirection soit à la +mano (attention à ne rien oublier). + +Charlie regardera ça d'ici la prochaine IN. + +### Nettoyage de printemps + + diff --git a/compte_rendus/2016_11_10.md b/compte_rendus/2016_11_10.md new file mode 100644 index 0000000..5fc75c4 --- /dev/null +++ b/compte_rendus/2016_11_10.md @@ -0,0 +1,133 @@ +# Réunion du Collège Technique + +* Date : Jeudi 10 novembre 2016 +* Lieu : Pavillon des Jardins +* Début : 19h00 +* Fin : 20h42 +* <> + +## Présents + +* Fardale +* Téou +* Chirac +* Dely + +## Ordre du jour + +Hamza a ammené des kinder délices, Hamza est gentil. + +### IPv6 + +Il semble qu'il faille quitter sixxs, quelle est le plan de bataille ? + +Une idée est de commencer à utiliser le préfixe ares. L'avantage principal est +qu'on pourra changer relativement facilement de provider tunnel IPv6 sans avoir +besoin de rechanger toutes les adresses. Le désavantage est que ça crée une +couche de complexité supplémentaire. +Chirac indique que la configuration de {{{quagga}}} est easy, {{{mars}}} est +d'ailleurs en proof of concept. +Le pire qui puisse arriver est qu'on ait plus d'IPv6. + +Charlie, Chirac et Hamza votent pour utiliser le préfixe Ares. + +* Step 1 : tester le tunnel bgp HE +* Step 2 : changer config.py, la BDD, et tous les trucs hardcodés qu'on trouve +* Step 3 : réactiver le DNS IPv6 + +Chirac fait la step 1, tache phabricator incoming. + +### Gros projets en cours + +Un petit tour de table pour voir où on en est sur le master backup, le +monitoring, le firewall, la migration vers lc_ldap et d'autres trucs que +j'oublie. + +Charlie : + +* Full master backup : Configuration stable du DHCP/DNS/radius/routeur sur + sable. Là, Il essaie de bien comprendre comment marche omapi… +* Digicode : Il reste un peu de code à faire + comprendre comment le bidule qui + est actuellement en place marche (quel fil fait quoi ???) + +Dely : + +* Zamokv5 : La step1 est done, le plan de guerre est en place. +* Firewall : Hamza attend toujours des retours sur le code, Guiness a commencer + à relire, mais faudrait qu'on se bouge les fesses. + +Il va le mettre en place sur sable, et on pourra faire des tests et faire +mumuse. + +* Icinga : Le core du truc est en place, toutes les fonctions basiques + d'autostatus tournent sur icinga, mais il en manque encore quelques unes. + +On pousse icinga en prod, et on va essayer de rajouter les quelques plugins qui +manquent le plus vite possible pour nuke autostatus. + +* KVM : Tout est commandé, ça arrive. + +Chirac : + +* Ipv6 et BGP : en cours, c'est tout frais. +* DU de moinmoin : il faut faire un test sur soyouz des modules qui posent + problèmes, puis passer à l'action. + +### Services critiques et mineurs + +Une question à se poser est : est-ce qu'il y a au moins une nounou jeune +capable de s'occuper des services critiques ? Il s'agirait de vérifier ça, et +de pallier à d'éventuels trous. +La même question se pose pour les services mineurs, mais en moins grave. + +Services upper dupper critiques : + +* Routage (Hamza et Chirac) +* DHCP (Chirac et Charlie) +* Radius (Chirac++, Hamza et Charlie +-) +* DNS (Charlie++, Hamza +-) +* ldap (Chirac et Hamza) +* mail SMTP (Hamza++, Charlie +-) + +Services critiques, mais pas trop, enfin, y a internet quoi : + +* NFS (On utilise le script magique, et on a déjà monté des servs nfs à petite + échelle, par contre, iscsi, on est caca) +* Gitlab (Chirac) +* Bcfg2 (Y a un plugin custom, Hamza voit en gros) +* Intranet (On a tous bouffé du python/django) +* Irc (On y connait rien…) +* Mail IMAP (On y connait rien) +* Cas (C'est du Django, ok) +* Webmail (Roundcube est packagé, c'est ok. Horde, on sait pas.) +* Wiki (Charlie a refait une install sur soyouz, mais attention au plugin + custom) +* Page perso (C'est apache, on connait pas) +* Proxy Frontdaur (C'est ok) +* Let's encrypt (Chirac et Charlie)) +* Thot, pqsl (On connait) +* Tunnel soyouz (Hamza) +* Backups (Hamza et Charlie) +* Jabber (???) +* Virtualisation (Ok) +* Rabbitmq (On sait pas, Hamza a une vague idée) +* Quota (Prout) + +Hamza : Apache et page perso +Charlie : va bouffer du nfs et iscsi, et retravailler le mail SMTP +Chirac : Mail Imap + +Guiness et la Loutre : bim sanction, z'avez qu'a pas être absent, jabber et irc +et quota + +### Sogo ??? + +Sogo est devenu payant pour les release prod, on a plus que les nightly builds. +Il faut maintenant un beau support contract, qu'ils aillent ********* +On annonce une interruption de service pour dans un mois. + +### Augmentation des quotas pour les clubs + +Le club salsa est par exemple un peu à l'étroit. On sait pas ce qu'on peut +faire avec quota, et faut savoir le faire marcher. Hamza et Fardale jettent un +coup d’œil, mais pas trop loin pour pouvoir le récupérer quand même. diff --git a/compte_rendus/2016_12_08.md b/compte_rendus/2016_12_08.md new file mode 100644 index 0000000..d207fa1 --- /dev/null +++ b/compte_rendus/2016_12_08.md @@ -0,0 +1,85 @@ +# Réunion du Collège Technique + +* Date : Jeudi 8 décembre 2016 +* Lieu : Pavillon des Jardins +* Début : 19h00 +* Fin : 20h00 +* <> + +## Présents + +* Hamza Dely +* Gabriel Detraz +* Rémi Oudin +* Kévin Le Run +* Charlie Jacomme +* Nathanël Gross--Humbert + +## Ordre du jour + +Hamza a amené un Kinder Bueno, Hamza est gentil. + +### IPv6 + +Lance-t-on le bousin ? + +On peut en effet facilement créer un tunnel BGP chez HE. On est d'accord pour y +passer, on lance donc l'opération. + +En première occurence, on ne s'occupe pas du plan d'adressage, et on modifie +juste rapidement les préfixes. + +### Fails réseaux récents + +A priori, c'était pas notre faute \o/ + +### Vlan 4 + +Tous les switchs sont maintenant dans un vlan à part. Ils restent des choses à +gérer, telles que les requêtes snmp pour le câblage. + +Les différentes solutions pour qu'on puisse avoir whos qui parle aux switchs : + +* Zamok prend une pate sur vlan4, un peu chiant vis à vis du firewall +* Router le vlan 4 à partir d'odlyd, même problème. +* Utiliser une clé ssh qui peux exécuter des commandes spécifiques sur thot. +* Changer de serveur de cablage, thot, créer une vm ? + +Les logs sont déjà centralisés sur thot, y donner l'accès aux cableurs peux +être intéressants. + +On décide donc de passer à la dernière options, le cablage se fera désormais +sur thot. + + +### Seconde intercalaire + +Faut-il faire quelque chose pour les serveurs ? Et pour le ntp ? + +ntp et tzdata sont (probablement) à jour, on fait confiance pour les serveurs. + + +Par contre, l'imprimante...... + +## L'imprimante a ntp de configuré, « It should be fine. » -- DS + +### Achat switchs + +Batp4, switch 8 ports non manageable. Minigiga a le même problème. +Il faut aussi remplacer le switch de la med qui est parti au RU. + +Pour optimiser les switch, on va acheter un switchs qui fait du giga pour le +mettre à la Kfet, et balancer le switchs Kfet à la med. + +Pour batp4 et minigiga, Chirac propose de le remplacer par un 2530-8G, qui +coûte 474€. Batp-4 semble vraiment avoir besoin d'être changé, pour minigiga, +c'est plus optionnel. + +Pour la Kfet, on partirait sur un 2920-24G POE, qui coûte ~1200€ + +On demande un budget de 2000€ au CA. + +### KVM + +On s'est fait avoir, on a rien eu de livré et on s'est fait rembourser. Faut +re-rechercher avec le budget du CA qui est toujours dans la course. diff --git a/compte_rendus/2017_01_05.md b/compte_rendus/2017_01_05.md new file mode 100644 index 0000000..b8b25b2 --- /dev/null +++ b/compte_rendus/2017_01_05.md @@ -0,0 +1,175 @@ +# Réunion du Collège Technique + +* Date : Jeudi 5 janvier +* Lieu : Pavillon des Jardins +* Début : 19h14 +* Fin : 20h10 +* <> + +## Présents + +* Emmanuel Arrighi +* Kévin Le Run +* Michaël Paulon +* Rémi Oudin +* Daniel Stan +* Martin Bauw +* Vincent Le Gallic + +## Ordre du jour + +### Droits par défaut sur les homes + +Quelles devrait-être les droits par défauts sur les homes ? +Y-a-t'il d'autres problèmes à régler ? + +Les droits par défaut sur les homes créés ont toujours été 755, jusqu'à +récemment. +Cela signifie que n'importe qui peut traverser ce home. Il s'avère que certains +anciens +ont décidé de changer ce droit par défaut, pour 700. Ceci empêche en +particulier les +pages perso de fonctionner, mais s'ils n'en ont pas, c'est leur droit. Il se +trouve qu'un +vieux a constaté que les droits sur son dossier www puis plus tard son home ont +été changés (remis en 755), ce qui n'est pas quelque chose acceptable (il n'a +pas +été prévenu et s'est donc retrouvé avec des infos potentiellement privées +dévoilées +sur zamok). + +On ne sait pas de quand ça date, plusieurs hypothèses sont possibles (mise en +place +d'owncloud, migration des homes lors du split par lettre, erreur de manip d'une +nounou), +et l'intervalle fourni par le vieux en question est plus que large. + +Suite à la discussion sur #roots, PEB a déjà commité le changement de la +création +de nouveaux homes en 701 par défaut. D'un commun accord, tout le monde se rend +compte que les adhérents pensent souvent à tort que leur home est par défaut +privé, donc autant le rendre privé. Pourquoi 701 et pas 700: le bit à 1 pour +others permet +au serveur web sur zamok de traverser le dossier afin d'accéder au sous-dossier +www (pages perso). +Les droits sur le reste des homes déjà créés n'ont pas été changés suite au +signalement (même si le vieux en question s'est occupé de son cas). + +* Mon avis sur la question est de + +changer tous les droits des homes en 701, par principe de précaution. On peut +ensuite notifier les adhérents où le changement a été nécessaire (et pas avant, +ce serait pas très responsable). Les quelques adhérents que ça dérange peuvent +de toute façon revenir en arrière une fois le mail reçu (le mail devrait +indiquer +la procédure pour changer/vérifier les droits). +Ça cassera peut-être *temporairement* des scripts à eux (mais je n'y crois +pas), mais au moins, ça ne risque pas de dévoiler des données. -- WikiB2moo + +* Perso, je suis ravi que mon home soit accessible, mais ça me dérangera pas de + faire un bête chmod le jour où je recevrai le + mail. -- [[Chirac]] <>^W -- [[Wiki20-100]] + +20-100 fait remarquer qu'il ne faut pas toucher aux homes des clubs, qui sont +traités d'une manière différente. + +Il faudra vérifier le commit de PEB pour voir s'il modifie les droits sur les +homes clubs, sur les archives, les logs… + +On va passer les home des adhérents en 701 (uniquement la racine, pas tout…) et +on fait gaffe aux clubs, logs, impressions… + +* Et par contre le fait que les clubs puissent voir tout ce qu'il y a dans les + www des adhérents, c'est pas + corrigé ? -- ZeldAurore <> + +### Attaque DDOS + +Il faudrait s'assurer que tout le monde sait comment la détecter et quoi faire. +Par ailleurs, il faudrait prévoir des moyens de communications de fallback, et +des outils de gestion de crise. + +20-100 propose l'IRC !RezoSup (comme le screen hors campus est rare, un client +web peut tout à fait faire l'affaire), Charlie a des réticences. +Il est indispensable que ce ne soit pas une solution ad hoc implémentée par +dessus la jambe par 2 cranseux, mais un truc fiable qui sera pas en rade le +jour où le Crans le sera. +On peut envisager un serveur IRC sur soyouz… +On peut mettre le mode historique au chan, ce qui règle le problème du backlog +et du screen. +On choisit de prendre le chan {{{ #roots }}} + +* Daniel pense que le problème n'est pas dans un manque d'outil, mais un + problème humain. À la question "qui est responsable pendant les + vacances" (posées deux fois), il n'a obtenu aucune réponse. Il semblerait que + toutes les nounous soient parties en vacances sans se poser cette + question (la page CransVacances n'existait même pas). Le problème du ddos + avait été remarqué par Hamza dès le dimanche soir : + +{{{ +01:57:28 &dely | 138.231.$x.$y +01:57:42* &dely | Cette machine s'est faite flooder salement +}}} +Le problème, c'est qu'Hamza n'allait pas bien et est parti faire autre chose, +et personne n'a souhaité prendre le relai pour investiguer davantage. +D'autre part, les outils de monitoring indiquent un grand trafic entrant, le +graphe munin est un exemple +criant: + + +Malheureusement, les nounous ne consultent que trop peu ces monitorings, et ne +se posent plus de question lors d'une nouvelle alerte (trop de faux positifs +ou d'alertes non critiques qui *trainent* cf certs sur soyouz et +titanic : ). Bref, à quoi bon chercher de +nouveaux outils quand les actuels ne sont pas utilisés… + +* Je suis d'accord avec cette remarque. Je pense que la désignation officielle + d'un moyen de comm' de backup ne résout pas tout mais serait utile en cas de + blackout. -- [[Wiki20-100]] +* Il est indéniable que la communication n'est pas le seul problème, mais ça à + au moins l'intérêt d'être un problème qu'on peux régler assez facilement, + juste en se mettant d'accord. -- Charlie + +Il faut fix les routes de la freebox (ssh zamok depuis la freebox se fait +refused). +(FX-ilo est down, il faudra réparer ça. Ça date du changement de switch ilo.) + +On va aussi mettre à jour le wiki et envoyer un mail récapitulant les +procédures. + +#### autostatus + +Il faudrait faire un effort collectif pour mieux utiliser les systèmes de +monitoring (autostatus.crans.org, munin.crans.org) et clear tout pour que ça +devienne propre à nouveau. + +Autostatus devrait être tout vert(/ouvert ?). + +### Taches phabricator + +Petit point des taches pour savoir où on en est (zamok, ipv6, câblage sur thot…) + +* zamokv5 : Planification en cours de la partie 2. Harcèlement des jeunes. +* IPv6 : Hamza a fait la demande de tunnel. Chirac doit fournir un LoA de + l'ARES. Il faut finir ça au plus vite. +* Câblage sur thot. Portage en cours, script de recherche dans les logs sur + thot. + +### Prise défectueuse + +sur nounou@ : +{{{ +On 02/01/2017 13:17, $prénom $nom wrote: +> Salut ! +> Je vous recontacte au sujet de ma prise éthernet défectueuse. +> Je suis disponible cette après-midi, et tous les soirs de la semaine, ainsi +que le weekend prochain. +> Merci et bonne année ! +> $prénom $nom (bâtiment $b, chambre $room) +}}} + +Blupon est intéressé pour apprendre, quelqu'un pour l'accompagner ? +NB : il y a une deuxième demande sur respbats@ (au bât M iirc) + +Blupon, Mikachu, Fardale se synchronisent pour gérer ça. +À voir s'il reste suffisamment de prises femelles non serties. diff --git a/compte_rendus/2017_02_02.md b/compte_rendus/2017_02_02.md new file mode 100644 index 0000000..01060a5 --- /dev/null +++ b/compte_rendus/2017_02_02.md @@ -0,0 +1,128 @@ +# Réunion du Collège Technique + +* Date : Jeudi 2 février +* Lieu : Pavillon des Jardins +* Début : 19h16 +* Fin : 20h02 + +## Présents + +* Clément Turck +* Myriam Bégel +* Rémi Oudin +* Gabriel Détraz +* Hamza Dély +* Charlie Jacomme + +## Ordre du jour + +### Point sur les dernières opérations + +Firmware upgrade de la baie, des switchs, et j'en oublie. Qu'est-ce qui s'est +bien passé, mal passé, qu'est-ce qui aurait pu mieux se passer. + +#### Baie + +Elle a été mise à jour… avec un Windows connecté sur un adm untagged par un +switch programmé à l'arrache. Bref. Ça a marché. On n'en parlera plus jamais. + +Des opérations ont été faites sur la baie sans que l'on rencontre de remount en +read-only, donc on a peut-être réglé nos problèmes. + +Il y a par contre toujours le problème du boot de zbee qui est caca, mais on a +rien réussi à y faire. Il faut faire gaffe quand on reboot, une solution est de +réinstaller zbee, mais ça fait potentiellement une grosse interruption de +service. Ça peut attendre des vacances. + +#### Switchs + +Ils sont tous passés sur le nouveau VLAN qui est isolé, le 4. Ils ne sont +visibles que depuis Thot, Fy, eap, pea, radius, sable. Ils ont aussi été +firmware upgradés. + +Il y a un joli script pour faire les firmware upgrade et les majs de conf sur +les switchs, /usr/scripts/gestion/majswitchs2.py + +Le câblage devra se faire par suite sur Thot. + +### Zamok v5 + +Il reste les pages perso à conf, puis il va falloir planifier la grosse +migration ! +Le portage des paquets a été long, mais c'est fait. +Il reste les pages persos, dont la configuration est actuellement moisie. +Hamza et Rémi investiguent. + +### IPv6 + +La LoA a été faite, le tunnel est ouvert, il faut régler tout ça sur odlyd. On +profiterait des vacances pour faire ça. On va essayer le premier week-end des +vacances. Attention à la conf du daemon bgp (pas de redistribute +OSPF) + modification de tous les trucs qui trainent, les IPs harcodés… + +* Ça veut dire quoi LoA ? -- ZeldAurore <> + +### VPN par freebox en permanence + +Est-ce qu'on veut que le VPN pour soyouz soit en permanence branché sur +titanic, ou que ce soit sur odlyd en permanence et sur titanic uniquement en +fallback ? + +On garde en fixe sur titanic. On va pouvoir supprimer des scripts devenus +inutiles. + +### Switchs - 2 + +Donc, le switch acheté pour la Kfet est overkill, on pourrait plutôt le mettre +au M, et acheter un 2530 (620euros). Le problème est qu'il faut des +convertisseurs pour les bornes du M, soit 20 à un vingtaine d'euros. +Celui de la Kfet ainsi remplacé irait au 5C. + +On demande 1400 euros au CA. + +### Charybde + +Les disques de charybde recommencent à faire des leurs, ça devient un peu +récurrent… Ce serait peut-être pertinent d'avoir des disques en rab, ou de +prendre des disques un peu plus solides ? + +On va racheter 5 disques de 2To, de meilleure qualité. Il faut faire une +enquête sur Internet, Guinness est dessus. + +### Plan d'Investissement d'Avenir ARES + +Défendre un projet au CROUS avec un financement sur 10 ans semble être l'un des +derniers moyen de s'implanter au CROUS à Saclay. Ce projet devrait s'inscrire +dans un cadre plus gros que "juste" fournir l'accès à Internet. +Un petit brainstorm sur l'ensemble des choses qu'on peux proposer pourrait +servir. + +* domotique +* système de note : compte pour payer plein de choses sur le campus (laverie, + CROUS, RU…) +* Accès et réservation des locaux +* Y-a-t'il de la place à la laverie ? + +### Gâteau + +C'était un mensonge :DDD + +Mais il y a une surprise, des nouvelles nounous ! + +Nous proposons donc à Bernie' et Myriam de devenir nounous. + +Iels acceptent. + +Bernie fait un discours : +Il appelle son coiffeur avant, qu'iel le recoiffe. Il refuse qu'on touche à ses +cheveux, belle confiance envers Guinness, ça promet… + +### Mail pour les home + +Rédaction !? +A vos avis : + + +### Jap + +Guinness nous a trahi !!!!! diff --git a/compte_rendus/2017_03_02.md b/compte_rendus/2017_03_02.md new file mode 100644 index 0000000..00d9db5 --- /dev/null +++ b/compte_rendus/2017_03_02.md @@ -0,0 +1,28 @@ +# Réunion du Collège Technique + +* Date : Jeudi 2 mars 2017 +* Lieu : 2B +* Début : 20h00 +* Fin : 20h52 +* <> + +## Présents + +## Ordre du jour + +### Old Baie + +Whatdowedowithit ??? + +On la donne à une association dans le besoin, donnée "as is". Chirac diffuse +l'offre auprès de ses partenaires. + +### Rezo Sup + +Nous estimons que la fiabilité du service proposé par le Crans n'est pas +suffisamment élevée pour s'engager auprès d'un groupe extérieur de personnes +sur ce genre de service. +Nous souhaitons par ailleurs pouvoir nous concentrer sur améliorer la qualité +des services que nous proposons actuellement, plutôt que d'éparpiller nos +efforts. +Nous encourageons fortement FedeRez à se porter candidat avec son dédié. diff --git a/compte_rendus/2017_04_06.md b/compte_rendus/2017_04_06.md new file mode 100644 index 0000000..37466fe --- /dev/null +++ b/compte_rendus/2017_04_06.md @@ -0,0 +1,112 @@ +# Réunion du Collège Technique + +* Date : Jeudi 6 avril 2017 +* Lieu : 2B +* Début : 19h12 +* Fin : 22h04 +* <> + +## Présents + +* Charlie Jacomme +* Gabriel Détraz +* Rémi Oudin + +## Ordre du jour + +### Changement du mot de passe root et du mot de passe LDAP + +Ça fait longtemps que ça n'a pas été fait, je pense que ça serait une bonne +chose de le faire. + +PS 1 : jben m'a dit qu'il connaissait le mot de passe du LDAP, donc ça +fait *vraiment* longtemps que ça n'a pas été fait... + +PS 2 : En plus le mot de passe root est super chiant à taper + +1) Mot de passe root, c'est easy, on fait ça de suite + +C'est fait. + +Pour être sûr que toutes les nounous sont aux courants, le nouveau mot de passe +est donc : +!Pr0uTtot0 + +2) Mot de passe LDAP, easy aussi + +C'est fait. C'était très long... + +### Achat de switch/bornes + +Toujours dans l'esprit d'améliorer la couverture wifi, on continue la réflexion +sur l'achat de switch et de bornes. +Il est à noter que la borne installée au 2B fonctionne, il n'y aurait donc pas +de problème avec les UAP AC Pro en générale, mais juste celle de la Kfet. + +* C'est l'image de la borne, ou c'est le matériel physique ? -> matériel + d'après Hamza + On ne sait pas trop, il faudrait tenter de reflash la borne pour fixer la + question. + +On souhaite remplacer les anciennes pico station qui sont totalement outdated +par des UAP AC Pro, il en faudrait donc une vingtaine. (2800€) + +Pour les toits, il faudrait acheter environ 5 nano +stations (80 euros/borne, 400€). Remarque : faire attention à ne pas se faire +refourguer des bornes avec bug matériel + +Lorsque l'on remplace une pico par une UAC, il faut soit mettre une adaptateur +POE actif, soit carrément remplacer le switch par un switch POE. La seconde +méthode, plus couteuse, à l'avantage de permettre de reboot les bornes à +distances. + +Les H,I,J seraient les principaux problèmes, on pourrait faire l'achat +de 3 switchs : 3 x 800 = 2400€ + +On demanderait donc un budget autour d'environ 5800€ pour améliorer la +couverture wifi du crans. +5k8€, c'est pas 5.8k€ ! 5k8€ ça veut +dire 5008€ ! -- ZeldAurore <> + +### Maintenance du nœud IRC + +Suite à l'internounous du 10/11/2016, il avait été décidé que Rémi s'occuperait +de InspIRCd et du nœud IRC. Il demande donc à devenir IRCOp pour pouvoir +s'occuper du nœud. + +La demande est bien évidemment validé. + +### Machines de FedeRez + +Il semblerait qu'une des machines de FedeRez (hébergée sur Kdell) envoie +beaucoup de données. + +Elle n'a donc a priori pas d'exceptions dans le comptage. +Il faudrait peut-être décider si on doit en mettre un ou pas +non ? :-° -- Guinness + +On exempte donc kdell et octogon du comptage d'upload : Kdell gère les backups +et octogon le gitlab. + +### Support + +PEB avait installer un redmine il y a environ un an. Le projet est en friche, +et la vm, abandonnée, on la supprime. + +### Odlyd et ses défaillances + +xtables--addons n'est pas dans les backports, ce qui nous bloque dans les mises +à jour du noyau d'odlyd. C'est un problème car les symboles de debugage de +cette version du noyau ne sont pas packagé, et donc pour le moment les crash +kdump sont inexploitable. +Il faut trouver une solution, l'une de celles envisagées est de passer sous +stretch. Folie pure ? +L'autre est de continuer à repackager à chaque fois, ce qui n'est pas vraiment +une solution très maintenable. + +### Generate et firewall + +Il faudrait faire une passe finale de reviewing, puis ce serait bien de les +mettre en prod. +On essaie de tous regarder ça d'ici l'internounous prochaine, à la fin de +l'internounous, la décision sera prise. diff --git a/compte_rendus/2017_05_04.md b/compte_rendus/2017_05_04.md new file mode 100644 index 0000000..ae1818b --- /dev/null +++ b/compte_rendus/2017_05_04.md @@ -0,0 +1,77 @@ +# Réunion du Collège Technique + +* Date : +* Lieu : 2B +* Début : 19h03 +* Fin : +* <> + +## Présents + +## Ordre du jour + +### Routeur + +Un problème de soft a été mis en évidence, plusieurs idées ont été proposés. +Routage ipv6 sur une vm, achat d'un vrai serveur capable d'assurer la charge de +full master backup... + +Routage ipv6 sur une vm. Prévoir assez d'espace disque pour les crashs et le +logall. + +sable rame du cul, il faut comprendre pourquoi. + +> mesurer le debit () + +migrer le service de sable sur un autre serveur physique ? + +* reutilisation d'un serveur existant plutot que l'achat d'un nouveau ? + +### Monitoring + +Icinga2 a été déployé, grafana a été proposé. Quelle est notre objectif finale ? + +Il semblerait que les deux peuvent à la fois remplacer autostatus et grafana, +il faudra se décider un jour. + +Il y actuellement trop de problèmes de confs d'icinga2, ça crée un max d'alerte +boggus non pertinente et ça noie les vraies problèmes. + +Donc : + +* Hamza essaie de régler un max de fausses alertes +* Dès que c'est fait on down autostatus +* En parallèle, Mikachu avance sur grafana. + +### Charydbe, disque + + + +Chirac propose de prendre des disques plus grand (4T), de ce genre là : + + + +On balance un devis de 1300€ au CA. + +### Renouvellement de la garantie de pulsar, batterie fatigué + +On considère que le renouvellement de garantie n'est pas nécessairement +pertinent, au vu de l'âge de la bête. +On envisage à long ou moyen termes de le remplacer. + +### openWRT + +L'état de dev d'openWRT est douteux, les core developpeur sont partis faire +mumuse avec LEDE. +Il faut suivre l'évolution de l'affaire, et envisager de passer à LEDE + +### Code review + +Objectif, regarder le nouveau firewall et generate + +Dès que possible, on le test, sur ipv6. + +### Gateaux + +Pas de gateaux, tant pis. +Mais Mikachu et Fardale sont nommés nounous ! :D diff --git a/compte_rendus/2017_06_08.md b/compte_rendus/2017_06_08.md new file mode 100644 index 0000000..b039b3a --- /dev/null +++ b/compte_rendus/2017_06_08.md @@ -0,0 +1,196 @@ +# Réunion du Conseil d'Administration et du Conseil Technique + +* Date : Jeudi 8 juin 2017 +* Lieu : Pavillon des Jardins +* Début : 19h03 +* Fin : 20h 33 + +Présents : + +* Gabriel Detraz +* Michael Paulon (procuration de Rémi Oudin) +* Nicolas Gasnier +* Rémy Garnier +* Charlie Jacomme +* Emmanuel Arrighi (arrivé à 19h04) +* Florent Marconi + +Exilés (mais toujours présents dans nos cœurs) : + +* Mathilde Espinasse +* Rémi Oudin + +## Ordre du jour + +### Budget 2B + +On propose un budget de 500€ pour le 2B. Ce point sera soumis au vote du CA.Les +nounous demandent plus de budget et remarquent que le 2B est sale et qu'il +faudrait le ranger. + +* Pour : 4 +* Contre : 0 +* Abstentions : 0 + +Le Budget est donc approuvé à l'unanimité des votants. + +### Point rentrée + +Il faudra modifier et remettre à jour les livrets CRANS (et les +réimprimer) : il faut fixer une deadline pour la version finale (15 août), +commandes de consommables à faire pour la rentrée . +La rentrée Crous à lieu du 29 au 30 août + +Il reste environ 280 câbles. Nicolas propose d'en commander. Le budget serait +d'environ 2€ par câble +pour 1000 câbles. ( +(câble blanc)) +Stockage au 0A. +On propose un budget de 2000€ pour les câbles. Ce point sera soumis au vote du +CA. + +* Pour : 4 +* Contre : 0 +* Abstentions : 0 + +Le Budget est donc approuvé à l'unanimité des votants. + +Étude du choix des goodies pour la rentrée. Les propositions sont : + +* Stickers (environ 800€ les 5000). Voir avec FedeRez pour leur fournisseur. On + propose aussi des stickers avec la possibilité de mettre les login dessus. + chez FedeRez : fournisseur Camaloon +* Clés USB : + * Mauvaise expérience et potentiellement assez cher. + * Difficile d'en avoir de bonne qualité pour un budget raisonnable. + * En donner à la fin des séminaires avec les slides dessus? +* Des peluches ! + +Quand les distribuer ? + +* À la rentrée ? +* À la soirée CRANS ? A priori oui pour les peluches. Proposer des goodies à + distribuer à la soirée permet d'en commander une plus petite quantité, et de + quand même inonder le campus de goodies stylé. + +Accord de principe pour des peluches et des stickers. Budget à fixer au +prochain CA. + +### Point WEI + +Fixer une deadline pour les versions à imprimer des livrets WEI. +Les livrets envoyés après cette date seront facturés. +Idée : 1 septembre deadline, 10 septembre on imprime plus rien. +Décision finale : + +* 15 aout pour le livret BDE, à partir du 1er septembre on imprime plus. +* 5 septembre pour les livrets bus, après le 10 septembre on fait rien du tout. + +Faites beaucoup de comm' auprès du BDE pour que l'info arrive jusqu'aux bus :) + +Réfléchir à l'animation. Twister sur clavier ? Pourquoi on a des buts de +water-polo ? +Nettoyer le Twister pour l'utiliser. + +### Communication externe + +On propose une mise à jour de la charte graphique du Crans. + +* Nouveau logo : EkstaProd et proposer à Pensil) + * Deadline : 30 juillet. + * Charte graphique : + * garder l'arobase ? + * prise RJ45 ? + * Finalement pas de contraintes imposées. +* Création d'un site web, statique (utilisation d'outils non libres ?). + * Objectifs : + * Com externe + * Information rapide et FAQ pour les gens ne pouvant pas utiliser le wiki + * Dissociation wiki. Minimiser le nombre d'interaction vers le wiki. + * Centraliser les infos essentielles + * Newsletter + +Un nouveau site web, qui un peu dans l'idée de la page d'accueil de Myriam, +serait cependant plus orienté vers les gens extérieur et/ou qui y connaissent +pas grand chose. Donc, une présentation rapide du Crans, une FAQ, les infos +essentielles/news (ça marche, ça marche pas, les événements, etc). Il faut +aussi qu'il permette d'afficher les communications faites sur facebook/twitter… + +### Modernisation des adhésions + +Étude du fait de rendre obligatoire la création d'un compte Crans. +Création d'office pour éviter les problèmes de paiement (accès au données, +problème légaux) et les problèmes de présence aux permanences +Avancer sur l'archivage des comptes non utilisés +On décide de créer automatiquement un compte crans à l'inscription. + +Une proposition, permettre aux gens d'adhérer totalement en ligne. Cela +n'empêche de tenir les perms rentrée crous pour rester le premier contact +des 1A. +Pour la réadhésion plutôt que l'adhésion? Difficulté pour trouver des câbleurs +en août. Possibilité d'activation temporaire. +Faire ça depuis une prise ? Problème de validation du statut d'étudiant et des +noms. +Possibilité d'adhérer que pour le Wifi? Réduction effective des charges des +permanences? Question de la nécessité du contrôle d'identité. +Faire la réadhésion par Internet est plutôt simple, la première adhésion pose +plusieurs problèmes (contrôle de l'identité). + +On décide de créer un nouveau système pour les réadhésions. Pour les nouvelles +adhésions, on propose de tester un outil pour les vacances. + +* Objectif pour la rentrée : Avoir le système de réadhésion qui + fonctionne + modifier le mail de fin d'adhésion +* Objectif plus long terme : Pouvoir, par exemple lors des vacances, proposer + aux gens d'adhérer totalement en ligne. + +Limiter le nombre de permanences (en particulier le midi) +3 permanences fixes (lundi, mercredi et vendredi soir) et on essaie de les +tenir. Non. On les tient. Point. +Perm officiel le midi? Un système de prise de rendez-vous pour les gens qui ne +peuvent pas venir le soir. +Difficulté avec le vendredi soir +Faire des flyers pour le CROUS pour donner les heures de permanence et +l'adresse mail de contact au cas où. +Politique random pour les vacances. + +### Portail captif + +Création d'un portail captif pouvant être réutilisé suivant les +évènements(installs partys, conférences, PR…). +Il en existe déjà, à faire nous même ou pas ? Gabriel s'en charge. + +### Les 20 ans du Cr@ns + +:: +:: Fusion journée Federez (soirée) +:: Recenser les idées. +:: Demander une subvention CVE pour la sécurité. +:: Remplir le pad d'idées. + +### Textiles + +:: Relancer une commande de textiles. +:: On attend le logo. + +### Le droit mailing + +On garde le droit modérateur (à l'origine pour modérer les News) et on +l'autorise à créer des ML. + +### Divers + +:: On demande un badge du portail au CROUS. +:: Permanences PR : aléatoires en fonction des disponibilités. +:: On relance la commande des disques WD RED pour Charybde : déja fait. +:: Croissants AGO : Nicolas rembourse les croissants. + +### Remarques + +* PEB a fait remarquer que changer les barillet du 2B reste pertinent, il + semblerait qu'il y ait des clés qui aient disparu avec des membres actifs aux + alentours de 2012. On a retrouvé les MA ou les clés ? Il semblerait que non. +* Charlie sera absent de la fin de cette réunion jusqu'au 1er juillet. + Contactable par téléphone ou mail en cas d'urgence, il sera sinon en train de + siroter un cocktail sur une plage de sable blanc. Ou en train d'essayer + d'avoir l'agreg, Au choix. diff --git a/compte_rendus/2017_09_28.md b/compte_rendus/2017_09_28.md new file mode 100644 index 0000000..0736634 --- /dev/null +++ b/compte_rendus/2017_09_28.md @@ -0,0 +1,162 @@ +# Réunion du Collège Technique + +* Date : Jeudi 28 septembre 2017 +* Lieu : Pavillon des Jardins +* Début : 19h00 +* Fin : 21h00 +* <> + +## Présents + +* Gabriel Détraz +* Charlie Jacomme +* Clément Turck +* Maxime Bombar +* Nathanël Gross--Humbert +* Zéphyr Salvy +* Thomas Bauvent +* Nicolas Gasnier +* Gabriel Le Bouder +* Hamza Dely +* Raymon Zhang + +## Ordre du jour + +### Présentation générale + +Charlie fait une présentation du collège technique et de son utilité. Il +rappelle qu'il ne faut pas avoir peur des discussions techniques et de poser +des questions. + +### Freeradius 3.0 + +Hamza a remis intégralement à neuf le système freeradius et nous l'a présenté. + +Première nouveauté, implémentation de la reconnexion dynamique. Ça marche pour +les bornes, et pour 1/3 des switchs. +Deuxième nouveauté, les vlans dynamiques qui permettent de rediriger quelqu'un +là où elle est censé être. +Troisième nouveauté, en cas de base en RO, freeradius ne meurt pas, et on ne +perd pas tout le réseau. + +On lance les tests sur le bâtiment I. + +### New switches + +Avoir quelques switchs neuf de rab, pour remplacer en cas de besoin. + +On a un stack de vieux switchs au 2B, ça pourrait être pertinent d'avoir des +switchs plus récents qui supportent des protocoles plus récents. +Sur le parc : + +* 16 2650 +* 5 2626 + +On remplace les 5 2626 par les 2910, et on aura 3 nouveaux switchs (si le CA +est gentil) de roulement. + +### 802.1ad + +La techno nous permettrait de propager tous nos vlans côté ENS en les fourrant +dans un seul. Magie ? + +On verra plus tard. Hamza envoie un mail. + +### Mail et blacklist + +Comment éviter de se faire blacklister par des hébergeurs de mail ? Remise en +mode slow ? + +On pourrait essayer de configurer une limite par heure et par journée sur +policyd. +Est-ce qu'il est possible de désactiver le compte SMTP d'un mec qui spam, de +manière temporaire. + +Rappel de la campagne de changement de mot de passe. => Zéphyr, Gabriel et +Thomas sont motivés pour s'en charger, encadrés par Bernie et Charlie. + +### Garanties + +Fz et Thot sortent de garantie en décembre. Renouvellement ? + +* Thot, y a pas de question, oui on renouvelle +* Pour fz, vu son âge on hésite, une option serait de le laisser continuer + tranquillement son rôle de fallback dans le cluster, et de le remplacer le + jour où il meurt. Hamza dit que si on laisse ça comme ça, quand fz mourra, on + aura la flemme de racheter un serveur. + +Donc, si on a la flemme, Hamza pourra dire "je vous l'avais bien dit". En +attendant, on renouvelle pas. + +### Ménages + +Trop de ML qui servent à rien. Destruction ! + + + +Zéroième étape, on augmente la taille de redisdead. + +Première étape, on contact les modérateurs de MLs trop vieilles pour savoir si +ils sont en vie. + +### Volume de backups + +Zéphir est à 80% d'usage de disque, avec une croissance de 25% sur 1 an. On ne +tiendra donc plus un an avec /a priori/. +Deux possibilités, on augmente l'espace de stockage, ou alors on réduit la +durée sur laquelle on backup. +Any thoughts ? + +On réduit violemment le nombre de back up, genre par 2, mais en gardant un +back-up de 6 mois. + +À voir si backuppc propose pas un autre algo de compression. + +Charlie regarde. + +### Futur du Crans + +#### Fibre + +On veut prendre une fibre indépendante de RENATER, pour se préparer à quand ils +seront plus là. Plusieurs demandes de devis ont été faites, on s'interroge sur +les questions de la qualité de la connexion. +Qu'est ce que c'est ti qu'on veux: + +* GTR 24/24 7/7 +* 1gb/sec +* port 10gb + +Il faut éplucher les contrats. Comment se renseigner sur leur service de +qualité ? -> FedeRez ? + +#### Infra + +Le Crans doit simplifier son infra pour se pérenniser et doit devenir +indépendant d'un point de vue fibre. Cela implique des grosses décisions +technique, et de ne pas faire n'importe quoi. +La fibre, c'est facile. Le reste de l'infra, on sait pas quoi faire, ou plutôt +ou n'est pas tous d'accord. Il y a des conditions inamovibles, on ne mettra PAS +un truc bancales en prod, si on pousse quelque chose, ce sera un beau produit +finit. Pour le reste, on verra. + +### Responsabilités + +Rappel sur le bon usage des droits Crans. +Chirac avait renommé une machine d'adhérent pour pouvoir en donner le nom à un +serveur Crans. Il reconnait que c'était une bêtise. Si l'acte est moralement +répréhensible, cela reste en pratique sans conséquence, il y a donc simplement +un avertissement qui est émis. + +On en profite pour rappeler les petites erreurs de ce genre que l'on peut +faire, sans toujours s'en rendre compte. + +* whokfet +* whos +* IRCop +* Upload depuis vo. +* ménage câbleur sauvage +* Blacklist de quelqu'un qu'on aime pas +* ... + +Bref, un grand pouvoir implique de grandes responsabilités. diff --git a/compte_rendus/2017_11_22.md b/compte_rendus/2017_11_22.md new file mode 100644 index 0000000..a238d3f --- /dev/null +++ b/compte_rendus/2017_11_22.md @@ -0,0 +1,194 @@ +# Réunion du Collège Technique + +* Date : 22/11/17 +* Lieu : 5A +* Début : 19h06 +* Fin : 21h17 +* <> + +## Présents + +* Gabriel Détraz +* Maxime Bombar +* Martin Bauw +* Gabriel Le Bouder +* Rémi Oudin +* Michael Paulon +* Benjamin Graillot +* Charlie Jacomme +* Hamza Dely +* Nicolas Gasnier + +## Starring + +* PEB + +## Ordre du jour + +### Signature du contrat pour la fibre + +Le contrat est signé, vive le contrat ! + +### Onduleur is tired + +On avait dit il y a un moment qu'on laissait l'onduleur dans son état actuel, +i.e. +qu'on ne changeait pas ses batteries ni ne prolongeait sa garantie. Ça commence +à faire un petit moment, il est temps de resoulever la question. + +On décide de faire une demande de devis pour renouveler l'onduleur. On va faire +des demandes pour des intensités de sortie de 2kVA, 2.5kVA et 3kVA. On garde +45 minutes d'autonomie. + +### Renouvellements garantie + +Fz et thot arrivent au bout, est-ce qu'on prolonge ? +Pour FZ on ne renouvelle pas. +Pour Thot on avait déja validé à la dernière IN, on envoie ça au vote du CA. + +### Fy ou "De l'art de la PLS" + +Ce bon vieux Fy commence à avoir du mal avec le monitoring, il faudra peut être +revoir la façon dont on gère le monitoring et/ou penser à déléguer certaines +taches +à des VMs. (ça éviterai aussi de perdre tout le monitoring quand Fy plante) + +Finalement, il semblerait que Fy ne soit pas tant que cela en PLS, nous passons +donc au point suivant. + +### La nouvelle fibre is coming + +Il faudrait réfléchir au plan d'attaque pour quand la fibre sera là, dans les +grands lignes au moins. + +Chirac s'occupe de la partie administrative et pose de la fibre. + +Ce qui a été fait : + +* rendez-vous avec le responsable patrimoine Crous +* prise de contact avec la mairie + +Ce qu'il reste à faire : + +* déterminer le point d'entrée de la nouvelle fibre et le point de raccordement + à l'infra actuelle -> 0B +* si c'est le 0B, investir dans un module 10 gig fibre ou cuivre suivant ce que + le routeur juniper délivrera. -> oui, il faudra un module 10Giga pour le + backbone. Il faut se renseigner sur + la connectique du provider. +* idem avec la carte réseau d'odlyd et de sable -> cf au dessus +* planifier le déploiement de nouveaux vlans etc d'abord pour du test, en lien + avec re2o ? -> re2o est en phase de tests, on va pas prévoir de l'utiliser dès + maintenant. +* suggestion, basculer le wifi federez sur la nouvelle fibre assez + rapidement (facile à faire, indépendant de lc_ldap et de la bdd crans + actuelle) -> On pourrait potentiellement switcher tous le wifi. + +Suite à des problèmes de configuration de Munin, on a pas la proprtion de BP +utilisé pour le filaire vs le wifi. Il faut fixe la conf, pour avoir des stats +sur l'utilisation en BP du wifi. + +Selon, il faudrait voir si c'est pertinent de mettre dans un premier temps +uniquement les machines wifi sur la nouvelle fibre. + +* envisager le système de nat à mettre en place en ipv4, proposition : nat par + plage de 1000 ports sur ip publique par ip privée derrière; ce qui donne au + maximum 65000 ip privée (on a de quoi faire) -> Comme premier plan, si c'est + pertinent vis a vis de la BP + +Remarque générale : est-ce que ça relance l'idée du miroir debian commun avec +l'ENS, car cela libère l'utilisation de la fibre principale. + +### Re2o + +Concernant la période d'essai re2o, il faudrait qu'on se fixe quelques petites +tâches à faire dessus pour avancer. + +Ce qui a été fait côté projet : + +* réunion de cadrage, le CR a été envoyé sur nounous des principaux dev +* projet migré sur le gitlab de federez, avec de la CI. De nouveaux dev se sont + rajoutés. +* politique de review obligatoire par un set de dev avant merge de nouveaux + commits sur master + +Ce qui a été fait coté Crans : + +* mise en place d'une instance de test sur re2o-server et re2o-ldap +* tests de migration de la bdd (à peu près 70%) des données, manquant encore + l'historique + +Ce qui reste à faire : + +* auditer les manques fonctionnels de re2o pour le crans +* envisager des améliorations et les classer par ordre de priorité, de + l'important lié au fonctionnel au cosmétique non prioritaire + +Après beaucoup de discussion autour de re2o, de l'option de faire évoluer +l'infra et de l'avenir du crans en générale, 3 questions ont été posé aux +présents. +4 sont pour bosser sur re2o en collaborant avec tous les campus +1 est pour avoir au final au crans un fork re2o +7 sont pour evolution de l'infra actuelle + +Conclusion : On laisse tomber la période d'essai re2o, on lance l'évolution à +fond. + +Premier objectifs faisable sans trop discuter : + +* brûler ldap_crans (cf code review pour guiness) +* Documenter ce qui ne l'est pas + +### Switchs + +Chirac a demandé à Anne une cotation pour 20 switchs soit 2530-48G +soit 2930-48G, pour éradiquer les 2650 qu'il reste (16). Il espère avoir des +résultats pour l'IN. + +Possibilité 1 : commande de 20 nouveaux switchs 2530-48G ou 2930-48G + +Possibilité 2 : plus économique, racheter les 2910-al de ex supelec rezo. +Avantage, ils valent 100-200 euros à l'argus, sont garantis à vie, et vu qu'on +a déjà pas mal de 2910-al, cela garde la cohérence dans les différents modèles +qu'on a. + +Problème, ils n'en ont que 9 - 48 ports donc il faudra compléter avec des neufs. + +On demande au CA d'acheter 16 switchs 2530-48G, pour environ 14k€ + +### Politique de modification des comptes + +Fardale avait envoyé un mail sur le sujet qui a soulevé quelques réactions mais +ce n'est pas allé plus loin. Il faudrait finir de répondre à cette question. +(Si je n'ai pas le temps de développer ce point il pourra être ignoré) + +> Ce genre de modifications semble engager d'un point de vue légal le CA. On +propose que le CA voit en premier et décide du concept, le CT dira si c'est +possible ou non. + +### Internet aux SDA + +Il faut répondre à Olympio sur la question d'internet au SDA. Je pense que +c'est un oui, mais vu qu'il y a une IN autant que ça soit validé par tous. + +> Charlie présent, mais potentiellement occupé. Bernie est potentiellement +disponible, mais ne peut s'engager tout de suite. Des peut-êtres du côté de +Pollion, Boudy, Mikachu. + +Bref, on dit oui. + +### Discourse + +Nous décidons à l'unanimité de dire au revoir à Discourse, qui n'aura pas su +s’implanter avec succès sur le campus. + +Attention, il faut faire un back-up ! + +### Cake + +There will be a cake. I swear ! + +## The Cake is a lie + +Il n'y a finalement pas eu de gateau, le RTC est un vil menteur. +Par contre, bienvenue à Boudy, Blupon et Pollion parmis les nounous !!! diff --git a/compte_rendus/2017_12_20.md b/compte_rendus/2017_12_20.md new file mode 100644 index 0000000..9c76245 --- /dev/null +++ b/compte_rendus/2017_12_20.md @@ -0,0 +1,144 @@ +# Réunion du Collège Technique + +* Date : 20 décembre 2017 +* Lieu : Maison de l'Étudiant +* Début : 18h00 +* Fin : 19h42 +* <> + +## Présents + +* Blupon +* Boudy +* Charlie +* Chirac +* Esum +* Pollion +* Fardale (auditeur libre) +* Gasnier (arrivé à 18h11) +* Bernie' (arrivé à 18h14) +* Grizzly (arrivé à 18h28) + +## Ordre du jour + +### Soyouz + +Renouvellement ? Upgrade ? + +Personne n'aura le temps de le changer d'ici le 31. + +Par contre, on change le renouvellement qui était annuel pour le passer à +trimestriel. Ceci permet à une personne intéressée pour le changer de ne pas +attendre un an. + +Si quelqu'un trouve une meilleur offre il est le bienvenu. + +### Upgrade de vo + +Certaines personnes veulent changer Vo. + +Le point est repoussé car les demandeurs ne sont pas présents. + +### Point fibre + +Où on en est, qu'est ce qui reste à faire ? + +La visite a été faite avec Adriatel le sous-traitant de Zayo : la +galerie/couloir TGBT derrière le B et aller jusqu'au H ne pose aucun problème, +mais il n'est pas évident de comment rejoindre la rue. +Ils vont repasser avec une aiguille pour tester. + +Ils ont jusqu'a fin février pour faire leur magie. + +### Évolution de l'infra + +Moult tâches phabricator ont été créées, il s'agit alors de détailler un peu le +plan de bataille. + +Tout le monde peut s'attaquer au wiki : +On a mis une petite sémantique de où va quoi. + +On s'interroge sur une génération automatique de doc à partir de docstring pour +le code. + +Les points priotaires : + +* Avoir un wiki à jour et documenté +* Élimination de autostatus (celà requiert une page publique icinga) +* Brûler ldap_crans +* Gros remplacements de vieux switchs pendant les vacances qui viennent (Chirac + crée une tâche phabricator) +* Revoir et compléter l'environnement de test (magnifiquement commencé par + tudor) + +### Bornes + +#### Firmware + +Des bornes sous openwrt ont de nombreux bug, le firmware propriétaire semble +régler le problème. Il faut prendre une décision sur notre course d'action. + +Les bornes en question sont au M et G. Il y a des nanostations, des AP lite ont +été posées (ENS, quelques CROUS), il y a eu ensuite un gros achat de UAP AC +Pro. Ça a marché pendant 6 mois, puis ça a commencé à tomber. Les UAP AC Pro et +UAP Ac light posent problème : openWRT crash souvent, LEDE un peu moins mais +toujours, et unifi semble tenir la charge. Il nous faut faire attentioin car +sur les AP tout court, on peut les briquer en passant à unifi. + +Nous devons choisir de déployer le firmware proprio avec ou sans le controleur +unifi, uniquement sur les uap ac pro, light ou sur toutes celles compatibles. + +> On passe les UAP AC Pro et UAP AC light sur le firmware proprio et le +controlleur. +> On laisse les AP et les nanostations sous openwrt, mais on peut tenter de +les mettre sur le controlleur si c'est pas trop galère, pour pouvoir voir +l'état de toutes les bornes au meme endroit et reboot. + +#### Nouvelle convention de nommage des bornes + +> On adopte les nouveaux noms : etageBatiment-numero, exemple 5a-01 + +Nous sommes pour changer petit à petit les noms des anciennes vers la nouvelle +convention, tout en gardant les anciens noms comme alias. + +#### Objectifs en terme de couverture + +> Les résidences sont notre priorité : on veut remplir les trous actuelles, +donc G au bout et M au milieu. Un premier objectif est 2 bornes par étage. + +Ce serait bien de savoir si elles sont directionnelles ou pas, pour optimiser +la pose. + +Une fois les nouveaux switchs posés, on commandera plus de UAP AC pro, et c'est +parti mon kiki. + +Il faudra peut-être refaire le trou du M (pour passer les câbles dans le local). + +### Divers + +* The lounge, un interface web irc ? + * Point positif : peut faire venir des gens sur IRC. Le Webirc actuel + n'attire personne. + * Point négatif: service en plus, est-ce stable ? Il faut que les gens + testent : Guinness aurait eu des soucis avec, et en plus c'est du react js + * The lounge semble ne pas relancer les connexions au serveur quand il est + reboot. Et il semble planter de temps en temps à Prologin + +. => Ok pour lancer the lounge, on nuke webirc, et on croise les doigts +.Il faudra attendre que le patch ldap soit dans la version stable + +* Les news + +.Fardale bloque sur du design pour les nouvelles webnews et les webnews php +risque de casser avec le passage à stretch. Qu'est-ce qu'on fait ? nuke it ? +.Il tournait en dev sur vo, il faut l'y remettre. +.=> ASAP, on sort le django webnews et on nuke le webnews php. + +* Recovery de mdp avec soit code de confirmation par SMS, déclenchable par + l'user ou un MA (proposition CA) + +.Pour les SMS, soit on utilise un dongle qui marche pas, soit une API en ligne. +.L'API en ligne a l'air une bonne idée. +.On va créer une tâche phabricator (ça fait comme si on était en train de +résoudre le truc !), avec si possible apprentis, et sinon nounous, mais y a pas +d'urgence. diff --git a/compte_rendus/2018_02_22.md b/compte_rendus/2018_02_22.md new file mode 100644 index 0000000..4223943 --- /dev/null +++ b/compte_rendus/2018_02_22.md @@ -0,0 +1,174 @@ +# Réunion du Collège Technique + +* Date : 22/02/18 +* Lieu : Pavillon des Jardins +* Début : 19h00 +* Fin : +* <> + +## Présents + +* Charlie Jacomme +* Gabriel Detraz +* Arthur Grisel Davy +* Gabriel Le Bouder +* Benjamin Graillot +* Nicolas Gasnier +* Martin Bauw + +## Ordre du jour + +### Renouvellement Garanties + +Deux garanties à renouveller, Nols et ft. + +On renouvelle Nols, mais la question devra se poser avant l'an prochain de son +remplacement. + +On renouvelle ft. + +### Tortilla au gwacamole + +Charlie en veut une + +### Module Backone + +Le switch Zayo est branché sur le backbone en 1G pour le moment. On a une +prise 10G, dont on voudrait pouvoir profiter, mais sans urgence. + +Options : changer le bckbone, acheter un switch, acheter un module pour le +backbone actuel. + + -> Le backbone est toujours en garantie, à vie. Il nous suffit amplement pour + les années à venir, on ne le changera pas. + -> Le switch rajoute un point de failure, qui n'apparait pas nécéssaire, car + il jouerait le meme role que le module, environ au meme prix. + -> on demande un module backbone, avec ou sans urgence, selon si le + branchement 1G fonctionne. + +### Nouvelle fibre + +C'est posé !!! Elle a été tirée, et arrive jusqu'au 0B, où un routeur de +Zayo ( un ciena 3930 ) la récupère et nous la redonne. + +On a demandé un numéro d'AS, pour que Zayo l'annonce. + +On passe tout l'ipv6 et le wifi dessus ? + +On peux passer assez facilement l'ipv6, car c'est routé de manière +indépendante. Il faut mettre à jour la conf de la VM ipv6, changer le prefix de +toutes les machines crans, et s'occuper de l'ipv6 côté DNS. + +On pourrait à terme passer le wifi aussi dessus, sachant que a priori les gens +en wifi n'ont pas besoin d'ipv4 public. Les machines wifi auraient donc des +adresses ipv4 privées sur le réseau, NATées statiquement sur des ports de +nos 1024 adresses publiques. + +On propose de n'utiliser que le premier /24 de notre /22 pour le wifi, on +pourra potentiellement y passer le filaire plus tard. + +> on lance les opérations pour l'ipv6, federez et vlan appart. +> on réfléchi pour le wifi, si le nat statique nous va, et on validera ça la +prochaine fois. + +### Renouvellement des switchs du G + +Ils ne gèrent pas l'ipv6, c'est leur problème. Ils sont au nombre de 4. + +Par ailleurs, le spare qui était prévu a été posé au PdJ, donc on a plus de +spare. + +On propose l'achat de 5 switchs Gigabit, les 2530 48G de la dernière fois + +> devis chez senetic, budget de 4/5k € + +### New ssid wifi + +Des appareils ne supportent pas WPA2-entreprise, une idée à base d'un nouvel +ssid va être proposé. + +Fardale: J'ai l'impression que ça complexifie de manière non négligeable +l'infra actuel. Je pense que c'est une idée intéressante mais vu la complexité +que ça apporte par rapport au gain +(on vend des routeurs pour les gens qui en ont besoin) je pense que pour +l'instant ça n'est pas intéressant et qu'il y a d'autre truc à +régler/voir/revoir avant. + +Mikachu: est également contre pour le niveau de complexité ajouté. + +RQ post réu de la part de Tudor : par le passé, les gens qui avaient ce genre +de soucis partageaient leur connexion filaire via WiFi avec un ordinateur (la +plupart des OS savent le faire nativement, ou avec des softs gratuits +type "connectify" ®© sur Windows). + +Les choses à faire sont : + +* créer un ssid WPA caché sur le controlleur +* hacker les scripts radius pour qu'ils répondent ce qu'il faut. +* Faire de la pub, sinon beaucoup de gens ne sauront pas que c'est possible. + -> cf la confition section sur wifi.crans.org + +Mais les gens déjà adhérent ne vont pas sur wifi.crans.org. + + -> je suis pas sur que ça mérite un mail_all + +Non mais un message sur twitter, un message dans la sauce, une footnote de la +ml événement par exemple + +Conditions pour la mise en place : + +* une section sur wifi.crans.org qui explique comment faire +* que la modification radius ne prennent pas plus de 3 lignes +* que la modification soit documentée + +> Bon, ça nous coûte rien (ou pas grand chose), et ça pourra servir à des +adhérents. Feu. + +### Chiffrement des backups + +Il faut que quelqu'un s'en charge. Pour les homes il reste à tester ce qui se +passe avec backuppc si la partition n'est pas monté au reboot et faire que ça +marche proprement puis basculer sur la partition chiffrée. + +Pour les VM il faut faire comme pour les homes. + +> Oui, il faut que quelqu'un s'en charge si quelqu'un est motivé + +Stocker la clé dans cpasswords, et demander à backuppc de chiffrer ? + +### Pose des bornes WiFi + +Belle perf ce week-end, 7 bornes de posées en 3 heures ! + +Il faut plus de bornes aux H, I et J + +> On demande 4 packs de 5, et une bobine en plus. + +### The lounge + +C'est en prod avec 2 instances, une publique sur irc.crans.org/web/ et une +privée sur webirc.crans.org. +Des remarques ? + +It works, its great. Et en plus c'est joli. + +> Everything is awesome, et y a déjà des gens qui l'utilisent :D + +### Wiki2.0 + +Benjamin se propose de passer le wiki du crans sous moin 2.0, il est +actuellement sous moin 1.9. +Moinmoin 2.0 n'est pas dans les dépots debian + + +C'est précoce. La première priorité est déjà de passer sous +stretch => attnetion, y a des plugins crans qui décèdent, notamment la partie +sur l'auth. -> on peut faire des tests sur soyouz et wiki2. + +### Questions diverses + +* Le webnews django est de nouveau en beta sur vo webnews-dev.crans.org. \o/ + +Faites des retours. + + -> Visuellement c'est cool. diff --git a/compte_rendus/2018_03_15.md b/compte_rendus/2018_03_15.md new file mode 100644 index 0000000..d883264 --- /dev/null +++ b/compte_rendus/2018_03_15.md @@ -0,0 +1,250 @@ +# Réunion du Collège Technique + +* Date : 15/03/18 +* Lieu : Condorcet +* Début : 19h48 +* Fin : 21h45 +* <> + +## Présents + +* Charlie Jacomme +* Gabriel Le Bouder +* Nicolas Gasnier +* Martin Bauw +* Maxime Bombar +* Benjamin Graillot +* Lev-Arcady Sellem +* Antoine Bernard +* Arthur Grisel-Davy +* Michael Paulon +* Gabriel Detraz + +## Ordre du jour + +### Divers + +* Du gateau ! Pour fêter les 20 ans ? + Le Crans a 20 ans, Charlie en a 24, du gateau !!! +* J'ai validé prog1 \o/ + Encore plus de gateau !!! + +J'ai menti, y a pas de gateau. Par contre, on accueil [[Grizzly]] et ArCas dans +le cercle des nounous. + +### Point sur la fibre + +Plan de déploiement. + +La fibre est en place, des essais sont en cours mais on n'a pas encore la +satisfaction totale quant à son utilisation. Potentiellement des erreurs de +routage. Une présentation plus approfondie sera faite. + +Benjamin propose un plan d'adressage IP : + +> On rediscute de cette partie à une futur IN, on veut se concentrer sur le +wifi aujourd´hui + +Module 10Gb backbone reçu, installé avec également la carte rézo sur odlyd, on +fait du gros speed test. Ça fonctionne, mais pour le moment on a un peu trop de +route, car on recoit tout, et avec un seul transitaire c'est un peu inutile. Il +faudrait passer à une default route chez zayo pour simplifier, et calmer le +daemon bgp. + +> Y nous faudrait un calendrier de déploiement + +ASAP, dès qu'on aura un peu mieux vu pourquoi des routes disparaissent. + +> Est-ce qu'il faut prévenir les gens qu'on les change ? + +Il faut prévenir les gens qui ont un port ouvert sur leur machine wifi. Le +reste, on balance. + +Par ailleurs, les applis ens ne sont plus dispo avec le réseau du Crans. + +On propose de mettre en place, si la conf est pas trop dégueu, un double NAT, +un pour contacter l'ENS et un pour le reste du monde, avec les defaults route +qui vont bien. +Mikachu est plutot contre à cause de la complexité de conf, la moitié des gens +ont pas d'avis, et le reste est plutot pour. On tente ça. + +On rappel que les gens vont garder des addresses ipv6 publiques. + +### WPA2 + +tudor souligne qu'avoir un mot de passe identique pour tout le monde pose des +soucis et que la solution acceptée devait utiliser le radius. +Il faudrait changer ça sinon il faut nuker le SSID. + +Tudor: De manière surprenante, je ne trouve pas de doc claire à ce sujet pour +unifi-controller, mais des gens en parlent ici: + +ou +là: +l'option semble présente dans l'unifi controller en prod au crans. +Ok, my bad, ça authentifie tout le monde avec le même mot de passe. La feature +recherchée s'appelle parfois PPSK (*private* pre-shared key), et pas mal de +gens se plaignent qu'elle n'existe pas (cf + +par exemple). +Feature request +officielle : +côté hostapd (utilisé en interne par openwrt et unifi-os), la feature existe +bel et bien : +"wpa_psk_radius" dans +Il faut juste modifier le serveur radius pour qu'il renvoie le mdp en clair +vers la borne (chose qu'il ne fait pas habituellement). + +> Une majorité de nounous pensent que c'est un problème de sécurité. +> 2 nounous tiennent à ce réseau + +-> elles trouvent une solution plus sécurisé, ou alors dans un mois on le nuke. + +### bcfg2 + +Actuellement, au Cr@ns est utilisé le paquet bcfg2 (un peu customisé pour nos +usages persos) pour gérer les config des serveurs. Cependant, le paquet se fait +vieux. Il faudrait peut-être envisager de trouver un autre gestionnaire. +Une alternative pas mal peut etre ansible qui est aussi en python et il me +semble est uttilisé dans d'autres assos de Federez. + +Question aux vieux: pourquoi bcfg2 ? + + -> parce que ça marchait, et que c'était en python. + +Des options : ansible, salt, autres ? + +Mikachu et Pollion regardent un peu en détails comment ils fonctionnent, pour +voir quelle option est la plus crédible, et la plus facilement portable pour +nous. + +### Autostatus + +On se propose de se débarasser entièrement d'autostatus pour le remplacer par +icinga. + +Il y a status.crans.org, icinga2-guest.crans, et icinga2.crans.org, on peut +nuker autostatus + +C'est validé au vote. + +### Augmentation du nombre de MACs par prise + +Actuellement la limite est de 2 pour les prises des chambres et de 5 pour les +clubs, cette limite est parfois atteinte au Club Jeux Vidéo et au club Serv[ENS] + +> on passe la limite club à 30 + +### MàJ du wiki + +Benjamin propose de créer une vm pour mettre à jour le wiki vers stretch + +-> oui, c'est cool + +### Conditions de mise en prod du webnews + +Le webnews "marche" mais n'est pas équivalent en feature par rapport à l'ancien +et il n'a pas été testé sauf que vu l'activité des news il ne sera clairement +jamais beaucoup testé. Du coup Fardale souhaiterait un cahier des charges à +remplir pour le mettre en prod. + +* Pouvoir lire des news +* Pouvoir écrire des nouveaux postes +* Pouvoir répondre + +C'est tout have fun. + +* Je trouve ça un peu léger pour une mise en prod, je rajoute + ma !WishList :-) -- 20-100 + * Affichage par thread + * Possibilité de marquer volontairement un message comme non lu(/lu) + * Cross-post (possibiité d'envoyer le même post sur plusieurs groupes) + * FU2 (lors d'un cross-post, on précise dans le champ Followup-To sur quel + groupe (unique) les réponses sont attendues; cela signifie qu'on attend du + client qu'il honore lesdit FU2) + * [Facultatif] On peut penser à une feature qui suggère automatiquement + en signature "FU2 ``", modifiable pas l'utilisateur. Mais c'est + du bonus. + * PAS de possibilité de supprimer les messages non envoyés avec le + webnews + * [Facultatif] Possibilité de supprimer ses propres messages envoyés avec le + webnews + * [Facultatif] …et ceux envoyés avec l'ancien webnews + * [Facultatif] Permettre à une liste de modérateurs de supprimer d'autres + messages que les leurs. Éventuellement distinguer la liste des modérateurs + pour chaque groupe. + * [Facultatif] Gestion des abonnements : pouvoir ne suivre que certains + groupes + * [Très Facultatif] Gestion de headers custom. Indispensable pour poster sur + crans.crans.annonces. Mais on peut tout à fait décider de limiter ces + posts à un client Thunderbird/Emacs/slrn… + +### Pérennité des services du Crans + +Pensons-nous pouvoir garantir le maintien d'un certain nombre de service pour x +années ? + + -> mail Crans, ce serait bien de pouvoir dire, on les préserve pour au + moins 10 ans. + Le CT demande au CA de mettre de coté de l'argent, 10K dédiés à maintenir les + mails le plus longtemps possible. + Cet argent nous permettrait notamment de garantir de pouvoir prévenir au + moins deux ans à l'avance de la coupure des mails. + -> On envisage à nouveau la migration vers re2o. pros & cons ? + +Le constat est que depuis la décision d'abandonner la période d'essai re2o il y +a 4 mois, rien n'a bougé. La solution re2o semble plus tenter et motiver la +plupart des nounous présentes. + +On tente l'aventure re2o : +on fait un fork, on essaie de programmer de manière vraiment modulaire, on +documente, on test. + +Deadline d'ici 1 mois : avoir déployé un joli vlan avec une simu de re2o, dhcp, +dns, radius +Deadline d'ici 3 mois : avoir rajouté tout ce qu'il fallait pour pouvoir +déployer +Deadline d'ici 4 mois : avoir fait des tests de manière extensive, et prendre +une semaine pour faire le déploiement final. + +> Attention, pas de déploiement si ce n'est pas au niveau, et strictement +beaucoup mieux que ce qu'on a aujourd'hui. + +Si on arrive à faire tout ça, on pourra se poser la question de refusionner +avec la branche master federez. + +On valide le plan, à l'unanimité moins une voix, qui s'en fouiche. + + + +### Renews les clef gpg pour le dépôt custom + +Et faire une page wiki sur comment faire +un +tuto : + +Pollion jete un coup d'oeil. + +### MàJ des Serveurs + +En parlant de pérénité des services, il faut parler mails. En parlant de mails, +il serait intéressant de planifier une interruption de services pour mettre à +jour redisdead et owl. btw il semble y avoir une faille de sécurité dans +dovecot jusqu'à la version de +stretch-backports : + + +On va faire un petit sondage, pour voir des gens dispos dans deux semaines, +pour pouvoir annoncer la date une semaine avant. +Si possible entre 23h et 7h00 +On fait une liste de MaJ à faire, avec un ordre de priorité. On en fait pas +plus de deux en parallèles, et on passe à la suivante que quand les précédentes +ont étaient vraiment finalisé. + +* Faites gaffe, mettre à jour redisdead, ça signifie mettre à jour mailman. Ça + se fait, hein, mais tête froide et sans précipitation. (Vérifiez bien que les + MLs marchent après coup, pas juste que les mails (non-ML) passent.) -- 20-100 + +Bisous, c'est fini <3 + +Du coup, on fait une mini GPG signing party avec les nouveaux ! diff --git a/compte_rendus/2018_04_06.md b/compte_rendus/2018_04_06.md new file mode 100644 index 0000000..8d80079 --- /dev/null +++ b/compte_rendus/2018_04_06.md @@ -0,0 +1,91 @@ +# Réunion développement re2o + +Présents : + +* Chirac +* Charlie +* Grizzly +* Esum + +A noter que la réunion n’a pas durée très longtemps à cause du départ de +Charlie : + +## Point sur ce qui a été fait niveau infra + +* mise en place de re2o-server, vm avec un serveur web apache de dev et bdd sur + thot (postgresl) +* mise en place de re2o-ldap, contenant le ldap de re2o +* mise en place de re2o-services, contenant les services dhcp, dns notamment. +* import de la bdd actuel avec un script d’import bien avancé, permettant de + faire des tests ( presque tout passe, sauf les serveurs disposant de la même + mac sur plusieurs + VLAN : ) + +Ces vm sont sur adh/adm. + +Charlie suggère de rajouter l’embryon de parefeu sur services, de créer des +vlans dédiés en dehors de adm avec des id élevés ( > 30 ? ); enfin de tester +sur ces vlan un mini réseau, avec également la vm re2o-services qui servirait +de routeur. Tout le monde semble d’accord là dessus. + +### Ce qui a été fait niveau dev + +* factorisation du système de gestion des acl +* portages de scripts divers mais essentiels ( chsh, chgpass, unifi-ap-sync, + dernière connexion) via des commandes django et des appels aux forms et aux + validations des models +* enregistrement de l’emplacement des switchs et génération de la map de la + topologie du réseau +* affichage pretty des switchs (equivalent de swicths2 pretty) +* fonction de ménage cableur +* possibilité d’éditer la liste des shells sans passer par le /admin +* model borne wifi spécifique + +Ces taches ont une criticité diverse. Sur le reste, il faut avancer dans le +code, on fait grosso modo la liste des chantiers. En critique/prioritaire, il y +a : + +* firewall, à partir de l’embyron présent dans re2o (nftable ? ) +* generation de la conf des switchs, code modulaire permettant de générer de la + conf pour d’autre modèles que des hp. Voir une solution existante ? +* adherent : gestion de la creation des homes, à inclure dans re2o-tools + +Enfin, on a débattu un peu sur la sécurité. Dans re2o, il n’y a qu’un seul +login/mdp pour tout. +Avantages : + +* plus simple pour les users à comprendre et à retenir comme système +* permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de + son compte crans en entier à un « ami » + +Inconvénient : + +* le mdp est le même partout, cela peut poser un problème de sécu en + particulier pour les admin. + +On identifie les fonctions sensibles : il s’agit de l’accès web re2o, et des +accès serveurs (sudo en particulier). +L’autre problème concerne la phase transitoire, il va falloir gérer les mdp +legacy des machines, mais il « suffira » de tweaker un peu auth.py au moins +temporairement pour ça. + +Plusieurs solutions possibles : + +Avoir un second compte; on est tous d’accord pour dire que les gens ne s’y +tiendront pas, cette solution semble trop pénible. + +Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en place +un second mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas +satisfaisant d’après Charlie, cela n’augmente pas la sécurité, en effet c’est +toujours le même mot de passe entre l’accès serveur, l’accès gitlab ou l’accès +mail, mais surtout les accès serveurs sudo qui sont la pièce critique, comme +actuellement au CRANS. + +On peut forcer l’authentification par clef ssh pour les admin, comme ça si un +mot de passe est compromis, les accès serveurs ne le sont pas. Problème : cela +ne résout pas le problème de l’accès re2o-web qui serait toujours le même mot +de passe. + +On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe +pour les admin permettant de récupérer leurs droits sur re2o-web, ce qui permet +de couvrir à peu près tout. Le débat reste ouvert. diff --git a/compte_rendus/2018_05_16.md b/compte_rendus/2018_05_16.md new file mode 100644 index 0000000..cfc853f --- /dev/null +++ b/compte_rendus/2018_05_16.md @@ -0,0 +1,156 @@ +# Réunion du Collège Technique + +* Date : Mercredi 16 mai 2018 +* Lieu : Kfet +* Début : 19h00 +* Fin : 20h40 +* <> + +## Présents + +* Grizzly +* Chirac +* Charlie +* Boudy +* Blupon +* Mikachu +* Esum +* Poult +* 20-100 +* Pollion +* Fardale +* Gasnier (19h21) + +## Ordre du jour + +### Devis + +On a un devis pour le nouveau serveur, la ram pour ft et les disques de la +baie, à valider. + +On valide le devis pour le nouveau serveur 4900€ TTC, 600€ TTC de RAM pour ft. + +Pour les disques, il faut du SAS v2 2To, Anne peut pas les prendre, on les +prends sur ldlc. On commence par en prendre un. + +### Multicast wifi + +Le Multicast wifi pose des problèmes de perf, il faut envisager de bloquer le +multicast entre WLAN/LAN. + + + +On commence par le mettre à la Kfet pour tester, et on passe à l'échelle si ça +marche. + +### Parefeu + +Présentation et plan d'attaques. + +* Le pare feu génère un set de règle indifférement v4/v6, puis traite ce qui + doit être particulier. +* Le parefeu de Nit devait rattraper plein d'erreur, par construction et à + cause d'ipset, qui était notamment nécéssaire pour le filtrage mac/ip. + Aujourd'hui, on a le dhcp snooping et le radius qui check le mac/ip, on est + plus sur que ça vaille le coup de le faire dans le parefeu. +* Il y a des vieilles blackliste paiement qui traine, c'est par très pertinent. + Le pb est qu'il y a la période de blacklist paiement +* Sur zamok, les blacklist hard sont bloqué en input, on peut le retirer. + +Vu qu'il n'y as plus de filtrage mac/ip, on peut juste régénerer quand on ouvre +des ports. Il y a un fonction delinblacklisthard dans le parefeu, qu'il +faudrait appeller quand on retire une bl. On peut aussi regen le parefeu plus +régulièrement. + +Attention, le pare feu a laissé "parfois" passer la note de test. C'est chelou, +et on sait pas d'où ça vient... + +Deux grosse étapes: + +* Il faut faire un cahier des charges sur le wiki. Chirac propose un premier + cahier des charges. +* Debuguer la partie v4 du nouveau pare feu, et unifier. Ça peut-être pertinent + de faire des tests sur sable avec le nouveau pare feu. + +### Fin de la migration des ipv4 ? + +Il y a encore 27 machines fixes avec des ip Crans-ENS. + +* Il faut poker OSM (esum), federez (?) et respo-info (Grizzly) pour finir. + +### Problèmes de VLAN + +Actuellement les switches ne peuvent détaguer qu'un seul vlan sur leurs prises, +ce qui posent des problèmes lorsqu'un adhérent ou un club branche à la fois des +machines à ip publique et des machines à ip privée dans sa chambre/local. + +Chirac propose d'utiliser une fonctionnalité des switches pour détager +plusieurs +vlan () +mais cela casse plus ou moins le broadcast (qui pose problème pour les ip v6), +mais cela n'a pas fonctionné lors de la mise en prod (ou bien ça n'était pas +activé ?). + +* une possibilité serait de mettre les ip privées et publiques sur le même vlan. +* une autre de mettre des switchs manageables à servens, etc (mais là on doit + le faire pour toutes les chambres) + +Options : + +1. fusion des vlans +1. switchs manageable à la Kfet et a servens, et par défault un personne qui a + une machine publique a toutes ses machines publiques +1. dhcpv6 +1. vlan tagged sur les prises + +On envoie le vlan ip publique en tagged + +### Certificat wildcard + +Benjamin propose d'utiliser un certificat wildcard pour les services webs, +c'est possible d'utiliser un challenge +DNS (voir ) en tirant le +paquet () depuis +stretch-backports et d'écrire un script pour l'automatiser. + +On le garde en tête, re2o ? + +### Mise à jour des serveurs + +#### Mise en prod de kiwi ? + +On met kiwi en prod, (il faut vérifier que la création de compte wiki +fonctionne en ip pub et privé), on migre juste le wiki en laissant tourner +niomniom. On annonce un downtime une semaine à l'avance avec un bandeau sur le +wiki. Il faudra aussi remettre en place le rsync vers soyouz pour wiki2. + +#### Mise à jour de redisdead + +Maintenant que le feu de la migration est passée, on aura peut-être du temps +pour terminer les upgrade. Faut-il prévoir une interruption de service ? + +Il faut le faire, et prévenir les gens. On est pas particulièrement pressé, on +essayera de prévoir une maintenance, ptet faire en même temps que odlyd2 et +owl, omnomnom, zephir. + +### Problèmes de connexion + +Des gens ont fait remonter des pb de connexions. On ne sait pas pourquoi, il +faut trouver des moyens de diagnosatiquer. On parle de pb de pings, de pb de +paquets perdus. +On a déjà augmenté les coeurs de ipv6-zayo, ça a amélioré un peu le ping en v6. + +La limite de débit retiré pourrait être une piste, mais l'uplink serait saturé +en GB, ce qui n'est pas le cas. + +Des questions de QOS, etc. + +Bref, on sait pas ce qu'il se passe, il faut trouver des moyens d'investiguer. + +### Questions re2o + +* Mot de passe unique (cf mails @nounous) +* problème du .forward +* créer compte wiki + +Repoussé à la prochaine fois. diff --git a/compte_rendus/2018_06_19.md b/compte_rendus/2018_06_19.md new file mode 100644 index 0000000..01e62fb --- /dev/null +++ b/compte_rendus/2018_06_19.md @@ -0,0 +1,118 @@ +# Réunion du Collège Technique + +* Date : Mardi 19 juin 2018 +* Lieu : 2B +* Début : 19h22 +* Fin : 20h10 +* <> + +## Présents + +* Blupon +* Boudy (va bosser) +* Charlie +* Chibrac +* Esum +* Gasnier + +## Ordre du jour + +* Création de comptes wiki +* .forward +* Le CAS +* Mot de passe unique +* ARPEJ + +## Créer compte wiki + +Quelle est la bonne manière d'interfacer le compte re2o avec le compte wiki ? + + + +On remarque que c'est ptet pas release critical, mais pouvoir se logguer sur le +wiki via le cas semble tout de meme pratique. + +## Problème du .forward + +Ce serait bien de ne plus avoir à écrire dans les homes des gens pour le +.forward. Le mail de redirection serait idéalement stocké dans la BDD, et +postfix pourrait taper directement dedans. Il y a le problème des gens qui +veulent conserver un .forward custom (procmail) + + + +## Le CAS + +Que va devenir le CAS avec re2o ? + +Est-ce qu'on prévoit de le faire fonctionner avec re2o ? + +Est-ce qu'on le garde uniquement pour quelques services ou pas ? + +re2o ne change rien pour le CAS, on exporte toujours la base ldap. On peut, si +on veut, permettre le login re2o via le cas, mais c'est le seul point. + +## Mot de passe unique + +Dans re2o, il n’y a qu’un seul login/mdp pour tout, et donc les machines wifi. + +Avantages : + +* plus simple pour les users à comprendre et à retenir comme système +* permet d’éviter la fraude, en effet, il est moins facile de filer son mdp de + son compte crans en entier à un « ami ». + +Inconvénients : + +* le mdp est le même partout, cela peut poser un problème de sécu en + particulier pour les admin, qui ont accès aux serveurs + serveur web +* la phase transitoire, il va falloir gérer les mdp legacy des machines, mais + il « suffira » de tweaker un peu auth.py au moins temporairement pour ça. + +La grande question est : est-ce que cela pose un véritable problème de +sécurité, ou est-ce que je fais parler ma paranoïa actuellement ? + +Si oui, il faut trouver une solution : + +* Avoir un second compte; mais ça semble pénible, est-ce que les gens le + feront ? Cela dit, pour les nounous, si on a un compte avec que sudo, pas de + mails, etc, et un autre pour tout le reste, on a pas vraiment le choix… +* Pour les admin ou pour les gens qui le souhaitent, on pourrait mettre en + place un second mot de passe pour tout ce qui n’est pas le wifi. Ce n’est pas + satisfaisant d’après Charlie, cela n’augmente pas la sécurité, en effet c’est + toujours le même mot de passe entre l’accès serveur, l’accès gitlab ou + l’accès mail, mais surtout les accès serveurs sudo qui sont la pièce + critique, comme actuellement au CRANS. +* Forcer l’authentification par clef ssh pour les admin, comme ça si un mot de + passe est compromis, les accès serveurs ne le sont pas. Problème : cela ne + résout pas le problème de l’accès re2o-web qui serait toujours le même mot de + passe. Par aileurs, en cas d'urgence, c'est balot de ne pas pouvoir réparer + le crans juste parce qu'on a pas son propre pc sous la main. +* Faire taper ailleurs que dans la base ldap la commande sudo, pour pouvoir + avoir un autre mdp (c'est possible simplement ?), et pareille sur re2o-web. + +. --> dans man 5 sudoers il y a le flag `rootpw` qui permet de prompter le mot +de passe de root plutôt que celui de l'utilisateur. +. (il y a aussi `runaspw` et `targetpw` qui ont des comportements du même type) +. Sinon ça peut se faire avec un module PAM, c'est un peu chiant mais ça peut +s'écrire en python. + +On peut allier les 2 solutions; forcer l’auth par SSH + second mot de passe +pour les admin permettant de récupérer leurs droits sur re2o-web, ce qui permet +de couvrir à peu près tout. + +Il y aura un problème à la transition, car les machines enregistré ne seront +pas sur le système du single password. On pense mettre côté auth.py une table +had oc contenant toutes les exceptions, que l'on fera disparaitre à terme, mais +pas en même temps que la rentrée. On peut envisager de faire disparatitres les +exceptions au fur et à mesure, genre tiers par tiers, pour ne pas avoir trop de +monde en même temps dont les machines wifi ne marchent plus. + +On propose de mettre en place un système à deux mot de passes. Le premier est +pour le compte classique, le second permet d'accéder à tous ce qui demande des +droits (ssh, re2o). + +## Arpej + +Il n'y aura pas d'ARPEJ d'ici le 2 juillet, et entre le 3 et 11 aout. À part +ça, feu. diff --git a/compte_rendus/2018_09_11.md b/compte_rendus/2018_09_11.md new file mode 100644 index 0000000..d2ad41d --- /dev/null +++ b/compte_rendus/2018_09_11.md @@ -0,0 +1,223 @@ +# Réunion du Collège Technique + +* Date : Mardi 11 septembre 2018 +* Lieu : Condorcet +* Début : 19h00 +* Fin : 21h15 +* <> + +## Présents + +* Charlie ! +* Chirac +* Fardale +* Blupon +* Bernie', «en chemin» à 19h06 (arrivé à 19h50) +* Mikachu +* Benjamin +* Hamza +* Grizzly +* Gauthier +* Émile +* Ed Pi +* Antoine +* David +* Erdnaxe +* Pollion +* Zéphyr +* Gasnier +* Boudy (arrivé à 19h50) +* Arcas (arrivé à 19h50) + +## Ordre du jour + +### Points triviaux + +* Le dépôt bcfg2 est en public et il y a le mail de JL (entre autres) dessus… + * Il est en privé, c'est réglé, LOL +* La TV ne marche toujours pas… + * Il faut faire des tests... + +. Pollion, Fardale et Mikachu + +* Il faut renouveler(?) la clé GPG du miroir jessie... + * Non, on passe à stretch + +### Débrief de la migration + +Comment ça s'est passé, de quoi on en content, de quoi on est pas content. +Pendant une semaine, début août, il y a eu la grande migration.<> + +Y a eu des problèmes, y a rien eu de dramatique. Y a pas de perte de données, +internet a pas été coupé trop longtemps. On espère ne pas avoir planté trop de +mines. Par contre, on a cassé plein de sides trucs (DNSSEC, quota, comptage +d'upload, wiki page perso, authentification wiki...) + +Fardale : le côté dommage de la migration, c'est que des choses ont du être +finies pendant. Les délais et contraintes sont compris, mais ça a rajouté des +problèmes. + +Il nous a probablement manqué une ou deux semaines. Quoi qu'il arrive, on +aurait pas été capable d'anticiper tous les problèmes. + +Bottom line : maintenant, on a re2o. + +> on dev dans le cadre d'un projet partagé par plusieurs assos + +C'est classe, et/mais ça rajoute des contraintes, et des dépendances externes. + +A terme, notre instance en prod doit juste suivre la branche master, i.e les +release. + +Reste-t-il d'autres choses à faire ? + +* problème de wifi intermittent (est-ce nouveau? ) + * Oui, c'est nouveau. Ça concerne pas tout le monde... + * Il faut faire du debug + * il faut quelqu'un sur le campus, pour faire un rapport complet. + * quelles bornes, tcpdump, que dit la borne quand ça arrive ? etc + * c'est en théorie faisable par un apprenti, ne pas hésiter à harceler + une nounoue, ils sont là pour ça + +* investiguer les problème de mails qui disparaissent ? + +* quota + * il faut remettre les quota à jours ? + * il faut reboot zamok, semba ? + * il faut désarchiver le script alias, et mettre dans le path le logsearch +* parefeu sur zamok + * y a une tache phabricator, le problème concerne l'accès à adm + + * pare-feu partout : arrêtez de DROPer des trucs légitimes + légitimes = refused drop au lieu de reject sur certains paquets + + * ssh2 en 443 vers zamok + +* refactor formulaire inscription + * Grizzly est dessus. On demande pas la gpg fingerprint ou la chambre à + l'adhésion + * Je certifie ne pas avoir de compte crans + * Mineur ? Transférez au CA. + +* comnpay fait des factures invalides. Le crans ne récupère pas l'info de + comnpay. C'est réglé <3 + * 3dsecure, est activé pour les cartes étrangères. Sad reacts only. + * Paypal ? Grosse commission ? Oui. + +À partir de maintenant, on ne peut soumettre que des problèmes déjà réglés en +IN. Voilà. Prout. + +* synchro des MLs automatiques + * Oh LOL, mailman 3 + +### Les idées futures ? + +* remettre l'ipv6 sur un serveur physique ? + * on pourrait tenter de remettre l'ipv6 sur odlyd, puis de le passer en main. + +[Nomination de nounou, ça mérite bien un point au CR, nan ?] + +* Pour avoir avec succès répondu à une question piège, esum est nommé Nounou. + Yeah !!! (bon, c'est aussi parce qu'il a fait plein de trucs. Mais surtout + parce qu'il a répondu à la question) + +* Créer un certificat racine autosigné et déployer des certificats sur bcfg2 et + gitlab.adm… + * Deux options, un certifs LE (génération un peu embêtante), ou un autosigné. + * celui qui fait fera comme il veut, Mikachu peut donner des conseils + utiles + +* Générer un certificat wildcard pour les serveurs https + * en fait, on fait ça, c'est bien + +* crans.ens-cachan.fr a disparu. Do we care ? + * Non -> mail d'apf à Sabrina, à suivre... + * Ce serait cool qu'on supporte encore ça pour les adresses mails. + +### Don de vieux matos ? + +cf . + +On a voté en CA pour donner des vieux serveurs avec approbation du CT, est-ce +qu'on valide ? + +* Ok +* OSM on s'en fouiche. +* Sable, il faut le wipper de manière propre avant de le donner. Faisons un + backup avant + * Fardale est cahdu + +## Petites idées (d'un câbleur) + +* Défaillance du lundi 10 septembre, qu'est-ce qui s'est passé ? Qu'est-ce qui + l'a causé ? + * bcfg2, thot , pgsql PLS, radius dead, restart, OKLM. + +. Chirac : "C'est ma faute" + +* Envoie de mail via PHP qui résulte en une erreur MSFRF2612, problème de conf + SMTP automatique ? + * J'ai aucune idée de ce que ça veut dire. +* Problème de configuration de Apache qui se croit en HTTP bien qu'il soit en + HTTPS... + Exemple : + * dans l'idéal, il faudrait ptet passer les pages perso en proxifier. On va + invoquer les vieux. +* Autoriser qqu qui n'a pas un mail @crans.org à accéder à Phabricator + * si il a pas un mail @crans.org, on l'aime pas. + +* on a pas de reverse DNS en public sur l'ENS, la délégation n'est plus bien + définie. + * il faut demander à la DSI, vite. + +## Bilan RTC + +Voici donc que je fusse RTC pendant 3 ans. Je n'ai évidemment pas fait ce qui +suit seul, bien loin s'en faut, mais au cours de ces 3 ans (ouais, un peu +moins, c'était depuis le 3 décembre 2015), il y a eu quelques changements, dont +je suis plutôt content. Merci les copaings ! + +Il y a maintenant : + +* des services redondés sur serveurs virtuels et physiques par paires +* un Full Master Backup, capable de gérer seul le réseau +* des certificats let's encrypt, via une centrilisation de l'https, avec des + jolies confs https pareilles partout +* plus de bornes wifi, et branchées sur des switches POE +* une nouvelle fibre en plus, indépendante de l'ENS +* un logiciel de gestion en projet commun inter écoles +* phabricator, un système *utilisé* de gestion des tâches. +* un backup externe du wiki + +Il n'y a plus : + +* des scripts essentiels codé par des gens dont plus aucune nounou active ne + connait le visage +* des scripts capitaux montés en NFS +* une migration partielle, avec un vieux binding encore plus ou moins utilisé à + des endroits +* les perms d'inscriptions sous peuplées et pas assez tenues (y a encore des + perms, mais bien plus légères) +* des références complétement outdated sur des pages wiki de serveurs ou + services critiques. +* de système de communication intra campus vraiment utilisé et géré par le crans + +Ce qu'il manque pour un monde plein de paillette (aka, ma liste au père noel): + +* DNSSEC + * Benjamin s'en occupe, on fait ça après octobre. +* Redondance psql +* Tout le monde sur des ips et la fibre zayo, avec fallback sur l'ens via bgp + multi homing en cas de pépin moi je te soutiens charlie <3 +* une imprimante qui brule +* une réinscpection à la loupe de re2o pour éviter les mauvaises surprises. +* porter l'appli wiki (d'une manière cool, genre, y a t'il vraiment besoin de + qqch dans re2o ?) +* porter l'appli page perso +* toutes les machines sous stretch +* ansible <3 + +Pollion est le nouveau RTC <3 <3 <3 + +Son gateau était bon, et open source diff --git a/compte_rendus/2018_10_17.md b/compte_rendus/2018_10_17.md new file mode 100644 index 0000000..36f3928 --- /dev/null +++ b/compte_rendus/2018_10_17.md @@ -0,0 +1,245 @@ +# Réunion du Collège Technique + +* Date : Mercredi 17 Octobre 2018 +* Lieu : Condorcet +* Début : 20h00 +* Fin : 22h20 +* <> + +## Présents + +* Pollion +* Grizzly +* PAC +* Gasnier +* Chirac +* Mikachu +* Emile +* Edpibu +* Fardale (via jitsi, et il a marché !) +* Arcas +* Erdnaxe (arrivée 20h13, départ 21h50) +* Boudy (arrivée 20h30) +* Quentin Petitjean (arrivée un peu avant 21h) + +## Ordre du jour + +### Renouvellement garanties + +Stitch et Thot arrivent en fin de garantie +les 4/11/2018 et 07/12/2018 respectivement. +Thot date de 2012, on ne renouvelle. On passera temporairement sur vulcain s'il +nous lâche +Stitch : On renouvelle ! + +### Problèmes rencontrés + +Ces derniers temps on a rencontré quelques soucis, qui ont pu être réglés, +d'autres non. Ce n'est pas forcément totalement dû à la migration mais on +surveille. + +#### Routage + +On a subit des pertes de routes BGP mais ça semble s'être calmé. On +sondera icinga. + +#### Instabilité Wifi + +Gros problème sous MacOS, on a désactivé le fastroaming, ça a réglé beaucoup de +cas mais certains adhérents ont toujours le problème. Faudrait vraiment +chercher. Gasnier signale en particulier des broken pipes en ssh, ou lors +d'envois massifs de mails mais ça ne se voit pas trop dans le reste des +cas (youtube etc...) + +#### Perte de paquets + +Avec !FastRoaming au bout de quelques minutes on était connectés mais plus +rien, ou ping abérant, connexions ssh qui mettent 1000 ans, mais ça a été réglé. + +#### Scams mails (rejet redirection ens) + +Arnaque identique dans pas mal d'autres organisations. + +On a forcé l'authentification. Ça pose aussi des problèmes... +Anti-spam au crans ? + +On décide de bloquer sur tous les serveurs mail, on débloquera quand on aura +mis en place un truc comme DNSBL (Proposition de Mikachu). +[Tache phab associée.](https://phabricator.crans.org/T412) + +#### DNS + +Il semblerait que l'on ait perdu la délégation de crans.ens-cachan.fr et +clubs.ens-cachan.fr. On a envoyé des mails à la DSI, sans réponse. On ira les +voir en personne pour leur demander. On en profitera pour leur demander de +déployer le VLAN 22 au bon endroit, ainsi que de whitelister notre /22. +On fera une liste de ce qu'il faut leur demander. + +* Mikachu : Est-ce que crans.eu et crans.fr sont générés par re2o correctement ? +* Chirac : Oui c'est un probleme connu, faut faire du code dans re2o. +* Chirac se porte volontaire pour piloter quelqu'un dessus, il marquera ça sur + une tâche phab. + +#### DHCP + +* Le service est régulièrement en failed sur le serveur dhcp et il faut + supprimer le pidfile pour redémarrer le service. ---> On va checker les bugs + report debian, On propose de faire un unitfile qui fait le taf. +* Machine qui prend mauvaise ip ---> Il faudra regarder, ça semble n'être que + des cas isolés. +* Passerelle mal detectee sur W10 (au moins 3 cas) en filaire --> Notre expert + bug report (aka Gasnier) signale que certaines machines sous W10 ne + trouvaient pas la passerelle. Il gardait en mémoire la passerelle de + switches. On peut peut-être spécifier le / d'ip que les switches prennent. + +Le workaround était de mettre la passerelle à la main. Ça marchera plus +ailleurs, mais c'est plus notre problème /o\ + +### Wiki en RO + +Fardale avait essayé de voir, mais ne savait pas d'où ça venait. On demandera +aux adhérents concernés si c'est tombé en marche. + +### Probleme d'attribution des chambres + +Portail captif qui marche pas partout. On a envoyé un mail aux adhérents +concernés. Beaucoup d'adhérents ont répondu. + +Proposition : Les adhérents demandent une chambre, et un cableur vérifie ? + +Projet apprenti ? +On fera une tâche phabricator. + +### Switch + +Bata-0 aurait apparemment un soucis ? Il va falloir regarder. + +### Mails de cron + +Les mails de cron (1344 le 9 octobre par exemple) : on prévoit un moment pour +réparer un peu tout ce merdier ? + +* Fardale a réparé une grosse partie des mails liés à bcfg2 (soucis de + génération de conf, apparemment réglés, sauf la radio --> Osef On va drop la + radio). +* 2eme vague de cron : adhérent qui est en double dans aliases.db sur + redisdead, soyouz, freebox, zamok, titanic..... +--> Boudy s'en occupe. De quoi ?! + + * Fardale : Le bug vient de l'intranet ou pas ? + * aid=2127 d'après le fichiers aliases de postfix son compte a été détruit + en 2014 mais il apparait comme actif sur l'intranet, du coup ça pose des + soucis car la redirection apparait 2 fois dans le fichier aliases et + postfix se plaint. + * TODO : régler le problème en scannant les users qui auraient du etre + supprimés; et se débarasser le cas échéant des doublons. +* 3eme type de mail : Erreurs 500 de l'API --> Ça coïncide avec logrotate. Nit + a proposé une solution, à tester. On décale le logrotate de 10 minutes pour + voir si c'est vraiment lié. + +### Problèmes sur Icinga + +* {{{/var/log/spool}}} de ft se remplit, les logs n'arrivent pas sur thot + * Fardale a regardé, mais ne sait pas trop d'où ça vient. Problèmes dans les + confs (Erreurs de syntaxe ?). Quantité énorme de logs, 1Go en 3 jours. Ca + a l'air d'être le cas uniquement sur ft. + * Chibrac: C'est un probleme de proxmox. +* ntp sur soyouz --> Fait exprès ou pas ? Soucis dans la génération de la conf. + Sombre histoire d'(ip-)typage. + +TODO : Refaire le script, vérifier qu'un soucis similaire n'existe pas dans +d'autres endroits. + +### Doc + +* IL FAUT FAIRE DE LA DOC sur ce qui a été fait, notamment au moment de la + migration. CF la tâche phab [mise à jour wiki](https://phabricator.crans.org/T234). +* Gasnier souligne qu'il va falloir une doc très claire en prévision de la + reprise du réseau par des inconnus après le départ de l'ENS vers la lointaine + saclay + +### TV + +La TV ? Le cochon est vivant ? +Boarf, il survit, mais le courant au J fait de la grosse merde. L'onduleur +commute en permanence.... +On tâche phab et on regarde après. + +### Bilans + +* Poses de nouvelles bornes. On a enfin du wifi dans certains lieux reculés du + G. On est au chomage technique car on n'a pas reçu les bornes. Il faut les + appeler, mais il faut quelqu'un qui parle Allemand. Ou on attend. +* Nouveau + système [provisioning de configuration des + switchs](CransTechnique/AutreMatériel/AjouterUnSwitch#A3_-_Provision_de_la_config). + Ça semble marcher, c'est cool, Chirac dit que c'est documenté, on le croit. +* Bilan sur la detection de mac + web redirect --> ça marche ... presque + partout. Pas de web redirect, pas de web redirect. A partir de ce WE tous les + switches du campus pourront en faire. Tous ? Non un certain nombres + d'irreductibles ne font pas de web redirect... +* interface d'impression --> Elle est prête, je finis de vérifier les bugs, + mais normalement elle devrait être lancée ce weekend. Soucis d'ergonomie, Je + vais suivre les conseils des experts tels qu'edpibu ou Grizzly. +* Où en est le firewall ? --> Le fw marche mais n'est pas satisfaisant pour + Chibrac. Le rezo metz est en train de dev un truc avec Nftables. On verra + pour le déployer au crans, mais faut pas que ça casse des trucs. + +Actuellement il juste marche. + +### Ménage + +* Chibrac dit qu'il faut faire du ménage dans les profils de port (renommage, + fusion etc). +* Pollion: Il faudrait faire ça aussi pour les noms des vlans ... + +### Projets + +* Apprentis : +* Recablage de qqs chambres au C: 0C ou 5C ? Notre respo tech préféré se + propose pour aider des gens à recabler. On commande une armoire de brassage, + on fait ça proprement dans une semaine. +* Cr@ns-Open --> Grizzly et chirac regardent, si des apprenti.e.s sont + motivé.e.s ,pour les rejoindre, qu'ils parlent maintenant, ou se taisent + jusqu'à leur prochaine intervention. +* Machines Legacy --> On droppe à la rentrée des vacances de la Toussaint. +* Boudy : Le compte Crans qu'on utilise depuis tout le temps, il faut qu'on se + crée un autre compte qui aura les droits. Car le mot de passe pour se + connecter en wifi ou les mails (c'était déjà le cas avant, ça veut pas dire + que c'était mieux) c'est le même que celui pour être root sur les serveurs. + On envisage de changer ça. + * PAC: Propose une authentification 2FA --> C'est pas con. + * Erdnaxe : Toutes les nounou doivent avoir une Yubikey. Même gdm le + supporte ! + ---> Et sur tel on fait quoi ? + + +On demande à Charlie ce qu'il en pense. + +### DNSSEC + +--> Benjamin, Boudy intéressés. Pour les tests on signera d'autres zones comme + crans.fr et crans.eu. ça implique de réparer la génération de ces zones !! + +Liste non exhaustive de projets : + +* Mailman3 +* Ajout automatique aux ml suivant les droits +* ssh2 +* système de ticket ? +* ansible <3 erdnaxe +* Changement système de virtualisation. Vers la fin de Proxmox ? -> Oulà on a + d'autres chats à fouetter avant. Et les remplaçants potentiels se bousculent + pas au portillon. +* webnews +* faire des qrcode/tag nfc pour automatiquement conf le wifi des adhérent (des + trucs récents permettent de supporter WPA2-Entrep. sur ce genre de conf) + +### Mises à jour + +stretch (zephir et omnomnom ; et news :P ) + +* chiffrement des backups, et de la clef de chiffrement ! + +Fardale dit que la partition pour les homes des adhérents est déjà faite, +suffit de chiffrer. diff --git a/compte_rendus/2019_01_14.md b/compte_rendus/2019_01_14.md new file mode 100644 index 0000000..96172ab --- /dev/null +++ b/compte_rendus/2019_01_14.md @@ -0,0 +1,391 @@ +# Réunion du Collège Technique + +* Date : Lundi 14 Janvier 2019 +* Lieu : 2B +* Début : 18:47 +* Fin : 21:01 +* <> + +## Présents + +* esum +* Chibrac +* Erdnaxe +* Edpibu +* elkmaennchen +* Boudy +* Pollion +* Fardale (en visio) +* Mikachu (arrivée vers 20h15) + +## Ordre du Jour + +### Bilan des activités crans de ces dernières semaines + +On fait un rapide bilan pour que tout le monde soit au fait de ce qu'il se +passe en ce moment niveau technique. + +* On n'a toujours pas d'imprimante. + +. Mais on a fait des tests en snmp on récupère plein d'info, Pollion finit ses +oraux blancs et s'y remet à partir de vendredi. +. Erdnaxe propose de se renseigner plus sur Icinga pour avoir un meilleur +monitoring de l'imprimante. + +* Autre truc cool, on a remis DNSSEC au crans. Chibrac rappelle qu'il y a des + vieux fichiers localement sur silice, on fera le nettoyage. + +* Buster freeze bientôt, Boudy fait remarquer qu'on a encore des serveurs sous + Jessie... + +. Apprentis intéressés ? + +* On a fait plein de ménage dans les mails de cron, c'est moins la guerre. +* Mirroring du dépot re2o upstream au crans, du coup toutes les instances du + crans pullent depuis le crans et sont à jour. +* On a augmenté le nombre de connexions simultanées à la bdd et on a fait le + ménage des restes de pg 9.1 et 9.4 qui traînaient sur thot. +* ça ne règle pas tous les soucis, il reste encore des services qui + plantent (exemple erreur 500 sur l'API pour mail-server ...) + +* Grâce à Boudy un problème sur les home avait été soulevé : Les home en + majuscule posaient soucis. (les vieux diront que c'était mieux avant et + qu'ils l'avaient dit mais ....) Il a été réglé. + +. Il faudra regarder le script des homes suite au renommage.... + +* Soucis avec unifi, chibrac regarde il s'en porte garant devant témoin, + c'était son idée. + +. Erdnaxe aimerait bien (dans un monde idéal) avoir un prof crans pour ça, +surtout qu'il y a de l'intégration Incinga-Unifi à faire je pense + +* On a réglé le soucis des noms des logs du fw sur le nfs. + * Odlyd possède une partition à part pour le {{{/var/log}}}, ça peut être + cool de faire pareil pour gulp. En plus il y a plein de place + dans {{{/var/log}}} sur odlyd. Il faut aussi mettre en place un rsylog + pour envoyer les logs d'odlyd vers {{{/home/log}}}. Comment ça marchait + avant avec sable ??? + + * Fardale soulève le fait qu'il y aurait un soucis avec rsyslog sur thot. + Pas mal de vm ont des soucis : Leur {{{/var/log/spool}}} se remplit .... + ce sont les fichiers en attente d'être envoyé sur thot.... + +. Il renseigne tout sur + +* On a aussi migré le gitlab vers le paquet omnibus. + +* re2o des choses ont changé, le crans a activement participé au dev de 2.7, + qui arrive soon. + +### Certificat SSL cassé + + et il n'y a pas de redirection HTTP > HTTPS + +* c'est normal, le port 443 est utilisé par le serveur irc +* il pourrait être derrière le proxy ?! +* possible mais c'était pour ne pas changer l'url + +Voir le Wiki sur la centralisation +HTTPS : + +Fardale explique pourquoi c'est comme ça, on laisse comme ça, c'est normal. + +### Petite pause + +Chirac fait une démo de mise à jour de borne, il casse internet, à cause de lui +l'IN fait une pause de 10 min. + +### Parefeu + +Zamok: l'accès au vlan adm depuis zamok est restreint par une série de reject. +Du coup il existe une race condition. Si un compte est crée et que le parefeu +n'est pas régénéré ce compte aura accès au vlan adm. +Question : Pourquoi un tel mode de fonctionnement ? +Proposition : Fonctionner sur un mode de whitelist. + +* ça semble pertinent surtout que ça va aussi drastiquement réduire le nombre + de règles à parcourir (on va passer de plusieurs milliers à quelques 100aines + au pire) +* Chibrac dit que c'est à cause du NFS que c'était la merde, Erdnaxe pense que + c'est un faux problème. + +Faut regarder mais tout le monde sauf Chirac trouve ça pertinent.... + +Par ailleurs, les services re2o de régénération du parefeu plantent salement. +On en a déjà parlé, mais il faudrait régler ça soon. + +### Mail + + est accessible depuis l'extérieur. +Pourquoi ? Actuellement on peut scanner les addresses mails des admins, c'est +chiant. Pollion propose de le dissimuler comme listinfo. + +* Mikachu plussoie +* ça semble simple, Pollion regarde avec sa croziflette après l'IN. + +On envoie trop de spam. + +* quand on aura fait le ménage dessus, ce serait pertinent une alerte icinga + qui affiche la taille de la mailq (si elle existe pas déjà). comme ça quand + elle est trop grande une nounou peut regarder et réparer et/ou aller + gentiment blacklister les comptes qui font nawak +* On a archivé les 3 comptes qui posent problèmes. + +. L'archivage : + +* Chibrac : Il faut qu'on parle de ce qu'on veut. +* Fardale : Il faut que Archivage soit un super-set de désactiver. +* Actuellement : + * Désactiver : Actuellement t'es plus dans le LDAP. + * Archivage : Desactiver + ça supprime ça libère les IP . +* Ce qu'on veut : + * Désactiver : On veut garder dans le LDAP mais passer shadowExpire=0. + * Archivage : On veut supprimer de LDAP + supprimer en plus les home. On + veut garder le minimum légal. + +On reçoit trop de spam + +* on a mis en place des trucs. +* Benjamin : Il y a un bot qui s'appelle peb qui périodiquement BL des IP. + +en cas de redirection @ens-cachan.fr -> @crans.org avec mail avec from +en @crans.org se fait jeter par redisdead car il n'est pas authentifié. + +Question : Quelqu'un a une solution ? Une idée pour chercher ça ? + +* On propose de WL l'ENS, et on regarde ce que font les autres. + +### VLAN Pub + +Il faut passer le vlan pub (aka adh) en tagged comme on l'avait suggéré à une +IN en Avril/Mai/Juin 2018, je ne me souviens plus. Qui est chaud pour +aider ? Des apprentis ? + +Bon, en fait Chibrac crache le morceau, c'est un peu plus compliqué que prévu +...... Il faut changer auth.py .... +Les apprentis font un séminaire sur les switches, puis freeradius. + +### Migration + +Il faut finir la migration entammée l'an dernier. Benjamin a envoyé un mail à +rezosup concernant leur vm, des nouvelles ? + +* Non. On les relance... + +Il faut déplacer les IP publiques des serveurs sur le VLAN dmz, pour unifier un +peu tout ce bordel. + +* On groupe tout ça avec les services, on fera une réu bientôt. + +### mailman3 + +Contextualisation: Actuellement on utilise au crans Mailman comme moteur de +mailing list. Une nouvelle version très différente et améliorée arrive avec +Debian Buster. Actuellement il existe une vm mailman3 mais elle a été recyclée +à partir d'un ancien routeur v6 et c'est pénible de faire le nettoyage. On +cherche donc un (ou plusieurs !!) apprenti pour nuker définitivement cette VM, +installer une nouvelle VM et faire joujou avec mailman3. + +* Erdnaxe veux bien le faire à partir du vendredi 25, mais je fais déjà des VM + donc autant que quelqu'un se forme +* Pollion veut bien encadrer. + +### Services à nuker + +On propose de se débarrasser des services suivants : + +* Limesurvey --> Chibrac est contre le nuker, le reste est pour --> On nuke, + et Federez peut se faire un LS +* Ethercalc --> Ok on nuke sauf si quelqu'un se réveille et rale du fond de sa + cave. +* ligne de VoIP --> On continue de payer la ligne sur le vieux compte OVH. On + nuke !!!!!!! + +Plus violent : + +* Horde > !NextCloud intègre un client Mail, est-ce qu'Owncloud aussi ? + * Pollion : Pour avoir fait des tests sur des instances + différentes, !NextCloud est vraiment trop gourmand en ressources par + rapport à Owncloud, et ce dernier nous suffit amplement. Je ne suis pas + certain qu'il faille en changer. + * Mikachu : Je +1, j'ai fait l'erreur d'installer Nextcloud au bureau, je + vais surement changer pour owncloud, ça consomme une quantité hallucinante + de ressources. + * erdnaxe : est-ce que l'on connait la raison ? La base de code paraît + pourtant similaire ? Après Owncloud doit surement intégrer un client mail + similaire à celui de !NextCloud, non ? + * Mikachu : normalement les plugins nextcloud/owncloud + étaient (sont?) compatibles et sinon après une recherche rapide il y a + ça : + * erdnaxe : Rainloop est une application équivalente à Horde/Roundcube, mais + qui apporte une facilité d'installation car elle se met directement + dans !OwnCloud. + +* Jabber + * Pollion : Plop, je sais que c'est un running gag mais il y a encore des + gens qui utilisent le + * Pollion : jabber du crans ? + * peb : ça arrive, mais de moins en moins + * peb : perso je m'en sers occasionnellement + * erdnaxe : qu'est-ce que Jabber apporte en plus de Jitsi/IRC ? Tout le + monde est sur Discord (mauvais argument, mais malheuresement de plus en + plus vrai)... + * Il tourne tout seul --> On garde + +### Plan de déménagement + +Avenir des services : mutualisation crans-aurore oui / non +Si oui, comment démanager les services à Orsay/Saclay ? Et dans quel ordre. + +* On fera une Réu pour ça, on en discute par mails. + +### Icinga2 (Propositions d'Erdnaxe) + +* Virer la colonne "apt" car il y a "package" ? +* association.crans.org ? Utilité ? + * +* Faire un recensement des serveurs que l'on allumera plus jamais + * +* Faire le point avec Mikachu pour savoir si Graphana+Icinga2 est toujours une + bonne idée vis-à-vis de Munin +* Mettre des raspberry pi sur Icinga et les brancher en amont des onduleurs + pour être informé des coupures élec + * Mikachu : tous nos onduleurs savent pas parler le SNMP sur l'internet + mondial et globalisé ? + * Erdnaxe : L'idée est de monitorer si le rpi est allumé ou non (en + branchant son alimentation sur une prise non alimenté par l'onduleur) + * Mikachu : oui j'ai bien compris, la question est: l'onduleur ne sait pas + parler le SNMP pour dire si oui ou non il est allimenté ? + * Erdnaxe : on m'a dit que nos onduleurs étaient pour la plupart « non + monitorables » donc je suppose que non + * Mikachu : ouki, dans ce cas je suis plutôt d'accord, modulo prendre un + truc peut être moins overkill qu'un pi (un pi 1 ou un random clone chinois) + * Erdnaxe : Un pauvre uControlleur avec une interface Ethernet pourrait + passer (ESP8266 bidouillé...) mais faudrait un client Icinga. + * Mikachu : si ça amuse quelqu'un ce serait coolish, je serais curieux + d'apprendre, mais j'aurais surement que le temps de regarder de loin :) et + tu sais pas faire parler le snmp à ton uC ? + * Erdnaxe : Il y a un truc pour les + uControlleurs qui sont sur le Framework Arduino +* > Pourquoi ne pas utiliser + qui est fait pour ? -> J'ai une très mauvaise expérience + avec à Federez, il est pas possible de l'interfacer avec un système de + scripting; l'api put/delete etc qui doit permettre cela + est (était ? ) totalement buggée + non packagé dans debian (à + l'époque ?) -> Dans ce cas remplacer le dashboard (qui est déjà composé + d'iframes) par une page Wiki (avec les iframes comme il faut) ? + * Mikachu : sinon tu parlais de se servir de grafana, on doit pouvoir faire + des dashboards dans ce style avec grafana (avec ensuite des liens fancy + vers des pages plus détaillées etc. ça peut être joli, mais faut prendre + le temps de le déployer et de le configurer (et de scripter la conf + auto (ansible mon amie :D) + * Erdnaxe : Je veux bien faire un rôle Ansible (surtout que je commence à + bien le manipuler avec ce que j'ai fait à Aurore) mais est-ce que je le + traduis ensuite en BCFG2 pour ne pas avoir deux systèmes au crans ? + * Mikachu : boarf, tu peux faire une maquette fonctionelle avec ansible et + on la déploiera en prod quand on passera à ansible :) + * Erdnaxe : Passer le crans à Ansible sera plus facile que prévu vu que j'ai + traduit déjà quelques trucs pour Aurore. + + * Mikachu : tu peux mettre ça public ? (pour l'instant il faut un compte sur + le gitlab d'aurore pour y accéder) + +### Wifi qui bogue (Propositions d'Erdnaxe) + +Constaté le soir + +Ça n'a pas l'air normal +ça : + +C'est l'occasion pour mieux monitorer les bornes avec +Icinga-Unifi ? + +* Erdnaxe : J'ai commencé des tests, la borne est toujours visible mais refuse + les connexions. Est-ce que l'on peut monitorer le lien Radius-Point + d'Accès ? Personnellement le wifi normal est inutilisable dans ma chambre le + soir et je suis loin d'être le seul dans la même frustration, du coup j'ai + mon propre AP. + +### ft.crans.org pas du tout à l'heure (Propositions d'Erdnaxe) + +On a essayé de fix avec un décalage progressif mais il continue à dériver + +* le 01/01/2019 vers 9h il a 296.11 secondes d'avance +* le 01/01/2019 vers 15h il a 308.08 secondes d'avance +* le 14/01/2019 vers 18h il a 869.49 secondes d'avance, ça empire donc... +* Mikachu : Il sait pas parler le NTP correctement ft ? en lui faisant faire + des query plus souvent pour rester à l'heure ? (je sais pas comment on + configure le daemon NTP, ce que je dis est peut être con :)) +* Erdnaxe : Bah de ce que j'ai compris on a une conf NTP client qui a pour but + de le faire converger progressivement vers la bonne heure pour ne pas tout + casser. +* Fardale s'en occupe + +### Remises à plat de l'infra (Propositions d'Erdnaxe) + +Qu'est ce qu'est oidentd ? +Pourquoi on monitore le fait qu'il soit présent sur tous les serveurs ? + +* C'est un relicat du temps où il servait à l'auth pour les connexions à la + bdd (cf ), c'est plus très utile + maintenant. -> cf + pg_hba.conf : + partout où il y a écrit ident, et une péletée de services s'en servent : + etherpad, roundcube, imap, sqlgrey, horde, mediadrop, icinga, django_cas +* c'est pas la priorité du siècle. + +Conteneur "sitesweb" +Est-ce bien un conteneur non privilégié ? + +* Erdnaxe dit que s'il n'est pas privilégié ça pose des soucis si faille de + sécu. Pollion veut bien un petit résumé de ce qu'il a dit + le lien vers le + wiki d'Aurore. +* Explications ici : + +On se met à faire des conteneurs au crans ? + +On pourrait faire un conteneur template re2o-test et ainsi proposer beaucoup +d'instances ? + +* Actuellement au crans c'est bagdad sur le virtu, on peut pas trop faire ça. + +### Wiki crans (Erdnaxe) + +Séparation partie technique / Partie vie à l'ENS ? + +* Mikachu : hein ? faire 2 wiki ? pourquoi maintenir 2 trucs plutot qu'un ? +* Fardale : la partie technique, c'est tout ce qu'il y a sous + CransTechnique (si tout le monde respecte les conventions) +* Pollion : Non. + +Erdnaxe peut se chauffer pour faire un thême crans / ENS ? + +* Mikachu : go for it, c'est du frontend, ça peut rien casser, au pire les gens + pourront se servir de celui qu'ils veulent. + +### Service de boot PXE (Erdnaxe) + +Est-ce que qqu le maintient ? + +* Mikachu : des gens qui "apprennent" sur le tas quand ça casse. En règle + générale c'est un truc qui se maintient assez bien tout seul, sauf quand des + gens font mumuse avec les plans d'addressage, dhcp, vlans etc. (en gros sur + un réseau de prod "stable" ça casse ~jamais) +* Erdnaxe : mais il faut update les iso à un moment ? ou on utilise un service + externe ? +* Mikachu : euh je me demande si c'est pas synchro avec le ftp, à vérifier. + +. je viens de voir que le script de `/usr/scripts` pour le pxe a été bougé +dans archives .... faut vraiment creuser le sujet, bon point erdnaxe. + ? -> Avant d'en déployer un nouveau, +faire complétement le ménage.. + +* Pollion : Oui + +### Site du Crans (Erdnaxe) + +Est-ce que ça gène quelqu'un si Erdnaxe auto-formate tout le code violemment +pour faciliter les futures contributions ? (problèmes de tab / 4 espaces) + +* Pollion : Go for it, bro. diff --git a/compte_rendus/2019_02_04.md b/compte_rendus/2019_02_04.md new file mode 100644 index 0000000..60efcf8 --- /dev/null +++ b/compte_rendus/2019_02_04.md @@ -0,0 +1,246 @@ +# Réunion du Collège Technique + +* Date : Lundi 04 Février 2019 +* Lieu : Salle de Conférence du Pavillon Des Jardins +* Début : 18:41 +* Fin : 21:52 +* <> + +## Présents + +* Erdnaxe +* Edpibu (jusqu'à 19h) +* Elkmaennchen +* Pollion +* Fardale (via Jitsi) +* Boudy +* Esum +* !MisterKraft (parti à 19h54) +* Baptiste Chanus +* !OursPolaire (18h49) + +## Ordre du Jour + +### Dans collège technique, il y a collège + +J'ai pas trop d'inspiration sur le titre de cette section pour l'instant, mais +j'ai quelques trucs à dire. +Il faut tenir au courant de ce qu'on fait et ne pas faire les trucs dans son +coin à l'arrache (coucou chirac même si t'es pas là) + +* Message sur #roots, ou sur les MLs nounou/apprentis, et utiliser phabricator. + +### Bilan des activités crans de ces dernières semaines + +Toujours pas d'imprimante, personne n'a eu le temps de vraiment s'en occuper. + +API re2o : Il y a une issue en cours pour faire du ménage dans l'API, et +essayer de voir ce qui bloque et pourquoi on a encore des erreurs 500. +Erdnaxe s'intéresse au problème, Pollion lui a filé un shell root dans un +screen. +> voir la gestion des tokens dans l'API : voir re2o-error.log.1 en cherchant api +> user_id: 20074 + +Création d'un ssid Cr@ns-5g pour diffuser le 5GHz et ainsi le séparer +du 2.4 GHz. Ça fait une semaine, on peut lancer de la com dessus, et prévenir +les adhérents qu'ils le capteront moins fort mais auront un meilleurs débit. Ça +peut aider à résoudre les soucis d'instabilité qu'on avait avant. + +* +* + +On fait un rapide bilan pour que tout le monde soit au fait de ce qu'il se +passe en ce moment niveau technique. + +Retours sur la dernière IN, trucs qui ont été faits, pas faits. + +### Logs + +Ce qu'on veut, ce qu'on ne veut pas, ce qui est important, ce dont on se fout. +Il pourrait être bon de revoir un peu le système de log, avec les problèmes +d'envoi de log sur thot par exemple (spool qui explose) (ce est peut être lié +au problème d'ipv6 sur les serveurs) + +### Stockage, partition, wtf ? + +Pendant ce temps /home-adh/logs et /home-adh/mail se remplissent sur zbee… +{{{ +/dev/sdaj1 630G 577G 22G 97% /home-adh/mail +/dev/sdcv1 296G 275G 6,0G 98% /home-adh/logs +}}} + +--> On a 1 T de + libre {{{/dev/mapper/lvm-stock 1008G 72M 957G 1% /stock}}} + +Pollion propose de repartitionner tout ça. + +* Dans un premier temps on bouge les vieux logs sur zbee de toute façon eux + sont déjà backuppés et zbee a de la place. +* On propose d'exporter le disque de zbee dans home-logs de façon permanente. + Il faut réécrire le script de rotation des logs du fw : Si home-logs est + monté, on l'envoie sur home-logs, sinon on le garde sur le routeur (pour + éviter les soucis en cas de crash du disque de zbee). + * A faire pendant la grosse maintenance à prévoir. +* Les mails se remplissent + * peb propose de supprimer les comptes mails inactifs qui consomment de + l'espace disque +* Partition de gulp : Actuellement gulp est partitionné à la zob, et a vraiment + plein de place libre non allouée. + * On va essayer de rétablir un fonctionnement normal, et ça règlera des + soucis de logs. +* Logs sur Odlyd. Quand c'est lui qui route, comme il n'a pas le NFS, il ne + rotate pas ses logs (cf tes mails). + * Soit on monte le nfs sur Odlyd + * Soit on rsync de temps en temps les logs d'Odlyd. + +. ==> On va rsync de temps en temps. + +Dans la grosse maintenance on va repartionner gulp et vérifier que keepalived +marche bien. + +### Futurs projets, répartition des tâches + +Pour les apprentis : Je rappelle que vous pouvez aller voir sur Phabricator +pour voir si une tâche vous intéresse et vous pouvez demander à n'importe +quelle nounou de vous encadrer. + +Pollion propose de se poser un Week-end, et de faire quelques petites tâches. +Par exemple le week-end du 09 ou du 16. + +* Mise à jour de serveurs : Les serveurs de backups sont toujours sous Jessie, + il serait temps de faire le DU. En lien + avec : + * Esum veut bien s'en occuper. +* Thelounge3 est enfin sorti. Fardale souhaite l'installer. Ça serait cool que + des apprentis y participent, surtout ceux qui utilisent thelounge :). (ça + amène plein de feature cool, comme les logs écrits dans un fichier en cas de + déconnection) + * erdnaxe est intéressé. Je note qu'il faut que je le fasse. +* Mailman3 : Mailman est le moteur de Mailing List qu'on utilise au Crans. Une + nouvelle version sort avec Buster, on veut faire une installation propre + avant sur une nouvelle vm, pour préparer la migration. Ça sera l'occasion de + parler de mails et peut intéresser les apprentis qui souhaitaient se + renseigner dessus. + * En l'absence de réponses d'apprentis, Pollion et Esum veulent s'en + occuper, ils renverront des mails sur les MLs apprentis et nounous avant + pour être sûr. +* Nuker l'ancienne vm IPV6 (actuellement mailman3). Va avec le point précédent, + et ça sera l'occasion de voir comment marche la virtualisation au crans. + * idem +* Liens wiki - re2o : + * Le wiki est old, c'est pas urgent. On a d'autres trucs à faire. +* Gros passage de doc, les gens qui savent svp documentez. Je regarde + particulièrement Chirac .... Et quand je dis doc c'est pas une copie du code, + une doc c'est un truc qui explique : "Si tu veux tel résultat, tu fais + ça". Je ne pense pas forcément à re2o uniquement, mais aussi aux reliquats + de l'ancienne infra. Exemple de pages pas à jour : + * [[CransTechnique/Services/RaDius/AttributionVlan]] + * +* Migration des derniers serveurs en zone + ENS. + * On a une quinzaine de serveurs qui doivent garder une ip publique, on les + met sur un vlan à part (exemple dmz, avec un autre nom parce que c'est pas + une dmz). Les autres serveurs sont sur adm, et certains serveurs ont + besoin d'avoir Internet (comme owncloud ou tracker) on les met sur un + range d'ip avec internet (aka fil mais pour les serveurs). + * Fardale propose de faire un VLAN séparé +* Réflexion vers Ansible : Erdnaxe ? Après le gala et Prologin, je prépare un + séminaire. Chirac a dit que les séminaires ça n'apprend pas grand chose aux + autres. + * Oui mais non, un séminaire c'est pratique pour que tout le monde soit au + courant de ce qu'il se passe. + * Erdnaxe est chaud pour un séminaire Ansible \o/ +* mise à jours des noyaux des virtualiseurs /!\ terrain miné + * voir + + pour le problème que l'on rencontre actuellement + * On fait un test sur un virtualiseur, et on verra... +* Changement de soyouz (il existe des serveurs moins cher et mieux chez ovh) si + ça motive quelqu'un, on peut le migrer sur un nouveau serveur ovh et c'est + cool car ça fait plein de truc différent soyouz (mail, wiki2, tunnel tinc, + dns) + * c'est pas beaucoup moins + cher ni substantiellement mieux. + * On fait une tâche phab dans idée, ou todo, c'est pas urgentissime. +* réparer les certificats letsencrypt + +. passage à un certif pour *.crans.org ? + +* Pour l'instant c'est aussi une idée, pas ultra urgent. +* ajouter la gestion de la bdd mysql de zamok sur re2o ? + * c'est la bdd des pages persos. On reporte à la prochaine IN. +* régler: [Django] ERROR (EXTERNAL IP): Invalid HTTP_HOST header: 'www.hp.com'. + You may need to add 'www.hp.com' to ALLOWED_HOSTS. + * {{{['*']}}} dans ALLOWED_HOSTS ? +* voir le souci de lvm sur zbee: + +. il n'y a pas `global_filter = [ "r|/dev/zd.*|", "r|/dev/mapper/pve-.*|", +"a|/dev/mapper/mpath.*|", "a|/dev/sd.*|" ]` +. je vous laisse vérifier que le mettre en oeuvre dans /etc/lvm/lvm.conf sur +zbee ne pètera rien +A mettre dans la conf. + +### Séminaires + +Quels sont les futurs séminaires ? Allez les apprentis faites pas vos timides :p + +* Le séminaire BGP est en cours de préparation. ETA ~ 1 mois. \o/ +* Edpibu : Séminaire Switch +* Elkmaenchen : Séminaire Freeradius +* Erdnaxe : Séminaire Ansible +* Vulcain : Séminaire DHCP +* Séminaire Sécu du web dans une semaine. + +### Est-ce que je peux commiter dans BCFG ? (erdnaxe) + +Je fais une branche ? + +* Ouais go + +### Utilisation de la radio crans + +Peut-on y accéder ? + +* On a déjà décidé de le supprimer, ça n'a juste pas été encore fait. + +### On nuke le service de SMS ? + +gammu, on l'utilise ? Qui veut des SMS ? + +* L'AMAP par exemple ! une extension de la note 2018 pour commander a distance ? +* C'était un projet, mais c'est un peu en plan, si vous voulez le reprendre go + for it. + +### IPV6 + +Certain serveurs n'ont pas leur ipv6 sur certaine interface (exemple ft sur adm +je l'ai ajouté à la main) + +* dans le cas de ft on avait oublié de changer l'ip quand on est passé de HE + aux ip ripe. +* Ok, faut voir. + +### Les comptes clubs sur zamok + +* On réfléchit, on reporte à la prochaine IN, pour l'instant on laisse comme ça. + +### Monitoring + +Ce qu'on veut, ce qu'on ne veut pas, ce qui est important, ce qui peut attendre + + +* On reporte. + +### Serveur matrix + +Eh ! Eh ! On installe un serveur matrix ? + +* du calme, du calme, c'est cool, mais ça pourrait plus un truc à tester à + servens avant nan ? ;) (où ça des conflits d'intérêts ? je vois pas :p) +* Si des gens sont chaud on peut tester mais c'est pas urgent. + +### Virer association.crans.org d'Icinga et/ou le monitoring de l'imprimante + +Car toutes les règles de ces services sont cassées + +* On reporte à la prochaine IN. diff --git a/compte_rendus/2019_04_16.md b/compte_rendus/2019_04_16.md new file mode 100644 index 0000000..0db31f0 --- /dev/null +++ b/compte_rendus/2019_04_16.md @@ -0,0 +1,259 @@ +# Réunion du Collège Technique + +* Date : Mardi 16 Avril 2019 +* Lieu : Amphi Tocqueville +* Début : 19:15 +* Fin : 21:55 +* <> + +## Présents + +* Fardale (via jitsi) +* Edgar Pierre "edpibu" BURKHART +* Solal "Otthorn" NATHAN (nous quitte à 21h07) +* Romain "Vulcain" Thibert +* "erdnaxe" +* Gauthier "Elkmaennchen" CROSIO (disparu à 19h50) +* Émile Siboulet +* Arthur "Grizzly" GRISEL-DAVY +* Benjamin "Esum" GRAILLOT +* Maxime "Pollion" BOMBAR +* Michaël "Mikachu" Paulon + +## Ordre du Jour + +### Bilan des trucs mis en place et lignes directrices des futurs projets + +#### GitLab CI + +Installé +par PAC sur [[CransTechnique/LesServeurs/ServeurVulcain|vulcain]]. +PAC n'est pas là on passe ce point. + +#### Prometheus et Ansible + +Déployé par Erdnaxe et OursPolaire + +Déploiement du serveur principal sur une VM. L'installation s'est bien passée, +mais la création de VM est déjà une aventure. Mise à jour de l'iso dans +proxmox. Fardale suggérait d'utiliser +le PXE. + +Petite interlude d'explication sur +le PXE, charybde etc. + +Linkage vers la page wiki : PXE. + +Playbooks Ansible : + +* Monter LDAP sur une VM fraîche (testé et ça marche ./) +* Déploiement de Prometheus (testé et ça marche ./) +* Déploiement des nodes (pas encore testé) + +Objectif: On continue à déployer les nodes, on continue à tester, déploiement +de grafana + +{{{[digression]}}} + +Création de VM: Discussion sur un DHCP sur +adm, pour le moment on estime qu'on n'a pas besoin de ça… + +Erdnaxe propose de se documenter sur terraform () qui +permettrait de faire tout ça automagiquement. + +{{{[/digression]}}} + +Actuellement Prometheus monitore uniquement Prometheus, déploiement des nodes +ce WE, test du playbook ansible. + +Quand tout sera stable et que ça marchera bien on migrera tout ça +sur fy. (enréinstallant fy :) ) + +* Fardale: attention fy est déjà un peu charger il me semble. + +#### Mailman 3 + +Il n'y a pas grand chose à dire en fait. + +Esum a installé la VM sous Buster, elle marche. Il faut la +configurer avec Ansible. Entre temps mailman3 n'a pas encore été installé parce +que soucis sur soucis ça a donné une impossibilité de se logguer. +On poursuit dans cette direction, on déploie petit à petit. + +* Elkmaennchen et le CT Aurore intéressés + +A priori Via est en train de déployer un mailman3 aussi mais +d'après Erdnaxe ils en chient sur quelques points. Il serait +interessant de les contacter pour ne pas tomber dans les mêmes pièges. + +#### Cr@ns-5g + +Historique rapide: Depuis N mois les adhérents avec des Mac ont des soucis de +wifi (Broken pipe, instabilité wifi etc). On savait pas trop d'où ça venait, on +avait essayé plein de trucs sans succès. + +On a décidé à une dernière IN de séparer les SSID 2.4 GHz, 5 GHz. On n'a pas +trop de retours dessus, puis une mise à jour du controlleur Unifi est arrivé, +Chibrac avait dit qu'il gérait mieux la gestion 2.4/5 et a donc refusionné les +SSID. Idem, on ne sait pas trop s'il y a eu une amélioration, mais il y a ~un +mois pas mal d'adhérents sont venus dire que le Crans ne marchait plus. On a +resplitté, et à présent les adhérents avec des devices Apple (Iphones, +MacOS & co) ne parviennent plus à se connecter sur le SSID Crans (2.4 GHz) par +contre le SSID Cr@ns-5g (5 GHz) marche parfaitement. Pour le moment on ne sait +pas exactement d'où ça vient, et on se contente de ça pour l'instant. + +On fait un dashboard grafana pour afficher le nombre d'user mac sur le 2.4G +et 5G ? + +En fait il y a déjà un truc du même genre sur le contrôleur Unifi + +Mikachu : Une explication au problème qui s'est passé après +la 2^ème^ séparation des SSID, une mise à jour de MacOS est arrivée récemment +et dans les release notes ils disent avoir améliorer la gestion du Wifi. Mika +pense qu'ils utilisent une sorte de cache pour mémoriser que des réseaux font +du 5GHz, et comme Crans ne fait plus de 5 les devices Apple pourraient ne pas +vouloir s'y connecter. Who knows ? + +Erdnaxe : Aux journées Federez Erdnaxe a +rencontré d'autres assos avec exactement les mêmes symptômes et leur a +conseillé de faire comme nous. Pas de retour pour l'instant. + +Mikachu: Apparemment les soucis Mac/Unifi sont connus, Mika +rapporte d'autres cas qu'il a pu voir dans sa boîte. + +#### Micro-code et Virtualiseurs + +Fait par Fardale. + +Le microcode est un firmware tournant sur le cpu, qui peut être mis à jour via +des paquets debian. Le paquet modifie la séquence de boot pour mettre à jour le +firmware au prochain reboot. + +Pour intel les fimrwares ont été mis à jour pour alléger les fix de metldown et +spectre. + +Le microcode a été déployé sur tous les serveurs physiques, il n'attend qu'un +reboot pour être activé. +fz tourne avec le microcode mis à jour. + +Testé sur ft la migration des VM de stitch (qui n'a pas le +microcode installé + Ancien noyau) n'a pas fonctionnée (VM éteintes à +l'arrivée) alors que cela n'avait pas posé de problème lors du test +de fz (VM migrées de ft vers fz)… + +Après la catastrophe grosses lenteurs, prompt qui n'apparaît plus +etc, Fardale a dû se connecter en root, commenter la ligne dans +grub et rebooter ft. Une fois le +reboot terminé les lenteurs avaient disparu. +Esum propose de désactiver les patches contre Spectre et +Meltdown (proposé aussi sur le forum sur lequel Peb avait posté il y a un an). + +Bon dans tous les cas on va devoir attendre une grosse maintenance pour faire +ça, on pourra voir ce qu'il se passe quand on migrera vers Buster, et/ou en +Juillet-Août. + +Fardale : Sinon il est peut être interessant de passer sur un +noyau plus récent qui améliore les patch meltdown et spectre. + +### Proposition d'achat de matériel + +Il y a aussi ce petit problème de switch de la baie qu'est pas très important +mais faut quand même… + +* * 2 (ou 3 histoire d'avoir du spare et + de pouvoir le prêter à S&L) 380€ +* 90€ +* 500€ +* ou `` (moins cher et moins de + latence !)`` 50€ +* ou racheter des alims. + +On explique à tout le monde comment fonctionne la +baie, iSCSI]], zbee & co. On rappelle que le 3 Février le Switch est tombé, et +du coup ça a coupé tout le réseau. Pas cool. Actuellement c'est un Aruba 48 +ports de Spare qui est branché, on va proposer au CA quelques modèles pour +racheter un switch. + +Le CT propose ce modèle au CA : + +On propose d'en acheter 2 (pour redonder) + 1 de spare, et puis au pire un +switch 8 ports c'est toujours utile. + +On propose aussi au CA de racheter des Alims pour les switches qu'on a mais qui +ont perdu leurs alims. OursPolaire s'en occupe. + +### Projet + +Matrix a l'air de bien marcher, et toute la conf (ou presque) est déjà sous +Ansible. On en déploie un au crans ? + +Bon personne n'est vraiment chaud et puis c'est maintenir deux trucs pour pas +grand chose. On peut par contre faire de la pub pour le Matrix d'Aurore. + +Fardale : je peux déployer ça, je l'ai déjà fait sur un serveur +perso si besoin. + +### Mises à jour + +Buster arrive, Jessie-updates et Jessie-backports ont été droppés des miroirs +debian (et du coup du crans). +On termine la mise à jour des serveurs de backup ? + +Vulcain est chaud à distance on lui filera tous les droits dessus +évidemment, Esum veut bien superviser sur place. + +### knot + +Transition de knot vers bind. + +Il y a des trucs chiants avec knot, on veut les views de bind (split +horizon DNS) que knot n'implémente pas. Esum demande donc au CT (avant de +déployer). + +Erdnaxe serait aussi intéressé, on en profiterait pour déployer +la conf avec Ansible pour avancer la transition Bcfg2 vers Ansible. + +Le CT n'y voit pas d'inconvénient mais on ne veut pas de downtime. + +### Lenteurs + +Pourquoi que c'est lent le crans ? + +* Symptomes: les ssh mettent 10000 ans à aboutir, le wiki est lent… +* Causes possibles: + * Latence/soucis d'IO: comment on debug ça ? + * Savoir si le soucis vient + de zbee ou de la baie ? + * Fardale : voir les graphes munin ou les ajouter si il + n'y en a pas assez + * Problèmes de DNS (récursif ou résolution récursive sur les domaines + crans); qui expliquerait assez bien les latences (dont ssh) + * Fardale : mais ça n'explique pas les ralentissement sur + les homes + * zbee swap depuis quelque jours + * Fardale : un serveur qui swap c'est normal, après à voir + si ça a augmenté brusquement ou non. + * Les + fichiers DNS de silice échoue à se mettre à jour depuis quelques jours. + * La partition pour les mails de la baie est pleine à 99% . Fear + * La latence des disks + de silice a explosé + depuis quelques jours. C'est le cas de plusieurs VM. C'est synchronisé + avec stitch. Les autre virtu ont pas ce comportement. + * + +### Routage + +Bon en fait on a des soucis de routage v4… On a des boucles sur le réseau… + +Va falloir investiguer… + +Esum et Mikachu veulent reprendre le routage et le +parefeu. Fardale aussi est motivé pour aider sur ça. + +### Gâteau + +Erdnaxe a accepté de devenir Nounou et a apporté des +biscuits (). + +Bravo à lui ! diff --git a/compte_rendus/2019_06_04.md b/compte_rendus/2019_06_04.md new file mode 100644 index 0000000..d69032e --- /dev/null +++ b/compte_rendus/2019_06_04.md @@ -0,0 +1,328 @@ +# Réunion du Collège Technique + +* Date : Mardi 04 Juin 2019 +* Début : 19h52 +* Fin : 21h57 +* Lieu : 2B +* <> + +## Présents + +* Esum +* Mikachu +* Erdnaxe +* Vulcain +* Pollion +* 20-100 +* Solal +* Raida +* PAC + +## Ordre du Jour + +### Liste de tête des choses à faire + +* Pare-feu +* IP Zayo +* Soyouz2 +* Routage +* Baie + +### Maintenance baie + +Il faut changer le switch temporaire de la baie de disques par les petits +switchs qu'on a achetés +Il faudrait essayer d'avoir le maximum de gens pour le faire, ce serait +formateur d'avoir des gens et de faire des choses en même temps + +On la fait quand ? En juillet ? + +Pollion est dispo à partir de début juillet (genre >= 5 Juillet) + +Quid des mails ? +solution temporaire de esum: virer les % réservés à root dans la +partition /var/mail (qu'on devrait virer partout, ça sert ~à rien sur des +partitions où root a pas à écrire) +solution à long terme: agrandir la partition lors de la maintenance de la baie + +### Apparté RENATER + +Ça a coupé, on a été avertis, les gens se demandent qui sont sur la ML +DSI-Cr@ns. Il s'avère que c'est plein de gens random dont des dinosaures. Oups, +on rajoute le bureau. + +### soyouz2 + +Quand est-ce que les apprentis sont dispo ? Ce serait bien de l'installer avant +cet été. +Je suis libre dans la semaine +Vulcain, Raida, Benjamin sont chauds pour l'installer et tout déployer avec +Ansible. + +### Mettre à jour les serveurs de backup + +{{{omnomnom}}} et {{{zephyr}}} +ASAP, Pollion et Vulcain s'en occupe après ses oraux sauf si vous voulez vous +en charger avant. + +### Titanic + +Achevez le. Il est à l'agonie et le rapelle un peu de temps en temps, le pont +il fait des choses cheloues. +Est-ce qu'il faudrait pas le réinstaller ? Si on le fait, il faudrait le faire +en même temps que soyouz2. + +Pollion explique ce que fait titanic : il fait passer un minimum vital via la +Freebox. Mais cette feature a été laissée tombée il y a longtemps, ça n'est pas +vraiment utile. +Le gros intérêt est pour les membres actifs de rentrer sur le campus via la +freebox quand les autres routes (Renater, Zayo) tombent. + +Une nouvelle VM a été créée pour que les apprentis jouent avec, et tentent une +installation en coordination avec soyouz2 (= Spoutnik). Ce serveur s'appelle +Boeing. + +### Cableuse + +Pas grand chose à dire à part qu'elle marche et que on va sûrement la mettre à +la Kfet avec Windows 10 / Ubuntu 18.04 en dual boot (Erdnaxe : "Je voulais +brûler Windows avec /dev/null mais on m'a convaincu que des câbleurs en aurait +besoin et puis on a une licence") +Elle fait beaucoup de bruit, quasiment autant que le bruit ambiant Kfet d'un +jour calme. Si les gens l'utilisent beaucoup, il faudra ptetre investir dans un +vrai ventilo >8€. + +Erdnaxe il a tout réparé, Erdnaxe il est trop bien, on aime Erdnaxe. +Elle est à disposition des câbleurs. + +### Prometheus et fy + +Monitoring des bornes et des switchs, notamment. + +Besoin d'un coup de main sur les MIBs SNMP mais sinon avec un peu de temps tout +y sera. +Est-ce que l'on formatte fy à terme sur buster avec Prometheus ? +1 pour le +formatage une fois qu'on a une POC de Prometheus qui fait bien tout ce qu'on +veut :) + +Et on reinstalle quoi dessus ? Que prometheus. +Le souci du stockage qui grossit à l'infini a été résolu ? A priori, avec +prometheus 2 (donc sous buster), c'est mieux géré, il droppe ce qui est plus +vieux que $jours (mais il ne sait pas faire de downsampling (= sur les données +plus anciennes, ne garder que des tendances et pas toutes les données) +Est-ce qu'on peut avoir des mails plus utiles ? Changer le template HTML des +mails ferait qu'on divergerait d'une install classique. Essayer de les passer +en raw text ? + +> envoyer le monitoring sur un channel IRC, plutôt ? Du coup erdnaxe fera un +chan #monitoring accessible pour tout le monde (munin l'est, grafana aussi). +Éviter d'y discuter +Ça en est où niveau parité d'utilisation avec les solutions éxistantes ? + +* A priori, tout ce que fait munin, prometeus sait le faire. Sauf l'historique. + +Est-ce qu'on a une page alerte comme dans munin ? + +On peut avoir le CAS pour se loguer sur grafana ? Ce serait cool parceque ça +permet de faire du Single Sign On, grafana le supporte par le proxy. + +On peut peut-être continuer à garder Munin s'il fait du downsampling, et que +les vieux s'en servent ça peut aider à proposer un diagnostic non ? + +### Knot + +Il y a eu des soucis avec Knot depuis qu'il a été mis en place, et il +semblerait que certaines feature de Bind ne soient pas supportées correctement. + +Proposition : Revenir à Bind. Des gens sont motivés pour le faire, donc +pourquoi pas. On fera ça dans l'été, il n'y a pas urgence. + +### RFC2136 avec knot/bind + +On pourrait utiliser certbot en wildcard avec cette RFC. +On pourrait réécrire le service re2o DNS pour utiliser cette RFC. +On pourrait drop le service re2o DNS et laisser le serveur DHCP remplir le DNS +quand un client se connecte avec cette RFC. +On pourrait expérimenter des choses fun quoi... avec cette RFC. + +Marrant, mais pas urgent. On le rajoute dans la file d'attente mais avec une +priority low +On envoie un mail. + +Mika met en garde, on peut perdre des trucs au reboot, faut voir. + +### Mailman 3 + +Faut motiver qqun dessus mais c'est critique et stressant. +Pendant l'été +TOUT PENDANT L'ETE ! +On peut faire plein de choses pendant l'été. + +### Proxmox et le stockage + +Est-ce qu'on essaie de faire un truc plus propre ? pourquoi s'embeter avec du +LVM et pas faire gentiment du qcow2 ? +(proposition: on exporte la baie en iscsi et on fait juste des disques +qcow2 dedans, pas besoin de lvm, pas besoin de quoi que ce soit de relou...) + +> Erdnaxe : ça semble + maintenable que la solution actuelle donc je suis pour. + +Attention à ne pas mettre trop de trucs en place en même temps tout de même. +Chaque chose en son temps. + +Voir le tableau des stockages supportés +ici : + +Certains types de stockage ont été testés sur la baie de Servens, comme prétest +avant le Crans. Cours résumé ici : + +Qu'est-ce qui a été testé à servens ? +ZFS over iSCSI +ZFS puis export en NFS de pools zfs +ZFS puis export en iscsi de volumes lvm dans la pool + +Question : Pourquoi ne pas faire directement du iSCSI + +* Parcequ'on avait envie de s'amuser avec ZFS + +Erdnaxe propose du Ceph en achetant du stockage, mais c'est plutot une solution +pour Aurore ça… +Mikachu précise que bien que Ceph semble interessant, c'est seulement dans le +cas où il y a plusieurs serveurs de stockage, et accessoirement avec une baie +comme la notre, il faut mettre un serveur en plus si on veut faire plus que +juste exporter en iscsi + +Erdnaxe répond qu'on pourrait mettre des disques dans chaque virtu et faire du +ceph dessus (l'idée est de garder la baie que pour les mails/homes) + +Mikachu : Euh ça semble relou/20, ça veut dire que la mort d'un virtu implique +aussi la mort d'une partie de ton stockage, mais ça peut se faire, je sais +qu'en général les gens aiment bien séparer le compute (des hyperviseurs avec +peu de disque et beaucoup de cpu/ram) et le storage (des baies avec plein de +disques (et des ssd potentiellement pour faire du cache) et pas beaucoup de +cpu/ram) +oh ok :) + +On coupe court à cette discussion : Ça ne sert pas à grand chose dans ces +conditions. Il vaut mieux faire un thread sur la ML nounou@ pour que les gens +aient le temps de regarder pour donner leur avis. + +Lien vers l'issue phabricator : + +### Runner gitlab + +Ça en est ou ? Ça semble tourner sur {{{vulcain}}} mais on n'en fait pas la +pub. Est-ce que le souci d'espace disque a été résolu ? +Il suffit de pull une deuxième image LaTeX différente pour saturer la CI. +Normalement la ci est censée faire le ménage dans les images peu utilisées mais +c'est pas trop le cas. +Après je trouve que l'on a été radin sur l'espace disque ici. +Solution : +Augmenter un peu le /var/docker +Mettre un cron qui `docker image prune` régulièrement. Erdnaxe propose de +chercher ce que fait Gitlab, car pour le moment il crashe quand ça sature +plutôt que de nettoyer. + +### Migration des serveurs sur les ip RIPE + +Un certain nombre de serveurs sont encore sur le / d'ip de l'ENS. Ça serait +bien de tout passer sur les IP Crans +sur 185.230.79.0/24 (voir [l'issue +phabricator](https://phabricator.crans.org/T323)), vlan qui a été nommé DMZ +l'an dernier. + +On rappelle ce qu'est une DMZ : Il s'agit plus d'un sous-réseau séparé du +réseau local. On y met les machines qui doivent être accessibles depuis +Internet, mais qui sont susceptibles d'être attaquées, et n'ont pas besoin +d'avoir un pied sur le réseau local. + +Actuellement Adm est le contraire d'une DMZ : Il s'agit d'un VLAN +d'administration sur lequel on a mis tous les serveurs crans. Les ip derrière +ADM ne sont pas accessibles depuis Internet. + +A-t-on vraiment envie de faire une DMZ ? + +### Mise en avant des services crans et statistique d'utilisation + +On a plein de service cool mais souvent aucune pub n'est faite pour et on ne +sait pas ce que les gens utilisent ou pas. Ça serait cool de regarder pour +faire des stats sur ça réfléchir à la mise en avant de service. Du maintien ou +non de service (coucou les news) + +Erdnaxe dit que pour la plupart des services on peut facilement exporter +l'utilisation s'ils sont derrière un nginx (prometheus). + +Réponse : Alors non ça ne fait pas tout, mais ça sera déjà un début, par +exemple tu peux vouloir avoir le nombre de pad créé et ça je ne pense pas que +le fait qu'il soit derrière nginx t'aide. + +Erdnaxe : Gitlab exporte de base en prometheus, django a un module pour + +esum rappelle aussi que l'on peut faire des livrets +On envoie ce problème au CA + +### Séminaires à la rentrée + +Git le retour , Django, howtobasic du Crans (PAC, qui n'as pas encore choisi) + +> Django Contrib (erdnaxe) mais ptetre trop avancé pour un premier séminaire +il faut commencer par python puis django peut être + +Pour la rentrée il vaut mieux des séminaires faciles : Introduction à Linux, +shell, ssh, comment marche le crans, internet c'est magique ? Le !BaBa de la +sécurité & co. Python basique ça rentre dans les séminaires de rentrée oui. +Après vu que Pac part en germanie on peut aussi faire d'autre types de +séminaires + +### Ansible + +On fait le bilan d'Ansible. Ce qui a déjà été fait, quelle est la prochaine +étape. + +Erdnaxe, avec l'aide d'autres membres du CT, a mis en place un certain nombre +de playbooks Ansible. L'objectif à court terme est de remplacer BCFG2 qui +viellit un peu. + +Actuellement c'est toujours plus ou moins en phase de test, et seuls les +serveurs les plus récents ont été mis en place avec Ansible. Peu de gens sont +formés pour l'instant. + +On propose d'avancer durant l'été dessus, ça serait cool de faire une +transition depuis BCFG2. + +### Le portail captif + +Le portail captif fonctionne au Villon. + +### Le Wifi + +Chirac a mis à jour les bornes et ça a cassé le wifi. + +Bilan : + +* Le SNMP ne marche toujours pas dans les nouvelles versions du coup monitoring + is not coming ! +* Le Wifi a violemment diminué de portée. +* Il faut bidouiller pour pouvoir se reconnecter. + +On rappelle aux nounous que c'est bien de faire des tests avant de mettre à +jour des services assez critiques comme les bornes. Surtout quand une simple +recherche sur la mise à jour indique une forte instabilité. Pour les bornes par +exemple, celle du 2b est entre autre là pour ça. Par ailleurs, il faut vérifier +que tout fonctionne correctement après la mise à jour. + +On rappelle aussi qu'il faut arrêter de rager dès que quelqu'un fait quelque +chose qui casse un truc ; ça peut arriver. On rappelle (encore une fois) aux +gens qui ont l'habitude de casser des trucs qu'il faut se coordonner avec le +reste de l'équipe technique et ne pas tout faire seul dans son coin. Personne +n'est infaillible. + +On va donc downgrade vers une mise à jour stable pour récupérer un meilleur +wifi. + +### Commission achat Crans - AURORE + +Le CT doit désigner 2 membres pour le représenter à la commission achat +crans-AURORE. + +Ce sera Mikachu et Erdnaxe diff --git a/compte_rendus/2019_09_30.md b/compte_rendus/2019_09_30.md new file mode 100644 index 0000000..1fbf157 --- /dev/null +++ b/compte_rendus/2019_09_30.md @@ -0,0 +1,468 @@ +# Réunion du Collège Technique + +* Date : 30 Septembre 2019 +* Début : 19h +* Fin : 21h25 +* Lieu : Salle de conf du PDJ +* <> + +## Présents + +* Mikachu +* Krokmou +* Erdnaxe +* Pollion +* Esum +* Vulcain +* Elkmaennchen + +### Des gentils première année + +* h@chi.no +* !TinyLinux +* Aka +* Charles +* Batablu +* Tinette +* Armand2 + +## Manger + +Sarcozy se propose de nous ramener des pâtes de la soirée C4, donc on accepte +et on commande des pâtes. + +## Ordre du Jour + +On commence par faire un bilan des derniers événements + +## Incidents et autres interruptions de services + +### Crash de thot le 21 Juillet 2019 + +Pollion a tenté un changement de disque dur de Thot. À cause de l'agencement +non protestant des disques (RAID logiciel sur 4 RAID0 gérés par une carte +propriétaire HP) thot a crashé. On l'a réinstallé. +Mais pas trop le choix sur les Gen7-, on a gardé un truc de vieux sur les +Gen8+ alors que le mode HBA sur une carte Raid HP aurait pu éviter ça. +Le Raid logiciel c'est coool et je suis de l'avis que Raid bien fait +logiciel > Raid matériel « boîte noir déconnante » + +Pour plus d'informations, allez +lire : + +On manque de compétences sur ces sujets, mais aller tester à ServENS est une +bonne idée et c'est ce que Pollion a fait ! + +Faire un séminaire sur le stockage ? RAID, ZFS, NFS, iSCSI ... ? -- Mikachu, +qui se propose pour le faire un jour ==> Cool. + +### Tocardise de Pollion + +En bossant sur les radius, Pollion n'est apperçu qu'Odlyd n'était pas du tout +dans la conf des switches. Il a donc décidé de le rajouter. Pour ça il a voulu +utiliser le script re2o de provisionning des switches. + +Après une rapide discussion sur la non documentation de ce script, il a essayé +de le modifier pour le rendre plus fonctionnel, avec un menu d'aide et +notamment un dry-run. Bon, il avait une erreur dans son script et il s'est +planté, il a lancé le provisionning en mode normal au lieu de dry-run. Résultat +des courses, il y a eu une petite confusion sur les conf des switches du +batiment M. En voulant réparer son erreur, il s'est rendu compte que plein de +switches étaient mal enregistrés dans la BDD (un arping ne donnait pas la bonne +MAC, donc soit c'était un problème de switch mal enregistrés, soit c'était une +permutation de conf). Dans le doute, il faut prendre la pire situation, donc il +s'est tappé une visite de la plupart des locaux techniques avec un cable série +pour vérifier ça à 2h du mat.... Ça lui apprendra. +En plus, les switches du RU n'ont pas réussi à reboot tout seul, mais comme +c'était les vacances le RU était fermé. C'est réglé. +Faudrait monitorer les switches (erdnaxe ?). + +### Inondation du -1I --> Coupure + +On ne pouvait pas faire grand chose. L'eau chaude du I, J, H était aussi down. +Je pense que les gens sont plus intéressés par l'eau chaude que internet (enfin +quoique...). + +### Maintenance d'Août 2019 + +On a profité qu'il n'y ait plus d'électricité pendant un après-midi. On avait +prévenu les adhérents via un mailall. + +Ce qui était prévu : + +* Changement du Switch de la baie +* Agrandissement de {{{/var/mail}}} +* Fin de la migration vers le subnet 185.230.76.0/22 (à nous, pas à l'ENS) + +vulcain à croisé la DSI et chez eux c'est la guerre : +/!\ ON PERD NOS IP LE 15 OCTOBRE. AAAAAAAH !!!! DE TOUTES FACONS DEBUT NOVEMBRE +YA PLUS DIPV4 !!!! C'EST LA FIN DU MMONDE !!!!! AAAAAAHHHHHHHHAAAAAAHHHHH !!!! + +* Mise à jour de la baie +* Mise à jour du bios des virtualiseurs +* Mise à jour du backbone + +Ce qui a été fait : + +* Changement du Switch de la baie +* Agrandissement de {{{/var/mail}}} +* Mise à jour de la baie --> IMPOSSIBLE +* Vérification des failovers, radius, postgresql (qui n'avait pas sa partition + montée lol)... + +`>> On n'a pas réparé le soucis avec le routage des IPv4 publiques Cr@ns. <<` + +> Faut trouver une solution et réparer. + +Pour les détails, voir le paragraphe suivant (quelle cohérence \o/) + +## Retour sur les décisions de la dernière IN + +[dernière IN](./2019_06_04.md) + +On va annoncer les points dans le même ordre + +## Maintenance baie + +Le switch a été changé. + +## Quid des mails ? + +On a agrandi `/var/mail/` et on a viré les % réservés à root dans cette +partition. + +On attribue un coeur en plus à redisdead pour qu'il arrête de crier à chaque +fois qu'il fait une compression ? + +Je doute que ça règle le soucis, il va jsute prendre 100% de 2cpu +pendant ~2fois moins longtemps +On limite les performances dispo pour le process ? +On rallonge le temps passé à 100% avant de lancer une alerte ? -> pas con (oui +je sais o:) :D) + + -> ça représente ~5min + +erdnaxe vient de monter l'alerte à >10mn. On passe à 15mn si ça ne suffit pas. +On le met dans Ansible. + +## Sputnik (Soyouz2) + +erdnaxe n'a pas trop envie d'être seul devant Soyouz2, en vrai le minimum +syndical a été installé. Il faut maintenant tout migrer. +En réalité le taf à faire ici correspond à une migration BCFG2 -> Ansible. + +C'est un projet parfait pour un apprenti : +et des apprentis sont motivés, c'est cool --> Hachino, TinyLinux, Batablu (si +d'autres apprentis sont motivés, feel free to join !) + +erdnaxe par contre est ultra volontaire pour former des codeurs Ansible et +relire des MR. + +En parlant de wiki on nous signale des soucis, Hachino dit que de façon très +bizarre, il lui arrive de changer de theme, erdnaxe dit qu'il a déjà eu le +soucis, on ira regarder. + +## Mettre à jour les serveurs de backup + +`omnomnom` et `zephyr` ont enfin été migrés sous Stretch par Vulcain, +encadré par Pollion. Et ce, avant la release de Buster eheh. +et les webnews ? Nope. + +## Titanic + +Il y avait un gros soucis avec le DNS, problèmes de permissions and co. Le DNS +était à genoux sur tous les serveurs, les zones ne se généraient plus depuis +des mois. Ça cassait DNSSec mais puisque personne ne valide ça n'embêtait +personne, et vu que Silice et Soyouz sont surdimensionnés, ils n'avaient pas le +problème de perf. Pollion a corrigé tout ça, Titanic n'est plus du tout à +genoux, et DNSSec marche \o/ + +## Boeing + +Pour remplacer titanic, c'est en pratique la même tache que Soyouz2. + +## Prometheus et fy + +Actuellement les problèmes de monitoring sont envoyés sur un chan irc +idoine[^ça veut dire quoi ?] : #monitoring. + +LE MONITORING EST CLEAN ! et ouaip le crans n'a jamais aussi été propre (On +parle bien d'un bot d'esum fait tourner de son côté qui est utilisé pour plein +d'autre truc et non documenté ?) + +Le monitoring des bornes a bien été mis en place. Ça a pas mal spammé quand le +controlleur a été coupé un moment pendant les vacances mais c'est revenu à la +normale. On continue le monitoring à fond cette année. Des volontaires ? + + + +Problème de la persistance sur 25jours. Censé être trivial à fix +dans {{{/etc/default/prometheus}}}, mais erdnaxe est un tocard et à fail la +dernière fois qu'il a tenté de changer ça (j'ai ptetre juste oublié de restart +le service avec la fatigue) +Niveau espace disque la VM risque d'etre limite pour contenir 1an, mais l'algo +de compression a des surprises et il se pourrait que ça marche au final. Il +faudrait récupérer moins d'info inutiles en SNMP pour nettoyer la bdd +prometheus. + +Grafana utilise le CAS ? +Non mais il faudrait. Il faut définir dans NGINX le fait d'aller chercher le +CAS et de passer le nom d'utilisateur en variable. + +Réinstallation de fy ? +On backup quoi ? munin +On réinstalle juste prometheus ? + +Ok pour la réinstallation, on backup munin je pense que ça suffit. + +QUESTION IMPORTANTE POUR FAIRE AVANCER/MOTIVER ERDNAXE : +Prometheus et les serveurs sous Stretch => est-ce que l'on prend le paquet de +backport qui monitore en plus Systemd et APT (et donc qui remplace monit et +munin entièrement de ce que j'ai vu) ? + +> It's a go. + +Dans le dernier épisode : + +Est-ce que l'on formatte fy à terme sur buster avec Prometheus ? +1 pour le +formatage une fois qu'on a une POC de Prometheus qui fait bien tout ce qu'on +veut :) +On va tester le downslampling sur la vm et quand tout marchera bien, fy fera du +monitoring. + +Et on reinstalle quoi dessus ? Que prometheus. +Le souci du stockage qui grossit à l'infini a été résolu ? A priori, avec +prometheus 2 (donc sous buster), c'est mieux géré, il droppe ce qui est plus +vieux que $jours (mais il ne sait pas faire de downsampling (= sur les données +plus anciennes, ne garder que des tendances et pas toutes les données) + +On peut peut-être continuer à garder Munin s'il fait du downsampling, et que +les vieux s'en servent ça peut aider à proposer un diagnostic non ? + +Bah, du graphage sans historique, c'est pas très utile, parce que ça permet pas +de répondre aux questions du type +"Ce disque s'est rempli, mais est-ce que c'est symptomatique d'un +problème (=> le régler; virer le garbage généré), ou une inflation normale +résultant d'une tendance globale longue durée et on vient seulement d'atteindre +la barre (=> agrandir le disque) ?" +Historique sans downsampling, c'est mieux que pas d'historique du tout (on n'a +pas besoin de garder les précisions sur la durée), mais ça va vite poser des +problèmes d'espace disque et de perf pour tracer les graphes (si je te demande +de tracer le graphe sur 1 an et que tu dois compiler 1 data/min sur un an, tu +vas en chier). +Donc bah sans solution correcte à tout ça, jeter munin me paraît +dangereux. -> prometheus ne renvoie pas tout heuresement +D'un autre côté, au fur et à mesure que vous renouvelez certains morceaux de +l'infrastructure, si vous les ajoutez pas à munin, il finira effectivement par +ne plus remplir son purpose. + +Conclusion : On fait par ordre de priorité : Downsampling avec +Prometheus > Couper les munin nodes > Formattage de fy et reinstallation. + +## Knot + +Résumé du dernier épisode : + +Il y a eu des soucis avec Knot depuis qu'il a été mis en place, et il +semblerait que certaines feature de Bind ne soient pas supportées correctement. +Proposition : Revenir à Bind. Des gens sont motivés pour le faire, donc +pourquoi pas. On fera ça dans l'été, il n'y a pas urgence. + +> On n'a pas eu le temps de le faire pendant l'été, il faudra toucher le +service et du ansible.... + +## RFC2136 avec knot/bind + +Résumé du dernier épisode : + +On pourrait utiliser certbot en wildcard avec cette RFC. +0+On pourrait réécrire le service re2o DNS pour utiliser cette RFC. +On pourrait drop le service re2o DNS et laisser le serveur DHCP remplir le DNS +quand un client se connecte avec cette RFC. +On pourrait expérimenter des choses fun quoi... avec cette RFC. + +Marrant, mais pas urgent. On le rajoute dans la file d'attente mais avec une +priority low +On envoie un mail. + +Mika met en garde, on peut perdre des trucs au reboot, faut voir. + +On en rediscute, car on a envie de faire un certificat wildcard. + +## Mailman 3 + +LOL ! + +Résumé du dernier épisode : +Faut motiver qqun dessus mais c'est critique et stressant. +Pendant l'été +TOUT PENDANT L'ETE ! +On peut faire plein de choses pendant l'été. + +--> On a présenté mailman aux 1A, mais la migration n'est pas une priorité, on + ne s'est pas attardé dessus. + +## Migration des serveurs sur les ip RIPE + +Parler de la maintenance d'Août. + +Résumé du dernier épisode : + +Un certain nombre de serveurs sont encore sur le / d'ip de l'ENS. Ça serait +bien de tout passer sur les IP Crans +sur 185.230.79.0/24 (voir [l'issue +phabricator](https://phabricator.crans.org/T323)), vlan qui a été nommé DMZ +l'an dernier. + +On rappelle ce qu'est une DMZ : Il s'agit plus d'un sous-réseau séparé du +réseau local. On y met les machines qui doivent être accessibles depuis +Internet, mais qui sont susceptibles d'être attaquées, et n'ont pas besoin +d'avoir un pied sur le réseau local. + +Actuellement Adm est le contraire d'une DMZ : Il s'agit d'un VLAN +d'administration sur lequel on a mis tous les serveurs crans. Les ip derrière +ADM ne sont pas accessibles depuis Internet. + +A-t-on vraiment envie de faire une DMZ ? + +On a migré en srv. + +############################################################################### + +Cool on a donc bien avancé. + +############################################################################### + +## Lutim + +Projet d'apprenti fait par Vulcain, encadré principalement par esum. +C'est un pastebin pour des images, c'est cool ; un nouveau service. + +Vulcain a mis en place un nouveau service. +Ça a l'air de bien marcher. On peut faire de la pub sur la page d'accueil de +l'intranet. + +## Services framadate + +Projets d'apprentis, apparemment frama ferme des projets, ça peut etre +pertinent de lancer un apprenti sur un projet des services frama qui +ferment. À voir. + +## Les backups + +Lien avec le crash de Thot susmensionné, les backups des bdd étaient mal faits, +Pollion a mis en place un réplicat postgres en RO sur Odlyd. C'est déjà mieux. + +Chiffrement des backups : Ça n'a toujours pas été fait, mais ça peut se faire +soon. Fardale toujours intéressé pour aider même si ça fait ~1an et demi qu'il +en parle ? +(Fardale a mis en place un serveur chiffré récement donc a à nouveau charger +les données en mémoire, ça ne durera pas éternellement) + +## Carte Raid sur thot, ou comment changer un disque ? + +Erdnaxe a expliqué rapidement son idée de HBA : +Il existe une méthode pour pouvoir passer outre la carte raid et envoyer +directement les disques au noyau +linux () +accessible via une mise à jour du bios à partir des HP Gen8, donc accessible +pour thot. + +On a encore un serveur de test, on va essayer de mettre ça en place et on +envisage une nouvelle install de thot sous ce mode si ça marche bien. + +## DHCP + +Lors de la migration vers re2o, le serveur DHCP primary a été passé +sur odlyd alors que le secondary a été passé sur la vm dhcp. +La personne qui a fait ça est "Votre Nom " cf commit +dece79374f94b64c3a79dfd9e8c54d03e3afb936 sur BCFG2. Anyway, qu'est-ce qu'on +fait ? On change ? + +On décide de revert et de changer. + +Dans tous les cas, penser à changer la page wiki + + +## Ansible + +Il faut continuer, on fera une IN spécial Ansible pour lister tout ce qu'on +doit faire avec. + +Il existe un serveur qui est sous buster et non sous ansible. + +## Les disques cassés dans le 0b + +Quid du disque orange de la baie ? --> On les rachete, pour la baie pas de +soucis pour changer, pour gulp ça va être probablement le même soucis que pour +thot. On annoncera une petite interruption de services et on passera sous +Buster à la toussaint. + +## Séminaires édition 2019-2020 + +« Wow » beaucoup de jeunes au premier séminaire (salle de conf du Pavillon des +jard rempli au 3/4). +L'ambiance est VRAIMENT cool, y a parfois à manger en plus. +faut continuer comme ça et faire son max pour faire vivre les +séminaires ! C'est pas si difficile de faire venir des gens et faire de la pub +si on s'y prend à beaucoup. +C'est une des grandes forces du Cr@ns et c'est qqch qui continuera d'exister +après le déménagement donc autant mettre l'énergie ici. Et c'est aussi un peu +le coeur de l'assos : + +```LaTeX +$$ \frac{\mathrm d \text{séminaires}}{\mathrm d t} > 0 \implies \frac{\mathrm +d \text{gens compétants}}{\mathrm d t} > 0 \implies \frac{\mathrm d \text{vie +de l'assos}}{\mathrm d t} > 0 $$ +```` + +## SATIE + Crans + +PAC et erdnaxe ont vu deux personnes du SATIE. Après long étallement de cahier +des charges d'un projet qu'ils veulent organiser, il semblerait qu'un +Matrix (non fédéré) + !EtherPad leur convient parfaitement. +On est en train d'installer une instance de test pour leur faire tester. +Deadlines ? +Ça peut être un chouette début de projet, ils ont clairement pas le même +background en info que nous et du coup ils n'imaginent pas forcément qu'une +solution à un de leur besoin existe. +On peut leur apporter des solutions qui (on l'espère) vont ptetre beaucoup les +aider. +Il faudrait faire idem dans LURPA / LMT... + +On peut avoir le cahier des charges ? Ils devront adhérents au Crans ? Qui +finance ? (Les adhérents n'ont pas à financer un projet pour des non +adhérents + si le crans perd la gestion de la connection il lui faudra d'autre +source de revenu) + +On laisse au CA + +## KWEI + +On a ouvert le portail captif au KWEI, allez voir le monitoring si vous voulez +voir l'utilisation. +Ok, ça marchait, on remettra ça pour l'install Party. C'est la nouvelle version +de fête du slip. En plus c'est monitoré. +Erdnaxe va documenter tout ça :) ! + +## NGINX qui reverse Apache cassait des choses + +!PhpMyAdmin pleurait et Wordpress redirigeait à l'infini car Apache se croyait +en HTTP à cause du reverse proxy NGINX. +Solution ! On dit à NGINX d'ajouter un header pour dire à son poto Apache qu'il +est en HTTPS. +Et ça marche ! Son&Lumens ont enfin leur Wordpress fonctionnel, erdnaxe pense +également en parler au BDS (ils souhaitaient déménager leur wordpress à une +époque). + +## Module NGINX de certbot + +Bah en fait avec ça un certif wildcard ce n'est plus si pertinent... +Genre vraiment `certbot renew --nginx` c'est la folie. +Est-ce que l'on passe dessus à la place du module standalone/webroot ? + +Le mieux c'est de faire du wildcard, donc on reste comme ça. + +## Fin de l'IN + +Bon, Sarcozy n'est pas venu avec les pâtes donc on a faim... diff --git a/compte_rendus/2019_10_21.md b/compte_rendus/2019_10_21.md new file mode 100644 index 0000000..5f3ec88 --- /dev/null +++ b/compte_rendus/2019_10_21.md @@ -0,0 +1,225 @@ +# Réunion du Collège Technique + +* Date : 21 octobre 2019 +* Début : 19:11 +* Fin : 21h04 +* Lieu : Salle de conférence du Pavillon des Jardins +* <> +* Jitsi : + +Présents: + +* Solal +* Charlie +* Edpibu +* Elkmaenchen +* Hachino +* TinyLinux +* 2 1A (Déso j'ai oublié vos noms). +* Mikachu +* Vulcain +* Erdnaxe +* Pollion +* Thybal + +## Bilan réunion avec la DSI + + + +La fibre vers le G passe par l'ENS : Une fibre entre le B et l'autocom, une +jarretière fibre, et la fibre repart vers le G. +L'ENS doit vider tous les bâtiments d'ici fin avril, a priori y compris +l'autocom. Il va falloir trouver une solution pour le bâtiment G. +Ce qu'ils veulent faire c'est tirer une fibre entre l'arrivée de RENATER et le +bâtiment De Vinci. +Ils ont eu une réunion avec un presta pour tirer cette fibre, et +ont /normalement/ proposé de rerouter notre fibre vers le De Vinci. +Ce n'est pas encore clair qui va payer, on verra plus tard (avant de faire des +travaux évidemment). + +Fardale s'interroge du bien fondé de tout ceci : On a notre contrat fibre +jusqu'à la fin du premier trimestre 2021. Donc jusqu'à ce moment on paye la +fibre. Pour l'instant on a envie de continuer à fournir le Crans, y compris au +G (et pourquoi pas De Vinci). + +Quoi qu'il arrive, on veut garder internet au G. + +Plusieurs solutions : + +* Soit on fait un pont radio +* Soit on tire une fibre dans les souterrains. + +La DSI est très intéressée par continuer à bosser avec nous, y compris sur +Saclay (Pas encore défini); ils nous ont proposé une demi baie sur Saclay. + +Ils ont proposé de nous faire rejoindre les discussions d'un comité "Métier" en +cours de création. + +Autre point : Démontage du matos de la DSI. Fin Avril, tout doit être vide, en +particulier les bornes, switches, serveurs etc .... Et nous proposent de +récupérer pas mal de matos (y compris les switches top of rack de la mort qui +tue ou les serveurs Dell pas trop vieux et qui ne ressemblent pas à une +étagère.) + +Ils nous ont proposé qu'on aille démonter le matos, ils vont voir avec la DAI +pour nous filer certains accès. + +L'idée c'est pas forcément de garder ces bornes mais de les refiler à d'autres +asso (Aurore, et autre ...) + +Charlie : Le don de matos a été promis par la DSI ou validé par la +DGS ? --> Pour l'instant ça a juste été évoqué par la DSI, mais ils veulent se +charger de voir tous les services (DGS, DAI etc ...) et reviennent vers nous. + +Vulcain : A priori ceci a été évoqué par Mazé devant Tavernier et ils avaient +l'air chauds --> ça leur évite de signer des chèques à moult presta. + +Migration des IP : On se fixe en objectif de finir tout ça avant la fin de +l'année (Civile) +On a commencé à faire des migrations à la va vite car on a commencé à perdre +nos routes par l'ENS le 15 Octobre, date qui avait été évoquée dans un couloir +par la DSI à vulcain (voir le CR de la dernière IN.) + +## Bilan Install Party + +### Le réseau + +On a eu un léger soucis de réseau : On avait demandé à la DSI s'ils pouvaient +brasser toutes les prises du PDJ avec nos VLANs. Résultat, on a perdu les deux +seules qui marchaient .... +On a tout de même pu s'en sortir avec le wifi. + +~13 interfaces enregistrés pendant l'IP (sans compter ceux qui était déjà au +Kwei) +16 utilisateurs, 24 machines (IP + Kwei) +Le portail captif a super bien marché, mais Mikachu a fait la remarque qu'une +attaqueIPoverDNS était possible puisque ça n'avait pas été envisagé. On a +testé, ça marche. + +### Portail Captif + +Faudrait un projet d'apprenti qui reprenne le portail captif (déjà bien nettoyé +récemment) avec : + +* nftables pour remplacer iptables et ipset +* laisser passer que le 80, 443 et 53 vers la VM quand l'utilisateur n'est pas + register +* mettre en place un bind9 débile avec juste une règle /#/IP LOCALE + +Ça sera l'occasion de revoir le portail captif d'auto enregistrement en filaire +afin d'unifier tout ça. + +Erdnaxe se propose pour encadrer cette tâche. + +On va faire une tâche phabricator <>. + +### Installations + +Erdnaxe évoque l'idée +d'utiliser [netboot.xyz](https://github.com/antonym/netboot.xyz). Il avait +essayé mais avait eu des problèmes. C'était potentiellement un soucis de MTU. +De toute façon, On n'a pas envie de contacter l'extérieur ... + +## Bilan Séminaires + +Séminaires faits : Introduction au Crans, Shell, Python basique. Ça s'est bien +passé, et les gens en redemandent ! +On a envoyé notre liste de séminaire à !ViaRézo, eux nous ont envoyé les leurs. +Ils veulent juste que l'on ne les spamme pas trop d'apprenti (genre moins +de 50), a priori ça passera. + +Prochain séminaire sera sur le réseau basique et le routage ! + +## Pages persos + +phpMyAdmin a été remis au crans. On va probablement remettre en place une appli +page perso. + +--> Projet apprenti + +## Conf Apache de Zamok + +Install-party.crans.org a été migré vers club-crans. + +## Point Interfaces + +Depuis Stretch les interfaces sont nommées à partir de leur emplacement +physique, on a envie de normaliser de cette nomenclature. +Erdnaxe propose d'utiliser pour cela la mécanique de systemd qui permet de +renommer les interfaces, et de faire gérer tout ça par Ansible. +Esum parle brièvement de la possibilité de créer des alias. + +> On décide donc de nommer les interfaces ethN avec N VlanID + des alias adm, +srv... + +## IPv4, IPv6, Plan d'Adressage + +### Mettre des RA pour les serveurs + +On parle des Router Advertisement. À une époque, il semblerait qu'on avait tout +désactivé parce que les machines sous Windows 7 pouvaient générer des faux RA +sur le réseau. +Maintenant, la protection mise en place sur les switchs et le fait qu'on n'ait +presque plus de Windows 7 nous poussent à réviser cette décision et de +simplifier la configuration de l'IPv6 des serveurs. + +erdnaxe propose de faire du semistatique : on fixe l'adresse IPv6 puis +l'interface récupère tout le reste en auto comme une grande personne. + +Ça a déjà été mis en place sur certains serveurs, et ça marche bien. Aucun +problème. On fait donc ça. + +### IPv6 et les adhérants + +À l'heure actuelle, quelqu'un qui renatte derrière le crans n'a pas d'IPv6. Par +exemple, un routeur TP-link d'un adhérent ne peut pas filer d'ipv6 (il a mois +d'un /64). + +En réfléchissant à ça Mikachu s'est rendu compte que le plan d'adressage +v4/v6 était pas fou fou. + +### Plan d'adressage + +Mikachu nous dit qu'on ne respecte pas tout à fait les normes dans le plan +d'addressage : Apparemment, on n'est pas censé faire comme ça pour le nat en +IPv4 en tant que FAI. +Il propose de plus de donner un /50 d'IPv6 aux adhérants afin de régler le +soucis évoqué au dessus. + +Ok soit, pour le moment c'est pas urgent, mais on pourra l'envisager plus tard. + +## Monitoring + +Conformément à la décision de la dernière IN, le paquet prometheus qui monitore +systemd a été installé. /!\ Il n'avait pas vu le fail de mailman. + +Le monitoring a pas mal été amélioré, on a droppé plein de choses +legacy (notamment des vieux services systemd). + +> + +erdnaxe a viré de la veille conf ISCSI, et avec Mikachu ils ont viré des +gateway fantomatiques. + +En parlant de systemd, Mikachu parle de networking. + +## Ménage d'hiver + +Renommer vulcain => on le renomme "gateau" + +Virer VM cups ? civet ? (c'est pas comme si un RabbitMQ était complexe à +installer…) +Pourquoi pas, de toute façon on peut les réinstaller si besoin. + +Autre Ménage (synchronisation auto sur les ML à remettre entre autre ....) +Oui on va faire ça. + +## Point disques + +Les disques de gulp sont garantis. +Pour la baie, le CA a donné Des SOUS + +## Gâteau + +On a eu du gâteau. Bienvenue à Vulcain ! diff --git a/compte_rendus/2019_12_09.md b/compte_rendus/2019_12_09.md new file mode 100644 index 0000000..14cbd59 --- /dev/null +++ b/compte_rendus/2019_12_09.md @@ -0,0 +1,254 @@ +# Réunion du Collège Technique + +* Date : 09 Décembre 2019 +* Début : 19:11 +* Fin : +* Lieu : Salle de conférence du Pavillon des Jardins +* <> +* Jitsi : + +Présents: + +* Raida +* Hamza \o/ +* Hachino +* Edpibu +* Mikachu +* Vulcain +* Erdnaxe +* Pollion +* Fardale (par Jitsi, à l'aéroport, quel dévouement) +* Solal +* Benjamin (par Jitsi/Discord) +* Krokmou +* !TinyLinux + +## Garantie Onduleur 0B + +La garantie expire le 18, est-ce qu'on renouvelle ? + +Pollion a contacté Anne pour avoir un devis, mais pas de réponse à ce jour. +On est tous d'accord sur le renouvellement de la garantie. Mikachu émet des +réserves, si le prix de la garantie est trop élevé (au dessus 2k€ on commence à +vraiment se poser des questions). + +Pollion va essayer d'appeler Anne, ça sera peut-être mieux. + +## State of the CRANS + +### Passage au module nginx pour le certificat sur bakdaur et sur Redisdead + +* grosse simplification de la conf, pas mal de lignes en moins +* la pipeline pour ajouter/enlever un site n'a pas changé + +Erdnaxe met en garde : Ne pas trop tenter l'installateur qui est un peu +instable, mais l'authentificateur marche. + +On fait la remarque que de toute façon à moyen terme on va utiliser le DNS et +faire du certificat wildcard. +Mikachu a fait un role ansible qui marche avec Bind pour un certif wildcard en +challenge dns. + + + +On revient sur l'idée de !DynDNS de tudor/erdnaxe. Il y a maintenant une RFC +pour dnssec avec !DynDns. + +Mika dit que ce n'est pas forcément une bonne idée. Pollion est d'accord, ce +n'est plus utile. Mention rejetée. + +### Panne Windows 8/8.1/10 Radius EAP + +* Le 07/12/2019 à 17h30 le cert !CaCert expire (date de 2017) +* Génération d'un nouveau cert avec bakdaur et le domaine wifi.crans.org (qui + redirige vers le wiki maintenant) + +Il faut copier le cert sur tous les radius automatiquement (TODO) et changer la +conf pour pointer dessus (déjà fait seulement sur radius.adm.crans.org). + +On a drop le WiFi sous Windows 7 avec ça... mais Windows 7 n'est plus supporté +fin Janvier 2020. +erdnaxe propose une upgrade gratuite vers Win10 (juste avoir la clé USB avec +l'installer quoi) ou Ubuntu/Debian aux gens qui se plaignent. + +Ok, on peut même en faire la pub, on fait une décharge comme aux Install-Party. +On propose des rdv aux gens. + +Oui enfin c'est long un upgrade faut avoir le temps -- Benjamin + +Effectivement oui, mais on décide officiellement de dropper le wifi pour +Windows 7, et si le cableur est motivé d'upgrade. Sinon on leur dit de faire du +filaire. + +Sinon on update le script pour les Windows 7 pour ajouter le certif racine de +LE ? -- Fardale + +Alors oui on peut aussi upgrade le script, mais le support de windows 7 pose +d'autres soucis. +On peut mettre le script pour configurer les W8 et W10 mais bon, pour eux c'est +beaucoup plus facile. + + + +### Changement du mode d'acquisition d'une ipv6 sur les machines + +* maintenant c'est du ipv6 semi-statique : l'ip est statique, le reste est + récup par un RA (dns, mtu, routeur...) +* on s'est rendu compte que le DNS n'était pas annoncé sur le filiaire adh en + ipv6 +* la conf radvd a totalement été nettoyée, cf /etc/radvd.conf sur + ipv6-zayo (drop des trucs deprecated). On peut la rendre encore plus concise + en sous-entendant les prefixes avec ::/64. + +. On pourrait le faire avec un commentaire. + +* Sauf que les commentaires peuvent devenir faux avec une maj, alors que les + options explicites non -- Fardale +* Oui fin si tu mets le fichier de conf à jour, tu mets aussi à jour les + commentaires... +* Une maj des options par défaut par une maj du paquet +* Bonne remarque Fardale --> On met nos options explicitement... + +### Problème de routage ipv6 + +En Novembre 2019, on a eu un gros problème de routage ipv6, vers certains +AS (par exemple vers ovh, scaleway, mais google/Facebook marchaient) + +On a ouvert un ticket chez zayo, mais ils nous ont fait la remarque "Chez nous +ça marche" (ie entre un point de leur infra et nous ça marchait, entre un point +de leur infra et les AS sus-mentionnés ça marchait). + +De notre côté, en faisant des tests avec !TcpDump, on voyait les paquets +arriver, ils repartaient chez Zayo et n'arrivaient jamais à l'autre bout. + +On a finalement réussi à contacter le Peering Manager Europe de Zayo via +Twitter, et c'est là qu'ils ont commencé à nous écouter. + +Finalement, l'OS de leur routeurs de bordures faisait n'import quoi. Ils ont +fait une mise à jour. Maintenant ça marche. + +Ça a aussi permis de régler un soucis dont le Crans n'était pas au +courant : Crans-Aurore en v4 ne marchait pas, depuis l'upgrade de Zayo ça +marche. + +### Installation de prometheus sur fyre + +* Backup complète de fy +* Update des firmwares avec un SPP HP de 2014 pour Gen5 +* Changement des disques avec 6*128G de HDD en RAID6 +* Installation de Buster puis provisionnement de grafana, prometheus et NinjaBot +* Changement d'ip et de nom de fy->fyre +* Suppression de munin-node et icinga sur tous les serveurs. Playbook Ansible + temporaire spécialement pour ça. +* Suppression de pleins d'alias relatif à munin et Icinga + +fyre n'est plus serveur ntp ou replicat ldap + +Il faut peut-être virer le munin-status nginx des serveurs où il traine + +Le paquet prometheus-postfix est arrivé dans debian. Faudrait l'installer mais +c'est pas encore backporté + +### Migrations d'ip + +On a pas mal avancé dans les migrations des IP ENS-->Zayo, on finit ça d'ici la +rentrée début Janvier. A priori c'est très transparent donc cool. Les seuls +soucis qu'on a eu c'est les ouvertures de ports dans le Parefeu qu'on a oublié. + +## Autorisation du protocole 6in4 + +Mikachu propose d'autoriser le 6in4 sur les ip publiques au moins, ça +permettrait auxadhérents de monter leur propre tunnel HE par exemple + +Pour les IP Natées, modulo écrire un script custom, le parefeu ne peut pas trop +tracer à quelle IP est attribuée le tunnel. + +Pollion dit que si Mikachu a envie de bosser là dessus et de toucher au +Parefeu, tant qu'il ne casse rien, go. + +## Retirer l'ipv6 sur adm + +Esum veut retirer l'ipv6 sur adm, mais bof. + +Du coup on peut peut-être passé sur un slash privé en fd0c:: + +Ouais ok pourquoi pas, mais c'est pas urgent... + +## Devis fibre optique + +Il faut revoir le devis fibre de la DSI et leur en reproposer un cohérent avec +notrebesoin, à savoir 0B into De Vinci + +On va les voir à la fin de la semaine. + +## vo + +Budget de 100€ pour vo voté par le CA pour changer des trucs dans VO. + +Des parties de VO sont au bout de leur vie, mais son CPU, sa CM sont bons. +Mikachu veut juste changer le GPU et une alim à pas cher. Edpibu vend son alim, +Mikachu a un GPU à vendre. Démerdez-vous avec le CA. + +On a l'alim d'edpibu pour 20 €. + +## Bilan des switchs 100Mb/s + +Combien en reste-il ? Peut-on finir de mettre le parc en Gigabit ? + +Il en reste 8, dont 3 au PDJ (démontés dans 3 mois ?). +Est-ce pertinent d'investir maintenant alors qu'on ne sait pas si le CRANS +existera encore à la rentrée ? Ca me semble pertinent de le faire, si on se +donne pour objectif de maintenir le réseau sur Cachan au minimum jusqu'à la +rentrée 2021. + +Alors oui on peut réflechir, on budgétise tout ça, on en reparle à la prochaine +IN. + +## clubs.crans.org + +cf mail sur nounou@ + +On move les fichiers servis dans ~/www/ ? Fusion avec perso.crans.org ? + +Plus personne n'utilise zamok en hébergement de sites qui pointe dessus en +CNAME car ça a été cassé avec la centralisation HTTPS. + +Uniformiser c'est la vie. -- Fardale + +On en rediscute après le pot vieux qui est concerné par ça. + +## Site crans.org poussiereux + +Prototype rapide mkdocs (juste la +homepage et la page de connexion a été faite, mais après c'est du markdown) + +Pourquoi pas, si ça amuse des gens de faire du front, parlez-en en CA. + +!TinyLinux veut bien participer, avec Erdnaxe. + +> Il faut quoi qu'il arrive virer les ref à un service d'impression et +commenter sur Windows 7 et le WiFi +Ok + +### Dist-Upgrades + +On peut faire des DU pendant les vacances ou avant, il faut voir si des +apprentis sont chauds pour participer. En passant sous Buster il faut faire un +peu de Ansible. + +### Ansible + +On rappelle Ansible, cf le séminaire de la semaine dernière (Quel timing +incroyable !) +Lorsque l'on fait un DU, il faut migrer les confs de bcfg2 à Ansible. + +On fait la liste des trucs à faire. + +### Python2to3 + +Il ne reste plus grand chose en python2, le plus gros soucis c'est freeradius. +Les dev upstreams sont réticents à fournir un module python3. Pollion fait la +remarque qu'il existe un rlm_rest, mais il n'est pas documenté (cf les fixme +dans la doc). Mikachu va relire la discussion sur l'issue github, visiblement +Pollion est out of date, depuis fin Octobre un module compatible +python3 commence à sortir, ça mérite un test. diff --git a/compte_rendus/2020_03_10.md b/compte_rendus/2020_03_10.md new file mode 100644 index 0000000..0cf52e3 --- /dev/null +++ b/compte_rendus/2020_03_10.md @@ -0,0 +1,180 @@ +# Réunion du Collège Technique + +* Date : 10 Mars 2020 +* Début : 19:15 +* Fin : 21:18 +* Lieu : 2B +* <> +* Jitsi : + +Présents: + +* Hachino +* Vulcain +* Erdnaxe +* Pollion +* Benjamin +* Sarcozy +* Ÿnerant +* Kaj +* Elkmaennchen +* Charles +* Fardale (Jitsi) + +## Point apprentis + +Il y a pas mal de nouveaux apprentis, c'est très cool. On rappelle les +séminaires du lundi soir +Répondez au [FramaDate](https://framadate.org/diffusionCrans). + +Prochain séminaire la semaine prochaine probablement, ce sera un séminaire Git + +Problème du PdJ qui ferme 31 mars, Elkmaennchen ira voir Trouslard pour la +Lika, il en profitera pour trouver une salle pour le Crans aussi. On envisage +fortement d'aller sur Saclay. + +Pollion propose d'automatiser le forward info-dsi vers les apprentis avec +Zentrum. <- c'est amusant comme idée, mais faut faire attention, zentrum est +pas encore très stable, j'ai d'ailleurs vu passer encore une erreur que j'ai +pas réussi à reproduire et j'ai supprimé par erreur le mail impliqué :( + +### Démémagement + +On lâche le PDJ le 31 Mars, mais on n'a pas de nouvelles de la part de l'ENS +donc on va les relancer (vulcain). + +On a 4 switchs et une 10zaine de bornes. + +#### Point du bâtiment G + +Fibre actuelle passe par l'ENS et revient vers le G. +La DSI nous a pas recontacter ! Il faut les relancer pour le matériel et +démontage. Vulcain va ping Pascal : + +{{{ +vulcain@lui-même$ ping pascal +No route to host +}}} + +Avec le départ de l'ENS, ça va couper Internet. Pollion propose au CT de +réaliser un pont wifi. + +* Vulcain propose un pont filaire <3 + * On a les photos sur comment faire en plus +* Solution proposée par Chirac : le CROUS a des paires de fibres non utilisées. + * C'est a priori une bonne idée, Pollion va contacter David Da Silva + +Le pont !WiFi peut faire backup. Mais problème de boucle réseau à éviter. + +### Avenir du CRANS 2.0 et Migration + +* Ce qu'on garde, et ce qu'on bouge, on en a déjà parlé, et on n'a toujours pas + de nouvelles de la DSI. Vulcain va les relancer. + * Pour rappel, la proposition se + trouve [ici](https://pad.crans.org/p/survie_crans). +* WikiPollion rappelle aux apprentis l'histoire des IP ENS et des migrations. + * Il reste à migrer charybde vers une nouvelle ip publique. On migre aussi + les mirroirs en http au lieu de ftp. +* Il faut aussi renommer tous les serveurs qui contiennent {{{.dmz.crans.org}}}. + +La liste des serveurs qui ont besoin d'internet se +trouve [sur ce pad](https://pad.crans.org/p/ip). + +On dispose de 3 types de serveur : + +1. serveur avec une ip publique +1. serveur avec une ip natée (qui a internet) +1. serveur sans internet + +* On a fait la liste sur le pad. Pollion et Mikachu relancent Rezosup. +* ON BRÛLE MEDIADROP avec un apprenti. +* On ne maintient plus !LimeSurvey. + +On rappelle aussi qu'il reste soyouz à migrer pour enfin s'en débarasser et +arrêter de payer les deux serveurs chez ovh : Soyouz et Sputnik. On fait le +point sur ce qui n'est pas encore dans Ansible : + +* le wiki +* la fin du DNS +* NTP +* Réplicat LDAP/Postgres +* Postgres de manière générale.... + +À vérifier. + +Ce qui a été mis : + +* Les mails sont ansiblisés +* Wireguard + +Sarco est chaud pour toucher à ça, il peut demander à qui il veut, et erdnaxe +veut brûler des choses. + +### Upgrade re2o + +erdnaxe a un fichier qui a exactement les commandes pour DU qu'il a fait sur +re2o-test. +Ça marche bien et ça ne prend pas plus que 20mn. + +Feu vert pour le migrer ce week-end (Plot twist, on n'a pas pu, c'était le +week-end du début du confinement). + +{{{#!wiki caution +Il faut upgrade toutes les instances de re2o. (sur les radius, bcfg2, et zamok +et thot) +}}} + +### DU + +On brûle aptdater, Ansible le remplace. + +#### Gulp + +Keepalived ansibleisé, toujours le pb des interfaces. +On fait le point sur les trucs qui restent pour gulp, on finit d'Ansibleiser. + +Mais c'est pas vraiment urgent, puisque à priori gulp va devenir un +Virtualiseur sur Saclay + +#### Zamok + +Client nfs ansibleisé, on va brûler le fstab.local, on utilise systemd-mount. +Les paquets installés sont ansibleisés. +Les mails sont ansibleisés. + +Il faut vérifier les ldap scripts (type chsh, passwd etc ...) + +Pour zamok, il va falloir prévoir une maintenance : Les gens vont perdre leurs +screen. +On peut le faire pendant les vacances scolaires (6 Avril -->) + +### Questions diverses + +* Faire quelque chose pour les gens qui lancent {{{find + . -name \.[A-Za-z]*}}} sur leurs mail (ce qui fait lagger zamok et zbee) + * On liste les gens qui utilisent ça, on leur envoie un mail pour leur + rappeler avec un timeout d'un mois à la fin duquel on change le script + comme des animaux dans leur home. +* Backup charybde ? Est-ce que l'on ne ferait pas un ftp "données à ne pas + backup" et un ftp "on backup" ? + * Suffit de le rajouter dans les backups avec le site de backuppc. +* Erdnaxe : Qu'est-ce qui nous oblige une MTU de 1496 ? Ça pose problème avec + les logiciels comme Docker auquel faut forcer 1496 à la place du 1500. + Peut-on passer sur 1500 ? + * Le problème était avec un vieux switch CRANS au niveau de la baie meso + DSI. D'après Chirac, ce switch a été démonté en 2018. On ne sait pas s'il + y a toujours des soucis avec l'interco DSI-CRANS qui pourrait en avoir + besoin, on ne sait pas ce qu'il se passerait si les switchs de la DSI et + leur routeur pioneer voyaient des trames de 1504 octets + arriver (1500 + 4 octets du tag vlan zrt 1132) au lieu de 1500. + * Toujours est-il que ce n'est absolument pas urgent, les gens affectés + savent ce qu'ils font normalement, et c'est vraiment pas le bon moment + pour se rajouter du boulot. +* Erdnaxe se pose la question de mettre un split à 128 plutot que 255 dans le + failover DHCP (en test à Aurore). + * On n'a pas de charge, on verra quand on passera le dhcp sous buster avec + Ansible. +* WPA perso sur le wifi avec config.properties maintenant qu'erdnaxe l'a + réparé. Est-ce que l'on le veut ? + * Erdnaxe fait des tests, on en rediscute à la prochaine IN. Mais bon ... + Est-ce que l'on a vraiment envie de ça ? diff --git a/compte_rendus/2020_05_09.md b/compte_rendus/2020_05_09.md new file mode 100644 index 0000000..5053c4c --- /dev/null +++ b/compte_rendus/2020_05_09.md @@ -0,0 +1,286 @@ +# Réunion du Collège Technique + +* Date : 09 Mai 2020 +* Début : 14:07 +* Fin : 19h16 (ouais c'était un peu long) +* Lieu : En visio +* <> +* Jitsi : + +Présents: + +* erdnaxe +* Esum +* shirenn +* Hachino +* Pollion +* Vulcain +* TinyLinux +* Mikachu +* Krokmou +* Vite fait au début +* Ÿnérant (là chez PA) +* PAC +* Thybal + +## Un jitsi scalable + + + +On a augmenté la ram de Jitsi à 4G, ça a l'air de mieux tenir. On vient de se +rendre compte que jitsi a publié un topo pour faire passer tout ça à l'echelle. + +« The Jitsi-Meet server will generally not have that much load (unless you have +many) conferences going at the same time. A 4 CPU, 8 GB machine will probably +be fine. +The videobridges will have more load. 4 or 8 CPU with 8 GB RAM seems to be a +good configuration. » + +Est-ce qu'on upgrade encore ? Est-ce qu'on tente d'avoir plusieurs videobridges? + +'''''Erdnaxe''''' : Java11 va probablement réparer des choses. + +'''''Hachino''''': - Pourquoi on a envie d'augmenter la puissance ? + +* On a envie de garder ce service car il est cool, et en l'état il se + met(tait) à crasher au bout d'une vingtaine de minutes. + +'''''TLinux''''' : Pourquoi certaines personnes n'entendent pas les autres ? + +* Ça fait partie des bugs qu'on a observés, et c'est potentiellement lié au + manque de ressources (en particulier à la RAM). On espère que ça va être fixé. + +'''''Mikachu''''' : Si le serveur peut pas être mis à jour vers java11 il va +falloir trouver une solution pour pouvoir quand même mettre à jour vers Buster, +ou alors dropper le service. + +On ansible-ise jitsi ? oui +On tente un passage sous buster malgré la jvm ? oui, sur une nouvelle vm à +créer pour l'occasion. + +'''Conclusion :''' + +* On va garder la vm jitsi actuelle +* En parallèle on déploie un videobridge satellite sous buster pour tester. +* À terme on aurait un jitsi-meet et des petits videobridges satellites. + +Vulcain est intéressé. Il regardera avec Pollion. + +## Désactiver UPNP sur les switches + +Erdnaxe : Si on ouvre vlc sur le campus (en filaire), on s'apperçoit qu'on peut +voir les fichiers multimedia de certains adhérents aussi branchés en filaire. +C'est un truc par défaut fait par Windows lorsque l'utilisateur a coché réseau +privé. +C'est pénible. + +Exemple : + + +Problème aussi des imprimantes réseaux. + +Attaques utilisant UPNP + + +On peut visiblement aussi désactiver mDNS sur les switches et ça a l'air de +régler le soucis UPNP. + +erdnaxe s'occupe de regarder ça pour le switch de sa chambre et on en +rediscutera. + +## Quelques points sur l'avancée du crans + +### Du monitoring + +--> Grafana + #monitoring alertes de prometheus. + +On monitore maintenant le dhcp avec l'exporteur mtail +On s'est rendu compte que certaines machines qui appartenaient à des adhérents +en manque de connexion/adhésion, mais qui ne s'étaient pas débranchées, +continuaient à faire des requêtes dhcp mais n'obtenaient évidemment aucune ip +et ne faisaient que flooder. Il a suffi de forcer la déconnexion de la prise +pour ça. ---> Il faut regarder si on ne peut pas demander aux switches de +forcer un challenge radius tous les X temps ... +Il manque la conf radius dans mtail, ça serait bien +On continue à déployer des nouveaux exporteurs etc ... Venez sur #monitoring. + +Pour +prometheus : + +Krokmou est intéressé par regarder pour éventuellement rajouter des nouveaux +exporteurs. +Pollion propose de monitorer l'état des dépots git. + +### cranspasswords 3.0 + +Pour l'instant c'est encore une version beta. Il reste des bugs, mais on se +rapproche d'un truc qui marche bien. On continue de tester. + +### Des motds + +Sur les machines qu'on gère avec Ansible, on indique les services dans le motd. +On propose de rationaliser un peu tout ça, de mettre les services en +bas, '''APRÈS''' le dessin et de tout rendre modulaire. + +### Des dist-upgrade + +Quelle belle transition ! + +On a pas mal avancé dans les mises à jour vers Buster. On ne lâche rien. +Pour suivre les DU, on a la page wiki idoine + + +### Du ansible + +* Quand on DU un serveur, on le passe en même temps de BCFG2 à Ansible. On en + profite pour faire des raffraîchissement de la conf et virer les vieux trucs + legacy. +* On déploie un header sur les fichiers gérés par ansible. Pour remplacer les + appels de BCFG2 à la base de donnée re2o, Pollion a développé un lookup + plugin dans le dépot ansible qui permet d'interroger l'API, et qui met les + résultats en cache afin d'accélérer tout ça. C'est en cours de relecture, et + ça sera mergé après. +* +* On va remplacer les lineinfile par un déploiement complet avec des + templates. Ça permet de savoir exactement les options qu'on veut. Si les + fichiers proposent des include, on garde évidemment la version des dépots + officiels. +* Fusion des playbooks, utilisation des tags et import_playbook. Avec les tags + on peut limiter à un petit playbook. + +### Du wildcard + +On a déployé *.adm.crans.org (pour gitlab.adm.crans.org) et *.crans.org +On pourrait mettre certbot sur toutes les VM et ne pas faire de wildcard mais +bien un challenge DNS-01 + +On a 4 options : + +1. On copie le wildcard du proxy partout +1. On crée un wildcard sur chaque serveur avec un challenge DNS --> Nécessite + la clé privée TSIG sur tous les serveurs mais pas de conf à écrire +1. On crée un certificat nominatif par serveur avec challenge DNS --> Nécessite + une clef privée TSIG pour _acme-challenge.nom_serveur(.adm).crans.org pour + chaque serveur +1. On fait du challenge HTTP --> pas possible sur adm. (enfin si mais c'est + chiant et on a pas envie) + +On est tous d'accord que pour les MX on veut passer à un challenge DNS. On a un +petit débat : + +* Pollion veut mettre le wildcard sur les autres services : On copie le + wildcard du proxy. --> Option 1) +* Benjamin n'aime pas l'idée de rsync, 4) là où c'est posssible + et 2) sinon ( 2) pour les serveurs sur adm) +* erdnaxe: vu la facilité du challenge HTTP-01 avec nginx, autant utiliser ça + où on peut, là où il y a déjà NGINX, sinon standalone avec le serveur dans + certbot +* Mikachu: Pas trop de préférences entre 1 et 2 mis à part que 2 il n'y a pas + de conf à écrire. +* Krokmou : (3, trop chiant -) 1 - 2 - 4 +* Hachino commence à comprendre, un peu. On va dire que le couplage 4-2 de Coq + a l'air pas mal. Mais au pire mon vote n'est pas éclairé. .-. +* TinyLinux : cf. Hachino +* Vulcain: plutôt 2 pour la facilité de déploiement et de maintien + +Finalement, on part sur l'option 2. + +### Bind vs knot + +Bind marche mieux et permet de faire des wildcard et des vues DNS mais c'est à +faire. [Tâche Phabricator](https://phabricator.crans.org/T444). + +* Il reste knot uniquement sur titanic et soyouz le temps de les virer +* boeing et sputnik tourneront sous bind +* Il faut aussi remettre en place DNSSEC + +### Framadate + +* Shirenn et Erdnaxe ont installé un nouveau serveur : ```voyager``` sur lequel + ils ont mis en place un Framadate. Pollion et Mikachu ont trouvé des + problèmes avec Postgres et PHP7.3. On propose d'arrêter d'utiliser la vieille + version 1.2alpha et de passer à la 1.1.10 mais cela nécessite d'utiliser + mysql (en local). +* Le README/wiki est flou sur la question de la version de PHP compatible + +'''Que fait-on ?''' +Shirenn teste mysql et si ça ne marche pas on brûle le service +peut-être un framaform à venir si framadate marche bien + +### Divers + +On a DU les proxy sous buster qui ajoute le support de TLSv1.3, ça semble très +bien marcher. + +## Idées + +Remplacer les services re2o par un nouveau dépot ansible-services, qui +utiliserait le lookup, et des template jinja pour générer les configurations : +alias mail +dns +dhcp +firewall +Même les switches potentiellement ? Il faudrait un connection_plugin pour +envoyer la conf en http mais pourquoi pas +Pas la peine, Ansible For Network Automation fournit un plugin d'Aruba nommé +aruba_config qui applique une conf via SSH. +Shirenn est en train de tester, on a un soucis avec les commentaires mais sinon +ça marche + +Ça résoudrait le soucis des erreurs 500 sur l'API, puisqu'il n'y aurait plus +d'invalidation de token +Déploiement par otis (la vm qui scribe tout) régulièrement via un cron. + +Encore mieux, si on mettait en place du MQTT ou des webhooks :p + +--> Benjamin : On crée une app dans re2o avec des signaux qui envoie à un + serveur MQTT (sur Otis ?) les changements quand il y en a eu. + +* On rajoute en plus une commande manage.py qui permet de faire un + full-regen de la conf. + +--> Mikachu soulève le problème suivant : + +* D'une manière ou d'une autre, un service peut ne pas recevoir le message + et il faut qu'il puisse recevoir la conf complète à intervalles réguliers, + fasse un diff avec ce qu'il a, et prenne la vraie conf le cas échéans. Si + jamais il y a eu un diff, c'est qu'il y a eu un soucis et il envoie un + mail pour que les nounous regardent. + +C'est la commande manage.py qui est appelée à intervalles réguliers (toutes les +heures par exemple). + +Conclusion: +On va tenter un concept où nos services sont regroupés dans un unique dépot +avec tous les scripts de regen. On utilise potentiellement des template jinja +pour proprifier. Ils écoutent la file MQTT et appliquent leur conf. + +## Liste des trucs à faire + +On prend chaque serveur un par un dans + et on +dresse une liste, y compris avec des gens motivés. + +Collegialement moins erdnaxe qui s'est barré faire du servens (oui je +rage <3 <>) : + +* On utilise les host_vars, c'est très propre, et on track les trucs locaux. +* En plus on ne se sert pas des alias interfaces. + +## Point déménagement + +Update, déménagement le 25 Mai des locaux crous par le BdE. On est d'accord que +ça ne nous concerne pas ? On n'est effectivement pas concernés + +Pollion doit recontacter le Crous de Créteil, le confinement a tout de même +retardé la chose. + +Le confinement a violemment bougé le calendrier, il faut voir avec la DSI pour +tout un tas de trucs : +La demi baie +Le matos de récup +Le démontage de nos bornes +Révision du calendrier de déménagement --> Point du bâtiment G devient critique +actuellement. +EPF ? Autre ? Ulmites ? diff --git a/compte_rendus/2020_07_24.md b/compte_rendus/2020_07_24.md new file mode 100644 index 0000000..8ea45cb --- /dev/null +++ b/compte_rendus/2020_07_24.md @@ -0,0 +1,143 @@ +# Réunion du Collège Technique + +* Date : 24 Juillet 2020 +* Début : 19h15, commencé par une signing-party gpg, IN à proprement + parler 20h00 +* Fin : 22h30 +* Lieu : 2B + en visio +* <> +* Jitsi : + +Présents: + +* 20-100 +* Erdnaxe +* Esum +* Hachino +* Mikachu +* Pollion +* Shirenn +* Solal + +## Un problème de clim ! + +Devis +Le technicien semble avoir fixé la fuite jeudi 23 juillet, après N tentatives +de LTC. +On a envie de changer de prestataire. + +## Bilan de ce qui a été fait et reste à faire + +### Monitoring radius + +On monitore certains types de connexion radius en parsant les logs, et ça passe +par prometheus. Il faut un peu l'améliorer, mais c'est cool. + +### cpasswords 2.0 + +Odlyd a toujours son ip ens et ça pose soucis. Le nouveau cpassword est encore +en beta test, mais c'est cool. + +### Ansible + +Beaucoup de choses ont été faites sur Ansible, mais il faut rationaliser la +conf. On va écrire un !HowToAnsible <> pour le crans et créer une +convention. Attention, quand on passera à Ansible 2.10 il faudra penser à +appeler les collections. ça sera dans le !HowTo. + +### Framadate + +On a mis un framadate au crans, il marchotte, on le laisse vivre comme ça. +Mikachu dit qu'il y a des notions cool dans phabricator pour faire des sondage +etc. ça ferai de la pub pour nos services. Pourquoi pas. + +### Postfix et dovecot + +On a droppé cyrus pour l'auth sasl. C'était encore en test pour l'instant, +Pollion va le mettre dans l'Ansible et le sortir de test. + +### Pad + +Shirenn propose de passer au nouveau thème, on verra mais pourquoi pas. + +## Coupure de l'ENS + +L'ENS est partie, quelques difficultés de communication, le G n'a pas été +coupé (mais le RU oui) : On passe maitenant par une fibre du Crous entre le 0B +et le 0G. + +Il faut finir de faire le ménage dans les ip ENS. + +## Récupération de matos + +On a récupéré N trucs de l'ENS : +4 Arista 10 Gb 24 ports de l'infini. L'objectif est d'en utiliser que deux. +2 Baies de disque !SuperMicro 2U (128 G de Ram). On va réutiliser de la ram +pour les hyperviseurs. +2 Baies 4U qu'on va laisser de côté pour l'instant. +Chacune des baies venait avec des carte 10G + +Et une palanquée de disques. + + +C'est super cool. Ça va nous permettre d'upgrade vraiment l'infra :D !! (Voir +point suivant). + +## Future infra + +On va jeter les vieux serveurs qui servent de chauffage. + +Mikachu fait une présentation globale de la POC de la nouvelle infra +actuellement en test au 2B depuis + +Regarder : Est-ce que l'on peut mettre des nice-levels dans le Proxmox pour +éviter de surcharger les VM de routage ? + +20-100 indique qu'en cas de keepalived sur des vms, le firewall datacenter de +Proxmox 6 considère certains paquets comme invalides et ça fout la merde + très +difficile à débuguer .... Il a rencontré ça au taf ... +Idée : mettre radvb sur les 3 VMs de routage sans keepalived et avec des +métriques différentes pour le routage ipv6. + +### Projet de LDAP nounous + +Esum présente le LDAP nounous : + +* envie de cacher les hosts +* passwd hash de façon faible, on va utiliser un script +* on conseille ldapvi +* on peut se loger en tant que soi avec les bons droits +* log en LDIF + +Esum présente aussi le routage et le plan d'adressage. On se pose la question +de regrouper le wifi et filaire. À part pour la TV on ne voit pas de contre +indication. On va faire le test, mais dans l'optique de tout simplifier ça nous +semble une bonne idée. + +## Virer les vieux switches 100M + +On va faire la liste et voir pour changer ces switchs avec le matos. Il serait +intéressant d'avoir le campus en Gigabit. + +## Configuration des switches + +Erdnaxe et Shirenn ont regardé comment automatiser la configuration des +switches. L'idée était au début d'utiliser Ansible, mais en fait c'est l'Enfer. +On va réécrire un script tout joli et tout propre. Erdnaxe propose de mettre en +place LLDP, c'est pratique pour débugguer. Pourquoi pas ? + +## Cloud-Init Proxmox + +Cloud-init est une techno qui vient d'!OpenStack qui permet à un provider cloud +pour monter un truc en même temps que la vm pour la provisionner. C'est très +pratique et ça a fait ses fruits. On fera un script pour automatiser la +création de vm ! Problème c'est long à booter et on veut pas que les gens +fassent de la merde non versionnée. On propose de supprimer le paquet +cloud-init après l'installation pour éviter ça. + + + +## Gateau + +Shirenn est nommé nounou, bravo à lui ! diff --git a/compte_rendus/2020_12_21.md b/compte_rendus/2020_12_21.md new file mode 100644 index 0000000..c17e8b2 --- /dev/null +++ b/compte_rendus/2020_12_21.md @@ -0,0 +1,139 @@ +# Réunion du Collège Technique + +* Date : 21 décembre 2020 +* Début : 17:17 +* Fin : 18h58 +* Lieu : En visio et à la Kolok +* <> +* Jitsi : + +Présents: + +* erdnaxe +* shirenn +* PAC +* Pollion +* Mikachu +* Solal +* Ÿnerant +* esum + +On a un peu avancé, mais c'est vrai que les confinements ne nous ont pas trop +fait de cadeau. + +## Planification de la migration + +### Mise en place des vms de routage + +* Pare-feu (nftables) --> Le parefeu marche. Il faut faire la migration de re2o + ou mettre une patte à re2o sur la nouvelle infra. + +Pour faciliter la migration, on va commencer par mettre une patte à re2o sur la +nouvelle infra, et on va commencer par migrer les machines avec ip publique. +Il faut passer sur master sur le script de génération du parefeu, afin de +parler à re2o, et rajouter une ligne pour le hack sur la proxy ARP. +Il faut aussi mettre en place rsyslog. On discute de où on met les logs. +On va les mettre sur tealc dans une pool /pool/logs. +Il faut donc adapter le role rsyslogd et logrotate. + +* La question de l'ipv6, comment ça marche actuellement sur la nouvelle + infra (@Esum) + +tout marche bien c'est cool. Il y a juste un bridge entre ipv6-zayo et +routeur-sam, avec un vlan spécifique pour l'interco. Mais c'est du hack +temporaire, ça sautera à la fin de la migration. + +### radius + +Le radius marche, il faut juste mettre en place rsyslog. + +### dhcp + +Il est en place, on vérifie quand même que ça marche, mais de mémoire cet été +c'était le cas. Il faut juste faire attention à ne pas utiliser dhcp-failover +car ça ne supporte que 2 serveurs et nous on en veut 3. + +### dns recursif + +Ok +dns autoritaire +Parfait + +### Migration des dernières vm + +* IRC --> On propose de DU zamok vers bullseye, comme ça on aura un serveur des + adhérents à jour et erdnaxe sera content. +* Rezosup (@Mika et @Esum) --> Ils vont migrer cette vm bientôt, et ça ira très + bien. +* Bde et Gala (@Pollion, @nanaxe et @Vulcain) --> Gala c'est fait, il faudra + juste rechanger l'interface quand on aura migré les IP publiques adhérents. + Pour le Bde, bah Pollion a laissé jusqu'au 26 décembre au BdE pour faire + quelque chose de cette VM. Pac et Ynerant s'en occupent. On propose d'offrir + un dump de la vm note sur une clé usb crans à 20-100. +* Matrix-eea (@nanaxe, @PAC) --> erdnaxe la brule mais avant : backup ! +* Redisdead, owncloud, owl --> redisdead change d'infra mais garde une pate sur + l'ancienne. Profiter de l'Interruption de Service ou alors commencer par + finir d'installer sputnik. + * Mikachu veut se taper une chouette ce soir. + * Pour owncloud et owl, on peut les installer sur une vm sur la nouvelle + infra et faire des tests avec Cameron (la baie des homes), en écrivant un + role pour owl, car c'est pas encore fait. Mais il faut attendre la + migration finale pour passer ça en prod. +* Sauvegarder tout le reste (dans une pool sur Zephir ?) + * On va faire une pool cimetière. RIP les vieilles vms. + +### Migration de zamok + +On va le DU vers bullseye. +On va rajouter des disques dans Zamok dans l'objectif d'héberger des petites +images podman, pour un futur projet. + +## Plan de la migration + +1. Migration des home: + Il faut prévoir une interruption de services. + Il faut : + * Être certain que les services qui parlent aux home tournent : En gros + owncloud et owl, + le nouveau serveur irc. + * DU Zamok vers bullseye. + * Refaire un rsync des home, mais ça devrait aller assez vite. + * Et finir de setup le nfs sur zamok. +1. Migration du réseau. + * Il faut migrer les switches. Ça veut globalement dire appliquer le script le + Mikachu. + * Il faut migrer les bornes. Pollion et Esum ont fait des tests pour migrer une + borne [c'est facile](https://wiki.crans.org/CransTechnique/ControleurUnifi#Changement_de_controleur). + +En bonus, on a testé avec un controlleur unifi sur buster. + +Par contre ce qu'on dit c'est que cette migration sera faite dans un second +temps. + +### Choix des dates + +1. Migration des home, lundi 28 Décembre. +1. Migration du réseau le week-end du 2/3 janvier. + +## Post-Migration + +### Nettoyage de Vo et caillassage des serveurs + +Backup des trucs qui trainent et stockage. + +### Après la migration, la DOC et ansible + +Ce serait pas mal qu'à un moment après la migration, on puisse run ansible sans +rien cassé +Écrire toute la doc et archiver la doc de l'ancienne infra + +### Chiffrement des disques + +On en reparle plus tard, mais il va falloir un autre rsync pour chiffrer la +pool ZFS sur cameron. Pour les backups, c'est fait avec borg. + +## GATEAU !!!! + +1. Le CT s'agrandit, avec l'arrivée de PAC. Bravo à lui ! +1. Ce n'est pas encore tout à fait officiel (je ne veux pas laisser un crans + instable), mais Pollion va rendre les rênes du CT et shirenn a accepté de + reprendre cette charge. Merci à lui et bonne chance ! diff --git a/compte_rendus/2021_02_16.md b/compte_rendus/2021_02_16.md new file mode 100644 index 0000000..302e76d --- /dev/null +++ b/compte_rendus/2021_02_16.md @@ -0,0 +1,176 @@ +# Réunion IN + +## Réunion du Collège Technique + +* Date : 16 Février 2021 +* Début : 20h15 +* Fin : 23h15 +* Lieu : Partout +* <> +* Jitsi : + +Présents: + +* Esum +* Ÿnerant +* shirenn +* Pollion +* Vanille +* PAC +* Nicomarg +* Sarcozy +* TinyLinux +* Mikachu +* Sun +* erdnaxe +* Solal + +### Accueil des nouveaux amis + +Bonjour les nouveaux amis. Le Crans c'est cool. Mangez-en --> Les +nouveaux ? ---> Ouiiii. shirenn et Ÿnerant ont fait une présentation de l'infra +aux nouveaux. C'est cool. Et ils sont motivés ! + +### News, Jabber, TV + +#### Jabber - (aka xmpp) + +Globalement personne ne s'en sert, ou presque, et surtout le Crans ne peut/veut +plus le maintenir. Il est backuppé, donc s'il le faut il peut être rallumé et +les données ne sont pas perdues. + +#### News + +Avis beaucoup plus mitigé, Pollion estime que l'historique des news apporte un +regard sur l'histoire moderne de Cachan. La vm est éteinte pour l'instant car +elle n'a jamais été mise à jour depuis Jessie. Un projet un jour, les mettre en +statique quelque part ? Remettre en place un autre +webnews ? . Esum: Le protocole +est mort de toute façon .... + +#### TV + +On a abandonné la TV en multicast, on a laissé la TV en unicast. C'était un +projet cool, mais dans l'optique où on veut laisser le Campus à l'EPF (et oui, +on a des repreneurs !!), on n'a pas spécialement envie de laisser tourner une +mine (ou une ferme). En plus ça n'a plus beaucoup d'intérêt à l'heure où la +plupart des chaînes diffusent en direct sur leur page web. On va arrêter d'en +faire la pub, et à terme l'arrêter. + +### Bilan de la migration + +On a viré les 20 ans d'empilement de scotch au Crans. L'idée qui semble assez +réussie était de simplifier au maximum l'infra, et on a des repreneurs !! (oui, +je me répète mais c'est cool). On va espérer que le Crans survive. Il reste +encore un soucis reporté par les utilisateurs de PS4. C'est vraiment très +bizarre et on n'a pas vraiment d'idée sur comment régler ça... + +Il faut vraiment terminer de configurer les routeurs de backups parce que là +c'est pas fait. Keepalive pas encore fini de gérer. TODO !! + +Il ne reste plus que le Backbone à remplacer par le deuxième Arista, mais le +couvre feu nous avait mis des bâtons dans les roues pour terminer la +maintenance. + +Update: Fait le Lundi 22 Février 2021 + +### Backups + +On pose la question de savoir par quel VLAN on fait passer les backups: Adm ou +directement SAN ? On décide de laisser SAN confiné au 0B et de continuer sur +ADM. On discute de backups offsite. On envisage Aurore et/ou Sputnik, mais pour +le moment Sputnik est down depuis ce matin .... + +### Convention pour les interfaces (interfaces.d, yay or nay ?) + +On discute d'une convention pour la configuration des interfaces et du réseau. +Pollion, Esum et shirenn sont pour garder la séparation des interfaces dans +interfaces.d. Mikachu dit qu'il aime bien un fichier monolithique qui contient +tout. On vote, on garde interfaces.d + +### Bornes wifi qui arrivent en fin de vie. + + + +Le controlleur se plaint qu'il y a des bornes qui deviennent EOL. On ne pourra +pas màj le controlleur après le 1er Mars. Elles ne seront plus configurables. +On propose de garder le changement de bornes sous le coude pour introduire les +EPF dans le monde du FAI associatif. + +### Vieux Switches 100M + +Même chose qu'au dessus, on en fait un projet EPF. + +### Windows 7 + +Pollion propose de virer le support TLS <1.2 des RADIUS ce qui aurait pour +conséquence de dropper le support de Windows 7. Benjamin est pour. On fait un +encart plus visible sur la page du Crans, et on invite les gens à passer sous +Windows 10. Ceux qui ont encore Bref, on est tous d'accord. + +### Pass + +On souhaite avoir un logiciel un peu plus mature. On reste temporairement +sur !CransPasswords (avec le serveur de esum). erdnaxe va debug reencrypt avec +Pollion sur pass-group. + +### Ansible + +#### Header + +Shirenn n'est pas content du header qui change tout le temps. Benjamin a trouvé +un compromis: Le header ne va changer que si le fichier en question est +modifié. Pollion trouve ça cool ce nouveau fonctionnement. shirenn est toujours +pas trop content du résultat, mais finalement on accepte le nouveau header. + +#### Playbook All + +On décider de remplacer le playbook {{{all.yml}}} par un script bash qui va +lancer ansible en check_mode sur tous les serveurs. On est tous pour. + +#### Fichiers statiques + +Les fichiers statiques sont partouts, on va faire des symlinks, et les +regrouper en un seul endroit. + +#### Branche + +Ça fait un an que notre ansible tourne dans la branche newinfra. Maintenant que +la migration est terminée on va renommer en master (Après les MR). + +#### Action_plugins + +Erdnaxe propose de déplacer les action_plugin dans les roles. Mais on a des +trucs relativement génériques, sauf l'action plugin du wiki, mais bon .... On +décide de garder à la racine. + +#### Port Forwarding + +Le LDAP CT n'écoute qu'en local sur tealc. On doit faire du port forwarding +pour s'y connecter. C'est nécessaire pour certains playbooks +comme {{{root.yml}}}. Erdnaxe propose d'automatiser de faire le port forwarding +pour le ldap au moment de lancer Ansible. Il va regarder comment faire. + +#### Inventaire + +Erdnaxe propose d'utiliser le LDAP comme inventaire ... Mais bon ça ne sert à +rien car on a de toute façon les host_vars. On décide de garder le +fonctionnement actuel. + +### Nginx et Gitlab + +Ynerant propose d'utiliser le nginx du paquet omnibus de Gitlab et de mettre un +nginx tout simple sur Gitlab pour gérer les multi +domaines ({{{gitlab.crans.org}}} et {{{gitlab.adm.crans.org}}}). L'idée est de +simplifier au maximum le nginx et pouvoir utiliser le rôle générique qui est en +cours d'écriture, et laisser Gitlab gérer sa merde. + +### Être nounou, de la légitimité au savoir faire. + +Idée : séparation CT/ancien CT, avec mandat de 4 ans dans le +CT "jeunes" (ie 4 ans nounou). Hachino se colle à la rédaction en express avant +l'AG. + +### Gateau, mais chacun chez soi + +Bravo à Ÿnérant ! \o/ diff --git a/compte_rendus/2021_03_20.md b/compte_rendus/2021_03_20.md new file mode 100644 index 0000000..d76991c --- /dev/null +++ b/compte_rendus/2021_03_20.md @@ -0,0 +1,140 @@ +# Réunion du Conseil Technique + +Lieu: + +Date: Samedi 20 Mars 2021 + +Présent: + +* Ynérant +* ds-ac +* Ifugao +* Esum +* Sarcozy +* Solal +* nanaxe +* Vanille +* shirenn +* Pollion +* Hachino + +Ordre du jour : + +* Mailman3 : Est-ce-qu'on migre et si oui, quand / comment ? +* On abordera aussi le BL de free +* Petit point sur les services qu'on a mis en place récemment ou qu'on souhaite + mettre en place dans le futur ? (framadate, hedgedoc, bbb, linx, belenios, + galene, tmpad, nitter) +* Weechat créée des processus zombies qui peut à terme empécher les + utilisateurs à se connecter sur zamok +* Déménagement : Comment migrer quoi et comment ? Comment maintenir avec le + materiel minimal l'infra à Cachan ? +* !AutoPerso : discussion sur l'hébèrgement des pages persos sur zamok +* !AutoBackup : backuper séparement les données des différents utilisateurs +* Script de création de VMs : quelques améliorations + +## Mise au point sur les services + +Les nouveaux services : + +* Framadate (maintenable, à peu près dev par Framasoft) : Il faut fixer la + backup de la base de données MySQL avec Borg et le mot de passe administrateur +* !HedgeDoc : Bug du conteneur qui restart en boucle si la base PostgreSQL est + non contactable. + On aimerait la regrouper sur kenobi. +* !BigBlueButton : on drop, trop lourd et douloureux à maintenir +* Galène : On veut associer un compte ldap à des salles de visio-conférence. + Patch dans Galène pour garder l'ordre des gens. Bug de son lors du partage + vidéo webm. Pour le support de l'OBS on s'en tape pour le moment. + On est très positif, erdnaxe pourra potentiellement faire un séminaire. ds-ac + est potentiellement intéressé pour bosser sur Galène avec nanaxe. On ne + l'annonce pas aux adh, c'est surtout pour du test pour le moment. +* linx : On pourrait augmenter la persistence à 1 mois. + Client linx avec curl pour automatiser l'upload du presse-papier, des + screenshots... + On garde et on le maintient. +* tmp-etherpad : les pads sont persistants par défaut, on retrouve ainsi des + antiquités. tmpad.crans.org est en place, ça marche. + Page qui propose entre les 2 instances sur la page d'accueil. + Proposition : texte blanc sur la popup verte. +* belenios : Installé proprement, on souhaite garder. + On souhaite documenter pour réaliser une élection. + [[CransTechnique/ServicesMineurs/Belenios#Utilisation]] + Un admin ne peut pas supprimer un vote car il y a un tallycounter chiffré. + +Les services que l'on droppe : + +* La TV (cochon) +* Invidious, Bibliogram, Nitter, Searx : On n'en veut pas ou on drop. + Controverse vis-à-vis de l'objectif du Crans. Il ressort que l'on a envie de + converger vers un fournisseur cloud plutôt que de logiciels tel que Nitter. + +## AutoPerso + +Par défaut on met du Apache2 + PHP pour rétrocompatible + +On crée une VM de test sur lequel on a un NGINX qui forward vers des .socket +par user. + +On veut que ça soit passable. + +## Mailman3 + +Mailman3 par rapport à Mailman2 : + +* L'interface web est plus utilisable, il y a de vrais comptes. +* Hypperkitty est exploitable et lisible. + +Il faut modérer les mails avant la migration. +La migration prend entre 2-3h pour les listes, et les archives 2-3 jours. + +Il faut envoyer un mail à *-owner@lists.crans.org + +Certaines ML n'ont pas d'admin ni de modérateurs. On fait au cas par cas. + +Proposition de solution pour la non-modération : + +* si mail reste en modération pendant 6 mois, on envoie + aux -owner@lists.crans.org et on supprime. +* en plus on ajoute "si vous voulez gardez votre ML, vous avez N mois pour nous + répondre" +* on envoie un mail la dernière semaine avant de supprimer à la liste + +Convention de +nommage : . +On passe les noms de ML en lowercase + +On aimerait avoir 2 MX et 2 SMTP (la sortie) bien séparés. Ainsi si on se fait +blacklisté par les listes de diffusion on ne casse pas les courriers normaux. + +Il faut vérifier abuse, trouble, postmaster@ redirige vers root@ + +Date de la migration : nuit du 11 avril au 12 avril + +## Mail vers les adhérents + +On ne fait rien pour HaveIBeenPwned, mais dans un mailall où on indique les +services que l'on arrête on rappelera qu'il faut changer son mot de passe. + +Il faut aussi faire un mail propre et concis disant seulement que l'on arrête +Internet pour les gens sur campus. (+ des affiches ?) + +## Weechat + +On a potentiellement un mauvais script qui tue weechat. +On invite les utilisateurs de Weechat de comparer leurs scripts. + +`ps -aux | grep weechat | awk '{print $1}' | sort | uniq -c | sort -n` + +## Nounou à la retraite + +Blupon, Bernie, Detraz et Grizzly ne veulent plus être nounou. + +Certaines autres nounous souhaitent d'être mis à jour sur l'infra. On attend le +déménagement à Saclay. + +## Début du déménagement à Saclay + +On commence à réfléchir mais on pense laisser Gulp à Cachan pour le routage +pendant le déménagement du cluster. +On mettra sur Gulp : Controleur Unifi, routage, re2o, wireguard (?). diff --git a/compte_rendus/2021_04_24.md b/compte_rendus/2021_04_24.md new file mode 100644 index 0000000..68b308e --- /dev/null +++ b/compte_rendus/2021_04_24.md @@ -0,0 +1,131 @@ +# Réunion du Collège Technique + +* Date : Samedi 24 Avril 2021 +* Lieu : +* Début : 15h00 +* Fin : 17h15 +* + +## Présents + +* shirenn +* ynerant +* esum +* erdnaxe (sporadiquement) +* solal +* vanille +* ds-ac +* ifugao + +## Compte Rendu + +### Déménagement à Saclay − Scission de l'infrastructure + +#### Cachan − Installation de gulp + +Gulp est le denier serveur du crans qui restera à Cachan, il va devoir assurer +l'accès à internet de tout le campus à lui tout seul. On va commencer par +installer à blanc tout ce qui est nécessaire pour le routage et on fera ensuite +la migration peu à peu (on peut se permettre de la faire switch à switch ce qui +évitera une coupure globale). On a fait le choix de garder l'instance de re2o à +Cachan sur toute la fin de la migration et sa bdd sera garder en local à même +sur l'hyperviseur. On détaille ensuite l'ensemble des taches à faire pour +configurer le serveur : + +* Installation de PostGreSQL et migration de la base de données re2o (shirenn) +* Installation d'une vm de routage : + * Installation du pare-feu et du nat (ds-ac encadré par esum) + * Installation du radius (vanille encadré par ynerant) + * Installation du dhcp et ra (ifugao encadré par shirenn) + * Installation du dns recursif (solal) + * Installation d'un pair BGP (ds-ac encadré par shirenn) +* Installation d'une vm re2o et du ldap associé (shirenn, please send help + Pollion) +* Installation d'un controlleur unifi (solal encadré par ÿnérant) + +On effectuera ensuite une première migration pour basculer le routage de toute +l'infra derrière gulp en faisant du BGP entre routeur-{sam,daniel,jack} et gulp +et une autre session BGP entre gulp et zayo. + +Puis on pourra migrer switch par switch l'infrastructure vers gulp. + +#### Saclay − Odlyd + +ds-ac va installer Odlyd avec ÿnérant sous proxmox pour pouvoir faire des tests +avec Aurore et Via d'échanges de routes. + +#### Saclay − Déménagement du reste de l'infrastructure + +Camion, tchou tchou, et normalement, il n'y a rien à configurer à part changer +l'ip de pair de la session BGP. + +##### Les blabla d'un vieux + +Mikachu conseille pour les alim électriques de choisir deux couleurs de cables, +une pour la voie ondulée et une pour la voie non ondulée +Mikachu conseille aussi d'acheter des cables ethernet et/ou des fibres de +couleurs permettant de les distinguer + +#### Achats de matériel pour le déménagement + +Le CT propose l'achat de materiel suivant au CA : + +* Un mail a été envoyé à la DSI de l'ens et de paris-saclay pour voir ce qu'il + faut acheter en terme de sfp + fibre +* On voudrait en plus acheter quelques paires de sfp 10G pour pouvoir être large +* Le cluster actuel est un peu limité en ram, on voudrait acheter quelques + barettes de RAM pour pallier à ce problème : 12*16GiB + +### Discussion sur la documentation + +La documentation est actuellement un peu en fouillis. Il y a des élèments +manquants et des choses plus du tout à jour. On voudrait aussi déplacer la +documentation technique sur un wiki à part. On propose de commencer pour le +moment par s'abstraire de l'engine qu'on va utiliser au profit d'un répot git +avec des fichiers markdowns. On réfléchira ensuite à comment le mettre en forme. + +Un des principaux objectifs de cette nouvelle documentation est de bien +segmenter la différence entre les idées (protocoles, etc …) et les +implémentations (logiciels). Un autre point sur lequel on veut insister et +l'importance de certains services par rapport à d'autres. Certains dont on veut +assurer la pérénité par rapport à d'autres qui seraient moins important. À ces +fins, on propose de restructurer la doc de la manière suivante : + +* Outils : + * Dans cette section, on rassemble tous les outils utilisés et les + descriptions de certains protocoles utilisés + * Exemple d'outils : TLS, APT, debian, rsync, ssh, … + * Exemple de connaissances : IP, Firewall, NAT, DHCP, … + * Mais aussi quelques trucs et astuces de techniciens : + * Acheter un disque +* Infrastructure : + * Ici on décrit l'infrastructure dans sa globalité, pour faire simple ce que + le Cr@ns met à disposition du Cr@ns. + * Par exemple: LDAP administration, NFS, Plan IP & VLAN, matériel technique, + Postgresql +* Services Critiques : ce qui ne doit pas être discontinué et avoir l'uptime le + plus élevé possible. On a établi une liste exhaustive : + * Réseaux (pare feu & NAT) + * Mail (serveur imap & smtp, webmail, mailman (+CAS)) + * Gitlab + * Owncloud + * pad + * wiki technique (actuellement sur kiwi tant qu'on a pas migré) + * zamok (pages perso, etc …) + * IRC +* Services Mineurs : Tout le reste + * Linx + * Framadate + * Tracker + * … + +### Retour sur la Migration de Mailman 3 + +Actuellement, les mails de rappels de modérations sont envoyés +par {{{nounou[AT]lists.crans.org}}} alors qu'avant les mails venaient +de {{{${ml}-bounces[AT]lists.crans.org}}}. C'est un comportement qu'on +souhaiterait conserver, ynerant va investiguer. Et sinon les mails de +verification d'adresse mail sont envoyé +depuis {{{nounou[AT]lists.crans.org}}} comme c'était le cas avant et on s'est +demandé si on ne préfèrerait pas qu'il provienne +de {{{noreply[AT]lists.crans.org}}}. diff --git a/compte_rendus/2021_12_17.md b/compte_rendus/2021_12_17.md new file mode 100644 index 0000000..fb1b454 --- /dev/null +++ b/compte_rendus/2021_12_17.md @@ -0,0 +1,88 @@ +# Réunion du Collège Technique + +* Date : Vendredi 17 Décembre 2021 +* Lieu : Galène () et MB84 +* Début : 20h04 +* Fin : 21:22 +* + +## Présents + +* Ÿnérant +* Vanille +* shirenn +* Solal +* Esum +* ds-ac +* Pigeon Moelleux + +## Ordre du jour + +### Réseau + +* Federez utilisent '''17''' IP publiques de notre réseau. Sans + doute 8 seraient suffisantes ? + +On va les contacter pour réduire leur consommation. + +* Un peu trop de switch sur le vlan 11. On supprime le vlan 11 et on les + déplace sur adm. + +### Bind/Unbound + +Arnaud a installé unbound mais n'a pas encore fait des tests de comparaison +avec bind. + +### Constellation + +Que veut-on que constellation fasse ? + +* Gérer les adhésions +* Gérer les alias mail +* Acheter des trucs +* Exporter un LDAP + +Qu'est-ce qu'on veut importer + +* Les adhérents et leurs infos +* Les factures : exporter les factures en pdf +* Les alias mail +* Les whitelists/blacklists + +### Machines virtuelles des adhérents + +Tout a été fait il faut communiquer aux adhérents et aux clubs. + +### SPAM + +* Comment ça s'est produit : un mdp a leak, un spammeur l'a récupéré +* Failles : + * Horde refuse d'utiliser submission, ignore les ports, et est difficile à + configurer. + Allons-nous brûler Horde ? + * Re2o ne flush pas les comptes donc on ne peut que difficilement lock un + compte en urgence +* Mitigation : + * Outlook nous a enfin déban +* Sécurité : + * tous les mails doivent être envoyés via submission pour qu'une rate limit + soit implémentée + * authentification renforcée pour envoi de messages est implémentée et sera + mise au point à la rentrée + +### Impression + +L'administration n'a pas l'air au courant qu'on va proposer de l'impression. +Imprimante achetée avec succès. Quelques tests faits, un frontend implémenté +pour faire des commandes. +Feature pour rendre les impressions plus secure : au moment de la commande, +choisir un code à 6 chiffres et le taper pour lancer l'impression. +Bientôt: tests de LDAP puis configuration de l'imprimante + +Discuter des modalités de payement avec le BDE. + +### DSI + +Routeur 2754 : on va contacter la DSI par DT, attention à la procédure qui a +changé récemment. +Serveurs : demande de deuxième accès électrique. diff --git a/compte_rendus/2022_04_16.md b/compte_rendus/2022_04_16.md new file mode 100644 index 0000000..c16cea5 --- /dev/null +++ b/compte_rendus/2022_04_16.md @@ -0,0 +1,107 @@ +# Réunion Inter Nounous + +* Date : Samedi 16 Avril 2022 +* Lieu : MB87 et Galène () +* Début : 20h03 +* Fin : 21h43 + +## Présents + +* Vanille +* bleizi +* esum +* Pigeon Moelleux +* Ÿnérant +* shirenn +* ds-ac +* Otthorn + +## Ordre du Jour + +* Suppression du domaine crans.ens-cachan.fr +* Mise en place des serveurs radius à Saclay +* Retour sur le déploiement d'OpenDMARC +* Point sur l'avancée du projet de backups +* Petite avalanche d'acronyme pour discuter des problèmes liés à ZFS + +### crans.ens-cachan.fr + +Avec le décomissionnement progressif du nom de domaine ens-cachan.fr, la DSI a +supprimé la zone crans.ens-cachan.fr qui nous était délégué. Celle-ci était de +notre côté configuré pour se comporter comme un DNAME de crans.org et nous en +avions de manière générale peut fait la promotion au cours des années. Sa +suppression est donc sans grande incidence. Elle ne devrait créer qu'un petit +nombre de liens morts rapidement réparable en substituant à crans.ens-cachan.fr +la zone vers lequel le DNAME pointait (ici crans.org). On peut cependant noter +que certains anciens, conscient de l'existence de ce DNAME avait décidé de +l'utiliser dans leurs adresses mails. Il n'y a malheureusement pas grand chose +que l'on puisse faire à ce propos. + +### Radius à Saclay + +#### Radius Federez + +Depuis le départ de Cachan, le crans n'exporte plus de serveur radius. Celui-ci +permettait aux gens bénéficiant d'une connexion internet sur le campus de +Cachan de pouvoir se connecter à internet sur les campus du réseau Federez. De +plus le crans ne vendant plus à proprement parler de connexions internet à ces +adhérents la question s'est posée de savoir, + +1. S'il était encore pertinent d'avoir un serveur Radius ? +1. Si oui, qui devrions nous exporter dans celui-là ? + +Un point important sur ces deux questions est le suivant, les gens qui par +notre politique d'exportation se retrouveront dans le serveur radius, auront de +fait accès à internet dans les résidences du campus (en particulier les +résidences gérées par Aurore et ViaRézo). Dans le but de ne pas leur poser des +problèmes économiques, il a été rappellé l'importance de ne pas proposer au +crans une solution qui donnerait accès à leur connexion de manière plus +avantageuse que ce qu'il propose. Ce constat nous a amené a réduire la liste +potentielle des gens que nous exporteriont à une seule partie des gens +bénéficiant des services d'hébèrgement de machines virtuelles. Ce nombre étant +assez réduit, il a été décidé qu'il ne justifiait pas le deploiement d'un +serveur Radius. + +#### Radius associatif + +Le running gag continue, il faut contacter l'administration. + +### OpenDMARC + +Pour s'assurer de l'authenticité des mails entrant sur une partie de nos +serveurs mails (pour le moment seulement redisdead et mailman), le logiciel +OpenDMARC a été déployé. C'est une implémentation du protocole DMARC, protocole +qui consiste à vérifier que soit le SPF, soit la signature DKIM du mail est +valide. De plus, il permet aussi l'envoie de rapports DMARC au MX qui le +demande. Cependant, pour envoyer ces rapports, le logiciel utilise une base de +donnée mariadb et n'est pas compatible avec postgresql. De plus, la manière +dont cette base de donnée est rempli a été décrite comme « assez chaotique », +bref, il a été décidé de garder la validation OpenDMARC mais d'attendre qu'une +solution plus propre existe pour l'envoi de rapport. + +### Backups + +Le travail est presque finalisé pour le serveur de backups, on pourra d'ici +peut l'envoyer chez via pour faire des premiers tests. + +### ZIL, ZLOG, ZFS + +Derrière cette avalanche d'acronyme absconts se cache le problème qui a affecté +cameron il y a peu. Le volume d'écriture demandé au serveur était devenu trop +important quand comparé, non à la vitesse, mais au délai d'écriture de +celui-ci. Les serveurs tentant d'acceder en écriture au nfs devait alors +attendre longtemps avant de recevoir un acquittement générant ainsi de l'iowait +sur ceux-ci, faisant monter en flèche leur charge et rendant inutilisable les +services qu'ils hébergeaient. Une solution de fortune a été implémenté sur le +serveur consistant à forcer l'envoi d'un acquittement dès la demande d'écriture +sans attendre que celle-ci ait effectivement été faite. Bien que cela ait +résolu le problème à cours terme, cette solution pourrait occasionner des +pertes de données. Il faut donc trouver une solution plus pérenne que le simple +mensonge sur les acquittements actuellement en place. Pour cela, il est +possible de fournir à zfs un disque séparé (de préférence un ssd car on cherche +ici au maximum à diminuer le temps d'écriture pris par le serveur) qui servira +de cache d'écriture, l'acquitement n'étant envoyé du coup ni dès l'arrivée de +la demande d'écriture, ni quand celui ci serait effectivement écrit sur le +disque mais dans un état intermédiaire, à la fois plus sûre que la première +solution et plus rapide que la deuxième. Le CT a voté pour l'achat de disques +pour essayé de mettre en place cette solution. diff --git a/compte_rendus/2022_11_13.md b/compte_rendus/2022_11_13.md new file mode 100644 index 0000000..9eecd7f --- /dev/null +++ b/compte_rendus/2022_11_13.md @@ -0,0 +1,138 @@ +# IN du 13 novemebre 2022 + +## Présents + + * Pigeon Moelleux (secrétaire par intérim) + * Chiaroush + * Hachino + * aplanos + * esum + * shirenn + * vanille + * ynerant + * erdnax + * bleizi + * otthorn + +## Propositions projets apprentis + + * Tester sympa pour potentiel remplacement de mailman3 (nyaaa comme nom de +VM) (ynerant) + * Dégager la centralisation des logs sur tealc (shirenn + pigeonmoelleux) + * Créer un serveur de monitoring de test pour faire des tests sans polluer la +bdd de prod (shirenn + bleizi) + * Migrer les bases postgresql sur une VM (chiaroush + shirenn + esum) + * Installer un kanboard ((otthorn)) + * Installer un keyserver sur un (autre) LDAP (pigeonmoelleux + aeltheos) + * unattended-upgrades (bleizi) + * Dépôt APT pour !TheLounge + * Infra de test (ds-ac) + * Constellation (n'existe pas) (shirenn) + * Intégration de Prometheus et Ceph (aplanos) + +## Licence sur le dépot Ansible + +MIT + +On va demander aux concernés la permission : vulcain, grizzly et Fardale + +Normalement c'est ok + +## Pages persos + +On prévoit de brûler Apache un jour -> Nginx (il y a des failles partout) +Par la même occasion, plus de PHP + +`.perso.crans.org` à la place de `perso.crans.org/` ? + +## Centralisation des logs sur tealc + +C'était vu comme une avancée à une époque. +Ne sert à rien ? + +Conclusion : on le dégage. + +## Monitoring + +On déplace le monitoring de l'imprimante car on voit plus le reste ! + + -> #monitoring/imprimante + +## Hello world + +Ghostscript sur hello world (des fichiers de plusieurs GB) + +Problème confié à ynérant + +Des id note qui font crash /print + +## ldap-adm + +Changement de nom + +## Impression + + + +bleizi se charge d'acheter de l'encre noire + +## Adopte un pingouin + +L'admin est prévenue : on attend leur validation. +Il faut prévenir le Yang. + +## 25 ans du Crans + +On verra plus tard + +## Ceph + +Système de fichiers distribué sur le réseau, avec redondance + +Plusieurs serveurs auront les mêmes données de manière intelligente pour +pouvoir accepter de la perte + +''Fait de la magie'' + +### Achat 3e serveur de stockage + +On va débourser de la moula : +Environ 2 000€ HT + 1000€ de +disques (). +Voir en CA combien on est prêt à débourser + + + +### Version shirenn + +On met les serveurs de stockage sous Debian + +On fait des trucs que j'ai pas eu le temps de noter + ++ On fait des trucs avec les VLAN et du DNAT + ++ Ajouter deux moniteurs + +### Version esum + +Déployer ceph uniquement sur les serveurs de stockage + +Installer proxmox sur ces serveurs (jolie interface) + +Plus simple d'utilisation + +Même trucs fait avec les VLAN que shirenn + +(J'avoue j'ai pas trop compris la différence) + +### Questionnements majeurs + +Debian ou proxmox ? + +Les clusters proxmox doivent ils faire partie du cluster ceph ? + +Combien de FS ? (1 ou 4) + +''Insérer discussions techniques complexes'' + +''Insérer combat shirenn vs esum'' diff --git a/compte_rendus/2023_01_07.md b/compte_rendus/2023_01_07.md new file mode 100644 index 0000000..96ab736 --- /dev/null +++ b/compte_rendus/2023_01_07.md @@ -0,0 +1,114 @@ +# Réunion du Collège Technique + +* Date : Samedi 7 Janvier 2023 +* Lieu : Galène () +* Début : 22h +* Fin : 23h55 +* + +## Présent⋅e⋅s + +* ds-ac +* aplanos +* bleizi +* esum +* Otthorn +* Pigeon Moelleux +* shirenn +* vanille + +## Planning des IN et des CAs + +Le CA a proposé que le planning des INs / CAs soit le suivant. Un samedi soir +sur deux, une fois IN et l'autre fois CA. Cela semble satisfaire tout le monde. +Un frama sera envoyé pout fixer l'horaire. + +## Infra de test + +Arnaud --(a rien foutu)-- fait des petites choses et j'ai pas suivi ce qu'il a +dit au début. + +* ecilis : plan d'utiliser knot mais il faut modifier le script ldap pour que + la délégation ne marche pas +* plan de rajouter un ldap parcélaire : +* projet de stocker les certificats dedans + projet d'apprentis + +## Faille de sécurité du Crans + +''Vous pouvez circulez, tout se passe bien ici'' + + -> projet d'apprentis (et de moins apprentis (et de moinmoins + apprentis<>)) filtrer les chemins + +## Summers et fluxx + +Ce sont des VMs. + +fluxx -> Système de streaming ( <3) + +Conclusion : on garde + +Summers -> On ne sait pas à quoi elle sert ... + +Conclusion : on brûle + +## Ftp + +On en a à deux endroits : + +* Le FTP du crans +* Le miroir () + +Supprimer le support ? + +Oui + +## Tealc et sam vont chez le médecin + +Il faut racheter des disques pour tealc et sam. + +## Ceph + +''Débat entre esum et shirenn incoming'' + +Faire une migration petit format + +Zbee -> utilisation pour la migration en RAID ? / Plutôt utiliser du ceph ? + +Date précise à la prochaine IN + +## Unattended upgrade + +Des tests ont été fait par shirenn et bleizi +Il faut discuter des paramètres : + +* Reboot après MAJ du kernel ? Si oui avec quelles exceptions ? + * Oui pour certains, et on utilise "need-reboot" avec prometheus pour les + autres +* Restart des services ? Si oui avec quelles exceptions ? + * Oui au maximum (pas IRC par exemple) : liste exhaustive à définir + +## Mail 25 ans du Crans + +On enverra un mail demain (presque aujourd'hui) + +On annonce : + +* L'immolation par le feu de horde +* Nouveau système pour `https://perso.crans.org/`` + +''Une certaine sh***nn voulant rester anonyme aurait dit : 'Le PHP c'est trop +bien' '' + +* Date des 25 ans + +## HaveIBeenPwned + +On envoie des messages sur IRC et on évite les mails all (sauf si +concerne '''beaucoup''' de monde). + +## Mastodon + +Mise en place après la migration sur ceph diff --git a/compte_rendus/2023_02_04.md b/compte_rendus/2023_02_04.md new file mode 100644 index 0000000..f2e5a72 --- /dev/null +++ b/compte_rendus/2023_02_04.md @@ -0,0 +1,69 @@ +# Réunion Inter Nounous + +* Date : Samedi 4 Février 2023 +* Lieu : MB85 et Galène () +* Début : 20h15 +* Fin : 21h45 + +## Présents + +* Vanille +* ds-ac +* Bleizi +* Pigeon Moelleux +* shirenn +* Otthorn + +### Routage avec Aurore + +3 routeurs Crans, 2 routeurs Aurore + +En permanence un unique lien Aurore-Crans; délai sur la clôture quand on change +de routeur. + +Jeltz + shirenn + Ds-ac vont taffer. + +Setup de routage avec aurore, donner des ips uniques sur le lien pour maximiser +l'uptime et réduire les potentiels problèmes de coupures + +### Séminaires + +Point sur les séminaires + +* peu de public mais ok +* dèche de présentateurs + +Sujets qui mijotent: + +* Pare-feu & routage par ds-ac (Jeudi 16 Février) +* virtualisation +* ipv6 par Chiara + +Fonds pour grignoter après la fin du séminaire ? + +### Présence sur campus + +Pas trop technique mais je sais pas où le mettre : en fin d'année on risque de +ne plus avoir grand-monde sur le campus et ça peut poser souci pour intervenir, +par exemple sur l'imprimante. Exemple bête, mais comment le nouveau BDE compte +imprimer ses GdR ? EDIT : Je suis con, ce sont les livrets WEI qui sont +imprimés par le Crans habituellement, donc on s'en tape + +Plus généralement, quid d'une éventuelle intervention hardware pendant les +départs en stage ? + +Solal est sur le campus la majorité du temps. + +### Redondance de rate-limit + +Plusieurs rate-limits, est-ce que celle de Postfix est redondante ? => non + +### mailing list sans proprio + +On envoie un mail pour trouver un⋅e proprio et on supprime au bou d'un mois +sans réponse (ou on supprime direct si c'est pas possible de trouver un⋅e +proprio légitime) + +### Site de la SoNo + +site sono => on va le faire doucement diff --git a/compte_rendus/2023_03_04.md b/compte_rendus/2023_03_04.md new file mode 100644 index 0000000..ab1beba --- /dev/null +++ b/compte_rendus/2023_03_04.md @@ -0,0 +1,71 @@ +# Réunion du Collège Technique + +* Date : Samedi 4 Mars 2023 +* Lieu : MB85 et Galène () +* Début : 16h00 +* Fin : ~17h00 +* Pad : + +## Présents + +* Vanille +* shirenn +* ds-ac +* Aeltheos +* bleizi +* Solal +* esum + +## Ordre du jour + +### DKIM + +Observation: beaucoup de signatures DKIM sur un seul mail. Mailman signe le +même mail à de multiples reprises. De plus mailman.crans.org semble signer pour +crans.org ? Il ne devrait même pas avoir de clé. + +Cause du problème (identifiée pendant la séance): il y avait des bypass pour +auto-signer les mails transférés en interne, cela produisait des mails +avec 3 signatures dont la 3ème était automanique pour des mails envoyés depuis +une ML. + +Solution (implémentée pendant la séance): ne pas faire passer en interne les +mails concernés. + +### Kea + +Suggestion d'utiliser Kea () pour +remplacer notre actuel serveur DHCP qui est déprécié. Kea n'est pas encore en +production. + +Le mode de configuration a été examiné pendant la séance et semble à première +vue gérable et propre. Si nous migrons il est envisagé de (1) automatiser la +migration et (2) s'y prendre à l'avance pour avoir une transition sans délai. + +### Suppression d'utilisateurs + +Suite au mail annuel il y a eu 17 demandes de suppression de compte. + +Elles sont traitées manuellement mais il est discuté la possibilité de +permettre aux utilisateurs de supprimer eux-même leur compte. +En attendant il s'agit de garantir que la documentation des choses à supprimer +et comment est à +jour: + +NOTE: impossible de supprimer certaines informations de facturation +avant 10 ans. + +NOTE: s'assurer que les demandes de justification d'identité passent par un +canal privé plutôt que la ML de support technique. + +### VoIP + +Un utilisateur nous a demandé ce qui était advenu de +VoIP (cf: [[VieCrans/UtiliserVoIP]]. +Nous confirmons que ce service a été désactivé il y a un certain temps pour +cause de non usage et il n'est pas envisagé de le réactiver. + +### Servers: murozond et nozdormu + +Demande d'ajout de ces serveurs aux racks de ServENS. +Approuvée à l'unanimité. diff --git a/compte_rendus/2023_04_01.md b/compte_rendus/2023_04_01.md new file mode 100644 index 0000000..c9dbb65 --- /dev/null +++ b/compte_rendus/2023_04_01.md @@ -0,0 +1,61 @@ +# Réunion Inter Nounous + +* Date : Samedi 04 Avril 2023 +* Lieu : MB85 et Galène () +* Début : 12h00 +* Fin : 13h15 + +## Présents + +* ds-ac +* bleizi +* esum +* Pigeon Moelleux +* Otthorn +* Vanille + +## Ordre du Jour + +* users externes sur gitlab +* ceph +* formation aux outils du crans pour le nouveau BDE +* description du crans sur agenda du libre + +### Users externes sur gitlab + +Suite à un user voulant ajouter quelqu'un d'externe sur un de ses projets +''Discussion en cours'' +On accepte les users externes après mail aux nounous avec pour +pseudo `_external` +Gitlab a été upgrade + +### Ceph + +On attend la livraison des disques, et on attend la commande des disques +Si on reçoit les disques la semaine prochaine, on peut faire la migration dans +quelques semaines (21-22 avril ?) +Il faudra : setup le serveur + fix les disques de tealc et cameron + remplacer +les disques avec des secteurs deffectueux +Commande : 17 disques (15 de 2To et 2 de 3To) + +### Changer le disque de sam + +bleizi fait ça cet aprem + +### Formation Crans + +On enverra un mail au BdE pour faire venir tout le monde + +### Agenda du libre + +Changer ; + +* adresse mail : contact@crans.org +* description : à peu près "Le Crans est une association à but non lucratif + fournissant des services informatiques reposants sur des logiciels libres aux + étudiants et associations de l'ENS Paris-Saclay." + +### WireGuard + +Fournir un VPN à tous les adhérents par wireguard +Projet apprenti (s'il y en a ? :sob:) diff --git a/compte_rendus/2023_04_29.md b/compte_rendus/2023_04_29.md new file mode 100644 index 0000000..a1a39da --- /dev/null +++ b/compte_rendus/2023_04_29.md @@ -0,0 +1,63 @@ +# Réunion Inter Nounous + +* Date : Samedi 29 Avril 2023 +* Lieu : MB85 et Galène () +* Début : 13h00 +* Fin : 15h10 + +## Présents + +* bleizi +* Otthorn +* shirenn +* Vanille +* lzebulon + +## Ordre du Jour + +* ceph + Installé + surcoût de vis pour fixer les disques + carte réseau pas compatible +* [infra de test] retour sur le projet Certdap + + LDAP créé avec 3 apprenti.es +* [infra de test] Droits et apprenti·es + Donner les droits d'écriture aux apprenti.es ? Pb: l'infra apprentis sur + laquelle les apprentis sont roots est isolée, celle-ci non +* Mettre en place une instance Overleaf au Crans ? + Overleaf rendu open récemment: + Voir qui est l'analogue CNRS. Obstacles de + scalabilité ? À voir. +* Framaform + ça marche très bien chez framaform, c'est pas vraiment nécessaire de + l'importer +* Ménage dans les ML + Considérées utiles / périmées : -> c'est bleizi qui supprime + * achats-crans + * apprenti-es + * aurore-crans (garder les archives) + * blahblahlist + * bureau + * ca + * conduct? → En attente de la réponse de Pollion + * crous-crans (garder les archives) + * disconnect (brûler les archives) + * dsi-crans (garder les archives) + * federez (hors de notre contrôle) + * fin-de-connexion-imminente (pas d'archives) + * technique + * install-party + * mailman (bruler d'archives) + * moderateurs (brûler les archives) + * nounous + * orga-25ans + * paiements (garder les archives + aliaser sur tresorerie) + * paypal (brûler les archives) + * ripe → Ping Pollion + * roots + * test + * tresorerie + * urgent → jéjé kraft envoie mail → c'est pas le crans +* Problèmes IPv6 récents → non. (vérifier à la couche 8) +* -> prochaine IN diff --git a/compte_rendus/2023_05_27.md b/compte_rendus/2023_05_27.md new file mode 100644 index 0000000..1319715 --- /dev/null +++ b/compte_rendus/2023_05_27.md @@ -0,0 +1,50 @@ +# Réunion Inter Nounous + +* Date : Samedi 27 Mai 2023 +* Lieu : MB87 et Galène () +* Début : 21h10 +* Fin : 22h30 + +## Présents + +* Otthorn +* Vanille +* lzebulon +* Pigeon Moelleux +* Aeltheos +* Chiaroush +* ds-ac + +## Ordre du Jour + +* Retour sur le changement de disque de tealc +* Questions diverses + +## Changement de disque de tealc + +Le disque a été modifé mais n'a pas été intégré à la pool ZFS. +Il faut utiliser `zpool replace` et tout sera bon. +Tout a été réglé en direct. +Problème : il a fallu spécifier le paramètre "ashift" à la main + +(Not so) fun fact: + +Seul un paramètre ashift est valide + +> zpool aurait pu nous en dire plus, genre "attention, pas le bon ashift +gnagnagna, si tu veux faire caca, ajouter XXX à la ligne de commande." + +## Questions diverses + +### Mastodon + +On attend la migration de Ceph pour en parler + +### VPN adhérent + +Debian + Wireguard + Interface web +Sera fait un WE prochain en vocal sur galène + +### Information sur l'avancement des projets + +Wiki ? diff --git a/compte_rendus/2023_06_24.md b/compte_rendus/2023_06_24.md new file mode 100644 index 0000000..f696d6d --- /dev/null +++ b/compte_rendus/2023_06_24.md @@ -0,0 +1,158 @@ +# Réunion Inter Nounous + +* Date : Samedi 24 Juin 2023 +* Lieu : MB87 et Galène () +* Début : 15h00 +* Fin : 17h00 + +## Présents + +* Vanille +* Pigeon Moelleux +* bleizi +* ds-ac +* esum +* lzebulon +* Aplanos + +## Ordre du Jour + +* Belenios + * mise à jour de 1.15 à 2.1 ? + * on est très (trop ?) bien référencé, donc on a reçu un mail de qqun (pas + du tout membre) qui voulais faire une élection +* Discussion autout de la prochaine IP + * En faire une petite en septembre ou attendre les 25ans ? + * Motivation : certain·es profs / chargé·es de TD aimeraient que leurs + élèves soient un peu plus à l'aise sur leurs machines et cela permettrait + probablement de discuter des 25ans (et donc ne pas se retrouver sans jeunes +* Idée à discuter concernant les IPs: faire le séminaire "Bases d'Unix, Bash, + SSH" le matin +* Que faire des VMs en fin de vie ? On les débranche ou on les met sous + perfusion pour le reste de leur vie ? +* Cancel !ChanServ --(+ ptdr comment on est une divinité sur IRC ?)-- +* Migration à bookworm + * J[ds-ac]'ai vu une VM hung sur un prompt lié à bookworm ; c'est normal ? +* Migration à NixOS de certains services ? +* Une première VM sous Guix ? + * Question : comment ajouter une VM au LDAP sans faire crier Prometheus +* suite office sur owncloud + * + * + * (proposition d'ethercalc like avec option pour + read-only) +* Le Crans n'est pas listé comme fournisseur d'ethercalc sur le site Chatons +* Envoyer un mail à !ViaRezo à propos du peering BGP +* Problèmes récents au niveau des crons +* Point Ceph +* rezel qui peut pas se connecter à proxmox +* xmpp + +### Belenios + +* On a reçu un mail de qqn qui n'est pas lié au Crans souhaitant administrer + une élection sur belenios. +* Il faut changer le message d'accueil pour bien spécifier que ce service est + réservé aux adhérents du crans à la 2e ligne. + +(2ème ligne dit "si vous n'avez pas de compte contactez-nous", ça sous-entend +que n'importe qui peut obtenir un compte juste en nous contactant...) + +* On en profite pour faire une MAJ (de belenios et de la VM) + +### Install Party + +* Faire install party et/ou séminaires bash, Unix et SSH vers fin septembre +* On prévient les départements, en particulier EEA et info et on demande de + faire de la pub + +### VM adhérents + +On tue les VMs en fin de vie + +* VM adhérent: mail, brûler. +* 1 mois après la fin de l'adhésion : on l'éteint +* 2 mois après la fin de l'adhésion : on supprime le disque + +### ChanServ + +--(Il est en sursis.)-- + + + +### Bookworm + +* Bullseye est mort. Longue vie à Bookworm ! +* Proxmox : + * Normalement les upgrades devraient bien se passer + * D'abord les services, puis les proxmox et on attend ceph pour les stockages + * Proxmox : les mettre à niveau un par un. + +### NixOS & Guix + +On teste de passer qq services sur NixOS car c'est plus simple à prendre en +main que Ansible + +* NixOS + * Gitlab + * IRC + * Zero + * Ethercalc ? + * Roundcube + * !NextCloud ? + *Avec !OnlyOffice ? +* Guix + * Non : pas plus de deux OS au Cr@ns => Nix plutôt que Guix (nombre de + paquets disponibles). + +### Owncloud, NextCloud + +* On passe sur !NextCloud ? +* Est-ce que la migration se fait bien du point de vue utilisateur ? +* On garde les deux un moment puis on coupe Owncloud au bout d'un moment. +* On intègre !OnlyOffice avec, et on invite les gens à migrer de ethercalc + +### Ethercalc + +[Cf Owncloud/NextCloud] + +* Pour être un chaton, il faudrait chiffrer tous les disques. +* Les disques de stockage de Cephiroth sont maintenant chiffrés +* On va devoir camper en SQ39 pour faire des trucs +* On est pas obligé d'être listé comme un chaton à la vue des contraintes que + cela génère + +### BGP ViaRézo + +bleizi s'est désigné pour envoyer un mail pour dire que tout est cassé + +### Cron + +Caca --(créé et)-- résolu par shirenn (''merci <3'') + +### Ceph + +''Ça commence à faire longtemps qu'on en parle, ça arrive bientôt'' + +* L'intégration de ceph sous NixOS est pas encore très mature donc on va rester + pour l'instant sur debian +* Cephiroth est installé avec les paquets ceph +* Il faudrait installer au moins un autre serveur au cluster pour que Cephiroth + ne soit plus en état "dégradé" +* Il faudra migrer les disques des VM crans sur ceph -> ... -> intégrer tealc + au cluster + +### Rezel + +* On a migré leur VM et elle est toute cassée, et ils ont pas accès à + l'interface proxmox. +* On leur crée un compte adhérent gratuitement, on leur reset leur MDP par mail + puis ils peuvent faire ça en passant par zamok. + +### xmpp + +* Question d'un ancien pour savoir si on avait un serveur XMPP +* Il y a autant d'utilisateurs de xmpp que de Guix -> donc non + ''Ça veut dire que je [ds-ac] ne suis plus tout seul à utiliser Guix au + Cr@ns ?'' + ''Yes, trop bien !'' diff --git a/compte_rendus/2023_09_23.md b/compte_rendus/2023_09_23.md new file mode 100644 index 0000000..fa79555 --- /dev/null +++ b/compte_rendus/2023_09_23.md @@ -0,0 +1,178 @@ +# Réunion IN + +## Réunion nounou + +* Date : Samedi 23 Septembre 2023 +* Lieu : MB87 et Galène () +* Début : 17h00 +* Fin : 18h53 + +### Présent⋅es + +* aeltheos +* Aplanos +* bleizi +* ds-ac +* esum +* GaBo +* Hachino +* hugoooo +* lzebulon +* Shinigami +* shirenn +* Vanille + +Et les 1A alors ? Ils existent et on les apprécie beaucoup. Vive la jeunesse. + +### Ordre du Jour + +* problèmes matériels + * RAM de tealc + * disque de thot -> 2TB SAS HP +* réparations/améliorations logicielles + * authentification sur pve-adh + * privilèges de lecture de mails sur zamok + * gitlab + * backups plus économes + * modération de la ML CA +* amélioration de la documentation et du logging + * regrouper les mails de Cron (*ahem* j'ai 23224 mails non lus de Cron dans + ma boîte mail...) + * lister proprement les services selon le critère "est-ce que c'est ok de + les éteindre et redémarrer" + * point sur la coupure de tous les services forcée par l'ENS + * accueil des nouveaux et nouvelles + * succession prochaine du CT +* divers + + home, vanille, aplanos + +### Accueil des nouveaux et nouvelles + +Tour de table pour que tout le monde se présente. Tout le monde est jeune, +c'est parfait. + +### Tealc + +Erreur de RAM -> Redémarrage -> Réparé #!DansLeDouteReboot + +### Disque de thot + +Il faut un disque HP de 2To en SAS + +sam a aussi des smart error sur un disque, prendre un HP 1TB + +je (aeltheos) passerais une liste des reférence. + +### Authentification sur pve-adh + +Modifications faites sur le script -> Permettre d'avoir des tokens d'API (en +discussion) et corriger qq droits d'accès + +### Lecture des mails sur zamok + +Tout le monde peut lire sur mailq (au pire, tout le monde peut savoir qui a +communiqué avec qui) + +Correction cf + +esum s'en occupe + +Ça marche pas, tristesse. + +### gitlab + +Reporté à quand Otthorn sera là + +Mise à jour 16.4 par bleizi + +### backups + +Reporté à quand Otthorn sera là + +### Modération de la ML CA + +Actuellement pas de modération pour les mails du Crans + +On passe en modération + +Suggestion : signaler sur signal-spam => non. + +### Regrouper les mails de cron + +Globalement non + +Il faut filtrer les mails + +Ceux qui lisent pas tous leurs mails sont cancels + +### Lister les services à redémarrer + +Cf. + +### Point sur la coupure de tous les services forcée par l'ENS + +RAS. + +### accueil des nouveaux et nouvelles + +Coucou ! + +aeltheos + +* projet Ceph +* HA sur les services critiques postgresql / openldap + +esum, shirenn, aeltheos, pigeonmoelleux + +* ansible -> nixos + utiliser des flakes + +Question : toutes les parties de nos configurations et fichiers Ansible qui +vont chercher dans le LDAP/le pass/les variables d'hôte sont récupérées quelque +part + +Réponse : c'est pas l'heure. Pour le moment, l'idée est juste d'avoir un +playbook root fonctionnel (pun intended haha <3) + +shirenn, aeltheos + +* upgrade debian : bullseye -> bookworm +* playbook root -> crans + +ds-ac, aeltheos, (vanille? : c'est lui qui a déployé radius il me semble) + +* Routeur 27-54 + +vanille + +* Constellation <3 -_- mais si tu es motivé ! je t'assure ! +* L'imprimante du Crans ? Elle charge des docs identiques N fois au lieu de les + charger 1 fois + copier l'instruction "imprimer". C'est très con. Entre + autres joyeusetés à améliorer (on parle même pas du statut de la BU ou de + l'imprimante post-Lumen, ni de celle de Cachan). + +### succession prochaine du CT + +Rappel: + +Au Cr@ns (enfin au CT (Conseil Technique) du Cr@ns), il y a : + +* des apprentis +* des nounous (qui prennent soin des serveurs (et des apprentis)) +* une nounou particulière : la maman des serveurs + +La maman est président·e du CT. + +Un·e apprenti·e peut devenir nounou. Cela se fait souvent après un projet +encadré. + +La maman va mourir, trouvons quelqu'un pour adopter ses petits. #Bambi + +### divers + +DsAc veut pousser pour du DANE pour certbot : +Crochets d'authentification pour Certbot : +scripts en bash → garder des scripts en Python. + +home, vanille, aplanos : +Il y avait un pb d'UID dans le LDAP. C'est corrigé. diff --git a/compte_rendus/2023_10_21.md b/compte_rendus/2023_10_21.md new file mode 100644 index 0000000..ea6da17 --- /dev/null +++ b/compte_rendus/2023_10_21.md @@ -0,0 +1,154 @@ +# Réunion nounou + +* Date : Samedi 21 Octobre 2023 +* Lieu : 1N82 et Jitsi () +* Début : 18h10 +* Fin : 19h35 + +## Présent⋅es + +* Aplanos +* bleizi +* ds-ac +* esum +* GaBo +* Hachino +* lzebulon +* Vanille +* RedDiamond +* Serenilink +* Pigeon Moelleux + +## Ordre du jour + +* pb de connexion +* pb de mot de passe/clé ssh +* discussion fail2ban / crowdsec pour gitlab +* passer le màj en « je fais que les updates de sécu » +* mailman avec le module sieve (pour les filtres mails) +* Projets apprentis: + * WG : permettre aux gens de se faire un bloc de config de WG + * Galène : front-end pour parler LDAP : autoriser la création de + groupes "frais" (la personne créant le groupe est "créateurice" et peut + supprimer le groupe, modif les options, ...) +* [ds-ac] Questions aux nixien·nes : + * y a-t-il un équivalent à "guix deploy" dans nix, et est-ce qu'on a une + chance de l'intégrer avec Proxmox ? Si oui, est-ce que unattended-upgrades + est impacté ? + * comment étendre Nix, au sens définir des fonctions maison, qui peuvent + être impures (e.g. pour lookup dans un ldap lors du (re)déploiement d'une + machine) ? +* [Pigeon Moelleux] BdE et Intel Unite +* [ds-ac] esum: quels changements sur IRC (réduction du spam) + +### Problèmes de connexion + +LE CRANS EST DOWN ! Longue vie au Cr@ns ! + +On timeout dans tous les sens ! Mais c'est pas notre faute ! +Aurore répare le problème bientôt. + +Sputnik est utilisé pour faire transiter le web (à la place de hodaur) + +Mailq a été augmenté à 10 jours pour pas perdre de mails. + +Activation du slow sur le postfix de mailman3 + +On enverra un mail all quand tout sera réglé + +Revoir la communication d'erreurs + +### Problèmes de mots de passe / clef SSH + +Des mots de passe ont fuité sur le gitlab + +Les mots de passe ont été changés par esum et shirenn + +Le pass a été rechiffré plusieurs fois + +### Discussion fail2ban / crowdsec pour gitlab + +On demandera à Solal quand on le verra. + +### Passer les MAJ en "Je fais que les updates de sécu" + +Est-ce qu'on le fait ? + +On attend que shirenn soit là pour en parler. + +### Roundcube avec le module sieve + +Demande de transformer la façon dont on gère les mails (étendre la gestion de +dovecot) + +ds-ac pop un serveur mail sur test.crans.org + +''Je vais l'appeler : mx47.test.crans.org'' + +Faire attention aux logs des tests + +### Projets apprentis + +#### WG : permettre aux gens de se faire un bloc de config de WG + +esum a un ancien petit projet en Django pour gérer du Wireguard à distance par +les adhérent⋅e⋅s + +Django app + +* le front-end gère la partie "qui a le droit de faire quoi?" +* subprocess -> utiliser `wg-tools` pour parler à WG + +#### Galène + +Front-end pour parler LDAP : autoriser la création de groupes "frais" (la +personne créant le groupe est "créateurice" et peut supprimer le groupe, modif +les options, ...) + +Problème : comment contrôler les accès aux salles + comment gérer les conflits +entre salles ? + +Regarder avec les sous-groupes + +Django app + +* le front-end gère la partie "qui a le droit de faire quoi" +* modifier un LDAP d'auth pour Galène derrière + +#### Wiki + +Connecter la Note au wiki + +Qui veut faire du Python 2 ? + +Aucun wiki ne correspond à nos attentes pour l'instant + +Ça ne réglera aucun problème au niveau intérêt des gens pour le wiki + +#### Intel Unite + +Refaire un Intel Unite version Crans ? + +Demander le cahier des charges au préalable + +Peut-être faire un hackathon ? + +On va demander à Erdnaxe si ce qu'il en pense. + +Si l'ENS nous demande, on va y réfléchir un peu, pour le BdE on dit non. + +### Nix + +#### NixOS deploy + +Équivalent de guix deploy : demander à aeltheos +Serveur de cache au Crans + +#### Utilisations de fichiers hors config + +Il vaudrait mieux mettre tout dans la config nix quitte à changer un peu notre +infra + +### Spam sur IRC + +On n'y peut pas grand chose (et il y a genre ~1 bot par semaine). diff --git a/compte_rendus/2023_12_02.md b/compte_rendus/2023_12_02.md new file mode 100644 index 0000000..08c3d31 --- /dev/null +++ b/compte_rendus/2023_12_02.md @@ -0,0 +1,248 @@ +# Réunion du Collège Technique + +* Date : Samedi 2 décembre 2023 +* Lieu : MB87 et Galène () +* Début : 20h22 +* Fin : 22h54 +* + +## Présent⋅es + +* Aplanos +* Korenst1 +* GaBo +* Hachino +* Vanille +* RedDiamond +* Pigeon Moelleux +* bleizi (arrivée à 21h15) +* Petit Gaga (???) (En post-Quill) + +## Ordre du jour + +* Réplication de la BDD gitlab (car elle est créée par gitlab, voir avec + shirenn) +* [bleizi] rendre inactifs les compte que l'on arrive pas à contacter par mail +* [bleizi] signer dkim les mails de re2o +* [shirenn, bleizi et ds-ac] redirection des mails depuis zamok vers redisdead +* [bleizi] crans OID + +* [bleizi et shirenn] SPF pour les mails sur redisdead : retour sur la mise en + place + est-ce qu'on est plus restrictif (drop des fails) ? +* [Pigeon] Dovecot sieve pour le tri des mails dans les sous-dossiers pour tous + les adhérent⋅e⋅s utilisant leur adresse mail crans +* [bleizi] c'est quoi ? +* [ds-ac] faire un mini tuto install Debian avec + gpt-auto-generator + systemd-growfs-root pour les VMs adh +* [ds-ac] mailman et spam from self : whitelists trop permissives ? +* [Hachino] [Un peu HS] Le hotspot eduroam de l'ENS marche pas quand t'as une + adresse/un compte hors ENS. :( (Testé avec Hachino et 20-100.) Quelle est la + bonne façon de contacter la DSI pour leur en parler ? +* [Hachino] Randomly, 20-100 vient de découvrir que la fonction "Ajouter un + commentaire" de Framadate est cassée. Qué pasta ? + +Trucs à pas oublier : + +* Contacter la DSI pour du RADIUS +* RALLUMER LES BACKUPS SUR NETNS, ZAMOK-MYSQL ET LINX + +## Dovecot sieve / Procmail + +Possibilité de définir un sieve par utilisateur ? + +"Est-ce qu'on utilise Dovecot au Crans ?" --> Après recherches, oui, mais "il +est planqué où ?" [Ça se voit que l'IN manque de gens là ?] + +Pigeon a trouvé, victoire ! "/etc/dovecot/conf.d/90-sieve.conf" + +Conclusion : + +* Vanille est choqué par le MOTD de Owl. À raison. +* Les gens apprennent à proxy jump +* on testera ça la prochaine fois qu'on casse les mails +* !GaBo demande où sont les adultes. Réponse : nulle part. +* ds-ac devait faire une VM sur l'infra de test et les membres actifs devaient + faire des tests. Bon bah plus tard alors. +* bleizi pose la question de l'expressivité de Dovecot. Pigeon affirme que + Procmail est strictement moins puissant que Dovecot et donne l'exemple des + messages d'absence/réponses automatiques/regex (Aplanos est très bruyemment + contre les regex). + +''On remarquera que le compte rendu n'est pas linéaire car certains points ont +été abordés plusieurs fois'' + +## Point DSI + +Les comptes non ENS ne fonctionnent pas sur eduroam. + +Hachino s'en charge. Un jour, insh'. 2ème étage, couloir 2[A-Z]82 d'après !GaBo +et Pigeon. + +L'espoir est très très mince. :( + +## Point Regex + +À l'aide + +## Point SCP (à l'intérieur du point Quill) + +Après avoir bifurqué sur Quill, Pigeon en arrive à une murder SCP qu'il écrit +avec Charsle. Korenst1 est perdu par ce qu'est SCP. + +S'ensuit une explication succincte de Pigeon. + +## Framadate + +Pigeon vient de le vérifier : le bouton "Ajouter un commentaire" est un +mensonge. + +Personne ne sait où sont les logs de framadate, on remet le point à la +prochaine IN. + +## Les autres points + +Il manque les gens qui les ont ajoutés à l'ODJ. Derp. Ce sera pour l'IN de +décembre. Bon allez, on essaye quand même. + +## Point Pass + +Pigeon explique le principe de GPG et de Pass. + +''Puis bleizi arrive, c'est un miracle !'' + +## Points messages de Pigeon + +* Aurore est très fortement sous l'eau, "plus que la DSI". 90% du taf est fait + par Jeltz, 5% par Lucas "Tavary-Maujean" et 5% par Vincent Lafeychine. +* Anim[ENS] se plaint de la qualité de service de Galène (vs Ghostream) et + demande la résurrection de Ghostream. Pigeon sait faire et s'en occupera + lui-même, vu sa proximité avec Anim[ENS] (au hasard). + +## Réplication BDD gitlab + +On backup certains trucs de gitlab mais pas sa BDD. Elle n'est backup que +pendant les MAJ gitlab (~1 fois/mois), il faudrait le faire automatiquement. + +Gitlab est un énorme pâté qui installe tout seul les paquets dont il a +besoin (et possiblement sa BDD). + +On attend shirenn pour voir ça. + +## Comptes non contactables + +On refuse de regarder le .forward des gens. + +Possibilité : envoyer un mail aux gens "hey, ton compte semble inactif, si tu +réponds pas d'ici X mois [X entre 1 et 6], on va l'archiver". Rien d'urgent +ceci dit. + +## Signature DKIM + +Signature faite par le serveur mail (redisdead au crans). + +Les mails envoyés par Re2o ne sont pas signés par DKIM, donc en +principe "suspects" (mais mieux vaut pas signés que mal signés). + +Peut-être qu'un jour les Gafam (Gmail en tête) vont mettre en place des +politiques plus strictes et les mails pas signés DKIM partiront par défaut en +spam. Gênant. Pour l'instant c'est pas le cas. Sont concernés notamment les +mailall annuels et les mails de confirmation d'inscription. + +Les mails ne sont pas signés DKIM quand ça passe par Redisdead et faudrait +enquêter pour savoir pourquoi. +Gitlab envoie des mails signés DKIM, Owncloud non (mais franchement, pour OC on +s'en tape). + +Personne de présent n'est volontaire pour regarder ça en profondeur. bleizi +propose la bouteille à la mer sur #roots (aled). + +Retour de la bouteille à la mer post réunion : + +* ''Au lieu que re2o envoie les mails lui même tu fais un nullmailer qui lui + dit que c'est un autre serveur qui envoie les mails ?'' (Otthorn) +* ''la solution simple (et sale) c'est de faire du submission avec le compte de + root'' (shirenn) +* ''l'autre c'est de dire à opendkim que quand les mails viennent de l'ip du + serveur de re2o il faut les signer'' (shirenn aussi) +* ''Bah re2o pourrait pas juste avoir son propre compte mail et envoyer des + mails comme tout le monde ?'' (Mikachu) + +## Mails Zamok -> Redisdead + +Quand un mail arrive pour le Crans, il passe par Redisdead, normal. Puis ça +passe par Zamok, qui stocke les mails des gens. Dans certains cas, les gens ont +des .forward vers une adresse extérieure (serveur perso, Gmail, ça dépend). Ça +fait beaucoup d'allers-retours. bleizi a oublié la conclusion de la réflexion, +mais ça a l'air sous-optimal. C'est bien noté. + +Un des soucis : les headers s'empilent à chaque redirection. + +L'idée serait de faire en sorte que Redisdead, plutôt que Zamok, lise le +.forward des gens. + +## Crans OID + +Le nom n'est pas le bon sur le lien (Stéphane Glondu, wouhou). Tout le monde +s'en tape, GG. + +En fait non, bleizi réfléchie à changer les infos, mais il faudrait voir qui +reçoit les mail sur oid-admin@crans.org + +## Point 'hosts' + +La génération du DNS est faite en regardant le LDAP et tous les trucs du LDAP +sont dans ou=hosts. + +## Point SPF + +SPF = Standard policy framework. Sert à faire de la sécurité sur les mails. + +Principe : vérifier que le Mail From et le serveur qui envoie le mail sont les +mêmes. Il paraît que les usurpations c'est pas bien. + +On peut donner au DNS (par le LDAP) la liste des serveurs qui ont le droit +d'envoyer des mails au nom du Crans. À la fin tu peux mettre un "All" pour dire +que tout le monde a le droit, un "-All" pour nier le droit et un "~All" pour +dire "c'est pas normal, mais on laisse passer quand même". + +Pigeon trouve un "~All" dans un champ txt. Les seuls serveurs enregistrés pour +le Crans sont Redisdead et Soputnik, mais pas Zamok. +Dans le txt, il y a deux IPv4 et deux IPv6 (on suppose que c'est Redisdead et +Sputnik). Les MX sont bien eux. + +Si on lit les headers d'un mail récent du Crans, genre celui que Pigeon envoie +exprès à bleizi dans la minute, on peut s'apercevoir qu'il s'agit d'un mail de +Q. De qanon@crans.org, pardon. Quand c'est signé DKIM, on lit pas les SPF parce +qu'on fait confiance. + +bleizi poste un exemple d'analyse SPF venant de chez shirenn. + +```bash +{{{ +Authentication-Results: redisdead; spf=softfail (domain owner discourages use +of this +host) smtp.mailfrom=gmail.com (client-ip=REDACTED; helo=abys.se; envelope-from=shirenn@gmail.com; receiver=) +}}} +``` + +Proposition de nouvelle politique : si fail (hardfail, pas softfail), alors +drop le mail. Est-ce qu'on veut implémenter ça ? Débat. L'idéal serait de +laisser passer le mail en informant les destinataires, mais + +* personne de normalement constitué (même pas au Crans) ne lit les headers de + ses mails; +* scripter une modif du mail (type ajouter '[*** SPAM ***]' au début de + l'objet) c'est techniquement chiant à faire, donc flemme. + +Par défaut, on laissera passer les mails quand même. Plus tard, quand SPF sera +plus répandu et/ou que les Gafam imposeront leur loi, peut-être qu'on changera +d'avis. + +Pigeon et Aplanos proposent de ressusciter la Stasi en censurant a priori tous +les mails. La motion est rejetée à l'unanimité. + +## Hosts.crans.org + +Ça héberge un Django en debug. Personne ne sait ce qu'il devrait y avoir à la +place. Un ssh fait tomber sur Hodaur, mais c'est normal. On demandera à de +vieilles nounous si elles savent. Il est probable que ce site ne serve à rien. diff --git a/compte_rendus/2024_02_10.md b/compte_rendus/2024_02_10.md new file mode 100644 index 0000000..44a7faf --- /dev/null +++ b/compte_rendus/2024_02_10.md @@ -0,0 +1,127 @@ +# Réunion IN + +* Date : Samedi 10 Février 2024 +* Lieu : MB87 et Galène () +* Début : 15h17 +* Fin : 18h41 + +## Présent⋅es + +* bleizi +* Pigeon Moelleux +* GaBo +* ds-ac +* Chiaroush +* Hachino +* esum +* Korenst1 +* lzebulon +* RDB +* Milo +* Emett + +### DNS et DNSSEC + +ds-ac fait une présentation aux apprenti⋅es en l'absence de shirenn + +### Mailman + +#### Spams + +On voit plus tard. + +#### Faux comptes + +Il y a apparemment des faux comptes, il faudrait peut-être les supprimer. +Ce sont apparemment des non-membres. +Ce sont des personnes ban donc il ne faut à priori pas les supprimer. + +#### Thème + +Le thème de mailman est cassé, il faudrait le changer/réparer. +On demandera à Solal. + +### Belenios + +Il faut brûler la VM et réinstaller bélénios depuis 0. +Ce n'est pas grave car il n'y a aucune donnée sauvegardée sur bélénios. + +### DANE + +ds-ac fait une présentation avec plein de trucs sur la sécurité des mails + +### ds-ac + +ds-ac fait une présentation rapide de tous ses points à l'ordre du jour. + +### systemd + +Re-centralisation des logs ? +Il faudra demander à shirenn pourquoi la décentralisation des logs. + +### Ajout security.txt + +Après quelques minutes de discussion, on s'est accordé sur le fait qu'on +ajouterait pas de security.txt (contrairement à internet.nl, google, amazon, +...). + +## Je suis curieux d'entendre les arguments, c'est possible de détailler ? + +Pour : + +* il serait possible de nous signaler des failles de manière standardisée + +Contre : + +* on a rien à offrir pour la découverte de nos failles (contrairement aux GAFAM + cités précédemment) +* ça partage une/des adresses à un endroit facilement trouvable par des bots +* si vraiment qq'un veut nous contacter, c'est pas si compliqué que ça de + trouver une adresse +* ça demande un peu de travail à mettre en place + +### Mails + +(J'ai l'impression que ça casse toutes les heures à ce stade.) +Petite explication par ds-ac de ce qu'est le smuggling, et de pourquoi c'est +dangereux et comment ça a été réglé. +Le problème n'est pas encore réglé sur zamok. + +### Gitlab + +On est ok pour installer les gitlab-pages. Ce sera fait dans quelques semaines +avec des apprenti⋅e⋅s. +Pour les runners, ça a l'air d'être bon d'une manière générale : pas besoin +d'en rajouter. + +Nouvelle mise à jour : est-ce qu'on force le 2FA pour les admins (nounous) ? +Globalement pour : ça a été activé. +Finalement, on l'a désactivé, on en reparlera entre les nounous. + +### Infra de test + +Il faut un VLAN dédié pour : + +* ne pas avoir à s'inscrire dans l'infra de déploiement du crans quand on fait + une VM (LDAP, ...), +* éviter que les VMs aient un accès à adm. + +NB : que faire des "home" nounous ? +On mettra la VM apprenti⋅e⋅s dans ce VLAN de tests. + +### Mailman + +On interdit à tout le monde sauf à mailman et sputnik d'envoyer des mails pour +lists.crans.org. + +> ajouter "-all" à notre champ SPF (TXT lists.crans.org) + +### NixOS + +Pigeon Moelleux décrivait ce qui a été fait sur NixOS au Crans le mois dernier. +Il a également été décidé que le git NixOS ne serait pas public. + +### Zero + +On mettra à jour le zero avec des changements gittés à partir du dépôt +original en faisant des rebase pour mettre à jour. diff --git a/compte_rendus/2024_03_02.md b/compte_rendus/2024_03_02.md new file mode 100644 index 0000000..cba4af6 --- /dev/null +++ b/compte_rendus/2024_03_02.md @@ -0,0 +1,101 @@ +# Réunion du Collège Technique + +* Date : Samedi 2 Mars 2024 +* Lieu : MB87 et Galène () +* Début : 13h37 +* Fin : 16h00 + +## Présents + +* bleizi +* GaBo +* ds-ac +* Chiaroush +* vanille +* Shinigami +* Hachino +* Korenst1 +* lzebulon +* shirenn + +## Ordre du jour + +* Nouvelles nounous +* Réparation de Cephiroth +* Moyen de contact indépendant du Crans +* Nombre maximum d'alias mail sur Re2o +* Le Wiki n'affiche pas correctement certaines images +* Question sur les patches Nix + +## Réunion + +### Nouvelles nounous + +Les membres suivants sont déterminés aptes à devenir nounous: + +* gabo +* korenstin +* lzebulon + +Cela sera officialisé à une occasion prochaine. + +### Cephiroth + +(Point soulevé par bleizi) + +Il y a de la casse, consulter l'égilibilité de la garantie. +(facture sur tresorerie le 28/12/2022) + +### Moyen de contact + +(Point soulevé par bleizi, suite à un signalement adhérent) + +Particulièrement suite à une coupure de service indépendante de nous (problème +technique chez Aurore) qui a rendu plusieurs services (dont les +mails) indisponibles pendant un temps, un adhérent a émis une suggestion qui +avait déjà été envisagée il y a longtemps: avoir une présence sur +Facebook/Mastodon/assimilé pour annoncer de tels évènements lorsqu'il sont +détectés et que nous n'avons pas eu le temps de les annoncer en avance. + +Plusieurs obstacles sont relevés, dont principalement le fait qu'avoir un tel +compte nécessite pour qu'il soit utile que + +* les utilisateur.ices soient au courant de son existence +* il y ait une activité fréquence (annoncer les autres évènements tels que + séminaires et install parties) + +Bref cela nécessite un investissement régulier. +Le manque de motivation est jugé principal facteur bloquant et nous considérons +que modulo une mise à jour l'existence de la page +est une solution suffisante et beaucoup moins contraignante. + +### Nombre maximum d'alias + +(Point soulevé par bleizi, suite à un signalement adhérent) + +Reçue une plainte que le nombre maximum d'alias mail réservables par une +personne (15) est insuffisant. +Nous n'adhérons pas à ce point de vue, surtout parce que chaque alias est un +point en moins disponible dans l'espace des pseudos valides. + +Si l'objectif est de pouvoir utiliser des adresses mail "jetables", une +solution envisageable pour peu qu'un membre trouve le temps de l'implémenter +serait de réserver un préfixe jetable, et par exemple garder le cap de 15 alias +standards mais 1000 alias parmi les adresses qui commencent par "u_". + +### Chargement des images sur Wiki + +(Point soulevé par korenstin) + +Certaines images ne chargent pas. +Le nombre est fixé mais les images spécifiques ne sont pas déterministes. +Le problème est identifier comme venant du paramètre "burst limit" (défini dans +nginx/sites-enabled/wiki pour faire face à un scraper), maintenant augmenté +de 10 à 100. + +### Patches Nix + +(Point soulevé par ds-ac) + +En l'absence de personnes qui connaissent bien Nix, cette question est +repoussée à la prochaine IN. diff --git a/compte_rendus/2024_04_06.md b/compte_rendus/2024_04_06.md new file mode 100644 index 0000000..b4a81c9 --- /dev/null +++ b/compte_rendus/2024_04_06.md @@ -0,0 +1,97 @@ +# Réunion IN + +* Date : Samedi 06 Avril 2024 +* Lieu : MB87 et Galène () +* Début : 14h25 +* Fin : 17h27 + +## Présent⋅es + +* bleizi +* Pigeon Moelleux +* GaBo +* ds-ac +* Hachino +* lzebulon +* shirenn +* Vanille +* aeltheos +* Shinigami +* shirenn +* RDB + +### Cephiroth + +Ça a pas avancé. + +C'est toujours cassé, il ne boot pas du tout. Il faut le renvoyer en récupérant +la carte réseau et les disques. + +### Miroirs + +Ils envoient des mails. C'est un problème logiciel : il faudrait augmenter une +limite pour une fois, puis tout remarchera. + +### Ft + +Serveur de backup chez !ViaRezo : il est cassé. --(On)-- !GaBo va envoyer un +mail. + +### Postfix + +Il faut mettre à jour postfix sur zamok et sputnik. + +NB : les settings par défaut fixent le pb de sécu mentionné il y a 3 mois (il +faudra peut être retirer des options ajoutées en janvier). + +### Grafts + +Guix -> Grafts -> Gestionnaire de packages fonctionnel (ne dépend que des +entrées déclarées). + +Pas besoin de world build en utilisant des caches -> on aura pas de maj (pas +les substituts) pendant qq jours. + +### Unattended upgrades + +L'intégration dans Nix ne nous intéresse pas, car elle est faite pour gérer les +paquet apt (et si on utilise apt, on est avec debian et pas avec NixOS). + +### Documentation + +IL FAUT FAIRE DE LA DOC. + +On héberge un wiki engine sur une VM NixOS. + +Projet apprenti/jeune nounou. + +Penser à faire un !HowToDocumentation (fait par Pigeon) avec un nombre maximal +de caractères par ligne. + +### NextCloud + +Applications à mettre : Fichier, photo, activité, agenda, contact, +audio-player, annonce, tache, onlyoffice (mais on a pas encore de backend) + +Applications pas à mettre (pour le moment, à demander à des +utilateurices/vieux) : deck (kanban), cospend, notes + +### Matrix + +Aeltheos at Chiaroush veulent faire un projet apprentis sur Matrix avec +NixOS -> OK, si il y a pas de pub du service et qu'il y a une documentation +détaillée, plus pour voir comment faire et faire de la doc que d'avoir un +nouveau service. + +### Faire pop des VM + +aeltheos essaiera de faire un script pour aller écrire dans le LDAP. + +Pigeon Moelleux se chargera de la documentation. + +### Mises à jour de sécurité sous NixOS + +Gitlab action qui met automatiquement à jour la flake ? + +On fera une VM qui build tous les dérivations nix et qui se chargera des remote +build. diff --git a/compte_rendus/2024_05_11.md b/compte_rendus/2024_05_11.md new file mode 100644 index 0000000..d3a28f3 --- /dev/null +++ b/compte_rendus/2024_05_11.md @@ -0,0 +1,99 @@ +# Réunion IN + +* Date : Samedi 11 Mai 2024 +* Lieu : MB87 et Galène () +* Début : 13h58 +* Fin : 16h25 + +## Présent⋅es + +* bleizi +* Chiaroush +* ds-ac +* floflobouf +* !GaBo +* Hachino +* Korenst1 +* Otthorn +* Pigeon Moelleux +* shirenn + +### Discussion autour du DHCP + +Présentation de shirenn (merci !) + +### Tiers listes de spam + +L'idée est de faire une tiers liste de spam. + +shirenn propose de le faire lorsqu'il y aura (enfin) un antispam + +### Où sont les disques ? + +Il faudrait acheter des disques. +Ça fait plus de 8 mois, faut se grouiller ! +Il faut juste transmettre la liste des références des disques à acheter. + +### Fyre remplis beaucoup ces disques + +Disques pleins car logs ne sont jamais effacés. (actuellement ~250Go de logs et +sauvegardes) + +Est-ce une feature ou un bug ? +Ce qui pose la question : Est-ce qu'on ajoute des disques ou on corrige se +problème ? + +Une limitation de taille disque à la taille actuelle du disque sera +instaurée -> 200 Go. + +Ottorn et !GaBo s'en chargent juste après l'IN (<< c'est une seule ligne >>). + +### Mail de rappel lors de la fin de l'adhésion + +Ce serait pratique ! +Il y avait un envoi de mail lors de fin de connexion mais pas en fin +d'adhésion. À Cachan adhésion == connexion mais ce n'est plus le cas. +Donc on n'y avait pas pensé. + +Peut-être pas pris nativement. Si c'est pas le cas il faudra aller coder un +truc. + +### Appli mobile nextcloud et dossier pour les 30Go + +Il n'est pas (facilement) possible de se connecter à Nextcloud avec l'appli +mobile. PigeonMoelleux règle le problème (en direct) -> Problème réglé + +Par défaut, le dossier courant ne peut contenir que 50Mo. Est-il possible de se +placer dans le dossier de 30 Go ? Probablement pas faisable mais un README a +été écrit par défaut pour expliquer ce qu'il faut faire. Qui lit les +README ? Sur Nextcloud, le README est affiché en gros sur la page d'accueil. + +### Ajout de SPF sur mailman && durcissement de la politique sur les fails + +On est actuellement cool sur les fails. (Un peu trop...) + +Le risque est qu'un serveur n'ayant pas mis un SRS pourrait drop un mail qui ne +devrait pas l'être. + +Est-ce qu'on drop les mails qui échouent les SPF ? + +* pour Mailman -> les fails seront drop +* pour Redisdead -> il y a déjà un en-tête pour dire que le mail à fail, et on + ne change pas ça pour le moment + +### Retour sur NextCloud et OnlyOffice (ou collabora) + +Il y a un mois installation, Nextcloud a été déployé au crans mais il restait +encore quelques configurations (il manquait encore autofs). + +Actuellement, il es possible d'utiliser agenda, calendrier... sur nextcloud +mais il manque un éditeur de documents. Le quel installer ? Onlyoffice ou +Colabora ? Telle est la question ! + +Pas de différence a priori entre les deux (Collabora et onlyoffice sont +compatible avec microsoft office et libre office). + +* Avantage de collabora : mis à jour plus rapidement (d'où l'utilisation à + Aurore) +* Avantage d'Onlyoffice : continuité avec les services de l'ENS (qui utilise + aussi Onlyoffice) diff --git a/compte_rendus/2024_09_22.md b/compte_rendus/2024_09_22.md new file mode 100644 index 0000000..4fd6793 --- /dev/null +++ b/compte_rendus/2024_09_22.md @@ -0,0 +1,207 @@ +# Réunion IN + +* Date : Dimanche 22 Septembre 2024 +* Lieu : MB85 et Galène () +* Début : 14h34 +* Fin : 17h21 + +## Participant⋅es + +* aeltheos +* Chiaroush +* DsAc +* GaBo +* Hachino +* korenst1 +* Louis +* Lyes +* Lzebulon +* Pigeon Moelleux +* RDB +* rigobert9 +* Sergey +* Shinigami + +## Ordre du jour + +* [Lzebulon] Présentation rapide de l'infrastructure pour les nouvelleaux +* [Lzebulon] Point sur l'avancement de la chronologie définie à la précédente IN +* [ds-ac] Discussion Cybermois 2024 ou 2025 +* [Gabo]Organisation des Journée Federez +* [ds-ac + Pigeon] discussion documentation +* [ds-ac] relancer la discussion "serveur mail utilisable" vs. "arrêter les + spams et opérations de phishing" +* [bleizi + aeltheos] Imprimante +* [Pigeon] Problèmes disques +* [Lzebulon] coupure des vacances de la Toussaint +* [Pigeon] Vaultwarden +* [ds-ac] proposition de modif séminaire : LaTeX + Typst + Texinfo + +### Présentation rapide de l'infrastructure pour les nouvelleaux + +Rapide présentation de l'infrastructure. + +Récapitulatif de ce qui a été présenté : + +Le crans est un fournisseur de services. +Il occupe 2 salles : MB87 et SQ39 -> salle des serveurs + +Baie de serveurs : + +* serveur photos +* serveurs au crans +* partie louée à serv[ens] + +Les serveurs du crans : + +* cephirot (qui est actuellement pété) +* thot (qui est actuellement pété) +* cameron +* baie d'hyperviseurs (sam/daniel/jack (adm) et stytch/gulp/olvyd(pété) (adh)) +* zamok + +Présentation de ssh (et zamok) + +Serveur PAS à l'ens : + +* à OVH +* à viarezo (routeur-ft) + +### Récupération de serveur à Paris + +[[WikiAeltheos|aeltheos]] ou [[WikiLzebulon|Lzebulon]] demande les specs avant +de prendre une décision lors de la prochaine IN. + +### point sur l'avancement de la chronologie définie à la précédente IN + +* les backups refonctionnent (et en particulier à Viarezo remarche) +* Intégration : Succès +* Onlyoffice : déployé mais on veut changer pour collabora +* avancée de l'imprimante : Il semble qu'il y ait un switch (telco-sw-1) entre + les serveurs et la DSI. La DSI donne probablement les bons vlans à ce switch. + Mais le switch nous donne lui uniquement 2751 (renater) en UNTAG. Il faut + voir avec la DSI pour configurer ce switch. +* cephiroth : Il faut acheter un nouveau contrôleur + SAS (cf [CA](./2024_09_22.md)) + +### Discussion Cybermois 2024 ou 2025 + +Proposer des événements de sensibilisation à la cyber sécurité ou à la bonne +gestion des outils informatiques (pour tous⋅tes) + +L’évènement a lieu en octobre. + +2024 -> c'est un peu court + +2025 -> c'est possible + +L'événement pourrait être ouvert au personne extérieur. Il faudra demander à +l'ENS. + +On peut enregistrer des événements qui sont partout en France. +L'organisation sera à voir avec le nouveau bureau... + +Il faudra prévoir d'inviter des intervenant⋅es. Potentiellement demander à la +présidente de l'April. + +On peut organiser des conférences, jeux, ateliers bref tout est possible. + +On peut demander à l'ENS pour valider de la diffusion des savoirs. + +### Organiser les journées federez + +Il faudrait trouver des logements et c'est compliqué, ou alors demander de +l'aide de viarezo + +L'idée a été abandonnée. + +### Discussion documentation + +Rappel : Documentation imprécise et lacunaire. Donc projet de refonte de la +documentation. + +> v2 de la doc + +Proposition de ds-ac : + +* faire une grosse page de documentation avec des cross reférences (possibilité + de faire plusieurs fichiers mais les cross références sont meilleures + lorsqu'il y a tout dans le même fichiers). +* c'est du .texi (Texinfo) +* génération d'une table des matières +* différent de markdown mais pas plus compliqué +* possibilité de faire des références vers d'autres manuels + +ds-ac va créer une autre branche avec la documentation en texi + +But documentation : lisible avec bat, cat, less + +PigeonMoelleux propose la création d'une documentation à destination des +utilisateur⋅ices pour expliquer par exemple comment synchroniser des +calendriers, connecter sont compte crans avec thunderbird. +Proposition d'utiliser mdmux pour cela. + +Pour de la doc jolie : + +Proposition pour faire un wiki comme Aurore () + +autre proposition de ds-ac -> quarto + +Licence Creative Commons ou BY-NC-SA (peut être sans NC) + +### relancer discussion "serveur mail utilisable" vs "arrêter spams phishing" + +Le serveur mail du crans c'est une passoire à spam +ds-ac propose d'être plus restrictif en applicant les conditions de google + +Est-ce qu'on devient plus restrictif ? (typiquement les mails qui sont de nous +à nous même) + +drop les mails ou créer un dossier spam : + +* dossier spam est plus difficile à mettre en spam +* soit taggé + +il faudra annoncer au gens⋅tes que les mails sont potentiellement frauduleux. + +Lyes et ds-ac vont s'en occuper. + +### Problèmes disques + +Jack a été changé + +Tealc ne râle plus depuis qu'aeltheos s'en occuper +On a encore des erreurs smartctl et des pools zfs bloquées + +Gabo va incessamment sous peu acheter des disques de secours et un contrôleur +SAS. + +* achat de câble de SATA +* acheter qch qui peut faire du SAS + +### coupure des vacances de la toussaint + +Tealc ne va pas bien, les serveurs n'ont pas été redémarrés pendant l'été et le +câble management est vraiment à refaire... +Il faut redémarrer les serveur soit couper le crans pendant 2 jours + +### Vaultwarden + +De nombreuses personne demandent si le crans propose des gestionnaires de mots +de passe. +Bitwarden et Vaultwarden sont les deux self-hostés. +Héberger cela pose des question de sécurité... + +* Le crans deviendrait une source plus intéressantes d'attaque +* Si on le fait, on ne fait pas de récupération et on a un audit (non officiel) +* Si une personne perd son master password, elle ne pourra pas récupérer ses + mdp, et on le dit clairement + +Le crans va l'implémenter avec nixos / ansible + +### Proposition de modification des séminaires : LaTeX+Typst+Texinfo / QUIC ? + +Il y a déjà séminaire LaTeX et Typst +ds-ac propose de faire un séminaire texinfo (en séminaire interne) +ds-ac propose aussi de faire (ou d'encadrer) un séminaire QUIC (au second +semestre) diff --git a/compte_rendus/2024_11_16.md b/compte_rendus/2024_11_16.md new file mode 100644 index 0000000..f32c7e0 --- /dev/null +++ b/compte_rendus/2024_11_16.md @@ -0,0 +1,347 @@ +# Réunion IN + +* Date : Samedi 16 Novembre 2024 +* Lieu : MB85 et Galène () +* Début : 14h34 +* Fin : 17h21 + +## Participant⋅es + +* bleizi +* Emett +* GaBo +* korenst1 +* Lzebulon +* Otthorn +* Pigeon Moelleux +* Rigobert + +## Ordre du jour + +* [Pigeon] trier l'ordre du jour (avec un tri topologique) +* [Lzebulon] (on est plus à un point pret) viarezo, on doit reconnecter je + crois ->^? sfp +* [Hachino] (Possiblement HS) Problèmes d'envois de la ML Événements vers + certains domaines (`@laposte.net` et `@gmx.fr`). Réputation + mail ? +* [Lzebulon, korenstin] sudo apprenti⋅e⋅s sur machine apprenti +* [Pigeon] Possible sans trop de soucis mais il faut alors pas monter les + home_nounous -> le but était justement de discuter de ce point ! (genre + ajouter dans ansible une exception à la vm apprenti pour dire "bah non en + fait... on ne veut pas les home_nounous") +* [Hachino, 30 oct. 10h30] Nextcloud est encore plus lent que d'habitude, au + point qu'il n'est pas arrivé à ouvrir un dossier < 5 Mo avec une dizaine de + PDF. Owncloud idem est devenu super lent (mais il sert tous les fichiers). + Sur OC, quand je lis un PDF dans le navigateur et que je fais "retour", je + suis renvoyé dans mon /home au lieu du dossier courant. EDIT : tiens, une + heure plus tard ça semble un peu plus fluide et l'erreur de retour a disparu ? +* augmenter le nombre de cpu/ram de la vm + augmenter le nombre de + pm.children_max (php-fpm) ? +* [Lzebulon] nettoyage de zamok : virer podman ? autres trucs ? possibilité de + faire un sondage pour savoir ce que les adhérent.e.s ont besoin pour virer ce + qui est inutile ? +* [Pigeon] nix sur zamok ? (Pas NixOS, juste le package manager) +* [Pigeon] Documentation adh : docmost ? +* [Lzebulon] update etherpad : 1.8.18 -> 2.2.6 ? (breaking changes + : npm -> pnpm) +* [Lzebulon] comment ca fonctionne policyd-rate-limit/comment debug quand + quelqu'un se plainds +* [Lzebulon] (peu important) redite.crans.org semble cassé (mais j'ai pas + regarde) -> redite n'est qu'une vm pour présenter nixos à des anciens + apprentis (merci aeltheos d'ailleurs !) +* [Lzebulon] Blackbox probe failed souvent sur owncloud +* [Lzebulon] onlyoffice est cassé je sais pas pourquoi +* [bleizi] SPF fail +* [Lzebulon] si zamok est down/postfix mal monte, et redisdead est up -> perte + de mail ? : possibilite de se passer de zamok pour la reception des + mails ? (comme c'est le cas pour nextcloud) +* [Pigeon] getty@ttyS0 +* [Lzebulon, korenstin] Point imprimante +* [Hachino] Charlie dit qu'on ne peut pas envoyer plusieurs fichiers à + l'imprimante et les faire imprimer en une fois. +* [aeltheos, lzebulon] serveurs à paris +* [Lzebulon] je ne sais pas à quoi fait référence ce point -> il y a ~1 mois + qn (sur le discord med surement) à transmis un msg à propos de la + disponibilité (par un don) de serveur d'une certaine asso. Le but était que + qn les contacts (toi ou aeltheos) pour demander les specs +* [Hachino] Jitsi semble bien cassé : je viens d'essayer de faire une visio + avec quelqu'un et chaque fois que l'un rentrait, l'autre était déconnecté. En + boucle. On a fini par utiliser celui d'Aurore à la place. +* [korenstin] les scripts python ne possèdent pas de requirements et ne sont + pas dans des venv +* [korenstin] Point ansible ? +* [korenstin] Que fait on de trinity ? + * [Pigeon] Installation Matrix prochainement ? Debian ou NixOS ? + * Même question (càd que fait-on de ... ?) pour les vms inactives sur + proxmox (éteinte) ? tealch, kameron, otter, daneel, listenup, gougle, + ceph{0, 1, 2}, test-debian-postfix (x2), aeris + * Suppression dans le ldap ? (constellation-dev, dsi??, excalibur, horst, + idrac-zbee, ilo-charybde, karst, passerelle, rodney, zephir) +* [korenstin] Organisation des machines (physiques et virtuelles) dans la + documentation (qu'est-ce qu'on met ? qu'est-ce qu'on ne met pas ? fichiers à + part ? tout dans le qui est qui ?) +* [Pigeon] Indiquer dans la doc quelles VM/machines on peut redémarrer sans + causer d'apocalypse +* [lzebulon, pigeonmoelleux, korenstin] ft ne marche toujours pas... pas de + doc, imcompréhensible + aka : pour se connecter à routeur ft il faut passer par backup ft..., + certaines machines ping ft mais pas toutes et pas toujours +* [Pigeon] Présentation restic +* [Pigeon] l'ipv6 ne fonctionne pas sur thot + +### trier l'ordre du jour (avec un tri topologique) + +Pigeonmoelleux s'est amusé ! + +### viarezo, on doit reconnecter je crois ->^? sfp + +Tout fonctionne, le vlan passe. +VR -> pb avec le switch et depuis et il y a eu des pb. +on verra quand on aura de nouveau SFP + +### Problèmes d'envois de la ML Événements vers certains domaines + +L'une des personnes en question n'était pas inscrite sur la ML et la poste est +sensible. + +### sudo apprenti⋅e⋅s sur machine apprenti + +Le but de la VM c'est de permettre le sudo pour les apprenti⋅es +Cependant les home_nounous sont montés. +Les home_nounous sont à démonter et la vm n'aura plus de backup borg à cause +d'une clé ssh + +Pour les hash des mots de passe dans /etc/shadow : on va leur faire confiance +pour ça (en faite il n'y a que le mot de passe root). + +Sinon, mettre un autre mot de passe root root + +### Nextcloud est encore plus lent que d'habitude + +Nextcloud est lent, mais plus que d'habitude ? +Le nombre de php a été augmenté sur Owncloud. +Sinon, peut-être qu'il faut augmenter la RAM, le stockage... + +ou alors encourager à utiliser des alternatives (dav, ou autre client) + +### nettoyage de zamok + +retirer des outils qui sont encore là comme podman qui semble utilisé par +personne (qui était utilisé par ynerant et erdnaxe) + +Erreur systemctl : prometheus, dhcp-server, postfix, smartmontools n'ont pas +d'user configurer (probablement à cause de la coupure) + +On ne sait pas pour smart, isc. + +### nix sur zamok ? (Pas NixOS, juste le package manager) + +Tout le monde pourrait installer n'importe quoi (dans /nix/). +Il faudrait donc augmenter la mémoire (qui a 250 Go de disponible et qui a des +disques libres). On peut ajouter un disque pour /nix et nix optimize/garbage +régulièrement) +Soit : + +* /nix est local sur zamok -> juste pour zamok (sur cameron) et un pour le + reste du crans +* /nix commun pour le crans (risquer) + +Pas d'opposition ferme + +### Documentation adh : docmost ? + +Facile à écrire (exemple config pour thunderbird). +on continuera à chercher plus tard (ne prend pas en charge l'interconnexion +avec le ldap). +Pas de connexion nécessaire pour lire la doc. +Import possible avec le markdown. + +Un certain nombre de demande pour découvrir les différents services du crans +avis mitigé... + +### update etherpad : 1.8.18 -> 2.2.6 ? + +Il y a une version majeure d'écart... +Est-ce que la migration se passe bien -> ça à l'air... (pas l'air d'y avoir de +breaking change) +Comment s'est installé et on met à jour ? -> le repo est clone depuis le github +de etherpad. + +### Comment ça fonctionne policyd-rate-limit/comment debug quand quelqu'un se plainds + +Permet de limiter nombre de mails envoyés. +Il vérifie que les utilisateurs n'otn pas atteint un quota (par IP et user) + +Il y a aussi une limite dans postfix +policyd-rate-limit -> possède une db on sait pas où + +si qn se plaint, on ne fait rien, ça partira en 24h +(envoyer un mail à PEB) + +### (peu important) redite.crans.org semble cassé (mais j'ai pas regarde) + +Ça marche très bien ! point suivant. + +### Blackbox probe failed souvent sur owncloud + +On sait pas pk, on sait pas ce que c'est. +C'est quand on utilise un service et qu'il renvoie une erreur 502 (comme +nextcloud, roundcube, ownloud, wiki) + + -> c'est un exporter prometheus qui peut servir à ça mais aussi d'autre chose + +### onlyoffice est cassé je sais pas pourquoi + +Ça ne marche plus... +Le lien symbolique (pour nginx) avait disparu... + +### SPF fail + +On peut se dire qu'on drop les mails qui fail + +Est-ce qu'on accepte ou refuse les hard et/ou soft fail ? +Si soft fail : on doit le laisser passer sauf si on a un autre critère de rejet +Si hard fail : on peut les bloquer (mais pas obligé) + +Proposition en cas de SPF fail : + +* sur redisdead, on augmente le score de spam s'il y a un anti spam, sinon on + fait rien +* sur mailman, on installe SPF, on drop le mail en cas de fail (mais pas de + soft fail) + +redisdead : les mails sont rejetés si sans nom de domaine associé, +score > 4 byebye (c'est pas clair) + +### Si zamok est down/postfix mal monte, et redisdead est up -> perte de + +mail ? : possibilité de se passer de zamok pour la réception des mails ? (comme +c'est le cas pour Nextcloud) + +On perd des mails +redisdead essaye d'écrire sur zamok et donc, si les disques sont inaccessibles, +on perd des mails. +La raison était de pouvoir avoir ses propres filtres de mails + +Sinon faire le filtre sur direct sur redisdead. +Il ne devrait pas perdre des mails quand même si zamok est down. + +Le problème vient probablement du serveur mail de zamok... + +Juste faire attention quand on redémarre + +Rajouter un ordre dans l’exécution dans systemctl ? +D'où vient le pb de montage ? +dire à postfix d'écrire dans un autre dossier si inaccessible +On attend ceph + +### getty@ttyS0 + +Ça fail bcp et un problème de droit encore (visiblement) + +### Point imprimante (ca refonctionne (merci aeltheos et lzebulon) mais pas la + +couleur (rien de nouveau -> si le scan !)) + +Ça marche, juste pas le magenta (problème avec la buse magenta) +Si on veut de la couleur on peut essayer de refaire fonctionner l'autre +imprimante -> Otthorn ne pense pas, il y avait le pb avec le finisher, +software, contrat avec HP et encres hyper chères. C'était une machine à gaz. + +### On ne peut pas envoyer plusieurs fichiers à l'imprimante et les faire + +imprimer en une fois. + +Le site a été développé vite et mal, il peut être intéressant de le dev +mieux.... (c'est pas urgent) + +### serveurs à paris + +pas contacté + +### Jitsi semble bien cassé : je viens d'essayer de faire une visio avec + +quelqu'un et chaque fois que l'un rentrait, l'autre était déconnecté. En +boucle. On a fini par utiliser celui d'Aurore à la place. + +pigeonmoelleux semble avoir résolu le problème. +Jitsi n'est pas à jour... +c'est sur apt -> probablement des breaking change + +### scripts python ne possèdent ni requirements ni venv + +Les scripts ont cassé car ni venv ni requirements. +On peut le faire mais probablement la flemme. + +### Point ansible ? + +Pas d'apprenti⋅es + +### Que fait on de trinity ? et d'autre vm + +Trinity, on garde + +Même question (càd que fait-on de ; + +* tealch +* kameron +* otter +* daneel +* listenup +* gougle +* ceph{0, 1, 2} (potentiellement on garde) +* test-debian-postfix (x2) +* aeris +* one + +On demande à ds-ac pour savoir si on peut les brûler + +Suppression dans le ldap ? + +* constellation-dev +* zamok-tmtc -> supprimer + +dsi -> il faut se renseigner + +### Organisation des machines (physiques et virtuelles) dans la documentation + +Pas ansible + +vlan, suffixe IP=ID + +Indiquer les machines que l'on peut redémarrer sans problème. + +Fichier à part détailler pour les machines physiques. + +On met dans le pad IN les trucs qui ont été fait en quatrième vitesse/non +documenter/pas ansible/pas de nixos + +### ft ne marche toujours pas... pas de doc, imcompréhensible + +Plus de backup actuellement : +thot : pb de boot, disque, on a tout réinstaller sur nixos (avec restic) +ft : ne marche plus depuis qu'il est revenu (depuis VR) (avec borg) + +ft ne répond plus. +VR a éteint ft sans nous le dire. Tout a été relancé et tout refonctionnait. VR +ré-éteint ft. ft a été ramené chez nous. +Pb chez nous, ça ne refonctionne pas et c'est incompréhensible. + +Sur ft, il a 2 vm (proxmox) routeur-ft, backup-ft. +routeur-ft a un vpn vers boeing. On ne comprend rien au fonctionnement. +On ne sait pas régler le problème. + +On dit : on supprime proxmox et vm, on met tout sur ft + +Si on devait réinstaller ft, on aura pas besoin de tout réinstaller. +On garde backup-ft mais on supprimer routeur-ft + +où on met ft ? peut être pas à VR + +### Présentation restic + +Thot ne supporte pas l'uefi et on a installé uefi +Restic et borg sont des bakcups incrémentales. Plus de détail dans la +documentation. + +### L'ipv6 ne fonctionne pas sur thot diff --git a/compte_rendus/2024_12_15.md b/compte_rendus/2024_12_15.md new file mode 100644 index 0000000..881793a --- /dev/null +++ b/compte_rendus/2024_12_15.md @@ -0,0 +1,116 @@ +# Réunion IN + +* Date : Dimanche 15 Décembre 2024 +* Lieu : MB87 et Galène () +* Début : 14h14 +* Fin : 15h10 + +## présent⋅es + +* bleizi +* WikiPigeonMoelleux +* korenst1 +* Hachino +* Igolta +* Lyes +* Lzebulon + +## ordre du jour + +* high availability proxmox pour les services importants : residead, ecilis, + romanesco, les ldaps, les db (quand elles seront sur vm), autres ? +* les backups sous restic sont déployées sur toutes les machines (debian) +* A quoi servent les disques durs dans l'armoir ? +* ft est de nouveau joignable +* disque dur de daniel changer +* apprentix et livre déployer +* hijacking d'un des deux kanban dispo sur le gitlab ou création d'un nouveau +* je sais plus si on en a parlé : mirror repo nixos sur git2 +* archivage de certains repo : Ghostream, django-webnews, bcfg2 +* Matrix + +### les backups sous restic sont déployées sur toutes les machines (debian) + +Il n'y a pas assez de place pour backuper le cameron. il faut passer en +raidz2 (car l'un des emplacements disques est cassé). + +Pas backuper : + +* kiwi : crashe tout le temps (pb de version probablement) +* re2o-dev : c'est pas grave + +Prune semble ne pas fonctionner : à debugger + +### Matrix + +Trinity possède synapse. + +Opération : + +* déplacer synapse sans perte de données + +2 types de connexion : + +* LDAP du crans +* Oauth2 avec la note (peut-être conflits) + +Si conflit : mettre pseudo note_[pseudo] ou _[pseudo] + +### A quoi servent les disques durs dans l'armoir + +Les disque sont (normalement) shred et peuvent être compatible avec les +serveurs (et utilisable, voire donnable). + +### Disque dur de daniel changer, changement pool en ashift 12 + +Changement des pool en ashift 12 -> plus tard + +### apprentix et livre déployés + +Il y a un problème de config nixos. Il faudra faire une pull request sur github + +### ft est de nouveau joignable + +Ça marche ! (La configuration des VLAN était différente entre les switchs +Arceus et Carapuce) + +Il est temps de décider de déplacer des backups à l'extérieur. + +Il faudrait changer le ventilos sur ft. + +### High availability proxmox pour les services importants (attendre ceph ?) + +Est-ce qu'on le setup pour : redisdead, silice, romanesco, hodaur, les ldaps, +les db (quand elles seront sur vm), autres ? + +Les db sont sur des machines physiques (tealc en théorie) + +Les ldaps sont déjà répliqué (sur toutes les machines physiques). + +Demander à Aeltheos pour ce qui est de ceph. + +### Hijacking d'un des deux kanban dispo sur le gitlab ou création d'un + +nouveau + +Création d'un kanban pour suivre ce qu'il y a à faire au crans et suivre +l'avancement. + +### mirror le repo nixos sur git2 + +OUI ! + +### archivage de certains repo + +Archiver : + +* Ghostream +* django-webnews +* bcfg2 + +### imprimante encres + +Réferences : + +* encres : +* waste : diff --git a/compte_rendus/2025_01_19.md b/compte_rendus/2025_01_19.md new file mode 100644 index 0000000..d2bc2bd --- /dev/null +++ b/compte_rendus/2025_01_19.md @@ -0,0 +1,105 @@ +# Réunion IN + +* Date : Dimanche 19 Janvier 2025 +* Lieu : MB87 et Galène () +* Début : 17h30 +* Fin : 18h45 + +## présent⋅es + +* antonin +* bleizi +* Chiaroush +* ds-ac +* Gabo +* korenst1 +* Lzebulon +* Lyes +* Pigeon Moelleux +* viadezo1er (Président de Federez, ancien de ViaRézo) + +## Ordre du jour + +* podman fail, que fait-on ? suppression ? +* centralisation de la configuration du dns (dans le LDAP) +* ferle (VM a disposition du RIPE) est éteinte et grub panic quand elle demarre +* borgmatic plante régulièrment à cause de ProtectSystem=full +* spamassassin : semble configurer pour chaque utilisateur⋅ices -> pourrait-on + proposer une configuration par défaut ? +* Déploiement nouvelle infrastructure Matrix +* vulnérabilité rsync sur mirror ? +* le kanban mentionné à la dernière IN est en place +* quels sont les conditions pour une alternative à moinmoin... +* sops -> agenix +* Serveur de build Nix + +### Podman + +Déjà désinstallé + +### Centralisation du DNS + +Le DNS est configuré dans le LDAP adh et adm (les deux à la fois). Dans le LDAP +adm, les alias des VMs définis à plusieurs endroits (notamment hodaur). + +On range mieux + [faire de la documentation](https://gitlab.crans.org/nounous/documentation/-/issues/13) + +### ferle + +VM à disposition du RIPE. Elle grub-panic lorsqu'elle démarre. Il faudrait les +contacter par mail / voir dans leur documentation si on peut réinstaller la VM. + +Pigeon Moelleux est délégué pour s'en charger. + +### Borgmatic + +Crash de borgmatic à cause de l'option systemd ProtectSystem=full. +Modifier le fichier directement poserais des problèmes lors des mises à jour de +borgmatic. Il est possible de créer un nouveau fichier systemd dans /etc pour +overwrite la configuration. + +### Spamassassin + +Configuration par utilisateurice -> on valide et on met un message indiquant de +la documentation. + +### Vulnérabilité rsync sur tealc + +On est pas impacté car on a une version antérieure à celle mise en cause. +Il faudrait mettre tout à jour, mais ça demanderait de tout redémarrer. + +### Matrix + +Ça avance (déploiement très prochainement). + +### Kanban + +Meilleure visibilité de ce qu'il y a à faire au Crans +() + +### Wiki + +Moinmoin -> python 2 donc on aimerait migrer +Quels sont les critères à remplir pour une potentielle migration sur un autre +service ? + +### Gestion des secrets sur NixOS + +Age -> SSH / Sops -> GPG +Age -> plus simple à configurer +On passe sur age -> on mettra les clefs SSH des gens qui veulent. + +### Serveur de build nix + +On va checker Hydra (). +On fera une VM un peu boostée. + +### Zero bin + +Zero a été mis à jour par ds-ac. +Enfin assez mal : le template est à revoir. + +### belenios + +Déjà packagé en nix par Lzebulon +Lyes s'est porté volontaire pour faire le service systemd. diff --git a/compte_rendus/2025_02_22.md b/compte_rendus/2025_02_22.md new file mode 100644 index 0000000..c0349fe --- /dev/null +++ b/compte_rendus/2025_02_22.md @@ -0,0 +1,193 @@ +# Réunion IN + +* Date : Samedi 22 Février 2025 +* Lieu : MB87 et Galène () +* Début : 16h +* Fin : 18h30 + +## Présent⋅es + +* [bleizi](WikiBleizi) +* Chiaroush +* Erdnaxe +* Gabo +* Hachino +* korenst1 +* Lyes +* Ohime +* [Pigeon Moelleux](WikiPigeonMoelleux) +* [RDB](WikiRDB) + +## Ordre du jour + +* Quie faire de vieilles ML ? 25ans@, respbats@ ? Brûler ? +* suppression de rsyslog +* AptObsolete, que peut-on supprimer dans les packets en question ? +* Qemu-guest-agent (option non activée sur de nombreuses vm mais le paquet est + installé sur toute), au prochain redémarrage, les activons-nous ? +* getty@ttyS0 fail car on n'a pas rajouté les ports séries dans l'interface de + proxmox (les rajouter au redémarrage des serveurs / nixos) +* openipmi fail sur routeur-daniel, mais ne semble pas installé sur sur + routeur-jack et routeur-sam... pourquoi ? doit-on le désinstaller ? (question + similaire pour hodaur, ce n'est pas dans ansible) +* retour sur le problème serveur du 11 février +* Rachat de nouveaux serveurs ? Un Gen10 se trouve à 400-600 € pièce et les Gen8 + du Crans datent de 2012-2015. +* MAJ de Nextcloud -> passage sur NixOS pour que ce soit plus simple à maintenir + ou on reste sur debian ? +* Setup d'un serveur de build pour NixOS +* Fin de mise en place Matrix -> Il y a un problème dans la précédente + configuration du bridge, que fait-on ? +* Remettre en marche Belenios avant l'AG BDE ? +* wiki (historique de modification) +* excalidraw + +### Que faire de vieilles ML ? 25ans@, respbats@ ? Brûler ? + +La ML respbats pourrait être encore utilisée de rare fois. + +Pour 25ans, la décision est de conserver les mails mais de drop tout les +nouveaux mails. Pour respbat, on ne change rien (ou alors suppression des +ancien⋅nes responsables). + +### suppression de rsyslog + +Aujourd'hui, on n'utilise plus rsyslog mais on utilise journald. Si rsyslog est +utilisé quelque part, on peut remplacer par journald. + +### AptObsolete, que peut-on supprimer dans les packets en question ? + +On a des logs sur roots/logs de services qui se plaignent de services qu'ils ont +des paquets installés orphelins/obsolete. + +Sur Galène, il y a avait probablement un paquet orphelin qui servait à quelque +chose. On peut donc les supprimer et si ça casse quelque chose, on réparera. + +Erdnaxe signale que orphelin signifie plus de source APT. Il dit qu'il faut +faire gaffe avant suppression à ce que ça ne soit pas "juste" une source APT +virée quelque part. (Exemple avec Docker : ajout source, apt install docker, +virer source et Docker devient orphelin, pourtant on a pas envie de le +supprimer.) + +### Qemu-guest-agent + +qemu-guest-agent est un logiciel qui permet une communication entre proxmox et +la vm et remonter des métadonnées (usage CPU, etc). Cependant, Il s'agit aussi +d'une back door car permet l'execution de commande en root. + +Puisqu'il s'agit d'une fail de sécurité, on désactive l'option sur promox et on +le retire de ansible. + +### getty@ttyS0 fail + +ttyS0 permet d'avoir un terminal série sur proxmox typiquement un terminal avec +copier-coller. + +On le rajoute lors du redémarrage des serveurs sur toutes les vm et sur nixos. + +### openipmi fail + +Ce serait une dépendance de exporter-prometheus. +S'il n'a pas de dépendance, on peut supprimer le paquet. + +### Retour sur le problème serveur du 11 février + +Il y a eu des erreurs avant mais un crash est arrivé le 11 février vers 15h +(Wiki a eu un bug). Les serveurs ont été utilisé à 100%. Tealc a visiblement eu +un problème de cpu et ne répondait plus. Toutes les vms attendaient tealc qui ne +répondait pas. + +Après discussion, les serveurs ont été poweroff ou éteint violemment. Lors du +redémarrage, sam a refusé de redémarrer à cause de 2 ventilateurs +dysfonctionnels qui ont donc été changés. + +### Rachat de nouveaux serveurs ? + +L'infra du crans est viellissante et on a l'argent. Proposition d'achat de +nouveau serveur pour renouveler l'infra/avoir un serveur de secours. Pour les +vielles versions, les pièces sont moins chères. + +Les gros ssd commencent à être rentables. + +Des études seront menées afin de déterminer le budget et la procédure qui sera +suivie pour la transition. (visiblement 100€ pour un ssd de 2 To) + +### MAJ de Nextcloud -> passage sur NixOS ou on reste sur debian ? + +Nextcloud a quelques(=2) mises à jour majeure de retard. Nextcloud est +actuellement sur debian mais c'est pénible à mettre à jour et installer à la +main. Sur nixos, les mises à jour sont beaucoup plus simple. + +Soit on ne fait pas les mises à jours (mauvaise idée), soit on ansibelise, soit +on passe sur nixos. + +Sur nixos, on peut copier-coller la configuration de debian. + +Plus agréable vs plus sécurisé ? Si des personnes sont intéressés, on peut +mettre en place de l'OIDC + +Projet apprentis : + +* pour uniformiser la page d'identification. +* script de mise à jour ou passage sur nixos ? + +Le passage sur nixos est privilégié. + +La migration sera effectué lorsqu'il y aura des apprentis et des gens motivés + +=== Setup d'un serveur de build pour NixOS === + +On peut mettre le serveur de build sur cephiroth directement (pas sur des vm). +Le serveur de build permettra d'optimiser les build en ne recompilant pas tout +et en utilisant la puissance de calculs sur le serveur de build. + +Proposition d'utiliser hydra et cachix. Alternative, dire au serveur de rebuild +la conf d'un autre serveur, dans ce cas rien à faire à part de la doc +(pigeonmoelleux s'en chagre). + +### Fin de mise en place Matrix -> Il y a un problème dans la précédente + +configuration du bridge, que fait-on ? === + +2 choses à mettre en place : + +* client web (element) +* connexion en OIDC par note kfet + +Lzebulon et pigeonmoelleux ont regardé la configuration de matrix et il faut +changer le bridge irc/matrix. Le serveur matrix a été pensé pour faire +uniquement du bridge donc le namespace (nom de channel gérer par le bridge) des +serveurs matrix doivent être des salons irc. Ils proposent de remapper les noms +des salons irc sur matrix mais tout les salons sont déjà mappé sur matrix et +donc pigeonmoelleux a drop les noms des salons mais les anciens salons existent +encore. La chose la plus simple à faire est de drop la base de données de +matrix. Cela signifie que tout l'historique sera perdu. (ce qui n'est pas un +problème car ni en prod ni beaucoup utilisé). Les personnes que ça dérangerait +seront potentiellement les personnes de Aurore. On préviendra les membres de +Aurore. + +Les administrateur⋅ices seront les nounous. + +### Remettre en marche Belenios avant l'AG BDE ? + +c'est compliqué : + +* Soit remet debian avec ansible : c'est compliqué, pas à jour et la compilation + ne marche pas. +* Soit on passe sur nixos : Est en train de se faire packager sur nixos par + Lzebulon/Lyes + +### Wiki (historique de modification) + +La page modification récente a été cassée et devrait refonctionner mais +visiblement ne fonctionne pas dans certains cas. + +Est-ce que le crans décide de mettre en place WikiStalk ? + +On peut garder WikiStalk et on le met sur zamok. + +### Escalidraw + + + +Pas primordiale mais pas d'objection. diff --git a/compte_rendus/2025_03_16.md b/compte_rendus/2025_03_16.md new file mode 100644 index 0000000..b876b91 --- /dev/null +++ b/compte_rendus/2025_03_16.md @@ -0,0 +1,53 @@ +# Réunion IN + +* Date : Dimanche 16 Mars 2025 +* Lieu : MB87 et Galène () +* Début : 10h33 +* Fin : 11h15 + +=== Présent⋅es === + +* Lzebulon +* Lyes +* korenst1 +* Pigeon +* Chiaroush +* Pyjacpp +* Romain + +== Ordre du jour == + +* Gâteau +* Incident imprimante +* Matrix + +== Gâteau (entre 10h05 et 10h15) == + +Lyes est maintenant Nounous. + +=== Incident imprimante === + +On reçoit des mails dès qu'une personne se connecte, il y a donc des erreurs. + +Lzebulon suppose que le problème vient de l'oauth (ce à quoi Lzebulon est +d'accord) + +Ducoup il faut trouver le temps de debug (contacter korenst1 qui adore Django) + +Pour l'issue : + +=== Matrix === + +Le déploiement est pratiquement fini. +On peut se connecter sur element.crans.org (ou sur n'importe quel client avec +le serveur matrix.crans.org) + +Pour laisser la possibilité aux gens de se connecter avec la note, on attends +le merge de + +== Fin de l'IN == + +On reparle de projet apprenti·e·s + +Et Lzebulon propose de relancer la machine des présentations techniques en +début d'IN.