Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen angezeigt.

--- administration:suche [2014/10/06 08:16] – [Tika überlastet Server] lulrich
+++ administration:suche [2023/02/01 14:44] (aktuell) – [Seiten von der Suche ausschliessen (Neu v11)] paellig
@@ Zeile 7: / Zeile 7: @@
   * **Seiten:** Werden über den normalen Solr-Indexer-Scheduler-Task indexiert. Änderungen an Seiten und Inhalten werden über DataHandler-Hooks erkannt und bei einer Änderung wird das entsprechende Element zur Neuindexierung/Löschung terminiert.
   * **Dokumente:** Im Inhalt verlinkte Dokumente werden von der Extension "solrfal" (nur für EAP2-Kunden zugänglich, visol ist EAP2-Kunde) indexiert. Bei der Indexierung wird über SignalSlot der Tika-Dienst der Extension "tika" aufgerufen, welcher die Metadaten und den Inhalt der Datei ausliest und in der Tabelle sys_file_reference speichert (Feld "tika_content"). Der Inhalt dieses Feldes wird ebenfalls in die Datenbank geschrieben, sodass eine Volltextsuche aller Dokumente möglich ist. Der Titel aus sys_file_reference wird in ein separates Feld "falTitle_stringS" gespeichert und wird - falls gesetzt - anstelle des Dateinamens ausgegeben.
-  * **Personen:** Die proprietäre Extension useruniluaddress importiert täglich alle Adressen aus einem von der Uni automatisiert auf den Server (/home/www-data/externaldata) gestellten XML-File. Ist dieses File gültig, werden via DataHandler alle bestehenden Adressen gelöscht, was auch die Löschung aus dem Solr-Index triggert. Danach werden alle Adressen neu importiert. Für Personen gibt es eine spezielle Suchausgabe, die direkt Telefonnummer, E-Mail-Adresse und Links auf Visitenkarte und Website anzeigt. Personen werden mit einem boostQuery priorisiert, sodass z.B. bei der Suche nach "Portmann" das Personen-Resultat Lukas Portmann vor Seiten mit Portmann im Text erscheint.
+  * **Personen:** Die proprietäre Extension useruniluaddress importiert täglich alle Adressen aus einem von der Uni automatisiert auf den Server (/home/www-data/externaldata) gestellten XML-File. Ist dieses File gültig, werden via DataHandler bestehende Adressen aktualisiert, entfernte gelöscht und neue hinzugefügt, was auch die entsprechenden Aktionen für den Solr-Index triggert. Für Personen gibt es eine spezielle Suchausgabe, die direkt Telefonnummer, E-Mail-Adresse und Links auf Visitenkarte und Website anzeigt. Personen werden mit einem boostQuery priorisiert, sodass z.B. bei der Suche nach "Portmann" das Personen-Resultat Lukas Portmann vor Seiten mit Portmann im Text erscheint.
 Für die Eingrenzung der Suche werden Facets verwenden. Die Facetten stehen bereits im Suchformular zur Verfügung:
@@ Zeile 21: / Zeile 21: @@
 **Berechtigung: Web-Administrator**
-Seiten, die nicht in der Suche erscheinen sollen, können für die Suche in den Seiteneigenschaften deaktiviert werden:
+Seiten, die nicht in der Suche erscheinen sollen, können für die Suche in den Seiteneigenschaften deaktiviert werden. Die Funktion heisst **Bei Suchmaschinen und Seitensuche indexieren/Index in search engines and site searches**. Das Deaktivieren der Checkbox bedeutet auch, dass diese Seiten gleichzeitig auch für externe Suchmaschinen wie z.B. Google als "nicht zu indexierende Seiten" markiert werden:
-{{:administration:pasted:20140614-234938.png}}
+{{:administration:pasted:20230201-143358.png}}
-Um dies für mehrere Seiten rekursiv zu machen, gibt es im Bereich Web > Funktionen ein Modul:
+Die Bedeutung der weiteren Felder ist:
+  * **Dieser Seite folgen/Follow this page**: Instruktion an die Suchmaschiene, dass sie allen Links auf dieser Website  für die weitere Indexierung folgen soll.
+  * **Untereinträge in Indexsuche einbeziehen/Include sub entries in Search**: Wenn dieses Feld deaktiviert wird, werden die Unterseiten **nicht** in die interne Suche der Website aufgenommen - egal wie die Konfiguration der Unterseite selbst ist. Dies ist z.B. bei einem Anmeldeformular mit einer untergeordneten Dankensseite praktisch.
+  * **Bilder aus Suche ausschliessen/Exclude images from search**: [[redaktion:f._bilder#bilder_aus_suche_zb_google_ausschliessen|Siehe Beschreibung]]
-{{:administration:pasted:20140614-233323.png}}
+Um für mehrere Seiten gleichzeitig, rekursiv die Checkbox **Dieser Seite folgen/Follow this page** zu setzen, gibt es im Hilfsmenü einer Seite ein Modul. Das Hilfsmodul kann durck Rechtsklick auf das Seiten-Icon aufgerufen werden:
-===== Troubleshooting =====
+{{:administration:pasted:20230201-153908.png}}
+===== Bilder von der Suche ausschliessen =====
+Siehe [[redaktion:f._bilder#bilder_aus_suche_zb_google_ausschliessen|Anleitung]]
+===== Setup von Solr & Troubleshooting =====
 Da Nine keinen Solr-Server in Version 4.8 bieten kann, wurde der Solr-Server mit dem Benutzer www-data selber installiert und muss auch selber betrieben werden. Insofern ist bei technischen Problemen von Nine auch keine Unterstützung zu erwarten.
-==== Tika überlastet Server ====
+==== Setup ====
-Tika extrahiert Inhalt und Metadaten aus allen Dokumenten, die auf der Website verknüpft sind. Offenbar kann Tika leaken; vermutlich, wenn es ein besonders grosses File oder ein fehlerhaftes File zu lesen versucht. Der Java-Prozess benötigt dann rund 100% CPU über längere Zeit, was den Server langsam macht.
+Da die mit der TYPO3-Solr-Extension mitgelieferten Installations-Skripts auf Administrator-Rechte überprüfen, mussten sie angepasst werden. Das komplette Setup ist in Github versioniert:
+https://github.com/phluzern/unilu-solr-tomcat
+(Master-Branch: Konfiguration für Unilu/phlu-eduweb2. Es gibt noch einen Branch phlu.ch für PHLU/phlu-eduweb3.)
-Durch ein "killall java" werden alle Java-Prozesse beendet, damit allerdings auch der Solr-Server, der neu gestartet werden muss.
+==== Zugriff auf die Web-Oberfläche ====
-//ToDo: Dieses Problem ist seit der "Massenindexierung" der mehreren tausend Files zum Start nicht mehr aufgetaucht.//
+Tomcat läuft auf Port 8080. Dieser Port ist von aussen nicht zugänglich, was aus Sicherheitsgründen auch vorteilhaft ist. Als Nebeneffekt ist aber die Solr-Weboberfläche nicht zugänglich. Dieses Problem kann umgangen werden, indem man einen SSH-Tunnel zum Server aufbaut und diesen im Browser (am besten in einem Zweitbrowser) als Proxy nutzt. Der SSH-Tunnel ist im Prinzip eine normale Verbindung zum Server mit einer Port-Forwarding-Konfiguration:
+{{:administration:pasted:20141006-102220.png}}
+{{:administration:pasted:20141006-102409.png}}
+Diese Verbindung wird dann mit den normalen SSH-Zugangsdaten geöffnet.
+Nun muss der Browser konfiguriert werden, diese Verbindung (im Beispiel auf Port 2048) zu nutzen. Konfiguration in Firefox:
+{{:administration:pasted:20141006-102608.png}}
+Sobald diese Konfiguration aktiv ist, kann die Solr-Weboberfläche unter http://localhost:8080/solr geöffnet werden.
+{{:administration:pasted:20141006-102837.png}}
+Wichtiger Hinweis: Hier gemachte Änderungen beziehen sich nur auf die aktuelle Ausführung von Tomcat/Solr. Bei einem Neustart gehen die Änderungen verloren. Permanente Konfigurationsänderungen müssen in den Konfigurations-Dateien vorgenommen werden.
 ==== Solr-Server starten ====
@@ Zeile 49: / Zeile 78: @@
 ~/solr-tomcat/tomcat/bin/startup.sh
 </code>
-Der englische Index funktionierte nach einem Startup ohne vorheriges Shutdown jeweils nicht mehr, was eigentlich unlogisch ist.
 Dass Solr wieder geht, kann anschliessend im Backend verifiziert werden:
 {{:administration:pasted:20140705-123726.png}}
+Der Solr-Server wird bei jedem System-Neustart automatisch gestartet. Dafür sorgt folgender Eintrag in der Crontab:
+<code>
+# Start Solr/Tomcat on Reboot
+@reboot /home/www-data/solr-tomcat/tomcat/bin/startup.sh
+</code>
+==== Logging-Konfiguration ====
+Die mitgelieferte Logging-Konfiguration führt zu sehr vielen und grossen Logs, da für den produktiven Betrieb nicht relevante Informationen (Log-Level INFO) geloggt werden. Der Log-Level wurde daher global auf WARN gestellt und das TransactionLog, welches für jede neu indexierte Adresse ein neues Log-File erstellte, ganz deaktiviert.
+Die Logging-Konfiguration ist zu finden unter
+<code>
+/home/www-data/solr-tomcat/tomcat/lib/log4j.properties
+</code>
+==== Tika überlastet Server ====
+Tika extrahiert Inhalt und Metadaten aus allen Dokumenten, die auf der Website verknüpft sind. Offenbar kann Tika leaken; vermutlich, wenn es ein besonders grosses File oder ein fehlerhaftes File zu lesen versucht. Der Java-Prozess benötigt dann rund 100% CPU über längere Zeit, was den Server langsam macht.
+Durch ein "killall java" werden alle Java-Prozesse beendet, damit allerdings auch der Solr-Server, der neu gestartet werden muss.