Nous utilisons des baies EMC Isilon pour notre stockage TIER3 et d’archive depuis environ un an désormais. Historiquement, les clusters OneFS ont été beaucoup utilisés via des partages CIFS sur lesquels tout se passait bien. Mais nous avons eu l’occasion plus récemment de produire des volumes via NFS… et là, les choses se sont compliquées au niveau des droits d’accès. Petite explication et retour d’expérience.
La gestion des permissions sur Isilon est un très vaste sujet. En effet, EMC a choisi un modèle unifié dans la représentation des droits d’accès, quel que soit le protocole utilisé. Il est possible techniquement, grâce à cette approche, d’exploiter des volumes Isilon à la fois via NFS et CIFS (voir FTP) tout en conservant une homogénéité dans les droits associés. Or, vous savez sans doute que le monde Windows dispose d’ACL plus riches que nos bon vieux rwx sous Unix (territoire de NFS). Certes, on peut améliorer les choses en activant les extensions ACL POSIX mais cela reste moins granulaire que sous Windows.
Pour pouvoir unifier (ou réconcilier, plutôt) les deux environnements, les ingénieurs Isilon ont mis au point un troisième modèle d’ACL associé à des règles de “traduction” (je ne rentre pas dans le détail, pardon pour les experts qui trouveraient mes termes mal choisis) entre les deux mondes. Ainsi, une permission posée sur Windows avec tous ses droits spécifiques sera d’abord traduite en ACL “Isilon”, puis convertie ensuite en ACL Unix.
Sur le papier ça fonctionne très bien et c’est une solution intéressante. Dans la pratique, cela peut poser des petits soucis spécifiques, même dans les environnements non partagés Windows/Unix. Dans la pratique donc, il nous est arrivé un souci spécifique lors de la mise en place d’un partage NFS sur un serveur qui était exploité par plusieurs users Unix différents, membre de groupes divers. Nous avions des comportements bizarres sur certains fichiers et répertoires : certains y accédaient, mais pas d’autres, qu’ils soient propriétaires ou non des objets en question. La ré-application des droits unix ne changeait pas grand chose. En désespoir de cause, nous avons contacté EMC.
Et là, nous avons découvert tout un nouveau monde merveilleux de la gestion des droits Isilon. Ce faisant, je me suis attaqué au pavé dédié sur le site du support. Bon, je vous avoue, je ne suis pas encore arrivé au bout, mais voici la solution très pragmatique à notre problème de production qui nous a été proposée par EMC.
Lorsque l’on créé un nouveau partage NFS qui doit être utilisé par des utilisateurs variés, nous appliquons systématiquement cette commande avant tout stockage de donnée sur ce volume :
|
1 |
chmod +a group "<gid>" allow <droits>,object_inherit,container_inherit <chemin_vers_racine_nfs></chemin_vers_racine_nfs></droits></gid> |
… l’objectif est de mettre en oeuvre le système intégré d’héritage de OneFS sur ce volume et appliqué au groupe cible. Si il existe plusieurs groupes potentiels d’utilisateurs, il faut la passer pour tous, sans se poser de question. Grosso modo, il s’agit donc que tout nouveau fichier ou répertoire créé hérite ses droits de son parent. Vous devez remplacer les champs par leur valeur adaptée au contexte. Pour la partie <DROITS> il s’agit de choisir parmi les 3 possibilités (bien connues du monde Unix) R-W-X. Les 3 attributs possibles, en terminologie Isilon, sont : dir_gen_read, dir_gen_write et dir_gen_execute.
Exemple : un partage NFS est créé sur la racine Isilon /ifs/data/partagenfs pour un serveur exploité par 4 utilisateurs Unix différents. Les 4 utilisateurs sont membre d’un group “users” dont le GID est 200. On souhaite que toutes ces personnes puissent utiliser en lecteur/ecriture et exécution les fichier et répertoires du share NFS. Pour que cela fonctionne bien, lancez la commande suivante :
|
1 |
chmod +a group "200" allow dir_gen_read, dir_gen_write,dir_gen_execute,object_inherit,container_inherit /ifs/data/partagenfs |
Si jamais vous oubliez de positionner ces droits à la racine, il est possible de corriger les droits a posterio, mais cela nécessite de parcourir l’ensemble du volume et exécuter des commandes de ce type sur chaque objet fichier ou répertoire. Frédéric, Un de nos super-héros Unix a créé un petit script shell qui permet d’appliquer ce type de droits à l’ensemble d’une arborescence donnée. A utiliser à vos risques et périls, bien entendu :)
Vous pouvez le télécharger à cette adresse
http://vblog.io/downloads/chg_attrib_recurse_v1.1.sh
Je suis très intéressé par vos retours sur ce sujet, car celui-ci est tellement riche que le partage d’expérience me parait la meilleure méthode pour maîtriser la bête. Donc à vos commentaires !