Translation(s): English - Español - Français - српски
?Discussion
This page addresses some frequently asked questions about Netplan on Debian. Also have a look at Netplan's upstream FAQ: https://netplan.io/faq
Contents
- Why Netplan?
- Is Netplan just another abstraction layer?
- Is Netplan available anywhere else?
- Is Netplan written in Python?
- Where does Netplan store its configuration?
- Is Netplan integrated with the rest of the system?
- Does Netplan bloat my system?
- Can Netplan interact with NetworkManager?
- Does Netplan take exclusive control over the network stack?
Why Netplan?
Using Netplan gives a central location to describe simple-to-complex networking configurations that function from desktop to server and from cloud to IoT devices.
Specifically, for systems with systemd-networkd, this reliefs the user from having to configure up to three different files per device or configuration.
It provides a common and unified way to do network configuration across the distribution and brings a modern, hybrid network stack, consisting of systemd-networkd (for minimal, static server/cloud scenarios) and NetworkManager (for interactive, dynamic desktop/laptop scenarios, e.g. WiFi). All components of this Netplan + systemd-networkd/NetworkManager stack are well-tested, under active development and supported by a company.
Furthermore, Netplan is:
- Already used on Debian Bookworm cloud images by default
- Supported by debian-installer/netcfg as of v1.190
- Supported in autopkgtest testbeds as of v5.36
- Well tested (big autopkgtest suite) and supported by Ubuntu/Canonical
Well-known with lots of Q/A & tutorials on the internet, as it's being used by millions of people since many years
- Proven in production, by being the default for several Ubuntu LTS releases
- Shipping solid documentation and a stable API for libnetplan, as of Netplan 1.0
Is Netplan just another abstraction layer?
No. Besides bringing consistent configuration to multiple backends, such as systemd-networkd, NetworkManager or Open vSwitch in form of an abstraction layer. It also brings unique runtime tooling for network configuration as part of the full netplan.io package, such as the netplan try command, which can roll back broken configuration easily or the netplan status [--diff] command, which can show differences between network configuration and system state.
Is Netplan available anywhere else?
We don't want to end up with another Debian-only solution, but instead use tooling that's widely adopted. Netplan is the default network stack used in Ubuntu since 2016 (incl. 4 major LTS releases) and therefore used by millions of people and supported by Canonical. It's also used as the default network stack in Debian cloud-images, as of the "Bookworm" release and is available for plenty of other distros, such as Arch Linux, Azure Linux, OpenSUSE, Yocto/OpenEmbedded. Community members from around the world and from different projects/companies contribute to the development of Netplan.
Is Netplan written in Python?
Partially. The core of Netplan, that is on the critical path, is written in C, shipped as a small /usr/libexec/netplan/generate binary and a libnetplan1 shared library.
On top of that, Netplan provides an (optional) CLI that is written in Python, allowing for easier runtime configuration and status tracking, such as netplan apply or netplan status. The CLI depends on the Python runtime itself, in addition to the python3-cffi-backend (via python3-netplan), python3-yaml and (optionally) python3-rich packages. Additional dependencies on python3-netifaces and python3-dbus are about to be dropped.
Where does Netplan store its configuration?
User configuration is stored as YAML configuration files in /etc/netplan/, following the Netplan schema.
While system components can install configuraiton snippets in /usr/lib/netplan/ and runtime configuration can be generated in /run/netplan/.
Is Netplan integrated with the rest of the system?
Yes. Netplan is already supported by many important system components, such as Debian-Installer, FAI, Calamares, autopkgtest infrastructure or networkd-dispatcher hooks.
Does Netplan bloat my system?
No. Netplan is designed as a one-shot service/generator, that runs only briefly during system boot-up (or when called interactively through its CLI) to generate relevant backend configuration. It exits its process afterwards, so does not consume runtime (CPU/Memory) resources continuously.
For storage, the minimal viable installation of just the netplan-generator package (without Recommends) takes up only 5.5M of disk space. While a full installation of the netplan.io package (without Recommends) takes up approx. 34M (102M with Recommends), including the Python runtime used by the interactive Netplan CLI.
Considering a system with the standard task already installed, Netplan adds a delta of approx. 7M (31M with Recommends) on top of that.
Can Netplan interact with NetworkManager?
Netplan is designed as a configuration generator. As such, it implements a unidirectional way of parsing Netplan configuration and generating backend configuration (e.g. for NetworkManager or systemd-networkd) out of it. If native backend configuration is applied on top of that, Netplan will now know, nor care about it (unless they try to configure an interface controlled by Netplan in a conflicting way).
On Ubuntu, the network-manager package contains a few patches that make this integration bidirectional. Allowing NetworkManager to write back any configuration changes made through the UI, nmcli, nmtui, D-Bus API, etc.. to be stored in /etc/netplan/. Those patches are not (yet) ready for adoption in Debian, though, due to hard-coding certain Ubuntu policies.
Does Netplan take exclusive control over the network stack?
No. Netplan plays nice with other network configuration tools and control only the interfaces that were explicitly listed in its configuration files. Not touching anything besides that. So you could run it side-by-side with the likes of ifupdown or (native) systemd-networkd.
Netplan can be effectively disabled by dropping all of its YAML configuration, e.g.: rm /etc/netplan/*.yaml
