ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-02-24T07:55:05Zhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4104ZoneQuota stats counter is not counting everything2024-02-24T07:55:05ZOndřej SurýZoneQuota stats counter is not counting everythingThe `ZoneQuota` should log all the hits to `fcount_incr()` returning `ISC_R_QUOTA`, but it does only in a single place. The counting should be moved to `fctx_incr()`.The `ZoneQuota` should log all the hits to `fcount_incr()` returning `ISC_R_QUOTA`, but it does only in a single place. The counting should be moved to `fctx_incr()`.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Ondřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/stork/-/issues/1043System test with Postgres using the ident authentication method2023-06-06T13:29:00ZSlawek FigielSystem test with Postgres using the ident authentication methodI added some unit and system tests to check if Stork supports the main Postgres authentication methods.
I've written unit tests for `trust`, `peer`, `ident`, `md5`, and `scram-sha-256`.
I tried to write system tests for the above method,...I added some unit and system tests to check if Stork supports the main Postgres authentication methods.
I've written unit tests for `trust`, `peer`, `ident`, `md5`, and `scram-sha-256`.
I tried to write system tests for the above method, and I did it except for `ident`.
I failed to configure the ident service. Ident service is a service running on the 113 port that implements [RFC 1413](https://datatracker.ietf.org/doc/html/rfc1413).
We use Debian 10.13-slim in our system tests, and no ident service is built-in.
In the `apt` repository are available three ident packages:
- `ident2`
- `oidentd`
- `nullidentd`
I checked all, and none of them is helpful in our case.
`ident2` runs properly, but it doesn't support IPv6, but the Postgres container tries to connect over this protocol. Due to Postgres running in a Docker container, the configuration capabilities are limited. I couldn't force it to use IPv4 without strongly reconfiguring our system tests' networks.
`oidentd` supports IPv6 well, but it didn't run due to failure during dropping root privileges. The problem occurs even if I run the service with a non-root user. I suppose it is a bug that is solved in the newer versions. Unfortunately, the author provides the binary packages on their own webpage. I think it isn't a good practice to link to non-trusted webpages from the system tests' environment, so I abandoned using them. I couldn't build the application from sources because some packages are missing in our current setup, and I didn't want to extend it.
`nullidentd` is a fake ident server intended to use with `inetd`. It increases the complexity of the solution, so I didn't spend time on it.
I think the best solution is to upgrade the system tests' operating system and use `oidentd`.
An alternative is implementing a fake ident service on our own, as the RFC 1413 is a very simple protocol.backloghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4103Package installation in RHE 92023-06-02T15:46:25ZPeter DaviesPackage installation in RHE 9### Summary
BIND 9.18.15-S is built with the jemalloc library. Jemalloc is apparently not
available in the default RHE OS software repository. This missing library causes
the Cloudsmith.io BIND 9.18.15-S package installation to fail....### Summary
BIND 9.18.15-S is built with the jemalloc library. Jemalloc is apparently not
available in the default RHE OS software repository. This missing library causes
the Cloudsmith.io BIND 9.18.15-S package installation to fail. Other versions
may be affected.
### BIND version used
/opt/isc/isc-bind/root/usr/sbin/named -v
BIND 9.18.15-S1 (Supported Preview Version) <id:863cc0d>
### Steps to reproduce
curl -1sLf 'https://dl.cloudsmith.io/xxxxxxxxxx/isc/bind/cfg/setup/bash.rpm.sh'| sudo bash
yum install isc-bind
### What is the current *bug* behavior?
The installation fails with the error message "nothing provides libjemalloc.so.2()(64bit)"
### What is the expected *correct* behavior?
Based on the documentation found here:
https://kb.isc.org/v1/docs/en/isc-packages-for-bind-9
After setting up the Cloudsmith.io repository, yum install isc-bind" should be
sufficient to install BIND
### Relevant configuration files
See: [RT #22075](#22075: authoritative servers issues)
### Relevant logs and/or screenshots
```
yum install isc-bind
Updating Subscription Management repositories.
isc-bind-9-18-sub 642 B/s | 659 B 00:01
isc-bind-9-18-sub-noarch 738 B/s | 659 B 00:00
isc-bind-9-18-sub-source 566 B/s | 659 B 00:01
Error:
Problem: package isc-bind-1:2-3.el9.x86_64 requires isc-bind-bind, but none of the providers can be installed
- package isc-bind-bind-9.18.15.S1-1.1.el9.x86_64 requires libbind9-9.18.15-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.15.S1-1.1.el9.x86_64 requires libdns-9.18.15-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.15.S1-1.1.el9.x86_64 requires libisc-9.18.15-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.15.S1-1.1.el9.x86_64 requires libisccfg-9.18.15-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.15.S1-1.1.el9.x86_64 requires libisccc-9.18.15-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.15.S1-1.1.el9.x86_64 requires libns-9.18.15-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.15.S1-1.1.el9.x86_64 requires isc-bind-bind-libs = 9.18.15.S1, but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.2.el9.x86_64 requires libbind9-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.2.el9.x86_64 requires libdns-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.2.el9.x86_64 requires libisc-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.2.el9.x86_64 requires libisccfg-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.2.el9.x86_64 requires libisccc-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.2.el9.x86_64 requires libns-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.2.el9.x86_64 requires isc-bind-bind-libs = 9.18.14.S1, but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.1.el9.x86_64 requires libbind9-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.1.el9.x86_64 requires libdns-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.1.el9.x86_64 requires libisc-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.1.el9.x86_64 requires libisccfg-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.1.el9.x86_64 requires libisccc-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.1.el9.x86_64 requires libns-9.18.14-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.14.S1-1.1.el9.x86_64 requires isc-bind-bind-libs = 9.18.14.S1, but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.2.el9.x86_64 requires libbind9-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.2.el9.x86_64 requires libdns-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.2.el9.x86_64 requires libisc-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.2.el9.x86_64 requires libisccfg-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.2.el9.x86_64 requires libisccc-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.2.el9.x86_64 requires libns-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.2.el9.x86_64 requires isc-bind-bind-libs = 9.18.13.S1, but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.1.el9.x86_64 requires libbind9-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.1.el9.x86_64 requires libdns-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.1.el9.x86_64 requires libisc-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.1.el9.x86_64 requires libisccfg-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.1.el9.x86_64 requires libisccc-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.1.el9.x86_64 requires libns-9.18.13-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.13.S1-1.1.el9.x86_64 requires isc-bind-bind-libs = 9.18.13.S1, but none of the providers can be installed
- package isc-bind-bind-9.18.12.S1-1.1.el9.x86_64 requires libbind9-9.18.12-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.12.S1-1.1.el9.x86_64 requires libdns-9.18.12-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.12.S1-1.1.el9.x86_64 requires libisc-9.18.12-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.12.S1-1.1.el9.x86_64 requires libisccfg-9.18.12-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.12.S1-1.1.el9.x86_64 requires libisccc-9.18.12-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.12.S1-1.1.el9.x86_64 requires libns-9.18.12-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.12.S1-1.1.el9.x86_64 requires isc-bind-bind-libs = 9.18.12.S1, but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.2.el9.x86_64 requires libbind9-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.2.el9.x86_64 requires libdns-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.2.el9.x86_64 requires libisc-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.2.el9.x86_64 requires libisccfg-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.2.el9.x86_64 requires libisccc-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.2.el9.x86_64 requires libns-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.2.el9.x86_64 requires isc-bind-bind-libs = 9.18.11.S1, but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.1.el9.x86_64 requires libbind9-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.1.el9.x86_64 requires libdns-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.1.el9.x86_64 requires libisc-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.1.el9.x86_64 requires libisccfg-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.1.el9.x86_64 requires libisccc-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.1.el9.x86_64 requires libns-9.18.11-S1.so()(64bit), but none of the providers can be installed
- package isc-bind-bind-9.18.11.S1-1.1.el9.x86_64 requires isc-bind-bind-libs = 9.18.11.S1, but none of the providers can be installed
- conflicting requests
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.15.S1-1.1.el9.x86_64
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.14.S1-1.2.el9.x86_64
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.14.S1-1.1.el9.x86_64
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13.S1-1.2.el9.x86_64
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.13.S1-1.1.el9.x86_64
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.12.S1-1.1.el9.x86_64
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.11.S1-1.2.el9.x86_64
- nothing provides libjemalloc.so.2()(64bit) needed by isc-bind-bind-libs-9.18.11.S1-1.1.el9.x86_64
(try to add '--skip-broken' to skip uninstallable packages or '--nobest' to use not only best candidate packages)
```
### Possible fixes
Michał: Setup a repository that does have jemalloc libraries. for example.
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpmPeter DaviesPeter Davieshttps://gitlab.isc.org/isc-projects/bind9/-/issues/4102Use liburcu QSBR flavor2023-07-26T09:59:54ZOndřej SurýUse liburcu QSBR flavorThe QSBR flavor is faster, but also requires rcu_quiescent_state() to be called periodically from every RCU thread.The QSBR flavor is faster, but also requires rcu_quiescent_state() to be called periodically from every RCU thread.Not plannedOndřej SurýOndřej Surýhttps://gitlab.isc.org/isc-projects/dhcp/-/issues/282Symptoms of dhcp.conf file disappearance after baremetal power-off to power-on2023-06-01T06:59:12Zalven-kimSymptoms of dhcp.conf file disappearance after baremetal power-off to power-on---
name: Bug report
about: Create a report to help us improve
---
**Description**
All files in the /etc/dhcpd.conf.d/ directory are missing.
I worked power-off the server and power-on.
Configuration file missing after power off -> o...---
name: Bug report
about: Create a report to help us improve
---
**Description**
All files in the /etc/dhcpd.conf.d/ directory are missing.
I worked power-off the server and power-on.
Configuration file missing after power off -> on
/etc/dhcpd.conf.d/dhcpd.master, /etc/dhcpd.conf.d/dhcpd.master
Is there a way to recover existing files for?
Please refer to the information below for more information.
**Environment**
- OS : Debian10
- Kernel : 4.19.0-16-amd64 #1 SMP Debian 4.19.181-1 (2021-03-19) x86_64 GNU/Linux
- etc : Baremetal
**Additional context**
Add any other context about the feature request here.
- 2023/05/26 21:58 baremetal power-off
- 2023/05/27 03:10 baremetal power-on
after, syslog : No such file or directory
1. power-off log
```
May 26 21:58:01 dhcp01 CRON[33764]: pam_unix(cron:session): session opened for user librenms by (uid=0)
May 26 21:58:01 dhcp01 CRON[33767]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33766]: pam_unix(cron:session): session opened for user librenms by (uid=0)
May 26 21:58:01 dhcp01 CRON[33768]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33765]: pam_unix(cron:session): session opened for user librenms by (uid=0)
May 26 21:58:01 dhcp01 CRON[33769]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33780]: (myuser) CMD (sleep 55; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33782]: (myuser) CMD (sleep 50; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33779]: (librenms) CMD ( /opt/librenms/ping.php >> /dev/null 2>&1)
May 26 21:58:01 dhcp01 CRON[33781]: (librenms) CMD ( /opt/librenms/alerts.php >> /dev/null 2>&1)
May 26 21:58:01 dhcp01 CRON[33783]: (myuser) CMD (sleep 45; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33784]: (librenms) CMD ( cd /opt/librenms/ && php artisan schedule:run >> /dev/null 2>&1)
May 26 21:58:01 dhcp01 CRON[33770]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33771]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33773]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33785]: (myuser) CMD (sleep 40; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33774]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33776]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33778]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33786]: (myuser) CMD (sleep 35; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33787]: (myuser) CMD (sleep 25; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33775]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33777]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33772]: pam_unix(cron:session): session opened for user myuser by (uid=0)
May 26 21:58:01 dhcp01 CRON[33788]: (myuser) CMD (sleep 20; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33789]: (myuser) CMD (bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33790]: (myuser) CMD (sleep 10; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33791]: (myuser) CMD (sleep 15; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33792]: (myuser) CMD (sleep 5; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33793]: (myuser) CMD (sleep 30; bash /home/myuser/test_simple_api/run.sh check & bash /home/myuser/test_simple_api02/run.sh check)
May 26 21:58:01 dhcp01 CRON[33778]: pam_unix(cron:session): session closed for user myuser
May 26 21:58:01 dhcp01 CRON[33766]: pam_unix(cron:session): session closed for user librenms
May 26 21:58:01 dhcp01 CRON[33765]: pam_unix(cron:session): session closed for user librenms
May 26 21:58:02 dhcp01 dhcpd[12662]: DHCPDISCOVER from 2c:ea:7f:5e:5c:15 via eno1: network 10.30.2.0/24: no free leases
May 26 21:58:06 dhcp01 CRON[33777]: pam_unix(cron:session): session closed for user myuser
May 26 21:58:11 dhcp01 CRON[33764]: pam_unix(cron:session): session closed for user librenms
May 26 21:58:11 dhcp01 CRON[33776]: pam_unix(cron:session): session closed for user myuser
May 26 21:58:16 dhcp01 CRON[33775]: pam_unix(cron:session): session closed for user myuser
May 26 21:58:21 dhcp01 CRON[33774]: pam_unix(cron:session): session closed for user myuser
May 26 21:58:21 dhcp01 dhcpd[12662]: DHCPDISCOVER from 2c:ea:7f:5e:5c:15 via eno1: network 10.30.2.0/24: no free leases
May 26 21:58:26 dhcp01 CRON[33773]: pam_unix(cron:session): session closed for user myuser
May 26 21:58:27 dhcp01 etc-dhcp-dhcpd.conf.d[10103]: [2023-05-26 12:58:27.492615] C [rpc-clnt-ping.c:162:rpc_clnt_ping_timer_expired] 0-dhcp-conf-client-1: server 10.30.2.242:49152 has not responded in the last 42 seconds, disconnecting.
May 26 21:58:29 dhcp01 dhcpd[12662]: DHCPDISCOVER from 2c:ea:7f:5e:5c:15 via eno1: network 10.30.2.0/24: no free leases
May 26 21:58:30 dhcp01 kernel: tg3 0000:03:00.0 eno1: Link is down
May 26 21:58:31 dhcp01 CRON[33772]: pam_unix(cron:session): session closed for user myuser
May 26 21:58:31 dhcp01 ntpd[9869]: Deleting interface #3 eno1, 10.30.2.241#123, interface stats: received=113508, sent=127702, dropped=0, active_time=44797832 secs
May 26 21:58:31 dhcp01 ntpd[9869]: 192.46.211.253 local addr 10.30.2.241 -> <null>
May 26 21:58:31 dhcp01 ntpd[9869]: 193.123.243.2 local addr 10.30.2.241 -> <null>
May 26 21:58:31 dhcp01 ntpd[9869]: 132.226.17.96 local addr 10.30.2.241 -> <null>
May 26 21:58:31 dhcp01 ntpd[9869]: Deleting interface #5 eno1, fe80::da9d:67ff:fe13:5d48%2#123, interface stats: received=0, sent=0, dropped=0, active_time=44797832 secs
```
2. power-on log
```
May 27 03:10:50 dhcp01 systemd[1]: etc-dhcp-dhcpd.conf.d.mount: Failed with result 'exit-code'.
May 27 03:10:50 dhcp01 systemd[1]: Started LSB: start or stop rrdcached.
May 27 03:10:50 dhcp01 systemd[1]: Started LSB: HPA's tftp server.
May 27 03:10:50 dhcp01 dhcpd[1399]: Can't open /etc/dhcp/dhcpd.conf.d/dhcpd.master: No such file or directory
May 27 03:10:50 dhcp01 dhcpd[1399]:
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: dhcpd self-test failed. Please fix /etc/dhcp/dhcpd.conf.
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: The error was:
May 27 03:10:50 dhcp01 dhcpd[1399]: If you think you have received this message due to a bug rather
May 27 03:10:50 dhcp01 dhcpd[1399]: than a configuration issue please read the section on submitting
May 27 03:10:50 dhcp01 dhcpd[1399]: bugs on either our web page at www.isc.org or in the README file
May 27 03:10:50 dhcp01 dhcpd[1399]: before submitting a bug. These pages explain the proper
May 27 03:10:50 dhcp01 dhcpd[1399]: process and the information we find helpful for debugging.
May 27 03:10:50 dhcp01 dhcpd[1399]:
May 27 03:10:50 dhcp01 dhcpd[1399]: exiting.
May 27 03:10:50 dhcp01 dhcpd[1495]: Internet Systems Consortium DHCP Server 4.4.1
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: Internet Systems Consortium DHCP Server 4.4.1
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: Copyright 2004-2018 Internet Systems Consortium.
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: All rights reserved.
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: For info, please visit https://www.isc.org/software/dhcp/
May 27 03:10:50 dhcp01 dhcpd[1495]: Copyright 2004-2018 Internet Systems Consortium.
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: Can't open /etc/dhcp/dhcpd.conf.d/dhcpd.master: No such file or directory
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: If you think you have received this message due to a bug rather
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: than a configuration issue please read the section on submitting
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: bugs on either our web page at www.isc.org or in the README file
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: before submitting a bug. These pages explain the proper
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: process and the information we find helpful for debugging.
May 27 03:10:50 dhcp01 isc-dhcp-server[1366]: exiting.
May 27 03:10:50 dhcp01 dhcpd[1495]: All rights reserved.
May 27 03:10:50 dhcp01 systemd[1]: isc-dhcp-server.service: Control process exited, code=exited, status=1/FAILURE
May 27 03:10:50 dhcp01 dhcpd[1495]: For info, please visit https://www.isc.org/software/dhcp/
May 27 03:10:50 dhcp01 systemd[1]: isc-dhcp-server.service: Failed with result 'exit-code'.
May 27 03:10:50 dhcp01 dhcpd[1495]: Can't open /etc/dhcp/dhcpd.conf.d/dhcpd.master: No such file or directory
May 27 03:10:50 dhcp01 systemd[1]: Failed to start LSB: DHCP server.
May 27 03:10:50 dhcp01 dhcpd[1495]:
May 27 03:10:50 dhcp01 dhcpd[1495]: If you think you have received this message due to a bug rather
May 27 03:10:50 dhcp01 dhcpd[1495]: than a configuration issue please read the section on submitting
May 27 03:10:50 dhcp01 dhcpd[1495]: bugs on either our web page at www.isc.org or in the README file
May 27 03:10:50 dhcp01 dhcpd[1495]: before submitting a bug. These pages explain the proper
May 27 03:10:50 dhcp01 dhcpd[1495]: process and the information we find helpful for debugging.
May 27 03:10:50 dhcp01 dhcpd[1495]:
May 27 03:10:50 dhcp01 dhcpd[1495]: exiting.
May 27 03:10:50 dhcp01 systemd[1]: Started Postfix Mail Transport Agent (instance -).
May 27 03:10:50 dhcp01 systemd[1]: Starting Postfix Mail Transport Agent...
May 27 03:10:50 dhcp01 systemd[1]: Started Postfix Mail Transport Agent.
May 27 03:10:55 dhcp01 systemd-udevd[1541]: Using default interface naming scheme 'v240'.
May 27 03:10:55 dhcp01 systemd-udevd[1541]: link_config: autonegotiation is unset or enabled, the speed and duplex are not writable.
May 27 03:10:56 dhcp01 systemd[1]: Started Latency Logging and Graphing System.
May 27 03:10:56 dhcp01 systemd-resolved[727]: Using degraded feature set (UDP+EDNS0+DO) for DNS server 8.8.8.8.
May 27 03:10:57 dhcp01 systemd[1]: Started Docker Application Container Engine.
May 27 03:10:57 dhcp01 systemd[1]: Reached target Multi-User System.
May 27 03:10:57 dhcp01 systemd[1]: Started Oxidized - Network Device Configuration Backup Tool.
May 27 03:10:57 dhcp01 systemd[1]: Reached target Graphical Interface.
May 27 03:10:57 dhcp01 systemd[1]: Starting Update UTMP about System Runlevel Changes...
May 27 03:10:57 dhcp01 systemd[1]: systemd-update-utmp-runlevel.service: Succeeded.
May 27 03:10:57 dhcp01 systemd[1]: Started Update UTMP about System Runlevel Changes.
May 27 03:10:57 dhcp01 systemd[1]: Startup finished in 27.483s (kernel) + 36.223s (userspace) = 1min 3.707s.
```
3. systemctl status
```
● isc-dhcp-server.service - LSB: DHCP server
Loaded: loaded (/etc/init.d/isc-dhcp-server; generated)
Active: failed (Result: exit-code) since Wed 2023-05-31 11:27:49 KST; 2h 12min ago
Docs: man:systemd-sysv-generator(8)
Process: 9079 ExecStart=/etc/init.d/isc-dhcp-server start (code=exited, status=1/FAILURE)
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]: Can't open /etc/dhcp/dhcpd.conf.d/dhcpd.master: No such file or directory
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]:
May 31 11:27:49 dhcp01.hq.alven.local systemd[1]: Failed to start LSB: DHCP server.
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]: If you think you have received this message due to a bug rather
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]: than a configuration issue please read the section on submitting
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]: bugs on either our web page at www.isc.org or in the README file
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]: before submitting a bug. These pages explain the proper
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]: process and the information we find helpful for debugging.
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]:
May 31 11:27:49 dhcp01.hq.alven.local dhcpd[9089]: exiting.
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4101Update b.root-server.net addresses2023-11-07T09:42:29ZMark AndrewsUpdate b.root-server.net addressesPer the announcement from USC/ISI we need to update the compiled in
addresses for b.root-servers.net for the November or December release.
Both addresses appear to be currently operational.
```
USC/ISI is renumbering both its IPv4 and ...Per the announcement from USC/ISI we need to update the compiled in
addresses for b.root-servers.net for the November or December release.
Both addresses appear to be currently operational.
```
USC/ISI is renumbering both its IPv4 and IPv6 addresses for
b.root-servers.net on 2023-11-27. Our new IPv4 address will be
170.247.170.2 and our new IPv6 address will be 2801:1b8:10::b.
USC/ISI will continue to support root service over our current IPv4 and
IPv6 addresses for at least one year (until 2024-11-27) in order to
provide a stable transition period while new root hints files are
distributed in software and operating system packages.
We are renumbering to increase the resilience of the Root Servers
System by further diversifying the number of Regional Internet
Registries (RIRs) that have allocated IP addresses to Root Server
Operators. Our addresses will be the first in the Root Server System to
have been allocated by LACNIC and our routes will be verifiable through
LACNIC’s Resource Public Key Infrastructure (RPKI) Trust Anchor
Location (TAL). We thank LACNIC for helping make this renumbering
possible, and ARIN for supporting our prior addressing assignments.
The LACNIC announcement, with English, Spanish and Portuguese
translations, can be found on their website here:
https://www.lacnic.net/6868/1/lacnic/lacnic-asigna-recursos-de-numeracion-al-servidor-raiz-de-usc_isi
Please direct any comments or questions to b-poc <at> isi.edu.
Regards,
The USC/ISI root operations team
P.S. Apologies to anyone receiving multiple copies of this announcement.
```November 2023 (9.16.45, 9.16.45-S1, 9.18.20, 9.18.20-S1, 9.19.18)2023-11-27https://gitlab.isc.org/isc-projects/kea/-/issues/2899bump up version to 2.3.9-git in configure.ac2023-07-17T13:58:21ZAndrei Pavelandrei@isc.orgbump up version to 2.3.9-git in configure.acIt's the usual bump up after a release.It's the usual bump up after a release.kea2.4.0Wlodzimierz WencelWlodzimierz Wencelhttps://gitlab.isc.org/isc-projects/kea/-/issues/2898decision about using pool-id 0 as UNUSED or first pool or INVALID2023-07-17T13:58:20ZRazvan Becheriudecision about using pool-id 0 as UNUSED or first pool or INVALIDthe current implementation and schema upgrade uses pool-id 0 value as default.
all leases currently stored in lease storage have pool id 0.
motivation:
1. subnet id 0 is the default so I think pool id should follow.
2. the SubnetID ty...the current implementation and schema upgrade uses pool-id 0 value as default.
all leases currently stored in lease storage have pool id 0.
motivation:
1. subnet id 0 is the default so I think pool id should follow.
2. the SubnetID type is uint32_t so PoolID is uint32_t also in Kea code.
3. -1 for pool id is not that portable (I am not sure all backends have the same support for the same data types - int32/uint32/int64/uint64 and choosing a value in kea code to int32_t to -1 would be interpreted by some of the backends as a large number (for unsigned) or even a middle value for uint64).
4. -1 would also cause migration issues if we decide to add support for uint64_t in Kea code (a large uint32_t value aka -1 will have a different large value for uint64_t which will make the old value a valid pool id, which will cause some kind of confusion).
using 0 has some flexibility:
5. 0 can mean UNSET and valid pool ids start from 1 (first pool index in a subnet), making the distinction between unset/unused and explicitly set.
6. 0 can be the first pool index that must exist (there can not be a lease assign that has been allocated in a subnet with no pools), making pool id 0 always a valid pool id, even if not accurate (before explicit lease update) if there are more pools. in this case, pool id is a bucket for all leases that have not been updated.
7. subnet stats are inaccurate when a subnet is added/removed and all subnets are recounted. the same could apply to pools. this makes all stats eventually consistent, and with each lease being updated, the stats converge to real values. this is acceptable because these are only stats.
8. pool id is only used in stats, and no kea query is using a specific pool id, so this can be changed at any time, in contrast to the subnet ids which are used in queries.
9. making pool id mandatory would make current configurations unusable, so a default value MUST be used, so 0 looked like the best candidate. there might be some huge configurations there with hundreds or thousands of subnets, each with one or more pools. this would make the config upgrade hard to manage, even if automated.
10. as mentioned before, there are 3 types of state in which an pool ID might have: VALID/ACCURRATE (after a lease update and before any config change related to subnets or pools), UNUSED (before any lease update and before the schema upgrade to 2.3.8) and INVALID (after a config change related to subnets and pools but before a lease update). the third kind will always exist as the subnet id will always cause it, even if the pool id somehow avoids it, and I think we should not spend much time/effort to try to fix it. using pool id 0 as UNSET and starting from 1 as first pool index makes a distinction between UNSET and VALID, but as there will always be the INVALID state, we can omit this state also and use 0 as the first pool index.kea2.4.0Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2897Cross-check - server should check its HA partner config2023-06-15T13:50:50ZTomek MrugalskiCross-check - server should check its HA partner configHere's an idea for new HA capability. On startup (or when explicit command is called), the server retrieves its partner configuration with `config-get` and checks it for consistency: if the subnets and pools are defined the same way, if ...Here's an idea for new HA capability. On startup (or when explicit command is called), the server retrieves its partner configuration with `config-get` and checks it for consistency: if the subnets and pools are defined the same way, if the subnet-ids match etc.
Right now the doc says those should be the same, with the only difference being server-name, but we don't check it.
What to do with spotted differences is to be determined. We could print a warning, refuse HA connection, shutdown, or even maybe the primary attempt to fix its partner's config.
This is merely an idea. If we like it, the first step would be to turn this into more coherent design. Hence the ~design.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2896Move to binary address as the lease6 primary key2023-06-15T13:24:43ZFrancis DupontMove to binary address as the lease6 primary keyThis details the long term plan sumarized by this comment:
```
# Holds the IPv6 leases.
# N.B. The use of a VARCHAR for the address is temporary for development:
# it will eventually be replaced by BINARY(16).
CREATE TABLE lease6 (
a...This details the long term plan sumarized by this comment:
```
# Holds the IPv6 leases.
# N.B. The use of a VARCHAR for the address is temporary for development:
# it will eventually be replaced by BINARY(16).
CREATE TABLE lease6 (
address VARCHAR(39) PRIMARY KEY NOT NULL, # IPv6 address
...
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4100REQUIRE(((multi) != ((void *)0) && ((const isc__magic_t *)(multi))->magic == ...2023-05-30T08:09:36ZMichal NowakREQUIRE(((multi) != ((void *)0) && ((const isc__magic_t *)(multi))->magic == ((('q') << 24 | ('p') << 16 | ('m') << 8 | ('v'))))) in qp.cJob [#3424074](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3424074) failed for 2e8ceeea14e336980c9da80449b84ecd16afc7e5.
The `qpmulti_test` unit test failed.
```
[==========] Running 1 test(s).
[ RUN ] qpmulti
qp.c:634: REQUI...Job [#3424074](https://gitlab.isc.org/isc-projects/bind9/-/jobs/3424074) failed for 2e8ceeea14e336980c9da80449b84ecd16afc7e5.
The `qpmulti_test` unit test failed.
```
[==========] Running 1 test(s).
[ RUN ] qpmulti
qp.c:634: REQUIRE(((multi) != ((void *)0) && ((const isc__magic_t *)(multi))->magic == ((('q') << 24 | ('p') << 16 | ('m') << 8 | ('v'))))) failed, back trace
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.14-dev.so(+0x2ddb2)[0x7f231ea2ddb2]
/builds/isc-projects/bind9/lib/isc/.libs/libisc-9.19.14-dev.so(isc_assertion_failed+0xa)[0x7f231ea2dd2d]
/builds/isc-projects/bind9/lib/dns/.libs/libdns-9.19.14-dev.so(+0xb9fe3)[0x7f231e0b9fe3]
/lib64/liburcu.so.6(+0x37a9)[0x7f231d64e7a9]
/lib64/libpthread.so.0(+0x81da)[0x7f231dbdd1da]
/lib64/libc.so.6(clone+0x43)[0x7f231ceafe73]
../../tests/unit-test-driver.sh: line 36: 13597 Aborted (core dumped) "${TEST_PROGRAM}"
FAIL qpmulti_test (exit status: 134)
```
There's no core file or full backtrace in the logs.https://gitlab.isc.org/isc-projects/kea/-/issues/2895Sanity checks for Kea 2.3.8 rc12023-05-30T18:54:08ZAndrei Pavelandrei@isc.orgSanity checks for Kea 2.3.8 rc1We are now at step SANITY CHECKS of Kea 2.3.8 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-co...We are now at step SANITY CHECKS of Kea 2.3.8 rc1.
Please verify the tarballs and packages according to [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks) and according to your imagination.
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.
#### Tarballs on repo.isc.org
* `/data/shared/sweng/kea/releases/2.3.8-rc1`
* `/data/shared/sweng/kea/releases/premium-2.3.8-rc1`
* `/data/shared/sweng/kea/releases/subscription-2.3.8-rc1`
* `/data/shared/sweng/kea/releases/enterprise-2.3.8-rc1`
```
SHA256 (kea-2.3.8.tar.gz) = 69854e888af6726b91ab8920bbec8c3ba2fd334db2ff021873d394a5a7ac3181
SHA256 (kea-enterprise-2.3.8.tar.gz) = 36caff70ed5b221d937ec5e021fdd6d5449c3610d22ed2c4103b3a016d031c15
SHA256 (kea-premium-2.3.8.tar.gz) = 5881402718ed8156082f5a571f5cf03403d7942806a0181b069ec8fc149d433e
SHA256 (kea-subscription-2.3.8.tar.gz) = 9ed5f3352b5ad88ca4a196a10ad632a826de293c706e5e3bfccc38ac93658868
```
#### Packages on packages.aws.isc.org
* [APK: 2.3.8-r20230530063557](https://packages.aws.isc.org/#browse/search/raw=format%3Draw%20AND%20name.raw%3D*r20230530063557.apk)
* [deb: 2.3.8-isc20230530063557](https://packages.aws.isc.org/#browse/search/apt=format%3Dapt%20AND%20version%3D2.3.8-isc20230530063557)
* [RPM: 2.3.8-isc20230530063557.\[os\]](https://packages.aws.isc.org/#browse/search/yum=format%3Dyum%20AND%20version%3D2.3.8-isc20230530063557*)
You can find the name for all the packages attached as build artifacts in the pkg job: https://jenkins.aws.isc.org/job/kea-dev/job/pkg/1178/
Instructions for installing packages are at point 9 of [chapter `4. Sanity Checks` of the release procedure](https://gitlab.isc.org/isc-private/qa-dhcp/-/wikis/Kea/Release-Process#user-content-4-sanity-checks).kea2.3.8https://gitlab.isc.org/isc-projects/kea/-/issues/2894pool-id is incorrectly assinged in load-balancing configuration2023-05-30T07:00:56ZMarcin Godzinapool-id is incorrectly assinged in load-balancing configurationWhen 2 Kea servers are in load balancing configuration and in contact, then most of the leases in the second pool are assigned the wrong pool-id. \
In ready and maintenance mode, the problem exists. In partner down state, pool-id is assi...When 2 Kea servers are in load balancing configuration and in contact, then most of the leases in the second pool are assigned the wrong pool-id. \
In ready and maintenance mode, the problem exists. In partner down state, pool-id is assigned correctly.
I didn't see the problem in standby mode.
In this configuration, all adreses from `::0` to `::30` should have `pool-id=0`, and all from `::100` to `::130` should have `pool-id=1`
Subnet:
``` json
"subnet6": [
{
"subnet": "2001:db8:1::/64",
"pools": [
{
"pool": "2001:db8:1::1-2001:db8:1::30",
"client-class": "HA_server1"
},
{
"pool": "2001:db8:1::100-2001:db8:1::130",
"client-class": "HA_server2"
}
],
"interface": "enp0s9"
}
]
```
Example lease:
``` python
server1:
{'cltt': 1685374590, 'duid': '00:03:00:01:01:03:0d:04:0b:01', 'fqdn-fwd': False, 'fqdn-rev': False, 'hostname': '', 'hw-address': '01:03:0d:04:0b:01', 'iaid': 3973, 'ip-address': '2001:db8:1::101', 'pool-id': 0, 'preferred-lft': 3000, 'state': 0, 'subnet-id': 1, 'type': 'IA_NA', 'valid-lft': 4000}
server2:
{'cltt': 1685374590, 'duid': '00:03:00:01:01:03:0d:04:0b:01', 'fqdn-fwd': False, 'fqdn-rev': False, 'hostname': '', 'hw-address': '01:03:0d:04:0b:01', 'iaid': 3973, 'ip-address': '2001:db8:1::101', 'pool-id': 1, 'preferred-lft': 3000, 'state': 0, 'subnet-id': 1, 'type': 'IA_NA', 'valid-lft': 4000}
```
[leases2.csv](/uploads/c99fbd40b17d5e15fed8e88ea3e2d0ff/leases2.csv)
[leases.csv](/uploads/fbdbeb0afdd5021ba8dbb1a5eb81aff2/leases.csv)
[kea-dhcp6.conf1](/uploads/8c82c5d6bb0cc422df51e30129025c79/kea-dhcp6.conf1)
[kea-dhcp6.conf](/uploads/310b2930b353b7996593260516294c8c/kea-dhcp6.conf)kea2.3.8Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2893pool-id not parsed by lease commands hook library2023-07-17T13:58:21ZRazvan Becheriupool-id not parsed by lease commands hook librarykea2.3.8Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/2892missing documentation: prefix hints, empty reservation, template classes, exc...2023-07-17T13:58:20ZAndrei Pavelandrei@isc.orgmissing documentation: prefix hints, empty reservation, template classes, exclude-first-last-24Certain features introduced in the 2.3 development cycle lack documentation or could be better documented:
* **Prefix hints**. There is no mention of what happens when a client povides a prefix hint. It should not be mentioned that Kea ...Certain features introduced in the 2.3 development cycle lack documentation or could be better documented:
* **Prefix hints**. There is no mention of what happens when a client povides a prefix hint. It should not be mentioned that Kea started respecting prefix hints with Kea 2.3.4 because that's not true. Rather, the focus was switched from matching the prefix address to matching the prefix length.
* **Empty reservations**. It's not mentioned that empty reservations are possible and that they can be used to quickly assign clients to KNOWN. Maybe one phrase about this would be helpful.
* **Template classes**. This is a big feature. However, there isn't a section dedicated to it. The info about template classes is in 2 notes and 2 paragraphs in the classification section. I think it deserves a dedicated section that users can search by.
* **exclude-first-last-24**. ARM mentions that this takes effects for subnets bigger than /24, but it should include /24 too - something like `subnets of /24 size or smaller`. Quotes from ARM:
* > Exclude First Last Addresses in Subnets Bigger Than /24
* > The exclude-first-last-24 compatibility flag is described in Configuration of IPv4 Address Pools (when true .0 and .255 addresses are excluded from subnets with prefix length less than 24).
* > When true, it applies only to subnets with prefix lengths less than 24 bits; the default is false.kea2.4.0Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2891Handling optional columns in SELECT for PostgreSQL2023-06-15T13:51:46ZMarcin SiodelskiHandling optional columns in SELECT for PostgreSQLDuring the discussions about #2886 it was apparent that we need to design a way of making SELECT queries in PostgreSQL with excluding some columns. It is particularly important for the `lease6` table queries where we recently started add...During the discussions about #2886 it was apparent that we need to design a way of making SELECT queries in PostgreSQL with excluding some columns. It is particularly important for the `lease6` table queries where we recently started adding new columns (related to BLQ) that are excluded in some (many?) cases. The `PgSqlLease6Exchange` contains the list of constants designating the indexes of the columns in the SELECT statements. A temporary solution was to assign the highest indexes for optional columns (put them at the end), but it may be good for a single optional column. If you have two optional columns this solution has serious limitations. For example, to query the last optional column you need to query all preceding optional columns, even if they are not needed in the particular case.
The following thread in #2886 is relevant: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2016#note_377155
It includes some ideas how to address this problem.https://gitlab.isc.org/isc-projects/kea/-/issues/2890How do you tell which pool stat belongs to which pool?2023-08-10T13:31:44ZAndrei Pavelandrei@isc.orgHow do you tell which pool stat belongs to which pool?The name of a pool stat looks like this: `subnet[1].pool[0].assigned-nas`.
There is no easy traceability between a pool and its ID in the stats. Pools have their IDs sorted by first address. So when a user wants to know the stats for a ...The name of a pool stat looks like this: `subnet[1].pool[0].assigned-nas`.
There is no easy traceability between a pool and its ID in the stats. Pools have their IDs sorted by first address. So when a user wants to know the stats for a pool, they would have to sort them by first address, and then count to see on what position (i.e. ID) the pool is. That's not very user-friendly.
You may argue that the same problem exists with subnets, but:
* Subnet IDs are sometimes specified in the config next to the subnet. Regardless, subnet IDs always appear in config-get results so they can be easily fetched and matched that way.
* If not explicitly specified, subnet IDs are sorted by the order that subnets are declared in the config, so even that is easier to figure out than for pool IDs.
* Subnet IDs are mentioned in logs in abundance, so admins who watch logs may become familiar with them. Pool IDs are not mentioned at all in logs.
One idea is to pass a tuple to `StatsMgr` when adding values or setting values. The tuple would contain, in addition to the usual integer value, a string with the text description of the pool which can be acquired from `Pool::toText()`. The tuple would translate into a list in the JSON response:
```json
"subnet[1].pool[0].assigned-nas": [
[
[2, "2001:db8::/64"],
"1970-01-01 00:00:00.000000"
]
]
```
As opposed to how it is now, which is:
```json
"subnet[1].pool[0].assigned-nas": [
[
2,
"1970-01-01 00:00:00.000000"
]
]
```https://gitlab.isc.org/isc-projects/kea/-/issues/2889Changes for Kea 2.3.8 release2023-07-17T13:58:21ZAndrei Pavelandrei@isc.orgChanges for Kea 2.3.8 release
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright years
- [x] added release entry to ChangeLogs
- [x] regenerated BNF grammar
- [x] regenerated message headers
- [x] regenerated parsers
- [x] reordered messages in alphabetical order
- [x] updated copyright yearskea2.3.8Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/28882.3.8 release checklist2023-06-01T05:37:49ZAndrei Pavelandrei@isc.org2.3.8 release checklist---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaRelease...---
name: a.b.c release checklist
about: Create a new issue using this checklist for each release.
---
# Kea Release Checklist
This is thoroughly documented in [the Kea Release Process guide](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess).
## Pre-Release Preparation
Some of those checks and updates can be made before the actual freeze.
For new stable releases or maintenance releases, please don't use `kea-dev` build farm. Use dedicated build farm for each release cycle.
1. Check Jenkins results:
1. [x] Check Jenkins jobs for failures: [distcheck](https://jenkins.aws.isc.org/job/kea-dev/job/distcheck/), etc...
1. [x] Check [Jenkins Tests Report](https://jenkins.aws.isc.org/job/kea-dev/job/jenkins-tests-report/).
1. [x] Check [tarball check report](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/Kea_20Build_20Checks/)
1. [x] Check [Performance Test Results](https://jenkins.isc.org/job/kea-dev/job/performance/KeaPerformanceReport/) in Jenkins for drops in performance.
1. Check versioning, ask the development team if:
- the library versions are being updated
- `KEA_HOOKS_VERSION` is being updated
- [x] create an issue for that for developers in Gitlab
- script: [./tools/bump-lib-versions.sh](https://gitlab.isc.org/isc-projects/kea/-/blob/master/tools/bump-lib-versions.sh) Kea-q.w.e Kea-a.b.c (where `a.b.c` is the version to be released and `q.w.e` is the version previous to that)
1. [x] Look at the issue numbers in commit descriptions. Add to ChangeLog a mention about any change with visible impact that had not been mentioned already.
1. If any changes have been done to database schemas, then:
1. [x] Check that a previously released schema has not been changed.
1. [x] Check that the additions to `dhcpdb_create.*sql`, and nothing more nor less than what was added in this release, is present in a `upgrade_*_to_*.sh.in` script that should also have been added in this release.
1. Prepare Release Notes
1. [x] Create Release Notes on Kea GitLab wiki and notify @tomek about that. It should be created under "release notes" directory, like this one: https://gitlab.isc.org/isc-projects/kea/-/wikis/release%20notes/release-notes-2.1.0
1. [x] Finish release notes and conduct its review. Also please notify @sgoldlust or @vicky that release notes are ready for review.
1. [x] Run [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/) as running parameter `TarballOrPkg` select `packages` and [release-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/) to test repositories for correctness.
1. If a new Cloudsmith repository is used, then:
1. [ ] Make sure freeradius packages are uploaded to the Cloudsmith repository or copied from a previous repository.
1. [ ] Make sure access tokens have been synchronized from previous Cloudsmith repositories and to the [check-pkgs.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/pkgs-check/check-pkgs.py) QA tool.
1. [x] Check if ReadTheDocs can build Kea documentation.
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds) and wait for the build to complete.
The following steps may involve changing files in the repository.
1. [x] Run [update-code-for-release.py](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/update-code-for-release.py) <br>
Example command: `GITLAB_TOKEN='...' ./update-code-for-release.py 1.9.7 --repo-dir ~/isc/repos/kea/` Use `--upload` to commit changes. <br>
Help: `GITLAB_TOKEN="..." ./update-code-for-release.py --help`<br>
This script makes the following changes and actions:
1. run prepare_kea_release.sh that does:
1. add release entries in ChangeLogs
1. update Kea version in configure.ac
1. update copyright years in files that were changed in current year
1. sort message files
1. regenerate message files headers
2. regenerate parsers using Bison from Docker<br>
With `--upload`:
3. create an issue in GitLab for release changes in kea repo
4. create branches and merge requests for kea and kea-premium
5. commit the changes in both repos
6. checkout created branches in both repos
7. commit and push the changes to GitLab server
1. Check manually User's Guide sections:
1. Chapter 1. Introduction
1. [x] On what platforms we are running tests using Jenkins? Update Supported Platforms in platforms.rst file.
1. [x] Did we add any additional 3rd party software? Update if needed
1. [x] Is there a new tool installed in bin or sbin released this time? If yes, is it documented?
1. Chapter 2. Quick Start
1. [x] Has the default installation process changed (for kea and hooks)? If yes, are those changes documented and highlighted in the release notes?
1. Chapter 3. Installation
1. [x] Check installation hierarchy (this is also automatically checked at the end of [ut-extended job](https://jenkins.aws.isc.org/job/kea-dev/job/ut-extended/))
1. [x] Check and update Build Requirements
1. [x] Check configure options against what `./configure -h` says
1. [x] Check ChangeLog entries in Kea main and premium: spelling, trailing whitespaces, etc.
1. [x] Check AUTHORS, INSTALL, README files in Kea main and premium.
- AUTHORS: update credits
- README: check "provides" with Release Notes, User Guide (1.3 Kea Software)
1. [x] If changes were made, commit the change, push the branch to the main repository and request a review. Once the changes have been approved, merge the MR to master.
## Build selection, tarballs upload and sanity checks
This is the last moment to freeze code! :snowflake:
1. [x] Go to [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/) Jenkins job and pick the last tarball built - it will be a release candidate.
1. [x] Check tarball before requesting sanity checks from the development team.
1. Download tarballs from picked Jenkins build
1. Check hook libraries.
1. Are there any new hook libraries installed in this release?
1. Are they in the proper tarball? Premium or subscription?
1. Do they have their own package?
1. Check sizes - is the new package reasonable?
1. Check installation tree, compare it with the previous release
1. Check installed libraries.
1. which were updated? (save results)
1. Do any of the libraries from the current release have lower version than in the previous release?
1. Uninstall Kea, check what left (there should be just configuration files)
1. Check if each of the installed binaries has a man page.
1. If not, is the binary included in the tarball? That might explain it.
1. Are man pages up to date?
1. Check if documentation is properly formatted, has correct versions and dates.
1. It's advised to search for previous version numbers, some of them are statically added in statements that are no longer valid.
1. [x] Upload tarballs to repo.isc.org using Jenkins and send sanity checks request.
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click "Build with Parameters".
1. In field "Tarball" select picked tarball build.
1. In field "Release_Candidate" pick:
1. rc1 if this is the first selected build for release, it will push the selected tarballs to repo.isc.org, to a directory suffixed with indicated rc#
1. next rc# if this is a respin after some fixes (note: it is not possible to pick previous rc number - it will result in an error)
1. Submit the job that will automatically:
1. Upload the tarballs <br>
and if this is not the final version:
1. Create a GitLab issue for sanity checks, put there the announcement
1. Send Sanity Checks announcement via email to dhcp-team@isc.org and to DHCP channel on Mattermost.<br>
The announcement includes:
- a link to chapter 4 Sanity Checks of the release process: [KeaReleaseProcess - SanityChecks](https://wiki.isc.org/bin/view/QA/KeaReleaseProcess#4.%20Sanity%20Checks)
- a link to the GitLab issue
- tarballs locations with SHA256 checksums
- rpm/deb packages locations and versions
## Releasing Tarballs and Packages
1. [x] Update Release Notes with ChangeLog entries
1. [x] Mark Jenkins jobs with release artifacts to be kept forever and update description of build by adding there version of released kea (e.g. Kea-2.2.2): <br>
Go to the following Jenkins jobs, click release build and then, on the build page, click `Keep this build forever` button and edit description: <br>
1. [build-tarball](https://jenkins.aws.isc.org/job/kea-dev/job/build-tarball/)
1. [pkg job](https://jenkins.aws.isc.org/job/kea-dev/job/pkg/)
1. [x] Upload final tarballs to repo.isc.org
1. Go to [release-tarball-upload](https://jenkins.aws.isc.org/job/kea-dev/job/release-tarball-upload/) Jenkins job.
1. Click "Build with Parameters"
1. In field "Tarball" select picked tarball build
1. In field "Release_Candidate" pick final <br>
This job will also:
- open an issue on [the signing repository](https://gitlab.isc.org/isc-private/signing/-/issues) for signing final tarballs on repo.isc.org
- create Git tags `Kea-a.b.c` in Kea main and premium repositories
- if release engineer is holding personal signing key, please use [sign, verify, and upload script](https://gitlab.isc.org/isc-private/qa-dhcp/-/blob/master/kea/build/sign_kea_and_upload_asc.sh)
- if release enginner do NOT have signing key, please contact team member.
1. [x] Upload final RPM & DEB packages, tarballs and sign files to cloudsmith.io
1. Go to [release-upload-to-cloudsmith](https://jenkins.aws.isc.org/job/kea-dev/job/release-upload-to-cloudsmith/).
1. Click "Build with Parameters" link
1. Pick your selected pkg build in Packages field, and select `PrivPubRepos: "both"`, `TarballOrPkg: "both"`, `TestProdRepos: "production"` and click `Build` button.
- this step is also veryfing sign files
1. When it finishes run check: [releases-pkgs-check](https://jenkins.aws.isc.org/job/kea-dev/job/release-pkgs-check/).
1. [x] Update ReadTheDocs
1. Trigger rebuilding docs on [readthedocs.org](https://readthedocs.org/projects/kea/builds).
1. Publish currently released version. On the `Versions` tab, scroll down to `Activate a version`, search for `kea-a.b.c` and click `Activate`.
1. For stable releases, change the default version to point to this stable release.
1. [x] Create an issue and a merge request to bump up Kea version in `configure.ac` to next development version which could be, based on just released version `a.b.c`:
* `a.b.z-git` where `z == c + 1` or
* `a.y.0-git` where `y == b + 1` or
* `x.1.0-git` where `x == a + 1`
1. [x] Send a request for publishing the release on the Support Mattermost channel linking the Signing issue and the release checklist issue.
### On the Day of Public Release
- [x] ***(Support)*** Wait for clearance from Security Officer to proceed with the public release (if applicable).
- [x] ***(Support)*** Confirm that the tarballs have the checksums mentioned on the signing ticket.
- [x] ***(Support)*** Place tarballs in public location on FTP site.
- [x] ***(Support)*** Publish links to downloads on ISC website.
- [x] ***(Support)*** Write release email to *kea-announce*.
- [x] ***(Support)*** Write email to *kea-users* (if a major release).
- [x] ***(Support)*** Send eligible customers updated links to the Subscription software FTP site.
- [x] ***(Support)*** If it is a new `major.minor` version, SWENG will have created a new repo in Cloudsmith, which will need the customer tokens migrated from an existing repo. Then update support customers that this new private repo exists.
- [x] ***(Support)*** Update tickets in case of waiting for support customers.
- [x] ***(Support)*** Inform Marketing of the release.
- [ ] ***(Marketing)*** If a new Cloudsmith repository is used, update the Zapier scripts.
- [x] ***(Marketing)*** Upload Premium hooks tarball to SendOwl. Create a new product if a new branch, otherwise update existing product. Send notifications to existing subscribers of the new version.
- [x] ***(Marketing)*** Announce on social media.
- [x] ***(Marketing)*** Update [Wikipedia entry for Kea](https://en.wikipedia.org/wiki/Kea_(software)).
- [ ] ***(Marketing)*** Write blog article (if a major release).
- [ ] ***(Marketing)*** Update [Kea page on web site if any new hooks](https://www.isc.org/kea/).
- [ ] ***(Marketing)*** Update Kea Premium and Kea Subscription data sheets if any new hooks.
- [x] ***(Marketing)*** Update [significant features matrix](https://kb.isc.org/docs/en/aa-01615) (if any significant new features).
- [x] ***(Marketing)*** Update [Kea documentation page in KB](https://kb.isc.org/docs/en/kea-administrator-reference-manual).kea2.3.8https://gitlab.isc.org/isc-projects/stork/-/issues/1042Stork fails to communicate with the DHCPv4 and DHCPv6 deamons2023-06-05T14:49:47ZDavid CascalesStork fails to communicate with the DHCPv4 and DHCPv6 deamonsI have installed both Kea, Stork server and agent in the same VM. I've just connected Kea to Stork, but for some reason Stork is unable to communicate with the DHCPv4 and DHCPv6 deamons. It is able to connect to the DDNS and CA, however ...I have installed both Kea, Stork server and agent in the same VM. I've just connected Kea to Stork, but for some reason Stork is unable to communicate with the DHCPv4 and DHCPv6 deamons. It is able to connect to the DDNS and CA, however i'm unnable to activate the monitorization of the DHCP servers. I got a warning message where it says that the (DHCP) deamons are not being monitored and that the deamons where either manually disabled or they were not running corretly.
![PlsHelp_1](/uploads/1fe0d58662810dd75b791b27a38c05f1/PlsHelp_1.jpg)
Both of my DHCP servers are active and running with no problems whatsoever. Opening "journalctl" on the command prompt shows me the following error:
![PlsHelp_2](/uploads/b8820a1ff8f4737ec2a5bd58c2da4109/PlsHelp_2.jpg)