I like to put my entire disk or partition in cryptsetup-luks type LUKS partitions/disks. Then, I use EVMS on top of that. That way, not only are the various EVMS meta files and object sizes encrypted, but I can resize my EVMS partitions easily inside EVMS as normal without having to wait for EVMS team to support LUKS directly. To do this, one needs EVMS to recognize the cryptsetup luksOpen created device-mapper device as a device EVMS ought to look at in this way. This has to be carefully done, since you could create loops, so carefully read the email attached and specify the correct options to EVMS and DM configuration files (/etc/evms.conf and /etc/lvm/lvm.conf). It works great for me on two systems I have. This requires a patch in EVMS. It is rather simple. I modified the latest EVMS ebuild by adding someone's patch for this (since they also wanted to do it) and put it into my portage OVERLAY directory. Contained in the referenced URL (<URL:"ftp://ftp.sonic.net/pub/users/qm/gentoo/emvs.tar.7z">) is a tar that has this overlay portage ebuild and associated files. P.S., if you have trouble reading evms.tar.7z, here are some hints: file emvs.tar.7z tells you: evms.tar.7z: 7z archive data, version 0.2 emerge -s 7z tells you: * app-arch/p7zip [...] so emerge p7zip and then: 7z x -so evms.tar.7z | tar xf - Thanks.
Specified bad URL; cloned bug with correct URL. Learned how to do attachments, too.
Uhm, we certainly won't download patches in some weird format just to have a look. Attach the needed file here as *plaintext* and reopen then. Thanks.
*** Bug 115876 has been marked as a duplicate of this bug. ***
Ok. Doing now.
*** Bug 115878 has been marked as a duplicate of this bug. ***
Created attachment 74958 [details] tarball of portage overlay for evms patch
Look, bitch, I am sick and tired of you bitching about how I attach things when: 1. The bug system doesn't even show how to attach attachments when creating a new bug, 2. p7zip is the current best compression method, and 3. A fresh copy of the bug in the first place like I originally did would have taken away all of your moaning and bitching in the first place, to make this a CLEAN bug report. There is no way to edit out all your dumb comments or edit the original text of my message. If there was, then I would have done that. Stop whining! Jesus christ! This is useful for security aspects of Gentoo, mostly including the recent LUKS support Gentoo has better than other distributions. Eventually, we'd like to think that EVMS will do this, but we don't know if or when they might do it, so for now, this is the solution. Perhaps a USE option to EVMS could be implemented to engage this only when that USE value is set (what to call it? evmsdmloop?) I like to put my entire disk or partition in cryptsetup-luks type LUKS partitions/disks. Then, I use EVMS on top of that. That way, not only are the various EVMS meta files and object sizes encrypted, but I can resize my EVMS partitions easily inside EVMS as normal without having to wait for EVMS team to support LUKS directly. To do this, one needs EVMS to recognize the cryptsetup luksOpen created device-mapper device(s) as a device EVMS ought to look at in this way. This has to be carefully done, since you could create loops, so carefully read the email attached and specify the correct options to EVMS and DM configuration files (/etc/evms.conf and /etc/lvm/lvm.conf). It works great for me on two systems I have. This requires a patch in EVMS. It is rather simple. I modified the latest EVMS ebuild by adding someone's patch for this (since they also wanted to do it) and put it into my portage OVERLAY directory. Contained in the attached file is a tar that has this overlay portage ebuild and associated files. The two main different files are etc/portage/sys-fs/evms/evms-2.5.3-r1.ebuild modified to contain the patch and the patch itself, plus updated digests and manifests. Excerpts: --- evms-2.5.3-r1.ebuild.~1~ 2005-11-11 15:36:03.000000000 -0800 +++ evms-2.5.3-r1.ebuild 2005-11-25 11:16:54.000000000 -0800 @@ -27,6 +27,7 @@ cd ${S} epatch ${FILESDIR}/${PV}/compaq_segments.patch epatch ${FILESDIR}/${PV}/md_expand.patch + epatch ${FILESDIR}/${PV}/devmapper.patch } src_compile() { and etc/portage/sys-fs/evms/files/2.5.3/devmapper.patch
http://www.gentoo.org/proj/en/devrel/handbook/handbook.xml?part=2&chap=3#doc_chap2 And two additional notes: 1/ Offending developers does *not* help your cause... 2/ Read The Fine Manual if you are unfamiliar with bugzilla. At least read the comments I've made, if you actually did that, you'd not submit the dreaded tarball for the third time. We don't care for any compression, we'd like to have a way to *quickly* inspect patches from a *browser*. Reopen with a *plaintext* patch, ktnxbye.
Created attachment 74963 [details, diff] Patch to EVMS 2.5.3 to add support for layering EVMS on top of device-mapper Patches cleanly to EVMS in ebuild sys-fs/evms-2.5.3-r1: --- /etc/portage/sys-fs/evms/evms-2.5.3-r1.ebuild.~1~ 2005-11-11 15:36:03.000000000 -0800 +++ /etc/portage/sys-fs/evms/evms-2.5.3-r1.ebuild 2005-11-25 11:16:54.000000000 -0800 @@ -27,6 +27,7 @@ cd ${S} epatch ${FILESDIR}/${PV}/compaq_segments.patch epatch ${FILESDIR}/${PV}/md_expand.patch + epatch ${FILESDIR}/${PV}/devmapper.patch } src_compile() {
Well, this feels like court or beauracracy. A million steps. There was a time when help in improving and developing systems including Unix was appreciated and facilitated. It seems that time has gone. Everyone has told me I should look more into BSD because it has that old way of thinking. Unfortunately, they're more server oriented, so there is a limit to how much they will do for new requirements such as video and audio. So, now, I have come to attach a plain text patch as requested, and thus, the bug, once again, has been reopened.
Created attachment 74965 [details] portage/sys-fs/evms/files/2.5.4/dev_mapper_input.patch.gz for DM input to EVMS COMPRESSED FOR portage files EVMS 2.5.4 patch for DM input to EVMS: tested and works.
Created attachment 74966 [details] portage/sys-fs/evms/evms-2.5.4.ebuild for EVMS 2.5.4, including DM input patch While submitting a patch to Gentoo Bugzilla for EVMS, I noticed EVMS 2.5.4 is out, so am attempting a rough ebuild for that. Starting from the ebuild for EVMS 2.5.3, I found: Gentoo's portage/sys-fs/evms/files/2.5.3/compaq_segments.patch is no longer necessary for EVMS 2.5.4, since it is already fully applied to 2.5.4; not included in my 2.5.4 ebuild. Gentoo's portage/sys-fs/evms/files/2.5.3/md_expand.patch contains patches to two files: evms-2.5.3.b/plugins/md/md_main.c, which has been fully applied to EVMS 2.5.4, and evms-2.5.3.b/plugins/md/raid5_mgr.c, which was not equivilently applied in EVMS 2.5.4, but looks like the issue was resolved in a different way (I am not close enough to it to know whether that is actually the case, but it looks like it was some memory freeing bugfixing, and that looks like what both differences are). Patch not included in my 2.5.4 ebuild. So, I am removing both patches from my temporary ebuild for EVMS 2.5.4. I added a USE flag for the DM input patch I mentioned for my EVMS 2.5.4 ebuild file called "evmsdminput". Everything I tested worked: I tested my new 2.5.4 ebuild with linux-2.6.14-gentoo-r4 before rebooting. I built linux-2.6.14-gentoo-r5, tested evms, worked. Rebuilt evms, worked. Moved rebuilt evms into initrd (which had old evms), installed kernel, rebooted, worked. So, EVMS 2.5.4 seems to work with linux-2.6.14-gentoo-r4 and linux-2.6.14-gentoo-r5. Seems to work great. An updated patch for EVMS 2.5.4 for DM input was also just attached.
Created attachment 74968 [details, diff] portage/sys-fs/evms/files/2.5.4/dev_mapper_input.patch for DM input to EVMS Ooops -- Gentoo buzilla wasps want it plain text for bugzilla easy viewing. Uncompressed version put in instead. Gzip -9 for the ebuild to work.
Created attachment 74969 [details, diff] portage/sys-fs/evms/files/2.5.4/dev_mapper_input.patch for DM input to EVMS Ok, I forgot to exclude the backup files. This patch is better, and now it's small enough not to have to compress. Updated ebuild to follow.
Created attachment 74970 [details, diff] portage/sys-fs/evms/files/2.5.4/dev_mapper_input.patch for DM input to EVMS @#^&*@^#&*@!#. That patch excluded the important text comments at the head of the patch. Fixed.
Created attachment 74971 [details] portage/sys-fs/evms/evms-2.5.4.ebuild for EVMS 2.5.4, including DM input patch Corrected ebuild for evms-2.5.4 -- only difference is removing ".gz" since I now submit the uncompressed patch file since you like watching diffs in bugzilla. Don't forget to add Manifest line: MD5 27cbfb8c0fceb3be3e8991d7cb060582 files/2.5.4/dev_mapper_input.patch 12175 and do digest rebuild.
Created attachment 74973 [details, diff] portage/sys-fs/evms/evms-2.5.4.ebuild diff from evms-2.5.3-r1.ebuild Oh very cool. Bugzilla does patch diffs to the original SOURCE. That is useful. THAT would explain why you want plain text patches. YOU COULD HAVE MENTIONED THAT. (1) You should explain this when you say you want plain text diffs. (2) Bugzilla should mention this when adding attachments, so there is an incentive to add plain text diffs. I include here a diff for the ebuild I made for evms-2.5.4, so you can see the differences. I hope it works and that you enjoy it.
as the cryptsetup{-luks} maintainer I would have liked to have been cc'd into this bug. I will look into this soon and see what I can do.
well that's a suprise I never expected this to show up here :) I originally wrote the patch for use with dmraid but I guess it should work with any other dm implementation like dm-crypt A better way for crypt to be setup with evms probably would be some form of region plugin or something to that effect, as evms won't be aware of how the source disk it's setup to use is configured (it'l have no control over the encryption in the evms gui) but that'd be more complicated to do, also I'd guess you'd have to figure out how to do it more securely within the evms code perhaps but still if it works then it works I guess
Created attachment 81447 [details, diff] Updated dm input patch for EVMS 2.5.5 I updated the patch for EVMS 2.5.5. There were five or six manifestations of the devices mapped while I realized and reconciled the changes, but everything's fine now, working as before. Please make sure you have appropriate reliabilities and redundancies when upgrading to EVMS 2.5.5 if relying on this patch; my confidence is high even if you do not, but I am not 100% certain. Brad
Comment on attachment 81447 [details, diff] Updated dm input patch for EVMS 2.5.5 I updated the patch for EVMS 2.5.5. There were five or six manifestations of the devices mapped while I realized and reconciled the changes, but everything's fine. Please make sure you have appropriate reliabilities and redundancies when upgrading to EVMS 2.5.5 if relying on this patch; my confidence is high even if you do not, but I am not 100% certain. Brad P.S., to reply to the two maintainers of the code I am depending on, LUKS and the writer of this patch, at first I used LUKS partitions on top of EVMS, but there are two problems with that: 1. Resizing is difficult, because there is no LUKS plugin for EVMS. 2. Entropy is in the clear; the partition names, EVMS metadata, etc., were not inside LUKS, therefore were unencrypted. The reason for me to use this patch is that I take the entire section of the disk (an entire disk even), put it into LUKS or dm-crypt or whatever, and then create all my partitions inside of that one big LUKS/dm-crypt/whatever section, and manage all of that normally inside EVMS; no unencrypted metadata, direct EVMS interaction with partition sizes, etc., and everything runs cleanly. EVMS doesn't even need to know that LUKS exists; merely that some DM object is there that it can use, which is what this patch tells it to do.
I'm sorry, but I don't have the time/resources to maintain this patch outside of evms mainline... Please continue to push for this to get accepted into the mainline code.
