[OpenWrt-Devel] project: online image and sysupgrade builder

[Paul]

On 04/09/2018 21.16, Yury Shvedov wrote:
> On 09/04/2018 11:32 PM, Paul wrote:
>> Hi all,
>>
>> some time ago I stumbled over the two difficulties for new users:
>>
>> * Finding the initial firmware to flash a router
>> * Upgrade a modified image without reinstalling all packages
>>
>> For this reason I created an *image on demand server*[0] which fetches
>> ImageBuilders and creates the desired image, allowing the modification
>> of installed packages and uci-defaults (if desired) via a simple API[1].
>> The images are build within seconds and offered to the user.
>>
>> While the project was initially created to simplify sysupgrades the
>> service is mostly used with a *online ImageBuilder* fronted[2]. About
>> 3000 firmware images where created over the last 6 month (some database
>> resets dilute the statistics).
>>
>> I was wondering if this service could eventually become somewhat
>> officially used. It offers a great simplification for user to get
>> started with OpenWrt and also keep devices up to date.
>>
>> Next steps would be two allow multiple builders in parallel [3] and use
>> ucert [4] to establish a trust chain. While build logs already contain
>> all required information to "rebuild" (and verify) the image locally,
>> sqaushfs needs to become reproducible[6] before it makes real sense.
>>
>> Please share your thoughts regarding this project, I'd be happy to
>> receive some feedback!
>>
>> Sunshine,
>> Paul
>>
>> [0] https://github.com/aparcar/attendedsysupgrade-server
>> [1] https://github.com/aparcar/attendedsysupgrade-server#api
>> [2] http://as-test.stephen304.com/chef/
>> [3] https://github.com/aparcar/attendedsysupgrade-server/pull/126
>> [4] https://git.openwrt.org/?p=project/ucert.git;a=summary
>> [5]
>> https://as-test.stephen304.com/download/openwrt/18.06.1/ar71xx/generic/archer-c7-v2/ba5cbe70ba1237b//buildlog-26ac67a4132b017.txt
>>
>> [6]
>> https://git.openwrt.org/?p=openwrt/staging/lynxis.git;a=commit;h=1ad9d341434e6cf123213928d9a2e86ceec59c55
>>
>>
>>
Hi Yury,

thanks for sharing these thoughts!

> This is a great step toward the user friendliness. But as I know the
> major difficulty for users who far from embedded system is to flash
> the board from original firmware. Sometimes there is very tricky
> process, sometimes there is huge red warning of the third word war in
> case of installing non-official firmware, etc. So as I think,
> sometimes user who can not find the wiki-page with device or build
> their own firmware with ImageBuilder could stuck on this step.
Most devices I've used so far where easily flashable via the stock web
interface, however you're right, many require additional steps. I'll try
to add Wiki pages to the online imagebuilder if available.
>
> For others, the set of packages is not the only way to customize the
> firmware. I don't tell about hand-created software but about the
> customization of packages (e.g. great list of busybox options or extra
> kernel modules). This is one of the shortage of ImageBuilder and the
> reason to use the BuildRoot more often. So maybe there is any sense to
> thought about *online BuildRoot* too? When it is warm enough it takes
> not much time to build a firmware for one board.

Yes, the ImageBuilder lacks the possibility to change Kernel or Busybox
settings after its own creation. However it is possible to build a
custom ImageBuilder and let the image server use these, to created images.

Also I'm thinking of adding the possibility to change the `.config` per
build, allowing for instance to optimize the Squashfs settings.

>
> Regarding to clients. May be there is any reason to automate it more?
> I.e. allow user to configure it to sysupgrage at night when the new
> service release is out?
This is eventually planed, maybe with some additional logic like
tracking used bandwidth + load for 30 minutes and only perform the
sysupgrade if no usage appear.
>
> This was just thoughts as you ask. May be I was wrong in some cases,
> please correct me then.
>
> P.S. I mentioned the tricky process for flashing from original
> firmware. Maybe there is any reason to automate building of additional
> software for desktops? I.e. there is many scripts for flashing
> mikrotik devises, so why not to build deb packages in the BuildRoot,
> which will rise dhcp server and flash boards automatically?

Sorry I can't follow this idea - maybe as I'm not aware of any mikrotik
related scripts...


_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/mailman/listinfo/openwrt-devel