Add uri to allow the change of a center's properties such as 'name' or
'comment'
Refuse to update center's name if that name is already in use by another
center. This is because a center should not share name with another one.
Reply with an error if user tries to create a client with a mac that is
already owned by another client
Write to syslog info about the client that owns the mac: client's name,
ip, mac address and room
Change the name of variable 'group', in og_group struct, to 'folder_id'.
Change payload field to 'folder_id'
These changes are to make code easier to understand.
Add support for deleting folders containing rooms. Delete rooms that are
in folder.
Computers inside rooms are automatically deleted in cascade when room is
deleted (implemented in sql)
Add support for deleting folders containing clients. Delete clients that are
in folder.
marker tells us if this folder to group rooms or computers.
this is a woraround because the database has two tables to store room and
computer folders, there is no unique id.
the tables cannot be merged yet because of the legacy web console, to overcome
this limitation, add a marker that provides a unique id to differentiate room
and computer folder.
this assumes only 65535 room folders are possible because the marker is
0x000010000 (65536)
do not use description field to decide if this is a new image or an update.
add og_dbi_get_image() to check if the image exists. If it is not found, then
add new image entry to database.
update og_dbi_add_image() to update the image.id field.
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 }
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: e4cb91b5f6 ("#990 wol: migrate mac and netmask query to ogServer")
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
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: 86ccc3c2e8 ("#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: e080fd5526
(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: d2c19ef13d ("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.
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.
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: d2f20d0be0 ("#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:
d2f20d0be0
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>
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"
}
}
]
}
Add ogServer support for parsing and storing the link speed from
ogClient's refresh response.
Probe response already has client's link speed, but this API is
deprecated.
Extend GET /stats to show the number of seconds since the ogserver started.
{
"time": {
"now": 1647262765, /* Seconds since 1970 */
"boot": 2151909 /* Seconds since boot */
"start" : 1647262854,, /* Seconds since 1970 */
},
[...]
This request returns certain statistics on memory and swap usage, as
well as the uptime.
The below structure gives the sizes of the memory and swap fields in
bytes.
Request: GET /stats
NO BODY
Response: 200 OK
{
"time": {
"now": 1647262765, /* Seconds since 1970 */
"boot": 2151909 /* Seconds since boot */
},
"memory": {
"size": 4104679424, /* Total usable main memory size */
"free": 322174976 /* Available memory size */
},
"swap": {
"size": 2147479552, /* Total swap space size */
"free": 2122563584 /* Swap space still available */
}
}
Report linux and windows client status in a compatible manner
with webconsole. This way clients are colored accordingly in
a room view depending on their status.
WIN/WINS: Windows, Windows session
LNX/LNXS: Linux, Linux session
Do not release the json object twice, once from og_send_request() and
again og_cmd_free().
Valgrind reports:
==11885== Invalid read of size 8
==11885== at 0x117B9A: json_decref (jansson.h:128)
==11885== by 0x117B9A: og_cmd_free (rest.c:2409)
==11885== by 0x113465: og_agent_deliver_pending_cmd (core.c:211)
==11885== by 0x113465: og_agent_read_cb (core.c:256)
==11885== by 0x4E41D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==11885== by 0x4E453DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==11885== by 0x110C2D: ev_loop (ev.h:835)
==11885== by 0x110C2D: main (main.c:104)
==11885== Address 0x8e7e988 is 8 bytes inside a block of size 72 free'd
==11885== at 0x4C32D3B: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11885== by 0x117437: json_decref (jansson.h:129)
==11885== by 0x117437: og_send_request (rest.c:330)
==11885== by 0x113454: og_agent_deliver_pending_cmd (core.c:208)
==11885== by 0x113454: og_agent_read_cb (core.c:256)
==11885== by 0x4E41D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==11885== by 0x4E453DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==11885== by 0x110C2D: ev_loop (ev.h:835)
==11885== by 0x110C2D: main (main.c:104)
==11885== Block was alloc'd at
==11885== at 0x4C31B0F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==11885== by 0x526461A: json_object (in /usr/lib/x86_64-linux-gnu/libjansson.so.4.11.0)
==11885== by 0x116A07: og_cmd_legacy_image_restore (rest.c:2627)
==11885== by 0x116A07: og_cmd_legacy (rest.c:2757)
==11885== by 0x116A07: og_queue_task_command (rest.c:2848)
==11885== by 0x118284: og_dbi_queue_command (rest.c:3109)
==11885== by 0x118284: og_schedule_run (rest.c:3190)
==11885== by 0x1147B9: og_agent_timer_cb (schedule.c:445)
==11885== by 0x4E41D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==11885== by 0x4E453DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==11885== by 0x110C2D: ev_loop (ev.h:835)
==11885== by 0x110C2D: main (main.c:104)
This patch aims simplifies the WoL sender routine.
A few related changes:
- Replace goto err to continue if IP address is malformed
- Use ret |= instead of ret &= to accumulate error code.
Levanta() is not required, iterate over the array of IP address and make
direct calls to WakeUp().
This is also implicitly fixing up a memleak in og_cmd_wol().
This patch allows you to update clients' database entry and PXE boot
file with the specified ogLive.
If you specify either an incorrect or unexisting ogLive, then, clients
use the default ogLive image. You can query ogLives installed on the
server with ogServer's GET /oglive/list API.
If you set the oglive field to "default", then the default ogLive is
used.
Request: POST /oglive/set
{
"clients": ["192.168.56.11", "192.168.56.12"],
"name": "ogLive-5.4.0-r20200629"
}
Response: 200 OK
Handles non usual situations like a client sending more than
one event of same type.
When toggling, receiving two events of the same type is the
same as receiving two different ones (eg. start, then stop).
Split into _session_start and _session_stop in order to check
valid client status.
ogServer supports events from clients in an agent mode
(linux/windows).
Client sends event information (eg. user login/logout)
via a 103 Early Hints http response message.
The database represents rooms groups and computers groups scope sets
with "grupos" (groups) and "gruposordenadores" (computers groups) tables
respectively. With this commit, ogServer abstracts both sets and offers
them though the API as the set "folder".
"grupos" table do not only group rooms, it can group other
elements of the database. You can see which kind of elements groups
looking at the column "tipo".
This commit often refers "rooms group" as group and "computers
group" as computers.
Request:
GET /scopes
NO BODY
Response
200 OK
{
"scope": [
{
"name": "center1",
"type": "center",
"id": 1,
"scope": [
{
"name": "folder1",
"type": "folder",
"id": 1,
"scope": [
{
"name": "folder2",
"type": "folder",
"id": 2,
"scope": []
},
{
"name": "room1",
"type": "room",
"id": 2,
"scope": [
{
"name": "folder3",
"type": "folder",
"id": 3,
"scope": [
{
"name": "folder4",
"type": "folder",
"id": 4,
"scope": []
},
{
"name": "computer1",
"type": "computer",
"id": 8,
"scope": [],
"ip": "192.168.56.12"
}
]
},
{
"name": "computer2",
"type": "computer",
"id": 7,
"scope": [],
"ip": "172.18.0.71"
}
]
}
]
},
{
"name": "room2",
"type": "room",
"id": 1,
"scope": []
}
]
}
]
}
ogClient can be run in windows mode, enabling connection with ogServer
when running on a Windows machine.
Don't expect the same payload in windows mode as a in live or virtual.
Client in windows mode does not send partition setup information, only
the status/state. (same case for linux mode)
ogClient can be run in linux mode, intended for exposing some
ogServer commands when running in a linux distribution.
When connecting with a client in linux mode, do not expect a full
partition setup response. Just expect a 'status', and then accept
the connection without updating any partition information in
the database.
200 => successful command, run next pending command
202 => successful command in progress, do not run next pending command
403 => server sent a malformed HTTP header, should not ever happen,
close connection (server is buggy?).
500 => client fails to run command, report error and run next pending command
503 => client is busy, report error and do not run next pending command
Anything else, should not ever happen (client is buggy?), close connection with
client.
On error, when processing response from ogClient, do not close the connection,
instead annotate in the database that command was not successful and run next
pending command.
*Only* if client replies status code 500 set last_cmd to UNSPEC so its state is
not BSY as reported by og_client_status function and pending cmds can be
sent.
The position 0 of the software profiles array is not initialized,
this triggers a bug randomly on image creation if the position 0
comes zero. Adjust the loop to initialize position 0 accordingly.
Commit 141b0797e1 introduced command scheduling rest api to
ogserver. Part of this changeset included
og_json_parse_create_image as a utility funtion to parse the json
payload of a "create image" command.
og_json_parse_create_image did not include the parsing of optional
parameters "description", "center_id" and "group_id". New components
like ogCP or ogCLI use these parameters.
Fix this by adding a struct og_image member to the struct og_msg_params
and assigning it when processing a "create image" command.
This could be extended to further payload parsing for image related
commands in the future.
Delete operation for images stored in the server. It deletes an image
from the database and filesystem, thus images must exists in both places.
POST /image/delete
{
"image": "3"
}
Pending schedule commands can deny ogLive boot of clients due
to filling of pending cmd queue with commands such as "Iniciar Sesión".
For example: Using RemotePC to serve clients that do not boot into
ogLive will fill up the pending command queue with "Iniciar Sesión".
Introduce a safety timeout for pending (scheduled) commands to
avoid this situation.
The "code" member of the og_legacy_partition is used to hold the string of
the partition type *name* for legacy parameter strings. Example:
par=2*cpt=LINUX-SWAP*sfi=LINUX-SWAP*tam=10000000*ope=0
Problem: Buffer size is smaller than possible values for this member.
Fix: Increase buffer size up to the max length defined in the DB
for the corresponding column.
Fixes task_id re-initialization in commit 33d8cecfe.
Task id is to be initialized with the "session" value and can be done
out of the for loop it was before. Avoiding unnecesary snprintf's with
the same value.
If the scope of a command, procedure or task is related to a group of
computers then actions associated with that schedule can share the same
session value.
og_dbi_add_action was not initializing session value, as it is only used
for visualization purposes in the legacy web interface.
This patch enables og_dbi_add_action to populate session column by
assigning it the id value of the first action related to the scope.
Example: Power off command for a room scope of 4 clients will result in
4 actions, a power off for each client. The first action id will determine
the session value for the rest.
A single command can be schedule for several clients.
Commit 141b0797e1 introduces a regression when scheduling a command for
several clients, the command only executes successfuly for the first
one.
Fix it by reintroducing the usage of the 'session' column to group
a single command into several actions (one for each client), the web
console interface already expects this 'session' column to be set
accordingly.
Adds the possibility to create a task with procedures and other tasks
integrated as steps.
Note: "steps" parameter is optional and "steps" array object order
defines execution order.
Request:
POST /task/add
{
"center": "1",
"name": "task",
"description": "My task",
"steps": [
{
"procedure": 4
},
{
"task": 1
},
{
"procedure": 24
}
]
}
Response:
200 OK
This commit also add task case to procedure's step processing.
Otherwise, gcc prints the following warning:
src/rest.c: In function ‘og_procedure_add_steps’:
src/rest.c:4089:17: warning: enumeration value ‘OG_STEP_TASK’ not handled in switch [-Wswitch]
4089 | switch (step->type) {
| ^~~~~~
Adds the possibility to update a procedure with commands and other
procedures integrated as steps.
Note: "steps" parameter is optional and "steps" array object order
defines execution order. Also, if the body has empty steps, the
procedure loses its previous steps.
Request:
POST /procedure/update
{
"procedure": "34",
"center": "1",
"name": "procedure-edited",
"description": "My procedure edited",
"steps": [
{
"command": "wol",
"params": { "type": "broadcast" }
},
{
"procedure": 24
},
{
"command": "reboot",
"params": {}
}
]
}
Response:
200 OK
ogServer searches queued commands (formerly actions) in the DB by
session. This can lead to problems because session is not an uniquely
identifier but an identifier that several commands can share to group
them.
This commit changes query filter from session to id, ensuring correct
results
This reverts commit d9b6aadf66.
Add ogServer support procedure execution. Now users can send a procedure
and a list of clients to ogServer, then ogServer breaks down the
procedure into commands (formerly actions) and queues them for each
indicated client.
TODO: Do not reply 200 OK when the procedure do not exist.
Request:
POST /procedure/run
{
"clients": ["192.168.56.11", "192.168.56.12"],
"procedure": "33"
}
Response:
200 OK
Delete operation for procedures stored in the database.
POST /procedure/delete
{
"id": "7"
}
If no procedure is found returns 200 OK but a syslog call is issued to
warn so. Such behavior will likely change in the future.
Commit 141b079 introduced a slight change in how rows from table
"acciones" are filtered when queuing a command, from "sesion" column to
"idaccion" column.
This seemed reasonable, as id column is the one autoincrementing. But
remotepc queued commands inserting actions id using a timestamp instead
of the action row id.
See c17ffa5d03/admin/WebConsole/rest/remotepc.php (L188)
Revert said change as long as remotepc keeps such behavior.
These function declarations belong to json.h:
int og_json_parse_partition_setup(json_t *element, struct og_msg_params *params);
int og_json_parse_create_image(json_t *element, struct og_msg_params *params);
int og_json_parse_restore_image(json_t *element, struct og_msg_params *params);
Adds the possibility to create a procedure with commands and other
procedures integrated as steps.
Note: "steps" parameter is optional and "steps" array object order
defines execution order.
Request:
POST /procedure/add
{
"center": "1",
"name": "procedure",
"description": "My procedure",
"steps": [
{
"command": "wol",
"params": { "type": "broadcast" }
},
{
"procedure": 22
},
{
"command": "poweroff",
"params": {}
}
]
}
Response:
200 OK
This commit also updates unit tests for /procedure/add POST method to
include steps.
Enables ogserver to schedule commands (also referred as actions in
legacy web console jargon).
This feature enables ogserver to write in the "acciones" table in order
to have full capabilities for command scheduling purposes, thus not
depending in the legacy web console to insert into "acciones" table.
When trying to open a connection to a database, an instance of
libdbi is created before any connection attempt. If connection is
unsuccessful then the og_dbi struct is freed but not the
libdbi instance member, thus leaking its memory.
Use libdbi dbi_shutdown_r to shutdown libdbi instance member
before freeing og_dbi struct inside og_dbi_open.
This method adds a procedure associated with a center to the database.
Required payload parameters are center and name, description is
optional.
Note: ogServer does not allow to add more than one procedure with the
same name and center.
Request:
POST /procedure/add
{
"center": "1"
"name": "procedure1"
"description": "My procedure"
}
Response:
200 OK
This commit also adds unit tests for /procedure/add POST method.
/usr/bin/ld: src/schema.o:/home/soleta/opengnsys/ogServer/src/schema.c:50: multiple definition of `ogconfig'; src/main.o:/home/soleta/opengnsys/ogServer/src/main.c:31: first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:411: ogserver] Error 1
Add ogServer support for parsing and storing in the DB disk type data
from ogClient refresh response.
See also commits with #1037 in ogClient and WebConsole repo.
This method deletes a room (lab) from the DB and deletes on cascade
computers and computers partitions.
Note: if the room id do not exists in the database, ogserver still
tries to delete it and replies with 200 OK.
Request:
POST /room/delete
{
"id": "1"
}
Response:
200 OK
This method deletes a center from the DB and deletes on cascade
rooms/labs, computers and computers partitions.
Note: if the center id do not exists in the database, ogserver still
tries to delete it and replies with 200 OK.
Request:
POST /center/delete
{
"id": "1"
}
Response:
200 OK
If a probe response contains speedinformation, parse and store
it inside the client struct. Speed is interpreted as an unsigned
integer representing Mbit/s.
Avoids multiple entries of a same client like
{"clients": [{"addr": "192.168.2.230", "state": "WOL_SENT"}, {"addr": "192.168.2.230", "state": "OPG"}]
These can arise when ogserver processes a WoL request for an already
connected client.
When processing the WoL request, search for the target address in the
clients list, if found we avoid creating the wol entry.
Add foreign keys (version 1 introduced innoDB as default db engine)
allowing cascade deletions for some tables:
- perfilessoft_softwares
If a software profile or a software component is deleted, the
corresponding row in this table will be deleted too.
- ordenadores_particiones
If a computer or a partition is deleted from the DB, delete the
corresponding row inside this table.
- aulas
If the center the room is in is removed, delete the room too.
- ordenadores
If the room in which a computer is in is removed, the computer
will be deleted accordingly.
We should take into account that this schema superseeds some code
regarding deletions inside WebConsole that probably are not needed any
more, at least for the tables mentioned.
(See admin/WebConsole/gestores/relaciones/*.php in OpenGnsys repo)
This patch adds database schema management capabilities to ogServer:
- ogServer now tracks the version of its database schema, if no version
is detected, creates a 'version' table with a single row starting at 0.
- ogServer can upgrade its database schema to a newer version if
detected. (ogServer ships required SQL commands to do so)
If ogServer is unable to upgrade the schema at startup (if needed be) it
*will not* start.
Defines schema update v1 which upgrades database engine tables of
ogServer database (usually named 'ogAdmBD') from myISAM to innoDB.
Otherwise, copying response json to response buffer could lead to stack
smashing is the json response is too large.
stdout example:
*** stack smashing detected ***: <unknown> terminated
Several universities have reported that creating a software profile
hangs the machine running the ogServer for a while, sometimes up to
minutes.
Legacy SQL code is producing said bottleneck, responsible for pruning a
intermediate table between "perfilessoft" and "softwares". There is
redundant code, "perfilssoft" should be pruned first, speeding up the
later task of pruning the intermediate table "perfilessoft_softwares"
There is no need to execute:
DELETE FROM perfilessoft_softwares
WHERE idperfilsoft IN (
SELECT idperfilsoft
FROM perfilessoft
WHERE idperfilsoft NOT IN (
SELECT DISTINCT idperfilsoft
from ordenadores_particiones)
AND idperfilsoft NOT IN (
SELECT DISTINCT idperfilsoft from imagenes))
When afterwards "perfilessoft" is going to be pruned and
"perfilessoft_softwares" pruned again:
DELETE FROM perfilessoft WHERE idperfilsoft NOT IN
(SELECT DISTINCT idperfilsoft from ordenadores_particiones)
AND idperfilsoft NOT IN
(SELECT DISTINCT idperfilsoft from imagenes)
DELETE FROM perfilessoft_softwares WHERE idperfilsoft NOT IN
(SELECT idperfilsoft from perfilessoft)
The two latter commands suffice.
This should not happen when using a relational database supporting
foreign keys and ON DELETE CASCADE, like innoDB, which will be adopted
soon.
mktime modifies the struct tm it receives and takes into account whether DST is
active or not (tm_isdst). tm_isdst == 0 adjusts the time, which causes the time
mismatch error.
All fields are being initialized to 0 and therefore it is assumed that the time
that has been passed is not in daylight saving time.
When the value is negative in tm.tm_isdst it delegates to mktime to guess if it
is in daylight saving time or not, this works 99% of the time.
Best way would be that ogserver knows what is its timezone and when daylight
saving applies, so tm_isdst is set to 0 or 1 accordingly.
Meanwhile, "tm_isdst = -1" provides the hotfix.
Adds POST method to add centers (organizational unit), required payload
parameter is the name, and an additional comment is optional.
{"name": "ACME"}
{"name": "ACME", "comment": "Some comment"}
/create/image adds an entry to the database for the given partition
image created when payload contains a "description" attribute. This
insertion into the database is lacking a check for duplicates, which are
not supported for the images table.
Add a prior duplicate check before inserting. Exit with -1 code if an
image with the same name is found.
This function returns the installed and available ogLiveS in the server
to be booted from.
Request:
GET /oglive/list
NO BODY
Response
200 OK
{
"oglive": [
{
"distribution": "bionic",
"kernel": "5.4.0-40-generic",
"architecture": "amd64",
"revision": "r20200629",
"directory": "ogLive-5.4.0-r20200629",
"iso": "ogLive-bionic-5.4.0-40-generic-amd64-r20200629.85eceaf.iso"
},
{
"distribution": "bionic",
"kernel": "5.0.0-27-generic",
"architecture": "amd64",
"revision": "r20190830",
"directory": "ogLive-5.0.0-r20190830",
"iso": "ogLive-bionic-5.0.0-27-generic-amd64-r20190830.7208cc9.iso"
}
],
"default": 0
}
This commit also adds tests for GET /oglive/test.
==28831== 1 errors in context 1 of 2:
==28831== Invalid read of size 1
==28831== at 0x55AC6FD: inet_aton (inet_addr.c:127)
==28831== by 0x10ECCA: WakeUp (ogAdmServer.c:337)
==28831== by 0x10EED6: Levanta (ogAdmServer.c:292)
==28831== by 0x11651E: og_cmd_wol (rest.c:498)
==28831== by 0x11651E: og_client_state_process_payload_rest (rest.c:3970)
==28831== by 0x110CF3: og_client_read_cb (core.c:143)
==28831== by 0x4E41D72: ev_invoke_pending (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==28831== by 0x4E453DD: ev_run (in /usr/lib/x86_64-linux-gnu/libev.so.4.0.0)
==28831== by 0x10E3E5: ev_loop (ev.h:835)
==28831== by 0x10E3E5: main (main.c:100)
==28831== Address 0x0 is not stack'd, malloc'd or (recently) free'd
Use number of matching ip addresses in the database, skip if zero.
ogServer gets netmask address from computer (ordenadores) table, see
commit a35b7c4. Netmask field is empty in most cases, is only filled
when the user adds computers with dhcpd.conf syntax and cannot be edited
in computer properties view.
Labs/rooms (aulas) table also have netmask field, WebConsole backend
ensures it is not empty and can be edited in lab properties view.
Get netmask from labs table to ensure it is not empty.
Tests for e68fefe were made after 00pm (12:00) so we did not cover <12:00 cases
for immediate commands that are logged (scheduled for the exact moment
they are processed and ignored the fact they are stale so they are executed
right away)
In addition, libdbi was complaining about the data type used to
represent the hours, they were not being inserted properly. From syslog:
failed to query database (og_dbi_schedule_create:3288) 1264: Out of
range value for column 'horas' at row 1
Fix og_tm_hours_mask so <12:00 immediate schedule is handled correctly.
Change return type to uint16_t, as the 'hours' column type is smallint(4)
Fixes e68fefe ("#997 Set stale check flag when processing schedule/create")
Commit e68fefe introduced 'check_stale' flag to better distinguish
real scheduled actions that do not execute if they are stale from
immediate actions that we want them to be logged in the action queue
(by creating a decoy schedule for the exact moment they are processed,
meaning that we ignore if the are stale).
Add this feature into schedule update too, in order to avoid executing
stale commands that were not meant to, ie. real scheduled commands.
Follows e68fefe ("Set stale check flag when processing schedule/create")
After executing an scheduled command/proc/task valgrind reported
leaks inside og_dbi_queue_{command,procedure,task}. String
duplication is not being freed after using them.
==21281== 36 bytes in 1 blocks are definitely lost in loss record 470 of
592
...
==21281== by 0x113DCB: og_dbi_queue_procedure (rest.c:2748)
==21281== by 0x113F91: og_dbi_queue_task (rest.c:2804)
==21281== by 0x114392: og_schedule_run (rest.c:2916)
==21281== by 0x112059: og_agent_timer_cb (schedule.c:441)
...
==21281== by 0x10E2A5: main (main.c:100)
These strdup are not necessary because the dbi result is not freed
before using them, it's safe to use the dbi result's reference to
this string.
Fix previous memleaks when executing scheduled commands, procedures
and tasks.
If you schedule a command in the past, the scheduler executes such
command immediately.
When expanding a schedule that result in commands that run weekly,
commands in the past are also executed, which is not expected.
Fix this by using the check_stale flag (formerly on_start) so
commands in the past that result from expansions are skipped.
image_json object is created to store the json representation of
an image returned by the database. This object is going to be appended
to a json list that will compose the overall root json object.
Use json_array_append_new to let "images" steal the reference of
image_json so when further decref(root) there is no json reference
hanging around.
Javier Hernandez
OpenGnSys Support Team
Jose M. Guisado
Javier Sánchez Parra
Diego Crespo Quinta