<div dir="ltr">Hi Sebastien -<div>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.</div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><b>--</b><div><font size="1"><b>Nathan Rutman · <font color="#666666">Principal Systems Architect</font><br><font color="#0b5394">Seagate Technology</font></b><b> · </b>+1 503 877-9507<b> · </b>GMT-8</font></div></div></div></div></div></div>
<br><div class="gmail_quote">On Thu, Apr 16, 2015 at 11:38 AM, Sebastien Buisson <span dir="ltr"><<a href="mailto:sebastien.buisson@atos.net" target="_blank">sebastien.buisson@atos.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Nathan,<br>
<br>
All the Kerberos related patches that are not landed yet are:<br>
LU-3778:<br>
<a href="http://review.whamcloud.com/14040" target="_blank">http://review.whamcloud.com/14040</a><br>
LU-6356:<br>
<a href="http://review.whamcloud.com/14349" target="_blank">http://review.whamcloud.com/14349</a><br>
<a href="http://review.whamcloud.com/14041" target="_blank">http://review.whamcloud.com/14041</a><br>
<a href="http://review.whamcloud.com/14042" target="_blank">http://review.whamcloud.com/14042</a><br>
<a href="http://review.whamcloud.com/14404" target="_blank">http://review.whamcloud.com/14404</a><br>
<br>
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.<br>
<br>
Best regards,<br>
Sebastien.<span class=""><br>
<br>
<br>
Le 16/04/2015 12:22, Nathan Rutman a écrit :<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Sebastien, do these patches represent all the merged Kerberos changes?<br>
Or can these be landed independently of the others?<br>
<br>
<br></span>
*--*<br>
*Nathan Rutman · Principal Systems Architect<br>
Seagate Technology** · *<a href="tel:%2B1%20503%20877-9507" value="+15038779507" target="_blank">+1 503 877-9507</a>* · *GMT-8<span class=""><br>
<br>
On Fri, Mar 27, 2015 at 1:45 AM, Sebastien Buisson<br></span><span class="">
<<a href="mailto:sebastien.buisson@atos.net" target="_blank">sebastien.buisson@atos.net</a> <mailto:<a href="mailto:sebastien.buisson@atos.net" target="_blank">sebastien.buisson@atos.net</a>>> wrote:<br>
<br>
Re-emitting because of issues with my email address.<br>
--------<br>
<br>
Hi,<br>
<br>
As I understand the need for evolutions in the GSS code, I advocate<br>
the review and merge of all patches related to Kerberos revival as<br>
soon as possible. It would avoid painful rebase of work done by IU,<br>
or Kerberos patches, or both.<br>
The Kerberos revival patches waiting for review are:<br></span>
<a href="http://review.whamcloud.com/__14040" target="_blank">http://review.whamcloud.com/__14040</a> <<a href="http://review.whamcloud.com/14040" target="_blank">http://review.whamcloud.com/14040</a>><br>
<a href="http://review.whamcloud.com/__14041" target="_blank">http://review.whamcloud.com/__14041</a> <<a href="http://review.whamcloud.com/14041" target="_blank">http://review.whamcloud.com/14041</a>><br>
<a href="http://review.whamcloud.com/__14042" target="_blank">http://review.whamcloud.com/__14042</a> <<a href="http://review.whamcloud.com/14042" target="_blank">http://review.whamcloud.com/14042</a>><span class=""><br>
<br>
Best regards,<br>
Sebastien.<br>
<br>
<br>
Le 25/03/2015 22:25, Dilger, Andreas a écrit :<br>
<br>
Sebastien,<br>
can you please also add <a href="mailto:lustre-devel@lists.lustre.org" target="_blank">lustre-devel@lists.lustre.org</a><br></span>
<mailto:<a href="mailto:lustre-devel@lists.lustre.org" target="_blank">lustre-devel@lists.lustre.org</a>> to the CC list for<span class=""><br>
this discussion.<br>
<br>
On 2015/03/24, 3:12 AM, "Sebastien Buisson"<br></span>
<<a href="mailto:sebastien.buisson@atos.net" target="_blank">sebastien.buisson@atos.net</a> <mailto:<a href="mailto:sebastien.buisson@atos.net" target="_blank">sebastien.buisson@atos.net</a>>><div><div class="h5"><br>
wrote:<br>
<br>
Hi there,<br>
<br>
I agree we should not bother with backward compatibility.<br>
Kerberos<br>
revival patches aim at Lustre 2.8, so we are good if the<br>
modifications<br>
you propose also land in 2.8.<br>
<br>
Taking advantage of the opportunity to replace<br>
handle_nullreq with<br>
subflavor specific code is really nice, as those bits are really<br>
confusing for someone who tries to understand the code.<br>
<br>
Cheers,<br>
Sebastien.<br>
<br>
<br>
Le 24/03/2015 02:34, Jeremy Filizetti a écrit :<br>
<br>
On the phone call last week we discussed an increment of the<br>
PTLRPC_GSS_VERSION to version 2 to allow some changes<br>
changes/restructuring. No one had any objections on the<br>
phone call but<br>
I wanted to send it out for wider distribution and feedback.<br>
<br>
Changing the request format would allow us to support<br>
larger GSS token<br>
sizes which today are limited (see ticket LU-3855).<br>
From what I have<br>
looked through so far the following seems to allow for<br>
larger tokens and<br>
also allow some of these changes without having to worry<br>
about backwards<br>
compatibility since it was never really "working" anyways.<br>
<br>
Change PTLRPC_GSS_VERSION to 2<br>
<br>
Enlarge GSS_CTX_INIT_MAX_LEN to something larger then<br>
1024. Ideally we<br>
would support MaxTokenSize of 64k for the largest active<br>
directory<br>
ticket: (see<br>
<br></div></div>
<a href="http://blogs.technet.com/b/__shanecothran/archive/2010/07/__16/maxtokensize-a" target="_blank">http://blogs.technet.com/b/__shanecothran/archive/2010/07/__16/maxtokensize-a</a><div><div class="h5"><br>
<<a href="http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a" target="_blank">http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a</a>><br>
nd-kerberos-token-bloat.aspx).<br>
The purpose of enlarging this is to support larger<br>
tokens. The<br>
sizeof(struct rsi) needs to remain under PAGE_SIZE right<br>
now with<br>
rsi_request calling sunrpc_cache_pipe_upcall. Since<br>
there is only one<br>
lsvcgssd process supposed to be running maybe it would<br>
be acceptable to<br>
use larger requests and just slightly modify rsi_request<br>
to incorporate<br>
must of the functionality of sunrpc_cache_pipe_upcall.<br>
<br>
To keep things simple with the lsvcgssd and continue to<br>
use a single<br>
channel proc file interface I'd like to AND the GSS<br>
subflavor onto most<br>
significant bits of lustre_svc in struct rsi. Instead<br>
of calling the<br>
inappropriately named handle_nullreq things would be<br>
changed to handle<br>
the multiple subflavors (gssnull, sk, krb5). gssnull<br>
and sk won't have<br>
a full userspace component so gss_accept_sec_context<br>
can't be called.<br>
<br>
Thoughts welcome. I'm sure I missed something along the<br>
way here but<br>
this is just what I have looked at so far.<br>
<br>
Thanks,<br>
Jeremy<br>
<br>
<br></div></div>
_________________________________________________<br>
Iudev mailing list<br>
<a href="mailto:Iudev@lists.opensfs.org" target="_blank">Iudev@lists.opensfs.org</a> <mailto:<a href="mailto:Iudev@lists.opensfs.org" target="_blank">Iudev@lists.opensfs.org</a>><br>
<a href="http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org" target="_blank">http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org</a> <<a href="http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org" target="_blank">http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org</a>><br>
<br>
_________________________________________________<br>
Iudev mailing list<br>
<a href="mailto:Iudev@lists.opensfs.org" target="_blank">Iudev@lists.opensfs.org</a> <mailto:<a href="mailto:Iudev@lists.opensfs.org" target="_blank">Iudev@lists.opensfs.org</a>><br>
<a href="http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org" target="_blank">http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org</a><br>
<<a href="http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org" target="_blank">http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org</a>><br>
<br>
<br>
<br>
Cheers, Andreas<br>
<br>
_________________________________________________<br>
Iudev mailing list<br>
<a href="mailto:Iudev@lists.opensfs.org" target="_blank">Iudev@lists.opensfs.org</a> <mailto:<a href="mailto:Iudev@lists.opensfs.org" target="_blank">Iudev@lists.opensfs.org</a>><br>
<a href="http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org" target="_blank">http://lists.opensfs.org/__listinfo.cgi/iudev-opensfs.org</a><span class=""><br>
<<a href="http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org" target="_blank">http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org</a>><br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
Iudev mailing list<br>
<a href="mailto:Iudev@lists.opensfs.org" target="_blank">Iudev@lists.opensfs.org</a><br>
<a href="http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org" target="_blank">http://lists.opensfs.org/listinfo.cgi/iudev-opensfs.org</a><br>
<br>
</span></blockquote>
</blockquote></div><br></div>