Schlagwort-Archive: Solr

Solr, Nutch und boost

Der Web-Crawler nutch berechnet aus der Linkstruktur einen Score und speichert ihn im Feld „boost“ ab. Leider scheint der boost nicht automatisch in den Gesamt-Score einzugehen. Eine Verwendung des Felds boost in der boost function (bf) des dismax-Parsers scheitert mit einer Fehlermeldung, weil die standardmäßige schema.xml von nutch das Feld nicht als uninvertible deklariert. Die Doku fand ich leider wenig hilfreich.

Eine Änderung der schema.xml im nutch-configset brachte für mich Abhilfe. Die Felddeklaration von boost sollte so aussehen:

<field name="boost" type="float" stored="true" uninvertible="true"/>

Anschließend kann bei der Solr-Suche im dismax-Parser in der bf das Feld boost verwendet werden. Es handelt sich dabei um einen additiven Boost für jedes Dokument. In der debug-Ansicht lässt sich die Berechnung des Scores nachvollziehen.

Solr Authentication

Aus der beliebten Serie „ein paar unsortierte Notizen mit Computerkram für mich selbst“ hier wie man in Solr 8.1 die Authentifizierung einschaltet (und anschließend aus Python heraus mir urllib abfragt). Quellen sind die Doku von Solr und die Doku von urllib.

Standardmäßig ist es bei Solr so, dass ohne jede Authentifizierung über die Admin-Oberfläche alles gemacht werden kann, insbesondere auch Dokumente aus dem Korpus löschen und so weiter! Die hier beschriebene Basic Authentication ist wenigstens ein Minimum an Zugriffsschutz, aber nach heutigen Maßstäben ist es nicht so sicher, jedenfalls nicht wenn man es nicht mit HTTPS kombiniert. Es ist empfehlenswert, zusätzlich dafür zu sorgen, dass der Solr-Server nicht aus dem Internet erreichbar ist.

Ins Verzeichnis solr-8.10.1/server/solr kommt in die Datei security.json folgender Inhalt:

{
"authentication":{ 
   "blockUnknown": true, 
   "class":"solr.BasicAuthPlugin",
   "credentials":{"solr":"IV0EHq1OnNrj6gvRCwvFwTrZ1+z1oBbnQdiVC3otuq0= Ndd7LKvVBAaZIF0QAVi1ekCfAJXr1GGfLtRUXhgrF8c="}, 
   "realm":"My Solr users", 
   "forwardCredentials": false 
},
"authorization":{
   "class":"solr.RuleBasedAuthorizationPlugin",
   "permissions":[{"name":"security-edit",
      "role":"admin"}], 
   "user-role":{"solr":"admin"} 
}}

Was bei credentials hinter dem Usernamen steht ist nicht so gut dokumentiert, offenbar wird erwartet, dass man das solr-Skript mit dem Kommando auth benutzt. Das nölt aber immer rum, wenn man nicht den ZooKeeper sondern eine Standalone-Installation verwendet. In der Beispieldatei ist das Passwort „SolrRocks“, der abgelegte String ist im Prinzip ein salted sha256, aber die Methode, wie das zustande kommt, ist etwas dubios. Auf github habe ich ein Skript gefunden, mit dem man den credentials-String erzeugen kann. Evtl. sind dafür noch Packages nachzuinstallieren, z.B. pwgen. Der Salt wird automatisch erzeugt und muss nicht angegeben werden.

#!/bin/bash
PW=$1
SALT=$(pwgen 48 -1)
echo "hash    : $(echo -n "$SALT$PW" | sha256sum -b | xxd -r -p | sha256sum -b | xxd -r -p | base64 -w 1024) $(echo -n "$SALT" | base64 -w1024)"

Mehrere credentials bestehend aus Usernamen und salted hashs können JSON-mäßig mit Komma hintereinander gehängt werden.

Und hier noch wie man in Python bei urllib die HTTP-Authentication benutzt:

    # Create an OpenerDirector with support for Basic HTTP Authentication...
    auth_handler = urllib.request.HTTPBasicAuthHandler()
    auth_handler.add_password(realm='My Solr users',
                              uri='http://localhost:8983/',
                          user='solr',
                          passwd='SolrRocks')
    opener = urllib.request.build_opener(auth_handler)
    # ...and install it globally so it can be used with urlopen.
    urllib.request.install_opener(opener)

Das Passwort steht dann halt im Klartext da drin. Das billige Authentication-Modul von Solr wird sicherheitsmäßig eh nicht für jeden Bedarf ausreichen und sollte für den Produktivbetrieb jedenfalls nicht als einzige Zugriffsbeschränkung benutzt werden.

Um mit dem Solr-Skript von der Kommandozeile Dinge zu erledigen (z.B. einen neuen Core anlegen) müssen bei eingeschalteter Basic Authentication noch folgende Variablen gesetzt werden (wie bei allem gilt, den Usernamen und das Passwort durch die eigenen zu ersetzen). Folgendes ist in die bin/solr/solr.in.sh einzusetzen bzw. die im Beispiel schon vorhandenen entsprechenden Zeilen auszukommentieren:

SOLR_AUTH_TYPE=basic
SOLR_AUTHENTICATION_OPTS="-Dbasicauth=solr:SolrRocks"

Nutch und Solr einrichten

Wer selber Suchmaschinenbetreiber werden und dem Großen G Konkurrenz machen will, kann das mit dem Webcrawler Nutch und dem Suchserver Solr tun. Leider ist das Tutorial von Nutch nicht ganz so deutlich, enthält ein paar unnötig komplizierte Sachen und zudem in einer nicht ganz logischen Reihenfolge.

Das hier gezeigte Vorgehen wurde mit Ubuntu 16.04 getestet, sollte aber genau so mit anderen Linuxen oder macOS funktionieren.

Unter Windows laufen die Nutch-Skripte nicht. Da das eigentliche Nutch selbst aber genau wie Solr in Java implementiert ist, ließe sich das mit Cygwin lösen. Die Frage ist nur, ob man das auch will…

Für die Beispiele wird davon ausgegangen, dass sich Nutch im Verzeichnis „apache-nutch-1.14“ und Solr im Verzeichnis „solr-6.6.3“ jeweils direkt unterhalb des Home-Verzeichnisses befinden.

Wer möchte, kann das Nutch-Tutorial parallel öffnen. Ich orientiere mich hier am Stand des Tutorials vom Mai 2018 und weise jeweils auf Stellen im Tutorial hin.

1. Voraussetzungen: Java und Solr

Siehe Abschnitt Requirements im Tutorial.

Nutch 1.14 setzt Java voraus. Von mir wurde Nutch mit Java 1.8 getestet.

Ant ist nicht nötig, wenn Nutch als Binary geladen und nicht selbst kompiliert werden soll.

Damit Nutch die gecrawlten Webseiten direkt zum Indexieren an Solr weiterreichen kann, muss die passende Solr-Version laufen. Nutch 1.14 läuft mit Solr 6.6

Die Installation von Solr ist denkbar einfach, es ist lediglich ein Archiv herunterzuladen und zu entpacken.

(Im Tutorial wird Solr erst später erwähnt, es ist meiner Ansicht nach aber empfehlenswert, schon an dieser Stelle Solr zum Laufen zu bringen und zu testen.)

2. Nutch herunterladen

Siehe Option 1 im Abschnitt Install Nutch im Tutorial.

Die Installation von Nutch läuft erst mal fast genau so: Downloaden von http://nutch.apache.org/ und in ein Verzeichnis nach Wahl entpacken.

Siehe nun Verify your Nutch installation im Tutorial.

Aus dem Nutch-Verzeichnis heraus sollte jetzt ein „bin/nutch“ schon funktionieren und Nutch sollte zumindest mal ein Lebenszeichen von sich geben.

Wenn Nutch wie oben angegeben ins Verzeichnis „apache-nutch-1.14“ entpackt wurde, sind folgende Befehle einzugeben:

cd apache-nutch-1.14/
bin/nutch

Es sollte eine Meldung erscheinen, die die möglichen Nutch-Kommandos auflistet.

Achtung: An der /etc/hosts herumzufummeln, wie es im Tutorial steht, sollte im allgemeinen nicht notwendig sein!

3. JAVA_HOME setzen

Wir sind immer noch bei Verify your Nutch installation im Tutorial.

Möglicherweise ist die Umgebungsvariable JAVA_HOME nicht gesetzt. Ob das so ist, erfährt man durch Eingabe von

echo $JAVA_HOME

Wenn nichts ausgegeben wird, war JAVA_HOME nicht gesetzt. Dann ist unter Ubuntu (oder Debian) folgendes zu tun:

export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")

Damit beim nächsten Neustart des Terminals die JAVA_HOME gleich gesetzt ist, empfiehlt es sich, diese Zeile ans Ende der .bashrc im Home-Verzeichnis anzufügen:

cd

echo 'export JAVA_HOME=$(readlink -f /usr/bin/java | sed "s:bin/java::")' >> .bashrc

Unter macOS setzt man die JAVA_HOME wie folgt auf den korrekten Wert (Achtung, die Angabe im Nutch-Tutorial stimmt für neuere macOS-Versionen nicht!):

export JAVA_HOME=$(/usr/libexec/java_home)

Bei macOS würde man die JAVA_HOME wohl eher in der .profile setzen:

cd

echo 'export JAVA_HOME=$(/usr/libexec/java_home)' >> .profile

4. Crawler-Properties

Wir sind im Tutorial nun bei Customize your crawl properties.

Der Crawler meldet sich bei den Web-Server, die gecrawlt werden, mit seinem Namen. Es ist aber standardmäßig nichts voreingestellt. Ohne dass wir hier etwas konfigurieren, verweigert Nutch seinen Dienst.

In die Datei apache-nutch-1.14/conf/nutch-site.xml muss folgendes rein (der fette Teil ist neu):

<?xml version="1.0"?>
<?xml-stylesheet type="text/xsl" href="configuration.xsl"?>

<!-- Put site-specific property overrides in this file. -->

<configuration>
<property>
<name>http.agent.name</name>
<value>Der Test Nutch Spider</value>
</property>
</configuration>

Statt „Der Test Nutch Spider“ sollte man natürlich selber irgendeinen Namen wählen.

5. Solr konfigurieren

Wir überspringen einiges im Tutorial und gehen nun direkt zu Setup Solr for search.

Im Tutorial wird als zu Nutch 1.14 zugehörig die Version Solr 6.6.0 angegeben. Im Test funktionierte es aber auch mit 6.6.3. Mit Solr 7 dagegen könnte es Probleme geben.

Die von Nutch gecrawlten Webseiten sollen in einen eigenen Solr-Core. Zum Setup des Schemas für diesen Core nehmen wir die Standard-Beispielkonfiguration von Solr und kombinieren sie mit einer schema.xml, die von Nutch geliefert wird.

Die Schritte im einzelnen:

1. Das Configset basic_configs kopieren und neu nutch nennen.

Update!

Das Configset heißt a Solr 7 „_default“ und nicht mehr „basic_configs“. Wenn Ihr bei den Befehlen unten das entsprechend ersetzt, funktioniert die Anleitung auch noch mit Nutch 1.16 und Solr 7.

2. Die managed_schema im Configset nutch löschen.

3. Die schema.xml von Nutch ins neue Configset nutch kopieren.

Noch ein Update!

Im Nutch-Tutorial ist im Abschnitt „Setup Solr for search“ eine alternative schema.xml verlinkt, am besten die „most recent schema.xml“ verwenden und die im Configset „nutch“ ersetzen.

4. Solr starten

5. Einen neuen Core unter Verwendung des soeben erstellen Configsets einrichten.

Die Befehle dazu:

cd
cd solr-6.6.3/
cd server/solr/configsets/

cp -r basic_configs nutch

cd nutch/conf

rm managed-schema

cd

cp apache-nutch-1.14/conf/schema.xml solr-6.6.3/server/solr/configsets/nutch/conf/

cd solr-6.6.3/

bin/solr start

bin/solr create -c nutch -d server/solr/configsets/nutch/conf/

6. Nutch klar machen zum Crawlen

Wir springen nun im Tutorial zurück zu „Create a URL seed list„.

Wenn man das Web crawlen will, muss man irgendwo anfangen. Diese Startseiten kommen in die Seed List.

Den Teil des Tutorials, wie man an eine schöne Seed List kommt, in dem man z.B. eine Liste von Webseiten von dmoz herunterlädt, ignorieren wir hier mal, wir machen das von Hand und setzen unsere Lieblingswebseite als Startpunkt.

Die Schritte im einzelnen:

1. Unterhalb von apache-nutch-1.14 ein Verzeichnis urls anlegen

2. Darin eine Datei seed.txt anlegen und da drin einfach eine Liste von URLs eintragen.

Konkret:

cd

cd apache-nutch-1.14/

mkdir urls

cd urls

echo 'http://hs-furtwangen.de/' > seed.txt

Jedenfalls sollte man das so machen, wenn die Webseite der Hochschule Furtwangen die Lieblingswebseite ist.

Den Regex-URL-Filter (siehe Tutorial) lassen wir so er ist. Wir müssten den ändern, wenn wir z.B. nur die Unterseiten einer Homepage crawlen und indexieren wollen, ohne externe Links zu verfolgen.

Den ganzen Abschnitt „Using Individual Commands“ überspringen wir mal getrost. Die Befehle, die dort stehen, sind zwar schön, wenn man mal sehen will, was im einzelnen passiert, aber zu kompliziert.

7. Crawl starten!

Wir gehen im Tutorial direkt zu Using the crawl script.

Den Aufruf des Crawl-Skripts ist im Tutorial erklärt, aber wir können selber das Skript von einem eigenen Skript aus starten, das direkt schon die gewünschten Parameter enthält. 🙂

Ich gehe hier davon aus, dass, wie hier im Beispiel, der Solr-Server auf dem selben Rechner läuft, der Core nutch heißt und die Seed-Liste dort liegt, wo wir sie in Schritt 4 gerade angelegt haben. Außerdem sind hier jetzt mal 50 Iterationen eingestellt. Das ist viel! Man kann den Crawl-Vorgang aber ruhig zwischendurch abbrechen.

cd

cd apache-nutch-1.14/

echo 'bin/crawl -i -D solr.server.url=http://localhost:8983/solr/nutch -s urls crawl 50' >> crawl.sh

chmod +x crawl.sh

./crawl.sh

8. Die Ergebnisse begutachten

Schon während der Crawl läuft, können wir in der Admin-Oberfläche von Solr den Index abfragen. Spätestens jetzt empfiehlt es sich, sich mit dem Schema des neuen Cores vertraut zu machen, um anschließend ein schönes Frontend programmieren zu können.

Viel Spaß!