Zum Inhalt springen

Kategorie: Linux

Alternative zu SearXNG: degoog

Ich nutze schon länger SearXNG und bin bei selfh.st über degoog gestolpert. Von der Idee her dasselbe, gefühlt aber etwas moderner und schicker. Auch hier können verschiedene Suchmaschinen eingebunden werden und die Ergebnisse werden dann aggregiert. Dazu gibt es auch noch Plugins, z.B. für Wetter oder OpenStreetMap.

Und hier ein Suchergebnis meiner SearXNG Instanz:

Ein nettes Feature ist das Plugin AI Summary. Mit einem (lokalen) LLM lassen sich Zusammenfassungen zur Suche generieren. Ich hab das mal mit llama3.2 ausprobiert, weil es sehr schnell Antworten erzeugt.

Und eingerichtet ist degoog auch innerhalb von wenigen Minuten mit Docker Compose.

Oracle reduziert die Compute Always Free Resources

Ich bin zufällig bei Reddit [1] [2] [3] darüber gestolpert:

Die bisher kostenlosen 4 OCPUs und 24 GB RAM werden halbiert auf 2 OCPUs und 12 GB RAM. An sich finde ich das in Ordnung, weil es ist halt kostenlos. Aber eine Email dazu wäre schon super gewesen. Sonst gibt es bald ein böses PAYG Erwachen, wenn die nicht mehr kostenlosen OCPUs und RAM berechnet werden.

Hier die Docs von Oracle dazu: https://docs.oracle.com/en-us/iaas/Content/FreeTier/freetier_topic-Always_Free_Resources.htm#compute

Aber egal, 2 + 12 ist immer noch gut und mehr als ausreichend, um z.B. dieses WordPress Blog hier zu hosten.

Bei heise.de ist die Nachricht auch angekommen. Aber auch hier ist mehr oder weniger die einzige Quellen die aktualisieren Docs.

Fehlermeldung nach Update auf Docker 29

Nach dem Update auf Docker 29.0.0 kommt es auf meinem Homeserver zu Problemen.
Die Fehlermeldung lautet zum Beispiel:

Error response from daemon: client version 1.24 is too old. 
Minimum supported API version is 1.44, please upgrade your client to a newer version.

Ein funktionierender Workaround ist der Wechsel zurück auf die letzte stabile 28er-Version, wie hier auf meinem Ubuntu 22.04 (Jammy).

# find previous versions
apt-cache madison docker-ce

# downgrade to 28.5.2
sudo apt install \
  docker-ce=5:28.5.2-1~ubuntu.22.04~jammy \
  docker-ce-cli=5:28.5.2-1~ubuntu.22.04~jammy \
  containerd.io docker-buildx-plugin docker-compose-plugin

Danach empfiehlt sich, die Pakete zu „freezen“, um ein automatisches Upgrade auf 29 zu verhindern:

# disable auto-updates
sudo apt-mark hold docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

# verify
apt-mark showhold

Jedenfalls so lange, bis die Probleme (z.B. bei Traefik) behoben sind.


Update 1: Bei Docker selbst gibt es auch Infos: https://www.docker.com/blog/docker-engine-version-29/

Also sollte auch der genannten Ansatz funktionieren, die /etc/docker/daemon.json anzupassen.

{
    "min-api-version": "1.24"
}

Update 2: Ja, das funktioniert ebenfalls. Danach macht das Update auf Docker 29 auch keine Probleme mehr.

Docker Desktop bzw. WSL Dateisystem verschieben

Mein Laufwerk C: läuft regelmäßig voll, u.a. wegen den wachsenden Dateisystemen von Docker und der WSL. Bisher hab ich mich mehr schlecht als recht damit geholfen, die ext4.vhdx Dateien zu komprimieren.

Aber… es ist möglich, die Dateisysteme, also die ext4.vhdx Dateien auf ein anderes Laufwerk umzuziehen.

Hier am Beispiel meines Ubuntu-18.04 WSL, welches ich von C: nach E:\wsl\ubuntu umziehen möchte:

# Zielverzeichnis erstellen
mkdir E:\wsl\ubuntu

# WSL stoppen
wsl --shutdown

# Backup erzeugen 
wsl --export Ubuntu-18.04 "E:\wsl\ubuntu\Ubuntu-18.04.tar"

# ggf. vorhandene originale ext4.vhdx von C: sichern, denn jetzt wird diese gelöscht
wsl --unregister Ubuntu-18.04

# Backup wieder importieren
wsl --import Ubuntu-18.04 "E:\wsl\ubuntu" "E:\wsl\ubuntu\Ubuntu-18.04.tar" --version 2

# ggf. default WSL und User setzen, wenn nötig
wsl --set-default Ubuntu-18.04
ubuntu1804 config --default-user <wsl_user_name>

# wenn die WSL startet und alles funktioniert, das Backup nun löschen
del E:\wsl\ubuntu\Ubuntu-18.04.tar

Auf E: ist mehr als genügend Platz und die ext4.vhdx Datei in E:\wsl\ubuntu kann (erstmal) wachen, wie sie möchte.

Websites auf Änderungen überwachen mit changedetection.io

Für den Homeserver daheim steht ein nettes Tool zur Verfügung, um Websites auf Änderungen zu überwachen: changedetection.io

Wie üblich ist alles mit Docker innerhalb kürzester Zeit aufgesetzt:

version: '2'
services:
  changedetection:
    image: dgtlmoon/changedetection.io
    container_name: changedetection.io
    ports:
     - "5050:5000"
    restart: unless-stopped
    volumes:
     - ./datastore:/datastore
    environment:
     - WEBDRIVER_URL=http://browser-chrome:4444/wd/hub
  browser-chrome:
    hostname: browser-chrome
    image: selenium/standalone-chrome
    container_name: standalone-chrome
    shm_size: '2gb'
    restart: unless-stopped

Benachrichtigen kann man sich dann z.B. via eMail, Discord oder Telegram. Oder über ganz viele andere Kanäle, dann im Endeffekt wird Apprise unter der Haube benutzt.

Grafana Loki mit Docker

Es ist relativ einfach, Grafana Loki als Logging Stack zu nutzen. Dann lassen sich sehr bequem die Logs aller Container zentral sammeln und einsehen (via Grafana).

Den passenden Treiber für Docker gibt es hier: https://grafana.com/docs/loki/latest/clients/docker-driver/

Nun noch das docker-compose.yml File um Loki zu starten (in diesem Stack könnte z.B. auch direkt Grafana mit dazugepackt werden):

version: '3.3'
services:
  loki:
    container_name: grafana-loki
    image: 'grafana/loki:latest'
    ports:
      - '3100:3100'
    command: '-config.file=/etc/loki/local-config.yaml'
    restart: unless-stopped
    volumes:
      - 'loki-data:/loki'
      - './loki/local-config.yaml:/etc/loki/local-config.yaml'
volumes:
  loki-data: null

Und noch die dazugehörige Loki Config mit einer Retention von 180 Tagen:

auth_enabled: false

server:
  http_listen_port: 3100

common:
  path_prefix: /loki
  storage:
    filesystem:
      chunks_directory: /loki/chunks
      rules_directory: /loki/rules
  replication_factor: 1
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: inmemory

schema_config:
  configs:
    - from: 2020-10-24
      store: boltdb-shipper
      object_store: filesystem
      schema: v11
      index:
        prefix: index_
        period: 24h

ruler:
  alertmanager_url: http://localhost:9093

compactor:
  working_directory: /loki/retention
  shared_store: filesystem
  compaction_interval: 10m
  retention_enabled: true
  retention_delete_delay: 2h
  retention_delete_worker_count: 150

limits_config:
  retention_period: 180d

Automatische Docker Image Updates

Auf meinem kleinen Ubuntu Server zu Hause tummeln sich ca. 30 Docker Container. Bisher habe ich mich via Docker-Update-Image-Notififier (DIUN) über Updates benachrichtigen lassen, wenn es neue Version der genutzten Images gab. Das Update hab ich dann aber trotzdem noch selbst gemacht bzw. machen müssen. Die Benachrichtung via eMail ist ganz ansprechend und die ganze Geschichte lässt sich sich schön individuell konfigurieren, ja nachdem, wie man es braucht.

Hier mal das dazugehörige docker-compose.yml:

version: "3.5"
services:
  diun:
    container_name: diun
    image: crazymax/diun:latest
    volumes:
      - "./data:/data"
      - "./diun.yml:/diun.yml:ro"
      - "/var/run/docker.sock:/var/run/docker.sock"
    environment:
      - "TZ=Europe/Berlin"
      - "LOG_LEVEL=info"
      - "LOG_JSON=false"
    restart: unless-stopped

Und noch die diun.yml dazu:

watch:
  workers: 20
  schedule: "30 2 * * *"
  firstCheckNotif: true

providers:
  docker:
    watchByDefault: true
    
notif:
  mail:
    host: smtp.my-email-provider.de
    port: 465
    ssl: true
    insecureSkipVerify: true
    from: [email protected]
    to: [email protected]
    username: blablabla
    password: blablubb123

Die Benachrichtigung sieht dann in etwa so aus:

Soweit, so gut. Heute habe ich dann zufällig Watchtower entdeckt. Da sehen die Benachrichtigungen zwar nicht so schön aus, aber dafür können automatische Updates gemacht werden, wenn neue Versionen der Images vorliegen.

Auch hier wieder eine komplette docker-compose.yml, inkl. eMail Relay via Postfix:

version: "3.5"

services:
  watchtower:
    image: containrrr/watchtower:latest
    container_name: watchtower
    restart: unless-stopped
    depends_on: 
      - postfix
    environment:
      TZ: 'Europe/Berlin'
      WATCHTOWER_MONITOR_ONLY: 'false'
      WATCHTOWER_CLEANUP: 'true'
      WATCHTOWER_SCHEDULE: '0 15 5 * * *'
      WATCHTOWER_HTTP_API_METRICS: 'true'
      WATCHTOWER_HTTP_API_TOKEN: no5theit0dooqueih2ohjoo7ya6Tai7a
      WATCHTOWER_NOTIFICATIONS: email
      WATCHTOWER_NOTIFICATION_EMAIL_FROM: [email protected]
      WATCHTOWER_NOTIFICATION_EMAIL_TO: [email protected]
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER: postfix
      WATCHTOWER_NOTIFICATION_EMAIL_SERVER_PORT: 25
      WATCHTOWER_NOTIFICATION_EMAIL_DELAY: 5
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
    ports:
      - 9180:8080
  postfix:
    image: juanluisbaptiste/postfix:latest
    container_name: postfix
    restart: unless-stopped
    environment:
      TZ: 'Europe/Berlin'
      SMTP_SERVER: smtp.my-email-provider.de
      SMTP_PORT: 25
      SMTP_USERNAME: blablabla
      SMTP_PASSWORD: blablubb123
      SERVER_HOSTNAME: my-dockerhost

Die bereitgestellten Metriken greift mein Prometheus ab:

  - job_name: 'watchtower'
    scrape_interval: 5s
    metrics_path: /v1/metrics
    bearer_token: no5theit0dooqueih2ohjoo7ya6Tai7a
    static_configs:
      - targets: ['192.168.1.130:9180']

Wenn bestimmt Images nicht aktualisiert werden sollen, was z.B. bei auf dem System selbst gebauten Images der Fall ist, kann das mit diesem Label verhindert werden:

version: '3.3'
services:
  my-app:
    ports:
      - '8080:8080'
    container_name: my-app
    image: 'my-app:latest'
    restart: unless-stopped
    volumes:
      - './log:/app/log'
    labels:
      - com.centurylinklabs.watchtower.enable=false