Run Landscape Client Safely and Check Its Connection

landscape-client is the agent behind Canonical's Landscape, watching or managing an Ubuntu machine, so know its state before you touch it. This covers inspecting, starting and verifying the client while keeping remote management disabled when you only need monitoring. The examples use the locally installed landscape-client package, version 24.02-0ubuntu5.7.

Allow about fifteen minutes. You need a shell, an already registered Landscape client configuration, and access to the host's service status and logs. Configuration and service changes need sudo; read-only checks normally do not, although the client configuration may be readable only by root.

Checkpoint: this guide runs an existing client. It does not register a computer, create an account key, change a server URL or edit policy from the Landscape web portal.

1. Check the installed command before running it

Start with read-only checks. This confirms which executable is on your path, records the installed package version, and shows the options this machine supports:

$ command -v landscape-client
/usr/bin/landscape-client
$ dpkg-query -W -f='${Package} ${Version}\n' landscape-client
landscape-client 24.02-0ubuntu5.7
$ landscape-client --version
24.02-0ubuntu5.7
$ landscape-client --help

The 2019 manpage supplied with this guide documents the core options: --config, --data-path, --log-dir, --url, --ping-url, --ssl-public-key, --daemon, --pid-file and --monitor-only. The installed 24.02 build also reports interval options such as --package-monitor-interval and --apt-update-interval in its help output. Prefer the installed help whenever a local package is newer than its manpage.

2. Confirm the configuration and registration state

The default configuration path is /etc/landscape/client.conf. The client reads settings from that file, and command-line options override them. The packaged systemd unit only starts the client when landscape-config --is-registered succeeds.

Inspect the file without printing secrets into a shared terminal or paste buffer, it commonly holds the account name, server URL and registration material. Use elevated privileges only for this read if you need to:

$ sudo test -r /etc/landscape/client.conf && echo 'configuration is readable by root'
configuration is readable by root
$ sudo sed -n '1,80p' /etc/landscape/client.conf

Check that the URL points at the intended Landscape message-system endpoint, do not replace it with a guessed web portal URL. The example configuration shipped with this package uses a value such as https://landscape.example.com/message-system for a self-hosted server. Over HTTPS, --ssl-public-key can specify the key used to verify the server; treat any change to that trust setting as security-sensitive.

Checkpoint: you have an existing configuration, know which server it names, and have not exposed its account or registration values in a command history or ticket.

3. Choose monitoring-only mode when management is not required

Landscape can report system information and execute remote management commands. --monitor-only disables management features and is useful when running as a non-root user. It is a boundary choice, not a cosmetic logging option.

For a one-off foreground test, keep the option explicit and use the normal configuration:

$ landscape-client --config=/etc/landscape/client.conf --monitor-only --log-level=info

This stays in the foreground: stop it with Ctrl-C after watching the output. It does not change the configuration, but it does start the client's communication and monitoring work, so do not launch a second copy against the same data and log paths if the client is already running as a service.

For a persistent non-root arrangement, the manpage says to place monitor_only = True in the configuration and set the account in /etc/default/landscape-client. That defaults file is packaging and deployment material rather than a command-line option, check that it exists on your installed release before relying on it.

4. Inspect the managed service before changing it

Read the service state first, an ordinary diagnostic check:

$ systemctl status --no-pager landscape-client.service
$ systemctl is-enabled landscape-client.service
$ systemctl is-active landscape-client.service

The unit installed by this package runs /usr/bin/landscape-client, uses the default configuration path unless overridden, and has an activation condition checking registration. An inactive service can therefore mean an unregistered or incomplete configuration, not necessarily a crashed process.

Do not use systemctl enable, start or restart until you have confirmed the server URL, registration state and maintenance window. Starting the service begins network communication; restarting it can interrupt an exchange. Both need sudo and change service state.

5. Start the service only after the checks pass

If the machine is registered and the configuration is correct, start the packaged service rather than adding a second background process:

$ sudo systemctl start landscape-client.service
$ systemctl is-active --quiet landscape-client.service && echo 'landscape-client is active'
landscape-client is active

Enabling it to start at boot is a separate, persistent change:

$ sudo systemctl enable landscape-client.service
$ systemctl is-enabled landscape-client.service
enabled

Enabled by mistake? Undo it with sudo systemctl disable landscape-client.service. Only started it? sudo systemctl stop landscape-client.service stops the service without removing its configuration or data. Do not delete /var/lib/landscape/client/ to solve a registration problem, it may hold state the client needs, and deletion is not a safe reset.

6. Verify exchanges through the client logs

The manpage gives /var/log/landscape as the default log directory. Inspect recent entries after starting the service:

$ sudo journalctl -u landscape-client.service --since '10 minutes ago' --no-pager
$ sudo find /var/log/landscape -maxdepth 1 -type f -printf '%f\n' | sort
$ sudo tail -n 40 /var/log/landscape/broker.log

Exact log files depend on the package and which components are enabled. The broker log is the useful first check for client-server exchanges; the monitor and manager logs help separate reporting from local management activity. A recent process or service status alone does not prove the server accepted an exchange, look for a current timestamp and a successful exchange message in the relevant log.

When the client is quiet, check the configured URL, DNS, proxy settings, system time and outbound firewall rules. A non-zero exit or a connection error is evidence to investigate, not a reason to disable TLS verification or paste registration secrets into a diagnostic command.

7. Keep foreground and daemon modes distinct

The manpage supports --daemon and --pid-file for background operation. Use those only when another supervisor is not already managing the client. On this package systemd is the supervisor, so a command like the following is normally for a deliberate, separate deployment rather than routine service operation:

$ sudo landscape-client --config=/etc/landscape/client.conf --daemon --pid-file=/run/landscape-client-test.pid

Do not combine this with the active systemd service. Two clients can contend for state, produce misleading logs and send duplicate reports. If you started a test daemon, stop it using the process and PID management method for that deployment, then remove only its test PID file once the process has exited. Do not kill an unknown PID just because a stale-looking file exists.

Done means