use context to store disk, partition and image id that is requested to client
and handle refresh response from ogclient to update database, otherwise, an
explicit refresh from web frontend is required.
Remove 'is_default' column from 'lives' database table and add
column 'priority' of type INT. This new value can store a priority
value but the actual design only stores 1 or 0.
Update GET oglive/list to use the new 'priority' database value.
Add POST oglive/default.
Set the database column 'priority' to 1 if the new default
exists in the database. Set the others to priority 0.
Modify legacy ogliveinfo.json if the new default coresponds to a
live not found in the database. Edit the field 'default' of the
file's json.
Add API to register and delete oglives from the database.
POST /oglive/add
Register an installed oglive in the database, if the entry already
exists update its creation date.
Example request payload:
{"name": "ogrelive-6.1.0-26"}
POST /oglive/delete
Remove an installed oglive from the database
Example request payload:
{"name": "ogrelive-6.1.0-26"}
Add last client command context that is used in the request to client.
This allows to remove the stub image entry in the database in case that the
image creation fails.
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.
Add POST cache/fetch request to request download of images in
the client's cache.
Resquest payload structure:
{
'clients': ['10.141.10.21', '10.141.10.22']
'image': 'windows.img'
'type': 'TIPTORRENT'
'repository': '12.141.10.2'
}
The clients listed in the 'clients' field will receive a
cache/fetch POST request with the payload received by the server
without the 'clients' field.
The clients respond with the contents of their cache so the server
can update the database.
Allow to restrict image to scope:
POST /image/restrict
{ "image" : 49, "scopes" : [ 1,3 ] }
response: 200 OK
This restricts image with ID 49 to scopes 1 and 3.
You can also fetch the current list of restrictions:
GET /image/restrict
{ "image" : 49 }
response: 200 OK
{ "image" : 49, "scopes" : [ 1,3 ] }
Existing limitations in this interface:
- Only restriction of image to center is possible at this moment.
- This is only used by ogCP to validate if this is possible, no existing code
in the ogserver uses this to restrict POST image/restore.
This is a usability feature.
Add GET shell/list request to obtain the list of scripts available
in /opt/opengnsys/client/shell
Resquest payload structure: no paylaod
Response's structure:
{
'scripts': ['script', 'script2']
}
Add URI to allow a POST request to move clients to a new room/folder.
Request POST /client/move:
{
"clients": [
"192.168.56.11"
],
"room": 10,
"folder_id": 0,
}
If folder_id is zero then that means computer is not stored in a folder.
Add URI to allow a GET request to obtain info about a center (name, id
and comment of the center as of now).
To use this uri, simply send a GET request with a json containing the id
of the center whose info needs to be consulted:
curl -X GET -H "Authorization: $API_KEY" http://127.0.0.1:8888/center/info -d '{"id":1}'
based on work from Javier Hernandez.
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.
Add GET cache/list request to obtain information about the client's
cache.
Resquest payload structure:
{
'clients': ['10.141.10.21', '10.141.10.22']
}
Response's structure:
{
'clients': [
{
'ip': '10.141.10.21',
'cache_size': 2894572304857,
'images': [
{name:'img1', size: 87283902343, checksum: '5d4dcc677bc19f40a647d0002f4ade90'},
{name:'img2', size: 894572304857, checksum: '3eb22f888f88a55ad954f55644e1192e'}
]
},
{
'ip': '10.141.10.22',
'cache_size': 49872839023434,
'images': [
{name:'img2', size: 894572304857, checksum: '3eb22f888f88a55ad954f55644e1192e'}
]
}
]
}
Both 'cache_size' and the values in 'image_sizes' are provided
as bytes.
If a client has no cache partition the payload will include it as:
...
{
'ip': '10.141.10.22',
'cache_size': 0,
'images': []
}
...
Add uri to allow the change of a room's properties, such as 'name',
'gateway' or 'netmask'
Reject update if new name is already being used by any room of the
center where the room is located
Add uri to allow the change of a center's properties such as 'name' or
'comment'
Refuse to update center's name if that name is already in use by another
center. This is because a center should not share name with another one.
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 }
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" }'
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.
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.
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.
"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"
}
}
]
}
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.
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)
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.
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.
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);
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.
If a probe response contains speedinformation, parse and store
it inside the client struct. Speed is interpreted as an unsigned
integer representing Mbit/s.
OpenGnSys Support Team
Alejandro Sirgo Rica
Javier Hernandez
Jose M. Guisado
Javier Sánchez Parra