#netplan — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #netplan, aggregated by home.social.
-
Okay, if today is a day of morons, I must mention #systemd, #netplan, and maintainers of #nftables who specified network-pre.target for Wants and Before in nftables.service.
Just think: network-pre
They are happily unaware of tunnels created by netplan.
And netplan cannot create tun interfaces, LOL.
#ifupdown and #sysvinit worked like a charm but which VPS provider offer, say, #devuan ?
Modern developers drag us back to the stone age.
-
Ubuntu 25.10 Network Disabled After Reboot? Do not panic! Here's How to Fix it.
Full Guide: https://ostechnix.com/ubuntu-25-10-network-disabled-after-reboot/
-
Es momento para lanzar un testlab 🤠 con la rc1 #debiantrixie #netplan #podman #wireguard
-
Just replaced my 18-year old gateway/router/firewall computer (homebuilt Athlon-based). It has been reliably up 24/7 all this time. Sorry to tear it down, but the new machine is better in every way.
The switch included a change in the boot configuration from using network/interfaces and ifupdown to using #netplan and #systemd.
Next: installing #PiHole and #Nextcloud on the new machine.
-
@ubuntuasahi #netplan was the answer. It doesn't do anything by default. Added config to request DHCPv4 on #ens0 (network interface). And then it immediately got an IP address after running `netplan apply`. Case solved
-
#Netplan 1.1.2 has been released (#Canonical / #Ubuntu / #YAML / #NetworkManager / #SystemdNetworkD / #NetworkConfiguration) https://netplan.io/
-
I just hope the rest of the road is smoother. Fighting for a while with configuration is pretty darn discouraging and exhausting.
I think I was spoiled with #networkd and #netplan (with networkd backend) for the most part working just the way I like, even though netplan is missing some things I need.
-
I just hope the rest of the road is smoother. Fighting for a while with configuration is pretty darn discouraging and exhausting.
I think I was spoiled with #networkd and #netplan (with networkd backend) for the most part working just the way I like, even though netplan is missing some things I need.
-
I just hope the rest of the road is smoother. Fighting for a while with configuration is pretty darn discouraging and exhausting.
I think I was spoiled with #networkd and #netplan (with networkd backend) for the most part working just the way I like, even though netplan is missing some things I need.
-
I just hope the rest of the road is smoother. Fighting for a while with configuration is pretty darn discouraging and exhausting.
I think I was spoiled with #networkd and #netplan (with networkd backend) for the most part working just the way I like, even though netplan is missing some things I need.
-
I just hope the rest of the road is smoother. Fighting for a while with configuration is pretty darn discouraging and exhausting.
I think I was spoiled with #networkd and #netplan (with networkd backend) for the most part working just the way I like, even though netplan is missing some things I need.
-
I'm configuring #KVM on my #Linux laptop this morning and I came across #netplan. It's a tool to easily configure, networks on Linux. Very useful if you need to configure bridge devices on #Ubuntu. #networking https://netplan.io
-
802.1x on #Debian or #Ubuntu anybody? Manually running wpa_supplicant with password=hash:something and dhclient works for me, but it did not work adding this to /etc/network/interfaces. I always end up in default VLAN using this method.
Will one of the other methods (#systemd-networkd, #NetworkManager or #netplan support hashed passwords?)
I am just looking for a method that works.
#8021x -
today i learned that when #systemd gets restarted on my headless ubuntu 24.04 server, as it did with a recent update, this apparently also restarts systemd-networkd, and that kills ethernet connectivity until a reboot. since it's headless and doesn't currently have any other management options, that's never fun.
i saw that systemd-networkd was integrated with #netplan. i tried bypassing netplan and using a systemd-networkd configuration alone - which was an interesting challenge - but still, every time systemd-networkd restarts, networking is donezo. so i also tried switching to #networkmanager and ditching systemd-networkd, but then, somehow boot is delayed significantly and udisks2 fails to start (...why?!).
i have had to resort to setting up the watchdog package to reboot when network activity stops or pings fail. i don't like it, but i don't know what else to do in this distro.
also, kudos to anyone who can manage to use the term "systemd-networkd" in a post more than i did here.
-
#Netplan 1.1 has been released (#Canonical / #Ubuntu / #YAML / #NetworkManager / #SystemdNetworkD / #NetworkConfiguration) https://netplan.io/
-
How to Switch Back to /etc/network/interfaces From #Netplan
https://www.tecmint.com/switch-from-netplan-to-interfaces-ubuntu/
-
Final review and merge of Lukas Märdian's merge request, adding #Netplan support to #DebianInstaller → https://salsa.debian.org/installer-team/netcfg/-/merge_requests/9 (uploaded as netcfg/1.190).
Whether `netplan-generator` gets installed by default is a *different* question though, and the installer team probably won't be making that decision.
-
Quizfrage an die netplan-Menschen unter euch:
Meine Netplan-Config im ersten Bild und dann die Ausgabe von ip a im nächsten Bild.
Warum will meine Brücke sich nie mit meinem Netzwerk verbinden? Habt Ihr Ideen, wie ich da weiteres herauszufinden kann?
Laut anderen Beispielen im Netz sollte das eigentlich klappen. -
Whats the "best" way to create a visual overview of #server #infrastructure with hosts, their #virtualmachines which run on them and their provided #services?
Problem of #netplan is the need to update it manually on a regular basis, which could be more time consuming. I tried a solution with #markdown and #mermaid syntax but the visual result is a bit lacking.
Open for any hints or tips in this regard. #sysadmin #linux #kvm #networks -
My Laptop turned Ubuntu Servers built-in LAN port broke. So over to Amazon same day delivery of a USB-Lan cable.
Plugged it in - but hmm, no IP. Quick google and found out about the new #NetPlan. So one file edited later and it's picked up my servers static IP from my router and all my dockers are up and running!
-
Woohoo! Template builds with packer and deploys with opentofu are all working. IP customization is passing through to the guest, which really was the hardest part for me to get going on Ubuntu 23.10 with netplan.
Shout out to @lamw who mentioned in a blog post about checking the file /var/log/vmware/toolsDeployPkg.log for relevant messages.
Said blog post is nearly two years old and reminds me of the power of blogging about technical topics. Little notes and tips are how people figure things out. They can be gems in the ocean of data that is the internet blogosphere.
I will, of course, be blogging my experience with Ubuntu 23.10 and what I've learned along the way.
-
It's always DNS, right? If someone experiencing some strange issues with ubuntu, maybe this toot is for you.
tl;dr: switch from systemd-resolved to resolvconf.
I thought, the saying from the beginning was just something from the "old days". No DNS Problems in 2024 anymore, right? But Ubuntu taught me different.
Ubuntu is using systemd-resolved since 20.04 (if I'm correct). But I was shocked, when I was looking at my uptime kuma Container on a Ubuntu 22.04 LTS Host. It was constantly failing. Sometimes 3 services at the same time, sometimes just 1 service a day. One Check suddenly failed. 60 seconds later, the next check, switched back to green again. But all fails had the same error message: "getaddrinfo ENOTFOUND domain.com". Doesn't matter if they were internal domains or external. Sometimes some of them just failed.
I thought it could be an old Firewall Applience that were running at like 120% system utilization and were serving DHCP and (with this) internal DNS. But no. Not even high latencies from that Firewall. Then I thought it might be AdGuard (in a Docker Container). So I switched to PiHole. But the problems were still the same.
Then I turned on debug logs of systemd-resolved and found out that sometimes it was switching to the secondary DNS Server for whatever reason and just attaching the search domain to the following requests:
1. AAAA of demodomain.com
--> no answer (because only A were available)
2. A of demodomain.com
--> somehow failed, systemd-resolved switched to second DNS (debug log of systemd-resolved is hard to read, not sure why it somehow failed)
3. AAAA of demodomain.com.local
--> it just attached the searchdomain of the system to the domain which now resulting in errors from all following DNS ServerAfter another round of wrong requests it suddenly get back his head. But in the meantime, uptime kuma already failed.
The solution in my case: switch "back" to resolvconf package on Ubuntu. Which comes to at least one downside: it seems to not have an interface to netplan and/or networkmanager (which leads to manual creating and managing of resolv.conf, not via DHCP, bummer). But after I switched: Everything is working fine and without any problems since days.
"We" also have an open bug report since 3 years: https://github.com/systemd/systemd/issues/21123
It's not exactly the same issue, but I think the root cause is connected somehow: it seems to be a problem of IPv6.
But a) I need (or better: want) IPv6 in my case/that network and b) WTF? How can this be a good solution to turn off IPv6 (https://github.com/systemd/systemd/issues/21123#issuecomment-2028976737)? Not to mention that we still need a solution for Post-IPv4.By the way: If you still experiencing DNS issues inside Docker Container, maybe Alpine could be another issue: https://martinheinz.dev/blog/92
#systemdresolved #ubuntu #Ubuntu2404 #uptimekuma #dns #usg #unifi #ubiquiti #adguard #pihole #netplan #networkmanager #ipv4 #ipv6 #alpine #docker #glibc #musl
-
It's always DNS, right? If someone experiencing some strange issues with ubuntu, maybe this toot is for you.
tl;dr: switch from systemd-resolved to resolvconf.
I thought, the saying from the beginning was just something from the "old days". No DNS Problems in 2024 anymore, right? But Ubuntu taught me different.
Ubuntu is using systemd-resolved since 20.04 (if I'm correct). But I was shocked, when I was looking at my uptime kuma Container on a Ubuntu 22.04 LTS Host. It was constantly failing. Sometimes 3 services at the same time, sometimes just 1 service a day. One Check suddenly failed. 60 seconds later, the next check, switched back to green again. But all fails had the same error message: "getaddrinfo ENOTFOUND domain.com". Doesn't matter if they were internal domains or external. Sometimes some of them just failed.
I thought it could be an old Firewall Applience that were running at like 120% system utilization and were serving DHCP and (with this) internal DNS. But no. Not even high latencies from that Firewall. Then I thought it might be AdGuard (in a Docker Container). So I switched to PiHole. But the problems were still the same.
Then I turned on debug logs of systemd-resolved and found out that sometimes it was switching to the secondary DNS Server for whatever reason and just attaching the search domain to the following requests:
1. AAAA of demodomain.com
--> no answer (because only A were available)
2. A of demodomain.com
--> somehow failed, systemd-resolved switched to second DNS (debug log of systemd-resolved is hard to read, not sure why it somehow failed)
3. AAAA of demodomain.com.local
--> it just attached the searchdomain of the system to the domain which now resulting in errors from all following DNS ServerAfter another round of wrong requests it suddenly get back his head. But in the meantime, uptime kuma already failed.
The solution in my case: switch "back" to resolvconf package on Ubuntu. Which comes to at least one downside: it seems to not have an interface to netplan and/or networkmanager (which leads to manual creating and managing of resolv.conf, not via DHCP, bummer). But after I switched: Everything is working fine and without any problems since days.
"We" also have an open bug report which since 3 years: https://github.com/systemd/systemd/issues/21123
It's not exactly the same issue, but I think the root cause is connected somehow: it seems to be a problem of IPv6.
But a) I need (or better: want) IPv6 in my case/that network and b) WTF? How can this be a good solution to turn off IPv6 (https://github.com/systemd/systemd/issues/21123#issuecomment-2028976737)? Not to mention that we still need a solution for Post-IPv4.By the way: If you still experiencing DNS issues inside Docker Container, maybe Alpine could be another issue: https://martinheinz.dev/blog/92
#systemdresolved #ubuntu #Ubuntu2404 #uptimekuma #dns #usg #unifi #ubiquiti #adguard #pihole #netplan #networkmanager #ipv4 #ipv6 #alpine #docker #glibc #musl
-
It's always DNS, right? If someone experiencing some strange issues with ubuntu, maybe this toot is for you.
tl;dr: switch from systemd-resolved to resolvconf.
I thought, the saying from the beginning was just something from the "old days". No DNS Problems in 2024 anymore, right? But Ubuntu taught me different.
Ubuntu is using systemd-resolved since 20.04 (if I'm correct). But I was shocked, when I was looking at my uptime kuma Container on a Ubuntu 22.04 LTS Host. It was constantly failing. Sometimes 3 services at the same time, sometimes just 1 service a day. One Check suddenly failed. 60 seconds later, the next check, switched back to green again. But all fails had the same error message: "getaddrinfo ENOTFOUND domain.com". Doesn't matter if they were internal domains or external. Sometimes some of them just failed.
I thought it could be an old Firewall Applience that were running at like 120% system utilization and were serving DHCP and (with this) internal DNS. But no. Not even high latencies from that Firewall. Then I thought it might be AdGuard (in a Docker Container). So I switched to PiHole. But the problems were still the same.
Then I turned on debug logs of systemd-resolved and found out that sometimes it was switching to the secondary DNS Server for whatever reason and just attaching the search domain to the following requests:
1. AAAA of demodomain.com
--> no answer (because only A were available)
2. A of demodomain.com
--> somehow failed, systemd-resolved switched to second DNS (debug log of systemd-resolved is hard to read, not sure why it somehow failed)
3. AAAA of demodomain.com.local
--> it just attached the searchdomain of the system to the domain which now resulting in errors from all following DNS ServerAfter another round of wrong requests it suddenly get back his head. But in the meantime, uptime kuma already failed.
The solution in my case: switch "back" to resolvconf package on Ubuntu. Which comes to at least one downside: it seems to not have an interface to netplan and/or networkmanager (which leads to manual creating and managing of resolv.conf, not via DHCP, bummer). But after I switched: Everything is working fine and without any problems since days.
"We" also have an open bug report since 3 years: https://github.com/systemd/systemd/issues/21123
It's not exactly the same issue, but I think the root cause is connected somehow: it seems to be a problem of IPv6.
But a) I need (or better: want) IPv6 in my case/that network and b) WTF? How can this be a good solution to turn off IPv6 (https://github.com/systemd/systemd/issues/21123#issuecomment-2028976737)? Not to mention that we still need a solution for Post-IPv4.By the way: If you still experiencing DNS issues inside Docker Container, maybe Alpine could be another issue: https://martinheinz.dev/blog/92
#systemdresolved #ubuntu #Ubuntu2404 #uptimekuma #dns #usg #unifi #ubiquiti #adguard #pihole #netplan #networkmanager #ipv4 #ipv6 #alpine #docker #glibc #musl
-
It's always DNS, right? If someone experiencing some strange issues with ubuntu, maybe this toot is for you.
tl;dr: switch from systemd-resolved to resolvconf.
I thought, the saying from the beginning was just something from the "old days". No DNS Problems in 2024 anymore, right? But Ubuntu taught me different.
Ubuntu is using systemd-resolved since 20.04 (if I'm correct). But I was shocked, when I was looking at my uptime kuma Container on a Ubuntu 22.04 LTS Host. It was constantly failing. Sometimes 3 services at the same time, sometimes just 1 service a day. One Check suddenly failed. 60 seconds later, the next check, switched back to green again. But all fails had the same error message: "getaddrinfo ENOTFOUND domain.com". Doesn't matter if they were internal domains or external. Sometimes some of them just failed.
I thought it could be an old Firewall Applience that were running at like 120% system utilization and were serving DHCP and (with this) internal DNS. But no. Not even high latencies from that Firewall. Then I thought it might be AdGuard (in a Docker Container). So I switched to PiHole. But the problems were still the same.
Then I turned on debug logs of systemd-resolved and found out that sometimes it was switching to the secondary DNS Server for whatever reason and just attaching the search domain to the following requests:
1. AAAA of demodomain.com
--> no answer (because only A were available)
2. A of demodomain.com
--> somehow failed, systemd-resolved switched to second DNS (debug log of systemd-resolved is hard to read, not sure why it somehow failed)
3. AAAA of demodomain.com.local
--> it just attached the searchdomain of the system to the domain which now resulting in errors from all following DNS ServerAfter another round of wrong requests it suddenly get back his head. But in the meantime, uptime kuma already failed.
The solution in my case: switch "back" to resolvconf package on Ubuntu. Which comes to at least one downside: it seems to not have an interface to netplan and/or networkmanager (which leads to manual creating and managing of resolv.conf, not via DHCP, bummer). But after I switched: Everything is working fine and without any problems since days.
"We" also have an open bug report which since 3 years: https://github.com/systemd/systemd/issues/21123
It's not exactly the same issue, but I think the root cause is connected somehow: it seems to be a problem of IPv6.
But a) I need (or better: want) IPv6 in my case/that network and b) WTF? How can this be a good solution to turn off IPv6 (https://github.com/systemd/systemd/issues/21123#issuecomment-2028976737)? Not to mention that we still need a solution for Post-IPv4.By the way: If you still experiencing DNS issues inside Docker Container, maybe Alpine could be another issue: https://martinheinz.dev/blog/92
#systemdresolved #ubuntu #Ubuntu2404 #uptimekuma #dns #usg #unifi #ubiquiti #adguard #pihole #netplan #networkmanager #ipv4 #ipv6 #alpine #docker #glibc #musl
-
It's always DNS, right? If someone experiencing some strange issues with ubuntu, maybe this toot is for you.
tl;dr: switch from systemd-resolved to resolvconf.
I thought, the saying from the beginning was just something from the "old days". No DNS Problems in 2024 anymore, right? But Ubuntu taught me different.
Ubuntu is using systemd-resolved since 20.04 (if I'm correct). But I was shocked, when I was looking at my uptime kuma Container on a Ubuntu 22.04 LTS Host. It was constantly failing. Sometimes 3 services at the same time, sometimes just 1 service a day. One Check suddenly failed. 60 seconds later, the next check, switched back to green again. But all fails had the same error message: "getaddrinfo ENOTFOUND domain.com". Doesn't matter if they were internal domains or external. Sometimes some of them just failed.
I thought it could be an old Firewall Applience that were running at like 120% system utilization and were serving DHCP and (with this) internal DNS. But no. Not even high latencies from that Firewall. Then I thought it might be AdGuard (in a Docker Container). So I switched to PiHole. But the problems were still the same.
Then I turned on debug logs of systemd-resolved and found out that sometimes it was switching to the secondary DNS Server for whatever reason and just attaching the search domain to the following requests:
1. AAAA of demodomain.com
--> no answer (because only A were available)
2. A of demodomain.com
--> somehow failed, systemd-resolved switched to second DNS (debug log of systemd-resolved is hard to read, not sure why it somehow failed)
3. AAAA of demodomain.com.local
--> it just attached the searchdomain of the system to the domain which now resulting in errors from all following DNS ServerAfter another round of wrong requests it suddenly get back his head. But in the meantime, uptime kuma already failed.
The solution in my case: switch "back" to resolvconf package on Ubuntu. Which comes to at least one downside: it seems to not have an interface to netplan and/or networkmanager (which leads to manual creating and managing of resolv.conf, not via DHCP, bummer). But after I switched: Everything is working fine and without any problems since days.
"We" also have an open bug report which since 3 years: https://github.com/systemd/systemd/issues/21123
It's not exactly the same issue, but I think the root cause is connected somehow: it seems to be a problem of IPv6.
But a) I need (or better: want) IPv6 in my case/that network and b) WTF? How can this be a good solution to turn off IPv6 (https://github.com/systemd/systemd/issues/21123#issuecomment-2028976737)? Not to mention that we still need a solution for Post-IPv4.By the way: If you still experiencing DNS issues inside Docker Container, maybe Alpine could be another issue: https://martinheinz.dev/blog/92
#systemdresolved #ubuntu #Ubuntu2404 #uptimekuma #dns #usg #unifi #ubiquiti #adguard #pihole #netplan #networkmanager #ipv4 #ipv6 #alpine #docker #glibc #musl
-
Will, I believe it's time to refresh to #Ubuntu #NobleNumbat.
Quite a lot has come out on this release. 😎 Defaulting to #netplan is one I want to try out. 😅
https://ubuntu.com/blog/ubuntu-desktop-24-04-noble-numbat-deep-dive -
Ubuntu 24.04 LTS kommt mit Netplan 1.0
https://opensocial.at/display/59c238fc-1666-164c-e109-f64064909244
-
#Canonical Announces #Netplan 1.0 with Simultaneous WPA2 and WPA3 Support
https://9to5linux.com/canonical-announces-netplan-1-0-with-simultaneous-wpa2-and-wpa3-support
-
Canonical Formally Announces #Netplan 1.0 with Simultaneous WPA2 & WPA3 Support, WPA3-Enterprise Support, and More https://9to5linux.com/canonical-announces-netplan-1-0-with-simultaneous-wpa2-and-wpa3-support
-
How To Configure Static IP Address In Ubuntu #ipaddress #ubuntu #linux #netplan #nmcli #nmtui #linuxhowto #linuxadministration
https://ostechnix.com/configure-static-ip-address-ubuntu/ -
How To Configure Static IP Address In Ubuntu #ipaddress #ubuntu #linux #netplan #nmcli #nmtui #linuxhowto #linuxadministration
https://ostechnix.com/configure-static-ip-address-ubuntu/ -
How To Configure Static IP Address In Ubuntu #ipaddress #ubuntu #linux #netplan #nmcli #nmtui #linuxhowto #linuxadministration
https://ostechnix.com/configure-static-ip-address-ubuntu/ -
How To Configure Static IP Address In Ubuntu #ipaddress #ubuntu #linux #netplan #nmcli #nmtui #linuxhowto #linuxadministration
https://ostechnix.com/configure-static-ip-address-ubuntu/ -
How To Configure Static IP Address In Ubuntu #ipaddress #ubuntu #linux #netplan #nmcli #nmtui #linuxhowto #linuxadministration
https://ostechnix.com/configure-static-ip-address-ubuntu/ -
Wanted to share a recent project of mine from past few weeks to turn my #nanopi r5s #sbc into a really potent pure debian Linux router that was sane to manage.
I was able to successfully switch over this weekend and retire my edgerouter-6p.
The formula is basically #ansible #systemd stuff #netplan #dnsmasq #frrouting and #foomuuri -- the lynchpin solution for sanely doing robust zone-to-zone firewalls using #nftables
Repo linked below has more details:
-
@yakkoj Have you ever considered using #Netplan?
#ItJust works and also does all the nice stuff, like #VLAN's and #Bonding...
Personally, I prefer putting #firewalling into the #Networking segment and put a #pfSense, #tnsr or #OPNsense in between it and the Interwebz.
But Netplan allows you to go precise and i.e. specify that no incoming connections are permitted on the Storage-LAN used for iSCSI traffic at MTU 9k and other stuff...
-
@yakkoj Have you ever considered using #Netplan?
#ItJust works and also does all the nice stuff, like #VLAN's and #Bonding...
Personally, I prefer putting #firewalling into the #Networking segment and put a #pfSense, #tnsr or #OPNsense in between it and the Interwebz.
But Netplan allows you to go precise and i.e. specify that no incoming connections are permitted on the Storage-LAN used for iSCSI traffic at MTU 9k and other stuff...
