DNS+Auto updates are still a mess 9 months later

Software SW bugs discussion
1

This is really my only major complaint about the Omnia, but it’s ridiculous that one of the main selling points of the Omnia (auto updates) can be such a nightmare. All I want is for it to stop trying to install other DNS-related packages and just use dnsmasq-full for everything DNS and DHCP related, rather than trying to use some combination of dnsmasq/unbound/kresd/whatever else.

This certainly isn’t anything new. There are questions (including mine) dating all the way back to January, as well as some more recent. It’s a total deal-breaker to have to jump through so many hoops just to use the “automatic” updates. I had to do the workaround described here just to get the update to work, let alone clean up the aftermath.

The addition of the “Install”/“Uninstall” features in /etc/updater/user.lua was a welcome addition, but for some reason they’re crippled by the fact that “basic system” packages will completely override that and install themselves anyway. The whole point of those keywords is to give the user control, but it ends up falling flat on the actual important bits of the system. If a package is blacklisted by the user, it shouldn’t install, period.

I thought for a while that I would be able to circumvent the issue by simply leaving those packages installed, but disabling their services. But even then, you run into issues like this. It seems the only way to make sure your system doesn’t get broken randomly by updates is to either:

  1. Disable automatic updates
  2. chattr +i anything of value
  3. Use the default set of packages
    OpenWRT/Turris doesn’t come with chattr, so #2 is out of the question. As for #3, well, there’s a reason I’m not using the default packages, so that’s not really a solution either. All you can really do is re-enable updates every so often when you’ll have a couple hours to fix whatever got broken.

Lastly, there’s also the odd choice to either have updater disabled completely, or update automatically. You can’t set it to “update manually”. This isn’t a huge deal, since you can just enable updater when you want to update, but still seems odd.

2 Likes
2

Don’t tell me. I agree, auto-updates are nightmare. Users are changing default packages configuration and they are messing with files from installed packages and then they are surprised.

Yep kind of solution.

Thanks god. You would end up with failed updates every time I suspect.

Yes that’s the one…

Eh we didn’t noticed. We have no way code prepared for that from way back: https://forum.test.turris.cz/t/how-do-you-setup-manual-system-updates/2155/10

Jokes aside. As mentioned multiple times here on forum (it just might be lost somewhere not possible to found it out) that I know about this issue and that I am working on it. For technical reasons we had to insist on some defaults. Real reason was just that updater-ng just wasn’t yet fully functional (it’s not even now, I have some major issues to solve). It took longer than expected, but updater-ng had required feature for about five months now (they are already released to you) and next job to be done was just complete rework of userlists (think that specifies basic packages). I finished that about moth ago. It now awaits the next major release. It took longer than expected, but what does not.

So after Turris OS 3.8 you will be able to install dnsmasq-full (which automatically removes dnsmasq) and also optionally remove even knot-resolver (not using opkg but using user.lua file).

Sorry for such light tone, but you are complaining about stuff that are already solved and just waits for release, so I can just make jokes about it. You can see changelog for next release here: Files · test · Turris / openwrt · GitLab

2 Likes
3

I disabled auto-updates a long time ago, cause even tough I managed to use the lua files to exclude stuff I don´t want to be installed, the automatic updates overwrote my config files without asking. This is an absolute no-go. As you told it just disabled dnsmasq again and I wondered why my setup was not working.

So from time to time use the following little script to update:

root@amrita:~# cat update.sh 
#!/bin/sh
get-api-crl
pkgupdate

That way it never touches my config files, but stuffes the new files into -opkg files

WARN:Config file /etc/updater/user.lua modified by the user. Backing up the new one into /etc/updater/user.lua-opkg
WARN:Config file /etc/updater/auto.lua modified by the user. Backing up the new one into /etc/updater/auto.lua-opkg

I then use find -name *.opkg to find those files and look whether there is anything I need to add to my current config files. Often there is nothing to change for me. I remove every *.opkg file after reviewing it.

What I am missing tough is a notification of my Turris when new updates are available. It usually sends me a mail after I installed a larger update, but does not notify me.

Also I even may agree to auto updates if I can tell it to leave my config files allow and notify of any new -okpg files to review.

4

What a coincidence, you have just reimplemented updater.sh script. If you look closely here Sign in · GitLab you would see that that is exactly what our updater.sh script does. Just ignore all stuffs like timeouts, backgrounding, approvals and notifications.

That is not what updater does. Packages should be blamed for it. They should specify what files are configurations. If they fail to do so then both updater-ng and opkg just replaces such file with shipped version. So consult package it self not automatic updates.

Could be new feature.

5

Nope. Its not exactly the same. First it adds a --batch option in case its running in the background, and then it does some approval magic:

# Check if we need an approval and if so, if we get it.
APPROVALS=
config_get_bool NEED_APPROVAL approvals need 0
if [ "$NEED_APPROVAL" = "1" ] ; then
	APPROVALS="--ask-approval=$APPROVAL_ASK_FILE"
	# Get a treshold time when we grant approval automatically. In case we don't, we set the time to
	[… shell magic …]
else
	# If approvals aren't enabled then run always in batch mode (don't ask user)
	PKGUPDATE_ARGS="$PKGUPDATE_ARGS --batch"
fi
# Run the actual updater
ptimeout 3000 pkgupdate $PKGUPDATE_ARGS --state-log --task-log=/usr/share/updater/updater-log $APPROVALS
EXIT_CODE="$?"

I didn´t research what exactly this does. Maybe that need approval option is by default switched off and it is exactly the functionality I´d like to see, but its not finished yet: To be able to approve individual updates. I also don´t know where that config is supposed to be set, but it doesn´t appear to be set yet in any of the files in /etc/config:

root@amrita:/etc/config# grep -i "approval" *
root@amrita:/etc/config#

So maybe that approval thing is unused here… but there is still the additional --batch option when run in background.

What ever that changes, my personal experience is exactly that:

  • When I activated the auto updater from the Foris web interface quite some time back for testing things it overwrote all updated config files unconditionally. Maybe with Turris 3.7.4 this has changed, but that was the behavior I have seen. Please don´t argue with me about this. I know what I have experienced. So please stop wasting my time by denying it.
  • As soon as I started to use my simple update script, it never again overwrote any config file.

Now guess what I am using now. Of course as your updater script does not seem to set the option --batch when I am calling it from the command line, I think, it may be just safe to use it instead of my script, but seriously, how was I supposed to know without first reading the whole script? My script is three lines. Yours is a lot longer.

I do not feel any motivation to try activating auto updates again, until you show me a way it won´t change any config file without my approval anymore. If it already does by default in Turris 3.7.4, please tell me. If it doesn´t, then what option do I need to set?

Really please take user feedback seriously. Its certainly not my job to reverse engineer the scripts you have done… my simple wish is: Leave my config files alone, or ask me about it. And if you can´t implement this with unattended upgrades, then notify me of any upgrade and tell me exactly what command to use in order to have it upgrade the stuff without touching my config files. They are mine. All mine.

Thank you,
Martin

6

Yes it’s exatly the same in that meaning. What --batch does is that pkgupdate will allow you to confirm changes on system (what packages will be removed and what will be installed). And approvals is just a way to do it trough web interface with notification. That’s all. Non of that has nothing to do with configuration files.

And I take user feedback seriously. I am just telling you with light tone that you are wrong. Updater doesn’t overides configuration files and in public release it newer did. Only change latelly (about a half a year back) were those -opkg files (originaly new files were just discarted). If it would be updater’s fault, than every update would essentialy bricked router as it would wipe out all configurations. You are barking on wrong tree. As I wrote, packages are the cause. If package won’t specify that given file is configuration then file is just replaced. And in case of for example dnsmasq it’s just a problem of post install script not working correctly (I think some of us looked in to it already so that might be fixed and that is why you have no problems now).

I don’t want to argue nor I wan’t to prove you anything. I just don’t want to let wrong informations just sit here without me addressing it.

7

Guys, let’s be constructive, please.

It is certainly possible that there are bugs. Whenever an update overwrites something it should not, please report it and make the report as specific as you can.

Saying ‘it overwrote everything’ does not help to fix the issue but telling ‘it overwrote file /etc/whatever and /etc/somethingelse’ will actually help to fix the problem in affected packages.

Thank you for understanding and patience.

8

Okay, I admit, I didn´t check whether it overwrote all config files. I was generalizing here. Sorry, I was upset, not thinking clearly, cause it felt to me as if you weren´t taking my feedback seriously. I think I received your “light” tone as disrespect.

However… with using my update script I never had it again that it deactivated dnsmasq – that observation was right. Of course maybe you fixed it in dnsmasq package and this was just a coincidence – all I experienced was: I enabled auto updating => dnsmasq broken, I used my own script, no issue – so I did just that. I still feel reluctant about enabling auto updates again. I didn´t find it funny to have to set IP address on laptop manually after an update. But I may try it… I see a log about tasks in “/usr/share/updater/updater-log”. Is there also a log what new config files opkg installs? Then I would have a way to pinpoint any issues. Well, of I also have config files in git, so I should be able to detect changes from there.

9

I know next to nothing about updates and packaging on OpenWRT but I’m a Knot Resolver person. I want to ask you: What functionality is missing in Knot Resolver and what forces you to go to dnsmasq? I would like to know so we can prioritize it accordingly.

Thank you for your time.

2 Likes
10

It’s not so much missing functionality, more so that having to use a separate package for DNS and DHCP (and configuring them to talk to each other to provide DHCP host name resolution) is just additional points of failure.

As for the additional features that knot provides, either dnsmasq-full provides them (dnssec, rudimentary support for views), or I just don’t need them. I get that it has a ton of features, I just wouldn’t be using them.

I would say, at the very least, “knot using dnsmasq to resolve local hostnames” is something that should work out of the box (maybe it does already on fresh installs of newer versions). Seeing as it didn’t, my options were “go back to dnsmasq like I have on every prior OpenWRT version” (it just works) or configure dnsmasq in a nonstandard way, learn kresd which I’ve never touched before, and configure it to talk to dnsmasq.

11

To come up with yet another example: I’m utilising dnsmasq’s ability to automagically serve MX records for the internal LAN.

TBH, I do not know whether KNOT is able to do that as well (but I rather assume it is not).

12

No, knot-resolver can’t do that currently in a trivial way. (E.g. a lua module for this could be written or something.) You want something like the “mailhub” use case, I guess?

On the whole, the integration between DHCP and DNS on Omnia certainly doesn’t have as much features as when using dnsmasq for both.

13

Not only that but if you plan on using ipsets for domain based selective VPN routing, you also need dnsmasq to play ball and that’s nigh on impossible with Knot as far as I’m aware.

I ended up taking the drastic step of removing Knot entirely so I just had dnsmasq-full and nothing else left over.

EDIT (3 Oct 2017): As of Turris OS 3.80 onwards, you no longer need to take the drastic step of uninstalling Knot etc. Simply uninstalling dnsmasq, installing dnsmasq-full instead and disabling Knot + Resolver will suffice. This also prevents any issues going forwrd when trying to update the OS.

14

[UPDATE: On subsequent tests this now appears to work, read end of post]

With Omnia Turris 3.8 I just added

Install("dnsmasq-full")
Uninstall("knot-resolver")

to /etc/updater.user.lua, ran updater.sh

After that dnsmasq was not running.

I did:

 /etc/init.d/dnsmasq start

and after a while dnsmasq was running just fine.

Well thus I did:

/etc/init.d/dnsmasq enable

to make sure it is enabled and rebooted again.

Again dnsmasq is not running. Any advice?

The updater.lua + updater.sh appeared to be working. I don´t have output anymore as it was in a screen that I closed. But I do have

root@amrita:~# opkg list | grep dnsmasq
dnsmasq-full - 2.73-5
root@amrita:~# opkg list | grep knot
root@amrita:~#

Hmmm, now as I wanted to reproduce the contents of /var/log/messages after reboot it worked out of the box. I tried another time. Okay, it appears to work. Strange. Maybe I didn´t wait long enough for dnsmasq full to startup… I hope it will work reliably on each boot now, I report back.

2 Likes
15

Okay, this works reliably. Maybe just took a bit longer initial. So only on dnsmasq-full now.