summaryrefslogtreecommitdiffstats
path: root/src/rest.c
Commit message (Collapse)AuthorAgeFilesLines
* #915 Remove useless WoL shim codeOpenGnSys Support Team2021-12-201-13/+41
| | | | | | | 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 Add support for client eventsJose M. Guisado2021-12-011-0/+4
| | | | | | | | 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": [] } ] } ] }
* #1065 client: add support for ogclient win stateJose M. Guisado2021-11-171-0/+2
| | | | | | | | | 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-171-0/+2
| | | | | | | | | | 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.
* #915 Fix create image payload parsingJose M. Guisado2021-10-191-12/+10
| | | | | | | | | | | | | | | | | 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.
* #915 Add POST /image/delete methodJavier Sánchez Parra2021-10-041-0/+90
| | | | | | | | | | 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" }
* #1061 add timeout to pending scheduled commandsJose M. Guisado2021-09-061-0/+1
| | | | | | | | | | | 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.
* #1051 Initialize task_id once in og_cmd_post_schedule_commandJose M. Guisado2021-07-221-7/+7
| | | | | | | | 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.
* #1052 Populate session column when adding actionsJose M. Guisado2021-07-221-3/+13
| | | | | | | | | | | | | | | | 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.
* #1051 Fix command schedule for several clientsJose M. Guisado2021-07-211-3/+24
| | | | | | | | | | | | | 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.
* #915 Add POST /task/add methodJavier Sánchez Parra2021-07-011-0/+162
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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) { | ^~~~~~
* #915 Add POST /procedure/update methodJavier Sánchez Parra2021-06-291-0/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix procedure id retrieving in steps creationJavier Sánchez Parra2021-06-291-3/+2
| | | | | | Otherwise, procedure id is always zero. Fixes: 1fdb7e6d1cf0709b1079b2d9990c0d53d8740461
* #915 Filter queued commands by idJavier Sánchez Parra2021-06-161-1/+1
| | | | | | | | | | | | 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 d9b6aadf66655a6713bcacb25d2ea6b01c07e3b5.
* #915 Add POST /procedure/run methodJavier Sánchez Parra2021-06-151-0/+97
| | | | | | | | | | | | | | | | | | | 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
* #915 Add procedure/deleteJose M. Guisado2021-06-111-0/+62
| | | | | | | | | | | | 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.
* #915 Revert filtering actions by id to "sesion" in og_dbi_queue_commandJose M. Guisado2021-06-101-1/+1
| | | | | | | | | | | | | | 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 https://github.com/opengnsys/OpenGnsys/blob/c17ffa5d032a82e8eca61481dd8a8adb8b3fc5b1/admin/WebConsole/rest/remotepc.php#L188 Revert said change as long as remotepc keeps such behavior.
* #915 Add commands and procedures to procedure creationJavier Sánchez Parra2021-06-101-3/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* #915 Add schedule/commandJose M. Guisado2021-06-091-9/+210
| | | | | | | | | 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.
* #942 Add POST /procedure/add methodJavier Sánchez Parra2021-05-311-0/+90
| | | | | | | | | | | | | | | | | | | | | | 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.
* Add REST POST /room/delete methodJavier Sánchez Parra2021-05-101-0/+59
| | | | | | | | | | | | | | | | | 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
* #942 Add REST POST /center/delete methodJavier Sánchez Parra2021-05-101-0/+59
| | | | | | | | | | | | | | | | | 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
* #995 Add link speed parsing to client probe responseJose M. Guisado2021-05-041-0/+1
| | | | | | If a probe response contains speedinformation, parse and store it inside the client struct. Speed is interpreted as an unsigned integer representing Mbit/s.
* ogServer is AGPLv3+OpenGnSys Support Team2021-05-041-2/+3
| | | | Update license header in files.
* #1043 don't create wol entries when client is connectedJose M. Guisado2021-04-291-0/+3
| | | | | | | | | | | | 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.
* #1043 add WOL_SENT stateOpenGnSys Support Team2021-04-291-1/+68
| | | | | WOL_SENT tells that WakeOnLan was sent to computer, after 60 seconds, if computer does not boot, this state is released.
* #1043 add function to append client to json treeOpenGnSys Support Team2021-04-291-18/+28
| | | | og_json_client_append() adds a client objet to the json tree.
* #915 Add /room/add POST methodJavier Sánchez Parra2021-04-201-0/+123
| | | | | | | | | | | | | | | | | | | | | | | Adds POST method to add rooms (labs), required payload parameters are name, netmask and center; any additional attributes are optional. Required JSON: { "center": 0, "name": "classroom10", "netmask": "255.255.255.0" } Full JSON: { "center": 0, "name": "classroom11", "netmask": "255.255.255.0", "group": 0, "location": "First floor", "gateway": "192.168.56.1", "ntp": "hora.cica.es", "dns": "1.1.1.1", "remote": True } This commit also adds unit tests for /room/add POST method.
* #915 increase maximum API REST response sizeJavier Sánchez Parra2021-04-191-1/+1
| | | | | GET /scope could generate a response larger than 64 Kbytes. Rise the maximum API REST response size to 256 Kbytes.
* #915 fix "response too large" error pathJavier Sánchez Parra2021-04-191-12/+9
| | | | | Otherwise, ogServer sends "200 OK" after a "500 Internal Server Error error" response.
* #915 validate response json sizeJavier Sánchez Parra2021-04-191-15/+65
| | | | | | | | 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
* #915 Add /center/add POST methodJose M. Guisado2021-04-081-0/+84
| | | | | | | | | 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"}
* #915 Add GET /oglive/test REST API functionJavier Sánchez Parra2021-04-051-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* #1004 Add GET /images testDiego Crespo Quinta2021-03-301-1/+1
| | | | Fix incorrect error if json is missing.
* #990 fix crash in wol with malformed IP addressOpenGnSys Support Team2021-03-301-1/+4
| | | | | | | | | | | | | | | | | | ==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.
* #990 Use lab netmask to calculate broadcast addressJavier Sánchez Parra2021-03-171-6/+15
| | | | | | | | | | | | 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.
* #997 Fix og_tm_hours_maskJose M. Guisado2021-03-151-2/+2
| | | | | | | | | | | | | | | | | | 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")
* #997 Use stale check flag in schedule/updateJose M. Guisado2021-03-151-1/+19
| | | | | | | | | | | | | 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")
* #942 return error if API REST parser failsOpenGnSys Support Team2021-03-151-38/+29
| | | | | Return error if json parser fails, ignore unknown json attributes. Missing uninitialized error value.
* #997 Remove unnecessary strdup in og_dbi_queue_*Jose M. Guisado2021-03-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | | 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.
* #997 Set stale check flag when processing schedule/createJose M. Guisado2021-03-111-1/+68
| | | | | | | | | | | 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.
* #1004 Fix memleak in og_cmd_imagesJose M. Guisado2021-02-241-1/+1
| | | | | | | | | | 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.
* #942 memleak in og_send_request()OpenGnSys Support Team2021-02-231-0/+2
|
* #942 memleak in error pathOpenGnSys Support Team2021-02-231-87/+172
| | | | | | Fix memleaks in error path. json_decref() checks for null objects.
* #990 Fix og_cmd_wol memory leakJose M. Guisado2021-02-231-0/+6
| | | | | | | Allocated strings using dbi_result_get_string_copy are not being freed after using them. This patch fix this memory leak. Fixes: e4cb91b ("#990 wol: migrate mac and netmask query to ogServer")
* #1019 UAF in schedule runOpenGnSys Support Team2021-02-231-1/+4
| | | | Otherwise accessing IP address results in use-after-free.
* #1019 Fix queued Wake on LANJavier Sánchez Parra2021-02-221-0/+28
| | | | | | | | | | | | | UMA and UPV report that Wake on LAN command (in queue mode) does not work. We improved WoL command, now ogServer calculates the broadcast address of the network to which the client belongs. To calculate this address ogServer needs the IP and the netmask of the client. We updated ogServer to retrieve the netmask from the database in non-queue mode, but we forgot to add this in queue mode. This patch adds netmask retrieving to queued WoL.
* #990 wol: migrate mac and netmask query to ogServerJose M. Guisado2021-02-151-69/+41
| | | | | | | | | | | | | ogServer WoL rest function is expecting ip, mac and netmask from the request's payload. This makes the client responsible for providing such data. ogServer should be the owner of the database, this patch adjusts the parameter expected in a request payload for /wol action so clients only need to provide the ips and wol type (broadcast, unicast). Database is expected to contain valid data for the netmask and mac of target computers.