4 Underrated Canonical Tools Every Ubuntu Administrator Should Know

4 Underrated Canonical Tools Every Ubuntu Administrator Should Know

Installing a clean Ubuntu environment, building smaller container images, automating infrastructure deployment, and patching production kernels are routine tasks. They are also easy to get wrong when every team maintains its own collection of scripts.

Canonical has tools for all four problems. Some are aimed at individual developers, while others target infrastructure teams managing hundreds of machines. They share a common philosophy: move repetitive operational work into tools and declarative configuration instead of rebuilding the same procedures for every project.

Canonical’s product portfolio includes more than thirty offerings. Many, such as OpenStack, Ceph, and Kubeflow, target large infrastructure deployments. Others are commercial services rather than standalone development tools.

Four products deserve more attention from everyday Linux developers and administrators: Multipass, Chisel and Rockcraft, Juju, and Landscape with Livepatch.

They do not solve the same problem, and they are not interchangeable. Each addresses a different part of the Linux infrastructure lifecycle.

🖥️ 1. Multipass: A Clean Ubuntu Machine in One Command

#

Developers frequently need a disposable Linux environment for testing packages, validating installation scripts, reproducing production issues, or experimenting with system configuration.

On Windows, the usual options include dual booting, manually configuring Hyper-V, or running a Linux container through Docker Desktop.

On macOS, developers often turn to Docker or a full virtual machine manager.

These approaches work, but they involve more setup than necessary when the requirement is simply a clean Ubuntu machine.

Multipass reduces that setup to a couple of commands.

Launch an Ubuntu virtual machine

#

Install Multipass using the appropriate package for your operating system, then create a new instance:

multipass launch 26.04 \
  --name dev \
  --cpus 2 \
  --memory 4G \
  --disk 20G

Enter the virtual machine:

multipass shell dev

You now have a separate Ubuntu environment with its own kernel, filesystem, network configuration, and systemd instance.

This is fundamentally different from running an ordinary Docker container.

A container shares the host kernel. Multipass creates a virtual machine with an independent operating system environment.

If you break a system service, modify kernel parameters, or experiment with low-level networking inside the VM, the host installation remains isolated from those changes.

Native virtualization across operating systems

#

Multipass uses the host’s available virtualization technology:

The backend depends on the host configuration and supported platform.

Multipass also manages Ubuntu images automatically. You do not need to download an ISO, create a virtual disk manually, and work through an installation wizard every time you need a fresh environment.

Test cloud-init configurations locally

#

One particularly useful feature is the ability to test cloud-init configuration files without provisioning an actual cloud instance.

For example:

multipass launch 26.04 \
  --name staging \
  --cloud-init user-data.yaml

This lets you validate initialization scripts, package installation, user creation, SSH configuration, and service setup in a disposable environment.

If the configuration fails, destroy the instance, fix the YAML, and launch another one.

You can repeat this process until the configuration behaves as expected.

This is especially useful when developing cloud-init templates intended for OpenStack, public cloud platforms, or automated Ubuntu server provisioning.

Where Multipass falls short

#

Multipass is not a lightweight replacement for containers.

A VM configured with 4 GB of memory reserves resources according to its virtualization configuration. It does not provide the same resource-sharing model as a typical container workload.

Other limitations include:

• Nested virtualization depends on host and hypervisor support.
• Hardware acceleration and device passthrough vary by platform.
• Running multiple VMs can consume substantial memory and storage.
• It is not intended to replace a production hypervisor or a full VM orchestration platform.

For individual developers, however, Multipass is one of the easiest ways to obtain a clean Ubuntu installation without disturbing the host system.

📦 2. Chisel and Rockcraft: Build Smaller, More Auditable Container Images

#

Traditional Dockerfiles often follow an imperative approach:

1. Start with a base image.
2. Install the required packages.
3. Copy application files.
4. Remove build dependencies and temporary files.
5. Clean package-manager caches.
6. Hope the final image contains nothing unnecessary.

A common example is:

RUN apt-get update \
    && apt-get install -y --no-install-recommends nginx \
    && rm -rf /var/lib/apt/lists/*

This works, but it is easy to leave behind unnecessary packages, libraries, and metadata.

Canonical’s Chisel takes a different approach.

Instead of installing complete Debian packages and removing unwanted files afterward, Chisel extracts selected filesystem components directly from Ubuntu package archives.

These selected components are called slices.

Chisel: Extract only the files you need

#

A simplified Chisel command looks like this:

chisel cut \
  --release ubuntu-26.04 \
  --root ./rootfs \
  base-files_base \
  libc6_libs

The release identifies the Ubuntu package archive to use, while the slice names identify the components to extract.

The resulting root filesystem contains the selected files and their required dependencies rather than an entire conventional Ubuntu installation.

This is particularly useful for applications that need a small runtime environment but do not need a complete operating system user space.

Chisel is not simply a compression utility. It changes how the runtime filesystem is assembled.

Rockcraft: Turn the filesystem into an OCI image

#

Chisel handles filesystem selection. Rockcraft provides the image-building workflow.

A Rockcraft project is described using rockcraft.yaml, which defines the base, build environment, application parts, dependencies, and target platforms.

A simplified example looks like this:

name: myapp
base: bare
build-base: ubuntu@26.04
version: "1.0"

platforms:
  amd64:

parts:
  myapp:
    plugin: nil
    stage-packages:
      - base-files_base
      - ca-certificates_data

The important distinction is between package names and slice names.

For Chisel-based builds, stage-packages can reference slices rather than complete Ubuntu packages.

The bare base means the image does not inherit a conventional complete user space. You explicitly provide the runtime components required by the application.

Build the image with:

rockcraft pack

Rockcraft produces a .rock artifact. Depending on the Rockcraft version and workflow, it can be used with compatible tooling or converted into an OCI image for container runtimes.

Do not assume that a .rock artifact is directly interchangeable with a Docker image. The artifact format and image import workflow are separate concerns.

Pebble: Manage services inside the container

#

Canonical’s container stack also includes Pebble, a lightweight process supervisor designed for container environments.

Pebble commonly runs as PID 1 and manages application services through declarative YAML configuration.

It handles operational tasks such as:

• Starting and stopping services.
• Restarting processes according to configured conditions.
• Forwarding termination signals.
• Managing service dependencies.
• Exposing service health information.
• Supporting log management.

Without a process supervisor, container projects often end up maintaining custom entrypoint.sh scripts and adding utilities such as tini to handle process lifecycle problems.

Pebble provides a more structured alternative.

Its configuration-driven model is particularly useful when a container needs to run multiple related processes.

Why smaller images are not just about download size

#

Canonical’s Rocks initiative has also applied this approach to common server software.

Examples of workloads distributed through Canonical’s Rock ecosystem include:

• Apache HTTP Server (apache2).
• Nginx.
• BIND 9 (bind9).
• Memcached.
• Squid.

These images combine selected runtime components with a managed service configuration.

The main benefits are reduced image size and a smaller collection of installed components.

However, the security implications deserve more attention than the raw size reduction.

A smaller image generally has fewer installed components that could contain vulnerabilities. It can also reduce the amount of software that needs to be maintained and updated.

But image size alone does not prove that an image is secure.

The more useful metric is the number of actual runtime components, their vulnerability status, and whether the image retains enough package information for reliable security scanning.

Chisel’s package-based approach helps preserve the relationship between extracted files and their originating Ubuntu packages. This is valuable for vulnerability management and software inventory.

Security scanners still need to understand the resulting image format and package metadata correctly. A clean scan should never be interpreted as proof that an image contains no vulnerabilities.

The trade-off: No shell, no package manager

#

Chiseled images are intentionally minimal.

Depending on the image, you may not find:

• /bin/bash.
• A package manager.
• Standard debugging utilities.
• Compilers and development tools.
• Interactive troubleshooting commands.

For example, this command may fail:

docker exec -it myapp bash

That is expected if the image does not contain Bash.

The right solution is not to add an entire debugging toolkit to every production image.

Instead, maintain a separate debugging environment with the required diagnostic tools. Use temporary containers, shared namespaces, or other supported runtime debugging mechanisms when investigating production problems.

Keep the production image focused on running the application.

The real objective is not merely to produce the smallest possible image. It is to minimize unnecessary runtime components while retaining reliable software inventory and vulnerability visibility.

⚙️ 3. Juju and Charms: Package Operational Knowledge as Deployable Software

#

Ansible playbooks and shell scripts are useful for infrastructure automation. Most teams eventually build a collection of reusable roles, templates, and deployment procedures.

The problem appears when that collection grows.

A playbook might contain dozens of conditional branches:

• If the system runs Ubuntu 22.04, modify one configuration file.
• If the database version changes, update another service.
• If the machine becomes a replica, adjust connection settings.
• If a dependency is unavailable, delay deployment until another service becomes ready.

Over time, these decisions become embedded in the automation repository.

A new team member must understand not only what the scripts do, but also why every operational decision exists.

Juju and Charms approach this problem differently.

A charm packages the operational logic required to deploy, configure, maintain, and integrate a service.

Instead of distributing a collection of unrelated scripts, you distribute an application operator that understands the lifecycle of the service it manages.

What a charm actually does

#

A charm can define:

• Application installation.
• Configuration management.
• Service lifecycle operations.
• Upgrade procedures.
• Integration with other applications.
• Monitoring and operational events.
• Scaling and recovery behavior.

Juju acts as the orchestration layer that coordinates these charms.

For example, deploying PostgreSQL can be as simple as:

juju deploy postgresql --channel 16/stable

The exact channel and availability depend on the published charm.

Once the database is deployed, another application can establish an integration:

juju integrate postgresql myapp

The charm relationship handles the exchange of application-specific information.

This can include database credentials, connection endpoints, usernames, and other configuration values.

The application charm receives the information it needs through the relationship interface instead of requiring administrators to manually copy credentials into configuration files.

Relationships are more than configuration templates

#

A useful distinction between Juju and traditional configuration management is that relationships are dynamic.

Suppose an application depends on PostgreSQL.

When the database charm changes relevant connection information, the application-side charm can receive an event and update its configuration.

The same mechanism can support more complex deployments involving message queues, storage systems, databases, and application services.

This reduces the amount of custom orchestration code required to keep dependent services synchronized.

It also gives operational knowledge a defined interface rather than leaving it scattered across deployment scripts.

When Juju makes sense

#

Juju is most useful when infrastructure has to be deployed repeatedly or maintained across multiple environments.

Typical scenarios include:

• Deploying the same application stack across development, testing, and production.
• Operating distributed databases.
• Managing infrastructure across LXD and OpenStack.
• Deploying services to public cloud environments.
• Coordinating applications with complex service relationships.
• Standardizing operational procedures across multiple teams.

Juju 4 introduces changes to the operator framework and charm compatibility model. Existing automation should be reviewed before upgrading.

Why I would not use Juju for everything

#

Juju has a learning curve.

You need to understand controllers, models, applications, units, relations, charms, channels, and the operator lifecycle.

The charm ecosystem also has its own release and maintenance schedule. You cannot assume that every charm receives updates as frequently as a popular container image.

Troubleshooting sometimes requires understanding the operator framework and the charm’s event-handling implementation.

For a single server running two services, this is usually unnecessary.

A Docker Compose file or a small collection of Ansible playbooks is likely to be easier to maintain.

Juju becomes valuable when the complexity of coordinating services exceeds the complexity of operating Juju itself.

🖧 4. Landscape and Livepatch: Manage Machines Without Logging Into Every One

#

Managing one Ubuntu server is straightforward.

Managing ten servers usually means writing scripts.

Managing thirty or more machines introduces a different problem: knowing their actual state at any given moment.

Which machines are missing security updates? Which systems are running outdated packages? Which servers have configuration drift? Which machines require immediate remediation?

Logging into every server individually is not a sustainable answer.

Canonical provides two complementary tools for this problem: Landscape and Livepatch.

Landscape: Centralized Ubuntu fleet management

#

Landscape provides centralized management for Ubuntu systems.

It gives administrators a way to maintain an inventory of managed machines and monitor their software state.

Common capabilities include:

• Machine inventory and system information.
• Package version reporting.
• Package installation and removal.
• Security update management.
• Repository management.
• Remote command execution.
• Compliance-related reporting.
• Centralized administration across multiple systems.

For example, imagine that a security update needs to be deployed to every Ubuntu server running an affected package.

Without centralized management, an administrator might need to write a script, distribute it, execute it across multiple machines, and collect the results.

With Landscape, the administrator can identify affected systems and coordinate package updates through a centralized interface.

This becomes increasingly useful as the number of managed machines grows.

Landscape has different deployment and subscription options. Individual users can access limited free capabilities, while larger managed environments and enterprise features may require a paid subscription.

Livepatch: Apply selected kernel fixes without rebooting

#

Kernel security updates traditionally require a reboot before the updated kernel becomes active.

For desktop systems, this is usually manageable.

For production servers running business-critical services, a reboot can introduce operational risk and require a maintenance window.

Livepatch addresses a specific part of this problem.

It applies supported kernel security patches to a running kernel without requiring an immediate reboot.

The service uses kernel live-patching mechanisms to modify the behavior of affected kernel functions while the system continues operating.

This is particularly useful for servers where frequent reboot windows are difficult to schedule.

However, Livepatch is not a replacement for normal kernel upgrades.

What Livepatch cannot fix

#

Livepatch has technical boundaries.

Not every kernel change can be safely applied to a running system.

A live patch must preserve the assumptions and data structures used by the currently running kernel. Changes that cannot be safely applied through the live-patching mechanism still require a conventional kernel update and reboot.

The distinction matters:

• Supported function-level changes may be applied through live patching.
• Changes involving incompatible data structures or broader kernel behavior may require a reboot.
• Unsupported vulnerabilities remain outside the scope of available live patches.
• User-space library vulnerabilities are not fixed by kernel Livepatch.

The last point is particularly important.

Livepatch operates at the kernel level. It does not patch application libraries, OpenSSL, database software, web servers, or other user-space packages.

Those components must still receive their own security updates.

Ubuntu Pro and Extended Security Maintenance

#

Landscape and Livepatch fit into Canonical’s broader Ubuntu Pro offering.

Ubuntu Pro provides additional security maintenance beyond the standard support period of Ubuntu LTS releases.

Extended Security Maintenance (ESM) extends security coverage for supported packages and release versions.

Combined with the standard Ubuntu LTS support lifecycle, Ubuntu Pro can provide up to fifteen years of security maintenance for eligible releases and package coverage.

The actual coverage depends on the Ubuntu release, package category, subscription, and applicable support terms.

For infrastructure teams, the combination is useful:

• Landscape helps identify and manage machines.
• Livepatch reduces the need for immediate reboots after supported kernel fixes.
• Ubuntu Pro extends security maintenance for supported packages.

These tools address different operational requirements rather than replacing one another.

📋 5. Three Common Misconceptions About Canonical’s Ecosystem

#

Canonical’s product ecosystem has changed over the years. Some information repeated in older Linux tutorials is no longer accurate.

Three areas deserve clarification.

MicroK8s is not the only Canonical Kubernetes offering

#

MicroK8s remains an actively maintained Kubernetes distribution designed for relatively simple installation and operation.

However, Canonical also offers Canonical Kubernetes, which targets broader infrastructure and production deployment requirements.

Canonical Kubernetes is available through different deployment and management approaches, including snap-based installation, charm-based operations, and Cluster API integration.

The right choice depends on the deployment architecture, operational requirements, and the level of infrastructure management needed.

MicroK8s is still a valid choice. It should not automatically be treated as the only Kubernetes product in Canonical’s portfolio.

LXD is maintained by Canonical, while Incus is a community fork

#

LXD was originally developed within the Linux Containers ecosystem.

In July 2023, Canonical took over direct maintenance and moved the project to its own GitHub organization.

The project repository is:

canonical/lxd

Following the governance and development changes, the community fork became known as Incus.

Incus is maintained independently by members of the original LXD community.

Both projects support system containers and virtual machines, but their development paths, release processes, and ecosystem integrations are different.

When choosing between them, check the current maintenance model and compatibility requirements rather than assuming they are interchangeable.

Juju 4 is not a simple version-number upgrade

#

Juju 4 introduces breaking changes that can affect existing charms and automation.

Some legacy interfaces and concepts have been removed or changed, including:

• The older leader-get and leader-set command interfaces.
• The legacy series-based deployment model.
• Older podspec-based charm workflows.

Existing charms and deployment procedures should be reviewed against the Juju 4 documentation before upgrading.

A controller upgrade is not the same as changing a version number in a configuration file.

The operator framework, charm compatibility, deployment configuration, and integration behavior all need to be considered.

Tools commonly mistaken for Canonical products

#

Another source of confusion is the distinction between software developed by Canonical and software that simply runs well on Ubuntu.

The following are not Canonical-developed products:

Canonical packages, supports, integrates, or provides infrastructure for many third-party technologies.

That does not make those projects Canonical products.

For system administrators, the distinction matters when evaluating support responsibilities, release schedules, licensing, and upstream maintenance.

Canonical’s Latest Kernel Security Strategy

#

Canonical’s approach to kernel maintenance continues to evolve. Its move toward more frequent kernel releases also affects how administrators plan patching windows and security updates.

For additional context, see:

• Ubuntu Moves to Weekly Kernel Releases as AI Accelerates CVEs — Explains Canonical’s updated kernel release pipeline and its implications for vulnerability response.
• Ubuntu ARM Becomes First-Class: Livepatch, Steam, and Main Repository Arrive — Covers Livepatch expansion, Ubuntu Pro, and Canonical’s broader ARM64 support.