Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#50224 - [dnscrypt-proxy] service file broken without warning in upgrade

Attached to Project: Community Packages
Opened by rdeckard (rdeckard) - Monday, 01 August 2016, 12:06 GMT
Last edited by Eli Schwartz (eschwartz) - Thursday, 05 April 2018, 02:40 GMT
Task Type Bug Report
Category Packages
Status Closed
Assigned To Felix Yan (felixonmars)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 2
Private No

Details

Upgrading dnscrypt-proxy 1.6.1-1 -> 1.7.0-1 results in the dnscrypt-proxy.service file being changed without warning. The service file is now not usable on its own and is simply a template. Simply running "systemctl daemon-reload" and "systemctl restart dnscrypt-proxy" results in a failed service. The install file for the package should at least warn the user of this.

To get the previous behavior a user should edit a systemd drop-in file for the service with the following contents:

[Service]
ExecStart=
ExecStart=/usr/bin/dnscrypt-proxy \
-R dnscrypt.eu-nl

This task depends upon

Closed by  Eli Schwartz (eschwartz)
Thursday, 05 April 2018, 02:40 GMT
Reason for closing:  Won't implement
Additional comments about closing:   FS#57027  obsoletes this
Comment by Jakub Klinkovský (lahwaacz) - Monday, 01 August 2016, 12:31 GMT
That was done in https://github.com/jedisct1/dnscrypt-proxy/commit/45884045caf88bc136e12c4ad0f9e57334feec61, motivated by this pull request: https://github.com/jedisct1/dnscrypt-proxy/pull/428

IMO the systemd units should be installed to /usr/share/doc/ rather than /usr/lib/systemd/ since they don't work by default.
Comment by Indrajit Raychaudhuri (indrajitr) - Tuesday, 02 August 2016, 12:16 GMT
Alternately, consider creating a user dnscrypt-proxy via systemd-sysuser in /usr/lib/sysusers.d/dnscrypt-proxy.conf and patch dnscrypt-proxy.service to pick that user.
Comment by rdeckard (rdeckard) - Tuesday, 02 August 2016, 15:34 GMT
@indajitr that would be in addition to choosing a provider, which now has to be done manually.

I filed this bug because there is no warning that manual intervention is required.
Comment by Indrajit Raychaudhuri (indrajitr) - Tuesday, 02 August 2016, 20:08 GMT
@rdeckard, indeed!

My comment wasn't meant as a workaround. It was meant as a possible fix for the service unit (by explicitly providing a resolver-name, say dnscrypt.eu-nl, and providing a user, say dnscrypt-proxy which could be created via systemd-user).

This would be preferred over what @lahwaacz suggests.
Comment by Jakub Klinkovský (lahwaacz) - Tuesday, 02 August 2016, 20:33 GMT
I don't see a point in having a default resolver, since most users would still need to edit the unit to change that. It doesn't matter if they replace the pseudovariable "<resolver name>" or a filled in default, copying the template in place would also be very minor thing.

I think upstream agrees with me, otherwise they would not make the change in the first place :)

As for creating a new system user, that's tracked in  FS#49881 .
Comment by Indrajit Raychaudhuri (indrajitr) - Tuesday, 02 August 2016, 20:41 GMT
@lahwaacz, fair enough. In that case we need a post_upgrade() message to warn the users instead of breaking silently.
Comment by I Said Socks (socks) - Sunday, 28 August 2016, 07:58 GMT
Or, since this service file is actually a config, make it a %BACKUP%
Comment by Jakub Klinkovský (lahwaacz) - Sunday, 28 August 2016, 08:06 GMT
Making it a backup does not make sense, because users should never edit in /usr/lib/systemd/ (instead they edit the snippets in /etc/systemd/), so pacman would always overwrite the service file without making a pacnew file.
Comment by I Said Socks (socks) - Sunday, 28 August 2016, 08:15 GMT
Except the snippet in /etc/systemd is a symlink?

Perhaps the proper way is to use a dnscrypt-proxy@profile.service

EDIT: here's what I mean: https://gist.github.com/lolilolicon/0fd732edb3fdeddacf521b9b08717025
To use the resolver "cisco", simply `systemctl enable dnscrypt-proxy@cisco.service`

Edit: I don't know how to make socket activation work with this, so --local-address can be removed...
Comment by Eli Schwartz (eschwartz) - Wednesday, 07 February 2018, 17:54 GMT
Is this relevant anymore considering  FS#57027 ?

Loading...