Thanks for feedback

I think this behavior is not really acceptable. Programs, init scripts,
hotplug events etc. should not automatically modify (and commit) uci
configurations, especially not such vital ones like the network config.

The new wireguard init script is only executed if the network configuration
has changes. This is triggered by the procd ubus service.

The main problem I see is that you do not know what state the config is
in at any point in time, whether there are other (intentionally!)
uncommitted user changes etc.

Yes, I agree, but I couldn't think of any other solution for this problem without touching the current configuration handling as you mentioned below

Wouldn't it be better to modify the code deleting the wireguard
interface to delete the peer sections as well? Or to remodel the
wireguard configuration model to cope with orphaned peer sections?

I already thought of that. I could imagine a list item that references
the peers in the interface section. If this wireguard interface section
is deleted then these list element sections should also be deleted.

For example

config interface 'wg
        option proto 'wireguard
option private_key '8OGwbqPFAJjjMgdF1kwkNYQ+uXCUYMWMyJjreDsruMk4='
        list peers <name1>
        list peers <name2>

config wireguard_test <name>
        option endpoint_host 'test.de
option public_key 'Cs46OJr5d3NoDRYf/g2l0RINYLvaypQCMtchlJhQgSQ='.
        list allowed_ips '0.0.0.0

Deleting an interface section in LuCI is generic. So I don't know if we should
do this and make an exception for wireguard.

Best regards Flo

_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel

Reply via email to