Upgrading to a Newer Version of Kea
  • 24 Jun 2020
  • 2 Minutes To Read
  • Contributors
  • Print
  • Share
  • Dark
    Light

Upgrading to a Newer Version of Kea

  • Print
  • Share
  • Dark
    Light

Introduction

Upgrading Kea is a relatively easy task. This article describes a Kea upgrade for versions 1.6.0 and newer; for instructions on how to upgrade older versions, please visit our Kea wiki page. Please make sure that the version you are about to upgrade is not listed in the "Exceptions" section below.

If there are future releases that are not backward-compatible, we will update this article.

Upgrade Preparations

Before starting the upgrade process, please read the release notes for the new version to check for changes that make your current configuration incompatible and, if necessary, update your configuration. Fortunately, incompatibilities are rare; one example was when we moved the location of the logging statement in the Kea configuration hierarchy. These types of changes will always be noted in the release notes.

Kea database upgrade scripts can detect the current running schema version and execute all necessary steps to upgrade, so it's possible to update across several version bumps at once (i.e,. from 1.6.0 to 1.6.2, without 1.6.1 in between).

Moving from Source to Packages

Moving from a source (tarball) installation to using a Kea package must be done with caution. When building from source, the location of the binaries, system libraries, and other support files may be defined on the configure command line. When moving to ISC-supplied packages, the locations of the files may change.

Be very careful when installing packages that remnants of the previously installed code do not remain on the system. Not removing the executables can lead to issues during system startup or maintenance when an older version of the server is run instead of the newly installed version. Not removing shared libraries can cause newly installed servers to attempt to use the older libraries and fail with linker errors.

Best Practice

It is highly recommended that you make copies of your configuration files before you begin a source-to-package migration.

Upgrading a Single Server

These instructions are for deployments that are not using High Availability. If you are building from source, compile the new version first.

  1. Back up the configuration and leases files.
  2. Turn off Kea.
  3. Install the new version.
  4. If you are using a database backend, run the kea-admin script as stated in the Administrator's Reference Manual (ARM for mysql, ARM for pgsql). If you are using the default memfile option, that will be upgraded automatically.
  5. Start Kea.

Upgrading a High-Availability Pair

When upgrading a HA pair, you can follow essentially the same process as above; simply repeat some of the steps. Important things to know are:

  • It is not necessary to turn off all nodes to upgrade. Each node can be updated in turn, while maintaining DHCP service in the network.
  • Kea 1.7.4 and newer versions have an in-maintenance mode, activated by the command ha-maintenance-start. It is recommended to use this command to instruct the HA partner server to take over all DHCP services, allowing the operator to upgrade the other server.
  • If you are not using ha-maintenance-startfor some reason, always start the upgrade from the lowest priority node, and move up one by one:
    • If your servers are in hot-standby, upgrade the secondary or backup machine first (if used).
    • If your servers are load-balancing, upgrade the backup first (if used). The upgrade sequence for load-balancing servers does not matter.
  • If HA nodes are using separate database backends, each should be updated separately.
  • If HA nodes are sharing a single database only one update is required.

Exceptions

These instructions do not apply to Kea versions prior to 1.6.0. Please visit the Kea wiki page for details.

Was This Article Helpful?