Our traditional network-scripts are deprecated: https://unix.stackexchange.com/questions/483354/rhel-8-deprecated-network-scripts and there is a message shown in cauldron for this deprecation. I guess many people use networkmanager on graphical interfaces e.g. laptops for wlan connection. But on servers nm is not very handy and you usally don't have a graphical userinterface. Should we move to systemd-networkd for static configurations? https://wiki.mageia.org/en/Systemd-networkd
I agree it would be a good idea. I'm using in on my m8 install, in addition to network scripts in order to get ipv6 working, without having to rely on network manager. # grep -v -e ^'#' -e ^$ /etc/systemd/network/eth0.network [Match] Name=e* [Network] Description=LAN_NIC DNS=::1 DNS=127.0.0.1 DNS=192.168.10.101 DNS=8.8.8.8 Domains=x3.hodgins.homeip.net DHCP=no LLMNR=false IPv6AcceptRA=yes [Address] Address=192.168.10.2/24 [Route] Gateway=192.168.10.11 I've enabled and started systemd-networkd.service and systemd-networkd.socket I do get an error during boot Mar 12 17:49:22 /etc/sysconfig/network-scripts/ifup-eth[1681]: Error adding address 192.168.10.2 for eth0. as the same address is used in both the systemd and ifup configurations, but the error message does not stop it from working. Just fyi, the nic is eth0 as I have net.ifnames=0 in the kernel cmdline. Since I only have one ethernet nic, I don't need the alternate name for this install.
CC: (none) => davidwhodgins
Assignee: bugsquad => mageiatools
(In reply to Marc Krämer from comment #0) > Our traditional network-scripts are deprecated: > https://unix.stackexchange.com/questions/483354/rhel-8-deprecated-network- > scripts > > and there is a message shown in cauldron for this deprecation. > > I guess many people use networkmanager on graphical interfaces e.g. laptops > for wlan connection. But on servers nm is not very handy and you usally > don't have a graphical userinterface. > Why wouldn't NetworkManager be handy on servers? It supports a wide range of server networking configurations (bonds, teams, taps, tuns, bridges, OVS, WireGuard, etc.) and has both a CLI tool (nmcli) and a TUI configuration tool (nmtui).
CC: (none) => ngompa13
You can also configure NetworkManager via dropping in config files: either by using ifcfg files for simple stuff or by using the native keyfiles for everything.
->we should migrate somewhere and remove the old scripts, as they interfere nm scripts: #31661 - I assume the old ifcfg files are only supported to deprecate the scripts first, and to be honest, the documentation was never very good and easy - For me, systemd looks easier, even with complex setups. - I suggest to migrate to either systemd-network or networkmanager, but use the new syntax and remove the old scripts. => we should make a decission about this SOON, so we are prepared for mga10. Since fedora/redhat already deprecated theses scripts, we should change this. ATM removing network-scripts gives me: urpme network-scripts-10.04-4.mga9.x86_64 Removing the following package will break your system: basesystem-minimal-9-0.1.mga9.x86_64 (due to missing initscripts) As we have systemd-network and networkmanager, we should not need it anymore - and I hope we will get rid of all old initscripts.
Hi, Why not install both tools (systemd and nm) with nm as default for end users and MCC and let administrator switch to "systemd-networkd" for his servers. If not switched in Mga9, replace the deprecated "egrep" in "ifdown-eth" and "ifup-wireless" scripts (with "grep -E" to avoid warnings)
CC: (none) => richard
yeah, that would be a good option.
please test initscripts-10.04-5.mga9 in core/updates_testing repo! it should avoid egrep for grep -E
CC: (none) => geiger.david68210
Test of these scripts ok. Thx
Well, I set up NetworkManager via nmcli (with help from the ArchLinux Wiki); it never even dawned on me to use a GUI. Really, network-scripts should have been removed from Mageia 9; NetworkManager is already built in Mageia in a way that's a drop-in replacement for network-scripts (e.g. the configs are stored in /etc/sysconfig/network-scripts; though, the ifcfg-rh plugin is deprecated (but unlike network-scripts, doesn't give you deprecation notices whenever you use it), so who knows how long it will be viable to use NetworkManager that way?). Surely, all that would be required would be to remove network-scripts and use update-alternatives to use /usr/libexec/nm-if{up,down} for the if{up,down} commands, and most users wouldn't be able to tell the difference (I'm an exception, as I had manually configured wpa_supplicant rather than used the desktop applet (so starting NetworkManager took down my WiFi), but even for me, it really wasn't difficult: `nmcli --ask dev wifi connect <ssid>`). systemd-networkd seems both more complicated (editing service files) and more limited than NetworkManager; I for one can get `networkctl down` to work but `networkctl up` does nothing (where both `nmcli dev down` and `nmcli dev up` work perfectly and required far less configuration). NetworkManager absolutely should be preferred for most users (users can configure to use systemd-networkd if they want, but I can't imagine why they would).
CC: (none) => zooplah
the question arises more for server setups. And e.g. configuring a) static routes b) vlan c) virtual devices e.g. https://docs.hetzner.com/cloud/networks/connect-dedi-vswitch/ most hosters don't show how to configure that via networkmanager I prefer editing (and comparing) config files over using command line tools. e.g. if you have a problem with the connection of 2 servers a diff of /etc/sysconfig/network-scripts is usally more effectiv than calling ip/ifconfig/route and what ever to find the problem.
You can edit NM config files directly if you want. It's all documented: https://networkmanager.dev/docs/admins/
I've looked into it, but there is not much real world documentation, e.g. how to setup vlan devices and configure routes with it. I guess mos documentation is about what debian/ubuntu does, because it is mostly used on servers. You always have headache, if you use other distros with other settings you need much more trial and error to match the setiings to other tools.