similar to: [PATCH 0/3] Simple augeas-related changes

v3: - Don't remove the LVM transform.

v2 of previous patch, which fixes some missing bits. For now I'm going to go with Pino's RHEL 7.1 patch, since it is at least smaller than this. So I'm sending this to the list just to have it archived for later. Rich.

Hi, currently /etc/shadow is edited manually when needed (i.e. when setting the password for an user), and it is not changed when removing users. Import the upstream shadow.aug (currently in their development serie, but not part of any released version yet), and use it only when the augeas version is less than a potential 1.2.1 (covering also the case when the new version is just 1.3.0). Pino

Augeas 1.7.0 was released a couple of days ago. By encouraging everyone to upgrade to this we can drop several calls to aug_transform and also our custom copies of two lenses, and a lot of related code. Rich.

Don't carry around Augeas lenses. It is fragile, since if the lens is added to upstream Augeas but the version number has not changed, then Augeas won't parse the target file at all. This specifically causes password adjustments to fail in RHEL 7.1. In future, if we need an Augeas lens, it must be added to Augeas, either upstream or as a downstream patch carried around by distros. ---

This synchronizes the embedded ocaml-augeas copy, and reimplements the augeas APIs using it (dropping all the C code). The behaviour seems unchanged, although I may have not tested all the various corner cases. Pino Toscano (5): common/mlaugeas: Synchronize with latest ocaml-augeas daemon: fix/enhance error reporting of Augeas exceptions Revert "Revert "daemon: implement

This reimplements the augeas APIs using ocaml-augeas (dropping all the C code). The behaviour seems unchanged, although I may have not tested all the various corner cases. Changes from v2: - dropped patch #1, as it was applied already (was a real bugfix) - rebased on master Pino Toscano (3): Revert "Revert "daemon: implement OptString for OCaml APIs"" daemon: move augeas

This reimplements the augeas APIs using ocaml-augeas (dropping all the C code). The behaviour seems unchanged, although I may have not tested all the various corner cases. Pino Toscano (4): daemon: fix/enhance error reporting of Augeas exceptions Revert "Revert "daemon: implement OptString for OCaml APIs"" daemon: move augeas APIs to OCaml daemon: drop usage of C

Simplify how we handle lvm.conf.

ocaml-augeas is used only by virtlibguestfs, so move it to this repository, instead of having it around in the common submodule. The removal from common will happen later. Pino Toscano (2): Bundle the ocaml-augeas library for use by libguestfs build: switch embedded copy of ocaml-augeas .gitignore | 1 + 3rdparty/ocaml-augeas/COPYING.LIB | 515

Hi, newer lvm2 releases don't have have uncommented "filter" lines, so the current way to edit lvm.conf doesn't work anymore. Instead, switch to augeas (with a "custom" len) for a cleaner and working way to set the lvm filter. Pino Toscano (3): daemon: add add_sprintf daemon: move AUGEAS_ERROR to the common header daemon: lvm-filter: use augeas for setting the

commit f59b87f7f18d9df89ff9940a317ff1fb452cbd28 breaks compile with older augeas (0.7.4). AFAIK there is no requirement for augeas 1.0 until 1.24. augeas.c: In function 'do_aug_init': augeas.c:102:38: error: 'AUG_NO_ERR_CLOSE' undeclared (first use in this function) Olaf

On Fri, Oct 18, Richard W.M. Jones wrote: > On Fri, Oct 18, 2013 at 11:15:54AM +0200, Olaf Hering wrote: > > > > commit f59b87f7f18d9df89ff9940a317ff1fb452cbd28 breaks compile with older > > augeas (0.7.4). AFAIK there is no requirement for augeas 1.0 until 1.24. > > > > augeas.c: In function 'do_aug_init': > > augeas.c:102:38: error:

Previously posted here: https://www.redhat.com/archives/libguestfs/2015-June/msg00266.html Rich.

If you've ever tried to use this option, you'll know that it didn't work well. It broke random things (probably RHBZ#1020216, definitely RHBZ#1023630), and caused random failures generally, while often not actually failing when valgrind itself found problems. This does not remove the guestfs_internal_exit API. That will instead be modified in a future commit. ---

On Monday 22 September 2014 13:50:18 Richard W.M. Jones wrote: > On Mon, Sep 22, 2014 at 10:49:42AM +0200, Pino Toscano wrote: > > The lenses in our custom path need the system lens for base > > definitions. Disabling the system path was worthless anyway, since > > our API does not allow user-specified custom paths. > > > > The only possible use for AUG_NO_STDINC

The lenses in our custom path need the system lens for base definitions. Disabling the system path was worthless anyway, since our API does not allow user-specified custom paths. The only possible use for AUG_NO_STDINC to aug-init could have been to not load the lenses right at init time loading them later; however, this is what the AUG_NO_LOAD flag (= 32) does already. --- daemon/augeas.c | 5

Hi all, I''m trying to come up with a lens for the zabbix agent config files. I find the lens language untransparent at best, so I''m struggeling to figure out what''s up. The debugging possibilities are extremely limited. Here''s what I have now: zabbix.aug: ==== (** An adjusted copy of the postfix_main module **) module Zabbix_agent = autoload xfm

Currently we are unable to properly run guestfsd (the daemon) under valgrind. Attempts to run valgrind inside the appliance have not been successful (see patch 1/7). However we desperately need better valgrind coverage of the daemon, particularly because it is doing a lot of complex parsing of program output. This has been a problem for a long time. A better way to attack this problem is to

From: "Richard W.M. Jones" <rjones at redhat.com> Check /sbin, /usr/sbin, /bin and /usr/bin to ensure that neither the directory nor the parent (eg. /usr) is a symlink, and use this directory for the virtual directory used to store guestfsd in the appliance. --- appliance/Makefile.am | 9 +++++---- configure.ac | 20 ++++++++++++++++++++ 2 files changed, 25