https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ernetas&feedformat=atomArchWiki - User contributions [en]2024-03-29T09:30:49ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Dm-crypt/Specialties&diff=785751Dm-crypt/Specialties2023-08-19T10:48:20Z<p>Ernetas: Highlight what needs to be added</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[es:Dm-crypt (Español)/Specialties]]<br />
[[ja:Dm-crypt/特記事項]]<br />
[[pl:Dm-crypt (Polski)/Specialties]]<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|1=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 [https://www.youtube.com/watch?v=pKeiKYA03eE].}}<br />
<br />
{{Note|When using [[UEFI]], only an [[ESP]] needs to remain unencrypted, if using [[Unified kernel image]]s for example. You can then use [[Secure Boot]] to make sure the boot chain has not been tampered with, which is an easy way to achieve the same result as the below methods. See [[dm-crypt/Encrypting an entire system#Simple encrypted root with TPM2 and Secure Boot]].}}<br />
<br />
=== Booting from a removable device ===<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#Kernel parameters]], 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 #for BIOS systems<br />
# mkfs.fat -F 32 /dev/sdx1 #for UEFI systems<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. for BIOS systems <br />
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub #for UEFI systems<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, [https://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 their 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 [https://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 installing, [[enable]] {{ic|chkboot.service}}.<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/sh<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<br />
/usr/local/bin/chkboot.sh<br />
sudo -u ''<user>'' /usr/local/bin/chkboot_user.sh<br />
echo "Pacman update [2] Syncing repos for pacman"<br />
pacman -Syu<br />
/usr/local/bin/chkboot.sh<br />
sudo -u ''<user>'' /usr/local/bin/chkboot_user.sh<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 boot loader 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 their 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#Encrypted /boot|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 boot loader (installed to the first 446 bytes of the bootdevice) to compare at the later boot processes. The main second-stage GRUB boot loader {{ic|core.img}} is not checked.<br />
<br />
=== AIDE ===<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 />
=== STARK ===<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 [https://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 [[Trusted Platform Module|TPM chip]] PCR 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 [https://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/<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 {{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 root (or other) partition ==<br />
<br />
Imagine a system with one or more LUKS encrypted partitions (root or others) or volumes and you need to unlock these partitions/volumes during startup. In this case you need to be able to log in from remote and provide a password during an early boot phase. This can be achieved by using one or more [[mkinitcpio]] hook(s) that configure a network interface and start some kind of SSH server. Some packages listed below contribute various [[Mkinitcpio#Build hooks|mkinitcpio build hooks]] to ease 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 />
* By default, Predictable Network Interface Names are activated and change the kernel device name during late boot. Use [[dmesg]] and look what your Network kernel module does to find the original name (e.g. {{ic|eth0}})<br />
* It could be necessary to add the module for your [[Network configuration/Ethernet#Device driver|ethernet]] or [[Network configuration/Wireless#Device driver|wireless]] network card to the [[Mkinitcpio#MODULES|MODULES]] array.<br />
}}<br />
<br />
=== Busybox based initramfs (built with mkinitcpio) ===<br />
<br />
For busybox based initramfs the packages {{Pkg|mkinitcpio-netconf}} and/or {{AUR|mkinitcpio-ppp}} provide network connectivity. As [[SSH]] server you have the option of using either {{Pkg|mkinitcpio-dropbear}} or {{Pkg|mkinitcpio-tinyssh}}. Those hooks do not install any shell, so you also need to [[install]] the {{Pkg|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). {{Note|<br />
#* {{ic|tinyssh}} only supports [[SSH keys#Ed25519|Ed25519]] and [[SSH keys#ECDSA|ECDSA]] key types without passphrase. If you chose to use {{Pkg|mkinitcpio-tinyssh}}, you need to create/use one of these.<br />
#* {{ic|mkinitcpio-tinyssh}} currently has a bug affecting it's use of tinyssh-convert. See [https://github.com/grazzolini/mkinitcpio-tinyssh/issues/10 Github] for details and a fix.<br />
#* {{ic|mkinitcpio-dropbear}} in version 0.0.3-5 is not compatible with the current dropbear implementation that removed dss. See [https://github.com/grazzolini/mkinitcpio-dropbear/issues/8 Github] for details and a fix.<br />
#}}<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 [[OpenSSH#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#Kernel parameters|parameter]] and add the {{ic|1=ip=}} [[Kernel parameters|kernel command parameter]] to your boot loader configuration with the appropriate arguments. For example, if you want the IP address to be assigned by DHCP, you can use the following parameter: {{bc|1=ip=dhcp}} This is most useful if your DHCP server is configured to always assign the same IP for this host, as otherwise accessing the system via SSH is going to be difficult. In that case, you can use a static IP: {{bc|1=ip=192.168.1.1:::::eth0:none}} Alternatively, you can also specify the subnet mask and gateway required by the network:{{bc|1=ip=192.168.1.1::192.168.1.254:255.255.255.0::eth0:none}}{{Note|As of version 0.0.4 of {{Pkg|mkinitcpio-netconf}}, you can nest multiple {{ic|1=ip=}} parameters in order to configure multiple interfaces. You cannot mix it with {{ic|1=ip=dhcp}} ({{ic|1=ip=:::::eth0:dhcp}}) alone. An interface needs to be specified.{{bc|1=ip=ip=192.168.1.1:::::eth0:none:ip=172.16.1.1:::::eth1:none}}}}If using DHCP, consider adding the {{ic|1=netconf_timeout=}} kernel parameter, to prevent netconf from trying to obtain an IP forever. For a detailed description of the {{ic|1=ip=}} parameter, have a look at the [[Mkinitcpio#Using net|according mkinitcpio section]]. When finished, update the configuration of your [[boot loader]].<br />
# Finally, restart the remote system and try to [[OpenSSH#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 {{Pkg|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, as dropbear does not support them). In case you are using {{Pkg|mkinitcpio-tinyssh}}, a script {{ic|tinyssh-convert}} is bundled, so you can use the same keys as your {{Pkg|openssh}} installation (currently only Ed25519 keys). It may be required to manually copy the host key, via {{ic|tinyssh-convert}}, to {{ic|/etc/tinyssh/sshkeydir}}. In either case, you should have run [[OpenSSH#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. The system will complete its boot process and you can then ssh to it [[OpenSSH#Client usage|as you normally would]] (with the remote user of your choice).<br />
<br />
==== Enabling WiFi ====<br />
<br />
The {{ic|netconf}} 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 use a predefined hook or create a custom hook to connect to a WiFi network before the {{ic|netconf}} hook is run.<br />
<br />
===== Predefined hook =====<br />
<br />
You can install a predefined hook based on the one in this wiki:<br />
<br />
# Install {{AUR|mkinitcpio-wifi}}.<br />
# Configure your WiFi connection by creating a ''wpa_supplicant'' configuration with your network properties: {{bc|wpa_passphrase "ESSID" "passphrase" > /etc/wpa_supplicant/initcpio.conf}}<br />
# Add the {{ic|wifi}} hook before {{ic|netconf}} in your {{ic|/etc/mkinitcpio.conf}}. Your WiFi-related modules should be auto-detected, if not: add them to the {{ic|MODULES}} section.<br />
# Add {{ic|1=ip=:::::wlan0:dhcp}} to the [[kernel parameters]].<br />
# [[Regenerate the initramfs]].<br />
# Update the configuration of your [[boot loader]].<br />
<br />
===== Custom hook =====<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 initramfs generator, you might need to adjust accordingly.<br />
<br />
# Modify {{ic|/etc/mkinitcpio.conf}}:<br />
#* Add the needed kernel module for your specific WiFi adapter.<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;# Associate with WiFi network<br>&#09;# 1. Save temp config file<br>&#09;wpa_passphrase "''network ESSID''" "''pass phrase''" > /tmp/wifi<br><br>&#09;# 2. Associate<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 />
=== systemd based initramfs (built with mkinitcpio) ===<br />
<br />
For systemd based initramfs the AUR package {{AUR|mkinitcpio-systemd-extras}} provides a collection of build hooks (aka install hooks) to achieve network connectivity and SSH login during early boot. Depending on the concrete setup this either gives you access to the initramfs environment via busybox' dash or just a password prompt.<br />
<br />
A minimal setup:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
HOOKS=(base systemd autodetect modconf keyboard sd-vconsole '''sd-network sd-tinyssh''' sd-encrypt<br />
block filesystems fsck)<br />
'''SD_TINYSSH_COMMAND="systemd-tty-ask-password-agent --query --watch"'''<br />
}}<br />
<br />
When building the initramfs with {{ic|mkinitcpio}} this setup copies the already existing configuration of [[systemd-networkd]] from the main system and also tries to copy / convert existing SSH server keys from an existing TinySSH or OpenSSH installation. {{Pkg|tinyssh}} needs to be installed (but not necessarily enabled) on the main system. There are additional configuration parameters in case [[systemd-networkd]] is not used by the main system. See the [https://github.com/wolegis/mkinitcpio-systemd-extras/wiki documentation] of {{AUR|mkinitcpio-systemd-extras}} for further details.<br />
<br />
{{Note|This section used to mention {{Pkg|mkinitcpio-systemd-tool}} as another alternative to achieve remote login and LUKS unlocking during early startup. The approach is completely different as it requires only one additional hook {{ic|systemd-tool}} and all further setup is done in special {{ic|[X-SystemdTool]}} sections in systemd service files. The tool is poorly documented and has effectively been abandoned. Only 4 commits in 2021 and only one (insignificant) in 2022. (See [https://github.com/random-archer/mkinitcpio-systemd-tool/commits/master commits], [https://github.com/random-archer/mkinitcpio-systemd-tool/issues/92 issue #92] and [https://github.com/random-archer/mkinitcpio-systemd-tool/issues/97 issue #97].) Nevertheless, it's still available as an official package in Extra.}}<br />
<br />
=== systemd based initramfs (built with dracut) ===<br />
<br />
If you are using [[dracut]] instead of [[mkinitcpio]], you might want to check out [https://github.com/gsauthof/dracut-sshd dracut-sshd] as an alternative to the above options.<br />
<br />
== One-time password-less reboot ==<br />
<br />
Another method that can be used to reboot a remote, headless or otherwise inaccessible system whilst not needing to be at the terminal to type the encrypted root drive password, is to use a temporary [[Dm-crypt/System configuration#Unlocking with a keyfile|keyfile]]. This will need to be placed in a location that is accessible to the kernel at boot, the [[Dm-crypt/System configuration#cryptkey|cryptkey]] boot parameter will be needed, and that particular keyfile will need to be registered as a valid key by way of the "cryptsetup luksAddKey" command.<br />
<br />
This can be done conveniently with the help of {{AUR|passless-boot}}. The procedure described to setup that tool on [https://gitlab.com/Marcool04/passless-boot the script's readme file] might serve as a template for setting up a home-made solution also. Do take a look at the discussion in the [https://gitlab.com/Marcool04/passless-boot#security-considerations-and-threat-model Security considerations] section.<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 [https://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 />
To enable TRIM support during boot, set the following [[kernel parameters]].<br />
<br />
If using the [[dm-crypt/System configuration#Using encrypt hook|encrypt]] hook:<br />
<br />
cryptdevice=/dev/sdaX:root:allow-discards<br />
<br />
If using the [[sd-encrypt]] hook with systemd-based initramfs:<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|2=<br />
luks-123abcdef-etc UUID=123abcdef-etc none discard<br />
}}<br />
<br />
When manually unlocking devices on the console use {{ic|--allow-discards}}.<br />
<br />
Alternatively, ''cryptsetup'' gained a new {{ic|--allow-discards}} option for opening a blockdevice with the option, as well as a {{man|8|cryptsetup-refresh}} command to persistently set it in the LUKS2 header.<br />
<br />
For example, you can open a LUKS device with the {{ic|--allow-discards}} option to execute a manual ''fstrim'' command:<br />
<br />
# cryptsetup --allow-discards open /dev/sdaX root<br />
<br />
When the device is already opened, the {{ic|open}} action will raise an error. For a LUKS2 device, you can still use the {{ic|refresh}} command in these cases, as well as set the {{ic|--persistent}} option for the LUKS2 header:<br />
<br />
# cryptsetup --allow-discards --persistent refresh 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 />
== Disable workqueue for increased solid state drive (SSD) performance ==<br />
<br />
[[Solid state drive]] users should be aware that, by default, discarding internal read and write workqueue commands are not enabled by the device-mapper, i.e. block-devices are mounted without the {{ic|no_read_workqueue}} and {{ic|no_write_workqueue}} option unless you override the default. <br />
<br />
The {{ic|no_read_workqueue}} and {{ic|no_write_workqueue}} flags were introduced by internal Cloudflare research [https://blog.cloudflare.com/speeding-up-linux-disk-encryption/ Speeding up Linux disk encryption] made while investigating overall encryption performance. One of the conclusions is that internal dm-crypt read and write queues decrease performance for SSD drives. While queuing disk operations makes sense for spinning drives, bypassing the queue and writing data synchronously doubled the throughput and cut the SSD drives' IO await operations latency in half. The patches were upstreamed and are available since {{Pkg|linux}} 5.9 and up [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/drivers/md/dm-crypt.c?id=39d42fa96ba1b7d2544db3f8ed5da8fb0d5cb877].<br />
<br />
{{Tip|{{Pkg|linux-zen}} has dm-crypt workqueues [https://github.com/zen-kernel/zen-kernel/issues/282 disabled by default].}}<br />
<br />
To disable workqueue for LUKS devices unlocked via [[crypttab]] use one or more of the desired {{ic|no-read-workqueue}} or {{ic|no-write-workqueue}} options. E.g.:<br />
<br />
{{hc|/etc/crypttab|2=<br />
luks-123abcdef-etc UUID=123abcdef-etc none no-read-workqueue<br />
}}<br />
<br />
To disable both read and write workqueue add both flags:<br />
<br />
{{hc|/etc/crypttab|2=<br />
luks-123abcdef-etc UUID=123abcdef-etc none no-read-workqueue,no-write-workqueue<br />
}}<br />
<br />
With LUKS2 you can set {{ic|--perf-no_read_workqueue}} and {{ic|--perf-no_write_workqueue}} as default flags for a device by opening it once with the option {{ic|--persistent}}. For example:<br />
<br />
# cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue --persistent open /dev/''sdaX'' root<br />
<br />
When the device is already opened, the {{ic|open}} action will raise an error. You can use the {{ic|refresh}} option in these cases, e.g.:<br />
<br />
# cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh root<br />
<br />
You can confirm which flags are 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: no-read-workqueue<br />
}}<br />
<br />
In any case, you can verify whether the device actually was opened with these flags 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 no_read_workqueue<br />
}}<br />
<br />
{{Note|Setting new persistent flags via {{ic|cryptsetup --persistent}} replaces old flags with new ones instead of adding a new flag to the already set flags. This means if you want to enable both {{ic|--perf-no_read_workqueue}} and {{ic|--perf-no_write_workqueue}} (or more) you have to set them all at once.}}<br />
<br />
Example for setting both {{ic|no_read_workqueue}} and {{ic|no_write_workqueue}} with {{ic|cryptsetup}}:<br />
<br />
# cryptsetup --perf-no_read_workqueue --perf-no_write_workqueue --persistent refresh root<br />
<br />
You can confirm both flags being set by inspecting the LUKS2 {{ic|cryptsetup luksDump}} output:<br />
<br />
{{hc|# cryptsetup luksDump /dev/sdaX {{!}} grep Flags|<br />
Flags: no-read-workqueue no-write-workqueue<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 systemd-cryptsetup-generator]].}}<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 close /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/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 />
Note that [[sd-encrypt]] supports multiple partitions out of the box. If several (or all) partitions opened this way share the same passphrase, sd-encrypt will try it for each and not ask for it multiple times. This may be an easier alternative to the following.<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 [[Data-at-rest 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=16M count=1<br />
# cryptsetup luksFormat /dev/sdX --offset 32768 --header header.img<br />
<br />
{{Tip|The {{ic|--offset}} option 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]]. The value is specified in 512-byte sectors, see {{man|8|cryptsetup-luksFormat}} for more details.}}<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 />
Set the following [[kernel parameters]]:<br />
<br />
rd.luks.name=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=enc rd.luks.options=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=header=/header.img:''UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ'' rd.luks.data=''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''=/dev/disk/by-id/''your-disk_id''<br />
<br />
* Replace {{ic|''XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX''}} with the LUKS super block UUID. It can be acquired with {{ic|cryptsetup luksDump header.img}} or {{ic|blkid -s UUID -o value header.img}}.<br />
* Replace {{ic|1=''UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ''}} with the block device of volume in which the header file is located.<br />
<br />
Alternatively, instead of using the {{ic|rd.luks}} kernel parameters, the options can be specified in a {{ic|/etc/crypttab.initramfs}} file:<br />
<br />
{{hc|/etc/crypttab.initramfs|2=<br />
enc /dev/disk/by-id/''your-disk_id'' none header=/header.img:''UUID=ZZZZZZZZ-ZZZZ-ZZZZ-ZZZZ-ZZZZZZZZZZZZ''<br />
}}<br />
<br />
Next, modify {{ic|/etc/mkinitcpio.conf}} [[Mkinitcpio#Common hooks|to use systemd]] and to include the [[file system]] module for the volume in which the header is located. For example, if it is a [[FAT]] volume:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
...<br />
MODULES=('''vfat''')<br />
...<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' lvm2 filesystems fsck)<br />
...<br />
}}<br />
<br />
[[Regenerate the initramfs]] and you are done.<br />
<br />
{{Note|<br />
* When using {{ic|/etc/crypttab.initramfs}}, 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.<br />
* Refrain from using the {{ic|rd.luks}} kernel parameters together with {{ic|/etc/crypttab.initramfs}} as it can cause conflicts. See the warning in [[dm-crypt/System configuration#Using systemd-cryptsetup-generator]] for details.<br />
}}<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 {{!}}{{!}} '''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 />
{{Out of date|1=This scenario was based on [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&oldid=562642#Encrypted_boot_partition_(GRUB)], whose structure was then changed with [https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=next&oldid=562642].|section=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 [[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|Prepare the boot partition]] but do not {{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 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 (see [[Gentoo: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 16M /mnt/header.img<br />
# cryptsetup --key-file=/dev/mapper/lukskey --keyfile-offset=''offset'' --keyfile-size=''size'' luksFormat /dev/sda --offset 32768 --header /mnt/header.img<br />
<br />
Pick an ''offset'' and ''size'' in bytes (8192 KiB 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 EFI system partition as {{ic|/mnt/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 />
mount --mkdir /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/initcpio/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}} 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|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 EFI system partition 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 --create --disk /dev/''device'' --part ''partition_number'' --label "Arch Linux Signed" --loader "EFI\Arch\linux-signed.efi" --unicode<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 --bootorder XXXX,YYYY,ZZZZ --unicode}}.<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 [[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>Ernetashttps://wiki.archlinux.org/index.php?title=OpenVPN&diff=641336OpenVPN2020-11-11T12:39:16Z<p>Ernetas: /* The update-systemd-resolved custom script */ Fix code formatting</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[ja:OpenVPN]]<br />
[[zh-hans:OpenVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN client in Linux Containers}}<br />
{{Related|OpenVPN server in Linux Containers}}<br />
{{Related|Easy-RSA}}<br />
{{Related articles end}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the [https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN 2.4 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation]. OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. It supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|Ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]]. Additionally it has support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it. It supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. Additionally it supports unencrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms. Overall, it aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint. OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openvpn}} package, which provides both server and client mode.<br />
<br />
Available frontends:<br />
<br />
* {{App| NetworkManager OpenVPN|NetworkManager VPN plugin for OpenVPN.|https://wiki.gnome.org/Projects/NetworkManager/VPN|{{Pkg|networkmanager-openvpn}}}}<br />
* {{App|QOpenVPN|Simple OpenVPN GUI written in PyQt for systemd based distributions.|https://github.com/xmikos/qopenvpn|{{Pkg|qopenvpn}}}}<br />
<br />
== Kernel configuration ==<br />
<br />
OpenVPN requires TUN/TAP support, which is already configured in the default kernel. Users of custom kernel should make sure to enable the {{ic|tun}} module:<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support<br />
}}<br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN service provided by a third party, most of the following can most likely be ignored, especially regarding server setup. Begin with [[#The client config profile]] and skip ahead to [[#Starting OpenVPN]] after that. One should use the provider certificates and instructions, see [[:Category:VPN providers]] for examples that can be adapted to other providers. [[OpenVPN client in Linux Containers]] also has general applicable instructions, while it goes a step further by isolating an OpenVPN client process into a container.<br />
<br />
{{Note|Most free VPN providers will (often only) offer [[PPTP server|PPTP]], which is drastically easier to setup and configure, but [http://poptop.sourceforge.net/dox/protocol-security.phtml not secure].}}<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
When setting up an OpenVPN server, users need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] which is detailed in the [[Easy-RSA]] article. Once the needed certificates, private keys, and associated files are created via following the steps in the separate article, one should have 5 files in {{ic|/etc/openvpn/server}} at this point:<br />
<br />
ca.crt<br />
dh.pem<br />
servername.crt<br />
servername.key<br />
ta.key<br />
<br />
Alternatively, as of OpenVPN 2.4, one can use Easy-RSA to generate certificates and keys using elliptic curves. See the OpenVPN documentation for details.<br />
<br />
== A basic Layer-3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes a basic Layer-3 IP routing configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both servers and clients.<br />
<br />
With the release of v2.4, server configurations are stored in {{ic|/etc/openvpn/server}} and client configurations are stored in {{ic|/etc/openvpn/client}} and each mode has its own respective systemd unit, namely, {{ic|openvpn-client@.service}} and {{ic|openvpn-server@.service}}.<br />
<br />
=== Example configuration ===<br />
<br />
The OpenVPN package comes with a collection of example configuration files for different purposes. The sample server and client configuration files make an ideal starting point for a basic OpenVPN setup with the following features:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI Layer-3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's official IANA port number[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openvpn]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the {{man|8|openvpn}} man page and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, the OpenVPN port must be forwarded on to the server.}}<br />
<br />
Copy the example server configuration file {{ic|/usr/share/openvpn/examples/server.conf}} to {{ic|/etc/openvpn/server/server.conf}}.<br />
<br />
Edit the file making a minimum of the following changes:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
ca ca.crt<br />
cert servername.crt<br />
key servername.key<br />
dh dh.pem<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 0''<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
If TLS with elliptic curves is used, specify {{ic|dh none}} and {{ic|ecdh-curve secp521r1}}. DH parameters file is not used when using elliptic curves. Starting from OpenVPN 2.4.8, it is required to specify the type of elliptic curves in server configuration. Otherwise the server would fail to recognize the curve type and possibly use an incompatible one, resulting in authentication errors.<br />
<br />
==== Hardening the server ====<br />
<br />
If security is a priority, additional configuration is recommended including: limiting the server to use a strong cipher/auth method and (optionally) limiting the set of enabled TLS ciphers to the newer ciphers. Starting from OpenVPN 2.4, the server and the client will automatically negotiate AES-256-GCM in TLS mode.<br />
<br />
Add the following to {{ic|/etc/openvpn/server/server.conf}}:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.2<br />
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA<br />
.<br />
}}<br />
<br />
{{Note|<br />
*The .ovpn client profile '''must''' contain a matching cipher and auth line to work properly (at least with the iOS and Android client).<br />
*Using {{ic|tls-cipher}} incorrectly may cause difficulty with debugging connections and may not be necessary. See [https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher OpenVPN’s community wiki] for more information.}}<br />
<br />
==== Enabling compression ====<br />
Enabling compression is not recommended by upstream; doing so opens to the server the so-called VORACLE attack vector. See [https://community.openvpn.net/openvpn/wiki/VORACLE this] article.<br />
<br />
==== Deviating from the standard port and/or protocol ====<br />
<br />
It is generally recommended to use OpenVPN over UDP, because [http://sites.inka.de/bigred/devel/tcp-tcp.html TCP over TCP is a bad idea][http://adsabs.harvard.edu/abs/2005SPIE.6011..138H].<br />
<br />
Some networks may disallow OpenVPN connections on the default port and/or protocol. One strategy to circumvent this is to mimic HTTPS traffic which is very likely unobstructed.<br />
<br />
To do so, configure {{ic|/etc/openvpn/server/server.conf}} as such:<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto tcp<br />
.<br />
}}<br />
<br />
{{Note|The .ovpn client profile '''must''' contain a matching port and proto line to work properly!}}<br />
<br />
==== Running multiple instances of OpenVPN on different ports on the physical machine ====<br />
<br />
One can have multiple, concurrent instances of OpenVPN running on the same box. Each server needs to be defined in {{ic|/etc/openvpn/server/}} as a separate .conf file. At a minimum, the parallel servers need to be running on different ports. A simple setup directs traffic connecting in to a separate IP pool. More advanced setups are beyond the scope of this guide.<br />
<br />
Consider this example, running 2 concurrent servers, one port 443/udp and another on port 80/tcp.<br />
<br />
First modify {{ic|/etc/openvpn/server/server.conf}} created as so:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto udp<br />
server 10.8.0.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Now copy it and modify the copy to run on 80/tcp:<br />
{{hc|/etc/openvpn/server/server2.conf|<br />
.<br />
port 80<br />
proto tcp<br />
server 10.8.1.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Be sure to setup the corresponding entries in the firewall, see the relevant sections in [[#Firewall configuration]].<br />
<br />
=== The client config profile ===<br />
<br />
Copy the example client configuration file {{ic|/usr/share/openvpn/examples/client.conf}} to {{ic|/etc/openvpn/client/}}.<br />
<br />
Edit the following:<br />
<br />
* The {{ic|remote}} directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]], hostname (as known to the client), or its IP address.<br />
* Uncomment the {{ic|user}} and {{ic|group}} directives to drop privileges.<br />
* The {{ic|ca}}, {{ic|cert}}, and {{ic|key}} parameters to reflect the path and names of the keys and certificates.<br />
* Enable the TLS HMAC handshake protection ({{ic|--tls-crypt}} or {{ic|--tls-auth}}).<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote elmer.acmecorp.org 1194<br />
.<br />
user nobody<br />
group nobody<br />
ca ca.crt<br />
cert client.crt<br />
key client.key<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 1''<br />
}}<br />
<br />
==== Run as unprivileged user ====<br />
<br />
Using the options {{ic|user nobody}} and {{ic|group nobody}} in the configuration file makes ''OpenVPN'' drop its {{ic|root}} privileges after establishing the connection. The downside is that upon VPN disconnect the daemon is unable to delete its set network routes again. If one wants to limit transmitting traffic without the VPN connection, then lingering routes may be considered beneficial. It can also happen, however, that the OpenVPN server pushes updates to routes at runtime of the tunnel. A client with dropped privileges will be unable to perform the update and exit with an error.<br />
<br />
As it could seem to require manual action to manage the routes, the options {{ic|user nobody}} and {{ic|group nobody}} might seem undesirable. Depending on setup, however, there are different ways to handle these situations: <br />
<br />
* For errors of the unit, a simple way is to [[edit]] it and add a {{ic|1=Restart=on-failure}} to the {{ic|[Service]}} section. Though, this alone will not delete any obsoleted routes, so it may happen that the restarted tunnel is not routed properly. <br />
* The package contains the {{ic|/usr/lib/openvpn/plugins/openvpn-plugin-down-root.so}}, which can be used to let ''openvpn'' fork a process with root privileges with the only task to execute a custom script when receiving a down signal from the main process, which is handling the tunnel with dropped privileges (see also its [https://community.openvpn.net/openvpn/browser/plugin/down-root/README?rev=d02a86d37bed69ee3fb63d08913623a86c88da15 README]).<br />
<br />
The OpenVPN HowTo's linked below go further by creating a dedicated non-privileged user/group, instead of the already existing {{ic|nobody}}. The advantage is that this avoids potential risks when sharing a user among daemons:<br />
* The [https://openvpn.net/index.php/open-source/documentation/howto.html#security OpenVPN HowTo] explains another way how to create an unprivileged user mode and wrapper script to have the routes restored automatically.<br />
* It is possible to let OpenVPN start as a non-privileged user in the first place, without ever running as root, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser this OpenVPN wiki] (howto). The howto assumes the presence of System V init, rather than [[Systemd]] and does not cover the handling of {{ic|--up}}/{{ic|--down}} scripts - those should be handled the same way as the ''ip'' command, with additional attention to access rights.<br />
* It is also possible to run OpenVPN from within unprivileged podman container, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser#RunOpenVPNwithinunprivilegedpodmancontainer this section of OpenVPN HowTo]<br />
<br />
{{Tip|[[#openvpn-unroot]] describes a tool to automate above setup.}}<br />
<br />
=== Converting certificates to encrypted .p12 format ===<br />
<br />
Some software will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|openvpn /etc/openvpn/server/server.conf}} (as the root user) on the server, and {{ic|openvpn /etc/openvpn/client/client.conf}} (as the root user) on the client. Example output should be similar to the following:<br />
<br />
{{hc|# openvpn /etc/openvpn/server/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the server, and [[ping]] it from the client.<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the client, and [[ping]] it from the server.<br />
<br />
{{Note|If using a firewall, make sure that IP packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
If experiencing issues when using (remote) services over OpenVPN (e.g. web browsing, [[DNS]], [[NFS]]), it may be needed to set a MTU value manually.<br />
<br />
The following message may indicate the MTU value should be adjusted:<br />
<br />
read UDPv4 [EMSGSIZE Path-MTU=1407]: Message too long (code=90)<br />
<br />
In order to get the maximum segment size (MSS), the client needs to discover the smallest MTU along the path to the server. In order to do this ping the server and disable fragmentation, then specify the maximum packet size [https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn]:<br />
<br />
# ping -M do -s 1500 -c 1 example.com<br />
<br />
Decrease the 1500 value by 10 each time, until the ping succeeds.<br />
<br />
{{Note|Clients that do not support the 'fragment' directive (e.g. OpenELEC, [https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ iOS app]) are not able to connect to a server that uses the {{ic|fragment}} directive. See {{ic|mtu-test}} as alternative solution.}}<br />
<br />
Update the client configuration to use the succeeded MTU value, e.g.:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
tun-mtu 1400 <br />
mssfix 1360<br />
}}<br />
<br />
OpenVPN may be instructed to test the MTU every time on client connect. Be patient, since the client may not inform about the test being run and the connection may appear as nonfunctional until finished. The following will add about 3 minutes to OpenVPN start time. It is advisable to configure the fragment size unless a client will be connecting over many different networks and the bottle neck is not on the server side:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
mtu-test<br />
...<br />
}}<br />
<br />
=== IPv6 ===<br />
<br />
==== Connect to the server via IPv6 ====<br />
<br />
Starting from OpenVPN 2.4, OpenVPN will use {{ic|AF_INET}} defined by the OS when just using {{ic|proto udp}} or {{ic|proto tcp}}, which in most cases will be IPv4 only. To use both IPv4 and IPv6, use {{ic|proto udp6}} or {{ic|proto tcp6}}. To enforce only IPv4-only, you need to use {{ic|proto udp4}} or {{ic|proto tcp4}}. On older OpenVPN versions, one server instance can only support either IPv4 or IPv6.<br />
<br />
==== Provide IPv6 inside the tunnel ====<br />
<br />
In order to provide IPv6 inside the tunnel, have an IPv6 prefix routed to the OpenVPN server. Either set up a static route on the gateway (if a static block is assigned), or use a DHCPv6 client to get a prefix with DHCPv6 Prefix delegation (see [[IPv6#Prefix delegation (DHCPv6-PD)|IPv6 Prefix delegation]] for details). Also consider using a unique local address from the address block fc00::/7. Both methods have advantages and disadvantages:<br />
<br />
* Many ISPs only provide dynamically changing IPv6 prefixes. OpenVPN does not support prefix changes, so change the server.conf every time the prefix is changed (Maybe can be automated with a script).<br />
* ULA addresses are not routed to the Internet, and setting up NAT is not as straightforward as with IPv4. This means one cannot route the entire traffic over the tunnel. Those wanting to connect two sites via IPv6, without the need to connect to the Internet over the tunnel, may want to use the ULA addresses for ease.<br />
<br />
Alternatively, if you have no access to these mentioned methods, an NDP proxy should work. See [https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel this StackExchange post].<br />
<br />
After having received a prefix (a /64 is recommended), append the following to the server.conf:<br />
<br />
server-ipv6 2001:db8:0:123::/64<br />
<br />
This is the IPv6 equivalent to the default 10.8.0.0/24 network of OpenVPN and needs to be taken from the DHCPv6 client. Or use for example fd00:1234::/64.<br />
<br />
Those wanting to push a route to a home network (192.168.1.0/24 equivalent), need to also append:<br />
<br />
push "route-ipv6 2001:db8:0:abc::/64"<br />
<br />
OpenVPN does not yet include DHCPv6, so there is no method to e.g. push DNS server over IPv6. This needs to be done with IPv4. The [https://community.openvpn.net/openvpn/wiki/IPv6 OpenVPN Wiki] provides some other configuration options.<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a VPN connection, start the client's daemon manually with {{ic|openvpn /etc/openvpn/client/client.conf}} as root. The server can be started the same way using its own configuration file (e.g., {{ic|openvpn /etc/openvpn/server/server.conf}}).<br />
<br />
=== systemd service configuration ===<br />
<br />
To start the OpenVPN server automatically at system boot, [[enable]] {{ic|openvpn-server@''configuration''.service}} on the applicable machine. For a client, [[enable]] {{ic|openvpn-client@''configuration''.service}} instead. (Leave {{ic|.conf}} out of the {{ic|''configuration''}} string.)<br />
<br />
For example, if the client configuration file is {{ic|/etc/openvpn/client/''client''.conf}}, the service name is {{ic|openvpn-client@''client''.service}}. Or, if the server configuration file is {{ic|/etc/openvpn/server/''server''.conf}}, the service name is {{ic|openvpn-server@''server''.service}}.<br />
<br />
{{Tip|If {{ic|openvpn-client@''configuration''.service}} units take a long time to start, it might be that your network manager is not triggering the {{ic|network-online.target}} systemd target at the right moment. For example, if you are using [[systemd-networkd]], you might want to properly configure {{ic|systemd-networkd-wait-online.service}}.}}<br />
<br />
=== Letting NetworkManager start a connection ===<br />
<br />
One might not always need to run a VPN tunnel and/or only want to establish it for a specific NetworkManager connection. This can be done by adding a script to {{ic|/etc/NetworkManager/dispatcher.d/}}. In the following example "Provider" is the name of the NetworkManager connection:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-openvpn|2=<br />
#!/bin/bash<br />
<br />
case "$2" in<br />
up)<br />
if [ "$CONNECTION_ID" == "Provider" ]; then<br />
systemctl start openvpn-client@''<configuration>''<br />
fi<br />
;;<br />
down)<br />
systemctl stop openvpn-client@''<configuration>''<br />
;;<br />
esac}}<br />
<br />
See [[NetworkManager#Network services with NetworkManager dispatcher]] for more details.<br />
<br />
=== Gnome configuration ===<br />
<br />
To connect to an OpenVPN server through Gnome's built-in network configuration do the following. First, install {{pkg|networkmanager-openvpn}}. Then go to the Settings menu and choose Network. Click the plus sign to add a new connection and choose VPN. From there, choose OpenVPN and manually enter the settings. One can optionally import [[#The client config profile]]. Yet, be aware NetworkManager does not show error messages for options it does not import. To connect to the VPN simply turn the connection on and check the options are applied (e.g. via {{ic|journalctl -b -u NetworkManager}}).<br />
<br />
== Routing client traffic through the server ==<br />
<br />
Without further configuration only traffic directly to and from the OpenVPN server's IP passes through the VPN. To have other traffic, like web traffic pass through the VPN, correspondent routes must be added. You can either add routes in the client's configuration or configure the server to push these routes to the client.<br />
<br />
To redirect traffic to and from a subnet of the server, add {{ic|push "route <address pool> <subnet>"}} right before the {{ic|remote <address> <port> udp/tcp}}, like:<br />
<br />
route 192.168.1.0 255.255.255.0<br />
<br />
To redirect all traffic including Internet traffic to the server, add the following in the client's configuration:<br />
<br />
redirect-gateway def1 bypass-dhcp ipv6<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option. If you are going IPv6-only, use {{ic|redirect-gateway ipv6 !ipv4}}.<br />
<br />
To make the server push routes, [[append]] {{ic|push "redirect-gateway def1 bypass-dhcp ipv6"}} to the configuration file (i.e. {{ic|/etc/openvpn/server/server.conf}}) [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] of the server. Note this is not a requirement and may even give performance issue:<br />
<br />
push "redirect-gateway def1 bypass-dhcp ipv6"<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option. If you are going IPv6-only, use {{ic|push "redirect-gateway ipv6 !ipv4"}}<br />
<br />
Use the {{ic|push "route <address pool> <subnet>"}} option to allow clients reaching other subnets/devices behind the server:<br />
<br />
push "route 192.168.1.0 255.255.255.0"<br />
push "route 192.168.2.0 255.255.255.0"<br />
<br />
Optionally, push local [[DNS]] settings to clients (e.g. the DNS-server of the router and domain prefix ''.internal''):<br />
<br />
{{Note|One may need to use a simple [[DNS]] forwarder like [[BIND]] and push the IP address of the OpenVPN server as DNS to clients.}}<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "dhcp-option DOMAIN internal"<br />
<br />
After setting up the configuration file, [[Internet_sharing#Enable_packet_forwarding|enable packet forwarding]] on the server. Additionally, the server's [[firewall]] needs to be adjusted to allow VPN traffic, which is described below for both [[#ufw|ufw]] and [[#iptables|iptables]].<br />
<br />
{{Note|There are potential pitfalls when routing all traffic through a VPN server. Refer to the [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect OpenVPN documentation] for more information.}}<br />
<br />
=== Firewall configuration ===<br />
<br />
==== firewalld ====<br />
<br />
If you use the default port 1194, enable the {{ic|openvpn}} service. Otherwise, create a new service with a different port.<br />
<br />
# firewall-cmd --zone=public --add-service openvpn<br />
<br />
Now add masquerade to the zone:<br />
<br />
# firewall-cmd --zone=FedoraServer --add-masquerade<br />
<br />
Make these changes permanent:<br />
<br />
# firewall-cmd --runtime-to-permanent<br />
<br />
==== ufw ====<br />
<br />
In order to allow [[ufw]] forwarding (VPN) traffic [[append]] the following to {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Change {{ic|/etc/ufw/before.rules}}, and [[append]] the following code after the header and before the "*filter" line:<br />
* Change the IP/subnet mask to match the {{ic|server}} set in the OpenVPN server configuration.<br />
* Change the [[Network_configuration#Check_the_connection|network interface]] to the connection used by OpenVPN server.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to the interface<br />
-A POSTROUTING -s 10.8.0.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# Optionally duplicate this line for each subnet if your setup requires it<br />
-A POSTROUTING -s 10.8.1.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# do not delete the "COMMIT" line or the NAT table rules above will not be processed<br />
COMMIT<br />
<br />
# Don't delete these required lines, otherwise there will be errors<br />
*filter<br />
..<br />
}}<br />
<br />
Make sure to open the chosen OpenVPN port (default 1194/udp):<br />
<br />
# ufw allow 1194/udp<br />
<br />
To apply the changes. [[reload]]/[[restart]] ufw:<br />
<br />
# ufw reload<br />
<br />
==== iptables ====<br />
<br />
In order to allow VPN traffic through an [[iptables]] firewall, first create an iptables rule for NAT forwarding [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] on the server. An example (assuming the interface to forward to is named {{ic|eth0}}):<br />
<br />
# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
<br />
If running multiple servers on different IP pools, add a corresponding line for each one, for example:<br />
<br />
# iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE<br />
<br />
If the server cannot be pinged through the VPN, one may need to add explicit rules to open up TUN/TAP interfaces to all traffic. If that is the case, do the following [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn]:<br />
<br />
{{Warning|There are security implications for the following rules if one does not trust all clients which connect to the server. Refer to the [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn OpenVPN documentation on this topic] for more details.}}<br />
<br />
# iptables -A INPUT -i tun+ -j ACCEPT<br />
# iptables -A FORWARD -i tun+ -j ACCEPT<br />
# iptables -A INPUT -i tap+ -j ACCEPT<br />
# iptables -A FORWARD -i tap+ -j ACCEPT<br />
<br />
Additionally be sure to accept connections from the OpenVPN port (default 1194) and through the physical interface:<br />
<br />
# iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT<br />
# iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i tap+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i eth0 -o tap+ -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
<br />
When satisfied, make the changes permanent as shown in [[iptables#Configuration and usage]].<br />
<br />
Those with multiple {{ic|tun}} or {{ic|tap}} interfaces, or more than one VPN configuration can "pin" the name of the interface by specifying it in the OpenVPN config file, e.g. {{ic|tun22}} instead of {{ic|tun}}. This is advantageous if different firewall rules for different interfaces or OpenVPN configurations are wanted.<br />
<br />
=== Prevent leaks if VPN goes down ===<br />
<br />
This prevents all traffic through the default interface (enp3s0 for example) and only allows traffic through tun0.<br />
If the OpenVPN connection drops, the system will lose its internet access thereby preventing connections through the default network interface.<br />
<br />
One may want to set up a script to restart OpenVPN if it goes down.<br />
<br />
==== ufw ====<br />
<br />
# Default policies<br />
ufw default deny incoming<br />
ufw default deny outgoing<br />
<br />
# Openvpn interface (adjust interface accordingly to your configuration)<br />
ufw allow in on tun0<br />
ufw allow out on tun0<br />
<br />
# Local Network (adjust ip accordingly to your configuration)<br />
ufw allow in on enp3s0 from 192.168.1.0/24<br />
ufw allow out on enp3s0 to 192.168.1.0/24<br />
<br />
# Openvpn (adjust port accordingly to your configuration)<br />
ufw allow in on enp3s0 from any port 1194<br />
ufw allow out on enp3s0 to any port 1194<br />
<br />
<br />
{{Warning|DNS '''will not''' work '''unless''' running a dedicated DNS server like [[BIND]].<br />
Alternatively, one can allow DNS leaks. '''Be sure to trust your DNS server!'''<br />
# DNS<br />
ufw allow in from any to any port 53<br />
ufw allow out from any to any port 53<br />
}}<br />
<br />
==== vpnfailsafe ====<br />
<br />
Alternatively, the [https://github.com/wknapik/vpnfailsafe vpnfailsafe] ({{AUR|vpnfailsafe-git}}) script can be used by the client to prevent DNS leaks and ensure that all traffic to the internet goes over the VPN. If the VPN tunnel goes down, internet access will be cut off, except for connections to the VPN server(s). The script contains the functionality of [[#The update-resolv-conf custom script|update-resolv-conf]], so the two do not need to be combined.<br />
<br />
== Layer-3 IPv4 routing==<br />
<br />
This section describes how to connect client/server LANs to each other using Layer-3 IPv4 routing.<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device. See [[Internet sharing#Enable packet forwarding]] for configuration details.<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
By default, all IP packets on a LAN addressed to a different subnet get sent to the default gateway. If the LAN/VPN gateway is also the default gateway, there is no problem and the packets get properly forwarded. If not, the gateway has no way of knowing where to send the packets. There are a couple of solutions to this problem.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
The server is on a LAN using the 10.66.0.0/24 subnet. To inform the client about the available subnet, add a push directive to the server configuration file:{{hc|/etc/openvpn/server/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{Note|To route more LANs from the server to the client, add more push directives to the server configuration file, but keep in mind that the server side LANs will need to know how to route to the client.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* Any subnets used on the client side, must be unique and not in use on the server or by any other client. In this example we will use 192.168.4.0/24 for the clients LAN.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
* The CCD folder must be accessible via user and group defined in the server config file (typically nobody:nobody)<br />
<br />
Create a client configuration directory on the server. It will be searched for a file named the same as the client's common name, and the directives will be applied to the client when it connects.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
Create a file in the client configuration directory called bugs, containing the {{ic|iroute 192.168.4.0 255.255.255.0}} directive. It tells the server what subnet should be routed to the client:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|route 192.168.4.0 255.255.255.0}} directive to the server configuration file. It tells the server what subnet should be routed from the tun device to the server LAN:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{Note|To route more LANs from the client to the server, add more iroute and route directives to the appropriate configuration files, but keep in mind that the client side LANs will need to know how to route to the server.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
By default clients will not see each other. To allow IP packets to flow between clients and/or client LANs, add a client-to-client directive to the server configuration file:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
}}<br />
<br />
In order for another client or client LAN to see a specific client LAN, add a push directive for each client subnet to the server configuration file (this will make the server announce the available subnet(s) to other clients):<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
..<br />
}}<br />
<br />
{{Note|One may need to adjust the [[#Firewall configuration|firewall]] to allow client traffic passing through the VPN server.}}<br />
<br />
== DNS ==<br />
For Linux, the OpenVPN client can receive DNS host information from the server, but the client expects an external command to act on this information. No such commands are configured by default. They must be specified with the {{ic|up}} and {{ic|down}} config options. There are a few alternatives for what scripts to use, but none are officially recognised by OpenVPN, so in order for any of them to work, {{ic|script-security}} must be set to 2. The {{ic|down-root}} plugin can be used instead of the {{ic|down}} option if [[#Run as unprivileged user|running as an unprivileged user]].<br />
<br />
=== The pull-resolv-conf custom scripts ===<br />
These scripts are [https://github.com/OpenVPN/openvpn/tree/master/contrib/pull-resolv-conf maintained by] OpenVPN. They are {{ic|client.up}} and {{ic|client.down}}, and they are packaged in {{ic|/usr/share/openvpn/contrib/pull-resolv-conf/}}. The following is an excerpt of a resulting client configuration using the scripts in conjunction with the {{ic|down-root}} plugin:<br />
<br />
{{hc|/etc/openvpn/client/''clienttunnel''.conf|<br />
user nobody<br />
group nobody<br />
# Optional, choose a suitable path to chroot into<br />
chroot /srv<br />
script-security 2<br />
up /usr/share/openvpn/contrib/pull-resolv-conf/client.up <br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-down-root.so "/usr/share/openvpn/contrib/pull-resolv-conf/client.down tun0"<br />
}}<br />
<br />
These scripts use the {{ic|resolvconf}} command if present. [[Systemd-resolvconf]] and [[Openresolv]] both implement this command. See their wiki pages for more information on getting a working {{ic|resolvconf}} implementation.<br />
<br />
{{Note|As of October 2019, systemd-resolvconf works as long as the systemd-resolved service is running. Openresolv will not work out of the box because {{ic|client.up}} will only create private DNS server entries. These require extra configuration of openresolv to work. See {{ic|man 8 resolvconf}} for more details on private DNS servers in openresolv.}}<br />
<br />
If no implementation of {{ic|resolvconf}} is present, {{ic|client.up}} preserves the existing {{ic|resolv.conf}} at {{ic|/etc/resolv.conf.ovpnsave}} and writes a new one. This new one will not have any of the original DNS servers.<br />
<br />
If you need to edit these scripts, copy them somewhere else and edit them there, so that your changes don't get overwritten by the next {{pkg|openvpn}} package upgrade. {{ic|/etc/openvpn/client}} is a pretty good place.<br />
# cp /usr/share/openvpn/contrib/pull-resolv-conf/* /etc/openvpn/client<br />
# $EDITOR /etc/openvpn/client/client.{up.,down}<br />
# # etc ...<br />
<br />
=== The update-resolv-conf custom script ===<br />
<br />
{{Note|Another script, [[#The update-systemd-resolved custom script|update-systemd-resolved]], is recommended by the author of update-resolv-conf for systems with systemd.}}<br />
<br />
The [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script is available as an alternative to packaged scripts. It needs to be saved for example at {{ic|/etc/openvpn/update-resolv-conf}} and made [[executable]].<br />
<br />
If you prefer a package, there is {{AUR|openvpn-update-resolv-conf-git}} that does above for you. You still need to do the following.<br />
<br />
Once the script is installed add lines like the following into the OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /etc/openvpn/update-resolv-conf<br />
down /etc/openvpn/update-resolv-conf<br />
<br />
{{Note|If manually placing the script on the filesystem, be sure to have {{pkg|openresolv}} installed.}}<br />
<br />
Now, when launching the OpenVPN connection, {{ic|resolv.conf}} should be updated accordingly, and also should get returned to normal when the connection is closed.<br />
<br />
{{Note|When using {{ic|openresolv}} with the ''-p'' or ''-x'' options in a script (as both the included {{ic|client.up}} and {{ic|update-resolv-conf}} scripts currently do), a DNS resolver like {{Pkg|dnsmasq}} or {{Pkg|unbound}} is required for {{ic|openresolv}} to correctly update {{ic|/etc/resolv.conf}}. In contrast, when using the default DNS resolution from {{ic|libc}} the ''-p'' and ''-x'' options must be removed in order for {{ic|/etc/resolv.conf}} to be correctly updated by {{ic|openresolv}}.<br />
For example, if the script contains a command like {{ic|resolvconf -p -a }} and the default DNS resolver from {{ic|libc}} is being used, change the command in the script to be {{ic|resolvconf -a }}.}}<br />
<br />
=== The update-systemd-resolved custom script ===<br />
<br />
{{Note|Since [[systemd]] 229, [[systemd-networkd]] has exposed an API through DBus allowing management of DNS configuration on a per-link basis. Tools such as {{pkg|openresolv}} may not work reliably when {{ic|/etc/resolv.conf}} is managed by {{ic|systemd-resolved}}, and will not work at all if using {{ic|resolve}} instead of {{ic|dns}} in {{ic|/etc/nsswitch.conf}}.}}<br />
<br />
The [https://github.com/jonathanio/update-systemd-resolved update-systemd-resolved] script links OpenVPN with {{ic|systemd-resolved}} via DBus to update the DNS records.<br />
<br />
Copy the script into {{ic|/etc/openvpn/scripts}} and mark as [[executable]] (or [[install]] {{AUR|openvpn-update-systemd-resolved}}) and [[append]] the following lines into the OpenVPN client configuration file:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote example.com 1194 udp<br />
..<br />
script-security 2<br />
setenv PATH /usr/bin<br />
up /etc/openvpn/scripts/update-systemd-resolved<br />
down /etc/openvpn/scripts/update-systemd-resolved<br />
down-pre<br />
}}<br />
<br />
In order to send all DNS traffic through the VPN tunnel and prevent DNS leaks, also add the following line (see [https://github.com/jonathanio/update-systemd-resolved#dns-leakage]):<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
dhcp-option DOMAIN-ROUTE .<br />
}}<br />
<br />
Make sure that the [[systemd-resolved]] service is configured and running. Also, since openvpn 2.5.0-3 scripts are running as openvpn user instead of root. Thus, you need to add a PolicyKit rule to allow OpenVPN systemd units to call DBus with SetLinkDNS:<br />
<br />
{{hc|/etc/polkit-1/rules.d/00-openvpn-resolved.rules|<nowiki><br />
polkit.addRule(function(action, subject) {<br />
if (action.id == 'org.freedesktop.resolve1.set-dns-servers' ||<br />
action.id == 'org.freedesktop.resolve1.set-domains' ||<br />
action.id == 'org.freedesktop.resolve1.set-dnssec') {<br />
if (subject.user == 'openvpn') {<br />
return polkit.Result.YES;<br />
}<br />
}<br />
});</nowiki><br />
}}<br />
<br />
===Override DNS servers using NetworkManager===<br />
<br />
By default {{pkg|networkmanager-openvpn}} plugin appends DNS servers provided by OpenVPN to {{ic|/etc/resolv.conf}}.<br />
<br />
To verify that the correct DNS server(s) are configured, see {{ic|resolvectl status}} if systemd-resolved is in use, for other resolvers see [[Domain name resolution]].<br />
<br />
== Layer-2 Ethernet bridging ==<br />
<br />
{{Expansion|Please add a well thought out section on Layer-2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
== Config generators ==<br />
<br />
{{Warning|Users are highly recommended to pass through the manual configuration described above to gain knowledge about options and usage before using any additional automation scripts.}}<br />
<br />
=== ovpngen ===<br />
<br />
The {{AUR|ovpngen}} package provides a simple shell script that creates OpenVPN compatible tunnel profiles in the unified file format suitable for the OpenVPN Connect app for Android and iOS.<br />
<br />
Simply invoke the script with 5 tokens:<br />
<br />
# Server Fully Qualified Domain Name of the OpenVPN server (or IP address).<br />
# Full path to the CA cert.<br />
# Full path to the client cert.<br />
# Full path to the client private key.<br />
# Full path to the server TLS shared secret key.<br />
# Optionally a port number.<br />
# Optionally a protocol (udp or tcp).<br />
<br />
Example:<br />
<br />
# ovpngen example.org /etc/openvpn/server/ca.crt /etc/easy-rsa/pki/signed/client1.crt /etc/easy-rsa/pki/private/client1.key /etc/openvpn/server/ta.key > foo.ovpn<br />
<br />
If the server is configured to use tls-crypt, as is suggested in [[#The server configuration file]], [https://github.com/graysky2/ovpngen/issues/4 manually edit] the resulting {{ic|foo.ovpn}} replacing {{ic|<tls-auth>}} and {{ic|</tls-auth>}} with {{ic|<tls-crypt>}} and {{ic|</tls-crypt>}}.<br />
<br />
The resulting {{ic|foo.ovpn}} can be edited if desired as the script does insert some commented lines. {{ic|foo.ovpn}} will not automatically route all traffic through the VPN, so you may want to follow [[#Routing client traffic through the server]] to enable redirection.<br />
<br />
The client expects this file to be located in {{ic|/etc/openvpn/client/foo.conf}}. Note the change in file extension from 'ovpn' to 'conf' in this case.<br />
<br />
{{Tip|If the server.conf contains a specified cipher and/or auth line, it is highly recommended that users manually edit the generated .ovpn file adding matching lines for cipher and auth. Failure to do so may results in connection errors!}}<br />
<br />
=== openvpn-unroot ===<br />
<br />
{{Note|If you intend to use a custom script, perhaps for configuring [[#DNS]], you must add these scripts to your config before calling openvpn-unroot on it. Failing to do so will cause problems if the scripts require root permissions.}}<br />
<br />
The steps necessary for OpenVPN to [[#Run as unprivileged user]], can be performed automatically using [https://github.com/wknapik/openvpn-unroot openvpn-unroot] ({{AUR|openvpn-unroot-git}}).<br />
<br />
It automates the actions required for the [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser OpenVPN howto] by adapting it to systemd, and also working around the bug for persistent tun devices mentioned in the note.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Client daemon not reconnecting after suspend ===<br />
<br />
{{AUR|openvpn-reconnect}}, available on the AUR, solves this problem by sending a SIGHUP to openvpn after waking up from suspend.<br />
<br />
Alternatively, restart OpenVPN after suspend by creating the following systemd service:<br />
<br />
{{hc|1=/etc/systemd/system/openvpn-reconnect.service|2=<br />
[Unit]<br />
Description=Restart OpenVPN after suspend<br />
<br />
[Service]<br />
ExecStart=/usr/bin/pkill --signal SIGHUP --exact openvpn<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
[[Enable]] this service for it to take effect.<br />
<br />
=== Connection drops out after some time of inactivity ===<br />
<br />
If the VPN-Connection drops some seconds after it stopped transmitting data and, even though it states it is connected, no data can be transmitted through the tunnel, try adding a {{ic|keepalive}}directive to the server's configuration:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
.<br />
keepalive 10 120<br />
.<br />
.<br />
}}<br />
<br />
In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up.<br />
If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.<br />
<br />
A small ping-interval can increase the stability of the tunnel, but will also cause slightly higher traffic. Depending on the connection, also try lower intervals than 10 seconds.<br />
<br />
=== PID files not present ===<br />
<br />
The default systemd service file for openvpn-client does not have the --writepid flag enabled, despite creating /var/run/openvpn-client. If this breaks a config (such as an i3bar VPN indicator), simply change {{ic|openvpn-client@.service}} using a [[drop-in snippet]]:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf --writepid /var/run/openvpn-client/%i.pid<br />
<br />
=== Route configuration fails with systemd-networkd ===<br />
<br />
When using [[systemd-networkd]] to manage network connections and attempting to tunnel all outgoing traffic through the VPN, OpenVPN may fail to add routes. This is a result of systemd-networkd attempting to manage the tun interface before OpenVPN finishes configuring the routes. When this happens, the following message will appear in the OpenVPN log.<br />
<br />
openvpn[458]: RTNETLINK answers: Network is unreachable<br />
openvpn[458]: ERROR: Linux route add command failed: external program exited with error status: 2<br />
<br />
From systemd-233, systemd-networkd can be configured to ignore the tun connections and allow OpenVPN to manage them. To do this, create the following file:<br />
<br />
{{hc|1=/etc/systemd/network/90-tun-ignore.network|2=<br />
[Match]<br />
Name=tun*<br />
<br />
[Link]<br />
Unmanaged=true<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to apply the changes. To verify that the changes took effect, start the previously problematic OpenVPN connection and run {{ic|networkctl}}. The output should have a line similar to the following:<br />
<br />
7 tun0 none routable unmanaged<br />
<br />
=== tls-crypt unwrap error: packet too short ===<br />
<br />
This error shows up in the server log when a client that does not support tls-crypt, or a client that is misconfigured to use tls-auth while the server is configured to use tls-crypt, attempts to connect.<br />
<br />
To support clients that do not support tls-crypt, replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 0}} (the default) in {{ic|server.conf}}. Also replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 1}} (the default) in {{ic|client.conf}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:OpenVPN]]<br />
* [https://www.infosecwriters.com/text_resources/pdf/securing_communication.pdf Securing Network Communication with Stunnel, OpenSSH, and OpenVPN] (PDF)</div>Ernetashttps://wiki.archlinux.org/index.php?title=OpenVPN&diff=641335OpenVPN2020-11-11T12:37:24Z<p>Ernetas: /* The update-systemd-resolved custom script */ Add Policykit rule to allow updating DNS through DBus</p>
<hr />
<div>[[Category:Virtual Private Network]]<br />
[[de:OpenVPN]]<br />
[[ja:OpenVPN]]<br />
[[zh-hans:OpenVPN]]<br />
{{Related articles start}}<br />
{{Related|OpenVPN client in Linux Containers}}<br />
{{Related|OpenVPN server in Linux Containers}}<br />
{{Related|Easy-RSA}}<br />
{{Related articles end}}<br />
<br />
This article describes a basic installation and configuration of [http://openvpn.net OpenVPN], suitable for private and small business use. For more detailed information, please see the [https://community.openvpn.net/openvpn/wiki/Openvpn24ManPage OpenVPN 2.4 man page] and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation]. OpenVPN is a robust and highly flexible [[Wikipedia:VPN|VPN]] daemon. It supports [[Wikipedia:SSL/TLS|SSL/TLS]] security, [[Wikipedia:Bridging_(networking)|Ethernet bridging]], [[Wikipedia:Transmission_Control_Protocol|TCP]] or [[Wikipedia:User_Datagram_Protocol|UDP]] [[Wikipedia:Tunneling_protocol|tunnel transport]] through [[Wikipedia:Proxy_server|proxies]] or [[Wikipedia:Network address translation|NAT]]. Additionally it has support for dynamic IP addresses and [[Wikipedia:Dynamic_Host_Configuration_Protocol|DHCP]], scalability to hundreds or thousands of users, and portability to most major OS platforms.<br />
<br />
OpenVPN is tightly bound to the [http://www.openssl.org OpenSSL] library, and derives much of its crypto capabilities from it. It supports conventional encryption using a [[Wikipedia:Pre-shared_key|pre-shared secret key]] (Static Key mode) or [[Wikipedia:Public_key|public key security]] ([[Wikipedia:SSL/TLS|SSL/TLS]] mode) using client & server certificates. Additionally it supports unencrypted TCP/UDP tunnels.<br />
<br />
OpenVPN is designed to work with the [[Wikipedia:TUN/TAP|TUN/TAP]] virtual networking interface that exists on most platforms. Overall, it aims to offer many of the key features of [[Wikipedia:Ipsec|IPSec]] but with a relatively lightweight footprint. OpenVPN was written by James Yonan and is published under the [[Wikipedia:GNU General Public License|GNU General Public License (GPL)]].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|openvpn}} package, which provides both server and client mode.<br />
<br />
Available frontends:<br />
<br />
* {{App| NetworkManager OpenVPN|NetworkManager VPN plugin for OpenVPN.|https://wiki.gnome.org/Projects/NetworkManager/VPN|{{Pkg|networkmanager-openvpn}}}}<br />
* {{App|QOpenVPN|Simple OpenVPN GUI written in PyQt for systemd based distributions.|https://github.com/xmikos/qopenvpn|{{Pkg|qopenvpn}}}}<br />
<br />
== Kernel configuration ==<br />
<br />
OpenVPN requires TUN/TAP support, which is already configured in the default kernel. Users of custom kernel should make sure to enable the {{ic|tun}} module:<br />
<br />
{{hc|Kernel config file|<br />
Device Drivers<br />
--> Network device support<br />
[M] Universal TUN/TAP device driver support<br />
}}<br />
<br />
Read [[Kernel modules]] for more information.<br />
<br />
== Connect to a VPN provided by a third party ==<br />
<br />
To connect to a VPN service provided by a third party, most of the following can most likely be ignored, especially regarding server setup. Begin with [[#The client config profile]] and skip ahead to [[#Starting OpenVPN]] after that. One should use the provider certificates and instructions, see [[:Category:VPN providers]] for examples that can be adapted to other providers. [[OpenVPN client in Linux Containers]] also has general applicable instructions, while it goes a step further by isolating an OpenVPN client process into a container.<br />
<br />
{{Note|Most free VPN providers will (often only) offer [[PPTP server|PPTP]], which is drastically easier to setup and configure, but [http://poptop.sourceforge.net/dox/protocol-security.phtml not secure].}}<br />
<br />
== Create a Public Key Infrastructure (PKI) from scratch ==<br />
<br />
When setting up an OpenVPN server, users need to create a [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] which is detailed in the [[Easy-RSA]] article. Once the needed certificates, private keys, and associated files are created via following the steps in the separate article, one should have 5 files in {{ic|/etc/openvpn/server}} at this point:<br />
<br />
ca.crt<br />
dh.pem<br />
servername.crt<br />
servername.key<br />
ta.key<br />
<br />
Alternatively, as of OpenVPN 2.4, one can use Easy-RSA to generate certificates and keys using elliptic curves. See the OpenVPN documentation for details.<br />
<br />
== A basic Layer-3 IP routing configuration ==<br />
<br />
{{Note|Unless otherwise explicitly stated, the rest of this article assumes a basic Layer-3 IP routing configuration.}}<br />
<br />
OpenVPN is an extremely versatile piece of software and many configurations are possible, in fact machines can be both servers and clients.<br />
<br />
With the release of v2.4, server configurations are stored in {{ic|/etc/openvpn/server}} and client configurations are stored in {{ic|/etc/openvpn/client}} and each mode has its own respective systemd unit, namely, {{ic|openvpn-client@.service}} and {{ic|openvpn-server@.service}}.<br />
<br />
=== Example configuration ===<br />
<br />
The OpenVPN package comes with a collection of example configuration files for different purposes. The sample server and client configuration files make an ideal starting point for a basic OpenVPN setup with the following features:<br />
<br />
* Uses [[Wikipedia:Public key infrastructure|Public Key Infrastructure (PKI)]] for authentication.<br />
* Creates a VPN using a virtual TUN network interface (OSI Layer-3 IP routing).<br />
* Listens for client connections on UDP port 1194 (OpenVPN's official IANA port number[https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml?search=openvpn]).<br />
* Distributes virtual addresses to connecting clients from the 10.8.0.0/24 subnet.<br />
<br />
For more advanced configurations, please see the {{man|8|openvpn}} man page and the [http://openvpn.net/index.php/open-source/documentation OpenVPN documentation].<br />
<br />
=== The server configuration file ===<br />
<br />
{{Note|Note that if the server is behind a firewall or a NAT translating router, the OpenVPN port must be forwarded on to the server.}}<br />
<br />
Copy the example server configuration file {{ic|/usr/share/openvpn/examples/server.conf}} to {{ic|/etc/openvpn/server/server.conf}}.<br />
<br />
Edit the file making a minimum of the following changes:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
ca ca.crt<br />
cert servername.crt<br />
key servername.key<br />
dh dh.pem<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 0''<br />
.<br />
user nobody<br />
group nobody<br />
}}<br />
<br />
If TLS with elliptic curves is used, specify {{ic|dh none}} and {{ic|ecdh-curve secp521r1}}. DH parameters file is not used when using elliptic curves. Starting from OpenVPN 2.4.8, it is required to specify the type of elliptic curves in server configuration. Otherwise the server would fail to recognize the curve type and possibly use an incompatible one, resulting in authentication errors.<br />
<br />
==== Hardening the server ====<br />
<br />
If security is a priority, additional configuration is recommended including: limiting the server to use a strong cipher/auth method and (optionally) limiting the set of enabled TLS ciphers to the newer ciphers. Starting from OpenVPN 2.4, the server and the client will automatically negotiate AES-256-GCM in TLS mode.<br />
<br />
Add the following to {{ic|/etc/openvpn/server/server.conf}}:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
cipher AES-256-GCM<br />
auth SHA512<br />
tls-version-min 1.2<br />
tls-cipher TLS-DHE-RSA-WITH-AES-256-GCM-SHA384:TLS-DHE-RSA-WITH-AES-128-GCM-SHA256:TLS-DHE-RSA-WITH-AES-256-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-256-CBC-SHA:TLS-DHE-RSA-WITH-AES-128-CBC-SHA:TLS-DHE-RSA-WITH-CAMELLIA-128-CBC-SHA<br />
.<br />
}}<br />
<br />
{{Note|<br />
*The .ovpn client profile '''must''' contain a matching cipher and auth line to work properly (at least with the iOS and Android client).<br />
*Using {{ic|tls-cipher}} incorrectly may cause difficulty with debugging connections and may not be necessary. See [https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-cipher OpenVPN’s community wiki] for more information.}}<br />
<br />
==== Enabling compression ====<br />
Enabling compression is not recommended by upstream; doing so opens to the server the so-called VORACLE attack vector. See [https://community.openvpn.net/openvpn/wiki/VORACLE this] article.<br />
<br />
==== Deviating from the standard port and/or protocol ====<br />
<br />
It is generally recommended to use OpenVPN over UDP, because [http://sites.inka.de/bigred/devel/tcp-tcp.html TCP over TCP is a bad idea][http://adsabs.harvard.edu/abs/2005SPIE.6011..138H].<br />
<br />
Some networks may disallow OpenVPN connections on the default port and/or protocol. One strategy to circumvent this is to mimic HTTPS traffic which is very likely unobstructed.<br />
<br />
To do so, configure {{ic|/etc/openvpn/server/server.conf}} as such:<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto tcp<br />
.<br />
}}<br />
<br />
{{Note|The .ovpn client profile '''must''' contain a matching port and proto line to work properly!}}<br />
<br />
==== Running multiple instances of OpenVPN on different ports on the physical machine ====<br />
<br />
One can have multiple, concurrent instances of OpenVPN running on the same box. Each server needs to be defined in {{ic|/etc/openvpn/server/}} as a separate .conf file. At a minimum, the parallel servers need to be running on different ports. A simple setup directs traffic connecting in to a separate IP pool. More advanced setups are beyond the scope of this guide.<br />
<br />
Consider this example, running 2 concurrent servers, one port 443/udp and another on port 80/tcp.<br />
<br />
First modify {{ic|/etc/openvpn/server/server.conf}} created as so:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
port 443<br />
proto udp<br />
server 10.8.0.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Now copy it and modify the copy to run on 80/tcp:<br />
{{hc|/etc/openvpn/server/server2.conf|<br />
.<br />
port 80<br />
proto tcp<br />
server 10.8.1.0 255.255.255.0<br />
.<br />
}}<br />
<br />
Be sure to setup the corresponding entries in the firewall, see the relevant sections in [[#Firewall configuration]].<br />
<br />
=== The client config profile ===<br />
<br />
Copy the example client configuration file {{ic|/usr/share/openvpn/examples/client.conf}} to {{ic|/etc/openvpn/client/}}.<br />
<br />
Edit the following:<br />
<br />
* The {{ic|remote}} directive to reflect either the server's [[Wikipedia:Fully qualified domain name|Fully Qualified Domain Name]], hostname (as known to the client), or its IP address.<br />
* Uncomment the {{ic|user}} and {{ic|group}} directives to drop privileges.<br />
* The {{ic|ca}}, {{ic|cert}}, and {{ic|key}} parameters to reflect the path and names of the keys and certificates.<br />
* Enable the TLS HMAC handshake protection ({{ic|--tls-crypt}} or {{ic|--tls-auth}}).<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote elmer.acmecorp.org 1194<br />
.<br />
user nobody<br />
group nobody<br />
ca ca.crt<br />
cert client.crt<br />
key client.key<br />
.<br />
tls-crypt ta.key # Replaces ''tls-auth ta.key 1''<br />
}}<br />
<br />
==== Run as unprivileged user ====<br />
<br />
Using the options {{ic|user nobody}} and {{ic|group nobody}} in the configuration file makes ''OpenVPN'' drop its {{ic|root}} privileges after establishing the connection. The downside is that upon VPN disconnect the daemon is unable to delete its set network routes again. If one wants to limit transmitting traffic without the VPN connection, then lingering routes may be considered beneficial. It can also happen, however, that the OpenVPN server pushes updates to routes at runtime of the tunnel. A client with dropped privileges will be unable to perform the update and exit with an error.<br />
<br />
As it could seem to require manual action to manage the routes, the options {{ic|user nobody}} and {{ic|group nobody}} might seem undesirable. Depending on setup, however, there are different ways to handle these situations: <br />
<br />
* For errors of the unit, a simple way is to [[edit]] it and add a {{ic|1=Restart=on-failure}} to the {{ic|[Service]}} section. Though, this alone will not delete any obsoleted routes, so it may happen that the restarted tunnel is not routed properly. <br />
* The package contains the {{ic|/usr/lib/openvpn/plugins/openvpn-plugin-down-root.so}}, which can be used to let ''openvpn'' fork a process with root privileges with the only task to execute a custom script when receiving a down signal from the main process, which is handling the tunnel with dropped privileges (see also its [https://community.openvpn.net/openvpn/browser/plugin/down-root/README?rev=d02a86d37bed69ee3fb63d08913623a86c88da15 README]).<br />
<br />
The OpenVPN HowTo's linked below go further by creating a dedicated non-privileged user/group, instead of the already existing {{ic|nobody}}. The advantage is that this avoids potential risks when sharing a user among daemons:<br />
* The [https://openvpn.net/index.php/open-source/documentation/howto.html#security OpenVPN HowTo] explains another way how to create an unprivileged user mode and wrapper script to have the routes restored automatically.<br />
* It is possible to let OpenVPN start as a non-privileged user in the first place, without ever running as root, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser this OpenVPN wiki] (howto). The howto assumes the presence of System V init, rather than [[Systemd]] and does not cover the handling of {{ic|--up}}/{{ic|--down}} scripts - those should be handled the same way as the ''ip'' command, with additional attention to access rights.<br />
* It is also possible to run OpenVPN from within unprivileged podman container, see [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser#RunOpenVPNwithinunprivilegedpodmancontainer this section of OpenVPN HowTo]<br />
<br />
{{Tip|[[#openvpn-unroot]] describes a tool to automate above setup.}}<br />
<br />
=== Converting certificates to encrypted .p12 format ===<br />
<br />
Some software will only read VPN certificates that are stored in a password-encrypted .p12 file. These can be generated with the following command:<br />
{{bc|# openssl pkcs12 -export -inkey keys/bugs.key -in keys/bugs.crt -certfile keys/ca.crt -out keys/bugs.p12}}<br />
<br />
=== Testing the OpenVPN configuration ===<br />
<br />
Run {{ic|openvpn /etc/openvpn/server/server.conf}} (as the root user) on the server, and {{ic|openvpn /etc/openvpn/client/client.conf}} (as the root user) on the client. Example output should be similar to the following:<br />
<br />
{{hc|# openvpn /etc/openvpn/server/server.conf|2=<br />
Wed Dec 28 14:41:26 2011 OpenVPN 2.2.1 x86_64-unknown-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:26 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
Wed Dec 28 14:41:26 2011 Diffie-Hellman initialized with 2048 bit key<br />
.<br />
.<br />
Wed Dec 28 14:41:54 2011 bugs/95.126.136.73:48904 MULTI: primary virtual IP for bugs/95.126.136.73:48904: 10.8.0.6<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 PUSH: Received control message: 'PUSH_REQUEST'<br />
Wed Dec 28 14:41:57 2011 bugs/95.126.136.73:48904 SENT CONTROL [bugs]: 'PUSH_REPLY,route 10.8.0.1,topology net30,ping 10,ping-restart 120,ifconfig 10.8.0.6 10.8.0.5' (status=1)<br />
}}<br />
<br />
{{hc|# openvpn /etc/openvpn/client/client.conf|2=<br />
Wed Dec 28 14:41:50 2011 OpenVPN 2.2.1 i686-pc-linux-gnu [SSL] [LZO2] [EPOLL] [eurephia] built on Aug 13 2011<br />
Wed Dec 28 14:41:50 2011 NOTE: OpenVPN 2.1 requires '--script-security 2' or higher to call user-defined scripts or executables<br />
.<br />
.<br />
Wed Dec 28 14:41:57 2011 GID set to nobody<br />
Wed Dec 28 14:41:57 2011 UID set to nobody<br />
Wed Dec 28 14:41:57 2011 Initialization Sequence Completed<br />
}}<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the server, and [[ping]] it from the client.<br />
<br />
[[Network configuration#IP addresses|Find the IP address]] assigned to the tunX interface on the client, and [[ping]] it from the server.<br />
<br />
{{Note|If using a firewall, make sure that IP packets on the TUN device are not blocked.}}<br />
<br />
=== Configure the MTU with Fragment and MSS ===<br />
<br />
If experiencing issues when using (remote) services over OpenVPN (e.g. web browsing, [[DNS]], [[NFS]]), it may be needed to set a MTU value manually.<br />
<br />
The following message may indicate the MTU value should be adjusted:<br />
<br />
read UDPv4 [EMSGSIZE Path-MTU=1407]: Message too long (code=90)<br />
<br />
In order to get the maximum segment size (MSS), the client needs to discover the smallest MTU along the path to the server. In order to do this ping the server and disable fragmentation, then specify the maximum packet size [https://www.sonassi.com/help/troubleshooting/setting-correct-mtu-for-openvpn]:<br />
<br />
# ping -M do -s 1500 -c 1 example.com<br />
<br />
Decrease the 1500 value by 10 each time, until the ping succeeds.<br />
<br />
{{Note|Clients that do not support the 'fragment' directive (e.g. OpenELEC, [https://docs.openvpn.net/connecting/connecting-to-access-server-with-apple-ios/faq-regarding-openvpn-connect-ios/ iOS app]) are not able to connect to a server that uses the {{ic|fragment}} directive. See {{ic|mtu-test}} as alternative solution.}}<br />
<br />
Update the client configuration to use the succeeded MTU value, e.g.:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
tun-mtu 1400 <br />
mssfix 1360<br />
}}<br />
<br />
OpenVPN may be instructed to test the MTU every time on client connect. Be patient, since the client may not inform about the test being run and the connection may appear as nonfunctional until finished. The following will add about 3 minutes to OpenVPN start time. It is advisable to configure the fragment size unless a client will be connecting over many different networks and the bottle neck is not on the server side:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
remote example.com 1194<br />
...<br />
mtu-test<br />
...<br />
}}<br />
<br />
=== IPv6 ===<br />
<br />
==== Connect to the server via IPv6 ====<br />
<br />
Starting from OpenVPN 2.4, OpenVPN will use {{ic|AF_INET}} defined by the OS when just using {{ic|proto udp}} or {{ic|proto tcp}}, which in most cases will be IPv4 only. To use both IPv4 and IPv6, use {{ic|proto udp6}} or {{ic|proto tcp6}}. To enforce only IPv4-only, you need to use {{ic|proto udp4}} or {{ic|proto tcp4}}. On older OpenVPN versions, one server instance can only support either IPv4 or IPv6.<br />
<br />
==== Provide IPv6 inside the tunnel ====<br />
<br />
In order to provide IPv6 inside the tunnel, have an IPv6 prefix routed to the OpenVPN server. Either set up a static route on the gateway (if a static block is assigned), or use a DHCPv6 client to get a prefix with DHCPv6 Prefix delegation (see [[IPv6#Prefix delegation (DHCPv6-PD)|IPv6 Prefix delegation]] for details). Also consider using a unique local address from the address block fc00::/7. Both methods have advantages and disadvantages:<br />
<br />
* Many ISPs only provide dynamically changing IPv6 prefixes. OpenVPN does not support prefix changes, so change the server.conf every time the prefix is changed (Maybe can be automated with a script).<br />
* ULA addresses are not routed to the Internet, and setting up NAT is not as straightforward as with IPv4. This means one cannot route the entire traffic over the tunnel. Those wanting to connect two sites via IPv6, without the need to connect to the Internet over the tunnel, may want to use the ULA addresses for ease.<br />
<br />
Alternatively, if you have no access to these mentioned methods, an NDP proxy should work. See [https://unix.stackexchange.com/questions/136211/routing-public-ipv6-traffic-through-openvpn-tunnel this StackExchange post].<br />
<br />
After having received a prefix (a /64 is recommended), append the following to the server.conf:<br />
<br />
server-ipv6 2001:db8:0:123::/64<br />
<br />
This is the IPv6 equivalent to the default 10.8.0.0/24 network of OpenVPN and needs to be taken from the DHCPv6 client. Or use for example fd00:1234::/64.<br />
<br />
Those wanting to push a route to a home network (192.168.1.0/24 equivalent), need to also append:<br />
<br />
push "route-ipv6 2001:db8:0:abc::/64"<br />
<br />
OpenVPN does not yet include DHCPv6, so there is no method to e.g. push DNS server over IPv6. This needs to be done with IPv4. The [https://community.openvpn.net/openvpn/wiki/IPv6 OpenVPN Wiki] provides some other configuration options.<br />
<br />
== Starting OpenVPN ==<br />
<br />
=== Manual startup ===<br />
<br />
To troubleshoot a VPN connection, start the client's daemon manually with {{ic|openvpn /etc/openvpn/client/client.conf}} as root. The server can be started the same way using its own configuration file (e.g., {{ic|openvpn /etc/openvpn/server/server.conf}}).<br />
<br />
=== systemd service configuration ===<br />
<br />
To start the OpenVPN server automatically at system boot, [[enable]] {{ic|openvpn-server@''configuration''.service}} on the applicable machine. For a client, [[enable]] {{ic|openvpn-client@''configuration''.service}} instead. (Leave {{ic|.conf}} out of the {{ic|''configuration''}} string.)<br />
<br />
For example, if the client configuration file is {{ic|/etc/openvpn/client/''client''.conf}}, the service name is {{ic|openvpn-client@''client''.service}}. Or, if the server configuration file is {{ic|/etc/openvpn/server/''server''.conf}}, the service name is {{ic|openvpn-server@''server''.service}}.<br />
<br />
{{Tip|If {{ic|openvpn-client@''configuration''.service}} units take a long time to start, it might be that your network manager is not triggering the {{ic|network-online.target}} systemd target at the right moment. For example, if you are using [[systemd-networkd]], you might want to properly configure {{ic|systemd-networkd-wait-online.service}}.}}<br />
<br />
=== Letting NetworkManager start a connection ===<br />
<br />
One might not always need to run a VPN tunnel and/or only want to establish it for a specific NetworkManager connection. This can be done by adding a script to {{ic|/etc/NetworkManager/dispatcher.d/}}. In the following example "Provider" is the name of the NetworkManager connection:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/10-openvpn|2=<br />
#!/bin/bash<br />
<br />
case "$2" in<br />
up)<br />
if [ "$CONNECTION_ID" == "Provider" ]; then<br />
systemctl start openvpn-client@''<configuration>''<br />
fi<br />
;;<br />
down)<br />
systemctl stop openvpn-client@''<configuration>''<br />
;;<br />
esac}}<br />
<br />
See [[NetworkManager#Network services with NetworkManager dispatcher]] for more details.<br />
<br />
=== Gnome configuration ===<br />
<br />
To connect to an OpenVPN server through Gnome's built-in network configuration do the following. First, install {{pkg|networkmanager-openvpn}}. Then go to the Settings menu and choose Network. Click the plus sign to add a new connection and choose VPN. From there, choose OpenVPN and manually enter the settings. One can optionally import [[#The client config profile]]. Yet, be aware NetworkManager does not show error messages for options it does not import. To connect to the VPN simply turn the connection on and check the options are applied (e.g. via {{ic|journalctl -b -u NetworkManager}}).<br />
<br />
== Routing client traffic through the server ==<br />
<br />
Without further configuration only traffic directly to and from the OpenVPN server's IP passes through the VPN. To have other traffic, like web traffic pass through the VPN, correspondent routes must be added. You can either add routes in the client's configuration or configure the server to push these routes to the client.<br />
<br />
To redirect traffic to and from a subnet of the server, add {{ic|push "route <address pool> <subnet>"}} right before the {{ic|remote <address> <port> udp/tcp}}, like:<br />
<br />
route 192.168.1.0 255.255.255.0<br />
<br />
To redirect all traffic including Internet traffic to the server, add the following in the client's configuration:<br />
<br />
redirect-gateway def1 bypass-dhcp ipv6<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option. If you are going IPv6-only, use {{ic|redirect-gateway ipv6 !ipv4}}.<br />
<br />
To make the server push routes, [[append]] {{ic|push "redirect-gateway def1 bypass-dhcp ipv6"}} to the configuration file (i.e. {{ic|/etc/openvpn/server/server.conf}}) [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] of the server. Note this is not a requirement and may even give performance issue:<br />
<br />
push "redirect-gateway def1 bypass-dhcp ipv6"<br />
<br />
If you are running an IPv4-only server, drop the {{ic|ipv6}} option. If you are going IPv6-only, use {{ic|push "redirect-gateway ipv6 !ipv4"}}<br />
<br />
Use the {{ic|push "route <address pool> <subnet>"}} option to allow clients reaching other subnets/devices behind the server:<br />
<br />
push "route 192.168.1.0 255.255.255.0"<br />
push "route 192.168.2.0 255.255.255.0"<br />
<br />
Optionally, push local [[DNS]] settings to clients (e.g. the DNS-server of the router and domain prefix ''.internal''):<br />
<br />
{{Note|One may need to use a simple [[DNS]] forwarder like [[BIND]] and push the IP address of the OpenVPN server as DNS to clients.}}<br />
<br />
push "dhcp-option DNS 192.168.1.1"<br />
push "dhcp-option DOMAIN internal"<br />
<br />
After setting up the configuration file, [[Internet_sharing#Enable_packet_forwarding|enable packet forwarding]] on the server. Additionally, the server's [[firewall]] needs to be adjusted to allow VPN traffic, which is described below for both [[#ufw|ufw]] and [[#iptables|iptables]].<br />
<br />
{{Note|There are potential pitfalls when routing all traffic through a VPN server. Refer to the [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect OpenVPN documentation] for more information.}}<br />
<br />
=== Firewall configuration ===<br />
<br />
==== firewalld ====<br />
<br />
If you use the default port 1194, enable the {{ic|openvpn}} service. Otherwise, create a new service with a different port.<br />
<br />
# firewall-cmd --zone=public --add-service openvpn<br />
<br />
Now add masquerade to the zone:<br />
<br />
# firewall-cmd --zone=FedoraServer --add-masquerade<br />
<br />
Make these changes permanent:<br />
<br />
# firewall-cmd --runtime-to-permanent<br />
<br />
==== ufw ====<br />
<br />
In order to allow [[ufw]] forwarding (VPN) traffic [[append]] the following to {{ic|/etc/default/ufw}}:<br />
<br />
{{hc|/etc/default/ufw|2=<br />
DEFAULT_FORWARD_POLICY="ACCEPT"<br />
}}<br />
<br />
Change {{ic|/etc/ufw/before.rules}}, and [[append]] the following code after the header and before the "*filter" line:<br />
* Change the IP/subnet mask to match the {{ic|server}} set in the OpenVPN server configuration.<br />
* Change the [[Network_configuration#Check_the_connection|network interface]] to the connection used by OpenVPN server.<br />
<br />
{{hc|/etc/ufw/before.rules|2=<br />
# NAT (Network Address Translation) table rules<br />
*nat<br />
:POSTROUTING ACCEPT [0:0]<br />
<br />
# Allow traffic from clients to the interface<br />
-A POSTROUTING -s 10.8.0.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# Optionally duplicate this line for each subnet if your setup requires it<br />
-A POSTROUTING -s 10.8.1.0/24 -o ''interface'' -j MASQUERADE<br />
<br />
# do not delete the "COMMIT" line or the NAT table rules above will not be processed<br />
COMMIT<br />
<br />
# Don't delete these required lines, otherwise there will be errors<br />
*filter<br />
..<br />
}}<br />
<br />
Make sure to open the chosen OpenVPN port (default 1194/udp):<br />
<br />
# ufw allow 1194/udp<br />
<br />
To apply the changes. [[reload]]/[[restart]] ufw:<br />
<br />
# ufw reload<br />
<br />
==== iptables ====<br />
<br />
In order to allow VPN traffic through an [[iptables]] firewall, first create an iptables rule for NAT forwarding [http://openvpn.net/index.php/open-source/documentation/howto.html#redirect] on the server. An example (assuming the interface to forward to is named {{ic|eth0}}):<br />
<br />
# iptables -t nat -A POSTROUTING -s 10.8.0.0/24 -o eth0 -j MASQUERADE<br />
<br />
If running multiple servers on different IP pools, add a corresponding line for each one, for example:<br />
<br />
# iptables -t nat -A POSTROUTING -s 10.8.1.0/24 -o eth0 -j MASQUERADE<br />
<br />
If the server cannot be pinged through the VPN, one may need to add explicit rules to open up TUN/TAP interfaces to all traffic. If that is the case, do the following [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn]:<br />
<br />
{{Warning|There are security implications for the following rules if one does not trust all clients which connect to the server. Refer to the [https://community.openvpn.net/openvpn/wiki/255-qconnection-initiated-with-xxxxq-but-i-cannot-ping-the-server-through-the-vpn OpenVPN documentation on this topic] for more details.}}<br />
<br />
# iptables -A INPUT -i tun+ -j ACCEPT<br />
# iptables -A FORWARD -i tun+ -j ACCEPT<br />
# iptables -A INPUT -i tap+ -j ACCEPT<br />
# iptables -A FORWARD -i tap+ -j ACCEPT<br />
<br />
Additionally be sure to accept connections from the OpenVPN port (default 1194) and through the physical interface:<br />
<br />
# iptables -A INPUT -i eth0 -m state --state NEW -p udp --dport 1194 -j ACCEPT<br />
# iptables -A FORWARD -i tun+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i eth0 -o tun+ -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i tap+ -o eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
# iptables -A FORWARD -i eth0 -o tap+ -m state --state RELATED,ESTABLISHED -j ACCEPT<br />
<br />
When satisfied, make the changes permanent as shown in [[iptables#Configuration and usage]].<br />
<br />
Those with multiple {{ic|tun}} or {{ic|tap}} interfaces, or more than one VPN configuration can "pin" the name of the interface by specifying it in the OpenVPN config file, e.g. {{ic|tun22}} instead of {{ic|tun}}. This is advantageous if different firewall rules for different interfaces or OpenVPN configurations are wanted.<br />
<br />
=== Prevent leaks if VPN goes down ===<br />
<br />
This prevents all traffic through the default interface (enp3s0 for example) and only allows traffic through tun0.<br />
If the OpenVPN connection drops, the system will lose its internet access thereby preventing connections through the default network interface.<br />
<br />
One may want to set up a script to restart OpenVPN if it goes down.<br />
<br />
==== ufw ====<br />
<br />
# Default policies<br />
ufw default deny incoming<br />
ufw default deny outgoing<br />
<br />
# Openvpn interface (adjust interface accordingly to your configuration)<br />
ufw allow in on tun0<br />
ufw allow out on tun0<br />
<br />
# Local Network (adjust ip accordingly to your configuration)<br />
ufw allow in on enp3s0 from 192.168.1.0/24<br />
ufw allow out on enp3s0 to 192.168.1.0/24<br />
<br />
# Openvpn (adjust port accordingly to your configuration)<br />
ufw allow in on enp3s0 from any port 1194<br />
ufw allow out on enp3s0 to any port 1194<br />
<br />
<br />
{{Warning|DNS '''will not''' work '''unless''' running a dedicated DNS server like [[BIND]].<br />
Alternatively, one can allow DNS leaks. '''Be sure to trust your DNS server!'''<br />
# DNS<br />
ufw allow in from any to any port 53<br />
ufw allow out from any to any port 53<br />
}}<br />
<br />
==== vpnfailsafe ====<br />
<br />
Alternatively, the [https://github.com/wknapik/vpnfailsafe vpnfailsafe] ({{AUR|vpnfailsafe-git}}) script can be used by the client to prevent DNS leaks and ensure that all traffic to the internet goes over the VPN. If the VPN tunnel goes down, internet access will be cut off, except for connections to the VPN server(s). The script contains the functionality of [[#The update-resolv-conf custom script|update-resolv-conf]], so the two do not need to be combined.<br />
<br />
== Layer-3 IPv4 routing==<br />
<br />
This section describes how to connect client/server LANs to each other using Layer-3 IPv4 routing.<br />
<br />
=== Prerequisites for routing a LAN ===<br />
<br />
For a host to be able to forward IPv4 packets between the LAN and VPN, it must be able to forward the packets between its NIC and its tun/tap device. See [[Internet sharing#Enable packet forwarding]] for configuration details.<br />
<br />
==== Routing tables ====<br />
<br />
{{Accuracy|Investigate if a routing protocol like RIP, QUAGGA, BIRD, etc can be used}}<br />
<br />
By default, all IP packets on a LAN addressed to a different subnet get sent to the default gateway. If the LAN/VPN gateway is also the default gateway, there is no problem and the packets get properly forwarded. If not, the gateway has no way of knowing where to send the packets. There are a couple of solutions to this problem.<br />
<br />
* Add a static route to the default gateway routing the VPN subnet to the LAN/VPN gateway's IP address.<br />
* Add a static route on each host on the LAN that needs to send IP packets back to the VPN.<br />
* Use [[iptables]]' NAT feature on the LAN/VPN gateway to masquerade the incoming VPN IP packets.<br />
<br />
=== Connect the server LAN to a client ===<br />
<br />
The server is on a LAN using the 10.66.0.0/24 subnet. To inform the client about the available subnet, add a push directive to the server configuration file:{{hc|/etc/openvpn/server/server.conf|push "route 10.66.0.0 255.255.255.0"}}<br />
<br />
{{Note|To route more LANs from the server to the client, add more push directives to the server configuration file, but keep in mind that the server side LANs will need to know how to route to the client.<br />
}}<br />
<br />
=== Connect the client LAN to a server ===<br />
<br />
Prerequisites:<br />
<br />
* Any subnets used on the client side, must be unique and not in use on the server or by any other client. In this example we will use 192.168.4.0/24 for the clients LAN.<br />
* Each client's certificate has a unique Common Name, in this case bugs.<br />
* The server may not use the duplicate-cn directive in its config file.<br />
* The CCD folder must be accessible via user and group defined in the server config file (typically nobody:nobody)<br />
<br />
Create a client configuration directory on the server. It will be searched for a file named the same as the client's common name, and the directives will be applied to the client when it connects.<br />
<br />
# mkdir -p /etc/openvpn/ccd<br />
<br />
Create a file in the client configuration directory called bugs, containing the {{ic|iroute 192.168.4.0 255.255.255.0}} directive. It tells the server what subnet should be routed to the client:<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
Add the client-config-dir and the {{ic|route 192.168.4.0 255.255.255.0}} directive to the server configuration file. It tells the server what subnet should be routed from the tun device to the server LAN:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{Note|To route more LANs from the client to the server, add more iroute and route directives to the appropriate configuration files, but keep in mind that the client side LANs will need to know how to route to the server.<br />
}}<br />
<br />
=== Connect both the client and server LANs ===<br />
<br />
Combine the two previous sections:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
push "route 10.66.0.0 255.255.255.0"<br />
.<br />
.<br />
client-config-dir ccd<br />
route 192.168.4.0 255.255.255.0<br />
}}<br />
<br />
{{hc|/etc/openvpn/ccd/bugs|iroute 192.168.4.0 255.255.255.0}}<br />
<br />
{{Note|Remember to make sure that all the LANs or the needed hosts can route to all the destinations.}}<br />
<br />
=== Connect clients and client LANs ===<br />
<br />
By default clients will not see each other. To allow IP packets to flow between clients and/or client LANs, add a client-to-client directive to the server configuration file:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
}}<br />
<br />
In order for another client or client LAN to see a specific client LAN, add a push directive for each client subnet to the server configuration file (this will make the server announce the available subnet(s) to other clients):<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
client-to-client<br />
push "route 192.168.4.0 255.255.255.0"<br />
push "route 192.168.5.0 255.255.255.0"<br />
..<br />
}}<br />
<br />
{{Note|One may need to adjust the [[#Firewall configuration|firewall]] to allow client traffic passing through the VPN server.}}<br />
<br />
== DNS ==<br />
For Linux, the OpenVPN client can receive DNS host information from the server, but the client expects an external command to act on this information. No such commands are configured by default. They must be specified with the {{ic|up}} and {{ic|down}} config options. There are a few alternatives for what scripts to use, but none are officially recognised by OpenVPN, so in order for any of them to work, {{ic|script-security}} must be set to 2. The {{ic|down-root}} plugin can be used instead of the {{ic|down}} option if [[#Run as unprivileged user|running as an unprivileged user]].<br />
<br />
=== The pull-resolv-conf custom scripts ===<br />
These scripts are [https://github.com/OpenVPN/openvpn/tree/master/contrib/pull-resolv-conf maintained by] OpenVPN. They are {{ic|client.up}} and {{ic|client.down}}, and they are packaged in {{ic|/usr/share/openvpn/contrib/pull-resolv-conf/}}. The following is an excerpt of a resulting client configuration using the scripts in conjunction with the {{ic|down-root}} plugin:<br />
<br />
{{hc|/etc/openvpn/client/''clienttunnel''.conf|<br />
user nobody<br />
group nobody<br />
# Optional, choose a suitable path to chroot into<br />
chroot /srv<br />
script-security 2<br />
up /usr/share/openvpn/contrib/pull-resolv-conf/client.up <br />
plugin /usr/lib/openvpn/plugins/openvpn-plugin-down-root.so "/usr/share/openvpn/contrib/pull-resolv-conf/client.down tun0"<br />
}}<br />
<br />
These scripts use the {{ic|resolvconf}} command if present. [[Systemd-resolvconf]] and [[Openresolv]] both implement this command. See their wiki pages for more information on getting a working {{ic|resolvconf}} implementation.<br />
<br />
{{Note|As of October 2019, systemd-resolvconf works as long as the systemd-resolved service is running. Openresolv will not work out of the box because {{ic|client.up}} will only create private DNS server entries. These require extra configuration of openresolv to work. See {{ic|man 8 resolvconf}} for more details on private DNS servers in openresolv.}}<br />
<br />
If no implementation of {{ic|resolvconf}} is present, {{ic|client.up}} preserves the existing {{ic|resolv.conf}} at {{ic|/etc/resolv.conf.ovpnsave}} and writes a new one. This new one will not have any of the original DNS servers.<br />
<br />
If you need to edit these scripts, copy them somewhere else and edit them there, so that your changes don't get overwritten by the next {{pkg|openvpn}} package upgrade. {{ic|/etc/openvpn/client}} is a pretty good place.<br />
# cp /usr/share/openvpn/contrib/pull-resolv-conf/* /etc/openvpn/client<br />
# $EDITOR /etc/openvpn/client/client.{up.,down}<br />
# # etc ...<br />
<br />
=== The update-resolv-conf custom script ===<br />
<br />
{{Note|Another script, [[#The update-systemd-resolved custom script|update-systemd-resolved]], is recommended by the author of update-resolv-conf for systems with systemd.}}<br />
<br />
The [https://github.com/masterkorp/openvpn-update-resolv-conf openvpn-update-resolv-conf] script is available as an alternative to packaged scripts. It needs to be saved for example at {{ic|/etc/openvpn/update-resolv-conf}} and made [[executable]].<br />
<br />
If you prefer a package, there is {{AUR|openvpn-update-resolv-conf-git}} that does above for you. You still need to do the following.<br />
<br />
Once the script is installed add lines like the following into the OpenVPN client configuration file:<br />
<br />
script-security 2<br />
up /etc/openvpn/update-resolv-conf<br />
down /etc/openvpn/update-resolv-conf<br />
<br />
{{Note|If manually placing the script on the filesystem, be sure to have {{pkg|openresolv}} installed.}}<br />
<br />
Now, when launching the OpenVPN connection, {{ic|resolv.conf}} should be updated accordingly, and also should get returned to normal when the connection is closed.<br />
<br />
{{Note|When using {{ic|openresolv}} with the ''-p'' or ''-x'' options in a script (as both the included {{ic|client.up}} and {{ic|update-resolv-conf}} scripts currently do), a DNS resolver like {{Pkg|dnsmasq}} or {{Pkg|unbound}} is required for {{ic|openresolv}} to correctly update {{ic|/etc/resolv.conf}}. In contrast, when using the default DNS resolution from {{ic|libc}} the ''-p'' and ''-x'' options must be removed in order for {{ic|/etc/resolv.conf}} to be correctly updated by {{ic|openresolv}}.<br />
For example, if the script contains a command like {{ic|resolvconf -p -a }} and the default DNS resolver from {{ic|libc}} is being used, change the command in the script to be {{ic|resolvconf -a }}.}}<br />
<br />
=== The update-systemd-resolved custom script ===<br />
<br />
{{Note|Since [[systemd]] 229, [[systemd-networkd]] has exposed an API through DBus allowing management of DNS configuration on a per-link basis. Tools such as {{pkg|openresolv}} may not work reliably when {{ic|/etc/resolv.conf}} is managed by {{ic|systemd-resolved}}, and will not work at all if using {{ic|resolve}} instead of {{ic|dns}} in {{ic|/etc/nsswitch.conf}}.}}<br />
<br />
The [https://github.com/jonathanio/update-systemd-resolved update-systemd-resolved] script links OpenVPN with {{ic|systemd-resolved}} via DBus to update the DNS records.<br />
<br />
Copy the script into {{ic|/etc/openvpn/scripts}} and mark as [[executable]] (or [[install]] {{AUR|openvpn-update-systemd-resolved}}) and [[append]] the following lines into the OpenVPN client configuration file:<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
client<br />
remote example.com 1194 udp<br />
..<br />
script-security 2<br />
setenv PATH /usr/bin<br />
up /etc/openvpn/scripts/update-systemd-resolved<br />
down /etc/openvpn/scripts/update-systemd-resolved<br />
down-pre<br />
}}<br />
<br />
In order to send all DNS traffic through the VPN tunnel and prevent DNS leaks, also add the following line (see [https://github.com/jonathanio/update-systemd-resolved#dns-leakage]):<br />
<br />
{{hc|/etc/openvpn/client/client.conf|<br />
dhcp-option DOMAIN-ROUTE .<br />
}}<br />
<br />
Make sure that the [[systemd-resolved]] service is configured and running. Also, since openvpn 2.5.0-3 scripts are running as openvpn user instead of root. Thus, you need to add a PolicyKit rule to allow OpenVPN systemd units to call DBus with SetLinkDNS:<br />
<br />
{{hc|/etc/polkit-1/rules.d/00-openvpn-resolved.rules|<br />
polkit.addRule(function(action, subject) {<br />
if (action.id == 'org.freedesktop.resolve1.set-dns-servers' ||<br />
action.id == 'org.freedesktop.resolve1.set-domains' ||<br />
action.id == 'org.freedesktop.resolve1.set-dnssec') {<br />
if (subject.user == 'openvpn') {<br />
return polkit.Result.YES;<br />
}<br />
}<br />
});<br />
}}<br />
<br />
===Override DNS servers using NetworkManager===<br />
<br />
By default {{pkg|networkmanager-openvpn}} plugin appends DNS servers provided by OpenVPN to {{ic|/etc/resolv.conf}}.<br />
<br />
To verify that the correct DNS server(s) are configured, see {{ic|resolvectl status}} if systemd-resolved is in use, for other resolvers see [[Domain name resolution]].<br />
<br />
== Layer-2 Ethernet bridging ==<br />
<br />
{{Expansion|Please add a well thought out section on Layer-2 bridging.}}<br />
<br />
For now see: [[OpenVPN Bridge]]<br />
<br />
== Config generators ==<br />
<br />
{{Warning|Users are highly recommended to pass through the manual configuration described above to gain knowledge about options and usage before using any additional automation scripts.}}<br />
<br />
=== ovpngen ===<br />
<br />
The {{AUR|ovpngen}} package provides a simple shell script that creates OpenVPN compatible tunnel profiles in the unified file format suitable for the OpenVPN Connect app for Android and iOS.<br />
<br />
Simply invoke the script with 5 tokens:<br />
<br />
# Server Fully Qualified Domain Name of the OpenVPN server (or IP address).<br />
# Full path to the CA cert.<br />
# Full path to the client cert.<br />
# Full path to the client private key.<br />
# Full path to the server TLS shared secret key.<br />
# Optionally a port number.<br />
# Optionally a protocol (udp or tcp).<br />
<br />
Example:<br />
<br />
# ovpngen example.org /etc/openvpn/server/ca.crt /etc/easy-rsa/pki/signed/client1.crt /etc/easy-rsa/pki/private/client1.key /etc/openvpn/server/ta.key > foo.ovpn<br />
<br />
If the server is configured to use tls-crypt, as is suggested in [[#The server configuration file]], [https://github.com/graysky2/ovpngen/issues/4 manually edit] the resulting {{ic|foo.ovpn}} replacing {{ic|<tls-auth>}} and {{ic|</tls-auth>}} with {{ic|<tls-crypt>}} and {{ic|</tls-crypt>}}.<br />
<br />
The resulting {{ic|foo.ovpn}} can be edited if desired as the script does insert some commented lines. {{ic|foo.ovpn}} will not automatically route all traffic through the VPN, so you may want to follow [[#Routing client traffic through the server]] to enable redirection.<br />
<br />
The client expects this file to be located in {{ic|/etc/openvpn/client/foo.conf}}. Note the change in file extension from 'ovpn' to 'conf' in this case.<br />
<br />
{{Tip|If the server.conf contains a specified cipher and/or auth line, it is highly recommended that users manually edit the generated .ovpn file adding matching lines for cipher and auth. Failure to do so may results in connection errors!}}<br />
<br />
=== openvpn-unroot ===<br />
<br />
{{Note|If you intend to use a custom script, perhaps for configuring [[#DNS]], you must add these scripts to your config before calling openvpn-unroot on it. Failing to do so will cause problems if the scripts require root permissions.}}<br />
<br />
The steps necessary for OpenVPN to [[#Run as unprivileged user]], can be performed automatically using [https://github.com/wknapik/openvpn-unroot openvpn-unroot] ({{AUR|openvpn-unroot-git}}).<br />
<br />
It automates the actions required for the [https://community.openvpn.net/openvpn/wiki/UnprivilegedUser OpenVPN howto] by adapting it to systemd, and also working around the bug for persistent tun devices mentioned in the note.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Client daemon not reconnecting after suspend ===<br />
<br />
{{AUR|openvpn-reconnect}}, available on the AUR, solves this problem by sending a SIGHUP to openvpn after waking up from suspend.<br />
<br />
Alternatively, restart OpenVPN after suspend by creating the following systemd service:<br />
<br />
{{hc|1=/etc/systemd/system/openvpn-reconnect.service|2=<br />
[Unit]<br />
Description=Restart OpenVPN after suspend<br />
<br />
[Service]<br />
ExecStart=/usr/bin/pkill --signal SIGHUP --exact openvpn<br />
<br />
[Install]<br />
WantedBy=sleep.target<br />
}}<br />
<br />
[[Enable]] this service for it to take effect.<br />
<br />
=== Connection drops out after some time of inactivity ===<br />
<br />
If the VPN-Connection drops some seconds after it stopped transmitting data and, even though it states it is connected, no data can be transmitted through the tunnel, try adding a {{ic|keepalive}}directive to the server's configuration:<br />
<br />
{{hc|/etc/openvpn/server/server.conf|<br />
.<br />
.<br />
keepalive 10 120<br />
.<br />
.<br />
}}<br />
<br />
In this case the server will send ping-like messages to all of its clients every 10 seconds, thus keeping the tunnel up.<br />
If the server does not receive a response within 120 seconds from a specific client, it will assume this client is down.<br />
<br />
A small ping-interval can increase the stability of the tunnel, but will also cause slightly higher traffic. Depending on the connection, also try lower intervals than 10 seconds.<br />
<br />
=== PID files not present ===<br />
<br />
The default systemd service file for openvpn-client does not have the --writepid flag enabled, despite creating /var/run/openvpn-client. If this breaks a config (such as an i3bar VPN indicator), simply change {{ic|openvpn-client@.service}} using a [[drop-in snippet]]:<br />
<br />
[Service]<br />
ExecStart=<br />
ExecStart=/usr/sbin/openvpn --suppress-timestamps --nobind --config %i.conf --writepid /var/run/openvpn-client/%i.pid<br />
<br />
=== Route configuration fails with systemd-networkd ===<br />
<br />
When using [[systemd-networkd]] to manage network connections and attempting to tunnel all outgoing traffic through the VPN, OpenVPN may fail to add routes. This is a result of systemd-networkd attempting to manage the tun interface before OpenVPN finishes configuring the routes. When this happens, the following message will appear in the OpenVPN log.<br />
<br />
openvpn[458]: RTNETLINK answers: Network is unreachable<br />
openvpn[458]: ERROR: Linux route add command failed: external program exited with error status: 2<br />
<br />
From systemd-233, systemd-networkd can be configured to ignore the tun connections and allow OpenVPN to manage them. To do this, create the following file:<br />
<br />
{{hc|1=/etc/systemd/network/90-tun-ignore.network|2=<br />
[Match]<br />
Name=tun*<br />
<br />
[Link]<br />
Unmanaged=true<br />
}}<br />
<br />
[[Restart]] {{ic|systemd-networkd.service}} to apply the changes. To verify that the changes took effect, start the previously problematic OpenVPN connection and run {{ic|networkctl}}. The output should have a line similar to the following:<br />
<br />
7 tun0 none routable unmanaged<br />
<br />
=== tls-crypt unwrap error: packet too short ===<br />
<br />
This error shows up in the server log when a client that does not support tls-crypt, or a client that is misconfigured to use tls-auth while the server is configured to use tls-crypt, attempts to connect.<br />
<br />
To support clients that do not support tls-crypt, replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 0}} (the default) in {{ic|server.conf}}. Also replace {{ic|tls-crypt ta.key}} with {{ic|tls-auth ta.key 1}} (the default) in {{ic|client.conf}}.<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:OpenVPN]]<br />
* [https://www.infosecwriters.com/text_resources/pdf/securing_communication.pdf Securing Network Communication with Stunnel, OpenSSH, and OpenVPN] (PDF)</div>Ernetashttps://wiki.archlinux.org/index.php?title=Firefox&diff=633389Firefox2020-08-25T10:42:26Z<p>Ernetas: /* Hardware video acceleration */ Firefox 80 is released</p>
<hr />
<div>[[Category:Web browser]]<br />
[[Category:Mozilla]]<br />
[[ar:Firefox]]<br />
[[cs:Firefox]]<br />
[[de:Firefox]]<br />
[[es:Firefox]]<br />
[[fr:Firefox]]<br />
[[it:Firefox]]<br />
[[ja:Firefox]]<br />
[[ko:Firefox]]<br />
[[ru:Firefox]]<br />
[[zh-hans:Firefox]]<br />
{{Related articles start}}<br />
{{Related|Browser plugins}}<br />
{{Related|Firefox/Tweaks}}<br />
{{Related|Firefox/Profile on RAM}}<br />
{{Related|Firefox/Privacy}}<br />
{{Related|Chromium}}<br />
{{Related|Opera}}<br />
{{Related articles end}}<br />
[https://www.mozilla.org/firefox Firefox] is a popular open source graphical web browser from [https://www.mozilla.org Mozilla].<br />
<br />
== Installing ==<br />
<br />
Firefox can be [[install]]ed with the {{Pkg|firefox}} package.<br />
<br />
Other alternatives include:<br />
<br />
* {{App|Firefox Developer Edition|for developers|https://www.mozilla.org/firefox/developer/|{{Pkg|firefox-developer-edition}}}}<br />
* {{App|Firefox Extended Support Release|long-term supported version|https://www.mozilla.org/firefox/organizations/|{{AUR|firefox-esr}} or {{AUR|firefox-esr-bin}}}}<br />
* {{App|Firefox Beta|cutting-edge version|https://www.mozilla.org/firefox/channel/desktop/#beta|{{AUR|firefox-beta}} or {{AUR|firefox-beta-bin}}}}<br />
* {{App|Firefox Nightly|nightly builds for testing ([https://developer.mozilla.org/Firefox/Experimental_features experimental features])|https://www.mozilla.org/firefox/channel/desktop/#nightly|{{AUR|firefox-nightly}}}} <br />
* {{App|Firefox KDE|Version of Firefox that incorporates an OpenSUSE patch for better [[#KDE/GNOME integration|KDE integration]] than is possible through simple Firefox plugins.|https://build.opensuse.org/package/show/mozilla:Factory/MozillaFirefox|{{AUR|firefox-kde-opensuse}}}}<br />
* On top of the different Mozilla build channels, a number of forks exist with more or less special features; see [[List of applications#Gecko-based]].<br />
<br />
A number of language packs are available for Firefox, other than the standard English. Language packs are usually named as {{ic|firefox-i18n-''languagecode''}} (where {{ic|''languagecode''}} can be any language code, such as '''de''', '''ja''', '''fr''', etc.). For a list of available language packs see [https://www.archlinux.org/packages/extra/any/firefox-i18n/ firefox-i18n] for {{Pkg|firefox}},[https://www.archlinux.org/packages/community/any/firefox-developer-edition-i18n/ firefox-developer-edition-i18n] for {{Pkg|firefox-developer-edition}} and [https://aur.archlinux.org/packages/?K=firefox-nightly- firefox-nightly-] for {{AUR|firefox-nightly}}.<br />
<br />
== Add-ons ==<br />
<br />
Firefox is well known for its large library of add-ons which can be used to add new features or modify the behavior of existing features. Firefox's "Add-ons Manager" is used to manage installed add-ons or find new ones. <br />
<br />
For instructions on how to install add-ons and a list of add-ons, see [[Browser extensions]].<br />
<br />
=== Adding search engines ===<br />
<br />
Search engines may be added to Firefox by creating bookmarks with the {{ic|Location}} field using search URLs completed with %s in place of the query and the {{ic|Keyword}} field completed with user-defined characters:<br />
<br />
Location:<br />
https://duckduckgo.com/html/?q=%s<br />
Keyword:<br />
d<br />
<br />
Searches are performed by pre-pending the search term with the keyword of the specified search engine: {{ic|d archwiki}} will query DuckDuckGo using the search term {{ic|archwiki}}<br />
<br />
Search engines may also be added to Firefox through add-on extensions, see [https://addons.mozilla.org/firefox/search-tools/ this page] for a list of available search tools and engines.<br />
<br />
A very extensive list of search engines can be found at the [https://mycroftproject.com/ Mycroft Project].<br />
<br />
Also, you can use the [https://firefox.maltekraus.de/extensions/add-to-search-bar add-to-searchbar] extension to add a search to your search bar from any web site, by simply right clicking on the site's search field and selecting ''Add to Search Bar...''<br />
<br />
==== arch-firefox-search ====<br />
<br />
[[Install]] the {{AUR|arch-firefox-search}} package to add Arch-specific searches (AUR, wiki, forum, etc, as specified by user) to the Firefox search toolbar.<br />
<br />
== Plugins ==<br />
<br />
The only plugin supported by Firefox is [[Browser plugins#Adobe Flash Player|Adobe Flash Player]] (NPAPI version). Other plugins are [https://support.mozilla.org/en-US/kb/npapi-plugins no longer supported].<br />
<br />
To find out what plugins are installed/enabled, enter:<br />
<br />
about:plugins<br />
<br />
in the Firefox address bar or go to the ''Add-ons'' entry in the Firefox Menu and select the ''Plugins'' tab.<br />
<br />
== Configuration ==<br />
<br />
Firefox exposes a number of configuration options. To examine them, enter in the Firefox address bar:<br />
<br />
about:config<br />
<br />
Once set, these affect the user's current profile, and may be synchronized across all devices via [https://www.mozilla.org/firefox/sync/ Firefox Sync]. Please note that only a subset of the {{ic|about:config}} entries are synchronized by this method, and the exact subset may be found by searching for {{ic|services.sync.prefs}} in {{ic|about:config}}. Additional preferences and third party preferences may be synchronized by creating new boolean entries prepending the config value with {{ic|services.sync.prefs.sync}} ([https://developer.mozilla.org/en-US/docs/Archive/Mozilla/Firefox_Sync/Syncing_custom_preferences documentation] is still applicable.) To synchronize the whitelist for the extension [https://addons.mozilla.org/firefox/addon/noscript/ NoScript]:<br />
<br />
services.sync.prefs.sync.capability.policy.maonoscript.sites<br />
<br />
The boolean {{ic|noscript.sync.enabled}} must be set to {{ic|true}} to synchronize the remainder of NoScript's preferences via Firefox Sync.<br />
<br />
Firefox also allows configuration for a profile via a {{ic|user.js}} file: [http://kb.mozillazine.org/User.js_file user.js] kept in the profile folder, usually {{ic|~/.mozilla/firefox/''xxxxxxxx''.default/}}. For a useful starting point, see e.g [https://github.com/pyllyukko/user.js custom user.js] which is targeted at privacy/security conscious users.<br />
<br />
One drawback of the above approach is that it is not applied system-wide. Furthermore, this is not useful as a "pre-configuration", since the profile directory is created after first launch of the browser. You can, however, let ''firefox'' create a new profile and, after closing it again, [https://support.mozilla.org/en-US/kb/back-and-restore-information-firefox-profiles#w_restoring-a-profile-backup copy the contents] of an already created profile folder into it. <br />
<br />
Sometimes it may be desired to lock certain settings, a feature useful in widespread deployments of customized Firefox. In order to create a system-wide configuration, follow the steps outlined in [http://kb.mozillazine.org/Locking_preferences Locking preferences]:<br />
<br />
1. Create {{ic|/usr/lib/firefox/defaults/pref/local-settings.js}}:<br />
<br />
pref("general.config.obscure_value", 0);<br />
pref("general.config.filename", "mozilla.cfg");<br />
<br />
2. Create {{ic|/usr/lib/firefox/mozilla.cfg}} (this stores the actual configuration):<br />
<br />
//<br />
//...your settings...<br />
// e.g to disable Pocket, uncomment the following line<br />
// lockPref("browser.pocket.enabled", false);<br />
<br />
Please note that the first line must contain exactly {{ic|//}}. The syntax of the file is similar to that of {{ic|user.js}}.<br />
<br />
=== Multimedia playback ===<br />
<br />
Firefox uses [[FFmpeg]] for playing multimedia inside HTML5 {{ic|<audio>}} and {{ic|<video>}} elements. Go to [http://demo.nimius.net/video_test/ video-test page] or [https://hpr.dogphilosophy.net/test/ audio-test page] to check which formats are actually supported.<br />
<br />
Firefox uses [[PulseAudio]] for audio playback and capture. For sound to work, you need to install the {{Pkg|pulseaudio}} package.<br />
<br />
In case, for whatever reason, [[PulseAudio]] is not an option for you, you can use [[Advanced Linux Sound Architecture#PulseAudio compatibility|apulse]] instead. To make this work, it is necessary to exclude {{ic|/dev/snd/}} from Firefox' sandboxing by adding it to the comma-separated list in {{ic|about:config}}:<br />
<br />
security.sandbox.content.write_path_whitelist<br />
<br />
{{Note|The trailing slash on {{ic|/dev/snd/}} is important, otherwise ''apulse'' will report "Permission denied" errors.}}<br />
<br />
If you have no audio even when using ''apulse'', try adding {{ic|16}} to {{ic|security.sandbox.content.syscall_whitelist}} in {{ic|about:config}}.<br />
<br />
==== HTML5 DRM/Widevine ====<br />
<br />
Widevine is a digital rights management tool that Netflix, Amazon Prime Video, and others use to protect their video content. It can be enabled in ''Preferences > General > Digital Rights Management (DRM) Content''. If you visit a Widevine-enabled page when this setting is disabled, Firefox will display a prompt below the address bar asking for permission to install DRM. Approve this and then wait for the "Downloading" bar to disappear, you are now able to watch videos from Widevine protected sites.<br />
<br />
It is also required that the private mode browsing is disabled, for the window and in the preferences.<br />
<br />
==== Open With extension ====<br />
<br />
# Install [https://addons.mozilla.org/firefox/addon/open-with/ Open With] add-on.<br />
# Go to ''Add-ons > Open With > Preferences''.<br />
# Proceed with instructions to install a file in your system and test the installation. <br />
# Click ''Add browser''.<br />
# In the dialog write a name for this menu entry and command to start a video streaming capable player (e.g. [[mpv|/usr/bin/mpv]]).<br />
# (Optional step) Add needed arguments to the player (e.g. you may want {{ic|--force-window --ytdl}} for ''mpv'')<br />
# Right click on links or visit pages containing videos. Select newly created entry from Open With's menu and if the site is supported, the player will open as expected.<br />
<br />
The same procedure can be used to associate video downloaders such as ''youtube-dl''.<br />
<br />
==== Hardware video acceleration ====<br />
<br />
[[Hardware video acceleration]] via VA-API is currently available under [[Wayland]] (see [https://mastransky.wordpress.com/2020/06/03/firefox-on-fedora-finally-gets-va-api-on-wayland/ Firefox gets VA-API on Wayland]); X.org support has been implemented in Firefox 80 (see [https://bugzilla.mozilla.org/show_bug.cgi?id=1619523 bugzilla X11 implement VAAPI] and [https://www.phoronix.com/scan.php?page=news_item&px=Firefox-80-VA-API-X11 Phoronix news VA API X11]).<br />
<br />
{{Note|[[AMDGPU]] users under {{pkg|linux-hardened}} may need to rebuild ''linux-hardened'' with {{ic|1=CONFIG_CHECKPOINT_RESTORE=y}} due to {{pkg|mesa}} [https://gitweb.gentoo.org/repo/gentoo.git/tree/media-libs/mesa/mesa-9999.ebuild requiring the kcmp syscall].}}<br />
<br />
Before trying VA-API support in Firefox be sure to:<br />
<br />
* Install correct VA-API driver for your video card and verify VA-API has been enabled and working correctly, see [[Hardware video acceleration]];<br />
** For Intel graphics use the i965 driver {{Pkg|libva-intel-driver}}, the iHD driver {{Pkg|intel-media-driver}} is currently unsupported;<br />
* Set {{ic|widget.wayland-dmabuf-vaapi.enabled}} to {{ic|true}} in {{ic|about:config}};<br />
* Use a compositor that supports hardware acceleration, either Gecko's OpenGL back-end or WebRender from the new Servo browser engine:<br />
** [[/Tweaks#Enable OpenGL compositor]];<br />
** [[/Tweaks#Enable WebRender compositor]];<br />
* Set {{ic|media.ffvpx.enabled}} to {{ic|false}} in {{ic|about:config}} to disable the bundled FFmpeg;<br />
* In Wayland, run Firefox with {{ic|1=MOZ_ENABLE_WAYLAND=1}} environment variable, see [[#Wayland]].<br />
* In X.org in Firefox 80 and above, run Firefox with {{ic|1=MOZ_X11_EGL=1}} environment variable.<br />
<br />
You can verify that VA-API is enabled by running Firefox with {{ic|1=MOZ_LOG="PlatformDecoderModule:5"}} [[environment variable]] and check in the log output that VA-API is enabled and used (search of the "VA-API" string) when, for example, playing a YouTube video.<br />
{{Note|Pay attention to these logs, as they might say that only one of the two possible hardware accelerated compositing methods described before (OpenGL or WebRender) works with VA-API on your particular setup.<br />
}}<br />
{{Tip|To allow hardware decoding in YouTube, the video codec used must be supported by the hardware. The profiles supported by your GPU can be checked with [[Hardware video acceleration#Verifying VA-API]] and the YouTube codecs used can be controlled with the [https://addons.mozilla.org/firefox/addon/h264ify/ h264ify] or [https://addons.mozilla.org/firefox/addon/enhanced-h264ify/ enhanced-h264ify] extensions. Alternatively, you can install {{AUR|firefox-h264ify}}.}}<br />
<br />
=== Spell checking ===<br />
<br />
Firefox can use system-wide installed [[Hunspell]] dictionaries as well as dictionaries installed through its own extension system.<br />
<br />
To enable spell checking for a specific language right click on any text field and check the ''Check Spelling'' box. To select a language for spell checking to you have right click again and select your language from the ''Languages'' sub-menu.<br />
<br />
When your default language choice does not stick, see [[#Firefox does not remember default spell check language]].<br />
<br />
==== System-wide Hunspell dictionaries ====<br />
<br />
Install [[Hunspell]] and its dictionaries for the languages you require.<br />
<br />
==== Dictionaries as extensions ====<br />
<br />
To get more languages right click on any text field and just click ''Add Dictionaries...'' and select the dictionary you want to install from the [https://addons.mozilla.org/firefox/language-tools/ Dictionaries and Language Packs list].<br />
<br />
{{Tip|For Russian, the extension is packaged as {{Pkg|firefox-spell-ru}}.}}<br />
<br />
=== KDE/GNOME integration ===<br />
<br />
* To bring the [[KDE]] look to GTK apps (including Firefox), install {{Pkg|breeze-gtk}} and {{Pkg|kde-gtk-config}}. Afterwards, go to ''System Settings > Application Style > Configure GNOME/GTK Application Style…''. Choose 'Breeze' or 'Breeze-Dark' in 'GTK2 Theme' and 'GTK3 Theme'.<br />
* To use the KDE file selection and print dialogs in Firefox 64 or newer, install {{Pkg|xdg-desktop-portal}} and {{Pkg|xdg-desktop-portal-kde}}, then add {{ic|1=GTK_USE_PORTAL=1}} to the [[Desktop entries#Modify environment variables|application startup command]].<br />
* For integration with [[KDE]] MIME type system and file dialog, one can use {{AUR|firefox-kde-opensuse}} variant from AUR with OpenSUSE’s patches applied. Alternatively, integration with MIME types can be achieved by creating a symbolic link to the MIME database {{ic|~/.config/mimeapps.list}} from the deprecated {{ic|~/.local/share/applications/mimeapps.list}} that is used by Firefox. See [[XDG MIME Applications#mimeapps.list]].<br />
* Extensions/add-ons may provide additional integration, such as:<br />
** Browser integration in [[Plasma]]: requires {{Pkg|plasma-browser-integration}} and the [https://addons.mozilla.org/firefox/addon/plasma-integration/ Plasma Integration add-on].<br />
** {{AUR|mozilla-extension-gnome-keyring-git}} (all-JavaScript implementation) to integrate Firefox with [[GNOME Keyring]]. To make firefox-gnome-keyring use your login keychain, set {{ic|extensions.gnome-keyring.keyringName}} to {{ic|login}} in {{ic|about:config}}. Note the lowercase 'l' despite the the keychain name having an uppercase 'L' in Seahorse.<br />
<br />
== Tips and tricks ==<br />
<br />
For general enhancements see [[Firefox/Tweaks]], for privacy related enhancements see [[Firefox/Privacy]].<br />
<br />
=== Dark themes ===<br />
<br />
If a dark [[GTK]] theme is in use (e.g. Arc Dark), it is recommended to start Firefox with a brighter one (e.g. Adwaita). See [[GTK#Themes]] and [[Firefox/Tweaks#Unreadable input fields with dark GTK themes]] for more information.<br />
<br />
Alternatively, starting with Firefox 68 you can make the all Firefox interfaces and even other websites respect dark themes, irrespective of the system GTK theme and Firefox theme. To do this, set {{ic|browser.in-content.dark-mode}} to {{ic|true}} and {{ic|ui.systemUsesDarkTheme}} to {{ic|1}} in {{ic|about:config}} [https://bugzilla.mozilla.org/show_bug.cgi?id=1488384#c23].<br />
<br />
=== Frame rate ===<br />
<br />
If Firefox is unable to automatically detect the right value, it will default to 60 fps. To manually correct this, set {{ic|layout.frame_rate}} to the refresh rate of your monitor (e.g. 144 for 144 Hz).<br />
<br />
=== Memory limit ===<br />
<br />
To prevent pages from abusing memory (and possible [[Wikipedia:Out_of_memory|OOM]]), we can use [[Firejail]] with the {{ic|rlimit-as}} option.<br />
<br />
=== New tabs position ===<br />
<br />
To control where new tabs appears (relative or absolute), use {{ic|browser.tabs.insertAfterCurrent}} and {{ic|browser.tabs.insertRelatedAfterCurrent}}. See [https://support.mozilla.org/en/questions/1229062] for more informations.<br />
<br />
=== Screenshot of webpage ===<br />
<br />
You can ''Take a Screenshot'' by either clicking the ''Page actions'' button (the three horizontal dots) in the address bar or by right-clicking on the webpage. See [https://support.mozilla.org/en-US/kb/firefox-screenshots] for more information.<br />
<br />
As an alternative you can use the screenshot button in the [https://developer.mozilla.org/en-US/docs/Tools/Taking_screenshots Developer Tools].<br />
<br />
=== Wayland ===<br />
<br />
{{Note|1=Starting Firefox 73.0.0-1 there have been [https://bugzilla.mozilla.org/show_bug.cgi?id=1616309 reports of weird focus and hover] issues with the wayland back-end. You can try switching back to ''x11'' if this happens, or [[downgrade]] to Firefox 72.0.2.}}<br />
<br />
More recent versions of Firefox support opting into Wayland via an environment variable.<br />
<br />
$ MOZ_ENABLE_WAYLAND=1 firefox<br />
<br />
To make this permanent, see [[Environment variables#Graphical environment]] and start Firefox via the desktop launcher like you normally would. To verify it worked check the ''Window Protocol'' again.<br />
<br />
You may enter {{ic|about:support}} in the URL bar to check the ''Window Protocol''. It should say ''wayland/drm'' instead of ''x11''.<br />
<br />
=== Window manager rules ===<br />
<br />
To apply different configurations to Firefox windows, change the WM_CLASS string by using Firefox's {{ic|--class}} option, to a custom one.<br />
<br />
==== Profiles ====<br />
<br />
To start new Firefox instances, multiple profiles are required. To create a new profile:<br />
<br />
$ firefox [--new-instance] -P<br />
<br />
Class can be specified when launching Firefox with a not-in-use profile:<br />
<br />
$ firefox [--new-instance] -P ''profile_name'' --class=''class_name''<br />
<br />
=== Touchscreen gestures and pixel-perfect trackpad scrolling ===<br />
<br />
{{Merge|Firefox/Tweaks#Enable touchscreen gestures|Same solution.}}<br />
<br />
To enable touch gestures (like scrolling and pinch-to-zoom) and one-to-one trackpad scrolling (as can be witnessed with GTK3 applications like Nautilus), set the {{ic|1=MOZ_USE_XINPUT2=1}} [[environment variable]] before starting Firefox.<br />
<br />
=== Multiple home pages ===<br />
<br />
To have multiple tabs opened when starting Firefox open a new window and then open the sites you want to have as "home tabs".<br />
<br />
Now go to ''Preferences > Home'' and under ''Homepage and new windows'' click the ''Use Current Pages'' button.<br />
<br />
Alternatively go directly to ''Preferences > Home'' and now under ''Homepage and new windows'' set the first field to ''Custom URLs..'' and enter the pages you want as new home pages in the following format:<br />
<br />
<nowiki>https://url1.com|https://url2.com|https://url3.com</nowiki><br />
<br />
== Troubleshooting ==<br />
<br />
=== Extension X does not work on some Mozilla owned domains ===<br />
<br />
By default extensions will not affect pages designated by {{ic|extensions.webextensions.restrictedDomains}}. If this is not desired, this field can be cleared (special pages such as {{ic|about:*}} will not be affected).<br />
<br />
=== Firefox startup takes very long ===<br />
<br />
If Firefox takes much longer to start up than other browsers, it may be due to lacking configuration of the localhost in {{ic|/etc/hosts}}. See [[Network configuration#Local network hostname resolution]] on how to set it up. <br />
<br />
=== Font troubleshooting ===<br />
<br />
See [[Font configuration]].<br />
<br />
Firefox has a setting which determines how many replacements it will allow from fontconfig. To allow it to use all your replacement-rules, change {{ic|gfx.font_rendering.fontconfig.max_generic_substitutions}} to {{ic|127}} (the highest possible value).<br />
<br />
Firefox ships with ''Twemoji Mozilla'' font. To use system emoji font set {{ic|font.name-list.emoji}} to {{ic|emoji}} in {{ic|about:config}}.<br />
<br />
Firefox has problems with [[Emoji]] presentation [https://bugzilla.mozilla.org/show_bug.cgi?id=1509988]. Set {{ic|gfx.font_rendering.fontconfig.max_generic_substitutions}} to {{ic|0}} as workaround.<br />
<br />
=== Setting an email client ===<br />
<br />
Inside the browser, {{ic|mailto}} links by default are opened by a web application such as Gmail or Yahoo Mail. To set an external email program, go to ''Preferences > Applications'' and modify the ''action'' corresponding to the {{ic|mailto}} content type; the file path will need to be designated (e.g. {{ic|/usr/bin/kmail}} for Kmail).<br />
<br />
Outside the browser, {{ic|mailto}} links are handled by the {{ic|x-scheme-handler/mailto}} mime type, which can be easily configured with [[xdg-mime]]. See [[Default applications]] for details and alternatives.<br />
<br />
=== File association ===<br />
<br />
See [[Default applications]].<br />
<br />
=== Firefox keeps creating ~/Desktop even when this is not desired ===<br />
<br />
Firefox uses {{ic|~/Desktop}} as the default place for download and upload files. To change it to another folder, set the {{ic|XDG_DESKTOP_DIR}} option as explained in [[XDG user directories]].<br />
<br />
=== Make plugins respect blocked pop-ups ===<br />
<br />
Some plugins can misbehave and bypass the default settings, such as the Flash plugin. You can prevent this by doing the following:<br />
<br />
# Type {{ic|about:config}} into the address bar.<br />
# Right-click on the page and select ''New > Integer''.<br />
# Name it {{ic|privacy.popups.disable_from_plugins}}.<br />
# Set the value to {{ic|2}}.<br />
<br />
The possible values are:<br />
<br />
* {{ic|'''0'''}}: Allow all popups from plugins.<br />
* {{ic|'''1'''}}: Allow popups, but limit them to {{ic|dom.popup_maximum}}.<br />
* {{ic|'''2'''}}: Block popups from plugins.<br />
* {{ic|'''3'''}}: Block popups from plugins, even on whitelisted sites.<br />
<br />
=== Changes to userChrome.css and userContent.css are ignored ===<br />
<br />
Set {{ic|toolkit.legacyUserProfileCustomizations.stylesheets}} to {{ic|true}} in {{ic|about:config}}<br />
<br />
=== Middle-click behavior ===<br />
<br />
To use the middle mouse button to paste whatever text has been highlighted/added to the clipboard, as is common in UNIX-like operating systems, set either {{ic|middlemouse.contentLoadURL}} or {{ic|middlemouse.paste}} to {{ic|true}} in {{ic|about:config}}. Having {{ic|middlemouse.contentLoadURL}} enabled was the default behaviour prior to Firefox 57.<br />
<br />
To scroll on middle-click (default for Windows browsers) set {{ic|general.autoScroll}} to {{ic|true}}.<br />
<br />
=== Backspace does not work as the 'Back' button ===<br />
<br />
According to [http://kb.mozillazine.org/Browser.backspace_action MozillaZine], the {{ic|Backspace}} key was mapped based on which platform the browser was running on. As a compromise, this preference was created to allow the {{ic|Backspace}} key to either go back/forward, scroll up/down a page, or do nothing.<br />
<br />
To make {{ic|Backspace}} go back one page in the tab's history and {{ic|Shift+Backspace}} go forward, set {{ic|browser.backspace_action}} to {{ic|0}} in {{ic|about:config}}.<br />
<br />
To have the {{ic|Backspace}} key scroll up one page and {{ic|Shift+Backspace}} scroll down one page, set {{ic|browser.backspace_action}} to {{ic|1}}. Setting this property to any other value will leave the key unmapped (Arch Linux defaults to {{ic|2}}, in other words, it is unmapped by default).<br />
<br />
=== Firefox does not remember login information ===<br />
<br />
It may be due to a corrupted {{ic|cookies.sqlite}} file in [https://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data Firefox's profile] folder. In order to fix this, just rename or remove {{ic|cookie.sqlite}} while Firefox is not running.<br />
<br />
Open a terminal of choice and type the following:<br />
<br />
$ rm -f ~/.mozilla/firefox/<profile id>.default/cookies.sqlite<br />
<br />
The profile id is a random 8 character string.<br />
<br />
Restart Firefox and see if it solved the problem.<br />
<br />
If it didn't work, check if there exists a {{ic|cookies.sqlite.bak}} file that you could use to manually restore the cookies.<br />
<br />
=== Cannot enter/leave fullscreen ===<br />
<br />
If Firefox detects an [https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html EWMH/ICCCM] compliant window manager, it will try to send a WM_STATE message to the root window to request Firefox be made to enter (or leave) full-screen mode (as defined by the window manager). Window managers are allowed to ignore it, but if they do, Firefox will assume the request got denied and propagate it to the end user which results in nothing happening. This may result in not being able to full screen a video. A general workaround is to set the {{ic|full-screen-api.ignore-widgets}} to {{ic|true}} in {{ic|about:config}}. <br />
<br />
Related bug reports: [https://bugzilla.mozilla.org/show_bug.cgi?id=1189622 Bugzilla 1189622].<br />
<br />
=== Firefox detects the wrong version of my plugin ===<br />
<br />
When you close Firefox, the latter saves the current timestamp and version of your plugins inside {{ic|pluginreg.dat}} located in your profile folder, typically in {{ic|~/.mozilla/firefox/''xxxxxxxx''.default/}}.<br />
<br />
If you upgraded your plugin when Firefox was still running, you will thus have the wrong information inside that file. The next time you will restart Firefox you will get that message {{ic|Firefox has prevented the outdated plugin "XXXX" from running on ...}} when you will be trying to open content dedicated to that plugin on the web. This problem often appears with the official [[Browser plugins#Adobe Flash Player|Adobe Flash Player plugin]] which has been upgraded while Firefox was still running.<br />
<br />
The solution is to remove the file {{ic|pluginreg.dat}} from your profile and that is it. Firefox will not complain about the missing file as it will be recreated the next time Firefox will be closed. [https://bugzilla.mozilla.org/show_bug.cgi?id=1109795#c16]<br />
<br />
=== JavaScript context menu does not appear on some sites ===<br />
<br />
You can try setting {{ic|dom.w3c_touch_events.enabled}} to {{ic|0}} in {{ic|about:config}}.<br />
<br />
=== Firefox does not remember default spell check language ===<br />
<br />
The default spell checking language can be set as follows:<br />
<br />
# Type {{ic|about:config}} in the address bar.<br />
# Set {{ic|spellchecker.dictionary}} to your language of choice, for instance {{ic|en_GB}}.<br />
# Notice that the for dictionaries installed as a Firefox plugin the notation is {{ic|en-GB}}, and for {{Pkg|hunspell}} dictionaries the notation is {{ic|en_GB}}.<br />
<br />
When you only have system wide dictionaries installed with {{Pkg|hunspell}}, Firefox might not remember your default dictionary language settings. This can be fixed by having at least one [https://addons.mozilla.org/firefox/language-tools/ dictionary] installed as a Firefox plugin. Notice that now you will also have a tab ''Dictionaries'' in ''Add-ons''. You may have to change the order of ''preferred language for displaying pages'' in {{ic|about:preferences#general}} to make the spell check default to the language of the addon dictionary.<br />
<br />
Related questions on the '''StackExchange''' platform: [https://stackoverflow.com/questions/26936792/change-firefox-spell-check-default-language/29446115], [https://stackoverflow.com/questions/21542515/change-default-language-on-firefox/29446353], [https://askubuntu.com/questions/184300/how-can-i-change-firefoxs-default-dictionary/576877]<br />
<br />
Related bug reports: [https://bugzilla.mozilla.org/show_bug.cgi?id=776028 Bugzilla 776028], [https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1026869 Ubuntu bug 1026869]<br />
<br />
=== Some MathML symbols are missing ===<br />
<br />
You need some Math fonts, namely Latin Modern Math and STIX (see this MDN page: [https://developer.mozilla.org/en-US/docs/Mozilla/MathML_Project/Fonts#Linux]), to display MathML correctly.<br />
<br />
In Arch Linux, these fonts are provided by {{Pkg|texlive-core}} '''and''' {{Pkg|texlive-fontsextra}}, but they are not available to fontconfig by default. See [[TeX Live#Making fonts available to Fontconfig]] for details. You can also try other [[Fonts#Math|Math fonts]].<br />
<br />
=== Tearing video in fullscreen mode ===<br />
<br />
If you are using the Xorg Intel or Nouveau drivers and experience tearing video in fullscreen mode, try [[Firefox/Tweaks#Enable OpenGL compositor]].<br />
<br />
=== Tearing when scrolling ===<br />
<br />
Try disabling smooth scrolling in ''Preferences > Browsing''.<br />
<br />
=== Firefox WebRTC module cannot detect a microphone ===<br />
<br />
WebRTC applications for instance [https://mozilla.github.io/webrtc-landing/gum_test.html Firefox WebRTC getUserMedia test page] say that microphone cannot be found. Issue is reproducible for both ALSA or PulseAudio setup. Firefox debug logs show the following error:<br />
<br />
{{hc|1=$ NSPR_LOG_MODULES=MediaManager:5,GetUserMedia:5 firefox|2=<br />
...<br />
[Unnamed thread 0x7fd7c0654340]: D/GetUserMedia VoEHardware:GetRecordingDeviceName: Failed 1<br />
}}<br />
<br />
You can try setting {{ic|media.navigator.audio.full_duplex}} property to {{ic|false}} at {{ic|about:config}} Firefox page and restart Firefox.<br />
<br />
This can also help if you are using the PulseAudio [[PulseAudio/Troubleshooting#Enable Echo/Noise-Cancellation|module-echo-cancel]] and Firefox does not recognise the virtual echo canceling source.<br />
<br />
=== Cannot login with my Chinese account ===<br />
<br />
Firefox provides a local service for Chinese users, with a local account totally different from the international one. Firefox installed with the {{Pkg|firefox}} package uses the international account system by default, to change into the Chinese local service, you should install the add-on manager on [http://mozilla.com.cn/thread-343905-1-1.html this page], then you can login with your Chinese account now.<br />
<br />
=== No audio on certain videos when using JACK and PulseAudio ===<br />
<br />
If you are using JACK in combination with PulseAudio and cannot hear any sound on some videos it could be because those videos have mono audio. This happens if your JACK setup uses more than just stereo, but you use normal headphones. To fix this you simply have to connect the {{ic|front-center}} port from the PulseAudio JACK Sink to both {{ic|playback_1}} and {{ic|playback_2}} ports of the system output.<br />
<br />
You can also do this automatically using a script:<br />
<br />
{{hc|jack-mono.sh<br />
|2=#!/bin/sh<br />
jack_connect "PulseAudio JACK Sink:front-center" "system:playback_1"<br />
jack_connect "PulseAudio JACK Sink:front-center" "system:playback_2"<br />
}}<br />
<br />
Keep in mind that the names for the sink and the ports might be different for you. You can check what your JACK setup looks like with a Patchbay like Catia from {{Pkg|cadence}}.<br />
<br />
=== Geolocation does not work ===<br />
<br />
Recently, Google limited the usage its location service for Arch Linux, which causes the following error when geolocation is enabled on a website: {{ic|Geolocation error: Unknown error acquiring position}}. Region-locked services such as [https://www.hulu.com/ Hulu] may display a similar error indicating that your location could not be determined even though you've allowed location services for the site.<br />
<br />
To avoid these problems, you can switch to use the [https://location.services.mozilla.com/ Mozilla Location Service]. In {{ic|about:config}} change the {{ic|geo.provider.network.url}} setting to:<br />
<br />
<nowiki>https://location.services.mozilla.com/v1/geolocate?key=%MOZILLA_API_KEY%</nowiki><br />
<br />
See {{Bug|65241}} for more details.<br />
<br />
=== Right mouse button instantly clicks the first option in window managers ===<br />
<br />
This problem has been observed in [[i3]], [[bspwm]] and [[xmonad]].<br />
<br />
To fix it, navigate to {{ic|about:config}} and change {{ic|ui.context_menus.after_mouseup}} to {{ic|true}}.<br />
<br />
See [https://www.reddit.com/r/i3wm/comments/88k0yt/right_mouse_btn_instantly_clicks_first_option_in/]<br />
<br />
== See also ==<br />
<br />
* [https://www.mozilla.org/firefox/ Official website]<br />
* [https://www.mozilla.org/ Mozilla Foundation]<br />
* [[MozillaWiki:Firefox]]<br />
* [[Wikipedia:Mozilla Firefox]]<br />
* [https://addons.mozilla.org/ Firefox Add-ons]<br />
* [https://addons.mozilla.org/firefox/themes/ Firefox themes]<br />
* [https://ftp.mozilla.org/pub/firefox/releases/ Mozilla's FTP]<br />
* [http://forums.mozillazine.org/ mozillaZine] unofficial forums</div>Ernetashttps://wiki.archlinux.org/index.php?title=Xiaomi_Mi_Notebook_Pro_15.6&diff=627047Xiaomi Mi Notebook Pro 15.62020-07-28T10:49:13Z<p>Ernetas: Fix model name</p>
<hr />
<div>[[Category:Xiaomi]]<br />
[[ja:Xiaomi Mi Notebook Pro 15.6]]<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| Wireless || {{G|Working}} || iwlwifi<br />
|-<br />
| Bluetooth || {{G|Working}}|| btusb<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| USB-C / Thunderbolt 3 || {{G|Working}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || xiaomi_wmi<br />
|}<br />
<br />
The Mi Notebook Pro 15.6 is an aluminium notebook. It is a product by the Chinese Company Xiaomi.<br />
<br />
The installation should be going without any problems if you follow the following steps.<br />
<br />
== Pre-Installation System Settings ==<br />
<br />
It is actually very easy getting the Arch Installation Medium to boot properly. Prior to booting the Arch installation ISO enter the UEFI menu by pressing F2 during Boot.<br />
<br />
* Security -> set password<br />
* Security -> Disable Secure Boot<br />
* reset the password by setting the password again but letting the "New Password" fields blank<br />
<br />
Installation of Arch can proceed normally. Refer to the [[Installation guide]] for more info.<br />
{{Note|1=Remember that your SSD is called {{ic|nvme0n1}}, not {{ic|sda}}.}}<br />
<br />
== Graphics Card Configuration ==<br />
<br />
The Mi Book has an Intel, as well as an NVIDIA GPU.<br />
<br />
=== Intel Only ===<br />
<br />
If you want to completely disable the NVIDIA GPU (which might save batterlife), do the following:<br />
<br />
* Install the {{pkg|xf86-video-intel}} package<br />
* Blacklist the {{pkg|nvidia}} and {{pkg|xf86-video-nouveau}} kernel modules [[Kernel modules#Blacklisting]]<br />
<br />
{{hc|/etc/modprobe.d/nouveau.conf|2=<br />
blacklist nouveau<br />
blacklist nvidia<br />
}}<br />
<br />
* Install {{pkg|bbswitch}} to [[Bumblebee#Power_management|turn off the card]]<br />
<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=0<br />
}}<br />
<br />
=== Intel/NVIDIA Hybrid Configuration ===<br />
<br />
You can enable hybrid GPUs by either using [[Bumblebee]] or [[NVIDIA Optimus]]. Bumblebee is generally better for battery-life and compatibility but not officially supported by NVIDIA.<br />
<br />
Refer to the respective articles.<br />
<br />
Optimus-manager [https://github.com/Askannz/optimus-manager] works great as well. In conjunction with bbswitch, it allows easy and persistent switching between modes (Intel, Hybrid, Nvidia) even after sleep / hibernation.<br />
<br />
Note that included MX150 GPU does not properly work with VDPAU. It also does not work with NVDECODE and NVENCODE. Thus, video playback works faster and better with Intel's chip with VAAPI on this particular notebook. Even though it supports specifications, this particular GPUs hardware acceleration APIs do not work with the proprietary NVIDIA driver (nouveau needs to be tested). The only benefit of NVIDIA GPU is better performance on high-resolution screens and CUDA/gaming.<br />
<br />
While video playback performance is best with Intel VAAPI, battery life is best when relying on CPU for video decoding (as VDPAU/NCDECODE/NVENCODE does not work).<br />
<br />
== Input ==<br />
<br />
=== Touchpad ===<br />
<br />
To use the touchpad like a normal one, you have to use {{pkg|xf86-input-libinput}}. If you use {{pkg|xf86-input-evdev}}, your touchpad acts like a touchscreen (e.g it maps your movements directly to your screen). But if you are using {{pkg|xf86-input-synaptics}} (although you really should not, because it is deprecated (see [[Synaptics]])) things are only working sporadically. This configuration of {{pkg|libinput}} using XOrg configuration files enables two-finger gestures, tap-to-click and 2-and 3-finger clicks (for right- and middle-click respectively).<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-touchpad.conf|2=<br />
Section "InputClass"<br />
Identifier "libinput touchpad"<br />
Driver "libinput"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Tapping" "on"<br />
Option "ClickMethod" "clickfinger"<br />
Option "NaturalScrolling" "true"<br />
EndSection<br />
}}<br />
<br />
=== Fn-Keys ===<br />
<br />
On this notebook, the Fn-keys are enabled as default (e.g. pressing F1 mutes the sound). If pressing the keys does nothing you are most likely using a [[Window manager]] and not a [[Desktop environment]]. Use the respective configuration files to bind the keys to their use. For example [[Xbindkeys]] or [[i3]]'s {{ic|bindsym}}.<br />
<br />
Most Fn-keys return the correct keycodes. Here is a table containing that information:<br />
<br />
{| class="wikitable"<br />
! Fn-F-Key<br />
! Keycode<br />
|-<br />
| {{ic|F1}}<br />
| {{ic|XF86AudioMute}}<br />
|-<br />
| {{ic|F2}}<br />
| {{ic|XF86AudioLowerVolume}}<br />
|-<br />
| {{ic|F3}}<br />
| {{ic|XF86AudioRaiseVolume}}<br />
|-<br />
| {{ic|F4}}<br />
| {{ic|XF86MonBrightnessDown}}<br />
|-<br />
| {{ic|F5}}<br />
| {{ic|XF86MonBrightnessUp}}<br />
|-<br />
| {{ic|F6}}<br />
| {{ic|Super_L + P}}<br />
|-<br />
| {{ic|F7}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F8}}<br />
| {{ic|Super_L + Tab}}<br />
|-<br />
| {{ic|F9}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F10}}<br />
| {{ic|Turns Keyboard backlight on/off}}<br />
|-<br />
| {{ic|F11}}<br />
| {{ic|Print}}<br />
|-<br />
| {{ic|F12}}<br />
| {{ic|Insert}}<br />
|}<br />
<br />
To make F7 ("Scissors") work, one have to make sure "xiaomi_wmi" kernel module is loaded. This enables you to assign anything to the key.<br />
<br />
== Display Calibration ==<br />
<br />
Factory display calibration is poor. Check the panel model:<br />
<br />
$ edid-decode < /sys/class/drm/card0-eDP-1/edid | grep Alphanumeric<br />
<br />
If it's NV156FHM-N61, try the [[ICC profiles]] at [https://www.notebookcheck.net/uploads/tx_nbc2/NV156FHM_N61.icm].<br />
<br />
== Hardware information ==<br />
<br />
The output of ''lspci'' is<br />
<br />
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)<br />
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)<br />
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)<br />
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1c.7 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #8 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
01:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)<br />
03:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)<br />
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961<br />
<br />
The output of ''lsusb'' is<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 005: ID 04f3:0c1a Elan Microelectronics Corp. ELAN:Fingerprint<br />
Bus 001 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller<br />
Bus 001 Device 003: ID 05c8:03b7 Cheng Uei Precision Industry Co., Ltd (Foxlink) XiaoMi USB 2.0 Webcam<br />
Bus 001 Device 002: ID 8087:0a2b Intel Corp. <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
== Troubleshoothing ==<br />
<br />
=== Backlight ===<br />
<br />
You can adjust brightness directly (works even with {{ic|modesetting}} driver):<br />
<br />
# echo 7500 > /sys/class/backlight/intel_backlight/brightness<br />
<br />
<br />
However, if you use a tool like {{pkg|xorg-xbacklight}} in its default configuration, nothing happens, because the path to the backlighting variable is not standard. To fix this issue, you have to setup Intel driver and add Backlight option to respective X-Org configuration file:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-backlight.conf|2=<br />
Section "Device" <br />
Identifier "Card0" <br />
Driver "intel" <br />
Option "Backlight" "intel_backlight" <br />
BusID "PCI:0:2:0" <br />
EndSection <br />
}}</div>Ernetashttps://wiki.archlinux.org/index.php?title=Xiaomi_Mi_Notebook_Pro_15.6&diff=603838Xiaomi Mi Notebook Pro 15.62020-04-03T09:22:45Z<p>Ernetas: Fix edid-decode command</p>
<hr />
<div>[[Category:Xiaomi]]<br />
[[ja:Xiaomi Mi Notebook Pro 15.6]]<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| Wireless || {{G|Working}} || iwlwifi<br />
|-<br />
| Bluetooth || {{G|Working}}|| btusb<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| USB-C / Thunderbolt 3 || {{G|Working}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || xiaomi_wmi<br />
|}<br />
<br />
The Mi Notebook Air 15.6 is an aluminium notebook. It is a product by the Chinese Company Xiaomi.<br />
<br />
The installation should be going without any problems if you follow the following steps.<br />
<br />
== Pre-Installation System Settings ==<br />
<br />
It is actually very easy getting the Arch Installation Medium to boot properly. Prior to booting the Arch installation ISO enter the UEFI menu by pressing F2 during Boot.<br />
<br />
* Security -> set password<br />
* Security -> Disable Secure Boot<br />
* reset the password by setting the password again but letting the "New Password" fields blank<br />
<br />
Installation of Arch can proceed normally. Refer to the [[Installation guide]] for more info.<br />
{{Note|1=Remember that your SSD is called {{ic|nvme0n1}}, not {{ic|sda}}.}}<br />
<br />
== Graphics Card Configuration ==<br />
<br />
The Mi Book has an Intel, as well as an NVIDIA GPU.<br />
<br />
=== Intel Only ===<br />
<br />
If you want to completely disable the NVIDIA GPU (which might save batterlife), do the following:<br />
<br />
* Install the {{pkg|xf86-video-intel}} package<br />
* Blacklist the {{pkg|nvidia}} and {{pkg|xf86-video-nouveau}} kernel modules [[Kernel modules#Blacklisting]]<br />
<br />
{{hc|/etc/modprobe.d/nouveau.conf|2=<br />
blacklist nouveau<br />
blacklist nvidia<br />
}}<br />
<br />
* Install {{pkg|bbswitch}} to [[Bumblebee#Power_management|turn off the card]]<br />
<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=0<br />
}}<br />
<br />
=== Intel/NVIDIA Hybrid Configuration ===<br />
<br />
You can enable hybrid GPUs by either using [[Bumblebee]] or [[NVIDIA Optimus]]. Bumblebee is generally better for battery-life and compatibility but not officially supported by NVIDIA.<br />
<br />
Refer to the respective articles.<br />
<br />
Note that included MX150 GPU does not properly work with VDPAU. It also does not work with NVDECODE and NVENCODE. Thus, video playback works faster and better with Intel's chip with VAAPI on this particular notebook. Even though it supports specifications, this particular GPUs hardware acceleration APIs do not work with the proprietary NVIDIA driver (nouveau needs to be tested). The only benefit of NVIDIA GPU is better performance on high-resolution screens and CUDA/gaming.<br />
<br />
While video playback performance is best with Intel VAAPI, battery life is best when relying on CPU for video decoding (as VDPAU/NCDECODE/NVENCODE does not work).<br />
<br />
== Input ==<br />
<br />
=== Touchpad ===<br />
<br />
To use the touchpad like a normal one, you have to use {{pkg|xf86-input-libinput}}. If you use {{pkg|xf86-input-evdev}}, your touchpad acts like a touchscreen (e.g it maps your movements directly to your screen). But if you are using {{pkg|xf86-input-synaptics}} (although you really should not, because it is deprecated (see [[Synaptics]])) things are only working sporadically. This configuration of {{pkg|libinput}} using XOrg configuration files enables two-finger gestures, tap-to-click and 2-and 3-finger clicks (for right- and middle-click respectively).<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-touchpad.conf|2=<br />
Section "InputClass"<br />
Identifier "libinput touchpad"<br />
Driver "libinput"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Tapping" "on"<br />
Option "ClickMethod" "clickfinger"<br />
Option "NaturalScrolling" "true"<br />
EndSection<br />
}}<br />
<br />
=== Fn-Keys ===<br />
<br />
On this notebook, the Fn-keys are enabled as default (e.g. pressing F1 mutes the sound). If pressing the keys does nothing you are most likely using a [[Window manager]] and not a [[Desktop environment]]. Use the respective configuration files to bind the keys to their use. For example [[Xbindkeys]] or [[i3]]'s {{ic|bindsym}}.<br />
<br />
Most Fn-keys return the correct keycodes. Here is a table containing that information:<br />
<br />
{| class="wikitable"<br />
! Fn-F-Key<br />
! Keycode<br />
|-<br />
| {{ic|F1}}<br />
| {{ic|XF86AudioMute}}<br />
|-<br />
| {{ic|F2}}<br />
| {{ic|XF86AudioLowerVolume}}<br />
|-<br />
| {{ic|F3}}<br />
| {{ic|XF86AudioRaiseVolume}}<br />
|-<br />
| {{ic|F4}}<br />
| {{ic|XF86MonBrightnessDown}}<br />
|-<br />
| {{ic|F5}}<br />
| {{ic|XF86MonBrightnessUp}}<br />
|-<br />
| {{ic|F6}}<br />
| {{ic|Super_L + P}}<br />
|-<br />
| {{ic|F7}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F8}}<br />
| {{ic|Super_L + Tab}}<br />
|-<br />
| {{ic|F9}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F10}}<br />
| {{ic|Turns Keyboard backlight on/off}}<br />
|-<br />
| {{ic|F11}}<br />
| {{ic|Print}}<br />
|-<br />
| {{ic|F12}}<br />
| {{ic|Insert}}<br />
|}<br />
<br />
== Display Calibration ==<br />
<br />
Factory display calibration is poor. Check the panel model:<br />
<br />
$ edid-decode < /sys/class/drm/card0-eDP-1/edid | grep Alphanumeric<br />
<br />
If it's NV156FHM-N61, try the [[ICC profiles]] at [https://www.notebookcheck.net/uploads/tx_nbc2/NV156FHM_N61.icm].<br />
<br />
== Hardware information ==<br />
<br />
The output of ''lspci'' is<br />
<br />
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)<br />
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)<br />
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)<br />
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1c.7 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #8 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
01:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)<br />
03:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)<br />
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961<br />
<br />
The output of ''lsusb'' is<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 005: ID 04f3:0c1a Elan Microelectronics Corp. ELAN:Fingerprint<br />
Bus 001 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller<br />
Bus 001 Device 003: ID 05c8:03b7 Cheng Uei Precision Industry Co., Ltd (Foxlink) XiaoMi USB 2.0 Webcam<br />
Bus 001 Device 002: ID 8087:0a2b Intel Corp. <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
== Troubleshoothing ==<br />
<br />
=== Backlight ===<br />
<br />
You can adjust brightness directly (works even with {{ic|modesetting}} driver):<br />
<br />
# echo 7500 > /sys/class/backlight/intel_backlight/brightness<br />
<br />
<br />
However, if you use a tool like {{pkg|xorg-xbacklight}} in its default configuration, nothing happens, because the path to the backlighting variable is not standard. To fix this issue, you have to setup Intel driver and add Backlight option to respective X-Org configuration file:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-backlight.conf|2=<br />
Section "Device" <br />
Identifier "Card0" <br />
Driver "intel" <br />
Option "Backlight" "intel_backlight" <br />
BusID "PCI:0:2:0" <br />
EndSection <br />
}}</div>Ernetashttps://wiki.archlinux.org/index.php?title=Xiaomi_Mi_Notebook_Air_13.3&diff=603831Xiaomi Mi Notebook Air 13.32020-04-03T09:02:36Z<p>Ernetas: /* Troubleshooting */ Removed Wifi paragraph, as kernel is above 4.9 now</p>
<hr />
<div>[[Category:Xiaomi]]<br />
[[ja:Xiaomi Mi Notebook Air 13.3]]<br />
[[zh-hans:Xiaomi Mi Notebook Air 13.3]]<br />
<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| Wireless || {{G|Working}} || iwlwifi<br />
|-<br />
| Bluetooth || {{G|Working}}|| btusb<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| USB-C / Thunderbolt 3 || {{G|Working}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Mi Notebook Air 13.3 is an aluminium Ultrabook. It is a product by the Chinese Company Xiaomi and is currently only available in China or through import online-shops. Using the [https://ark.intel.com/products/88193/Intel-Core-i5-6200U-Processor-3M-Cache-up-to-2_80-GHz Intel Core i5 6200U] @ 2.3 GHz and the NVIDIA GeForce 940MX, it provides good power for a decent price.<br />
<br />
The installation should be going without any problems, if you follow the following steps.<br />
<br />
== Pre-Installation System Settings ==<br />
<br />
It is actually very easy getting the Arch Installation Medium to boot properly. Prior to booting the Arch installation ISO enter the UEFI menu by pressing F2 during Boot.<br />
<br />
* Security -> set password<br />
* Security -> Disable Secure Boot<br />
* reset the password by setting the password again but letting the "New Password" fields blank<br />
<br />
Installation of Arch can proceed normally. Refer to the [[Installation guide]] for more info.<br />
{{Note|1=Remember that your SSD is called {{ic|nvme0n1}}, not {{ic|sda}}.}}<br />
<br />
== Graphics Card Configuration ==<br />
<br />
The Mi Book has an Intel, as well as a Nvidia GPU. <br />
<br />
=== Intel Only ===<br />
<br />
If you want to completely disable the Nvidia GPU and save batterylife, do the following:<br />
<br />
* Install the {{pkg|xf86-video-intel}} package<br />
* Blacklist the {{pkg|nvidia}} and {{pkg|xf86-video-nouveau}} kernel modules [[Kernel modules#Blacklisting]]<br />
<br />
{{hc|/etc/modprobe.d/nouveau.conf|2=<br />
blacklist nouveau<br />
blacklist nvidia<br />
}}<br />
<br />
* Install {{pkg|bbswitch}} to [[Bumblebee#Power_management|turn off the card]]<br />
<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=0<br />
}}<br />
<br />
=== Intel/Nvidia Hybrid Configuration ===<br />
<br />
You can enable hybrid GPUs by either using [[Bumblebee]] or [[NVIDIA Optimus]]. Bumblebee is generally better for battery-life and compatibility but not officially supported by NVIDIA.<br />
<br />
Refer to the respective articles.<br />
<br />
== Input ==<br />
<br />
=== Touchpad ===<br />
<br />
To use the touchpad like a normal one, you have to use {{pkg|xf86-input-libinput}}. If you use {{pkg|xf86-input-evdev}}, your touchpad acts like a touchscreen (e.g it maps your movements directly to your screen). But if you are using {{pkg|xf86-input-synaptics}} (although you really should not, because it is deprecated (see [[Synaptics]])) things are only working sporadically. This configuration of {{pkg|libinput}} using XOrg configuration files enables two finger gestures, tap-to-click and 2-and 3-finger clicks (for right- and middle-click respectively).<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-touchpad.conf|2=<br />
Section "InputClass"<br />
Identifier "libinput touchpad"<br />
Driver "libinput"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"/<br />
Option "Tapping" "on"<br />
Option "ClickMethod" "clickfinger"<br />
Option "NaturalScrolling" "true"<br />
EndSection<br />
}}<br />
<br />
=== Fn-Keys ===<br />
<br />
On this notebook the Fn-keys are enabled as default (e.g. pressing F1 mutes the sound). If pressing the keys does nothing you are most likely using a [[Window manager]] and not a [[Desktop environment]]. Use the respective configuration files to bind the keys to their use. For example [[Xbindkeys]] or [[i3]]'s {{ic|bindsym}}.<br />
<br />
To reverse to normal Fn keys just press: Fn+Esc<br />
<br />
Most Fn-keys return the correct keycodes. Here is a table containing that information:<br />
<br />
{| class="wikitable"<br />
! Fn-F-Key<br />
! Keycode<br />
|-<br />
| {{ic|F1}}<br />
| {{ic|XF86AudioMute}}<br />
|-<br />
| {{ic|F2}}<br />
| {{ic|XF86AudioLowerVolume}}<br />
|-<br />
| {{ic|F3}}<br />
| {{ic|XF86AudioRaiseVolume}}<br />
|-<br />
| {{ic|F4}}<br />
| {{ic|XF86MonBrightnessDown}}<br />
|-<br />
| {{ic|F5}}<br />
| {{ic|XF86MonBrightnessUp}}<br />
|-<br />
| {{ic|F6}}<br />
| {{ic|Super_L + P}}<br />
|-<br />
| {{ic|F7}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F8}}<br />
| {{ic|Super_L + Tab}}<br />
|-<br />
| {{ic|F9}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F10}}<br />
| {{ic|Turns Keyboard backlight on/off}}<br />
|-<br />
| {{ic|F11}}<br />
| {{ic|Print}}<br />
|-<br />
| {{ic|F12}}<br />
| {{ic|Insert}}<br />
|}<br />
<br />
== Display Calibration ==<br />
<br />
Factory display calibration is poor. In lieu of a colorimeter, try the [[ICC profiles]] at [https://github.com/tlvince/xiaomi-mi-notebook-air-13/tree/master/display-calibration tlvince/xiaomi-mi-notebook-air-13].<br />
<br />
== Hardware information ==<br />
<br />
The output of ''lspci'' is<br />
<br />
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation HD Graphics 520 (rev 07)<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:17.0 SATA controller: Intel Corporation Sunrise Point-LP SATA Controller [AHCI mode] (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point-LP LPC Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
01:00.0 3D controller: NVIDIA Corporation GM108M [GeForce 940MX] (rev ff)<br />
02:00.0 Network controller: Intel Corporation Wireless 8260 (rev 3a)<br />
03:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM951/PM951 (rev 01)<br />
<br />
The output of ''lsusb'' is<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 003: ID 8087:0a2b Intel Corp.<br />
Bus 001 Device 002: ID 05c8:03a2 Cheng Uei Precision Industry Co., Ltd (Foxlink)<br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
== Troubleshooting ==<br />
<br />
=== Backlight ===<br />
<br />
If you use a tool like {{pkg|xorg-xbacklight}} in its default configuration, nothing happens, because the path to the backlighting variable is not standard. To fix this issue, you have to use a X-Org configuration file:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-backlight.conf|2=<br />
Section "Device" <br />
Identifier "Card0" <br />
Driver "intel" <br />
Option "Backlight" "intel_backlight" <br />
BusID "PCI:0:2:0" <br />
EndSection <br />
}}<br />
<br />
=== Audio Jack ===<br />
<br />
If you want to use the microphone from the headset plugged in the combo jack input add this line to alsa config:<br />
<br />
{{hc|/etc/modprobe.d/alsa-base.conf|2=<br />
options snd-hda-intel model=dell-headset-multi<br />
}}<br />
<br />
And reboot the machine.</div>Ernetashttps://wiki.archlinux.org/index.php?title=Xiaomi_Mi_Notebook_Pro_15.6&diff=583557Xiaomi Mi Notebook Pro 15.62019-09-21T17:51:27Z<p>Ernetas: Finishing a sentence /* Intel/NVIDIA Hybrid Configuration */</p>
<hr />
<div>[[Category:Xiaomi]]<br />
[[ja:Xiaomi Mi Notebook Pro 15.6]]<br />
[[zh-hans:Xiaomi Mi Notebook Pro 15.6]]<br />
<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| Wireless || {{G|Working}} || iwlwifi<br />
|-<br />
| Bluetooth || {{G|Working}}|| btusb<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| USB-C / Thunderbolt 3 || {{G|Working}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Mi Notebook Air 15.6 is an aluminium notebook. It is a product by the Chinese Company Xiaomi.<br />
<br />
The installation should be going without any problems if you follow the following steps.<br />
<br />
== Pre-Installation System Settings ==<br />
<br />
It is actually very easy getting the Arch Installation Medium to boot properly. Prior to booting the Arch installation ISO enter the UEFI menu by pressing F2 during Boot.<br />
<br />
* Security -> set password<br />
* Security -> Disable Secure Boot<br />
* reset the password by setting the password again but letting the "New Password" fields blank<br />
<br />
Installation of Arch can proceed normally. Refer to the [[Installation guide]] for more info.<br />
{{Note|1=Remember that your SSD is called {{ic|nvme0n1}}, not {{ic|sda}}.}}<br />
<br />
== Graphics Card Configuration ==<br />
<br />
The Mi Book has an Intel, as well as an NVIDIA GPU.<br />
<br />
=== Intel Only ===<br />
<br />
If you want to completely disable the NVIDIA GPU (which might save batterlife), do the following:<br />
<br />
* Install the {{pkg|xf86-video-intel}} package<br />
* Blacklist the {{pkg|nvidia}} and {{pkg|xf86-video-nouveau}} kernel modules [[Kernel modules#Blacklisting]]<br />
<br />
{{hc|/etc/modprobe.d/nouveau.conf|2=<br />
blacklist nouveau<br />
blacklist nvidia<br />
}}<br />
<br />
* Install {{pkg|bbswitch}} to [[Bumblebee#Power_management|turn off the card]]<br />
<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=0<br />
}}<br />
<br />
=== Intel/NVIDIA Hybrid Configuration ===<br />
<br />
You can enable hybrid GPUs by either using [[Bumblebee]] or [[NVIDIA Optimus]]. Bumblebee is generally better for battery-life and compatibility but not officially supported by NVIDIA.<br />
<br />
Refer to the respective articles.<br />
<br />
Note that included MX150 GPU does not properly work with VDPAU. It also does not work with NVDECODE and NVENCODE. Thus, video playback works faster and better with Intel's chip with VAAPI on this particular notebook. Even though it supports specifications, this particular GPUs hardware acceleration APIs do not work with the proprietary NVIDIA driver (nouveau needs to be tested). The only benefit of NVIDIA GPU is better performance on high-resolution screens and CUDA/gaming.<br />
<br />
While video playback performance is best with Intel VAAPI, battery life is best when relying on CPU for video decoding (as VDPAU/NCDECODE/NVENCODE does not work).<br />
<br />
== Input ==<br />
<br />
=== Touchpad ===<br />
<br />
To use the touchpad like a normal one, you have to use {{pkg|xf86-input-libinput}}. If you use {{pkg|xf86-input-evdev}}, your touchpad acts like a touchscreen (e.g it maps your movements directly to your screen). But if you are using {{pkg|xf86-input-synaptics}} (although you really should not, because it is deprecated (see [[Synaptics]])) things are only working sporadically. This configuration of {{pkg|libinput}} using XOrg configuration files enables two-finger gestures, tap-to-click and 2-and 3-finger clicks (for right- and middle-click respectively).<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-touchpad.conf|2=<br />
Section "InputClass"<br />
Identifier "libinput touchpad"<br />
Driver "libinput"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Tapping" "on"<br />
Option "ClickMethod" "clickfinger"<br />
Option "NaturalScrolling" "true"<br />
EndSection<br />
}}<br />
<br />
=== Fn-Keys ===<br />
<br />
On this notebook, the Fn-keys are enabled as default (e.g. pressing F1 mutes the sound). If pressing the keys does nothing you are most likely using a [[Window manager]] and not a [[Desktop environment]]. Use the respective configuration files to bind the keys to their use. For example [[Xbindkeys]] or [[i3]]'s {{ic|bindsym}}.<br />
<br />
Most Fn-keys return the correct keycodes. Here is a table containing that information:<br />
<br />
{| class="wikitable"<br />
! Fn-F-Key<br />
! Keycode<br />
|-<br />
| {{ic|F1}}<br />
| {{ic|XF86AudioMute}}<br />
|-<br />
| {{ic|F2}}<br />
| {{ic|XF86AudioLowerVolume}}<br />
|-<br />
| {{ic|F3}}<br />
| {{ic|XF86AudioRaiseVolume}}<br />
|-<br />
| {{ic|F4}}<br />
| {{ic|XF86MonBrightnessDown}}<br />
|-<br />
| {{ic|F5}}<br />
| {{ic|XF86MonBrightnessUp}}<br />
|-<br />
| {{ic|F6}}<br />
| {{ic|Super_L + P}}<br />
|-<br />
| {{ic|F7}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F8}}<br />
| {{ic|Super_L + Tab}}<br />
|-<br />
| {{ic|F9}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F10}}<br />
| {{ic|Turns Keyboard backlight on/off}}<br />
|-<br />
| {{ic|F11}}<br />
| {{ic|Print}}<br />
|-<br />
| {{ic|F12}}<br />
| {{ic|Insert}}<br />
|}<br />
<br />
== Display Calibration ==<br />
<br />
Factory display calibration is poor. Check the panel model:<br />
<br />
$ edid-decode < /sys/class/drm/card1-eDP-1/edid | grep ASCII<br />
<br />
If it's NV156FHM-N61, try the [[ICC profiles]] at [https://www.notebookcheck.net/uploads/tx_nbc2/NV156FHM_N61.icm].<br />
<br />
== Hardware information ==<br />
<br />
The output of ''lspci'' is<br />
<br />
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)<br />
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)<br />
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)<br />
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1c.7 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #8 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
01:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)<br />
03:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)<br />
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961<br />
<br />
The output of ''lsusb'' is<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 005: ID 04f3:0c1a Elan Microelectronics Corp. ELAN:Fingerprint<br />
Bus 001 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller<br />
Bus 001 Device 003: ID 05c8:03b7 Cheng Uei Precision Industry Co., Ltd (Foxlink) XiaoMi USB 2.0 Webcam<br />
Bus 001 Device 002: ID 8087:0a2b Intel Corp. <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
== Troubleshoothing ==<br />
<br />
=== Backlight ===<br />
<br />
You can adjust brightness directly (works even with {{ic|modesetting}} driver):<br />
<br />
# echo 7500 > /sys/class/backlight/intel_backlight/brightness<br />
<br />
<br />
However, if you use a tool like {{pkg|xorg-xbacklight}} in its default configuration, nothing happens, because the path to the backlighting variable is not standard. To fix this issue, you have to setup Intel driver and add Backlight option to respective X-Org configuration file:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-backlight.conf|2=<br />
Section "Device" <br />
Identifier "Card0" <br />
Driver "intel" <br />
Option "Backlight" "intel_backlight" <br />
BusID "PCI:0:2:0" <br />
EndSection <br />
}}</div>Ernetashttps://wiki.archlinux.org/index.php?title=Xiaomi_Mi_Notebook_Pro_15.6&diff=583546Xiaomi Mi Notebook Pro 15.62019-09-21T15:42:41Z<p>Ernetas: Initial commit. There are some notable differences between Notebook Air and Notebook Pro.</p>
<hr />
<div>[[Category:Xiaomi]]<br />
[[ja:Xiaomi Mi Notebook Pro 15.6]]<br />
[[zh-hans:Xiaomi Mi Notebook Pro 15.6]]<br />
<br />
{| class="wikitable" style="float: right;"<br />
| '''Device''' || '''Status''' || '''Modules'''<br />
|-<br />
| Video || {{G|Working}} || i915<br />
|-<br />
| Wireless || {{G|Working}} || iwlwifi<br />
|-<br />
| Bluetooth || {{G|Working}}|| btusb<br />
|-<br />
| Audio || {{G|Working}} || snd_hda_intel<br />
|-<br />
| Touchpad || {{G|Working}} || ?<br />
|-<br />
| Webcam || {{G|Working}} || uvcvideo<br />
|-<br />
| USB-C / Thunderbolt 3 || {{G|Working}} || ?<br />
|-<br />
| Function/Multimedia Keys || {{G|Working}} || ?<br />
|}<br />
<br />
The Mi Notebook Air 15.6 is an aluminium notebook. It is a product by the Chinese Company Xiaomi.<br />
<br />
The installation should be going without any problems if you follow the following steps.<br />
<br />
== Pre-Installation System Settings ==<br />
<br />
It is actually very easy getting the Arch Installation Medium to boot properly. Prior to booting the Arch installation ISO enter the UEFI menu by pressing F2 during Boot.<br />
<br />
* Security -> set password<br />
* Security -> Disable Secure Boot<br />
* reset the password by setting the password again but letting the "New Password" fields blank<br />
<br />
Installation of Arch can proceed normally. Refer to the [[Installation guide]] for more info.<br />
{{Note|1=Remember that your SSD is called {{ic|nvme0n1}}, not {{ic|sda}}.}}<br />
<br />
== Graphics Card Configuration ==<br />
<br />
The Mi Book has an Intel, as well as an NVIDIA GPU.<br />
<br />
=== Intel Only ===<br />
<br />
If you want to completely disable the NVIDIA GPU (which might save batterlife), do the following:<br />
<br />
* Install the {{pkg|xf86-video-intel}} package<br />
* Blacklist the {{pkg|nvidia}} and {{pkg|xf86-video-nouveau}} kernel modules [[Kernel modules#Blacklisting]]<br />
<br />
{{hc|/etc/modprobe.d/nouveau.conf|2=<br />
blacklist nouveau<br />
blacklist nvidia<br />
}}<br />
<br />
* Install {{pkg|bbswitch}} to [[Bumblebee#Power_management|turn off the card]]<br />
<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=0<br />
}}<br />
<br />
=== Intel/NVIDIA Hybrid Configuration ===<br />
<br />
You can enable hybrid GPUs by either using [[Bumblebee]] or [[NVIDIA Optimus]]. Bumblebee is generally better for battery-life and compatibility but not officially supported by NVIDIA.<br />
<br />
Refer to the respective articles.<br />
<br />
Note that included MX150 GPU does not properly work with VDPAU. It also does not work with NVDECODE and NVENCODE. Thus, video playback works faster and better with Intel's chip with VAAPI on this particular notebook. Even though it supports specifications, this particular GPUs hardware acceleration APIs do not work with the proprietary NVIDIA driver (nouveau needs . The only benefit of NVIDIA GPU is better performance on high-resolution screens and CUDA/gaming.<br />
<br />
While video playback performance is best with Intel VAAPI, battery life is best when relying on CPU for video decoding (as VDPAU/NCDECODE/NVENCODE does not work).<br />
<br />
== Input ==<br />
<br />
=== Touchpad ===<br />
<br />
To use the touchpad like a normal one, you have to use {{pkg|xf86-input-libinput}}. If you use {{pkg|xf86-input-evdev}}, your touchpad acts like a touchscreen (e.g it maps your movements directly to your screen). But if you are using {{pkg|xf86-input-synaptics}} (although you really should not, because it is deprecated (see [[Synaptics]])) things are only working sporadically. This configuration of {{pkg|libinput}} using XOrg configuration files enables two-finger gestures, tap-to-click and 2-and 3-finger clicks (for right- and middle-click respectively).<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-touchpad.conf|2=<br />
Section "InputClass"<br />
Identifier "libinput touchpad"<br />
Driver "libinput"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "Tapping" "on"<br />
Option "ClickMethod" "clickfinger"<br />
Option "NaturalScrolling" "true"<br />
EndSection<br />
}}<br />
<br />
=== Fn-Keys ===<br />
<br />
On this notebook, the Fn-keys are enabled as default (e.g. pressing F1 mutes the sound). If pressing the keys does nothing you are most likely using a [[Window manager]] and not a [[Desktop environment]]. Use the respective configuration files to bind the keys to their use. For example [[Xbindkeys]] or [[i3]]'s {{ic|bindsym}}.<br />
<br />
Most Fn-keys return the correct keycodes. Here is a table containing that information:<br />
<br />
{| class="wikitable"<br />
! Fn-F-Key<br />
! Keycode<br />
|-<br />
| {{ic|F1}}<br />
| {{ic|XF86AudioMute}}<br />
|-<br />
| {{ic|F2}}<br />
| {{ic|XF86AudioLowerVolume}}<br />
|-<br />
| {{ic|F3}}<br />
| {{ic|XF86AudioRaiseVolume}}<br />
|-<br />
| {{ic|F4}}<br />
| {{ic|XF86MonBrightnessDown}}<br />
|-<br />
| {{ic|F5}}<br />
| {{ic|XF86MonBrightnessUp}}<br />
|-<br />
| {{ic|F6}}<br />
| {{ic|Super_L + P}}<br />
|-<br />
| {{ic|F7}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F8}}<br />
| {{ic|Super_L + Tab}}<br />
|-<br />
| {{ic|F9}}<br />
| {{ic|Nothing}}<br />
|-<br />
| {{ic|F10}}<br />
| {{ic|Turns Keyboard backlight on/off}}<br />
|-<br />
| {{ic|F11}}<br />
| {{ic|Print}}<br />
|-<br />
| {{ic|F12}}<br />
| {{ic|Insert}}<br />
|}<br />
<br />
== Display Calibration ==<br />
<br />
Factory display calibration is poor. Check the panel model:<br />
<br />
$ edid-decode < /sys/class/drm/card1-eDP-1/edid | grep ASCII<br />
<br />
If it's NV156FHM-N61, try the [[ICC profiles]] at [https://www.notebookcheck.net/uploads/tx_nbc2/NV156FHM_N61.icm].<br />
<br />
== Hardware information ==<br />
<br />
The output of ''lspci'' is<br />
<br />
00:00.0 Host bridge: Intel Corporation Xeon E3-1200 v6/7th Gen Core Processor Host Bridge/DRAM Registers (rev 08)<br />
00:02.0 VGA compatible controller: Intel Corporation UHD Graphics 620 (rev 07)<br />
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th Gen Core Processor Gaussian Mixture Model<br />
00:14.0 USB controller: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller (rev 21)<br />
00:14.2 Signal processing controller: Intel Corporation Sunrise Point-LP Thermal subsystem (rev 21)<br />
00:15.0 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #0 (rev 21)<br />
00:15.1 Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO I2C Controller #1 (rev 21)<br />
00:16.0 Communication controller: Intel Corporation Sunrise Point-LP CSME HECI #1 (rev 21)<br />
00:1c.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #1 (rev f1)<br />
00:1c.4 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #5 (rev f1)<br />
00:1c.7 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #8 (rev f1)<br />
00:1d.0 PCI bridge: Intel Corporation Sunrise Point-LP PCI Express Root Port #9 (rev f1)<br />
00:1f.0 ISA bridge: Intel Corporation Sunrise Point LPC Controller/eSPI Controller (rev 21)<br />
00:1f.2 Memory controller: Intel Corporation Sunrise Point-LP PMC (rev 21)<br />
00:1f.3 Audio device: Intel Corporation Sunrise Point-LP HD Audio (rev 21)<br />
00:1f.4 SMBus: Intel Corporation Sunrise Point-LP SMBus (rev 21)<br />
01:00.0 3D controller: NVIDIA Corporation GP108M [GeForce MX150] (rev a1)<br />
03:00.0 Network controller: Intel Corporation Wireless 8265 / 8275 (rev 78)<br />
04:00.0 Non-Volatile memory controller: Samsung Electronics Co Ltd NVMe SSD Controller SM961/PM961<br />
<br />
The output of ''lsusb'' is<br />
<br />
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub<br />
Bus 001 Device 005: ID 04f3:0c1a Elan Microelectronics Corp. ELAN:Fingerprint<br />
Bus 001 Device 004: ID 0bda:0129 Realtek Semiconductor Corp. RTS5129 Card Reader Controller<br />
Bus 001 Device 003: ID 05c8:03b7 Cheng Uei Precision Industry Co., Ltd (Foxlink) XiaoMi USB 2.0 Webcam<br />
Bus 001 Device 002: ID 8087:0a2b Intel Corp. <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub<br />
<br />
== Troubleshoothing ==<br />
<br />
=== Backlight ===<br />
<br />
You can adjust brightness directly (works even with {{ic|modesetting}} driver):<br />
<br />
# echo 7500 > /sys/class/backlight/intel_backlight/brightness<br />
<br />
<br />
However, if you use a tool like {{pkg|xorg-xbacklight}} in its default configuration, nothing happens, because the path to the backlighting variable is not standard. To fix this issue, you have to setup Intel driver and add Backlight option to respective X-Org configuration file:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/10-backlight.conf|2=<br />
Section "Device" <br />
Identifier "Card0" <br />
Driver "intel" <br />
Option "Backlight" "intel_backlight" <br />
BusID "PCI:0:2:0" <br />
EndSection <br />
}}</div>Ernetashttps://wiki.archlinux.org/index.php?title=ICC_profiles&diff=517149ICC profiles2018-04-13T10:49:46Z<p>Ernetas: /* Loading ICC profiles */ Typo settiongs -> settings</p>
<hr />
<div>[[Category:Image manipulation]]<br />
[[ja:ICC プロファイル]]<br />
[[ru:ICC profiles]]<br />
As it pertains to general desktop use, an [[Wikipedia:ICC profile|ICC profile]] is a binary file which contains precise data regarding the color attributes of an input, or output device. Single, or multiple profiles can be applied across a system and its devices to produce consistent and repeatable results for graphic and document editing and publishing. ICC profiles are typically calibrated with a [[Wikipedia:Tristimulus colorimeter|(tristimulus) colorimeter]], or a spectrophotometer when absolute color accuracy is required.<br />
<br />
== Profile generation ==<br />
<br />
Color management is a workflow of hardware calibration, software profiling and embedding the profile into the picture or video. It's all based on using an [[Wikipedia:ICC profile|ICC profile]].<br />
<br />
=== Colorimeter or spectrometer ===<br />
<br />
It is highly recommended to use a colorimeter or spectrometer device for hardware-assisted display, printer and scanner calibration. For home use there are several affordable colorimeters available. Some are well- or even better-supported under Linux than on other operating systems. Frequently recommended devices are [http://www.xrite.com/colormunki-display X-Rite ColorMunki Display], [http://spyder.datacolor.com/portfolio-view/spyder5express/ DataColor Spyder5 Express] and the open source hardware [http://www.hughski.com/ ColorHug]. You can find more Linux-supported devices listed in the [http://www.argyllcms.com/doc/instruments.html AgyllCMS documentation].<br />
<br />
=== Argyll CMS ===<br />
<br />
The [http://www.argyllcms.com/ Argyll Color Management System] is a complete suite of command-line profile creation and loading tools listed under {{Pkg|argyllcms}}. <br />
<br />
Review the official [http://www.argyllcms.com/doc/ArgyllDoc.html Argyll CMS documentation] for details on how to profile selected devices.<br />
<br />
=== Monitor calibration and profiling with additional calibration hardware ===<br />
<br />
There is a GUI frontend for ArgyllCMS called [http://displaycal.net DisplayCal], available as {{Pkg|displaycal}}. In most common cases you will want to use its default settings. It is a common way to calibrate to a daylight color of 6500K and gamma 2,2. Read the DispalGui documentation for more. Many tutorials are available on the net.<br />
<br />
=== Scanner calibration ===<br />
<br />
Follow the scanner part of the [https://blog.simon-dreher.de/color-management.html scanner calibration] tutorial.<br />
<br />
=== Printer calibration ===<br />
<br />
See {{man|8|cups-calibrate}}.<br />
<br />
=== File transfer ===<br />
<br />
Profile generation on a Windows or macOS system is one of the easiest and most widely recommended methods to obtain a ICC monitor profile. Since ICC color profiles are written to an open specification, they are compatible across operating systems. Transferring profiles from one OS to another can be used as a workaround for the lack of support for certain spectrophotometers or colorimeters under Linux: one can simply produce a profile on a different OS and then use it in a Linux workflow. Note that the system on which the profile is generated must host the exact same video card and monitor for which the profile is to be used. Once generation of an ICC profile, or a series of profiles is complete on a Windows system, copy the file(s) from the default path:<br />
<br />
C:\WINDOWS\System32\spool\drivers\color<br />
<br />
macOS generally stores saved ICC profiles in one of two locations:<br />
<br />
/Library/ColorSync/Profiles<br />
/Users/USER_NAME/Library/ColorSync/Profile<br />
<br />
Once the appropriate {{Ic|.icc/.icm}} files have been copied, install the device profiles to your desired system. Common installation device profiles directories on Linux include:<br />
<br />
/usr/share/color/icc<br />
/usr/local/share/color/icc<br />
/home/USER_NAME/.color/icc<br />
<br />
{{Note|Ensure that the calibrated contrast, brightness and RGB settings of the monitor do not change between the time of calibration and the loading of the ICC profile. Use this method only if you are absolutely certain that neither Linux nor the other OS does anything behind your back (in video drivers or vendor utilities) that alters the signal actually sent to the display, or the way the display interprets the signal. Watch out for "Broadcast RGB" or similar settings. One concrete example where profiling in Windows and Linux yields [https://bugzilla.kernel.org/show_bug.cgi?id&#61;70721 significantly different results] is the Lenovo Ideapad Yoga 2 Pro laptop, because these OSes program the flat panel controller in very different ways.|}}<br />
<br />
=== Gnome Color Manager ===<br />
<br />
On Gnome, an ICC profile can easily be created by using {{pkg|gnome-color-manager}}. Under Gnome, this is accessible via the Control Center and is pretty straightforward to use. You'll need a colorimeter device to use this feature.<br />
<br />
==== Manually ====<br />
<br />
Ensure ''gnome-settings-daemon'' is started, and run:<br />
<br />
$ colormgr get-devices <br />
<br />
Look for the {{ic|Device ID}} line of your monitor. If this is e.g. {{ic|xrandr-Lenovo Group Limited}}, start calibration with the command:<br />
<br />
gcm-calibrate --device "''xrandr-Lenovo Group Limited''"<br />
<br />
=== LPROF ICC Profiler ===<br />
<br />
[http://lprof.sourceforge.net/ LPROF] is an ICC profiler with a graphical user interface listed under {{AUR|lprof}} in the [[AUR]]. <br />
<br />
{{Note|The following walkthrough has been modified from the ArchWiki article [[Using LPROF to profile monitors]].}}<br />
<br />
==== Monitor calibration ====<br />
<br />
===== Contrast/Brightness =====<br />
<br />
Adjust the lighting in the room to what you will be using when working. Even if your screen is coated with an anti-reflective coating, you should avoid light falling directly on it. Let your monitor warm up for at least an hour for the image to get stabilized. If your calibration device has an ambient diffuser, adjust your room brightness to reach the recommended target lux point.<br />
<br />
# Set the monitor contrast to maximum, or 100%. <br />
# Next, display a pure black over entire screen by creating a small, black PNG image (all pixels have RGB = 0, 0, 0) and opening it up in a picture viewer that is capable of displaying an image in fullscreen mode without any controls.<br />
# Reduce the vertical size of the monitor screen (not the PNG image displayed by a picture viewer but the whole of what's displayed on the screen) to 60% to 70% of the full height. What is revealed above and below the picture is called a ''non-scanned area'', and since that area is not receiving any voltage, it is the blackest of black your monitor is capable of displaying. <br />
# Locate the brightness control (usually a sun, circle with rays projecting from it's edges) and lower the value until the black ''image'' matches the non-scanned area.<br />
<br />
===== Color temperature =====<br />
<br />
As we said in the introduction, setting color temperature must occur at noon. If you only have fixed factory default color temperature, you do not really need to wait for the sunny day to come. Just set it to 6500K.<br />
<br />
Place your monitor so that you can see outside the window ''and'' your screen at the same time. For this step, you also need to create a white square image (RGB = 255, 255, 255), roughly 10 by 10 centimeters (4 by 3 inches). Using the same Gwenview technique as with brightness/contrast, display the white square on a pure black background.<br />
<br />
# First, prepare your eyes by staring at the outside world for a while. Let them adjust to the daylight viewing condition for a few minutes.<br />
# Glance at the monitor, and the white square for a few second (it has to be short, because eyes will readjust quickly).<br />
# If the square seems yellowish, you need higher color temperature, or if it has a blueish cast, the temperature needs to be lowered.<br />
# Keep glancing, looking out the window, and adjusting the white temperature, until the square looks pure white<br />
<br />
Take your time with the steps described above. It is essential to get it right.<br />
<br />
==== Monitor profiling without additional calibration hardware ====<br />
<br />
Start lprof. You will be presented by a fairly large window with multiple tabs on the right. <br />
<br />
# Click on the ''Monitor Profiler'' tab. Then click on the large ''Enter monitor values >>'' button.<br />
# White point should be set to ''6500K (daylight)''.<br />
# Primaries should be set to either ''SMPTE RP145-1994'', or ''EBU Tech.3213-E'' or ''P22'', or whatever appropriate values for your monitor. If you come across correct values for your monitor, enter those by selecting ''User Defined'' from the drop-down. If in doubt, you may use ''P22'' for all monitors with Trinitron CRTs (in this case, ''Trinitron'' is not related to Sony Trinitron mointors and TVs), and ''SMPTE RP145-1994'' for other CRTs.<br />
# Click the ''Set Gamma and Black Point'' button.<br />
# You will now see a full-screen view of two charts with some controls at the bottom.<br />
# Uncheck the ''Link channels'' check-box and adjust individual Red, Green, and Blue gamma by either moving the slider left or right, or by entering and changing values in the three boxes to the left. The goal is to make the chart on the left (the smaller square one) flat. When you are satisfied with how it looks, check the ''Link channels'' check-box and adjust the gamma again.<br />
# When you are done, click ''OK''. Click ''OK'' again.<br />
<br />
When you are finished entering monitor values, you might want to enter some information about the monitor. This is not mandatory, but it is always nice to know what profile is for what.<br />
<br />
# Click ''Profile identification'' button.<br />
# Fill in the data.<br />
# Click ''OK'' to finish.<br />
<br />
After you are all done, click on the '...' button next to ''Output Profile File'' box. Enter the name of your profile: ''somemonitor.icc''. Click ''Create Profile'' button, and you are done.<br />
<br />
=== ThinkPads ===<br />
<br />
See [http://www.thinkwiki.org/wiki/Colour_profile color profiles] for IBM/Lenovo [[Wikipedia:ThinkPad|ThinkPad]] notebook [http://www-307.ibm.com/pc/support/site.wss/migr-62923.html monitor profile] ([http://www-307.ibm.com/pc/support/site.wss/migr-44320.html generic]) support.<br />
<br />
== Loading ICC profiles ==<br />
<br />
ICC profiles are loaded either by the session daemon or by a dedicated ICC loader. Both Gnome and KDE have daemons capable of loading ICC profiles from {{pkg|colord}}. If you use colord in combination with either {{pkg|gnome-settings-daemon}} or {{Pkg|colord-kde}}, the profile will be loaded automatically. If you're not using neither Gnome nor KDE, you may install an independent daemon, [https://github.com/agalakhov/xiccd xiccd], which does the same but does not depend on your desktop environment. Do not start two ICC-capable daemons (e.g. gnome-settings-daemon and xiccd) at the same time.<br />
<br />
If you're not using any ICC-capable session daemon, make sure you use only one ICC loader - either xcalib, dispwin, dispcalGUI-apply-profiles or others, otherwise you easily end up with uncontrolled environment. (The most recently run loader set the calibration, and the earlier loaded calibration is overwritten.)<br />
<br />
Before using a particular ICC loader, you should understand that some tools set only the calibration curves (e.g. xcalib), other tools set only the display profile to X.org _ICC_PROFILE atom (e.g. xicc) and other tools do both tasks at once (e.g. dispwin, dispcalGUI-apply-profiles).<br />
<br />
=== xcalib ===<br />
<br />
* [http://xcalib.sourceforge.net/ xcalib] is a lightweight monitor calibration loader which can load an ICC monitor profile to be shared across desktop applications. {{AUR|xcalib}} is part of the Arch User Repository (AUR).<br />
<br />
==== Xinitrc example ====<br />
<br />
Load profile {{ic|P221W-sRGB.icc}} in {{Ic|/usr/share/color/icc}} on display host:0 when X server starts<br />
<pre>#!/bin/bash<br />
<br />
/usr/bin/xcalib -d :0 /usr/share/color/icc/P221W-sRGB.icc</pre><br />
<br />
==== JWM {{ic|<StartupCommand>}} example ====<br />
<br />
Load profile {{ic|P221W-Native.icc}} in {{Ic|/usr/local/share/color/icc}} on display host:0 when JWM starts<br />
{{ic|<StartupCommand>}}xcalib -d :0 /usr/local/share/color/icc/P221W-Native.icc{{ic|</StartupCommand>}}<br />
<br />
=== dispwin ===<br />
* [http://www.argyllcms.com/doc/dispwin.html dispwin] is a part of {{Pkg|argyllcms}}.<br />
<br />
==== Xinitrc example ====<br />
<br />
Load profile {{ic|906w-6500K.icc}} in {{Ic|/home/arch/.color/icc}} on display 0 when X server starts<br />
<pre>#!/bin/bash<br />
<br />
/usr/bin/dispwin -d0 /home/arch/.color/icc/906w-6500K.icc</pre><br />
<br />
==== JWM {{ic|<StartupCommand>}} example ====<br />
<br />
Load Argyll calibration file {{ic|906w-7000K.cal}} in {{Ic|/usr/local/share/color/icc}} on display 1 when JWM starts<br />
{{ic|<StartupCommand>}}dispwin -d1 /usr/local/share/color/icc/906w-7000K.cal{{ic|</StartupCommand>}}<br />
<br />
You can easily use one of these loaders to apply the color profile in early boot stage when starting a display manager, e.g. using [https://wiki.ubuntu.com/LightDM#Adding_System_Hooks LightDM startup script]. This allows to load a single icc profile file. This won't work with loading several profile files when using a multi monitopr setup.<br />
<br />
== Applications that support ICC profiles ==<br />
<br />
* [http://www.xsane.org/doc/sane-xsane-color-management-doc.html Xsane] can use ICC profiles for color-corrected scanning.<br />
* [[CUPS]] can use ICC profiles for color-corrected printing using [https://www.freedesktop.org/software/colord/faq.html#cups Colord], but the actual implementation and usability is [https://lists.cups.org/pipermail/cups/2016-December/056399.html unclear].<br />
* [[GIMP]] can use ICC profiles for display of the image being edited. The use of the installed ICC profile has to be explicitly enabled in the settings dialog, though.<br />
* [[mpv]] can take an ICC profile into account when playing a video. The command line argument is: <code>--icc-profile=/path/to/profile.icc</code> or <code>--icc-profile-auto</code>. Only <code>--vo=opengl</code> does color management; other VO drivers will silently ignore the ICC profile options.<br />
* [[Firefox]], by default, uses the system-wide ICC profile only when displaying images that are already tagged with an ICC profile. To assume that untagged images use sRGB and apply color correction also to them, set the {{ic|gfx.color_management.mode}} preference to 1.<br />
* Both [https://www.archlinux.org/packages/?name=eog Eye of Gnome] and [https://www.archlinux.org/packages/?name=eom Eye of MATE] automatically use the system-installed ICC profile.<br />
<br />
== See also ==<br />
<br />
* [[Using LPROF to profile monitors]] - Additional details on how to profile monitors<br />
* [[Wikipedia:Linux color management]]<br />
* [http://www.argyllcms.com/ Argyll Color Management System] - Official Site<br />
* [http://lprof.sourceforge.net/help/lprof-help.html LPROF Main Help Window] - Details on profiling printers and scanners<br />
* [http://displaycal.net/#concept DisplayCal: Basic concept of display calibration and profiling]<br />
* [https://encrypted.pcode.nl/blog/2013/11/24/display-color-profiling-on-linux/ Display color profiling on Linux (XFCE)]<br />
* [https://linuxtidbits.wordpress.com/2013/04/20/handling-display-calibration/ Monitor Hardware Calibration]</div>Ernetashttps://wiki.archlinux.org/index.php?title=Fan_speed_control&diff=342812Fan speed control2014-11-01T23:06:08Z<p>Ernetas: </p>
<hr />
<div>[[Category:CPU]]<br />
[[it:Fan Speed Control]]<br />
[[ru:Fan Speed Control]]<br />
{{Related articles start}}<br />
{{Related|Lm_sensors}}<br />
{{Related articles end}}<br />
Fancontrol, part of {{Pkg|lm_sensors}}, can be used to control the speed and sound of CPU/case fans. This article covers configuration/setup of the utility.<br />
<br />
== Sensor driver ==<br />
<br />
Support for newer motherboards may not yet be in the Linux kernel. Check the official [http://www.lm-sensors.org/wiki/Devices lm-sensors devices] table to see if experimental drivers are available for such motherboards.<br />
<br />
It is recommended not to use lm_sensors.service to load the needed modules for fancontrol. Instead, manually place them in {{ic|/etc/modules-load.d/load_these.conf}} since the order in which these modules are loaded dictate the order in which the needed symlinks for hwmon get created. In other words, using the lm_sensors.service causes inconsistencies boot-to-boot which will render the configuration file for fan control worthless for a consistency point of view.<br />
<br />
For more, see this thread: https://bbs.archlinux.org/viewtopic.php?pid=1251766<br />
<br />
=== lm-sensors ===<br />
<br />
Set up [[lm_sensors]].<br />
<br />
{{hc|$ sensors|2=<br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0: +29.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
[...]<br />
<br />
it8718-isa-0290<br />
Adapter: ISA adapter<br />
Vcc: +1.14 V (min = +0.00 V, max = +4.08 V) <br />
VTT: +2.08 V (min = +0.00 V, max = +4.08 V) <br />
+3.3V: +3.33 V (min = +0.00 V, max = +4.08 V) <br />
NB Vcore: +0.03 V (min = +0.00 V, max = +4.08 V) <br />
VDRAM: +2.13 V (min = +0.00 V, max = +4.08 V) <br />
fan1: 690 RPM (min = 10 RPM)<br />
temp1: +37.5°C (low = +129.5°C, high = +129.5°C) sensor = thermistor<br />
temp2: +25.0°C (low = +127.0°C, high = +127.0°C) sensor = thermal diode<br />
}}<br />
<br />
If the output does not display an RPM value for the CPU fan, one may need to increase the fan divisor. If fan speed is shown and higher than 0, skip the next step.<br />
<br />
==== Increasing fan_div ====<br />
<br />
The first line of the sensors output is the chipset used by the motherboard for readings of temperatures and voltages. <br />
<br />
Edit {{ic|/etc/sensors3.conf}} and look up the exact chipset. A few chipset names are similar, so make sure the one to edit is correct. Add the line {{ic|set fanX_div 4}} near the start of the chipset config, replacing X with the number of CPU fans in the target system.<br />
<br />
Save the file, and run as root:<br />
# sensors -s<br />
<br />
which will reload the {{ic|sensors3.conf}} file's set variables.<br />
Run {{ic|sensors}} again, and check if there is an RPM readout. If not, increase the divisor to 8, 16, or 32. YMMV!<br />
<br />
== Configuration ==<br />
<br />
{{Note|Advanced users may want to skip this section and write {{ic|/etc/fancontrol}} on their own, which also saves them from hearing all of the fans at full speed.}}<br />
<br />
Once sensors is properly configured, run {{Ic|pwmconfig}} to test and configure speed control. Follow the instructions in {{Ic|pwmconfig}} to set up basic speeds. The default configuration options should create a new file, {{ic|/etc/fancontrol}}.<br />
<br />
=== Tweaking ===<br />
<br />
{{Warning|Some of the steps outlined below describe how to tweak fan speeds. Before doing this be sure to have a low CPU load.}}<br />
<br />
{{Note|On several systems, the included script may report errors as it trys to calibrate fans to the respective PWM. Users may safely ignore these errors. The problem is that the script does not wait long enough before ramping up or down the PWM.}}<br />
<br />
Users wishing more more control may need to tweak the generated configuration. Here is a sample configuration file:<br />
INTERVAL=10<br />
DEVPATH=hwmon0=devices/platform/coretemp.0 hwmon2=devices/platform/w83627ehf.656<br />
DEVNAME=hwmon0=coretemp hwmon2=w83627dhg<br />
FCTEMPS=hwmon0/device/pwm1=hwmon0/device/temp1_input<br />
FCFANS= hwmon0/device/pwm1=hwmon0/device/fan1_input<br />
MINTEMP=hwmon0/device/pwm1=20<br />
MAXTEMP=hwmon0/device/pwm1=55<br />
MINSTART=hwmon0/device/pwm1=150<br />
MINSTOP=hwmon0/device/pwm1=105<br />
<br />
* {{ic|INTERVAL}}: how often the daemon should poll CPU temps and adjust fan speeds. INTERVAL is in seconds.<br />
<br />
The rest of the configuration file is split into (at least) two values per configuration option. Each configuration option first points to a PWM device which is written to which sets the fan speed. The second "field" is the actual value to set. This allows monitoring and controlling multiple fans and temperatures.<br />
<br />
* {{ic|FCTEMPS}}: The temperature input device to read for CPU temperature. The above example corresponds to {{ic|/sys/class/hwmon/hwmon0/device/temp1_input}}.<br />
* {{ic|FCFANS}}: The current fan speed, which can be read (like the temperature) in {{ic|/sys/class/hwmon/hwmon0/device/fan1_input}}<br />
* {{ic|MINTEMP}}: The temperature (&deg;C) at which to '''SHUT OFF''' the CPU fan. Efficient CPUs often will not need a fan while idling. Be sure to set this to a temperature that ''you know is safe''. Setting this to 0 is not recommended and may ruin your hardware!<br />
* {{ic|MAXTEMP}}: The temperature (&deg;C) at which to spin the fan at its ''MAXIMUM'' speed. This should be probably be set to perhaps 10 or 20 degrees (&deg;C) below your CPU's critical/shutdown temperature. Setting it closer to MINTEMP will result in higher fan speeds overall.<br />
* {{ic|MINSTOP}}: The PWM value at which your fan stops spinning. Each fan is a little different. Power tweakers can {{ic|echo}} different values (between 0 and 255) to {{ic|/sys/class/hwmon/hwmon0/device/pwm1}} and then watch the CPU fan. When the CPU fan stops, use this value.<br />
* {{ic|MINSTART}}: The PWM value at which your fan starts to spin again. This is often a higher value than MINSTOP as more voltage is required to overcome inertia.<br />
<br />
There are also two settings fancontrol needs to verify the configuration file is still up to date. The lines start with the setting name and a equality sign, followed by groups of hwmon-class-device=setting, seperated by spaces. You need to specify each setting for each hwmon class device you use anywhere in the config, or fancontrol will not work.<br />
<br />
* {{ic|DEVPATH}}: Sets the physical device. You can determine this by executing the command<br />
readlink -f /sys/class/hwmon/''hwmon-device''/device | sed -e 's/^\/sys\///'<br />
* {{ic|DEVNAME}}: Sets the name of the device. Try:<br />
$ sed -e 's/[[:space:]=]/_/g' /sys/class/hwmon/''hwmon-device''/device/name<br />
<br />
{{Tip|Use {{ic|MAXPWM}} and {{ic|MINPWM}} options that limit fan speed range. See fancontrol manual page for details.}}<br />
{{Tip|Not only the {{ic|DEVPATH}} may change on reboot due to different timing of module loading, but also e.g. the temperature sensor paths (hwmon0/device/temp1_input becomes hwmon0/temp1_input). This usually happens on a kernel update. Check the system log to find out which is the troublemaker:<br />
# systemctl status fancontrol.service<br />
and correct your config file accordingly.}}<br />
<br />
== fancontrol ==<br />
<br />
Try to run fancontrol:<br />
# /usr/bin/fancontrol<br />
<br />
A properly configured setup will not error out and will take control of system fans. Users should hear system fans slowing shortly after executing this command.<br />
<br />
{{Note|For Dell Latitude/Inspiron laptops, {{Pkg|i8kutils}} is available. The {{ic|i8k}} kernel module is known to have issues on several models.}}<br />
<br />
To make fancontrol start automatically on every boot as a [[systemd|service]] enable it.<br />
<br />
For the i8kmon service to be capable of controlling the fan, the "auto" config option needs to be set to 1 in /etc/i8kutils/i8kmon.conf</div>Ernetashttps://wiki.archlinux.org/index.php?title=DeveloperWiki_talk:NewMirrors&diff=290792DeveloperWiki talk:NewMirrors2013-12-29T14:10:38Z<p>Ernetas: </p>
<hr />
<div>* someone could please add description about the storage requirement of a archlinux mirror? --[[User:Rae|Rae]] 10:46, 28 June 2010 (EDT)<br />
* added --[[User:Romashka|Romashka]]<br />
* i believe we should have an reference script here (maybe the links?) Pierre has some scripts but there's no explanation about them. -- [[User:T-u-N-i-X|tunix]]<br />
* Storage size for the repos is out of date. as of NOV 20, 2011: community->31G, core->460M, extra->11G, multilib->229M. others may need updating too.-- [[User:Surlyjake|surlyjake]]<br />
* How much traffic should one expect from syncing alone? [[User:Ernestas|ernetas]]</div>Ernetashttps://wiki.archlinux.org/index.php?title=Automatic_login_to_virtual_console&diff=233001Automatic login to virtual console2012-11-01T13:22:13Z<p>Ernetas: </p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Security]]<br />
[[es:Automatic login to virtual console]]<br />
[[it:Automatic login to virtual console]]<br />
{{Article summary start}}<br />
{{Article summary text|Describes how to automatically log in to a virtual console.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary wiki|Start X at Login}}<br />
{{Article summary end}}<br />
<br />
This article describes how to automatically log in to a ''virtual console'' at the end of the [[boot process]]. This article only covers console log-ins; methods for starting an [[Xorg|X server]] are described in [[Start X at Login]].<br />
<br />
== Service ==<br />
Create a new service file similar to {{ic|getty@.service}} by copying it to {{ic|/etc/systemd/system/}}:<br />
<br />
# cp /usr/lib/systemd/system/getty\@.service /etc/systemd/system/autologin\@.service<br />
<br />
{{Note|{{ic|/etc/systemd/system/}} takes precedence over {{ic|/usr/lib/systemd/system/}}.}}<br />
<br />
Once created you can link the new {{ic|autologin@.service}} to your chosen tty, e.g. {{ic|tty1}}, {{ic|tty2}}, [...] {{ic|tty8}}, etc., by specifying it as an alias in the {{ic|[Install]}} section of the unit file. Accordingly, change the value of {{ic|ExecStart}} in {{ic|autologin@.service}}:<br />
<br />
{{hc|/etc/systemd/system/autologin@.service|<br />
2=[Service]<br />
[...]<br />
ExecStart&#61;-/sbin/agetty --noclear -a ''USERNAME'' %I 38400<br />
[...]<br />
[Install]<br />
Alias=getty.target.wants/getty@''tty1''.service<br />
}}<br />
{{Tip|It is possible to change {{ic|1=Type=idle}} to {{ic|1=Type=simple}} and avoid delaying the execution of agetty until all jobs (state change requests to units) are completed. This option is more useful when [[Start X at Login|starting X automatically]]. See {{ic|man systemd.service}} for more info. {{Note|{{ic|1=Type=simple}} can cause systemd boot-up messages to pollute the login prompt.}}}}<br />
<br />
Finally, you need to disable the old getty@.service for the specified tty and enable the new autologin@.service for the same tty:<br />
# systemctl daemon-reload<br />
# systemctl disable getty@tty1<br />
# systemctl enable autologin@tty1<br />
# systemctl start autologin@tty1<br />
<br />
{{Warning|If you are currently in an X session on the same tty configured in the service file, starting autologin@tty''X''.service will kill your X server.}}<br />
<br />
To avoid errors related to display-manager.service in dmesg, you should set the default target to multi-user instead of graphical:<br />
# systemctl enable multi-user.target<br />
(See also: [[Systemd#Change_default_target_to_boot_into|Change default runlevel/target to boot into]].)</div>Ernetashttps://wiki.archlinux.org/index.php?title=Automatic_login_to_virtual_console&diff=233000Automatic login to virtual console2012-11-01T13:18:11Z<p>Ernetas: /* Service */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Security]]<br />
[[es:Automatic login to virtual console]]<br />
[[it:Automatic login to virtual console]]<br />
{{Article summary start}}<br />
{{Article summary text|Describes how to automatically log in to a virtual console.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary wiki|Start X at Login}}<br />
{{Article summary end}}<br />
<br />
This article describes how to automatically log in to a ''virtual console'' at the end of the [[boot process]]. This article only covers console log-ins; methods for starting an [[Xorg|X server]] are described in [[Start X at Login]].<br />
<br />
== Service ==<br />
Create a new service file similar to {{ic|getty@.service}} by copying it to {{ic|/etc/systemd/system/}}:<br />
<br />
# cp /usr/lib/systemd/system/getty\@.service /etc/systemd/system/autologin\@.service<br />
<br />
{{Note|{{ic|/etc/systemd/system/}} takes precedence over {{ic|/usr/lib/systemd/system/}}.}}<br />
<br />
Once created you can link the new {{ic|autologin@.service}} to your chosen tty, e.g. {{ic|tty1}}, {{ic|tty2}}, [...] {{ic|tty8}}, etc., by specifying it as an alias in the {{ic|[Install]}} section of the unit file. Accordingly, change the value of {{ic|ExecStart}} in {{ic|autologin@.service}}:<br />
<br />
{{hc|/etc/systemd/system/autologin@.service|<br />
2=[Service]<br />
[...]<br />
ExecStart&#61;-/sbin/agetty --noclear -a ''USERNAME'' %I 38400<br />
[...]<br />
[Install]<br />
Alias=getty.target.wants/getty@''tty1''.service<br />
}}<br />
{{Tip|It is possible to change {{ic|1=Type=idle}} to {{ic|1=Type=simple}} and avoid delaying the execution of agetty until all jobs (state change requests to units) are completed. This option is more useful when [[Start X at Login|starting X automatically]]. See {{ic|man systemd.service}} for more info. {{Note|{{ic|1=Type=simple}} can cause systemd boot-up messages to pollute the login prompt.}}}}<br />
<br />
Finally, you need to disable the old getty@.service for the specified tty and enable the new autologin@.service for the same tty:<br />
# systemctl daemon-reload<br />
# systemctl disable getty@tty1<br />
# systemctl enable autologin@tty1<br />
# systemctl start autologin@tty1<br />
<br />
{{Warning|If you are currently in an X session on the same tty configured in the service file, starting autologin@tty''X''.service will kill your X server.}}<br />
<br />
To avoid errors related to display-manager.service in dmesg, you should set the default target to multi-user instead of graphical:<br />
# systemctl enable multi-user.target<br />
(See also: [[Systemd#Change_default_runlevel.2Ftarget_to_boot_into|Change default runlevel/target to boot into]].)</div>Ernetashttps://wiki.archlinux.org/index.php?title=Talk:Udisks&diff=232997Talk:Udisks2012-11-01T12:43:07Z<p>Ernetas: </p>
<hr />
<div>Ernestas: This article should be edited as ConsoleKit was replaced by logind.</div>Ernetashttps://wiki.archlinux.org/index.php?title=Talk:Udisks&diff=232996Talk:Udisks2012-11-01T12:38:48Z<p>Ernetas: Created page with "This article should be edited as ConsoleKit was replaced by logind."</p>
<hr />
<div>This article should be edited as ConsoleKit was replaced by logind.</div>Ernetas