https://wiki.archlinux.org/api.php?action=feedcontributions&user=Wincraft71&feedformat=atomArchWiki - User contributions [en]2024-03-28T19:53:14ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=525116Dnscrypt-proxy2018-06-08T07:30:52Z<p>Wincraft71: /* Select resolver */ While the package does not have the cache file for the resolvers list initially, it is created later on and is useful for configuration</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
<br />
The service can be started in two mutually exclusive ways (i.e. only one of the two may be enabled):<br />
<br />
* With the {{ic|.service}} file.<br />
<br />
{{Note|The {{ic|listen_addresses}} option must configured (e.g. {{ic|1=listen_addresses = ['127.0.0.1:53', '[::1]:53']}}) in the configuration file when using the {{ic|.service}} file.}}<br />
<br />
* Through the {{ic|.socket}} activation. <br />
<br />
{{Note|When using socket activation the {{ic|listen_addresses}} option must be set to empty (i.e. {{ic|1=listen_addresses = [ ]}}) in the configuration file, since systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
<br />
By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.<br />
<br />
To manually set which server is used, edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
A full list of resolvers is located at the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page] or [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github]. If ''dnscrypt-proxy'' has run successfully on the system before, {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}} will also contain a list. Look at the description for servers note which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
{{Expansion|Explain what the options mean.}}<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[start/enable]] the {{ic|dnscrypt-proxy.service}} unit or {{ic|dnscrypt-proxy.socket}}, depending on which method you chose above.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Tip|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
In order to forward queries from a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root.<br />
<br />
There are two methods for changing the default port:<br />
<br />
'''Socket method'''<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
When queries are forwarded from the local DNS cache to {{ic|53000}}, {{ic|dnscrypt-proxy.socket}} will start {{ic|dnscrypt-proxy.service}}.<br />
<br />
'''Service method'''<br />
<br />
Edit the {{ic|listen_addresses}} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} with the following:<br />
<br />
listen_addresses = ['127.0.0.1:53000', '[::1]:53000']<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID CAP_NET_BIND_SERVICE<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
{{Expansion|Name the advantages/motivation for enabling this.}}<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
<br />
options edns0<br />
<br />
{{Out of date|dnscrypt-proxy2 uses different config file.}}<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
{{Remove|Out of date and irrelevant since dnscrypt-proxy2 handles the configuration of multiple sources.}}<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:DNS over HTTPS]]</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Specialties&diff=524348Talk:Dm-crypt/Specialties2018-06-02T02:56:07Z<p>Wincraft71: /* The encrypt hook and multiple disks */ re</p>
<hr />
<div>== Downgrade the kernel using LVM on LUKS ==<br />
<br />
:''From [[Downgrade]]. I'm not familiar with this article series, so I'll have others decide on where it fits best. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 02:57, 25 August 2015 (UTC)''<br />
<br />
=== Discussion ===<br />
<br />
With my recent installation ISO, the dm_crypt and dm_mod modules are loaded automatically, and the lvm volume is activated automatically, so those commands can probably be removed from that section. Also, since this procedure is valid for any maintenance of an LVM on LUKS system, wouldn't it make more sense to have it on the LVM on LUKS page?<br />
[[User:Cmatteri|Cmatteri]] ([[User talk:Cmatteri|talk]]) 19:35, 20 March 2015 (UTC)<br />
<br />
:Well, there is no "LVM on LUKS" page. We had a discussion on similar issues [https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt&diff=315248&oldid=304026] and currently have no place to put it appropriately. You have an idea where to link it? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:05, 20 March 2015 (UTC)<br />
<br />
::I was thinking of [[Dm-crypt/Encrypting_an_entire_system#LUKS_on_LVM]]. The subject of that page is installation, but that also means that just about everyone using that setup knows about that page and may look there for more information. I don't have strong feelings though, and you've had more time to think about the organization. [[User:Cmatteri|Cmatteri]] ([[User talk:Cmatteri|talk]]) 00:04, 21 March 2015 (UTC)<br />
<br />
:::I've crosslinked it with [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_entire_system&diff=366459&oldid=365932], so we have a reference. If you shorten the content, I'd vote for leaving the lvm commands for activation in - just in case. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 10:36, 21 March 2015 (UTC)<br />
<br />
::::Moved to [[Talk:Dm-crypt/Specialties]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 04:07, 25 August 2015 (UTC)<br />
<br />
:I'm undecided what we should do with this section. I see three alternatives: <br />
:# It may be dropped and we may add a sentence or two for some of the [[Dm-crypt/Encrypting an entire system]] scenarios about how to access it from the ISO for repairs. <br />
:# We make it more elaborate and add a subsection per scenario at the end for it. <br />
:# We add a general subsection in [[Dm-crypt/System_configuration]] with a couple examples <br />
: Something like unlocking a LUKS encrypted root from an ISO & LVM activation should be covered somewhere in my view, that's why I tried to save the section in the previous location :)<br />
:Opinions? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 14:01, 13 September 2015 (UTC)<br />
<br />
::I think that if one has understood how he's created his specific stack, he's also able to reopen it from a live system without too much hand holding (which in this case would then be redundant IMO).<br />
::For this reason I'm for solution 3), although I'm not sure if [[Dm-crypt/System configuration]] is the best place to put it. For example [[dm-crypt/Device encryption]] already mentions dm_crypt, and deals with other maintenance tasks like [[Dm-crypt/Device_encryption#Backup_and_restore]].<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:36, 14 September 2015 (UTC)<br />
<br />
:::I prefer (3) as well. But you are right, not such a big deal and another choice is (4) Skip the topic for now; not necessary, if readers understood what they setup. <br />
:::[[Dm-crypt/Device encryption#Backup and restore]] is only about the header. I'd prefer that subpage to stick to the topics involved with the crypto/cryptsetup actions. [[Dm-crypt/System_configuration]] has more of the points one needs to touch when doing maintenance (fix fstab/crypttab, bootloader config). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:09, 14 September 2015 (UTC)<br />
<br />
::::Agreed on (4), let's wait until somebody else exhumes this thread, if that ever happens. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:32, 15 September 2015 (UTC)<br />
<br />
=== Section (see discussion above) ===<br />
<br />
Boot the Arch Linux installation ISO, and run the following commands to unlock the LUKS container and chroot into the system.<br />
<br />
Load the necessary kernel modules:<br />
<br />
# modprobe dm_crypt<br />
# modprobe dm_mod<br />
<br />
Unlock the LUKS container:<br />
<br />
# cryptsetup luksOpen /dev/sd''xY'' crypt<br />
<br />
Scan for and activate LVM volumes:<br />
<br />
# vgscan<br />
# vgchange -ay<br />
<br />
Create a folder for mounting and mount the partitions. Adapt this as necessary for the given system.<br />
<br />
# mkdir /mnt<br />
# mount /dev/mapper/''LVM-partition'' /mnt<br />
<br />
Mount the boot partition.<br />
<br />
# mount /dev/sd''xZ'' /mnt/boot<br />
<br />
Chroot into the mounted filesystem.<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
At this point, follow the instructions in the previous section [[#Downgrading the kernel]].<br />
<br />
Source: http://sch1zo.github.com/blog/2012/05/08/downgrading-a-bad-kernel-on-arch-with-luks-and-lvm/<br />
<br />
== dm-verity ==<br />
It might be helpful to mention dm-verity on this page and also to reference [[Secure_Boot]]<br />
{{unsigned| 18:34, 31 May 2016|MountainX}}<br />
<br />
:Yes, both would be nice. For dm-verity I think it would be neater to let it have its own short article actually, which can be crosslinked from here and other articles like [[Secure Boot]], etc. However, as long as there is no install instructions for it, it might as well be mentioned in [[Dm-crypt/Specialties#Other methods]]. Please go ahead, if you want. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 11:41, 2 June 2016 (UTC)<br />
<br />
== Encrypted /boot and a detached LUKS header on USB ==<br />
<br />
Besides violating multiple style rules (which I couldn't be bothered to list in the style template) [[dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB]] is over complicated for very little gain.<br />
<br />
By not placing the keyfile and LUKS header in initramfs it only makes it more complex. A simpler solution would be to combine [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] and [[dm-crypt/Specialties#Encrypted system using a detached LUKS header]] into something like:<br />
<br />
{{bc|<nowiki><br />
+---------------+---------------+ +-----------------------+-----------------------+-----------------------+<br />
|ESP: |Boot partition:| |Volume 1: |Volume 2: |Volume 3: |<br />
| | | | | | |<br />
|/boot/efi |/boot | |root |swap |home |<br />
| | | | | | |<br />
| | | |/dev/mapper/store-root |/dev/mapper/store-swap |/dev/mapper/store-home |<br />
|/dev/sda1 |/dev/sda2 + +-----------------------+-----------------------+-----------------------+<br />
|unencrypted |LUKS encrypted | | /dev/sdb encrypted using LVM on LUKS with a detached header |<br />
+---------------+---------------+ +-----------------------------------------------------------------------+<br />
| USB drive /dev/sda | | HDD /dev/sdb (unpartitioned) |<br />
+-------------------------------+ +-----------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
With {{ic|sd-encrypt}} it wouldn't even require any custom hooks. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:11, 3 January 2018 (UTC)<br />
<br />
:That's what I initially did but when systemd handles the boot via crypttab.initramfs it adds an unnecessary start job for the keyfile and the system will only boot if you go to the emergency shell and mask that startjob using {{ic|ln -s}}. Also that depends on the initramfs image having the header and keyfile inside of it, versus getting it in realtime from the USB directly. While it is more lines of code, the custom hook is easier to boot up with less waiting time. While simply combining different sections from different articles is one "solution", I believe putting it all together for future generations has more value of it own.<br />
<br />
:Regardless, having the header and keyfile on its own and not inserted into an image enhances security because it would completely require the USB drive to boot which is what I thought was the main point of having a seperate usb bootable key, versus having it on an image that does not necessarily depend on the USB to the same degree. While an attacker could theoretically copy the header if they can also access the initramfs image, I believe the extra layer of complexity and closing the keyfile before we boot into the system can mitigate this. Also note that the sections you reference have no instructions for creating a LUKS encrypted keyfile.<br />
<br />
:Another point is that without the embedded header in the initramfs, the user is easily able to "disable" a usb key by removing or corrupting the header, granted they have a well-protected and safe encrypted backup offline or in secure storage online. This would be useful for a scenario where a user needs a USB key to appear that it works but actually doesn't for somewhat of a plausible deniability. Otherwise, they would have to remake initcpio after removing it from /etc/mkinitcpio.conf then restore the old one to put the header back in. <br />
<br />
:Lastly, in the event that the header, initramfs, and keyfile have been taken from memory or the disk or otherwise compromised, or the user is simply reencrypting or changing keys preemptively, the user can go offline by disabling all networking and {{ic|cryptsetup-reencrypt}} to change the master key (volume key) of the disk and header or change the keyfile using [[Dm-crypt/Specialties#Changing_the_LUKS_keyfile]]. All changes would simply work when they boot back into the system and require no regeneration of the initramfs. The user could even do it from an install cd or a live usb of a different linux operating system.<br />
<br />
:If you could please tell me specifically about the "multiple style rules" I have violated, I will gladly have that fixed as soon as possible. - [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 02:43, 4 January 2018 (UTC)<br />
<br />
::Is there a bug report for the unnecessary systemd start job? It sounded like something I've seen referenced before, but after checking [https://github.com/systemd/systemd/issues/3816] that's a different issue.<br />
::I don't see the need to avoid placing the keyfile in initramfs when initramfs resides in a '''encrypted''' {{ic|/boot}}. As long as {{ic|/boot}} is not unlocked everything in it is ''safe''™.<br />
::About style, read all of [[Help:Reading]], [[Help:Editing]], [[Help:Style]], [[Help:Style/Formatting and punctuation]], [[Help:Style/White space]]. At a quick glance I spot these issues:<br />
::* [[Help:Style#Command line text]]<br />
::* [[Help:Style#Code formatting]]<br />
::* [[Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...]]<br />
::* [[Help:Style/Formatting and punctuation#Pseudo-variables in file/command line contents]]<br />
::* [[Help:Style/Formatting and punctuation#File names and paths]]<br />
::<br />
::Now about the content:<br />
::* [[dm-crypt/Specialties#Preparing the disk devices]] should not duplicate [[dm-crypt/Drive preparation]]. Don't provide the specific commands, just tell what needs to be done and like the appropriate article explaining how to do it. Also don't specify cryptsetup's hash, cypher, key-size etc. options, use the defaults and link to [[dm-crypt/Device encryption#Encryption options for LUKS mode]]. Try to avoid duplicating instructions already available in other wiki pages and link to them instead, the wiki is not a tutorial.<br />
::* [[dm-crypt/Specialties#The actual installation procedure and custom encrypt hook]] - use pseudo variables. {{ic|/usr/lib/initcpio/}} is package manager territory, custom hooks should be placed in {{ic|/etc/initcpio/}}. If a file doesn't need to be changed just copy it, look at [[dm-crypt/Specialties#Modifying encrypt hook]].<br />
::and more... -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 10:19, 4 January 2018 (UTC)<br />
<br />
:::That's the thing about /boot however, is that you have to mount it eventually for system updates (kernel files) or regenerating the initramfs (after you update the kernel), and in doing so expose it to potential attacks. The user will probably have the keyfile somewhere on their usb from when they generated it, and if somebody copies your keyfile or initramfs while /boot is unencrypted then you are hosed. The main need would be easy changing of the keyfile without having to regenerate the initramfs, and the extra privacy since boot does have to be eventually mounted. I believe I've seen something like that on Github issues for systemd when I was searching, but I can't remember exactly. I can try finding it from my browser history if you want. I thank you kindly for the necessary resources on improving the style, formatting, and content. I will begin immediately on improvements and come back to this talk page when they are done to see if there is anything else that needs to be done. - [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 11:18, 4 January 2018 (UTC)<br />
<br />
::::You forgot the whitespace after the prompt symbol. Why are there empty lines between commands and a weird indentation in {{ic|customencrypthook}} [[dm-crypt/Specialties#The actual installation procedure and custom encrypt hook]]? Also unless it's a long code block it's preferred to start the line with a whitespace ([[Help:Editing#Code]]) instead of using [[Template:bc]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 14:39, 4 January 2018 (UTC)<br />
<br />
:::::Okay those are fixed and thanks for the suggestions, how is it looking now? -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:41, 4 January 2018 (UTC)<br />
<br />
::::::You forgot [[Special:Diff/506028|these empty lines]]. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:57, 4 January 2018 (UTC)<br />
<br />
::::::: Thanks for the assist, besides the out of scope backup section, what should we do now? -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 16:15, 4 January 2018 (UTC)<br />
<br />
::::::::[[dm-crypt/Specialties#Preparing the USB key]] need simplifying, preferably with links to [[Partitioning]] and [[EFI System Partition]]. [[dm-crypt/Specialties#The actual installation procedure and custom encrypt hook]] - the {{ic|ls *}} stuff needs to disappear, link to [[Persistent block device naming#by-id and by-path]] and use pseudo variables. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:23, 4 January 2018 (UTC)<br />
<br />
:::::::::Are there any other pseudo-variables that I need? -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 17:01, 4 January 2018 (UTC)<br />
<br />
::::::::::I don't think so.<br />
::::::::::Try to add more wikilinks and man page links for detailed explanations. For example for GRUB cryptodisk - [[GRUB#Boot partition]]. For efibootmgr instead of explaining all options link to {{man|8|efibootmgr}}. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 17:25, 4 January 2018 (UTC)<br />
<br />
::::::::Instead of suggesting partition sizes link to [[Partitioning]] and use [[w:MiB|MiB]] & [[w:GiB|GiB]] instead MB & GB. [[dm-crypt/Specialties#Installation procedure and custom encrypt hook]] could use a bit of simplification, it should not reiterate the [[Installation guide]]. Just specify at which point these instructions should be used. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 15:18, 12 January 2018 (UTC)<br />
<br />
:::::::::It is now simplified -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:38, 13 January 2018 (UTC)<br />
<br />
==<s> The encrypt hook and multiple disks </s>==<br />
<br />
Does this take into account virtual machines, and resizing the disk of the guest? [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 07:12, 19 April 2018 (UTC)<br />
<br />
:My meaning with this was: there are sections for Expanding LVM on multiple disks and Modifying the encrypt hook for multiple partitions. Resizing the disk size of a virtual machine/VPS guest is a fairly common task. Does this need to be included as well? [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 04:08, 28 May 2018 (UTC)<br />
<br />
::Resizing LVM is already thoroughly covered in [[LVM]] and related articles, it should not be included also here (there's already an ''lvextend'' example anyway), closed. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:22, 29 May 2018 (UTC)<br />
<br />
:::What if the volume you're resizing is encrypted? [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 10:06, 1 June 2018 (UTC)<br />
<br />
::::See [[Resizing_LVM-on-LUKS]] from the sidebar of [[LVM]] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 02:56, 2 June 2018 (UTC)<br />
<br />
== Multiple non-root partitions ==<br />
<br />
What about [https://www.martineve.com/2012/11/02/luks-encrypting-multiple-partitions-on-debianubuntu-with-a-single-passphrase/ this]? I just tried steps 4, 5, and 6 in Arch, and it works. You have to remember to run {{ic|mkinitcpio -p linux}} instead of {{ic|update-initramfs -u}}, but it's a lot less clunky than the current example. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 03:51, 24 May 2018 (UTC)<br />
<br />
:Your linked guide basically uses the setup described in [[dm-crypt/Encrypting a non-root file system#At boot time]], the partitions will be unlocked only after switch root.<br />
:[[dm-crypt/Specialties#Multiple non-root partitions]] is specifically about unlocking the non-root partition(s) at the initramfs stage. Unless you really need to unlock the partition in the initramfs, it's easier to unlock it from crypttab after boot.<br />
:-- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:17, 24 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=523948Dnscrypt-proxy2018-05-30T17:25:38Z<p>Wincraft71: /* Change port */ Reflect that there are two methods for changing the port.</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
<br />
The service can be started in two mutually exclusive ways (i.e. only one of the two may be enabled):<br />
<br />
* With the {{ic|.service}} file<br />
* Through the {{ic|.socket}} activation aka unix socket activation (which then starts the service on access of said socket).<br />
<br />
{{Note|For using the service directly, the {{ic|listen_addresses }} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} has to be configured (e.g. {{ic|1=listen_addresses = ['127.0.0.1:53', '[::1]:53']}}). However, when using unix socket activation the option has to be the empty set (i.e. {{ic|1=listen_addresses = [ ]}}), as systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.<br />
}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
{{Expansion|Explain what the options mean.}}<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[start/enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
In order to forward queries from a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root.<br />
<br />
There are two methods for changing the default port:<br />
<br />
'''Socket method'''<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
When queries are forwarded from the local DNS cache to {{ic|53000}}, {{ic|dnscrypt-proxy.socket}} will start {{ic|dnscrypt-proxy.service}}.<br />
<br />
'''Service method'''<br />
<br />
Edit the {{ic|listen_addresses}} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} with the following:<br />
<br />
listen_addresses = ['127.0.0.1:53000', '[::1]:53000']<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID CAP_NET_BIND_SERVICE<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
{{Expansion|Name the advantages/motivation for enabling this.}}<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
<br />
options edns0<br />
<br />
{{Out of date|dnscrypt-proxy2 uses different config file.}}<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
{{Remove|Out of date and irrelevant since dnscrypt-proxy2 handles the configuration of multiple sources.}}<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523854Talk:Dnscrypt-proxy2018-05-29T09:48:55Z<p>Wincraft71: /* Startup method when using Unbound */ re</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. As it is now, the {{ic|dnscrypt-proxy.toml}} file contains {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}} so for an average user following [[DNSCrypt#Unbound]] (especially when coming directly from the [[Unbound]] page) this would lead to a misconfiguration. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:34, 28 May 2018 (UTC)<br />
<br />
:You need to 1. configure [[unbound]], and 2. configure [[DNSCrypt]], so you should read both pages (from the start). Why is that not clear? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:11, 28 May 2018 (UTC)<br />
::Okay, let's say the reader starts from [[Unbound]] then follows the link to [[DNSCrypt]] or [[DNSCrypt#Unbound]] from [[Unbound#Forwarding_queries]]. Nowhere in [[DNSCrypt]] now does it explicitly say "Use the socket method for Unbound and DNSCrypt". But you need to use the socket method for Unbound + DNSCrypt to work. Why are you acting like it's so perfectly clear when it's not? Not every reader is going to be able to surmise that forwarding queries to DNSCrypt requires the socket method and editing the config to work. Would it really kill you to make a brief mention that Unbound uses the socket method in [[DNSCrypt#Startup]]? Either way the readers should have examples of which option to choose based on different uses. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:05, 28 May 2018 (UTC)<br />
<br />
::If you still haven't seen the need, this is a matter of config files and systemd. In the old dnscrypt the listen address was configured as expected:<br />
<br />
::{{bc|If the socket is created by systemd, the proxy cannot change the address using this option. You should edit systemd's dnscrypt-proxy.socket file instead.}}<br />
<br />
::The user could have followed [[DNSCrypt#Change_port]] and it worked as expected.<br />
<br />
::In the first versions of the new dnscrypt-proxy the {{ic|<nowiki>listen_addresses = [ ]</nowiki>}} was blank so it did not interfere. Now the config comes with {{ic|listen_addresses}} filled in so that the user has to manually empty it or the {{ic|.service}} will listen on those addresses[https://raw.githubusercontent.com/jedisct1/dnscrypt-proxy/master/dnscrypt-proxy/example-dnscrypt-proxy.toml]. Not only does this interfere with existing setups (such as using DNSCrypt with Unbound), but it is also a caveat that new users deserve to know about. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:04, 28 May 2018 (UTC)<br />
<br />
:::In any case, users can get to know about this in [[DNSCrypt#Startup]] (see the note). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:40, 28 May 2018 (UTC)<br />
::::The users should at least have a hint that it's related to DNSCrypt + Unbound working successfully, such as "unix socket activation" being given an example: "when using unix socket activation (such as when forwarding to a local DNS cache)" -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 23:42, 28 May 2018 (UTC)<br />
<br />
:::::It's not related to DNSCrypt + Unbound, the startup method of DNSCrypt is irrelevant for Unbound. If you enable {{ic|dnscrypt-proxy.service}} (and disable {{ic|dnscrypt-socket.service}}) and set {{ic|1=listen_addresses = ['127.0.0.1:53000', '[::1]:53000']}} in {{ic|dnscrypt-proxy.toml}}, it will too. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:47, 29 May 2018 (UTC)<br />
<br />
::::::Since that is a possible alternative, shouldn't that be stated in [[DNSCrypt#Change port]] as another option? -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 09:48, 29 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=523812Dnscrypt-proxy2018-05-29T01:17:52Z<p>Wincraft71: /* Change port */ better explain ports and socket activation</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
The service can be started in two mutually exclusive ways (i.e. only one of the two may be enabled):<br />
* With the {{ic|.service}} file (default)<br />
* Through the {{ic|.socket}} activation aka unix socket activation (which then starts the service on access of said socket).<br />
<br />
{{Note|For using the service directly, the {{ic|listen_addresses }} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} has to be configured (e.g. {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}}). However, when using unix socket activation the option has to be the empty set (i.e. {{ic|1=listen_addresses = [ ] }}), as systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
{{Expansion|Explain what the options mean.}}<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
In order to forward queries from a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
When queries are forwarded from the local DNS cache to {{ic|53000}}, {{ic|dnscrypt-proxy.socket}} will start {{ic|dnscrypt-proxy.service}}.<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID CAP_NET_BIND_SERVICE<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
{{Expansion|Name the advantages/motivation for enabling this.}}<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
{{Out of date|dnscrypt-proxy2 uses different config file.}}<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
{{Remove|Out of date and irrelevant since dnscrypt-proxy2 handles the configuration of multiple sources.}}<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523811Talk:Dnscrypt-proxy2018-05-28T23:42:44Z<p>Wincraft71: /* Startup method when using Unbound */ re</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. As it is now, the {{ic|dnscrypt-proxy.toml}} file contains {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}} so for an average user following [[DNSCrypt#Unbound]] (especially when coming directly from the [[Unbound]] page) this would lead to a misconfiguration. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:34, 28 May 2018 (UTC)<br />
<br />
:You need to 1. configure [[unbound]], and 2. configure [[DNSCrypt]], so you should read both pages (from the start). Why is that not clear? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:11, 28 May 2018 (UTC)<br />
::Okay, let's say the reader starts from [[Unbound]] then follows the link to [[DNSCrypt]] or [[DNSCrypt#Unbound]] from [[Unbound#Forwarding_queries]]. Nowhere in [[DNSCrypt]] now does it explicitly say "Use the socket method for Unbound and DNSCrypt". But you need to use the socket method for Unbound + DNSCrypt to work. Why are you acting like it's so perfectly clear when it's not? Not every reader is going to be able to surmise that forwarding queries to DNSCrypt requires the socket method and editing the config to work. Would it really kill you to make a brief mention that Unbound uses the socket method in [[DNSCrypt#Startup]]? Either way the readers should have examples of which option to choose based on different uses. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:05, 28 May 2018 (UTC)<br />
<br />
::If you still haven't seen the need, this is a matter of config files and systemd. In the old dnscrypt the listen address was configured as expected:<br />
<br />
::{{bc|If the socket is created by systemd, the proxy cannot change the address using this option. You should edit systemd's dnscrypt-proxy.socket file instead.}}<br />
<br />
::The user could have followed [[DNSCrypt#Change_port]] and it worked as expected.<br />
<br />
::In the first versions of the new dnscrypt-proxy the {{ic|<nowiki>listen_addresses = [ ]</nowiki>}} was blank so it did not interfere. Now the config comes with {{ic|listen_addresses}} filled in so that the user has to manually empty it or the {{ic|.service}} will listen on those addresses[https://raw.githubusercontent.com/jedisct1/dnscrypt-proxy/master/dnscrypt-proxy/example-dnscrypt-proxy.toml]. Not only does this interfere with existing setups (such as using DNSCrypt with Unbound), but it is also a caveat that new users deserve to know about. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:04, 28 May 2018 (UTC)<br />
<br />
:::In any case, users can get to know about this in [[DNSCrypt#Startup]] (see the note). -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:40, 28 May 2018 (UTC)<br />
::::The users should at least have a hint that it's related to DNSCrypt + Unbound working successfully, such as "unix socket activation" being given an example: "when using unix socket activation (such as when forwarding to a local DNS cache)" -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 23:42, 28 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=523810Dnscrypt-proxy2018-05-28T23:38:57Z<p>Wincraft71: /* Startup */ formatting and correction about address</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
The service can be started in two mutually exclusive ways (i.e. only one of the two may be enabled):<br />
* With the {{ic|.service}} file (default)<br />
* Through the {{ic|.socket}} activation aka unix socket activation (which then starts the service on access of said socket).<br />
<br />
{{Note|For using the service directly, the {{ic|listen_addresses }} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} has to be configured (e.g. {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}}). However, when using unix socket activation the option has to be the empty set (i.e. {{ic|1=listen_addresses = [ ] }}), as systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
{{Expansion|Explain what the options mean.}}<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID CAP_NET_BIND_SERVICE<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
{{Expansion|Name the advantages/motivation for enabling this.}}<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
{{Out of date|dnscrypt-proxy2 uses different config file.}}<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
{{Remove|Out of date and irrelevant since dnscrypt-proxy2 handles the configuration of multiple sources.}}<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523802Talk:Dnscrypt-proxy2018-05-28T22:06:45Z<p>Wincraft71: /* Startup method when using Unbound */ monospace</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. As it is now, the {{ic|dnscrypt-proxy.toml}} file contains {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}} so for an average user following [[DNSCrypt#Unbound]] (especially when coming directly from the [[Unbound]] page) this would lead to a misconfiguration. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:34, 28 May 2018 (UTC)<br />
<br />
:You need to 1. configure [[unbound]], and 2. configure [[DNSCrypt]], so you should read both pages (from the start). Why is that not clear? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:11, 28 May 2018 (UTC)<br />
::Okay, let's say the reader starts from [[Unbound]] then follows the link to [[DNSCrypt]] or [[DNSCrypt#Unbound]] from [[Unbound#Forwarding_queries]]. Nowhere in [[DNSCrypt]] now does it explicitly say "Use the socket method for Unbound and DNSCrypt". But you need to use the socket method for Unbound + DNSCrypt to work. Why are you acting like it's so perfectly clear when it's not? Not every reader is going to be able to surmise that forwarding queries to DNSCrypt requires the socket method and editing the config to work. Would it really kill you to make a brief mention that Unbound uses the socket method in [[DNSCrypt#Startup]]? Either way the readers should have examples of which option to choose based on different uses. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:05, 28 May 2018 (UTC)<br />
<br />
::If you still haven't seen the need, this is a matter of config files and systemd. In the old dnscrypt the listen address was configured as expected:<br />
<br />
::{{bc|If the socket is created by systemd, the proxy cannot change the address using this option. You should edit systemd's dnscrypt-proxy.socket file instead.}}<br />
<br />
::The user could have followed [[DNSCrypt#Change_port]] and it worked as expected.<br />
<br />
::In the first versions of the new dnscrypt-proxy the {{ic|<nowiki>listen_addresses = [ ]</nowiki>}} was blank so it did not interfere. Now the config comes with {{ic|listen_addresses}} filled in so that the user has to manually empty it or the {{ic|.service}} will listen on those addresses[https://raw.githubusercontent.com/jedisct1/dnscrypt-proxy/master/dnscrypt-proxy/example-dnscrypt-proxy.toml]. Not only does this interfere with existing setups (such as using DNSCrypt with Unbound), but it is also a caveat that new users deserve to know about. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:04, 28 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523801Talk:Dnscrypt-proxy2018-05-28T22:04:11Z<p>Wincraft71: /* Startup method when using Unbound */ second re</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. As it is now, the {{ic|dnscrypt-proxy.toml}} file contains {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}} so for an average user following [[DNSCrypt#Unbound]] (especially when coming directly from the [[Unbound]] page) this would lead to a misconfiguration. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:34, 28 May 2018 (UTC)<br />
<br />
:You need to 1. configure [[unbound]], and 2. configure [[DNSCrypt]], so you should read both pages (from the start). Why is that not clear? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:11, 28 May 2018 (UTC)<br />
::Okay, let's say the reader starts from [[Unbound]] then follows the link to [[DNSCrypt]] or [[DNSCrypt#Unbound]] from [[Unbound#Forwarding_queries]]. Nowhere in [[DNSCrypt]] now does it explicitly say "Use the socket method for Unbound and DNSCrypt". But you need to use the socket method for Unbound + DNSCrypt to work. Why are you acting like it's so perfectly clear when it's not? Not every reader is going to be able to surmise that forwarding queries to DNSCrypt requires the socket method and editing the config to work. Would it really kill you to make a brief mention that Unbound uses the socket method in [[DNSCrypt#Startup]]? Either way the readers should have examples of which option to choose based on different uses. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:05, 28 May 2018 (UTC)<br />
<br />
::If you still haven't seen the need, this is a matter of config files and systemd. In the old dnscrypt the listen address was configured as expected:<br />
<br />
::{{bc|If the socket is created by systemd, the proxy cannot change the address using this option. You should edit systemd's dnscrypt-proxy.socket file instead.}}<br />
<br />
::The user could have followed [[DNSCrypt#Change_port]] and it worked as expected.<br />
<br />
::In the first versions of the new dnscrypt-proxy the listen_addresses = [ ] was blank so it did not interfere. Now the config comes with listen_addresses filled in that the user has to manually empty or the {{ic|.service}} will listen on those addresses[https://raw.githubusercontent.com/jedisct1/dnscrypt-proxy/master/dnscrypt-proxy/example-dnscrypt-proxy.toml]. Not only does this interfere with existing setups (such as using DNSCrypt with Unbound), but it is also a caveat that new users deserve to know about. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:04, 28 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523785Talk:Dnscrypt-proxy2018-05-28T21:05:56Z<p>Wincraft71: /* Startup method when using Unbound */ re</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. As it is now, the {{ic|dnscrypt-proxy.toml}} file contains {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}} so for an average user following [[DNSCrypt#Unbound]] (especially when coming directly from the [[Unbound]] page) this would lead to a misconfiguration. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:34, 28 May 2018 (UTC)<br />
<br />
:You need to 1. configure [[unbound]], and 2. configure [[DNSCrypt]], so you should read both pages (from the start). Why is that not clear? -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:11, 28 May 2018 (UTC)<br />
::Okay, let's say the reader starts from [[Unbound]] then follows the link to [[DNSCrypt]] or [[DNSCrypt#Unbound]] from [[Unbound#Forwarding_queries]]. Nowhere in [[DNSCrypt]] now does it explicitly say "Use the socket method for Unbound and DNSCrypt". But you need to use the socket method for Unbound + DNSCrypt to work. Why are you acting like it's so perfectly clear when it's not? Not every reader is going to be able to surmise that forwarding queries to DNSCrypt requires the socket method and editing the config to work. Would it really kill you to make a brief mention that Unbound uses the socket method in [[DNSCrypt#Startup]]? Either way the readers should have examples of which option to choose based on different uses. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:05, 28 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523754Talk:Dnscrypt-proxy2018-05-28T15:34:23Z<p>Wincraft71: /* Startup method when using Unbound */ note about default listen_addresses in config</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. As it is now, the {{ic|dnscrypt-proxy.toml}} file contains {{ic|<nowiki>listen_addresses = ['127.0.0.1:53', '[::1]:53']</nowiki>}} so for an average user following [[DNSCrypt#Unbound]] (especially when coming directly from the [[Unbound]] page) this would lead to a misconfiguration. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 15:34, 28 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523751Talk:Dnscrypt-proxy2018-05-28T14:33:13Z<p>Wincraft71: /* Startup method when using Unbound */ fix links</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[DNSCrypt#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[DNSCrypt#Startup]] section. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 14:31, 28 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523750Talk:Dnscrypt-proxy2018-05-28T14:31:59Z<p>Wincraft71: /* Startup method when using Unbound */ signature</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[#Startup]] section. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 14:31, 28 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523749Talk:Dnscrypt-proxy2018-05-28T14:31:38Z<p>Wincraft71: unbound using empty listen_addresses and socket method should be specified clearly</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)<br />
<br />
== Startup method when using Unbound ==<br />
<br />
It should be specified clearly that Unbound uses the socket method with empty listen_addresses from the [[#Startup]] section and upstream [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-ArchLinux].<br />
<br />
Something along the lines of "When forwarding queries with [[Unbound]], ''dnscrypt-proxy'' should be started through {{ic|dnscrypt-proxy.socket}}" in the [[#Startup]] section.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=523648Dnscrypt-proxy2018-05-27T23:41:29Z<p>Wincraft71: /* Sandboxing */ dnscrypt-proxy needs "CAP_NET_BIND_SERVICE" capabilities</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
The service can be started in two (mutually exclusive) ways (i.e. only one of the two may be enabled): With the {{ic|.service}} file (default) or through {{ic|.socket}} activation aka. unix socket activation (which then starts the service on access of said socket).<br />
<br />
{{Note|For using the service directly, the {{ic|listen_addresses }} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} has to be configured (e.g. {{ic|1=listen_addresses = [ "127.0.0.1:53" ] }}). However, when using unix socket activation the option has to be the empty set (i.e. {{ic|1=listen_addresses = [ ] }}), as systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
As described in [[#Startup]], {{ic|listen_addresses}} in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} should be empty and only {{ic|dnscrypt-proxy.socket}} needs to be enabled and started.<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID CAP_NET_BIND_SERVICE<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=SELinux&diff=523646SELinux2018-05-27T23:12:06Z<p>Wincraft71: /* SELinux aware system utilities */ alphabetical order</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Kernel]]<br />
[[ja:SELinux]]<br />
[[ru:SELinux]]<br />
{{Related articles start}}<br />
{{Related|Security}}<br />
{{Related|AppArmor}}<br />
{{Related|TOMOYO Linux}}<br />
{{Related articles end}}<br />
<br />
Security-Enhanced Linux (SELinux) is a Linux feature that provides a variety of security policies, including U.S. Department of Defense style [[Mandatory Access Control]] (MAC), through the use of Linux Security Modules (LSM) in the Linux kernel. It is not a Linux distribution, but rather a set of modifications that can be applied to Unix-like operating systems, such as Linux and BSD.<br />
<br />
Running SELinux under a Linux distribution requires three things: An SELinux enabled kernel, SELinux Userspace tools and libraries, and SELinux Policies (mostly based on the Reference Policy). Some common Linux programs will also need to be patched/compiled with SELinux features.<br />
<br />
==Current status in Arch Linux==<br />
<br />
SELinux is not officially supported (see [https://lists.archlinux.org/pipermail/arch-general/2013-October/034352.html][https://lists.archlinux.org/pipermail/arch-general/2017-February/043149.html]). The status of unofficial support is:<br />
<br />
{| class="wikitable"<br />
! Name !! Status !! Available at<br />
|-<br />
| SELinux enabled kernel || Implemented for {{pkg|linux-hardened}}, but not {{pkg|linux}} || Removed since the 3.14 official {{pkg|linux}} kernel.<br />
|-<br />
| SELinux Userspace tools and libraries || Implemented in AUR: https://aur.archlinux.org/packages/?O=0&K=selinux || Work is done at https://github.com/archlinuxhardened/selinux<br />
|-<br />
| SELinux Policy || Work in progress, using [https://github.com/TresysTechnology/refpolicy Reference Policy] as upstream || Upstream: https://github.com/TresysTechnology/refpolicy (since release 20170805 the policy has integrated support for systemd and single-/usr/bin directory)<br />
|}<br />
<br />
Summary of changes in AUR as compared to official core packages:<br />
<br />
{| class="wikitable"<br />
! Name !! Status and comments<br />
|-<br />
| linux || Need a rebuild with some KConfig options enabled<br />
|-<br />
| linux-hardened || SELinux support enabled, but audit support is disabled by default and needs to be enabled with audit=1 on the kernel line<br />
|-<br />
| coreutils || Need a rebuild with {{ic|--with-selinux}} flag to link with libselinux<br />
|-<br />
| cronie || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| dbus || Need a rebuild with {{ic|--enable-libaudit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| findutils || Need a rebuild with libselinux installed to enable SELinux-specific options<br />
|-<br />
| iproute2 || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| logrotate || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| openssh || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| pam || Need a rebuild with {{ic|--enable-selinux}} flag for Linux-PAM ; Need a patch for pam_unix2, which only removes a function already implemented in a recent versions of libselinux<br />
|-<br />
| pambase || Configuration changes to add pam_selinux.so to {{ic|/etc/pam.d/system-login}}<br />
|-<br />
| psmisc || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| shadow || Need a rebuild with {{ic|--with-selinux}} flags<br />
|-<br />
| sudo || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
| systemd || Need a rebuild with {{ic|--enable-audit}} and {{ic|--enable-selinux}} flags<br />
|-<br />
| util-linux || Need a rebuild with {{ic|--with-selinux}} flag<br />
|-<br />
|}<br />
<br />
All of the other SELinux-related packages may be included without changes nor risks.<br />
<br />
==Concepts: Mandatory Access Controls==<br />
<br />
{{Note|This section is meant for beginners. If you know what SELinux does and how it works, feel free to skip ahead to the installation.}}<br />
<br />
Before you enable SELinux, it is worth understanding what it does. Simply and succinctly, SELinux enforces ''Mandatory Access Controls (MACs)'' on Linux. In contrast to SELinux, the traditional user/group/rwx permissions are a form of ''Discretionary Access Control (DAC)''. MACs are different from DACs because security policy and its execution are completely separated.<br />
<br />
An example would be the use of the ''sudo'' command. When DACs are enforced, sudo allows temporary privilege escalation to root, giving the process so spawned unrestricted systemwide access. However, when using MACs, if the security administrator deems the process to have access only to a certain set of files, then no matter what the kind of privilege escalation used, unless the security policy itself is changed, the process will remain constrained to simply that set of files. So if ''sudo'' is tried on a machine with SELinux running in order for a process to gain access to files its policy does not allow, it will fail.<br />
<br />
Another set of examples are the traditional (-rwxr-xr-x) type permissions given to files. When under DAC, these are user-modifiable. However, under MAC, a security administrator can choose to freeze the permissions of a certain file by which it would become impossible for any user to change these permissions until the policy regarding that file is changed.<br />
<br />
As you may imagine, this is particularly useful for processes which have the potential to be compromised, i.e. web servers and the like. If DACs are used, then there is a particularly good chance of havoc being wreaked by a compromised program which has access to privilege escalation.<br />
<br />
For further information, visit [[wikipedia:Mandatory access control]].<br />
<br />
==Installing SELinux==<br />
<br />
===Package description===<br />
<br />
All SELinux related packages belong to the ''selinux'' group in the AUR.<br />
<br />
====SELinux aware system utilities====<br />
<br />
;{{AUR|coreutils-selinux}}<br />
:Modified coreutils package compiled with SELinux support enabled. It replaces the {{pkg|coreutils}} package<br />
<br />
;{{AUR|cronie-selinux}}<br />
:Fedora fork of Vixie cron with SELinux enabled. It replaces the {{pkg|cronie}} package.<br />
<br />
;{{AUR|dbus-selinux}}<br />
:An SELinux aware version of [[D-Bus]]. It replaces the {{pkg|dbus}} package.<br />
<br />
;{{AUR|findutils-selinux}}<br />
:Patched findutils package compiled with SELinux support to make searching of files with specified security context possible. It replaces the {{pkg|findutils}} package.<br />
<br />
;{{AUR|iproute2-selinux}}<br />
:iproute2 package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|ss}}. It replaces the {{pkg|iproute2}} package.<br />
<br />
;{{AUR|logrotate-selinux}}<br />
:Logrotate package compiled with SELinux support. It replaces the {{pkg|logrotate}} package.<br />
<br />
;{{AUR|openssh-selinux}}<br />
:[[OpenSSH]] package compiled with SELinux support to set security context for user sessions. It replaces the {{pkg|openssh}} package.<br />
<br />
;{{AUR|pam-selinux}} and {{AUR|pambase-selinux}}<br />
:PAM package with pam_selinux.so. and the underlying base package. They replace the {{pkg|pam}} and {{pkg|pambase}} packages respectively.<br />
<br />
;{{AUR|psmisc-selinux}}<br />
:Psmisc package compiled with SELinux support; for example, it adds the {{ic|-Z}} option to {{ic|killall}}. It replaces the {{pkg|psmisc}} package.<br />
<br />
;{{AUR|shadow-selinux}}<br />
:Shadow package compiled with SELinux support; contains a modified {{ic|/etc/pam.d/login}} file to set correct security context for user after login. It replaces the {{pkg|shadow}} package.<br />
<br />
;{{AUR|sudo-selinux}}<br />
:Modified [[sudo]] package compiled with SELinux support which sets the security context correctly. It replaces the {{pkg|sudo}} package.<br />
<br />
;{{AUR|systemd-selinux}}<br />
:An SELinux aware version of [[Systemd]]. It replaces the {{pkg|systemd}} package.<br />
<br />
;{{AUR|util-linux-selinux}}<br />
:Modified util-linux package compiled with SELinux support enabled. It replaces the {{pkg|util-linux}} package.<br />
<br />
====SELinux userspace utilities====<br />
;{{AUR|checkpolicy}}<br />
:Tools to build SELinux policy<br />
<br />
;{{AUR|mcstrans}}<br />
:Daemon which is used by libselinux to translate MCS labels<br />
<br />
;{{AUR|libselinux}}<br />
:Library for security-aware applications. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsemanage}}<br />
:Library for policy management. Python bindings needed for ''semanage'' and ''setools'' now included.<br />
<br />
;{{AUR|libsepol}}<br />
:Library for binary policy manipulation.<br />
<br />
;{{AUR|policycoreutils}}<br />
:SELinux core utils such as newrole, setfiles, etc.<br />
<br />
;{{AUR|restorecond}}<br />
:Daemon which maintains the label of some files<br />
<br />
;{{AUR|secilc}}<br />
:Compiler for SELinux policies written in CIL (Common Intermediate Language)<br />
<br />
;{{AUR|selinux-dbus-config}}<br />
:DBus service which allows managing SELinux configuration<br />
<br />
;{{AUR|selinux-gui}}<br />
:SELinux GUI tools (system-config-selinux)<br />
<br />
;{{AUR|selinux-python}} and {{AUR|selinux-python2}}<br />
:SELinux python tools and libraries (semanage, sepolgen, sepolicy, etc.)<br />
<br />
;{{AUR|selinux-sandbox}}<br />
:Sandboxing tool for SELinux<br />
<br />
;{{AUR|semodule-utils}}<br />
:Tools to handle SELinux modules when building a policy<br />
<br />
====SELinux policy packages====<br />
<br />
;{{AUR|selinux-refpolicy-src}}<br />
:Reference policy sources<br />
<br />
;{{AUR|selinux-refpolicy-git}}<br />
:Reference policy git master (https://github.com/TresysTechnology/refpolicy) built with configuration specific for Arch Linux<br />
<br />
;{{AUR|selinux-refpolicy-arch}}<br />
:Precompiled modular Reference policy with headers and documentation but without sources. Development Arch Linux Refpolicy patches included, which fixes issues related to path labeling and systemd support. These patches are also sent to Reference Policy maintainers and their inclusion in {{AUR|selinux-refpolicy-arch}} is mainly a way to perform updates between Refpolicy releases.<br />
<br />
====Other SELinux tools====<br />
<br />
;{{AUR|setools}}<br />
:CLI and GUI tools to manage SELinux<br />
<br />
;{{AUR|selinux-alpm-hook}}<br />
:pacman hook to label files accordingly to SELinux policy when installing and updating packages<br />
<br />
=== Installation ===<br />
<br />
===Preparing the Kernel===<br />
<br />
Only ext2, ext3, ext4, JFS, XFS and BtrFS filesystems are supported to use SELinux. By default, the Arch Kernel does not have the SELinux LSM enabled. If you are using Arch Linux packaged kernel ({{pkg|linux}}), there is an AUR package which adds the configuration options for SELinux, {{aur|linux-selinux}}. Otherwise, when you are using a custom kernel, please do make sure that Xattr (Extended Attributes), {{ic|CONFIG_AUDIT}} and {{ic|CONFIG_SECURITY_SELINUX}} are enabled in your config. (Source: [[debian:SELinux/Setup#kernel|Debian Wiki]])<br />
<br />
Here is the complete list of options which need to be enabled on Linux 4.3.3 to use SELinux :<br />
{{hc|config.selinux-custom|<nowiki>CONFIG_AUDIT=y<br />
CONFIG_AUDITSYSCALL=y<br />
CONFIG_AUDIT_WATCH=y<br />
CONFIG_AUDIT_TREE=y<br />
CONFIG_NETLABEL=y<br />
CONFIG_IP_NF_SECURITY=m<br />
CONFIG_IP6_NF_SECURITY=m<br />
CONFIG_NETFILTER_XT_TARGET_AUDIT=m<br />
CONFIG_FANOTIFY_ACCESS_PERMISSIONS=y<br />
CONFIG_NFSD_V4_SECURITY_LABEL=y<br />
CONFIG_SECURITY=y<br />
CONFIG_SECURITY_NETWORK=y<br />
CONFIG_SECURITY_PATH=y<br />
CONFIG_LSM_MMAP_MIN_ADDR=65536<br />
CONFIG_SECURITY_SELINUX=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM=y<br />
CONFIG_SECURITY_SELINUX_DISABLE=y<br />
CONFIG_SECURITY_SELINUX_DEVELOP=y<br />
CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=1<br />
CONFIG_SECURITY_SELINUX_CHECKREQPROT_VALUE=1<br />
CONFIG_SECURITY_SELINUX_ENABLE_SECMARK_DEFAULT=y<br />
CONFIG_SECURITY_SELINUX_AVC_STATS=y<br />
CONFIG_DEFAULT_SECURITY_SELINUX=y</nowiki>}}<br />
<br />
{{Note|If using proprietary drivers, such as [[NVIDIA]] graphics drivers, you may need to [[NVIDIA#Custom kernel|rebuild them]].}}<br />
<br />
There are two methods to install the requisite SELinux packages.<br />
<br />
==== Via AUR ====<br />
<br />
* First, install SELinux userspace tools and libraries, in this order (because of the dependencies): {{AUR|libsepol}}, {{AUR|libselinux}}, {{AUR|secilc}}, {{AUR|checkpolicy}}, {{AUR|setools}}, {{AUR|libsemanage}}, {{AUR|semodule-utils}}, {{AUR|policycoreutils}}, {{AUR|selinux-python}} (which depends on {{AUR|python-ipy}}), {{AUR|mcstrans}} and {{AUR|restorecond}}.<br />
* Then install {{AUR|pambase-selinux}} and {{AUR|pam-selinux}} and make sure you can login again after the installation completed, because files in {{ic|/etc/pam.d/}} got removed and created when {{pkg|pambase}} got replaced with {{AUR|pambase-selinux}}.<br />
* Next you can recompile some core packages by installing: {{AUR|coreutils-selinux}}, {{AUR|findutils-selinux}}, {{AUR|iproute2-selinux}}, {{AUR|logrotate-selinux}}, {{AUR|openssh-selinux}}, {{AUR|psmisc-selinux}}, {{AUR|shadow-selinux}}, {{AUR|cronie-selinux}}<br />
* Next, backup your {{ic|/etc/sudoers}} file. Install {{AUR|sudo-selinux}} and restore your {{ic|/etc/sudoers}} (it is overridden when this package is installed as a replacement of {{pkg|sudo}}).<br />
* Next come util-linux and systemd. Because of a cyclic makedepends between these two packages which will not be fixed ({{bug|39767}}), you need to build the source package {{AUR|systemd-selinux}}, install {{AUR|libsystemd-selinux}}, build and install {{AUR|util-linux-selinux}} (with {{AUR|libutil-linux-selinux}}) and rebuild and install {{AUR|systemd-selinux}}.<br />
* Next, install {{AUR|dbus-selinux}}.<br />
* Next, install {{AUR|selinux-alpm-hook}} in order to run restorecon every time pacman installs a package.<br />
<br />
After all these steps, you can install a SELinux kernel (like {{AUR|linux-selinux}}) and a policy (like {{AUR|selinux-refpolicy-arch}} or {{AUR|selinux-refpolicy-git}}).<br />
<br />
==== Using the GitHub repository ====<br />
<br />
All packages are maintained at https://github.com/archlinuxhardened/selinux . This repository also contains a script named {{ic|build_and_install_all.sh}} which builds and installs (or updates) all packages in the needed order. Here is an example of a way this script can be used in a user shell to install all packages (with downloading the GPG keys which are used to verify the source tarballs of the package):<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux<br />
./recv_gpg_keys.sh<br />
./build_and_install_all.sh<br />
<br />
Of course, it is possible to modify the content of {{ic|build_and_install_all.sh}} before running it, for example if you already have SELinux support in your kernel.<br />
<br />
===Changing boot loader configuration===<br />
<br />
If you have installed a new kernel, make sure that you update your bootloader accordingly to boot on it. Moreover you may need to add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to the kernel command line. More precisely, if the kernel configuration does not set {{ic|CONFIG_DEFAULT_SECURITY_SELINUX}}, {{ic|<nowiki>security=selinux</nowiki>}} is needed, and if it contains {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM=y</nowiki>}} {{ic|<nowiki>CONFIG_SECURITY_SELINUX_BOOTPARAM_VALUE=0</nowiki>}}, {{ic|<nowiki>selinux=1</nowiki>}} is needed.<br />
<br />
====GRUB====<br />
<br />
Add {{ic|<nowiki>security=selinux selinux=1</nowiki>}} to {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variable in {{ic|/etc/default/grub}}<br />
Run the following command:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
====Syslinux====<br />
<br />
Change your syslinux.cfg file by adding:<br />
<br />
{{hc|/boot/syslinux/syslinux.cfg|<nowiki>LABEL arch-selinux<br />
LINUX ../vmlinuz-linux-selinux<br />
APPEND root=/dev/sda2 ro security=selinux selinux=1<br />
INITRD ../initramfs-linux-selinux.img</nowiki>}}<br />
<br />
at the end. Change "linux-selinux" to whatever kernel you are using.<br />
<br />
====systemd-boot====<br />
<br />
Create a new loader entry, for example in {{ic|/boot/loader/entries/arch-selinux.conf}}:<br />
<br />
{{hc|/boot/loader/entries/arch-selinux.conf|2=<br />
title Arch Linux SELinux<br />
linux /vmlinuz-linux-selinux<br />
initrd /initramfs-linux-selinux.img<br />
options root=/dev/sda2 ro selinux=1 security=selinux<br />
}}<br />
<br />
===Checking PAM===<br />
<br />
A correctly set-up [[PAM]] is important to get the proper security context after login. Check for the presence of the following lines in {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{bc|# pam_selinux.so close should be the first session rule<br />
session required pam_selinux.so close}}<br />
<br />
{{bc|# pam_selinux.so open should only be followed by sessions to be executed in the user context<br />
session required pam_selinux.so open}}<br />
<br />
===Installing a policy===<br />
<br />
{{Warning|The reference policy as given by [https://github.com/TresysTechnology/refpolicy/wiki Tresys] is not very good for Arch Linux, as before release 20170805 almost no file were labelled correctly. The major problems were:<br />
<br />
* {{ic|/lib}} and {{ic|/usr/lib}} were considered different (and also {{ic|/bin}}, {{ic|/sbin}}, {{ic|/usr/bin}} and {{ic|/usr/sbin}}). This introduced some instability when applying labels to the whole system, as files in these folders might be seen with 2 (or 4) different labels. <br />
* systemd was not yet supported (C. PeBenito, main developer of the refpolicy, announced its willingness to work on it in its github repository in October 2014, http://oss.tresys.com/pipermail/refpolicy/2014-October/007430.html)<br />
<br />
Since refpolicy release 20170805 these two points have been addressed, but most people submitting patches to improve the policy use an other distribution (Debian, Gentoo, RHEL, etc.). Therefore the compatibility with Arch Linux packages is not perfect (for example the policy may not support the most recent features of a program). }}<br />
<br />
Policies are the mainstay of SELinux. They are what govern its behaviour. The only policy currently available in the AUR is the Reference Policy. In order to install it, you should use the source files, which may be got from the package {{AUR|selinux-refpolicy-src}} or by downloading the latest release on https://github.com/TresysTechnology/refpolicy/wiki/DownloadRelease#current-release. When using the AUR package, navigate to {{ic|/etc/selinux/refpolicy/src/policy}} and run the following commands:<br />
<br />
{{bc|# make bare<br />
# make conf<br />
# make install}}<br />
<br />
to install the reference policy as it is. Those who know how to write SELinux policies can tweak them to their heart's content before running the commands written above. The command takes a while to do its job and taxes one core of your system completely, so do not worry. Just sit back and let the command run for as long as it takes.<br />
<br />
To load the reference policy run:<br />
{{bc|# make load}}<br />
<br />
Then, make the file {{ic|/etc/selinux/config}} with the following contents (Only works if you used the defaults as mentioned above. If you decided to change the name of the policy, you need to tweak the file):<br />
<br />
{{hc|/etc/selinux/config|<nowiki># This file controls the state of SELinux on the system.<br />
# SELINUX= can take one of these three values:<br />
# enforcing - SELinux security policy is enforced.<br />
# Set this value once you know for sure that SELinux is configured the way you like it and that your system is ready for deployment<br />
# permissive - SELinux prints warnings instead of enforcing.<br />
# Use this to customise your SELinux policies and booleans prior to deployment. Recommended during policy development.<br />
# disabled - No SELinux policy is loaded.<br />
# This is not a recommended setting, for it may cause problems with file labelling<br />
SELINUX=permissive<br />
# SELINUXTYPE= takes the name of SELinux policy to<br />
# be used. Current options are:<br />
# refpolicy (vanilla reference policy)<br />
# <custompolicy> - Substitute <custompolicy> with the name of any custom policy you choose to load<br />
SELINUXTYPE=refpolicy</nowiki>}}<br />
<br />
Now, you may reboot. After rebooting, run:<br />
<br />
# restorecon -r /<br />
<br />
to label your filesystem.<br />
<br />
Now, make a file {{ic|requiredmod.te}} with the contents:<br />
<br />
{{hc|requiredmod.te|<nowiki>module requiredmod 1.0;<br />
<br />
require {<br />
type devpts_t;<br />
type kernel_t;<br />
type device_t;<br />
type var_run_t;<br />
type udev_t;<br />
type hugetlbfs_t;<br />
type udev_tbl_t;<br />
type tmpfs_t;<br />
class sock_file write;<br />
class unix_stream_socket { read write ioctl };<br />
class capability2 block_suspend;<br />
class dir { write add_name };<br />
class filesystem associate;<br />
}<br />
<br />
#============= devpts_t ==============<br />
allow devpts_t device_t:filesystem associate;<br />
<br />
#============= hugetlbfs_t ==============<br />
allow hugetlbfs_t device_t:filesystem associate;<br />
<br />
#============= kernel_t ==============<br />
allow kernel_t self:capability2 block_suspend;<br />
<br />
#============= tmpfs_t ==============<br />
allow tmpfs_t device_t:filesystem associate;<br />
<br />
#============= udev_t ==============<br />
allow udev_t kernel_t:unix_stream_socket { read write ioctl };<br />
allow udev_t udev_tbl_t:dir { write add_name };<br />
allow udev_t var_run_t:sock_file write;</nowiki>}}<br />
<br />
and run the following commands:<br />
<br />
{{bc|<nowiki># checkmodule -m -o requiredmod.mod requiredmod.te<br />
# semodule_package -o requiredmod.pp -m requiredmod.mod<br />
# semodule -i requiredmod.pp</nowiki>}}<br />
<br />
This is required to remove a few messages from {{ic|/var/log/audit/audit.log}} which are a nuisance to deal with in the reference policy. This is an ugly hack and it should be made very clear that the policy so installed simply patches the reference policy in order to hide the effects of incorrect labelling.<br />
<br />
===Testing in a Vagrant virtual machine===<br />
<br />
It is possible to use [[Vagrant]] to provision a virtual Arch Linux machine with SELinux configured. This is a convenient way to test an Arch Linux system running SELinux without modifying a current system. Here are commands which can be used to achieve this:<br />
<br />
git clone https://github.com/archlinuxhardened/selinux<br />
cd selinux/_vagrant<br />
vagrant up<br />
vagrant ssh<br />
<br />
==Post-installation steps==<br />
<br />
You can check that SELinux is working with {{ic|sestatus}}. You should get something like:<br />
<br />
{{bc|<nowiki>SELinux status: enabled<br />
SELinuxfs mount: /sys/fs/selinux<br />
SELinux root directory: /etc/selinux<br />
Loaded policy name: refpolicy<br />
Current mode: permissive<br />
Mode from config file: permissive<br />
Policy MLS status: disabled<br />
Policy deny_unknown status: allowed<br />
Max kernel policy version: 28</nowiki>}}<br />
<br />
To maintain correct context, you can use ''restorecond'':<br />
<br />
# systemctl enable restorecond<br />
<br />
To switch to enforcing mode without rebooting, you can use:<br />
<br />
# echo 1 > /sys/fs/selinux/enforce<br />
<br />
===Swapfiles===<br />
<br />
If you have a swap file instead of a swap partition, issue the following commands in order to set the appropriate security context:<br />
<br />
{{bc|# semanage fcontext -a -t swapfile_t "/path/to/swapfile"<br />
# restorecon /path/to/swapfile}}<br />
<br />
==Working with SELinux==<br />
<br />
SELinux defines security using a different mechanism than traditional Unix access controls. The best way to understand it is by example. For example, the SELinux security context of the apache homepage looks like the following:<br />
<br />
$ls -lZ /var/www/html/index.html<br />
-rw-r--r-- username username system_u:object_r:httpd_sys_content_t /var/www/html/index.html<br />
<br />
The first three and the last columns should be familiar to any (Arch) Linux user. The fourth column is new and has the format:<br />
<br />
user:role:type[:level]<br />
<br />
To explain:<br />
#'''User:''' The SELinux user identity. This can be associated to one or more roles that the SELinux user is allowed to use.<br />
#'''Role:''' The SELinux role. This can be associated to one or more types the SELinux user is allowed to access.<br />
#'''Type:''' When a type is associated with a process, it defines what processes (or domains) the SELinux user (the subject) can access. When a type is associated with an object, it defines what access permissions the SELinux user has to that object.<br />
#'''Level:''' This optional field can also be know as a range and is only present if the policy supports MCS or MLS.<br />
<br />
This is important in case you wish to understand how to build your own policies, for these are the basic building blocks of SELinux. However, for most purposes, there is no need to, for the reference policy is sufficiently mature. However, if you are a power user or someone with very specific needs, then it might be ideal for you to learn how to make your own SELinux policies.<br />
<br />
[http://www.fosteringlinux.com/tag/selinux/ This] is a great series of articles for someone seeking to understand how to work with SELinux.<br />
<br />
==Troubleshooting==<br />
<br />
The place to look for SELinux errors is the systemd journal. In order to see SELinux messages related to the label {{ic|system_u:system_r:policykit_t:s0}} (for example), you would need to run:<br />
<br />
# journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0<br />
<br />
===Useful tools===<br />
<br />
There are some tools/commands that can greatly help with SELinux. <br />
<br />
;restorecon: Restores the context of a file/directory (or recursively with {{ic|-R}}) based on any policy rules <br />
;chcon: Change the context on a specific file<br />
<br />
===Reporting issues===<br />
<br />
Please report issues on GitHub: https://github.com/archlinuxhardened/selinux/issues<br />
<br />
==See also==<br />
* [[wikipedia:Security-Enhanced_Linux|Security Enhanced Linux]]<br />
* [https://wiki.gentoo.org/wiki/SELinux Gentoo SELinux Handbook]<br />
* [https://fedoraproject.org/wiki/SELinux Fedora Project's SELinux Wiki]<br />
* [https://www.nsa.gov/what-we-do/research/selinux/ NSA's Official SELinux Homepage]<br />
* [http://userspace.selinuxproject.org/ SELinux Userspace Homepage]<br />
** [http://oss.tresys.com/projects/refpolicy Reference Policy Homepage]<br />
** [http://oss.tresys.com/projects/setools SETools Homepage]<br />
* [https://web.archive.org/web/20140816115906/http://jamesthebard.net/archlinux-selinux-and-you-a-trip-down-the-rabbit-hole/ ArchLinux, SELinux and You (archived)]</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=523645Dnscrypt-proxy2018-05-27T22:47:55Z<p>Wincraft71: /* Startup */ remove exclamation point</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
The service can be started in two (mutually exclusive) ways (i.e. only one of the two may be enabled): With the {{ic|.service}} file (default) or through {{ic|.socket}} activation aka. unix socket activation (which then starts the service on access of said socket).<br />
<br />
{{Note|For using the service directly, the {{ic|listen_addresses }} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} has to be configured (e.g. {{ic|1=listen_addresses = [ "127.0.0.1:53" ] }}). However, when using unix socket activation the option has to be the empty set (i.e. {{ic|1=listen_addresses = [ ] }}), as systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
As described in [[#Startup]], {{ic|listen_addresses}} in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} should be empty and only {{ic|dnscrypt-proxy.socket}} needs to be enabled and started.<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=523644Dnscrypt-proxy2018-05-27T22:39:20Z<p>Wincraft71: /* Unbound */ clarification about listen_addresses and socket startup when using Unbound</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
The service can be started in two (mutually exclusive) ways (i.e. only one of the two may be enabled!): With the {{ic|.service}} file (default) or through {{ic|.socket}} activation aka. unix socket activation (which then starts the service on access of said socket).<br />
<br />
{{Note|For using the service directly, the {{ic|listen_addresses }} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} has to be configured (e.g. {{ic|1=listen_addresses = [ "127.0.0.1:53" ] }}). However, when using unix socket activation the option has to be the empty set (i.e. {{ic|1=listen_addresses = [ ] }}), as systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
As described in [[#Startup]], {{ic|listen_addresses}} in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} should be empty and only {{ic|dnscrypt-proxy.socket}} needs to be enabled and started.<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523642Talk:Dnscrypt-proxy2018-05-27T22:21:32Z<p>Wincraft71: /* "CapabilityBoundingSet" in /* Sandboxing */ */ re</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)<br />
<br />
:That has nothing with the "newest update" (whatever that means today), {{ic|1=AmbientCapabilities=CAP_NET_BIND_SERVICE}} appeared in [https://git.archlinux.org/svntogit/community.git/commit/trunk?h=packages/dnscrypt-proxy&id=89137afa76eadf133f217b029fb6a43f3707983f]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 21:47, 27 May 2018 (UTC)<br />
<br />
::Well the only way I can get it to work when starting directly or from the socket {{ic|dnscrypt-proxy.socket}} is by adding {{ic|CAP_NET_BIND_SERVICE}} to the end of {{ic|1=CapabilityBoundingSet=}}. I meant "the update from 9 days ago". It has to do with an update that happened recently is what I mean. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:21, 27 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=523629Dnscrypt-proxy2018-05-27T21:07:20Z<p>Wincraft71: /* Unbound */ warning that after the newest update, if using Unbound the dnscrypt-proxy.socket must be started first</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
=== Startup ===<br />
The service can be started in two (mutually exclusive) ways (i.e. only one of the two may be enabled!): With the {{ic|.service}} file (default) or through {{ic|.socket}} activation aka. unix socket activation (which then starts the service on access of said socket).<br />
<br />
{{Note|For using the service directly, the {{ic|listen_addresses }} option in {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} has to be configured (e.g. {{ic|1=listen_addresses = [ "127.0.0.1:53" ] }}). However, when using unix socket activation the option has to be the empty set (i.e. {{ic|1=listen_addresses = [ ] }}), as systemd is taking care of the socket configuration.}}<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|53000}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:53000<br />
ListenDatagram=127.0.0.1:53000<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|53000}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
{{Warning|{{ic|dnscrypt-proxy.socket}} should be started first before starting {{ic|dnscrypt-proxy.service}} or a {{ic|Socket service dnscrypt-proxy.service already active, refusing.}} error will be caused.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#53000<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 53000<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|53000}} for the original socket and {{ic|53001}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@53000<br />
forward-addr: 127.0.0.1@53001<br />
}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (53000, 53001, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=523628Talk:Dnscrypt-proxy2018-05-27T21:01:16Z<p>Wincraft71: "CapabilityBoundingSet" no longer works</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)<br />
<br />
== "CapabilityBoundingSet" in /* Sandboxing */ ==<br />
<br />
With the newest update using the "CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID" option causes this error:<br />
<br />
{{bc|1=<br />
archlinux systemd[1]: Started DNSCrypt-proxy client.<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed to apply ambient capabilities (before UID change): Operation not permitted<br />
<br />
archlinux systemd[1863]: dnscrypt-proxy.service: Failed at step CAPABILITIES spawning /usr/bin/dnscrypt-proxy: Operation not permitted<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Main process exited, code=exited, status=218/CAPABILITIES<br />
<br />
archlinux systemd[1]: dnscrypt-proxy.service: Failed with result 'exit-code'.}}<br />
-- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 21:01, 27 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521316Dnscrypt-proxy2018-05-16T05:01:15Z<p>Wincraft71: /* Modify resolv.conf */ options</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with the address for ''localhost'' and options [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521310Dnscrypt-proxy2018-05-15T22:37:27Z<p>Wincraft71: /* Modify resolv.conf */ follow the resolv.conf instructions from upstream</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'' [https://github.com/jedisct1/dnscrypt-proxy/wiki/Installation-linux#step-4-change-the-system-dns-settings]:<br />
<br />
nameserver 127.0.0.1<br />
options edns0 single-request-reopen<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521309Dnscrypt-proxy2018-05-15T22:23:44Z<p>Wincraft71: /* Modify resolv.conf */ selecting a resolver isn't necessary</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
Modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=521308Talk:Dnscrypt-proxy2018-05-15T22:15:55Z<p>Wincraft71: /* I created new article about new version of Dnscrypt 2.x */ signature</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:15, 15 May 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dnscrypt-proxy&diff=521307Talk:Dnscrypt-proxy2018-05-15T22:15:41Z<p>Wincraft71: /* I created new article about new version of Dnscrypt 2.x */ re</p>
<hr />
<div>== Revise or remove? ==<br />
<br />
No matter how well it's written, this basically does what the instanced services method does, but users make the individual socket ''and'' service files by hand. Even if individual resolvers need different configurations, that could be achieved by overriding the instanced services. Some of this I would recycle into the instanced services section (Tip, Lastly). [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 16:04, 25 January 2017 (UTC)<br />
<br />
== Draft ==<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use additional dnscrypt providers, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.service}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.service}} and specify a different resolver using the {{ic|-R}} flag with a short name from [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]].<br />
{{Tip|Any other options you wish to use with this resolver should be specified on this command line; the use of a config file with command line options is unsupported.}}<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/bin/dnscrypt-proxy -R ''short-name.here''<br />
<br />
Then copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy-''short-name.here''.socket}} and, [[#Change_port|specify another port]].<br />
<br />
{{Comment|This is a cheapened version of the multiple instances method; considering to delete the above and move the below under "Create instanced systemd service". [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 02:46, 26 March 2017 (UTC)}}<br />
<br />
Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{Comment|command-line options override the configuration file (when run as a systemd service at least) [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:29, 24 January 2017 (UTC)}}<br />
:{{Comment|If this is the case, it is a bug - the man page says {{ic|OPTIONS (ignored when a configuration file is provided)}}. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:18, 24 January 2017 (UTC)}}<br />
::{{Comment|That's bad news; this is definetly the case. So users who want redundant / instanced services need to specify all their options on the command line and that's fine with me. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 13:34, 24 January 2017 (UTC)}}<br />
:::{{Comment|1=Or simply have multiple config files and an instantiated service similar to [https://wiki.archlinux.org/index.php?title=Talk:DNSCrypt&diff=next&oldid=466525 this one] to select the right config. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:45, 24 January 2017 (UTC)}}<br />
::::{{Comment|Sounds good; putting this back into the proposal with some adjustments. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 14:15, 24 January 2017 (UTC)}}<br />
:::::{{Comment|The more I boil down the method above, the more it seems like it would be more sensible to remove it from the page entirely and just recommend the instances method. [[User:Quequotion|quequotion]] ([[User talk:Quequotion|talk]]) 15:07, 24 January 2017 (UTC)}}<br />
<br />
== Backup DNSCrypt resolver - especially with the new configuration file ==<br />
<br />
Usually when setting a dns resolver you will always have the option to set a second/backup dns resolver (android,windows,networkmanager,router, what ever).<br />
<br />
I think the wiki should cover a way on how to achieve the same with dnscrypt. Especially as some if the dnscrypt resolvers like to go offline every now and then (looking at you dnscrypt.eu-nl).<br />
<br />
I have a running setup (which caused me some struggles to achieve that setup) but I have no idea how to replicate it. Espcially with the new configuration file which seems like it will only cover one dnscrypt instance?<br />
<br />
Right now I have 2x dnscrypt running in systemd and the resolver.conf will choose which ever is online/working.<br />
<br />
{{unsigned|11:56, 30 December 2016|Utini2000}}<br />
<br />
:It already describes that: [[DNSCrypt#Redundant_DNSCrypt_providers]] -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:02, 30 December 2016 (UTC)<br />
<br />
::But this is with the old configuration file, not the new one? Also it seems like this only covers unbound but what about e.g. dnsmasq? {{unsigned|16:21, 30 December 2016|Utini2000}}<br />
<br />
== DNSCrypt download page and github project seems to be down ==<br />
<br />
All I could find was this Reddit thread [https://twitter.com/jedisct1/status/928942292202860544] and a [https://github.com/DNSCrypt/dnscrypt-proxy new Github project here] [https://github.com/dyne/dnscrypt-proxy and here] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
:The "dyne" link seems to have an updated resolvers.csv [https://github.com/dyne/dnscrypt-proxy] -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 03:23, 8 January 2018 (UTC)<br />
<br />
== I created new article about new version of Dnscrypt 2.x ==<br />
<br />
I write about the flag on my article - [[Dnscrypt-proxy2]]. <br />
{{Note|This article or section is a candidate for merging with DNSCrypt.}}<br />
We have to have only one article about Dnscrypt.<br />
<br />
[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 10:33, 14 May 2018 (UTC)<br />
<br />
:What is unclear? --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 11:05, 14 May 2018 (UTC)<br />
::I'm sorry, i explained my intention to merge these articles. I invited people to read my article to revist it, if is necessary, before completing the merging. "Users are encouraged to participate in merger discussions or simply complete the merge". Can i do the merging?<br />
::[[User:Clorofilla|Clorofilla]] ([[User talk:Clorofilla|talk]]) 11:51, 14 May 2018 (UTC)<br />
<br />
:::Yes you can update [[DNSCrypt]] but be sure to do it gradually with edit summaries explaining your changes. --[[User:Larivact|Larivact]] ([[User talk:Larivact|talk]]) 12:19, 14 May 2018 (UTC)<br />
<br />
:::I've updated [[Dnscrypt]] enough to where your second article is unnecessary. I don't understand why your configuration instructions say to edit in static servers, however. The user would be better off leaving the default public resolvers under {{ic|[sources]}}, and choosing their requirements with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options. Or use {{ic|server_names}} to choose a server from the {{ic|[sources]}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521306Dnscrypt-proxy2018-05-15T22:04:02Z<p>Wincraft71: /* Disable any services bound to port 53 */ tip that unbound runs on port 53</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
{{Tip|If using [[#Unbound]] as your local DNS cache this section can be ignored, as ''unbound'' runs on port 53 by default.}}<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
After selecting a dnscrypt resolver, modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521305Dnscrypt-proxy2018-05-15T21:54:41Z<p>Wincraft71: /* Select resolver */ links to list of public resolvers, server requirements, multiple tip stack format</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|<br />
* You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}.<br />
* Users should look at the description for servers on the public resolvers list and take note of which validate [[DNSSEC]], do not log, and are uncensored. These requirements can be configured globally with the {{ic|require_dnssec}}, {{ic|require_nolog}}, {{ic|require_nofilter}} options.}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
After selecting a dnscrypt resolver, modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521304Dnscrypt-proxy2018-05-15T21:51:44Z<p>Wincraft71: Undo revision 521303 by Wincraft71 (talk) nowiki tags are unnecessary</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
After selecting a dnscrypt resolver, modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521303Dnscrypt-proxy2018-05-15T21:49:42Z<p>Wincraft71: /* Select resolver */ nowiki tags</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|<nowiki>[sources]</nowiki>}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
After selecting a dnscrypt resolver, modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521302Dnscrypt-proxy2018-05-15T21:48:49Z<p>Wincraft71: /* Select resolver */ note that select resolver is optional</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
{{Note|By leaving {{ic|server_names}} commented out in the configuration file {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}}, ''dnscrypt-proxy'' will choose the fastest server from the sources already configured under {{ic|[sources]}} [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration#an-example-static-server-entry]. The lists will be downloaded, verified, and automatically updated. [https://github.com/jedisct1/dnscrypt-proxy/wiki/Configuration-Sources#what-is-the-point-of-these-lists]. Thus, configuring a specific set of servers is optional.}}<br />
<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
After selecting a dnscrypt resolver, modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dnscrypt-proxy&diff=521300Dnscrypt-proxy2018-05-15T21:13:49Z<p>Wincraft71: /* Select resolver */ links to public resolvers list</p>
<hr />
<div>[[Category:Domain Name System]]<br />
[[Category:Encryption]]<br />
[[es:DNSCrypt]]<br />
[[ja:DNSCrypt]]<br />
[[pt:DNSCrypt]]<br />
[[zh-hans:DNSCrypt]]<br />
<br />
[http://dnscrypt.info/ DNSCrypt] encrypts and authenticates DNS traffic between user and DNS resolver. While IP traffic itself is unchanged, it prevents local spoofing of DNS queries, ensuring DNS responses are sent by the server of choice. [https://www.reddit.com/r/sysadmin/comments/2hn435/dnssec_vs_dnscrypt/ckuhcbu]<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|dnscrypt-proxy}} package.<br />
<br />
== Configuration ==<br />
<br />
{{Note|Systemd overrides the {{ic|listen_addresses}} option with a [[#Change_port|socket file]].}}<br />
<br />
To configure ''dnscrypt-proxy'', perform the following steps:<br />
<br />
=== Select resolver ===<br />
Edit {{ic|/etc/dnscrypt-proxy/dnscrypt-proxy.toml}} and uncomment the {{ic|server_names}} variable, selecting one or more of the servers. For example, to use Cloudflare's servers:<br />
<br />
server_names = ['cloudflare', 'cloudflare-ipv6']<br />
<br />
{{Tip|You can find the full list of resolvers on the [https://download.dnscrypt.info/resolvers-list/v2/public-resolvers.md upstream page], [https://raw.githubusercontent.com/DNSCrypt/dnscrypt-resolvers/master/v2/public-resolvers.md Github], or {{ic|/var/cache/dnscrypt-proxy/public-resolvers.md}}}}<br />
<br />
=== Disable any services bound to port 53 ===<br />
To see if any programs are using port 53, run<br />
<br />
$ ss -lp 'sport = :domain'<br />
<br />
If the output contains more than the first line of column names, you need to disable whatever service is using port 53. One common culprit is {{ic|systemd-resolved.service}}, but other network managers may have analogous components. You are ready to proceed once the above command outputs nothing more than the following line:<br />
<br />
Netid State Recv-Q Send-Q Local Address:Port Peer Address:Port<br />
<br />
=== Modify resolv.conf ===<br />
<br />
After selecting a dnscrypt resolver, modify the [[resolv.conf]] file and replace the current set of resolver addresses with address for ''localhost'':<br />
<br />
nameserver 127.0.0.1<br />
<br />
Other programs may overwrite this setting; see [[resolv.conf#Preserve DNS settings]] for details.<br />
<br />
=== Start systemd service ===<br />
<br />
Finally, [[Enable|start and enable]] the {{ic|dnscrypt-proxy.service}}.<br />
<br />
== Tips and tricks ==<br />
<br />
=== Local DNS cache configuration ===<br />
<br />
{{Note|''dnscrypt'' can cache entries without relying on another program. This feature is enabled by default with the line {{ic|1=cache = true}} in your dnscrypt configuration file}}<br />
<br />
It is recommended to run DNSCrypt as a forwarder for a local DNS cache if not using ''dnscrypt's'' cache feature; otherwise, every single query will make a round-trip to the upstream resolver. Any local DNS caching program should work. In addition to setting up ''dnscrypt-proxy'', you must setup your local DNS cache program. <br />
<br />
==== Change port ====<br />
<br />
{{Note|Changing the IP address or port in {{ic|/etc/dnscrypt-proxy.conf}} [https://web.archive.org/web/20171215112100/https://github.com/jedisct1/dnscrypt-proxy/issues/528 does not work] when using the provided systemd unit and must be changed in the provided systemd socket as follows.}}<br />
<br />
In order to forward to a local DNS cache, ''dnscrypt-proxy'' should listen on a port different from the default {{ic|53}}, since the DNS cache itself needs to listen on {{ic|53}} and query ''dnscrypt-proxy'' on a different port. Port number {{ic|5353}} is used as an example in this section. In this example, the port number is larger than 1024 so ''dnscrypt-proxy'' is not required to be run by root. [[Edit]] {{ic|dnscrypt-proxy.socket}} with the following contents:<br />
<br />
[Socket]<br />
ListenStream=<br />
ListenDatagram=<br />
ListenStream=127.0.0.1:5353<br />
ListenDatagram=127.0.0.1:5353<br />
<br />
{{Note|UDP Port {{ic|5353}} is used by [[Avahi#Firewall|Avahi]] (if installed and running) and can cause warnings in the journal and [[Avahi]]'s mDNS unreliable.}}<br />
<br />
==== Example local DNS cache configurations====<br />
<br />
The following configurations should work with ''dnscrypt-proxy'' and assume that it is listening on port {{ic|5353}}.<br />
<br />
===== Unbound =====<br />
<br />
Configure [[Unbound]] to your liking (in particular, see [[Unbound#Local DNS server]]) and add the following lines to the end of the {{ic|server}} section in {{ic|/etc/unbound/unbound.conf}}:<br />
<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
<br />
{{Tip|If you are setting up a server, add {{ic|interface: 0.0.0.0@53}} and {{ic|access-control: ''your-network''/''subnet-mask'' allow}} inside the {{ic|server:}} section so that the other computers can connect to the server. A client must be configured with {{ic|nameserver ''address-of-your-server''}} in {{ic|/etc/resolv.conf}}.}}<br />
<br />
[[Restart]] {{ic|unbound.service}} to apply the changes.<br />
<br />
===== dnsmasq =====<br />
<br />
Configure dnsmasq as a [[dnsmasq#DNS cache setup|local DNS cache]]. The basic configuration to work with DNSCrypt:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
no-resolv<br />
server=127.0.0.1#5353<br />
listen-address=127.0.0.1<br />
}}<br />
<br />
If you configured DNSCrypt to use a resolver with enabled DNSSEC validation, make sure to enable it also in dnsmasq:<br />
<br />
{{hc|/etc/dnsmasq.conf|2=<br />
proxy-dnssec<br />
}}<br />
<br />
Restart {{ic|dnsmasq.service}} to apply the changes.<br />
<br />
===== pdnsd =====<br />
<br />
Install [[pdnsd]]. A basic configuration to work with DNSCrypt is:<br />
<br />
{{hc|/etc/pdnsd.conf|2=<br />
global {<br />
perm_cache = 1024;<br />
cache_dir = "/var/cache/pdnsd";<br />
run_as = "pdnsd";<br />
server_ip = 127.0.0.1;<br />
status_ctl = on;<br />
query_method = udp_tcp;<br />
min_ttl = 15m; # Retain cached entries at least 15 minutes.<br />
max_ttl = 1w; # One week.<br />
timeout = 10; # Global timeout option (10 seconds).<br />
neg_domain_pol = on;<br />
udpbufsize = 1024; # Upper limit on the size of UDP messages.<br />
}<br />
<br />
server {<br />
label = "dnscrypt-proxy";<br />
ip = 127.0.0.1;<br />
port = 5353;<br />
timeout = 4;<br />
proxy_only = on;<br />
}<br />
<br />
source {<br />
owner = localhost;<br />
file = "/etc/hosts";<br />
}<br />
}}<br />
<br />
Restart {{ic|pdnsd.service}} to apply the changes.<br />
<br />
=== Sandboxing ===<br />
<br />
[[Edit]] {{ic|dnscrypt-proxy.service}} to include the following lines:<br />
<br />
[Service]<br />
CapabilityBoundingSet=CAP_IPC_LOCK CAP_SETGID CAP_SETUID<br />
ProtectSystem=strict<br />
ProtectHome=true<br />
ProtectKernelTunables=true<br />
ProtectKernelModules=true<br />
ProtectControlGroups=true<br />
PrivateTmp=true<br />
PrivateDevices=true<br />
MemoryDenyWriteExecute=true<br />
NoNewPrivileges=true<br />
RestrictRealtime=true<br />
RestrictAddressFamilies=AF_INET AF_INET6<br />
SystemCallArchitectures=native<br />
SystemCallFilter=~@clock @cpu-emulation @debug @keyring @ipc @module @mount @obsolete @raw-io<br />
<br />
See {{man|5|systemd.exec}} and [[Systemd#Sandboxing application environments]] for more information. Additionally see [https://github.com/jedisct1/dnscrypt-proxy/pull/601#issuecomment-284171727 upstream comments]{{Dead link|2018|01|08}}.<br />
<br />
=== Enable EDNS0 ===<br />
<br />
[[wikipedia:Extension_mechanisms_for_DNS|Extension Mechanisms for DNS]] that, among other things, allows a client to specify how large a reply over UDP can be.<br />
<br />
Add the following line to your {{ic|/etc/resolv.conf}}:<br />
options edns0<br />
<br />
You may also wish to append the following to {{ic|/etc/dnscrypt-proxy.conf}}:<br />
EDNSPayloadSize ''<bytes>''<br />
<br />
Where ''<bytes>'' is a number, the default size being '''1252''', with values up to '''4096''' bytes being purportedly safe. A value below or equal to '''512''' bytes will disable this mechanism, unless a client sends a packet with an OPT section providing a payload size.<br />
<br />
==== Test EDNS0 ====<br />
<br />
Make use of the [https://www.dns-oarc.net/oarc/services/replysizetest DNS Reply Size Test Server], use the ''drill'' command line tool to issue a TXT query for the name ''rs.dns-oarc.net'':<br />
$ drill rs.dns-oarc.net TXT<br />
<br />
With '''EDNS0''' supported, the "answer section" of the output should look similar to this:<br />
rst.x3827.rs.dns-oarc.net.<br />
rst.x4049.x3827.rs.dns-oarc.net.<br />
rst.x4055.x4049.x3827.rs.dns-oarc.net.<br />
"2a00:d880:3:1::a6c1:2e89 DNS reply size limit is at least 4055 bytes"<br />
"2a00:d880:3:1::a6c1:2e89 sent EDNS buffer size 4096"<br />
<br />
=== Redundant DNSCrypt providers ===<br />
<br />
To use several different dnscrypt providers, you may simply copy the original {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}. Then in your new copy of the service change the command line parameters, either pointing to a new configuration file or naming a different resolver directly. From there change the port in the new copy of the socket. Lastly, update your local DNS cache program to point to new service's port. For example, with [[unbound]] the configuration file would look like if using ports {{ic|5353}} for the original socket and {{ic|5354}} for the new socket.<br />
<br />
{{hc|/etc/unbound/unbound.conf|<br />
do-not-query-localhost: no<br />
forward-zone:<br />
name: "."<br />
forward-addr: 127.0.0.1@5353<br />
forward-addr: 127.0.0.1@5354}}<br />
<br />
==== Create instanced systemd service ====<br />
<br />
An alternative option to copying the systemd service is to used an instanced service.<br />
<br />
===== Create systemd file =====<br />
<br />
First, create {{ic|/etc/systemd/system/dnscrypt-proxy@.service}} containing:<br />
<br />
[Unit]<br />
Description=DNSCrypt client proxy<br />
Documentation=man:dnscrypt-proxy(8)<br />
Requires=dnscrypt-proxy@%i.socket<br />
<br />
[Service]<br />
Type=notify<br />
NonBlocking=true<br />
ExecStart=/usr/bin/dnscrypt-proxy \<br />
--resolver-name=%i<br />
Restart=always<br />
<br />
This specifies an instanced systemd service that starts a dnscrypt-proxy using the service name specified after the @ symbol of a corresponding .socket file.<br />
<br />
===== Add dnscrypt-sockets =====<br />
<br />
To create multiple dnscrypt-proxy sockets, copy {{ic|/usr/lib/systemd/system/dnscrypt-proxy.socket}} to a new file, {{ic|/etc/systemd/system/dnscrypt-proxy@''short-name.here''.socket}}, replacing the socket instance name with one of the short names listed in [[#Select_resolver|{{ic|dnscrypt-resolvers.csv}}]] and [[#Change_port|change the port]]. Use a different port for each instance (5353, 5354, and so forth).<br />
<br />
===== Apply new systemd configuration =====<br />
<br />
Now we need to reload the systemd configuration.<br />
<br />
# systemctl daemon-reload<br />
<br />
Since we are replacing the default service with a different name, we need to explicitly [[stop]] and [[disable]] {{ic|dnscrypt-proxy.service}} and {{ic|dnscrypt-proxy.socket}}.<br />
<br />
Now [[start/enable]] the new service(s), e.g., {{ic|dnscrypt-proxy@dnscrypt.eu-nl}}, etc.<br />
<br />
Finally [[restart]] {{ic|unbound.service}}.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Pam_oath&diff=519477Pam oath2018-04-30T20:19:56Z<p>Wincraft71: /* Logging with an oath pass */ spelling and grammar</p>
<hr />
<div>{{DISPLAYTITLE:pam_oath}}<br />
[[Category:Secure Shell]]<br />
[[ja:Pam oath]]<br />
The [http://www.nongnu.org/oath-toolkit/index.html OATH Toolkit] provides a two-step authentication procedure using one-time passcodes (OTP). It complies to two OTP method RFC standards ([[w:HMAC-based_One-time_Password_Algorithm|HOTP]], [[w:Time-based_One-time_Password_Algorithm|TOTP]]). The OTP generator applications are available for iOS, Android, Blackberry and other devices. Similar to [[Google Authenticator]] the authentication mechanism integrates into the Linux [[PAM]] system. This guide shows the installation and configuration of this mechanism.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|oath-toolkit}} package.<br />
<br />
== Setting up the oath ==<br />
<br />
The oath seed is an hexadecimal number that should be unique per user. To generate a new seed for a user, you could use the following command line:<br />
<br />
$ head -10 /dev/urandom | sha512sum | cut -b 1-30<br />
1ab4321412aebcw<br />
<br />
Note the above output seed is used as example seed in this article and '''must not''' be used. There needs to be one oath per user and link to it in a configuration file {{ic|/etc/users.oath}}. While being root create the file and insert the user seed:<br />
<br />
{{hc|/etc/users.oath|# Option User Prefix Seed<br />
HOTP/T30/6 ''user'' - ''1ab4321412aebcw''}}<br />
<br />
Make sure that the file can only be accessed by root:<br />
<br />
# chmod 600 /etc/users.oath<br />
# chown root /etc/users.oath<br />
<br />
== Setting up the PAM ==<br />
<br />
To enable oath for a specific service only, like ssh, you can edit the file /etc/pam.d/sshd and add at the beginning of the file the following line :<br />
<br />
auth sufficient pam_oath.so usersfile=/etc/users.oath window=30 digits=6<br />
<br />
This will allow authentication if you just enter the right oath code. You can make it a requirement and let the rest of the pam stack be processed if you use the following line instead :<br />
<br />
auth required pam_oath.so usersfile=/etc/users.oath window=30 digits=6<br />
<br />
== Logging with an oath pass ==<br />
<br />
Run the following command if you are logging in and need the current oath pass :<br />
<br />
oathtool -v -d6 ''1ab4321412aebcw''<br />
<br />
Of course replace ''1ab4321412aebcw'' by the seed corresponding to your user. It will display something like that :<br />
<br />
Hex secret: 1ab4321412aebc<br />
Base32 secret: DK2DEFASV26A====<br />
Digits: 6<br />
Window size: 0<br />
Start counter: 0x0 (0)<br />
<br />
820170<br />
<br />
The last number is actually the code you can use to log in right now, but more interestingly the Base32 secret, is actually what we need to generate a qr code for this user. To do so install the package {{Pkg|qrencode}} to run the following command :<br />
<br />
qrencode -o ''user''.png 'otpauth://totp/''user''@''machine''?secret=''DK2DEFASV26A===='''<br />
<br />
Of course change ''user'', ''machine'' and ''DK2DEFASV26A===='' accordingly. Once done, you can visualize your qrcode with your preferred image visualizer application and use that to configure your phone. It is pretty straight forward to use FreeOTP to then take a screenshot of that ''.png'' and get it to display OTP pass when needed.<br />
<br />
{{Note|The secret key of your users is the most important information in this system. Once you setup a phone to provide OTP, it does have that key. The qr code in that ''.png'' file does have that key. You need to take extra care of this file. They should only be stored on encrypted medium (Your phone need to be using encryption for any sane level of security). If not even confined in a sandbox like Samsung Knox to prevent third party application to potentially access them.}}<br />
<br />
== See also ==<br />
<br />
* [http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml Two-factor time based (TOTP) SSH authentication with pam_oath and Google Authenticator]<br />
* [http://www.nongnu.org/oath-toolkit/pam_oath.html pam_oath man page]</div>Wincraft71https://wiki.archlinux.org/index.php?title=Pam_oath&diff=518936Pam oath2018-04-28T05:52:26Z<p>Wincraft71: /* Setting up the PAM */ misspelled word</p>
<hr />
<div>{{DISPLAYTITLE:pam_oath}}<br />
[[Category:Secure Shell]]<br />
[[ja:Pam oath]]<br />
The [http://www.nongnu.org/oath-toolkit/index.html OATH Toolkit] provides a two-step authentication procedure using one-time passcodes (OTP). It complies to two OTP method RFC standards ([[w:HMAC-based_One-time_Password_Algorithm|HOTP]], [[w:Time-based_One-time_Password_Algorithm|TOTP]]). The OTP generator applications are available for iOS, Android, Blackberry and other devices. Similar to [[Google Authenticator]] the authentication mechanism integrates into the Linux [[PAM]] system. This guide shows the installation and configuration of this mechanism.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|oath-toolkit}} package.<br />
<br />
== Setting up the oath ==<br />
<br />
The oath seed is an hexadecimal number that should be unique per user. To generate a new seed for a user, you could use the following command line:<br />
<br />
$ head -10 /dev/urandom | sha512sum | cut -b 1-30<br />
1ab4321412aebcw<br />
<br />
Note the above output seed is used as example seed in this article and '''must not''' be used. There needs to be one oath per user and link to it in a configuration file {{ic|/etc/users.oath}}. While being root create the file and insert the user seed:<br />
<br />
{{hc|/etc/users.oath|# Option User Prefix Seed<br />
HOTP/T30/6 ''user'' - ''1ab4321412aebcw''}}<br />
<br />
Make sure that the file can only be accessed by root:<br />
<br />
# chmod 600 /etc/users.oath<br />
# chown root /etc/users.oath<br />
<br />
== Setting up the PAM ==<br />
<br />
To enable oath for a specific service only, like ssh, you can edit the file /etc/pam.d/sshd and add at the beginning of the file the following line :<br />
<br />
auth sufficient pam_oath.so usersfile=/etc/users.oath window=30 digits=6<br />
<br />
This will allow authentication if you just enter the right oath code. You can make it a requirement and let the rest of the pam stack be processed if you use the following line instead :<br />
<br />
auth required pam_oath.so usersfile=/etc/users.oath window=30 digits=6<br />
<br />
== Logging with an oath pass ==<br />
<br />
Run the following command if you loggin and need the current oath pass :<br />
<br />
oathtool -v -d6 ''1ab4321412aebcw''<br />
<br />
Of course replace ''1ab4321412aebcw'' by the seed corresponding to your user. It will display something like that :<br />
<br />
Hex secret: 1ab4321412aebc<br />
Base32 secret: DK2DEFASV26A====<br />
Digits: 6<br />
Window size: 0<br />
Start counter: 0x0 (0)<br />
<br />
820170<br />
<br />
The last number is actually the code you can use to log in right now, but more interestingly the Base32 secret, is actually what we need to generate a qr code for this user. To do so install the package {{Pkg|qrencode}} to run the following command :<br />
<br />
qrencode -o ''user''.png 'otpauth://totp/''user''@''machine''?secret=''DK2DEFASV26A===='''<br />
<br />
Of course change ''user'', ''machine'' and ''DK2DEFASV26A===='' accordingly. Once done, you can visualize your qrcode with your preferred image visualizer application and use that to configure your phone. It is pretty straight forward to use FreeOTP to then take a screenshot of that ''.png'' and get it to display OTP pass when needed.<br />
<br />
{{Note|The secret key of your users is the most important information in this system. Once you setup a phone to provide OTP, it does have that key. The qr code in that ''.png'' file does have that key. You need to take extra care of this file. They should only be stored on encrypted medium (Your phone need to be using encryption for any sane level of security). If not even confined in a sandbox like Samsung Knox to prevent third party application to potentially access them.}}<br />
<br />
== See also ==<br />
<br />
* [http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml Two-factor time based (TOTP) SSH authentication with pam_oath and Google Authenticator]<br />
* [http://www.nongnu.org/oath-toolkit/pam_oath.html pam_oath man page]</div>Wincraft71https://wiki.archlinux.org/index.php?title=Pam_oath&diff=518935Pam oath2018-04-28T05:51:41Z<p>Wincraft71: /* Logging with an oath pass */ misspelled words. italic for file extensions</p>
<hr />
<div>{{DISPLAYTITLE:pam_oath}}<br />
[[Category:Secure Shell]]<br />
[[ja:Pam oath]]<br />
The [http://www.nongnu.org/oath-toolkit/index.html OATH Toolkit] provides a two-step authentication procedure using one-time passcodes (OTP). It complies to two OTP method RFC standards ([[w:HMAC-based_One-time_Password_Algorithm|HOTP]], [[w:Time-based_One-time_Password_Algorithm|TOTP]]). The OTP generator applications are available for iOS, Android, Blackberry and other devices. Similar to [[Google Authenticator]] the authentication mechanism integrates into the Linux [[PAM]] system. This guide shows the installation and configuration of this mechanism.<br />
<br />
== Installation ==<br />
<br />
Install the {{Pkg|oath-toolkit}} package.<br />
<br />
== Setting up the oath ==<br />
<br />
The oath seed is an hexadecimal number that should be unique per user. To generate a new seed for a user, you could use the following command line:<br />
<br />
$ head -10 /dev/urandom | sha512sum | cut -b 1-30<br />
1ab4321412aebcw<br />
<br />
Note the above output seed is used as example seed in this article and '''must not''' be used. There needs to be one oath per user and link to it in a configuration file {{ic|/etc/users.oath}}. While being root create the file and insert the user seed:<br />
<br />
{{hc|/etc/users.oath|# Option User Prefix Seed<br />
HOTP/T30/6 ''user'' - ''1ab4321412aebcw''}}<br />
<br />
Make sure that the file can only be accessed by root:<br />
<br />
# chmod 600 /etc/users.oath<br />
# chown root /etc/users.oath<br />
<br />
== Setting up the PAM ==<br />
<br />
To enable oath for a specific service only, like ssh, you can edit the file /etc/pam.d/sshd and add at the beginning of the file the following line :<br />
<br />
auth sufficient pam_oath.so usersfile=/etc/users.oath window=30 digits=6<br />
<br />
This will allow authentification if you just enter the right oath code. You can make it a requirement and let the rest of the pam stack be processed if you use the following line instead :<br />
<br />
auth required pam_oath.so usersfile=/etc/users.oath window=30 digits=6<br />
<br />
== Logging with an oath pass ==<br />
<br />
Run the following command if you loggin and need the current oath pass :<br />
<br />
oathtool -v -d6 ''1ab4321412aebcw''<br />
<br />
Of course replace ''1ab4321412aebcw'' by the seed corresponding to your user. It will display something like that :<br />
<br />
Hex secret: 1ab4321412aebc<br />
Base32 secret: DK2DEFASV26A====<br />
Digits: 6<br />
Window size: 0<br />
Start counter: 0x0 (0)<br />
<br />
820170<br />
<br />
The last number is actually the code you can use to log in right now, but more interestingly the Base32 secret, is actually what we need to generate a qr code for this user. To do so install the package {{Pkg|qrencode}} to run the following command :<br />
<br />
qrencode -o ''user''.png 'otpauth://totp/''user''@''machine''?secret=''DK2DEFASV26A===='''<br />
<br />
Of course change ''user'', ''machine'' and ''DK2DEFASV26A===='' accordingly. Once done, you can visualize your qrcode with your preferred image visualizer application and use that to configure your phone. It is pretty straight forward to use FreeOTP to then take a screenshot of that ''.png'' and get it to display OTP pass when needed.<br />
<br />
{{Note|The secret key of your users is the most important information in this system. Once you setup a phone to provide OTP, it does have that key. The qr code in that ''.png'' file does have that key. You need to take extra care of this file. They should only be stored on encrypted medium (Your phone need to be using encryption for any sane level of security). If not even confined in a sandbox like Samsung Knox to prevent third party application to potentially access them.}}<br />
<br />
== See also ==<br />
<br />
* [http://spod.cx/blog/two-factor-ssh-auth-with-pam_oath-google-authenticator.shtml Two-factor time based (TOTP) SSH authentication with pam_oath and Google Authenticator]<br />
* [http://www.nongnu.org/oath-toolkit/pam_oath.html pam_oath man page]</div>Wincraft71https://wiki.archlinux.org/index.php?title=OpenSSH&diff=518925OpenSSH2018-04-28T01:02:54Z<p>Wincraft71: /* Forwarding other ports */ reworded sentences to make more sense, fixed information about bind_address, reference man page for -L option which explains interfaces. Monospace for ip addresses.</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[de:SSH]]<br />
[[es:Secure Shell]]<br />
[[fa:SSH]]<br />
[[fr:ssh]]<br />
[[ja:Secure Shell]]<br />
[[ru:Secure Shell]]<br />
[[zh-hans:Secure Shell]]<br />
{{Related articles start}}<br />
{{Related|SSH keys}}<br />
{{Related|Pam abl}}<br />
{{Related|fail2ban}}<br />
{{Related|sshguard}}<br />
{{Related|Sshfs}}<br />
{{Related|Syslog-ng}}<br />
{{Related|SFTP chroot}}<br />
{{Related|SCP and SFTP}}<br />
{{Related articles end}}<br />
<br />
Secure Shell (SSH) is a network protocol that allows data to be exchanged over a secure channel between two computers. Encryption provides confidentiality and integrity of data. SSH uses public-key cryptography to authenticate the remote computer and allow the remote computer to authenticate the user, if necessary.<br />
<br />
SSH is typically used to log into a remote machine and execute commands, but it also supports tunneling, forwarding arbitrary TCP ports and X11 connections; file transfer can be accomplished using the associated SFTP or SCP protocols.<br />
<br />
An SSH server, by default, listens on the standard TCP port 22. An SSH client program is typically used for establishing connections to an ''sshd'' daemon accepting remote connections. Both are commonly present on most modern operating systems, including macOS, GNU/Linux, Solaris and OpenVMS. Proprietary, freeware and open source versions of various levels of complexity and completeness exist.<br />
<br />
== OpenSSH ==<br />
OpenSSH (OpenBSD Secure Shell) is a set of computer programs providing encrypted communication sessions over a computer network using the ssh protocol. It was created as an open source alternative to the proprietary Secure Shell software suite offered by SSH Communications Security. OpenSSH is developed as part of the OpenBSD project, which is led by Theo de Raadt.<br />
<br />
OpenSSH is occasionally confused with the similarly-named OpenSSL; however, the projects have different purposes and are developed by different teams, the similar name is drawn only from similar goals.<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{Pkg|openssh}} package.<br />
<br />
=== Client usage ===<br />
<br />
To connect to a server, run:<br />
<br />
$ ssh -p ''port'' ''user''@''server-address''<br />
<br />
If the server only allows public-key authentication, follow [[SSH keys]].<br />
<br />
==== Configuration ====<br />
<br />
The client can be configured to store common options and hosts. All options can be declared globally or restricted to specific hosts. For example:<br />
<br />
{{hc|~/.ssh/config|# global options<br />
User ''user''<br />
<br />
# host-specific options<br />
Host myserver<br />
HostName ''server-address''<br />
Port ''port''}}<br />
<br />
With such a configuration, the following commands are equivalent<br />
<br />
$ ssh -p ''port'' ''user''@''server-address''<br />
$ ssh myserver<br />
<br />
See {{man|5|ssh_config}} for more information.<br />
<br />
Some options do not have command line switch equivalents, but you can specify config options on the command line with {{ic|-o}}. For example {{ic|1=-oKexAlgorithms=+diffie-hellman-group1-sha1}}.<br />
<br />
=== Server usage ===<br />
<br />
==== Configuration ====<br />
<br />
The SSH daemon configuration file can be found and edited in {{ic|/etc/ssh/ssh'''d'''_config}}.<br />
<br />
To allow access only for some users add this line:<br />
AllowUsers ''user1 user2''<br />
<br />
To allow access only for some groups:<br />
AllowGroups ''group1 group2''<br />
<br />
To add a nice welcome message (e.g. from the {{ic|/etc/issue}} file), configure the {{ic|Banner}} option:<br />
Banner /etc/issue<br />
<br />
Public and private host keys are automatically generated at installation in {{ic|/etc/ssh}} by the ''sshd'' [[#Daemon_management|service files]]. Four key pairs are provided based on the algorithms [[SSH_keys#Choosing_the_authentication_key_type|dsa, rsa, ecdsa and ed25519]]. To have sshd use a particular key, specify the following option:<br />
HostKey /etc/ssh/ssh_host_rsa_key<br />
<br />
If the server is to be exposed to the WAN, it is recommended to change the default port from 22 to a random higher one like this:<br />
Port 39901<br />
<br />
{{Tip|<br />
* To help select an alternative port that is not already assigned to a common service, review the [[Wikipedia:List of TCP and UDP port numbers|list of TCP and UDP port numbers]]. You can also find port information locally in {{ic|/etc/services}}. A port change from default port 22 will reduce the number of log entries caused by automated authentication attempts but will not eliminate them. See [[Port knocking]] for related information.<br />
* It is recommended to disable password logins entirely. This will greatly increase security, see [[#Force public key authentication]] for more information. See [[#Protection]] for more recommend security methods.<br />
* OpenSSH can listen to multiple ports simply by having multiple {{ic|Port ''port_number''}} lines in the config file.}}<br />
<br />
==== Daemon management ====<br />
<br />
{{Pkg|openssh}} comes with two kinds of [[systemd]] service files:<br />
#{{ic|sshd.service}}, which will keep the SSH daemon permanently active and fork for each incoming connection.[https://projects.archlinux.org/svntogit/packages.git/tree/trunk/sshd.service?h=packages/openssh#n16] It is especially suitable for systems with a large amount of SSH traffic.[https://projects.archlinux.org/svntogit/packages.git/tree/trunk/sshd.service?h=packages/openssh&id=4cadf5dff444e4b7265f8918652f4e6dff733812#n15] <br />
#{{ic|sshd.socket}} + {{ic|sshd@.service}}, which spawn on-demand instances of the SSH daemon per connection. Using it implies that ''systemd'' listens on the SSH socket and will only start the daemon process for an incoming connection. It is the recommended way to run {{ic|sshd}} in almost all cases.[https://projects.archlinux.org/svntogit/packages.git/tree/trunk/sshd.service?h=packages/openssh&id=4cadf5dff444e4b7265f8918652f4e6dff733812#n18][http://lists.freedesktop.org/archives/systemd-devel/2011-January/001107.html][http://0pointer.de/blog/projects/inetd.html]<br />
<br />
You can [[start]] and [[enable]] either {{ic|sshd.service}} '''or''' {{ic|sshd.socket}} to begin using the daemon.<br />
<br />
If using the socket service, you will need to [[edit]] the unit file if you want it to listen on a port other than the default 22:<br />
<br />
{{hc|# systemctl edit sshd.socket|<nowiki><br />
[Socket]<br />
ListenStream=<br />
ListenStream=12345<br />
</nowiki>}}<br />
<br />
{{Warning|Using {{ic|sshd.socket}} negates the {{ic|ListenAddress}} setting, so it will allow connections over any address. To achieve the effect of setting {{ic|ListenAddress}}, you must specify the port ''and'' IP for {{ic|ListenStream}} (e.g. {{ic|1=ListenStream=192.168.1.100:22}}). You must also add {{ic|1=FreeBind=true}} under {{ic|[Socket]}} or else setting the IP address will have the same drawback as setting {{ic|ListenAddress}}: the socket will fail to start if the network is not up in time.}}<br />
<br />
{{Tip|When using socket activation a transient instance of {{ic|sshd@.service}} will be started for each connection (with different instance names). Therefore, neither {{ic|sshd.socket}} nor the daemon's regular {{ic|sshd.service}} allow to monitor connection attempts in the log. The logs of socket-activated instances of SSH can be seen with {{ic|journalctl -u "sshd@*"}} or with {{ic|journalctl /usr/bin/sshd}}.}}<br />
<br />
==== Protection ====<br />
<br />
Allowing remote log-on through SSH is good for administrative purposes, but can pose a threat to your server's security. Often the target of brute force attacks, SSH access needs to be limited properly to prevent third parties gaining access to your server.<br />
<br />
Several other good guides are available on the topic, for example:<br />
*[https://wiki.mozilla.org/Security/Guidelines/OpenSSH Article by Mozilla Infosec Team]<br />
*[https://stribika.github.io/2015/01/04/secure-secure-shell.html Secure sshd]<br />
<br />
===== Force public key authentication =====<br />
<br />
If a client cannot authenticate through a public key, by default the SSH server falls back to password authentication, thus allowing a malicious user to attempt to gain access by [[#Protecting against brute force attacks|brute-forcing]] the password. One of the most effective ways to protect against this attack is to disable password logins entirely, and force the use of [[SSH keys]]. This can be accomplished by disabling the following options in {{ic|sshd_config}}:<br />
<br />
PasswordAuthentication no<br />
<br />
{{Warning|Before adding this to your configuration, make sure that all accounts which require SSH access have public-key authentication set up in the corresponding {{ic|authorized_keys}} files. See [[SSH keys#Copying the public key to the remote server]] for more information.}}<br />
<br />
===== Two-factor authentication and public keys =====<br />
SSH can be set up to require multiple ways of authentication, you can tell which authentication methods are required using the {{ic|AuthenticationMethods}} option. This enables you to use public keys as well as a two-factor authorization.<br />
<br />
See [[Google Authenticator]] to set up Google Authenticator.<br />
<br />
To use [[PAM]] with OpenSSH, edit the following files:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
ChallengeResponseAuthentication yes<br />
AuthenticationMethods publickey keyboard-interactive:pam<br />
}}<br />
<br />
Then you can log in with either a publickey '''or''' the user authentication as required by your PAM setup.<br />
<br />
If, on the other hand, you want to authenticate the user on both a publickey '''and''' the user authentication as required by your PAM setup, use a comma instead of a space to separate the AuthenticationMethods:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
ChallengeResponseAuthentication yes<br />
AuthenticationMethods publickey''','''keyboard-interactive:pam<br />
}}<br />
<br />
With required pubkey '''and''' pam authentication you may wish to disable the password requirement:<br />
{{hc|/etc/pam.d/sshd|<br />
auth required pam_securetty.so #disable remote root<br />
#Require google authenticator<br />
auth required pam_google_authenticator.so<br />
#But not password<br />
#auth include system-remote-login<br />
account include system-remote-login<br />
password include system-remote-login<br />
session include system-remote-login<br />
}}<br />
<br />
===== Protecting against brute force attacks =====<br />
Brute forcing is a simple concept: One continuously tries to log in to a webpage or server log-in prompt like SSH with a high number of random username and password combinations.<br />
<br />
====== Using ufw ======<br />
<br />
See [[ufw#Rate limiting with ufw]].<br />
<br />
====== Using iptables ======<br />
<br />
{{Merge|Simple_stateful_firewall#Bruteforce_attacks|Out of scope, same technique as already described in the SSF.}}<br />
<br />
If you are already using iptables you can easily protect SSH against brute force attacks by using the following rules. <br />
<br />
{{note|In this example the SSH port was changed to port 42660 TCP.}}<br />
<br />
Before the following rules can be used we create a new rule chain to log and drop too many connection attempts:<br />
<br />
# iptables -N LOG_AND_DROP<br />
<br />
The first rule will be applied to packets that signal the start of new connections headed for TCP port 42660<br />
<br />
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --set --name DEFAULT --rsource<br />
<br />
The next rule tells iptables to look for packets that match the previous rule's parameters, and which also come from hosts already added to the watch list.<br />
<br />
# iptables -A INPUT -p tcp -m tcp --dport 42660 -m state --state NEW -m recent --update --seconds 90 --hitcount 4 --name DEFAULT --rsource -j LOG_AND_DROP<br />
<br />
Now iptables decides what to do with TCP traffic to port 42660 which does not match the previous rule.<br />
<br />
# iptables -A INPUT -p tcp -m tcp --dport 42660 -j ACCEPT<br />
<br />
We are appending this rule to the LOG_AND_DROP table, and we use the -j (jump) operator to pass the packet's information to the logging facility<br />
<br />
# iptables -A LOG_AND_DROP -j LOG --log-prefix "iptables deny: " --log-level 7<br />
<br />
After they are logged by the first rule, all packets are then dropped<br />
<br />
# iptables -A LOG_AND_DROP -j DROP<br />
<br />
====== Anti-brute-force tools ======<br />
<br />
You can protect yourself from brute force attacks by using an automated script that blocks anybody trying to brute force their way in, for example [[fail2ban]] or [[sshguard]].<br />
<br />
* Only allow incoming SSH connections from trusted locations<br />
* Use [[fail2ban]] or [[sshguard]] to automatically block IP addresses that fail password authentication too many times.<br />
* Use [https://github.com/jtniehof/pam_shield pam_shield] to block IP addresses that perform too many login attempts within a certain period of time. In contrast to [[fail2ban]] or [[sshguard]], this program does not take login success or failure into account.<br />
<br />
===== Limit root login =====<br />
{{Out of date|Root login has been disabled by default upstream in the current version. Unclear to me what parts of this section and subsections are redundant.}}<br />
<br />
It is generally considered bad practice to allow the root user to log in without restraint over SSH. There are two methods by which SSH root access can be restricted for increased security.<br />
<br />
====== Deny ======<br />
<br />
Sudo selectively provides root rights for actions requiring these without requiring authenticating against the root account. This allows locking the root account against access via SSH and potentially functions as a security measure against brute force attacks, since now an attacker must guess the account name in addition to the password.<br />
<br />
SSH can be configured to deny remote logins with the root user by editing the "Authentication" section in {{ic|/etc/ssh/sshd_config}}. Simply change {{ic|#PermitRootLogin prohibit-password}} to {{ic|no}} and uncomment the line:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
PermitRootLogin no<br />
...<br />
}}<br />
<br />
Next, [[restart]] the SSH daemon.<br />
<br />
You will now be unable to log in through SSH under root, but will still be able to log in with your normal user and use [[su]] or [[sudo]] to do system administration.<br />
<br />
====== Restrict ======<br />
<br />
Some automated tasks such as remote, full-system backup require full root access. To allow these in a secure way, instead of disabling root login via SSH, it is possible to only allow root logins for selected commands. This can be achieved by editing {{ic|~root/.ssh/authorized_keys}}, by prefixing the desired key, e.g. as follows:<br />
<br />
command="/usr/lib/rsync/rrsync -ro /" ssh-rsa …<br />
<br />
This will allow any login with this specific key only to execute the command specified between the quotes.<br />
<br />
The increased attack surface created by exposing the root user name at login can be compensated by adding the following to {{ic|sshd_config}}:<br />
<br />
PermitRootLogin forced-commands-only<br />
<br />
This setting will not only restrict the commands which root may execute via SSH, but it will also disable the use of passwords, forcing use of public key authentication for the root account.<br />
<br />
A slightly less restrictive alternative will allow any command for root, but makes brute force attacks infeasible by enforcing public key authentication. For this option, set:<br />
<br />
PermitRootLogin prohibit-password<br />
<br />
===== Securing the authorized_keys file =====<br />
<br />
For additional protection, you can prevent users from adding new public keys and connecting from them.<br />
<br />
In the server, make the {{ic|authorized_keys}} file read-only for the user and deny all other permissions:<br />
$ chmod 400 ~/.ssh/authorized_keys<br />
<br />
To keep the user from simply changing the permissions back, [[File permissions and attributes#chattr and lsattr|set the immutable bit]] on the {{ic|authorized_keys}} file. After that the user could rename the {{ic|~/.ssh}} directory to something else and create a new {{ic|~/.ssh}} directory and {{ic|authorized_keys}} file. To prevent this, set the immutable bit on the {{ic|~/.ssh}} directory too.<br />
<br />
{{Note|If you find yourself needing to add a new key, you will first have to remove the immutable bit from {{ic|authorized_keys}} and make it writable. Follow the steps above to secure it again.}}<br />
<br />
== Other SSH clients and servers ==<br />
Apart from OpenSSH, there are many SSH [[Wikipedia:Comparison of SSH clients|clients]] and [[Wikipedia:Comparison of SSH servers|servers]] available.<br />
<br />
=== Dropbear ===<br />
[[Wikipedia:Dropbear (software)|Dropbear]] is a SSH-2 client and server. {{Pkg|dropbear}} is available in the [[official repositories]].<br />
<br />
The command-line ssh client is named dbclient.<br />
<br />
=== Mosh ===<br />
From the Mosh [http://mosh.mit.edu/ website]:<br />
<br />
:Remote terminal application that allows roaming, supports intermittent connectivity, and provides intelligent local echo and line editing of user keystrokes. Mosh is a replacement for SSH. It is more robust and responsive, especially over slow connections such as Wi-Fi, cellular, and long-distance.<br />
<br />
[[Install]] the {{Pkg|mosh}} package, or {{AUR|mosh-git}} for the latest revision.<br />
<br />
Mosh has an undocumented command line option {{ic|1=--predict=experimental}} which produces more aggressive echoing of local keystrokes. Users interested in low-latency visual confirmation of keyboard input may prefer this prediction mode.<br />
<br />
{{Note|Mosh by design does not let you access session history, consider installing a terminal multiplexer such as [[tmux]] or [[screen]].}}<br />
<br />
== Tips and tricks ==<br />
<br />
{{Accuracy|According to the current layout, this section seems rather generic, but in fact most of the offered tips work only in ''openssh''. For example ''dropbear'' (listed in [[#Other SSH clients and servers]]) does not support SOCKS proxy.[https://en.wikipedia.org/wiki/Comparison_of_SSH_clients#Technical]}}<br />
<br />
=== Encrypted SOCKS tunnel ===<br />
<br />
This is highly useful for laptop users connected to various unsafe wireless connections. The only thing you need is an SSH server running at a somewhat secure location, like your home or at work. It might be useful to use a dynamic DNS service like [http://www.dyndns.org/ DynDNS] so you do not have to remember your IP-address.<br />
<br />
==== Step 1: start the connection ====<br />
<br />
You only have to execute this single command to start the connection:<br />
<br />
$ ssh -TND 4711 ''user''@''host''<br />
<br />
where {{Ic|''user''}} is your username at the SSH server running at the {{Ic|''host''}}. It will ask for your password, and then you are connected! The {{Ic|N}} flag disables the interactive prompt, and the {{Ic|D}} flag specifies the local port on which to listen on (you can choose any port number if you want). The {{Ic|T}} flag disables pseudo-tty allocation.<br />
<br />
It is nice to add the verbose ({{Ic|-v}}) flag, because then you can verify that it is actually connected from that output.<br />
<br />
==== Step 2: configure your browser (or other programs) ====<br />
<br />
The above step is completely useless if you do not configure your web browser (or other programs) to use this newly created socks tunnel. Since the current version of SSH supports both SOCKS4 and SOCKS5, you can use either of them.<br />
<br />
* For Firefox: ''Edit > Preferences > Advanced > Network > Connection > Setting'': <br> Check the ''Manual proxy configuration'' radio button, and enter {{ic|localhost}} in the ''SOCKS host'' text field, and then enter your port number in the next text field ({{ic|4711}} in the example above).<br />
<br />
Firefox does not automatically make DNS requests through the socks tunnel. This potential privacy concern can be mitigated by the following steps:<br />
<br />
# Type about:config into the Firefox location bar.<br />
# Search for network.proxy.socks_remote_dns<br />
# Set the value to true.<br />
# Restart the browser.<br />
<br />
* For Chromium: You can set the SOCKS settings as environment variables or as command line options. I recommend to add one of the following functions to your {{ic|.bashrc}}:<br />
function secure_chromium {<br />
port=4711<br />
export SOCKS_SERVER=localhost:$port<br />
export SOCKS_VERSION=5<br />
chromium &<br />
exit<br />
}<br />
OR<br />
function secure_chromium {<br />
port=4711<br />
chromium --proxy-server="socks://localhost:$port" &<br />
exit<br />
}<br />
<br />
Now open a terminal and just do:<br />
$ secure_chromium<br />
<br />
Enjoy your secure tunnel!<br />
<br />
=== X11 forwarding ===<br />
<br />
X11 forwarding is a mechanism that allows graphical interfaces of X11 programs running on a remote system to be displayed on a local client machine. For X11 forwarding the remote host does not need to have a full X11 system installed, however it needs at least to have ''xauth'' installed. ''xauth'' is a utility that maintains {{ic|Xauthority}} configurations used by server and client for authentication of X11 session ([http://xmodulo.com/2012/11/how-to-enable-x11-forwarding-using-ssh.html source]).<br />
<br />
{{Warning|X11 forwarding has important security implications which should be at least acknowledged by reading relevant sections of {{man|1|ssh}}, {{man|5|sshd_config}}, and {{man|5|ssh_config}} manual pages. See also [https://security.stackexchange.com/questions/14815/security-concerns-with-x11-forwarding this StackExchange question.]}}<br />
<br />
==== Setup ====<br />
<br />
On the remote system:<br />
<br />
*[[install]] the {{Pkg|xorg-xauth}} and {{Pkg|xorg-xhost}} packages<br />
*in {{ic|/etc/ssh/ssh'''d'''_config}}:<br />
**verify that {{ic|AllowTcpForwarding}} and {{ic|X11UseLocalhost}} options are set to ''yes'', and that {{ic|X11DisplayOffset}} is set to ''10'' (those are the default values if nothing has been changed, see {{man|5|sshd_config}})<br />
**set {{ic|X11Forwarding}} to ''yes''<br />
* then [[restart]] the [[#Daemon management|''sshd'' daemon]]. <br />
<br />
On the client side, enable the {{ic|ForwardX11}} option by either specifying the {{ic|-X}} switch on the command line for opportunistic connections, or by setting {{ic|ForwardX11}} to ''yes'' in the [[#Configuration|client's configuration]].<br />
<br />
{{Tip|You can enable the {{ic|ForwardX11Trusted}} option ({{ic|-Y}} switch on the command line) if GUI is drawing badly or you receive errors; this will prevent X11 forwardings from being subjected to the [http://www.x.org/wiki/Development/Documentation/Security/ X11 SECURITY extension] controls. Be sure you have read [[#X11 forwarding|the warning]] at the beginning of this section if you do so.}}<br />
<br />
==== Usage ====<br />
<br />
{{Accuracy|{{ic|xhost}} is [http://unix.stackexchange.com/questions/12755/how-to-forward-x-over-ssh-from-ubuntu-machine#comment-17148 generally not needed]}}<br />
<br />
Log on to the remote machine normally, specifying the {{ic|-X}} switch if ''ForwardX11'' was not enabled in the client's configuration file:<br />
$ ssh -X ''user@host''<br />
If you receive errors trying to run graphical applications, try ''ForwardX11Trusted'' instead:<br />
$ ssh -Y ''user@host''<br />
You can now start any X program on the remote server, the output will be forwarded to your local session:<br />
$ xclock<br />
<br />
If you get "Cannot open display" errors try the following command as the non root user:<br />
$ xhost +<br />
<br />
The above command will allow anybody to forward X11 applications. To restrict forwarding to a particular host type:<br />
$ xhost +hostname<br />
<br />
where hostname is the name of the particular host you want to forward to. See {{man|1|xhost}} for more details.<br />
<br />
Be careful with some applications as they check for a running instance on the local machine. [[Firefox]] is an example: either close the running Firefox instance or use the following start parameter to start a remote instance on the local machine:<br />
$ firefox --no-remote<br />
<br />
If you get "X11 forwarding request failed on channel 0" when you connect (and the server {{ic|/var/log/errors.log}} shows "Failed to allocate internet-domain X11 display socket"), make sure package {{Pkg|xorg-xauth}} is installed. If its installation is not working, try to either:<br />
<br />
* enable the {{ic|AddressFamily any}} option in {{ic|ssh'''d'''_config}} on the ''server'', or<br />
* set the {{ic|AddressFamily}} option in {{ic|ssh'''d'''_config}} on the ''server'' to inet.<br />
Setting it to inet may fix problems with Ubuntu clients on IPv4.<br />
<br />
For running X applications as other user on the SSH server you need to {{Ic|xauth add}} the authentication line taken from {{Ic|xauth list}} of the SSH logged in user.<br />
<br />
{{Tip|[http://unix.stackexchange.com/a/12772/29867 Here] are [http://unix.stackexchange.com/a/46748/29867 some] useful [http://superuser.com/a/805060/185665 links] for troubleshooting {{ic|X11 Forwarding}} issues.}}<br />
<br />
=== Forwarding other ports ===<br />
<br />
In addition to SSH's built-in support for X11, it can also be used to securely tunnel any TCP connection, by use of local forwarding or remote forwarding.<br />
<br />
Local forwarding opens a port on the local machine, connections to which will be forwarded to the remote host and from there on to a given destination. Very often, the forwarding destination will be the same as the remote host, thus providing a secure shell and, e.g. a secure VNC connection, to the same machine. Local forwarding is accomplished by means of the {{Ic|-L}} switch and it is accompanying forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -L 1000:mail.google.com:25 192.168.0.100<br />
<br />
will use SSH to login to and open a shell on {{ic|192.168.0.100}}, and will also create a tunnel from the local machine's TCP port 1000 to mail.google.com on port 25. Once established, connections to {{ic|localhost:1000}} will connect to the Gmail SMTP port. To Google, it will appear that any such connection (though not necessarily the data conveyed over the connection) originated from {{ic|192.168.0.100}}, and such data will be secure between the local machine and 192.168.0.100, but not between {{ic|192.168.0.100}} and Google, unless other measures are taken.<br />
<br />
Similarly:<br />
<br />
$ ssh -L 2000:192.168.0.100:6001 192.168.0.100<br />
<br />
will allow connections to {{ic|localhost:2000}} which will be transparently sent to the remote host on port 6001. The preceding example is useful for VNC connections using the vncserver utility--part of the tightvnc package--which, though very useful, is explicit about its lack of security.<br />
<br />
Remote forwarding allows the remote host to connect to an arbitrary host via the SSH tunnel and the local machine, providing a functional reversal of local forwarding, and is useful for situations where, e.g., the remote host has limited connectivity due to firewalling. It is enabled with the {{Ic|-R}} switch and a forwarding specification in the form of {{Ic|<tunnel port>:<destination address>:<destination port>}}.<br />
<br />
Thus:<br />
<br />
$ ssh -R 3000:irc.freenode.net:6667 192.168.0.200<br />
<br />
will bring up a shell on {{ic|192.168.0.200}}, and connections from {{ic|192.168.0.200}} to itself on port 3000 (the remote host's {{ic|localhost:3000}}) will be sent over the tunnel to the local machine and then on to irc.freenode.net on port 6667, thus, in this example, allowing the use of IRC programs on the remote host to be used, even if port 6667 would normally be blocked to it.<br />
<br />
Both local and remote forwarding can be used to provide a secure "gateway", allowing other computers to take advantage of an SSH tunnel, without actually running SSH or the SSH daemon by providing a bind-address for the start of the tunnel as part of the forwarding specification, e.g. {{Ic|<tunnel address>:<tunnel port>:<destination address>:<destination port>}}. The {{Ic|<tunnel address>}} can be any address on the machine at the start of the tunnel. The address {{Ic|localhost}} allows connections via the {{ic|localhost}} or loopback interface, and an empty address or {{Ic|*}} allow connections via any interface. By default, forwarding is limited to connections from the machine at the "beginning" of the tunnel, i.e. the {{Ic|<tunnel address>}} is set to {{Ic|localhost}}. Local forwarding requires no additional configuration, however remote forwarding is limited by the remote server's SSH daemon configuration. See the {{Ic|GatewayPorts}} option in {{man|5|sshd_config}} and {{ic|-L address}} option in {{man|1|ssh}} for more information about remote forwarding and local forwarding, respectively.<br />
<br />
=== Jump hosts ===<br />
<br />
In certain scenarios, there might not be a direct connection to your target SSH daemon, and the use of a jump server (or bastion server) is required. Thus, we attempt to connect together two or more SSH tunnels, and assuming your local keys are authorized against each server in the chain. This is possible using SSH agent forwarding ({{ic|-A}}) and pseudo-terminal allocation ({{ic|-t}}) which forwards your local key with the following syntax:<br />
<br />
$ ssh -A -t -l user1 bastion1 \<br />
ssh -A -t -l user2 intermediate2 \<br />
ssh -A -t -l user3 target<br />
<br />
An easier way to do this is using the {{ic|-J}} flag:<br />
<br />
$ ssh -J user1@bastion1,user2@intermediate2 user3@target<br />
<br />
Multiple hosts in the {{ic|-J}} directive can be separted with a comma, they will be connected to in the order listed. The {{ic|user...@}} part is not required, but can be used. The host specifications for {{ic|-J}} use the ssh configuration file, so specific per-host options can be set there, if needed.<br />
<br />
=== Reverse SSH through a relay ===<br />
<br />
{{Style|The idea of SSH tunneling is classic, so some references for detailed explanation would be nice. E.g. [https://unix.stackexchange.com/questions/46235/how-does-reverse-ssh-tunneling-work/118650#118650] which includes other scenarios.}}<br />
<br />
The idea is that client connects to the server via another relay, while the server is connected to the same relay using a reverse SSH tunnel. This is for example useful when the server is behind a NAT and relay is a publicly accessible SSH server used as a proxy to which the user has access. So the prerequisite is that client's keys are authorized against both the relay and the server and server's need to be authorized against the relay as well for the reverse SSH connection.<br />
<br />
The following configuration example assumes that user1 is the user account used on client, user2 on relay and user3 on server. First the server needs to establish the reverse tunnel with:<br />
<br />
ssh -R 2222:localhost:22 -N user2@relay<br />
<br />
Which can also be automated with a startup script, systemd service or {{Pkg|autossh}}.<br />
<br />
{{Expansion|Explain why {{ic|ssh user3@relay -p 2222}} is not sufficient.}}<br />
<br />
At the client side the connection is established with:<br />
<br />
ssh user2@relay ssh user3@localhost -p 2222<br />
<br />
The remote command to establish the connection to reverse tunnel can also be defined in relay's {{ic|~/.ssh/authorized_keys}} by including the {{ic|command}} field as follows:<br />
<br />
command="ssh user3@localhost -p 2222" ssh-rsa KEY2 user1@client<br />
<br />
In this case the connection is established with:<br />
<br />
ssh user2@relay<br />
<br />
Note that SCP's autocomplete function in client's terminal is not working and even the SCP transfers themselves aren't working under some configurations.<br />
<br />
=== Multiplexing ===<br />
<br />
The SSH daemon usually listens on port 22. However, it is common practice for many public internet hotspots to block all traffic that is not on the regular HTTP/S ports (80 and 443, respectively), thus effectively blocking SSH connections. The immediate solution for this is to have {{ic|sshd}} listen additionally on one of the whitelisted ports:<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
Port 22<br />
Port 443<br />
}}<br />
<br />
However, it is likely that port 443 is already in use by a web server serving HTTPS content, in which case it is possible to use a multiplexer, such as {{Pkg|sslh}}, which listens on the multiplexed port and can intelligently forward packets to many services.<br />
<br />
=== Speeding up SSH ===<br />
<br />
There are several [[#Configuration|client configuration]] options which can speed up connections either globally or for specific hosts. See {{man|5|ssh_config}} for full descriptions of these options.<br />
<br />
* You can make all sessions to the same host share a single connection using these options: {{bc|<nowiki><br />
ControlMaster auto<br />
ControlPersist yes<br />
ControlPath ~/.ssh/sockets/socket-%r@%h:%p<br />
</nowiki>}}<br />
: where {{ic|~/.ssh/sockets}} can be any directory not writable by other users.<br />
<br />
* {{ic|ControlPersist}} specifies how long the master should wait in the background for new clients after the initial client connection has been closed. Possible values are either: <br />
** {{ic|no}} to close the connection immediately after the last client disconnects, <br />
** a time in seconds,<br />
** {{ic|yes}} to wait forever, the connection will never be closed automatically.<br />
<br />
* Another option to improve speed is to enable compression with the {{ic|Compression yes}} option or the {{ic|-C}} flag.<br />
: {{Note|{{man|1|ssh}} states that "[c]ompression is desirable on modem lines and other slow connections, but will only slow down things on fast networks." This tip might be counterproductive depending on your network configuration.}}<br />
<br />
* Login time can be shortened by bypassing IPv6 lookup using the {{ic|AddressFamily inet}} option or {{ic|-4}} flag.<br />
<br />
* Last, if you intend to use SSH for SFTP or SCP, [https://www.psc.edu/index.php/hpn-ssh High Performance SSH/SCP] can significantly increase throughput by raising dynamically the SSH buffer sizes. Install the package {{AUR|openssh-hpn-git}} to use a patched version of OpenSSH with this enhancement.<br />
<br />
=== Mounting a remote filesystem with SSHFS ===<br />
<br />
Please refer to the [[SSHFS]] article to mount a SSH-accessible remote system to a local folder, so you will be able to do any operation on the mounted files with any tool (copy, rename, edit with vim, etc.). ''sshfs'' is generally preferred over ''shfs'', the latter has not been updated since 2004.<br />
{{Tip|There is a package {{AUR|autosshfs-git}} that can be used to run autosshfs automatically at login.}}<br />
<br />
=== Keep alive ===<br />
<br />
By default, the SSH session automatically logs out if it has been idle for a certain time. To keep the session up, the client can send a keep-alive signal to the server if no data has been received for some time, or symmetrically the server can send messages at regular intervals if it has not heard from the client.<br />
<br />
* On the '''server''' side, {{ic|ClientAliveInterval}} sets the timeout in seconds after which if no data has been received from the client, ''sshd'' will send a request for response. The default is 0, no message is sent. For example to request a response every 60 seconds from the client, set the {{ic|ClientAliveInterval 60}} option in your [[#Configuration_2|server configuration]]. See also the {{ic|ClientAliveCountMax}} and {{ic|TCPKeepAlive}} options.<br />
* On the '''client''' side, {{ic|ServerAliveInterval}} controls the interval between the requests for response sent from the client to the server. For example to request a response every 120 seconds from the server, add the {{ic|ServerAliveInterval 120}} option to your [[#Configuration|client configuration]]. See also the {{ic|ServerAliveCountMax}} and {{ic|TCPKeepAlive}} options.<br />
<br />
{{Note| To ensure a session is kept alive, only one of either the client or the server needs to send keep alive requests. If ones control both the servers and the clients, a reasonable choice is to only configure the clients that require a persistent session with a positive {{ic|ServerAliveInterval}} and leave other clients and servers in their default configuration.}}<br />
<br />
=== Automatically restart SSH tunnels with systemd ===<br />
<br />
[[systemd]] can automatically start SSH connections on boot/login ''and'' restart them when they fail. This makes it a useful tool for maintaining SSH tunnels.<br />
<br />
The following service can start an SSH tunnel on login using the connection settings in your [[#Configuration|ssh configuration]]. If the connection closes for any reason, it waits 10 seconds before restarting it:<br />
<br />
{{hc|~/.config/systemd/user/tunnel.service|<nowiki><br />
[Unit]<br />
Description=SSH tunnel to myserver<br />
<br />
[Service]<br />
Type=simple<br />
Restart=always<br />
RestartSec=10<br />
ExecStart=/usr/bin/ssh -F %h/.ssh/config -N myserver<br />
</nowiki>}}<br />
<br />
Then [[enable]] and [[start]] the user service. See [[#Keep alive]] for how to prevent the tunnel from timing out. If you wish to start the tunnel on boot, you will need to rewrite the unit as a system service.<br />
<br />
=== Autossh - automatically restarts SSH sessions and tunnels ===<br />
<br />
When a session or tunnel cannot be kept alive, for example due to bad network conditions causing client disconnections, you can use {{Pkg|autossh}} to automatically restart them.<br />
<br />
Usage examples:<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" username@example.com<br />
<br />
Combined with [[SSHFS]]:<br />
$ sshfs -o reconnect,compression=yes,transform_symlinks,ServerAliveInterval=45,ServerAliveCountMax=2,ssh_command='autossh -M 0' username@example.com: /mnt/example <br />
<br />
Connecting through a SOCKS-proxy set by [[Proxy settings]]:<br />
$ autossh -M 0 -o "ServerAliveInterval 45" -o "ServerAliveCountMax 2" -NCD 8080 username@example.com <br />
<br />
With the {{ic|-f}} option autossh can be made to run as a background process. Running it this way however means the passphrase cannot be entered interactively.<br />
<br />
The session will end once you type {{ic|exit}} in the session, or the autossh process receives a SIGTERM, SIGINT of SIGKILL signal.<br />
<br />
==== Run autossh automatically at boot via systemd ====<br />
<br />
If you want to automatically start autossh, you can create a systemd unit file:<br />
<br />
{{hc|/etc/systemd/system/autossh.service|2=<br />
[Unit]<br />
Description=AutoSSH service for port 2222<br />
After=network.target<br />
<br />
[Service]<br />
Environment="AUTOSSH_GATETIME=0"<br />
ExecStart=/usr/bin/autossh -M 0 -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Here {{ic|1=AUTOSSH_GATETIME=0}} is an environment variable specifying how long ssh must be up before autossh considers it a successful connection, setting it to 0 autossh also ignores the first run failure of ssh. This may be useful when running autossh at boot. Other environment variables are available on the manpage. Of course, you can make this unit more complex if necessary (see the systemd documentation for details), and obviously you can use your own options for autossh, but note that the {{ic|-f}} implying {{ic|1=AUTOSSH_GATETIME=0}} does not work with systemd. <br />
<br />
Remember to [[start]] and/or [[enable]] the service afterwards.<br />
<br />
You may also need to disable ControlMaster e.g.<br />
<br />
ExecStart=/usr/bin/autossh -M 0 -o ControlMaster=no -NL 2222:localhost:2222 -o TCPKeepAlive=yes foo@bar.com<br />
<br />
{{Tip|It is also easy to maintain several autossh processes, to keep several tunnels alive. Just create multiple service files with different names.}}<br />
<br />
=== Alternative service should SSH daemon fail ===<br />
<br />
For remote or headless servers which rely exclusively on SSH, a failure to start the SSH daemon (e.g., after a system upgrade) may prevent administration access. [[systemd]] offers a simple solution via {{ic|OnFailure}} option.<br />
<br />
Let's suppose the server runs {{ic|sshd}} and [[telnet]] is the fail-safe alternative of choice. Create a file as follows. Do '''not''' [[enable]] telnet.socket!<br />
<br />
{{hc|/etc/systemd/system/sshd.service.d/override.conf|2=<br />
[Unit]<br />
OnFailure=telnet.socket<br />
}}<br />
<br />
That's it. Telnet is not available when {{ic|sshd}} is running. Should {{ic|sshd}} fail to start, a telnet session can be opened for recovery.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Checklist ===<br />
<br />
Check these simple issues before you look any further.<br />
<br />
# The config directory {{ic|~/.ssh}} and its contents should be accessible only by your user (check this on both the client and the server): {{bc|<nowiki><br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/*<br />
$ chown -R $USER ~/.ssh<br />
</nowiki>}}<br />
# Check that the client's public key (e.g. {{ic|id_rsa.pub}}) is in {{ic|~/.ssh/authorized_keys}} on the server.<br />
# Check that you did not limit SSH access with {{ic|AllowUsers}} or {{ic|AllowGroups}} in the [[#Configuration_2|server config]].<br />
# Check if the user has set a password. Sometimes new users who have not yet logged in to the server do not have a password.<br />
# [[Append]] {{ic|LogLevel DEBUG}} to {{ic|/etc/ssh/sshd_config}}.<br />
# Use {{ic|journalctl -xe}} for possible (error) messages.<br />
# [[Restart]] {{ic|sshd}} and logout/login on both client and server.<br />
<br />
=== Connection refused or timeout problem ===<br />
<br />
==== Port forwarding ====<br />
<br />
If you are behind a NAT mode/router (which is likely unless you are on a VPS or publicly addressed host), make sure that your router is forwarding incoming ssh connections to your machine. Find the server's internal IP address with {{ic|$ ip addr}} and set up your router to forward TCP on your SSH port to that IP. [http://portforward.com portforward.com] can help with that.<br />
<br />
==== Is SSH running and listening? ====<br />
$ ss -tnlp<br />
<br />
If the above command do not show SSH port is open, SSH is NOT running. Check {{ic|/var/log/messages}} for errors etc.<br />
<br />
==== Are there firewall rules blocking the connection? ====<br />
<br />
[[Iptables]] may be blocking connections on port {{ic|22}}. Check this with:<br />
{{bc|# iptables -nvL}}<br />
and look for rules that might be dropping packets on the {{ic|INPUT}} chain. Then, if necessary, unblock the port with a command like: <br />
{{bc|<br />
# iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT<br />
}}<br />
For more help configuring firewalls, see [[firewalls]].<br />
<br />
==== Is the traffic even getting to your computer? ====<br />
Start a traffic dump on the computer you are having problems with:<br />
<br />
# tcpdump -lnn -i any port ssh and tcp-syn<br />
<br />
This should show some basic information, then wait for any matching traffic to happen before displaying it. Try your connection now. If you do not see any output when you attempt to connect, then something outside of your computer is blocking the traffic (e. g., hardware firewall, NAT router etc.).<br />
<br />
==== Your ISP or a third party blocking default port? ====<br />
{{Note|Try this step if you '''know''' you are not running any firewalls and you know you have configured the router for DMZ or have forwarded the port to your computer and it still does not work. Here you will find diagnostic steps and a possible solution.}}<br />
<br />
In some cases, your ISP might block the default port (SSH port 22) so whatever you try (opening ports, hardening the stack, defending against flood attacks, et al) ends up useless. To confirm this, create a server on all interfaces (0.0.0.0) and connect remotely. <br />
<br />
If you get an error message comparable to this:<br />
ssh: connect to host www.inet.hr port 22: Connection refused<br />
<br />
That means the port is '''not''' being blocked by the ISP, but the server does not run SSH on that port (See [[wikipedia:Security_through_obscurity|security through obscurity]]).<br />
<br />
However, if you get an error message comparable to this:<br />
ssh: connect to host 111.222.333.444 port 22: Operation timed out <br />
<br />
That means that something is rejecting your TCP traffic on port 22. Basically that port is stealth, either by your firewall or 3rd party intervention (like an ISP blocking and/or rejecting incoming traffic on port 22). If you know you are not running any firewall on your computer, and you know that Gremlins are not growing in your routers and switches, then your ISP is blocking the traffic.<br />
<br />
To double check, you can run Wireshark on your server and listen to traffic on port 22. Since Wireshark is a Layer 2 Packet Sniffing utility, and TCP/UDP are Layer 3 and above (see [[wikipedia:Internet protocol suite|IP Network stack]]), if you do not receive anything while connecting remotely, a third party is most likely to be blocking the traffic on that port to your server.<br />
<br />
===== Diagnosis =====<br />
<br />
[[Install]] either {{Pkg|tcpdump}} or Wireshark with the {{Pkg|wireshark-cli}} package.<br />
<br />
For tcpdump:<br />
<br />
# tcpdump -ni ''interface'' "port 22"<br />
<br />
For Wireshark:<br />
<br />
$ tshark -f "tcp port 22" -i ''interface''<br />
<br />
where {{ic|''interface''}} is the network interface for a WAN connection (see {{ic|ip a}} to check). If you are not receiving any packets while trying to connect remotely, you can be very sure that your ISP is blocking the incoming traffic on port 22.<br />
<br />
===== Possible solution =====<br />
The solution is just to use some other port that the ISP is not blocking. Open the {{ic|/etc/ssh/sshd_config}} and configure the file to use different ports. For example, add:<br />
<br />
Port 22<br />
Port 1234<br />
<br />
Also make sure that other "Port" configuration lines in the file are commented out. Just commenting "Port 22" and putting "Port 1234" will not solve the issue because then sshd will only listen on port 1234. Use both lines to run the SSH server on both ports. <br />
<br />
[[Restart]] the server {{ic|sshd.service}} and you are almost done. You still have to configure your client(s) to use the other port instead of the default port. There are numerous solutions to that problem, but let us cover two of them here.<br />
<br />
==== Read from socket failed: connection reset by peer ====<br />
<br />
Recent versions of openssh sometimes fail with the above error message when connecting to older ssh servers. This can be worked around by setting various [[#Configuration|client options]] for that host. See {{man|5|ssh_config}} for more information about the following options.<br />
<br />
The problem could be the {{ic|ecdsa-sha2-nistp*-cert-v01@openssh}} elliptical host key algorithms. These can be disabled by setting {{ic|HostKeyAlgorithms}} to a list excluding those algorithms.<br />
<br />
If that does not work, it could be that the list of ciphers is too long. Set the {{ic|Ciphers}} option to a shorter list (fewer than 80 characters should be enough). Similarly, you can also try shortening the list of {{ic|MACs}}.<br />
<br />
See also the [http://www.gossamer-threads.com/lists/openssh/dev/51339 discussion] on the openssh bug forum.<br />
<br />
=== "[your shell]: No such file or directory" / ssh_exchange_identification problem ===<br />
One possible cause for this is the need of certain SSH clients to find an absolute path (one returned by {{Ic|whereis -b [your shell]}}, for instance) in {{Ic|$SHELL}}, even if the shell's binary is located in one of the {{Ic|$PATH}} entries.<br />
<br />
==="Terminal unknown" or "Error opening terminal" error message===<br />
If you receive the above errors upon logging in, this means the server does not recognize your terminal. Ncurses applications like nano may fail with the message "Error opening terminal".<br />
<br />
The correct solution is to install the client terminal's terminfo file on the server. This tells console programs on the server how to correctly interact with your terminal. You can get info about current terminfo using {{ic|$ infocmp}} and then find out [[Pacman#Querying_package_databases|which package owns it]].<br />
<br />
If you cannot [[install]] it normally, you can copy your terminfo to your home directory on the server:<br />
<br />
$ ssh myserver mkdir -p ~/.terminfo/${TERM:0:1}<br />
$ scp /usr/share/terminfo/${TERM:0:1}/$TERM myserver:~/.terminfo/${TERM:0:1}/<br />
<br />
After logging in and out from the server the problem should be fixed.<br />
<br />
==== TERM hack ====<br />
<br />
{{warning|This should only be used as a last resort.}}<br />
<br />
Alternatively, you can simply set {{ic|1=TERM=xterm}} in your environment on the server (e.g. in {{ic|.bash_profile}}). This will silence the error and allow ncurses applications to run again, but you may experience strange behavior and graphical glitches unless your terminal's control sequences exactly match xterm's.<br />
<br />
=== Connection closed by x.x.x.x [preauth] ===<br />
If you are seeing this error in your sshd logs, make sure you have set a valid HostKey<br />
HostKey /etc/ssh/ssh_host_rsa_key<br />
<br />
=== id_dsa refused by OpenSSH 7.0 ===<br />
<br />
OpenSSH 7.0 deprecated DSA public keys for security reasons. If you absolutely must enable them, set the [[#Configuration|config]] option {{ic|PubkeyAcceptedKeyTypes +ssh-dss}} (http://www.openssh.com/legacy.html does not mention this).<br />
<br />
=== No matching key exchange method found by OpenSSH 7.0 ===<br />
<br />
OpenSSH 7.0 deprecated the diffie-hellman-group1-sha1 key algorithm because it is weak and within theoretical range of the so-called Logjam attack (see http://www.openssh.com/legacy.html). If the key algorithm is needed for a particular host, ssh will produce an error message like this:<br />
<br />
Unable to negotiate with 127.0.0.1: no matching key exchange method found.<br />
Their offer: diffie-hellman-group1-sha1<br />
<br />
The best resolution for these failures is to upgrade/configure the server to not use deprecated algorithms. If that is not possible, you can force the client to reenable the algorithm with the [[#Configuration|client option]] {{ic|KexAlgorithms +diffie-hellman-group1-sha1}}.<br />
<br />
=== tmux/screen session killed when disconnecting from SSH ===<br />
<br />
If your processes get killed at the end of the session, it is possible that you are using socket activation and it gets killed by {{Pkg|systemd}} when it notices that the SSH session process exited. In that case there are two solutions. One is to avoid using socket activation by using {{ic|ssh.service}} instead of {{ic|ssh.socket}}. The other is to set {{ic|1=KillMode=process}} in the Service section of {{ic|ssh@.service}}.<br />
<br />
The {{ic|1=KillMode=process}} setting may also be useful with the classic {{ic|ssh.service}}, as it avoids killing the SSH session process or the {{Pkg|screen}} or {{Pkg|tmux}} processes when the server gets stopped or restarted.<br />
<br />
=== SSH session stops responding ===<br />
<br />
SSH responds to [[Wikipedia:Software_flow_control|flow control commands]] {{ic|XON}} and {{ic|XOFF}}. It will freeze/hang/stop responding when you hit {{ic|Ctrl+s}}. Use {{ic|Ctrl+q}} to resume your session.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:Secure Shell]]<br />
* [http://www.la-samhna.de/library/brutessh.html Defending against brute force ssh attacks]<br />
* [http://www.ibm.com/developerworks/library/l-keyc/index.html OpenSSH key management, Part 1] and [http://www.ibm.com/developerworks/library/l-keyc2 Part 2] on IBM developerWorks<br />
* [https://stribika.github.io/2015/01/04/secure-secure-shell.html Secure Secure Shell]</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dm-crypt/Specialties&diff=518873Dm-crypt/Specialties2018-04-27T01:49:50Z<p>Wincraft71: /* Boot Loader */ sbupdate was updated to allow configuration of filenames for "db" files</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Disk encryption]]<br />
[[ja:Dm-crypt/特記事項]]<br />
<br />
== Securing the unencrypted boot partition ==<br />
<br />
The {{ic|/boot}} partition and the [[Master Boot Record]] are the two areas of the disk that are not encrypted, even in an [[dm-crypt/Encrypting an entire system|encrypted root]] configuration. They cannot usually be encrypted because the [[boot loader]] and BIOS (respectively) are unable to unlock a dm-crypt container in order to continue the boot process. An exception is [[GRUB]], which gained a feature to unlock a LUKS encrypted {{ic|/boot}} - see [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]]. <br />
<br />
This section describes steps that can be taken to make the boot process more secure. <br />
<br />
{{Warning|Note that securing the {{ic|/boot}} partition and MBR can mitigate numerous attacks that occur during the boot process, but systems configured this way may still be vulnerable to BIOS/UEFI/firmware tampering, hardware keyloggers, cold boot attacks, and many other threats that are beyond the scope of this article. For an overview of system-trust issues and how these relate to full-disk encryption, refer to [http://www.youtube.com/watch?v&#61;pKeiKYA03eE].}}<br />
<br />
=== Booting from a removable device ===<br />
<br />
{{Warning|systemd version 230 cryptsetup generator emits {{ic|RequiresMountsFor}} for crypto keyfile. Therefore, when the filesystem that holds this file is unmounted, it also stops cryptsetup service. This behavior is incorrect because the filesystem and cryptokey is required only once, when the crypto container is initially setup. See [https://github.com/systemd/systemd/issues/3816 systemd issue 3816].}}<br />
<br />
Using a separate device to boot a system is a fairly straightforward procedure, and offers a significant security improvement against some kinds of attacks. Two vulnerable parts of a system employing an [[Dm-crypt/Encrypting_an_entire_system|encrypted root filesystem]] are<br />
<br />
* the [[Master Boot Record]], and<br />
* the {{ic|/boot}} partition.<br />
<br />
These must be stored unencrypted in order for the system to boot. In order to protect these from tampering, it is advisable to store them on a removable medium, such as a USB drive, and boot from that drive instead of the hard disk. As long as you keep the drive with you at all times, you can be certain that those components have not been tampered with, making authentication far more secure when unlocking your system.<br />
<br />
It is assumed that you already have your system configured with a dedicated partition mounted at {{ic|/boot}}. If you do not, please follow the steps in [[dm-crypt/System configuration#Boot loader]], substituting your hard disk for a removable drive.<br />
<br />
{{Note|You must make sure your system supports booting from the chosen medium, be it a USB drive, an external hard drive, an SD card, or anything else.}}<br />
<br />
Prepare the removable drive ({{ic|/dev/sdx}}).<br />
<br />
# gdisk /dev/sdx #format if necessary. Alternatively, cgdisk, fdisk, cfdisk, gparted...<br />
# mkfs.ext2 /dev/sdx1<br />
# mount /dev/sdx1 /mnt<br />
<br />
Copy your existing {{ic|/boot}} contents to the new one.<br />
<br />
# cp -ai /boot/* /mnt/<br />
<br />
Mount the new partition. Do not forget to update your [[fstab]] file accordingly.<br />
<br />
# umount /boot<br />
# umount /mnt<br />
# mount /dev/sdx1 /boot<br />
# genfstab -p -U / > /etc/fstab<br />
<br />
Update [[GRUB]]. {{ic|grub-mkconfig}} should detect the new partition UUID automatically, but custom menu entries may need to be updated manually.<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
# grub-install /dev/sdx #install to the removable device, not the hard disk.<br />
<br />
Reboot and test the new configuration. Remember to set your device boot order accordingly in your BIOS or [[UEFI]]. If the system fails to boot, you should still be able to boot from the hard drive in order to correct the problem.<br />
<br />
=== chkboot ===<br />
<br />
{{Warning|chkboot makes a {{ic|/boot}} partition '''tamper-evident''', not '''tamper-proof'''. By the time the chkboot script is run, you have already typed your password into a potentially compromised boot loader, kernel, or initrd. If your system fails the chkboot integrity test, no assumptions can be made about the security of your data.}}<br />
<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012, [http://www.heise.de/ct/inhalt/2012/03/6/]) the following script checks files under {{ic|/boot}} for changes of SHA-1 hash, inode, and occupied blocks on the hard drive. It also checks the [[Master Boot Record]]. The script cannot prevent certain type of attacks, but a lot are made harder. No configuration of the script itself is stored in unencrypted {{ic|/boot}}. With a locked/powered-off encrypted system, this makes it harder for some attackers because it is not apparent that an automatic checksum comparison of the partition is done upon boot. However, an attacker who anticipates these precautions can manipulate the firmware to run his own code on top of your kernel and intercept file system access, e.g. to {{ic|boot}}, and present the untampered files. Generally, no security measures below the level of the firmware are able to guarantee trust and tamper evidence.<br />
<br />
The script with installation instructions is [ftp://ftp.heise.de/pub/ct/listings/1203-146.zip available] (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2). There is also package {{AUR|chkboot}} to [[install]].<br />
<br />
After installation add a service file (the package includes one based on the following) and [[enable]] it: <br />
<br />
[Unit]<br />
Description=Check that boot is what we want<br />
Requires=basic.target<br />
After=basic.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/local/bin/chkboot.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
<br />
There is a small caveat for systemd. At the time of writing, the original {{ic|chkboot.sh}} script provided contains an empty space at the beginning of {{ic|<u> </u>#!/bin/bash}} which has to be removed for the service to start successfully.<br />
<br />
As {{ic|/usr/local/bin/chkboot_user.sh}} needs to be executed right after login, you need to add it to the [[autostart]] (e.g. under KDE -> ''System Settings -> Startup and Shutdown -> Autostart''; GNOME 3: ''gnome-session-properties''). <br />
<br />
With Arch Linux, changes to {{ic|/boot}} are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so: <br />
<br />
#!/bin/bash<br />
#<br />
# Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically<br />
#<br />
echo "Pacman update [1] Quickcheck before updating" & <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
/usr/local/bin/chkboot.sh<br />
sync # sync disks with any results <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
echo "Pacman update [2] Syncing repos for pacman" <br />
pacman -Syu<br />
/usr/local/bin/chkboot.sh<br />
sync <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user><br />
echo "Pacman update [3] All done, let us roll on ..."<br />
<br />
=== mkinitcpio-chkcryptoboot ===<br />
<br />
{{Warning|This hook does '''not''' encrypt [[GRUB]]'s core (MBR) code or EFI stub, nor does it protect against situations where an attacker is able to modify the behaviour of the bootloader to compromise the kernel and/or initramfs at run-time.}}<br />
<br />
{{aur|mkinitcpio-chkcryptoboot}} is a [[mkinitcpio]] hook that performs integrity checks during early-userspace and advises the user not to enter his root partition password if the system appears to have been compromised. Security is achieved through an [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|encrypted boot partition]], which is unlocked using [[GRUB#Boot partition|GRUB]]'s {{ic|cryptodisk.mod}} module, and a root filesystem partition, which is encrypted with a password different from the former. This way, the [[initramfs]] and [[kernel]] are secured against offline tampering, and the root partition can remain secure even if the {{ic|/boot}} partition password is entered on a compromised machine (provided that the chkcryptoboot hook detects the compromise, and is not itself compromised at run-time). <br />
<br />
This hook requires {{Pkg|grub}} release >=2.00 to function, and a dedicated, LUKS encrypted {{ic|/boot}} partition with its own password in order to be secure.<br />
<br />
==== Installation ====<br />
<br />
[[Install]] {{aur|mkinitcpio-chkcryptoboot}} and edit {{ic|/etc/default/chkcryptoboot.conf}}. If you want the ability of detecting if your boot partition was bypassed, edit the {{ic|CMDLINE_NAME}} and {{ic|CMDLINE_VALUE}} variables, with values known only to you. You can follow the advice of using two hashes as is suggested right after the installation. Also, be sure to make the appropriate changes to the [[kernel command line]] in {{ic|/etc/default/grub}}. Edit the {{ic|1=HOOKS=}} line in {{ic|/etc/mkinitcpio.conf}}, and insert the {{ic|chkcryptoboot}} hook '''before''' {{ic|encrypt}}. When finished, [[regenerate the initramfs]].<br />
<br />
==== Technical Overview ====<br />
<br />
{{aur|mkinitcpio-chkcryptoboot}} consists of an install hook and a run-time hook for mkinitcpio. The install hook runs every time the initramfs is rebuilt, and hashes the GRUB [[EFI]] stub ({{ic|$esp/EFI/grub_uefi/grubx64.efi}}) (in the case of [[UEFI]] systems) or the first 446 bytes of the disk on which GRUB is installed (in the case of BIOS systems), and stores that hash inside the initramfs located inside the encrypted {{ic|/boot}} partition. When the system is booted, GRUB prompts for the {{ic|/boot}} password, then the run-time hook performs the same hashing operation and compares the resulting hashes before prompting for the root partition password. If they do not match, the hook will print an error like this:<br />
<br />
CHKCRYPTOBOOT ALERT!<br />
CHANGES HAVE BEEN DETECTED IN YOUR BOOT LOADER EFISTUB!<br />
YOU ARE STRONGLY ADVISED NOT TO ENTER YOUR ROOT CONTAINER PASSWORD!<br />
Please type uppercase yes to continue:<br />
<br />
In addition to hashing the boot loader, the hook also checks the parameters of the running kernel against those configured in {{ic|/etc/default/chkcryptoboot.conf}}. This is checked both at run-time and after the boot process is done. This allows the hook to detect if GRUB's configuration was not bypassed at run-time and afterwards to detect if the entire {{ic|/boot}} partition was not bypassed.<br />
<br />
For BIOS systems the hook creates a hash of GRUB's first stage bootloader (installed to the first 446 bytes of the bootdevice) to compare at the later boot processes. The main second-stage GRUB bootloader {{ic|core.img}} is not checked.<br />
<br />
=== Other methods ===<br />
<br />
Alternatively to above scripts, a hash check can be set up with [[AIDE]] which can be customized via a very flexible configuration file. <br />
<br />
While one of these methods should serve the purpose for most users, they do not address all security problems associated with the unencrypted {{ic|/boot}}. One approach which endeavours to provide a fully authenticated boot chain was published with POTTS as an academic thesis to implement the [http://www1.informatik.uni-erlangen.de/stark STARK] authentication framework. <br />
<br />
The POTTS proof-of-concept uses Arch Linux as a base distribution and implements a system boot chain with <br />
<br />
* POTTS - a boot menu for a one-time authentication message prompt <br />
* TrustedGrub - a [[GRUB Legacy]] implementation which authenticates the kernel and initramfs against TPM chip registers <br />
* TRESOR - a kernel patch which implements AES but keeps the master-key not in RAM but in CPU registers during runtime. <br />
<br />
As part of the thesis [http://13.tc/p/potts/manual.html installation] instructions based on Arch Linux (ISO as of 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.<br />
<br />
== Using GPG, LUKS, or OpenSSL Encrypted Keyfiles ==<br />
<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 Post regarding OpenSSL salted bf-cbc encrypted keys] This post has the {{ic|bfkf}} initcpio hooks, install, and encrypted keyfile generator scripts.<br />
* LUKS: [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 Post regarding LUKS encrypted keys] with a {{ic|lukskey}} initcpio hook. Or [[#Encrypted /boot and a detached LUKS header on USB]] below with a custom encrypt hook for initcpio.<br />
<br />
Note that:<br />
<br />
* You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} should look like this:{{bc|1=HOOKS=( ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... )}} and you should add {{bc|1=resume=/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>}} to your [[kernel parameters]].<br />
* If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package {{AUR|gnupg1}}<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
== Remote unlocking of the root (or other) partition ==<br />
<br />
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a [[Wake-on-LAN]] service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running a [[mkinitcpio]] hook that configures a network interface. Some packages listed below contribute various [[Mkinitcpio#Build hooks|mkinitcpio build hooks]] to ease with the configuration.<br />
<br />
{{Note|<br />
* Keep in mind to use kernel device names for the network interface (e.g. {{ic|eth0}}) and not [[udev|udev's]] ones (e.g. {{ic|enp1s0}}), as those will not work.<br />
* It could be necessary to add [[Network configuration#Device driver|the module for your network card]] to the [[Mkinitcpio#MODULES|MODULES]] array.<br />
}}<br />
<br />
=== Remote unlocking (hooks: systemd, systemd-tool) ===<br />
<br />
AUR package {{AUR|mkinitcpio-systemd-tool}} provides a {{Pkg|systemd}}-centric mkinitcpio hook named ''systemd-tool'' with the following set of features for systemd in initramfs:<br />
<br />
{| class="wikitable"<br />
|- style="vertical-align:top;"<br />
| width=50% style="padding:10px;" |<br />
Core features provided by the hook:<br />
* unified systemd + mkinitcpio configuration<br />
* automatic provisioning of binary and config resources<br />
* on-demand invocation of mkinitcpio scripts and in-line functions <br />
| width=50% style="padding:10px;" |<br />
Features provided by the included service units:<br />
* initrd debugging<br />
* early network setup<br />
* interactive user shell<br />
* remote ssh access in initrd<br />
* cryptsetup + custom password agent <br />
|}<br />
<br />
The {{AUR|mkinitcpio-systemd-tool}} package requires the [[mkinitcpio#Common hooks|systemd hook]]. For more information be sure to read the project's [https://github.com/random-archer/mkinitcpio-systemd-tool/blob/master/README.md README] as well as the provided default [https://github.com/random-archer/mkinitcpio-systemd-tool systemd service unit files] to get you started.<br />
<br />
The recommended hooks are: {{ic|base autodetect modconf block filesystems keyboard fsck systemd systemd-tool}}.<br />
<br />
=== Remote unlocking (hooks: netconf, dropbear, tinyssh, ppp) ===<br />
<br />
Another package combination providing remote logins to the initcpio is {{AUR|mkinitcpio-netconf}} and/or {{AUR|mkinitcpio-ppp}} (for remote unlocking using a [[Wikipedia:Point-to-Point Protocol|PPP]] connection over the internet) along with an [[SSH]] server. You have the option of using either {{AUR|mkinitcpio-dropbear}} or {{AUR|mkinitcpio-tinyssh}}. Those hooks do not install any shell, so you also need to [[install]] the {{AUR|mkinitcpio-utils}} package. The instructions below can be used in any combination of the packages above. When there are different paths, it will be noted.<br />
<br />
# If you do not have an SSH key pair yet, [[SSH keys#Generating_an_SSH_key_pair|generate one]] on the client system (the one which will be used to unlock the remote machine). If your choose to use {{AUR|mkinitcpio-tinyssh}}, you have the option of using [[SSH_keys#Ed25519|Ed25519 keys]].<br />
# Insert your SSH public key (i.e. the one you usually put onto hosts so that you can ssh in without a password, or the one you just created and which ends with ''.pub'') into the remote machine's {{ic|/etc/dropbear/root_key}} or {{ic|/etc/tinyssh/root_key}} file. {{Tip|This method can later be used to add other SSH public keys as needed; In the case of simply copying the content of the remote's {{ic|~/.ssh/authorized_keys}}, be sure to verify that it only contains keys you intend to be using to unlock the remote machine. When adding additional keys, regenerate your initrd as well using {{ic|mkinitcpio}}. See also [[Secure Shell#Protection]].}}<br />
# Add all three {{ic|<netconf and/or ppp> <dropbear or tinyssh> encryptssh}} [[Mkinitcpio#HOOKS|hooks]] before {{ic|filesystems}} within the "HOOKS" array in {{ic|/etc/mkinitcpio.conf}} (the {{ic|encryptssh}} replaces the {{ic|encrypt}} hook). Then [[regenerate the initramfs]]. {{Note|The {{ic|net}} hook provided by {{Pkg|mkinitcpio-nfs-utils}} is '''not''' needed.}}<br />
# Configure the required {{ic|1=cryptdevice=}} [[Dm-crypt/System_configuration#Boot_loader|parameter]] and add the {{ic|1=ip=}} [[Kernel_parameters|kernel command parameter]] to your bootloader configuration with the appropriate arguments. For example, if the DHCP server does not attribute a static IP to your remote system, making it difficult to access via SSH accross reboots, you can explicitly state the IP you want to be using:{{bc|<nowiki>ip=192.168.1.1:::::eth0:none</nowiki>}}{{Note|As of version 0.0.4 of {{AUR|mkinitcpio-netconf}}, you can nest multiple {{ic|ip<nowiki>=</nowiki>}} parameters in order to configure multiple interfaces. You cannot mix it with {{ic|ip<nowiki>=</nowiki>dhcp}} ({{ic|ip<nowiki>=</nowiki>:::::eth0:dhcp}}) alone. An interface needs to be specified.}}{{bc|<nowiki>ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none</nowiki>}}For a detailed description have a look at the [[Mkinitcpio#Using net|according mkinitcpio section]]. When finished, update the configuration of your [[bootloader]].<br />
# Finally, restart the remote system and try to [[Secure_Shell#Client usage|ssh to it]], '''explicitly stating the "root" username''' (even if the root account is disabled on the machine, this root user is used only in the initrd for the purpose of unlocking the remote system). If you are using the {{AUR|mkinitcpio-dropbear}} package and you also have the {{Pkg|openssh}} package installed, then you most probably will not get any warnings before logging in, because it convert and use the same host keys openssh uses. (Except Ed25519 keys, dropbear does not support them). In case you are using {{AUR|mkinitcpio-tinyssh}}, you have the option of installing {{AUR|tinyssh-convert}} or {{AUR|tinyssh-convert-git}} so you can use the same keys as your {{Pkg|openssh}} installation (currently only Ed25519 keys). In either case, you should have run [[Secure_Shell#Daemon_management|the ssh daemon]] at least once, using the provided systemd units, so the keys can be generated first. After rebooting the machine, you should be prompted for the passphrase to unlock the root device. Afterwards, the system will complete its boot process and you can ssh to it [[Secure_Shell#Client usage|as you normally would]] (with the remote user of your choice).<br />
<br />
{{Tip|1=If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}}) remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].}}<br />
<br />
=== Remote unlock via wifi (hooks: build your own) ===<br />
<br />
The net hook is normally used with an ethernet connection. In case you want to setup a computer with wireless only, and unlock it via wifi, you can create a custom hook to connect to a wifi network before the net hook is run.<br />
<br />
Below example shows a setup using a usb wifi adapter, connecting to a wifi network protected with WPA2-PSK. In case you use for example WEP or another boot loader, you might need to change some things.<br />
<br />
# Modify {{ic|/etc/mkinitcpio.conf}}:<br />
#* Add the needed kernel module for your specific wifi adatper.<br />
#* Include the {{ic|wpa_passphrase}} and {{ic|wpa_supplicant}} binaries.<br />
#* Add a hook {{ic|wifi}} (or a name of your choice, this is the custom hook that will be created) before the {{ic|net}} hook.{{bc|1=MODULES=(''module'')<br>BINARIES=(wpa_passphrase wpa_supplicant)<br>HOOKS=(base udev autodetect ... '''wifi''' net ... dropbear encryptssh ...)}}<br />
# Create the {{ic|wifi}} hook in {{ic|/etc/initcpio/hooks/wifi}}:{{bc|run_hook ()<br>{<br>&#09;# sleep a couple of seconds so wlan0 is setup by kernel<br>&#09;sleep 5<br><br>&#09;# set wlan0 to up<br>&#09;ip link set wlan0 up<br><br>&#09;# assocciate with wifi network<br>&#09;# 1. save temp config file<br>&#09;wpa_passphrase "''network ESSID''" "''pass phrase''" > /tmp/wifi<br><br>&#09;# 2. assocciate<br>&#09;wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi<br><br>&#09;# sleep a couple of seconds so that wpa_supplicant finishes connecting<br>&#09;sleep 5<br><br>&#09;# wlan0 should now be connected and ready to be assigned an ip by the net hook<br>}<br><br>run_cleanuphook ()<br>{<br>&#09;# kill wpa_supplicant running in the background<br>&#09;killall wpa_supplicant<br><br>&#09;# set wlan0 link down<br>&#09;ip link set wlan0 down<br><br>&#09;# wlan0 should now be fully disconnected from the wifi network<br>}|}}<br />
# Create the hook installation file in {{ic|/etc/initcpio/install/wifi}}:{{bc|build ()<br>{<br>&#09;add_runscript<br>}<br>help ()<br>{<br>cat<<HELPEOF<br>&#09;Enables wifi on boot, for dropbear ssh unlocking of disk.<br>HELPEOF<br>}|}}<br />
# Add {{ic|1=ip=:::::wlan0:dhcp}} to the [[kernel parameters]]. Remove {{ic|1=ip=:::::eth0:dhcp}} so it does not conflict.<br />
# Optionally create an additional boot entry with kernel parameter {{ic|1=ip=:::::eth0:dhcp}}.<br />
# [[Regenerate the initramfs]].<br />
# Update the configuration of your [[boot loader]].<br />
<br />
Remember to setup [[wifi]], so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.<br />
<br />
== Discard/TRIM support for solid state drives (SSD) ==<br />
<br />
[[Solid State Drive]] users should be aware that, by default, TRIM commands are not enabled by the device-mapper, i.e. block-devices are mounted without the {{ic|discard}} option unless you override the default. <br />
<br />
The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications.[http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html][http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html] Minimal data leakage in the form of freed block information, perhaps sufficient to determine the filesystem in use, may occur on devices with TRIM enabled. An illustration and discussion of the issues arising from activating TRIM is available in the [http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html blog] of a ''cryptsetup'' developer. If you are worried about such factors, keep also in mind that threats may add up: for example, if your device is still encrypted with the previous (cryptsetup <1.6.0) default cipher {{ic|--cipher aes-cbc-essiv}}, more information leakage may occur from trimmed sector observation than with the current [[dm-crypt/Device encryption#Encryption options for LUKS mode|default]]. <br />
<br />
The following cases can be distinguished:<br />
<br />
* The device is encrypted with default dm-crypt LUKS mode:<br />
** By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects cryptsetup FAQ, section 5.19 What about SSDs, Flash and Hybrid Drives?] and [https://www.reddit.com/r/archlinux/comments/2f370s/full_disk_encryption_on_an_ssd/ck5p5c5 Full disk encryption on an ssd]. <br />
** TRIM can be left disabled if the security issues stated at the top of this section are considered a worse threat than the above bullet.<br />
: See also [[Securely wipe disk#Flash memory]].<br />
* The device is encrypted with dm-crypt plain mode, or the LUKS header is stored [[#Encrypted system using a detached LUKS header|separately]]:<br />
** If plausible deniability is required, TRIM should '''never''' be used because of the considerations at the top of this section, or the use of encryption will be given away.<br />
** If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.<br />
<br />
{{Warning|Before enabling TRIM on a drive, make sure the device fully supports TRIM commands, or data loss can occur. See [[Solid State Drives#TRIM]].}}<br />
<br />
In {{Pkg|linux}} 3.1 and up, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add {{ic|:allow-discards}} to the {{ic|cryptdevice}} option. The TRIM option may look like this:<br />
<br />
cryptdevice=/dev/sdaX:root:allow-discards<br />
<br />
For the main {{ic|cryptdevice}} configuration options before the {{ic|:allow-discards}} see [[Dm-crypt/System configuration]].<br />
<br />
If you are using a systemd based initrd, you must pass:<br />
<br />
rd.luks.options=discard<br />
<br />
{{Note|The {{ic|1=rd.luks.options=discard}} kernel option does not have any effect on devices included in the initramfs image's {{ic|/etc/crypttab}} file ({{ic|/etc/crypttab.initramfs}} on real root). You must specify option {{ic|discard}} in {{ic|/etc/crypttab.initramfs}}.}}<br />
<br />
Besides the kernel option, it is also required to periodically run {{ic|fstrim}} or mount the filesystem (e.g. {{ic|/dev/mapper/root}} in this example) with the {{ic|discard}} option in {{ic|/etc/fstab}}. For details, please refer to the [[TRIM]] page.<br />
<br />
For LUKS devices unlocked via {{ic|/etc/crypttab}} use option {{ic|discard}}, e.g.:<br />
<br />
{{hc|/etc/crypttab|<br />
2=luks-123abcdef-etc UUID=123abcdef-etc none discard}}<br />
<br />
When manually unlocking devices on the console use {{ic|--allow-discards}}.<br />
<br />
With LUKS2 you can set {{ic|allow-discards}} as a default flag for a device by opening it once with the option {{ic|--persistent}}:<br />
<br />
# cryptsetup --allow-discards --persistent open --type luks2 /dev/sdaX root<br />
<br />
You can confirm the flag is persistently set in the LUKS2 header by looking at the {{ic|cryptsetup luksDump}} output:<br />
<br />
{{hc|# cryptsetup luksDump /dev/sdaX {{!}} grep Flags|<br />
Flags: allow-discards<br />
}}<br />
<br />
In any case, you can verify whether the device actually was opened with discards by inspecting the {{ic|dmsetup table}} output:<br />
<br />
{{hc|# dmsetup table|<br />
luks-123abcdef-etc: 0 1234567 crypt aes-xts-plain64 000etc000 0 8:2 4096 1 allow_discards<br />
}}<br />
<br />
== The encrypt hook and multiple disks ==<br />
<br />
{{Tip|{{ic|sd-encrypt}} hook supports unlocking multiple devices. They can be specified on the kernel command line or in {{ic|/etc/crypttab.initramfs}}. See [[dm-crypt/System configuration#Using sd-encrypt hook]].}}<br />
<br />
The {{ic|encrypt}} hook only allows for a '''single''' {{ic|1=cryptdevice=}} entry ({{Bug|23182}}). In system setups with multiple drives this may be limiting, because ''dm-crypt'' has no feature to exceed the physical device. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS mapper. This is perfectly fine for a single-drive system, since there is only one device to decrypt. But what happens when you want to increase the size of the LVM? You cannot, at least not without modifying the {{ic|encrypt}} hook.<br />
<br />
The following sections briefly show alternatives to overcome the limitation. The first deals with how to expand a [[Dm-crypt/Encrypting_an_entire_system#LUKS_on_LVM|LUKS on LVM]] setup to a new disk. The second with modifying the {{ic|encrypt}} hook to unlock multiple disks in LUKS setups without LVM.<br />
<br />
=== Expanding LVM on multiple disks ===<br />
<br />
The management of multiple disks is a basic [[LVM]] feature and a major reason for its partitioning flexibility. It can also be used with ''dm-crypt'', but only if LVM is employed as the first mapper. In such a [[dm-crypt/Encrypting an entire system#LUKS_on_LVM|LUKS on LVM]] setup the encrypted devices are created inside the logical volumes (with a separate passphrase/key per volume). The following covers the steps to expand that setup to another disk. <br />
<br />
{{Warning|Back up! While resizing filesystems may be standard, keep in mind that operations '''may''' go wrong and the following might not apply to a particular setup. Generally, extending a filesystem to free disk space is less problematic than shrinking one. This in particular applies when stacked mappers are used, as it is the case in the following example.}}<br />
<br />
==== Adding a new drive ====<br />
<br />
First, it may be desired to prepare a new disk according to [[dm-crypt/Drive preparation]]. <br />
Second, it is partitioned as a LVM, e.g. all space is allocated to {{ic|/dev/sdY1}} with partition type {{ic|8E00}} (Linux LVM). <br />
Third, the new disk/partition is attached to the existing LVM volume group, e.g.:<br />
<br />
# pvcreate /dev/sdY1<br />
# vgextend MyStorage /dev/sdY1<br />
<br />
==== Extending the logical volume ====<br />
<br />
For the next step, the final allocation of the new diskspace, the logical volume to be extended has to be unmounted. It can be performed for the {{ic|cryptdevice}} root partition, but in this case the procedure has to be performed from an Arch Install ISO. <br />
<br />
In this example, it is assumed that the logical volume for {{ic|/home}} (lv-name {{ic|homevol}}) is going to be expanded with the fresh disk space: <br />
<br />
# umount /home<br />
# fsck /dev/mapper/home<br />
# cryptsetup luksClose /dev/mapper/home<br />
# lvextend -l +100%FREE MyStorage/homevol<br />
<br />
Now the logical volume is extended and the LUKS container comes next: <br />
<br />
# cryptsetup open /dev/mapper/MyStorage-homevol home<br />
# umount /home # as a safety, in case it was automatically remounted<br />
# cryptsetup --verbose resize home<br />
<br />
Finally, the filesystem itself is resized: <br />
<br />
# e2fsck -f /dev/mapper/home<br />
# resize2fs /dev/mapper/home<br />
<br />
Done! If it went to plan, {{ic|/home}} can be remounted and now includes the span to the new disk:<br />
<br />
# mount /dev/mapper/home /home<br />
<br />
Note that the {{ic|cryptsetup resize}} action does not affect encryption keys, and these have not changed.<br />
<br />
=== Modifying the encrypt hook for multiple partitions ===<br />
<br />
==== Root filesystem spanning multiple partitions ====<br />
<br />
It is possible to modify the encrypt hook to allow multiple hard drive decrypt root ({{ic|/}}) at boot. One way:<br />
<br />
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2<br />
# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2<br />
# sed -i "s/cryptdevice/cryptdevice2/" /etc/initcpio/hooks/encrypt2<br />
# sed -i "s/cryptkey/cryptkey2/" /etc/initcpio/hooks/encrypt2<br />
<br />
Add {{ic|1=cryptdevice2=}} to your boot options (and {{ic|1=cryptkey2=}} if needed), and add the {{ic|encrypt2}} hook to your [[mkinitcpio.conf]] before rebuilding it. See [[dm-crypt/System configuration]].<br />
<br />
==== Multiple non-root partitions ====<br />
<br />
Maybe you have a requirement for using the {{ic|encrypt}} hook on a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/dev/sd*}} partition, the second to the name you want to attribute). That should be enough.<br />
<br />
The big advantage is you can have everything automated, while setting up {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{pkg|cryptsetup}} package gets upgraded, you will have to change this script again. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
{{Accuracy|Why not use the supported Grub2 right away? See also [[mkinitcpio#Using RAID]]}} <br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
<br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup. [[GRUB]] can handle multiple array definitions just fine:<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
== Encrypted system using a detached LUKS header ==<br />
<br />
This example follows the same setup as in [[dm-crypt/Encrypting an entire system#Plain dm-crypt]], which should be read first before following this guide.<br />
<br />
By using a detached header the encrypted blockdevice itself only carries encrypted data, which gives [[Wikipedia:Deniable encryption|deniable encryption]] as long as the existence of a header is unknown to the attackers. It is similar to using [[dm-crypt/Encrypting an entire system#Plain_dm-crypt|plain dm-crypt]], but with the LUKS advantages such as multiple passphrases for the masterkey and key derivation. Further, using a detached header offers a form of two factor authentication with an easier setup than [[#Using GPG, LUKS, or OpenSSL Encrypted Keyfiles|using GPG or OpenSSL encrypted keyfiles]], while still having a built-in password prompt for multiple retries. See [[Disk encryption#Cryptographic metadata]] for more information.<br />
<br />
See [[dm-crypt/Device encryption#Encryption options for LUKS mode]] for encryption options before performing the first step to setup the encrypted system partition and creating a header file to use with {{ic|cryptsetup}}:<br />
<br />
# dd if=/dev/zero of=header.img bs=4M count=1 conv=notrunc<br />
# cryptsetup luksFormat --type luks2 /dev/sdX --align-payload 8192 --header header.img<br />
<br />
{{Tip|When using option {{ic|--header}}, {{ic|--align-payload}} allows specifying the start of encrypted data on a device. By reserving a space at the beginning of device you have the option of later [[dm-crypt/Device encryption#Restore using cryptsetup|reattaching the LUKS header]]. See {{man|8|cryptsetup}} for values supported by {{ic|--align-payload}}.}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open --header header.img /dev/sdX enc<br />
<br />
Now follow the [[dm-crypt/Encrypting an entire system#Preparing the non-boot partitions|LVM on LUKS setup]] to your requirements. The same applies for [[dm-crypt/Encrypting an entire system#Preparing the boot partition 4|preparing the boot partition]] on the removable device (because if not, there is no point in having a separate header file for unlocking the encrypted disk).<br />
Next move the {{ic|header.img}} onto it:<br />
<br />
# mv header.img /mnt/boot<br />
<br />
Follow the installation procedure up to the mkinitcpio step (you should now be {{ic|arch-chroot}}ed inside the encrypted system). <br />
<br />
{{Tip|1=You will notice that since the system partition only has "random" data, it does not have a partition table and by that an {{ic|UUID}} or a {{ic|LABEL}}. But you can still have a consistent mapping using the [[Persistent block device naming#by-id and by-path]]. E.g. using disk id from {{ic|/dev/disk/by-id/}}.}}<br />
<br />
There are two options for initramfs to support a detached LUKS header.<br />
<br />
=== Using systemd hook ===<br />
<br />
First create {{ic|/etc/crypttab.initramfs}} and add the encrypted device to it. The syntax is defined in {{man|5|crypttab}}<br />
<br />
{{hc|/etc/crypttab.initramfs|2=<br />
enc /dev/disk/by-id/''your-disk_id'' none header=/boot/header.img<br />
}}<br />
<br />
Modify {{ic|/etc/mkinitcpio.conf}} [[Mkinitcpio#Common_hooks|to use systemd]] and add the header to {{ic|FILES}}.<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
...<br />
FILES=('''/boot/header.img''')<br />
...<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''sd-lvm2''' filesystems fsck)<br />
...<br />
}}<br />
<br />
[[Regenerate the initramfs]] and you are done.<br />
<br />
{{Note|No cryptsetup parameters need to be passed to the kernel command line, since{{ic|/etc/crypttab.initramfs}} will be added as {{ic|/etc/crypttab}} in the initramfs. If you wish to specify them in the kernel command line see [[dm-crypt/System configuration#Using sd-encrypt hook]] for the supported options.}}<br />
<br />
=== Modifying encrypt hook ===<br />
<br />
This method shows how to modify the {{ic|encrypt}} hook in order to use a detached LUKS header. <br />
Now the {{ic|encrypt}} hook has to be modified to let {{ic|cryptsetup}} use the separate header ({{Bug|42851}}; base source and idea for these changes [https://bbs.archlinux.org/viewtopic.php?pid=1076346#p1076346 published on the BBS]). Make a copy so it is not overwritten on a [[mkinitcpio]] update:<br />
<br />
# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2<br />
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2<br />
<br />
{{hc|/etc/initcpio/hooks/encrypt2 (around line 52)|output=<br />
warn_deprecated() {<br />
echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"<br />
echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."<br />
}<br />
<br />
'''local headerFlag=false'''<br />
for cryptopt in ${cryptoptions//,/ }; do<br />
case ${cryptopt} in<br />
allow-discards)<br />
cryptargs="${cryptargs} --allow-discards"<br />
;; <br />
<b>header)<br />
cryptargs="${cryptargs} --header /boot/header.img"<br />
headerFlag=true<br />
;;</b><br />
*) <br />
echo "Encryption option '${cryptopt}' not known, ignoring." >&2 <br />
;; <br />
esac<br />
done<br />
<br />
if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then<br />
if '''$headerFlag &#124;&#124; '''cryptsetup isLuks ${resolved} >/dev/null 2>&1; then<br />
[ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated<br />
dopassphrase=1<br />
}}<br />
<br />
Now edit the [[mkinitcpio.conf]] to add the {{ic|encrypt2}} and {{ic|lvm2}} hooks, the {{ic|header.img}} to {{ic|FILES}} and the {{ic|loop}} to {{ic|MODULES}}, apart from other configuration the system requires:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
...<br />
MODULES=('''loop''')<br />
...<br />
FILES=('''/boot/header.img''')<br />
...<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt2''' '''lvm2''' filesystems fsck)<br />
...<br />
}}<br />
<br />
This is required so the LUKS header is available on boot allowing the decryption of the system, exempting us from a more complicated setup to mount another separate USB device in order to access the header. After this set up [[Mkinitcpio#Image_creation_and_activation|the initramfs]] is created.<br />
<br />
Next the [[dm-crypt/Encrypting an entire system#Configuring the boot loader 4|boot loader is configured]] to specify the {{ic|1=cryptdevice=}} also passing the new {{ic|header}} option for this setup: <br />
<br />
cryptdevice=/dev/disk/by-id/''your-disk_id'':enc:header<br />
<br />
To finish, following [[dm-crypt/Encrypting an entire system#Post-installation]] is particularly useful with a {{ic|/boot}} partition on an USB storage medium.<br />
<br />
== Encrypted /boot and a detached LUKS header on USB ==<br />
<br />
Rather than embedding the {{ic|header.img}} and keyfile into the [[initramfs]] image, this setup will make your system depend entirely on the usb key rather than just the image to boot, and on the encrypted keyfile inside of the encrypted boot partition. Since the header and keyfile are not included in the [[initramfs]] image and the custom encrypt hook is specifically for the usb's [[Persistent_block_device_naming#by-id_and_by-path|by-id]], you will literally need the usb key to boot.<br />
<br />
For the usb drive, since you are encrypting the drive and the keyfile inside, it is preferred to cascade the ciphers as to not use the same one twice. Whether a [[Wikipedia:Meet-in-the-middle_attack|meet-in-the-middle]] attack would actually be feasible is debatable. You can do twofish-serpent or serpent-twofish.<br />
<br />
=== Preparing the disk devices ===<br />
<br />
{{ic|sdb}} will be assumed to be the USB drive, {{ic|sda}} will be assumed to be the main hard drive.<br />
<br />
Prepare the devices according to [[dm-crypt/Drive preparation]].<br />
<br />
==== Preparing the USB key ====<br />
<br />
Use [[fdisk#gdisk|gdisk]] to partition the disk according to the layout [[Dm-crypt/Encrypting_an_entire_system#Preparing_the_disk_5|shown here]], with the exception that it should only include the first two partitions. So as follows:<br />
<br />
{{hc|# gdisk /dev/sdb|<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 1050623 512.0 MiB EF00 EFI System<br />
2 1050624 1460223 200.0 MiB 8300 Linux filesystem<br />
}}<br />
<br />
Before running {{ic|cryptsetup}}, look at the [[Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode|Encryption options for LUKS mode]] and [[Disk_encryption#Ciphers_and_modes_of_operation|Ciphers and modes of operation]] first to select your desired settings.<br />
<br />
[[Dm-crypt/Encrypting_an_entire_system#Preparing_the_boot_partition_5|Prepare the boot partition]] but don't {{ic|mount}} any partition yet and [[EFI_System_Partition#Format_the_partition|Format the EFI System Partition]].<br />
<br />
# mount /dev/mapper/cryptboot /mnt<br />
# dd if=/dev/urandom of=/mnt/key.img bs=''filesize'' count=1<br />
# cryptsetup --align-payload=1 luksFormat /mnt/key.img<br />
# cryptsetup open /mnt/key.img lukskey<br />
<br />
''filesize'' is in bytes but can be followed by a suffix such as {{ic|M}}. Having too small of a file will get you a nasty {{ic|Requested offset is beyond real size of device /dev/loop0}} error. As a rough reference, creating a 4M file will encrypt it successfully. You should make the file larger than the space needed since the encrypted loop device will be a little smaller than the file's size.<br />
<br />
With a big file, you can use {{ic|1=--keyfile-offset=''offset''}} and {{ic|1=--keyfile-size=''size''}} to navigate to the correct position. [https://wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile]<br />
<br />
Now you should have {{ic|lukskey}} opened in a loop device (underneath {{ic|/dev/loop1}}), mapped as {{ic|/dev/mapper/lukskey}}.<br />
<br />
==== The main drive ====<br />
<br />
# truncate -s 2M /mnt/header.img<br />
# cryptsetup --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' luksFormat /dev/sda --align-payload 4096 --header /mnt/header.img<br />
<br />
Pick an ''offset'' and ''size'' in bytes (8192 bytes is the maximum keyfile size for {{ic|cryptsetup}}).<br />
<br />
# cryptsetup open --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' /dev/sda enc <br />
# cryptsetup close lukskey<br />
# umount /mnt<br />
<br />
Follow [[Dm-crypt/Encrypting_an_entire_system#Preparing_the_logical_volumes|Preparing the logical volumes]] to set up LVM on LUKS.<br />
<br />
See [[Partitioning#Discrete partitions]] for recommendations on the size of your partitions.<br />
<br />
Once your root partition is mounted, {{ic|mount}} your encrypted boot partition as {{ic|/mnt/boot}} and your ESP or EFI partition as {{ic|/mnt/boot/efi}}.<br />
<br />
=== Installation procedure and custom encrypt hook ===<br />
<br />
Follow the [[installation guide]] up to the {{ic|mkinitcpio}} step but do not do it yet, and skip the partitioning, formatting, and mounting steps as they have already been done.<br />
<br />
In order to get the encrypted setup to work, you need to build your own hook, which is thankfully easy to do and here is the code you need. You will have to follow [[Persistent block device naming#by-id and by-path]] to figure out your own {{ic|by-id}} values for the usb and main hard drive (they are linked -> to {{ic|sda}} or {{ic|sdb}}).<br />
<br />
You should be using the {{ic|by-id}} instead of just {{ic|sda}} or {{ic|sdb}} because {{ic|sdX}} can change and this ensures it is the correct device.<br />
<br />
You can name {{ic|customencrypthook}} anything you want, and custom build hooks can be placed in the {{ic|hooks}} and {{ic|install}} folders of {{ic|/etc/initcpio}}. Keep a backup of both files ({{ic|cp}} them over to the {{ic|/home}} partition or your user's {{ic|/home}} directory after you make one). {{ic|/usr/bin/ash}} is not a typo.<br />
<br />
{{hc|/etc/initcpio/hooks/customencrypthook|output=<nowiki><br />
#!/usr/bin/ash<br />
<br />
run_hook() {<br />
modprobe -a -q dm-crypt >/dev/null 2>&1<br />
modprobe loop<br />
[ "${quiet}" = "y" ] && CSQUIET=">/dev/null"<br />
<br />
while [ ! -L '/dev/disk/by-id/</nowiki>''usbdrive''<nowiki>-part2' ]; do<br />
echo 'Waiting for USB'<br />
sleep 1<br />
done<br />
<br />
cryptsetup open /dev/disk/by-id/</nowiki>''usbdrive''<nowiki>-part2 cryptboot<br />
mkdir -p /mnt<br />
mount /dev/mapper/cryptboot /mnt<br />
cryptsetup open /mnt/key.img lukskey<br />
cryptsetup --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' open /dev/disk/by-id/</nowiki>''harddrive''<nowiki> enc<br />
cryptsetup close lukskey<br />
umount /mnt<br />
}<br />
</nowiki>}}<br />
<br />
{{ic|''usbdrive''}} is your USB drive {{ic|by-id}}, and {{ic|''harddrive''}} is your main hard drive {{ic|by-id}}.<br />
<br />
{{Tip|You could also close {{ic|cryptboot}} using {{ic|cryptsetup close}}, but having it open makes it easier to mount for system updates using [[Pacman]] and regenerating the initramfs with [[mkinitcpio]]. The {{ic|/boot}} partition must be mounted for updates that affect the [[kernel]] or [[Initramfs]], and the initramfs will be automatically regenerated after these updates.}}<br />
<br />
# cp /usr/lib/initcpio/install/encrypt /etc/initpcio/install/customencrypthook<br />
<br />
Now edit the copied file and remove the {{ic|help()}} section as it is not necessary.<br />
<br />
{{hc|/etc/mkinitcpio.conf (edit this only do not replace it, these are just excerpts of the necessary parts)|output=<br />
MODULES=(loop)<br />
...<br />
HOOKS=(base udev autodetect modconf block customencrypthook lvm2 filesystems keyboard fsck)<br />
}}<br />
<br />
The {{ic|1=files=()}} and {{ic|1=binaries=()}} arrays are empty, and you should not have to replace {{ic|1=HOOKS=(...)}} array entirely just edit in {{ic|customencrypthook lvm2}} after {{ic|block}} and before {{ic|filesystems}}, and make sure {{ic|systemd}}, {{ic|sd-lvm2}}, and {{ic|encrypt}} are removed.<br />
<br />
==== Boot Loader ====<br />
<br />
Finish the [[Installation_guide#Initramfs|Installation Guide]] from the {{ic|mkinitcpio}} step. To boot you would need either [[GRUB]] or [[efibootmgr]]. Note you can use [[GRUB]] to support the encrypted disks by [[Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader_6|Configuring the boot loader]] but editing the {{ic|GRUB_CMDLINE_LINUX}} is not necessary for this set up.<br />
<br />
Or use Direct UEFI Secure boot by generating keys with {{AUR|cryptboot}} then signing the initramfs and kernel and creating a bootable .efi file for your {{ic|/boot/efi}} directory with {{AUR|sbupdate-git}}. Before using cryptboot or sbupdate note this excerpt from [[Secure Boot#Using your own keys]]:<br />
<br />
{{Tip|Note that {{AUR|cryptboot}} requires the encrypted boot partition to be specified in {{ic|/etc/crypttab}} before it runs, and if you are using it in combination with {{AUR|sbupdate-git}}, sbupdate expects the {{ic|/boot/efikeys/db.*}} files created by cryptboot to be capitalized like {{ic|DB.*}} unless otherwise configured in {{ic|/etc/default/sbupdate}}. Users who do not use systemd to handle encryption may not have anything in their {{ic|/etc/crypttab}} file and would need to create an entry.<br />
}}<br />
<br />
# efibootmgr -c -d /dev/''device'' -p ''partition_number'' -L "Arch Linux Signed" -l "EFI\Arch\linux-signed.efi"<br />
<br />
See {{man|8|efibootmgr}} for an explanation of the options.<br />
<br />
Make sure the boot order puts {{ic|Arch Linux Signed}} first. If not change it with {{ic|efibootmgr -o XXXX,YYYY,ZZZZ}}.<br />
<br />
=== Changing the LUKS keyfile ===<br />
<br />
{{Merge|dm-crypt/Device encryption#Keyfiles|Changing the keyfile is not a required action in this setup.}}<br />
<br />
# cryptsetup --header /boot/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' luksChangeKey /dev/mapper/enc /dev/mapper/lukskey2 --new-keyfile-size=''newsize'' --new-keyfile-offset=''newoffset''<br />
<br />
Afterwards, {{ic|cryptsetup close lukskey}} and [[Securely_wipe_disk#shred|shred]] or [[Securely_wipe_disk#dd|dd]] the old keyfile with random data before deleting it, then make sure that the new keyfile is renamed to the same name of the old one: {{ic|key.img}} or other name.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:LVM&diff=518342Talk:LVM2018-04-22T22:13:52Z<p>Wincraft71: /* /dev/mapper/* */ re</p>
<hr />
<div>== systemd services ==<br />
<br />
{{pkg|lvm2}} has lvm2-lvmetad.service, lvm2-monitor.service, and lvm2-pvscan@.service. Those should probably be listed with explanations of what they do, and what effects there are from having or not having them running. The wiki does mention lvmetad in the context of its conf file, but not as a systemd service to consider enabling. (Could also mention use_lvmetad = 0 in conf if you don't want it.) [[User:Jamespharvey20|Jamespharvey20]] ([[User talk:Jamespharvey20|talk]]) 21:38, 28 July 2015 (UTC)<br />
<br />
:Yes, yes, YES! A million times YES. I've just spent hours figuring out why my system would hang for 90 seconds on reboot/shutdown. I had a setup with LVM on LUKS where a number of moving parts could be causing it (and were causing it for other people at one point or another) until I figured out... heh... let's leave LUKS out of the picture since it seems to be the culprit and things were working fine. Until I decided to create snapshots of my LVM volumes today before performing a system update and... TADA! It started hanging on reboot/shutdown again. Again, I had a million moving parts that could have been causing it (it's a fresh system that I'm still setting up) and it turns out all I needed was to enable lvm2-monitor... sadly I didn't scroll all the way to the bottom of this wiki page to figure out this could be a problem. I definitely vote to make this a more prominent topic... I don't know if this only affects me but it might be unsuspectingly affecting more people and both degrading their perception of their Arch install as well as getting some data loss. [[User:Tiago|Tiago]] ([[User talk:Tiago|talk]]) 19:10, 1 May 2017 (UTC)<br />
<br />
::As you discovered, the issue is already documented in the Troubleshooting section - [[LVM#Delay on shutdown]]. There's no point in making it more prominent, since manually enabling {{ic|lvm2-monitor.service}} should not be the standard practice, it should be enabled by default in {{Pkg|lvm2}}. Vote on {{Bug|50420}} and hope the devs will fix it. (Or contact them directly.) -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 07:04, 2 May 2017 (UTC)<br />
<br />
:::Good point, it didn't occur to me that {{ic|lvm2-monitor.service}} should be on by default, but reading that bug report makes me really scared that unsuspecting LVM users out there are running their LVM systems without the monitor enabled... Let's just hope the bug gets fixed soon and nobody gets hurt in the process (I upvoted the bug report). --[[User:Tiago|Tiago]] ([[User talk:Tiago|talk]]) 19:57, 2 May 2017 (UTC)<br />
<br />
== Move physical extents ==<br />
<br />
Ok, I'm confused. This section mentions 92468, 92467 and 92466 PEs. There may be more than one off-by-one error going on here.<br />
<br />
Which of these is correct? [[User:Ataraxy|Ataraxy]] ([[User talk:Ataraxy|talk]]) 10:35, 28 October 2016 (UTC)Ataraxy<br />
<br />
== Logical volume types ==<br />
<br />
This section says we should discuss Thin Provisioning here....<br />
<br />
Go! [[User:Ataraxy|Ataraxy]] ([[User talk:Ataraxy|talk]]) 10:47, 28 October 2016 (UTC)Ataraxy<br />
<br />
== Create physical volumes ==<br />
<br />
It is written that -<br />
"If LVM has to be set on the entire disk, there is no need to create any partitions", and also "DEVICE can be '''a disk''' or a partition",<br />
but I think it is worth mentioning somewhere in this wiki that GRUB cannot be installed on a disk with LVM installed on it as a whole (see [https://bbs.archlinux.org/viewtopic.php?id=214315 grub-install with LVM on entire disk]). Any thoughts?<br />
[[User:Duduedri96|Duduedri96]] ([[User talk:Duduedri96|talk]]) 22:57, 30 November 2016 (UTC)<br />
<br />
== /dev/mapper/* ==<br />
<br />
While reading {{man|8|lvm|VALID_NAMES}}, I noticed: "Links or nodes in /dev/mapper are intended only for internal use and the precise format and escaping might change between releases and distributions. Other software and scripts should use the /dev/VolumeGroupName/LogicalVolumeName format to reduce the chance of needing amendment when the software is updated."<br />
<br />
I've been changing {{ic|/dev/VolumeGroupName/LogicalVolumeName}} to {{ic|/dev/mapper/VolumeGroupName-LogicalVolumeName}} since I don't like that the volume group dirs are directly under {{ic|/dev/}} instead of inside a common subdir. Should we change the paths used in the wiki to use {{ic|/dev/VolumeGroupName/LogicalVolumeName}} or just leave them as they are? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 06:21, 22 April 2018 (UTC)<br />
<br />
:I vote for {{ic|/dev/VolGroup/LogicalVol}} just because it's easier to type and looks better, in my opinion. However, I am a little confused because it seems that people often use {{ic|/dev/mapper}} in their {{ic|/etc/fstab}} files. Although that could be considered "internal use"? We should identify which parts of the wiki are considered "other software and scripts". -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 22:13, 22 April 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=LVM&diff=518333LVM2018-04-22T20:15:02Z<p>Wincraft71: /* Create logical volumes */ There are a few exceptions to what you can name a logical volume. Reworded sentence.</p>
<hr />
<div>[[Category:Storage virtualization]]<br />
[[cs:LVM]]<br />
[[de:LVM]]<br />
[[es:LVM]]<br />
[[fr:LVM]]<br />
[[it:LVM]]<br />
[[ja:LVM]]<br />
[[ru:LVM]]<br />
[[zh-hans:LVM]]<br />
{{Related articles start}}<br />
{{Related|Software RAID and LVM}}<br />
{{Related|dm-crypt/Encrypting an entire system#LVM on LUKS}}<br />
{{Related|dm-crypt/Encrypting an entire system#LUKS on LVM}}<br />
{{Related|Resizing LVM-on-LUKS}}<br />
{{Related|Create root filesystem snapshots with LVM}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Logical Volume Manager (Linux)]]:<br />
:LVM is a [[Wikipedia:logical volume management|logical volume manager]] for the [[Wikipedia:Linux kernel|Linux kernel]]; it manages disk drives and similar mass-storage devices.<br />
<br />
== LVM Building Blocks ==<br />
<br />
Logical Volume Management utilizes the kernel's [http://sources.redhat.com/dm/ device-mapper] feature to provide a system of partitions independent of underlying disk layout. With LVM you abstract your storage and have "virtual partitions", making [[#Resizing volumes|extending/shrinking]] easier (subject to potential filesystem limitations).<br />
<br />
Virtual partitions allow addition and removal without worry of whether you have enough contiguous space on a particular disk, getting caught up fdisking a disk in use (and wondering whether the kernel is using the old or new partition table), or, having to move other partitions out of the way. This is strictly an ease-of-management solution: LVM adds no security.<br />
<br />
Basic building blocks of LVM:<br />
<br />
; Physical volume (PV): Partition on hard disk (or even the disk itself or loopback file) on which you can have volume groups. It has a special header and is divided into physical extents. Think of physical volumes as big building blocks used to build your hard drive.<br />
; Volume group (VG): Group of physical volumes used as a storage volume (as one disk). They contain logical volumes. Think of volume groups as hard drives.<br />
; Logical volume (LV): A "virtual/logical partition" that resides in a volume group and is composed of physical extents. Think of logical volumes as normal partitions.<br />
; Physical extent (PE): The smallest size in the physical volume that can be assigned to a logical volume (default 4 MiB). Think of physical extents as parts of disks that can be allocated to any partition.<br />
<br />
Example:<br />
'''Physical disks'''<br />
<br />
Disk1 (/dev/sda):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 50 GiB (Physical volume) |Partition2 80 GiB (Physical volume) |<br />
|/dev/sda1 |/dev/sda2 |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |<br />
<br />
Disk2 (/dev/sdb):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 120 GiB (Physical volume) |<br />
|/dev/sdb1 |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
<br />
'''LVM logical volumes'''<br />
<br />
Volume Group1 (/dev/MyStorage/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Logical volume1 15 GiB |Logical volume2 35 GiB |Logical volume3 200 GiB |<br />
|/dev/MyStorage/rootvol |/dev/MyStorage/homevol |/dev/MyStorage/mediavol |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
<br />
== Advantages ==<br />
<br />
LVM gives you more flexibility than just using normal hard drive partitions:<br />
<br />
* Use any number of disks as one big disk.<br />
* Have logical volumes stretched over several disks.<br />
* Create small logical volumes and resize them "dynamically" as they get filled up.<br />
* Resize logical volumes regardless of their order on disk. It does not depend on the position of the LV within VG, there is no need to ensure surrounding available space.<br />
* Resize/create/delete logical and physical volumes online. File systems on them still need to be resized, but some (such as ext4) support online resizing.<br />
* Online/live migration of LV being used by services to different disks without having to restart services.<br />
* Snapshots allow you to backup a frozen copy of the file system, while keeping service downtime to a minimum.<br />
* Support for various device-mapper targets, including transparent filesystem encryption and caching of frequently used data. This allows creating a system with (one or more) physical disks (encrypted with LUKS) and [[dm-crypt/Encrypting an entire system#LVM on LUKS|LVM on top]] to allow for easy resizing and management of separate volumes (e.g. for {{ic|/}}, {{ic|/home}}, {{ic|/backup}}, etc.) without the hassle of entering a key multiple times on boot.<br />
<br />
== Disadvantages ==<br />
<br />
* Additional steps in setting up the system, more complicated.<br />
* If dual-booting, note that Windows does not support LVM; you will be unable to access any LVM partitions from Windows.<br />
<br />
== Installing Arch Linux on LVM ==<br />
<br />
You should create your LVM Volumes between the [[partitioning]] and [[File systems#Create a file system|formatting]] steps of the [[Installation guide|installation procedure]]. Instead of directly formatting a partition to be your root file system, the file system will be created inside a logical volume (LV). <br />
<br />
Make sure the {{pkg|lvm2}} package is [[installed]].<br />
<br />
Quick overview: <br />
<br />
* Create [[Partitioning|partition(s)]] where your PV(s) will reside.<br />
** If you use Master Boot Record partition table, set the [[Wikipedia:Partition type|partition type ID]] to {{ic|8e}} (partition type {{ic|Linux LVM}} in ''fdisk'').<br />
** If you use GUID Partition Table, set the [[Wikipedia:GUID Partition Table#Partition type GUIDs|partition type GUID]] to {{ic|E6D6D379-F507-44C2-A23C-238F2A3DF928}} (partition type {{ic|Linux LVM}} in ''fdisk'' and {{ic|8e00}} in ''gdisk'').<br />
* Create your physical volumes (PVs). If you have one disk it is best to just create one PV in one large partition. If you have multiple disks you can create partitions on each of them and create a PV on each partition.<br />
* Create your volume group (VG) and add all PVs to it.<br />
* Create logical volumes (LVs) inside that VG.<br />
* Continue with [[Installation guide#Format the partitions]].<br />
* When you reach the “Create initial ramdisk environment” step in the Installation guide, add the {{ic|lvm}} hook to {{ic|/etc/mkinitcpio.conf}} (see below for details).<br />
<br />
{{Warning|{{ic|/boot}} cannot reside in LVM when using a boot loader which does not support LVM; you must create a separate {{ic|/boot}} partition and format it directly. Only [[GRUB]] is known to support LVM.}}<br />
<br />
=== Create partitions ===<br />
<br />
If LVM has to be set on the entire disk, there is no need to create any partitions.<br />
<br />
Otherwise, [[partition]] the device as required before configuring LVM.<br />
<br />
=== Create physical volumes ===<br />
<br />
To list all your devices capable of being used as a physical volume:<br />
<br />
# lvmdiskscan<br />
<br />
{{Warning|Make sure you target the correct device, or below commands will result in data loss!}}<br />
<br />
Create a physical volume on them:<br />
<br />
# pvcreate ''DEVICE''<br />
<br />
This command creates a header on each device so it can be used for LVM. As defined in [[#LVM Building Blocks]], ''DEVICE'' can be a disk (e.g. {{ic|/dev/sda}}), a partition (e.g. {{ic|/dev/sda2}}) or a loop back device. For example: <br />
<br />
# pvcreate /dev/sda2<br />
<br />
You can track created physical volumes with:<br />
<br />
# pvdisplay<br />
<br />
{{Note|If using a SSD without partitioning it first, use {{ic|pvcreate --dataalignment 1m /dev/sda}} (for erase block size < 1 MiB), see e.g. [http://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment here]}}<br />
<br />
=== Create volume group ===<br />
<br />
The next step is to create a volume group on this physical volume.<br />
<br />
First you need to create a volume group on one of the physical volumes:<br />
<br />
# vgcreate <''volume_group''> <''physical_volume''><br />
<br />
See {{man|8|lvm}} for a list of valid characters for volume group names.<br />
<br />
For example:<br />
<br />
# vgcreate VolGroup00 /dev/sda2<br />
<br />
Then add to it all other physical volumes you want to have in it:<br />
<br />
# vgextend <''volume_group''> <''physical_volume''><br />
# vgextend <''volume_group''> <''another_physical_volume''><br />
# ...<br />
<br />
For example:<br />
<br />
# vgextend VolGroup00 /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdc<br />
<br />
You can track how your volume group grows with:<br />
<br />
# vgdisplay<br />
<br />
{{Note|You can create more than one volume group if you need to, but then you will not have all your storage presented as one disk.}}<br />
<br />
=== Create in one step ===<br />
<br />
LVM allows you to combine the creation of a volume group and the physical volumes in one easy step. For example, to create the group VolGroup00 with the three devices mentioned above, you can run:<br />
<br />
# vgcreate VolGroup00 /dev/sda2 /dev/sdb1 /dev/sdc<br />
<br />
This command will first set up the three partitions as physical volumes (if necessary) and then create the volume group with the three volumes. The command will warn you it detects an existing filesystem on any of the devices.<br />
<br />
=== Create logical volumes ===<br />
<br />
{{Tip|If you wish to use snapshots, logical volume caching, thin provisioned logical volumes or RAID see [[#Logical volume types]].}}<br />
<br />
Now we need to create logical volumes on this volume group. You create a logical volume with the next command by giving the name of a new logical volume, its size, and the volume group it will live on:<br />
<br />
# lvcreate -L <''size''> <''volume_group''> -n <''logical_volume''><br />
<br />
For example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome<br />
<br />
This will create a logical volume that you can access later with {{ic|/dev/mapper/Volgroup00-lvolhome}} or {{ic|/dev/VolGroup00/lvolhome}}. Just like volume groups, you can use any name you want for your logical volume when creating it besides a few exceptions listed in {{man|8|lvm|VALID_NAMES}}.<br />
<br />
You can also specify one or more physical volumes to restrict where LVM allocates the data. For example, you may wish to create a logical volume for the root filesystem on your small SSD, and your home volume on a slower mechanical drive. Simply add the physical volume devices to the command line, for example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome /dev/sdc1<br />
<br />
If you want to fill all the free space left on a volume group, use the next command:<br />
<br />
# lvcreate -l 100%FREE <''volume_group''> -n <''logical_volume''><br />
<br />
You can track created logical volumes with:<br />
<br />
# lvdisplay<br />
<br />
{{Note|You may need to load the ''device-mapper'' kernel module ({{ic|modprobe dm_mod'}}) for the above commands to succeed.}}<br />
<br />
{{Tip|You can start out with relatively small logical volumes and expand them later if needed. For simplicity, leave some free space in the volume group so there is room for expansion.}}<br />
<br />
=== Create file systems and mount logical volumes ===<br />
<br />
Your logical volumes should now be located in {{ic|/dev/mapper/}} and {{ic|/dev/''YourVolumeGroupName''}}. If you cannot find them, use the next commands to bring up the module for creating device nodes and to make volume groups available:<br />
<br />
# modprobe dm_mod<br />
# vgscan<br />
# vgchange -ay<br />
<br />
Now you can create file systems on logical volumes and mount them as normal partitions (if you are installing Arch linux, refer to [[mount|mounting the partitions]] for additional details):<br />
<br />
# mkfs.<''fstype''> /dev/mapper/<''volume_group''>-<''logical_volume''><br />
# mount /dev/mapper/<''volume_group''>-<''logical_volume''> /<''mountpoint''><br />
<br />
For example:<br />
<br />
# mkfs.ext4 /dev/mapper/VolGroup00-lvolhome<br />
# mount /dev/mapper/VolGroup00-lvolhome /home<br />
<br />
{{Warning|When choosing mountpoints, just select your newly created logical volumes (use: {{ic|/dev/mapper/Volgroup00-lvolhome}}). Do '''not''' select the actual partitions on which logical volumes were created (do not use: {{ic|/dev/sda2}}).}}<br />
<br />
=== Configure mkinitcpio ===<br />
<br />
In case your root filesystem is on LVM, you will need to enable the appropriate [[mkinitcpio]] hooks, otherwise your system might not boot. Enable:<br />
<br />
* {{ic|udev}} and {{ic|lvm2}} for the default busybox based initramfs<br />
* {{ic|systemd}} and {{ic|sd-lvm2}} for systemd based initramfs<br />
<br />
{{ic|udev}} is there by default. Edit the file and insert {{ic|lvm2}} between {{ic|block}} and {{ic|filesystems}} like so:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=<br />
HOOKS=(base '''udev''' ... block '''lvm2''' filesystems)<br />
}}<br />
<br />
For systemd based initramfs:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=<br />
HOOKS=(base '''systemd''' ... block '''sd-lvm2''' filesystems)<br />
}}<br />
<br />
Afterwards, you can continue in normal installation instructions with the [[mkinitcpio#Image creation and activation|create an initial ramdisk]] step.<br />
<br />
{{Tip|<br />
* The {{ic|lvm2}} and {{ic|sd-lvm2}} hooks are installed by {{pkg|lvm2}}, not {{pkg|mkinitcpio}}. If you are running ''mkinitcpio'' in an ''arch-chroot'' for a new installation, {{pkg|lvm2}} must be installed inside the ''arch-chroot'' for ''mkinitcpio'' to find the {{ic|lvm2}} or {{ic|sd-lvm2}} hook. If {{pkg|lvm2}} only exists outside the ''arch-chroot'', ''mkinitcpio'' will output {{ic|Error: Hook 'lvm2' cannot be found}}.<br />
* If your root filesystem is on LVM RAID see [[#Configure mkinitcpio for RAID]].<br />
}}<br />
<br />
=== Kernel options ===<br />
<br />
If the root file system resides in a logical volume, the {{ic|1=root=}} [[kernel parameter]] must be pointed to the mapped device, e.g {{ic|/dev/mapper/''vg-name''-''lv-name''}}.<br />
<br />
== Volume operations ==<br />
<br />
=== Advanced options ===<br />
<br />
If you need monitoring (needed for snapshots) you can enable lvmetad. <br />
For this set {{ic|1=use_lvmetad = 1}} in {{ic|/etc/lvm/lvm.conf}}.<br />
This is the default by now. <br />
<br />
You can restrict the volumes that are activated automatically by setting the {{ic|auto_activation_volume_list}} in {{ic|/etc/lvm/lvm.conf}}. If in doubt, leave this option commented out.<br />
<br />
=== Resizing volumes ===<br />
<br />
==== Physical volumes ====<br />
<br />
After extending or prior to reducing the size of a device that has a physical volume on it, you need to grow or shrink the PV using {{ic|pvresize}}.<br />
<br />
===== Growing =====<br />
<br />
To expand the PV on {{ic|/dev/sda1}} after enlarging the [[partition]], run:<br />
<br />
# pvresize /dev/sda1<br />
<br />
This will automatically detect the new size of the device and extend the PV to its maximum.<br />
<br />
{{Note|This command can be done while the volume is online.}}<br />
<br />
===== Shrinking =====<br />
<br />
To shrink a physical volume prior to reducing its underlying device, add the {{ic|--setphysicalvolumesize ''size''}} parameters to the command, ''e.g.'':<br />
<br />
# pvresize --setphysicalvolumesize 40G /dev/sda1<br />
<br />
The above command may leave you with this error:<br />
<br />
/dev/sda1: cannot resize to 25599 extents as later ones are allocated.<br />
0 physical volume(s) resized / 1 physical volume(s) not resized<br />
<br />
Indeed {{ic|pvresize}} will refuse to shrink a PV if it has allocated extents after where its new end would be. One needs to run [[#Move physical extents|pvmove]] beforehand to relocate these elsewhere in the volume group if there is sufficient free space.<br />
<br />
====== Move physical extents ======<br />
<br />
Before moving free extents to the end of the volume, one must run {{ic|pvdisplay -v -m}} to see physical segments. In the below example, there is one physical volume on {{ic|/dev/sdd1}}, one volume group {{ic|vg1}} and one logical volume {{ic|backup}}.<br />
<br />
{{hc|# pvdisplay -v -m|<br />
Finding all volume groups.<br />
Using physical volume(s) on command line.<br />
--- Physical volume ---<br />
PV Name /dev/sdd1<br />
VG Name vg1<br />
PV Size 1.52 TiB / not usable 1.97 MiB<br />
Allocatable yes <br />
PE Size 4.00 MiB<br />
Total PE 399669<br />
Free PE 153600<br />
Allocated PE 246069<br />
PV UUID MR9J0X-zQB4-wi3k-EnaV-5ksf-hN1P-Jkm5mW<br />
<br />
--- Physical Segments ---<br />
Physical extent 0 to 153600:<br />
FREE<br />
Physical extent 153601 to 307199:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 1 to 153599<br />
Physical extent 307200 to 307200:<br />
FREE<br />
Physical extent 307201 to 399668:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 153601 to 246068<br />
}}<br />
<br />
One can observe FREE space are split across the volume. To shrink the physical volume, we must first move all used segments to the beginning.<br />
<br />
Here, the first free segment is from 0 to 153600 and leaves us with 153601 free extents. We can now move this segment number from the last physical extent to the first extent. The command will thus be:<br />
<br />
{{hc|# pvmove --alloc anywhere /dev/sdd1:307201-399668 /dev/sdd1:0-92466|<br />
/dev/sdd1: Moved: 0.1 %<br />
/dev/sdd1: Moved: 0.2 %<br />
...<br />
/dev/sdd1: Moved: 99.9 %<br />
/dev/sdd1: Moved: 100,0%<br />
}}<br />
<br />
{{Note|<br />
* this command moves 92468 PEs (399668-307200) '''from''' the last segment '''to''' the first segment. This is possible as the first segment encloses 153600 free PEs, which can contain the 92467 moved PEs.<br />
* the {{ic|--alloc anywhere}} option is used as we move PEs inside the same partition. In case of different partitions, the command would look something like this: {{bc|# pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999}}<br />
* this command may take a long time (one to two hours) in case of large volumes. It might be a good idea to run this command in a [[Tmux]] or [[GNU Screen]] session. Any unwanted stop of the process could be fatal.<br />
* once the operation is complete, run [[fsck]] to make sure your file system is valid.<br />
}}<br />
<br />
====== Resize physical volume ======<br />
<br />
Once all your free physical segments are on the last physical extent, run {{ic|vgdisplay}} and see your free PE.<br />
<br />
Then you can now run again the command:<br />
<br />
# pvresize --setphysicalvolumesize ''size'' ''PhysicalVolume''<br />
<br />
See the result:<br />
<br />
{{hc|# pvs|<br />
PV VG Fmt Attr PSize PFree <br />
/dev/sdd1 vg1 lvm2 a-- 1t 500g<br />
}}<br />
<br />
====== Resize partition ======<br />
<br />
Last, you need to shrink the partition with your favorite [[Partitioning#Partitioning tools|partitioning tool]].<br />
<br />
==== Logical volumes ====<br />
<br />
{{Note|''lvresize'' provides more or less the same options as the specialized {{ic|lvextend}} and {{ic|lvreduce}} commands, while allowing to do both types of operation. Notwithstanding this, all those utilities offer a {{ic|-r}}/{{ic|--resizefs}} option which allows to resize the file system together with the LV using {{man|8|fsadm}} (''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] supported). Therefore it may be easier to simply use {{ic|lvresize}} for both operations and use {{ic|--resizefs}} to simplify things a bit, except if you have specific needs or want full control over the process.}}<br />
<br />
===== Growing or shrinking with lvresize =====<br />
<br />
{{Warning|While enlarging a file system can often be done on-line (''i.e.'' while it is mounted), even for the root partition, shrinking will nearly always require to first unmount the file system so as to prevent data loss. Make sure your FS supports what you are trying to do.}}<br />
<br />
Extend logical volume ''lv1'' within volume group ''vg1'' by 2 GiB ''without'' touching its file system:<br />
<br />
# lvresize -L +2G vg1/lv1<br />
<br />
Reduce the size of {{ic|vg1/lv1}} by 500 MiB ''without'' resizing its file system (make sure it is [[#Resizing the file system separately|already shrunk]] in that case):<br />
<br />
# lvresize -L -500M vg1/lv1<br />
<br />
Set {{ic|vg1/lv1}} to 15 GiB and resize its file system ''all at once'':<br />
<br />
# lvresize -L 15G -r vg1/lv1<br />
<br />
{{Note|Only ''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] [[file systems]] are supported. For a different type of file system look for the [[File systems#Types of file systems|appropriate utility]].}}<br />
<br />
If you want to fill all the free space on a volume group, use the following command:<br />
<br />
# lvresize -l +100%FREE ''vg''/''lv''<br />
<br />
See {{man|8|lvresize}} for more detailed options.<br />
<br />
===== Extending the logical volume and file system in one go =====<br />
<br />
{{Merge|#Growing or shrinking with lvresize|No need to split the sections.}}<br />
<br />
{{Warning|Not all file systems support resizing without loss of data and/or resizing online.}}<br />
<br />
Extend the logical volume ''home'' in ''volume-group'' with 10 GiB<br />
<br />
# lvresize -L +10G /dev/''volume-group''/''home'' --resizefs<br />
<br />
Alternatively with a XFS filesystem<br />
<br />
# lvextend -L+10G /dev/''volume-group''/''home''<br />
# xfs_growfs /home<br />
<br />
Note: ''xfs_growfs'' takes a mount point as argument. See {{man|8|xfs_growfs}} for more detailed options.<br />
<br />
===== Resizing the file system separately =====<br />
<br />
{{Move|Ext4|File system specific operations should be placed in their respective wiki pages.}}<br />
<br />
If not using the {{ic|-r}}/{{ic|--resizefs}} option to {{ic|lvresize}}, {{ic|lvextend}} or {{ic|lvreduce}}, or using a file system unsupported by {{man|8|fsadm}} (e.g. [[Btrfs]], [[ZFS]]), you need to manually resize the file system before shrinking the LV or after expanding it.<br />
<br />
{{Warning|Not all file systems support resizing without loss of data and/or resizing online.}}<br />
<br />
For example with an ext2/ext3/ext4 file system:<br />
<br />
# resize2fs ''vg''/''lv''<br />
<br />
will expand the FS to the maximum size of the underlying LV, while<br />
<br />
# resize2fs -M ''vg''/''lv''<br />
<br />
will shrink it to its minimum size. To resize it to a specified size, use:<br />
<br />
# resize2fs ''vg''/''lv'' ''NewSize''<br />
<br />
=== Remove logical volume ===<br />
<br />
{{Warning|Before you remove a logical volume, make sure to move all data that you want to keep somewhere else; otherwise, it will be lost!}}<br />
<br />
First, find out the name of the logical volume you want to remove. You can get a list of all logical volumes with:<br />
<br />
# lvs<br />
<br />
Next, look up the mountpoint of the chosen logical volume:<br />
<br />
$ lsblk<br />
<br />
Then unmount the filesystem on the logical volume:<br />
<br />
# umount /<''mountpoint''><br />
<br />
Finally, remove the logical volume:<br />
<br />
# lvremove <''volume_group''>/<''logical_volume''><br />
<br />
For example:<br />
<br />
# lvremove VolGroup00/lvolhome<br />
<br />
Confirm by typing in {{ic|y}}.<br />
<br />
Update {{ic|/etc/fstab}} as necessary.<br />
<br />
You can verify the removal of the logical volume by typing {{ic|lvs}} as root again (see first step of this section).<br />
<br />
=== Add physical volume to a volume group ===<br />
<br />
You first create a new physical volume on the block device you wish to use, then extend your volume group<br />
<br />
# pvcreate /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdb1<br />
<br />
This of course will increase the total number of physical extents on your volume group, which can be allocated by logical volumes as you see fit.<br />
<br />
{{Note|It is considered good form to have a [[Partitioning|partition table]] on your storage medium below LVM. Use the appropriate type code: {{ic|8e}} for MBR, and {{ic|8e00}} for GPT partitions.}}<br />
<br />
=== Remove partition from a volume group ===<br />
<br />
If you created a logical volume on the partition, [[#Remove logical volume|remove]] it first.<br />
<br />
All of the data on that partition needs to be moved to another partition. Fortunately, LVM makes this easy:<br />
<br />
# pvmove /dev/sdb1<br />
<br />
If you want to have the data on a specific physical volume, specify that as the second argument to {{ic|pvmove}}:<br />
<br />
# pvmove /dev/sdb1 /dev/sdf1<br />
<br />
Then the physical volume needs to be removed from the volume group:<br />
<br />
# vgreduce myVg /dev/sdb1<br />
<br />
Or remove all empty physical volumes:<br />
<br />
# vgreduce --all vg0<br />
<br />
And lastly, if you want to use the partition for something else, and want to avoid LVM thinking that the partition is a physical volume:<br />
<br />
# pvremove /dev/sdb1<br />
<br />
=== Deactivate volume group ===<br />
<br />
Just invoke <br />
<br />
# vgchange -a n my_volume_group<br />
<br />
This will deactivate the volume group and allow you to unmount the container it is stored in.<br />
<br />
== Logical volume types ==<br />
<br />
{{Expansion|Add instructions for thin-provisioned volume creation and RAID volume creation.|section=Logical volume types}}<br />
<br />
Besides simple logical volumes, LVM supports snapshots, logical volume caching, thin provisioned logical volumes and RAID.<br />
<br />
=== Snapshots ===<br />
<br />
LVM allows you to take a snapshot of your system in a much more efficient way than a traditional backup. It does this efficiently by using a COW (copy-on-write) policy. The initial snapshot you take simply contains hard-links to the inodes of your actual data. So long as your data remains unchanged, the snapshot merely contains its inode pointers and not the data itself. Whenever you modify a file or directory that the snapshot points to, LVM automatically clones the data, the old copy referenced by the snapshot, and the new copy referenced by your active system. Thus, you can snapshot a system with 35 GiB of data using just 2 GiB of free space so long as you modify less than 2 GiB (on both the original and snapshot). In order to be able to create snapshots you need to have unallocated space in your volume group. Snapshot like any other volume will take up space in the volume group. So, if you plan to use snapshots for backing up your root partition do not allocate 100% of your volume group for root logical volume.<br />
<br />
==== Configuration ====<br />
<br />
You create snapshot logical volumes just like normal ones.<br />
<br />
# lvcreate --size 100M --snapshot --name snap01 /dev/mapper/vg0-pv<br />
<br />
With that volume, you may modify less than 100 MiB of data, before the snapshot volume fills up.<br />
<br />
Reverting the modified 'pv' logical volume to the state when the 'snap01' snapshot was taken can be done with<br />
<br />
# lvconvert --merge /dev/mapper/vg0-snap01<br />
<br />
In case the origin logical volume is active, merging will occur on the next reboot.(Merging can be done even from a LiveCD)<br />
<br />
The snapshot will no longer exist after merging.<br />
<br />
Also multiple snapshots can be taken and each one can be merged with the origin logical volume at will.<br />
<br />
The snapshot can be mounted and backed up with '''dd''' or '''tar'''. The size of the backup file done with '''dd''' will be the size of the files residing on the snapshot volume. <br />
To restore just create a snapshot, mount it, and write or extract the backup to it. And then merge it with the origin.<br />
<br />
{{Expansion|scripts to automate snapshots of root before updates, to rollback... updating {{ic|menu.lst}} to boot snapshots (separate article?)}}<br />
<br />
Snapshots are primarily used to provide a frozen copy of a file system to make backups; a backup taking two hours provides a more consistent image of the file system than directly backing up the partition.<br />
<br />
See [[Create root filesystem snapshots with LVM]] for automating the creation of clean root file system snapshots during system startup for backup and rollback.<br />
<br />
[[dm-crypt/Encrypting an entire system#LVM on LUKS]] and [[dm-crypt/Encrypting an entire system#LUKS on LVM]].<br />
<br />
If you have LVM volumes not activated via the [[initramfs]], [[enable]] {{ic|lvm-monitoring.service}}, which is provided by the {{pkg|lvm2}} package.<br />
<br />
=== LVM cache ===<br />
<br />
From {{man|7|lvmcache}}:<br />
<br />
: The cache logical volume type uses a small and fast LV to improve the performance of a large and slow LV. It does this by storing the frequently used blocks on the faster LV. LVM refers to the small fast LV as a cache pool LV. The large slow LV is called the origin LV. Due to requirements from dm-cache (the kernel driver), LVM further splits the cache pool LV into two devices - the cache data LV and cache metadata LV. The cache data LV is where copies of data blocks are kept from the origin LV to increase speed. The cache metadata LV holds the accounting information that specifies where data blocks are stored (e.g. on the origin LV or on the cache data LV). Users should be familiar with these LVs if they wish to create the best and most robust cached logical volumes. All of these associated LVs must be in the same VG.<br />
<br />
==== Create cache ====<br />
<br />
The fast method is creating a PV (if necessary) on the fast disk and add it to the existing volume group:<br />
<br />
# vgextend dataVG /dev/sdx<br />
<br />
Create a cache pool with automatic meta data on sdb, and convert the existing logical volume (dataLV) to a cached volume, all in one step:<br />
<br />
# lvcreate --type cache --cachemode writethrough -L 20G -n dataLV_cachepool dataVG/dataLV /dev/sdx<br />
<br />
Obviously, if you want your cache to be bigger, you can change the {{ic|-L}} parameter to a different size.<br />
<br />
{{Note|Cachemode has two possible options:<br />
* {{ic|writethrough}} ensures that any data written will be stored both in the cache pool LV and on the origin LV. The loss of a device associated with the cache pool LV in this case would not mean the loss of any data;<br />
* {{ic|writeback}} ensures better performance, but at the cost of a higher risk of data loss in case the drive used for cache fails.<br />
<br />
If a specific {{ic|--cachemode}} is not indicated, the system will assume {{ic|writethrough}} as default.<br />
}}<br />
<br />
==== Remove cache ====<br />
<br />
If you ever need to undo the one step creation operation above:<br />
<br />
# lvconvert --uncache dataVG/dataLV<br />
<br />
This commits any pending writes still in the cache back to the origin LV, then deletes the cache. Other options are available and described in {{man|7|lvmcache}}.<br />
<br />
=== RAID ===<br />
<br />
From {{man|7|lvmraid}}:<br />
: {{man|8|lvm}} RAID is a way to create a Logical Volume (LV) that uses multiple physical devices to improve performance or tolerate device failures. In LVM, the physical devices are Physical Volumes (PVs) in a single Volume Group (VG).<br />
<br />
LVM RAID supports RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 and RAID 10. See [[Wikipedia:Standard RAID levels]] for details on each level.<br />
<br />
==== Setup RAID ====<br />
<br />
Create physical volumes:<br />
<br />
# pvcreate /dev/sda2 /dev/sdb2<br />
<br />
Create volume group on the physical volumes:<br />
<br />
# vgcreate VolGroup00 /dev/sda2 /dev/sdb2<br />
<br />
Create logical volumes useing {{ic|lvcreate --type ''raidlevel''}}, see {{man|7|lvmraid}} and {{man|8|lvcreate}} for more options.<br />
<br />
# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]<br />
<br />
For example:<br />
<br />
# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol VolGroup00 /dev/sda2 /dev/sdb2<br />
<br />
will create a 20 GiB mirrored logical volume named "myraid1vol" in VolGroup00 on {{ic|/dev/sda2}} and {{ic|/dev/sdb2}}.<br />
<br />
==== Configure mkinitcpio for RAID ====<br />
<br />
If your root filesystem is on LVM RAID additionally to {{ic|lvm2}} or {{ic|sd-lvm2}} hooks, you need to add {{ic|dm-raid}} and the appropriate RAID modules (e.g. {{ic|raid0}}, {{ic|raid1}}, {{ic|raid10}} and/or {{ic|raid456}}) to the MODULES array in {{ic|mkinitcpio.conf}}.<br />
<br />
For busybox based initramfs:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=('''dm-raid raid0 raid1 raid10 raid456''')<br />
HOOKS=(base '''udev''' ... block '''lvm2''' filesystems)<br />
}}<br />
<br />
For systemd based initramfs:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=('''dm-raid raid0 raid1 raid10 raid456''')<br />
HOOKS=(base '''systemd''' ... block '''sd-lvm2''' filesystems)<br />
}}<br />
<br />
== Graphical configuration ==<br />
<br />
There is no "official" GUI tool for managing LVM volumes, but {{AUR|system-config-lvm}} covers most of the common operations, and provides simple visualizations of volume state. It can automatically resize many file systems when resizing logical volumes.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Changes that could be required due to changes in the Arch-Linux defaults ===<br />
<br />
The {{ic|1=use_lvmetad = 1}} must be set in {{ic|/etc/lvm/lvm.conf}}. This is the default now - if you have a {{ic|lvm.conf.pacnew}} file, you must merge this change.<br />
<br />
=== LVM commands do not work ===<br />
<br />
* Load proper module:<br />
<br />
# modprobe dm_mod<br />
<br />
The {{ic|dm_mod}} module should be automatically loaded. In case it does not, you can try:<br />
{{Accuracy|Should module loading at boot be done using "/etc/modules-load.d" instead?}}<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=(dm_mod ...)<br />
}}<br />
<br />
You will need to [[regenerate the initramfs]] to commit any changes you made.<br />
<br />
* Try preceding commands with ''lvm'' like this:<br />
<br />
# lvm pvdisplay<br />
<br />
=== Logical Volumes do not show up ===<br />
<br />
If you are trying to mount existing logical volumes, but they do not show up in {{ic|lvscan}}, you can use the following commands to activate them:<br />
<br />
# vgscan<br />
# vgchange -ay<br />
<br />
=== LVM on removable media ===<br />
<br />
Symptoms:<br />
{{hc|# vgscan|<br />
Reading all physical volumes. This may take a while...<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error<br />
Found volume group "backupdrive1" using metadata type lvm2<br />
Found volume group "networkdrive" using metadata type lvm2<br />
}}<br />
<br />
Cause:<br />
:Removing an external LVM drive without deactivating the volume group(s) first. Before you disconnect, make sure to:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Fix: assuming you already tried to activate the volume group with {{ic|vgchange -ay ''vg''}}, and are receiving the Input/output errors:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Unplug the external drive and wait a few minutes:<br />
<br />
# vgscan<br />
# vgchange -ay ''volume group name''<br />
<br />
=== Resizing a contiguous logical volume fails ===<br />
<br />
If trying to extend a logical volume errors with:<br />
<br />
" Insufficient suitable contiguous allocatable extents for logical volume "<br />
<br />
The reason is that the logical volume was created with an explicit contiguous allocation policy (options {{ic|-C y}} or {{ic|--alloc contiguous}}) and no further adjacent contiguous extents are available (see also [http://www.hostatic.ro/2010/02/15/lvm-inherit-and-contiguous-policies/ reference]).<br />
<br />
To fix this, prior to extending the logical volume, change its allocation policy with {{ic|lvchange --alloc inherit <logical_volume>}}. If you need to keep the contiguous allocation policy, an alternative approach is to move the volume to a disk area with sufficient free extents (see [http://superuser.com/questions/435075/how-to-align-logical-volumes-on-contiguous-physical-extents]).<br />
<br />
=== Command "grub-mkconfig" reports "unknown filesystem" errors ===<br />
<br />
Make sure to remove snapshot volumes before [[GRUB#Generate the main configuration file|generating grub.cfg]].<br />
<br />
=== Thinly-provisioned root volume device times out ===<br />
<br />
With a large number of snapshots, {{ic|thin_check}} runs for a long enough time so that waiting for the root device times out. To compensate, add the {{ic|1=rootdelay=60}} kernel boot parameter to your boot loader configuration.<br />
<br />
=== Delay on shutdown ===<br />
<br />
If you use RAID, snapshots or thin provisioning and experience a delay on shutdown, make sure {{ic|lvm2-monitor.service}} is [[started]]. See {{Bug|50420}}.<br />
<br />
== See also ==<br />
<br />
* [http://sourceware.org/lvm2/ LVM2 Resource Page] on SourceWare.org<br />
* [http://wiki.gentoo.org/wiki/LVM LVM] article at Gentoo wiki<br />
* [http://www.tutonics.com/2012/11/ubuntu-lvm-guide-part-1.html Ubuntu LVM Guide Part 1][http://www.tutonics.com/2012/12/lvm-guide-part-2-snapshots.html Part 2 detals snapshots]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Logical_Volume_Manager_Administration/index.html Red Hat: Logical Volume Manager Administration]</div>Wincraft71https://wiki.archlinux.org/index.php?title=LVM&diff=518332LVM2018-04-22T20:09:03Z<p>Wincraft71: /* Create volume group */ link to LVM man page about valid characters for naming volume group</p>
<hr />
<div>[[Category:Storage virtualization]]<br />
[[cs:LVM]]<br />
[[de:LVM]]<br />
[[es:LVM]]<br />
[[fr:LVM]]<br />
[[it:LVM]]<br />
[[ja:LVM]]<br />
[[ru:LVM]]<br />
[[zh-hans:LVM]]<br />
{{Related articles start}}<br />
{{Related|Software RAID and LVM}}<br />
{{Related|dm-crypt/Encrypting an entire system#LVM on LUKS}}<br />
{{Related|dm-crypt/Encrypting an entire system#LUKS on LVM}}<br />
{{Related|Resizing LVM-on-LUKS}}<br />
{{Related|Create root filesystem snapshots with LVM}}<br />
{{Related articles end}}<br />
From [[Wikipedia:Logical Volume Manager (Linux)]]:<br />
:LVM is a [[Wikipedia:logical volume management|logical volume manager]] for the [[Wikipedia:Linux kernel|Linux kernel]]; it manages disk drives and similar mass-storage devices.<br />
<br />
== LVM Building Blocks ==<br />
<br />
Logical Volume Management utilizes the kernel's [http://sources.redhat.com/dm/ device-mapper] feature to provide a system of partitions independent of underlying disk layout. With LVM you abstract your storage and have "virtual partitions", making [[#Resizing volumes|extending/shrinking]] easier (subject to potential filesystem limitations).<br />
<br />
Virtual partitions allow addition and removal without worry of whether you have enough contiguous space on a particular disk, getting caught up fdisking a disk in use (and wondering whether the kernel is using the old or new partition table), or, having to move other partitions out of the way. This is strictly an ease-of-management solution: LVM adds no security.<br />
<br />
Basic building blocks of LVM:<br />
<br />
; Physical volume (PV): Partition on hard disk (or even the disk itself or loopback file) on which you can have volume groups. It has a special header and is divided into physical extents. Think of physical volumes as big building blocks used to build your hard drive.<br />
; Volume group (VG): Group of physical volumes used as a storage volume (as one disk). They contain logical volumes. Think of volume groups as hard drives.<br />
; Logical volume (LV): A "virtual/logical partition" that resides in a volume group and is composed of physical extents. Think of logical volumes as normal partitions.<br />
; Physical extent (PE): The smallest size in the physical volume that can be assigned to a logical volume (default 4 MiB). Think of physical extents as parts of disks that can be allocated to any partition.<br />
<br />
Example:<br />
'''Physical disks'''<br />
<br />
Disk1 (/dev/sda):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 50 GiB (Physical volume) |Partition2 80 GiB (Physical volume) |<br />
|/dev/sda1 |/dev/sda2 |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ |<br />
<br />
Disk2 (/dev/sdb):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Partition1 120 GiB (Physical volume) |<br />
|/dev/sdb1 |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
<br />
'''LVM logical volumes'''<br />
<br />
Volume Group1 (/dev/MyStorage/ = /dev/sda1 + /dev/sda2 + /dev/sdb1):<br />
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _<br />
|Logical volume1 15 GiB |Logical volume2 35 GiB |Logical volume3 200 GiB |<br />
|/dev/MyStorage/rootvol |/dev/MyStorage/homevol |/dev/MyStorage/mediavol |<br />
|_ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
<br />
== Advantages ==<br />
<br />
LVM gives you more flexibility than just using normal hard drive partitions:<br />
<br />
* Use any number of disks as one big disk.<br />
* Have logical volumes stretched over several disks.<br />
* Create small logical volumes and resize them "dynamically" as they get filled up.<br />
* Resize logical volumes regardless of their order on disk. It does not depend on the position of the LV within VG, there is no need to ensure surrounding available space.<br />
* Resize/create/delete logical and physical volumes online. File systems on them still need to be resized, but some (such as ext4) support online resizing.<br />
* Online/live migration of LV being used by services to different disks without having to restart services.<br />
* Snapshots allow you to backup a frozen copy of the file system, while keeping service downtime to a minimum.<br />
* Support for various device-mapper targets, including transparent filesystem encryption and caching of frequently used data. This allows creating a system with (one or more) physical disks (encrypted with LUKS) and [[dm-crypt/Encrypting an entire system#LVM on LUKS|LVM on top]] to allow for easy resizing and management of separate volumes (e.g. for {{ic|/}}, {{ic|/home}}, {{ic|/backup}}, etc.) without the hassle of entering a key multiple times on boot.<br />
<br />
== Disadvantages ==<br />
<br />
* Additional steps in setting up the system, more complicated.<br />
* If dual-booting, note that Windows does not support LVM; you will be unable to access any LVM partitions from Windows.<br />
<br />
== Installing Arch Linux on LVM ==<br />
<br />
You should create your LVM Volumes between the [[partitioning]] and [[File systems#Create a file system|formatting]] steps of the [[Installation guide|installation procedure]]. Instead of directly formatting a partition to be your root file system, the file system will be created inside a logical volume (LV). <br />
<br />
Make sure the {{pkg|lvm2}} package is [[installed]].<br />
<br />
Quick overview: <br />
<br />
* Create [[Partitioning|partition(s)]] where your PV(s) will reside.<br />
** If you use Master Boot Record partition table, set the [[Wikipedia:Partition type|partition type ID]] to {{ic|8e}} (partition type {{ic|Linux LVM}} in ''fdisk'').<br />
** If you use GUID Partition Table, set the [[Wikipedia:GUID Partition Table#Partition type GUIDs|partition type GUID]] to {{ic|E6D6D379-F507-44C2-A23C-238F2A3DF928}} (partition type {{ic|Linux LVM}} in ''fdisk'' and {{ic|8e00}} in ''gdisk'').<br />
* Create your physical volumes (PVs). If you have one disk it is best to just create one PV in one large partition. If you have multiple disks you can create partitions on each of them and create a PV on each partition.<br />
* Create your volume group (VG) and add all PVs to it.<br />
* Create logical volumes (LVs) inside that VG.<br />
* Continue with [[Installation guide#Format the partitions]].<br />
* When you reach the “Create initial ramdisk environment” step in the Installation guide, add the {{ic|lvm}} hook to {{ic|/etc/mkinitcpio.conf}} (see below for details).<br />
<br />
{{Warning|{{ic|/boot}} cannot reside in LVM when using a boot loader which does not support LVM; you must create a separate {{ic|/boot}} partition and format it directly. Only [[GRUB]] is known to support LVM.}}<br />
<br />
=== Create partitions ===<br />
<br />
If LVM has to be set on the entire disk, there is no need to create any partitions.<br />
<br />
Otherwise, [[partition]] the device as required before configuring LVM.<br />
<br />
=== Create physical volumes ===<br />
<br />
To list all your devices capable of being used as a physical volume:<br />
<br />
# lvmdiskscan<br />
<br />
{{Warning|Make sure you target the correct device, or below commands will result in data loss!}}<br />
<br />
Create a physical volume on them:<br />
<br />
# pvcreate ''DEVICE''<br />
<br />
This command creates a header on each device so it can be used for LVM. As defined in [[#LVM Building Blocks]], ''DEVICE'' can be a disk (e.g. {{ic|/dev/sda}}), a partition (e.g. {{ic|/dev/sda2}}) or a loop back device. For example: <br />
<br />
# pvcreate /dev/sda2<br />
<br />
You can track created physical volumes with:<br />
<br />
# pvdisplay<br />
<br />
{{Note|If using a SSD without partitioning it first, use {{ic|pvcreate --dataalignment 1m /dev/sda}} (for erase block size < 1 MiB), see e.g. [http://serverfault.com/questions/356534/ssd-erase-block-size-lvm-pv-on-raw-device-alignment here]}}<br />
<br />
=== Create volume group ===<br />
<br />
The next step is to create a volume group on this physical volume.<br />
<br />
First you need to create a volume group on one of the physical volumes:<br />
<br />
# vgcreate <''volume_group''> <''physical_volume''><br />
<br />
See {{man|8|lvm}} for a list of valid characters for volume group names.<br />
<br />
For example:<br />
<br />
# vgcreate VolGroup00 /dev/sda2<br />
<br />
Then add to it all other physical volumes you want to have in it:<br />
<br />
# vgextend <''volume_group''> <''physical_volume''><br />
# vgextend <''volume_group''> <''another_physical_volume''><br />
# ...<br />
<br />
For example:<br />
<br />
# vgextend VolGroup00 /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdc<br />
<br />
You can track how your volume group grows with:<br />
<br />
# vgdisplay<br />
<br />
{{Note|You can create more than one volume group if you need to, but then you will not have all your storage presented as one disk.}}<br />
<br />
=== Create in one step ===<br />
<br />
LVM allows you to combine the creation of a volume group and the physical volumes in one easy step. For example, to create the group VolGroup00 with the three devices mentioned above, you can run:<br />
<br />
# vgcreate VolGroup00 /dev/sda2 /dev/sdb1 /dev/sdc<br />
<br />
This command will first set up the three partitions as physical volumes (if necessary) and then create the volume group with the three volumes. The command will warn you it detects an existing filesystem on any of the devices.<br />
<br />
=== Create logical volumes ===<br />
<br />
{{Tip|If you wish to use snapshots, logical volume caching, thin provisioned logical volumes or RAID see [[#Logical volume types]].}}<br />
<br />
Now we need to create logical volumes on this volume group. You create a logical volume with the next command by giving the name of a new logical volume, its size, and the volume group it will live on:<br />
<br />
# lvcreate -L <''size''> <''volume_group''> -n <''logical_volume''><br />
<br />
For example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome<br />
<br />
This will create a logical volume that you can access later with {{ic|/dev/mapper/Volgroup00-lvolhome}} or {{ic|/dev/VolGroup00/lvolhome}}. Same as with the volume groups, you can use any name you want for your logical volume when creating it.<br />
<br />
You can also specify one or more physical volumes to restrict where LVM allocates the data. For example, you may wish to create a logical volume for the root filesystem on your small SSD, and your home volume on a slower mechanical drive. Simply add the physical volume devices to the command line, for example:<br />
<br />
# lvcreate -L 10G VolGroup00 -n lvolhome /dev/sdc1<br />
<br />
If you want to fill all the free space left on a volume group, use the next command:<br />
<br />
# lvcreate -l 100%FREE <''volume_group''> -n <''logical_volume''><br />
<br />
You can track created logical volumes with:<br />
<br />
# lvdisplay<br />
<br />
{{Note|You may need to load the ''device-mapper'' kernel module ({{ic|modprobe dm_mod'}}) for the above commands to succeed.}}<br />
<br />
{{Tip|You can start out with relatively small logical volumes and expand them later if needed. For simplicity, leave some free space in the volume group so there is room for expansion.}}<br />
<br />
=== Create file systems and mount logical volumes ===<br />
<br />
Your logical volumes should now be located in {{ic|/dev/mapper/}} and {{ic|/dev/''YourVolumeGroupName''}}. If you cannot find them, use the next commands to bring up the module for creating device nodes and to make volume groups available:<br />
<br />
# modprobe dm_mod<br />
# vgscan<br />
# vgchange -ay<br />
<br />
Now you can create file systems on logical volumes and mount them as normal partitions (if you are installing Arch linux, refer to [[mount|mounting the partitions]] for additional details):<br />
<br />
# mkfs.<''fstype''> /dev/mapper/<''volume_group''>-<''logical_volume''><br />
# mount /dev/mapper/<''volume_group''>-<''logical_volume''> /<''mountpoint''><br />
<br />
For example:<br />
<br />
# mkfs.ext4 /dev/mapper/VolGroup00-lvolhome<br />
# mount /dev/mapper/VolGroup00-lvolhome /home<br />
<br />
{{Warning|When choosing mountpoints, just select your newly created logical volumes (use: {{ic|/dev/mapper/Volgroup00-lvolhome}}). Do '''not''' select the actual partitions on which logical volumes were created (do not use: {{ic|/dev/sda2}}).}}<br />
<br />
=== Configure mkinitcpio ===<br />
<br />
In case your root filesystem is on LVM, you will need to enable the appropriate [[mkinitcpio]] hooks, otherwise your system might not boot. Enable:<br />
<br />
* {{ic|udev}} and {{ic|lvm2}} for the default busybox based initramfs<br />
* {{ic|systemd}} and {{ic|sd-lvm2}} for systemd based initramfs<br />
<br />
{{ic|udev}} is there by default. Edit the file and insert {{ic|lvm2}} between {{ic|block}} and {{ic|filesystems}} like so:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=<br />
HOOKS=(base '''udev''' ... block '''lvm2''' filesystems)<br />
}}<br />
<br />
For systemd based initramfs:<br />
<br />
{{hc|1=/etc/mkinitcpio.conf|2=<br />
HOOKS=(base '''systemd''' ... block '''sd-lvm2''' filesystems)<br />
}}<br />
<br />
Afterwards, you can continue in normal installation instructions with the [[mkinitcpio#Image creation and activation|create an initial ramdisk]] step.<br />
<br />
{{Tip|<br />
* The {{ic|lvm2}} and {{ic|sd-lvm2}} hooks are installed by {{pkg|lvm2}}, not {{pkg|mkinitcpio}}. If you are running ''mkinitcpio'' in an ''arch-chroot'' for a new installation, {{pkg|lvm2}} must be installed inside the ''arch-chroot'' for ''mkinitcpio'' to find the {{ic|lvm2}} or {{ic|sd-lvm2}} hook. If {{pkg|lvm2}} only exists outside the ''arch-chroot'', ''mkinitcpio'' will output {{ic|Error: Hook 'lvm2' cannot be found}}.<br />
* If your root filesystem is on LVM RAID see [[#Configure mkinitcpio for RAID]].<br />
}}<br />
<br />
=== Kernel options ===<br />
<br />
If the root file system resides in a logical volume, the {{ic|1=root=}} [[kernel parameter]] must be pointed to the mapped device, e.g {{ic|/dev/mapper/''vg-name''-''lv-name''}}.<br />
<br />
== Volume operations ==<br />
<br />
=== Advanced options ===<br />
<br />
If you need monitoring (needed for snapshots) you can enable lvmetad. <br />
For this set {{ic|1=use_lvmetad = 1}} in {{ic|/etc/lvm/lvm.conf}}.<br />
This is the default by now. <br />
<br />
You can restrict the volumes that are activated automatically by setting the {{ic|auto_activation_volume_list}} in {{ic|/etc/lvm/lvm.conf}}. If in doubt, leave this option commented out.<br />
<br />
=== Resizing volumes ===<br />
<br />
==== Physical volumes ====<br />
<br />
After extending or prior to reducing the size of a device that has a physical volume on it, you need to grow or shrink the PV using {{ic|pvresize}}.<br />
<br />
===== Growing =====<br />
<br />
To expand the PV on {{ic|/dev/sda1}} after enlarging the [[partition]], run:<br />
<br />
# pvresize /dev/sda1<br />
<br />
This will automatically detect the new size of the device and extend the PV to its maximum.<br />
<br />
{{Note|This command can be done while the volume is online.}}<br />
<br />
===== Shrinking =====<br />
<br />
To shrink a physical volume prior to reducing its underlying device, add the {{ic|--setphysicalvolumesize ''size''}} parameters to the command, ''e.g.'':<br />
<br />
# pvresize --setphysicalvolumesize 40G /dev/sda1<br />
<br />
The above command may leave you with this error:<br />
<br />
/dev/sda1: cannot resize to 25599 extents as later ones are allocated.<br />
0 physical volume(s) resized / 1 physical volume(s) not resized<br />
<br />
Indeed {{ic|pvresize}} will refuse to shrink a PV if it has allocated extents after where its new end would be. One needs to run [[#Move physical extents|pvmove]] beforehand to relocate these elsewhere in the volume group if there is sufficient free space.<br />
<br />
====== Move physical extents ======<br />
<br />
Before moving free extents to the end of the volume, one must run {{ic|pvdisplay -v -m}} to see physical segments. In the below example, there is one physical volume on {{ic|/dev/sdd1}}, one volume group {{ic|vg1}} and one logical volume {{ic|backup}}.<br />
<br />
{{hc|# pvdisplay -v -m|<br />
Finding all volume groups.<br />
Using physical volume(s) on command line.<br />
--- Physical volume ---<br />
PV Name /dev/sdd1<br />
VG Name vg1<br />
PV Size 1.52 TiB / not usable 1.97 MiB<br />
Allocatable yes <br />
PE Size 4.00 MiB<br />
Total PE 399669<br />
Free PE 153600<br />
Allocated PE 246069<br />
PV UUID MR9J0X-zQB4-wi3k-EnaV-5ksf-hN1P-Jkm5mW<br />
<br />
--- Physical Segments ---<br />
Physical extent 0 to 153600:<br />
FREE<br />
Physical extent 153601 to 307199:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 1 to 153599<br />
Physical extent 307200 to 307200:<br />
FREE<br />
Physical extent 307201 to 399668:<br />
Logical volume /dev/vg1/backup<br />
Logical extents 153601 to 246068<br />
}}<br />
<br />
One can observe FREE space are split across the volume. To shrink the physical volume, we must first move all used segments to the beginning.<br />
<br />
Here, the first free segment is from 0 to 153600 and leaves us with 153601 free extents. We can now move this segment number from the last physical extent to the first extent. The command will thus be:<br />
<br />
{{hc|# pvmove --alloc anywhere /dev/sdd1:307201-399668 /dev/sdd1:0-92466|<br />
/dev/sdd1: Moved: 0.1 %<br />
/dev/sdd1: Moved: 0.2 %<br />
...<br />
/dev/sdd1: Moved: 99.9 %<br />
/dev/sdd1: Moved: 100,0%<br />
}}<br />
<br />
{{Note|<br />
* this command moves 92468 PEs (399668-307200) '''from''' the last segment '''to''' the first segment. This is possible as the first segment encloses 153600 free PEs, which can contain the 92467 moved PEs.<br />
* the {{ic|--alloc anywhere}} option is used as we move PEs inside the same partition. In case of different partitions, the command would look something like this: {{bc|# pvmove /dev/sdb1:1000-1999 /dev/sdc1:0-999}}<br />
* this command may take a long time (one to two hours) in case of large volumes. It might be a good idea to run this command in a [[Tmux]] or [[GNU Screen]] session. Any unwanted stop of the process could be fatal.<br />
* once the operation is complete, run [[fsck]] to make sure your file system is valid.<br />
}}<br />
<br />
====== Resize physical volume ======<br />
<br />
Once all your free physical segments are on the last physical extent, run {{ic|vgdisplay}} and see your free PE.<br />
<br />
Then you can now run again the command:<br />
<br />
# pvresize --setphysicalvolumesize ''size'' ''PhysicalVolume''<br />
<br />
See the result:<br />
<br />
{{hc|# pvs|<br />
PV VG Fmt Attr PSize PFree <br />
/dev/sdd1 vg1 lvm2 a-- 1t 500g<br />
}}<br />
<br />
====== Resize partition ======<br />
<br />
Last, you need to shrink the partition with your favorite [[Partitioning#Partitioning tools|partitioning tool]].<br />
<br />
==== Logical volumes ====<br />
<br />
{{Note|''lvresize'' provides more or less the same options as the specialized {{ic|lvextend}} and {{ic|lvreduce}} commands, while allowing to do both types of operation. Notwithstanding this, all those utilities offer a {{ic|-r}}/{{ic|--resizefs}} option which allows to resize the file system together with the LV using {{man|8|fsadm}} (''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] supported). Therefore it may be easier to simply use {{ic|lvresize}} for both operations and use {{ic|--resizefs}} to simplify things a bit, except if you have specific needs or want full control over the process.}}<br />
<br />
===== Growing or shrinking with lvresize =====<br />
<br />
{{Warning|While enlarging a file system can often be done on-line (''i.e.'' while it is mounted), even for the root partition, shrinking will nearly always require to first unmount the file system so as to prevent data loss. Make sure your FS supports what you are trying to do.}}<br />
<br />
Extend logical volume ''lv1'' within volume group ''vg1'' by 2 GiB ''without'' touching its file system:<br />
<br />
# lvresize -L +2G vg1/lv1<br />
<br />
Reduce the size of {{ic|vg1/lv1}} by 500 MiB ''without'' resizing its file system (make sure it is [[#Resizing the file system separately|already shrunk]] in that case):<br />
<br />
# lvresize -L -500M vg1/lv1<br />
<br />
Set {{ic|vg1/lv1}} to 15 GiB and resize its file system ''all at once'':<br />
<br />
# lvresize -L 15G -r vg1/lv1<br />
<br />
{{Note|Only ''ext2'', [[ext3]], [[ext4]], ''ReiserFS'' and [[XFS]] [[file systems]] are supported. For a different type of file system look for the [[File systems#Types of file systems|appropriate utility]].}}<br />
<br />
If you want to fill all the free space on a volume group, use the following command:<br />
<br />
# lvresize -l +100%FREE ''vg''/''lv''<br />
<br />
See {{man|8|lvresize}} for more detailed options.<br />
<br />
===== Extending the logical volume and file system in one go =====<br />
<br />
{{Merge|#Growing or shrinking with lvresize|No need to split the sections.}}<br />
<br />
{{Warning|Not all file systems support resizing without loss of data and/or resizing online.}}<br />
<br />
Extend the logical volume ''home'' in ''volume-group'' with 10 GiB<br />
<br />
# lvresize -L +10G /dev/''volume-group''/''home'' --resizefs<br />
<br />
Alternatively with a XFS filesystem<br />
<br />
# lvextend -L+10G /dev/''volume-group''/''home''<br />
# xfs_growfs /home<br />
<br />
Note: ''xfs_growfs'' takes a mount point as argument. See {{man|8|xfs_growfs}} for more detailed options.<br />
<br />
===== Resizing the file system separately =====<br />
<br />
{{Move|Ext4|File system specific operations should be placed in their respective wiki pages.}}<br />
<br />
If not using the {{ic|-r}}/{{ic|--resizefs}} option to {{ic|lvresize}}, {{ic|lvextend}} or {{ic|lvreduce}}, or using a file system unsupported by {{man|8|fsadm}} (e.g. [[Btrfs]], [[ZFS]]), you need to manually resize the file system before shrinking the LV or after expanding it.<br />
<br />
{{Warning|Not all file systems support resizing without loss of data and/or resizing online.}}<br />
<br />
For example with an ext2/ext3/ext4 file system:<br />
<br />
# resize2fs ''vg''/''lv''<br />
<br />
will expand the FS to the maximum size of the underlying LV, while<br />
<br />
# resize2fs -M ''vg''/''lv''<br />
<br />
will shrink it to its minimum size. To resize it to a specified size, use:<br />
<br />
# resize2fs ''vg''/''lv'' ''NewSize''<br />
<br />
=== Remove logical volume ===<br />
<br />
{{Warning|Before you remove a logical volume, make sure to move all data that you want to keep somewhere else; otherwise, it will be lost!}}<br />
<br />
First, find out the name of the logical volume you want to remove. You can get a list of all logical volumes with:<br />
<br />
# lvs<br />
<br />
Next, look up the mountpoint of the chosen logical volume:<br />
<br />
$ lsblk<br />
<br />
Then unmount the filesystem on the logical volume:<br />
<br />
# umount /<''mountpoint''><br />
<br />
Finally, remove the logical volume:<br />
<br />
# lvremove <''volume_group''>/<''logical_volume''><br />
<br />
For example:<br />
<br />
# lvremove VolGroup00/lvolhome<br />
<br />
Confirm by typing in {{ic|y}}.<br />
<br />
Update {{ic|/etc/fstab}} as necessary.<br />
<br />
You can verify the removal of the logical volume by typing {{ic|lvs}} as root again (see first step of this section).<br />
<br />
=== Add physical volume to a volume group ===<br />
<br />
You first create a new physical volume on the block device you wish to use, then extend your volume group<br />
<br />
# pvcreate /dev/sdb1<br />
# vgextend VolGroup00 /dev/sdb1<br />
<br />
This of course will increase the total number of physical extents on your volume group, which can be allocated by logical volumes as you see fit.<br />
<br />
{{Note|It is considered good form to have a [[Partitioning|partition table]] on your storage medium below LVM. Use the appropriate type code: {{ic|8e}} for MBR, and {{ic|8e00}} for GPT partitions.}}<br />
<br />
=== Remove partition from a volume group ===<br />
<br />
If you created a logical volume on the partition, [[#Remove logical volume|remove]] it first.<br />
<br />
All of the data on that partition needs to be moved to another partition. Fortunately, LVM makes this easy:<br />
<br />
# pvmove /dev/sdb1<br />
<br />
If you want to have the data on a specific physical volume, specify that as the second argument to {{ic|pvmove}}:<br />
<br />
# pvmove /dev/sdb1 /dev/sdf1<br />
<br />
Then the physical volume needs to be removed from the volume group:<br />
<br />
# vgreduce myVg /dev/sdb1<br />
<br />
Or remove all empty physical volumes:<br />
<br />
# vgreduce --all vg0<br />
<br />
And lastly, if you want to use the partition for something else, and want to avoid LVM thinking that the partition is a physical volume:<br />
<br />
# pvremove /dev/sdb1<br />
<br />
=== Deactivate volume group ===<br />
<br />
Just invoke <br />
<br />
# vgchange -a n my_volume_group<br />
<br />
This will deactivate the volume group and allow you to unmount the container it is stored in.<br />
<br />
== Logical volume types ==<br />
<br />
{{Expansion|Add instructions for thin-provisioned volume creation and RAID volume creation.|section=Logical volume types}}<br />
<br />
Besides simple logical volumes, LVM supports snapshots, logical volume caching, thin provisioned logical volumes and RAID.<br />
<br />
=== Snapshots ===<br />
<br />
LVM allows you to take a snapshot of your system in a much more efficient way than a traditional backup. It does this efficiently by using a COW (copy-on-write) policy. The initial snapshot you take simply contains hard-links to the inodes of your actual data. So long as your data remains unchanged, the snapshot merely contains its inode pointers and not the data itself. Whenever you modify a file or directory that the snapshot points to, LVM automatically clones the data, the old copy referenced by the snapshot, and the new copy referenced by your active system. Thus, you can snapshot a system with 35 GiB of data using just 2 GiB of free space so long as you modify less than 2 GiB (on both the original and snapshot). In order to be able to create snapshots you need to have unallocated space in your volume group. Snapshot like any other volume will take up space in the volume group. So, if you plan to use snapshots for backing up your root partition do not allocate 100% of your volume group for root logical volume.<br />
<br />
==== Configuration ====<br />
<br />
You create snapshot logical volumes just like normal ones.<br />
<br />
# lvcreate --size 100M --snapshot --name snap01 /dev/mapper/vg0-pv<br />
<br />
With that volume, you may modify less than 100 MiB of data, before the snapshot volume fills up.<br />
<br />
Reverting the modified 'pv' logical volume to the state when the 'snap01' snapshot was taken can be done with<br />
<br />
# lvconvert --merge /dev/mapper/vg0-snap01<br />
<br />
In case the origin logical volume is active, merging will occur on the next reboot.(Merging can be done even from a LiveCD)<br />
<br />
The snapshot will no longer exist after merging.<br />
<br />
Also multiple snapshots can be taken and each one can be merged with the origin logical volume at will.<br />
<br />
The snapshot can be mounted and backed up with '''dd''' or '''tar'''. The size of the backup file done with '''dd''' will be the size of the files residing on the snapshot volume. <br />
To restore just create a snapshot, mount it, and write or extract the backup to it. And then merge it with the origin.<br />
<br />
{{Expansion|scripts to automate snapshots of root before updates, to rollback... updating {{ic|menu.lst}} to boot snapshots (separate article?)}}<br />
<br />
Snapshots are primarily used to provide a frozen copy of a file system to make backups; a backup taking two hours provides a more consistent image of the file system than directly backing up the partition.<br />
<br />
See [[Create root filesystem snapshots with LVM]] for automating the creation of clean root file system snapshots during system startup for backup and rollback.<br />
<br />
[[dm-crypt/Encrypting an entire system#LVM on LUKS]] and [[dm-crypt/Encrypting an entire system#LUKS on LVM]].<br />
<br />
If you have LVM volumes not activated via the [[initramfs]], [[enable]] {{ic|lvm-monitoring.service}}, which is provided by the {{pkg|lvm2}} package.<br />
<br />
=== LVM cache ===<br />
<br />
From {{man|7|lvmcache}}:<br />
<br />
: The cache logical volume type uses a small and fast LV to improve the performance of a large and slow LV. It does this by storing the frequently used blocks on the faster LV. LVM refers to the small fast LV as a cache pool LV. The large slow LV is called the origin LV. Due to requirements from dm-cache (the kernel driver), LVM further splits the cache pool LV into two devices - the cache data LV and cache metadata LV. The cache data LV is where copies of data blocks are kept from the origin LV to increase speed. The cache metadata LV holds the accounting information that specifies where data blocks are stored (e.g. on the origin LV or on the cache data LV). Users should be familiar with these LVs if they wish to create the best and most robust cached logical volumes. All of these associated LVs must be in the same VG.<br />
<br />
==== Create cache ====<br />
<br />
The fast method is creating a PV (if necessary) on the fast disk and add it to the existing volume group:<br />
<br />
# vgextend dataVG /dev/sdx<br />
<br />
Create a cache pool with automatic meta data on sdb, and convert the existing logical volume (dataLV) to a cached volume, all in one step:<br />
<br />
# lvcreate --type cache --cachemode writethrough -L 20G -n dataLV_cachepool dataVG/dataLV /dev/sdx<br />
<br />
Obviously, if you want your cache to be bigger, you can change the {{ic|-L}} parameter to a different size.<br />
<br />
{{Note|Cachemode has two possible options:<br />
* {{ic|writethrough}} ensures that any data written will be stored both in the cache pool LV and on the origin LV. The loss of a device associated with the cache pool LV in this case would not mean the loss of any data;<br />
* {{ic|writeback}} ensures better performance, but at the cost of a higher risk of data loss in case the drive used for cache fails.<br />
<br />
If a specific {{ic|--cachemode}} is not indicated, the system will assume {{ic|writethrough}} as default.<br />
}}<br />
<br />
==== Remove cache ====<br />
<br />
If you ever need to undo the one step creation operation above:<br />
<br />
# lvconvert --uncache dataVG/dataLV<br />
<br />
This commits any pending writes still in the cache back to the origin LV, then deletes the cache. Other options are available and described in {{man|7|lvmcache}}.<br />
<br />
=== RAID ===<br />
<br />
From {{man|7|lvmraid}}:<br />
: {{man|8|lvm}} RAID is a way to create a Logical Volume (LV) that uses multiple physical devices to improve performance or tolerate device failures. In LVM, the physical devices are Physical Volumes (PVs) in a single Volume Group (VG).<br />
<br />
LVM RAID supports RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 and RAID 10. See [[Wikipedia:Standard RAID levels]] for details on each level.<br />
<br />
==== Setup RAID ====<br />
<br />
Create physical volumes:<br />
<br />
# pvcreate /dev/sda2 /dev/sdb2<br />
<br />
Create volume group on the physical volumes:<br />
<br />
# vgcreate VolGroup00 /dev/sda2 /dev/sdb2<br />
<br />
Create logical volumes useing {{ic|lvcreate --type ''raidlevel''}}, see {{man|7|lvmraid}} and {{man|8|lvcreate}} for more options.<br />
<br />
# lvcreate --type RaidLevel [OPTIONS] -n Name -L Size VG [PVs]<br />
<br />
For example:<br />
<br />
# lvcreate --type raid1 --mirrors 1 -L 20G -n myraid1vol VolGroup00 /dev/sda2 /dev/sdb2<br />
<br />
will create a 20 GiB mirrored logical volume named "myraid1vol" in VolGroup00 on {{ic|/dev/sda2}} and {{ic|/dev/sdb2}}.<br />
<br />
==== Configure mkinitcpio for RAID ====<br />
<br />
If your root filesystem is on LVM RAID additionally to {{ic|lvm2}} or {{ic|sd-lvm2}} hooks, you need to add {{ic|dm-raid}} and the appropriate RAID modules (e.g. {{ic|raid0}}, {{ic|raid1}}, {{ic|raid10}} and/or {{ic|raid456}}) to the MODULES array in {{ic|mkinitcpio.conf}}.<br />
<br />
For busybox based initramfs:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=('''dm-raid raid0 raid1 raid10 raid456''')<br />
HOOKS=(base '''udev''' ... block '''lvm2''' filesystems)<br />
}}<br />
<br />
For systemd based initramfs:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=('''dm-raid raid0 raid1 raid10 raid456''')<br />
HOOKS=(base '''systemd''' ... block '''sd-lvm2''' filesystems)<br />
}}<br />
<br />
== Graphical configuration ==<br />
<br />
There is no "official" GUI tool for managing LVM volumes, but {{AUR|system-config-lvm}} covers most of the common operations, and provides simple visualizations of volume state. It can automatically resize many file systems when resizing logical volumes.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Changes that could be required due to changes in the Arch-Linux defaults ===<br />
<br />
The {{ic|1=use_lvmetad = 1}} must be set in {{ic|/etc/lvm/lvm.conf}}. This is the default now - if you have a {{ic|lvm.conf.pacnew}} file, you must merge this change.<br />
<br />
=== LVM commands do not work ===<br />
<br />
* Load proper module:<br />
<br />
# modprobe dm_mod<br />
<br />
The {{ic|dm_mod}} module should be automatically loaded. In case it does not, you can try:<br />
{{Accuracy|Should module loading at boot be done using "/etc/modules-load.d" instead?}}<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES=(dm_mod ...)<br />
}}<br />
<br />
You will need to [[regenerate the initramfs]] to commit any changes you made.<br />
<br />
* Try preceding commands with ''lvm'' like this:<br />
<br />
# lvm pvdisplay<br />
<br />
=== Logical Volumes do not show up ===<br />
<br />
If you are trying to mount existing logical volumes, but they do not show up in {{ic|lvscan}}, you can use the following commands to activate them:<br />
<br />
# vgscan<br />
# vgchange -ay<br />
<br />
=== LVM on removable media ===<br />
<br />
Symptoms:<br />
{{hc|# vgscan|<br />
Reading all physical volumes. This may take a while...<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836585984: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 319836643328: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 0: Input/output error<br />
/dev/backupdrive1/backup: read failed after 0 of 4096 at 4096: Input/output error<br />
Found volume group "backupdrive1" using metadata type lvm2<br />
Found volume group "networkdrive" using metadata type lvm2<br />
}}<br />
<br />
Cause:<br />
:Removing an external LVM drive without deactivating the volume group(s) first. Before you disconnect, make sure to:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Fix: assuming you already tried to activate the volume group with {{ic|vgchange -ay ''vg''}}, and are receiving the Input/output errors:<br />
<br />
# vgchange -an ''volume group name''<br />
<br />
Unplug the external drive and wait a few minutes:<br />
<br />
# vgscan<br />
# vgchange -ay ''volume group name''<br />
<br />
=== Resizing a contiguous logical volume fails ===<br />
<br />
If trying to extend a logical volume errors with:<br />
<br />
" Insufficient suitable contiguous allocatable extents for logical volume "<br />
<br />
The reason is that the logical volume was created with an explicit contiguous allocation policy (options {{ic|-C y}} or {{ic|--alloc contiguous}}) and no further adjacent contiguous extents are available (see also [http://www.hostatic.ro/2010/02/15/lvm-inherit-and-contiguous-policies/ reference]).<br />
<br />
To fix this, prior to extending the logical volume, change its allocation policy with {{ic|lvchange --alloc inherit <logical_volume>}}. If you need to keep the contiguous allocation policy, an alternative approach is to move the volume to a disk area with sufficient free extents (see [http://superuser.com/questions/435075/how-to-align-logical-volumes-on-contiguous-physical-extents]).<br />
<br />
=== Command "grub-mkconfig" reports "unknown filesystem" errors ===<br />
<br />
Make sure to remove snapshot volumes before [[GRUB#Generate the main configuration file|generating grub.cfg]].<br />
<br />
=== Thinly-provisioned root volume device times out ===<br />
<br />
With a large number of snapshots, {{ic|thin_check}} runs for a long enough time so that waiting for the root device times out. To compensate, add the {{ic|1=rootdelay=60}} kernel boot parameter to your boot loader configuration.<br />
<br />
=== Delay on shutdown ===<br />
<br />
If you use RAID, snapshots or thin provisioning and experience a delay on shutdown, make sure {{ic|lvm2-monitor.service}} is [[started]]. See {{Bug|50420}}.<br />
<br />
== See also ==<br />
<br />
* [http://sourceware.org/lvm2/ LVM2 Resource Page] on SourceWare.org<br />
* [http://wiki.gentoo.org/wiki/LVM LVM] article at Gentoo wiki<br />
* [http://www.tutonics.com/2012/11/ubuntu-lvm-guide-part-1.html Ubuntu LVM Guide Part 1][http://www.tutonics.com/2012/12/lvm-guide-part-2-snapshots.html Part 2 detals snapshots]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Logical_Volume_Manager_Administration/index.html Red Hat: Logical Volume Manager Administration]</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=518205Talk:Dm-crypt/Encrypting an entire system2018-04-21T18:12:10Z<p>Wincraft71: /* Rename volume group to be more consistent with device naming */ fix re to mention man page</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== Encrypted boot (GRUB): no need for separate partition? ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
:::::I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.<br />
:::::Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/group-volume path.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:57, 20 April 2018 (UTC)<br />
<br />
::::::From these, I'd vote for "MyVolGroup". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:17, 20 April 2018 (UTC)<br />
<br />
::::::"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 16:45, 20 April 2018 (UTC)<br />
<br />
:::::::I don't think this is the appropriate article to explicitly state that uppercase is allowed, that's more in the scope of the [[LVM]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:56, 20 April 2018 (UTC)<br />
<br />
::::::::Right, [[LVM]] is linked within this page and that would be a more proper place. 'VolGroup00' is another idea. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 19:08, 20 April 2018 (UTC)<br />
<br />
:::::::::So I've [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_entire_system&type=revision&diff=518110&oldid=517996 replaced] all the examples with "MyVolGroup".<br />
:::::::::The other articles mentioning LVM use all kinds of example names, but at least they do have "group", "vg", or even just a "g", enough to remind that it's a volume group, not a volume, so I don't see the need to update them, does anyone?<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:12, 21 April 2018 (UTC)<br />
<br />
::::::::::It looks good. Terry may have implied both articles using the same name when he was referring to "consistency". It is an optional possibility, but [[LVM]] could be edited to use "MyVolGroup" for all volume group names. And also editing [[LVM#Create volume group]] to say something like "See {{man|8|lvm}} for a list of valid characters for Volume Group names." -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 18:04, 21 April 2018 (UTC)<br />
<br />
==<s> Add notes to explain /etc/cryptroot layout (revision 517646) </s>==<br />
<br />
I think these are needed because this process is already complicated, and this may not be obvious to a new user. It needs to be clear that /etc/crypttab is decrypted partitions and encrypted devices, and /etc/fstab is decrypted partitions and mount points. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
:(For reference, the [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517646&oldid=517609 original] edit, and my [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517725&oldid=517649 undo])<br />
:This article is only a collection of particular scenarios, general explanations should be made in the referenced articles; all the scenarios that use crypttab link to [[crypttab]], which new users are supposed to have read before going back to the scenario, therefore I think it's better if you try to improve that section. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 18 April 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=518203Talk:Dm-crypt/Encrypting an entire system2018-04-21T18:04:34Z<p>Wincraft71: /* Rename volume group to be more consistent with device naming */ re</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== Encrypted boot (GRUB): no need for separate partition? ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
:::::I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.<br />
:::::Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/group-volume path.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:57, 20 April 2018 (UTC)<br />
<br />
::::::From these, I'd vote for "MyVolGroup". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:17, 20 April 2018 (UTC)<br />
<br />
::::::"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 16:45, 20 April 2018 (UTC)<br />
<br />
:::::::I don't think this is the appropriate article to explicitly state that uppercase is allowed, that's more in the scope of the [[LVM]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:56, 20 April 2018 (UTC)<br />
<br />
::::::::Right, [[LVM]] is linked within this page and that would be a more proper place. 'VolGroup00' is another idea. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 19:08, 20 April 2018 (UTC)<br />
<br />
:::::::::So I've [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_entire_system&type=revision&diff=518110&oldid=517996 replaced] all the examples with "MyVolGroup".<br />
:::::::::The other articles mentioning LVM use all kinds of example names, but at least they do have "group", "vg", or even just a "g", enough to remind that it's a volume group, not a volume, so I don't see the need to update them, does anyone?<br />
:::::::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:12, 21 April 2018 (UTC)<br />
<br />
::::::::::It looks good. Terry may have implied both articles using the same name when he was referring to "consistency". It is an optional possibility, but [[LVM]] could be edited to use "MyVolGroup" for all volume group names. And also editing [[LVM#Create volume group]] to say something like "Virtual Group names can include any of the following characters: 'a-zA-Z0-9+_.-'" -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 18:04, 21 April 2018 (UTC)<br />
<br />
==<s> Add notes to explain /etc/cryptroot layout (revision 517646) </s>==<br />
<br />
I think these are needed because this process is already complicated, and this may not be obvious to a new user. It needs to be clear that /etc/crypttab is decrypted partitions and encrypted devices, and /etc/fstab is decrypted partitions and mount points. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
:(For reference, the [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517646&oldid=517609 original] edit, and my [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517725&oldid=517649 undo])<br />
:This article is only a collection of particular scenarios, general explanations should be made in the referenced articles; all the scenarios that use crypttab link to [[crypttab]], which new users are supposed to have read before going back to the scenario, therefore I think it's better if you try to improve that section. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 18 April 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=518088Talk:Dm-crypt/Encrypting an entire system2018-04-20T19:08:11Z<p>Wincraft71: /* Rename volume group to be more consistent with device naming */ re</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== Encrypted boot (GRUB): no need for separate partition? ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
:::::I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.<br />
:::::Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/volume-group path.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:57, 20 April 2018 (UTC)<br />
<br />
::::::From these, I'd vote for "MyVolGroup". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:17, 20 April 2018 (UTC)<br />
<br />
::::::"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 16:45, 20 April 2018 (UTC)<br />
<br />
:::::::I don't think this is the appropriate article to explicitly state that uppercase is allowed, that's more in the scope of the [[LVM]] article. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:56, 20 April 2018 (UTC)<br />
<br />
::::::::Right, [[LVM]] is linked within this page and that would be a more proper place. 'VolGroup00' is another idea. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 19:08, 20 April 2018 (UTC)<br />
<br />
== Add notes to explain /etc/cryptroot layout (revision 517646) ==<br />
<br />
I think these are needed because this process is already complicated, and this may not be obvious to a new user. It needs to be clear that /etc/crypttab is decrypted partitions and encrypted devices, and /etc/fstab is decrypted partitions and mount points. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
:(For reference, the [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517646&oldid=517609 original] edit, and my [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517725&oldid=517649 undo])<br />
:This article is only a collection of particular scenarios, general explanations should be made in the referenced articles; all the scenarios that use crypttab link to [[crypttab]], which new users are supposed to have read before going back to the scenario, therefore I think it's better if you try to improve that section. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 18 April 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=518076Talk:Dm-crypt/Encrypting an entire system2018-04-20T16:45:46Z<p>Wincraft71: /* Rename volume group to be more consistent with device naming */ sign</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== Encrypted boot (GRUB): no need for separate partition? ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
:::::I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.<br />
:::::Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/volume-group path.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:57, 20 April 2018 (UTC)<br />
<br />
::::::From these, I'd vote for "MyVolGroup". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:17, 20 April 2018 (UTC)<br />
<br />
::::::"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 16:45, 20 April 2018 (UTC)<br />
<br />
== Add notes to explain /etc/cryptroot layout (revision 517646) ==<br />
<br />
I think these are needed because this process is already complicated, and this may not be obvious to a new user. It needs to be clear that /etc/crypttab is decrypted partitions and encrypted devices, and /etc/fstab is decrypted partitions and mount points. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
:(For reference, the [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517646&oldid=517609 original] edit, and my [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517725&oldid=517649 undo])<br />
:This article is only a collection of particular scenarios, general explanations should be made in the referenced articles; all the scenarios that use crypttab link to [[crypttab]], which new users are supposed to have read before going back to the scenario, therefore I think it's better if you try to improve that section. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 18 April 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=518075Talk:Dm-crypt/Encrypting an entire system2018-04-20T16:45:21Z<p>Wincraft71: /* Rename volume group to be more consistent with device naming */ re</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== Encrypted boot (GRUB): no need for separate partition? ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
:::::I think more important than the spelling here is that 'MyVol' is misleading because it's supposed to be an example name for a volume group, not a volume, so it should be at least 'MyVolGroup', 'MyVGroup' or 'MyGroup'.<br />
:::::Regarding the spelling though, I prefer the CamelCase version because then it's easier to tell group and volume apart in the /dev/mapper/volume-group path.<br />
:::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:57, 20 April 2018 (UTC)<br />
<br />
::::::From these, I'd vote for "MyVolGroup". -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 16:17, 20 April 2018 (UTC)<br />
<br />
::::::"MyGroup" sounds good. Perhaps even "VolGroup"? The Camel casing would imply that you are free to rename it as you please and this can also be explicitly stated.<br />
<br />
== Add notes to explain /etc/cryptroot layout (revision 517646) ==<br />
<br />
I think these are needed because this process is already complicated, and this may not be obvious to a new user. It needs to be clear that /etc/crypttab is decrypted partitions and encrypted devices, and /etc/fstab is decrypted partitions and mount points. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
:(For reference, the [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517646&oldid=517609 original] edit, and my [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517725&oldid=517649 undo])<br />
:This article is only a collection of particular scenarios, general explanations should be made in the referenced articles; all the scenarios that use crypttab link to [[crypttab]], which new users are supposed to have read before going back to the scenario, therefore I think it's better if you try to improve that section. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 18 April 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Talk:Dm-crypt/Encrypting_an_entire_system&diff=517940Talk:Dm-crypt/Encrypting an entire system2018-04-19T10:58:43Z<p>Wincraft71: /* Rename volume group to be more consistent with device naming */ re</p>
<hr />
<div>== LUKS on LVM /tmp example ==<br />
<br />
I don't think the example config for /tmp is correct. It uses tmpfs, which ''completely bypasses the physical disks'' (other than swap), making the whole endeavor pointless. The proper solution seems to be to use the 'tmp' option in /etc/crypttab--I just set this up, and it seems to be working. It automatically creates a new ext2 filesystem with a random key on each boot. I'd update the article, but the crypttab syntax it uses doesn't even match mine, and I don't know how to translate to the new syntax. [[User:TravisE|TravisE]] ([[User talk:TravisE|talk]]) 10:27, 11 March 2014 (UTC)<br />
:You probably use in crypttab "tmp=ext2" as option? I'd say you are right anyway (and the example still works but wastes the reserved lv diskspace). Feel free to edit right away if you clarified or post the settings you use here and we adapt them. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:06, 11 March 2014 (UTC)<br />
:I updated syntax: [https://wiki.archlinux.org/index.php?title=Dm-crypt%2FEncrypting_an_Entire_System&diff=307002&oldid=306998]<br />
:I still left the lv for it. Question to answer before removing it would be where /tmp swaps to, if required. Do you know that? <br />
:--[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 22:45, 25 March 2014 (UTC)<br />
<br />
== Encrypted boot (GRUB): no need for separate partition? ==<br />
<br />
Exploiting [[GRUB#LVM]], I've just tried the following scenario on VirtualBox, modified from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|Encrypted boot partition (GRUB)]]:<br />
<br />
+---------------+----------------+----------------+----------------+----------------+<br />
|ESP partition: |Volume 1: |Volume 2: |Volume 3: |Volume 4: |<br />
| | | | | |<br />
|/boot/efi |boot |root |swap |home |<br />
| | | | | |<br />
| |/dev/store/boot |/dev/store/root |/dev/store/swap |/dev/store/home |<br />
|/dev/sdaX |----------------+----------------+----------------+----------------+<br />
|'''un'''encrypted |/dev/sdaY encrypted using LVM on LUKS |<br />
+---------------+----------------+--------------------------------------------------+<br />
<br />
It works perfectly fine, including the [[Dm-crypt/Device_encryption#With_a_keyfile_embedded_in_the_initramfs]] trick. The result is clearly a lot simpler and neater, and allows avoiding [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] altogether, again being able to unlock everything by entering the password only once.<br />
<br />
Can anybody think of any disadvantages, or worse, security holes? Otherwise I'd like to update the current scenario with this method.<br />
<br />
The only problem I can think of is that [[Dm-crypt/Specialties#mkinitcpio-chkcryptoboot]] needs the partition to be separate, but we can merge [[Dm-crypt/Encrypting_an_entire_system#Configuring_fstab_and_crypttab_2]] there and leave a link from [[Dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]] as a Tip.<br />
<br />
— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:11, 29 November 2015 (UTC)<br />
<br />
:You don't even need a separate volume for /boot. It can perfectly reside on the root volume, and GRUB will be able to boot from it.<br />
:--[[User:Elijah Master|Elijah Master]] ([[User talk:Elijah Master|talk]]) 18:03, 6 December 2017 (UTC)<br />
<br />
== Full disk encryption with LUKS (encrypted LVM with swap and root) ==<br />
I wasnt able to find what I need on the wiki, but this guide got me there. I hope the arch wiki could summarize step by step as this guide does.<br />
https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/<br />
<br />
[[User:Voukait|Voukait]] ([[User talk:Voukait|talk]]) 04:13, 6 May 2016 (UTC)<br />
<br />
:Wow, that's a thorough guide indeed. Nice to see someone reused the ASCII partition layout diagram (I think Kynikos sketched this LVM one:). It also links to our instructions in a number of places, which makes me wonder if the author keeps it updated in case links change. Anyhow, very thorough, yes. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:59, 6 May 2016 (UTC)<br />
<br />
::I don't remember who originally sketched that particular diagram, but everything's published under GFDL :)<br />
::To give an answer to Voukait, we don't keep step-by-step guides like that in this wiki, as they are too difficult to maintain because too many pages would duplicate content and should be continuously kept in sync.<br />
::I think a good way of getting a first grasp on some topic is indeed to go and read "aggregated" information for a specific use case on some external sites/blogs, and then come to the ArchWiki to read more up-to-date information that can be more easily adapted to other scenarios.<br />
::Anyway we should really find a place in this article where to list external links like that.<br />
::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:03, 7 May 2016 (UTC)<br />
<br />
::: Yes, why not use a regular [[Dm-crypt/Encrypting an entire system#See also]] section and use the description. For example<br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide to install [[#LVM on LUKS]] (dated: 2014/11)<br />
::: Other possibilities? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:50, 7 May 2016 (UTC)<br />
<br />
:::Actually another possibility would be to simply use [[dm-crypt#See also]]. For example <br />
:::* [https://www.loganmarchione.com/2014/11/arch-linux-encrypted-lvm-hardware-2/ Loganmarchione blog] - elaborate step-by-step guide referencing [[Dm-crypt/Encrypting an entire system#LVM on LUKS]] (dated: 2014/11)<br />
:::If it gets many links, they could be grouped. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 13:16, 7 May 2016 (UTC)<br />
<br />
::::I agree we can use [[dm-crypt#See also]] for the moment, I'll let you implement your idea, or Voukait who pointed out the link :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 04:06, 8 May 2016 (UTC)<br />
<br />
== Rename volume group to be more consistent with device naming ==<br />
<br />
I propose renaming 'MyVol' to 'volumegroup' (or something similar) to improve consistency with the device names (which are all lower case), and make the example more meaningful.<br />
{{Unsigned|08:13, 16 April 2018|Terry tibbles}}<br />
<br />
:I'm not against renaming it, but "volumegroup" is too generic. Also the use of uppercase letters gives a hint to the reader that using them is allowed. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 08:32, 16 April 2018 (UTC)<br />
<br />
::What would your suggestion be? Mine would be the 'volgroup-cryptroot' layout, to keep it as close as possible to the existing examples. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 08:21, 18 April 2018 (UTC)<br />
<br />
:::I think that "volgroup" sounds too generic. Previously the article had "[[Special:Diff/423732|MyStorage]]" and "[[Special:Diff/461158|lvm]]". I'm not good at naming things, so I can't think of a good replacement.<br />
:::Actually I'm not even certain if there's a need to rename the current VG. -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
::::I think it needs to change, as I've done this several times and still find it confusing. If you imagine that someone has several volume groups, it doesn't scale well (MyVol, MyVol1), and also the mix of capital and lower case letters is difficult to read. I think a system with 'vol_group-root_crypt' for encrypted devices and 'root' for the decrypted partition would be preferable. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:25, 18 April 2018 (UTC)<br />
<br />
:::::How exactly is "vol_group" better than "MyVol" in a setup with multiple VGs? -- [[User:nl6720|nl6720]] ([[User talk:nl6720|talk]]) 09:44, 18 April 2018 (UTC)<br />
<br />
:::::I'm not going to argue with you. That's my suggestion for improving the documentation, and making it more consistent and user-friendly. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 06:37, 19 April 2018 (UTC)<br />
<br />
::::'vol_group' does not scale any better than 'MyVol'. Is there really a major difference between 'vol_group1' and 'MyVol1'? Also shouldn't the LVM names be distinguished from physical device names like sda1? One is virtual the other physical. What exactly is confusing about 'MyVol'? It's just a placeholder for what you name the volume group. Lastly, different examples use different names or pseudo-variables. Is there really a need to have the entire page consistent beyond each example? Most users will pick one example and the partitioning scheme is clearly defined at the beginning of each example. The names chosen seem trivial as they all represent the same concept of virtual groups and logical volumes. -- [[User:Wincraft71|Wincraft71]] ([[User talk:Wincraft71|talk]]) 10:58, 19 April 2018 (UTC)<br />
<br />
== Add notes to explain /etc/cryptroot layout (revision 517646) ==<br />
<br />
I think these are needed because this process is already complicated, and this may not be obvious to a new user. It needs to be clear that /etc/crypttab is decrypted partitions and encrypted devices, and /etc/fstab is decrypted partitions and mount points. [[User:Terry tibbles|Terry tibbles]] ([[User talk:Terry tibbles|talk]]) 09:09, 18 April 2018 (UTC)<br />
<br />
:(For reference, the [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517646&oldid=517609 original] edit, and my [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=517725&oldid=517649 undo])<br />
:This article is only a collection of particular scenarios, general explanations should be made in the referenced articles; all the scenarios that use crypttab link to [[crypttab]], which new users are supposed to have read before going back to the scenario, therefore I think it's better if you try to improve that section. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:24, 18 April 2018 (UTC)</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_a_non-root_file_system&diff=517347Dm-crypt/Encrypting a non-root file system2018-04-14T09:56:37Z<p>Wincraft71: /* Without losetup */ change external links</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Disk encryption]]<br />
[[ja:Dm-crypt/root 以外のファイルシステムの暗号化]]<br />
[[pl:Dm-crypt/Encrypting a non-root file system]]<br />
The following are examples of encrypting a secondary, i.e. non-root, filesystem with dm-crypt. <br />
== Overview == <br />
Encrypting a secondary filesystem usually protects only sensitive data, while leaving the operating system and program files unencrypted. This is useful for encrypting an external medium, such as a USB drive, so that it can be moved to different computers securely. One might also choose to encrypt sets of data separately according to who has access to it. <br />
<br />
Because dm-crypt is a [[Disk encryption#Block_device_encryption|block-level]] encryption layer, it only encrypts full devices, [[#Partition|full partitions]] and [[#Loop_device|loop devices]]. To encrypt individual files requires a filesystem-level encryption layer, such as [[eCryptfs]] or [[EncFS]]. See [[Disk encryption]] for general information about securing private data.<br />
<br />
== Partition ==<br />
This example covers the encryption of the {{ic|/home}} partition, but it can be applied to any other comparable non-root partition containing user data.<br />
<br />
{{Tip|You can either have a single user's {{ic|/home}} directory on a partition, or create a common partition for all user's {{ic|/home}} partitions.}}<br />
<br />
First make sure the partition is empty (has no file system attached to it). Delete the partition and create an empty one if it has a file system. Then prepare the partition by securely erasing it, see [[Dm-crypt/Drive preparation#Secure erasure of the hard disk drive]]. <br />
<br />
Then setup the LUKS header with:<br />
# cryptsetup ''options'' luksFormat --type luks2 ''device''<br />
<br />
Replace {{ic|''device''}} with the previously created partition. See [[Dm-crypt/Device encryption#Encryption options for LUKS mode]] for details like the available {{ic|''options''}}.<br />
<br />
To gain access to the encrypted partition, unlock it with the device mapper, using:<br />
# cryptsetup open ''device'' ''name''<br />
<br />
After unlocking the partition, it will be available at {{ic|/dev/mapper/''name''}}. Now create a [[file system]] of your choice with:<br />
# mkfs.''fstype'' /dev/mapper/''name''<br />
<br />
Mount the file system to {{ic|/home}}, or if it should be accessible to only one user to {{ic|/home/''username''}}, see [[#Manual mounting and unmounting]].<br />
<br />
{{Tip|Unmount and mount once to verify that the mapping is working as intended.}}<br />
<br />
=== Manual mounting and unmounting ===<br />
To mount the partition:<br />
<br />
# cryptsetup open ''device'' ''name''<br />
# mount -t ''fstype'' /dev/mapper/''name'' /mnt/home<br />
<br />
To unmount it:<br />
<br />
# umount /mnt/home<br />
# cryptsetup close ''name''<br />
<br />
{{Tip|[[GVFS]] can also mount encrypted partitions. One can use a file manager with gvfs support (e.g. [[Thunar]]) to mount the partition, and a password dialog will pop-up. For other desktops, {{Aur|zulucrypt}} also provides a GUI.}}<br />
<br />
=== Automated unlocking and mounting ===<br />
<br />
There are three different solutions for automating the process of unlocking the partition and mounting its filesystem.<br />
<br />
==== At boot time ====<br />
<br />
Using the {{ic|/etc/crypttab}} configuration file, unlocking happens at boot time by systemd's automatic parsing. This is the recommended solution if you want to use one common partition for all user's home partitions or automatically mount another encrypted block device. <br />
<br />
See [[Dm-crypt/System configuration#crypttab]] for references and [[Dm-crypt/System configuration#Mounting at boot time]] for an example set up. <br />
<br />
==== On user login ====<br />
<br />
Using ''pam_exec'' it is possible to unlock (''cryptsetup open'') the partition on user login: this is the recommended solution if you want to have a single user's home directory on a partition. See [[dm-crypt/Mounting at login]].<br />
<br />
Unlocking on user login is also possible with [[pam_mount]].<br />
<br />
== Loop device ==<br />
<br />
There are two methods for using a loop device as an encrypted container, one using {{ic|losetup}} directly and one without.<br />
<br />
=== Without losetup ===<br />
<br />
Using losetup directly can be avoided completely by doing the following [https://wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile]:<br />
<br />
{{bc|1=<br />
# dd if=/dev/urandom of=key.img bs=20M count=1<br />
# cryptsetup --align-payload=1 luksFormat key.img<br />
}}<br />
<br />
Before running {{ic|cryptsetup}}, look at the [[Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode|Encryption options for LUKS mode]] and [[Disk_encryption#Ciphers_and_modes_of_operation|Ciphers and modes of operation]] first to select your additional desired settings.<br />
<br />
The instructions for opening the device and making the [[file system]] are the same as [[#Partition]].<br />
<br />
Having too small of a file will get you a {{ic|Requested offset is beyond real size of device /dev/loop0}} error, but as a rough reference creating a 4 MiB file will encrypt it successfully. [http://archive.is/VOh2p]<br />
<br />
If creating a larger file, {{ic|dd}} from {{ic|/dev/urandom}} will stop after 32 MiB, requiring the {{ic|1=iflag=fullblock}} option to complete the full write. [https://unix.stackexchange.com/questions/178949/why-does-dd-from-dev-urandom-stops-early]<br />
<br />
Manual mounting and unmounting procedure is equivalent to [[#Manual mounting and unmounting]].<br />
<br />
=== Using losetup ===<br />
<br />
A loop device enables to map a blockdevice to a file with the standard util-linux tool {{ic|losetup}}. The file can then contain a filesystem, which can be used quite like any other filesystem. A lot of users know [[TrueCrypt]] as a tool to create encrypted containers. Just about the same functionality can be achieved with a loopback filesystem encrypted with LUKS and is shown in the following example. <br />
<br />
First, start by creating an encrypted container, using an appropriate [[random number generator]]: <br />
<br />
# dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes. <br />
<br />
{{Note|To avoid having to [[Dm-crypt/Device_encryption#Loopback filesystem|resize]] the container later on, make sure to make it larger than the total size of the files to be encrypted, in order to at least also host the associated metadata needed by the internal file system. If you are going to use LUKS mode, its metadata header requires one to two megabytes alone.}}<br />
<br />
Next create the device node {{ic|/dev/loop0}}, so that we can mount/use our container:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|# losetup -f}}.}}<br />
<br />
From now on the procedure is the same as for [[#Partition]], except for the fact that the container is already randomised and will not need another secure erasure.<br />
<br />
{{Tip|Containers with ''dm-crypt'' can be very flexible. Have a look at the features and documentation of [[Tomb]]. It provides a ''dm-crypt'' script wrapper for fast and flexible handling.}}<br />
<br />
==== Manual mounting and unmounting ====<br />
To unmount the container:<br />
<br />
# umount /mnt/secret<br />
# cryptsetup close secret<br />
# losetup -d /dev/loop0<br />
<br />
To mount the container again:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
# cryptsetup open /dev/loop0 secret<br />
# mount -t ext4 /dev/mapper/secret /mnt/secret</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dm-crypt/Specialties&diff=517344Dm-crypt/Specialties2018-04-14T09:48:48Z<p>Wincraft71: /* Preparing the USB key */ rm unneeded reference</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Disk encryption]]<br />
[[ja:Dm-crypt/特記事項]]<br />
<br />
== Securing the unencrypted boot partition ==<br />
<br />
The {{ic|/boot}} partition and the [[Master Boot Record]] are the two areas of the disk that are not encrypted, even in an [[dm-crypt/Encrypting an entire system|encrypted root]] configuration. They cannot usually be encrypted because the [[boot loader]] and BIOS (respectively) are unable to unlock a dm-crypt container in order to continue the boot process. An exception is [[GRUB]], which gained a feature to unlock a LUKS encrypted {{ic|/boot}} - see [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)]]. <br />
<br />
This section describes steps that can be taken to make the boot process more secure. <br />
<br />
{{Warning|Note that securing the {{ic|/boot}} partition and MBR can mitigate numerous attacks that occur during the boot process, but systems configured this way may still be vulnerable to BIOS/UEFI/firmware tampering, hardware keyloggers, cold boot attacks, and many other threats that are beyond the scope of this article. For an overview of system-trust issues and how these relate to full-disk encryption, refer to [http://www.youtube.com/watch?v&#61;pKeiKYA03eE].}}<br />
<br />
=== Booting from a removable device ===<br />
<br />
{{Warning|systemd version 230 cryptsetup generator emits {{ic|RequiresMountsFor}} for crypto keyfile. Therefore, when the filesystem that holds this file is unmounted, it also stops cryptsetup service. This behavior is incorrect because the filesystem and cryptokey is required only once, when the crypto container is initially setup. See [https://github.com/systemd/systemd/issues/3816 systemd issue 3816].}}<br />
<br />
Using a separate device to boot a system is a fairly straightforward procedure, and offers a significant security improvement against some kinds of attacks. Two vulnerable parts of a system employing an [[Dm-crypt/Encrypting_an_entire_system|encrypted root filesystem]] are<br />
<br />
* the [[Master Boot Record]], and<br />
* the {{ic|/boot}} partition.<br />
<br />
These must be stored unencrypted in order for the system to boot. In order to protect these from tampering, it is advisable to store them on a removable medium, such as a USB drive, and boot from that drive instead of the hard disk. As long as you keep the drive with you at all times, you can be certain that those components have not been tampered with, making authentication far more secure when unlocking your system.<br />
<br />
It is assumed that you already have your system configured with a dedicated partition mounted at {{ic|/boot}}. If you do not, please follow the steps in [[dm-crypt/System configuration#Boot loader]], substituting your hard disk for a removable drive.<br />
<br />
{{Note|You must make sure your system supports booting from the chosen medium, be it a USB drive, an external hard drive, an SD card, or anything else.}}<br />
<br />
Prepare the removable drive ({{ic|/dev/sdx}}).<br />
<br />
# gdisk /dev/sdx #format if necessary. Alternatively, cgdisk, fdisk, cfdisk, gparted...<br />
# mkfs.ext2 /dev/sdx1<br />
# mount /dev/sdx1 /mnt<br />
<br />
Copy your existing {{ic|/boot}} contents to the new one.<br />
<br />
# cp -ai /boot/* /mnt/<br />
<br />
Mount the new partition. Do not forget to update your [[fstab]] file accordingly.<br />
<br />
# umount /boot<br />
# umount /mnt<br />
# mount /dev/sdx1 /boot<br />
# genfstab -p -U / > /etc/fstab<br />
<br />
Update [[GRUB]]. {{ic|grub-mkconfig}} should detect the new partition UUID automatically, but custom menu entries may need to be updated manually.<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
# grub-install /dev/sdx #install to the removable device, not the hard disk.<br />
<br />
Reboot and test the new configuration. Remember to set your device boot order accordingly in your BIOS or [[UEFI]]. If the system fails to boot, you should still be able to boot from the hard drive in order to correct the problem.<br />
<br />
=== chkboot ===<br />
<br />
{{Warning|chkboot makes a {{ic|/boot}} partition '''tamper-evident''', not '''tamper-proof'''. By the time the chkboot script is run, you have already typed your password into a potentially compromised boot loader, kernel, or initrd. If your system fails the chkboot integrity test, no assumptions can be made about the security of your data.}}<br />
<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012, [http://www.heise.de/ct/inhalt/2012/03/6/]) the following script checks files under {{ic|/boot}} for changes of SHA-1 hash, inode, and occupied blocks on the hard drive. It also checks the [[Master Boot Record]]. The script cannot prevent certain type of attacks, but a lot are made harder. No configuration of the script itself is stored in unencrypted {{ic|/boot}}. With a locked/powered-off encrypted system, this makes it harder for some attackers because it is not apparent that an automatic checksum comparison of the partition is done upon boot. However, an attacker who anticipates these precautions can manipulate the firmware to run his own code on top of your kernel and intercept file system access, e.g. to {{ic|boot}}, and present the untampered files. Generally, no security measures below the level of the firmware are able to guarantee trust and tamper evidence.<br />
<br />
The script with installation instructions is [ftp://ftp.heise.de/pub/ct/listings/1203-146.zip available] (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2). There is also package {{AUR|chkboot}} to [[install]].<br />
<br />
After installation add a service file (the package includes one based on the following) and [[enable]] it: <br />
<br />
[Unit]<br />
Description=Check that boot is what we want<br />
Requires=basic.target<br />
After=basic.target<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/local/bin/chkboot.sh<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
<br />
There is a small caveat for systemd. At the time of writing, the original {{ic|chkboot.sh}} script provided contains an empty space at the beginning of {{ic|<u> </u>#!/bin/bash}} which has to be removed for the service to start successfully.<br />
<br />
As {{ic|/usr/local/bin/chkboot_user.sh}} needs to be executed right after login, you need to add it to the [[autostart]] (e.g. under KDE -> ''System Settings -> Startup and Shutdown -> Autostart''; GNOME 3: ''gnome-session-properties''). <br />
<br />
With Arch Linux, changes to {{ic|/boot}} are pretty frequent, for example by new kernels rolling-in. Therefore it may be helpful to use the scripts with every full system update. One way to do so: <br />
<br />
#!/bin/bash<br />
#<br />
# Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically<br />
#<br />
echo "Pacman update [1] Quickcheck before updating" & <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
/usr/local/bin/chkboot.sh<br />
sync # sync disks with any results <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
echo "Pacman update [2] Syncing repos for pacman" <br />
pacman -Syu<br />
/usr/local/bin/chkboot.sh<br />
sync <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user><br />
echo "Pacman update [3] All done, let us roll on ..."<br />
<br />
=== mkinitcpio-chkcryptoboot ===<br />
<br />
{{Warning|This hook does '''not''' encrypt [[GRUB]]'s core (MBR) code or EFI stub, nor does it protect against situations where an attacker is able to modify the behaviour of the bootloader to compromise the kernel and/or initramfs at run-time.}}<br />
<br />
{{aur|mkinitcpio-chkcryptoboot}} is a [[mkinitcpio]] hook that performs integrity checks during early-userspace and advises the user not to enter his root partition password if the system appears to have been compromised. Security is achieved through an [[dm-crypt/Encrypting an entire system#Encrypted boot partition (GRUB)|encrypted boot partition]], which is unlocked using [[GRUB#Boot partition|GRUB]]'s {{ic|cryptodisk.mod}} module, and a root filesystem partition, which is encrypted with a password different from the former. This way, the [[initramfs]] and [[kernel]] are secured against offline tampering, and the root partition can remain secure even if the {{ic|/boot}} partition password is entered on a compromised machine (provided that the chkcryptoboot hook detects the compromise, and is not itself compromised at run-time). <br />
<br />
This hook requires {{Pkg|grub}} release >=2.00 to function, and a dedicated, LUKS encrypted {{ic|/boot}} partition with its own password in order to be secure.<br />
<br />
==== Installation ====<br />
<br />
[[Install]] {{aur|mkinitcpio-chkcryptoboot}} and edit {{ic|/etc/default/chkcryptoboot.conf}}. If you want the ability of detecting if your boot partition was bypassed, edit the {{ic|CMDLINE_NAME}} and {{ic|CMDLINE_VALUE}} variables, with values known only to you. You can follow the advice of using two hashes as is suggested right after the installation. Also, be sure to make the appropriate changes to the [[kernel command line]] in {{ic|/etc/default/grub}}. Edit the {{ic|1=HOOKS=}} line in {{ic|/etc/mkinitcpio.conf}}, and insert the {{ic|chkcryptoboot}} hook '''before''' {{ic|encrypt}}. When finished, [[regenerate the initramfs]].<br />
<br />
==== Technical Overview ====<br />
<br />
{{aur|mkinitcpio-chkcryptoboot}} consists of an install hook and a run-time hook for mkinitcpio. The install hook runs every time the initramfs is rebuilt, and hashes the GRUB [[EFI]] stub ({{ic|$esp/EFI/grub_uefi/grubx64.efi}}) (in the case of [[UEFI]] systems) or the first 446 bytes of the disk on which GRUB is installed (in the case of BIOS systems), and stores that hash inside the initramfs located inside the encrypted {{ic|/boot}} partition. When the system is booted, GRUB prompts for the {{ic|/boot}} password, then the run-time hook performs the same hashing operation and compares the resulting hashes before prompting for the root partition password. If they do not match, the hook will print an error like this:<br />
<br />
CHKCRYPTOBOOT ALERT!<br />
CHANGES HAVE BEEN DETECTED IN YOUR BOOT LOADER EFISTUB!<br />
YOU ARE STRONGLY ADVISED NOT TO ENTER YOUR ROOT CONTAINER PASSWORD!<br />
Please type uppercase yes to continue:<br />
<br />
In addition to hashing the boot loader, the hook also checks the parameters of the running kernel against those configured in {{ic|/etc/default/chkcryptoboot.conf}}. This is checked both at run-time and after the boot process is done. This allows the hook to detect if GRUB's configuration was not bypassed at run-time and afterwards to detect if the entire {{ic|/boot}} partition was not bypassed.<br />
<br />
For BIOS systems the hook creates a hash of GRUB's first stage bootloader (installed to the first 446 bytes of the bootdevice) to compare at the later boot processes. The main second-stage GRUB bootloader {{ic|core.img}} is not checked.<br />
<br />
=== Other methods ===<br />
<br />
Alternatively to above scripts, a hash check can be set up with [[AIDE]] which can be customized via a very flexible configuration file. <br />
<br />
While one of these methods should serve the purpose for most users, they do not address all security problems associated with the unencrypted {{ic|/boot}}. One approach which endeavours to provide a fully authenticated boot chain was published with POTTS as an academic thesis to implement the [http://www1.informatik.uni-erlangen.de/stark STARK] authentication framework. <br />
<br />
The POTTS proof-of-concept uses Arch Linux as a base distribution and implements a system boot chain with <br />
<br />
* POTTS - a boot menu for a one-time authentication message prompt <br />
* TrustedGrub - a [[GRUB Legacy]] implementation which authenticates the kernel and initramfs against TPM chip registers <br />
* TRESOR - a kernel patch which implements AES but keeps the master-key not in RAM but in CPU registers during runtime. <br />
<br />
As part of the thesis [http://13.tc/p/potts/manual.html installation] instructions based on Arch Linux (ISO as of 2013-01) have been published. If you want to try it, be aware these tools are not in standard repositories and the solution will be time consuming to maintain.<br />
<br />
== Using GPG, LUKS, or OpenSSL Encrypted Keyfiles ==<br />
<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?id=155393 Post regarding OpenSSL salted bf-cbc encrypted keys] This post has the {{ic|bfkf}} initcpio hooks, install, and encrypted keyfile generator scripts.<br />
* LUKS: [https://bbs.archlinux.org/viewtopic.php?pid=1502651#p1502651 Post regarding LUKS encrypted keys] with a {{ic|lukskey}} initcpio hook. Or [[#Encrypted /boot and a detached LUKS header on USB]] below with a custom encrypt hook for initcpio.<br />
<br />
Note that:<br />
<br />
* You can follow the above instructions with only two primary partitions, one boot partition (required because of encryption) and one primary LVM partition. Within the LVM partition you can have as many partitions as you need, but most importantly it should contain at least root, swap, and home logical volume partitions. This has the added benefit of having only one keyfile for all your partitions, and having the ability to hibernate your computer (suspend to disk) where the swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} should look like this:{{bc|1=HOOKS=( ... usb usbinput (etwo or ssldec) encrypt (if using openssl) lvm2 resume ... )}} and you should add {{bc|1=resume=/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>}} to your [[kernel parameters]].<br />
* If you need to temporarily store the unencrypted keyfile somewhere, do not store them on an unencrypted disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package {{AUR|gnupg1}}<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
== Remote unlocking of the root (or other) partition ==<br />
<br />
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a [[Wake-on-LAN]] service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running a [[mkinitcpio]] hook that configures a network interface. Some packages listed below contribute various [[Mkinitcpio#Build hooks|mkinitcpio build hooks]] to ease with the configuration.<br />
<br />
{{Note|<br />
* Keep in mind to use kernel device names for the network interface (e.g. {{ic|eth0}}) and not [[udev|udev's]] ones (e.g. {{ic|enp1s0}}), as those will not work.<br />
* It could be necessary to add [[Network configuration#Device driver|the module for your network card]] to the [[Mkinitcpio#MODULES|MODULES]] array.<br />
}}<br />
<br />
=== Remote unlocking (hooks: systemd, systemd-tool) ===<br />
<br />
AUR package {{AUR|mkinitcpio-systemd-tool}} provides a {{Pkg|systemd}}-centric mkinitcpio hook named ''systemd-tool'' with the following set of features for systemd in initramfs:<br />
<br />
{| class="wikitable"<br />
|- style="vertical-align:top;"<br />
| width=50% style="padding:10px;" |<br />
Core features provided by the hook:<br />
* unified systemd + mkinitcpio configuration<br />
* automatic provisioning of binary and config resources<br />
* on-demand invocation of mkinitcpio scripts and in-line functions <br />
| width=50% style="padding:10px;" |<br />
Features provided by the included service units:<br />
* initrd debugging<br />
* early network setup<br />
* interactive user shell<br />
* remote ssh access in initrd<br />
* cryptsetup + custom password agent <br />
|}<br />
<br />
The {{AUR|mkinitcpio-systemd-tool}} package requires the [[mkinitcpio#Common hooks|systemd hook]]. For more information be sure to read the project's [https://github.com/random-archer/mkinitcpio-systemd-tool/blob/master/README.md README] as well as the provided default [https://github.com/random-archer/mkinitcpio-systemd-tool systemd service unit files] to get you started.<br />
<br />
The recommended hooks are: {{ic|base autodetect modconf block filesystems keyboard fsck systemd systemd-tool}}.<br />
<br />
=== Remote unlocking (hooks: netconf, dropbear, tinyssh, ppp) ===<br />
<br />
Another package combination providing remote logins to the initcpio is {{AUR|mkinitcpio-netconf}} and/or {{AUR|mkinitcpio-ppp}} (for remote unlocking using a [[Wikipedia:Point-to-Point Protocol|PPP]] connection over the internet) along with an [[SSH]] server. You have the option of using either {{AUR|mkinitcpio-dropbear}} or {{AUR|mkinitcpio-tinyssh}}. Those hooks do not install any shell, so you also need to [[install]] the {{AUR|mkinitcpio-utils}} package. The instructions below can be used in any combination of the packages above. When there are different paths, it will be noted.<br />
<br />
# If you do not have an SSH key pair yet, [[SSH keys#Generating_an_SSH_key_pair|generate one]] on the client system (the one which will be used to unlock the remote machine). If your choose to use {{AUR|mkinitcpio-tinyssh}}, you have the option of using [[SSH_keys#Ed25519|Ed25519 keys]].<br />
# Insert your SSH public key (i.e. the one you usually put onto hosts so that you can ssh in without a password, or the one you just created and which ends with ''.pub'') into the remote machine's {{ic|/etc/dropbear/root_key}} or {{ic|/etc/tinyssh/root_key}} file. {{Tip|This method can later be used to add other SSH public keys as needed; In the case of simply copying the content of the remote's {{ic|~/.ssh/authorized_keys}}, be sure to verify that it only contains keys you intend to be using to unlock the remote machine. When adding additional keys, regenerate your initrd as well using {{ic|mkinitcpio}}. See also [[Secure Shell#Protection]].}}<br />
# Add all three {{ic|<netconf and/or ppp> <dropbear or tinyssh> encryptssh}} [[Mkinitcpio#HOOKS|hooks]] before {{ic|filesystems}} within the "HOOKS" array in {{ic|/etc/mkinitcpio.conf}} (the {{ic|encryptssh}} replaces the {{ic|encrypt}} hook). Then [[regenerate the initramfs]]. {{Note|The {{ic|net}} hook provided by {{Pkg|mkinitcpio-nfs-utils}} is '''not''' needed.}}<br />
# Configure the required {{ic|1=cryptdevice=}} [[Dm-crypt/System_configuration#Boot_loader|parameter]] and add the {{ic|1=ip=}} [[Kernel_parameters|kernel command parameter]] to your bootloader configuration with the appropriate arguments. For example, if the DHCP server does not attribute a static IP to your remote system, making it difficult to access via SSH accross reboots, you can explicitly state the IP you want to be using:{{bc|<nowiki>ip=192.168.1.1:::::eth0:none</nowiki>}}{{Note|As of version 0.0.4 of {{AUR|mkinitcpio-netconf}}, you can nest multiple {{ic|ip<nowiki>=</nowiki>}} parameters in order to configure multiple interfaces. You cannot mix it with {{ic|ip<nowiki>=</nowiki>dhcp}} ({{ic|ip<nowiki>=</nowiki>:::::eth0:dhcp}}) alone. An interface needs to be specified.}}{{bc|<nowiki>ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none</nowiki>}}For a detailed description have a look at the [[Mkinitcpio#Using net|according mkinitcpio section]]. When finished, update the configuration of your [[bootloader]].<br />
# Finally, restart the remote system and try to [[Secure_Shell#Client usage|ssh to it]], '''explicitly stating the "root" username''' (even if the root account is disabled on the machine, this root user is used only in the initrd for the purpose of unlocking the remote system). If you are using the {{AUR|mkinitcpio-dropbear}} package and you also have the {{Pkg|openssh}} package installed, then you most probably will not get any warnings before logging in, because it convert and use the same host keys openssh uses. (Except Ed25519 keys, dropbear does not support them). In case you are using {{AUR|mkinitcpio-tinyssh}}, you have the option of installing {{AUR|tinyssh-convert}} or {{AUR|tinyssh-convert-git}} so you can use the same keys as your {{Pkg|openssh}} installation (currently only Ed25519 keys). In either case, you should have run [[Secure_Shell#Daemon_management|the ssh daemon]] at least once, using the provided systemd units, so the keys can be generated first. After rebooting the machine, you should be prompted for the passphrase to unlock the root device. Afterwards, the system will complete its boot process and you can ssh to it [[Secure_Shell#Client usage|as you normally would]] (with the remote user of your choice).<br />
<br />
{{Tip|1=If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}}) remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].}}<br />
<br />
=== Remote unlock via wifi (hooks: build your own) ===<br />
<br />
The net hook is normally used with an ethernet connection. In case you want to setup a computer with wireless only, and unlock it via wifi, you can create a custom hook to connect to a wifi network before the net hook is run.<br />
<br />
Below example shows a setup using a usb wifi adapter, connecting to a wifi network protected with WPA2-PSK. In case you use for example WEP or another boot loader, you might need to change some things.<br />
<br />
# Modify {{ic|/etc/mkinitcpio.conf}}:<br />
#* Add the needed kernel module for your specific wifi adatper.<br />
#* Include the {{ic|wpa_passphrase}} and {{ic|wpa_supplicant}} binaries.<br />
#* Add a hook {{ic|wifi}} (or a name of your choice, this is the custom hook that will be created) before the {{ic|net}} hook.{{bc|1=MODULES=(''module'')<br>BINARIES=(wpa_passphrase wpa_supplicant)<br>HOOKS=(base udev autodetect ... '''wifi''' net ... dropbear encryptssh ...)}}<br />
# Create the {{ic|wifi}} hook in {{ic|/etc/initcpio/hooks/wifi}}:{{bc|run_hook ()<br>{<br>&#09;# sleep a couple of seconds so wlan0 is setup by kernel<br>&#09;sleep 5<br><br>&#09;# set wlan0 to up<br>&#09;ip link set wlan0 up<br><br>&#09;# assocciate with wifi network<br>&#09;# 1. save temp config file<br>&#09;wpa_passphrase "''network ESSID''" "''pass phrase''" > /tmp/wifi<br><br>&#09;# 2. assocciate<br>&#09;wpa_supplicant -B -D nl80211,wext -i wlan0 -c /tmp/wifi<br><br>&#09;# sleep a couple of seconds so that wpa_supplicant finishes connecting<br>&#09;sleep 5<br><br>&#09;# wlan0 should now be connected and ready to be assigned an ip by the net hook<br>}<br><br>run_cleanuphook ()<br>{<br>&#09;# kill wpa_supplicant running in the background<br>&#09;killall wpa_supplicant<br><br>&#09;# set wlan0 link down<br>&#09;ip link set wlan0 down<br><br>&#09;# wlan0 should now be fully disconnected from the wifi network<br>}|}}<br />
# Create the hook installation file in {{ic|/etc/initcpio/install/wifi}}:{{bc|build ()<br>{<br>&#09;add_runscript<br>}<br>help ()<br>{<br>cat<<HELPEOF<br>&#09;Enables wifi on boot, for dropbear ssh unlocking of disk.<br>HELPEOF<br>}|}}<br />
# Add {{ic|1=ip=:::::wlan0:dhcp}} to the [[kernel parameters]]. Remove {{ic|1=ip=:::::eth0:dhcp}} so it does not conflict.<br />
# Optionally create an additional boot entry with kernel parameter {{ic|1=ip=:::::eth0:dhcp}}.<br />
# [[Regenerate the initramfs]].<br />
# Update the configuration of your [[boot loader]].<br />
<br />
Remember to setup [[wifi]], so you are able to login once the system is fully booted. In case you are unable to connect to the wifi network, try increasing the sleep times a bit.<br />
<br />
== Discard/TRIM support for solid state drives (SSD) ==<br />
<br />
[[Solid State Drive]] users should be aware that, by default, TRIM commands are not enabled by the device-mapper, i.e. block-devices are mounted without the {{ic|discard}} option unless you override the default. <br />
<br />
The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications.[http://www.saout.de/pipermail/dm-crypt/2011-September/002019.html][http://www.saout.de/pipermail/dm-crypt/2012-April/002420.html] Minimal data leakage in the form of freed block information, perhaps sufficient to determine the filesystem in use, may occur on devices with TRIM enabled. An illustration and discussion of the issues arising from activating TRIM is available in the [http://asalor.blogspot.de/2011/08/trim-dm-crypt-problems.html blog] of a ''cryptsetup'' developer. If you are worried about such factors, keep also in mind that threats may add up: for example, if your device is still encrypted with the previous (cryptsetup <1.6.0) default cipher {{ic|--cipher aes-cbc-essiv}}, more information leakage may occur from trimmed sector observation than with the current [[dm-crypt/Device encryption#Encryption options for LUKS mode|default]]. <br />
<br />
The following cases can be distinguished:<br />
<br />
* The device is encrypted with default dm-crypt LUKS mode:<br />
** By default the LUKS header is stored at the beginning of the device and using TRIM is useful to protect header modifications. If for example a compromised LUKS password is revoked, without TRIM the old header will in general still be available for reading until overwritten by another operation; if the drive is stolen in the meanwhile, the attackers could in theory find a way to locate the old header and use it to decrypt the content with the compromised password. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects cryptsetup FAQ, section 5.19 What about SSDs, Flash and Hybrid Drives?] and [https://www.reddit.com/r/archlinux/comments/2f370s/full_disk_encryption_on_an_ssd/ck5p5c5 Full disk encryption on an ssd]. <br />
** TRIM can be left disabled if the security issues stated at the top of this section are considered a worse threat than the above bullet.<br />
: See also [[Securely wipe disk#Flash memory]].<br />
* The device is encrypted with dm-crypt plain mode, or the LUKS header is stored [[#Encrypted system using a detached LUKS header|separately]]:<br />
** If plausible deniability is required, TRIM should '''never''' be used because of the considerations at the top of this section, or the use of encryption will be given away.<br />
** If plausible deniability is not required, TRIM can be used for its performance gains, provided that the security dangers described at the top of this section are not of concern.<br />
<br />
{{Warning|Before enabling TRIM on a drive, make sure the device fully supports TRIM commands, or data loss can occur. See [[Solid State Drives#TRIM]].}}<br />
<br />
In {{Pkg|linux}} 3.1 and up, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add {{ic|:allow-discards}} to the {{ic|cryptdevice}} option. The TRIM option may look like this:<br />
<br />
cryptdevice=/dev/sdaX:root:allow-discards<br />
<br />
For the main {{ic|cryptdevice}} configuration options before the {{ic|:allow-discards}} see [[Dm-crypt/System configuration]].<br />
<br />
If you are using a systemd based initrd, you must pass:<br />
<br />
rd.luks.options=discard<br />
<br />
Besides the kernel option, it is also required to periodically run {{ic|fstrim}} or mount the filesystem (e.g. {{ic|/dev/mapper/root}} in this example) with the {{ic|discard}} option in {{ic|/etc/fstab}}. For details, please refer to the [[TRIM]] page.<br />
<br />
For LUKS devices unlocked via {{ic|/etc/crypttab}} use option {{ic|discard}}. When manually unlocking devices on the console use {{ic|--allow-discards}}.<br />
<br />
With LUKS2 you can set {{ic|allow-discards}} as a default flag for a device by opening it once with the option {{ic|--persistent}}:<br />
<br />
# cryptsetup --allow-discards --persistent open --type luks2 /dev/sdaX root<br />
<br />
You can confirm the flag is set by looking at the {{ic|cryptsetup luksDump}} output:<br />
<br />
{{hc|# cryptsetup luksDump /dev/sdaX {{!}} grep Flags|<br />
Flags: allow-discards<br />
}}<br />
<br />
== The encrypt hook and multiple disks ==<br />
<br />
{{Tip|{{ic|sd-encrypt}} hook supports unlocking multiple devices. They can be specified on the kernel command line or in {{ic|/etc/crypttab.initramfs}}. See [[dm-crypt/System configuration#Using sd-encrypt hook]].}}<br />
<br />
The {{ic|encrypt}} hook only allows for a '''single''' {{ic|1=cryptdevice=}} entry ({{Bug|23182}}). In system setups with multiple drives this may be limiting, because ''dm-crypt'' has no feature to exceed the physical device. For example, take "LVM on LUKS": The entire LVM exists inside a LUKS mapper. This is perfectly fine for a single-drive system, since there is only one device to decrypt. But what happens when you want to increase the size of the LVM? You cannot, at least not without modifying the {{ic|encrypt}} hook.<br />
<br />
The following sections briefly show alternatives to overcome the limitation. The first deals with how to expand a [[Dm-crypt/Encrypting_an_entire_system#LUKS_on_LVM|LUKS on LVM]] setup to a new disk. The second with modifying the {{ic|encrypt}} hook to unlock multiple disks in LUKS setups without LVM.<br />
<br />
=== Expanding LVM on multiple disks ===<br />
<br />
The management of multiple disks is a basic [[LVM]] feature and a major reason for its partitioning flexibility. It can also be used with ''dm-crypt'', but only if LVM is employed as the first mapper. In such a [[dm-crypt/Encrypting an entire system#LUKS_on_LVM|LUKS on LVM]] setup the encrypted devices are created inside the logical volumes (with a separate passphrase/key per volume). The following covers the steps to expand that setup to another disk. <br />
<br />
{{Warning|Backup! While resizing filesystems may be standard, keep in mind that operations '''may''' go wrong and the following might not apply to a particular setup. Generally, extending a filesystem to free disk space is less problematic than shrinking one. This in particular applies when stacked mappers are used, as it is the case in the following example.}}<br />
<br />
==== Adding a new drive ====<br />
<br />
First, it may be desired to prepare a new disk according to [[dm-crypt/Drive preparation]]. <br />
Second, it is partitioned as a LVM, e.g. all space is allocated to {{ic|/dev/sdY1}} with partition type {{ic|8E00}} (Linux LVM). <br />
Third, the new disk/partition is attached to the existing LVM volume group, e.g.:<br />
<br />
# pvcreate /dev/sdY1<br />
# vgextend MyStorage /dev/sdY1<br />
<br />
==== Extending the logical volume ====<br />
<br />
For the next step, the final allocation of the new diskspace, the logical volume to be extended has to be unmounted. It can be performed for the {{ic|cryptdevice}} root partition, but in this case the procedure has to be performed from an Arch Install ISO. <br />
<br />
In this example, it is assumed that the logical volume for {{ic|/home}} (lv-name {{ic|homevol}}) is going to be expanded with the fresh disk space: <br />
<br />
# umount /home<br />
# fsck /dev/mapper/home<br />
# cryptsetup luksClose /dev/mapper/home<br />
# lvextend -l +100%FREE MyStorage/homevol<br />
<br />
Now the logical volume is extended and the LUKS container comes next: <br />
<br />
# cryptsetup open /dev/mapper/MyStorage-homevol home<br />
# umount /home # as a safety, in case it was automatically remounted<br />
# cryptsetup --verbose resize home<br />
<br />
Finally, the filesystem itself is resized: <br />
<br />
# e2fsck -f /dev/mapper/home<br />
# resize2fs /dev/mapper/home<br />
<br />
Done! If it went to plan, {{ic|/home}} can be remounted <br />
<br />
# mount /dev/mapper/home /home<br />
<br />
and now includes the span to the new disk. Note that the {{ic|cryptsetup resize}} action does not affect encryption keys, they have not changed.<br />
<br />
=== Modifying the encrypt hook for multiple partitions ===<br />
<br />
==== Root filesystem spanning multiple partitions ====<br />
<br />
It is possible to modify the encrypt hook to allow multiple hard drive decrypt root ({{ic|/}}) at boot. One way:<br />
<br />
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2<br />
# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2<br />
# sed -i "s/cryptdevice/cryptdevice2/" /etc/initcpio/hooks/encrypt2<br />
# sed -i "s/cryptkey/cryptkey2/" /etc/initcpio/hooks/encrypt2<br />
<br />
Add {{ic|1=cryptdevice2=}} to your boot options (and {{ic|1=cryptkey2=}} if needed), and add the {{ic|encrypt2}} hook to your [[mkinitcpio.conf]] before rebuilding it. See [[dm-crypt/System configuration]].<br />
<br />
==== Multiple non-root partitions ====<br />
<br />
Maybe you have a requirement for using the {{ic|encrypt}} hook on a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/dev/sd*}} partition, the second to the name you want to attribute). That should be enough.<br />
<br />
The big advantage is you can have everything automated, while setting up {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{pkg|cryptsetup}} package gets upgraded, you will have to change this script again. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
{{Accuracy|Why not use the supported Grub2 right away? See also [[mkinitcpio#Using RAID]]}} <br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
<br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup. [[GRUB]] can handle multiple array definitions just fine:<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
== Encrypted system using a detached LUKS header ==<br />
<br />
This example follows the same setup as in [[dm-crypt/Encrypting an entire system#Plain dm-crypt]], which should be read first before following this guide.<br />
<br />
By using a detached header the encrypted blockdevice itself only carries encrypted data, which gives [[Wikipedia:Deniable encryption|deniable encryption]] as long as the existence of a header is unknown to the attackers. It is similar to using [[dm-crypt/Encrypting an entire system#Plain_dm-crypt|plain dm-crypt]], but with the LUKS advantages such as multiple passphrases for the masterkey and key derivation. Further, using a detached header offers a form of two factor authentication with an easier setup than [[#Using GPG, LUKS, or OpenSSL Encrypted Keyfiles|using GPG or OpenSSL encrypted keyfiles]], while still having a built-in password prompt for multiple retries. See [[Disk encryption#Cryptographic metadata]] for more information.<br />
<br />
See [[dm-crypt/Device encryption#Encryption options for LUKS mode]] for encryption options before performing the first step to setup the encrypted system partition and creating a header file to use with {{ic|cryptsetup}}:<br />
<br />
# dd if=/dev/zero of=header.img bs=4M count=1 conv=notrunc<br />
# cryptsetup luksFormat --type luks2 /dev/sdX --align-payload 8192 --header header.img<br />
<br />
{{Tip|When using option {{ic|--header}}, {{ic|--align-payload}} allows specifying the start of encrypted data on a device. By reserving a space at the beginning of device you have the option of later [[dm-crypt/Device encryption#Restore using cryptsetup|reattaching the LUKS header]]. See {{man|8|cryptsetup}} for values supported by {{ic|--align-payload}}.}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open --header header.img /dev/sdX enc<br />
<br />
Now follow the [[dm-crypt/Encrypting an entire system#Preparing the non-boot partitions|LVM on LUKS setup]] to your requirements. The same applies for [[dm-crypt/Encrypting an entire system#Preparing the boot partition 4|preparing the boot partition]] on the removable device (because if not, there is no point in having a separate header file for unlocking the encrypted disk).<br />
Next move the {{ic|header.img}} onto it:<br />
<br />
# mv header.img /mnt/boot<br />
<br />
Follow the installation procedure up to the mkinitcpio step (you should now be {{ic|arch-chroot}}ed inside the encrypted system). <br />
<br />
{{Tip|1=You will notice that since the system partition only has "random" data, it does not have a partition table and by that an {{ic|UUID}} or a {{ic|LABEL}}. But you can still have a consistent mapping using the [[Persistent block device naming#by-id and by-path]]. E.g. using disk id from {{ic|/dev/disk/by-id/}}.}}<br />
<br />
There are two options for initramfs to support a detached LUKS header.<br />
<br />
=== Using systemd hook ===<br />
<br />
First create {{ic|/etc/crypttab.initramfs}} and add the encrypted device to it. The syntax is defined in {{man|5|crypttab}}<br />
<br />
{{hc|/etc/crypttab.initramfs|2=<br />
enc /dev/disk/by-id/''your-disk_id'' none header=/boot/header.img<br />
}}<br />
<br />
Modify {{ic|/etc/mkinitcpio.conf}} [[Mkinitcpio#Common_hooks|to use systemd]] and add the header to {{ic|FILES}}.<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
...<br />
FILES=('''/boot/header.img''')<br />
...<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''sd-lvm2''' filesystems fsck)<br />
...<br />
}}<br />
<br />
[[Regenerate the initramfs]] and you are done.<br />
<br />
{{Note|No cryptsetup parameters need to be passed to the kernel command line, since{{ic|/etc/crypttab.initramfs}} will be added as {{ic|/etc/crypttab}} in the initramfs. If you wish to specify them in the kernel command line see [[dm-crypt/System configuration#Using sd-encrypt hook]] for the supported options.}}<br />
<br />
=== Modifying encrypt hook ===<br />
<br />
This method shows how to modify the {{ic|encrypt}} hook in order to use a detached LUKS header. <br />
Now the {{ic|encrypt}} hook has to be modified to let {{ic|cryptsetup}} use the separate header ({{Bug|42851}}; base source and idea for these changes [https://bbs.archlinux.org/viewtopic.php?pid=1076346#p1076346 published on the BBS]). Make a copy so it is not overwritten on a [[mkinitcpio]] update:<br />
<br />
# cp /usr/lib/initcpio/hooks/encrypt /etc/initcpio/hooks/encrypt2<br />
# cp /usr/lib/initcpio/install/encrypt /etc/initcpio/install/encrypt2<br />
<br />
{{hc|/etc/initcpio/hooks/encrypt2 (around line 52)|output=<br />
warn_deprecated() {<br />
echo "The syntax 'root=${root}' where '${root}' is an encrypted volume is deprecated"<br />
echo "Use 'cryptdevice=${root}:root root=/dev/mapper/root' instead."<br />
}<br />
<br />
'''local headerFlag=false'''<br />
for cryptopt in ${cryptoptions//,/ }; do<br />
case ${cryptopt} in<br />
allow-discards)<br />
cryptargs="${cryptargs} --allow-discards"<br />
;; <br />
<b>header)<br />
cryptargs="${cryptargs} --header /boot/header.img"<br />
headerFlag=true<br />
;;</b><br />
*) <br />
echo "Encryption option '${cryptopt}' not known, ignoring." >&2 <br />
;; <br />
esac<br />
done<br />
<br />
if resolved=$(resolve_device "${cryptdev}" ${rootdelay}); then<br />
if '''$headerFlag &#124;&#124; '''cryptsetup isLuks ${resolved} >/dev/null 2>&1; then<br />
[ ${DEPRECATED_CRYPT} -eq 1 ] && warn_deprecated<br />
dopassphrase=1<br />
}}<br />
<br />
Now edit the [[mkinitcpio.conf]] to add the {{ic|encrypt2}} and {{ic|lvm2}} hooks, the {{ic|header.img}} to {{ic|FILES}} and the {{ic|loop}} to {{ic|MODULES}}, apart from other configuration the system requires:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
...<br />
MODULES=('''loop''')<br />
...<br />
FILES=('''/boot/header.img''')<br />
...<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt2''' '''lvm2''' filesystems fsck)<br />
...<br />
}}<br />
<br />
This is required so the LUKS header is available on boot allowing the decryption of the system, exempting us from a more complicated setup to mount another separate USB device in order to access the header. After this set up [[Mkinitcpio#Image_creation_and_activation|the initramfs]] is created.<br />
<br />
Next the [[dm-crypt/Encrypting an entire system#Configuring the boot loader 4|boot loader is configured]] to specify the {{ic|1=cryptdevice=}} also passing the new {{ic|header}} option for this setup: <br />
<br />
cryptdevice=/dev/disk/by-id/''your-disk_id'':enc:header<br />
<br />
To finish, following [[dm-crypt/Encrypting an entire system#Post-installation]] is particularly useful with a {{ic|/boot}} partition on an USB storage medium.<br />
<br />
== Encrypted /boot and a detached LUKS header on USB ==<br />
<br />
Rather than embedding the {{ic|header.img}} and keyfile into the [[initramfs]] image, this setup will make your system depend entirely on the usb key rather than just the image to boot, and on the encrypted keyfile inside of the encrypted boot partition. Since the header and keyfile are not included in the [[initramfs]] image and the custom encrypt hook is specifically for the usb's [[Persistent_block_device_naming#by-id_and_by-path|by-id]], you will literally need the usb key to boot.<br />
<br />
For the usb drive, since you are encrypting the drive and the keyfile inside, it is preferred to cascade the ciphers as to not use the same one twice. Whether a [[Wikipedia:Meet-in-the-middle_attack|meet-in-the-middle]] attack would actually be feasible is debatable. You can do twofish-serpent or serpent-twofish.<br />
<br />
=== Preparing the disk devices ===<br />
<br />
{{ic|sdb}} will be assumed to be the USB drive, {{ic|sda}} will be assumed to be the main hard drive.<br />
<br />
Prepare the devices according to [[dm-crypt/Drive preparation]].<br />
<br />
==== Preparing the USB key ====<br />
<br />
Use [[fdisk#gdisk|gdisk]] to partition the disk according to the layout [[Dm-crypt/Encrypting_an_entire_system#Preparing_the_disk_5|shown here]], with the exception that it should only include the first two partitions. So as follows:<br />
<br />
{{hc|# gdisk /dev/sdb|<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 1050623 512.0 MiB EF00 EFI System<br />
2 1050624 1460223 200.0 MiB 8300 Linux filesystem<br />
}}<br />
<br />
Before running {{ic|cryptsetup}}, look at the [[Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode|Encryption options for LUKS mode]] and [[Disk_encryption#Ciphers_and_modes_of_operation|Ciphers and modes of operation]] first to select your desired settings.<br />
<br />
[[Dm-crypt/Encrypting_an_entire_system#Preparing_the_boot_partition_5|Prepare the boot partition]] but don't {{ic|mount}} any partition yet and [[EFI_System_Partition#Format_the_partition|Format the EFI System Partition]].<br />
<br />
# mount /dev/mapper/cryptboot /mnt<br />
# dd if=/dev/urandom of=/mnt/key.img bs=''filesize'' count=1<br />
# cryptsetup --align-payload=1 luksFormat /mnt/key.img<br />
# cryptsetup open /mnt/key.img lukskey<br />
<br />
''filesize'' is in bytes but can be followed by a suffix such as {{ic|M}}. Having too small of a file will get you a nasty {{ic|Requested offset is beyond real size of device /dev/loop0}} error. As a rough reference, creating a 4M file will encrypt it successfully. You should make the file larger than the space needed since the encrypted loop device will be a little smaller than the file's size.<br />
<br />
With a big file, you can use {{ic|1=--keyfile-offset=''offset''}} and {{ic|1=--keyfile-size=''size''}} to navigate to the correct position. [https://wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile]<br />
<br />
Now you should have {{ic|lukskey}} opened in a loop device (underneath {{ic|/dev/loop1}}), mapped as {{ic|/dev/mapper/lukskey}}.<br />
<br />
==== The main drive ====<br />
<br />
# truncate -s 2M /mnt/header.img<br />
# cryptsetup --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' luksFormat /dev/sda --align-payload 4096 --header /mnt/header.img<br />
<br />
Pick an ''offset'' and ''size'' in bytes (8192 bytes is the maximum keyfile size for {{ic|cryptsetup}}).<br />
<br />
# cryptsetup open --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' /dev/sda enc <br />
# cryptsetup close lukskey<br />
# umount /mnt<br />
<br />
Follow [[Dm-crypt/Encrypting_an_entire_system#Preparing_the_logical_volumes|Preparing the logical volumes]] to set up LVM on LUKS.<br />
<br />
See [[Partitioning#Discrete partitions]] for recommendations on the size of your partitions.<br />
<br />
Once your root partition is mounted, {{ic|mount}} your encrypted boot partition as {{ic|/mnt/boot}} and your ESP or EFI partition as {{ic|/mnt/boot/efi}}.<br />
<br />
=== Installation procedure and custom encrypt hook ===<br />
<br />
Follow the [[installation guide]] up to the {{ic|mkinitcpio}} step but do not do it yet, and skip the partitioning, formatting, and mounting steps as they have already been done.<br />
<br />
In order to get the encrypted setup to work, you need to build your own hook, which is thankfully easy to do and here is the code you need. You will have to follow [[Persistent block device naming#by-id and by-path]] to figure out your own {{ic|by-id}} values for the usb and main hard drive (they are linked -> to {{ic|sda}} or {{ic|sdb}}).<br />
<br />
You should be using the {{ic|by-id}} instead of just {{ic|sda}} or {{ic|sdb}} because {{ic|sdX}} can change and this ensures it is the correct device.<br />
<br />
You can name {{ic|customencrypthook}} anything you want, and custom build hooks can be placed in the {{ic|hooks}} and {{ic|install}} folders of {{ic|/etc/initcpio}}. Keep a backup of both files ({{ic|cp}} them over to the {{ic|/home}} partition or your user's {{ic|/home}} directory after you make one). {{ic|/usr/bin/ash}} is not a typo.<br />
<br />
{{hc|/etc/initcpio/hooks/customencrypthook|output=<nowiki><br />
#!/usr/bin/ash<br />
<br />
run_hook() {<br />
modprobe -a -q dm-crypt >/dev/null 2>&1<br />
modprobe loop<br />
[ "${quiet}" = "y" ] && CSQUIET=">/dev/null"<br />
<br />
while [ ! -L '/dev/disk/by-id/</nowiki>''usbdrive''<nowiki>-part2' ]; do<br />
echo 'Waiting for USB'<br />
sleep 1<br />
done<br />
<br />
cryptsetup open /dev/disk/by-id/</nowiki>''usbdrive''<nowiki>-part2 cryptboot<br />
mkdir -p /mnt<br />
mount /dev/mapper/cryptboot /mnt<br />
cryptsetup open /mnt/key.img lukskey<br />
cryptsetup --header /mnt/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' open /dev/disk/by-id/</nowiki>''harddrive''<nowiki> enc<br />
cryptsetup close lukskey<br />
umount /mnt<br />
}<br />
</nowiki>}}<br />
<br />
{{ic|''usbdrive''}} is your USB drive {{ic|by-id}}, and {{ic|''harddrive''}} is your main hard drive {{ic|by-id}}.<br />
<br />
{{Tip|You could also close {{ic|cryptboot}} using {{ic|cryptsetup close}}, but having it open makes it easier to mount for system updates using [[Pacman]] and regenerating the initramfs with [[mkinitcpio]]. The {{ic|/boot}} partition must be mounted for updates that affect the [[kernel]] or [[Initramfs]], and the initramfs will be automatically regenerated after these updates.}}<br />
<br />
# cp /usr/lib/initcpio/install/encrypt /etc/initpcio/install/customencrypthook<br />
<br />
Now edit the copied file and remove the {{ic|help()}} section as it is not necessary.<br />
<br />
{{hc|/etc/mkinitcpio.conf (edit this only do not replace it, these are just excerpts of the necessary parts)|output=<br />
MODULES=(loop)<br />
...<br />
HOOKS=(base udev autodetect modconf block customencrypthook lvm2 filesystems keyboard fsck)<br />
}}<br />
<br />
The {{ic|1=files=()}} and {{ic|1=binaries=()}} arrays are empty, and you should not have to replace {{ic|1=HOOKS=(...)}} array entirely just edit in {{ic|customencrypthook lvm2}} after {{ic|block}} and before {{ic|filesystems}}, and make sure {{ic|systemd}}, {{ic|sd-lvm2}}, and {{ic|encrypt}} are removed.<br />
<br />
==== Boot Loader ====<br />
<br />
Finish the [[Installation_guide#Initramfs|Installation Guide]] from the {{ic|mkinitcpio}} step. To boot you would need either [[GRUB]] or [[efibootmgr]]. Note you can use [[GRUB]] to support the encrypted disks by [[Dm-crypt/Encrypting_an_entire_system#Configuring_the_boot_loader_6|Configuring the boot loader]] but editing the {{ic|GRUB_CMDLINE_LINUX}} is not necessary for this set up.<br />
<br />
Or use Direct UEFI Secure boot by generating keys with {{AUR|cryptboot}} then signing the initramfs and kernel and creating a bootable .efi file for your {{ic|/boot/efi}} directory with {{AUR|sbupdate-git}}. Before using cryptboot or sbupdate note this excerpt from [[Secure Boot#Using your own keys]]:<br />
<br />
{{Tip|Note that {{AUR|cryptboot}} requires the encrypted boot partition to be specified in {{ic|/etc/crypttab}} before it runs, and if you are using it in combination with {{AUR|sbupdate-git}}, sbupdate expects the {{ic|/boot/efikeys/db.*}} files created by cryptboot to be capitalized like {{ic|DB.*}}. Users who do not use systemd to handle encryption may not have anything in their {{ic|/etc/crypttab}} file and would need to create an entry.<br />
}}<br />
<br />
# efibootmgr -c -d /dev/''device'' -p ''partition_number'' -L "Arch Linux Signed" -l "EFI\Arch\linux-signed.efi"<br />
<br />
See {{man|8|efibootmgr}} for an explanation of the options.<br />
<br />
Make sure the boot order puts {{ic|Arch Linux Signed}} first. If not change it with {{ic|efibootmgr -o XXXX,YYYY,ZZZZ}}.<br />
<br />
=== Changing the LUKS keyfile ===<br />
<br />
{{Merge|dm-crypt/Device encryption#Keyfiles|Changing the keyfile is not a required action in this setup.}}<br />
<br />
# cryptsetup --header /boot/header.img --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' luksChangeKey /dev/mapper/enc /dev/mapper/lukskey2 --new-keyfile-size=''newsize'' --new-keyfile-offset=''newoffset''<br />
<br />
Afterwards, {{ic|cryptsetup close lukskey}} and [[Securely_wipe_disk#shred|shred]] or [[Securely_wipe_disk#dd|dd]] the old keyfile with random data before deleting it, then make sure that the new keyfile is renamed to the same name of the old one: {{ic|key.img}} or other name.</div>Wincraft71https://wiki.archlinux.org/index.php?title=Accessibility&diff=516428Accessibility2018-04-07T19:05:51Z<p>Wincraft71: /* Mouse keys */ It is more helpful to link to the section that specifies where the "keyboard configuration file" should be edited</p>
<hr />
<div>[[Category:Accessibility]]<br />
{{Related articles start}}<br />
{{Related|TalkingArch}}<br />
{{Related articles end}}<br />
[[ja:アクセシビリティ]]<br />
There are many different methods of providing accessibility to users that suffer from a physical or visual handicap. However, unless a [[desktop environment]] is used, the configuration might require some tinkering until one gets it right.<br />
<br />
== Desktop environments ==<br />
<br />
Most modern desktop environments ship with an extensive set of features, among which one can find a tool to configure the accessibility options with. Generally, these options can be found listed under those of 'accessibility', or under those of the corresponding input device (e.g. 'keyboard' and 'mouse'). For example, with [https://help.gnome.org/users/gnome-help/stable/a11y.html.en GNOME] and [https://userbase.kde.org/Applications/Accessibility KDE].<br />
<br />
{{Note|When using the configuration tools of a desktop environment, be weary of possible conflicts with settings of desktop-environment-independent tools.}}<br />
<br />
== Independent to specific desktop environments ==<br />
<br />
The [[Xorg]] server has features (accessx) for physical assistance by setting parameters via the [[X KeyBoard extension]]. This section covers examples.<br />
<br />
For speech recognition, see also [[Text to speech]].<br />
<br />
=== Operating the keyboard ===<br />
<br />
For Braille, see [[Arch Linux for the blind]].<br />
<br />
==== Sticky keys with systemd ====<br />
<br />
In order to enable Sticky Keys in a TTY, you require to know the exact keycodes of the keys to be used. These can be found by a tool like {{Pkg|xorg-xev}} or {{Pkg|xkeycaps}}. Alternatively, you can inspect the output of ''dumpkeys'', provided that the current keymap is correct.<br />
<br />
For example, a Logitech Ultra-X will provide the following keycodes for the modifier keys:<br />
LCtrl = 29<br />
LShift = 42<br />
LAlt = 56<br />
RShift = 54<br />
RCtrl = 97<br />
<br />
Next, use ''dumpkeys'' to determine the range of the keycodes:<br />
# dumpkeys | head -1<br />
keymaps 0-63<br />
<br />
Continue by creating a new file with a suitable name, e.g. "stickyKeys", and use your favourite editor to combine the previously-found information with the desired key function.<br />
<br />
In case of the keycodes found earlier, you would get:<br />
keymaps 0-63<br />
keycode 29 = SCtrl<br />
keycode 42 = SShift<br />
keycode 56 = SAlt<br />
keycode 54 = SShift<br />
keycode 97 = SCtrl<br />
<br />
Here, the letter "S" in front of a modifier key denotes that we want the sticky version of that key.<br />
<br />
{{Note|The following step will change your key mapping in all TTYs. Ensure the correctness of your keycodes, or you might lose the ability to use certain important keys.}}<br />
<br />
Load your new mapping by running the following command:<br />
# loadkeys ./stickyKeys<br />
<br />
If you are satisfied by the results, then move the file to a suitable directory. To have it [[enable]]d on boot, see the following systemd unit: <br />
{{hc|/etc/systemd/system/loadkeys.service|2=<br />
[Unit]<br />
Description="load custom keymap (sticky keys)"<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/loadkeys /path/to/stickyKeys<br />
StandardInput=tty<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=multi-user.target emergency.target rescue.target}}<br />
<br />
==== Sticky keys with xserverrc ====<br />
<br />
One method of enabling desktop environment-independent accessibility function is by passing it through X, given that it is build with XKB support. This can be done by setting parameters for the X server, as specified in its man page:<br />
[+-]accessx [ timeout [ timeout_mask [ feedback [ options_mask ] ] ] ]<br />
enables(+) or disables(-) AccessX key sequences (Sticky Keys).<br />
<br />
-ardelay milliseconds<br />
sets the autorepeat delay (length of time in milliseconds that<br />
a key must be depressed before autorepeat starts).<br />
<br />
-arinterval milliseconds<br />
sets the autorepeat interval (length of time in milliseconds<br />
that should elapse between autorepeat-generated keystrokes).<br />
<br />
These parameters must be placed in the file {{ic|~/.xserverrc}}, which you may need to create.<br />
<br />
For example, to enable Sticky Keys without timeout and without audible or visible feedback, the following can be used:<br />
if [ -z "$XDG_VTNR" ]; then<br />
exec /usr/bin/X -nolisten tcp "$@" +accessx 0 0x1e 0 0xcef<br />
else<br />
exec /usr/bin/X -nolisten tcp "$@" vt$XDG_VTNR +accessx 0 0x1e 0 0xcef<br />
fi<br />
<br />
Note that once X has started, e.g. by executing {{ic|startx}}, it still requires you to press the shift key 5 times to enable Sticky Keys. Unfortunately, this is needed each time X starts. Alternatively, a script can be used to automate this process.<br />
<br />
Similar to most implementations, Sticky Keys can be disabled by pressing a modifier key and any other key at the same time.<br />
<br />
=== Operating the mouse ===<br />
<br />
==== Button mapping ====<br />
<br />
By using ''xmodmap'', you can map functions to mouse buttons independent of your graphical environment. For this, you need to know which physical button on your mouse is read as which number, which can be found by a tool such as {{Pkg|xorg-xev}}. Generally, the physical buttons of left, middle, and right are read as the first, second, and third button, respectively. <br />
<br />
Once you have acquired these, continue by creating a configuration file on a suitable location, e.g. {{ic|~/.mouseconfig}}. Next, open the file with your favourite editor, and write the keyword {{ic|1=pointer = }} followed by an enumeration of the previously-found number of mouse buttons.<br />
<br />
For example, a three button mouse with a scroll wheel is able to provide five physical actions: left, middle, and right click, as well as scroll up and scroll down. This can be mapped to the same functions by using the following line in the configuration file:<br />
pointer = 1 2 3 4 5<br />
<br />
Here, the location will tell the action required to perform an internal mouse-button function. For example, a mapping for left-handed people (left- and right button switched) might look like<br />
pointer = 3 2 1 4 5<br />
<br />
When you are done, you can test and inspect your mapping by running {{ic|xmodmap}}:<br />
$ xmodmap ~/.mouseconfig<br />
$ xmodmap -pp<br />
<br />
Once satisfied, you can enable it on start by placing the first line in {{ic|~/.xinitrc}}.<br />
<br />
==== Mouse keys ====<br />
<br />
[[w:Mouse keys|Mouse keys]] is a Xorg feature (like StickyKeys) to use the keyboard (especially a numeric keypad) as a pointing device. It can replace a mouse, or work beside it. It is disabled by default. You can use<br />
$ xset q | grep "Mouse Keys"<br />
to see status. To enable it for a session:<br />
$ setxkbmap -option keypad:pointerkeys<br />
If you use a [[xmodmap]] configuration, be aware ''setxkbmap'' resets it.<br />
<br />
To enable Mouse keys permanently, add<br />
Option "XkbOptions" "keypad:pointerkeys" <br />
to the keyboard configuration file. This will make the {{ic|Shift+NumLock}} shortcut toggle mouse keys.<br />
<br />
For more see [[Keyboard_configuration_in_Xorg#Using_X_configuration_files]] and [[X KeyBoard extension#Mouse control]] for advanced configuration.<br />
<br />
=== Visual assistance ===<br />
<br />
As with physical assistance, most modern desktop environments ship with an extensive set of features to tweak the visual aspects of your system. Generally, these options can be found listed under those of 'accessibility' or 'visual assistance'. Alternatively, useful options might be found in the settings of the individual applications.<br />
<br />
==== Speech recognition ====<br />
<br />
See [[Speech recognition]].<br />
<br />
==== Console and Virtual Terminal Emulators ====<br />
<br />
* Edit {{ic|/etc/vconsole.conf}}.<br />
* Edit {{ic|~/.Xresources}}.<br />
<br />
== Known issues ==<br />
<br />
* Configuration of input devices is not recognized by software that circumvents the software layer, e.g. [[wine]], [[VirtualBox]], and [[QEMU]].</div>Wincraft71https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_a_non-root_file_system&diff=516046Dm-crypt/Encrypting a non-root file system2018-04-04T23:45:59Z<p>Wincraft71: /* Loop device */ Split off into two methods for loop device</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Disk encryption]]<br />
[[ja:Dm-crypt/root 以外のファイルシステムの暗号化]]<br />
[[pl:Dm-crypt/Encrypting a non-root file system]]<br />
The following are examples of encrypting a secondary, i.e. non-root, filesystem with dm-crypt. <br />
== Overview == <br />
Encrypting a secondary filesystem usually protects only sensitive data, while leaving the operating system and program files unencrypted. This is useful for encrypting an external medium, such as a USB drive, so that it can be moved to different computers securely. One might also choose to encrypt sets of data separately according to who has access to it. <br />
<br />
Because dm-crypt is a [[Disk encryption#Block_device_encryption|block-level]] encryption layer, it only encrypts full devices, [[#Partition|full partitions]] and [[#Loop_device|loop devices]]. To encrypt individual files requires a filesystem-level encryption layer, such as [[eCryptfs]] or [[EncFS]]. See [[Disk encryption]] for general information about securing private data.<br />
<br />
== Partition ==<br />
This example covers the encryption of the {{ic|/home}} partition, but it can be applied to any other comparable non-root partition containing user data.<br />
<br />
{{Tip|You can either have a single user's {{ic|/home}} directory on a partition, or create a common partition for all user's {{ic|/home}} partitions.}}<br />
<br />
First make sure the partition is empty (has no file system attached to it). Delete the partition and create an empty one if it has a file system. Then prepare the partition by securely erasing it, see [[Dm-crypt/Drive preparation#Secure erasure of the hard disk drive]]. <br />
<br />
Then setup the LUKS header with:<br />
# cryptsetup ''options'' luksFormat --type luks2 ''device''<br />
<br />
Replace {{ic|''device''}} with the previously created partition. See [[Dm-crypt/Device encryption#Encryption options for LUKS mode]] for details like the available {{ic|''options''}}.<br />
<br />
To gain access to the encrypted partition, unlock it with the device mapper, using:<br />
# cryptsetup open ''device'' ''name''<br />
<br />
After unlocking the partition, it will be available at {{ic|/dev/mapper/''name''}}. Now create a [[file system]] of your choice with:<br />
# mkfs.''fstype'' /dev/mapper/''name''<br />
<br />
Mount the file system to {{ic|/home}}, or if it should be accessible to only one user to {{ic|/home/''username''}}, see [[#Manual mounting and unmounting]].<br />
<br />
{{Tip|Unmount and mount once to verify that the mapping is working as intended.}}<br />
<br />
=== Manual mounting and unmounting ===<br />
To mount the partition:<br />
<br />
# cryptsetup open ''device'' ''name''<br />
# mount -t ''fstype'' /dev/mapper/''name'' /mnt/home<br />
<br />
To unmount it:<br />
<br />
# umount /mnt/home<br />
# cryptsetup close ''name''<br />
<br />
{{Tip|[[GVFS]] can also mount encrypted partitions. One can use a file manager with gvfs support (e.g. [[Thunar]]) to mount the partition, and a password dialog will pop-up. For other desktops, {{Aur|zulucrypt}} also provides a GUI.}}<br />
<br />
=== Automated unlocking and mounting ===<br />
<br />
There are three different solutions for automating the process of unlocking the partition and mounting its filesystem.<br />
<br />
==== At boot time ====<br />
<br />
Using the {{ic|/etc/crypttab}} configuration file, unlocking happens at boot time by systemd's automatic parsing. This is the recommended solution if you want to use one common partition for all user's home partitions or automatically mount another encrypted block device. <br />
<br />
See [[Dm-crypt/System configuration#crypttab]] for references and [[Dm-crypt/System configuration#Mounting at boot time]] for an example set up. <br />
<br />
==== On user login ====<br />
<br />
Using ''pam_exec'' it is possible to unlock (''cryptsetup open'') the partition on user login: this is the recommended solution if you want to have a single user's home directory on a partition. See [[dm-crypt/Mounting at login]].<br />
<br />
Unlocking on user login is also possible with [[pam_mount]].<br />
<br />
== Loop device ==<br />
<br />
There are two methods for using a loop device as an encrypted container, one using {{ic|losetup}} directly and one without.<br />
<br />
=== Without losetup ===<br />
<br />
Using losetup directly can be avoided completely by doing the following:<br />
<br />
{{bc|1=<br />
# dd if=/dev/urandom of=key.img bs=20M count=1<br />
# cryptsetup --align-payload=1 luksFormat key.img<br />
}}<br />
<br />
Before running {{ic|cryptsetup}}, look at the [[Dm-crypt/Device_encryption#Encryption_options_for_LUKS_mode|Encryption options for LUKS mode]] and [[Disk_encryption#Ciphers_and_modes_of_operation|Ciphers and modes of operation]] first to select your additional desired settings.<br />
<br />
The instructions for opening the device and making the [[file system]] are the same as [[#Partition]].<br />
<br />
Having too small of a file will get you a {{ic|Requested offset is beyond real size of device /dev/loop0}} error, but as a rough reference creating a 4 MiB file will encrypt it successfully. [https://wiki.gentoo.org/wiki/Custom_Initramfs#Encrypted_keyfile]<br />
<br />
If creating a larger file, {{ic|dd}} from {{ic|/dev/urandom}} will stop after 32 MiB, requiring the {{ic|1=iflag=fullblock}} option to complete the full write. [https://unix.stackexchange.com/questions/178949/why-does-dd-from-dev-urandom-stops-early]<br />
<br />
Manual mounting and unmounting procedure is equivalent to [[#Manual mounting and unmounting]].<br />
<br />
=== Using losetup ===<br />
<br />
A loop device enables to map a blockdevice to a file with the standard util-linux tool {{ic|losetup}}. The file can then contain a filesystem, which can be used quite like any other filesystem. A lot of users know [[TrueCrypt]] as a tool to create encrypted containers. Just about the same functionality can be achieved with a loopback filesystem encrypted with LUKS and is shown in the following example. <br />
<br />
First, start by creating an encrypted container, using an appropriate [[random number generator]]: <br />
<br />
# dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes. <br />
<br />
{{Note|To avoid having to [[Dm-crypt/Device_encryption#Loopback filesystem|resize]] the container later on, make sure to make it larger than the total size of the files to be encrypted, in order to at least also host the associated metadata needed by the internal file system. If you are going to use LUKS mode, its metadata header requires one to two megabytes alone.}}<br />
<br />
Next create the device node {{ic|/dev/loop0}}, so that we can mount/use our container:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|# losetup -f}}.}}<br />
<br />
From now on the procedure is the same as for [[#Partition]], except for the fact that the container is already randomised and will not need another secure erasure.<br />
<br />
{{Tip|Containers with ''dm-crypt'' can be very flexible. Have a look at the features and documentation of [[Tomb]]. It provides a ''dm-crypt'' script wrapper for fast and flexible handling.}}<br />
<br />
==== Manual mounting and unmounting ====<br />
To unmount the container:<br />
<br />
# umount /mnt/secret<br />
# cryptsetup close secret<br />
# losetup -d /dev/loop0<br />
<br />
To mount the container again:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
# cryptsetup open /dev/loop0 secret<br />
# mount -t ext4 /dev/mapper/secret /mnt/secret</div>Wincraft71