very intrigued and confused by my manually edited configuration files in /usr/local/etc getting replaced by template ones after upgrading a package (it was a file related to that specific package), I was sure this cannot happen

anyone here uses Kerberos? I have kerberos in a jail + nfs server + linux client working all fine, but I am not able to make macOS client work at all

antranigv: which implementation do you have on FreeBSD?

Remilia latest, so... MIT I think

Mac OS is Heimdal if I recall right?

it is? lemme check

it just say "Kerberos 5 version 1.22.2"

I think FreeBSD had Heimdal as the default

> The Heimdal Kerberos implementation was explicitly developed outside of the US to avoid export regulations. The Heimdal Kerberos distribution is included in the base FreeBSD installation, and another distribution with more configurable options is available as security/heimdal in the Ports Collection.

are you using krb5 from ports then

no no, in FreeBSD 15 we moved to MIT.

handbook needs updating

I wonder what is with Mac OS... 10.2 had MIT, Monterey had Heimdal, ??

yeah its weird.

Remilia: if it is a config file then it should be marked as @sample in the pkg-plist and pkg will preserve your version, if it isn't marked @sample then pkg will override the file when upgrading

nimaje: darn it

it is just %%ETCDIR%%/config.kdl

seems like you have to write a problem report

going to make a quick patch first so I can attach that

this really sucks because it was a somewhat complex configuration

hm, pkg-plist contains %%ETCDIR%%/config.kdl %%ETCDIR%%/config.kdl.orig and %%ETCDIR%%/config.kdl.sample seems like someone wanted to use @sample but forgot to adjust the plist correctly and forgot to not install the .orig file from patching

@sample %%ETCDIR%%/config.kdl.sample is enough

nimaje: yeah

bugs.freebsd.org/bugzilla/show_bug.cgi?id=296506 done

wait darn the patch is not quite right

nimaje: there's extra stuff in Makefile too so I'm amending my patch now haha (extra install invocations to add those .sample files manually, huh)

Remilia: docs.freebsd.org/en/books/porters-handbook/book/#plist-config

mzar: I read that an hour ago, thank you!

nimaje: I wonder, if I am following an example from existing pkg-plists and it's not behaving in a way I expect, am I doing something really wrong :\

taking `net-im/ejabberd/pkg-plist:@sample %%ETCDIR%%/inetrc.example %%ETCDIR%%/inetrc` as an example I added `@sample %%ETCDIR%%/config.kdl %%ETCDIR%%/config.kdl.sample` but `pkg remove` deletes the file even if it is modified...

(`poudriere testport` passes)

Remilia: `@sample %%ETCDIR%%/config.kdl.sample %%ETCDIR%%/config.kdl`

I tried that too, sorry

copied the wrong one

" The format is @sample sample-file actual-config-file. "

the one I pasted does not pass testport

going to try again, maybe something went wrong :\

just upgraded to 15.1-RELEASE-p1 from 14.4-RELEASE-p6, the dialog tool has disappeared. bsddialog is lacking the hotkey functionality

also, I did not dare to risk the pkgbase update

dnp1: testport'd again and for some reason that syntax does not work ha ha. the opposite (what I posted) passes but ???

docs.freebsd.org/en/books/porters-h…dbook/book/#plist-keywords-examples looks like that is the right syntax

so my problem becomes 'how do I pre-build rename files'

post-patch

mzar: I refuse

bugs.freebsd.org/bugzilla/attachment.cgi?id=272486&action=diff and now it is Done

hm, why does it not work with ${INSTALL_DATA} ? that should do exactly what you want as it just is install -m 0644

nimaje: because you end up installing two files (.kdl, ,kdl.sample), which is incorrect in this case

for @sample we want .sample in stagedir, nothing else, or we have to list it in pkg-plist and then it can't be .sample and will get deleted

ah, you move inside STAGEDIR, ok

I found lots of other ports that rename stock configuration files to .sample

nimaje: yep, I tested it just now on my server and it finally does what I expected it to do: [varnish] [1/1] Deleting files for iocaine-3.5.0_1: 100% \ You may need to manually remove /usr/local/etc/iocaine/config.kdl if it is no longer needed.

(after I deleted a single comment from the file)

I finally checked what is wrong with the ports feed, someone forgot that it is intendet for bots and put it behind bot protection… bugs.freebsd.org/bugzilla/show_bug.cgi?id=296516

it could be put behind per IP and per subnet ratelimits

I have no probem fetching the feed via my browser and via curl, just my feed reader (rss guard) had problems with it, but a workaround is setting the user agent to curl instead

hey, did anything change since 14.4 in terms of pfctl calling from within a jail? my fail2ban jail started getting "pfctl: Operation not supported by device" after reinstalling its jail with 15 binaries. interestingly, 14 binaries didn't have this issue

If it is a vnet jail then all should work as expected. If it is not a vnet jail then how does that work? It's in a jail. Says me but you could convince me there is a use case for it.

rwp: I've enabled access to /dev/pf in the jail, fail2ban runs there checking the logs, and adds bans to PF... at least it did until I've upgraded

btw it's not a vnet jail

now I'm trying to make sense of what happens but truss-ing a "pfctl -s rules" doesn't give much information

the interesting thing is, it worked on 15 kernel and 14 userland, it doesn't with 15/15

so I'm thinking something has changed in pfctl that does this

newer versions use netlink for some (most?) opes

ops

all my opes, gone

is that something I can enable within that jail?

okay, I've reached an impasse. putting fail2ban in a vnet jail would only manage the jail's pf rules, and a non-vnet jail now just rejects pfctl requests

fail2ban needs to run in the host

alternatively, putting freebsd 14's pfctl into the jail as the path for it still exists, but it's a fugly hack I won't do

I guess you must have been running fail2ban in a jail on the root file system? So it was a process jail only in that case, since it had access to all files on the file system? I know that process jails are useful for trapping the process.

In the case of fail2ban it only processes local files. It doesn't have a large attack surface from the hostile Internet to attack it. So I have never considered running it inside of a process jail.

it was my shtick to put everything possible into a jail so as to have as little as possible installed stuff on the host

In order for something to attack it that hostile actor would need to cause something malicious to be logged into a log file, and then fail2ban would need to read it. That's a stretch.

turns out it was a bad idea with f2b

All of my jails have their own separate filesystem that they are running in a jail.

same here, the logs were only a nullmount

I could still chroot it and circumvent the issue but that seems to me an even bigger hack :)

But you wanted something inside the jail to affect something outside the jail.

yeah, it's how it worked so far, with having /dev/pf in it

A chroot is a layer. And then the processes in the chroot could of course communicate outside the chroot.

Should I add regression tests for bugs that I introduced and spotted during development?

like, before even sending the patch anywhere

If somehow fail2ban turned evil then it would still be filesystem blocked from other files. Even if it can communicate out.

runxiyu_, If the project for which you are reporting a bug has regression tests and you can add one for it then yes that is appreciated. But if that is going to significantly delay reporting then I think you can go ahead and report it. (Says me who has no idea what project you are working with here.)

karolyi, Have you exhausted looking to see if there is a sysctl option which will re-enable the feature you have been using? I know there are many optional things that can be enabled.

rwp: sorry, I mean

I'm writing up a kernel patch to improve capsicum for jaildesc

And there's a subtle point about somewhere where _SET looks appropriate but I should actually check for _SET|_ATTACH

I'm thinking whether I should regress-test that

rwp: there is allow.routing but no equivalent exists for pf

D49843 = FreeBSD Phabricator revision for commit 3a53fe2cc4b7 ("jail: add allow.routing jail permission"), author Lexi Winter, it added a new jail permission allow.routing (sys/sys/jail.h: PR_ALLOW_ROUTING) letting a non-VNET jail modify the host's routing table via PRIV_NET_ROUTE, and flagged the netlink RTM_NEWROUTE/RTM_DELROUTE handlers (sys/netlink/route/rt.c) with RTNL_F_ALLOW_NONVNET_JAIL so they

bypass the usual VNET-only restriction when that jail permission is set.

karolyi, I think that would be a reasonable thing to make a problem report since it removes a feature which had been working without any way to regain that capability. It might not have been explicitly meant to remove it.

rwp: where do I do that?

bugs.freebsd.org?

Yes. That's where I would make the report. The author of that commit you referenced <ivy> hasn't been seen in this channel since June 8th but often hangs out here. But it's been long enough that making a PR there seems reasonable. It's a behavior change. It's a regression for you.

I'm making a report now

I have this idea that explicit changes in behavior that affect things should have a note of some sort in the release notes. That way we know it either is or is not a regression bug. Some things could go either way and unless you are deep into the code it can be hard to know sometimes.

rwp: bugs.freebsd.org/bugzilla/show_bug.cgi?id=296521

full transparency, I've used claude code to have a go at the freebsd-src repo to get a glimpse of what I'm really facing, while I was expressing my concerns on here

It does read like an AI generated report. :-( I think most people will know this even though you didn't say it.

AI or not, the crux of the matter is there in a detailed way, and the first paragraph is mine :) not AI

not sure I would have been able to phrase it better btw, without risking a lot of follow-up questions

I agree that the main point of the report is true regardless and I think it is good to have it reported. I doubt this was an intentional change. I am thinking it just fell out of the intended change and wasn't noticed.

well I need to put fail2ban over (with the tools I've made around it) over to the host jail nonetheless

Good luck and happy hacking!

Remilia: in my defense, I'm from the midwest bits of the US and we do a lot of opeing

I've made a munin graph source for graphing the amount of bans per jail from its sqlite db

karolyi: Coming at these things without slop will get you more credibility and traction.

mason: again, the problem is that I'm unsure I could have phrased it better, since it's got a lot of technical detail and I'm not a freebsd dev

rwp: it was noticed, but netlink doesn't have a good answer at the moment

kevans: I would be happy with an allow.pf sysctl similar to allow.routing

karolyi, You would be better off not including the technical detail then. Don't run faster than your angels can fly. The AI included a bunch of stuff only marginally relevant. Which is one of the fingerprints of AI generated reports.

I sometimes naturally speak like that, going off on weird tangents

btw I was thinking about slowly getting over to VNET based jails, which is a PITA since I have an ansible based scriptset that creates my jails (of which I have 42 now)

It worked on 14. It fails on 15. That's succinct and anyone into that part of the code base will be able to reproduce it once asked to look at that detail. And they will know all of the things the AI is trying to helpfully educate us about which is all peripheral.

now with this bug(?) surfacing, it seems I'll need to pick up the speed with that

karolyi: Ironically, I'm moving the other way. Everything was VNET but I've come to appreciate the relative lightness of traditional jail networking, with pf.

If you have 42 non-vnet jails and they are doing good work for you then probably they should not be vnet jails. (Note that I *LOVE* vnet jails for creating a software defined networking environment for a test lab setup. Totally awesome.) But that does not sound like what you are doing. So I would not make converting to a vnet jail a priority.

mason: if you would see my configuration, you wouldn't say it's light :)

rwp: right now all my jails work after the upgrade, it's only the fail2ban one that hit this thing

karolyi: Ignoring the bug, do you need to manipulate pf that way? This might be a little Rube Goldberg, but if you realize you need to add an address to a table, add it to a file and have something on the host going through regularly and parsing/processing those files per-jail.

Like mason if I can make something work in a non-vnet jail then that's my first choice. It's simpler. It keeps things simpler. I use vnet jails when I want to create a test environment to test something out and need, say, a dhcp server running to hand out many addresses or something.

karolyi: For instance, I quite literally have a Perl script tailing logs, and then acting if a match is found. Your case would be far simpler, just seeing that a new line has been added, and either parsing the whole thing for changes, or just adding what's new, or whatever. Should be entirely doable with a couple minutes quick hacking.

(My Perl script tailing logs is what I use instead of fail2ban, because in my experience, fail2ban fails2ban all too often.)

mason: yeah I was thinking on it, especially after realizing what other tooling I have in that jail

(My stuff might be described better as instaban.)

The fail2ban.log file could be tail'd and parsed.

I just need to patch the direct pf manipulation over to this new method

But I would not Rube Goldberg this one. Because then your tail'd processing would be in another jail, right? Where does it end? Isn't fail2ban vetted well enough? It's a python program that runs on half of the Internet's systems already.

karolyi: If you try this approach and hit any hurdles, I'd be more than happy to help. Should pfctl work from within jails? Sure, if that permission exists and works right. But don't let that stop you. :)

kevans: nah you just reminded me of that hilarious post from those 'NFTs are definitely the future' years

rwp: I'd think "on the host" rather than in another jail, but I don't know karolyi's firewalling set up so I'm guessing.

rwp: If popularity mattered, we'd all agree that McDonald's is the world's finest cuisine.

I run it on the host. I think that's the normal configuration.

mason: probably a quick script that uses inotify on the host can do the job, once I've modified fail2ban to emit the pf changes to files

karolyi: Is the host Linux??

Oh, we have some kind of inotify emulation now I guess.

mason: I'm on FreeBSD 15.1 all the way :)

I still have a lot of 14 deployed. Although it's a mix now - 14.4, 15.0, 15.1.

it's the inotify python module, I've use it in other projects, works. probably uses kqueue as a backend

Yeah. Useful.

mason, I take the point that popularity is not an indicator of the best thing. But it does get back to many eyes will find most bugs. And jails is specifically a security layer. So...

btw the thing about the non-vnet jail is, it's got ipv4 on one interface (lo0) and ipv6 on another (bridge0). some daemons don't like such configurations, php-fpm would be one

Anyway, I'll be doing projects off and on today, but if I can be of use, say the word and I imagine I'll be checking in at least hourly or thereabouts.

karolyi, Some VPS hosting providers split IPv4 & IPv6 onto different networking devices and it always makes me wonder why. And breaks a bunch of assumptions I had previously made and then had to modify to make work. Gah!

mason: thanks for the offer, will let you know but I probably can get it done with a little hacking :) I want to keep the f2b jail as is, with as little work as possible

karolyi: Good hunting then. :)

mason, freebsd.org/releases/15.0R/relnotes "FreeBSD now natively implements the Linux inotify(2) interface. The system calls themselves are not API-compatible, but libc provides an API-compatible interface, so software which relies on inotify can be run unmodified. f1f230439fa4 (Sponsored by Klara, Inc.)"

Which is pretty cool! And something I have been anxiously waiting for so I can move some more things from linux over to FreeBSD. One of them is on my task goal list for today. :-)

oh we can finally monitor directories whole

actually, does syncthing build with it...

I haven't tried it yet but I'll be giving it a good workout very soon. This has been a feature I have been needing.

I have a setup on a linux system which uses it and this will allow me to convert it to FreeBSD. Woot!

yeah, inotify is quite handy

oh, the python module is called watchdog... no idea why I was thinking inotify

the kqueue shim was fine, but iirc there are at least a few semantic differences that you can't adequately capture with kqueue at all

Remilia, I recently heard someone complaining about how syncthing was problematic because, up until now anyway, it wanted to use the inotify interface and it was not available on FreeBSD. I imagine that syncthing will now be hugely better. I don't know if it has already been converted or not.

Supported Platforms: FreeBSD/BSD (kqueue)

rwp: golang.org/x/sys/unix does not seem to do inotify on freebsd yet

kevans: I remember reading about that somewhere (might have been years ago), but the way I use it, works. just getting notified if files change

Remilia, :-( Let's hope that gets improved soon then. However I am not using syncthing myself so this is just wishing for those that do use it to have a better day in the future.

I have syncthing since it's kind of the best solution out of simple ones, but mine's got less than 15 files in the shared directory so it's fine

Remilia, Right! Small numbers of files are fine. In my inotify case it is watching 342,529 files which feels like a significant number.

[19:52:16] <karolyi> I just need to patch the direct pf manipulation over to this new method

^ but

doesn't fail2ban support custom actions?

do you really need to 'patch' it

> An action is a shell command (or commands) that Fail2Ban executes at appropriate times. For example a ban action is executed when Fail2Ban invokes a ban against an IP address. Actions are normally defined by configuration files in the action.d subdirectory.

Which files are included in the compat14x and compat15x packages? (I'm pretty sure I found a listing previously, but...)

Ah, "compat14x-<arch>`, not "compat14x".

Remilia: I'm creating a new action script, basically

runxiyu_: unless your regression test is adding massive amounts of overhead to the test suite for little gain, it's worth adding. particularly if it tests a subtle corner like that

alright, ty

its not much overhead imo

hey guys, anyone using bastille jail here ? i noticed some hangs

asking in #bastillebsd but that chan seems a bit slow

ok, i think i was able to reproduce the problem at least in my setup:

open screen (or tmux -- however i havent tested with tmux), create 2 windows in the screen. Go to window 1

ensure the jail is stopped.

run: sudo bastille console -a jailtest

immediately press ctlr+a so screen/tmux switches to the other window (This hangs on for 1-2 seconds brefore it switches to the second window)

im gonna try that again..

wow, doing the same with "stop" also hangs.. for like 10 seconds

on (screen/tmux)window#1 sudo bastille stop jailtest

then immediately press ctrl+a to switch to the other window

then wait... it hangs for 10 seconds before switching to the other window

does that only happens to me ?

(and i dont mean this is a bastille problem, i just want to know if there is a fix, or maybe its an only me problem)

hernan604, I think what you are seeing is that when bastille creates a new jail that it must do a lot of file copying and this uses a lot of file system I/O and probably a spike of memory use too. This is causing screen to not get full machine cycles and the visible pause until it can catch up.

You can probably get the same effect if you untar base.txz or cp -R a large directory tree or similar things that cause a lot of file copy activity all at once.

rwp: right, that would "explain" why i get the same problem in another host that seems to hang randomly with the jails running

but then its unusable

if one single untar causes everything to hang, its "unusable"

there must be some solution

cant be that everyones jails hangs and nobody complains ? that makes no sense

these random hangs would cause weeks of total time loss during a year

maybe not weeks, but a good amount of lost processing time

so my bridging-pfctl-between-jail-and-host script is done, and it works like a charm

hernan604, How long do these hangs last? I thought you said for like 10 seconds? No? Then things become responsive again?

What I described is just a momentary system saturation which eventually (like 10 seconds) sorts out and then things move on.

If it is like that then that's not what I would describe as unusuable. And that can be mitigated if the system has more RAM. That really only happens when the system is quite short on memory.

How much memory is on your system?

karolyi, Woot! \o/

rwp: now let's wait for the response for my submitted bug :)

I subscribed to the bug so I could see what happened with it.

rwp: yes 10 secs. 128gb ram

Well 128 GB of ram seems like it should be more than enough!

only an nfs share running, plus this jail that hangs and the jail is brand new

Is it only around 10 seconds? In which case I would not call it a hang. I can see that the pause would be annoying. But a hang would be like you go off for an hour and it is still wedged up stuck. That's a hang.

rwp: 10 seconds +-

but it can affect other running processes

I also think that with 128 GB of RAM that it should not be pausing with a burst of file copy either. Keep asking this question. I don't know the answer but maybe someone else will be by who will have a suggestion.

well it does affect.. because the processes become unresponsive

Permanently unresponsive?

for the 10 seconds

Then it is not a hang.

I know we are just debating the words here but a hang has a specific meaning when debugging computer programs and it will lead to the wrong conclusion.

well, if i run stuff in the host without a jail, it wouldnt hang... maybe thats what i will do

rwp: well imagine i have 10 customers, 1 on each jail... and they are using the jails and it hangs randomly for 10 seconds, multiple times a day.... is this a good service ?

imagine if everyones VPS hosting VM hangs for 10 seconds...

randomly, everyday, all the time

something wrong is not right

I wasn't saying that something was not wrong. I am just saying it isn't a hang.

And as I said, keep asking the question. I don't know the answer. But maybe someone else who happens by will know. And if not here then send an email to the questions⊙fo mailing list. More deep expertise there.

well, its unresponsive, so i concluded its a hang

Or the web forums. But I never touch the web forums. Other people do though.

ah good idea

i created an issue in bastille github

Please say the URL here for that github issue so that curious lurkers can browse it too.