Turris OS 3.11.2 is out!


#1

Dear Turris users,

We have released a minor release of Turris OS 3.11.2 from RC to everybody. It brings you new features (like updated syslog-ng, which can now send logs to Slack - more details here) and some improvements. There’s also updated Knot Resolver to the latest version, which will help in some corner cases.

Full release notes:
• knot-resolver: update improving behaviour without IPv6
• localrepo: fixed issue described here and here (for Czech users)
• mac80211: update to the latest version from LEDE 17.01
• pakon: fix sorting and other small issues
• foris: internal bus replaced by mosquito, if you are using mosquito, make sure it is still active
• uboot-mkimage and dtc: new packages
• kernel and various minor packages (e.g. syslog-ng, wireguard, youtube-dl, wget, samba, and so on): update

Enjoy!


Plné /tmp/ -> různé věci jsou rozbité
#3

Looks ok.
After restart there were many /etc/init.d/kresd restart processes, but they did what they wanted to and disappered.


#5

Needed first restart after installation and second restart to start data collection (closed ports and no collected) .


split this topic #6

9 posts were split to a new topic: CPU shows 100% usage


#7

Today’s update from RC to 3.11.2 resulted in an unwanted restart 3 minutes after updater finished. After this restart, network was unreachable for several hours. When I came home, I restarted the router manually and everything works. Not sure how syslog-ng and git update can break it like this… It might have been my ISP’s problem, but it got resolved at the exact same time I restarted the router. The logs do not say anything interesting…


#8

If I look in Pakon for “192.168.1.10” hostnames, it returns results for 192.168.1.10*, like 192.168.1.101.
Not sure if that is the desired behavior.


#10

Hi, since I installed Turris OS 3.11.2, I no longer get any firewall data for my router at the project.turris.cz website. ucollect data is appearing fine. nikola seems to be sending data regularly every 15 minutes per the below…is there anything else I can check? Is anyone else seeing this?

2019-01-16 22:45:01 info /usr/sbin/cron[26903]: (root) CMD (/usr/share/nikola/bin/nikola.sh)
2019-01-16 22:45:03 info nikola[]: (v43) recognized WAN interfaces: eth1, lo
2019-01-16 22:45:21 info nikola[]: (v43) Establishing connection took 1.012709 seconds
2019-01-16 22:45:21 info nikola[]: (v43) Logrotate took 0.020127 seconds
2019-01-16 22:45:21 info nikola[]: (v43) Syslog parsing took 0.056578 seconds
2019-01-16 22:45:22 info nikola[]: (v43) Session init took 0.734755 seconds
2019-01-16 22:45:22 info nikola[]: (v43) Records parsed: 11
2019-01-16 22:45:22 info nikola[]: (v43) Records after filtering: 11
2019-01-16 22:45:22 info nikola[]: (v43) Records filtering took 0.012788 seconds
2019-01-16 22:45:22 info nikola[]: (v43) {'msg': 'Data were inserted into work queue.'}
2019-01-16 22:45:22 info nikola[]: (v43) Sending records took 0.188130 seconds

Downtime: Firewall: 24 hours offline , uCollect: 0 hours sent
#11

Ano také mi neodesílá FW, ale Foris chybu odesílání neukáže, v datech firewall chybí. Začalo to 15.ledna v18:00. A nějak mi nejdou obvyklým způsobem vložit obrázky. Ani odkazem ani Ctrl-V.

    2019-01-16 19:00:01 err server_uplink[]: Failed to download contract status
    2019-01-16 19:00:02 info nikola[]: (v43) recognized WAN interfaces: eth1, lo
    2019-01-16 19:00:14 info nikola[]: (v43) Establishing connection took 0.586622 seconds
    2019-01-16 19:00:14 info nikola[]: (v43) Logrotate took 0.004578 seconds
    2019-01-16 19:00:14 info nikola[]: (v43) Syslog parsing took 0.067535 seconds
    2019-01-16 19:00:15 info nikola[]: (v43) Session init took 0.586223 seconds
    2019-01-16 19:00:15 info nikola[]: (v43) Records parsed: 71
    2019-01-16 19:00:15 info nikola[]: (v43) Records after filtering: 51
    2019-01-16 19:00:15 info nikola[]: (v43) Records filtering took 0.011610 seconds
    2019-01-16 19:00:15 info nikola[]: (v43) {'msg': 'Data were inserted into work queue.'}
    2019-01-16 19:00:15 info nikola[]: (v43) Sending records took 0.032709 seconds
    2019-01-16 19:00:34 err server_uplink[]: Failed to get registration code
    2019-01-16 19:00:55 err foris-controller[6332]: WARNING:turrishw:unsupported TOS version (on omnia): 3
    2019-01-16 19:01:00 err foris-controller[6011]: Last message 'WARNING:turrishw:uns' repeated 3 times, suppressed by syslog-ng on Omnia
    ```

![V%C3%BDst%C5%99i%C5%BEek2|687x165](upload://3EPZX22qowValZxss3HBdMXlQoH.jpeg) 

![a3|690x395](upload://kLQ2ZAKMCJwL8RlsATZ60o6sTXU.jpeg)

#12

logged bug https://gitlab.labs.nic.cz/turris/nikola/issues/17


Downtime: Firewall: 24 hours offline , uCollect: 0 hours sent
#13

Same here. Forris tells me FW data is send, but the server tells something different?


#15

foris: internal bus replaced by mosquito, if you are using mosquito, make sure it is still active

Why a new version was released whe I have to be on business trip ? :face_with_raised_eyebrow:
I missed this point and of course, Mosquito went down and I lost two days of sensors data :frowning:

Now I have two processes running:

turris ~ # ps -w  |grep mos
13256 109      10968 S    /usr/sbin/mosquitto -c /etc/mosquitto/mosquitto.conf
15335 mosquitt  3712 S    mosquitto -c /etc/mosquitto/mosquitto.conf
21523 root      1352 R    grep mos
turris ~ # 

Mosquito now works as before, but is it correct?


#16

You can try using pstree and see if one process is child of the other.


#17

Thanks.
There are two mosquitto servers - the second one is in homeassistant container. So it is not an issue.

  |-lxc-start---systemd-+-agetty
  |                     |-cron
  |                     |-dbus-daemon
  |                     |-hass---13*[{hass}]
  |                     |-mosquitto
  |                     |-mysqld---31*[{mysqld}]
  |                     |-rsyslogd---3*[{rsyslogd}]
  |                     |-sshd---sshd---sshd---bash-+-python3
  |                     |                           `-sudo---su---bash
  |                     |-systemd---(sd-pam)
  |                     |-systemd-journal
  |                     |-systemd-logind
  |                     `-systemd-udevd
  |-mosquitto
  |-mountd

#18

On my other router running stable TOS, syslog-ng was also stopped until automatic restart 3 days later. Was there a reason to not start syslog-ng before system restart? I know it got updated, but is there really something that blocks using it without restart?


#19

Hmm I’m still on 3.11 and automatic updates are enabled.

I’ve turned them on and off in foris
And I get this notice:
_Updater selhal: _

[string “backend”]:1194: [string “backend”]:1185: Failed to lock the lock file //var/lock/opkg.lock: Resource temporarily unavailable

Any advice?
Many thanks


#20

#21

As you can see above, I have the exact same error.
The updater wheel keeps on turning indeed.


#22

If you look into the thread there is a solution mentioned


#23

It looks like this was fixed on 18 Jan in the 3AM hour. From then until now project.turris.cz has been showing that it is receiving firewall data continuously. I guess this must have been a server side issue as nothing changed on my router.


#24

I have flashed my Omnia using latest medkit (3.11.2) and configured it using Foris only.

Unfortunately I am experiencing issues with OpenVPN. The connection cannot be established. There are no responses from the Omnia. Anybody else is experiencing similar behavior?