Register and Verify a Landscape Client with landscape-config

landscape-config is short-lived but its effects are not: get the account, key or server wrong and you mismanage a machine quietly. This covers registering an installed Landscape client, confirming whether registration completed, and what to do when the server or network is unavailable. The examples use landscape-config from landscape-client version 24.02-0ubuntu5.7 on this machine.

Allow about fifteen minutes, plus time for an administrator to hand you the Landscape account name, registration key and server details. You need a shell, the landscape-client package, and permission to write its system configuration. Registration sends account and computer information to the Landscape server, so treat the key as a secret and do not paste it into shell history, tickets or chat.

This guide changes client configuration and can start the client at boot. Keep a copy of any existing configuration before reconfiguring a machine that is already managed.

1. Check the installed command

Start with read-only checks, none of these need elevated privileges:

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

The default configuration file is /etc/landscape/client.conf. Runtime data normally lives under /var/lib/landscape/client/, and logs under /var/log/landscape. These defaults matter when a command appears to have registered but is not running from the location you expected.

Checkpoint: confirm the command and package version are the ones you intend to operate on before you hand over a real registration key.

2. Back up an existing configuration

If this host has been configured before, take a root-owned backup before re-registering it. This is an elevated, state-changing command:

$ sudo install -m 600 /etc/landscape/client.conf /etc/landscape/client.conf.before-config

If the file does not exist, that command fails without changing anything, which is normal for a first-time setup. Do not copy the registration key into a world-readable file, and keep it out of a shared shell history.

To recover from an unwanted reconfiguration: stop the client first if it is active, then restore the backup and start it using your distribution's normal service management. Check the available unit name before running a service command:

$ systemctl list-unit-files 'landscape*'
$ sudo cp --preserve=mode,ownership /etc/landscape/client.conf.before-config /etc/landscape/client.conf

The restore replaces the current configuration, check the source and destination paths carefully before pressing Enter.

3. Register interactively first

For a first setup, interactive mode is easier to review. Run it with elevated privileges so it can write the system configuration and client state:

$ sudo landscape-config

Answer the prompts with the values your Landscape administrator gives you. The account name identifies the account, the registration key authorises this client, and the computer title is the name shown in Landscape. If your organisation runs its own server, give it that server's message-system URL rather than silently accepting the Canonical-hosted default.

The command can register a new machine or reconfigure an already registered one. A successful run means registration succeeded and leaves the client configured and running. A network error can leave registration incomplete; according to the installed manual, the client keeps trying in the background.

Checkpoint: do not assume that returning to a shell means the machine is managed, verify registration in the next step.

4. Verify registration without changing it

Use --is-registered to ask the configured client for its registration information:

$ sudo landscape-config --is-registered
$ printf 'exit status: %s\n' "$?"

Status 0 means the client is registered.
Status 5 means it is not registered.
Any other status, such as an unreadable configuration file, needs investigation rather than another registration attempt.

The output is host-specific, check the account, computer title and server information against the intended machine without publishing the key. On a newly installed host, a failure such as config file /etc/landscape/client.conf can't be read means that configuration has not been created or cannot be read by the current invocation. It is not proof the server rejected a valid key.

5. Use non-interactive registration carefully

Automation can supply the account name, key, computer title and server URL as options. The key below is an obvious placeholder, replace it through a protected secret mechanism rather than committing it to a script:

$ sudo landscape-config --silent \
    --account-name ACCOUNT_NAME \
    --registration-key REGISTRATION_KEY \
    --computer-title HOSTNAME \
    --url https://landscape.example.invalid/message-system

The manual's non-interactive example configures the client to start on boot automatically unless --no-start is supplied. That is a service-disrupting and persistence-affecting choice, use --no-start when you need to write configuration now but will arrange the service start separately.

Command-line options override settings from the file named by --config. You can also import options from a file or URL with --import; imported options rank lower priority than real command-line options. Protect imported files and review them before use, they can contain registration and proxy settings.

A failed registration normally returns a non-zero status. --ok-no-register changes the unregistered result to status 0, which can hide a real deployment failure, use it only when the surrounding automation explicitly records and checks registration later with --is-registered.

6. Add tags or script access only deliberately

Tags help identify a client in Landscape:

$ sudo landscape-config --silent \
    --account-name ACCOUNT_NAME \
    --registration-key REGISTRATION_KEY \
    --computer-title HOSTNAME \
    --tags=server,www

Do not add tags that disclose secrets or sensitive host details. --script-users controls which users can run Landscape scripts. A value of ALL permits every user and is a broad remote-execution boundary, not a convenience default. If script execution is required, name only the accounts that need it and review the access group and server-side permissions too.

7. Disable the client when management must stop

Disabling is an elevated, service-disrupting action. It stops running clients and disables start at boot:

$ sudo landscape-config --disable

This is not the same as deleting registration data, keep the configuration if you expect to resume management. Verify the registration record still exists, then re-enable it through your approved service-management process and run sudo landscape-config --is-registered again.

If you need to remove the client completely, stop here and follow your organisation's package-removal and data-retention procedure. Do not delete /etc/landscape/client.conf or the client data directory merely because the service is disabled, those files are useful for recovery and diagnosis.

Done means

Version confirmed. The installed package and command version were checked.
Previous config backed up. A previous configuration was backed up before reconfiguration, when one existed.
Registered correctly. The client was registered with the correct account, title and server.
Registration verified. sudo landscape-config --is-registered returned status 0.
Secrets kept out. Any non-interactive command keeps the registration key out of source control and shared logs.
Deliberate changes only. Script access, tags, automatic start and disabling were all treated as deliberate configuration changes.