Back in 2007, Canonical Landscape -  a tool for managing Ubuntu systems - was introduced. So beside already popular tools such as Uyuni and Foreman there is yet another software with comparable features. How useful is it?

Expectations

I've never used Landscape. The reason for this is that I usually work with Red Hat-based distributions, mainly RHEL and SLES. I'm running some Debian-based systems in my Homelab: my Raspberry Pis are running on Raspbian and Ubuntu.

On the hand, I've been using Spacewalk (which lead to Uyuni) and Foreman and Katello which are the basis for the commercial Red Hat Satellite and ATIX Orcharhino for 10 years. Beside daily administration (installing patches, configuration systems) these tools can also be used for automatically installing new hosts and also integrate into a range of third-party software.

Canonical advertises the following features:

• Automating usual administration tasks
• Managing up to 40.000 systems
• Creating customized software repositories
• Customization via REST-API

As both Uyuni and Foreman have been supporting Ubuntu for quite a while I was curious about the benefit of Canoncial's solution. With coming system management into picture, I find the following functions mandatory:

• Grouping hosts
• Managing software packages and patches
  • Displaying errata information (patch details, scoring via CVSS)
  • Local mirror for packages to save bandwidth and limit internet access
  • Freezing tested software versions
• Deploying new systems
  • Creating VMs and container images
• Integration into state of the art configuration management (Ansible, Salt, Chef, Puppet)
• Automating re-occuring tasks
• Management via REST-API

Installation

It looks like Canonical focussed selling their SaaS offer - especially in combination with  Ubuntu Advantage with extra charge for additional services:

• Kernel Livepatch
• Ceph Support
• 24/7 Support
• Unlimited KVM and LXD guests

Without this subscription, the on-premises variant only suports up to 10 systems and 50 containers. If you plan to manage more systems, you will need to purchase a subscription.

Canonical only names rough system requirements:

• Xenial Xerus (16.04) or Bionic Beaver (18.04) as base system (Focal Fossa, 20.04 can't be used)
• Access to the internet
• Sufficient storage if software repositories are supposed to be cloned

My experiments have shown that the system should have at least 2 CPU cores and 4 GB memory.

Also, it is a good idea to create dedicated file systems for the following paths:

The actual installation is really easy - you only need to configure a PPA (Personal Package Archive) and install a package:

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

During the process, necessary libraries, a PostgreSQL database and the Landscape server are installed. It is also possible to seperate database and application server on multiple hosts - check out the appropriate manual on the Canonical website. Landscape is developed in Python and Erlang.

After the installation, the web interface is available at https://. During the first start, an administrator user needs to be created:

Afterwards, the overview is displayed:

Backup & restore

The most users might run Landscape within a virtual machine - making it easy to create agentless backups by leveraging snapshot technology. Alternatively or in addition the following paths are important for backups:

Basic concepts

Clients

Managed hosts are registered using landscape-client, the package is available to all currently maintained Ubuntu releases. For communication, the client uses two http(s) sockets - one for management and an additional one for checking availability. Optionally, the client is also able to run scripts on the host. By default, only the nobody user is used for execution. Running scripts as root is considered as security risk and needs to be enabled manually during client registration. A better option would be using a service user for scripts and grant higher permissions using sudo.

Multiple tags can be assigned to a host optionally. These tags consist of letters, numbers or hyphens and describe a system. As Landscape offers no system groups, tags are also used for grouping related hosts. Names can be choosed freely - some examples:

• web
• database
• proxy
• dev
• prod

Groups and roles

Systems are isolated from each other by leveraring Access Groups - a concept that is also known as mandator, organization or organization unit from other tools. Every host can only be part of one group at the same time.

By assigning roles to Access Groups, administrators can utilize permissions. After some pre-configured roles (GlobalAdmin, Auditor, SupportAnalyst) also customized roles can be created.

Profiles

Landscap differentiates between three kinds of profiles.

Package Profile

A Package Profile defined a list of packages and dependencies that should be installed or removed.

A profile's particular packages might be defined manually or copied from an existing system. Landscape can simply copy the package list of a registered system or the administrator imports a CSV or the output of a dpkg command:

1$ dpkg --get-selections > package_profile

Using this, a common baseline for systems can be created easily. Rules are defined in form of Debian packages that are installed on the system:

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

When applying a profile that would remove installed packages, an Approval is created within the web interface. If removed packages are re-installed, an alarm is generated and the profile can be applied for a second time.

Removal Profile

The Removal Profile defines the amount of days after that a host is removed from Landscape once it became not reachable. The makes sense in order to avoid wasting dung 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

The Upgrade Profile defines a time frame in which updates are installed automatically. Beside time, also tags and Access Groups are defined. Package selection can be limited to security upgrades - it is also possible to remove unneeded packages (apt-get autoremove). When patching multiple systems, a time frame and offset in which affected systems are updated randomly can be specified. Depending on the host type, differing rules can be defined.

API access

Landscape offers an API that can automate numerous functions of the graphical interface. To leverage it, a Python client is shipped - it can be installed using apt:

1# apt-get install landscape-api

For using the client, API tokens needs to be generated first. This can be done from the profile settings view next to API Access:

Afterwards you might want to create a script that export the connection details via shell variables:

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

Make sure to load the variables to get access:

1$ source landscape_vars.sh

Alternatively, you can specify the required information with parameters for every call.

Alarms and scripts

Predefined alarms inform the administrator about issues, e.g:

• Unpatched systems
• Systems requiring a reboot
• Systems registered twice
• Expiring or exhausted subscriptions
• Outstanding approvals

The particular alarms can be accessed within the web interfaces and optionally subscribed via mail.

Unfortunately there is no way to define customized alarms.

Landscape script repository functionality is more fleixble. Using it, commands that are executed on a regular basis can be stored as script.

By clicking, these scripts can be executed on appropriate systems.

Monitoring

Landscape can be used for simple monitoring - the following metrics are gathered every 5 minutes:

• System usage
• Memory and swap usage
• Temperature
• Root file system capacity
• Traffic per network card

In addition, customized metrics can be defined. For this, a script that only returns a number is defined. This script is linked to a Access Group and tags to select systems for execution. Unfortunately, long-term analysis and capacity planning is not possible as these values are only stored for a maximum of 4 weeks.

Registering systems

For registering a client install the Landscape client from the Ubuntu repositories first:

1# apt-get install landscape-client

Before the client can be registered, the Landscape server SSL certificate needs to be verified - but there is no interactive prompt.

The certificate needs to be copied to the client - e.g. using scp:

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

Optionally, a registration key can be specified for the Landscape organization. If enabled, clients can only be registered when using the key.

Registration is done using the landscape-config command - and it needs several parameters:

 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.

In case of errors the assistant is not useful:

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.

Having a look in the log file /var/log/landscape/broker.log usually helps:

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

Ensure to use FQDNs rather than short names during registration.

LXC container are detected during registration, they don't need a host license.

Managing systems

After clicking Computers in the menu, another menu that offers filtering per tag is shown on the left. This enables doing management on multiple systems.

Landscape supports:

• Listing hardware information (components, network information, hypervisor)
• Shutdown and reboot
• Listing recent activity
• Basic system monitoring
• Running commands and scripts
• Listing and stopping processes
• Installing, updating and removing software packages
• Managing local users
• Simple reporting (patch state)

Most tasks can be seen under Activities afterwards - including optional output and user information. So, basic auditing is possible.

Management is noticeable slow - even on powerful hardware. It looks like communication isn't handled in real time but in periodic intervals.

Software repositories

Landscape offers no graphical way for configuring and managing software repositories. What a bummer - that would have been a important feature.

For synchronizing software repositories a key GPG signatures needs to be created first. In accordance with the documentation it is common not to specify a passphrase and use the name "Mirror Key":

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

The generated key is imported using the API:

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

Aferwards the distribution required to synchronize is created - e.g. 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...

With repositories coming into picture, Landscape differentiates between the following artifacts:

• Series - Release, e.g. bionic
• Components - Software componens, e.g. main, restricted or universe
• Pockets - Software source, e.g. release, updates or security

In addition, also the architecture and the mirror server URL needs to be specified:

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

Now the particular repositories can be synchronized. Unfortunately it is not possible to run multiple synchronization jobs parallely:

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

Synchronization progress can also only be gathered via API. When starting synchronization, a job ID is printed (id) - using this the job status can be retrieved. The most interesting variable is 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'}]

In case of issues you will also find an error message that can also be read from the web interface.

After synchronization, a repository profile can be created. This profile will be linked with software repositories and connected hosts via tags in the next step. So it might be useful to create tags per distribution.

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 are always cloned with all available data - this takes not only time but also a lot of storage (roughly 150 GB per release/architecture). Using Pull Pockets party of repositories can be cloned - e.g. to limit the software set for clients.

Hosts linked with the repository profile will be configured for apt automatically - previously defined software sources are disabled.

Conclusion

Canonical Landscape is a simple tool that only offers basic administration functionality. It is possible to patch systems and control them using scripts, but additional important functions such a freezing tested software versions or deploying new systems are missing.

Here and there, the graphical interface is confusing and looks outdated. Also, not all product features can be accessed using the UI. As an example, cloning software repositories requires leveraging the API that also needs to be configured first. That's unnecessarily complex in comparison with other tools. Freezing software versions - e.g. to synchronize development and production systems - is not possible. Listing USNs (Ubuntu Security Notices), Ubuntu's errata information, did not work for me - maybe this requires Ubuntu Advantage. Another drawback is that managing systems is noticeably slow - even on powerful hardware. Usual configuration management tools such as Ansible and Salt are way faster here.

It is a bummer that the tool officially only supports Ubuntu. When cloning external APT repositories it is also possible to enter a Debian mirror but the required Landscape client will be missing. Even though it should be possible to also install the appropriate Ubuntu package on a Debian system it is not recommended to mix packages of different distributions.

It is sad that Landscape sends Telemetrie data to Canonical by default if you miss to Opt-Out.

I'm missing some important features for system management in bigger environments. Landscape doesn't offer configuration management or integration into existing tools - that's a manual task for the administrator. Cloning APT repositories is way too complex. When registering clients a parameter for accepting self-signed certificates could speed-up automatic processes.

The integrated monitoring can be used for basic infrastructure monitoring - using scripts, it can also be extended with customized metrics. Sadly, the storage period is too low for capacity planning.

The tool might be a decent option for small homogeneous environments. If you mainly manage clients rather than servers and don't need configuration management integration or quality assurance when selecting software packages**,** Landscape will do the job. For larger system landscapes or requirements, Uyuni or Foreman are a better option. Orcharhino offers an even better support for Ubuntu as it includes USNs.