similar to: [PATCH] v2v: Further increase memory allocated to the appliance (RHBZ#1418283).

On Wed, Feb 01, 2017 at 03:53:52PM +0100, Pino Toscano wrote: > On Wednesday, 1 February 2017 13:40:17 CET Richard W.M. Jones wrote: > > In commit 08f82f2e3d6975b72340dd59f438862e152a15ef we increased the > > memory size to 800MB (on x86) so that the semodule command would work. > > > > However it has been discovered that another SELinux command takes > > large

On Wednesday, 1 February 2017 13:40:17 CET Richard W.M. Jones wrote: > In commit 08f82f2e3d6975b72340dd59f438862e152a15ef we increased the > memory size to 800MB (on x86) so that the semodule command would work. > > However it has been discovered that another SELinux command takes > large amounts of RAM (setfiles during the SELinux relabel step). > Therefore increase the memory

[This email is either empty or too large to be displayed at this time]

Argon2 is the default LUKS Password-Based Key Derivation Function (PBKDF) for some new guests such as RHEL 8.2 and Fedora. It is designed to be "memory hard", meaning that by design it requires large amounts of memory, making it expensive to brute-force. Unfortunately the default for guests which had more than a few GB of RAM at install time is to require about 1 GB of RAM to decrypt

Rewrite the relabel API to read the policy configured in the guest, invoking setfiles (added as part of the appliance, as part of policycoreutils) to relabel the specified root. In case of failure at any point of the process, a touch of .autorelabel in the root is tried as last-attempt measure to do the relabel. Considering that running SELinux tools in the appliance might be affected by the

Hi, On Wed, November 16, 2016 11:10 am, Richard W.M. Jones wrote: > >> It eventually did complete, after several hours. But I don't understand >> why this particular VM took so long when others (with similar disk >> sizes/usages/configurations) completed in only 1-2 minutes. Each VM is >> effectively exactly the same (it's a build slave), so it's just the

> -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@redhat.com] > Sent: Tuesday, March 6, 2018 11:49 AM > To: Зиновик Игорь Анатольевич <ZinovikIA@nspk.ru> > Cc: libguestfs@redhat.com > Subject: Re: [Libguestfs] virt-v2v 1.38 fails to convert .vmx VM: setfiles ... > Multiple same specifications for /.*. > > On Tue, Mar 06, 2018 at 08:40:51AM

[This email is either empty or too large to be displayed at this time]

On Wednesday, 16 May 2018 14:43:09 CEST Richard W.M. Jones wrote: > With recent Linux kernels, adding and partitioning 255 disks causes > the appliance to run out of memory. This causes a test failure in > tests/disks/test-255-disks.sh. This change gives the appliance enough > memory to complete the test. TBH raising the amount of memory only for those tests is the solution IMHO,

Hello, Richard. > -----Original Message----- > From: Richard W.M. Jones [mailto:rjones@redhat.com] > Sent: Monday, March 5, 2018 8:42 PM > To: Зиновик Игорь Анатольевич <ZinovikIA@nspk.ru> > Cc: libguestfs@redhat.com > Subject: Re: [Libguestfs] virt-v2v 1.38 fails to convert .vmx VM: setfiles ... > Multiple same specifications for /.*. > > On Mon, Mar 05, 2018 at

v1 -> v2: - Add simple test of the setfiles API. - Use SELinux_relabel module in virt-v2v (instead of touch /.autorelabel). - Small fixes. Rich.

Hi, On Thu, November 17, 2016 1:07 pm, Richard W.M. Jones wrote: > On Thu, Nov 17, 2016 at 11:06:48AM -0500, Derek Atkins wrote: >> Would you like a copy of the VMDK? If so I can figure out how to make >> it >> available to you (privately). > > I can certainly have a go. Can you post it on a website somewhere? Yep. I'll send you the URL privately. > Rich.

Use %d to parse them as int (since the variables for them as int) instead of %u, even if they both need to be at least > 0. --smp was already checked to be >= 1 while --memsize not, so check that the specified memory size is not < 128 (which is semi-arbitrary, but enough as a minimum threshold). --- rescue/rescue.c | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-)

Hi Rich, On Wed, November 16, 2016 1:34 pm, Richard W.M. Jones wrote: > On Wed, Nov 16, 2016 at 11:31:40AM -0500, Derek Atkins wrote: >> > Running `virt-v2v -v -x ...' and observing the output will give you a >> > good idea of what precisely it was doing for those hours. >> >> Well, as I said in my original email, it was hanging at running >> setfiles:

--- daemon/selinux-relabel.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) diff --git a/daemon/selinux-relabel.c b/daemon/selinux-relabel.c index 112bee1..2f48ee6 100644 --- a/daemon/selinux-relabel.c +++ b/daemon/selinux-relabel.c @@ -27,6 +27,8 @@ #include "actions.h" #include "optgroups.h" +#include "ignore-value.h" +

Continuation/rework of: https://www.redhat.com/archives/libguestfs/2020-May/msg00020.html This is my approach, as I explained here: https://bugzilla.redhat.com/show_bug.cgi?id=1828952#c4 https://www.redhat.com/archives/libguestfs/2020-May/msg00035.html IOW: do not attempt to relabel if the guest is not enforcing, as it is either useless or may fail; few words more are in the comments of patch #3.

[ I realized that we were discussing adding this feature, in various private email, IRC, and this long bugzilla thread: https://bugzilla.redhat.com/show_bug.cgi?id=1060423 That's not how we should do things. Let's discuss it on the mailing list. ] One thing that virt-customize/virt-sysprep/virt-builder have to do is relabel SELinux guests. What we do at the moment

This shows which files are being relabelled. Also only use -q (suppress non-error output) when we are not verbose. --- daemon/selinux-relabel.c | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) diff --git a/daemon/selinux-relabel.c b/daemon/selinux-relabel.c index 2f48ee6..e7da42d 100644 --- a/daemon/selinux-relabel.c +++ b/daemon/selinux-relabel.c @@ -112,8 +112,11 @@

I am doing some SELinux testing under 2.6.0-test4 on PPC with an ext3 partition. It uses the extended attributes and security labels. After using the SELinux setfiles utility, which sets all of the security labels in the filesystem, I get some strange behavior from e2fsck. When I fsck it, it gets a pair of problems with all of the symlinks on the system, like these: Symlink /usr/bin/ptx (inode

We can use the setfiles(8) command to relabel the guest filesystem, even though we don't have a policy loaded nor SELinux enabled in the appliance kernel. This also deprecates or removes the old and broken SELinux support. This patch isn't quite complete - I would like to add some tests to the new API. I'm posting here to garner early feedback. Rich.