Upgrading OpenWrt with a Lua script

Hello community!

Occasionally, people ask questions on this forum and elsewhere about a convenient way to upgrade OpenWrt packages, something simple, like apt upgrade in Debian/Ubuntu.

Since OpenWrt ships with Lua, I thought one way to make this happen would be to write a simple Lua script. In its most stripped-down form, with no additional output informing the user about what is happening or about to happen, it might look something like this:

os.execute("opkg update")
tempfile = os.tmpname()
os.execute ("opkg list-upgradable > " .. tempfile)
for line in io.lines(tempfile) do
  words = {};
  for match in (line.." "):gmatch("(.-)".." ") do
    table.insert(words, match)
    end
  os.execute("opkg upgrade "..words[1])
  end
os.remove(tempfile)

Essentially, it does three things:

  1. Runs opkg update
  2. Saves the output of opkg list-upgradable into a temp file, and
  3. Parses the said temp file, extracting names of upgradable packages and running opkg upgrade on one package at a time

Given paltry storage on many target platforms, I think it's important to upgrade one package at a time to avoid overfilling potentially limited storage space.

So the question I have is, are there any good reasons to NOT use something like this? In other words, is the tool I am proposing in any way unsafe, insecure, or counterproductive? In yet other words, is this solution worse than the problem it purports to solve?

Any thoughtful critique would be sincerely appreciated.

3 Likes

I was under the impression that Lua was soon to be phased out, into non-standard in future versions. A Lua runtime package will need to be installed at that time.

See - and perhaps inquire here: LuCI rewrite in ucode - testers wanted

So if you write such a script, you may need to consider the programming language employed.

2 Likes

Interesting... Very different from what you usually see in other Linux communities, but, given the large number of target platforms and limited opportunities for testing this may imply, appears overall reasonable.

1 Like

AFAIK there's no version dependency DB, if you upgrade package A, but not B, something important might break, and packages are probably built independently from each other.

Again, makes sense given the sometimes-tight hardware confines. Thanks for pointing this out!

Is there any network routing/switching/ap hardware anywhere business class or home use using upgrades in any other way other than total image upgrade?

Yep; it's called x64. :slight_smile:

x64-based hardware, even when used in networking, tends to run a full-blown operating system rather than firmware (OpenWrt is a rare exception), which requires installation rather than flashing and comes with a package manager inherited from the upstream OS (usually, BSD or Linux). pfSense, for example, doesn't even ship as an x64 system image, only as an installation media image (system images are available only for Netgate's ARM devices). OPNsense does ship as an x64 system image, but installation media images are available as well. Both, if memory serves, rely on pkg, BSD's package manager, for upgrades.

Moreover, some x64-based network hardware comes with expansion options. You may have an unoccupied PCI slot, which can be populated later with an extra NIC, or a transceiver, or whatever. And once a new device is on the system, you need to add a driver/firmware for it. Incrementally, with the core system remaining in place.

But, again, x64 can afford all that. Sophos, for example, shipped four-port UTM firewalls with Atom processors, 2 GB of RAM, and 320 GB hard drives all the way back in 2013. Most devices OpenWrt aims to power don't have anywhere near that to work with. My beloved Check Point L-50W, for example, runs like a champ on 512 MB RAM and 512 MB of Flash storage. And even that is on the high side; there are devices that have to make do with 64 MB RAM and 64 MB storage. So I, for one, cannot blame OpenWrt developers for compromises they had to make to reduce system resource requirements...

I wouldn't say only x64. As most of your examples are more or less full blown OS with all their pros and cons, they can afford to have a package manager and fully writeable mass storage, they should be able to run on existing hardware you already have in your datacenter, or even in an virtual application.
But your named examples are more or less very specialized Linux/BSD distris. I could also do this by myself and install a e.g. Debian on a supported machine and turn it into an AP/Managed Switch/Router ...
Those distibutions decided to support x64 or sometimes even ARM and build their specialised packages for those. AND of course the want to sell you hardware they have to support.
There are a lot non-x64 router/ap/switching hardware which also uses image based os in business class.
OpenWrt have to (or must) decide to use a image like approach because of different reasons. Size, Kernel Drivers, ...
You can see the image based approach as a negative. But you should not forget that OpenWrt is more or less the only distibution for ap/router/... which allows us to decide which features we want to install or not. All other router distributions i know of (and which can run on those hardware) do not have this (or sometimes in a very bad way implemented).
And in my opinion the best answer for people who ask how to upgrade OpenWrt --> auc (luci-app-attendedsysupgade).

I don't. Honestly. I see it as a necessity. Moreover, coming from the x86-only background, I am finding out that I need to adjust my thinking on the whole issue of upgrading when it comes to non-x86 architectures. And I am deeply grateful to @frollic for pointing me in the right direction.

I started this thread by asking people where I might be wrong. I've received some good food for thought in this regard. :slight_smile:

2 Likes

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.