90 lines
5.2 KiB
Markdown
90 lines
5.2 KiB
Markdown
# Inventaire du serveur Syllabus
|
||
|
||
> Relevé le 2026-10-07, en lecture seule, depuis `ssh paillasse` (alias créé dans `~/.ssh/config`, clé dédiée `~/.ssh/id_ed25519_claude`).
|
||
|
||
## Identité
|
||
|
||
- Hébergeur : Scaleway Dedibox, offre Start-2-L, datacenter DC2 (France).
|
||
- Nom d'hôte : `sd-124443`.
|
||
- IP publique unique : `163.172.4.195`.
|
||
- Utilisateur d'administration : `adam` (uid 1000), `sudo` sans mot de passe via `/etc/sudoers.d/90-adam` (`adam ALL=(ALL) NOPASSWD:ALL`).
|
||
|
||
## Système et noyau
|
||
|
||
- `PRETTY_NAME="Debian GNU/Linux 12 (bookworm)"`.
|
||
- Noyau : `Linux sd-124443 6.1.0-53-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.187-1 (2026-09-07) x86_64`.
|
||
|
||
## CPU et virtualisation
|
||
|
||
- Intel Xeon D-1531 @ 2.20 GHz, 1 socket, 6 cœurs, 2 threads/cœur → 12 CPU logiques.
|
||
- Flag `vmx` présent (virtualisation matérielle Intel VT-x active).
|
||
- `/dev/kvm` existe (`crw-rw---- root:kvm`), modules `kvm` et `kvm_intel` chargés.
|
||
- → la virtualisation matérielle est disponible, Nova pourra utiliser `nova_compute_virt_type: kvm`.
|
||
|
||
## RAM et swap
|
||
|
||
- RAM totale : 31 Gi (≈ 32 Go), quasiment inutilisée au repos (759 Mi utilisés).
|
||
- Swap : 4,1 Gi, vide.
|
||
|
||
## Disques et RAID
|
||
|
||
- 2 × SSD 232,9 Go (`sda`, `sdb`), partitionnés à l'identique :
|
||
- partition swap de 2 Go sur chaque disque (pas de RAID sur le swap) ;
|
||
- `md0` (RAID1, `sda2`+`sdb2`) → `/boot`, 511 Mo.
|
||
- `md1` (RAID1, `sda3`+`sdb3`) → `/`, 230,2 Go.
|
||
- `cat /proc/mdstat` et `mdadm --detail` : les deux grappes sont `active`, `[UU]` (aucun disque dégradé), état `clean`.
|
||
- `/` (`md1`, ext4) : 226 Go, 1,9 Go utilisés, 213 Go libres.
|
||
- `/boot` (`md0`, ext4) : 469 Mo, 102 Mo utilisés.
|
||
- → RAID 1 logiciel (mdadm) sain sur les deux grappes, conforme à ce qu'annonçait Adam.
|
||
|
||
## Réseau
|
||
|
||
- `eno1` : UP, seule interface active, porte l'unique IP publique `163.172.4.195/24` (+ lien local IPv6).
|
||
- `eno2` : DOWN, inutilisée pour l'instant — c'est elle qui portera la paire veth NAT de l'étape 4.
|
||
- Route par défaut : `163.172.4.1` via `eno1`.
|
||
- DNS : `51.159.69.156` et `51.159.69.162` (résolveurs Scaleway), domaine de recherche `online.net`.
|
||
- Pare-feu actuel : **aucun** (`nft list ruleset` vide). Seul `sshd` écoute sur une interface publique (port 22, IPv4 et IPv6). Un résolveur `named` (bind9) écoute uniquement sur `127.0.0.1`/`::1` (non exposé).
|
||
|
||
## SSH (état avant durcissement — étape 2 à venir)
|
||
|
||
- `sshd -T` effectif : `permitrootlogin without-password`, `passwordauthentication yes`, `pubkeyauthentication yes`, `kbdinteractiveauthentication no`.
|
||
- **`/root/.ssh/authorized_keys` contient déjà 2 clés** : comme `PermitRootLogin` autorise la connexion par clé pour root, une intrusion sur une des clés présentes permettrait aujourd'hui une connexion root directe. À traiter en priorité à l'étape 2 (`PermitRootLogin no`).
|
||
- Mot de passe toujours accepté (`passwordauthentication yes`) : à désactiver à l'étape 2.
|
||
|
||
## Paquets de durcissement (absents, à installer à l'étape 2)
|
||
|
||
- `fail2ban` : absent.
|
||
- `chrony` : absent (l'horloge est néanmoins synchronisée, probablement par `systemd-timesyncd` ; `timedatectl` indique `System clock synchronized: yes`, fuseau déjà `Europe/Paris`).
|
||
- `unattended-upgrades` : absent.
|
||
- `nftables` : déjà installé (paquet présent), mais sans règles actives.
|
||
|
||
## Outillage côté Mac
|
||
|
||
- `python3` : absent du Mac dans le PATH par défaut testé (à vérifier/installer avec Ansible à l'étape 2 — le Mac a normalement Python 3 via Homebrew, `ansible`/`ansible-playbook` ne sont pas encore installés).
|
||
- Côté serveur : `python3` 3.11.2 présent (nécessaire pour Ansible).
|
||
|
||
## Choix de version : Kolla-Ansible
|
||
|
||
**Choix : Kolla-Ansible série `2025.2` (nom de code *Flamingo*).**
|
||
|
||
Justification (vérifié dans la documentation officielle OpenStack, pas de mémoire) :
|
||
|
||
- Le support matrix de `2025.2` liste explicitement *Debian Bookworm (12)* comme OS hôte supporté : https://docs.openstack.org/kolla-ansible/2025.2/user/support-matrix.html
|
||
- La série suivante, `2026.1` (*Gazpacho*), a **abandonné Debian 12** au profit de Debian 13 (Trixie) uniquement — confirmé sur son support matrix. Notre serveur est en Debian 12 (choix d'Adam, fait), donc `2026.1` et `2026.2` sont exclus pour l'instant.
|
||
- La série précédente, `2025.1` (*Epoxy*), supporte aussi Bookworm, mais passe en statut « non maintenue » autour du 2 octobre 2026 (https://releases.openstack.org/) — donc déjà en fin de vie au moment de ce choix.
|
||
- `2025.2` est en statut **« maintenue »** jusqu'à une fin de vie estimée au 28 avril 2027 : c'est la série la plus récente qui coche à la fois « supporte Bookworm » et « encore maintenue avec une marge confortable ».
|
||
|
||
Installation prévue (étape 5), dans un venv Python sur le serveur :
|
||
|
||
```bash
|
||
pip install git+https://opendev.org/openstack/kolla-ansible@stable/2025.2
|
||
kolla-ansible install-deps
|
||
```
|
||
|
||
puis la séquence `bootstrap-servers` → `prechecks` → `deploy` → `post-deploy`.
|
||
|
||
## Critère de l'étape 1 — vérifié
|
||
|
||
- [x] Inventaire écrit (ce fichier).
|
||
- [x] KVM disponible (`/dev/kvm` + modules chargés, flag `vmx`).
|
||
- [x] Version de Kolla-Ansible choisie (`2025.2`) et justifiée par la documentation officielle (support matrix + statut de maintenance).
|