Réflexion sur l’évolution des accès fichiers sur eole3

Objectif

Documenter l’état de réflexion avant l’installation de SFTPGo, afin de garder une trace des choix envisagés, de leurs conséquences immédiates et futures, notamment pour :

l’organisation des données sur eole3 ;
les accès clients en SFTP ;
le fonctionnement des VM clientes ;
la sauvegarde et la réplication vers beotos3.

Cette note sert de base de relecture avant décision définitive.

---

Étape 1 : sécuriser le backup avant tout changement

Avant toute modification importante de droits ou d’ACL, un backup des ACL a été réalisé.

Commande utilisée :

mkdir -p /root/acl-backups
getfacl -R /var/data > /root/acl-backups/acl-backup-AAAA-MM-JJ_HHMM.acl

Remarque :

sur un serveur contenant de très nombreux fichiers, cette commande peut être longue ;
le temps dépend surtout du nombre d’inodes, pas directement du volume total en To.

Une fois le backup terminé, il est recommandé de le compresser puis de le recopier sur un autre serveur avant toute manipulation importante.

Exemple :

cd /root/acl-backups
tar -czf acl-backup-AAAA-MM-JJ_HHMM.tar.gz acl-backup-AAAA-MM-JJ_HHMM.acl

Puis recopie vers un autre serveur :

scp acl-backup-AAAA-MM-JJ_HHMM.tar.gz user@serveur:/chemin/de/sauvegarde/

Objectif :

garantir un rollback des ACL ;
ne pas perdre ce backup si eole3 est modifié ou endommagé.

---

Rappel du contexte technique

Le stockage est actuellement organisé avec :

un pool ZFS principal data ;
un dataset logique data/clients avec canmount=off ;
un dataset ZFS par client monté sous /var/data/<client>-data.

Exemple :

data/clients/ad53-data        -> /var/data/ad53-data
data/clients/ad64-data        -> /var/data/ad64-data
data/clients/pleade.com-data  -> /var/data/pleade.com-data

Cette base ZFS est saine et constitue un bon socle pour une évolution future.

---

Situation initiale côté SFTP OpenSSH

Un accès SFTP a d’abord été mis en place via OpenSSH, avec un groupe dédié eole3-sftp afin de ne plus mélanger les comptes clients SFTP avec le groupe applicatif pleade.

Problème initial

La configuration historique utilisait :

Match Group pleade
    ChrootDirectory %h
    ForceCommand internal-sftp

Conséquence :

tous les utilisateurs du groupe pleade étaient forcés en SFTP ;
cela bloquait l’utilisateur admin ajlsm qui devait conserver un vrai accès SSH.

Correction adoptée

Création d’un groupe dédié :

groupadd eole3-sftp

Exemple d’ajout d’un utilisateur SFTP de test :

usermod -aG eole3-sftp pleadecom

Et configuration SSH dédiée :

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

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

Remarques :

ajlsm ne doit pas appartenir à eole3-sftp ;
l’ancien bloc Match Group pleade a été commenté dans /etc/ssh/sshd_config.

Validation :

sshd -t
systemctl reload ssh

Contrôles :

sshd -T -C user=pleadecom,addr=127.0.0.1,host=eole3
sshd -T -C user=ajlsm,addr=127.0.0.1,host=eole3

Résultat obtenu :

pleadecom est bien forcé en SFTP ;
ajlsm conserve un accès SSH normal.

---

Difficultés rencontrées avec OpenSSH SFTP

Plusieurs problèmes ont été rencontrés.

1. Délai important à l’ouverture de session

Des connexions SSH/SFTP prenaient environ 25 secondes.

Le problème a été relié à pam_systemd / systemd-logind et non à la configuration SFTP elle-même.

Impact :

lenteur en SSH ;
lenteur en SFTP ;
timeout côté FileZilla.

2. Overwrite de fichiers existants

Comportement observé :

création de nouveaux fichiers : OK ;
renommage : OK ;
remplacement d’un fichier existant : échec dans plusieurs cas.

Le cœur du problème vient du fait que :

les droits réels des répertoires sont très hétérogènes ;
beaucoup de fichiers existants sont en 644 ;
le comportement attendu avec l’ancien FTP n’est pas automatiquement reproduit par SFTP.

Constat important :

pour permettre un overwrite fiable, il faut des zones de dépôt cohérentes ;
le simple maintien de l’arborescence historique ne suffit pas.

---

Analyse fonctionnelle des données

En observant les répertoires existants, trois catégories de données ont été identifiées.

1. Dépôt de données par le client

Exemples typiques :

contenus placés dans les zones équivalentes à pleade/internet, images, ead, pdf, etc. ;
éventuellement projet ou projets selon les clients.

Ces données doivent :

être accessibles en SFTP ;
pouvoir être déposées, remplacées, supprimées ou renommées par le client ;
être lues ensuite par la VM si nécessaire.

2. Données dérivées générées par les traitements

Exemple :

images-preparees.

Ces données :

sont générées à partir des originaux ;
représentent souvent une part très importante du volume stocké ;
ne doivent pas être exposées aux clients ;
doivent rester réservées à la VM concernée.

3. Données internes nécessaires à l’application

Exemple :

data-private ;
éléments Drupal ;
données techniques ou runtime.

Ces données :

ne doivent pas être exposées en SFTP ;
doivent rester accessibles à la VM du client concerné ;
doivent être étanches entre clients.

---

Première conclusion importante

La vraie séparation utile n’est pas d’abord entre data-private et images-preparees.

La séparation la plus urgente et la plus utile est :

ce qui relève du dépôt client ;
tout le reste.

Autrement dit :

le SFTP ne doit servir qu’au dépôt client ;
les données internes et dérivées doivent être sorties du périmètre SFTP.

---

Modèle cible envisagé

Pour chaque client, organisation cible :

/var/data/<client>-data/
├── upload/
│   ├── pleade/
│   └── projets/
│
└── internal/
    ├── data-private/
    │   ├── images-preparees/
    │   └── pleade/
    │       ├── datadir/
    │       └── ...
    └── drupal/

Interprétation :

upload = dépôt client, visible côté SFTP ;
internal = tout ce qui doit rester réservé à la VM.

Remarque :

la séparation éventuelle ultérieure entre data-private et images-preparees n’est pas encore décidée ;
pour le moment, ils peuvent rester regroupés dans internal.

---

Choix d’exposition SFTP

Deux grandes approches ont été envisagées.

Option A : OpenSSH SFTP avec chroot classique

Avec :

ChrootDirectory %h

et home de l’utilisateur pointant sur :

/var/data/<client>-data

Conséquence :

le client verrait la racine du dataset ;
donc potentiellement /upload et /internal.

Pour éviter cela, il faudrait ensuite masquer ou interdire internal.

Conclusion :

techniquement faisable ;
mais peu élégant ;
et demande ensuite une logique de droits plus complexe.

Option B : SFTPGo en frontal

Idée :

utiliser SFTPGo comme couche d’accès SFTP ;
exposer uniquement les chemins voulus ;
masquer complètement internal ;
gérer les comptes clients dans SFTPGo plutôt que via OpenSSH seul.

Conclusion provisoire :

cette option est la plus prometteuse ;
il faut la tester maintenant, avant de restructurer toute l’infrastructure autour d’elle.

---

Répertoires simples ou sous-datasets ZFS ?

Deux stratégies ont été discutées.

Hypothèse 1 : simples répertoires dans le dataset client existant

Exemple :

/var/data/ad53-data/upload
/var/data/ad53-data/internal

Avantages :

très simple ;
rapide à mettre en place ;
faible risque technique immédiat.

Inconvénients :

pas de quotas séparés ;
snapshots et réplications non distingués ;
pas de séparation physique nette entre dépôt et données internes.

Hypothèse 2 : sous-datasets ZFS

Exemple :

data/clients/ad53-data/upload
data/clients/ad53-data/internal

montés respectivement sur :

/var/data/ad53-data/upload
/var/data/ad53-data/internal

Avantages :

quotas séparés ;
snapshots indépendants ;
réplication plus fine ;
base plus propre pour l’industrialisation et le backup.

Inconvénients :

plus de rigueur à la mise en place ;
impact plus important sur l’organisation ;
nécessite de valider auparavant le rôle réel de SFTPGo.

---

Argument décisif en faveur des sous-datasets

La réflexion a évolué en faveur des sous-datasets ZFS pour une raison importante :

les quotas doivent s’appliquer aux données réellement déposées par les clients ;
les données dérivées comme images-preparees ne doivent pas consommer le quota client.

Donc, si les quotas restent gérés au niveau ZFS, il faut séparer au moins :

upload ;
internal.

Exemple cible :

zfs create data/clients/ad53-data/upload
zfs create data/clients/ad53-data/internal

zfs set quota=5T data/clients/ad53-data/upload
zfs set quota=none data/clients/ad53-data/internal

Conclusion :

si les quotas restent pilotés par ZFS, les sous-datasets deviennent très pertinents ;
si SFTPGo gère correctement le quota logique côté dépôt client, la séparation pourrait éventuellement rester fonctionnelle sans sous-datasets, mais cela devait être validé par test.

---

Réflexion sur les quotas SFTPGo

Question posée :

SFTPGo permet-il de gérer des quotas ?
et si oui, cela permet-il d’éviter la création de deux sous-datasets ?

Constat :

SFTPGo sait gérer des quotas logiques sur des dossiers virtuels et des permissions par chemin ;
cela peut être suffisant pour limiter un client à son espace de dépôt ;
mais cela ne remplace pas un quota ZFS physique.

Conséquence :

si l’objectif est seulement un quota fonctionnel côté client, SFTPGo peut être une solution suffisante ;
si l’objectif est aussi d’avoir une séparation physique et des quotas durs au niveau du stockage, les sous-datasets ZFS gardent leur intérêt.

Décision avant test :

installer et tester SFTPGo d’abord ;
ne pas figer immédiatement le choix 1 dataset ou 2 datasets ;
prendre la décision après validation réelle de SFTPGo en frontal.

---

Impact sur la réplication vers beotos3

Le serveur beotos3 doit reproduire rapidement et proprement ce qui fonctionnera sur eole3.

Contrainte métier :

pas trop tôt pour éviter une désynchronisation avec eole2 encore utilisé ;
pas trop tard après la bascule vers eole3 pour ne pas risquer une perte de données.

Conséquence :

la solution finale doit être industrialisable ;
elle doit pouvoir être reproduite vite sur beotos3 ;
elle doit être stable avant généralisation.

Raisonnement retenu :

il vaut mieux valider l’architecture sur eole3 ;
puis reproduire exactement la même logique sur beotos3 ;
et non reconstruire manuellement un modèle différent sur le backup.

---

État de l’existant sur eole3 au moment de la réflexion

Constats généraux :

1 dataset ZFS par client est déjà en place ;
les structures internes sont hétérogènes ;
les permissions Unix sont très variables selon les clients ;
certaines zones relèvent clairement du dépôt ;
d’autres relèvent du fonctionnement de la VM ;
le mélange historique FTP ne permet pas de généraliser simplement un modèle SFTP sans restructuration.

En revanche :

la base ZFS existante est bonne ;
la séparation par client existe déjà ;
cela constitue un bon socle pour la suite.

---

Installation de SFTPGo : décision de test

Décision retenue avant installation :

installer SFTPGo maintenant ;
le paramétrer simplement ;
vérifier qu’il sait :
- exposer uniquement les datasets ou répertoires souhaités ;
- créer et gérer les comptes clients ;
- permettre upload, overwrite, delete, rename ;
- masquer ce qui ne doit pas être visible ;
décider ensuite, à partir du comportement réel, si l’architecture finale repose sur :
- 1 dataset client avec séparation logique ;
- ou 2 sous-datasets ZFS par client.

L’objectif n’est donc pas encore de figer toute l’architecture finale, mais de valider d’abord que SFTPGo fait bien le travail attendu en frontal.

---

Résumé des options en discussion

Option 1 : conserver OpenSSH SFTP

Avantages :

déjà en place ;
pas de nouvelle brique logicielle.

Inconvénients :

comportement plus rigide ;
gestion plus compliquée des zones visibles ;
overwrite et permissions plus délicats ;
moins pratique pour exposer seulement certaines parties.

Option 2 : passer à SFTPGo

Avantages :

exposition contrôlée des chemins ;
gestion plus simple des comptes clients ;
possibilité de masquer complètement internal ;
quotas logiques possibles ;
meilleure souplesse pour l’avenir.

Inconvénients :

ajout d’une nouvelle brique à maintenir ;
nécessité de vérifier que cela s’intègre bien à l’infra existante.

Option A : un seul dataset client

Avantages :

simplicité ;
peu de modifications structurelles.

Inconvénients :

quota client non distinct des dérivés si on reste sur des quotas ZFS ;
snapshots et réplication non différenciés.

Option B : deux sous-datasets ZFS par client

Avantages :

quotas propres ;
séparation nette ;
meilleure base pour réplication et industrialisation.

Inconvénients :

demande plus de préparation ;
intérêt à confirmer après test réel de SFTPGo.

---

Conclusion provisoire avant installation de SFTPGo

À ce stade :

le backup des ACL a été réalisé ;
la réflexion a permis d’identifier une séparation fonctionnelle claire entre dépôt client et données internes ;
la séparation upload / internal est retenue comme direction cible ;
la séparation supplémentaire entre data-private et images-preparees reste à discuter ultérieurement ;
le choix entre 1 dataset ou 2 sous-datasets n’est pas définitivement tranché ;
l’installation et le test de SFTPGo doivent permettre de décider plus sereinement.

La prochaine étape logique est donc :

installer SFTPGo ;
valider son comportement réel sur eole3 ;
puis prendre la décision d’architecture finale en intégrant les besoins de réplication vers beotos3.

Réflexion sur l’évolution des accès fichiers sur eole3

Sommaire