| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
Use permissions and last update from client.
update src/schema.c to add a new database version.
|
|
|
|
|
| |
Still incomplete, src/schema.c needs to be update to add a new field to the
'imagenes' table in the database.
|
|
|
|
| |
add .description field to json.
|
|
|
|
|
|
|
|
|
|
|
| |
netmask field in 'computers' table is never used, but ogcli still
displays it through:
# ogcli list client --client-ip 1.2.3.4
and it shows '0' or incorrect netmask (ogCP hardcodes this field).
Update SQL query to fetch the room.netmask instead.
|
|
|
|
|
|
|
| |
Add GET /room/info to obtain room information, this includes the name,
gateway and netmask.
curl -X GET -H "Authorization: $API_KEY" http://127.0.0.1:8888/room/info -d '{ "id" : 1 }
|
|
|
|
|
|
| |
Use computer.maintenance instead of computer.name.
Fixes: af47a082adb1 ("#1004 Add GET /client/info HTTP REST method")
|
|
|
|
|
|
|
|
|
|
| |
Add POST repository/update request to update repository. Repository is
identified by its id, that is provided in the payload.
This can be tested with curl like:
curl -X POST -H "Authorization: $API_KEY"
http://127.0.0.1:8888/repository/update -d '{ "repo_id" : 16, "center" :
3, "name": "newName", "ip":"127.0.0.1" }'
|
|
|
|
|
|
|
|
|
|
| |
The following log message is display for each ogClient that is connected to
the ogServer:
Sent refresh to: 192.168.2.200
this tells the ogClient to send his current partition table when the connection
between ogServer <-> ogClient starts. This is not very useful, remove it.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Skip logging for the following REST API invocations:
- GET /scopes
- GET /clients
- POST /clients (for legacy web console only)
The web front-end generated very frequent requests for this.
Update logging format to:
127.0.0.1:54637 POST /wol clients=192.168.2.130
to include client IP address.
|
|
|
|
|
|
|
|
|
|
| |
Valgrind reports a memleak because og_cmd_wol() overrides params->ips_array,
then it releases params->ips_array but og_cmd_free() already does this.
Use a new_params structure to store the IPs that has been filtered through the
database query and check that buffer overrun does not happen.
Fixes: e4cb91b5f660 ("#990 wol: migrate mac and netmask query to ogServer")
|
|
|
|
|
| |
Set it to 1, ogCP and ogCLI never use this, and this REST API is never
used by the old web console.
|
|
|
|
| |
Remove unused code in this request and do not assume center id.
|
|
|
|
|
| |
Add POST client/update request to update client, this is identified by its ip
address, with the data provided in the payload.
|
|
|
|
| |
debian packages use etc, so update source code to use this folder too.
|
|
|
|
|
| |
Until there is TLS support for this, frontend and ogserver needs to be in the
same box by now.
|
|
|
|
|
|
| |
ogserver will check that the user provided a valid bootmode. It will go
through the list of all available boot modes and check that the bootmode
provided by the user is in said list; otherwise, it will not set it.
|
|
|
|
|
|
| |
og_cmd_get_modes() now uses a helper function that returns a list of all boot
modes, this is for a new API REST validate that boot mode is set to something
that exists in a follow up patch.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Every time a delete operation is performed it needs to be checked that a row
has been deleted. If no rows are deleted, then ogserver reports an error.
Previous to this change, it only checks that the connection to db
was succesful. For example, previously, if a user deletes a client that did
not exist, ogserver responds with no errors.
After this change, it responds with an error.
This error check has been implemented when deleting:
- A client
- An image
- A center
- A repo
- A room
- A server
|
|
|
|
|
| |
/clients says bad request for unsupported method, use correct error
report.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POST /repository/add checks validity of the repository ip address
specified in the request payload.
/repository/add can optionally receive a center id parameter inside its
request payload. For backward compatibility, the default center id (1)
is used if no center is received inside the request payload.
POST /repository/add returns a JSON response payload containing relevant
fields from the inserted repository.
$ curl -D-
\ -X POST
\ -H "Authorization: a0e9ab768cbe93dab5b1998e952bcdb7"
\ --json '{"name": "helloworld", "ip": "192.168.21.21a", "center": 2}'
\ localhost:8888/repository/add
HTTP/1.1 400 Bad Request
Content-Length: 0
$ curl -D-
\ -X POST
\ -H "Authorization: a0e9ab768cbe93dab5b1998e952bcdb7"
\ --json '{"name": "helloworld", "ip": "192.168.21.21a", "center": 2}'
\ localhost:8888/repository/add
HTTP/1.1 200 OK
Content-Length: 54
{"id": 7, "ip": "192.168.21.21", "name": "helloworld"}
|
|
|
|
|
|
|
|
|
|
| |
Move struct og_repository to dbi.h and use field max length for name and
ip.
Use og_json_parse_string_copy instead of og_json_parse_string to check
maximum length against the request payload.
Fixes: 86ccc3c2e8377623 ("#915 Add POST /repository/add")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Set a client repository in the OpenGnsys database using the endpoint
POST /client/repo.
Expects "clients" and "id" parameters in the request payload.
POST /client/repo
{
"clients": [...],
"id": "2"
}
Response:
200 OK
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Replace invalid variable @ipserveradm by @serverip in the SQL query of
og_set_client_mode.
@ipserveradm is a typo as this variable does not exists. This ends up
feeding a string to the legacy setclientmode code and crashes.
This bug also caused problems when adding clients via ogCP or any other
command that required running the set client mode logic.
Fixes: e080fd5526949a5615ae391ea9dda8b70c95f345
(rest: add "server=" boot param in set client mode)
|
|
|
|
|
|
|
|
|
|
|
|
| |
When og_dbi_open cannot open a connection during schema update, then
ogServer crashes.
og_dbi_open returns NULL when it cannot open a DB connection.
Do not use dbi variable if og_dbi_open is unable to open a DB
connection.
Add syslog message when database schema couldn't be updated.
|
|
|
|
|
|
|
| |
Store a client associated ogserver ip address in "server=" boot param.
Use this boot param to lookup for network-specific ogClient
configuration when launching ogClient during ogLive booting process.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
struct og_computer holds the value of "identorno" column inside the
server_id field.
Extend GET /client/info payload with server_id. This way clients can
get the associated server id when requesting client information.
{
...
"server_id": 1,
}
|
|
|
|
|
|
|
|
|
| |
Extend og_dbi_get_computer_info to fetch "identorno" column from
"ordenadores". "identorno" holds the row id value from the "entornos"
table (valid ogserver addresses).
Extend og_computer struct with a new field: "server_id" that will store
the value of "identorno" column fetched from the database.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Enable modification of the associated ogserver of a given client.
This API is exposed via the POST /client/server endpoint and expects a
JSON payload with an array of clients ("client":[]) and the "id" of the
ogserver ("identorno" column value inside the "entornos" table)
For example:
>>>
POST /client/server
{
"client": [
"10.141.10.100",
"10.141.10.101",
"10.141.10.104",
"10.141.10.102"
],
"id": "6"
}
<<<
HTTP/1.1 200 OK
If the ogserver id does not exist the foreign key constraint (ON UPDATE
RESTRICT) inside the "ordenadores" table will cancel the operation and
the server will reply with 400 Bad Request.
>>>
POST /client/server
{
"client": [
"10.141.10.100",
"10.141.10.101",
"10.141.10.104",
"10.141.10.102"
],
"id": "666"
}
<<<
HTTP/1.1 400 Bad Request
The OpenGnsys database stores different ip addresses for the ogServer
inside the "entornos" table. This table is related to the "ordenadores"
table using a foreign key on the "identorno" column.
i.e: Clients in the "ordenadores" table associate to an specific server
in the database using the "identorno" column (from "entornos" table).
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Expose deletion of rows from "entornos" table via the /server
endpoint using the DELETE http request method.
The expected payload is the server id as a string. For example:
>>>
DELETE /server
{ "id": "4" }
<<<
200 OK
If the specified server is currently associated with any computer
("ordenadores" table) the foreign key contraint (ON DELETE RESTRICT)
will avoid the deletion and the server responds with
400 Bad Request.
>>>
DELETE /server
{ "id": "1" }
<<<
400 Bad Request
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reuse endpoints in order to add deletion operation such as "/server".
This way there is no need to declare a different if/else block in order
to parse a new URI for the new "*/delete" endpoint.
Current deletion operations are implemented using a different endpoint
name such as "/client/delete", "/center/delete" with POST request method.
Endpoints using "/delete" suffix may not be removed for backwards
compatibility. Adding HTTP method DELETE support for endpoints such as
"/center" or "/client" can use the already existing *_post_delete*
functions.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
DB stores different ogserver addresses in the "entornos" table.
Expose addition and deletion operations for the "entornos" table using
the /server endpoint.
GET /server returns a list of rows from the "entornos" table including
the "identorno" and "ipserveradm" columns. For example:
>>>
GET /server
<<<
200 OK
...
{
"servers": [
{
"id": 1,
"address": "10.141.10.1"
}
]
}
POST /server inserts into the "entornos" table and returns the
id ("identorno") of the new row.
>>>
POST /server
{
"address": "192.168.2.240"
}
<<<
200 OK
...
{
"id": 2
}
If the server address already exists the response is 400 Bad Request
with no payload.
>>>
POST /server
{
"address": "192.168.2.240"
}
<<<
400 Bad Request
|
|
|
|
|
|
|
|
|
|
|
| |
This parameter is used by ogServer to instruct target client if image
backup should be performed before image creation.
This parameter is optional to preserve backward compatibility with
webconsole (legacy web client) and avoid the need of updating any legacy
client.
Default is true if the REST request is missing this parameter.
|
|
|
|
|
|
|
|
| |
We need to inspect the received payload if any error is raised related
to the X-Sequence header. Not just when a malformed X-Sequence header is
detected.
Fixes: d2c19ef13d7 ("core: add X-Sequence header support")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add non-standard HTTP header "X-Sequence" to the header section of
requests (og_send_request) sent to a connected client.
Define a starting sequence number when creating a new instance of struct
og_client inside og_server_accept_cb. This sequence number is
incremented by one for each outgoing request from ogServer.
This sequence number is checked when receiving a response from a
connected client, if they do not match the connection is dropped.
Use sequence 0 for out-of-band commands (reboot, poweroff, stop). Any
client response with header "X-Sequence: 0" bypasses sequence check.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Harden refresh response logic. Check for necessary JSON fields inside
the payload.
Check if serial_number is null before calling strlen, prevent ogServer
from a malformed refresh response with missing serial_number.
Refresh uses legacy function actualizaConfiguracion that takes a long
string with the computers configuration (serialno, partitions, disks,
link speed and status). Check for an empty string before executing any
legacy code inside actualizaConfiguracion.
|
|
|
|
|
|
|
|
|
|
|
|
| |
Large software inventory is truncated because it does not fit into the
existing buffer.
Software inventory response payload consists of a string with each
component delimited by '\n'. Large software inventories can consist of
more than 8192 bytes.
Avoid truncating any large software inventory by increasing the buffer
size where this string is stored.
|
|
|
|
|
| |
Otherwise, administrators can not read the logging history from
WebConsole.
|
|
|
|
|
|
|
|
|
|
|
|
| |
ogServer "GET /images" list images that exist simultaneously in database
and in disk (/opt/opengnsys/images).
With this patch, ogServer list all images in database, exist or not in
disk. If an image exists in disk, it retrieves more information about
them.
This change is useful for environments where images are in different
machines/repositories.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method deletes a repository from the database.
Request:
POST /repository/delete
{
"id": "10"
}
Response:
200 OK
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This method adds a new repository to the database.
Request:
POST /repository/add
{
"name": "Repository 1",
"ip": "192.168.56.10"
}
Response:
200 OK
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add id parameter to the response. This is useful to identify
repositories that have several IPs.
Request:
GET /repositories
{
"repositories": [
{
"id": 1,
"ip": "192.168.56.10",
"name": "Repositorio (Default)"
}
]
}
Response:
200 OK
Related-to: d5e6dc0 ("#915 Add API GET /repositories")
|
|
|
|
|
|
|
|
|
|
|
| |
On image creation, ogServer always sends 0 as image id to clients. When
clients sends the response to the "create image" command with new
information to update the image's entry in the database, the image id is
0 and ogServer fails to update the image's entry.
This patch fixes this, assigning the correct id of the image.
Fixes: d2f20d0be0661 ("#942 Create DB image when calling POST /image/create")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
API "GET /images" shows the repository ID the image belongs to, instead
of the IP. This is a preparative commit to the support of repositories
with several IPs.
Request GET /images
Response 200 OK:
{
"images": [
{
"name": "windows10",
"datasize": 0,
"size": 626088433,
"modified": "Fri Jun 10 12:20:32 2022",
"permissions": "744",
"software_id": 1,
"type": 1,
"id": 6,
"repo_id": 1
}
],
"disk": {
"total": 52573995008,
"free": 38964637696
}
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
POST /image/create has two modes, image creation and update. You can
find more information about the "creation" mode in commit:
d2f20d0be06617f421eecca111449d94672695eb
On image creation, use the id to identify repositories instead of the
IP. This is a preparative commit to the support of repositories with
several IPs.
On image update, "repository_id" field is not needed because the image
already has the repository assigned.
This commit maintains backward compatibility with the Web Console (old
web interface), because it only use the "update" mode of /image/create.
Request POST /create/image:
{
"clients": [
"192.168.56.11"
],
"disk": "1",
"partition": "1",
"name": "archlinux",
"repository_id": 1,
"id": "0",
"code": "131",
"description": "This is a test",
"group_id": 0,
"center_id": 1
}
Response 200 OK
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add foreign key "identornos" from table "entornos" to table
"ordenadores".
A row in table "entornos" represent a valid ogServer address.
Multiple ogServer valid addresses can exist when running several
instances or a single ogServer instance is exposed to different networks.
Can't delete rows in "entornos" table nor update their id (primary
key) if the row has any associated clients ({ON UPDATE/ON DELETE} RESTRICT).
Allows assigning different but valid ogServer IPs to clients.
Enabling support for multiple instances of ogServer (e.g: load balancing) or
exposing a single ogServer instance to different networks (e.g: VLAN).
Look up for the valid ogServer IP of a given client when changing a
client's mode (og_set_client_mode).
Determines valid ogServer IP using a JOIN statement.
JOIN entornos USING(identorno)
Reuses the fetched ip using a statement variable.
@serverip:=entornos.ipserveradm
For example, for a two VLAN setup:
vlan1 ogserver: 192.168.56.10
vlan2 ogserver: 192.168.57.10
The "entornos" table should look like:
identorno ipserveradm ...
--------- ----------- ...
1 192.168.56.10 ...
2 192.168.57.10 ...
And computers in the "ordenadores" table might look like:
idordenador identorno ...
---------- --------- ...
1 1 ...
2 1 ...
3 2 ...
4 2 ...
... ... ...
Additionally, splits the SQL query for better readability.
Co-authored-by: Jose Guisado <jguisado@soleta.eu>
|
|
|
|
|
| |
Assign to the image the repository indicated in the JSON body instead of
a default one.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This extension adds the field 'repo_ip', indicating which repository has
the image. This new field is useful when restoring an image.
Request:
GET /images
Response:
200 OK
{
"disk": {
"free": 37091418112,
"total": 52573995008
},
"images": [
{
"datasize": 5939200000,
"id": 25,
"modified": "Wed Oct 14 11:49:00 2020",
"name": "archlinux",
"permissions": "744",
"size": 1844222333,
"software_id": 19,
"type": 1
"repo_ip": "192.168.56.10"
}
]
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This API returns a list of available images repositories.
Request:
GET /repositories
Response
200 OK
{
"repositories": [
{
"ip": "192.168.56.10",
"name": "Default"
},
{
"ip": "192.168.57.10",
"name": "Extra"
}
]
}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Valgrind says:
==9452== 1 errors in context 1 of 38:
==9452== Conditional jump or move depends on uninitialised value(s)
==9452== at 0x11BD1E: og_resp_refresh (client.c:383)
==9452== by 0x11CF2A: og_agent_state_process_response (client.c:822)
==9452== by 0x112FCE: og_agent_read_cb (core.c:254)
==9452== by 0x4E41D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==9452== by 0x4E453DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==9452== by 0x1107CD: ev_loop (ev.h:835)
==9452== by 0x1107CD: main (main.c:108)
==9452== Uninitialised value was created by a stack allocation
==9452== at 0x11BB02: og_resp_refresh (client.c:348)
Fixes: f03425e ("#915 Add support for link speed in the refresh response")
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"last_cmd" json object contains information of the last command executed
by the correspondent client. For now, it only includes "result" string
property, which stores "success" if the last command finished correctly
or "failure" on the contrary.
To populate "result" property, this commit also adds "last_cmd_result"
enum attribute to og_client struct. Client response processing fills
this attribute according to its success.
Clients in WOL_SENT state always have last_cmd->result = "unknown".
Request: GET /clients
Response: 200 OK
{
"clients": [
{
"addr": "10.141.10.102",
"state": "WOL_SENT",
"last_cmd": {
"result": "unknown"
}
},
{
"addr": "10.141.10.101",
"state": "OPG",
"speed": 1000,
"last_cmd": {
"result": "success"
}
},
{
"addr": "10.141.10.100",
"state": "OPG",
"speed": 1000,
"last_cmd": {
"result": "failure"
}
}
]
}
|