summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* rest: Change room field 'group' to 'folder_id'Javier Hernandez2024-01-112-4/+4
| | | | | | | | 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.
* rest: update og_uri_handle with new folder commandsOpenGnSys Support Team2024-01-112-0/+4
| | | | Add folder/add and folder/delete, otherwise logging shows "unknown"
* rest: Support adding clients inside folderJavier Hernandez2024-01-112-6/+12
| | | | | | Add support for adding clients that are inside a folder. Add new folder_id field, if zero it means computer is not in a folder.
* rest: Add support for deleting foldersJavier Hernandez2024-01-101-0/+132
| | | | | | | | | | 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.
* rest: Add support for adding foldersJavier Hernandez2024-01-092-0/+158
| | | | Add support for adding computer folders and room folders.
* rest: Use mask to differentiate folder typesJavier Hernandez2024-01-081-4/+10
| | | | | | | | | | | | | | 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)
* rest: allow to set boot mode in client/updateOpenGnSys Support Team2023-12-211-2/+16
| | | | | Allow to specify .boot field and call set_client_mode() to update the boot mode.
* rest: missing POST /image/update in syslogOpenGnSys Support Team2023-12-212-0/+2
| | | | | | Update it so it shows in syslog, instead of unknown: Dec 19 18:31:18 ogserver ogserver[1133]: 127.0.0.1:36538 POST /unknown clients=150.128.34.25
* rest: cannot fail with image/create if it existsv1.2.5-8OpenGnSys Support Team2023-12-191-7/+0
| | | | | | legacy web console uses this REST API to refresh an existing image. Relax check not to break things.
* rest: add POST image/updateOpenGnSys Support Team2023-12-192-1/+40
| | | | add explicit API to update an image
* rest: no assumption on description field in create/imagev1.2.5-7OpenGnSys Support Team2023-12-193-24/+42
| | | | | | | | | 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.
* rest: log failed to delete entry from tableOpenGnSys Support Team2023-12-181-0/+12
| | | | add logging to report failure to remove entry.
* rest: do not exit() if execlp() failsv1.2.5-6OpenGnSys Support Team2023-12-151-1/+1
| | | | | execlp() should not ever fail, but if it ever happens, return -1 instead of exitting this daemon.
* rest: do not report error when removing image fileOpenGnSys Support Team2023-12-151-9/+2
| | | | this file might be in a different repository, this is best effort.
* client: parse permissions and lastupdate in /image/create response from clientv1.2.5-5OpenGnSys Support Team2023-12-124-28/+54
| | | | | | Use permissions and last update from client. update src/schema.c to add a new database version.
* client: stub to parse size field in /image/create response from clientOpenGnSys Support Team2023-12-121-3/+6
| | | | | Still incomplete, src/schema.c needs to be update to add a new field to the 'imagenes' table in the database.
* rest: expose description in GET /imagesOpenGnSys Support Team2023-12-121-1/+6
| | | | add .description field to json.
* dbi: og_computer_get_info() uses netmask field in 'room' tablev1.2.5-4OpenGnSys Support Team2023-11-301-2/+2
| | | | | | | | | | | 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.
* rest: add GET /room/infoOpenGnSys Support Team2023-11-304-0/+116
| | | | | | | 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 }
* rest: fix client/info maintenance fieldOpenGnSys Support Team2023-11-301-1/+1
| | | | | | Use computer.maintenance instead of computer.name. Fixes: af47a082adb1 ("#1004 Add GET /client/info HTTP REST method")
* rest: add POST repository/updatev1.2.5-3Javier Hernandez2023-11-242-0/+83
| | | | | | | | | | 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" }'
* core: remove useless log when ogClient connects to serverOpenGnSys Support Team2023-11-231-9/+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.
* rest: revisit loggingOpenGnSys Support Team2023-11-232-4/+190
| | | | | | | | | | | | | | | | 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.
* rest: fix WoL handlingOpenGnSys Support Team2023-11-231-13/+22
| | | | | | | | | | 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: e4cb91b5f660 ("#990 wol: migrate mac and netmask query to ogServer")
* rest: set center in /repository/addOpenGnSys Support Team2023-11-231-1/+3
| | | | | Set it to 1, ogCP and ogCLI never use this, and this REST API is never used by the old web console.
* rest: remove dead code in /repository/addOpenGnSys Support Team2023-11-231-27/+3
| | | | Remove unused code in this request and do not assume center id.
* rest: add /client/updateJavier Hernandez2023-11-231-0/+127
| | | | | Add POST client/update request to update client, this is identified by its ip address, with the data provided in the payload.
* main: use etc folder instead of cfg to store .json configuration fileOpenGnSys Support Team2023-11-141-1/+1
| | | | debian packages use etc, so update source code to use this folder too.
* core: restrict rest API to 127.0.0.1OpenGnSys Support Team2023-11-143-5/+11
| | | | | Until there is TLS support for this, frontend and ogserver needs to be in the same box by now.
* rest: Check valid bootmodeJavier Hernandez2023-11-061-0/+29
| | | | | | 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.
* rest: extract og_get_boot_modes from og_cmd_get_modes()Javier Hernandez2023-11-061-22/+62
| | | | | | 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.
* rest: Add error check to delete commandsJavier Hernandez2023-11-061-0/+31
| | | | | | | | | | | | | | | | | | | 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
* INSTALL: generate 'configure' scriptOpenGnSys Support Team2023-10-301-0/+4
|
* add INSTALL fileOpenGnSys Support Team2023-10-301-0/+18
|
* rest: use method not found instead of bad request for /clients requestsOpenGnSys Support Team2023-10-191-1/+1
| | | | | /clients says bad request for unsupported method, use correct error report.
* rest: extend /repository/addv1.2.5Jose M. Guisado2023-10-112-7/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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"}
* src: move og_repository to dbi.hJose M. Guisado2023-10-103-7/+12
| | | | | | | | | | 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: 86ccc3c2e8377623 ("#915 Add POST /repository/add")
* rest: add POST /client/repoJose M. Guisado2023-10-101-0/+105
| | | | | | | | | | | | | | | | 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
* rest: fix sql typo in og_set_client_modeJose M. Guisado2023-09-291-1/+1
| | | | | | | | | | | | | | 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: e080fd5526949a5615ae391ea9dda8b70c95f345 (rest: add "server=" boot param in set client mode)
* schema: fix bug when og_dbi_open cannot open a connectionJose M. Guisado2023-09-282-5/+5
| | | | | | | | | | | | 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.
* rest: add "server=" boot param in set client modev1.2.4Jose M. Guisado2023-08-281-0/+1
| | | | | | | 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.
* 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.