koloblicin

Hi, in short: I would like the network settings to require a confirmation after a timeout. motivation in detail: what Currently, to change Unraid network settings, the user accesses the UI, usually via IP/hostname and webbrowser, changes the desired network settings like static/dynamic IP, subnet, gateway etc. and finally presses 'apply'. Which will immediately apply the new settings, discarding the old network settings. I propose the basic process remain the same, however, after applying the new settings, those will automatically revert after a given time span, unless they are confirmed. This behaviour should be toggle-able. why Assuming a bare metal install, applying misconfigured network settings will render the unraid web UI as well as CLI inaccessible. Thus manual server access is required (to attach keyboard and display). Some server hardware is not easily accessible or does not even offer display output, increasing the effort of recovery and the llikelihood of estranging novice users. how I propose to include (in web UI): a check box to enable/disable the behavior (maybe called 'require success confirmation') a pop-up window with a countdown, shown after 'apply' was selected, with the options: 'confirm new setting' 'revert settings') If 'revert settings' is selected or 'confirm new settings' was not selected within the count down time frame, the previous network settings will be restored. network settings should gain a 'transient' attribute, to prevent changes before a consistent state is reached (countdown duration should be long enough to account for NIC reconfiguration, web UI access and user login short enough to keep subsequent behavior associated with the change, if ignored ~30 seconds?) possible alternatives/workarounds Could probably be achieved with self written user scripts. (not viable -reliably- for novice users) relevance Hard to gauge. However, since Unraid is often chosen as a simpler / more user-friendly alternative to more pro options, this feature would align with general target audience. related FRs: prevent network failure through VM setup possible side-effects user input/activity during countdown could create inconsistent state (changing network setting from other tab / via other user / via CLI) (applying validated settings for new network settings, which might then be reverted) (settings reversal might not be successful, e.g. if IP was snatched > not an Unraid problem) countdown might be interrupted (power outage, service restart,...) estimated development effort Neither trivial nor overly complex. Can very likely be omitted from CLI (assumption of advanced users). Requires rigorous unit and integration tests. disadvantages (-) increases complexity > increases documentation complexity increases support/debugging complexity could introduce bugs advantages (+) prevent irrecoverable or arduous lockouts increase user satifaction decrease support numbers increase useablity / safeguarding for novice/non-professional users conclusion While implementation might not be trivial and could harbor bug potential, this feature could alleviate serious user frustrations and possible data (access) loss. If implemented as optional feature, possible 'cross fire' should be restricted to those users, which are liklely to prioritize hypervisor (/unraid host) access over possible negative side effects.