Confirmed, in latest CentOS stream 9 new installation, the NetworkManager-1.34.0-0.1.el9 is not providing `ifup` command.


Considering a lot customers(according to PM Anita) are using ifup/ifdown, raise bug priority to high.

(In reply to Timothy Redaelli from comment #0)
> Description of problem:
> 
> Since RHEL9 doesn't have initscripts installed by default, ifup and ifdown
> wrappers are not installed, but they are listed in the package.
> 
> So if a user try to use it, bash-completion tell him to install
> NetworkManager, but it's already installed:

just for the record, this is not bash-completion but PackageKit-command-not-found AFAIK.

> 
> [root@wsfd-netdev27 ~]# ifup
> bash: ifup: command not found...
> Install package 'NetworkManager' to provide command 'ifup'? [N/y] y
> 
>  * Waiting in queue... Failed to install packages:
> NetworkManager-1:1.34.0-0.1.el9.x86_64 is already installed
> 
> 
> Another thing is that if you install initscripts and then you remove it, the
> symlinks for ifup and ifdown are not deleted (by design?)

Yes, this is by design.

> Steps to Reproduce:
> 1. Install a snapshot of RHEL9
> 2. Try to use ifup or ifdown
> 
> Actual results:
> 
> ifup/ifdown is not found and the system tell you to install NetworkManager
> to use it
> 
> 
> Expected results:
> 
> ifup/ifdown is available OR the system should not tell you to install
> NetworkManager

Proposed acceptance criteria:
Given a fresh Linux installation without initscripts, when a user runs `ifup`, then bash will print `bash: ifup: command not found`.
Given a Linux installation that provides /usr/bin/ifup, when I run rpm -qf /usr/sbin/ifup, it will report a package that owns it.
Given a Linux installation with initscripts and NetworkManager, when a user runs `ifup`, then it will call the NetworkManager ifup wrapper.
Given a Linux installation with initscripts and NetworkManager, when a user uninstalls initscripts and run `ifup`, then it will call the NetworkManager ifup wrapper.
Given a Linux installation with initscripts and NetworkManager and without network-scripts, when a user uninstalls NetworkManager, then /usr/sbin/ifup will be removed.

[and the same for ifdown instead of ifup]


AFAICS, the fix might be to remove these lines from the NM spec file:
%ghost %attr(755, root, root) %{_sbindir}/ifup
%ghost %attr(755, root, root) %{_sbindir}/ifdown
touch %{buildroot}%{_sbindir}/ifup %{buildroot}%{_sbindir}/ifdown

Maybe, also initscripts should be changed to %ghost the files instead, since with this solutions, no package will own /usr/sbin/ifup|ifdown, which is also bad. But then it will break if NetworkManager is not installed but only initscripts (maybe this is an edge scenario that we can accept?). Maybe the acceptance criteria are not possible to meet without complex changes to PackageKit-command-not-found which don't seem worth the effort. What do you think? An alternative might be to change the first acceptance criteria to allow it to suggest installing a package that will actually make ifup/ifdown available but since we want to be on a path to remove these legacy commands, it does not seem to be good idea.

New acceptance criteria from discussion at backlog refinement on 2021-12-14:

Given a fresh Linux installation without initscripts, when a user runs `ifup`, then PackageKit-command-not-found will suggest a package and after installing it, ´ifup´ will be the NetworkManager wrapper.
Given a Linux installation that provides /usr/bin/ifup, when I run rpm -qf /usr/sbin/ifup, it will report a package that owns it.
Given a Linux installation with initscripts and NetworkManager, when a user runs `ifup`, then it will call the NetworkManager ifup wrapper.
Given a Linux installation with initscripts and NetworkManager, when a user uninstalls initscripts and run `ifup`, then it will call the NetworkManager ifup wrapper.
Given a Linux installation with initscripts and NetworkManager and without network-scripts, when a user uninstalls NetworkManager, then /usr/sbin/ifup will be removed.

[and the same for ifdown instead of ifup]

*** Bug 2041764 has been marked as a duplicate of this bug. ***

I've tested the individual points in acceptance criteria, and they seem to be met, so I am moving it to verified.

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 (new packages: NetworkManager), 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:3915