Différences entre les pages « Postfix et SASL » et « Installation logicielle de la caméra »

De Cliss XXI
(Différence entre les pages)
Sauter à la navigation Sauter à la recherche
imported>SylvainBeucler
m ('en clair' s'applique à MySQL, pas à auxprop_plugin)
 
 
Ligne 1 : Ligne 1 :
J'ai passé du temps à comprendre comment mettre en place une authentificationd dans Postfix (c'est à dire, demander un nom/mot de passe pour avoir le droit d'envoyer du courriel) - et encore plus de temps à comprendre comment Postfix et SASL communiquent.
+
Dans le cadre de Utopia 2005, '''CLISS XXI''' met en oeuvre une solution de visio conférence, reposant complètement sur des logiciels libres. Voici le descriptif technique, concernant l'installation de la caméra.
  
SASL (Simple Authentication Security Layer) est une bibliothèque qui regroupe un certain nombre de méthodes d'authentification, utilisables dans plusieurs applications.
+
Les différents postes informatiques concernés par la visio conférence sont équipés de micro et d'une caméra internet (web caméra, ou webcam).
  
Postfix fait appel à libsasl2, l'implémentation SASL de chez Cyrus, en tant que bibliothèque C intégrée au programme; le fichier de configuration est déterminé par:
+
En dehors des aspects logiciels (on verra plus loin la configuration de [['Configuration de Gnomemeeting' Gnomemeeting]]) il n'y a pas de problème particulier concernant la configuration du micro et des enceintes : ils sont physiquement connectés à la carte son, et il est possible de tester la bonne marche du dispositif simplement en parlant dans le micro. Les règlages divers (volume, basses, balance ...) peuvent être peaufinés, sous GNU/Linux, grâce à un logiciel tout simple, mais bien pratique, '''aumix''', qui peut s'utiliser même dans un terminal alphanumérique.
# des constantes dans le code source de Postfix et/ou dans les patches Debian (/etc/postfix/sasl:/usr/lib/sasl2)
 
# le paramètre de configuration Postfix smtpd_sasl_application_name (par défaut, smtpd)
 
Donc, /etc/postfix/sasl/smtpd.conf
 
  
Ensuite, SASL peut déléguer l'authentification proprement dite à plusieurs outils:
+
Concernant la mise en place d'un module de gestion vidéo, on veille au préalable à l'existence du device approprié : /dev/video0. Si ce n'est pas le cas, on l'initialise : '''mknod /dev/video0 c 81 0''' et on le rend éventuellement accessible à tous les utilisateurs : '''chmod 666 /dev/video0'''.
* pwcheck_method: saslauthd : démon de Cyrus qui gère entre autres LDAP et PAM
 
* pwcheck_method: authdaemond: un démon qui vient avec le server "Courier" et qui gère MySQL
 
* pwcheck_method: auxprop: des plug-ins, dont le plug-in SQL qui gère SQL, mais uniquement si les mots de passes des utilisateurs sont en clair dans la base! - à moins d'y appliquer (une rustine) un patch.
 
  
On note que PAM gère aussi SQL - MAIS, on ne pourra gérer que les mécanismes d'authentification 'PLAIN' ou 'Login', PAM ne permet pas des méthodes plus sophistiquées à base de secret partagé telles que DIGEST-MD5. L'intérêt de ces méthodes est que le mot de passe n'est jamais transmis.
+
Les caméras sont des Philips ToUcam 2 PCVC 820K, qui se connectent sur l'ordinateur par un port USB. En général, les distributions GNU/Linux modernes incluent par défaut, et dès l'installation (pensez cependant à connecter physiquement la caméra au port USB ;-)) le module ov511.
  
Rajoutez 2 type de contraintes:
+
C'est un module  qui convient pour un grand nombre de caméras... mais pas pour les Philips ToUcam 2 PCVC 820K :-(<br>
* essayer de gérer un maximum de méthodes d'authentification SASL (ou moins LOGIN et DIGEST-MD5)
+
En effet, le module ov511 ne contient pas de décompression, ce qui est indispensable pour ce modèle de caméra. Il faut donc installer un autre driver : le driver ov51x, qui gère le module de décompression ov518_decomp. Nous détaillons maintenant ces différentes configurations, mais on peut au préalable se reporter au site [http://www.alpha.dyndns.org/ov511 alpha.dyndns.org]
* ne pas commencer à patcher des paquets Debian qui relèvent directement de la sécurité du système
 
  
Note: quand on patche des paquest Debian, le coût de maintenance augmente considérablement (vérifier les correctifs de sécurité, repatcher et recompiler l'application si cela arrive, faire attention à ne pas écraser le paquet patché par le paquet d'origine...) à moins de mettre en place une solution automatisée sur laquelle vous serez bien évidemment fous de joie d'apprendre que je suis en train de travailler (depuis plusieurs donc ne soyez pas pressés).
 
  
Bref, pour que Postfix puisse vérifier un mot de passe dans ma base de données en passant par SASL, j'ai trouvé 4 chemins possibles:
+
Comme il nous faudra compiler un driver, et générer deux modules, se pose inévitablement la question du noyau Linux concerné par le chargement de ces modules. Il s'agit d'installations spécifiques, que '''CLISS XXI''' réalise dans le cadre de '''UTOPIA 2005'''. Raison de plus pour se faire plaisir ;-))<br>
 +
Nous choisissons de travailler sur le dernier noyau stable disponible : le noyau 2.6.11.5, qui est disponible depuis le 18 mars 2005.
  
postfix -> paquet libsasl2 -> pwcheck_method: saslauthd -> PAM -> mysql
+
La configuration type sur laquelle nous implémentons la solution de visio conférence est donc la suivante :
postfix -> paquet libsasl2 -->
+
* Debian GNU/Linux Sarge (dans le cadre d'une installation par internet, elle est livrée avec un noyau 2.6.8).
        --> "pwcheck_method: auxprop" + "auxprop_plugin: sql" -> mysql avec mots de passe EN CLAIR
+
* Recompilation d'un nouveau noyau : le 2.6.11.5
postfix -> paquet libsasl2 -> pwcheck_method: auxprop + auxprop_plugin: sql + patch -> mysql
 
postfix -> paquet libsasl2 patché -> courier.authdaemond -> mysql
 
  
Maintenant il reste à déterminer s'il y en a une qui correspond à mes 2 contraintes évoquées ci-dessus.
+
La recompilation et l'installation d'un nouveau noyau ne font pas l'objet de cet article. Disons simplement que, à l'issue de la mise en place du nouveau noyau, notre système GNU/linux dispose de toute l'arborescence des sources du noyau, dans /usr/src (ce n'est pas le cas au moment de l'installation initiale : les sources ne sont pas installés, et, pour aller plus loin, une autre solution, dans ce cas, peut consister à télécharger les fichiers d'en-tête du noyau, les fameux kernel-headers).
  
  
En attendant je vais, dans un premier temps, mettre en plain PLAIN + TLS - faisons simple et tirez-en les conclusions qui s'imposent ;)
+
'''La compilation des sources du driver :'''<br>
 +
En première approche, il ne semble pas y avoir de souci :
 +
* On télécharge les sources sur alpha.dydndns.org (ov51x-1.65-1.11-mark).
 +
* On décompresse tout ça dans un répertoire temporaire.
 +
* On lance la compilation : '''make'''
 +
* Tout semble OK, à peine remarque-t-on un ou deux warnings, concernant des symboles non définis.
  
 +
'''L'installation des drivers :'''<br>
 +
Il s'agit de deux modules du noyau, d'extension '''.ko''' (kernel objects) : ov51x.ko et ov518_decomp.ko
  
Autre chose: Cyrus SASL n'est pas la seule bibliothèque SASL libre. Il y a notamment la bibliothèque gsasl (GNU SASL) de Simon Josefsson. Par contre elle ne semble fournir que la structure SASL; il n'y a donc notamment pas de quoi attaquer une base MySQL a priori. A voir...
+
A partir de là, on peut mettre en place ces modules, et les charger :
 +
* cp ov51x.ko /lib/modules/2.6.11.5/kernel/drivers/usb/media/ et cp ov518_decomp.ko /lib/modules/2.6.11.5/kernel/drivers/usb/media/ (pour installer les 2 modules)
 +
* depmod (pour générer /lib/modules/2.6.11.5/modules.dep)
 +
* modprobe ov51x (pour charger une première fois à la main notre joli module)
  
 +
Et là... patatras... on a droit à une toute aussi jolie '''FATAL ERROR : unresolved symbols'''.<br>
 +
Autrement dit, ça nous apprendra à ne pas tenir compte des warnings au moment de la compilation :-(
  
==Liens==
+
Que s'est il passé ? Les sources du module ne passent plus  sur les  sources d'un noyau récent, qui gère une table de symboles qui a évolué. Deux solutions :
 +
* revenir à un noyau plus ancien :-(
 +
* corriger les  symboles non résolus.
  
* http://asg.web.cmu.edu/cyrus/download/sasl/: documentation de Cyrus libsasl
+
C'est donc ce que nous faisons. Heureusement, ce n'est pas bien compliqué : on relance le chargement du module et on trace la FATAL ERROR : c'est la  fonction remap_page_range() qui est concernée. Il suffit de la remplacer, dans le code source ov51x.c, par la fonction io_remap_page_range(), qui est celle que gère le noyau 2.6.11.5
* http://www.gnu.org/software/gsasl/: GNU SASL
+
 
* http://wispdirect.com/docs/sasl-howto.html: patch pour le plug-in SQL de cyrus sasl
+
Et on recommence :  
* http://lists.andrew.cmu.edu/pipermail/jeaton-test/2005-October/thread.html: le thread "how are 'sasl_minimum_layer' & TLS related/dependent?" permet de comprendre un minimum à quoi sert le paramètre SASL 'minimum_layer', qui n'est pas documenté chez Cyrus.
+
* make
 +
* copie des .ko
 +
* depmod
 +
* modprobe
 +
 
 +
Cette fois ci, tout est OK. On vérifie que tout s'est bien passé, avec dmesg et lsmod. Et on peut passer à la suite : [la visio conférence elle-même->17].

Version du 20 janvier 2006 à 17:05

Dans le cadre de Utopia 2005, CLISS XXI met en oeuvre une solution de visio conférence, reposant complètement sur des logiciels libres. Voici le descriptif technique, concernant l'installation de la caméra.

Les différents postes informatiques concernés par la visio conférence sont équipés de micro et d'une caméra internet (web caméra, ou webcam).

En dehors des aspects logiciels (on verra plus loin la configuration de 'Configuration de Gnomemeeting' Gnomemeeting) il n'y a pas de problème particulier concernant la configuration du micro et des enceintes : ils sont physiquement connectés à la carte son, et il est possible de tester la bonne marche du dispositif simplement en parlant dans le micro. Les règlages divers (volume, basses, balance ...) peuvent être peaufinés, sous GNU/Linux, grâce à un logiciel tout simple, mais bien pratique, aumix, qui peut s'utiliser même dans un terminal alphanumérique.

Concernant la mise en place d'un module de gestion vidéo, on veille au préalable à l'existence du device approprié : /dev/video0. Si ce n'est pas le cas, on l'initialise : mknod /dev/video0 c 81 0 et on le rend éventuellement accessible à tous les utilisateurs : chmod 666 /dev/video0.

Les caméras sont des Philips ToUcam 2 PCVC 820K, qui se connectent sur l'ordinateur par un port USB. En général, les distributions GNU/Linux modernes incluent par défaut, et dès l'installation (pensez cependant à connecter physiquement la caméra au port USB ;-)) le module ov511.

C'est un module qui convient pour un grand nombre de caméras... mais pas pour les Philips ToUcam 2 PCVC 820K :-(
En effet, le module ov511 ne contient pas de décompression, ce qui est indispensable pour ce modèle de caméra. Il faut donc installer un autre driver : le driver ov51x, qui gère le module de décompression ov518_decomp. Nous détaillons maintenant ces différentes configurations, mais on peut au préalable se reporter au site alpha.dyndns.org


Comme il nous faudra compiler un driver, et générer deux modules, se pose inévitablement la question du noyau Linux concerné par le chargement de ces modules. Il s'agit d'installations spécifiques, que CLISS XXI réalise dans le cadre de UTOPIA 2005. Raison de plus pour se faire plaisir ;-))
Nous choisissons de travailler sur le dernier noyau stable disponible : le noyau 2.6.11.5, qui est disponible depuis le 18 mars 2005.

La configuration type sur laquelle nous implémentons la solution de visio conférence est donc la suivante :

  • Debian GNU/Linux Sarge (dans le cadre d'une installation par internet, elle est livrée avec un noyau 2.6.8).
  • Recompilation d'un nouveau noyau : le 2.6.11.5

La recompilation et l'installation d'un nouveau noyau ne font pas l'objet de cet article. Disons simplement que, à l'issue de la mise en place du nouveau noyau, notre système GNU/linux dispose de toute l'arborescence des sources du noyau, dans /usr/src (ce n'est pas le cas au moment de l'installation initiale : les sources ne sont pas installés, et, pour aller plus loin, une autre solution, dans ce cas, peut consister à télécharger les fichiers d'en-tête du noyau, les fameux kernel-headers).


La compilation des sources du driver :
En première approche, il ne semble pas y avoir de souci :

  • On télécharge les sources sur alpha.dydndns.org (ov51x-1.65-1.11-mark).
  • On décompresse tout ça dans un répertoire temporaire.
  • On lance la compilation : make
  • Tout semble OK, à peine remarque-t-on un ou deux warnings, concernant des symboles non définis.

L'installation des drivers :
Il s'agit de deux modules du noyau, d'extension .ko (kernel objects) : ov51x.ko et ov518_decomp.ko

A partir de là, on peut mettre en place ces modules, et les charger :

  • cp ov51x.ko /lib/modules/2.6.11.5/kernel/drivers/usb/media/ et cp ov518_decomp.ko /lib/modules/2.6.11.5/kernel/drivers/usb/media/ (pour installer les 2 modules)
  • depmod (pour générer /lib/modules/2.6.11.5/modules.dep)
  • modprobe ov51x (pour charger une première fois à la main notre joli module)

Et là... patatras... on a droit à une toute aussi jolie FATAL ERROR : unresolved symbols.
Autrement dit, ça nous apprendra à ne pas tenir compte des warnings au moment de la compilation :-(

Que s'est il passé ? Les sources du module ne passent plus sur les sources d'un noyau récent, qui gère une table de symboles qui a évolué. Deux solutions :

  • revenir à un noyau plus ancien :-(
  • corriger les symboles non résolus.

C'est donc ce que nous faisons. Heureusement, ce n'est pas bien compliqué : on relance le chargement du module et on trace la FATAL ERROR : c'est la fonction remap_page_range() qui est concernée. Il suffit de la remplacer, dans le code source ov51x.c, par la fonction io_remap_page_range(), qui est celle que gère le noyau 2.6.11.5

Et on recommence :

  • make
  • copie des .ko
  • depmod
  • modprobe

Cette fois ci, tout est OK. On vérifie que tout s'est bien passé, avec dmesg et lsmod. Et on peut passer à la suite : [la visio conférence elle-même->17].