• ComptesRendusCrans
• Jeudi15Mars2018

Réunion du Collège Technique

• Date : 15/03/18
• Lieu : Condorcet
• Début : 19h48
• Fin : 21h45

• Lien vers l'etherpad associé

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 : https://pad.crans.org/p/PlanIP

• ==> 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:

• https://community.ubnt.com/t5/UniFi-Wireless/Unifi-AP-support-mac-based-authentication/td-p/2232766 ou là: https://community.ubnt.com/t5/UniFi-Wireless/What-does-Radius-MAC-authentication-do/td-p/2126890 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 https://www.reddit.com/r/Ubiquiti/comments/79yhhd/does_ubiquiti_have_any_plan_to_implement_wpa2ppsk/ par exemple). Feature request officielle: https://community.ubnt.com/t5/UniFi-Feature-Requests/Private-WPA-keys/idi-p/626751 côté hostapd (utilisé en interne par openwrt et unifi-os), la feature existe bel et bien:

  • "wpa_psk_radius" dans https://w1.fi/cgit/hostap/plain/hostapd/hostapd.conf 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 <groupe>", 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.

https://gitlab.federez.net/federez/re2o.git

Renews les clef gpg pour le dépôt custom

Et faire une page wiki sur comment faire

• un tuto : https://blog.packagecloud.io/eng/2014/10/28/howto-gpg-sign-verify-deb-packages-apt-repositories/

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 : https://www.cvedetails.com/cve/CVE-2017-15132/ https://tracker.debian.org/pkg/dovecot

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 !

• CatégoriePagePublique