nulltaz, Yes. pf is upside down compared to what I would expect or would write it myself. But I am told that the syntax was based upon an earlier firewall and the author tried to make it more compatible with the previous that it replaced. So that's why it is upside down.

However this does provide some of the powerful capabilities. Packets can be tagged based upon the interface they arrived in and then sorted out later based upon that information. And other things.

In the case of pf it is pretty much required to read the documentation on it. Trying to guess at it would be frustrating because it can't be obvious. But the documentation is pretty good for it.

topcat001, This is an old article but I think it still applies. schmidp.com/2014/01/05/freebsd-10-does-swap-work-on-a-zvol

Because for example here is a somewhat more recent report of deadlocks putting swap on zfs on linux systems. openzfs/zfs #7734

rwp: thanks man, i appreciate the insight and assistance. I’ll read that tonight!

nulltaz, Uhm... Did I give you something to read? I gave another two articles about swap on zfs and why that's not good.

anyone familiar with sand syntax?

anyone familiar with sanoid syntax?

crb, Better to ask a specific question about sanoid.

I think I got it going, thanks

\o/

Has anyone ever done a guide or writeup on migrating a TrueNAS core setup to vanilla FreeBSD?

jmw_: without reinstalling?

if your truenas core OS is installed separate from the data, then in theory, one can export the zfs vols, install stock fbsd, import the zfs vols, but there are lot of things truenas does that you'll have to setup yourself in fbsd

there are people who have tried it, forums.freebsd.org/threads/plan-and…-truenas-core-to-pure-freebsd.93128

I did the same thing once they dropped core. I just installed and imported my pool. That's why ZFS is so amazing.

hi

does anyone else here force firefox to use OSS via media.cubeb.backend="oss"? I had applied that setting a while back, since the default of pulseaudio was having clipping audio, but I started noticing that with 60fps videos on youtube, roughly half of the frames were getting dropped

switching back to pulse fixes that issue, and at least now I'm not having the same issue with pulse, but I'm wondering if anyone else has run into this issue with OSS and maybe knows a way to resolve it

it'd be nice to not have to rely on pulse

I'm wondering if I've really been having that frame drop issue for months and somehow never noticed it, or if it cropped up when I moved to CURRENT

hm, I build firefox without pulseaudio support, but I never use it to watch videos, those I watch in mpv so no idea about your issue

the only thing I can think of is that some OSS write call is blocking abnormally long to the point where FF has to drop frames to keep the audio and video synced. I'm not sure. it doesn't happen with mpv

guessing cubeb's OSS support is just not very well-maintained, but I plan on trying out the OSS backend again once I'm back on 15-STABLE (hopefully soon)

currently in the middle of a git bisect on the drm-kmod repo, trying to pinpoint the commit that fixes this GPU hang issue that's been plaguing my setup for quite some time but appears fixed as of the 6.10 drivers

hoping the commit that fixes the issue can be backported into the LTS branches without breaking support for 14 and 15

and hoping the commit that fixes the issue is actually one that can stand on its own and doesn't depend on a bunch of other changes that drm-61 and drm-66 lack

if you can find the commit that is a big step, we can do direct commits to resolve regressions

yeah that's currently a WIP. it's gonna take some time, though. getting a GPU hang is a sure sign that the issue isn't resolved, but not getting a hang is not quite as conclusive

the hangs have seemed to be more reliable on drm-66 and later but there have been times where it's seemed like I've needed firefox to consume some vague threshold of GPU resources before mpv would trigger a hang

so I've only been marking a commit as fixed only when mpv consistently fails to hang after at least half a day of normal use

it will be quite time consuming if I incorrectly mark a commit during the bisecting process

anyone has an example of pf.conf with dnctl? I need QoS but I think I still need to compile the kernel for altq, which I don't wanna do on this system.

how do i enable wol persistently, do i just add wol_magic like this in my rc.conf

ifconfig_re0="inet 192.168.1.2 netmask 255.255.255.0 wol_magic"

well, it doent seem to work at all. It works fine on linux where i have tested it already

someone else seemed to have a similar issue recently forums.freebsd.org/threads/wake-on-…n-igc-driver-nic-intel-i226-v.94598

and ifconfig indicates that that interface supports WOL_MAGIC in options?

Does anyone know how Ruby works on FreeBSD? On a standard Ruby install, you have 'gem', 'rake', etc but FreeBSD takes a standard install apart and separates it into different ports. That would be fine if those ports didn't force you to use ruby33. How do I use ruby40 and also have a package manager at the same time?

Seems really strange to me. This situation. Why package ruby40 at all if it is going to be like this?

hm, seems like ruby packages only get build for the default version (whyever that is 3.3 instead of 4.0), seems like USES=ruby should also grow flavor support, so that all packages are build for all ruby versions

Yeah. The ports tree supports RUBY_VER. I could set that, and then rubygems etc would be bound to ruby40 instead. But that's not an option if you only have pkg(8). I'm kind of shocked at this situation. It's like shooting yourself in the foot. A standard install solves all this weirdness.

I think it's basically unusable for Ruby development and I'm going to avoid it entirely.

could you please open a problem report saying that the port with those ruby development tools don't produce a package for non-default versions of ruby, making non-default versions of ruby about useless for pkg users, if you want you can also add the suggestion to add flavor support to USES=ruby

Sure

deimosBSD: ty - that's a good start

nimaje bugs.freebsd.org/bugzilla/show_bug.cgi?id=293316

thanks, lets see what the ruby@ group thinks

In /usr/ports/Mk/Uses/gem.mk RUBY_VER is used as well and so I think in the ports tree, it works fine. I can set RUBY_VER and run make install. But with pkg, I don't see any options. Everything is bound to ruby33 AFAICT.

I did plan to use ruby / freebsd on CI but this situation is too messy so I'm gonna hold off on that.

I'm having trouble configuring sanoid correctly. When looking at debug output it's telling me it has 14 hourly snapshot but 0 are desired. What gives?

there seems to be a lot of tension around how the ports collection handles python too, not specifically helped by packaging standards changes on the python end

It's neither here or there I guess but I also use OpenBSD, and there ruby is packaged as a standard install, and also maintained by a ruby core team member. I have never had any issue with it.

˜/47

rwp: I think I'll have to just manually track IPs added, re: my question about expiration the other day.

Given my tooling that finds the things, this won't be a ton of extra work.

mason: you could use blocklistd…

mason, I am still reading through the pf book and learning the nooks and crannies. But so far I think that's the only solution available to us.

nimaje, Off the top of my head I don't recall why I found blocklistd insufficient and will need to visit it again but I remember thinking that it was not as good as installing and using fail2ban so I have been using fail2ban. Even though fail2ban has many deficiencies too and I want to finish writing a better tool.

Finish, because I use a collection of my own scripts to do my own thing to augment fail2ban covering for some of the limitations there.

nimaje: I don't see blocklistd doing anything with expiry times. What am I missing?

Also, I'm not seeing it in FreeBSD 14. Is it new with 15? I'm not going to be migrating just yet.

nimaje: Ah, you might have missed the original question. I was hoping there was a facility like ipset's "timeout" directive, but I'm not seeing one.

In 14 it is called blacklistd. But the name has been modified so people don't trigger on the black part of the name.

Oh, good catch. Thank you.

Hey, it *does* have a timeout.

I missed this somehow.

nimaje: Thank you. Looks worth exploring rather than rolling my own.

I feel compelled to say this as neutrally as possible but blacklist dates back to at least the year 1639 en.wikipedia.org/wiki/Blacklisting and avoiding it now feels like Orwell's language Doublethink en.wikipedia.org/wiki/Doublethink (and I say no more in this channel now about it).

rwp: Replying in -social

qsy to #freebsd-social