| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Append oglive info at the end of the array of the "oglive" entry.
Each entry defines the name of the oglive and the creation date.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
fix incorrect error report when updating table.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 a new checksum attribute to GET /images, extend database to add a new
checksum field to images table.
|
|
|
|
|
| |
Add a new table to store the image file that are stores in the client cache.
Use bigint to store file size in bytes.
|
|
|
|
|
|
| |
Use permissions and last update from client.
update src/schema.c to add a new database version.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add foreign key "identornos" from table "entornos" to table
"ordenadores".
A row in table "entornos" represent a valid ogServer address.
Multiple ogServer valid addresses can exist when running several
instances or a single ogServer instance is exposed to different networks.
Can't delete rows in "entornos" table nor update their id (primary
key) if the row has any associated clients ({ON UPDATE/ON DELETE} RESTRICT).
Allows assigning different but valid ogServer IPs to clients.
Enabling support for multiple instances of ogServer (e.g: load balancing) or
exposing a single ogServer instance to different networks (e.g: VLAN).
Look up for the valid ogServer IP of a given client when changing a
client's mode (og_set_client_mode).
Determines valid ogServer IP using a JOIN statement.
JOIN entornos USING(identorno)
Reuses the fetched ip using a statement variable.
@serverip:=entornos.ipserveradm
For example, for a two VLAN setup:
vlan1 ogserver: 192.168.56.10
vlan2 ogserver: 192.168.57.10
The "entornos" table should look like:
identorno ipserveradm ...
--------- ----------- ...
1 192.168.56.10 ...
2 192.168.57.10 ...
And computers in the "ordenadores" table might look like:
idordenador identorno ...
---------- --------- ...
1 1 ...
2 1 ...
3 2 ...
4 2 ...
... ... ...
Additionally, splits the SQL query for better readability.
Co-authored-by: Jose Guisado <jguisado@soleta.eu>
|
|
|
|
|
|
| |
/usr/bin/ld: src/schema.o:/home/soleta/opengnsys/ogServer/src/schema.c:50: multiple definition of `ogconfig'; src/main.o:/home/soleta/opengnsys/ogServer/src/main.c:31: first defined here
collect2: error: ld returned 1 exit status
make: *** [Makefile:411: ogserver] Error 1
|
|
|
|
|
|
| |
Simplify database update v3, no need for iteration.
Fixes: 12d8fff (#1037 Add disk type)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Update license header in files.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Add foreign keys (version 1 introduced innoDB as default db engine)
allowing cascade deletions for some tables:
- perfilessoft_softwares
If a software profile or a software component is deleted, the
corresponding row in this table will be deleted too.
- ordenadores_particiones
If a computer or a partition is deleted from the DB, delete the
corresponding row inside this table.
- aulas
If the center the room is in is removed, delete the room too.
- ordenadores
If the room in which a computer is in is removed, the computer
will be deleted accordingly.
We should take into account that this schema superseeds some code
regarding deletions inside WebConsole that probably are not needed any
more, at least for the tables mentioned.
(See admin/WebConsole/gestores/relaciones/*.php in OpenGnsys repo)
|
|
This patch adds database schema management capabilities to ogServer:
- ogServer now tracks the version of its database schema, if no version
is detected, creates a 'version' table with a single row starting at 0.
- ogServer can upgrade its database schema to a newer version if
detected. (ogServer ships required SQL commands to do so)
If ogServer is unable to upgrade the schema at startup (if needed be) it
*will not* start.
Defines schema update v1 which upgrades database engine tables of
ogServer database (usually named 'ogAdmBD') from myISAM to innoDB.
|