ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-26T19:39:49Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3278Perfmon-Hook-Task-4 Implement PerfMonMgr Basics - start up, configuration2024-03-26T19:39:49ZThomas MarkwalderPerfmon-Hook-Task-4 Implement PerfMonMgr Basics - start up, configurationComplete Hook Task 4: Implement PerfMonMgr Basics - start up, configuration.
This creates the initial PerfMonMgr class with stub functions. It should be able to parse configuration but not yet provide data processing.
See https://gitla...Complete Hook Task 4: Implement PerfMonMgr Basics - start up, configuration.
This creates the initial PerfMonMgr class with stub functions. It should be able to parse configuration but not yet provide data processing.
See https://gitlab.isc.org/isc-projects/kea/-/wikis/Designs/performance-monitor#perfmon-hook-taskskea2.5.8Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/bind9/-/issues/4622BIND hangs in qp_makekey2024-03-25T10:53:39ZMichal NowakBIND hangs in qp_makekeyMy home resolver (`main` - 88a5befa2578bf9969652798ff0b3ede2d19e5c8) with QP got stuck after less than an hour of runtime:
```
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11efb74c00 86.49.239.93#37346 (fedoraproject.org): que...My home resolver (`main` - 88a5befa2578bf9969652798ff0b3ede2d19e5c8) with QP got stuck after less than an hour of runtime:
```
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11efb74c00 86.49.239.93#37346 (fedoraproject.org): query: fedoraproject.org IN AAAA +E(0)T (23.88.124.106)
Mar 06 17:53:17 dns.mnowak.cz named[81103]: client @0x7f11d913fc00 86.49.239.93#37388 (fedoraproject.org): query: fedoraproject.org IN AAAA +E(0)T (23.88.124.106)
Mar 06 17:53:18 dns.mnowak.cz named[81103]: client @0x7f11d905c400 86.49.239.93#37265 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:18 dns.mnowak.cz named[81103]: client @0x7f11ef80dc00 86.49.239.93#37366 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:20 dns.mnowak.cz named[81103]: client @0x7f11c5f93400 86.49.239.93#37217 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:20 dns.mnowak.cz named[81103]: client @0x7f11c5e70800 86.49.239.93#37210 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:21 dns.mnowak.cz named[81103]: client @0x7f11d913fc00 86.49.239.93#37346 (download.copr.fedorainfracloud.org): query: download.copr.fedorainfracloud.org IN A +E(0)T (23.88.124.106)
Mar 06 17:53:24 dns.mnowak.cz named[81103]: client @0x7f11c5f80c00 86.49.239.93#37347 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:24 dns.mnowak.cz named[81103]: client @0x7f11c5e6f000 86.49.239.93#37298 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:26 dns.mnowak.cz named[81103]: client @0x7f11c6408800 86.49.239.93#37257 (cdn.samsungcloudsolution.com): query: cdn.samsungcloudsolution.com IN A + (23.88.124.106)
Mar 06 17:53:31 dns.mnowak.cz named[81103]: client @0x7f11c5e57400 2a02:8308:a006:2b00::901f#56962 (download.copr.fedorainfracloud.org): query: download.copr.fedorainfracloud.org IN A +E(0)T (2a01:4f8:1c17:cdb0::1)
```
I `abort`ed the server to get a core file. Here's a backtrace:
```
#0 dns_qpkey_fromname (key=0x7ffdf559a200 "\002\"%\032\002\034&\026\002 \024''\030% \"&'\002\002", name=0x7f11c6260110) at qp.c:234
#1 0x00007f11f18dd88f in qp_makekey (key=<optimized out>, uctx=<optimized out>, pval=<optimized out>, ival=<optimized out>) at qpdb.c:201
#2 0x00007f11f18bf605 in leaf_qpkey (qpr=..., n=0x7f11f02ee048, key=0x7ffdf559a200 "\002\"%\032\002\034&\026\002 \024''\030% \"&'\002\002") at /home/newman/bind9/lib/dns/qp_p.h:883
#3 fix_iterator (qp=qp@entry=0x7f11f02d82c0, iter=iter@entry=0x7ffdf559c160, start=<optimized out>,
search=search@entry=0x7ffdf559bec0 "\002\"%\032\002\031\030\027\"%\024\034!\031%\024\026\037\"(\027\002\026\"#%\002\027\"*!\037\"\024\027\002\002", searchlen=searchlen@entry=36, bit=bit@entry=37 '%',
offset=9) at qp.c:2152
#4 0x00007f11f18bfeee in dns_qp_lookup (qpr=..., name=name@entry=0x7f11d9108380, foundname=foundname@entry=0x0, iter=iter@entry=0x7ffdf559c160, chain=0x7ffdf559b4a0, chain@entry=0x0,
pval_r=pval_r@entry=0x7ffdf559d178, ival_r=0x0) at qp.c:2284
#5 0x00007f11f18d62c0 in find_coveringnsec (search=search@entry=0x7ffdf559d6b0, name=name@entry=0x7f11d9108380, nodep=nodep@entry=0x7ffdf55a0080, now=now@entry=1709744001,
foundname=foundname@entry=0x7f11d9108100, rdataset=rdataset@entry=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at qp-cachedb.c:636
#6 0x00007f11f18d69ee in cache_find (db=<optimized out>, name=0x7f11d9108380, version=<optimized out>, type=1, options=16, now=<optimized out>, nodep=0x7ffdf55a0080, foundname=0x7f11d9108100,
rdataset=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at qp-cachedb.c:803
#7 0x00007f11f18538f7 in dns__db_findext (db=0x7f11f0259800, name=name@entry=0x7f11d9108380, version=0x0, type=1, options=options@entry=16, now=1709744001, nodep=0x7ffdf55a0080, foundname=0x7f11d9108100,
methods=0x7ffdf559f6f0, clientinfo=0x7ffdf559f660, rdataset=0x7f11d9129c00, sigrdataset=0x7f11d912b480) at db.c:535
#8 0x00007f11f1add5b1 in query_lookup (qctx=qctx@entry=0x7ffdf559fbe0) at query.c:5969
#9 0x00007f11f1ade2f7 in ns__query_start (qctx=qctx@entry=0x7ffdf559fbe0) at query.c:5817
#10 0x00007f11f1ae3b6e in query_setup (client=client@entry=0x7f11d913fc00, qtype=qtype@entry=1) at query.c:5529
#11 0x00007f11f1ae4667 in ns_query_start (client=client@entry=0x7f11d913fc00, handle=handle@entry=0x7f11d9180700) at query.c:12107
#12 0x00007f11f1ac66fe in ns_client_request (handle=0x7f11d9180700, eresult=<optimized out>, region=<optimized out>, arg=<optimized out>) at client.c:2231
#13 0x00007f11f1b2a968 in streamdns_on_complete_dnsmessage (dnsasm=<optimized out>, region=0x7ffdf55a0850, sock=0x7f11d9161300, transphandle=0x7f11ee98d500) at netmgr/streamdns.c:147
#14 streamdns_on_dnsmessage_data_cb (dnsasm=<optimized out>, result=<optimized out>, region=0x7ffdf55a0850, cbarg=0x7f11d9161300, userarg=0x7f11ee98d500) at netmgr/streamdns.c:206
#15 0x00007f11f1b2a1c8 in isc__dnsstream_assembler_callcb (dnsasm=0x7f11efb71300, result=ISC_R_SUCCESS, region=0x7ffdf55a0850, userarg=0x0) at ./include/isc/dnsstream.h:306
#16 isc__dnsstream_assembler_handle_message (dnsasm=dnsasm@entry=0x7f11efb71300, userarg=userarg@entry=0x7f11ee98d500) at ./include/isc/dnsstream.h:353
#17 0x00007f11f1b2ab7b in isc__dnsstream_assembler_processing (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500) at ./include/isc/dnsstream.h:370
#18 isc__dnsstream_assembler_incoming_direct (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500, buf=0x7ffdf55a0970, buf_size=65) at ./include/isc/dnsstream.h:396
#19 isc_dnsstream_assembler_incoming (dnsasm=0x7f11efb71300, userarg=0x7f11ee98d500, buf=0x7ffdf55a0970, buf_size=65) at ./include/isc/dnsstream.h:508
#20 streamdns_handle_incoming_data (sock=sock@entry=0x7f11d9161300, transphandle=transphandle@entry=0x7f11ee98d500, data=0x7ffdf55a0970, len=65) at netmgr/streamdns.c:242
#21 0x00007f11f1b2ad34 in streamdns_readcb (handle=0x7f11ee98d500, result=ISC_R_SUCCESS, region=0x7ffdf55a0960, cbarg=0x7f11d9161300) at netmgr/streamdns.c:557
#22 0x00007f11f1b30b73 in tls_do_bio (sock=sock@entry=0x7f11d9162200, received_data=received_data@entry=0x7ffdf55b09f0, send_data=send_data@entry=0x0, finish=finish@entry=false) at netmgr/tlsstream.c:679
#23 0x00007f11f1b30fb5 in tls_readcb (handle=0x7f11ee987400, result=ISC_R_SUCCESS, region=0x7ffdf55b09f0, cbarg=0x7f11d9162200) at netmgr/tlsstream.c:840
#24 0x00007f11f1b2314c in isc___nm_readcb (arg=<optimized out>) at netmgr/netmgr.c:1856
#25 0x00007f11f1b2321e in isc__nm_readcb (sock=sock@entry=0x7f11d9163b00, uvreq=<optimized out>, eresult=eresult@entry=ISC_R_SUCCESS, async=async@entry=false) at netmgr/netmgr.c:1871
#26 0x00007f11f1b2ee80 in isc__nm_tcp_read_cb (stream=<optimized out>, nread=174, buf=0x7ffdf55b0a90) at netmgr/tcp.c:772
#27 0x00007f11f131c6fb in uv.read () from /lib64/libuv.so.1
#28 0x00007f11f131ca78 in uv.stream_io () from /lib64/libuv.so.1
#29 0x00007f11f132262b in uv.io_poll () from /lib64/libuv.so.1
#30 0x00007f11f1309708 in uv_run () from /lib64/libuv.so.1
#31 0x00007f11f1b48255 in loop_thread (arg=arg@entry=0x7f11f0227000) at loop.c:284
#32 0x00007f11f1b5a02e in thread_body (wrap=0x7f11f0325480) at thread.c:85
#33 0x00007f11f1b5a0a7 in isc_thread_main (func=func@entry=0x7f11f1b481ca <loop_thread>, arg=0x7f11f0227000) at thread.c:116
#34 0x00007f11f1b491ea in isc_loopmgr_run (loopmgr=0x7f11f0209a80) at loop.c:456
#35 0x0000000000426ac0 in main (argc=4, argv=0x7ffdf55b4e08) at main.c:1574
```
[bt-full.txt](/uploads/e4d8eb5744a3ea1c45f09cc9bd521294/bt-full.txt)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/bind9/-/issues/4614Fix memory consumption in qp (Follow-up from "create QPDB zone database")2024-03-14T18:06:55ZMatthijs Mekkingmatthijs@isc.orgFix memory consumption in qp (Follow-up from "create QPDB zone database")The following discussion from !8543 should be addressed:
- [x] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8543#note_438118): (+1 comment)
> I gave it a quick look and sanity check - ...The following discussion from !8543 should be addressed:
- [x] @pspacek started a [discussion](https://gitlab.isc.org/isc-projects/bind9/-/merge_requests/8543#note_438118): (+1 comment)
> I gave it a quick look and sanity check - loaded `net.` TLD into this version (configured as secondary - [named.conf](/uploads/d55553c50824d4c519123d18d743225f/named.conf)).
>
> Here's a quick summary:
>
> | metric | main | qpdb-heavy | 4411-qpdb-lite |
> |---------------------------------------------|---------|------------|----------------|
> | zone load time | 4:20 | 1:30 | 1:38 |
> | memory RSS | 6.2 GiB | 12.8 GiB | 12.8 GiB |
> | repeated bla.net. A query [QPS] | 155 k | 160 k | 152 k |
> | repeated bla.net. A query [CPU utilization] | 400 % | 300 % | 320 % |
> | random delegations [QPS] | 150 k | 150 k | 148 k |
> | random delegations [CPU utilization] | 470 % | 370 % | 410 % |
>
> TL;DR smaller CPU usage while doubling amount of memory.
>
> Statistics channel output after just loading the zone (no queries yet):
> - [main.json](/uploads/b0e43a7f25acb60fad379fee27577f06/main.json)
> - [heavy.json](/uploads/42baadb5c3dba87142ef36552c71d725/heavy.json)
> - [lite.json](/uploads/7bc0516d2565aba18692cc9bf0bd50b1/lite.json)May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4580Add resolver.arpa to the built in empty zones2024-03-21T00:23:52ZMark AndrewsAdd resolver.arpa to the built in empty zonesRFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served z...RFC 9462 adds resolver.arpa to the lists of empty zones.
```
6.4. Handling Non-DDR Queries for resolver.arpa
DNS resolvers that support DDR by responding to queries for _dns.resolver.arpa. MUST treat resolver.arpa as a
locally served zone per [RFC6303]. In practice, this means that resolvers SHOULD respond to queries of any
type other than SVCB for _dns.resolver.arpa. with NODATA and queries of any type for any domain name under
resolver.arpa with NODATA.
```May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/4535"digdelv" system test often fails the "try the next server after a TCP socket...2024-02-24T07:57:52ZMichał Kępień"digdelv" system test often fails the "try the next server after a TCP socket connection error/timeout" checkFor at least the past two weeks or so, the following check in the
`digdelv` system test has been failing particularly often, for no
apparent reason that I could think of:
```
2024-01-14 04:17:49 INFO:digdelv I:digdelv_tmp_aq8itlsn:c...For at least the past two weeks or so, the following check in the
`digdelv` system test has been failing particularly often, for no
apparent reason that I could think of:
```
2024-01-14 04:17:49 INFO:digdelv I:digdelv_tmp_aq8itlsn:check that dig tries the next server after a TCP socket connection error/timeout (89)
2024-01-14 04:18:09 INFO:digdelv I:digdelv_tmp_aq8itlsn:failed
```
It is an intermittent failure. It seems to be at least strongly
"preferring" FreeBSD jobs (and may even be exclusive to these, but I
have not checked all of its occurrences):
- https://gitlab.isc.org/isc-projects/bind9/-/jobs/3926964
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3938693
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3938692
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939505
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939504
- https://gitlab.isc.org/isc-private/bind9/-/jobs/3939503
The check itself dates back to March 2022 (!5976), so it is surprising
to only see an uptick in its failures now. Perhaps some other fix
merged in the meantime changed `dig` behavior in a way that trips this
logic up?May 2024 (9.18.27, 9.18.27-S1, 9.19.24)https://gitlab.isc.org/isc-projects/bind9/-/issues/1621"statistics" system test is prone to races and does not preserve forensic data2024-02-24T07:58:28ZMichał Kępień"statistics" system test is prone to races and does not preserve forensic dataIt was hard to figure out what was happening in https://gitlab.isc.org/isc-private/bind9/-/jobs/674674 because the `statistics` system test does not preserve enough forensic data to troubleshoot this particular failure mode easily, but I...It was hard to figure out what was happening in https://gitlab.isc.org/isc-private/bind9/-/jobs/674674 because the `statistics` system test does not preserve enough forensic data to troubleshoot this particular failure mode easily, but I think I got to the bottom of what is happening. I believe the problem is that `ns3` retries the SOA query for the `a-slave` zone right *before* the first use of `rndc stats` but the response to that query is received *after* the first use of `rndc stats`. This retried SOA query is usually sent after the first use of `rndc stats` and replied to before the second use of `rndc stats`; if that is not the case, statistics get skewed. Here is how things look typically:
```
$ grep -E "(created socket| soa_query:|refresh:|'stats')" ns3/named.run | sed -E "/'stats'/{s|(.*)|---------- \1 ----------|}"
14-Feb-2020 13:39:51.279 dispatch 0x7faf54030ce0: created socket 0x7faf5ec9f600
14-Feb-2020 13:39:51.279 dispatch 0x7faf54030720: created socket 0x7faf5ec9f778
14-Feb-2020 13:39:51.279 dispatch 0x7faf54030160: created socket 0x7faf5ec9f8f0
14-Feb-2020 13:39:51.279 dispatch 0x7faf5402fba0: created socket 0x7faf5ec9fa68
14-Feb-2020 13:39:51.303 soa_query: zone a-slave/IN: enter
14-Feb-2020 13:39:51.303 dispatch 0x7faf54652fa0: created socket 0x7faf5a41e600
14-Feb-2020 13:39:51.304 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#5300 (source 10.53.0.3#0)
---------- 14-Feb-2020 13:39:51.537 received control channel command 'stats' ----------
14-Feb-2020 13:39:51.803 soa_query: zone a-slave/IN: enter
14-Feb-2020 13:39:51.803 dispatch 0x7faf54652fa0: created socket 0x7faf5a41ebe0
14-Feb-2020 13:39:51.807 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#5300 (source 0.0.0.0#0)
---------- 14-Feb-2020 13:39:53.564 received control channel command 'stats' ----------
```
while this is what happened in the job linked to above:
```
$ grep -E "(created socket| soa_query:|refresh:|'stats')" ns3/named.run | sed -E "/'stats'/{s|(.*)|---------- \1 ----------|}"
13-Feb-2020 14:47:44.500 dispatch 0x80545b000: created socket 0x80508d838
13-Feb-2020 14:47:44.500 dispatch 0x80545aa00: created socket 0x80508d990
13-Feb-2020 14:47:44.500 dispatch 0x80545a400: created socket 0x80508dae8
13-Feb-2020 14:47:44.500 dispatch 0x805459e00: created socket 0x80508dc40
13-Feb-2020 14:47:44.549 soa_query: zone a-slave/IN: enter
13-Feb-2020 14:47:44.550 dispatch 0x805743400: created socket 0x8054e0508
13-Feb-2020 14:47:44.552 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#12400 (source 10.53.0.3#0)
13-Feb-2020 14:47:45.048 soa_query: zone a-slave/IN: enter
13-Feb-2020 14:47:45.048 dispatch 0x805743400: created socket 0x80508d430
---------- 13-Feb-2020 14:47:45.058 received control channel command 'stats' ----------
13-Feb-2020 14:47:45.069 zone a-slave/IN: refresh: unexpected rcode (NXDOMAIN) from master 10.53.0.1#12400 (source 0.0.0.0#0)
---------- 13-Feb-2020 14:47:47.149 received control channel command 'stats' ----------
```
Thus, I *believe* that the active socket count was 1 less than the expected value in the second `ns3/named.stats` file being examined.
AFAICT, the `a-slave` zone is only relevant in the `checking bind9.xsl vs xml` check, it is not configured on `ns1`. If it was actually configured, the SOA query would not need to be retried due to an NXDOMAIN response, hopefully making the test more reliable.
Forensic data preservation should also be improved for this test.May 2024 (9.18.27, 9.18.27-S1, 9.19.24)Tom KrizekTom Krizekhttps://gitlab.isc.org/isc-projects/kea/-/issues/3152Extraneous second lookup in host cache in the radius access callout when subn...2024-03-25T14:14:24ZAndrei Pavelandrei@isc.orgExtraneous second lookup in host cache in the radius access callout when subnet is not reselectedIn `subnetX_select` callouts for `libdhcp_radius.so`, there are two `getXAny` lookups in the host cache. The second one has the purpose of fetching the host again with the new subnet ID. But this makes sense only if the subnet was resele...In `subnetX_select` callouts for `libdhcp_radius.so`, there are two `getXAny` lookups in the host cache. The second one has the purpose of fetching the host again with the new subnet ID. But this makes sense only if the subnet was reselected since the first retrieval as part of the subnet reselection process that is specific to RADIUS. However, it is called regardless of whether the subnet was reselected or not. This could be optimized.next-stable-2.6Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2882kea-admin tool doesn't support -P argument to specify port for remote mysql c...2023-06-15T13:48:46ZАлександр Левданскийkea-admin tool doesn't support -P argument to specify port for remote mysql connection**Describe the bug**
Trying to connect to remote mysql-server providing not standard port:
```root@kea1-test:~# kea-admin db-init mysql -u <my_secret_user> -p <my_secret_password> -n <my_secret_database> -h <my_secret_host> --port 3307...**Describe the bug**
Trying to connect to remote mysql-server providing not standard port:
```root@kea1-test:~# kea-admin db-init mysql -u <my_secret_user> -p <my_secret_password> -n <my_secret_database> -h <my_secret_host> --port 3307
Checking if there is a database initialized already...
mysql: [Warning] Using a password on the command line interface can be insecure.
Verifying create permissions for kea_dhcp
mysql: [Warning] Using a password on the command line interface can be insecure.
MySQL Version is: 8.0.33
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
mysql: [Warning] Using a password on the command line interface can be insecure.
Initializing database using script /usr/share/kea/scripts/mysql/dhcpdb_create.mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 2003 (HY000): Can't connect to MySQL server on '<my_secret_host>:3306' (111)
```
**Expected behavior**
I expect to connect to remote mysql-server with specified port
**Environment:**
- Kea version: 2.2.0
- OS: Ubuntu 20.04
**Additional Information**
I can only connect to mysql-server with not standard port like
```
root@kea1-test:~# kea-admin db-init mysql -u <my_secret_user> -p <my_secret_password> -n <my_secret_database> -h <my_secret_host> -x --port=3307
```
But then what is the option for -P|--port?next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2478Documentation - how to migrate from ISC dhcp to Kea2024-03-21T14:43:40ZPeter DaviesDocumentation - how to migrate from ISC dhcp to KeaDocumentation - how to migrate from ISC dhcp to Kea.
Add a section to the ARM describing migration strategiesfrom ISC dhcp to Kea.
This could contain:
a) A short description of the differences between ISC dhcp and Kea.
b) kea...Documentation - how to migrate from ISC dhcp to Kea.
Add a section to the ARM describing migration strategiesfrom ISC dhcp to Kea.
This could contain:
a) A short description of the differences between ISC dhcp and Kea.
b) keama introduction
c) Where can I find keama?
d) https://kb.isc.org/docs/migrating-from-isc-dhcp-to-kea-dhcp-using-the-migration-assistant
d) link to https://kb.isc.org/docs/kea-migration-assistant
e) What cannot be migrated with keama
(this need to be fleshed out)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/48Add a park point to subnet select callout (RADIUS async access)2023-11-08T10:05:03ZGhost UserAdd a park point to subnet select callout (RADIUS async access)Needed for Radius asynchronous access. Prepared (code reorganized) for DHCPv6 in #5458.Needed for Radius asynchronous access. Prepared (code reorganized) for DHCPv6 in #5458.next-stable-2.6https://gitlab.isc.org/isc-projects/stork/-/issues/935Ability to write Kea config (config-set + config-write)2023-11-07T11:29:01ZTomek MrugalskiAbility to write Kea config (config-set + config-write)Sooner or later, Stork will need the ability to write Kea's config file to disk. Couple scenarios where it would be handy:
- checkers now report issues. With config-write available, we could think about "fix it for me" button.
- we talk...Sooner or later, Stork will need the ability to write Kea's config file to disk. Couple scenarios where it would be handy:
- checkers now report issues. With config-write available, we could think about "fix it for me" button.
- we talked about HR migration from config file to DB.
- we talked about migrating subnet/shared networks from config file to CB.
- enabling higher logging levels for debugging
- many more...
There are many ways how to slice this, so ~design is needed for sure. Personally, I think this ticket should cover design phase and maybe code for the agent ability to do the write, but without any UI elements. A stepping stone for future work.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/889Feature Request: Possibility to connect to the postgresql database using Unix...2023-10-17T12:34:25ZmikygeeFeature Request: Possibility to connect to the postgresql database using Unix socketsHello,
According to the documentation and to this discussion #887, it's not possible that the stork server uses unix sockets to connect to the database.
It's sometimes a good choice to rely on unix sockets instead of tcp/ip (should be f...Hello,
According to the documentation and to this discussion #887, it's not possible that the stork server uses unix sockets to connect to the database.
It's sometimes a good choice to rely on unix sockets instead of tcp/ip (should be faster and more secure)
It would be nice to have this implementation within the stork server.
Regardsbackloghttps://gitlab.isc.org/isc-projects/stork/-/issues/871Unsupported stat info messages should be a lower log level2023-03-07T13:44:37Zvps-ericUnsupported stat info messages should be a lower log levelThese log statements are, in my opinion, not relevant enough to warrant being INFO level:
```
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-no-pools
INFO[2022-09-26 21:45:51] prom...These log statements are, in my opinion, not relevant enough to warrant being INFO level:
```
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-no-pools
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-subnet
INFO[2022-09-26 21:45:51] promkeaexporter.go:680 Encountered unsupported stat: v4-reservation-conflicts
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: declined-addresses
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: reclaimed-leases
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: reclaimed-declined-addresses
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-reservation-conflicts
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-shared-network
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: v4-allocation-fail-classes
INFO[2022-09-26 21:45:51] promkeaexporter.go:683 Encountered unsupported stat: cumulative-assigned-addresses
INFO[2022-09-26 21:45:51] promkeaexporter.go:680 Encountered unsupported stat: v4-reservation-conflicts
...
```
I propose that they be moved to DEBUG log level. Adding support for an unsupported stat is not something expected of a normal system administrator.
See #839.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/842BuildNameToCertificate is deprecated2022-12-13T12:20:43ZSlawek FigielBuildNameToCertificate is deprecatedThe `backend/server/restservice/restservice.go:261` line:
```go
// must have at least one certificate or panics
httpServer.TLSConfig.BuildNameToCertificate()
```
causes a deprecation warning:
> httpServer.TLSConfig.BuildNameToCertif...The `backend/server/restservice/restservice.go:261` line:
```go
// must have at least one certificate or panics
httpServer.TLSConfig.BuildNameToCertificate()
```
causes a deprecation warning:
> httpServer.TLSConfig.BuildNameToCertificate has been deprecated since Go 1.14: NameToCertificate only allows associating a single certificate with a given name. Leave that field nil to let the library select the first compatible chain from Certificates. (SA1019)go-staticcheckbackloghttps://gitlab.isc.org/isc-projects/stork/-/issues/793Update Swagger2023-04-03T10:49:26ZSlawek FigielUpdate SwaggerOur OpenAPI/Swagger dependencies are a little out-of-date:
- OpenAPI Generator: current: 5.2.0, available: 6.0.0
- GoSwagger: current: 0.23, available: 0.29
The GoSwagger is now feature-complete. It means that it fully implements the S...Our OpenAPI/Swagger dependencies are a little out-of-date:
- OpenAPI Generator: current: 5.2.0, available: 6.0.0
- GoSwagger: current: 0.23, available: 0.29
The GoSwagger is now feature-complete. It means that it fully implements the Swagger 2.0 specifications. It is great news but the upgrade is not easy because GoSwagger supports now the "read-only" attribute.
> Relevant only for Schema "properties" definitions. Declares the property as "read only". This means that it MAY be sent as part of a response but MUST NOT be sent as part of the request. Properties marked as readOnly being true SHOULD NOT be in the required list of the defined schema. Default value is false.
Unfortunately, our frontend sends read-only attributes in the requests. It causes them to be rejected by the server. It seems that it takes a lot of work to solve the problem.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/776Avoid using long numbers for IPv6 statistics2023-10-09T14:08:40ZSlawek FigielAvoid using long numbers for IPv6 statisticsThe issue was found during 1.4 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/771#note_289567)
Counting the IPv6 addresses is intimidating task. Instead of printing awfully long number of digits, we could try...The issue was found during 1.4 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/771#note_289567)
Counting the IPv6 addresses is intimidating task. Instead of printing awfully long number of digits, we could try to say something like "5 /16 prefixes". I think this could be done with the tooltip. Although I admit that it may get very messy very quickly if you mix subnets with different lengths...
This particular screenshot taken on the shared networks page, but this problem appears in many places.
![counting-v6](https://gitlab.isc.org/isc-projects/stork/uploads/a2098d549399833b79a953c97790383d/counting-v6.png)backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/769Duplicate key from includes in swagger.in.yaml2023-03-30T16:00:16ZAndrei Pavelandrei@isc.orgDuplicate key from includes in swagger.in.yamlIf you go to https://gitlab.isc.org/isc-projects/stork/-/blob/master/api/swagger.in.yaml, Gitlab shows:
```
Errors
Parser error on line 43
duplicated mapping key
```
```
Unable to render this definition
The provided definition does n...If you go to https://gitlab.isc.org/isc-projects/stork/-/blob/master/api/swagger.in.yaml, Gitlab shows:
```
Errors
Parser error on line 43
duplicated mapping key
```
```
Unable to render this definition
The provided definition does not specify a valid version field.
Please indicate a valid Swagger or OpenAPI version field. Supported version fields are swagger: "2.0" and those that match openapi: 3.0.n (for example, openapi: 3.0.0).
```
I have no idea what the implications are.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/726API returns the nil/null instead of empty lists.2023-04-03T10:51:10ZSlawek FigielAPI returns the nil/null instead of empty lists.The Stork Server API returns a nil/null value when the list has no elements.
The Swagger.yaml specifies that the returned type always is a list.
Returning nil breaks the strict type validation.
Additionally, some of our endpoints accept...The Stork Server API returns a nil/null value when the list has no elements.
The Swagger.yaml specifies that the returned type always is a list.
Returning nil breaks the strict type validation.
Additionally, some of our endpoints accept or return non-fulled data (e.g., list machines), but it isn't described in the API files.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/671Stork Agent - failed compilation on FreeBSD2022-12-13T12:32:04ZSlawek FigielStork Agent - failed compilation on FreeBSDThe issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/650#note_253285
I was unable to build Stork Agent on FreeBSD. It is about missing protocolbuffers package for that...The issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/650#note_253285
I was unable to build Stork Agent on FreeBSD. It is about missing protocolbuffers package for that system. There is actually an existing TODO in our Rakefile.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/655Missing "entr" - non-descriptive error2022-12-13T12:34:28ZSlawek FigielMissing "entr" - non-descriptive errorThe issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253010
I wonder if we want some more informative error that `entr` tool must be installed? It also relate...The issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253010
I wonder if we want some more informative error that `entr` tool must be installed? It also relates to other tasks that may have some dependencies.backlog