Ja, hallo zusammen, herzlich willkommen zum Vortrag Open Source Search Engines, Schlussspurt quasi auf der Froscon 2. Tag an der Stelle, weil es am Ende sonst immer untergeht.

Vielen, vielen Dank an das Orga-Team, eine wunderschöne Froscon. Wie eigentlich immer, danke auch an die, die technisch unterstützen etc. Es geht heute um Open Source Search Engines, also Suchmaschinen oder Suchmaschinen-Komponenten.

Schauen wir uns das gleich an. Grundsätzlich möchte ich gerne zunächst einen kurzen Vortrag halten und einmal schnell durchgehen durchs Thema, um das eben einzuordnen, anschließend ein bisschen was aus der Praxis.

Auch mal zeigen mit verschiedenen Fallstricken, die sich eben ergeben und anschließend, wenn ihr mögt, in einer ausgiebigen Diskussion mit euch starten, vielleicht eben auch kurz Austausch über Erfahrungen, die ihr gesammelt habt, Fragen etc. Ich bin Michael Hierwig, eigentlich in der Open Source Szene, wie auch immer, aktiv seit 20 Jahren,

inzwischen darf ich sagen, und für unterschiedliche Unternehmen tätig. Den Vortrag heute halte ich für die QSI GmbH. Das ist ein Software, es ist Service-Dienstleister aus Berlin, der unter anderem eben auch im Bereich Search Engines Sachen im Programm hat.

Das soll ich aber an der Stelle nur untergeordnete Rolle spielen. Genau. Suchlösungen gibt es in verschiedener Form aus Open Source Komponenten

oder eben auch aus kommerziellen, proprietären Komponenten in Form von Appliances. Das sind eben so Bundles aus Hardware und Software. Als Software ist es Service, was hier so schön Third Party Hosted Services heißt, oder man kann es eben, das ist wahrscheinlich so für Open Source Fans das Beste, eben tatsächlich auch selbst hosten

und es geht eben um Anbindung von Drittsystemen und eben Fragen, was man mit den Komponenten machen kann, wo potenzielle Schwierigkeiten auftreten. Die bekanntesten Anbieter von Such Appliances, nachdem eben die Google Search Appliance jetzt ausläuft oder ausgelaufen ist,

sind hier aufgezählt oder dargestellt. Wenn man jetzt also so Enterprise-mäßig irgendwie eine Lösung sucht, dann kann man diese aus der Packung nehmen. Das hat verschiedene Vor- und Nachteile. Vorteil ist, man kann sie einfach kaufen und ins Rack schrauben, hat da an der Stelle wenig Stress.

Ja gut, und dann kommen eben die Nachteile. Typischerweise keine Redundanz, mitunter auch nicht zukaufbar. Backup, Konfigurationsänderung. Eigentlich müsste man irgendwie entwickeln, staging, keine Ahnung was wie.

Na ja, kann man auf den Dingern halt irgendwie klicken und dann hoffen, dass das eben funktioniert. Und die haben auch sehr unterschiedliche Lizenzmodelle. Es gibt eben Search Appliances, bei denen dann zum Beispiel 25.000 Dokumente lizenziert sind und die sagen einem dann nicht proaktiv im Monitoring-System, sobald ist voll,

du hast noch 10% oder sowas, sondern man darf sich darauf einloggen und mal nachgucken, wie viel dann eigentlich schon weg ist. Und unter Umständen sagen sie auch nicht, wenn es aufgebraucht ist, sondern indizieren dann neue einfach nur nicht mehr. Es kann also durchaus Überraschungen geben, da sollte man einfach ein bisschen aufpassen,

bevor man eben sowas kauft. Dann gibt es das Ganze als Software-as-a-Service. Teilweise eben auch bei denselben Anbietern einzukaufen. Und gut, ist halt eben auch die Frage, wem gebe ich jetzt meine Daten?

Also welche Daten habe ich denn da eigentlich drin, wenn ich jetzt irgendwie nur mein öffentliches Wiki oder die öffentliche Website indiziere? Dann kriegen die zumindest noch raus, wer bei mir war und wer bei mir sucht vielleicht, je nachdem, wie es eben tatsächlich gebaut und angebunden ist. Aber wenn es darum geht, irgendwie Unternehmensintranetz zu indizieren, also spannende Fälle,

dann stellt sich die spannende Frage, warum ich mein Intranet eigentlich irgendwie absondere oder abschotte, wenn es dann irgendwie möglicherweise einen Crawler gibt oder irgendwie einen externen Service, der sowieso alles weiß. Muss man also wissen, ob man das eben einsetzen kann oder will? Ja, so sieht es eben auch aus.

Mitunter eben auch Schwierigkeiten mit der Lizenzauslastung. Und überhaupt stellt sich die Frage, wie kriege ich denn meine Sachen da überhaupt rein über irgendwelche Webschnittstellen und so weiter, ist auch nicht ganz so einfach. So, dann kann man es eben auch selbst machen. Und wir haben in der Vergangenheit zwei Out-of-the-Box-Lösungen getestet

und auch mal versucht, für Kunden einzusetzen, namentlich die beiden. Also die sind dann eben auch tatsächlich open source. Und in vielen Stellen haben wir aber festgestellt, dass die Anforderungen doch so individuell sind,

dass man irgendwie mehr machen muss, als die Lösungen aus der Packung hergeben. Wir wollen sie uns trotzdem anschauen, weil sie für viele Leute ein guter Einstieg sein können in eben sozusagen diese Welt und in Use-Cases, die jetzt nicht so ganz besondere Anforderungen haben,

möglicherweise eben auch reichen. Vorteil ist, ich kann das alles im Haus machen, offensichtlich. Keine Daten müssen nach draußen. Ich brauche aber irgendwen, der sich damit auskennt. Und mitunter ist das auch nicht ganz unaufwendig, je nachdem, welche Ansprüche man hat. Da gehe ich gleich auch noch im praktischen Teil darauf ein,

wo da eben möglicherweise eben Fallstricke lauern und vielleicht auch mit keinem Hinweis darauf, wie man mit 20 Prozent des Aufwands 80 Prozent des Ergebnisses erzielen kann. Klassischerweise bestehen diese Lösungen am Ende alle aus zwei mehr oder weniger open source Komponenten.

Die älteren, gerade auch die kommerziell angebotenen, oft noch auf Basis von Solar oder eben moderner auf Basis eben von Elasticsearch. Das sind eben Lösungen auf Basis von Apechelucine, also eine Lösung für Verarbeitung von strukturierten Daten.

Also grundsätzlich kann man sich das eben so vorstellen, dass am Ende dahinter eben eine Datenbank arbeitet, die gut mit strukturierten Daten, wie auch immer, eben umgehen kann, die Daten eben gezielt wiederfinden kann. Das Grundstück besteht eigentlich darin, wie bekomme ich denn jetzt irgendwelche Sachen,

die indiziert und dann nachher gesucht werden sollen, eben in diese strukturierte Form. Zwei Möglichkeiten gibt es, Daten reinzubekommen. Entweder die Anwendungen liefern von sich aus die Daten bei der Suchlösung an über entsprechende Schnittstellen

oder man nutzt einen Crawler, so ähnlich wie den Google Crawler, der eben irgendwie im Internet dann durchsuchen kann und eben URLs, also Ressourcen, die zur Indizierung anstehen, selbsttätig findet und dann eben in den Index aufnimmt.

Im Unternehmenskontext ist es zumindest häufiger so, dass man eben auch Drittsysteme anbinden möchte, wie beispielsweise E-Mail-Archive oder andere Sachen.

Also man hat eben nicht nur Webseiten, Datenbanken etc. Da gibt es dann typischerweise Plugins oder eben Ergänzungslösungen, für die irgendwie eine Brücke dahin bilden sollen. Genau. Zumindest für Elasticsearch gibt es auch unter dem Gesichtspunkt Anbindung von Drittsystemen, die sogenannte X-Pack.

Diejenigen, die vielleicht mit Elasticsearch schon mal gearbeitet haben, wissen, dass in den früheren Versionen

die Installation von diesen gängigen Add-ons, Extensions, Plugins, wie auch immer man sie nennen will, etwas hakelig war. Das ist jetzt eben in diesem X-Pack alles gut gebündelt und aufeinander abgestimmt, sodass es eben leicht installierbar ist. Allerdings ist das X-Pack auch nicht ganz unkritisch unter dem Gesichtspunkt.

Es sieht nämlich aus wie Open Source, ist aber nicht so richtig. Also für alle, die sich eben für Open Source im eigentlichen Sinne interessieren, Vorsicht mit dem X-Pack. Das gibt es nämlich auch lizenzpflichtig und das Gemeine ist, wenn man das X-Pack runterlädt, funktioniert erstmal alles

und 30 Tage nach der Installation hören wesentliche Komponenten auf. Das heißt, wer das also nur kurz testet, freut sich, dass eben ganz viel funktioniert und erlebt dann möglicherweise nachher in der Produktion Überraschungen, die man nicht haben möchte.

Dann hast du eine wunderschöne Umgehungslösung dafür gefunden. Die Frage war eben, wie geht X-Pack damit um, wenn man alle paar Tage neu installiert? Die Antwort ist eben, das ist eine super Lösung dafür. Die Frage ist, ob die für Production taugt.

QSI bietet Beratung, Hosting, Anpassung usw. in dem Kontext an. Und damit sind wir mit dem wundervollen Vortrag an der Stelle auch schon durch und wollen uns jetzt mal was in der Praxis anschauen.

Und zwar, wir haben, das ist eigentlich auch das, was ich, wenn man jetzt keine allzu komplexen Set-ups für den Einstieg durchaus eben empfehlen kann,

eine Fertiglösung, sprich FES, ausprobiert und mal geschaut, wie weit man damit kommt, ohne aufwändiges Customizing usw. Und wir haben auch auf der anderen Seite Open Search Server ausprobiert. Wenn ich die beiden abgrenzen soll, würde ich sagen, Open Search Server ist komplexer.

Kann viel genauer konfiguriert werden unter dem Gesichtspunkt eben beim Crawlen, welche Inhaltsbereiche, also welche HTML-Blöcke sind relevant, welche sind nicht relevant, ja, wie generiere ich daraus Zusammenfassungen usw. Das kann man viel toller konfigurieren.

Das muss man allerdings auch konfigurieren, sonst funktioniert es nicht und so richtig froh sind wir davon nicht geworden. FES erschien uns als Lösung, die man eben außer Packung sehr gut einsetzen kann, wenn man jetzt eben keine besonderen Ansprüche hat oder als leichtgewichtiger Einstieg in das Thema. Und ansonsten hat sich eigentlich gezeigt, sind die Ansprüche meistens so fortgeschritten,

dass man eben auf Basis von Elastic Search plus Integrationscode vielleicht doch besser eine auf die Projektanforderungen zugeschnittene Lösung mehr oder weniger selbst entwirft, ja, auf Basis eben von vorgefertigten Komponenten.

Also das wirkliche Einsatzszenario für den Open Search Server konnten wir so nicht ausmachen. Also für mal eben schnell zu kompliziert und für komplexe Projekte dann vielleicht irgendwie doch nicht mehr flexibel genug.

Der Kontext, bei dem ich eben den FES eben auf Basis von Elastic Search reine Open Source Lösung eben auf Java Basis vorstellen möchte, ist das Beispiel der Host Sharing EG, für die ich eben ansonsten auch noch tätig bin. Die Host Sharing EG ist ein genossenschaftlicher Web-Poster, so mit Community und so weiter.

Und wir haben den Wunsch gehabt seit langer Zeit irgendwie unsere verschiedenen Web-Anwendungen mal gemeinsam durchsuchbar zu machen. Also namentlich die Hauptwebsite, das Wiki, was wir zur Dokumentation einsetzen, die offizielle Dokumentation,

die eben auch auf einer Website eben tatsächlich steht und auch das Mailing-Listen-Archiv. Im Augenblick setzen wir da noch Mailman 2 ein und dachten, das ist doch irgendwie nett, wenn ich jetzt hier irgendwie nach irgendwas suche. Ich sag mal beispielsweise, wo wir gerade beim Thema sind.

Ich nehme mal E-Mail. Wir warten auf die Internetverbindung. Dann wäre es doch irgendwie sehr cool, wenn man jetzt übergreifend suchen könnte. Ja und hier gibt es jetzt eben tatsächlich Treffer aus den verschiedenen Datenquellen, die da eben gecrawlt werden.

Das Projekt, was wir da umgesetzt haben eben für die Host Sharing EG, hatte einen Umfang von eineinhalb Personentagen. Wobei wir viel Zeit damit verbracht haben, einen kleinen Bug im Open Search Server fest zu umkurven, der nämlich folgendermaßen lautet, es gibt bestimmte Robots TXT.

Also Robots TXT wird von dem Ding honoriert, aber in bestimmten Fällen, wenn bestimmte Direktiven drin sind, dann versteht er die falsch und indiziert nicht, obwohl er sollte. Und da haben wir, das war jetzt auch gerade das Beispielprojekt, an dem wir das das erste Mal versucht haben umzusetzen,

ziemlich dumm geguckt, warum da eben die Host Sharing Website, die zu dem Zeitpunkt auf Plon basiert, nicht indizieren wollte. Da stand in der Robots TXT irgendwie so was drin wie Send To und so weiter nicht indizieren. Und da ist da voll auf die Nase gefallen, hat dann eben einfach gar nichts indiziert. Das ging auch nicht so richtig schön aus den Logs hervor.

Wir konnten halt sehen, er geht drauf, er holt die Robots TXT, fertig. Und konnten das dann anfangs nicht richtig deuten. Also wie gesagt, mit Manipulationen an der Robots TXT haben wir das ganze Ding dann eben zum Laufen bekommen.

Wir waren am Fest nicht dran, wir haben die Robots TXT etwas angefasst bzw. angepasst. Ich weiß auch nicht, wir haben auch nicht richtig rausgekriegt eben welches Pattern es jetzt genau ist, was da eben tatsächlich stört.

Doch, doch, wir haben da ein Beispiel hingegeben. Also die Festentwickler, das ist meiner Ansicht nach, also nach meiner Einschätzung eher kleine Company. Da gibt es wenig Committer. Die waren zu dem Zeitpunkt allerdings auch schwer damit beschäftigt, eben fest auf

die neue Elastic Search Version irgendwie von 2.4 auf 5.2 zu heben. Wo sich eben auch einiges geändert hat und wir haben auf der anderen Seite aber das Projekt auch noch nicht auf die neue Festversion migriert. Insofern wissen wir jetzt auch nicht, ob sich da an der Stelle möglicherweise was getan hat.

Aber wenn ich jetzt eben beispielsweise Open Source Projekt bin und habe zum Beispiel eine Projektwebsite und ein Mailinglistenarchiv und vielleicht noch ein Wiki oder sowas, also irgendwie so ein Use Case so ähnlich wie hier, dann ist Fest ein wunderschönes Projekt. Ganz einfach aufzusetzen, also es ist einfach eine Java-Anwendung. Die wird im Wesentlichen ausgepackt, dann kann man die eben auf dem Server starten.

Die hat eine Web-Oberfläche, die zeige ich gleich. Dann kann man ein paar Einstellungen machen und dann läuft das Ding los. Und dann kann man eben tatsächlich mal die Informationen zusammenbringen und gemeinsam durchsuchbar machen. Was ich eben für sehr angenehm halte.

Das ganze Elastic Search ist Java. Theoretisch könnte man natürlich jetzt irgendwelche Frontends in beliebigen Sprachen davor bauen. Also sowohl der Open Search Server als auch der Fest sind aber Java-Lösungen.

Also der Einwurf war, man sollte das nicht in Java machen, sondern eben lieber Nativkoden. Also wir können versichern, dass die Bibliotheken, die drunter laufen, also Apache Lucene, für diesen Zweck schon ziemlich gut geeignet sind.

Und damit das eben Java Hotspot kompiliert wird seit längerer Zeit, ist das auch ziemlich schnell und ziemlich effizient. Was jetzt nicht heißt, dass man es nicht in C oder C++ möglicherweise schneller hinbekommen würde.

Das will ich jetzt an der Stelle gar nicht abstreiten. Allerdings für die Größenordnungen, die wir haben, also Intranets mit ein paar Hunderttausend Dokumenten oder teilweise auch mal mit ein paar Millionen URLs, gab es an der Stelle keine Engpässe. In der Konstellation, wie es jetzt hier ist, also in dem Beispielprojekt, hat das ganze Ding ein Gigabyte RAM zugewiesen für die Java VM.

Ja und läuft auf dem Server, also auf dem virtualisierten Server mit, der nebenbei auch noch die Websites ausliefert und die anderen Sachen da eben tatsächlich macht.

Das ist nicht so gefräßig, es ist eher beim Crawlen etwas CPU-lastig. Also wenn man eben sehr viele URLs hat und sagt, ich möchte sehr intensiv crawlen, dann wird es eben zu, ja dann wird das Crawlen CPU-lastig.

Der geht ja über die Seiten drüber und guckt vor allen Dingen erst mal nach dem Modifikationsdatum. Und was bei uns eben so ein bisschen pitfall ist da, das mit dem Modifikationsdatum, das passt bei den Mailing-Listen-Archiven vom Mailman nicht so richtig gut, weil der schreibt eben häufiger mal irgendwelche Sachen eben neu, also jetzt die uralten Archive nicht.

Und dann wird eben auch einigermaßen viel angeguckt, können wir aber gut mitleben. So, Admin-Oberfläche. Eigentlich hätte der sich das Passwort merken sollen.

Nee, leider nicht. Also wir haben die Admin-Oberfläche normalerweise auch

komplett wegkonfiguriert, also die wird von dem Reverse-Box gar nicht ausgeliefert. Wir haben sie jetzt mal freigegeben, damit man eben was sieht. Ach, das ist ja nett, das war doch drin.

So, also hier gibt es ein Dashboard. Theoretisch kann man an den Fest eben auch ein Cluster anschließen oder den Fest selbst clustern. Also mit ganz vielen Hosts, die eben crawlen und die Elasticsearch -Datenbank, sag ich mal eben als strukturierte Datenbank, eben grundsätzlich auch clustern.

Das ist nicht trivial, ein bestehendes oder neu installiertes Elasticsearch-Cluster an den Fest anzuschließen. Aber wie gesagt, also wir haben jetzt hier in dem Fall, wie ich gerade gesehen habe, auch 6 Millionen Dokumente drin. Kann man da eben sehen, also URLs, das läuft aber eben auf einer bescheidenen VM mal ebenso mit und tut da an der Stelle gar nicht weh.

Die spannende Konfiguration ist die Crawler-Konfiguration. Wir haben ja vier Website-Bestandteile, die wir ja crawlen wollen, eben die Hauptwebsite, das Wiki, Dokumentation und eben Mailing-Listen.

Für jeden haben wir eben so einen Crawler definiert, der hat bescheiden wenig Einstellmöglichkeiten. Also das verkaufe ich jetzt an der Stelle sozusagen als Feature von dem Fest. Man kann nicht viel einstellen, man muss auch nicht viel einstellen.

Was gibt man denn an, wo es losgehen soll? Ein Pattern für die URLs, die er crawlen soll. Dann könnte man theoretisch noch Ausschlusspattern angeben von irgendwelchen Dateinamen oder sonstigen Mustern, die er eben nicht crawlen soll. Abgesehen davon, dass Robots.txt, wenn es dann funktioniert, eben auch richtig interpretiert würde.

Man kann angeben, mit wie viel Threads parallel der Crawler crawlen soll, wie groß die Intervallzeit ist. Also wann ein Thread wieder einen Aufruf machen soll, weil wir wollen ja die zu crawlenden Websites auch nicht überfordern.

Sodass uns nachher die produktive Website in die Knie geht oder sowas, weil der Crawler da den meisten Traffic eben drauf verursacht. Das muss ja wohl dosiert sein. Man kann doch ein Boostlevel angeben, damit kann man eben, also im Prinzip, je crawler, dann die Suchergebnisse quasi wie in einem Topf. Und man kann die mit einem Boostlevel versehen, um sie zu priorisieren.

Wir sagen eben beispielsweise, naja, so ein Treffer E-Mail oder sowas von der Hauptwebsite ist wahrscheinlich spannender oder aus der Doku wahrscheinlich spannender als aus den Untiefen des Mailing-Listen-Archivs. Das ist so ein bisschen Hinting sozusagen für die Priorisierung.

So, dann wurde ich wieder ausgelockt. Auch nicht schlecht.

Müsste eigentlich noch drin sein, ja. Nee, ich glaube, der hat mich ausgelockt, weil irgendwie gerade ganz kurze Internetverbindung. Nee, nee, ich bin nur mit einem drin.

Also in der, nein, hier ist es. Also man kann hier noch den internen Scheduler konfigurieren und eben sagen, naja, wann soll der denn jetzt hier welche Crawler für machen und interne Reorganisationen. So ähnlich wie bei Cron. So sieht das eben an der Stelle aus.

Und unserer Ansicht nach ist das ein nettes Ding. Es könnte zusätzlich eben auch noch Dateisysteme durchsuchen und Datenbanken, um relativ schnell zu Ergebnissen zu kommen, die man auch tatsächlich brauchen kann. Also es gibt hier noch ein Dateisystem-Crawler und ein Datastore-Crawler.

Also für Databases ergibt man dann eben Datenbankzugriffsdaten an und formuliert sozusagen so ein Muster, wie eben also welche Datensätze aus welcher Tabelle genommen werden sollen und wie die eben in ein URL umgerechnet werden sollen, weil die Daten müssen ja auch irgendwie repräsentiert werden.

Benutzen wir aber jetzt an der Stelle gar nicht, sondern wir benutzen es eben nur, um den öffentlichen Teil der Websites und Nebenanwendungen eben durchsuchbar zu machen. Und wie gesagt, also wenn wir nicht den Wunsch gehabt hätten, noch das UI zu customisieren, etwas aufwendiger als nur Logo tauschen und nicht das Problem hätten mit der Robots TXT.

Deswegen seid gewarnt, dann ist das ein Projekt, das kann man im halben Tag ohne weiteres durchziehen. Völlig problemlos. So, genau. Was können wir nicht an der Stelle? Wir haben auch ein Mailing-Listen-Archiv, wo nur die Mitglieder der Genossenschaft, also eine interne Liste.

Wenn wir die jetzt durchsuchbar machen wollten, wäre es deutlich komplizierter. Ja, zum einen müssten wir natürlich ein Login-Mechanismus etablieren.

Man kann den Fest an LDAP anbinden. Wenn die User alle im LDAP sind, ist das überhaupt kein Problem. Dann müssen die sich zum Suchen anmelden, dann könnten sie eben auch interne Suchergebnisse sehen. Zum anderen müssten wir aber auch dem Crawler beibringen, wie er eben auf die eigentlich nicht zugänglichen Inhalte zugreifen kann.

Wenn das per HTTP Basic Auth irgendwie möglich ist oder irgendwelche anderen Tricks, dass man dem das freigibt, dann kann man das machen. Wer Mailman 2 kennt, weiß, dass Mailman 2 so ein bisschen komisch ist. Ja, da ist auch nichts mit LDAP. Und eine Abbildung zwischen Fest-Benutzern und Mailman-Benutzern, die ja eigentlich E-Mail-Adressen sind.

Und ein Zugriff für den Crawler auf das private Mailing-Listen-Archiv ist meiner Ansicht nach für Fest völlig out of scope. Das ist damit nicht hinzukriegen, jedenfalls nicht mit vertretbarem Aufwand.

Ja, und da sind wir dann eben auch tatsächlich bei den Begrenzungen. Wenn ich eben Sachen durchsuchen möchte, die ohnehin öffentlich sind oder ein Intranet durchsuchen möchte, wo alle zumindest Leseberechtigung haben. Oder mit HTTP Basic Auth zurechtkomme, dann kann man das einsetzen. Ansonsten stößt man da an Grenzen.

Genau. Und in der Realität eben von großen Firmeninternets ist es ja eigentlich noch viel komplizierter. Da gibt es eben sehr viele Dokumente mit Access-Control-Lists. Möglicherweise unterliegen die Dokumente Workflows und die Rechte ändern sich eben unterwegs.

Das ist für beide Systeme nichts. Also weder für den Fest noch für den Open-Search-Server. Und dann ist eben nicht unwesentlicher Integrationsaufwand nötig. Und es ist dann eben Customizing, was sehr vom individuellen Fall abhängt.

Und dann geht es eben um große Projekte, die eben viele Wochen oder gegebenenfalls Monate in Anspruch nehmen. Für so Open-Source-Projekte, wo im Prinzip die Informationen im Wesentlichen öffentlich sind oder man vielleicht noch einen Projektmitgliederbereich hat, kann man es aber super außer Packung einsetzen.

Ja, soweit die Berichte aus der Praxis. Und jetzt will ich eigentlich gerne zum Frage-Antwort-Teil übergehen oder eben vielleicht auch mal kurz Sachen hören zur Erfahrung, die ihr gemacht habt. Bitte.

Und das hat eigentlich ganz gut funktioniert, muss ich sagen. Das hat auch diese Feature gehabt, da kannst du mit externen Tools, sondern auch

mit Word-Tatel und KDS und sonst wie alles dann zu Text-Tatel konvertieren. Und das konnte er dann injizieren und man konnte dann einstellen, das ist auch so ein Fazit-Search. Und sonst was macht das auch nicht in Java-Geschrieben. Das ist in richtigen C-Geschrieben. Das hat damals auf dem Pension 2 sehr gut performt. Und es konnte mal einen ganzen E-Book-Bestand injizieren.

Und das hat auch rasend schnell gearbeitet. Das war auch wirklich so ein aufgepasstes Java-Kram. Genau, also der Hinweis heißt, also HT-Dig gibt es. Das hat eben auch viele Filter. Oder man kann Filter eben anbinden. Und das kann eben auch Fazit-Search. Ja, das macht das hier auch. Und es ist eben in C-Geschrieben und läuft deswegen auch auf dem Pension 2.

Bitte. Weißt du, welchen Code der Festleute einsetzt? Ja, einen eigenen. Der heißt Riverweb. Und gehört. Also die Festlösung besteht. Also Frage war, welcher Crawler wird hier eingesetzt?

Also das Festsystem selbst besteht aus ganz vielen Einzelkomponenten. Beispielsweise eben diesem Riverweb-Crawler. Und dem Indexer. Und diversen anderen Komponenten. Und eben auch dem Webfrontend. Die gibt es eben alle einzeln bei GitHub.

Und dann muss man eben zusehen, wie man sie integriert. Oder es geht eben fest als Komplettlösung. Also zu dem Thema, wie man sie integriert. Wir haben versucht aus dem Komplettprodukt abzuleiten, wie man sie integriert. Wenn man nämlich Einzelkomponenten vielleicht austauschen möchte. Das ist uns nicht so richtig gut gelungen.

Ja, also ich habe selbst in einem Kontext mal irgendwie drei Tage darin versenkt fest, obwohl es theoretisch ansatzweise dokumentiert ist, mal ein bestehendes Elasticsearch-Cluster anzubinden. Und es ist mir nicht so richtig gelungen. Was mich mal interessiert, wäre so ein Suchansatz, der umdiskaliert.

Also ein weniger Anwendungsfall ist der. Ich habe eine kleine Bude, die Spezial-Geheim-O-Technologie entwickelt. Und die Leute sollen nicht wissen, was ich suche. Das heißt, wenn ich jetzt bei Google oder Draco oder sonst wo suche, dann wissen die, diese komische Bude, die sucht immer nach irgendwelchen Fluglagerregelungen und sonst was ist suspect. Wenn ich jetzt also dann habe ich lieber diese Suchmaschine bei mir.

Und habe sozusagen eine Privat-Suchmaschine. Und ich möchte nicht jetzt einen Scrawler laufen lassen, sondern ich habe vielleicht 50 andere Bude, die auch so spezielle Bedürfnisse haben, die selber auch wieder eine Suchmaschine haben. Und ich möchte, dass diese Suchmaschinen sich miteinander die Daten abgleichen. Das heißt, ich scrawle das Netz, ganz viele Leute scrawlen das Netz, tauschen diese Daten untereinander aus,

sodass ich nicht dabei infizieren muss, sondern das andere mir das schön immer, dass es immer gesünd wird, dass es so positiver wird von indizierten Webseiten, sodass sich alle die Arbeit sparen können. Okay, also die Frage zielt in die Richtung ab, wenn ich es richtig verstanden habe, ob man nicht gemeinsam ein Netz von Suchinstanzen aufbauen kann,

die dann eben für sich scrawlen und irgendwie die Inhalte abgleichen oder zusammenbringen etc. Kann man bauen, ja, also eben auch beispielsweise auf Basis von Elasticsearch oder eben auch Apache Lucene, wenn man es eben noch eine Ebene drunter gehen möchte.

Grundsätzlich würde eben auch FES, ist nach Dokumentation clusterfähig und man könnte, wenn man sich eben gegenseitig vertraut, eben natürlich auch aus mehrere, also mit mehreren Leuten eine Suchgemeinschaft machen und damit eben einen gemeinsamen Festcluster betreiben, stelle ich mir eben nach unseren Erfahrungen allerdings nicht trivial vor.

Nächste Frage ist... Community Web-Suchmaschine namens Yassi. Also Einwurf ist, es gibt eine Community-basierte Suchmaschine namens Yassi,

die ich allerdings auch nicht kenne, man sich aber sicherlich mal anschauen sollte.

Genau, also hier gab es gerade einen Erfahrungsbericht eben zu Yassi, der in die Richtung ging, irgendwie nach einer gewissen Zeit geht schon mal der Index kaputt. Stabilität ist sozusagen fraglich, kann ich allerdings selbst auch Mangelskenntnis nicht bewerten. Bitte.

Die Frage ist eben, wie sieht es mit Alternativformaten aus?

Da sieht es beim Open-Search-Server besser aus. Der hat ein paar mehr Filter dabei und eben bessere Schnittstellen, um Filter zu integrieren. Also FES wäre mehr jetzt nur für Webseiten und zwar statische Webseiten in der Form, der wältet eben auch kein JavaScript aus.

Direkt noch die Nachfrage dazu. Ja, also ich habe das jetzt aufgefasst als Rückfrage zu meiner Antwort. Ja, genau, also Harttidic hat auch Filter für PDF.

Bitte.

Also die Frage war, wenn ich schon irgendwie Datenquellen habe,

die möglicherweise auch Suchdaten vorab aufbereitet oder teilweise aufbereitet haben, wie kann ich die anbinden? Ich möchte die Frage verallgemeinern. Ich habe irgendwelche Datenquellen, irgendwelche Bauart und möchte sie gerne anbinden. Der FES ist an der Stelle so modular, dass man eben auch weitere Plugins dazuschreiben kann.

Also wir haben ja jetzt in der Standardinstallation eben das Plugin gesehen für Web, für Datenbanken und eben für Datalsysteme. Auf Basis eben derselben Schnittstelle kann man natürlich eben auch beliebige andere Systeme einbinden. Entscheidend ist für den FES, die Suchergebnisrepräsentation ist natürlich irgendwie ein webbasierter URL mit irgendwie,

ja, also eigentlich will man ja am Ende einen Link irgendwie auf ein Zielobjekt haben, was man sich angucken kann. Die Verbindung muss man eben sozusagen herstellen und eben die Daten, die in den Index fließen sollen, strukturiert aufbereitet haben. Da kann man aber eben in die Beispiel Plugins gucken, dass es jetzt kein großes Geheimnis ist.

Genau, also Hinweis war eben, wenn man Solar als Zwischenstatus hat sozusagen,

wir indizieren irgendwas nach Solar und würden es dann eigentlich gerne weiter nochmal indizieren von irgendeiner davor geschalteten Suchmaschinerie, dann ist eben der Hinweis, die Daten sind in Solar in einer Form abgelegt, dass man eben jetzt nicht die Originaldaten zur Verfügung hat,

sondern eben gucken muss, ob man da überhaupt was mit anfangen kann. Bitte. Ja, haben wir. Also Frage war, wie sieht das mit den Benutzerrechten aus?

Also wenn ich jetzt eben irgendwas indizieren und dann eben durchsuchbar machen möchte, wo eben komplexe Situationen sind eben mit ACLs oder ähnlichem,

also komplexe Benutzerzugriffsrechte, ja, haben wir gemacht. Es gibt grundsätzlich mehrere Möglichkeiten, das Problem anzugehen. Also zum einen kann man eben versuchen, auf Basis von der Suchlösung irgendwie dieses ACL-System eben mit abzubilden

oder eben umgekehrt die ACL-Informationen des Datenobjekts eben mit in den Index zu schreiben und dann eben auszuwerten an der Stelle, wenn man eben den Index liest. Also das haben wir beides gemacht. Damit die Sicherheitsinformationen dann auch aktuell sind,

haben wir in den Fällen dann oft auch einen Filter geschrieben, der sozusagen die Suchergebnisse dann nochmal nachgefiltert hat, also dann beim scharfen System nochmal nachgefragt hat, ob eben der URL jetzt eigentlich für die Person überhaupt noch zugreifbar ist. Denn wenn man eine Crawling-Lösung nimmt, sind die Informationen ja möglicherweise veraltet

und eben auch die Informationen über die Zugriffsrechte möglicherweise veraltet. Also wenn ich beispielsweise gerade mich vom Mitarbeiter getrennt habe, der dann irgendwie was nicht mehr sehen soll oder sehen darf oder irgendwie sowas, dann hätte ich das ja auch gerne jetzt und sofort und nicht dann, wenn der Index aktualisiert ist. Die Metadaten oder die Dateien?

Moment, einer nach dem anderen. Die Frage, bitte? Ob ihr die Dateien versteckt habt oder auch die Metadaten? Also wir haben in der Implementierung die Suchergebnisse nachgefiltert.

Das heißt eben, die Sachen, die nicht zu sehen waren, sind dann auch nicht in der Zusammenfassung angezeigt worden. Bitte.

Also die Frage ist, wenn ich ein Push-Verfahren einsetze, dann kann ich dann auch die Suchergebnisse nachgefiltert haben. Dann kann ich mir das nachfiltern wahrscheinlich sparen, weil die Informationen dann ohnehin aktuell sind.

Antwort dazu ist richtig. Ja, also wenn ich das sicherstellen kann, dass das Push-Verfahren zuverlässig funktioniert und die Suchlösung auch dann verfügbar ist in jedem Fall, wenn sich irgendwie die Zugriffsrechte ändern und das System, wo die Daten drin sind, das mitkriegt, dass sich die Zugriffsrechte ändern

und dann eben die Push-Notification kommt, dann kann man sich das Ganze natürlich sparen. Aber Vorsicht, wenn ich eine typische Konstellation habe, beispielsweise, ich habe ein LDAP und am Ende hängt es dann eben an LDAP-Gruppenmitgliedschaften und so weiter,

dann stellt sich eben die Frage, ob ich sag mal, mein Content-Management-System das aktiv mitbekommt, wenn irgendjemand außer LDAP-Gruppe fliegt und dann eben für alle Dokumente, die das betrifft, dann eben tatsächlich den Push-Richtung-Suchsystem auslösen kann. Wenn das gesichert wäre, dann sehe ich da keine Schwierigkeiten.

In der Praxis konnten wir das allerdings dann nicht sichern aufgrund von Bestenkungen der Systeme, die die Daten bereitstellen, sodass wir dann eben den Weg genommen haben, wo wir eben an die Systeme, die eben für Authentifizierung, Autorisierung zuständig sind, dann eben nachgefragt haben, ob der URL quasi noch gültig ist,

sprich der Benutzer, der eingeloggt ist bei der Suchlösung, eben noch View-Berechtigung auf dem Objekt hat. Bitte. Beim Fest nicht, beim Open-Search-Server ja, also Frage ist, pushen, geht das oder nicht?

Beim Fest nein, beim Open-Search-Server ja. Bei den Lösungen, die wir auf Elasticsearch-Basis gebaut haben, typischerweise auch, oder mit denen wir Kontakt hatten, also eine Lösung, die eben in die Richtung geht

und das vielleicht eben da gerade auch erklärt ist, wer kennt Plone? Okay, wenige ist halt eben so eine CMS-intranet-wie-auch-immer-Lösung. Da gibt es eben einen Adapter für Elasticsearch und der arbeitet eben auf Push-Basis,

also sprich die Anwendung fängt eben Änderungsevents ab auf Basis eben der einzelnen Datenobjekte, die eben drin sind und schickt dann eben eine Benachrichtigung an die Elasticsearch-Instanz.

Der Frage Open-Search-Server benutzt auch Elasticsearch. Apache Manifold sollte eigentlich auch mit Elasticsearch arbeiten?

Also Apache Manifold habe ich selbst noch keine Berührung mit gehabt. Also es hat Projekte gegeben, die eben hier in dem Unternehmen auch umgesetzt worden sind. Soweit ich weiß, haben wir alle Projekte in den vergangenen zwei, drei Jahren mit Elasticsearch umgesetzt

und da war auch Apache Manifold im Einsatz. Aber kann ich jetzt nicht mit hundertprozentiger Sicherheit sagen, eben mangels eigener Erfahrung. Also bin ich mir nicht ganz sicher.

Die Frage ist eben, wie komme ich an die Suchergebnisse dran? Also beide Suchlösungen, sowohl der Open-Search-Server als auch der Fest, bieten eben APIs an,

kommen aber auch mit einer integrierten Web-Oberfläche, wo die Sachen dann eben als HTML gerendert werden. Die Frage ist eben, ob man die Oberfläche mag oder nicht lieber irgendwie anderweitig in seine eigene Oberfläche integrieren möchte oder wie auch immer möglicherweise hat man ja auch andere abhängige Systeme, die einfach nur auf die Daten zugreifen können sollen.

Die sind also in der Form modular, also die haben eben entsprechende Schnittstellen.

Bitte. Die Frage ist, außer Lucin gibt es nichts. Also hier ist die Antwort, H.T. Dick.

Gut, wenn keine weiteren Fragen sind, dann bedanke ich mich fürs Zuhören und wünsche euch noch eine wunderschöne und interessante Rest-Frostkon.

Ich glaube, eine Session passt heute noch ins Programm.