| Message ID | 553B52FA.2080700@darbyshire-bryant.me.uk |
|---|---|
| State | Rejected, archived |
| Headers | show |
> miniupnpd service was always disabled after firmware upgrade. Original
luci default logic was 'enable miniupnpd and if that succeeds, stop and then
disable the service'. It should be 'enable miniupnpd and if that fails, stop
& disable the service'.
You got the original script's logic wrong, as you mixed "enable" and "enabled".
"enable" activates the service, while "enabled" is just a query if the
service is active.
/etc/rc.common defines both of them.
The logic is: query if miniupnpd is active, and if yes, then stop and disable it.
The feature has originally been added as a security feature to luci-app-upnp.
But why it is set in luci, not in the actual miniupnpd package in the routing
repo?
It originates from 2008:
https://github.com/openwrt/luci/commit/66fa0eb0e8e206d26e16615941c60b22b5004649
modified in 2011:
https://github.com/openwrt/luci/commit/6811edb3d9fe289190fbc7337d372027a655daf8
On 25/04/2015 10:00, Hannu Nyman wrote: > > miniupnpd service was always disabled after firmware upgrade. Original luci default logic was 'enable miniupnpd and if that succeeds, stop and then disable the service'. It should be 'enable miniupnpd and if that fails, stop & disable the service'. > > You got the original script's logic wrong, as you mixed "enable" and "enabled". > "enable" activates the service, while "enabled" is just a query if the service is active. > /etc/rc.common defines both of them. > > The logic is: query if miniupnpd is active, and if yes, then stop and disable it. > > The feature has originally been added as a security feature to luci-app-upnp. But why it is set in luci, not in the actual miniupnpd package in the routing repo? > > It originates from 2008: https://github.com/openwrt/luci/commit/66fa0eb0e8e206d26e16615941c60b22b5004649 > modified in 2011: https://github.com/openwrt/luci/commit/6811edb3d9fe289190fbc7337d372027a655daf8 Ah, ok. Ooops! Another cr*p patch from me then, that makes it 2 out of 2 so far. 3rd time lucky maybe :-) This feature/behaviour has had me confused for quite some time. Personally I really don't like this behaviour. I can sort of see an argument for security, but if I've installed the service and enabled it then I'd kind of like it to stick around after an upgrade, like all of my other possibly insecure config file settings do. Would I be correct in thinking that this behaviour only occurs if you have the luci-upnp module installed as well? Is the same thing done for other services like Transmission/asterisk etc?
diff --git a/applications/luci-app-upnp/root/etc/uci-defaults/luci-upnp b/applications/luci-app-upnp/root/etc/uci-defaults/luci-upnp index fe22a3e..4c45f3c 100755 --- a/applications/luci-app-upnp/root/etc/uci-defaults/luci-upnp +++ b/applications/luci-app-upnp/root/etc/uci-defaults/luci-upnp @@ -1,6 +1,6 @@ #!/bin/sh -/etc/init.d/miniupnpd enabled && { +/etc/init.d/miniupnpd enabled || { /etc/init.d/miniupnpd stop /etc/init.d/miniupnpd disable }
miniupnpd service was always disabled after firmware upgrade. Original luci default logic was 'enable miniupnpd and if that succeeds, stop and then disable the service'. It should be 'enable miniupnpd and if that fails, stop & disable the service'. Signed-off-by: Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk>