Debian Wheezy : installation Solr pour l’indexation drupal7

Sous ce titre pompeux, il s’agira de détailler l’installation du service d’indexation Solr à l’effet de l’utiliser via un site web Drupal7 pour lui permettre d’indexer ses contenus (articles et fichiers attachés) grâce à l’utilisation des modules apachesolr et apachesolr_attachments.
Comme je n’aime guère Java (doux euphémisme pour rester politiquement correct !!!), l’installation se fera dans une machine virtuelle dédiée à cette utilisation, ce qui évitera de polluer un serveur web avec une machine virtuelle Java…

I – Installation de Tomcat 7 :

Solr est un projet de la fondation Apache écrit en Java, et s’exécutant sous forme d’un servlet (au sein d’un conteneur web de servlets et JSP Java EE ; il faudra donc installer Jetty ou Tomcat pour le faire tourner : c’est ce dernier que j’ai choisi d’installer dans la mesure où il est empaqueté dans Wheezy en version 7.x. Un simple :
$ sudo apt-get install tomcat7
se chargera d’installer le conteneur web tomcat et sa panoplie de dépendances, dont notamment la machine virtuelle Java qui convient.

Si tout se passe bien, on devrait avoir tomcat7 à l’écoute du port 8080 :

tomcat_works

Il peut être utile de compléter cette installation avec les paquetages d’administration de tomcat, voire la documentation de la bestiole ; donc :

$ sudo apt-get install tomcat7-manager tomcat7-admin tomcat7-docs

A partir de ce moment, les liens de la page par défaut (It Works !!!) deviennent actifs, et on peut ainsi accéder à l’administration de tomcat 7, à ceci près qu’il est demandé de s’authentifier.
Les comptes sont définis pour Debian Wheezy dans le fichier /etc/tomcat7/tomcat-users.xml, qu’il convient de modifier comme suit :

$ sudo vim /etc/tomcat7/tomcat-users.xm
<tomcat-users><role rolename="tomcat"/>

<role rolename=”admin-gui”/>
<role rolename=”manager-gui”/>
<role rolename=”manager-script”/>
<role rolename=”manager-jmx”/>
<user username=”nom-user” password=”motdepasse” roles=”manager-gui,manager-script,manager-jmx,admin-gui”/>
</tomcat-users>

Bon, là j’ay ai mis toute la panoplie … au cas où !
Après redémarrage de tomcat
$ sudo service tomcat7 restart
il devrait être possible de s’identifier et accéder à la console d’administration de tomcat 7 :
console_admin_tomcat

Au final, on obtient un beau conteneur de servlets prêt à être administré, mais toujours désespérément vide …

II – Installation de Apache/Solr :

Wheezy empaquette bien solr, mais il s’agit d’une version 3 pour tomcat 6, alors que Solr est maintenant en version 4 (la 4.3.1 au moment de la manip), et qu’on vient d’installer tomcat 7 … il va donc falloir installer SolR à la main (ce qui est au final plus intéressant, quand on veut comprendre un peu comment celà fonctionne). On va donc télécharger la dernière version du monstre :
$ wget http://apache.mirrors.multidist.eu/lucene/solr/4.3.1/solr-4.3.1.tgz

Dans la mesure où le paquetage tomcat installe ses fichiers dans /usr/share, on va rester cohérents et faire de même avec Solr ; donc décompresser cette archive dans /usr/share, puis créer un lien symbolique depuis le répertoire généré (avec son numéro de version) vers /usr/share/solr afin de se simplifier une éventuelle mise à jour ultérieure, et la même chose vers le fichier .war :

$ cd /usr/share/
$ sudo tar zxvf ~/solr-4.3.1.tgz
$ sudo ln -s solr-4.3.1 solr
$ sudo ln -s /usr/share/solr/dist/solr-4.3.1.war /usr/share/solr/dist/solr.war

Il faut également fournir à tomcat les librairies nécessaires au fonctionnement de Solr, sous peine de se voir spammer par des centaines de lignes dans les logs de tomcat à la mise en œuvre du servlet :

$ cd /usr/share/tomcat7/lib
$ sudo ln -s /usr/share/solr/example/lib/ext/jcl-over-slf4j-1.6.6.jar jcl-over-slf4j-1.6.6.jar
$ sudo ln -s /usr/share/solr/example/lib/ext/jul-to-slf4j-1.6.6.jar jul-to-slf4j-1.6.6.jar
$ sudo ln -s /usr/share/solr/example/lib/ext/log4j-1.2.16.jar log4j-1.2.16.jar
$ sudo ln -s /usr/share/solr/example/lib/ext/slf4j-api-1.6.6.jar slf4j-api-1.6.6.jar
$ sudo ln -s /usr/share/solr/example/lib/ext/slf4j-log4j12-1.6.6.jar slf4j-log4j12-1.6.6.jar

Enfin, il nous reste à déployer notre servlet Solr dans le répertoire /var/lib/tomcat7/webapps/, mais dans la mesure où on a installé le monstre dans /usr/share/solr/, un simple lien symbolique fera l’affaire :

$sudo ln -s /usr/share/solr/dist/solr.war /var/lib/tomcat7/webapps/solr.war

Ceci fait, après un redemarrage du service tomcat7, un petit tour vers le manager de la console d’administration devrait nous montrer la présence de notre nouveau servlet :

tomcat_manager

Mais, contrairement à ce qui est ici affiché, votre servlet /solr ne sera probablement pas actif … et pour cause, on l’a pas encore configuré !!!

III – Configuration de Solr en multi-core pour Drupal 7 :

Toujours à poursuivre notre but initial, qui est de fournir à Drupal 7 un service d’indexation, l’idée est de configurer Solr pour gérer de multiples bases : ce qui revient à gérer dans le jargon Solr le multi-core sur notre instance unique. Cette configuration s’effectue via le fichier solr.xml se trouvant dans le répertoire d’installation de Solr, donc pour nous (et comme nous l’indique notre page ‘It Works’) il s’agira de la valeur de CATALINA_BASE, soit /var/lib/tomcat7/, on va donc créer un sous-répertoire solr/ dans ce dossier, y copier le fichier fourni par la distribution solr (ou celui-ci), et y adapter la section ‘cores’ :


$ mkdir /var/lib/tomcat7/solr
$ cd /var/lib/tomcat7/solr
$ tar zxvf ~/solr_conf_drupal7.tgz
$ sudo vim /usr/share/solr/solr.xml
...
<cores adminPath="/admin/cores" defaultCoreName="collection1">
<core name="collection1" instanceDir="/var/lib/tomcat7/solr/collection1">
<property name="dataDir" value="/var/lib/tomcat7/solr_data/Collection1" />
</core>
<core name="d7test" instanceDir="site1">
<property name="dataDir" value="/var/lib/tomcat7/solr_data/site1" />
</core>
<core name="modernisation" instanceDir="/var/lib/tomcat7/solr/site2">
<property name="dataDir" value="/var/lib/tomcat7/solr_data/site2" />
</core>
<core name="modern_preprod" instanceDir="/var/lib/tomcat7/solr/site3">
<property name="dataDir" value="/var/lib/tomcat7/solr_data/site3" />
</core>
</cores>
...

Dans cette configuration, il est indiqué que l’instance comportera 4 cores (i.e. 4 “bases d’indexation”) distinctes dont les fichiers de données seront situées dans des répertoires éponymes dans /var/lib/tomcat7/solr_data/, et ces dossiers devront être propriété de l’utilisateur tomcat7 qui devra pouvoir y écrire :

$ sudo mkdir /var/lib/tomcat7/solr_data/
$ sudo mkdir /var/lib/tomcat7/solr_data/Collection1
$ sudo mkdir /var/lib/tomcat7/solr_data/site1
$ sudo mkdir /var/lib/tomcat7/solr_data/site2
$ sudo mkdir /var/lib/tomcat7/solr_data/site3
$ sudo chown -R tomcat7.tomcat7 /var/lib/tomcat7/solr_data/

N.B. : Le core Collection1 est le core par défaut, et ne sera pas utilisé spécifiquement par un site Drupal, il est juste créé pour éviter d’écraser les données d’un site en cas de mauvaise configuration.

Manquent encore les fichiers de définitions de chacun de ces cores, qui comprennent notamment la description du schéma de données à indexer, et qui doivent donc correspondre à ce qu’attend le module Drupal apachesolr : c’est donc dans la distribution de ce module qu’on va trouver cette configuration (ou bien ici), et simplement la recopier dans des dossiers éponymes de chacun des cores configurés dans /var/lib/tomcat7/solr/ :

$ cd /var/lib/tomcat7/solr
$ sudo mkdir collection1 site1 site2 site3
$ cd collection1
$ sudo tar zxvf ~/conf_solr4_drupal7.tgz
$ cd ../site1
$ sudo tar zxvf ~/conf_solr4_drupal7.tgz
$ cd ../site2
$ sudo tar zxvf ~/conf_solr4_drupal7.tgz
$ cd ../site3
$ sudo tar zxvf ~/conf_solr4_drupal7.tgz

Enfin, dans la mesure où il s’agit d’une machine dédiée à Solr, on va pouvoir augmenter la quantité de ram allouée à la machine Java, qui est par défaut de 128 Mo, ce qui peut paraître peu si l’on doit indexer de gris sites. Ce paramètre peut se configurer dans le fichier /etc/default/tomcat7, dans lequel il faut modifier la ligne définissant la variable shell JAVA_OPTS et la passer de :
JAVA_OPTS=-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC
à
JAVA_OPTS=-Djava.awt.headless=true -Xms128m -Xmx512m -XX:+UseConcMarkSweepGC

Une fois ceci achevé, et après une dernier redémarrage de tomcat7 on devrait avoir un serveur d’indexation Solr fonctionnel et adapté à l’utilisation par le module drupal 7 apachesolr, auquel on peut accéder par l’URL http://votre-ip:8080/solr/ :

solr

La suite de l’aventure consistera à configurer les modules apachesolr* de Druapl 7 pour utiliser notre infrastructure … mais c’est une autre histoire.

posté le 27. juin 2013 à 3:28 pm par info · Permalink
Catégories : Administration système, web · Mots-clés: , ,

15 Réponses

Inscrivez-vous au fil RSS des commentaires

  1. Ecrit par Kapik
    de 23/07/2013 à 11:25 am
    Permalink

    Bonjour,

    Merci pour le tuto.
    Pour info : il manque l’extension .war lors de la création du lien symbolique :

    $sudo ln -s /usr/share/solr/dist/solr.war /var/lib/tomcat7/webapps/solr

  2. Ecrit par francois
    de 23/07/2013 à 1:02 pm
    Permalink

    Oups !!!
    C’est corrigé … à la guerre comme à la guerre.

  3. Ecrit par Kapik
    de 23/07/2013 à 2:01 pm
    Permalink

    Encore le même 😉

    Au niveau de la configuration il y a un fichier solr_conf_drupal7.tgz ?!

  4. Ecrit par Kapik
    de 23/07/2013 à 2:16 pm
    Permalink

    Résolu, j’ai lu trop vite 😉 tu peux effacer ces com 😉

  5. Ecrit par pcsystemd
    de 15/01/2014 à 3:41 pm
    Permalink

    Bonjour,

    Dans la partie pour copier les fichiers de définitions des cores, il est indiqué :

    $ cd /usr/share/solr
    $ sudo mkdir collection1 site1 site2 site3

    Il ne faut pas plutôt copier ces fichiers dans :
    /var/lib/tomcat7/solr_data/Collection1
    /var/lib/tomcat7/solr_data/site1
    etc.. ?

    Merci

  6. Ecrit par francois
    de 15/01/2014 à 6:40 pm
    Permalink

    Effectivement, une erreur s’est glissée dans l’article c’est bien dans /var/lib/tomcat7/solr/xxxxx (au lieu de /usr/share/tomcat7/solr/xxxx, comme il était indiqué) qu’il faut les copier ; mais pas dans les répertoires /var/lib/tomcat7/solr_data/xxxx qui ne contiennent que les données générées par le moteur.
    L’article est corrigé.
    Merci.

  7. Ecrit par VANCAPPEL
    de 21/03/2014 à 11:15 pm
    Permalink

    Bonjour,

    je ne suis pas développeur de formation, mais plutôt très curieux.
    J’ai suivi votre tuto, mais je pense que je dois faire une erreur dans l’étape n° III “Configuration de Solr en multi-core pour Drupal 7”. En effet, lorsque je vais sur http://mon_url_de_serveur:8080/solr/, j’ai un très long message d’erreur.

    HTTP Status 500 – {msg=SolrCore ‘collection1’ is not available due to init failure: Could not load config file /var/lib/tomcat7/solr/collection1/solrconfig.xml,trace=org.apache.solr.common.SolrException: SolrCore ‘collection1’ is not available due to init failure: Could not load config file /var/lib/tomcat7/solr/collection1/solrconfig.xml at org.apache.solr.core.CoreContainer.getCore(CoreContainer.java:827) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:317) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:217) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:225) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:927) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1001) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:312) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:724) Caused by: org.apache.solr.common.SolrException: Could not load config file /var/lib/tomcat7/solr/collection1/solrconfig.xml at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:530) at org.apache.solr.core.CoreContainer.create(CoreContainer.java:597) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:258) at org.apache.solr.core.CoreContainer$1.call(CoreContainer.java:250) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) … 3 more Caused by: org.apache.solr.common.SolrException: solrconfig.xml contains more than one value for config path: indexConfig/useCompoundFile at org.apache.solr.core.Config.getNode(Config.java:251) at org.apache.solr.core.Config.getNode(Config.java:228) at org.apache.solr.core.Config.getVal(Config.java:362) at org.apache.solr.core.Config.getBool(Config.java:406) at org.apache.solr.update.SolrIndexConfig.(SolrIndexConfig.java:139) at org.apache.solr.core.SolrConfig.(SolrConfig.java:168) at org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:527) … 11 more ,code=500}

    J’ai vérifié, le fichier “/var/lib/tomcat7/solr/collection1/solrconfig.xml” est pourtant bien présent, et identique au fichier que l’on peut trouver dans le fichier que vous proposez au téléchargement.

    Pouvez-vous m’aider svp ?

    Merci

    Kévin

  8. Ecrit par francois
    de 22/03/2014 à 6:24 am
    Permalink

    Bonjour Kevin,
    Quand au début de l’article, je dis ne pas spécialement apprécier Java, c’est en particulier pour ce genre de messages d’erreur imbuvables … dû à l’empilement d’une multitude de couches d’objets, d’abstractions, et j’en passe.
    Sinon, il me semble bien indiquer que Tomcat ne peut utiliser le fichier /var/lib/tomcat7/solr/collection1/solrconfig.xml, même s’il est bien présent au bon endroit, mais pas forcément pour un problème de droits, mais en raison d’une erreur dans le fichier de conf. lui-même : solrconfig.xml (cf. Caused by: org.apache.solr.common.SolrException: solrconfig.xml contains more than one value for config path : indexConfig/useCompoundFile ).
    Apparemment, il a eu une modification du moteur solR (cf. http://mail-archives.apache.org/mod_mbox/lucene-commits/201308.mbox/%3C20130801181811.1BFD023888E2@eris.apache.org%3E) portant sur :
    XML configuration parsing is now more strict about situations where a single
    setting is allowed but multiple values are found. In the past, one value
    would be chosen arbitrarily and silently. Starting with 4.5, configuration
    parsing will fail with an error in situations like this. If you see error
    messages such as “solrconfig.xml contains more than one value for config path:
    indexConfig/infoStream” check your solrconfig.xml file for multiple occurrences
    of “infoStream” and delete the one that you do not wish to use. See SOLR-4953
    for more details.

    et le moteur ne permet plus d’avoir plusieurs sections useCompoundFile dans la configuration.
    Essayez de commenter l’une de ces 2 sections.

  9. Ecrit par VANCAPPEL
    de 24/03/2014 à 4:54 pm
    Permalink

    Bonjour,

    merci pour tout. Pour finir, j’ai réinstallé avec solr 4.3.1. Encore une fois, merci.
    Je suis désormais votre second tuto concernant solr et drupal.

    Merci

    Kévin V

  10. Ecrit par VANCAPPEL
    de 24/03/2014 à 6:58 pm
    Permalink

    Bon, pour finir, il me reste toujours un petit problème. Je n’ai qu’un seul core qui est “collection1” visible dans le panneau d’administration de solr (je ne vois donc pas site1, site2 et site3).
    Ma configuration est la même que celle proposée par ce tuto, à savoir tomcat6 / apache solr 4.3.1.

    Voici les étapes réalisées.

    1. Création d’un dossier “solr” dans “/var/lib/tomcat7”
    2. Dans ce dossier, j’ai bien 4 répertoires (collection1, site1, site2, site3)
    3. Dans chacun de ces dossiers, j’ai :
    >>> pour collection1 : 3 dossiers (conf, conf.old, data)
    >>> pour site1 : 1 dossier (conf)
    >>> pour site2 : 1 dossier (conf)
    >>> pour site3 : 1 dossier (conf)
    4. Création et édition du fichier “solr.xml” dans “/usr/share/solr”
    5. On y trouve bien dedans :

    6. Création du dossier “solr_data” dans “/var/lib/tomcat7/solr_data/”
    7. Création des 4 dossiers “Collection1” “site1” “site2” “site3” dans “/var/lib/tomcat7/solr_data/”
    8. Attribution des droits à l’utilisateur “tomcat7” via “chown -R tomcat7.tomcat7 /var/lib/tomcat7/solr_data/” (petite question au passage : doit-on préalablement créer l’utilisateur tomcat7 via la commande “adduser tomcat7” ?)

    Je redémarre bien le service tomcat “service tomcat7 restart”, mais rien n’y fait. Je ne vois que le core Collection1.
    Pouvez-vous m’aider svp ?

    Merci

    Kévin V.

  11. Ecrit par VANCAPPEL
    de 24/03/2014 à 7:00 pm
    Permalink

    Pour le point n°5, je complète car les balises ont du faire que ça ne s’affiche pas, j’ai bien renseigné ce que vous indiquez dans votre tuto.

    cores adminPath=”/admin/cores” defaultCoreName=”collection1″…

    …cores

  12. Ecrit par francois
    de 24/03/2014 à 10:53 pm
    Permalink

    Au point 5, je pense qu’il y a une coquille dans l’article…
    En fait, dans mon installation définitive, le fichier solr.xml contenant la déclaration des différents ‘cores’ se trouve dans le répertoire /var/lib/tomcat7/solr (ou faire un lien symbolique depuis /usr/share/solr/solr.xml, mais ce ne serait pas très propre, à y être autant tout regrouper !).
    Si les cores ne se lancent toujours pas, vérifiez s’il n’y a pas de messages particuliers dans le log de tomcat7 (/var/log/tomcat7/catalina.out).
    Sinon, pour l’utilisateur tomcat7, il a normalement dû être créé par l’installation du paquet Debian éponyme.

  13. Ecrit par tchoua
    de 26/10/2014 à 3:52 pm
    Permalink

    Bonjour,

    J’ai suivi votre tuto avec la version : solr 4.10
    J’ai eu du mal a me débarrasser de l’erreur : Caused by: org.apache.solr.common.SolrException: solrconfig.xml contains more than one value for config path : indexConfig/useCompoundFile

    Pour cela j’ai du modifier les fichiers solrconfig.xml pour les 4 dossiers :
    /var/lib/tomcat7/solr/collection1/conf/solrconfig.xml
    /var/lib/tomcat7/solr/site1/conf/solrconfig.xml
    /var/lib/tomcat7/solr/site2/conf/solrconfig.xml
    /var/lib/tomcat7/solr/site3/conf/solrconfig.xml

    J’ai du commenter les lignes 213 à 215 :
    <!– false
    32
    10
    –>

    Si cela peut aider.
    Merci pour votre tutorial.
    Cdlt
    Tchoua

  14. Ecrit par tchoua
    de 26/10/2014 à 3:57 pm
    Permalink

    Je suis désolé mais il semble que les ligne de code (syntaxe xml proche du html) ne soit pas prise en compte dans mon post :
    je tente dans ce 2eme post de les encoder :
    <!–
    <useCompoundFile>false</useCompoundFile>
    <ramBufferSizeMB>32</ramBufferSizeMB>
    <mergeFactor>10</mergeFactor>
    –>

Inscrivez-vous au fil RSS des commentaires

Ajoutez un commentaire