summaryrefslogtreecommitdiffstats
path: root/src/client.c
Commit message (Collapse)AuthorAgeFilesLines
* client: update cache after image/restorev1.2.5-11Alejandro Sirgo Rica2024-05-301-0/+2
| | | | | | | | | | | | | | | | | | | | Update the database with the new cache contents sent by the client after an image/restore operation. Resquest response structure: { ... 'cache': [ {'name': 'windows.img', 'size': 2432370213, checksum: '5d4dcc677bc19f40a647d0002f4ade90'}, {'name': 'linux.img', 'size': 243234534213, checksum: '3eb22f888f88a55ad954f55644e1192e'} ] ... } Parse the contents of the 'cache' field to update the data of the client's cache in the database. This is one of the required changes the make cache/list coherent and prevent cache desync between the server and clients.
* rest: add cache/deleteAlejandro Sirgo Rica2024-05-301-0/+56
| | | | | | | | | | | | | | | | | | | Add POST cache/delete request to request deletion of images in the client's cache. Resquest payload structure: { 'clients': ['10.141.10.21', '10.141.10.22'] 'images': ['windows.img', 'linux.img'] } The clients listed in the 'clients' field will receive a cache/delete POST request with the 'clients' field removed and only containing 'images' from the payload received by the server. Each client will try to delete as many images as available in their cache from the list of files in 'images'. The clients will give response with the contents of the cache so the server can update the database.
* client: store image cache data in databaseAlejandro Sirgo Rica2024-05-301-7/+60
| | | | | | | | | | | | | | | | | | | | | | Parse the 'cache' field of the refresh payload sent by the clients. Cache field structure in the payload: { ... 'cache': [ {'name': 'windows.img', 'size': 2432370213, checksum: '5d4dcc677bc19f40a647d0002f4ade90'}, {'name': 'linux.img', 'size': 243234534213, checksum: '3eb22f888f88a55ad954f55644e1192e'}, ] ... } Store that data in the 'cache' table of the database so it can be obtained later on. The table contains the following fields: - clientid: the numeric identifier of the client. - imagename: name of the image in cache. - size: size in bytes of the image in cache. - checksum: checksum of the image in cache.
* src: replace old function to update image informationOpenGnSys Support Team2024-05-291-7/+91
| | | | replace old legacy code, no functional changes are intended.
* client: parse permissions and lastupdate in /image/create response from clientv1.2.5-5OpenGnSys Support Team2023-12-121-5/+11
| | | | | | 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.
* client: harden og_resp_refreshJose M. Guisado2023-06-071-1/+5
| | | | | | | | | | | | | 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 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-181-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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 remove temporary file to store shell outputOpenGnSys Support Team2022-01-181-12/+2
| | | | | Remove legacy behaviour, store it in the client object instead of a temporary file.
* #915 remove shim code to update database after image restore commandOpenGnSys Support Team2021-12-221-21/+26
| | | | Make direct call to dbi API to update database instead.
* #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-011-1/+72
| | | | | | | | 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.
* #1065 client: add support for ogclient win stateJose M. Guisado2021-11-171-2/+6
| | | | | | | | | 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/+8
| | | | | | | | | | 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-121-11/+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.
* #1037 Add disk typeJavier Sánchez Parra2021-05-261-2/+2
| | | | | | | Add ogServer support for parsing and storing in the DB disk type data from ogClient refresh response. See also commits with #1037 in ogClient and WebConsole repo.
* #980 ignore unknown attributesOpenGnSys Support Team2021-05-041-14/+0
| | | | If ogClient sends an unknown attribute, ignore it.
* #995 Add link speed parsing to client probe responseJose M. Guisado2021-05-041-0/+6
| | | | | | 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.
* #980 memleak in json ogclient pathOpenGnSys Support Team2021-02-231-0/+1
|
* #1008 Restore support for 4 disks and 16 partitionsJavier Sánchez Parra2020-11-181-14/+16
| | | | | | | | ogServer expects to receive information of 1 disk and 4 partitions from ogClient. Previous ogServer versions support several disks and partitions. Add ogServer support for 4 disks and 16 partitions.
* #988 remove legacy configurationOpenGnSys Support Team2020-10-071-6/+7
| | | | | Use og_server_cfg everywhere. Convert port to string to make it easy for the dbi API since it expects a string. Remove legacy example configuration file.
* #941 Use fixed length strings in og_computer and og_dbi_get_computer_infoRoberto Hueso Gómez2020-10-061-14/+1
| | | | | | This patch is a refactor for og_computer and og_dbi_get_computer_info. It now uses fixed lenght strings to make it more reliable and avoid errors if the DB is not returning a null ended string.
* #1004 Fix integer overflow in datasizeJavier Sánchez Parra2020-09-291-1/+1
| | | | ogClient datasize is now in bytes, update format to fix a possible overflow.
* #941 Extend og_dbi_get_computer_info(...)Roberto Hueso Gómez2020-09-221-5/+18
| | | | | | For the strings in og_computer we do not need to know the max size in advance but instead we need to free up memmory using og_dbi_free_computer_info(...) function.
* #941 pass og_dbi to og_dbi_get_computer_info()OpenGnSys Support Team2020-09-181-40/+51
| | | | Reuse the existing dbi handler, instead of opening a new one.
* #941 move og_dbi_get_computer_info() to dbiOpenGnSys Support Team2020-09-181-59/+0
| | | | Move this function to the dbi.{h,c} files.
* #1004 Handle new fields in /image/create responseJavier Sánchez Parra2020-09-101-3/+48
| | | | | | | | | | | | | | | | | | | | | | | | ogClient now includes more information regarding the new image. This patch modifies ogServer to support new elements sent in ogClient /image/create response and store them in the database. Example of new /image/create response: { "disk": "1", "partition": "1", "code": "131", "id": "1", "name": "ubuntu", "repository": "192.168.56.10", "software": "Ubuntu 18.04.5 LTS \naccountsservice 0.6.45\n...", "clonator": "PARTCLONE", "compressor": "LZOP", "filesystem": "EXTFS", "datasize": 2100000 } New fields are "clonator", "compressor", "filesystem" and "datasize".
* #971 rename sources folder to srcOpenGnSys Support Team2020-06-261-0/+689
Use the same folder as in ogClient.