[FRsAG] NFSv4 et ACL : problèmes

Jonathan Tremesaygues jonathan.tremesaygues at menta.fr
Jeu 31 Juil 16:06:06 CEST 2014


 > Ok, j'ai rien de plus à dire que vérifier les versions des 
installations...
Sur les clients, on utilise les versions fournies pour RHEL 6.5.
Sur le Qnap, suite à nos premiers échecs, et ne connaissant pas vraiment 
les versions des programmes utilisés
qu'on supposés antédiluviennes (NFSv4 n'est pas officiellement supporté 
par Qnap), on a recompilé et installé
les différents outils dans leurs dernières versions :
  - nfs4-acl-tools (nfs4_getfacl, nfs4_setfacl) : 0.3.3
  - libnfsidmap (libnfsidmap) : 0.25
  - nfs-utils (rpc.idmapd, rpc.mountd, ...) : 1.3.0


 > Le montage sur lequel a été placé les ACL a bien été remonté (machine 
redémarrée si sur / ) au moins une fois depuis l'activation des acl ?
La partition de données est bien montée avec les options acl et 
user_xttr, et la bestiole a déjà été redémarré depuis l'activation des ACLs
[/] # mount | grep md0
/dev/md0 on /share/MD0_DATA type ext4 
(rw,usrjquota=aquota.user,jqfmt=vfsv0,user_xattr,data=ordered,delalloc,acl)


 > Peut-être la faute au QNAP comme tu dis, mais je trouverai ça bizarre...
Juste ça marche bien avec Scientific Linux, Ubuntu ou Arch Linux en 
serveur (j'ai eu le temps de faire des tests, vive les VM),
mais pas avec cette saloperie de QNAP, je ne vois pas vraiment d'autres 
explications.


On 07/31/2014 03:43 PM, Arnaud Serrut wrote:
> Ok, j'ai rien de plus à dire que vérifier les versions des 
> installations... Le montage sur lequel a été placé les ACL a bien été 
> remonté (machine redémarrée si sur / ) au moins une fois depuis 
> l'activation des acl ?
>
> Peut-être la faute au QNAP comme tu dis, mais je trouverai ça bizarre...
>
> ------------------------------------------------------------------------
> Date: Thu, 31 Jul 2014 11:04:22 +0200
> From: jonathan.tremesaygues at menta.fr
> To: arnaud.serrut at hotmail.fr
> CC: frsag at frsag.org
> Subject: Re: [FRsAG] NFSv4 et ACL : problèmes
>
> Cette config est la même sur ma VM.
>
> C'est un serveur de "semi-prod" : le NAS est essentiellement utilisé 
> par l'équipe de R&D.
> Il s'occupe du stockage, de l'authentification (c'est lui le serveur 
> ldap), ...
> Donc si je casse tout, je ne me ferais que modérément engueuler et ça 
> leur servira
> de pretexte pour prendre une pause café :-)
> Mais je ne pense pas que le problème vienne de ça vu que 
> l'authentification et les permissions
> posix de base fonctionnent très bien.
>
>
> On 07/31/2014 10:58 AM, Arnaud Serrut wrote:
>
>     Cette configuration de nsswitch côté serveur est la même sur ta VM ?
>
>     Si c'est un serveur en production, je suis pas sûr que ce soit une
>     bonne idée de tester comme ça sans prévenir, mais modifier ce
>     fichier de configuration :
>     passwd:     compat ldap winbind
>     shadow:     compat ldap winbind
>     group:      compat ldap winbind
>
>     Peut résoudre le problème, mais il peut aussi y avoir des effets
>     de bord.
>
>     Cdt,
>
>
>
>     ------------------------------------------------------------------------
>     Date: Thu, 31 Jul 2014 10:44:08 +0200
>     From: jonathan.tremesaygues at menta.fr
>     <mailto:jonathan.tremesaygues at menta.fr>
>     To: arnaud.serrut at hotmail.fr <mailto:arnaud.serrut at hotmail.fr>
>     CC: frsag at frsag.org <mailto:frsag at frsag.org>
>     Subject: Re: [FRsAG] NFSv4 et ACL : problèmes
>
>     Les divers relancement de idmapd et autres rpc.* aussi bien sur le
>     serveur que
>     sur les clients n'ont rien changé.
>
>
>     Serveur :
>     [~] # cat /etc/nsswitch.conf
>     passwd:     compat winbind ldap
>     shadow:     compat winbind ldap
>     group:      compat winbind ldap
>
>     hosts:      files dns wins
>
>     bootparams: files
>
>     ethers:     files
>     netmasks:   files
>     networks:   files
>     protocols:  files
>     rpc:        files
>     services:   files
>
>     netgroup:   files
>
>     publickey:  files
>
>     automount:  files
>     aliases:    files
>
>
>
>     Client :
>     [jtremesay at hawk ~]$ cat /etc/nsswitch.conf
>     passwd:     files sss
>     shadow:     files sss
>     group:      files sss
>
>     hosts:      files mdns4_minimal [NOTFOUND=return] dns
>
>     bootparams: nisplus [NOTFOUND=return] files
>
>     ethers:     files
>     netmasks:   files
>     networks:   files
>     protocols:  files
>     rpc:        files
>     services:   files
>
>     netgroup:   files sss
>
>     publickey:  nisplus
>
>     automount:  files
>     aliases:    files nisplus
>
>
>     [root at hawk ~]# cat /etc/sssd/sssd.conf
>     [sssd]
>     config_file_version = 2
>     services = nss, pam
>     domains = LDAP
>
>     [nss]
>     filter_groups = root
>     filter_users = root
>     reconnection_retries = 3
>
>     [pam]
>     reconnection_retries = 3
>
>     [domain/default]
>     cache_credentials = False
>
>     [domain/LDAP]
>     id_provider = ldap
>     ldap_uri = ldap://whale
>     ldap_search_base = dc=menta,dc=fr
>     ldap_schema = rfc2307
>     ldap_tls_reqcert = allow
>     auth_provider = ldap
>     cache_credentials = true
>     enumerate = true
>
>
>     On 07/31/2014 10:33 AM, Arnaud Serrut wrote:
>
>         cat /etc/nsswitch.conf  ?
>         J'ai vu passer qu'un redémarrage du service idmapd corrige
>         parfois des trucs, on sait jamais...
>
>
>
>         > Date: Thu, 31 Jul 2014 10:15:46 +0200
>         > From: jonathan.tremesaygues at menta.fr
>         <mailto:jonathan.tremesaygues at menta.fr>
>         > To: frsag at ww7.be <mailto:frsag at ww7.be>
>         > CC: frsag at frsag.org <mailto:frsag at frsag.org>
>         > Subject: Re: [FRsAG] NFSv4 et ACL : problèmes
>         >
>         > Bonjour,
>         >
>         > Selinux est désactivé sur sl65 (c'est une VM destinée à
>         subir les
>         > expériences
>         > douloureuses nécessaire à mon apprentissage de sysadmin,
>         osef de la
>         > sécurité),
>         > donc je ne pense pas qu'il soit en cause.
>         > Sur les "vrais" machines où selinux est activé, j'ai rien vu de
>         > particulier dans les logs.
>         >
>         > Cordialement,
>         > Jonathan
>         >
>         >
>         > On 07/31/2014 10:06 AM, neo futur wrote:
>         > > vous avez regarde les logs kernel ? y aurai pas un selinux
>         ou autre
>         > > rbac qui foutrai sa zone ?
>         > >
>         > > 2014-07-31 3:56 GMT-04:00 Jean Milot
>         <milot.jean at gmail.com> <mailto:milot.jean at gmail.com>:
>         > >> Bonjour,
>         > >>
>         > >> As tu essayé de forcer la version sur le serveur nfs?
>         > >>
>         > >> Cordialement
>         > >>
>         > >> Jean
>         > >>
>         > >> Le 31 juil. 2014 09:52, "Jonathan Tremesaygues"
>         > >> <jonathan.tremesaygues at menta.fr>
>         <mailto:jonathan.tremesaygues at menta.fr> a écrit :
>         > >>
>         > >>> Bonjour,
>         > >>>
>         > >>> Ne marche pas non plus en NFSv3 :-/
>         > >>>
>         > >>>
>         > >>> Montage de l'export de test en nfs3 :
>         > >>> [root at sl65 mnt]# mount -o vers=3,acl
>         whale:/share/MD0_DATA/test whale/
>         > >>> [root at sl65 mnt]# nfsstat -m
>         > >>> /mnt/whale from whale:/share/MD0_DATA/test
>         > >>> Flags:
>         > >>>
>         rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,mountaddr=192.168.10.150,mountvers=3,mountport=58340,mountproto=udp,local_lock=none,addr=192.168.10.150
>         > >>>
>         > >>>
>         > >>> Vérification de la présence des ACL :
>         > >>> [root at sl65 mnt]# ll
>         > >>> total 8
>         > >>> drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale
>         > >>> [root at sl65 mnt]# getfacl whale
>         > >>> # file: whale
>         > >>> # owner: root
>         > >>> # group: root
>         > >>> user::rwx
>         > >>> user:lrouge:rwx
>         > >>> user:jtremesay:rwx
>         > >>> user:nfsnobody:---
>         > >>> group::rwx
>         > >>> mask::rwx
>         > >>> other::rwx
>         > >>> default:user::rwx
>         > >>> default:user:lrouge:rwx
>         > >>> default:user:jtremesay:rwx
>         > >>> default:user:nfsnobody:---
>         > >>> default:group::rwx
>         > >>> default:mask::rwx
>         > >>> default:other::---
>         > >>>
>         > >>>
>         > >>> Tentative d'accès au dossier :
>         > >>> [jtremesay at sl65 mnt]$ ls whale/
>         > >>> ls: cannot open directory whale/: Permission denied
>         > >>>
>         > >>>
>         > >>> Cordialement
>         > >>> Jonathan
>         > >>>
>         > >>>
>         > >>>
>         > >>>
>         > >>> On 07/30/2014 06:15 PM, Jean Milot wrote:
>         > >>>
>         > >>> Bonjour,
>         > >>>
>         > >>> Moi, j'ai abandonné NFSv4. Je force l'utilisation de la
>         version 3 pour
>         > >>> utiliser les ACLs.
>         > >>>
>         > >>> Cordialement,
>         > >>>
>         > >>> Jean
>         > >>>
>         > >>>
>         > >>>
>         > >>> Le 30 juillet 2014 16:40, Jonathan Tremesaygues
>         > >>> <jonathan.tremesaygues at menta.fr>
>         <mailto:jonathan.tremesaygues at menta.fr> a écrit :
>         > >>>> Bonjour la liste,
>         > >>>>
>         > >>>> Nous essayons désespérément de faire fonctionner les
>         ACL sur du partage
>         > >>>> réseau
>         > >>>> NSFv4. Le serveur de partage est un NAS QNAP TS-879-PRO
>         tournant sous un
>         > >>>> linux
>         > >>>> custom et les clients sont essentiellement des
>         Scientific Linux
>         > >>>> (RHEL-like)
>         > >>>> 6.5. Les comptes des utilisateurs sont stockés dans un
>         LDAP.
>         > >>>>
>         > >>>> ########################
>         > >>>> # Configuration du serveur (whale) : #
>         > >>>> ########################
>         > >>>> [~] # cat /etc/idmapd.conf
>         > >>>> [General]
>         > >>>> Verbosity = 9
>         > >>>> Pipefs-Directory = /var/lib/nfs/rpc_pipefs
>         > >>>> Domain = menta.fr
>         > >>>>
>         > >>>> [Mapping]
>         > >>>> Nobody-User = guest
>         > >>>> Nobody-Group = guest
>         > >>>>
>         > >>>> [Translation]
>         > >>>> Method = nsswitch
>         > >>>>
>         > >>>>
>         > >>>> [~] # cat /etc/exports
>         > >>>> "/share/NFS"
>         > >>>>
>         *(no_subtree_check,no_root_squash,insecure,fsid=0,subtree_check,acl,sec=sys)
>         > >>>> "/share/NFS/shared"
>         > >>>>
>         192.168.10.0/255.255.254.0(rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys)
>         > >>>> "/share/NFS/test"
>         > >>>>
>         192.168.10.0/255.255.254.0(rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys)
>         > >>>>
>         > >>>>
>         > >>>> [~] # cat
>         /sys/module/nfsd/parameters/nfs4_disable_idmapping
>         > >>>> N
>         > >>>>
>         > >>>>
>         > >>>> [~] # ll /share/NFS/
>         > >>>> drwxr-xr-x 19 root root 1.0k Jul 29 10:16 ./
>         > >>>> drwxr-xr-x 32 root root 1.0k Jul 29 14:34 ../
>         > >>>> drwxrwxrwx 12 root shared 4.0k Jul 17 15:00 shared/
>         > >>>> drwxrwx--- 2 root root 4.0k Jul 22 15:44 test/
>         > >>>>
>         > >>>>
>         > >>>> [~] # getfacl /share/NFS/test
>         > >>>> getfacl: Removing leading '/' from absolute path names
>         > >>>> # file: share/NFS/test
>         > >>>> # owner: root
>         > >>>> # group: root
>         > >>>> user::rwx
>         > >>>> user:jtremesay:rwx
>         > >>>> group::rwx
>         > >>>> mask::rwx
>         > >>>> other::---
>         > >>>> default:user::rwx
>         > >>>> default:group::rwx
>         > >>>> default:mask::rwx
>         > >>>> default:other::---
>         > >>>>
>         > >>>>
>         > >>>>
>         > >>>> ###################
>         > >>>> # Configuration d'un client : #
>         > >>>> ###################
>         > >>>> [jtremesay at hawk ~]$ cat /etc/idmapd.conf
>         > >>>> [General]
>         > >>>> Verbosity = 9
>         > >>>> Pipefs-Directory = /var/lib/nfs/rpc_pipefs
>         > >>>> Domain = menta.fr
>         > >>>>
>         > >>>> [Mapping]
>         > >>>> Nobody-User = nobody
>         > >>>> Nobody-Group = nobody
>         > >>>>
>         > >>>> [Translation]
>         > >>>> Method = nsswitch
>         > >>>>
>         > >>>>
>         > >>>> [jtremesay at hawk ~]$ mount | grep whale
>         > >>>> whale:/ on /mnt/whale type nfs
>         > >>>> (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
>         > >>>>
>         > >>>>
>         > >>>> [jtremesay at hawk ~]$ nfsstat -m
>         > >>>> /mnt/whale from whale:/
>         > >>>> Flags:
>         > >>>>
>         rw,relatime,vers=4,rsize=32768,wsize=32768,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.10.121,minorversion=0,local_lock=none,addr=192.168.10.150
>         > >>>>
>         > >>>>
>         > >>>> [jtremesay at hawk ~]$ ll /mnt/whale/
>         > >>>> total 134
>         > >>>> drwxr-xr-x. 19 root root 1024 Jul 29 10:16 .
>         > >>>> drwxr-xr-x. 5 root root 4096 Jul 29 10:46 ..
>         > >>>> drwxrwxrwx. 12 root shared 4096 Jul 17 15:00 shared
>         > >>>> drwxrwx---. 2 root root 4096 Jul 22 15:44 test
>         > >>>>
>         > >>>>
>         > >>>> [jtremesay at hawk ~]$ nfs4_getfacl /mnt/whale/test/
>         > >>>> A::OWNER@:rwaDxtTcCy
>         > >>>> A::jtremesay at menta.fr:rwaDxtcy
>         <mailto:A::jtremesay at menta.fr:rwaDxtcy>
>         > >>>> A::GROUP@:rwaDxtcy
>         > >>>> A::EVERYONE@:tcy
>         > >>>> A:fdi:OWNER@:rwaDxtTcCy
>         > >>>> A:fdi:GROUP@:rwaDxtcy
>         > >>>> A:fdi:EVERYONE@:tcy
>         > >>>>
>         > >>>>
>         > >>>> [jtremesay at hawk ~]$ ll /mnt/whale/test/
>         > >>>> ls: cannot open directory /mnt/whale/test/: Permission
>         denied
>         > >>>>
>         > >>>>
>         > >>>> Lorsque que j'utilise la même configuration (mêmes réglages
>         > >>>> d'idmapd.conf,
>         > >>>> mêmes exports, mêmes ACL) depuis un serveur sous
>         Scientific Linux, ça
>         > >>>> fonctionne : seul moi et root peuvent accéder au
>         dossier "test".
>         > >>>> Donc à priori le problème viendrait du QNAP mais je
>         vois pas trop ce que
>         > >>>> j'ai pu oublier de modifier ou vérifier.
>         > >>>>
>         > >>>> Si quelqu'un a une idée... Merci d'avance
>         > >>>>
>         > >>>>
>         > >>>> Cordialement,
>         > >>>> Jonathan Tremesaygues
>         > >>>> _______________________________________________
>         > >>>> Liste de diffusion du FRsAG
>         > >>>> http://www.frsag.org/
>         > >>>
>         > >>>
>         > >>>
>         > >>> --
>         > >>> MILOT Jean
>         > >>> Tél. : 0659514624
>         > >>> milot.jean at gmail.com <mailto:milot.jean at gmail.com>
>         > >>>
>         > >>>
>         > >> _______________________________________________
>         > >> Liste de diffusion du FRsAG
>         > >> http://www.frsag.org/
>         > >>
>         >
>         > _______________________________________________
>         > Liste de diffusion du FRsAG
>         > http://www.frsag.org/
>
>
>

-------------- section suivante --------------
Une pièce jointe HTML a été nettoyée...
URL: <http://www.frsag.org/pipermail/frsag/attachments/20140731/62a1fd8f/attachment-0001.html>


Plus d'informations sur la liste de diffusion FRsAG