Bonjour,
Ne marche pas non plus en NFSv3 :-/
Montage de l'export de test en nfs3 : [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/ [root@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@sl65 mnt]# ll total 8 drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale [root@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@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@menta.fr mailto:jonathan.tremesaygues@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 <http://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) <http://192.168.10.0/255.255.254.0%28rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys%29> "/share/NFS/test" 192.168.10.0/255.255.254.0(rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys) <http://192.168.10.0/255.255.254.0%28rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys%29> [~] # 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@hawk ~]$ cat /etc/idmapd.conf [General] Verbosity = 9 Pipefs-Directory = /var/lib/nfs/rpc_pipefs Domain = menta.fr <http://menta.fr> [Mapping] Nobody-User = nobody Nobody-Group = nobody [Translation] Method = nsswitch [jtremesay@hawk ~]$ mount | grep whale whale:/ on /mnt/whale type nfs (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121) [jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ A::OWNER@:rwaDxtTcCy A::jtremesay@menta.fr:rwaDxtcy A::GROUP@:rwaDxtcy A::EVERYONE@:tcy A:fdi:OWNER@:rwaDxtTcCy A:fdi:GROUP@:rwaDxtcy A:fdi:EVERYONE@:tcy [jtremesay@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@gmail.com mailto:milot.jean@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@menta.fr> a écrit :
Bonjour,
Ne marche pas non plus en NFSv3 :-/
Montage de l'export de test en nfs3 : [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/ [root@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@sl65 mnt]# ll total 8 drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale [root@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@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@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) http://192.168.10.0/255.255.254.0%28rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys%29 "/share/NFS/test" 192.168.10.0/255.255.254.0(rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys) http://192.168.10.0/255.255.254.0%28rw,nohide,async,no_root_squash,insecure,subtree_check,acl,sec=sys%29
[~] # 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@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@hawk ~]$ mount | grep whale whale:/ on /mnt/whale type nfs (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
[jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ A::OWNER@:rwaDxtTcCy A::jtremesay@menta.fr:rwaDxtcy A::GROUP@:rwaDxtcy A::EVERYONE@:tcy A:fdi:OWNER@:rwaDxtTcCy A:fdi:GROUP@:rwaDxtcy A:fdi:EVERYONE@:tcy
[jtremesay@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@gmail.com
Bonjour,
Les utilisateurs que tu utilises pour les ACL sont-ils bien reconnus côté serveur ? J'ai cru comprendre que tu utilisais un LDAP pour cela, si tu fais un : $> id jtremesay du côté du serveur, cela remonte bien quelque chose ?
Cdt, Arnaud
Date: Thu, 31 Jul 2014 09:56:24 +0200 From: milot.jean@gmail.com To: jonathan.tremesaygues@menta.fr CC: frsag@frsag.org Subject: Re: [FRsAG] NFSv4 et ACL : problèmes
Bonjour, As tu essayé de forcer la version sur le serveur nfs? Cordialement Jean Le 31 juil. 2014 09:52, "Jonathan Tremesaygues" jonathan.tremesaygues@menta.fr a écrit :
Bonjour,
Ne marche pas non plus en NFSv3 :-/
Montage de l'export de test en nfs3 :
[root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/
[root@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@sl65 mnt]# ll
total 8
drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale
[root@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@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@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@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@hawk ~]$ mount | grep whale
whale:/ on /mnt/whale type nfs (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
[jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/
A::OWNER@:rwaDxtTcCy
A::jtremesay@menta.fr:rwaDxtcy
A::GROUP@:rwaDxtcy
A::EVERYONE@:tcy
A:fdi:OWNER@:rwaDxtTcCy
A:fdi:GROUP@:rwaDxtcy
A:fdi:EVERYONE@:tcy
[jtremesay@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
--
MILOT Jean
Tél. : 0659514624
milot.jean@gmail.com
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
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@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@menta.fr a écrit :
Bonjour,
Ne marche pas non plus en NFSv3 :-/
Montage de l'export de test en nfs3 : [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/ [root@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@sl65 mnt]# ll total 8 drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale [root@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@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@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@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@hawk ~]$ mount | grep whale whale:/ on /mnt/whale type nfs (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
[jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ A::OWNER@:rwaDxtTcCy A::jtremesay@menta.fr:rwaDxtcy A::GROUP@:rwaDxtcy A::EVERYONE@:tcy A:fdi:OWNER@:rwaDxtTcCy A:fdi:GROUP@:rwaDxtcy A:fdi:EVERYONE@:tcy
[jtremesay@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@gmail.com
Liste de diffusion du FRsAG http://www.frsag.org/
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@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@menta.fr a écrit :
Bonjour,
Ne marche pas non plus en NFSv3 :-/
Montage de l'export de test en nfs3 : [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/ [root@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@sl65 mnt]# ll total 8 drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale [root@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@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@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@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@hawk ~]$ mount | grep whale whale:/ on /mnt/whale type nfs (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
[jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ A::OWNER@:rwaDxtTcCy A::jtremesay@menta.fr:rwaDxtcy A::GROUP@:rwaDxtcy A::EVERYONE@:tcy A:fdi:OWNER@:rwaDxtTcCy A:fdi:GROUP@:rwaDxtcy A:fdi:EVERYONE@:tcy
[jtremesay@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@gmail.com
Liste de diffusion du FRsAG http://www.frsag.org/
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@menta.fr To: frsag@ww7.be CC: frsag@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@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@menta.fr a écrit :
Bonjour,
Ne marche pas non plus en NFSv3 :-/
Montage de l'export de test en nfs3 : [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/ [root@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@sl65 mnt]# ll total 8 drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale [root@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@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@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@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@hawk ~]$ mount | grep whale whale:/ on /mnt/whale type nfs (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
[jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ A::OWNER@:rwaDxtTcCy A::jtremesay@menta.fr:rwaDxtcy A::GROUP@:rwaDxtcy A::EVERYONE@:tcy A:fdi:OWNER@:rwaDxtTcCy A:fdi:GROUP@:rwaDxtcy A:fdi:EVERYONE@:tcy
[jtremesay@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@gmail.com
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
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@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@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@menta.fr To: frsag@ww7.be CC: frsag@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@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@menta.fr a écrit :
Bonjour,
Ne marche pas non plus en NFSv3 :-/
Montage de l'export de test en nfs3 : [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test
whale/
[root@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@sl65 mnt]# ll total 8 drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale [root@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@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@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@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@hawk ~]$ mount | grep whale whale:/ on /mnt/whale type nfs (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
[jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ A::OWNER@:rwaDxtTcCy A::jtremesay@menta.fr:rwaDxtcy A::GROUP@:rwaDxtcy A::EVERYONE@:tcy A:fdi:OWNER@:rwaDxtTcCy A:fdi:GROUP@:rwaDxtcy A:fdi:EVERYONE@:tcy
[jtremesay@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@gmail.com
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
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@menta.fr To: arnaud.serrut@hotmail.fr CC: frsag@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@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@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@menta.fr
> To: frsag@ww7.be
> CC: frsag@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@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@menta.fr a écrit :
> >>
> >>> Bonjour,
> >>>
> >>> Ne marche pas non plus en NFSv3 :-/
> >>>
> >>>
> >>> Montage de l'export de test en nfs3 :
> >>> [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/
> >>> [root@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@sl65 mnt]# ll
> >>> total 8
> >>> drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale
> >>> [root@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@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@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@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@hawk ~]$ mount | grep whale
> >>>> whale:/ on /mnt/whale type nfs
> >>>> (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
> >>>>
> >>>>
> >>>> [jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/
> >>>> A::OWNER@:rwaDxtTcCy
> >>>> A::jtremesay@menta.fr:rwaDxtcy
> >>>> A::GROUP@:rwaDxtcy
> >>>> A::EVERYONE@:tcy
> >>>> A:fdi:OWNER@:rwaDxtTcCy
> >>>> A:fdi:GROUP@:rwaDxtcy
> >>>> A:fdi:EVERYONE@:tcy
> >>>>
> >>>>
> >>>> [jtremesay@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@gmail.com
> >>>
> >>>
> >> _______________________________________________
> >> Liste de diffusion du FRsAG
> >>
>
> _______________________________________________
> Liste de diffusion du FRsAG
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@menta.fr To: arnaud.serrut@hotmail.fr CC: frsag@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@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@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@menta.fr <mailto:jonathan.tremesaygues@menta.fr> > To: frsag@ww7.be <mailto:frsag@ww7.be> > CC: frsag@frsag.org <mailto:frsag@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@gmail.com> <mailto:milot.jean@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@menta.fr> <mailto:jonathan.tremesaygues@menta.fr> a écrit : > >> > >>> Bonjour, > >>> > >>> Ne marche pas non plus en NFSv3 :-/ > >>> > >>> > >>> Montage de l'export de test en nfs3 : > >>> [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/ > >>> [root@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@sl65 mnt]# ll > >>> total 8 > >>> drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale > >>> [root@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@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@menta.fr> <mailto:jonathan.tremesaygues@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@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@hawk ~]$ mount | grep whale > >>>> whale:/ on /mnt/whale type nfs > >>>> (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121) > >>>> > >>>> > >>>> [jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ > >>>> A::OWNER@:rwaDxtTcCy > >>>> A::jtremesay@menta.fr:rwaDxtcy <mailto:A::jtremesay@menta.fr:rwaDxtcy> > >>>> A::GROUP@:rwaDxtcy > >>>> A::EVERYONE@:tcy > >>>> A:fdi:OWNER@:rwaDxtTcCy > >>>> A:fdi:GROUP@:rwaDxtcy > >>>> A:fdi:EVERYONE@:tcy > >>>> > >>>> > >>>> [jtremesay@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@gmail.com <mailto:milot.jean@gmail.com> > >>> > >>> > >> _______________________________________________ > >> Liste de diffusion du FRsAG > >> http://www.frsag.org/ > >> > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/
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@menta.fr To: arnaud.serrut@hotmail.fr CC: frsag@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@menta.fr
To: arnaud.serrut@hotmail.fr
CC: frsag@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@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@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@menta.fr
> To: frsag@ww7.be
> CC: frsag@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@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@menta.fr a écrit :
> >>
> >>> Bonjour,
> >>>
> >>> Ne marche pas non plus en NFSv3 :-/
> >>>
> >>>
> >>> Montage de l'export de test en nfs3 :
> >>> [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/
> >>> [root@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@sl65 mnt]# ll
> >>> total 8
> >>> drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale
> >>> [root@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@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@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@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@hawk ~]$ mount | grep whale
> >>>> whale:/ on /mnt/whale type nfs
> >>>> (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121)
> >>>>
> >>>>
> >>>> [jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/
> >>>> A::OWNER@:rwaDxtTcCy
> >>>> A::jtremesay@menta.fr:rwaDxtcy
> >>>> A::GROUP@:rwaDxtcy
> >>>> A::EVERYONE@:tcy
> >>>> A:fdi:OWNER@:rwaDxtTcCy
> >>>> A:fdi:GROUP@:rwaDxtcy
> >>>> A:fdi:EVERYONE@:tcy
> >>>>
> >>>>
> >>>> [jtremesay@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@gmail.com
> >>>
> >>>
> >> _______________________________________________
> >> Liste de diffusion du FRsAG
> >>
>
> _______________________________________________
> Liste de diffusion du FRsAG
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@menta.fr To: arnaud.serrut@hotmail.fr CC: frsag@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@menta.fr <mailto:jonathan.tremesaygues@menta.fr> To: arnaud.serrut@hotmail.fr <mailto:arnaud.serrut@hotmail.fr> CC: frsag@frsag.org <mailto:frsag@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@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@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@menta.fr <mailto:jonathan.tremesaygues@menta.fr> > To: frsag@ww7.be <mailto:frsag@ww7.be> > CC: frsag@frsag.org <mailto:frsag@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@gmail.com> <mailto:milot.jean@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@menta.fr> <mailto:jonathan.tremesaygues@menta.fr> a écrit : > >> > >>> Bonjour, > >>> > >>> Ne marche pas non plus en NFSv3 :-/ > >>> > >>> > >>> Montage de l'export de test en nfs3 : > >>> [root@sl65 mnt]# mount -o vers=3,acl whale:/share/MD0_DATA/test whale/ > >>> [root@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@sl65 mnt]# ll > >>> total 8 > >>> drwxrwx---+ 3 root root 4096 Jul 31 09:14 whale > >>> [root@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@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@menta.fr> <mailto:jonathan.tremesaygues@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@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@hawk ~]$ mount | grep whale > >>>> whale:/ on /mnt/whale type nfs > >>>> (rw,vers=4,addr=192.168.10.150,clientaddr=192.168.10.121) > >>>> > >>>> > >>>> [jtremesay@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@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@hawk ~]$ nfs4_getfacl /mnt/whale/test/ > >>>> A::OWNER@:rwaDxtTcCy > >>>> A::jtremesay@menta.fr:rwaDxtcy <mailto:A::jtremesay@menta.fr:rwaDxtcy> > >>>> A::GROUP@:rwaDxtcy > >>>> A::EVERYONE@:tcy > >>>> A:fdi:OWNER@:rwaDxtTcCy > >>>> A:fdi:GROUP@:rwaDxtcy > >>>> A:fdi:EVERYONE@:tcy > >>>> > >>>> > >>>> [jtremesay@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@gmail.com <mailto:milot.jean@gmail.com> > >>> > >>> > >> _______________________________________________ > >> Liste de diffusion du FRsAG > >> http://www.frsag.org/ > >> > > _______________________________________________ > Liste de diffusion du FRsAG > http://www.frsag.org/
Le 2014-07-31 16:06, Jonathan Tremesaygues a écrit :
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
Plop,
et ton kernel ? Par défaut il me semble désormais que le support nfs serveur est ds le kernel... Sais-tu quelle version de kernel tu as ? Les options relatives au nfs qui sont activées ? (grep qui va bien /proc/zconfig.gz si tu as)
Visiblement il y a plusieurs modules relatifs à nfs : /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common/nfs_acl.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs_layout_nfsv41_files.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd/nfsd.ko
Cdlt,
JYL
On 07/31/2014 05:06 PM, jean-yves@lenhof.eu.org wrote:
Le 2014-07-31 16:06, Jonathan Tremesaygues a écrit :
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
Plop,
et ton kernel ? Par défaut il me semble désormais que le support nfs serveur est ds le kernel... Sais-tu quelle version de kernel tu as ? Les options relatives au nfs qui sont activées ? (grep qui va bien /proc/zconfig.gz si tu as)
Visiblement il y a plusieurs modules relatifs à nfs : /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common/nfs_acl.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs_layout_nfsv41_files.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd/nfsd.ko
Cdlt,
JYL _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
C'est un peu le bordel mais d'après ce que j'ai compris, il y a une partie dans le kernel et une partie en userland. La partie kernel est l'implémentation de l'interface VFS (Virtual FileSystem) pour le client (nfs.ko) et pour le serveur (nfsd.ko). Les outils en espace utilisateur (rpc.*, libnfsidmap, ...) s'occupent de la communication entre les machines, la gestion des utilisateurs (idmapping), ect...
Kernel : [/] # uname -a Linux whale 3.4.6 #1 SMP Thu Jun 12 17:23:50 CST 2014 x86_64 unknown
Config extraite à grand coup de grep NFS : CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y CONFIG_NFS_FSCACHE=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFSV4_FS_RICHACL is not set CONFIG_NFSD=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_V4_COMMON=y CONFIG_NFS_COMMON=y
Donc NFSv4 et ACL sont bien activés. Confirmé par le fait que mount -o vers4 fonctionne et que nfs4_getfacl côté client récupère bien (modulo traduction) ce qui a été mis en place côté serveur via setfacl.
Cordialement, Jonathan
tente quand meme un tail -f /var/log/kern.log ( chemin different selon les distributions utilisees ) au meme moment ou tu essaye de faire tes manips, peut etre que le kernel te dira un truc utile
voire meme tail -f /var/log/*log d autres logs pourraient etre utiles peut etre
2014-07-31 11:27 GMT-04:00 Jonathan Tremesaygues jonathan.tremesaygues@menta.fr:
On 07/31/2014 05:06 PM, jean-yves@lenhof.eu.org wrote:
Le 2014-07-31 16:06, Jonathan Tremesaygues a écrit :
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
Plop,
et ton kernel ? Par défaut il me semble désormais que le support nfs serveur est ds le kernel... Sais-tu quelle version de kernel tu as ? Les options relatives au nfs qui sont activées ? (grep qui va bien /proc/zconfig.gz si tu as)
Visiblement il y a plusieurs modules relatifs à nfs : /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common/nfs_acl.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs_layout_nfsv41_files.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd/nfsd.ko
Cdlt,
JYL _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
C'est un peu le bordel mais d'après ce que j'ai compris, il y a une partie dans le kernel et une partie en userland. La partie kernel est l'implémentation de l'interface VFS (Virtual FileSystem) pour le client (nfs.ko) et pour le serveur (nfsd.ko). Les outils en espace utilisateur (rpc.*, libnfsidmap, ...) s'occupent de la communication entre les machines, la gestion des utilisateurs (idmapping), ect...
Kernel : [/] # uname -a Linux whale 3.4.6 #1 SMP Thu Jun 12 17:23:50 CST 2014 x86_64 unknown
Config extraite à grand coup de grep NFS : CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y CONFIG_NFS_FSCACHE=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFSV4_FS_RICHACL is not set CONFIG_NFSD=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_V4_COMMON=y CONFIG_NFS_COMMON=y
Donc NFSv4 et ACL sont bien activés. Confirmé par le fait que mount -o vers4 fonctionne et que nfs4_getfacl côté client récupère bien (modulo traduction) ce qui a été mis en place côté serveur via setfacl.
Cordialement, Jonathan
Liste de diffusion du FRsAG http://www.frsag.org/
T'as VM ne serait pas un conteneur LXC par hasard? Car ça ne fonctionne pas "out of the box" avec.
2014-08-01 1:26 GMT+02:00 neo futur frsag@ww7.be:
tente quand meme un tail -f /var/log/kern.log ( chemin different selon les distributions utilisees ) au meme moment ou tu essaye de faire tes manips, peut etre que le kernel te dira un truc utile
voire meme tail -f /var/log/*log d autres logs pourraient etre utiles peut etre
2014-07-31 11:27 GMT-04:00 Jonathan Tremesaygues jonathan.tremesaygues@menta.fr:
On 07/31/2014 05:06 PM, jean-yves@lenhof.eu.org wrote:
Le 2014-07-31 16:06, Jonathan Tremesaygues a écrit :
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
Plop,
et ton kernel ? Par défaut il me semble désormais que le support nfs serveur est ds le kernel... Sais-tu quelle version de kernel tu as ? Les options relatives au nfs qui sont activées ? (grep qui va bien /proc/zconfig.gz si tu as)
Visiblement il y a plusieurs modules relatifs à nfs : /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common/nfs_acl.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs_layout_nfsv41_files.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd/nfsd.ko
Cdlt,
JYL _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
C'est un peu le bordel mais d'après ce que j'ai compris, il y a une
partie
dans le kernel et une partie en userland. La partie kernel est l'implémentation de l'interface VFS (Virtual FileSystem) pour le client (nfs.ko) et pour le serveur (nfsd.ko). Les outils en espace utilisateur (rpc.*, libnfsidmap, ...) s'occupent de
la
communication entre les machines, la gestion des utilisateurs
(idmapping),
ect...
Kernel : [/] # uname -a Linux whale 3.4.6 #1 SMP Thu Jun 12 17:23:50 CST 2014 x86_64 unknown
Config extraite à grand coup de grep NFS : CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y CONFIG_NFS_FSCACHE=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFSV4_FS_RICHACL is not set CONFIG_NFSD=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_V4_COMMON=y CONFIG_NFS_COMMON=y
Donc NFSv4 et ACL sont bien activés. Confirmé par le fait que mount -o vers4 fonctionne et que nfs4_getfacl
côté
client récupère bien (modulo traduction) ce qui a été mis en place côté serveur via setfacl.
Cordialement, Jonathan
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
On 15 août 2014 22:31:43 CEST, Alexandre PIERRET alexandre.pierret-frsag@loiklo.net wrote:
T'as VM ne serait pas un conteneur LXC par hasard? Car ça ne fonctionne pas "out of the box" avec.
2014-08-01 1:26 GMT+02:00 neo futur frsag@ww7.be:
tente quand meme un tail -f /var/log/kern.log ( chemin different selon les distributions utilisees ) au meme moment ou tu essaye de faire tes manips, peut
etre
que le kernel te dira un truc utile
voire meme tail -f /var/log/*log d autres logs pourraient etre utiles
peut
etre
2014-07-31 11:27 GMT-04:00 Jonathan Tremesaygues jonathan.tremesaygues@menta.fr:
On 07/31/2014 05:06 PM, jean-yves@lenhof.eu.org wrote:
Le 2014-07-31 16:06, Jonathan Tremesaygues a écrit :
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
Plop,
et ton kernel ? Par défaut il me semble désormais que le support nfs serveur est
ds le
kernel... Sais-tu quelle version de kernel tu as ? Les options relatives au nfs qui sont activées ? (grep qui va bien /proc/zconfig.gz si tu as)
Visiblement il y a plusieurs modules relatifs à nfs : /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common /lib/modules/3.2.0-4-amd64/kernel/fs/nfs_common/nfs_acl.ko /lib/modules/3.2.0-4-amd64/kernel/fs/nfs /lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs.ko
/lib/modules/3.2.0-4-amd64/kernel/fs/nfs/nfs_layout_nfsv41_files.ko
/lib/modules/3.2.0-4-amd64/kernel/fs/nfsd /lib/modules/3.2.0-4-amd64/kernel/fs/nfsd/nfsd.ko
Cdlt,
JYL _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
C'est un peu le bordel mais d'après ce que j'ai compris, il y a une
partie
dans le kernel et une partie en userland. La partie kernel est l'implémentation de l'interface VFS (Virtual FileSystem) pour le client (nfs.ko) et pour le serveur (nfsd.ko). Les outils en espace utilisateur (rpc.*, libnfsidmap, ...)
s'occupent de
la
communication entre les machines, la gestion des utilisateurs
(idmapping),
ect...
Kernel : [/] # uname -a Linux whale 3.4.6 #1 SMP Thu Jun 12 17:23:50 CST 2014 x86_64
unknown
Config extraite à grand coup de grep NFS : CONFIG_NFS_FS=y CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y # CONFIG_NFS_V4_1 is not set CONFIG_ROOT_NFS=y CONFIG_NFS_FSCACHE=y # CONFIG_NFS_USE_LEGACY_DNS is not set CONFIG_NFS_USE_KERNEL_DNS=y # CONFIG_NFSV4_FS_RICHACL is not set CONFIG_NFSD=y CONFIG_NFSD_V2_ACL=y CONFIG_NFSD_V3=y CONFIG_NFSD_V3_ACL=y CONFIG_NFSD_V4=y CONFIG_NFS_ACL_SUPPORT=y CONFIG_NFS_V4_COMMON=y CONFIG_NFS_COMMON=y
Donc NFSv4 et ACL sont bien activés. Confirmé par le fait que mount -o vers4 fonctionne et que
nfs4_getfacl
côté
client récupère bien (modulo traduction) ce qui a été mis en place
côté
serveur via setfacl.
Cordialement, Jonathan
Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Nope, c'était une machine virtuelle VirtualBox connecté au réseau en mode bridge.
Mais vous cassez pas la tête pour ça, on a abandonnés l'idée de mettre en place des ACL, et commencés à envisager de remplacer cette saleté de Qnap par un vrai Linux :-)
Bonjour,
Je suis à la recherche de rails serveur 1U DELL de type A4 => "RAIL TYPE A4 / KIT,RCKRL,2/4PST,1U,STAT,SFF"
Quelqu'un à une idée d'un vendeur pour de l'occasion ou même du neuf à titre de comparaison ?
Merci par avance et bonne journée.
Bonjour,
As-tu tenté Curvature (ancien NHR). Ils vendent du matériel Dell d'occasion. https://www.curvature.com/fr
Ebay sinon ?
Bonne journée.
Le 20/08/2014 10:42, Sébastien 65 a écrit :
Bonjour,
Je suis à la recherche de rails serveur 1U DELL de type A4 => "RAIL TYPE A4 / KIT,RCKRL,2/4PST,1U,STAT,SFF"
Quelqu'un à une idée d'un vendeur pour de l'occasion ou même du neuf à titre de comparaison ?
Merci par avance et bonne journée.
as tu essayé https://www.servershop24.de/en/components/rackmount-kits/
Le 20/08/2014 10:56, David B. a écrit :
Bonjour,
As-tu tenté Curvature (ancien NHR). Ils vendent du matériel Dell d'occasion. https://www.curvature.com/fr
Ebay sinon ?
Bonne journée.
Le 20/08/2014 10:42, Sébastien 65 a écrit :
Bonjour,
Je suis à la recherche de rails serveur 1U DELL de type A4 => "RAIL TYPE A4 / KIT,RCKRL,2/4PST,1U,STAT,SFF"
Quelqu'un à une idée d'un vendeur pour de l'occasion ou même du neuf à titre de comparaison ?
Merci par avance et bonne journée.
Liste de diffusion du FRsAG http://www.frsag.org/
Salut à tous,
Peut-être ici :
http://www.hardware-attitude.com/
Bonne journée :-)
________________________________
Date: Wed, 20 Aug 2014 11:04:02 +0200 From: hugues@max4mail.com To: frsag@frsag.org Subject: Re: [FRsAG] [SPAM] [MessageScore][alltestmode] Re: Cherche rails serveur 1U DELL
as tu essayé https://www.servershop24.de/en/components/rackmount-kits/
Le 20/08/2014 10:56, David B. a écrit : Bonjour,
As-tu tenté Curvature (ancien NHR). Ils vendent du matériel Dell d'occasion. https://www.curvature.com/fr
Ebay sinon ?
Bonne journée.
Le 20/08/2014 10:42, Sébastien 65 a écrit : Bonjour,
Je suis à la recherche de rails serveur 1U DELL de type A4 => "RAIL TYPE A4 / KIT,RCKRL,2/4PST,1U,STAT,SFF"
Quelqu'un à une idée d'un vendeur pour de l'occasion ou même du neuf à titre de comparaison ?
Merci par avance et bonne journée.
Liste de diffusion du FRsAG http://www.frsag.org/
-- Salutations
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour,
Merci à tous pour les infos, je vais regarder ça !
Bonne journée.