NetworkManager that is called via dbus by nmcli or nmtui from chrooted %post script is not running in chroot, so ifcfg scripts in installer (and NetworkManager) root are actually changed [1]. To workaround this it could be possible to use another --nochroot %post script that would copy modified ifcfg scripts from installer environment (/etc/sysconfig/network-scripts/ifcfg-*) to target system root (/mnt/sysimage/etc/sysconfig/network-scripts/).

[1] They are copied to chroot (/mnt/sysimage) at the end of installation before the %post scripts are run

(In reply to Radek Vykydal from comment #1)
> NetworkManager that is called via dbus by nmcli or nmtui from chrooted %post
> script is not running in chroot, so ifcfg scripts in installer (and
> NetworkManager) root are actually changed [1]. To workaround this it could
> be possible to use another --nochroot %post script that would copy modified
> ifcfg scripts from installer environment
> (/etc/sysconfig/network-scripts/ifcfg-*) to target system root
> (/mnt/sysimage/etc/sysconfig/network-scripts/).
 
Other option would be to run the whole script as %post --nochroot but that would work only with nmcli which is present in installer image (NetworkManager-tui is not).

It would be nice to have offline mode for modifying connections with nmcli (eg in installer %post scripts in chroot). Reassigning for consideration to NM.

Yes, such a feature makes sense, and similar ideas already float around.

Rename bug.

See also: https://bugzilla.redhat.com/show_bug.cgi?id=1164677#c12

(In reply to Radek Vykydal from comment #5)
> It would be nice to have offline mode for modifying connections with nmcli
> (eg in installer %post scripts in chroot). Reassigning for consideration to
> NM.

Actually, we take a standard USB image, squirt it into a loopback device, mount it, and then a customization script inside chroot.

The one thing we've not figured out how to do is make offline config changes via nmcli inside the chroot.

Seems nmcli wants to talk to the host's NetworkManager over DBus, and that ends up reconfiguring the host...  not the chroot'd image.

Hi Amar,

The nmstate shipping in RHEL 8.4 provides a function allowing you to generate NetworkManager config files without access to the NetworkManager daemon.

Could you take a look on below links to see whether it fix your needs?
https://github.com/nmstate/nmstate/pull/1424


Thank you!

Do we need the ability to modify connections or would it be enough to create connections without NM running?

Thomas, Beniamino: A patch to allow something like

nmcli con add --stdout con-name ens32 ifname ens32 type ethernet ip4 $NIC_IP/24 gw4 $NIC_GW > new_profile.nmconnection
# this would be adding a --stdout option that uses the library to write a keyfile instead of using dbus to create the new profile.

using the recently added library to write profiles as keyfiles seems to me to be low to medium effort, what do you think?

What would be the use case to modify existing connections?

(In reply to Till Maas from comment #18)
> Do we need the ability to modify connections or would it be enough to create
> connections without NM running?
> 
> Thomas, Beniamino: A patch to allow something like
> 
> nmcli con add --stdout con-name ens32 ifname ens32 type ethernet ip4
> $NIC_IP/24 gw4 $NIC_GW > new_profile.nmconnection
> # this would be adding a --stdout option that uses the library to write a
> keyfile instead of using dbus to create the new profile.

I like the idea, but I would change the '--stdout' option to something indicating that nmcli doesn't connect to NM like '--offline', '--no-dbus'.
'--stdout' gives the impression that only the output mode changes.

Maybe there should be also a '--file' option instead of always writing to stdout.

> using the recently added library to write profiles as keyfiles seems to me
> to be low to medium effort, what do you think?

I agree.

> What would be the use case to modify existing connections?

I don't know exactly, but maybe during installation there could be a template connection that gets customized. The modify command could be implemented using stdin and stdout, or a --file option:

  nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 < input.nmconnection > output.nmconnection
  nmcli --offline connection modify ens3 ipv4.dns 192.168.1.1 --file my.nmconnection

Closing as no reply from reporter to get this bug moving forward.

Please reopen.

Hi Philip Prindeville,

Could you state the use case required for this feature?

Thank you!

(In reply to Gris Ge from comment #23)
> Hi Philip Prindeville,
> 
> Could you state the use case required for this feature?
> 
> Thank you!

I have a need for building images in a chroot with the image mounted on a loopback device, and I want to preconfigure VPN and WiFi profiles into that image... but without affecting the host that's doing the image building.

Hi Philip,

Could you try `nmstatectl gc` command[1] which generate the NetworkManager configuration files without host network access.


[1]: https://nmstate.io/features/gen_conf.html

This would be useful to help with a possible migration to allow getting current ifcfg profiles as keyfiles:

nmcli con show --keyfile $UUID

moving to POST.

A first feature was added with https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/merge_requests/1183 .
While we probably want do expand on this topic further, it's not clear when or how exactly.
Also, it warrants a new bug to discuss what exactly to do about future improvements, and to have the issue better scoped.

Please try this new feature, and open a new bug with discussion about what is missing or what should be improved (if anything). Thanks.

I manually tested latest `main` (using copr build).
I did not find any issues. Also the manual page lgtm.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (NetworkManager bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:7680

The needinfo request[s] on this closed bug have been removed as they have been unresolved for 120 days