crans
/
documentation
mirror of https://gitlab.crans.org/nounous/documentation.git
19
0
Fork 0
Code Issues Projects Releases Wiki Activity
documentation/compte_rendus/2007_03_29.md

4.7 KiB
Raw Blame History

Réunion inter-nounous

Horaires

  • Date : Jeudi 29 mars 2007
  • Début : -- WikiSgnb <<DateTime(2007-03-29T17:22:41Z)>>
  • Fin : -- WikiSgnb <<DateTime(2007-03-29T19:16:32Z)>>
  • Lieu : salle Condorcet

Présents

  • Alexandre Bos
  • Antoine Durand-Gasselin
  • Augustin Parret-Fréaud
  • Jérémie Dimino
  • Stéphane Glondu

Ordre du jour

Pénurie d'adresses IP wifi

Problème:: On va bientôt arriver à cours d'adresses IP pour les machines wifi des adhérents (il en reste 45).

Solutions possibles::

  • On a trois /24 inutilisés (138.231.{145,146,147}); on pourrait déplacer le vlan adm (qui n'est de toute façon pas accessible directement depuis l'extérieur) dans une plage privée, et élargir le réseau wifi à 138.231.144.0/21 -> beaucoup de reconfiguration (switchs, serveurs).
    • On peut aussi laisser le vlan adm dans son /24, étendre le réseau wifi à 138.231.144.0/21, tout en continuant de réserver les 256 premières adresses pour le vlan adm -> solution la plus simple à mettre en œuvre et la plus raisonnable
    • Le réseau wifi est entièrement routé. Vous pouvez prendre 138.231.147.0/24 et ainsi de suite
  • Déplacer les bornes dans un des sous-réseaux inutilisés (les bornes ont-elles vraiment besoin d'être dans le même sous-réseau que les machines wifi ?)
  • Attribuer des IPs dynamiques -> il faudra maintenir des logs des correspondances MAC-IP, pour que, par exemple, les logs de squid soient utiles
  • Mettre les machines wifi dans un sous-réseau privé derrière un NAT
  • Restreindre le nombre de machines wifi pour les membres non actifs, mais de toute façon, il n'y a pas assez d'adresses IP (762) pour chaque adhérent (964)

Mails de confirmation

Mise en œuvre::

  • les liens qui ont été cliqués ont été logués par apache, ces logs seront utilisés pour mettre à jour la base LDAP pour ceux pour qui la page de confirmation n'aurait pas fonctionné
  • création d'un service (au sens de generate.py) pour mettre à jour la base -> élimine (façon de parler) les problèmes de locks
  • clarification : le spammage de la nuit dernière est le seul, il avait pour but d'initialiser le processus; à l'avenir, les mails ne seront envoyés que suite à un doute quant à la validité d'une adresse mail
  • pour les détenteurs de comptes crans : on pourrait exploiter le script de détection de comptes inactifs et envoyer le lien de confirmation directement dans le mail de détection d'inactivité -> utiliser mailconf pour confirmer aussi l'utilisation d'un compte crans

Choses à améliorer::

  • encoder l'adresse mail dans l'adresse de retour
  • changer l'expéditeur (moi, j'ai rien contre disconnect -- -- WikiSgnb <<DateTime(2007-03-29T19:16:32Z)>>)
  • mettre un message plus explicatif

Logs

État des lieux:: Parfois, quelqu'un de non-nounou a besoin de pouvoir accéder à certains logs. Par exemple, le bureau, pour voir l'utilisation des fichiers copyrightés, ou un apprenti, pour voir ou tester un script...

Discussion:: on abandonne le groupe logs et on gère les accès par ACL au cas par cas. Par contre, il faudrait trouver un moyen de centraliser et suivre l'attribution des ACLs, sinon on risque de se retrouver avec un tas de fichiers avec des ACLs « fantômes ». Solutions proposées :

  • un script et/ou fichier de conf commité dans le CVS qui fixe les ACLs (voir si un tel système n'existe pas déjà)
  • effacer toutes les ACLs régulièrement

Passage du Père Noël

On a reçu ce matin ce qui a été commandé le 13 mars, sauf 5 kits POE. Tout le contenu n'a pas encore été vérifié (en cours).

Impressions à chaud :

  • Armoire : très classe
  • Disques durs : mignons tout plein
  • KVM IP : le client est une applet ActiveX. Quelqu'un a-t-il une solution ?
    • Il ne cause pas VNC ou rdesktop ? pas documenté en tout cas -- WikiSgnb <<DateTime(2007-03-29T22:07:54Z)>>
  • Baptême : le nouveau serveur 8 cœurs a été appelé « fx », approuvé à l'unanimité des personnes qui étaient d'accord.

Impressions diverses sur fx :

  • le live-CD d'Ubuntu ne détecte que 3,2 Go de RAM (le BIOS en détecte bien 4 Go)
    • Normal, faut un noyau highmem avec support > 4 Go (sinon, le Go restant est pour le noyau)
  • le centre de contrôle de gnome n'affiche que 6 processeurs (bugreport à envoyer)
  • interface iLO 2 qui obsolète le KVM IP (applet Java cette fois-ci)
    • si c'est de l'IPMI, il y a les outils pour dans Debian

OVH

Installé :

  • VPN/CVS/cfengine

À faire :

  • Correction de la base LDAP (quel est le problème ?)
  • Migration du common_etc vers cfengine en cours
  • Postfix
  • DNS
  • Backup sur Pegase
  • Munin/Monit
  • Fallback du VPN sur la connexion de secours

Reporté à plus tard

  • Todolist
  • Cableurs