sans.pub/CLAUDE.md

Serveur sans.pub

Lorsque tu interroges le serveur, ne lances que des commandes en LECTURE SEULE (non destructrices). Sauf à la demande explicite de l'utilisateur.

Accès

• SSH: ssh zuck@sans.pub (alias ~/.ssh/config : Host sans.pub) — sudo sans mot de passe. Note : ce document mentionnait auparavant un utilisateur cloud, à vérifier/clarifier (voir install-serveur.md, le compte créé est zuck).
• CapRover: https://captain.cloud.sans.pub
• Gitea: git.sans.pub (port SSH 2242, User git dans ~/.ssh/config)

Infrastructure

• OS: Debian 9 (kernel 4.9.0-12-amd64)
• Docker: 19.03.12 (mode Swarm)
• Disque: 914 Go total, ~193 Go utilisés (23%)
• RAM: 23 Go (~6 Go utilisés, swap quasi vide — vérifié 2026-02-19)

Structure Caprover

• /captain/data/ - données persistantes
• /captain/generated/ - configs générées
• /captain/temp/ - fichiers temporaires

Services actifs (~40 services)

Outils collaboratifs

• etherpad - éditeur collaboratif
• ethercalc - tableur collaboratif
• cryptpad - suite bureautique chiffrée
• nextcloud - cloud personnel

Développement

• gitea - forge Git
• adminer - gestion BDD

Communication

• writefreely - blog
• peertube - vidéos
• rss + rss-bridge - flux RSS

Sécurité/Outils

• bitwarden - gestionnaire mots de passe
• privatebin - partage de texte chiffré
• ots - secrets temporaires
• it-tools - boîte à outils
• cyberchef - manipulation de données

Sites perso

• pierre-martin - site perso
• sans-pub-site - site principal
• une-espace - autre projet

Enquêtes

• limesurvey - sondages

Services en erreur

Aucun service en erreur connu (vérifié 2026-02-19). mail tourne correctement (1/1, poste.io).

Commandes et skills Claude

Commande

• /supervision - analyse complète de la santé du serveur (invocation manuelle)

Skill (auto-activé)

• caprover - gestion des apps via API CapRover
  • list : lister les apps
  • info NOM : détails d'une app
  • env NOM : variables d'environnement
  • scale NOM N : changer le nombre d'instances
  • restart NOM : redémarrer une app

Prérequis : définir CAPROVER_PASSWORD dans .env (voir .envrc)

Gitea — détails techniques

• Containers Docker (Swarm) : srv-captain--gitea.1.* (gitea/gitea:1.25.4) + srv-captain--gitea-db.1.* (mysql:5.7)
• Volume de données : captain--gitea-data → monté sur /data dans le container
  • Dépôts bare : /data/git/repositories/<owner>/<repo>.git
  • Config app : /data/gitea/conf/app.ini (contient des secrets en clair : INTERNAL_TOKEN, LFS_JWT_SECRET, mot de passe MySQL — jamais versionner ce fichier)
  • .gitconfig global (compte système utilisé par Gitea pour exécuter git) : /data/gitea/home/.gitconfig
  • Logs applicatifs : /data/gitea/log/gitea.log (rotation quotidienne en .gz)
• Réseau : container Gitea sur captain-overlay-network, IP interne observée 10.0.1.75. Le reverse-proxy CapRover (captain-nginx) apparaît côté Gitea sous l'IP 10.0.1.105 pour toutes les requêtes publiques (pas d'IP client réelle sans config X-Forwarded-For/trusted proxies).
• Connexion à la base MySQL depuis le host/container : passer par -h 127.0.0.1 (TCP), pas par défaut socket local (localhost) — le grant MySQL de l'utilisateur gitea ne couvre que %/TCP, pas localhost.
• ⚠️ Voir incidents/2026-09-14-gitea-cryptominer.md : l'API interne Gitea (/api/internal/manager/add-logger) a été exploitée pour injecter des packObjectsHook malveillants dans .gitconfig. Toujours vérifier ce fichier ne contient pas d'entrées [uploadpack] packObjectsHook inattendues.

Suivi des tâches

Voir todo.txt (format todo.txt standard)

Mettre à jour une app CapRover

TOUJOURS passer par l'API CapRover — jamais via docker service update directement (CapRover ne le verrait pas).

Procédure

1. Login (obtenir un token) :

import urllib.request, json

data = json.dumps({'password': 'CAPROVER_PASSWORD'}).encode()
req = urllib.request.Request('https://captain.cloud.sans.pub/api/v2/login', data=data, headers={'Content-Type': 'application/json'}, method='POST')
with urllib.request.urlopen(req) as r:
    token = json.loads(r.read().decode())['data']['token']

2. Déployer une nouvelle image :

headers = {'Content-Type': 'application/json', 'x-captain-auth': token, 'x-namespace': 'captain'}
captain_def = json.dumps({'schemaVersion': 2, 'imageName': 'IMAGE:TAG'})
payload = json.dumps({'appName': 'NOM_APP', 'captainDefinitionContent': captain_def, 'gitHash': ''}).encode()
req = urllib.request.Request('https://captain.cloud.sans.pub/api/v2/user/apps/appData/NOM_APP', data=payload, headers=headers, method='POST')
with urllib.request.urlopen(req) as r:
    print(r.read().decode())  # {"status":100,"description":"Deploy is done"}

Note : curl a un problème d'encodage dans cet environnement — utiliser python3 à la place.

Commandes utiles

# Voir les logs d'un service
ssh cloud@sans.pub "docker service logs srv-captain--NOM --tail 100"

# Espace disque des volumes
ssh cloud@sans.pub "docker system df -v"

# Nettoyer les images inutilisées
ssh cloud@sans.pub "docker image prune -a"

Attention

• Debian 9 est obsolète (fin de support LTS)
• RAM : surveiller si ajout de nouveaux services (mail = 1,78 Go, scenari = 862 Mo)