Debian Packaging for Corosync and Pacemaker

This article provides an overview of how the Debian operating system packages, structures, and maintains enterprise-grade high-availability clustering software, focusing specifically on Corosync and Pacemaker. It explores the role of the Debian High Availability team, package modularization, dependency management, and how the distribution ensures cluster stability across its release lifecycles.

Maintenance by the Debian High Availability Team

Corosync and Pacemaker are maintained within Debian by the Debian HA (High Availability) team. The packaging sources are tracked on Debian’s GitLab instance (Salsa), where maintainers collaborate on upstream tracking, patch integration, and Debian policy compliance. The team coordinates releases to align with Debian's freeze schedules, applying Debian-specific adjustments such as systemd service hardening, compiler flag enforcements (like hardening against buffer overflows), and compliance with the Filesystem Hierarchy Standard (FHS).

Modular Packaging Architecture

Debian breaks large upstream projects into smaller, targeted binary packages to minimize footprint and maintain security boundaries:

  • Corosync: The core engine is packaged as corosync, which provides the cluster communication infrastructure and the corosync.service systemd unit. Related libraries—such as libcmap, libcfg, libcpg, and libquorum—are split into individual shared library packages (e.g., libcorosync-common4, libcmap4) along with their corresponding development headers (*-dev). Debian also packages corosync-qdevice and corosync-qnetd separately for arbitrary quorum node configurations.
  • Pacemaker: The cluster resource manager is split into core utilities, daemons, and libraries. The primary daemon package is pacemaker, while administrative tools like crm_mon, crm_resource, and crm_attribute are included within or modularized into packages like pacemaker-cli-utils. The actual C-libraries powering Pacemaker are distributed as libpacemaker1.
  • Shared Dependencies: Low-level libraries shared by the ecosystem, such as libqb (high-performance IPC and logging) and libknet (Kronosnet, handling the transport layer for Corosync), are packaged as separate independent packages with strict upstream version pinning to maintain deterministic ABI stability.

Resource and Fence Agents Segregation

Pacemaker relies on external scripts to manage resources and perform node fencing (STONITH). Debian separates these scripts from the core engine into dedicated packages:

  • resource-agents: Contains the standard Open Cluster Framework (OCF) scripts for managing virtual IPs, filesystems, and generic application services.
  • fence-agents: Contains the STONITH modules for interacting with hardware management interfaces (IPMI, iLO, DRAC) and cloud provider APIs.

This separation prevents a cluster controller node from needing to install every hypervisor or cloud SDK unless explicitly required by the administrator.

Management Interfaces

Debian provides user-space management utilities through separate packages:

  • crmsh: The classic command-line interface shell for cluster configuration.
  • pcs: The Pacemaker/Corosync configuration system, providing both a CLI and an optional web-based GUI daemon (pcsd).

Because both tools modify cluster XML configurations directly, Debian allows administrators to select their preferred management toolset without forcing one as an absolute dependency of the Pacemaker core.

Lifecycle, Stability, and Upgrades

Debian follows a conservative release cycle. Once a Debian version enters the "Stable" branch, the versions of Corosync and Pacemaker are frozen. Upstream bug fixes and security patches are backported rather than updated to new upstream point releases, ensuring cluster behavior remains predictable throughout the system's support window.

For deployments needing newer upstream features (such as newer fencing APIs or enhanced multi-site capabilities), packages are periodically ported to Debian Backports, allowing targeted upgrades of the clustering stack without changing the underlying base operating system. Configuration files are stored under /etc/corosync/ and /etc/pacemaker/, with Debian maintaining backward compatibility using post-installation scripts that detect and preserve local modifications during upgrades.