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.tremesayg...@menta.fr
To: arnaud.ser...@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.tremesayg...@menta.fr
To: arnaud.ser...@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.tremesayg...@menta.fr
> To: fr...@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.j...@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.tremesayg...@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.tremesayg...@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::jtreme...@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.j...@gmail.com
> >>>
> >>>
> >>
_______________________________________________
> >> Liste de diffusion du FRsAG
> >> http://www.frsag.org/
> >>
>
> _______________________________________________
> Liste de diffusion du FRsAG
> http://www.frsag.org/
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
