search for: keyslots

...hortdesc = "change the master volume key on a LUKS partition"; + longdesc = "\ +This reencrypts a LUKS device with a new random master volume key, +using the L<cryptsetup-reencrypt(8)> tool. A new passphrase C<key> +is added in key slot C<keyslot>, and all other keyslots are erased. + +With no optional parameters, the same type of cipher is used. To +change to a different cipher, supply the optional C<cipher> parameter. + +This command has to rewrite the entire C<device>, and so is both +long running and will destroy all the data on the device if the +...

...ncryption. Does some JSON reformatting and is otherwise very opaque. A disk from a VM which is using LUKS + NBDE will have a Clevis keyslot, shown in luksDump output: # cryptsetup luksDump /dev/sda2 ... Tokens: 0: clevis Keyslot: 1 It will also usually have one or more regular keyslots, since a guest which uses NBDE can also be booted disconnected from the trusted network using a regular passphrase at the keyboard. There's an obscure sequence of commands which can be used (when on the trusted network of course) to unlock the disk: Clevis token...

The changes since the previous patch: - safe ADD_ARG macro for adding arguments to a fixed size stack array - support for testing functions that return RHashtable, ie. tune2fs-l. - add tests that set (tune2fs) and get (tune2fs-l) various parameters. - only one 'intervalbetweenchecks' parameter (in seconds) Rich.

From: "Richard W.M. Jones" <rjones at redhat.com> Callers are supposed to use the availability API to check for functions that may not be available in particular builds of libguestfs. If they don't do this, currently they tend to get obscure error messages, eg: libguestfs: error: zerofree: /dev/vda1: zerofree: No such file or directory This commit changes the error

Return the UUID of a LUKS device. --- daemon/luks.c | 25 +++++++++++++++++++++++++ generator/actions_core.ml | 8 ++++++++ generator/proc_nr.ml | 1 + lib/MAX_PROC_NR | 2 +- 4 files changed, 35 insertions(+), 1 deletion(-) diff --git a/daemon/luks.c b/daemon/luks.c index 5c48a91eb..d631cb100 100644 --- a/daemon/luks.c +++ b/daemon/luks.c @@ -292,3 +292,28 @@

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

On Mon, Jan 20, 2014 at 04:39:42PM +0100, Olaf Hering wrote: > > 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? The underlying API takes a passphrase parameter, ie:

Fix for: https://bugzilla.redhat.com/show_bug.cgi?id=619793 Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones New in Fedora 11: Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 70 libraries supprt'd http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw -------------- next part

I'm currently working on gobject bindings for libguestfs. I haven't got as far as compiling anything yet, but I've attached the C header for initial review. Matt -- Matthew Booth, RHCA, RHCSS Red Hat Engineering, Virtualisation Team GPG ID: D33C3490 GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490 -------------- next part -------------- An embedded and

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

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

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

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

As discussed in the emails today, this is the third version addressing most points from the v1/v2 review. You will need to pair this with the changes in libguestfs-common from this series: https://www.redhat.com/archives/libguestfs/2020-September/msg00050.html Rich.

Previously we had lots of types like String, Device, StringList, DeviceList, etc. where Device was just a String with magical properties (but only inside the daemon), and DeviceList was just a list of Device strings. Replace these with some simple top-level types: String StringList and move the magic into a subtype. The change is mechanical, for example: old

Very large but mechanical change to the generator. Rich.

- fix names of arguments & optional arguments in C<..> markers - use https for URLs where possible - fix links to other guestfs APIs - use more C<..> markers for special tests, shell commands, values of arguments, and names of fields - link to command man pages where an explicit command is mentioned - fix few incorrect documentation bits --- generator/actions_augeas.ml

This is a follow-up to the other generator changes in: https://www.redhat.com/archives/libguestfs/2017-February/msg00217.html Rich.

guestfsd calls many different tools. Keeping track of all of them is error prone. This patch introduces a new helper macro to put the command string into its own ELF section: GUESTFSD_EXT_CMD(C_variable, command_name); This syntax makes it still possible to grep for used command names. The actual usage of the collected list could be like this: objcopy -j .guestfsd_ext_cmds -O binary