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"
}
]
}
"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"
}
}
]
}
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
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
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.
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.
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.
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.
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.
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.
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
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"}
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.
Javier Sánchez Parra
OpenGnSys Support Team
Jose M. Guisado
Diego Crespo Quinta