Run shadow-utils inside the chroot to avoid contradictory configurations

[mhjacks]

This is the suggestion that @sgallagher offered; I tested this on a FreeIPA-enrolled system and it worked.
I'm a bit nervous about the comment above the line about old shadow-utils being problematic; but we definitely also have the case where shadow-utils config from the host "leaks" into the chroot. I'm not sure which problem is bigger.

[sgallagher]

FWIW, I think the comment there refers mostly to whether the version of shadow-utils in the container supported the --root option, which it probably didn't if we were building for an old RHEL release. I'm 99% sure that all non-EOL RHEL systems have that feature at this point.

[mhjacks]

That's good to know. This approach specifically avoids using the --root option now because of the "leaking" problem discussed above. Thanks for the feedback!

[mhjacks]

This is pursuant to our Slack discussion of how to handle this - I know the full patch would need documentation in the defaults file and probably tests as well. Since the buildroot object has the config dict, we can look it up there.

The way this is structured, the default case would be to use the host's shadow-utils, and then only if the explicit configuration is set to use the chroot's would the chroot's utils be used. I'm definitely open to more idiomatic ways to express it but that's the intention.

[praiskup]

Thank you for your work on this, @mhjacks.

• can you please specify the default value in config.py?
• use_chroot_shadow_utils should be also documented in ./mock/docs/site-defaults.cfg
• it would be nice to have a new releng/release-notes-next/*.feature markdown entry documenting the change.

Note that Mock no longer installs shadow-utils into the minimal buildroot as it used to, this has changed in a34d3ae. Mock never installed shadow-utils into the bootstrap chroot explicitly.
bootstrap typically only contains dnf and its dependencies. But since this is opt-in, I think it is just fine to depend on an implicit set of packages.

[praiskup]

FWIW, I think the comment there refers mostly to whether the version of shadow-utils in the container supported the --root option, which it probably didn't if we were building for an old RHEL release. I'm 99% sure that all non-EOL RHEL systems have that feature at this point.

There only used to be nuance between -N and -n option, see the 4.0 release notes. But indeed, this is no longer the case for non-EOL RHEL systems.

Mock never used --prefix with shadow-utils from bootstrap, and never used ShadoUtils' --root at all. That's because --root seems to be broken even on recent distributions.

The reasoning behind the "on host decision" is that Mock upstream expects that the machines that are used by users for Mock builds are "new enough". Ideally Fedora builders, or the latest RHEL releases (users should start moving builders out from RHEL8 definitely). Then, using the tooling "on host" is much more predictable (and fixable) for the builder machine administrator) then relying on various in-chroot tooling versions (one machine typically builds for different distributions, and builder admins are unlikely to have rights to fix the target buildroots).

[mhjacks]

Converting to draft to add the other items you requested. Thanks for the review!

[praiskup]

Thank you!