⚠️ This is NOT a viable Landscape deployment method.lslabis a developer/support tool for spinning up disposable, single-host test environments using LXD containers or VMs. It is intended exclusively for debugging, bug reproduction, and testing. Do not use it to deploy or manage production Landscape infrastructure.
A CLI tool (lslab) for quickly creating and tearing down self-contained Landscape server + client environments. Designed for support engineers and developers who need to reproduce bugs, test client behaviour, or validate fixes against a real Landscape stack without touching production.
- One-command environments —
lslab up mylabprovisions a Landscape server, creates client containers, registers them, and prints access details in a single operation - Multiple concurrent deployments — each deployment is fully isolated with its own state, cookies, and certificates
- Full client lifecycle — add, remove, register, deregister, accept, isolate, and unisolate clients
- Direct debugging access — shell into containers, run commands, query the Landscape database directly, call the REST API, tail logs, manage services
- Snapshots — checkpoint and restore individual containers or entire deployments
- Network simulation — isolate clients from the server to test offline/disconnected behaviour
- Context switching —
lslab use <name>sets the active deployment for concise commands - Doctor — automated diagnostics for common misconfiguration issues
- Containers or VMs — use
--container(fast, default) or--vm(full kernel isolation)
- Ubuntu 20.04+ (tested on 22.04 and 24.04)
- LXD (snap) — your user must be in the
lxdgroup jqinstalled (sudo apt install jq)curlinstalled- ~4 GB RAM and ~10 GB disk per deployment (the Landscape server is resource-heavy)
- Internet access (for Ubuntu archive and Landscape PPA)
git clone <repo-url>
cd landscape-lab
chmod +x lslab
# Optionally symlink into PATH:
sudo ln -s "$PWD/lslab" /usr/local/bin/lslabEnsure LXD is initialized:
sudo snap install lxd
lxd init --auto # or configure interactively
sudo usermod -aG lxd "$USER" && newgrp lxdVerify prerequisites:
lslab --version # prints version
lslab help # shows full command reference# Create a deployment with 3 clients (auto-registered)
lslab up mylab --clients 3 --container
# Open the Landscape web UI in your browser
lslab open
# Check deployment status (shows server state, client registrations)
lslab status
# Shell into the server
lslab shell server
# Shell into client 2 (numeric shorthand)
lslab shell 2
# Register a client manually (if --no-register was used during up)
lslab register-client client-1
# Snapshot everything before a risky change
lslab snapshot-all before-change
# Destroy when done
lslab destroy mylabEdit config.sh or override via environment variables:
| Variable | Default | Description |
|---|---|---|
LANDSCAPE_VERSION |
24.04 |
Landscape PPA version to install |
UBUNTU_RELEASE |
noble |
Ubuntu release for containers/VMs |
USE_VM |
false |
true for VMs, false for containers |
NUM_CLIENTS |
3 |
Default number of clients to provision |
AUTO_REGISTER |
true |
Register clients automatically at provision time |
REGISTRATION_KEY |
lslab-key-1 |
Key for auto-accepting clients |
ADMIN_EMAIL |
admin@landscape.lab |
Admin account email |
ADMIN_PASSWORD |
landscapelab |
Admin account password |
SERVER_CPUS |
2 |
CPUs allocated to the server |
SERVER_MEM |
4GB |
Memory allocated to the server |
CLIENT_CPUS |
1 |
CPUs allocated to each client |
CLIENT_MEM |
1GB |
Memory allocated to each client |
SCRIPT_USERS |
root,landscape |
Users allowed to run Landscape scripts |
-d, --deployment <id> Override active deployment for this command
--version Print version and exit
| Command | Description |
|---|---|
up [ID] [OPTIONS] |
Create and provision a new deployment |
destroy|rm ID [--force] |
Destroy a deployment and all its containers |
down [--force] |
Destroy the current deployment |
list|ls |
List all deployments with status overview |
status |
Show server and client state for active deployment |
info [ID] |
Show access details (URLs, credentials, IPs) |
up options: --clients N, --register-count N, --no-register, --version VER, --release REL, --vm\|--container
| Command | Description |
|---|---|
use ID |
Set the active deployment |
current |
Print the active deployment ID |
| Command | Description |
|---|---|
add-client [NAME] [OPTIONS] |
Add a new client container/VM |
remove-client NAME |
Remove and destroy a client |
register-client NAME [OPTIONS] |
Register a client with the Landscape server |
deregister-client NAME |
Deregister a client |
accept-client NAME |
Accept a pending client |
pending |
List pending (unaccepted) computers |
add-client options: --register\|--no-register, --release REL, --tags TAG1,TAG2, --access-group GROUP, --vm\|--container
register-client options: --registration-key KEY, --no-key, --tags TAG1,TAG2, --access-group GROUP
| Command | Description |
|---|---|
isolate NAME |
Block a client's network access to the server |
unisolate NAME |
Restore network access |
| Command | Description |
|---|---|
snapshot NAME [SNAP] |
Create a snapshot (auto-names if omitted) |
restore NAME [SNAP] |
Restore from a snapshot |
snapshots NAME |
List snapshots for a container |
snapshot-all [SNAP] |
Snapshot all containers in the deployment |
| Command | Description |
|---|---|
shell NAME |
Open an interactive shell in a container |
exec NAME -- CMD [ARGS...] |
Run a command in a container |
open |
Open the Landscape web UI in a browser |
inspect NAME |
Show detailed container/VM information |
logs NAME [--service SVC|all] [-f] |
View or follow service logs |
service NAME start|stop|restart|status [SVC] |
Manage services |
db [DB_NAME] |
Open a psql session or run SQL against Landscape DB |
api ENDPOINT [--method M] [--data JSON] [--raw] |
Call the Landscape REST API |
doctor |
Run automated diagnostic checks |
The examples/ folder contains comprehensive walkthroughs with full command output:
- Basic Deployment — create, inspect, destroy
- Multi-Deployment — side-by-side environments, context switching
- Client Management — register, deregister, accept, add, remove
- Snapshots — checkpoint and restore
- Network Isolation — simulate connectivity problems
- Debugging — inspect, logs, services, database, shell
- Support Workflows — real-world scenarios for reproducing issues
# Reproduce a client registration issue
lslab up repro --clients 1 --no-register --container
lslab shell 1
# Manually run landscape-config with different options...
# Test with a specific Ubuntu release
lslab up jammy-test --clients 2 --release jammy
# Isolate a client to test offline behaviour
lslab isolate client-1
# Client can no longer reach the server
lslab unisolate client-1
# Query the server database directly
lslab db "SELECT title, last_ping_time FROM computer;"
# Snapshot before a risky change
lslab snapshot-all before-upgrade
lslab exec server -- apt upgrade landscape-server-quickstart
# Restore if something broke:
lslab restore server before-upgradeState, certificates, and cookies are stored in:
${XDG_DATA_HOME:-~/.local/share}/lslab/deployments/<id>/
├── state.json # Deployment state and client metadata
├── server.pem # Server TLS certificate (copied from server container)
└── cookies.txt # Session cookies for API calls
- Not for production — this tool installs Landscape via the quickstart package in containers; it is unsuitable for any production or long-lived deployment
- Single-host only — everything runs on one machine via LXD
- Resource-heavy — the Landscape server alone needs ~4 GB RAM and several GB of disk
- No HA — single server, no clustering, no load balancing
- Self-signed TLS — certificates are self-signed and extracted from the server container
MIT