https://jira.whamcloud.com This file is an XML representation of an issue en-us 9.4.14 940014 05-12-2023 https://jira.whamcloud.com/browse/LU-5074 Lustre <p>We need to reserve a connection flag for the Secure Data Appliance.</p> <p>A patch will be uploaded shortly.</p> <p>Thanks.</p> LU-5074

Connection flag reservation for Secure Data Appliance

Improvement Minor Resolved Won't Fix Peter Jones Andrew Perepechko patch Fri, 16 May 2014 16:19:12 +0000 Thu, 6 Sep 2018 10:08:25 +0000 Thu, 6 Sep 2018 10:08:25 +0000 Lustre 2.5.2 0 7 <p><a href="http://review.whamcloud.com/#/c/10352/" class="external-link" target="_blank" rel="nofollow noopener">http://review.whamcloud.com/#/c/10352/</a></p> <p>Can you point us to the design document for the new protocol referenced in the patch?</p> <p>Can you explain what the Secure Data Appliance is and what new Lustre protocol(s) it will require?</p> <p>Christopher, you can find additional information at <a href="http://www.xyratex.com/products/clusterstor-sda" class="external-link" target="_blank" rel="nofollow noopener">http://www.xyratex.com/products/clusterstor-sda</a></p> <p>I'm afraid I'm not entitled to expose any internal documents or the code. The wire protocol changes<br/> mentioned in the patch include additional security data transfered between SDA-aware clients and servers.</p> <p>The code will eventually need to be released as part of a GPL module in the kernel.</p> <p>On a technical front, it will be interesting to see how this resolves the issue of trusting Lustre clients. Is it implementing Kerberos and OST capabilities, or some other mechanism? </p> <p>I'm afraid that if you can't tell us anything about the protocol changes, then we can't support it in the community, Open Source version of Lustre. If you decide to make private, proprietary changes to Lustre, then the burden is entirely on you to deal with the continued maintenance implications. </p> <p>Protocol changes include the transport of additional MLS information to/from SE Linux clients, and some additional RPCs between servers. We're in a bit of a conundrum because the security accreditation we're under does not allow us to share the code, even though of course it based on Lustre which they understand is Open Source. So while are trying to figure out legally how we can do this, in the meantime to let our customers connect to our SDA version and to regular Lustre systems without conflict, we thought pushing a connect flag upstream would be the easiest and least contentious option.</p> <p>(There are of course plenty of precedents for this; the Linux kernel has all sorts of reserved flags for proprietary drivers.) </p> <p>That would certainly seem to be a troubling situation, but one that was self-inflicted. If your organization has chosen to violate Lustre's license, I'm not sure why the community should assist you in doing so.</p> <blockquote><p>(There are of course plenty of precedents for this; the Linux kernel has all sorts of reserved flags for proprietary drivers.)</p></blockquote> <p>Yes, but those are generally for things like ioctl numbers, and Linus has more-or-less taken the stance that kernel modules are not a derivative product of the kernel, and proprietary code is allowed. So avoiding ioctl conflict makes some sense in that situation.</p> <p>Lustre grants no such latitude for derivative products.</p> <p>It's just a flag, and it just as sensibly is reasonable to avoid conflicts with different versions.</p> <p>It is not just a flag; it is condoning the violation of Lustre's license. If the "different version" were to be made Free Software (Open Source), compatible with Lustre's license, and implemented in a way that could be integrated in to Lustre, then I would withdraw my objection.</p> <p>Letting this one little flag into Lustre introduces a new <em>Lustre</em> precedence that is not good for the Lustre Free Software/Open Source community.</p> <p>Would you like me to put this on the CDWG's agenda for discussion on May 21?</p> <p>I am not going to argue about licensing issues here; I will have to discuss with my management how to proceed.</p> <p>No longer relevant</p> Related LU-6784 Development Rank 1|hzwmnr: Rank (Obsolete) 14006