stork issueshttps://gitlab.isc.org/isc-projects/stork/-/issues2021-03-24T10:43:24Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/176prepare DHCPv6 dashboard for Grafana2021-03-24T10:43:24ZMichal Nowikowskiprepare DHCPv6 dashboard for GrafanaA dashboard template should be prepared for Grafana.A dashboard template should be prepared for Grafana.0.16Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/347basic HTTP authentication support2021-11-04T13:48:00ZFrancis Dupontbasic HTTP authentication supportHTTP authentication is done with 3 things:
- a header clients are required to add
- a specific Unauthorized HTTP error (same as other HTTP standard errors so nothing really new)
- a header added in error response (supposed to only hel...HTTP authentication is done with 3 things:
- a header clients are required to add
- a specific Unauthorized HTTP error (same as other HTTP standard errors so nothing really new)
- a header added in error response (supposed to only help client for basic authentication).
On the client side it is the basic authentication is really basic:
- you have a user id which is a string with no embedded colon (character ':') in it. It is not required by the standard but it makes sense too to require the string to not be empty.
- a password which can be any string
- a secret with user:password (concat user, ':' and password) is built
- this secret is encoded into UTF-8. This allows to use 8 bits per byte...
- the UTF-8 secret is encoded in base64 (noted base64 below)
- the header is between quotes "Authorization: Basic base64\r\n"
So with the server address and port (or URL) you have to optionally specify user id and password. In curl the argument -u or --user takes user:password. Note that the old idea to put the user id and password in the URL is now strongly not recommended.
You can check if there is a colon in the user id as some other tools do it.
if the user id is not empty you generate the header and add it.
You should check too that HTTP errors are correctly handled (Kea code is in 1304 ticket). Note it is 401 (not 1) and the JSON content is a map (not a list even from the control agent).
**UPDATE**: Let's scope it to being able to use Kea's basic http authentication. This is something that was requested by a customer that's testing kea 1.9.0 with basic auth. For details, see https://gitlab.isc.org/isc-projects/kea/-/issues/13040.22Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/354DB migration tool must allow migration to specific schema versions2021-03-05T13:12:48ZTomek MrugalskiDB migration tool must allow migration to specific schema versionsSee background for this request: [support#16817](https://support.isc.org/Ticket/Display.html?id=16817).
There's a need to be able to migrate to specific version. In some environments (with FIPS enabled), some migrations may have to be d...See background for this request: [support#16817](https://support.isc.org/Ticket/Display.html?id=16817).
There's a need to be able to migrate to specific version. In some environments (with FIPS enabled), some migrations may have to be done manually. This is not ideal, but it's useful for troubleshooting/workaround purposes.
There should be a command, like `migrate 12`.1.0-backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/355Add server option to skip DB migration on startup2021-04-09T10:46:37ZTomek MrugalskiAdd server option to skip DB migration on startupBy default, the server always runs migrations on startup. This is convenient, as users don't need to remember about it and migrations are done automatically. However, on some systems where migration is causing problems, there should be a...By default, the server always runs migrations on startup. This is convenient, as users don't need to remember about it and migrations are done automatically. However, on some systems where migration is causing problems, there should be a way to skip migration.
When migration is disabled, the server should simply check if the schema version is as expected. If it's not, refuse to start. Alternatively, it could print a critical warning and try to run, but if the DB is not up to date, there would be problems that's impossible to predict.
Background for this request [support#16817](https://support.isc.org/Ticket/Display.html?id=16817).outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/356Make sure Stork runs on RHEL7 with FIPS enabled2020-08-11T07:58:05ZTomek MrugalskiMake sure Stork runs on RHEL7 with FIPS enabledThere's a report that Stork migration fails on RHEL7 with FIPS enabled.
For details, see [support#16817](https://support.isc.org/Ticket/Display.html?id=16817).
On a related note, we should migrate away from poor security algorithms lik...There's a report that Stork migration fails on RHEL7 with FIPS enabled.
For details, see [support#16817](https://support.isc.org/Ticket/Display.html?id=16817).
On a related note, we should migrate away from poor security algorithms like MD5 and use something modern.0.10Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/376Subnet ID no populating from DHCP4 Config file2023-01-18T14:20:04ZEric GibbeschSubnet ID no populating from DHCP4 Config file---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/...---
name: Bug report
about: Create a report to help us improve
---
If you believe your bug report is a security issue (e.g. a packet that can kill the server), DO NOT
REPORT IT HERE. Please use https://www.isc.org/community/report-bug/ instead or send mail to
security-office(at)isc(dot)org.
**Describe the bug**
A clear and concise description of what the bug is.
**To Reproduce**
Steps to reproduce the behavior:
1. Install Kea 1.6.3 and Stork 0.10.0
2. I do the following: I add 2 Machines to Stork
3. A device in my network does the following: I add a machine to Stork that is running DHCP4
4. Stork server does the following: The stork server is assigning a generic Subnet ID instead of the given one to the subnets used by the machine that was added. IE ( the Subnet ID in the config is 3000, the Subnet ID in stork show 10)
**Expected behavior**
A clear and concise description of what you expected to happen:
The Stork is supposed to report/do A, but didn't or did B instead.
**Environment:**
- Kea version: which release?1.6.3
tarball
linked with:
log4cplus 1.1.3
OpenSSL 1.0.2k-fips 26 Jan 2017
database:
MySQL backend 8.2, library 5.5.64-MariaDB
PostgreSQL backend 5.1, library 90224
Memfile backend 2.1
- Stork: 0.10.0
- OS: CentOS 7
- Kea: HA
- Kea: HA
**Is your feature request related to a problem? Please describe.**
We use the subnet ID to easily identify the VLAN (same as Subnet ID) to see which VLAN we can use for our ISP customers.
**Describe the solution you'd like**
The Correct Subnet ID would appear beside the Subnet
**Describe alternatives you've considered**
**Additional context**
**Contacting you**
Email is best1.9Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/398Stork cannot connect large Kea installation2023-06-12T17:00:19ZPeter DaviesStork cannot connect large Kea installation---
name: Stork cannot connect large Kea installation
about: Stork 0.10 is unable to connect to agent when there a large number of subnets defined in Kea (1.8).
---
KEA 1.8.0 today and installed Stork 0.10, I noticed that Stork server c...---
name: Stork cannot connect large Kea installation
about: Stork 0.10 is unable to connect to agent when there a large number of subnets defined in Kea (1.8).
---
KEA 1.8.0 today and installed Stork 0.10, I noticed that Stork server can't connect to my large instances (with ~4500 subnets) and I see the following errors logged in Events tab:
grpc manager is unable to re-establish connection with the agent 192.168.1.5:8080: rpc error: code = ResourceExhausted desc = grpc: received message larger than max (4607854 vs. 4194304)
RT [#17072](https://support.isc.org/Ticket/Modify.html?id=17072)
## Comments:
According to the gRPC doc there are two functions
to set maximum sizes:
- MaxCallRecvMsgSize
- MaxCallSendMsgSize
The default seems to be 4MB (confirmed by the error message).
Another idea is to use compression: JSON should
be very easy to compress efficiently...0.13Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/755Overlapping Subnet Warning2022-08-23T10:32:25ZPeter DaviesOverlapping Subnet WarningOverlapping Subnet Warning:
It is at present not considered an error to configure a subnet that has an address space that either partially or completely overlaps the address space of existing subnet.
It may however be of interest to ...Overlapping Subnet Warning:
It is at present not considered an error to configure a subnet that has an address space that either partially or completely overlaps the address space of existing subnet.
It may however be of interest to administrators that this sort of configuration exists.
Would it be possible to allow Kea to log a warning message when it discovers this type of situation?
refers to RT [#17206](https://support.isc.org/Ticket/Display.html?id=17206)1.6https://gitlab.isc.org/isc-projects/stork/-/issues/458Replace 'appID' with server name or IP2021-03-01T20:15:48ZVicky Riskvicky@isc.orgReplace 'appID' with server name or IPthe appID is not useful to the humans (I realize it is useful to Stork). the human will be thinking of the Application by hostname or IP address. We need some naming scheme that is also implemented on the Kea server, so the same name can...the appID is not useful to the humans (I realize it is useful to Stork). the human will be thinking of the Application by hostname or IP address. We need some naming scheme that is also implemented on the Kea server, so the same name can be observed on Kea either directly or via Stork. One possibility is to have Stork get some sort of dhcp server 'name' from the Kea server. this could be a dns name but doesn't have to be.
Both users we tested with so far remarked that they didn't know what appID was or how to use it, and they were both searching for some key to associate a Kea server across multiple panels.0.15Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/461Config Review component needed: step 1(design)2021-11-17T11:18:42ZTomek MrugalskiConfig Review component needed: step 1(design)While working on #433 (Stork not able to show stats if stat_cmds hook is not loaded), I realized that there will be many cases like this. Instead of adding specific check for this particular case, I think we need a new component that wil...While working on #433 (Stork not able to show stats if stat_cmds hook is not loaded), I realized that there will be many cases like this. Instead of adding specific check for this particular case, I think we need a new component that will do the Kea config inspection.
For the time being, the checks will be simple:
- if the stat_cmds hook is not loaded, show a note about missing statistics
The code should be written in a way that will be easily extensible with other checks in the future. If possible each entry should be shown as a separate line (maybe an itemized list?). In the far future, we'll probably extend this with a "fix" button that would improve the underlying condition.
Those are not necessarily warnings, more like notes. In many cases it's impossible to tell if certain aspect is a problem or not (e.g. the deployment may not use DB for storing reservations, so they don't care about host cmds). This shouldn't be alarmist.
Here's a bunch of potential things we may check here. Those are out of scope for this ticket. I'm putting them to give you a better perspective how to address the extensibility requirement:
- if the host_cmds hook is not loaded, show a note about being unable to monitor reservations in DB (not included in initial implementation)
- if there is only one subnet in a shared network, suggest disabling shared network;
- if there is in-pool reservation enabled, but there are no in-pool reservations, suggest out-of-pool as better performant;
- if there is custom option definition, but no option-data that uses it, suggest removing unused defintions;
- if there are subnets without any pools and no reservations, suggest removing unused subnets;
- inspect HA configs of both servers and make sure there are no discrepancies;
- it's possible to misconfigure ports in HA+MT configuration, so it's still connecting via CA rather than with DHCP directly.
The follow-up ticket with many more checkers expected is #611.0.22Marcin SiodelskiMarcin Siodelskihttps://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 Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/469DHCPv6 dashboard for Grafana2021-03-12T18:08:46ZTomek MrugalskiDHCPv6 dashboard for GrafanaA customer is interested in DHCPv6 dashboard. He came up with one on his own.A customer is interested in DHCPv6 dashboard. He came up with one on his own.0.16Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/470Tooltips for Grafana links2021-03-02T07:56:31ZTomek MrugalskiTooltips for Grafana linksA customer reported that the Grafana links in Stork dashboard. It was confusing what it is about. He suggested to have a tooltip that explains what the icon/link does.A customer reported that the Grafana links in Stork dashboard. It was confusing what it is about. He suggested to have a tooltip that explains what the icon/link does.0.15Tomek MrugalskiTomek Mrugalskihttps://gitlab.isc.org/isc-projects/stork/-/issues/561Cleartext passwords displayed in Stork2021-09-02T13:35:12ZEverett FultonCleartext passwords displayed in StorkRef: https://support.isc.org/Ticket/Display.html?id=18581
A customer has noted that Stork is displaying passwords obtained from Kea via 'config-get'. Stork should hide these passwords for non-super-admins, and require some action to d...Ref: https://support.isc.org/Ticket/Display.html?id=18581
A customer has noted that Stork is displaying passwords obtained from Kea via 'config-get'. Stork should hide these passwords for non-super-admins, and require some action to display for super-admins.0.20Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/614Kea stats for prometheus2022-02-28T10:56:12ZPeter DaviesKea stats for prometheusKea stats for prometheus:
In Kea installations with a very large number of subnets and where the user is only interested in employing the stork agent to collect global statistics to export to prometheus.
To limit the load on the Ke...Kea stats for prometheus:
In Kea installations with a very large number of subnets and where the user is only interested in employing the stork agent to collect global statistics to export to prometheus.
To limit the load on the Kea server it could be useful if one could configure stork to collect only the global statistics and not the subnet lists.
Perhaps via a configurable setting such as: “STORK_AGENT_PROMETHEUS_KEA_EXPORTER_STATS_ONLY”
[RT #18748](https://support.isc.org/Ticket/Display.html?id=18748)1.2Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/638LDAP support2023-10-05T11:36:45ZPeter DaviesLDAP supportIs is a request for LDAP/Active Directory support in Stork
The goal is to be able to use LDAP for authenticating Stork users for now. However, in the future the scope of LDAP support will likely be expanded to cover other functionalitie...Is is a request for LDAP/Active Directory support in Stork
The goal is to be able to use LDAP for authenticating Stork users for now. However, in the future the scope of LDAP support will likely be expanded to cover other functionalities.
[RT #19920](https://support.isc.org/Ticket/Display.html?id=19920)1.13Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/639Convert flex-id to text2022-01-13T14:24:32ZPeter DaviesConvert flex-id to textConvert flex-id to text:
This is a request to have the Kea "flex-id" value shown in plain text instead of a row of hexidecimal valuesConvert flex-id to text:
This is a request to have the Kea "flex-id" value shown in plain text instead of a row of hexidecimal values1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/676[ISC-support #19985] Fix database migration in Stork 1.0.02023-01-03T13:11:06ZMarcin Siodelski[ISC-support #19985] Fix database migration in Stork 1.0.0The database migration 37, among other things, does this:
```sql
...
DELETE FROM host;
...
-- Add a missing foreign key to host table.
ALTER TABLE local_host
ADD CONSTRAINT local_host_to_host_id FOREIGN KEY (host_id)
REFEREN...The database migration 37, among other things, does this:
```sql
...
DELETE FROM host;
...
-- Add a missing foreign key to host table.
ALTER TABLE local_host
ADD CONSTRAINT local_host_to_host_id FOREIGN KEY (host_id)
REFERENCES host (id) MATCH SIMPLE
ON UPDATE CASCADE
ON DELETE CASCADE;
```
The first statement relies on the presence of the foreign key which is added later. This causes constraint violation issues when people migrate databases that include host reservations. The order of these operations must be swapped.
Current workaround for this issue is to manually run:
```sql
DELETE FROM local_host;
```
using psql.1.1Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/713Agent non-detect message2022-05-20T12:32:46ZPeter DaviesAgent non-detect messagenon-detect message:
The Stork agent will generate a message when an application is detected.
I will however not generate a message if it fails to detect an application after a resonable about of time.
The addition of such a mess...non-detect message:
The Stork agent will generate a message when an application is detected.
I will however not generate a message if it fails to detect an application after a resonable about of time.
The addition of such a message may be of use to users troubleshooting there Stork environment.
[RT #18748](https://support.isc.org/Ticket/Display.html?id=18748)1.4Slawek 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.8