ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-10-03T11:59:42Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/974Stork not consider bind chroot path in all cases2023-10-03T11:59:42ZJuliano GuidiniStork not consider bind chroot path in all cases---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms?
Maybe, changing all Bind setup, stork will find th...---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms?
Maybe, changing all Bind setup, stork will find the conf files.
- Stork is in very early stages of development. If your request is not simple, it
may be a while until anyone does anything with your request. Are you ok with that?
OK.
**Is your feature request related to a problem? Please describe.**
Yes. My Bind setup, and a wich a great number of Binds running, are on chroot environment. All Bind configuration is relactive to chroot path and in some them (my case) the configuration files are inside chroot.
Sample:
```
stork agent version: 1.9.0.230131111245
OS: Ubuntu 18.04.6 LTS - amd_64
chroot path: /var/lib/named
diretory absolute path: /var/lib/named/databases
bind command line: /var/lib/named/sbin/named -f -u bind -t /var/lib/named
```
Starting stork, in log it shows:
```
Feb 7 15:33:10 teste-compilando-bind-UB18 stork-agent[9802]: time="2023-02-07 15:33:10" level="warning" msg="cannot parse BIND 9 config file /etc/named.conf: exit status 1; /etc/named.conf.options:5: change directory to '/databases' failed: file not found\n\n/etc/named.conf.options:5: parsing failed: file not found\n" file=" bind9.go:405 "
```
Examining backend/agent/bind9.go
(commit 639fbb707313e7e7c9ac99d15c413fca1b6860f7 (HEAD -> master, tag: v1.9.0, origin/master, origin/HEAD))
```go
403 out, err := executor.Output(namedCheckconfPath, "-p", bind9ConfPath)
```
If I understand the code (sorry, programing is not my best :-) ) this function result on:
```bash
named-checkconf -p /etc/named.conf
/etc/named.conf.options:5: change directory to '/databases' failed: file not found
/etc/named.conf.options:5: parsing failed: file not found
```
Line 5 of /etc/named.conf.options is:
```
2 options {
3
4
5 directory "/databases";
```
This directory is relative to chroot path, but chroot path is not indicated to named-checonf -t option.
My Bind is compiled, so i think this is some part of the trouble.
If i use Bind from distro ( apt-get install bind9 ), this error not occours, see:
```
stork agent version: 1.9.0.230131111245
OS: Ubuntu 18.04.6 LTS - amd_64
chroot path: /var/bind9/chroot
diretory absolute path: /var/cache/bind
bind command line: /usr/sbin/named -f -u bind -t /var/bind9/chroot
```
/etc/bind/named.conf.options
```
1 options {
2
3 directory "/var/cache/bind";
```
This directory exists outside chroot directory, this way named-checkconf -p works whitout -t, of course, and all conf files are in /etc/bind.
I would like stork consider the chroot directory, automatically or by configuration the file agent.env, and if possible, configurations parameters to indicate bind named.conf.
**Describe alternatives you've considered**
To indicate Bind conf files a link was created from chroot/etc to /etc/bind.
But no solution to use chroot unless change all Bind setup on all my servers.
Thanks.1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/958Create a UI form for updating a subnet2023-11-07T11:29:01ZMarcin SiodelskiCreate a UI form for updating a subnetWhen user clicks `Edit Subnet` button a new form should be opened where user can create new subnet and specify all required DHCP parameters, pools, options, etc. It depends on #956 and #957.When user clicks `Edit Subnet` button a new form should be opened where user can create new subnet and specify all required DHCP parameters, pools, options, etc. It depends on #956 and #957.1.13Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/957REST API calls to update a subnet2023-11-07T11:29:01ZMarcin SiodelskiREST API calls to update a subnetThere are several REST API calls to update a subnet (similar to the calls we have for the host reservations). Specifically, we need: `createSubnetUpdate`, `commitSubnetUpdate`. Internally they will make calls to the config manager's func...There are several REST API calls to update a subnet (similar to the calls we have for the host reservations). Specifically, we need: `createSubnetUpdate`, `commitSubnetUpdate`. Internally they will make calls to the config manager's functions: `BeginSubnetUpdate`, `ApplySubnetUpdate` and `Commit`.1.13Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/897permission denied for schema public on stork-tool db-init2023-09-27T15:42:54ZAndrei Pavelandrei@isc.orgpermission denied for schema public on stork-tool db-init`stork-tool db-create` works, but the `db-init` command that follows, fails for me:
```sh
$ stork-tool db-init
INFO[2022-11-09 18:20:24] connection.go:75 Checking connection to database
FATA[2022-11-09 18:20:24] mai...`stork-tool db-create` works, but the `db-init` command that follows, fails for me:
```sh
$ stork-tool db-init
INFO[2022-11-09 18:20:24] connection.go:75 Checking connection to database
FATA[2022-11-09 18:20:24] main.go:218 problem migrating database: ERROR #42501 permission denied for schema public
EXIT 1
```
I'm able to work around it with the following sequence:
```sh
$ stork-tool db-create
$ sudo -u postgres psql -d stork -c 'GRANT ALL PRIVILEGES ON SCHEMA public TO stork;'
$ stork-tool db-init
```
I'm using a dockerized PostgreSQL that comes by default with the following authentication setup. I don't know if it's relevant.
```sh
# TYPE DATABASE USER ADDRESS METHOD
# "local" is for Unix domain socket connections only
local all all trust
# IPv4 local connections:
host all all 127.0.0.1/32 trust
# IPv6 local connections:
host all all ::1/128 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local replication all trust
host replication all 127.0.0.1/32 trust
host replication all ::1/128 trust
```
Suggesting that the `GRANT ALL PRIVILEGES` command is added to the existing set of commands that are run with `db-create`.1.13https://gitlab.isc.org/isc-projects/stork/-/issues/893ARM support2023-09-15T12:56:44ZSlawek FigielARM supportSome of our developers use MacBook M1 (ARM architecture). We should support this platform for development.Some of our developers use MacBook M1 (ARM architecture). We should support this platform for development.1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/846Prepare Docker base image for Alpine-related CI tasks2023-10-09T13:48:30ZSlawek FigielPrepare Docker base image for Alpine-related CI tasksCurrently, we are installing all dependencies on each pipeline run. We should prepare a base image and upload it to our registry to limit transferred data and decrease the external dependency providers' overhead.Currently, we are installing all dependencies on each pipeline run. We should prepare a base image and upload it to our registry to limit transferred data and decrease the external dependency providers' overhead.1.13https://gitlab.isc.org/isc-projects/stork/-/issues/809Update the NPM version2023-10-09T13:49:59ZSlawek FigielUpdate the NPM versionThe NPM Registry works wrong (slow and unstable transfer) with out-of-date NPM versions.The NPM Registry works wrong (slow and unstable transfer) with out-of-date NPM versions.1.13https://gitlab.isc.org/isc-projects/stork/-/issues/689Update Ubuntu version in Docker demo2023-09-27T11:58:18ZMarcin SiodelskiUpdate Ubuntu version in Docker demoCurrently our docker demo runs on Ubuntu 18. I'd suggest moving to Ubuntu 20, suspecting that it will also shorten the time required to run the demo because less system updates would be fetched during installation.Currently our docker demo runs on Ubuntu 18. I'd suggest moving to Ubuntu 20, suspecting that it will also shorten the time required to run the demo because less system updates would be fetched during installation.1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/638LDAP support2023-10-05T11:36:45ZPeter DaviesLDAP supportIs is a request for LDAP/Active Directory support in Stork
The goal is to be able to use LDAP for authenticating Stork users for now. However, in the future the scope of LDAP support will likely be expanded to cover other functionalitie...Is is a request for LDAP/Active Directory support in Stork
The goal is to be able to use LDAP for authenticating Stork users for now. However, in the future the scope of LDAP support will likely be expanded to cover other functionalities.
[RT #19920](https://support.isc.org/Ticket/Display.html?id=19920)1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/472ARM build?2023-09-26T11:21:43Zid prismARM build?---
name: Cloudsmith packaging enhancement
about: Diversify architecture support
---
I was attempting to install isc products via apt. Bind and Kea exist in the ubuntu/debian arm repos, but stork does not.
**Proposed solution**
Current...---
name: Cloudsmith packaging enhancement
about: Diversify architecture support
---
I was attempting to install isc products via apt. Bind and Kea exist in the ubuntu/debian arm repos, but stork does not.
**Proposed solution**
Currently cloudsmith packages are only for x86_64 systems. Can cloudsmith be used to build an ARM-based .deb/.rpm for release?1.13Slawek FigielSlawek Figielhttps://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/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/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/3101hardcode ICMP header len2023-10-11T11:49:03ZPiotrek Zadrogahardcode ICMP header len`struct icmphdr` is different for BSD and GNU libc:
BSD code:
```c++
/*
* Structure of an icmp header.
*/
struct icmphdr {
u_char icmp_type; /* type of message, see below */
u_char icmp_code; ...`struct icmphdr` is different for BSD and GNU libc:
BSD code:
```c++
/*
* Structure of an icmp header.
*/
struct icmphdr {
u_char icmp_type; /* type of message, see below */
u_char icmp_code; /* type sub code */
u_short icmp_cksum; /* ones complement cksum of struct */
};
```
GNU code:
```c++
struct icmphdr
{
uint8_t type; /* message type */
uint8_t code; /* type sub-code */
uint16_t checksum;
union
{
struct
{
uint16_t id;
uint16_t sequence;
} echo; /* echo datagram */
uint32_t gateway; /* gateway address */
struct
{
uint16_t __glibc_reserved;
uint16_t mtu;
} frag; /* path mtu discovery */
} un;
};
```
Because of that calculations of ICMP message header len vary on different systems, and also some UTs related to ping-check hook fail on FreeBSD.
ICMP header len could be defined inside of `ICMPMsg` class.kea2.5.3Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3099compilation error on FreeBSD2023-10-05T17:34:58ZPiotrek Zadrogacompilation error on FreeBSDThere is compilation error on FreeBSD distros 12 and 13 detected.
This is related to #3055 .
This issue will be fixed in premium MR only.There is compilation error on FreeBSD distros 12 and 13 detected.
This is related to #3055 .
This issue will be fixed in premium MR only.kea2.5.3Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3095DHCPv4 option 21 policy-filter example may be misleading2023-10-20T13:42:39ZPiotrek ZadrogaDHCPv4 option 21 policy-filter example may be misleadingExample of that Option that is currently in the source code (`all-options.json`) may be misleading.
```
/*
Code Len Address 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+--...Example of that Option that is currently in the source code (`all-options.json`) may be misleading.
```
/*
Code Len Address 1 Mask 1
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 21 | n | a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Address 2 Mask 2
+-----+-----+-----+-----+-----+-----+-----+-----+---
| a1 | a2 | a3 | a4 | m1 | m2 | m3 | m4 | ...
+-----+-----+-----+-----+-----+-----+-----+-----+---
*/
// Type: array of {IPv4 address}
{
"code": 21,
"data": "192.0.2.21, 192.0.2.22",
"name": "policy-filter"
},
```
`data` should be rather pairs of (IPv4, mask), e.g.
```
"data": "192.0.2.0, 255.255.255.0",
```
or
```
"data": "192.0.2.0, 255.255.255.0, 10.2.0.0, 255.255.0.0",
```kea2.5.3Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3093Missing error message from OpenSSL 3.1.32023-09-27T07:18:10ZFrancis DupontMissing error message from OpenSSL 3.1.3OpenSSL 3.1.3 release the 2023/09/19 changed one of the error messages checked in TLS unit tests.
Patch attached.[openssl313.diff](/uploads/ad85a5778be88145f6159130bf597fa2/openssl313.diff)OpenSSL 3.1.3 release the 2023/09/19 changed one of the error messages checked in TLS unit tests.
Patch attached.[openssl313.diff](/uploads/ad85a5778be88145f6159130bf597fa2/openssl313.diff)kea2.5.3Francis DupontFrancis Dupont