ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-03-03T15:08:19Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2066Memory leak in several HA scenarios2022-03-03T15:08:19ZTomek MrugalskiMemory leak in several HA scenarios@wlodek recently implemented extended HA stability tests and the results are worrisome. It seems that there is a memory leak in the following scenarios:
* passive backup memfile v4
* passive backup memfile v6
* hotstandby memfile v6
* h...@wlodek recently implemented extended HA stability tests and the results are worrisome. It seems that there is a memory leak in the following scenarios:
* passive backup memfile v4
* passive backup memfile v6
* hotstandby memfile v6
* hotstandby postgresql v4
* hotstandby postgresql v6
Open the report [report-ha-1.9.11-master.html](/uploads/6413385966bb41e93076f347bc53f561/report-ha-1.9.11-master.html), and go to `HA stability` tab. For example, see "passive backup memfile v4". There are two diagrams 13-A (shows traffic) and 13-B that shows CPU and memory utilization. Note the primary mem usage. The machine has 64G ram. The memory usage grows stadily to over 25% (16GB) when the test concludes after 800 seconds (specified test duration). Other scenarios listed above show similar behaviors. @wlodek will provide more details, including configs, once he gets back to office.
UPDATE: The results above were run on master, after 1.9.11 code freeze and later repeated on 1.9.8 release, which showed similar problems.
![Screenshot_2021-08-31_at_10.56.55](/uploads/56e3157583f1c06f8318ee01fd9efb85/Screenshot_2021-08-31_at_10.56.55.png)kea2.0.0 (formerly 1.9.12)Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/1307congestion recovery for the HA / HTTP service2022-03-03T15:08:20ZFrancis Dupontcongestion recovery for the HA / HTTP serviceIn most High Availability configurations at the end of the packing processing the response is sent back to the client only after the peer updated the lease so to summarize instead to have only packet processing we have a two stage pipeli...In most High Availability configurations at the end of the packing processing the response is sent back to the client only after the peer updated the lease so to summarize instead to have only packet processing we have a two stage pipeline with the packet processing at the first stage and the HA processing at the second stage.
The HA processing is sequential at both sides: the HTTP client reuses the same connection for the same destination and queues new requests waiting for the response, and at the peer side the HTTP request is a command which is executed before the answer is sent back and next command or packet is processed. As the packet processing is usually faster (and for sure faster with a multi-threading service) it is possible to accumulate a backlog of packets in the HA / HTTP part i.e. waiting for the peer lease update before being sent.
Packets waiting to be sent are put in a parking lot so it is trivial to count them. This ticket proposes to consider the HA parking lot as a limited size queue. If the parking lot is full no new packet should be added in it. As usual it is only congestion recovery: as the congestion as an external cause there is no way to avoid or control it: the only possible action is to mitigate congestion consequences so at first to limit backlog size.kea2.0.0 (formerly 1.9.12)Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3186Segmentation fault in BN_num_bits2022-03-04T05:19:00Zvijay reddySegmentation fault in BN_num_bitsBIND Version: 9.18.0
**Build Options:**
```
running on Linux x86_64 5.13.4-1.el7.elrepo.x86_64 #1 SMP Wed Jul 21 23:02:00 EDT 2021
built by make with '--prefix=/opt/vijay' '--enable-dependency-tracking' '--enable-warn-error' '--enable-...BIND Version: 9.18.0
**Build Options:**
```
running on Linux x86_64 5.13.4-1.el7.elrepo.x86_64 #1 SMP Wed Jul 21 23:02:00 EDT 2021
built by make with '--prefix=/opt/vijay' '--enable-dependency-tracking' '--enable-warn-error' '--enable-dnstap' '--enable-singletrace' '--enable-querytrace' '--disable-auto-validation' '--enable-dnsrps-dl' '--enable-dnsrps' '--enable-full-report' '--with-tuning=large' '--enable-fixed-rrset' '--with-libidn2' '--with-lmdb' '--with-json-c' '--with-jemalloc=detect' '--with-maxminddb=yes' '--with-openssl=/opt/vijay' '--enable-largefile' '--enable-threads'
compiled by GCC 4.8.5 20150623 (Red Hat 4.8.5-44)
compiled with OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
linked to OpenSSL version: OpenSSL 1.0.2k-fips 26 Jan 2017
compiled with libuv version: 1.42.0
linked to libuv version: 1.42.0
compiled with libnghttp2 version: 1.33.0
linked to libnghttp2 version: 1.33.0
compiled with json-c version: 0.11
linked to json-c version: 0.11
compiled with zlib version: 1.2.7
linked to zlib version: 1.2.7
linked to maxminddb version: 1.2.0
compiled with protobuf-c version: 1.0.2
linked to protobuf-c version: 1.0.2
threads support is enabled
```
**Stacktrace:**
```
Program terminated with signal 11, Segmentation fault.
#0 0x00007fb603f163d1 in BN_num_bits () from /opt/vijay/lib/libcrypto.so.1.1
Missing separate debuginfos, use: debuginfo-install glibc-2.17-323.el7_9.x86_64 keyutils-libs-1.5.8-3.el7.x86_64 krb5-libs-1.15.1-50.el7.x86_64 libattr-2.4.46-13.el7.x86_64 libcom_err-1.42.9-19.el7.x86_64 libselinux-2.5-15.el7.x86_64 openssl-libs-1.0.2k-21.el7_9.x86_64 pcre-8.32-17.el7.x86_64 sssd-client-1.16.5-10.el7_9.7.x86_64 zlib-1.2.7-19.el7_9.x86_64
(gdb) l
1364 main.c: No such file or directory.
(gdb) bt
#0 0x00007fb603f163d1 in BN_num_bits () from /opt/vijay/lib/libcrypto.so.1.1
#1 0x00007fb6040102ed in RSA_size () from /opt/vijay/lib/libcrypto.so.1.1
#2 0x00007fb6072d2638 in opensslrsa_sign (dctx=0x7fb5fdc631c0, sig=0x7fb6007ee200) at opensslrsa_link.c:167
#3 0x00007fb60727b0d4 in dns_dnssec_sign (name=name@entry=0x7fb5fd4bd1d8, set=set@entry=0x7fb6007ee9b0, key=<optimized out>, inception=inception@entry=0x7fb6007eee78, expire=expire@entry=0x7fb6007eee80, mctx=mctx@entry=0x7fb602334000,
buffer=buffer@entry=0x7fb6007ee970, sigrdata=sigrdata@entry=0x7fb6007ee940) at dnssec.c:349
#4 0x00007fb6073a55ed in add_sigs (db=db@entry=0x7fb5fd49f900, ver=ver@entry=0x7fb5fdbf3e80, name=name@entry=0x7fb5fd4bd1d8, zone=zone@entry=0x7fb5feee3e00, type=48, diff=0x7fb6007ef070, keys=keys@entry=0x7fb6007ef3a0, nkeys=nkeys@entry=2, mctx=0x7fb602334000,
inception=inception@entry=1646219277, expire=expire@entry=1648814876, check_ksk=check_ksk@entry=true, keyset_kskonly=keyset_kskonly@entry=true) at zone.c:7273
#5 0x00007fb6073a5d98 in dns__zone_updatesigs (diff=diff@entry=0x7fb6007ef050, db=db@entry=0x7fb5fd49f900, version=version@entry=0x7fb5fdbf3e80, zone_keys=zone_keys@entry=0x7fb6007ef3a0, nkeys=2, zone=zone@entry=0x7fb5feee3e00, inception=inception@entry=1646219277,
expire=expire@entry=1648814877, keyexpire=keyexpire@entry=1648814876, now=now@entry=1646222877, check_ksk=check_ksk@entry=true, keyset_kskonly=keyset_kskonly@entry=true, zonediff=zonediff@entry=0x7fb6007ef040) at zone.c:8444
#6 0x00007fb6072501cd in sign_apex (zonediff=0x7fb6007ef040, diff=0x7fb6007ef050, now=1646222877, ver=0x7fb5fdbf3e80, db=0x7fb5fd49f900, zone=0x7fb5feee3e00) at zone.c:20587
#7 zone_rekey (zone=zone@entry=0x7fb5feee3e00) at zone.c:21804
#8 0x00007fb6073a7780 in zone_maintenance (zone=<optimized out>) at zone.c:11414
#9 zone_timer (task=<optimized out>, event=0x7fb5fe82e9b0) at zone.c:15103
#10 0x00007fb607685be4 in task_run (task=0x7fb60235f080) at task.c:820
#11 isc_task_run (task=0x7fb60235f080) at task.c:900
#12 0x00007fb60764fb9d in isc__nm_async_task (ev0=ev0@entry=0x7fb5fe82a880, worker=0x7fb602027cb0) at netmgr/netmgr.c:837
#13 0x00007fb607655f08 in process_netievent (worker=worker@entry=0x7fb602027cb0, ievent=0x7fb5fe82a880) at netmgr/netmgr.c:916
#14 0x00007fb6076566c9 in process_queue (worker=worker@entry=0x7fb602027cb0, type=type@entry=NETIEVENT_TASK) at netmgr/netmgr.c:1010
#15 0x00007fb607656e13 in process_all_queues (worker=0x7fb602027cb0) at netmgr/netmgr.c:756
#16 async_cb (handle=0x7fb602028010) at netmgr/netmgr.c:785
#17 0x00007fb605644293 in uv__async_io () from /opt/vijay/lib/libuv.so.1
#18 0x00007fb6056575e3 in uv__io_poll () from /opt/vijay/lib/libuv.so.1
#19 0x00007fb605644ac0 in uv_run () from /opt/vijay/lib/libuv.so.1
#20 0x00007fb607656788 in nm_thread (worker0=0x7fb602027cb0) at netmgr/netmgr.c:691
#21 0x00007fb60768cd85 in isc__trampoline_run (arg=0xbdddf0) at trampoline.c:187
#22 0x00007fb604bd4ea5 in start_thread () from /usr/lib64/libpthread.so.0
#23 0x00007fb6048fd9fd in clone () from /usr/lib64/libc.so.6
```https://gitlab.isc.org/isc-projects/dhcp/-/issues/226docs/trivial: typo in dhcpd.conf.5 manpage2022-03-04T09:34:38ZJan "Yenya" Kasprzakdocs/trivial: typo in dhcpd.conf.5 manpageHello,
there is apparently a typo in dhcpd.conf.5 manpage:
"_The valid lifetime determines at what point **at** lease might be said to have expired_"
Patch attached:
[dhcpd.conf.5.diff](/uploads/fe4251426005e586c2ec3746c9860328/dhcpd...Hello,
there is apparently a typo in dhcpd.conf.5 manpage:
"_The valid lifetime determines at what point **at** lease might be said to have expired_"
Patch attached:
[dhcpd.conf.5.diff](/uploads/fe4251426005e586c2ec3746c9860328/dhcpd.conf.5.diff)
Thanks for considering this.4.4.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/3111restore missing lines in dlz_pthread.h2022-03-04T13:33:58ZEvan Huntrestore missing lines in dlz_pthread.hJosef Möllers pointed out on bind-users that DLZ modules cannot be built in 9.16 due to some lines that were inadvertently deleted when updating the copyrights.Josef Möllers pointed out on bind-users that DLZ modules cannot be built in 9.16 due to some lines that were inadvertently deleted when updating the copyrights.February 2022 (9.16.26, 9.16.26-S1)Evan HuntEvan Hunthttps://gitlab.isc.org/isc-projects/dhcp/-/issues/223RFE dhcrelay: add option to force giaddr2022-03-04T14:04:05ZjelmdRFE dhcrelay: add option to force giaddr
**Problem**
Some buggy dhcp clients (e.g. Solaris grub, which gets used e.g. for network install) use the address of the dhcp gateway (the host on which dhcrelay is running) to setup its default route instead of the announced default r...
**Problem**
Some buggy dhcp clients (e.g. Solaris grub, which gets used e.g. for network install) use the address of the dhcp gateway (the host on which dhcrelay is running) to setup its default route instead of the announced default router (3) entry. Therefore it is not able to download the config/kernel/miniroot and network [emergency] boot does not work (unless the required server are in the same [V]LAN/subnet).
**Solution**
Add an option e.g. "-g <ip_address>" to force setting the gw address in packages sent back to the dhclient to the given <ip_address>.
**Alternatives**
None.
**Funding its development**
No funding is needed. We already developed a patch and use it for several years on our gpu cluster as well as department networks and can be considered stable. However, wondering how to submit it. Clone and add a PR or just attaching it as plain text?4.4.3Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/kea/-/issues/2325Wrong file creation dates on files installed by Kea Cloudsmith packages2022-03-04T16:53:37ZVicky Riskvicky@isc.orgWrong file creation dates on files installed by Kea Cloudsmith packagesA user installing Kea from the ISC Cloudsmith repo reported:
Thanks! I installed from Debian packages (v2.0.1) but somehow they do not work.
The files:
```
root@dhcp01:/usr/lib/x86_64-linux-gnu/kea/hooks# ls -l
total 3192
-rw-r--r-- 1...A user installing Kea from the ISC Cloudsmith repo reported:
Thanks! I installed from Debian packages (v2.0.1) but somehow they do not work.
The files:
```
root@dhcp01:/usr/lib/x86_64-linux-gnu/kea/hooks# ls -l
total 3192
-rw-r--r-- 1 root root 63664 Apr 2 2019 libdhcp_bootp.so
-rw-r--r-- 1 root root 129312 Apr 2 2019 libdhcp_flex_id.so
-rw-r--r-- 1 root root 133248 Apr 2 2019 libdhcp_flex_option.so
-rw-r--r-- 1 root root 687728 Apr 2 2019 libdhcp_ha.so
-rw-r--r-- 1 root root 145568 Apr 2 2019 libdhcp_host_cmds.so
-rw-r--r-- 1 root root 268608 Apr 2 2019 libdhcp_lease_cmds.so
-rw-r--r-- 1 root root 420936 Apr 2 2019 libdhcp_legal_log.so
-rw-r--r-- 1 root root 1073680 Apr 2 2019 libdhcp_mysql_cb.so
-rw-r--r-- 1 root root 182384 Apr 2 2019 libdhcp_run_script.so
-rw-r--r-- 1 root root 145696 Apr 2 2019 libdhcp_stat_cmds.so
```
djt installed using the same instructions and got the same result - the file dates are wrong. by running a
`kea-dhcp4 -V` he found that the version is indeed 2.0.1, so the dates on the files are wrong.kea2.1.4Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2330Refactor CB v6 unit tests2022-03-04T19:16:26ZThomas MarkwalderRefactor CB v6 unit testsRepeat the unit test refactoring done under #2275 for CB V6.
Create generic CB V6 UT test classes, to house common code currently in mysql_cb_dhcp6_unittest.cc.Repeat the unit test refactoring done under #2275 for CB V6.
Create generic CB V6 UT test classes, to house common code currently in mysql_cb_dhcp6_unittest.cc.kea2.1.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/2294.4.2 final release notes2022-03-07T18:30:29ZWlodzimierz Wencel4.4.2 final release notesWrite release notes and please remember about comment https://gitlab.isc.org/isc-projects/dhcp/-/issues/222#note_262849Write release notes and please remember about comment https://gitlab.isc.org/isc-projects/dhcp/-/issues/222#note_2628494.4.3https://gitlab.isc.org/isc-projects/bind9/-/issues/3105Assertion failure on shutdown in req_senddone()2022-03-08T08:50:44ZMichal NowakAssertion failure on shutdown in req_senddone()This seems to be the same issue as isc-projects/bind9#2951 but it has the fix isc-projects/bind9!5715 in and the problem still occurs in the CI.
Job [#2240130](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2240130) failed for 710f62b...This seems to be the same issue as isc-projects/bind9#2951 but it has the fix isc-projects/bind9!5715 in and the problem still occurs in the CI.
Job [#2240130](https://gitlab.isc.org/isc-projects/bind9/-/jobs/2240130) failed for 710f62bf39a925c9a580192ec5ce8dee1ea66a06:
```
D:inline:Core was generated by `/builds/isc-projects/bind9/bin/named/.libs/named -D inline-ns2 -X named.lock -m'.
D:inline:Program terminated with signal SIGABRT, Aborted.
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:[Current thread is 1 (Thread 0x7f9c82efb700 (LWP 28048))]
D:inline:#0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
D:inline:#1 0x00007f9c885cc537 in __GI_abort () at abort.c:79
D:inline:#2 0x0000000000420cbc in assertion_failed (file=0x7f9c89033a11 "request.c", line=<optimized out>, type=<optimized out>, cond=<optimized out>) at main.c:238
D:inline:#3 0x00007f9c890b726a in isc_assertion_failed (file=0x2 <error: Cannot access memory at address 0x2>, line=-2098243744, line@entry=1030, type=type@entry=isc_assertiontype_require, cond=0x7f9c885e2ce1 <__GI_raise+321> "H\213\204$\b\001") at assertions.c:49
D:inline:#4 0x00007f9c88f82172 in req_senddone (eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at request.c:1030
D:inline:#5 0x00007f9c88eb8cb5 in send_done (handle=0x7f9c75389780, result=ISC_R_CANCELED, cbarg=0x0) at dispatch.c:1864
D:inline:#6 0x00007f9c890a7cbf in isc__nm_async_sendcb (worker=<optimized out>, ev0=ev0@entry=0x7f9c7538a080) at netmgr/netmgr.c:2838
D:inline:#7 0x00007f9c890a4362 in process_netievent (worker=worker@entry=0x7f9c85c49c80, ievent=ievent@entry=0x7f9c7538a080) at netmgr/netmgr.c:972
D:inline:#8 0x00007f9c8909fa81 in process_queue (worker=0x7f9c85c49c80, type=NETIEVENT_NORMAL) at netmgr/netmgr.c:1010
D:inline:#9 process_all_queues (worker=0x7f9c85c49c80) at netmgr/netmgr.c:756
D:inline:#10 async_cb (handle=0x7f9c85c49fe0) at netmgr/netmgr.c:785
D:inline:#11 0x00007f9c889bce83 in uv__async_io (loop=0x7f9c85c49c90, w=0x7f9c85c49e58, events=1) at /usr/src/libuv-v1.43.0/src/unix/async.c:163
D:inline:#12 0x00007f9c889d8b87 in uv__io_poll (loop=0x7f9c85c49c90, timeout=0) at /usr/src/libuv-v1.43.0/src/unix/epoll.c:374
D:inline:#13 0x00007f9c889bd86c in uv_run (loop=0x7f9c85c49c90, mode=UV_RUN_DEFAULT) at /usr/src/libuv-v1.43.0/src/unix/core.c:389
D:inline:#14 0x00007f9c8909fbf1 in nm_thread (worker0=0x7f9c85c49c80) at netmgr/netmgr.c:691
D:inline:#15 0x00007f9c890dede5 in isc__trampoline_run (arg=0x2372760) at trampoline.c:187
D:inline:#16 0x00007f9c88774ea7 in start_thread (arg=<optimized out>) at pthread_create.c:477
D:inline:#17 0x00007f9c886a4def in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
```
[core.28030-backtrace.txt](/uploads/454199c1540460b792772cad022aea8f/core.28030-backtrace.txt)April 2022 (9.16.28, 9.16.28-S1, 9.18.2, 9.19.0)https://gitlab.isc.org/isc-projects/dhcp/-/issues/231final release of 4.4.32022-03-08T09:25:06ZWlodzimierz Wencelfinal release of 4.4.34.4.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/stork/-/issues/298Nested menus and tabs confusion2022-03-08T14:38:44ZVicky Riskvicky@isc.orgNested menus and tabs confusionThe combined top nav menu, 'Kea Apps' tabs, and then the list of daemons below that, was confusing. Cathy commented that while she liked the fact that she could open tabs here and leave them open, there were so many layers of tabs she wa...The combined top nav menu, 'Kea Apps' tabs, and then the list of daemons below that, was confusing. Cathy commented that while she liked the fact that she could open tabs here and leave them open, there were so many layers of tabs she wasn't sure what related to what.
This could be somewhat ameliorated by using the same names for the app in the upper set of tabs and the title of the lower panel. Here the upper tabs are labelled 'Kea@hostname' but the title of the panel below is 'Kea App<ID>'. It would help to allay confusion if we used the same identifier in both places.
![Screen_Shot_2020-05-28_at_4.19.54_PM](/uploads/2de86660e28e505e67b0845ef45f9bb2/Screen_Shot_2020-05-28_at_4.19.54_PM.png)https://gitlab.isc.org/isc-projects/dhcp/-/issues/2284.4.3 release2022-03-10T13:57:42ZWlodzimierz Wencel4.4.3 release---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# ISC-DHCP Release Checklist
1. Check Jenkins results:
1. [x] Check Jenkins [tarball](https://jenkins.aws.isc.org/view/isc-dhcp-d...---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# ISC-DHCP Release Checklist
1. Check Jenkins results:
1. [x] Check Jenkins [tarball](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/dhcp-tarball/) job for failures
1. [x] Check Jenkins [unit tests](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/tarball-system-tests/) job for failures
1. [x] Check Jenkins [system tests](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/tarball-system-tests/) job for failures
1. [x] If needed use those jobs to run tests against any branch
1. Tarball preparation:
1. [x] If this is release of final version please check sanity check ticket of previous release and make sure all comments are addressed
1. [x] Make sure that Release Notes are written and reviewed before sanity checks, changes in Release Notes require tarball respin!
1. [x] bump up version in configure.ac
1. [x] change copy rights string that is printed on startup for each of the applications in `server/dhcpd.c`
1. [x] change copy rights string that is printed on startup for each of the applicationsdate in `client/dhclient.c`
1. [x] change copy rights string that is printed on startup for each of the applicationsdate in `relay/dhcrelay.c`
1. [x] check the date in LICENSE
1. [x] check README file (including installation details)
1. [x] update copyrigths in all touched files using simple script in [qa-dhcp](https://gitlab.isc.org/isc-private/qa-dhcp/-/tree/master/dhcp/scripts).
1. [x] commit changes to repo
1. aclocal/autoheader/automake/autoconf
1. [x] login to docs.isc.org
1. [x] checkout release branch (it's important to have configure.ac change done before)
1. [x] regenerate makefiles `aclocal && autoheader && automake && autoconf`
1. [x] review and push changes
1. Build tarball
1. [x] go to [tarball](https://jenkins.aws.isc.org/view/isc-dhcp-dev/job/dhcp-dev/job/dhcp-tarball/) > Build with Parameters, in field `dhcpBranch` put in release branch and run job, this will build release tarball and save it as artifact of the job
1. [x] wait for other jobs to finish testing (unit-tests and system-tests) and check their results
1. [x] before tarball will be deemed as ready to release it will be `release candidate`. Each consecutive respin will have it's own name starting from `-rc1`
1. [x] prepare directory for current release at repo.isc.org with correct prefix for release candidate e.g. `/data/shared/sweng/dhcp/releases/4.4.3b1.rc1`
1. [x] upload tarball and release notes (even if release notes are included into tarball, it should be also in separate file) to created directory for sanity checks
1. Sanity Checks
1. [x] open a ticket in dhcp repo called `release X.Y.Z-rcX sanity checks` and put there location of release tarball and it's sha256 sum
1. [x] wait for team input about new tarball, if respin is needed go back to `Build tarball` point also increasing release candidate number
1. [x] if tarball is accepted create a tag of this version on a last commit in release branch
1. [x] move tarball and release notes to non release candidate location (e.g. moving from /data/shared/sweng/dhcp/releases/4.3.2b1.rc1 to /data/shared/sweng/dhcp/releases/4.3.2b1)
1. [x] make sure that new release directory allow group write e.g. `chmod 665 /data/shared/sweng/dhcp/releases/4.3.2b1`
1. [x] open tickets to address issues mentioned in sanity checks IF those were not already fixed and close sanity check ticket
1. Signing and notification
1. [x] it's time to [open a signing ticket](https://gitlab.isc.org/isc-private/signing/-/issues) that include location and sha256 of the tarball
1. [x] notify support about readiness of release, at this point QA and dev team work is done
1. Releasing tarball
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Wait for the signing ticket from the release engineer.
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [x] ***(Support)*** Sign the tarballs.
- [x] ***(Support)*** Upload signature files to repo.isc.org.
- [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 *dhcp-announce*.
- [x] ***(Support)*** Write email to *dhcp-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [ ] ***(Marketing)*** Announce on social media.
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Translate the man pages, reformat and upload to the DHCP documentation pages in the KB.
[checklist source](https://wiki.isc.org/bin/view/Main/HowToReleaseDHCP)4.4.3Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/14Building DHCP 4.4.1 using libbind from BIND 9.14.x2022-03-13T21:09:54ZGhost UserBuilding DHCP 4.4.1 using libbind from BIND 9.14.xI'm trying to build DHCP 4.4.1. There are many build errors because of missing definitions, e.g.:
`../includes/tree.h:307:30: error: unknown type name 'isc_boolean_t'; did you mean 'isc_token_t'?`
When building against BIND 9.12.4, I'm...I'm trying to build DHCP 4.4.1. There are many build errors because of missing definitions, e.g.:
`../includes/tree.h:307:30: error: unknown type name 'isc_boolean_t'; did you mean 'isc_token_t'?`
When building against BIND 9.12.4, I'm able to work around these by adding `#include <isc/boolean.h>` and similarly for int.h to dhcpd.h and omapip.h. However, that is no longer a viable fix when building against BIND 9.14.x, because those header files are no longer part of BIND in that release.
Is there a recommended approach for building DHCP 4.4.1?https://gitlab.isc.org/isc-projects/bind9/-/issues/2488Update key refresh timer after 'rndc dnssec -rollover'2022-03-14T09:47:54ZMarc Dequènes (Duck)Update key refresh timer after 'rndc dnssec -rollover'### Summary
`rndc dnssec -rollover` does not trigger a KSK rollover as expected.
### BIND version used
```
BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
...### Summary
`rndc dnssec -rollover` does not trigger a KSK rollover as expected.
### BIND version used
```
BIND 9.16.8-Debian (Stable Release) <id:539f9f0>
running on Linux x86_64 4.19.0-13-amd64 #1 SMP Debian 4.19.160-2 (2020-11-28)
built by make with '--build=x86_64-linux-gnu' '--prefix=/usr' '--includedir=/usr/include' '--mandir=/usr/share/man' '--infodir=/usr/share/info' '--sysconfdir=/etc' '--localstatedir=/var' '--disable-silent-rules' '--libdir=/usr/lib/x86_64-linux-gnu' '--runstatedir=/run' '--disable-maintainer-mode' '--disable-dependency-tracking' '--libdir=/usr/lib/x86_64-linux-gnu' '--sysconfdir=/etc/bind' '--with-python=python3' '--localstatedir=/' '--enable-threads' '--enable-largefile' '--with-libtool' '--enable-shared' '--enable-static' '--with-gost=no' '--with-openssl=/usr' '--with-gssapi=/usr' '--with-libidn2' '--with-json-c' '--with-lmdb=/usr' '--with-gnu-ld' '--with-maxminddb' '--with-atf=no' '--enable-ipv6' '--enable-rrl' '--enable-filter-aaaa' '--disable-native-pkcs11' '--enable-dnstap' 'build_alias=x86_64-linux-gnu' 'CFLAGS=-g -O2 -fdebug-prefix-map=/build/bind9-Pv1hAF/bind9-9.16.8=. -fstack-protector-strong -Wformat -Werror=format-security -fno-strict-aliasing -fno-delete-null-pointer-checks -DNO_VERSION_DATE -DDIG_SIGCHASE' 'LDFLAGS=-Wl,-z,relro -Wl,-z,now' 'CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2'
compiled by GCC 8.3.0
compiled with OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
linked to OpenSSL version: OpenSSL 1.1.1d 10 Sep 2019
compiled with libuv version: 1.24.1
linked to libuv version: 1.24.1
compiled with libxml2 version: 2.9.4
linked to libxml2 version: 20904
compiled with json-c version: 0.12.1
linked to json-c version: 0.12.1
compiled with zlib version: 1.2.11
linked to zlib version: 1.2.11
linked to maxminddb version: 1.3.2
compiled with protobuf-c version: 1.3.1
linked to protobuf-c version: 1.3.1
threads support is enabled
default paths:
named configuration: /etc/bind/named.conf
rndc configuration: /etc/bind/rndc.conf
DNSSEC root key: /etc/bind/bind.keys
nsupdate session key: //run/named/session.key
named PID file: //run/named/named.pid
named lock file: //run/named/named.lock
geoip-directory: /usr/share/GeoIP
```
### Steps to reproduce
* on a domain with one single KSK currently in use and working properly as reported by dnsviz
* rndc dnssec -rollover -key <ksk-id> <domain>
### What is the current *bug* behavior?
Status before:
```dnssec-policy: generated
current time: Wed Feb 10 20:16:26 2021
key: 43281 (RSASHA512), KSK
published: yes - since Fri Aug 28 00:31:44 2020
key signing: yes - since Fri Aug 28 00:31:44 2020
Next rollover scheduled on Sun Sep 26 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 20426 (RSASHA512), ZSK
published: yes - since Sat Nov 21 00:31:44 2020
zone signing: yes - since Mon Dec 21 00:31:44 2020
Next rollover scheduled on Sat Mar 20 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
```
Status after:
```
dnssec-policy: generated
current time: Thu Feb 11 16:03:34 2021
key: 43281 (RSASHA512), KSK
published: yes - since Fri Aug 28 00:31:44 2020
key signing: yes - since Fri Aug 28 00:31:44 2020
Next rollover scheduled on Wed Feb 10 20:21:50 2021
- goal: omnipresent
- dnskey: omnipresent
- ds: omnipresent
- key rrsig: omnipresent
key: 20426 (RSASHA512), ZSK
published: yes - since Sat Nov 21 00:31:44 2020
zone signing: yes - since Mon Dec 21 00:31:44 2020
Next rollover scheduled on Sat Mar 20 22:26:44 2021
- goal: omnipresent
- dnskey: omnipresent
- zone rrsig: omnipresent
```
Except for the rollover date, which is now in the past, *nothing* happened.
### What is the expected *correct* behavior?
I was expecting:
* the key to have a new goal state (there is no doc on the possible states, so I don't know which one would be appropriate)
* a new KSK to be automatically generated as per the policy
* the new key to be introduced so that I can mark it as seen when published (with `rndc dnssec -checkds` IIUC)
* and the rest of the rollover steps to follow
Since I asked for a forced rollover and the time when not set is *now* according to the doc (the scheduled time matches, so that's fine), then I would expect things to be set in motion very quickly. I did not try to restart to do anything that might supposedly trigger the scheduler but it should not be necessary. I'm also not expecting to have to create a new key by myself, as I think it's the policy's responsibility to create keys with the proper parameters.
### Relevant configuration files
The policy:
```
dnssec-policy "generated" {
keys {
ksk key-directory lifetime P1Y algorithm rsasha512 4096;
zsk key-directory lifetime 30d algorithm rsasha512 2048;
};
max-zone-ttl PT1H;
};
```
The zone config:
```
zone "_kage.hq.duckcorp.org" IN {
type master;
allow-transfer { key duckcorp-internal; };
update-policy { grant duckcorp-le-Elwing name _acme-challenge.smtp._kage.hq.duckcorp.org TXT; grant duckcorp-le-Elwing name _25._tcp.smtp._kage.hq.duckcorp.org TLSA; };
file "/var/cache/bind/masters/_kage.hq.duckcorp.org.zone";
dnssec-policy "generated";
};
```
### Possible fixes
Maybe this command is not doing what I expect but since there is no documentation about procedures with the new dnssec-policy system and it seems almost noone is writing on it on the Internet I'm at a loss to understand what to do.
Btw I was thinking about doing an algo rollover in the future, and I was wondering if simply changing the policy would automagically do the required steps the next time a key is replaced (or when you force a rollover).April 2021 (9.11.30/9.11.31, 9.11.30-S1/9.11.31-S1, 9.16.14/9.16.15, 9.16.14-S1/9.16.15-S1, 9.17.12)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2342PgSql CB V6 core, queries and support for servers2022-03-14T13:18:32ZThomas MarkwalderPgSql CB V6 core, queries and support for servers All queries complete, support for unit tests, and CRUD for servers All queries complete, support for unit tests, and CRUD for serverskea2.1.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2346PgSql CB V6 Add support for globals, option defs, and options2022-03-14T13:18:32ZThomas MarkwalderPgSql CB V6 Add support for globals, option defs, and optionsNext step in Postgresql CB v6:
global parameters
option definitions
options
Note does not include implement methods or tests for definitions or options that belong to other objects (such as networks, subnets...)Next step in Postgresql CB v6:
global parameters
option definitions
options
Note does not include implement methods or tests for definitions or options that belong to other objects (such as networks, subnets...)kea2.1.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2349PgSql CB V6 Add support for shared-networks, subnets, pools2022-03-14T13:23:24ZThomas MarkwalderPgSql CB V6 Add support for shared-networks, subnets, poolskea2.1.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2355PgSql CB V6 Add support for client-classes2022-03-14T16:06:39ZThomas MarkwalderPgSql CB V6 Add support for client-classesAdd support to Postgresql CB for client classes. This ticket will complete the Postgresql CB implementation.Add support to Postgresql CB for client classes. This ticket will complete the Postgresql CB implementation.kea2.1.4Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/96CB: Implement PgSQLConfigBackendDHCPv62022-03-14T17:38:45ZMarcin SiodelskiCB: Implement PgSQLConfigBackendDHCPv6The PgSQLConfigBackendDHCPv6 class implements Config Backend for MySQL as described in https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-designThe PgSQLConfigBackendDHCPv6 class implements Config Backend for MySQL as described in https://gitlab.isc.org/isc-projects/kea/wikis/designs/configuration-in-db-designkea2.1.4Thomas MarkwalderThomas Markwalder