[02:19] Is there a way to install the "Ubuntu Server (minimized)" option via autoinstall? Using the yaml config generated with autoinstall installs the standard "Ubuntu Server" option. [02:22] ^^ this is me trying to automated via pxe install. === DArqueBish0p is now known as DArqueBishop [14:22] waveform: hi, I suspect you might have an armhf host at hand, with an ubuntu install? If yes, could you check what ls -lad /usr/lib/*-linux-gnu/ returns please? [14:22] my pi3 with raspbian doesn't have that directory [14:23] ahasenack, sure -- just a mo [14:23] ahasenack, ls: cannot access '/usr/lib/*-linux-gnu/': No such file or directory [14:23] hmm [14:24] is that running jammy, kinetic, or what? [14:24] there is /usr/lib/arm-linux-gnueabihf [14:24] jammyu [14:24] jammy even :) [14:24] gnueabihf? Did your cat approach the keyboard, or is that really the name? [14:24] abi hard float? [14:24] no, that's really the name :) [14:25] and yes hard-float variant of the ARM ABI [14:25] could I persuade you to install samba there (and remove later), and check if that directory shows up? [14:26] I'm specifically looking for the armhf version of /usr/lib/x86_64-linux-gnu/samba/samba-bgqd [14:27] actually I think that box already has samba installed ... let me just check ... [14:27] oh, no it doesn't -- just cifs-utils [14:27] the client-side bit [14:29] just a mo -- I'll spin up a fresh armhf card and stuff it in another pi (don't particularly want to mess with that pi as it runs a ton of monitoring stuff in the loft!) [14:29] sure, thanks [14:29] armhf is annoying to get, arm64 is much easier [14:30] indeed -- oh, actually, just a mo -- I can just do this in a container on my main dev pi (which runs arm64 but is happy spinning up armhf lxd containers) [14:30] its cpu allows that? [14:31] let me check if mine does too [14:31] well ... it works, put it that way :) [14:31] I thought you need a cpu which supported 32bit emulation [14:31] and not many apparently do [14:31] (I use it all the time for building armhf test packages / debugging armhf bits that don't require kernel stuff) [14:31] ah, kernel stuff [14:31] that's the thing that just a few cpus have [14:32] yeah, it's still running on an arm64 kernel so it's no use for debugging armhf kernel stuff -- need to reboot into a separate image for that (or try full VMs but there's not much doing that on a pi -- faster to just flash a card) [14:35] ahasenack, from the samba installation in an armhf container: everything's still under /usr/lib/arm-linux-gnueabihf [14:35] ok, thanks a lot [14:35] no prob [14:35] looks like the @{multiarch} macro in apparmor won't work for armhf then [14:35] as it defines just *-linux-gnu [14:36] oh, wait [14:36] I missed another star [14:36] @{multiarch}=*-linux-gnu* [14:36] hmmm, that *ought* to be okay [14:53] @rbasak, thanks for the review on ubuntu-advantage-tools 27.10. I have removed the ca-certificates dependency from the PR and answered the other points you made about the release. Let me know if there are any points that need clarification for this release [15:31] Hi there, how to prevent netscan on a dedicated server? [15:31] so users having nat vps on it cannot attempt to do netscan [15:34] https://i.imgur.com/xtlOiPz.png [15:37] PSAD can do a good job, https://www.unixmen.com/how-to-block-port-scan-attacks-with-psad-on-ubuntu-debian/ [15:54] oerheks, thanks! i'll test. === JanC_ is now known as JanC === oerheks1 is now known as oerheks === leftyfb_ is now known as leftyfb === Kamilion|ZNC is now known as Kamilion === Thumpxr6 is now known as Thumpxr === NightMonkey_ is now known as NightMonkey [22:58] I have gathered some extra benchmarks to see where my degraded php/redis comes from and I tried on bcc-tools' runqlat program on a couple of identical vm's running Ubuntu 18.04/20.04 with stock and HWE kernel versions: https://pastebin.com/3zg41QAn (simple php redis set benchmark) https://pastebin.com/Gm3pSKc2 (results) [23:00] I also included results from Debian 11 with 5.18 from backports, this combo is so much faster than all Ubuntu/kernel combo's :( [23:09] I wonder if we could isolate those... possibly starting with verifying if these is seen with either redis (in other environments?) or php (no redis). Then checking which specific codepaths are causing the delays... sth similar to what we did with that other php performance issue mentioned here [23:09] arthurvk: it would be nice if you could file a bug with your nice findings so far (thanks btw)