Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-09-21T13:53:17Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3064performance drop during 2.3 release cycle for mysql2023-09-21T13:53:17ZWlodzimierz Wencelperformance drop during 2.3 release cycle for mysqlWe observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at...We observed huge performance drop during 2.3 release cycle, Exactly between 2.3.8 and 2.3.9
![Screenshot_2023-09-14_at_09.55.50](/uploads/06cdfb127f6609246e68c58d63663a2e/Screenshot_2023-09-14_at_09.55.50.png)
![Screenshot_2023-09-14_at_09.57.01](/uploads/d9fb7fbabb11d49faa3e40efbd6f4bac/Screenshot_2023-09-14_at_09.57.01.png)
Please check [report on master](https://jenkins.aws.isc.org/job/kea-dev/job/performance/lastSuccessfulBuild/artifact/qa-dhcp/kea/performance-jenkins/report.html), during this work I was testing migration to binary addresses in mysql and this did not show performance degradation in [the report](https://jenkins.aws.isc.org/view/Kea-manual/job/kea-manual/job/performance/108/artifact/qa-dhcp/kea/performance-jenkins/report.html)next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3062Any interface created while retrying sockets are used unfiltered2024-02-08T14:35:31ZEfe Can İçözAny interface created while retrying sockets are used unfiltered
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in conf...
**Describe the bug**
While retrying an interface that didn't met the socket requirements in `IfaceMgr::openSockets4` yet, if new interfaces registered to system Kea DHCP4 server listens those interfaces even they are not listed in configuration file.
**To Reproduce**
Steps to reproduce the behavior:
1. Set a dummy interface and ensure that it's down.
`ip link add dummy0 type dummy`
`ip addr add 192.168.1.1/24 dev dummy0`
`ip link set dummy0 down`
2. Run Kea dhcp4 server with the following config
{
"Dhcp4": {
"valid-lifetime": 4000,
"renew-timer": 1000,
"rebind-timer": 2000,
"interfaces-config": {
"interfaces": [ "dummy0/192.168.1.1" ],
"service-sockets-max-retries": 1000,
"service-sockets-retry-wait-time": 1000
},
"lease-database": {
"type": "memfile",
"persist": true,
"name": "/var/lib/dhcp4.leases"
},
"subnet4": [
{
"subnet": "192.168.1.0/24",
"interface": "dummy0",
"pools": [
{
"pool": "192.168.1.4 - 192.168.1.254",
}
]
}
]
}
}
3. At this point Kea will print `DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: the interface dummy0 is down` messages.
4. Add another interface with
`ip link add dummy1 type dummy`
`ip addr add 10.10.1.1/24 dev dummy1`
`ip link set dummy1 up`
5. Set dummy0 online to let Kea run
`ip link set dummy1 up`
6. Check open sockets by Kea
`netstat -tulpan | grep kea` which is
udp 0 0 192.168.1.1:67 0.0.0.0:* 694387/kea-dhcp4
udp 0 0 10.10.1.1:67 0.0.0.0:* 694387/kea-dhcp4
**Expected behavior**
Server should only listen _dummy0_ interface.
**Environment:**
- Kea version: 2.2.0
- OS: Ubuntu 22.04.3 x64
**Additional Information**
This issue happened also on our custom yocto build on imx8qxp with aarch64next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3061Include wildcards2023-09-21T13:48:46ZTomek MrugalskiInclude wildcardsOne Kea user wrote:
> we use puppet to define our service configurations and Kea seems to have support for including a single file, yet not a complete directory that we could fill easily. That kind of including a full directory that is ...One Kea user wrote:
> we use puppet to define our service configurations and Kea seems to have support for including a single file, yet not a complete directory that we could fill easily. That kind of including a full directory that is exclusive under control of a configuration management solution seems to be lacking and causes us to add a preparser to the deployment, which is very well possible but somewhat doesn't feel right. Are we simply not seeing "the solution" that you originally designed here?
This is a proposal to extend the syntax `<?include "file.json"?>` to be able to use wildcards and include multiple files.
Personally, I don't think this would be a very popular feature. But on the other hand, it opens up some interesting use cases.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3057Update Template Classes in the ARM2024-03-22T06:23:10ZPeter DaviesUpdate Template Classes in the ARMTo save duplicating work in updating two sources of documentation it has been
suggested the the KB article about [template](https://kb.isc.org/docs/facilitating-classification-with-template-classes) classes could be moved to the ARM. ...To save duplicating work in updating two sources of documentation it has been
suggested the the KB article about [template](https://kb.isc.org/docs/facilitating-classification-with-template-classes) classes could be moved to the ARM.
The "Facilitating Classification with Template Classes" KB article contain the
following use case examples:
Example. OUI Vendor
Use case 1. Reference the spawned class directly in configuration
Use case 2. Have a class dependency on the template class or spawned class
Use case 3. Define the spawned class
Use case 4. Lease limiting and rate limiting ok
The following examples are not found in the ARM:
Use case 1. Reference the spawned class directly in configuration
Use case 2. Have a class dependency on the template class or spawned classnext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3056libdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) pack...2023-09-23T09:04:56ZEddict NLlibdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) package in Cloudsmith---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
libdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) package in Cloudsmith
**To Reproduce**
Steps to reproduce the behavior:
1...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
libdhcp_user_chk.so missing from isc-kea-hooks (2.4.0-isc20230630120747) package in Cloudsmith
**To Reproduce**
Steps to reproduce the behavior:
1. Add ISC Kea 2.4 Cloudsmith repository (https://dl.cloudsmith.io/public/isc/kea-2-4/deb/debian bookworm InRelease)
2. apt install (isc-kea and) isc-kea-hooks
3. there are 8 .so files in /usr/lib/x86_64-linux-gnu/kea/hooks/
4. libdhcp_user_chk.so is missing
**Expected behavior**
libdhcp_user_chk.so is installed as well
**Environment:**
- Kea version: 2.4.0 installed from repository
- OS: Debian GNU/Linux 12 (bookworm)
- Which features were compiled in: N/A
- If/which hooks where loaded in
**Additional Information**
N/A
**Contacting you**
How can ISC reach you to discuss this matter further? herenext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3049permit ddns-qualifying-suffix option in pool scope2023-09-21T18:21:11Zalimdipermit ddns-qualifying-suffix option in pool scopeHi Folks,
I'm happy with kea dhcp so far as it really fulfills the needs.
However when it come to ddns, I'm a bit frustrated as it's not possible to segragate pool clients in different dns zones.
ddns-qualifying-suffix is either global,...Hi Folks,
I'm happy with kea dhcp so far as it really fulfills the needs.
However when it come to ddns, I'm a bit frustrated as it's not possible to segragate pool clients in different dns zones.
ddns-qualifying-suffix is either global, shared network or subnet but **not** pool.
Let's say I want all defined client in a subnet (those with reservation) to have a fqdn foo.bar and the unknown ones (choosed from the pool) to have guest.foo.bar, didn't find a way to do it.
It would be really helpful to scope ddns-qualifying-suffix to poolbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3047Detection of packet processing slowdown2024-03-22T13:16:46ZDarren AnkneyDetection of packet processing slowdownSometimes Kea will find itself unable to keep up with incoming packet load for various reasons (overwhelming amounts of packets in an avalanche scenario, slowdown in SQL queries in the case of database usage, and etc). Kea currently has...Sometimes Kea will find itself unable to keep up with incoming packet load for various reasons (overwhelming amounts of packets in an avalanche scenario, slowdown in SQL queries in the case of database usage, and etc). Kea currently has no way to detect or warn about this situation. Detailed analysis of the logs is necessary to understand what is happening. This issue is meant to provide some ideas for future development in this area where Kea could possibly detect this situation and provide warning log messages about it.
Possible ideas:
1. Add timestamps to received packets (possible? [perhaps](https://www.kernel.org/doc/Documentation/networking/timestamping.txt)) as they are put into the buffer. Check these timestamps against the current time as they are pulled out of the buffer. If there is some discrepancy that is larger than some threshold, emit some kind of log message about this.
2. In `netstat -l` output, there is a representation of the current buffer size for a process. Example:
```
$ netstat -l
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
...
udp 0 0 10.1.2.2:bootps 0.0.0.0:*
```
Administrators sometimes use this to find out if some process has a slowdown in processing packets. If the number is larger than normal, then there might be. Kea may not necessarily know what is normal, but there must be some maximum size of the Recv-Q. If so, perhaps this maximum size is being reached when these backups occur. If that could be detected, perhaps a warning message could be logged.
[RT22378](https://support.isc.org/Ticket/Display.html?id=22378)kea2.5.8Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/3040failure to start up with ppp interfaces2024-02-08T14:35:31ZJaco Kroonfailure to start up with ppp interfaces2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed...2023-08-31 23:34:48.506 WARN [kea-dhcp6.dhcpsrv/27456.140590317625408] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open multicast socket on interface ppp0, reason: Failed to open link-local socket on interface ppp0: Failed to bind socket 20 to fe80::e/port=547: Cannot assign requested address
```
26: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1350 qdisc tbf state UNKNOWN group default qlen 3
inet6 fe80::14e4:139f:8862:3dfd peer fe80::e/128 scope link
valid_lft forever preferred_lft forever
```
Obviously we should bind to the local link-local, not the remote one.
kea 2.4.0. 2.5.1 segfaults on my configuration:
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "ppp0" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/run/kea/kea6-ctrl-socket"
},
"lease-database": {
"type": "memfile",
"lfc-interval": 3600
},
"expired-leases-processing": {
"reclaim-timer-wait-time": 10,
"flush-reclaimed-timer-wait-time": 25,
"hold-reclaimed-time": 3600,
"max-reclaim-leases": 100,
"max-reclaim-time": 250,
"unwarned-reclaim-cycles": 5
},
"renew-timer": 1000,
"rebind-timer": 2000,
"preferred-lifetime": 3000,
"valid-lifetime": 4000,
"option-data": [
{
"name": "dns-servers",
"data": "2c0f:f720::..., 2c0f:f720::..."
}
],
"subnet6": [
{
"subnet": "2c0f:f720:fcf0::/44",
"pd-pools": [
{
"prefix": "2c0f:f720:fcf0::",
"prefix-len": 44,
"delegated-len": 56
}
]
}
],
"loggers": [
{
"name": "kea-dhcp6",
"output_options": [
{
"output": "/var/log/kea/kea-dhcp6.log"
}
],
"severity": "DEBUG",
"debuglevel": 99
}
]
}
}
```
Strace from a re-run (so socket number is different):
```
bind(19, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 0
getsockname(19, {sa_family=AF_NETLINK, nl_pid=6688, nl_groups=00000000}, [12]) = 0
sendto(19, [{nlmsg_len=20, nlmsg_type=RTM_GETLINK, nlmsg_flags=NLM_F_REQUEST|NLM_F_DUMP, nlmsg_seq=1, nlmsg_pid=0}, {ifi_family=AF_PACKET, ...}], 20, 0, {sa_family=AF_NETLINK, nl_pid=0, nl_groups=00000000}, 12) = 20
recvmsg(19, {msg_name={sa_family=AF_NETLINK ...
ifa_index=if_nametoindex("ppp0")}, [[{nla_len=20, nla_type=IFA_LOCAL}, **inet_pton(AF_INET6, "fe80::14e4:139f:8862:3dfd")], [{nla_len=20, nla_type=IFA_ADDRESS}, inet_pton(AF_INET6, "fe80::e")],** [{nla_len=20, nla_type=IFA_CACHEINFO}, {ifa_prefered=4294967295, ifa_valid=4294967295, cstamp=168714876, tstamp=168714876}], [{nla_len=8, nla_type=IFA_FLAGS}, IFA_F_PERMANENT]]], [{nlmsg_len=72, nlmsg_type=RTM_NEWADDR, nlmsg_flags=NLM_F_MULTI, nlmsg_seq=2, nlmsg_pid=6688}, {ifa_family=AF_INET6, ifa_prefixlen=64, ifa_flags=IFA_F_PERMANENT, ifa_scope=RT_SCOPE_LINK,
...
close(19) = 0
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC, 0) = 19
ioctl(19, SIOCGIFINDEX, {ifr_name="ppp0", ifr_ifindex=26}) = 0
close(19) = 0
socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 19
fcntl(19, F_SETFD, FD_CLOEXEC) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEADDR, [1], 4) = 0
setsockopt(19, SOL_SOCKET, SO_REUSEPORT, [1], 4) = 0
setsockopt(19, SOL_IPV6, IPV6_V6ONLY, [1], 4) = 0
bind(19, {sa_family=AF_INET6, sin6_port=htons(547), sin6_flowinfo=htonl(0), inet_pton(AF_INET6, "**fe80::e**", &sin6_addr), sin6_scope_id=if_nametoindex("ppp0")}, 28) = -1 EADDRNOTAVAIL (Cannot assign requested address)
close(19) = 0
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3039HA+MT+TLS, certificates and keys on both servers2023-09-21T13:29:33ZFabian WittHA+MT+TLS, certificates and keys on both servers# Setup:
I setuped KEA for our internal network, in place of isc-dhcp and wanted to go with https for High Availability. Its a simple setup with 2 servers with mt, ha, tls, one subnet and one host-reservation.
# Problem:
After I created...# Setup:
I setuped KEA for our internal network, in place of isc-dhcp and wanted to go with https for High Availability. Its a simple setup with 2 servers with mt, ha, tls, one subnet and one host-reservation.
# Problem:
After I created Certs and Keys with our internal CA and Kea worked. But it only works when I have both certs and keys on both machines. So I need to send my certificate private key over network to the other server. And since certs are running out it needs to send them regularly.
# Question:
Why do all servers need the certs and keys of all the other servers? Is there a way to automate that process via kea directly or am I missing something?outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/3037Kea / hostapd conflict2023-09-21T17:55:21ZThomas KöllerKea / hostapd conflictI am currently migrating my DHCP server setup from dhcpd to kea. While doing so, I came across a problem that so far I have been unable to solve.
There are three network interfaces on my system that are relevant here, namely lan_wifi (3...I am currently migrating my DHCP server setup from dhcpd to kea. While doing so, I came across a problem that so far I have been unable to solve.
There are three network interfaces on my system that are relevant here, namely lan_wifi (3), lan_ether (4), and a bridge interface br_lan (6), of which these two are slaves:
```
[thomas@sarkovy ~]$ networkctl list
IDX LINK TYPE OPERATIONAL SETUP
1 lo loopback carrier unmanaged
2 enp38s0 ether off unmanaged
3 lan_wifi ether enslaved configured
4 lan_ether ether enslaved configured
5 eth_cable ether routable configured
6 br_lan bridge routable configured
6 links listed.
```
In my existing dhcpd-based setup, there is an instance of the hostapd daemon running on the lan_wifi interface:
```
[root@sarkovy kea]# lsof -i udp:67
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
hostapd 18322 root 5u IPv4 288312 0t0 UDP *:bootps
dhcpd 19279 dhcpd 8u IPv4 312588 0t0 UDP *:bootps
```
Both these daemons apparently co-exist just fine. If, however, I try to replace dhcpd with kea-dhcp4, a conflict arises:
```
Aug 31 11:57:18 sarkovy kea-dhcp4[19308]: 2023-08-31 11:57:18.970 WARN [kea-dhcp4.dhcpsrv/19308.140339384615296] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open socket on interface br_lan, reason: failed to bind fallback socket to address 192.168.0.1, port 67, reason: Address already in use - is another DHCP server running?
Aug 31 11:57:18 sarkovy kea-dhcp4[19308]: 2023-08-31 11:57:18.970 INFO [kea-dhcp4.dhcp4/19308.140339384615296] DHCP4_OPEN_SOCKETS_FAILED maximum number of open service sockets attempts: 0, has been exhausted without success
```
I have to stop hostapd in order to be able to start kea-dhcp4. Unfortunately, I need both of them. My kea configuration includes the following "interfaces-config" section:
```
"interfaces-config": {
"interfaces": [ "br_lan/192.168.0.1" ],
"dhcp-socket-type": "raw",
"service-sockets-require-all": true
},
```
Is there anything I can do to resolve this conflict?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3035Expose interface-id in dhcpv6 hook points2023-09-21T13:22:34ZSorin EsanuExpose interface-id in dhcpv6 hook pointsHello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!Hello!
I see useful to expose option18 (interface id) and, eventually, option37 (remote id) to dhcpv6 hook points, in a similar way that option82 is sent in dhcpv4 hook points (QUERY4_OPTION_82 or QUERY4_OPTION_82_SUB_OPTION_1).
Thank you!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3024Post audit: Write KB article/ARM section about securing DB connection2023-09-21T10:10:03ZTomek MrugalskiPost audit: Write KB article/ARM section about securing DB connectionAs pointed out in [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#12-secure-db-connection), we should have a kind of tutorial or step by step guide how to secure Kea and MariaDB/Postgres connect...As pointed out in [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#12-secure-db-connection), we should have a kind of tutorial or step by step guide how to secure Kea and MariaDB/Postgres connection.
I think this would be best achieved by having a config example in the ARM + a KB article explaining how to do the changes in Maria/Postgres installations.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3023Implement RFC3118: DHCPv4 authentication2023-09-21T10:10:23ZTomek MrugalskiImplement RFC3118: DHCPv4 authenticationAs pointed out by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#14-support-authentication-in-dhcpv4-protocol), we should implement RFC3118 (DHCPv4 authentication).As pointed out by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#14-support-authentication-in-dhcpv4-protocol), we should implement RFC3118 (DHCPv4 authentication).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3022Post audit: retire MD5 and SHA12023-09-21T10:10:13ZTomek MrugalskiPost audit: retire MD5 and SHA1By using MD5 in particular and SHA1 to some degree, we risk getting more complaints, even if those are used in contexts that are not security related. Some procurement processes might simply ask if obsolete and broken algorithms are in u...By using MD5 in particular and SHA1 to some degree, we risk getting more complaints, even if those are used in contexts that are not security related. Some procurement processes might simply ask if obsolete and broken algorithms are in use. If they are, the software might be determined not suitable.
In one case, we had an interaction with a user who had those explicitly disabled in their deployment for security reasons.
If we decide to keep those, there should be a very good explanation in the ARM why keeping those is acceptable. "because getting rid of them is a lot of work" is not a good explanation.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3021Post audit: update ARM to show how to confirm source code integrity2023-09-21T10:09:54ZTomek MrugalskiPost audit: update ARM to show how to confirm source code integrityAnother proposal by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). We should document how to check the integrity of the source code ...Another proposal by [@manu's audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). We should document how to check the integrity of the source code (and packages, too).
With the SBOM being increasingly focused, this is an important aspect. Fortunately, it's very easy doc update.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3020Post audit: investigate if basic auth with http could be discouraged2023-09-21T10:09:47ZTomek MrugalskiPost audit: investigate if basic auth with http could be discouragedAnother [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth o...Another [report by @manu](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#10-remote-administrative-access-authentication-restful-api). The overall idea is to strongly discourage people from running basic auth over plain HTTP. It's insecure, but maybe in some experiments it might be useful, so we probably shouldn't forcibly abort.
But perhaps print a warning with a link to ARM section explaining why it's wrong would do?next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3050Post audit: tighten access permissions for configs2023-09-21T17:00:32ZTomek MrugalskiPost audit: tighten access permissions for configsAnother point after @manu's [audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#9-limiting-permission-of-the-kea-configuration-files):
I would propose considering the following:
* [ ] put a WARNING sectio...Another point after @manu's [audit](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023#9-limiting-permission-of-the-kea-configuration-files):
I would propose considering the following:
* [ ] put a WARNING section to the config files (close to the sections where password/key is configured) with a link to guide how to setup it up correctly so the administrator has at least a chance to notice it and follow the recommendation
* [ ] let service during startup/reload if the password or key secret is present and display/log warning (?with link to the guide?)
* [x] change access permissions to 0640 by default (instead of 0644); in other words, remove read rights for 'other'. Note: User/group ownership should be 'root' or the 'user' under which kea is running.
While the second would probably be tricky to implement, so we might skip it, proposals 1 and 3 are solid and we should do it.
This ticket is about updating the packages. Some might argue that similar action should be done for Kea sources (e.g. make sure the make install install the sources with more restrictive permissions).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3018motd (message of the day) in kea2023-08-24T13:35:43ZTomek Mrugalskimotd (message of the day) in keaWe could implement a message in Kea, the if configured, would be logged when Kea is started or reconfigured. Trivial to implement.
This would be useful in Docker. We need to put some config file in a Docker image, with the expectation t...We could implement a message in Kea, the if configured, would be logged when Kea is started or reconfigured. Trivial to implement.
This would be useful in Docker. We need to put some config file in a Docker image, with the expectation that the user will replace it with a real config. If the user doesn't, Kea should start, but print something like "please edit your config file, map your volume when starting Docker image, etc.". The text would be configurable in a config file.
This is similar to Unix idea of `/etc/motd` (its content is printed as a welcome message to the user every time he/she logs in).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3015Post audit: update docs2023-09-21T10:10:46ZTomek MrugalskiPost audit: update docs@manu completed an audit and pointed the following problems [in his report](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023):
- [ ] 2. Elaborate more about \[meta\] package, in particular how to run only selec...@manu completed an audit and pointed the following problems [in his report](https://gitlab.isc.org/isc-private/kea/-/wikis/Kea-Security-Review-02-2023):
- [ ] 2. Elaborate more about \[meta\] package, in particular how to run only selected service. Looks like a good idea also to update the security section and point out that one should only run the services that are strictly needed.
- [ ] 3. Elaborate more about `interface` requirement for making the service running in [ARM QuickStart section](https://kea.readthedocs.io/en/kea-2.2.0/arm/quickstart.html#quick-start-guide-for-dhcpv4-and-dhcpv6-services) - this should be easy, a sentence or two pointing out that binding address is by default set to defensive 127.0.0.1.
- [ ] 4. Correct references in configs
- [ ] 5. Clarify sentence in DDNS (it's `dhcp-ddns` in `Dhcp4` or `Dhcp6`)
- [ ] 6. Clarify about sockets open by default (add something like this "While Kea doesn't open any sockets by default on its own, the default configs shipped with packages do define some socket and Kea opens them).next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3013Prepared statement needs to be re-prepared2023-08-24T13:27:42ZYehuda KatzPrepared statement needs to be re-prepared**Describe the bug**
This probably doesn't qualify as a Kea bug, but I thought it might be worth asking about.
We are running 2 kea servers with a shared MySQL (MariaDB) backend. We recently upgraded from MariaDB 10.3 to MariaDB 10.5.
W...**Describe the bug**
This probably doesn't qualify as a Kea bug, but I thought it might be worth asking about.
We are running 2 kea servers with a shared MySQL (MariaDB) backend. We recently upgraded from MariaDB 10.3 to MariaDB 10.5.
We replaced the `hosts` table with a `hosts_history` TABLE (added a `deleted_at` column to allow for keeping host history) and a `hosts` VIEW that only shows non-deleted items. This has been working for us for many years.
Everything seems to work for a while until randomly, we start getting errors for systems with host reservations.
The error in the log is:
```
2023-08-14 18:52:59.613 DEBUG [kea-dhcp4.bad-packets/169655.139690552555648] DHCP4_PACKET_DROP_0007 [hwtype=1 xx:xx:xx:xx:xx:17], cid=[no info], tid=0xee1b36c3
: failed to process packet: unable to execute for <SELECT h.host_id, h.dhcp_identifier, h.dhcp_identifier_type, h.dhcp4_subnet_id, h.dhcp6_subnet_id, h.ipv4_address, h.hostname, h.dhcp4_client_classes, h.dhcp6_client_classes, h.us
er_context, h.dhcp4_next_server, h.dhcp4_server_hostname, h.dhcp4_boot_file_name, h.auth_key, o.option_id, o.code, o.value, o.formatted_value, o.space, o.persistent, o.user_context FROM hosts AS h LEFT JOIN dhcp4_options AS o ON h
.host_id = o.host_id WHERE h.dhcp4_subnet_id = ? AND h.dhcp_identifier_type = ? AND h.dhcp_identifier = ? ORDER BY h.host_id, o.option_id>, reason: Prepared statement needs to be re-prepared (error code 1615)
```
When this happens, the host making the request gets no response, not even an error. (Similar to #281?)
It is not clear exactly how to reproduce this error. We even created a completely new copy of the database using `kea-admin` and it ran fine for just less than 24 hours before stopping with the same error.
**To Reproduce**
Steps to reproduce the behavior:
1. Create a MySQL database. Rename the `hosts` table to `hosts_history` and create a VIEW for `hosts`:
```sql
CREATE VIEW `hosts` AS select distinct `hosts_history`.`host_id` AS `host_id`,
`hosts_history`.`dhcp_identifier` AS `dhcp_identifier`,`hosts_history`.`dhcp_identifier_type` AS `dhcp_identifier_type`,
`hosts_history`.`dhcp4_subnet_id` AS `dhcp4_subnet_id`,`hosts_history`.`dhcp6_subnet_id` AS `dhcp6_subnet_id`,
`hosts_history`.`ipv4_address` AS `ipv4_address`,`hosts_history`.`hostname` AS `hostname`,`hosts_history`.`dhcp4_client_classes` AS `dhcp4_client_classes`,
`hosts_history`.`dhcp6_client_classes` AS `dhcp6_client_classes`,`hosts_history`.`dhcp4_next_server` AS `dhcp4_next_server`,
`hosts_history`.`dhcp4_server_hostname` AS `dhcp4_server_hostname`,`hosts_history`.`dhcp4_boot_file_name` AS `dhcp4_boot_file_name`,
`hosts_history`.`user_context` AS `user_context`,`hosts_history`.`auth_key` AS `auth_key`
from `hosts_history` where `hosts_history`.`deleted` IS NULL
```
1. Run Kea dhcp4 with standard mysql configuration
1. The client uses the standard linux dhclient or the Nagios `check_dhcp` plugin.
1. The server usually send standard responses except sometimes when it logs this error and sends no response.
**Expected behavior**
1. Valid responses should always be sent
2. An error should be sent back to the client when there is a server error.
**Environment:**
- Kea version: Supplied from RHEL9 EPEL respository
```
# kea-dhcp4 -V
2.2.0
tarball
linked with:
log4cplus 2.0.5
OpenSSL 3.0.7 1 Nov 2022
database:
MySQL backend 14.0, library 3.2.6
PostgreSQL backend 13.0, library 130011
Memfile backend 2.1
```
- OS: RHEL 9.2outstanding