Hello.
I'm coming back to OpenWRT from Ubiquity where I've got used to having the ability to apply changes or even whole complete configs without saving them (to /config/config.boot) which yielded me following benefits:
Is it something like that possible with OpenWRT? No uci commands combination I have tried yielded me what I want so far. Thanks.
Yes - uci.
Then you are nt using it correctly.
Here is an example of a typical wireless config:
root@OpenWrt:~# uci show wireless
wireless.radio0=wifi-device
wireless.radio0.type='mac80211'
wireless.radio0.path='1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0'
wireless.radio0.channel='1'
wireless.radio0.band='2g'
wireless.radio0.htmode='HT20'
wireless.radio0.disabled='0'
wireless.default_radio0=wifi-iface
wireless.default_radio0.device='radio0'
wireless.default_radio0.network='lan'
wireless.default_radio0.mode='ap'
wireless.default_radio0.ssid='OpenWrt'
wireless.default_radio0.encryption='none'
wireless.radio1=wifi-device
wireless.radio1.type='mac80211'
wireless.radio1.path='1e140000.pcie/pci0000:00/0000:00:00.0/0000:01:00.0+1'
wireless.radio1.channel='36'
wireless.radio1.band='5g'
wireless.radio1.htmode='VHT80'
wireless.radio1.disabled='0'
wireless.default_radio1=wifi-iface
wireless.default_radio1.device='radio1'
wireless.default_radio1.network='lan'
wireless.default_radio1.mode='ap'
wireless.default_radio1.ssid='OpenWrt'
wireless.default_radio1.encryption='none'
Say you want to try changing the SSID of radio 0.
The uci output above shows:
wireless.default_radio0.ssid='OpenWrt'
So lets do:
uci set wireless.default_radio0.ssid='My New SSID'
Now activate it:
wifi
Check with your phone and the new ssid will be present after a few seconds.
Do you want to revert back to what it was before?
uci revert wireless
Activate:
wifi
Change it again:
uci set wireless.default_radio0.ssid='Grawp-2g'
Activate:
wifi
That's more like it - lets finally save the changes so they survive a reboot:
uci commit wireless
The Luci UI uses uci in the same/similar way and this becomes obvious, for example if you change the ip address. It reverts if you do not confirm the connection works after a set interval.
OpenWrt is based on configuration files. Configurations are saved to a file then the service parses the file when it (re)starts. So there's really no such thing as non-persistent configuration.
The "revert" mechanism in case contact with the GUI is lost (e.g. changing the LAN IP, then not reassociating the PC and browser with the new IP in time), is a complex workaround that only exists in the GUI code.
Not entirely correct. The service init scripts use the uci command (or in some cases libuci) to obtain values. Uci (or libuci) will overlay settings from /etc/config/whatever with deltas in /tmp/.uci/ - this makes it possible to stage changes which are effective on service restart without committing/writing those changes into /etc/config/*.
For a example a simple uci set system.@system[0].hostname=foo will store a config override for the hostname option in /tmp/.uci/system. Running uci get system.@system[0].hostname will yield foo while /etc/config/system still contains the original value. A service system reload will set the new hostname (should be immediately noticeable in the shell prompt) while /etc/config/system still remains unchanged.
A reboot without running uci commit system would revert the system to its old state, as the temporary overrides in /tmp/.uci/ will not survive a reboot. Running uci revert system would yield the same effect (as would rm /tmp/.uci/system). The LuCI ui utilizies the same mechanism, but with a different, per-session delta directory, not the default global /tmp/.uci/ one.
That functionality can be easily emulated on the cli using something like this:
# schedule a revert of uncommitted changes in 30s
nohup sh -c 'sleep 30 && uci revert && /sbin/reload_config' &
# remember pid
revert_pid=$!
# apply uncommitted changes
/sbin/reload_config
# give some settle time
sleep 5
# kill scheduled revert job
kill -9 $revert_pid
# write uncommitted changes to /etc/config
uci commit
In case access is lost after the config_reload, the background revert process will not get killed and reset the uci overlay and reload the config again after ~30s.
Thank you @vgaetera, @bluewavenet, @jow.
I had completely misunderstood the configuration system before and during my experiments I was missing actual reload to get what I want.
I'm marking @bluewavenet's post as a solution for anybody who might search for this since it is not behind links but I understood it all the same from those two links in @vgaetera's first post.
Could temporary settings possibly be a feature in LuCi? I know broken configs are automatically reverted and saved my sorry behind too many times than I'd like to admit, but they've also meant I could try things out confidently. I really do love that. At the same time, I see a lot of value in applying configs in a non-permanent manner, even if they were not to break any settings. Maybe something like a firewall rule or VLAN to access a new device but never meant to be applied permanently.
Somewhat related, versioning configuration files or general state would also be an amazing feature.
This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.