| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This handles changes in:
- The host of the DB.
- New json config file.
|
|
|
|
|
| |
This schema is now adapted to work on this repository instead of the
"OpenGnsys" general repository.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This field needs to be at least 31 bits long to store all days in a month.
Other fields are also set to 32 bits because unsigned int length can change
depending on the system.
We also need to support the three ways that the ogAdmAgent and the WebConsole
have to create an schedule. At first, we only supported the easiest
method:
* Hour, day, month and year -> 10:00, 28, february, 2020
This commit adds these two ways to create an schedule:
* Hour, week day, month and year -> 10:00, Monday, february,
2020
* Hour, week, month and year -> 10:00, first week, february,
2020
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new command to the REST API to run tasks.
A task (tarea) is composed of procedures (procedimientos), each procedure is
composed of commands (acciones) that are represented through legacy sockHidra
parameters in the database.
This results in iterating over the task (tareas_acciones) table in the
database to fetch the list of procedures (procedimientos).
Then, this iterates over the list commands that compose a procedures
represented through procedimientos_acciones table.
Finally, this builds and sends the sockHidra legacy message for the client.
This patch includes an implementation of the Linux linked list.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch includes tests for the remaining REST API commands:
POST /shell/output
POST /session
POST /poweroff
POST /reboot
POST /stop
POST /refresh
POST /hardware
POST /software
POST /image/create
POST /image/restore
POST /setup
POST /image/create/basic
POST /image/create/incremental
POST /image/restore/basic
POST /image/restore/incremental
POST /run/schedule
This test covers requests that are missing one of the parameters in its
payload.
|
|
|
|
|
| |
This test covers requests that do not contain 1 of the parameters in their
payloads.
|
|
|
|
|
| |
This test covers requests that do not contain 1 of the parameters in their
payloads.
|
|
|
|
|
| |
This test covers requests that do not contain 1 of the parameters in their
payloads.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch extends tests for requests without any payload in the following REST
API POST functions:
- /clients
- /wol
- /shell/run
- /shell/output
- /session
- /poweroff
- /reboot
- /stop
- /refresh
- /hardware
- /software
|
|
|
|
| |
This patch renames the setup command to avoid semantic confusion.
|
| |
|
|
|
|
| |
This patch adds missing parameters to the test JSON.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
| |
This test covers 3 scenarios:
1. Correct usage.
2. Incorrect usage, without payload.
3. Incorrect usage, use this command with GET.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the command "run/schedule" that kicks in pending commands
execution.
Request:
POST /run/schedule
{
"clients": ["192.168.56.11"]
}
Reply:
200 OK
This patch also adds a simple test to cover correction of the command.
|
|
|
|
| |
This test covers correction of the command.
|
|
|
|
| |
This test covers correction of the command.
|
|
|
|
| |
This test covers correction of the command.
|
|
|
|
| |
This test covers correction of the command.
|
|
|
|
| |
This test covers correction of the command.
|
|
|
|
| |
Update restore_image.json to use id and profile fields.
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the command "image/create" that creates an image
in a client.
Request:
POST /image/restore
{ "clients" : [ "192.168.56.11" ], "disk" : "1", "partition" : "1", "name" : "test", "repository" : "192.168.56.10", "type" : "UNICAST", "filesystem": "1", "image_id": "1"}
Reply:
200 OK
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the command "image/create" that creates an image
in a client.
Request:
POST /image/create
{ "clients" : [ "192.168.2.1" ], "disk" : "1", "partition" : "1", "code" : "1", "id" : "1", "name" : "test", "repository" : "192.168.2.2" }
Reply:
200 OK
|
|
|
|
|
|
|
| |
If no payload is attached to method that requires a payload, then the API
returns a 400 status code (following RFC 7231) instead of the previous 404.
test_0001_get_clients.py is also modified to fit the new status code.
|
|
|
|
|
| |
Some tests should perform GET requests however they incorrectly use POST.
Return codes for these tests have also been fixed.
|
|
|
|
| |
This test is already performed in test_0001_get_clients.py
|
|
|
|
|
| |
This test sends a POST with no body, which is illegal, use a function
name that describes this.
|
|
|
|
|
|
|
| |
This test checks for wrong headers HTTP requests:
1. POST /clients with a content length larger than a signed int.
2. POST /clients with an auth token larger than 63 characters.
|
|
|
|
|
|
|
|
| |
This test checks for too large HTTP requests, for example:
POST /clients
with a body of 4096 bytes.
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if you try to run the python test without the ogAdmServer
binary, it will throw an exception.
This patch adds a check to ensure the existence of the ogAdmServer binary
at the beginning of the script.
# python3 run-tests.py
You need to build the ogAdmServer binary to run these tests :-)
|
|
|
|
|
| |
Without the brackets the call works (200 response) but the ogAdmServer
does not send the WOL packets.
|
|
|
|
|
|
|
|
|
| |
This test adds four new error test cases:
1. Non existent method with POST.
2. Non existent method with GET.
3. Non existent method with POST but with wrong API token.
4. Non existent method with POST but without json.
|
|
|
|
|
|
|
| |
This test covers two two scenarios:
1. Correct usage.
2. Incorrect usage, use this command with GET (this returns http 405).
|
|
|
|
|
|
|
| |
This test covers two two scenarios:
1. Correct usage.
2. Incorrect usage, use this command with GET (this returns http 405).
|
|
|
|
|
|
|
| |
This test covers two two scenarios:
1. Correct usage.
2. Incorrect usage, use this command with GET (this returns http 405).
|
|
|
|
|
|
|
| |
This test covers two two scenarios:
1. Correct usage.
2. Incorrect usage, use this command with GET (this returns http 405).
|
|
|
|
|
|
|
| |
This test covers two two scenarios:
1. Correct usage.
2. Incorrect usage, use this command with GET (this returns http 405).
|
|
|
|
|
|
|
| |
This test covers two two scenarios:
1. Correct usage.
2. Incorrect usage, use this command with GET (this returns http 405).
|
|
|
|
| |
This should test /shell/run instead of /session
|
|
|
|
|
|
|
|
| |
* Call the tests with python module unittest. In particular, the
discover function.
* Rename tests files to meet the default requirements of discover
function.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the command "software" that fetches the software
configuration from the clients.
Request:
POST /software
{"clients" : [ "192.168.2.1", "192.168.2.2" ]}
Reply:
200 OK
This allows to refresh the software inventory from clients.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch implements the command "hardware" that fetches the hardware
configuration from the clients.
Request:
POST /hardware
{"clients" : [ "192.168.2.1", "192.168.2.2" ]}
Reply:
200 OK
This allows to refresh the hardware inventory from clients.
|