ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2021-05-24T13:55:09Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2689CID 331477: Resource leaks (RESOURCE_LEAK)2021-05-24T13:55:09ZMichal NowakCID 331477: Resource leaks (RESOURCE_LEAK)This seems to be a result of fa05c1b8da1ee9dfe5b005a00edf8178c2e884d4:
```
*** CID 331477: Resource leaks (RESOURCE_LEAK)
/lib/dns/dst_api.c: 653 in dst_key_fromnamedfile()
647 return (ISC_R_SUCCESS);
648 }
649
650 ...This seems to be a result of fa05c1b8da1ee9dfe5b005a00edf8178c2e884d4:
```
*** CID 331477: Resource leaks (RESOURCE_LEAK)
/lib/dns/dst_api.c: 653 in dst_key_fromnamedfile()
647 return (ISC_R_SUCCESS);
648 }
649
650 result = algorithm_status(pubkey->key_alg);
651 if (result != ISC_R_SUCCESS) {
652 dst_key_free(&pubkey);
>>> CID 331477: Resource leaks (RESOURCE_LEAK)
>>> Variable "statefilename" going out of scope leaks the storage it points to.
653 return (result);
654 }
655
656 key = get_key_struct(pubkey->key_name, pubkey->key_alg,
657 pubkey->key_flags, pubkey->key_proto,
658 pubkey->key_size, pubkey->key_class,
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2690Remove Windows support for BIND 9.17/9.18+2022-01-21T13:43:04ZOndřej SurýRemove Windows support for BIND 9.17/9.18+This is a tracking issue to remove the Windows port from BIND 9 source code for the next stable release.This is a tracking issue to remove the Windows port from BIND 9 source code for the next stable release.July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2691Remove native PKCS#11 support from BIND 9.17/9.18+2022-01-19T11:20:49ZOndřej SurýRemove native PKCS#11 support from BIND 9.17/9.18+This a tracking issue to remove the native PKCS#11 implementation from BIND 9 source code (including the documentation).This a tracking issue to remove the native PKCS#11 implementation from BIND 9 source code (including the documentation).October 2021 (9.11.36, 9.11.36-S1, 9.16.22, 9.16.22-S1, 9.17.19)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/stork/-/issues/543Issue with self-signed TLS certificates2023-03-08T12:02:34ZDavid YaffeIssue with self-signed TLS certificates---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/...---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org.
**Describe the bug**
I'm using stork as part of a managed environment with Red Hat's IDM (FreeIPA) handling certificate for the internal network. Using self-signed certificates with Stork does not allow TLS connections with web browsers. Using the same certificates with other applications on the same server works. Hostnames/domain names changed to protect the innocent.
**To Reproduce**
Steps to reproduce the behavior:
1. Using Kea, Bind9 and Stork:
1. isc-stork-agent.x86_64 - 0.17.0.210507080500-1
2. isc-stork-server.x86_64 - 0.17.0.210507080500-1
3. kea.x86_64 - 1.9.4-1.fc34
4. bind.x86_64 - 32:9.16.15-1.fc34
2. Generate a self signed certificate. I'm using Red Hat's Dogtag / IDM system to generate the certificates
instructions: https://blog.christophersmart.com/2014/08/24/creating-certs-and-keys-for-services-using-freeipa-dogtag/
3. Configure the Stork server:
```bash
# database settings
STORK_DATABASE_HOST=localhost
STORK_DATABASE_PORT=5432
STORK_DATABASE_NAME=stork
STORK_DATABASE_USER_NAME=stork
# empty password is set to avoid prompting user for password to database
STORK_DATABASE_PASSWORD="<redacted>"
# ReST API settings
STORK_REST_HOST=192.168.1.2
STORK_REST_PORT=8067
STORK_REST_TLS_CERTIFICATE=/etc/stork/stork.pem
STORK_REST_TLS_PRIVATE_KEY=/etc/stork/tork.key
STORK_REST_TLS_CA_CERTIFICATE=/usr/share/ipa/html/ca.crt
STORK_REST_STATIC_FILES_DIR=/usr/share/stork/www
```
5. Stork starts normally, but returns an certificate error when attempting to open the website.
6. curl -vvv https://192.168.1.2 display the following:
```bash
$ curl -vvv https://ipa-01.example.com:8067
* Trying 192.168.1.2:8067...
* Connected to ipa-01.example.com (192.168.1.2) port 8067 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Request CERT (13):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS handshake, Certificate (11):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server accepted to use h2
* Server certificate:
* subject: O=EXAMPLE.COM; CN=ipa-01.example.com
* start date: May 3 01:42:46 2021 GMT
* expire date: May 4 01:42:46 2023 GMT
* subjectAltName: host "ipa-01.example.com" matched cert's "ipa-01.example.com"
* issuer: O=EXAMPLE.COM; CN=Certificate Authority
* SSL certificate verify ok.
* Using HTTP2, server supports multi-use
* Connection state changed (HTTP/2 confirmed)
* Copying HTTP/2 data in stream buffer to connection buffer after upgrade: len=0
* OpenSSL SSL_write: Broken pipe, errno 32
* Failed sending HTTP2 data
* Connection #0 to host ipa-01.example.com left intact
curl: (16) OpenSSL SSL_write: Broken pipe, errno 32
```
7. The same certificates on the same server produce no errors when used with another application (prometheus):
$ curl -vvv https://ipa-01.example.com:9000/metrics
* Trying 192.168.1.2:9000...
* Connected to ipa-01.example.com (192.168.1.2) port 9000 (#0)
* ALPN, offering h2
* ALPN, offering http/1.1
* successfully set certificate verify locations:
* CAfile: /etc/pki/tls/certs/ca-bundle.crt
* CApath: none
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
* TLSv1.3 (IN), TLS handshake, Server hello (2):
* TLSv1.3 (IN), TLS handshake, Encrypted Extensions (8):
* TLSv1.3 (IN), TLS handshake, Certificate (11):
* TLSv1.3 (IN), TLS handshake, CERT verify (15):
* TLSv1.3 (IN), TLS handshake, Finished (20):
* TLSv1.3 (OUT), TLS change cipher, Change cipher spec (1):
* TLSv1.3 (OUT), TLS handshake, Finished (20):
* SSL connection using TLSv1.3 / TLS_AES_128_GCM_SHA256
* ALPN, server did not agree to a protocol
* Server certificate:
* subject: O=EXAMPLE.COM; CN=ipa-01.example.com
* start date: May 3 01:42:46 2021 GMT
* expire date: May 4 01:42:46 2023 GMT
* subjectAltName: host "ipa-01.example.com" matched cert's "ipa-01.example.com"
* issuer: O=EXAMPLE.COM; CN=Certificate Authority
* SSL certificate verify ok.
> GET /metrics HTTP/1.1
> Host: ipa-01.example.com:9000
> User-Agent: curl/7.76.1
> Accept: */*
>
* TLSv1.3 (IN), TLS handshake, Newsession Ticket (4):
* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Content-Type: text/plain; version=0.0.4; charset=utf-8
< Date: Tue, 11 May 2021 16:03:10 GMT
< Transfer-Encoding: chunked
<
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 3.5531e-05
go_gc_duration_seconds{quantile="0.25"} 0.000102564
go_gc_duration_seconds{quantile="0.5"} 0.00013617
go_gc_duration_seconds{quantile="0.75"} 0.000168258
go_gc_duration_seconds{quantile="1"} 0.000635662
go_gc_duration_seconds_sum 0.146570868
go_gc_duration_seconds_count 1063
**Expected behavior**
Secured TLS connections with Stork.
**Environment:**
- OS Fedora 34 and RHEL 8.3
- isc-stork-agent.x86_64 - 0.17.0.210507080500-1
- isc-stork-server.x86_64 - 0.17.0.210507080500-1
- kea.x86_64 - 1.9.4-1.fc34
- bind.x86_64 - 32:9.16.15-1.fc34
Stork is from the official repositories
**Additional Information**
Kea is working as expected, as is named/bind9. I have not tested certificates with a full subject. I can easily regenerate the certificate with the full subject if required.
**Describe the solution you'd like**
Self signed certificates to work with stork1.10Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/580Error while reading host reservations2021-11-03T10:14:38ZFabian KretschmerError while reading host reservationsHi,
we are facing a problem reading the host reservations in Stork 0.19.0 with the kea premium hook host_cmds library (tested with compiled kea 1.8.2 and 1.9.11).
Using the API, multiple hosts reservations were successfully added to a M...Hi,
we are facing a problem reading the host reservations in Stork 0.19.0 with the kea premium hook host_cmds library (tested with compiled kea 1.8.2 and 1.9.11).
Using the API, multiple hosts reservations were successfully added to a MySQL database backend. The Library is successfully loaded, the kea server is registered in stork and the agent is running, so everything looks fine until here.
At the DHCP host reservation page in stork no reservations are displayed. At this time, an Error is logged in stork and kea, please have a look at the logs below. In both Kea versions they are looking the same and the error is reproducible.
Please let me know, if you need any additional informations, any help would be appreciated.
Kind regards,
Fabian
**Environment:**
- Kea version: 1.8.2 / 1.9.11 with Stork 0.19.0
- OS: Ubuntu 18.04 Docker Container
- Which hooks where loaded in: libdhcp_host_cmds.so, libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Logs:**
The reservation-add command logs looks like:
```
INFO COMMAND_RECEIVED Received command 'reservation-add'
INFO HOST_CMDS_RESERV_ADD reservation-add command successful (parameters: { "reservation": { "boot-file-name": "bootfile.efi", "hostname": "HOST1", "hw-address": "00:11:22:33:44:55", "ip-address": "192.168.10.100", "subnet-id": 10, "user-context": "{key': 'value'}" } })
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-add successfully forwarded to the service dhcp4
```
Kea Server:
`ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $reservation_get_page registered by library with index 3 (callout address 0x7ff88302e410) (callout duration 18.124 ms)`
Stork Server:
```
INFO[2021-09-03 07:38:44] eventcenter.go:117 event 'communication with <daemon id="12" name="dhcp4" appId="3" appType="kea"> of <app id="3" name="kea@172.17.0.3" type="kea" version="1.9.11"> failed'
ERRO[2021-09-03 07:38:44] host.go:87 error occurred while fetching hosts from app 3: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 07:38:44] host.go:100 completed pulling hosts from Kea apps: 0/1 succeeded
ERRO[2021-09-03 07:38:44] puller.go:172 errors were encountered while pulling data from apps: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 06:37:47] eventcenter.go:117 event 'communication with <daemon id="3" name="dhcp4" appId="1" appType="kea"> of <app id="1" name="kea@172.17.0.3" type="kea" version="1.8.2"> failed'
ERRO[2021-09-03 06:37:47] host.go:87 error occurred while fetching hosts from app 1: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
INFO[2021-09-03 06:37:47] host.go:100 completed pulling hosts from Kea apps: 0/1 succeeded
ERRO[2021-09-03 06:37:47] puller.go:172 errors were encountered while pulling data from apps: error returned by Kea in response to reservation-get-page command
isc.org/stork/server/apps/kea.(*HostDetectionIterator).sendReservationGetPage
/tmp/build/backend/server/apps/kea/host.go:254
isc.org/stork/server/apps/kea.(*HostDetectionIterator).DetectHostsPageFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:356
isc.org/stork/server/apps/kea.updateHostsFromHostCmds
/tmp/build/backend/server/apps/kea/host.go:536
isc.org/stork/server/apps/kea.(*HostsPuller).pullData
/tmp/build/backend/server/apps/kea/host.go:84
isc.org/stork/server/agentcomm.(*PeriodicPuller).pullerLoop
/tmp/build/backend/server/agentcomm/puller.go:169
runtime.goexit
/tmp/build/tools/1.15.5/go/src/runtime/asm_amd64.s:1374
problem with sending reservation-get-page command upon attempt to detect host reservations over the host_cmds hooks library
```
Edit: Here's a more verbose (debuglevel 99) output from the kea server:
```
WARN[2021-09-07 13:32:42] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.581 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED deleted 0 reclaimed leases from the database
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 128 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_get_page
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 3 has called a callout on hook $reservation_get_page that has address 0x7f176473c4a0 (callout duration: 4.296 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_get_page (total callouts duration: 4.296 ms)
DEBUG COMMAND_SOCKET_WRITE Sent response of 92 bytes (0 bytes left to send) over command socket 23
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-get-page successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 96 B to 108 B, ratio 112%
INFO COMMAND_RECEIVED Received command 'stat-lease4-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 56 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'stat-lease4-get'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $stat_lease4_get
INFO STAT_CMDS_LEASE4_GET stat-lease4-get command successful, parameters: [all subnets] rows found: 1
DEBUG HOOKS_CALLOUT_CALLED hooks library with index 2 has called a callout on hook $stat_lease4_get that has address 0x7f17649600c0 (callout duration: 0.431 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $stat_lease4_get (total callouts duration: 0.431 ms)
INFO CTRL_AGENT_COMMAND_FORWARDED command stat-lease4-get successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_WRITE Sent response of 303 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 307 B to 212 B, ratio 69%
INFO COMMAND_RECEIVED Received command 'statistic-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 96 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 90 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 94 B to 110 B, ratio 117%
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 129 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'reservation-get-page'
DEBUG HOOKS_CALLOUTS_BEGIN begin all callouts for hook $reservation_get_page
ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook 3 registered by library with index $reservation_get_page (callout address 0x7f176473c4a0) (callout duration 15.274 ms)
DEBUG HOOKS_CALLOUTS_COMPLETE completed callouts for hook $reservation_get_page (total callouts duration: 15.274 ms)
INFO CTRL_AGENT_COMMAND_FORWARDED command reservation-get-page successfully forwarded to the service dhcp4
DEBUG COMMAND_SOCKET_WRITE Sent response of 657 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO[2021-09-07 13:32:50] agent.go:375 Compressing response from 661 B to 365 B, ratio 55%
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:32:52] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 1.478 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'version-get'
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 116 B to 125 B, ratio 107%
INFO COMMAND_RECEIVED Received command 'config-get'
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 683 B to 314 B, ratio 45%
INFO COMMAND_RECEIVED Received command 'version-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 67 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'version-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 205 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command version-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 482 B to 273 B, ratio 56%
INFO COMMAND_RECEIVED Received command 'status-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 60 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'status-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 107 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command status-get successfully forwarded to the service dhcp4
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 249 B to 196 B, ratio 78%
INFO COMMAND_RECEIVED Received command 'config-get'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 66 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'config-get'
DEBUG COMMAND_SOCKET_WRITE Sent response of 3167 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command config-get successfully forwarded to the service dhcp4
WARN[2021-09-07 13:32:59] kea.go:69 skipped refreshing viewable log files because config-get returned non success result
WARN[2021-09-07 13:32:59] kea.go:69 skipped refreshing viewable log files because config-get returned non success result
INFO[2021-09-07 13:32:59] agent.go:375 Compressing response from 3444 B to 1296 B, ratio 37%
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:02] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.633 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:12] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: flush-reclaimed-leases
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE begin deletion of reclaimed leases expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETE_EXPIRED_RECLAIMED4 deleting reclaimed IPv4 leases that expired more than 3600 seconds ago
DEBUG DHCPSRV_MYSQL_DELETED_EXPIRED_RECLAIMED deleted 0 reclaimed leases from the database
DEBUG ALLOC_ENGINE_V4_RECLAIMED_LEASES_DELETE_COMPLETE successfully deleted 0 expired-reclaimed leases
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: flush-reclaimed-leases
DEBUG DHCPSRV_TIMERMGR_RUN_TIMER_OPERATION running operation for timer: reclaim-expired-leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_START starting reclamation of expired leases (limit = 100 leases or 250 milliseconds)
DEBUG DHCPSRV_MYSQL_GET_EXPIRED4 obtaining maximum 101 of expired IPv4 leases
DEBUG ALLOC_ENGINE_V4_LEASES_RECLAMATION_COMPLETE reclaimed 0 leases in 0.626 ms
DEBUG ALLOC_ENGINE_V4_NO_MORE_EXPIRED_LEASES all expired leases have been reclaimed
DEBUG DHCPSRV_TIMERMGR_START_TIMER starting timer: reclaim-expired-leases
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_CONNECTION_OPENED Opened socket 23 for incoming command connection
DEBUG COMMAND_SOCKET_READ Received 86 bytes over command socket 23
INFO COMMAND_RECEIVED Received command 'statistic-get-all'
DEBUG COMMAND_SOCKET_WRITE Sent response of 1759 bytes (0 bytes left to send) over command socket 23
DEBUG COMMAND_SOCKET_CONNECTION_CLOSED Closed socket 23 for existing command connection
INFO CTRL_AGENT_COMMAND_FORWARDED command statistic-get-all successfully forwarded to the service dhcp4
WARN[2021-09-07 13:33:22] promkeaexporter.go:368 problem with connecting to dhcp daemon: unable to forward command to the dhcp6 service: No such file or directory. The server is likely to be offline
```0.22https://gitlab.isc.org/isc-projects/stork/-/issues/544Include Grafana dashboard json files in the official RPM packages.2021-06-01T06:40:52ZDavid YaffeInclude Grafana dashboard json files in the official RPM packages.---
name: Feature request
about: Add Grafana dashboards to RPMs
---
**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms?
- Stork is in very early stages of development. If you...---
name: Feature request
about: Add Grafana dashboards to RPMs
---
**Some initial questions**
- Are you sure what you would like to do is not possible using some other mechanisms?
- Stork is in very early stages of development. If your request is not simple, it
may be a while until anyone does anything with your request. Are you ok with that?
**Is your feature request related to a problem? Please describe.**
This will save effort to install the packages on systems which are not directly connected to the internet.
**Describe the solution you'd like**
include the Grafana dashboard json configuration files in the official RPM packages.
**Describe alternatives you've considered**
manually downloading from gitlab.
**Additional context**
Include the configuration files from the /grafana directory in the RPM packages:
- bind9-resolver.json
- kea-dhcp4.json
- kea-dhcp6.json
The files could be included in /usr/share/stork/examples/grafana.
I'm assuming the same issue will exist for other packages e.g. deb packages.0.18Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1866segfault on parameter-less forensic logging2021-05-19T14:26:22ZAndrei Pavelandrei@isc.orgsegfault on parameter-less forensic loggingWhen configuring kea-dhcp[46] with a forensic logging without a "parameters" field, it segfaults.
```json
"hooks-libraries": [
{
"library": "libdhcp_legal_log.so"
}
]
```
`
kea-dhcp6: /usr/include/boost/smar...When configuring kea-dhcp[46] with a forensic logging without a "parameters" field, it segfaults.
```json
"hooks-libraries": [
{
"library": "libdhcp_legal_log.so"
}
]
```
`
kea-dhcp6: /usr/include/boost/smart_ptr/shared_ptr.hpp:728: typename boost::detail::sp_member_access<T>::type boost::shared_ptr<T>::operator->() const [with T = isc::legal_log::BackendStore; typename boost::detail::sp_member_access<T>::type = isc::legal_log::BackendStore*]: Assertion 'px != 0' failed.
`
`
#4 0x00007ffff34e1cf5 in boost::shared_ptr<isc::legal_log::BackendStore>::operator-> (this=0x7ffff3558250 <isc::legal_log::BackendStore::instance()::backend_store>) at /usr/include/boo
st/smart_ptr/shared_ptr.hpp:728
#5 0x00007ffff34decf1 in load (handle=...) at load_unload.cc:52
`
This used to work in 1.9.7.
This is also why system tests are failing on Jenkins.
`parameters` is checked on the first line of `BackendStore::parseFile()`, it returns on null, and the backend store is not instantiated further down below.
```cpp
void
BackendStore::parseFile(const ConstElementPtr& parameters) {
if (!parameters) {
return;
}
[..]
BackendStore::instance().reset(new RotatingFile(path, base, unit, count,
prerotate, postrotate));
}
```kea1.9.8Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/1867update example configs in ARM to not use auto-assigned subnet IDs2022-11-02T15:10:19ZVicky Riskvicky@isc.orgupdate example configs in ARM to not use auto-assigned subnet IDsapparently we don't want people to use the automatically assigned subnet IDs so
please update the examples in the arm to add subnet-ID parametersapparently we don't want people to use the automatically assigned subnet IDs so
please update the examples in the arm to add subnet-ID parametersbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1836dhcp-server-identifier in client class scope2022-09-01T13:02:51ZMaria Hrabosovadhcp-server-identifier in client class scopeI tried to configure _dhcp-server-identifier_ in the client class scope but the server didn't send an ACK. Instead it dropped the DHCP request complaining that "it contains a foreign server identifier". After that, I found in the documen...I tried to configure _dhcp-server-identifier_ in the client class scope but the server didn't send an ACK. Instead it dropped the DHCP request complaining that "it contains a foreign server identifier". After that, I found in the documentation that "this option is only supported at the global, shared network, and subnet levels; it must not be specified on the client class or host reservation levels".
I think that when it is not supported in client classes, Kea should complain during the validation of the configuration so that the users know right away that they shouldn't use the option in this scope.
Or even better, it would be great if you could add the support in this scope so that we could use _dhcp-server-identifier_ for PXE boot the same way as we did in client groups in ISC DHCP.kea1.9.9Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2692grep from FreeBSD 13.0 stumbles on '\r' in digdelv test2021-05-17T11:38:35ZMichal Nowakgrep from FreeBSD 13.0 stumbles on '\r' in digdelv testgrep from FreeBSD 13.0 stumbles on `\r` in the digdelv system test:
```
I:digdelv:check that dig +bufsize=0 +edns sends EDNS with bufsize of 0 (81)
grep: trailing backslash (\)
I:digdelv:failed
```
This is because, according to FreeBSD 1...grep from FreeBSD 13.0 stumbles on `\r` in the digdelv system test:
```
I:digdelv:check that dig +bufsize=0 +edns sends EDNS with bufsize of 0 (81)
grep: trailing backslash (\)
I:digdelv:failed
```
This is because, according to FreeBSD 13.0 [release notes](https://www.freebsd.org/releases/13.0R/relnotes/), FreeBSD 13.0 uses BSD grep instead of GNU grep:
> The BSD version of grep(1) is now installed by default. The obsolete GNU version that was the previous default has been removed. 8aff76fb37b5, 47d1ad2413da
Which also recently dropped support for escape codes:
> The regex(3) function no longer accepts redundant escapes for most ordinary characters. This will cause applications such as sed(1) and grep(1) to reject regular expressions using these escapes. adeebf4cd47c
```
[newman@freebsd13 ~/bind9/bin/tests/system]$ grep -E 'EDNS:.* udp: 0\r{0,1}$' digdelv/dig.out.test81
grep: trailing backslash (\)
[newman@freebsd13 ~/bind9/bin/tests/system]$ /usr/local/bin/grep -E 'EDNS:.* udp: 0\r{0,1}$' digdelv/dig.out.test81
; EDNS: version: 0, flags:; udp: 0
```
`grep` from FreeBSD [11.4](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1710615#L3401) and [12.2](https://gitlab.isc.org/isc-projects/bind9/-/jobs/1710616#L3486) does not exhibit this problem, because it's actually GNU grep 2.5.
This appears to be the fix:
```patch
diff --git a/bin/tests/system/digdelv/tests.sh b/bin/tests/system/digdelv/tests.sh
index 099e08e87e..9d1f5171d5 100644
--- a/bin/tests/system/digdelv/tests.sh
+++ b/bin/tests/system/digdelv/tests.sh
@@ -975,7 +975,8 @@ if [ -x "$DIG" ] ; then
echo_i "check that dig +bufsize=0 +edns sends EDNS with bufsize of 0 ($n)"
ret=0
dig_with_opts @10.53.0.3 a.example +bufsize=0 +edns +qr > dig.out.test$n 2>&1 || ret=1
- grep -E 'EDNS:.* udp: 0\r{0,1}$' dig.out.test$n > /dev/null|| ret=1
+ pat='EDNS:.* udp: 0{0,1}$'
+ tr -d '\r' < dig.out.test$n | grep -E "$pat" > /dev/null || ret=1
if [ $ret -ne 0 ]; then echo_i "failed"; fi
status=$((status+ret))
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2693Add py.test to the list of tested pytest names2021-05-17T09:30:35ZMichal NowakAdd py.test to the list of tested pytest namespytest is not being detected on OpenBSD 6.9:
```
checking for pytest-3... no
checking for py.test-3... no
checking for pytest... no
checking for pytest-pypy... no
configure: WARNING: pytest not found, some system tests will be skipped
``...pytest is not being detected on OpenBSD 6.9:
```
checking for pytest-3... no
checking for py.test-3... no
checking for pytest... no
checking for pytest-pypy... no
configure: WARNING: pytest not found, some system tests will be skipped
```
It works for OpenBSD 6.8:
```
checking for pytest-3... no
checking for py.test-3... /usr/local/bin/py.test-3
```
It seems that pytest was renamed from `py.test-3` to `py.test`. (This might be the [change](https://github.com/openbsd/ports/commit/248932be7402afca2547890b0036909453504f48).)
The `configure.ac` check needs to be updated to detect `py.test`:
```
checking for pytest-3... no
checking for py.test... /usr/local/bin/py.test
```
This works:
```patch
diff --git a/configure.ac b/configure.ac
index 2518969534..9157c8bc01 100644
--- a/configure.ac
+++ b/configure.ac
@@ -303,7 +303,7 @@ AM_CONDITIONAL([HAVE_PERLMOD_TIME_HIRES],
AM_PATH_PYTHON([3.4], [], [:])
AM_CONDITIONAL([HAVE_PYTHON], [test "$PYTHON" != ":"])
-AC_PATH_PROGS([PYTEST], [pytest-3 py.test-3 pytest pytest-pypy], [])
+AC_PATH_PROGS([PYTEST], [pytest-3 py.test py.test-3 pytest pytest-pypy], [])
AS_IF([test -z "$PYTEST"],
[AC_MSG_WARN([pytest not found, some system tests will be skipped])])
AC_SUBST([PYTEST])
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2694Drop seq command from views/tests.sh2021-05-19T14:56:20ZMichal NowakDrop seq command from views/tests.sh`seq` is not present on OpenBSD and should be replaced with something else.
```
bin/tests/system/views/tests.sh:for i in `seq 1 50`; do
````seq` is not present on OpenBSD and should be replaced with something else.
```
bin/tests/system/views/tests.sh:for i in `seq 1 50`; do
```June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Michal NowakMichal Nowakhttps://gitlab.isc.org/isc-projects/stork/-/issues/545add automation for creating qcow2 image used in CI for system testing2021-05-31T11:00:17ZMichal Nowikowskiadd automation for creating qcow2 image used in CI for system testing0.18Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/474test stork with latest bind9 (9.17.x)2021-05-24T10:24:07ZTomek Mrugalskitest stork with latest bind9 (9.17.x)There's a report #467 that complains about Stork 0.14 not working with bind 9.17.8. As of today, we're using an old bind 9.11.x in the stork demo. And that's probably about it how closely we test it.
The goal of this ticket to figure ou...There's a report #467 that complains about Stork 0.14 not working with bind 9.17.8. As of today, we're using an old bind 9.11.x in the stork demo. And that's probably about it how closely we test it.
The goal of this ticket to figure out how to test Stork with recent BIND9 versions.
One way (but certainly not the only one) is to update one of the containers we have in demo (there are two: agent-bind9 and agent-bind9-2) to use the latest bind version.
Whatever the testing practice is, it should be reasonably easy to update the bind version. The overall goal is to keep up with the reasonably latest BIND releases.
Another potential explanation for the issues in #467 is that the demo used native packages provided by Ubuntu. The submitter of #467 seems to have used BIND9 packages provided by ISC.0.18Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/1869Design relay daemon in Kea2022-05-24T22:43:14ZTomek MrugalskiDesign relay daemon in KeaAs of June 2021, Kea provides the DHCP server functionality, with relay agent and client functionalities missing. The client likely never going to happen, but with relay there is some possibility. At this time, we would love to get some...As of June 2021, Kea provides the DHCP server functionality, with relay agent and client functionalities missing. The client likely never going to happen, but with relay there is some possibility. At this time, we would love to get some feedback from potential users and customers who are interested in the relay functionality. Please post your thoughts here.
In particular, details about your deployment use cases are most useful. Most people assume that the relay functionality is provided by hardware routers and switches and there's very limited need for software relay. Counter-arguments for this reasoning would be much appreciated.
Steps necessary:
- [ ] decide if there's a need for software relay
- [ ] write down requirements
- [ ] architecture design
- [ ] implement skeleton code
- [ ] implement relay functionality for v4
- [ ] implement relay functionality for v6outstandinghttps://gitlab.isc.org/isc-projects/bind9/-/issues/2695Launchpad PPA for Ubuntu 21.04 (Hirsute Hippo)2021-06-09T15:18:42ZTobias GüntherLaunchpad PPA for Ubuntu 21.04 (Hirsute Hippo)Similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/1294 and https://gitlab.isc.org/isc-projects/bind9/-/issues/1801 I would like to request the release in the repository for the now released Ubuntu 21.04 codenamed: "hirsute hi...Similar to https://gitlab.isc.org/isc-projects/bind9/-/issues/1294 and https://gitlab.isc.org/isc-projects/bind9/-/issues/1801 I would like to request the release in the repository for the now released Ubuntu 21.04 codenamed: "hirsute hippo"
Again, thanks for the great work!
Are these kind of "Issues" desired, or is this tracked already somewhere ?July 2021 (9.11.34, 9.11.34-S1, 9.16.19, 9.16.19-S1, 9.17.16)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/bind9/-/issues/2696Misleading diagnostic in update_soa_serial indicates BIND will use increment ...2021-05-24T13:58:17ZJP MensMisleading diagnostic in update_soa_serial indicates BIND will use increment but it doesn'tIt seems to me there's a misleading (or inaccurate) diagnostic reported by BIND 9.17.11 configured with inline-signing:
```
zone "example" IN {
type master;
file "example";
auto-dnssec maintain;
inline-s...It seems to me there's a misleading (or inaccurate) diagnostic reported by BIND 9.17.11 configured with inline-signing:
```
zone "example" IN {
type master;
file "example";
auto-dnssec maintain;
inline-signing yes;
serial-update-method date;
};
```
Upon launching named in the foreground (`named -g`) it reports the new serial would be lower than old serial, but I don't see that occurring.
Here named loads the unsigned zone with SOA serial `1`:
```
14-May-2021 12:46:23.485 zone example/IN (unsigned): loaded serial 1
14-May-2021 12:42:33.648 zone example/IN (signed): loaded serial 1
14-May-2021 12:42:33.649 zone example/IN (signed): receive_secure_serial: unchanged
14-May-2021 12:42:33.649 zone example/IN (signed): reconfiguring zone keys
14-May-2021 12:42:33.655 zone example/IN (signed): next key event: 14-May-2021 13:42:33.649
14-May-2021 12:42:33.662 zone example/IN (signed): update_soa_serial:new serial would be lower than old serial, using increment method instead
```
Querying the SOA, I see a reasonable-looking SOA serial:
```
example. 86400 IN SOA localhost. jp. 2021051401 10800 3600 604800 3600
```
When the unsigned zone is loaded with serial `2021051483`, the following diagnostic message is printed:
```
14-May-2021 12:44:41.265 zone example/IN (unsigned): loaded serial 2021051483
14-May-2021 12:44:41.266 zone example/IN (signed): loaded serial 2021051483
14-May-2021 12:44:41.267 zone example/IN (signed): receive_secure_serial: unchanged
14-May-2021 12:44:41.269 zone example/IN (signed): update_soa_serial:new serial would be lower than old serial, using increment method instead
14-May-2021 12:44:41.272 zone example/IN (signed): next key event: 14-May-2021 13:44:41.267
14-May-2021 12:44:41.279 zone example/IN (signed): update_soa_serial:new serial would be lower than old serial, using increment method instead
```
and querying that zone's SOA shows me:
```
example. 86400 IN SOA localhost. jp. 2021051485 10800 3600 604800 3600
```
In both cases the value I specified as SOA serial in the unsigned zone has been correctly set to a date.June 2021 (9.11.33, 9.11.33-S1, 9.16.17/9.16.18, 9.16.17-S1/9.16.18-S1, 9.17.14/9.17.15)Mark AndrewsMark Andrewshttps://gitlab.isc.org/isc-projects/bind9/-/issues/2697Further taskmgr refactoring2022-03-01T09:56:48ZOndřej SurýFurther taskmgr refactoringJust dumping notes/ideas:
* schedule events directly onto the worker loops, not tasks
* thus events will have to attach to task (or just reference count running events)
* as the last event schedule conditional task cleanup (move the logi...Just dumping notes/ideas:
* schedule events directly onto the worker loops, not tasks
* thus events will have to attach to task (or just reference count running events)
* as the last event schedule conditional task cleanup (move the logic from task_run there)
* use isc_queue_t to store task events instead of locked LIST to remove contention
This should further simplify the taskmgr logic.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/kea/-/issues/1873hammer: drop support for python2 in building kea packages2021-05-21T21:02:19ZMichal Nowikowskihammer: drop support for python2 in building kea packageskea1.9.8https://gitlab.isc.org/isc-projects/bind9/-/issues/2698Issues with cppcheck 2.4.1, 2.52022-01-11T14:25:31ZMichał KępieńIssues with cppcheck 2.4.1, 2.5cppcheck 2.4.1 is now available, but, while it fixes one of the issues
with cppcheck 2.3, it also introduces a new set of false positives we
would have to deal with. IMHO we should skip updating to this version
for the time being.
---
...cppcheck 2.4.1 is now available, but, while it fixes one of the issues
with cppcheck 2.3, it also introduces a new set of false positives we
would have to deal with. IMHO we should skip updating to this version
for the time being.
---
cppcheck 2.4.1 triggers the following type of false positives:
```
lib/isc/netaddr.c:274:8: warning: The address of local variable 'in' might be accessed at non-zero index. [objectIndex]
if (p[i] != 0xFF) {
^
lib/isc/netaddr.c:263:30: note: Address of variable taken here.
p = (const unsigned char *)&s->type.in;
^
lib/isc/netaddr.c:274:8: note: The address of local variable 'in' might be accessed at non-zero index.
if (p[i] != 0xFF) {
^
```
The affected files are:
- `bin/dnssec/dnssec-cds.c`
- `lib/dns/ecs.c`
- `lib/dns/resolver.c`
- `lib/isc/netaddr.c`
- `lib/ns/client.c`
It seems that cppcheck gets confused about data sizes when structure
pointers are explicitly cast.
Multiple upstream reports about similar issues are already opened:
- https://trac.cppcheck.net/ticket/10133
- https://trac.cppcheck.net/ticket/10213
- https://trac.cppcheck.net/ticket/10154
- https://trac.cppcheck.net/ticket/10156
None of the above problems have yet been resolved in cppcheck's `main`
branch, therefore I did not bother to create yet another upstream issue
for this. I suggest we wait and see what happens in future cppcheck
releases.
---
[Upstream commit c267d85640523c045c7d43ba7ce9c0f305423c5d][1] triggers
the following type of false positives:
```
lib/isc/base64.c:119:10: warning: Either the condition 'ctx->digits==4' is redundant or the array 'ctx->val[4]' is accessed at index 4, which is out of bounds. [arrayIndexOutOfBoundsCond]
ctx->val[ctx->digits++] = (int)(s - base64);
^
lib/isc/base64.c:120:18: note: Assuming that condition 'ctx->digits==4' is not redundant
if (ctx->digits == 4) {
^
lib/isc/base64.c:119:10: note: Array index out of bounds
ctx->val[ctx->digits++] = (int)(s - base64);
^
```
The affected files are:
- `lib/isc/base64.c`
- `lib/isc/base32.c`
- `lib/isc/hex.c`
I [reported this upstream][2] because it is still not addressed in
cppcheck's development branch.
[1]: https://github.com/danmar/cppcheck/commit/c267d85640523c045c7d43ba7ce9c0f305423c5d
[2]: https://sourceforge.net/p/cppcheck/discussion/general/thread/128272da00/January 2022 (9.16.25, 9.16.25-S1, 9.17.22)Michał KępieńMichał Kępień