Loic Wiki - Contributions [fr]

Trace install tas

2026-09-09T20:46:42Z

Daneel : Documenter l accès VPN OpenHands dans la trace 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]]
* [[Trace install tas - SGLang]]
* [[Trace install tas - DeepSeek Harness (DSH)]]

== Vue synthétique ==

Les ports locaux et publics ci-dessous sont alignés sur les publications et reverse-proxy observés dans <code>/etc/caddy/Caddyfile</code> le 14 août 2026. Un port local peut rester fermé lorsqu’un service est arrêté ou en échec.

{| class="wikitable"
! Brique !! Local !! Port public Caddy !! Domaine / accès !! Rôle / état
|-
| Open WebUI || 8085 || 25680 || owui.lololand.org || Interface LLM
|-
| Dependency-Track frontend || 8103 || 25681 || dt.lololand.org || Frontend ; répond HTTP 200
|-
| Dependency-Track API || 8092 || 25692 || lololand.hopto.org:25692 || Backend ; service arrêté sur base H2 corrompue
|-
| Vaultwarden || 8082 || 25682 || vault.lololand.org || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || kuma.lololand.org || Supervision
|-
| Scriberr || 8084 || 25684 || lololand.hopto.org:25684 || Speech-to-text
|-
| CyberBro || 8102 || 25685 || cyberbro.lololand.org || Analyse / visualisation
|-
| Social Analyzer || 8086 || 25686 || social-analyzer.lololand.org || OSINT ; racine HTTP 404 mais service répond
|-
| Greenbone OpenVAS || 9392 || 25687 || lololand.hopto.org:25687 || Scanner ; GSA non disponible pendant la relance
|-
| Immich || 8088 || 25688 || immich.lololand.org || Gestion photo
|-
| Headscale + UI || 8089 / 8090 || 25689 || headscale.lololand.org || Contrôle réseau privé + interface
|-
| CyberChef || 8091 || 25691 || cyberchef.lololand.org || Outils de transformation ; corrigé et HTTP 200
|-
| Beszel || 8093 || 25693 || bezel.lololand.org || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || paperless.lololand.org || GED / OCR
|-
| Karakeep || 8095 || 25695 || karakeep.lololand.org || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || nextcloud.lololand.org || Fichiers / groupware ; état applicatif sain
|-
| Homepage || 8097 || 25697 || lololand.hopto.org:25697 || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || wiki.lololand.org || Wiki collaboratif
|-
| n8n || 5678 || 25678 || n8n.lololand.org || Automatisation
|-
| Ollama AMD || 11434 || 25434 || ollama.lololand.org || API LLM protégée
|-
| Hugo || 8100 || 25700 || hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701 || trilium.lololand.org || Base de connaissances / notes
|-
| Gitea || 8105 || 25702 || gitea.lololand.org || Forge Git
|-
| Stalwart || 1025 / 1110 / 1143 / 1465 / 1587 / 1993 / 1995 / 14190 / 18080 / 18443 || aucun déclaré par Caddy || mail.lololand.org / lololand.org || Serveur mail
|-
| Hermes Agent || 8642 || aucun || accès local || Agent IA outillé
|-
| DeepSeek Harness (DSH) || 3080 || aucun || accès local || Interface Web d’agent de codage
|}

== État de vérification — 14 août 2026 ==

* '''Firewall :''' les entrées sont maintenues fermées temporairement pendant l’audit et les corrections. La règle active nftables nécessite une vérification root pour être détaillée.
* '''Nextcloud :''' le service et la base sont actifs ; <code>php occ status</code> indique Nextcloud 34.0.2, maintenance désactivée et aucune mise à niveau de base en attente. Le HTTP local redirige vers l’URL canonique HTTPS.
* '''Dependency-Track :''' le frontend 8103 répond ; l’API 8092 est indisponible. Les journaux indiquent une corruption H2 (<code>MVStoreException: Chunk 102363 not found</code>). Le volume a été sauvegardé avant toute tentative de correction.
* '''Social Analyzer :''' le conteneur et le port 8086 répondent ; la racine renvoie HTTP 404, ce qui indique une route applicative absente plutôt qu’un port fermé.
* '''Greenbone OpenVAS :''' la relance a été tentée sans suppression de volumes. La pile reste en initialisation avec des dépendances de flux en état unhealthy ; 9392 n’est pas encore disponible.
* '''CyberChef :''' corrigé. L’image écoute sur 8080 dans le conteneur, alors que le Quadlet publiait 8091 vers 80 ; le mapping est maintenant 8091:8080 et le test local renvoie HTTP 200.
* '''Tailscale :''' le client système est installé et actif. Sa suppression nécessite les privilèges root ; Headscale est un service distinct et n’a pas été supprimé.

''Les actions ayant modifié des services ou fichiers ont conservé une sauvegarde préalable dans <code>/home/loic/backups/</code>.''

== DeepSeek Harness (DSH) ==

DSH est déployé sur <code>tas</code> en Podman rootless avec l’image locale
<code>localhost/deepseek-harness:0.1.0-rc.7</code>. L’unité Quadlet génère
<code>deepseek-harness.service</code>, qui écoute uniquement sur
<code>127.0.0.1:3080</code>.

* '''Commande :''' <code>dsh web --host 127.0.0.1 --port 3080 --no-open</code>
* '''Automatisation :''' <code>deepseek-harness-autostart.service</code>, unité systemd utilisateur activée dans <code>default.target</code>.
* '''Démarrage :''' <code>systemctl --user start deepseek-harness-autostart.service</code>
* '''Arrêt :''' <code>systemctl --user stop deepseek-harness.service</code>
* '''Contrôle :''' <code>curl -fsS http://127.0.0.1:3080/</code> et <code>podman ps --filter name=deepseek-harness</code>.
* '''Exploitation détaillée :''' [[Trace install tas - DeepSeek Harness (DSH)]].

== ngrok ==

ngrok fournit un tunnel HTTPS public vers le point d’entrée Caddy local.
Le domaine fixe est configuré dans le service utilisateur
<code>ngrok-8080.service</code>.

* Commande : <code>ngrok http --url=https://noella-oxidizable-nonsuppositively.ngrok-free.dev 8099 --config /home/loic/.config/ngrok/ngrok.yml</code>
* Automatisation : unité systemd utilisateur, activée dans <code>default.target</code>, avec redémarrage automatique après panne.
* Démarrage : <code>systemctl --user start ngrok-8080.service</code>
* Arrêt : <code>systemctl --user stop ngrok-8080.service</code>
* Exploitation détaillée : [[Trace install tas - ngrok]]

== 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

== État d’exploitation actuel — 2026-07-25 ==

L'exploitation courante repose sur '''Podman rootless + Quadlet + systemd utilisateur''', avec Caddy comme reverse proxy public. Les sources de vérité sont :

* Quadlet : <code>/home/loic/.config/containers/systemd/</code>
* systemd utilisateur : <code>/home/loic/.config/systemd/user/</code>
* Caddy : <code>/etc/caddy/Caddyfile</code>
* Documentation locale : <code>/home/loic/mediawiki/docs/</code>
* Index thématique des pages : <code>/home/loic/clawd/wiki-mediawiki-index.md</code>

Les ports hôte <code>8080</code> et <code>8081</code> sont réservés et ne doivent pas être publiés par un conteneur. Les pages spécifiques MediaWiki, Immich et Ollama ont été actualisées pour refléter leurs unités Quadlet et leurs chemins de données actuels.

== Gitea ==

* [[Trace install tas - Gitea]] : service Git exécuté par Podman rootless + Quadlet.
* Image Gitea versionnée : <code>docker.io/gitea/gitea:1.27.1</code>.
* Image PostgreSQL versionnée : <code>docker.io/library/postgres:17.10</code>.
* Accès local : <code>127.0.0.1:8105</code> ; URL canonique : <code>https://gitea.lololand.org/</code> ; accès externe alternatif : <code>https://lololand.hopto.org:25702/</code>.
* Le mot de passe PostgreSQL est fourni par le secret Podman <code>gitea-postgres-password</code> et ne figure plus dans les Quadlets.

== Mise à jour 2026-08-15 — PostgreSQL, SBOM et tableau de bord ==
* Dependency-Track utilise PostgreSQL neuf ; voir [[Trace install tas - Dependency-Track PostgreSQL et SBOM]].
* Trivy et OSV-Scanner ont alimenté les projets SBOM du serveur tas ; voir [[Trace install tas - OSV-Scanner]].
* Homarr est disponible localement sur 8106 avec les signets des services et les widgets Beszel ; voir [[Trace install tas - Homarr]].

== Mise à jour 2026-08-20 — SGLang Qwen3.8 W8A8 ==
* Le service [[Trace install tas - SGLang|SGLang]] est maintenant actif sur la RX 7900 XTX avec une image ROCm dédiée à <code>gfx1100</code>.
* Modèle : <code>qwen3.8-27b-w8a8</code>, contexte 32 768, API locale <code>127.0.0.1:30000/v1</code>.
* Quadlet rootless : <code>sglang.service</code> ; conteneur <code>sglang-qwen38-w8a8</code>.
* Le test déterministe <code>17 + 25</code> renvoie <code>42</code> avant et après redémarrage.
* Le profil consomme environ 22,5 Go de VRAM ; éviter de charger simultanément un gros modèle Ollama.

== Dify — 2026-09-09 ==
* [[Trace install tas - Dify]] : Dify Community Edition 1.17.0 en Podman rootless, frontend local 8107, URL préparée https://dify.lololand.org, mise à jour hebdomadaire par dify-update.timer.

== OpenHands — 2026-09-09 ==

OpenHands est installé via le Quadlet rootless <code>/home/loic/.config/containers/systemd/openhands.container</code>, avec l'interface locale sur <code>127.0.0.1:8108</code>. Sa sandbox personnalisée contient OpenCode CLI et Trivy, et rejoint le réseau <code>dify_default</code> pour accéder à Dify. Voir [[Trace install tas - OpenHands]].

== OpenHands — accès VPN — 2026-09-09 ==

OpenHands est maintenant publié sur <code>10.8.0.1:8108</code>, l’adresse de l’interface VPN, tout en conservant <code>127.0.0.1:8108</code> pour l’accès local. L’adresse LAN <code>192.168.1.55:8108</code> reste volontairement non publiée.

Trace install tas - OpenHands

2026-09-09T20:46:42Z

Daneel : Ajouter l accès VPN OpenHands

= Trace install tas - OpenHands =

== État ==

'''Déployé et validé le 9 septembre 2026''' sur tas.

* Service : <code>openhands.service</code>, Quadlet Podman rootless systemd utilisateur.
* Interface locale : <code>http://127.0.0.1:8108</code> (hôte uniquement).
* Interface VPN : <code>http://10.8.0.1:8108</code>.
* URL publique prévue : <code>https://openhands.lololand.org</code>.
* Données : <code>/home/loic/.openhands</code>.
* Workspace : <code>/home/loic/openhands/workspace</code>.

== Runtime et outils ==

Le runtime est construit depuis l’image officielle <code>ghcr.io/openhands/agent-server:1.26.0-python</code> dans l’image locale <code>localhost/openhands-runtime-tools:1.26.0-1</code>.

* OpenCode CLI <code>1.14.48</code>, configuré sans secret vers Ollama.
* Trivy <code>0.74.0</code>.
* Ollama : <code>http://host.containers.internal:11434</code>.
* Dify : <code>http://docker_nginx_1</code> via le réseau Podman <code>dify_default</code>.

Les sandboxes rejoignent <code>dify_default</code> avec <code>SANDBOX_ADDITIONAL_NETWORKS</code>. Un test équivalent a confirmé HTTP 200 vers Dify et Ollama, ainsi que la disponibilité d’OpenCode et Trivy.

== Mises à jour ==

Le timer <code>openhands-update.timer</code> détecte automatiquement les dernières versions publiées de Trivy et OpenCode, reconstruit l’image runtime avec <code>--pull=always</code> puis redémarre le service chaque dimanche vers 05:00. L’image UI porte aussi <code>AutoUpdate=registry</code>. Les versions détectées sont enregistrées dans le journal systemd.

== Caddy ==

<syntaxhighlight lang="caddy">
openhands.lololand.org {
reverse_proxy 127.0.0.1:8108
}
</syntaxhighlight>

== Retour arrière ==

Le Quadlet et la documentation précédents sont sauvegardés sous <code>/home/loic/backups/openhands-20260909-175838/</code>. Les credentials OpenCode de l’hôte et les clés OpenRouter ne sont pas montés dans le runtime.

Trace install tas - OpenHands

2026-09-09T19:39:19Z

Daneel : Automatiser les mises à jour Trivy et OpenCode

= Trace install tas - OpenHands =

== État ==

'''Déployé et validé le 9 septembre 2026''' sur tas.

* Service : <code>openhands.service</code>, Quadlet Podman rootless systemd utilisateur.
* Interface locale : <code>http://127.0.0.1:8108</code>.
* URL publique prévue : <code>https://openhands.lololand.org</code>.
* Données : <code>/home/loic/.openhands</code>.
* Workspace : <code>/home/loic/openhands/workspace</code>.

== Runtime et outils ==

Le runtime est construit depuis l’image officielle <code>ghcr.io/openhands/agent-server:1.26.0-python</code> dans l’image locale <code>localhost/openhands-runtime-tools:1.26.0-1</code>.

* OpenCode CLI <code>1.14.48</code>, configuré sans secret vers Ollama.
* Trivy <code>0.74.0</code>.
* Ollama : <code>http://host.containers.internal:11434</code>.
* Dify : <code>http://docker_nginx_1</code> via le réseau Podman <code>dify_default</code>.

Les sandboxes rejoignent <code>dify_default</code> avec <code>SANDBOX_ADDITIONAL_NETWORKS</code>. Un test équivalent a confirmé HTTP 200 vers Dify et Ollama, ainsi que la disponibilité d’OpenCode et Trivy.

== Mises à jour ==

Le timer <code>openhands-update.timer</code> détecte automatiquement les dernières versions publiées de Trivy et OpenCode, reconstruit l’image runtime avec <code>--pull=always</code> puis redémarre le service chaque dimanche vers 05:00. L’image UI porte aussi <code>AutoUpdate=registry</code>. Les versions détectées sont enregistrées dans le journal systemd.

== Caddy ==

<syntaxhighlight lang="caddy">
openhands.lololand.org {
reverse_proxy 127.0.0.1:8108
}
</syntaxhighlight>

== Retour arrière ==

Le Quadlet et la documentation précédents sont sauvegardés sous <code>/home/loic/backups/openhands-20260909-175838/</code>. Les credentials OpenCode de l’hôte et les clés OpenRouter ne sont pas montés dans le runtime.

Trace install tas

2026-09-09T16:01:21Z

Daneel : Ajouter OpenHands à la trace centrale

Trace install tas - OpenHands

2026-09-09T16:00:59Z

Daneel : Documenter l installation OpenHands

= Trace install tas - OpenHands =

== État ==

'''Déployé et validé le 9 septembre 2026''' sur tas.

* Service : <code>openhands.service</code>, Quadlet Podman rootless systemd utilisateur.
* Interface locale : <code>http://127.0.0.1:8108</code>.
* URL publique prévue : <code>https://openhands.lololand.org</code>.
* Données : <code>/home/loic/.openhands</code>.
* Workspace : <code>/home/loic/openhands/workspace</code>.

== Runtime et outils ==

Le runtime est construit depuis l’image officielle <code>ghcr.io/openhands/agent-server:1.26.0-python</code> dans l’image locale <code>localhost/openhands-runtime-tools:1.26.0-1</code>.

* OpenCode CLI <code>1.14.48</code>, configuré sans secret vers Ollama.
* Trivy <code>0.74.0</code>.
* Ollama : <code>http://host.containers.internal:11434</code>.
* Dify : <code>http://docker_nginx_1</code> via le réseau Podman <code>dify_default</code>.

Les sandboxes rejoignent <code>dify_default</code> avec <code>SANDBOX_ADDITIONAL_NETWORKS</code>. Un test équivalent a confirmé HTTP 200 vers Dify et Ollama, ainsi que la disponibilité d’OpenCode et Trivy.

== Mises à jour ==

Le timer <code>openhands-update.timer</code> reconstruit l’image runtime avec <code>--pull=always</code> puis redémarre le service chaque dimanche vers 05:00. L’image UI porte aussi <code>AutoUpdate=registry</code>.

== Caddy ==

<syntaxhighlight lang="caddy">
openhands.lololand.org {
reverse_proxy 127.0.0.1:8108
}
</syntaxhighlight>

== Retour arrière ==

Le Quadlet et la documentation précédents sont sauvegardés sous <code>/home/loic/backups/openhands-20260909-175838/</code>. Les credentials OpenCode de l’hôte et les clés OpenRouter ne sont pas montés dans le runtime.

Trace install tas

2026-09-09T10:00:44Z

Daneel : Ajouter Dify à la trace centrale

Trace install tas - Dify

2026-09-09T10:00:44Z

Daneel : Documenter le déploiement Dify sur tas

= Trace install tas - Dify =

== État ==

'''Déployé et validé le 9 septembre 2026''' sur tas avec Dify Community Edition '''1.17.0'''.

* Runtime : Podman rootless sous l’utilisateur <code>loic</code>.
* Service : <code>dify.service</code>.
* Mise à jour : <code>dify-update.timer</code>, hebdomadaire, avec <code>podman-compose pull</code> puis <code>up -d</code>.
* Répertoire runtime : <code>/home/loic/dify</code>.
* Documentation locale : <code>/home/loic/mediawiki/docs/dify.md</code>.
* Artefacts Nextcloud : <code>minidev/dify/</code>.

== Architecture et ports ==

La stack officielle comprend API, web, workers, PostgreSQL, Redis, Weaviate,
plugin daemon, agent backend, sandboxes et proxies SSRF.

* Frontend local : <code>127.0.0.1:8107</code>.
* HTTPS Dify interne : <code>127.0.0.1:8443</code>.
* URL préparée : <code>https://dify.lololand.org</code>.
* Caddy doit relayer vers <code>127.0.0.1:8107</code>.
* Les données persistantes sont dans <code>/home/loic/dify/docker/volumes/</code>.

Bloc Caddy à copier :

<syntaxhighlight lang="caddy">
dify.lololand.org {
reverse_proxy 127.0.0.1:8107
}
</syntaxhighlight>

== Modèles ==

Ollama est joignable depuis le conteneur API par
<code>http://host.containers.internal:11434</code> ; le test API local a répondu
HTTP 200. OpenRouter se configure via le fournisseur OpenAI-compatible avec la
base <code>https://openrouter.ai/api/v1</code>. La clé OpenRouter est saisie dans
l’interface Dify et ne figure ni dans les fichiers, ni dans le wiki.

== Contrôle et sauvegarde ==

<syntaxhighlight lang="bash">
systemctl --user status dify.service dify-update.timer
curl -I http://127.0.0.1:8107/install
podman ps --format '{{.Names}}\t{{.Status}}' | grep '^docker_'
podman exec docker_db_postgres_1 pg_dump -U postgres -d dify --format=custom > dify.dump
</syntaxhighlight>

Ne pas utiliser <code>podman-compose down -v</code>. La sauvegarde PostgreSQL
créée pendant l’installation est conservée dans
<code>/home/loic/backups/dify-20260909-115516/</code>.

Trace install tas

2026-08-18T19:38:54Z

Daneel : Ajouter la trace SGLang ROCm

= 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 ==

Les ports locaux et publics ci-dessous sont alignés sur les publications et reverse-proxy observés dans <code>/etc/caddy/Caddyfile</code> le 14 août 2026. Un port local peut rester fermé lorsqu’un service est arrêté ou en échec.

{| class="wikitable"
! Brique !! Local !! Port public Caddy !! Domaine / accès !! Rôle / état
|-
| Open WebUI || 8085 || 25680 || owui.lololand.org || Interface LLM
|-
| Dependency-Track frontend || 8103 || 25681 || dt.lololand.org || Frontend ; répond HTTP 200
|-
| Dependency-Track API || 8092 || 25692 || lololand.hopto.org:25692 || Backend ; service arrêté sur base H2 corrompue
|-
| Vaultwarden || 8082 || 25682 || vault.lololand.org || Gestion de secrets
|-
| Uptime Kuma || 8083 || 25683 || kuma.lololand.org || Supervision
|-
| Scriberr || 8084 || 25684 || lololand.hopto.org:25684 || Speech-to-text
|-
| CyberBro || 8102 || 25685 || cyberbro.lololand.org || Analyse / visualisation
|-
| Social Analyzer || 8086 || 25686 || social-analyzer.lololand.org || OSINT ; racine HTTP 404 mais service répond
|-
| Greenbone OpenVAS || 9392 || 25687 || lololand.hopto.org:25687 || Scanner ; GSA non disponible pendant la relance
|-
| Immich || 8088 || 25688 || immich.lololand.org || Gestion photo
|-
| Headscale + UI || 8089 / 8090 || 25689 || headscale.lololand.org || Contrôle réseau privé + interface
|-
| CyberChef || 8091 || 25691 || cyberchef.lololand.org || Outils de transformation ; corrigé et HTTP 200
|-
| Beszel || 8093 || 25693 || bezel.lololand.org || Monitoring léger
|-
| Paperless-ngx || 8094 || 25694 || paperless.lololand.org || GED / OCR
|-
| Karakeep || 8095 || 25695 || karakeep.lololand.org || Gestion de bookmarks
|-
| Nextcloud || 8096 || 25696 || nextcloud.lololand.org || Fichiers / groupware ; état applicatif sain
|-
| Homepage || 8097 || 25697 || lololand.hopto.org:25697 || Tableau de bord
|-
| MediaWiki || 8098 || 25698 || wiki.lololand.org || Wiki collaboratif
|-
| n8n || 5678 || 25678 || n8n.lololand.org || Automatisation
|-
| Ollama AMD || 11434 || 25434 || ollama.lololand.org || API LLM protégée
|-
| Hugo || 8100 || 25700 || hugo.lololand.org || Site statique / documentation
|-
| Trilium Notes || 8101 || 25701 || trilium.lololand.org || Base de connaissances / notes
|-
| Gitea || 8105 || 25702 || gitea.lololand.org || Forge Git
|-
| Stalwart || 1025 / 1110 / 1143 / 1465 / 1587 / 1993 / 1995 / 14190 / 18080 / 18443 || aucun déclaré par Caddy || mail.lololand.org / lololand.org || Serveur mail
|-
| Hermes Agent || 8642 || aucun || accès local || Agent IA outillé
|}

== État de vérification — 14 août 2026 ==

* '''Firewall :''' les entrées sont maintenues fermées temporairement pendant l’audit et les corrections. La règle active nftables nécessite une vérification root pour être détaillée.
* '''Nextcloud :''' le service et la base sont actifs ; <code>php occ status</code> indique Nextcloud 34.0.2, maintenance désactivée et aucune mise à niveau de base en attente. Le HTTP local redirige vers l’URL canonique HTTPS.
* '''Dependency-Track :''' le frontend 8103 répond ; l’API 8092 est indisponible. Les journaux indiquent une corruption H2 (<code>MVStoreException: Chunk 102363 not found</code>). Le volume a été sauvegardé avant toute tentative de correction.
* '''Social Analyzer :''' le conteneur et le port 8086 répondent ; la racine renvoie HTTP 404, ce qui indique une route applicative absente plutôt qu’un port fermé.
* '''Greenbone OpenVAS :''' la relance a été tentée sans suppression de volumes. La pile reste en initialisation avec des dépendances de flux en état unhealthy ; 9392 n’est pas encore disponible.
* '''CyberChef :''' corrigé. L’image écoute sur 8080 dans le conteneur, alors que le Quadlet publiait 8091 vers 80 ; le mapping est maintenant 8091:8080 et le test local renvoie HTTP 200.
* '''Tailscale :''' le client système est installé et actif. Sa suppression nécessite les privilèges root ; Headscale est un service distinct et n’a pas été supprimé.

''Les actions ayant modifié des services ou fichiers ont conservé une sauvegarde préalable dans <code>/home/loic/backups/</code>.''

== 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\n\n== État d’exploitation actuel — 2026-07-25 ==

L'exploitation courante repose sur '''Podman rootless + Quadlet + systemd utilisateur''', avec Caddy comme reverse proxy public. Les sources de vérité sont :

* Quadlet : <code>/home/loic/.config/containers/systemd/</code>
* systemd utilisateur : <code>/home/loic/.config/systemd/user/</code>
* Caddy : <code>/etc/caddy/Caddyfile</code>
* Documentation locale : <code>/home/loic/mediawiki/docs/</code>
* Index thématique des pages : <code>/home/loic/clawd/wiki-mediawiki-index.md</code>

Les ports hôte <code>8080</code> et <code>8081</code> sont réservés et ne doivent pas être publiés par un conteneur. Les pages spécifiques MediaWiki, Immich et Ollama ont été actualisées pour refléter leurs unités Quadlet et leurs chemins de données actuels.

== Gitea ==

* [[Trace install tas - Gitea]] : service Git exécuté par Podman rootless + Quadlet.
* Image Gitea versionnée : <code>docker.io/gitea/gitea:1.27.1</code>.
* Image PostgreSQL versionnée : <code>docker.io/library/postgres:17.10</code>.
* Accès local : <code>127.0.0.1:8105</code> ; URL canonique : <code>https://gitea.lololand.org/</code> ; accès externe alternatif : <code>https://lololand.hopto.org:25702/</code>.
* Le mot de passe PostgreSQL est fourni par le secret Podman <code>gitea-postgres-password</code> et ne figure plus dans les Quadlets.\n\n== Mise à jour 2026-08-15 — PostgreSQL, SBOM et tableau de bord ==\n* Dependency-Track utilise PostgreSQL neuf ; voir [[Trace install tas - Dependency-Track PostgreSQL et SBOM]].\n* Trivy et OSV-Scanner ont alimenté les projets SBOM du serveur tas ; voir [[Trace install tas - OSV-Scanner]].\n* Homarr est disponible localement sur 8106 avec les signets des services et les widgets Beszel ; voir [[Trace install tas - Homarr]].\n

== Mise à jour 2026-08-18 — SGLang ==
* Le Quadlet SGLang, l’image ROCm et le modèle Qwen2.5-Coder-32B-Instruct-AWQ ont été préparés ; voir [[Trace install tas - SGLang]].
* Le modèle est conservé sur <code>/media/loic/nem/sglang</code> et le port prévu est <code>127.0.0.1:30000</code>.
* Le service reste arrêté : l’image <code>lmsysorg/sglang:v0.5.17-rocm700-mi30x</code> détecte la RX 7900 XTX mais échoue sur <code>HIP error: invalid device function</code> dès une opération PyTorch GPU élémentaire. Une image compilée pour <code>gfx1100</code> est nécessaire.

Trace install tas - SGLang

2026-08-18T19:38:53Z

Daneel : Documenter le déploiement SGLang ROCm et le blocage gfx1100

{{Projet|SGLang}}
== SGLang ROCm — déploiement préparé ==

{{Encadré|couleur=orange|titre=État au 18 août 2026|contenu=Le Quadlet, l'image et le modèle sont installés, mais le service est arrêté : l'image SGLang ROCm testée ne fournit pas les kernels PyTorch nécessaires à la Radeon RX 7900 XTX (gfx1100).}}

=== Composants ===
* Quadlet : <code>/home/loic/.config/containers/systemd/sglang.container</code>
* Unité : <code>sglang.service</code>
* Image : <code>docker.io/lmsysorg/sglang:v0.5.17-rocm700-mi30x</code>
* Modèle : <code>Qwen/Qwen2.5-Coder-32B-Instruct-AWQ</code>
* Poids : <code>/media/loic/nem/sglang/models/Qwen2.5-Coder-32B-Instruct-AWQ</code>
* Taille des cinq safetensors : environ 19 Gio binaires, soit un peu plus de 20 Go décimaux
* Port prévu : <code>127.0.0.1:30000</code>
* Volume conteneur : <code>/models</code>
* GPU ciblé : Radeon RX 7900 XTX, 24 Gio, <code>gfx1100</code>

=== Procédure appliquée ===
# Vérification de Podman rootless, de la VRAM et de l'espace disponible.
# Création du répertoire persistant <code>/media/loic/nem/sglang</code>.
# Import de l'image ROCm SGLang et création du Quadlet.
# Téléchargement vérifiable du dépôt public Qwen avec reprise automatique.
# Test d'accès aux périphériques AMD : SGLang voit bien la Radeon RX 7900 XTX.
# Test de chargement réel du modèle.

=== Blocage identifié ===
Le test minimal suivant échoue dans l'image actuelle :
<syntaxhighlight lang="text">
torch.ones(1, device="cuda")
HIP error: invalid device function
</syntaxhighlight>

L'image <code>mi30x</code> détecte le GPU mais sa pile PyTorch/ROCm est compilée pour la famille Instinct. Les tentatives <code>HSA_OVERRIDE_GFX_VERSION=10.3.0</code> et <code>11.0.0</code> n'ont pas rendu le service fonctionnel : AITER refuse <code>gfx1030</code>, tandis que <code>gfx1100</code> reproduit l'erreur HIP. Le problème est donc une incompatibilité de kernels, pas un manque de VRAM ni un fichier de modèle incomplet.

Le service est laissé arrêté pour éviter un redémarrage en boucle. Il pourra reprendre avec une image SGLang/PyTorch compilée pour <code>gfx1100</code>, ou avec une image dédiée construite depuis une base ROCm Radeon. Le modèle et le Quadlet ne doivent pas être supprimés.

=== Contrôles et reprise ===
<syntaxhighlight lang="bash">
systemctl --user status sglang.service --no-pager
systemctl --user start sglang.service
curl -fsS http://127.0.0.1:30000/health
podman logs sglang
</syntaxhighlight>

=== Sauvegardes ===
* Déploiement : <code>/home/loic/backups/sglang-20260818T204121+0200/</code>
* Quadlet avant le dernier test GPU : <code>sglang.container.before-gfx-override</code>
* Sauvegardes des pages MediaWiki avant publication : sous-répertoire <code>wiki/</code> du dossier ci-dessus

=== Références ===
* [https://github.com/sgl-project/sglang/blob/main/docs/platforms/amd_gpu.md SGLang — AMD GPU]
* [https://github.com/sgl-project/sglang/issues/30599 Suivi officiel de l'activation Radeon RDNA3/RDNA4]
* [https://huggingface.co/Qwen/Qwen2.5-Coder-32B-Instruct-AWQ Qwen2.5-Coder-32B-Instruct-AWQ]

Trace install tas - Ollama

2026-08-13T22:48:57Z

Daneel : Documentation mise à jour Ollama ROCm et client

= Trace install tas - Ollama =

== Rôle ==
API locale de modèles LLM avec deux instances distinctes :
* une instance AMD/ROCm sur la Radeon RX 7900
* une instance NVIDIA/CUDA sur la GeForce RTX 3070

== Accès ==
=== Instance AMD / ROCm ===
* Local : http://10.8.0.1:11434
* Depuis le terminal local : `OLLAMA_HOST=http://127.0.0.1:11434`
* Public : https://lololand.hopto.org:25434

=== Instance NVIDIA / CUDA ===
* Local : http://10.8.0.1:11435
* Depuis le terminal local : `OLLAMA_HOST=http://127.0.0.1:11435`
* Pas d'exposition publique dédiée documentée à ce stade

== Ports ==
* 11434/tcp : serveur Ollama AMD / ROCm
* 11435/tcp : serveur Ollama NVIDIA / CUDA
* 25434/tcp : proxy public Caddy vers l'instance AMD/ROCm, protégé par basicauth

== Exécution / runtime ==
=== AMD / ROCm ===
* Service systemd user généré : `ollama-rocm.service`
* Conteneur : `ollama_roc`
* Image : `docker.io/ollama/ollama:rocm`
* Devices : `/dev/kfd`, `/dev/dri`

=== NVIDIA / CUDA ===
* Service systemd user généré : `ollama-nvidia.service`
* Conteneur : `ollama_nv`
* Image : `docker.io/ollama/ollama:latest`
* Intégration GPU : Podman + NVIDIA Container Toolkit + CDI
* Device CDI utilisé : `nvidia.com/gpu=all`

== Chemins de configuration ==
* `/home/loic/.config/containers/systemd/ollama-rocm.container`
* `/home/loic/.config/containers/systemd/ollama-nvidia.container`
* `/etc/caddy/Caddyfile`
* `/home/loic/.bashrc` (alias CLI)
* `/home/loic/upgrade/ollama-dual-gpu-plan.md`

== Volumes / persistance ==
* Stockage modèles partagé entre les deux instances : `/media/loic/nem/ollama`
* Montage conteneur : `/media/loic/nem/ollama -> /root/.ollama`

== Dépendances ==
* Caddy 25434 -> 11434 avec basicauth pour l'instance AMD/ROCm
* NVIDIA driver 580 open pour la RTX 3070
* NVIDIA Container Toolkit
* CDI NVIDIA généré dans `/var/run/cdi/nvidia.yaml`
* clients comme Open WebUI

== Remarques ==
* L'instance NVIDIA n'a fonctionné correctement qu'après mise en place de NVIDIA Container Toolkit et CDI.
* Le stockage de modèles est partagé entre les deux serveurs pour éviter les doublons disque.
* Par prudence, éviter les `ollama pull` simultanés sur les deux instances.
* Faire préférentiellement les opérations d'écriture (`pull`, `rm`, création de modèles) sur une seule instance à la fois.
* Le proxy public documenté actuellement cible uniquement l'instance AMD/ROCm.

== Utilisation CLI ==
=== Sélection explicite du serveur ===
Pour cibler un serveur particulier depuis le terminal local, utiliser `OLLAMA_HOST`.

Exemples :
<pre>
OLLAMA_HOST=http://127.0.0.1:11434 ollama list
OLLAMA_HOST=http://127.0.0.1:11434 ollama run qwen3

OLLAMA_HOST=http://127.0.0.1:11435 ollama list
OLLAMA_HOST=http://127.0.0.1:11435 ollama run qwen3
</pre>

=== Alias shell ===
Alias ajoutés dans `/home/loic/.bashrc` :
<pre>
alias ollama-amd='OLLAMA_HOST=http://127.0.0.1:11434 ollama'
alias ollama-nvidia='OLLAMA_HOST=http://127.0.0.1:11435 ollama'
</pre>

Exemples :
<pre>
ollama-amd list
ollama-amd run qwen3

ollama-nvidia list
ollama-nvidia run qwen3
</pre>

== Exemples de tests ==
=== Test basique de disponibilité ===
<pre>
curl http://127.0.0.1:11434/api/tags
curl http://127.0.0.1:11435/api/tags
</pre>

=== Questions de test ===
<pre>
OLLAMA_HOST=http://127.0.0.1:11434 ollama run qwen3 "Donne-moi un résumé en 3 phrases de la différence entre ROCm et CUDA."
OLLAMA_HOST=http://127.0.0.1:11435 ollama run qwen3 "Donne-moi un résumé en 3 phrases de la différence entre ROCm et CUDA."
</pre>

<pre>
OLLAMA_HOST=http://127.0.0.1:11434 ollama run qwen3 "Écris un haïku sur les GPU."
OLLAMA_HOST=http://127.0.0.1:11435 ollama run qwen3 "Écris un haïku sur les GPU."
</pre>

=== Vérifier le GPU utilisé côté NVIDIA ===
Les logs de `ollama-nvidia.service` doivent montrer une détection CUDA du type :
* `library=CUDA`
* `description="NVIDIA GeForce RTX 3070"`

== Supervision / diagnostic ==
=== État des services ===
<pre>
systemctl --user status ollama-rocm.service
systemctl --user status ollama-nvidia.service
</pre>

=== Journaux ===
<pre>
journalctl --user -u ollama-rocm.service -n 100 --no-pager
journalctl --user -u ollama-nvidia.service -n 100 --no-pager
</pre>

=== Vérifier la carte NVIDIA ===
<pre>
nvidia-smi
watch -n 1 nvidia-smi
</pre>

=== Vérifier que CDI voit le GPU ===
<pre>
nvidia-ctk cdi list
</pre>

=== Conteneurs actifs ===
<pre>
podman ps | grep -E 'ollama_roc|ollama_nv'
</pre>

=== Contrôler la réponse API ===
<pre>
curl http://127.0.0.1:11434/api/tags
curl http://127.0.0.1:11435/api/tags
</pre>

== Données / emplacements à sauvegarder ==
* `/media/loic/nem/ollama`
* `/home/loic/.config/containers/systemd/ollama-rocm.container`
* `/home/loic/.config/containers/systemd/ollama-nvidia.container`
* `/etc/caddy/Caddyfile`
* `/home/loic/.bashrc`

== Sauvegarde ==
* Sauvegarder le répertoire de modèles partagé `/media/loic/nem/ollama`.
* Sauvegarder les deux services systemd user Ollama.
* Sauvegarder la configuration Caddy liée à `25434`.

== Restauration ==
* Restaurer `/media/loic/nem/ollama`.
* Restaurer les fichiers systemd user `ollama.service` et `ollama-nvidia.service`.
* Recharger systemd user puis relancer les services :
<pre>
systemctl --user daemon-reload
systemctl --user restart ollama-rocm.service
systemctl --user restart ollama-nvidia.service
</pre>
* Vérifier ensuite `curl http://127.0.0.1:11434/api/tags` et `curl http://127.0.0.1:11435/api/tags`.

== Procédure de mise à jour — ROCm et client CLI ==

La procédure ci-dessous met à jour uniquement l’instance AMD/ROCm. Elle ne redémarre pas <code>ollama-nvidia.service</code> et ne modifie pas les modèles.

=== Mise à jour du conteneur ROCm ===

<pre>
# Sauvegarder la définition Quadlet avant modification éventuelle
STAMP=$(date +%Y%m%d-%H%M%S)
mkdir -p /home/loic/backups/ollama
cp -p /home/loic/.config/containers/systemd/ollama-rocm.container \
/home/loic/backups/ollama/ollama-rocm.container.before-update-${STAMP}.bak

# Télécharger l’image flottante ROCm puis recréer le conteneur
podman pull docker.io/ollama/ollama:rocm
systemctl --user daemon-reload
systemctl --user restart ollama-rocm.service

# Contrôler le service et la version API
systemctl --user is-active ollama-rocm.service
podman ps --filter name=ollama_roc
curl -fsS http://127.0.0.1:11434/api/version
curl -fsS http://127.0.0.1:11434/api/tags
</pre>

Le 14 août 2026, cette procédure a fait passer l’API ROCm de <code>0.32.0</code> à <code>0.32.9</code>. Le journal confirme la détection ROCm de la Radeon RX 7900 XTX.

=== Mise à jour du client CLI utilisateur ===

Le binaire système <code>/usr/bin/ollama</code> était une installation root en version client <code>0.30.7</code>. Comme l’accès sudo n’était pas disponible, le client officiel a été installé dans <code>/home/loic/.local/bin</code>, qui est prioritaire dans le <code>PATH</code>.

<pre>
# Télécharger l’archive officielle Linux AMD64
TMP=$(mktemp -d)
trap 'rm -rf "$TMP"' EXIT
curl -fsSL https://ollama.com/download/ollama-linux-amd64.tar.zst \
-o "$TMP/ollama.tar.zst"
zstd -d "$TMP/ollama.tar.zst" -o "$TMP/ollama.tar"
tar -xf "$TMP/ollama.tar" -C "$TMP"

# Installer le client pour l’utilisateur courant
mkdir -p /home/loic/.local/bin
install -m 0755 "$TMP/bin/ollama" /home/loic/.local/bin/ollama
hash -r

# Vérifier la résolution et la version
command -v ollama
ollama --version

# Tester le client contre l’instance AMD
OLLAMA_HOST=http://127.0.0.1:11434 ollama list
</pre>

Résultat vérifié : <code>/home/loic/.local/bin/ollama</code>, client version <code>0.32.9</code>, aligné avec l’API ROCm.

Pour remplacer également le binaire système, après validation et avec un compte root :

<pre>
sudo cp -p /usr/bin/ollama /home/loic/backups/ollama/ollama-client.system.before-update-$(date +%Y%m%d-%H%M%S).bin
sudo install -o root -g root -m 0755 /home/loic/.local/bin/ollama /usr/bin/ollama
/usr/bin/ollama --version
</pre>

=== Retour arrière ===

<pre>
# Revenir à l’image actuellement utilisée avant le pull : utiliser son digest
podman image ls --digests docker.io/ollama/ollama

# Restaurer le Quadlet si nécessaire, puis relancer
systemctl --user daemon-reload
systemctl --user restart ollama-rocm.service

# Désactiver le client utilisateur pour revenir au client système
mv /home/loic/.local/bin/ollama /home/loic/.local/bin/ollama.disabled
hash -r
/usr/bin/ollama --version
</pre>

== Maintenance documentaire ==
Lors d'un changement de port, de proxy public, de stockage des modèles, de pilote GPU, de toolkit NVIDIA, d'alias shell ou d'architecture AMD/NVIDIA, mettre à jour cette page et la page centrale [[Trace install tas]].

== Trace documentaire ==
Cette page fait partie de [[Trace install tas]].\n\n== État Quadlet confirmé — 2026-07-25 ==

Les deux instances Ollama sont définies par Quadlet :

* ROCm : <code>ollama-rocm.service</code>, conteneur <code>ollama_roc</code>, port <code>11434</code>, image <code>docker.io/ollama/ollama:rocm</code>, API vérifiée en version <code>0.32.9</code> le 14 août 2026
* NVIDIA : <code>ollama-nvidia.service</code>, conteneur <code>ollama_nv</code>, port <code>11435</code>, image <code>docker.io/ollama/ollama:latest</code>
* Fichiers : <code>/home/loic/.config/containers/systemd/ollama-rocm.container</code> et <code>ollama-nvidia.container</code>
* Modèles partagés : <code>/media/loic/nem/ollama</code>

L’API ROCm répond en version <code>0.32.9</code> après mise à jour du conteneur le 14 août 2026. Le tag <code>:rocm</code> est flottant ; pour figer une version, comparer son digest à un tag versionné tel que <code>:0.32.3-rocm</code> puis modifier le Quadlet.

L'instance NVIDIA reste dépendante de la cohérence entre le pilote noyau, les bibliothèques NVIDIA, le toolkit et le CDI.

Trace install tas

2026-08-13T22:41:24Z

Daneel : Restauration et mise à jour des ports selon Caddy

Trace install tas

2026-08-13T22:40:38Z

Daneel : Mise à jour des ports selon Caddy et état de vérification

Configurationphysique

2026-08-13T22:40:38Z

Daneel : Mise à jour de la carte mère et du type de RAM

= Configuration physique =

Cette page décrit la configuration matérielle relevée sur le serveur '''tas'''. Les valeurs peuvent évoluer après une intervention matérielle ou une mise à niveau ; la date du dernier relevé est indiquée ci-dessous.

== Identification de la machine ==

{| class="wikitable"
! Élément !! Valeur
|-
| Nom d’hôte || <code>tas</code>
|-
| Constructeur || Micro-Star International Co., Ltd.
|-
| Carte mère || MSI MAG B660M MORTAR WIFI DDR4 (MS-7D42)
|-
| Système d’exploitation || Ubuntu 24.04.4 LTS
|-
| Architecture || x86_64
|-
| Noyau || Linux 6.8.0-137-generic
|}

== Processeur et mémoire ==

* '''Processeur :''' Intel Core i7-12700 de 12e génération.
* '''Cœurs / threads :''' 12 cœurs, 20 processeurs logiques.
* '''Fréquence maximale annoncée :''' 4,9 GHz.
* '''Mémoire vive reconnue :''' 96 Gio de RAM de type DDR4.
* '''Mémoire swap :''' 2 Gio.

== Processeurs graphiques ==

{| class="wikitable"
! GPU !! Informations relevées
|-
| AMD || Radeon RX 7900 XT / XTX / 7900M, contrôleur Navi 31
|-
| NVIDIA || GeForce RTX 3070 LHR, 8 Gio de VRAM, pilote 580.173.02
|-
| Vidéo intégrée || Intel Alder Lake-S GT1
|}

La machine dispose donc d’un GPU AMD et d’un GPU NVIDIA utilisables séparément selon les charges. La présence de la RTX 3070 et le fonctionnement du pilote NVIDIA ont été vérifiés avec <code>nvidia-smi</code>.

== Stockage physique et montages ==

{| class="wikitable"
! Périphérique !! Modèle !! Capacité brute !! Point de montage / usage
|-
| <code>/dev/sda</code> || SanDisk SSD PLUS 1000GB || 931,5 Gio || Système (<code>/</code>) et partition EFI
|-
| <code>/dev/sdb</code> || Seagate Exos ST16000NM001G-2KK103 || 14,6 Tio || <code>/media/loic/D0_16To</code>
|-
| <code>/dev/sdc</code> || Seagate Barracuda ST8000DM004-2CX188 || 7,3 Tio || <code>/mnt/sdd1</code>
|-
| <code>/dev/nvme0n1</code> || Samsung SSD 990 PRO with Heatsink 4TB || 3,6 Tio || <code>/media/loic/nem</code>
|}

=== Systèmes de fichiers relevés ===

* <code>/dev/sda3</code> : ext4, monté sur <code>/</code>.
* <code>/dev/sda2</code> : vfat, monté sur <code>/boot/efi</code>.
* <code>/dev/sdb</code> : ext4, monté sur <code>/media/loic/D0_16To</code>.
* <code>/dev/sdc1</code> : ext2, monté sur <code>/mnt/sdd1</code>.
* <code>/dev/nvme0n1</code> : ext4, monté sur <code>/media/loic/nem</code>.

== Relevé ==

* '''Dernier relevé :''' 14 août 2026.
* '''Commandes utilisées :''' <code>hostnamectl</code>, <code>lscpu</code>, <code>free -h</code>, <code>lsblk</code>, <code>lspci</code> et <code>nvidia-smi</code>.
* Les valeurs de capacité affichées par le système sont exprimées en unités binaires (Gio/Tio), tandis que les modèles de disques utilisent souvent des capacités commerciales en Go/To.

[[Catégorie:Administration]]
[[Catégorie:Architecture]]

Accueil

2026-08-13T22:16:38Z

Daneel : Référencement de la configuration physique depuis Accueil

= Bienvenue sur le Wiki documentaire de tas =

Ce wiki centralise la documentation technique, la traçabilité d'installation et les modèles d'architecture du serveur '''tas'''.

== 🏗️ Architecture et Installation ==
Cette section regroupe la cartographie du système et le suivi des déploiements.

* '''[[Trace install tas]]''' : Le point d'entrée principal recensant toutes les briques logicielles installées (Nextcloud, MediaWiki, Open WebUI, Ollama, etc.), leurs rôles et leurs ports.
* '''[[Architecture logicielle de tas]]''' : La cartographie logique décrivant l'exposition des services via Caddy et les interactions entre composants.
* '''[[configurationphysique|Configuration physique]]''' : Les caractéristiques matérielles, les GPU et les volumes de stockage du serveur tas.
* '''[[Installation conteneurisée standard sur tas]]''' : Les règles et bonnes pratiques pour déployer de nouveaux services (Podman, systemd, Caddy).
* '''[[Schéma d'architecture cliquable de tas]]''' : Une vue visuelle et interactive de l'infrastructure.
* '''[[Tests de représentations d'architecture de tas]]''' : Différentes approches visuelles (couches, mindmap, accès publics) pour cartographier le serveur.

== 📊 Modélisation et Diagrammes ==
Le wiki est configuré pour générer dynamiquement différents types de diagrammes (Mermaid, PlantUML, BPMN, D2, Graphviz).

* '''[[Index des modèles de schémas]]''' : Le catalogue complet de tous les exemples de diagrammes disponibles.
* '''[[Déploiement Mermaid PlantUML BPMN JS]]''' : La documentation technique expliquant comment le support de ces diagrammes a été intégré au wiki.

=== Outils de modélisation intégrés ===
* '''Mermaid''' : Pour les diagrammes rapides (flowchart, séquence, Gantt, mindmap...).
* '''D2''' et '''Graphviz''' : Pour les schémas d'architecture physique et logicielle.
* '''PlantUML''' : Pour l'UML et les diagrammes techniques.
* '''BPMN JS''' : Pour les workflows et processus métiers natifs.

== ⚙️ Administration ==
* [https://lololand.hopto.org:25697 Homepage] : Le portail des services.
* Les modifications de configuration d'infrastructure doivent toujours être reportées dans [[Trace install tas]].\n\n== Index d'exploitation de tas ==

* '''[[Index de la documentation de tas]]''' : index thématique des pages, liens HTML et fichiers locaux associés.
* Source locale de l'index : <code>/home/loic/clawd/wiki-mediawiki-index.md</code>
* Source locale de la documentation MediaWiki : <code>/home/loic/mediawiki/docs/</code>

Configurationphysique

2026-08-13T22:16:20Z

Daneel : Création de la page de configuration physique

= Configuration physique =

Cette page décrit la configuration matérielle relevée sur le serveur '''tas'''. Les valeurs peuvent évoluer après une intervention matérielle ou une mise à niveau ; la date du dernier relevé est indiquée ci-dessous.

== Identification de la machine ==

{| class="wikitable"
! Élément !! Valeur
|-
| Nom d’hôte || <code>tas</code>
|-
| Constructeur || Micro-Star International Co., Ltd.
|-
| Modèle de carte mère / système || <code>MS-7D42</code>
|-
| Système d’exploitation || Ubuntu 24.04.4 LTS
|-
| Architecture || x86_64
|-
| Noyau || Linux 6.8.0-137-generic
|}

== Processeur et mémoire ==

* '''Processeur :''' Intel Core i7-12700 de 12e génération.
* '''Cœurs / threads :''' 12 cœurs, 20 processeurs logiques.
* '''Fréquence maximale annoncée :''' 4,9 GHz.
* '''Mémoire vive reconnue :''' 96 Gio.
* '''Mémoire swap :''' 2 Gio.

== Processeurs graphiques ==

{| class="wikitable"
! GPU !! Informations relevées
|-
| AMD || Radeon RX 7900 XT / XTX / 7900M, contrôleur Navi 31
|-
| NVIDIA || GeForce RTX 3070 LHR, 8 Gio de VRAM, pilote 580.173.02
|-
| Vidéo intégrée || Intel Alder Lake-S GT1
|}

La machine dispose donc d’un GPU AMD et d’un GPU NVIDIA utilisables séparément selon les charges. La présence de la RTX 3070 et le fonctionnement du pilote NVIDIA ont été vérifiés avec <code>nvidia-smi</code>.

== Stockage physique et montages ==

{| class="wikitable"
! Périphérique !! Modèle !! Capacité brute !! Point de montage / usage
|-
| <code>/dev/sda</code> || SanDisk SSD PLUS 1000GB || 931,5 Gio || Système (<code>/</code>) et partition EFI
|-
| <code>/dev/sdb</code> || Seagate Exos ST16000NM001G-2KK103 || 14,6 Tio || <code>/media/loic/D0_16To</code>
|-
| <code>/dev/sdc</code> || Seagate Barracuda ST8000DM004-2CX188 || 7,3 Tio || <code>/mnt/sdd1</code>
|-
| <code>/dev/nvme0n1</code> || Samsung SSD 990 PRO with Heatsink 4TB || 3,6 Tio || <code>/media/loic/nem</code>
|}

=== Systèmes de fichiers relevés ===

* <code>/dev/sda3</code> : ext4, monté sur <code>/</code>.
* <code>/dev/sda2</code> : vfat, monté sur <code>/boot/efi</code>.
* <code>/dev/sdb</code> : ext4, monté sur <code>/media/loic/D0_16To</code>.
* <code>/dev/sdc1</code> : ext2, monté sur <code>/mnt/sdd1</code>.
* <code>/dev/nvme0n1</code> : ext4, monté sur <code>/media/loic/nem</code>.

== Relevé ==

* '''Dernier relevé :''' 14 août 2026.
* '''Commandes utilisées :''' <code>hostnamectl</code>, <code>lscpu</code>, <code>free -h</code>, <code>lsblk</code>, <code>lspci</code> et <code>nvidia-smi</code>.
* Les valeurs de capacité affichées par le système sont exprimées en unités binaires (Gio/Tio), tandis que les modèles de disques utilisent souvent des capacités commerciales en Go/To.

[[Catégorie:Administration]]
[[Catégorie:Architecture]]

Trace install tas - Gitea

2026-08-04T14:09:30Z

Daneel : Rendre la gestion du mot de passe PostgreSQL instructive

= Trace install tas - Gitea =

Gitea fournit le service Git local de '''tas'''.

== Accès et exposition ==

* URL canonique : <code>https://gitea.lololand.org/</code>
* Accès externe alternatif : <code>https://lololand.hopto.org:25702/</code>
* Publication locale : <code>127.0.0.1:8105</code> vers le port conteneur <code>3000</code>
* Le serveur SSH interne de Gitea est désactivé ; la surface publiée est HTTP/HTTPS.

== Runtime ==

Le runtime est '''Podman rootless + Quadlet + systemd utilisateur'''.

* Application : <code>/home/loic/.config/containers/systemd/gitea.container</code>
* PostgreSQL : <code>/home/loic/.config/containers/systemd/postgresql-gitea.container</code>
* Réseau : <code>gitea-net</code>, assuré par <code>/home/loic/.config/systemd/user/gitea-network.service</code>
* Données Gitea : volume Podman <code>gitea_data</code> monté sur <code>/data</code>
* Cache Gitea : volume Podman <code>gitea_cache</code> monté sur <code>/cache</code>
* Données PostgreSQL : <code>/media/loic/nem/gitea/postgres</code>
* Reverse proxy : bloc Gitea dans <code>/etc/caddy/Caddyfile</code>

Images actuellement utilisées et tags versionnés :

* <code>docker.io/gitea/gitea:1.27.1</code>
* <code>docker.io/library/postgres:17.10</code>

== Secret PostgreSQL ==

Les Quadlets ne contiennent plus la valeur du mot de passe. Les deux conteneurs utilisent le secret Podman <code>gitea-postgres-password</code> : <code>POSTGRES_PASSWORD</code> pour PostgreSQL et <code>GITEA__database__PASSWD</code> pour Gitea.

La valeur n'est jamais publiée dans cette documentation. Pour vérifier uniquement la présence du secret :

<syntaxhighlight lang="bash">
podman secret inspect gitea-postgres-password
</syntaxhighlight>

Pour créer ou remplacer le secret sans l'écrire dans un Quadlet :

<syntaxhighlight lang="bash">
read -r -s -p 'Mot de passe PostgreSQL Gitea: ' GITEA_DB_PASSWORD
printf '\n'
printf '%s' "$GITEA_DB_PASSWORD" | podman secret create --replace gitea-postgres-password -
unset GITEA_DB_PASSWORD
</syntaxhighlight>

=== Visualiser la valeur actuelle ===

<code>podman secret inspect</code> affiche les métadonnées du secret, mais pas sa valeur. Pour la récupérer localement, on peut l'injecter temporairement dans un conteneur et l'afficher dans le terminal :

<syntaxhighlight lang="bash">
podman run --rm \
--secret gitea-postgres-password,type=env,target=GITEA_DB_PASSWORD \
docker.io/library/postgres:17.10 \
sh -c 'printf "%s\n" "$GITEA_DB_PASSWORD"'
</syntaxhighlight>

Cette commande ne modifie ni PostgreSQL ni Gitea, mais révèle le mot de passe à l'écran. Ne pas l'utiliser dans une session partagée, une capture d'écran ou une commande enregistrée.

=== Modifier le mot de passe ===

Le mot de passe doit être identique dans le rôle PostgreSQL <code>gitea</code> et dans le secret Podman <code>gitea-postgres-password</code>. <code>POSTGRES_PASSWORD</code> ne modifie pas un rôle déjà initialisé : il n'est utilisé qu'à la création initiale du répertoire de données.

La méthode recommandée génère un mot de passe hexadécimal et modifie le rôle SQL avant de remplacer le secret :

<syntaxhighlight lang="bash">
new_password="$(openssl rand -hex 32)"
printf "ALTER ROLE gitea PASSWORD '%s';\n" "$new_password" \
| podman exec -i gitea-db psql -U gitea -d gitea -v ON_ERROR_STOP=1 -f -
printf '%s' "$new_password" | podman secret create --replace gitea-postgres-password -
unset new_password
systemctl --user restart gitea.service
</syntaxhighlight>

Vérifier ensuite :

<syntaxhighlight lang="bash">
podman exec gitea-db pg_isready -U gitea -d gitea
systemctl --user is-active postgresql-gitea.service gitea.service
curl -fsS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8105/
</syntaxhighlight>

Ne pas modifier uniquement le secret Podman ou uniquement le rôle SQL : les deux valeurs doivent rester synchronisées.

== Étapes de configuration ==

# Créer le réseau <code>gitea-net</code> et le maintenir par <code>gitea-network.service</code>.
# Créer le secret Podman <code>gitea-postgres-password</code>.
# Démarrer PostgreSQL avec le volume persistant et le secret injecté dans <code>POSTGRES_PASSWORD</code>.
# Démarrer Gitea avec le même secret injecté dans <code>GITEA__database__PASSWD</code>.
# Configurer Gitea pour PostgreSQL sur <code>gitea-db:5432</code>, avec la base et l'utilisateur <code>gitea</code>.
# Publier le port HTTP local <code>8105</code> via Caddy vers <code>gitea.lololand.org</code> et le port externe <code>25702</code>.
# Vérifier systemd, PostgreSQL, la réponse HTTP locale et la réponse publique.

== Commandes de vérification ==

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user is-active gitea-network.service postgresql-gitea.service gitea.service
podman exec gitea-db pg_isready -U gitea -d gitea
podman exec gitea gitea --version
podman exec gitea-db postgres --version
curl -fsS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8105/
</syntaxhighlight>

== Sauvegarde et retour arrière ==

Le backup de la modification du 4 août 2026 est dans :

<code>/home/loic/backups/gitea-quadlet-hardening-20260804T102558+0200/</code>

Restaurer les Quadlets depuis ce dossier, exécuter <code>systemctl --user daemon-reload</code>, puis redémarrer PostgreSQL et Gitea dans cet ordre. Ne pas supprimer le volume PostgreSQL lors d'un retour arrière.

== Vérifications du 4 août 2026 ==

* Gitea <code>1.27.1</code> actif.
* PostgreSQL <code>17.10</code> actif et <code>pg_isready</code> positif.
* HTTP local : <code>200</code>.
* HTTP public sur <code>https://gitea.lololand.org/</code> : <code>200</code>.
* Aucun mot de passe en clair dans les deux Quadlets Gitea/PostgreSQL.

Trace install tas - Gitea

2026-08-04T08:33:41Z

Daneel : Créer la documentation de configuration Gitea

= Trace install tas - Gitea =

Gitea fournit le service Git local de '''tas'''.

== Accès et exposition ==

* URL canonique : <code>https://gitea.lololand.org/</code>
* Accès externe alternatif : <code>https://lololand.hopto.org:25702/</code>
* Publication locale : <code>127.0.0.1:8105</code> vers le port conteneur <code>3000</code>
* Le serveur SSH interne de Gitea est désactivé ; la surface publiée est HTTP/HTTPS.

== Runtime ==

Le runtime est '''Podman rootless + Quadlet + systemd utilisateur'''.

* Application : <code>/home/loic/.config/containers/systemd/gitea.container</code>
* PostgreSQL : <code>/home/loic/.config/containers/systemd/postgresql-gitea.container</code>
* Réseau : <code>gitea-net</code>, assuré par <code>/home/loic/.config/systemd/user/gitea-network.service</code>
* Données Gitea : volume Podman <code>gitea_data</code> monté sur <code>/data</code>
* Cache Gitea : volume Podman <code>gitea_cache</code> monté sur <code>/cache</code>
* Données PostgreSQL : <code>/media/loic/nem/gitea/postgres</code>
* Reverse proxy : bloc Gitea dans <code>/etc/caddy/Caddyfile</code>

Images actuellement utilisées et tags versionnés :

* <code>docker.io/gitea/gitea:1.27.1</code>
* <code>docker.io/library/postgres:17.10</code>

== Secret PostgreSQL ==

Les Quadlets ne contiennent plus la valeur du mot de passe. Les deux conteneurs utilisent le secret Podman <code>gitea-postgres-password</code> : <code>POSTGRES_PASSWORD</code> pour PostgreSQL et <code>GITEA__database__PASSWD</code> pour Gitea.

La valeur n'est jamais publiée dans cette documentation. Pour vérifier uniquement la présence du secret :

<syntaxhighlight lang="bash">
podman secret inspect gitea-postgres-password
</syntaxhighlight>

Pour créer ou remplacer le secret sans l'écrire dans un Quadlet :

<syntaxhighlight lang="bash">
read -r -s -p 'Mot de passe PostgreSQL Gitea: ' GITEA_DB_PASSWORD
printf '\\n'
printf '%s' "$GITEA_DB_PASSWORD" | podman secret create --replace gitea-postgres-password -
unset GITEA_DB_PASSWORD
</syntaxhighlight>

Le mot de passe du rôle PostgreSQL doit correspondre au secret avant de redémarrer Gitea. Une rotation doit donc être effectuée avec une commande SQL locale contrôlée, puis le secret doit être remplacé et Gitea redémarré.

== Étapes de configuration ==

# Créer le réseau <code>gitea-net</code> et le maintenir par <code>gitea-network.service</code>.
# Créer le secret Podman <code>gitea-postgres-password</code>.
# Démarrer PostgreSQL avec le volume persistant et le secret injecté dans <code>POSTGRES_PASSWORD</code>.
# Démarrer Gitea avec le même secret injecté dans <code>GITEA__database__PASSWD</code>.
# Configurer Gitea pour PostgreSQL sur <code>gitea-db:5432</code>, avec la base et l'utilisateur <code>gitea</code>.
# Publier le port HTTP local <code>8105</code> via Caddy vers <code>gitea.lololand.org</code> et le port externe <code>25702</code>.
# Vérifier systemd, PostgreSQL, la réponse HTTP locale et la réponse publique.

== Commandes de vérification ==

<syntaxhighlight lang="bash">
systemctl --user daemon-reload
systemctl --user is-active gitea-network.service postgresql-gitea.service gitea.service
podman exec gitea-db pg_isready -U gitea -d gitea
podman exec gitea gitea --version
podman exec gitea-db postgres --version
curl -fsS -o /dev/null -w '%{http_code}\\n' http://127.0.0.1:8105/
</syntaxhighlight>

== Sauvegarde et retour arrière ==

Le backup de la modification du 4 août 2026 est dans :

<code>/home/loic/backups/gitea-quadlet-hardening-20260804T102558+0200/</code>

Restaurer les Quadlets depuis ce dossier, exécuter <code>systemctl --user daemon-reload</code>, puis redémarrer PostgreSQL et Gitea dans cet ordre. Ne pas supprimer le volume PostgreSQL lors d'un retour arrière.

== Vérifications du 4 août 2026 ==

* Gitea <code>1.27.1</code> actif.
* PostgreSQL <code>17.10</code> actif et <code>pg_isready</code> positif.
* HTTP local : <code>200</code>.
* HTTP public sur <code>https://gitea.lololand.org/</code> : <code>200</code>.
* Aucun mot de passe en clair dans les deux Quadlets Gitea/PostgreSQL.

Trace install tas

2026-08-04T08:33:40Z

Daneel : Documenter Gitea, tags versionnés et secrets Quadlet

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

2026-05-03T18:40:38Z

Daneel : Ajout de Stalwart dans la trace centrale tas

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

2026-04-11T08:49:28Z

Daneel : Correction du tableau : Hugo et Trilium

Trace install tas

2026-04-11T08:37:48Z

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

Trace install tas

2026-04-11T08:23:29Z

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

Trace install tas

2026-04-11T07:45:57Z

Daneel : Mise à jour de la trace centrale avec Hugo

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 - 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]].