Sources :
Le cas d'utilisation décrit est l'installation d'une instance de Solr sur un serveur Debian 7/8 en vue de prototypage1).
Plus précisément, on choisit la version de Solr que l'ont installe et on utilise une version packagée intégrant un serveur de servlet. Autrement dit, aucun autre composant serveur ne sera nécessaire. En revanche, la présence d'une version minimale de Java JRE reste un pré-requis.
Bien que le système cible soit équipé de Virtualmin, l'installation de Solr sera indépendante de Virtualmin2).
Dans notre cas, le choix de version de Solr (5.4.1) est dicté par l'application, basée sur une instance Drupal 7 et interfacée via un module communautaire.
On récupère la version souhaitée de Solr via la page d'archivage des versions.
Comme indiqué en introduction, la version de Solr choisie incorpore le serveur de servlet. Il est donc inutile d'installer Java, Tomcat, etc.
Afin de procéder correctement à une installation correcte :
Dans tous les cas, Solr sera installé et configuré pour être exécuté avec les droits de l'utilisatrice solr, automatiquement créée.
$ cd /tmp $ wget http://archive.apache.org/dist/lucene/solr/5.4.1/solr-5.4.1.tgz $ wget http://archive.apache.org/dist/lucene/solr/5.4.1/solr-5.4.1.tgz.md5 $ md5sum -c solr-5.4.1.tgz.md5
Sachant syntaxe du script d'installation est la suivante :
install_solr_service.sh <archive_compressée_de_Solr> [OPTIONS]
il est inutile de décompresser toute l'archive. On se contente d'extraire le script d'installation :
$ tar xf solr-5.4.1.tgz solr-5.4.1/bin/install_solr_service.sh --strip-components=2
Installer Java (on a choisi une version légère de JRE)
$ sudo apt-get install openjdk-7-jre-headless
puis de lancer l'exécution du script:
$ sudo ./install_solr_service.sh solr-5.4.1.tgz
Voici l'affichage typique produit par le script d'installation se déroulant sans erreur4).
id: solr : utilisateur inexistant
Creating new user: solr
Ajout de l'utilisateur système « solr » (UID 117) ...
Ajout du nouveau groupe « solr » (GID 122) ...
Ajout du nouvel utilisateur « solr » (UID 117) avec pour groupe d'appartenance « solr » ...
Création du répertoire personnel « /var/solr »...
Extracting solr-5.4.1.tgz to /opt
Installing symlink /opt/solr -> /opt/solr-5.4.1 ...
Installing /etc/init.d/solr script ...
Installing /etc/default/solr.in.sh ...
● solr.service - LSB: Controls Apache Solr as a Service
Loaded: loaded (/etc/init.d/solr)
Active: active (running) since lun. 2017-07-17 15:35:02 CEST; 5s ago
Process: 9215 ExecStart=/etc/init.d/solr start (code=exited, status=0/SUCCESS)
CGroup: /system.slice/solr.service
└─9264 java -server -Xms512m -Xmx512m -XX:NewRatio=3 -XX:SurvivorRatio=4 -XX:TargetSurvivorRat...
juil. 17 15:34:56 server8 su[9217]: Successful su for solr by root
juil. 17 15:34:56 server8 su[9217]: + ??? root:solr
juil. 17 15:34:56 server8 su[9217]: pam_unix(su:session): session opened for user solr by (uid=0)
juil. 17 15:35:02 server8 solr[9215]: [169B blob data]
juil. 17 15:35:02 server8 solr[9215]: Started Solr server on port 8983 (pid=9264). Happy searching!
juil. 17 15:35:02 server8 systemd[1]: Started LSB: Controls Apache Solr as a Service.
juil. 17 15:35:02 server8 solr[9215]: [14B blob data]
Service solr installed.
On constate que l'installation a été suivie de l'activation réussie du service. À tout moment, il est possible de s'informer sur l'état du service Solr :
$ sudo service solr status
On s'assure que l'interface web d'administration est bien accessible. D'abord localement sur depuis le serveur lui-même :
$ lynx http://localhost:8983/
puis, depuis un autre système/ordi, avec un navigateur graphique, en pointant sur l'url : http://hostname:8983/ , où hostname est le nom du serveur.
Si tout s'est bien déroulé, on constate que Solr est actif mais qu'il n'existe aucun Core.
Solr ayant été installé en mode standalone5), nous allons créer un Core6).
Notre objectif étant d'exploiter Solr à travers le module communautaire de Drupal dénommé Search API Solr Search, nous allons nous appuyer sur les fichiers de configuration Solr proposés par ce module. Ces fichiers sont contenus dans un répertoire modèle structuré au format attendu par Solr.
Dans l'exemple traité, on crée deux Core Solr : un pour l'application en production, l'autre pour l'application en pré-production.
$ cd /tmp $ wget https://ftp.drupal.org/files/projects/search_api_solr-7.x-1.12.tar.gz $ tar xf search_api_solr-7.x-1.12.tar.gz search_api_solr/solr-conf/5.x --strip-components=2 $ sudo su - solr -c "/opt/solr/bin/solr create -c drupal_prod -d /tmp/5.x -n drupal_prod" $ sudo su - solr -c "/opt/solr/bin/solr create -c drupal_pre_prod -d /tmp/5.x -n drupal_pre_prod"
Dans l'exemple, le répertoire cible de configuration (-c) et le “nom logique” (-n) qui sera utilisé par Solr sont identiques. C'est un choix, par une obligation ! En revanche, on voit que le répertoire contenant le modèle de configuration (-d) utilisé (/tmp/5.x) existe de manière autonome.
Si l'on souhaite supprimer un core existant, on le désigne par le nom du répertoire cible de configuration.
$ sudo su - solr -c "/opt/solr/bin/solr delete -c drupal_pre_prod"
Et pour en savoir plus sur la commande de création de Core, autant demander à la commande elle-même :
$ sudo su - solr -c "/opt/solr/bin/solr create -help"
L'interface Web d'administration de Solr ne bénéficie d'aucune protection. Si le serveur ne se trouve derrière un pare-feu correctement configuré, il convient de mettre en place un contrôle d'accès.
$ sudo iptables -A INPUT -p tcp -s localhost --dport 8983 -j ACCEPT $ sudo iptables -A INPUT -p tcp --dport 8983 -j DROP
Il pourra être intéressant d'autoriser un poste d'adaministration ou tout un réseau. La première règle donne le motif à utiliser, en remplaçant localhost par ce qui convient à votre cas. Suppression des règles(Pour un mini-mémo sur l'ajout et la suppression de règles : How To List and Delete Iptables Firewall Rules.)) :
$ sudo iptables -D INPUT -p tcp --dport 8983 -j DROP $ sudo iptables -D INPUT -p tcp -s localhost --dport 8983 -j ACCEPT