From sebastien.buisson at atos.net Thu Apr 16 18:38:38 2015 From: sebastien.buisson at atos.net (Sebastien Buisson) Date: Thu, 16 Apr 2015 12:38:38 -0600 Subject: [lustre-devel] [Iudev] proposed version change for PTLRPC GSS In-Reply-To: References: <55111C81.5010009@bull.net> <551518C3.70002@bull.net> Message-ID: <553001AE.2070601@bull.net> 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 > > 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" > > > 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 > > > > > > _______________________________________________ > Iudev mailing list > Iudev at lists.opensfs.org > http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org > From nathan.rutman at seagate.com Tue Apr 21 19:46:40 2015 From: nathan.rutman at seagate.com (Nathan Rutman) Date: Tue, 21 Apr 2015 12:46:40 -0700 Subject: [lustre-devel] [Iudev] proposed version change for PTLRPC GSS In-Reply-To: <553001AE.2070601@bull.net> References: <55111C81.5010009@bull.net> <551518C3.70002@bull.net> <553001AE.2070601@bull.net> Message-ID: 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 at 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 >> > 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 >> to the CC list for >> this discussion. >> >> On 2015/03/24, 3:12 AM, "Sebastien Buisson" >> > >> >> 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 >> 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 >> >> >> >> >> >> _______________________________________________ >> 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: From nathan.rutman at seagate.com Thu Apr 16 18:29:19 2015 From: nathan.rutman at seagate.com (Nathan Rutman) Date: Thu, 16 Apr 2015 18:29:19 -0000 Subject: [lustre-devel] [Iudev] proposed version change for PTLRPC GSS In-Reply-To: <551518C3.70002@bull.net> References: <55111C81.5010009@bull.net> <551518C3.70002@bull.net> Message-ID: 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 at 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" >> 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: