* [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
[parent not found: <55111C81.5010009@bull.net>]
[parent not found: <D13891F9.E8187%andreas.dilger@intel.com>]
* [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.