RFC: A New Concept for Gluon Config Generation #2238
Comments
lemoer
changed the title
lemoer
changed the title
|
I have mixed feelings regarding an ever open API. Mandatory relying on Javascript for the configmode is likely raising the hurdle for not just a few users. I like a lot about the goal of part two though. |
|
The scope of Netjson is very different from the current Gluon configuration approach. Netjson is a low-level definition of device configuration. The level of detail of Netjson is on par with the OpenWrt uci config. In fact, you can represent almost any possible OpenWrt router configuration in Netjson. In Gluon, we have a different approach. We only allow high-level configuration options like This has two advantages:
If we were to open the way for low-level configuration and officially support it, I think Gluon would become a maintenance hell.
I would like to postpone the discussion of this concern to a later date. This API does not have to be made openly accessible. There are many technical ways to protect it: using HTTPS, SSH tunneling, enabling the API only in configuration mode, exposing it only on a special Lan port, ... However, for the implementation of the API itself, this is not important for now. You can always just put security in front of an HTTP API.
In fact, this is one of the choices to be made. The other option would be to add the REST API as an additional way to configure the node besides the existing |
|
|
Okay, you are right. That there are orthogonal ideas. I would like to focus on the REST API idea first. Some Requirements for the REST API:
Especially REQ4 is challenging to realize, incorporating all the possibilities resulting from REQ1, REQ2 and REQ3. Even more, if we intend to provide a somewhat intuitive API. "Nice To Haves" (NTH) for the REST API:
My Current FeelingCurrently I tend towards implementing NTH1 and NTH2b and towards using something similar to the What I Need From You
|
|
I just created an example how a single JSON resource could look like. It is based on a current image from Freifunk Hannover. The JSON structure is oriented to the current structure of the config-mode web interface. This example can be used for discussion. It gives an overview of which config options we currently support in the web interface. EDIT: Some options have been added. {
"wizard": {
"hostname": "freifunk-foobar",
"mesh-vpn": {
"enabled": true,
"bandwidth_limit": {
"enabled": true,
"up": 40000,
"down": false
}
},
"domain": "burgdorf",
"location": {
"share_location": true,
"lat": 57.0912121,
"lon": 10.2121211,
"altitude": 2.332
},
"contact": "[email protected]",
"is_outdoor_device": false
},
"advanced": {
"remote-access": {
"password": "1337",
"ssh-keys": [
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK4qBzYhG0oXJCAVr5Bgh9dJ2ZqgzsB9oTGZlBn5ZIjO lemoer@orange",
"ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIK4qBzYhG0oXJCAVr5Bgh9dJ2ZqgzsB9oTGZlBn5ZIjO lemoer@orange"
]
},
"autoupdates": {
"enabled": true,
"branch": "stable",
"minute": 23
},
"private-wifi": {
"enabled": true,
"ssid": "my-very-clever-ssid",
"key": "das-ist-mein-cleveres-passwort",
"encryption": "wpa2",
"management-frame-protection": false
},
"wifi-radios": {
"2-4GHz": {
"mesh_enabled": true,
"client_enabled": false,
"tx_power_dbm": 13.0
},
"5GHz": {
"mesh_enabled": true,
"client_enabled": false,
"tx_power_dbm": 13.0,
"outdoor_htmode": "default"
}
},
"network": {
"wan": {
"ipv4": {
"config": "static",
"ip": "192.168.0.123",
"netmask": "255.255.255.0",
"gateway": "192.168.0.1"
},
"ipv6": {
"config": "automatic"
},
"dns_servers": ["8.8.8.8", "1.1.1.1"]
},
"mesh_on_lan": true,
"mesh_on_wan": false
},
"logging": {
"enabled": true,
"ip": "192.168.0.1",
"port": 514
},
"mesh-vpn": {
"security": "performance"
},
"node-role": "Offloader"
}
} |
|
I am currently preparing a table of external dependencies of the json structure. This will probably help to make decisions. I think I will be able to post this on sunday. |
|
I finished the two tables. Please see below. In general, the options are referenced by their JSON path in the (updated) JSON structure above. However, the tables are based on the code in the current gluon-config-mode-* and gluon-web-* packages. Therefore the tables below represent the status quo of the dependencies of the options in the config mode in gluon. These tables should provide an overview of the complexity of the json config. They can be used to make design decisions for the API. I will post some questions, on which we need to decide (in my opinion) later on. External Dependencies of the JSON structure
Internal Dependencies of the JSON structure
|
Summary of the External Dependencies
|
Hi all,
in the last days I have been working on a concept to improve the config generation of Gluon. Please give me some feedback on this concept. Since this concept is a very raw design, feel free to leave raw comments. Early feedback is more important than accurate feedback. So especially if you have concerns but no solutions yet, please raise the concerns.
Also please use the 👍/:eyes:/👎 to indicate your first gut feelings, whether this is going in the right direction:
Kind regards,
lemoer
A New Concept for Gluon Config Generation
Aims
1. API Idea
local-schema.json.GET /local.jsonPOST /local.jsonPUT /local.jsonGET /local-schema.jsonlocal.jsonis not matching the JSON-Schema, the firmware will reject it.local-schema.json.2. Allowing Reconfiguration without Reboot
gluon-reconfigureis executed to generate the new uci configs.uci:commit()is not yet called here!gluon-reload:gluon-reloadwill useuci changesto see which uci configs/uci sections are changed.uci:commit()is called.uci:revert()is called.The text was updated successfully, but these errors were encountered: