luci-app-attendedsysupgrade and owut by default?

[Daniel Golle]

Hi,

On Thu, Sep 25, 2025 at 10:33:51PM +0200, Hauke Mehrtens wrote:
> Hi,
> 
> I would like to have the basic attended sysupgrade features in the default
> images for the next major release.
> 
> I am not very familiar with the feature and what is needed.
> 
> I think LuCI should inform the user when a new major release is available.

Currently both, the LuCI app as well as owut only show possible updates
when instructed by the user to do so.

We should better think twice before having all devices with those tools
installed query online services for updates when ever the admin logs in,
this has wide ranging implications regarding the user's privacy as well,
RAM usage for package lists, data consumption on metered connections, ...

I'd therefore restrict this to query for release updates (and not just a
newer snapshot build in case of a device currently running a snapshot
image, and also only query for package updates upon user requests).
Checking the availability of an newer release could be done using a
TXT record in DNS, for example, which would be much more lightweight
(on both ends) than using HTTPS JSON RPC queries for that.

Neither of the ASU clients currently supports anything like that, but
it would obviously be quite easy to implement in either
luci-mod-admin-full or the ASU clients.

> There should be a button in LuCI which will tell ASU to create an image and
> then install it using sysupgrade.
> 
> We should also have this feature on the command line, at least that you can
> ask a tool if an upgrade is available and then tell it to upgrade including
> all packages.
> 
> Maybe we should restrict this to large flash devices.

One of the design goals of ASU was to support devices with very small
flash. In fact, having an ASU client (owut or the LuCI app) installed takes
less space than keeping a full package manager incl. unstripped metadata of
the installed packages -- so on small flash devices I'd rather drop the
(in this case anyway pretty useless) package manager and keep only an ASU
client instead.

> 
> Do we have to install luci-app-attendedsysupgrade and owut for this or is it
> possible with less?

Either of the two packages is sufficient, we don't need both of them.

> 
> Should we add luci-app-attendedsysupgrade as a dependency to
> luci/collections/luci/Makefile ?

I'd say yes, but that's just my opinion.

> 
> Should we move utils/attendedsysupgrade-common from the package feed to the
> main repository?

I suggest to merge the content of the utils/attendedsysuprade-common
package into base-files, as the packaging overhead is bigger than the
actual content (a single UCI configuration file).

> 
> Should we also move utils/owut from the package feed to the main repository
> and add it as a default dependency to DEFAULT_PACKAGES.

I'd say yes for !SMALL_FLASH devices.

> 
> Is this all needed or does this feature also work with less new packages?

The approach of both clients a slightly different:
- owut talks to the configured ASU server directly over HTTPS. Hence it
  requires network connectivity with the ASU server, and depends on
  libuclient (+ ucode bindings), libustream-ssl and ca-certs or ca-bundle
  being installed.

- The LuCI app does not require connectivity (nor CA certs) on the device
  itself but instead has the browser accessing LuCI query the ASU server
  on its behalf. Hence, only the browser accessing the LuCI app needs
  connectivity with the ASU server while the device itself doesn't.


Cheers


Daniel