Kea issueshttps://gitlab.isc.org/isc-projects/kea/-/issues2024-03-22T13:05:49Zhttps://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/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/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/329Add a verbose flag to developer YANG module check scripts.2022-11-02T15:08:43ZFrancis DupontAdd a verbose flag to developer YANG module check scripts.Add a verbose flag to `src/share/yang/modules/utils/check-{hashes, revisions}.sh`.
cf #204Add a verbose flag to `src/share/yang/modules/utils/check-{hashes, revisions}.sh`.
cf #204backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/1912update lib dns++ python tools2021-06-03T15:37:03ZFrancis Dupontupdate lib dns++ python tools#1880 showed that even they still work the python tools used for the dns++ library should be updated:
- src/lib/dns/gen-rdatacode.py complains about a not existing (BTW for a long time) file in a not existing (this point triggers the er...#1880 showed that even they still work the python tools used for the dns++ library should be updated:
- src/lib/dns/gen-rdatacode.py complains about a not existing (BTW for a long time) file in a not existing (this point triggers the error) src/lib/dns/python directory. IMHO the corresponding code is obsolete i.e. implements a feature which has not been used since a lot of years if it was used one day...
- src/lib/util/python/gen_wiredata.py triggers a warning with python3. I added a comment at the corresponding line of code.
The documentation should be updated too: for the first script it is in the s-rdatacode entry of the Makefile. The second is in a commented entry of the src/lib/dns/tests/testdata Makefile and requires to be called in the UTC timezone when timestamps are generated as for RRSIG or TKEY RRs (I used with success the TZ environment variable).outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/902Configuration Backend in DHCPv4 dhcp4_subnet not display2019-10-03T19:12:39ZGhost UserConfiguration Backend in DHCPv4 dhcp4_subnet not display![image](/uploads/78df9669353f2e41db6aac33097f6b65/image.png)
this is sql dhcp4_options tables
this is post confi-get , not code 3 display in subnet id 216,99
"subnet4": [
{
"4o6-interface": "...![image](/uploads/78df9669353f2e41db6aac33097f6b65/image.png)
this is sql dhcp4_options tables
this is post confi-get , not code 3 display in subnet id 216,99
"subnet4": [
{
"4o6-interface": "",
"4o6-interface-id": "",
"4o6-subnet": "",
"id": 99,
"option-data": [
{
"always-send": false,
"code": 3,
"csv-format": true,
"data": "192.168.0.1",
"name": "routers",
"space": "dhcp4"
}
],
"pools": [
{
"option-data": [],
"pool": "192.168.0.10-192.168.0.100"
}
],
"relay": {
"ip-addresses": []
},
"reservations": [],
"subnet": "192.168.0.0/24"
},
{
"4o6-interface": "",
"4o6-interface-id": "",
"4o6-subnet": "",
"id": 100,
"option-data": [],
"pools": [
{
"option-data": [],
"pool": "192.168.1.10-192.168.1.100"
}
],
"relay": {
"ip-addresses": []
},
"reservations": [],
"subnet": "192.168.1.0/24"
},
{
"4o6-interface": "",
"4o6-interface-id": "",
"4o6-subnet": "",
"id": 216,
"option-data": [
{
"always-send": false,
"code": 6,
"csv-format": true,
"data": "172.22.1.253",
"name": "domain-name-servers",
"space": "dhcp4"
},
{
"always-send": false,
"code": 4,
"csv-format": true,
"data": "10.10.10.50",
"name": "time-servers",
"space": "dhcp4"
}
],
"pools": [
{
"option-data": [],
"pool": "172.30.216.10-172.30.216.20"
}
],
"relay": {
"ip-addresses": []
},
"reservations": [],
"subnet": "172.30.216.0/21"
}
],outstandinghttps://gitlab.isc.org/isc-projects/kea/-/issues/705Solve the problem of variable expansion in general way2022-05-30T14:23:38ZMichal NowikowskiSolve the problem of variable expansion in general wayThe ticket evolved into a request to solve the variable expansion in a generic way. The solution should work for:
- makefiles
- scripts (both internal and external)
- documentation (.rst and man pages)
- config file examples
The origina...The ticket evolved into a request to solve the variable expansion in a generic way. The solution should work for:
- makefiles
- scripts (both internal and external)
- documentation (.rst and man pages)
- config file examples
The original description is as follows:
wipe_data.sh.in contains:
```bash
if [ -e @datarootdir@/@PACKAGE_NAME@/scripts/admin-utils.sh ]; then
. @datarootdir@/@PACKAGE_NAME@/scripts/admin-utils.sh
else
. @abs_top_builddir@/src/bin/admin/admin-utils.sh
fi
```
and this is evaluated by ./configure to:
```bash
if [ -e ${prefix}/share/kea/scripts/admin-utils.sh ]; then
. ${prefix}/share/kea/scripts/admin-utils.sh
else
. /home/test/workspace/kea-master-system-tests-v6/src/bin/admin/admin-utils.sh
fi
```
but ${prefix} has to been substituted but should have been.
After ./configure it should be:
```bash
if [ -e /usr/local/share/kea/scripts/admin-utils.sh ]; then
. /usr/local/share/kea/scripts/admin-utils.sh
else
. /home/test/workspace/kea-master-system-tests-v6/src/bin/admin/admin-utils.sh
fi
```
Generally this problem is broader. It touches many generated files by autoconf using AC_CONFIG_FILES.
One of the solution is using path_replacer.sh but it is inconvenient. Other approach is using sh script and makaefiles capabilities of resolving unresolved vars on its own. But it does not work in e.g. config files.
It would be good to have one solution for all.outstandingMichal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/kea/-/issues/330keactrl should better handle disabled services2022-11-02T15:24:12ZTomek Mrugalskikeactrl should better handle disabled servicesThis is a follow-up coming form #186 review.
There's a section in keactrl.conf that has flags for each daemon:
```
# Start DHCPv4 server?
dhcp4=yes
# Start DHCPv6 server?
dhcp6=yes
# Start DHCP DDNS server?
dhcp_ddns=no
# Start Contr...This is a follow-up coming form #186 review.
There's a section in keactrl.conf that has flags for each daemon:
```
# Start DHCPv4 server?
dhcp4=yes
# Start DHCPv6 server?
dhcp6=yes
# Start DHCP DDNS server?
dhcp_ddns=no
# Start Control Agent?
ctrl_agent=yes
# Start Netconf?
netconf=no
```
When a service is set to false, there's no way to start it using keactrl. For example:
```
root@billabong:/opt186# sbin/keactrl start -s netconf
root@billabong:/opt186# sbin/keactrl stop -s netconf
INFO/keactrl: kea-netconf isn't running.
```
Note the start command. It quits silently without starting the netconf service.
IMHO the flags should govern whether the service is started when ALL services are started (keactrl start). There should always be a way to start the service manually.
If you strongly disagree with this, at the very least keactrl should print out why it didn't even try to start the service.outstanding