Hi, for the last year I've been working on a server which allows two things:
Devices check online for new versions or package upgrades
Easily create custom images without setting up a build environment.
This is done by a back-end which automatically sets up ImageBuilders and parses available packages and profiles. Once initialized, an API allows to perform upgrade checks and build requests.
Without giving to many details here, the created images are cached to allow faster responses.
While initially only planned for upgrade checks, the API is usable to offer an online ImageBuilder which allows firmware creation even from mobile devices.
There have been some major refactoring lately, so some stuff does not fully work, but as I have currently some spare time I'll try to fix all the issues within the next weeks.
I'd be happy for some feedback & feature requests, the project is intended to be generically usable so communities can setup their own servers.
Good idea, I've planed created something similar to allow allow all kinds of files, but reducing it to UCI appears much easier to implement. My only concern is on how to add SSH keys...
Regarding “ * Devices check online for new versions or package upgrades”
Are “devices” also the router itself?
Is there also something planned on router side maybe an upgrade package (incl luci for update / upgrade config)?
Not just planned but implemented, see here.
The Luci app uses the HTTPS support of the client device (Laptop/Smartphone) and then push data on the routing device. However, this doesn't work on the clients device. Generally I have to rework the trust chain, so that devices without HTTPS capabilities validate created images via usign. However, as in future the version multiple worker should run in parallel, it needs something like ucert.
In general, the Luci app was my first JavaScript "project", I'm happy if somebody would refactor the code with me
There is some odd behavior regarding OpenWrt snapshot builds, causing the worker to stuck, resulting in other people to stay in the queue forever. I'm looking into this...
Hi, I added the possibility to add an uci script. It will put the contents of the text area in /etc/uci-defaults/99-server-defaults. This is untested as I have no devices here, but if anybody has the time, please test.
Also the caching isn't quite finished yet, meaning you have to change the package selection everytime you change your uci defaults, else the server will instantly respond with a different image.
Regarding the implementation, I'm limiting the UCI size to 10KB and store them in the database, I'd add a worker which removes custom builds after some time (48 hours?) and also the stored UCI default.
As I had to change the database layout at various parts the ImageBuilder is currently parsing all packages/profiles again, so in case your device is missing, give it some time.
This is indeed awesome. Exactly what I was looking for.
If I was you, I would put all the fancy and additional requirements like "own uci-defaults for selected packages" to the backlog of 2020.
Double thumbs up for not using Java!
If you have the option to select additional packages and to select the router model, it is already awesome.
The only real missing piece is the router-server communication (without local PC intermediate) since this could be an automated process without manual interaction. Doesn't openwrt have "opkg install ca-certificates" ? This and wget would perfectly make it.
If you have standard images with user-selectable additional packages for the famous routers, you are already in the game (from my point of view).
What I am also thinking about is the trust issue. Why should I - as a paranoid IT guy - trust your image builder and the resulting image? I would need to be able to check the end to end building process from the git sources to the final binary. (Which is in fact a default requirement for all custom software solutions developed and used in comapanies internally). Mabye a well known domain name or certification or an approval process or any kind of 4 eye check process for the build scripts could support the trust in the images for the standard end users people. (Side note: I love the openwrt community but I would never install a pre-compiled binary from downloads.openwrt.org)
If such an update server could be established for dummy end users, this would definitely help to spread the usage of openwrt.
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.
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
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.
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.
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.
