summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* rest: return server_id in GET /client/infoJose M. Guisado2023-08-231-0/+1
| | | | | | | | | | | | | 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, }
* dbi: add server_id to og_computer structJose M. Guisado2023-08-232-0/+3
| | | | | | | | | 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.
* rest: add POST client/server methodJose M. Guisado2023-08-231-0/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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).
* rest: add DELETE operation to /server endpointJose M. Guisado2023-08-231-0/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* rest: support DELETE HTTP request methodJose M. Guisado2023-08-232-0/+4
| | | | | | | | | | | | | | 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.
* rest: add /server GET and POST methodsJose M. Guisado2023-08-231-0/+169
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* rest: add optional param "backup" for create_imagev1.2.3Jose M. Guisado2023-07-072-0/+9
| | | | | | | | | | | 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.
* core: log payload if sequences do not matchJose M. Guisado2023-07-031-3/+5
| | | | | | | | 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")
* core: add X-Sequence header supportv1.2.2Jose M. Guisado2023-06-133-3/+35
| | | | | | | | | | | | | | | 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.
* client: harden og_resp_refreshJose M. Guisado2023-06-072-1/+11
| | | | | | | | | | | | | 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.
* client: increase software inventory buffer sizeJose M. Guisado2023-04-201-1/+1
| | | | | | | | | | | | 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.
* Log ogClient sessions in ogagent.logv1.2.1Javier Sánchez Parra2022-11-021-4/+41
| | | | | Otherwise, administrators can not read the logging history from WebConsole.
* #915 List all database images.Javier Sánchez Parra2022-07-071-3/+1
| | | | | | | | | | | | 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.
* #915 Add POST /repository/deleteJavier Sánchez Parra2022-07-011-0/+62
| | | | | | | | | | | | | This method deletes a repository from the database. Request: POST /repository/delete { "id": "10" } Response: 200 OK
* #915 Add POST /repository/addJavier Sánchez Parra2022-07-012-0/+71
| | | | | | | | | | | | | | This method adds a new repository to the database. Request: POST /repository/add { "name": "Repository 1", "ip": "192.168.56.10" } Response: 200 OK
* #915 Extend GET /repositories with param idJavier Sánchez Parra2022-06-231-2/+5
| | | | | | | | | | | | | | | | | | | | | | 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")
* #915 Fix missing id on image creationJavier Sánchez Parra2022-06-201-0/+1
| | | | | | | | | | | 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")
* #915 Use the repository id on image listJavier Sánchez Parra2022-06-202-9/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 } }
* #915 Use the repository id on image creationJavier Sánchez Parra2022-06-203-56/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* #1074 rest: set_mode: add support for different ogserver addressesJavier Sánchez Parra2022-06-012-1/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* #915 Set repository on image creationJavier Sánchez Parra2022-05-262-3/+46
| | | | | Assign to the image the repository indicated in the JSON body instead of a default one.
* #915 Extend GET /images function with the repository IPJavier Sánchez Parra2022-05-262-2/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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" } ] }
* #915 Add API GET /repositoriesJavier Sánchez Parra2022-05-261-0/+60
| | | | | | | | | | | | | | | | | | | | | | 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" } ] }
* #915 Fix conditional jump depending on uninitialised valueJavier Sánchez Parra2022-05-181-1/+1
| | | | | | | | | | | | | | | | | | 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")
* #915 Add last_cmd to GET /clients APIJavier Sánchez Parra2022-05-183-2/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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" } } ] }
* #915 Add support for link speed in the refresh responseJavier Sánchez Parra2022-05-091-0/+6
| | | | | | | | 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.
* #915 Set boot mode to ogLive on client creationJavier Sánchez Parra2022-03-281-0/+8
| | | | Otherwise, users have to use POST /modes to make clients bootable.
* #915 Remove template_name from og_set_client_modeJavier Sánchez Parra2022-03-281-43/+5
| | | | This argument is not needed for setting clients' boot mode.
* #915 add seconds since ogserver has been launchedOpenGnSys Support Team2022-03-253-1/+10
| | | | | | | | | | | | 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 */ }, [...]
* #915 Add GET /stats REST requestJavier Sánchez Parra2022-03-141-0/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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 */ } }
* #1065 og_client_status compatible with webconsoleJose M. Guisado2022-02-021-3/+3
| | | | | | | | | 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
* #1043 check for WoL pending confirmation logic only for clientOpenGnSys Support Team2022-01-211-4/+4
| | | | REST API request does not need to perform a list lookup on the wol list.
* #915 release existing client on reconnectionsOpenGnSys Support Team2022-01-213-12/+32
| | | | | Trasient network problems might result in duplicated clients, drop client object if it already exists before creating a new one.
* #915 remove temporary file to store shell outputOpenGnSys Support Team2022-01-184-44/+10
| | | | | Remove legacy behaviour, store it in the client object instead of a temporary file.
* #915 Initialize group when adding a new client to DBJavier Sánchez Parra2022-01-171-1/+2
| | | | Other methods expect not NULL clients' group.
* #1067 fix use-after-free in deliver pending commandOpenGnSys Support Team2021-12-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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)
* #915 consolidate WoL sender functionOpenGnSys Support Team2021-12-226-100/+74
| | | | | | | | 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.
* #915 remove shim code to update database after image restore commandOpenGnSys Support Team2021-12-223-63/+26
| | | | Make direct call to dbi API to update database instead.
* #915 remove dead code in ogAdmLibOpenGnSys Support Team2021-12-222-50/+1
| | | | Remove declarations that are not used anymore in ogAdmLib.
* #915 Remove useless WoL shim codeOpenGnSys Support Team2021-12-203-50/+43
| | | | | | | 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().
* #915 Add POST /oglive/set REST requestJavier Sánchez Parra2021-12-171-0/+114
| | | | | | | | | | | | | | | | | | | 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
* #1065 split og_status_session_toggleJose M. Guisado2021-12-031-9/+22
| | | | | | | | | | | 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.
* #1065 Add support for client eventsJose M. Guisado2021-12-013-1/+78
| | | | | | | | 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.
* #915 Add folders to scopeJavier Sánchez Parra2021-11-261-31/+285
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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": [] } ] } ] }
* #1043 fix timeout refreshOpenGnSys Support Team2021-11-232-18/+15
| | | | | as described by man(3) ev, to make it work with ev_timer_again() otherwise timer might not ever expire.
* #1065 client: add support for ogclient win stateJose M. Guisado2021-11-173-2/+9
| | | | | | | | | 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)
* #1065 client: add support for ogclient linux stateJose M. Guisado2021-11-173-0/+11
| | | | | | | | | | 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.
* #1064 revisit error handling from ogClientOpenGnSys Support Team2021-11-122-14/+73
| | | | | | | | | | | | | | | | | | | | 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.
* #1042 incorrect initialization of software profiles arrayOpenGnSys Support Team2021-10-201-2/+3
| | | | | | 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.
* #915 Fix create image payload parsingJose M. Guisado2021-10-192-12/+11
| | | | | | | | | | | | | | | | | 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.