[LU-7845] Support namespace in credentials retrieval Created: 04/Mar/16  Updated: 15/Feb/23  Resolved: 17/Dec/16

Status: Resolved
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.10.0

Type: New Feature Priority: Minor
Reporter: Sebastien Buisson (Inactive) Assignee: John Hammond
Resolution: Fixed Votes: 0
Labels: patch

Issue Links:
Duplicate
Related
is related to LU-16557 don't skip add_conn with -o network m... Resolved
is related to LU-8392 sanity test_27z: soft lockup - CPU#0 ... Resolved
Rank (Obsolete): 9223372036854775807

 Description   

We are running Lustre clients from Docker containers, and we try to have Kerberos authentication for them.
We hit an issue when Lustre code (kernel space, so running on the host) calls request_key to get Kerberos credentials. The problem is that the request_key function will call the userland helper function that is on the host, not in the container, because it has no idea that it all started from a container. The consequence is that Lustre cannot get the Kerberos credentials associated with the client in the container.

There are some ongoing discussions in the kernel to find the best way, if any, to address this problem of namespace between request_key and userland helper.
However, I think we cannot afford having a patched kernel on client side. So I started thinking about a way to be able to retrieve credentials stored inside a Docker container when Lustre is mounted from this container.
I will post a patch with my proposal.

Thanks,
Sebastien.



 Comments   
Comment by Gerrit Updater [ 04/Mar/16 ]

Sebastien Buisson (sbuisson@ddn.com) uploaded a new patch: http://review.whamcloud.com/18781
Subject: LU-7845 gss: support namespace in lgss_keyring
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 97a147b3c1103191251d8a63308c7428dc230d27

Comment by Gerrit Updater [ 04/Mar/16 ]

Sebastien Buisson (sbuisson@ddn.com) uploaded a new patch: http://review.whamcloud.com/18782
Subject: LU-7845 lnet: check if address is visible
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: a7a4ffe03eea7f6f17ccaad86c52d0f9e3717a0f

Comment by Gerrit Updater [ 26/Apr/16 ]

Sebastien Buisson (sbuisson@ddn.com) uploaded a new patch: http://review.whamcloud.com/19792
Subject: LU-7845 obd: add 'network' client mount option
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: c58fa1a8da4c43b26abefda54dbe46ec79cadc3f

Comment by Gerrit Updater [ 11/Jul/16 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/18782/
Subject: LU-7845 lnet: check if address is visible
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 57b80581e8f13b9f7ddb4c1135390de1ec22b11d

Comment by Gerrit Updater [ 02/Aug/16 ]

Oleg Drokin (oleg.drokin@intel.com) uploaded a new patch: http://review.whamcloud.com/21631
Subject: Revert "LU-7845 lnet: check if address is visible"
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 70a9b59ff792834bd540370cf7fd1fa91609deb3

Comment by Sebastien Buisson (Inactive) [ 02/Aug/16 ]

Oleg,

I guess you reverted patch http://review.whamcloud.com/18782 to solve the issue described in LU-8392. But as the issue was still hit with patch http://review.whamcloud.com/21437 (patch that avoids calling lnet_ipif_query() while holding the lnet_net_lock), there is no clue that this patch is responsible for this soft lockup.

If you anyway think that patch http://review.whamcloud.com/21437 is necessary, let's work to have it merged.

Sebastien.

Comment by John Hammond [ 02/Aug/16 ]

> But as the issue was still hit with patch http://review.whamcloud.com/21437 (patch that avoids calling lnet_ipif_query() while holding the lnet_net_lock), there is no clue that this patch is responsible for this soft lockup.

This patch calls LIBCFS_ALLOC() while holding the lock so it's also subject to soft lockup.

Comment by Sebastien Buisson (Inactive) [ 03/Aug/16 ]

I pushed a new version of the patch at http://review.whamcloud.com/21437, that avoids calling LIBCFS_ALLOC() while holding the lock.

Comment by Sebastien Buisson (Inactive) [ 04/Aug/16 ]

FYI, patch http://review.whamcloud.com/21437 successfully passed Maloo tests.
I have just retriggered them with:
Test-Parameters: fortestonly testlist=sanity,sanity,sanity,sanity
to see if it passes sanity consistently.

Comment by Sebastien Buisson (Inactive) [ 05/Aug/16 ]

Hi,

Confirmed that http://review.whamcloud.com/21437 passes sanity tests consistently.

Comment by Gerrit Updater [ 06/Aug/16 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/21631/
Subject: Revert "LU-7845 lnet: check if address is visible"
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 0f9fa5180fb015af656b8eea06f04b02abc02232

Comment by Gerrit Updater [ 11/Aug/16 ]

Sebastien Buisson (sbuisson@ddn.com) uploaded a new patch: http://review.whamcloud.com/21884
Subject: LU-7845 lnet: check if ni is in current net namespace
Project: fs/lustre-release
Branch: master
Current Patch Set: 1
Commit: 17aecba54686ec1ed45fd62944d3d61b48b547b6

Comment by Gerrit Updater [ 29/Aug/16 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch http://review.whamcloud.com/21884/
Subject: LU-7845 lnet: check if ni is in current net namespace
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 9a7c0e1207becd10fb70672193ca39cbfabdcf84

Comment by Gerrit Updater [ 17/Dec/16 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/18781/
Subject: LU-7845 gss: support namespace in lgss_keyring
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 94c44c62dea2cf1f2174569524721ded1bbd1ce7

Comment by Gerrit Updater [ 17/Dec/16 ]

Oleg Drokin (oleg.drokin@intel.com) merged in patch https://review.whamcloud.com/19792/
Subject: LU-7845 obd: add 'network' client mount option
Project: fs/lustre-release
Branch: master
Current Patch Set:
Commit: 1cf11e1cf9a55fa71c873a5f485be4b63e3a5e39

Comment by Peter Jones [ 17/Dec/16 ]

Landed for 2.10

Generated at Sat Feb 10 02:12:25 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.