For managed automatic upgrades as a third party reseller or as IT admin, you really should build and test your custom firmware using either build root or image builder. After that is tested and abused and tested again you could use TFTP to deploy it in a corporate setting (dnsmasq...?) As a used equip rebuilder or reseller you can include SFTP package and a cron job to phone home once a month. If a new firmware is available, then sysupgrade with 'save settings.'
The problem with the different phillosiphies covered thoughout above is that people forget OpenWrt is not a product. OpenWrt is a base or reference design (all be it extremely functional) from which you can make a product.
So with that in mind what is missing is a meta package that can be included and UCI configured to phone home, sftp, sysupgrade, and all that.
I slightly differ on if OpenWrt itself is/is not a "product." In the commercial sense - I'm definitely agreeable in saying it's not a "commercial product"...therefore, I'd stretch to say it's not an "industrial product." This is because of many reasons (e.g. certain licenses, it simply hasn't been sold by its "owner", etc.)...but this goes into the potential commercial value of a thing (i.e. the product).
Though clearly, OpenWrt is surely a result of actions and processes; and by definition is a "software product."
Why important...? After all the community-based development philosophy is a product of forums and groups like ourselves talking here...non-commercially on the fate of this or any other software. Any result is likewise a product - developed/included/compiled on/by our engagements here, on the PR comments, etc. The author's code is a product, it works with OpenWrt; and he engages here for wider considerations by our community - not just those who regularly frequent the GitHub portion of the operation.
(Of course, coding some phone home feature for use by someone who needs it, is cool and makes sense.)
"openwrt" is often seen as a single product. In fact, it's a highly dynamic ecosystem.
so what makes it so great also hinders other aspects. wide device support and alternate progressive code bases offer choice and often improved security.
this is to the detriment of "one size fits all" features.
regarding your use case. to be practical, one would need a limited scope, for instance, the ToH might need a per device property of "TOTALLY SUPPORTED", in this way, such a feature can be tackled on the most common and understood devices AND only for CURRENT RELEASE to NEXT RELEASE. Then you start .... yes merely start..... to have something that is practical.
Then if ABC user want's AUTO everything, they need to adhere to some parameters regarding device selection and images in use.
Personally.... something like an RSS feed checkbox on RELEASE images, that displays a SECURITY FIX notification in LUCI.... ( which could possibly be extended to per device "autopatch" opt in scripts ) is enough from where I stand. If a user is unable to check this every few weeks / months and reflash / mitigate at an APPROPRIATE time of day, then they really shouldn't be flashing firmware - setting up services in the first place.
As has been discussed on this forum.... some extensensibility in config backup imports, would help. But again, without a minimal scope or slowing development to half speed..... the practicality of implementing such features for 1000+ services becomes non-existent.
synology has one of the slickest UI's around. everything is done with a few clicks. it also chomps 200MB of ram when openwrt snaps along on 40MB. ( and many vendors run into update dramas with ONE device to support! )
So automatic updates? not really that needed i think along the lines your thinking...... developers hindering progress? more like wide scope and operational imperatives.
Could a regular user be better tooled to manage their "well supported devices/services"..... yes.
Yes. @wulfy23 is more thoroughly covering what I was trying to say.
My specific example would be for a small business though. Lets consider this thought experiment. TL Archer C7 are readily available so lets assume we can buy a bunch of over stock or well-used wholesale on pallets for cheap. The 802.11ac and single core MIPS is sufficient for so many still on cable and DSL with <100Mbps. Note now we are locking in on a popular, well supported, and narrow hardware set. We compile our own OpenWrt variant from source, different packages, and create a rebuilt-archer product. We then have a business were someone can "buy" that product from us. But really the hardware and software don't cost us that much. What they buy is that we (help) manage their router remotely for them. We could just register each serial number with a unique SSH key and manage manually by SSH. However, the billable hours on that mess will kill profits. We could instead have a mostly automated process that phones home and pulls from our servers to do routine tasks we define. That could generate a nice monthly revenue without too much hourly cost.
I don't understand if you are not reading or what. I already sent the link twice and it was in comments of the pull request that OP linked (did you read them?) in the first post. There is a package for OpenWRT which you can install, also with luci web interface. It will send the list of your packages and your router model to a remote server and the remote server builds the upgrade package with all your custom packages for you.
The name is attendedsysupgrade-server and for luci the package name is luci-app-attendedsysupgrade. You can even build yourself an upgrade package manually now from here: https://chef.libremesh.org/ I tried it and it was impressively fast even!
About NSA, as the upgrade package is built live with different combination of packages, on a remote server. There would be no way of checking signature to see if it was modified etc. That is inherently unsafe.
We are talking about users making fundemental changes on devices as root user. There is no way you can stop them from destroying the device. So in your opinion the firmware upgrade should be removed from OpenWRT because there is a chance that a rookie user can brick their router? Perhaps the reset to defaults option should have never been implemented? Because user can execute it (basically resulting worse than doing a system upgrade) then he won't be able to connect to internet anymore and can't fix it? Should it be removed?
The fact is there is a situation which can cause things to get broken does not change the overall result. It would be still useful if opkg kept list of explicitly installed packages, compared to right now where you have nothing.
I already proposed it and explained why the other way is more error prone.
Why don't you do it instead of arguing with me?
Luckily you are not my boss so I don't have to write code because you think I should.
I don't understand your point as the neither the changes in OP's pull request nor the hack to sysupgrade which adds possibility of storing installed packages resolve this issue. Because it is literally impossible to overcome due the lack of device resources. Pointing this out makes no sense.
This may be so, but also irrelevant as no package manager can deal with such situations. User would need to-reconfigure the package. But the package would be already there helping the resolution of the problem.
As I explained to @lleachii , you can't control everything that a user does with so much flexibility and power. In your example, Bob created a customOpenWRT image with additional packages. It is partially not the software's responsibility to try to overcome every possible combination. If you think about it, you can see that once you open pandora's box you will have more problems. For example, Bob may have compiled the packages with custom settings etc. also. Maybe Bob compiled his own packages which are not registered etc. It may be that Bob modified the source of OpenWRT before compiling this image...
If I install Ubuntu, then compile a program and install on it. The Ubuntu package manager can't upgrade my program. If my program relies on some shared libraries, after an Ubuntu upgrade my program may cease to function. This does not mean that Ubuntu package manager is useless now does it?
The original issue was about people who are not capable of building upgrade images themselves. There must be some assumptions made or you would have to deal with a large number of combinations and impossible to resolve situations. Then such attempt will be refused to OpenWRT code base as a cumbersome hack. In this case we have to assume the basic user is using a default image and used opkg to install additional packages.
Anyway, I am off from this thread. This does not seem to be progressing. It feels like a loop itself. Good luck guys!
All this more or less boils down to overall project roadmap and personal goals.
The overall goal has never been to replace vendor firmware in all possible scenarios. There is simply a lack of developers, testing and interest/"public interest" for doing a one fits all solution not including the hardware limitations of doing so. Your best bet AFAIK in that case would be the Turris project by cz.nic but then you have a controlled environment with very few hardware options.
You also have do consider the end-user point of view, even if there are large disclaimers saying that there's no responsibility etc if X breaks there will be be efforts finding a scapegoat and with it comes drama which is highly unwanted especially if you "work for free".
One of the biggest strengths of OpenWrt is that it runs on very limited hardware, this is slowly changing with new hardware being much more beefy over time so even now you might have more "complete" firmwares/Operating Systems which better suits your needs as much is already in upstream repos.
Anyone following up on these ideas should take into consideration that there are over 2,500 posts and close to 80,000 reads on
The popularity of custom ROMs is not easy to ignore. Whether they deliver on their promises of "faster, smoother, better" or not, here, just as in the Android world, they abound and have strong followings.
 General statement, not intended to reference the David502 builds, but custom ROMs in general.
Basically you complain that developers chose to prioritize things which are not important or useful to you
Here is my opinion. Volunteer developers should do whatever makes them happy. Project leaders have additional responsibility. Developers and users alike depend on you to provide a stable project every morning, which implies to me a moral directive to make the project better for them all and the millions of people like them.
I also have a selfish purpose: I want OpenWrt to continue to be strong and make the internet a better place for me. So it must grow and be deployed widely, it must be healthy, and the members must be happy. I encourage OpenWrt leadership to make OpenWrt as good for as many people as possible.
The way I see it, away from the specifics, is that flexibility involves complexity. If you want to make it simple enough for the average user then you will have to give away the flexibility, because you can't just program for every usecase and make it foolproof. That's not even feasible in a commercial project let alone an open-source with limited resources.
I understand the selfish intent, and perhaps its an intent that you others share, @mhegab illustrates this well (i believe). Now consider openwrt origins, and now look at the broad devices with different bootloaders, architectures, and look how many devs are contributing there free time. Compare that to any commercial product, they only support limited devices.
One interesting point made is indeed hardware is getting more powerfull, Perhaps a good compromise would be to design a plugin that notifies the user of an update in the webui. In fact more effort spent egging on the devs to increase their complexity and thus complications later, and less time developing code that actually runs on these devices is going to help. So put your money where your mouth is, not being rude. I would help if i could, and probably many users are that way
As other stated, if you need to remote upgrade, then one can deploy a ssh/tftp server to do sysupgrades, alltho you'd probably want a full box locally in doing that just to be somewhat safe. that is something you can do if you want to really remote upgrade, and im sure if you don't know how the someone in the forum can help you make a script to run that can accomplish that for a specific device(s) you made need to sys-upgrade from.
It's not about selfishness; it's just there is no one size that fits all. A more obvious example is probably Windows and Linux.
There are other router firmware projects that are closer to being easier for the average user, such as dd-wrt or Tomato, but that comes on the expenses of the flexibility.
The are certainly some fine ideas that were brought in the discussion and can be used to make OpenWrt better, and hopefully increase the user base, but all I am saying is that we need to remain realistic about the target audience.
I world be interested actually to see how manufacturers who ship devices with OpenWrt or OpenWrt-based firmware handle that. At least they have a more controlled selection of hardware, and they practically save most of the software development efforts by using OpenWrt, so I imagine they can spare the resources to research in implementing such features (let that be on their own or by commissioning OpenWrt developers to do it); if it proves useful then it can be introduced in mainstream OpenWrt.
I'm sure the NSA is the last thing we should be worried about. The issue is the countless up and coming hackers who will try and take over a router, and the ideal situation would be if the could then install a firmware they have built.
To this end, I see Owrt as requiring some sort of checking before a firmware is applied. Sure it checks for the general CPU but, for instance the hundreds of variations of the Qualcomm single chippers. They are all mostly different. Some only subtly, but some require a u-boot do-over. Each of these should not allow a foreign firmware to be applied.
This would indicate some responsibility for "someone" who is in charge of that particular build. With thousand of variations I do not see this as even a remote possibility. Just remember, Windows is a single target, with everyone focused on it, and yet they can still get it wrong. Remember when, not that long ago, that Firebox removed all of your extensions? Again, they have only one moving target and yet it can still end up a disaster.
My experience, and I come from nearly 45 years of programming, is that all upgrades should be optional. There is nothing more infuriating to see that some program or OS decided it was time for an auto update and they could care less what I was doing. I have had overnight builds stopped dead because Windows decided it was time. I now have Pro and have setup everything to never touch it until I say to do so. Guess what? They cannot even get that right and at times, while I am deep into a problem, things just start to go wonky. So wonky that I try the old Windows 95 cure of reboot, only to be told not to shutdown the unit until the update is finished. Thanks for that.
So, do we want this for our Routers? My way is to build new versions and offer them to my users when I am sure they will not make a brick.
We cannot think of Owrt as "ONE". It is definitely "MANY" and we have to choose which one. It is awesome that they have essentially wrapped a common core around so many different devices.
As to the contributors not desiring the billions of problems, I am just glad you do what you do. In the end it is up to me if I want something different. Why would I even dream to expect essentially paid for support to be free? If there is a free lunch somewhere I must have missed the memo.
This cuts both ways. Ie, it also applies to the newbie who doesn't know what they don't know but is SURE that the way its being done now could and should be better and is sure the only reason their very good suggestion/code that they don't want to bring up to community standards isn't already implemented are other peoples personality flaws.
(the above isn't directed at anyone in particular. It's instead an illustration of how calls for less ego are sometimes made by people who either don't see themselves as clearly as they think they see others, or, (much) worse, are being manipulative and passive aggressive).