Note:
This documentation has moved to a new home! Please update your bookmarks to the new URL for the up-to-date version of this page.
4 Likes
I figured out how to make the wired network manageable in 19.10.
View the netplan configuration
$cd /etc/netplan
$sudo nano 50-cloud-init.yaml
If the 50-cloud-init.yaml file is blank
$sudo netplan generate
$sudo netplan apply
Edit 50-cloud-init.yaml
$sudo nano 50-cloud-init.yaml
50-cloud-init.yaml:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
ethernets:
eth0:
dhcp4: true
optional: true
version: 2
Edit 50-cloud-init.yaml by adding renderer: NetworkManager
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following
# network: {config: disabled}
network:
renderer: NetworkManager
ethernets:
eth0:
dhcp4: true
version: 2
Save the file and apply the new configuration:
$sudo netplan apply
My reply didn’t format correctly. Sorry!
Hi mcapehart!
Thanks for contributing some information. I went through and updated your post to use the ``` before and after each of the code blocks. That enables it to be formatted correctly.
About your content, on most server deployments we generally do not find two things that are different than your suggestion:
- network configuration is passed via a cloud’s metadata service and configured by cloud-init. Therefore, if the cloud-init yaml is empty then you are booting on a cloud without a metadataservice or not using the subiquity-based server installer.
- NetworkManager is generally not used. In fact it is only installed if someone enables it to be installed.
Do you have more details why your cloud-init yaml is empty? How did you install Ubuntu or get your server running? Is there a reason you want to use NetworkManager?
Thanks!
Just in case anyone searches for this and finds it, I wanted to notate an issue I found with the page discussed here.
In the section Static IP Address Assignment I found a problem in which my 20.04 servers were using the static IP address I was configuring while still trying to get a DHCP address issued to them. It seems the code section is missing a line under the adaptor section.
Current code:
network:
version: 2
renderer: networkd
ethernets:
eth0:
addresses:
- 10.10.10.2/24
gateway4: 10.10.10.1
nameservers:
search: [mydomain, otherdomain]
addresses: [10.10.10.1, 1.1.1.1]
I added the line dhcp4: no under the eth0: entry to stop that behaviour. It’s working for me for what I wanted. I figured if you’re specifying the IP address, you probably want to turn off DHCP, so the documentation may want to be updated.
Thanks,
Chris
Text reads " … lshw shows a single Ethernet interface with the logical name of eth0 …"
The example indicates ’ … logical name: eth4 …’; slightly confusing.
The Static IP section shows an example using gateway4 but this results in a warning message on Ubuntu 22.04:
`gateway4` has been deprecated, use default routes instead.
See the 'Default routes' section of the documentation for more details.
It would certainly be handy if it actually linked to the appropriate documentation, but that’s a netplan issue and not a documentation issue.
1 Like
Found the documentation at https://netplan.io/reference. The gateway4 should be replaced by
routes:
- to: default
via: 10.0.0.1
Thanks @jsglg and @fstx, I updated the yaml file with the new routes: block instead of gateway4, and added a note for Bionic 18.04 users.
Thanks @rokamuffin, I updated the interface name to be consistent with the lshw output.
Hello, noticed that the link Networking-Bridge doesn’t work.
404 Page Not Found
Hello @rokamuffin, thank you for the note. I updated the reference with a more precise link to the bridges examples in the netplan site, and removed the broken reference to the linux foundation site.
I was tempted to use the Linux Foundation’s wiki page on the subject, but it’s still using ifconfig instead of ip for many of the commands, so I thought it might be an old reference and it’s best we not link to it.
From what I see in https://netplan.io, the spelling of the project is “Netplan”, not “NetPlan”.
I’d like to suggest that everytime a tool or command is shown, at least for the first time in the page, that its mention should also be a link to its manpage.
For example, lshw could become lshw.
It’s probably best to introduce netplan generate here, and/or netplan try, as they can catch syntax errors that could cause networking to fail.
I suggest inverting the order, and adding “vice-versa”, like so:
“… process of mapping hostnames to IP addresses, and vice-versa, making it easier…”
Good catch - you’re quite right. I changed all the instances I could find to Netplan.
You’re right, this reads better. I’ve changed it now.
It would be nice if Cannonical would pick one way of congiguring networks and stick with it. Just about every time I set up a server, with a static address, there is a new and completely different way of doing it. This is the first I have heard of netplan.
I am unable to create a new topic therefore I find one that is closer to my issue.
I wonder if someone noticed this behavior when doing a ping -a on the Windows system. I cannot get the Pi’s hostname using -a on path B (Green), but my Android device can see the Pi’s hostname when connected. Only Windows Mobile hotspot is okay. Why is it so?
In both test cases, the UFW is enabled. All the connection types are wireless.
#### Windows 10 Mobile Hotspot with SSID 1 ######
PS C:\WINDOWS\system32> ping -a 192.168.137.145
Pinging hostname.mshome.net [192.168.137.145] with 32 bytes of data:
Reply from 192.168.137.145: bytes=32 time=1ms TTL=64
Reply from 192.168.137.145: bytes=32 time=2ms TTL=64
Reply from 192.168.137.145: bytes=32 time=4ms TTL=64
Reply from 192.168.137.145: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.137.145:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 4ms, Average = 2ms
PS C:\WINDOWS\system32>
#### Windows 10 Mobile Hotspot with SSID 2 ######
PS C:\WINDOWS\system32> ping -a 192.168.137.143
Pinging hostname-desktop.mshome.net [192.168.137.143] with 32 bytes of data:
Reply from 192.168.137.143: bytes=32 time=1ms TTL=64
Reply from 192.168.137.143: bytes=32 time=1ms TTL=64
Reply from 192.168.137.143: bytes=32 time=1ms TTL=64
Reply from 192.168.137.143: bytes=32 time=1ms TTL=64
Ping statistics for 192.168.137.143:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 1ms, Maximum = 1ms, Average = 1ms
PS C:\WINDOWS\system32>
#### Path B Router or Android Hotspot connection ######
PS C:\WINDOWS\system32> ping -a 192.168.175.63
Pinging 192.168.175.63 with 32 bytes of data:
Reply from 192.168.175.63: bytes=32 time=8ms TTL=64
Reply from 192.168.175.63: bytes=32 time=7ms TTL=64
Reply from 192.168.175.63: bytes=32 time=45ms TTL=64
Reply from 192.168.175.63: bytes=32 time=45ms TTL=64
Ping statistics for 192.168.175.63:
Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
Minimum = 7ms, Maximum = 45ms, Average = 26ms
PS C:\WINDOWS\system32>
Default: deny (incoming), allow (outgoing), disabled (routed)
New profiles: skip
To Action From
-- ------ ----
22/tcp ALLOW IN Anywhere
5900 ALLOW IN Anywhere
22/tcp (OpenSSH) ALLOW IN Anywhere
8000 ALLOW IN Anywhere
80 ALLOW IN Anywhere
3389 ALLOW IN Anywhere
5901 ALLOW IN Anywhere
22/tcp (v6) ALLOW IN Anywhere (v6)
5900 (v6) ALLOW IN Anywhere (v6)
22/tcp (OpenSSH (v6)) ALLOW IN Anywhere (v6)
8000 (v6) ALLOW IN Anywhere (v6)
80 (v6) ALLOW IN Anywhere (v6)
3389 (v6) ALLOW IN Anywhere (v6)
5901 (v6) ALLOW IN Anywhere (v6)
