Details
-
Improvement
-
Resolution: Won't Fix
-
Minor
-
None
-
Lustre 2.5.2
-
14006
Description
We need to reserve a connection flag for the Secure Data Appliance.
A patch will be uploaded shortly.
Thanks.
Attachments
Issue Links
- is related to
-
LU-6784 Defects in SELinux support
-
- Resolved
-
Activity
I am not going to argue about licensing issues here; I will have to discuss with my management how to proceed.
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.
Letting this one little flag into Lustre introduces a new Lustre precedence that is not good for the Lustre Free Software/Open Source community.
Would you like me to put this on the CDWG's agenda for discussion on May 21?
It's just a flag, and it just as sensibly is reasonable to avoid conflicts with different versions.
(There are of course plenty of precedents for this; the Linux kernel has all sorts of reserved flags for proprietary drivers.)
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.
Lustre grants no such latitude for derivative products.
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.
(There are of course plenty of precedents for this; the Linux kernel has all sorts of reserved flags for proprietary drivers.)
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.
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.
The code will eventually need to be released as part of a GPL module in the kernel.
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?
No longer relevant