similar to: [PATCH 1/3] get-kernel: split command line handling in own function

Extract the guest kernel/ramdisk extraction from virt-builder into a separate utility, so it can be used and improved without cluttering virt-builder. Currently it does what virt-builder --get-kernel did, adding also the options for remote disks and libvirt access, much like other libguestfs tools. virt-builder --get-kernel now just spawns virt-get-kernel. --- .gitignore |

New --unversioned-names option to save extracted files just with their base name (i.e. "vmlinux", "initrd.img"). --- get-kernel/get_kernel.ml | 17 +++++++++++++---- get-kernel/virt-get-kernel.pod | 9 +++++++++ 2 files changed, 22 insertions(+), 4 deletions(-) diff --git a/get-kernel/get_kernel.ml b/get-kernel/get_kernel.ml index 646a240..1523363 100644 ---

From: Nikolay Ivanets <stenavin@gmail.com> This patch adds '--blocksize' command line option for virt-get-kernel tool. This option allows specifying disk sector size as described in 'guestfs_add_drive_opts' libguestfs API. --- get-kernel/get_kernel.ml | 22 ++++++++++++---------- get-kernel/virt-get-kernel.pod | 8 ++++++++ 2 files changed, 20 insertions(+), 10

New --prefix option to specify a prefix for the extracted file names. --- get-kernel/get_kernel.ml | 21 ++++++++++++++++----- get-kernel/virt-get-kernel.pod | 13 +++++++++++++ 2 files changed, 29 insertions(+), 5 deletions(-) diff --git a/get-kernel/get_kernel.ml b/get-kernel/get_kernel.ml index 1523363..01297f0 100644 --- a/get-kernel/get_kernel.ml +++ b/get-kernel/get_kernel.ml @@

Introduce a new common helper to add the common options for libguestfs tools (short/long options, version, verbose, trace), and sort them. All the OCaml-based tools had these options already, so there are no functional changes in the interface they provide. The only difference is that now the options are always sorted, while some tools didn't had them like that previously: because of this, a

On Fri, Jun 24, 2016 at 05:42:37PM +0200, Pino Toscano wrote: > Add a new Getopt module to mllib, to parse command line arguments with > handlers close to the ones used with Arg, but using getopt(3) (actually > getopt_long_only) to do the real parsing. This allow us to provide > options for OCaml tools with a syntax similar to the C tools, and use > the additional features getopt

--- builder/cmdline.ml | 61 +++++++-------- dib/cmdline.ml | 57 +++++++------- generator/customize.ml | 29 +++---- get-kernel/get_kernel.ml | 17 +++-- mllib/common_utils.ml | 15 ++-- mllib/getopt.ml | 121 +++++++++++++++--------------- mllib/getopt.mli

Add a new Getopt module to mllib, to parse command line arguments with handlers close to the ones used with Arg, but using getopt(3) (actually getopt_long_only) to do the real parsing. This allow us to provide options for OCaml tools with a syntax similar to the C tools, and use the additional features getopt offers and Arg does not. Do a single-step conversion of Common_utils and all the OCaml

Add a new Getopt module to mllib, to parse command line arguments with handlers close to the ones used with Arg, but using getopt(3) (actually getopt_long_only) to do the real parsing. This allow us to provide options for OCaml tools with a syntax similar to the C tools, and use the additional features getopt offers and Arg does not. Getopt now handles every part of the command line handling,

Add a new Getopt module to mllib, to parse command line arguments with handlers close to the ones used with Arg, but using getopt(3) (actually getopt_long_only) to do the real parsing. This allow us to provide options for OCaml tools with a syntax similar to the C tools, and use the additional features getopt offers and Arg does not. Do a single-step conversion of Common_utils and all the OCaml

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

Move --debug-gc as common option for all the OCaml-based tools, even a couple of them which didn't have it previously. As implementation note, make set_debug_gc private to set_standard_options, as it needed to be moved otherwise, and it is no more required as public function. --- customize/customize_main.ml | 1 - mllib/common_utils.ml | 8 ++++---- mllib/common_utils.mli | 3 ---

Several tools handle --debug-gc command-line option, by explicitly forcing GC on every exit path. This is tedious and prone to forgetting some of the exit paths. Instead, add a generic handler for --debug-gc, which installs an at_exit hook to do the GC consistency check, and which can be called right in the command-line parser. Also adjust all users of --debug-gc to use that handler.

Add a dummy description value to mark an option as "hidden", so it will not be shown in the help text. Mark few options as hidden: - common: --short-options, --long-options - virt-sysprep: --dump-pod, --dump-pod-options --- Related question: should --debug-gc be considered really internal, thus marked as such and removed from the documentations? mllib/getopt.ml | 13 ++++++++++---

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

In commit ae6f726ecc3bc1b67fd76e51a7b1e1a33d4dcfc0 we started to use the virt-customize code to replace various virt-sysprep operations. This had the effect of adding many more possible operationg to virt-sysprep, but some of them (specifically --install) did not work unless the appliance network is enabled. It was not enabled in virt-sysprep, so these operations never worked. This change

Help the OCaml compiler by expliciting Guestfs.guestfs as type for 'g' in some functions. --- get-kernel/get_kernel.ml | 2 +- sysprep/sysprep_operation_abrt_data.ml | 2 +- sysprep/sysprep_operation_bash_history.ml | 2 +- sysprep/sysprep_operation_ca_certificates.ml | 2 +- sysprep/sysprep_operation_crash_data.ml

Instead of creating Guestfs handles and manually apply common options (e.g. debug and trace), use the open_guestfs in Common_utils. This also applies the common options to handles which didn't set them before, so we can inspect also their messages if needed. --- builder/builder.ml | 8 ++------ customize/customize_main.ml | 4 +--- dib/dib.ml | 4 +---

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

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