stork issueshttps://gitlab.isc.org/isc-projects/stork/-/issues2024-03-22T12:56:27Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/1193CA returns number overflow on ipv6 stats2024-03-22T12:56:27ZSlawek FigielCA returns number overflow on ipv6 statsThe issue was found during [1.13 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408666) by @slawek.
I have observed a weird error in logs:
```
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED R...The issue was found during [1.13 sanity checks](https://gitlab.isc.org/isc-projects/stork/-/issues/1187#note_408666) by @slawek.
I have observed a weird error in logs:
```
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'statistic-get-all'
stork-1130-agent-kea6-1 | INFO CTRL_AGENT_COMMAND_RECEIVED command statistic-get-all received from remote address 127.0.0.1
stork-1130-agent-kea6-1 | INFO COMMAND_RECEIVED Received command 'statistic-get-all'
stork-1130-agent-kea6-1 | time="2023-10-10 12:40:51" level="error" msg="Failed to parse responses from Kea: response result from Kea != 0: 1, text: internal server error: unable to parse server's answer to the forwarded message: Number overflow: 36893488147419103232 in <wire>:0:8422" file=" promkeaexporter.go:850 "
stork-1130-agent-kea6-1 | time="2023-10-10 12:40:51" level="error" msg="Some errors were encountered while collecting stats from Kea: response result from Kea != 0: 1, text: internal server error: unable to parse server's answer to the forwarded message: Number overflow: 36893488147419103232 in <wire>:0:8422\nisc.org/stork/agent.(*GetAllStatisticsResponse).UnmarshalJSON\n\tisc.org/stork/agent/promkeaexporter.go:149\nencoding/json.(*decodeState).array\n\tencoding/json/decode.go:507\nencoding/json.(*decodeState).value\n\tencoding/json/decode.go:364\nencoding/json.(*decodeState).unmarshal\n\tencoding/json/decode.go:181\nencoding/json.Unmarshal\n\tencoding/json/decode.go:108\nisc.org/stork/agent.(*PromKeaExporter).collectStats\n\tisc.org/stork/agent/promkeaexporter.go:847\nisc.org/stork/agent.(*PromKeaExporter).statsCollectorLoop\n\tisc.org/stork/agent/promkeaexporter.go:710\nruntime.goexit\n\truntime/asm_amd64.s:1650" file=" promkeaexporter.go:712 "
```1.16Slawek FigielSlawek Figiel2024-05-29https://gitlab.isc.org/isc-projects/stork/-/issues/1323Attach more labels to the Prometheus samples2024-03-19T14:58:05ZSlawek FigielAttach more labels to the Prometheus samplesCurrently, if you haven't the subnet_cmds hook, the metrics are labeled with the subnet ID, and if you have the subnet_cmds hook, the metrics are labeled with the subnet name prefix if provided, otherwise with the subnet ID.
Our custome...Currently, if you haven't the subnet_cmds hook, the metrics are labeled with the subnet ID, and if you have the subnet_cmds hook, the metrics are labeled with the subnet name prefix if provided, otherwise with the subnet ID.
Our customer needs samples labeled by subnet ID regardless of the subnet_cmds presence. It would also be helpful to attach the shared network name.
[SF#1762](https://isc.lightning.force.com/lightning/r/Case/500S6000006AQSSIA4/view)1.17https://gitlab.isc.org/isc-projects/stork/-/issues/1319Package issues during update2024-03-28T13:33:54ZDarren AnkneyPackage issues during updateIt was found that when updating to Stork 1.15.0 (in this case from 1.14.0) on RHEL 7 (and CentOS 7 though engineering states that this problem likely applies to all versions) that there are two problems encountered:
1. The Stork Server ...It was found that when updating to Stork 1.15.0 (in this case from 1.14.0) on RHEL 7 (and CentOS 7 though engineering states that this problem likely applies to all versions) that there are two problems encountered:
1. The Stork Server service ends up stopped in the disabled state even though it was enabled and started prior to update.
2. The `useradd` call in the postinstall script sets the homedir to `/var/lib` instead of `/var/lib/stork-server`.
A patch was provided by the reporter:
```
diff --git a/etc/hooks/rpm/isc-stork-server.postinst b/etc/hooks/rpm/isc-stork-server.postinst
index 3b890b75..7833efd4 100644
--- a/etc/hooks/rpm/isc-stork-server.postinst
+++ b/etc/hooks/rpm/isc-stork-server.postinst
@@ -4,5 +4,5 @@ set -eu
# add stork-server user if does not exist
if ! getent passwd stork-server > /dev/null; then
- useradd --system --home-dir /var/lib/ stork-server
+ useradd --system --base-dir /var/lib/ stork-server
fi
diff --git a/etc/hooks/rpm/isc-stork-server.prerm b/etc/hooks/rpm/isc-stork-server.prerm
index e4649e2c..cc007fbc 100644
--- a/etc/hooks/rpm/isc-stork-server.prerm
+++ b/etc/hooks/rpm/isc-stork-server.prerm
@@ -1,16 +1,17 @@
#!/bin/sh
set -eu
-
-has_active_systemd=0
-if command -v systemctl > /dev/null; then
- status=$(systemctl is-system-running || true)
- if [ "${status}" = "running" ] || [ "${status}" = "degraded" ] || [ "${status}" = "maintenance" ]; then
- has_active_systemd=1
+if [ "$1" -eq 0 ]; then # Uninstall == 0 not Upgrade == 1
+ has_active_systemd=0
+ if command -v systemctl > /dev/null; then
+ status=$(systemctl is-system-running || true)
+ if [ "${status}" = "running" ] || [ "${status}" = "degraded" ] || [ "${status}" = "maintenance" ]; then
+ has_active_systemd=1
+ fi
fi
-fi
-if [ $has_active_systemd -eq 1 ]; then
- systemctl disable isc-stork-server
- systemctl stop isc-stork-server
-fi
+ if [ $has_active_systemd -eq 1 ]; then
+ systemctl disable isc-stork-server
+ systemctl stop isc-stork-server
+ fi
+fi
```
[SF1727](https://isc.lightning.force.com/lightning/r/Case/500S6000005dJugIAE/view)1.16Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1222Make it obvious that an entire machine has stopped responding2024-02-22T18:14:29ZDarren AnkneyMake it obvious that an entire machine has stopped respondingCurrently, if an entire host with stork-agent + kea-* goes offline, there is not much indication in the Stork UI. Eventually, a message will appear in the Events on the right hand side. This was as reported to me by a customer during a...Currently, if an entire host with stork-agent + kea-* goes offline, there is not much indication in the Stork UI. Eventually, a message will appear in the Events on the right hand side. This was as reported to me by a customer during a call where I was helping him install Stork and do some testing. The customer was sharing their screen and I did see that nothing indicated that the host was gone. Under "machines" all of the services still had a green checkmark next to them even a few minutes later.
I propose that there should be an area of the GUI dedicated to warnings regarding various critical problems (like an entire machine has gone away). The events area is fine but it is filled with all kind of messages and users quickly learn to ignore it. Maybe, in addition to an area that shows warnings, there should be some kind of monitoring page where the current health of each component (even the entire host) could be shown visually. I think this type of screen is what the customer was ultimately after.
[SF1448](https://isc.lightning.force.com/lightning/r/Case/500S6000000sLFmIAM/view) and [SF1430](https://isc.lightning.force.com/lightning/r/Case/5007V00002ZyNuWQAV/view)1.16Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/1201Stork 1.13.0 not working on Ubuntu 20.04.6. LTS2023-12-06T18:32:23ZThomas MaurerStork 1.13.0 not working on Ubuntu 20.04.6. LTS---
name: Stork 1.13.0 not working on Ubuntu 20.04.6. LTS
about: `isc-stork-server`
---
**Describe the bug**
Stork V1.13.0 requires GLIBC_2.32 or newer. But on Ubuntu 20.04.6 LTS (focal) only 2.31 is available. However in the Documenta...---
name: Stork 1.13.0 not working on Ubuntu 20.04.6. LTS
about: `isc-stork-server`
---
**Describe the bug**
Stork V1.13.0 requires GLIBC_2.32 or newer. But on Ubuntu 20.04.6 LTS (focal) only 2.31 is available. However in the Documentation (https://stork.readthedocs.io/en/v1.13.0/install.html#supported-systems) Ubuntu 18.04 and 20.04 are reportet to work.
**To Reproduce**
Steps to reproduce the behavior:
1. Update stork to V1.13.0
2. Stork does not Start
3. in var/log/syslog is see:
Oct 16 08:26:34 sbcc-dhcp-0101 stork-server[1557772]: /usr/bin/stork-server: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/bin/stork-server)
Oct 16 08:26:34 sbcc-dhcp-0101 stork-server[1557772]: /usr/bin/stork-server: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by /usr/bin/stork-server)
Oct
**Expected behavior**
Update the Documentation or update the dependencies for Stork to run on Ubuntu 20.04
**Environment:**
- Kea version: 2.0.3
tarball
linked with:
log4cplus 1.1.2
OpenSSL 1.1.1f 31 Mar 2020
database:
MySQL backend 12.0, library 8.0.34
PostgreSQL backend 6.2, library 120016
Memfile backend 2.1
- Stork: 1.13.0.231011103556
- OS: Ubuntu 20.04.6 LTS
**Contacting you**
Feel free to contact me via E-Mail1.14Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1154Stop using self-signed certs during agent registration2023-10-04T17:26:11ZSlawek FigielStop using self-signed certs during agent registrationBug report:
Stork agent fails to start after upgrading to 1.12. It was working on the previous version.
The logs contain the below message:
```
Aug 30 20:00:43 user (...) time="2023-08-30 20:00:43" level="error" msg="problem registerin...Bug report:
Stork agent fails to start after upgrading to 1.12. It was working on the previous version.
The logs contain the below message:
```
Aug 30 20:00:43 user (...) time="2023-08-30 20:00:43" level="error" msg="problem registering machine: problem sending POST to https://host/api/machines: Post \"https://host/api/machines\": x509: certificate signed by unknown authority" file=" register.go:383 "
```1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1060Display of IPv6 subnets in Stork Server GUI2023-07-19T14:19:51Zbbuclin-attDisplay of IPv6 subnets in Stork Server GUIWhen listing subnets, or already on the home screen, /64 IPv6 subnet display is not too clean, as you can see in the screenshot attached. /64 subnets in an IPv6 network are the most frequent thing, and it would be nice to have a reasonab...When listing subnets, or already on the home screen, /64 IPv6 subnet display is not too clean, as you can see in the screenshot attached. /64 subnets in an IPv6 network are the most frequent thing, and it would be nice to have a reasonable display of those. Widening the left-most, “Subnet” table column might be a simple way of achieving it. The column should be sized to accommodate a complete /64 designation, eg. 2001:1234:5678:9abc::/64![Unknown](/uploads/1358ee0c08d607af94f41b92d6863d30/Unknown.png)1.12Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1039Apache configuration example with document root in a subdirectory2023-08-01T16:22:40ZSlawek FigielApache configuration example with document root in a subdirectory[support#22012](https://support.isc.org/Ticket/Display.html?id=22012#txn-879708)
A user wants to configure the Apache server to serve Stork from the `https://domain.example.com/stork` URL.[support#22012](https://support.isc.org/Ticket/Display.html?id=22012#txn-879708)
A user wants to configure the Apache server to serve Stork from the `https://domain.example.com/stork` URL.1.12Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1037External authentication using headers2023-05-23T13:20:55ZDarren AnkneyExternal authentication using headersSome web software packages support a method of remote authentication where REMOTE_USER headers are used. This might be called RemoteUserMiddleware, Header authentication, or a subset of Shibboleth.
In the Django world, there is an Auth...Some web software packages support a method of remote authentication where REMOTE_USER headers are used. This might be called RemoteUserMiddleware, Header authentication, or a subset of Shibboleth.
In the Django world, there is an AuthN backend called RemoteUserMiddleware: https://docs.djangoproject.com/en/4.2/howto/auth-remote-user/ which may describe the intent here.
[RT22012](https://support.isc.org/Ticket/Display.html?id=22012)backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1036Include statements with non-JSON extensions in Kea CA config2023-06-02T16:58:27ZSlawek FigielInclude statements with non-JSON extensions in Kea CA configStork supports the `include` statements in the Kea Control Agent configuration, but only if the included file has a `.json` extension. Kea allows any extensions. If the Kea Control Agent configuration contains the `include` statement wit...Stork supports the `include` statements in the Kea Control Agent configuration, but only if the included file has a `.json` extension. Kea allows any extensions. If the Kea Control Agent configuration contains the `include` statement with the non-JSON file, Stork throws an error and rejects the particular Kea.
The problem was reported on our mailing list on 2023-05-11:
> The Stork Agent is not happy when a KEA configuration file has an include statement in it. This is the error I see on the syslog:
>
> ```
> level="error" msg="Invalid Kea Control Agent config" file=" kea.go:215 " error="Cannot parse Kea Control Agent config file: problem parsing Kea configuration: invalid character '<' looking for beginning of object key string: invalid character '<' looking for beginning of object key string"
> ```
> And the configuration file it is trying to read is starting as:
> ```
> {
> "Control-agent": {
> <?include "/mnt/data/etc/kea/local-ctrl-agent.include"?>
> ```
>
> Hmm… KEA accepts the .include extension though, so shouldn’t Stork accept what KEA accepts?1.11Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/1033Persistent database of dhcp clients seen on the network2024-02-01T14:51:36ZVicky Riskvicky@isc.orgPersistent database of dhcp clients seen on the networkThis is a feature request for an endpoint database in Stork, of all the clients serviced by any of the Kea servers managed by Stork.
Stork users would like to be able to store, view and update client information that persists after the ...This is a feature request for an endpoint database in Stork, of all the clients serviced by any of the Kea servers managed by Stork.
Stork users would like to be able to store, view and update client information that persists after the lease may have been released. It would be useful to maintain a database of client information that could associate networked client identity with other administrative parameters that a help desk or network admin function might need.
Possible use cases
- identify the end user associated with an ip address or subnet of addresses, in order to send email notification about upcoming maintenance that might impact that subnet
- identify the date a client associated with a particular DNS host name was last seen on the network, to help in identifying abandoned hostnames in the DNS.
- identify the end user associated with a device for which there is an unused host reservation, in order to follow up off-line and possibly 'reclaim' that HR
- identifying all the printers scattered across multiple subnets, in order to move them all to a separate subnet
- determine the physical location for a client device that is misbehaving on the network in order to find it and remove it, update, or reboot it
- find all devices associated with an end user who has recently left the company, to determine whether any of those devices are still responding/renewing on the network
- identify the phone number associated with an ip phone, to update a directory listing (this is probably not the ideal way to do this however)
- locating all the users with client devices of a particular vendor and device type in case of an urgent security update (this is probably not the ideal way to do this however)
Possible db fields
- client-identifying parameters from the DHCP interaction (MAC, DUID, etc)
- host reservation information (if there is an associated HR), including DNS name, boot file location, user-context, perhaps any other options on the HR
- IP address assigned and date/time it was last renewed.
- [device type](https://gitlab.isc.org/isc-projects/stork/-/issues/161), such as Android phone, iPhone, Windows laptop, HP Printer, etc (eventually we might want to try populating this information using client [fingerprinting](https://gitlab.isc.org/isc-projects/stork/-/issues/777) from options provided in requests)
- vendor/manufacturer (e.g. Apple, Samsung, HP etc). This could eventually be populated by fingerprinting.
- geographic location (this could be a city/office such as Baltimore, MD, or it could be some other code such as BLDG21-3rdFlr. We should probably permit a wide range of possible end user formats/strings for this.
- any 'user context' data associated with the client. Other than host reservations, is there any other way that user context could be associated with a client? There could be user context associated with the subnet that the client most recently received a lease from, would we want to associate that with the client??
- end user contact information fields, such as fname, lname, userID, email address, phone extension, mobile and administrative affiliation (e.g. department). (this might be in a different linked table, so a user could be associated with multiple devices? Also, that would facilitate importing a table of end user contact data.)
Other features
- it would be very cool if this database of endpoints could be created from lease data, but without removing endpoints when the leases failed to renew
- it would be ideal if the information could be updated when a new lease is assigned, if the endpoint is found in the database with a prior lease. So, for example, the ip address and some option data might be updated, but the rest of the information, much of which would have been administratively entered, would persist on the record
- some organizations might have a table of endpoints that they would want to import, in csv format, for instance. It would also be useful to be able to export this information for import into some other client inventory system
- this should be different from the Lease db in that Kea does not need to maintain it in real time! Nobody would want this if updates were blocking on assigning or renewing leases, or if using it put a big performance strain on Kea. It is fine if updates to this database are not acknowledged to Kea, and Kea definitely should not wait for responses from the endpoint db. Possibly this could use the 3rd lease data stream from HA as an input?
- Some of the above may be features that make more sense as use cases for a network documentation system, such as NetBox. We are not trying to replace the network documentation, but to provide documentation at a more granular level... So we might want to investigate what a NetBox might offer for endpoint tracking first, and possible somehow leverage that ...
- The Stork admin would likely want to customize which fields are used and displayed in the GUI, as many enterprises would not populate all of the fields.
- It might be necessary for the Stork admin to identify *which* endpoint identifier should be used as the unique index field, so that updates are possible.
We haven't discussed the GUI features that might leverage this database, but it does seem to be desirable to permit record deletion, or at least mark them as historical/deprecated/inactive or something. Otherwise this db would grow and grow like an unrotated log file...backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/1031Difficult to monitor BIND with stork-agent2023-06-05T18:17:45ZDarren AnkneyDifficult to monitor BIND with stork-agentStork-agent is not able to make use of the simple rndc.key found in the bind configuration directory. It complains there is no control clause as shown:
```
May 3 14:31:06 dynamic-192-168-20-20 stork-agent[8367]: time="2023-05-03 14:31:...Stork-agent is not able to make use of the simple rndc.key found in the bind configuration directory. It complains there is no control clause as shown:
```
May 3 14:31:06 dynamic-192-168-20-20 stork-agent[8367]: time="2023-05-03 14:31:06" level="info" msg="Found BIND 9 config file in /etc/bind/named.conf based on output of `named -V`." file=" bind9.go:485 "
May 3 14:31:06 dynamic-192-168-20-20 stork-agent[8367]: time="2023-05-03 14:31:06" level="warning" msg="Cannot determine BIND 9 rndc details: cannot determine rndc key" file=" bind9.go:561 "
```
Perhaps this is as intended. However, if you then configure rndc.conf and bind correctly using rndc-confgen, it still does not work as it uses an incorrect format for executing rndc as shown:
```
May 3 14:51:09 dynamic-192-168-20-20 stork-agent[9178]: time="2023-05-03 14:51:09" level="debug" msg="Rndc: [/usr/sbin/rndc -s 127.0.0.1 -p 953 -y hmac-sha256:iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM= status]" file=" bind9.go:125 "
May 3 14:51:09 dynamic-192-168-20-20 stork-agent[9178]: time="2023-05-03 14:51:09" level="error" msg="Failed to forward commands to rndc: exit status 1" file=" agent.go:244 " Address="127.0.0.1" Port="953"
```
The rndc command is being executed like so: `rndc -s 127.0.0.1 -p 953 -y hmac-sha256:iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM= status`
This produces errors if run from the command line as shown:
```
$ rndc -s 127.0.0.1 -p 953 -y hmac-sha256:iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM= status
rndc: no key definition for name hmac-sha256:iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM=
```
Proper syntax is as follows: `rndc -s 127.0.0.1 -p 953 -y rndc-key status`. Relevant configuration shown below:
excerpt of named.conf:
```
key "rndc-key" {
algorithm hmac-sha256;
secret "iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM=";
};
controls {
inet 127.0.0.1 port 953 allow { 127.0.0.1; } keys { "rndc-key"; };
};
```
rndc.conf:
```
# Start of rndc.conf
key "rndc-key" {
algorithm hmac-sha256;
secret "iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM=";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
# End of rndc.conf
```
Alternatively, the rndc.conf file could be specified on the command line: `rndc -c /etc/bind/rndc.conf status` which would allow you to remove the ip and port specification from the command line as it is in the conf file.
A third option, to obviate the need for the administrator to create an rndc.conf file, would be to look for rndc.key if no rndc.conf or controls clause (in named.conf) was found. An rndc.key file can be specified as follows: `rndc -k /etc/bind/rndc.key status`. If a rndc.key file exists in the directory with named.conf (can be generated with `rndc-confgen -a` if it was removed) and no controls clause exists in named.conf, then named will allow connections locally using the key in that key file. Many administrators use rndc this way, so something to consider.
The only way to get bind monitoring working at the moment is to setup rndc.conf this way:
```
#key "rndc-key" {
key "hmac-sha256:iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM=" {
algorithm hmac-sha256;
secret "iCQvHPqq43AvFK/xRHaKrUiq4GPaFyBpvt/GwKSvKwM=";
};
options {
default-key "rndc-key";
default-server 127.0.0.1;
default-port 953;
};
```
which, I assume, means that if the -y is specified on the command line that rndc is ignoring the options section with the defaults defined.
[RT22012](https://support.isc.org/Ticket/Display.html?id=22012)1.11Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/999Display user-context in lease details2023-08-29T19:08:00ZPeter DaviesDisplay user-context in lease detailsStork uses the leaseX-get commands to retrieve lease information from Kea.
"user-context" is returned but not displayed in Stork. "user-context" may contain interesting information such as RAI (option 82) data.
It would be hel...Stork uses the leaseX-get commands to retrieve lease information from Kea.
"user-context" is returned but not displayed in Stork. "user-context" may contain interesting information such as RAI (option 82) data.
It would be helpful if this data was also displayed.
[RT #21662](https://support.isc.org/Ticket/Display.html?id=21862)1.11Razvan BecheriuRazvan Becheriuhttps://gitlab.isc.org/isc-projects/stork/-/issues/933Send statistic-get-all only for running daemons2023-03-07T13:44:37ZPeter DaviesSend statistic-get-all only for running daemonsCurrently, the Stork agent detects Kea by searching for the Kea Control Agent (CA)
process. The CA configuration file could be expected to contain information about
which kea services are running.
Does stork need to send "stat...Currently, the Stork agent detects Kea by searching for the Kea Control Agent (CA)
process. The CA configuration file could be expected to contain information about
which kea services are running.
Does stork need to send "statistic-get-all" for both "dhcp4" and "dhcp6" when
only dhcp4 is configured in the CA config? Asking only for statistics from the
active service would reduce the number of errors messages generated by the CA
From backend/agent/promkeaexporter.go
```
...
// Request to kea dhcp daemons for getting all stats. Both v4 and v6 is queried because
// here we do not have knowledge which are active.
requestData := `{
"command":"statistic-get-all",
"service":["dhcp4", "dhcp6"],
"arguments": {}
}`
...
```
[RT #21508](https://support.isc.org/Ticket/Display.html?id=21508)1.10Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/901Regular expressions2023-02-17T11:29:20ZPeter DaviesRegular expressionsThere may be some utility in allowing the search bar to process regular expression.
I'm not sure how much work this would entail. It has been pointed out that for leases
Kea's leaseX-get-by-* commands do not support this; the leaseX-...There may be some utility in allowing the search bar to process regular expression.
I'm not sure how much work this would entail. It has been pointed out that for leases
Kea's leaseX-get-by-* commands do not support this; the leaseX-get-all could be used.
[ RT #21476 ](https://support.isc.org/Ticket/Display.html?id=21476)backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/884Feature request - Host reservation option to select client-class2022-12-05T11:32:26ZRinse KloekFeature request - Host reservation option to select client-class---
name: Feature request - Host reservation option to select client-class
---
The latest version of Stork gives the option to add a Host Reservaration to select for example an IP address.
However in our setup , we use host reservartio...---
name: Feature request - Host reservation option to select client-class
---
The latest version of Stork gives the option to add a Host Reservaration to select for example an IP address.
However in our setup , we use host reservartion to assign a host to a specific client-class.
At this moment we use the API to insert such host reservartion. However , because of a redundant setup, we have to insert these host reservartion to two (or more) DHCP servers. We are investigation the option to have Stork handle these request
So our request would be if it will be possible to select a client-class with adding a host reservation.1.8Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/817Server creates a false disconnect event on Kea hook conflict2022-10-19T08:44:57ZSlawek FigielServer creates a false disconnect event on Kea hook conflictThe Kea daemon can be configured to use the `host_cmds` hook and RADIUS backend simultaneously. The RADIUS backend doesn't support listing host reservations. It causes the `reservation-get-page` command fails due to an unsupported except...The Kea daemon can be configured to use the `host_cmds` hook and RADIUS backend simultaneously. The RADIUS backend doesn't support listing host reservations. It causes the `reservation-get-page` command fails due to an unsupported exception. Stork's host puller uses this command to update the host reservations data.
```
2022-06-29 07:50:52.273 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'reservation-get-page'
2022-06-29 07:50:52.275 ERROR [kea-dhcp4.callouts/443501.139831042103424] HOOKS_CALLOUT_ERROR error returned by callout on hook 3 registered by library with index $reservation_get_page (callout address 0x7f2cebb0b540) (callout duration 1.420 ms)
```
Stork has multiple pullers working parallel. When any fails, the server produces a disconnect event and displays a warning message.
```json
{
"createdAt": "2022-06-29T14:30:51.561Z",
"id": 51358,
"level": 2,
"text": "Communication with <daemon id=\"2\" name=\"dhcp4\" appId=\"1\" appType=\"kea\"> of <app id=\"1\" name=\"Primary\" type=\"kea\" version=\"1.8.2\"> failed"
},
```
Any subsequent success pulling from any puller (it may be different than a puller that notified connection problems) produces a resumed connection event.
```json
{
"createdAt": "2022-06-29T14:31:11.658Z",
"id": 51360,
"level": 1,
"text": "Communication with <daemon id=\"2\" name=\"dhcp4\" appId=\"1\" appType=\"kea\"> of <app id=\"1\" name=\"Primary\" type=\"kea\" version=\"1.8.2\"> resumed"
},
```
It causes to generate tons of events and false alerts. We should gracefully handle the hook conflict and stop or mute a puller in this situation. Additionally, a config checker should report an unsupported hook combination.1.7Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/792Stork Server Continually Disconnects from Agents2022-10-19T08:44:57Zvps-ericStork Server Continually Disconnects from AgentsI have a Stork server monitoring two Kea servers (no BIND involved). Everything works properly, except that, constantly, the Stork server shows communication interruption events for both servers' Kea daemons:
**https://stork-server/api/...I have a Stork server monitoring two Kea servers (no BIND involved). Everything works properly, except that, constantly, the Stork server shows communication interruption events for both servers' Kea daemons:
**https://stork-server/api/events**:
```
{
"items": [
{
"createdAt": "2022-06-29T14:32:11.782Z",
"id": 51365,
"level": 1,
"text": "Communication with <daemon id=\"4\" name=\"dhcp4\" appId=\"2\" appType=\"kea\"> of <app id=\"2\" name=\"Secondary\" type=\"kea\" version=\"1.8.2\"> resumed"
},
{
"createdAt": "2022-06-29T14:32:11.763Z",
"id": 51364,
"level": 1,
"text": "Communication with <daemon id=\"2\" name=\"dhcp4\" appId=\"1\" appType=\"kea\"> of <app id=\"1\" name=\"Primary\" type=\"kea\" version=\"1.8.2\"> resumed"
},
{
"createdAt": "2022-06-29T14:31:51.615Z",
"id": 51363,
"level": 2,
"text": "Communication with <daemon id=\"4\" name=\"dhcp4\" appId=\"2\" appType=\"kea\"> of <app id=\"2\" name=\"Secondary\" type=\"kea\" version=\"1.8.2\"> failed"
},
{
"createdAt": "2022-06-29T14:31:51.599Z",
"id": 51362,
"level": 2,
"text": "Communication with <daemon id=\"2\" name=\"dhcp4\" appId=\"1\" appType=\"kea\"> of <app id=\"1\" name=\"Primary\" type=\"kea\" version=\"1.8.2\"> failed"
},
{
"createdAt": "2022-06-29T14:31:11.677Z",
"id": 51361,
"level": 1,
"text": "Communication with <daemon id=\"4\" name=\"dhcp4\" appId=\"2\" appType=\"kea\"> of <app id=\"2\" name=\"Secondary\" type=\"kea\" version=\"1.8.2\"> resumed"
},
{
"createdAt": "2022-06-29T14:31:11.658Z",
"id": 51360,
"level": 1,
"text": "Communication with <daemon id=\"2\" name=\"dhcp4\" appId=\"1\" appType=\"kea\"> of <app id=\"1\" name=\"Primary\" type=\"kea\" version=\"1.8.2\"> resumed"
},
{
"createdAt": "2022-06-29T14:30:51.574Z",
"id": 51359,
"level": 2,
"text": "Communication with <daemon id=\"4\" name=\"dhcp4\" appId=\"2\" appType=\"kea\"> of <app id=\"2\" name=\"Secondary\" type=\"kea\" version=\"1.8.2\"> failed"
},
{
"createdAt": "2022-06-29T14:30:51.561Z",
"id": 51358,
"level": 2,
"text": "Communication with <daemon id=\"2\" name=\"dhcp4\" appId=\"1\" appType=\"kea\"> of <app id=\"1\" name=\"Primary\" type=\"kea\" version=\"1.8.2\"> failed"
},
{
"createdAt": "2022-06-29T14:30:11.578Z",
"id": 51357,
"level": 1,
"text": "Communication with <daemon id=\"4\" name=\"dhcp4\" appId=\"2\" appType=\"kea\"> of <app id=\"2\" name=\"Secondary\" type=\"kea\" version=\"1.8.2\"> resumed"
},
{
"createdAt": "2022-06-29T14:30:11.561Z",
"id": 51356,
"level": 1,
"text": "Communication with <daemon id=\"2\" name=\"dhcp4\" appId=\"1\" appType=\"kea\"> of <app id=\"1\" name=\"Primary\" type=\"kea\" version=\"1.8.2\"> resumed"
}
],
"total": 51365
}
```
Notice that there is a predictable delay between the messages. I don't know if this is because Stork polls every 20 seconds or if it's something else.
While the agents are reported as "unreachable," I can still cURL them on port 8080 (I don't get any interesting data, of course, but I can reach it - it doesn't time out). The logs on the server from `journalctl -xeu isc-stork-server` don't show anything useful except the event pasted earlier, along with warnings about `reservation-get-page` being unsupported. On the agent, I see no issues except an occasional "Problem connecting to dhcp daemon: forwarding socket is not configured for the server type dhcp6" - but we don't use DHCP6.
As for the web interface, I see:
![image](/uploads/c023b2beb4274481c7742ee7f69a0da0/image.png)
The Kea logs themselves show the commands, but no errors that I can find:
```
2022-06-29 07:50:50.674 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'version-get'
2022-06-29 07:50:50.675 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'status-get'
2022-06-29 07:50:50.677 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'config-get'
2022-06-29 07:50:52.273 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'reservation-get-page'
2022-06-29 07:50:52.275 ERROR [kea-dhcp4.callouts/443501.139831042103424] HOOKS_CALLOUT_ERROR error returned by callout on hook 3 registered by library with index $reservation_get_page (callout address 0x7f2cebb0b540) (callout duration 1.420 ms)
2022-06-29 07:50:57.627 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'statistic-get-all'
2022-06-29 07:50:57.636 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'subnet4-list'
2022-06-29 07:52:32.466 INFO [kea-dhcp4.commands/443501.139831042103424] COMMAND_RECEIVED Received command 'stat-lease4-get'
2022-06-29 07:52:32.467 INFO [kea-dhcp4.stat-cmds-hooks/443501.139831042103424] STAT_CMDS_LEASE4_GET stat-lease4-get command successful, parameters: [all subnets] rows found: 2
...
```
All servers are on the same subnet. The Stork agents are listening and responding on port 8080, bound to their LAN IPv4 address. Port 8080 is open on their firewalls and I can cURL it from the Stork server.
Clients:
Version: isc-stork-agent-1.4.0.220531122317-1.x86_64
OS: RHEL 8.5
Server:
Installation type: https://stork.readthedocs.io/en/v1.4.0/install.html#installing-on-centos-rhel-fedora
Version: isc-stork-server-1.4.0.220531122323-1.x86_64
OS: AlmaLinux 9.0
How can this issue be uncovered?1.8https://gitlab.isc.org/isc-projects/stork/-/issues/764Feature Request: Add version control and version history (and maybe some limi...2023-01-31T10:05:50ZCathy AlmondFeature Request: Add version control and version history (and maybe some limited roll back?) capability to Kea configuration/CB[Per Support Ticket #17332](https://support.isc.org/Ticket/Display.html?id=17332)
I think it's highly probable this is something that would need to be integrated with Stork and/or something completely independent (git-based?) for config...[Per Support Ticket #17332](https://support.isc.org/Ticket/Display.html?id=17332)
I think it's highly probable this is something that would need to be integrated with Stork and/or something completely independent (git-based?) for configuration change management.
Recording it here as a placeholder feature request anywaybackloghttps://gitlab.isc.org/isc-projects/stork/-/issues/763Add optional validation of overlapping pools in Kea configuration (v4 and v6)2022-08-22T11:39:14ZCathy AlmondAdd optional validation of overlapping pools in Kea configuration (v4 and v6)Bad things happen if you accidentally configure overlapping lease pools, but currently Kea does not do any checks of the configuration to prevent this from happening.
The reason it doesn't is that for large and complex configurations, t...Bad things happen if you accidentally configure overlapping lease pools, but currently Kea does not do any checks of the configuration to prevent this from happening.
The reason it doesn't is that for large and complex configurations, the performance cost will outweigh the potential benefit for many administrators. Those environments already have change control processes with sanity checks that prevent this type of accident.
But some smaller sites - especially those that are seldom updates, so the DHCP admins are generalists rather than specialists, might appreciate something like this.
This request also applies to PD pools, where it was discovered (in ticket [Ticket #17393](https://support.isc.org/Ticket/Display.html?id=17393), albeit accidentally, that configuring overlapping PD pools might actually work without problems - although we don't recommend this because not all potential scenarios have been tested (plus the stats will be quite peculiar).1.6Slawek FigielSlawek Figiel