[03:34] A simple cp -Rv command on 20 files is taking longer than it should. What might this imply? We're talking < less than 10MB of files. [03:44] foo: How fast are the disks involved, and is one of the directories on a remote server and attached over the network? [03:44] I've had copies between my local system and an SFTP directory to be painfully slow. [03:45] Though I'm using a connection with a rather slow upload speed and uploading to a remote server over the Internet. [04:31] arraybolt3: this is on a digital ocean droplet on a production server. All files are local to the VM. [04:31] arraybolt3: what's odd is everything else seems ok, just the copying of files that causes an issue [04:31] I don't see any network delays during this time but am paying attention to that too [04:36] how many files is also important; "less than 10 MiB" could in theory be a million or more tiny/empty files/directories :) [04:39] also, the -v could be causing the slowness too [04:39] especially if there are many files [13:33] bryyce: have you looked at the autopkgtest failure in bug 1986521? [13:33] -ubottu:#ubuntu-server- Bug 1986521 in openssh (Ubuntu Jammy) "ssh client spins if output fd closed" [Medium, Fix Committed] https://launchpad.net/bugs/1986521 [13:50] no [13:52] hg-git and xen-tools. hmm [13:58] @rbasak xen-tools might just be flaky. retriggered it. Not sure on hg-git but for now retriggered those too. I'll check back later. [14:22] Thanks! [14:38] hiya. there seems to be an issue with the image create by xen-create-image --dist=bullseye. when loading the created domu with xl create /etc/xen/.cfg, it bootloops. if i use the console to get on, i can see that it gets to pygrub, but if i try to edit the kernel options, it errors with an 'unable to find partition containing kernel' (i can paste the whole traceback on pastebin if youd like), [14:38] and if i hit enter or wait for the timeout, it crashes silently. [14:38] the same xen-create-image line differing only by --dist=buster works fine upon load. [14:38] (as a sidenote, the /usr/share/xen-tools/debian.d/20-setup-apt file is missing instructions for bullseye, but even adding them does not fix the issue.) [14:38] i have full straces for the creation and load of both buster and bullseye images, if that would be helpful. [15:06] elflng: https://bugs.launchpad.net/ubuntu/+source/xen/+bug/1956166 maybe this is related? [15:06] -ubottu:#ubuntu-server- Launchpad bug 1956166 in xen (Ubuntu Kinetic) "Ubuntu 22.04 doesn't boot with xen" [Medium, Fix Released] [15:08] i dont think Ubuntu spends a lot of time on Xen anymore. I moved on to lxf a long time ago too :) [15:10] lxf ? did i miss two iterations ? 😄 [15:11] :D === elastic_dog is now known as Guest3137 [16:23] Let me know if I need to RTFM harder or use a search engine better. Can't find an obvious answer. Removing a CA cert is easy enough - plop in /usr/local/share/ca-certificates/ and update-ca-certificates. But how do I *remove* a CA certificate? Is it as simple as removing the two symlinks in /etc/ssl/certs ? [16:25] a help https://ubuntu.com/server/docs/security-trust-store [16:25] Correction to third sentence should have read "Adding a CA cert is easy enough" [16:26] https://ubuntu.com/server/docs/security-certificates [16:26] oerheks, neither of those describe how to remove the trust of a CA [16:28] radix0: I think you need to edit `/etc/ca-certificates.conf` and prefix those you do not trust with a `!` [16:29] radix0: then run `sudo update-ca-certificates` [16:58] sdeziel, I looked at that file but mine did not show up there. I just removed the two links and rebooted and it *seems* to have had the desired effect. It's just weird this isn't obvious/documented. [16:59] chatgpt also gave me a hint of grepping the /etc/ssl/cert/ca-certificates.crt file which is how I confirmed that the CA was no longer trusted. [17:02] radix0: removing the links risks having them recreated by the next run of `update-ca-certificates`, no? [17:10] Starting working at the commune with Ubuntu stuff on Friday this week :) [18:28] sdeziel, I neglected to mention that I removed the cert from the /usr/local/share directory [18:38] radix0: I think dpkg-reconfigure on the ca-certificates package does what you want [18:39] if you wnat an easy way to check/uncheck certificates [18:39] I'm not familiar with dpkg operations. I'll have to check that out later. Does it bring up a TUI or something? [18:41] yeah, a curses TUI that allows you to select if new certificates should be added automatically (yes/no/ask) and allows you to check/uncheck individual certs from the package [18:42] intriguing. thanks. [18:42] I assume it basically does what sdeziel says (edit that .conf & then run the update script) [18:43] radix0: ah, I assumed you wanted to remove one of the packaged-shipped CA. If you want to remove a custom one (in /usr/local/share/...), removing the file in question and running `sudo update-ca-certificates` should do [18:44] radix0: but if you removed the file and the symlink, you've probably essentially did what `update-ca-certificates` would have done for you [18:47] ah, right, when it's a custom cert; not sure if dpkg-reconfigure would handle that :) [19:46] sdeziel, see I thought removing the cert first from /usr/local/share + update-ca-certificates would do it, but in terms of CRUD that's only a CRU operation me thinks. Not that I know what I'm talking about lol [23:16] hey bryyce, I forgot to mention: pg-snakeoil tests just needed to be re-triggered for clamav (after pg-15 migrated) [23:16] they are green now [23:17] clamav should migrate soon [23:17] also, thanks for the php7.4 review ;) [23:25] sergiodj: The new postgis build should unblock the remaining issues with pg-common now. Thanks for the review [23:40] athos, ok great, thanks for looking at it! [23:46] athos: +1