Turris OS 3.8 is out!

Community office
43

I believe that if you check “disable DNSSEC” in Foris/DNS, you will mostly get the pre-3.8 flavor of forwarding (except for better caching now). I suspect your ISP’s DNS servers obstruct some DNSSEC records or something like that.

2 Likes
44

Ahh thank you @vcunat. Disabling DNSSEC worked. I also just tried changing the DNS server to 8.8.8.8 and that worked fine with forwarding and DNSSEC enabled. It would appear my ISP’s DNS servers are the issue.

Is it safe to disable DNSSEC for the long-term? I’ve left forwarding off at the moment so that I can keep DNSSEC enabled. I guess my other option would be to use a different DNS provider (not Google… ) although I wouldn’t know who to trust.

45

If you trust cz.nic enough to use the router, you may want to forward to our public servers, assuming they are reasonably fast from your location. It’s also possible you will get better performance without forwarding, depending on your connection and the chosen servers to forward to. EDIT: to be clear, DNSSEC validation should work without forwarding basically everywhere. (Unless the ISP is specifically intercepting DNS packets to/from elsewhere.)

Is it safe to disable DNSSEC for the long-term?

I don’t want to hijack this thread. TL;DR: in most cases there are also some other security measures than DNSSEC, as knowing the correct IP doesn’t by itself guarantee even that you really get connected to a machine with that IP and not some middleman.

1 Like
46

@miska @cynerd
Could you please advice me how to get back a working webinterface?!
(or whom I need to contact to get those information quickly)

47

Great, thanks for that! Have updated it accordingly. (Indeed that contains the exact time my router died last night! :slight_smile: )

Glad it died at 8:48 PM, not 8:48 AM which was the other possibility…

That solves the issue for me, but clearly a Foris setting will be helpful for others in the future.

48

Yes, same story here. it did broke DNS for me as well, but disabling “use forwarding” and enabling “disable DNSSEC” solved the situation for now

49

Actually I updated /etc/opkg/customfeeds.conf:
src/gz omnia_turrispackages_old https://repo.turris.cz/archive/omnia/3.7.5/packages//turrispackages

Then I could opkg install transmission-web

1 Like
50

Did your update finished? What does /etc/init.d/lighttpd restart do? Do you remember anything that you did on your router that might have affected web interface (like install another webserver)?

51

Update fails repeatedly with following error:

Updater failed:
inconsistent: Package luci-ssl requires package libustream-polarssl that is not available.

Seems the same problem already happened in past, during update to 3.7:

In the version 3.7.5 the luci-ssl depends on libustream-openssl instead:

root@turris:~# cat /etc/turris-version
3.7.5
root@turris:~# opkg list | grep luci-ssl
luci-ssl - git-17.125.68803-99f44f6-1
luci-ssl - git-17.212.24321-49c3edd-1 - Standard OpenWrt set with HTTPS support
root@turris:~# opkg list-installed | grep luci-ssl
luci-ssl - git-17.125.68803-99f44f6-1
root@turris:~# opkg info luci-ssl
Package: luci-ssl
Version: git-17.212.24321-49c3edd-1
Depends: libc, luci, libustream-polarssl, px5g
Status: unknown ok not-installed
Section: luci
Architecture: all
Size: 946
Filename: luci-ssl_git-17.212.24321-49c3edd-1_all.ipk
Source: feeds/lucics/collections/luci-ssl
Description: Standard OpenWrt set with HTTPS support

Package: luci-ssl
Version: git-17.125.68803-99f44f6-1
Depends: libc, luci, libustream-openssl, px5g
Status: install user installed
Architecture: all
Installed-Time: 1502641056

root@turris:~#

52

  1. Did update finish?
    How can I check on that? The updater logfile shows no errors.

  2. etc/init.d/lighttpd restart works flawlessly

  3. what I did concerning kresd:
    Enter my public domain to etc/kresd/hints
    Create usr/sbin/kresd-fix.sh with content:

    #!/bin/bash
    HACK=mktemp -t kres_hack.XXXXXX
    echo “modules.load(‘hints > iterate’)” > $HACK
    echo “hints.config(’/etc/kresd/hints’)” >> $HACK

    socat $HACK UNIX-CONNECT:/tmp/kresd/tty/$(pidof kresd)

    rm $HACK

In /etc/rc.local added “/usr/sbin/kresd-fix.sh” before “exit 0”.

(see How to access lan ressources from guest network)

No other changes concerning webserver.

53

I am seeing:

2017-09-15T16:16:07+01:00 info procd[]: Instance lighttpd::instance1 s in a crash loop 6 crashes, 4 seconds since last crash

in my log. My turris v1 is crashing and rebooting every 2 minutes.

Edit: It’s been up for 10 minutes!

Edit2: It’s been up 17 minutes. I made no changes to it today. It started rebooting at 2 minute intervals for about 30 minutes and now seems to have stopped doing that. Weird.

54 
root@omnia:~# updater.sh
WARN:Script revision-specific not found, but ignoring its absence as requested
WARN:Script serial-specific not found, but ignoring its absence as requested
WARN:Requested package luci-i18n-ddns-en that is missing, ignoring as requested.
There is no message to send.

i have to say, this is one of the most botched updates for the omnia yet.

55

Seems like the update didn’t work for me:

Updater failed: 
inconsistent: Requested package https-cert that is not available.

I currently can not ssh to the router to investigate, but I’m not aware of doing something special about this package.

56

We discussed this today at the office and the conclusion is that we don’t want to give that ability to every user because than everybody would set it to some middle of the night and it that could potentially result to hight traffic on server. Currently every installation has random time generated during first updater-ng installation. I don’t see it as problematic for normal users. But I accept that for some users heavily relaying on internet connection during day it’s not optimal so I have now in todolist note about that and we will add it to documentation.

57

Yes that works now too (since 3.7 I think). But at the time writing of that article it did not. So I will some time in future update that documentation to contain also this solution.

Thank you for pointing that out.

1 Like
58

As I once wrote. If you don’t have heavily changed setup, then web server running on Turris is Lighttpd and SSL for it is provided by package lighttpd-https-cert and not luci-ssl. luci-ssl is broken and not supported.

59

Package https-cert was renamed to more appropriate lighttpd-https-cert. You probably have installed it in past by hand or you have some added configuration regarding of that package to updater configuration. To fix it just check /etc/updater/user.lua and /etc/updater/auto.lua files and replace https-cert with lighttpd-https-cert. I am sorry for inconveniences.

60

Just to be sure that you have just single instance of lighttpd running please restart your router. If it won’t help then please try to run lighttpd directly to see what is happening.

/etc/init.d/lighttpd stop
/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf
61

I realise that’s why it was set up the way it was. Maybe a more robust update install procedure could be in the longer term plans: for example downloading the full set of updates packages and dependencies at the random time, but only installing later at a fixed time or following a reboot, and only if there are no missing packages or conflicts.

The problem I had was the router stopped responding to dhcp and dns queries and I had no indication it was due to an update (it could have been a hardware issue, or pretty much anything) and hence I had to power it off and on. After the reboot I found the update was not complete and so I rolled back using schnapps and manually ran it again and debugged.

(I certainly don’t want to come across as being overly critical here; schnapps is superb for dealing with such issues and I’m generally delighted with the flexibility of the Omnia.)

2 Likes
62

This is probably bigger discussion. If you want to follow on it then please create new topic.

But reacting to your suggestions. We can do something like ability to prepare update (download all packages, do all checks and such) but don’t apply changes yet. That is possible but will be little bit bigger task as that is not something we had in mind during updater design phase. But it’s good tip. I am just against of applying it following the reboot as that requires user attention (do reboot) and that goes against automatic updates idea.

Also I see from you now that we should probably do some warning that updater is running as during that time we are really restarting network service so we are basically shutting down the router for short period of time from users point of view. So probably something like special changing led lights pattern might be handy to inform user on first sight that router is updating. In reality thanks to journal we can recover from reboot, but user is confused about what happened.

3 Likes