S’il y a quelque chose que vous faites et que personne ne doit savoir, peut-être qu’il faudrait commencer par ne pas le faire

Source : Google CEO Eric Schmidt Dismisses the Importance of Privacy

Il a raison le bon docteur Schmidt, il aurait du faire plus attention Liu Xiaobo avant de chercher droits de l’homme sur un moteur de recherche censuré…

Bref vous m’avez compris ce genre de parole dans la bouche de l’homme le plus puissant de la plante ne m’inspire pas confiance et je continue à penser que le slogan de Google Don’t be evil est une véritable plaisanterie.

Alors au lieu de vous conseiller de passer à Bling, je vais vous expliquer comment faire votre propre moteur de recherche.

Ce billet décrit la mise en place d’un moteur de recherche sous Debian GNU/Linux basé sur Nutch.

Pré-requis

Pour faire votre propre moteur de recherche vous avez besoin de : 450 000 serveurs répartis sur toute la planète ; 80Go d’espace disque par machine ; 4Go de mémoire par machine ; Une connexion fibre optique entre vos “data centers” ;

Bref, si vous n’avez pas cette infrastructure à votre disposition ce n’est pas la peine d’aller plus loin
Bon d’accord, vous voulez simplement un moteur de recherche personnel?

Un seul serveur avec les caractéristiques suivantes :

• Un bon processeur ;
• Beaucoup de mémoire (4Go, ba oui, c’est du Java ma petite dame ) ;
• Un gros disque dur très rapide de plus de 500Go (des Raptor par exemple ) ;
• Une bonne bande passante, avec plus de 2Mb en download;
• Une distribution Debian GNU/Linux ;
• Des compétences en administration d’Apache, Tomcat et ligne de commande ;
• Un peu de temps pour configurer le système et le paramétrer aux petits oignons.

C’est bien plus abordable ?

Fonctionnalités

En mettant en place mon propre moteur de recherche, je voulais obtenir les fonctionnalités suivantes :

• Indexation des documents locaux (ex: un Intranet) ;
• Indexation plus poussé de mes centres d’intérêts ;
• Indépendance par rapport à un moteur de recherche ;

Néanmoins, je dois faire une croix sur :

• la publicité ciblée ;
• la recherche d’images, de vidéos et temps réel ;
• la correction orthographique.

Les limitations

On pourrait dire que Nutch est un moteur de recherche de l’époque “web 1.0″. En effet, il ne contient pas d’algorithme d’Intelligence Bolchevique^Wcollective comme la plupart des moteurs de recherche. Cela signifie que seul le Page rank est utilisé et que les votes des utilisateurs ne sont pas pris en compte. Il est aussi plus sensible au Spamdexing.

Présentation des composants

L’architecture d’un moteur de recherche est assez simple, vous avez besoin : d’un Web crawler, un logiciel qui explore automatiquement le Web à la recherche de ressources. un système d’indexation, dans le cas de Nutch c’est Apache Lucene ; des interfaces de recherche ;

Installation

Voici les étapes nécessaires pour faire fonctionner la version 1.0 Nuch sur une machine Debian GNU/Linux version “lenny”.

Dépendances

Vous avez besoin des composants suivants :
# apt-get install tomcat5.5 tomcat5.5-admin tomcat5.5-webapps sun-java6-jre

Configurer le JRE par default :
# update-alternatives --set java /usr/lib/jvm/java-6-sun/jre/bin/java

Nutch

C’est une application en Java, que je place dans le repertoire opt :

# cd /opt
# wget http://mirror.mkhelif.fr/apache/lucene/nutch/nutch-1.0.tar.gz
# tar xzf nutch-1.0.tar.gz
# ln -s nutch-1.0 nutch
# mkdir nutch/urls
# mkdir nutch/crawl
# chown tomcat55: nutch-1.0


Configuration

La configuration du moteur de recherche se trouve dans le fichier conf/nutch-default.xml, vous disposez de votre fichier conf/nutch-site.xml, spécifique à votre instance. Les variables intéressantes sont :

• http.agent.* : la politesse, pour décrire votre robot ou bien prendre l’identité d’un autre ;
• db.fetch.interval.(default|max) : ces variables définissent le nombre de jours entre chaque passage du robot, comme vous ne pourrez pas faire le tour du web en moins de 30 jours , une bonne idée est d’augmenter ces valeurs ;
• plugin.includes : la définition des plugins pris en charge, ici vous pouvez ajouter la gestion des documents pdf, microsoft word et du protocole https.

Bootstrapping du moteur de recherche

Votre moteur de recherche doit avaler une quantité de donnée importante avant de pouvoir faire une recherche pertinente.
Voici quelques sources pour l’initialiser.

A l’aide d’un annuaire

Il existe de très bons annuaires complets comme le projet Open Directory Project.
Dont l’ensemble des données sont disponibles au format RDF et téléchargeables librement : http://rdf.dmoz.org/rdf/.
Par contre, attention ce fichier référence 4 446 480 sites web et vous allez avoir besoin de beaucoup de place pour les référencer tout ce contenu.

Voici la procédure pour utiliser l’annuaire DMOZ avec Nutch :

$ cd /opt/nutch
$ mkdir urls
$ wget http://rdf.dmoz.org/rdf/content.rdf.u8.gz -O urls/content.rdf.u8.gz
$ gunzip urls/content.rdf.u8.gz
$ bin/nutch org.apache.nutch.tools.DmozParser urls/content.rdf.u8 > urls/dmoz
$ bin/nutch inject crawl/crawldb urls/dmoz
Injector: starting
Injector: crawlDb: crawl/crawldb
Injector: urlDir: urls/dmoz
Injector: Converting injected urls to crawl db entries.
Injector: Merging injected urls into crawl db.
Injector: done


A l’aide d’un Marque-page

Une autre source pour initialiser le moteur de recherche est d’utiliser les adresses contenues dans votre marque-page. Le principal avantage de cette technique est la faible quantité de données à analyser et une pertinence de recherche accrue.
Pour ce faire, vous devez exporter votre marque-page au format HTML (pour Mozilla Firefox) et en extraire les adresses de la manière suivante :


$ cd /opt/nutch
$ grep "A HREF=\"http" bookmarks.html | cut -d '"' -f 2 > urls/bookmarks
$ bin/nutch inject crawl/crawldb urls/bookmarks
Injector: starting
Injector: crawlDb: crawl/crawldb
Injector: urlDir: urls/bookmarks
Injector: Converting injected urls to crawl db entries.
Injector: Merging injected urls into crawl db.
Injector: done


A l’aide de Wikipedia

Wikipedia fourni des dumps de sa base de données au format XML. Il est donc possible d’utiliser les URLs des articles de wikipedia comme source.
Voici la procédure pour la version française de Wikipedia, celle-ci contient 897 974 urls.

$ cd /opt/nutch/
$ mkdir urls
$ wget http://download.wikimedia.org/frwiki/latest/frwiki-latest-abstract.xml -O urls/frwiki-latest-abstract.xml
$ grep "<url>" urls/frwiki-latest-abstract.xml | cut -d '>' -f 2 | cut -d '< ' -f 1 > urls/wikipedia-fr
$ bin/nutch inject crawl/crawldb urls/wikipedia-fr
Injector: starting
Injector: crawlDb: crawl/crawldb
Injector: urlDir: urls/wikipedia-fr
Injector: Converting injected urls to crawl db entries.
Injector: Merging injected urls into crawl db.
Injector: done


What you’re waitin’ for ? Christmas ?

Come get some!

Une fois que vous avez chargé la base de données avec vos urls, il faut les parcourir afin de les indexer. Cela se fait à l’aide de plusieurs commandes :

• generate : sélections des adresses à parcourir ;
• fetch : parcourt des urls ;
• updatedb : mise à jours de la base des adresses ;
• invertlinks : mise à jours de l’index des adresses inversées ;
• index : indexation des données ;

Une séquence classique ressemble donc à cela :

bin/nutch generate crawl/crawldb crawl/segments -topN 1000
s1=`ls -d crawl/segments/2* | tail -1`
bin/nutch fetch $s1
bin/nutch updatedb crawl/crawldb $s1
bin/nutch invertlinks crawl/linkdb $s1
bin/nutch index crawl/indexes crawl/crawldb crawl/linkdb $s1

Cette suite de commandes vous permet de parcourir et d´indexer 1000 adresses issues de votre base.
C’est un très bon 1er test pour voir si cela fonctionne.

Shake it, baby!

Une autre commande intéressante est readdb avec l’option stats, qui permet d’obtenir des informations sur le contenu de votre base :

$ bin/nutch readdb crawl/crawldb/ -stats
CrawlDb statistics start: crawl/crawldb/
Statistics for CrawlDb: crawl/crawldb/
TOTAL urls: 3377315
...
min score: 0.0
avg score: 0.13178158
max score: 401.402
status 1 (db_unfetched): 2966337
status 2 (db_fetched): 300008
status 3 (db_gone): 46659
status 4 (db_redir_temp): 27857
status 5 (db_redir_perm): 36454

Une bonne idées serait de mettre en place un système de monitoring sur ces informations pour suivre le déroulement. Par contre, il faut faire attention car la commande prend plusieurs minutes à s’exécuter. (donc hors de question de la placer dans un plugin munin, un mail tous les soirs serait une meilleur méthode).

Damn… I’m looking good!

Vous pouvez tester en ligne de commande le fonctionnement du moteur de recherche :
$ bin/nutch org.apache.nutch.searcher.NutchBean apache
Total hits: 6413
0 20100104001440/http://xmlgraphics.apache.org/fop/
... be part of Apache's XML Graphics project . Demonstration ... goals of the Apache FOP project are to ...
1 20100103201220/http://velocity.apache.org/
... Library Site building Site tools Apache Reference Apache Website How the ASF ... way in its field. Apache
...


Voilà cela fonctionne en ligne de commande, nous pouvons passer à l’interface end user (enfin un moteur de recherche en ligne de commande c’est très pratique aussi )

Configuration de l’interface web

Nutch fournir un application pour Tomcat / Jboss. Il suffit de la déployer et de lui indiquer l’emplacement de votre index de la manière suivante :

# cd /opt/nutch
# cp nutch-1.0.war /var/lib/tomcat5.5/webapps
... attendre
# vim /var/lib/tomcat5.5/webapps/nutch-1.0/WEB-INF/classes/nutch-default.xml
... remplacer la value de searcher.dir par /opt/nutch/crawl

Mais aussi modifier la sécurité de tomcat, via le fichier /etc/default/tomcat5.5 en mettant la variable TOMCAT5_SECURITY à no.
Ou bien en créant un fichier policy donnant l’accès au répertoire /opt/nutch/crawl. (c’est plus propre )

Vous pouvez ensuite redémarrer tomcat et accèder au moteur de recherche via votre navigateur sur le port 8180.

Problèmes rencontrés

Voici quelques problèmes que j’ai rencontré lors de mes tests de la version 1.0 de Nutch :

La directive merge ne fonctionne pas

Impossible de fusionner deux index, il est nécessaire de re-creer l’ensemble de l’index à chaque fois.

La directive fetch flanche

Lorsque trop nombreux sites sont choisis dans la liste des sites à parcourir par le robot d’indexation à l’aide de l’option topN, le programme produit une erreur et le segement produit est corrompu. (c’est pour cette raison que je limite le nombre de site dans un segment à 5000)

Maintenance de l’index

Une fois le moteur de recherche mise en place, il faut maintenir l’index à jours. Pour cela, j’ai mis en place un simple script de crawl avec cron qui se lance tous les soirs :

#!/bin/sh
bin/nutch generate crawl/crawldb crawl/segments -topN 5000
s1=`ls -d crawl/segments/2* | tail -1`
bin/nutch fetch $s1
bin/nutch updatedb crawl/crawldb $s1
bin/nutch invertlinks crawl/linkdb $s1

et un autre qui re-créer l’index :

#!/bin/sh
rm -rf crawl/indexes/
bin/nutch index crawl/indexes/ crawl/crawldb/ crawl/linkdb/ crawl/segments/*


Optimisation du robot d’indexation

La principale difficulté de ce projet est l’indexation d’une énorme quantité de données avec des moyens techniques très limité.
Voici donc quelques idées pour optimiser l’indexation de votre moteur de recherche.

Utiliser le serveur mandataire de votre fournisseur d’accès à Internet

Vous pouvez ajouter l’adresse du serveur mandataire de votre FAI dans le fichier conf/nutch-site.xml :

<property>
<name>http.proxy.host</name>
<value>proxy.free.fr</value>
</property>
<property>
<name>http.proxy.port</name>
<value>3128</value>
</property>


Note : On me signale dans l’oreillette, que mon FAI à fermer son proxy à cause d’une sombre histoire de Haute Autorité De l’Ouverture Postale Inopinée.

Mise en place d’un serveur DNS locale

Vous avez besoin de mettre en place un serveur cache DNS locale qui prend en charge les requêtes du robot. Vous pouvez faire cela avec ISC BIND ou bien pdnsd.

Augmentation du nombre de Threads

Vous pouvez aussi augmenter le nombre de processus utiliser par le robot d’indexation en modifiant les variables du fichier de configuration :

• fetcher.threads.fetch : nombre de threads au total (42) ;

Pour plus d’informations, vous pouvez voir sur le wiki du projet : OptimizingCrawls.

Imposer^WIntégrer Nutch

Voici quelques astuces pour intégrer Nutch à votre architecture.

Mozilla Firefox

Pour Mozilla Firefox, le système de plugin permet d’inclure votre propre moteur de recherche.
Pour faire cela, il faut placer le fichier nutch.xml dans votre profile Firefox : ~/.mozilla/firefox/*.default/searchplugins (en remplacant par l’addresse de votre instance ) .

DNS Menteur

Vous pouvez modifier la configuration de votre DNS pour résoudre le domaine google avec l’adresse de votre moteur de recherche. (Ouais, je sais Net Neutrality, toussa ). En modifiant la feuille de style de l’interface web certains utilisateurs ne verront surement pas la diffèrence.

Est-ce bien raisonnable ?

Vous allez me dire. Héberger son propre moteur de recherche chez soit, quelle drôle d’idée
Je pousse, le concept d’Auto-hébergement au maximum, mais il est clair que j’ai fait cette article “Just for fun”, car même si je ne peut indexer que 5000 sites par jours (le script fonctionne durant les heures creuses) , soit 1 825 000 en un an, je vais avoir beaucoup de mal à indexer les 4 446 480 urls de DMOZ.

Références

Voici quelques références intéressantes sur le sujet :

• The Anatomy of a Large-Scale Hypertextual Web Search Engine : description de l’architecture de Google ;
• La réponse de Bruce Schneier à Eric Schmidt ;
• Le tutorial pour les versions 0.8.x de Nutch ;
• Le Wiki du projet Nutch ;
• Un tee short très googlitude ;
• Un autre tutorial similaire pour une version plus ancienne : Installation de Nutch 0.8.1 sous Ubuntu 6.10 d’Arnaud Goupil ;
• Le blog du groupe de travail francophone : Frutch ;
• Motrech, le blog consacré aux moteurs de recherche.

Conclusion

Vous avez maintenant à votre disposition un moteur de recherche personnel.
Et vous êtes libre de rechercher des choses sans que personne ne puisse le savoir
L’étape la plus dure est de se passer de l’utilisation google
Si vous voulez aller plus loin dans le monde des moteurs de recherche libre vous pouvez intégrer Nutch avec Solr, comme décrit dans cette article : Using Nutch with Solr.
Afin d’obtenir un moteur de recherche professionnel pour une entreprise. (principalement pour éviter la fuite d’information).
Ou bien si vous si êtes intéressé par un produit similaire aux Solutions d’entreprise de Google.

Pour finir, la petite cerise sur la gâteau, comme Nutch utilise Hadoop, il scale comme un troupeau éléphants

Dans la plupart des cas, il est possible de s’en sortir en utilisant les possiblités offertes par les feuilles de style CSS.
Mais le rendu final du document n’est pas garanti, les différents navigateurs interprètent la feuille de style selon leur humeur
et cela ne fonctionne pas dans le cas de documents complexes.

Dans ce cas, l’unique solution est de produire un document au format PDF, unique garantie pour une impression de qualité.
Je vais donc décrire dans cet article, la solution que nous avons mis en place dans le cadre du projet MAVISE.

Historique

La base de données MAVISE fourni les données sur l’ensemble des chaînes de télévision accessibles dans l’Union européenne.

Elle a été développé par la société Easter-eggs en collaboration avec l’Observatoire européen de l’audiovisuel (OEA) pour le compte de la DG Communication de la Commission Européenne.

Dans la 1ère phase du projet nous avons développé un système d’impression avec des feuilles de style.
Ce système ne donnait pas entièrement satisfaction au client.

En effet, les pages du projet étant très complexes, le résultat de l’impression produite par les différents navigateurs était très aléatoire (coupure en plein milieu d’un tableau, impression sur plusieurs pages et saut de pages inexpliqués).

Le résultat n’était pas professionnel et il était difficile pour le client d’alimenter un rapport avec les contenu de la base.
Nous avons donc proposé de mettre en place un export PDF pour l’ensemble des éléments de l’application.

Choix techniques

Au fils du temps, je suis devenu un expert de la production de document PDF,
en effet, j’ai été en charge de l’export PDF dans de nombreux projets.

J’ai eu le plaisir d’utiliser plusieurs API pour produire des documents au format PDF, comme par exemple :

• ReportLab en Python ;
• FPDF en PHP ;
• PDF::API2 en Perl.

Le travail pour produire des documents PDF consiste dans la plupart des cas à dessiner avec l’aide de ces diffèrentes
API, le contenu du document. (texte, tableaux, graphique et mise en page).

Il s’agit d’un travail long et fastidieux, qui consiste à fournir une suite d’instructions pour former le document.
Cette technique montre vite ses limites :

• les demandes de modification de la mise en page du document produit, sont lourdes et nécessitent beaucoup de temps ;
• le code pour produire le document est difficilement rationalisable ;
• elle ne convient pas à des documents de grande taille.

Dans le modèle MVC, qu’utilise la plupart des applications Web, nous utilisons un système de template pour l’affichage (la vue).

Alors pourquoi bon “coder” la présentation des documents PDF?

Pour cette raison, j’ai proposé au client de bâtir le système d’impression des documents PDF sur un système de template.

Ce système repose sur le langage de programmation XSL-FO, les projets Apache FOP et Apache Cocoon.

Architecture du système d’impression

1. Lorsque l’utilisateur clique sur le lien PDF, il est redirigé vers Apache Cocoon ;
2. Cocoon, récupère l’ensemble des informations directement sur le site web, via l’API REST ;
3. Il agrége les informations dans un document XML ;
4. Ce document est transformé en FO à l’aide d’une feuille de style XSLT ;
5. Le document est produit par Apache FOP ;
6. L’utilisateur obtient le document final.

L’interface entre le Site Web et Apache Cocoon

L’architecture du système d’impression repose sur le fait que l’ensemble des variables manipulées par notre application sont accessibles à l’aide d’URL REST.

En effet, il est possible d’afficher le contenu des diffèrentes variables manipulées par l’application à l’aide d’adresses URL spécifiques.
Voici un exemple de sortie :

<?xml version="1.0" encoding="UTF-8"?>
<array>
<is_admin />
<country>
<id>1</id>
<iso3166>FR</iso3166>
<name>France</name>
<enabled>t</enabled>
<minimal_age_of_audience>4+</minimal_age_of_audience>
</country></array>
...


Il est donc possible de récupèrer l’ensemble des informations du site à l’aide du protocol REST.

Nous avons aussi de très nombreux tableaux dans l’application, pour les récupérer, nous utilisons le format XML natif du contrôleur de tableaux dhtmlxGrid.
Voici un exemple de sortie : fichier XML pour dhtmlxGrid.

Agrégation des données dans un seul fichier

Pour récupérer l’ensemble des données du site dans un fichier XML, j’utilise la directive include, offerte par Cocoon :

$ cat /var/lib/tomcat5/webapps/cocoon/mavise/program/program.xml
<?xml version="1.0"?>

<page name='program' xmlns:i="http://apache.org/cocoon/include/1.0">
<i:include src='cocoon:/webui_program'/>
...


Cette directive dit à Cocoon, d’inclure le contenu qui se trouve à l’url cocoon:/webui_program, défini dans le fichier
sitemap.xmap :

<!-- Webui -->
<map:match pattern="webui_*/*">
<map:generate src='http://localhost/{1}?id={2}&presenter=rest&filter=webui'/>
<map:serialize type="exml"/>
</map:match>


Transformation XSLT

Pour transformer les données contenues dans ce fichier, nous avons créé notre propre feuille de style XSLT, pour produire un document FO.
Cette feuille de style prend en compte la mise en forme des diffèrentes données du site.

Grâce à ce système, l’ensemble de la mise en forme est centralisé dans un seul fichier.
Il est aussi possible d’ajouter du contenu statique dans le PDF à l’aide de balises dédiées.
Comme par exemple, une balise copyright, qui sera transformées en un texte statique dans tous les documents PDF.

Le pipeline pour les documents PDF

Voici le pipeline final pour produire des documents PDF :

<!-- PDF -->
<map:match pattern="*/*/*.pdf">
<map:generate src='{1}/{3}.xml'/>
<map:transform src="mk_id.xsl" type="xslt">
<map:parameter name="val" value="{2}" />
</map:transform>
<map:transform type="include">
<map:parameter name="parallel" value="true"/>
<map:parameter name="support-caching" value="true"/>
<map:parameter name="expires" value="600"/>
</map:transform>


Le point intéressant à noter dans ce pipeline est l’encodage des arguments passés via l’URL pour le document PDF.
En effet, les URL pour produire les PDF sont formés de la manière suivante :

http://mavise.obs.coe.int/cocoon/mavise/channel/2157/channel.pdf

L’URL contient, le nom du module et l’identifiant de la chaîne.
De cette manière, il est possible de passer d’autres arguments au système d’impression (comme par exemple, changer l’orientation du document).

Performances

Au niveau des performances du système d’impression, nous n’avons pas une charge très importante sur la génération des documents PDF.
La production des documents est une tâche complexe et nécessite donc de manière génèrale beaucoup de ressources.
Néanmoins, il y a une chose intéressante à noter au niveau de la génération des documents PDF.
Celle-ci est plus rapide que l’affichage dans un navigateur.
En effet cela est lié au fait que les échanges de données se font en local sur le serveur, il y a donc moins de bande passante utilisée que dans le cas de l’affichage de cette même page par le navigateur.

Les petits désagréments du format PDF

Nous avons rencontré un petit problème, avec la gestion des polices UTF-8, en effet, comme la base contient des données sur des chaînes de télévision et des entreprises Turques, nous avons eu besoin d’embarquer une police UTF-8 à l’intérieur du document.
Et visiblement cela pose des problèmes à certains lecteurs.

Quelques liens utiles

Voici quelques liens utiles qui nous ont aidé dans la réalisation de ce système d’impression :

• Le guide d’installation d’Apache Cocoon, FOP sur Debian GNU/Linux ;
• Documentation de la version 2.1 d’Apache Cocoon ;
• XPath Tutorial ;
• XSLT Tutorial ;
• XSL-FO ;

Conclusion

En conclusion, j’aimerais remercié l’Observatoire européen de l’audiovisuel (OEA), pour nous avoir fait confiance pour la mise en place de cette solution.
Au 1er abord, le schéma de l’architecture n’est pas très engageant

J’espère que cette solution donnera des idées à d’autres personnes, pour leur système d’impression.
L’objectif final est de faire des économies de papier par rapport à une impression faite via Internet Explorer

Cette possibilité forte intéressante, est devenus au fils du temps un handicape.

Car la moindre modification d’un document nécessite la régénération des différents formats d’export.

J’ai donc cherché à simplifié et automatisé la procedure de publication. La résultat de ce travail est décrit dans ce document :

Mise en place d’un système de publication de contenu basé sur le projet Apache Cocoon et le langage de balises DocBook

Zeroconf

Zeroconf est le nom d’un ensemble de technologies permettant à plusieurs ordinateurs de communiquer sans configuration.
Le but est d’obtenir un réseau IP fonctionnel sans dépendance d’une infrastructure (serveur DHCP, serveur DNS, etc.) ou d’une expertise réseau. L’ensemble des ces technologies sont implémantées sous Linux par le projet Avahi.

mod_dnssd

Le module mod_dnssd permet d’intégrer le support de Zeroconf dans Apache2 et de publier par l’intèrmédiaire d’Avahi l’ensemble des sites disponibles sur le serveur.

Installation du module

Tout d’abord vous avez besoin d’Avahi :

# aptitude install avahi

Des biblithèques de developpement d’Apache2 :

# aptitude install apache2-dev

Télécharger les sources du modules sur le site web de l’auteur :

$ wget http://0pointer.de/lennart/projects/mod_dnssd/mod_dnssd-0.4.tar.gz

Compiler et installer le module :

$ tar xzf mod_dnssd-0.4.tar.gz
$ cd mod_dnssd-0.4
$ ./configure && make
# make install

Le module se retrouve dans le répertoire : /usr/lib/apache2/modules/

Configuration d’Apache

Pour publier, un site web il faut activer la publication dans le fichier de configuration d’Apache :

DNSSDEnable On

Pour publier une URL, il suffit d’indiquer son nom à l’aide de la directive DNSSDServiceName :

<location /foobar>
DNSSDServiceName “Documentation”
</location>

Vous pouvez aussi publier des flux RSS en précisant le type de services :

<Location /blog.cgi?rss>
DNSSDServiceName “The blog”
DNSSDServiceTypes _rss._tcp
</Location>

Exploitation

Vous pouvez vérifier que les sites ont bien été publié à l’aide d’utilitaire avahi-discover.