Le blog des salariés

Aller au contenu | Aller au menu | Aller à la recherche

Contribution au Libre

Fil des billets - Fil des commentaires

mardi, octobre 22 2013

Validation en masse d'adresses mail

mail Pour le besoin d'un de nos clients, j'ai eu à valider dans un script python un très grand nombre d'adresse e-mails. En y pensant cette situation est courante : combien de bases de données clients contiennent un grand nombre d'adresse mail qui, pour certaines, ont pu être saisies des années auparavant, sans forcément de validation efficace (double opt-in par exemple). On imagine bien ainsi qu'en utilisant une telle adresse mail des années plus tard, rien n'est moins sûr que notre mail arrive à destination. C'est pourquoi il nous a été utile d'écrire un script capable de détecter les adresses mails assurément invalides d'une base de données.

Pour la réalisation de ce script (écrit en python), je me suis tout d'abord en toute logique tourné vers une librairie qui me semblait parfaitement adaptée validate_email. Cette librairie implémente une méthodologie en plusieurs étapes :

  1. Une validation syntaxique de l'adresse mail pour commencer ;
  2. Une validation du nom de domaine en récupérant via une requête DNS le serveur de mail du domaine (enregistrement MX) ;
  3. Vérification du serveur mail en s'y connectant, en vérifiant la réponse en cas d'une commande HELO du protocole SMTP, voire même de sa réponse en cas d'un test d'envoi de mail à l'adresse à vérifier (commande SMPT RCPT TO) ;

Il est par ailleurs possible de définir jusqu’où on souhaite pousser la validation : syntaxique uniquement, syntaxique + validation DNS du MX ou sinon validation complète.

Mes premières utilisations de cette librairie m'ont démontré que son utilisation pour une validation en masse d'adresses mail n'était pas du tout optimale (+ de 24heures pour la validation d'environ 70 000 adresses mails même incomplètes). J'ai alors développé une librairie similaire optimisant les phases 2 et 3. En effet pourquoi valider plusieurs fois un même nom de domaine ou encore pourquoi valider une connexion SMTP à un même serveur de mail. Voici donc une librairie reprenant cette méthodologie et l'optimisant pour une validation en masse, en insérant simplement un mécanisme de mise en cache des vérifications communes à un même domaine. Pour vous donner une idée de l'optimisation apportée, une validation d'environ 70 000 adresses mails (validation syntaxique + validation d'une connexion MX) prend environ 1h30 à 2h. Cette librairie dénommée mass_validate_email est disponible ici et publié sous licence LGPL.

jeudi, septembre 26 2013

Superviser la synchronisation de vos annuaires OpenLDAP

Logo OpenLDAP Cette problématique semble peut-être simple de prime abord, mais une supervision efficace de la synchronisation d'annuaires OpenLDAP n'est pas aussi triviale qu'elle peut en avoir l'air. Toute la complexité réside dans le mécanisme relativement simpliste de réplication avec syncrepl : un schéma LDAP périmé ou des ACL mal définies, peut facilement entraîner une désynchronisation de vos annuaires sans que cela soit très visible.

Le mécanisme de réplication syncrepl se base sur des identifiants de versions des données contenues dans l'annuaire, pour déterminer quelles informations doivent être répliquées et quelles informations est la plus à jour (dans le cas d'une réplication master-master). Ces identifiants de versions sont stockés dans l'attribut contextCSN de la racine de l'annuaire et dans les attributs entryCSN de chacun des objets de l'annuaire. Les valeurs de ces attributs (obligatoirement indexés) sont construites à l'aide de la date de dernière modification. Cela permet, via l'overlay syncrepl d'OpenLDAP, de déterminer à partir du contextCSN d'un répliqua, les objets LDAP de l'annuaire source modifiés depuis et qui devront donc être synchronisés. La réplication d'un objet consiste ensuite à transférer l'objet complet d'un annuaire à l'autre, sans distinction d'attributs : tous les attributs seront répliqués quelle que soit la modification l'ayant entraînée. Ce mécanisme très simple n'est malheureusement pas très robuste et des cas de désynchronisation son relativement fréquents. Une bonne supervision est alors indispensable, d'autant plus qu'une synchronisation en panne n'empêche pas pour autant un répliqua de répondre aux requêtes qui lui sont adressées.

Un plugin de check Nagios (ou Icinga) existait déjà mais il se basait uniquement sur la valeur du contextCSN des annuaires, sans vérification objet par objet, voire attribut par attribut. Il pouvait alors laisser passer une désynchronisation.

J'ai donc eu l'occasion d'en développer un qui, selon moi, aborde plus globalement la supervision d'une réplication syncrepl. Ce plugin ne se contentera donc par simplement de vérifier les valeurs des attributs contextCSN, mais permettra une vérification des objets présents dans chacun des annuaires, de la valeur de leur attribut entryCSN, voire même de la valeur de l'ensemble de leurs attributs. Il est évident qu'une supervision plus exhaustive sera plus coûteuse en terme de ressource, et c'est pourquoi j'ai voulu, à travers différents paramètres, permettre une vérification plus ou moins complète de l'état de synchronisation :

  • --filter : il est possible de ne vérifier qu'une partie des objets de l'annuaire, en spécifiant un filtre de recherche LDAP
  • --no-check-contextCSN : permet de désactiver la vérification du contextCSN des annuaires
  • --attributes : permet d'activer la validation des valeurs de tous les attributs de tous les objets des annuaires

Il est a noter cependant, que la supervision la plus complète sur un annuaire d'environ 10 000 objets, ne prend que quelques secondes (entre 3 et 10 secondes en fonction de la charge des serveurs).

Pour télécharger ce plugin, c'est ici

Exemple d'utilisation :

check_syncrepl_extended \
     -p ldap://ldap0.example.lan \
     -c ldap://ldap1.example.lan/ \
     -D 'uid=nagios,ou=sysaccounts,o=example' \
     -P 'password' \
     -b 'o=example' -a -n

Définition de la command correspondante dans Nagios :

define command {
        command_name    check_syncrepl
        command_line    /usr/local/lib/nagios/plugins/check_syncrepl_extended -p $ARG1$ -c ldap://$HOSTADDRESS$/ -b $ARG2$ -D '$ARG3$' -P '$ARG4$' -a -n
}

Définition du service correspondant :

define service{
        use                           generic-service
        service_description     LDAP Syncrepl
        check_command         check_syncrepl!ldap://ldap0.example.lan!o=example!uid=nagios,ou=sysaccounts,o=example!password
        host_name                ldap1
}

jeudi, septembre 19 2013

Mailt : l'outil indispensable pour tester vos serveurs de mail

mail Lors de la mise en place d'un serveur de mail, à un moment ou un autre, on aura toujours besoin d'envoyer un mail de test pour tester une connexion IMAP ou POP. Pour faciliter tout cela, nous avons mis au point une boite à outils bien pratique, que nous avons nommée Mailt. Elle se compose de trois outils (pour le moment) :

  • smtpt : envoyez un mail en une commande au serveur SMTP de votre choix, en définissant simplement le destinataire, l'expéditeur ou encore le contenu du mail. Fini les connexions telnet manuelle à coup de copier/coller pour simuler les différents cas de figure que vous souhaitez expérimenter ! Cette commande sera d'autant plus pratique si vous souhaitez valider l'efficacité de votre analyse anti-spam et/ou anti-virus :
    • le paramètre --spam vous permettra de facilement adapter le contenu du mail, afin qu'il contienne la chaîne de caractères de test GTUBE qui sera interprété comme un spam par votre anti-spam.
    • le paramètre --virus vous permettra, de la même manière, d'insérer dans le contenu du mail la chaîne de caractères de test EICAR qui sera interprété comme un virus par votre anti-virus.

Vous pourrez également facilement valider une connexion STARTTLS ou SMTPS, authentifiée ou non, et avec le paramètre --debug, ce sera comme si vous tapiez tout cela manuellement dans une session telnet ou openssl s_client.

  • imapt : testez en une commande la connexion à un serveur IMAP de votre choix. Fournissez simplement les informations de connexion (utilisateur, mot de passe, serveur, port, sécurité SSL, dossier INBOX, etc.) et cette commande validera pour vous la réussite d'une connexion, en affichant le nombre de messages contenus dans le dossier de votre choix. Vous pourrez facilement ajuster le niveau de détail de vos tests avec les paramètres --verbose ou --debug
  • popt : testez en une commande la connexion à un serveur POP de votre choix. De la même manière, à partir de paramètres fournis, cette commande validera pour vous la connexion au serveur de votre choix et vous affichera le nombre de mails sur le serveur.

Cette suite d'outils est écrite en Python et utilise des librairies standards, le plus souvent déjà présentes sur vos serveurs (paquet Debian python-support). Elle est facilement installable au travers d'un paquet Debian très léger, téléchargeable ici ou en ajoutant le repos Debian suivant et installer le paquet mailt :

deb http://debian.zionetrix.net/debian/ squeeze mailt

Remarque : Ces paquets sont également disponibles pour la version testing de Debian (Wheezy).

mercredi, avril 17 2013

Dokuwiki : une page d'accès refusé personnalisée

Logo Dokuwiki Lorsqu'un utilisateur accède à votre wiki Dokuwiki alors qu'il n'en a pas le droit, un message l'informe que l'accès à cette page lui est interdit et lui suggère de s'authentifier. Ce message ne correspond pas forcément à la réalité en fonction de l'utilisation que vous faites de votre wiki. Il peut être intéressant alors d'avoir une page personnalisable qui avec vos propres mots, expliquera à l'utilisateur pourquoi il obtient cette page ou encore comment accéder à la page souhaitée.

Dans cette optique, j'ai écrit un plugin Dokuwiki dénommé deniedpage permettant de définir une page de votre wiki sur laquelle l'utilisateur sera redirigé automatiquement en cas d'accès refusé à une page. Vous pourrez définir la page de votre choix en utilisant la page de configuration de la section administration. Comme n'importe quelle autre page de votre wiki, vous pourrez créer, et plus tard modifier cette page, en utilisant l'éditeur en ligne.

Grâce au gestionnaire d’extensions de Dokuwiki, l'installation de ce plugin se fait très simplement en copiant l'URL suivante dans le champ de téléchargement et en cliquant sur le bouton Télécharger :

https://github.com/brenard/dokuwiki-plugin-deniedpage/zipball/master

La mise à jour se fera ensuite tout aussi simplement en utilisant le bouton de Mettre à jour. Penser à activer le plugin après son installation et assurez- vous que votre page d'erreur personnalisée soit accessible à n'importe qui. Pour plus d'information sur ce plugin, vous pouvez consulter sa page sur le site Dokuwiki.org.

jeudi, mars 28 2013

Dokuwiki : Authentification LDAP + HTTP

Logo Dokuwiki Pour un de nos clients, la problématique suivante s'est posée : afin de supporter l'authentification SSO en place dans son infrastructure, il était nécessaire que Dokuwiki n'authentifie pas directement les utilisateurs mais fasse confiance à l'authentification effectué par Apache. Pour cela, Dokuwiki, avec son système de plugin d'authentification, implémente une solution relativement simple :

  • Dokuwiki (core) récupère les informations d'authentification fournies par Apache et les propose au plugin via la méthode trustExternal()
  • Les plugins ayant implémenté cette méthode, utilisent les informations d'authentification fournies pour authentifier l'utilisateur sans avoir besoin de lui afficher un formulaire.

Si comme nous, vous avez besoin de récupérer par ailleurs des informations sur vos utilisateurs Dokuwiki dans un annuaire LDAP tout en faisant confiance à l'authentification faite par Apache, vous serez heureux d'apprendre que c'est désormais possible. En effet, le plugin d'authentification LDAP de Dokuwiki (authldap) n'implémentait pas jusqu'ici cette méthode trustExternal() et affichait donc systématiquement un formulaire à l'utilisateur, quand bien même celui-ci avait déjà été authentifié par Apache. Nous avons implémenté cette méthode et l'avons proposé au projet Dokuwiki. Pour voir la Pull Request correspondante sur Github, c'est ici

dimanche, septembre 9 2001

GPL, kesako ?

Article rédigé par Florent Jugla, fondateur de la société ELEDO

Le but de ce article est de répondre à des questions simples et pratiques à propos de la licence GPL.

Cet article est basé sur les textes contenus dans les sites suivants :

Qu’est ce que la licence GPL ?

La licence GPL (GNU General Public License) est une "licence de logiciel libre" :

  • "licence de logiciel" car elle définit un cadre d'utilisation fixé par un programmeur sur son logiciel.
  • "libre" car le cadre d'utilisation défini par cette licence est - contrairement aux licences classiques - de s'assurer qu'un certain nombre de "libertés" seront respectées sur le logiciel protégé par celle-ci (ou sur tout logiciel en dérivant).

Pour R. Stallman (inventeur de la GPL), les "libertés" sur un logiciel sont :

  • liberté d'exécuter le logiciel, et ce pour n'importe quel usage;
  • liberté de modifier le logiciel pour l'adapter à ses besoins (dans la pratique, cela nécessite l'accès au code source);
  • liberté de redistribuer des copies, soit gratuitement, soit contre rémunération;
  • liberté de distribuer des versions modifiées afin que la communauté du logiciel libre puisse en profiter.

La licence GPL est basée sur la notion de "copyleft" (détournement du terme "copyright") :

  • la notion de "copyright" permet à l'auteur d'un logiciel propriétaire de bloquer les "libertés" sur son logiciel ;
  • au contraire la notion de "copyleft" permet à l'auteur d'un logiciel, d'être sûr que ces "libertés" seront bien respectées non seulement sur son logiciel, mais aussi sur tout logiciel dérivant du sien.

GPL Pratique

Placer un code sous licence GPL : (cf. gpl-howto.html)

Dans chaque fichier source, inclure en commentaires :

  • une ligne de copyright 'Copyright 2001 '
  • une déclaration sur les droits de copie précisant que le programme est distribué sous les termes de la Licence Publique Générale GNU.

Ajouter un fichier COPYING contenant le texte de la licence GPL.

A l'heure actuelle, seule la version anglaise peut être utilisée.

Réutilisation de code GPL par un programmeur :

  • les fichiers sources présents dans la versions originales et qui ont été modifiés peuvent porter le 'copyright' du programmeur. Cependant, le ou les 'copyright' déjà présents dans le source original ne doivent pas être effacés.
  • les nouveaux fichiers source de cette version du logiciel portent seulement le 'copyright' du programmeur.

Points importants :

Le fait de placer son code sous licence GPL assure que ce code ne sera jamais "fermé".

Toute utilisation ultérieure de ce code devra être faite dans l’ "esprit" GPL.

Un logiciel construit à partir de briques de code GPL peut être commercialisé .

En fait, même de simples copies du logiciel GPL initial peuvent l’être, les seules restrictions sont :

  • que les codes sources doivent être présentés à l'acheteur ou à toute personne qui le demande, et ce sans surcoût sur le logiciel (mis à part le coût de copie physique de ce code source).
  • que la licence GPL doit être conservée dans chaque copie du code.
  • En usage interne, on peut tout faire avec du code GPL ; une société peut ainsi utiliser du code GPL pour ses logiciels internes, sans avoir de comptes à rendre à personne.
  • Il ne faut pas confondre GPL et "Open Source". Si tout code GPL est automatiquement "Open Source", la réciproque n’est pas vraie. Il existe un tas d’autres licences à caractères "Open Source", mais qui sont différentes de la licence GPL.

Aspects "philosophiques" et implications de la licence GPL

L’un des aspects les plus intéressants de la licence GPL est qu’elle a permis l’émergence d’une "communauté du logiciel libre". Cette communauté rassemble un grand nombre de personnes autour de thèmes communs :

  • Lutte contre les monopoles, favorisation de la concurrence : la licence GPL favorise la concurrence puisqu’elle assure à toute personne la possibilité d’améliorer un logiciel et de pouvoir profiter de fruits de son travail. Dans le même sens, elle empêche des monopoles (du type Microsoft) de se constituer.
  • Brevetabilité sur les logiciels : bien qu’en pratique, la licence GPL n’ait aucun rapport avec la question de brevetabilité sur les logiciels, la communauté du logiciel libre est fortement impliquée dans la lutte contre celle-ci. En effet, les thèmes défendus par la communauté du libre (favorisation de la concurrence, lutte contre les monopoles, aspects démocratiques) rejoignent les critiques formulées à l’encontre de la brevetabilité sur les logiciels. (cf. savingeurope.fr)
  • Informatique et démocratie : l’introduction de l’informatique dans le processus démocratique se fera dans un avenir proche ; on peut penser que cela sera réalisé dans la pratique par des logiciels placés sous des licences de type "libre". A ce propos, voir : Trois députés proposent de généraliser l’usage des standards ouverts, l’accès au code source et introduisent le "droit à la compatibilité" : ( cf. prop. loi)

Note : il est intéressant de remarquer que, lors d’un vote en France, les urnes sont transparentes. L’urne de demain - l’ordinateur et le logiciel de vote qu’il héberge - devront eux aussi être "transparents". Cette transparence ne pourra être assurée que si chacun a la possibilité physique d’accéder au code du logiciel.

Critiques sur la GPL

La licence GPL est proche de la notion de "démocratie à l’américaine" - citons Stallman, auteur de la GNU GPL :Le mouvement pour le Logiciel Libre a été fondé en 1984, mais son inspiration provient des idéaux de 1776 : liberté, communauté et coopération volontaire. C’est ce qui conduit à la libre entreprise, au droit à la parole et au logiciel libre.