- 1 Static IP example for Wireless adapter
- 2 Static IP example for single host
- 3 standalone vs containers
- 4 Usage with containers -- Static IP network
- 5 I couldn't find /run/systemd/resolve/resolv.conf
- 6 Note about systemd-resolved.service
- 7 More static/DHCP examples
- 8 Systemd-networkd dhcp configuration
- 9 nsswitch.conf
- 10 Why link /run/systemd/resolve/resolv.conf instead of /usr/lib/systemd/resolv.conf ?
Static IP example for Wireless adapter
Simply create /etc/systemd/network/25-wireless.network with, e.g.
[Match] Name=wlan0 [Network] Address=192.168.0.12/24 Gateway=192.168.0.254
needs no other file to work
Static IP example for single host
(moved from Talk:Network_configuration#Systemd-networkd)
Now that networkd is maturing and much simpler to configure for VMs, containers, etc should we include a section with an example? —This unsigned comment is by Chetwisniewski (talk) 21:42, 1 January 2015. Please sign your posts with ~~~~!
- There is a whole page on systemd-networkd already, and it is linked from Network_configuration#Configure_the_IP_address. -- Lahwaacz (talk) 21:52, 1 January 2015 (UTC)
- It doesn't include any decent static examples. Perhaps I should post these points to that page? Something with example config, like:
[Match] Name=enp3s0 [Network] DNS=fe80:a3c1::1 DNS=192.168.0.1 Address=192.168.0.10/24 Address=2001:DB8::1/64 Gateway=192.168.0.1
- Re-opening. That would make sense imo. But we need to take care not to break the existing Systemd-networkd#Static IP network instructions. Maybe it is just necessary to clarify which steps are required to set up static for a single host before leading over to the bridge/container setup (analoguous to the first example in Systemd-networkd#Basic DHCP network). Ok?--Indigo (talk) 23:57, 1 January 2015 (UTC)
- Comparing your example config again to what we have, the only major difference is the IPv6 which is not covered in this article yet. Still the basic instructions for a single host could be made clearer in this article. --Indigo (talk) 18:11, 9 February 2015 (UTC)
standalone vs containers
Yes, I agree with the discussion and the style warning on the main page: we should break this out into two parts to make it clear which are for standalone systems and which are for containers which are likely foreign to some users. Graysky (talk) 12:06, 27 March 2015 (UTC)
- There, I made a pretty major edit to the main article in an attempt to break out "basic" from "complex" usage cases. I don't have inclination or knowledge to comb through the original article targeted mainly at container usage. Graysky (talk) 19:49, 27 March 2015 (UTC)
- Neat edit that was! Good to have the basic examples on top. As for moving the container section to a subpage, sure why not. Yet, I would vote for keeping Systemd-networkd#Configuration files on the main page (to see how it works I moved it like it is now). It would be a strange article ending with a section like that though.? The container section uses some configuration files content as practical examples on the other hand. --Indigo (talk) 20:39, 27 March 2015 (UTC)
Usage with containers -- Static IP network
Not having worked with systemd-networkd before (moving over from the custom systemd script method) this section looks like it has a typo, an omission, or a missing explanation. The list of configuration files uses a .netdev extension on MyBridge, and the example uses a .network extension on MyBridge.
Again, being new to systemd-networkd, I think there is supposed to be both a MyBridge.netdev file with "[NetDev] Name=br0 Kind=bridge" and a MyBridge.bridge file with "[Match] Name=br0 [Network] DNS= Address= Gateway=". Or, maybe I'm using more files than I needed and just one of the extensions needs to be changed. Or maybe I'm totally off, and a clarification would prevent someone else from making the same mistake. Jamespharvey20 (talk) 06:44, 20 July 2015 (UTC)
- My guess is that you need MyBridge.netdev from Systemd-networkd#Bridge_interface, MyEth.network from Systemd-networkd#Bind_ethernet_to_bridge and MyBridge.network from Systemd-networkd#Static_IP_network (this is the change against Systemd-networkd#Bridge_network, hence the only file actually shown in that section). If you manage to get it working, please fix the listing of necessary files accordingly. -- Lahwaacz (talk) 07:39, 20 July 2015 (UTC)
- This is correct. The MyBridge.netdev file is needed to create the virtual device br0 first. This way the device now exists when MyEth.network refers to it with Bridge=br0 and MyBridge.network refers to it with Name=br0. Note: In a DHCP setup, I think it may be important to use file names to specify the order, since in theory a physical adapter needs to be bound to the bridge first before the bridge can request an IP address. Perhaps naming the files 10-MyBridge.netdev, 20-MyEth.network, and 30-MyBridge.network would help clarify the meaning behind these files better? This setup worked well for me. Xerion567 (talk) 09:31, 30 January 2016 (UTC)
I couldn't find /run/systemd/resolve/resolv.conf
I had read this line and I couldn't find the file
- ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf
But I can see /etc/systemd/resolved.conf. should I just do not link anything?
Answer: you need to run systemd-resolved, which will create it.
- This symlink should not be needed since systemd-226. In a typical setup, you should simply remove /etc/resolv.conf. Posted here, rather than edit wiki directly, in the event that this is not good for more advanced setups. DJ L (talk) 04:51, 4 February 2016 (UTC)
Note about systemd-resolved.service
In my today's contribution (https://wiki.archlinux.org/index.php?title=Systemd-networkd&oldid=408408) I've added a note about the systemd-resolved service. I never needed that service in a wired/static-ip/single user environment, checking the LFS doc http://www.linuxfromscratch.org/lfs/view/systemd/chapter07/network.html seems to confirm that in that scenario you don't actually need it. Please double check.
- I have no idea what you mean by "single user environment", but the official documentation is here. -- Lahwaacz (talk) 13:14, 7 November 2015 (UTC)
- The previous comment (by Matt3o) is incorrect. I'm not sure where exactly we differ (I only comment because I was actually the one who rewrote that part of BLFS page linked above), but the systemd-networkd service does not seem to be enabled by default in Arch's systemd package (I'm sure there is a reason, since it is enabled by default in a fresh build of systemd, I'm just not familiar with the decision to exclude it). As to where "single user environment" came from, I've no idea. That concept is pretty much dead, no more runlevel 2 since systemd has arrived, and networking wouldn't have been present in any case. Maybe he was referring to a single PC (very small network) where static networking is acceptable? :-/ DJ L (talk) 05:34, 4 February 2016 (UTC)
More static/DHCP examples
The Wiki mentions as a note "The Metric option is for static routes while the RouteMetric option is for setups not using static routes." While not clear why two different keywords are needed (but let's leave that for upstream to discuss), the Wiki has no example of how "Metric" is used in a static configuration.
I think the reader is left somewhat in a trial&error loop here (at least I am as I intend to keep my configuration I used in another distro: static for wired, DHCP for wireless). While I'll figure it out eventually, I think at least some clues here would have been helpful as I do not think that config is so exotic. (use static wired in home office, DHCP wireless abroad) Unfortunately, I'm still lacking sufficient systemd experience to make the amendments myself Archer666 (talk) 20:48, 2 November 2016 (UTC)
Systemd-networkd dhcp configuration
I'm getting confused with dhcp configuration parameters for ipv4. While SYSTEMD.NETWORK(5) suggests setting DHCP=ipv4 under the [Network] section, systemd-networkd refuses to start and logs a unknown parameter error. Setting DHCP=v4 resolves the issue, as the german Arch wiki article suggests: https://wiki.archlinux.de/title/Systemd/systemd-networkd Does anyone else see this with systemd 232? anarki (talk) 22:40, 2016-12-06 UTC
I removed the recommended nsswitch.conf configuration; it was misleading and out-of-date. The latest filesystem package configures nsswitch.conf correctly to use nss-resolve and fall back in the proper way to nss-dns. The recommended setup breaks glibc DNS resolution in several situations, notably with GPG. Tad (talk) 20:25, 21 February 2017 (UTC)
says linking from
/usr/lib/systemd/resolv.conf is preferred over linking to
- Could you provide a literal quote of the confusing part? -- Lahwaacz (talk) 16:58, 15 November 2017 (UTC)
- Sorry for being unspecific. It's the first codeblock here Systemd-networkd#Required_services_and_setup, immediately after the sentence "For compatibility with resolv.conf, delete or rename the existing file and create the following symbolic link when using systemd-resolved:" Mearon (talk) 18:22, 15 November 2017 (UTC)
- "•A static file /usr/lib/systemd/resolv.conf is provided that lists the 127.0.0.53 DNS stub (see above) as only DNS server. This file may be symlinked from /etc/resolv.conf in order to connect all local clients that bypass local DNS APIs to systemd-resolved. This mode of operation is recommended."
- Considering this seems to be in perpetual flux as most systemd things, I'd say we delete that sentence and just refer to the man page. -- Alad (talk) 19:29, 15 November 2017 (UTC)
-  lists three alternatives for dealing with /etc/resolv.conf:
- The Arch Wiki currently only mentions option 2 (
ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf) while recommends option 1 (
ln -s /usr/lib/systemd/resolv.conf /etc/resolv.conf) as quoted by Alad. Mearon (talk) 20:49, 15 November 2017 (UTC)
- It seems that in systemd 236 the recommended option is changing. As per : "systemd-resolved now maintains a new dynamic /run/systemd/resolve/stub-resolv.conf compatibility file. It is recommended to make /etc/resolv.conf a symlink to it. This file points at the systemd-resolved stub DNS 127.0.0.53 resolver and includes dynamically acquired search domains, achieving more correct DNS resolution by software that bypasses local DNS APIs such as NSS."
- It seems the best of both worlds since this way programs that directly read
resolv.confdon't bypass systemd-resolved's per-interface DNS server configuration (very problematic in the case of VPN's, for example) but search domains are still accessible for them.
stub-resolv.conf. --Icycat (talk) 16:30, 16 December 2017 (UTC) 236 is finally available in core, I think we should update this page to recommend using the new