search for: proc_nrs

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

This can be used to enlarge or shrink an existing partition. --- daemon/parted.c | 31 +++++++++++++++++++++++++++++++ generator/actions_core.ml | 22 ++++++++++++++++++++++ generator/proc_nr.ml | 1 + lib/MAX_PROC_NR | 2 +- 4 files changed, 55 insertions(+), 1 deletion(-) diff --git a/daemon/parted.c b/daemon/parted.c index 72e1b8420..f1205cadf 100644 ---

Split up the huge generator/actions.ml into several smaller files. Rich.

After this change the debugging output looks like this: guestfsd: enter: mount (0x1) request length 64 bytes commandrvf: stdout=n stderr=y flags=0x0 commandrvf: udevadm --debug settle -E /dev/sda1 calling: settle command: mount '/dev/sda1' '/sysroot//' [ 0.951731] EXT4-fs (sda1): mounting ext2 file system using the ext4 subsystem [ 0.954585] EXT4-fs (sda1):

The existing mechanism was clunky, slow and used ~ 10 MB of local disk. Rich.

By splitting up large C files we can make parallel compiles a bit faster. Rich.

The yara_destroy API allows to claim resources back via the removal of the previously loaded Yara rules. Signed-off-by: Matteo Cafasso <noxdafox@gmail.com> --- daemon/yara.c | 14 ++++++++++++++ generator/actions_yara.ml | 8 ++++++++ generator/proc_nr.ml | 1 + lib/MAX_PROC_NR | 2 +- 4 files changed, 24 insertions(+), 1 deletion(-) diff --git

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

On Sat, Jul 29, 2017 at 08:51:04PM +0300, Nikos Skalkotos wrote: > This can be used to enlarge or shrink an existing partition. > --- > daemon/parted.c | 31 +++++++++++++++++++++++++++++++ > generator/actions_core.ml | 22 ++++++++++++++++++++++ > generator/proc_nr.ml | 1 + > lib/MAX_PROC_NR | 2 +- > 4 files changed, 55 insertions(+), 1

Allow reading and setting the GPT partition attribute flags. --- daemon/parted.ml | 23 +++++++++++++++++++++++ daemon/parted.mli | 2 ++ generator/actions_core.ml | 37 +++++++++++++++++++++++++++++++++++++ generator/proc_nr.ml | 2 ++ lib/MAX_PROC_NR | 2 +- 5 files changed, 65 insertions(+), 1 deletion(-) diff --git a/daemon/parted.ml b/daemon/parted.ml

Allow reading and setting the GPT partition attribute flags. --- daemon/parted.ml | 23 +++++++++++++++++++++++ daemon/parted.mli | 3 +++ generator/actions_core.ml | 37 +++++++++++++++++++++++++++++++++++++ generator/proc_nr.ml | 2 ++ lib/MAX_PROC_NR | 2 +- 5 files changed, 66 insertions(+), 1 deletion(-) diff --git a/daemon/parted.ml b/daemon/parted.ml

Allow reading and setting the GPT partition attribute flags. --- daemon/parted.ml | 18 +++++++++++++++++- daemon/parted.mli | 3 +++ generator/actions_core.ml | 40 ++++++++++++++++++++++++++++++++++++++++ generator/proc_nr.ml | 2 ++ lib/MAX_PROC_NR | 2 +- 5 files changed, 63 insertions(+), 2 deletions(-) diff --git a/daemon/parted.ml b/daemon/parted.ml

Rebase patches on top of 1.37.1. No changes since last series. Matteo Cafasso (7): daemon: expose file upload logic appliance: add yara dependency New API: yara_load New API: yara_destroy New API: internal_yara_scan New API: yara_scan yara_scan: added API tests appliance/packagelist.in | 4 + configure.ac | 1 + daemon/Makefile.am

Although the commit message ties this to https://bugzilla.redhat.com/1804207, in fact I believe this commit could be applied independently. It's a simple optimization. Rich.

The old vgscan API literally ran vgscan. When we switched to using lvmetad (in commit dd162d2cd56a2ecf4bcd40a7f463940eaac875b8) this stopped working because lvmetad now ignores plain vgscan commands without the --cache option. We documented that vgscan would rescan PVs, VGs and LVs, but without activating them. I have introduced a new API (lvm_scan) which scans or rescans PVs, VGs and LVs. It

The internal_yara_scan runs the Yara engine with the previously loaded rules against the given file. For each rule matching against the scanned file, a struct containing the file name and the rule identifier is returned. The gathered list of yara_detection structs is serialised into XDR format and written to a file. Signed-off-by: Matteo Cafasso <noxdafox@gmail.com> --- daemon/yara.c

The internal_yara_scan runs the Yara engine with the previously loaded rules against the given file. For each rule matching against the scanned file, a struct containing the file name and the rule identifier is returned. The gathered list of yara_detection structs is serialised into XDR format and written to a file. Signed-off-by: Matteo Cafasso <noxdafox@gmail.com> --- daemon/yara.c

The internal_yara_scan runs the Yara engine with the previously loaded rules against the given file. For each rule matching against the scanned file, a struct containing the file name and the rule identifier is returned. The gathered list of yara_detection structs is serialised into XDR format and written to a file. Signed-off-by: Matteo Cafasso <noxdafox@gmail.com> --- daemon/yara.c

v6: - use new test functions - fix yara_detection struct field names - revert yara_load function to initial version With Pino we were exploring the idea of allowing Users to load multiple rule files with subsequent calls to yara_load API. https://www.redhat.com/archives/libguestfs/2016-November/msg00119.html It turns out impractical due to YARA API limitations. It is possible to load multiple

v9: - fixes according to comments Matteo Cafasso (7): daemon: expose file upload logic appliance: add yara dependency New API: yara_load New API: yara_destroy New API: internal_yara_scan New API: yara_scan yara_scan: added API tests appliance/packagelist.in | 4 + configure.ac | 1 + daemon/Makefile.am | 4 +-