Online ImageBuilder and Upgrade Server

While that's a great question everyone using this remote image builder should ask themselves, well, if you don't trust the openwrt.org, it will be very hard to convince you to trust @apacrar. :wink:

1 Like

Sorry I don't fully understand that. For now you can only add one uci-defaults file, however it can contain options to influence various tools. Meaning, Changing uhttpd and dhcp settings can be done from a single file.

If the service becomes more popular and people (or routers automatically) check for upgrades on a daily base, I'd rewrite the server part in rust - hope you'd like that too :stuck_out_tongue:

This is the current implementation, however I'm planing the following. Each image contains the servers certificate. On downloading an image, the client also downloads a list of trusted workers, which is signed by the servers cert. The client can then automatically check if the image produced by the worker, but delivered by the server, has a valid certificate using only usign (with the mentioned ucert). This would keep the overall requirements for sysupgrades low.

I'm working on a way to get all created images signed automatically, see here.

If I'm not mistaken, that's already the case. The server supports literally all routers supported by OpenWrt.

Fair enough, well I hope that eventually some OpenWrt core devs think the project is worth a look and thereby deploying an instance, which then would have the same trust level of images from downloads.openwrt.org, right? Apart from that, I've been in contact with some people of reproducible builds. My idea is to offer all env vars in the build log so people can rebuild the package on their own. I think this works already for x86/* images, squasfskit should solve it for most ar71xx/* devices.

Anyway, you're free to run your own server, I'll add some documentation on how to do that.

How update image to modem ???? xxx-squashfs-sysupgrade.bin ????

Sorry I don't understand your question, usually the file called "sysupgrade" is suitable to perform sysupgrades, however I don't see what you mean by modem.

Big thank aparcar, "Online ImageBuilder".
I build image but not found image sysupgrade download for update modem via lede

Very interesting project and one that seems to fill the needs of people without the skills or equipment to assemble their own images.

How are you going to handle license compliance?

You're definitely distributing binaries that fall under a number of different licenses and simply distributing the binary doesn't meet the terms of most of the licenses under which the code falls. It's not just GPL, but BSD-style, Apache, Eclipse, and all of them that need to be complied with.

How does OpenWrt follow that?

Surely this would be no different than somebody simply distributing a custom Linux distro?

Once the imagebuilder or opkg can handle spdx license tags I'm happy to integrate this feature, as requested a long time ago

1 Like

Awsome, nice work.

As @aparcar points out, handling the spdx and similar licensing tags to collect the licenses and required files would make distribution of images a lot "cleaner" from a licensing perspective. I'd definitely welcome that!

https://openwrt.org/docs/guide-developer/packages does call out

PKG_LICENSE - The license(s) the package is available under, SPDX form.
PKG_LICENSE_FILE - file containing the license text

but I don't think that anything is done with them, nor are all packages annotated.

There are some very important distinctions between "a custom Linux distro" and a "bare-bones" binary distribution. If you look at most of the desktop/server distros out there, they typically either include in the distribution or directly host the full source code for the kernel, standard utilities, and packages. These typically include the license text for each component, as well as any additional files or build instructions needed to satisfy the specific licenses (not just GPL, but all of the licenses and their own peculiarities). They include the required statements about licenses and often include those licenses and required files in their binary distributions.

As an example of an embedded OS, Android (AOSP, at least) collects all the licenses and required documents and puts them into a compressed file that is included in the image to be flashed to the device. Yes, a challenge on ROM-constrained devices, but at least a direction on how to make compliance easier. Another embedded-device approach is that silly CD in the box that we all ignore ("what am I going to do with this Asus motherboard CD when I don't even have a CD drive?") -- typically containing the required statements and licenses and occasionally the source code itself.

1 Like

Hey @jeff I think I get your point and nobody is eager to produce any CDs. As long as opkg info or opkg list-installed does not print any information regarding the license, I can't really do anything. Once this is done I hope this information is included in the .manifest file and then available for every created image.

1 Like

Hello @aparcar.

First, congratulations for your work.
I´m trying to create a build for my router, but i have a doubt.
Look at the files created:
image_builder

I cannot see the factory and sysupgrade file..
Which of these files i can write into my router?

Thanks.
Juliano

Check your buildlog for error messages, but this is almost always indicating that your image got too large - especially for 4 MB flash devices.

I'm afraid the refactoring broke the detection for "to big images". I'll try to update the server within the next hours

Hello @aparcar.

I agree with you...
Using online image builder from libremesh, i get an error when the image become too big.
It´s easy to fix this?

Another question: It´s possible to customize the squashs block size?
In other builds that other users did, it seemed that using the 1024Kb block size improved the compression level.

Regards,
Juliano

I have no experience with that, if you'd suggest to use that value for all LibreMesh image builder I can add a feature to change individual .config options. Please send me the related line & request comments on the LiMe mailing list.

However, making all .config options editable per requested image is a bit out of scope.

Hello @aparcar.

I don´t know how to do this too.
I have no experience with linux. My sugestion was based on builds from other users.
If somebody can help.

Juliano

The problem seem to be that the snapshot ImageBuilder don't print the error message. Here is an example of a working version while sometime it just doesn't. I'll ask on the mailing list for some further help.

I'll ask the LibreMesh mailing list if this is recommended, if so I'll implement it.

The config option is TARGET_SQUASHFS_BLOCK_SIZE, and the default is 256. Increasing it will noticeably reduce the size of the image. The drawback is that three of those will be cached by default, so if you increase it to 1 MB then it will use 4 times more RAM. It can be reduced to 1 using make kernel_menuconfig, the setting is SQUASHFS_FRAGMENT_CACHE_SIZE. Setting it to 512 KB and 1 cache fragment could be a good idea on a 4/32 router, though. I don't know how much it would influence CPU usage.

2 Likes