<div dir="ltr">Sebastien, do these patches represent all the merged Kerberos changes?<div>Or can these be landed independently of the others?</div><div><br></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 Fri, Mar 27, 2015 at 1:45 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">Re-emitting because of issues with my email address.<br>
--------<span class=""><br>
<br>
Hi,<br>
<br>
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.<br>
The Kerberos revival patches waiting for review are:<br>
<a href="http://review.whamcloud.com/14040" target="_blank">http://review.whamcloud.com/<u></u>14040</a><br>
<a href="http://review.whamcloud.com/14041" target="_blank">http://review.whamcloud.com/<u></u>14041</a><br>
<a href="http://review.whamcloud.com/14042" target="_blank">http://review.whamcloud.com/<u></u>14042</a><br>
<br>
Best regards,<br>
Sebastien.<br>
<br>
<br>
Le 25/03/2015 22:25, Dilger, Andreas 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,<br>
can you please also add <a href="mailto:lustre-devel@lists.lustre.org" target="_blank">lustre-devel@lists.lustre.org</a> to the CC list for<br>
this discussion.<br>
<br>
On 2015/03/24, 3:12 AM, "Sebastien Buisson" <<a href="mailto:sebastien.buisson@atos.net" target="_blank">sebastien.buisson@atos.net</a>><br>
wrote:<br>
<br>
</span><div><div class="h5"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi there,<br>
<br>
I agree we should not bother with backward compatibility. Kerberos<br>
revival patches aim at Lustre 2.8, so we are good if the modifications<br>
you propose also land in 2.8.<br>
<br>
Taking advantage of the opportunity to replace 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>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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 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 larger GSS token<br>
sizes which today are limited (see ticket LU-3855). From what I have<br>
looked through so far the following seems to allow for larger tokens and<br>
also allow some of these changes without having to worry 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 1024. Ideally we<br>
would support MaxTokenSize of 64k for the largest active directory<br>
ticket: (see<br>
<br>
<a href="http://blogs.technet.com/b/shanecothran/archive/2010/07/16/maxtokensize-a" target="_blank">http://blogs.technet.com/b/<u></u>shanecothran/archive/2010/07/<u></u>16/maxtokensize-a</a><br>
nd-kerberos-token-bloat.aspx).<br>
The purpose of enlarging this is to support larger tokens. The<br>
sizeof(struct rsi) needs to remain under PAGE_SIZE right now with<br>
rsi_request calling sunrpc_cache_pipe_upcall. Since there is only one<br>
lsvcgssd process supposed to be running maybe it would be acceptable to<br>
use larger requests and just slightly modify rsi_request to incorporate<br>
must of the functionality of sunrpc_cache_pipe_upcall.<br>
<br>
To keep things simple with the lsvcgssd and continue to use a single<br>
channel proc file interface I'd like to AND the GSS subflavor onto most<br>
significant bits of lustre_svc in struct rsi. Instead of calling the<br>
inappropriately named handle_nullreq things would be changed to handle<br>
the multiple subflavors (gssnull, sk, krb5). gssnull and sk won't have<br>
a full userspace component so gss_accept_sec_context can't be called.<br>
<br>
Thoughts welcome. I'm sure I missed something along the way here but<br>
this is just what I have looked at so far.<br>
<br>
Thanks,<br>
Jeremy<br>
<br>
<br>
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/iudev-opensfs.org</a><br>
<br>
</blockquote>
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/iudev-opensfs.org</a><br>
<br>
</blockquote>
<br>
<br></div></div>
Cheers, Andreas<br>
<br>
</blockquote><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<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/<u></u>listinfo.cgi/iudev-opensfs.org</a><br>
</div></div></blockquote></div><br></div>