| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
| |
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"
}
}
]
}
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Otherwise, users have to use POST /modes to make clients bootable.
|
|
|
|
| |
This argument is not needed for setting clients' boot mode.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
REST API request does not need to perform a list lookup on the wol list.
|
|
|
|
|
| |
Trasient network problems might result in duplicated clients, drop
client object if it already exists before creating a new one.
|
|
|
|
|
| |
Remove legacy behaviour, store it in the client object instead of a temporary
file.
|
|
|
|
| |
Other methods expect not NULL clients' group.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Make direct call to dbi API to update database instead.
|
|
|
|
| |
Remove declarations that are not used anymore in ogAdmLib.
|
|
|
|
|
|
|
| |
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": []
}
]
}
]
}
|
|
|
|
|
| |
as described by man(3) ev, to make it work with ev_timer_again()
otherwise timer might not ever expire.
|
|
|
|
|
|
|
|
|
| |
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 141b0797e17f616d6 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.
|
|
|
|
|
|
|
|
|
|
|
| |
Unnattended upgrades from Ubuntu can cause a stop and start of mysql
service, this in turn makes ogserver go down.
Avoid ogserver shutting down when mysql does. It's not necessary,
ogserver can report if it can't connect to the database.
'Wants' declare a weak dependency as described in
https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Wants=
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
Otherwise, procedure id is always zero.
Fixes: 1fdb7e6d1cf0709b1079b2d9990c0d53d8740461
|