What are you standard use cases for rsync? Drew DeVault propose tar instead: <drewdevault.com/blog/rsync-without-rsync> .

Also, is there no possiblity to keep using the latest non-slop version for a while?

ant-x: Nice thing about OpenRsync is it's BSD licensed.

The only reason OpenRsync exists is to change licenses for OpenBSD. github.com/kristapsdz/openrsync

And it accomplishes that nicely.

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!

If rsync is now on the AI Slop train (social.hails.org/@hailey/116657391001259044) it does not bode well for it. Might be time to switch to OpenRsync for stability.

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?

Sounds like a regression in ps. Jails do not normally have a kernel at all.

yes, there is a thread here forums.freebsd.org/threads/why-does…and-then-complain-when-it-is.102485 that indicates the same, but their discussion was not conclusive

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.

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.

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

Seems like a good enough PR to me.

Just read the Drew DeVault's blog posting saying that tar options are "hard to remember how to use".

Huh? The options to tar are extremely basic and simple.

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.

That's really all that one ever needs to know about tar. How hard is that?

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

Traditionally instead of <<tar xvf foo.tar.gz -C ~/src>> we would <<( cd /usr/src && tar xvf foo.tar.gz )>> and so the -C option is not ever really needed.

I mixed my metaphors there but I am sure you know what I meant to say there.

Same thing for the same reason about make -C too.

but it doesnt really say much?

elivoncoder: it says plenty, just may not say what you wanted to hear

elivoncoder: yeah, i thought it was pretty weak compared to what e.g. EFF have published.

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

well, technically the freebsd foundation doesn't have a project, their entire job is advocacy (and paying people to work on freebsd)

s/project/product

sure, but their core goal is to support the freebsd project. treading lightly is to be expected

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

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

it seemingly installing a bunch of files, but they're still all broken.

I've also tried setting the version back to 14.3, but they also fail despite previously working

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.

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.

I'm not sure how to look in the jail

Axman6: It might be worth using straight system tools for your jails. It's important to understand how they're put together.

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.

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)

mason: that would have been good advice in the past

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).

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?

Hmm... I don't know about .resume files. I haven't dealt with them before. So probably. But no idea.

ok, looks like it was a botched etcupdate

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.

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

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

which is annoying because i like to block egress traffic from obviously invalid addresses

ivy: can you use tags?

lts: ah yes, that seems to work, thanks

"pass out ... tag NAT nat-to ...", "block out ... !tagged NAT"

Awesome

Hi!

How high :-?

No.

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?

Also, is automation (e.g. via ACME) that important for managing a single certificate for a single domain?

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

I could tolerate 90 days, but not a month. OK. Why do you think they are decreasing certificate lifetime?

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.

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

why is a month so bad? You basically write a shell script and put that into cron.

You assume Internet connectivity

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

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.

So far, I assume internet connectivity.

LetsEncrypt does 90-day certs (on my side at least).

I think that's what I have for my internal-only wildcard cert

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

hodapp, Why use LE for internal certs?

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

and it's so much simpler to just get "proper" certs

wavefunction, thanks. I have considered <getfreessl.org> (which supports manual workflow), but their own certificate is obsolette!

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.

ant-x: Depends entirely on how you want to authenticate and do stuff. I can shift this to DMs.

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

ng. here's a paste with more info if needed: paste.c-net.org/PicklesConrad

hmjsp: What MTU size do you use?

Is it different between locations?

skered: 1420, trying 1380 didn't help at all. it is between different locations, yes

I forget what I had to drop min to to make it work at some different places.

If you go lower you still have issues?

But if it's the same thing, pings, then MTU might not be the problem.

For me it was ping/ssh small payload size was fine.

But when you tried something larger (scp) is when it failed

But it was also depending where I was at.

dropped mtu to 1280, still get 50% packet loss

should i go lower?

If it's all pings then it shouldn't be an MTU issue.

50% packet loss on ping that is

what else could it be? i rotated a couple different server configs from the vpn provider, same issue

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.

Any chance you're behind some load balancer? server or client side

not that i know of, certainly not client side

just a regular router, and a pc connected to it via ethernet

You try running mtr ?

Might help to see where it's dropping.

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

what's mtr?

mtr is ping plus traceroute in one interface.

okok i'll see

skered: paste.c-net.org/CurseKarate

So you only have one hop between you and the endpoint?

no... sorry i didn't wanna post all ip addresses but ig it doesn't matter... give me a sec

Well if it's all 0s and loss is at the end then it shouldn't matter.

here it is now: paste.c-net.org/SenateProstate

very silly randomly generated paste name xD

anyone use the kde install script on 15.1?

did you initially get a login loop with wayland?

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

Might be if you're first hop is losing stuff then that's not a good sign.

ugh nvm back to 50% packet loss

im 80% sure it's just vpn provider being dodgy

hmjsp: Easy way to tell is to disable the VPN and test real quick.

But, it looks to me like you're getting loss between you and the immediate router/gateway. That's a problem.

Ideally you would let that mtr run for more than 20 seconds. Maybe all day.

Or at least an hour.

I usually let it run a while. Especially the entire duration of the troubleshooting.

I'm trying to wrap my head around the loss to 192.168.1.1 or 10.2.0.1, though.

iRobbery: Haha. I noticed that as well and chuckled.

ek: but you did click?

iRobbery: You don't click it... it clicks you.

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.

Now i'm just terrified, but reading back on wg issue

👉[C😲

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

hmjsp: do you write now that you did try wg/vpn using fib0 too?

i have not tried it on fib0, i wouldn't be able to ssh if i did that (im sshing into this system)

hmm i see, no ipmi or something to fallback to?

i do have physical access but it's in an awkward place away from any display

nope, nothing

or not that i know of

it's asus h110t

Do you get this weird jitter value consistently too in your speedtest results?

lemme see

paste.c-net.org/CurseKarate your mtr is a bit short too?

or it is just that hop where packetloss occurs?

on fib0: Download: 525.18 Mbps (Used: 680.23MB) (Latency: 14ms Jitter: 6ms Min: 7ms Max: 32ms)

iRobbery: ignore that one, see the next one

with fib1: Download: 344.46 Mbps (Used: 476.47MB) (Latency: 76ms Jitter: 31ms Min: 47ms Max: 140ms)

packet loss is back to 0% again...

aah it clicked me! *reading now*

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

xD

if you wrote about this yesterday i still had some decomissioned metal online, but they janked it offline this morning

aww :(

sneaky bastards did 500 mbit cap unmentioned

lol

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)

i reckon yes, you should have the same results as fib 0

do you have any special fib settings in your /boot/loader.conf?

here it is: paste.c-net.org/WidowedCapacity

nothing fib specific

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...

wireguard server is really easy

not more difficult than setting up the client which you managed

should prolly be able to manage with man page and some googling

hmjsp: first hit reads good, ianix.com/wireguard/openbsd-howto.html

"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

ah the configuration looks pretty much the same

iRobbery: where do i find client public key on freebsd?

or should i generate it also?

you generate it yes

i did do that... and i can't connect?

i followed the instructions on the server side word for word

ping just hangs

100% packet loss

you see the wg tunnel established, bytes in and out?

wg show on client says: transfer: 2.30 KiB received, 67.81 KiB sent

so SOMETHING is happening

wg show on server just tells me the listening port

i did add pf.conf rules and reload

tcpdump on wg0 shows nothing tho...

wg show is a good indication yes. You should see something with tcpdump. Firewall setup good/active?

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

ip forwarding enabled?

192.168.1.111 is my freebsd, 192.168.1.123 is my openbsd

ip forwarding is enabled, yes

And you picked some random lan range for wireguard network?

net.inet.ip.forwarding=1 on obsd box

s/random/other

wdym?

AllowedIPs = 10.0.0.2/32 on server

yes something else for the wireguard network then your lan that's what i poorly said

im certain my public/private key combos are accurate in my configs...

and you only saw packets from your freebsd client to obsd and no return?

and on client, pf.conf has "pass out"

yes

100% packet loss on fbsd client

So no 2 way udp traffic on wireguard port?

yes

double check both sides firewalls i'd say?

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

hmm there should only be two options, or the keys/config is not correct, or firewall, i cant imagine anything else

i'll try generating and copying keys again i guess. wait, maybe router ports not being open stops this?

but it's on lan so

not sure how that would be an issue

neither of the hosts are VMs are they?

transfer: 8.36 KiB received, 252.49 KiB sent; kbs sent/recv are increasing....

on client

spork_css: nope

both bare metal, one is obsd arm64, and the client is fbsd amd64

just checking, I saw "em0" and figured it was physical, but wanted to check (ran into weird issues w/wireguard on a VPS myself).

redoing public/private keys doesn't help...

:(

hmm hmm debugging remote is hard

what does 'wg show' on server show?

interface: wg0

listening port: 51820

odd that it doesn't show in/out

can you show the configs? with censored keys?

sure

iRobbery: ^

server config doesnt specific an address? Sure it's listening on the right ip/interface there (just double checking)

server config from the website doesn't ask for an address

two lines each for interface and peer

im gonna try disable pf on both and see

...and still nothing. defo not firewall rules

client side doesnt specify a wg client ip?

at [interface] block

again, if the website instructions are correct, i don't need to specify an ip, it's only one line for the private key

well i do in my wireguard servers and clients :)

hmm okay i'll see...

should i put my local ip under the interface for the server?

since im doing all this on lan anyways

also hold on, freebsd wireguard (without isntalling from ports) does not support Address

it doesn't work, i learnt how to make it work from: blog.feld.me/posts/2025/12/wireguard-freebsd-way

have to admit my servers are typically freebsd, clients are 'endusers' :) windows, mac, iot devices etc mainly

but i thought address would be standard wireguard spec

nah it's defo not

Using DHCP on WG server-side, maybe?

iRobbery: also, wg show on server DOES show more info, if i run it with doas

blehh

ek: nop, static ip, connected via ethernet

despite there being i/o when using wg show, i consistently get 100% packet loss

hmjsp: How is the client supposed to get an IP withing WG then?

good question. i got no idea. i thought wg just figures itself out...

nowhere is it mentioned that i need a dhcp server running?

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.

i see

Wireguard doesn't figure anything out. It's dumb as a box of rocks.

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?)

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.

and i assign the ip on the client by doing...?

Adding the "Address" line.

The page your referenced is for setting up the server only. Not the client.

Scroll down a little to the "Create a WireGuard Client Configuration" section.

It'll show you the client configuration.

ek: doesn't this resolve this exact issue: blog.feld.me/posts/2025/12/wireguard-freebsd-way ?

i certainly had client working, i was just getting packet loss

hmjsp: That's the server setup and it should work fine.

But, you still need to specify an address for the client on the client-side WG configuration.

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

aside from getting packet loss which was intermittent, implying it's probably too much load on the vpn server's side

The server should be fine. I'm guessing it's the client configuration that needs attention.

maybe... i'll revisit this tomorrow tbh because i have to go now

thanks for the help tho everyone

hmjsp: Best of luck!