I’m not sure if this went (email issues at the office), so re-sending. From: Mackay, Michael At the risk of repeating myself, the POSIX file system underpinnings are not a concern – that part is understood and handled. I’m also not asking for help to solve this problem, again, to be clear. SE Linux is not an option. To summarize the point of my post: I’ve gotten what I want to work. I have a small list of code changes to make it work. I wish to find out if the Gluster community is interested in the changes. Thanks Mike From: Dustin Black [mailto:dblack@xxxxxxxxxx] I don't see how you could accomplish what you're describing purely through the gluster code. The bricks are mounted on the servers as standard local POSIX file systems, so there is always the chance that something could change the data outside of Gluster's control. This all seems overly-restrictive to me, given that your storage system should be locked-down from an administrative perspective as a best practice in the first place, limiting the risk of any brick-side corruption or in your case even writes/changes. But assuming that you have a compliance or other requirement that is forcing this configuration, why not simply mount the brick local file system as read only, and then also enable the existing Gluster read-only translator, providing two layers of protection against any writes? Of course this would also restrict any metadata actions on the Gluster side, which could be problematic for something like bitrot detection and could result in a lot of log noise, I'm guessing. And administratively someone could still get in and remount the bricks as r/w, so if you _really_ _really_ need it locked down you may also need selinux. Dustin Black, RHCA Senior Architect, Software-Defined Storage Red Hat, Inc. On Tue, Mar 21, 2017 at 10:52 AM, Mackay, Michael <mackay@xxxxxxxxxxx> wrote: Thanks for the help and advice so far. It’s difficult at times to describe what the use case is, so I’ll try here. We need to make sure that no one can write to the physical volume in any way. We want to be able to be sure that it can’t be corrupted. We know from working with Gluster that we shouldn’t access the brick directly, and that’s part of the point. We want to make it so it’s impossible to write to the volume or the brick under any circumstances. At the same time, we like Gluster’s recovery capability, so if one of two copies of the data becomes unavailable (due to failure of the host server or maintenance) the other copy will still be up and available. Essentially, the filesystem under the brick is a physically read-only disk that is set up at integration time and delivered read-only. We won’t want to change it after delivery, and (in this case for security) we want it to be immutable so we know we can rely on that data to be the same always, no matter what. All users will get data from the Gluster mount and use it, but from the beginning it would be read-only. A new deliver might have new data, or changed data, but that’s the only time it will change. I want to repeat as well that we’ve identified changes in the code baseline that allow this to work, if interested. I hope that provides the information you were looking for. Mike From: Saravanakumar Arumugam [mailto:sarumuga@xxxxxxxxxx]
On 03/21/2017 07:33 PM, Mackay, Michael wrote:
Again, it’s not just whether Gluster considers the volume to be read-only to clients, but whether the gluster brick and its underlying medium can be read-only. No, it is only Gluster consider it as a read-only voume. From: Atin Mukherjee [mailto:amukherj@xxxxxxxxxx] On Tue, Mar 21, 2017 at 6:06 PM, Mackay, Michael <mackay@xxxxxxxxxxx> wrote: Samikshan, read-only xlator is loaded at gluster server (brick) stack. so once the volume is in place, you'd need to enable read-only option using volume set and then you should be able to mount the volume which would provide you the read-only access.
~ Atin (atinm) _______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
|
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
