/etc/config/network
/etc/config/dhcp
my understanding is after 30 seconds Luci rolls it back to where it was when you said save and apply, and pops up the dialog. at this point you apply unchecked.
or if you know the config lines you want do it over ssh.
1 Like
I don't think this is entirely accurate. On Friday, I demonstrated this in-person to someone. I changed the LAN IP from 192.168.x.1 to 192.168.y.1. The old browser window showed the "Apply Unchecked" dialogue, but I had already browsed to LuCI at the new IP in a new tab.
If we can pinpoint the exact issue being experienced, perhaps a developer can actually fix it.
You can also compile an older version of LuCI then patch any new features (not including the rollback). You can also change the rollback to a high amount (although, this won't work in your use case).
Seriously?
This is an interesting use case...are you saying that you pre-configure a router (using LuCI), and then deploy to the location (sometimes weeks later), without ever testing the change?
WELL...That makes sense on why rollback doesn't work for you!
Wow...
I'm not sure you consider working around or bypassing the feature the same as disabling it; I'd advise simply making such edits in the UCI instead.
1 Like
Hmm.. Is this because the apply unchecked function is running in the browser rather than on the server? Perhaps it pops up the dialog, but doesn't actually do anything?
1 Like
What is so odd about using something and wanting it to keep working the same way it has always worked? If I want to use a 5 char password or if I don't want to use a verification system that someone dreamed up that I need to use, then I think it should at least be an option. I like to be able to control my own environment and that's why I use OpenWRT instead of the stock firmware. I may be the only one without a Linux backgroud using this firmware but I give it my best shot.
Huh? There's a verification system too?
So compiling the software without the rollback is not the solution?
At the moment I am working on a network in a camper. If someone hacks me or if I have a flat tire and have to address it, or spend a week in a shop getting the engine repaired, my priorities do change. Also in my home I often start projects and the water heater blows out or the lawn needs mowing and I have to set things down and pick them up some other day.
So with a limited Linux education I have to look at the trade offf, 5 years minimum of constant study to get to where some of the younger programmers are here or take a chance and do things the way I understand and leave a risk open, or the ultimate choice, to put all of my toys away and go read a book or something.
1 Like
I think that at this point, I would suggest to you and others who are interested, to organize in a thread perhaps - to fork LuCI back when the rollback was added; and keep it up-to-date with all other added improvements.
It can then be added to the repository as luci-old or something.
All this forking business always going on seems like the ancient "my way or the highway" type development. How about the historic option file as an ooption for people who don't agree on such things?
e.g. replace "power play" with "people play" by providing options to users of the product to allow each user select what is best rather than "love it or leave it"
*** and don't get me wrong, I appreciate the intention and for that is is good, it's only that when it doesn't work, it doesn't work
***** Fix: ____ Enable auto-rollobach (check for yes, default is yes is checked)
1 Like
Did you try just waiting 30 seconds and then hitting "apply unchecked"?
The problem with "just allow this feature to be turned off" is that if you have N features and want to then be able to have each one on or off, you need to support 2^N possible configurations. So for example if there are 20 features to support you have to support 1,048,576 possible configurations. For 30 features its 1,073,741,824 configurations... No one is going to test all those combinations, or even 1% of those combinations, so if it works, it'll be an accident.
It's critical for the continued stability of public open-source projects developed by volunteers, or even paid people, to prioritize what features to support and which ones to drop or the cost of maintenance overwhelms the project and it dies.
4 Likes
Yes, I did try that and it didn't work.
By the same token on development, why not devote the time to making the software more stable and user friendly rather than adding a feature such as this one? This thing seems massively complicated and (without hurting anyone's feelings) a bit of overkill. True, there is a grin when one first sees the cleverness of the design effort that went into it when it works but when it doesn't, work all that is out the window. And the same thing with that complicated UCI interface or that complicated nested-programming-like, long, period-delimited line command structure. I can understand if line command and VI is all one has to do editing of config files but for example on Windows with WinSCP you can edit full screen text a configuration file in seconds that could take hours to hammer out in the UCI code. Plus you can see what you just did and you don't even need an "are you sure" action because if you make a mistake with a full text editor sitting in front of you, at this state an "are you sure" action is probably not going to bail you out.
Otherwise as far as the "are you sure" type feature which if the person making the change is not sure, then maybe they need to start all over anyway, I mean if they are not sure or didn't really mean to do the last thing they did. Also if they are not sure the first time, how about the second time or how many more second chances do they get?
1 Like
If you have a better proposal, laying out the use cases, both "happy path" and otherwise, would allow someone to examine, propose, and perhaps implement an alternate approach.
Yes, this is the approach that many who use more sophisticated configurations take. I generally don't install LuCI on my "production" boxes.
I think you're talking about vi, which I never use. I'm an emacs person but emacs is too big for a little device, so I use nano, it's probably the first package I install on a router (I don't compile my own). It has on screen assistance for the most common text editing commands.
I believe this is a bug as it's intended to always fall back to the old config and let you apply. So it's worth documenting how you triggered it and filing a bug report.
The feature works just fine.
With regards to been able to use Luci at the new ip address means it is working. That is how rollback works. The new settings are applied and if connection is lost with the initial Luci session it is rolled back and you are required to confirm the change "unchecked"
1 Like
the feature is annoyance, it should default to 60 sec at least
1 Like
Are you sure? I was hit by this "feature", when I needed to change the lan IP/subnet/router IP and it was no go, since I was not able to reconnect to the router to confirm the changes. I had to set up an ssh to the router and edit /etc/config/* files for that and do the change manually.
Besides I am still not sure I understand what is this feature supposed to do. If I am going to make a change which does not break my connectivity then I do not need it, because if the change won't work I simply change it back. If on the other hand it breaks the connectivity then it seems the reconnecting (on a different interface, or via a different IP) is not supported by this feature either. Or was I just unlucky with my particular use case?
I mean, can someone explain the scenario, when this is actually useful?
Read the code /comments if you like:
The comments describe how the rollback is implemented in LuCI, but I did not find anything related to my problem, or my questions, if your link was supposed to answer those.
Basically, if youâre smart enough to know with certainty just what will and wonât break connectivity, youâre probably not using LuCI. For the rest of the world, this is a reasonable safety net.
Remember that loss of connectivity is not just IP addressing, but VLANs, switch config, service config, service running, firewalls, port forwards, ...
4 Likes
I do not mind having "reasonable safety net", if it works. My point was that this feature breaks LuCI in the very case (at least for me in the case described above) it should be helping with. I would not consider changing the LAN subnet to be an exotic case either (compared to the others you named in your post).
I do not know how it behaves in the other cases you named when it breaks connectivity, or better write - interrupts the connectivity, because it is not actually lost - since I did not face them, but my question stands.
Is, in those other cases, actually possible to reconnect and confirm the changes, before they are reverted? I mean if the connection is interrupted and I cannot reconnect to the same LuCI session to confirm the change because of the nature of the change and the nature of how the roll-back feature works, would not it be better to simply disable the option for changes in LuCI to save the user the frustration and tell him to make the change in the config files?