00:32:49 What are you standard use cases for rsync? Drew DeVault propose tar instead: . 00:33:35 Also, is there no possiblity to keep using the latest non-slop version for a while? 00:42:25 ant-x: Nice thing about OpenRsync is it's BSD licensed. 00:46:04 The only reason OpenRsync exists is to change licenses for OpenBSD. https://github.com/kristapsdz/openrsync 00:46:40 And it accomplishes that nicely. 00:47:10 rsync is one of my examples that I use to show a project which never said no to an option-feature. They have more options than ls! 00:49:58 If rsync is now on the AI Slop train (https://social.hails.org/@hailey/116657391001259044) it does not bode well for it. Might be time to switch to OpenRsync for stability. 00:51:17 hi all, I have a pkgbase jail on 15.1-STABLE and within the jail I cannot get a result for ps which returns ps: /boot/kernel/kernel: No such file or directory. This does not happen on another 15.0-RELEASE jail. Any suggestions? 00:52:07 Sounds like a regression in ps. Jails do not normally have a kernel at all. 00:54:16 yes, there is a thread here https://forums.freebsd.org/threads/why-does-a-jailed-ps-1-suddenly-require-a-kernel-to-be-present-and-then-complain-when-it-is.102485/ that indicates the same, but their discussion was not conclusive 00:56:58 yelnah, Thank you for running the prerelease and finding this bug before release. If it does not have a PR problem report then that would be good. Maybe it can be fixed before release and it hitting a lot of people. 00:58:17 Looking at that thread it is reported that known working previous versions of ps also fail. That indicates to me that the problem is either a library that is called or a kernel system call which has changed behavior. 01:45:15 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295782 I don't often report non-port bugs so let me know if that needs more 01:57:35 Seems like a good enough PR to me. 02:08:08 Just read the Drew DeVault's blog posting saying that tar options are "hard to remember how to use". 02:08:12 Huh? The options to tar are extremely basic and simple. 02:08:17 c to create, t for table of contents, x for extract. Add v for verbose. Use f for file to read or file to write. 02:08:22 That's really all that one ever needs to know about tar. How hard is that? 02:10:54 rwp: -C is also useful. my experience is that when people struggle with tar options, it's more about the order of the options. i'm not sure why that is though 02:14:24 Traditionally instead of <> we would <<( cd /usr/src && tar xvf foo.tar.gz )>> and so the -C option is not ever really needed. 02:15:04 I mixed my metaphors there but I am sure you know what I meant to say there. 02:15:36 Same thing for the same reason about make -C too. 02:32:27 https://opensource.org/blog/open-source-organizations-weigh-in-on-age-attestation 02:34:10 but it doesnt really say much? 02:37:04 elivoncoder: it says plenty, just may not say what you wanted to hear 02:42:06 elivoncoder: yeah, i thought it was pretty weak compared to what e.g. EFF have published. 02:47:34 not sure that's a fair comparison. it's literally the kind of stuff EFF deals with, and EFF doesn't have an actual product they maintain, so their position is very different 02:49:55 well, technically the freebsd foundation doesn't have a project, their entire job is advocacy (and paying people to work on freebsd) 02:50:15 s/project/product 02:56:38 sure, but their core goal is to support the freebsd project. treading lightly is to be expected 03:46:49 Hello all, does anyone have any experience with cbsd? I've somehow managed to kill all of my jails, they all fail to start after updating my system to FreeBSD 14.4 and trying to update them to the same version. I get "/bin/sh: cannot open /etc/rc: No such file or directory\njail: unifi: /bin/sh /etc/rc: failed" when I try to start any of them 03:51:52 Things started to go wrong when I changed the version for my jails, amd it asked me to choose a source for the base (I think), I chose to use the current system but then ^C's it in the middle after decided I'd use the repo option like I have in the past. I hoped it'd ask me again when I tried to start the jail again, but it just failed. I've been looking for ways to try and fix the base, and thought I had fixed it by using cbsd repo action=get sources=base and 03:51:52 it seemingly installing a bunch of files, but they're still all broken. 03:52:18 I've also tried setting the version back to 14.3, but they also fail despite previously working 04:01:35 Since the first error is about /bin/sh: cannot open /etc/rc I would start there and look in the jail and see if /etc/rc is there or missing. I expect it is missing. 04:02:02 Then I would look at a backup or snapshot where the file was there and probably restore to that previously working version. Because apparently something removed a bunch of files. 04:06:53 I'm not sure how to look in the jail 04:07:50 Axman6: It might be worth using straight system tools for your jails. It's important to understand how they're put together. 04:08:28 I use ls. For me I locate jails at /jails and named after the jail name. So for example an nginx jail is located at /jails/nginx. Therefore /etc/rc is located at /jails/nginx/etc/rc so I would look at it with ls -l /jails/nginx/etc/rc and also just the rest ls -l /jails/nginx/etc/ too. 04:08:29 There are zfs snapshots for the various datasets but I'm not sure what would need to rolled back (and they're use read only bases, which I assume means they're shared) 04:08:41 mason: that would have been good advice in the past 04:10:40 If you have a previous snapshot you can rollback to that previous snapshot using the zfs-rollback command. For example zfs rollback zroot/jails/nginx@2026-04-30-1 for me would cause the dataset to return to that data discarding what had happened since (assuming I don't have the recent stuff in another snapshot). 04:11:01 Hmm, ok interesting, looking in /etc of one of the jails, there is indeed no /etc/rc; there is a /etc/rc.resume though; would that have been created by something like etcupdate? 04:11:46 Hmm... I don't know about .resume files. I haven't dealt with them before. So probably. But no idea. 04:21:15 ok, looks like it was a botched etcupdate 04:29:30 Things that I put into jails I pretty much know what goes into them. The theory goes that I would simply create a new jail and then copy the configuration forward to the new jail start it up and discard the old one. 08:34:28 hm... so the new "pass ... nat-to" in pf.conf is quite nice, except it seems that it changes the semantics of outgoing packets. previously you could do something like "nat on $inet_if inet from 198.18.0.0/23 to any -> 1.2.3.4/32" and later rules would see the packet as coming from 1.2.3.4 08:35:18 now if you do "pass out on $inet_if from 198.18.0.0/23 to any nat-to 1.2.3.4/32", and later you have a rule "block out on $inet_if inet from 198.18.0.0/23 to any", it will block the NAT'd traffic 08:35:53 which is annoying because i like to block egress traffic from obviously invalid addresses 08:51:40 ivy: can you use tags? 09:28:38 lts: ah yes, that seems to work, thanks 09:28:52 "pass out ... tag NAT nat-to ...", "block out ... !tagged NAT" 09:31:40 Awesome 09:54:55 Hi! 09:59:04 How high :-? 10:04:35 No. 10:59:14 Since many members run their web- and other hosts on FreeBSD, I hope my question is not OT: Does /Let's Encrypt/ support a manual procedure for certificate generation and renewal, or is the ACME API the only way of using that service? 10:59:47 Also, is automation (e.g. via ACME) that important for managing a single certificate for a single domain? 11:11:23 ant-x: they only support ACME, and since they only issue short-lived certificates (i think 3 months currently, probably moving to 30 days later) you really wouldn't want to do it manually 11:30:37 I could tolerate 90 days, but not a month. OK. Why do you think they are decreasing certificate lifetime? 11:31:31 I don't understand anything about this procedure, am using a self-singned cert right now, so I just wanted to start with the basics. Now it seems I'll need an ACME client from the start. 11:32:17 because it reduces the impact of leaked certificates or existing certificates for expired / reallocated domains, and it encourages people to use automation instead of an error-prone manual process 11:39:48 why is a month so bad? You basically write a shell script and put that into cron. 11:50:45 You assume Internet connectivity 11:51:55 if you don't have Internet connectivity, you shouldn't be using Let's Encrypt, because you won't be able to access the CRL or (for some providers) OCSP server 11:52:54 I meant bad for the manual process. With ACME, I probably must invoke an ACME client regularly, and then signal my stunnel to load the updated certificate. 11:53:27 So far, I assume internet connectivity. 15:01:28 LetsEncrypt does 90-day certs (on my side at least). 15:03:38 I think that's what I have for my internal-only wildcard cert 15:08:14 ant-x: I have a single domain with a few subdomains, but if all I had was one domain I'd keep using LE. Renewing a certificate once a year or whatever is always error-prone and caused outages at my job regularly 15:11:33 hodapp, Why use LE for internal certs? 15:12:16 ant-x: because I have devices that are pissy and annoying if you try to use TLS with self-signed certs or those signed with custom CAs 15:12:27 and it's so much simpler to just get "proper" certs 15:12:30 wavefunction, thanks. I have considered (which supports manual workflow), but their own certificate is obsolette! 15:13:43 Look like I will appeal to your help with setting up automation with acme-client. As far as I understand, one has regularly to run it and then to signal the services to reload the cert files. 15:56:37 ant-x: Depends entirely on how you want to authenticate and do stuff. I can shift this to DMs. 17:02:37 i have some odd behaivour with wireguard. im creating a wireguard interface and setting it to fib 1, because i only want to route specific processes to it, not all. it SEEMS to be working fine initially, but i get some absurd packet loss. pinging 1.1.1.1 20 times gives 60% packet loss one time, 40% the other, etc. running speedtest-go also gives about 55% packet loss, although the actual throughput is not horrible. im really unsure what i'm doing wrong, if anythi 17:02:37 ng. here's a paste with more info if needed: https://paste.c-net.org/PicklesConrad 17:06:37 hmjsp: What MTU size do you use? 17:06:49 Is it different between locations? 17:07:16 skered: 1420, trying 1380 didn't help at all. it is between different locations, yes 17:07:49 I forget what I had to drop min to to make it work at some different places. 17:08:06 If you go lower you still have issues? 17:08:26 But if it's the same thing, pings, then MTU might not be the problem. 17:08:47 For me it was ping/ssh small payload size was fine. 17:08:58 But when you tried something larger (scp) is when it failed 17:09:09 But it was also depending where I was at. 17:09:21 dropped mtu to 1280, still get 50% packet loss 17:09:25 should i go lower? 17:09:40 If it's all pings then it shouldn't be an MTU issue. 17:09:48 50% packet loss on ping that is 17:10:14 what else could it be? i rotated a couple different server configs from the vpn provider, same issue 17:11:22 Ditto with my issues. OpenVPN did the samething but like I said it was only when you tried to use larger packets that you overflowed with the overhead. 17:12:03 Any chance you're behind some load balancer? server or client side 17:12:30 not that i know of, certainly not client side 17:12:44 just a regular router, and a pc connected to it via ethernet 17:12:48 You try running mtr ? 17:13:05 Might help to see where it's dropping. 17:13:12 incidentally this exact same issue happened with an old router, and i recently replaced it (faster wifi) and it's the same issue, so it's defo not the router or anything 17:13:14 what's mtr? 17:13:22 mtr is ping plus traceroute in one interface. 17:13:35 okok i'll see 17:17:52 skered: https://paste.c-net.org/CurseKarate 17:19:36 So you only have one hop between you and the endpoint? 17:21:01 no... sorry i didn't wanna post all ip addresses but ig it doesn't matter... give me a sec 17:21:46 Well if it's all 0s and loss is at the end then it shouldn't matter. 17:22:29 here it is now: https://paste.c-net.org/SenateProstate 17:22:47 very silly randomly generated paste name xD 17:44:38 anyone use the kde install script on 15.1? 17:45:22 did you initially get a login loop with wayland? 17:50:42 skered: it SEEMS it's just vpn provider having too high load? kept trying different servers, and on the last server i tried i finally got 0% packet loss 17:53:02 Might be if you're first hop is losing stuff then that's not a good sign. 18:06:04 ugh nvm back to 50% packet loss 18:06:17 im 80% sure it's just vpn provider being dodgy 18:14:15 hmjsp: Easy way to tell is to disable the VPN and test real quick. 18:14:42 But, it looks to me like you're getting loss between you and the immediate router/gateway. That's a problem. 18:15:55 Ideally you would let that mtr run for more than 20 seconds. Maybe all day. 18:15:59 Or at least an hour. 18:17:24 I usually let it run a while. Especially the entire duration of the troubleshooting. 18:17:55 I'm trying to wrap my head around the loss to 192.168.1.1 or 10.2.0.1, though. 18:18:17 * iRobbery doesnt dare to click on anything labelled 'senate prostate' 18:18:45 iRobbery: Haha. I noticed that as well and chuckled. 18:18:57 ek: but you did click? 18:19:18 iRobbery: You don't click it... it clicks you. 18:19:48 Of course! I don't worry about internet safety with this system. Worst that can happen is I see something grotesque or get Rickrolled or something. 18:19:49 Now i'm just terrified, but reading back on wg issue 18:19:55 👉[C😲 18:22:46 ek: traffic on my non vpn is fine. vpn is only on fib 1, fib 0 works great. but im just as confused as you about 192.168.1.1 losses 18:23:22 hmjsp: do you write now that you did try wg/vpn using fib0 too? 18:23:48 i have not tried it on fib0, i wouldn't be able to ssh if i did that (im sshing into this system) 18:24:03 hmm i see, no ipmi or something to fallback to? 18:24:03 i do have physical access but it's in an awkward place away from any display 18:24:14 nope, nothing 18:24:26 or not that i know of 18:24:29 it's asus h110t 18:25:04 Do you get this weird jitter value consistently too in your speedtest results? 18:25:58 lemme see 18:26:10 https://paste.c-net.org/CurseKarate your mtr is a bit short too? 18:26:36 or it is just that hop where packetloss occurs? 18:26:44 on fib0: Download: 525.18 Mbps (Used: 680.23MB) (Latency: 14ms Jitter: 6ms Min: 7ms Max: 32ms) 18:27:06 iRobbery: ignore that one, see the next one 18:27:16 https://paste.c-net.org/senateprostate 18:27:39 with fib1: Download: 344.46 Mbps (Used: 476.47MB) (Latency: 76ms Jitter: 31ms Min: 47ms Max: 140ms) 18:27:49 packet loss is back to 0% again... 18:28:18 aah it clicked me! *reading now* 18:28:45 90% sure it's just vpn provider, but idk. it's protonvpn, free tier, and i used protonvpn on a phone couple times and it was never horrible or laggy so im not sure 18:28:47 xD 18:31:05 if you wrote about this yesterday i still had some decomissioned metal online, but they janked it offline this morning 18:31:25 aww :( 18:31:54 sneaky bastards did 500 mbit cap unmentioned 18:32:16 lol 18:32:46 could i isolate the cause if i set up a vpn server locally? i do also have an openbsd box running locally, albeit it will most definitely be the limiting factor (rpi 4) 18:33:13 i reckon yes, you should have the same results as fib 0 18:33:37 do you have any special fib settings in your /boot/loader.conf? 18:34:11 here it is: https://paste.c-net.org/WidowedCapacity 18:34:13 nothing fib specific 18:34:32 also i got no idea how to set up a vpn server in the first place, but i guess it's a good experience to learn how... 18:35:06 wireguard server is really easy 18:35:25 not more difficult than setting up the client which you managed 18:35:32 should prolly be able to manage with man page and some googling 18:36:27 hmjsp: first hit reads good, https://ianix.com/wireguard/openbsd-howto.html 18:37:23 "Please note that the following configuration is in the style of the original wireguard-go implementation, from before OpenBSD got in-kernel support. The new ifconfig and /etc/hostname.wg0 approach is more reliable since the old method can potentially fail after an ABI change, requiring the wg-tools package to be updated before the WireGuard interface can come up." booo 18:40:15 ah the configuration looks pretty much the same 18:44:43 iRobbery: where do i find client public key on freebsd? 18:44:48 or should i generate it also? 18:48:13 you generate it yes 18:53:48 i did do that... and i can't connect? 18:53:58 i followed the instructions on the server side word for word 18:54:04 ping just hangs 18:54:12 100% packet loss 18:55:31 you see the wg tunnel established, bytes in and out? 18:56:27 wg show on client says: transfer: 2.30 KiB received, 67.81 KiB sent 18:56:31 so SOMETHING is happening 18:56:44 wg show on server just tells me the listening port 18:56:48 i did add pf.conf rules and reload 18:57:34 tcpdump on wg0 shows nothing tho... 18:58:08 wg show is a good indication yes. You should see something with tcpdump. Firewall setup good/active? 18:58:16 i can see this on tcpdump on bse0 (ethernet on pi 4 openbsd server): 19:57:47.573793 192.168.1.111.56973 > 192.168.1.123.51820: [wg] data length 96 to 0x7e5cb92e nonce 7 18:58:17 ip forwarding enabled? 18:58:29 192.168.1.111 is my freebsd, 192.168.1.123 is my openbsd 18:58:41 ip forwarding is enabled, yes 18:59:05 And you picked some random lan range for wireguard network? 18:59:07 net.inet.ip.forwarding=1 on obsd box 18:59:17 s/random/other 18:59:33 wdym? 18:59:42 AllowedIPs = 10.0.0.2/32 on server 19:00:44 yes something else for the wireguard network then your lan that's what i poorly said 19:01:19 im certain my public/private key combos are accurate in my configs... 19:02:02 and you only saw packets from your freebsd client to obsd and no return? 19:02:05 and on client, pf.conf has "pass out" 19:02:10 yes 19:02:20 100% packet loss on fbsd client 19:02:39 So no 2 way udp traffic on wireguard port? 19:03:00 yes 19:04:00 double check both sides firewalls i'd say? 19:06:30 i did; i added the three lines for client at the end of my pf.conf; ran pfctl -f /etc/pf.conf; added the single line for client as well, did the same. to no avail 19:07:17 hmm there should only be two options, or the keys/config is not correct, or firewall, i cant imagine anything else 19:07:57 i'll try generating and copying keys again i guess. wait, maybe router ports not being open stops this? 19:08:04 but it's on lan so 19:08:12 not sure how that would be an issue 19:09:03 neither of the hosts are VMs are they? 19:09:23 transfer: 8.36 KiB received, 252.49 KiB sent; kbs sent/recv are increasing.... 19:09:26 on client 19:09:28 spork_css: nope 19:09:49 both bare metal, one is obsd arm64, and the client is fbsd amd64 19:12:31 just checking, I saw "em0" and figured it was physical, but wanted to check (ran into weird issues w/wireguard on a VPS myself). 19:16:12 redoing public/private keys doesn't help... 19:16:13 :( 19:17:23 hmm hmm debugging remote is hard 19:17:48 what does 'wg show' on server show? 19:18:47 interface: wg0 19:18:47 listening port: 51820 19:18:56 odd that it doesn't show in/out 19:21:05 can you show the configs? with censored keys? 19:21:24 sure 19:23:49 https://paste.c-net.org/PatheticProspect 19:24:01 iRobbery: ^ 19:26:40 server config doesnt specific an address? Sure it's listening on the right ip/interface there (just double checking) 19:28:02 server config from the website doesn't ask for an address 19:28:11 two lines each for interface and peer 19:28:59 im gonna try disable pf on both and see 19:29:30 ...and still nothing. defo not firewall rules 19:29:49 client side doesnt specify a wg client ip? 19:29:59 at [interface] block 19:31:17 again, if the website instructions are correct, i don't need to specify an ip, it's only one line for the private key 19:33:10 well i do in my wireguard servers and clients :) 19:34:53 hmm okay i'll see... 19:35:16 https://r3rr.com/paste/U0NkVj 19:36:14 should i put my local ip under the interface for the server? 19:36:23 since im doing all this on lan anyways 19:37:04 also hold on, freebsd wireguard (without isntalling from ports) does not support Address 19:37:20 it doesn't work, i learnt how to make it work from: https://blog.feld.me/posts/2025/12/wireguard-freebsd-way/ 19:40:54 have to admit my servers are typically freebsd, clients are 'endusers' :) windows, mac, iot devices etc mainly 19:41:05 but i thought address would be standard wireguard spec 19:42:52 nah it's defo not 19:42:59 Using DHCP on WG server-side, maybe? 19:44:07 iRobbery: also, wg show on server DOES show more info, if i run it with doas 19:44:08 blehh 19:44:21 https://paste.c-net.org/MeantimeScrews 19:44:37 ek: nop, static ip, connected via ethernet 19:45:50 despite there being i/o when using wg show, i consistently get 100% packet loss 19:45:55 hmjsp: How is the client supposed to get an IP withing WG then? 19:46:29 good question. i got no idea. i thought wg just figures itself out... 19:46:45 nowhere is it mentioned that i need a dhcp server running? 19:46:54 hmjsp: Sounds like it's connected to the server, handshake is good, but routing isn't working. Likely due to the client not getting an address that's routable. 19:47:09 i see 19:47:10 Wireguard doesn't figure anything out. It's dumb as a box of rocks. 19:47:44 So dumb, in fact, that it will allow any client to choose any IP they want (I don't like this feature and think it should be assigned from the server-side. But, who am I?) 19:48:38 So, you either need to setup DHCP for WG on the server and have the client request an IP. Or, assign the IP on the client. 19:49:33 and i assign the ip on the client by doing...? 19:51:55 Adding the "Address" line. 19:52:14 The page your referenced is for setting up the server only. Not the client. 19:53:13 https://docs.vultr.com/how-to-install-wireguard-vpn-on-freebsd-14-0#configure-wireguard 19:53:21 Scroll down a little to the "Create a WireGuard Client Configuration" section. 19:53:36 It'll show you the client configuration. 19:54:31 ek: doesn't this resolve this exact issue: https://blog.feld.me/posts/2025/12/wireguard-freebsd-way/ ? 19:54:49 i certainly had client working, i was just getting packet loss 19:55:35 hmjsp: That's the server setup and it should work fine. 19:55:51 But, you still need to specify an address for the client on the client-side WG configuration. 19:57:09 im pretty sure it's not server setup, given that i've had the client working this whole time, and it's only when introducing my own server into the equation that things went wrong 19:57:28 aside from getting packet loss which was intermittent, implying it's probably too much load on the vpn server's side 19:57:57 The server should be fine. I'm guessing it's the client configuration that needs attention. 20:01:24 maybe... i'll revisit this tomorrow tbh because i have to go now 20:01:30 thanks for the help tho everyone 20:03:50 hmjsp: Best of luck!