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
systemd-networkd + Dm-crypt/Swap = system not booting
I encountered issue on fresh install on small VPS (1Gb RAM, 1vCPU) that if I have systemd-networkd and crypt-swap then boot process hangs while waiting for crypt-swap device. Posted workaround here: https://bbs.archlinux.org/viewtopic.php?pid=1882917#p1882917
Setting up and connecting to wireless networks using systemd-networkd via wpa_supplicant
systemd-networkd is great for configuring wired networks, but it lacks the ability to authenticate or associate (connect) with/to a wireless network. This leaves the user wondering and looking for alternatives. There is a clever trick, and that is to use something like wpa_supplicant. There are advantages to use systemd-networkd with wpa_supplicant, and here are the highlights:
- wpa_supplicant does not interfere with systemd-networkd, as systemd-networkd handles IP and routing, whereas wpa_supplicant handles with authentication and association/connection. Technically, the two operates on different layers on the OSI model.
- wpa_supplicant, like systemd-networkd, does not have a graphical interface/front-end. This can be especially useful when one does not need to worry about the memory/bandwidth overhead for needing to interface it graphically and/or remotely.
- wpa_supplicant can store Pre-Shared Key (PSK) in encrypted format. Some network managers stores these in plain text, thus could lead to other security implications in the event of machine compromise, and that it contains keys/passwords stored in plain text.
Naturally, the use of such a setup does also have certain caveats, and with complicating the issues being one of them.
These leads me to my suggestion. Considering that there has been discussions on how to make the two daemons work together on Arch Linux Forums, and that it is a link under the See Also section of this (Systemd-networkd wiki) page. Is it possible instead, to expand this as a sub-page (to this page of course) or at least as a sub-section? Unfortunately,
- Some of the links detailed on the forums are dead (but Wayback machine still has records of these),
- The forum thread does not offer much explanation/insights, and,
- There's no reference from wpa_supplicant page to either that forum thread, or this (Systemd-networkd) page.
With that said, I could help contribute if there's an/enough interest. Addressing this could also see the following be added once it is complete; Talk:Systemd-networkd#Static_IP_example_for_Wireless_adapter
- What is there to describe on the "subpage"? As you said, systemd-networkd and wpa_supplicant operate on different layers, so you configure both as usual, there is nothing special needed to make them work together. There are already multiple references to both wpa_supplicant and iwd so it is obvious that the other thing is needed too. -- Lahwaacz (talk) 09:43, 22 December 2020 (UTC)
- Indeed, there is nothing special about the process. However, the information currently provided as-is, are rudimentary at best, almost like as if considerations to such options are of an afterthought. My point was to:
- Adding page/section visibility (as a related article, as opposed to a link in the see also section),
- Flesh out the information by adding (reference) links, even if they might be dead or archived, and,
- Allow the viability of expansion for the said article.
- Pages on the wiki are created based on the content, not for artificial visibility. I don't think there is enough content for a separate page.
- What references are you talking about? Adding dead or archived links does not make sense.
- You can expand this very page if something is missing, you don't need a new page for that. But I don't see how you imagine the new content yet...
- -- Lahwaacz (talk) 09:37, 24 December 2020 (UTC)
- The intention was to create a stub page that explains lightly the process, provide a crude example of how to make it all work, along with a few archived links as reference points. This was with hopes to have more related content (e.g. more examples) added to it, as this (existing) page primarily focuses on wired networking aspect, and I was hoping to structure it based on how Network_configuration and Network_configuration/Wireless were made respectively.
- The references are as per outlined before; making systemd-networkd and wpa_supplicant work together. Anyway, here are the links to it:
- The alternative would then be to simply copy and paste the contents of the archived links on here instead, as I do not wish to necro-bump/necro-post an old BBS/forum thread. Posting a new thread in continuation on that old thread instead could potentially be counter-intuitive.
- I could expand on this existing page. However after discussing it, noticing the recent change on this talk page, it made sense, and my interest with it waned. Initially, I did not want to "pollute" the page with wireless content, as it is also hypothetically possible to make iwd, instead of wpa_supplicant to work with systemd-networkd for instance. Besides, it is boiling down to the end users needing to exercise some ingenuity, as opposed to having a wiki thoroughly explaining these. :)
- -- Tuxsavvy (talk) 09:17, 2 January 2021 (UTC)
Add configuration examples from archiso
... to Systemd-networkd#Configuration_examples, as suggested in Talk:Installation_guide#GitLab_blobs_in_Lynx. I'm not sure on the best fit - maybe a Template:Tip? -- Alad (talk) 11:35, 4 November 2021 (UTC)
Cloud image uses netplan
I had a lot of trouble setting the search domains on a vm built from the arch cloud image.
Network on there is configured by cloud-init using netplan (looking for that on the wiki yields zero results). What I had to do was to edit /etc/netplan/50-cloud-init.yaml and reapply to make my settings work. *.network files were ignored.
Would it make sense to include that somewhere in the article?
- Can you provide a link to the base Arch "cloud image" that you used? — Lahwaacz (talk) 06:52, 16 December 2021 (UTC)
- Of course: https://gitlab.archlinux.org/archlinux/arch-boxes/-/jobs/38324/artifacts/raw/output/Arch-Linux-x86_64-cloudimg-20211101.38317.qcow2 this is the image I used. -- JoeCool (talk) 00:42, 17 December 2021 (UTC)
All .link files are processed by systemd-udevd rather than systemd-networkd. Mixing them with .network and .netdev files causes confusion among readers.
Alternatively, this page should be renamed to systemd-network (remove the trailing 'd').