search for: key_options

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

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

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

Expose via Common_utils the C functions & variables (part of guestfish) that handle decryption of LUKS partitions, and the additional command line arguments to tune the way they work. This way it will be easy to provide (basic) crypto support also in OCaml-based tools. Related to: RHBZ#1362649 --- mllib/Makefile.am | 3 ++ mllib/common_utils-c.c | 75

...char line[8192], *file; int authenticated; u_int bits; FILE *f; @@ -179,11 +179,11 @@ * found, perform a challenge-response dialog to verify that the * user really has the corresponding private key. */ while (fgets(line, sizeof(line), f)) { char *cp; - char *options; + char *key_options; linenum++; /* Skip leading whitespace, empty and comment lines. */ for (cp = line; *cp == ' ' || *cp == '\t'; cp++) @@ -197,19 +197,19 @@ * for now. If there are no options, set the starting * address to NULL. */ if (*cp < '0' || *cp > ...

Make use of the additional command line arguments, and API needed to decrypt LUKS partitions. This affects only virt-customize, virt-get-kernel, virt-sparsify, and virt-sysprep, as they are the main OCaml tools interacting with user-provided images. --- customize/customize_main.ml | 5 ++++- customize/virt-customize.pod | 12 ++++++++++++ get-kernel/get_kernel.ml | 5 ++++-

Hi, the following series adds a --key option in the majority of tools: this makes it possible to pass LUKS credentials programmatically, avoid the need to manually input them, or unsafely pass them via stdin. Thanks, Pino Toscano (2): mltools: create a cmdline_options struct Introduce a --key option in tools that accept keys builder/cmdline.ml | 2 +-

I have hinted in the past of wanting to go to a more selective control of the output of rsync. Here it is. PROBLEMS with the existing --verbose et al. The simple incrementing verbose doesn't allow one to restrict stdout to what actually is of interest. For instance inside dirvish i don't care about directories, or any kind of non-regular file because they show up every time even if

Make use of the helper provided by Tools_utils.create_standard_options, so there is no need to implement the logic in each tool. This affects all the OCaml tools with --machine-readable, namely: virt-builder, virt-builder-repository, virt-dib, virt-get-kernel, virt-resize, virt-sparsify, and virt-v2v. --- builder/cmdline.ml | 8 ++------ builder/repository_main.ml | 6 ++----

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

Add an optional argument for --machine-readable to select the output, adding a new function to specifically write data to that output stream. 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 Adapt all

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

https://bugzilla.mindrot.org/show_bug.cgi?id=1765 Summary: Error message if key not first in authorized_keys file Product: Portable OpenSSH Version: 5.5p1 Platform: Other OS/Version: Linux Status: NEW Severity: normal Priority: P2 Component: sshd AssignedTo: unassigned-bugs at mindrot.org

Split most of the code from external_command to a new external_command_code, so it is possible to get the exit code of the process without considering it fatal. --- common/mltools/tools_utils.ml | 22 ++++++++++------------ common/mltools/tools_utils.mli | 8 ++++++++ 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/common/mltools/tools_utils.ml b/common/mltools/tools_utils.ml

Allow to specify a file descriptor for the machine readable output. Use the same assumption as done in v2v, i.e. that Unix.file_descr is simply the int file descriptor. --- common/mltools/test-machine-readable.sh | 7 +++++++ common/mltools/tools_utils.ml | 11 ++++++++++- lib/guestfs.pod | 5 +++++ 3 files changed, 22 insertions(+), 1 deletion(-) diff --git

Allow to specify a file descriptor for the machine readable output. Sadly, the OCaml C glue for the channels is not public API, so enable the internals for this... --- common/mltools/tools_utils-c.c | 17 +++++++++++++++++ common/mltools/tools_utils.ml | 10 +++++++++- lib/guestfs.pod | 5 +++++ 3 files changed, 31 insertions(+), 1 deletion(-) diff --git

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

Add an optional argument for --machine-readable to select the output, adding a new function to specifically write data to that output stream. 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 Adapt all

On Wed, Jan 16, 2019 at 03:17:32PM +0100, Pino Toscano wrote: > Split most of the code from external_command to a new > external_command_code, so it is possible to get the exit code of the > process without considering it fatal. > --- > common/mltools/tools_utils.ml | 22 ++++++++++------------ > common/mltools/tools_utils.mli | 8 ++++++++ > 2 files changed, 18