stork issueshttps://gitlab.isc.org/isc-projects/stork/-/issues2024-02-26T14:50:32Zhttps://gitlab.isc.org/isc-projects/stork/-/issues/818HA state unavailable, though working2024-02-26T14:50:32ZNicolas EHA state unavailable, though working---
Stork 1.4.0 is showing both Kea 2.1.7 dhcp4 servers in HA+MT with state unavailable.
Actually, there are both working fine, as Stork server is.
**To Reproduce**
Steps to reproduce the behaviour:
1. Run Kea 2.1.7 in High-availability...---
Stork 1.4.0 is showing both Kea 2.1.7 dhcp4 servers in HA+MT with state unavailable.
Actually, there are both working fine, as Stork server is.
**To Reproduce**
Steps to reproduce the behaviour:
1. Run Kea 2.1.7 in High-availability hot-standby + Multi Threading on two machines, Stork server running on machine 1
2. Restart both machine (to be sure to be sure)
3. Witness that after every daemon has started, and the logs are showing a correct HA state (machine 1 = primary and OK, machine 2 in hot-standby)
4. Make some tests (stop one dhcp4 service, validate that clients still get served, restart, witness a correct chat between both nodes)
5. During all this, the stork web GUI dashboard (very first page after login) is showing : "HA state unavailable"
When clicking on the "unavailable" clickable link, it leads me to a page where everything is green, OK, correct, valid as it can be.
**Expected behaviour**
The dashboard show report a situation as happy as the reality is when looking at the details pages, or in the logs, or in the currently running services.
**Environment:**
- Kea version: 2.1.7
- Stork agent + server : 1.4.0
- OS: Debian 11 bullseye
**Contacting you**
admin@sitpi.fr1.7Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/737Demo: Server starts earlier then the database2022-05-17T13:32:45ZSlawek FigielDemo: Server starts earlier then the databaseThe issue was found during 1.3 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/732#note_285141)
I've been testing on 733aaea2cf70106719d8065de41eeacaec66c126 (master as of today). I like the new build system a...The issue was found during 1.3 sanity checks. [Source](https://gitlab.isc.org/isc-projects/stork/-/issues/732#note_285141)
I've been testing on 733aaea2cf70106719d8065de41eeacaec66c126 (master as of today). I like the new build system a lot. The elapsed build time is super useful, as is the general cleaning of the `rake` tasks. I had some problems: Something that looked like a race condition (`server_1 | FATA[2022-05-09 14:56:57] main.go:45 cannot start the Stork Server: FATAL #57P03 the database system is starting up`), but after the second attempt it worked well.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/678Upgrade go-pg to version 102022-02-04T08:46:22ZMarcin SiodelskiUpgrade go-pg to version 10The currently used go-pg version is already pretty old. It would be good to migrate to the new version v10: https://github.com/go-pg/pg/blob/v10/CHANGELOG.md. One of the useful features is "Added pg.DBI which is a DB interface implemente...The currently used go-pg version is already pretty old. It would be good to migrate to the new version v10: https://github.com/go-pg/pg/blob/v10/CHANGELOG.md. One of the useful features is "Added pg.DBI which is a DB interface implemented by pg.DB and pg.Tx".1.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/573Change sslmode based on server.env2021-11-09T14:22:02ZbradleymccandlessChange sslmode based on server.envDatabase connections are hardcoded with sslmode='disable'. We should add a variable in server.env that can change this value.Database connections are hardcoded with sslmode='disable'. We should add a variable in server.env that can change this value.1.0https://gitlab.isc.org/isc-projects/stork/-/issues/571get events failing (0.19)2021-09-03T10:49:59ZTomek Mrugalskiget events failing (0.19)This is a follow-up to the sanity check issue discovered (see [here](https://gitlab.isc.org/isc-projects/stork/-/issues/569#note_229567) ).
Steps to reproduce:
1. Install 0.19 RPMs for server and agent
2. start server on port 8080: `sys...This is a follow-up to the sanity check issue discovered (see [here](https://gitlab.isc.org/isc-projects/stork/-/issues/569#note_229567) ).
Steps to reproduce:
1. Install 0.19 RPMs for server and agent
2. start server on port 8080: `systemctl start isc-stork-server`
3. run agent: `stork-agent --server-url http://192.168.56.101:8000/ --host 192.168.56.101 --port 8080`
4. go to UI, click unauthorized, authorize the new machine
5. nagivate to Services>Machines, click on the machine.
![cannot-get-events](/uploads/84b80aa2dd7b15c641305a733ef7803a/cannot-get-events.png)
When looking at the firefox console, I got this:
![500-error](/uploads/377dee8e5625f70ba1efaaa94383fb1f/500-error.png)
The response says: `{"message":"problem with fetching events from the database"}`.
The server log prints lots of data, but this one seems relevant: ```#033[31mERRO#033[0m[2021-08-11 12:22:19] events.go:63 problem with getting events: ERROR #42846 cannot cast type jsonb to integer```
Full logs attached:
[centos8-stork.log](/uploads/c4397c406587f463f731199ca01baf12/centos8-stork.log)0.20Slawek FigielSlawek Figielhttps://gitlab.isc.org/isc-projects/stork/-/issues/546migrate to bun ie. pg-go rewrite2022-02-04T08:46:21ZMichal Nowikowskimigrate to bun ie. pg-go rewritehttps://bun.uptrace.dev/guide/pg-migration.html#new-featureshttps://bun.uptrace.dev/guide/pg-migration.html#new-featuresoutstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/515Ability to export certificates from Stork2021-05-31T07:04:11ZTomek MrugalskiAbility to export certificates from StorkStork stores its certificates in a database. @tomek feels (and @fdupont agrees) that there needs to be an ability to import and export certificates. Here are couple usecases:
1. there is a problem with TLS and it needs to be investigate...Stork stores its certificates in a database. @tomek feels (and @fdupont agrees) that there needs to be an ability to import and export certificates. Here are couple usecases:
1. there is a problem with TLS and it needs to be investigated. The standard practice is to inspect the certificates using openssl.
2. admin wants to inspect the traffic and decode the traffic, e.g. wireshark allows such ability, but it of course requires providing the necessary secrets.
3. an audit wants to inspect certificates and perform some form of automated checks
A more advanced case would be this:
4. a deployment with high security requirements would want to generate its own certs and keys and provision them to Stork. This by definition would be a manual process
Since the last item requires import capabilities, it is currently out of scope for this ticket. But it would very useful and also the next logical step after we get the export capability.0.18Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/488Perf: dedicated call to count authorized/unauthorized machines2022-11-16T11:55:06ZTomek MrugalskiPerf: dedicated call to count authorized/unauthorized machinesThe implementation introduced in !267 to get a list of unauthorized machines is pretty inefficient. It retrieves all the machines with all the configurations just to count them. We should optimize it. One way would be to have a dedicated...The implementation introduced in !267 to get a list of unauthorized machines is pretty inefficient. It retrieves all the machines with all the configurations just to count them. We should optimize it. One way would be to have a dedicated query for simply returning the number of machines.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/484Committing Kea app to the database may hang2021-03-02T16:08:17ZMarcin SiodelskiCommitting Kea app to the database may hangWhen I was testing #483, I came across an issue described in the following comment: https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_195348.
In order to reproduce, follow these steps:
- Start Stork server,
- Make sure...When I was testing #483, I came across an issue described in the following comment: https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_195348.
In order to reproduce, follow these steps:
- Start Stork server,
- Make sure that no Kea app runs on the machine with an agent,
- Launch agent registration procedure,
- Approve agent registration in the UI,
- Start Kea app on the monitored machine and allow some time for the agent to discover the Kea app,
- Navigate to the machine page and click "Get Latest State"
The request to get state should hang (not return status 200) and the app should be neither visible in the UI nor in the database. The database transaction committing the app to the database should hang.
As I explained in the following comment: https://gitlab.isc.org/isc-projects/stork/-/merge_requests/267#note_195373, the issue appears to be related to committing events to the database outside of an open transaction. We may consider committing the events within the transaction, but we should investigate why exactly it hangs to avoid this issue in the future.https://gitlab.isc.org/isc-projects/stork/-/issues/403Support for DB connection encryption2021-11-09T13:33:40ZTomek MrugalskiSupport for DB connection encryptionOne of the issues pointed out in [security audit 1](https://gitlab.isc.org/isc-private/stork/-/wikis/SecurityAudit1) was that the Postgres connection is not encrypted. It doesn't have to be always encrypted, but we need to implement a wa...One of the issues pointed out in [security audit 1](https://gitlab.isc.org/isc-private/stork/-/wikis/SecurityAudit1) was that the Postgres connection is not encrypted. It doesn't have to be always encrypted, but we need to implement a way to use TLS for more security conscious users.1.0Marcin SiodelskiMarcin Siodelskihttps://gitlab.isc.org/isc-projects/stork/-/issues/367migration tool up to version X doesn't work, doesn't report its own version (-h)2021-04-09T10:44:12ZTomek Mrugalskimigration tool up to version X doesn't work, doesn't report its own version (-h)Two problems with the migration tool:
- the migration to specific version doesn't work, `stork-db-migrate up 20` always migrates to latest version.
- Every software should be able to return its own version using -v or --version.Two problems with the migration tool:
- the migration to specific version doesn't work, `stork-db-migrate up 20` always migrates to latest version.
- Every software should be able to return its own version using -v or --version.outstandinghttps://gitlab.isc.org/isc-projects/stork/-/issues/366Debug/verbose mode to db migration2021-03-05T13:12:51ZTomek MrugalskiDebug/verbose mode to db migrationOur DB schema is not documented anywhere and it's stored in .go files. There was one incident when migration failed and it was difficult to debug what exactly was going on. We need a `--debug` or `--verbose` flag that would print each DB...Our DB schema is not documented anywhere and it's stored in .go files. There was one incident when migration failed and it was difficult to debug what exactly was going on. We need a `--debug` or `--verbose` flag that would print each DB migration schema before it's actually applied.0.12Tomek MrugalskiTomek Mrugalskihttps://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/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/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/328Spelling errors in the database2023-07-27T12:21:13ZMarcin SiodelskiSpelling errors in the databaseWee have spelling errors in the database in the per subnet statistics. It should be `assigned-addresses`, but it is `assigned-addreses` (with single s). This error is repeated for total addresses and declined addresses too.Wee have spelling errors in the database in the per subnet statistics. It should be `assigned-addresses`, but it is `assigned-addreses` (with single s). This error is repeated for total addresses and declined addresses too.backloghttps://gitlab.isc.org/isc-projects/stork/-/issues/268Detect incompatible Postgresql version2021-09-07T15:31:04ZThomas MarkwalderDetect incompatible Postgresql versionDuring initial environment setup I inadvertently pointed Stork to Postgresql 9.5. This apparently caused a SQL syntax error in the migrations code. IIRC it had something to with "AS", syntax error at or near "AS". I did not save the ...During initial environment setup I inadvertently pointed Stork to Postgresql 9.5. This apparently caused a SQL syntax error in the migrations code. IIRC it had something to with "AS", syntax error at or near "AS". I did not save the exact message. Upon pointing Stork to Postgresql 11 everything was fine.
It should be possible to detect the Postgresql version in the init db or migration logic and bail if it is too old. Barring that we might consider a more helpful failure message if possible.https://gitlab.isc.org/isc-projects/stork/-/issues/233Create data model for daemons2020-04-22T11:57:33ZMarcin SiodelskiCreate data model for daemonsOur UI seems to become "daemon centric". The lists we're aiming to present in the dashboard contain daemons and their statuses rather than apps and their statuses. When clicking on the given app the user is taken to the view where we hav...Our UI seems to become "daemon centric". The lists we're aiming to present in the dashboard contain daemons and their statuses rather than apps and their statuses. When clicking on the given app the user is taken to the view where we have multiple tabs, each one for each daemon. Configurations are per daemon, rather than per app and so forth.
This all implies that daemons already deserve their own SQL table(s) so as the daemon specific information (e.g. LPS stats) can be associated with them. In fact, the HA status is also presented per daemons. This ticket should introduce the new tables and fill them in with the daemon specific information upon adding a new app or refreshing an existing app. It should also handle deletion of the app. The service tables should be adopted to provide the relations to the daemon table(s) rather than app tables.0.7Michal NowikowskiMichal Nowikowskihttps://gitlab.isc.org/isc-projects/stork/-/issues/228Database model for Kea High Availability2020-04-15T15:01:47ZMarcin SiodelskiDatabase model for Kea High AvailabilityAs of Kea 0.6.0, the HA status is fetched directly from the monitored Kea servers and displayed in the UI. We'd like to move to a different model in which the Stork server is fetching the HA status from the servers and stores them in the...As of Kea 0.6.0, the HA status is fetched directly from the monitored Kea servers and displayed in the UI. We'd like to move to a different model in which the Stork server is fetching the HA status from the servers and stores them in the database. The UI can then fetch this information from the db along with some additional information not present in the response to the `status-get` command. Such information may include things like last failover event seen from the Stork server's perspective or anything else that the server is able to gather from the Kea servers over a period of time.
This ticket extends the Stork database to accommodate the HA specific information.0.7Michal NowikowskiMichal Nowikowski