Updater reinstalls kresd+unbound, overwrites statistics config

Software SW help
1

I used the following code in my /etc/updater/user.lua as suggested in another thread:

--[[
A place for user definitions.

Repository "name" "URI" { ca = "file:///etc/ssl/ca.pem", pubkey = "file:///etc/repo.pubkey" }
Install "pkgname" "other"
]]
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 "tinyproxy" {priority = 60}


Install "dnsmasq" {priority = 60}
Install "ntpd" {priority = 60}

However, updater still reinstalls unbound, unbound-anchor, and knot-resolver.
Also, the updater overwrote certain configs (namely statistics). Is there a way to fully block config overwrites?

2

You are trying to remove critical packages, see here: Updater is removing local packages

If some configurations are override by updater, than it is fault of package it self (being confident that it isn’t udater bug). There are two options why it happens, it can be because file isn’t specified as configuration file or because there is some post-install script that does something to that configuration. In both cases it requires fix in package it self. What package is causing you problems?

3

If I want to uninstall a critical package and sets it as uninstall critical with priority 60. Will be it uninstalled?

I don’t know the correct syntax, but something as (/etc/updater/user.lua):
Uninstall "knot-libdnssec" {priority = 60, critical = true}

I don’t go to use it at this time, but I’m curious about it.

4

No. Critical is Install command extra option only.

Just being more verbose. Critical means that we need it in system. From this point critical unistall makes little bit of sense. What you all encountering is way it is handled in packages planing, all critical packages are planned first ignoring any priority settings. But critical means more than that. If request is critical, updater tries harder to make install process of it consistent, it for example wont install it if it is in cyclic dependency (that would result in unconsistent state during update). So uninstalling such package just goes against updater’s goal. Correct way of handling it would be from configuration scripts. But that is not possible currently most probably, because script inserting these critical packages is downloaded from our servers. But in reality there are more pressing issues. This with small exceptions (specially dnsmasq) means just that there are some files in system installed but don’t have to be used, TO has enough memory. And small final point, we are not currently advertising any support limitations for TO, but it is probable that in future our support team will have specified boundaries of what we support and what not and replacing critical packages would most probably not be supported. I mean by our support team, we always accept patches and bug reports to any software running on TO, difference is just that supported software will probably receive more care.

5

Your users don’t think knot-resolver is a critical bit of software. What is higher priority for you, your users, or your idea of what ‘critical’ means? It seems to me most of the users want to be in control of the system, yet you seem to imply they cannot be.

This isn’t a very good attitude, I must say.

2 Likes
6

Let me put this strait. Knot is CZ.NIC creation and will be in TO. As I and vorner mentioned here on forum, we know about issue of not possibility to replace critical package by their alternatives. But in case of Knot you don’t have to use it, but it must be in system for now (unless some crazy hacking is done). And more importantly Knot will be most probably only supported DNS server (that means support by developers will be given), simply because we can’t support everything and Knot have to be supported.

From my point of view, users are in control of system. And if they don’t want any interventions from cz.nic they can disable updater or even build their own version of Turris OS. It’s not like it is closed system without source codes and in case of updater disable it is even single button. But everything is two way business, users want support, but support can’t be reasonably given if we don’t have some known base. If you don’t want that base, then it is most probably out of our possibilities to support you.

It’s not like we don’t want to allow you that, but currently look here on forum and you will see that we have more pressing issues and we solve problems in order of their priority. Common answer in open-source is, if you need something fast, you can always send patch.

2 Likes