use first repository/server in the list in case no specific repository/server
is found in the same network, this is a fallback that works if repository/server
is reachable through gateway.
infer server IP for a given client. User does not have to attach a client to
a given server IP anymore through ordenadores.identorno.
this simplifies previous work to allow a server to have more than one IP address
a0a3470682 ('#1074 rest: set_mode: add support for different ogserver addresses')
44745a3f22 ('rest: add POST client/server method')
POST /client/server is removed, it is only used by ogcli and explicit association
between server and client is not required.
server_id json attribute is also removed in GET client/info.
Repository can have more than one single IP address.
* Add alias field to database to represent the extra IPs that are attached to
the repository, update schema and add version 9.
* Use og_dbi_get_repository_ip() to infer the repository IP address.
* Add helper functions (src/repo.c) to build a list of repositories and update
rest API to use it.
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.
escape non-ascii characters in json otherwise ogclient len() and Content-Length:
report a mismatch when utf-8 representation is used in any of the string fields.
For consistency, enable this flag too for json dumps that are consumed by ogcp
and ogcli.
If repository_id json field is provided, use it to narrow down the image lookup.
After this, search use this same repository ID to fetch the IP address.
Old web console may not provide repository_id, infer it from the image name.
Always set image id field for creation and update.
call og_delete_tftpboot_file for both pxe configuration files
in client/delete and client/update.
Delete files for client/update only if the MAC changes.
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.
Implement most of the code from the script setclientmode into
ogServer to improve error handling and logs.
Use a reduced version legacy script to replace the contents of
the base PXE template. This file is now called updategrubprofile.
Add updategrubprofile to the new extras/ folder.
Create BIOS and UEFI files for PXE boot configuration. Each file
is located in a different directory and requires a different name
pattern.
-BIOS-
File format:
/opt/opengnsys/tftpboot/menu.lst/01-XX-XX-XX-XX-XX-XX
Template dir:
/opt/opengnsys/tftpboot/menu.lst/templates/
-UEFI-
File format:
/opt/opengnsys/tftpboot/grub/01-xx:xx:xx:xx:xx:xx
Template dir:
/opt/opengnsys/tftpboot/grub/templates/
Revisit 6cbe69e89e ("rest: add cmd to shell/output") to reject response with
no 'cmd' field, otherwise strdup() crashes when dealing with NULL string.
Set retcode to zero, otherwise this value remains uninitialized if no retcode
json field is provided by the client.
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.
Exclude centerid of the center we update from the search of
centers with the same name.
Report when other center have the same name as the one in the
payload of the update request.
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.
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.
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': []
}
...
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.
GET /session only supports for one single client IP address, extend
it to remove this artificial limit.
Add "clients" json attribute which is an alias of the existing "client"
for consistency with other existing endpoints.
When og_cmd_post_center_delete is invoked by the REST API the
images that contain the same id as the center being deleted are
also deleted.
Move the image deletion functionality into its own function called
og_delete_image to prevent code duplication as it is now required
in og_cmd_post_center_delete and og_cmd_delete_image.
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.
Reply with an error if user tries to create a client with a mac that is
already owned by another client
Write to syslog info about the client that owns the mac: client's name,
ip, mac address and room
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.
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.
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)
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.
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.
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" }'
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.
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.
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: e4cb91b5f6 ("#990 wol: migrate mac and netmask query to ogServer")
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.
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.
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
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"}
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")
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
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: e080fd5526
(rest: add "server=" boot param in set client mode)
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.
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.
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,
}
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.
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).
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
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.
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
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.
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: d2c19ef13d ("core: add X-Sequence header support")
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.
OpenGnSys Support Team
Alejandro Sirgo Rica
Javier Hernandez
Jose M. Guisado