ISC Open Source Projects issueshttps://gitlab.isc.org/groups/isc-projects/-/issues2022-06-01T11:08:25Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/662Memory usage is unreadable for small values2022-06-01T11:08:25ZSlawek FigielMemory usage is unreadable for small valuesThe issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253080
Memory usage percentage on the machines list page is unreadable.The issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253080
Memory usage percentage on the machines list page is unreadable.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/661Cross icon is larger than others2022-06-23T09:58:13ZSlawek FigielCross icon is larger than othersThe issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253062
The red cross icon in the dashboard is visibly larger than other icons.The issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253062
The red cross icon in the dashboard is visibly larger than other icons.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/659Stork Server shutting down event it logged twice2023-12-06T09:19:10ZSlawek FigielStork Server shutting down event it logged twiceThe issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253038
When running stork-server in the console and shutting it down with ctrl-c, the shutting down event...The issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253038
When running stork-server in the console and shutting it down with ctrl-c, the shutting down event it logged twice.![stork-double-shutdown](https://gitlab.isc.org/isc-projects/stork/uploads/327df5a8afea527115b241c8a4b94cd6/stork-double-shutdown.png)
Here's what I see in the console:
```
^CINFO[2021-12-07 14:57:25] main.go:37 Received Ctrl-C signal
INFO[2021-12-07 14:57:25] eventcenter.go:117 event 'shutting down Stork Server'
INFO[2021-12-07 14:57:25] server.go:224 Shutting down Stork Server
INFO[2021-12-07 14:57:25] restservice.go:312 Stopping ReST API Service
INFO[2021-12-07 14:57:25] restservice.go:257 stopped serving Stork Server
INFO[2021-12-07 14:57:25] eventcenter.go:117 event 'shutting down Stork Server'
INFO[2021-12-07 14:57:25] sse.go:65 to 0xc0009581c0 sent {"ID":32,"CreatedAt":"2021-12-07T13:57:25.837546Z","Text":"shutting down Stork Server","Level":0,"Relations":{},"Details":""}
INFO[2021-12-07 14:57:25] server.go:224 Shutting down Stork Server
INFO[2021-12-07 14:57:25] restservice.go:312 Stopping ReST API Service
INFO[2021-12-07 14:57:25] sse.go:65 to 0xc0009581c0 sent {"ID":33,"CreatedAt":"2021-12-07T13:57:25.839525Z","Text":"shutting down Stork Server","Level":0,"Relations":{},"Details":""}
```backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/658Confused help and unused arguments in Stork Agent CLI2021-12-28T14:34:47ZSlawek FigielConfused help and unused arguments in Stork Agent CLIThe issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253037
The hint is in the help: `stork-agent [global options] command [command options] [arguments...]`. ...The issue was found during sanity checks for the 1.0 release.
Source: https://gitlab.isc.org/isc-projects/stork/-/issues/645#note_253037
The hint is in the help: `stork-agent [global options] command [command options] [arguments...]`. But how the user is supposed to know which options are global and which are command?
Why does it ask about the host or port when I specifically defined in using --host and --port? If it really has to ask, it should use the port I told it to use as a default.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2230Optionally put the database password in a file2023-08-21T14:05:56ZFrancis DupontOptionally put the database password in a fileExtension of #2006 to database configuration. With #34 aka database communication over SSL/TLS this will greatly improve security.Extension of #2006 to database configuration. With #34 aka database communication over SSL/TLS this will greatly improve security.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/648Machine de-authorization2021-12-21T14:54:16ZVicky Riskvicky@isc.orgMachine de-authorizationUsing the Stork 1.0 demo on lab.isc.org, I find that after authorizing some machines, if I want to remove them from view there is no option to de-authorize them. The only option is 'Remove' which then makes them impossible to re-authoriz...Using the Stork 1.0 demo on lab.isc.org, I find that after authorizing some machines, if I want to remove them from view there is no option to de-authorize them. The only option is 'Remove' which then makes them impossible to re-authorize.
It would be very useful to be able to remove some Apps temporarily from view by de-authorizing them, without losing access to them entirely. For example, if you want to just see data from a few apps that are giving you trouble, you could temporarily de-authorize the other apps to focus on just the data you want to see.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/647Don't display DHCPv6 subnets on dashboard if no DHCPv6 apps being monitored2023-01-09T12:05:17ZVicky Riskvicky@isc.orgDon't display DHCPv6 subnets on dashboard if no DHCPv6 apps being monitoredWith the Stork 1.0 candidate (using the stork lab set up) the dashboard displays a blank area for DHCPv6 subnets. It would be better to omit that section of the dashboard if the Stork server is not monitoring any authorized DHCPv6 apps. ...With the Stork 1.0 candidate (using the stork lab set up) the dashboard displays a blank area for DHCPv6 subnets. It would be better to omit that section of the dashboard if the Stork server is not monitoring any authorized DHCPv6 apps. It is a lot of screen real estate to waste in an environment where they are not using DHCPv6 at all.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2212Kea IPv6 build in Docker container: can't initially bind to link-local addres...2022-11-02T15:10:41ZK. M. PetersonKea IPv6 build in Docker container: can't initially bind to link-local address, error isn't clearly actionable**Describe the bug**
Implementing Kea DHCP in a Docker container, initial startup results in dhcp6 "active" but not listening or responsive due to attempt to bind to link-local IPv6 address.
Message: `WARN [kea-dhcp6.dhcpsrv/44.140567...**Describe the bug**
Implementing Kea DHCP in a Docker container, initial startup results in dhcp6 "active" but not listening or responsive due to attempt to bind to link-local IPv6 address.
Message: `WARN [kea-dhcp6.dhcpsrv/44.140567258032256] DHCPSRV_OPEN_SOCKET_FAIL failed to open socket: Failed to open link-local socket on interface eth0: Failed to bind socket 12 to fe80::b47a:f100:1fa6:671e/port=547: Cannot assign requested address`
The only way to automate a test for this state is to process the log. The dhcp6 process continues to run but is not operational. A `keactrl stop dhcp6; keactrl start dhcp6` seems to fix the issue.
**To Reproduce**
Steps to reproduce the behavior:
1. Configuration including dhcpv6; starting with `keactrl start`. Interface eth0 defined in configuration.
2. DHCPv4 server starts normally. DHCP6 server starts, fails.
**Expected behavior**
Two levels of difficulty: first, why does this error occur (possibly related to issues/321?). Second, the process does not die, making it difficult to detect. Process is "started" even though:
`2021-11-29 01:02:22.946 WARN [kea-dhcp6.dhcp6/44.140564753819776] DHCP6_MULTI_THREADING_INFO enabled: no, number of threads: 0, queue size: 0
2021-11-29 01:02:22.946 INFO [kea-dhcp6.dhcp6/44.140564753819776] DHCP6_STARTED Kea DHCPv6 server version 2.0.0 started`
**Environment:**
- Kea version: 2.0.0 general distribution.
- OS: CentOS 7, docker container
- No changes made to default configure script.
**Additional Information**
Build [Dockerfile](/uploads/ecedc999141e92f6cb5c104daa228bb8/Dockerfile)
Build/run [docker-compose.yml](/uploads/c252d2371cbeb2a1d7b708ffebf8259b/docker-compose.yml)
Sanitized/excerpted [kea-dhcp6.conf](/uploads/2763097189c8f38cde2432506ec004e5/kea-dhcp6.conf)
Init script in container [init_kea](/uploads/b1531b73332d70a7dc932835dd0bf7a8/init_kea)
**Contacting you**
I'm not primarily a dev, so I've perhaps left something out; contact kmp@kmpeterson.com or associated github address. I do have a (horrible, as you can see) workaround for this, not high priority. Thanks!backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/636Supported systems - Debian2021-11-30T14:45:02ZSlawek FigielSupported systems - DebianDo we really not supporting Debian? Maybe consider to extend supported systems. [supported systems](https://stork.readthedocs.io/en/latest/install.html#supported-systems).Do we really not supporting Debian? Maybe consider to extend supported systems. [supported systems](https://stork.readthedocs.io/en/latest/install.html#supported-systems).backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/635Inform about agent being uninstalled2021-11-30T14:42:37ZSlawek FigielInform about agent being uninstalledProvide info in the Stork UI that the agent was uninstalled/removed. So far there is a generic error that could mean more things like network issues, ...Provide info in the Stork UI that the agent was uninstalled/removed. So far there is a generic error that could mean more things like network issues, ...backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/634Add option to ignore agent2021-11-30T14:36:50ZSlawek FigielAdd option to ignore agentConsider to add option to ignore agent otherwise the agent will keep recurring.Consider to add option to ignore agent otherwise the agent will keep recurring.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/630Make STORK_AGENT_ADDRESS optional2021-11-30T20:37:01ZSlawek FigielMake STORK_AGENT_ADDRESS optionalSTORK_AGENT_ADDRESS should be optional and by default Stork should try to fetch the IP address from the system automatically (primary interface). In the case of multiple interfaces, take the one used (by the system) to reach "STORK_SERVE...STORK_AGENT_ADDRESS should be optional and by default Stork should try to fetch the IP address from the system automatically (primary interface). In the case of multiple interfaces, take the one used (by the system) to reach "STORK_SERVER_URL".backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/619Connect to agent over IPv6 link-local address2021-11-30T14:28:16ZSlawek FigielConnect to agent over IPv6 link-local addressThe connection between Stork Agent and Stork Server doesn't work when the Agent uses a link-local IPv6 address.
The Stork Server rejects this address during validation. But even if the validation will change there is one more problem.
...The connection between Stork Agent and Stork Server doesn't work when the Agent uses a link-local IPv6 address.
The Stork Server rejects this address during validation. But even if the validation will change there is one more problem.
The apps in the Stork Server use schema `APPNAME@AGENTADDRESS%NUM`. The NUM is sequential and optional.
The zone ID in the link-local address (e.g. `fe80::%eth0`) is recognized as an app number. Additionally, the validator denies multiple app numbers in the name.
The validation is implemented partially as the database triggers.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2203Update doc about ways to get the config/build report2023-03-08T09:40:04ZFrancis DupontUpdate doc about ways to get the config/build reportThere are 2 or 3 ways to get the config/build report when the config.report file itself is not available:
- the -W command line argument
- a grep for ';;;;' on the extracted strings from the main binary
- when there is a control chann...There are 2 or 3 ways to get the config/build report when the config.report file itself is not available:
- the -W command line argument
- a grep for ';;;;' on the extracted strings from the main binary
- when there is a control channel the build-report command
All have different constraints: the first requires to run the binary, the second is more hairy but requires only access to the main binary, and the last requires a running binary but can be done remotely.
Unfortunately it seems this is not explained in the ARM for all Kea commands compiled from C++ so:
- the ARM must be updated
- each way should be checked (some failures were reported and fixed so do not assume they work)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2191ddns with dhcp6 not working2022-11-02T15:10:41ZChristian Böschddns with dhcp6 not workingKea 2.0.0
DDNS updates are not working with DHCP6. IPv6 address is assigned but nothing happens with D2.
I've tried a tcpdump on lo0, but no traffic to 53001.
If I try the same with DHCP4 everything is fine and DDNS is updated.
config s...Kea 2.0.0
DDNS updates are not working with DHCP6. IPv6 address is assigned but nothing happens with D2.
I've tried a tcpdump on lo0, but no traffic to 53001.
If I try the same with DHCP4 everything is fine and DDNS is updated.
config snippets:
```
{
"DhcpDdns":
{
"ip-address": "127.0.0.1",
"port": 53001,
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea-ddns-ctrl-socket"
},
"tsig-keys": [
{
"name": "dhcp-update.",
"algorithm": "hmac-md5",
"secret": "replaced"
}
],
"forward-ddns" : {
"ddns-domains": [
{
"dns-servers": [
{
"ip-address": "2002:629:2131:2300::53:1",
"port": 53
}
],
"key-name": "dhcp-update.",
"name": "lan6.abc.net."
},
....
```
```
{
"Dhcp6": {
"interfaces-config": {
"interfaces": [ "vmx0/2002:629:2131:2300::547:11" ]
},
"control-socket": {
"socket-type": "unix",
"socket-name": "/tmp/kea6-ctrl-socket"
},
"dhcp-ddns" : {
"enable-updates" : true,
"server-ip": "127.0.0.1",
"server-port":53001
},
...
"subnet6": [
{
"subnet": "2002:629:2131:445C::/64",
"id": 2016,
"rapid-commit": true,
"pools": [ { "pool": "2002:629:2131:445C::4-2002:629:2131:445C::80", "client-class": "registered-server1" },
{ "pool": "2002:629:2131:445C::81-2002:629:2131:445C::FF", "client-class": "registered-server2" } ],
"reservations-global": true,
"reservations-in-subnet": false,
"ddns-override-client-update": true,
"ddns-override-no-update": true,
"ddns-send-updates": true,
"ddns-qualifying-suffix": "lan6.abc.net.",
"hostname-char-set": "[^A-Za-z0-9.-]",
"hostname-char-replacement": "x"
}
],
...
```backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/611Add new Kea config checkers2023-01-31T14:26:52ZMarcin SiodelskiAdd new Kea config checkersWe have gathered the following ideas for the new config checkers:
- [x] 1. if there is only one subnet in a shared network, suggest disabling shared network;
- [x] 2. if there is in-pool reservation enabled, but there are no in-pool res...We have gathered the following ideas for the new config checkers:
- [x] 1. if there is only one subnet in a shared network, suggest disabling shared network;
- [x] 2. if there is in-pool reservation enabled, but there are no in-pool reservations, suggest out-of-pool as better performant;
- [ ] 3. if there is custom option definition, but no option-data that uses it, suggest removing unused defintions;
- [x] 4. if there are subnets without any pools and no reservations, suggest removing unused subnets;
- [ ] 5. inspect HA configs of both servers and make sure there are no discrepancies;
- [ ] 6. it's possible to misconfigure ports in HA+MT configuration, so it's still connecting via CA rather than with DHCP directly. #611
- [ ] 7. if there is the Stork Agent configured to use Basic Auth, but the Kea CAs use HTTP only (@slawek)
- [ ] 8. you might check whether the customer has both the subnet commands hook and the config backend hook. a lot of people don't seem to understand these are sort of mutually exclusive (@vicky) #940
- [ ] 9. db backends configured and no secrets provided for the connection (@vicky)
- [ ] 10. if your pool equals the number of reservations, warn that devices not in the reserved list will not get an address (support) #941
- [ ] 11. HA ST but Kea MT - suggest to enable MT for HA #611
We could pick one, two or three and add them for the 1.0. Other to be postponed.
UPDATE: A nice list of ideas was discussed on [DHCP/support call on 2021-11-03](https://pad.isc.org/p/dhcp-call-2021-11-03#L119).backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2169ddns-rev-domainname2022-11-02T15:10:41ZPeter Daviesddns-rev-domainnameThe ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0....The ISC dhcp server has the "ddns-rev-domainname" keyword which allows one to override the default reverse dns domain.
This could be handy when working with delegations of address spaces below octet boundaries.
for example:
20.0.168.192.in-addr.arpa. CNAME 20.0-64.0.168.192.in-addr.arpa.
20.0-64.0.168.192.in-addr.arpa. PTR mypc.example.com.
From a question raised on Kea-users@lists.isc.org mailing list.backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2168kea-dhcp4 hangs after kea-dhcp-ddns error2022-11-02T15:10:41Zdirk winterkea-dhcp4 hangs after kea-dhcp-ddns error---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
We use 4 kea-dhcp4 services in our network. The kea services run in High Availability (HA) mode. 1 as primary, 1 as standby and 2 as backup nodes. A...---
name: Bug report
about: Create a report to help us improve
---
**Describe the bug**
We use 4 kea-dhcp4 services in our network. The kea services run in High Availability (HA) mode. 1 as primary, 1 as standby and 2 as backup nodes. As backend we use mariadb-server-10.3. The databases run in High Availability mode galera-3.
The service is running and DHCP requests are processed. If there is an error with the dynamic DNS entries, the kea-dhcp4 service stops. In the process list the kea services are visible, but the dhcp4 service stops responding.
**To Reproduce**
Steps to reproduce the behavior:
1. services kea-dhcp-ddns, kea-dhcp4, kea-ctrl-agent.
2. a client stops and releases its IP address, the kea-dhcp-ddns returns an error
3. the server stops
4.
```
Nov 3 13:39:14 bla0022 kea-dhcp-ddns: ERROR [kea-dhcp-ddns.d2-to-dns.140257951971200] DHCP_DDNS_FORWARD_REMOVE_ADDRS_REJECTED DNS Request ID 000101528812ABEE2C22399F0F3A3B7AFFF20D24A940285564B2E713F01ED1F46A2EA2: Server, 127.0.0.1 port:5300, rejected a DNS update request to remove the forward address mapping for FQDN, <SERVER-FQDN>., with an RCODE: 2
Nov 3 13:39:14 bla0022 kea-dhcp-ddns: ERROR [kea-dhcp-ddns.d2-to-dns.140257951971200] DHCP_DDNS_REMOVE_FAILED DHCP_DDNS Request ID 000101528812ABEE2C22399F0F3A3B7AFFF20D24A940285564B2E713F01ED1F46A2EA2: Transaction outcome: Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse change: failed, request: Type: 1 (CHG_REMOVE)#012Forward Change: yes#012Reverse Change: yes#012FQDN: [<SERVER-FQDN>.]#012IP Address: [10.189.16.71]#012DHCID: [000101528812ABEE2C22399F0F3A3B7AFFF20D24A940285564B2E713F01ED1F46A2EA2]#012Lease Expires On: 20211103123909#012Lease Length: 604800#012
```
**Expected behavior**
The server catches the error and continues to run normally
**Environment:**
- Kea version: 1.8.2-isc0001520201206093433
- OS: Ubuntu 20.04.2 LTS x86_64
- offical isc deb package
- hooks libdhcp_lease_cmds.so libdhcp_stat_cmds.so libdhcp_ha.so
**Additional Information**
```
Nov 3 13:39:08 bla0022 kea-ctrl-agent: INFO [kea-ctrl-agent.ctrl-agent.140579089548864] CTRL_AGENT_COMMAND_FORWARDED command reservation-get-page successfully forwarded to the service dhcp4
Nov 3 13:39:14 bla0022 kea-ctrl-agent: INFO [kea-ctrl-agent.commands.140579089548864] COMMAND_RECEIVED Received command 'ha-heartbeat'
Nov 3 13:39:14 bla0022 kea-dhcp-ddns: ERROR [kea-dhcp-ddns.d2-to-dns.140257951971200] DHCP_DDNS_FORWARD_REMOVE_ADDRS_REJECTED DNS Request ID 000101528812ABEE2C22399F0F3A3B7AFFF20D24A940285564B2E713F01ED1F46A2EA2: Server, 127.0.0.1 port:5300, rejected a DNS update request to remove the forward address mapping for FQDN, <SERVER-FQDN>., with an RCODE: 2
Nov 3 13:39:14 bla0022 kea-dhcp-ddns: ERROR [kea-dhcp-ddns.d2-to-dns.140257951971200] DHCP_DDNS_REMOVE_FAILED DHCP_DDNS Request ID 000101528812ABEE2C22399F0F3A3B7AFFF20D24A940285564B2E713F01ED1F46A2EA2: Transaction outcome: Status: Failed, Event: UPDATE_FAILED_EVT, Forward change: failed, Reverse change: failed, request: Type: 1 (CHG_REMOVE)#012Forward Change: yes#012Reverse Change: yes#012FQDN: [<SERVER-FQDN>.]#012IP Address: [10.189.16.71]#012DHCID: [000101528812ABEE2C22399F0F3A3B7AFFF20D24A940285564B2E713F01ED1F46A2EA2]#012Lease Expires On: 20211103123909#012Lease Length: 604800#012
Nov 3 13:40:14 bla0022 kea-ctrl-agent: INFO [kea-ctrl-agent.commands.140579089548864] COMMAND_RECEIVED Received command 'version-get'
Nov 3 13:40:14 bla0022 kea-ctrl-agent: INFO [kea-ctrl-agent.commands.140579089548864] COMMAND_RECEIVED Received command 'ha-heartbeat'
Nov 3 13:41:14 bla0022 kea-ctrl-agent: INFO [kea-ctrl-agent.commands.140579089548864] COMMAND_RECEIVED Received command 'ha-heartbeat'
```
**Contacting you**
dirk.winter@itscare.de
[isc-kea-dhcp4.conf](/uploads/cc7c43bbb64d570cee0b4e5ac3252218/isc-kea-dhcp4.conf)backloghttps://gitlab.isc.org/isc-projects/kea/-/issues/2123Loose / indirect dependencies in testutils libraries2022-11-02T15:10:40ZFrancis DupontLoose / indirect dependencies in testutils librariesThis should not have customer impact but Makefile.am files for testutils libraries show loose / indirect dependencies.
Usually indirect dependencies work but not in all cases.
The right way to find dependencies is to use ldd (otool -L ...This should not have customer impact but Makefile.am files for testutils libraries show loose / indirect dependencies.
Usually indirect dependencies work but not in all cases.
The right way to find dependencies is to use ldd (otool -L on macOS) to list dependencies from the library object. Note that dependencies should be added in the right order i.e. the reserve order `src/lib/Makefile.am` build them. Do not forget external (i.e. not Kea) dependencies too as the crypto backend.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/588Load kea config from another kea server2021-10-12T13:17:29ZPeter DaviesLoad kea config from another kea serverLoad kea config from another kea server
I would appear we have all the necessary mechanisms to enable a secondary HA server to load its configuration from the primary.
This feature could be enabled with a command line parameter that co...Load kea config from another kea server
I would appear we have all the necessary mechanisms to enable a secondary HA server to load its configuration from the primary.
This feature could be enabled with a command line parameter that could instruct the server to look and retrieve its config from a server/address before loading its local config.
In this way users running into issues caused by mismatching configurations and typos.
The interface name and "this-server-name" would need to be syntherzied somehow.backlog