luci-app-attendedsysupgrade and owut by default?

[Hauke Mehrtens]

On 9/26/25 04:01, Daniel Golle wrote:
> 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 agree with you, I think for owut it is fine it it shows the recent 
version when asked to do and for LuCI a button like we have it and an an 
opt in automatic check would be nice. I think we have this already.

> 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.

How well can we integrate DNS into the LuCI web interface?
DNS is also not authenticated, it should be fine if the attacker could 
only prevent the UI from showing an update notification, but it should 
not be able to tell the user where to get the update.
> 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.

I would go with the interfaces which are already there for now. Someone 
can still in parallel set up some better interfaces.

>> 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.

I think we would get some negative feedback from users when we remove 
apk from the default images. We could offer an option in the ASU web 
interface to remove APK.
If we have a button to generate a default image without apk in the 
firmware selector UI it would be sufficient:
https://firmware-selector.openwrt.org/?version=24.10.3&target=mediatek%2Fmt7622&id=linksys_e8450
Removing it manually from the list is a bit complicated for the novice user.
>> 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.

I think this is a good option.

>> 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).

I agree with you.

Maybe we should handle the ASU signing key a bit special.
This key is not as good protected as the other keys.
Maybe store it in /etc/opkg/asu-key/ and use this key for signature 
checks initialized by the tools using ASU intentionally only.

>> 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.

Agree
>> 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.


So to summarize:
  * Add luci-app-attendedsysupgrade as a dependency to the LuCI default 
collections for all builds with use LuCI.
  * Add OWUT for !SMALL_FLASH
  * The automatic checks for updates should be opt in, we can keep it 
like it is for now and improve later.

I would keep apk for now, but make it easy for users to generate images 
without apk in the firmware selector UI.

Hauke