Fess: Enterprise-Suche auf OpenSearch, die ohne Suchmaschinen-Vorwissen auskommt

Welches Problem Fess löst und für wen es gebaut ist

In vielen Organisationen liegen die relevanten Dokumente nicht an einem Ort. Sie stecken in Websites, in Dateisystemen, in Datenbanken, in CSV-Exporten und in SaaS-Anwendungen. Eine Suche, die nur einen dieser Orte abdeckt, erzeugt Trefferlisten, denen die Nutzer nicht vertrauen. Fess setzt genau dort an: Es bringt einen Crawler mit, der Webseiten, Dateisysteme und Datenquellen einsammelt, und stellt darüber eine einheitliche Suchoberfläche bereit. Die Zielgruppe sind Betreiber, die eine Suche im eigenen Netz betreiben wollen, statt sie an einen Cloud-Anbieter abzugeben.

Bemerkenswert ist die Zielsetzung beim Bedienpersonal. Das README formuliert es so, dass Vorkenntnisse zu OpenSearch nicht nötig seien, weil Fess über eine browserbasierte Administrationsoberfläche konfiguriert wird. Das ist die eigentliche Positionierung: nicht die Suchqualität allein, sondern der Verzicht auf direkte Indexverwaltung. Wer schon einmal Mapping-Konflikte und Analyzer-Ketten von Hand gepflegt hat, erkennt den Reiz. Wer diese Kontrolle behalten will, erkennt gleichzeitig die Grenze.

Crawler, Konfigurationsseiten und Scheduler: der tatsächliche Ablauf

Der Datenfluss ist im README in wenigen Schritten beschrieben. Zuerst werden die Ziele auf den Konfigurationsseiten für Web, File oder Data Store im Admin-Bereich registriert. Danach wird der Crawler von der Scheduler-Seite aus gestartet. Der Crawler holt die Dokumente, Fess legt sie in OpenSearch ab, und die Suchoberfläche unter http://localhost:8080/ liest daraus. Die Admin-Oberfläche liegt unter http://localhost:8080/admin/, das Standardkonto ist admin/admin. Dieses Standardpasswort ist der erste Punkt, der in jedem erreichbaren Deployment geändert werden muss.

Für die Datenquellen gibt es getrennte Connector-Repositories, die das README auflistet: Confluence/Jira, Box, CSV, Datenbank, Dropbox, Elasticsearch, Git, Gitbucket, G Suite, JSON, Office 365, S3, Salesforce, SharePoint und Slack. Das ist eine breite Abdeckung, aber sie ist nicht im Hauptprojekt enthalten, sondern liegt in separaten Repositories wie fess-ds-s3 oder fess-ds-sharepoint. Wer eine Quelle anbindet, pflegt damit ein weiteres Artefakt. Bei Dateiformaten nennt das README Microsoft Office, PDF und ZIP-Archive.

Erweiterbarkeit läuft über vier Plugin-Kategorien: Data Store, Ingest, Script und Theme. Für Ingest existieren Logger und NDJSON, für Script Groovy und OGNL, für Themes die Sammlung fess-themes, deren Einträge laut README jeweils als eigenständige Single-Page-App per ZIP-Upload im Admin-Bereich installiert werden. Das ist ein sauberer Schnitt: Themes sind austauschbar, ohne den Kern anzufassen.

Installation: ZIP, Docker oder Paket

Das README zeigt den ZIP-Weg mit drei Befehlen: unzip fess-<version>.zip, dann cd fess-<version>, dann ./bin/fess. Für RPM und DEB gibt es eigene Pakete. Voraussetzung für ZIP, RPM und DEB ist Java 21 oder neuer. OpenSearch ist nicht enthalten, sondern muss separat betrieben werden; nur die Docker-Images bringen es laut README mit. Die Compose-Datei liegt im Repository docker-fess unter compose/.

Für Entwicklungsarbeit ist der Ablauf ebenfalls dokumentiert. Nach dem Klonen wird das Projekt als Maven-Projekt importiert. Die OpenSearch-Plugins kommen über mvn antrun:run in das plugins-Verzeichnis. Starten lässt sich Fess dann über die Klasse org.codelibs.fess.FessBoot in der IDE. Pakete entstehen über mvn package mit Ausgabe nach target/releases, dazu mvn rpm:rpm und mvn jdeb:jdeb. Die Quellgenerierung nutzt mvn dbflute:download einmalig, danach mvn dbflute:freegen und mvn license:format.

Für Integrationstests nennt das README konkrete Parameter: mvn test -P integrationTests -Dtest.fess.url="http://localhost:8080" -Dtest.search_engine.url="http://localhost:9201". Vorher muss der Server laufen, und die Bereitschaft lässt sich über curl -s "http://localhost:8080/api/v1/health" prüfen. Das README weist darauf hin, dass der Start bis zu 60 Sekunden dauern kann. Zusätzlich werden Testdaten aus dem Repository fess-testdata benötigt, weil SearchApiTests darauf zugreift. Diese Abhängigkeit von externen Testdaten ist ein Detail, das in CI-Umgebungen gern übersehen wird.

Suche, Rechte und Anmeldung

Die Funktionsliste nennt Volltextsuche mit Facettierung, Sortierung und Suchvorschlägen sowie rollen- und berechtigungsbasierte Filterung der Ergebnisse. Das ist für Unternehmenssuche kein Beiwerk: Sobald Dokumente aus SharePoint oder Confluence indexiert werden, muss die Trefferliste dieselben Zugriffsgrenzen respektieren wie die Quelle. Wie Fess diese Filterung intern durchsetzt, geht aus dem vorliegenden Material nicht hervor. Wer das braucht, muss die Dokumentation zur Berechtigungskonfiguration heranziehen, bevor er produktiv geht.

Bei der Anmeldung nennt das README LDAP, OpenID Connect, SAML, SPNEGO und Microsoft Entra ID. Auch hier gilt: Die Liste belegt die vorhandenen Anschlüsse, nicht deren Verhalten in einer bestimmten IdP-Konfiguration. Die mehrsprachige Oberfläche und Textanalyse deckt laut README über 20 Sprachen ab. Ob die eigene Sprache darunter ist und wie gut die Analyse greift, lässt sich nur im eigenen Korpus beurteilen.

Die REST API ist Teil der Funktionsliste, und der Health-Endpunkt ist im Testabschnitt konkret belegt. Für automatisierte Prüfungen in einem Deployment ist das der brauchbarste Anker, den das Material liefert.

Wo Fess die falsche Wahl ist

Der offensichtlichste Fall ist ein Team ohne OpenSearch-Betrieb. Fess selbst ist Java, aber der Index lebt in OpenSearch. Bei ZIP-, RPM- und DEB-Installationen muss OpenSearch separat aufgesetzt, versioniert und gesichert werden. Nur die Docker-Images nehmen einem das ab. Wer diese Betriebslast nicht will, sollte nicht mit Fess beginnen.

Der zweite Fall betrifft das Berechtigungsmodell. Sobald Suchergebnisse aus Quellen mit eigenen Zugriffsregeln stammen, wird die Frage, wie Fess diese Regeln abbildet, zur zentralen Frage. Das vorliegende README nennt die Filterung als Feature, beschreibt aber nicht, wie die Zuordnung zwischen Quellberechtigung und Suchberechtigung gepflegt wird. Wer hier ohne Prüfung ausrollt, riskiert Treffer, die Nutzer sehen dürfen, obwohl sie das Dokument nicht öffnen dürften.

Drittens die Connector-Abhängigkeit. Die Datenquellen liegen in separaten Repositories. Eine Quelle, die dort nicht auftaucht, bedeutet eigene Entwicklungsarbeit gegen die Plugin-Schnittstelle. Das ist machbar, aber es ist ein anderes Vorhaben als das Aufsetzen eines Suchservers.

Schließlich die Testinfrastruktur. Integrationstests brauchen einen laufenden Server, einen erreichbaren Suchmaschinen-Endpunkt und geklonte Testdaten. In einer Umgebung ohne diese Bestandteile lässt sich der Testpfad nicht nachvollziehen.

Alternative: Fess Site Search statt des vollen Servers

Das README verweist auf Fess Site Search als kostenlose Alternative zu Google Site Search, die sich in eine eigene Website einbetten lässt, mit einem Generator unter fss-generator.codelibs.org. Der Unterschied liegt nicht in der Suchtechnik, sondern im Zuschnitt. Der volle Fess-Server indexiert viele Quellen und verwaltet sie über die Admin-Oberfläche. Fess Site Search ist auf die Suche innerhalb einer Website zugeschnitten und wird über einen Generator eingebunden. Wer nur die eigene Seite durchsuchbar machen will, trägt beim vollen Server Crawler-Konfiguration, Scheduler und OpenSearch-Betrieb mit, ohne den Nutzen daraus zu ziehen.

Eine zweite Abgrenzung ergibt sich aus der Datenquellenliste selbst: Fess kann Elasticsearch als Datenquelle crawlen, was den Fall abdeckt, dass bereits ein Index existiert und nur die Suche darüber fehlt. Der umgekehrte Weg, Fess als reinen Index ohne Crawler zu betreiben, ist im Material nicht beschrieben. Wer das vorhat, muss die Dokumentation prüfen.

Wartung, Release-Takt und Lizenz

Die letzten drei Releases im Material sind fess-15.8.0 vom 20. August 2026, fess-15.7.0 vom 25. Juni 2026 und fess-15.6.1 vom 2. Mai 2026. Der Abstand zwischen 15.6.1 und 15.7.0 beträgt knapp zwei Monate, zwischen 15.7.0 und 15.8.0 ebenfalls knapp zwei Monate. Das deutet auf einen regelmäßigen Minor-Takt, aus dem sich ein Upgrade-Fenster ableiten lässt. Ob Minor-Versionen Index-Migrationen erfordern, sagt das Material nicht. Das ist die wichtigste offene Frage für den Betrieb, denn eine Indexmigration bestimmt, ob ein Upgrade ein Wartungsfenster oder einen Neuaufbau bedeutet.

Die Kosten liegen weniger im Kern als in der Umgebung: OpenSearch-Version, Java-21-Laufzeit und die separat gepflegten Connector-Repositories müssen zusammenpassen. Jeder zusätzliche Connector ist ein weiteres Artefakt mit eigenem Stand. Wer fünf Quellen anbindet, pflegt fünf zusätzliche Abhängigkeiten.

Lizenziert ist Fess unter Apache-2.0. Das erlaubt kommerzielle Nutzung und Modifikation unter den Bedingungen dieser Lizenz, üblicherweise inklusive Beibehaltung von Copyright- und Lizenzhinweisen. Für die separaten Connector-Repositories und die Theme-Sammlung ist die Lizenz im vorliegenden Material nicht genannt; sie muss pro Repository geprüft werden. Das ist keine Rechtsberatung, sondern ein Hinweis auf die Stellen, an denen vor einer Auslieferung nachgesehen werden sollte.

Redaktionelles Fazit

Fess passt zu Teams, die eine eigene Suche über heterogene Quellen brauchen und Java 21 sowie einen OpenSearch-Betrieb akzeptieren. Wer eine reine Website-Suche ohne Crawler-Betrieb will, sollte zuerst die Fess-Site-Search-Variante prüfen, und wer kein OpenSearch betreiben möchte, ist hier falsch. Vor der Einführung zu klären: die in der Installationsanleitung genannte unterstützte OpenSearch-Version, ob die benötigte Datenquelle als Connector-Repository existiert, und ob die Authentifizierung über LDAP, SAML oder Entra ID im eigenen IdP getestet wurde.

Offizielle Quellen

1. codelibs/fess on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases