https://wiki.archlinux.org/api.php?action=feedcontributions&user=Schmodd&feedformat=atomArchWiki - User contributions [en]2024-03-29T14:42:29ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Systemd-networkd&diff=404870Systemd-networkd2015-10-15T16:33:04Z<p>Schmodd: layout fix</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network configuration]]<br />
[[Category:Virtualization]]<br />
[[fr:systemd-networkd]]<br />
[[ja:systemd-networkd]]<br />
[[ru:Systemd-networkd]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd-nspawn}}<br />
{{Related|Network bridge}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network managers}}<br />
{{Related articles end}}<br />
<br />
''systemd-networkd'' is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service can be especially useful to set up complex network configurations for a container managed by [[systemd-nspawn]] or for virtual machines. It also works fine on simple connections.<br />
<br />
== Basic usage ==<br />
The {{Pkg|systemd}} package is part of the default Arch installation and contains all needed files to operate a wired network. Wireless adapters can be setup by other services, such as [[wpa_supplicant]], which are covered later in this article.<br />
<br />
=== Required services and setup ===<br />
<br />
To use ''systemd-networkd'', [[start]] the following two services and [[enable]] them to run on system boot:<br />
<br />
* {{ic|systemd-networkd.service}}<br />
* {{ic|systemd-resolved.service}}<br />
<br />
For compatibility with [[resolv.conf]], delete or rename the existing file and create the following symbolic link:<br />
<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
Additionally, in order to use the local DNS stub resolver of ''systemd-resolved'' (and thus use LLMNR and DNS merging per interface), replace {{ic|dns}} with {{ic|resolve}} in {{ic|/etc/nsswitch.conf}}:<br />
<br />
hosts: files '''resolve''' myhostname<br />
<br />
{{Note| Replacing {{ic|dns}} with {{ic|resolve}} may hinder [[Steam]] connecting properly at first start.}}<br />
<br />
See {{ic|man systemd-resolved}} and {{ic|man resolved.conf}} and [https://github.com/systemd/systemd/blob/master/README#L205 Systemd README].<br />
<br />
{{Note|Systemd's {{ic|resolve}} may not search the local domain when given just the hostname, even when {{ic|1=UseDomains=yes}} or {{ic|1=Domains=[domain-list]}} is present in the appropriate {{ic|.network}} file, and that file produces the expected {{ic|search [domain-list]}} in {{ic|resolv.conf}}. If you run into this problem:<br />
* Switch to using fully-qualified domain names<br />
* Use {{ic|/etc/hosts}} to resolve hostnames<br />
* Fall back to using glibc's {{ic|dns}} instead of using systemd's {{ic|resolve}}}}<br />
<br />
=== Configuration examples ===<br />
All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network}}. For a full listing of options and processing order, see [[#Configuration files]] and the {{ic|systemd.network}} man page.<br />
<br />
Systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use {{ic|networkctl list}} to list the devices on the system.<br />
<br />
After making changes to a configuration file, reload the networkd daemon.<br />
<br />
# systemctl restart systemd-networkd <br />
<br />
{{Note|In the examples below, '''enp1s0''' is the wired adapter and '''wlp2s0''' is the wireless adapter. These names can be different on different systems.}}<br />
<br />
==== Wired adapter using DHCP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4</nowiki><br />
}}<br />
<br />
==== Wired adapter using a static IP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
Address=10.1.10.9/24<br />
Gateway=10.1.10.1</nowiki><br />
}}<br />
<br />
See the {{ic|systemd.network(5)}} man page for more network options such as specifying DNS servers and a broadcast address.<br />
<br />
==== Wireless adapter ====<br />
In order to connect to a wireless network with ''systemd-networkd'', a wireless adapter configured with another service such as [[wpa_supplicant]] is required. In this example, the corresponding systemd service file that needs to be enabled is {{ic|wpa_supplicant@wlp2s0.service}}.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a [[#Wired adapter using a static IP|wired adapter]].<br />
<br />
==== Wired and wireless adapters on the same machine ====<br />
<br />
This setup will enable a DHCP IP for both a wired and wireless connection making use of the metric directive to allow the kernel the decide on-the-fly which one to use. This way, no connection downtime is observed when the wired connection is unplugged.<br />
<br />
The kernel's route metric (same as configured with ''ip'') decides which route to use for outgoing packets, in cases when several match. This will be the case when both wireless and wired devices on the system have active connections. To break the tie, the kernel uses the metric. If one of the connections is terminated, the other automatically wins without there being a gap with nothing configured (ongoing transfers may still not deal with this nicely but that is at a different OSI layer).<br />
<br />
{{Note|The '''Metric''' option is for static routes while the '''RouteMetric''' option is for setups not using static routes.}}<br />
<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=10<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
==== IPv6 privacy extensions ====<br />
<br />
If you are using IPv6 you might also want to set the {{ic|IPv6PrivacyExtensions}} option as settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}} are not honored.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
IPv6PrivacyExtensions=true<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
<br />
== Configuration files ==<br />
<br />
Configuration files are located in {{ic|/usr/lib/systemd/network}}, the volatile runtime network directory {{ic|/run/systemd/network}} and, the local administration network directory {{ic|/etc/systemd/network}}. Files in {{ic|/etc/systemd/network}} have the highest priority.<br />
<br />
There are three types of configuration files. <br />
<br />
* '''.network''' files. They will apply a network configuration for a ''matching'' device<br />
* '''.netdev''' files. They will create a ''virtual network device'' for a ''matching'' environment<br />
* '''.link''' files. When a network device appears, [[udev]] will look for the first ''matching'' '''.link''' file<br />
<br />
They all follow the same rules: <br />
<br />
* If '''all''' conditions in the {{ic|[Match]}} section are matched, the profile will be activated<br />
* an empty {{ic|[Match]}} section means the profile will apply in any case (can be compared to the {{ic|*}} joker)<br />
* each entry is a key with the {{ic|1=NAME=VALUE}} syntax <br />
* all configuration files are collectively sorted and processed in lexical order, regardless of the directory in which they live<br />
* files with identical name replace each other<br />
<br />
{{Tip|<br />
* to override a system-supplied file in {{ic|/usr/lib/systemd/network}} in a permanent manner (i.e even after upgrade), place a file with same name in {{ic|/etc/systemd/network}} and symlink it to {{ic|/dev/null}}<br />
* the {{ic|*}} joker can be used in {{ic|VALUE}} (e.g {{ic|en*}} will match any Ethernet device)<br />
* following this [https://mailman.archlinux.org/pipermail/arch-general/2014-March/035381.html Arch-general thread], the best practice is to setup specific container network settings ''inside the container'' with '''networkd''' configuration files.<br />
}}<br />
<br />
=== network files ===<br />
<br />
These files are aimed at setting network configuration variables, especially for servers and containers.<br />
<br />
Below is a basic structure of a {{ic|''MyProfile''.network}} file:<br />
<br />
{{hc|/etc/systemd/network/''MyProfile''.network|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Network]<br />
''a vertical list of keys''<br />
<br />
[Address]<br />
''a vertical list of keys''<br />
<br />
[Route]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} the device name (e.g Br0, enp4s0)<br />
* {{ic|1=Host=}} the machine hostname<br />
* {{ic|1=Virtualization=}} check whether the system is executed in a virtualized environment or not. A {{ic|1=Virtualization=no}} key will only apply on your host machine, while {{ic|1=Virtualization=yes}} apply to any container or VM.<br />
<br />
==== [Network] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=DHCP=}} enables [[Wikipedia:Dynamic Host Configuration Protocol|DHCPv4]] and/or DHCPv6 support. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}} or {{ic|ipv6}}<br />
* {{ic|1=DNS=}} is a [[Wikipedia:Domain Name System|DNS]] server address. You can specify this option more than once<br />
* {{ic|1=Bridge=}} is the name of the bridge to add the link to<br />
* {{ic|1=IPForward=}} enables IP forwarding, performing the forwarding according to the routing table, and is required for setting up [[Internet sharing]]. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}}, {{ic|ipv6}} or {{ic|kernel}}.<br />
<br />
==== [Address] section ====<br />
Most common key in the {{ic|[Address]}} section is:<br />
<br />
* {{ic|1=Address=}} is a static '''IPv4''' or '''IPv6''' address and its prefix length, separated by a {{ic|/}} character (e.g {{ic|192.168.1.90/24}}). This option is '''mandatory''' unless DHCP is used.<br />
<br />
==== [Route] section ====<br />
Most common key in the {{ic|[Route]}} section is:<br />
<br />
* {{ic|1=Gateway=}} is the address of your machine gateway. This option is '''mandatory''' unless DHCP is used.<br />
For an exhaustive key list, please refer to {{ic|systemd.network(5)}}<br />
<br />
{{Tip|you can put the {{ic|1=Address=}} and {{ic|1=Gateway=}} keys in the {{ic|[Network]}} section as a short-hand if {{ic|1=Address=}} contains only an Address key and {{ic|1=Gateway=}} section contains only a Gateway key<br />
}}<br />
<br />
=== netdev files ===<br />
<br />
These files will create virtual network devices.<br />
<br />
Below is a basic structure of a ''Mydevice''.netdev file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.netdev|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Netdev]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=Host=}} and {{ic|1=Virtualization=}}<br />
<br />
==== [Netdev] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} is the interface name used when creating the netdev. This option is '''compulsory'''<br />
* {{ic|1=Kind=}} is the netdev kind. For example, ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. are supported. This option is '''compulsory'''<br />
<br />
For an exhaustive key list, please refer to {{ic|systemd.netdev(5)}}<br />
<br />
=== link files ===<br />
<br />
These files are an alternative to custom udev rules and will be applied by [[udev]] as the device appears.<br />
<br />
Below is a basic structure of a ''Mydevice''.link file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.link|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Link]<br />
''a vertical list of keys''<br />
}}<br />
<br />
The {{ic|[Match]}} section will determine if a given link file may be applied to a given device, when the {{ic|[Link]}} section specifies the device configuration.<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=MACAddress=}}, {{ic|1=Host=}} and {{ic|1=Virtualization=}}.<br />
<br />
{{ic|1=Type=}} is the device type (e.g. vlan)<br />
<br />
==== [Link] section ====<br />
<br />
Most common keys are:<br />
<br />
{{ic|1=MACAddressPolicy=}} is either ''persistent'' when the hardware has a persistent MAC address (as most hardware should) or ''random'' , which allows to give a random MAC address when the device appears.<br />
<br />
{{ic|1=MACAddress=}} shall be used when no {{ic|1=MACAddressPolicy=}} is specified.<br />
<br />
{{Note|the system {{ic|/usr/lib/systemd/network/99-default.link}} is generally sufficient for most of the basic cases.}}<br />
<br />
== Usage with containers ==<br />
<br />
The service is available with {{Pkg|systemd}} >= 210. You will want to [[systemd#Basic systemctl usage|enable and start]] the {{ic|systemd-networkd.service}} on the host and container.<br />
<br />
For debugging purposes, it is strongly advised to [[pacman|install]] the {{Pkg|bridge-utils}}, {{Pkg|net-tools}} and {{Pkg|iproute2}} packages.<br />
<br />
If you are using ''systemd-nspawn'', you may need to modify the {{ic|systemd-nspawn@.service}} and append boot options to the {{ic|ExecStart}} line. Please refer to {{ic|man 1 systemd-nspawn}} for an exhaustive list of options.<br />
<br />
Note that if you want to take advantage of automatic DNS configuration from DHCP, you need to enable {{ic|systemd-resolved}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}. See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
{{Style|Too many points for a tip, some of them are very similar so they could be merged.}}<br />
<br />
{{Tip|Before you start to configure your container network, it is useful to:<br />
* disable all your [[netctl]] services. This will avoid any potential conflicts with '''systemd-networkd''' and make all your configurations easier to test. Furthermore, odds are high you will end with few or even no [[netctl]] activated profiles. The {{ic|netctl list}} command will output a list of all your profiles, with the activated one being starred.<br />
* disable the {{ic|systemd-nspawn@.service}} and use the {{ic|systemd-nspawn -bnD /path_to/your_container/}} command as root to boot the container. To log off and shutdown inside the container {{ic|systemctl poweroff}} is used as root. Once the network setting meets your requirements, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-nspawn@.service}}<br />
* disable the {{ic|dhcpcd.service}} if enabled on your system, since it activates ''dhcpcd'' on '''all''' interfaces<br />
* make sure you have no [[netctl]] profiles activated in the container, and ensure that {{ic|systemd-networkd.service}} is neither enabled nor started<br />
* make sure you do not have any [[iptables]] rules which can block traffic<br />
* make sure ''packet forwarding'' is [[Internet sharing#Enable packet forwarding|enabled]] if you want to let containers access the internet<br />
* when the daemon is started the systemd {{ic|networkctl}} command displays the status of network interfaces.<br />
}}<br />
<br />
{{Note|For the set-up described below, <br />
* we will limit the output of the {{ic|ip a}} command to the concerned interfaces<br />
* we assume the ''host'' is your main OS you are booting to and the ''container'' is your guest virtual machine<br />
* all interface names and IP addresses are only examples<br />
}}<br />
<br />
=== Basic DHCP network ===<br />
<br />
This setup will enable a DHCP IP for host and container. In this case, both systems will share the same IP as they share the same interfaces.<br />
<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
Then, [[enable]] and start {{ic|systemd-networkd.service}} on your container.<br />
<br />
You can of course replace {{ic|en*}} by the full name of your ethernet device given by the output of the {{ic|ip link}} command.<br />
<br />
* on host and container:<br />
<br />
{{hc|$ ip a|<br />
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.72/24 brd 192.168.1.255 scope global enp7s0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
By default hostname received from the DHCP server will be used as the transient hostname.<br />
<br />
To change it add {{ic|1=UseHostname=false}} in section {{ic|[DHCPv4]}}<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[DHCPv4]<br />
UseHostname=false<br />
</nowiki>}}<br />
<br />
If you did not want configure a DNS in {{ic|/etc/resolv.conf}} and want to rely on DHCP for setting it up, you need to [[enable]] {{ic|systemd-resolved.service}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}<br />
<br />
# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
=== DHCP with two distinct IP ===<br />
<br />
==== Bridge interface ====<br />
<br />
Create a virtual bridge interface <br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.netdev|<nowiki><br />
[NetDev]<br />
Name=br0<br />
Kind=bridge<br />
</nowiki>}}<br />
<br />
On host and container:<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default <br />
link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Note that the interface br0 is listed but is DOWN.<br />
<br />
==== Bind ethernet to bridge ====<br />
<br />
Modify the {{ic|/etc/systemd/network/''MyDhcp''.network}} to remove the DHCP, as the bridge requires an interface to bind to with no IP, and add a key to bind this device to br0. Let us change its name to a more relevant one.<br />
<br />
{{hc|/etc/systemd/network/''MyEth''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
Bridge=br0<br />
</nowiki>}}<br />
<br />
==== Bridge network ====<br />
<br />
Create a network profile for the Bridge<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
==== Add option to boot the container ====<br />
<br />
As we want to give a separate IP for host and container, we need to ''Disconnect'' networking of the container from the host. To do this, add this option {{ic|1=--network-bridge=br0}} to your container boot command.<br />
<br />
# systemd-nspawn --network-bridge&#61;br0 -bD /path_to/my_container<br />
<br />
==== Result ====<br />
<br />
* on host<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default <br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.87/24 brd 192.168.1.255 scope global br0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
6: vb-''MyContainer'': <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000<br />
link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff<br />
inet6 fe80::d07c:97ff:fe97:3725/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip a|<br />
2: host0: <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.73/24 brd 192.168.1.255 scope global host0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5c96:85ff:fe83:a85d/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
==== Notice ====<br />
<br />
* we have now one IP address for Br0 on the host, and one for host0 in the container<br />
* two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option. This option ''implies'' another option, {{ic|--network-veth}}. This means a ''virtual Ethernet link'' has been created between host and container.<br />
* the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file.<br />
* on host<br />
<br />
{{hc|$ brctl show|<br />
bridge name bridge id STP enabled interfaces<br />
br0 8000.14dae9b57a88 no enp7s0<br />
vb-''MyContainer''<br />
}}<br />
<br />
the above command output confirms we have a bridge with two interfaces binded to.<br />
<br />
* on host<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev br0 <br />
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev host0 <br />
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.73<br />
}}<br />
<br />
the above command outputs confirm we have activated {{ic|br0}} and {{ic|host0}} interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by ''systemd-networkd''<br />
<br />
{{hc|$ cat /run/systemd/resolve/resolv.conf|<br />
nameserver 192.168.1.254<br />
}}<br />
<br />
=== Static IP network ===<br />
<br />
Setting a static IP for each device can be helpful in case of deployed web services (e.g FTP, http, SSH). Each device will keep the same MAC address across reboots if your system {{ic|/usr/lib/systemd/network/99-default.link}} file has the {{ic|1=MACAddressPolicy=persistent}} option (it has by default). Thus, you will easily route any service on your Gateway to the desired device.<br />
First, we shall get rid of the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file. To do it in a permanent way (e.g even after upgrades), do the following on container. This will mask the file {{ic|/usr/lib/systemd/network/80-container-host0.network}} since files of the same name in {{ic|/etc/systemd/network}} take priority over {{ic|/usr/lib/systemd/network}}.<br />
<br />
# ln -sf /dev/null /etc/systemd/network/80-container-host0.network<br />
<br />
Then, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-networkd}} on your container.<br />
<br />
The needed configuration files:<br />
* on host <br />
{{Accuracy|In the listing of configuration files, /etc/systemd/network/MyBridge.netdev has the .netdev extension. But, the MyBridge.network example file has the .network extension.}}<br />
<br />
/etc/systemd/network/''MyBridge''.netdev<br />
/etc/systemd/network/''MyEth''.network<br />
<br />
A modified ''MyBridge''.network<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.87/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
* on container<br />
<br />
{{hc|/etc/systemd/network/''MyVeth''.network|<nowiki><br />
[Match]<br />
Name=host0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.94/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html systemd.networkd man page]<br />
* [https://plus.google.com/u/0/+TomGundersen/posts Tom Gundersen, main systemd-networkd developer, G+ home page]<br />
* [https://coreos.com/blog/intro-to-systemd-networkd/ Tom Gundersen posts on Core OS blog]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums)</div>Schmoddhttps://wiki.archlinux.org/index.php?title=Systemd-networkd&diff=404869Systemd-networkd2015-10-15T16:31:39Z<p>Schmodd: added note that steam may not function properly if one deceides to replace dns with resolve in /etc/nsswitch.conf - i guess people should know</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Network configuration]]<br />
[[Category:Virtualization]]<br />
[[fr:systemd-networkd]]<br />
[[ja:systemd-networkd]]<br />
[[ru:Systemd-networkd]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|systemd-nspawn}}<br />
{{Related|Network bridge}}<br />
{{Related|Network configuration}}<br />
{{Related|Wireless network configuration}}<br />
{{Related|:Category:Network managers}}<br />
{{Related articles end}}<br />
<br />
''systemd-networkd'' is a system daemon that manages network configurations. It detects and configures network devices as they appear; it can also create virtual network devices. This service can be especially useful to set up complex network configurations for a container managed by [[systemd-nspawn]] or for virtual machines. It also works fine on simple connections.<br />
<br />
== Basic usage ==<br />
The {{Pkg|systemd}} package is part of the default Arch installation and contains all needed files to operate a wired network. Wireless adapters can be setup by other services, such as [[wpa_supplicant]], which are covered later in this article.<br />
<br />
=== Required services and setup ===<br />
<br />
To use ''systemd-networkd'', [[start]] the following two services and [[enable]] them to run on system boot:<br />
<br />
* {{ic|systemd-networkd.service}}<br />
* {{ic|systemd-resolved.service}}<br />
<br />
For compatibility with [[resolv.conf]], delete or rename the existing file and create the following symbolic link:<br />
<br />
# ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
Additionally, in order to use the local DNS stub resolver of ''systemd-resolved'' (and thus use LLMNR and DNS merging per interface), replace {{ic|dns}} with {{ic|resolve}} in {{ic|/etc/nsswitch.conf}}:<br />
<br />
hosts: files '''resolve''' myhostname<br />
<br />
{{Note| Replacing 'dns' with 'resolve' may hinder [[Steam]] connecting properly at first start.}}<br />
<br />
See {{ic|man systemd-resolved}} and {{ic|man resolved.conf}} and [https://github.com/systemd/systemd/blob/master/README#L205 Systemd README].<br />
<br />
{{Note|Systemd's {{ic|resolve}} may not search the local domain when given just the hostname, even when {{ic|1=UseDomains=yes}} or {{ic|1=Domains=[domain-list]}} is present in the appropriate {{ic|.network}} file, and that file produces the expected {{ic|search [domain-list]}} in {{ic|resolv.conf}}. If you run into this problem:<br />
* Switch to using fully-qualified domain names<br />
* Use {{ic|/etc/hosts}} to resolve hostnames<br />
* Fall back to using glibc's {{ic|dns}} instead of using systemd's {{ic|resolve}}}}<br />
<br />
=== Configuration examples ===<br />
All configurations in this section are stored as {{ic|foo.network}} in {{ic|/etc/systemd/network}}. For a full listing of options and processing order, see [[#Configuration files]] and the {{ic|systemd.network}} man page.<br />
<br />
Systemd/udev automatically assigns predictable, stable network interface names for all local Ethernet, WLAN, and WWAN interfaces. Use {{ic|networkctl list}} to list the devices on the system.<br />
<br />
After making changes to a configuration file, reload the networkd daemon.<br />
<br />
# systemctl restart systemd-networkd <br />
<br />
{{Note|In the examples below, '''enp1s0''' is the wired adapter and '''wlp2s0''' is the wireless adapter. These names can be different on different systems.}}<br />
<br />
==== Wired adapter using DHCP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4</nowiki><br />
}}<br />
<br />
==== Wired adapter using a static IP ====<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
Address=10.1.10.9/24<br />
Gateway=10.1.10.1</nowiki><br />
}}<br />
<br />
See the {{ic|systemd.network(5)}} man page for more network options such as specifying DNS servers and a broadcast address.<br />
<br />
==== Wireless adapter ====<br />
In order to connect to a wireless network with ''systemd-networkd'', a wireless adapter configured with another service such as [[wpa_supplicant]] is required. In this example, the corresponding systemd service file that needs to be enabled is {{ic|wpa_supplicant@wlp2s0.service}}.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
If the wireless adapter has a static IP address, the configuration is the same (except for the interface name) as in a [[#Wired adapter using a static IP|wired adapter]].<br />
<br />
==== Wired and wireless adapters on the same machine ====<br />
<br />
This setup will enable a DHCP IP for both a wired and wireless connection making use of the metric directive to allow the kernel the decide on-the-fly which one to use. This way, no connection downtime is observed when the wired connection is unplugged.<br />
<br />
The kernel's route metric (same as configured with ''ip'') decides which route to use for outgoing packets, in cases when several match. This will be the case when both wireless and wired devices on the system have active connections. To break the tie, the kernel uses the metric. If one of the connections is terminated, the other automatically wins without there being a gap with nothing configured (ongoing transfers may still not deal with this nicely but that is at a different OSI layer).<br />
<br />
{{Note|The '''Metric''' option is for static routes while the '''RouteMetric''' option is for setups not using static routes.}}<br />
<br />
{{hc|/etc/systemd/network/''wired''.network|<nowiki><br />
[Match]<br />
Name=enp1s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=10<br />
</nowiki>}}<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
==== IPv6 privacy extensions ====<br />
<br />
If you are using IPv6 you might also want to set the {{ic|IPv6PrivacyExtensions}} option as settings placed in {{ic|/etc/sysctl.d/40-ipv6.conf}} are not honored.<br />
<br />
{{hc|/etc/systemd/network/''wireless''.network|<nowiki><br />
[Match]<br />
Name=wlp2s0<br />
<br />
[Network]<br />
DHCP=yes<br />
IPv6PrivacyExtensions=true<br />
<br />
[DHCP]<br />
RouteMetric=20<br />
</nowiki>}}<br />
<br />
<br />
== Configuration files ==<br />
<br />
Configuration files are located in {{ic|/usr/lib/systemd/network}}, the volatile runtime network directory {{ic|/run/systemd/network}} and, the local administration network directory {{ic|/etc/systemd/network}}. Files in {{ic|/etc/systemd/network}} have the highest priority.<br />
<br />
There are three types of configuration files. <br />
<br />
* '''.network''' files. They will apply a network configuration for a ''matching'' device<br />
* '''.netdev''' files. They will create a ''virtual network device'' for a ''matching'' environment<br />
* '''.link''' files. When a network device appears, [[udev]] will look for the first ''matching'' '''.link''' file<br />
<br />
They all follow the same rules: <br />
<br />
* If '''all''' conditions in the {{ic|[Match]}} section are matched, the profile will be activated<br />
* an empty {{ic|[Match]}} section means the profile will apply in any case (can be compared to the {{ic|*}} joker)<br />
* each entry is a key with the {{ic|1=NAME=VALUE}} syntax <br />
* all configuration files are collectively sorted and processed in lexical order, regardless of the directory in which they live<br />
* files with identical name replace each other<br />
<br />
{{Tip|<br />
* to override a system-supplied file in {{ic|/usr/lib/systemd/network}} in a permanent manner (i.e even after upgrade), place a file with same name in {{ic|/etc/systemd/network}} and symlink it to {{ic|/dev/null}}<br />
* the {{ic|*}} joker can be used in {{ic|VALUE}} (e.g {{ic|en*}} will match any Ethernet device)<br />
* following this [https://mailman.archlinux.org/pipermail/arch-general/2014-March/035381.html Arch-general thread], the best practice is to setup specific container network settings ''inside the container'' with '''networkd''' configuration files.<br />
}}<br />
<br />
=== network files ===<br />
<br />
These files are aimed at setting network configuration variables, especially for servers and containers.<br />
<br />
Below is a basic structure of a {{ic|''MyProfile''.network}} file:<br />
<br />
{{hc|/etc/systemd/network/''MyProfile''.network|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Network]<br />
''a vertical list of keys''<br />
<br />
[Address]<br />
''a vertical list of keys''<br />
<br />
[Route]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} the device name (e.g Br0, enp4s0)<br />
* {{ic|1=Host=}} the machine hostname<br />
* {{ic|1=Virtualization=}} check whether the system is executed in a virtualized environment or not. A {{ic|1=Virtualization=no}} key will only apply on your host machine, while {{ic|1=Virtualization=yes}} apply to any container or VM.<br />
<br />
==== [Network] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=DHCP=}} enables [[Wikipedia:Dynamic Host Configuration Protocol|DHCPv4]] and/or DHCPv6 support. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}} or {{ic|ipv6}}<br />
* {{ic|1=DNS=}} is a [[Wikipedia:Domain Name System|DNS]] server address. You can specify this option more than once<br />
* {{ic|1=Bridge=}} is the name of the bridge to add the link to<br />
* {{ic|1=IPForward=}} enables IP forwarding, performing the forwarding according to the routing table, and is required for setting up [[Internet sharing]]. Accepts {{ic|yes}}, {{ic|no}}, {{ic|ipv4}}, {{ic|ipv6}} or {{ic|kernel}}.<br />
<br />
==== [Address] section ====<br />
Most common key in the {{ic|[Address]}} section is:<br />
<br />
* {{ic|1=Address=}} is a static '''IPv4''' or '''IPv6''' address and its prefix length, separated by a {{ic|/}} character (e.g {{ic|192.168.1.90/24}}). This option is '''mandatory''' unless DHCP is used.<br />
<br />
==== [Route] section ====<br />
Most common key in the {{ic|[Route]}} section is:<br />
<br />
* {{ic|1=Gateway=}} is the address of your machine gateway. This option is '''mandatory''' unless DHCP is used.<br />
For an exhaustive key list, please refer to {{ic|systemd.network(5)}}<br />
<br />
{{Tip|you can put the {{ic|1=Address=}} and {{ic|1=Gateway=}} keys in the {{ic|[Network]}} section as a short-hand if {{ic|1=Address=}} contains only an Address key and {{ic|1=Gateway=}} section contains only a Gateway key<br />
}}<br />
<br />
=== netdev files ===<br />
<br />
These files will create virtual network devices.<br />
<br />
Below is a basic structure of a ''Mydevice''.netdev file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.netdev|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Netdev]<br />
''a vertical list of keys''<br />
}}<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=Host=}} and {{ic|1=Virtualization=}}<br />
<br />
==== [Netdev] section ====<br />
<br />
Most common keys are:<br />
<br />
* {{ic|1=Name=}} is the interface name used when creating the netdev. This option is '''compulsory'''<br />
* {{ic|1=Kind=}} is the netdev kind. For example, ''bridge'', ''bond'', ''vlan'', ''veth'', ''sit'', etc. are supported. This option is '''compulsory'''<br />
<br />
For an exhaustive key list, please refer to {{ic|systemd.netdev(5)}}<br />
<br />
=== link files ===<br />
<br />
These files are an alternative to custom udev rules and will be applied by [[udev]] as the device appears.<br />
<br />
Below is a basic structure of a ''Mydevice''.link file:<br />
<br />
{{hc|/etc/systemd/network/''MyDevice''.link|<br />
[Match]<br />
''a vertical list of keys''<br />
<br />
[Link]<br />
''a vertical list of keys''<br />
}}<br />
<br />
The {{ic|[Match]}} section will determine if a given link file may be applied to a given device, when the {{ic|[Link]}} section specifies the device configuration.<br />
<br />
==== [Match] section ====<br />
<br />
Most common keys are {{ic|1=MACAddress=}}, {{ic|1=Host=}} and {{ic|1=Virtualization=}}.<br />
<br />
{{ic|1=Type=}} is the device type (e.g. vlan)<br />
<br />
==== [Link] section ====<br />
<br />
Most common keys are:<br />
<br />
{{ic|1=MACAddressPolicy=}} is either ''persistent'' when the hardware has a persistent MAC address (as most hardware should) or ''random'' , which allows to give a random MAC address when the device appears.<br />
<br />
{{ic|1=MACAddress=}} shall be used when no {{ic|1=MACAddressPolicy=}} is specified.<br />
<br />
{{Note|the system {{ic|/usr/lib/systemd/network/99-default.link}} is generally sufficient for most of the basic cases.}}<br />
<br />
== Usage with containers ==<br />
<br />
The service is available with {{Pkg|systemd}} >= 210. You will want to [[systemd#Basic systemctl usage|enable and start]] the {{ic|systemd-networkd.service}} on the host and container.<br />
<br />
For debugging purposes, it is strongly advised to [[pacman|install]] the {{Pkg|bridge-utils}}, {{Pkg|net-tools}} and {{Pkg|iproute2}} packages.<br />
<br />
If you are using ''systemd-nspawn'', you may need to modify the {{ic|systemd-nspawn@.service}} and append boot options to the {{ic|ExecStart}} line. Please refer to {{ic|man 1 systemd-nspawn}} for an exhaustive list of options.<br />
<br />
Note that if you want to take advantage of automatic DNS configuration from DHCP, you need to enable {{ic|systemd-resolved}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}. See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
{{Style|Too many points for a tip, some of them are very similar so they could be merged.}}<br />
<br />
{{Tip|Before you start to configure your container network, it is useful to:<br />
* disable all your [[netctl]] services. This will avoid any potential conflicts with '''systemd-networkd''' and make all your configurations easier to test. Furthermore, odds are high you will end with few or even no [[netctl]] activated profiles. The {{ic|netctl list}} command will output a list of all your profiles, with the activated one being starred.<br />
* disable the {{ic|systemd-nspawn@.service}} and use the {{ic|systemd-nspawn -bnD /path_to/your_container/}} command as root to boot the container. To log off and shutdown inside the container {{ic|systemctl poweroff}} is used as root. Once the network setting meets your requirements, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-nspawn@.service}}<br />
* disable the {{ic|dhcpcd.service}} if enabled on your system, since it activates ''dhcpcd'' on '''all''' interfaces<br />
* make sure you have no [[netctl]] profiles activated in the container, and ensure that {{ic|systemd-networkd.service}} is neither enabled nor started<br />
* make sure you do not have any [[iptables]] rules which can block traffic<br />
* make sure ''packet forwarding'' is [[Internet sharing#Enable packet forwarding|enabled]] if you want to let containers access the internet<br />
* when the daemon is started the systemd {{ic|networkctl}} command displays the status of network interfaces.<br />
}}<br />
<br />
{{Note|For the set-up described below, <br />
* we will limit the output of the {{ic|ip a}} command to the concerned interfaces<br />
* we assume the ''host'' is your main OS you are booting to and the ''container'' is your guest virtual machine<br />
* all interface names and IP addresses are only examples<br />
}}<br />
<br />
=== Basic DHCP network ===<br />
<br />
This setup will enable a DHCP IP for host and container. In this case, both systems will share the same IP as they share the same interfaces.<br />
<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
Then, [[enable]] and start {{ic|systemd-networkd.service}} on your container.<br />
<br />
You can of course replace {{ic|en*}} by the full name of your ethernet device given by the output of the {{ic|ip link}} command.<br />
<br />
* on host and container:<br />
<br />
{{hc|$ ip a|<br />
2: enp7s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.72/24 brd 192.168.1.255 scope global enp7s0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
By default hostname received from the DHCP server will be used as the transient hostname.<br />
<br />
To change it add {{ic|1=UseHostname=false}} in section {{ic|[DHCPv4]}}<br />
{{hc|/etc/systemd/network/''MyDhcp''.network|<nowiki><br />
[DHCPv4]<br />
UseHostname=false<br />
</nowiki>}}<br />
<br />
If you did not want configure a DNS in {{ic|/etc/resolv.conf}} and want to rely on DHCP for setting it up, you need to [[enable]] {{ic|systemd-resolved.service}} and symlink {{ic|/run/systemd/resolve/resolv.conf}} to {{ic|/etc/resolv.conf}}<br />
<br />
# ln -sf /run/systemd/resolve/resolv.conf /etc/resolv.conf<br />
<br />
See {{ic|systemd-resolved.service(8)}} for more details.<br />
<br />
=== DHCP with two distinct IP ===<br />
<br />
==== Bridge interface ====<br />
<br />
Create a virtual bridge interface <br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.netdev|<nowiki><br />
[NetDev]<br />
Name=br0<br />
Kind=bridge<br />
</nowiki>}}<br />
<br />
On host and container:<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default <br />
link/ether ae:bd:35:ea:0c:c9 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
Note that the interface br0 is listed but is DOWN.<br />
<br />
==== Bind ethernet to bridge ====<br />
<br />
Modify the {{ic|/etc/systemd/network/''MyDhcp''.network}} to remove the DHCP, as the bridge requires an interface to bind to with no IP, and add a key to bind this device to br0. Let us change its name to a more relevant one.<br />
<br />
{{hc|/etc/systemd/network/''MyEth''.network|<nowiki><br />
[Match]<br />
Name=en*<br />
<br />
[Network]<br />
Bridge=br0<br />
</nowiki>}}<br />
<br />
==== Bridge network ====<br />
<br />
Create a network profile for the Bridge<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DHCP=ipv4<br />
</nowiki>}}<br />
<br />
==== Add option to boot the container ====<br />
<br />
As we want to give a separate IP for host and container, we need to ''Disconnect'' networking of the container from the host. To do this, add this option {{ic|1=--network-bridge=br0}} to your container boot command.<br />
<br />
# systemd-nspawn --network-bridge&#61;br0 -bD /path_to/my_container<br />
<br />
==== Result ====<br />
<br />
* on host<br />
<br />
{{hc|$ ip a|<br />
3: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default <br />
link/ether 14:da:e9:b5:7a:88 brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.87/24 brd 192.168.1.255 scope global br0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::16da:e9ff:feb5:7a88/64 scope link <br />
valid_lft forever preferred_lft forever<br />
6: vb-''MyContainer'': <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master br0 state UP group default qlen 1000<br />
link/ether d2:7c:97:97:37:25 brd ff:ff:ff:ff:ff:ff<br />
inet6 fe80::d07c:97ff:fe97:3725/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip a|<br />
2: host0: <BROADCAST,MULTICAST,ALLMULTI,AUTOMEDIA,NOTRAILERS,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000<br />
link/ether 5e:96:85:83:a8:5d brd ff:ff:ff:ff:ff:ff<br />
inet 192.168.1.73/24 brd 192.168.1.255 scope global host0<br />
valid_lft forever preferred_lft forever<br />
inet6 fe80::5c96:85ff:fe83:a85d/64 scope link <br />
valid_lft forever preferred_lft forever<br />
}}<br />
<br />
==== Notice ====<br />
<br />
* we have now one IP address for Br0 on the host, and one for host0 in the container<br />
* two new interfaces have appeared: {{ic|vb-''MyContainer''}} in the host and {{ic|host0}} in the container. This comes as a result of the {{ic|1=--network-bridge=br0}} option. This option ''implies'' another option, {{ic|--network-veth}}. This means a ''virtual Ethernet link'' has been created between host and container.<br />
* the DHCP address on {{ic|host0}} comes from the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file.<br />
* on host<br />
<br />
{{hc|$ brctl show|<br />
bridge name bridge id STP enabled interfaces<br />
br0 8000.14dae9b57a88 no enp7s0<br />
vb-''MyContainer''<br />
}}<br />
<br />
the above command output confirms we have a bridge with two interfaces binded to.<br />
<br />
* on host<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev br0 <br />
192.168.1.0/24 dev br0 proto kernel scope link src 192.168.1.87<br />
}}<br />
<br />
* on container<br />
<br />
{{hc|$ ip route|<br />
default via 192.168.1.254 dev host0 <br />
192.168.1.0/24 dev host0 proto kernel scope link src 192.168.1.73<br />
}}<br />
<br />
the above command outputs confirm we have activated {{ic|br0}} and {{ic|host0}} interfaces with an IP address and Gateway 192.168.1.254. The gateway address has been automatically grabbed by ''systemd-networkd''<br />
<br />
{{hc|$ cat /run/systemd/resolve/resolv.conf|<br />
nameserver 192.168.1.254<br />
}}<br />
<br />
=== Static IP network ===<br />
<br />
Setting a static IP for each device can be helpful in case of deployed web services (e.g FTP, http, SSH). Each device will keep the same MAC address across reboots if your system {{ic|/usr/lib/systemd/network/99-default.link}} file has the {{ic|1=MACAddressPolicy=persistent}} option (it has by default). Thus, you will easily route any service on your Gateway to the desired device.<br />
First, we shall get rid of the system {{ic|/usr/lib/systemd/network/80-container-host0.network}} file. To do it in a permanent way (e.g even after upgrades), do the following on container. This will mask the file {{ic|/usr/lib/systemd/network/80-container-host0.network}} since files of the same name in {{ic|/etc/systemd/network}} take priority over {{ic|/usr/lib/systemd/network}}.<br />
<br />
# ln -sf /dev/null /etc/systemd/network/80-container-host0.network<br />
<br />
Then, [[systemd#Basic systemctl usage|enable and start]] {{ic|systemd-networkd}} on your container.<br />
<br />
The needed configuration files:<br />
* on host <br />
{{Accuracy|In the listing of configuration files, /etc/systemd/network/MyBridge.netdev has the .netdev extension. But, the MyBridge.network example file has the .network extension.}}<br />
<br />
/etc/systemd/network/''MyBridge''.netdev<br />
/etc/systemd/network/''MyEth''.network<br />
<br />
A modified ''MyBridge''.network<br />
<br />
{{hc|/etc/systemd/network/''MyBridge''.network|<nowiki><br />
[Match]<br />
Name=br0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.87/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
* on container<br />
<br />
{{hc|/etc/systemd/network/''MyVeth''.network|<nowiki><br />
[Match]<br />
Name=host0<br />
<br />
[Network]<br />
DNS=192.168.1.254<br />
Address=192.168.1.94/24<br />
Gateway=192.168.1.254<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://www.freedesktop.org/software/systemd/man/systemd-networkd.service.html systemd.networkd man page]<br />
* [https://plus.google.com/u/0/+TomGundersen/posts Tom Gundersen, main systemd-networkd developer, G+ home page]<br />
* [https://coreos.com/blog/intro-to-systemd-networkd/ Tom Gundersen posts on Core OS blog]<br />
* [https://bbs.archlinux.org/viewtopic.php?pid=1393759#p1393759 How to set up systemd-networkd with wpa_supplicant] (WonderWoofy's walkthrough on Arch forums)</div>Schmoddhttps://wiki.archlinux.org/index.php?title=Thunar&diff=350145Thunar2014-12-15T15:23:13Z<p>Schmodd: /* Using Thunar to browse remote locations */ added dbus execution for enabling thunar remote location browsing</p>
<hr />
<div>[[Category:File managers]]<br />
[[ar:Thunar]]<br />
[[es:Thunar]]<br />
[[fr:Thunar]]<br />
[[it:Thunar]]<br />
[[ja:Thunar]]<br />
[[pl:Thunar]]<br />
[[ru:Thunar]]<br />
[[zh-CN:Thunar]]<br />
{{Related articles start}}<br />
{{Related|Xfce}}<br />
{{Related|File manager functionality}}<br />
{{Related|GNOME Files}}<br />
{{Related|PCManFM}}<br />
{{Related|Nemo}}<br />
{{Related articles end}}<br />
<br />
From the project [http://docs.xfce.org/xfce/thunar/start home page]:<br />
: ''Thunar is a new modern file manager for the Xfce Desktop Environment. Thunar has been designed from the ground up to be fast and easy-to-use. Its user interface is clean and intuitive, and does not include any confusing or useless options by default. Thunar is fast and responsive with a good start up time and folder load time.''<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|thunar}} package which is available in the [[official repositories]]. It is part of the {{Grp|xfce4}} group, so if you are running [[Xfce4]], you probably already have Thunar installed.<br />
<br />
=== Automounting ===<br />
<br />
Thunar uses [[GVFS]] for automounting. See also [[File manager functionality]] for more details.<br />
<br />
=== Plugins and addons ===<br />
<br />
* {{App|Thunar Archive Plugin|Plugin which allows you to create and extract archive files using contextual menu items. It does not create or extract archives directly, but instead acts as a frontend for other programs such as File Roller ({{Pkg|file-roller}}), Ark ({{Pkg|kdeutils-ark}}) or Xarchiver ({{Pkg|xarchiver}}). Part of {{Grp|xfce4-goodies}}.|http://goodies.xfce.org/projects/thunar-plugins/thunar-archive-plugin|{{Pkg|thunar-archive-plugin}}}}<br />
* {{App|Thunar Media Tags Plugin|Plugin which allows you to view detailed information about media files. It also has a bulk renamed and allows editing of media tags. It supports ID3 (the MP3 file format's system) and Ogg/Vorbis tags. Part of {{Grp|xfce4-goodies}}.|http://goodies.xfce.org/projects/thunar-plugins/thunar-media-tags-plugin|{{Pkg|thunar-media-tags-plugin}}}}<br />
* {{App|Thunar Shares Plugin|Plugin which allows you to quickly share a folder using Samba from Thunar without requiring root access. See also [[Samba#Creating user share path|how to configure directions]].|http://goodies.xfce.org/projects/thunar-plugins/thunar-shares-plugin|{{AUR|thunar-shares-plugin}}}}<br />
* {{App|[[Thunar#Thunar Volume Manager|Thunar Volume Manager]]|Automatic management of removeable devices in Thunar. Part of {{Grp|xfce4}}.|http://goodies.xfce.org/projects/thunar-plugins/thunar-volman|{{Pkg|thunar-volman}}}}<br />
* {{App|Tumbler|External program to generate thumbnails. Also install {{Pkg|ffmpegthumbnailer}} to enable video thumbnailing.|http://git.xfce.org/xfce/tumbler/tree/README|{{Pkg|tumbler}}}}<br />
* {{App|RAW Thumbnailer|A lightweight and fast raw image thumbnailer that is needed to displane raw thumbnails.|https://code.google.com/p/raw-thumbnailer/|{{Pkg|raw-thumbnailer}}}}<br />
* {{App|libgsf|The GNOME Structured File Library is a utility library for reading and writing structured file formats. Install if you need support for odf thumbnails|http://directory.fsf.org/wiki/Libgsf|{{Pkg|libgsf}}}}<br />
<br />
== Thunar Volume Manager ==<br />
<br />
While Thunar can support automatic mounting and unmounting of removable media, the Thunar Volume Manager allows extended functionality, such as automatically running commands or automatically opening a Thunar window for mounted media.<br />
<br />
=== Installation ===<br />
<br />
Thunar Volume Manager can be installed from the package {{Pkg|thunar-volman}} in the official repositories.<br />
<br />
=== Configuration ===<br />
<br />
It can also be configured to execute certain actions when cameras and audio players are connected. <br />
After installing the plugin:<br />
# Launch Thunar and go to ''Edit > Preferences''<br />
# Under the 'Advanced' tab, check 'Enable Volume Management'<br />
# Click configure and check the following items:<br />
#* Mount removable drives when hot-plugged.<br />
#* Mount removable media when inserted.<br />
# Also make desired changes (see the example below)<br />
Here's an example setting for making Amarok play an audio CD.<br />
Multimedia - Audio CDs: {{ic|amarok --cdplay %d}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Automounting of large external drives ===<br />
If Thunar refuses to mount large removable media (size > 1TB) although thunar-volman and gvfs has been installed, then try installing a different automounter such as {{Pkg|udevil}} or {{Pkg|udiskie}}. The latter should be preferred as it uses udisks2 and thus is compatible with gvfs. To start udiskie with udisks2 support, add the following line to your autostart file:<br />
<br />
udiskie -2 &<br />
<br />
=== Using Thunar to browse remote locations ===<br />
<br />
Since Xfce 4.8 (Thunar 1.2) it is possible to browse remote locations (such as FTP servers or Samba shares) directly in Thunar. To enable this functionality ensure that {{Pkg|gvfs}}, {{Pkg|gvfs-smb}} and {{Pkg|sshfs}} packages are installed and dbus is being executed (e.g. use 'exec dbus-launch' in .xinitrc). A 'Network' entry is visible in Thunar's side bar and remote locations can be opened by using the following URI schemes in the location dialog (opened with {{ic|Ctrl+l}}): smb://, <nowiki>ftp://</nowiki>, ssh://, sftp:// & followed by the server hostname or IP address.<br />
<br />
There is no URI scheme for [[NFS]] shares, but Thunar can issue a {{ic|mount}} command if you setup your [[fstab]] properly.<br />
{{hc|/etc/fstab|<br />
# nas1 server<br />
nas1:/c/home /media/nas1/home nfs noauto,user,_netdev,bg 0 0}}<br />
<br />
What's important here is the {{ic|noauto}} which prevents the share from being mounted until you click on it, {{ic|user}} which allows any user to mount (and unmount) the share, {{ic|_netdev}} which makes network connectivity a pre-requisite, and finally {{ic|bg}} which puts the mounting operation the background so if your server requires some spin-up time you won't have to deal with time out messages and re-clicking until it works.<br />
<br />
{{Tip|If you want to permanently store passphrases of remote filesystem locations, you have to install [[GNOME Keyring]].}}<br />
<br />
=== Starting in daemon mode ===<br />
<br />
Thunar may be run in daemon mode. This has several advantages, including a faster startup for Thunar, as well as Thunar running in the background and only opening a window when necessary (for instance, when a flash drive is inserted).<br />
<br />
Make sure the command {{ic|thunar --daemon}} is autostarted on login. See [[Xfce]] and [[Autostarting]] for more details.<br />
<br />
=== Solving problem with slow cold start ===<br />
<br />
Some people still have problems with Thunar taking a long time to start for the first time. This is due to gvfs checking the network, preventing Thunar from starting until gvfs finishes its operations. To change this behaviour, edit {{ic|/usr/share/gvfs/mounts/network.mount}} and change '''AutoMount=true''' to '''AutoMount=false'''.<br />
<br />
=== Hide Shortcuts in Side Pane ===<br />
<br />
There is a hidden menu to hide Shortcuts in the Side Pane.<br />
<br />
Right click in the Side Pane where there are no shortcuts, like on the DEVICES section label. Then you will get a pop-up menu where you can uncheck items you do not want displayed.<br />
<br />
=== Assign keyboard shortcuts in Thunar ===<br />
<br />
There is a way to assign a shortcut to the commands with whatever key you like, in fact, menu option which is listed in the menubar in Thunar can be assigned with shortcuts of your liking. But unfortunately options from plugins (like the Thunar Archive Plugin) can't be assigned via shortcuts.<br />
<br />
xfconf-query -c xsettings -p /Gtk/CanChangeAccels -T<br />
<br />
After this step, open Thunar and search for in example the "Open Terminal Here" menu option, hover with the mouse over this entry and just press your favourite keyboard shortcut. For many (not all) of you, {{ic|F4}} is the right option. To delete a key assignment, press the Backspace key.<br />
<br />
Done, now you can open the terminal simply by pressing the shortcut you defined inside Thunar!<br />
<br />
=== Showing partitions defined in fstab ===<br />
<br />
By default Thunar will not show in devices any partitions defined in {{ic|/etc/fstab}} besides the root partition.<br />
<br />
We can change that by adding the option '''comment=x-gvfs-show''' to fstab for the partition we wish to show.<br />
<br />
== Custom actions ==<br />
<br />
This section covers useful custom actions which can be accessed through {{ic|Edit -> Configure custom actions}} and which are stored in {{ic|~/.config/Thunar/uca.xml}}. More examples are listed in the [http://docs.xfce.org/xfce/thunar/custom-actions thunar wiki]. Furthermore, [http://duncanlock.net/blog/2013/06/28/useful-thunar-custom-actions/ this] blog post provides a comprehensive collection of custom actions.<br />
<br />
=== Search for files and folders ===<br />
<br />
To use this action you need to have {{Pkg|catfish}} installed.<br />
<br />
{| class="wikitable"<br />
! Name !! Command !! File patterns !! Appears if selection contains<br />
|-<br />
! Search<br />
| {{ic|1=catfish --path=%f}} || * || Directories<br />
|}<br />
<br />
=== Scan for viruses ===<br />
<br />
To use this action you need to have {{Pkg|clamav}} and {{AUR|clamtk}} installed.<br />
<br />
{| class="wikitable"<br />
! Name !! Command !! File patterns !! Appears if selection contains<br />
|-<br />
! Scan for virus<br />
| {{ic|clamtk %F}} || * || Select all<br />
|}<br />
<br />
=== Link to Dropbox ===<br />
<br />
{| class="wikitable"<br />
! Name !! Command !! File patterns !! Appears if selection contains<br />
|-<br />
! Link to Dropbox<br />
| {{ic|ln -s %f /path/to/DropboxFolder}} || * || Directories, other files<br />
|}<br />
<br />
Please note that when using many custom actions to symlink files and folder to a particular place, it might be useful to put them into the {{ic|Send To}} folder of the context menu to avoid that the menu itself gets bloated. This is fairly easy to achieve and requires a .desktop file in {{ic|~/.local/share/Thunar/sendto}} for each action to perform. Say we want to put the above Dropbox symlink action into Send To, we create a {{ic|dropbox_folder.desktop}} with the following content. The new applied action will be active after restarting Thunar.<br />
<br />
{{bc|<nowiki><br />
[Desktop Entry]<br />
Type=Application<br />
Version=1.0<br />
Encoding=UTF-8<br />
Exec=ln -s %f /path/to/DropboxFolder<br />
Icon=/usr/share/icons/dropbox.png<br />
Name=Dropbox<br />
</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Tumblerd hangs up, uses too much CPU ===<br />
<br />
Tumblerd, the service that watches the file system and notifies the system when a thumbnail needs to be made may get stuck in a loop, using 100% of the system's CPU, see the [https://bugzilla.xfce.org/show_bug.cgi?id=7384 bug report]. The following script is a temporary workaround to stop this from happening. Copy, and paste this into a ''.sh'' file, save it somewhere in your home directory, mark the file as executable then set up the system to autostart it at system startup. <br />
<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
period=20<br />
tumblerpath="/usr/lib/*/tumbler-1/tumblerd" # The * here should find the right one, whether 32 and 64-bit<br />
cpu_threshold=50<br />
mem_threshold=20<br />
max_strikes=2 # max number of above cpu/mem-threshold's in a row<br />
log="/tmp/tumblerd-watcher.log"<br />
<br />
if [[ -n "${log}" ]]; then<br />
cat /dev/null > "${log}"<br />
exec >"${log}" 2>&1<br />
fi<br />
<br />
<br />
strikes=0<br />
while sleep "${period}"; do<br />
while read pid; do<br />
cpu_usage=$(ps --no-headers -o pcpu -f "${pid}"|cut -f1 -d.)<br />
mem_usage=$(ps --no-headers -o pmem -f "${pid}"|cut -f1 -d.)<br />
<br />
if [[ $cpu_usage -gt $cpu_threshold ]] || [[ $mem_usage -gt $mem_threshold ]]; then<br />
echo "$(date +"%F %T") PID: $pid CPU: $cpu_usage/$cpu_threshold %cpu MEM: $mem_usage/$mem_threshold STRIKES: ${strikes} NPROCS: $(pgrep -c -f ${tumblerpath})"<br />
(( strikes++ ))<br />
if [[ ${strikes} -ge ${max_strikes} ]]; then<br />
kill "${pid}"<br />
echo "$(date +"%F %T") PID: $pid KILLED; NPROCS: $(pgrep -c -f ${tumblerpath})"<br />
strikes=0<br />
fi<br />
else<br />
strikes=0<br />
fi<br />
done < <(pgrep -f ${tumblerpath})<br />
done<br />
</nowiki>}}<br />
<br />
=== Trash/network icons disappear randomly ===<br />
<br />
Make sure all Thunar instances start '''after''' ''gvfs''. [https://bugs.launchpad.net/ubuntu/+source/thunar/+bug/1057610] For {{ic|thunar --daemon}}, you can create a wrapper that waits until GVFS is active:<br />
<br />
{{Note|{{ic|/usr/local/bin}} should come before {{ic|/usr/bin}} in {{ic|$PATH}}.}}<br />
<br />
{{hc|/usr/local/bin/Thunar|<nowiki><br />
#!/bin/bash<br />
if [[ $1 == --daemon ]]<br />
then<br />
until pgrep gvfs >/dev/null<br />
do<br />
sleep 1<br />
done<br />
exec /usr/bin/Thunar "$@"<br />
else<br />
exec /usr/bin/Thunar "$@"<br />
fi<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [http://thunar.xfce.org/index.html Thunar] project page<br />
* [http://goodies.xfce.org/projects/thunar-plugins/thunar-volman Thunar Volume Manager] project page<br />
* This [http://goodies.xfce.org/projects/thunar-plugins/start list] of plugins</div>Schmodd