Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-02-21T16:25:39Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3130ax_gtest.m4 needs further small improvement2024-02-21T16:25:39ZPiotrek Zadrogaax_gtest.m4 needs further small improvementDuring Kea 2.5.3 rc2 sanity checks it turned out that in case `./configure --with-gtest-source` is called with a path with trailing slash `/`, e.g.
```
--with-gtest-source=/usr/src/googletest/googletest/
```
the gtest version could not b...During Kea 2.5.3 rc2 sanity checks it turned out that in case `./configure --with-gtest-source` is called with a path with trailing slash `/`, e.g.
```
--with-gtest-source=/usr/src/googletest/googletest/
```
the gtest version could not be correctly detected (https://gitlab.isc.org/isc-projects/kea/-/issues/3126#note_412356).
This is a follow up to #3065
Trailing slash is a special case and the script needs small patch for that.kea2.5.6Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3128update hammer to build kea packages without freeradius dependency2023-12-05T09:23:28ZWlodzimierz Wencelupdate hammer to build kea packages without freeradius dependencyWith new radius we will no longer need freeradius dependency, remove it from hammerWith new radius we will no longer need freeradius dependency, remove it from hammerkea2.5.5Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3127Add load code and tests to new RADIUS2023-10-26T14:18:33ZFrancis DupontAdd load code and tests to new RADIUSWas scheduled for #3115. Should be easy and anyway should be done one day...Was scheduled for #3115. Should be easy and anyway should be done one day...kea2.5.4Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3126Sanity checks for Kea 2.5.3 rc22023-11-28T14:49:23ZWlodzimierz WencelSanity checks for Kea 2.5.3 rc2We are now at step SANITY CHECKS of Kea 2.5.3 rc2.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.5.3 rc2.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.5.3-rc2`
* `/data/shared/sweng/kea/releases/premium-2.5.3-rc2`
* `/data/shared/sweng/kea/releases/subscription-2.5.3-rc2`
* `/data/shared/sweng/kea/releases/enterprise-2.5.3-rc2`
```
SHA256 (kea-2.5.3.tar.gz) = bb7cf06af1cc27da0d55d071651b75018e898d14c9f6e2e837ee0515006f6fef
SHA256 (kea-enterprise-2.5.3.tar.gz) = 07a155679e80bdb743d48c80e1807f09f76b92121d4ad42c2d7f0dc51ae1679a
SHA256 (kea-premium-2.5.3.tar.gz) = e1775673d6f4d681d404e284eeac560abae63c76bcde5de55fcddd1ffd22bb53
SHA256 (kea-subscription-2.5.3.tar.gz) = dc9c9bf185e5de46d406d3ca5fe2b8c16b98f2a21fb4bb21e87b990337cb384f
```
#### Packages on packages.aws.isc.org
* [APK: 2.5.3-r20231024153937](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20231024153937.apk)
* [deb: 2.5.3-isc20231024153937](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.5.3-isc20231024153937)
* [RPM: 2.5.3-isc20231024153937.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.5.3-isc20231024153937*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1329/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).kea2.5.3https://gitlab.isc.org/isc-projects/kea/-/issues/3124Sanity checks for Kea 2.5.3 rc12023-11-28T14:49:23ZWlodzimierz WencelSanity checks for Kea 2.5.3 rc1We are now at step SANITY CHECKS of Kea 2.5.3 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.5.3 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is.
This way we know what is covered upfront and we can avoid repeating ourselves.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.5.3-rc1`
* `/data/shared/sweng/kea/releases/premium-2.5.3-rc1`
* `/data/shared/sweng/kea/releases/subscription-2.5.3-rc1`
* `/data/shared/sweng/kea/releases/enterprise-2.5.3-rc1`
```
SHA256 (kea-2.5.3.tar.gz) = 075fea1ca59d302526b6ac2fa976a71af8d02ed7114a3a87258533171f57148e
SHA256 (kea-enterprise-2.5.3.tar.gz) = 9b1174e5b69a858b687816507a405d19a14ee8de175c0136bcfc6de958a00b95
SHA256 (kea-premium-2.5.3.tar.gz) = 06279c5191d7305e08f6549443567a537866660f81a27f5ec6354866d0480ba9
SHA256 (kea-subscription-2.5.3.tar.gz) = df13fcac556fb57b857d4b40b7dda042a7095c864bae186da7c0b26fbfb87a1e
```
#### Packages on packages.aws.isc.org
* [APK: 2.5.3-r20231023144813](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20231023144813.apk)
* [deb: 2.5.3-isc20231023144813](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.5.3-isc20231023144813)
* [RPM: 2.5.3-isc20231023144813.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.5.3-isc20231023144813*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1327/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).https://gitlab.isc.org/isc-projects/kea/-/issues/3123Synced leases with HA standby cause RADIUS accounting packets2024-01-26T15:38:09ZDarren AnkneySynced leases with HA standby cause RADIUS accounting packetsIf the Kea HA peers (`libdhcp_ha.so`) are configured to send RADIUS accounting packets using the `libdhcp_radius.so` hook, then the standby peer also sends accounting packets on lease sync. This can create a few problems such as:
- The ...If the Kea HA peers (`libdhcp_ha.so`) are configured to send RADIUS accounting packets using the `libdhcp_radius.so` hook, then the standby peer also sends accounting packets on lease sync. This can create a few problems such as:
- The "acct-session-id" will not match between the accounting packets sent from the primary and standby Kea peers.
- The timestamp of the event may not match between the packets sent from the primary and standby Kea peers.
- If there were attributes gathered via the RADIUS authentication process, this will not have occurred on the standy peer. Therefore, there may be missing data in the accounting packet.
Propose that some type of flag to disable sending these accounting updates from the standby server be added.
[SF1403](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZRLi2QAH/view)kea2.5.5Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3122Changes for Kea 2.5.3 release2023-10-23T14:06:52ZWlodzimierz WencelChanges for Kea 2.5.3 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.5.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3121HA scenario: some devices keep sending DHCP requests2023-11-27T17:49:20ZdotsoltectiHA scenario: some devices keep sending DHCP requests---
name: Bug report
about: Some clients keep sending DHCP requests in a HA setup, in single server setup they don't
---
**Describe the bug**
Two clients in my network keep sending DHCP requests when using 2 kea dhcp4-servers in a HA s...---
name: Bug report
about: Some clients keep sending DHCP requests in a HA setup, in single server setup they don't
---
**Describe the bug**
Two clients in my network keep sending DHCP requests when using 2 kea dhcp4-servers in a HA setup. This results in those 2 clients not being connected. When running 1 kea dhcp4-server (without HA configuration) the two clients work perfectly fine.
**To Reproduce**
Steps to reproduce the behavior:
1. Start kea dhcp4-server and control agent on 2 hosts (1 Debian bullseye; 1 Odroid C4) in Docker containers using this compose file[docker-compose.yml](/uploads/de75b17bfe9fe5d299a5a7e9b24b6bb8/docker-compose.yml) and configuration files [ctrl-agent.json](/uploads/d03fb3c809be7801c090a926299fd009/ctrl-agent.json), [dhcp4_HA.json](/uploads/13b888a95714c3e810ce6a4b1c9322e2/dhcp4_HA.json)
2. The server starts fine, heartbeats work fine, most of the clients are working as expected.
3. Two clients (same manufacturer) keep sending DHCP requests. The result seem that those 2 clients are unable to connect to the network. For example the devices with MAC address 1c:ca:e3:7a:60:8c in this log: [_kea-dhcp4_logs_6_.txt](/uploads/49a209571159a112e12eb17b5114c850/_kea-dhcp4_logs_6_.txt). Log file does not seem to throw any relevant errors.
**Expected behavior**
Two clients should be able to connect even in HA setup.
**Environment:**
- Kea version: 2.4.0
- OS: Docker images on 1) Debian Bullseye host and 2) Odroid C4 with Armbian 23.02.2 Bullseye
**Additional Information**
Configuration files are attached above, but always available to provide more information.
**Contacting you**
How can ISC reach you to discuss this matter further? Via e-mail: h37dcmrr@duck.comhttps://gitlab.isc.org/isc-projects/kea/-/issues/3119Coverity scan issues2024-02-06T12:55:09ZPiotrek ZadrogaCoverity scan issuesI triaged new issues detected by Coverity scan and below ones could be checked more carefully:
- High: `time_t` casting to `uint_32` - assuming we are doing `static_cast`, we should be ok until year 2106. One cases misses the `static_ca...I triaged new issues detected by Coverity scan and below ones could be checked more carefully:
- High: `time_t` casting to `uint_32` - assuming we are doing `static_cast`, we should be ok until year 2106. One cases misses the `static_cast`.
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303669&defectInstanceId=53277773&mergedDefectId=1533185
- Medium: dereferencing invalid iterator - in most cases it seems to be false positive, but there is one place where it could be checked - this could have separate ticket
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303968&defectInstanceId=53270168&mergedDefectId=1533337
- Low: used `auto` causing copy - this is low priority, but could be fixed anyway, just `const auto&` could be used.
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303713&defectInstanceId=53363199&mergedDefectId=1539484
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303704&defectInstanceId=53363142&mergedDefectId=1539483
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250303706&defectInstanceId=53363182&mergedDefectId=1539482
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250304018&defectInstanceId=53270328&mergedDefectId=1532980 and all others in `src/hooks/dhcp/lease_cmds/lease_cmds.cc`
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250304037&defectInstanceId=53270311&mergedDefectId=1532961 and all others in `src/hooks/dhcp/mysql_cb/mysql_cb_dhcp*.cc`
- https://scan5.scan.coverity.com/reports.htm#v60426/p10289/fileInstanceId=250304057&defectInstanceId=53270884&mergedDefectId=1532978 and all others in `src/hooks/dhcp/pgsql_cb/pgsql_cb_dhcp*.cc`kea2.5.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3118bump up library version for 2.5.32023-10-23T12:30:14ZWlodzimierz Wencelbump up library version for 2.5.3....as stated in the title ;)....as stated in the title ;)kea2.5.3Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/31172.5.3 release checklist2023-10-26T10:53:53ZWlodzimierz Wencel2.5.3 release checklist# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual fr...# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
For new stable releases or maintenance releases, please don't use `kea-dev` build farm. Use dedicated build farm for each release cycle.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [x] Finish release notes and conduct its review. Also please notify @sgoldlust or @vicky that release notes are ready for review.
1. [ ] Check that packges can be uploaded to cloudsmith.
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick the latest pkg build in the `Packages` field, and the corresponding tarball build in the `Tarball` field, leave the rest as they are `PrivPubRepos: "private"`, `TarballOrPkg: "packages"`, `TestProdRepos: "testing"` and click `Build`.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation. Alternatively, look for failures in emails if you know that the ReadTheDocs webhook is working.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 1.9.7 --repo-dir ~/isc/repos/kea/` Use `--upload` to commit changes. <br>
Help: `GITLAB_TOKEN="..." ./update-code-for-release.py --help`<br>
This script makes the following changes and actions:
1. run prepare_kea_release.sh that does:
1. add release entries in ChangeLogs
1. update Kea version in configure.ac
1. update copyright years in files that were changed in current year
1. sort message files
1. regenerate message files headers
2. regenerate parsers using Bison from Docker<br>
With `--upload`:
3. create an issue in GitLab for release changes in kea repo
4. create branches and merge requests for kea and kea-premium
5. commit the changes in both repos
6. checkout created branches in both repos
7. commit and push the changes to GitLab server
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick:
1. `rc1` if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement on the Kea/DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. Kea-2.2.2): <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description: <br>
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Upload final tarballs to repo.isc.org.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click `Build with Parameters`.
1. In field `Tarball` select picked tarball build.
1. In field `Pkg` select the corresponding pkg job.
1. In field `Release_Candidate` pick `final`. <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- if release engineer is holding personal signing key, please use [sign, verify, and upload script](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh)
- if release enginner do NOT have signing key, please contact team member.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click `Build with Parameters`.
1. Pick your selected pkg build in the `Packages` field, the corresponding tarball build in the `Tarball` field, `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build`.
- This step also verifies sign files.
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Update ReadTheDocs
1. Trick ReadTheDocs into pulling the latest tags. Click `Build version` on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. If it's a stable release, change the default version to point to this stable release. `Admin -> Advanced Settings -> Default version* -> Kea-a.b.c`.
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` most of the time, or
* `a.y.0-git` where `y == b + 2` if a new development series starts, or
* `x.1.0-git` where `x == a + 1` when the released minor version `b` is 9 and `a.b.c` was the last version in the development series and a new development version is coming up next.
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [x] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(Support)*** Inform Marketing of the release.
- [x] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [x] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [x] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(Marketing)*** Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
- [x] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).kea2.5.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3116Kea DDNS can not listen on 0.0.0.02023-10-20T13:03:51ZMarcin GodzinaKea DDNS can not listen on 0.0.0.0Kea DDNS can not listen on 0.0.0.0.
This is a problem if using DDNS in hostname-based environment with unknown IP like docker networks.
```
DHCP_DDNS_CONFIG_FAIL DHCP-DDNS server configuration failed: IP address cannot be "0.0.0.0" (/etc...Kea DDNS can not listen on 0.0.0.0.
This is a problem if using DDNS in hostname-based environment with unknown IP like docker networks.
```
DHCP_DDNS_CONFIG_FAIL DHCP-DDNS server configuration failed: IP address cannot be "0.0.0.0" (/etc/kea/kea-dhcp-ddns.conf:3:23)
DCTL_CONFIG_FILE_LOAD_FAIL DhcpDdns reason: IP address cannot be "0.0.0.0" (/etc/kea/kea-dhcp-ddns.conf:3:23)
Service failed: Could Not load configuration file: IP address cannot be "0.0.0.0" (/etc/kea/kea-dhcp-ddns.conf:3:23)
```
I think it should present a Warning message like setting IP defined one other than 127.0.0.1 and not an error preventing starting up a service.
Check is performed in `src/lib/d2srv/d2_config.cc`
```
void
D2Params::validateContents() {
if ((ip_address_.toText() == "0.0.0.0") || (ip_address_.toText() == "::")) {
isc_throw(D2CfgError,
"D2Params: IP address cannot be \"" << ip_address_ << "\"");
}
```kea2.5.3Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3115new RADIUS config2023-10-24T22:03:04ZFrancis Dupontnew RADIUS configPort the RADIUS config from the old code but getting rid of the AUTH/ACCT table.Port the RADIUS config from the old code but getting rid of the AUTH/ACCT table.kea2.5.3Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3112the io_service run/run_once/poll should be called in a try-catch_all block in...2023-12-14T20:22:27ZRazvan Becheriuthe io_service run/run_once/poll should be called in a try-catch_all block in thread function in thread poolsthe io_service->run should be guarded by a try catch(...) and exceptions should be logged (if possible):
```
void
IoServiceThreadPool::threadWork() {
bool done = false;
while (!done) {
switch (getState()) {
case ...the io_service->run should be guarded by a try catch(...) and exceptions should be logged (if possible):
```
void
IoServiceThreadPool::threadWork() {
bool done = false;
while (!done) {
switch (getState()) {
case State::RUNNING: {
{
std::unique_lock<std::mutex> lck(mutex_);
running_++;
// If We're all running notify main thread.
if (running_ == pool_size_) {
main_cv_.notify_all();
}
}
// try { <<<---
// Run the IOService.
io_service_->run();
// } catch(exception& ex) { <<<---
// LOG the exception error here <<<---
// } catch (...) { <<<---
// LOG general error here <<<---
// } <<<---
```kea2.5.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3110ping-check-hook update HA peer(s) with lease declinations2023-12-01T16:56:45ZThomas Markwalderping-check-hook update HA peer(s) with lease declinationsThe design overlooked how HA update peers will be updated when leases are declined. The initial release may simply state the hook is experimental and doesn't work with HA.
Proposed solution:
Leases are marked decline via a function a...The design overlooked how HA update peers will be updated when leases are declined. The initial release may simply state the hook is experimental and doesn't work with HA.
Proposed solution:
Leases are marked decline via a function added to support
ping-checking, Dhcpv4Srv::serverDecline(). This function gets
invoked by the unpark callback if ping-check concluded the address
is unavailable (i.e. in use).
In order to propagate the declination to HA peers, a new hook point
will be added within this function, "lease4-server-decline". This
affords any hook library with an opportunity to take an action when
the server declines a lease. There is already a "lease4-decline" hook
point but this is for leases that are declined by clients via DHCPDECLINEs.
HA will need to implement a callout handler for this hook point which
propagates the update to the appropriate peer(s). Unlike updates done
via leases4_committed, there is no outbound response pending and
thus no need to park the query. Nor is there any need to wait for
the updates to be acknowledged.kea2.5.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3109Logging inconsistency between dhcp4.packets and dhcp6.packets2023-11-27T11:53:16ZDarren AnkneyLogging inconsistency between dhcp4.packets and dhcp6.packetsThis log for DHCPv4:
```
[kea-dhcp4.packets/2921701.140031672309504] DHCP4_QUERY_DATA [hwtype=1 00:00:00:ff:ff:ff], cid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0x8eabb73f, packet details: local_address=1.2.3.4:67, remote_address=1.2.3.5:...This log for DHCPv4:
```
[kea-dhcp4.packets/2921701.140031672309504] DHCP4_QUERY_DATA [hwtype=1 00:00:00:ff:ff:ff], cid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0x8eabb73f, packet details: local_address=1.2.3.4:67, remote_address=1.2.3.5:68, msg_type=DHCPREQUEST (3), transid=0x8eabb73f,
```
contains the msg_type while the DHCPv6 counterpart does not:
```
[kea-dhcp6.packets/3264085.139762203666176] DHCP6_QUERY_DATA duid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0x5f541f, packet details: localAddr=[1:1:1:1::1]:0 remoteAddr=[2:2:2:2::2]:547
```
Similar inconsistency in these two log messages:
```
[kea-dhcp4.packets/2921701.140031535531776] DHCP4_RESPONSE_DATA [hwtype=1 00:00:00:ff:ff:ff], cid=[00:00:00:00:ff:ff:ff:ff:ff:ff:ff], tid=0xfe456e5f: responding with packet DHCPACK (type 5), packet details: local_address=1.2.3.4:67, remote_address=1.2.3.5:68, msg_type=DHCPACK (5), transid=0xfe456e5f,
```
and
```
[kea-dhcp6.packets/3264085.139762070353664] DHCP6_RESPONSE_DATA responding with packet type 7 data is localAddr=[1:1:1:1::1]:547 remoteAddr=[2:2:2:2::2]:547
```
Perhaps this is this way for a reason? There are, of course, differences between DHCPv4 and DHCPv6.
[SF1375](https://isc.lightning.force.com/lightning/r/Case/5007V00002YkWE4QAN/view)kea2.5.4Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3108ALLOC_ENGINE_V4_ALLOC_ERROR message update2023-12-18T19:11:47ZPeter DaviesALLOC_ENGINE_V4_ALLOC_ERROR message updateALLOC_ENGINE_V4_ALLOC_ERROR:
A suggestion from a Kea user to update the ALLOC_ENGINE_V4_ALLOC_ERROR messages
"with multiple records were found in the database where only one was expected ..."
It may be helpful for new users...ALLOC_ENGINE_V4_ALLOC_ERROR:
A suggestion from a Kea user to update the ALLOC_ENGINE_V4_ALLOC_ERROR messages
"with multiple records were found in the database where only one was expected ..."
It may be helpful for new users to mention the "ip-reservations-unique" setting.
[kea-users](https://lists.isc.org/pipermail/kea-users/2023-October/004332.html)kea2.5.5Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3107ping-check-hook implement ST mode in PingCheckMgr2023-12-13T15:44:38ZThomas Markwalderping-check-hook implement ST mode in PingCheckMgrExtend PingCheckMgr, created in #3083, to support ST mode. The basic steps are:
1. PingCheckMgr::start()
- Skip creating the thread-pool
- Create an WatchSocket and pass it into PingChannel::open(). PingChannel::asyncSend() would ...Extend PingCheckMgr, created in #3083, to support ST mode. The basic steps are:
1. PingCheckMgr::start()
- Skip creating the thread-pool
- Create an WatchSocket and pass it into PingChannel::open(). PingChannel::asyncSend() would invoke WatchSocket::markReady() and socketWriteCallback() would invoke WatchSocket::clearReady()
- After the PingChannel is created, manager would crate an external socket, via IfaceMgr::addExternalSocket(), for the channel's socket.
2. PingCheckMgr::stop() would need to remove the sockets added abovekea2.5.5Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3106Ground work in the HA Service and Network State to support the hub-and-spoke ...2023-12-06T15:32:09ZMarcin SiodelskiGround work in the HA Service and Network State to support the hub-and-spoke modelThis issue extends the `HAService`, `HAImpl`, `HAConfig` and `NetworkState` to allow co-existence of multiple HA relationships in a single Kea server. It doesn't introduce any logic for the hub-and-spoke use case. It is just a ground wor...This issue extends the `HAService`, `HAImpl`, `HAConfig` and `NetworkState` to allow co-existence of multiple HA relationships in a single Kea server. It doesn't introduce any logic for the hub-and-spoke use case. It is just a ground work to eliminate the code that assumes existence of a single relationship.
See the [design](https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/hub-and-spoke-ha-mode#ground-work) for details.kea2.5.4Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3105RADIUS reply message2023-10-31T19:52:48ZFrancis DupontRADIUS reply messageThe RADIUS protocol defines a Reply-Message (18) attribute which carries human readable text in responses from a server. The freeRADIUS client library collects them but the old RADIUS hook does nothing about these attributes. I propose t...The RADIUS protocol defines a Reply-Message (18) attribute which carries human readable text in responses from a server. The freeRADIUS client library collects them but the old RADIUS hook does nothing about these attributes. I propose to fix that i.e. to log them at the INFO level.kea2.5.4Francis DupontFrancis Dupont