250 lines
8.5 KiB
Markdown
250 lines
8.5 KiB
Markdown
# Réunion du Collège Technique
|
|
|
|
* Date :
|
|
* Lieu : PdJ
|
|
* Début : 19h00
|
|
* Fin : 20h36
|
|
* <<Pad>>
|
|
|
|
## 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](./2016_02_11.md)), 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](http://www.linux-ha.org/wiki/Main_Page) 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://developer.valvesoftware.com/wiki/SteamPipe).
|
|
<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.
|