130 lines
4.7 KiB
Markdown
130 lines
4.7 KiB
Markdown
# 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
|