> Yeah. But then, if it could do an unattended boot, then someone who steals > the system isn't hindered by the encryption either. In this hypothetical situation, is securing your machine room a consideration? I suspect someone could do far worse things, destroying your entire infrastructure, that is pretty important as well, hypothetical speaking :) > "On 4 a.m. reboot, automate waking an administrator" territory. Then there's > the problem of how to get Gluster to behave and wait for the underlying > storage to be mounted before trying to use it - since as I've seen it will > just use the mountpoints without the mount. Could always take a bash script approach to start the glusterfsd service. If the /mnt/point is not encrypted (assuming writable), do not start glusterfsd, if it is, check to see if glusterfsd is running, if not, start glusterfsd. > Would the encrytion overhead noticeably decrease the speed of Gluster? Any sort of encryption operation is slow, compared to non-encrypted. So yes, you will notice a slowness if you are comparing it to a non-encrypted setup. If you are fine with performance (and it sounds like you are) you should see roughly experience the same speeds -- assuming network is not saturated, MTU setting, etc. -- Adam Brenner Computer Science, Undergraduate Student Donald Bren School of Information and Computer Sciences Research Computing Support Office of Information Technology http://www.oit.uci.edu/rcs/ University of California, Irvine www.ics.uci.edu/~aebrenne/ aebrenne at uci.edu On Thu, Sep 13, 2012 at 4:42 PM, Whit Blauvelt <whit.gluster at transpect.com> wrote: > On Thu, Sep 13, 2012 at 02:42:13PM -0700, Joshua Baker-LePain wrote: > >> I haven't, but given that Gluster runs on top of a standard FS, I >> don't see any reason why this wouldn't work. Rather than just >> Gluster on top of ext3/4/XFS, it would be Gluster on top of >> ext3/4/XFS on top of an LUKS encrypted partition. >> >> The main stumbling block I see isn't Gluster related at all, it's >> simply how to do an unattended boot of a system with an encrypted >> partition... > > Yeah. But then, if it could do an unattended boot, then someone who steals > the system isn't hindered by the encryption either. So this gets into the > "On 4 a.m. reboot, automate waking an administrator" territory. Then there's > the problem of how to get Gluster to behave and wait for the underlying > storage to be mounted before trying to use it - since as I've seen it will > just use the mountpoints without the mount. But as was kindly suggested, if > the mountpoints are subdirectories rather than / of the underlying > partitions, that will stop Gluster. > > Would the encrytion overhead noticeably decrease the speed of Gluster? > > Whit > _______________________________________________ > Gluster-users mailing list > Gluster-users at gluster.org > http://gluster.org/cgi-bin/mailman/listinfo/gluster-users >
