documentation/compte_rendus/2018_03_15.md

# Réunion du Collège Technique

* Date : 15/03/18
* Lieu : Condorcet
* Début : 19h48
* Fin : 21h45
* <<Pad>>

## 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 !