search for: lukly

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506 This small set covers the new /dev/mapper/VG-LV "--key" ID format in the libguestfs LUKS-on-LVM inspection test. Thanks, Laszlo Laszlo Ersek (3): update common submodule LUKS-on-LVM inspection test: rename VGs and LVs LUKS-on-LVM inspection test: test /dev/mapper/VG-LV translation common

I'm sorry, but grep -i crypt /var/log/anaconda/anaconda.program.log returns nothing. But I have got an entry in /etc/crypttab. I only found this with grep -i luks /var/log/anaconda/anaconda.*: /var/log/anaconda/anaconda.storage.log:20:47:55,959 DEBUG blivet: LUKS.__init__: /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui: LUKS.__init__:

On Fri, May 19, 2023 at 04:08:49PM +0200, Laszlo Ersek wrote: > In the LUKS-on-LVM inspection test, call the "check_filesystems" function > yet another time, now with such "--key" options that exercise the recent > "/dev/mapper/VG-LV" -> "/dev/VG/LV" translation (unescaping) from > libguestfs-common. > > Bugzilla:

Requires this series: https://www.redhat.com/archives/libguestfs/2019-November/msg00036.html

This combined patch series enables to decrypt LUKS devices on inspection by allowing the UUID of the LUKS device with the --key syntax. I opted for reusing the option instead of adding another one, as I think that device names and UUIDs are different enough that can be properly distinguished. A test for this (patch #4) can be applied only when the patches for common are applied, and the

Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=2168506 This small set covers the new /dev/mapper/VG-LV "--key" ID format in the LUKS-on-LVM virt-inspector test. Thanks, Laszlo Laszlo Ersek (3): update common submodule inspector: rename VGs and LVs in LUKS-on-LVM test inspector: test /dev/mapper/VG-LV translation in LUKS-on-LVM test common

Test both the decryption by device name, and UUID. --- tests/luks/Makefile.am | 3 +- tests/luks/test-key-option-inspect.sh | 48 +++++++++++++++++++++++++++ 2 files changed, 50 insertions(+), 1 deletion(-) create mode 100755 tests/luks/test-key-option-inspect.sh diff --git a/tests/luks/Makefile.am b/tests/luks/Makefile.am index 30c817f87..2330ed72f 100644 ---

On Fri, Nov 29, 2019 at 12:21:57PM +0100, Pino Toscano wrote: > Test both the decryption by device name, and UUID. > --- > tests/luks/Makefile.am | 3 +- > tests/luks/test-key-option-inspect.sh | 48 +++++++++++++++++++++++++++ > 2 files changed, 50 insertions(+), 1 deletion(-) > create mode 100755 tests/luks/test-key-option-inspect.sh > > diff --git

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

This commit deprecates luks-open/luks-open-ro/luks-close for the more generic sounding names cryptsetup-open/cryptsetup-close, which also correspond directly to the cryptsetup commands. The optional cryptsetup-open readonly flag is used to replace the functionality of luks-open-ro. The optional cryptsetup-open crypttype parameter can be used to select the type (corresponding to cryptsetup open

The following patch attempts to implement sparsification of LUKS-encrypted partitions. It uses lsblk to pair the underlying LUKS block device with its mapped name. Also, --allow-discards was added by default to luks_open(). There are several potential issues that I can think of: 1) If and entire device is encrypted (not just one of more partitions), the lsblk trick might not work. 2) The

Also, if you want to use deduplication (via VDO) then you must remember to "dedupe then encrypt" Storage > LUKS > VDO > LVM old but good reference to: https://access.redhat.com/articles/2106521 On Tue, Jun 16, 2020 at 3:00 PM Jason Edgecombe <jwedgeco at uncc.edu> wrote: > > I recommend having LUKS be "under" LVM. the layers would be: > /dev/sda ->

Hi all, with regard to LUKS; should it placed before LVM or after? Any recommendations? TRIM command fully supported through all layers etc? -- Leon

These commits, along with the associated changes to common: https://www.redhat.com/archives/libguestfs/2020-March/msg00286.html support the transparent decryption and inspection of Windows guests encrypted with BitLocker encryption. To do the BitLocker decryption requires cryptsetup 2.3.0 (although cryptsetup 2.3 is not required for existing LUKS use). It also requires a new-ish Linux kernel, I

I wonder if it is possible to set up an encrypted "file container" on a CentOS VPS? I am the root user of the VPS but the hosting company also has access to the VPS and thus all files. Is it possible to create a LUKS-container on the VPS and those files only be accessible by me? IOW, most of the file system on the VPS would be regular file system but the container could be used by me as

Hi Chris, thanks for your answer. It is the first time I decided to encrypt my lvm. I choosed to encrypt the volume group, not every logical volume itself, because in case of doing lvm snapshots in that group they will be encrypted too? And how do I create a new encrypted volume group? Regards Tim Am 6. M?rz 2015 01:58:23 MEZ, schrieb Chris Murphy <lists at colorremedies.com>: >On

Original version linked from here: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 There is no change in the code in this series, but feedback from the original series was we shouldn't lose the error message in patch 7. When I tested this just now in fact we don't lose the error if debugging is enabled, but I have updated the commit message to note what the error message is in the

I have existing systems with un-encrypted disks. I have tried unsuccessfully to encrypt them using LUKS. Has anyone out there been able to encrypt an existing system (after the fact, so to speak)? TIA -- Roger Wells, P.E. leidos 221 Third St Newport, RI 02840 401-847-4210 (voice) 401-849-1585 (fax) roger.k.wells at leidos.com

Leon Fauster wrote: >> Am 20.06.2017 um 16:53 schrieb m.roth at 5-cent.us: >> >> Upgraded a RAID. Copied everything from backup. >> >> And then my manager said I had to encrypt the drive. >> >> I've done that, and made the filesystem, but I can't mount it. >> >> CentOS 6. >> I have the entry in /etc/crypttab, and a key in

Is "luks-format" supposed to work with guestfish? Like guestfish <<EOF luks-format /dev/sda4 0 EOF Appearently it lacks an option to give the passphrase programmatically. Was this option skipped on purpose? Olaf