Moving on from net-tools

Posted Jan 5, 2017 9:35 UTC (Thu) by jrigg (guest, #30848)
Parent article: Moving on from net-tools

How long before this is all subsumed by systemd-networkd and needs to be relearned again?

Moving on from net-tools

Posted Jan 5, 2017 10:10 UTC (Thu) by anselm (subscriber, #2796) [Link] (6 responses)

Systemd-networkd lives in the ecological niche otherwise occupied, among other things, by NetworkManager or your distribution's network setup scripts and is pretty much orthogonal to whatever low-level CLI tools you would use to poke around in your network configuration. It might conceivably use either inet-tools or iproute2 to actually set up the network (I wouldn't know, but it probably doesn't).

Did you need to relearn the low-level CLI network management commands when dhclient came out? No? Thought so.

Moving on from net-tools

Posted Jan 5, 2017 12:32 UTC (Thu) by jrigg (guest, #30848) [Link]

> Systemd-networkd....is pretty much orthogonal to whatever low-level CLI tools you would use to poke around in your network configuration

Ok, thanks for the clarification. I was thinking (perhaps misguidedly) of possible feature creep when I made my comment.

Moving on from net-tools

Posted Jan 5, 2017 13:16 UTC (Thu) by fishface60 (subscriber, #88700) [Link] (3 responses)

I was under the impression that systemd-networkd was more closely in the niche of ifupdown than NetworkManager,
since NetworkManager quite happily coexists with networkd or ifupdown
and is more for the desktop-user-level networking configuration,
while networkd and ifupdown are for network configuration that isn't expected to change all the time, so handy for desktops, servers and containers.

Moving on from net-tools

Posted Jan 5, 2017 15:04 UTC (Thu) by drag (guest, #31333) [Link] (2 responses)

> NetworkManager quite happily coexists with networkd or ifupdown

Not really.

NetworkManager features backends for compatibility Debian/Redhat configurations. 'Ifcfg' should be compatible with Redhat style ifcfg files, but really are not. I am sure that this sort of thing has pissed off a great deal of people who found that their ifcfg machinations that previously worked fine with the ifcfg scripts failed in subtle ways under NetworkManager. A example of this is bridge configuration options are different between NetworkManager and the RH ifcfg scripts.

If I have a non-trivial network configuration to deal with I tend to do two things with NetworkManager, 1. disable the auto configuration of interfaces (no-auto-default=*). 2. disable compatibility with distro configurations and use the 'keyfile' config backend.

I don't know how well NetworkManager works with Debian-style network configuration, but I expect it's similar.

'Ifup' and 'ifdown' commands, similarly, should be avoided. It may work, but it's likely doing funky things. 'nmcli c up/down' is preferable.

systemd-networkd is interesting to me. One of the things I could never figure out with NetworkManager is the use of it to configure 'foreign' network devices. So, for example, if you are using VPNs it works fine if the VPN has a plugin that integrates with NetworkManager. But if you are using something like 'tinc' that has no NetworkManager plugin then you are stuck doing all the configuration in shell scripts. I am hoping that networkd would be able to work properly with 'non native' network devices that get created without having to deal with a complex set of requirements for plugin compatibility.

Moving on from net-tools

Posted Jan 5, 2017 17:48 UTC (Thu) by cortana (subscriber, #24596) [Link]

FYI, I find tinc and networkd work very well together. I have configured tinc to do nothing to configure the interface (empty tinc-up script); then it is a simple matter to create myvpn.network with [Match] Name=mynetwork and then whatever configuration I need in the [Network] section. Tinc creates the interface, and networkd configures it.

Moving on from net-tools

Posted Jan 13, 2017 16:07 UTC (Fri) by dcbw (guest, #50562) [Link]

"One of the things I could never figure out with NetworkManager is the use of it to configure 'foreign' network devices. So, for example, if you are using VPNs it works fine if the VPN has a plugin that integrates with NetworkManager. But if you are using something like 'tinc' that has no NetworkManager plugin then you are stuck doing all the configuration in shell scripts."

Since NM is aware of all network devices, you can apply NM configuration to them, even if NM doesn't auto-activate any configuration or directly control them. So for example, say you have a 'tun3' device created by tinc you can create an NM config with all your desired details, lock the connection to 'tun3', and then run tinc to set up the device and then 'nmcli con up my-tinc' to set up the IP configuration and DNS configuration.

Moving on from net-tools

Posted Jan 12, 2017 17:52 UTC (Thu) by judas_iscariote (guest, #47386) [Link]

>It might conceivably use either inet-tools or iproute2 to actually set up the network (I wouldn't know, but it probably doesn't).

No, systemd-networkd does not use any of these tools. it uses sd-netlink to talk kernel.

Moving on from net-tools

Posted Jan 5, 2017 10:36 UTC (Thu) by pbonzini (subscriber, #60935) [Link] (1 responses)

Judging from your comment, after you've learnt systemd-networkd (i.e., never).

Moving on from net-tools

Posted Jan 5, 2017 12:08 UTC (Thu) by jrigg (guest, #30848) [Link]

> Judging from your comment, after you've learnt systemd-networkd (i.e., never).

You're correct but you missed my point, which was that changing to something that's already been around for a few years may be wasted effort if something new is likely to supplant it in the near future.