Thomas Kramer

IT-COW | All posts tagged 'Java'

Nextcloud mit ElasticSearch um Volltextsuche erweitern

By Administrator at April 13, 2022 22:21
Filed Under:

Wenn man viele Dokumente in Nextcloud speichert, ist die Erweiterung um eine Volltextsuche hilfreich. Im Nextcloud Appstore gibt es dazu die “Full Text Search”-Apps, die optional heruntergeladen und installiert werden können:

 

image

 

Jedoch ist es mit der Installation dieser Apps nicht getan, da es sich nur um Wrapper für die Kommandozeilentools ElasticSearch und Tesseract (OCR-Texterkennung in Bildern) handelt. Eine Installationsanleitung dazu gibt es bei Decatec, oder sehr ähnlich bei Carsten Rieger IT-Services.

 

Ganz ausreichend war die Anleitung für mich aber nicht, denn beim Start von ElasticSearch bekam ich die folgende Fehlermeldung, die ich mit dem Befehl “systemctl status elasticsearch.service” einsehen konnte.

 

Apr 13 19:57:02 elasticsearch systemd[1]: Starting Elasticsearch...
Apr 13 19:57:39 elasticsearch systemd-entrypoint[1253]: ERROR: [1] bootstrap checks failed. You must address the points described in the following [1] lines before starting Elasticsearch.
Apr 13 19:57:39 elasticsearch systemd-entrypoint[1253]: bootstrap check failure [1] of [1]: the default discovery settings are unsuitable for production use; at least one of [discovery.seed_hosts, discovery.seed_providers, cluster.initial_master_nodes] must be configured
Apr 13 19:57:39 elasticsearch systemd-entrypoint[1253]: ERROR: Elasticsearch did not exit normally - check the logs at /var/log/elasticsearch/elasticsearch.log

 

Man muss in die Konfigurationsdatei von ElasticSearch

nano /etc/elasticsearch/elasticsearch.yml

auch den Beferhl

discovery.seed_hosts: ["0.0.0.0"]

mit hineinnehmen. Das fehlt in der Anleitung, aber vielleicht ist das auch erst später durch ein Update hinzugekommen.

 

Da ElasticSearch bei mir nicht innerhalb der Nextcloud-Instanz sondern über Proxmox in einer eigenen CT läuft, darf ElasticSearch auch nicht nur lokal verfügbar sein:

network.host: 0.0.0.0

Eine Erklärung der Parameter der Konfigurationsdatei ist bei elastic.co zu finden. Weitere Parameter sind hier erläutert. Bei Problemen wird man sich auch die Logging-Einstellungen anschauen müssen, aber alles läuft über die Kommandozeile.

 

Danach den Dienst neu starten und es funktioniert:

service elasticsearch restart

 

Allerdings muss man der Instanz sehr viel RAM zuweisen. Wenn beim Starten des Dienstes die Fehlermeldung

elasticsearch.service: A process of this unit has been killed by the OOM killer

kommt, ist zuwenig RAM zugeordnet worden.

 

Mit den Default-Einstellungen und ohne dass ein Scan läuft, brauchte die Instanz bei mir bereits 8,7 GB der zugeordneten 10 GB RAM, während des Scans änderte sich das aber nicht mehr wesentlich. Da man in Nextcloud den Host für ElasticSearch angeben kann (Java),

image

muss der Dienst nicht auf demselben Rechner wie Nextcloud laufen. Tesseract scheint aber clientseitig Rechenlast zu erzeugen, das ist bei mir der Nextcloud-Server. Ich sehe keine Tesseract-Prozesse auf dem ElasticSearch-Server, insofern scheint mir die OCR-Textindizierung für einen Raspberry Pi generell ungeeignet zu sein, da nicht auslagerungsfähig.

 

Ich habe gerade den RAM-Verbrauch von ElasticSearch noch signifikant senken können, dazu setzt man die folgenden Befehle ab:

cd /etc/elasticsearch/jvm.options.d
nano jvm.options

und schreibt dann die Java-Parameter

-Xms2g
-Xmx2g

hinein und startet anschließend den Dienst mit

service elasticsearch restart

neu. Der VM oder CT sollte man dann 4 GB RAM zuordnen, da in der Anleitung steht:

image

Quelle elastic.co. Damit läuft es dann auch zufriedenstellend schnell, braucht nur 2,6 GB von 4 GB RAM und swappt vor allem nicht mehr.

 

Der initiale Scan zum Aufbauen des Indexes dauert natürlich sehr lange, erst recht mit OCR-Texterkennung in Bildern (über Tesseract). Bei mir trat dabei immer der Fehler

elasticsearch Error: Call to a member function getContent() on string in /var/www/html/custom_apps/files_fulltextsearch pdf

bei jedem Scan von PDF-Dateien auf, ich empfehle den Parameter

image

zu deaktivieren. PDF-Dateien indiziert er dann immer noch, aber versucht nicht mehr Texte in Bildern von PDF-Dateien zu finden. Falls man die Funktion doch benutzen will, ich habe gerade einen Workaround dazu bei github gefunden. Scheinbar muss man dazu Rechtefreigaben in der Konfigurationsdatei von ImageMagick im Nextcloud-Container korrigieren:

 

image

 

Je nach Quelle kann alles in einer PDF-Datei ein einziges Bild sein, auch Text. Dann ist das unbrauchbar langsam. Ich habe das Feature bei mir wieder abgeschaltet.

 

Standardmäßig werden von Nextcloud nur Dateien mit einer maximalen Dateigröße von 20 MB indiziert. Ich hatte den Wert bei mir auf 100 MB hochgesetzt und bekam dann bei einer PDF-Datei mit ca. 87 MB Größe folgende Fehlermeldung:

PHP Fatal error:  Allowed memory size of 536870912 bytes exhausted

Der Arbeitsspeicher-Grenzwert für PHP ist im Nextcloud-Container defaultmäßig auf 512 MB begrenzt, das reicht zur Indizierung großer PDF-Dateien nicht mehr aus. In der Nextcloud-Oberfläche ist dieser Wert unter System zu sehen. Das kann man beheben indem man lokal eine PHP.ini-Datei mit folgenden Werten anlegt:

 

memory_limit=1G
upload_max_filesize=${PHP_UPLOAD_LIMIT}
post_max_size=${PHP_UPLOAD_LIMIT}

 

Und dann lässt man diese Datei in den Container über die YAML-Datei veröffentlichen:

- ./php.ini:/usr/local/etc/php/conf.d/zzz-custom.ini

Wobei die Benennung der Datei mit führendem Z-Buchstaben wahrscheinlich dafür sorgt, dass die Datei zuletzt eingelesen wird. Den Tipp habe ich aus dieser Github-Diskussion. Konfigurationsdateien für Linux sollten natürlich andere Zeilenumbruchzeichen als unter Windows verwenden, daher in Notepad++ auf Unix umstellen.

image

 

Dann lässt man den Nextcloud-Docker-Container neu starten und in der Nextcloud-Oberfläche ist der Erfolg zu sehen:

image

 

Wichtig kann auch sein bestimmten Ordnern eine .noindex-Datei hinzuzufügen, damit ein Ordner nicht indiziert wird. Das hat dann eher mit Nextcloud als Elasticsearch zu tun. Zum Beispiel macht es wenig Sinn, den Inhalt von MP3-Dateien versuchen zu indizieren.

 

Falls die Indizierung mit einem Fehler abgebrochen war, muss man sie komplett mit dem Befehl

docker exec --user www-data nextcloud /var/www/html/occ fulltextsearch:stop

stoppen, mit

docker exec --user www-data nextcloud /var/www/html/occ fulltextsearch:reset

kann man den Index zurücksetzen. Mit dem Befehl

docker exec --user www-data nextcloud /var/www/html/occ fulltextsearch:test

kann man einen Testlauf starten, mit dem Befehl

docker exec --user www-data nextcloud /var/www/html/occ fulltextsearch:index

kann man den Indizierungslauf neu starten. Zumindest lauten die Befehle so, wenn bei euch Nextcloud wie bei mir in einem Docker läuft und der Nextcloud benannt wurde, ansonsten müsst Ihr die Befehle abwandeln.

 

Insgesamt erscheint mir die Volltextsuche schon brauchbar, aber bei der Texterkennung in Bildern hatte ich mir noch etwas mehr erwartet. Man kann es sicher weiterempfehlen, aber den RAM-Verbrauch würde ich für private Zwecke wie oben beschrieben etwas senken. Früher hatte ich als Volltextsuche übrigens mal Regain verwendet, aber das hatte noch nichts mit Nextcloud zu tun.

   

Tag-Wolke

Monats-Liste