LuCI changes not seen by uci changes

Software versions of OpenWrt/LEDE release, packages, etc.
Linksys WRT32X
OpenWrt 21.02.0 r16279-5cc0535800 / LuCI openwrt-21.02 branch git-22.025.79177-4ec18ec
uci - 2021-04-14-4b3db117-5 - Utility for the Unified Configuration Interface (UCI)

Hi all,

In my backup script, I use uci changes to check if a change is about to occur and back off until staged changes have been committed. I noticed changes made in LuCI before hitting the Save & Apply button is never seen by the uci changes command.

  • Steps to reproduce
    1. Make a change to the configuration in LuCI but don't Save & Apply
    2. From an SSH session on the router as root, issue a
      (a) uci changes: no output results
      (b) uci commit: the changes made in LuCI are not committed

I can see staged changes made by LuCI via rpcd in /tmp/run/rpcd/uci-a2346c38a0ce90c1a5b2c2825d43201a/dhcp +dhcp.cfg22fe63='host'. This suggests LuCI used the proper uci rpc call to stage the change.

Is what I'm witnessing the expected behavior? I could not find any documentation about this besides the cursory usage information. Could this be a bug?

Thanks in advance,

This is international. The LuCI ubus rpc session uses uci delta directories isolated from the system wide cli ones.

Yes, yes, of course. I know it uses a temporary area to store changes before committing. That's not the question.

uci changes should show these staged changes according to the documentation in the command table row 5 for the changes description:

List staged changes to the given configuration file or if none given, all configuration files.

We should be able to see the staged changes BEFORE the commit correct?

Sorry @jow, I just re-read your sentence. So there are two different temporary storage locations for CLI uci changes and for LuCI via the rpc mechanism?

That's making the ubus less useful.

The documentation should state that uci changes list all configuration changes in the default delta path. LuCI, through rpcd, deliberately uses a non-default path to not interfere with changes done through the cli.

You could see those changes by doing something like uci -P /var/run/rpcd/uci-* changes

Thank you @jow this makes things more clear.

If I may "hijack" this thread, although my request is similar.
A helpful aid to using UCI for changes - I normally preer cli to gui for admin - it would be really helpful if any change using luci would show the correlating uci commands that will be used to make the luci change.
I notic that some or all of network changes sort of do this, and I've been cutting and pasting them.
But other commands do no show them. I did look at /var/run/rpcd/uci-* after making a portforward change, but this is quite cumbersome - both cut/paste and checking this directory.

A really helpful enhancement would be to write the UCI commands to a file for every luci change - this would be a helpful learning tool as well as a historic record of your changes.

Maybe I have missed this somewhere. If so, please advise. Maybe there's already an add-on somewhere available.

As a frame of reference, my now-departed Netscreen SSG5 did exactly this. All changes with gui became commands in a file and the file could be downloaded, appropriate parts edited; e.g. add more static leases, etc and then uploaded. The file full of commands became the backup.



If you save instead of save&apply, the LuCI changes are staged but not committed. You can then hit the unsaved changes indicator in the top right corner and view any resulting uci command.

Yep. See it. Didn't see it before. Helps a bit.
Can you possibly tell me what the comment in the line below means . I also saw just the "cfg..." previously as a result when I added a bunch of static dhcp leases.
"uci add firewall redirect # =cfg133837"



If an anonymous, unnamed section is added, UCI generates an internal ID (cfgXXXXXX) which you can refer to in subsequent uci set commands. The comment reports this automatically created ID for reference.

LuCI will generalize uci set commands on added anonymous sections by replacing this specific automatic ID with a positional @type[-1] notation which refers to the "last section of type" in order to make the shown UCI commands suitable for scripting.

Thanks. And just to clarify a mis-statement I made. The Netscreen generated the script commands as it's configuration backup, NOT as they were applied via gui.

My Openwrit router almost ready to go online - just watching now for memory leaks, etc.

Jimmy, your approach is just brilliant. Glad you jumped in to give me a, "now why didn't I think of that" kind of moment.

Just some background, I'm compulsive about network configuration management and love how OpenWrt lends itself to go above and beyond what's available on commercial firmware. I'm version controlling /etc and using sysupgrade backups together. Tools like Oxidized are great but it's got problems so I've been finding myself hand-rolling scripts for my needs. Plus with managed switches and access points all running OpenWrt I can manage site-wide configuration. Been only getting OpenWrt compatible equipment religiously to get to that point.

Anyway, UCI is really important and your use case is awesome. I see how replaying such a UCI config command log would work nicely to replace equipment and how it would work well with site-wide management too.

Curious, could you share how you implemented it?


Gosh. I usually get dissed with my suggestions.

I am sorry, but the device that did this was a Juniper Networks Netscreen SSG5 - also had a NSG5-GT before that - back in the day VPN was uncommon (I think) and they had it.
It was a commercial router and very complicated and robust.
Am sure it would not be open source, but I did search Netscreen open source and they seem to be heading that way, but doubt it would help you - not sure even what language it was.
Your knowledge of /etc and UCI might be all needed to have a utility to replace the backup. The Netscreen allowed full updates of entire backup, and/or partials of update file extracts.
I'd love to dive in but my last programming job was 2013.



No worries thanks for elaborating. Cheers.