similar to: [PATCH 0/2] RFC: --key option for tools

Store the machine-readable flag globally, just like done for verbose/debug/etc, and enhance create_standard_options to provide --machine-readable automatically. --- common/mlstdutils/std_utils.ml | 4 ++++ common/mlstdutils/std_utils.mli | 7 +++++-- common/mltools/tools_utils.ml | 7 ++++++- common/mltools/tools_utils.mli | 5 ++++- 4 files changed, 19 insertions(+), 4 deletions(-) diff

Hi, this is a first approach (hence RFC, since it misses tests & documentation) in selecting the output for --machine-readable. The possible choices are: * --machine-readable: to stdout, like before * --machine-readable=file:name-of-file: to the specified file * --machine-readable=stream:stdout: explicitly to stdout * --machine-readable=stream:stderr: explicitly to stderr This makes it

Hi, this adds the possibility to select the output for --machine-readable in OCaml tools. The possible choices are: * --machine-readable: to stdout, like before * --machine-readable=file:name-of-file: to the specified file * --machine-readable=stream:stdout: explicitly to stdout * --machine-readable=stream:stderr: explicitly to stderr This makes it possible to add additional output for

Hi, this series refactors some guestfish code (not much), and exposes it via Common_utils, so it is possible to decrypt LUKS partitions when using virt-customize, virt-get-kernel, virt-sparsify, and virt-sysprep. This brings them closer in features with C tools. Most probably a couple more of other OCaml-based tools (virt-v2v to convert encrypted guests, and virt-builder to use encrypted

On Wed, Sep 19, 2018 at 12:37:00PM +0200, Pino Toscano wrote: > diff --git a/common/mltools/tools_utils.mli b/common/mltools/tools_utils.mli > index 2b8c2b78a..99984bfa1 100644 > --- a/common/mltools/tools_utils.mli > +++ b/common/mltools/tools_utils.mli > @@ -74,7 +74,13 @@ val machine_readable : unit -> machine_readable_fn option > readable output to, in case it was

Enhance the output in machine parseable mode, by outputting all the messages of OCaml tools as JSON to the machine parseable stream. Related, although not strictly needed for this (and thus can be split if requested), is the addition of the fd format for the machine readable stream. Changes from v1: - use Obj.magic to convert int -> Unix.file_descr - add tests Pino Toscano (4):

In case a repository of virt-builder references files (e.g. the index) that cannot be downloaded (network issues, 404, etc) then virt-builder errors out on this situation. This is not a nice situation, from an user POV. This series does some refactoring to allow to better handle downloading failures, and handle the failures gracefully in virt-builder. RFC because I'm not yet too convinced

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

Enhance the output in machine parseable mode, by outputting all the messages of OCaml tools as JSON to the machine parseable stream. Related, although not strictly needed for this (and thus can be split if requested), is the addition of the fd format for the machine readable stream. Pino Toscano (4): common/mltools: move the code for machine readable up common/mltools: make sure machine

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

--- mltools/tools_utils-c.c | 8 ++++---- mltools/tools_utils.ml | 6 +++--- mltools/tools_utils.mli | 8 ++++++-- options/decrypt.c | 5 +++-- options/inspect.c | 2 +- options/options.h | 2 +- 6 files changed, 18 insertions(+), 13 deletions(-) diff --git a/mltools/tools_utils-c.c b/mltools/tools_utils-c.c index 6c43b8d..1dcebc4 100644 --- a/mltools/tools_utils-c.c +++

Make use of the additional command line arguments, and API needed to decrypt LUKS partitions. This extends to v2v the work done in other OCaml tools with commit 6b26a0cce4f1d6264bee88902b8931e39288c901, since it seems to be working fine after a basic testing. Related to: RHBZ#1362649 --- v2v/cmdline.ml | 2 +- v2v/v2v.ml | 3 +++ v2v/virt-v2v.pod | 20 ++++++++++++++++++++ 3 files

The majority of the tools have already options (--echo-keys & --keys-from-stdin) to deal with LUKS credentials, although there is no way to automatically provide credentials. --keys-from-stdin is suboptimal, because it is an usable solution only when there is just one device to open, and no other input passed via stdin to the tool (like the commands for guestfish). To overcome this

Introduce a new type of option with an optional string argument. --- common/mltools/getopt-c.c | 20 +++++++++++++++++++- common/mltools/getopt.ml | 5 ++++- common/mltools/getopt.mli | 4 ++++ common/mltools/getopt_tests.ml | 18 +++++++++++++++++- common/mltools/test-getopt.sh | 11 +++++++++++ 5 files changed, 55 insertions(+), 3 deletions(-) diff --git

Support transparent decryption/inspection of Windows guests encrypted with BitLocker encryption. This won't make much sense without the associated libguestfs patches which I will post momentarily. (Submodules, ho hum) Rich.

For links to the original patch series, see: https://bugzilla.redhat.com/show_bug.cgi?id=1808977#c8 The original feedback was that ignoring errors from guestfs_luks_uuid would ignore legitimate errors from non-BitLocker disks, so I have modified this series so that errors are only ignored in the BitLocker case. As noted in the 4th patch there is no actual error in the BitLocker case, cryptsetup

Miscellaneous refactoring, but the main one is to rename mllib/ as common/mltools/ Rich.

Instead of returning directly a Getopt.t handle, now Tools_utils.create_standard_options returns a struct, which at the moment contains only the Getopt.t handle. This way, it will be easy to add more data needed for handling standard command line options. This is mostly refactoring, with no functional changes. --- builder/cmdline.ml | 2 +- builder/repository_main.ml

In Std_utils we already extend Char and String. These commits take it a little further by extending List and adding a new Option submodule. All basically simple refactoring. Rich.

v2 -> v3: - Renamed List.assoc_ -> List.assoc_lbl. - Rebased on top of current master branch. Rich.