Mit Canonical Landscape gibt es seit 2007 ein Werkzeug zur Verwaltung von Ubuntu-Systemen. Damit gibt es neben bereits bekannten Tools wie Uyuni und Foreman ein weiteres Tool, das ähnliche Features verspricht. Doch, wie nützlich ist das Tool?

Erwartungen

Ich habe noch nie vorher mit Landscape gearbeitet. Das liegt vor allem daran, dass ich mehr mit Red Hat-basierten Distributionen arbeite, vor allem RHEL und SLES. Debian-basierte Systeme kommen vor allem im Homelab zum Einsatz: auf meinen Raspberry Pis läuft Raspbian bzw. Ubuntu.

Allerdings arbeite ich seit 10 Jahren mit Spacewalk (welches in Uyuni mündete) sowie Foreman und Katello, welche die Basis für den kommerziellen Red Hat Satellite und ATIX Orcharhino bilden. Neben der täglichen Administration (Patches installieren, Systeme konfigurieren) bieten diese Tools auch die Option automatisiert neue Hosts zu installieren und integrieren sich in eine Reihe von Drittanbieter-Tools.

Canonical selbst verspricht unter anderem die folgenden Features:

• Automatisierung von üblichen Administrationsaufgaben
• Verwaltung von bis zu 40.000 Systemen
• Erstellen eigener Software-Repositories
• Anpassungen via REST-API

Nachdem sowohl Uyuni als auch Foreman schon seit einiger Zeit ebenfalls Ubuntu unterstützen, interessierte mich vor allem der Mehrwert von Canonicals Lösung gegenüber den bereits vorhandenen Werkzeugen. Für die Systemverwaltung erachte ich die folgenden Funktionen als wichtig:

• Gruppierung von Hosts
• Verwaltung von Software-Paketen und -Patches
  • Einsehen von Errata-Informationen (Patch-Details, Gewichtung via CVSS)
  • Lokales Vorhalten von Paketen um Bandbreite einzusparen und Internet-Zugriff zu limitieren
  • Einfrieren getesteter Software-Stände
• Bereitstellen neuer Systeme
  • Erstellen von VMs und Container-Images
• Integration in gängiges Configuration Management (Ansible, Salt, Chef, Puppet)
• Automatisierung wiederkehrender Aufgaben
• Fernsteuerung via REST-API

Installation

Canonicals Fokus liegt augenscheinlich auf dem Vertrieb des eigenen SaaS-Angebots - vor allem in Verbindung mit dem aufpreispflichtigen Ubuntu Advantage für weitere Zusatzservices:

• Kernel Livepatch
• Ceph Support
• 24/7 Support
• Unbegrenzte KVM-/LXD-Gäste

Die on-premises Variante unterstützt ohne diese Subscription lediglich 10 Systeme und 50 Container. Sollen mehr Systeme verwaltet werden, muss eine Subscription erworben werden.

Canonical nennt nur sehr vage Systemanforderungen:

• Xenial Xerus (16.04) oder Bionic Beaver (18.04) als Basis-System (Focal Fossa, 20.04 kann nicht verwendet werden)
• Zugriff auf das Internet
• Ausreichend Speicherplatz, wenn Software-Repositories geklont werden sollen

Meine Experimente haben gezeigt, dass das System über mindestens 2 CPU-Cores und 4 GB Arbeitsspeicher verfügen sollte.

Es empfiehlt sich dedizierte Dateisysteme für die folgenden Pfade zu erstellen:

Die eigentliche Installation ist sehr einfach - es muss lediglich ein PPA (Personal Package Archive) konfiguriert sowie ein Paket installiert werden:

1# add-apt-repository --update ppa:landscape/19.10
2# apt install landscape-server-quickstart

Im Laufe des Prozesses werden neben benötigten Bibliotheken auch eine PostgreSQL-Datenbank sowie der Landscape-Server installiert. Es ist auch möglich Datenbank und Applikationsserver auf mehreren Systemen zu betreiben - hierfür existiert eine entsprechende Anleitung auf der Canonical-Webseite. Landscape ist in Python und Erlang programmiert.

Nach der Installation kann die Web-Oberfläche über https:// erreicht werden. Beim ersten Aufruf ist ein Administrator-Benutzer zu erstellen:

Anschließend wird die Hauptseite angezeigt:

Backup & Restore

Die meisten Benutzer werden Landscape vermutlich als virtuelle Maschine betreiben - eine solche lässt sich agentenlos via Snapshot-Mechanismus sichern. Alternativ sind die folgenden Pfade für konventionelle oder ergänzende Backups von Interesse:

Grundlegende Konzepte

Clients

Zu verwaltende Computer werden mithilfe des landscape-client registriert, das Paket steht unter allen aktuell gewarteten Ubuntu-Releases zur Verfügung. Zur Kommunikation verwendet der Client zwei http(s)-Sockets - eines für die Fernsteuerung und eines zur Überprüfung der Erreichbarkeit. Der Client kann optional auch Skripte auf dem Zielsystem ausführen. Hierbei wird standardmäßig lediglich der nobody-Benutzer zum Ausführen angeboten. Das Ausführen von Skripten als root ist ein Sicherheitsrisiko und muss manuell bei der Client-Registrierung aktiviert werden. Eine bessere Option ist es für Skripte einen Servicebenutzer zu erstellen und diesen via sudo für höhere Rechte zu konfigurieren.

Einem Computer können optional mehrere Tags zugewiesen werden. Diese bestehen aus Buchstaben, Zahlen oder Bindestrichen und beschreiben die Funktion des Systems näher. Systemgruppen gibt es in Landscape nicht, daher dienen die Tags zur Gruppierung von ähnlichen Systemen. Die Namen können frei gewählt werden - einige Beispiele:

• web
• database
• proxy
• dev
• prod

Gruppen und Rollen

Systeme werden mithilfe von Access Groups voneinander isoliert - ein Konzept, das bei anderen Tools oft als Mandant oder Organisation bzw. Organisationseinheit bezeichnet wird. Jeder Computer kann nur gleichzeitig Mitglied einer solchen Gruppe sein.

Jeder Administrator hat Berechtigungen in Form von zugewiesenen Rollen in einer Access Group. Neben einigen wenigen vorkonfigurierten Rollen (GlobalAdmin, Auditor, SupportAnalyst) können auch eigene definiert werden.

Profile

Landscape unterscheidet zwischen drei Profilarten.

Package Profile

Das Package Profile definiert eine Auswahl an Paketen und Abhängigkeiten die installiert oder entfernt werden sollen.

Die einzelnen Pakete eines solchen Profils können entweder manuell eingetragen werden, oder aber von einem bestehenden System übernommen werden. Hier kann Landscape entweder die Paketliste eines registrierten Systems auslesen oder der Administrator importiert ein CSV oder die Ausgabe eines dpkg-Kommandos:

1$ dpkg --get-selections > package_profile

Somit lässt sich schnell eine gemeinsame Baseline für Systeme erstellen. Diese Regeln werden in Form von Debian-Paketen auf dem System installiert:

1$ dpkg -l|grep -i landscape-profile
2ii  landscape-profile-standalone-basic         1                                               all          Landscape meta-package for profile basic
3ii  landscape-profile-standalone-remove-legacy 2                                               all          Landscape meta-package for profile remove-legacy

Das Übernehmen eines Profils, welches bereits installierte Pakete entfernt, erfordert ein Approval in der Web-Oberfläche. Werden diese Pakete nachträglich wieder installiert, wird ein Alarm generiert und das Profil kann erneut übernommen werden.

Removal Profile

Das Removal Profile definiert die Anzahl an Tagen nachdem ein Host aus Landscape entfernt wird, wenn er nicht mehr erreichbar ist. Das macht vor allem aus lizenztechnischer Sicht Sinn, um der Verschwendung von Subscriptions entgegen zu wirken. Die Einstellungen lassen sich auf Tag- und Access Group-Ebene definieren. Es können somit auch mehrere Regeln je nach Art des Hosts definiert werden.

Upgrade Profile

Das Upgrade Profile definiert eine Zeitspanne, in welcher Aktualisierungen automatisch installiert werden. Neben einer Uhrzeit können wieder Tags und Access Groups definiert werden. Die Paketauswahl kann auf Security-Upgrades beschränkt werden - auch ist es möglich, nicht mehr benötigte Pakete entfernen zu lassen (apt-get autoremove). Beim Patchen mehrerer Systeme kann ein Zeitrahmen angegeben werden, in welchem die betroffenen Systeme in zufälliger Reihenfolge und Zeitabstand aktualisiert werden. Auch hier lassen sich je nach Hostart wieder unterschiedliche Regeln definieren.

API-Zugriff

Landscape bietet eine API, mit der zahlreiche Funktionen der grafischen Oberfläche automatisiert werden können. Hierfür existiert ein Python-Client, der einfach über apt installiert werden kann:

1# apt-get install landscape-api

Zur Verwendung des Clients müssen erst noch API-Tokens generiert werden. Dieser Menüpunkt findet sich in den Profil-Einstellungen unter API Access:

Anschließend ist ein Skript zu erstellen, welches die neu generierten Verbindungsdetails mittels Shell-Variablen exportiert:

1#!/bin/sh
2export LANDSCAPE_API_KEY="..."
3export LANDSCAPE_API_SECRET="..."
4export LANDSCAPE_API_URI="https://landscape-server/api/"

Diese Variablen sind noch zu laden, damit der Zugriff funktioniert:

1$ source landscape_vars.sh

Alternativ können die benötigten Informationen auch bei jedem Aufruf über Parameter übergeben werden.

Alarme und Skripte

Vordefinierte Alarme informieren den Administrator über zahlreiche Missstände, beispielsweise:

• Ungepatchte Systeme
• Systeme mit ausstehendem Neustart
• Doppelt registrierte Systeme
• Auslaufende oder erschöpfte Subscriptions
• Ausstehende Approvals

Die einzelnen Alarme werden in der Web-Oberfläche angezeigt, können jedoch auch per Mail abonniert werden.

Leider gibt es keine Option, eigene Alarme zu definieren.

Etwas flexibler ist die Skriptablage Landscapes. Hier können Kommandos, die regelmäßig ausgeführt werden gespeichert werden.

Per Klick können diese Skripte dann auf den Systemen ausgeführt werden.

Monitoring

Landscape kann für rudimentäres Monitoring verwendet werden - so werden alle 5 Minuten die folgenden Metriken abgefragt:

• Systemlast
• Arbeitsspeicher- und Swap-Auslastung
• Temperatur
• Auslastung des Root-Dateisystems
• Traffic pro Netzwerkkarte

Darüber hinaus lassen sich auch eigene Metriken definieren. Hierzu wird ein Skript definiert, welches lediglich eine Zahl zurückgeben darf. Dieses Skript wird dann mit einer Access Group sowie einem oder mehreren Tags verknüpft und so auf Systemen ausgeführt. Langzeit-Überwachungen oder Kapazitätsplanungen sind jedoch nicht möglich, da die Werte nur maximal 4 Wochen gespeichert werden.

Registrieren von Systemen

Zur Registrierung eines Systems muss der Landscape-Client aus den Ubuntu-Repositories installiert werden:

1# apt-get install landscape-client

Bevor der Client registriert werden kann muss das SSL-Zertifikat des Landscape-Servers beglaubigt werden - eine interaktive Abfrage gibt es nicht.

Hierzu muss das Zertifikat auf den Client kopiert werden - beispielsweise via scp:

1$ scp /etc/ssl/certs/landscape_server.pem root@client:/etc/landscape/

Optional kann ein Registrierungsschlüssel in der Landscape-Organisation definiert werden. Falls konfiguriert, können Clients nur unter Angabe des Schlüssels registriert werden.

Die Registrierung erfolgt über das landscape-config-Kommando - unter Angabe zahlreicher Parameter:

 1# landscape-config --computer-title "landscape-client" \
 2  --account-name standalone \
 3  --url https://landscape-server/message-system \
 4  --ping-url http://landscape-server/ping \
 5  --ssl-public-key /etc/landscape/landscape_server.pem
 6
 7This script will interactively set up the Landscape client. It will
 8ask you a few questions about this computer and your Landscape
 9account, and will submit that information to the Landscape server.
10After this computer is registered it will need to be approved by an
11account administrator on the pending computers page.
12
13Please see https://landscape.canonical.com for more information.
14
15A registration key may be associated with your Landscape
16account to prevent unauthorized registration attempts.  This
17is not your personal login password.  It is optional, and unless
18explicitly set on the server, it may be skipped here.
19
20If you don't remember the registration key you can find it
21at https://landscape.canonical.com/account/standalone
22
23Account registration key:
24
25The Landscape client communicates with the server over HTTP and
26HTTPS.  If your network requires you to use a proxy to access HTTP
27and/or HTTPS web sites, please provide the address of these
28proxies now.  If you don't use a proxy, leave these fields empty.
29
30HTTP proxy URL:
31HTTPS proxy URL:
32
33Landscape has a feature which enables administrators to run
34arbitrary scripts on machines under their control. By default this
35feature is disabled in the client, disallowing any arbitrary script
36execution. If enabled, the set of users that scripts may run as is
37also configurable.
38
39Enable script execution? [Y/n]: Y
40
41By default, scripts are restricted to the 'landscape' and
42'nobody' users. Please enter a comma-delimited list of users
43that scripts will be restricted to. To allow scripts to be run
44by any user, enter "ALL".
45
46Script users:
47
48You may provide an access group for this computer e.g. webservers.
49
50Access group:
51
52You may provide tags for this computer e.g. server,precise.
53
54Tags:
55[ ok ] Restarting landscape-client (via systemctl): landscape-client.service.
56Please wait...
57
58Request a new registration for this computer now? [Y/n]:
59System successfully registered.

Im Fehlerfall ist der Assistent allerdings weniger nützlich:

We were unable to contact the server. Your internet connection may be down. The landscape client will continue to try and contact the server periodically.

Ein Blick in die Log-Datei /var/log/landscape/broker.log hilft oftmals:

1pycurl.error: (51, "SSL: certificate subject name (landscape-server.pinkepank.de) does not match target host name 'landscape-server'")

Bei der Registrierung muss drauf geachtet werden, FQDNs anstatt von Kurznamen zu verwenden.

LXC-Container werden bei der Registrierung übrigens automatisch als solche erkannt und verbrauchen daher keine vollwertige Hostlizenz.

Verwalten von Systemen

Nach einem Klick auf Computers in der Menüleiste erscheint links ein weiteres Menü, welches das Filtern nach Tags erlaubt. So können administrative Aufgaben direkt auf mehreren Systemen ausgeführt werden.

Landscape unterstützt:

• Anzeigen von Hardware-Informationen (verbaute Komponenten, Netzwerk-Informationen, Hypervisor)
• Herunterfahren und Neustarten
• Einsehen aktueller und vergangener Aktivitäten
• Rudimentäres Überwachen des Systems
• Ausführen von Kommandos und Skripten
• Einsehen und Beenden von Prozessen
• Installieren, Aktualisieren und Entfernen von Software-Paketen
• Pflegen von lokalen Benutzern
• Einfaches Reporting (Patch-Status)

Sämtliche Aufgaben können später unter Activities eingesehen werden - inklusive eventueller Ausgaben und Benutzerinformationen. Eine grundlegende Auditierung ist also möglich.

Auffällig ist, dass die Fernsteuerung sehr träge agiert - auch auf potenter Hardware. Hier scheint der Kommunikationsweg nicht in Echtzeit sondern periodischen Abständen zu erfolgen.

Software-Repositories

Landscape bietet keine grafische Option zur Pflege und Konfiguration von Software-Repositories. Das ist schade, da das eine außerordentlich wichtige Funktion wäre.

Zur Synchronisation von Software-Repositories muss eigens ein Key zur Signatur via GPG erstellt werden. Laut Dokumentation empfiehlt es sich hier keine Passphrase anzugeben und den Namen "Mirror Key" zu vergeben:

1$ gpg --gen-key
2...
3GnuPG needs to construct a user ID to identify your key.
4
5Real name: Mirror Key
6Email address:
7...

Der generierte Schlüssel wird nun via API importiert:

1$ landscape-api import-gpg-key mirror-key mirror-key.asc
2{u'fingerprint': u'...',
3 u'has_secret': True,
4 u'id': 1,
5 u'key_id': u'...',
6 u'name': u'mirror-key'}
7...

Anschließend wird die zu synchronisierende Distribution erstellt - beispielsweise Ubuntu:

1landscape-api create-distribution ubuntu
2{u'access_group': u'global',
3 u'creation_time': u'2020-09-22T07:12:05Z',
4 u'name': u'ubuntu',
5 u'series': []}
6...

Landscape unterscheidet bezüglich der Repositories zwischen den folgenden Artefakten:

• Series - Release, z. B. bionic
• Components - Software-Komponente, z. B. main, restricted oder universe
• Pockets - Software-Quelle, z. B. release, updates oder security

Darüber hinaus müssen noch die gewünschte Architektur sowie die URL des Spiegelservers angegeben werden:

1$ landscape-api create-series --pockets release,updates,security \
2  --components main,restricted,universe,multiverse \
3  --architectures amd64 \
4  --gpg-key mirror-key \
5  --mirror-uri http://archive.ubuntu.com/ubuntu/ \
6  --mirror-series bionic bionic ubuntu

Nun können die einzelnen Repositories synchronisiert werden. Eine Parallelisierung ist leider nicht möglich, da immer nur eine Synchronisation zeitgleich ausgeführt werden kann:

1$ landscape-api sync-mirror-pocket release bionic ubuntu
2{u'activity_status': u'undelivered',
3...
4                u'id': 28,
5...
6$ landscape-api sync-mirror-pocket updates bionic ubuntu
7$ landscape-api sync-mirror-pocket security bionic ubuntu

Der Synchronisationsfortschritt lässt sich ebenfalls nur via API herausfinden. Beim Starten der Synchronisation wird eine Job-ID ausgegeben (id) - mithilfe dieser kann der Status des Jobs ausgegeben werden. Interessant ist hier die Variable progress:

 1$ landscape-api get-activities --query id:28
 2[{u'activity_status': u'delivered',
 3u'children': [],
 4u'completion_time': None,
 5...
 6u'id': 28,
 7...
 8u'progress': 7,
 9...
10u'summary': u"Sync pocket 'release' of series 'bionic' in distribution 'ubuntu'",
11u'type': u'SyncPocketRequest'}]

Im Fehlerfall ist hier eine Fehlermeldung zu finden, die auch über die Web-Oberfläche eingesehen werden kann.

Nach der Synchronisation kann ein Repository-Profil erstellt werden. Dieses wird im Anschluss mit den synchronisierten Software-Repositories und angeschlossenen Computern via Tags verknüpft. Es macht also Sinn pro Distribution entsprechende Tags zu erstellen.

1$ landscape-api create-repository-profile --description "This profile is for Bionic Beaver On-Premise clients" bionic-profile
2$ landscape-api associate-repository-profile --tags bionic bionic-profile
3$ landscape-api add-pockets-to-repository-profile bionic-profile release,updates,security bionic ubuntu

Software-Repositories werden vollständig geklont, was nicht nur Zeit, sondern auch viel Speicherplatz in Anspruch nimmt (ca. 150 GB pro Release/Architektur).
In Form von sogenannten Pull Pockets lassen sich Teile der Repositories klonen - beispielsweise, um den Software-Umfang für Clients zu beschränken.

Mit dem Repository-Profil verknüpfte Computer erhalten automatisch eine angepasste apt-Konfiguration - vorher definierte Software-Quellen werden deaktiviert.

Fazit

Canonical Landscape ist ein recht simples Werkzeug, welches lediglich rudimentäre Administrationsaufgaben abbildet. So können Systeme zwar grundlegend gepatcht und mit Skripten ferngesteuert werden, jedoch fehlen weitere wichtige Funktionen, wie das Einfrieren getesteter Patchstände oder das Bereitstellen neuer Systeme.

Die grafische Oberfläche ist stellenweise unübersichtlich und wirkt angestaubt. Ein Manko ist, dass nicht alle Funktionen des Tools über die UI genutzt werden können. So erfordert beispielsweise das Klonen von Software-Repositories den Umweg über die API, die auch erst noch konfiguriert werden muss. Das ist unnötig komplex im Vergleich zu anderen Tools. Es ist nicht möglich, getestete Versionsstände einzufrieren - beispielsweise um das Produktionssystem auf dem gleichen Patchstand analog zur Entwicklungsumgebung zu halten. Das Einsehen von USN (Ubuntu Security Notices), Ubuntus Errata-Informationen, funktionierte für mich nicht - möglicherweise ist hierfür Ubuntu Advantage nötig. Auffällig ist auch, dass das Verwalten von Systemen auch auf potenter Hardware sehr träge ist - hier sind übliche Configuration Mangement-Tools wie Ansible oder Salt um längen schneller.

Schade ist auch, dass das Tool offiziell nur Ubuntu unterstützt. Beim Klonen externer APT-Repositories lässt sich zwar auch ein Debian-Spiegelserver eintragen, jedoch fehlt dann der benötigte Landscape-Client. Zwar ließe sich das entsprechende Ubuntu-Paket vermutlich auch auf einem Debian-System installieren, jedoch ist vom Vermischen unterschiedlicher Distributionspakete abzuraten.

Ebenfalls schade ist, dass Landscape standardmäßig Telemetrie-Daten Richtung Canonical sendet, sofern man das Opt-Out übersieht.

Ich vermisse einige wichtige Funktionen für Systemverwaltung im größeren Umfeld. Landscape bietet kein Configuration Management oder eine Integration in ein solches - hier muss der Administrator manuell tätig werden. Das Klonen von APT-Repositories ist unnötig komplex. Beim Registrieren von Systemen könnte ein Schalter für das Akzeptieren eines selbstsignierten Zertifikats automatisierte Registrierungen beschleunigen.

Das integrierte Monitoring ist für eine rudimentäre Übersicht über die Infrastruktur geeignet - es kann auch leicht über Skripte um eigene Metriken erweitert werden. Für Kapazitätsplanung fehlt jedoch ein längerer Speicherzeitraum.

Für kleine homogene Umgebungen kann das Tool jedoch eine denkbar gute Option sein. Wer hauptsächlich Clients statt Server verwaltet und keine Configuration Management-Integration oder Qualitätssicherung bei der Auswahl von Software-Paketen benötigt findet mit Landscape ein einfach zu benutzendes Tool. Für größere Umgebungen und/oder Anforderungen empfehlen sich jedoch eher Uyuni oder Foreman. Orcharhino bietet darüber hinaus noch besseren Ubuntu-Support, da es beispielsweise USNs integriert.