|
Taille: 3517
Commentaire:
|
← Version 8 à la date du 2015-02-19 08:06:20 ⇥
Taille: 3543
Commentaire:
|
| Texte supprimé. | Texte ajouté. |
| Ligne 1: | Ligne 1: |
| ## page was renamed from CompteRendusCrans/CompteRenduNounousTemplate | ## page was renamed from ComptesRendusCrans/Jeudi8Janvier2015 |
| Ligne 6: | Ligne 6: |
| * Date : 08/01/2015 | * Date : Jeudi 8 janvier 2015 |
| Ligne 21: | Ligne 21: |
| Reste à lui trouver une place sur le campus Les présents décident de l'installer au 0H à faire un soir entres deux backups. |
Il reste à lui trouver une place sur le campus. Les présents décident de l'installer au 0H, à faire un soir entre deux backups. |
| Ligne 25: | Ligne 27: |
| Gabriel rapelle que getlogwifi est maitenant un daemon qui sert a ouvrir des connexions SSH vers toutes les bornes et d'en récupérer les logs. Il reste à faire en sorte que ce script renvoie les logs directement vers rsyslog et non pas dans un fichier (sic) comme c'est le cas actuellement. |
Gabriel rappelle que getlogwifi est maintenant un démon qui sert à ouvrir des connexions SSH vers toutes les bornes et d'en récupérer les logs. Il reste à faire en sorte que ce script renvoie les logs directement vers rsyslog et non pas dans un fichier (sic) comme c'est le cas actuellement. |
| Ligne 29: | Ligne 32: |
| Il semblerait que l'attribution d'une IP via une connexion 5GHz soit très lente... Il faut investiger |
Il semblerait que l'attribution d'une IP via une connexion 5GHz soit très lente… Il faut investiguer. |
| Ligne 32: | Ligne 35: |
| === Kludge des Ipv4 Wifi === | |
| Ligne 33: | Ligne 37: |
| === Kludge des IPv4 WiFi === | Cf http://git.crans.org/?p=usr-scripts.git;a=commitdiff;h=275934c23c944a2fe711a29bed71b4020833929b |
| Ligne 35: | Ligne 39: |
| Cf http://git.crans.org/?p=usr-scripts.git;a=commitdiff;h=275934c23c944a2fe711a29bed71b4020833929b But de la manœuvre: beaucoup (~2000 ?) de machines inscrites en WiFi, avec souvent des mac restées en <automatique> donc jamais vraiment utilisées. Le système voulait en revanche que l'ipv4 soit assignée à l'avance, ce qui nous saturait notre slash ipv4 wifi. |
But de la manœuvre : beaucoup (~2000 ?) de machines inscrites en WiFi, avec souvent des mac restées en <automatique> donc jamais vraiment utilisées. Le système voulait en revanche que l'ipv4 soit assignée à l'avance, ce qui nous saturait notre slash ipv4 WiFi. |
| Ligne 41: | Ligne 44: |
| J'ai donc rapidement patché ldap_crans et cie pour autoriser l'absence d'ipv4 sur une machine, et fait en sorte que l'ipv4 soit assignée à la première |
Daniel a donc rapidement patché ldap_crans et cie pour autoriser l'absence d'ipv4 sur une machine, et fait en sorte que l'ipv4 soit assignée à la première |
| Ligne 44: | Ligne 47: |
| machine n'a pas de champs ldap "ipHostNumber" (<automatique> posait problème), | machine n'a pas de champs ldap "ipHostNumber" ("<automatique>" posait problème), |
| Ligne 46: | Ligne 49: |
| calculée à partir de là. | calculée à partir de là. |
| Ligne 48: | Ligne 51: |
| Pour l'instant, ça marche, mais je suis d'accord que ce n'est pas une solution totalement pérenne. |
Pour l'instant, ça marche, même s'il ne s'agit pas d'une solution totalement pérenne. |
| Ligne 52: | Ligne 55: |
| jamais connectées: jepense que cela nous sera bien trop coûteux de debugger | jamais connectées : il pense que cela nous sera bien trop coûteux de déboguer |
| Ligne 54: | Ligne 57: |
| n'existent plus. En plus, ça polluera encore l'image du Wifi en tant que service "qui marche pas ®©". |
n'existent plus. En plus, ça polluera encore l'image du WiFi en tant que service "qui marche pas"®©. |
| Ligne 57: | Ligne 60: |
| PE et Raphaël préferent détruire les machines WiFi qui restent inactives pendant plus de 3 mois quitte à envoyer un mail aux adhérents concernés. | Pierre-Elliott et Raphaël préfèrent détruire les machines WiFi qui restent inactives pendant plus de 3 mois quitte à envoyer un mail aux adhérents concernés. |
| Ligne 59: | Ligne 63: |
| === Câbleuse 2.1 === Daniel bidouille une nouvelle version de la câbleuse/ticketteuse à base de rpi au |
=== Câbleuse 2.1 === Daniel bidouille une nouvelle version de la câbleuse/ticketteuse à base de rpi au |
| Ligne 62: | Ligne 66: |
| Un des objectifs est d'avoir quelque chose de résilient aux pannes de courant de la Kfet'. De la doc va venir, aussi. | Un des objectifs est d'avoir quelque chose de résilient aux pannes de courant de la Kfet'. De la doc va venir, aussi. |
| Ligne 66: | Ligne 71: |
| On va pas tarder à dist-upgrade il faudra trouver des motivés et annoncer les mises à jour des services critiques. | On ne va pas tarder à dist-upgrade il faudra trouver des motivés et annoncer les mises à jour des services critiques. |
| Ligne 68: | Ligne 75: |
| Django à un module d'administration ldap (django-ldapdb https://github.com/jlaine/django-ldapdb) ca simplifieraint grandement la gestion des attributs et des logs. Cela permettrait surtout d'avoir un binding maitenu, plus simple à comprendre et plus léger. En plus on pourrait facilement adapter une interface web pour le cablage. Aucune urgence mais il serait intéressant de réflechir un peu a cette piste et continuer à se renseigner. |
Django a un module d'administration ldap (django-ldapdb https://github.com/jlaine/django-ldapdb). Ça simplifierait grandement la gestion des attributs et des logs et cela permettrait surtout d'avoir un binding maintenu, plus simple à comprendre et plus léger. En plus, on pourrait facilement adapter une interface web pour le câblage. Aucune urgence mais il serait intéressant de réfléchir un peu à cette piste et continuer à se renseigner. |
Sommaire
Réunion du Collège Technique
- Date : Jeudi 8 janvier 2015
- Lieu : Pavillon des Jardins
- Début : 19h12
- Fin : 19h56
Présents
- Gabriel Détraz
- Raphaël-David Lasseri
- Pierre-Elliott Bécue
Ordre du jour
Serveur de backups
Omnomnom est en marche, il backup les homes des adhérents \o/
Il reste à lui trouver une place sur le campus.
Les présents décident de l'installer au 0H, à faire un soir entre deux backups.
Mise à jour vers Barrier Breaker (bornes wifi)
Gabriel rappelle que getlogwifi est maintenant un démon qui sert à ouvrir des connexions SSH vers toutes les bornes et d'en récupérer les logs.
Il reste à faire en sorte que ce script renvoie les logs directement vers rsyslog et non pas dans un fichier (sic) comme c'est le cas actuellement.
Bornes Unifi 5Ghz
Il semblerait que l'attribution d'une IP via une connexion 5GHz soit très lente… Il faut investiguer.
Kludge des Ipv4 Wifi
Cf http://git.crans.org/?p=usr-scripts.git;a=commitdiff;h=275934c23c944a2fe711a29bed71b4020833929b
But de la manœuvre : beaucoup (~2000 ?) de machines inscrites en WiFi, avec souvent des mac restées en <automatique> donc jamais vraiment utilisées. Le système voulait en revanche que l'ipv4 soit assignée à l'avance, ce qui nous saturait notre slash ipv4 WiFi.
Daniel a donc rapidement patché ldap_crans et cie pour autoriser l'absence d'ipv4 sur une machine, et fait en sorte que l'ipv4 soit assignée à la première connexion (dans freeradius), en même temps que la mac. Plus précisément, la machine n'a pas de champs ldap "ipHostNumber" ("<automatique>" posait problème), ni de champ ldap "rid". On assigne un rid valide à la machine, et l'ipv4 est calculée à partir de là.
Pour l'instant, ça marche, même s'il ne s'agit pas d'une solution totalement pérenne.
Par contre, Daniel est formellement contre l'effacement systématique de machines jamais connectées : il pense que cela nous sera bien trop coûteux de déboguer les connexions WiFi d'adhérents qui essayeront de rentrer des logins qui n'existent plus. En plus, ça polluera encore l'image du WiFi en tant que service "qui marche pas"®©.
Pierre-Elliott et Raphaël préfèrent détruire les machines WiFi qui restent inactives pendant plus de 3 mois quitte à envoyer un mail aux adhérents concernés.
Câbleuse 2.1
Daniel bidouille une nouvelle version de la câbleuse/ticketteuse à base de rpi au format compact (découpé avec amour, à la perceuse, dans une boite de Ferrero), stay tuned. Un des objectifs est d'avoir quelque chose de résilient aux pannes de courant de la Kfet'. De la doc va venir, aussi.
Remarques diverses
Passage à Jessie
On ne va pas tarder à dist-upgrade il faudra trouver des motivés et annoncer les mises à jour des services critiques.
Binding ldap
Django a un module d'administration ldap (django-ldapdb https://github.com/jlaine/django-ldapdb). Ça simplifierait grandement la gestion des attributs et des logs et cela permettrait surtout d'avoir un binding maintenu, plus simple à comprendre et plus léger. En plus, on pourrait facilement adapter une interface web pour le câblage.
Aucune urgence mais il serait intéressant de réfléchir un peu à cette piste et continuer à se renseigner.