ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2024-03-14T14:07:08Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/1326Stork does not display leases statistics2024-03-14T14:07:08ZJohn PapStork does not display leases statistics**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server'...**Describe the bug**
Stork server not displaying lease statistics. Remote stork agent has already registered. Stork server GUI displays the kea dhcp4 service correctly and I can manually pull statistics via the API from the stork server's CLI using curl. Although there are active leases for clients the Web UI displays 0 for assigned IPs on all subnets. Probably a bug in the stat-lease4-get API command.
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea server 2.0.2, Stork 1.15.0 and run them with the following configs: '...'
2. Configure several subnets.
2. Have 3 VMs act as clients on all subnets and get ip addresses from kea server
3. Clients get IP address but the Stork GUI shows 0 for all lease statistics.
**Expected behavior**
Stork GUI should display the leases statistics for the connected clients.
**Environment:**
- Kea version: 2.0.2
- Stork: 1.15.0
- OS: Ubuntu 22.04 x64
- Kea: Hooks libdhcp_stat_cmds.so, libdhcp_lease_cmds.so
**Additional Information**
Querying the DHCP agent from the stork server using the cli and the management API I figured out that the stat-lease4-get command without arguments returns different results for the same subnet than the stat-lease4-get command having the subnet-id as an argument.
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"]}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 47, 56, 0, 0, 0 ], [ 51, 56, 0, 0, 0 ], [ 66, 41, 0, 0, 0 ] ], "timestamp": "2024-03-08 14:09:09.100431" } }, "result": 0, "text": "stat-lease4-get[all subnets]: 3 rows found" } ]
curl -X POST -H "Content-Type: application/json" -d '{ "command": "stat-lease4-get", "service": ["dhcp4"], "arguments": {"subnet-id" : 66}}' http://192.168.59.21:8000
[ { "arguments": { "result-set": { "columns": [ "subnet-id", "total-addresses", "cumulative-assigned-addresses", "assigned-addresses", "declined-addresses" ], "rows": [ [ 66, 41, 0, 3, 0 ] ], "timestamp": "2024-03-08 14:09:17.884123" } }, "result": 0, "text": "stat-lease4-get[subnet-id=66]: 1 rows found" } ]
The second output above has the correct leases stats for subnet-id 66 while the first output shows 0 leases for subnet-id 66https://gitlab.isc.org/isc-projects/bind9/-/issues/4624Invalid durations in configuration files do not cause a syntax error2024-03-14T12:54:59ZMatthijs Mekkingmatthijs@isc.orgInvalid durations in configuration files do not cause a syntax errorFor example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.For example: `signatures-refresh P7.5D;` is accepted but treated as `P7D`.April 2024 (9.16.50, 9.16.50-S1, 9.18.26, 9.18.26-S1, 9.19.23)Matthijs Mekkingmatthijs@isc.orgMatthijs Mekkingmatthijs@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/3283CableLabs option (RFC3495): Inconsistent "option_def" usage in client class d...2024-03-27T20:44:57ZPeter DaviesCableLabs option (RFC3495): Inconsistent "option_def" usage in client class definitionsInconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"opt...Inconsistent "option_def" usage in client class definitions:
Using Kea 2.5.6 - I have yet to try with 2.4.1.
The following "option-def" statement is accepted in the global scope of a
configuration file:
```
...
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" }
],
...
```
However, if this "option-def" is defined within a client class as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 122, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
The following message is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '122' in space 'dhcp4'
```
If the "Option_122" "option-def" is changed to private option "224" as:
```
...
"client-classes": [{
"name": "Docsis_Class", "test": "substring(option[60].hex,0,6) == 'docsis'",
"option-def": [ {
"name": "Option_122", "code": 224, "type": "empty", "encapsulate": "Option_122_space" }, {
"name": "Option_122_1", "code": 1, "space": "Option_122_Space", "type": "ipv4-address" }, {
"name": "Option_122_2", "code": 2, "space": "Option_122_Space", "type": "ipv4-address" } ],
"option-data": [ {
"name": "Option_122_1", "data": "10.0.0.68", "code": 1, "space": "Option_122_Space" }, {
"name": "Option_122_2", "data": "10.0.0.69", "code": 2, "space": "Option_122_Space" } ]
}],
...
```
Then the following error is generated, and Kea exits:
```
Error encountered: Not allowed option definition for code '1' in space 'Option_122_Space'
```
[SF00001775](https://isc.lightning.force.com/lightning/r/Case/500S6000006TLtj/view)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/3282Support option-data based on client class AND subnet2024-03-14T14:49:00ZDarren AnkneySupport option-data based on client class AND subnetScenario: A class of clients (ACME Phones) need to receive option 225 "foo" with string content. This string needs to vary depending on the subnet selected. The option-data must not be offered to clients that are NOT ACME Phones.
<det...Scenario: A class of clients (ACME Phones) need to receive option 225 "foo" with string content. This string needs to vary depending on the subnet selected. The option-data must not be offered to clients that are NOT ACME Phones.
<details><summary>Current solution:</summary>
```
{
"Dhcp4": {
"option-def": [
{
"name": "foo",
"code": 225,
"type": "string",
}
],
"client-classes": [
{
"name": "ACMEphone",
"test": "option[60].hex == 'ACME IP Phone'",
"option-data": [
{
"name": "foo",
"data": "'some string 1'"
}
],
"only-if-required": true
},
{
"name": "ACMEphone2",
"test": "option[60].hex == 'ACME IP Phone'",
"option-data": [
{
"name": "foo",
"data": "'some string 2'"
}
],
"only-if-required": true
}
],
"subnet4": [
{
"id": 1,
"subnet": "192.0.2.0/24",
"require-client-classes": [
"ACMEphone"
],
"pools": [
{
"pool": "192.0.2.2 - 192.0.2.254"
}
]
},
{
"id": 2,
"subnet": "192.0.3.0/24",
"require-client-classes": [
"ACMEphone2"
],
"pools": [
{
"pool": "192.0.3.2 - 192.0.3.254"
}
]
}
]
}
}
```
</details>
This solution works but requires adding one client-class per subnet that will need to provide differing parameters to the class of clients in question on a per subnet basis.
This scenario is quite common and was handled previously in ISC DHCP with "if" statements where an "if" statement would be dropped into a subnet as necessary for the clients that might appear there that needed some option content provided with values specific to the subnet selected.
[SF1773](https://isc.lightning.force.com/lightning/r/Case/500S6000006NkOVIA0/view)next-stable-3.0https://gitlab.isc.org/isc-projects/stork/-/issues/1325LDAP hook: Different DNs for bind user and login users2024-03-26T14:54:08ZRobin BergerLDAP hook: Different DNs for bind user and login usersIf your bind user has a different `dn` than the users that will be able to login to the stork web interface, you don't have a chance to set different root `dn`s.
Here a example:
Bind user: cn=bind_user,ou=service_account,ou=users,dc=ex...If your bind user has a different `dn` than the users that will be able to login to the stork web interface, you don't have a chance to set different root `dn`s.
Here a example:
Bind user: cn=bind_user,ou=service_account,ou=users,dc=example,dc=org
Login user: cn=login_user,ou=real_users,ou=users,dc=example,dc=org
It tried to use the maximum similar `dn` as root parameter and set the remainder in the bind username variable like this:
```
STORK_SERVER_HOOK_LDAP_ROOT="ou=users,dc=example,dc=org"
STORK_SERVER_HOOK_LDAP_BIND_USERNAME="bind_user,ou=service_account"
```
With this setup I was able to get the connection to ldap with the bind user but I was not able to login with a user, becuause I was not able to manipulate the username like the `STORK_SERVER_HOOK_LDAP_BIND_USERNAME` variable.
---
A possible solution is to set the full dn for the bind user in `STORK_SERVER_HOOK_LDAP_BIND_USERNAME` and use the `STORK_SERVER_HOOK_LDAP_ROOT` only for the search base of the users that will be able to login to the web interface.
Although I am not very comfortable with go and ldap, I would be able to help in implementing this solution.1.17https://gitlab.isc.org/isc-projects/bind9/-/issues/4623dns_db_setloop at wrong place in cache_create_db2024-03-08T11:48:33ZMark Andrewsdns_db_setloop at wrong place in cache_create_dbdns_db_setloop should only be called if the database creation succeeds.dns_db_setloop should only be called if the database creation succeeds.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://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/4621rndc flush make cache pruning no-op2024-03-08T11:44:42ZOndřej Surýrndc flush make cache pruning no-opWhen `rndc flush` (e.g. `dns_cache_flush()`) is called, the task is not set for the rbtdb which makes the cache pruning basically no-op, piling up the parent nodes that could not be sweeped together with the child nodes.When `rndc flush` (e.g. `dns_cache_flush()`) is called, the task is not set for the rbtdb which makes the cache pruning basically no-op, piling up the parent nodes that could not be sweeped together with the child nodes.March 2024 (9.16.49, 9.16.49-S1, 9.18.25, 9.18.25-S1, 9.19.22)https://gitlab.isc.org/isc-projects/stork/-/issues/1324502 bad gateway on authorize kea machine, but it is visible in authorized mac...2024-03-26T14:53:23ZPiotrek Zadroga502 bad gateway on authorize kea machine, but it is visible in authorized machines afterThis issue happened to me while running stork demo.
I tried to authorize 2 kea machines: `agent-kea6` and `agent-kea`.
The latter couldn't be authorized, I got 502 error.
Request:
```
XHRPUT
http://127.0.0.1:8080/api/machines/8
[HTTP/1...This issue happened to me while running stork demo.
I tried to authorize 2 kea machines: `agent-kea6` and `agent-kea`.
The latter couldn't be authorized, I got 502 error.
Request:
```
XHRPUT
http://127.0.0.1:8080/api/machines/8
[HTTP/1.1 502 Bad Gateway 280ms]
```
```json
{"address":"agent-kea","agentPort":8888,"agentToken":"(...)","apps":[],"id":8,"authorized":true}
```
But the machine disappeared from unauthorized machines and appeared in authorized:
![image](/uploads/bea9bebfe8ead8a60aec4790e80e2344/image.png)
I also got some 502's and 504's in console after:
![image](/uploads/fc99562530d9e658c84f700bf11f3134/image.png)1.17https://gitlab.isc.org/isc-projects/stork/-/issues/1323Attach more labels to the Prometheus samples2024-03-19T14:58:05ZSlawek FigielAttach more labels to the Prometheus samplesCurrently, if you haven't the subnet_cmds hook, the metrics are labeled with the subnet ID, and if you have the subnet_cmds hook, the metrics are labeled with the subnet name prefix if provided, otherwise with the subnet ID.
Our custome...Currently, if you haven't the subnet_cmds hook, the metrics are labeled with the subnet ID, and if you have the subnet_cmds hook, the metrics are labeled with the subnet name prefix if provided, otherwise with the subnet ID.
Our customer needs samples labeled by subnet ID regardless of the subnet_cmds presence. It would also be helpful to attach the shared network name.
[SF#1762](https://isc.lightning.force.com/lightning/r/Case/500S6000006AQSSIA4/view)1.17https://gitlab.isc.org/isc-projects/stork/-/issues/1322Upgrade Grafana and its dashboards2024-03-05T15:02:12ZSlawek FigielUpgrade Grafana and its dashboardsYou cannot import the example Grafana dashboards to a modern Grafana instance.
![image](/uploads/a95f33a1aa876ae18d92057fd933fc5f/image.png)
The Stork demo uses the `8.3.7` Grafana version. The latest version is `10.3.3`.
We should up...You cannot import the example Grafana dashboards to a modern Grafana instance.
![image](/uploads/a95f33a1aa876ae18d92057fd933fc5f/image.png)
The Stork demo uses the `8.3.7` Grafana version. The latest version is `10.3.3`.
We should upgrade the Grafana (and maybe Prometheus) used in the demo and migrate the example dashboards to a modern format.1.16https://gitlab.isc.org/isc-projects/kea/-/issues/3281Follow-up from "Draft: Resolve "heap-use-after-free and invalid vptr on PingC...2024-03-27T21:43:06ZRazvan BecheriuFollow-up from "Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMgr destruction""The following discussion from !2197 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2197#note_438320 'Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMg...The following discussion from !2197 should be addressed:
- [ ] @andrei started a [discussion](https://gitlab.isc.org/isc-projects/kea/-/merge_requests/2197#note_438320 'Draft: Resolve "heap-use-after-free and invalid vptr on PingCheckMgr destruction"'): (+3 comments)
> > To keep the members alive, they can be added to a lambda function which uses a smart pointer to capture the object, but does not use it. It then must be added to the IOService queue using the post function.
>
> I would take the `shared_from_this` alternative anytime if it gets rid of the posts.
>
> If you think that it is too much work for now although it shouldn't be, we can create a ticket, but can you at least add comments to say that they are posted only for extending lifetime?
>
> Core:
>
> ```plaintext
> + getIOService()->post(std::bind(f, queue_mgr_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_));
> + io_service_->post(std::bind(f, timer_, tcp_socket_, tls_socket_));
> ```
>
> Premium:
>
> ```plaintext
> + main_io_service_->post(std::bind(f, expiration_timer_, channel_));
> ```kea2.5.8https://gitlab.isc.org/isc-projects/bind9/-/issues/4620Cleanup: the characters from Regexp field are all unsigned and use unsigned c...2024-03-05T05:17:25ZMingshuai Renrenmingshuai@huawei.comCleanup: the characters from Regexp field are all unsigned and use unsigned char instead.```
From 0eac3b986972b2888ebf386642c1d281344aba91 Mon Sep 17 00:00:00 2001
From: renmingshuai <renmingshuai@huawei.com>
Date: Tue, 5 Mar 2024 09:49:01 +0800
Subject: [PATCH] Cleanup: the characters from Regexp field are all unsinged.
Us...```
From 0eac3b986972b2888ebf386642c1d281344aba91 Mon Sep 17 00:00:00 2001
From: renmingshuai <renmingshuai@huawei.com>
Date: Tue, 5 Mar 2024 09:49:01 +0800
Subject: [PATCH] Cleanup: the characters from Regexp field are all unsinged.
Use unsigned char instead.
Signed-off-by: renmingshuai <renmingshuai@huawei.com>
---
lib/dns/rdata/generic/naptr_35.c | 4 ++--
lib/isc/regex.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/lib/dns/rdata/generic/naptr_35.c b/lib/dns/rdata/generic/naptr_35.c
index ecae2c0ca3..abc1e41101 100644
--- a/lib/dns/rdata/generic/naptr_35.c
+++ b/lib/dns/rdata/generic/naptr_35.c
@@ -25,8 +25,8 @@
static inline isc_result_t
txt_valid_regex(const unsigned char *txt) {
unsigned int nsub = 0;
- char regex[256];
- char *cp;
+ unsigned char regex[256];
+ unsigned char *cp;
bool flags = false;
bool replace = false;
unsigned char c;
diff --git a/lib/isc/regex.c b/lib/isc/regex.c
index 99809cc244..eb01c7d4d9 100644
--- a/lib/isc/regex.c
+++ b/lib/isc/regex.c
@@ -28,7 +28,7 @@
* Validate the regular expression 'C' locale.
*/
int
-isc_regex_validate(const char *c) {
+isc_regex_validate(const unsigned char *c) {
enum {
none, parse_bracket, parse_bound,
parse_ce, parse_ec, parse_cc
--
2.33.0
```https://gitlab.isc.org/isc-projects/stork/-/issues/1321Enable running Stork on macbook M32024-03-04T19:25:10ZMarcin SiodelskiEnable running Stork on macbook M3There are several things that need to be changed in building Stork (mainly concerning the docker Demo) to run it on macbook with M3 processor. To list the main two: the architecture name "arm64" is not recognized in the rake files. Secon...There are several things that need to be changed in building Stork (mainly concerning the docker Demo) to run it on macbook with M3 processor. To list the main two: the architecture name "arm64" is not recognized in the rake files. Second, we need to emulate arm64 in the docker images becuase of lack of the certain Docker images (flamethrower, bind9 image).1.16Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/bind9/-/issues/4618kenya domain not available2024-03-01T15:00:30ZThomas Hankekenya domain not available<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confident...<!--
If the bug you are reporting is potentially security-related - for example,
if it involves an assertion failure or other crash in `named` that can be
triggered repeatedly - then please make sure that you make the new issue
confidential by clicking the checkbox at the bottom!
-->
### Summary
When I configure a domain from Kenya, it is not resolved.
### BIND version affected
<!--
Make sure you are testing with the **latest** supported version of BIND
for a given branch. Many bugs have been fixed over time!
See https://kb.isc.org/docs/supported-platforms for the current list.
The latest source is available from https://www.isc.org/download/#BIND
Paste the output of `named -V` here.
-->
- 9.16.48
### Steps to reproduce
<!--
This is extremely important! Be precise and use itemized lists, please.
Even if a default configuration is affected, please include the full configuration
files _you were testing with_.
Example:
1. Use _attached_ configuration file
2. Start BIND server with command: `named -g -c named.conf ...`
3. Simulate legitimate clients using command `dnsperf -S1 -d legit-queries ...`
4. Simulate attack traffic using command `dnsperf -S1 -d attack-queries ...`
-->
1. Add configuration for .ke domain
2. Check with dig that response will be right
### What is the current *bug* behavior?
```
dig han.ke @ns1.y4roc.de
; <<>> DiG 9.10.6 <<>> han.ke @ns1.y4roc.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 15861
;; flags: qr rd; QUERY: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 1232
;; QUESTION SECTION:
;han.ke. IN A
;; Query time: 20 msec
;; SERVER: 5.9.143.51#53(5.9.143.51)
;; WHEN: Fri Mar 01 14:23:15 CET 2024
;; MSG SIZE rcvd: 35
```
### What is the expected *correct* behavior?
```
dig han.ke @ns1.y4roc.de
; <<>> DiG 9.10.6 <<>> han.ke @ns1.y4roc.de
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 19451
;; flags: qr aa rd; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1
;; WARNING: recursion requested but not available
;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;han.ke. IN A
;; ANSWER SECTION:
han.ke. 86400 IN A 195.201.140.251
;; Query time: 22 msec
;; SERVER: 5.9.143.51#53(5.9.143.51)
;; WHEN: Fri Mar 01 15:29:57 CET 2024
;; MSG SIZE rcvd: 51
```https://gitlab.isc.org/isc-projects/bind9/-/issues/4617dig does not support IDN without configure option2024-03-02T06:12:04ZMitsuru Shimamuradig does not support IDN without configure option### Summary
Without configure option: --with-libidn2, dig does not support IDN even though libidn2 library header is installed.
### BIND version affected
```
# ./bin/named/named -V | head -1
BIND 9.19.21 (Development Release) <id:c030a...### Summary
Without configure option: --with-libidn2, dig does not support IDN even though libidn2 library header is installed.
### BIND version affected
```
# ./bin/named/named -V | head -1
BIND 9.19.21 (Development Release) <id:c030a67>
```
### Steps to reproduce
1. prepare for build
```
# docker run --rm -it rockylinux:9.3
(in the container)
# dnf groupinstall -y "Development Tools"
# dnf in --enablerepo=crb -y libidn2-devel openssl-devel libnghttp2-devel libuv-devel libcap-devel
# pkg-config --libs libidn2
-lidn2 <== library header is installed
```
2a. configure without "--with-libidn2" and make binary
```
# curl -O https://downloads.isc.org/isc/bind9/9.19.21/bind-9.19.21.tar.xz
# tar xf bind-9.19.21.tar.xz
# cd bind-9.19.21
# ./configure | tee configure.log
# grep idn configure.log
IDN support (--with-libidn2) <=== what's this?
# make
```
3a. check dig suppports +idn or not
```
# ./bin/dig/dig -h | grep idn
(not match)
^^^^^^^^^^^
# ./bin/dig/dig +noall +ans +idn xn--wgv71a119e.jp
;; IDN support is not available
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
xn--wgv71a119e.jp. 275 IN A 117.104.133.183
```
2b. configure **with** "--with-libidn2" and make binary
```
# curl -O https://downloads.isc.org/isc/bind9/9.19.21/bind-9.19.21.tar.xz
# tar xf bind-9.19.21.tar.xz
# cd bind-9.19.21
# ./configure --with-libidn2 | tee configure.log
^^^^^^^^^^^^^^
# grep idn configure.log
checking for libidn2... yes
# make
```
3b. check dig suppports +idn or not
```
# ./bin/dig/dig -h | grep idn
+[no]idn (convert international domain names)
# ./bin/dig/dig +noall +ans +idn xn--wgv71a119e.jp
日本語.jp. 300 IN A 117.104.133.183
^^^^^^^^^^
```
### What is the current *bug* behavior?
configure DOES NOT find libidn2 library header automatically
### What is the expected *correct* behavior?
configure find libidn2 library header automatically
in the other words,
dig supports +idn option without explicitly configure option when libidn2 library header is installed
### Relevant configuration files
no config files
### Relevant logs
no logs or see Steps to reproducehttps://gitlab.isc.org/isc-projects/bind9/-/issues/4616Resolver cache redesign2024-03-01T12:29:31ZPetr Špačekpspacek@isc.orgResolver cache redesignThis is a meta issue to collect current problems & ideas what to do about it.
Current known problems:
- LRU cleaning can get state into a weird state: #2744
- Cache cleaning can block things, and is generally a mess: #3261, #4383
- Neg...This is a meta issue to collect current problems & ideas what to do about it.
Current known problems:
- LRU cleaning can get state into a weird state: #2744
- Cache cleaning can block things, and is generally a mess: #3261, #4383
- Negative answers from e.g. a random subdomain attack can push out useful things: #2495, #1831
- ADB vs. cache size is hardcoded and nobody knows if this is optimal or not: #2483, #2405
- Sizing is hard to get right: #614
- Cache is child-centric: #3311
- RRSIGs and not tightly bound to respective RR: #3396
- Data structures referenced by RBTDB are a mess: #4356, #3403, #3405Štěpán BalážikŠtěpán Balážikhttps://gitlab.isc.org/isc-projects/kea/-/issues/3280Fix doxygen errors2024-03-12T16:00:39ZThomas MarkwalderFix doxygen errorsThere are a slew of doxygen errors that should be fixed. I attached an error report[doxygen-error.log](/uploads/cba7a4ce50a93cad07e9477202585ee5/doxygen-error.log)There are a slew of doxygen errors that should be fixed. I attached an error report[doxygen-error.log](/uploads/cba7a4ce50a93cad07e9477202585ee5/doxygen-error.log)kea2.5.7Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3279ddns[46]_update documented argument names incorrect2024-03-27T15:17:48ZPatrick Armitageddns[46]_update documented argument names incorrectsrc/bin/dhcp[46]/dhcp[46]_hooks.dox document arguments _fwd_update_, _rev_update_ and _ddns_params_. Using these parameter names causes an exception to be thrown:
```
ERROR HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook ddns...src/bin/dhcp[46]/dhcp[46]_hooks.dox document arguments _fwd_update_, _rev_update_ and _ddns_params_. Using these parameter names causes an exception to be thrown:
```
ERROR HOOKS_CALLOUT_EXCEPTION exception thrown by callout on hook ddns4_update registered by library with index 1 (callout address 0x7fff875b8ffc): unable to find argument with name fwd_update
```
The names for these arguments in the code are _fwd-update_, _rev-update_ and _ddns-param_, i.e. the _'s should be -'s.
The following patch corrects the issue:
```
commit 67063ae09d2c1f924586404eea2fa85a328bccb5 (HEAD -> master)
Author: Quentin Armitage <quentin@armitage.org.uk>
Date: Thu Feb 29 17:44:38 2024 +0000
Fix documentation for ddns[46]_update hooks
The documented argument names fwd_update, rev_update and ddns_params
should be fwd-update, rev_update and ddns-params.
Signed-off-by: Quentin Armitage <quentin@armitage.org.uk>
diff --git a/src/bin/dhcp4/dhcp4_hooks.dox b/src/bin/dhcp4/dhcp4_hooks.dox
index ae6c903ff9..ed0620e035 100644
--- a/src/bin/dhcp4/dhcp4_hooks.dox
+++ b/src/bin/dhcp4/dhcp4_hooks.dox
@@ -260,9 +260,9 @@ called before "subnet4_select".
- name: @b response4, type: isc::dhcp::Pkt4Ptr, direction: <b>in</b>
- name: @b subnet4, type: isc::dhcp::Subnet4Ptr, direction: <b>in</b>
- name: @b hostname, type: std::string, direction: <b>in/out</b>
- - name: @b fwd_update, type: bool, direction: <b>in/out</b>
- - name: @b rev_update, type: bool, direction: <b>in/out</b>
- - name: @b ddns_params, type: isc::dhcp::DdnsParamsPtr, direction: <b>in</b>
+ - name: @b fwd-update, type: bool, direction: <b>in/out</b>
+ - name: @b rev-update, type: bool, direction: <b>in/out</b>
+ - name: @b ddns-params, type: isc::dhcp::DdnsParamsPtr, direction: <b>in</b>
- @b Description: this callout is executed after the server has selected
a lease and has formed a host name to associate with the lease and/or use
@@ -272,17 +272,17 @@ called before "subnet4_select".
host name as well as whether or not forward and/or reverse updates are
enabled.
- Upon entry into the callout, the arguments <b>hostname</b>,<b>fwd_update</b>,
- and <b>rev_update</b> have been set by the server based on the client packet,
+ Upon entry into the callout, the arguments <b>hostname</b>,<b>fwd-update</b>,
+ and <b>rev-update</b> have been set by the server based on the client packet,
and various configuration values (e.g host reservations, DDNS behavioral
parameters, etc). Upon return from the callout, any changes to these
values will be applied as follows:
- If <b>hostname</b> has changed it will be used to update the outbound
host name (option 12) if it exists, the output FQDN option (option 81)
if it exists, and used as the FQDN sent in DNS updates
- - Forward DNS update(s) will be done if <b>fwd_update</b> is true (and
+ - Forward DNS update(s) will be done if <b>fwd-update</b> is true (and
<b>kea-dhcp-ddns</b> connectivity is enabled)
- - Reverse DNS update(s) will be done if <b>rev_update</b> is true (and
+ - Reverse DNS update(s) will be done if <b>rev-update</b> is true (and
<b>kea-dhcp-ddns</b> connectivity is enabled)
- <b>Next step status</b>: Not applicable, its value will be ignored.
```
There appears to be no tests for the ddns[46]_update hooks. Should some be added?kea2.6.0https://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 Markwalder