在非systemd环境下使用dnscrypt-proxy

[nadebula]

Artix的wiki上有相关介绍，不过它用的是dnscrypt-proxy-openrc这个包。本人并未比较它和Debian中的dnscrypt-proxy有何不同，并且鉴于Arch和（本人常用的）Debian之间存在较大差异，并没有照搬这种workaround。
本人目前在不使用systemd的发行版上暂时这样配置（如Artix wiki所述，存在重大安全隐患）。其他配置文件的修改方式同Debian，在/etc/dnscrypt-proxy/dnscrypt-proxy.toml的listen_addresses参数后面的方括号中添加'127.0.2.1:53'（也就是/etc/dhcp/dhclient.conf中的prepend domain-name-servers参数后面跟着的IP地址）。
启动dnscrypt-proxy服务（本人自行研究发现的一种拙劣的workaround）：
# dnscrypt-proxy -config /etc/dnscrypt-proxy/dnscrypt-proxy.toml
保持该终端窗口打开。此笨拙workaround在MX（使用sysvinit）和Devuan（使用OpenRC）上测试通过，可访问被污染的网站。

注意：1，由于存在重大安全隐患（参见<https://wiki.artixlinux.org/Main/Dnscrypt-proxy>），务必设法在启动dnscrypt-proxy之后降低其权限。（本人尚未试验到这一步。）
2，如果想要尝试不带systemd的发行版，不要使用MX，它比Ubuntu更“污”，本人发现它将私有固件当作内核模块加载。
3，如需尝试Devuan，建议使用testing版本的二进制安装DVD，它类似于Debian Installer的每周构建镜像，只是暂时不能像Debian Installer那样通过jigdo更新。

[nadebula]

更新一些关于Devuan的测试结果：
目前已经基本解决了以root帐户运行dnscrypt-proxy带来的巨大安全隐患。
Devuan的testing介质尚不完善。最为重大的问题是包含私有固件并且默认启用私有源。技术方面，除了不能通过jigdo更新以外，它还未提供UEFI安装支持，以及在执行tasksel时，可选的桌面环境会有所不同（例如我试过的两个weekly build均不显示Gnome的选项）。
如果没有看到自己想要的桌面环境，可以先安装一个不带桌面环境的最简版本（已配置好网络），然后手动配置软件源（国内没有，我使用台湾镜像），利用tasksel或者通过对应meta-package安装桌面环境均可。