[00:04] <blahdeblah> rfm: thanks
[01:46] <ChmEarl> blahdeblah, you need dom0 at xen-4.15.x or higher to handle zstd compressed kernels like in Jammy or any Fedora 34+
[01:58] <blahdeblah> ChmEarl: Yeah, seems that way.  Which means a jammy domU on a Debian bullseye dom0 is no-go.
[01:58] <ChmEarl> blahdeblah, wait till you try and debootstrap a jammy domU
[01:59] <ChmEarl> since jammy has zstd built into dpkg, but Bullseye does not
[02:00] <blahdeblah> I guess this accelerates my plans to move from Xen to KVM on my VM host. :-)
[02:04] <ChmEarl> blahdeblah, I'm in xen-4.16.2 with qemu-7 on Bullseye now with Alma9 & Jammy VM's
[02:05] <blahdeblah> Custom-built xen packages?  Doesn't seem like there's a 4.15+ backport
[02:05] <ChmEarl> and a focal VM has my buildroot for all Debian/Ubuntu builds
[02:06] <ChmEarl> http://199.249.188.45/xen/debian/bullseye-nmu/4gx-q7/setup/xl-info-deb11.multi
[02:11] <ChmEarl> blahdeblah, if you need to debootstrap Jammy, do it from a Focal VM
[13:27] <JornS> I'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 enp12s0
[13:27] <JornS> config, enp1s0 works and replies just fine 
[13:47] <ahasenack> JornS: have you set ip_forwarding to 1? That's /proc/sys/net/ipv4/ip_forward
[13:50] <JornS> should 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:53] <JornS> haha, echoing 1 to ip_forward makes it send every other response on that nic
[13:54] <JornS> https://pastebin.com/C4rckX0T
[13:54] <ahasenack> I misunderstood your diagnostic then
[13:54] <ahasenack> diagnosis
[13:54] <ahasenack> you said the internal one only replied to pings on the same subnet
[13:55] <ahasenack> which is expected if routing isn't being done
[13:55] <JornS> yes, indeed
 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:57] <ahasenack> I there is even an alias, so both ssh and sshd works from a systemctl perspective
[13:57] <diddledani> nice
[13:57] <diddledani> (I actually think it's a good idea to make the change)
[13:58] <diddledani> let systemd borg everything ;-)
[13:58] <ahasenack> I dislike the fact that /etc/ssh/sshd_config no longer controls the port number, for example
[13:58] <ahasenack> it can be very confusing
[13:58] <ahasenack> you edit that file, issue your normal restart, but the port it's listening on doesn't change
[13:59] <diddledani> yes, 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 it
[14:00] <ahasenack> another systemd feature is needed, you say? :)
[14:01] <diddledani> yes, yes I do ;-p
[14:01] <diddledani> I, for once, welcome our new programmatic overlords
[14:01] <diddledani> one*
[14:02] <diddledani> although getting it going in WSL2 was a pain, as was getting it going in docker containers
[14:06] <sdeziel> JornS: you have 2 gateway4 clauses which could explain the round robin routing behavior I think
[14:07] <JornS> yeah, I just tried adding routes to the netplan config instead, seems netplan isn't too happy about gateway4 clauses at all :P
[14:07] <JornS> "`gateway4` has been deprecated, use default routes instead. See the 'Default routes' section of the documentation for more details."
[14:08] <JornS> (awesome that netplan.io is updated and current in it's suggestions /s )
[14:08] <ahasenack> yesterday I lost access to a VM because I had an indentation error in the netplan file
[14:08] <ahasenack> two spaces were all it took to force me to do some acrobatics and get back into the vm
[14:09] <sdeziel> ahasenack: I hear you... there is `netplan try` that can be handy sometimes
[14:09] <JornS> yeah.. like, I understand the need to modernize network config, but yaml...
[14:09] <JornS> lol
[14:09] <JornS> oh well, thanks anyway :)
[14:09] <ahasenack> sdeziel: I thought I had run `generate` first
[14:09] <ahasenack> if I did, and it failed, I didn't see it
[14:09] <ahasenack> I then rebooted
[14:09] <ahasenack> and kaput
[14:10] <sdeziel> JornS: yeah, `gateway4` and `gateway6` are deprecated but that's what Jammy's installed put in the file...
[14:13] <sdeziel> ahasenack: `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:14] <ahasenack> really?
[14:15] <sdeziel> ahasenack: that said, `generate` only translate the YAML into systemd-networkd *ephemeral* configs so if you missed the reported error and rebooted it was too late
[14:15] <ahasenack> yes
[14:15] <ahasenack> I probably just missed the error
[14:15] <ahasenack> I reproduced it now, and generate does fail:
[14:15] <sdeziel> ahasenack: `generate` vs `try` output: https://termbin.com/dxzj
[14:16] <ahasenack> I rarely use `try`, just the generate + apply combo
[14:31] <ahasenack> I was using netplan to configure wireguard, and found two bugs already
[14:31] <ahasenack> so I don't really see any advantage in using netplan
[14:31] <ahasenack> unless for some readon you cannot install wireguard-tools
[14:31] <ahasenack> https://bugs.launchpad.net/netplan/+bug/1987842
[14:31] <ahasenack> https://bugs.launchpad.net/netplan/+bug/1987343
[14:32] <ahasenack> this latter one is probably more on systemd-networkd's shoulders, but netplan could still add the routes itself
[14:32] <ahasenack> at least the behavior is documented on systemd-networkd's manpage
[14:33] <ahasenack> so its user (netplan in this case) should add the missing routes I think
[14:33] <ahasenack> s/user/consumer/
[14:34] <JornS> >:/
[14:34] <JornS> tried redoing the config with routes - to, same issue as far as I can tell: https://pastebin.com/d3BtYy1f
[14:35] <JornS> (I'm more than willing to learn how-to-netplan, but it seems pretty... yolo so far :P)
[14:38] <sdeziel> JornS: can you describe the issue again (sorry) because the paste you shared looks good to me
[14:39] <sdeziel> JornS: 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] <JornS> hmm.. good point, I'll see if changing that makes any difference!
[14:42] <JornS> I'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] <JornS> it...
[14:47] <sdeziel> JornS: that wg-interface doesn't show in the `ip a`, ... output in the paste making it harder to understand
[14:48] <JornS> the wg-interface is on my local machine, not the server :P
[14:50] <sdeziel> JornS: and what's the source IP address of packets showing up at the server?
[14:50] <sdeziel> JornS: when you ping over Wireguard that is
[14:54] <JornS> 14:53:08.017245 IP 10.249.137.8 > logingest.domain.tld: ICMP echo request, id 5, seq 6, length 64
[14:56] <sdeziel> JornS: 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:57] <sdeziel> JornS: if `ip route get` confirms this, the question is then: can 10.29.32.1 reach 10.249.137.8 ?
[14:57] <JornS> that gave me: 10.249.137.8 dev enp1s0 src 10.29.32.104 uid 0 
[14:57] <JornS>     cache 
[14:57] <JornS> 104 is the ip of the server itself, not the gw
[14:58] <sdeziel> yeah, 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] <JornS> sure!
[14:58] <JornS> two secs
[15:01] <JornS> https://pastebin.com/eRmSBWSN
[15:03] <sdeziel> JornS: OK so that explains why the kernel wants to do a direct reply not route anything
[15:04] <JornS> ok?
[15:04] <sdeziel> JornS: in your tcpdump, do you see an `ICMP echo reply`?
[15:06] <JornS> nope
[15:06] <sdeziel> JornS: is there a firewall on the server?
[15:07] <JornS> not 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 running
[15:08] <sdeziel> JornS: hang on, the `ip r` shows a route for 10.249.0.0/16 but that's not coming from netplan
[15:08] <sdeziel> and the 10.29.0.0/16 that should be there is missing
[15:25] <JornS> thanks!
[15:25] <JornS> I'll try to figure that out
[20:30] <mybalzitch>   System load:                      6.23974609375
[20:44] <sdeziel>   that's almost 2π
[20:55] <ahasenack> there's a bug for that
[20:58] <ahasenack> hm, maybe it was just someone mentioning it, I can't find a bug now
[21:32] <znf> Is anyone else seeing this on Ubuntu 22.04? https://pastie.dev/wi4WV9.yaml
[21:32] <znf> this is a fresh deployment on Vultr
[21:33] <znf> but I can reproduce it anywhere else with 22.04 
[21:33] <znf> what I'm hinting at is the "" "" "" "" "" crap 
[21:43] <mybalzitch> yep
[21:43] <mybalzitch> mines got a whole lot of that
[21:53] <sdeziel> same here, the worker processes has it
[23:20] <tomreyn> this looks like someone overdid it when some quoting related vulnerability needed to be fixed.