Cloud

Optimierung Ihrer OwnCloud-Umgebung auf dedizierten Root-Servern

by

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.

MaßnahmeVorteilROI-Auswirkung
—————————————————–——————————–
Load BalancingBessere LastverteilungHöhere Nutzerzufriedenheit
CachingSchnellere DatenbereitstellungGeringere Serverlast
AutomatisierungWeniger manuelle EingriffeKostensenkung durch Effizienz

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.

Waiting for a Linux system to be online

by
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.0 paves the way to stable, declarative network management

by

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 v0.107 is now available

by

I’m happy to announce that Netplan version 0.107 is now available on GitHub and is soon to be deployed into a Linux installation near you! Six months and more than 200 commits after the previous version (including a .1 stable release), this release is brought to you by 8 free software contributors from around the globe.

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:

Bug fixes:

A declarative approach to Linux networking with Netplan

by
Photo by Taylor Vick (Unsplash)

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.

Design overview (netplan.io)

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.

Netplan status (Debian)

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.