[opensuse] unbound as recursive DNS server - question about setup.
I tried to set up unbound with 15.2 but ran into serious difficulty. Is there any guideline on how to set up unbound as recursive dns server with e.g. 15.1 (I had to go back because of compatibility problems). What actually happened was that it claimed either syntax errors, or was not able to run without dnsmasq installed. Both should not be the case. In particular the QNAME Minimisation did not work after the install which induces me to belief that it was just still dnsmasq to be used.That is why without it, it did not work any more. So, if there is an official Leap howto on this, I would appreciate. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
I tried to set up unbound with 15.2 but ran into serious difficulty. Is there any guideline on how to set up unbound as recursive dns server with e.g. 15.1 (I had to go back because of compatibility problems).
I would not expect anything in the unbound setup to be specific to either release. We did have a change to bind recently, enforcing dnssec by default, any chance the same might have been done to unbound ?
What actually happened was that it claimed either syntax errors, or was not able to run without dnsmasq installed. Both should not be the case. In particular the QNAME Minimisation did not work after the install which induces me to belief that it was just still dnsmasq to be used.That is why without it, it did not work any more.
So, if there is an official Leap howto on this, I would appreciate.
I don't know if we have one, I would use the one from archlinux. -- Per Jessen, Zürich (6.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
I tried to set up unbound with 15.2 but ran into serious difficulty. Is there any guideline on how to set up unbound as recursive dns server with e.g. 15.1 (I had to go back because of compatibility problems).
I would not expect anything in the unbound setup to be specific to either release. We did have a change to bind recently, enforcing dnssec by default, any chance the same might have been done to unbound ?
What actually happened was that it claimed either syntax errors, or was not able to run without dnsmasq installed. Both should not be the case. In particular the QNAME Minimisation did not work after the install which induces me to belief that it was just still dnsmasq to be used.That is why without it, it did not work any more.
So, if there is an official Leap howto on this, I would appreciate.
I don't know if we have one, I would use the one from archlinux. It was not unbound the compatibility question but heavy data loss and kmail
In data mercoledì 4 novembre 2020 17:28:00 CET, Per Jessen ha scritto: that was / is disfunctional in 15.2. Every try to install this version results in emergency shutdowns and blocked system etc. So since I had the install done, I do not think that the DNSSEC thingy would be a problem. Unbound uses dnssec as default. It is actually quite well done but I was not able to start the server in a way that I am able to use it. What do we usually use in our system to solve DNS? I would suppose we are not using the systemd solver but maybe dnsmasq? We are not using bind as bind is not installed by default. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2020 20.59, Stakanov wrote:
What do we usually use in our system to solve DNS? I would suppose we are not using the systemd solver but maybe dnsmasq? We are not using bind as bind is not installed by default.
I use dnsmasq, but I have one machine with bind. I've never used unbound, news to me. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq. -- Per Jessen, Zürich (6.8°C) http://www.hostsuisse.com/ - dedicated server rental in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use. Oh, they say this also from unbound (which is very safely designed and has rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight. I went through the config, apparently I have no errors. But now...I get: ● unbound.service - Unbound recursive Domain Name Server Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto: preset: disabled) Active: failed (Result: exit-code) since Wed 2020-11-04 23:32:33 CET; 2min 6s ago Process: 6301 ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS (code=exited, status=1/FAILURE) Process: 6299 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS) Process: 6288 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS) Main PID: 6301 (code=exited, status=1/FAILURE) Nov 04 23:32:33 roadrunner systemd[1]: Starting Unbound recursive Domain Name Server... Nov 04 23:32:33 roadrunner sudo[6288]: root : TTY=unknown ; PWD=/ ; USER=unbound ; COMMAND=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key - c /etc/unbound/icannbundle.pem Nov 04 23:32:33 roadrunner unbound-checkconf[6299]: unbound-checkconf: no errors in /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: Started Unbound recursive Domain Name Server. Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] error: Could not open /etc/unbound/unbound.conf: Permission denied Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] fatal error: Could not read config file: /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Unit entered failed state. Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Failed with result 'exit-code'. which surprises me to some extend. This because I did not change for the moment the standard setting of the package to chroot which will then require full path (set to ""). So if the program is capable to check the correct syntax, why unbound then cannot read its own config when starting? I am puzzled. Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem root has rw and owner read. All seems OK. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2020 23.46, Stakanov wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use. Oh, they say this also from unbound (which is very safely designed and has rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight. I went through the config, apparently I have no errors. But now...I get: ● unbound.service - Unbound recursive Domain Name Server Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto: preset: disabled) Active: failed (Result: exit-code) since Wed 2020-11-04 23:32:33 CET; 2min 6s ago Process: 6301 ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS (code=exited, status=1/FAILURE) Process: 6299 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited, status=0/SUCCESS) Process: 6288 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS) Main PID: 6301 (code=exited, status=1/FAILURE)
This is very strange to me. A system service calling sudo? Why? Using sudo needs a matching sudo configuration, and administrators change it. Mine is changed, for instance.
Nov 04 23:32:33 roadrunner systemd[1]: Starting Unbound recursive Domain Name Server... Nov 04 23:32:33 roadrunner sudo[6288]: root : TTY=unknown ; PWD=/ ; USER=unbound ; COMMAND=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key - c /etc/unbound/icannbundle.pem
I would look at the full syslog around 23:32:33.
Nov 04 23:32:33 roadrunner unbound-checkconf[6299]: unbound-checkconf: no errors in /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: Started Unbound recursive Domain Name Server. Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] fatal error: Could not read config file: /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Unit entered failed state. Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Failed with result 'exit-code'.
which surprises me to some extend. This because I did not change for the moment the standard setting of the package to chroot which will then require full path (set to ""). So if the program is capable to check the correct syntax, why unbound then cannot read its own config when starting?
Permission denied. It is not running under the correct user, or the permissions are not what it expects.
I am puzzled.
Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
root has rw and owner read. All seems OK.
But it tries sudo.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use.
Oh, they say this also from unbound (which is very safely designed and has rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight. I went through the config, apparently I have no errors. But now...I get: ● unbound.service - Unbound recursive Domain Name Server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor
preset: disabled)
Active: failed (Result: exit-code) since Wed 2020-11-04 23:32:33 CET; 2min
6s ago
Process: 6301 ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS (code=exited,
status=1/FAILURE)
Process: 6299 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited,
status=0/SUCCESS)
Process: 6288 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor> -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
Main PID: 6301 (code=exited, status=1/FAILURE)
This is very strange to me. A system service calling sudo? Why? Using sudo needs a matching sudo configuration, and administrators change it. Mine is changed, for instance.
Nov 04 23:32:33 roadrunner systemd[1]: Starting Unbound recursive Domain Name Server... Nov 04 23:32:33 roadrunner sudo[6288]: root : TTY=unknown ; PWD=/ ; USER=unbound ; COMMAND=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key - c /etc/unbound/icannbundle.pem
I would look at the full syslog around 23:32:33.
Nov 04 23:32:33 roadrunner unbound-checkconf[6299]: unbound-checkconf: no errors in /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: Started Unbound recursive Domain Name Server. Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] fatal error: Could not read config file: /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Unit entered failed state. Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Failed with result 'exit-code'.
which surprises me to some extend. This because I did not change for the moment the standard setting of the package to chroot which will then require full path (set to ""). So if the program is capable to check the correct syntax, why unbound then cannot read its own config when starting?
Permission denied. It is not running under the correct user, or the permissions are not what it expects.
I am puzzled.
Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
root has rw and owner read. All seems OK.
But it tries sudo. It tries sudo because it is needed for the ancor file. But even when I did set up sudo with a user unbound (which it is) in yast sudo with: user unbound, host all, RUNAS all, NOPASSWORD yes Commands all (which is if I understand terrible, then it still has the same error when starting up. Cannot read the damn conf. And I am lost.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote: > What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use.
Oh, they say this also from unbound (which is very safely designed and has rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight. I went through the config, apparently I have no errors. But now...I get: ● unbound.service - Unbound recursive Domain Name Server
Loaded: loaded (/usr/lib/systemd/system/unbound.service; enabled; vendor
preset: disabled)
Active: failed (Result: exit-code) since Wed 2020-11-04 23:32:33 CET; 2min
6s ago
Process: 6301 ExecStart=/usr/sbin/unbound -d $UNBOUND_OPTIONS (code=exited,
status=1/FAILURE)
Process: 6299 ExecStartPre=/usr/sbin/unbound-checkconf (code=exited,
status=0/SUCCESS)
Process: 6288 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor>
-a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
Main PID: 6301 (code=exited, status=1/FAILURE)
This is very strange to me. A system service calling sudo? Why? Using sudo needs a matching sudo configuration, and administrators change it. Mine is changed, for instance.
Nov 04 23:32:33 roadrunner systemd[1]: Starting Unbound recursive Domain Name Server... Nov 04 23:32:33 roadrunner sudo[6288]: root : TTY=unknown ; PWD=/ ; USER=unbound ; COMMAND=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key - c /etc/unbound/icannbundle.pem
I would look at the full syslog around 23:32:33.
Nov 04 23:32:33 roadrunner unbound-checkconf[6299]: unbound-checkconf: no errors in /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: Started Unbound recursive Domain Name Server. Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] fatal error: Could not read config file: /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Main process exited, code=exited, status=1/FAILURE Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Unit entered failed state. Nov 04 23:32:33 roadrunner systemd[1]: unbound.service: Failed with result 'exit-code'.
which surprises me to some extend. This because I did not change for the moment the standard setting of the package to chroot which will then require full path (set to ""). So if the program is capable to check the correct syntax, why unbound then cannot read its own config when starting?
Permission denied. It is not running under the correct user, or the permissions are not what it expects.
I am puzzled.
Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
root has rw and owner read. All seems OK.
But it tries sudo.
It tries sudo because it is needed for the ancor file. But even when I did set up sudo with a user unbound (which it is) in yast sudo with: user unbound, host all, RUNAS all, NOPASSWORD yes Commands all (which is if I understand terrible, then it still has the same error when starting up. Cannot read the damn conf. And I am lost. I will check two things: apparmor (but that I tried to de-activate (I am however sure it might, once I set up the profile, require the "change hat
In data giovedì 5 novembre 2020 02:17:52 CET, Stakanov ha scritto: package". If not, it is might be an issue of PAM? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/11/2020 02.17, Stakanov wrote:
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto:
Process: 6288 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor> -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
Main PID: 6301 (code=exited, status=1/FAILURE)
This is very strange to me. A system service calling sudo? Why? Using sudo needs a matching sudo configuration, and administrators change it. Mine is changed, for instance.
Nov 04 23:32:33 roadrunner systemd[1]: Starting Unbound recursive Domain Name Server... Nov 04 23:32:33 roadrunner sudo[6288]: root : TTY=unknown ; PWD=/ ; USER=unbound ; COMMAND=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key - c /etc/unbound/icannbundle.pem
I would look at the full syslog around 23:32:33.
Nov 04 23:32:33 roadrunner unbound-checkconf[6299]: unbound-checkconf: no errors in /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: Started Unbound recursive Domain Name Server. Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
But it tries sudo. It tries sudo because it is needed for the ancor file.
Why? If it has to run a command as another user, the correct thing to do is use "su username -c command", not sudo, which is not guaranteed to work. This is not Ubuntu.
But even when I did set up sudo with a user unbound (which it is) in yast sudo with: user unbound, host all, RUNAS all, NOPASSWORD yes Commands all (which is if I understand terrible, then it still has the same error when starting up. Cannot read the damn conf. And I am lost.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data giovedì 5 novembre 2020 11:40:18 CET, Carlos E. R. ha scritto:
On 05/11/2020 02.17, Stakanov wrote:
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto: Process: 6288 ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor>
-a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem (code=exited, status=0/SUCCESS)
Main PID: 6301 (code=exited, status=1/FAILURE)
This is very strange to me. A system service calling sudo? Why? Using sudo needs a matching sudo configuration, and administrators change it. Mine is changed, for instance.
Nov 04 23:32:33 roadrunner systemd[1]: Starting Unbound recursive Domain Name Server... Nov 04 23:32:33 roadrunner sudo[6288]: root : TTY=unknown ; PWD=/ ; USER=unbound ; COMMAND=/usr/sbin/unbound-anchor -a /var/lib/unbound/root.key - c /etc/unbound/icannbundle.pem
I would look at the full syslog around 23:32:33.
Nov 04 23:32:33 roadrunner unbound-checkconf[6299]: unbound-checkconf: no errors in /etc/unbound/unbound.conf Nov 04 23:32:33 roadrunner systemd[1]: Started Unbound recursive Domain Name Server. Nov 04 23:32:33 roadrunner unbound[6301]: [1604529153] unbound[6301:0] error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
But it tries sudo.
It tries sudo because it is needed for the ancor file.
Why?
If it has to run a command as another user, the correct thing to do is use "su username -c command", not sudo, which is not guaranteed to work. This is not Ubuntu.
But even when I did set up sudo with a user unbound (which it is) in yast sudo with: user unbound, host all, RUNAS all, NOPASSWORD yes Commands all (which is if I understand terrible, then it still has the same error when starting up. Cannot read the damn conf. And I am lost. Carlos, with all the given respect. The package is original opensuse. I just followed the indications first of a manual found on an Ubuntu linked site (never used it). Blame it on missing documentation in openSUSE. I could have used Arch or any other site. I then found the original site of the project. No difference. You see, the sudo thing is something the packager of opensuse did. I did not change it, but the only the config putting to active several privacy related issues (which internal addresses to protect etc), even if it would not have been necessary if you use it as a recursive resolver on 127.0.0.1 local host for your own machine.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/11/2020 12.05, Stakanov wrote:
In data giovedì 5 novembre 2020 11:40:18 CET, Carlos E. R. ha scritto:
On 05/11/2020 02.17, Stakanov wrote:
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
But it tries sudo.
It tries sudo because it is needed for the ancor file.
Why?
If it has to run a command as another user, the correct thing to do is use "su username -c command", not sudo, which is not guaranteed to work. This is not Ubuntu.
But even when I did set up sudo with a user unbound (which it is) in yast sudo with: user unbound, host all, RUNAS all, NOPASSWORD yes Commands all (which is if I understand terrible, then it still has the same error when starting up. Cannot read the damn conf. And I am lost. Carlos, with all the given respect. The package is original opensuse. I just followed the indications first of a manual found on an Ubuntu linked site (never used it). Blame it on missing documentation in openSUSE. I could have used Arch or any other site. I then found the original site of the project. No difference.
I know it is the original package.
You see, the sudo thing is something the packager of opensuse did.
I doubt that openSUSE people wrote that, rather upstream if all they test is Ubuntu. IMHO, this is a bug.
I did not change it, but the only the config putting to active several privacy related issues (which internal addresses to protect etc), even if it would not have been necessary if you use it as a recursive resolver on 127.0.0.1 local host for your own machine.
-- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Stakanov (05.11.20 02:17):
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote: > What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use.
Oh, they say this also from unbound (which is very safely designed and has rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight. I went through the config, apparently I have no errors. But now...I get:
[...]
error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important. [...]
Is there AppArmor running on the box and not configured to allow read access for unbound to this file? Just a wild guess... -- -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 13:34:18 CET, Werner Flamme ha scritto:
Stakanov (05.11.20 02:17):
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto: > Stakanov wrote: >> What do we usually use in our system to solve DNS? > > "our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by
default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use.
Oh, they say this also from unbound (which is very safely designed
and has
rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight.
I went through the config, apparently I have no errors. But now...I get: [...]
error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
[...]
Is there AppArmor running on the box and not configured to allow read access for unbound to this file?
Just a wild guess...
-- Actually no. The issue is described here (and a bug was opened in 2016! for TW.
https://arcaik.net/posts/debugging-a-strange-permission-issue-on-unbound/ Quite interesting what he found out. I tried to deactivate AA all together, and tried also to give root permission as he suggests but still does not start because of "no permission to read". -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
In data venerdì 6 novembre 2020 13:34:18 CET, Werner Flamme ha scritto:
Stakanov (05.11.20 02:17):
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha scritto:
On 04/11/2020 22.07, Stakanov wrote: > In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha > scritto: >> Stakanov wrote: >>> What do we usually use in our system to solve DNS? >> >> "our" ? I use bind, sometimes dnsmasq. > > "Our": what is the standard in opensuse Leap to resolve DNS by
default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use.
Oh, they say this also from unbound (which is very safely designed
and has
rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight.
I went through the config, apparently I have no errors. But now...I get: [...]
error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
[...]
Is there AppArmor running on the box and not configured to allow read access for unbound to this file?
Just a wild guess...
-- Actually no. The issue is described here (and a bug was opened in 2016! for TW.
https://arcaik.net/posts/debugging-a-strange-permission-issue-on-unbound/
Quite interesting what he found out.
The conclusion says it _was_ apparmor though ? "To summarize, Unbound was unable to read its configuration file because AppArmor limited its capabilities ..... "
I tried to deactivate AA all together, and tried also to give root permission as he suggests but still does not start because of "no permission to read".
So you changed ownership of the unbound config files and directory to be root ? That is funny - I have just now installed unbound on my 15.2 system, the config files and directory are all owned by root. -- Per Jessen, Zürich (10.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 15:39:16 CET, Per Jessen ha scritto:
Stakanov wrote:
In data venerdì 6 novembre 2020 13:34:18 CET, Werner Flamme ha
scritto:
Stakanov (05.11.20 02:17):
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha
scritto:
On 04/11/2020 23.46, Stakanov wrote:
In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha
scritto: > On 04/11/2020 22.07, Stakanov wrote: >> In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha >> >> scritto: >>> Stakanov wrote: >>>> What do we usually use in our system to solve DNS? >>> >>> "our" ? I use bind, sometimes dnsmasq. >> >> "Our": what is the standard in opensuse Leap to resolve DNS by
default?
> dnsmasq. it comes installed by default, I think, but not > activated. It is very simple to setup and use.
Oh, they say this also from unbound (which is very safely designed
and has
rightly some nice privacy feature (besides DNSSEC it is also possible to choose to use external servers via DOT. And it is very lightweight.
I went through the config, apparently I have no errors. But
now...I get: [...]
error: Could not open /etc/unbound/unbound.conf: Permission denied
That seems important.
[...]
Is there AppArmor running on the box and not configured to allow read access for unbound to this file?
Just a wild guess...
--
Actually no. The issue is described here (and a bug was opened in 2016! for TW.
https://arcaik.net/posts/debugging-a-strange-permission-issue-on-unbound/
Quite interesting what he found out.
The conclusion says it _was_ apparmor though ?
"To summarize, Unbound was unable to read its configuration file because AppArmor limited its capabilities ..... "
I tried to deactivate AA all together, and tried also to give root permission as he suggests but still does not start because of "no permission to read".
So you changed ownership of the unbound config files and directory to be root ? That is funny - I have just now installed unbound on my 15.2 system, the config files and directory are all owned by root. With me they were owned unbound:root
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 15:53:56 CET, Stakanov ha scritto:
In data venerdì 6 novembre 2020 15:39:16 CET, Per Jessen ha scritto:
Stakanov wrote:
In data venerdì 6 novembre 2020 13:34:18 CET, Werner Flamme ha
scritto:
Stakanov (05.11.20 02:17):
In data giovedì 5 novembre 2020 01:09:03 CET, Carlos E. R. ha
scritto:
On 04/11/2020 23.46, Stakanov wrote: > In data mercoledì 4 novembre 2020 22:09:17 CET, Carlos E. R. ha > > scritto: >> On 04/11/2020 22.07, Stakanov wrote: >>> In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha >>> >>> scritto: >>>> Stakanov wrote: >>>>> What do we usually use in our system to solve DNS? >>>> >>>> "our" ? I use bind, sometimes dnsmasq. >>> >>> "Our": what is the standard in opensuse Leap to resolve DNS by
default?
>> dnsmasq. it comes installed by default, I think, but not >> activated. It is very simple to setup and use. > > Oh, they say this also from unbound (which is very safely > designed
and has
> rightly some nice privacy feature (besides DNSSEC it is also > possible to choose to use external servers via DOT. > And it is very lightweight. > > I went through the config, apparently I have no errors. But
> now...I get: [...]
> error: Could not open /etc/unbound/unbound.conf: Permission > denied
That seems important.
[...]
Is there AppArmor running on the box and not configured to allow read access for unbound to this file?
Just a wild guess...
--
Actually no. The issue is described here (and a bug was opened in 2016! for TW.
https://arcaik.net/posts/debugging-a-strange-permission-issue-on-unbound/
Quite interesting what he found out.
The conclusion says it _was_ apparmor though ?
"To summarize, Unbound was unable to read its configuration file because AppArmor limited its capabilities ..... "
I tried to deactivate AA all together, and tried also to give root permission as he suggests but still does not start because of "no permission to read".
So you changed ownership of the unbound config files and directory to be root ? That is funny - I have just now installed unbound on my 15.2 system, the config files and directory are all owned by root.
With me they were owned unbound:root actually other way round: Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
Still, under these conditions, with AA deactivated (service stopped) it cannot read. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
06.11.2020 17:56, Stakanov пишет:
Still, under these conditions, with AA deactivated (service stopped)
What makes you think that stopping apparmor service deactivates anything? Apparmor is not daemon that has to be running to be active. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 16:04:13 CET, Andrei Borzenkov ha scritto:
06.11.2020 17:56, Stakanov пишет:
Still, under these conditions, with AA deactivated (service stopped)
What makes you think that stopping apparmor service deactivates anything? Apparmor is not daemon that has to be running to be active.
And why is it then possible to stop it? What do I have to do to deactivate AA? Uninstall it? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
06.11.2020 18:07, Stakanov пишет:
In data venerdì 6 novembre 2020 16:04:13 CET, Andrei Borzenkov ha scritto:
06.11.2020 17:56, Stakanov пишет:
Still, under these conditions, with AA deactivated (service stopped)
What makes you think that stopping apparmor service deactivates anything? Apparmor is not daemon that has to be running to be active.
And why is it then possible to stop it?
Because every systemd unit can be started and stopped. And because you may want to re-run service start command and for that service must be stopped.
What do I have to do to deactivate AA? Uninstall it?
aa-teardown -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 16:10:39 CET, Andrei Borzenkov ha scritto:
06.11.2020 18:07, Stakanov пишет:
In data venerdì 6 novembre 2020 16:04:13 CET, Andrei Borzenkov ha scritto:
06.11.2020 17:56, Stakanov пишет:
Still, under these conditions, with AA deactivated (service stopped)
What makes you think that stopping apparmor service deactivates anything? Apparmor is not daemon that has to be running to be active.
And why is it then possible to stop it?
Because every systemd unit can be started and stopped. And because you may want to re-run service start command and for that service must be stopped.
What do I have to do to deactivate AA? Uninstall it?
aa-teardown
Does aa-teardown require a reboot? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 16:14:55 CET, Stakanov ha scritto:
In data venerdì 6 novembre 2020 16:10:39 CET, Andrei Borzenkov ha scritto:
06.11.2020 18:07, Stakanov пишет:
In data venerdì 6 novembre 2020 16:04:13 CET, Andrei Borzenkov ha scritto:
06.11.2020 17:56, Stakanov пишет:
Still, under these conditions, with AA deactivated (service stopped)
What makes you think that stopping apparmor service deactivates anything? Apparmor is not daemon that has to be running to be active.
And why is it then possible to stop it?
Because every systemd unit can be started and stopped. And because you may want to re-run service start command and for that service must be stopped.
What do I have to do to deactivate AA? Uninstall it?
aa-teardown
Does aa-teardown require a reboot? Apparently not.
The service starts now, I created manually a profile for /usr/sbin/unbound Will see if I am able to make it work. What I find odd: the information that it is AA to be the problem should appear in the error. And the information that in order to be sure not having troubles with AA should be in a tooltip of yast controlling AA. I do not think I am alone with the conviction that stopping a service stops it from working. Still thank you very much for your help that proved to be the most efficient one. Very appreciated. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
controlling AA. I do not think I am alone with the conviction that stopping a service stops it from working.
The misunderstanding is perhaps that apparmor is not a service. It does not "run". -- Per Jessen, Zürich (7.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/11/2020 17.30, Per Jessen wrote:
Stakanov wrote:
controlling AA. I do not think I am alone with the conviction that stopping a service stops it from working.
The misunderstanding is perhaps that apparmor is not a service. It does not "run".
Still, I do not remember using "aa-teardown" to disable aa. Documentation on apparmour on https://doc.opensuse.org/ is not to be found in the Reference Book, but in Security Guide. https://doc.opensuse.org/documentation/leap/security/html/book-security/cha-... 21.2 Enabling and Disabling AppArmor ... To disable AppArmor permanently (by removing it from the sequence of scripts executed on system boot) proceed as follows: 1 Start YaST. 2 Select System › Services Manager. 3 Mark apparmor by clicking its row in the list of services, then click Enable/Disable in the lower part of the window. Check that Enabled changed to Disabled in the apparmor row. 4 Confirm with OK. AppArmor will not be initialized on reboot, and stays inactive until you re-enable it. Re-enabling a service using the YaST Services Manager tool is similar to disabling it. Toggle the status of AppArmor in a running system by using the AppArmor Configuration window. These changes take effect when you apply them and survive a reboot of the system. To toggle the status of AppArmor, proceed as follows: 1 Start YaST, select AppArmor Configuration, and click Settings in the main window. 2 Enable AppArmor by checking Enable AppArmor or disable AppArmor by deselecting it. 3 Click Done in the AppArmor Configuration window. The command "aa-teardown" which is faster is not mentioned :-? However, if a profile for unbound existed, aa could be switched to complain mode instead of enforce. And the first step would be "aa-logprof" to check for aa problems. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
06.11.2020 18:32, Stakanov пишет:
The service starts now, I created manually a profile for /usr/sbin/unbound
This is the first time you mentioned you created (apparmor?) profile for unbound. You continued to claim
Carlos, with all the given respect. The package is original opensuse.
Which is blatant lie - original opensuse does not install any apparmor profile for unbound. And "original opensuse" installation starts without any issues. Moreover, you went further blaming everyone but yourself, like
Blame it on missing documentation in openSUSE.
I do not feel like ever paying attention to your questions again. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/11/2020 18.50, Andrei Borzenkov wrote:
06.11.2020 18:32, Stakanov пишет:
The service starts now, I created manually a profile for /usr/sbin/unbound
This is the first time you mentioned you created (apparmor?) profile for unbound.
I understand he created it now, not before. Another detail is that he is using 15.1 -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
In data venerdì 6 novembre 2020 18:50:40 CET, Andrei Borzenkov ha scritto:
06.11.2020 18:32, Stakanov пишет:
The service starts now, I created manually a profile for /usr/sbin/unbound
This is the first time you mentioned you created (apparmor?) profile for unbound. You continued to claim
Dear Andrei. I created the AA profile following(!) your indications of AA-teardown. Therefore, an AA profile was created after I managed to start the service after AA-teardown, a command that previously I did not know our encounter. Once done, I wanted to build that profile, but I did not find the program. So I searched on the internet googling and found the command whereis (how do I find a program in Linux). Which gave me: entropia@roadrunner:~> whereis unbound unbound: /usr/sbin/unbound /etc/unbound /usr/share/unbound /usr/share/man/ man8/unbound.8.gz So I created (by hope, chance and deduction, the profile: /usr/sbin/unbound and did put it (as I had learned from the past with "preloaded" profile to "complain". I have learned that in that mode it just registers "offenses" to be evaluated as legit or not. As I have no idea what the program shall be allowed to open or read, I just "accepted" all, as it is a quite recent reinstall of 15.1 (coming back from 15.2). Now all works and if the next round of checking the log there is nothing I try to put it on enforce. That is all about it. The only problem I encountered was a sudden shutdown due to overheat, but I do not know if there was a program hanging or if unbound has to do something very intensive in calculus (maybe updating its ancors or whatever) that this old machine was not able to handle together with other threads loading the CPU. After original install: Before, first I had a problem that the program claimed that I had syntax errors. That was overcome by simply using the original conf that I had as a backup and erasing mine, just to make sure nothing interfered. Then the program did not start due to "permission error. I then went for AA as I thought, I want to take off any possibility of interference. I did not know, neither heard about that AA does NOT stop when you stop it in yast. This is actually in my eyes a possible enhancement, because you cannot simply think that everybody knows this. A simple informative popup in yast might avoid it in the future, if somebody want to implement it. I for sure will make the suggestion. And that I solved it, this is all your merit, as you gave as only person the most valuable information on how to eliminate (!) the source of error.
Carlos, with all the given respect. The package is original opensuse.
Which is blatant lie - original opensuse does not install any apparmor profile for unbound.
And "original opensuse" installation starts without any issues. Well mine didn't. Which brought me here to ask. Which is the very purpose of
Look. The original comment to Carlos, was on behalf of his criticism of me having used an ubuntu based howto (which I did not "follow blindly to be clear" but for general orientation.) The AA profile, as I told you, was NOT created by me before. At least not intentionally, I do not know if you can create one. What is sure, AA was running and it did so even when I thought it did not any more. I do not comment on the, for me not understandable, emotional part of your reply. I however allow myself the observation that it is not adding to the problem, solution and probably from a communication point of view does not open my filters of perception. this mailing list. And thanks to your observations, now it does work.
Moreover, you went further blaming everyone but yourself, like
Blame it on missing documentation in openSUSE.
Feel free to point me to the openSUSE documentation of the package, and I give you my written apologies on that point. I have seen that, unlike in recent years were there has not been a convenient documentation, there is one growing and it is well done and not outdated. Maybe I did not look good enough? However the "blame it on" was in context and referred to as of above and already clarified.
I do not feel like ever paying attention to your questions again.
As aforementioned, I cannot comment on irrationality. However. андреи, как всегда, и как это правильно, вы делаете то, что чувствуете. Я благодарен за информацию, которую вы мне дал. спосиба. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 20:34:32 CET, Stakanov ha scritto:
In data venerdì 6 novembre 2020 18:50:40 CET, Andrei Borzenkov ha scritto:
06.11.2020 18:32, Stakanov пишет:
The service starts now, I created manually a profile for /usr/sbin/unbound
This is the first time you mentioned you created (apparmor?) profile for unbound. You continued to claim
Dear Andrei.
I created the AA profile following(!) your indications of AA-teardown. Therefore, an AA profile was created after I managed to start the service after AA-teardown, a command that previously I did not know our encounter. Once done, I wanted to build that profile, but I did not find the program. So I searched on the internet googling and found the command whereis (how do I find a program in Linux). Which gave me: entropia@roadrunner:~> whereis unbound unbound: /usr/sbin/unbound /etc/unbound /usr/share/unbound /usr/share/man/ man8/unbound.8.gz So I created (by hope, chance and deduction, the profile: /usr/sbin/unbound and did put it (as I had learned from the past with "preloaded" profile to "complain". I have learned that in that mode it just registers "offenses" to be evaluated as legit or not. As I have no idea what the program shall be allowed to open or read, I just "accepted" all, as it is a quite recent reinstall of 15.1 (coming back from 15.2). Now all works and if the next round of checking the log there is nothing I try to put it on enforce. That is all about it. The only problem I encountered was a sudden shutdown due to overheat, but I do not know if there was a program hanging or if unbound has to do something very intensive in calculus (maybe updating its ancors or whatever) that this old machine was not able to handle together with other threads loading the CPU.
After original install: Before, first I had a problem that the program claimed that I had syntax errors. That was overcome by simply using the original conf that I had as a backup and erasing mine, just to make sure nothing interfered. Then the program did not start due to "permission error. I then went for AA as I thought, I want to take off any possibility of interference. I did not know, neither heard about that AA does NOT stop when you stop it in yast. This is actually in my eyes a possible enhancement, because you cannot simply think that everybody knows this. A simple informative popup in yast might avoid it in the future, if somebody want to implement it. I for sure will make the suggestion. And that I solved it, this is all your merit, as you gave as only person the most valuable information on how to eliminate (!) the source of error.
Carlos, with all the given respect. The package is original opensuse.
Which is blatant lie - original opensuse does not install any apparmor profile for unbound.
Look. The original comment to Carlos, was on behalf of his criticism of me having used an ubuntu based howto (which I did not "follow blindly to be clear" but for general orientation.) The AA profile, as I told you, was NOT created by me before. At least not intentionally, I do not know if you can create one. What is sure, AA was running and it did so even when I thought it did not any more.
I do not comment on the, for me not understandable, emotional part of your reply. I however allow myself the observation that it is not adding to the problem, solution and probably from a communication point of view does not open my filters of perception.
And "original opensuse" installation starts without any issues.
Well mine didn't. Which brought me here to ask. Which is the very purpose of this mailing list. And thanks to your observations, now it does work.
Moreover, you went further blaming everyone but yourself, like
Blame it on missing documentation in openSUSE.
Feel free to point me to the openSUSE documentation of the package, and I give you my written apologies on that point. I have seen that, unlike in recent years were there has not been a convenient documentation, there is one growing and it is well done and not outdated. Maybe I did not look good enough? However the "blame it on" was in context and referred to as of above and already clarified.
I do not feel like ever paying attention to your questions again.
As aforementioned, I cannot comment on irrationality. However. андреи, как всегда, и как это правильно, вы делаете то, что чувствуете. Я благодарен за информацию, которую вы мне дал.
спосиба.
So in TW this worked flawlessly and is easy now. Since I have learned before. To your observation on "why was there a profile". Thinking of it: I had to interrupt a previous install ( I do not know how many install ago) in 15.2. That fabulous system 15.2 forced me three times in a row no to reinstall, between kmail blocking the machine, mail is lost, data is lost by akonadi, akonadi stalls the system, archive function is broken, emergency shutdown due to heat (CPU on 200%) etc. Now that cause several "emergency install" of 15.1, coming from 15.2, in order to repair. And no, not going to rant further on that, I gave up now on 15.2, it is simply for kmail not working. Its OK, design choice or incompatibility, I will make mine. But of course, if in this fuss and stress, I may have done errors, maybe there would have been a profile? But for sure I never created a profile with path indication of /user/sbin/unbound prior to the suggestions of "aa-teardown" from Andrei and starting the server. If it is possible to create a profile over an existing one, and there is no warning that one already exists, then this was probably the case, because I got no warning. All runs perfect now, and to tell the truth, given the speed pages open now, I am going to change all my machines that way. Or I may set up one resolver for my network at home, but that would be on a machine running TrueNas (BSD based). So on this behalf a question on security. Is it advisable to run that on the TrueNas (which is the only machine "constant on" here, or wouldn't it be saver and better to set up a separate RaspberryPi? For what I understand, a Raspi DNS recursive server like that, which would serve only my small home network, does not have to be powerful. Am I right or mistaken? Another possibility would be to set up an older Mikrotik GL750 with OpenWRT and install unbound on it. Better? Worse? Thanks for input. . -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
actually other way round: Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
Still, under these conditions, with AA deactivated (service stopped) it cannot read.
"service stopped" ? That is not sufficient, there is no real stop action for apparmor. I'm not sure if there is a way to unload all the profiles, but you can always reboot with apparmor=0. -- Per Jessen, Zürich (10.5°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 16:06:52 CET, Per Jessen ha scritto:
Stakanov wrote:
actually other way round: Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
Still, under these conditions, with AA deactivated (service stopped) it cannot read.
"service stopped" ? That is not sufficient, there is no real stop action for apparmor. I'm not sure if there is a way to unload all the profiles, but you can always reboot with apparmor=0. ok, I will try and in the meanwhile I did erase the unbound directory and will force a reinstall. Still, there should be an AA profile no? Hasn't this been adapted to the package?
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
In data venerdì 6 novembre 2020 16:06:52 CET, Per Jessen ha scritto:
Stakanov wrote:
actually other way round: Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
Still, under these conditions, with AA deactivated (service stopped) it cannot read.
"service stopped" ? That is not sufficient, there is no real stop action for apparmor. I'm not sure if there is a way to unload all the profiles, but you can always reboot with apparmor=0. ok, I will try and in the meanwhile I did erase the unbound directory and will force a reinstall. Still, there should be an AA profile no?
In principle yes, in practice noone has bothered afaict. -- Per Jessen, Zürich (7.4°C) http://www.dns24.ch/ - free dynamic DNS, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 06/11/2020 17.28, Per Jessen wrote:
Stakanov wrote:
In data venerdì 6 novembre 2020 16:06:52 CET, Per Jessen ha scritto:
Stakanov wrote:
actually other way round: Permissions of the folder are currently: entropia@roadrunner:~> ls -l /etc/unbound totale 80 drwxr-xr-x 2 root unbound 4096 4 nov 23.29 conf.d -rw-r----- 1 root unbound 435 26 giu 10.14 dlv.isc.org.key -rw-r--r-- 1 root root 17699 28 dic 2013 icannbundle.pem drwxr-xr-x 2 root unbound 4096 26 giu 10.14 keys.d drwxr-xr-x 2 root unbound 4096 26 giu 10.14 local.d -rw-r----- 1 root unbound 1066 26 giu 10.14 root.key -rw-r----- 1 root unbound 21967 4 nov 23.27 unbound.conf -rw------- 1 root unbound 2459 30 ott 13.20 unbound_control.key -rw-r----- 1 root unbound 1342 30 ott 13.20 unbound_control.pem -rw------- 1 root unbound 2459 30 ott 13.20 unbound_server.key -rw-r----- 1 root unbound 1334 30 ott 13.20 unbound_server.pem
Still, under these conditions, with AA deactivated (service stopped) it cannot read.
"service stopped" ? That is not sufficient, there is no real stop action for apparmor. I'm not sure if there is a way to unload all the profiles, but you can always reboot with apparmor=0. ok, I will try and in the meanwhile I did erase the unbound directory and will force a reinstall. Still, there should be an AA profile no?
In principle yes, in practice noone has bothered afaict.
Wait, unbound comes without an AA profile, yet the problem with unbound is apparmor? I don't understand how can that be. The article that was mentioned: <https://arcaik.net/posts/debugging-a-strange-permission-issue-on-unbound/> clearly mentions an AA profile in /etc/apparmor.d/usr.sbin.unbound. And that the root cause is that the deamon runs at root with capabilities restricted: +++················ POSIX capabilities Besides limiting access to files and directory, AppArmor can assign or remove POSIX capabilities to limit what a process is allowed to do on the system. In the case of Unbound, it is only granted the ones it really needs (for instance the NET_BIND_SERVICE capability allows it to listen ports lower than 1024). This means that even when Unbound is running as root, during the early phase of its startup process, it is limited to the capabilities that was explicitly granted. Actually, this is the key difference between Unbound and my interactive shell, the later is basically granted with the full list of capabilities. There’s one specific capabilities that explains this difference: DAC_OVERRIDE allows a process to bypass access right checks on files. That explains it all: Unbound can’t read a file that is owned by the unbound user without read permission for other users while running as root, because it doesn’t have that capability assigned. ················++- -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
The default is to use the DNS services from your internet provider :-) Anything else is really up to you. -- Per Jessen, Zürich (7.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 5 novembre 2020 09:59:03 CET, Per Jessen ha scritto:
Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha
scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
The default is to use the DNS services from your internet provider :-) Anything else is really up to you.
I am very often in uncomfortable environment were you wish either to use a vpn (not always possible) but at least have your DNS request been send DOT and validated DNSSEC. One example is a tethered 4G connection. There I am not even the possibility to resolve if I do not use such a setup. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 05/11/2020 12.08, Stakanov wrote:
In data giovedì 5 novembre 2020 09:59:03 CET, Per Jessen ha scritto:
Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha
scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
The default is to use the DNS services from your internet provider :-) Anything else is really up to you.
I am very often in uncomfortable environment were you wish either to use a vpn (not always possible) but at least have your DNS request been send DOT and validated DNSSEC. One example is a tethered 4G connection. There I am not even the possibility to resolve if I do not use such a setup.
Then there is a "bug" with your ISP setup. When I tether with my phone Linux works out of the box, it does resolve. If I don't like their setup then I change it - using dnsmasq. -- Cheers / Saludos, Carlos E. R. (from 15.1 x86_64 at Telcontar)
On Thu, 5 Nov 2020 12:27:22 +0100 "Carlos E. R." <robin.listas@telefonica.net> wrote:
On 05/11/2020 12.08, Stakanov wrote:
In data giovedì 5 novembre 2020 09:59:03 CET, Per Jessen ha scritto:
Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha
scritto:
Stakanov wrote: > What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
The default is to use the DNS services from your internet provider :-) Anything else is really up to you.
I am very often in uncomfortable environment were you wish either to use a vpn (not always possible) but at least have your DNS request been send DOT and validated DNSSEC. One example is a tethered 4G connection. There I am not even the possibility to resolve if I do not use such a setup.
Then there is a "bug" with your ISP setup. When I tether with my phone Linux works out of the box, it does resolve. If I don't like their setup then I change it - using dnsmasq.
Maybe the uncomfortable environments and the connections associated with it are precisely when Stakanov is not using his ISP's facilities? -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 5 novembre 2020 13:03:51 CET, Dave Howorth ha scritto:
On Thu, 5 Nov 2020 12:27:22 +0100
"Carlos E. R." <robin.listas@telefonica.net> wrote:
On 05/11/2020 12.08, Stakanov wrote:
In data giovedì 5 novembre 2020 09:59:03 CET, Per Jessen ha
scritto:
Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha
scritto: > Stakanov wrote: >> What do we usually use in our system to solve DNS? > > "our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
The default is to use the DNS services from your internet provider :-) Anything else is really up to you.
I am very often in uncomfortable environment were you wish either to use a vpn (not always possible) but at least have your DNS request been send DOT and validated DNSSEC. One example is a tethered 4G connection. There I am not even the possibility to resolve if I do not use such a setup.
Then there is a "bug" with your ISP setup. When I tether with my phone Linux works out of the box, it does resolve. If I don't like their setup then I change it - using dnsmasq.
Maybe the uncomfortable environments and the connections associated with it are precisely when Stakanov is not using his ISP's facilities? Bingo my dear.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
In data giovedì 5 novembre 2020 09:59:03 CET, Per Jessen ha scritto:
Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha
scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
The default is to use the DNS services from your internet provider :-) Anything else is really up to you.
I am very often in uncomfortable environment were you wish either to use a vpn (not always possible) but at least have your DNS request been send DOT and validated DNSSEC. One example is a tethered 4G connection.
Okay - I guess I don't quite see the specific need in that situation, but you're still left with doing it yourself, whether with dnsmasq, bind or unbound. I would likely chose dnsmasq, I've already used it for a couple of unusual setups. I'm sure the docus for unbound are just as good though. -- Per Jessen, Zürich (9.2°C) http://www.cloudsuisse.com/ - your owncloud, hosted in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data giovedì 5 novembre 2020 12:42:05 CET, Per Jessen ha scritto:
Stakanov wrote:
In data giovedì 5 novembre 2020 09:59:03 CET, Per Jessen ha scritto:
Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha
scritto:
Stakanov wrote: > What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
The default is to use the DNS services from your internet provider
:-) Anything else is really up to you.
I am very often in uncomfortable environment were you wish either to use a vpn (not always possible) but at least have your DNS request been send DOT and validated DNSSEC. One example is a tethered 4G connection.
Okay - I guess I don't quite see the specific need in that situation, but you're still left with doing it yourself, whether with dnsmasq, bind or unbound. I would likely chose dnsmasq, I've already used it for a couple of unusual setups. I'm sure the docus for unbound are just as good though. Unbound would have the advantage of being lighter in CPU power than dnsmasq. In fact the machine is a Core i5 ironlake(!) with 8 GB Ram and a 860Pro SSD Samsung. Works fine but one wants to avoid heavyweights. As for 4G: I cannot tell you what they do, but if I did use VPN worked flawlessly, worked with the tor browser bundle, but they definitely did not wish to hinder me to use a different DNS server then theirs, so with the normal settings I had (Leap out of the box) while solving everywhere, when tethering I could not use the PC. The 4G would work as standalone. I think another stupid move to try to block tethered devices or as Carlos said bad setup. Since not always it is useful to do VPN (imagine a travel in train with tunnels, every time the VPN breaks it troubles to connect again speedy enough) in these cases I prefer to resolve as said. My whole problems is to understand the permission problem of /etc/unbound/ unbound.conf.
-- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
Stakanov wrote:
In data giovedì 5 novembre 2020 12:42:05 CET, Per Jessen ha scritto:
I would likely chose dnsmasq, I've already used it for a couple of unusual setups. I'm sure the docus for unbound are just as good though. Unbound would have the advantage of being lighter in CPU power than dnsmasq. In fact the machine is a Core i5 ironlake(!) with 8 GB Ram and a 860Pro SSD Samsung. Works fine but one wants to avoid heavyweights.
dnsmasq ran fine on my son's Raspi3 for a school project a couple of years ago :-)
My whole problems is to understand the permission problem of /etc/unbound/ unbound.conf.
If you google it, you will quickly find someone suggesting it is apparmor getting in your way. Check the logs. Also be aware that unbound looks like it has not yet been updated to work with firewalld instead of SuSEfirewall2. -- Per Jessen, Zürich (8.8°C) http://www.hostsuisse.com/ - virtual servers, made in Switzerland. -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
On 04/11/2020 16:09, Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use.
+1 to that. As far as getting it working, it is easier to initially modify and then later extend than BIND. If you are also using DHCP it is also easier to use as an integrated DHCP/DNS master than the crytpto stuff needed with BIND. Along the way, I also had dnsmasq do spam filtering and advert filtering. Oh, my that was easy! -- “Reality is so complex, we must move away from dogma, whether it’s conspiracy theories or free-market,” -- James Glattfelder. http://jth.ch/jbg -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
In data venerdì 6 novembre 2020 13:50:22 CET, Anton Aylward ha scritto:
On 04/11/2020 16:09, Carlos E. R. wrote:
On 04/11/2020 22.07, Stakanov wrote:
In data mercoledì 4 novembre 2020 21:17:31 CET, Per Jessen ha scritto:
Stakanov wrote:
What do we usually use in our system to solve DNS?
"our" ? I use bind, sometimes dnsmasq.
"Our": what is the standard in opensuse Leap to resolve DNS by default?
dnsmasq. it comes installed by default, I think, but not activated. It is very simple to setup and use.
+1 to that. As far as getting it working, it is easier to initially modify and then later extend than BIND. If you are also using DHCP it is also easier to use as an integrated DHCP/DNS master than the crytpto stuff needed with BIND.
Along the way, I also had dnsmasq do spam filtering and advert filtering. Oh, my that was easy! Well, I raised a bug report against unbound. Factually the bug I encounter is known and a problem since 2016. Once should really not offer a package that is broken that long I suppose.
I will likely do dnsmasq, I wonder however if it is capable of DNSSEC, DOT and round robin out of the box (which is what I am looking for). Alternative would be to compile from source (which is a PITA). -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse+owner@opensuse.org
participants (7)
-
Andrei Borzenkov -
Anton Aylward -
Carlos E. R. -
Dave Howorth -
Per Jessen -
Stakanov -
Werner Flamme