Its also worth noting: http://hekafs.org/ as John Mark pointed out months ago here: http://community.gluster.org/q/does-glusterfs-supports-encryption-and-compression/ -- 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 5:02 PM, Adam Brenner <aebrenne at uci.edu> wrote: >> 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 >>
