Installation de eole3 avec stockage ZFS et migration FTP vers SFTP

Objectif

Voir aussi :

Le serveur eole3 est le nouveau serveur de DATA destiné à remplacer eole2.

Objectifs de l’installation :

installer Ubuntu 24.04 sur les 2 NVMe en miroir ;
conserver les 6 disques de 22 To pour le stockage DATA ;
mettre en place un pool ZFS RAIDZ2 ;
préparer une structure par client avec un dataset ZFS par répertoire de données ;
migrer les comptes FTP existants en comptes SFTP chrootés ;
conserver les chemins historiques sous /var/data/... ;
préparer la migration des données par rsync depuis eole2 ;
permettre ensuite des snapshots, quotas et restaurations fines par client.

Contexte matériel

Le serveur eole3 dispose de :

2 × NVMe ~960 Go pour le système ;
6 × HDD ~22 To pour les données.

Le serveur a été installé avec Ubuntu 24.04 et les disques DATA ont été laissés vierges pour permettre la création manuelle du pool ZFS.

Choix d’architecture

Système

Le système d’exploitation est installé sur les 2 NVMe, en miroir RAID1 logiciel, avec :

/boot sur RAID1 ;
/ sur RAID1 ;
swap local.

Données

Le stockage DATA est mis en place avec :

un pool ZFS nommé data ;
un vdev unique en raidz2 sur les 6 disques de 22 To ;
un dataset racine monté sur /var/data ;
un dataset enfant par client monté directement sur /var/data/<nom>-data.

Cette approche permet :

l’isolation logique par client ;
la mise en place de snapshots par dataset ;
l’ajout éventuel de quotas par client ;
la compatibilité avec les chemins historiques ;
une migration simple via rsync.

Installation initiale depuis OVH

Choix de l’OS

Dans le manager OVH :

choisir Ubuntu Server 24.04 LTS ;
choisir uniquement le groupe de disques NVMe pour l’installation système ;
ne pas utiliser les 6 disques de 22 To pour l’installation ;
laisser ces 6 disques vierges pour ZFS.

Résultat attendu après installation

Connexion SSH fournie par OVH :

IP : 51.178.110.230
utilisateur initial : ubuntu

Vérification de la présence des disques :

lsblk -o NAME,SIZE,TYPE,MOUNTPOINT

Résultat observé :

NAME          SIZE TYPE  MOUNTPOINT
sda          21.8T disk
sdb          21.8T disk
sdc          21.8T disk
sdd          21.8T disk
sde          21.8T disk
sdf          21.8T disk
nvme0n1     894.3G disk
├─nvme0n1p1   511M part
├─nvme0n1p2     1G part
│ └─md2      1022M raid1 /boot
├─nvme0n1p3 892.3G part
│ └─md3     892.1G raid1 /
└─nvme0n1p4   512M part  [SWAP]
nvme1n1     894.3G disk
├─nvme1n1p1   511M part  /boot/efi
├─nvme1n1p2     1G part
│ └─md2      1022M raid1 /boot
├─nvme1n1p3 892.3G part
│ └─md3     892.1G raid1 /
├─nvme1n1p4   512M part  [SWAP]
└─nvme1n1p5     2M part

Conclusion :

les NVMe sont utilisés pour le système ;
les 6 disques de 22 To sont libres ;
le serveur est prêt pour ZFS.

Installation et création du pool ZFS

Installation du paquet ZFS

sudo apt update
sudo apt install -y zfsutils-linux

Dans le cas présent, le paquet était déjà installé :

zfsutils-linux is already the newest version (2.2.2-0ubuntu9.4).

Nettoyage des signatures éventuelles sur les disques DATA

sudo wipefs -a /dev/sd[a-f]

Création du pool ZFS

Commande utilisée :

sudo zpool create -o ashift=12 \
  -O compression=lz4 \
  -O atime=off \
  -O xattr=sa \
  -O acltype=posixacl \
  data raidz2 \
  /dev/sda /dev/sdb /dev/sdc /dev/sdd /dev/sde /dev/sdf

Vérification du pool

zpool status
zpool list
df -h

Résultat observé :

pool: data
state: ONLINE
config:

    NAME        STATE     READ WRITE CKSUM
    data        ONLINE       0     0     0
      raidz2-0  ONLINE       0     0     0
        sda     ONLINE       0     0     0
        sdb     ONLINE       0     0     0
        sdc     ONLINE       0     0     0
        sdd     ONLINE       0     0     0
        sde     ONLINE       0     0     0
        sdf     ONLINE       0     0     0

errors: No known data errors

NAME   SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP    HEALTH  ALTROOT
data   131T  1.62M   131T        -         -     0%     0%  1.00x    ONLINE  -

Et dans df -h :

data             88T  256K   88T   1% /data

Ensuite, le point de montage a été utilisé sous /var/data dans la suite de la configuration.

Préparation des comptes SFTP

Principe

Les anciens comptes FTP de eole2 ont été exportés, puis recréés sur eole3 en comptes SFTP.

Objectif :

conserver les mêmes utilisateurs ;
conserver les mêmes UID/GID si possible ;
réutiliser les mêmes mots de passe hashés ;
utiliser des homes sous /var/data/<client>-data ;
interdire le shell ;
autoriser uniquement le SFTP ;
chrooter l’utilisateur dans son home.

Fichier d’export

Un fichier d’export TSV a été utilisé sur eole3 :

/root/ftp_users_export.tsv

Ce fichier contient des colonnes du type :

username    uid    gid    groupname    home    shell    shadow_hash

Script d’import initial des comptes SFTP

Script initial

Le script initial recréait les utilisateurs et la structure de base :

#!/usr/bin/env bash
set -euo pipefail

IMPORT_FILE="${1:-/root/ftp_users_export.tsv}"

if [[ ! -f "$IMPORT_FILE" ]]; then
  echo "Fichier introuvable : $IMPORT_FILE"
  exit 1
fi

echo "=== Import des utilisateurs SFTP ==="

while IFS=$'\t' read -r username uid gid groupname home shell shadow_hash; do

    # skip header
    [[ "$username" == "username" ]] && continue

    echo "→ Traitement $username ($home)"

    # créer groupe si nécessaire
    if ! getent group "$groupname" >/dev/null; then
        echo "   - création groupe $groupname"
        groupadd "$groupname"
    fi

    # vérifier si user existe déjà
    if id "$username" &>/dev/null; then
        echo "   - utilisateur déjà existant, skip"
        continue
    fi

    # créer utilisateur SANS créer le home automatiquement
    useradd \
        -u "$uid" \
        -g "$groupname" \
        -d "$home" \
        -s /usr/sbin/nologin \
        -M \
        "$username"

    # appliquer mot de passe
    usermod -p "$shadow_hash" "$username"

    # créer structure
    mkdir -p "$home"
    mkdir -p "$home/data"

    # droits chroot
    chown root:root "$home"
    chmod 755 "$home"

    # droits data (zone écriture)
    chown "$username:$groupname" "$home/data"
    chmod 755 "$home/data"

done < "$IMPORT_FILE"

echo "=== Import terminé ==="

Limite du script initial

Après création des datasets ZFS par client, ce script ne suffisait plus, car il faisait continue si l’utilisateur existait déjà. Il ne recréait donc pas la structure du home dans les nouveaux datasets montés.

Création des datasets ZFS par client

Situation avant structuration fine

Au départ, il n’existait qu’un seul dataset :

zfs list -r data

NAME   USED  AVAIL  REFER  MOUNTPOINT
data  1.40M  87.1T   384K  /var/data

Tous les répertoires clients présents sous /var/data/ étaient donc de simples répertoires classiques, pas encore des datasets ZFS dédiés.

Création d’un parent logique

Commande utilisée :

zfs create -o canmount=off -o mountpoint=none data/clients

Vérification :

zfs list -r data

Résultat :

NAME           USED  AVAIL  REFER  MOUNTPOINT
data          1.78M  87.1T   384K  /var/data
data/clients   192K  87.1T   192K  none

Création automatique d’un dataset par home client

Commande utilisée :

cut -f5 /root/ftp_users_export.tsv | tail -n +2 | while read -r home; do
    suffix="${home#/var/data/}"
    dataset="data/clients/${suffix}"
    echo "Creating $dataset -> $home"
    zfs create -o mountpoint="$home" "$dataset"
done

Cette boucle :

lit la colonne home du fichier TSV ;
retire le préfixe /var/data/ ;
crée un dataset enfant sous data/clients/... ;
monte ce dataset directement sur le chemin historique du home.

Exemple :

/var/data/ad53-data devient le dataset data/clients/ad53-data ;
/var/data/module-pleade-data devient le dataset data/clients/module-pleade-data.

Vérification après création

zfs list -r data

Résultat observé :

NAME                               USED  AVAIL  REFER  MOUNTPOINT
data                              8.62M  87.1T   384K  /var/data
data/clients                      4.31M  87.1T   192K  none
data/clients/ad44-data             192K  87.1T   192K  /var/data/ad44-data
data/clients/ad53-data             192K  87.1T   192K  /var/data/ad53-data
data/clients/ad64-data             192K  87.1T   192K  /var/data/ad64-data
data/clients/am-angers-data        192K  87.1T   192K  /var/data/am-angers-data
data/clients/apbp-data             192K  87.1T   192K  /var/data/apbp-data
data/clients/bm-rouen-data         192K  87.1T   192K  /var/data/bm-rouen-data
data/clients/canigo-data           192K  87.1T   192K  /var/data/canigo-data
data/clients/cdf-data              192K  87.1T   192K  /var/data/cdf-data
data/clients/cnd-data              192K  87.1T   192K  /var/data/cnd-data
data/clients/demo-v4-data          192K  87.1T   192K  /var/data/demo-v4-data
data/clients/drac-ge-data          192K  87.1T   192K  /var/data/drac-ge-data
data/clients/ens-lyon-data         192K  87.1T   192K  /var/data/ens-lyon-data
data/clients/formation0-data       192K  87.1T   192K  /var/data/formation0-data
data/clients/formation1-data       192K  87.1T   192K  /var/data/formation1-data
data/clients/formation2-data       192K  87.1T   192K  /var/data/formation2-data
data/clients/formation3-data       192K  87.1T   192K  /var/data/formation3-data
data/clients/formation4-data       192K  87.1T   192K  /var/data/formation4-data
data/clients/module-pleade-data    192K  87.1T   192K  /var/data/module-pleade-data
data/clients/msh-dijon-data        192K  87.1T   192K  /var/data/msh-dijon-data
data/clients/port-dunkerque-data   192K  87.1T   192K  /var/data/port-dunkerque-data
data/clients/siges-data            192K  87.1T   192K  /var/data/siges-data
data/clients/test-ajlsm-data       192K  87.1T   192K  /var/data/test-ajlsm-data

Script d’import SFTP corrigé après création des datasets

Voir uassi : Transfert_des_comptes_FTP_vers_SFTP_(d'un_serveur_à_un_autre)

Pourquoi un second script

Une fois les datasets montés sur les chemins /var/data/<client>-data, les anciens répertoires de base étaient masqués par les nouveaux montages ZFS.

Il fallait donc rejouer la création de la structure :

home du chroot ;
sous-répertoire data/ ;
droits.

Sans recréer les utilisateurs déjà présents.

Script utilisé

#!/usr/bin/env bash
set -euo pipefail

IMPORT_FILE="${1:-/root/ftp_users_export.tsv}"

if [[ ! -f "$IMPORT_FILE" ]]; then
  echo "Fichier introuvable : $IMPORT_FILE"
  exit 1
fi

echo "=== Import des utilisateurs SFTP ==="

while IFS=$'\t' read -r username uid gid groupname home shell shadow_hash; do

    [[ "$username" == "username" ]] && continue

    echo "→ Traitement $username ($home)"

    if ! getent group "$groupname" >/dev/null; then
        echo "   - création groupe $groupname"
        groupadd -g "$gid" "$groupname"
    fi

    if id "$username" &>/dev/null; then
        echo "   - utilisateur déjà existant"
    else
        useradd \
            -u "$uid" \
            -g "$groupname" \
            -d "$home" \
            -s /usr/sbin/nologin \
            -M \
            "$username"

        usermod -p "$shadow_hash" "$username"
    fi

    mkdir -p "$home"
    mkdir -p "$home/data"

    chown root:root "$home"
    chmod 755 "$home"

    chown "$username:$groupname" "$home/data"
    chmod 755 "$home/data"

done < "$IMPORT_FILE"

echo "=== Import terminé ==="

Exécution

chmod +x /root/import_sftp_users_after-zfs.sh
/root/import_sftp_users_after-zfs.sh

Résultat observé :

tous les utilisateurs existaient déjà ;
la structure et les droits ont été recréés correctement dans les datasets.

Vérification

find /var/data -mindepth 1 -maxdepth 2 | sort
ls -ld /var/data/ad53-data /var/data/ad53-data/data

Exemple de résultat :

drwxr-xr-x 3 root root   3 Apr  3 11:46 /var/data/ad53-data
drwxr-xr-x 2 ad53 pleade 2 Apr  3 11:46 /var/data/ad53-data/data

Configuration SSH / SFTP chrooté

Voir aussi : Doctrine_des_accès_sur_eole3#3._Comptes_clients_SFTP

Objectif

Permettre un accès SFTP de secours (mode emergency) en confinant les utilisateurs dans leur environnement, sans accès SSH interactif.

Configuration retenue

Fichiers :

/etc/ssh/sshd_config
/etc/ssh/sshd_config.d/20-eole3-sftp.conf

Fichier principal

Include /etc/ssh/sshd_config.d/*.conf

PermitRootLogin yes
PasswordAuthentication yes
KbdInteractiveAuthentication no
UsePAM yes
X11Forwarding no
PrintMotd no
AcceptEnv LANG LC_*

Subsystem sftp internal-sftp

Configuration spécifique SFTP

Match Group eole3-sftp
    ChrootDirectory %h
    ForceCommand internal-sftp -P setstat,fsetstat
    AllowTcpForwarding no
    PermitTunnel no
    X11Forwarding no
    PasswordAuthentication yes

Explications

Match Group eole3-sftp applique le confinement uniquement aux comptes SFTP.
ChrootDirectory %h enferme l’utilisateur dans son dataset.
ForceCommand internal-sftp interdit tout accès SSH interactif.
-P setstat,fsetstat limite certaines opérations (compatibilité clients).
AllowTcpForwarding no désactive les tunnels TCP.
PermitTunnel no désactive les tunnels TUN/TAP.
X11Forwarding no interdit le forwarding X11.

Important

Le groupe pleade n’est **plus utilisé** pour le confinement SFTP.
Le groupe dédié est eole3-sftp.
Les comptes d’administration (ex : ajlsm) **ne doivent jamais appartenir à ce groupe**.

Ajout des comptes clients existants à eole3-sftp

Comptes clients déjà créés sous /var/data, en excluant ajlsm, ubuntu, root, etc.

for u in ad44 ad53 ad64 am-angers apbp bm-rouen canigo cdf cnd demo-v4 drac-ge ens-lyon formation0 formation1 formation2 formation3 formation4 module-pleade msh-dijon pdk siges test-ajlsm pleadecom; do   usermod -aG eole3-sftp "$u"; done

Puis contrôle :

getent group eole3-sftp

et pour quelques comptes :

id ad53
id apbp
id pleadecom
id ajlsm

Test de cohérence sshd

sshd -t
sshd -T -C user=ad53,addr=127.0.0.1,host=eole3 | egrep 'forcecommand|chrootdirectory'
sshd -T -C user=ajlsm,addr=127.0.0.1,host=eole3 | egrep 'forcecommand|chrootdirectory'

Résultat attendu :

ad53 : internal-sftp + chrootdirectory %h
ajlsm : forcecommand none / chrootdirectory none

Test et rechargement

sshd -t
systemctl restart ssh

Tests du chroot SFTP

Test avec un utilisateur client

sftp ad53@localhost

Puis dans la session SFTP :

pwd
ls

Résultat attendu et obtenu :

Remote working directory: /
data

Cela confirme :

le chroot fonctionne ;
l’utilisateur ne voit que son environnement SFTP ;
le seul répertoire visible est data.

Préparation à la migration rsync

Principe

Les données historiques de eole2 doivent être copiées dans le sous-répertoire data/ de chaque client, et non à la racine du home chrooté.

Donc :

source : root@eole2:/var/data/<client>-data/
destination : /var/data/<client>-data/data/

Options rsync retenues

-aHAXv --numeric-ids

Signification :

-a : archive ;
-H : liens physiques ;
-A : ACL ;
-X : xattrs ;
-v : verbeux ;
--numeric-ids : conserve les UID/GID numériques.

Test à blanc sur un petit dataset

Exemple avec test-ajlsm-data :

rsync -aHAXvn --numeric-ids \
  root@193.70.47.97:/var/data/test-ajlsm-data/ \
  /var/data/test-ajlsm-data/data/

Résultat observé :

receiving incremental file list
./
projet/
projet/mirador3-reactjs.tar.gz

sent 34 bytes  received 142 bytes  117.33 bytes/sec
total size is 236,697,705  speedup is 1,344,873.32 (DRY RUN)

Copie réelle

rsync -aHAXv --numeric-ids \
  root@193.70.47.97:/var/data/test-ajlsm-data/ \
  /var/data/test-ajlsm-data/data/

Résultat observé :

receiving incremental file list
./
projet/
projet/mirador3-reactjs.tar.gz

sent 54 bytes  received 236,755,675 bytes  94,702,291.60 bytes/sec
total size is 236,697,705  speedup is 1.00

Vérification après copie

ls -la /var/data/test-ajlsm-data/data/

Exemple :

total 2
drwxr-xr-x 3 test-ajlsm pleade 3 Jul 29  2025 .
drwxr-xr-x 3 root       root   3 Apr  3 11:46 ..
drwxr-xr-x 2 test-ajlsm   1001 3 Jul 29  2025 projet

Second test rsync : module-pleade-data

Test à blanc

rsync -aHAXvn --numeric-ids \
  root@193.70.47.97:/var/data/module-pleade-data/ \
  /var/data/module-pleade-data/data/

Copie réelle

rsync -aHAXv --numeric-ids \
  root@193.70.47.97:/var/data/module-pleade-data/ \
  /var/data/module-pleade-data/data/

Vérification locale

ls -la /var/data/module-pleade-data/data/
zfs list data/clients/module-pleade-data

Résultat observé :

total 35
drwxrwxr-x 4          1025   1001     5 Nov 18  2022 .
drwxr-xr-x 3 root          root       3 Apr  3 11:46 ..
-rwxr-xr-x 1 module-pleade pleade 12628 Nov 15  2022 .htaccess
drwxrwxrwx 2 module-pleade pleade     3 Nov 18  2022 logs
drwxrwxrwx 6 module-pleade pleade    16 Dec 19  2022 pleade

NAME                              USED  AVAIL  REFER  MOUNTPOINT
data/clients/module-pleade-data  39.4M  87.1T  39.3M  /var/data/module-pleade-data

Vérification SFTP

sftp module-pleade@localhost

Puis :

pwd
ls
cd data/
ls
cd pleade/
ls

Résultat observé :

pwd renvoie / ;
ls montre seulement data ;
le contenu copié est visible dans data/.

État de l’installation à ce stade

À ce stade, les éléments suivants sont validés :

Ubuntu 24.04 installé sur les NVMe ;
pool ZFS data en RAIDZ2 sur les 6 disques de 22 To ;
dataset racine monté sur /var/data ;
dataset ZFS dédié par client ;
comptes SFTP recréés ;
chroot SFTP fonctionnel ;
tests de migration rsync validés sur petits jeux de données.

Étapes suivantes prévues

Les étapes à traiter ensuite sont :

lancer les rsync réels pour tous les clients ;
éventuellement définir des quotas ZFS par dataset client ;
mettre en place des snapshots ZFS ;
prévoir la stratégie de rétention et de purge ;
surveiller le taux de remplissage du pool ;
préparer éventuellement la réplication ou la sauvegarde secondaire.

Commandes utiles récapitulatives

Vérification ZFS

zpool status
zpool list
zfs list -r data
df -h

Vérification des répertoires

find /var/data -mindepth 1 -maxdepth 2 | sort
ls -ld /var/data/ad53-data /var/data/ad53-data/data

Vérification SSH

sshd -t
systemctl restart ssh
grep -v '^#' /etc/ssh/sshd_config

Test SFTP

sftp ad53@localhost

Test rsync à blanc

rsync -aHAXvn --numeric-ids \

 root@193.70.47.97:/var/data/module-pleade-data/ \
 /var/data/module-pleade-data/data/

</syntaxhighlight>

Copie réelle

rsync -aHAXv --numeric-ids \
  root@193.70.47.97:/var/data/module-pleade-data/ \
  /var/data/module-pleade-data/data/

Synchronisation des données eole2 → eole3 (rsync réseau privé)

Objectif

Mettre en place une synchronisation incrémentale des données entre :

eole2 (source)
eole3 (destination ZFS + SFTP)

La synchronisation utilise :

le réseau privé (vRack) : 192.168.123.0/24
rsync via SSH
une exécution automatisée via cron
des logs horodatés

---

Principe

Chaque dataset client est synchronisé de :

/var/data/<client>-data/

vers :

/var/data/<client>-data/data/

Ce choix est imposé par la configuration SFTP chrootée de eole3.

---

Script de synchronisation

Fichier :

/root/rsync_from_eole2_private.sh

Contenu :

#!/usr/bin/env bash
set -euo pipefail
IFS=$'\n\t'
umask 022

BASE_DIR="/opt/rsync_eole2_to_eole3"
LOG_DIR="$BASE_DIR/logs"
TMP_DIR="$BASE_DIR/tmp"
LOCK_FILE="$TMP_DIR/rsync_eole2_to_eole3.lock"

SRC_HOST="192.168.123.101"
SRC_USER="root"
SSH_OPTS="-p 22 -o ConnectTimeout=30"

mkdir -p "$LOG_DIR" "$TMP_DIR" /var/data/tmp/rsync-partial

LOG_FILE="$LOG_DIR/rsync_eole2_to_eole3_$(date +%F_%H-%M-%S).log"

log() {
  printf "[%s] %s\n" "$(date '+%Y-%m-%d %H:%M:%S')" "$*"
}

exec 9>"$LOCK_FILE"
if ! flock -n 9; then
  {
    log "Un rsync eole2 -> eole3 est deja en cours, abandon."
  } >> "$LOG_FILE" 2>&1
  exit 0
fi

TARGETS=(
  "template-data"
  "tmp"
  "test-ajlsm-data"
  "cnd-data"
  "module-pleade-data"
  "test-ftp-data"
  "formation3-data"
  "formation4-data"
  "formation-data-template"
  "formation0-data"
  "formation2-data"
  "formation1-data"
  "am-angers-data"
  "demo-v4-data"
  "drac-ge-data"
  "ad44-data"
  "cdf-data"
  "pleade.com-data"
  "ftp-ajlsm-data"
  "canigo-data"
  "msh-dijon-data"
  "ens-lyon-data"
  "apbp-data"
  "ad53-data"
  "ad64-data"
)

{
  log "=== Debut rsync eole2 -> eole3 via reseau prive ==="

  for name in "${TARGETS[@]}"; do
    SRC="/var/data/${name}/"
    DST="/var/data/${name}/data/"

    log "--- ${name} ---"
    log "Source      : ${SRC_USER}@${SRC_HOST}:${SRC}"
    log "Destination : ${DST}"

    if [ ! -d "$DST" ]; then
      log "ERREUR: destination absente : $DST"
      continue
    fi

    /usr/bin/ionice -c2 -n7 /usr/bin/nice -n 19 \
      /usr/bin/rsync \
        -aHAX \
        --numeric-ids \
        --delete-after \
        --safe-links \
        --omit-dir-times \
        --stats \
        --human-readable \
        --partial \
        --partial-dir="/var/data/tmp/rsync-partial" \
        --temp-dir="/var/data/tmp" \
        -e "ssh $SSH_OPTS" \
        "${SRC_USER}@${SRC_HOST}:${SRC}" \
        "$DST"

    RC=$?
    log "Fin ${name} / RC=${RC}"
  done

  log "=== Fin rsync eole2 -> eole3 ==="
} >> "$LOG_FILE" 2>&1

---

Permissions et préparation

chmod +x /root/rsync_from_eole2_private.sh

mkdir -p /opt/rsync_eole2_to_eole3/logs
mkdir -p /opt/rsync_eole2_to_eole3/tmp
mkdir -p /var/data/tmp/rsync-partial

---

Exécution manuelle

nohup /root/rsync_from_eole2_private.sh >/dev/null 2>&1 &

---

Suivi en temps réel

tail -f "$(ls -1t /opt/rsync_eole2_to_eole3/logs/rsync_eole2_to_eole3_*.log | head -1)"

---

Vérification du processus

pgrep -af rsync

---

Supervision ZFS

zpool iostat -v 5

---

Mise en place du cron

crontab -e

Ajouter :

0 1 * * * /root/rsync_from_eole2_private.sh

Vérification :

crontab -l

---

Problèmes connus

Répertoire data absent

Erreur possible :

ERREUR: destination absente : /var/data/<client>-data/data/

Solution :

mkdir -p /var/data/<client>-data/data
chown <user>:<group> /var/data/<client>-data/data

---

Performances observées

Réseau privé (vRack)
Débit moyen : 60 à 120 MB/s
Exemple :

 * 30 Go copiés en ~4 minutes

---

Comportement rsync

Première synchronisation : copie complète
Synchronisations suivantes :

 * incrémentales
 * très rapides
 * peu de trafic réseau

---

Sécurité

Accès via SSH uniquement
Utilisation du réseau privé
Pas d'exposition Internet
Isolation par dataset ZFS

---

Remarques

Le script empêche les exécutions simultanées (flock)
Les logs sont horodatés
Chaque dataset est traité indépendamment
Les erreurs sur un dataset n'interrompent pas les autres

Installation de eole3 avec stockage ZFS et migration FTP vers SFTP

Installation de eole3 avec stockage ZFS et migration FTP vers SFTP

Objectif

Contexte matériel

Choix d’architecture

Système

Données

Installation initiale depuis OVH

Choix de l’OS

Résultat attendu après installation

Installation et création du pool ZFS

Installation du paquet ZFS

Nettoyage des signatures éventuelles sur les disques DATA

Création du pool ZFS

Vérification du pool

Préparation des comptes SFTP

Principe

Fichier d’export

Script d’import initial des comptes SFTP

Script initial

Limite du script initial

Création des datasets ZFS par client

Situation avant structuration fine

Création d’un parent logique

Création automatique d’un dataset par home client

Vérification après création

Script d’import SFTP corrigé après création des datasets

Pourquoi un second script

Script utilisé

Exécution

Vérification

Configuration SSH / SFTP chrooté

Objectif

Configuration retenue

Fichier principal

Configuration spécifique SFTP

Explications

Important

Ajout des comptes clients existants à eole3-sftp

Test et rechargement

Tests du chroot SFTP

Test avec un utilisateur client

Préparation à la migration rsync

Principe

Options rsync retenues

Test à blanc sur un petit dataset

Copie réelle

Vérification après copie

Second test rsync : module-pleade-data

Test à blanc

Copie réelle

Vérification locale

Vérification SFTP

État de l’installation à ce stade

Étapes suivantes prévues

Commandes utiles récapitulatives

Vérification ZFS

Vérification des répertoires

Vérification SSH

Test SFTP

Test rsync à blanc

Copie réelle

Synchronisation des données eole2 → eole3 (rsync réseau privé)

Objectif

Principe

Script de synchronisation

Permissions et préparation

Exécution manuelle

Suivi en temps réel

Vérification du processus

Supervision ZFS

Mise en place du cron

Problèmes connus

Répertoire data absent

Performances observées

Comportement rsync

Sécurité

Remarques

Menu de navigation

Rechercher