It’s been a long time (and hard days as well). We have got a lot of work with – mainly – TurrisOS 4.0 and other stuff related to it.
The last update was from May and we also spent some time to prepare this one. So I will introduce you about our work from June through September.
Marek
I will start with Marek, our kernel developer. Marek has recently sent patches supporting MOX into U-Boot. Some other patches (adding the proper functionality of different MOX modules) are ready and currently in testing. Our goal to have full support for all MOX modules in upstream U-Boot looks promising.
On the side of the mainline Linux kernel, Marek’s patches with support for the Armada 3720 watchdog has been accepted into the watchdog-next tree and are expected in Linux 4.20/5.0.
The driver for detecting MOX modules are connected is currently work-in-progress and the first version was already reviewed by kernel developers.
The developers of the Linux network subsystem have recently added support for SFP cages on DSA switch ports. Marek has backported these patches into the 4.14 LTS kernel (which will be used in Turris OS 4.0). So users will be able to plug the SFP module (MOX D) into the Super Ethernet module (MOX E) and everything will work correctly.
The most interesting consequence of all this is that once all these patches are in mainline Linux, power users will be able to install mainstream Linux distributions (OpenSUSE, Fedora, Gentoo, …) on MOX and all hardware will work “out of the box”.
Michal
Michal (@miska) pushes forward Turris OS releases. We have released several minor 3.10.x TOS versions since last dev update while working in parallel on 3.11 (which is in RC at the moment).
Michal works on the new build system for next major release as well (I mean the TOS 4.0). Various parts of TOS 4.0 are polished and it’s usable and testable. You have probably noticed he prepared a short description how to try it yourself.
Michal spent a lot of work on the MOX, its testing and preparing bits and pieces to integrate it with 4.0. There were plenty of kernel and U-Boot iterations but everything starts to calm down now. MOX is kind of special device as you expect different default behavior depending on modules you connect to main CPU board: different firewall settings, different networks on the same port and so. We have initial setup mostly covered nowadays.
Michal also started to work on MOX network boot feature and integration of rescue system. There is still some work left in this field, but we hope most important parts would be done soon.
Pepe
Pepe (@Pepe) – which you can know from here, forum, and/or our support – started out more about the packages in our repository. He really helps all of us with packages updates and some bug fixes while others work on Turris OS 4.0 and MOX.
He updated, for example, transmission and wireguard packages, he added Alpine Linux 3.8 image to our LXC containers repository. These updates were done mainly on your requests. The most interesting is owfs package update in upstream OpenWRT (together with help from Jan (@paja)). Pepe works on shadowsocks update with its libraries. Some of them are very important, so don’t underestimate anything, Pepe!
Karel
Karel (@cynerd) is the Master of Updater. He works mostly on Updater and Turris OS 4.0 preparation. The core of his work is to prepare Updater for new MOX and update it to be compatible with changes in current OpenWRT upstream. He was thinning the Updater to make it less memory demanding together with Bolek, our second updater developer. These optimizations are needed to support more constrained Turris MOX.
Karel took the chance to refactor and improve some of the core Updater components which should solve some long existing problems (such as buggy install script that could lead to stuck the Updater process). Unfortunately, not all of these changes are ready yet but you can expect them soon.
Rest of his work is dedicated testing TOS 4.0 and make sure that Updater is able to run on it. He also implemented some new components, such as the new way of changelog and news distribution for routers called turris-news.
Lastly, he is tied up with Turris MOX tester and programmer. This programmer is specialized board and companion software to program and test Turris MOX in the factory (read: to bring the HW alive).
Štěpán
Štěpán (@shenek) works on our Foris and its backend controller. He has done a lot of work which you can directly encounter on the Router web interface such as performance and UI improvements.
Not-so-visible internal changes are complete migration from Python version 2 to version 3, reworked Foris plugin subsystem and templates standardization. Foris now use standard Jinja 2 templates and each plugin is a regular python package. Migration to Python 3 includes backporting Python modules, libraries, and packages to TOS 3.x.
Another big and expected change is the replacement of the original Foris wizard with brand-new Foris guide. Foris wizard was originally a separate application but the guide will be integrated within Foris (you will be guided through Foris web interface during the initial Router setup).
Last but not least piece of work is to make Foris compatible with TOS 4.0 and add a posibility to configure network interfaces directly from Foris (this feature will be released in TOS 4.0).
Martin
Martin Petráček (@mpetracek) works mainly on our new modular data-collecting system, Sentinel. His part is the router-side applications. He created Sentinel:Proxy, the core router-side component and several data collecting modules, that will soon replace uCollect. The collected data are then processed on our servers and sent back to the router as firewall updates - to protect our users against detected threats.
Martin also made some improvements of Pakon and worked on software support for MOX, our upcoming router.
Me and others
I have, finally, fulfill my DevOps job and finished some real Dev work. I have developed a certification authority for Sentinel:Certificator (Sentinel:CA for short). Sentinel:Certificator is a set of components to take care of automated certificate issuing to routers. These certificates are used mainly to connect Sentinel:Proxy to our data-collecting servers confidentially. Other Sentinel:Certificator components (router-side client, http API, and database connector) is developed by Martin Prudek (@mprudek) and we were both (as well as other developers in the team) supervised by our development leader Robin.
I take care of all Sentinel:Certificator components deployment via Ansible as well as other Sentinel network “boxes” in future Minipot pipeline. This pipeline is ready to report collected data from “minipots” – for example, telnet honeypot.
Writing about prepared data-collecting system Sentinel reminds me still-running older uCollect system. This system is really near end of its life, as its dying database is proof of it. To be able to collect data to this old system, I had to realize the migration of a huge table to save some space and optimize. Playing with a hundreds-of-gigabytes table in poor-old db server is quite fun.
I also prepared new physical servers in another locality (another DC in another city). These servers will serve mainly as DB server for Sentinel, the hypervisor for app servers and build server for Turris OS 4.0 builds.
Conclusion
At the end of this post, I just want to say goodbye to our project leader Patrick who just left Turris in recent days. Good luck @tangero!
Well, this was though! I hope the next dev update will come a bit sooner.
