Change in ffilz/nfs-ganesha[next]: SAL: add EXPORT_OPTION_SECLABEL_SET
by GerritHub
From Jeff Layton <jlayton(a)redhat.com>:
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426933
Change subject: SAL: add EXPORT_OPTION_SECLABEL_SET
......................................................................
SAL: add EXPORT_OPTION_SECLABEL_SET
Add a new generic export option to enable security labels on a
per-export basis. The default is to have them disabled.
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
Change-Id: If75ed7722efedb1a296cb197c1a152e0fc1d295b
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/include/nfs_exports.h
M src/support/exports.c
2 files changed, 5 insertions(+), 0 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/33/426933/1
--
To view, visit https://review.gerrithub.io/426933
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: If75ed7722efedb1a296cb197c1a152e0fc1d295b
Gerrit-Change-Number: 426933
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
5 years, 7 months
Change in ffilz/nfs-ganesha[next]: mdcache: do readdir cb supercall using entry->attrs
by GerritHub
From Jeff Layton <jlayton(a)redhat.com>:
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426925
Change subject: mdcache: do readdir cb supercall using entry->attrs
......................................................................
mdcache: do readdir cb supercall using entry->attrs
mdc_readdir_uncached_cb will update the mdcache first, and then do the
supercall with the old attributes. When updating the cache though, we
might "steal" some of the pointers in "attrs", which could make us
populate the reply from an incomplete set of attrs. Use the attrs in
the mdcache instead.
Change-Id: If2e3b7e9de1f496c96ad2cb29552318e33626c61
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
1 file changed, 3 insertions(+), 3 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/25/426925/1
--
To view, visit https://review.gerrithub.io/426925
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: If2e3b7e9de1f496c96ad2cb29552318e33626c61
Gerrit-Change-Number: 426925
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
5 years, 7 months
Nfs-ganesha with openldap and kerberos
by Durgaprasad Dandi
Hello,
These are my system configuration.
CentOS Linux release 7.3.1611
Linux 3.10.0-514.el7.x86_64 kernel
nfs-ganesha-2.3.2-1.el7.x86_64
libnfsidmap-0.25-19.el7.x86_64
I am trying to use nfs-ganesha with openldap and kerberos.
In the client, I am using autofs to mount the home directories of the users.
Logging as a user in the client is failing with following error
>>Could not chdir to home directory /home/demouser2: Permission denied
>>-bash: /home/demouser2/.bash_profile: Permission denied
Nfs-ganesha logs:
25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6]
nfs_req_creds :DISP :M_DBG :Mapping RPCSEC_GSS principal demouser2(a)DMS.COM
to uid/gid
25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6]
principal2uid :RW LOCK :F_DBG :Got read lock on 0x7f92c10e6380
(&idmapper_user_lock) at
/builddir/build/BUILD/nfs-ganesha-2.3.2/src/idmapper/idmapper.c:662
25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6]
principal2uid :RW LOCK :F_DBG :Unlocked 0x7f92c10e6380
(&idmapper_user_lock) at
/builddir/build/BUILD/nfs-ganesha-2.3.2/src/idmapper/idmapper.c:667
25/09/2018 06:54:34 : epoch 5ba9e1a1 : ganesha.nfsd-29533[work-6]
nfs_req_creds :ID MAPPER :WARN :Could not map principal demouser2(a)DMS.COM
to uid
If I am using nfs, everything is working properly. So why this issue is
only with nfs-ganesha? Am I doing something wrong in configuration?
nfs-ganesha configuration file : /etc/ganesha/ganesha.conf
NFSV4
{
IdmapConf = /etc/idmapd.conf;
Allow_Numeric_Owners = false;
}
EXPORT
{
# Export Id (mandatory, each EXPORT must have a unique Export_Id)
Export_Id = 77;
# Exported path (mandatory)
Path = /home;
# Pseudo Path (required for NFS v4)
Pseudo = /home;
# Required for access (default is None)
# Could use CLIENT blocks instead
Access_Type = RW;
SecType = sys, krb5;
# Exporting FSAL
FSAL {
Name = VFS;
}
CLIENT {
Clients = client;
Squash = No_root_squash;
}
NFS_KRB5
{
PrincipalName = "nfs" ;
KeytabPath = /etc/krb5.keytab ;
Active_krb5 = YES ;
}
}
Thanks,
Durga.
5 years, 7 months
Re: [Nfs-ganesha-devel] Issue with file locks after upgrade from 2.5.4 to 2.6.2
by Naresh Babu
Thanks for the response, Daniel. Ping to "::ffff:10.0.0.7" works fine. Do
you suspect anything else?
Thanks,
Naresh
On Tue, Sep 11, 2018 at 5:48 AM Daniel Gryniewicz <dang(a)redhat.com> wrote:
> My guess is that this is related to IPv6. IPv6 support in 2.5 was
> spotty, but that's been fixed since. It's clearly using the 4-in-6
> address (pretty common on a v6 enabled machine), and I don't believe it
> could have used that in 2.5, so that's seems the smoking gun.
>
> Does IPv6 work on your system? If you ping ::ffff:10.0.0.7 on that box,
> does it work? If the problem is IPv6, you may be able to work around it
> by preferring IPv4 to IPv6. This is done by adding this line to
> /etc/gai.conf:
>
> precedence ::ffff:0:0/96 100
>
> Daniel
>
> On 09/11/2018 03:42 AM, Naresh Babu wrote:
> > This list has been deprecated. Please subscribe to the new devel list at
> lists.nfs-ganesha.org.
> >
> >
> >
> > We have developed a custom FSAL on top of nfs-ganesha 2.5.4 version and
> > lock tests ran fine with that. But, after upgrading nfs-ganesha to
> > 2.6.2, lock tests are failing with the following errors:
> >
> > ganesha.nfsd-1419[svc_70] nsm_monitor :NLM :CRIT :Monitor
> > ::ffff:10.0.0.7 SM_MON failed (1)
> >
> > /var/log/messages:
> > Sep 11 07:26:27 mbclvm3 rpc.statd[1439]: SM_MON/SM_UNMON call from
> > non-local host ::1
> > Sep 11 07:26:27 mbclvm3 rpc.statd[1439]: STAT_FAIL to mbclvm3 for SM_MON
> > of ::ffff:10.0.0.7
> >
> > $ rpcinfo -p |grep "status\|lockmgr"
> > 100024 1 udp 46991 status
> > 100024 1 tcp 33715 status
> > 100021 4 udp 45075 nlockmgr
> > 100021 4 tcp 45075 nlockmgr
> >
> >
> >
> >
> > _______________________________________________
> > Nfs-ganesha-devel mailing list
> > Nfs-ganesha-devel(a)lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/nfs-ganesha-devel
> >
>
>
5 years, 7 months
Change in ffilz/nfs-ganesha[next]: FSAL_CEPH: open file as root for COMMIT purposes
by GerritHub
From Jeff Layton <jlayton(a)redhat.com>:
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426589
Change subject: FSAL_CEPH: open file as root for COMMIT purposes
......................................................................
FSAL_CEPH: open file as root for COMMIT purposes
Kenneth reported that he was seeing problems copying large, read
only files to a share as an unprivileged user. The final COMMIT
call would get back a permissions error.
Since we don't have a stateid to use as a hint, we have to use the
global fd to issue a commit. In many situations we won't have it
open for write already, so we need to perform an open. If the file
has gone r/o though, we can't do that with the creds sent in the
RPC.
Switch to using root creds for the when we're opening the file for
a COMMIT call. We check the permissions at the protocol layer already
and we're just using it to issue an fsync, so this should be safe.
Fixes: https://github.com/nfs-ganesha/nfs-ganesha/issues/349
Change-Id: I60fba7ff05b3a5210d34e25f591256c9a1d61949
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/FSAL/FSAL_CEPH/handle.c
1 file changed, 10 insertions(+), 2 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/89/426589/1
--
To view, visit https://review.gerrithub.io/426589
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I60fba7ff05b3a5210d34e25f591256c9a1d61949
Gerrit-Change-Number: 426589
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
5 years, 7 months
Change in ffilz/nfs-ganesha[next]: FSAL_MDCACHE: prevent double free on new raced entries
by GerritHub
From <fatih(a)gandi.net>:
fatih(a)gandi.net has uploaded this change for review. ( https://review.gerrithub.io/426583
Change subject: FSAL_MDCACHE: prevent double free on new raced entries
......................................................................
FSAL_MDCACHE: prevent double free on new raced entries
This is a partial revert of c55046feb786d69de8ba046e7cbd242479621b66.
The newly acquired entry is actually in the LRU at this point,
it is inserted in mdcache_alloc_handle.
We should put the ref once and let the reaper do the rest,
otherwise it may race with another thread (LRU thread/reaper).
Change-Id: Ia548c842b79958deb6b895a0249ec0bb4cde65d2
Signed-off-by: Fatih Acar <fatih.acar(a)gandi.net>
---
M src/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c
1 file changed, 1 insertion(+), 3 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/83/426583/1
--
To view, visit https://review.gerrithub.io/426583
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Ia548c842b79958deb6b895a0249ec0bb4cde65d2
Gerrit-Change-Number: 426583
Gerrit-PatchSet: 1
Gerrit-Owner: Anonymous Coward <fatih(a)gandi.net>
5 years, 7 months
Announce Push of V2.7.0.1
by Frank Filz
Branch next
Tag:V2.7.0.1
Release Highlights
* To handle open upgrade, attempt to open lock fd RDWR
* FSAL_CEPH: add flag to mask for setting atime/mtime to server time
* specfile: build with libasan support if it was specified during cmake
* ganesha-rados-grace: only create pool and db on "add"
* rpm: add lttng-tools-devel as BuildRequires to .spec file
* CMake - Find libraries on Debian
* FSAL GLUSTER: fix the result of SEEK2 according to RFC7862
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
Contents:
0fe4db2 Frank S. Filz V2.7.0.1
b4c0a4f Kinglong Mee FSAL GLUSTER: fix the result of SEEK2 according to
RFC7862
59fe3bd Daniel Gryniewicz CMake - Find libraries on Debian
4a11713 Ali Maredia rpm: add lttng-tools-devel as BuildRequires to .spec
file
93b47c6 Jeff Layton ganesha-rados-grace: only create pool and db on "add"
ee7bad6 Jeff Layton specfile: build with libasan support if it was specified
during cmake
4a12680 Zhu Shangzhong FSAL_CEPH: add flag to mask for setting atime/mtime
to server time
baa858b Frank S. Filz To handle open upgrade, attempt to open lock fd RDWR
5 years, 7 months
Change in ffilz/nfs-ganesha[next]: To handle open upgrade, attempt to open lock fd RDWR
by GerritHub
From Frank Filz <ffilzlnx(a)mindspring.com>:
Frank Filz has uploaded this change for review. ( https://review.gerrithub.io/426288
Change subject: To handle open upgrade, attempt to open lock fd RDWR
......................................................................
To handle open upgrade, attempt to open lock fd RDWR
If that fails, then open in the openstate mode if available.
Change-Id: I6c765b29d64d4d407feca99917ff0ec9b6516535
Signed-off-by: Frank S. Filz <ffilzlnx(a)mindspring.com>
---
M src/FSAL/commonlib.c
1 file changed, 21 insertions(+), 11 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/88/426288/1
--
To view, visit https://review.gerrithub.io/426288
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: I6c765b29d64d4d407feca99917ff0ec9b6516535
Gerrit-Change-Number: 426288
Gerrit-PatchSet: 1
Gerrit-Owner: Frank Filz <ffilzlnx(a)mindspring.com>
5 years, 7 months
Change in ffilz/nfs-ganesha[next]: ganesha-rados-grace: only create pool and db on "add"
by GerritHub
From Jeff Layton <jlayton(a)redhat.com>:
Jeff Layton has uploaded this change for review. ( https://review.gerrithub.io/426263
Change subject: ganesha-rados-grace: only create pool and db on "add"
......................................................................
ganesha-rados-grace: only create pool and db on "add"
The first thing we have to do with a new cluster is add members, so it
doesn't make sense to create the pool or db unless we're doing that.
Otherwise, the tool will create the pool and db, even if we're just
dumping the current status.
Also, clean up some unnecessary code duplication. We need at least one
nodeid for all commands except for "dump" so just check that after we
see if we're handling a dump command.
Change-Id: Id6f72384a0fb4ae3e7286cad71fa8b8fda90607f
Signed-off-by: Jeff Layton <jlayton(a)redhat.com>
---
M src/tools/ganesha-rados-grace.c
1 file changed, 40 insertions(+), 74 deletions(-)
git pull ssh://review.gerrithub.io:29418/ffilz/nfs-ganesha refs/changes/63/426263/1
--
To view, visit https://review.gerrithub.io/426263
To unsubscribe, or for help writing mail filters, visit https://review.gerrithub.io/settings
Gerrit-Project: ffilz/nfs-ganesha
Gerrit-Branch: next
Gerrit-MessageType: newchange
Gerrit-Change-Id: Id6f72384a0fb4ae3e7286cad71fa8b8fda90607f
Gerrit-Change-Number: 426263
Gerrit-PatchSet: 1
Gerrit-Owner: Jeff Layton <jlayton(a)redhat.com>
5 years, 7 months
Crash in mdcache_lru_cleanup_push()
by Sandeep Nashikkar
Ganesha Version: 2.5.1
Platform: Linux x86_64
I am seeing following issue while doing re-exporting the ganesha export (remove_export -> add_export)
The crash happens during add_export operation and there are some applications using the export while this is happening. We also implemented mechanism to stall the IOs when this operation is happening but it did not help.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000000530d27 in mdcache_lru_cleanup_push (entry=0x7f3078007f50)
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:935
935 LRU_DQ_SAFE(lru, q);
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-12.el7.x86_64 dbus-libs-1.10.24-7.el7.x86_64 elfutils-libelf-0.160-1.el7.x86_64 elfutils-libs-0.160-1.el7.x86_64 gssproxy-0.3.0-10.el7.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-19.el7.x86_64 libacl-2.2.51-14.el7.x86_64 libattr-2.4.46-13.el7.x86_64 libblkid-2.23.2-21.el7.x86_64 libcap-2.22-8.el7.x86_64 libcom_err-1.42.9-12.el7_5.x86_64 libgcrypt-1.5.3-12.el7.x86_64 libgpg-error-1.12-3.el7.x86_64 libnfsidmap-0.25-11.el7.x86_64 libselinux-2.5-12.el7.x86_64 libuuid-2.23.2-21.el7.x86_64 lz4-1.7.5-2.el7.x86_64 pcre-8.32-17.el7.x86_64 systemd-libs-219-57.el7.x86_64 xz-libs-5.1.2-9alpha.el7.x86_64 zlib-1.2.7-13.el7.x86_64
(gdb) bt
#0 0x0000000000530d27 in mdcache_lru_cleanup_push (entry=0x7f3078007f50)
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_lru.c:935
#1 0x000000000054a0fc in _mdcache_kill_entry (entry=0x7f3078007f50,
file=0x5a0970 "/root/rpmbuild/BUILD/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c", line=218,
function=0x5a2120 <__func__.23400> "mdcache_alloc_handle")
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:3310
#2 0x00000000005419de in mdcache_alloc_handle (export=0x7f30bc05d070, sub_handle=0x7f3078007c20, fs=0x0)
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:218
#3 0x00000000005430ea in mdcache_new_entry (export=0x7f30bc05d070, sub_handle=0x7f3078007c20, attrs_in=0x7f31287c6670, attrs_out=0x0, new_directory=false,
entry=0x7f31287c67e8, state=0x0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:590
#4 0x0000000000544093 in mdcache_locate_host (fh_desc=0x7f31287c6c60, export=0x7f30bc05d070, entry=0x7f31287c67e8, attrs_out=0x0)
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:998
#5 0x000000000053d1b3 in mdcache_create_handle (exp_hdl=0x7f30bc05d070, fh_desc=0x7f31287c6c60, handle=0x7f31287c6c58, attrs_out=0x0)
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_handle.c:1902
#6 0x000000000047729d in nfs4_mds_putfh (data=0x7f31287c6d60) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/Protocols/NFS/nfs4_op_putfh.c:211
#7 0x0000000000477486 in nfs4_op_putfh (op=0x7f30a00424c0, data=0x7f31287c6d60, resp=0x7f3078000d30)
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/Protocols/NFS/nfs4_op_putfh.c:281
#8 0x000000000045f670 in nfs4_Compound (arg=0x7f30a00010f0, req=0x7f30a00008e8, res=0x7f3078001fa0)
at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/Protocols/NFS/nfs4_Compound.c:743
#9 0x000000000044c20d in nfs_rpc_execute (reqdata=0x7f30a00008c0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1289
#10 0x000000000044ca17 in worker_run (ctx=0x1d88bf0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/MainNFSD/nfs_worker_thread.c:1561
#11 0x0000000000508a7a in fridgethr_start_routine (arg=0x1d88bf0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/support/fridgethr.c:550
#12 0x00007f31797f2df5 in start_thread (arg=0x7f31287c8700) at pthread_create.c:308
#13 0x00007f3178eb31ad in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:113
(gdb) p q
$1 = (struct lru_q *) 0x0
(gdb) f 3
#3 0x00000000005430ea in mdcache_new_entry (export=0x7f30bc05d070, sub_handle=0x7f3078007c20, attrs_in=0x7f31287c6670, attrs_out=0x0, new_directory=false,
entry=0x7f31287c67e8, state=0x0) at /usr/src/debug/nfs-ganesha-2.5.1-0.1.1-Source/FSAL/Stackable_FSALs/FSAL_MDCACHE/mdcache_helpers.c:590
590 nentry = mdcache_alloc_handle(export, sub_handle, sub_handle->fs);
(gdb) p export->flags
$2 = 1 '\001'
(gdb) p entry->lru
$6 = {q = {next = 0x0, prev = 0x0}, qid = LRU_ENTRY_NONE, refcnt = 1, flags = 0, lane = 2, cf = 0}
mdc_check_mapping () in following snippet returns error because MDC_UNEXPORT flag in export->flags is set.
After an export is completely removed and ganesha_mgr remove_export command returned successfully, why do we see the flag set?
The comment also says "The current export is in process to be unexported"
/* Map the export before we put this entry into the LRU, but after it's
* well enough set up to be able to be unrefed by unexport should there
* be a race.
*/
status = mdc_check_mapping(result);
if (unlikely(FSAL_IS_ERROR(status))) {
/* The current export is in process to be unexported, don't
* create new mdcache entries.
*/
LogDebug(COMPONENT_CACHE_INODE,
"Trying to allocate a new entry %p for export id %"
PRIi16" that is in the process of being unexported",
result, op_ctx->ctx_export->export_id);
mdcache_put(result);
mdcache_kill_entry(result);
return NULL;
}
The crash occurs because lru_queue_of() returns q = NULL due to entry->lru.qid = LRU_NO_LANE and LRU_DQ_SAFE refers to q.
Is there any deferred work during unexport in mdcache FSAL?
If we add delay between remove_export and add_export, I did not see the problem. But that does not seem to be elegant solution.
Please help me understand if there are any limitations from mdcache with respect to back to back unexport and export operation.
Thanks,
Sandeep
***************************Legal Disclaimer***************************
"This communication may contain confidential and privileged material for the
sole use of the intended recipient. Any unauthorized review, use or distribution
by others is strictly prohibited. If you have received the message by mistake,
please advise the sender by reply email and delete the message. Thank you."
**********************************************************************
5 years, 7 months