Revert back to dnsmasq

Hello,

quite some time ago if I remember correctly dnsmasq was the default name resolver on Turris. I had configured everything and it worked, I had couple of zones forwarded to different IP-s behind IPSec tunnels etc.

At some point the software updater did it’s trick and now there is kresd instead of dnsmasq, so everything I had configured stopped working. I have tried to manually stop and disable kresd and resolver, reconfigure dnsmasq, enable and start it, but occasionally still I see kresd running.

What can I do to permanently revert back to dnsmasq?

dnsmasq was never default resolver on Turris Omnia. You can force uninstall kresd if you want. Add to updater configuration following line:

Uninstall("knot-resolver", { priority = 60 })

But of course this is no way supported and might break in future. But for time being this should work.

1 Like

You gotta be kidding me. The updater reset my user.lua, so once again kresd and friends got reinstalled (and set dnsmasq port to 0). Should I just put a script in hook_postupdate that will manually install/uninstall the packages or will the updater find a way to undo that too?

I would really like to have confidence in the updater to not break the same things it’s been breaking for almost two years.

Or a working chattr +i as a last resort.

First thing. You are out of topic. Always create new one for your problem instead of cluttering existing unrelated one. Please learn how to use forum before our post.

Second thing. You gave me no information at all. Yeah updater reseted its configuration thanks I will debug that for years. Let me fix it next year.

Third thing. No, using hooks for installing or uninstalling packages is madness. You would weir out your flash and you would pretty much be spammed by updater every day.

Fourth thing. Chattr +i is simply wrong. Updater tries to be atomic and doesn’t expects that it can’t replace some file (it’s running as root). It would exit with error while letting journal behind for you to fix given problem and recover update. This potentially could break your system and definitely would break any future updates.

So please instead of just creating some crazy workarounds consider first to sensibly reporting problem and letting us fix it. Updater isn’t perfect and there is little to no feedback from user except of misplaced complaining.

So at least answer following questions: Version of Turris OS before and after update. If you have any hooks or configuration for updater (basically you can pack and send me whole /etc/updater directory). If you were using opkg and if you were doing something like opkg install --force-reinstall updater-ng or opkg upgrade. Or even opkg-trans -r updater-ng. Updater on its own won’t reset configuration files. Only to me known way is if you remove package first and then install it back because in such case updater just removed configuration during uninstall and it’s a known bug: https://gitlab.labs.nic.cz/turris/updater/issues/191.

2 Likes

I don’t believe it’s off topic, because the solution that was suggested above is not a working solution, and my root problem is the same as the thread poster’s. But, I’ll make a new thread if it helps.

Well, using dnsmasq for DNS isn’t supported, as noted above, but we’ve seen it used by some other users here on the forum, so they might have a way that works for them (for now). I suppose you want the same or something similar to OP.

Being not supported is a different league than force disabling it and force enabling another resolver during minor update. I expect such behavior from Microsoft, but not from Turris or another FOSS project.

For now, the “solution” is to reboot after update, immediately check whether DNS works, and if not, do the dance with disabling the resolver service and enabling the dnsmasq service. Sometimes, also wondering, why do I put up with such attitude and why I don’t run an resolver on some other device yet.

OpenWRT/LEDE managed to respect user settings for years. I don’t understand, why Turris can’t do the same.

2 Likes

I do agree that for an open source project this is not acceptable attitude. Even if you’re forcing users to use kresd, bare minimum you could do is to have decent page which describes differences compared to vanilla OpenWrt/LEDE and reasoning behind it. Also it would be helpful to have somewhere instructions how to do DNS forwarding according to suffix somewhere.

1 Like

Forwarding and other actions according to various rules: