# hermes_user

Crée le user `hermes` (uid/gid 1002) sur **les deux hôtes** avec SSH partagé : la clé générée sur storage-01 est autorisée sur gpu-01, ce qui permet à l'agent de lancer des commandes read-only sur le nœud GPU.

## Ce que fait le rôle

- User/groupe `hermes` (1002:1002, home `/opt/hermes`)
- Sudo **limité** (listes blanches différentes storage-01 / gpu-01)
- Génération clé ed25519 sur storage-01 → poussée dans `authorized_keys` de gpu-01
- `~/.ssh/config` + known_hosts pré-remplis (gpu-01)
- Copie du kubeconfig dans `~hermes/.kube/` si présent (accès kubectl read-only)
- Ajout au groupe `systemd-journal`

## Variables principales

| Variable | Défaut |
|---|---|
| `hermes_user` / `hermes_group` | `hermes` |
| `hermes_uid` / `hermes_gid` | 1002 |
| `hermes_home` | `/opt/hermes` |
| `hermes_ssh_key_type` | ed25519 |

## Ordre d'exécution

Doit passer **avant** `hermes_agent` (qui suppose le user existant). C'est le premier rôle des deux playbooks.

## Caveat

Le rôle touche les deux machines mais avec des branches conditionnelles (`inventory_hostname`) — un run sur storage-01 seul ne pousse pas la clé sur gpu-01 : lancer les **deux** playbooks après régénération de clé.