24 Zář
2021
24 Zář
'21
20:08
On 2021-09-24 09:57, Günther J. Niederwimmer wrote:
Hello Vladimir,
Am Freitag, 24. September 2021, 16:03:21 CEST schrieb Vladimír Čunát:
I think what you need to do here, is
ensure that:
1) after adding the service Group && Name entries
2) ensure that the knot-resolver (kresd) working directory is owned by root
*as well as its contents* --
# cd /knot-resolver/working/directoy
# sudo chown -Rh root .
3) restart the knot-resolver service
HTH
--Chris
On 24/09/2021 15.43, Günther J. Niederwimmer
wrote:
I heard / read from a user that knot resolver
must have its own rights for
the certificate, but that is not possible, because the key is also
intended for other computers and this creates a system risk? Is this a
design problem or a bug?
I would not suggest that the private keys should be world-readable.
Normal installation uses a special user and group for running Knot
Resolver, so you might e.g. switch the file to this group.
Running the daemons as root would seem a higher risk to me, but
otherwise it shouldn't be a problem either. Of course, you can't change
that in kresd.conf, as that's done on systemd level already. I think it
should suffice to use `systemctl edit kresd@.service` and add [Service]
User=root
Group=root
and the same with `systemctl edit kres-cache-gc.service`.
Unfortunately, that doesn't work that way? I then get error messages for the
paths and files in paths (permission denied)?
Apparently something is still being coded somewhere in the files? Since I
get
Lua errors
I am not a programmer, just a user, so I will not use "DNS over TLS" now and
try to use the knot-resolver sensibly to work!
--
mit freundlichen Grüßen / best regards
Günther J. Niederwimmer