194 lines
7.1 KiB
Markdown
194 lines
7.1 KiB
Markdown
# Réunion Nounous
|
|
|
|
* Date : Mardi 30 octobre 2012
|
|
* Lieu : 2B
|
|
* Début : 18h30
|
|
* Fin : 22h07
|
|
|
|
## Présents
|
|
|
|
* Daniel Stan
|
|
* Lilian Besson
|
|
* Olivier Iffrig
|
|
* Pauline Pommeret
|
|
* Pierre-Elliott Bécue
|
|
* Raphaël Cauderlier
|
|
* Valentin Samir
|
|
* Vincent Le Gallic
|
|
* Yann Duplouy
|
|
|
|
## Ordre du jour
|
|
|
|
### Bornes Wifi
|
|
|
|
Les !PicoStations sont arrivées.
|
|
|
|
* On a un problème : avec les anciennes comme avec les nouvelles bornes, il
|
|
arrive qu'au bout d'un temps aléatoire les utilisateurs n'arrivent pas à
|
|
aller plus loin que le DHCP. Une solution proposée est de faire un script qui
|
|
monitore ça, et qui relance ce qu'il faut ("wifi" semble suffire, mais on
|
|
peut décider selon les cas de rebooter la borne). De plus, hostapd semble
|
|
segfaulter sur certaines bornes, il est suggéré d'installer monit sur les
|
|
bornes, à voir si c'est suffisant. Daniel et Valentin vont voir ce qu'ils
|
|
peuvent faire.
|
|
* Pour le flashage : il faut des volontaires. On fera ça au fur et à mesure,
|
|
appel aux intéressés.
|
|
* Feature potentiellement intéressante des nouvelles bornes : il serait
|
|
possible de faire de l'authentification Pre-Shared-Key avec une clé
|
|
différente par MAC. Revers de la médaille : on ne peut plus valider le
|
|
certificat radius, donc possibilités de bornes pirates. Il pourrait y avoir
|
|
d'autres problèmes de sécurité si la borne connait le mot de passe en clair
|
|
de l'utilisateur.
|
|
* Étant donné qu'on va pouvoir recycler les anciennes bornes, il serait
|
|
intéressant d'essayer de faire fonctionner la dernière version d'OpenWRT
|
|
dessus. On va voir au cas par cas ce qu'on peut récupérer.
|
|
* En attendant d'avoir une réponse du CROUS pour l'installation de nouvelles
|
|
bornes, on peut déjà remplacer les anciennes bornes dans les faux-plafonds
|
|
par des nouvelles. Ça implique de ressertir les câbles PoE maison. Avis aux
|
|
intéressés.
|
|
* On n'a toujours pas les plans des bâtiments, donc pour l'instant le dossier
|
|
pour le CROUS est en attente
|
|
|
|
### Logs
|
|
|
|
#### Serveur
|
|
|
|
* On a reçu un devis de la part de notre fournisseur : même gamme que fx, fy et
|
|
sable. Cela fait peut-être un peu overkill, surtout que l'on est en train de
|
|
migrer les services qui sont sur sable. Le serveur est a
|
|
priori 100% modulaire, mais cher.
|
|
* Pas de SATA sur sable, mais du SAS, vu qu'on est en train de migrer les
|
|
services de sables vers des domU, il pourrait être envisageable d'acheter des
|
|
disques SAS et d'utiliser sable comme serveur de log.
|
|
|
|
On va demander des précisions/des nouveaux devis pour les différentes solutions
|
|
suivantes :
|
|
|
|
* Acheter le serveur (2500€ + éventuellement les disques → 3120€)
|
|
* Demander un serveur moins cher mais rackable (disques inclus)
|
|
* Utiliser sable en demandant seulement des disques SAS
|
|
* Extension de garantie pour sable ?
|
|
|
|
Il faut réfléchir à l'espace disque nécessaire.
|
|
Olivier s'occupera ensuite de demander les devis.
|
|
|
|
#### DomU pour les consulter
|
|
|
|
Daniel a créé un DomU de log qui récupère ceux de gordon (afin d'avoir des
|
|
données dans la base). Yann va configurer un frontend sur cette machine.
|
|
|
|
#### Envoi des logs
|
|
|
|
Vu que ragnarok n'est plus, et qu'on a des soucis pour récupérer les logs sur
|
|
vo,
|
|
on désactive cette fonctionnalité.
|
|
|
|
Seuls gordon (et donc les bornes WiFi) et news envoient leurs logs au domU, on
|
|
va rajouter quelques serveurs supplémentaires pour avoir une petite base de
|
|
données
|
|
qui reste représentative, ceci afin de développer et tester le frontend.
|
|
|
|
#### Logs d'Apache
|
|
|
|
Apache n'utilise pas syslog. Il faut interfacer Apache avec syslog. On peut dire
|
|
à Apache d'envoyer ses logs à un programme externe. Valentin s'en charge.
|
|
|
|
### DHCP
|
|
|
|
Valentin a créé un DomU (dhcp) centralisant tous les dhcp. Il a donc une patte
|
|
sur tous nos VLAN sur lequel le service est présent (adhérent, wifi, accueil,
|
|
isolement, appartement, install party).
|
|
|
|
Les switchs ont été reconfigurés pour le dhcp snooping, désormais sur tous les
|
|
vlans. Seul bata-3 n'a pas été reconfiguré car il semble mal configuré pour
|
|
un réglage à distance. Une fois que ce problème sera réglé et après
|
|
vérification,
|
|
on pourra couper les anciens services (sur sable, gordon, titanic). Pour
|
|
l'instant,
|
|
les serveurs fonctionnent en parallèle.
|
|
|
|
### Réunion avec la DSI
|
|
|
|
Il faut organiser une réunion avec la DSI.
|
|
|
|
Ordre du jour :
|
|
|
|
* Réunion périodiques ? (nouvelles têtes, coucou c'est nous)
|
|
* Personnels NATés sur Renater
|
|
* Plans du réseau
|
|
* Gigabit
|
|
* Clef placard (On a une clef du placard qui emprisonne ilona, mais elle est
|
|
endommagée. On peut leur demander la leur pour faire un double.)
|
|
* IPv6 (Rubis il est méchant)
|
|
* Étoiler le PDJ. (minigiga.new() → 0P)
|
|
* conf bato-1 (agrégation des deux fibres disponibles) : accès à l'autocom
|
|
nécessaire
|
|
|
|
### Passage de LDAP à PostgreSQL
|
|
|
|
## Vincent Le Gallic a remis ça sur la table. Pourquoi ça a été abandonné ? Mis
|
|
à part le boulot niveau scripts crans, pourquoi pourrait-on ne pas vouloir y
|
|
retourner ?
|
|
##
|
|
## Premièrement parce qu'on ne peut pas "mettre à part" le boulot au niveau des
|
|
scripts : personne ne les améliore pour LDAP, je ne vois pas pourquoi ça serait
|
|
plus facile de les refaire from scratch...
|
|
## Deuxièmement parce que l'intégration de LDAP à tous les services est
|
|
éprouvée (authentification, radius wifi, postfix, dovecot, apache...),
|
|
contrairement à celle de postgresql (libnss-pgsql avait tendance à segfaulter
|
|
aléatoirement)
|
|
## Troisièmement parce qu'il y a des choses plus utiles et plus intéressantes à
|
|
faire. Notre fonctionnement autour de LDAP est correct, pourquoi repartir de
|
|
zéro ?
|
|
## -- NicolasDandrimont <<DateTime(2012-10-30T11:50:52+0200)>>
|
|
## Les réplicat SQL ont tendance à se désynchroniser et ne pas toujours super
|
|
bien fonctionner.
|
|
|
|
On oublie ce point pour l'instant, au vu des réponses, un jour… peut-être…
|
|
|
|
### Switchs du bâtiment G
|
|
|
|
## Daniel propose d'enlever des switchs inutiles au bâtiment G
|
|
|
|
batg-2 et batg-7 pourraient être libérés pour remplacer des switchs en fault,
|
|
en mettant des adhérents sur les switches gigabit. Il faudrait d'ailleurs faire
|
|
jouer la garantie des switches défectueux. Ou les mettre à la poubelle/donner.
|
|
|
|
### Questions diverses
|
|
|
|
#### DNSSEC
|
|
|
|
Valentin a activé la validation DNSSEC sur les résolveurs DNS du Cr@ns. Ça
|
|
marche.
|
|
|
|
Le point suivant serait de signer la zone Cr@ns. (Valentin propose aux
|
|
apprentis présents (hint : ∅))
|
|
Ça consiste à faire des tests.
|
|
Attention : il faudra penser à pusher la clé publique chaque année.
|
|
|
|
#### PXE
|
|
|
|
Valentin veut migrer le PXE de sable vers charybde.
|
|
|
|
#### Ménage Baie de disque
|
|
|
|
Pierre-Elliott fera le ménage dans la baie de disques.
|
|
|
|
#### DomU routage
|
|
|
|
Valentin, toujours dans son idée de nettoyer sable des services, pour l'utiliser
|
|
à d'autres fins, souhaite créer un domU de routage spécialisé pour les
|
|
VLANs appartement, isolement, accueil, etc…
|
|
On y mettrait aussi un serveur web pour servir les pages de déconnexion et finir
|
|
(lentement) de démanteler squid.
|
|
|
|
#### lc_ldap
|
|
|
|
Il faut finir de coder lc_ldap et le documenter (pas forcément dans cet ordre).
|
|
Sont motivés : Pierre-Elliott, Vincent, Olivier.
|
|
|
|
#### Mails superflus
|
|
|
|
Vincent propose de passer en revue tous les mails reçus par les nounous afin
|
|
d'alléger le débit de mails. Olivier regardera avec Vincent.
|