[lustre-devel] [Iudev] proposed version change for PTLRPC GSS
Sebastien Buisson
sebastien.buisson at atos.net
Thu Apr 16 11:38:38 PDT 2015
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 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/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 at 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 at 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 at 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 at 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 at 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
>
More information about the lustre-devel
mailing list