documentation/compte_rendus/2014_03_13.md

# 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).