... | ... | @@ -2,19 +2,19 @@ |
|
|
|
|
|
Welcome to Kea 1.9.5, the fifth monthly release of the 1.9 development branch. As with any other development release, use this with caution: development releases are not recommended for production use.
|
|
|
|
|
|
This release adds new features, improves existing features, clarifies documentation and fixes a few bugs. The most notable changes introduced in this version are:
|
|
|
This release adds new features, improves existing features, clarifies documentation, and fixes a few bugs. The most notable changes introduced in this version are:
|
|
|
|
|
|
**New script hook.** Due to popular demand a new hook that calls an arbitrary external script has been added. These scripts may initiate an external process, such as, for example, updating routing and firewall rules for provisioned devices. The script is called asynchronously, i.e. Kea starts the script, doesn't wait for its completion, and continues with processing the packet. This approach greatly decreases performance impact. This hook has been only lightly tested. Use with caution and please do share your experience #899.
|
|
|
**New script hook.** Due to popular demand, a new hook that calls an arbitrary external script has been added. This script may initiate an external process, such as updating routing and firewall rules for provisioned devices. The script is called asynchronously, i.e. Kea starts the script, does not wait for its completion, and continues processing the packet. This approach greatly decreases performance impact. This hook has been only lightly tested; use it with caution and please do share your experience. #899
|
|
|
|
|
|
**Setting lease time for client classes.** Earlier Kea versions allowed setting different lease lifetimes depending on where the device was located in the network (using the global, network, or subnet levels). However, it was impossible to set the lifetime based on device type. This missing capability is now implemented for IPv4, with IPv6 support coming up soon #1635.
|
|
|
**Setting lease time for client classes.** Earlier Kea versions allowed setting different lease lifetimes depending on where the device was located in the network (using the global, network, or subnet levels). However, it was impossible to set the lifetime based on device type. This missing capability is now implemented for IPv4, with IPv6 support coming soon. #1635
|
|
|
|
|
|
**TLS support work in progress.** The Kea team continues its work on implementing TLS in Kea. The ultimate goal is for the CA to be able to accept HTTPS connections. While the TLS solution is not usable yet, several important milestones have been completed. There are now several new parameters available in the Control Agent (CA) configuration: `trust-anchor`, `cert-file`, `key-file` and `cert-required`. The parameters can be configured, but they are not used yet. A new config example `doc/examples/agent/https.json` has been added with some commentary #1662. Another change updated the asiolink library to be able to handle the new TLS socket type. This is not a user-visible change #1644.
|
|
|
**TLS support work in progress.** The Kea team continues its work on implementing Transport Layer Security (TLS) in Kea. The ultimate goal is for the Control Agent (CA) to be able to accept HTTPS connections. While the TLS solution is not yet usable, several important milestones have been completed. There are now several new parameters available in the CA configuration: `trust-anchor`, `cert-file`, `key-file`, and `cert-required`. The parameters can be configured, but they are not yet used. A new config example, `doc/examples/agent/https.json`, has been added with some commentary (#1662). Another change updated the asiolink library to be able to handle the new TLS socket type. This is not a user-visible change. #1644
|
|
|
|
|
|
**DB cluster improvements.** Kea does not officially support any DB clustering solutions. We have heard from users who have used clustering solutions with varying results. The ISC team has begun experimenting with Galera, Percona, NDB, and group replication. We set up clusters and ran unit and system tests and found a few issues to address. The first two improvements make our MySQL libraries run better in a Percona cluster. One ticket updated the MySQL schema with the primary key for forensic logging (#1709), while another fixed several problems in unit tests that manifested themselves only on Percona (#1708). Finally, we are getting ready to run performance tests of multiple Kea instances connected to a DB cluster. To do that reliably, we need to export the list of leases assigned by each instance and then correlate them to check for any duplicates. With that in mind, we extended our `perfdhcp` tool with the ability to export the list of assigned leases. We hope to make good use of that capability in future tests #1703.
|
|
|
**DB cluster improvements.** Kea does not officially support any database (DB) clustering solutions; we have heard from users who have used clustering solutions with varying results. The ISC team has begun experimenting with Galera, Percona, NDB, and group replication. We set up clusters and ran unit and system tests, and found a few issues to address. The first two improvements make our MySQL libraries run better in a Percona cluster. One ticket updated the MySQL schema with the primary key for forensic logging (#1709), while another fixed several problems in unit tests that manifested themselves only on Percona (#1708). Finally, we are getting ready to run performance tests of multiple Kea instances connected to a DB cluster. To do that reliably, we need to export the list of leases assigned by each instance and then correlate them to check for any duplicates. With that in mind, we extended our `perfdhcp` tool with the ability to export the list of assigned leases. We hope to make good use of that capability in future tests. #1703
|
|
|
|
|
|
**Bug fixes.** Earlier Kea versions could experience a DB access deadlock when processing a high request rate while the forensic logging hook was configured to write log entries to a database and multi-threading was enabled. This release includes a fix for this problem #1711. One user reported that Kea used values defined in client classes in a non-deterministic way. The code has been updated to provide consistent behavior for options and fixed fields #1672. When dealing with client classification, it is possible to encounter a situation when there are subnets and pools available, but due to the client not meeting the class requirements is unable to use any of them. In such cases, earlier Kea versions printed cryptic error messages, such as `failed to allocate an IPv4 address after 0 attempt(s)`. This was confusing. The message has been tweaked and there are several additional messages that explain the reasons why the allocation failed. More details are available debug the problem #1701.
|
|
|
**Bug fixes.** Earlier Kea versions could experience a DB access deadlock when processing a high request rate while the forensic logging hook was configured to write log entries to a database and multi-threading was enabled. This release includes a fix for this problem (#1711). One user reported that Kea used values defined in client classes in a non-deterministic way. The code has been updated to provide consistent behavior for options and fixed fields (#1672). When dealing with client classification, it is possible to encounter a situation when there are subnets and pools available, but the client does not meet the class requirements and is therefore unable to use any of them. In such cases, earlier Kea versions printed cryptic error messages, such as `failed to allocate an IPv4 address after 0 attempt(s)`. This was confusing, so the message has been tweaked; several additional messages explain the reasons why the allocation failed. More details are available to debug the problem. #1701
|
|
|
|
|
|
**MySQL DB upgrade improvements.** Two prior development releases had incorrectly versioned database schema. As a result, when upgrading from 1.9.2 or 1.9.3 to 1.9.4 the `kea-admin` tool incorrectly assumed the schema was already updated, when if fact it wasn't. This is now corrected #1698. Upgrading from any earlier Kea versions to 1.9.5 work and a work around for ugprading to 1.9.4 is documented in the Known issues list. See the link below.
|
|
|
**MySQL DB upgrade improvements.** Two prior development releases had incorrectly versioned database schema. As a result, when upgrading from 1.9.2 or 1.9.3 to 1.9.4 the `kea-admin` tool incorrectly assumed the schema was already updated, when in fact it was not. This is now corrected (#1698). Upgrading from any earlier Kea versions to 1.9.5 works correctly, and a workaround for upgrading to 1.9.4 is documented in the Known issues list. See the link below.
|
|
|
|
|
|
## Incompatible Changes
|
|
|
|
... | ... | @@ -26,7 +26,7 @@ For details on known issues, visit: |
|
|
|
|
|
https://gitlab.isc.org/isc-projects/kea/-/wikis/known-issues-list
|
|
|
|
|
|
And the list of issues marked as bug:
|
|
|
And for the list of issues marked as bugs:
|
|
|
|
|
|
https://gitlab.isc.org/isc-projects/kea/issues?label_name%5B%5D=bug
|
|
|
|
... | ... | |