EOLE3 — Administration, maintenance et flux de données

1. Objet du document

Ce document décrit le rôle du serveur eole3 dans l’infrastructure AJLSM, son architecture de stockage, son usage pour les comptes SFTP, ses échanges avec les autres serveurs, ainsi que les principes de restauration en cas d’incident.

Il est destiné à un administrateur système reprenant l’exploitation du serveur.

---

2. Rôle de eole3 dans l’architecture

EOLE3 est le serveur principal de stockage.

Ses rôles sont les suivants :

héberger les données clients ;
exposer les données via SFTP ;
recevoir des copies offsite en provenance de beotos3 ;
servir de cible de migration depuis eole2 ;
constituer à terme le point central de stockage actif.

---

3. Serveurs liés à eole3

3.1 eole3

IP publique : 51.178.110.230
OS : Ubuntu 24.04 LTS
rôle : stockage principal ZFS, comptes SFTP, réception des copies

3.2 beotos3

IP publique : 51.210.192.214
rôle : serveur intermédiaire de synchronisation et de quarantaine
fonction :
- reçoit actuellement les synchronisations de données ;
- héberge la quarantaine rsync ;
- pousse certaines données offsite vers eole3.

3.3 pbs4

IP publique : 51.178.245.43
rôle : Proxmox Backup Server
fonction :
- contient les sauvegardes PBS des VM ;
- certaines sauvegardes sont recopiées via beotos3 vers eole3.

3.4 saturne3

IP publique : 141.95.206.118
rôle : hyperviseur Proxmox
fonction :
- héberge les VM métiers et techniques ;
- s’appuie sur PBS4 pour les sauvegardes.

3.5 eole2

ancien serveur de stockage
fonction actuelle :
- source de migration vers eole3 ;
- doit continuer à synchroniser vers eole3 jusqu’à la bascule complète.

---

4. Flux de données principaux

4.1 Migration historique

Flux de migration initial :

 eole2 → eole3

Cette migration a été lancée depuis eole3 via le script :

 /root/rsync_from_eole2_private.sh

4.2 Synchronisation miroir existante

Flux actuellement industrialisé côté beotos3 :

 eole2 → beotos3

avec :

quarantaine ;
logs ;
rapports HTML ;
rotation d’archives.

Ce flux devra être transposé vers :

 eole3 → beotos3

une fois eole3 devenu source principale.

4.3 Sauvegardes PBS / VM

Flux actuel :

 pbs4 → beotos3 → eole3

Les données copiées concernent notamment :

`import-saturne`
`import-saturne3`
dump `vzdump` de la VM PBS4 (VM 100)

---

5. Accès au serveur

5.1 Utilisateur recommandé

L’exploitation courante doit se faire avec l’utilisateur :

 ubuntu

Le compte `root` est réservé :

aux opérations système ;
aux opérations ZFS ;
aux opérations d’administration nécessitant des privilèges élevés.

5.2 Connexion SSH

Connexion standard :

ssh ubuntu@51.178.110.230

Connexion root :

possible actuellement ;
à limiter à l’administration système.

5.3 Configuration SSH actuelle

Le fichier `/etc/ssh/sshd_config` montre notamment :

`PermitRootLogin yes`
`PasswordAuthentication yes`
`Subsystem sftp internal-sftp`

Configuration spéciale pour les comptes SFTP :

Match Group pleade
    ChrootDirectory %h
    ForceCommand internal-sftp
    AllowTcpForwarding no
    PermitTunnel no
    X11Forwarding no
    PasswordAuthentication yes

Conséquences :

les utilisateurs du groupe `pleade` sont enfermés dans leur répertoire personnel ;
ils n’ont qu’un accès SFTP ;
ils n’ont pas de shell interactif.

---

6. Architecture de stockage

6.1 ZFS

Le stockage de données est basé sur ZFS.

Pool principal :

 data

État actuel :

pool en ligne ;
topologie : RAIDZ2 ;
6 disques ;
aucune erreur connue.

Résumé :

pool: data
state: ONLINE
config:
  raidz2-0
    sda
    sdb
    sdc
    sdd
    sde
    sdf

Le RAIDZ2 permet la perte simultanée de deux disques sans perte de données.

6.2 Pourquoi ZFS

ZFS a été retenu pour :

la robustesse ;
la vérification d’intégrité ;
la souplesse des datasets ;
la possibilité de quotas par dataset ;
l’administration fine des montages ;
la compression ;
les snapshots si besoin.

6.3 Datasets actuels

Dataset racine :

 data → /var/data

Dossier logique des clients :

 data/clients

Un dataset par client :

 data/clients/ad53-data → /var/data/ad53-data
 data/clients/ad64-data → /var/data/ad64-data
 etc.

Dataset offsite :

 data/offsite-backups-beotos3 → /srv/offsite-backups/beotos3

6.4 Important : séparation des usages

Deux zones doivent rester distinctes :

/var/data

 → données clients, stockage métier

/srv/offsite-backups/beotos3

 → copies techniques/offsite en provenance de beotos3

Cette séparation évite :

les boucles de synchronisation ;
la confusion entre données de production et données de secours ;
le remplissage de `/home` ou de `/`.

---

7. Comptes SFTP

7.1 Principe

Chaque client dispose :

d’un utilisateur Linux dédié ;
d’un home positionné sur son dataset ;
d’un shell désactivé (`/usr/sbin/nologin`) ;
d’un accès SFTP restreint via le groupe `pleade`.

Exemples :

ad53:x:1000:1000::/var/data/ad53-data:/usr/sbin/nologin
ad64:x:1004:1000::/var/data/ad64-data:/usr/sbin/nologin

7.2 Ajouter un nouveau client SFTP

Étape 1 : créer le dataset ZFS

zfs create data/clients/clientX-data
zfs set mountpoint=/var/data/clientX-data data/clients/clientX-data

Étape 2 : créer l’utilisateur

Le groupe de confinement est `pleade`.

Exemple :

useradd -g pleade -d /var/data/clientX-data -s /usr/sbin/nologin clientX
passwd clientX

Étape 3 : permissions du chroot

Le chroot SSH impose que le répertoire racine appartienne à root.

Exemple recommandé :

chown root:root /var/data/clientX-data
chmod 755 /var/data/clientX-data
mkdir -p /var/data/clientX-data/data
chown clientX:pleade /var/data/clientX-data/data

Remarque :

dans l’état actuel observé, les homes clients pointent directement sur `/var/data/<client>-data` ;
il faut donc vérifier la cohérence réelle des permissions avant d’ajouter de nouveaux comptes ;
la stratégie la plus propre est d’utiliser un sous-répertoire de dépôt (`data/`) à l’intérieur du chroot.

7.3 Retirer un compte SFTP

Pour désactiver un compte :

passwd -l clientX

Pour supprimer un compte :

userdel clientX

Attention :

ne pas supprimer le dataset ZFS sans validation ;
la suppression du compte Linux n’efface pas automatiquement les données.

7.4 Définir un quota

Exemple :

zfs set quota=500G data/clients/clientX-data

Vérification :

zfs get quota data/clients/clientX-data

---

8. Cockpit

8.1 Raison de l’installation

Cockpit a été installé pour fournir une administration Web légère du serveur :

état système ;
services ;
stockage ;
ZFS (avec le plugin installé dans `/opt/cockpit-zfs`) ;
accès simple pour maintenance.

URL observée :

 https://51.178.110.230:9090/

8.2 Point restant à finaliser

Le paramétrage des notifications n’est pas terminé.

À documenter / finaliser :

alertes d’espace disque ;
alertes ZFS ;
alertes services ;
adresses de réception des emails.

---

9. Scripts et répertoires rsync

9.1 beotos3 : socle industrialisé

Répertoire principal :

 /opt/rsync_mirror/

Contient notamment :

`rsync_mirror_clients.sh`
`config.sh`
`targets.csv`
`purge_quarantine.sh`
`archive-logs-rsync-mirror.sh`
rsync-pbs-copy.sh
rsync-beotos3-offsite-eole3.sh

9.2 eole3 : cas particulier

Le script de migration depuis eole2 n’a pas été rangé dans `/opt/rsync_*`.

Emplacement constaté :

 /root/rsync_from_eole2_private.sh

Ce choix n’est pas cohérent avec le reste de l’industrialisation.

Explication probable :

script ponctuel ;
écrit rapidement pour la migration ;
non réintégré ensuite dans une arborescence standard.

Conséquence :

faible découvrabilité ;
risque d’oubli ;
documentation indispensable.

9.3 Logs associés à la migration eole2 → eole3

Répertoire :

 /opt/rsync_eole2_to_eole3/

Contenu :

`logs/`
`tmp/`

Le lock observé :

 /opt/rsync_eole2_to_eole3/tmp/rsync_eole2_to_eole3.lock

---

10. Particularité du script eole2 → eole3

Le log observé montre que le script lançait des synchronisations de type :

Source      : root@192.168.123.101:/var/data/test-ajlsm-data/
Destination : /var/data/test-ajlsm-data/data/

Cela révèle un problème de conception :

le script attendait une destination en sous-répertoire `data/` ;
or le modèle ZFS actuel monte les datasets directement sur `/var/data/<client>-data`.

Conclusion :

l’ancien script n’est pas aligné avec la structure finale de eole3 ;
la bonne destination doit être :

 `/var/data/<client>-data/`
 et non
 `/var/data/<client>-data/data/`

---

11. Sauvegardes et scénarios de reprise

11.1 Cas : crash de beotos3

Conséquences :

perte de la quarantaine rsync ;
interruption des synchronisations intermédiaires ;
interruption des copies offsite pilotées depuis beotos3.

Restauration :

eole3 conserve les données finales ;
les copies PBS déjà transférées sur eole3 restent disponibles dans :

 `/srv/offsite-backups/beotos3`

il faut reconstruire beotos3 puis rétablir :
- `/opt/rsync_mirror/`
- `config.sh`
- `targets.csv`
- cron
- clés SSH

11.2 Cas : crash de pbs4

Conséquences :

perte du serveur PBS lui-même ;
interruption des sauvegardes PBS courantes.

Restauration :

reconstituer PBS4 ;
récupérer les données recopiées via beotos3 vers eole3 dans :

 `/srv/offsite-backups/beotos3`

réinjecter les dumps / datastores nécessaires selon le périmètre du sinistre.

11.3 Cas : crash de eole3

Conséquences :

perte du stockage principal ;
perte des comptes SFTP ;
perte de la cible finale des migrations.

Situation actuelle :

il n’existe pas encore de synchronisation de secours formalisée de eole3 vers beotos3 ;
ce point constitue le principal risque actuel.

Action prioritaire à mettre en place :

industrialiser un flux :

 `eole3 → beotos3`

avec :
- exclusions adaptées ;
- quarantaine ;
- logs ;
- rétention ;
- supervision.

11.4 Cas : restauration de eole3 depuis beotos3

Pré-requis :

jeux de données présents sur beotos3 ;
scripts de synchronisation disponibles ;
structure ZFS de destination prête.

Ordre logique :

recréer l’OS ;
recréer le pool ZFS ;
recréer les datasets ;
restaurer les données clientes ;
restaurer les comptes SFTP ;
restaurer les clés et scripts ;
revalider SSH / SFTP / quotas.

---

12. Ce qui doit encore être mis en place

12.1 Synchronisation transitoire

Mettre en place un rsync quotidien :

 eole2 → eole3

jusqu’à la bascule définitive.

12.2 Protection de eole3

Mettre en place un rsync documenté :

 eole3 → beotos3

avec logique comparable à celle déjà utilisée pour eole2 → beotos3.

12.3 Nettoyage / industrialisation

À faire :

déplacer `rsync_from_eole2_private.sh` vers un emplacement standard ;
versionner / documenter le script ;
supprimer les ambiguïtés de structure (`/data/` en destination).

---

13. Bonnes pratiques d’exploitation

travailler en priorité avec l’utilisateur `ubuntu` ;
n’utiliser `root` que pour l’administration système ;
créer tous les nouveaux espaces clients en datasets ZFS ;
documenter tout nouveau script hors `/opt/rsync_*` ;
ne jamais stocker d’offsite volumineux dans `/home` ;
utiliser `/srv/offsite-backups/beotos3` pour les copies techniques ;
vérifier régulièrement :
- `zpool status`
- `zfs list`
- l’état de `/`
- l’espace disponible sur les datasets critiques.

---

14. Références internes à conserver

script migration eole2 → eole3 :

 `/root/rsync_from_eole2_private.sh`

logs migration eole2 → eole3 :

 `/opt/rsync_eole2_to_eole3/logs/`

infrastructure rsync centralisée sur beotos3 :

 `/opt/rsync_mirror/`

stockage offsite sur eole3 :

 `/srv/offsite-backups/beotos3`

EOLE3 — Administration, maintenance et flux de données

EOLE3 — Administration, maintenance et flux de données

1. Objet du document

2. Rôle de eole3 dans l’architecture

3. Serveurs liés à eole3

3.1 eole3

3.2 beotos3

3.3 pbs4

3.4 saturne3

3.5 eole2

4. Flux de données principaux

4.1 Migration historique

4.2 Synchronisation miroir existante

4.3 Sauvegardes PBS / VM

5. Accès au serveur

5.1 Utilisateur recommandé

5.2 Connexion SSH

5.3 Configuration SSH actuelle

6. Architecture de stockage

6.1 ZFS

6.2 Pourquoi ZFS

6.3 Datasets actuels

6.4 Important : séparation des usages

7. Comptes SFTP

7.1 Principe

7.2 Ajouter un nouveau client SFTP

Étape 1 : créer le dataset ZFS

Étape 2 : créer l’utilisateur

Étape 3 : permissions du chroot

7.3 Retirer un compte SFTP

7.4 Définir un quota

8. Cockpit

8.1 Raison de l’installation

8.2 Point restant à finaliser

9. Scripts et répertoires rsync

9.1 beotos3 : socle industrialisé

9.2 eole3 : cas particulier

9.3 Logs associés à la migration eole2 → eole3

10. Particularité du script eole2 → eole3

11. Sauvegardes et scénarios de reprise

11.1 Cas : crash de beotos3

11.2 Cas : crash de pbs4

11.3 Cas : crash de eole3

11.4 Cas : restauration de eole3 depuis beotos3

12. Ce qui doit encore être mis en place

12.1 Synchronisation transitoire

12.2 Protection de eole3

12.3 Nettoyage / industrialisation

13. Bonnes pratiques d’exploitation

14. Références internes à conserver

Menu de navigation

Rechercher