|
Taille: 337
Commentaire:
|
Taille: 5285
Commentaire: OTL !
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| ## page was renamed from CompteRendusCrans/Jeudi06Février2014 | |
| Ligne 5: | Ligne 6: |
| * Date : 6 février 2014 | * Date : Jeudi 6 février 2014 |
| Ligne 8: | Ligne 9: |
| * Fin : | * Fin : 20h30 |
| Ligne 12: | Ligne 13: |
| === Interface de cranspassword avec ldap === | === 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épot git de bcfg2. Pas d'objection cinglante. |
| Ligne 15: | Ligne 47: |
Valentin a réécrit le script bind.py de génération du DNS. C'est moins monolitique, 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 [[CransTechnique/CaCert|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. |
Sommaire
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épot 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 monolitique, 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.