From mboxrd@z Thu Jan 1 00:00:00 1970 From: 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> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: lustre-devel@lists.lustre.org 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 >