we just released Turris OS 3.9.4 into RC. It contains various security fixes but the main feature of this release is updated and much more robust HaaS integration. Full release notes are the following:
haas: update to the latest version
haas: more robust registration
kernel: update to the latest version, Sierra Wireless EM7565 drivers
Once again, after the update, the resolver init script was reenabled in /etc/init.d, even though I had explicitely and deliberately disabled it. I’m sorry, but I can’t trust TurrisOS. I’m switching to vanilla OpenWrt as soon as it officially supports the Turris Omnia.
I am not part of the RC test effort. Nevertheless, my TO just updated from 3.9.3 backwards to 3.9.1. I got following notification message:
Restart is needed
The system was updated, but some changes will take effect only after reboot. Please reboot the device.
The device will be restarted automatically on Monday, January 29 at 03:30 AM.
News announcements
• coreutils: update to the latest version
• uci: less sync calls - in theory a little faster commits
• hostapd: updated patches from LEDE
• kernel: update to the latest version
• pakon: more robust installation
• haas-proxy: more robust firewall integration
• updater: more robust updates and fixes to local repos handling
• knot-resolver: update to the latest version
• foris: updated translations and more diagnostics, fixed error on about page
Hello,
you was using knot-resolver which is by the default on Turris Omnia, but you decided to disable it?
Unfortunately, that’s the wrong way. How to do it.
Please see it here:
I have one wish: Can you stop doing releases on Friday afternoon? It’s really not the best timing to break things :-). Apparently while releasing RC something else messed up and everybody on stable branch is getting downgraded to 3.9.1:
I am not in RC branch. I have 3.9.3 and updater want to approve to update to Install kernel 4.4.105 and so on. I assume that is 3.9.4 RC - whats wrong?
updater.sh
WARN:Branch overriden to rc
line not found
line not found
line not found
ERROR:
unreachable: https://repo.turris.cz/omnia-rc/lists/base.lua: The requested URL returned error: 502 Bad Gateway
Working on message: 1516988356-7304
Working on message: 1516988416-7647
Most probable cause is that you have installed hass-proxy using opkg before it was introduced by userlists. That way you probably had it in /etc/updater/conf.d/opkg-auto.lua file too so it wasn’t removed automatically. That is feature not a bug .
If you want. I don’t think that I will be looking to it on my own because it seems to be as clear cut (if opkg remove resolves it). On my router just unchecking hass requires for its removal but of course that means nothing.
Ok then if you have time can you please reproduce it and send me three states of updater’s configuration? When haas is installed. When it’s deselected in foris. And when you removed it with opkg. Thank you in advance.
Edit: updater configuration means content of /etc/config/updater and /etc/updater/conf.d
I confirm the problem with HaaS when attacker tries connecting:
info twisted[]: [SSHService ssh-connection on SSHServerTransport,18,195.3.147.49] got channel direct-tcpip request
alert twisted[]: [SSHService ssh-connection on SSHServerTransport,18,195.3.147.49] channel open failed
alert twisted[]: [SSHService ssh-connection on SSHServerTransport,18,195.3.147.49] Traceback (most recent call last):
alert twisted[]: [SSHService ssh-connection on SSHServerTransport,18,195.3.147.49] Failure: twisted.conch.error.ConchError: (3, ‘unknown channel’)
In reality we were doing something to deploy. It wasn’t caused by rc deployment. There was a bug in medkit so we redeployed for omnia. There was no software change so there should have been no problems but something messed up deployment (most probably the deployment script it self). We are not sure yet what exactly is the cause but we did hotfix and debugging waits for me on Monday.
But I would like to say on our protection that I don’t see how any other day we would manage it other way. When we found out we did as much as we could to fix it no matter if it’s Friday or not. I don’t see how not releasing on Friday changes anything for users or for us. Either way we would be solving that problem outside of our work hours since you report it when you have time and not when we have time. And in the end it wasn’t such critical as it might seen (thanks to quick fix).
.
Warning regarding ssl-enable will not get installed automatically, rather on next lighttpd bump.