/srv/irclogs.ubuntu.com/2022/08/26/#ubuntu-server.txt

blahdeblahrfm: thanks00:04
ChmEarlblahdeblah, you need dom0 at xen-4.15.x or higher to handle zstd compressed kernels like in Jammy or any Fedora 34+01:46
blahdeblahChmEarl: Yeah, seems that way.  Which means a jammy domU on a Debian bullseye dom0 is no-go.01:58
ChmEarlblahdeblah, wait till you try and debootstrap a jammy domU01:58
ChmEarlsince jammy has zstd built into dpkg, but Bullseye does not01:59
blahdeblahI guess this accelerates my plans to move from Xen to KVM on my VM host. :-)02:00
ChmEarlblahdeblah, I'm in xen-4.16.2 with qemu-7 on Bullseye now with Alma9 & Jammy VM's02:04
blahdeblahCustom-built xen packages?  Doesn't seem like there's a 4.15+ backport02:05
ChmEarland a focal VM has my buildroot for all Debian/Ubuntu builds02:05
ChmEarlhttp://199.249.188.45/xen/debian/bullseye-nmu/4gx-q7/setup/xl-info-deb11.multi02:06
ChmEarlblahdeblah, if you need to debootstrap Jammy, do it from a Focal VM02:11
=== pizzaiolo is now known as pizza
=== schopin_ is now known as schopin
=== Droid is now known as Maik
=== ginggs_ is now known as ginggs
=== kdas_ is now known as kushal
JornSI've got an issue on a box with two nic's, one with a public ip and one private ip. Both are configured for static ip's using netplan, but the internal one only replies to pings form the same subnet - assuming I'll need to add routing manually? config similar to this one (just sanitized the ips) https://pastebin.com/x8s8k9g4 If I remove the enp12s013:27
JornSconfig, enp1s0 works and replies just fine 13:27
ahasenackJornS: have you set ip_forwarding to 1? That's /proc/sys/net/ipv4/ip_forward13:47
JornSshould I? the box shouldn't route, fw or nat anything, I'm just trying to have it listen to two distinct networks and reply to traffic from them? I'm guessing that the server is sending the ping replies out over the public interface instead of just using the same it received the ping on...13:50
JornShaha, echoing 1 to ip_forward makes it send every other response on that nic13:53
JornShttps://pastebin.com/C4rckX0T13:54
ahasenackI misunderstood your diagnostic then13:54
ahasenackdiagnosis13:54
ahasenackyou said the internal one only replied to pings on the same subnet13:54
ahasenackwhich is expected if routing isn't being done13:55
JornSyes, indeed13:55
diddledani<troll> perhaps we should petition for sshd to drop it's `d` because with this change it's not a daemon anymore, just a server that spins up and shuts down on request: https://discourse.ubuntu.com/t/sshd-now-uses-socket-based-activation-ubuntu-22-10-and-later/30189/5 </troll> 🤪13:56
ahasenackI there is even an alias, so both ssh and sshd works from a systemctl perspective13:57
diddledaninice13:57
diddledani(I actually think it's a good idea to make the change)13:57
diddledanilet systemd borg everything ;-)13:58
ahasenackI dislike the fact that /etc/ssh/sshd_config no longer controls the port number, for example13:58
ahasenackit can be very confusing13:58
ahasenackyou edit that file, issue your normal restart, but the port it's listening on doesn't change13:58
diddledaniyes, that's a bit of a pain - what we need is for systemd to allow a helper script to parse things like that out of pre-existing disperate configuration files to allow for fallback if a system is old or the admin hasn't heard about the changes and is now confused how to configure it13:59
ahasenackanother systemd feature is needed, you say? :)14:00
diddledaniyes, yes I do ;-p14:01
diddledaniI, for once, welcome our new programmatic overlords14:01
diddledanione*14:01
diddledanialthough getting it going in WSL2 was a pain, as was getting it going in docker containers14:02
sdezielJornS: you have 2 gateway4 clauses which could explain the round robin routing behavior I think14:06
JornSyeah, I just tried adding routes to the netplan config instead, seems netplan isn't too happy about gateway4 clauses at all :P14:07
JornS"`gateway4` has been deprecated, use default routes instead. See the 'Default routes' section of the documentation for more details."14:07
JornS(awesome that netplan.io is updated and current in it's suggestions /s )14:08
ahasenackyesterday I lost access to a VM because I had an indentation error in the netplan file14:08
ahasenacktwo spaces were all it took to force me to do some acrobatics and get back into the vm14:08
sdezielahasenack: I hear you... there is `netplan try` that can be handy sometimes14:09
JornSyeah.. like, I understand the need to modernize network config, but yaml...14:09
JornSlol14:09
JornSoh well, thanks anyway :)14:09
ahasenacksdeziel: I thought I had run `generate` first14:09
ahasenackif I did, and it failed, I didn't see it14:09
ahasenackI then rebooted14:09
ahasenackand kaput14:09
sdezielJornS: yeah, `gateway4` and `gateway6` are deprecated but that's what Jammy's installed put in the file...14:10
sdezielahasenack: `netplan generate` and `netplan try` fail very differently on indentation error, that is despite the fact that `try` is supposed to call `generate` behind the scene...14:13
ahasenackreally?14:14
sdezielahasenack: that said, `generate` only translate the YAML into systemd-networkd *ephemeral* configs so if you missed the reported error and rebooted it was too late14:15
ahasenackyes14:15
ahasenackI probably just missed the error14:15
ahasenackI reproduced it now, and generate does fail:14:15
sdezielahasenack: `generate` vs `try` output: https://termbin.com/dxzj14:15
ahasenackI rarely use `try`, just the generate + apply combo14:16
ahasenackI was using netplan to configure wireguard, and found two bugs already14:31
ahasenackso I don't really see any advantage in using netplan14:31
ahasenackunless for some readon you cannot install wireguard-tools14:31
ahasenackhttps://bugs.launchpad.net/netplan/+bug/198784214:31
ubottuLaunchpad bug 1987842 in netplan "wireguard: netdev file can leak private key" [Undecided, New]14:31
ahasenackhttps://bugs.launchpad.net/netplan/+bug/198734314:31
ubottuLaunchpad bug 1987343 in netplan "wireguard: Missing routes for AllowedIPs" [Wishlist, Triaged]14:31
ahasenackthis latter one is probably more on systemd-networkd's shoulders, but netplan could still add the routes itself14:32
ahasenackat least the behavior is documented on systemd-networkd's manpage14:32
ahasenackso its user (netplan in this case) should add the missing routes I think14:33
ahasenacks/user/consumer/14:33
JornS>:/14:34
JornStried redoing the config with routes - to, same issue as far as I can tell: https://pastebin.com/d3BtYy1f14:34
JornS(I'm more than willing to learn how-to-netplan, but it seems pretty... yolo so far :P)14:35
sdezielJornS: can you describe the issue again (sorry) because the paste you shared looks good to me14:38
sdezielJornS: the only thing that caught my attention is the private NIC uses a /24 but a /16 route. Not an issue per say but maybe a typo?14:39
JornShmm.. good point, I'll see if changing that makes any difference!14:39
JornSI've got two interfaces, enp1s0 (private net) and enp12s0 (public internet). as soon as I add the public interface, the private one stops responding to ping/traffic from routed networks on the private one (my servers in the same subnet can still ping the private ip, but I'm unable of getting any replies over my wg-interface in subnets "surrounding"14:42
JornSit...14:42
sdezielJornS: that wg-interface doesn't show in the `ip a`, ... output in the paste making it harder to understand14:47
JornSthe wg-interface is on my local machine, not the server :P14:48
sdezielJornS: and what's the source IP address of packets showing up at the server?14:50
sdezielJornS: when you ping over Wireguard that is14:50
JornS14:53:08.017245 IP 10.249.137.8 > logingest.domain.tld: ICMP echo request, id 5, seq 6, length 6414:54
sdezielJornS: OK so 10.249.137.8 falls outside of 10.29.32.0/24 so it will be routed through 10.29.32.1. You can confirm by running this on the server: `ip route get 10.249.137.8`14:56
sdezielJornS: if `ip route get` confirms this, the question is then: can 10.29.32.1 reach 10.249.137.8 ?14:57
JornSthat gave me: 10.249.137.8 dev enp1s0 src 10.29.32.104 uid 0 14:57
JornS    cache 14:57
JornS104 is the ip of the server itself, not the gw14:57
sdezielyeah, I'm working with an old paste though where a /16 route was in place. Would you mind pasting the newer version with `ip` commands and the netplan conf?14:58
JornSsure!14:58
JornStwo secs14:58
JornShttps://pastebin.com/eRmSBWSN15:01
sdezielJornS: OK so that explains why the kernel wants to do a direct reply not route anything15:03
JornSok?15:04
sdezielJornS: in your tcpdump, do you see an `ICMP echo reply`?15:04
JornSnope15:06
sdezielJornS: is there a firewall on the server?15:06
JornSnot that I'm aware of at least... this is a plain ubuntu server install, so I don't think there's any ufw or anything like that running15:07
sdezielJornS: hang on, the `ip r` shows a route for 10.249.0.0/16 but that's not coming from netplan15:08
sdezieland the 10.29.0.0/16 that should be there is missing15:08
JornSthanks!15:25
JornSI'll try to figure that out15:25
=== justDeez is now known as justache
mybalzitch  System load:                      6.2397460937520:30
sdeziel  that's almost 2Ï€20:44
ahasenackthere's a bug for that20:55
ahasenackhm, maybe it was just someone mentioning it, I can't find a bug now20:58
znfIs anyone else seeing this on Ubuntu 22.04? https://pastie.dev/wi4WV9.yaml21:32
znfthis is a fresh deployment on Vultr21:32
znfbut I can reproduce it anywhere else with 22.04 21:33
znfwhat I'm hinting at is the "" "" "" "" "" crap 21:33
mybalzitchyep21:43
mybalzitchmines got a whole lot of that21:43
sdezielsame here, the worker processes has it21:53
tomreynthis looks like someone overdid it when some quoting related vulnerability needed to be fixed.23:20

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!