142 lines
5.2 KiB
Markdown
142 lines
5.2 KiB
Markdown
# Réunion du Collège Technique
|
||
|
||
* Date : 20 février 2014
|
||
* Lieu : Salle de conférence du Pavillon des Jardins
|
||
* Début : 19h19
|
||
* Fin : 21h00
|
||
|
||
## Présents
|
||
|
||
* Ariane Soret
|
||
* Aymeric Labatut
|
||
* Daniel Stan
|
||
* Lucas Serrano
|
||
* Jordan Delorme
|
||
* Raphaël-David Lasseri
|
||
* Riwan Kherouf
|
||
* Valentin Samir
|
||
|
||
## Ordre du jour
|
||
|
||
### Digicode
|
||
|
||
Lucas a mis en place le nouveau digicode_server et gen_code sur intranet2 et
|
||
sur asterisk.
|
||
Pour générer un code à partir de l'intranet2, il faut accéder à l'interface
|
||
admin de django.
|
||
Sinon, on peut toujours en générer sur l'intranet1…
|
||
|
||
### lc_ldap
|
||
|
||
Valentin a surchargé les attributs de lc_ldap pour permettre une comparaison
|
||
plus simple (et fonctionnelle) entre des objets ldap.
|
||
L'égalité fonctionne de façon sémantique sur les objets et les attributs comme
|
||
on pourrait s'y attendre (du coup {{{'club' in
|
||
club['objectClass']}}} fonctionne).
|
||
Les attributs peuvent être instanciés par leur type python correspondant (au
|
||
lieu de juste des unicodes).
|
||
Si deux attributs sont égaux, ils ont le même hash (cf. set et hashtable).
|
||
Les attributs pythons des attributs ldap Attr sont directement accessibles
|
||
comme des attributs d'Attr.
|
||
Les {{{machines['historique'].append()}}} fonctionnent comme on pourrait s'y
|
||
attendre et plein d'autres bonnes choses !
|
||
|
||
D'une manière générale, si on a besoin d’accéder à {{{attrs}}} sur
|
||
les !CransLdapObject ou à {{{value}}} sur les Attr,
|
||
c'est qu'il manque, sans doute, une méthode à écrire ou surcharger quelque part.
|
||
|
||
### Enregistrement automatique des adresses MAC
|
||
|
||
Daniel arrive à faire de l'authentification radius pour le WPA2 sans utiliser
|
||
le module radius dédié à cela mais en utilisant un script python.
|
||
Lors de l'authentification d'un client sur une borne, la borne met en relation
|
||
radius et le client, et radius l'authentifie avant de renvoyer le résultat à la
|
||
borne.
|
||
|
||
Une idée en utilisant un script custom serait de pouvoir ne fournir aux
|
||
adhérents, lors de l'enregistrement d'une nouvelle machine wifi, que le nom
|
||
d'utilisateur et le mot de passe. Puis de remplir l'adresse mac de la machine
|
||
seulement lors de la première authentification réussie en utilisant celle de la
|
||
première machine qui s'authentifie.
|
||
|
||
Les gens présents ont l'air assez enthousiastes pour le wifi. Une option
|
||
similaire en filaire reste à discussion.
|
||
|
||
Il serait également bien que la première fois que l'adresse mac est
|
||
enregistrée, comme la machine vient de se connecter, qu'elle puisse accéder à
|
||
internet. Pour le dhcp, la mise à jour est déjà instantanée. Il manque la mise
|
||
à jour du pare-feu, au moins celui de komaz.
|
||
|
||
Valentin propose une solution à partir d'une clef ssh n'ayant que le droit de
|
||
trigger l'appel à generate en s'inspirant
|
||
de [[CransTechnique/AdminRéseau/CommunicationsParSshEntreLesServeurs]].
|
||
Nicolas aurait parlé d'une solution rabbitmq qui pourrait à terme remplacer le
|
||
système maison generate.
|
||
|
||
### intranet2
|
||
|
||
#### Création de compte wiki
|
||
|
||
Fait.
|
||
|
||
#### Gestion des clefs ssh
|
||
|
||
Valentin a ajouté la possibilité de remplacer les attributs sshFingerprint de
|
||
ses propres machines. Ils sont alors publiés dans le DNS du crans.
|
||
|
||
### DNS
|
||
|
||
#### TLSA
|
||
|
||
Valentin rappelle brièvement que TLSA est un enregistrement DNS permettant de
|
||
vérifier la validité d'une clef publique du standard x509 via le DNS.
|
||
|
||
Pour pouvoir permettre aux adhérents de publier, dans le DNS de leur machine,
|
||
leur certificat, il faudrait ajouter un nouvel objet ldap enfant des objets
|
||
machines (n'a pas de sens en LDAP) qui aurait en attribut :
|
||
|
||
* name : les noms de domaine pour lesquels le certificat est
|
||
utilisé (multivalué)
|
||
* port : les ports sur lesquels le certificat est utilisé (multivalué)
|
||
* proto : tcp ou udp (multivalué)
|
||
* cert : quelque chose représentant le certificat (monovalué)
|
||
* certtype : le type d'enregistrement ; 0 = CA pinning, 1 = cert
|
||
pinning, 2 = self trusted CA, 3 = self trusted cert (monovalué)
|
||
* reftype : 0 = plain cert, 1 = sha256, 2 = sha512 (monovalué)
|
||
|
||
À voir si on veut utiliser l'objet pour gérer les certificats d'une manière
|
||
générale…
|
||
|
||
#### Blocage via response policy zone
|
||
|
||
Valentin avait lors de l'install party précédente mis en place un DNS menteur
|
||
renvoyant archive.ubuntu vers
|
||
le miroir local.
|
||
Récemment il a étendu le rôle du DNS menteur à la zone crans pour empêcher les
|
||
IP utilisés par
|
||
Teredo (tunnel v6 propre aux machines sous windows) de contacter le DNS et
|
||
ainsi de faire de l'IPv6 pirate.
|
||
Théoriquement la future présence de RA pirates sur le réseau ne serait donc
|
||
plus fortuite
|
||
(en tout cas beaucoup moins).
|
||
|
||
### Remplacement de ovh
|
||
|
||
Une nouvelle machine est prête pour remplacer ovh : soyouz.
|
||
''A priori'', Valentin a fini sa configuration. Il faut juste modifier les
|
||
enregistrements du dns (MX et NS et glue record) pour remplacer ovh.
|
||
le TLSSTART en smtp ne marche pas, il faudrait juste mettre une paire de clefs.
|
||
|
||
On va rendre ovh, il faudrait donc prendre le temps de shred les disques en
|
||
rescue mode.
|
||
|
||
### Question diverse
|
||
|
||
#### Migration XEN -> Proxmox
|
||
|
||
Daniel propose de faire une séance migration samedi après-midi (tôt pour ne pas
|
||
concurrencer la LAN A♡).
|
||
Les volontaires ne lèvent pas tous le doigt en même temps.
|
||
Daniel annonce donc une « petite » maintenance sur CransIncidents et sur les
|
||
news.
|