That is - Congratulations! You installed OpenWrt. It's working great. How do you keep it up to date?
Let's use this topic to consider those issues (and keep the Recommended/Limited/Difficult discussion there...) Thanks.
Update: It's my expectation that this discussion will only apply to Recommended devices (16/128 currently). People using "limited" or "difficult" routers will have been forewarned, and any niceties that come to OpenWrt may not be available to them.
There was some additional discussion on that thread as well, prior to the creation of this thread.
Suggestions:
Get the project, at least for maintenance releases, onto a predictable cadence
Cadence fast enough that users have confidence that they're "current" (2-3 times a year?)
Edit: I'm not saying "new features" every 4 months, or even that there are any significant changes. There is, however, a "formal" release every 4 months with stable packages associated with it.
Get rid of the misleading "upgradable" feature for packages in LuCI (keep for command line for users who understand what it means to them and the risks involved)
Take advantage of the new features in sysupgrade from master to:
Capture a list of user-installed packages and then provide a GUI to reinstall some or all of them after upgrade
Offer (in LuCI) or perhaps default is only copy changed config (saves a few kB for the resource-constrained)
Consider an opt-in mailing list for upgrade / update notifications (shown in LuCI as text might be enough)
Edit: Also provide an opt-in (due to GDPR requirements) "banner" at the top of the LuCI pages that indicates if a ROM upgrade is available. Checks an OpenWrt-hosted URL for data no more often than, say, once every 48 hours when the page is accessed or refreshed (so "random" and reasonable load). Only supplied for OpenWrt-generated, release images.
Consider having some Luci config so that if you opt in it automatically pulls notifications in from the openwrt.org website, some kind of semi static data page that a Luci app can grab and display info from.
Though many command-line-only users are savvy enough to deal with upgrades in their own, meaningful way, that data could also be revealed at command-line login, perhaps right after the banner (again, opt-in due to privacy regulations).
While I suggested that it only be available for OpenWrt releases, there probably should be a way that those that manage "fleets" of devices with custom builds, be it an organization like Freifunk or individuals (including "community builds"), can maintain their own server and configure their own builds to reference that server.
On any of this -- including things like "assisted package reinstallation" (which should also gracefully fail if flash is becoming exhausted long before the overlay system becomes unusable due to lack of erase blocks).
Someone was working on a package (can't find it now for some reason) similar to what Jeff suggested that would allow for checking to see if a new release was available through Luci, and if so to download/install. I tried it a while back, but it was still being developed and wasn't working at the time, seems like a good idea though, optional of course.
I like the notion of making it trivial to sysupgrade. Although it requires developer attention, it promotes the project and makes it available to more people. (On the other hand, I will make the claim that an non-updated OpenWrt release installation is far better than up-to-date vendor firmware. "Friends don't let friends run vendor firmware...")
My first allegiance has always been to "newcomers". (They may be extremely knowledgeable, but may simply not have tried OpenWrt...)
A couple years ago, I tried to make a super-simple Getting Started guide that had a definite opinion about simplicity ("Just do this... it'll work, it'll be secure, you'll be on the air.") But there seem to be too many details...
I wonder if there is a way to incorporate some of the ideas of Homenet (hncp). Its design allows the router to automatically probe each of its interfaces to make a guess about what kind of link is there, and then "do the right thing" by connecting to your ISP, other wireless routers, etc.
This is missing a very important item: how to configure the router in an easy way. Will anyone call setting up a guest network easy? Easy-peasy, right?!.
I think the initial configuration subject deserves a separate thread.
Initial config is a good question, I think intelligent high level configurator apps could be a useful thing... Like a site that could ask you questions about your use case and then spit out a tar.gz of config files that meet your high level needs. Luci is much more low level "change this option, enable this switch port, enter an additional DNS..."
As I am the one responsible for the creation of this thread, I am gonna expand on the original points from the other thread. I see three main issues with maintaining a router and these are the reasons I would not recommend anyone I know to use OpenWRT unless they are technically advanced: I do not have time to maintain everyone's router and this is not a router that an average person can maintain even if it is properly installed by someone who knows how to do that.
Configuration changes between minor & major releases and due to bug fixes.
Be that new regex in Adblock or a new parameter in uhttp, there is no way of knowing about them. Well, besides spending tons of time in this forum, but that is not for everyone. I see several possible solutions
For novice & advanced users: a Luci app (installed by default) that allows them to see a side by side and file by file diff between default config (left panel), their local config (right panel), and an editable view of the local file itself (bottom panel). The file could be edited by copying and pasting lines from the diff above. The comparison view would refresh as the file is being edited. There is no need to do any automatic merge or re-implement meld here; the file is only saved at the end.
A new policy for the apps to not store runtime configuration in the config file. Adblock's regex is executable and enabling/disabling a filter is configuration. These must not be in the same file as the user should not need to know what regex is and when properly separated the regex could be deployed independently from config (like recently happened Adblock needed to fix adguard source: it required merging the changes form the default config file).
A longer term solution is for each feature to become responsible for upgrading their configuration either quietly. Having said that, if #1 and #2 above are both properly implemented, this might not be necessary.
Releases
I saw a proposal to generate upgrade images two or three times a year. I can tell you right away, that that will not be an easy sell as a good security practice. The argument will go like this: everyone else is releasing upgrades every month and that means they are more secure! Perception matters a lot and infrequent releases will be perceived as less secure. I think there should be a dot or dot-dot release/build once or twice a month. Sun Microsystems did refuse to play the perception game (CPU frequency) and look where that got them
Asking users to use daily release snapshots will be perceived as the having to use unreliable and untested firmware. They will always chose an easy and familiar way.
Upgrade/Release Images
The entire industry has conditioned the users that firmware is a single file and going against that is futile. No-one wants to have to mess with figuring out what packages to install to get some functions. I also think that trying to address this by reinstalling packages individually is very error prone. Turris Omnia failed to handle all corner cases by using opkg (for two years) and they totally changed their approach now.
It would be simpler and more beneficial to generate a few standard images with all the basic packages already built-in for the routers from the easy list. The default feature set can be taken from one of the mainstream routers. I personally like ASUS routers and maybe Synology. The configs should be created based on a specific use case and I only see three of those for home use so far:
A router appliance only (and my personal choice): Adblock, DDNS, SQM, Statistics, Bandwidth Monitor, BCP38, maybe a few more basic packages.
#1 + NAS
#2 + Media Streaming Server
Everything else (including VPN) should be delegated to advanced users who know what they are doing. None of the off the shelves routers can provide good performance over VPN with OpenWRT anyway.
P.S. I do have some thoughts to share about the pain of the initial config, but I hope there is gonna be a dedicated thread for that.
Forgot to mention, that auto upgrade or one-click upgrades are also very important. This should not be as big deal to implement for the predefined bundles upgrading to the new version of the same bundle. But I know there are a lot of people who will tell me all the reasons why that is a bad idea
Do you see a non-technical person appreciating this process and also knowing what to do with a tar ball? Adding more steps to the setup will turn some people away. More steps, more people will not complete the procedure. To be usable it got to be a wizard within the default firmware file. But this discussion should be in a separate thread.
Upload it to the LuCI restore backup function... that'd be spelled out with screenshots.
The point of what I'm thinking of is to dramatically lower the number of steps needed to get a more sophisticated level of function. Imagine if you could go to a site and click a few buttons to say "I want a main LAN and 2 separate guest LANs, with ports 3 and 4 part of guest LAN2 and port 1 a port that will connect to a further AP (ie. become a tagged trunk port) ... etc etc. The questions would be goal oriented rather than technology oriented (like whether you want tags on port 3).
But yes, this should go to a separate thread: how to get started, slightly different from maintaining
And until a dedicated thread is created I see no reason for this not to be included in the firmware as a module or embedded into a page. Doing so will eliminate the need to upload any files at all.
It all depends on the back end technology you need, if it's lightweight fine. I imagined using some more heavy hitting tech than what you might want embedded.
I do not have a link, but I did quite an extensive research recently and came across a remark from a frustrated Turris team member about how many corner cases opkg could not handle and so on. You can search forum about all the auto update issues.
There are also a lot of posts about the nightmare of configuration merge during the upgrade. These are big issues to solve.
Another way to handle configuration merge during an upgrade would be to redefine how the configuration is managed and used. Let’s say a uhttpd installed a default version of its config file under /etc/config (for backwards compatibility the same location should be used). This file cannot be modified anymore. All user changes go into uhttpd.user file in the same location and the runtime merges the config via inheritance.
This way a new parameter added to limit the concurrency of scripts that it runs will be delivered as a part of the default config and user settings will not have to be overritten. When the router reboots it will merge the new default config into the user file and the upgraded config will be the latest.
Adblock could change its regex anytime and it is delivered the same way in the default config file while the adblock.user stays unchanged.
I see no reason for this not to be included in the firmware as a module or embedded into a page. Doing so will eliminate the need to upload any files at all.