ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-08-22T11:39:14Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/763Add optional validation of overlapping pools in Kea configuration (v4 and v6)2022-08-22T11:39:14ZCathy AlmondAdd optional validation of overlapping pools in Kea configuration (v4 and v6)Bad things happen if you accidentally configure overlapping lease pools, but currently Kea does not do any checks of the configuration to prevent this from happening.
The reason it doesn't is that for large and complex configurations, t...Bad things happen if you accidentally configure overlapping lease pools, but currently Kea does not do any checks of the configuration to prevent this from happening.
The reason it doesn't is that for large and complex configurations, the performance cost will outweigh the potential benefit for many administrators. Those environments already have change control processes with sanity checks that prevent this type of accident.
But some smaller sites - especially those that are seldom updates, so the DHCP admins are generalists rather than specialists, might appreciate something like this.
This request also applies to PD pools, where it was discovered (in ticket [Ticket #17393](https://support.isc.org/Ticket/Display.html?id=17393), albeit accidentally, that configuring overlapping PD pools might actually work without problems - although we don't recommend this because not all potential scenarios have been tested (plus the stats will be quite peculiar).1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/752Migrate from CentOS to RedHat Universal Base Image2022-08-17T15:06:56ZSlawek FigielMigrate from CentOS to RedHat Universal Base ImageCentOS 8 disappeared (surprise EOL) and we need a widely acceptable base image. RedHat provides such an image that's free of charge and is supposed to be binary compatible with RHEL.CentOS 8 disappeared (surprise EOL) and we need a widely acceptable base image. RedHat provides such an image that's free of charge and is supposed to be binary compatible with RHEL.1.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/stork/-/issues/746Rewrite the update package system tests2022-08-17T15:06:56ZSlawek FigielRewrite the update package system testsThe system tests that check updating Stork from the packages were omitted in the first new system tests development due to technical troubles.
They are critical, and we should restore them.The system tests that check updating Stork from the packages were omitted in the first new system tests development due to technical troubles.
They are critical, and we should restore them.1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/736Stork-Agent Alpine Docker2022-09-02T11:24:45Zrgomez-engStork-Agent Alpine DockerWe are using docker stack with Alpine to form an HA of kea-dhcp4. That is all working good. Recently we decided to give a try to Stork. We managed to build the stork-server and the stork-webui based on the docker files provided, but thos...We are using docker stack with Alpine to form an HA of kea-dhcp4. That is all working good. Recently we decided to give a try to Stork. We managed to build the stork-server and the stork-webui based on the docker files provided, but those are based on Debian.
Is there any way to install the stork-agent on the already working kea-dhcp4 alpine image? I believe that's the only thing missing here to add the machines to Stork.
We also did try to download the agent from the Stork webui of course but we get an error about problem reading `Problem reading 'webui/dist/stork/assets/pkgs' directory with packages: open webui/dist/stork/assets/pkgs: no such file or directory`, which is weird since this image is freshly built from the `server-webui` stage in the provided Dockerfile.
Thanks,1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/731Migrate from primeflex 2.0 to primeflex 3.02022-08-17T15:06:56ZMarcin SiodelskiMigrate from primeflex 2.0 to primeflex 3.0Primeflex 3.0 has significantly more styling classes and other features. I propose that we migrate to it. The sooner the easier.Primeflex 3.0 has significantly more styling classes and other features. I propose that we migrate to it. The sooner the easier.1.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/610Dismiss certain config checkers2022-09-16T13:04:22ZMarcin SiodelskiDismiss certain config checkersSome config checkers may produce unwanted alarms. Some configuration decisions may be deliberate. We should allow users to disable those checkers that they don't want to run. This will reduce the noise in the reviews list. It will also i...Some config checkers may produce unwanted alarms. Some configuration decisions may be deliberate. We should allow users to disable those checkers that they don't want to run. This will reduce the noise in the reviews list. It will also improve the performance of the configuration review.1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/193Test Stork on FreeBSD and OpenBSD2023-11-26T13:32:21ZTomek MrugalskiTest Stork on FreeBSD and OpenBSDOne of the fundamental requirements for the Stork project was that it's supposed to be portable. We decided that the two systems Stork should run on are Ubuntu and FreeBSD. Jeff confirmed that our commitment to FreeBSD remains as import...One of the fundamental requirements for the Stork project was that it's supposed to be portable. We decided that the two systems Stork should run on are Ubuntu and FreeBSD. Jeff confirmed that our commitment to FreeBSD remains as important as it was throughout the years. So far we're running Stork on Ubuntu and did some quick tests on FreeBSD and discovered some problems with running it there.
Note the following excerpt from Rakefile:
```Rakefile
when "FreeBSD"
OS="FreeBSD"
# TODO: there are no swagger built packages for FreeBSD
GOSWAGGER_BIN=""
puts "WARNING: There are no FreeBSD packages for GOSWAGGER_BIN"
GO_SUFFIX="freebsd-amd64"
# TODO: there are no protoc built packages for FreeBSD (at least as of 3.10.0)
PROTOC_ZIP_SUFFIX=""
puts "WARNING: There are no protoc packages built for FreeBSD"
NODE_SUFFIX="node-v10.16.3.tar.xz"
GOLANGCILINT_SUFFIX="freebsd-amd64"
```
One of the possible ways to avoid problems with missing goswagger binaries is to generate the API bindings only when they're changed and keep them checked into the repo. See #182 for related problem.
As for the protoc, there are [no FreeBSD builds](https://github.com/protocolbuffers/protobuf/releases/download) as of March 2020. However, that can be compiled from sources.
**EDIT:** Updated title to reflect OpenBSD changes.1.6Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3514CID 356328: Control flow issues (DEADCODE) in bin/named/server.c2022-09-06T09:15:23ZMichal NowakCID 356328: Control flow issues (DEADCODE) in bin/named/server.cCoverity Scan reports supposed dead code (originated in b69e783164cd50e3306364668558e460617ee8fc):
```
/bin/named/server.c: 8756 in load_configuration()
8750 "creating UDP/IPv4 port set: %s",
8751 isc_result_tot...Coverity Scan reports supposed dead code (originated in b69e783164cd50e3306364668558e460617ee8fc):
```
/bin/named/server.c: 8756 in load_configuration()
8750 "creating UDP/IPv4 port set: %s",
8751 isc_result_totext(result));
8752 goto cleanup_bindkeys_parser;
8753 }
8754 isc_portset_create(named_g_mctx, &v6portset);
8755 if (result != ISC_R_SUCCESS) {
>>> CID 356328: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "isc_log_write(named_g_lctx,...".
8756 isc_log_write(named_g_lctx, NAMED_LOGCATEGORY_GENERAL,
8757 NAMED_LOGMODULE_SERVER, ISC_LOG_ERROR,
8758 "creating UDP/IPv6 port set: %s",
8759 isc_result_totext(result));
8760 goto cleanup_v4portset;
8761 }
```September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3489CID 355779: Null pointer dereferences in lib/dns/tkey.c2022-08-26T13:17:55ZMichal NowakCID 355779: Null pointer dereferences in lib/dns/tkey.cCoverity Scan identified the following issue on `main`:
```
*** CID 355779: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 997 in buildquery()
991 dns_message_puttempname(msg, &aname);
992 }
993 if (question...Coverity Scan identified the following issue on `main`:
```
*** CID 355779: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 997 in buildquery()
991 dns_message_puttempname(msg, &aname);
992 }
993 if (question != NULL) {
994 dns_rdataset_disassociate(question);
995 dns_message_puttemprdataset(msg, &question);
996 }
>>> CID 355779: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "dynbuf" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
997 if (dynbuf != NULL) {
998 isc_buffer_free(&dynbuf);
999 }
1000 return (result);
1001 }
1002
```
5c8cb7cc3f13eb1d041bd6264c61b3d30707b4c5 might be the culprit. @aram can you have a look?September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3467dns_rdatalist_tordataset can not fail update prototype to return void2022-09-06T08:25:45ZMark Andrewsdns_rdatalist_tordataset can not fail update prototype to return voidUpdate prototype and cleanup unnecessary error handling.
Repeat for any calling functions that subsequently cannot fail.Update prototype and cleanup unnecessary error handling.
Repeat for any calling functions that subsequently cannot fail.September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Arаm SаrgsyаnArаm Sаrgsyаnhttps://gitlab.isc.org/isc-projects/bind9/-/issues/3364Various Coverity issues after dns_message_gettemp* cleanup2022-09-08T10:57:47ZMichal NowakVarious Coverity issues after dns_message_gettemp* cleanupVarious issues identified by Coverity Scan after `dns_message_gettemp*` functions cleanup (33ba0057a7c44d4e5d63f7f55e1823279e996a19) on `main`:
```
** CID 352819: Control flow issues (DEADCODE)
/lib/dns/xfrin.c: 1366 in xfrin_send_requ...Various issues identified by Coverity Scan after `dns_message_gettemp*` functions cleanup (33ba0057a7c44d4e5d63f7f55e1823279e996a19) on `main`:
```
** CID 352819: Control flow issues (DEADCODE)
/lib/dns/xfrin.c: 1366 in xfrin_send_request()
________________________________________________________________________________________________________
*** CID 352819: Control flow issues (DEADCODE)
/lib/dns/xfrin.c: 1366 in xfrin_send_request()
1360
1361 failure:
1362 if (qname != NULL) {
1363 dns_message_puttempname(msg, &qname);
1364 }
1365 if (qrdataset != NULL) {
>>> CID 352819: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttemprdataset...".
1366 dns_message_puttemprdataset(msg, &qrdataset);
1367 }
1368 if (msg != NULL) {
1369 dns_message_detach(&msg);
1370 }
1371 if (soatuple != NULL) {
** CID 352818: Null pointer dereferences (REVERSE_INULL)
/lib/dns/message.c: 2882 in dns_message_setquerytsig()
________________________________________________________________________________________________________
*** CID 352818: Null pointer dereferences (REVERSE_INULL)
/lib/dns/message.c: 2882 in dns_message_setquerytsig()
2876
2877 msg->querytsig = set;
2878
2879 return (result);
2880
2881 cleanup:
>>> CID 352818: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "rdata" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
2882 if (rdata != NULL) {
2883 dns_message_puttemprdata(msg, &rdata);
2884 }
2885 if (list != NULL) {
2886 dns_message_puttemprdatalist(msg, &list);
2887 }
** CID 352817: Control flow issues (DEADCODE)
/lib/ns/xfrout.c: 1568 in sendstream()
________________________________________________________________________________________________________
*** CID 352817: Control flow issues (DEADCODE)
/lib/ns/xfrout.c: 1568 in sendstream()
1562
1563 /* Advance lasttsig to be the last TSIG generated */
1564 CHECK(dns_message_getquerytsig(msg, xfr->mctx, &xfr->lasttsig));
1565
1566 failure:
1567 if (msgname != NULL) {
>>> CID 352817: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "if (msgrds != NULL) {
if ...".
1568 if (msgrds != NULL) {
1569 if (dns_rdataset_isassociated(msgrds)) {
1570 dns_rdataset_disassociate(msgrds);
1571 }
1572 dns_message_puttemprdataset(msg, &msgrds);
1573 }
** CID 352816: Control flow issues (DEADCODE)
/lib/ns/query.c: 8443 in query_dns64()
________________________________________________________________________________________________________
*** CID 352816: Control flow issues (DEADCODE)
/lib/ns/query.c: 8443 in query_dns64()
8437 cleanup:
8438 if (buffer != NULL) {
8439 isc_buffer_free(&buffer);
8440 }
8441
8442 if (dns64_rdata != NULL) {
>>> CID 352816: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttemprdata(cl...".
8443 dns_message_puttemprdata(client->message, &dns64_rdata);
8444 }
8445
8446 if (dns64_rdataset != NULL) {
8447 dns_message_puttemprdataset(client->message, &dns64_rdataset);
8448 }
** CID 352815: Control flow issues (DEADCODE)
/lib/dns/xfrin.c: 1363 in xfrin_send_request()
________________________________________________________________________________________________________
*** CID 352815: Control flow issues (DEADCODE)
/lib/dns/xfrin.c: 1363 in xfrin_send_request()
1357 isc_nmhandle_attach(send_xfr->handle, &xfr->sendhandle);
1358 isc_refcount_increment0(&send_xfr->sends);
1359 isc_nm_send(xfr->handle, ®ion, xfrin_send_done, send_xfr);
1360
1361 failure:
1362 if (qname != NULL) {
>>> CID 352815: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttempname(msg...".
1363 dns_message_puttempname(msg, &qname);
1364 }
1365 if (qrdataset != NULL) {
1366 dns_message_puttemprdataset(msg, &qrdataset);
1367 }
1368 if (msg != NULL) {
** CID 352814: Null pointer dereferences (REVERSE_INULL)
/lib/dns/xfrin.c: 1267 in tuple2msgname()
________________________________________________________________________________________________________
*** CID 352814: Null pointer dereferences (REVERSE_INULL)
/lib/dns/xfrin.c: 1267 in tuple2msgname()
1261 failure:
1262
1263 if (rds != NULL) {
1264 dns_rdataset_disassociate(rds);
1265 dns_message_puttemprdataset(msg, &rds);
1266 }
>>> CID 352814: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "rdl" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1267 if (rdl != NULL) {
1268 ISC_LIST_UNLINK(rdl->rdata, rdata, link);
1269 dns_message_puttemprdatalist(msg, &rdl);
1270 }
1271 if (rdata != NULL) {
1272 dns_message_puttemprdata(msg, &rdata);
** CID 352813: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 199 in add_rdata_to_list()
________________________________________________________________________________________________________
*** CID 352813: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 199 in add_rdata_to_list()
193
194 ISC_LIST_APPEND(*namelist, newname, link);
195
196 return (ISC_R_SUCCESS);
197
198 failure:
>>> CID 352813: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "newrdata" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
199 if (newrdata != NULL) {
200 if (ISC_LINK_LINKED(newrdata, link)) {
201 INSIST(newlist != NULL);
202 ISC_LIST_UNLINK(newlist->rdata, newrdata, link);
203 }
204 dns_message_puttemprdata(msg, &newrdata);
** CID 352812: Control flow issues (DEADCODE)
/lib/ns/query.c: 8584 in query_filter64()
________________________________________________________________________________________________________
*** CID 352812: Control flow issues (DEADCODE)
/lib/ns/query.c: 8584 in query_filter64()
8578 cleanup:
8579 if (buffer != NULL) {
8580 isc_buffer_free(&buffer);
8581 }
8582
8583 if (myrdata != NULL) {
>>> CID 352812: Control flow issues (DEADCODE)
>>> Execution cannot reach this statement: "dns_message_puttemprdata(cl...".
8584 dns_message_puttemprdata(client->message, &myrdata);
8585 }
8586
8587 if (myrdataset != NULL) {
8588 dns_message_puttemprdataset(client->message, &myrdataset);
8589 }
** CID 352811: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 213 in add_rdata_to_list()
________________________________________________________________________________________________________
*** CID 352811: Null pointer dereferences (REVERSE_INULL)
/lib/dns/tkey.c: 213 in add_rdata_to_list()
207 dns_message_puttempname(msg, &newname);
208 }
209 if (newset != NULL) {
210 dns_rdataset_disassociate(newset);
211 dns_message_puttemprdataset(msg, &newset);
212 }
>>> CID 352811: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "newlist" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
213 if (newlist != NULL) {
214 dns_message_puttemprdatalist(msg, &newlist);
215 }
216 return (result);
217 }
218
** CID 352810: Null pointer dereferences (REVERSE_INULL)
/lib/dns/message.c: 2885 in dns_message_setquerytsig()
________________________________________________________________________________________________________
*** CID 352810: Null pointer dereferences (REVERSE_INULL)
/lib/dns/message.c: 2885 in dns_message_setquerytsig()
2879 return (result);
2880
2881 cleanup:
2882 if (rdata != NULL) {
2883 dns_message_puttemprdata(msg, &rdata);
2884 }
>>> CID 352810: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "list" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
2885 if (list != NULL) {
2886 dns_message_puttemprdatalist(msg, &list);
2887 }
2888 if (set != NULL) {
2889 dns_message_puttemprdataset(msg, &set);
2890 }
** CID 352809: Null pointer dereferences (REVERSE_INULL)
/lib/dns/message.c: 4654 in dns_message_buildopt()
________________________________________________________________________________________________________
*** CID 352809: Null pointer dereferences (REVERSE_INULL)
/lib/dns/message.c: 4654 in dns_message_buildopt()
4648 if (rdata != NULL) {
4649 dns_message_puttemprdata(message, &rdata);
4650 }
4651 if (rdataset != NULL) {
4652 dns_message_puttemprdataset(message, &rdataset);
4653 }
>>> CID 352809: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "rdatalist" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
4654 if (rdatalist != NULL) {
4655 dns_message_puttemprdatalist(message, &rdatalist);
4656 }
4657 return (result);
4658 }
4659
** CID 352808: Null pointer dereferences (REVERSE_INULL)
/lib/dns/xfrin.c: 1271 in tuple2msgname()
________________________________________________________________________________________________________
*** CID 352808: Null pointer dereferences (REVERSE_INULL)
/lib/dns/xfrin.c: 1271 in tuple2msgname()
1265 dns_message_puttemprdataset(msg, &rds);
1266 }
1267 if (rdl != NULL) {
1268 ISC_LIST_UNLINK(rdl->rdata, rdata, link);
1269 dns_message_puttemprdatalist(msg, &rdl);
1270 }
>>> CID 352808: Null pointer dereferences (REVERSE_INULL)
>>> Null-checking "rdata" suggests that it may be null, but it has already been dereferenced on all paths leading to the check.
1271 if (rdata != NULL) {
1272 dns_message_puttemprdata(msg, &rdata);
1273 }
1274
1275 return (result);
1276 }
```September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/3334rdata unit test fails on OpenBSD 7.1 in "key" and "sig_rrsig" tests2022-09-14T11:48:11ZMichal Nowakrdata unit test fails on OpenBSD 7.1 in "key" and "sig_rrsig" testsThe `rdata_test` unit test fails on OpenBSD 7.1 with Clang 13.0.0 on `main` (and only there) and thus prevents updating to the new release (isc-projects/images!163):
```
[==========] Running 27 test(s).
[ RUN ] amtrelay
[ OK ]...The `rdata_test` unit test fails on OpenBSD 7.1 with Clang 13.0.0 on `main` (and only there) and thus prevents updating to the new release (isc-projects/images!163):
```
[==========] Running 27 test(s).
[ RUN ] amtrelay
[ OK ] amtrelay
[ RUN ] apl
[ OK ] apl
[ RUN ] atma
[ OK ] atma
[ RUN ] cdnskey
[ OK ] cdnskey
[ RUN ] csync
[ OK ] csync
[ RUN ] dnskey
[ OK ] dnskey
[ RUN ] doa
[ OK ] doa
[ RUN ] ds
[ OK ] ds
[ RUN ] eid
[ OK ] eid
[ RUN ] hip
[ OK ] hip
[ RUN ] https_svcb
[ OK ] https_svcb
[ RUN ] isdn
[ OK ] isdn
[ RUN ] key
[ ERROR ] --- 0 == 0
[ LINE ] --- rdata_test.c:410: error: Failure!
[ FAILED ] key
[ RUN ] loc
[ OK ] loc
[ RUN ] nimloc
[ OK ] nimloc
[ RUN ] nsec
[ OK ] nsec
[ RUN ] nsec3
[ OK ] nsec3
[ RUN ] nxt
[ OK ] nxt
[ RUN ] rkey
[ OK ] rkey
[ RUN ] sig_rrsig
[ ERROR ] --- 0 == 0
[ LINE ] --- rdata_test.c:410: error: Failure!
[ FAILED ] sig_rrsig
[ RUN ] sshfp
[ OK ] sshfp
[ RUN ] wks
[ OK ] wks
[ RUN ] zonemd
[ OK ] zonemd
[ RUN ] edns_client_subnet
[ OK ] edns_client_subnet
[ RUN ] atcname
[ OK ] atcname
[ RUN ] atparent
[ OK ] atparent
[ RUN ] iszonecutauth
[ OK ] iszonecutauth
[==========] 27 test(s) run.
[ PASSED ] 25 test(s).
[ FAILED ] 2 test(s), listed below:
[ FAILED ] key
[ FAILED ] sig_rrsig
2 FAILED TEST(S)
FAIL rdata_test (exit status: 2)
```September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/3521Crash during reconfig in ns_interface_create()2022-09-08T11:01:11ZCathy AlmondCrash during reconfig in ns_interface_create()Reported to us via [Support Ticket #21126](https://support.isc.org/Ticket/Display.html?id=21126)
Reported against BIND 9.16.23
> In ns_interface_create(), there's insufficient cleanup upon failure.
>
> The following is the patch commi...Reported to us via [Support Ticket #21126](https://support.isc.org/Ticket/Display.html?id=21126)
Reported against BIND 9.16.23
> In ns_interface_create(), there's insufficient cleanup upon failure.
>
> The following is the patch committed to fix it:
```patch
diff --git a/bind9.16/lib/ns/interfacemgr.c b/bind9.16/lib/ns/interfacemgr.c
index 7006e7c478b..0e1cc71560d 100644
--- a/bind9.16/lib/ns/interfacemgr.c
+++ b/bind9.16/lib/ns/interfacemgr.c
@@ -448,6 +448,15 @@ ns_interface_create(ns_interfacemgr_t *mgr, isc_sockaddr_t *addr,
return (ISC_R_SUCCESS);
failure:
+#ifdef ORIGINAL_ISC_CODE
+#else
+ LOCK(&ifp->mgr->lock);
+ ISC_LIST_UNLINK(ifp->mgr->interfaces, ifp, link);
+ UNLOCK(&ifp->mgr->lock);
+ ns_interfacemgr_detach(&ifp->mgr);
+ isc_refcount_decrementz(&ifp->references);
+ isc_refcount_destroy(&ifp->references);
+#endif
isc_mutex_destroy(&ifp->lock);
ifp->magic = 0;
```September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)https://gitlab.isc.org/isc-projects/bind9/-/issues/3526Release Checklist for BIND 9.16.33, 9.16.33-S1, 9.18.7, 9.19.52022-11-07T11:59:41ZMichał KępieńRelease Checklist for BIND 9.16.33, 9.16.33-S1, 9.18.7, 9.19.5## Release Schedule
**Code Freeze:** Wednesday, September 7th, 2022
**Tagging Deadline:** Monday, September 12th, 2022
**Public Release:** Wednesday, September 21st, 2022
## Documentation Review Links
**Closed issues assigned to the...## Release Schedule
**Code Freeze:** Wednesday, September 7th, 2022
**Tagging Deadline:** Monday, September 12th, 2022
**Public Release:** Wednesday, September 21st, 2022
## Documentation Review Links
**Closed issues assigned to the milestone without a release note:**
- [9.19.5](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.19)
- [9.18.7](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.18)
- [9.16.33](https://gitlab.isc.org/isc-projects/bind9/-/issues/?sort=created_asc&state=closed&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29¬%5Blabel_name%5D%5B%5D=Release%20Notes¬%5Blabel_name%5D%5B%5D=Duplicate&label_name%5B%5D=v9.16)
**Merge requests merged into the milestone without a release note:**
- [9.19.5](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29¬[label_name][]=Release%20Notes&target_branch=main)
- [9.18.7](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29¬[label_name][]=Release%20Notes&target_branch=v9_18)
- [9.16.33](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29¬[label_name][]=Release%20Notes&target_branch=v9_16)
**Merge requests merged into the milestone without a `CHANGES` entry:**
- [9.19.5](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29&label_name[]=No%20CHANGES&target_branch=main)
- [9.18.7](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29&label_name[]=No%20CHANGES&target_branch=v9_18)
- [9.16.33](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests?sort=merged_at&state=merged&milestone_title=September%202022%20%289.16.33,%209.16.33-S1,%209.18.7,%209.19.5%29&label_name[]=No%20CHANGES&target_branch=v9_16)
## 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.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to disallow merging to them.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is in effect.
### Before the Tagging Deadline
- [x] ***(QA)*** Ensure release notes are correct, ask Support and Marketing to check them as well.
- [x] ***(QA)*** Add a release marker to `CHANGES`.
- [x] ***(QA)*** Add a release marker to `CHANGES.SE` (Subscription Edition only).
- [x] ***(QA)*** Update BIND 9 version in `configure.ac` (9.18+) or `version` (9.16).
- [x] ***(QA)*** Rebuild `configure` using Autoconf on `docs.isc.org` (9.16).
- [x] ***(QA)*** Tag the releases in the private repository (`git tag -s -m "BIND 9.x.y" v9_x_y`).
### Before the ASN Deadline (for ASN Releases) or the Public Release Date (for Regular Releases)
- [x] ***(QA)*** Check that the formatting is correct for HTML and PDF versions of release notes.
- [x] ***(QA)*** Check that the formatting of the generated man pages is correct.
- [x] ***(QA)*** Verify GitLab CI results for the tags created and sign off on the releases to be published.
- [x] ***(QA)*** Update GitLab settings for all maintained branches to allow merging to them again.
- [x] ***(QA)*** Prepare and merge MRs resetting the release notes and updating the version string for each maintained branch.
- [x] ***(QA)*** Announce (on Mattermost) that the code freeze is over.
- [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 (update the -S edition delivery tickets, even if those links were provided earlier via an ASN ticket).
- [x] ***(Support)*** Update tickets in case of waiting support customers.
- [x] ***(QA)*** Build and test any outstanding private packages.
- [x] ***(QA)*** Build public RPMs.
- [x] ***(SwEng)*** Build Debian/Ubuntu packages.
- [x] ***(SwEng)*** Update Docker images.
- [x] ***(QA)*** Inform Marketing of the release.
- [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] ***(QA)*** Push tags for the published releases to the public repository.
- [x] ***(QA)*** Merge published release tags (non-linearly) back into the their relevant development/maintenance branches.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to the current release milestone and do not describe a security vulnerability, then make them public.
- [x] ***(QA)*** Sanitize confidential issues which are assigned to older release milestones and describe security vulnerabilities, then make them public if appropriate[^2].
- [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]: As a rule of thumb, security vulnerabilities which have reproducers merged to the public repository are considered okay for full disclosure.September 2022 (9.16.33, 9.16.33-S1, 9.18.7, 9.19.5)Michał KępieńMichał Kępień2022-09-21https://gitlab.isc.org/isc-projects/stork/-/issues/852Sanity checks for Stork 1.6.0 rc22022-09-08T10:05:42ZMarcin GodzinaSanity checks for Stork 1.6.0 rc2We are now at step SANITY CHECKS of Stork 1.6.0 rc2.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
1. Get the deb & rpm pack...We are now at step SANITY CHECKS of Stork 1.6.0 rc2.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
1. Get the deb & rpm packages, place them in the tarball location, run tests with `rake system_tests` and `rake system_tests_ui`.
1. Start demo locally with `rake demo:up` and follow the steps from the demo wiki: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
1. Install server and agent locally e.g. in VMs from deb & rpm packages
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is. This way we know what is covered upfront and we can avoid repeating ourselves.
```
* tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/2743231/artifacts/browse
* apk & deb & rpm packages: https://gitlab.isc.org/isc-projects/stork/-/jobs/2743235/artifacts/browse
```1.6https://gitlab.isc.org/isc-projects/stork/-/issues/850Sanity checks for Stork 1.6.0 rc12022-09-08T10:05:12ZMarcin GodzinaSanity checks for Stork 1.6.0 rc1We are now at step SANITY CHECKS of Stork 1.6.0 rc1.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
1. Get the deb & rpm pack...We are now at step SANITY CHECKS of Stork 1.6.0 rc1.
Please do sanity checks according to the steps below:
1. Get the tarball and check it, run tests with `rake unittest:backend` or `rake unittest:backend_db`.
1. Get the deb & rpm packages, place them in the tarball location, run tests with `rake system_tests` and `rake system_tests_ui`.
1. Start demo locally with `rake demo:up` and follow the steps from the demo wiki: https://gitlab.isc.org/isc-projects/stork/-/wikis/Demo
1. Install server and agent locally e.g. in VMs from deb & rpm packages
Before starting, please state what you are checking in a thread/discussion (not as comment).
When you finish a check, state in the same thread/discussion what the result is. This way we know what is covered upfront and we can avoid repeating ourselves.
```
* tarball: https://gitlab.isc.org/isc-projects/stork/-/jobs/2740406/artifacts/browse
* apk & deb & rpm packages: https://gitlab.isc.org/isc-projects/stork/-/jobs/2740410/artifacts/browse
```1.6https://gitlab.isc.org/isc-projects/stork/-/issues/8441.6.0. release version bump2022-09-05T18:45:15ZMarcin Godzina1.6.0. release version bump1.6Marcin GodzinaMarcin Godzinahttps://gitlab.isc.org/isc-projects/stork/-/issues/812Manually provided DHCP option in host reservation form produces backend error2022-08-30T12:02:17ZSlawek FigielManually provided DHCP option in host reservation form produces backend errorThe issue found during the 1.5 sanity checks [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/808#note_300620)
Providing option code by hand in the host reservation form causes GO unmarshal error. Selecting the option code fr...The issue found during the 1.5 sanity checks [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/808#note_300620)
Providing option code by hand in the host reservation form causes GO unmarshal error. Selecting the option code from the dropdown works well, the option is forwarded to the Kea.
Error:
```
Cannot commit new host
The transaction adding new host failed: parsing host body from "" failed, because json: cannot unmarshal string into Go struct field DHCPOption.localHosts.options.code of type int64
```
Parameters to reproduce:
* Global reservation: true
* DHCP Servers: kea@agent-kea-premium/dhcp6
* DHCP Identifier: flex-id / text / xa<zsc
* IP Reservations: IPv6 address / 2001:db8:1::2
* DHCP options:
* Option code: 92 (manually provided)
* Payload: hex-bytes 1234451.6Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/802System tests fail on none config reports2022-08-23T10:34:07ZSlawek FigielSystem tests fail on none config reportsRefers to: `test_get_dhcp4_config_review_reports` test case.
The Stork Server returns HTTP 204 No Content status if the config review is not performed yet for a given daemon. It is correctly described in the Swagger YAML file. The serve...Refers to: `test_get_dhcp4_config_review_reports` test case.
The Stork Server returns HTTP 204 No Content status if the config review is not performed yet for a given daemon. It is correctly described in the Swagger YAML file. The server sends only HTTP status and no data in response.
Unfortunately, it seems that the Python OpenAPI client doesn't support No Content status and always expects that the config reviews will be included in the server response.
It causes the system tests may sporadically fail on listing the reviews. Additionally, we need a function to wait for complete review for a given daemon.1.6https://gitlab.isc.org/isc-projects/stork/-/issues/799stork-agent bind exporter frequently errors on named cwd detection2022-07-26T08:15:07ZJens Krabbenhoeftstork-agent bind exporter frequently errors on named cwd detection**Describe the bug**
We have added the stork-agent to standard ISC bind containers (`internetsystemsconsortium/bind9:9.18`) and run them side by side with the named process. While testing we found that every 10 seconds following error m...**Describe the bug**
We have added the stork-agent to standard ISC bind containers (`internetsystemsconsortium/bind9:9.18`) and run them side by side with the named process. While testing we found that every 10 seconds following error messages get created (where 8 is the named pid):
```
time="2022-07-04 06:56:31" level="warning" msg="Cannot get process current working directory: readlink /proc/8/cwd: permission denied" file=" monitor.go:213 "
time="2022-07-04 06:56:41" level="warning" msg="Cannot get process current working directory: readlink /proc/8/cwd: permission denied" file=" monitor.go:213 "
time="2022-07-04 06:56:51" level="warning" msg="Cannot get process current working directory: readlink /proc/8/cwd: permission denied" file=" monitor.go:213 "
time="2022-07-04 06:57:01" level="warning" msg="Cannot get process current working directory: readlink /proc/8/cwd: permission denied" file=" monitor.go:213 "
time="2022-07-04 06:57:11" level="warning" msg="Cannot get process current working directory: readlink /proc/8/cwd: permission denied" file=" monitor.go:213 "
time="2022-07-04 06:57:21" level="warning" msg="Cannot get process current working directory: readlink /proc/8/cwd: permission denied" file=" monitor.go:213 "
```
**Expected behavior**
No error message gets logged.
**Additional Information**
There is a bug for the same error message in issue #274 - unfortunately the solution setting CAP_SYS_PTRACE does not work on unprivileged docker containers. cwd is not readable unless starting the container privileged (and cap_sys_ptrace is not working on unprivileged containers either).
**Environment:**
- BIND9 version: 9.18.4-1+ubuntu22.04.1+isc+1
- Stork: 1.4.0
- OS: Ubuntu 22.04 LTS (docker container `internetsystemsconsortium/bind9:9.18`)1.6