SearXNG ja ValkeyDB:n asennus

SearXNG vaihtoi Redisistä Valkeyhin. Nuo ovat periaattessa samaa, ja samantyyppisestä asiasta on kyse kuin mikä on tilanne MySQL:n ja MariaDB:n kanssa. Valkey taitaa olla Redisin forkki.

Valkey ymmärtääkseni syntyi lisenssiriidoista, kun Redis muutti omaansa sellaiseksi, että se ei nää mahtunut open source filosofiaan. Kyllä, käytin lauseessa aika paljon epävarmuuksia, koska en edes väitä ymmärtäväni tuota. Minä vain asennan mitä käsketään. Ja käskettiin käyttää Valkeyta.

En ole aivan varma, että tarvitsenko edes Valkeytä. Mutta kaipa se on hyvä olla.

Olen muissakin yhteyksissä maininnut, että SearXNG:n dokumentointi vaatii syvempää kuin perusosaamista. Toki aina kaikessa perusteiden vaatimus löytyy, jollain tasolla, mutta SearXNG edellyttää tavallista enemmän, ja että tosiaankin osaa käyttää tarvittavia lisäkilkkeitä. Discoursen asennus onnistuu kehittäjän ohjeilla, kunhan tietää edes perusteet linux-serverien sielunelämästä. WordPress onnistuu, jos hallitsee kopioinnin ja liimaamisen.

En saanut Valkeyta asennettua SearXNG:n dokumentoinnilla. Sen sijaan oma SearXNG instanssi palveli ansiokkaasti hakujani etsiessäni rautalankatason ohjeita asennukseen ja asetuksiin.

Näillä tempuilla sain kuitenkin omani käyntiin. Ohjeet ovat dockerilla käytettävälle SearXNG-asennukselle. Jos on asentanut omansa ilman, niin päässee helpommalla. Riittää kun laittaa hostissa paikallisesti asiat kuntoon ja sitten kertoo settings.yml tiedostossa missä tietokanta kuuntelee. Luulisin.

Jos käyttää hostissa Valkeytä

ValkeyDB:tä ei saa käyttökuntoon pelkällä apt install valkey-server. Tai minulla ei onnistunut, koska docker sotki kaiken mahdollisen. Ja ennen kuin pääsin edes riitelemään dockerin kanssa, niin Valkey ei suostunut edes käynnistymään.

Minä en sitten tiedä koska puhutaan dockerista ja milloin pitäisi mainita container.

Jos olisin mennyt TCP:n kanssa, niin olisin saattanut päästä vähän helpommalla. Mutta päätin käyttää socketia, ja se aiheutti mutkia matkaan.

Ubuntu 24.04 ja asennus menee kuin aina (melkein) kaikessa:

sudo apt update
sudo apt install valkey-server
sudo systemctl enable --now valkey-server
sudo systemctl status valkey-server

Ja tässä vaiheessa sitten valkey-server kaatui heti, ensimmäisen kerran. Syy oli kädetön sysadmin, joka oli totaalisesti unohtanut, että serverillä pyöri jo Redis. Olin kokeillut sitä aika kauankin aikaa sitten objekticachena WordPressille ja turhaksi havainnut omilla kävijämäärillä. Joten se oli taustalla hylättynä ja hyödyntämättömänä käynnissä.

Valmeyn asennuksen jälkeen molemmat yrittivät änkeä samaan porttiin, ja sehäm ei ole sallittua. Taisto, jonka viimeinen pääsääntöisesti häviää. Joten sammutin Redisin ja muistin jopa disabloida sen. Lisäksi vapautin portit ja tapoin varmuuden vuoksi molemmat prosessit.

sudo systemctl stop valkey-server redis-server 2>/dev/null || true
sudo pkill -f 'valkey-server|redis-server' || true
sudo ss -lptn 'sport = :6379' || true

Valkeyn asetukset

Koska halusin käyttää socketia, niin se vaatii omat kikkailunsa. Ensin laitetaan Valkeyn asetukset kuntoon.

sudo nano /etc/valkey/valkey.conf

Sinne laitetaan tämä:

port 0
unixsocket /run/valkey/valkey.sock
unixsocketperm 770

supervised systemd
daemonize no

maxmemory 512mb
maxmemory-policy allkeys-lru #

# Persistenssi: useimmiten EI tarvita SearXNG:n cache/limitteriin
save ""
appendonly no

Useimmat kohdat Valkeyn konffissa on kommentoitu, joten tuon voi kopypeistata heti alkuun. Mutta muistaakseni daemonize yes on joko komentoitava tai vaihdettava.

Riitelin pari tuntia, koska Valkey kaatui koko ajan. Sain sen lopulta kuntoon, kun oivalsin komennon

sudo journalctl -u valkey-server -e --no-pager | tail -n 50

. Joten huomioi kaksi asiaa:

• socketin kanssa konffin rivi pidfile /run/valkey/valkey-server.pid täytyy kommentoida
• inline-kommentteja ei saa käyttää, ja olin suunnilleen jokaisen kohdan kommentoinut ymmärtääkseni ensi viikollakin miksi ne olivat siellä; joten kommentit omalle rivilleen.

Sitten:

sudo systemctl restart valkey-server

Jos Valkey valittaa hakemisto-oikeuksista socketin kanssa, niin korjaa ne käsin:

sudo mkdir -p /run/valkey
sudo chown valkey:valkey /run/valkey
sudo chmod 0770 /run/valkey

Ryhmäasiat täytyy laittaa kuntoon. En ole kylläkään ihan täysin varma, että tarvitaanko tätä dockerin kanssa, mutta näin minä tein:

sudo usermod -aG valkey searxng

docker-compose.yml

Ennenkuin alat muokkaamaan mitään, niin selvitä mikä on Valkeyn GID. Sitä numeroa tarvitaan seuraavaksi:

getent group valkey

SearXNG ei vielä toimi, vaikka settings.yml olisi oikein. Container ei näe mitä hostissa tapahtuu, joten sille Valkeyta ei ole edes olemassa.

Joten nämä kohdat on lisättävä (merkitsen vain tässä oleelliset):

services:
  searxng:
    volumes:
      # tuo hostin socket-hakemisto
      - /run/valkey:/run/valkey:rw
      # ja tämän alle loput searxng asiat

    group_add:
      # anna valkey-ryhmän GID hostista (korvaa 123 oikealla GID:llä)
      - "123"

Valkeyn socket täytyy kertoa ensimmäisenä. Tai näin uskon, en tarkistanut asiaa. Mutta uskoisin tietokannan täytyvän olla tiedossa ennenkuin muita asioita tehdään — taas: en tosin ymmärrä miten docker, container ja imaget ylipäätään toimivat.

Vielä settings.yml auki ja:

valkey:
  url: unix:///run/valkey/valkey.sock?db=0

Lopuksi tuttu

docker compose down && docker compose up -d && docker logs -f searxng

Login ei pitäisi näyttää virheitä.

Jos käyttää containerissa Valkeyta

Hieman vähemmällä vaivalla pääsee, jos laittaa Valkeyn dockeriin/containeriin ja käyttää sitä sieltä. Tai ilmeisesti se laitetaan searxng kanssa samaan tai vierekkäin. Jotain.

Pointti on kuitenkin siinä, että silloin ei tarvitse asentaa hostille Valkeyta ja aptit, ryhmät sun muut jäävät välistä. Ellei halua tai tarvitse.

Joten avataan suoraan docker-compose.yml. Nyt lienee helpompi, että esitän omani. Pääsee vähemmällä selittämisellä. Mutta kyse on kuitenkin kahdesta:

• Valkey täytyy määritellä omaksi serviceksi
• Valkey täytyy käynnistää ennen searcxng:tä ja koska healthcheck tuntui muutenkin hyvältä ajatukselta (ja sellaisen ohjeen löysin… oman SearXNG-instanssin avustuksella), niin hyödynsin sitä

Samalla piti vaihtaa TCP:hen. En täysin tiedä miksi, mutta ilmeisesti ne jollain tapaa luokitellaan eri serverillä oleviksi, jolloin socket ei toimi. Tai sitten socketia ei vaan esimerkeissä käytetä.

services:
  valkey:
    image: valkey/valkey:latest
    command: >
      valkey-server
      --protected-mode no
      --port 6379
      --maxmemory 512mb
      --maxmemory-policy allkeys-lru
      --save ""
      --appendonly no
    healthcheck:
      test: ["CMD", "valkey-cli", "-h", "127.0.0.1", "-p", "6379", "PING"]
      interval: 5s
      timeout: 2s
      retries: 12
    restart: unless-stopped

  searxng:
    image: searxng/searxng:latest
    container_name: searxng
    depends_on:
      valkey:
        condition: service_healthy
    restart: unless-stopped
    ports:
      - "127.0.0.1:8888:8080"
    volumes:
      - /opt/searxng/settings.yml:/etc/searxng/settings.yml
      - /opt/searxng/limiter.toml:/etc/searxng/limiter.toml
      - /opt/searxng/static/custom:/usr/local/searxng/searx/static/custom
      # Logo
      - /opt/searxng/static/custom/img/searxng.png:/usr/local/searxng/searx/static/themes/simple/img/searxng.png
      # CSS muutokset
      - /opt/searxng/templates/simple/base.html:/usr/local/searxng/searx/templates/simple/base.html
      - /opt/searxng/static/css/custom.css:/usr/local/searxng/searx/static/css/custom.css

    environment:
      - SEARXNG_VALKEY_URL=valkey://valkey:6379/0
      - SEARXNG_BASE_URL=https://haku.eksis.eu/
      - SEARXNG_SECRET_KEY=<pitkä-merkkisarja>
      - UWSGI_WORKERS=2
      - UWSGI_THREADS=2

Tämä kuuluu settings.yml:

valkey:
  url: valkey://valkey:6379/0

Tämäkin muutos lopetetaan tähän. Ensin

docker compose pull

Ja sitten sammutukset, käynnistykset ja logi:

docker compose down && docker compose up -d && docker logs -f searxng

Taaskaan ei saisi näky Valkeyhin liittyviä erroreita.

Kumman itse valitsin?

Minä kokeilin kumpaakin, ja lopuksi otin käyttöön dockerimaisemman version. Pelkästään siitä syystä, että Valkeyn cli ja debuggaus on pari pykälää helpompaa kuin jos Valkey on hostissa. Koska käytin sockettia, niin Valkey CLI murjotti puuttuvasta portista, enkä saanut kyselyjäni toimimaan.

Olisi CLI:n käyttöön ollut parikin kiertotietä, mutta haluan päästä suoraan asiaan, jos mahdollista. Ehkä jos joskus tarvitsen serverin muissa hommissa moista tietokantaa, niin vaihdan takaisin hostissa toimivaan. Toiselta puolelta, minulla on hostin puolella myös Redis odottamassa töitä.

Syy sille miksi halusin CLI:n toimivan oli niinkin maatiainen, että halusin tietää toimiiko Valkey. Se, että en nähnyt virheitä, ei kuitenkaan minun maailmassani tarkoita, että Valkey tekisi töitä SearXNG:n kanssa. Haluan jotain minkä voin havainnoida.

Joten kun oli laittanut Valkeyn dockeriin, niin tämä toimi:

docker compose exec valkey valkey-cli info keyspace

Kun tekee haun, niin tuon reagointi tarkoittaa, että valkey tekee avaimia tietokantaan ja tajuaa searxng:n olemassaolon. Sitten taasen tämä:

docker compose exec valkey sh -lc "valkey-cli monitor" \
| grep -E 'SearXNG_|SET|EXPIRE|GET'

ja katselee livenä mitä tapahtuu hakuja tehdessä todistanee, että searxng kirjoittaa valkeyhyn.

Rate limiter

Viimeinen muistettava asia.

Suurin osa dokumenteista, ellei jokainen, totesi, että nyt saa otettua käyttöön limiterin. Sen aktivointiin yhdessä Valkeyn kanssa myös kannustettiin: limiter: true

Taas kerran kiukuttelen SearXNG:n dokumenteista. Minulle on selvinnyt, että limiter tekee erilaisia asioita, kuten arpoo headereista ja käyttäytymisestä onko joku botti, ja sen jälkeen säätänee rate limit aikoja. Ja sitten on rate limit itse — niin sanotusti kuinka monta kertaa saa painaa enteriä minuutissa.

Muille limiteriin liittyville toiminnoille on jonkinlaiset asetukset, jos ymmärtää mitä ne tarkoittavat ja mitkä saa käyttöön sekä miten, mutta ei rate limiterille. Se on jollain tavalla sisäänrakennettu, tai piilotettu default arvoilla.

Minulla on vain huonoja kokemuksia rate limitereista, aivan jokaisesta käyttämästäni palvelusta. Asetusten löytäminen niin, että se rankaisee botteja, mutta ei tehokäyttäjiä, on ollut aivan tolkuttoman vaikeaa. Mutta ehkä moinen olisi syytä ottaa käyttöön, koska instanssini on julkinen, vaikkakaan ei SearXNG:n lingossa julkinen.

Joten kokeilin sitä. Ensimmäinen haku, ja minulle ilmoitettiin liian useista pyynnöistä, ja jouduin jäähylle. Aloin kuitenkin asentelemaan limiteriä, koska halusin tietää miksi olin jäänyt kiinni jo yhdestä pyynnöstä, ja korjata sitten syyn.

Bottiestoja en sinällään varsinaisesti tarvitse, ainakaan SearXNG:n tekemänä. Tosin tuokin on turhan yksioikoisesti todettu, koska minulla bottiesto toimii user agentin mukaan ja user agentin muuttaminen on täysin triviaalia. Minulla kuitenkin Nginx tekee bottieston, samaten geoip-blokkauksen. Paljilta säästyy kun rajoittaa käytön vain suomalaisille ja on täysin triviaalia teknisesti sallia pääsy vain suomalaisilta IP-osoitteilta. En siis tarvitse rata limiter optiota, ainakaan sen mukaan miten nyt asian näen.

Ongelmaa saattaa tulla siinä vaiheessa, kun botti valehtee user agentissaan olevansa ihminen, ja käyttää VPN-tyyppistä ratkaisua ohittaakseen maaestot. Se menee vihellellen estojeni läpi ja alkaa spämmäämään hakuja. Siinä vaiheessa rate limiter olisi, jos ei ihan pelastus, niin hyödyllinen työkalu.

SearXNG:n dokumentaatio kertoo vaaditun limiter.toml asetustiedoston perusrakenteen, mutta ei yhtään enempää hyödyllistä — ja minun kohdallani tarkoittaa yksinkertaista rautalankaa. Lisäksi proaktiivisesti kannustetaan ottamaan käyttöön vain sellaiset vaihtoehdot, joita ehdottomasti tarvitsee. Oppimiskäyrän tässä vaiheessa tiedän ikkiriikkisen mitä ehkä tarvitsen, mutta en tiedä mitä limiter tarjoaa ja miten ne edes saa käyttöön.

Sen sijaan rate limiterin aika- ja muista säädöistä en löytänyt muuta kuin lyhyen maininnan sellaisten olemassaolosta. Joten jouduin taas kiusaamaan hakukoneita.

Juurikin rate limiter on vahvin kannuste, että asensin ValkeyDB:n — se vaaditaan siihen työhön.

Tämä on minulla (aloitusvaiheen) limiter.toml ja hyvin lähellä sellainen kuin mitä SearXNG:n reposta löytyy pohjamallina. Laita se containerin juureen hostilla, samaan paikkaan missä on settings.yml. Muista mountata se tiedostossa docker-compose.yml — aivan samalla tavalla kuin settingskin.

[botdetection]

# The prefix defines the number of leading bits in an address that are compared
# to determine whether or not an address is part of a (client) network.

ipv4_prefix = 32
ipv6_prefix = 64   # <-- vaihda tähän, koska oletus bannaa ison alueen

# If the request IP is in trusted_proxies list, the client IP address is
# extracted from the X-Forwarded-For and X-Real-IP headers. This should be
# used if SearXNG is behind a reverse proxy or load balancer.

trusted_proxies = [
  '127.0.0.0/8',
  '::1',
  # '192.168.0.0/16',
  # '172.16.0.0/12',
  # '10.0.0.0/8',
  # 'fd00::/8',
]

[botdetection.ip_limit]

# To get unlimited access in a local network, by default link-local addresses
# (networks) are not monitored by the ip_limit
filter_link_local = false

# activate link_token method in the ip_limit method
link_token = false

[botdetection.ip_lists]

# In the limiter, the ip_lists method has priority over all other methods -> if
# an IP is in the pass_ip list, it has unrestricted access and it is also not
# checked if e.g. the "user agent" suggests a bot (e.g. curl).

block_ip = [
  # '93.184.216.34',  # IPv4 of example.org
  # '257.1.1.1',      # invalid IP --> will be ignored, logged in ERROR class
]

pass_ip = [
# tässä saat vapautettua itsesi. En käytä, vielä, koska miten sitten tietää miten limiter toimii
  # '192.168.0.0/16',      # IPv4 private network
  # 'fe80::/10'            # IPv6 linklocal / wins over botdetection.ip_limit.filter_link_local
]

# Activate passlist of (hardcoded) IPs from the SearXNG organization,
# e.g. `check.searx.space`.
pass_searxng_org = false  # oletus on true. Tuo on public instanssien seurantaa varten. Mutta koska ei suoraan sanota mitä kolkutteluja tulee ja kuinka usein, mutta ovat huolissaan rate limitistä, niin minulla se toistaiseksi false

Joskus saattaa olla tarve saada dockerin proxyn IP luotetuksi proxyksi. Sen saa selvitettyä tällä komennolla:

docker network inspect searxng_default | jq -r '.[0].IPAM.Config[0].Subnet'

Se on kuitenkin luultavasti 172.17.0.0/16 tai 172.18.0.0/16

Törmäsin tuohon mahdollisuuteen kun pengoin syitä sille, että saan error 429 välittömästi. Ei se tosin auttanut. Mutta periaatteessa sen rooli tulee vastaan siinä vaiheessa kun SearXNG alkaa tuumimaan onko kävijä hyvis vai pahis. Jos käytetty proxy ei ole luotettu, trusted_pxoxy niin silloin käyttäjän IP:n sijaan tipautetaankin proxyn osoite.

Jos on noin, niin tätä en ymmärrä. Jokainen SearXNG:hen saapunut on tullut juurikin sen proxyn kautta. Se on ainoa ovi saapua. Joten se näkyy jokaikisellä, joten miksi sitä edes vahditaan, koska sen bannaaminen sulkee silloin koko palvelun aivan kaikilta — paitsi heiltä, joiden oma IP on luotettu, mutta heitähän ikkiriikkisen vähän.

Olisin säästänyt aikamoisesti hakukoneaikaa, jos olisin heti laittanut asetuksista päälle debug: true. Containerin/composen/dockerin — en aidosti tiedä kenen loki se on — kertoi välittömästi syyn estolle. Minulla ei ollut Accept-Encoding käytössä. Ei pakkausta, ei purkua. Ei ollutkaan, ja se säätö tuli Nginxin hostista, joten vaikutti jokaiseen kävijään.

Olin kokeillut JS-pohjaista tiedotusbanneria. Siinä ujutetaan JS-rivi sen jälkeen, kun sivu on matkalla maailmalle. Mutta sitä temppua ei voi tehdä pakatulle. Koska hakutulossivujen esittämisessä ei pakkauksella ole suurtakaan merkitystä, niin olin ottanut sen pois kokonaan — ja unohdin välittömästi koko homman.

Itseasiassa olin säätänyt gzipiä väärässä paikassa, ja ongelma syntyi siitä. Kun korjasin sen, niin ongelma poistui. Mutta pakkaustieto on yksi merkki muiden joukossa, jota SearXNG käyttää arvuutellessaan onko joku paha botti vai ei, ja kuinka tiukkoja sääntöjä pitäisi käyttää.