EOLE3 — Administration, maintenance et flux de données

EOLE3 — Administration, maintenance et flux de données

Voir aussi :

• Installation_de_eole3_avec_stockage_ZFS_et_migration_FTP_vers_SFTP
• Mise_en_place_de_Cocckpit_et_du_module_cockpit-zfs

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

Voir aussi :

• Doctrine_des_accès_sur_eole3#3._Comptes_clients_SFTP

7.1 Principe

Chaque client dispose :

• d’un utilisateur Linux dédié ;
• d’un home positionné sur son dataset (ex : /var/data/ad53-data) ;
• d’un shell désactivé (/usr/sbin/nologin) ;
• d’un accès SFTP via le groupe eole3-sftp.

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

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

---

Étape 3 : ajouter au groupe SFTP

usermod -aG eole3-sftp clientX

⚠️ Important :

• ne pas utiliser Match Group pleade ;
• seul le groupe eole3-sftp déclenche le confinement.

---

Étape 4 : permissions

Dans la configuration actuelle :

• le home client correspond directement au dataset ;
• les permissions existantes sont conservées ;
• les droits SFTP reposent sur les permissions Unix.

Aucune modification spécifique du chroot n’est appliquée.

---

7.3 Retirer un compte SFTP

Désactiver :

passwd -l clientX

Supprimer :

userdel clientX

---

7.4 Définir un quota

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 :

1. recréer l’OS ;
2. recréer le pool ZFS ;
3. recréer les datasets ;
4. restaurer les données clientes ;
5. restaurer les comptes SFTP ;
6. restaurer les clés et scripts ;
7. 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`