It was about two months since last update. Today, I will describe our work in the last three months of the year 2018.
To sum it up, we released 3.11 minor release with two patch releases and also 4.0-alpha for Turris MOX. We have finished manufacturing process for MOXes and we have sent first boards. Next batches are prepared and we will send them soon. We continue our work on new features we have promised and we need to reliably provide Turris OS updates and associated services such as data collecting.
Michal (@miska) spent most of his time with Turris OS 4.0 development. This work includes kernel and U-boot finalization (together with Marek) and also the preparation of MOX network boot from Omnia. Michal managed to finish TOS 3.11 into production (3.11.2 at the time of writing) and prepares NOR-update for Turris 1.0 and 1.1 hardware.
Pepe (@Pepe) tested with Michal the NOR-update very intensively as it has a significant impact on the rescue system. They didn’t want to underestimate anything and tried to cover all possible issues, which could appear. Our users help us to test this crucial update and we have prepared Turris OS 3.10.9 release with this update for Turris 1.x routers.
Pepe started to update packages from upstream to TOS 3.x regularly (such as tor, wireguard, haveged, vim, and so on) and added recent Ubuntu among LXC containers. He also started to develop TOS 4.0 on MOX prototype and prepared several pull request to OpenWRT upstream packages (such as bind, Netdata, findutils, youtube-dl, …). Most of them were already merged.
Martin works on replacement of notification system with a new one written from scratch. He made good progress and all important pieces are in place, however, there are still parts that need attention and polishing before release. Also, we haven’t tested integration with other parts of Turris OS yet, so it will take more time before it is ready.
Štěpán (@shenek) works intensively on Foris interface. You have probably noticed a lot of changes in TOS 3.11 like DHCP clients list, separate data collect module, DNS forwarding options, NTP configuration, etc. He modifies most of the Foris modules to be more compliant with PEP508.
Štěpán put all his effort during October to make MOX devices be easily configurable. MOX can run with a only single Ethernet interface – such device can’t act as a router anymore. This (and similar device setup) requires to add a new workflow into the Foris guide and a new mode for LAN tab.
On the end of December, he started the replacement of original Foris message bus ubus with mqtt message broker Mosquitto which will allow to configure the device using mqtt API over the network. This API would be used in new prepared mobile application.
Martin (@mpetracek) spent a lot of time on finishing TurrisHW, a library for detecting available interfaces on Turris MOX. In response to some bug reports, he reworked an archive feature of PaKon (our local network monitoring tool) which should solve the problems with huge databases. He also ported other parts of our data collection system to Sentinel – hopefully replacing uCollect in the following months.
Karel (@cynerd) worked on programmer software that supports MOX manufacturing. This part of the manufacturing process brings the dead silicon alive: it programs SPI flash memory and then it tests board. It also takes care about secret keys generation for the boards and stores public keys in our database.
As to the Updater, he reworked our repository layout for Turris OS 4.0 – you might have noticed new directories on our repo.
The second great feature in Updater is called relative URI which will allow us to link repositories or another script relative to the introduced script. This feature is needed with new network boot for MOX.
Karel also spent some time with refactoring and cleaning up Updater code so it would be more clear and maintainable in the future.
I have spent most of the time last two months preparing factory environment for MOX production. This environment consists of several “programmer” computers, database servers and a router – of course, Turris Omnia. Omnia takes care – besides the next – of persistent (Open)VPN connection to our server infrastructure, the database is replicated across three dbservers (one in our server infrastructure) because it holds crucial data from the production, and everything is Ansible-automated. So it is not big deal for us to tune PostgreSQL features or to deploy another programmer computer in the future.
Me, Štěpán and Robin have worked together to revise the device registration process as we want to drop some obsolete code and old Turris infrastructure components.
Michal worked on implementing this new registration process for Turris users and devices and the whole system we call My:Turris. Due to comfort user experience and security of user data, we will use Single-Sign-On design pattern for this web application. It will allow you to use all our services with only one account including login into (so-called) third-party services such as HaaS or our Cloud Backups.
Martin’s (@mprudek) work was divided into two main parts: Sentinel and Netmetr. Sentinel is our new data-collecting system that replaces uCollect. And Netmetr is a tool to measure the quality of Internet connection which you can simply install on your Turris device as well.
Martin worked on Sentinel:Checker component (which checks authenticity of Turris devices) and Sentinel:Dumper component (which stores Sentinel data into a database for later processing). Remarkable work (in cooperation with Robin) was also given to Sentinel:Monitoring: the concept of monitoring and debugging system for Sentinel network pipeline components.
Honza (@paja) updated security issues in packages like apache, git, openssh, nginx, curl, samba4, mosquitto, ntpd and so on. Some of these security fixes were sent to OpenWrt upstream repositories together with Unbound’s DNS64 module). Thanks to @Ondrej_Caletka for bug report! Honza also did some user-list reduction and cleanup in our feeds for upcoming Turris OS 4.0.