Remove legacy "echo" parameter.
Add boolean "inline" parameter to determine if the execution is
an inline command or a predefined script in /opt/opengnsys/shell/
Extend database table ordenadores_particiones to add new "used_size" and "free_size" fields.
FIELD TYPE
| tamano | bigint |
| uso | tinyint |
| used_size | bigint |
| free_size | bigint |
"tamano" is the field storing the total size of the partition.
"uso" is a field storing the integer percentage of use, it is preserved for backwards compatibility with scritps that access the database.
"used_size" and "free_size" contain the used and free partition
size in bytes.
Old response from ogClient for /cache/delete, /cache/fetch
and /image/restore:
{
'cache': [
{'name': 'windows.img', 'size': 2432370213, checksum: '5d4dcc677bc19f40a647d0002f4ade90'},
{'name': 'linux.img', 'size': 243234534213, checksum: '3eb22f888f88a55ad954f55644e1192e'}
]
}
New response:
{
'cache': {
'used_size': 4520232322423,
'free_size': 48273465287452945,
'images': [
{'name': 'windows.img', 'size': 2432370213, checksum: '5d4dcc677bc19f40a647d0002f4ade90'},
{'name': 'linux.img', 'size': 243234534213, checksum: '3eb22f888f88a55ad954f55644e1192e'}
]
}
}
Parse the new "free_size" and "used_size" fields of each partition data in the response payload of /refresh
Parse "free_size" and "used_size" fields of the cache data in the reponse payload of /image/restore, /cache/delete and /cache/fetch
Replace "used_size" field of GET /client/setup with the value
of the new database field "used_size"
Add GET /efi request to obtain information about the client's
boot entries.
Field inside the /refresh payload
'efi': {
'entries': [
{
"order": 0,
"name": "Boot0000",
"active": false,
"description": "grub"
},
{
"order": 1,
"name": "Boot0001",
"active": true,
"description": "UEFI: PXE IP4 Realtek PCIe GBE Family Controller"
}
]
}
If the client is not a EFI system it won't add the 'efi' field.
If an entry is not in the boot order it won't have the 'order' field.
GET /efi resquest payload structure:
{
'clients': ['10.141.10.21', '10.141.10.22']
}
GET /efi response's structure:
{
'clients': [
{
'ip': '10.141.10.21',
'entries': [
{
"order": 0,
"name": "Boot0000",
"active": false,
"description": "grub"
},
{
"order": 1,
"name": "Boot0001",
"active": true,
"description": "UEFI: PXE IP4 Realtek PCIe GBE Family Controller"
}
]
},
{
'ip': '10.141.10.22',
'entries': []
}
]
}
The client with ip 10.141.10.22 is a BIOS system.
If an entry does not appear in the boot order it won't have the
'order' field.
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.
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: 86ccc3c2e8 ("#915 Add POST /repository/add")
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.
Commit 141b0797e1 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.
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) {
| ^~~~~~
These function declarations belong to json.h:
int og_json_parse_partition_setup(json_t *element, struct og_msg_params *params);
int og_json_parse_create_image(json_t *element, struct og_msg_params *params);
int og_json_parse_restore_image(json_t *element, struct og_msg_params *params);
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.
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.
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.
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"}
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.
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".
This patch implements HTTP POST /modes request which can change the mode of any
particular scope.
Request: POST /modes
{
"scope": {"id": 1,
"type": "computer"},
"mode": "pxe"
}
Response: 200 OK
Some universities have computers in a different subnet where the
ogServer is, but ogServer WoL functionality only supported to send
packet to its own subnets. This commit solves this.
Now ogServer sends two WoL packets per client, one with the broadcast
address of the interface indicated in the config file, the other with
the broadcast address calculated with the address and netmask of the
client.
To ensure that the second WoL works correctly you must configure
correctly the IP and netmask of the clients. Also, you have to configure
the network of your organization to route WoL packet to the correct
subnet.
OpenGnSys Support Team
Alejandro Sirgo Rica
Jose M. Guisado
Javier Sánchez Parra
Roberto Hueso Gómez