Metasuchmaschine SearXNG mit docker-compose und nginx

Die Frage nach dem wichtigsten Tool im Internet werden sicher viele mit „Google“ beantworten – schließlich muss man nicht alles wissen, da man ja „googeln“ kann. Der US-Konzern betreibt mittlerweile sehr viele Dienste und kennt seine User besser, als den meisten recht sein dürfte: Welche Videos man auf Youtube sieht, welche Apps man auf dem Android-Smartphone nutzt, welche Smart-Home-Komponenten zum Einsatz kommen, welche Strecken man mit dem Navi fährt – um hier nur mal eine kleine Auswahl zu nennen. Für viele dieser Dinge gibt es allerdings freie und quelloffene Alternativen. Wenn es um Datenschutz und Privatsphäre bei der Internet-Recherche geht, lohnt ein Blick auf alternative Suchmaschinen (z.B. Startpage).

Es ist jedoch auch mit einfachen Mitteln möglich, mit SearXNG eine (Meta-)Suchmaschine auf einem eigenen Server zu betreiben. Mit SearXNG sollte die Qualität der Suchergebnisse vergleichbar mit anderen Suchmaschinen sein, allerdings liegt hier der Fokus auf Datenschutz und Privatsphäre. Der folgende Artikel zeigt dazu das genaue Vorgehen, um SearXNG mit Docker (genauer gesagt docker-compose) und nginx auf einem eigenen Server zu installieren.

Wer mal einen Blick auf SearXNG werden möchte, kann dazu eine beliebige Instanz ausprobieren (siehe Liste der öffentlichen SearXNG- und searx-Instanzen).
Mit search.decatec.de habe ich ebenfalls eine öffentlich zugängliche Instanz bereitgestellt (Standard-Einstellungen, kein Logging). Meine Instanz ist im Grunde genommen genauso installiert, wie hier im Blog beschrieben, damit ihr euch einen Eindruck von dieser Metasuchmachine machen könnt.

Suchmaschinen vs. Metasuchmaschinen

Was ist nun genau eine Metasuchmaschine?
Hinter jeder „klassischer“ Suchmaschine (wie z.B. Google oder auch Bing) steht meist ein Unternehmen, welches einen eigenen Suchindex aufbaut und verwaltet. Hier gibt es mittlerweile gar nicht mehr so viele Anbieter, denn für das Betreiben einer solchen Suchmaschine sind große Rechenkapazitäten erforderlich. Warum betreiben Unternehmen denn genau diesen Aufwand? Ganz einfach: Wenn man „mitlesen“ kann, nach was die Internet-User suchen, lassen sich ganz einfach User-Profile anlegen. Wenn ihr das nächste Mal „googelt“, dann schaut mal nach, ob ihr bei Google angemeldet seid. Ja? Dann weiß Google genau, nach was ihr gesucht habt. Mit diesem Wissen kann ein Unternehmen dann sehr effizient Werbeanzeigen schalten. Und damit kann dann eine Menge Geld gemacht werden.

Daneben gibt es noch die sog. Metasuchmaschinen: Anstatt einen eigenen Suchindex aufzubauen, leiten diese Suchmaschinen die Anfragen einfach an andere Suchmaschinen weiter und generieren ihre Ergebnisse auf diese Art und Weise. Das bereits erwähnte Startpage ist hier ein recht bekannter Vertreter dieser Art von Suchmaschine (trotzdem eher problematisch, da auch hier ein Unternehmen hinter dieser Suchmaschine steht).
Die Daten (also die Begriffe nach dem die Benutzer suchen) können dadurch anonymisiert werden. Die Anfrage an z.B. Google erfolgt dann ja über die Metasuchmaschine, nicht mehr über einen (bei Google) angemeldeten Benutzer. Google sollte dann (in der Theorie) eine Suchanfrage nicht mehr einer individuellen Person zuordnen können.

Mit SearXNG gibt es nun eine Metasuchmaschine, die jedermann auf einem eigenen Server betrieben kann. Was dann geloggt wird und was über die einzelnen User bekannt ist, das ist Sache des Betreibers der SearXNG-Instanz.

SearXNG vs. searx

Der Artikel kommt euch bisher irgendwie bekannt vor? Einen ähnlichen Artikel gab es in der Tat schon mal hier. Die Suchmaschine hieß hier aber noch searx.

SearXNG ist (wie der Name bereits vermuten lässt) ein Fork von searx. Hintergrund war wohl, dass sich die (Haupt-)Entwickler nicht ganz einig waren, in welche Richtung sich das Projekt weiterentwickeln soll. Dank Open Source ist es in einem solchen Fall dann ganz üblich, dass ein Projekt geforked wird, damit die Entwickler ihre jeweils eigene Vision des Projekts umsetzen können.

Die Haupt-Unterschiede von SearXNG sind dabei:

• Überarbeitung der Benutzeroberfläche.
• Viele Neuerungen bei den Einstellungen.
• Eine neue Übersichtsseite, welche Statistiken zu den verwendeten Suchmaschinen ausgibt.
• Vereinfachung der Installation der Metasuchmaschine.
• Rolling Releases, schnellere Entwicklung.

Weitere Unterschiede sind im entsprechenden GitHub-Repository zu finden.

Vor ca. 3 Jahren hatte ich mich damals mit searx beschäftigt und auch eine öffentliche Instanz der Metasuchmaschine betrieben. Allerdings gab es hier nach einiger Zeit Probleme (v.a. mit der Zuverlässigkeit: viele „Backend-Suchmaschinen“ lieferten keine Ergebnisse mehr). Das Projekt habe ich dann über die Zeit aus den Augen verloren.
Als ich von SearXNG gehört habe, fand ich den Ansatz nicht schlecht, so dass ich nochmal einen neuen Versuch mit diesem Fork unternehme.

Voraussetzungen und Installationsvarianten

Der Artikel basiert wie immer auf Ubuntu Server 22.04 LTS. Jedoch sollten die gezeigten Schritte auch auf anderen Distributionen umsetzbar sein.

Beim Thema Hardware lässt sich bei SearXNG leider keine konkrete Empfehlung geben, da dies auch immer von den Nutzer-Zahlen abhängt. Empfehlenswert ist hier ein Root- oder vServer beim bevorzugen Server-Anbieter, z.B. Netcup (Affiliate-Link).

Die eigene Suchmaschine soll später über eine eigene (Sub-)Domain erreichbar sein. Diese muss zuvor natürlich beim Domain-Provider angelegt bzw. bestellt werden. Diese Domain muss dann auf die jeweilige Maschine verweisen (A- bzw. AAAA-Record bei einem Root-Server/vServer oder per CNAME-Eintrag bei DynDNS).
Im Rahmen des Artikels gehe ich von der beispielhaften Domain searxng.meinedomain.de aus.

Die Installation kann prinzipiell auf drei verschiedene Arten durchgeführt werden:

• Per Docker-Container (mit Dockerfile oder docker-compose).
• Installations-Skript.
• Installation „by Source“.

Da die Installation mittels Docker am einfachsten ist, habe ich mich für diese Variante entschieden. Dabei nutze ich docker-compose, denn dies ist die empfohlene Variante mit sinnvollen Standard-Einstellungen.

Mit docker-compose werden dabei drei Container installiert:

• SearXNG
• Redis (In-Memory-Datenbank)
• caddy (Webserver)

Das in diesem Artikel gezeigte Vorgehen unterscheidet sich allerdings in einem wichtigen Punkt von der Standard-Installation: Normalerweise kommt hier der Webserver caddy per Docker-Container zum Einsatz. Bei korrekter Konfiguration übernimmt dieser Container auch gleich die automatische Generierung der TLS-Zertifikate. Ich gehe allerdings davon aus, dass auf dem Docker-Host bereits ein Webserver (nginx) installiert ist, der für die SSL-Terminierung übernehmen soll. Daher wird der caddy-Container in meinem Setup nicht benötigt.
Hintergrund ist, dass auf einem Root-Server meistens mehrere Webanwendungen installiert sind, ein Dienst wie SearXNG ist dabei nur ein Dienst von vielen. Das Standard-Setup mittels caddy-Container setzt allerdings voraus, dass kein anderer Webserver auf dem Docker-Host läuft. In der Praxis wird dies vermutlich eher selten der Fall sein.
Die Konfiguration von nginx lehnt sich dabei an jene an, die hier im Blog immer verwendet wird.

nginx soll im hier gezeigten Setup RSA- und ECDSA-Zertifikate im Hybrid-Betrieb nutzen. Für die Generierung der Zertifikate wird acme.sh als Let’s Encrypt Client verwendet. Ich gehe im Folgenden davon aus, dass acme.sh auf dem System bereits installiert und konfiguriert ist. Falls noch nicht geschehen, ist dies im Artikel RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) detailliert beschrieben.

Hinweis: Wer wirklich nur SearXNG auf einem Server betreiben möchte und das mit möglichst geringem Aufwand, der kann auch einfach caddy als Webserver verwenden, wie es die Standard-Variante von SearXNG/docker-compose vorsieht. In diesem Fall können dann im Folgenden alle Anweisungen weggelassen werden, die nginx betreffen. Die Zertifikate werden automatisch von caddy beim ersten Start generiert.

Installation Docker und docker-compose

Bevor es mit der Installation losgehen kann, bringen wir das System erst einmal auf den neusten Stand:

apt update && apt upgrade -V && apt dist-upgrade && apt autoremove

Es folgt die Installation von Docker und docker-compose. Details dazu habe ich bereits im Artikel Docker auf Ubuntu Server erklärt, daher hier der Schnelldurchlauf:

Als erstes installieren wir die Voraussetzungen:

apt install apt-transport-https ca-certificates curl software-properties-common

Als nächstes wird der Key des offiziellen Docker-Repositories auf dem System bekannt gemacht

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /usr/share/keyrings/docker-archive-keyring.gpg

Nun wird das offizielle Docker-Repository auf dem System konfiguriert:

echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/docker-archive-keyring.gpg] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

Docker und docker-compose werden nun über folgenden Befehl installiert:

apt update && apt install docker-ce docker-compose

Installation nginx

Den Webserver nginx installieren wir aus den offiziellen Paketquellen von nginx. Falls nginx bereits auf dem System installiert sein wollte, kann der folgende Abschnitt übersprungen werden. Auch hier wird erst einmal der Repository-Key importiert:

curl https://nginx.org/keys/nginx_signing.key | gpg --dearmor | sudo tee /usr/share/keyrings/nginx-archive-keyring.gpg >/dev/null

Nun wird das offizielle nginx-Repository hinzugefügt:

echo "deb [signed-by=/usr/share/keyrings/nginx-archive-keyring.gpg] http://nginx.org/packages/mainline/ubuntu $(lsb_release -cs) nginx" | tee /etc/apt/sources.list.d/nginx.list

Die Installation des Webservers erfolgt dann mit folgendem Befehl:

apt update && apt install nginx

Installation SearXNG

Nun kann es auch schon mit der Installation der Metasuchmaschine losgehen. Zunächst clonen wird das entsprechende GitHub-Repository in das Verzeichnis /opt und wechseln dann in dieses Verzeichnis:

cd /opt
git clone https://github.com/searxng/searxng-docker.git
cd searxng-docker

Anschließend generieren wird den Secret-Key für die SearXNG-Instanz (quasi die Identifizierung der Instanz). Dieser Key sollte dabei nicht an die Öffentlichkeit gelangen):

sed -i "s|ultrasecretkey|$(openssl rand -hex 32)|g" searxng/settings.yml

Als nächstes werfen wir einen Blick in die Konfigurations-Datei für SearXNG:

nano searxng/settings.yml

Ganz oben sehen wir gleich eine wichtige Zeile:

use_default_settings: true

SearXNG soll hier die Standard-Einstellungen nutzen (siehe hier). Dies macht die Konfiguration sehr einfach, da diese Einstellungen für die meisten Instanzen passen sollten und man sich nicht mit allen möglichen Einstellungen herumschlagen muss. Auf GitHub gibt es hier eine komplette settings.yml, die die Standard-Einstellungen repräsentiert.
In unserer settings.yaml kann dabei jede Standard-Einstellung von individuellen Einstellungen überschrieben werden. Hier ein Beispiel, wie so etwas aussehen kann:

# see https://docs.searxng.org/admin/engines/settings.html#use-default-settings
use_default_settings: true
general:
  # displayed name
  instance_name: "Meine eigene Suchmaschine"
  contact_url: mailto:meine-email@meinedomain.de
server:
  # base_url is defined in the SEARXNG_BASE_URL environment variable, see .env >
  secret_key: "automatisch-erzeugter-key
  limiter: true  # can be disabled for a private instance
  image_proxy: true
  http_protocol_version: "1.1"
ui:
  static_use_hash: true
redis:
  url: redis://redis:6379/0

Folgende Einstellungen wurden hier individuell angepasst:

• Mit "instance_name" wird der Name der Instanz angegeben. Dieser Name erscheint dann z.B. in der Titelleiste des Browsers.
• contact_url gibt eine URL oder auch per mailto eine Kontaktmöglichkeit (per Mail) zum Betreuer der Instanz an.
• Den secret_key haben wir bereits weiter oben durch einen zufälligen Schlüssel ersetzt.
• Mit http_protocol_version wird die zu verwendende HTTP-Version angegeben. Version 1.1 ist hier die neuste Version, die angegeben werden kann, daher nutzen wir diese.

Weitere Einstellungen – beispielsweise die standardmäßig aktivierten Suchmaschinen, Safe Search, etc. – können in der settings.yml einfach zusätzlich mit angegeben werden, dadurch werden dann die Standard-Einstellungen überschrieben. Eine Übersicht aller Einstellungen inkl. Erklärungen sind in der Dokumentation zu finden.

Als nächstes wird die Domain konfiguriert, unter der SearXNG später erreichbar sein soll:

nano .env

Hier ist lediglich die Variable SEARXNG_HOSTNAME zu definieren, die LETSENCRYPT_EMAIL ist unwichtig, da wir die Let’s Encrypt Zertifikate später selbst generieren werden.
Wer keinen nginx, sondern caddy per docker-compose verwenden möchte, sollte hier aber eine gültige E-Mail-Adresse hinterlegen, da diese für die automatische Zertifikats-Generierung von caddy benötigt wird.

# By default listen on https://localhost
# To change this:
# * uncomment SEARXNG_HOSTNAME, and replace <host> by the SearXNG hostname
# * uncomment LETSENCRYPT_EMAIL, and replace <email> by your email (require to create a Let's Encrypt certificate)

SEARXNG_HOSTNAME=searxng.meinedomain.de
# LETSENCRYPT_EMAIL=<email>

Bevor wir nun die Container hochziehen können, passen wir noch die Datei docker-compose.yaml an. In dieser werden die einzelnen Container inkl. Einstellungen definiert, die später mittels docker-compose hochgezogen werden sollen.

nano docker-compose.yaml

Wie bereits erwähnt, nutzen wir hier nicht caddy, sondern nginx als Webserver, daher können sämtliche Blöcke, die caddy betreffen, auskommentiert oder entfernt werden. Eine komplette docker-compose.yaml kann dann so aussehen:

version: '3.7'

services:

#  caddy:
#    container_name: caddy
#    image: caddy:2-alpine
#    network_mode: host
#    volumes:
#      - ./Caddyfile:/etc/caddy/Caddyfile:ro
#      - caddy-data:/data:rw
#      - caddy-config:/config:rw
#    environment:
#      - SEARXNG_HOSTNAME=${SEARXNG_HOSTNAME:-http://localhost:80}
#      - SEARXNG_TLS=${LETSENCRYPT_EMAIL:-internal}
#    cap_drop:
#      - ALL
#    cap_add:
#      - NET_BIND_SERVICE
#      - DAC_OVERRIDE

  redis:
    container_name: redis
    image: "redis:alpine"
    command: redis-server --save "" --appendonly "no"
    networks:
      - searxng
    tmpfs:
      - /var/lib/redis
    cap_drop:
      - ALL
    cap_add:
      - SETGID
      - SETUID
      - DAC_OVERRIDE
    restart: always


  searxng:
    container_name: searxng
    image: searxng/searxng:latest
    networks:
      - searxng
    ports:
     - "127.0.0.1:8080:8080"
    volumes:
      - ./searxng:/etc/searxng:rw
    environment:
      - SEARXNG_BASE_URL=https://${SEARXNG_HOSTNAME:-localhost}/
    cap_drop:
      - ALL
    cap_add:
      - CHOWN
      - SETGID
      - SETUID
      - DAC_OVERRIDE
    logging:
      driver: "json-file"
      options:
        max-size: "1m"
        max-file: "1"
    restart: always
networks:
  searxng:
    ipam:
      driver: default

#volumes:
#  caddy-data:
#  caddy-config:

Die Teile, die caddy betreffen habe ich hier mal auskommentiert. Abweichend vom Standard habe ich hier lediglich die Anweisung restart: always für die beiden verbliebenden Container hinzugefügt, damit die Container bei Systemstart automatisch mit gestartet werden.
Der Port 8080 wird dabei von Host an den SearXNG Container weitergeleitet. Sollte der Port 8080 auf dem System bereits belegt sein (netstat -tulpn | grep 8080), dann sollte folgende Zeile angepasst werden (hier wird dann beispielsweise Port 8181 des Hosts für diesen Zweck verwendet):

ports:
     - "127.0.0.1:8181:8080"

Nun können die Container auch schon gestartet werden:

docker-compose up -d

Nach einer kurzen Wartezeit läuft nun schon mal SearXNG und wir können mit dem Webserver weiter machen.

Konfiguration nginx

Hier erweitern wir zunächst den HTTP-Gateway-vHost, dass dieser auf die SearXNG-Domain „hört“:

nano /etc/nginx/conf.d/HttpGateway.conf

Wichtig ist hier, dass die SearXNG-Domain unter server_name mit angegeben wird. Wenn ihr bereits andere Webanwendungen am Laufen habt, werden vermutlich schon mehrere Domains unter server_name aufgelistet sein. In diesem Fall dann einfach die SearXNG-Domain am Ende mit hinzufügen (hier müsst ihr natürlich eure echte Domain verwenden).

server {
        listen 80 default_server;
        listen [::]:80 default_server;
        server_name searxng.meinedomain.de;

        root /var/www;

        location ^~ /.well-known/acme-challenge {
                default_type text/plain;
                root /var/www/letsencrypt;
        }

        location / {
                return 301 https://$server_name$request_uri;
        }
}

Im Grunde genommen ist dieser vHost nur für die Generierung der TLS-Zertifikate notwendig, da nur diese Anfragen unverschlüsselt über Port 80 beantwortet werden. Alles andere wird automatisch an Port 443 (verschlüsselt) weitergeleitet.

Nun legen wir gleich noch einen vHost für SearXNG an. Dieser wird aber erst einmal nicht aktiviert (Dateiname endet nicht auf .conf), weil die hier angegebenen Zertifikate ja noch nicht generiert wurden:

nano /etc/nginx/conf.d/searxng.meinedomain.de.conf.disabled

Der Inhalt sieht hier folgendermaßen aus:

server {
    listen 443 ssl http2;
    listen [::]:443 ssl http2;
    server_name searxng.mainedomain.de;
        
    # SSL configuration
    # SA certificates
    ssl_certificate /etc/letsencrypt/searxng.mainedomain.de/rsa/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/searxng.mainedomain.de/rsa/key.pem;
    # ECC certificates
    ssl_certificate /etc/letsencrypt/searxng.mainedomain.de/ecc/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/searxng.mainedomain.de/ecc/key.pem;

    # This should be ca.pem (certificate with the additional intermediate certifica$
    # See here: https://certbot.eff.org/docs/using.html
    # ECC
    ssl_trusted_certificate /etc/letsencrypt/searxng.mainedomain.de/ecc/ca.pem;

    # SSL stapling has to be done seperately, becuase it will not work with self signed certs
    # OCSP Stapling fetch OCSP records from URL in ssl_certificate and cache them
    ssl_stapling on;
    ssl_stapling_verify on;
        
    # Include SSL configuration
    include /etc/nginx/snippets/ssl.conf;

    # Include headers
    include /etc/nginx/snippets/headers.conf;

    # Important: Disable error and access log, so that no IPs get logged
    access_log  off;
    error_log off;

    location /{
        proxy_pass http://127.0.0.1:8080;

        proxy_set_header   Host             $host;
        proxy_set_header   Connection       $http_connection;

        # see flaskfix.py
        proxy_set_header   X-Scheme         $scheme;

        # see limiter.py
        proxy_set_header   X-Real-IP        $remote_addr;
        proxy_set_header   X-Forwarded-For  $proxy_add_x_forwarded_for;

        # proxy_buffering  off;
        # proxy_request_buffering off;
        # proxy_buffer_size 8k;

    }
}

Wichtig sind hier zwei Dinge:

• Der server_name gibt wieder eure SearXNG-Domain an.
• Sollte bei euch schon der Port 8080 belegt sein (siehe oben) und ihr SearXNG daher auf einen anderen Port gelegt haben solltet, dann ist dieser Port bei proxy_pass entsprechend anzupassen.

Wie in diesem vHost zu sehen, werden „Snippets“ für die SSL- und Header-Einstellungen inkludiert – dies sollte dem Leser dieses Blogs ja durchaus schon geläufig sein. Hier nochmal zum besseren Verständnis die Inhalte dieser beiden Snippets:

/etc/nginx/snippets/ssl.conf 

#
# Configure SSL
#

# Certificates used are located in file /etc/nginx/snippets/certs_pub.conf and /etc/nginx/snippets/certs_priv.conf
# These have to be included in the vHosts

# Diffie-Hellman parameter for DHE ciphersuites, recommended 4096 bits
ssl_dhparam /etc/nginx/dhparams/dhparams.pem;

# Not using TLSv1 will break:
# Android <= 4.4.40 IE <= 10 IE mobile <=10
# Removing TLSv1.1 breaks nothing else!
ssl_protocols TLSv1.2 TLSv1.3;

# SSL ciphers: RSA + ECDSA
# Two certificate types (ECDSA, RSA) are needed.
ssl_ciphers 'TLS-CHACHA20-POLY1305-SHA256:TLS-AES-256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA512:DHE-RSA-AES256-GCM-SHA512:ECDHE-RSA-AES256-GCM-SHA384';

# Use multiple curves.
ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

resolver 127.0.0.53;

# SSL session handling
ssl_session_timeout 1d; 
ssl_session_cache shared:SSL:50m; 
ssl_session_tickets off;

/etc/nginx/snippets/headers.conf 

#
# Add headers to serve security related headers
#  
# HSTS (ngx_http_headers_module is required) In order to be recoginzed by SSL test, there must be an index.hmtl in the server's root
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload;" always; 
add_header X-Content-Type-Options "nosniff" always;
add_header X-XSS-Protection "1; mode=block" always;
add_header X-Robots-Tag none always;
add_header X-Download-Options noopen always;
add_header X-Permitted-Cross-Domain-Policies none always;
add_header Referrer-Policy no-referrer always;
add_header X-Frame-Options "SAMEORIGIN" always;
# Disable FloC
add_header Permissions-Policy "interest-cohort=()";

# Remove X-Powered-By, which is an information leak
fastcgi_hide_header X-Powered-By;

Wir starten den Webserver nun einmal neu, damit die Änderungen übernommen werden:

service nginx restart

Generierung der TLS-Zertifikate

Ein letzter Schritt fehlt nun noch: Die Generierung der TLS-Zertifikate. Dies erledigen wir mit dem Let’s Encrypt Client acme.sh. Falls dieser noch nicht installiert und konfiguriert sein sollte: Im Artikel RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) ist dies im Detail beschrieben.

Zuerst werden die Verzeichnisse angelegt, in die gleich die Zertifikate „installiert“ werden:

mkdir -p /var/www/letsencrypt/.well-known/acme-challenge 
chown -R www-data:www-data /var/www/letsencrypt 
chmod -R 775 /var/www/letsencrypt 
mkdir -p /etc/letsencrypt/searxng.meinedomain.de/rsa
mkdir -p /etc/letsencrypt/searxng.meinedomain.de/ecc
chown -R www-data:www-data /etc/letsencrypt/searxng.meinedomain.de 
chmod -R 775 /etc/letsencrypt/searxng.meinedomain.de 

Nun wechseln wir auf den Let’s Encrypt User:

su - letsencrypt

Als erstes besorgen wir uns die RSA-Zertifikate (hier ist wieder die tatsächlich genutzte Domain zu verwenden):

acme.sh --issue -d searxng.meinedomain.de --server letsencrypt --keylength 4096 -w /var/www/letsencrypt --key-file /etc/letsencrypt/searxng.meinedomain.de/rsa/key.pem --ca-file /etc/letsencrypt/searxng.meinedomain.de/rsa/ca.pem --cert-file /etc/letsencrypt/searxng.meinedomain.de/rsa/cert.pem --fullchain-file /etc/letsencrypt/searxng.meinedomain.de/rsa/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Es folgen die ECDSA-Zertifikate:

acme.sh --issue -d searxng.meinedomain.de --server letsencrypt --keylength ec-384 -w /var/www/letsencrypt --key-file /etc/letsencrypt/searxng.meinedomain.de/ecc/key.pem --ca-file /etc/letsencrypt/searxng.meinedomain.de/ecc/ca.pem --cert-file /etc/letsencrypt/searxng.meinedomain.de/ecc/cert.pem --fullchain-file /etc/letsencrypt/searxng.meinedomain.de/ecc/fullchain.pem --reloadcmd "sudo /bin/systemctl reload nginx.service"

Am Ende wechseln wir wieder auf den normalen User:

exit

Wenn die Zertifikate korrekt generiert worden sind, dann kann nun der vHost aktiviert werden, der diese Zertifikate verwendet:

mv /etc/nginx/conf.d/searxng.meinedomain.de.conf.disabled /etc/nginx/conf.d/searxng.meinedomain.de.conf
service nginx restart

Aufruf und Nutzung von SearXNG

Nun könnt ihr auch schon eure SearXNG-Domain im Browser aufrufen: https://searxng.meinedomainde

Die Einstellungen erreicht ihr über das Zahnrad-Symbol (oben rechts). Hier können die zu nutzenden Suchmaschinen definiert und weitere Einstellungen festgelegt werden. Diese Einstellungen werden ausschließlich per Cookie in eurem Browser (und nicht auf dem Server) gespeichert.
Wenn ihr mal alle Einstellungen durchgegangen seid und die Optionen nach euren Vorlieben angepasst habt, könnt ihr in den Einstellungen unter Cookies einen Link finden, mit dem ihr diese Einstellungen auch in anderen Browsern übernehmen könnt („URL zur Wiederherstellung der Einstellungen in einem anderen Browser“).

Ansonsten gibt es hier nicht viel zu sagen, bedient wird SearXNG wie jede andere Suchmaschine auch. Tipps zur Such-Syntax sind in der offiziellen Dokumentation zu finden.

Bleibt bloß noch, die eigene SearXNG-Instanz als Standard-Suchmaschine im Browser hinzuzufügen. Das jeweilige Vorgehen ist dabei von Browser abhängig:

• Firefox: Suchmaschinen in Firefox hinzufügen oder entfernen
• Chrome: Kürzel für die Standardsuchmaschine und die Websitesuche festlegen
• Edge: Ändern der Standardsuchmaschine in Microsoft Edge
• Brave: How do I set my default search engine?
• Safari: Hier sieht Apple keine eigenen Suchmaschinen vor, Abhilfe schafft hier aber eine Browser-Erweiterung: Safari: Benutzerdefinierte Suchmaschine einrichten

Anpassen der Standard-Einstellungen für SearXNG

Wenn ihr nun nachträglich nun die Standard-Einstellungen eurer SearXNG-Instanz verändern wollt, kann die settings.yml angepasst werden:

nano /opt/searxng-docker/searxng/settings.yml

Damit die Änderungen übernommen werden, ist SearXNG mittels docker-compose neu zu starten:

cd /opt/searxng-docker
docker-compose restart

Update von SearXNG

SearXNG wird aktiv weiterentwickelt und so stehen von Zeit zu Zeit Updates zur Verfügung. Am besten schaut man regelmäßig hier auf „Tags“-Seite bei DockerHub vorbei, hier sieht man, wann das letzte Update bereitgestellt wurde.

Vor einem Update sichert man sich am besten die Dateien, die man für die eigene Instanz angepasst hat:

cp /opt/searxng-docker/.env /backups/searxng-docker/.env
cp /opt/searxng-docker/docker-compose.yaml /backups/searxng-docker/docker-compose.yaml
cp /opt/searxng-docker/searxng/settings.yml /backups/searxng-docker/searxng/settings.yml

Das Update kann dann durch folgende Befehle durchgeführt werden:

cd /opt/searxng-docker
docker-compose pull
docker-compose down
docker-compose up -d

Fazit

Die Installation von SearXNG gestaltet sich mittels docker-compose recht einfach, so dass ihr innerhalb von ca. 30 Minuten eure eigene Metasuchmaschine realisieren könnt. SearXNG nutzt im Hintergrund die Suchmaschine(n), die ihr sonst auch nutzen würdet, so dass die Qualität der Suchergebnisse vergleichbar sein sollte. Was Datenschutz und Privatsphäre angeht, steht ihr mit eurer eigenen Suchmaschine allerdings sehr viel besser da.

Probiert SearXNG doch einfach mal aus. Wenn ihr nicht gleich eine eigene Suchmaschine hosten wollt, dann gibt es auf searx.space eine Liste an öffentlichen SearXNG (und searx) Instanzen, die jeder nutzen kann. Unter search.decatec.de habe ich auch mal eine Instanz aufgesetzt, die öffentlich zugänglich ist. Das Setup und die Einstellungen entsprechen genau jenen, die hier im Artikel gezeigt wurden. Einfach mal ausprobieren!

Weiterführende Artikel

• Docker auf Ubuntu Server
• RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung)
• Metasuchmaschine searx auf eigenem Server installieren (mit Docker und nginx)

Links

• search.decatec.de (SearXNG-Instanz von decatec.de)
• SearXNG (GitHub)
• searxng-docker (GitHub)
• SearXNG Dokumentation
• Metasuchmaschine (Wikipedia)
• acme.sh (GitHub)
• Liste der öffentlichen searx/SearXNG Instanzen

Ähnliche Artikel:

Metasuchmaschine searx auf eigenem Server installieren (mit Docker und nginx) RSA und ECDSA-Zertifikate mit nginx (Hybrid-Lösung) Nextcloud auf Ubuntu Server 20.04 LTS mit nginx, MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban Nextcloud auf Ubuntu Server 22.04 LTS mit nginx, PostgreSQL/MariaDB, PHP, Let’s Encrypt, Redis und Fail2ban