Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-11-30T14:32:43Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3176Kea disables logging if configured without an `output-options`2023-11-30T14:32:43ZAndrei Pavelandrei@isc.orgKea disables logging if configured without an `output-options`To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dh...To replicate, start a `kea-dhcp6` with a configuration that has the `loggers` entry for the general logger `kea-dhcp6` that does not have an `output-options` entry.
```json
{
"Dhcp6": {
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
}
```
Or set the same configuration through unix socket or kea-ctrl-agent (maybe while still preserving the control-socket, that's why it's there):
```json
{
"arguments": {
"Dhcp6": {
"control-socket": {
"socket-name": "/tmp/kea-dhcp6-ctrl.sock",
"socket-type": "unix"
},
"loggers": [
{
"name": "kea-dhcp6",
"severity": "INFO"
}
]
}
},
"command": "config-set",
"service": [
"dhcp6"
]
}
```
You get this and no more logging after that.
```
log4cplus:ERROR No appenders could be found for logger (kea-dhcp6.hosts).
log4cplus:ERROR Please initialize the log4cplus system properly.
```
This contradicts the ARM which says:
> Each logger can have zero or more `output-options`.
It replicates with subloggers too. Only the sublogger is affected in that case.
You can have `interfaces-config` and `subnet6` and anything else besides it.
DHCP traffic works. Commands work. Logging does not.
It also replicates on `kea-dhcp4`.
There is the workaround of reconfiguring with `output-options`. Logging recovers after that.
Also found a typo in the ARM: `output_commands` should be `output-options`.
Suggested actions:
* [ ] Make logging work when `output-options` is not configured with the documented default of `stdout` as output option.
* [ ] Fix the typo in the ARM: `output_commands` should be `output-options`.next-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/2825Deprecate extended JSON in favor for compliant JSON comments2023-04-20T12:55:56ZCarsten StrotmannDeprecate extended JSON in favor for compliant JSON comments---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and incl...---
name: Deprecate extended JSON in favor for compliant JSON comments/includes
Kea DHCP uses an extended JSON format with comments and includes that deviates from "standard" JSON (RFC 8259).
While it is nice to have comments and includes in the configuration file, the current implementation is not compliant with the JSON specs and breaks other tools JSON parser.
For non-trivial Kea DHCP configuration files, it is highly recommended to use a text editor with JSON support (VS Code, VIM, Emacs, BBEdit etc) or a JSON editor. However, the current "extensions" break the JSON support in these tools/editors so that they cannot be used. The loss of these tools is hurting more than the extra functions implemented in the extended JSON format.
I propose that the current extension are being deprecated and replaced with comments and includes that are valid according to the JSON RFC, so that non-Kea tools can be used when working with Kea configuration files.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2824Optimizations in the allocator selection: copy the existing state2023-04-13T13:49:14ZMarcin SiodelskiOptimizations in the allocator selection: copy the existing stateThe random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and ...The random and flq allocators maintain their states. It is particularly long for the FLQ allocator to populate its initial state. It can take from milliseconds to minutes. When a subnet is reconfigured without changing the allocator and the subnet pools, we could perhaps avoid re-building the allocator state but keeping the existing state aside, and then copying the pointer to the allocation state to the new subnet instance. In that case we'd only have the overhead during the startup, renumbering and an allocator change. In all other cases, the reconfiguration would be smooth.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2818Read YAML configuration file2023-04-13T13:47:19ZVicky Riskvicky@isc.orgRead YAML configuration fileIn today's webinar on configuring custom options, a participant asked whether we could enable configuration in YAML instead of JSON. Carsten revealed that he uses a YAML <-> JSON translator so he can work in YAML but still feed Kea JSON....In today's webinar on configuring custom options, a participant asked whether we could enable configuration in YAML instead of JSON. Carsten revealed that he uses a YAML <-> JSON translator so he can work in YAML but still feed Kea JSON. It was suggested that maybe we could make Kea recognize whether the configuration file is in YAML or JSON, and in case of YAML, run this translator first. It seems like there might be a useful usability improvement in here somewhere.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2731Remove dead code in command processing2023-02-09T14:18:22ZTomek MrugalskiRemove dead code in command processingWhile reviewing #2693, @andrei discovered that adding log messages in ControlledDhcpv4Srv::processCommand() section that handles libreload doesn't actually gets triggered when the command are sent over CA or directly over UNIX socket. Th...While reviewing #2693, @andrei discovered that adding log messages in ControlledDhcpv4Srv::processCommand() section that handles libreload doesn't actually gets triggered when the command are sent over CA or directly over UNIX socket. This should be investigated further. Perhaps processCommand() is no longer needed?
See background and details here: https://gitlab.isc.org/isc-projects/kea/-/merge_requests/1895?commit_id=877d1cfad37bd41d7d7db105ff6de0b83ca710e2#note_345720outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2697if require-client-certs is false than cert-file and key-file should not be ne...2023-02-22T14:42:36Zjbbjarnasonif require-client-certs is false than cert-file and key-file should not be necessary---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- A...---
name: Feature request
about: Suggest an idea for this project
---
**Some initial questions**
- Are you sure your feature is not already implemented in the latest Kea version? _No, I am running version `2.2.0-isc20220726061131`_
- Are you sure what you would like to do is not possible using some other mechanisms? _It is possible but wrong._
- Have you discussed your idea on kea-users or kea-dev mailing lists? _No_
**Is your feature request related to a problem? Please describe.**
If you configure `require-client-certs` as false in high availability hooks, you should not be required to declare `cert-file` and `key-file`
It is very important to describe what you would like to do and why?
Why? It doesn't make sense for remote Kea server to require client certificate from other Kea server when it is already configured as non-required.
**Describe the solution you'd like**
A clear and concise description of what you want to happen.
**Example config**
From high availability hook,
```json
"peers": [
{
"auto-failover": true,
"name": "kea-dhcpremote-2.kea-dhcpremote.default.svc.cluster.local.",
"role": "primary",
"url": "http://10.244.0.7:8000/"
},
{
"auto-failover": true,
"cert-file": "/certs/kea-client.crt",
"key-file": "/certs/kea-client.key",
"name": "kea-dhcpremote-1.kea-dhcpremote.default.svc.cluster.local.",
"require-client-certs": false,
"role": "standby",
"trust-anchor": "/certs/ca.crt",
"url": "https://10.244.0.5:8000/"
},
{
"auto-failover": true,
"name": "kea-dhcpremote-0.kea-dhcpremote.default.svc.cluster.local.",
"role": "backup",
"url": "http://10.244.0.10:8000/"
}
]
```
From the above config snippet, the `cert-file` and `key-file` should not be needed.
**Describe alternatives you've considered**
The alternative is to generate a bogus client certificate file and client key file and point to it, **Note** the files do not need to be the correct ones since it is not used.
**Additional context**
Add any other context about the feature request here.
**Funding its development**
Kea is run by ISC, which is a small non-profit organization without any government funding or any permanent sponsorship organizations. Are you able and willing to participate financially in the development costs? _No sorry_
**Participating in development**
Are you willing to participate in the feature development? ISC team always tries to make a feature as generic as possible, so it can be used in wide variety of situations. That means the proposed solution may be a bit different that you initially thought. Are you willing to take part in the design discussions? Are you willing to test an unreleased engineering code? _I would have to ask my employer_
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
_jon.bjarni@menandmice.com_backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2495Kea uses predictable filenames for sockets in /tmp2023-07-05T10:39:19ZParide LegoviniKea uses predictable filenames for sockets in /tmpDebian maintainer of the Kea package here; this is a forward of Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014929 and Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100.
---
The default Kea con...Debian maintainer of the Kea package here; this is a forward of Debian bug https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1014929 and Ubuntu bug https://bugs.launchpad.net/ubuntu/+source/isc-kea/+bug/1863100.
---
The default Kea configuration files place control sockets under `/tmp`, e.g.:
```
+---
| "control-socket": {
| "socket-type": "unix",
| "socket-name": "/tmp/kea4-ctrl-socket"
| },
+---[ /etc/kea/kea-dhcp4.conf ]
```
This can be a security issue, especially given that the socket have fixed names, as any use can create a file/socket with that name under `/tmp`. Please move the control sockets to `/run/kea`. Thanks!next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1253subnet inheritance inconsistencies2022-11-02T15:10:18ZFrancis Dupontsubnet inheritance inconsistenciesThere are some inconsistencies (nothing critical so not a bug but lost opportunities to simplify code and improve performance) in the way subnets are handles for at least relay, interface name and v6 interface id:
- relay is a direct fi...There are some inconsistencies (nothing critical so not a bug but lost opportunities to simplify code and improve performance) in the way subnets are handles for at least relay, interface name and v6 interface id:
- relay is a direct field of Network, is derived in syntax parsing and checked for both subnet and parent shared network for subnet selection.
- interface name (getIface) is inherited using getProperty, checked in sharedNetworksSanityChecks after syntax parsing and checked for both subnet and parent shared network for subnet selection.
- interface id (v6 option) is inherited using getProperty and subject of #652.
Ideas are:
- get rid of the syntax derivation when possible (in particular when the other inheritance mechanism applies)
- avoid spurious inheritance in CB cmds (aka #652)
- apply a subset of sharedNetworksSanityChecks in merging
- at the opposite use inheritance to make only subnet level checks in subnet selection (note this means a subnet should be attached to its parent shared network before being added to the global subnet container)
Related to #513 (sharedNetworksSanityChecks not applied to config backend) and #554 (select subnet performance).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1137some configuration related functions should throw exception if called from pa...2021-10-20T11:53:14ZRazvan Becheriusome configuration related functions should throw exception if called from packet processing functions or while processing packets (in MT)outstandingRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1084Kea does not recover from interface down when Kea starts2024-02-08T14:35:31ZRob AusteinKea does not recover from interface down when Kea startsProblem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server i...Problem scenario: Debian 9 server running Kea 1.7.1 package, server has three interfaces: eth1 serves directly connected hosts, eth2 and eth3 serve via DHCP relays, so must use "raw" rather than "udp" configuration. Problem is: server is part of a large rack of equipment, and we have no control over the order in which things come up, not to mention various replacement and reinstall scenarios. Kea quietly fails to listen on interfaces that show no carrier at the time Kea first starts, and never notices when they come up.
So far I have not thought of anything better than a separate process which monitors link states (eg with PyRoute2) and sends a config-reload control message whenever any of the interfaces comes up. This seems kind of lame.
Is this a known issue? Note that this is not the "new interface" problem: we know all the interfaces and list them in the config file, we just can't guarantee that they'll be up (and in some cases they *can't* come up until after Kea does because they're waiting for a DHCP lease in order to install the software that will eventually bring up the other end of the link).
Is this something ISC is likely to be able to fix anytime soon? Is there a better workaround?
Thanks! (Obligatory note: on the whole I'm very happy with Kea as a replacement for isc-dhcpd, don't think I'm complaining about the new thing... I just need to find a solution to this problem.)outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/726Implement global parameters as stamped elements2022-11-02T15:10:18ZFrancis DupontImplement global parameters as stamped elementsMarcin's idea from #630 https://gitlab.isc.org/isc-projects/kea/issues/630#note_61471:
What do you think about changing the internal representation of the `SrvConfig::configured_globals_` from `isc::data::ElementPtr` to `data::StampedVa...Marcin's idea from #630 https://gitlab.isc.org/isc-projects/kea/issues/630#note_61471:
What do you think about changing the internal representation of the `SrvConfig::configured_globals_` from `isc::data::ElementPtr` to `data::StampedValueCollection` and start tracking database identifiers of the global parameters. That way, instead of deleting the entire global config, you could delete a given parameter if it comes from the database (its id is non-zero). The existing configuration would be preserved. Admittedly, if the parameter is set in the file and the database, the parameter value set in the file will be lost and the default will be set for it. But, that's really no different than what would happen if you have the same subnet in both places and you delete the one from the database. Attention least we'd be consistent.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/656Need more checks on global parameters.2021-10-20T09:44:17ZFrancis DupontNeed more checks on global parameters.Reference https://gitlab.isc.org/isc-projects/kea/issues/576#note_61000 second problem: invalid values for global parameters should be rejected even they are not used:
- for individual parameters, e.g. next-server sets to something not ...Reference https://gitlab.isc.org/isc-projects/kea/issues/576#note_61000 second problem: invalid values for global parameters should be rejected even they are not used:
- for individual parameters, e.g. next-server sets to something not parse-able as an IPv4 address (nor empty)
- between parameters, e.g. 0 <= t1_percent <= 1 and t1_percent < t2_percent
The ideas are:
- avoid cases where the config backend is used to create a configuration which can't be saved and reloaded (get then set or write then reload fails)
- avoid cases where a global parameter with an invalid value is added/accepted and the invalid will raise an error a long time ago when an update will first use it (e.g. configuration built incrementally starting by global parameters, IMHO could be a popular way to proceed).
To summary the current check on global parameter value type is fine but not enough. Related to #576, #535 and #513outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/290Arguments/parameters for hooks and commands are not checked2023-02-25T19:27:17ZFrancis DupontArguments/parameters for hooks and commands are not checkedChild of #229 for all hooks.Child of #229 for all hooks.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/193Server level option data is sent instead of subnet level option data2022-11-02T15:08:41ZKevan BrownServer level option data is sent instead of subnet level option data**Describe the bug**
Given a DHCP4 configuration where a client option is defined at the server level, and also at the subnet level, the client is receiving the option data from the server level first, and then after forcing the client t...**Describe the bug**
Given a DHCP4 configuration where a client option is defined at the server level, and also at the subnet level, the client is receiving the option data from the server level first, and then after forcing the client to renew, it receives the value from the subnet level.
**To Reproduce**
1) Kea DHCP4
2) Boot a Windows 10 client
3) Client receives domain-name-servers option data defined at the server level
4) Run ipconfig /renew Ethernet on the client and now it receives the correct domain-name-servers option data defined at the subnet level
5) Reboot the client and it now has the server level domain-name-servers option data again.
**Expected behavior**
The Kea DHCP4 server should send the option data defined at the subnet level to which the host reservation is mapped.
**Environment:**
- Kea version:
* 1.4.0-P1
* tarball
* linked with:
* log4cplus 1.1.2
* OpenSSL 1.1.0f 25 May 2017
* database:
* PostgreSQL backend 4.0, library 90610
* Memfile backend 2.0
- OS: Debian Stretch (Raspbian)
- Which features were compiled in (in particular which backends): "--with-pgsql --enable-shell"
- If/which hooks where loaded in: libdhcp_lease_cmds.so
**Additional Information**
- The intent here is to define common option data at level that reduces redundancy, while overriding it at the subnet level when required.
- Configuration excerpt:
```
"option-data": [
{
"name": "domain-name",
"code": 15,
"data": "mydomain.com"
},
{
"name": "domain-name-servers",
"code": 6,
"data": "172.20.0.1"
},
{
"name": "ntp-servers",
"code": 42,
"data": "172.20.0.1"
}
],
"hooks-libraries": [
{
// Lease hooks library for Kea Anterius
"library": "/usr/local/lib/hooks/libdhcp_lease_cmds.so"
}
],
"shared-networks": [
{
"name": "Home",
"subnet4": [
{
// Networking Devices
"subnet": "172.20.0.0/24",
"id": 1,
"pools": [ { "pool": "172.20.0.3 - 172.20.0.8" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.0.1"
}
]
},
{
// Host Management
"subnet": "172.20.1.0/24",
"id": 2,
"pools": [
{ "pool": "172.20.1.2 - 172.20.1.4" },
{ "pool": "172.20.1.6/32" }
],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.1.1"
}
]
},
{
// Non-Domain Servers
"subnet": "172.20.3.0/24",
"id": 4,
"pools": [ { "pool": "172.20.3.4 - 172.20.3.4" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.3.1"
}
]
},
{
// Known Clients
"subnet": "172.20.4.0/24",
"id": 5,
"pools": [ { "pool": "172.20.4.2 - 172.20.4.5" } ],
"option-data": [
{
"name": "routers",
"code": 3,
"data": "172.20.4.1"
},
{
"name": "domain-name-servers",
"code": 6,
"data": "172.20.2.3,172.20.2.4,172.21.0.10,172.20.2.5,172.20.0.1"
}
]
},
```
**Describe the solution you'd like**
A fix for the options data hierarchy behavior in the product.
**Describe alternatives you've considered**
The only other alternative I have is to remove the common options data and repeat it, over and over, for each of the subnets that use it.
**Contacting you**
How can ISC reach you to discuss this matter further? If you do not specify any means such as e-mail, jabber id or a telephone, we may send you a message on github with questions when we have them.
- Emailbackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/54Reconfigure with an unusable lease back end, leaves the server in a non-worki...2022-11-02T15:08:41ZGhost UserReconfigure with an unusable lease back end, leaves the server in a non-working state (no rollback)A running kea-dhcpX server can be rendered non-functional by issuing a reconfigure (either by command or signal) with a configuration containing
a flawed lease back end specifications or to back end which cannot be reached.
After succes...A running kea-dhcpX server can be rendered non-functional by issuing a reconfigure (either by command or signal) with a configuration containing
a flawed lease back end specifications or to back end which cannot be reached.
After successfully parsing the configuration, the server attempts to connect to the new lease back end. This causes the LeaseMgrFactory to close the existing instance and subsequently fails to open a new one. The server will emit a log message that states reconfiguration has failed and at this point it will no longer process client packets.
A simple scenario:
1. start server with memfile lease back end
2. verify server hands out leases
3. change configuration to MySQL back end with an invalid database or user name
4. issue reconfig command
5. verify server does not see or acknowledge packets
The basic issue is the LeaseMgrFactory only permits one instance to exist. There is no "Staged" instance and we do not restore the one we closed. We probably don't handle host back ends any differently.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/44make database config parsing more flexible2022-11-02T15:08:41ZGhost Usermake database config parsing more flexibleCf. #5528 comments (look for "line 125").Cf. #5528 comments (look for "line 125").backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/37revamp subnet sanity checks2022-11-02T15:08:41ZGhost Userrevamp subnet sanity checksOn one side decides what should be checked:
- interface in shared network
- "same subnet" (cf #5423)
- malformed prefix
etc
And apply this to documentation and code in:
- plain subnet configuration
- in shared network subnet config...On one side decides what should be checked:
- interface in shared network
- "same subnet" (cf #5423)
- malformed prefix
etc
And apply this to documentation and code in:
- plain subnet configuration
- in shared network subnet configuration
- subnet REST API
Should be done after #5423 (definition of "same subnet") and client-class in pools.backlog