Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-21T14:50:56Zhttps://gitlab.isc.org/isc-projects/kea/-/issues/3275Kea DB allows to store too short identifier in the lease table2024-03-21T14:50:56ZSlawek FigielKea DB allows to store too short identifier in the lease tableWhile performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it b...While performing some experiments in Stork, I found that the Kea database accepts identifiers that are too short (less than 3 bytes) in the `lease6` table. It causes the error to be thrown when the identifier is processed. I noticed it blocks fetching this lease by API. I don't know if it has any other internal consequences.
Steps to reproduce:
1. Setup Kea 2.3.8 or above with PostgreSQL.
2. Configure lease database.
3. Insert a lease with too short DUID (e.g., `00`)
```
INSERT INTO lease6(address, duid, valid_lifetime, expire, subnet_id, pref_lifetime, lease_type, iaid, prefix_len, hwtype, hwaddr_source, state) VALUES('3001:db8:1::2', DECODE('00', 'hex'), 3600, NOW() + interval '1' MONTH, 1, 1800, 0, 1, 128, 0, 0, 1);
```
4. Send the `lease-get` command with the specified address (i.e., `3001:db8:1::2`).
5. Observe the error:
```
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command lease6-get received from remote address 127.0.0.1
stork-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'lease6-get'
stork-agent-kea6-1 | ERROR LEASE_CMDS_GET6_FAILED lease6-get command failed (parameters: { "ip-address": "3001:db8:1::2", "type": "IA_NA" }, reason: Could not convert data to Lease6, reason: identifier is too short (1), at least 3 is required)
stork-agent-kea6-1 | ERROR HOOKS_CALLOUT_ERROR error returned by callout on hook $lease6_get registered by library with index 1 (callout address 0x7f12e8310e90) (callout duration 0.593 ms)
stork-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_FORWARDED command lease6-get successfully forwarded to the service dhcp6 from remote address 127.0.0.1
```backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3273Upgrade schema on startup2024-03-14T14:36:20ZAndrei Pavelandrei@isc.orgUpgrade schema on startupKea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.Kea could have a boolean database-level configuration knob with a default of false that, when enabled, makes the schema be upgraded on startup.
Should be straightforward to do following the work on automatic database init in issue 3025.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/3189Follow-up on #3019: limits are incompatbile with retry-on-startup2024-03-28T14:56:49ZAndrei Pavelandrei@isc.orgFollow-up on #3019: limits are incompatbile with retry-on-startupThe limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the leas...The limits library needs the lease manager initialized in dhcpX_srv_configured in order to check for JSON support and to do some recounting. When `retry-on-startup` is configured for the lease database, and a retry is triggered, the lease manager is not yet available, so an exception is thrown and the reconfiguration aborts, instead of actually retrying.
We should make limits compatible with retry-on-startup. Through some lazy recounting mechanism. @razvan's idea was a callback in `LeaseMgrFactory` that gets called on instantiation.kea2.6.0https://gitlab.isc.org/isc-projects/kea/-/issues/3160Too many nullable fields in DB schema?2023-11-23T14:48:53ZDavid KraeutmannToo many nullable fields in DB schema?I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but onl...I'm writing an admin tool for the Kea DB and noticed that a lot of fields in lease4/lease6 are nullable even when they shouldn't be. This adds a lot of handling overhead.
For example, in lease4, most of the columns are nullable, but only relay_id and remote_id are actually possibly set to NULL in the Kea code.
What is the design decision behind that?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/3137Audit revision conflicts between IPv4 and IPv6 due to shared session variable2023-11-23T14:37:03ZMaurice MakaayAudit revision conflicts between IPv4 and IPv6 due to shared session variable**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_rev...**Describe the bug**
For creating audit revisions, separate paths exists for DHCP4 and DHCP6 auditing. The paths are not fully separated though. The two implementations make use of some shared session variables, amongst which `audit_revision_id`. These session variables tightly couple the two paths, which can lead to conflicts.
**To Reproduce**
Here's an example scenario for a conflict:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, ok
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 2, fail
```
Because the global revision id now points at 2, but only `dhcp6_audit` with id 1 exists, we get:
```
ERROR: insert or update on table "dhcp6_audit" violates foreign key constraint "fk_dhcp6_audit_revision"
DETAIL: Key (revision_id)=(2) is not present in table "dhcp6_audit_revision".
CONTEXT: SQL statement "INSERT INTO dhcp6_audit (object_type, object_id, modification_type, revision_id)
VALUES (object_type_val, object_id_val,
(SELECT id FROM modification WHERE modification_type = modification_type_val),
audit_revision_id)"
PL/pgSQL function createauditentrydhcp6(character varying,bigint,character varying) line 11 at SQL statement
SQL statement "SELECT createAuditEntryDHCP6('dhcp6_client_class', NEW.id, 'create')"
PL/pgSQL function func_dhcp6_client_class_ains() line 4 at PERFORM
```
In this case, the INSERT breaks, because the DHCP6 audit record points to a non-existent `dhcp6_audit_revision` id.
Another scenario is possible, where coincidentally the incorrect revision id does exist. In that case, the audit will be assigned to an old revision in the audit trail, changing history. An example scenario for this one:
```
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('one'); -- uses audit_revision_id = 1, ok
kea=# SELECT createAuditRevisionDHCP4(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 2
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('two'); -- uses audit_revision_id = 2, ok
kea=# SELECT createAuditRevisionDHCP6(CURRENT_TIMESTAMP,'all','test', true); -- audit_revision_id = 1
kea=# INSERT INTO dhcp6_client_class (name) VALUES ('something'); -- uses audit_revision_id = 1, ok
kea=# INSERT INTO dhcp4_client_class (name) VALUES ('three'); -- uses audit_revision_id = 1, fail
```
**Expected behavior**
The audit revisions should be independent and use their own specific session variables, instead of shared ones.
When running the first scenario from the reproduction scenario:
- It must not fail
- The DHCP6 change must be logged in `dhcp6_audit` with `revision_id` = 1
- The DHCP4 change must be logged in `dhcp4_audit` with `revision_id` = 2
When running the second scenario:
- DHCP4 client class 'one' must be related to `dhcp4_audit' with `revision_id` = 1
- DHCP4 client class 'two' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP4 client class 'three' must be related to `dhcp4_audit' with `revision_id` = 2
- DHCP6 client class 'something' must be related to `dhcp6_audit' with `revision_id` = 1
**Environment:**
- Kea version: 2.5.3 and before
- Affects both MySQL and PostgreSQL
**Work-around**
To prevent issues with the current database schema, make sure that DHCP4 and DHCP6 updates are separated in the query sequence:
- create DHCP4 audit revision
- perform all DHCP4 updates
- create DHCP6 audit revision
- perform all DHCP6 updates
**Contacting you**
You can reach me at account-gitlab-isc@makaay.nloutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/2957dhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on...2024-03-22T13:05:49ZJohn W. O'Briendhcpdb_create.pgsql erroneously creates dhcp4_server_modification_ts index on dhcp6_server table---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the b...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
dhcpdb_create.pgsql erroneously creates the dhcp4_server_modification_ts index on the dhcp6_server table
**To Reproduce**
Steps to reproduce the behavior:
1. Initialize a PostgreSQL database using dhcpdb_create.pgsql
2. Inspect the dhcp4_server_modification_ts index
3. See that it is associated with the dhcp6_server table
**Expected behavior**
A clear and concise description of what you expected to happen:
The dhcp4_server_modification_ts index should be associated with the dhcp4_server table.
**Environment:**
- Kea version: 2.2.0
- OS: FreeBSD 13.2-RELEASE amd64
- Compiled with pgsql backend
- Loaded hooks: pgsql_cb
**Additional Information**
```
kea=> \di dhcp4_server_modification_ts
List of relations
Schema | Name | Type | Owner | Table
--------+------------------------------+-------+-------+--------------
public | dhcp4_server_modification_ts | index | kea | dhcp6_server
(1 row)
```
This appears to have been introduced as a [copy/paste error in version 7.0 of the schema](https://gitlab.isc.org/isc-projects/kea/-/blob/Kea-2.3.8/src/share/database/scripts/pgsql/dhcpdb_create.pgsql#L1398). I could identify no correspond bug in the MySQL schema.
**Contacting you**
* SMS/Signal: (available upon request)
* GitHub/GitLab: neirbowj
* Mastodon: [@neirbowj@mastodon.online](https://mastodon.online/@neirbowj)kea2.5.8https://gitlab.isc.org/isc-projects/kea/-/issues/2762Lease user context processing can be made more consistent2023-03-09T14:47:03ZFrancis DupontLease user context processing can be made more consistentFor instance it is possible to add using directly the API a lease user context which is not a map: with SQL backends to try to retrieve the lease throws including in a returning collection method without giving the address of the lease...For instance it is possible to add using directly the API a lease user context which is not a map: with SQL backends to try to retrieve the lease throws including in a returning collection method without giving the address of the lease...next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2499don't extend dhcpdb_create scripts any more2024-03-27T13:32:29ZWlodzimierz Wenceldon't extend dhcpdb_create scripts any moreWe should stop to make two paths of database creation. It leads to mistakes more work during releases additional jobs to check differences. So rather to develop scripts like `dhcpdb_create.mysql` (`dhcpdb_create.pgsql`) and upgrade scrip...We should stop to make two paths of database creation. It leads to mistakes more work during releases additional jobs to check differences. So rather to develop scripts like `dhcpdb_create.mysql` (`dhcpdb_create.pgsql`) and upgrade scripts (eg. upgrade_009_to_010.sh.in) separately we should develop just upgrade scripts which will be executed by dhcpdb_create.sh script.
It's ugly to do it this late in a process but it will make our life much easier in the future.
- [ ] as part of the refactor process, please make sure there's a VERY good reason why there's .in version that needs to be expanded during configure.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/2479Documentation - upgrading Kea servers with a common DB backend2023-07-31T13:34:54ZPeter DaviesDocumentation - upgrading Kea servers with a common DB backend**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some u...**Documentation - upgrading Kea servers with a common DB backend**
Kea implementations where servers do not share common databases Kea may be upgraded individually.
In this way the down time of dhcp services may be limited.
Some users employ a common database backend for leases and/or configuration data.
As Kea software upgrades normally increment database schema versions, individual upgrades may have unfortunate side effects.
We would like advice regarding this type of upgrade added to:
4.3.2.2 Upgrading a MySQL Database From an Earlier Version of Kea
4.3.3.3 Upgrading a PostgreSQL Database From an Earlier Version of Keanext-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/2345Kea 2.0.0 Fails to Allocate Leases2022-11-02T15:10:41ZALOK KUMAR SINGHKea 2.0.0 Fails to Allocate LeasesWe are using Kea 2.0.0 version with backend database postgresql and observer an issue where lease not getting allocated/extended and producing below error message.
Note: Kea and Postgresql database is installed on same VM and has timez...We are using Kea 2.0.0 version with backend database postgresql and observer an issue where lease not getting allocated/extended and producing below error message.
Note: Kea and Postgresql database is installed on same VM and has timezone EST set, also database timezone is set to EST but still this issue is happening, though this was running perfect from last 3 months after an upgrade from 1.5.0P1 to 2.0.0
```
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.dhcp4/1541.140278882691264] DHCP4_CLASS_ASSIGNED [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: client packet has been assigned to the following class(es): UNKNOWN
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.dhcp4/1541.140278882691264] DHCP4_CLASS_ASSIGNED [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: client packet has been assigned to the following class(es): ALL, HA_codcmdndh001, VENDOR_CLASS_MSFT 5.0, UNKNOWN
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_CLIENT_FQDN_PROCESS [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: processing Client FQDN option
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_CLIENT_FQDN_DATA [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: Client sent FQDN option: type=81 (CLIENT_FQDN), flags: (N=0, E=0, O=0, S=0), domain-name='compy' (partial)
2022-03-07 01:48:13.030 DEBUG [kea-dhcp4.ddns/1541.140278882691264] DHCP4_RESPONSE_FQDN_DATA [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: including FQDN option in the server's response: type=81 (CLIENT_FQDN), flags: (N=1, E=0, O=0, S=0), domain-name='compy.' (full)
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_GET_CLIENTID obtaining IPv4 leases for client ID 01:9c:ad:97:16:83:2f
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4 get one host with reservation for subnet id 2 and IPv4 address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ALL_ADDRESS4 get all hosts with reservations for IPv4 address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ALL_ADDRESS4_COUNT using address 10.52.67.126, found 0 host(s)
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.hosts/1541.140278882691264] HOSTS_CFG_GET_ONE_SUBNET_ID_ADDRESS4_NULL host not found using subnet id 2 and address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_GET_ADDR4 obtaining IPv4 lease for address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.alloc-engine/1541.140278882691264] ALLOC_ENGINE_V4_REQUEST_EXTEND_LEASE [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: extending lifetime of the lease for address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.dhcpsrv/1541.140278882691264] DHCPSRV_PGSQL_UPDATE_ADDR4 updating IPv4 lease for address 10.52.67.126
2022-03-07 01:48:13.031 ERROR [kea-dhcp4.alloc-engine/1541.140278882691264] ALLOC_ENGINE_V4_ALLOC_ERROR [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: error during attempt to allocate an IPv4 address: unable to update lease for address 10.52.67.126 as it does not exist
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.bad-packets/1541.140278882691264] DHCP4_PACKET_NAK_0004 [hwtype=1 9c:ad:97:16:83:2f], cid=[01:9c:ad:97:16:83:2f], tid=0x23d07203: failed to grant a lease, client sent ciaddr 0.0.0.0, requested-ip-address 10.52.67.126
2022-03-07 01:48:13.031 DEBUG [kea-dhcp4.callouts/1541.140278882691264] HOOKS_CALLOUTS_BEGIN begin all callouts for hook leases4_committed
```
[6mar.pcap](/uploads/819df2d10bd7335b39dae233f837379e/6mar.pcap)[kea-dhcp4.log.10](/uploads/64ac95d818035cf59d7ba2f75604e770/kea-dhcp4.log.10)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2331Kea-Admin db-upgrade fails if using different Port for pgsql2023-07-05T10:39:19ZAlex GastKea-Admin db-upgrade fails if using different Port for pgsql---
name: Kea-Admin db-upgrade fails if using different Port for pgsql
about: Kea-Admin should respect supplied Port (-P) Parameter for doing db-upgrade
---
**Bug Description**
When doing the `db-upgrade` with `kea-admin` using a pgs...---
name: Kea-Admin db-upgrade fails if using different Port for pgsql
about: Kea-Admin should respect supplied Port (-P) Parameter for doing db-upgrade
---
**Bug Description**
When doing the `db-upgrade` with `kea-admin` using a pgsql-Backend with a port different than 5432 the update fails.
The `-P` Parameter is used and verified before but does not work in the real upgrade process.
Starting the PostgreSQL Database on the default-port and omitting the Port-Parameter the update works well.
Example:
```
kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea
Database version reported before upgrade: 8.0
Processing /usr/share/kea/scripts/pgsql/upgrade_001.0_to_002.0.sh file...
This script upgrades 1.0 to 2.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_002.0_to_003.0.sh file...
This script upgrades 2.0 to 3.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.0_to_003.1.sh file...
This script upgrades 3.0 to 3.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.1_to_003.2.sh file...
This script upgrades 3.1 to 3.2. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.2_to_003.3.sh file...
This script upgrades 3.2 to 3.3. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_003.3_to_004.0.sh file...
This script upgrades 3.3 to 4.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_004.0_to_005.0.sh file...
This script upgrades 4.0 to 5.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_005.0_to_005.1.sh file...
This script upgrades 5.0 to 5.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_005.1_to_006.0.sh file...
This script upgrades 5.1 to 6.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.0_to_006.1.sh file...
This script upgrades 6.0 to 6.1. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.1_to_006.2.sh file...
This script upgrades 6.1 to 6.2. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_006.2_to_007.0.sh file...
This script upgrades 6.2 to 7.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_007_to_008.sh file...
This script upgrades 7.0 to 8.0. Reported version is 8.0. Skipping upgrade.
Processing /usr/share/kea/scripts/pgsql/upgrade_008_to_009.sh file...
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
```
**To Reproduce**
Steps to reproduce the behavior:
1. Use Kea with Lease-Backend on pgsql configured with a Port other than 5432
2. Do a software-upgrade (in my case via APT-Packages) [rem. might be another bug that the APT does not upgrade the db-schema itself]
3. Kea reports a wrong Schema-Version at startup.
4. Execute `kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea`
5. See that it detects the actual Schema-Version and then in the last step ends with "Connection refused" at Port 5432.
6. Run the PostgreSQL-Software at Port 5432
7. Use the above `kea-admin`-Command with the same `-P` Parameter
8. See that it can't detect the actual Schema and exits:
```
kea-admin db-upgrade pgsql -h localhost -P 5435 -u kea -p "AWlZgeouj5vkRkexSAND" -n kea
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5435?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5435?
```
9. Omit the `-P`-Parameter and successfully upgrade the Schema.
10. Turn back the Database to the port used before
11. Start kea and see it running.
**Expected behavior**
The DB-Update Procedure should take full awareness of the changed port and update the database schema accordingly.
In the best case the APT update procedure should implement this step as well (for unattended updating purpose) - I'm not sure if it already does as the manual process already fails.
**Environment:**
- Kea version: 2.1.3 from Cloudsmith-Repository
- OS: Ubuntu 20.04.4 LTS, AMD64
- pgsql-Lease-Backend with Port different than 5432
**Additional Information**
Lease-Backend-Configuration:
```
"lease-database": {
"type": "postgresql",
"user": "kea",
"password": "<my-fancy-password>",
"name": "kea",
"port": 5435
},
```
As the mentioned update-script does take some parameters via `$@`-Variable kea-admin migth don't declare the `-p` or `--port` Parameter for the pgsql Backend.
Other commands like `lease-dump` do behave accordingly:
```
kea-admin lease-dump pgsql -h localhost -P 5435 -u kea -p "<my-fancy-password>" -n kea -4 -o output-dump.csv
psql: error: could not connect to server: Connection refused
Is the server running on host "localhost" (::1) and accepting
TCP/IP connections on port 5432?
could not connect to server: Connection refused
Is the server running on host "localhost" (127.0.0.1) and accepting
TCP/IP connections on port 5432?
ERROR/kea-admin: lease-dump: psql call failed, exit code: 0
```
**Contacting you**
Please reach out via the contact information on my profile or via Twitter / GitHub.next-stable-2.6https://gitlab.isc.org/isc-projects/kea/-/issues/1746multiple contact points for MySQL and PostgreSQL2023-04-06T12:02:31ZAndrei Pavelandrei@isc.orgmultiple contact points for MySQL and PostgreSQLFor the purpose of highly-available database connectivity, eliminating single point of failures in cluster nodes, and benefitting from Galera and Percona's active-active responsiveness, Kea could use the ability to specify multiple conta...For the purpose of highly-available database connectivity, eliminating single point of failures in cluster nodes, and benefitting from Galera and Percona's active-active responsiveness, Kea could use the ability to specify multiple contact points in the same database access set.
Ideally, it would be less work if you could pass the responsibility of shuffling through the nodes onto the database library, like in Cassandra.
But if this is not an option, to avoid contention on selecting the connection to be used, a connection could be randomly chosen by each thread.
Design document: TODObackloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1559doc: picking the right redundancy solution (HA vs shared database)2024-03-21T12:23:39ZTomek Mrugalskidoc: picking the right redundancy solution (HA vs shared database)Once the situation with MySQL group replication improves (see #1411, #593 and #980) and we get more experience with running Kea with a cluster, we should document this a possible alternative for HA.
Support and sales are vitally interes...Once the situation with MySQL group replication improves (see #1411, #593 and #980) and we get more experience with running Kea with a cluster, we should document this a possible alternative for HA.
Support and sales are vitally interested in this. Hence the customer label.
At various times it was commented that the decision tree for recently added in host reservation docs is very useful. Regardless if this ends up as a KB article or part of Kea ARM, there should be a decision tree helping the reader to navigate through available options.next-stable-3.0https://gitlab.isc.org/isc-projects/kea/-/issues/1463Performance improvement: lookup leases by address first when address is avail...2023-07-31T13:14:28ZAndrei Pavelandrei@isc.orgPerformance improvement: lookup leases by address first when address is availableEdit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by addre...Edit: TLDR: This issue is about looking up leases by address hint in renews and v6 requests. Currently, they are first searched by DUID/client ID. Because these are not primary keys, but indexes, this lookup is slower. Searching by address which is a primary key should be significantly faster. I imagine this as a few lines of code changed, although it is affecting the allocation engine. There are concerns that this might affect host reservations, RADIUS or other aspects. I expect that to come up in tests.
---
When designing database scehmas, it is desirable to look at access patterns in order to define keys or indexes or maybe entire table definitions. When looking at the DHCP protocol, we can easily figure out that the key that we most want to use in a lookup is the client's identifier which is usually the DUID or client ID. This is not the case for current Kea since address is clearly chosen as sole primary key across all backends for the lease databases. This is probably because it is chosen based on it's unique properties. A v6 client can have multiple addresses per DUID and maybe it's the same for v4 in same strange use cases. This could have been solved by storing addresses as a list in DUID/clientID-keyed tables at the cost of complexity. But that is not my proposal.
We can leverage the current table structure by looking up by address when possible. This is effectively the case when an address hint is provided. A well known case when this happens is during the renew process, but I think I remember reading from a RFC that it can be provided in other DHCP messages as well. But a well-behaved client should (RFC SHOULD?) always send the address in their RENEW (I think it's still called REQUEST for DHCPv4?) and RENEWs are 99% of the DHCP messages sent in networks with high uptime. So it is an optimization for RENEW.
Concerns:
* Security? Honoring DHCP clients requesting address directly might lead to address starvation?
* No, after lookup by address finds nothing, the usual DISCOVER & SOLICIT messages go through with looking up by DUID/clientID. And then it will find the lease that belonged to the malicious client. Even if it did, add that to the list of security issues. Clients spoofing their DUID/clientID doesn't do the same?
* Are we sure we aren't providing the address to the wrong client?
* Yes. We can check in-memory/in-server if the DUIDs/clientIDs match. Even though what harm can the right lease given to the wrong client do?
* Does this affect the ability to reserve addresses/prefixes, RADIUS, hooks or other use-cases?
* To be investigated. I don't know. Because firstly I don't understand why host reservations are looked up before leases. This optimization is less impactful if we still search by DUID/clientID in hosts first. I would move the address lookup in the lease database at the beginning of the packet processing. But then why not move the DUID/clientID lookup at the beginning as well? If the client has an active lease, doesn't it stop there?backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1045Implement wipe commands for PgSQL and MySQL2020-04-29T10:35:15ZTomek MrugalskiImplement wipe commands for PgSQL and MySQL@fdupont reported that wipe commands for MySQL and PgSQL are not implemented. This is an unfortunate omission.
We need to implement them.
One thing to do is to look at older branches. Perhaps there's some code there. I vaguely recall t...@fdupont reported that wipe commands for MySQL and PgSQL are not implemented. This is an unfortunate omission.
We need to implement them.
One thing to do is to look at older branches. Perhaps there's some code there. I vaguely recall they were being discussed with some code written, but I may be misremembering.outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/1039avoiding race conditions when sharing database between processes or threads2021-10-20T10:31:31ZRazvan Becheriuavoiding race conditions when sharing database between processes or threadsthis ticket is intended to clarify the design needed to make 2 servers using the same database function properly.
the main problem is that, by having 2 separate servers or threads, one could insert/delete/update one lease at the same tim...this ticket is intended to clarify the design needed to make 2 servers using the same database function properly.
the main problem is that, by having 2 separate servers or threads, one could insert/delete/update one lease at the same time the other does some similar action.
this ticket is no related to multi-threading but the MT design relies on the fact that the functionality of 2 servers sharing the database is handled properlyoutstandingRazvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/kea/-/issues/1027Database reconnect settings ignored during startup2023-11-18T09:34:42ZChrisDatabase reconnect settings ignored during startup**Describe the bug**
During startup if the database is unreachable (which is easily possible during boot since there is, understandably, no dependency/ordering on sql servers in the default systemd unit) kea-server will immediately shut...**Describe the bug**
During startup if the database is unreachable (which is easily possible during boot since there is, understandably, no dependency/ordering on sql servers in the default systemd unit) kea-server will immediately shut down despite reconnect settings.
Since there is a chance for the SQL database to be available after kea is being started this can lead to kea not running after boot despite being expected to.
**To Reproduce**
Steps to reproduce the behavior:
1. Configure Kea with mysql leases/reservations including reconnect options ("max-reconnect-tries": 10,"reconnect-wait-time": 1000)
2. Stop and start kea + mysql, kea before mysql
```
service isc-kea-dhcp4-server stop; service mysql stop; service isc-kea-dhcp4-server start; service mysql start; sleep 1; service isc-kea-dhcp4-server status;
```
3. See that no reconnect attempts were made
**Expected behavior**
Kea to use the reconnect options during startup
**Environment:**
- Kea version: 1.6.0
- OS: Ubuntu 18.04 x64
- From ISC Kea repository
- If/which hooks where loaded in: lease-commands, haoutstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/980MySQL Group Replication doesn't support foreign key cascade2021-04-06T09:26:00ZGhost UserMySQL Group Replication doesn't support foreign key cascade**COMPLETELY UPDATED**
I'm using Kea 1.7.0 (installed via the cloudsmith.io yum repo) on CentOS 7.7.1908 with all updates installed. I'm using MySQL 8.0.18 installed from MySQL's yum repo for the backend. MySQL is configured with Group ...**COMPLETELY UPDATED**
I'm using Kea 1.7.0 (installed via the cloudsmith.io yum repo) on CentOS 7.7.1908 with all updates installed. I'm using MySQL 8.0.18 installed from MySQL's yum repo for the backend. MySQL is configured with Group Replication.
I ran into this issue trying to insert into dhcp4_options while doing a host reservation.
After digging into MySQL logs I found these errors:
[ERROR] [MY-011543] [Repl] Plugin group_replication reported: 'Table dhcp4_audit has a foreign key with 'CASCADE' clause. This is not compatible with Group Replication.'
[ERROR] [MY-011543] [Repl] Plugin group_replication reported: 'Table dhcp6_audit has a foreign key with 'CASCADE' clause. This is not compatible with Group Replication.'
I set the following foreign keys to no action:
* fk_dhcp4_audit_revision on update
* fk_dhcp6_audit_revision on update
* fk_dhcp4_subnet_shared_network on delete
* fk_dhcp6_subnet_shared_network on delete
* fk_dhcp4_pool_subnet_id on update
* fk_dhcp6_pool_subnet_id on update
* fk_dhcp6_pd_pool_subnet_id on update
Making these changes appears to work. I can insert and delete reservations and reservation specific options and Kea uses the reservations to respond to requests. However, I'm assuming these constraints are in there for a reason so what have I broken by doing this?outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/849Kea MySQL CB accepts an option for non-existing subnet2022-11-02T15:10:18ZMarcin SiodelskiKea MySQL CB accepts an option for non-existing subnetIt is possible to set a DHCP option with the `remote-option4-subnet-set` for non-existing subnet. It is possible that the same issue is present for other similar commands.It is possible to set a DHCP option with the `remote-option4-subnet-set` for non-existing subnet. It is possible that the same issue is present for other similar commands.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/792quality of life improvement: kea-admin db-version fails on empty db2022-03-31T08:12:51ZTomek Mrugalskiquality of life improvement: kea-admin db-version fails on empty dbkea-admin db-version prints the following error:
```
# kea-admin db-version mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1146 (42S02) at line 1: Table 'keatest.schema_version' doesn't exis...kea-admin db-version prints the following error:
```
# kea-admin db-version mysql
mysql: [Warning] Using a password on the command line interface can be insecure.
ERROR 1146 (42S02) at line 1: Table 'keatest.schema_version' doesn't exist
```
when run on an empty DB (without any schema).
Instead, it should catch the fact that schema_version does not exist and should point user to kea-admin db-init command.
This is a quality of life improvement, so it's not terribly important.outstanding