All solutions that involve copying the data elsewhere or restoring data don't actually solve my problem statement - Which is to encrypt with minimal downtime.
Yes, of course - I keep backups. In two different physical locations. But restoring them is actually a worst case scenario which involves days of downtime. It takes time to copy TB's of data. Even if you break a RAID 1 you're still going to have to make the other half read only or you're going to have new data on your original that doesn't make it across. And correct me if I'm wrong with the ecryptfs solution - but doesn't it leave unencrypted copies of your files in free space? Because it's not encrypting in place at a block level, some / most / many files are left unallocated but in clear text on your volume, until you later overwrite them with new data? I'll try to give another example of a use case: Imagine you take over as sysadmin for a company. You run a web based instant messenger solution, hosted off premises in someone else's VPS. eg, an OpenStack provider. The previous sysadmin has been storing logs / message history on the server disk. These are required because your web clients need to be able to query conversion history (think Facebook Messenger). It concerns you that these logs are stored in plain text, because often you have drive failures (and some are RAID 1 for performance) , and drives cannot be cleanly sanitized before they go back to the manufacturer because they are dead, and besides, are the responsibility of your Openstack provider anyway. You decide that to replicate your environment or start fresh would be too costly, and prefer an incremental approach that you test on your dev environment first. It strikes me as strange that we have kernel level APIs for abstracting blocks, we can do all this fantastic crazy stuff with LVM, yet can't do this simple operation that every other OS seems to be able to.. Imagine if Android said "sorry, you must wipe your phone first" when you turned on device encryption... On 23 April 2015 at 22:27, Andrew McGlashan < [email protected]> wrote: > On 23/04/2015 7:51 PM, Craig Sanders wrote: > > On Thu, Apr 23, 2015 at 04:59:21AM +0000, Toby Corkindale wrote: > >> find -type f crypted -exec rewrite_file \{\} \; > >> where rewrite_file does something like > >> cp $FILE tmp_file > >> rm $FILE > >> mv tmp_file $FILE > > > > if you're going to do something like this then use 'cp -a' to preserve > > file ownership, group, permissions, and timestamps. > > Yes, but rsync would be better. > > I hate it when I see "cp" without at least "cp -p" ... ;-) > > Having a 3 way RAID-1 disk set would be the way to go, take one disk out > of RAID and LUKS that disk, then add the LUKS volume back in as a RAID > component, let it sync; when done do the same for each other mirror disk > that you want to keep. > > Oh and if you are going to LUKS encrypt the root file system, then > you'll need to consider other things. I use dropbear to enter pass > phrases at boot time via ssh with "cryptsetup luksOpen ...." for each > container and then LVM to provide all the required file systems > (including root). > > A. > > _______________________________________________ > luv-main mailing list > [email protected] > http://lists.luv.asn.au/listinfo/luv-main >
_______________________________________________ luv-main mailing list [email protected] http://lists.luv.asn.au/listinfo/luv-main
