Repository navigation
Architecture Cluster Zeta
Fichier : Architecture-Cluster-Zeta.md · Dossier : wiki (racine) Branche : master (wiki) · Auteur : hprzeta · MAJ : 2026-08-30 (accès distant : rebond pur bastion §1 — voir Diagnostic-WireGuard-Hotspot §8 ; session réseau 23/08 — IP fixe PC2/PC3, nettoyage PC4, correction adresse IPv6 §11, §15)
Réseau local domestique · 5 machines Ubuntu/Debian/OpenBSD Interconnexion SSH sans mot de passe · PC4 = bastion WireGuard accès externe IPv6 Statut : MONITOR 5/5 ✅ + TMUX CLUSTER ✅ + ACCÈS DISTANT PC1 VALIDÉ ✅ — 23 juin 2026 (PC5 ajouté 20/09/2026)
⚠️ Adresses IP/hostname DDNS retirés de ce document (purge identifiants réseau) — détail complet dans la doc interne (skills privés), non reproduit ici.
Internet (4G / WiFi externe)
│
▼ UDP 51820 IPv6 — DDNS dédié (non divulgué)
┌───────────────────────────────────────┐
│ PC4 — zeta-secure (IP LAN interne) │
│ OpenBSD 7.9 amd64 — Bastion VPN │
│ WireGuard wg0 — concentrateur VPN │
└──────────────┬────────────────────────┘
│ réseau LAN privé
│ + réseau VPN privé
┌───────────┼───────────────┬──────────────────┬──────────────┐
│ │ │ │ │
PC1 PC2 PC3 [box SFR] PC5
zeta-lab zeta-calc- zeta-backup CGNAT IPv4 zeta-monitor
Ubuntu i7 second Debian Ubuntu 14.04 i686 (WAN masqué) Debian 12
Orchestr. Core2Duo backup+log Monitoring
client VPN (log pending) (via bastion)
Téléphone (client VPN) ──WireGuard──▶ PC4 bastion (concentrateur) ──ProxyJump──▶ PC2/PC3/PC5
PC1 distant (client VPN) ──WireGuard──▶ PC4 bastion (concentrateur) ──ProxyJump──▶ PC2/PC3/PC5
MAJ 30/08/2026 — le tunnel ne route que le réseau VPN privé (rebond pur par le bastion, cf. Diagnostic-WireGuard-Hotspot §8) : PC2/PC3 sont atteints par
ProxyJumpSSH via PC4, jamais par une route LAN injectée dans le tunnel.
| Composant | Détail |
|---|---|
| OS | Ubuntu 24.04 LTS |
| CPU | Intel Core i7-7500U · 2C/4T HT · 2.7–3.5 GHz |
| RAM | 8 Go DDR4 + 16 Go swap /mnt/data
|
| GPU | NVIDIA GTX 960M · 4 Go VRAM · CUDA 12.2 |
| IP locale | (interne, non divulguée) ✅ |
| User | riemann |
| Hostname | zeta-lab |
| Alias SSH |
zeta-lab (depuis les autres nodes) |
| Rôle | Calcul principal · orchestration · git · wiki |
| Pipeline | v12 · 8 workers · 8.8 min T=100k ✅ |
| Composant | Détail |
|---|---|
| Modèle | HP Compaq 8000 Elite · carte mère HP 3647h |
| OS | Debian 6.1 (Bookworm) · kernel 6.1.158-1 amd64 |
| CPU | Intel Core2Duo E8400 · 2C/2T · 3.0 GHz · 64 bits |
| RAM | DDR3 1333 MHz · jusqu'à 16 Go (4 slots) |
| DD | SATA 80 Go + IDE 500 Go |
| Réseau | Intel 82567LM-3 · 1 Gbit/s filaire · enp0s25
|
| IP locale | (interne, non divulguée) ✅ |
| Méthode IP | Fixe — NetworkManager manual (connexion zeta-calc-second-LAN2), depuis 23/08/2026 |
| DNS | résolveurs du FAI (harmonisés 23/08/2026) |
| User | hprzeta |
| Hostname | zeta-calc-second |
| Alias SSH | zeta-calc-second |
| Rôle | Calcul secondaire · Gigabit ethernet stable |
| Statut SSH | ✅ Connecté depuis PC1 |
| Composant | Détail |
|---|---|
| Modèle | Compaq Presario SG3210FR · carte mère ECS Livermore8 |
| OS | Ubuntu 14.04 LTS — kernel 4.4.0-210 i686 32-bit |
| CPU | AMD Athlon II X2 215 · 2C · 2.7 GHz · 64 bits |
| RAM | 3 Go DDR2 667 MHz · 2 slots pleins · pas d'upgrade |
| DD | 250 Go Hitachi |
| Réseau | Realtek RTL810xE · 100 Mbit/s · enp1s0
|
| IP locale | (interne, non divulguée) ✅ |
| Méthode IP | Fixe — NetworkManager manual (connexion zeta-backup-LAN3), depuis 23/08/2026 |
| DNS | résolveurs du FAI (harmonisés 23/08/2026) |
| User | hprzeta |
| Hostname | zeta-backup |
| Alias SSH | zeta-backup |
| Rôle | Backup nocturne (rsync+rclone) · monitor cluster |
| Statut SSH | ✅ Connecté depuis PC1 |
| Python |
3.5.2 (Ubuntu 14.04 LTS) — f-strings interdits, .format() obligatoire |
| Monitor | ✅ zeta_monitor.py opérationnel (PYTHONNOUSERSITE=1 dans CMD_LINUX) |
ssh-keygen -t ed25519 -C "hprzeta-zeta-cluster" -f <clé SSH dédiée>
# Clé publique (non secrète, empreinte omise ici) :
# ssh-ed25519 AAAA...(tronquée) hprzeta-zeta-clusterHost zeta-calc-second
HostName <IP interne — non divulguée>
User hprzeta
IdentityFile <clé SSH dédiée>
Host zeta-backup
HostName <IP interne — non divulguée>
User hprzeta
IdentityFile <clé SSH dédiée>
Host zeta-secure
HostName <IP interne — non divulguée>
User hprzeta
IdentityFile <clé SSH dédiée>
| Connexion | Commande | Statut |
|---|---|---|
| PC1 → PC2 | ssh zeta-calc-second |
✅ Opérationnel |
| PC1 → PC3 | ssh zeta-backup |
✅ Opérationnel |
| PC1 → PC4 | ssh zeta-secure |
✅ Opérationnel |
# 1. Installer openssh-server
sudo apt update && sudo apt install -y openssh-server
sudo systemctl enable ssh && sudo systemctl start ssh
# 2. Autoriser la clé publique i7
mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAA...(tronquée) hprzeta-zeta-cluster" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys
# 3. Vérifier l'IP
hostname -IE: dpkg a été interrompu — sudo dpkg --configure -a nécessaire
Could not get lock /var/lib/dpkg/lock-frontend
Cause : MAJ interrompue, processus dpkg bloqué. Solution :
sudo rm /var/lib/dpkg/lock-frontend
sudo rm /var/lib/dpkg/lock
sudo rm /var/cache/apt/archives/lock
sudo dpkg --configure -adebconf: DbDriver "config": /var/cache/debconf/config.dat is locked
Cause : processus debconf zombie après interruption MAJ. Solution :
sudo kill $(lsof /var/cache/debconf/config.dat 2>/dev/null | awk 'NR>1{print $2}')
sudo DEBIAN_FRONTEND=noninteractive dpkg --configure -a/etc/ssh/sshd_config: No such file or directory
Cause : openssh-server installé mais post-install script échoué. Solution :
sudo ssh-keygen -A # Régénère les clés hôte
sudo bash -c 'echo "Port 22
PermitRootLogin no
PubkeyAuthentication yes
AuthorizedKeysFile .ssh/authorized_keys
PasswordAuthentication yes" > /etc/ssh/sshd_config'Privilege separation user sshd does not exist
Cause : utilisateur système sshd absent (non créé par dpkg échoué).
Solution :
sudo useradd -r -s /usr/sbin/nologin -d /run/sshd sshd
sudo mkdir -p /run/sshd
sudo systemctl start ssh✅ SSH actif après cette étape.
# Sur PC2 et sur PC3 (même commande) :
ssh-keygen -t ed25519 -C "zeta-calc-second" -f <clé SSH dédiée> # sur PC2
ssh-keygen -t ed25519 -C "zeta-backup" -f <clé SSH dédiée> # sur PC3
# Enter 2 fois — pas de passphrase# Sur PC1 — autoriser PC2 et PC3 à se connecter :
echo "ssh-ed25519 AAAA...(tronquée) zeta-calc-second" >> ~/.ssh/authorized_keys
echo "ssh-ed25519 AAAA...(tronquée) zeta-backup" >> ~/.ssh/authorized_keys# Sur PC2 ET sur PC3 (même config) :
cat >> ~/.ssh/config << 'EOF'
Host zeta-lab
HostName <IP interne — non divulguée>
User riemann
IdentityFile <clé SSH dédiée>
EOF| De → Vers | Commande | Statut |
|---|---|---|
| PC1 → PC2 | ssh zeta-calc-second |
✅ |
| PC1 → PC3 | ssh zeta-backup |
✅ |
| PC1 → PC4 | ssh zeta-secure |
✅ |
| PC1 → PC5 | ssh zeta-monitor |
✅ |
| PC2 → PC1 | ssh zeta-lab |
✅ |
| PC3 → PC1 | ssh zeta-lab |
✅ |
| PC2 → PC3 | ssh hprzeta@zeta-backup |
(non configuré) |
| PC3 → PC2 | ssh hprzeta@zeta-calc-second |
(non configuré) |
ssh zeta-calc-second # → hprzeta@zeta-calc-second (PC2)
ssh zeta-backup # → hprzeta@zeta-backup (PC3)
ssh zeta-secure # → hprzeta@zeta-secure (PC4 OpenBSD)
exit # Quitter la session SSH# Envoyer code vers PC2
scp ~/projet_zeta/src/calculs/optimisation/compute_zeros_v12.py \
zeta-calc-second:~/projet_zeta/src/
# Récupérer résultats de PC2
scp zeta-calc-second:~/projet_zeta/calculs/zeros_*.csv ~/projet_zeta/calculs/
# Backup calculs vers PC3 (zeta-backup)
rsync -avz ~/projet_zeta/calculs/ zeta-backup:~/backup/calculs/
rsync -avz ~/projet_zeta/logs/ zeta-backup:~/backup/logs/
rsync -avz ~/projet_zeta/pdf/ zeta-backup:~/backup/pdf/# Suivre un run sur PC2
ssh zeta-calc-second "tail -f ~/projet_zeta/logs/run_current.log"
# Charge CPU sur chaque node
ssh zeta-calc-second "uptime && free -h"
ssh zeta-backup "uptime && df -h"
# Lancer un calcul sur PC2 en arrière-plan
ssh zeta-calc-second "cd ~/projet_zeta && source zeta_env/bin/activate && \
nohup python src/calculs/optimisation/compute_zeros_v12.py \
2>&1 | tee logs/run_pc2_\$(date +%Y%m%d_%H%M%S).log &"# Depuis PC1 via SSH :
ssh zeta-calc-second
# Installer Python + libs calcul
sudo apt install -y python3 python3-pip python3-venv \
libmpfr-dev libgmp-dev libflint-dev build-essential rsync
# Créer venv
mkdir -p ~/projet_zeta && cd ~/projet_zeta
python3 -m venv zeta_env
source zeta_env/bin/activate
pip install mpmath numpy
# Copier le code depuis PC1 :
rsync -avz ~/projet_zeta/src/ zeta-calc-second:~/projet_zeta/src/
rsync -avz ~/projet_zeta/scripts/ zeta-calc-second:~/projet_zeta/scripts/
rsync -avz ~/projet_zeta/config/ zeta-calc-second:~/projet_zeta/config/# Services déjà déployés sur zeta-backup (session 15/06) :
# chrony (NTP), rsyslog, dnsmasq (.lan), zeta_monitor.sh
# Installer rclone (si pas encore fait)
curl https://rclone.org/install.sh | sudo bash
# Configurer Proton Drive
rclone config
# Cron backup quotidien à 2h
echo '0 2 * * * rclone copy ~/backup/ protondrive:hprzeta/Riemann_Lab/backup/ --include "*.csv" --include "*.pdf"' | crontab -┌──────────────────────────────────────────────────────┐
│ Pipeline distribué T=1 000 000 │
├──────────────────────────────────────────────────────┤
│ zeta-lab — orchestrateur │
│ ├── Segments [14, 500k] → calcul local (8W) │
│ └── Segments [500k, 1000k] → ssh zeta-calc-second │
│ │
│ zeta-calc-second — worker │
│ ├── 2 workers Illinois/Arb │
│ └── Résultats → rsync → zeta-backup │
│ │
│ zeta-backup — collecteur │
│ ├── Agrège les CSV des 2 nodes │
│ └── rclone → Proton Drive (backup auto) │
│ │
│ Total : 8W (zeta-lab) + 2W (zeta-calc-second) │
│ T=100k : ~7 min · T=1M v12 : ~30h · T=1M OS : ~3h │
└──────────────────────────────────────────────────────┘
| Config | Workers | T=100k | T=1M v12 | T=1M OS |
|---|---|---|---|---|
| zeta-lab seul | 8 HT | 8.8 min ✅ | ~37–47 h | ~2–4 h |
| zeta-lab + zeta-calc-second | 8+2=10 | ~7 min | ~30–35 h | ~2–3 h |
| + zeta-backup stockage | — | — | — | — |
Ajouté le 2026-06-15 — PC4 n'est pas un nœud de calcul mais le gardien du périmètre réseau. Migration matérielle le 2026-08-16 (Dell Dimension 4500 → Compaq CQ58, suite à 2 crashes matériels isolés le même jour) — détail complet : Migration-PC4-Compaq-CQ58-20260816.
| Composant | Détail |
|---|---|
| Modèle | Compaq CQ58 Notebook PC · amd64 |
| OS | OpenBSD 7.9 / amd64 |
| CPU | Intel Celeron B830 @1.80GHz · dual-core · 64 bits |
| RAM | 4 GB |
| Disque | Hitachi 698 Go (sd0) |
| IP locale |
(interne, non divulguée) (re0) ✅ |
| IP VPN |
(non divulguée) (concentrateur WireGuard wg0) |
| User | hprzeta |
| Hostname | zeta-secure |
| Alias SSH | zeta-secure |
| DDNS | dédié, non divulgué ici (AAAA mis à jour toutes les 5 min) |
| Rôle | Bastion VPN · pare-feu pf · point d'entrée externe |
| Statut | ✅ Opérationnel depuis 2026-08-16 (nouveau matériel) |
| IPv6 temporaires | Désactivées (inet6 autoconf -temporary dans /etc/hostname.re0), 23/08/2026 |
| Résolution DNS |
resolvd désactivé, DNS statique (résolveurs du FAI, 23/08/2026) |
Internet (4G)
│
[Téléphone Android]
WireGuard "zeta-vpn"
(client VPN)
Endpoint: DDNS dédié (non divulgué) :51820
│
│ IPv6 (adresse publique bastion, non divulguée)
│
[Box SFR — modèle non divulgué]
Préfixe IPv6 délégué (non divulgué)
Règle "Réseau v6" : UDP 51820 → PC4 activée
│
[PC4 — zeta-secure (IP LAN interne)]
OpenBSD 7.9 · re0 (IPv6 SLAAC global)
WireGuard wg0 — concentrateur VPN
pf : block in / pass WireGuard + ICMPv6
│
┌──────┴──────┐
│ LAN local │ (réseau privé, non divulgué)
┌────────▼────┐ ┌────────────────────┐ ┌────▼───────────┐
│PC1 zeta-lab │ │PC2 zeta-calc-second│ │PC3 zeta-backup │
│(IP interne) │ │(IP interne) │ │(IP interne) │
│client VPN │ │ (futur pair │ │ (futur pair │
└─────────────┘ │ WireGuard) │ │ WireGuard) │
└────────────────────┘ └────────────────┘
| Type | Adresse | Usage |
|---|---|---|
| Locale-lien | (non divulguée) | Interne uniquement |
| Globale SLAAC | (non divulguée) | Endpoint public ✅ (courante, corrigée 23/08/2026) |
| Temporary | Désactivées depuis 23/08/2026 (inet6 autoconf -temporary) |
— |
⚠️ Correction 23/08/2026 — cette section affichait une adresse périmée, obsolète depuis la migration matérielle du 16/08/2026. Toujours vérifier la valeur courante avecdig +short AAAA <DDNS du bastion>avant de s'y fier — voir Diagnostic-WireGuard-Hotspot pour le mode de défaillance associé (règle box qui ne suit pas ce changement automatiquement).L'adresse globale SLAAC se renouvelle périodiquement (
pltime/vltimemesurés à ≈460 s le 23/08/2026 — remplace l'estimation précédente de ~12 min/~2 h, qui n'était pas mesurée).duck.shextrait en temps réel l'adresse non-temporary et met à jour le DDNS toutes les 5 min.
| Pair | IP VPN | Clé publique (tronquée) | allowed-ips | Statut |
|---|---|---|---|---|
| PC4 (serveur) | (non divulguée) | — | — | ✅ concentrateur |
| PC1 zeta-lab | (non divulguée) |
... (i7) |
(réseau VPN privé) | ✅ handshake OK |
| Téléphone Android | (non divulguée) | [CLE_PUB_TEL] |
(réseau VPN privé + LAN) | ✅ testé 2026-06-15 |
allowed-ipsdu téléphone inclut le réseau LAN privé pour accès complet via le tunnel. Test ping LAN depuis téléphone → reporté à la prochaine session.
[Interface]
Address = <IP VPN concentrateur>/24
ListenPort = 51820
PrivateKey = <clé privée PC4>
[Peer]
# PC1 — zeta-lab (i7)
PublicKey = <clé publique PC1>
AllowedIPs = <IP VPN PC1>/32
[Peer]
# Téléphone Android
PublicKey = [CLE_PUB_TEL]
AllowedIPs = <IP VPN téléphone>/32Config PC1 créée le 14/06 mais jamais testée hors LAN : deux erreurs bloquaient l'accès complet au cluster depuis l'extérieur (ex. Paris/Free, hors du LAN SFR de PC4).
Champ wg0.conf (PC1) |
Avant (cassé) | Après (corrigé) |
|---|---|---|
Endpoint |
IP LAN (injoignable hors réseau SFR) | DDNS dédié du bastion |
AllowedIPs |
route uniquement PC4 | réseau VPN privé + LAN (route tout le LAN via le tunnel) |
# Correctifs appliqués sur PC1
sudo cp /etc/wireguard/wg0.conf /etc/wireguard/wg0.conf.bak
sudo sed -i 's|Endpoint = <IP LAN PC4>:51820|Endpoint = <DDNS bastion>:51820|' /etc/wireguard/wg0.conf
sudo sed -i 's|AllowedIPs = <IP VPN PC4>/32|AllowedIPs = <réseau VPN privé>, <réseau LAN privé>|' /etc/wireguard/wg0.conf
sudo wg-quick up wg0
sudo systemctl enable wg-quick@wg0 # persistance au démarrageValidation depuis PC1, hors LAN SFR (Paris/Free, 2026-06-23) :
| Cible | Résultat |
|---|---|
ping <IP VPN PC4> (PC4 tunnel) |
✅ 0 % perte, 13 ms |
ping <IP LAN PC2> (PC2 via PC4) |
✅ 0 % perte, 11 ms |
ping <IP LAN PC3> (PC3 via PC4) |
✅ 0 % perte, 15 ms |
ssh -i <clé SSH dédiée> hprzeta@zeta-calc-second |
✅ connexion OK |
Le routage IPv4 LAN via le tunnel (point resté « reporté » pour le téléphone, voir tableau ci-dessus) fonctionnait déjà côté PC4 (
net.inet.ip.forwardingactif) — aucune modification nécessaire côté PC4 pour ce test. PC1 est donc maintenant un client WireGuard pleinement opérationnel, accessible à distance (4G, autre box) avec accès complet au LAN privé.
# Variables
ext_if = "re0"
# Politique par défaut
block in all
pass out all
# WireGuard — entrant IPv4 et IPv6
pass in on $ext_if proto udp from any to any port 51820
pass in on wg0 all
# ICMPv6 — INDISPENSABLE pour SLAAC (RA, NDP)
pass in on $ext_if inet6 proto icmp6 icmp6-type {routeradv, neighbradv, neighbrsol, redir}
pass out on $ext_if inet6 proto icmp6 all
⚠️ Sans la règleicmp6-type {routeradv,...},inet6 autoconfdans/etc/hostname.re0reste sans effet : les Router Advertisements sont bloqués avant que la pile TCP/IP les traite. Le type correct sous OpenBSD estneighbrsol(pasneighbrsolicit).
inet6 autoconf
#!/bin/sh
# Extraire l'adresse IPv6 globale non-temporary de re0
IP6=$(ifconfig re0 | awk '/inet6/ && !/fe80/ && !/temporary/ {print $2; exit}')
TOKEN="<token_duckdns>"
DOMAIN="<sous-domaine DuckDNS — non divulgué>"
# Pousser A (IPv4 vide si CGNAT) et AAAA
curl -s "https://www.duckdns.org/update?domains=${DOMAIN}&token=${TOKEN}&ip=&ipv6=${IP6}" >> /var/log/duck.log 2>&1Cron : */5 * * * * /etc/duckdns/duck.sh — vérifié avec crontab -l.
| Piège | Symptôme | Solution |
|---|---|---|
| CGNAT IPv4 |
curl ifconfig.me renvoie une IP "publique" mais la box en affiche une RFC1918 |
Comparer avec l'IP WAN dans l'interface box, pas depuis l'intérieur du réseau |
| Pare-feu IPv6 box SFR distinct du NAT | Règle UDP 51820 en NAT/redirection créée, mais trafic IPv6 entrant quand même bloqué | Ouvrir la section "Réseau v6 → Sécurité → Accès" de l'interface box |
| SLAAC OpenBSD bloqué par pf |
inet6 autoconf dans /etc/hostname.re0 mais aucune adresse globale |
Ajouter pass in ... icmp6-type {routeradv,...} dans pf.conf
|
rx=0 persistant WireGuard Android |
Le paquet part (tx croissant) mais n'arrive jamais | Chercher du côté des pare-feu intermédiaires (box), pas du client |
| Adresse SLAAC temporary | DDNS pointe sur une adresse qui change toutes les quelques minutes | Filtrer avec awk '!/temporary/' dans duck.sh
|
| Rebond du bridge LAN (box) | Sauvegarder la section Service DHCP de la box coupe les ports filaires ~3 s | Ne jamais le faire pendant un calcul, un job MPI ou un rsync ; le Wi-Fi (PC1) n'est pas affecté |
nmcli con reload ≠ con up
|
Un profil NetworkManager modifié (ou son fichier) ne s'applique pas tout seul |
sudo nmcli con up <nom> — sur une connexion déjà active, recharge sans couper le lien |
| Traduction automatique du navigateur | Sur l'interface box traduite en FR, chaque zeta saisi devenait zêta (accent invalide en nom d'hôte) |
Basculer l'interface box en EN et désactiver la traduction de page avant toute saisie sur une interface d'administration |
Colonne « Hôte » de LAN → Équipements
|
Affiche « Pas de nom » pour PC2/PC4 en IP fixe | Structurel : alimentée par l'option DHCP 12, qu'une machine en IP fixe n'envoie jamais — pas un réglage manquant |
- Lancer tmux session
zeta:tmux new -s zetaoutmux attach -t zeta - Les alias SSH sont définis dans
~/.ssh/configsur PC1
ssh zeta-calc-second # → hprzeta@zeta-calc-second (PC2 Debian)
ssh zeta-backup # → hprzeta@zeta-backup (PC3 Ubuntu 14.04 i686)
ssh zeta-secure # → hprzeta@zeta-secure (PC4 OpenBSD)
ssh zeta-monitor # → hprzeta@zeta-monitor (PC5 Debian, via bastion)
⚠️ PC4 OpenBSD : si sudo nécessite un TTY interactif, utiliserssh -t zeta-secure doas commande
# 1. Activer WireGuard sur le device mobile/distant
# Endpoint : DDNS dédié du bastion :51820 (IPv6 AAAA, non divulgué ici)
# 2. Depuis le device, accès direct au LAN :
ssh riemann@zeta-lab # PC1 zeta-lab
ssh hprzeta@zeta-calc-second # PC2 zeta-calc-second
ssh hprzeta@zeta-backup # PC3 zeta-backup
ssh hprzeta@zeta-monitor # PC5 zeta-monitor (via ProxyJump PC4)Les scripts SSH changent la couleur de la barre tmux pour identifier visuellement la machine :
- Cyan/vert clair → PC1 zeta-lab (Ubuntu, machine principale)
- Jaune/orange → PC2 zeta-calc-second (Debian)
- Cyan clair → PC3 zeta-backup (Ubuntu 14.04 i686)
- Noir → PC4 zeta-secure (OpenBSD — sobre, bastion)
- Bleu → PC5 zeta-monitor (Debian, monitoring — cyan déjà pris par PC3)
Exemple de wrapper SSH avec changement de couleur :
# Changer couleur barre tmux à la connexion
tmux set-option -g status-bg colour214 # jaune → PC2
ssh hprzeta@zeta-calc-second
tmux set-option -g status-bg colour28 # restaurer vert foncé par défaut# Avant tout run de calcul zéros :
bash ~/projet_zeta/scripts/zeta_turbo_on.sh
# Lancer le run (exemple) :
cd ~/projet_zeta
nohup python src/calculs/optimisation/compute_zeros_v12.py ... &
# Après le run :
bash ~/projet_zeta/scripts/zeta_turbo_off.shAjouté le 2026-06-16 — monitor 4/4 opérationnel, session tmux colorée opérationnelle. MAJ 20/09/2026 — PC5
zeta-monitorajouté au dashboard, monitor 5/5 (voir #18-pc5-zeta-monitor-noeud-monitoring).
Script Python sur PC1 (scripts/zeta_monitor.py) qui interroge les 5 machines en parallèle via SSH (PC5 via ProxyJump sur le bastion, comme PC2/PC3).
| Machine | OS | Méthode CPU | Fix appliqué | Statut |
|---|---|---|---|---|
PC1 zeta-lab
|
Ubuntu 24.04 |
/proc/stat natif |
— | ✅ |
PC2 zeta-calc-second
|
Debian 12 |
/proc/stat natif |
— | ✅ |
PC3 zeta-backup
|
Ubuntu 14.04 (Python 3.5.2) |
/proc/stat via top batch |
PYTHONNOUSERSITE=1 + .format()
|
✅ |
PC4 zeta-secure
|
OpenBSD 7.9 amd64 |
top -b -n 1 (awk NF-1) |
len(p) >= 5, idle=p[-1]
|
✅ |
PC5 zeta-monitor
|
Debian 12 |
/proc/stat natif |
— | ✅ (ajouté 20/09/2026) |
Fixes appliqués dans zeta_monitor.py (session 2026-06-16) :
- PC3 : f-strings remplacés par
.format()(Python 3.5 ne supporte pas f-strings) - PC3 :
PYTHONNOUSERSITE=1préfixé dansCMD_LINUX(contournedistutils-precedence.pth) - PC4 : CPU extrait via
top -b -n 1(pas/proc/stat— absent sous OpenBSD) - PC4 :
len(p) >= 5au lieu de>= 7(OpenBSD top produit moins de colonnes)
# Extrait zeta_monitor.py — commande SSH pour PC3 (Python 3.5)
CMD_LINUX = "PYTHONNOUSERSITE=1 python3 /home/hprzeta/proj/monitor_agent.py"
# Extrait — parsing CPU OpenBSD (top -b -n 1)
# Ligne : "CPU: 2.3% user, ... 96.2% idle"
p = line.split()
if len(p) >= 5 and p[0] == 'CPU:':
idle = float(p[-1].replace('%', ''))
cpu = 100.0 - idle
⚠️ Système distinct des « Couleurs tmux par machine » ci-dessus (celles-là colorent le fond des panneauxzeta_tmux.sh, pas les labels du dashboard curses).
Le dict MACHINES de scripts/zeta_monitor.py fixe, par machine, la couleur du texte
curses utilisée pour le label (PC1 · zeta-lab, etc.) affiché dans le TUI :
| Machine | Couleur curses |
|---|---|
PC1 zeta-lab
|
magenta |
PC2 zeta-calc-second
|
jaune (inchangé) |
PC3 zeta-backup
|
cyan |
PC4 zeta-secure
|
vert (inchangé) |
PC5 zeta-monitor
|
couleur dédiée (ajouté 20/09/2026, voir MACHINES dans le code) |
Script scripts/zeta_tmux.sh — crée (ou reprend) la session tmux zeta-cluster :
# Lancer la session cluster
zeta-cluster # alias ~/.bashrc PC1
# Disposition des panneaux (fenêtre principale) :
# ┌─────────────────────┬─────────────────────┐
# │ PC2 zeta-calc-second│ PC4 zeta-secure │
# │ fond JAUNE (colour3)│ fond NOIR (colour0) │
# ├─────────────────────┼─────────────────────┤
# │ PC3 zeta-backup │ PC1 local + monitor │
# │ fond CYAN (colour6) │ fond MAGENTA (colour5│
# └─────────────────────┴─────────────────────┘
#
# Fenêtre "PC5" dédiée (ajoutée 20/09/2026, distincte de la fenêtre principale) :
# ┌─────────────────────────────────────────────┐
# │ htop en direct sur PC5 (pseudo-terminal) │
# ├─────────────────────────────────────────────┤
# │ shell SSH libre sur PC5 │
# └─────────────────────────────────────────────┘Les couleurs utilisent tmux select-pane -P 'bg=colourX,fg=colourY' — chaque panneau SSH
change de couleur dès l'ouverture de la connexion, permettant d'identifier la machine au premier coup d'œil.
La fenêtre PC5 se connecte au nœud exactement comme les panneaux PC2/PC3 (via le bastion), et
s'ouvre sans prendre le focus pour préserver le comportement de démarrage sur la fenêtre principale.
alias zeta-cluster='bash ~/projet_zeta/scripts/zeta_tmux.sh'Ajouté le 2026-09-20 — PC5 n'est ni un nœud de calcul ni un relais backup : il porte uniquement le dashboard/tmux de monitoring, joignable exactement comme PC2/PC3 (
ProxyJumpvia le bastion PC4).
| Composant | Détail |
|---|---|
| Modèle | Compaq CQ57 Notebook PC |
| OS | Debian 12 |
| IP locale | (interne, non divulguée) ✅ |
| User | hprzeta |
| Hostname | zeta-monitor |
| Alias SSH | zeta-monitor |
| Clé SSH | dédiée (même clé que PC2/PC3/PC4 sur Riemann_Lab_IA) |
| Rôle | Dashboard zeta_monitor.py (5/5) · fenêtre tmux dédiée · alias zeta-webmonitor en préparation |
| Statut | ✅ Opérationnel depuis 2026-09-20 |
⚠️ Divergence pré-existante (hors périmètre PC5) : la brancheRiemann_Lab_Cutilise une clé SSH différente deRiemann_Lab_IApour PC2/PC3/PC4 — PC5 suit la conventionRiemann_Lab_IAsur les deux branches, sans convertir les entrées existantes.
- Plancher-Hardware-Architecture — limites hardware, mur de latence
- Etape-1-Calcul-des-zéros-non-triviaux — pipeline v12
- STACK — roadmap, outils, matériel
- Guide-Linux-Commandes — §12 tmux, §15 Python 3.5 compat
- JOURNAL — entrée 2026-06-16 : monitor 4/4 + zeta_tmux.sh ; 2026-09-20 : PC5 ajouté (monitor 5/5)
Fichier : Architecture-Cluster-Zeta.md · Dossier : wiki (racine) Branche : master (wiki) · Auteur : hprzeta · MAJ : 2026-09-26 (ajout PC5 §18 ; purge des identifiants réseau — IPs, DDNS, IPv6, chemins de clés SSH — dans tout le document, cf. session du 26/09)
Architecture-Cluster-Zeta.md · wiki racine · branche master · hprzeta · MAJ 2026-09-26