7.7 KiB
Réunion du Collège Technique
- Date : 21 octobre 2019
- Début : 19:11
- Fin : 21h04
- Lieu : Salle de conférence du Pavillon des Jardins
- <>
- Jitsi : https://jitsi.crans.org/IN
Présents:
- Solal
- Charlie
- Edpibu
- Elkmaenchen
- Hachino
- !TinyLinux
- 2 1A (Déso j'ai oublié vos noms).
- Mikachu
- Vulcain
- Erdnaxe
- Pollion
- Thybal
Bilan réunion avec la DSI
https://pad.crans.org/p/ReunionDsiCrans
La fibre vers le G passe par l'ENS : Une fibre entre le B et l'autocom, une jarretière fibre, et la fibre repart vers le G. L'ENS doit vider tous les bâtiments d'ici fin avril, a priori y compris l'autocom. Il va falloir trouver une solution pour le bâtiment G. Ce qu'ils veulent faire c'est tirer une fibre entre l'arrivée de RENATER et le bâtiment De Vinci. Ils ont eu une réunion avec un presta pour tirer cette fibre, et ont /normalement/ proposé de rerouter notre fibre vers le De Vinci. Ce n'est pas encore clair qui va payer, on verra plus tard (avant de faire des travaux évidemment).
Fardale s'interroge du bien fondé de tout ceci : On a notre contrat fibre jusqu'à la fin du premier trimestre 2021. Donc jusqu'à ce moment on paye la fibre. Pour l'instant on a envie de continuer à fournir le Crans, y compris au G (et pourquoi pas De Vinci).
Quoi qu'il arrive, on veut garder internet au G.
Plusieurs solutions :
- Soit on fait un pont radio
- Soit on tire une fibre dans les souterrains.
La DSI est très intéressée par continuer à bosser avec nous, y compris sur Saclay (Pas encore défini); ils nous ont proposé une demi baie sur Saclay.
Ils ont proposé de nous faire rejoindre les discussions d'un comité "Métier" en cours de création.
Autre point : Démontage du matos de la DSI. Fin Avril, tout doit être vide, en particulier les bornes, switches, serveurs etc .... Et nous proposent de récupérer pas mal de matos (y compris les switches top of rack de la mort qui tue ou les serveurs Dell pas trop vieux et qui ne ressemblent pas à une étagère.)
Ils nous ont proposé qu'on aille démonter le matos, ils vont voir avec la DAI pour nous filer certains accès.
L'idée c'est pas forcément de garder ces bornes mais de les refiler à d'autres asso (Aurore, et autre ...)
Charlie : Le don de matos a été promis par la DSI ou validé par la DGS ? --> Pour l'instant ça a juste été évoqué par la DSI, mais ils veulent se charger de voir tous les services (DGS, DAI etc ...) et reviennent vers nous.
Vulcain : A priori ceci a été évoqué par Mazé devant Tavernier et ils avaient l'air chauds --> ça leur évite de signer des chèques à moult presta.
Migration des IP : On se fixe en objectif de finir tout ça avant la fin de l'année (Civile) On a commencé à faire des migrations à la va vite car on a commencé à perdre nos routes par l'ENS le 15 Octobre, date qui avait été évoquée dans un couloir par la DSI à vulcain (voir le CR de la dernière IN.)
Bilan Install Party
Le réseau
On a eu un léger soucis de réseau : On avait demandé à la DSI s'ils pouvaient brasser toutes les prises du PDJ avec nos VLANs. Résultat, on a perdu les deux seules qui marchaient .... On a tout de même pu s'en sortir avec le wifi.
~13 interfaces enregistrés pendant l'IP (sans compter ceux qui était déjà au Kwei) 16 utilisateurs, 24 machines (IP + Kwei) Le portail captif a super bien marché, mais Mikachu a fait la remarque qu'une attaqueIPoverDNS était possible puisque ça n'avait pas été envisagé. On a testé, ça marche.
Portail Captif
Faudrait un projet d'apprenti qui reprenne le portail captif (déjà bien nettoyé récemment) avec :
- nftables pour remplacer iptables et ipset
- laisser passer que le 80, 443 et 53 vers la VM quand l'utilisateur n'est pas register
- mettre en place un bind9 débile avec juste une règle /#/IP LOCALE
Ça sera l'occasion de revoir le portail captif d'auto enregistrement en filaire afin d'unifier tout ça.
Erdnaxe se propose pour encadrer cette tâche.
On va faire une tâche phabricator <<FootNote(Frapper WikiPollion s'il n'a pas indiqué la tâche phabricator ici.)>>.
Installations
Erdnaxe évoque l'idée d'utiliser netboot.xyz. Il avait essayé mais avait eu des problèmes. C'était potentiellement un soucis de MTU. De toute façon, On n'a pas envie de contacter l'extérieur ...
Bilan Séminaires
Séminaires faits : Introduction au Crans, Shell, Python basique. Ça s'est bien passé, et les gens en redemandent ! On a envoyé notre liste de séminaire à !ViaRézo, eux nous ont envoyé les leurs. Ils veulent juste que l'on ne les spamme pas trop d'apprenti (genre moins de 50), a priori ça passera.
Prochain séminaire sera sur le réseau basique et le routage !
Pages persos
phpMyAdmin a été remis au crans. On va probablement remettre en place une appli page perso.
--> Projet apprenti https://phabricator.crans.org/T345
Conf Apache de Zamok
Install-party.crans.org a été migré vers club-crans.
Point Interfaces
Depuis Stretch les interfaces sont nommées à partir de leur emplacement physique, on a envie de normaliser de cette nomenclature. Erdnaxe propose d'utiliser pour cela la mécanique de systemd qui permet de renommer les interfaces, et de faire gérer tout ça par Ansible. Esum parle brièvement de la possibilité de créer des alias.
##> On décide donc de nommer les interfaces ethN avec N VlanID + des alias adm, srv...
IPv4, IPv6, Plan d'Adressage
Mettre des RA pour les serveurs
On parle des Router Advertisement. À une époque, il semblerait qu'on avait tout désactivé parce que les machines sous Windows 7 pouvaient générer des faux RA sur le réseau. Maintenant, la protection mise en place sur les switchs et le fait qu'on n'ait presque plus de Windows 7 nous poussent à réviser cette décision et de simplifier la configuration de l'IPv6 des serveurs.
erdnaxe propose de faire du semistatique : on fixe l'adresse IPv6 puis l'interface récupère tout le reste en auto comme une grande personne.
Ça a déjà été mis en place sur certains serveurs, et ça marche bien. Aucun problème. On fait donc ça.
IPv6 et les adhérants
À l'heure actuelle, quelqu'un qui renatte derrière le crans n'a pas d'IPv6. Par exemple, un routeur TP-link d'un adhérent ne peut pas filer d'ipv6 (il a mois d'un /64).
En réfléchissant à ça Mikachu s'est rendu compte que le plan d'adressage v4/v6 était pas fou fou.
Plan d'adressage
Mikachu nous dit qu'on ne respecte pas tout à fait les normes dans le plan d'addressage : Apparemment, on n'est pas censé faire comme ça pour le nat en IPv4 en tant que FAI. Il propose de plus de donner un /50 d'IPv6 aux adhérants afin de régler le soucis évoqué au dessus.
Ok soit, pour le moment c'est pas urgent, mais on pourra l'envisager plus tard.
Monitoring
Conformément à la décision de la dernière IN, le paquet prometheus qui monitore systemd a été installé. /!\ Il n'avait pas vu le fail de mailman.
Le monitoring a pas mal été amélioré, on a droppé plein de choses legacy (notamment des vieux services systemd).
##> https://lutim.crans.org/2fJq5s6j/8V4gXbIK.png
erdnaxe a viré de la veille conf ISCSI, et avec Mikachu ils ont viré des gateway fantomatiques.
En parlant de systemd, Mikachu parle de networking.
Ménage d'hiver
Renommer vulcain => on le renomme "gateau"
Virer VM cups ? civet ? (c'est pas comme si un RabbitMQ était complexe à installer…) Pourquoi pas, de toute façon on peut les réinstaller si besoin.
Autre Ménage (synchronisation auto sur les ML à remettre entre autre ....) Oui on va faire ça.
Point disques
Les disques de gulp sont garantis. Pour la baie, le CA a donné
Gâteau
On a eu du gâteau. Bienvenue à Vulcain !