staging.inyokaproject.org

9. Februar 2020

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

Routed Netzwerkkonfiguration mit Netplan

Schon seit langer Zeit hoste ich meine Seiten bei Hetzner auf einem eigenen Server. Nun, nach langer reiner Debian-Zeit habe ich mal wieder einen Ubuntu-Server aufgesetzt und durfte Bekanntschaft mit netplan machen, dass unter Ubuntu ifupdown abgelöst hat. Dieses lässt sich natürlich wieder nachträglich installieren, aber ich wollte netplan einfach mal eine Chance geben.

Die Konfiguration selbst findet unter /etc/netplan statt. Dort habe ich ein neues File mit dem Namen 10-hetzner-network.yaml angelegt. Im Grunde genommen ist der Name allerdings egal, lediglich die Zahl zu Beginn bestimmt die Priorisierung.

netplan erwartet, wie die Dateiendung schon verrät die Konfiguration im YAML-Format. Meine neuste Hassliebe, da dort auf eine korrekte Syntax und auch Einrückung geachtet werden muss.

Mein derzeitiges Setup bei Hetzner sieht wie folgt aus: 1 Server mit Proxmox, mehrere Einzel-IPs sowie ein IPv6-Subnetz. Die virtuellen Maschinen sind per routed-Setup angebunden. Unter Debian ist die Konfiguration mittels pointopoint relativ simpel, aber auch unter netplan muss eine entsprechende Route angelegt werden.
Die folgende Konfiguration bringt einer virtuellen Maschine mit Ubuntu somit IPv4 + IPv6.

network:
  version: 2
  renderer: networkd
  ethernets:
    ens18:
      addresses:
        - xxx.xxx.xxx.xxx/32
        - "xxxx:xxxx:xxxx:xxxx::6/64"
      routes:
        - to: 0.0.0.0/0
          via: xxx.xxx.xxx.xxx
          on-link: true
      dhcp4: no
      dhcp6: no
      gateway4: xxx.xxx.xxx.xxx
      gateway6: xxxx:xxxx:xxxx:xxxx::xxxx
      nameservers:
          addresses: [213.133.99.99,213.133.100.100,213.133.98.98,"2a01:4f8:0:1::add:9898","2a01:4f8:0:1::add:1010","2a01:4f8:0:1::add:9999"]

Das schöne an netplan ist, die Funktion netplan try, womit die Konfiguration auf Fehler geprüft wird und man diese dann mit Enter bestätigen muss bevor diese aktiv wird. Ist man sich seiner Sache sicher, kann man aber auch direkt netplan apply verwenden.

8. Februar 2020

Lesern dieses Blogs wird geläufig sein, dass ich elementary OS für eines der spannendsten Projekte am Linux Desktop halte. Die Entwickler sammeln nun Geld für einen Entwicklersprint. Das Ziel ist das App Center und die Flatpak Entwicklung voran zu bringen.

Elementary OS ist ein Distribution für den Desktop. Als Basis nutzt man die jeweilige Ubuntu LTS Version. Darauf aufbauend entwickelt man einen eigenen Desktop, die Pantheon Shell, sowieso zahlreiche eigene Programme. Das Ziel ist eine möglichst optimale Integration der Programm und des Desktops - sowohl funktional als auch optisch. Inspiriert wird das Projekt offenkundig von macOS.

Elementary OS war hier schon ein paar Mal Thema:

Vergangenes Jahr kündigte man bereits an zukünftig stärker auf Flatpaks setzen zu wollen. Ich bin da skeptisch, weil die Ubuntu Basis in Richtung Snaps steuert, halte en grundsätzlichen Weg in Richtung der neuen Formate aber für richtig und zukunftsweisen (siehe: Snaps oder Flatpaks - Es gibt kein zurück).

Mit der Crowdfunding-Kampagne möchte man den weltweit verstreuten Entwicklern ermöglichen für einen Sprint zusammen zu kommen und die Entwicklung zu forcieren.

Apps sollen zukünftig als Flatpaks ausgeliefert werden und dadurch unabhängig von den alten Bibliotheken an der Basis funktionieren. Gegenwärtig ist die Basis mit Ubuntu 18.04 mal wieder in die Jahre gekommen und elementary OS wird sicherlich nicht vor Jahresmitte auf die neue Version 20.04 aktualisieren. Sowas erschwert natürlich die Entwicklung. Nebenbei gibt es natürlich auch Vorteile für die Anwender, da Apps in einer Sandbox laufen.

Außerdem möchten die Entwickler ihr eigenes App-Ökosystem in Form einer Flatpak-Quelle auch für andere Distributionen öffnen.

Ich finde das Projekt verdient Unterstützung!

"

7. Februar 2020

Falls jemandem der Titel dieses Post bekannt vorkommen sollte: Das ist Absicht. Ein gewisser [ENC]BladeXP hatte Ende 2016 bereits einen Artikel zu dieser Thematik geschrieben, und ich wollte das Experiment mal auf einem aktuellen System wiederholen. Allerdings mit einer kleinen Ergänzung: Ich habe mir auch die Zeiten für die Dekompression angesehen.

Verwendet wurde hierfür ein System mit einer NVMe SSD, einem Intel Core i7-8550U, sowie 16GB RAM.

Erzeugen der Ramdisk + Kompression

Nach jedem Kernelupdate muss unter Archlinux mit Hilfe des Tools mkinitcpio eine neue Ramdisk erzeugt werden, welche der Kernel zum Booten benötigt.

In der Tabelle befindet sich dafür jeweils die Angabe des Kompressionsalgorithmus, die Größe der Fallback- und der Standard-Ramdisk, sowie die dafür benötigte Zeit. Der Prozentwert setzt lediglich die erzeugte Dateigröße in Relation zu einer unkomprimierten Ramdisk.

Algorithmus Fallback (MB) Standard (MB) Zeit (s) Prozent (%)
cat (none) 127 66 12,9 100,0
gzip 39 22 22,0 31,6
bzip2 37 21 26,6 30,1
lzma 27 15 122,9 21,8
xz 27 15 122,6 21,8
lzop 55 31 13,4 44,6
lz4 58 31 13,4 46,1
zstd 38 21 13,4 30,6

cat (none)
Erzeugung der Ramdisk ohne Kompression. Geht zwar schnell, erzeugt aber auch die größten Dateien. Einziger Nachteil ist der relativ hohe Platzverbrauch.

gzip, bzip2
Die beiden etwas älteren Kompressionsformate erzeugen zwar bereits relativ kleine Dateien, brauchen dafür aber auch grob die doppelte Zeit. Nicht zu empfehlen, zumal die Dekompression relativ langsam ist.

lzma, xz
Sowohl lzma als auch xz erzeugen sehr kleine Dateien, brauchen dafür aber auch gut die zehnfache Zeit. Für gewisse Szenarien mag das Sinn ergeben, hier allerdings nicht.

lzop, lz4, zstd
Die drei Verfahren erzeugen mit kaum wahrnehmbaren Overhead (gerade mal 0,5s im Vergleich zu cat) relativ kleine Dateien, wobei zstd auf eine ähnliche Kompressionsrate wie gzip bzw. bzip2 kommt. Leider ist zstd noch nicht fester Bestandteil des Kernels, und ein Booten einer mit zstd komprimierten Ramdisk daher nicht so einfach möglich. Auch wenn lz4 minimal größere Dateien als lzop erzeugt rate ich zu lz4, da die Dekompressionsgeschwindigkeit (wie man gleich sehen wird) bei lz4 wesentlich höher ist.

Lesen der Ramdisk + Dekompression

Die Dekompressionszeit zu messen war leider nicht ganz so einfach. Letztlich habe ich mich dafür entschieden Werte zu nehmen, die ich aus diversen Quellen zusammengetragen, und einer Plausabilitätsprüfung unterzogen habe. Außerdem ist die Dekompression alleine nicht entscheidend für den Bootvorgang, sondern muss auch in Relation zur Lesegeschwindigkeit des Speichermediums gesehen werden.

In der folgenden Tabelle habe ich meine NVMe SSD als Referenz genommen, welche lesend ca. 1,5GB/s schafft.

Algorithmus Größe (MB) Lesen (s) Dekompression (MB/s) Zeit (s) Gesamt (s) Prozent (%)
cat (none) 66 0,044 – – 0,044 100,0
gzip 22 0,015 684 0,032 0,047 106,4
bzip2 21 0,014 171 0,123 0,137 310,9
lzma 15 0,010 335 0,045 0,055 124,5
xz 15 0,010 308 0,049 0,059 133,4
lzop 31 0,021 950 0,033 0,053 121,1
lz4 31 0,021 2000 0,016 0,036 82,2
zstd 21 0,014 1600 0,013 0,027 61,6

Wie man sehen kann ist der Lesevorgang plus die Zeit, welche die Dekompression benötigt, nur bei Einsatz von lz4 oder zstd unter der Zeit, die eine unkomprimierte Ramdisk benötigt. Bei sehr schnellen Speichermedien ist es also fraglich, ob man überhaupt eine Kompression anwenden sollte. Der einzige Vorteil sind die reduzierte Anzahl der Schreib-/Lesezyklen auf das Speichermedium, im Bootvorgang selbst macht es aber keinen Unterschied mehr. Zumal wir hier von Zeit im Bereich weniger Millisekunden reden.

Spannender wird es, wenn man ein etwas langsameres Speichermedium verwendet. Als Beispiel eine SATA-3 SSD welche "nur" 500MB/s lesend schafft:

Algorithmus Größe (MB) Lesen (s) Dekompression (MB/s) Zeit (s) Gesamt (s) Prozent (%)
cat (none) 66 0,132 – – 0,132 100,0
gzip 22 0,044 684 0,089 0,076 57,7
bzip2 21 0,042 171 0,339 0,165 124,9
lzma 15 0,030 335 0,125 0,075 56,6
xz 15 0,030 308 0,136 0,079 59,6
lzop 31 0,062 950 0,091 0,095 71,7
lz4 31 0,062 2000 0,045 0,078 58,7
zstd 21 0,042 1600 0,037 0,055 41,8

Auch hier ist zstd wieder klar führend, gefolgt von lz4 (gzip, lzma und xz fallen aufgrund der geringen Kompressionsgeschwindigkeit bei der Erzeugung weg). Lzo ist auch nicht wirklich schlecht, aber es ist doch ein deutlicher Unterschied gegenüber lz4 erkennbar. Und bzip2 ist für heutige Anwendungsfälle einfach nicht mehr geeignet.

Fazit

Lz4 ist das Mittel der Wahl. Der Algorithmus bietet, unter Berücksichtigung des Speichermediums, der Kompressionszeit/-rate, sowie der Dekompressiongeschwindigkeit, im Moment das beste Verhältnis. Zstd wird wohl der bessere Nachfolger, ist aber zur Zeit noch nicht im Kernel enthalten.

Es bleibt allerdings fraglich, ob bei Speichermedien >500MB/s die Kompression überhaupt noch Sinn ergibt. Die Werte sind jetzt schon kaum mess- geschweige denn wahrnehmbar.

Falls jemandem der Titel dieses Post bekannt vorkommen sollte: Das ist Absicht. Ein gewisser [ENC]BladeXP hatte Ende 2016 bereits einen Artikel zu dieser Thematik geschrieben, und ich wollte das Experiment mal auf einem aktuellen System wiederholen. Allerdings mit einer kleinen Ergänzung: Ich habe mir auch die Zeiten für die Dekompression angesehen.

Verwendet wurde hierfür ein System mit einer NVMe SSD, einem Intel Core i7-8550U, sowie 16GB RAM.

Erzeugen der Ramdisk + Kompression

Nach jedem Kernelupdate muss unter Archlinux mit Hilfe des Tools mkinitcpio eine neue Ramdisk erzeugt werden, welche der Kernel zum Booten benötigt.

In der Tabelle befindet sich dafür jeweils die Angabe des Kompressionsalgorithmus, die Größe der Fallback- und der Standard-Ramdisk, sowie die dafür benötigte Zeit. Der Prozentwert setzt lediglich die erzeugte Dateigröße in Relation zu einer unkomprimierten Ramdisk.

Algorithmus Fallback (MB) Standard (MB) Zeit (s) Prozent (%)
cat (none) 127 66 12,9 100,0
gzip 39 22 22,0 31,6
bzip2 37 21 26,6 30,1
lzma 27 15 122,9 21,8
xz 27 15 122,6 21,8
lzop 55 31 13,4 44,6
lz4 58 31 13,4 46,1
zstd 38 21 13,4 30,6

cat (none)
Erzeugung der Ramdisk ohne Kompression. Geht zwar schnell, erzeugt aber auch die größten Dateien. Einziger Nachteil ist der relativ hohe Platzverbrauch.

gzip, bzip2
Die beiden etwas älteren Kompressionsformate erzeugen zwar bereits relativ kleine Dateien, brauchen dafür aber auch grob die doppelte Zeit. Nicht zu empfehlen, zumal die Dekompression relativ langsam ist.

lzma, xz
Sowohl lzma als auch xz erzeugen sehr kleine Dateien, brauchen dafür aber auch gut die zehnfache Zeit. Für gewisse Szenarien mag das Sinn ergeben, hier allerdings nicht.

lzop, lz4, zstd
Die drei Verfahren erzeugen mit kaum wahrnehmbaren Overhead (gerade mal 0,5s im Vergleich zu cat) relativ kleine Dateien, wobei zstd auf eine ähnliche Kompressionsrate wie gzip bzw. bzip2 kommt. Leider ist zstd noch nicht fester Bestandteil des Kernels, und ein Booten einer mit zstd komprimierten Ramdisk daher nicht so einfach möglich. Auch wenn lz4 minimal größere Dateien als lzop erzeugt rate ich zu lz4, da die Dekompressionsgeschwindigkeit (wie man gleich sehen wird) bei lz4 wesentlich höher ist.

Lesen der Ramdisk + Dekompression

Die Dekompressionszeit zu messen war leider nicht ganz so einfach. Letztlich habe ich mich dafür entschieden Werte zu nehmen, die ich aus diversen Quellen zusammengetragen, und einer Plausabilitätsprüfung unterzogen habe. Außerdem ist die Dekompression alleine nicht entscheidend für den Bootvorgang, sondern muss auch in Relation zur Lesegeschwindigkeit des Speichermediums gesehen werden.

In der folgenden Tabelle habe ich meine NVMe SSD als Referenz genommen, welche lesend ca. 1,5GB/s schafft.

Algorithmus Größe (MB) Lesen (s) Dekompression (MB/s) Zeit (s) Gesamt (s) Prozent (%)
cat (none) 66 0,044 – – 0,044 100,0
gzip 22 0,015 684 0,032 0,047 106,4
bzip2 21 0,014 171 0,123 0,137 310,9
lzma 15 0,010 335 0,045 0,055 124,5
xz 15 0,010 308 0,049 0,059 133,4
lzop 31 0,021 950 0,033 0,053 121,1
lz4 31 0,021 2000 0,016 0,036 82,2
zstd 21 0,014 1600 0,013 0,027 61,6

Wie man sehen kann ist der Lesevorgang plus die Zeit, welche die Dekompression benötigt, nur bei Einsatz von lz4 oder zstd unter der Zeit, die eine unkomprimierte Ramdisk benötigt. Bei sehr schnellen Speichermedien ist es also fraglich, ob man überhaupt eine Kompression anwenden sollte. Der einzige Vorteil sind die reduzierte Anzahl der Schreib-/Lesezyklen auf das Speichermedium, im Bootvorgang selbst macht es aber keinen Unterschied mehr. Zumal wir hier von Zeit im Bereich weniger Millisekunden reden.

Spannender wird es, wenn man ein etwas langsameres Speichermedium verwendet. Als Beispiel eine SATA-3 SSD welche "nur" 500MB/s lesend schafft:

Algorithmus Größe (MB) Lesen (s) Dekompression (MB/s) Zeit (s) Gesamt (s) Prozent (%)
cat (none) 66 0,132 – – 0,132 100,0
gzip 22 0,044 684 0,089 0,076 57,7
bzip2 21 0,042 171 0,339 0,165 124,9
lzma 15 0,030 335 0,125 0,075 56,6
xz 15 0,030 308 0,136 0,079 59,6
lzop 31 0,062 950 0,091 0,095 71,7
lz4 31 0,062 2000 0,045 0,078 58,7
zstd 21 0,042 1600 0,037 0,055 41,8

Auch hier ist zstd wieder klar führend, gefolgt von lz4 (gzip, lzma und xz fallen aufgrund der geringen Kompressionsgeschwindigkeit bei der Erzeugung weg). Lzo ist auch nicht wirklich schlecht, aber es ist doch ein deutlicher Unterschied gegenüber lz4 erkennbar. Und bzip2 ist für heutige Anwendungsfälle einfach nicht mehr geeignet.

Fazit

Lz4 ist das Mittel der Wahl. Der Algorithmus bietet, unter Berücksichtigung des Speichermediums, der Kompressionszeit/-rate, sowie der Dekompressiongeschwindigkeit, im Moment das beste Verhältnis. Zstd wird wohl der bessere Nachfolger, ist aber zur Zeit noch nicht im Kernel enthalten.

Es bleibt allerdings fraglich, ob bei Speichermedien >500MB/s die Kompression überhaupt noch Sinn ergibt. Die Werte sind jetzt schon kaum mess- geschweige denn wahrnehmbar.

5. Februar 2020

Du fängst gerade mit Linux auf deinem Laptop an und möchtest wissen, welche Anwendungen du benutzen solltest? Oder du möchtest bessere Alternativen zu den Apps finden, die du aktuell verwendest? Dieser Wegweiser zeigt dir Anwendungen für fast jeden Einsatzbereich unter Linux.

3. Februar 2020

Auf der FOSDEM wurden einige interessante Themen in den Fokus gerückt. Mit dabei die Probleme mit den Graubärten und die Schwierigkeiten mit GPL Software zu überleben.

Leider fehlte mir bisher die Zeit, die Talks anzusehen, weshalb ich mich primär auf die Heise-Berichterstattung beziehe. Diese fand ich ganz nebenbei dieses Jahr ungewohnt kritisch, aber vielleicht kam mir das nur so vor.

Daniel Riek thematisierte die aktuellen Mentalitätsprobleme bei der rasanten Fortentwicklung. Er hat dafür das Schlagwort "Greybeards", also zu deutsch "Graubärte" gewählt. Das Thema treibt mich auch schon ein wenig länger um, aber ich möchte mir gar nicht ausmalen, wie sich das anfühlt, wenn man versucht unter dem Dach von Red Hat das Linux-Ökosystem voran zu treiben. Das Kernproblem ist sicherlich, dass es Linux nun auch schon ein bisschen länger gibt und viele eingefleischte "Graubärte" das System seit 20 Jahren nutzen. Sie haben sich eingerichtet und wollten keine Veränderungen. Das gibt es überall, für Linux ist das aber neu, weil nun die erste Generation der Anwender alt wird. Persönlich habe ich zudem manchmal den Eindruck, dass diese Gruppe bei Linux öffentlich sehr präsent ist und wenig neue Anwender nachkommen.

Ein weiteres Thema war die GPL und die kommerziellen Möglichkeiten von Firmen. Hier wirken die Schocks nach, weil Redis und MongoDB den Code zwar nicht unzugänglich gemacht, wohl aber die Freiheit der Weiterverwendung eingeschränkt haben. Die GPL wirkte sich für beide Projekte scheinbar negativ auf die kommerziellen Möglichkeiten der Firmen aus (siehe auch: Reflexionen: Open Source hat kein funktionierendes Monetarisierungsmodell). Frank Karlitschek warf sich auf der FOSDEM dann für die GPL in die Bresche. Heise bemängelt aber zu recht, dass man die Geschäftsmodelle von Nextcloud schlecht mit den beiden obigen Beispielen vergleichen kann und man dadurch gewissermaßen aneinander vorbei redete.

Zusätzlich gab es natürlich auch noch neues von Lennart Poettering. Ich bewundere diesen Mann wirklich für seine Hartnäckigkeit, mit der er Veränderungen voran treibt. Ohne mich jetzt über den Stil oder die technische Dimension auszulassen finde ich es einfach bewundernswert, dass er nie hingeschmissen hat. Kaum eine Person in der Open Source-Szene war schließlich n den vergangenen Jahren so einem Hass ausgesetzt. Auf der FOSDEM ging es dann um systemd-home: Ein System um portable, verschlüsselte Home-Verzeichnisse zu ermöglichen. Ich bin gespannt!


Bilder:
Einleitungs- und Beitragsbild von qimono via pixabay

"

Auf der FOSDEM gab es auch einen Vortrag zu Thunderbird. Dabei wurde laut Heise auch die hochgerechnete Zahl von 10 Millionen Anwendern präsentiert. Klingt nach viel, ist es aber meiner Meinung nach nicht.

Erst einmal klingt 10 Millionen Anwender natürlich beeindruckend. Natürlich ist zudem, wie bei vielen anderen freien Projekten, auch nicht ganz klar, wie Mozilla (bzw. demnächst MZLA Technologies Corporation) diese Zahlen erhebt. Es wäre also möglich, dass die Zahlen in Wirklichkeit höher sind. Vermutlich ist aber wie bei vielen öffentlich präsentierten Schätzungen eher das Gegenteil der Fall.

Egal wie es sich damit verhält, es ist eigentlich kein sonderlich hoher Wert. Wir müssen uns dazu vergegenwärtigen, dass Thunderbird ja nicht nur für Linux eine Rolle spielt (und hier vielleicht der beliebteste E-Mail Client ist), sondern auch unter macOS und Windows einen festen Platz hat. Windows 10 läuft laut Microsoft auf 1 Milliarde Geräte. Apples macOS kommt je nach Berechnung und Quartal auf ca. 10% Marktanteil. E-Mail wird zwar seit langem Tot gesagt, allerdings hat immer noch quasi jeder eine E-Mail Adresse und die Zahl der verschickten und empfangenen Nachrichten bleibt sehr hoch. Wenn man diese Zahlen zugrunde legt ist 10 Millionen Anwender nicht viel.

Gerade hinsichtlich Datenschutz und Verschlüsselung ist das ein weiterer Sargnagel für die E-Mail Verschlüsselung (siehe leider auch: Die E-Mail wird niemals sicher sein!). Thunderbird ist der mit Abstand am besten geeignete Client für Verschlüsselung. S/MIME und OpenPGP sind bestmöglich umgesetzt - entweder durch feste Integration oder sehr gute Addons. Mit keinem anderen verbreiteten Client kann man dieses Maß an Komfort erreichen. Die verfügbaren browserbasierten Lösungen sind zudem ein Sicherheitsproblem.

Der Kreis der potenziellen Korrespondenten für sichere E-Mail beschränkt sich damit auf gut 10 Millionen. Zusätzlich noch die paar Nutzer, die AddIns in Outlook oder Apple Mail nutzen.

Traurige Zahlen!


Bilder:
Einleitungs- und Beitragsbild von ribkhan via pixaybay

"

1. Februar 2020

Synology Netzwerkspeicher sind dank Datenspiegelung auf verschiedenen Festplatten gut gegen Ausfälle geschützt. Trotzdem sollte man ein zusätzliches Backup anlegen um dieses räumlich getrennt vom NAS aufbewahren zu können. Dazu liefert Synology "Hyper Backup" mit.

Backups sind ein sträflich vernachlässigtes Thema. Die meisten IT-affinen Leute heute die für selbstverständlich (und machen sie trotzdem zu selten) aber viele machen nie Backups, weil sie entweder sich nicht mit dem Thema beschäftigen oder glauben sie merken es schon irgendwie, wenn ihre Geräte bald defekt sind. Gerne hört man solche Kommentare wie: "Mein Notebook ist noch fast neu, da muss ich keine Daten sichern". Das Thema Backups kommt immer erst auf, wenn der Datenverlust bereits eingetreten ist und nur noch eine schwierige Datenrettung hilft.

Umso wichtiger sind leicht bedienbare Backup-Werkzeuge und möglichst viel Automatisierung um die eigenen Nachlässigkeit zu überlisten.


Dieser Artikel ist Teil einer Serie:


Hyper Backup kann theoretisch sowohl lokale Sicherungen, als auch Sicherungen in der Cloud anlegen. Das umfangreiche Angebot an möglichen Diensten deckt alle großen Cloud-Dienstleister ab.

Eine Sicherung in der Cloud ist hinsichtlich der Gefahr eines Datenverlusts natürlich nicht zu übertreffen. Natürlich könnte rein theoretisch auch ein Cloudanbieter durch Fehler Daten verlieren, aber das Risiko ist sehr viel geringer, als bei einer Sicherung mit Privatpersonen zur Verfügung stehenden Mitteln. Allerdings würde zumindest bei mir ein Backup meiner NAS alle (wirklich alle!) privat vorgehaltenen Daten beinhalten. Dadurch würden alle sonstigen Schutzmaßnahmen konterkariert werden. Manche begegnen diesem Risiko durch eine Komplettverschlüsselung des Backups. Mein persönliches Vertrauen in Verschlüsselung reicht aber nicht soweit, dass ich meine Daten aus der Hand geben würde. Ich bekomme sie danach schließlich potenziell nie wieder aus dem Netz raus und wer garantiert schon für die ewige Sicherheit der aktuellen Verschlüsselungsstandards?

Es bleibt also aus meiner Sicht nur die Sicherung auf einer externen Festplatte. Genannt "Lokaler Ordner und USB".

Als Gemeinsamen Ordner wählt man die externe Festplatte. Diese muss als ext4 formatiert sein, was man aber sonst auch noch vorab über die Synology Oberfläche erledigen kann.

Anschließend wählt man die zu sichernden Ordner. Vielleicht speichert man ja auf dem NAS Dinge, die so unwichtig sind, dass sie kein Backupmedium verstopfen sollen. Bei mir wären das z. B. Test-VMs ohne Inhalt.

Danach kann man noch auswählen welche Anwendungen man sichern möchte. Insbesondere Calendar und CardDAV solte man berücksichtigen, wenn man - so wie ich - Kontakte und Kalender über die Synology NAS synchronisiert.

Das ganze lässt sich über einen Zeitplan konfigurieren oder auch manuell starten. Ein Zeitplan setzt voraus, dass immer ein Backupmedium angeschlossen ist.

Zu guter letzt kommt noch die Frage was passieren soll wenn das Medium voll oder die maximale Anzahl an Versionen erreicht wurde. Sollte man hier keine Präferenzen haben, kann man auch einfach die Standardeinstellungen abnicken.


Bilder:

Einleitungs- und Beitragsbild von Mudassar Iqbal via Pixabay 

"

31. Januar 2020

Auch wenn das System bald aus dem Support ist, habe ich noch einige 16.04 Systeme im Einsatz und möchte hier mal eine Muster-Einstellung für Konfiguration zeigen. Die Einstellungen befinden sich in /etc/network/interfaces. auto eth0 iface eth0 inet static address 192.168.0.10 netmask 255.255.255.0 gateway 192.168.0.1 dns-nameservers 192.168.0.1 8.8.8.8 Wenn man keine grafische Oberfläche hat, z.b. auf einem Server kommt man schon einmal in die Situation, das manuell anpassen zu müssen.

Für ein kleines Java-Projekt war ich auf der Suche nach einem schnellen Weg um Dateien darauf hin zu überprüfen, ob am Ende der Datei ein Zeilenumbruch zu finden ist. Fündig geworden bin ich beim Tool pcregrep. Nach der Installation unter Ubuntu mittels:

apt install pcregrep

kann das Ganze genutzt werden um Dateien ohne Zeilenumbruch am Ende zu finden. Dazu sollte in den gewünschten Ordner gewechselt und anschließend der Befehl:

pcregrep --include="java" -LMr '\n$' .

ausgeführt werden. In diesem Fall wird über die Option include sichergestellt das nur Dateien mit der Zeichenkette Java im Namen berücksichtigt werden.

30. Januar 2020

Unter Lock-in Effekten versteht man eine besonders enge Produktbindung durch hohe Wechselkosten. Im Bereich der Betriebssysteme wird das vor allem mit dem Goldenen Käfig der Apple-Produkte verbunden. Lock-in Effekte können allerdings auf jedem System entstehen. Sie lassen sich aber durch reflektiertes Handeln vermeiden.

Vergleich man macOS mit Linux (wie bspw. hier: Reflexionen: Von Linux zu macOS) kommt immer jemand und spricht den vermeintlich Goldenen Käfig an (dazu übrigens: macOS vs. Linux - Goldener Käfig gegen Freiheit?). Gemeint ist da der vermeintlich besonders hohe Lock-in Effekt bei Apple Produkten. Diese urban myth wird allerdings auch nicht wahrer, wenn man sie häufig wiederholt. Jedes Betriebssystem erzeugt Lock-in Effekte. Genau so kann man sie auf jedem Betriebssystem vermeiden.

Nehmen wir doch einfach Linux als Beispiel. Jenes System, das angeblich kein Goldener Käfig und frei von Lock-in Effekten ist. Wenn ich mein Kubuntu System mit den Standardprogrammen nutze laufe ich gleich in ein paar Gefängnisse rein. E-Mails mit POP3 in KMail abgeholt, Finanzen und Online-Banking mit KMyMoney erledigt, in Dolphin viel mit Tags gearbeitet, in DigiKam eine riesige SQL-Datenbank mit Bildern erzeugt etc. pp. Alle diese erzeugten Daten sind bei einem Wechsel zu Windows oder macOS verloren oder lassen sich nur mit viel Aufwand portieren. Hinzu kommen noch die Dateien aus Produkten wie LibreOffice, die sich wirklich gut auch wieder nur in LibreOffice darstellen lassen - was aber wenigstens plattformübergreifend zur Verfügung steht.

Bei einer entsprechend unvorsichtigen Arbeitsweise wird Linux bzw. die Programmlandschaft unter Linux genau so zum Gefängnis wie es macOS oder Windows sein können. Vermeiden kann man dies durch überlegtes Handeln.

Die erste Frage bevor man ein Programm intensiver nutzt muss daher lautet: Wie und wo speichert es meine Daten. Speichert das Programm die Daten in einem Format, das nur dieses Programm verarbeiten kann (egal, ob das Programm Open Source oder das Format transparent spezifiziert ist) ist das schon mal schlecht. Gibt es zusätzlich keine Exportfunktion in eine plattformübergreifend verfügbare Variante (abhängig vom Programmtyp), nutzt man das Programm prinzipiell nicht. Das ist zum Beispiel der Grund weshalb ich niemals ein Dokumenten Management System nutzen würde. Selbst bei zigtausenden Dateien kann man noch mit einer klugen Ordnerstruktur arbeiten.

Sollte ein Programm unterschiedliche Speichermethoden anbieten muss man abwägen. DigiKam kann beispielsweise Metainformationen in die Dateien schreiben oder lediglich in der Datenbank speichern. Viele Apple Programm wie Fotos oder Musik (ehedem iTunes) können ebenfalls die verarbeiteten Dateien automatisch verwalten oder lediglich einlesen. Hier muss man dann abwägen wie viel Komfortverluste die dateibasierte (Informations-)Verwaltung bedeutet. Sind diese nicht exorbitant: Dateien selbst verwalten.

Datenabgleich zwischen verschiedenen Geräte sollte immer über freie Protokolle erledigt werden. Wer seine E-Mails mit IMAP synchronisiert, seinen Kalender mit CalDAV und seine Kontakte mit dem Pendant CardDAV abgleicht und auf die eigene Cloud notfalls mittels WebDAV zugreifen kann, muss keine Wechselprobleme fürchten. In dem Fall kann man sogar problemlos proprietäre Programme unter manchen Betriebssystemen verwenden. Die Daten werden dadurch in keinen Käfig eingesperrt.

Diese Liste ließe sich jetzt beliebig fortführen. Natürlich kann man nicht alle Reibungsverluste beim Wechsel zwischen verschiedenen Betriebssystemen vermeiden. Es wird immer dieses oder jenes Programm geben, das nur auf dem einen System läuft und auf das man nicht verzichten mag. Das kann einem aber auch beim Versionsupgrade innerhalb einer Betriebssystem-Gruppe passieren.

Wenn man aber ein bisschen umsichtig vorgeht, gibt es heute keine nennenswerten Lock-in Effekte mehr. Diese Zeiten sind schon lange vorbei. Nicht zuletzt auch dank der viele unterschiedlichen Endgeräte, die wir heute mit uns herumtragen und die Softwareentwickler dazu animiert haben den Datenabgleich zu vereinfachen.


Bilder:
Einleitungs- und Beitragsbild von TeroVesalainen via pixabay

"

Für Backups nutze ich seit vielen Jahren rsync-time-backup. Allerdings hörte ich in letzter Zeit viel gutes über die freie Software Restic. Restic selbst wird über GitHub entwickelt und ist unter der BSD-Lizenz in der Zweiklausel-Version lizenziert. Unter Linux und macOS kann Restic einfach über entsprechende Paketmanager installiert werden:

brew install restic

Restic arbeiten mit sogenannten Repositories. In einem Repository befindet sich das entsprechende Backup mit all seinen Versionen. Um ein solchen Repository anzugelegen wirde der Befehl:

restic init --repo ./

genutzt. Bei Restic ist jedes Backup automatisch verschlüsselt, sodass bereits beim Anlegen eines Backups ein entsprechendes Passwort vergeben werden muss. Die Daten werden mit AES, bei 256 Bit, verschlüsselt.

restic.net

Danach kann theoretisch mit dem ersten Backup begonnen werden:

restic -r /Volumes/Volume/ResticRepository backup /Users/User

In diesem Fall würde der Ordner /Users/User/ in das Restic-Repository gesichert. Bevor das Backup startet, muss das entsprechende Passwort des Repositorys eingegeben werden. Anschließend wird der Nutzer über den Fortschritt des Prozesses informiert:

repository 567f35fa opened successfully, password is correct
created new cache in /Users/User/Library/Caches/restic
[0:09] 10 files 4.296 MiB, total 451 files 224.551 MiB, 0 errors
/Users/User/System/btrfstune
/Users/User/System/busybox
...

Nach dem Abschluss des Backups erscheint eine entsprechende Meldung im Terminal:

Files:          25 new,     0 changed,     0 unmodified
Dirs:            2 new,     0 changed,     0 unmodified
Added to the repo: 616.694 KiB

processed 25 files, 615.493 KiB in 0:00
snapshot 6c0d7af6 saved

Nun verfügt der Nutzer über ein Backup Repository mit einem bzw. mehreren Snapshots. Die angelegten Snapshots können über dem Befehl:

restic -r /Volumes/Volume/ResticRepository snapshots

angezeigt werden. Der Nutzer erhält eine entsprechende Ausgabe im Terminal:

repository fd5947c7 opened successfully, password is correct
ID        Time                 Host        Tags        Paths
------------------------------------------------------------------------------
6c0d7af6  2020-01-05 10:09:15  Earth.local             /Users/User/System
31d3160f  2020-01-05 10:11:30  Earth.local             /Users/User/System
38d6cbca  2020-01-05 10:15:09  Earth.local             /Users/User/System
ea96fa22  2020-01-05 10:15:20  Earth.local             /Users/User/System
------------------------------------------------------------------------------
4 snapshots

Das beste Backup nutzt nichts, wenn es nicht wiederhergestellt werden kann. Dazu wird die Option restore genutzt:

restic -r /Volumes/Volume/ResticRepository restore 38d6cbca --target /Users/User/System

Anschließend wird der gewünschte Snapshop wieder hergestellt:

repository fd5947c7 opened successfully, password is correct
restoring  to /Users/User/System

Soll anstatt eines bestimmten Snapshot der letzte Snapshot wiederhergestellt werden so wird anstatt einer Snapshot-ID einfach latest als Wert angegeben. Soll nur eine einzelne Datei wiederhergestellt werden, ist das komplette zurückspielen eines Backup eher suboptimal. Für einen solchen Fall können die Snapshots im Dateisystem gemountet werden.

restic -r /Volumes/Volume/ResticRepository mount /Volumes/Volume/ResticRepositoryMounted

Anschließend wird das Repository im Dateisystem unter dem angegebenen Mountpoint eingebunden:

repository fd5947c7 opened successfully, password is correct
Now serving the repository at /Volumes/Volume/ResticRepositoryMounted
When finished, quit with Ctrl-c or umount the mountpoint.

Im Gegensatz zu den Befehlen zur Wiederherstellung des Backups muss beim Mounten keine Snapshot-ID angegeben werden. In der gemounteten Struktur werden stattdessen alle Snapshots angezeigt. Die gewünschte Datei zur Wiederherstellung kann somit gesucht und wiederhergestellt werden.

Beim Backup sollen in vielen Fällen bestimmte Dateien nicht gesichert werden. Dies können z.B. temporäre Dateien oder Caches sein. Um diese Datei vom Backup auszuschließen, kann ein sogenanntes Exclude File genutzt werden:

restic -r /Volumes/Volume/ResticRepository backup /Users/User/System --exclude-file="/Users/User/excludes.txt"

Eine solche Datei könnte z.B. wie folgt aussehen:

+ /etc/
+ /home/
+ /root/
+ /srv/
+ /usr/local/
+ /var/

- /*
- /var/cache/*
- /var/lib/lxcfs/*
- /var/log/*
- /var/tmp/*

Neben diesen Basisfunktionalitäten, verfügt Restic über weitere Funktionen, so z.B. zum Löschen alter Snapshots nach bestimmten Regeln. Alles in allem wirkt Restic für mich wie eine durchdachte Backup-Lösung, deren Nutzung durchaus ins Auge gefasst werden kann.

28. Januar 2020

Das Thunderbird-Projekt hat heute bekannt gegeben, ab sofort unter dem Dach der neu gegründeten MZLA Technologies Corporation zu operieren. Es handelt sich dabei um eine neue Tochtergesellschaft der Mozilla Foundation.

Der beliebte E-Mail-Client Thunderbird wird bereits seit einigen Jahren nicht mehr von der Mozilla Corporation entwickelt, welche auch Entwicklerin von Firefox ist. Stattdessen ist Thunderbird ein eigenständiges Projekt, welches zwar den Namen und Technologie von Mozilla nutzt, aber unabhängig agiert. Die Mozilla Foundation tritt außerdem weiterhin als juristische wie auch finanzwirtschaftliche Heimat des Thunderbird-Projekts auf.

Wie die kommerzielle Mozilla Corporation eine Tochtergesellschaft der nicht profitorientierten Mozilla Foundation ist, so ist auch die neu gegründete MZLA Technologies Corporation eine Tochtergesellschaft der Mozilla Foundation und ab sofort neue Heimat von Thunderbird.

An der grundsätzlichen Ausrichtung des Thunderbird-Projekts ändert sich dadurch nichts. Thunderbird bleibt weiterhin Open Source und für den Nutzer kostenlos. Jedoch gibt die neue Heimat dem Thunderbird-Projekt die Möglichkeit, Einnahmen durch Partnerschaften und nicht nur durch Spenden zu generieren sowie bezahlte Produkte und Dienste anzubieten, was unter dem Dach der Mozilla Foundation aufgrund seines Not-for-Profit-Status nicht möglich wäre. Auch gibt das Thunderbird-Projekt an, unter der neuen Organisation leichter neue Mitarbeiter einstellen zu können.

Der Beitrag MZLA Technologies Corporation ist die neue Heimat von Thunderbird erschien zuerst auf soeren-hentzschel.at.

26. Januar 2020

Die Zahl der durch uns genutzten Zugänge nimmt kontinuierlich zu, gleichzeitig sollen Passwörter möglichst lang und komplex sein, sowie lediglich für einen einzigen Dienst zur Verwendung kommen. Wer kein begnadetes Gedächtnis hat ist hier schnell überfordert. Der Ausweg aus dem Dilemma: Ein Passwortmanager.

Passwörter sind prinzipiell ein ziemliches unsicheres Konzept. Mit einer Kombination aus Zugangskennung und Passwort kann man sich theoretisch von jedem Gerät auf der Welt irgendwo anmelden. Mit genügend Zeit und Versuchen dürfte damit jedes Passwort zu knacken sein. Leider haben wir gegenwärtig kein besseres Konzept. Manche sehen in biometrischen Daten den nächsten großen Entwicklungsschritt aber diese sind nicht zwingend sicherer als ein Passwort (siehe: (Un-)Sicherheit per Fingerabdruck). Vorerst ist man daher dazu übergegangen das Prinzip des Passworts zu ergänzen mit Einmal-Codes wie TOTP von einem so genannten zweiten Faktor, wie z. B. einem Gerät in eurem Besitz oder einem Hardwaretoken wie den YubiKey oder Nitrokey. Zusätzliche Sicherheit sollen Anmeldeversuche, technische Verzögerungen und im Extremfall sogar die Datenlöschung nach einer bestimmten Anzahl Fehlversuche bieten.

Wichtig ist dennoch ein möglichst langes, komplexes und zufällig gewähltes Passwort. Die meisten geknackten Accounts entstehen nämlich nicht durch dunkle Hackermagie, sondern durch Phishing und Social Engineering. Letzterem beugt man unter anderem vor, indem man eben nicht den Namen der Ehefrau oder der Katze als Passwort nimmt und natürlich auch nicht das beliebte 12345 oder in seiner extrem sicheren Variante 54321.

Viele empfehlen so genannte Passwortsätze um sich die komplexen Kennwörter zu merken. Dabei überlegt man sich einen Satz und nimmt als Kennwort beispielsweise jeden ersten Buchstaben eines Wortes und ersetzt dabei einige Buchstaben durch Sonderzeichen wie wie ein i durch !. Doch auch dieses System kommt bei dutzenden verschiedenen Passwörtern schnell an seine Grenzen.

Genau in diese Lücke stoßen Passwortmanager. Dabei handelt es sich um spezielle Programme, deren Aufgabe darin besteht, die verschiedenen Loginkombinationen (ggf. mit zusätzlichen Informationen) sicher zu speichern. Die Datenbank ist dabei wiederum verschlüsselt und durch ein eigenes Kennwort gesichert. Theoretisch ist dies das einzige Passwort, das man sich merken muss. Dazu bieten sich der oben bereits angesprochene Passwortsatz an. Viele dieser Programme bieten inzwischen zusätzliche Funktionen wie entsprechende Browser-Addons um die Anmeldedaten automatisch in die entsprechenden Felder einzutragen oder mobile Pendants um die Kennwörter immer dabei zu haben.

Verschiedene Angebote

Zu welcher Lösung man greifen sollte hängt ganz massiv zum Nutzungszenario und den geforderten Funktionen ab. Die folgende Liste sollte einige Optionen aufzeigen. Der Markt ist enorm vielfältig, weshalb die Liste weder den Anspruch erhebt vollständig zu sein, noch alle Systeme abzudecken. Einige Grundsätze sind jedoch immer zu beherzigen.

Das Programm sollte aktiv gepflegt werden und die Daten verschlüsselt, lokal auf dem Gerät speichern. Die zunehmend beliebter werdenden Cloud-Lösungen sind nicht zu empfehlen. Selbst wenn man dem Dienst vertraut und er die Daten gegenwärtig sicher verschlüsselt, heißt das nicht, dass die Verschlüsselung nicht jetzt schon gebrochen sein könnte (manche Geheimdienste horten solches Wissen) oder zukünftig gebrochen werden könnte (was wahrscheinlich ist). Kennwort-Datenbanken sind relativ kleine Datensätze. Im Grunde genommen könnte es daher für Geheimdienste, staatliche Sicherheitsbehörden oder Kriminelle interessant sein, solche Daten zu horten bis sie knackbar sind. Die meisten Menschen ändern ihre Passwörter schließlich nicht all zu häufig.

Ebenso sollte man überlegen, ob man die Passwörter wirklich unbedingt mobil auf dem Smartphone braucht. Erstens besteht bei einem Smartphone eine deutlich höhere Gefahr das Gerät zu verlieren und zweitens sind viele Smartphone-Betriebssysteme schlecht gepflegt und weisen gefährliche Sicherheitslücken auf.

Integrierte Lösungen

Alle Betriebssysteme haben interne Passwortspeicher. Diese sind funktional limitiert aber in der Regel sehr sicher. Sofern man nur ein System und/oder ein Gerät nutzt sollte man in Erwägung ziehen einfach auf die interne Lösung zurückzugreifen. Im Fall von Apples Schlüsselbund wurde das hier bereits thematisiert: Passwortverwaltung mit Apples Schlüsselbund. Das Prinzip ist aber ebenso auf Linux mit GNOME Keyring und KDE's KWallet übertragbar.

KeePass und Varianten

Eine gute Alternative für alle, denen die limitierten Funktionen der integrierten Passwortverwaltungen nicht genügen ist das quelloffene KeePass. Das eigentliche Programm steht nur für Windows zur Verfügung, aber rund um KeePass hat sich ein ganzes App-Ökosystem entwickelt, das Datenbanken im kdbx-Format lesen und speichern kann. Dadurch steht KeePass auf quasi jeder Plattform zur Verfügung. Die Herausforderung besteht darin unter den vielen Alternativen das beste Programm für die jeweilige Plattform zu finden. Zudem unterstützen nicht alle Programme alle Funktionen gleichermaßen.

Die vielfältigen Lösungen für die Plattformen erfordern zudem bei der Synchronisation zwischen den Geräten und einer etwaigen Integration in den präferieren Browser mehr Konfigurationsaufwand als proprietäre All-in-One Lösungen.

Gegenwärtig empfehlen sich zur Nutzung neben dem Original für Windows noch MacPass für macOS und KeePassXC für Linux. Mobil kann man Keepass DX für Android verwenden, sowie Keepassium für iOS.

Enpass

Enpass hat sich in den letzten Jahren zu einer proprietären Alternative zum KeePass-Ökosystem gemausert (ein älterer Bericht hier: Enpass - Ein Passwortmanager für alle Systeme). Die Enpass Entwickler bieten ihren Passwortmanager für alle verbreiteten Systeme (Windows, macOS, Linux, Android und iOS) aber können im Gegensatz zu den vielfältigen KeePass-Varianten einen konsistenten Funktionsumfang garantieren.

Die letzten Updates und Entwicklungsentscheidungen könnten dies aber gefährden. Zuerst rollte man ein einheitliches Design für alle Plattformen aus, das zumindest auf macOS und Linux sehr bescheiden aussieht und dann entschloss man sich kürzlich für Neukunden auf ein Abo-Modell zu wechseln.

SafeInCloud

SafeInCloud wird seit 2012 entwickelt und der Name des Programmes ist mehrfach irreführend. Erstens können Daten grundsätzlich nicht sicher in der Cloud abgelegt sein (siehe oben) und zweitens ist SafeInCloud ein normaler Passwortspeicher, der die Daten lokal ablegt. Man sollte sich davon also nicht irritieren lassen. Ausführlich ist das Programm hier beschrieben: SafeInCloud - Vielfältiger Passwortmanager

SafeInCloud setzt nicht auf ein Abo-Modell sondern finanziert sich durch Lizenzverkäufe. Der Funktionsumfang ist für die meisten Anwendungsgebiete ausreichend und es kommen regelmäßig kleine Funktionsupdates. Allerdings steht SafeInCloud nur für macOS, Windows, Android und iOS zur Verfügung und ist somit nichts für Linux-Nutzer.

Pass

Anwender mit Unix/Linux Fokus können sich Pass anschauen. Dieses und das Qt-Frontend QtPass ist in diesem etwas älteren, aber immer noch weitestgehend gültigen Artikel besprochen: Passwörter mit QtPass / pass verwalten

Für Pass spricht die unaufgeregte aber kontinuierliche Entwicklung. Durch Rückgriff auf OpenPGP nutzt man zudem einen etablierten Verschlüsselungsstandard und läuft nicht Gefahr ausversehen Sicherheitslücken in einer Eigenentwicklung einzubauen.

Problematisch ist ähnlich wie bei KeePass die Client-Situation. Es gibt zwar für alle möglichen Plattformen Clients aber deren Entwicklung geschieht unabhängig und der Datenabgleich zwischen unterschiedlichen Betriebssystemen/Clients ist nicht immer ganz trivial. Das gleiche gilt für die Integration in die unterschiedlichen Browser um Daten komfortabler einzugeben.

Bitwarden

Relativ jung ist Bitwarden. Man kann es als Nextcloud-Pendant für Passwörter bezeichnen. Die Open Source Software basiert zwar auf der - eigentlich von mir kritisch gesehenen - Cloud-Synchronisation. Ähnlich wie bei Nextcloud kann man diese zentrale Instanz aber auch selbst z. B. auf einem Homeserver oder einem NAS hosten. Dadurch gibt man die Daten nicht aus der Hand.

Der Funktionsumfang kann mit den freien und proprietären Alternativen hier problemlos mithalten. Positiv sind halt die direkt zur Verfügung stehenden Clients für Desktop, mobile Systeme und alle gängien Browser. Dadurch muss man nicht mit Dritt-Apps, etwaigen Inkompatibilitäten und Entwicklungsbrüchen umgehen.

Bitwarden finanziert sich über ein Business-Modell mit Abonnements. Dabei kommt dann allerdings eine zentrale Cloud-Instanz zum Einsatz, weshalb davon abzuraten ist.

Fazit

Im Grunde genommen ist es gleichgültig welches der Angebote man nimmt und hängt massiv von den eigenen Anforderungen ab. Wichtig ist lediglich, dass man auf einen der Passwortmanager zurückgreift. Ohne einen solchen Manager nimmt man halt doch wieder die gleichen Kennwörter für unterschiedliche Dienste oder nutzt unterkomplexe Passwörter. Passwortgeschützte Listen in Word- oder Excel-Dokumenten fehlen zudem essentielle Funktionen wie eine automatische Bereinigung der Zwischenablage oder eine automatische Sperrung nach Standby.


Bilder:

Einleitungs- und Beitragsbild von MasterTux via pixabay

"

23. Januar 2020

Das Argument Open Source bzw. Linux fehle es an einem funktionsfähigen Monetarisierungsmodell bringe ich in verschiedenen Artikeln immer mal wieder ohne es jemals wirklich ausgeführt zu haben. Lediglich mit den Folgen habe ich mich mal befasst (siehe: Folgen der Kostenlos-Mentalität) Dies soll daher hier nachgeholt werden.

Ich möchte in der Reflexionen-Serie einige Erfahrungen und Grundannahmen transparent machen, die in vielen meiner Artikel implizit oder explizit mitschwingen.

Linux-Enthusiasten tun in Diskussionen manchmal so, als ob Linux im Privat-/Endverbraucher-Sektor und insbesondere auf dem Desktop bereits wirtschaftlich funktionieren würde. Sie suggerieren damit, dass Open Source eine überlegene Idee wäre, die nur von der gesamten IT-Wirtschaft übernommen werden müsste. Proprietäre Software wäre ein Auslaufmodell, dem nur veraltete Firmen mit überholten Geschäftsmodellen anhängen. Initiativen wie "Public Money, Public Code" wollen gleich den Staat verpflichten hier einen Beitrag zu leisten (siehe auch: netzpolitik.org Podcast zu freier Software) und für die Allgemeinheit zu entwickeln.

Sobald man dem widerspricht kommen immer einige Kommentatoren und zählen die großen Leuchttürme der Open Source Welt auf: Red Hat (nun zu IBM gehörig), SUSE, teilweise Canonical und viele weitere Nischenanbieter. Alle diese Firmen verdienen mit Open Source Produkten sehr viel Geld. Die Übernahme von Red Hat hat sich IBM rund 30 Milliarden Euro kosten lassen. Das sind natürlich ordentliche Zahlen. Zusätzlich steuern institutionelle Entwickler einen Großteil des Codes bei wichtigen Projekten wie dem Kernel bei.

Enterprise Sektor

Doch was haben alle diese Anbieter gemeinsam? Sie verdienen ihr Geld im Enterprise-Segment mit dem Verkauf von Supportverträgen für Produkte. Viele dieser Firmen haben ihre Umsatzsteigerungen der letzten Jahre zudem dem Cloud-Trend zu verdanken. Man könnte es die "Enterprisisierung des Business-Modells" nennen, weil das Produktportfolio sich nochmal deutlich vom Endverbraucher entfernt hat. Natürlich haben Red Hat oder SUSE auch noch einen herkömmlichen Desktop im Angebot, aber dieser dürfte nur einen Bruchteil des Umsatzes ausmachen und das Engagement in diesem Bereich hat doch sehr sichtbar nachgelassen. Bei Canonical weiß man, dass lediglich die Cloud-Sparte wirklich rentabel ist. Von Red Hat bis Canonical ist der Enterprise-Desktop ein ziemliches einerlei aus GNOME und einigen wenigen rudimentären Programmen. 

Das klappt deshalb so gut, weil Supportverträge für Produkte im Business-Umfeld auch bei der proprietären Konkurrenz üblich sind und oft die Lizenz- und Anschaffungskosten über die Laufzeit hinweg übersteigen. Die Open Source Anbieter konnten also ein bestehendes Geschäftsmodell relativ einfach für sich fruchtbar machen. Gleichzeitig ermöglicht der Open Source Charakter zwar legale Clone (z. B. CentOS) aber die im Enterprise-Segment oft notwendige Zertifizierung lässt die Kunden in ausreichender Anzahl zum Original greifen. Die Risiken des Open Source Modell werden dadurch erfolgreich neutralisiert.

Open Source Software ist im Enterprise-Sektor daher eine feste Größe und kann es spielend mit der proprietären Konkurrenz aufnehmen. Hier gibt es zweifelsohne ein funktionierendes Monetarisierungsmodell.

Außerhalb des Enterprise Sektors

Außerhalb des "Big Business" gibt es bei der proprietären Konkurrenz - von Microsoft, über Apple bis Google - aber einen veritablen Privat- und Mittelstandssektor. Hier wird Software "von der Stange" entwickelt und lizenziert. Support gibt es gar nicht oder lediglich als Zusatzleistung. Dazu gehört neben dem basalen Desktop auch das gesamte Desktop-Ökosystem. Eben jener heute gerne "Apps" titulierter Bereich verleiht diesen Plattformen ihre Attraktivität. Dieser Bereich ist für Privatanwender viel wichtiger als die großen Leuchtturmprojekte.

Eben diesen Sektor gibt es aber im Open Source Bereich kaum. In diesem Bereich entwickeln viele kleine Firmen und Einzelentwickler Softwareprodukte mit hoher Qualität die als Abonnements oder versionsgebundene Lizenz verkauft werden. Für Open Source Betriebssysteme wie Linux ist dieser Bereich kaum existent - weder als kommerziell vertriebene freie Software, noch proprietäre Alternativen. Die existenten Produkte wie CrossOver oder Softmaker Office lassen sich an wenigen Fingern abzählen und kommen ebenfalls alle aus dem semi-professionellen Bereich.

Doch hat Linux nicht auch hier ohne große Firmen eine erhebliche Qualität erreicht? Nun wichtige Projekte im Desktopumfeld wie KDE, GNOME, Virtualbox oder LibreOffice und seine Vorgänger wurden oder werden von den oben genannten Firmen durch ihre Erträge in anderen Geschäftsfeldern querfinanziert und damit subventioniert. Der überragende Einfluss von Red Hat auf die GNOME Entwicklung wird schließlich immer wieder kritisert. KDE hat zudem mit bluesystems einen philanthropischen Mittelgeber. Ohne diese Mittel und die dadurch bezahlten Vollzeitentwickler wäre die gegenwärtige Qualität sicherlich nicht zu erreichen. Dies sieht man genau an jenem Bereich an dem die Firmen kaum Interesse haben: Der mobile Sektor. Die Entwicklung wird hier fast nur von der Community und ehrenamtlichen Entwicklern getragen und kommt seit Jahren nicht voran.

Woran liegt das? Gerne wird auf den geringen Marktanteil von Linux verwiesen, der eine Entwicklung unrentabel macht. Es gibt zwar nur wenige offizielle Zahlen, aber der Marktanteil von Apples macOS liegt nur geringfügig über dem vom Linux und kommt nicht an Windows heran. Möglicherweise sind Apple-Kunden kaufkräftiger, als Linux-Anwender - dazu kenne ich keine Zahlen. Allerdings glaube ich nicht an Linux als "arme-Leute-System".

Das Problem ist vermutlich eher vielschichtig. Ein erheblicher Teil der Linux-Nutzer glaubt an den Mehrwert und die Idee von freier Software. Dahinter steht bei vielen oft eine gewisse Kapitalismuskritik und die Idee von der Vergemeinschaftung von Code. Ironischerweise oftmals vorgetragen von Vertretern einer Branche, die gemessen an den Durchschnittsgehältern zu den Gewinnern der aktuellen wirtschaftlichen Entwicklung gehört. Open Source-Enthusiasten kaufen proprietäre Software nur wenn es sich absolut nicht vermeiden lässt und greifen eher zu einer freien, aber schlechteren Lösung, als zur guten, aber proprietären Variante. Der eh schon kleine Linux-Markt schrumpft damit noch weiter. Der Spiele-Markt illustriert dies anschaulich, da Steam hier durchaus Umsätze unter Linux verbuchen kann - eben weil es keine nennenswerten Alternativen gibt.

Nun kann man natürlich auch freie Kleinsoftware auf die gleiche Weise wie die großen Enterprise-Produkte mit Service-Verträgen vermarkten. Das haben auch einige Anbieter versucht, aber es scheitert. Der Verpflichtung der Code-Offenlegung ermöglicht immer Nachbauten und anders als bei einem ganzen Betriebssystem, wie im Fall von RHEL, ist das bei einem einzelnen Programm mit deutlich überschaubarerem Aufwand verbunden. Es wird daher immer kostenlose Forks und Community-Varianten geben. Klappen tut dies daher nur in relativ kontrollierten Märkten. Einige Entwickler von Open Source Apps für Android bieten diese z. B. gegen einen Obolus bei Google Play an. Weil viele Android-Nutzer alternative Stores nicht kennen, funktioniert das in begrenztem Maße. Open Source Enthusiasten mit F-Droid umgehen aber auch diese Gebühr.

Alternative Monetarisierungsmöglichkeiten

Weil der kommerzielle Vertrieb von Software faktisch scheitert haben sich Entwickler einige andere Lösungen überlegt. Dazu gehören Spenden, ebenso wie Fundraising-Kampagnen. Spenden funktionieren ausweislich aller Zahlen nicht wirklich. Das liegt auch daran, dass viele institutionelle Nutzer wie der Öffentliche Dienst zwar Geld für Software ausgeben dürfen, aber keinesfalls Spenden können. Um dem Dilemma zu entgehen haben viele populäre Open Source Projekte in der Vergangenheit sehr erfolgreich Kampagnen gestartet. Die Kampagnen-Wirtschaft hat aber ihre Risiken, weil zur Gewährleistung des steten Geldflusses immer neue Kampagnen benötigt werden. Für Purism hat ein Blogger das mal sehr gut nachgezeichnet (siehe: Links der Woche KW 50 - Purism, Onlineshopping und Linux). Wirklich nachhaltig ist dieses Modell also auch nicht.

Natürlich gibt es neben Lizenzierung, Spenden und Fundraising auch noch andere Monetarisierungsmöglichkeiten. Die Digitalwirtschaft hat mit der Veräußerung von (Nutzer-)Daten und Werbung zwei sehr bekannt gemacht. Beides kommt bei der Datenschutz-affinen Zielgruppe nur naturgemäß kaum in Frage.

Folgen

Durch diese Probleme und Limitationen basiert ein Großteil dessen was man Linux-Desktop nennt auf ehrenamtlicher Arbeit, teilweise finanziert durch einige wenige Firmen und altruistische Einzelpersonen. Davon profitieren aber primär die Basisprojekte wie z. B. die großen Desktops durch ihre Querfinanzierung aus dem Enterprise-Segment. Diese Zuwendungen sind aber tendenziell rückläufig, wie z. B. die alleinige Fokussierung von RHEL auf GNOME illustriert.

Nischenprojekte, Zukunftsideen und kleine Softwareideen werden meist von wenigen Freiwilligen entwickelt. Die Qualität hinkt - pauschal gesagt - der proprietären Konkurrenz deutlich hinterher und der Abstand wächst, weil die Entwickler weniger Zeit zur Verfügung haben und oft auch primär für sich selbst entwicklen. Letzteres hat dann auch zur Folge, dass Projekte verwaisen wenn der Entwickler die Lust oder das Interesse verliert. Der niedrige Bus-Faktor vieler Open Source Projekte macht sich hier dann auch negativ bemerkbar. Natürlich verlieren auch Entwickler proprietärer Produkte mal das Interesse, aber hier gibt es wenigstens noch den monetären Anreiz. Software wird zudem immer komplexer und schon vor einigen Jahren fragte sich der scheidende Dolphin-Entwickler wie lange ehrenamtliche Arbeit hier noch mitziehen kann.

Für den Anwender fehlt ganz nebenbei durch diese Entwicklung auch die Wahlfreiheit zwischen Open Source Projekten und proprietärer Software im konkreten Fall zu entscheiden. Diese Wahl musste der Anwender faktisch schon bei der Auswahl des Betriebssystems treffen. Aus Sicht des Anwenders bedeutet Linux dadurch sogar weniger (Wahl-)Freiheit als proprietäre Systeme.

Aus diesem Grund muss ich konstantieren, dass Open Source vor allem im Privat-/Endverbraucherbereich ein dauerhaft funktionsfähiges Monetarisierungsmodell fehlt - allen Beteuerungen zum Trotz. Das muss nicht unbedingt zum Untergang führen und man kann vorerst problemlos so weiter machen. Es hat aber Auswirkungen auf die Qualität und die Stabilität des Ökosystems. Man kann dies als gegeben hinnehmen und hier auch die Vorteile von Linux sehen, aber sollte keine wirtschaftliche Erfolgsstory herbeireden.

Die Frage ist halt, was passiert wenn die letzten Firmen mit Hoffnung auf eine erfolgreiche Monetarisierung ihrer Entwicklungsleistung sich aus dem Endverbraucherbereich (Distributionen, Desktops, Programme, Apps) zurückziehen. Kann die Gemeinschaft nur die ehrenamtliche Arbeit wirklich dieses Niveau halten? Hofft man auf den Staat als Mittelgeber angetrieben durch den Wunsch nach digitaler Souveränität?


Änderungen

Die Argumentation etwas konsistenter ausformuliert und den Artikel gegliedert.


Bilder:

Einleitungs- und Beitragsbild von stevepb via pixabay

"