ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2023-09-14T14:23:48Zhttps://gitlab.isc.org/isc-projects/keama/-/issues/8keama build fails on illumos because of incorrect headers2023-09-14T14:23:48ZGhost Userkeama build fails on illumos because of incorrect headerskeama build fails with
```
keama.c: In function 'main':
keama.c:127:33: error: 'errno' undeclared (first use in this function)
"input: %s", strerror(errno));
^~~~~
```
on OpenIndiana, because ...keama build fails with
```
keama.c: In function 'main':
keama.c:127:33: error: 'errno' undeclared (first use in this function)
"input: %s", strerror(errno));
^~~~~
```
on OpenIndiana, because sys/errno.h doesn't define errno.
The following patch helps.
[004-errno.patch](/uploads/5df1a6ea904a544f2444cac4d6895fa6/004-errno.patch)4.5.0https://gitlab.isc.org/isc-projects/keama/-/issues/6Keama doesn't build on Free BSD 12.12024-02-08T13:50:37ZPeter DaviesKeama doesn't build on Free BSD 12.1Keama doesn't build on Free BSD 12.1
./configure
make
...
cd keama
make
cc -DHAVE_CONFIG_H -I. -I../includes -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/tmp/dhcp-4.4.2/bind/include -MT keama.o -MD -MP -MF .deps/k...Keama doesn't build on Free BSD 12.1
./configure
make
...
cd keama
make
cc -DHAVE_CONFIG_H -I. -I../includes -g -O2 -Wall -Werror -fno-strict-aliasing -I../includes -I/tmp/dhcp-4.4.2/bind/include -MT keama.o -MD -MP -MF .deps/keama.Tpo -c -o keama.o keama.c
keama.c:75:19: error: use of undeclared identifier 'AF_INET'
local_family = AF_INET;
^
keama.c:77:19: error: use of undeclared identifier 'AF_INET6'
local_family = AF_INET6;
^
See [RT #17269](https://support.isc.org/Ticket/Display.html?id=17269)4.5.0Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/keama/-/issues/1Isolate keama from DHCP sources2023-09-14T14:23:48ZTomek MrugalskiIsolate keama from DHCP sourcesThis repository started as a clone of ISC DHCP, with client, server, relay, omapi etc.
The goal of this ticket is to do the initial:
- removal of client, relay, server code
- enable keama to be built by default
- update some basic docum...This repository started as a clone of ISC DHCP, with client, server, relay, omapi etc.
The goal of this ticket is to do the initial:
- removal of client, relay, server code
- enable keama to be built by default
- update some basic documentation
- update the project to identify as keama4.5.0Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/3091Bump up Kea version in configure.ac to 2.5.3-git2023-09-26T18:48:07ZMarcin GodzinaBump up Kea version in configure.ac to 2.5.3-gitkea2.5.2Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/3087Changes for Kea 2.5.2 release2023-09-25T10:54:41ZMarcin GodzinaChanges for Kea 2.5.2 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.2https://gitlab.isc.org/isc-projects/kea/-/issues/3085Bump up library versions for 2.5.22023-09-22T17:47:19ZRazvan BecheriuBump up library versions for 2.5.2kea2.5.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/30762.5.2 release checklist2023-10-11T15:43:58ZMarcin Godzina2.5.2 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. [x] 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. [x] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [x] 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. [ ] 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.
- [ ] ***(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)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on website if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [ ] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).kea2.5.2https://gitlab.isc.org/isc-projects/kea/-/issues/3069Finish renaming radius to old_radius2023-09-21T05:27:57ZAndrei Pavelandrei@isc.orgFinish renaming radius to old_radius`radius` was renamed to `old_radius` in premium, as part of #3043 which opened the way for the RADIUS client development.
But right now, `old_radius` is just dead code. It does not get built.
We still need to have it working like befor...`radius` was renamed to `old_radius` in premium, as part of #3043 which opened the way for the RADIUS client development.
But right now, `old_radius` is just dead code. It does not get built.
We still need to have it working like before until the new radius library is done.
This issue is about bringing old_radius back to a working state, which should just mean putting some autoconf code back and renaming some library files.kea2.5.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3067ping-check-core-task-3 Update devel docs with the info about new hook point l...2023-09-19T15:57:48ZPiotrek Zadrogaping-check-core-task-3 Update devel docs with the info about new hook point lease4_offer1. [x] Update devel docs with the info about new hook point.1. [x] Update devel docs with the info about new hook point.kea2.5.2Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3063ping-check-core-task-2 Changes to lib/dhcpsrv2023-09-18T17:54:06ZPiotrek Zadrogaping-check-core-task-2 Changes to lib/dhcpsrvThe allocation engine will need to be modified to set `Context4::new_lease_` in `AllocEngine::allocateLease4()` on OFFERs.The allocation engine will need to be modified to set `Context4::new_lease_` in `AllocEngine::allocateLease4()` on OFFERs.kea2.5.2Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3060systemd in RHEL/CentOS 7 lacks the same Directory directives that Debian 9 lacks2023-09-22T12:57:06ZKenneth Portersystemd in RHEL/CentOS 7 lacks the same Directory directives that Debian 9 lacksI tried installing kea 2.4 on CentOS 7 using yum and journalctl output reports that several "Directory" directives in the service unit files are not known to its old version of systemd. It looks like the kea source already has build code...I tried installing kea 2.4 on CentOS 7 using yum and journalctl output reports that several "Directory" directives in the service unit files are not known to its old version of systemd. It looks like the kea source already has build code to deal with this for Debian 9 in hammer.py. (Search for LogsDirectory for the loop where these are removed.) More info on the directives:
https://serverfault.com/questions/1033129/centos-7-systemd-exec-configuration-alternatives-to-logsdirectory-cachedirect
I've reverted to kea 2.2 where these new directives are absent.
Here's the code in hammer.py that addresses this for Debian 9:
```
# debian 9 does not support some fields in systemd unit files so they need to be commented out
if system == 'debian' and revision == '9':
for f in services_list:
for k in ['RuntimeDirectory', 'RuntimeDirectoryPreserve', 'LogsDirectory', 'LogsDirectoryMode', 'StateDirectory', 'ConfigurationDirectory']:
cmd = "sed -i -E 's/^(%s=.*)/#\\1/' %s" % (k, f)
execute(cmd, cwd='kea-src/kea-%s/debian' % pkg_version, check_times=check_times, dry_run=dry_run)
```kea2.5.2Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3054ping-check-hook-task-3 Implement PingContext and PingContextStore2023-09-20T11:34:07ZThomas Markwalderping-check-hook-task-3 Implement PingContext and PingContextStoreImplement PingContext and PingContextStore classes per Ping Check design
https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/ping-check
When complete: PingContextStore should provide CRUD operations for PingContexts, as well as req...Implement PingContext and PingContextStore classes per Ping Check design
https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/ping-check
When complete: PingContextStore should provide CRUD operations for PingContexts, as well as requisite finder methods. This implies that PingContext is fully functional (ctor, accessors, state etc...)kea2.5.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3053ping-check-hook-task-2 Implement ICMPEndpoint and ICMPSocket2023-09-15T14:39:30ZThomas Markwalderping-check-hook-task-2 Implement ICMPEndpoint and ICMPSocketImplement ICMPEndpoint and ICMPSocket classes per Ping Check design
https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/ping-check
When complete, should be able to send and receive ICMP messages.Implement ICMPEndpoint and ICMPSocket classes per Ping Check design
https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/ping-check
When complete, should be able to send and receive ICMP messages.kea2.5.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3048Matching of case for ASCII content2023-09-22T13:36:44ZDarren AnkneyMatching of case for ASCII contentSometimes administrators will want to match some arbitrary content for reservations or classes. For example, they may want to match on remote id. There may be some differences between equipment with how this content is added to remote ...Sometimes administrators will want to match some arbitrary content for reservations or classes. For example, they may want to match on remote id. There may be some differences between equipment with how this content is added to remote id.
- Device 1 remote ID content: `some ascii string` Hex: `736F6D6520617363696920737472696E67`
- Device 2 remote ID content: `SOME ASCII STRING` Hex: `534F4D4520415343494920535452494E47`
Currently, Kea is only able to match these based on the hexadecimal content of the remote ID field. At no time is Kea able to decode these as it has no way to know how it was encoded. Therefore the administrator cannot predict what the match will be in advance. In ISC DHCP, one might match like this: `ucase(binary-to-ascii(10,8,option agent.remote-id)) = "SOME ASCII STRING"` where the string would first be converted to ASCII and then converted to all uppercase letters so that strings would be, in a sense, case insensitive.
Suggest to add some equivalent of these functions to Kea so that matches could be done in a similar way.
Relevant ISC DHCP functions:
**binary-to-ascii (numeric-expr1, numeric-expr2, data-expr1, data-expr2)**
Converts the result of evaluating data-expr2 into a text string containing one number for each element of the result of evaluating data-expr2. Each number is separated from the other by the result of evaluating data-expr1. The result of evaluating numeric-expr1 specifies the base (2 through 16) into which the numbers should be converted. The result of evaluating numeric-expr2 specifies the width in bits of each number, which may be either 8, 16 or 32.
As an example of the preceding three types of expressions, to produce the name of a PTR record for the IP address being assigned to a client, one could write the following expression:
concat (binary-to-ascii (10, 8, ".",
reverse (1, leased-address)),
".in-addr.arpa.");
**lcase (data-expr)**
The lcase function returns the result of evaluating data-expr converted to lower case. If data-expr evaluates to null, then the result is also null.
**ucase (data-expr)**
The ucase function returns the result of evaluating data-expr converted to upper case. If data-expr evaluates to null, then the result is also null.
[SF1172](https://isc.lightning.force.com/lightning/r/Case/5007V00002VW9pgQAD/view)kea2.5.2Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/3043Support for RADIUS attributes2023-09-15T14:47:05ZAndrei Pavelandrei@isc.orgSupport for RADIUS attributesPart of the RADIUS redesign.
* [ ] add support for the attributes that are explicitly/in-a-hardcoded-manner supported in Kea at present. These include, but may not be limited to:
- `PW_USER_NAME`
- `PW_CALLING_STATION_ID`
- `PW_FR...Part of the RADIUS redesign.
* [ ] add support for the attributes that are explicitly/in-a-hardcoded-manner supported in Kea at present. These include, but may not be limited to:
- `PW_USER_NAME`
- `PW_CALLING_STATION_ID`
- `PW_FRAMED_IP_ADDRESS`
- `PW_ACCT_SESSION_ID`
- `PW_ACCT_STATUS_TYPE`
- `PW_CLASS`
- `PW_FRAMED_IPV6_ADDRESS`
- `PW_FRAMED_IPV6_PREFIX`
- `PW_DELEGATED_IPV6_PREFIX`
- `PW_FRAMED_POOL`
- `PW_SERVICE_TYPE`
- `PW_NAS_PORT`
* [ ] compile in old library dictionaries
* [ ] unit testskea2.5.2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/3038ping-check-core-task-1 Implement lease4-offer hook point in kea-dhcp42023-11-18T09:53:34ZPiotrek Zadrogaping-check-core-task-1 Implement lease4-offer hook point in kea-dhcp41. [x] `Dhcp4Srv::processDhcp4Query()` needs to be modified to call `lease4-offer` when processing a DISCOVER, or `leases4-committed` otherwise. This includes preparing a different argument list for the callout for `lease4-offer` vs `lea...1. [x] `Dhcp4Srv::processDhcp4Query()` needs to be modified to call `lease4-offer` when processing a DISCOVER, or `leases4-committed` otherwise. This includes preparing a different argument list for the callout for `lease4-offer` vs `leases4-committed`.
1. [x] `lease4-offer` callout needs two arguments that `leases4-committed` does not: `offer_lifetime` and `old_lease`.
1. [x] UTs should be written for the new hook point.kea2.5.2Piotrek ZadrogaPiotrek Zadrogahttps://gitlab.isc.org/isc-projects/kea/-/issues/3034version bump in configure.ac2023-08-30T12:05:46ZWlodzimierz Wencelversion bump in configure.ackea2.5.2Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/3031Fedora 38 compilation error2023-11-20T10:15:51ZMarcin GodzinaFedora 38 compilation errorCompilation error encountered on Fedora 38 in Kea 2.5.1 rc1
Compilation error
```
CXX run_unittests-rdata_unittest.o
rdata_unittest.cc: In static member function ‘static std::string {anonymous}::Rdata_Unknown_Test::getLongestRdat...Compilation error encountered on Fedora 38 in Kea 2.5.1 rc1
Compilation error
```
CXX run_unittests-rdata_unittest.o
rdata_unittest.cc: In static member function ‘static std::string {anonymous}::Rdata_Unknown_Test::getLongestRdataTxt()’:
rdata_unittest.cc:257:16: error: ‘setw’ was not declared in this scope
257 | oss << setw(2) << (i & 0xff);
| ^~~~
rdata_unittest.cc:29:1: note: ‘std::setw’ is defined in header ‘<iomanip>’; did you forget to ‘#include <iomanip>’?
28 | #include <boost/lexical_cast.hpp>
+++ |+#include <iomanip>
29 |
```
Warning:
```
In file included from stamped_value_unittest.cc:12:
In function ‘testing::AssertionResult testing::internal::CmpHelperEQ(const char*, const char*, const T1&, const T2&) [with T1 = int; T2 = long int]’,
inlined from ‘static testing::AssertionResult testing::internal::EqHelper::Compare(const char*, const char*, const T1&, const T2&) [with T1 = int; T2 = long int; typename std::enable_if<((! std::is_integral<_Tp>::value) || (! std::is_pointer<_T2>::value))>::type* <anonymous> = 0]’ at /home/mgodzina/googletest/googletest/include/gtest/gtest.h:1397:64,
inlined from ‘virtual void {anonymous}::StampedValueTest_createFromInteger_Test::TestBody()’ at stamped_value_unittest.cc:68:5:
/home/mgodzina/googletest/googletest/include/gtest/gtest.h:1378:11: warning: ‘signed_integer’ may be used uninitialized [-Wmaybe-uninitialized]
1378 | if (lhs == rhs) {
| ~~~~^~~~~~
stamped_value_unittest.cc: In member function ‘virtual void {anonymous}::StampedValueTest_createFromInteger_Test::TestBody()’:
stamped_value_unittest.cc:66:13: note: ‘signed_integer’ declared here
66 | int64_t signed_integer;
| ^~~~~~~~~~~~~~
```
Error and warning discovered by Razvan and confirmed by me.
[config.report](/uploads/9d7b2e9b48863ea788d976c7a754b332/config.report)kea2.5.2Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/kea/-/issues/3012ping-check-hook-task-1 Implement skeleton of new hook.2023-09-26T07:46:06ZThomas Markwalderping-check-hook-task-1 Implement skeleton of new hook.Create the necessary premium sub directories and basic infrastructure for new ping-check hook library. The skeleton hook should load and unload and provide NOP C callout functions.Create the necessary premium sub directories and basic infrastructure for new ping-check hook library. The skeleton hook should load and unload and provide NOP C callout functions.kea2.5.2Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3011Log message format section (19.1.2) in ARM could be more clear2023-09-14T17:16:35ZDarren AnkneyLog message format section (19.1.2) in ARM could be more clearI find this section: [19.1.2. Logging Message Format](https://kea.readthedocs.io/en/kea-2.4.0/arm/logging.html#id4) of the ARM a little confusing and so wanted to detail below what I find confusing about it.
**Potential Issue 1:** https...I find this section: [19.1.2. Logging Message Format](https://kea.readthedocs.io/en/kea-2.4.0/arm/logging.html#id4) of the ARM a little confusing and so wanted to detail below what I find confusing about it.
**Potential Issue 1:** https://kea.readthedocs.io/en/kea-2.4.0/arm/logging.html#id4 - The wording of the sentence preceeding this table and the title of the table imply that it is a complete list of all possible format options. It appears to be only a list of date/time format options possible inside of the `%D{}` or `%d{}` block. The sentence following seems to imply that this is indeed the content of the table as it refers to `strftime(3)` man page.
**Potential Issue 2:** Are there other non-time format strings besides `%D`, `%-5p`, `%c`, `%i`, `%t`, and `%m`? It isn't clear if this is an exhaustive list.
**Potential Issue 3:** The examples `"%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i.%t] %m\n";` and `"%-5p [%c.%t] %m\n";` have semicolons at the end of the strings. These semicolons cause syntax errors if used literally in Kea configuration. Perhaps a better way might be showing the way they would actually look in `output-options` (e.g., `"pattern": "%D{%Y-%m-%d %H:%M:%S.%q} %-5p [%c/%i.%t] %m\n"`)kea2.5.2Darren AnkneyDarren Ankney