Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-02-22T15:00:09Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3255CA reconfig doesn't pick up on new certificates2024-02-22T15:00:09ZPeter DaviesCA reconfig doesn't pick up on new certificatesCA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed...CA reconfig doesn't pick up on new certificates:
After changing the certificates directory in the kea-ctrl-agent configuration
file and sending a SIGHUP signal, kea-ctrl-agent reports
DCTL_CONFIG_COMPLETE server has completed configuration:
However, the agent still uses the old certificates:
Users that employ the systemd restart command may expect a different behaviour
A workaround would be to kill the process and restart a new one.
[000016830](https://isc.lightning.force.com/lightning/r/Case/500S60000055eAC/view)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3223kea v4 returns status-get 0 when not connected to database2024-02-21T09:17:05ZMarcin Godzinakea v4 returns status-get 0 when not connected to databaseDuring the missing lease database connection process, we send 'status-'get' to Kea.
Kea v6 returns:
```
{
"result": 1,
"text": "Error during command processing: no current lease manager is available"
}
```
Kea v4 returns norm...During the missing lease database connection process, we send 'status-'get' to Kea.
Kea v6 returns:
```
{
"result": 1,
"text": "Error during command processing: no current lease manager is available"
}
```
Kea v4 returns normal status:
```
{
"arguments": {
"multi-threading-enabled": true,
(...)
"uptime": 4
},
"result": 0
}
```
Getting result 0 on kea4 is misleading when there is no database connection.
**These features should be included in tests `tests/dhcp/test_database.py::test_db_retry*`. Please inform QA about the merging solution for this issue.**next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/3082kea-ctrl-agent and dual stack listening2024-03-21T11:45:53ZDarren Ankneykea-ctrl-agent and dual stack listeningThe `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure...The `kea-ctrl-agent` can presently only listen on one address, be that an IPv4 or IPv6 address. If you have a dual stack on the equipment where you want to listen, then you have to choose either the IPv4 or the IPv6 address to configure in the `kea-ctrl-agent.json`.
I propose to add a new parameter to the kea-ctrl-agent configuration "http-hosts" as shown:
```
{
"Control-agent": {
"http-hosts": [
"2001:db8::2",
"10.1.2.2"
],
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
This would allow listening on multiple IP addresses especially in a dual stack environment. Also, the new parameter would preserve backward compatibility.
FYI: I did solve this problem by running two copies of the `kea-ctrl-agent`. However, I'm not convinced that is a good solution. Configurations and other details included below for illustration.
<details><summary>kea-dhcp4.json</summary>
```
{
"Dhcp4": {
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
},
"interfaces-config": {
"interfaces": [
"ens256"
]
},
"lease-database": {
"type": "memfile",
"persist": false
},
"subnet4": [
{
"subnet": "10.1.2.0/24",
"id": 1,
"option-data": [
{
"name": "routers",
"data": "10.1.2.1"
}
],
"pools": [
{
"pool": "10.1.2.100 - 10.1.2.254"
}
]
}
],
"loggers": [
{
"name": "kea-dhcp4",
"severity": "INFO",
"output_options": [
{
"output": "stdout"
}
]
}
]
}
}
```
</details>
<details><summary>kea-ctrl-agent-v4.json</summary>
```
{
"Control-agent": {
"http-host": "10.1.2.2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>kea-ctrl-agent-v6.json</summary>
```
{
"Control-agent": {
"http-host": "2001:db8::2",
"http-port": 8000,
"control-sockets": {
"dhcp4": {
"socket-type": "unix",
"socket-name": "/tmp/socket4"
}
}
}
}
```
</details>
<details><summary>Configuration of ens256</summary>
```
3: ens256: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:c0:5f:47 brd ff:ff:ff:ff:ff:ff
altname enp26s0
inet 10.1.2.2/24 brd 10.1.2.255 scope global ens256
valid_lft forever preferred_lft forever
inet6 2001:db8::2/64 scope global
valid_lft forever preferred_lft forever
inet6 fe80::20c:29ff:fec0:5f47/64 scope link
valid_lft forever preferred_lft forever
```
</details>
<details><summary>Daemon command lines</summary>
```
kea-dhcp4 -c kea-dhcp4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v4.json
```
```
kea-ctrl-agent -c kea-ctrl-agent-v6.json
```
</details>
<details><summary>Send config-get with curl to both</summary>
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://10.1.2.2:8000/ | jq
```
```
curl -X POST -H "Content-Type: application/json" -d '{ "command": "config-get", "service": [ "dhcp4" ] }' http://[2001:db8::2]:8000/
```
</details>
Both returned a result successfully.
[SF1260](https://isc.lightning.force.com/lightning/r/Case/5007V00002X2x4cQAB/view)next-stable-3.0https://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/1562command_processed hook not tested or documented in CA2022-08-01T13:27:57ZTomek Mrugalskicommand_processed hook not tested or documented in CAThis was discovered in #1421 that the `command_processed` hook point is not documented and not tested.
With the upcoming RBAC, we need to improve the testing situation.This was discovered in #1421 that the `command_processed` hook point is not documented and not tested.
With the upcoming RBAC, we need to improve the testing situation.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1537Kea CA port 8000 clashes with other daemons2022-11-02T15:10:17ZCarsten StrotmannKea CA port 8000 clashes with other daemonsHi,
the Kea control agent uses port 8000 by default. It a lot of new projects (Python, Go, Rust based projects) in the last 10 years have chosen this same port, and now admins have to work around this by changing the defaults.
Would it...Hi,
the Kea control agent uses port 8000 by default. It a lot of new projects (Python, Go, Rust based projects) in the last 10 years have chosen this same port, and now admins have to work around this by changing the defaults.
Would it be possible to register dedicated port(s) with IANA for Kea services (and change the defaults to use these ports instead of 8000) to lower the possibility of port clashes?
Greetings
Carstenbacklog