Debian E/LTS, May 2026

During this month, I have worked on the following tasks for Debian LTS and ELTS.
Thanks to Freexian and sponsors for making this possible [0].

nghttp2

Misc

Cheers,
Lukas

[0] https://www.freexian.com/lts/debian/#sponsors

Debian E/LTS, April 2026

During this month, I have worked on the following tasks for Debian LTS and ELTS.
Thanks to Freexian and sponsors for making this possible [0].

nghttp2

Misc

Cheers,
Lukas

[0] https://www.freexian.com/lts/debian/#sponsors

Debian E/LTS, March 2026

March 2026

During this month, I have worked on the following tasks for Debian LTS and ELTS.
This was my first month as LTS/ELTS contributor, including technical onboarding
and initial setup of workflows.
Thanks to Freexian and sponsors for making this possible [0].

Asterisk

Misc

  • Initial technical onboarding/setup of LTS/ELTS repositories.
  • Spent some time experimenting with Debusine to utilize it for LTS/ELTS work.
  • Attended the monthly LTS/ELTS team meeting.

Cheers,
Lukas

[0] https://www.freexian.com/lts/debian/#sponsors

Maximierung der Effizienz: Automatisierungstechniken in LibreOffice auf dedizierten Servern

Automatisierung ist der Schlüssel zur Effizienzsteigerung in der modernen Arbeitswelt. Besonders bei der Verwaltung großer Datenmengen oder sich wiederholender Aufgaben kann die Automatisierung erhebliche Vorteile bieten. LibreOffice, eine der führenden freien Office-Suiten, bietet vielfältige Möglichkeiten, um Arbeitsabläufe durch Automatisierung zu optimieren, insbesondere auf dedizierten Servern. Dieser Beitrag beleuchtet, wie erweiterte Automatisierungstechniken in LibreOffice eingesetzt werden können, um die Effizienz zu maximieren.

Herausforderungen in der Büroautomatisierung

In vielen Unternehmen sind Office-Programme unverzichtbare Werkzeuge. Dennoch gibt es Herausforderungen, die die Effizienz beeinträchtigen können. Manuelle Datenverarbeitung ist zeitaufwändig und fehleranfällig. Wiederholte Eingaben und Formatierungen beanspruchen wertvolle Ressourcen und können die Produktivität erheblich senken. Diese Probleme werden noch komplexer, wenn große Datenmengen auf dedizierten Servern verarbeitet werden müssen, wo Geschwindigkeit und Zuverlässigkeit entscheidend sind.

Die Rolle dedizierter Server

Dedizierte Server bieten eine leistungsstarke Plattform zur Verarbeitung komplexer Aufgaben. Sie ermöglichen es, große Datenmengen effizient zu verwalten und zu verarbeiten. Doch ohne geeignete Automatisierungstechniken kann das volle Potenzial dieser Server nicht ausgeschöpft werden. Hier setzt die Automatisierung mit LibreOffice an, um diese Herausforderungen zu meistern und die Effizienz zu steigern.

Automatisierungstechniken in LibreOffice

LibreOffice bietet verschiedene Möglichkeiten zur Automatisierung, die von einfachen Makros bis hin zu komplexen Skripten reichen. Diese Techniken helfen, Routineaufgaben zu automatisieren und die Konsistenz der Datenverarbeitung zu gewährleisten.

Makros und Skripte

Makros sind eine der einfachsten Methoden zur Automatisierung in LibreOffice. Sie ermöglichen es, wiederkehrende Aufgaben mit einem einzigen Klick auszuführen. Ein einfaches Makro zur Automatisierung könnte beispielsweise so aussehen:

Sub SimpleMacro
MsgBox "Dies ist ein automatisierter Prozess!"
End Sub

Für komplexere Automatisierungen bieten sich Skripte in Python oder JavaScript an. Diese Skripte können komplexe Berechnungen durchführen oder Daten aus verschiedenen Quellen integrieren. Durch die Nutzung dieser Skripte auf dedizierten Servern kann die Verarbeitungsgeschwindigkeit erheblich gesteigert werden.

Integration mit Datenbanken

Eine weitere Möglichkeit zur Effizienzsteigerung ist die Integration von LibreOffice mit externen Datenbanken. Dies ermöglicht den automatisierten Import und Export von Daten, wodurch manuelle Eingaben minimiert werden. Beispielsweise kann ein Skript automatisch Daten aus einer SQL-Datenbank abrufen, analysieren und in einem LibreOffice Calc-Dokument darstellen.

Implementierung auf dedizierten Servern

Die Implementierung von Automatisierungstechniken auf dedizierten Servern erfordert eine gezielte Planung und Ausführung. Hierbei spielen Skalierung und Sicherheit eine entscheidende Rolle.

Skalierung und Leistung

Um die Leistung zu maximieren, sollten Automatisierungsprozesse so konzipiert werden, dass sie die Ressourcen des Servers optimal nutzen. Dazu gehört die parallele Verarbeitung von Aufgaben und die effiziente Nutzung von Speicher und CPU. Ein Beispiel für eine skalierbare Lösung ist die Nutzung von Docker-Containern, um LibreOffice-Instanzen in isolierten Umgebungen auszuführen. Dies ermöglicht es, mehrere Prozesse gleichzeitig zu betreiben, ohne dass es zu Ressourcenengpässen kommt.

Sicherheit und Wartung

Sicherheit ist ein wesentlicher Aspekt bei der Automatisierung auf dedizierten Servern. Es ist wichtig, dass alle Automatisierungsprozesse regelmäßig auf Sicherheitslücken überprüft werden. Zudem sollten Backups und Wiederherstellungspläne vorhanden sein, um Datenverlust zu vermeiden.

Vorteile der Automatisierung

Die Implementierung erweiterter Automatisierungstechniken in LibreOffice bietet zahlreiche Vorteile, die weit über die reine Effizienzsteigerung hinausgehen.

  • Zeitersparnis: Automatisierung reduziert die Notwendigkeit manueller Eingaben und ermöglicht es, komplexe Aufgaben in kürzerer Zeit zu erledigen.
  • Fehlerreduktion: Durch die Automatisierung werden menschliche Fehler minimiert, was die Genauigkeit der Datenverarbeitung erhöht.
  • Kosteneffizienz: Die Reduzierung der benötigten Arbeitszeit führt zu einer Senkung der Betriebskosten.
  • Skalierbarkeit: Automatisierte Prozesse lassen sich leicht an wachsende Datenmengen anpassen, ohne dass die Leistung darunter leidet.

Vergleichstabelle: Vorher und Nachher der Automatisierung

KriteriumVor AutomatisierungNach Automatisierung
BearbeitungszeitHochNiedrig
FehlerquoteHochNiedrig
BetriebskostenHochGering

Durch die gezielte Implementierung von Automatisierungstechniken in LibreOffice können Unternehmen ihre Effizienz erheblich steigern und gleichzeitig die Qualität ihrer Datenverarbeitung verbessern. Dedizierte Server bieten die ideale Plattform, um diese Techniken effektiv einzusetzen und das volle Potenzial von LibreOffice auszuschöpfen.

Erweiterte Automatisierungsmöglichkeiten in LibreOffice

LibreOffice bietet nicht nur grundlegende Makros und Skripte, sondern auch eine Vielzahl erweiterter Automatisierungsmöglichkeiten, die es ermöglichen, noch komplexere Aufgaben effizient zu bewältigen. Diese Techniken erfordern ein tieferes Verständnis der LibreOffice-APIs und können maßgeschneiderte Lösungen für spezifische Geschäftsanforderungen schaffen.

UNO-API für erweiterte Anpassungen

Die Universal Network Objects (UNO)-API von LibreOffice ist eine leistungsstarke Möglichkeit, um tief in die Automatisierung von Prozessen einzutauchen. Sie erlaubt es Entwicklern, benutzerdefinierte Funktionen zu erstellen, die weit über die Möglichkeiten einfacher Makros hinausgehen. Mit der UNO-API können beispielsweise individuelle Benutzeroberflächen angepasst oder spezielle Datenverarbeitungsroutinen implementiert werden. Dadurch lässt sich die Software perfekt an die spezifischen Bedürfnisse eines Unternehmens anpassen.

Verwendung von Batch-Prozessen

Batch-Prozesse sind ein weiterer Ansatz zur Automatisierung, der besonders auf dedizierten Servern effektiv eingesetzt werden kann. Sie ermöglichen die Verarbeitung großer Datenmengen in einem einzigen Durchlauf, ohne dass ein menschliches Eingreifen erforderlich ist. Ein typisches Szenario wäre das nächtliche Generieren von Berichten oder die Aktualisierung von Datenbanken, während die Serverauslastung gering ist. Diese Prozesse können so geplant werden, dass sie außerhalb der regulären Arbeitszeiten stattfinden, um die Ressourcen optimal zu nutzen.

Automatisierte Dokumentenverarbeitung

Ein häufiges Einsatzgebiet für die Automatisierung in LibreOffice ist die automatisierte Verarbeitung von Dokumenten. Dazu gehört das Generieren von Serienbriefen, das Zusammenführen von Dokumenten oder das Konvertieren von Dateien in verschiedene Formate. Diese Aufgaben können durch Automatisierung nicht nur schneller, sondern auch konsistenter erledigt werden. Beispielsweise kann ein Skript erstellt werden, das automatisch alle relevanten Informationen aus einer Datenbank zieht und sie in ein vordefiniertes Dokument einfügt.

Best Practices für die Automatisierung

Die Implementierung fortschrittlicher Automatisierungstechniken erfordert sorgfältige Planung und Durchführung. Es gibt einige Best Practices, die Unternehmen berücksichtigen sollten, um den Erfolg ihrer Automatisierungsprojekte sicherzustellen.

Iterative Entwicklung und Testing

Automatisierungslösungen sollten schrittweise entwickelt werden, um Fehler frühzeitig zu erkennen und zu beheben. Es ist ratsam, zunächst mit einem kleinen, überschaubaren Projekt zu beginnen und die Lösung schrittweise zu erweitern. Regelmäßiges Testing ist unerlässlich, um sicherzustellen, dass alle automatisierten Prozesse wie erwartet funktionieren und keine unerwarteten Probleme verursachen.

Schulung und Weiterbildung

Die Einführung neuer Automatisierungstechniken erfordert oft eine Umstellung der Arbeitsweise. Mitarbeiter sollten entsprechend geschult werden, um die neuen Systeme effektiv nutzen zu können. Dies umfasst sowohl die Bedienung der automatisierten Prozesse als auch ein grundlegendes Verständnis der zugrunde liegenden Technologien, um bei Bedarf Anpassungen vornehmen zu können.

Dokumentation und Wissensmanagement

Eine umfassende Dokumentation ist entscheidend für den langfristigen Erfolg von Automatisierungsprojekten. Alle entwickelten Skripte, Makros und Prozesse sollten detailliert dokumentiert werden, um sicherzustellen, dass sie auch von anderen Teammitgliedern verstanden und gewartet werden können. Ein effektives Wissensmanagement hilft, das gesammelte Wissen zu bewahren und neuen Mitarbeitern zugänglich zu machen.

Beispiele aus der Praxis

Viele Unternehmen haben bereits erfolgreich Automatisierungstechniken in LibreOffice implementiert und konnten dadurch signifikante Verbesserungen in ihrer Effizienz und Datenverarbeitung erzielen.

Fallstudie: Finanzberichtserstellung

Ein mittelständisches Unternehmen im Finanzsektor nutzte die Automatisierung in LibreOffice, um den Prozess der Finanzberichtserstellung zu optimieren. Vor der Automatisierung wurden die Berichte manuell erstellt, was zu Inkonsistenzen und Verzögerungen führte. Durch die Implementierung automatisierter Skripte, die Daten aus verschiedenen Quellen zusammenführten und in standardisierte Berichtsvorlagen einfügten, konnte die Bearbeitungszeit um über 50% reduziert und die Genauigkeit der Berichte erheblich gesteigert werden.

Fallstudie: Verwaltung von Kundendaten

Ein weiteres Beispiel ist ein Einzelhandelsunternehmen, das die Automatisierung nutzte, um seine Kundendaten effizienter zu verwalten. Durch die Integration von LibreOffice mit der bestehenden CRM-Datenbank konnte das Unternehmen den Prozess der Datenaktualisierung automatisieren, was zu einer verbesserten Datenqualität und einer personalisierteren Kundenansprache führte.

Durch den Einsatz von Automatisierungstechniken in LibreOffice auf dedizierten Servern können Unternehmen nicht nur ihre Effizienz steigern, sondern auch die Qualität ihrer Geschäftsprozesse verbessern. Die vielfältigen Möglichkeiten, die LibreOffice bietet, ermöglichen es, maßgeschneiderte Lösungen für unterschiedlichste Anforderungen zu entwickeln. Die sorgfältige Planung, Implementierung und Wartung dieser Systeme ist der Schlüssel zum Erfolg in der modernen, datengetriebenen Geschäftswelt.

Debian E/LTS, October 2025

During this month, I have worked on the following tasks for Debian LTS and ELTS.
This was my initial contact with the LTS/ELTS project and preparation of security updates.
Thanks to Freexian and sponsors for making this possible [0].

Log4cxx

Cheers,
Lukas

[0] https://www.freexian.com/lts/debian/#sponsors

Waiting for a Linux system to be online

Designed by Freepik

What is an “online” system?

Networking is a complex topic, and there is lots of confusion around the definition of an “online” system. Sometimes the boot process gets delayed up to two minutes, because the system still waits for one or more network interfaces to be ready. Systemd provides the network-online.target that other service units can rely on, if they are deemed to require network connectivity. But what does “online” actually mean in this context, is a link-local IP address enough, do we need a routable gateway and how about DNS name resolution?

The requirements for an “online” network interface depend very much on the services using an interface. For some services it might be good enough to reach their local network segment (e.g. to announce Zeroconf services), while others need to reach domain names (e.g. to mount a NFS share) or reach the global internet to run a web server. On the other hand, the implementation of network-online.target varies, depending on which networking daemon is in use, e.g. systemd-networkd-wait-online.service or NetworkManager-wait-online.service. For Ubuntu, we created a specification that describes what we as a distro expect an “online” system to be. Having a definition in place, we are able to tackle the network-online-ordering issues that got reported over the years and can work out solutions to avoid delayed boot times on Ubuntu systems.

In essence, we want systems to reach the following networking state to be considered online:

  1. Do not wait for “optional” interfaces to receive network configuration
  2. Have IPv6 and/or IPv4 “link-local” addresses on every network interface
  3. Have at least one interface with a globally routable connection
  4. Have functional domain name resolution on any routable interface

A common implementation

NetworkManager and systemd-networkd are two very common networking daemons used on modern Linux systems. But they originate from different contexts and therefore show different behaviours in certain scenarios, such as wait-online. Luckily, on Ubuntu we already have Netplan as a unification layer on top of those networking daemons, that allows for common network configuration, and can also be used to tweak the wait-online logic.

With the recent release of Netplan v1.1 we introduced initial functionality to tweak the behaviour of the systemd-networkd-wait-online.service, as used on Ubuntu Server systems. When Netplan is used to drive the systemd-networkd backend, it will emit an override configuration file in /run/systemd/system/systemd-networkd-wait-online.service.d/10-netplan.conf, listing the specific non-optional interfaces that should receive link-local IP configuration. In parallel to that, it defines a list of network interfaces that Netplan detected to be potential global connections, and waits for any of those interfaces to reach a globally routable state.

Such override config file might look like this:

[Unit]
ConditionPathIsSymbolicLink=/run/systemd/generator/network-online.target.wants/systemd-networkd-wait-online.service

[Service]
ExecStart=
ExecStart=/lib/systemd/systemd-networkd-wait-online -i eth99.43:carrier -i lo:carrier -i eth99.42:carrier -i eth99.44:degraded -i bond0:degraded
ExecStart=/lib/systemd/systemd-networkd-wait-online --any -o routable -i eth99.43 -i eth99.45 -i bond0

In addition to the new features implemented in Netplan, we reached out to upstream systemd, proposing an enhancement to the systemd-networkd-wait-online service, integrating it with systemd-resolved to check for the availability of DNS name resolution. Once this is implemented upstream, we’re able to fully control the systemd-networkd backend on Ubuntu Server systems, to behave consistently and according to the definition of an “online” system that was lined out above.

Future work

The story doesn’t end there, because Ubuntu Desktop systems are using NetworkManager as their networking backend. This daemon provides its very own nm-online utility, utilized by the NetworkManager-wait-online systemd service. It implements a much higher-level approach, looking at the networking daemon in general instead of the individual network interfaces. By default, it considers a system to be online once every “autoconnect” profile got activated (or failed to activate), meaning that either a IPv4 or IPv6 address got assigned.

There are considerable enhancements to be implemented to this tool, for it to be controllable in a fine-granular way similar to systemd-networkd-wait-online, so that it can be instructed to wait for specific networking states on selected interfaces.

A note of caution

Making a service depend on network-online.target is considered an antipattern in most cases. This is because networking on Linux systems is very dynamic and the systemd target can only ever reflect the networking state at a single point in time. It cannot guarantee this state to be remained over the uptime of your system and has the potentially to delay the boot process considerably. Cables can be unplugged, wireless connectivity can drop, or remote routers can go down at any time, affecting the connectivity state of your local system. Therefore, “instead of wondering what to do about network.target, please just fix your program to be friendly to dynamically changing network configuration.” [source].

Netplan v1.1 released

I’m happy to announce that Netplan version 1.1 is now available on GitHub and is soon to be deployed into a Debian and/or Ubuntu installation near you! Six months and 120 commits after the previous version (including one patch release v1.0.1), this release is brought to you by 17 free software contributors from around the globe. 🚀

Kudos to everybody involved! ❤️

Highlights

  • Custom systemd-networkd-wait-online logic override to wait for link-local and routable interfaces. (#456#482)
  • Modification of the embedded-switch-mode setting without virtual-function (VF) definitions on SR-IOV devices (#454)
  • Parser flag to ignore individual, broken configurations, instead of not generating any backend configuration (#412)
  • Fixes for @ProtonVPN (#495) and @microsoft Azure Linux (#445), contributed by those companies

Releasing v1.1

Documentation

Bug fixes

New Contributors

Full Changelog1.0…1.1

Creating a Netplan enabled system through Debian-Installer

With the work that has been done in the debian-installer/netcfg merge-proposal !9 it is possible to install a standard Debian system, using the normal Debian-Installer (d-i) mini.iso images, that will come pre-installed with Netplan and all network configuration structured in /etc/netplan/.

In this write-up, I’d like to run you through a list of commands for experiencing the Netplan enabled installation process first-hand. Let’s start with preparing a working directory and installing the software dependencies for our virtualized Debian system:

$ mkdir d-i_tmp && cd d-i_tmp
$ apt install ovmf qemu-utils qemu-system-x86

Now let’s download the official (daily) mini.iso, linux kernel image and initrd.gz containing the Netplan enablement changes:

$ wget https://d-i.debian.org/daily-images/amd64/daily/netboot/gtk/mini.iso
$ wget https://d-i.debian.org/daily-images/amd64/daily/netboot/gtk/debian-installer/amd64/initrd.gz
$ wget https://d-i.debian.org/daily-images/amd64/daily/netboot/gtk/debian-installer/amd64/linux

Next we’ll prepare a VM, by copying the EFI firmware files, preparing some persistent EFIVARs file, to boot from FS0:\EFI\debian\grubx64.efi, and create a virtual disk for our machine:

$ cp /usr/share/OVMF/OVMF_CODE_4M.fd .
$ cp /usr/share/OVMF/OVMF_VARS_4M.fd .
$ qemu-img create -f qcow2 ./data.qcow2 20G

Finally, let’s launch the debian-installer using a preseed.cfg file, that will automatically install Netplan (netplan-generator) for us in the target system. A minimal preseed file could look like this:

# Install minimal Netplan generator binary
d-i preseed/late_command string in-target apt-get -y install netplan-generator

For this demo, we’re installing the full netplan.io package (incl. the interactive Python CLI), as well as the netplan-generator package and systemd-resolved, to show the full Netplan experience. You can choose the preseed file from a set of different variants to test the different configurations:

We’re using the linux kernel and initrd.gz here to be able to pass the preseed URL as a parameter to the kernel’s cmdline directly. Launching this VM should bring up the official debian-installer in its netboot/gtk form:

$ export U=https://people.ubuntu.com/~slyon/d-i/netplan-preseed+full.cfg
$ qemu-system-x86_64 \
	-M q35 -enable-kvm -cpu host -smp 4 -m 2G \
	-drive if=pflash,format=raw,unit=0,file=OVMF_CODE_4M.fd,readonly=on \
	-drive if=pflash,format=raw,unit=1,file=OVMF_VARS_4M.fd,readonly=off \
	-device qemu-xhci -device usb-kbd -device usb-mouse \
	-vga none -device virtio-gpu-pci \
	-net nic,model=virtio -net user \
	-kernel ./linux -initrd ./initrd.gz -append "url=$U" \
	-hda ./data.qcow2 -cdrom ./mini.iso;

Now you can click through the normal Debian-Installer process, using mostly default settings. Optionally, you could play around with the networking settings, to see how those get translated to /etc/netplan/ in the target system.

After you confirmed your partitioning changes, the base system gets installed. I suggest not to select any additional components, like desktop environments, to speed up the process.

During the final step of the installation (finish-install.d/55netcfg-copy-config) d-i will detect that Netplan was installed in the target system (due to the preseed file provided) and opt to write its network configuration to /etc/netplan/ instead of /etc/network/interfaces or /etc/NetworkManager/system-connections/.

Done! After the installation finished, you can reboot into your virgin Debian Sid/Trixie system.

To do that, quit the current Qemu process, by pressing Ctrl+C and make sure to copy over the EFIVARS.fd file that was modified by grub during the installation, so Qemu can find the new system. Then reboot into the new system, not using the mini.iso image any more:

$ cp ./OVMF_VARS_4M.fd ./EFIVARS.fd
$ qemu-system-x86_64 \
        -M q35 -enable-kvm -cpu host -smp 4 -m 2G \
        -drive if=pflash,format=raw,unit=0,file=OVMF_CODE_4M.fd,readonly=on \
        -drive if=pflash,format=raw,unit=1,file=EFIVARS.fd,readonly=off \
        -device qemu-xhci -device usb-kbd -device usb-mouse \
        -vga none -device virtio-gpu-pci \
        -net nic,model=virtio -net user \
        -drive file=./data.qcow2,if=none,format=qcow2,id=disk0 \
        -device virtio-blk-pci,drive=disk0,bootindex=1
        -serial mon:stdio

Finally, you can play around with your Netplan enabled Debian system! As you will find, /etc/network/interfaces exists but is empty, it could still be used (optionally/additionally). Netplan was configured in /etc/netplan/ according to the settings given during the d-i installation process.

In our case, we also installed the Netplan CLI, so we can play around with some of its features, like netplan status:

Thank you for following along the Netplan enabled Debian installation process and happy hacking! If you want to learn more, find us at GitHub:netplan.

Netplan v1.0 paves the way to stable, declarative network management

New “netplan status –diff” subcommand, finding differences between configuration and system state

As the maintainer and lead developer for Netplan, I’m proud to announce the general availability of Netplan v1.0 after more than 7 years of development efforts. Over the years, we’ve so far had about 80 individual contributors from around the globe. This includes many contributions from our Netplan core-team at Canonical, but also from other big corporations such as Microsoft or Deutsche Telekom. Those contributions, along with the many we receive from our community of individual contributors, solidify Netplan as a healthy and trusted open source project. In an effort to make Netplan even more dependable, we started shipping upstream patch releases, such as 0.106.1 and 0.107.1, which make it easier to integrate fixes into our users’ custom workflows.

With the release of version 1.0 we primarily focused on stability. However, being a major version upgrade, it allowed us to drop some long-standing legacy code from the libnetplan1 library. Removing this technical debt increases the maintainability of Netplan’s codebase going forward. The upcoming Ubuntu 24.04 LTS and Debian 13 releases will ship Netplan v1.0 to millions of users worldwide.

Highlights of version 1.0

In addition to stability and maintainability improvements, it’s worth looking at some of the new features that were included in the latest release:

  • Simultaneous WPA2 & WPA3 support.
  • Introduction of a stable libnetplan1 API.
  • Mellanox VF-LAG support for high performance SR-IOV networking.
  • New hairpin and port-mac-learning settings, useful for VXLAN tunnels with FRRouting.
  • New netplan status –diff subcommand, finding differences between configuration and system state.

Besides those highlights of the v1.0 release, I’d also like to shed some light on new functionality that was integrated within the past two years for those upgrading from the previous Ubuntu 22.04 LTS which used Netplan v0.104:

  • We added support for the management of new network interface types, such as veth, dummy, VXLAN, VRF or InfiniBand (IPoIB). 
  • Wireless functionality was improved by integrating Netplan with NetworkManager on desktop systems, adding support for WPA3 and adding the notion of a regulatory-domain, to choose proper frequencies for specific regions. 
  • To improve maintainability, we moved to Meson as Netplan’s buildsystem, added upstream CI coverage for multiple Linux distributions and integrations (such as Debian testing, NetworkManager, snapd or cloud-init), checks for ABI compatibility, and automatic memory leak detection. 
  • We increased consistency between the supported backend renderers (systemd-networkd and NetworkManager), by matching physical network interfaces on permanent MAC address, when the match.macaddress setting is being used, and added new hardware offloading functionality for high performance networking, such as Single-Root IO Virtualisation virtual function link-aggregation (SR-IOV VF-LAG).

The much improved Netplan documentation, that is now hosted on “Read the Docs”, and new command line subcommands, such as netplan status, make Netplan a well vested tool for declarative network management and troubleshooting.

Integrations

Those changes pave the way to integrate Netplan in 3rd party projects, such as system installers or cloud deployment methods. By shipping the new python3-netplan Python bindings to libnetplan, it is now easier than ever to access Netplan functionality and network validation from other projects. We are proud that the Debian Cloud Team chose Netplan to be the default network management tool in their official cloud-images for Debian Bookworm and beyond. Ubuntu’s NetworkManager package now uses Netplan as it’s default backend on Ubuntu 23.10 Desktop systems and beyond. Further integrations happened with cloud-init and the Calamares installer.

Please check out the Netplan version 1.0 release on GitHub! If you want to learn more, follow our activities on Netplan.io, GitHub, Launchpad, IRC or our Netplan Developer Diaries blog on discourse.

Netplan brings consistent network configuration across Desktop, Server, Cloud and IoT

Ubuntu 23.10 “Mantic Minotaur” Desktop, showing network settings

We released Ubuntu 23.10 ‘Mantic Minotaur’ on 12 October 2023, shipping its proven and trusted network stack based on Netplan. Netplan is the default tool to configure Linux networking on Ubuntu since 2016. In the past, it was primarily used to control the Server and Cloud variants of Ubuntu, while on Desktop systems it would hand over control to NetworkManager. In Ubuntu 23.10 this disparity in how to control the network stack on different Ubuntu platforms was closed by integrating NetworkManager with the underlying Netplan stack.

Netplan could already be used to describe network connections on Desktop systems managed by NetworkManager. But network connections created or modified through NetworkManager would not be known to Netplan, so it was a one-way street. Activating the bidirectional NetworkManager-Netplan integration allows for any configuration change made through NetworkManager to be propagated back into Netplan. Changes made in Netplan itself will still be visible in NetworkManager, as before. This way, Netplan can be considered the “single source of truth” for network configuration across all variants of Ubuntu, with the network configuration stored in /etc/netplan/, using Netplan’s common and declarative YAML format.

Netplan Desktop integration

On workstations, the most common scenario is for users to configure networking through NetworkManager’s graphical interface, instead of driving it through Netplan’s declarative YAML files. Netplan ships a “libnetplan” library that provides an API to access Netplan’s parser and validation internals, which is now used by NetworkManager to store any network interface configuration changes in Netplan. For instance, network configuration defined through NetworkManager’s graphical UI or D-Bus API will be exported to Netplan’s native YAML format in the common location at /etc/netplan/. This way, the only thing administrators need to care about when managing a fleet of Desktop installations is Netplan. Furthermore, programmatic access to all network configuration is now easily accessible to other system components integrating with Netplan, such as snapd. This solution has already been used in more confined environments, such as Ubuntu Core and is now enabled by default on Ubuntu 23.10 Desktop.

Migration of existing connection profiles

On installation of the NetworkManager package (network-manager >= 1.44.2-1ubuntu1) in Ubuntu 23.10, all your existing connection profiles from /etc/NetworkManager/system-connections/ will automatically and transparently be migrated to Netplan’s declarative YAML format and stored in its common configuration directory /etc/netplan/

The same migration will happen in the background whenever you add or modify any connection profile through the NetworkManager user interface, integrated with GNOME Shell. From this point on, Netplan will be aware of your entire network configuration and you can query it using its CLI tools, such as “sudo netplan get” or “sudo netplan status” without interrupting traditional NetworkManager workflows (UI, nmcli, nmtui, D-Bus APIs). You can observe this migration on the apt-get command line, watching out for logs like the following:

Setting up network-manager (1.44.2-1ubuntu1.1) ...
Migrating HomeNet (9d087126-ae71-4992-9e0a-18c5ea92a4ed) to /etc/netplan
Migrating eduroam (37d643bb-d81d-4186-9402-7b47632c59b1) to /etc/netplan
Migrating DebConf (f862be9c-fb06-4c0f-862f-c8e210ca4941) to /etc/netplan

In order to prepare for a smooth transition, NetworkManager tests were integrated into Netplan’s continuous integration pipeline at the upstream GitHub repository. Furthermore, we implemented a passthrough method of handling unknown or new settings that cannot yet be fully covered by Netplan, making Netplan future-proof for any upcoming NetworkManager release.

The future of Netplan

Netplan has established itself as the proven network stack across all variants of Ubuntu – Desktop, Server, Cloud, or Embedded. It has been the default stack across many Ubuntu LTS releases, serving millions of users over the years. With the bidirectional integration between NetworkManager and Netplan the final piece of the puzzle is implemented to consider Netplan the “single source of truth” for network configuration on Ubuntu. With Debian choosing Netplan to be the default network stack for their cloud images, it is also gaining traction outside the Ubuntu ecosystem and growing into the wider open source community.

Within the development cycle for Ubuntu 24.04 LTS, we will polish the Netplan codebase to be ready for a 1.0 release, coming with certain guarantees on API and ABI stability, so that other distributions and 3rd party integrations can rely on Netplan’s interfaces. First steps into that direction have already been taken, as the Netplan team reached out to the Debian community at DebConf 2023 in Kochi/India to evaluate possible synergies.

Conclusion

Netplan can be used transparently to control a workstation’s network configuration and plays hand-in-hand with many desktop environments through its tight integration with NetworkManager. It allows for easy network monitoring, using common graphical interfaces and provides a “single source of truth” to network administrators, allowing for configuration of Ubuntu Desktop fleets in a streamlined and declarative way. You can try this new functionality hands-on by following the “Access Desktop NetworkManager settings through Netplan” tutorial.


If you want to learn more, feel free to follow our activities on Netplan.io, GitHub, Launchpad, IRC or our Netplan Developer Diaries blog on discourse.