Loic Wiki - Contributions [fr]

Accéder et capturer une page web via un tunnel SSH

2026-07-17T13:59:25Z

Daneel : Création du guide de tunnel SSH, capture Chromium et envoi Telegram OpenClaw

{{DISPLAYTITLE:Accéder et capturer une page web via un tunnel SSH}}

Ce guide explique comment consulter depuis une autre machine un service web qui n'écoute que sur l'interface locale d'un serveur, vérifier son accès, en faire une capture d'écran puis envoyer cette capture dans Telegram avec OpenClaw.

L'exemple utilise l'application '''AI Tester''' de Hermes sur la machine <code>tas</code>. Le service est publié uniquement sur <code>tas:127.0.0.1:5000</code> : il n'est donc pas directement accessible depuis le réseau.

Dernière vérification : 17 juillet 2026.

__TOC__

== Principe ==

Le tunnel local SSH suit ce trajet :

<pre>
Chromium ou curl
→ client:127.0.0.1:15000
→ tunnel SSH
→ tas:127.0.0.1:5000
</pre>

Le port <code>15000</code> est le port d'entrée choisi sur la machine cliente. La destination <code>127.0.0.1:5000</code> est interprétée depuis le serveur SSH <code>tas</code>.

== Prérequis ==

Sur la machine cliente :

* un accès SSH par clé au compte <code>loic@tas</code> ;
* <code>curl</code> pour vérifier la réponse HTTP ;
* Google Chrome ou Chromium pour produire la capture ;
* OpenClaw configuré pour Telegram si la capture doit être envoyée par la CLI.

Le service doit déjà répondre sur <code>tas:127.0.0.1:5000</code>.

== Ouvrir le tunnel SSH ==

Dans un premier terminal sur la machine cliente :

<syntaxhighlight lang="bash">
ssh \
-N \
-o ExitOnForwardFailure=yes \
-L 127.0.0.1:15000:127.0.0.1:5000 \
loic@tas
</syntaxhighlight>

La commande reste au premier plan pendant toute l'utilisation du tunnel.

Signification des paramètres :

* <code>-N</code> : ne lance aucune commande distante ;
* <code>-L</code> : crée une redirection locale ;
* <code>127.0.0.1:15000</code> : adresse et port d'entrée sur la machine cliente ;
* <code>127.0.0.1:5000</code> : service de destination vu depuis <code>tas</code> ;
* <code>ExitOnForwardFailure=yes</code> : arrête immédiatement SSH si le tunnel ne peut pas être créé.

Si la clé n'est pas sélectionnée automatiquement, préciser son chemin :

<syntaxhighlight lang="bash">
ssh \
-i ~/.ssh/id_rsa_user \
-N \
-o ExitOnForwardFailure=yes \
-L 127.0.0.1:15000:127.0.0.1:5000 \
loic@tas
</syntaxhighlight>

Le préfixe local <code>127.0.0.1:</code> empêche les autres machines du réseau d'utiliser ce tunnel.

== Vérifier l'accès HTTP ==

Dans un second terminal sur la machine cliente :

<syntaxhighlight lang="bash">
curl --fail --show-error \
-o /dev/null \
-w 'HTTP %{http_code} | %{content_type}\n' \
http://127.0.0.1:15000/
</syntaxhighlight>

Réponse attendue :

<pre>
HTTP 200 | text/html; charset=utf-8
</pre>

Pour ouvrir la page manuellement, utiliser dans le navigateur de la machine cliente :

<pre>
http://127.0.0.1:15000/
</pre>

== Capturer la page avec Chromium ==

Avec Google Chrome :

<syntaxhighlight lang="bash">
google-chrome \
--headless \
--disable-gpu \
--screenshot="$PWD/hermes-ai-tester-home.png" \
--window-size=1440,1100 \
http://127.0.0.1:15000/
</syntaxhighlight>

Avec Chromium, remplacer simplement <code>google-chrome</code> par <code>chromium</code> ou <code>chromium-browser</code> selon la distribution.

Vérifier ensuite le fichier :

<syntaxhighlight lang="bash">
file "$PWD/hermes-ai-tester-home.png"
</syntaxhighlight>

== Envoyer la capture dans Telegram avec OpenClaw ==

Remplacer <code>IDENTIFIANT_DU_CHAT</code> par l'identifiant du chat Telegram destinataire :

<syntaxhighlight lang="bash">
openclaw message send \
--channel telegram \
--target 'IDENTIFIANT_DU_CHAT' \
--message 'Capture de la page d’accueil AI Tester via tunnel SSH.' \
--media "$PWD/hermes-ai-tester-home.png"
</syntaxhighlight>

Cette commande envoie un fichier existant. Elle ne lance pas de modèle de langage.

Pour vérifier la commande sans envoyer de message :

<syntaxhighlight lang="bash">
openclaw message send \
--dry-run \
--channel telegram \
--target 'IDENTIFIANT_DU_CHAT' \
--message 'Capture de test.' \
--media "$PWD/hermes-ai-tester-home.png"
</syntaxhighlight>

== Fermer le tunnel ==

Revenir dans le premier terminal et presser <code>Ctrl+C</code>. Le port local <code>15000</code> est alors libéré.

Vérification facultative :

<syntaxhighlight lang="bash">
curl --max-time 2 http://127.0.0.1:15000/
</syntaxhighlight>

Après fermeture, cette commande doit échouer avec une erreur de connexion.

== Dépannage ==

=== Le port local 15000 est déjà occupé ===

Choisir un autre port d'entrée, par exemple <code>15001</code>, dans la commande SSH et dans toutes les URL locales.

=== SSH affiche « No route to host » ===

Vérifier la résolution de <code>tas</code>, sa route réseau, son adresse IP et l'accessibilité du port SSH :

<syntaxhighlight lang="bash">
getent hosts tas
ssh -v loic@tas
</syntaxhighlight>

=== SSH affiche « Permission denied (publickey) » ===

Vérifier le compte distant, le chemin de la clé et la présence de sa clé publique dans <code>~/.ssh/authorized_keys</code> sur <code>tas</code>.

=== curl renvoie « Connection refused » ===

Le tunnel peut être établi alors que le service cible ne fonctionne pas. Depuis <code>tas</code>, contrôler directement :

<syntaxhighlight lang="bash">
curl -I http://127.0.0.1:5000/
</syntaxhighlight>

=== Précautions de sécurité ===

* conserver l'écoute locale du tunnel sur <code>127.0.0.1</code> ;
* ne pas publier directement AI Tester sur Internet ;
* ne pas exposer un serveur Flask/Werkzeug de développement sans authentification ni reverse proxy adapté ;
* vérifier le destinataire avant d'utiliser <code>openclaw message send</code> sans <code>--dry-run</code>.

== Résumé des commandes ==

<syntaxhighlight lang="bash">
# Terminal 1 : tunnel
ssh -N -o ExitOnForwardFailure=yes \
-L 127.0.0.1:15000:127.0.0.1:5000 loic@tas

# Terminal 2 : test
curl --fail --show-error -o /dev/null \
-w 'HTTP %{http_code} | %{content_type}\n' \
http://127.0.0.1:15000/

# Capture
google-chrome --headless --disable-gpu \
--screenshot="$PWD/hermes-ai-tester-home.png" \
--window-size=1440,1100 \
http://127.0.0.1:15000/

# Envoi Telegram
openclaw message send \
--channel telegram \
--target 'IDENTIFIANT_DU_CHAT' \
--message 'Capture AI Tester via tunnel SSH.' \
--media "$PWD/hermes-ai-tester-home.png"
</syntaxhighlight>

[[Category:SSH]]
[[Category:OpenClaw]]
[[Category:Hermes]]

Trace install tas - Hermes Agent

2026-07-16T21:22:07Z

Daneel : Documente le port local 5000 et le tunnel SSH pour AI Tester

= Trace install tas - Hermes Agent =

== Rôle ==
Agent IA outillé exposé via sa gateway de messagerie, avec état persistant sur disque dédié.

== Statut opérationnel ==
Dernière mise à jour documentaire : '''16 juillet 2026'''.

Capacités actuellement actives et vérifiées :
* [x] gateway Telegram dédiée via `@LoicHermesBot`
* [x] modèle local Ollama via `gemma4:e4b-it-q8_0_128k`
* [x] outils fichiers / terminal / mémoire / délégation
* [x] browser local embarqué
* [x] `browser_cdp` via Chrome dédié `hermes-cdp.service`
* [x] `browser_dialog` via le même endpoint CDP
* [x] STT local et TTS Edge
* [x] `web_search` via backend `ddgs` sans clé API
* [x] `web_extract` via backend `tavily`

Capacités encore bloquées ou partielles :
* [ ] `image_generate`
* [ ] `read_terminal` et `close_terminal` hors application desktop Hermes
* [ ] `computer_use` dans ce gateway Telegram sans contexte desktop/X11

== Accès ==
* Local service : `127.0.0.1:8642`
* AI Tester local : `127.0.0.1:5000` lorsqu'une instance de l'application est lancée dans le conteneur
* Public HTTP : aucun par défaut
* Messagerie prévue : Telegram via un second bot dédié à créer

== Ports ==
* `8642` local uniquement
* `5000` local uniquement, publié par le Quadlet pour AI Tester ; aucun accès direct depuis le LAN ou Internet
* `9222` non publié ; accessible uniquement sur le réseau Podman privé `hermes-net`

== Accès temporaire à AI Tester ==
Le Quadlet publie `127.0.0.1:5000:5000`. L'application Flask doit néanmoins être lancée dans le conteneur :
* `podman exec -d --user hermes --workdir /opt/data/ai-tester hermes uv run flask --app ai_tester.web run --host 0.0.0.0 --port 5000`
* contrôle depuis `tas` : `curl -I http://127.0.0.1:5000/`

Depuis une autre machine disposant d'un accès SSH à `tas` :
* ouvrir le tunnel : `ssh -L 5000:127.0.0.1:5000 tas`
* consulter ensuite `http://127.0.0.1:5000` dans le navigateur local

Le serveur Werkzeug utilisé est un serveur de développement sans protection adaptée à une exposition publique. Ne pas publier ce port sur `0.0.0.0` et ne pas l'ajouter directement à Caddy. Le processus Flask lancé avec `podman exec -d` n'est pas persistant et disparaît lors d'une recréation de `hermes.service`.

== Exécution / runtime ==
Quadlets systemd user : `hermes.container` et `hermes-cdp.container` ; unités générées : `hermes.service` et `hermes-cdp.service`.

Réseau privé :
* unité idempotente `hermes-network.service`
* réseau CNI `hermes-net` sur `10.89.12.0/24`
* IP CDP réservée : `10.89.12.2`
* les cycles de vie Hermes et CDP sont indépendants

Commande de démarrage :
* `gateway run`

Image :
* `docker.io/nousresearch/hermes-agent:latest`

== Chemins de configuration ==
* `/home/loic/.config/containers/systemd/hermes.container`
* `/home/loic/.config/containers/systemd/hermes-cdp.container`
* `/home/loic/.config/systemd/user/hermes-network.service`
* `/home/loic/hermes-config/hermes.env`
* `/media/loic/nem/hermes/config.yaml`

Sources de vérité :
* le quadlet gère le runtime Podman rootless
* `hermes.env` porte les secrets / variables Telegram
* `config.yaml` porte la configuration non secrète Hermes

== Exploitation courante ==
Toutes les commandes ci-dessous sont exécutées avec le compte utilisateur `loic` ; ne pas ajouter `sudo` aux commandes `systemctl --user` ou `podman`.

=== Appliquer une modification de configuration ===
Après sauvegarde préalable du fichier concerné :
* modification de `config.yaml` ou `hermes.env` : `systemctl --user restart hermes.service`
* modification d'un fichier Quadlet `.container` : `systemctl --user daemon-reload`, puis redémarrer uniquement le service concerné
* vérifier ensuite : `systemctl --user is-active hermes.service hermes-cdp.service hermes-network.service`

=== Démarrage ===
* démarrer le réseau privé : `systemctl --user start hermes-network.service`
* démarrer Hermes : `systemctl --user start hermes.service`
* démarrer CDP : `systemctl --user start hermes-cdp.service`
* démarrage groupé : `systemctl --user start hermes-network.service hermes.service hermes-cdp.service`

=== Arrêt ===
* arrêt normal complet : `systemctl --user stop hermes-cdp.service hermes.service`
* il n'est normalement pas nécessaire d'arrêter `hermes-network.service`; le réseau persiste volontairement
* ne pas supprimer manuellement le conteneur `hermes` tant qu'un ancien conteneur utilisant `--network container:hermes` existe encore

=== Redémarrage ===
* redémarrer Hermes seul : `systemctl --user restart hermes.service`
* redémarrer Chrome CDP seul : `systemctl --user restart hermes-cdp.service`
* le redémarrage de l'un ne doit pas redémarrer ni bloquer l'autre
* après modification des Quadlets : `systemctl --user daemon-reload && systemctl --user restart hermes.service hermes-cdp.service`

=== État et journaux ===
* état synthétique : `systemctl --user is-active hermes-network.service hermes.service hermes-cdp.service`
* état détaillé Hermes : `systemctl --user status hermes.service --no-pager -l`
* état détaillé CDP : `systemctl --user status hermes-cdp.service --no-pager -l`
* logs Hermes : `journalctl --user -u hermes.service -n 100 --no-pager`
* logs CDP : `journalctl --user -u hermes-cdp.service -n 100 --no-pager`
* suivre les logs : `journalctl --user -f -u hermes.service -u hermes-cdp.service`
* état Podman : `podman ps --filter name=hermes`

=== Contrôles de santé ===
* vérifier le port local Hermes : `ss -ltn | rg ':8642'`
* vérifier CDP depuis Hermes : `podman exec hermes curl -fsS http://10.89.12.2:9222/json/version`
* la réponse CDP doit contenir `webSocketDebuggerUrl`
* vérifier que CDP n'est pas publié sur l'hôte : <nowiki>`podman inspect hermes-cdp --format '{{json .NetworkSettings.Ports}}'`</nowiki>
* vérifier l'IP privée CDP : <nowiki>`podman inspect hermes-cdp --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'`</nowiki>

=== Mise à jour des images ===
* simulation : `podman auto-update --dry-run`
* mise à jour gérée : `systemctl --user start podman-auto-update.service`
* contrôler ensuite les trois services et les journaux
* sur Podman 4.6.2, si le dry-run mentionne un ancien ID absent, vérifier d'abord `podman ps -a` et l'état des services ; ne pas supprimer les données persistantes

=== Sauvegarde avant intervention ===
* Quadlets : `/home/loic/.config/containers/systemd/hermes.container` et `/home/loic/.config/containers/systemd/hermes-cdp.container`
* réseau : `/home/loic/.config/systemd/user/hermes-network.service`
* environnement : `/home/loic/hermes-config/hermes.env`
* configuration et données : `/media/loic/nem/hermes`
* conserver les sauvegardes hors du répertoire remplacé, par exemple dans `/home/loic/backups`

=== Retour arrière ===
* arrêter `hermes-cdp.service` puis `hermes.service`
* restaurer les fichiers sauvegardés sans supprimer `/media/loic/nem/hermes`
* exécuter `systemctl --user daemon-reload`
* redémarrer dans l'ordre réseau, Hermes, puis CDP
* vérifier les journaux et `/json/version` avant de conclure

== Volumes / persistance ==
* `/media/loic/nem/hermes:/opt/data`

Contenu notable dans la persistance :
* `config.yaml`
* historiques / sessions Hermes
* mémoire et skills synchronisés par Hermes

== Dépendances ==
* Podman rootless
* Ollama local via `http://host.containers.internal:11434/v1`
* second bot Telegram dédié avec token distinct de l'instance OpenClaw existante
* package Python `ddgs` installé via `hermes tools post-setup ddgs` le `13 juillet 2026`
* clé API Tavily injectée via `hermes.env` le `13 juillet 2026`
* service `hermes-cdp.service` indépendant, relié à Hermes par `hermes-net` depuis le `16 juillet 2026`

== Modèle LLM principal ==
Configuration Hermes actuellement retenue :
* provider : `custom`
* backend : API Ollama locale sur `http://host.containers.internal:11434/v1`
* modèle par défaut : `gemma4:e4b-it-q8_0_128k`
* contexte cible : `131072` tokens

== Outils et backends activés ==
Activation explicite actuellement retenue dans `config.yaml` :
* `web.search_backend: ddgs`
* `web.extract_backend: tavily`
* `browser.cdp_url: http://10.89.12.2:9222`

Conséquences :
* `web_search` devient disponible sans clé API
* `web_extract` devient disponible via Tavily pour les URLs HTTP/HTTPS et le rendu markdown
* `browser_cdp` et `browser_dialog` deviennent disponibles sans exposer CDP sur le réseau hôte

Backends non activés à ce stade :
* aucun backend `image_gen`

== Intégration Telegram préparée ==
Configuration locale maintenant active :
* fichier dédié : `/home/loic/hermes-config/hermes.env`
* allowlist utilisateur configurée sur l'identifiant Telegram de Loïc : `5910858583`
* canal home Telegram préparé sur `5910858583`
* bot dédié configuré : `@LoicHermesBot`

Important :
* le token du bot dédié est maintenant renseigné dans `hermes.env`
* il faut un bot distinct de `@LoicBoBBot` pour éviter le conflit `getUpdates` avec OpenClaw

Variables prévues dans `hermes.env` :
* `TELEGRAM_ALLOWED_USERS=5910858583`
* `TELEGRAM_HOME_CHANNEL=5910858583`
* `TELEGRAM_BOT_TOKEN=...` configuré pour `@LoicHermesBot`
* `TAVILY_API_KEY=...` configurée sans etre documentée en clair dans cette page

== Procédure pour finaliser le second bot ==
Bot dédié déjà créé et validé :
* nom : `Hermes`
* username : `@LoicHermesBot`

Pour refaire la procédure sur une autre instance :
* créer un bot dédié via `@BotFather`
* renseigner `TELEGRAM_BOT_TOKEN` dans `/home/loic/hermes-config/hermes.env`
* `systemctl --user daemon-reload`
* `systemctl --user restart hermes.service`
* vérifier `journalctl --user -u hermes.service -n 100 --no-pager`

== Procédure de relance / diagnostic ==
Commandes utiles :
* `systemctl --user status hermes.service --no-pager -l`
* `systemctl --user status hermes-cdp.service --no-pager -l`
* `systemctl --user restart hermes.service`
* `systemctl --user restart hermes-cdp.service`
* `journalctl --user -u hermes.service -n 100 --no-pager`
* `journalctl --user -u hermes-cdp.service -n 100 --no-pager`
* `ss -ltn | rg 8642`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.web_tools import check_web_api_key; print(check_web_api_key())"`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.web_tools import _get_search_backend,_get_extract_backend; print(_get_search_backend(), _get_extract_backend())"`
* `podman exec hermes curl -fsS http://10.89.12.2:9222/json/version`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.browser_cdp_tool import _browser_cdp_check; print(_browser_cdp_check())"`

Interprétation rapide :
* si le service tourne mais logue `No messaging platforms enabled`, le token Telegram n'est pas encore actif
* si le service refuse de démarrer après ajout du token, vérifier d'abord le format du token et l'unicité du bot
* si un conflit de token apparaît, s'assurer que le bot Hermes n'est pas le même que celui d'OpenClaw
* si Telegram est bien pris en compte, les logs montrent une phase de connexion du type `Connecting to Telegram`
* si `check_web_api_key()` renvoie `True` avec `search_provider=ddgs` et `extract_provider=tavily`, la recherche et l'extraction web sont activées
* si `curl http://10.89.12.2:9222/json/version` renvoie un `webSocketDebuggerUrl` depuis le conteneur Hermes, la cible CDP est joignable
* ne pas rétablir `--network container:hermes` : un conteneur CDP dépendant empêcherait Podman de recréer Hermes lors d'une mise à jour
* si `_browser_cdp_check()` renvoie `True`, `browser_cdp` et `browser_dialog` doivent etre exposes par Hermes

== Plan d'activation des potentiels ==
Checklist de suivi :
* [x] sécuriser le runtime rootless + backups de config
* [x] activer Telegram dédié
* [x] basculer sur le modèle local `gemma4:e4b-it-q8_0_128k`
* [x] activer `web_search` gratuit via `ddgs`
* [x] choisir et brancher un backend `web_extract`
* [x] fournir un endpoint CDP persistant pour `browser_cdp`
* [ ] choisir et brancher un backend `image_generate`
* [ ] décider si un contexte desktop dédié doit être exposé à Hermes

Intervention attendue de Loïc pour débloquer la suite :
* `image_generate` : fournir un provider et un secret ou une auth exploitable dans le conteneur (`OPENAI_API_KEY`, `FAL_KEY`, ou auth Codex dans Hermes)

== Données / emplacements à sauvegarder ==
* `/home/loic/.config/containers/systemd/hermes.container`
* `/home/loic/.config/containers/systemd/hermes-cdp.container`
* `/home/loic/.config/systemd/user/hermes-network.service`
* `/home/loic/hermes-config/hermes.env`
* `/media/loic/nem/hermes`

== Sauvegarde ==
Avant modification de la config critique :
* sauvegarder le quadlet Hermes
* sauvegarder `hermes.env`
* sauvegarder la persistance `/media/loic/nem/hermes`

== Restauration ==
* restaurer `hermes.container`
* restaurer `hermes.env`
* restaurer `/media/loic/nem/hermes`
* recharger systemd user
* relancer `hermes.service`

== Rollback ==
Si l'intégration Telegram du second bot casse Hermes :
* recommenter `TELEGRAM_BOT_TOKEN` dans `/home/loic/hermes-config/hermes.env`
* redémarrer `hermes.service`
* revenir au backup du quadlet si nécessaire

== Maintenance documentaire ==
Lors d'un changement d'image, de provider LLM, de chemin de persistance, de port local, de bot Telegram ou de stratégie d'allowlist, mettre à jour cette page et la trace centrale.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Utiliser les chats Hermes et OpenClaw en ligne de commande

2026-07-16T18:05:53Z

Daneel : Création du guide CLI Hermes et OpenClaw avec sélection explicite de modèle

{{DISPLAYTITLE:Utiliser les chats Hermes et OpenClaw en ligne de commande}}

Ce guide décrit les commandes de consultation et de reprise de conversation pour Hermes Agent et OpenClaw sur la machine ''tas''.

Dernière vérification : 16 juillet 2026, avec Hermes dans le conteneur Podman <code>hermes</code> et OpenClaw 2026.7.1.

__TOC__

== Différence entre <code>hermes -z</code> et <code>hermes chat</code> ==

Hermes propose deux modes non interactifs principaux :

* <code>hermes -z "..."</code> : appel ponctuel destiné aux scripts, avec uniquement la réponse finale sur la sortie standard ;
* <code>hermes chat -q "..."</code> : tour de chat complet, capable de créer ou reprendre une session et offrant davantage de contrôles.

L'option <code>-z</code> contourne automatiquement les demandes d'approbation. Elle doit donc rester réservée aux demandes textuelles bornées, sans action sensible. Pour utiliser des outils, conserver un historique ou reprendre une conversation, préférer <code>hermes chat</code>.

== Requêter Hermes ==

=== Question ponctuelle sans action ===

<syntaxhighlight lang="bash">
podman exec hermes hermes -z \
"Définis Podman Quadlet en trois phrases, sans utiliser d'outil."
</syntaxhighlight>

Ne pas employer cette forme pour une consigne susceptible de modifier des fichiers, d'exécuter une commande dangereuse ou d'envoyer un message.

=== Requête contrôlée dans une session distincte ===

<syntaxhighlight lang="bash">
podman exec hermes hermes chat \
--query "Analyse cette architecture sans rien modifier." \
--quiet \
--source tool \
--max-turns 5
</syntaxhighlight>

* <code>--quiet</code> réduit l'affichage aux résultats utiles ;
* <code>--source tool</code> identifie la session comme un appel programmatique ;
* <code>--max-turns 5</code> borne le nombre d'itérations de l'agent.

=== Conversation interactive dans le terminal ===

<syntaxhighlight lang="bash">
podman exec -it hermes hermes chat --cli
</syntaxhighlight>

Pour utiliser l'interface moderne, remplacer <code>--cli</code> par <code>--tui</code>.

=== Choisir explicitement un modèle Hermes ===

L'exemple suivant force <code>gpt-5.6-sol</code> via le provider <code>openai-codex</code> uniquement pour cet appel :

<syntaxhighlight lang="bash">
podman exec hermes hermes chat \
--provider openai-codex \
--model 'gpt-5.6-sol' \
--query "Compare Docker et Podman, sans effectuer d'action." \
--quiet \
--source tool
</syntaxhighlight>

Pour forcer à la place le modèle Ollama local de secours :

<syntaxhighlight lang="bash">
podman exec hermes hermes chat \
--provider custom \
--model 'gemma4:e4b-it-q8_0_128k' \
--query "Compare Docker et Podman, sans effectuer d'action." \
--quiet \
--source tool
</syntaxhighlight>

Ces choix temporaires ne modifient pas le modèle configuré par défaut.

== Reprendre le chat Hermes utilisé par Telegram ==

=== Retrouver la session Telegram ===

<syntaxhighlight lang="bash">
podman exec hermes hermes sessions list --source telegram --limit 10
</syntaxhighlight>

La colonne <code>ID</code> fournit l'identifiant à passer à <code>--resume</code>. Toujours relire la liste avant usage afin de sélectionner la bonne conversation.

=== Reprendre le contexte depuis le terminal ===

Mode interactif :

<syntaxhighlight lang="bash">
podman exec -it hermes hermes chat \
--resume ID_DE_SESSION \
--cli
</syntaxhighlight>

Tour unique :

<syntaxhighlight lang="bash">
podman exec hermes hermes chat \
--resume ID_DE_SESSION \
--query "Poursuis l'analyse précédente sans rien modifier." \
--quiet
</syntaxhighlight>

<code>--resume</code> recharge le contexte de la conversation Telegram, mais une réponse produite par la CLI reste affichée dans le terminal. Elle n'est pas publiée automatiquement dans Telegram.

=== Envoyer explicitement un texte dans Telegram ===

Après validation humaine du texte :

<syntaxhighlight lang="bash">
podman exec hermes hermes send \
--to telegram \
"Texte validé à publier dans le chat Telegram."
</syntaxhighlight>

<code>hermes send</code> ne lance aucun LLM : la commande livre seulement le texte fourni. Pour poursuivre naturellement le contexte et recevoir la réponse dans Telegram, la méthode la plus simple reste d'écrire directement à <code>@LoicHermesBot</code>.

== Commandes équivalentes avec OpenClaw ==

=== Tour ponctuel sans livraison externe ===

<syntaxhighlight lang="bash">
openclaw agent \
--agent main \
--session-key agent:main:consultation-cli \
--message "Définis Podman Quadlet en trois phrases." \
--json
</syntaxhighlight>

Sans <code>--deliver</code>, le résultat revient dans le terminal et n'est pas envoyé dans Telegram.

=== Choisir explicitement un modèle OpenClaw ===

Le modèle doit être un identifiant présent dans <code>openclaw models list</code>. Exemple :

<syntaxhighlight lang="bash">
openclaw agent \
--agent main \
--session-key agent:main:consultation-gpt54 \
--model 'openai/gpt-5.4' \
--message "Compare Docker et Podman en cinq points." \
--json
</syntaxhighlight>

Cette surcharge vaut pour ce tour ; elle ne change pas la configuration globale. Si l'identifiant n'est pas disponible dans l'installation, le remplacer par une valeur effectivement affichée par :

<syntaxhighlight lang="bash">
openclaw models list
</syntaxhighlight>

=== Lister et reprendre une session ===

<syntaxhighlight lang="bash">
openclaw sessions --agent main --limit 20
</syntaxhighlight>

Reprise par clé :

<syntaxhighlight lang="bash">
openclaw agent \
--session-key 'CLE_DE_SESSION' \
--message "Poursuis l'analyse précédente." \
--json
</syntaxhighlight>

Reprise par identifiant :

<syntaxhighlight lang="bash">
openclaw agent \
--session-id 'ID_DE_SESSION' \
--message "Poursuis l'analyse précédente." \
--json
</syntaxhighlight>

=== Interface terminal ===

<syntaxhighlight lang="bash">
openclaw tui --session 'CLE_DE_SESSION'
</syntaxhighlight>

Ajouter <code>--deliver</code> uniquement si les réponses doivent être livrées au canal externe associé à la session.

=== Répondre dans une conversation Telegram OpenClaw ===

Retrouver d'abord la session :

<syntaxhighlight lang="bash">
openclaw sessions --agent main --json
</syntaxhighlight>

Puis lancer le tour sur sa clé exacte avec livraison explicite :

<syntaxhighlight lang="bash">
openclaw agent \
--session-key 'CLE_DE_SESSION_TELEGRAM' \
--message "Poursuis notre échange précédent." \
--channel telegram \
--deliver
</syntaxhighlight>

Pour imposer une destination de réponse distincte :

<syntaxhighlight lang="bash">
openclaw agent \
--session-key 'CLE_DE_SESSION_TELEGRAM' \
--message "Prépare puis envoie la réponse." \
--deliver \
--reply-channel telegram \
--reply-to 'IDENTIFIANT_DU_CHAT'
</syntaxhighlight>

=== Envoyer un texte sans appeler le LLM ===

<syntaxhighlight lang="bash">
openclaw message send \
--channel telegram \
--target 'IDENTIFIANT_DU_CHAT' \
--message "Texte déjà validé."
</syntaxhighlight>

Cette commande livre un texte existant ; elle ne lance pas de tour d'agent.

== Correspondances rapides ==

{| class="wikitable"
! Besoin
! Hermes
! OpenClaw
|-
| Question ponctuelle
| <code>hermes -z "..."</code>
| <code>openclaw agent --message "..."</code>
|-
| Tour contrôlé
| <code>hermes chat -q "..."</code>
| <code>openclaw agent --message "..."</code>
|-
| Lister les sessions
| <code>hermes sessions list</code>
| <code>openclaw sessions</code>
|-
| Reprendre une session
| <code>hermes chat --resume ID</code>
| <code>openclaw agent --session-key CLE</code>
|-
| Terminal interactif
| <code>hermes chat --resume ID --cli</code>
| <code>openclaw tui --session CLE</code>
|-
| Envoyer sans LLM
| <code>hermes send --to telegram</code>
| <code>openclaw message send --channel telegram</code>
|}

== Précautions ==

# Ne jamais ajouter <code>--yolo</code> pour une simple consultation Hermes.
# Réserver <code>hermes -z</code> aux questions sans effet de bord.
# Utiliser <code>--source tool</code> pour isoler les appels programmatiques Hermes.
# Vérifier l'identifiant de session avant toute reprise.
# Avec OpenClaw, omettre <code>--deliver</code> tant que la réponse ne doit pas quitter le terminal.
# Relire tout contenu avant d'utiliser <code>hermes send</code>, <code>openclaw agent --deliver</code> ou <code>openclaw message send</code>.

== Voir aussi ==

* [[Trace install tas - Hermes Agent]]
* [[Trace install tas]]

Trace install tas - Hermes Agent

2026-07-16T09:46:51Z

Daneel : Correction rendu commandes podman inspect

= Trace install tas - Hermes Agent =

== Rôle ==
Agent IA outillé exposé via sa gateway de messagerie, avec état persistant sur disque dédié.

== Statut opérationnel ==
Dernière mise à jour documentaire : '''16 juillet 2026'''.

Capacités actuellement actives et vérifiées :
* [x] gateway Telegram dédiée via `@LoicHermesBot`
* [x] modèle local Ollama via `gemma4:e4b-it-q8_0_128k`
* [x] outils fichiers / terminal / mémoire / délégation
* [x] browser local embarqué
* [x] `browser_cdp` via Chrome dédié `hermes-cdp.service`
* [x] `browser_dialog` via le même endpoint CDP
* [x] STT local et TTS Edge
* [x] `web_search` via backend `ddgs` sans clé API
* [x] `web_extract` via backend `tavily`

Capacités encore bloquées ou partielles :
* [ ] `image_generate`
* [ ] `read_terminal` et `close_terminal` hors application desktop Hermes
* [ ] `computer_use` dans ce gateway Telegram sans contexte desktop/X11

== Accès ==
* Local service : `127.0.0.1:8642`
* Public HTTP : aucun par défaut
* Messagerie prévue : Telegram via un second bot dédié à créer

== Ports ==
* `8642` local uniquement
* `9222` non publié ; accessible uniquement sur le réseau Podman privé `hermes-net`

== Exécution / runtime ==
Quadlets systemd user : `hermes.container` et `hermes-cdp.container` ; unités générées : `hermes.service` et `hermes-cdp.service`.

Réseau privé :
* unité idempotente `hermes-network.service`
* réseau CNI `hermes-net` sur `10.89.12.0/24`
* IP CDP réservée : `10.89.12.2`
* les cycles de vie Hermes et CDP sont indépendants

Commande de démarrage :
* `gateway run`

Image :
* `docker.io/nousresearch/hermes-agent:latest`

== Chemins de configuration ==
* `/home/loic/.config/containers/systemd/hermes.container`
* `/home/loic/.config/containers/systemd/hermes-cdp.container`
* `/home/loic/.config/systemd/user/hermes-network.service`
* `/home/loic/hermes-config/hermes.env`
* `/media/loic/nem/hermes/config.yaml`

Sources de vérité :
* le quadlet gère le runtime Podman rootless
* `hermes.env` porte les secrets / variables Telegram
* `config.yaml` porte la configuration non secrète Hermes

== Exploitation courante ==
Toutes les commandes ci-dessous sont exécutées avec le compte utilisateur `loic` ; ne pas ajouter `sudo` aux commandes `systemctl --user` ou `podman`.

=== Appliquer une modification de configuration ===
Après sauvegarde préalable du fichier concerné :
* modification de `config.yaml` ou `hermes.env` : `systemctl --user restart hermes.service`
* modification d'un fichier Quadlet `.container` : `systemctl --user daemon-reload`, puis redémarrer uniquement le service concerné
* vérifier ensuite : `systemctl --user is-active hermes.service hermes-cdp.service hermes-network.service`

=== Démarrage ===
* démarrer le réseau privé : `systemctl --user start hermes-network.service`
* démarrer Hermes : `systemctl --user start hermes.service`
* démarrer CDP : `systemctl --user start hermes-cdp.service`
* démarrage groupé : `systemctl --user start hermes-network.service hermes.service hermes-cdp.service`

=== Arrêt ===
* arrêt normal complet : `systemctl --user stop hermes-cdp.service hermes.service`
* il n'est normalement pas nécessaire d'arrêter `hermes-network.service`; le réseau persiste volontairement
* ne pas supprimer manuellement le conteneur `hermes` tant qu'un ancien conteneur utilisant `--network container:hermes` existe encore

=== Redémarrage ===
* redémarrer Hermes seul : `systemctl --user restart hermes.service`
* redémarrer Chrome CDP seul : `systemctl --user restart hermes-cdp.service`
* le redémarrage de l'un ne doit pas redémarrer ni bloquer l'autre
* après modification des Quadlets : `systemctl --user daemon-reload && systemctl --user restart hermes.service hermes-cdp.service`

=== État et journaux ===
* état synthétique : `systemctl --user is-active hermes-network.service hermes.service hermes-cdp.service`
* état détaillé Hermes : `systemctl --user status hermes.service --no-pager -l`
* état détaillé CDP : `systemctl --user status hermes-cdp.service --no-pager -l`
* logs Hermes : `journalctl --user -u hermes.service -n 100 --no-pager`
* logs CDP : `journalctl --user -u hermes-cdp.service -n 100 --no-pager`
* suivre les logs : `journalctl --user -f -u hermes.service -u hermes-cdp.service`
* état Podman : `podman ps --filter name=hermes`

=== Contrôles de santé ===
* vérifier le port local Hermes : `ss -ltn | rg ':8642'`
* vérifier CDP depuis Hermes : `podman exec hermes curl -fsS http://10.89.12.2:9222/json/version`
* la réponse CDP doit contenir `webSocketDebuggerUrl`
* vérifier que CDP n'est pas publié sur l'hôte : <nowiki>`podman inspect hermes-cdp --format '{{json .NetworkSettings.Ports}}'`</nowiki>
* vérifier l'IP privée CDP : <nowiki>`podman inspect hermes-cdp --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'`</nowiki>

=== Mise à jour des images ===
* simulation : `podman auto-update --dry-run`
* mise à jour gérée : `systemctl --user start podman-auto-update.service`
* contrôler ensuite les trois services et les journaux
* sur Podman 4.6.2, si le dry-run mentionne un ancien ID absent, vérifier d'abord `podman ps -a` et l'état des services ; ne pas supprimer les données persistantes

=== Sauvegarde avant intervention ===
* Quadlets : `/home/loic/.config/containers/systemd/hermes.container` et `/home/loic/.config/containers/systemd/hermes-cdp.container`
* réseau : `/home/loic/.config/systemd/user/hermes-network.service`
* environnement : `/home/loic/hermes-config/hermes.env`
* configuration et données : `/media/loic/nem/hermes`
* conserver les sauvegardes hors du répertoire remplacé, par exemple dans `/home/loic/backups`

=== Retour arrière ===
* arrêter `hermes-cdp.service` puis `hermes.service`
* restaurer les fichiers sauvegardés sans supprimer `/media/loic/nem/hermes`
* exécuter `systemctl --user daemon-reload`
* redémarrer dans l'ordre réseau, Hermes, puis CDP
* vérifier les journaux et `/json/version` avant de conclure

== Volumes / persistance ==
* `/media/loic/nem/hermes:/opt/data`

Contenu notable dans la persistance :
* `config.yaml`
* historiques / sessions Hermes
* mémoire et skills synchronisés par Hermes

== Dépendances ==
* Podman rootless
* Ollama local via `http://host.containers.internal:11434/v1`
* second bot Telegram dédié avec token distinct de l'instance OpenClaw existante
* package Python `ddgs` installé via `hermes tools post-setup ddgs` le `13 juillet 2026`
* clé API Tavily injectée via `hermes.env` le `13 juillet 2026`
* service `hermes-cdp.service` indépendant, relié à Hermes par `hermes-net` depuis le `16 juillet 2026`

== Modèle LLM principal ==
Configuration Hermes actuellement retenue :
* provider : `custom`
* backend : API Ollama locale sur `http://host.containers.internal:11434/v1`
* modèle par défaut : `gemma4:e4b-it-q8_0_128k`
* contexte cible : `131072` tokens

== Outils et backends activés ==
Activation explicite actuellement retenue dans `config.yaml` :
* `web.search_backend: ddgs`
* `web.extract_backend: tavily`
* `browser.cdp_url: http://10.89.12.2:9222`

Conséquences :
* `web_search` devient disponible sans clé API
* `web_extract` devient disponible via Tavily pour les URLs HTTP/HTTPS et le rendu markdown
* `browser_cdp` et `browser_dialog` deviennent disponibles sans exposer CDP sur le réseau hôte

Backends non activés à ce stade :
* aucun backend `image_gen`

== Intégration Telegram préparée ==
Configuration locale maintenant active :
* fichier dédié : `/home/loic/hermes-config/hermes.env`
* allowlist utilisateur configurée sur l'identifiant Telegram de Loïc : `5910858583`
* canal home Telegram préparé sur `5910858583`
* bot dédié configuré : `@LoicHermesBot`

Important :
* le token du bot dédié est maintenant renseigné dans `hermes.env`
* il faut un bot distinct de `@LoicBoBBot` pour éviter le conflit `getUpdates` avec OpenClaw

Variables prévues dans `hermes.env` :
* `TELEGRAM_ALLOWED_USERS=5910858583`
* `TELEGRAM_HOME_CHANNEL=5910858583`
* `TELEGRAM_BOT_TOKEN=...` configuré pour `@LoicHermesBot`
* `TAVILY_API_KEY=...` configurée sans etre documentée en clair dans cette page

== Procédure pour finaliser le second bot ==
Bot dédié déjà créé et validé :
* nom : `Hermes`
* username : `@LoicHermesBot`

Pour refaire la procédure sur une autre instance :
* créer un bot dédié via `@BotFather`
* renseigner `TELEGRAM_BOT_TOKEN` dans `/home/loic/hermes-config/hermes.env`
* `systemctl --user daemon-reload`
* `systemctl --user restart hermes.service`
* vérifier `journalctl --user -u hermes.service -n 100 --no-pager`

== Procédure de relance / diagnostic ==
Commandes utiles :
* `systemctl --user status hermes.service --no-pager -l`
* `systemctl --user status hermes-cdp.service --no-pager -l`
* `systemctl --user restart hermes.service`
* `systemctl --user restart hermes-cdp.service`
* `journalctl --user -u hermes.service -n 100 --no-pager`
* `journalctl --user -u hermes-cdp.service -n 100 --no-pager`
* `ss -ltn | rg 8642`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.web_tools import check_web_api_key; print(check_web_api_key())"`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.web_tools import _get_search_backend,_get_extract_backend; print(_get_search_backend(), _get_extract_backend())"`
* `podman exec hermes curl -fsS http://10.89.12.2:9222/json/version`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.browser_cdp_tool import _browser_cdp_check; print(_browser_cdp_check())"`

Interprétation rapide :
* si le service tourne mais logue `No messaging platforms enabled`, le token Telegram n'est pas encore actif
* si le service refuse de démarrer après ajout du token, vérifier d'abord le format du token et l'unicité du bot
* si un conflit de token apparaît, s'assurer que le bot Hermes n'est pas le même que celui d'OpenClaw
* si Telegram est bien pris en compte, les logs montrent une phase de connexion du type `Connecting to Telegram`
* si `check_web_api_key()` renvoie `True` avec `search_provider=ddgs` et `extract_provider=tavily`, la recherche et l'extraction web sont activées
* si `curl http://10.89.12.2:9222/json/version` renvoie un `webSocketDebuggerUrl` depuis le conteneur Hermes, la cible CDP est joignable
* ne pas rétablir `--network container:hermes` : un conteneur CDP dépendant empêcherait Podman de recréer Hermes lors d'une mise à jour
* si `_browser_cdp_check()` renvoie `True`, `browser_cdp` et `browser_dialog` doivent etre exposes par Hermes

== Plan d'activation des potentiels ==
Checklist de suivi :
* [x] sécuriser le runtime rootless + backups de config
* [x] activer Telegram dédié
* [x] basculer sur le modèle local `gemma4:e4b-it-q8_0_128k`
* [x] activer `web_search` gratuit via `ddgs`
* [x] choisir et brancher un backend `web_extract`
* [x] fournir un endpoint CDP persistant pour `browser_cdp`
* [ ] choisir et brancher un backend `image_generate`
* [ ] décider si un contexte desktop dédié doit être exposé à Hermes

Intervention attendue de Loïc pour débloquer la suite :
* `image_generate` : fournir un provider et un secret ou une auth exploitable dans le conteneur (`OPENAI_API_KEY`, `FAL_KEY`, ou auth Codex dans Hermes)

== Données / emplacements à sauvegarder ==
* `/home/loic/.config/containers/systemd/hermes.container`
* `/home/loic/.config/containers/systemd/hermes-cdp.container`
* `/home/loic/.config/systemd/user/hermes-network.service`
* `/home/loic/hermes-config/hermes.env`
* `/media/loic/nem/hermes`

== Sauvegarde ==
Avant modification de la config critique :
* sauvegarder le quadlet Hermes
* sauvegarder `hermes.env`
* sauvegarder la persistance `/media/loic/nem/hermes`

== Restauration ==
* restaurer `hermes.container`
* restaurer `hermes.env`
* restaurer `/media/loic/nem/hermes`
* recharger systemd user
* relancer `hermes.service`

== Rollback ==
Si l'intégration Telegram du second bot casse Hermes :
* recommenter `TELEGRAM_BOT_TOKEN` dans `/home/loic/hermes-config/hermes.env`
* redémarrer `hermes.service`
* revenir au backup du quadlet si nécessaire

== Maintenance documentaire ==
Lors d'un changement d'image, de provider LLM, de chemin de persistance, de port local, de bot Telegram ou de stratégie d'allowlist, mettre à jour cette page et la trace centrale.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - Hermes Agent

2026-07-16T09:46:07Z

Daneel : Documentation exploitation Hermes et migration CDP indépendante

= Trace install tas - Hermes Agent =

== Rôle ==
Agent IA outillé exposé via sa gateway de messagerie, avec état persistant sur disque dédié.

== Statut opérationnel ==
Dernière mise à jour documentaire : '''16 juillet 2026'''.

Capacités actuellement actives et vérifiées :
* [x] gateway Telegram dédiée via `@LoicHermesBot`
* [x] modèle local Ollama via `gemma4:e4b-it-q8_0_128k`
* [x] outils fichiers / terminal / mémoire / délégation
* [x] browser local embarqué
* [x] `browser_cdp` via Chrome dédié `hermes-cdp.service`
* [x] `browser_dialog` via le même endpoint CDP
* [x] STT local et TTS Edge
* [x] `web_search` via backend `ddgs` sans clé API
* [x] `web_extract` via backend `tavily`

Capacités encore bloquées ou partielles :
* [ ] `image_generate`
* [ ] `read_terminal` et `close_terminal` hors application desktop Hermes
* [ ] `computer_use` dans ce gateway Telegram sans contexte desktop/X11

== Accès ==
* Local service : `127.0.0.1:8642`
* Public HTTP : aucun par défaut
* Messagerie prévue : Telegram via un second bot dédié à créer

== Ports ==
* `8642` local uniquement
* `9222` non publié ; accessible uniquement sur le réseau Podman privé `hermes-net`

== Exécution / runtime ==
Quadlets systemd user : `hermes.container` et `hermes-cdp.container` ; unités générées : `hermes.service` et `hermes-cdp.service`.

Réseau privé :
* unité idempotente `hermes-network.service`
* réseau CNI `hermes-net` sur `10.89.12.0/24`
* IP CDP réservée : `10.89.12.2`
* les cycles de vie Hermes et CDP sont indépendants

Commande de démarrage :
* `gateway run`

Image :
* `docker.io/nousresearch/hermes-agent:latest`

== Chemins de configuration ==
* `/home/loic/.config/containers/systemd/hermes.container`
* `/home/loic/.config/containers/systemd/hermes-cdp.container`
* `/home/loic/.config/systemd/user/hermes-network.service`
* `/home/loic/hermes-config/hermes.env`
* `/media/loic/nem/hermes/config.yaml`

Sources de vérité :
* le quadlet gère le runtime Podman rootless
* `hermes.env` porte les secrets / variables Telegram
* `config.yaml` porte la configuration non secrète Hermes

== Exploitation courante ==
Toutes les commandes ci-dessous sont exécutées avec le compte utilisateur `loic` ; ne pas ajouter `sudo` aux commandes `systemctl --user` ou `podman`.

=== Appliquer une modification de configuration ===
Après sauvegarde préalable du fichier concerné :
* modification de `config.yaml` ou `hermes.env` : `systemctl --user restart hermes.service`
* modification d'un fichier Quadlet `.container` : `systemctl --user daemon-reload`, puis redémarrer uniquement le service concerné
* vérifier ensuite : `systemctl --user is-active hermes.service hermes-cdp.service hermes-network.service`

=== Démarrage ===
* démarrer le réseau privé : `systemctl --user start hermes-network.service`
* démarrer Hermes : `systemctl --user start hermes.service`
* démarrer CDP : `systemctl --user start hermes-cdp.service`
* démarrage groupé : `systemctl --user start hermes-network.service hermes.service hermes-cdp.service`

=== Arrêt ===
* arrêt normal complet : `systemctl --user stop hermes-cdp.service hermes.service`
* il n'est normalement pas nécessaire d'arrêter `hermes-network.service`; le réseau persiste volontairement
* ne pas supprimer manuellement le conteneur `hermes` tant qu'un ancien conteneur utilisant `--network container:hermes` existe encore

=== Redémarrage ===
* redémarrer Hermes seul : `systemctl --user restart hermes.service`
* redémarrer Chrome CDP seul : `systemctl --user restart hermes-cdp.service`
* le redémarrage de l'un ne doit pas redémarrer ni bloquer l'autre
* après modification des Quadlets : `systemctl --user daemon-reload && systemctl --user restart hermes.service hermes-cdp.service`

=== État et journaux ===
* état synthétique : `systemctl --user is-active hermes-network.service hermes.service hermes-cdp.service`
* état détaillé Hermes : `systemctl --user status hermes.service --no-pager -l`
* état détaillé CDP : `systemctl --user status hermes-cdp.service --no-pager -l`
* logs Hermes : `journalctl --user -u hermes.service -n 100 --no-pager`
* logs CDP : `journalctl --user -u hermes-cdp.service -n 100 --no-pager`
* suivre les logs : `journalctl --user -f -u hermes.service -u hermes-cdp.service`
* état Podman : `podman ps --filter name=hermes`

=== Contrôles de santé ===
* vérifier le port local Hermes : `ss -ltn | rg ':8642'`
* vérifier CDP depuis Hermes : `podman exec hermes curl -fsS http://10.89.12.2:9222/json/version`
* la réponse CDP doit contenir `webSocketDebuggerUrl`
* vérifier que CDP n'est pas publié sur l'hôte : `podman inspect hermes-cdp --format '{{json .NetworkSettings.Ports}}'`
* vérifier l'IP privée CDP : `podman inspect hermes-cdp --format '{{range .NetworkSettings.Networks}}{{.IPAddress}}{{end}}'`

=== Mise à jour des images ===
* simulation : `podman auto-update --dry-run`
* mise à jour gérée : `systemctl --user start podman-auto-update.service`
* contrôler ensuite les trois services et les journaux
* sur Podman 4.6.2, si le dry-run mentionne un ancien ID absent, vérifier d'abord `podman ps -a` et l'état des services ; ne pas supprimer les données persistantes

=== Sauvegarde avant intervention ===
* Quadlets : `/home/loic/.config/containers/systemd/hermes.container` et `/home/loic/.config/containers/systemd/hermes-cdp.container`
* réseau : `/home/loic/.config/systemd/user/hermes-network.service`
* environnement : `/home/loic/hermes-config/hermes.env`
* configuration et données : `/media/loic/nem/hermes`
* conserver les sauvegardes hors du répertoire remplacé, par exemple dans `/home/loic/backups`

=== Retour arrière ===
* arrêter `hermes-cdp.service` puis `hermes.service`
* restaurer les fichiers sauvegardés sans supprimer `/media/loic/nem/hermes`
* exécuter `systemctl --user daemon-reload`
* redémarrer dans l'ordre réseau, Hermes, puis CDP
* vérifier les journaux et `/json/version` avant de conclure

== Volumes / persistance ==
* `/media/loic/nem/hermes:/opt/data`

Contenu notable dans la persistance :
* `config.yaml`
* historiques / sessions Hermes
* mémoire et skills synchronisés par Hermes

== Dépendances ==
* Podman rootless
* Ollama local via `http://host.containers.internal:11434/v1`
* second bot Telegram dédié avec token distinct de l'instance OpenClaw existante
* package Python `ddgs` installé via `hermes tools post-setup ddgs` le `13 juillet 2026`
* clé API Tavily injectée via `hermes.env` le `13 juillet 2026`
* service `hermes-cdp.service` indépendant, relié à Hermes par `hermes-net` depuis le `16 juillet 2026`

== Modèle LLM principal ==
Configuration Hermes actuellement retenue :
* provider : `custom`
* backend : API Ollama locale sur `http://host.containers.internal:11434/v1`
* modèle par défaut : `gemma4:e4b-it-q8_0_128k`
* contexte cible : `131072` tokens

== Outils et backends activés ==
Activation explicite actuellement retenue dans `config.yaml` :
* `web.search_backend: ddgs`
* `web.extract_backend: tavily`
* `browser.cdp_url: http://10.89.12.2:9222`

Conséquences :
* `web_search` devient disponible sans clé API
* `web_extract` devient disponible via Tavily pour les URLs HTTP/HTTPS et le rendu markdown
* `browser_cdp` et `browser_dialog` deviennent disponibles sans exposer CDP sur le réseau hôte

Backends non activés à ce stade :
* aucun backend `image_gen`

== Intégration Telegram préparée ==
Configuration locale maintenant active :
* fichier dédié : `/home/loic/hermes-config/hermes.env`
* allowlist utilisateur configurée sur l'identifiant Telegram de Loïc : `5910858583`
* canal home Telegram préparé sur `5910858583`
* bot dédié configuré : `@LoicHermesBot`

Important :
* le token du bot dédié est maintenant renseigné dans `hermes.env`
* il faut un bot distinct de `@LoicBoBBot` pour éviter le conflit `getUpdates` avec OpenClaw

Variables prévues dans `hermes.env` :
* `TELEGRAM_ALLOWED_USERS=5910858583`
* `TELEGRAM_HOME_CHANNEL=5910858583`
* `TELEGRAM_BOT_TOKEN=...` configuré pour `@LoicHermesBot`
* `TAVILY_API_KEY=...` configurée sans etre documentée en clair dans cette page

== Procédure pour finaliser le second bot ==
Bot dédié déjà créé et validé :
* nom : `Hermes`
* username : `@LoicHermesBot`

Pour refaire la procédure sur une autre instance :
* créer un bot dédié via `@BotFather`
* renseigner `TELEGRAM_BOT_TOKEN` dans `/home/loic/hermes-config/hermes.env`
* `systemctl --user daemon-reload`
* `systemctl --user restart hermes.service`
* vérifier `journalctl --user -u hermes.service -n 100 --no-pager`

== Procédure de relance / diagnostic ==
Commandes utiles :
* `systemctl --user status hermes.service --no-pager -l`
* `systemctl --user status hermes-cdp.service --no-pager -l`
* `systemctl --user restart hermes.service`
* `systemctl --user restart hermes-cdp.service`
* `journalctl --user -u hermes.service -n 100 --no-pager`
* `journalctl --user -u hermes-cdp.service -n 100 --no-pager`
* `ss -ltn | rg 8642`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.web_tools import check_web_api_key; print(check_web_api_key())"`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.web_tools import _get_search_backend,_get_extract_backend; print(_get_search_backend(), _get_extract_backend())"`
* `podman exec hermes curl -fsS http://10.89.12.2:9222/json/version`
* `podman exec hermes /opt/hermes/.venv/bin/python -c "from tools.browser_cdp_tool import _browser_cdp_check; print(_browser_cdp_check())"`

Interprétation rapide :
* si le service tourne mais logue `No messaging platforms enabled`, le token Telegram n'est pas encore actif
* si le service refuse de démarrer après ajout du token, vérifier d'abord le format du token et l'unicité du bot
* si un conflit de token apparaît, s'assurer que le bot Hermes n'est pas le même que celui d'OpenClaw
* si Telegram est bien pris en compte, les logs montrent une phase de connexion du type `Connecting to Telegram`
* si `check_web_api_key()` renvoie `True` avec `search_provider=ddgs` et `extract_provider=tavily`, la recherche et l'extraction web sont activées
* si `curl http://10.89.12.2:9222/json/version` renvoie un `webSocketDebuggerUrl` depuis le conteneur Hermes, la cible CDP est joignable
* ne pas rétablir `--network container:hermes` : un conteneur CDP dépendant empêcherait Podman de recréer Hermes lors d'une mise à jour
* si `_browser_cdp_check()` renvoie `True`, `browser_cdp` et `browser_dialog` doivent etre exposes par Hermes

== Plan d'activation des potentiels ==
Checklist de suivi :
* [x] sécuriser le runtime rootless + backups de config
* [x] activer Telegram dédié
* [x] basculer sur le modèle local `gemma4:e4b-it-q8_0_128k`
* [x] activer `web_search` gratuit via `ddgs`
* [x] choisir et brancher un backend `web_extract`
* [x] fournir un endpoint CDP persistant pour `browser_cdp`
* [ ] choisir et brancher un backend `image_generate`
* [ ] décider si un contexte desktop dédié doit être exposé à Hermes

Intervention attendue de Loïc pour débloquer la suite :
* `image_generate` : fournir un provider et un secret ou une auth exploitable dans le conteneur (`OPENAI_API_KEY`, `FAL_KEY`, ou auth Codex dans Hermes)

== Données / emplacements à sauvegarder ==
* `/home/loic/.config/containers/systemd/hermes.container`
* `/home/loic/.config/containers/systemd/hermes-cdp.container`
* `/home/loic/.config/systemd/user/hermes-network.service`
* `/home/loic/hermes-config/hermes.env`
* `/media/loic/nem/hermes`

== Sauvegarde ==
Avant modification de la config critique :
* sauvegarder le quadlet Hermes
* sauvegarder `hermes.env`
* sauvegarder la persistance `/media/loic/nem/hermes`

== Restauration ==
* restaurer `hermes.container`
* restaurer `hermes.env`
* restaurer `/media/loic/nem/hermes`
* recharger systemd user
* relancer `hermes.service`

== Rollback ==
Si l'intégration Telegram du second bot casse Hermes :
* recommenter `TELEGRAM_BOT_TOKEN` dans `/home/loic/hermes-config/hermes.env`
* redémarrer `hermes.service`
* revenir au backup du quadlet si nécessaire

== Maintenance documentaire ==
Lors d'un changement d'image, de provider LLM, de chemin de persistance, de port local, de bot Telegram ou de stratégie d'allowlist, mettre à jour cette page et la trace centrale.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - Hermes Agent

2026-07-13T17:13:55Z

Daneel : Documente l activation de browser_cdp sur Hermes

Trace install tas - Hermes Agent

2026-07-13T12:13:26Z

Daneel : Activation de web_extract via Tavily et mise a jour de la checklist Hermes

Trace install tas - Hermes Agent

2026-07-13T08:57:56Z

Daneel : Publication de la page Trace install tas - Hermes Agent

Trace install tas

2026-07-13T08:57:14Z

Daneel : Ajout du lien vers Trace install tas - Hermes Agent et synchro de la page centrale

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Hugo]]
* [[Trace install tas - Trilium Notes]]
* [[Trace install tas - Stalwart]]
* [[Trace install tas - Hermes Agent]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Ports publics !! Domaines !! Rôle
|-
| Open WebUI || 8080 || 25680 || owui.lololand.org || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681 / 25692 || dt.lololand.org || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682 || vault.lololand.org || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || kuma.lololand.org || Supervision
|-
| Scriberr || 8084 || 25684 || || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || || OSINT / profils sociaux
|-
| Immich || 8088 || 25688 || immich.lololand.org || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689 || headscale.lololand.org || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691 || cyberchef.lololand.org || Outils de transformation
|-
| Beszel || 8093 || 25693 || bezel.lololand.org || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || || GED / OCR
|-
| Karakeep || 8095 || 25695 || || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || nextcloud.lololand.org || Fichiers / groupware
|-
| Homepage || 8097 || 25697 || home.lololand.org || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || wiki.lololand.org || Wiki collaboratif
|-
| n8n || 5678 || 25678 || n8n.lololand.org || Automatisation
|-
| Ollama || 11434 || 25434 || || API LLM locale
|-
| Hugo || 8100 || 25700 || hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701 || trilium.lololand.org || Base de connaissances / notes
|-
| Stalwart || 1025 / 1465 / 1587 / 1993 / 18080 || aucun à date || mail.lololand.org / lololand.org (MX à basculer) || Serveur mail local
|-
| Hermes Agent || 8642 || aucun à date || || Agent IA outillé via gateway de messagerie
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas

2026-05-03T18:40:38Z

Daneel : Ajout de Stalwart dans la trace centrale tas

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Hugo]]
* [[Trace install tas - Trilium Notes]]
* [[Trace install tas - Stalwart]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Ports publics !! Domaines !! Rôle
|-
| Open WebUI || 8080 || 25680 || owui.lololand.org || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681 / 25692 || dt.lololand.org || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682 || vault.lololand.org || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || kuma.lololand.org || Supervision
|-
| Scriberr || 8084 || 25684 || || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || || OSINT / profils sociaux
|-
| Immich || 8088 || 25688 || immich.lololand.org || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689 || headscale.lololand.org || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691 || cyberchef.lololand.org || Outils de transformation
|-
| Beszel || 8093 || 25693 || bezel.lololand.org || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || || GED / OCR
|-
| Karakeep || 8095 || 25695 || || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || nextcloud.lololand.org || Fichiers / groupware
|-
| Homepage || 8097 || 25697 || home.lololand.org || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || wiki.lololand.org || Wiki collaboratif
|-
| n8n || 5678 || 25678 || n8n.lololand.org || Automatisation
|-
| Ollama || 11434 || 25434 || || API LLM locale
|-
| Hugo || 8100 || 25700 || hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701 || trilium.lololand.org || Base de connaissances / notes
|-
| Stalwart || 1025 / 1465 / 1587 / 1993 / 18080 || aucun à date || mail.lololand.org / lololand.org (MX à basculer) || Serveur mail local
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas - Stalwart

2026-05-03T18:40:38Z

Daneel : Mise à jour Stalwart: ports locaux, étapes de configuration mail et état de réception externe

= Trace install tas - Stalwart =

== Vue d'ensemble ==
* Service mail tout-en-un ''Stalwart'' déployé sur ''tas'' via Podman rootless et Quadlet systemd user.
* Objectif: héberger localement les boîtes mail et l'administration, avec préparation pour ''lololand.org''.
* Image utilisée: ''docker.io/stalwartlabs/stalwart:latest''.
* État actuel: service fonctionnel en local sur ports non privilégiés, authentification testée avec succès depuis Thunderbird, mais réception Internet pas encore activée.

== Source de vérité ==
* Quadlet: ''/home/loic/.config/containers/systemd/stalwart.container''
* Configuration Stalwart: ''/home/loic/stalwart-data/etc/config.toml''
* Données: ''/home/loic/stalwart-data/data''
* Logs: ''/home/loic/stalwart-data/logs''
* Sauvegarde config 2026-05-03: ''/home/loic/backups/stalwart-config.toml.bak.2026-05-03T09:08:08+02:00''
* Sauvegarde quadlet 2026-05-03: ''/home/loic/backups/stalwart.container.bak.2026-05-03T09:15:01+02:00''

== Configuration Quadlet actuelle ==
<pre>
[Unit]
Description=Stalwart Mail Server
After=network-online.target
Wants=network-online.target

[Container]
Image=docker.io/stalwartlabs/stalwart:latest
ContainerName=stalwart
AutoUpdate=registry
Volume=/home/loic/stalwart-data/etc:/etc/stalwart:Z
Volume=/home/loic/stalwart-data/data:/var/lib/stalwart:Z
Volume=/home/loic/stalwart-data/logs:/var/log/stalwart:Z
PublishPort=1025:25
PublishPort=1465:465
PublishPort=1587:587
PublishPort=1143:143
PublishPort=1993:993
PublishPort=1110:110
PublishPort=1995:995
PublishPort=14190:4190
PublishPort=18080:8080
PublishPort=18443:443

[Service]
Restart=always
TimeoutStartSec=180

[Install]
WantedBy=default.target
</pre>

== Listeners internes configurés ==
<pre>
SMTP : 25
Submission: 587
SMTPS : 465
IMAP : 143
IMAPS : 993
POP3 : 110
POP3S : 995
Sieve : 4190
HTTP : 8080
HTTPS : 443
</pre>

== Cartographie des ports ==
{| class="wikitable"
! Usage !! Port local sur tas !! Port interne conteneur !! Exposition publique actuelle !! Remarques
|-
| SMTP entrant || 1025 || 25 || aucune || cible future pour la réception Internet via redirection TCP 25
|-
| SMTPS client || 1465 || 465 || aucune || test utilisateur validé avec authentification
|-
| Submission client || 1587 || 587 || aucune || alternative client authentifiée
|-
| IMAP || 1143 || 143 || aucune || accès local uniquement
|-
| IMAPS || 1993 || 993 || aucune || lecture sécurisée locale
|-
| POP3 || 1110 || 110 || aucune || non prioritaire
|-
| POP3S || 1995 || 995 || aucune || non prioritaire
|-
| ManageSieve || 14190 || 4190 || aucune || optionnel
|-
| Admin HTTP || 18080 || 8080 || aucune || interface web locale
|-
| Admin HTTPS || 18443 || 443 || aucune || interface web locale
|}

== Vérifications réalisées ==
* Le service écoute bien localement sur ''1025'', ''1465'', ''1587'' et ''1993''.
* Test HTTP local validé sur ''http://127.0.0.1:18080/''.
* Test d'envoi fiable validé depuis Thunderbird via ''127.0.0.1:1465'' avec authentification du compte et acceptation du certificat local.
* Les logs Stalwart montrent un flux sain sur le listener ''submissions'' et une classification ''message-ingest.ham'' lors d'un envoi authentifié.
* Les tests directs sur ''127.0.0.1:1025'' acceptent bien le SMTP entrant local, mais ce chemin peut être classé ''spam'' dans les logs pour des tests non authentifiés.

== Procédure de récupération admin (incident 2026-05-03) ==
* L'ancien ''authentication.fallback-admin'' dans ''config.toml'' ne suffisait plus pour l'interface web après mise à jour/redémarrage.
* Procédure ayant fonctionné sur Stalwart 0.16:
** ajouter temporairement ''STALWART_RECOVERY_ADMIN=recovery:<mot_de_passe>'' dans le quadlet
** ''systemctl --user daemon-reload''
** ''systemctl --user restart stalwart.service''
** recréer ou réparer un vrai compte admin dans l'interface
** retirer ensuite ''STALWART_RECOVERY_ADMIN'' du quadlet et redémarrer le service
* Sauvegarde avant retrait de la variable de recovery: ''/home/loic/backups/stalwart.container.remove-recovery.bak.2026-05-03T10:16:14+02:00''

== Étapes de configuration recommandées pour recevoir ''loic@lololand.org'' ==
=== 1. Configuration Stalwart ===
* Créer ou vérifier le domaine ''lololand.org'' dans l'interface d'administration.
* Créer la boîte ou l'alias ''loic@lololand.org''.
* Vérifier que l'authentification fonctionne en local avec:
** SMTP client: ''127.0.0.1:1465''
** IMAPS: ''127.0.0.1:1993''
* Conserver les ports élevés locaux dans le conteneur rootless; l'exposition Internet doit se faire par redirection TCP devant le service.

=== 2. Configuration réseau / exposition SMTP ===
* Le conteneur rootless ne peut pas publier directement les ports privilégiés ''25/465/587/993''.
* Pour la réception Internet, il faut au minimum faire arriver le ''TCP/25 public'' vers ''tas'', puis vers ''127.0.0.1:1025''.
* Deux familles d'approche:
** redirection routeur + redirection hôte/firewall vers ''1025''
** ou proxy TCP dédié en frontal
* Important: ''Caddy'' standard sert de reverse proxy HTTP/HTTPS; il ne traite pas SMTP/IMAP sans module TCP/L4 additionnel.

=== 3. DNS à corriger avant bascule ===
* ''mail.lololand.org A 82.67.187.157'' est déjà présent.
* Les MX actuels de ''lololand.org'' pointent d'abord chez OVH, puis seulement vers ''mail.lololand.org''.
* Pour faire de Stalwart le serveur recevant les mails du domaine, prévoir une bascule vers un MX principal du type:
** ''lololand.org. MX 10 mail.lololand.org.''
* Publier ensuite les enregistrements ''SPF'', ''DKIM'' et ''DMARC'' générés/confirmés côté Stalwart.
* Vérifier aussi le ''PTR/rDNS'' de l'IP publique si possible.

=== 4. Ordre de bascule prudent ===
# valider le compte ''loic@lololand.org'' en local
# faire la redirection réseau du port public ''25'' vers Stalwart
# tester depuis une source externe vers ''mail.lololand.org:25''
# seulement ensuite modifier le MX principal du domaine
# refaire un test réel d'envoi depuis l'extérieur vers ''loic@lololand.org''

== Limites et points de vigilance ==
* Tant que le MX principal reste chez OVH, les mails extérieurs arriveront d'abord chez OVH et pas directement sur Stalwart.
* Tant que rien n'écoute ou ne redirige le ''port 25 public'' vers ''1025'', Stalwart ne peut pas recevoir de mail Internet.
* Les tests SMTP sortants vers des MX publics sur le port 25 ont déjà time-out; un ''relay SMTP'' restera probablement nécessaire pour l'émission Internet fiable.
* Si une terminaison TLS publique est ajoutée pour les ports mail, elle doit être faite en mode ''TCP passthrough'' ou avec un frontal explicitement conçu pour ces protocoles.

== Relance et diagnostic ==
* Redémarrer: ''systemctl --user restart stalwart.service''
* Statut: ''systemctl --user status stalwart.service''
* Logs systemd user: ''journalctl --user -u stalwart.service -n 200 --no-pager''
* Logs conteneur: ''podman logs --tail 200 stalwart''
* Vérifier les ports: ''ss -ltn | egrep ':(1025|1110|1143|1465|1587|1993|1995|14190|18080|18443)\\s''

== Décision retenue à date ==
* Conserver Stalwart en Podman rootless avec ports élevés locaux.
* Préparer la réception Internet par une redirection réseau explicite et réversible, plutôt qu'en abaissant globalement ''net.ipv4.ip_unprivileged_port_start''.
* Documenter séparément les variantes de frontalisation possibles (routeur + firewall hôte, ou Caddy avec module layer4 si retenu).

Trace install tas - Paperless-ngx

2026-04-12T17:02:38Z

Daneel : Documentation maintenance conteneurs enrichie: dépendances, volumes, relance et paramètres

= Trace install tas - Paperless-ngx =

== Rôle ==
GED / OCR documentaire.

== Accès ==
* Local : http://10.8.0.1:8094
* Public : https://lololand.hopto.org:25694

== Ports ==
8094 local, 25694 public

== Exécution / runtime ==
Quadlets systemd user : paperless.container et paperless-broker.container ; conteneur principal systemd-paperless.

Rôle des services :
* `paperless.service` : application Paperless-ngx
* `paperless-broker.service` : Redis utilisé par l'application via `PAPERLESS_REDIS`

== Chemins de configuration ==
* /home/loic/.config/containers/systemd/paperless.container
* /home/loic/.config/containers/systemd/paperless-broker.container
* /home/loic/paperless/consume
* /home/loic/paperless/export

Les quadlets sont les sources de vérité de lancement ; les répertoires `consume` et `export` sont les points d'échange documentaires / entrants-sortants.

== Volumes / persistance ==
* `paperless-data:/usr/src/paperless/data`
* données applicatives et métadonnées internes
* `paperless-media:/usr/src/paperless/media`
* documents importés et fichiers gérés
* `/home/loic/paperless/export -> /usr/src/paperless/export`
* exports produits par l'application
* `/home/loic/paperless/consume -> /usr/src/paperless/consume`
* dossier de dépôt pour ingestion automatique

== Dépendances ==
* paperless-broker.service
* réseau paperless-net
* redis via PAPERLESS_REDIS
* Caddy 25694 -> 8094

== Procédure de relance / diagnostic ==
Ordre recommandé :
* broker Redis
* application Paperless

Commandes utiles :
* `systemctl --user restart paperless-broker.service`
* `systemctl --user restart paperless.service`
* `systemctl --user status paperless.service --no-pager -l`
* `curl -I http://127.0.0.1:8094/`

Explication :
* Paperless dépend du broker Redis pour son fonctionnement normal ; un démarrage applicatif sans broker sain peut produire des erreurs trompeuses.
* `curl -I` permet de valider rapidement l'interface HTTP avant d'accuser Caddy.
* `status --no-pager -l` permet de voir les erreurs de volume, variable ou dépendance.

== Remarques ==
OCR configuré sur fra+eng. Service important pour la persistance documentaire.

== Données / emplacements à sauvegarder ==
* Métadonnées / application : volume paperless-data
* Documents : volume paperless-media
* Répertoires locaux : /home/loic/paperless/export et /home/loic/paperless/consume
* Quadlets : paperless.container et paperless-broker.container

== Sauvegarde ==
* Sauvegarder les volumes paperless-data, paperless-media, paperless-redis-data.
* Sauvegarder /home/loic/paperless/export et /home/loic/paperless/consume.
* Exporter aussi les quadlets si une restauration complète de l'orchestration est visée.

== Restauration ==
* Restaurer les volumes paperless-data, paperless-media, paperless-redis-data.
* Restaurer /home/loic/paperless/export et /home/loic/paperless/consume.
* Restaurer les quadlets puis relancer d'abord le broker, ensuite Paperless.
* Vérifier ensuite l'accès HTTP, l'ingestion depuis `consume` et la présence des documents dans l'interface.

== Maintenance documentaire ==
Lors d'un changement de répertoires consume/export, OCR, broker Redis, variables Paperless ou volumes, mettre à jour cette page.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - Nextcloud

2026-04-12T17:02:38Z

Daneel : Documentation maintenance conteneurs enrichie: dépendances, volumes, relance et paramètres

= Trace install tas - Nextcloud =

== Rôle ==
Stockage de fichiers et groupware.

== Accès ==
* Local : http://10.8.0.1:8096
* Public : https://lololand.hopto.org:25696

== Ports ==
8096 local, 25696 public

== Exécution / runtime ==
Quadlets systemd user : nextcloud.container, nextcloud-db.container, nextcloud-redis.container ; conteneurs systemd-nextcloud, nextcloud-db, nextcloud-redis.

Rôle des services :
* `nextcloud.service` : application Nextcloud / PHP / Apache ou équivalent selon l'image retenue
* `nextcloud-db.service` : MariaDB de l'instance
* `nextcloud-redis.service` : cache / verrouillage / broker léger pour améliorer la stabilité applicative

== Chemins de configuration ==
* /home/loic/.config/containers/systemd/nextcloud.container
* /home/loic/.config/containers/systemd/nextcloud-db.container
* /home/loic/.config/containers/systemd/nextcloud-redis.container

Ce sont les sources de vérité de lancement. Toute évolution de ports, volumes, réseau ou variables doit passer par ces fichiers.

== Volumes / persistance ==
* `nextcloud-html:/var/www/html`
* code applicatif et fichiers web Nextcloud
* `nextcloud-data:/var/www/html/data`
* données utilisateurs
* `nextcloud-db:/var/lib/mysql`
* base MariaDB

== Dépendances ==
* nextcloud-db.service
* nextcloud-redis.service
* réseau nextcloud-net
* Caddy 25696 -> 8096

== Procédure de relance / diagnostic ==
Ordre recommandé :
* base MariaDB
* redis
* application Nextcloud

Commandes utiles :
* `systemctl --user restart nextcloud-db.service`
* `systemctl --user restart nextcloud-redis.service`
* `systemctl --user restart nextcloud.service`
* `systemctl --user status nextcloud.service --no-pager -l`
* `curl -I http://127.0.0.1:8096/`

Explication :
* relancer la base avant l'application évite une partie des faux diagnostics applicatifs
* `status --no-pager -l` permet de voir rapidement si le problème vient d'un volume, d'une image ou d'une dépendance non disponible
* `curl -I` permet de distinguer une panne HTTP d'un simple souci de proxy public

== Remarques ==
Trusted domains configurés pour localhost, 127.0.0.1 et lololand.hopto.org. PHP_MEMORY_LIMIT et PHP_UPLOAD_LIMIT à 1024M.

== Données / emplacements à sauvegarder ==
* HTML applicatif : volume nextcloud-html
* Données utilisateurs : volume nextcloud-data
* Base MariaDB : volume nextcloud-db
* Quadlets : nextcloud.container, nextcloud-db.container, nextcloud-redis.container

== Sauvegarde ==
* Sauvegarder les volumes nextcloud-html, nextcloud-data et nextcloud-db.
* Exporter les quadlets nextcloud.container, nextcloud-db.container et nextcloud-redis.container.
* Conserver une trace des trusted domains et des limites PHP si elles sont définies dans les quadlets ou variables d'environnement.

== Restauration ==
* Restaurer les volumes nextcloud-html, nextcloud-data et nextcloud-db.
* Restaurer les quadlets.
* Recharger systemd user si nécessaire.
* Redémarrer les services nextcloud-db, nextcloud-redis puis nextcloud.
* Vérifier ensuite l'accès HTTP local, la connexion DB et les trusted domains.

== Maintenance documentaire ==
Lors d'un changement de base, redis, volumes, réseau, trusted domains, limites PHP ou image, mettre à jour cette page et la trace centrale.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - Immich

2026-04-12T17:02:37Z

Daneel : Documentation maintenance conteneurs enrichie: dépendances, volumes, relance et paramètres

= Trace install tas - Immich =

== Rôle ==
Gestionnaire photo / vidéo.

== Accès ==
* Local : http://10.8.0.1:8088
* Public : https://lololand.hopto.org:25688

== Ports ==
8088 applicatif, 25688 public

== Exécution / runtime ==
Stack docker-compose dans /home/loic/immich/docker-compose.yml ; conteneurs immich_server, immich_microservices, immich_machine_learning, immich_redis, immich_postgres.

Rôle des conteneurs :
* `immich_server` : API / frontend principal exposé localement sur 8088
* `immich_microservices` : traitements de fond Immich
* `immich_machine_learning` : inférence et reconnaissance, ici avec accélération ROCm
* `immich_redis` : broker/cache Redis
* `immich_postgres` : base PostgreSQL/pgvector

== Chemins de configuration ==
* /home/loic/immich/docker-compose.yml
* /home/loic/immich/.env si présent

Le `.env` est critique s'il porte des variables comme :
* `UPLOAD_LOCATION`
* `DB_DATA_LOCATION`
* `IMMICH_VERSION`
* éventuels paramètres GPU / ROCm ou mots de passe de base

== Volumes / persistance ==
* `${UPLOAD_LOCATION}` -> `/usr/src/app/upload`
* photos, vidéos, vignettes et contenus applicatifs liés aux médias
* `${DB_DATA_LOCATION}` -> `/var/lib/postgresql/data`
* données PostgreSQL/pgvector
* `/home/loic/immich/ml-cache` -> `/cache`
* cache du service machine learning

== Dépendances ==
* redis
* postgres pgvector
* machine learning ROCm
* Caddy 25688 -> 8088

== Procédure de relance / diagnostic ==
Relance standard :
* relancer la stack compose Immich depuis /home/loic/immich

Vérifications utiles :
* vérifier que `immich_server` est exposé sur 8088
* vérifier l'état de `immich_postgres` avant toute conclusion sur une panne applicative
* vérifier `immich_machine_learning` séparément si les fonctions IA posent problème
* tester l'accès local avant le proxy Caddy

Points à surveiller :
* si les volumes changent de chemin dans `.env`, la restauration ou la sauvegarde devient incorrecte si la page n'est pas mise à jour
* le cache ML peut être reconstruit, mais sa présence peut améliorer les redémarrages

== Remarques ==
Architecture multi-conteneurs avec accélération ROCm pour la partie machine learning.

== Données / emplacements à sauvegarder ==
* Photos/vidéos : `${UPLOAD_LOCATION}`
* Base Postgres : `${DB_DATA_LOCATION}`
* Cache ML : /home/loic/immich/ml-cache
* fichiers de définition : docker-compose.yml et `.env`

== Sauvegarde ==
* Sauvegarder `${UPLOAD_LOCATION}`, `${DB_DATA_LOCATION}` et /home/loic/immich/ml-cache.
* Sauvegarder /home/loic/immich/docker-compose.yml et le `.env` associé.
* Pour une restauration cohérente, conserver les valeurs exactes des variables de chemin au moment de la sauvegarde.

== Restauration ==
* Restaurer les répertoires d'upload, la base Postgres et le cache ML si souhaité.
* Restaurer `docker-compose.yml` et `.env`.
* Relancer ensuite la stack Immich complète et vérifier séparément le frontend, la base et la partie machine learning.

== Maintenance documentaire ==
Lors d'un changement de volumes photo, base, cache ML, variables `.env`, accélération GPU ou version `IMMICH_VERSION`, mettre à jour cette page.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - Homepage

2026-04-12T17:02:37Z

Daneel : Documentation maintenance conteneurs enrichie: dépendances, volumes, relance et paramètres

= Trace install tas - Homepage =

== Rôle ==
Tableau de bord des services.

== Accès ==
* Local : http://10.8.0.1:8097
* Public : https://lololand.hopto.org:25697

== Ports ==
8097 local, 25697 public via Caddy

== Exécution / runtime ==
Quadlet systemd user : /home/loic/.config/containers/systemd/homepage.container ; conteneur systemd-homepage.

Paramètres importants à expliquer :
* `Image=ghcr.io/gethomepage/homepage:latest` : image du dashboard
* `AutoUpdate=registry` : activation des mises à jour automatiques via podman auto-update
* montage de `/home/loic/homepage-config` vers `/app/config` : la configuration affichée par Homepage vient de ce dossier hôte
* port local 8097 : point d'écoute local du service derrière Caddy

== Chemins de configuration ==
* /home/loic/.config/containers/systemd/homepage.container
* /home/loic/homepage-config/services.yaml
* /home/loic/homepage-config/settings.yaml
* /home/loic/homepage-config/custom.js
* /home/loic/homepage-config/custom.css

Rôle des fichiers :
* `services.yaml` : cartes, liens, groupes et cibles de supervision / navigation
* `settings.yaml` : options globales de Homepage
* `custom.js` : comportements ou intégrations frontend spécifiques
* `custom.css` : surcharge visuelle locale

== Volumes / persistance ==
* /home/loic/homepage-config -> /app/config
* ce bind mount est la source de vérité de la configuration affichée
* pas de base de données dédiée documentée

== Dépendances ==
* Caddy pour l'exposition publique
* liste des services documentée dans services.yaml

== Procédure de relance / diagnostic ==
Relance standard :
* `systemctl --user restart homepage.service`

Vérifications utiles :
* `systemctl --user status homepage.service --no-pager -l`
* `systemctl --user cat homepage.service`
* `curl -I http://127.0.0.1:8097/`
* vérifier le rendu des cartes après modification de services.yaml

Explication des commandes :
* `systemctl --user cat` : montre l'unité réellement générée par Quadlet.
* `curl -I` : vérifie rapidement la disponibilité HTTP.
* `status --no-pager -l` : utile pour repérer un souci d'image, de bind mount ou de port.

== Remarques ==
Image ghcr.io/gethomepage/homepage:latest avec AutoUpdate=registry. HOMEPAGE_ALLOWED_HOSTS configuré. Le dashboard porte les liens publics et internes des services.

== Données / emplacements à sauvegarder ==
* Configuration dans /home/loic/homepage-config
* quadlet /home/loic/.config/containers/systemd/homepage.container
* pas de base de données applicative dédiée documentée

== Sauvegarde ==
* Sauvegarder /home/loic/homepage-config (services.yaml, settings.yaml, custom.js, custom.css).
* Exporter aussi le quadlet /home/loic/.config/containers/systemd/homepage.container.

== Restauration ==
* Restaurer /home/loic/homepage-config et le quadlet homepage.container.
* Recharger systemd user si nécessaire puis relancer le service.
* Vérifier ensuite l'accès local/public et la cohérence des liens vers les autres services.

== Maintenance documentaire ==
Lors d'un changement de carte, port, image, lien public/interne, HOMEPAGE_ALLOWED_HOSTS ou custom.js/custom.css, mettre à jour cette page et la page centrale trace install tas.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - Social Analyzer

2026-04-12T16:57:52Z

Daneel : Documentation conteneurs enrichie: runtime, paramètres, ports, volumes, relance et diagnostic

= Trace install tas - Social Analyzer =

== Rôle ==
OSINT / analyse de profils sociaux.

== Accès ==
* Local : http://10.8.0.1:8086/app.html
* Public : https://lololand.hopto.org:25686/app.html
* Attention : la racine / peut répondre 404 ; le point d'entrée applicatif observé est /app.html

== Ports ==
* 8086 -> 9005 : interface web Social Analyzer publiée par le conteneur applicatif
* 4444 -> 4444 : Selenium Hub
* 9002 -> 5900 : VNC du noeud Firefox Selenium
* 25686 -> 8086 : publication publique via Caddy

== Exécution / runtime ==
Stack podman-compose dans /home/loic/clawd/social-analyzer/docker-compose.yml ; conteneurs attendus :
* social-analyzer_social-analyzer_1 : application Node.js / interface web
* social-analyzer_hub_1 : hub Selenium
* web-automation_firefox : noeud Firefox Selenium

Service systemd user associé : /home/loic/.config/systemd/user/social-analyzer.service
* Type=oneshot : systemd considère le lancement réussi quand `podman-compose up -d` se termine, même si la santé réelle des conteneurs doit être vérifiée séparément.
* WorkingDirectory=/home/loic/clawd/social-analyzer : toutes les commandes du service s'exécutent depuis ce dossier.
* ExecStart=/usr/bin/podman-compose up -d : crée/recrée et démarre la stack en arrière-plan.
* `up` : crée et démarre les services du compose.
* `-d` : mode détaché, le processus compose rend la main après lancement.
* ExecStop=/usr/bin/podman-compose down : arrête et supprime les conteneurs/réseaux créés par la stack.
* RemainAfterExit=yes : l'unité reste marquée active après la fin du processus oneshot.

== Chemins de configuration ==
* /home/loic/.config/systemd/user/social-analyzer.service
* /home/loic/clawd/social-analyzer/docker-compose.yml
* /home/loic/clawd/social-analyzer/Dockerfile
* /home/loic/clawd/social-analyzer/package.json
* /home/loic/clawd/social-analyzer/package-lock.json

== Images et build ==
* image locale buildée : localhost/social-analyzer_social-analyzer:latest
* image hub : docker.io/selenium/hub
* image noeud Firefox : docker.io/selenium/node-firefox

Dockerfile applicatif actuel :
* `FROM node:20.18.1-alpine3.20` : base Node épinglée pour éviter les incompatibilités vues avec Node 18.15.0.
* `WORKDIR /usr/src/app` : répertoire de travail dans l'image.
* `COPY . .` : copie du contexte de build complet.
* `RUN apk update && apk add --no-cache firefox-esr && npm ci && npm install lodash && npm install --loglevel=error`
* `apk add --no-cache firefox-esr` : installe Firefox ESR dans l'image applicative.
* `npm ci` : installe strictement les dépendances depuis package-lock.json, de façon reproductible.
* `npm install lodash` : ajoute explicitement lodash si requis par le projet.
* `npm install --loglevel=error` : second passage npm plus silencieux pour finaliser les dépendances.
* `EXPOSE 9005` : documentation du port interne de l'application.
* `ENTRYPOINT [ "npm", "start", "--","--docker"]` : lance l'application en mode docker.

== Paramètres du docker-compose ==
Service `social-analyzer` :
* `build: .` : construit l'image locale à partir du Dockerfile du dossier courant.
* `ports: "8086:9005"` : publie le port 9005 du conteneur sur le port 8086 de l'hôte.
* `depends_on: hub` : demande à compose de démarrer le hub avant l'application.
* `links: hub` : alias réseau historique vers `hub`.
* `entrypoint: npm start -- --docker --grid "http://hub:4444/wd/hub"`
* `npm start` : démarre l'application définie dans package.json.
* `--` : transmet les arguments suivants au script npm.
* `--docker` : active le mode conteneur.
* `--grid "http://hub:4444/wd/hub"` : pointe l'application vers le Selenium Hub interne.

Service `hub` :
* `image: docker.io/selenium/hub`
* `ports: "4444:4444"` : expose le hub Selenium sur l'hôte.
* variables :
* `GRID_MAX_SESSION=16` : limite haute de sessions Selenium simultanées.
* `GRID_BROWSER_TIMEOUT=6000` : timeout navigateur côté grid.
* `GRID_TIMEOUT=6000` : timeout global grid.

Service `firefox` :
* `image: docker.io/selenium/node-firefox`
* `container_name: web-automation_firefox` : fixe un nom de conteneur stable.
* `depends_on: hub` : démarre après le hub.
* variables :
* `SE_EVENT_BUS_HOST=hub` : hôte du bus Selenium.
* `SE_EVENT_BUS_PUBLISH_PORT=4442` : port de publication du bus.
* `SE_EVENT_BUS_SUBSCRIBE_PORT=4443` : port d'abonnement du bus.
* `SE_NODE_MAX_SESSIONS=${CPU_CORES:-2}` : nombre de sessions Firefox, avec valeur par défaut 2 si CPU_CORES n'est pas défini.
* `volumes: /dev/shm:/dev/shm` : partage la mémoire partagée de l'hôte pour limiter les crashs navigateur.
* `ports: "9002:5900"` : expose le VNC Firefox.
* `links: hub` : alias réseau historique vers `hub`.

== Volumes / persistance ==
* /dev/shm -> /dev/shm dans le conteneur Firefox
* Pas de volume persistant applicatif identifié pour l'interface elle-même dans cette passe
* Le contexte de build local (/home/loic/clawd/social-analyzer) fait partie de l'état à sauvegarder

== Dépendances ==
* hub Selenium
* node-firefox Selenium
* image locale buildée depuis le code source du dossier social-analyzer
* Caddy 25686 -> 8086

== Procédure de relance / diagnostic ==
Relance standard :
* `systemctl --user restart social-analyzer.service`

Vérifications utiles :
* `systemctl --user status social-analyzer.service --no-pager -l`
* `podman ps --all | grep -i 'social-analyzer\|web-automation_firefox'`
* `podman logs --tail 80 social-analyzer_social-analyzer_1`
* `curl -I http://127.0.0.1:8086/app.html`

Explication des commandes :
* `systemctl --user` : agit sur les services systemd utilisateur rootless.
* `status --no-pager -l` : évite le pager interactif et affiche les lignes complètes.
* `podman ps --all` : montre aussi les conteneurs arrêtés, utile pour repérer les fantômes.
* `podman logs --tail 80` : limite la sortie aux dernières lignes pertinentes.
* `curl -I` : teste uniquement les en-têtes HTTP, sans télécharger toute la page.

== Remarques ==
* Incident observé puis corrigé : état Podman rootless incohérent avec noms de conteneurs réservés mais conteneurs introuvables.
* Incident observé puis corrigé : crash Node/npm avec Node.js v18.15.0 ; le Dockerfile a été adapté vers node:20.18.1-alpine3.20.
* Le service Homepage pointait historiquement aussi vers 8085 pour Social Analyzer, alors que la stack courante expose 8086. Cette divergence doit être surveillée et corrigée si nécessaire.
* Le point d'entrée utile est /app.html, pas forcément /.

== Données / emplacements à sauvegarder ==
* /home/loic/.config/systemd/user/social-analyzer.service
* /home/loic/clawd/social-analyzer/docker-compose.yml
* /home/loic/clawd/social-analyzer/Dockerfile
* /home/loic/clawd/social-analyzer/package.json
* /home/loic/clawd/social-analyzer/package-lock.json
* plus largement le dossier /home/loic/clawd/social-analyzer si le contexte de build a été modifié

== Sauvegarde ==
* Sauvegarder le service systemd user et l'intégralité du dossier /home/loic/clawd/social-analyzer.
* Si des variables d'environnement ou fichiers .env sont ajoutés plus tard, les inclure explicitement.
* En cas de rebuild important, conserver aussi le hash/image de référence si besoin d'un rollback rapide.

== Restauration ==
* Restaurer le dossier /home/loic/clawd/social-analyzer et /home/loic/.config/systemd/user/social-analyzer.service.
* Rebuilder ensuite l'image locale avec `podman-compose build --no-cache` si le cache est suspect ou si l'image manque.
* Redémarrer avec `systemctl --user restart social-analyzer.service`.
* Vérifier ensuite `podman ps`, les logs applicatifs et `http://127.0.0.1:8086/app.html`.

== Maintenance documentaire ==
Lors d'une évolution de la stack Selenium, du Dockerfile, du port exposé, du point d'entrée HTTP ou de la route Caddy, mettre à jour cette page et Homepage.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - Open WebUI

2026-04-12T16:57:52Z

Daneel : Documentation conteneurs enrichie: runtime, paramètres, ports, volumes, relance et diagnostic

= Trace install tas - Open WebUI =

== Rôle ==
Interface web vers les LLM locaux.

== Accès ==
* Local : http://10.8.0.1:8080
* Public : https://lololand.hopto.org:25680

== Ports ==
8080 local, 25680 public

== Exécution / runtime ==
Conteneur open-webui (image ghcr.io/open-webui/open-webui:main) ; exposition Caddy active.

État documentaire actuel :
* la présence du conteneur actif est confirmée
* un volume Podman nommé `open-webui` est référencé comme persistance probable
* la méthode de lancement exacte (quadlet, compose, service systemd manuel ou commande podman) n'est pas encore formellement tracée ici

Conséquence :
* les éléments d'accès et de dépendances sont documentés
* mais la source de vérité de lancement reste à compléter pour une restauration 100% déterministe

== Chemins de configuration ==
* /etc/caddy/Caddyfile
* /home/loic/clawd/RAG_openWebUI.md
* /home/loic/openwebui.tar.gz
* à identifier puis ajouter : fichier de service exact, compose ou quadlet si retrouvé

== Volumes / persistance ==
* volume Podman nommé `open-webui` présent sur l'hôte
* points de montage internes exacts encore à confirmer dans la documentation

== Dépendances ==
* Ollama pour l'inférence locale
* Caddy 25680 -> 8080

== Procédure de relance / diagnostic ==
À utiliser tant que la source de vérité n'est pas formellement documentée :
* identifier d'abord le service réel ou la commande réelle avant toute modification
* commandes de diagnostic recommandées :
* `podman ps --all | grep -i open-webui`
* `podman inspect open-webui`
* `systemctl --user list-unit-files | grep -i open-webui`
* `curl -I http://127.0.0.1:8080/`

Explication des commandes :
* `podman ps --all` : montre les conteneurs actifs et arrêtés.
* `podman inspect` : permet d'identifier image, volumes, ports et labels du conteneur réel.
* `systemctl --user list-unit-files` : permet de repérer un éventuel service systemd utilisateur associé.
* `curl -I` : vérifie rapidement l'accès HTTP local.

== Remarques ==
Le conteneur est actif mais les détails de la méthode de lancement ne sont pas encore documentés dans un quadlet local identifié. Cette page reste donc opérationnelle pour l'accès et la sauvegarde probable, mais incomplète pour la reconstitution exacte du lancement.

== Données / emplacements à sauvegarder ==
* volume Podman nommé open-webui présent sur l'hôte
* bloc Caddy lié à l'exposition publique
* chemins de lancement exacts encore à confirmer

== Sauvegarde ==
* Sauvegarder le volume Podman open-webui s'il correspond bien à l'instance active.
* Sauvegarder le bloc Caddy et tout fichier de service/compose/quadlet dès qu'il est identifié.
* Documenter ensuite explicitement les variables d'environnement si elles existent.

== Restauration ==
* Restaurer le volume open-webui puis relancer le conteneur/service actif selon la méthode réellement identifiée.
* Vérifier ensuite la connexion à Ollama et le proxy Caddy.
* Après identification de la méthode de lancement, compléter cette page avec la commande exacte et ses paramètres.

== Maintenance documentaire ==
Dès que le fichier de service exact ou le compose est identifié, l'ajouter ici avec les volumes, variables, ports internes et commande de relance. Mettre à jour cette page à chaque changement d'image, de backend LLM ou de proxy.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - MediaWiki

2026-04-12T16:57:51Z

Daneel : Documentation conteneurs enrichie: runtime, paramètres, ports, volumes, relance et diagnostic

= Trace install tas - MediaWiki =

== Rôle ==
Wiki collaboratif et base documentaire.

== Accès ==
* Local : http://10.8.0.1:8098
* Public : https://lololand.hopto.org:25698

== Ports ==
8098 local, 25698 public via Caddy

== Exécution / runtime ==
Stack compose dans /home/loic/mediawiki ; conteneurs mediawiki-app et mediawiki-db.

Principe :
* `mediawiki-app` sert l'application wiki en HTTP sur le port local 8098
* `mediawiki-db` fournit la base MariaDB dédiée
* Caddy publie ensuite le service local vers le port public 25698

== Chemins de configuration ==
* /home/loic/mediawiki/compose.yaml
* /home/loic/mediawiki/.env
* /home/loic/mediawiki/app/LocalSettings.php
* /home/loic/mediawiki/docs/README.md

== Paramètres clés à documenter dans le compose ==
Cette page suppose que le compose local est la source de vérité. Pour rester exploitable en maintenance, il faut considérer ces éléments comme prioritaires :
* image de `mediawiki-app`
* image de `mediawiki-db`
* variables injectées via `.env`
* ports publiés localement
* bind mounts ou volumes de l'application et de la base
* éventuelles extensions ou personnalisations chargées par `LocalSettings.php`

== Volumes / persistance ==
* ./app -> /var/www/html
* contient le code applicatif local, les extensions, `LocalSettings.php` et les données nécessaires côté MediaWiki
* ./db -> /var/lib/mysql
* contient les données MariaDB du wiki

== Dépendances ==
* MariaDB dédiée (mediawiki-db)
* Caddy 25698 -> 8098

== Procédure de relance / diagnostic ==
Relance standard :
* depuis /home/loic/mediawiki, relancer la stack compose selon la méthode utilisée sur l'hôte

Vérifications utiles :
* vérifier que `mediawiki-app` écoute bien sur 8098 local
* vérifier que `mediawiki-db` est sain avant de conclure à une panne applicative
* tester l'accès local avant l'accès public
* revalider `LocalSettings.php` après toute restauration

Comme la commande exacte de compose n'est pas recopiée ici, la règle documentaire est : documenter explicitement la commande réelle utilisée dès qu'une modification est faite sur cette stack.

== Remarques ==
Le wiki héberge la documentation d'installation, la trace logicielle et les intégrations Mermaid / PlantUML / BPMN JS.

== Données / emplacements à sauvegarder ==
* Données wiki : /home/loic/mediawiki/app
* Base : /home/loic/mediawiki/db
* Variables : /home/loic/mediawiki/.env
* Documentation locale : /home/loic/mediawiki/docs

== Sauvegarde ==
* Sauvegarder /home/loic/mediawiki/app, /home/loic/mediawiki/.env et /home/loic/mediawiki/docs.
* Sauvegarder la base MariaDB via dump ou en copiant /home/loic/mediawiki/db après arrêt propre.
* Si une extension ou un réglage Caddy change, inclure aussi les fichiers de configuration modifiés dans la sauvegarde documentaire.

== Restauration ==
* Restaurer /home/loic/mediawiki/app, /home/loic/mediawiki/.env et /home/loic/mediawiki/db.
* Relancer la stack compose puis vérifier LocalSettings.php, la connexion à la base et l'accès wiki local/public.
* Après restauration, revalider les extensions chargées et les éventuels chemins personnalisés.

== Maintenance documentaire ==
Lors d'un ajout d'extensions, d'un changement de compose, de variables .env, d'images, de ports, de Caddy ou de structure documentaire, mettre à jour cette page et les pages de documentation associées.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas - CyberChef

2026-04-12T16:57:51Z

Daneel : Documentation conteneurs enrichie: runtime, paramètres, ports, volumes, relance et diagnostic

= Trace install tas - CyberChef =

== Rôle ==
Boîte à outils de transformation / encodage / analyse.

== Accès ==
* Local : http://10.8.0.1:8091
* Public : https://lololand.hopto.org:25691

== Ports ==
8091 local, 25691 public

== Exécution / runtime ==
Quadlet /home/loic/.config/containers/systemd/cyberchef.container ; conteneur lancé sous le nom systemd-cyberchef par le générateur Podman/systemd.

Le Quadlet actuel déclare :
* `Image=ghcr.io/gchq/cyberchef:latest` : image du service
* `AutoUpdate=registry` : autorise `podman auto-update` à rechercher une image plus récente dans le registre
* `PublishPort=8091:80` : publie le port 80 du conteneur sur le port 8091 de l'hôte

Le service généré hérite automatiquement de paramètres utiles :
* `Environment=PODMAN_SYSTEMD_UNIT=%n` : ajoute le label attendu pour le redémarrage automatique via systemd après auto-update
* `ExecStart=/usr/bin/podman run ... --publish 8091:80 ...` : commande générée par Quadlet, à ne pas dupliquer dans un service manuel séparé

== Chemins de configuration ==
* /home/loic/.config/containers/systemd/cyberchef.container
* sauvegarde historique d'ancien service manuel si conservée hors production

== Volumes / persistance ==
* Aucun volume monté dans le Quadlet actuel
* Service stateless dans l'état actuel

== Dépendances ==
* Caddy 25691 -> 8091
* podman-auto-update.timer pour les mises à jour automatiques quotidiennes de l'hôte

== Procédure de relance / diagnostic ==
Relance standard :
* `systemctl --user restart cyberchef.service`

Vérifications utiles :
* `systemctl --user cat cyberchef.service`
* `systemctl --user status cyberchef.service --no-pager -l`
* `curl -I http://127.0.0.1:8091/`
* `podman auto-update --dry-run`

Explication des commandes :
* `systemctl --user cat` : affiche l'unité générée réelle, utile pour vérifier ce que Quadlet produit effectivement.
* `status --no-pager -l` : montre l'état complet sans couper les lignes.
* `curl -I` : vérifie rapidement la disponibilité HTTP.
* `podman auto-update --dry-run` : teste la détection de mise à jour sans rien changer.

== Remarques ==
* Service simple, stateless, basé sur ghcr.io/gchq/cyberchef:latest avec AutoUpdate=registry.
* Correction importante appliquée : il faut utiliser le Quadlet comme source de vérité. Un ancien service systemd manuel lançant `podman run --label io.containers.autoupdate=registry ...` cassait `podman auto-update` car il n'ajoutait pas correctement le label `PODMAN_SYSTEMD_UNIT` attendu.
* Ne pas recréer de service manuel parallèle tant que le Quadlet remplit le besoin.

== Données / emplacements à sauvegarder ==
* /home/loic/.config/containers/systemd/cyberchef.container
* éventuellement le bloc Caddy correspondant si modifié

== Sauvegarde ==
* Sauvegarder le quadlet cyberchef.container suffit généralement, le service étant stateless.
* Sauvegarder aussi la configuration proxy si l'exposition publique évolue.

== Restauration ==
* Restaurer le quadlet cyberchef.container.
* Recharger systemd user avec `systemctl --user daemon-reload`.
* Relancer le service avec `systemctl --user restart cyberchef.service`.
* Vérifier ensuite l'accès HTTP local et l'état de `podman auto-update --dry-run`.

== Maintenance documentaire ==
Lors d'un changement d'image, de port, de publication, d'auto-update ou de méthode de lancement, mettre à jour cette page.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Extensions

2026-04-12T16:57:50Z

Daneel : Documentation conteneurs enrichie: runtime, paramètres, ports, volumes, relance et diagnostic

Trace install tas

2026-04-11T08:50:49Z

Daneel : Séparation des ports publics et domaines dans le tableau

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Hugo]]
* [[Trace install tas - Trilium Notes]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Ports publics !! Domaines !! Rôle
|-
| Open WebUI || 8080 || 25680 || owui.lololand.org || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681 / 25692 || dt.lololand.org || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682 || vault.lololand.org || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || kuma.lololand.org || Supervision
|-
| Scriberr || 8084 || 25684 || || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || || OSINT / profils sociaux
|-
| Immich || 8088 || 25688 || immich.lololand.org || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689 || headscale.lololand.org || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691 || cyberchef.lololand.org || Outils de transformation
|-
| Beszel || 8093 || 25693 || bezel.lololand.org || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || || GED / OCR
|-
| Karakeep || 8095 || 25695 || || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || nextcloud.lololand.org || Fichiers / groupware
|-
| Homepage || 8097 || 25697 || home.lololand.org || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || wiki.lololand.org || Wiki collaboratif
|-
| n8n || 5678 || 25678 || n8n.lololand.org || Automatisation
|-
| Ollama || 11434 || 25434 || || API LLM locale
|-
| Hugo || 8100 || 25700 || hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701 || trilium.lololand.org || Base de connaissances / notes
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas

2026-04-11T08:49:28Z

Daneel : Correction du tableau : Hugo et Trilium

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Hugo]]
* [[Trace install tas - Trilium Notes]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Public / sous-domaines !! Rôle
|-
| Open WebUI || 8080 || 25680, owui.lololand.org || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681, 25692, dt.lololand.org || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682, vault.lololand.org || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683, kuma.lololand.org || Supervision
|-
| Scriberr || 8084 || 25684 || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || OSINT / profils sociaux
|-
| Immich || 8088 || 25688, immich.lololand.org || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689, headscale.lololand.org || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691, cyberchef.lololand.org || Outils de transformation
|-
| Beszel || 8093 || 25693, bezel.lololand.org || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || GED / OCR
|-
| Karakeep || 8095 || 25695 || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696, nextcloud.lololand.org || Fichiers / groupware
|-
| Homepage || 8097 || 25697, home.lololand.org || Tableau de bord
|-
| MediaWiki || 8098 || 25698, wiki.lololand.org || Wiki collaboratif
|-
| n8n || 5678 || 25678, n8n.lololand.org || Automatisation
|-
| Ollama || 11434 || 25434 || API LLM locale
|-
| Hugo || 8100 || 25700, hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701, trilium.lololand.org || Base de connaissances / notes
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas

2026-04-11T08:37:48Z

Daneel : Mise à jour du tableau avec les sous-domaines visibles dans Caddy

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Hugo]]
* [[Trace install tas - Trilium Notes]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Public / sous-domaines !! Rôle
|-
| Open WebUI || 8080 || 25680, owui.lololand.org || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681, 25692, dt.lololand.org || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682, vault.lololand.org || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683, kuma.lololand.org || Supervision
|-
| Scriberr || 8084 || 25684 || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || OSINT / profils sociaux
|-
| Immich || 8088 || 25688, immich.lololand.org || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689, headscale.lololand.org || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691, cyberchef.lololand.org || Outils de transformation
|-
| Beszel || 8093 || 25693, bezel.lololand.org || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || GED / OCR
|-
| Karakeep || 8095 || 25695 || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696, nextcloud.lololand.org || Fichiers / groupware
|-
| Homepage || 8097 || 25697, home.lololand.org || Tableau de bord
|-
| MediaWiki || 8098 || 25698, wiki.lololand.org || Wiki collaboratif
|-
| n8n || 5678 || 25678, n8n.lololand.org || Automatisation
|-
| Ollama || 11434 || 25434 || API LLM locale
|-
| Hugo || 8100 || hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701 || Base de connaissances / notes
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas

2026-04-11T08:23:29Z

Daneel : Correction de la trace centrale : réintégration de Trilium Notes

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Hugo]]
* [[Trace install tas - Trilium Notes]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Public !! Rôle
|-
| Open WebUI || 8080 || 25680 || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681 / 25692 || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682 || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || Supervision
|-
| Scriberr || 8084 || 25684 || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || OSINT / profils sociaux
|-
| Immich || 8088 || 25688 || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689 || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691 || Outils de transformation
|-
| Beszel || 8093 || 25693 || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || GED / OCR
|-
| Karakeep || 8095 || 25695 || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || Fichiers / groupware
|-
| Homepage || 8097 || 25697 || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || Wiki collaboratif
|-
| n8n || 5678 || 25678 || Automatisation
|-
| Ollama || 11434 || 25434 || API LLM locale
|-
| Hugo || 8100 || hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701 || Base de connaissances / notes
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas

2026-04-11T07:45:57Z

Daneel : Mise à jour de la trace centrale avec Hugo

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Hugo]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Public !! Rôle
|-
| Open WebUI || 8080 || 25680 || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681 / 25692 || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682 || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || Supervision
|-
| Scriberr || 8084 || 25684 || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || OSINT / profils sociaux
|-
| Immich || 8088 || 25688 || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689 || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691 || Outils de transformation
|-
| Beszel || 8093 || 25693 || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || GED / OCR
|-
| Karakeep || 8095 || 25695 || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || Fichiers / groupware
|-
| Homepage || 8097 || 25697 || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || Wiki collaboratif
|-
| n8n || 5678 || 25678 || Automatisation
|-
| Ollama || 11434 || 25434 || API LLM locale
|-
| Hugo || 8100 || hugo.lololand.org || Site statique / documentation
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas - Hugo

2026-04-11T07:45:57Z

Daneel : Ajout de la trace d'installation de Hugo

= Trace install tas - Hugo =

== Rôle ==
Site statique de documentation Hugo servi sur tas via un conteneur Nginx.

== Accès ==
* Local : http://127.0.0.1:8100
* Public : https://hugo.lololand.org/

== Ports ==
8100 local, 443 public via domaine dédié

== Exécution / runtime ==
Quadlet systemd user : hugo-docs.container ; conteneur hugo-docs ; unité générée : hugo-docs.service

== Chemins de configuration ==
* /home/loic/.config/containers/systemd/hugo-docs.container
* /home/loic/sites/hugo-docs/hugo.toml
* /home/loic/sites/hugo-docs/publish.sh
* /etc/caddy/Caddyfile

== Volumes / persistance ==
* /home/loic/sites/hugo-docs/public:/usr/share/nginx/html:ro

== Dépendances ==
* network-online.target
* Caddy sur le domaine `hugo.lololand.org`
* publication statique générée dans `/home/loic/sites/hugo-docs/public`

== Installation ==
* Image de service : docker.io/library/nginx:alpine
* Déploiement rootless via Quadlet Podman
* Publication locale : 8100 -> 80 dans le conteneur
* Service actif : hugo-docs.service
* Build du site via `publish.sh`, qui lance `docker.io/klakegg/hugo:ext-alpine` dans un conteneur Podman et génère le contenu dans `./public`

== Configuration Hugo ==
* baseURL = https://hugo.lololand.org/
* languageCode = fr-fr
* title = Hugo Docs Tas
* enableRobotsTXT = true

== Vérifications post-installation ==
* `systemctl --user status hugo-docs.service`
* `curl -I http://127.0.0.1:8100`
* vérifier le domaine public `https://hugo.lololand.org/`

== Supervision ==
Le service est déjà supervisé par Uptime Kuma, comme montré par les requêtes User-Agent `Uptime-Kuma/2.2.1` dans les logs du conteneur.

== Données / emplacements à sauvegarder ==
* Sources Hugo : /home/loic/sites/hugo-docs
* Statique publié : /home/loic/sites/hugo-docs/public
* Quadlet : /home/loic/.config/containers/systemd/hugo-docs.container

== Sauvegarde ==
* Sauvegarder /home/loic/sites/hugo-docs
* Sauvegarder le quadlet hugo-docs.container
* Sauvegarder la configuration Caddy associée au domaine `hugo.lololand.org`

== Restauration ==
* Restaurer /home/loic/sites/hugo-docs
* Restaurer le quadlet hugo-docs.container
* Regénérer le site si nécessaire via `publish.sh`
* Relancer `systemctl --user daemon-reload` puis `systemctl --user start hugo-docs.service`

== Maintenance documentaire ==
Lors d'un changement d'image, de domaine, de port, de chemin de build ou de mode de publication, mettre à jour cette page et la trace centrale.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].

Trace install tas

2026-04-11T06:55:20Z

Daneel : Mise à jour de la trace centrale avec Trilium Notes

= trace install tas =

Cette page sert de '''trace d'installation''' pour les principales briques logicielles déployées sur la machine '''tas'''.

== Objectif ==
Documenter, pour chaque brique logicielle :
* son rôle
* son exposition locale et publique
* ses ports
* ses conteneurs / services
* ses remarques d'installation et de configuration

== Règle générale de déploiement ==
Les installations doivent privilégier :
* des '''images Podman'''
* '''gérées par des services'''
* et '''mises à jour régulièrement'''

== Pages spécifiques ==
* [[Trace install tas - Open WebUI]]
* [[Trace install tas - Dependency-Track]]
* [[Trace install tas - Vaultwarden]]
* [[Trace install tas - Uptime Kuma]]
* [[Trace install tas - Scriberr]]
* [[Trace install tas - Social Analyzer]]
* [[Trace install tas - Immich]]
* [[Trace install tas - Headscale]]
* [[Trace install tas - CyberChef]]
* [[Trace install tas - Beszel]]
* [[Trace install tas - Paperless-ngx]]
* [[Trace install tas - Karakeep]]
* [[Trace install tas - Nextcloud]]
* [[Trace install tas - Homepage]]
* [[Trace install tas - MediaWiki]]
* [[Trace install tas - n8n]]
* [[Trace install tas - Ollama]]
* [[Trace install tas - Trilium Notes]]

== Vue synthétique ==
{| class="wikitable"
! Brique !! Local !! Public !! Rôle
|-
| Open WebUI || 8080 || 25680 || Interface LLM
|-
| Dependency-Track || 8081 / 8092 || 25681 / 25692 || SBOM / vuln
|-
| Vaultwarden || 8082 || 25682 || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || Supervision
|-
| Scriberr || 8084 || 25684 || Speech-to-text
|-
| Social Analyzer || 8086 || 25686 || OSINT / profils sociaux
|-
| Immich || 8088 || 25688 || Gestion photo
|-
| Headscale || 8089 / 8090 || 25689 || Tailscale self-hosted + UI
|-
| CyberChef || 8091 || 25691 || Outils de transformation
|-
| Beszel || 8093 || 25693 || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || GED / OCR
|-
| Karakeep || 8095 || 25695 || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || Fichiers / groupware
|-
| Homepage || 8097 || 25697 || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || Wiki collaboratif
|-
| n8n || 5678 || 25678 || Automatisation
|-
| Ollama || 11434 || 25434 || API LLM locale
|-
| Trilium Notes || 8101 || 25701 || Base de connaissances / notes
|}

== Remarque ==
Cette documentation est une trace opérationnelle. Elle doit évoluer lorsque :
* de nouveaux services sont ajoutés
* des ports changent
* les méthodes d'installation ou de mise à jour changent

Trace install tas - Trilium Notes

2026-04-11T06:55:20Z

Daneel : Ajout de la trace d'installation de Trilium Notes

= Trace install tas - Trilium Notes =

== Rôle ==
Base de connaissances personnelle auto-hébergée (notes, arborescences, recherche, synchronisation web).

== Accès ==
* Local : http://127.0.0.1:8101
* Public : https://lololand.hopto.org:25701

== Ports ==
8101 local, 25701 public

== Exécution / runtime ==
Quadlet systemd user : trilium.container ; conteneur trilium ; unité générée : trilium.service

== Chemins de configuration ==
* /home/loic/.config/containers/systemd/trilium.container
* /etc/caddy/Caddyfile

== Volumes / persistance ==
* /home/loic/trilium-data:/home/node/trilium-data

== Variables d'environnement ==
* TRILIUM_DATA_DIR=/home/node/trilium-data
* TZ=Europe/Paris

== Dépendances ==
* network-online.target
* Caddy 25701 -> 8101
* podman-auto-update.timer pour les mises à jour automatiques de l'image

== Installation ==
* Image utilisée : docker.io/triliumnext/notes:latest
* Déploiement rootless via Quadlet Podman
* Publication locale : 8101 -> 8080 dans le conteneur
* Démarrage du service via l'unité générée trilium.service après `systemctl --user daemon-reload`

== Vérifications post-installation ==
* `systemctl --user status trilium.service`
* `curl -I http://127.0.0.1:8101`
* `curl -Ik https://lololand.hopto.org:25701`

== Supervision ==
Uptime Kuma :
* Nom : Trilium Notes
* Type : HTTP(s)
* URL : https://lololand.hopto.org:25701
* Intervalle : 60 secondes
* Codes acceptés : 200-399

== Données / emplacements à sauvegarder ==
* Données applicatives : /home/loic/trilium-data
* Quadlet : /home/loic/.config/containers/systemd/trilium.container
* Reverse proxy : /etc/caddy/Caddyfile

== Sauvegarde ==
* Sauvegarder /home/loic/trilium-data
* Sauvegarder le quadlet trilium.container
* Sauvegarder /etc/caddy/Caddyfile avant modification

== Restauration ==
* Restaurer /home/loic/trilium-data
* Restaurer le quadlet trilium.container
* Restaurer /etc/caddy/Caddyfile si le reverse proxy doit être annulé
* Relancer `systemctl --user daemon-reload` puis `systemctl --user start trilium.service`

== Maintenance documentaire ==
Lors d'un changement d'image, de port, de volume, de reverse proxy ou de supervision, mettre à jour cette page et la trace centrale.

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].