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

[Nathan Rutman]

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" <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
>>>> 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: <http://lists.lustre.org/pipermail/lustre-devel-lustre.org/attachments/20150416/437565ab/attachment.htm>