224 lines
7.4 KiB
Markdown
224 lines
7.4 KiB
Markdown
# Réunion Nounous
|
||
|
||
* Date : Jeudi 10 janvier 2013
|
||
* Lieu : Condorcet
|
||
* Début : 19h16
|
||
* Fin : 21h36
|
||
|
||
# Présents
|
||
|
||
* Ariane Soret
|
||
* Daniel Stan
|
||
* Lucas Serrano
|
||
* Olivier Iffrig
|
||
* Pauline Pommeret
|
||
* Pierre-Elliott Bécue
|
||
* Raphaël Bonaque
|
||
* Raphaël Cauderlier
|
||
* Valentin Samir
|
||
* Vincent Le Gallic
|
||
* Yann Duplouy
|
||
|
||
# Ordre du jour
|
||
|
||
## Gmail
|
||
|
||
## Depuis mi-décembre, Gmail refuse de récupérer les mails depuis les serveurs
|
||
## dont il ne reconnaît pas la validité de l'autorité de certification, CACert
|
||
## faisant partie des autorités non reconnues
|
||
Depuis le 12/12/12, Gmail a changé sa politique de vérification des certificats
|
||
SSL, CAcert ne fait plus partie des autorités de certification reconnues comme
|
||
"de confiance" et les utilisateurs ne peuvent pas changer ce comportement.
|
||
|
||
Les adhérents Cr@ns ne peuvent donc plus relever leurs mails Cr@ns sur leur
|
||
boîte Gmail.
|
||
|
||
La situation et la marche à suivre pour les adhérents sont ici :
|
||
https://wiki.crans.org/VieCrans/GMailSucks
|
||
|
||
Le Cr@ns pourrait proposer un autre serveur imap avec un certificat d'une autre
|
||
autorité.
|
||
En dehors du problème idéologique et de "flemme", cette solution implique tout
|
||
de même de continuer à encourager les adhérent à donner leur mot de passe Cr@ns
|
||
à Google.
|
||
|
||
L'avis général semble être plutôt de rester dans la situation actuelle.
|
||
Daniel (avec un apprenti [les absents, levez la main]) va tout de même essayer
|
||
de mettre en place un serveur imap alternatif.
|
||
|
||
Valentin soulève la question d'un mot de passe alternatif (optionnel) permettant
|
||
de s'authentifier sur les serveurs mail / imap / ... seulement.
|
||
À voir si c'est possible.
|
||
|
||
## SIP
|
||
|
||
Le SIP (Session Initiation Protocol) est un protocole de signalement
|
||
permettant de mettre en relation deux pairs. Il est principalement
|
||
utilisé dans le cadre de la téléphonie sur Internet (Voix sur IP).
|
||
|
||
{{{asterisk}}} a été ressuscité et le Cr@ns possède une ligne SIP chez OVH.
|
||
Le service a donc été mis en place et est maintenant disponible pour les
|
||
adhérents.
|
||
Modulo l'installation d'un client SIP et une connexion internet,
|
||
les adhérents peuvent donc téléphoner. Dans un premier temps entre comptes SIP
|
||
Cr@ns, mais il y a également une passerelle vers l'extérieur.
|
||
|
||
L'interface sur l'intranet2 permet l'inscription, la gestion de sa configuration
|
||
(mot de passe, code perso de la messagerie, se masquer dans l'annuaire), un
|
||
annuaire…
|
||
|
||
Pour les utilisateurs, c'est en test : https://intranet2.crans.org/voip/
|
||
|
||
Reste à faire :
|
||
|
||
* Documentation technique
|
||
* Documentation d'utilisation (Yann s'occupe d'Android, iOS ?)
|
||
* Facturation de la passerelle (prix coûtant? On utilise le compte impression?)
|
||
* Service d'impression ? (notification des impressions, dictée du digicode)
|
||
* Numéro unique vers la Nounou d'astreinte ?
|
||
|
||
Bref, il y a plein de possibilités.
|
||
|
||
## DNS
|
||
|
||
### DNSSEC
|
||
|
||
DNSsec est une extension du protocole DNS qui permet de signer numériquement
|
||
les réponses des requêtes DNS.
|
||
|
||
Elle (l'extension) a été mise en place par Valentin sur le domaine
|
||
{{{crans.eu}}}.
|
||
|
||
À terme, il serait bien de signer {{{crans.org}}}
|
||
|
||
Il n'est pas possible pour un serveur de répondre qu'il a effectuer une
|
||
validation
|
||
dnssec s'il est autoritaire pour la réponse.
|
||
Il pourrait être bien de séparer DNS récursif et autoritaires.
|
||
|
||
### Renouvellement nom de domaine
|
||
|
||
{{{crans.fr}}} expire dans une cinquantaine de jours. Il ''faut'' le renouveler.
|
||
Olivier s'en occupe.
|
||
|
||
### Champs DNS
|
||
|
||
Valentin a rajouté un champ TXT dans les réponses DNS des bornes wifi,
|
||
qui contient : {{{"LOC %f,%f" % (latitude, longitude)}}}.
|
||
|
||
Il désirerait aussi rajouter un champ SSHFP pour pouvoir transmettre les
|
||
fingerprints SSH des serveurs. Combiné à DNSSEC, cela permettrait de s'assurer
|
||
de l'absence de Man in the Middle quand on se connecte à un serveur en SSH.
|
||
|
||
À étudier plus profondément.
|
||
|
||
## Documentation Sphinx
|
||
|
||
## Olivier a mis en place de quoi documenter le nouveau binding LDAP avec Sphinx
|
||
C'est une librairie pour python qui permet de générer automatiquement de la
|
||
documentation.
|
||
|
||
Olivier l'a mise en place pour {{{lc_ldap}}}. C'est beau, il faut continuer.
|
||
|
||
## Wifi
|
||
|
||
Le bâtiment M est couvert sur tous les étages sauf le 4ème et le 5ème Nord.
|
||
Le bâtiment A est couvert aux étages pairs.
|
||
Le reste est à faire.
|
||
|
||
On va fixer un rendez-vous régulier, par exemple le dimanche une fois tous les
|
||
quinze jours.
|
||
|
||
## IRC
|
||
|
||
Dancer-ircd, le daemon IRC actuel, ne semble plus très maintenu et manque de
|
||
features, principalement un support de SSL et de l'ipv6.
|
||
On souhaiterait donc changer de daemon pour quelque chose de plus moderne.
|
||
|
||
UnrealIRCd semble bien mais n'est pas package pour Debian (voir
|
||
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=515130)
|
||
|
||
daemons packages sous squeeze :
|
||
|
||
* dancer-ircd
|
||
* inspircd
|
||
* ircd-hybrid
|
||
* ircd-irc2
|
||
* ircd-ircu
|
||
* ircd-ratbox
|
||
* ngircd
|
||
|
||
Supportant SSL d'apres
|
||
https://en.wikipedia.org/wiki/Comparison_of_Internet_Relay_Chat_daemons
|
||
|
||
* inspircd
|
||
* ircd-hybrid
|
||
* ircd-ratbox
|
||
* ngircd
|
||
|
||
Supportant l'IPv6 d’après la même page: tous
|
||
|
||
inspircd ftw ?
|
||
|
||
Pierre-Elliott va se pencher sur inspircd qui a l'air packagé, supportant SSL,
|
||
IPv6 et pas trop "pain in the ass" à configurer.
|
||
|
||
Il faudra contre-annoncer pour dire que finalement on ne fera pas de changement
|
||
Dimanche.
|
||
|
||
## Mail
|
||
|
||
### Champ mail dans la base LDAP
|
||
|
||
Le champ mail a été modifié dans la base LDAP pour pouvoir être utilisé
|
||
par !SoGo
|
||
(c'est-à-dire que l'on enregistre dans tous les cas une adresse mail, et non le
|
||
login lorsque l'adhérent a un compte Cr@ns). PE avait effectué dans un premier
|
||
temps la modification sur son propre compte afin de chasser les bugs dans les
|
||
scripts qui supposaient manipuler un login (et non une adresse mail).
|
||
|
||
### Réécriture des en-têtes mail
|
||
|
||
Pendant un certain moment, dans les mails envoyés et reçus, toutes les adresses
|
||
mails envoyées et reçues étaient automatiquement remplacées par
|
||
Prenom.Nom@crans.org (''i.e.'' l'alias canonique). Cette réécriture a été
|
||
désormais
|
||
désactivée, ce qui a posé des problèmes pour déterminer le destinataire final
|
||
du mail et il a fallu corriger après coup les filtres de recherches dans
|
||
la configuration postfix.
|
||
|
||
Ceci explique quelques dysfonctionnements dans l'acheminement des mails pendant
|
||
environ une semaine.
|
||
|
||
## Tests de configuration des services
|
||
|
||
Suite à ces problèmes, iota propose la mise en place de serveurs alternatifs
|
||
afin de tester les configurations de services critiques.
|
||
PEB a remplacé les adresses mail dans la base LDAP par leur version avec
|
||
@crans.org. On a en même temps supprimé la réécriture d'en-tête des emails.
|
||
Cela a malheureusement engendré des bugs, et la perte de mails.
|
||
|
||
De manière générale, il faut faire attention lorsqu'on touche à des services
|
||
critiques en place dont on ne maîtrise pas la façon dont ils loguent
|
||
(dovecot, postfix), bien lire la doc, et surtout demander aux développeurs
|
||
des services si on a un doute concernant une fonctionnalité.
|
||
|
||
## Bug tracking, projets
|
||
|
||
On a deux bug trackers, debbugs (http://bugs.crans.org) et
|
||
redmine (https://tracker.crans.org), plus éventuellement des todolists sur le
|
||
wiki.
|
||
L'idée est de se décider sur lequel on utilise. On garde redmine.
|
||
|
||
Raphaël propose également d'utiliser une catégorie wiki !CategorieProjetEnCours.
|
||
|
||
## Passage à Git
|
||
|
||
Deux outils de versionnement présente plusieurs inconvénients :
|
||
|
||
* Plus de commandes à connaître, et risque de s'embrouiller
|
||
* Nos dépôts darcs ne sont pas à jour.
|
||
|
||
On se propose de passer nos dépôts darcs sous git.
|
||
Vincent et Daniel s'en occupent et encadreront Pauline.
|