[lustre-devel] [Iudev] proposed version change for PTLRPC GSS

[Sebastien Buisson <sebastien.buisson@atos.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
> <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
>