For context, when initscripts' "network-scripts" package is not installed, then via "alternatives", `ifup` maps to `nm-ifup`, which literally does:

  #!/usr/bin/sh
  nmcli connection load "/etc/sysconfig/network-scripts/ifcfg-$1" &&
  exec nmcli connection up filename "/etc/sysconfig/network-scripts/ifcfg-$1"

That also roughly corresponds to what initscripts do, when NetworkManager is running and the ifcfg does not contain `NM_CONTROLLED=no`.


With initscripts, the entire API is strongly centered about the actual files (and file names). That is, the user edits ifcfg files and then issues `ifup $PART_OF_FILENAME`.



I don't see how the command argument to `ifup` can make sense for keyfiles.

It would require defining what it means, but I don't think we should extend ifup in such a way. I would close this as WONTFIX.

network-scripts also falls back to the name if the filename does not exist: https://github.com/fedora-sysv/initscripts/blob/master/network-scripts/network-functions#L48

So possible algorithm would be:

if exists /etc/sysconfig/network-scripts/ifcfg-$1 then load and activate it
elif exists /etc/NetworkManager/system-connections/$a.nmconnection then load and activate it
elif exists /etc/NetworkManager/system-connections/$a.ovpn then load and activate it # do this for all suffixes that are supported there)
elif profile $1 exists then activate it
elif profile "Auto $1" exists then activate it
elif profile "System $1" exists then activate it
else fail

(In reply to Till Maas from comment #2)
> network-scripts also falls back to the name if the filename does not exist:
> https://github.com/fedora-sysv/initscripts/blob/master/network-scripts/
> network-functions#L48
> 
> So possible algorithm would be:
> 
> if exists /etc/sysconfig/network-scripts/ifcfg-$1 then load and activate it
> elif exists /etc/NetworkManager/system-connections/$a.nmconnection then load
> and activate it
> elif exists /etc/NetworkManager/system-connections/$a.ovpn then load and
> activate it # do this for all suffixes that are supported there)
> elif profile $1 exists then activate it
> elif profile "Auto $1" exists then activate it
> elif profile "System $1" exists then activate it
> else fail

Possible. But is that a good idea? Why?

What about /run/NetworkManager/system-connections and /usr/lib/NetworkManager/system-connections?

`nmcli connection up` and is already flexible in accepting a ID, UUID, D-Bus path, filename.

I don't think there should be even more "guesswork" done. The user should make a minimal effort to specify the profile they care about. This is not an API we should provide. If it's too cumbersome for a user to type `nmcli connection up`, they are free to create their own shell script.


I also don't think it's good to pollute $PATH with a variaty of command line tools (kinit, kdestroy, klist). Yes, `nmcli connection up` is a mouth full, so is `git add`. I am glad that there is no `gadd` wrapper for `git add`, and I don't think there should be an `ifup` wrapper script for `nmcli connection up`. Well, currently there is one, because of compatibility with initscripts. But not because NetworkManager should provide this.

Also, one of the several reasons to move away from ifcfg files, is that NetworkManager becomes more similar on all distros. We should not provide a Fedora/RHEL specific script nor encourage users to use it.



This change is documented in the release-notes. The user can opt out by configuring rhel-8 behavior. The user can also provide their own `ifup` script, if they care so much.

(In reply to Thomas Haller from comment #3)
> (In reply to Till Maas from comment #2)
> > network-scripts also falls back to the name if the filename does not exist:
> > https://github.com/fedora-sysv/initscripts/blob/master/network-scripts/
> > network-functions#L48
> > 
> > So possible algorithm would be:
> > 
> > if exists /etc/sysconfig/network-scripts/ifcfg-$1 then load and activate it
> > elif exists /etc/NetworkManager/system-connections/$a.nmconnection then load
> > and activate it
> > elif exists /etc/NetworkManager/system-connections/$a.ovpn then load and
> > activate it # do this for all suffixes that are supported there)
> > elif profile $1 exists then activate it
> > elif profile "Auto $1" exists then activate it
> > elif profile "System $1" exists then activate it
> > else fail
> 
> Possible. But is that a good idea? Why?

This seems to be an easy win to smoothen the migration for users who are used to ifup/ifdown.

> 
> What about /run/NetworkManager/system-connections and
> /usr/lib/NetworkManager/system-connections?

Please remind me, what is the guidance for those directories to be used? The current nm-ifup code implies that it was used right after admins updated the ifcfg file manually which is what I expect for them to do in /etc and not /run. Not sure about /usr/lib - is it /usr/lib or /var/lib?

> 
> `nmcli connection up` and is already flexible in accepting a ID, UUID, D-Bus
> path, filename.
> 
> I don't think there should be even more "guesswork" done. The user should
> make a minimal effort to specify the profile they care about. This is not an
> API we should provide. If it's too cumbersome for a user to type `nmcli
> connection up`, they are free to create their own shell script.

I think if we want to get rid of nm-ifup, there should be at least a deprecation warning. But I can understand why network-scripts is guessing the System/Auto prefix since for me this is an unfortunate chose for the shell: nmcli c up "System eth0" is no fun to type. I had this thought yesterday unrelated to this ticket, too.

> I also don't think it's good to pollute $PATH with a variaty of command line
> tools (kinit, kdestroy, klist). Yes, `nmcli connection up` is a mouth full,
> so is `git add`. I am glad that there is no `gadd` wrapper for `git add`,
> and I don't think there should be an `ifup` wrapper script for `nmcli
> connection up`. Well, currently there is one, because of compatibility with
> initscripts. But not because NetworkManager should provide this.

ifup/ifdown already exists, though.

> Also, one of the several reasons to move away from ifcfg files, is that
> NetworkManager becomes more similar on all distros. We should not provide a
> Fedora/RHEL specific script nor encourage users to use it.
> 
> 
> 
> This change is documented in the release-notes. The user can opt out by
> configuring rhel-8 behavior. The user can also provide their own `ifup`
> script, if they care so much.

The ifup/ifdown challenge is not as much documented, maybe it is better in the release notes but the Fedora change missed this:
https://fedoraproject.org/wiki/Changes/NetworkManager_keyfile_instead_of_ifcfg_rh

> I think if we want to get rid of nm-ifup

We don't want to get rid of it (as long as NetworkManager supports ifcfg files).

> But I can understand why network-scripts is guessing the System/Auto prefix 

Which guessing do you mean? network-scripts unambiguously refer to the filename "/etc/sysconfig/network-scripts/ifcfg-$1".

> nmcli c up "System eth0" is no fun to type

"System eth0" is the "connection.id" of a profile in ifcfg format, that does not specify the NetworkManager specific variable `NAME=`. Yes, that is not a nice choice, but cannot change now.  I guess you also dislike "Wired connection 1". Me too.

It only affects certain scenarios, and in all cases has the user the possibility to change the connection.id of a profile.


> The ifup/ifdown challenge is not as much documented

If you are using ifcfg files directly, then there is no change and `ifup` will continue to work.
If you are not using ifcfg files explicitly, then ifup was always the wrong tool.

> Please remind me, what is the guidance for those directories to be used? The current nm-ifup code implies that it was used right after admins updated the ifcfg file manually which is what I expect for them to do in /etc and not /run. Not sure about /usr/lib - is it /usr/lib or /var/lib?

The current code reloads the file first, because a common usage of initscripts would be

    vim /etc/sysconfig/network-scripts/ifcfg-eth0
    ifup eth0

that worked with initscripts, because it would read the latest version of the file. Hence, when the file is managed by NetworkManager, then it also must first be loaded. This is what /etc/sysconfig/network-scripts/ifup and also nm-ifup does.

With NetworkManager you need

    vim /etc/NetworkManager/system-connections/eth0.nmconnection
    nmcli connection load /etc/NetworkManager/system-connections/eth0.nmconnection
    nmcli connection up /etc/NetworkManager/system-connections/eth0.nmconnection

But that is not special about the keyfile. It's the same with a file /etc/sysconfig/network-scripts/ifcfg-eth0.


> ifup/ifdown already exists, though.

Provided with two alternatives, from network-scripts package and NeworkManager package. network-scripts are deprecated already and no longer installed by default. nm-ifup exists in rhel-8 to ease the transition. It's already a replacement for a deprecated tool. It keeps existing, but I think we should not expand it's usage to keyfile because of the semantics (where the argument is part of the filename).




# /etc/sysconfig/network-scripts/ifup eth0
/etc/sysconfig/network-scripts/ifup: configuration for eth0 not found.
Usage: ifup <configuration>
# /usr/libexec/nm-ifup eth0
Error: unknown connection '/etc/sysconfig/network-scripts/ifcfg-eth0'.

This message is pretty clear, isn't it? Maybe that should be improved to


diff --git i/src/core/settings/plugins/ifcfg-rh/nm-ifup w/src/core/settings/plugins/ifcfg-rh/nm-ifup
index 96637a92fb37..0d557d42bee0 100644
--- i/src/core/settings/plugins/ifcfg-rh/nm-ifup
+++ w/src/core/settings/plugins/ifcfg-rh/nm-ifup
@@ -1,3 +1,9 @@
 #!/bin/sh
 nmcli connection load "/etc/sysconfig/network-scripts/ifcfg-$1" &&
-exec nmcli connection up filename "/etc/sysconfig/network-scripts/ifcfg-$1"
+nmcli connection up filename "/etc/sysconfig/network-scripts/ifcfg-$1" &&
+exit 0
+
+echo "  See all profiles with \`nmcli connection\`."
+echo "  Reload files from disk with \`nmcli connection reload\`"
+echo "  Activate the desired profile with \`nmcli connection up \"\$NAME\"\`"
+exit 1



> it means configurations created by installer will not use rh-ifup format.

True, that might be a change. Note that since we use NetworkManager in initrd, those profiles also are no longer in ifcfg format but under /run/NetworkManager/system-connections -- already on rhel-8.

(In reply to Thomas Haller from comment #5)
> > I think if we want to get rid of nm-ifup
> 
> We don't want to get rid of it (as long as NetworkManager supports ifcfg
> files).
> 
> > But I can understand why network-scripts is guessing the System/Auto prefix 
> 
> Which guessing do you mean? network-scripts unambiguously refer to the
> filename "/etc/sysconfig/network-scripts/ifcfg-$1".


The one I linked in comment:2 - https://github.com/fedora-sysv/initscripts/blob/master/network-scripts/network-functions#L48

Try:
echo 'NAME="System b"' > /etc/sysconfig/network-scripts/ifcfg-a
ifup b


with network-scripts.


> 
> > nmcli c up "System eth0" is no fun to type
> 
> "System eth0" is the "connection.id" of a profile in ifcfg format, that does
> not specify the NetworkManager specific variable `NAME=`. Yes, that is not a

NAME does not seem to be NM specific. Maybe it was but network-scripts supports it now.


 
> > The ifup/ifdown challenge is not as much documented
> 
> If you are using ifcfg files directly, then there is no change and `ifup`
> will continue to work.
> If you are not using ifcfg files explicitly, then ifup was always the wrong
> tool.
> 
> > Please remind me, what is the guidance for those directories to be used? The current nm-ifup code implies that it was used right after admins updated the ifcfg file manually which is what I expect for them to do in /etc and not /run. Not sure about /usr/lib - is it /usr/lib or /var/lib?
> 
> The current code reloads the file first, because a common usage of
> initscripts would be
> 
>     vim /etc/sysconfig/network-scripts/ifcfg-eth0
>     ifup eth0
> 
> that worked with initscripts, because it would read the latest version of
> the file. Hence, when the file is managed by NetworkManager, then it also
> must first be loaded. This is what /etc/sysconfig/network-scripts/ifup and
> also nm-ifup does.
> 
> With NetworkManager you need
> 
>     vim /etc/NetworkManager/system-connections/eth0.nmconnection
>     nmcli connection load
> /etc/NetworkManager/system-connections/eth0.nmconnection
>     nmcli connection up
> /etc/NetworkManager/system-connections/eth0.nmconnection

yes. You mentioned the other paths (/var/run, /usr/lib). Is it typical to do this for the other paths?

> 
> But that is not special about the keyfile. It's the same with a file
> /etc/sysconfig/network-scripts/ifcfg-eth0.
> 
> 
> > ifup/ifdown already exists, though.
> 
> Provided with two alternatives, from network-scripts package and
> NeworkManager package. network-scripts are deprecated already and no longer
> installed by default. nm-ifup exists in rhel-8 to ease the transition. It's
> already a replacement for a deprecated tool. It keeps existing, but I think
> we should not expand it's usage to keyfile because of the semantics (where
> the argument is part of the filename).


the argument is not just part of the filename.

> # /etc/sysconfig/network-scripts/ifup eth0
> /etc/sysconfig/network-scripts/ifup: configuration for eth0 not found.
> Usage: ifup <configuration>
> # /usr/libexec/nm-ifup eth0
> Error: unknown connection '/etc/sysconfig/network-scripts/ifcfg-eth0'.
> 
> This message is pretty clear, isn't it? Maybe that should be improved to


I tried this as non-root, then the error message is not that clear:

LANG=C ifup eth0
Error: failed to load connection: access denied.

> 
> 
> diff --git i/src/core/settings/plugins/ifcfg-rh/nm-ifup
> w/src/core/settings/plugins/ifcfg-rh/nm-ifup
> index 96637a92fb37..0d557d42bee0 100644
> --- i/src/core/settings/plugins/ifcfg-rh/nm-ifup
> +++ w/src/core/settings/plugins/ifcfg-rh/nm-ifup
> @@ -1,3 +1,9 @@
>  #!/bin/sh
>  nmcli connection load "/etc/sysconfig/network-scripts/ifcfg-$1" &&
> -exec nmcli connection up filename "/etc/sysconfig/network-scripts/ifcfg-$1"
> +nmcli connection up filename "/etc/sysconfig/network-scripts/ifcfg-$1" &&


Why does nmcli con up filename $path not imply "nmcli con load?" Would it be bad to change it so that ifup can be replace by nmlci con up  filename $path?

Created attachment 1782067 [details]
[patch] ifup: extend ifup/ifdown to be smarter about NetworkManager profiles

this would be a possible implementation of a script.

However, I think this should not be done.

Doing this makes `ifup`/`ifdown` more useful and more part of NetworkManager API.  People would get more used to them, than they already are. This is not desirable.

They currently only work on Fedora/RHEL. Making them part of NetworkManager API would urge us that they are also available on Debian. But Debian already has conflicting ifup/ifdown commands with entirely different behavior. Hijacking commands is bad style and should not be done. Having NetworkManager behave differently between Fedora/RHEL and Debian is also very undesirable. Also, providing unqualified tools without a clear nm-prefix in the system's $PATH seems undesirable.

If a user wants to safe typing, they can write a shell script (like the one attached) on their own. In my bashrc I also have many aliases that are useful helpers to me. That doesn't mean such aliases should be provided by the distro in general installations.


If the typing is the problem, we could add a `nmcli up $ARG` command both accepts device and profile names as arguments and tries to guess what the user does. That would be useful in it's own right. Another useful usability improvement for nmcli would be https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/issues/678 . Extending these ifup scripts is IMO wrong.

fixed upstream:

https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/30e7400528979ded07758643fdd18e367abc581e

backported to nm-1-32 as https://gitlab.freedesktop.org/NetworkManager/NetworkManager/-/commit/937171ba18082d002ad4c009c142b14907d80d36
(for 1.32.10).