Switch to rpcd based uci apply/rollback workflow which helps to avoid soft-
bricking devices by requiring an explicit confirmation call after config
apply.
When a user now clicks "Save & Apply", LuCI first issues a call to uci apply
which commits and reloads configuration, then goes into a polling countdown
mode where it repeatedly attempts to call uci confirm.
If the committed configuration is sane, the confirm call will go through and
cancel rpcd's pending rollback timer.
If the configuration change leads to a loss of connectivity (e.g. due to bad
firewall rules or similar), the rollback mechanism will kick in after the
timeout and revert configuration files and pending changes to the pre-apply
state.
In order to cover such rare cases where a lost of connectivity is expected
and desired, the user is offered an "unchecked" apply option after timing
out, which allows committing and applying the changes anyway, without the
extra safety checks.
As a consequence of this change, the luci-reload mechanism is now completely
unsused since rpcd uses ubus config reload signals to reload affected
services, which means that only procd-enabled services will receive proper
reload treatment with the new workflow.
Signed-off-by: Jo-Philipp Wich <jo@mein.io>
- support Radicale > v1.1
- modified version detection
- adaption to new function version_compare() in ipkg.lua
- adaption to fixed Flag.parse() in cbi.lua
- adaption to new property map.tabbed in cbi.lua using map template with extensions
- change optional values to non optional
- add support new option "system.boot_delay"
Signed-off-by: Christian Schoenebeck <christian.schoenebeck@gmail.com>
New Application
!!! Dependency not set because there are two packages "radicale-py2" and
"radicale-py3" (currently BROKEN) available !!!
Signed-off-by: Christian Schoenebeck <christian.schoenebeck@gmail.com>
