136 lines
4.9 KiB
Markdown
136 lines
4.9 KiB
Markdown
# Réunion du Collège Technique
|
||
|
||
* Date : Jeudi 6 février 2014
|
||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||
* Début : 19h00
|
||
* Fin : 20h30
|
||
|
||
## Présents
|
||
|
||
## Ordre du jour
|
||
|
||
### Interfaçage de cranspassword avec ldap
|
||
|
||
On a rajouté un attribut gpgMail (en plus du gpgFingerprint) dans la base ldap.
|
||
Il est fonctionnel dans le nouveau binding, mais pas encore dispo dans
|
||
gest_crans.
|
||
Daniel a écrit un script qui génère la configuration de cranspassword serveur à
|
||
partir de la base ldap (en se servant des attributs droits, gpgFingerPrint et
|
||
gpgMail).
|
||
Pour le moment, la base a été peuplée (pour l'attribut gpgMail) pour tous les
|
||
gens qui avaient donné une fingerprint.
|
||
|
||
Il sera bientôt mis en production.
|
||
Question : modifie-t-on la configuration de manière automatique (via un cron)
|
||
ou requiert-on une intervention humaine pour confirmer les modifications de
|
||
droits ? On décide de garder un système de confirmation avant d'appliquer les
|
||
modifications (à la bcfg2) pour rendre la chose failproof.
|
||
|
||
Todo : écrire une application sur l'intranet2 (dans mon compte) pour enregistrer
|
||
les fingerprint/mail.
|
||
|
||
### apt-key
|
||
|
||
Le crans possède un dépôt custom pour les paquets qu'il crée pour lui même (par
|
||
exemple bcfg2).
|
||
Ces paquets sont alors signés par une nounou (avec sa clef gpg). Aussi, faut-il
|
||
installer ces clefs sur les serveurs dans la configuration d'apt pour pouvoir
|
||
installer les paquets sans warning.
|
||
Les clefs sont dans bcfg2.
|
||
Rappel: il y a un
|
||
script {{{/usr/scripts/gestion/tools/apt-keys-crans.py}}} pour mettre à
|
||
jour les clefs sur bcfg2.
|
||
|
||
Pour le moment il est exécuté manuellement. Valentin propose de le croner et de
|
||
retirer les fichier générer du dépôt git de bcfg2.
|
||
|
||
Pas d'objection cinglante.
|
||
|
||
### Génération du dns
|
||
|
||
Valentin a réécrit le script bind.py de génération du DNS. C'est moins
|
||
monolithique, plus POO et ça utilise lc_ldap.
|
||
Changement notable : Les machines ont leur IPv6 d'annoncée par défaut par leur
|
||
nom de domaine.
|
||
|
||
* {{{nom.v4}}} retourne seulement l'IPv4.
|
||
* {{{nom.v6}}} seulement l'IPv6.
|
||
|
||
Il y a une case à cocher dans l'intranet2 dans l'application machines pour
|
||
désactiver ou réactiver ce comportement.
|
||
|
||
Deux trois problèmes:
|
||
|
||
* {{{freebox}}} et {{{ovh}}} ont des IPv6 erronées dans la base
|
||
ldap (IPv6 locales) -> plus joignables une fois annoncée dans le DNS
|
||
* {{{zbee}}} -> pour des raisons de NFS qui essayait de se monter en IPv6 à
|
||
travers le pare-feu
|
||
* munin -> les acl des nodes n'autorisaient pas l'IPv6 (connexion refused) ce
|
||
qui empêchait le fallback IPv4
|
||
|
||
### IPv6
|
||
|
||
Daniel a reregardé Huricann-Electrics : le plan était d'adhérer à Gitoyen pour
|
||
pouvoir lui demander un numéro d'AS (Autonomous System) et des IPv6.
|
||
Niveau coût il faudrait payer l'adhésion à Gitoyen (entre 100 et 200€) plus des
|
||
frais
|
||
administratifs (entre 200 et 300€).
|
||
Pierre-Elliott fait remarquer qu'on adhère à FedeRez pour un prix plus élevé.
|
||
Niveau administratif, il faut étudier la question (demander au CA).
|
||
|
||
Valentin fait remarquer que quand bien même, avoir ses propres IPs serait bien
|
||
sympathique, il faut s'assurer de pouvoir les utiliser le jour où l'ENS passe
|
||
en IPv6. Aujourd'hui pour annoncer ses propres IPs via H-E, le tunnel de sortie
|
||
se trouve à Londres au lieu de Paris. Ce qui fait passer le RTT de 1ms à 8ms.
|
||
|
||
### CaCert et clubs
|
||
|
||
L'idée est de générer des certificats SSL !CaCert pour les machines de clubs
|
||
qui en font la demande.
|
||
|
||
Sur le principe ok. Seul problème : si la machine est détruite, le certificat
|
||
existe toujours alors que le domaine peut être utilisé par quelqu'un d'autre.
|
||
|
||
Soit on révoque directement les certificats quand la machine disparaît, via
|
||
une API (qui n'a pas l'air dispo pour l'instant
|
||
sur CaCert.
|
||
|
||
Soit on empêche les opérations sur les machines qui ont toujours un certificat
|
||
valide.
|
||
|
||
API à étudier : <http://wiki.cacert.org/Software/IntegrationInterface>
|
||
<http://wiki.cacert.org/SubRoot>
|
||
|
||
Il serait bien d'avoir une interface sur l'intranet2 (étendre l'interface de
|
||
machine)
|
||
pour permettre de faire des demandes de certificats (et si l'API de !CaCert ne
|
||
marche pas,
|
||
une interface pour y répondre manuellement).
|
||
|
||
### Digicode
|
||
|
||
Lucas a rajouté une option sur l'app digicode pour créer des codes. Ça a l'air
|
||
de marcher.
|
||
|
||
Reste plus qu'à migrer le tout.
|
||
|
||
### Édition .forward
|
||
|
||
Raphaël-David a fait un script pour éditer des {{{.forward}}}. Reste à régler
|
||
le problème de droits d'exécution du script (qui s’exécute en root pour
|
||
l'instant).
|
||
Il pourrait être envisagé de donner le droit au groupe respbats d’exécuter le
|
||
script en temps que n'importe qui du groupe user et de le lancer en temps que
|
||
l'user dont on veut éditer le .forward (cf ce qui est actuellement fait pour
|
||
l'intranet1).
|
||
|
||
### ft
|
||
|
||
Il est installé au 0B physiquement et logiciellement. Ça marche.
|
||
Il ne reste qu'à finir les migrations depuis Xen.
|
||
|
||
### Wifi
|
||
|
||
La DSI abandonne le ssid ENS Cachan. On arrête donc définitivement de le
|
||
diffuser.
|