94 lines
5.4 KiB
Plaintext
94 lines
5.4 KiB
Plaintext
{"login": "manager","password": "l3tm3in"}
|
|
|
|
|
|
|
|
|
|
todo: MAYBE a datetime kind of parameter is interpreted as LOCAL by the server on a route
|
|
so what the fuck
|
|
sent from client http://localhost:7575/api/v8.0/server-metric?maxRecords=400&tsStart=2020-05-27T13:07:39.068Z&tsEnd=2020-05-27T19:07:40.068Z
|
|
At server route: tsStart: {2020-05-27 6:07:39 AM} tsEnd: {2020-05-27 12:07:40 PM} Kind=local for both
|
|
so actually that's all good so far, how about the query itself?
|
|
|
|
2020-05-27 12:13:38.6439|DEBUG|Microsoft.EntityFrameworkCore.Database.Command|Executing DbCommand [Parameters=[@__tsStart_0='2020-05-27T06:13:32' (DbType = DateTime), @__tsEnd_1='2020-05-27T12:13:33' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
|
|
FROM ametricmm AS a
|
|
WHERE (a.t >= @__tsStart_0) AND (a.t <= @__tsEnd_1)
|
|
ORDER BY a.t DESC
|
|
2020-05-27 12:13:38.8848|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (241ms) [Parameters=[@__tsStart_0='2020-05-27T06:13:32' (DbType = DateTime), @__tsEnd_1='2020-05-27T12:13:33' (DbType = DateTime)], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
|
|
FROM ametricmm AS a
|
|
WHERE (a.t >= @__tsStart_0) AND (a.t <= @__tsEnd_1)
|
|
ORDER BY a.t DESC
|
|
|
|
Well, shit. The query is sending local time to the db server, so any query that sends to teh server needs teh values converted to utc first
|
|
This is malarky pure and simple!
|
|
:)
|
|
|
|
If change parameters to DateTimeOffset from DateTime and rerun exact steps as above:
|
|
2020-05-27 12:21:49.8196|INFO|Microsoft.EntityFrameworkCore.Database.Command|Executed DbCommand (21ms) [Parameters=[@__tsStart_0='2020-05-27T13:21:48.4840000+00:00', @__tsEnd_1='2020-05-27T19:21:49.4840000+00:00'], CommandType='Text', CommandTimeout='30']
|
|
SELECT a.t, a.allocated, a.cpu, a.gen0, a.gen1, a.gen2, a.privatebytes, a.workingset
|
|
FROM ametricmm AS a
|
|
WHERE (CAST(a.t AS timestamp with time zone) >= @__tsStart_0) AND (CAST(a.t AS timestamp with time zone) <= @__tsEnd_1)
|
|
ORDER BY a.t
|
|
|
|
* Now it properly is sending the value to the db in UTC as it stays IN utc from input to query
|
|
One thing though is it's casting the query to a timestamp with timezone which is weird but maybe because the column is defined as timestamp witout timezone
|
|
|
|
going to try
|
|
changing the model to datetimeoffset
|
|
change database schema for mmetric to with timezone
|
|
no, actually for me it's better without because it will never try to interpret or change it, it will just return and accept it as is and
|
|
that's what I want if I'm only dealing in UTC
|
|
rerun again and see if it's casting still
|
|
|
|
|
|
|
|
todo: leave running check it does overnight backup properly
|
|
|
|
todo: add backup turn off setting
|
|
environment variable
|
|
todo: add backup master time out setting
|
|
environment variable
|
|
|
|
TODO: BIG UPDATE ALL GUTS
|
|
|
|
|
|
todo: notification?
|
|
|
|
todo: OPS notification created for failed jobs
|
|
also maybe direct immediate email bypassing generator?
|
|
Add backup fail to this will stub out for now
|
|
|
|
todo: (BREAK THIS OUT INTO LATER/NOW/CASES) there are several outstanding AUTHENTICATION related cases in rockfish for RAVEN
|
|
e.g. https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1924
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1835
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1998 <---this is an important case for consideration
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3367 <--time limited accounts for support or temporary access?
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/2059 <--- time restricted accounts so user can only login during business hours (still to be considered)
|
|
2fa stuff, some logging and lockout stuff
|
|
Go through the auth related cases and notes in client side and implement or close
|
|
todo: 2fa? (if not in first release, is there something needed to support it in future dbwise?)
|
|
todo: Auth Backdoor reset password feature
|
|
how to code it here, pretty easy to do:
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3250
|
|
todo: Look into 2fa
|
|
https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/3395
|
|
todo: look into how to use an SSL certificate with the RAVEN server directly when not behind nginx
|
|
https://docs.microsoft.com/en-us/aspnet/core/fundamentals/servers/kestrel?view=aspnetcore-3.1
|
|
- this should be supported by default out of the box working with Let's encrypt ideally
|
|
- is it now considered ok to host .net core web api directly internet facing?
|
|
todo: onboarding and default manager account password
|
|
- Need to come up with a safety plan for this so people don't leave it at default
|
|
- Maybe the very first thing required of a user is to change the password before any tasks can be performed
|
|
- Server stays in safety lock until they set a password?
|
|
- Or maybe a random password is generated on seeding and somehow provided to user through console or something?
|
|
- Maybe an empty db if no other users can be set password only so no one has made a hidden backdoor user account before ops changes it?
|
|
- maybe tied to license if licensed so they bring some info they have from rockfish / their license purchase or something?
|
|
- don't want it to be onerous too much and have some very inexperienced users so...
|
|
- see what other programs do, like our forum software
|
|
todo: API docs, make separate page for datalists and remove from api-response-format.md doc but put a reference link to it there.
|
|
|
|
DEPLOY AND TEST
|
|
|
|
todo: Test backup on Linux
|
|
- going to need to run in vm I think maybe |