Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2023-11-10T09:50:24Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/2932Kea HA issue with terminating connection2023-11-10T09:50:24ZNick HahnKea HA issue with terminating connectionWe recently migrated our DHCP setup from dhcpd to Kea. It runs on
two servers with hot standby and a memfile backend for the leases. Kea
assigns IP addresses for around 7000 pools.
Over the past few months the HA connection terminated...We recently migrated our DHCP setup from dhcpd to Kea. It runs on
two servers with hot standby and a memfile backend for the leases. Kea
assigns IP addresses for around 7000 pools.
Over the past few months the HA connection terminated in random intervals.
From looking at the logs on the passive node I can see a lot of
'ResourceBusy: IP address ... could not be updated' warnings prior to
the connection terminating. Since multithreading is enabled I suspected
this may be due to the threads encountering a resource lock on the memfile.
I suppose after the lease update fails a few times, the connection is terminated.
Is the 'ResourceBusy' warning the cause for the terminating HA connection and
is there any way to fix the underlying issue? Any ideas on the issue are greatly
appraciated.
Here are the logs from the primary server:
```
Jun 12 15:04:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1, cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:04:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:04:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:04:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:04:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:04:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:04:45 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.ha-hooks.139625718580992] HA_LEASE_UPDATE_CONFLICT [hwtype=1], cid=[], tid=0x0: lease update to standby-dhcp (http://dhcp-2:8001/) returned conflict status code: ResourceBusy: IP address:123.123.123.123 could not be updated. (error code 4)
Jun 12 15:04:56 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:04:56 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:04:56 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625735366400] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:05:28 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:05:28 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:05:28 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625726973696] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:05:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625752151808] ALLOC_ENGINE_V4_ALLOC_FAIL_SUBNET [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 lease in the subnet 123.123.123.123/30, subnet-id 30926, shared network (none)
Jun 12 15:05:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625752151808] ALLOC_ENGINE_V4_ALLOC_FAIL [hwtype=1], cid=[], tid=0x0: failed to allocate an IPv4 address after 1 attempt(s)
Jun 12 15:05:31 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.alloc-engine.139625752151808] ALLOC_ENGINE_V4_ALLOC_FAIL_CLASSES [hwtype=1], cid=[], tid=0x0: Failed to allocate an IPv4 address for client with classes: ALL, HA_primary-dhcp, VENDOR_CLASS_MSFT 5.0, UNKNOWN
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.ha-hooks.139625701795584] HA_LEASE_UPDATE_CONFLICT [hwtype=1], cid=[], tid=0x0: lease update to standby-dhcp (http://dhcp-2:8001/) returned conflict status code: ResourceBusy: IP address:123.123.123.123 could not be updated. (error code 4)
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: WARN [kea-dhcp4.ha-hooks.139625718580992] HA_LEASE_UPDATE_CONFLICT [hwtype=1], cid=[], tid=0x0: lease update to standby-dhcp (http://dhcp-2:8001/) returned conflict status code: ResourceBusy: IP address:123.123.123.123 could not be updated. (error code 4)
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: ERROR [kea-dhcp4.ha-hooks.139625718580992] HA_LEASE_UPDATE_REJECTS_CAUSED_TERMINATION too many rejected lease updates cause the HA service to terminate
Jun 12 15:05:39 dhcp-1 kea-dhcp4[564812]: ERROR [kea-dhcp4.ha-hooks.139625718580992] HA_TERMINATED HA service terminated due to an unrecoverable condition. Check previous error message(s), address the problem and restart!
```
Here are the logs from the standby server:
```
Mar 12 19:25:06 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670034884352] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678688706, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 2907, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:25:06 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670009706240] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678688706, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 2907, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:27:28 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670009706240] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678688848, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 3812, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:32:05 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670018098944] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678689125, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 274, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:32:34 dhcp-2 kea-dhcp4[203037]: WARN [kea-dhcp4.lease-cmds-hooks.139670009706240] LEASE_CMDS_UPDATE4_CONFLICT lease4-update command failed due to conflict (parameters: { "client-id": "", "expire": 1678689154, "force-create": true, "fqdn-fwd": false, "fqdn-rev": false, "hostname": "", "hw-address": "", "ip-address": "", "state": 0, "subnet-id": 113, "valid-lft": 43200 }, reason: ResourceBusy: IP address:123.123.123.123 could not be updated.)
Mar 12 19:32:36 dhcp-2 kea-dhcp4[203037]: ERROR [kea-dhcp4.ha-hooks.139670104323840] HA_TERMINATED HA service terminated due to an unrecoverable condition. Check previous error message(s), address the problem and restart!
Mar 12 22:11:09 dhcp-2 kea-dhcp4[203037]: ERROR [kea-dhcp4.packets.139670138794688] DHCP4_BUFFER_RECEIVE_FAIL error on attempt to receive packet: Truncated DHCPv4 packet (len=0) received, at least 236 is expected.
```
The relevant config is the following on both hosts, differing only in the "this-server-name" property.
```
"hooks-libraries": [{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_lease_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_stat_cmds.so",
"parameters": {}
},
{
"library": "/usr/lib/x86_64-linux-gnu/kea/hooks/libdhcp_ha.so",
"parameters": {
"high-availability": [{
"this-server-name": "standby-dhcp",
"mode": "hot-standby",
"heartbeat-delay": 10000,
"max-response-delay": 60000,
"max-ack-delay": 5000,
"max-unacked-clients": 5,
"peers": [{
"name": "primary-dhcp",
"url": "http://dhcp-1:8001/",
"role": "primary",
"auto-failover": true
}, {
"name": "standby-dhcp",
"url": "http://dhcp-2:8001/",
"role": "standby",
"auto-failover": true
}]
}]
}
}]
```next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2586Create Memfile V4 indexes for BLQ2023-07-17T13:58:23ZFrancis DupontCreate Memfile V4 indexes for BLQkea2.3.5Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/2305Kea should always return lease file location if memfile is used2022-11-02T15:10:41ZTomek MrugalskiKea should always return lease file location if memfile is usedThis issue came up during Stork sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/667. The background of the problem is that Kea does not return lease file location if a default value is used. However, for an average user...This issue came up during Stork sanity checks: https://gitlab.isc.org/isc-projects/stork/-/issues/667. The background of the problem is that Kea does not return lease file location if a default value is used. However, for an average user to determine where the lease file is located, he'd have to figure out compilation options and what prefix was configured during compilation. This is not something average user can do.
The proposal is to always return the lease file location if memfile is used, even if the location is "the default" (because effectively, the default can change from one deployment to another).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2374kea-admin lease-dump file permisions2022-11-02T15:10:41ZMarcin Godzinakea-admin lease-dump file permisionsCommand `kea-admin lease-dump` exports database as memfile file with permissions of user running the command.
If Kea is running from packages on Ubuntu it expects `/var/lib/kea/kea-leases4.csv`(or v6) file to be owned by `_kea` user/gro...Command `kea-admin lease-dump` exports database as memfile file with permissions of user running the command.
If Kea is running from packages on Ubuntu it expects `/var/lib/kea/kea-leases4.csv`(or v6) file to be owned by `_kea` user/group.
**In this case, we can not directly copy exported file without changing its permissions, or Kea will not be able to read the file and start.**
The problem was discovered during forge tests. The test Starts Kea with database and exports database to the memfile location. Then it restarts Kea using the exported file.
Test failed on Ubuntu using deb packages.
**Possible solutions:**
- We can modify the forge test to account for different permissions and modify help text of `lease-dump` command to warn user about possible permission clash.
- We can modify `lease-dump` script to detect what permissions the file should have, and apply them during export. This will solve import and export on the same system, but the problem will still exist if migrating to other systems with a different way of installing Kea.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/833LFC logs are not under control of config2022-11-02T15:10:20ZMichal NowikowskiLFC logs are not under control of confige.g. log pattern does not follow the one set for DHCP4:
````
2019-08-13 18:19:16.205 INFO [kea-dhcp4.dhcpsrv/25380] DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup
2019-08-13 18:19:16.206 INFO [kea-dhcp4.dhcpsrv/25380] DHCPSRV_M...e.g. log pattern does not follow the one set for DHCP4:
````
2019-08-13 18:19:16.205 INFO [kea-dhcp4.dhcpsrv/25380] DHCPSRV_MEMFILE_LFC_START starting Lease File Cleanup
2019-08-13 18:19:16.206 INFO [kea-dhcp4.dhcpsrv/25380] DHCPSRV_MEMFILE_LFC_EXECUTE executing Lease File Cleanup using: /usr/sbin/kea-lfc -4
INFO [DhcpLFC] LFC_START Starting lease file cleanup
INFO [DhcpLFC] LFC_PROCESSING Previous file: /var/lib/kea/kea-leases4.csv.2, copy file: /var/lib/kea/kea-leases4.csv.1
INFO [DhcpLFC.dhcpsrv] DHCPSRV_MEMFILE_LEASE_FILE_LOAD loading leases from file /var/lib/kea/kea-leases4.csv.2
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/77memfile: add a command to force writing in-memory DB to file2022-11-02T15:08:43ZGhost Usermemfile: add a command to force writing in-memory DB to filememfile keeps leases in memory and writes changes to disk. If the leasefile is lost for whatever reason, it may be useful to tell Kea to write is entire lease file to disk.memfile keeps leases in memory and writes changes to disk. If the leasefile is lost for whatever reason, it may be useful to tell Kea to write is entire lease file to disk.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/266ISC DHCP release on roam flag2022-11-02T15:08:42ZFrancis DupontISC DHCP release on roam flag>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on t...>>>
release-on-roam flag;
When enabled and the dhcpd server detects that a DHCPv6 client
(IAID+DUID) has roamed to a new network, it will release the
pre-existing leases on the old network and emit a log statement
similiar to the following:
"Client: <id> roamed to new network, releasing lease:
<address>"
The server will carry out all of the same steps that would nor-
mally occur when a client explicitly releases a lease. When
release-on-roam is disabled (the default) the server makes such
leases unavailable until they expire or the server is restarted.
Clients that need leases in multiple networks must supply a
unique IAID in each IA. This parameter may only be specified at
the global level.
>>>
Make sense for a moving client which for some reasons does not release its address at the previous location. Can be implemented in Kea if there is an easy and fast way to get leases by IAID+DUID only.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2436Memfile support for Lease Limits2022-07-11T16:36:27ZThomas MarkwalderMemfile support for Lease LimitsAdd the functionality to support lease limits to Memfile_LeaseMgr as outlined below:
- Add lease count map(s) to track leases per class and/or subnet
- Ability to update lease limits upon lease events (add, update, delete)
- Ability to ...Add the functionality to support lease limits to Memfile_LeaseMgr as outlined below:
- Add lease count map(s) to track leases per class and/or subnet
- Ability to update lease limits upon lease events (add, update, delete)
- Ability to refresh lease count map(s) after lease file load
- Add functions to query for and/or test lease counts against a set of limitskea2.2.0 - a new stable branchThomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/2039ability to migrate memfile leases to database leases2022-02-18T08:00:19ZAndrei Pavelandrei@isc.orgability to migrate memfile leases to database leasesThe reverse action that #2038 would take.
Something like: `kea-admin lease-import mysql -6 -o leases.csv`.
These two kea-admin commands would cover all the cases. If someone wants to migrate from MySQL to PostgreSQL they can go through...The reverse action that #2038 would take.
Something like: `kea-admin lease-import mysql -6 -o leases.csv`.
These two kea-admin commands would cover all the cases. If someone wants to migrate from MySQL to PostgreSQL they can go through CSV. That is:
```
kea-admin lease-dump mysql -6 -o leases.csv
kea-admin lease-import pgsql -6 -o leases.csv
```kea2.1.2https://gitlab.isc.org/isc-projects/kea/-/issues/2038ability to migrate database leases to memfile leases2022-02-18T08:00:19ZAndrei Pavelandrei@isc.orgability to migrate database leases to memfile leaseskea-admin does have the lease-dump action which generates a very similar CSV to the one generated and read by kea-dhcp[46] when configured to work with memfile, but it's not quite there yet. Here are differences:
`kea-admin lease-dump m...kea-admin does have the lease-dump action which generates a very similar CSV to the one generated and read by kea-dhcp[46] when configured to work with memfile, but it's not quite there yet. Here are differences:
`kea-admin lease-dump mysql`:
```csv
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,
10.0.0.0,000C01020334,01000C01020334,7200,2021-08-17 19:00:20,1,0,0,,default,
```
Leases saved by kea-dhcp4:
```csv
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context
10.0.0.0,00:0c:01:02:03:04,01:00:0c:01:02:03:04,7200,1629215965,1,0,0,,0,
```
Required format changes:
* hwaddr: blob "000C01020334" to colon-separated "00:0c:01:02:03:04"
* client_id: blob "01000C01020334" to colon-separated "01:00:0c:01:02:03:04"
* expire: human-readable "2021-08-17 19:00:20" to unix "1629215965"
* state: human-readable "default" to numeric "0"
And for v6:
`kea-admin lease-dump mysql`:
```csv
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,hwtype,hwaddr_source,state,user_context
2001:db8:1:0:1::,0001000128AE81F5000C01020304,7200,2021-08-17 19:19:33,1,3600,IA_NA,1,128,0,0,,000C01020304,1,HWADDR_SOURCE_IPV6_LINK_LOCAL,default,
```
Leases saved by kea-dhcp6:
```csv
address,duid,valid_lifetime,expire,subnet_id,pref_lifetime,lease_type,iaid,prefix_len,fqdn_fwd,fqdn_rev,hostname,hwaddr,state,user_context
2001:db8:1:0:1::,00:01:00:01:28:ae:81:f5:00:0c:01:02:03:3f,7200,1629217233,1,3600,0,1,128,0,0,,00:0c:01:02:03:3f,0,
```
Required format changes:
* duid: blob "0001000128AE81F5000C01020304" to colon-separated "00:01:00:01:28:ae:81:f5:00:0c:01:02:03:3f"
* expire: human-readable "2021-08-17 19:19:33" to unix "1629217233"
* lease-type: human-readable "IA_NA" to numeric "1"
* hwaddr: blob "000C01020304" to colon-separated "00:0c:01:02:03:3f"
* state: human-readable "default" to numeric "0"
And there are two extra columns in the case of lease-dump. What's up with those:
* hwtype
* hwaddr_source
user-context needs to be looked at too in both cases.
The output of `kea-admin lease-dump` might differ for PostgreSQL than for MySQL.kea2.1.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2236add hwtype and hwaddr_source columns to memfile2022-01-18T13:59:04ZAndrei Pavelandrei@isc.orgadd hwtype and hwaddr_source columns to memfileRequired by #2038 and #2039.Required by #2038 and #2039.kea2.1.2Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/2257lease not loaded from memfile if user context has multiple key-value pairs2022-01-12T12:26:19ZAndrei Pavelandrei@isc.orglease not loaded from memfile if user context has multiple key-value pairsmemfile CSV:
```
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context
10.0.0.1,ff:01:02:03:04:08,01:ff:01:02:03:04:08,7200,1641205200,1,0,0,,0,{"comment": "hello", "comment2": "do not rel...memfile CSV:
```
address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname,state,user_context
10.0.0.1,ff:01:02:03:04:08,01:ff:01:02:03:04:08,7200,1641205200,1,0,0,,0,{"comment": "hello", "comment2": "do not release"}
```
error:
```
ERROR DHCPSRV_MEMFILE_LEASE_LOAD_ROW_ERROR discarding row x, error: EOF read, one of ",}" expected in <string>:y:z
```
See `MemfileLeaseMgrTest.v4UserContext` and `MemfileLeaseMgrTest.v6UserContext` unit tests. They will require adjustments.https://gitlab.isc.org/isc-projects/kea/-/issues/1603Calling kea-lfc on a CSV file without a trailing blank line makes it not proc...2021-01-04T17:46:51ZAndrei Pavelandrei@isc.orgCalling kea-lfc on a CSV file without a trailing blank line makes it not process the last lineReplication steps:
```sh
printf address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname > kea-dhcp4.csv
kea-lfc -4 -c ignored-path -f kea-dhcp4.csv.completed -i kea-dhcp4.csv -o kea-dhcp4.csv.output -p kea-dhc...Replication steps:
```sh
printf address,hwaddr,client_id,valid_lifetime,expire,subnet_id,fqdn_fwd,fqdn_rev,hostname > kea-dhcp4.csv
kea-lfc -4 -c ignored-path -f kea-dhcp4.csv.completed -i kea-dhcp4.csv -o kea-dhcp4.csv.output -p kea-dhcp4.csv.pid -x kea-dhcp4.csv.2
```
You'll get no error, because `kea-lfc` doesn't output anything outside of Kea, but notice there's no `kea-dhcp4.csv.2`. There should be. `kea-dhcp4.csv` is not removed. It should be.
What happens is line is not empty but EOF is set. Good flag is not set, so it enters the second branch below.
`csv_file.cc:273`
```c++
std::string line;
std::getline(*fs_, line);
// If we got empty line because we reached the end of file
// return an empty row.
if (line.empty() && fs_->eof()) {
row = EMPTY_ROW();
return (true);
} else if (!fs_->good()) {
// If we hit an IO error, communicate it to the caller but do NOT close
// the stream. Caller may try again.
setReadMsg("error reading a row from CSV file '"
+ std::string(filename_) + "'");
return (false);
}
```
It should be:
```c++
std::string line;
// Read the next non-empty line.
while (line.empty() && fs_->good()) {
std::getline(*fs_, line);
}
// If we reached the end of file, return an empty row.
if (fs_->eof()) {
row = EMPTY_ROW();
return (true);
...
```kea1.9.4Andrei Pavelandrei@isc.orgAndrei Pavelandrei@isc.orghttps://gitlab.isc.org/isc-projects/kea/-/issues/135encode exported JSON maps in hexadecimal2020-03-24T13:07:43ZFrancis Dupontencode exported JSON maps in hexadecimalAnd of course decode imported JSON maps when they are in hexadecimal.
In details the idea is:
- add a variant of Element::toJSON which encode into hexadecimal the string so it begins by 7b or 7B and embedded commas are translated into 2...And of course decode imported JSON maps when they are in hexadecimal.
In details the idea is:
- add a variant of Element::toJSON which encode into hexadecimal the string so it begins by 7b or 7B and embedded commas are translated into 2c or 2C
- enhance Element::fromJSON to decode first its input argument when it begins by 7b or 7B
This allows to store not trivial user context into memfile lease database.
Possible additions:
- support more than maps
- better (less space) encoding than hexadecimal
note IMHO for the intended use these are overkilling.
If there is an issue about the memfile problem please replace this sentence by a reference to it.kea2.1-backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/527check return value of multi index push_back2019-07-22T10:51:02ZFrancis Dupontcheck return value of multi index push_backThe C++ vector push_back returns void but the boost multi index one can fail so returns a pair of iterator and boolean. This returned value must be checked as for any method modifying a multi index to get failure cases as a duplicate un...The C++ vector push_back returns void but the boost multi index one can fail so returns a pair of iterator and boolean. This returned value must be checked as for any method modifying a multi index to get failure cases as a duplicate unique key.Kea1.6-beta2Francis DupontFrancis Duponthttps://gitlab.isc.org/isc-projects/kea/-/issues/591kea-dhcpv6 lease sanity-checking is flagging PD leases2019-05-10T09:48:34ZThomas Markwalderkea-dhcpv6 lease sanity-checking is flagging PD leasesReported via support issue https://support.isc.org/Ticket/Display.html?id=14522.
Analysis showed that kea-dhcpv6 sanity checking is attempting to map PD leases to subnets by address which a: is not supported b: the admin guide says is...Reported via support issue https://support.isc.org/Ticket/Display.html?id=14522.
Analysis showed that kea-dhcpv6 sanity checking is attempting to map PD leases to subnets by address which a: is not supported b: the admin guide says is not done for PD leases. Testing confirms this as does visual code inspection. The code should either not check PD leases or check them properly. In either case, there are no unit tests to verify PD leases are treated correctly.Kea1.6Thomas MarkwalderThomas Markwalderhttps://gitlab.isc.org/isc-projects/kea/-/issues/55legldb_create.* legldb_drop.* scripts in premium repo2018-12-10T21:52:56ZGhost Userlegldb_create.* legldb_drop.* scripts in premium repothere are 6 new databases scripts in premium repo:
* legldb_create.mysql legldb_drop.mysql
* legldb_create.cql legldb_drop.cql
* legldb_create.psql legldb_drop.psql
1. is there a typo in names? shouldn't it be legal_db* ?
2. why do we ...there are 6 new databases scripts in premium repo:
* legldb_create.mysql legldb_drop.mysql
* legldb_create.cql legldb_drop.cql
* legldb_create.psql legldb_drop.psql
1. is there a typo in names? shouldn't it be legal_db* ?
2. why do we need 6 scripts to add/remove one table from db schema? couldn't it be integrated to main kea db schema?
3. those scripts are not being installed - that have to be fixed.Kea1.5-finalFrancis DupontFrancis Dupont