4993
Commentaire:
|
5052
|
Texte supprimé. | Texte ajouté. |
Ligne 5: | Ligne 5: |
* Date : 6 février 2014 | * Date : Jeudi 6 février 2014 |
Ligne 22: | Ligne 22: |
Question: modifie-t-on la configuration de manière automatique (via un cron) | Question : modifie-t-on la configuration de manière automatique (via un cron) |
Ligne 33: | Ligne 33: |
Ces paquets sont alors signé par une nounou (avec sa clef gpg). Aussi, faut-t-il | Ces paquets sont alors signés par une nounou (avec sa clef gpg). Aussi, faut-il |
Ligne 38: | Ligne 38: |
jour les clef sur bcfg2. | jour les clefs sur bcfg2. |
Ligne 41: | Ligne 41: |
retirer les fichier générer gu dépot git de bcfg2. | retirer les fichier générer du dépot git de bcfg2. |
Ligne 47: | Ligne 47: |
Valentin à réécrit le script bind.py de génération du dns. C'est moins | Valentin a réécrit le script bind.py de génération du dns. C'est moins |
Ligne 49: | Ligne 49: |
Changement notable : Les machines ont leur ipv6 d'annoncé par défaut par leur | Changement notable : Les machines ont leur IPv6 d'annoncé par défaut par leur |
Ligne 51: | Ligne 51: |
nom.v4 retourne seulement ipv4 nom.v6 seulement l'ipv6 |
* {{{nom.v4}}} retourne seulement l'IPv4. * {{{nom.v6}}} seulement l'IPv6. |
Ligne 57: | Ligne 57: |
Deux trois probs: * freebox, ovh ont des ipv6 erronées dans la base ldap (ipv6 locales) -> plus joinable une fois annoncée dans le dns * zbee -> pour des raisons de nfs qui essayait de se monter en ipv6 à travers le parefeu * munin -> les acl des nodes n'autorisaient pas l'ipv6 (connexion refused) ce qui empêchait le fallback ipv4 |
Deux trois problèmes: * freebox, ovh ont des IPv6 erronées dans la base ldap (IPv6 locales) -> plus joinable une fois annoncée dans le dns * zbee -> pour des raisons de nfs qui essayait de se monter en IPv6 à travers le parefeu * munin -> les acl des nodes n'autorisaient pas l'IPv6 (connexion refused) ce qui empêchait le fallback IPv4 |
Ligne 65: | Ligne 65: |
=== IpV6 === | === IPv6 === |
Ligne 67: | Ligne 67: |
Daniel à reregardé Huricann-Electrics : le plan était d'adhérer à gitoyen pour pouvoir lui demander un numéro d'AS et des ipv6. Niveau coût il faudrait : l'adhésion à Gitoyen (entre 100 et 200€) plus des frais administratif (entre 200 et 300€). Pierre-Elliott fait remarqué qu'on adhère à FédeRez pour un prix plus élevé. |
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 remarqué qu'on adhère à FedeRez pour un prix plus élevé. |
Ligne 74: | Ligne 74: |
Valentin fait remarquer que quand bien avoir ses propre ips serait bien | Valentin fait remarquer que quand bien avoir ses propres IPs serait bien |
Ligne 76: | Ligne 76: |
en ipv6. Aujourd'hui pour annoncer ses propros ips via H-E, le tunnel de sortie se trouve à londre au lieu de paris. Ce qui fait passer le RTT de 1ms à 8ms. |
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. |
Ligne 84: | Ligne 84: |
une API (qui n'a pas l'air dispo pour l'instant sur cacert). | une API (qui n'a pas l'air dispo pour l'instant sur CaCert). |
Ligne 93: | Ligne 93: |
pour permettre de faire des demandes de certificats (et si l'API de cacert ne marche pas, | pour permettre de faire des demandes de certificats (et si l'API de CaCert ne marche pas, |
Ligne 101: | Ligne 101: |
Raphaël-David a fait un script pour éditer des .forward. Reste à régler le problème de droit d'exécutions du script (qui s'éxecute en root pour l'instant). Il pourrait être envisagé de donner le droit au groupe respbats d'éxécuter le script en temps que n'importequi du groupe user et de le lancer en temps que l'user dont on veut éditer le .forward (cf ce qui es actuellement fait pour l'internet1) |
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'internet1). |
Ligne 109: | Ligne 109: |
La dsi abandonne le ssid ENS Cachan. On arrête donc définitivement de le diffuser. | 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épot 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 singlante.
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é 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, ovh ont des IPv6 erronées dans la base ldap (IPv6 locales) -> plus joinable une fois annoncée dans le dns
zbee -> pour des raisons de nfs qui essayait de se monter en IPv6 à travers le parefeu
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 remarqué 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 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
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'internet1).
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.