nsd users - May 2020 - NSD still shows permission errors on Debian 10 Buster

On 27/05/2020 19:02, Simon Deziel wrote:

Hi Simon,
>> Are you certain of this? I have never seen any errors on my NSD
systems.
> 
> I reproduced it all in a Debian Buster VM before posting. Are you using
> the same systemd unit as Debian Buster's [*] ?
No, I'm running NSD on CentOS 7. I'm not using the unit file from 
contrib. I find it a mess. It's trying to enable every possible option 
in systemd, without taking care of all the related permission problems 
they cause. I build my own packages of NSD, and ship a very simple unit 
file with it:

[Unit]
Description=NSD DNS Server
After=network-online.target

[Service]
LimitNOFILE=8192
ExecStart=/usr/sbin/nsd -d
KillMode=process

[Install]
WantedBy=multi-user.target
>>> [Service]
>>> ExecStartPre=-/bin/chown --quiet root:root /var/log/nsd.log
>>
>> All of this seems to be band-aid upon band-aid of unnecessary hacks.
> 
> That's a band-aid indeed. IMHO the proper fix is to be consistent in
> handling the file. So either open it as root and not chown it or always
> touch it after setuid().
I agree. In order to avoid problems, on my systems, I log to 
/var/log/nsd, where that directory is owned by nsd:nsd.
>>> As for the failed unlinking of the pidfile, this is harmless and
should
>>> not be logged as a warning. It may already be fixed in newer
releases as
>>> it was done with Unbound already.
>>
>> PID files are so pass?! They are irrelevant on systems where daemons
are
>> run under supervisors. I would highly recommend setting
"pidfile" to ""
>> in nsd.conf. This prevents creation of a PID file. Systemd already
knows
>> the PID of the NSD process, and can signal it directly.
> 
> Would it make sense to simply ignore the pidfile directive when running
> through systemd?
No. I don't like it when software silently does things. Instead, when 
package maintainers build NSD for systems with systemd, they should pass 
the --with-pidfile="" option to the configure script, so that by 
default, NSD doesn't create PID files. If a user still wants a PID file 
for some bizarre reason, he can set the "pidfile" option in nsd.conf. 
And then deal with the permissions issues himself.

Regards,
Anand

On 2020-05-27 3:18 p.m., Anand Buddhdev via nsd-users
wrote:
> On 27/05/2020 19:02, Simon Deziel wrote:
>>>> As for the failed unlinking of the pidfile, this is harmless
and should
>>>> not be logged as a warning. It may already be fixed in newer
>>>> releases as
>>>> it was done with Unbound already.
>>>
>>> PID files are so pass?! They are irrelevant on systems where
daemons are
>>> run under supervisors. I would highly recommend setting
"pidfile" to ""
>>> in nsd.conf. This prevents creation of a PID file. Systemd already
knows
>>> the PID of the NSD process, and can signal it directly.
>>
>> Would it make sense to simply ignore the pidfile directive when running
>> through systemd?
> 
> No. I don't like it when software silently does things. Instead, when
> package maintainers build NSD for systems with systemd, they should pass
> the --with-pidfile="" option to the configure script, so that by
> default, NSD doesn't create PID files.
I like the idea. Since Debian wants to preserve compatibility with both
systemd and init, I proposed a slightly different fix to Debian for nsd
[1] and unbound [2]. Thanks!

Regards,
Simon

1: https://salsa.debian.org/dns-team/nsd/-/merge_requests/4
2: https://salsa.debian.org/dns-team/unbound/-/merge_requests/9