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