[lustre-devel] [Iudev] proposed version change for PTLRPC GSS
Nathan Rutman
nathan.rutman at seagate.com
Tue Apr 21 12:46:40 PDT 2015
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
>> <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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20150421/84d7e4bd/attachment.htm>
More information about the lustre-devel
mailing list