search for: luk

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 | 2 +- test-data/phony-guests/make-fedora-i...

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__: /var/log/anaconda/anaconda.storage.log:20:49:25,009 DEBUG storage.ui: getFormat('lu...

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 t...

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 | 2 +- inspector/test-virt-inspector-luk...

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..2330...

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 a/tests/luks/Makefile.am b/tests/luks/Makefile...

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 pa...

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 pa...

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...

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 -> partition (/dev/sda1) -&...

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

...ges 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 believe 5.3+ This starts by adding new APIs cryptsetup-open and cryptsetup-close. As well as dropping the "luks-" prefix, this allows specifying an optional type parameter, allowing you to select BitLocker encryption. Although also the n...

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 needed. This would allow the VPS to reboot normally, I could ssh in normally etc etc. I would rsync files as needed to this L...

...is according to the existing encryption >so that it will be decrypted by the same passphrase I use at startup? > >http://linux.die.net/man/5/crypttab > >When you create a new entry in crypttab, you can use the 3rd field to >point to a file that contains the passphrase for this new LUKS volume. >In effect, one passphrase gives access to both drives. > >So there's a pro con here. Pro is that you could actually opt for a >completely different passphrase for the 2nd drive, but never have to >directly type it in. The con is that should you forget this >passphras...

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

...verything 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 /etc/crypt.pw, and the >> luks UUID in /etc/fstab. I cannot find the command that tells it to >> create the device in /dev/mapper from the info in /etc/crypttab. >> >> Clues for the poor? Yes, the server will, at some point in the future, >> go to CentOS 7, but that needs my user to be off for a while, a...

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