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

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.

Die Leistung von OwnCloud auf dedizierten Root-Servern zu maximieren, erfordert gezielte Netzwerkoptimierung. Der Einsatz eines dedizierten Servers bietet Ihnen die Kontrolle und Kapazität, um Ihre OwnCloud-Installation zu einem leistungsstarken und effizienten Werkzeug zu machen. Ein optimiertes Netzwerk ist der Schlüssel, um die volle Bandbreite der Möglichkeiten auszuschöpfen, die Ihnen eine solche Infrastruktur bietet.

Leistungsverbesserung durch Netzwerkarchitektur

Die Netzwerkarchitektur bildet das Fundament jedes OwnCloud-Hostings. Durch den gezielten Einsatz von Load Balancing und Caching-Techniken können Sie die Effizienz und Geschwindigkeit Ihrer Server erheblich steigern. Load Balancing sorgt dafür, dass der Datenverkehr gleichmäßig auf alle verfügbaren Ressourcen verteilt wird, wodurch Engpässe vermieden und Reaktionszeiten verkürzt werden.

Caching ist eine weitere Methode, die Ihnen hilft, die Netzwerklast zu reduzieren. Durch das Zwischenspeichern häufig abgefragter Daten direkt im Speicher können Sie die Serverlast verringern und die Antwortzeiten der Cloud spürbar verbessern. Eine Kombination aus Varnish Cache und Redis bietet hier optimale Ergebnisse. Während Varnish Cache statische Inhalte schnell bereitstellen kann, eignet sich Redis ideal für das Zwischenspeichern von Sitzungsdaten und anderen dynamischen Inhalten.

Technische Implementierung von Load Balancing und Caching

• Load Balancing kann durch den Einsatz von NGINX oder HAProxy erreicht werden. Beide Lösungen bieten robuste Funktionen, um den Datenfluss effizient zu steuern.
• Varnish Cache wird durch eine einfache Konfiguration in die bestehende Serverarchitektur integriert. Es ist wichtig, die TTL (Time to Live) der gecachten Inhalte auf die Bedürfnisse Ihrer Nutzer abzustimmen.
• Redis als In-Memory-Datenbank kann sowohl für das Caching von Datenbankabfragen als auch für die Speicherung von Sitzungsdaten eingesetzt werden.

Sicherheit und Stabilität durch Netzwerküberwachung

Die Sicherheit und Stabilität Ihrer OwnCloud-Installation auf einem dedizierten Root-Server hängen maßgeblich von einer effektiven Netzwerküberwachung ab. Durch den Einsatz von Monitoring-Tools wie Zabbix oder Prometheus können Sie die Performance Ihrer Server in Echtzeit überwachen und Engpässe frühzeitig erkennen. Diese Tools bieten Ihnen detaillierte Einblicke in den Netzwerkverkehr und ermöglichen es Ihnen, gezielte Maßnahmen zur Optimierung zu ergreifen.

Ein weiterer wichtiger Aspekt ist die Implementierung von Firewalls und Intrusion Detection Systemen (IDS). Eine gut konfigurierte Firewall schützt Ihre Server vor unbefugtem Zugriff und sorgt dafür, dass nur autorisierte Nutzer auf Ihre OwnCloud-Installation zugreifen können. Ein IDS ergänzt diese Schutzmaßnahmen, indem es verdächtige Aktivitäten im Netzwerk erkennt und Sie rechtzeitig warnt.

• Regelmäßige Updates und Patches sind unerlässlich, um Sicherheitslücken zu schließen und die Stabilität Ihrer OwnCloud-Installation zu gewährleisten.
• Die Implementierung von SSL/TLS-Zertifikaten sorgt dafür, dass alle Datenübertragungen verschlüsselt und gegen unbefugten Zugriff geschützt sind.
• Die Nutzung von VPNs kann den Zugang zu Ihrer OwnCloud-Installation weiter absichern, indem der Datenverkehr durch einen sicheren Tunnel geleitet wird.

Effizienzsteigerung durch Automatisierung und Skripting

Automatisierung ist ein wesentlicher Schlüssel zur Effizienzsteigerung bei der Verwaltung von OwnCloud auf dedizierten Root-Servern. Mit Tools wie Ansible oder Puppet können Sie wiederkehrende Aufgaben automatisieren und die Skalierung Ihrer Infrastruktur vereinfachen. Dies spart nicht nur Zeit, sondern minimiert auch die Fehlerquote bei der Verwaltung komplexer Netzwerkkonfigurationen.

Durch das Erstellen und Implementieren von Skripten können Sie Routineaufgaben effizienter gestalten. Von der automatisierten Aktualisierung der Server bis hin zur regelmäßigen Sicherung Ihrer Daten – gut geschriebene Skripte entlasten Ihre IT-Ressourcen und erhöhen die Zuverlässigkeit Ihrer Infrastruktur.

Implementierung von Automatisierungstools

• Ansible ermöglicht eine einfache Konfiguration und Verwaltung Ihrer Server durch deklarative Playbooks. Diese Playbooks beschreiben den gewünschten Zustand Ihrer Systeme und lassen sich leicht anpassen und erweitern.
• Puppet bietet eine zentrale Verwaltungskonsole, über die Sie Konfigurationsänderungen über eine grafische Oberfläche vornehmen können. Dies ist besonders nützlich in großen Netzwerken mit einer Vielzahl von Knotenpunkten.
• Regelmäßige Backups können durch Cron-Jobs und Shell-Skripte automatisiert werden. Dies stellt sicher, dass immer eine aktuelle Sicherung Ihrer Daten verfügbar ist.

ROI durch optimierte OwnCloud-Umgebung

Die Optimierung Ihrer OwnCloud-Installation auf dedizierten Root-Servern bringt nicht nur technische Vorteile, sondern auch einen klaren Return on Investment (ROI). Durch gesteigerte Effizienz und verbesserte Skalierbarkeit können Sie die Betriebskosten senken und die Benutzerzufriedenheit erhöhen. Eine optimierte Netzwerkumgebung sorgt für schnellere Ladezeiten und weniger Ausfallzeiten, was sich direkt auf die Produktivität Ihrer Nutzer auswirkt.

Die Investition in eine fortschrittliche Netzwerkoptimierung zahlt sich durch verbesserte Leistung und erhöhte Sicherheit aus. Dies ermöglicht es Ihnen, das volle Potenzial Ihrer OwnCloud-Umgebung zu nutzen und langfristige Vorteile zu realisieren.

Erweiterte Netzwerkskalierung und Ressourcenzuweisung

Eine effiziente Ressourcenzuweisung ist entscheidend für die Leistungsfähigkeit Ihrer OwnCloud-Umgebung. Mit der Nutzung von Virtualisierungstechnologien wie Docker oder Kubernetes können Sie Ihre Serverressourcen optimal verteilen und dynamisch anpassen. Diese Technologien ermöglichen es Ihnen, verschiedene Dienste in isolierten Containern auszuführen, was die Flexibilität erhöht und die Komplexität reduziert.

Implementierung von Virtualisierungstechnologien

• Docker: Durch die Nutzung von Docker-Containern können Sie Ihre OwnCloud-Instanzen in einer flexiblen und portablen Umgebung betreiben. Docker ermöglicht es Ihnen, Anwendungen schnell zu deployen und zu skalieren, während der Ressourcenverbrauch minimiert wird.
• Kubernetes: Für größere Infrastrukturen bietet Kubernetes eine leistungsstarke Plattform zur Orchestrierung von Container-Anwendungen. Es automatisiert die Bereitstellung, Skalierung und Verwaltung von Container-Anwendungen, was besonders vorteilhaft in Multi-Server-Umgebungen ist.
• Ressourcenzuweisung: Durch die Definition von Ressourcenlimits und -reservierungen innerhalb von Docker und Kubernetes können Sie sicherstellen, dass Ihre OwnCloud-Instanzen stets die benötigten Ressourcen erhalten, während ungenutzte Kapazitäten für andere Anwendungen freigegeben werden.

Optimierung der Datenbankleistung

Ein weiterer kritischer Aspekt der Optimierung Ihrer OwnCloud-Installation ist die Verbesserung der Datenbankleistung. Da die Datenbank das Rückgrat jeder OwnCloud-Instanz bildet, hat ihre Effizienz einen direkten Einfluss auf die Gesamtleistung des Systems. Die Wahl der richtigen Datenbank und deren Konfiguration kann die Geschwindigkeit und Zuverlässigkeit Ihrer OwnCloud-Umgebung erheblich steigern.

Auswahl und Konfiguration der Datenbank

• MySQL/MariaDB: Diese weit verbreiteten Datenbanken bieten robuste und zuverlässige Leistung für OwnCloud-Installationen. Durch das Tuning von Parametern wie `innodb_buffer_pool_size` und `max_connections` können Sie die Performance weiter steigern.
• PostgreSQL: Als Alternative bietet PostgreSQL erweiterte Funktionen und eine hervorragende Performance bei komplexen Abfragen. Die Optimierung von Parametern wie `shared_buffers` und `work_mem` kann die Effizienz erheblich verbessern.
• Indizes und Query-Optimierung: Durch das Setzen von Indizes auf häufig abgefragte Tabellen und die Optimierung von SQL-Abfragen können Sie die Datenbankzugriffe beschleunigen und die Serverlast reduzieren.

Benutzerverwaltung und Zugriffsrechte

Ein effektives Benutzer- und Rechteverwaltungssystem ist essenziell für die Sicherheit und Effizienz Ihrer OwnCloud-Umgebung. Eine gut strukturierte Verwaltung der Zugriffsrechte stellt sicher, dass Nutzer nur auf die Daten zugreifen können, die für sie bestimmt sind, während die Integrität und Vertraulichkeit sensibler Informationen gewahrt bleibt.

Implementierung eines robusten Zugriffsmanagements

• Gruppenrichtlinien: Durch die Verwendung von Gruppenrichtlinien können Sie Benutzern bestimmte Rollen und Berechtigungen zuweisen. Dies vereinfacht die Verwaltung und sorgt für eine klare Struktur innerhalb der Benutzerverwaltung.
• Zwei-Faktor-Authentifizierung (2FA): Die Implementierung von 2FA erhöht die Sicherheit Ihrer OwnCloud-Installation erheblich, indem sie einen zusätzlichen Schutzmechanismus für den Benutzerzugriff bietet.
• Audit-Logs: Das Führen detaillierter Audit-Logs ermöglicht die Nachverfolgung von Benutzeraktivitäten und die Erkennung potenzieller Sicherheitsvorfälle. Diese Logs sind ein wertvolles Werkzeug zur Einhaltung von Compliance-Vorgaben und zur Analyse von Sicherheitslücken.

Netzwerkredundanz und Ausfallsicherheit

Die Gewährleistung von Netzwerkredundanz und Ausfallsicherheit ist entscheidend, um die Verfügbarkeit Ihrer OwnCloud-Umgebung zu maximieren. Durch den Einsatz von Redundanzstrategien können Sie sicherstellen, dass Ihre Dienste auch im Falle eines Hardwareausfalls oder anderer Störungen weiter verfügbar bleiben.

Strategien für eine robuste Netzwerkverfügbarkeit

• Georedundanz: Durch die Verteilung Ihrer Server auf mehrere geografische Standorte können Sie das Risiko eines vollständigen Systemausfalls minimieren. Diese Strategie erhöht die Ausfallsicherheit und reduziert die Latenz für internationale Benutzer.
• Failover-Mechanismen: Die Implementierung von automatisierten Failover-Mechanismen stellt sicher, dass bei einem Ausfall eines Servers sofort ein Backup-Server aktiviert wird, um die Dienstverfügbarkeit aufrechtzuerhalten.
• Load Balancer mit Redundanz: Der Einsatz redundanter Load Balancer sorgt für eine gleichmäßige Lastverteilung und verbessert die Ausfallsicherheit, indem sie verhindern, dass ein einzelner Ausfall den gesamten Datenverkehr beeinträchtigt.

Durch die weitere Vertiefung dieser Aspekte und die Implementierung der genannten Maßnahmen können Sie die Effizienz, Sicherheit und Zuverlässigkeit Ihrer OwnCloud-Umgebung auf dedizierten Root-Servern erheblich verbessern.

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].

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

• CI: adopt autopkgtest for 1.0-1 on 22.04 by @slyon in #446
• tools/keyfile_to_yaml: display the generated YAML by @daniloegea in #452
• tests: import the config fuzzing tests by @daniloegea in #453
• ATTN: parse/bonds: handle same primary in multiple bonds by @daniloegea in #451
• sriov: accept setting the eswitch mode without VFs (LP#2020409) by @daniloegea in #454
• Custom systemd-networkd-wait-online override to wait on interfaces. (Closes: #1008995) (LP#2060311) by @slyon in #456
• Ignore bad NetDefs and files via parser flags by @daniloegea in #412
• networkd:apply: Drop handling of legacy wpa@ instance units by @slyon in #471
• migrate: support aliases by @Kristof0127 in #473
• networkd: add ipv6 ra overrides (LP#1973222) by @KhooHaoYit in #461
• netplan status –diff fixes and improvements by @daniloegea in #466
• apply: make sure that networkd is restarted when needed by @alfonsosanchezbeato in #449
• Don’t escape certain non-ascii characters by @daniloegea in #486
• networkd: make s-n-wait-online wait for at least one routable interface by @slyon in #482
• networkd: Implement ipv6-address-generation: stable-privacy by @tatokis in #480
• Implementing advmss ip route option by @barvius in #489
• meson: Add ‘testing’ option by @slyon in #493
• Add a scheduled workflow to run TICS by @daniloegea in #498
• ci: migrate to Ubuntu 24.04 by @daniloegea in #465
• Prepare Netplan v1.1 by @slyon in #504

Documentation

• Fix wrong syntax in example by @fzakfeld in #459
• Tutorial improvements by @rkratky in #458
• added guide for contributing to the netplan documentation by @ade555 in #457
• Add initial SECURITY.md policy by @slyon in #478
• Create single-nic-vm-host.md by @ilvipero in #475
• Create single-nic-vm-host-with-vlans.md by @ilvipero in #476
• Create multi-nic-vm-host-with-bonds-and-vlans.md by @ilvipero in #477
• bullet point removal by @shirleyherox in #483
• Add netplan try to netplan tutorial by @davidekete in #494
• Update the docs checks runner to ubuntu-latest by @rkratky in #500
• Add spelling exceptions by @rkratky in #499

Bug fixes

• Fix logging setup when python-rich is not present by @frhuelsz in #445
• parse-nm: add a workaround for the DoT DNS option (LP#2055148) by @daniloegea in #447
• parse: don’t remove datalist items during iteration by @daniloegea in #450
• parse: fix redefinition of gateway(4|6) by @daniloegea in #460
• python: elements of all must be strings by @daniloegea in #464
• CI: Fix DebCI check, using newer ‘meson’ from unstable by @slyon in #467
• tests: fix diff test with iproute2 6.8 by @daniloegea in #469
• cli/generate: skip daemon_reload with –mapping by @daniloegea in #470
• CI: fork spread to get snapcore/spread#179 fixes by @slyon in #472
• ctests: fix a memory leak in a unit test by @daniloegea in #474
• nm/nd: fix a couple of crashes by @daniloegea in #468
• test:integration: Try to improve test flakyness (Closes: #1069871) by @slyon in #481
• Security fixes (CVE-2022-4968) by @daniloegea in #484
• emitter: allow unicode characters in the emitter (LP#2071652) by @daniloegea in #485
• CLI:apply: call udevadm trigger, using –action=move (Closes: #1071220) (LP#2066344, LP#2071363) by @slyon in #479
• CI: fix CodeQL permissions by @slyon in #491
• ci: run meson tests with unbuffer by @daniloegea in #501
• ci/tics: install “expect” as a dependency by @daniloegea in #502
• generate: avoid calling ‘udevadm control –reload’ (LP#1999178) by @slyon in #488
• netplan ignores NetworkManager ipv4.route-metric (LP#2076172) by @calexandru2018 in #495
• Change default umask when creating dirctories (LP#2076319) by @rmalz-c in #497

New Contributors

• @frhuelsz made their first contribution in #445
• @fzakfeld made their first contribution in #459
• @Kristof0127 made their first contribution in #473
• @ade555 made their first contribution in #457
• @KhooHaoYit made their first contribution in #461
• @ilvipero made their first contribution in #475
• @shirleyherox made their first contribution in #483
• @tatokis made their first contribution in #480
• @barvius made their first contribution in #489
• @davidekete made their first contribution in #494
• @calexandru2018 made their first contribution in #495
• @rmalz-c made their first contribution in #497

Full Changelog: 1.0…1.1

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:

• Netplan minimal
  • https://people.ubuntu.com/~slyon/d-i/netplan-preseed.cfg
• Netplan + systemd-resolved configuration
  • https://people.ubuntu.com/~slyon/d-i/netplan-preseed+full.cfg
• Netplan + NetworkManager configuration
  • https://people.ubuntu.com/~slyon/d-i/netplan-preseed+nm.cfg

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.

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.

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.

Highlights

Highlights of this release include the new configuration types for veth and dummy interfaces:

network:
  version: 2
  virtual-ethernets:
    veth0:
      peer: veth1
    veth1:
      peer: veth0
  dummy-devices:
    dm0:
      addresses:
        - 192.168.0.123/24
      ...

Furthermore, we implemented CFFI based Python bindings on top of libnetplan’s API, that can easily be consumed by 3rd party applications (see full cffi-bindings.py example):

from netplan import Parser, State, NetDefinition
from netplan import NetplanException, NetplanParserException

parser = Parser()

# Parse the full, existing YAML config hierarchy
parser.load_yaml_hierarchy(rootdir='/')

# Validate the final parser state
state = State()
try:
    # validation of current state + new settings
    state.import_parser_results(parser)
except NetplanParserException as e:
    print('Error in', e.filename, 'Row/Col', e.line, e.column, '->', e.message)
except NetplanException as e:
    print('Error:', e.message)

# Walk through ethernet NetdefIDs in the state and print their backend
# renderer, to demonstrate working with NetDefinitionIterator &
# NetDefinition
for netdef in state.ethernets.values():
    print('Netdef', netdef.id, 'is managed by:', netdef.backend)
    print('Is it configured to use DHCP?', netdef.dhcp4 or netdef.dhcp6)

Changelog:

• Support for “dummy” (dummy-devices) interfaces (LP#1774203) by @daniloegea in #361
• Support for “veth” (virtual-ethernets) interfaces by @daniloegea in #368
• Add Python bindings for libnetplan by @slyon in #385
• netplan: Handle command exceptions by @daniloegea in #334
• WPA3 (personal) support (LP#2023238) by @daniloegea in #369
• Add all the commands to the bash completion file (LP#1749869) by @daniloegea in #326
• New submodule for state manipulation by @daniloegea in #379
• commands/status: show routes from all routing tables by @daniloegea in #390
• cli:status: Make rich pretty printing optional by @slyon in #388
• libnetplan: expose dhcp4 and dhcp6 properties by @daniloegea in #394
• Expose macaddress and DNS configuration from the netdef by @daniloegea in #395
• libnetplan: expose the routes list in the netdef by @daniloegea in #397
• NetworkManager: Wireguard private key flag support by @daniloegea in #371
• Add a netplan_parser_load_keyfile() Python binding by @daniloegea in #351
• keyfile parser: add support for all tunnel types (LP#2016473) by @daniloegea in #360
• parse-nm:wg: add support for reading the listen-port property by @daniloegea in #372
• parse-nm: add support for VRF devices by @daniloegea in #398
• Vlan keyfile parser support by @daniloegea in #370
• Netplan docs rework by @daniloegea in #333 & #337
• docs: Add a short netplan-everywhere howto by @daniloegea in #325
• doc: make us of sphinx copybutton plugin by @slyon in #354
• doc: Add Ubuntu Code of Conduct 2.0 by @slyon in #355
• doc: Explanation about 00-network-manager-all.yaml by @slyon in #378

Bug fixes:

• Fix FTBFS on Fedora and refresh RPM packaging by @Conan-Kudo in #323
• parser: validate lacp-rate properly (LP#1745648) by @daniloegea in #324
• meson: use meson-make-symlink.sh helper script instead of install_symlink() by @slyon in #327
• netplan: cli: fix typo from ‘unkown’ to ‘unknown’ by @AristoChen in #328
• Handle duplication during parser second pass (LP#2007682) by @daniloegea in #329
• parse:ovs: Ignore deprecated OpenFlow1.6 protocol (LP#1963735) by @slyon in #332
• dbus: Build the copy path correctly by @daniloegea in #331
• tests: add new spread based snapd integration test by @mvo5 in #330
• Use controlled execution environment, to avoid failure if PATH is unset (LP#1959570) by @slyon in #336
• Some refactoring by @slyon in #338
• netplan: adjust the maximum buffer size to 1MB by @daniloegea in #340
• parse: use “–” with systemd-escape by @daniloegea in #347
• docs: fix bridge parameters types and add examples by @daniloegea in #346
• vrfs: skip policies parsing if list is NULL (LP#2016427) by @daniloegea in #341
• networkd: plug a memory leak by @daniloegea in #344
• libnetplan: don’t try to read from a NULL file by @daniloegea in #342
• nm: return if write_routes() fails by @daniloegea in #345
• parse: plug a memory leak by @daniloegea in #348
• parse: set the backend on nm-devices to NM by default by @daniloegea in #349
• parse: don’t point to the wrong node on validation by @daniloegea in #343
• rtd: set the OS and Python versions explicitly by @daniloegea in #357
• Fix 8021x eap method parsing (LP#2016625) by @daniloegea in #358
• CI: update canonical/setup-lxd to v0.1.1 by @barrettj12 in #359
• CI: fix dch after adding the new 0.106.1 tag by @daniloegea in #364
• Provide frequency to wpa_supplicant when in adhoc mode (LP#2020754) by @yevmel in #363
• Improve the coverage of the memory leak tests by @daniloegea in #365
• Fix keyfile parsing of wireguard config when the prefix of allowed IPs is omited by @daniloegea in #366
• routes: fix metric rendering (LP#2023681) by @bengentil in #367
• CI: add DebCI integration test by @slyon in #362
• CI: initial NetworkManager autopkgtests by @slyon in #374
• parse-nm: handle cloned-mac-address special cases (LP#2026230) by @daniloegea in #376
• Improve autopkgtest stability with systemd 253 & iproute 6.4 by @slyon in #377
• Fixes for minor issues by @daniloegea in #380
• tests:integration: Adopt for systemd v254 (Closes: #1041310) by @slyon in #381
• parse: Downgrade NM passthrough warning to debug by @slyon in #384
• netplan.c: Don’t drop files with just global values on ‘set’ (LP#2027584) by @slyon in #382
• Fixing Coverity issues by @daniloegea in #383
• CLI: Refactoring to avoid namespace clash with public bindings by @slyon in #387
• tests: fix test coverage report with newer python-coverage by @daniloegea in #389
• github: add a scheduled action to run Coverity by @daniloegea in #391
• github: only run the coverity workflow on our repository by @daniloegea in #392
• Addressing a few issues found by coverity by @daniloegea in #393
• Wireguard fixes by @daniloegea in #352
• Fix a memory leak, an assert and an error message by @daniloegea in #350
• ovs: don’t allow peers with the same name by @daniloegea in #353
• CI: make use of the canonical/setup-lxd action by @slyon in #356

Linux networking can be confusing due to the wide range of technology stacks and tools in use, in addition to the complexity of the surrounding network environment. The configuration of bridges, bonds, VRFs or routes can be done programmatically, declaratively, manually or with automated with tools like ifupdown, ifupdown2, ifupdown-ng, iproute2, NetworkManager, systemd-networkd and others. Each  of these tools use different formats and locations to store their configuration files. Netplan, a utility for easily configuring networking on a Linux system, is designed to unify and standardise how administrators interact with these underlying technologies. Starting from a YAML description of the required network interfaces and what each should be configured to do, Netplan will generate all the necessary configuration for your chosen tool.

In this article, we will provide an overview of how Ubuntu uses Netplan to manage Linux networking in a unified way. By creating a common interface across two disparate technology stacks, IT administrators benefit from a unified experience across both desktops and servers whilst retaining the unique advantages of the underlying tech.

But first, let’s start with a bit of history and show where we are today.

The history of Netplan in Ubuntu

Starting with Ubuntu 16.10 and driven by the need to express network configuration in a common way across cloud metadata and other installer systems, we had the opportunity to switch to a network stack that integrates better with our dependency-based boot model. We chose systemd-networkd on server installations for its active upstream community and because it was already part of Systemd and therefore included in any Ubuntu base installation. It has a much better outlook for the future, using modern development techniques, good test coverage and CI integration, compared to the ifupdown tool we used previously. On desktop installations, we kept using NetworkManager due to its very good integration with the user interface.

Having to manage and configure two separate network stacks, depending on the Ubuntu variant in use, can be confusing, and we wanted to provide a streamlined user experience across any flavour of Ubuntu. Therefore, we introduced Netplan.io as a control layer above systemd-networkd and NetworkManager. Netplan takes declarative YAML files from /etc/netplan/ as an input and generates corresponding network configuration for the relevant network stack backend in /run/systemd/network/ or /run/NetworkManager/ depending on the system configuration. All while keeping full flexibility to control the underlying network stack in its native way if need be.

Who is using Netplan?

Recent versions of Netplan are available and ready to be installed on many distributions, such as Ubuntu, Fedora, RedHat Enterprise Linux, Debian and Arch Linux.

Ubuntu

As stated above, Netplan has been installed by default on Ubuntu systems since 2016 and is therefore being used by millions of users across multiple long-term support versions of Ubuntu (18.04, 20.04, 22.04) on a day-to-day basis. This covers Ubuntu server scenarios primarily, such as bridges, bonding, VLANs, VXLANs, VRFs, IP tunnels or WireGuard tunnels, using systemd-networkd as the backend renderer.

On Ubuntu desktop systems, Netplan can be used manually through its declarative YAML configuration files, and it will handle those to configure the NetworkManager stack. Keep reading to get a glimpse of how this will be improved through automation and integration with the desktop stack in the future.

Cloud

It might not be as obvious, but many people have been using Netplan without knowing about it when configuring a public cloud instance on AWS, Google Cloud or elsewhere through cloud-init. This is because cloud-init’s “Networking Config Version 2” is a passthrough configuration to Netplan, which will then set up the underlying network stack on the given cloud instance. This is why Netplan is also a key package on the Debian distribution, for example, as it’s being used by default on Debian cloud images, too.

Our vision for Linux networking

We know that Linux networking can be a beast, and we want to keep simple things simple. But also allow for custom setups of any complexity. With Netplan, the day-to-day networking needs are covered through easily comprehensible and nicely documented YAML files, that describe the desired state of the local network interfaces, which will be rendered into corresponding configuration files for the relevant network stack and applied at (re-)boot or at runtime, using the “netplan apply” CLI. For example /etc/netplan/lan.yaml:

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: true

Having a single source of truth for network configuration is also important for administrators, so they do not need to understand multiple network stacks, but can rely on the declarative data given in /etc/netplan/ to configure a system, independent of the underlying network configuration backend. This is also very helpful to seed the initial network configuration for new Linux installations, for example through installation systems such as Subiquity, Ubuntu’s desktop installer or cloud-init across the public and private clouds.

In addition to describing and applying network configuration, the “netplan status” CLI can be used to query relevant data from the underlying network stack(s), such as systemd-networkd, NetworkManager or iproute2, and present them in a unified way.

At the Netplan project we strive for very high test automation and coverage with plenty of unit tests, integration tests and linting steps, across multiple Linux distros, which gives high confidence in also supporting more advanced networking use cases, such as Open vSwitch or SR-IOV network virtualization, in addition to normal wired (static IP, DHCP, routing), wireless (e.g. wwan modems, WPA2/3 connections, WiFi hotspot, controlling the regulatory domain, …) and common server scenarios.

Should there ever be a scenario that is not covered by Netplan natively, it allows for full flexibility to control the underlying network stack directly through systemd override configurations or NetworkManager passthrough settings in addition to having manual configuration side-by-side with interfaces controlled through Netplan.

The future of Netplan desktop integration

On workstations, the most common scenario is for end users to configure NetworkManager through its user interface tools, instead of driving it through Netplan’s declarative YAML files, which makes use of NetworkManager’s native configuration files. To avoid Netplan just handing over control to NetworkManager on such systems, we’re working on a bidirectional integration between NetworkManager and Netplan to further improve the “single source of truth” use case on Ubuntu desktop installations.

Netplan is shipping a “libnetplan” library that provides an API to access Netplan’s parser and validation internals, that can be used by NetworkManager to write back a network interface configuration. For instance, configuration given through NetworkManager’s UI tools or D-Bus API can be exported to Netplan’s native YAML format in the common location at /etc/netplan/. This way, administrators just need to care about Netplan when managing a fleet of Desktop installations. This solution is currently being used in more confined environments, like Ubuntu Core, when using the NetworkManager snap, and we will deliver it to generic Ubuntu desktop systems in 24.04 LTS.

In addition to NetworkManager, libnetplan can also be used to integrate with other tools in the networking space, such as cloud-init for improved validation of user data or installation systems when seeding new Linux images.

Conclusion

Overall, Netplan can be considered to be a good citizen within a network environment that plays hand-in-hand with other networking tools and makes it easy to control modern network stacks, such as systemd-networkd or NetworkManager in a common, streamlined and declarative way. It provides a “single source of truth” to network administrators about the network state, while keeping simple things simple, but allowing for arbitrarily complex custom setups.
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.

If you want to experiment with systemd-networkd and Netplan on Debian, this can be done easily in QEMU using the official images. To start, you need to download the relevant .qcow2 Debian cloud-image from: https://cloud.debian.org/images/cloud/bookworm/latest/

$ wget https://cloud.debian.org/images/cloud/bookworm/latest/debian-12-generic-amd64.qcow2

Prepare a cloud image

Next, you need to prepare some configuration files for cloud-init and Netplan, to prepare a data-source (seed.img) for your local cloud-image.

$ cat > meta.yaml <<EOF
instance-id: debian01
local-hostname: cloudimg
EOF

$ cat > user.yaml <<EOF
#cloud-config
ssh_pwauth: true
password: test
chpasswd:
  expire: false
EOF

$ cat > netplan.yaml <<EOF
network:
  version: 2
  ethernets:
    id0:
      match:
        macaddress: "ca:fe:ca:fe:00:aa"
      dhcp4: true
      dhcp6: true
      set-name: lan0
EOF

Once all configuration is prepared, you can create the local data-source image, using the cloud-localds tool from the cloud-image-utils package:

$ cloud-localds --network-config=netplan.yaml seed.img user.yaml meta.yaml

Launch the local VM

Now, everything is prepared to launch a QEMU VM with two NICs and do some experimentation! The following command will launch an ephemeral environment for you, keeping the original Debian cloud-image untouched. If you want to preserve any changes on disk, you can remove the trailing -snapshot parameter.

$ qemu-system-x86_64 \
  -machine accel=kvm,type=q35 \
  -cpu host \
  -m 2G \
  -device virtio-net-pci,netdev=net0,mac=ca:fe:ca:fe:00:aa \
  -netdev user,id=net0,hostfwd=tcp::2222-:22 \
  -nic user,model=virtio-net-pci,mac=f0:0d:ca:fe:00:bb \
  -drive if=virtio,format=qcow2,file=debian-12-generic-amd64.qcow2 \
  -drive if=virtio,format=raw,file=seed.img -snapshot

We set up the default debian user account through cloud-init’s user-data configuration above, so you can now login to the system, using that user with the (very unsafe!) password “test”.

$ ssh -o "StrictHostKeyChecking=no" -o "UserKnownHostsFile=/dev/null" -p 2222 debian@localhost # password: test

Experience Netplan and systemd-networkd

Once logged in successfully, you can execute the netplan status command to check the system’s network configuration, as configured through cloud-init’s netplan.yaml passthrough. So you’ve already used Netplan at this point implicitly and it did all the configuration of systemd-networkd for you in the background!

debian@cloudimg:~$ sudo netplan status -a
     Online state: online
    DNS Addresses: 10.0.2.3 (compat)
       DNS Search: .

●  1: lo ethernet UNKNOWN/UP (unmanaged)
      MAC Address: 00:00:00:00:00:00
        Addresses: 127.0.0.1/8
                   ::1/128
           Routes: ::1 metric 256

●  2: enp0s2 ethernet DOWN (unmanaged)
      MAC Address: f0:0d:ca:fe:00:bb (Red Hat, Inc.)

●  3: lan0 ethernet UP (networkd: id0)
      MAC Address: ca:fe:ca:fe:00:aa (Red Hat, Inc.)
        Addresses: 10.0.2.15/24 (dhcp)
                   fec0::c8fe:caff:fefe:aa/64
                   fe80::c8fe:caff:fefe:aa/64 (link)
    DNS Addresses: 10.0.2.3
           Routes: default via 10.0.2.2 from 10.0.2.15 metric 100 (dhcp)
                   10.0.2.0/24 from 10.0.2.15 metric 100 (link)
                   10.0.2.2 from 10.0.2.15 metric 100 (dhcp, link)
                   10.0.2.3 from 10.0.2.15 metric 100 (dhcp, link)
                   fe80::/64 metric 256
                   fec0::/64 metric 100 (ra)
                   default via fe80::2 metric 100 (ra)

As you can see from this output, the lan0 interface is configured via the “id0” Netplan ID to be managed by systemd-networkd. Compare this data to the netplan.yaml file above, the networkctl output, the local Netplan configuration in /etc/netplan/ and the auto-generated systemd-networkd configuration.

debian@cloudimg:~$ networkctl 
IDX LINK   TYPE     OPERATIONAL SETUP     
  1 lo     loopback carrier     unmanaged
  2 enp0s2 ether    off         unmanaged
  3 lan0   ether    routable    configured

3 links listed.

debian@cloudimg:~$ cat /etc/netplan/50-cloud-init.yaml 
# [...]
network:
    ethernets:
        id0:
            dhcp4: true
            dhcp6: true
            match:
                macaddress: ca:fe:ca:fe:00:aa
            set-name: lan0
    version: 2

debian@cloudimg:~$ ls -l /run/systemd/network/
total 8
-rw-r--r-- 1 root root  78 Jul  5 15:23 10-netplan-id0.link
-rw-r--r-- 1 root root 137 Jul  5 15:23 10-netplan-id0.network

Now you can go ahead and try something more advanced, like link aggregation, using the second NIC that you configured for this QEMU VM and explore all the possibilities of Netplan on Debian, by checking the Netplan YAML documentation.