ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2020-09-28T10:31:43Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/1437distcheck is failing2020-09-28T10:31:43ZMichal Nowikowskidistcheck is failingFailed builds on jenkins:
https://jenkins.isc.org/job/kea-dev/job/distcheck/
from # 10 to # 13.
The failures can look differently:
1.
```
[----------] Global test environment tear-down
[==========] 651 tests from 46 test cases ran. (6...Failed builds on jenkins:
https://jenkins.isc.org/job/kea-dev/job/distcheck/
from # 10 to # 13.
The failures can look differently:
1.
```
[----------] Global test environment tear-down
[==========] 651 tests from 46 test cases ran. (6828 ms total)
[ PASSED ] 642 tests.
[ FAILED ] 9 tests, listed below:
[ FAILED ] IfaceMgrTest.receiveTimeout6
[ FAILED ] IfaceMgrTest.sockets6
[ FAILED ] IfaceMgrTest.socketsFromIface
[ FAILED ] IfaceMgrTest.socketsFromAddress
[ FAILED ] IfaceMgrTest.socketsFromRemoteAddress
[ FAILED ] IfaceMgrTest.sendReceive6
[ FAILED ] PktFilterInet6Test.openSocket
[ FAILED ] PktFilterInet6Test.send
[ FAILED ] PktFilterInet6Test.receive
9 FAILED TESTS
YOU HAVE 7 DISABLED TESTS
FAIL: libdhcp++_unittests
======================================
1 of 1 test failed
Please report to kea-dev@lists.isc.org
======================================
make[7]: *** [Makefile:1738: check-TESTS] Błąd 1
make[7]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp/tests'
make[6]: *** [Makefile:1889: check-am] Błąd 2
make[6]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp/tests'
make[5]: *** [Makefile:1645: check-recursive] Błąd 1
make[5]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp/tests'
make[4]: *** [Makefile:1171: check-recursive] Błąd 1
make[4]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib/dhcp'
make[3]: *** [Makefile:458: check-recursive] Błąd 1
make[3]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src/lib'
make[2]: *** [Makefile:451: check-recursive] Błąd 1
make[2]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub/src'
make[1]: *** [Makefile:622: check-recursive] Błąd 1
make[1]: Opuszczenie katalogu '/home/godfryd/isc/repos/kea/kea-1.9.0-git/_build/sub'
make: *** [Makefile:836: distcheck] Błąd 1
```
or 2.
```
22:14:46.082 [----------] Global test environment tear-down
22:14:46.082 [==========] 650 tests from 25 test cases ran. (14302 ms total)
22:14:46.082 [ PASSED ] 649 tests.
22:14:46.082 [ FAILED ] 1 test, listed below:
22:14:46.082 [ FAILED ] CtrlChannelDhcpv4SrvTest.controlChannelStats
22:14:46.082
22:14:46.082 1 FAILED TEST
22:14:46.082 YOU HAVE 2 DISABLED TESTS
22:14:46.082
22:14:46.082 FAIL: dhcp4_unittests
22:14:46.082 ======================================
22:14:46.082 1 of 1 test failed
22:14:46.082 Please report to kea-dev@lists.isc.org
22:14:46.082 ======================================
22:14:46.082 make[6]: *** [Makefile:1307: check-TESTS] Error 1
22:14:46.082 make[6]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
22:14:46.082 make[5]: *** [Makefile:1433: check-am] Error 2
22:14:46.082 make[5]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
22:14:46.082 make[4]: *** [Makefile:714: check-recursive] Error 1
22:14:46.082 make[4]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4'
22:14:46.082 make[3]: *** [Makefile:453: check-recursive] Error 1
22:14:46.082 make[3]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin'
22:14:46.082 make[2]: *** [Makefile:451: check-recursive] Error 1
22:14:46.082 make[2]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src'
22:14:46.082 make[1]: *** [Makefile:622: check-recursive] Error 1
22:14:46.082 make[1]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub'
22:14:46.082 make: *** [Makefile:836: distcheck] Error 1
```
or 3.
```
20:50:12.373 Running command "/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/kea-dhcp4 -t /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json".
20:50:12.373 Syntax check failed with: /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json:1.11-22: got unexpected keyword "interfaces" in Dhcp4 map.
20:50:12.373 PASSED dhcpv4.syntax_check_bad_syntax
20:50:12.373
20:50:12.373
20:50:12.374 START TEST dhcpv4.syntax_check_bad_values
20:50:12.374 Creating Kea configuration file: /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json.
20:50:12.374 Running command "/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/kea-dhcp4 -t /home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json".
20:50:12.374 Error encountered: subnet configuration failed: a pool of type V4, with the following address range: 192.168.0.10-192.168.0.100 does not match the prefix of a subnet: 10.0.0.0/8 to which it is being added (/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests/test_config.json:1:173)
20:50:12.374 PASSED dhcpv4.syntax_check_bad_values
20:50:12.374
20:50:12.374 make[6]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
20:50:12.374 Makefile:1392: recipe for target 'check-am' failed
20:50:12.374 make[5]: *** [check-am] Error 2
20:50:12.374 make[5]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4/tests'
20:50:12.374 Makefile:701: recipe for target 'check-recursive' failed
20:50:12.374 make[4]: *** [check-recursive] Error 1
20:50:12.374 make[4]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin/dhcp4'
20:50:12.374 Makefile:453: recipe for target 'check-recursive' failed
20:50:12.374 make[3]: *** [check-recursive] Error 1
20:50:12.374 make[3]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src/bin'
20:50:12.374 Makefile:451: recipe for target 'check-recursive' failed
20:50:12.374 make[2]: *** [check-recursive] Error 1
20:50:12.374 make[2]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub/src'
20:50:12.374 Makefile:622: recipe for target 'check-recursive' failed
20:50:12.374 make[1]: *** [check-recursive] Error 1
20:50:12.374 make[1]: Leaving directory '/home/jenkins/workspace/kea-dev/distcheck/kea-1.9.0-git/_build/sub'
20:50:12.374 Makefile:828: recipe for target 'distcheck' failed
20:50:12.374 make: *** [distcheck] Error 1
```kea1.9.0https://gitlab.isc.org/isc-projects/kea/-/issues/1436Document DHCPv6 options set by Kea2020-10-23T11:04:48ZTomek MrugalskiDocument DHCPv6 options set by KeaThere's a long list of v6 options that Kea supports, but they're not listed as supported, because they can't be configured explicitly. However, support requested a documentation for similar options in v4 (see #1323) and @tomek added it. ...There's a long list of v6 options that Kea supports, but they're not listed as supported, because they can't be configured explicitly. However, support requested a documentation for similar options in v4 (see #1323) and @tomek added it. We should have a similar list for v6.
It's actually easy to do: checkout old branch (e.g. v1_4_0) and look at doc/guide/dhcp6-srv.xml for comments around line 1344.kea1.9.1https://gitlab.isc.org/isc-projects/kea/-/issues/1435Backport #1431 (remove mutli-threading experimental message)2020-11-27T06:38:00ZTomek MrugalskiBackport #1431 (remove mutli-threading experimental message)We should remove the experimental message from 1.8.x branch.We should remove the experimental message from 1.8.x branch.kea1.8.1Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/1434HA hook with mysql backend not working2020-11-05T16:25:38ZMichal HynekHA hook with mysql backend not workingHello, I Have problem with HA (in my case hot-standby). Server is unable to sync leases.
```
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 100.104.3.2
202...Hello, I Have problem with HA (in my case hot-standby). Server is unable to sync leases.
```
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_GET_ADDR4 obtaining IPv4 lease for address 100.104.3.2
2020-09-25 09:51:32.806 DEBUG [kea-dhcp4.dhcpsrv/34387.140540437956480] DHCPSRV_MYSQL_UPDATE_ADDR4 updating IPv4 lease for address 100.104.3.2
2020-09-25 09:51:32.806 WARN [kea-dhcp4.ha-hooks/34387.140540437956480] HA_LEASE_SYNC_FAILED synchronization failed for lease: { "cltt": 1600979173, "fqdn-fwd": true, "fqdn-rev": true, "hostname": "lt_pohorany_137_eap1", "hw-address": "c4:ad:34:ce:99:64", "ip-address": "100.104.3.2", "state": 0, "subnet-id": 10010400, "valid-lft": 432000 }, reason: unable to update lease for address 100.104.3.2 as it does not exist
```
mysql debug:
```
2020-09-25T07:51:32.806428Z 370 Execute SELECT address, hwaddr, client_id, valid_lifetime, expire, subnet_id, fqdn_fwd, fqdn_rev, hostname, state, user_context FROM lease4 WHERE address = 1684538114
2020-09-25T07:51:32.806540Z 370 Execute UPDATE lease4 SET address = 1684538114, hwaddr = 'ĭ4Ιd', client_id = NULL, valid_lifetime = 432000, expire = '2020-09-29 22:26:13', subnet_id = 10010400, fqdn_fwd = 1, fqdn_rev = 1, hostname = 'lt_pohorany_137_eap1', state = 0, user_context = NULL WHERE address = 1684538114 AND expire = '1970-01-01 01:00:00'
```
you can see it tries to match weird expire value '1970-01-01 01:00:00' but in database is:
```
mysql> SELECT * FROM dhcp.lease4 WHERE address=1684538114;
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
| address | hwaddr | client_id | valid_lifetime | expire | subnet_id | fqdn_fwd | fqdn_rev | hostname | state | user_context |
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
| 1684538114 | ĭ4Ιd | NULL | 432000 | 2020-09-27 10:26:13 | 10010400 | 1 | 1 | lt_pohorany_137_eap1 | 0 | NULL |
+------------+--------+-----------+----------------+---------------------+-----------+----------+----------+----------------------+-------+--------------+
1 row in set (0.00 sec)
```
Time is synchronized on both server. Same timezone selected.
**Expected behavior**
- Lease on remote site will update
**Environment:**
- Kea version: 1.8.0 + libdhcp_lease_cmds + libdhcp_ha
- OS: Debian x64
- Mysql server: 5.7.31 (Percona Server)kea1.9.1Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1433hammer: problem with building centos 8 and passing attempts argument2021-05-04T10:55:36ZMichal Nowikowskihammer: problem with building centos 8 and passing attempts argumentkea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/414Partner down in Kea HA is reported awkwardly2022-11-16T11:54:51ZTomek MrugalskiPartner down in Kea HA is reported awkwardlyHere's what I did:
1. started demo as usual `rake docker_up`
1. added agent-kea-ha1, agent-kea-ha2
1. used traffic generator to stop kea-dhcp4 on agent-kea-ha2
1. After a while this was shown in the dashboard:
![stork-partner-down](/up...Here's what I did:
1. started demo as usual `rake docker_up`
1. added agent-kea-ha1, agent-kea-ha2
1. used traffic generator to stop kea-dhcp4 on agent-kea-ha2
1. After a while this was shown in the dashboard:
![stork-partner-down](/uploads/8c3fa57bbcb46f66136c670cb172648b/stork-partner-down.png)
The problem is "Detected failure w/HA" for agent-kea-ha2. It says "never".
This is not a major problem, more like confusion. The HA state correctly says "partner down", so there's indication. It's just one column contradicts another.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1432hammer: building centos 8 fails due to network issues2021-05-04T10:55:36ZMichal Nowikowskihammer: building centos 8 fails due to network issuessolution: add retries on network operationssolution: add retries on network operationskea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2187Release Checklist for BIND 9.11.24, BIND 9.11.24-S1, BIND 9.16.8, BIND 9.16.8...2020-10-28T16:58:10ZMichał KępieńRelease Checklist for BIND 9.11.24, BIND 9.11.24-S1, BIND 9.16.8, BIND 9.16.8-S1, BIND 9.17.6## Release Schedule
**Code Freeze:** Wednesday, October 7th, 2020
**Tagging Deadline:** Monday, October 12th, 2020
**Public Release:** Wednesday, October 21st, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** ...## Release Schedule
**Code Freeze:** Wednesday, October 7th, 2020
**Tagging Deadline:** Monday, October 12th, 2020
**Public Release:** Wednesday, October 21st, 2020
## Release Checklist
### Before the Code Freeze
- [x] ***(QA)*** Inform Support and Marketing of impending release (and give estimated release dates).
- [x] ***(QA)*** Ensure there are no permanent test failures on any platform.
- [x] ***(QA)*** Check Perflab to ensure there has been no unexplained drop in performance for the versions being released.
- [x] ***(QA)*** Check whether all issues assigned to the release milestone are resolved[^1].
- [x] ***(QA)*** Ensure that there are no outstanding merge requests in the private repository[^1] (Subscription Edition only).
- [x] ***(QA)*** Ensure all merge requests marked for backporting have been indeed backported.
### Before the Tagging Deadline
- [x] ***(QA)*** Look for outstanding documentation issues (e.g. `CHANGES` mistakes) and address them if any are found.
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(Support)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(Marketing)*** Check release notes, ask QA to correct any mistakes found.
- [x] ***(SwEng)*** Update API files for libraries with new version information.
- [x] ***(SwEng)*** Change software version and library versions in `configure.ac` (new major release only).
- [x] ***(SwEng)*** Rebuild `configure` using Autoconf on `docs.isc.org`.
- [x] ***(SwEng)*** Update `CHANGES`.
- [x] ***(SwEng)*** Update `CHANGES.SE` (Subscription Edition only).
- [x] ***(SwEng)*** Update `README.md`.
- [x] ***(SwEng)*** Update `version`.
- [x] ***(SwEng)*** Build documentation on `docs.isc.org`.
- [x] ***(QA)*** Check that all the above steps were performed correctly.
- [x] ***(QA)*** Check that the formatting is correct for text, PDF, and HTML versions of release notes.
- [x] ***(SwEng)*** Tag the releases[^2]. (Tags may only be pushed to the public repository for releases which are *not* security releases.)
- [x] ***(SwEng)*** If this is the first tag for a release (e.g. beta), create a release branch named `release_v9_X_Y` to allow development to continue on the maintenance branch whilst release engineering continues.
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Verify GitLab CI results for the tags created and prepare a QA report for the releases to be published.
- [x] ***(QA)*** Request signatures for the tarballs, providing their location and checksums.
- [x] ***(Signers)*** Validate tarball checksums, sign tarballs, and upload signatures.
- [x] ***(QA)*** Verify tarball signatures and check tarball checksums again.
- [x] ***(Support)*** Pre-publish ASN and/or Subscription Edition tarballs so that packages can be built.
- [x] ***(QA)*** Build and test ASN and/or Subscription Edition packages.
- [x] ***(QA)*** Notify Support that the releases have been prepared.
- [x] ***(Support)*** Send out ASNs (if applicable).
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [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 *bind-announce*.
- [x] ***(Support)*** Write email to *bind-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription Edition.
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public packages (`*.deb`, RPMs).
- [x] ***(QA)*** Inform Marketing of the release.
- [x] ***(QA)*** Update the internal [BIND release dates wiki page](https://wiki.isc.org/bin/view/Main/BindReleaseDates) when public announcement has been made.
- [x] ***(Marketing)*** Post short note to Twitter.
- [x] ***(Marketing)*** Update [Wikipedia entry for BIND](https://en.wikipedia.org/wiki/BIND).
- [x] ***(Marketing)*** Write blog article (if a major release).
- [x] ***(QA)*** Ensure all new tags are annotated and signed.
- [x] ***(SwEng)*** Merge the automatically prepared `prep 9.X.Y` commit which updates `version` and documentation on the release branch into the relevant maintenance branch (`v9_X`).
- [x] ***(SwEng)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** For each maintained branch, update the `BIND_BASELINE_VERSION` variable for the `abi-check` job in `.gitlab-ci.yml` to the latest published BIND version tag for a given branch.
- [x] ***(QA)*** Prepare empty release notes for the next set of releases.
- [x] ***(QA)*** Sanitize all confidential issues assigned to the release milestone and make them public.
- [x] ***(QA)*** Update QA tools used in GitLab CI (e.g. Flake8, PyLint) by modifying the relevant `Dockerfile`.
[^1]: If not, use the time remaining until the tagging deadline to ensure all outstanding issues are either resolved or moved to a different milestone.
[^2]: Preferred command line: `git tag -u <DEVELOPER_KEYID> -a -s -m "BIND 9.X.Y[alphatag]" v9_X_Y[alphatag]`, where `[alphatag]` is an optional string such as `b1`, `rc1`, etc.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Michał KępieńMichał Kępień2020-10-21https://gitlab.isc.org/isc-projects/bind9/-/issues/2186rndc thaw does not correctly process zone changes2022-03-01T09:47:44ZJean-Christophe Manciotrndc thaw does not correctly process zone changes- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL ...- Debian bullseye
- bind9 9.17.5
For instance, when changing $TTL from 604800 (1 week) to 3600 in ```/etc/bind/db.sdxlive.com```, when no RR (other than SOA) has a defined TTL:
```
# rndc freeze sdxlive.com
in /etc/bind/zone-file:
$TTL 604800 --> $TTL 3600
# rndc thaw sdxlive.com
```
Most RRs keep their original TTL:
```
# bind-get-all-resource-records.sh sdxlive.com|grep " 604800 "
zone sdxlive.com/IN: loaded serial 2020092411 (DNSSEC signed)
OK
sdxlive.com. 604800 IN NS ns1.sdxlive.com.
sdxlive.com. 604800 IN RRSIG NS 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. WgQwG0FpqPOPiTZKi65qn01Fe4g3qRkQ0OybOLawl7PlWWKc9XdYMTwf 7AP3c/fKnE0l0BujSSir8HKf4IBVjw==
sdxlive.com. 604800 IN A 176.139.106.168
sdxlive.com. 604800 IN RRSIG A 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. sqeyUzMxZ6JlK+hr6XlLKBJHAZmmVo+ku8oElfuc+6rH8Cr+uKNovK6F Awu76tmcURpR5grYDA0vsC5Cl3B0aQ==
sdxlive.com. 604800 IN MX 1 mail.sdxlive.com.
sdxlive.com. 604800 IN RRSIG MX 13 2 604800 20201011132540 20200911124442 33345 sdxlive.com. xZiYSxYb4gX3e2ZbcC2cmEHT7IKUT/c+wil3ZioViRsW+4RLH/LAJ6Mp eC9+ooWgN7jjArM4EvEQCl6xkuln3Q==
and so on...
```
Same issue if I begin with a ```rndc sync -clean sdxlive.com``` before the zone freeze.
Am I missing something?Not plannedhttps://gitlab.isc.org/isc-projects/kea/-/issues/1431Misleading multithread msg being generated on startup2020-11-04T20:08:17ZPeter DaviesMisleading multithread msg being generated on startupKea 1.8.0
When multithreading is enabled Kea logs the following message:
DHCP4_MULTI_THREADING_WARNING The multi-threading feature is experimental. Don't use in production environment." is multi-threading still a experimental feature?
T...Kea 1.8.0
When multithreading is enabled Kea logs the following message:
DHCP4_MULTI_THREADING_WARNING The multi-threading feature is experimental. Don't use in production environment." is multi-threading still a experimental feature?
This text ought to be amended.kea1.9.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2185nsdname-wait-recurse speed test fails under tsan2020-10-02T08:38:18ZMark Andrewsnsdname-wait-recurse speed test fails under tsan```
7640I:rpzrecurse:checking 'nsdname-wait-recurse no' is faster than 'nsdname-wait-recurse yes' (72)
7641I:rpzrecurse:timing 'nsdname-wait-recurse yes' (default)
7642I:rpzrecurse:elapsed time 0 seconds
7643I:rpzrecurse:timing 'nsdname-...```
7640I:rpzrecurse:checking 'nsdname-wait-recurse no' is faster than 'nsdname-wait-recurse yes' (72)
7641I:rpzrecurse:timing 'nsdname-wait-recurse yes' (default)
7642I:rpzrecurse:elapsed time 0 seconds
7643I:rpzrecurse:timing 'nsdname-wait-recurse no'
7644I:rpzrecurse:elapsed time 0 seconds
7645I:rpzrecurse:failed
```October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Michał KępieńMichał Kępieńhttps://gitlab.isc.org/isc-projects/stork/-/issues/413Stork not pulling lease stats for DHCP42023-03-15T16:52:51ZleecgenesisStork not pulling lease stats for DHCP4---
name: Stork not pulling lease stats for DHCP4
about: Stork colocated on a single kea-dhcp4/6 host running Kea 1.8.0 and Stork 0.11 is not reporting DHCP4 lease statistics.
---
**Describe the bug**
I have a single DHCP VM built with...---
name: Stork not pulling lease stats for DHCP4
about: Stork colocated on a single kea-dhcp4/6 host running Kea 1.8.0 and Stork 0.11 is not reporting DHCP4 lease statistics.
---
**Describe the bug**
I have a single DHCP VM built with Kea version 1.8.0 and Stork 0.11 running on CentOS 7 using prebuilt packages. It's sole purpose is to serve as a DHCP helper for a small regional network. It's currently got 3 IPv4 ranges and 4 IPv6 ranges. The IPv4 ranges contain approximately 1000 IPv4 addresses, and the IPv6 ranges are /64's with prefix delegation handing out /56's from a larger /48 block.
Stork is working fine, on non-standard ports, however the DHCP4 statistics never report. IPv6 statistics, including leases AND prefix-delegations report just fine. Looking at the stdout for the isc-stork-server process, I see the following repeating errors every minute:
statspuller.go:59 missing key total-addreses in LocalSubnet 4 stats
statspuller.go:59 missing key total-addreses in LocalSubnet 5 stats
statspuller.go:59 missing key total-addreses in LocalSubnet 6 stats
Additionally,
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea 1.8.0, Stork 0.11 from package manager in CentOS 7.
2. Configure kea-ctrl-agent, kea-dhcp4, kea-dhcp6, and agent.env, server.env as attached.
3. DHCP Processes work, clients receive addresses and IPv6 Prefix Delegations.
4. Kea functions as expected.
5. Stork does NOT display DHCP4 statistics, DOES display DHCP6 statistics.
**Expected behavior**
I expect stork to display both DHCP4 and DHCP6 statistics for all discovered ranges.
**Environment:**
- Kea version: 1.8.0
- Stork: 0.11.0
- OS: CentOS 7.8
- Kea: Using MySQL backend, but memfile and PSQL backend also compiled in.
- Kea: Using libdhcp_stat_cmds.so and libdhcp_lease_cmds.so on both DHCP4 and DHCP6.
[agent.env](/uploads/d8037ffb05b4d499d03d5114cd04d819/agent.env)
[kea-ctrl-agent.conf](/uploads/f5c4d0cfeca2c8f72c17160f842bc189/kea-ctrl-agent.conf)
[kea-dhcp4.conf](/uploads/56f052faff28a147b0ca5f0dddbcb249/kea-dhcp4.conf)
[kea-dhcp6.conf](/uploads/91598b56fcd21981d1a9da2cf27a7524/kea-dhcp6.conf)
[server.env](/uploads/6e79c09f7caa83e28275697779c5f8da/server.env)0.13Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2184Add RFC8906 to list of RFCs in doc/arm/general.rst2020-09-24T11:55:10ZSuzanne GoldlustAdd RFC8906 to list of RFCs in doc/arm/general.rstNow that RFC8906 has been officially accepted/published, I want to add it to the list of RFCs in the ARM.Now that RFC8906 has been officially accepted/published, I want to add it to the list of RFCs in the ARM.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Suzanne GoldlustSuzanne Goldlusthttps://gitlab.isc.org/isc-projects/kea/-/issues/1430flex_option should be able to generate option data according to a specified p...2020-09-28T12:47:01ZRazvan Becheriuflex_option should be able to generate option data according to a specified patternkea1.9.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1429hammer: add support for building kea on Alpine 3.122021-05-04T10:55:36ZMichal Nowikowskihammer: add support for building kea on Alpine 3.12kea1.9.1Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1428Multiple reservations for the same IP2022-10-25T13:30:06ZTomek MrugalskiMultiple reservations for the same IPA new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to d...A new use case has been brought to our attention. A new device with two NICs is being powered. Each NIC has its own MAC address. However, at any given time only one of those NICs is connected and powered up. Sadly, it's not possible to determine this a'priori which interface will be connected. The intention here to have the same IP address assigned, regardless which NIC will be used.
Under normal circumstances, it is a configuration error to have more than one reservation for the same IP. However, the use case above provides an external constraint that ensures this conflict will never be observed, as there is always only one of the two reservations that will be in use.
The goal of this ticket is to make such operation possible.
While we will start this work in %"kea1.9.0", given the imminent code freeze this Friday, the solution will likely be available in %"kea1.9.1"
[Support ticket #17096](https://support.isc.org/Ticket/Display.html?id=17096)kea1.9.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2183DNS Flag Day 20202022-04-26T13:13:00ZOndřej SurýDNS Flag Day 2020This is a issue to make the necessary changes for DNS Flag Day 2020.This is a issue to make the necessary changes for DNS Flag Day 2020.October 2020 (9.11.24, 9.11.24-S1, 9.16.8, 9.16.8-S1, 9.17.6)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1427bump up library versions and HOOKS_VERSION if needed (kea 1.9.0 release)2020-09-23T12:07:48ZMichal Nowikowskibump up library versions and HOOKS_VERSION if needed (kea 1.9.0 release)if not needed, please close this issueif not needed, please close this issuekea1.9.0https://gitlab.isc.org/isc-projects/kea/-/issues/14261.9.0 release changes2021-05-04T10:55:36ZMichal Nowikowski1.9.0 release changeskea1.9.0Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/2182statschannel python test leave no forensic traces to work out what went wrong.2023-11-02T17:00:03ZMark Andrewsstatschannel python test leave no forensic traces to work out what went wrong.Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Job [#1177271](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1177271) failed for 7a822740e09fd56900383d35889892827dcf94c6:Not planned