Réunion du Collège Technique
- Date :
- Lieu : PdJ
- Début : 19h00
- Fin : 20h36
Lien vers l'etherpad associé
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), 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 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 : https://lists.crans.org/private/roots/2016-March/288827.html https://lists.crans.org/private/roots/2016-March/288767.html
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://blog.multiplay.co.uk/2014/04/lancache-dynamically-caching-game-installs-at-lans-using-nginx/ https://trac.resel.fr/wiki/Doc/Howto/InstallCache#no1
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
https://crans.org 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 ? https://ethercalc.crans.org/xr5ltkuwpf
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.