Uninstall "knot-libdnssec" {priority = 60}
Uninstall "knot-libzscanner" {priority = 60}
Uninstall "knot-libknot" {priority = 60}
Uninstall "knot-resolver" {priority = 60}
Uninstall "unbound" {priority = 60}
Uninstall "unbound-anchor" {priority = 60}
Uninstall "dnsmasq" {priority = 60}
Uninstall "tinyproxy" {priority = 60}
Install "dnsmasq-full" {priority = 60}
Install "ntpd" {priority = 60}
Oh, I see. Well, there are some packages that are considered critical by the updater and wonāt let you mess too much with them, so it is a bit harder to destroy the system. I was confused about the label āremoving local packagesā, I thought you wanted to install something directly from .ipk file.
But yes, youāre right, it might make some sense to have just one resolver and be able to choose which one it is. Iāll hopefuly find some time to modify the server-provided configuration to allow this soon.
Alternatively, if you really wanted to mess with it, you can have a look at this file (https://gitlab.labs.nic.cz/turris/updater/blob/updater-ng/src/pkgupdate/configs/entry.lua) and create your own configuration from scratch. Then you can disable the updater in foris and run it yourself with the top-level configuration of your own. But then, there are of course no warranties about what will go wrong.
Hmm, why is it so complicated, and how can knot or unbound be considered critical software? This is something strictly optional, and I see no reason why the updater should be preventing these packages from being removed.
I donāt really want to create a new configuration from scratch, why would I? I just want to remove a few packages I never wanted to have to begin with.
Well I would say that DNS resolver is pretty critical.
Thereās a DNS resolver built into libc which is enough for most tasks, given that knot-resolver canāt be critical piece of software.
A bit longer answer than one of my collegue.
It is so complicated, because it is a router and it needs to do attention-less upgrades. If you have a server and do apt-get upgrade, it can ask questions. We canāt. The updater needs to solve the problems it has with the rules and flags it has. Furthermore, we wanted to be on the safe side, so we forced the ācriticalā flag onto everything that is the very base TurrisOS system.
The stub resolver in libc is not enough, for several reasons. For one, it is a router. It is supposed to provide real resolution to such stub resolvers on the devices on your LAN. Omnia uses knot, you can alternatively switch to unbound. We donāt really support anything else, because, you know, thereās only limited amount of manpower and we canāt just test everything.
As the router uses its own resolver as well, removing it would break the internet access both to other devices on your LAN and the router itself, further preventing it from downloading any packages in manual attempt to fix that.
Depending on your OS on computer, if you try to remove some important parts, like libc or kernel, youāll be prevented from doing that or youāll be at least given a very loud warning. We canāt opt for the warning, because the updater needs to work on its own if the repository changes. So it canāt really decide to get rid of some of these things because it collides with some other request.
Yes, I agree that, in some cases, we marked more than absolutely necessary as critical. We try to err on the safe side. As I said, Iāll have a look at making it more flexible and allowing some more freedom. But I still think it is quite reasonable to mandate that DNS resolution must work both on the router and on LAN.
2 Likes
I supported quite a few routers with DNS forwarding and local DNS resolution, and Iāve never had problems with the built-in resolver. In this configuration, I prefer dnsmasq for both DNS and DHCP as itās an integrated solution which handles dynamic DNS updates, DHCP, RA+DHCPv6 and DNS forwarding without extra configuration. Apart from that, I already have dnsmasq configuration from a different device which just works until Omnia updater breaks it by removing dnsmasq-full and installing unbound and knot. Apart from that, there having a daemon which answers on port 53 really isnāt a requirement for a router, other machines on a local network can just use the routerās upstream DNS.