* [lustre-devel] Fwd: proposed version change for PTLRPC GSS
[not found] <CAC2+cFgRWEEALvwhOiSdhiapkvE=VeeiZ_KeNihud0bxN8y2ew@mail.gmail.com>
@ 2015-03-24 20:15 ` Jeremy Filizetti
[not found] ` <55111C81.5010009@bull.net>
1 sibling, 0 replies; 7+ messages in thread
From: Jeremy Filizetti @ 2015-03-24 20:15 UTC (permalink / raw)
To: lustre-devel
I'm sending to lustre-devel for wider distribution/comment.
---------- Forwarded message ----------
From: Jeremy Filizetti <jeremy.filizetti@gmail.com>
Date: Mon, Mar 23, 2015 at 9:34 PM
Subject: proposed version change for PTLRPC GSS
To: "iudev at lists.opensfs.org" <iudev@lists.opensfs.org>
On the phone call last week we discussed an increment of the
PTLRPC_GSS_VERSION to version 2 to allow some changes
changes/restructuring. No one had any objections on the phone call but I
wanted to send it out for wider distribution and feedback.
Changing the request format would allow us to support larger GSS token
sizes which today are limited (see ticket LU-3855). From what I have
looked through so far the following seems to allow for larger tokens and
also allow some of these changes without having to worry about backwards
compatibility since it was never really "working" anyways.
Change PTLRPC_GSS_VERSION to 2
Enlarge GSS_CTX_INIT_MAX_LEN to something larger then 1024. Ideally we
would support MaxTokenSize of 64k for the largest active directory ticket:
(see
http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-and-kerberos-token-bloat.aspx
).
The purpose of enlarging this is to support larger tokens. The
sizeof(struct rsi) needs to remain under PAGE_SIZE right now with
rsi_request calling sunrpc_cache_pipe_upcall. Since there is only one
lsvcgssd process supposed to be running maybe it would be acceptable to use
larger requests and just slightly modify rsi_request to incorporate must of
the functionality of sunrpc_cache_pipe_upcall.
To keep things simple with the lsvcgssd and continue to use a single
channel proc file interface I'd like to AND the GSS subflavor onto most
significant bits of lustre_svc in struct rsi. Instead of calling the
inappropriately named handle_nullreq things would be changed to handle the
multiple subflavors (gssnull, sk, krb5). gssnull and sk won't have a full
userspace component so gss_accept_sec_context can't be called.
Thoughts welcome. I'm sure I missed something along the way here but this
is just what I have looked at so far.
Thanks,
Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20150324/6879d571/attachment.htm>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
[not found] ` <D13891F9.E8187%andreas.dilger@intel.com>
@ 2015-03-27 8:45 ` Sebastien Buisson
2015-04-16 18:29 ` Nathan Rutman
0 siblings, 1 reply; 7+ messages in thread
From: Sebastien Buisson @ 2015-03-27 8:45 UTC (permalink / raw)
To: lustre-devel
Re-emitting because of issues with my email address.
--------
Hi,
As I understand the need for evolutions in the GSS code, I advocate the
review and merge of all patches related to Kerberos revival as soon as
possible. It would avoid painful rebase of work done by IU, or Kerberos
patches, or both.
The Kerberos revival patches waiting for review are:
http://review.whamcloud.com/14040
http://review.whamcloud.com/14041
http://review.whamcloud.com/14042
Best regards,
Sebastien.
Le 25/03/2015 22:25, Dilger, Andreas a ?crit :
> Sebastien,
> can you please also add lustre-devel at lists.lustre.org to the CC list for
> this discussion.
>
> On 2015/03/24, 3:12 AM, "Sebastien Buisson" <sebastien.buisson@atos.net>
> wrote:
>
>> Hi there,
>>
>> I agree we should not bother with backward compatibility. Kerberos
>> revival patches aim at Lustre 2.8, so we are good if the modifications
>> you propose also land in 2.8.
>>
>> Taking advantage of the opportunity to replace handle_nullreq with
>> subflavor specific code is really nice, as those bits are really
>> confusing for someone who tries to understand the code.
>>
>> Cheers,
>> Sebastien.
>>
>>
>> Le 24/03/2015 02:34, Jeremy Filizetti a ?crit :
>>> On the phone call last week we discussed an increment of the
>>> PTLRPC_GSS_VERSION to version 2 to allow some changes
>>> changes/restructuring. No one had any objections on the phone call but
>>> I wanted to send it out for wider distribution and feedback.
>>>
>>> Changing the request format would allow us to support larger GSS token
>>> sizes which today are limited (see ticket LU-3855). From what I have
>>> looked through so far the following seems to allow for larger tokens and
>>> also allow some of these changes without having to worry about backwards
>>> compatibility since it was never really "working" anyways.
>>>
>>> Change PTLRPC_GSS_VERSION to 2
>>>
>>> Enlarge GSS_CTX_INIT_MAX_LEN to something larger then 1024. Ideally we
>>> would support MaxTokenSize of 64k for the largest active directory
>>> ticket: (see
>>>
>>> http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a
>>> nd-kerberos-token-bloat.aspx).
>>> The purpose of enlarging this is to support larger tokens. The
>>> sizeof(struct rsi) needs to remain under PAGE_SIZE right now with
>>> rsi_request calling sunrpc_cache_pipe_upcall. Since there is only one
>>> lsvcgssd process supposed to be running maybe it would be acceptable to
>>> use larger requests and just slightly modify rsi_request to incorporate
>>> must of the functionality of sunrpc_cache_pipe_upcall.
>>>
>>> To keep things simple with the lsvcgssd and continue to use a single
>>> channel proc file interface I'd like to AND the GSS subflavor onto most
>>> significant bits of lustre_svc in struct rsi. Instead of calling the
>>> inappropriately named handle_nullreq things would be changed to handle
>>> the multiple subflavors (gssnull, sk, krb5). gssnull and sk won't have
>>> a full userspace component so gss_accept_sec_context can't be called.
>>>
>>> Thoughts welcome. I'm sure I missed something along the way here but
>>> this is just what I have looked at so far.
>>>
>>> Thanks,
>>> Jeremy
>>>
>>>
>>> _______________________________________________
>>> Iudev mailing list
>>> Iudev at lists.opensfs.org
>>> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>>>
>> _______________________________________________
>> Iudev mailing list
>> Iudev at lists.opensfs.org
>> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>>
>
>
> Cheers, Andreas
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
2015-03-27 8:45 ` [lustre-devel] [Iudev] " Sebastien Buisson
@ 2015-04-16 18:29 ` Nathan Rutman
2015-04-16 18:38 ` Sebastien Buisson
0 siblings, 1 reply; 7+ messages in thread
From: Nathan Rutman @ 2015-04-16 18:29 UTC (permalink / raw)
To: lustre-devel
Sebastien, do these patches represent all the merged Kerberos changes?
Or can these be landed independently of the others?
*--*
*Nathan Rutman ? Principal Systems ArchitectSeagate Technology** ? *+1 503
877-9507* ? *GMT-8
On Fri, Mar 27, 2015 at 1:45 AM, Sebastien Buisson <
sebastien.buisson@atos.net> wrote:
> Re-emitting because of issues with my email address.
> --------
>
> Hi,
>
> As I understand the need for evolutions in the GSS code, I advocate the
> review and merge of all patches related to Kerberos revival as soon as
> possible. It would avoid painful rebase of work done by IU, or Kerberos
> patches, or both.
> The Kerberos revival patches waiting for review are:
> http://review.whamcloud.com/14040
> http://review.whamcloud.com/14041
> http://review.whamcloud.com/14042
>
> Best regards,
> Sebastien.
>
>
> Le 25/03/2015 22:25, Dilger, Andreas a ?crit :
>
>> Sebastien,
>> can you please also add lustre-devel at lists.lustre.org to the CC list for
>> this discussion.
>>
>> On 2015/03/24, 3:12 AM, "Sebastien Buisson" <sebastien.buisson@atos.net>
>> wrote:
>>
>> Hi there,
>>>
>>> I agree we should not bother with backward compatibility. Kerberos
>>> revival patches aim at Lustre 2.8, so we are good if the modifications
>>> you propose also land in 2.8.
>>>
>>> Taking advantage of the opportunity to replace handle_nullreq with
>>> subflavor specific code is really nice, as those bits are really
>>> confusing for someone who tries to understand the code.
>>>
>>> Cheers,
>>> Sebastien.
>>>
>>>
>>> Le 24/03/2015 02:34, Jeremy Filizetti a ?crit :
>>>
>>>> On the phone call last week we discussed an increment of the
>>>> PTLRPC_GSS_VERSION to version 2 to allow some changes
>>>> changes/restructuring. No one had any objections on the phone call but
>>>> I wanted to send it out for wider distribution and feedback.
>>>>
>>>> Changing the request format would allow us to support larger GSS token
>>>> sizes which today are limited (see ticket LU-3855). From what I have
>>>> looked through so far the following seems to allow for larger tokens and
>>>> also allow some of these changes without having to worry about backwards
>>>> compatibility since it was never really "working" anyways.
>>>>
>>>> Change PTLRPC_GSS_VERSION to 2
>>>>
>>>> Enlarge GSS_CTX_INIT_MAX_LEN to something larger then 1024. Ideally we
>>>> would support MaxTokenSize of 64k for the largest active directory
>>>> ticket: (see
>>>>
>>>> http://blogs.technet.com/b/shanecothran/archive/2010/07/
>>>> 16/maxtokensize-a
>>>> nd-kerberos-token-bloat.aspx).
>>>> The purpose of enlarging this is to support larger tokens. The
>>>> sizeof(struct rsi) needs to remain under PAGE_SIZE right now with
>>>> rsi_request calling sunrpc_cache_pipe_upcall. Since there is only one
>>>> lsvcgssd process supposed to be running maybe it would be acceptable to
>>>> use larger requests and just slightly modify rsi_request to incorporate
>>>> must of the functionality of sunrpc_cache_pipe_upcall.
>>>>
>>>> To keep things simple with the lsvcgssd and continue to use a single
>>>> channel proc file interface I'd like to AND the GSS subflavor onto most
>>>> significant bits of lustre_svc in struct rsi. Instead of calling the
>>>> inappropriately named handle_nullreq things would be changed to handle
>>>> the multiple subflavors (gssnull, sk, krb5). gssnull and sk won't have
>>>> a full userspace component so gss_accept_sec_context can't be called.
>>>>
>>>> Thoughts welcome. I'm sure I missed something along the way here but
>>>> this is just what I have looked at so far.
>>>>
>>>> Thanks,
>>>> Jeremy
>>>>
>>>>
>>>> _______________________________________________
>>>> Iudev mailing list
>>>> Iudev at lists.opensfs.org
>>>> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>>>>
>>>> _______________________________________________
>>> Iudev mailing list
>>> Iudev at lists.opensfs.org
>>> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>>>
>>>
>>
>> Cheers, Andreas
>>
>> _______________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20150416/437565ab/attachment.htm>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
2015-04-16 18:29 ` Nathan Rutman
@ 2015-04-16 18:38 ` Sebastien Buisson
2015-04-21 19:46 ` Nathan Rutman
0 siblings, 1 reply; 7+ messages in thread
From: Sebastien Buisson @ 2015-04-16 18:38 UTC (permalink / raw)
To: lustre-devel
Hi Nathan,
All the Kerberos related patches that are not landed yet are:
LU-3778:
http://review.whamcloud.com/14040
LU-6356:
http://review.whamcloud.com/14349
http://review.whamcloud.com/14041
http://review.whamcloud.com/14042
http://review.whamcloud.com/14404
They can all possibly impact the work done on Shared Key feature, this
is why I was proposing that have them merged as soon as possible.
Best regards,
Sebastien.
Le 16/04/2015 12:22, Nathan Rutman a ?crit :
> Sebastien, do these patches represent all the merged Kerberos changes?
> Or can these be landed independently of the others?
>
>
> *--*
> *Nathan Rutman ? Principal Systems Architect
> Seagate Technology** ? *+1 503 877-9507* ? *GMT-8
>
> On Fri, Mar 27, 2015 at 1:45 AM, Sebastien Buisson
> <sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>> wrote:
>
> Re-emitting because of issues with my email address.
> --------
>
> Hi,
>
> As I understand the need for evolutions in the GSS code, I advocate
> the review and merge of all patches related to Kerberos revival as
> soon as possible. It would avoid painful rebase of work done by IU,
> or Kerberos patches, or both.
> The Kerberos revival patches waiting for review are:
> http://review.whamcloud.com/__14040 <http://review.whamcloud.com/14040>
> http://review.whamcloud.com/__14041 <http://review.whamcloud.com/14041>
> http://review.whamcloud.com/__14042 <http://review.whamcloud.com/14042>
>
> Best regards,
> Sebastien.
>
>
> Le 25/03/2015 22:25, Dilger, Andreas a ?crit :
>
> Sebastien,
> can you please also add lustre-devel at lists.lustre.org
> <mailto:lustre-devel@lists.lustre.org> to the CC list for
> this discussion.
>
> On 2015/03/24, 3:12 AM, "Sebastien Buisson"
> <sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>>
> wrote:
>
> Hi there,
>
> I agree we should not bother with backward compatibility.
> Kerberos
> revival patches aim at Lustre 2.8, so we are good if the
> modifications
> you propose also land in 2.8.
>
> Taking advantage of the opportunity to replace
> handle_nullreq with
> subflavor specific code is really nice, as those bits are really
> confusing for someone who tries to understand the code.
>
> Cheers,
> Sebastien.
>
>
> Le 24/03/2015 02:34, Jeremy Filizetti a ?crit :
>
> On the phone call last week we discussed an increment of the
> PTLRPC_GSS_VERSION to version 2 to allow some changes
> changes/restructuring. No one had any objections on the
> phone call but
> I wanted to send it out for wider distribution and feedback.
>
> Changing the request format would allow us to support
> larger GSS token
> sizes which today are limited (see ticket LU-3855).
> From what I have
> looked through so far the following seems to allow for
> larger tokens and
> also allow some of these changes without having to worry
> about backwards
> compatibility since it was never really "working" anyways.
>
> Change PTLRPC_GSS_VERSION to 2
>
> Enlarge GSS_CTX_INIT_MAX_LEN to something larger then
> 1024. Ideally we
> would support MaxTokenSize of 64k for the largest active
> directory
> ticket: (see
>
> http://blogs.technet.com/b/__shanecothran/archive/2010/07/__16/maxtokensize-a
> <http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a>
> nd-kerberos-token-bloat.aspx).
> The purpose of enlarging this is to support larger
> tokens. The
> sizeof(struct rsi) needs to remain under PAGE_SIZE right
> now with
> rsi_request calling sunrpc_cache_pipe_upcall. Since
> there is only one
> lsvcgssd process supposed to be running maybe it would
> be acceptable to
> use larger requests and just slightly modify rsi_request
> to incorporate
> must of the functionality of sunrpc_cache_pipe_upcall.
>
> To keep things simple with the lsvcgssd and continue to
> use a single
> channel proc file interface I'd like to AND the GSS
> subflavor onto most
> significant bits of lustre_svc in struct rsi. Instead
> of calling the
> inappropriately named handle_nullreq things would be
> changed to handle
> the multiple subflavors (gssnull, sk, krb5). gssnull
> and sk won't have
> a full userspace component so gss_accept_sec_context
> can't be called.
>
> Thoughts welcome. I'm sure I missed something along the
> way here but
> this is just what I have looked at so far.
>
> Thanks,
> Jeremy
>
>
> _________________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>
> _________________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>
>
>
> Cheers, Andreas
>
> _________________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>
>
>
>
> _______________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org
> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
2015-04-16 18:38 ` Sebastien Buisson
@ 2015-04-21 19:46 ` Nathan Rutman
2015-07-09 14:06 ` Nunez, James A
0 siblings, 1 reply; 7+ messages in thread
From: Nathan Rutman @ 2015-04-21 19:46 UTC (permalink / raw)
To: lustre-devel
Hi Sebastien -
thanks for pushing this forward. At this point, I want to make sure that we
have the "union" of all the Kerberos fixes from Bull and Seagate on track
for landing. I know you're already working with Andrew but if there's
anything else that you need from Seagate please let me know.
*--*
*Nathan Rutman ? Principal Systems ArchitectSeagate Technology** ? *+1 503
877-9507* ? *GMT-8
On Thu, Apr 16, 2015 at 11:38 AM, Sebastien Buisson <
sebastien.buisson@atos.net> wrote:
> Hi Nathan,
>
> All the Kerberos related patches that are not landed yet are:
> LU-3778:
> http://review.whamcloud.com/14040
> LU-6356:
> http://review.whamcloud.com/14349
> http://review.whamcloud.com/14041
> http://review.whamcloud.com/14042
> http://review.whamcloud.com/14404
>
> They can all possibly impact the work done on Shared Key feature, this is
> why I was proposing that have them merged as soon as possible.
>
> Best regards,
> Sebastien.
>
>
> Le 16/04/2015 12:22, Nathan Rutman a ?crit :
>
>> Sebastien, do these patches represent all the merged Kerberos changes?
>> Or can these be landed independently of the others?
>>
>>
>> *--*
>> *Nathan Rutman ? Principal Systems Architect
>> Seagate Technology** ? *+1 503 877-9507* ? *GMT-8
>>
>> On Fri, Mar 27, 2015 at 1:45 AM, Sebastien Buisson
>> <sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>> wrote:
>>
>> Re-emitting because of issues with my email address.
>> --------
>>
>> Hi,
>>
>> As I understand the need for evolutions in the GSS code, I advocate
>> the review and merge of all patches related to Kerberos revival as
>> soon as possible. It would avoid painful rebase of work done by IU,
>> or Kerberos patches, or both.
>> The Kerberos revival patches waiting for review are:
>> http://review.whamcloud.com/__14040 <
>> http://review.whamcloud.com/14040>
>> http://review.whamcloud.com/__14041 <
>> http://review.whamcloud.com/14041>
>> http://review.whamcloud.com/__14042 <
>> http://review.whamcloud.com/14042>
>>
>> Best regards,
>> Sebastien.
>>
>>
>> Le 25/03/2015 22:25, Dilger, Andreas a ?crit :
>>
>> Sebastien,
>> can you please also add lustre-devel at lists.lustre.org
>> <mailto:lustre-devel@lists.lustre.org> to the CC list for
>> this discussion.
>>
>> On 2015/03/24, 3:12 AM, "Sebastien Buisson"
>> <sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>>
>>
>> wrote:
>>
>> Hi there,
>>
>> I agree we should not bother with backward compatibility.
>> Kerberos
>> revival patches aim at Lustre 2.8, so we are good if the
>> modifications
>> you propose also land in 2.8.
>>
>> Taking advantage of the opportunity to replace
>> handle_nullreq with
>> subflavor specific code is really nice, as those bits are
>> really
>> confusing for someone who tries to understand the code.
>>
>> Cheers,
>> Sebastien.
>>
>>
>> Le 24/03/2015 02:34, Jeremy Filizetti a ?crit :
>>
>> On the phone call last week we discussed an increment of
>> the
>> PTLRPC_GSS_VERSION to version 2 to allow some changes
>> changes/restructuring. No one had any objections on the
>> phone call but
>> I wanted to send it out for wider distribution and
>> feedback.
>>
>> Changing the request format would allow us to support
>> larger GSS token
>> sizes which today are limited (see ticket LU-3855).
>> From what I have
>> looked through so far the following seems to allow for
>> larger tokens and
>> also allow some of these changes without having to worry
>> about backwards
>> compatibility since it was never really "working" anyways.
>>
>> Change PTLRPC_GSS_VERSION to 2
>>
>> Enlarge GSS_CTX_INIT_MAX_LEN to something larger then
>> 1024. Ideally we
>> would support MaxTokenSize of 64k for the largest active
>> directory
>> ticket: (see
>>
>>
>> http://blogs.technet.com/b/__shanecothran/archive/2010/07/__16/maxtokensize-a
>>
>> <
>> http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a
>> >
>> nd-kerberos-token-bloat.aspx).
>> The purpose of enlarging this is to support larger
>> tokens. The
>> sizeof(struct rsi) needs to remain under PAGE_SIZE right
>> now with
>> rsi_request calling sunrpc_cache_pipe_upcall. Since
>> there is only one
>> lsvcgssd process supposed to be running maybe it would
>> be acceptable to
>> use larger requests and just slightly modify rsi_request
>> to incorporate
>> must of the functionality of sunrpc_cache_pipe_upcall.
>>
>> To keep things simple with the lsvcgssd and continue to
>> use a single
>> channel proc file interface I'd like to AND the GSS
>> subflavor onto most
>> significant bits of lustre_svc in struct rsi. Instead
>> of calling the
>> inappropriately named handle_nullreq things would be
>> changed to handle
>> the multiple subflavors (gssnull, sk, krb5). gssnull
>> and sk won't have
>> a full userspace component so gss_accept_sec_context
>> can't be called.
>>
>> Thoughts welcome. I'm sure I missed something along the
>> way here but
>> this is just what I have looked at so far.
>>
>> Thanks,
>> Jeremy
>>
>>
>> _________________________________________________
>> Iudev mailing list
>> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
>> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
>> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>>
>> _________________________________________________
>> Iudev mailing list
>> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
>> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
>> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>>
>>
>>
>> Cheers, Andreas
>>
>> _________________________________________________
>> Iudev mailing list
>> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
>> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
>> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>>
>>
>>
>>
>> _______________________________________________
>> Iudev mailing list
>> Iudev at lists.opensfs.org
>> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20150421/84d7e4bd/attachment.htm>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
2015-04-21 19:46 ` Nathan Rutman
@ 2015-07-09 14:06 ` Nunez, James A
2015-07-09 15:34 ` Sebastien Buisson
0 siblings, 1 reply; 7+ messages in thread
From: Nunez, James A @ 2015-07-09 14:06 UTC (permalink / raw)
To: lustre-devel
Nathan and Sebastien,
I?m interested in testing the revived Kerberos support in Lustre. I?d like to understand how you tested this feature and suggested best practices on setting up the Kerberos environment for use with Lustre.
I?ve looked in Jira and can?t find a test plan for Kerberos. Do you have a test plan and would you please share it?
I?ve looked over all the patches for the Kerberos Revival ticket and don?t see any new tests added by these patches. Does this mean that the existing Kerberos tests in sanity-krb5 still work and test the feature thoroughly? If not, would you please submit a patch adding new tests?
Thank you,
James
From: lustre-devel [mailto:lustre-devel-bounces at lists.lustre.org] On Behalf Of Nathan Rutman
Sent: Tuesday, April 21, 2015 1:47 PM
To: Sebastien Buisson; Andrew Perepechko
Cc: iudev at lists.opensfs.org; lustre-devel at lists.lustre.org
Subject: Re: [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
Hi Sebastien -
thanks for pushing this forward. At this point, I want to make sure that we have the "union" of all the Kerberos fixes from Bull and Seagate on track for landing. I know you're already working with Andrew but if there's anything else that you need from Seagate please let me know.
--
Nathan Rutman ? Principal Systems Architect
Seagate Technology ? +1 503 877-9507 ? GMT-8
On Thu, Apr 16, 2015 at 11:38 AM, Sebastien Buisson <sebastien.buisson at atos.net<mailto:sebastien.buisson@atos.net>> wrote:
Hi Nathan,
All the Kerberos related patches that are not landed yet are:
LU-3778:
http://review.whamcloud.com/14040
LU-6356:
http://review.whamcloud.com/14349
http://review.whamcloud.com/14041
http://review.whamcloud.com/14042
http://review.whamcloud.com/14404
They can all possibly impact the work done on Shared Key feature, this is why I was proposing that have them merged as soon as possible.
Best regards,
Sebastien.
Le 16/04/2015 12:22, Nathan Rutman a ?crit :
Sebastien, do these patches represent all the merged Kerberos changes?
Or can these be landed independently of the others?
*--*
*Nathan Rutman ? Principal Systems Architect
Seagate Technology** ? *+1 503 877-9507<tel:%2B1%20503%20877-9507>* ? *GMT-8
On Fri, Mar 27, 2015 at 1:45 AM, Sebastien Buisson
<sebastien.buisson at atos.net<mailto:sebastien.buisson@atos.net> <mailto:sebastien.buisson at atos.net<mailto:sebastien.buisson@atos.net>>> wrote:
Re-emitting because of issues with my email address.
--------
Hi,
As I understand the need for evolutions in the GSS code, I advocate
the review and merge of all patches related to Kerberos revival as
soon as possible. It would avoid painful rebase of work done by IU,
or Kerberos patches, or both.
The Kerberos revival patches waiting for review are:
http://review.whamcloud.com/__14040 <http://review.whamcloud.com/14040>
http://review.whamcloud.com/__14041 <http://review.whamcloud.com/14041>
http://review.whamcloud.com/__14042 <http://review.whamcloud.com/14042>
Best regards,
Sebastien.
Le 25/03/2015 22:25, Dilger, Andreas a ?crit :
Sebastien,
can you please also add lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>
<mailto:lustre-devel at lists.lustre.org<mailto:lustre-devel@lists.lustre.org>> to the CC list for
this discussion.
On 2015/03/24, 3:12 AM, "Sebastien Buisson"
<sebastien.buisson at atos.net<mailto:sebastien.buisson@atos.net> <mailto:sebastien.buisson at atos.net<mailto:sebastien.buisson@atos.net>>>
wrote:
Hi there,
I agree we should not bother with backward compatibility.
Kerberos
revival patches aim at Lustre 2.8, so we are good if the
modifications
you propose also land in 2.8.
Taking advantage of the opportunity to replace
handle_nullreq with
subflavor specific code is really nice, as those bits are really
confusing for someone who tries to understand the code.
Cheers,
Sebastien.
Le 24/03/2015 02:34, Jeremy Filizetti a ?crit :
On the phone call last week we discussed an increment of the
PTLRPC_GSS_VERSION to version 2 to allow some changes
changes/restructuring. No one had any objections on the
phone call but
I wanted to send it out for wider distribution and feedback.
Changing the request format would allow us to support
larger GSS token
sizes which today are limited (see ticket LU-3855).
From what I have
looked through so far the following seems to allow for
larger tokens and
also allow some of these changes without having to worry
about backwards
compatibility since it was never really "working" anyways.
Change PTLRPC_GSS_VERSION to 2
Enlarge GSS_CTX_INIT_MAX_LEN to something larger then
1024. Ideally we
would support MaxTokenSize of 64k for the largest active
directory
ticket: (see
http://blogs.technet.com/b/__shanecothran/archive/2010/07/__16/maxtokensize-a
<http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a>
nd-kerberos-token-bloat.aspx).
The purpose of enlarging this is to support larger
tokens. The
sizeof(struct rsi) needs to remain under PAGE_SIZE right
now with
rsi_request calling sunrpc_cache_pipe_upcall. Since
there is only one
lsvcgssd process supposed to be running maybe it would
be acceptable to
use larger requests and just slightly modify rsi_request
to incorporate
must of the functionality of sunrpc_cache_pipe_upcall.
To keep things simple with the lsvcgssd and continue to
use a single
channel proc file interface I'd like to AND the GSS
subflavor onto most
significant bits of lustre_svc in struct rsi. Instead
of calling the
inappropriately named handle_nullreq things would be
changed to handle
the multiple subflavors (gssnull, sk, krb5). gssnull
and sk won't have
a full userspace component so gss_accept_sec_context
can't be called.
Thoughts welcome. I'm sure I missed something along the
way here but
this is just what I have looked at so far.
Thanks,
Jeremy
_________________________________________________
Iudev mailing list
Iudev at lists.opensfs.org<mailto:Iudev@lists.opensfs.org> <mailto:Iudev at lists.opensfs.org<mailto:Iudev@lists.opensfs.org>>
http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
_________________________________________________
Iudev mailing list
Iudev at lists.opensfs.org<mailto:Iudev@lists.opensfs.org> <mailto:Iudev at lists.opensfs.org<mailto:Iudev@lists.opensfs.org>>
http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
<http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
Cheers, Andreas
_________________________________________________
Iudev mailing list
Iudev at lists.opensfs.org<mailto:Iudev@lists.opensfs.org> <mailto:Iudev at lists.opensfs.org<mailto:Iudev@lists.opensfs.org>>
http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
<http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
_______________________________________________
Iudev mailing list
Iudev at lists.opensfs.org<mailto:Iudev@lists.opensfs.org>
http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20150709/d24cb57b/attachment-0001.htm>
^ permalink raw reply [flat|nested] 7+ messages in thread
* [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
2015-07-09 14:06 ` Nunez, James A
@ 2015-07-09 15:34 ` Sebastien Buisson
0 siblings, 0 replies; 7+ messages in thread
From: Sebastien Buisson @ 2015-07-09 15:34 UTC (permalink / raw)
To: lustre-devel
Hello James,
I just updated LU-6356 with the Kerberos Test Plan.
Basically, all sanity-krb5 tests pass, with some patches that I will
submit very soon in the ticket.
The notable exceptions are tests related to 'lfs flushctx': I started
investigating, but the thing is I cannot figure out what this command is
supposed to do exactly. So it prevents me from determining which part of
the code should be fixed.
Cheers,
Sebastien.
Le 09/07/2015 16:06, Nunez, James A a ?crit :
> Nathan and Sebastien,
>
> I?m interested in testing the revived Kerberos support in Lustre. I?d
> like to understand how you tested this feature and suggested best
> practices on setting up the Kerberos environment for use with Lustre.
>
> I?ve looked in Jira and can?t find a test plan for Kerberos. Do you have
> a test plan and would you please share it?
>
> I?ve looked over all the patches for the Kerberos Revival ticket and
> don?t see any new tests added by these patches. Does this mean that the
> existing Kerberos tests in sanity-krb5 still work and test the feature
> thoroughly? If not, would you please submit a patch adding new tests?
>
> Thank you,
>
> James
>
> *From:*lustre-devel [mailto:lustre-devel-bounces at lists.lustre.org] *On
> Behalf Of *Nathan Rutman
> *Sent:* Tuesday, April 21, 2015 1:47 PM
> *To:* Sebastien Buisson; Andrew Perepechko
> *Cc:* iudev at lists.opensfs.org; lustre-devel at lists.lustre.org
> *Subject:* Re: [lustre-devel] [Iudev] proposed version change for PTLRPC GSS
>
> Hi Sebastien -
>
> thanks for pushing this forward. At this point, I want to make sure that
> we have the "union" of all the Kerberos fixes from Bull and Seagate on
> track for landing. I know you're already working with Andrew but if
> there's anything else that you need from Seagate please let me know.
>
>
> *--*
>
> *Nathan Rutman ? Principal Systems Architect
> Seagate Technology ? *+1 503 877-9507* ? *GMT-8
>
> On Thu, Apr 16, 2015 at 11:38 AM, Sebastien Buisson
> <sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>> wrote:
>
> Hi Nathan,
>
> All the Kerberos related patches that are not landed yet are:
> LU-3778:
> http://review.whamcloud.com/14040
> LU-6356:
> http://review.whamcloud.com/14349
> http://review.whamcloud.com/14041
> http://review.whamcloud.com/14042
> http://review.whamcloud.com/14404
>
> They can all possibly impact the work done on Shared Key feature, this
> is why I was proposing that have them merged as soon as possible.
>
> Best regards,
> Sebastien.
>
>
> Le 16/04/2015 12:22, Nathan Rutman a ?crit :
>
> Sebastien, do these patches represent all the merged Kerberos changes?
> Or can these be landed independently of the others?
>
>
> *--*
> *Nathan Rutman ? Principal Systems Architect
> Seagate Technology** ? *+1 503 877-9507 <tel:%2B1%20503%20877-9507>* ?
> *GMT-8
>
> On Fri, Mar 27, 2015 at 1:45 AM, Sebastien Buisson
> <sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>
> <mailto:sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>>>
> wrote:
>
> Re-emitting because of issues with my email address.
> --------
>
> Hi,
>
> As I understand the need for evolutions in the GSS code, I advocate
> the review and merge of all patches related to Kerberos revival as
> soon as possible. It would avoid painful rebase of work done by IU,
> or Kerberos patches, or both.
> The Kerberos revival patches waiting for review are:
> http://review.whamcloud.com/__14040 <http://review.whamcloud.com/14040>
> http://review.whamcloud.com/__14041 <http://review.whamcloud.com/14041>
> http://review.whamcloud.com/__14042 <http://review.whamcloud.com/14042>
>
> Best regards,
> Sebastien.
>
>
> Le 25/03/2015 22:25, Dilger, Andreas a ?crit :
>
> Sebastien,
> can you please also add lustre-devel at lists.lustre.org
> <mailto:lustre-devel@lists.lustre.org>
> <mailto:lustre-devel@lists.lustre.org
> <mailto:lustre-devel@lists.lustre.org>> to the CC list for
> this discussion.
>
> On 2015/03/24, 3:12 AM, "Sebastien Buisson"
> <sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>
> <mailto:sebastien.buisson at atos.net <mailto:sebastien.buisson@atos.net>>>
>
>
> wrote:
>
> Hi there,
>
> I agree we should not bother with backward compatibility.
> Kerberos
> revival patches aim at Lustre 2.8, so we are good if the
> modifications
> you propose also land in 2.8.
>
> Taking advantage of the opportunity to replace
> handle_nullreq with
> subflavor specific code is really nice, as those bits are
> really
> confusing for someone who tries to understand the code.
>
> Cheers,
> Sebastien.
>
>
> Le 24/03/2015 02:34, Jeremy Filizetti a ?crit :
>
> On the phone call last week we discussed an increment
> of the
> PTLRPC_GSS_VERSION to version 2 to allow some changes
> changes/restructuring. No one had any objections on the
> phone call but
> I wanted to send it out for wider distribution and
> feedback.
>
> Changing the request format would allow us to support
> larger GSS token
> sizes which today are limited (see ticket LU-3855).
> From what I have
> looked through so far the following seems to allow for
> larger tokens and
> also allow some of these changes without having to worry
> about backwards
> compatibility since it was never really "working" anyways.
>
> Change PTLRPC_GSS_VERSION to 2
>
> Enlarge GSS_CTX_INIT_MAX_LEN to something larger then
> 1024. Ideally we
> would support MaxTokenSize of 64k for the largest active
> directory
> ticket: (see
>
> http://blogs.technet.com/b/__shanecothran/archive/2010/07/__16/maxtokensize-a
>
>
>
> <http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a>
> nd-kerberos-token-bloat.aspx).
> The purpose of enlarging this is to support larger
> tokens. The
> sizeof(struct rsi) needs to remain under PAGE_SIZE right
> now with
> rsi_request calling sunrpc_cache_pipe_upcall. Since
> there is only one
> lsvcgssd process supposed to be running maybe it would
> be acceptable to
> use larger requests and just slightly modify rsi_request
> to incorporate
> must of the functionality of sunrpc_cache_pipe_upcall.
>
> To keep things simple with the lsvcgssd and continue to
> use a single
> channel proc file interface I'd like to AND the GSS
> subflavor onto most
> significant bits of lustre_svc in struct rsi. Instead
> of calling the
> inappropriately named handle_nullreq things would be
> changed to handle
> the multiple subflavors (gssnull, sk, krb5). gssnull
> and sk won't have
> a full userspace component so gss_accept_sec_context
> can't be called.
>
> Thoughts welcome. I'm sure I missed something along the
> way here but
> this is just what I have looked at so far.
>
> Thanks,
> Jeremy
>
> _________________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
> <mailto:Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>>
> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>
> _________________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
> <mailto:Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>>
> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>
>
>
> Cheers, Andreas
>
> _________________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
> <mailto:Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>>
> http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org
> <http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org>
>
>
>
>
> _______________________________________________
> Iudev mailing list
> Iudev at lists.opensfs.org <mailto:Iudev@lists.opensfs.org>
> http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org
>
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2015-07-09 15:34 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CAC2+cFgRWEEALvwhOiSdhiapkvE=VeeiZ_KeNihud0bxN8y2ew@mail.gmail.com>
2015-03-24 20:15 ` [lustre-devel] Fwd: proposed version change for PTLRPC GSS Jeremy Filizetti
[not found] ` <55111C81.5010009@bull.net>
[not found] ` <D13891F9.E8187%andreas.dilger@intel.com>
2015-03-27 8:45 ` [lustre-devel] [Iudev] " Sebastien Buisson
2015-04-16 18:29 ` Nathan Rutman
2015-04-16 18:38 ` Sebastien Buisson
2015-04-21 19:46 ` Nathan Rutman
2015-07-09 14:06 ` Nunez, James A
2015-07-09 15:34 ` Sebastien Buisson
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.