Bug 231592 - dns/dnscrypt-proxy2: Provided sample configuration entries do not work unmodified
Summary: dns/dnscrypt-proxy2: Provided sample configuration entries do not work unmodi...
Status: Closed Works As Intended
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: amd64 Any
: --- Affects Only Me
Assignee: Vinícius Zavam
URL:
Keywords: needs-qa
Depends on:
Blocks:
 
Reported: 2018-09-22 15:40 UTC by Igor Pavlov
Modified: 2018-11-19 15:45 UTC (History)
2 users (show)

See Also:
egypcio: maintainer-feedback+


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Igor Pavlov 2018-09-22 15:40:46 UTC
dnscrypt-proxy2 service doesn't start if I enable the user_name = 'nobody' option.

There are following messages in the log:

[2018-09-22 17:25:20] [NOTICE] Source [public-resolvers.md] loaded
[2018-09-22 17:25:20] [NOTICE] dnscrypt-proxy 2.0.16
[2018-09-22 17:25:20] [FATAL] I need root permissions. Try again with 'sudo'
Comment 1 Vinícius Zavam freebsd_committer freebsd_triage 2018-09-24 14:45:48 UTC
(In reply to Igor Pavlov from comment #0)

Hi Igor,

thanks for reporting it; appreciated.

what else on the config file you changed? did you also adjusted files/directories permissions to reflect this changes? have you also modified anything on its rcvars?

this port is tuned to run as an unprivileged user already (_dnscrypt-proxy) and works out-of-the-box.

  root@moose:~ # pw user show _dnscrypt-proxy
  _dnscrypt-proxy:*:978:978::0:0:dnscrypt-proxy user:/var/empty:/usr/sbin/nologin

also, the FATAL error says it needs root permissions, but it doesn't; as you can see we already worked to put it working as an unpriv user on FreeBSD. is there any particular reason you wanna force it to use 'nobody'?
Comment 2 Igor Pavlov 2018-09-24 15:56:22 UTC
There is no other reason for the report except the feature just doesn't work.
Comment 3 Vinícius Zavam freebsd_committer freebsd_triage 2018-09-26 08:08:24 UTC
(In reply to Igor Pavlov from comment #2)

I am sorry to put things this way, but it looks like you did not get my last comments and questions. Please, don't get me wrong. 

Have you also took some time to understand and/or troubleshoot why it "doesn't work", for you?

Once again, thank for the bug report (but it does not seems to be a problem; things are really working as expected). If you have more input, I'll appreciate and take a better look into it.

KR,
Comment 4 Kubilay Kocak freebsd_committer freebsd_triage 2018-09-26 08:20:59 UTC
Maintainer provided feedback (+).

This doesn't appear to be a bug. 

Modifying the username (from the port default), requires changing other relevant files/paths/programs/etc permissions to suit, at which point it is a non-standard (and therefore unsupported) port installation/configuration. 

The option/ability to change the username (or any other features/arguments) in rc.conf (via the rc script) are meant only as conveniences to the user for single-point configuration.
Comment 5 Igor Pavlov 2018-09-26 09:57:13 UTC
> Have you also took some time to understand and/or troubleshoot why it "doesn't work", for you?

I understand why it doesn't work.

It just wasn't obvious that the user_name = 'nobody' service option from the provided sample config is incompatible with the tunings of the port environment. It will be good to add an explicit note about it, may be.

There are following comments currently in the dnscrypt-proxy.toml.sample:

## Switch to a non-privileged system user after listening sockets have been created.
## Two processes will be running.
## The first one will keep root privileges, but is only a supervisor, that does nothing
## except create the sockets, manage the service, and restart it if it crashes.
## The second process is the service itself, and that one will always run as a different
## user.
## Note (1): this feature is currently unsupported on Windows.
## Note (2): this feature is not compatible with systemd socket activation.

# user_name = 'nobody'

It's not Windows and I'm not using socket activation.
I hope, it's more clear now.
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2018-09-26 10:19:15 UTC
@Vinícius, Can we look at making any modifications necessary to the sample configuration file such that they work out-of-the-box (unmodified) ?

Alternatively, can we think of ways we might make it clearer that the file is an unmodified upstream 'dist' configuration, if that is indeed what it is, and not a 'usable sample' ? 

The latter could be done by way of file naming, and I believe a few ports make the distinction between multiple provided configs, naming the config.conf.sample (a modified -dist config made to work out of the box) and config.conf.sample-dist differently.

It's highly preferably, recommended and I believe at least somewhat expected that .sample configuration files are a simple matter of copy-paste (cp config.conf.sample -> config.conf) without modifications to work.

I haven't reviewed the dnscrypt-proxy2 port in depth, so if the state of the port is already as above, please let us know.
Comment 7 Vinícius Zavam freebsd_committer freebsd_triage 2018-09-26 15:25:12 UTC
(In reply to Kubilay Kocak from comment #6)

Hi koobs@,

thank you for jumping in! appreciated.

so, we already have modifications on the main template; https://svnweb.freebsd.org/ports/head/dns/dnscrypt-proxy2/Makefile?view=markup#l54

plus: one can just check 'pkg info -D dnscrypt-proxy2' to get the steps and info provided with the package.

I also just ran a small test here on 11.2/amd64 (fresh installed); 
  * changed the pkg config to use /latest;
  * installed dnscrypt-proxy2;
  * service dnscrypt-proxy onestart;
  * drill -p 5353 @127.0.0.1 freebsd.org;
  * worked!
Comment 8 Igor Pavlov 2018-09-26 16:20:05 UTC
> Provided sample configuration entries do not work unmodified

Actually, it should work, because the:
# user_name = 'nobody'
option is commented.
It's unclear that some (at least one) options may not work and it's by design of the port, not a bug.
Comment 9 Vinícius Zavam freebsd_committer freebsd_triage 2018-09-27 09:57:01 UTC
(In reply to Igor Pavlov from comment #8)

the provided sample configuration works just fine, unmodified.

what we can't provide is a note on every single port regarding specific changes on the service's configurations. these changes and features also must reflect upstream support (coming from Go, in this case). if you are interested, read https://redbyte.eu/en/blog/supervised-freebsd-init-script-for-go-deamon/

when I first mentioned that you need to understand why it was not working, I really mean that you should know the flags you can use/combine with this port's rc script and so on - and as koobs@ mentioned too, you might also need to change permissions by yourself.

AFAIK, and as far as some other devs and users tested, the port and its rc script are working as expected. so, again, I truly appreciate your report but I see no need to patch the port - the issue you have with binding here is not related to the port itself.

PS: imagine that *all* ports should be patched to explain/teach configuration details and customization to the users. I do not see it happening. sorry.
Comment 10 Tobias Kortkamp freebsd_committer freebsd_triage 2018-11-16 12:13:05 UTC
(In reply to Vinícius Zavam from comment #9)
It sounds like this could be closed with "Working As Intended" or "Not A Bug"?
Comment 11 Vinícius Zavam freebsd_committer freebsd_triage 2018-11-19 15:45:09 UTC
(In reply to Tobias Kortkamp from comment #10)

hey, hi tobik@.
it definitely can! thank you.