00:03:33 <polarian> kerneldove: ssh forward on the host then?
00:03:55 <polarian> wait nvm hmmm
00:04:09 <kerneldove> polarian that won't work?
00:04:20 <kerneldove> that's what i'd hope to do i think
00:05:52 <polarian> honestly if the vnet jail is limited to the host network, then there is not going to be some elegate way which doesn't involve the host, if the jails are available on the local network, but not got a public IPv4 (IE: not WAN reachable) then you can simply transfer the file locally?
00:06:24 <polarian> kerneldove: you could use git (or friends), push the asset there, and have the asset pulled back down
00:06:30 <polarian> or push the asset to some webserver and pull it back down from the jail
00:06:43 <kerneldove> well with docker type containers, the container host can do port forwarding to the container. i just assumed jails would have something similar
00:06:55 <polarian> yeah you can, with pf!
00:07:02 <kerneldove> the jails do have a private ip so that jails can be on the same private lan, if that helps?
00:07:47 <kerneldove> would i connect to ip of jail host and it forwards to jail using its private lan ip?
00:07:49 <polarian> match in proto tcp from any to $hostip nat-to $jailip
00:08:03 <polarian> sorry no
00:08:20 <polarian> match in proto tcp from any to $hostip port $someport rdr-to $jailip
00:08:22 <polarian> there you go
00:08:25 <polarian> thats what you want
00:09:25 <polarian> actually
00:09:27 <polarian> you want to do
00:09:30 <kerneldove> and hostip is like 10.1.1.5 (my home lan) or 1.2.3.4 (public ipv4 at a colo) and the jailip would be like 192.168.15.20? (192.168.15/24 being the private lan for the project, so its various jails can all talk to each other on that private lan)
00:09:42 <polarian> match in on $hostif proto tcp from any to $hostip port $someport rdr-to $jailip
00:10:28 <polarian> the hostip is the ip of your jail host, and then the jailip is the ip address of the vnet jail
00:10:49 <polarian> and you want this to be only matching against packets coming in on the host interface
00:10:51 <kerneldove> but you get my point about the vnet jail's ip being in a private lan subnet?
00:10:56 <polarian> aka the interface which connects it to the local network
00:11:08 <polarian> kerneldove: yes but the host can reach said subnet
00:11:18 <kerneldove> ok so that's supported, nice!
00:11:20 <polarian> so you can just do packet redirection
00:11:33 <polarian> rdr-to is pf's way to redirect packets, aka "port forwarding"
00:11:46 <polarian> the port(s) you specify are redirected to the IP you specify
00:13:20 <kerneldove> ok that's great, seems this is a solution. i had no idea the public ip of the host could be used to 'bridge' onto the private lan subnet of a set of jails
00:13:25 <kerneldove> that's really great
00:13:53 <kerneldove> tyvm
00:15:55 <polarian> this relies on the host being able to access the internal networks
00:16:01 <polarian> I assume its configured with an epair right>
00:16:03 <polarian> ?
00:16:03 <kerneldove> polarian can i forward the port to a different port on the jail? that way each jail can have normal ports
00:16:06 <kerneldove> ya epair
00:16:25 <kerneldove> like 5522 forwards to 22
00:16:45 <kerneldove> 5622 forwards to 22 of a different jail's private ip
00:16:50 <kerneldove> etc
00:16:53 <polarian> kerneldove: yes iirc you just specify the jail port after
00:16:55 <polarian> so
00:17:01 <kerneldove> ok nice thought so
00:17:05 <polarian> match in on $hostif proto tcp from any to $hostip port $someport rdr-to $jailip port $someotherport
00:17:08 <polarian> I think...
00:17:16 <polarian> :)
00:17:30 <polarian> I mainly know pf from OpenBSD, it differs slightly, but afaik that is the correct syntax
00:23:44 <kerneldove> man i've been so stressed wondering how tf i'm gonna allow network access to select services (ssh/rsync/sftp) in jails without giving them public ips
00:24:35 <kerneldove> i guess this scheme makes pinging jails impossible unless i created host forwards for that too?
00:24:50 <kerneldove> (not a deal killer jc)
00:25:53 <polarian> kevans: any docs to debug loader stages?
00:30:24 <kerneldove> polarian do you know about ping forwarding too?
01:54:10 <spork_css> some of MWL's footnotes are just good life advice: "If you don’t like your vendor’s answer, ask more loudly and with malice aforethought."
03:49:12 <kerneldove> how do you install pkgs into a jail that doesn't have public internet access?
03:50:39 <wez> You can setup separate routing in a gaol?
03:53:03 <kerneldove> gaol?
03:53:15 <kerneldove> i assume i can't use pkg -j since that runs from within the jail
03:53:42 <wez> kerneldove: yeah?
03:53:48 <kerneldove> so freebsd-update -j operates ON the jail, but pkg -j operates IN the jail? seems weird inconsistent
03:54:50 <kevans> freebsd-update -j is more like pkg -r
03:54:58 <kevans> but with the path resolved from `jls`
03:55:36 <kerneldove> would be nice if pkg had that too :/ seem slike a gap
03:55:43 <wez> You can give it a VNET to work with and then use ipfw or whatever to block traffic
03:55:58 <wez> Is that what you are refering to?
03:56:04 <kerneldove> wut
03:58:47 <kerneldove21> got d/c
03:58:49 <kerneldove21> wut?
04:59:24 <dkeav> dumb question, but is there any efforts to bring the openbsd pledge/unveil stuff into the FreeBSD kernel?
05:00:11 <dkeav> capsicum seems to be well nobody gives a shit about it and doesn't want to mess with it, and pledge/unveil stuff seem readily adopted
05:01:43 <dkeav> i mean at this point its okay to say maybe we were wrong and this is a better option etc
05:02:48 <dkeav> I just worry because of the AI find exploits thing and its going to be predominately 3rd party stuff and we have zero way to protect ourselves from it
05:06:11 <kerneldove21> does actually noone give  shit about capsicum?
05:10:13 <kevans> no
05:10:51 <kevans> it hasn't seen widespread adoption, but we still deploy it in base utilities
05:11:18 <spork_css> nobody ever evangelized it that I'm aware of, couldn't even give you a one sentence summary of what it is but I guess SE-Linux-like?
05:11:34 <kerneldove21> hopefully it keeps being spread into base
05:11:47 <kerneldove21> like ucl and other freebsd tech, constantly spreading slowly but surely
05:11:58 <kerneldove21> like jails spreading to now have service jails
05:14:11 <dkeav> well it just seems like capsicum is very difficult to implement
05:14:22 <dkeav> so, it doesn't get implemented
05:14:38 <dkeav> i dunno, maybe there are options here
05:16:10 <kevans> spork_css: selinux is more like MAC
05:16:21 <kevans> except gross
05:16:30 <dkeav> lol
05:17:03 <kevans> you boot a linux system and see that selinux is enabled, your first thought is "ah shit"
05:17:27 <kevans> MAC? nah, it's helpful. it removed root from ntpd like a good guy
05:17:35 <spork_css> IIRC it's like someone's thesis originally or something? some relation to oxford? I only have vague vibes on it.
05:18:31 <dkeav> granted in SELinux they're trying to tackle the userland security at the kernel level but they don't have a userland
05:18:37 <dkeav> FreeBSD does
05:19:29 <spork_css> the last thing FreeBSD introduced where I just jumped in really, really early was ZFS. Prior to that a 2.2.7-stable snapshot where CAM was brought in (we had a fancy RAID controller that in some way required something that CAM introduced - I think something really silly like addressing multiple LUNs or something.
05:20:10 <kerneldove21> if you install a pkg with pkg mypkg, then you install the same pkg again with a jail root like pkg -r ... mypkg, will it download mypkg again or is there a cache that'll be used?
05:20:11 <dkeav> yea i remember when some jerkass mentioned about boot environments with zfs being a killer feature in solaris
05:21:58 <kevans> kerneldove21: iirc pkg -r sandboxes itself to the root these days, it wouldn't have access to system cache
05:22:28 <kevans> don't quote me on that
05:25:04 <spork_css> We ran some stats to compare running just a pair of (very expensive at that time) SSDs for postgresql servers to a pair of "enterprise" 7200 RPM SATA drives, but backed with a pair of small Intel 320 SSDs as ZIL/L2ARC and that's when we bought in fully.
05:25:45 <spork_css> The ZIL basically let us *safely* cache atomic writes at SSD speed instead of HD speed is the most basic way to explain it.
05:25:50 <kerneldove21> swap && zfs is a hairy thing to me but aside from that zfs is gold
05:25:59 <spork_css> So a filesystem saved us a shitload of money.
05:26:55 <spork_css> I still don't put swap on zfs, I imagine it works now, but I still partition the same - gpt w/boot - swap - zfs  (or add in EFI if you're doing that)
05:27:40 <kerneldove21> ya i don't use swap unless i'm running single disk zfs
05:28:19 <spork_css> I think part of what swayed us was that lots of people with influence in the PostgreSQL community were banging on it immediately, and there were also people running PG on Solaris back then, so they came in with knowledge.
05:28:57 <spork_css> since it's late night, some #social-ish material: https://imgur.com/a/Il89ch4
05:29:20 <spork_css> unpacking and finding 90's things...
05:30:31 <dnp1> Walnut Creek, nastolgia
05:47:40 <kerneldove21> so instead of running pkg within a jail, and running pkg ON a jail, i change pkg bootstrap -f to pkg -r /zroot/jails/myjail bootstrap -f?
12:05:38 <polarian> kenichi: you cant ping something which you do not have access to.
12:05:43 <polarian> it would eliminate the point of ICMP
12:06:39 <polarian> kenichi: as for pkg installation on airgapped containers, you can proxy the pkg repository using nginx on the host, and then you use the nginx on the host to install ports
12:06:53 <polarian> someone spoke about this recently on XMPP
12:07:14 <polarian> sorry I meant to ping kerneldove not kenichi I am so sorry...
12:07:21 <polarian> oh wait kerneldove isn't even in the channel
12:07:26 * polarian facepalms
15:35:37 <polarian> question, how many people here would refuse to attend an event if it was branded under FSF(E)? Would you attend an event if it was simply sponsored/supported by FSF(E)?
15:36:19 <polarian> I am finding it difficult to mix FOSS circles (FSF(E) endorsed) with BSD, because well... BSD folks tend to hate FSF(E)
15:37:03 <polarian> intentionally keeping this out of the ML, as I dont want drama around it, I just want an honest response from the community without archives
16:10:02 <wavefunction> polarian: There's a huge difference between hating the FSF as an entity (which I kinda do because they're so busy protecting Stallman), and FSF-endorsed stuff.
16:10:53 <wavefunction> Free Software is great, happy to take your money and tell you as an entity to go pound sand. (If grants require FSF influence, that's money with ropes, not strings)
16:38:37 <polarian> wavefunction: tl;dr I have an offer from FSFE I am turning down
16:38:54 <polarian> they want the branding for a series of meetups I am planning in London
16:39:22 <polarian> however its targetted at FOSS entirely, incl BSD
16:39:50 <polarian> last time I helped organise a FOSS meetup it was sponsored by FSF and BSD people got a little... yk...
16:40:05 <polarian> I know FSFE is a lot more mild than the FSF so probably wouldnt be as controversial, but still
16:40:25 <polarian> I will be running a meetup on 8th and I will let them take the branding for it
16:40:45 <polarian> but in the future I ideally want my own branding and for it to be across many groups (BSD, XMPP, FOSS)
16:41:14 <polarian> im not even looking for funding, all I wanted from the FSFE was advertisement, which they can do for free. Plus I donated to them :)
16:42:19 <polarian> I was originally looking to make a BUG (BSD User Group) but FOSS in the UK is in a bad place right now (little to no functional linux user groups, hackerspaces are actually makerspaces and are pretty hostile to free software in some cases), so I have pivoting to combine and run a joint effort for FOSS+BSD+XMPP
16:42:42 <polarian> but I cant combine 3 different interests together if I then brand it as a FSFE event, can I?
16:43:24 <polarian> I want it to be flexible, I dont want to be locked into a name or into a organisation which is advertising (or potentially funding) it
16:43:46 <polarian> anyways, I need to get the whole FDE stuff sorted because one of the servers which I want to use for it needs it done :)
16:43:47 <kerneldove> so instead of running pkg within a jail, i'm switching to running pkg ON a jail, and that means i change jexec -l myjail /bin/sh -c "pkg bootstrap -f | cat" to pkg -r /zroot/jails/myjail bootstrap -f | cat right?
16:44:24 <polarian> kerneldove: yes that *could* work
16:44:43 <polarian> but you wont be able to bootstrap pkg without network access in the first place
16:44:53 <polarian> you can copy /usr/ports into the jail (or mount it as a nullfs)
16:44:59 <polarian> and then make install the port
16:45:06 <kerneldove> network access where? the jail host has network access, the jail shouldn't
16:45:12 <polarian> yes
16:45:20 <kerneldove> WHERE
16:45:27 <polarian> to bootstrap the jail you need network access, your command is jexec the boostrap inside the jail
16:45:41 <polarian> "pkg boostrap -f | cat" is ran within the jail
16:45:49 <polarian> pkg bootstrap requires network access
16:45:49 <kerneldove> uh ya
16:45:53 <kerneldove> i didn't ask that
16:46:01 <polarian> then I am not sure what you are asking/
16:46:10 <kerneldove> i said that's the current command. i want to change it to run pkg -r
16:46:12 <kerneldove> so instead of running pkg within a jail, i'm switching to running pkg ON a jail, and that means i change jexec -l myjail /bin/sh -c "pkg bootstrap -f | cat" to pkg -r /zroot/jails/myjail bootstrap -f | cat right?
16:46:16 <kerneldove> read the whole question pls
16:46:33 <polarian> oh right
16:46:54 <polarian> no you dont need to boostrap the jail then
16:47:06 <polarian> afaik you can just use the -r flag with pkg on the host, and it will install the files into the directory
16:47:10 <polarian> I think!
16:47:20 <polarian> you will need to test it
16:47:50 <polarian> eg try
16:48:04 <polarian> pkg -r /zroot/jails/myjail install cowsay
16:49:12 <polarian> then run cowsay within the jail
16:49:16 <polarian> if it works as expected, it should work!
17:05:12 <polarian> so is there a freebsd dev willing to help me with debugging stage 1 loader to find out why its either ignoring loader.env or there is some bug in it?
17:05:30 <polarian> im not giving up on this :)
17:07:29 <kevans> sorry, dealing with ports tree things
17:24:57 <polarian> ah yes that fuck up, one of 3 in 48 hours xD
17:25:31 <polarian> seems like hell quite frankly, someone should buy ya'll a coffee (or a beer to drown out the suffering)
17:33:58 <jmnbtslsQE> polarian: i'm not a dev, but i read part of the previous conversation about this. my question is, would it solve your problem if you use gptboot instead of gptzfsboot? or does this also present the same hard-coded value?
17:35:36 <polarian> jmnbtslsQE: gptboot is for ufs afaik
17:35:38 <polarian> but no
17:36:13 <polarian> this is stage 1, and the issue lies with potentially either the parsing of the loader.env, or a bug within the stage 1 loader
17:36:28 <polarian> that is what I need to debug, but I dont know how to do this, and I will have to wait for a dev to become available to help mentor :p
17:37:22 <jmnbtslsQE> OK, i just thought that if gptboot had the value you wanted, you could put your kernel in a ufs partition then mountroot from a separate zfs-on-root partition
17:37:32 <kevans> polarian: i think you can move the devinit() call in loader's main() down a little bit to after we've adjusted `howto`, but i suspect this will not be enough
17:38:28 <kevans> polarian: i think the bits that read loader env would also need to move above cons_probe()
17:39:08 <kevans> i think both are safe to make, but it'd be worth confirming if you have the time.  just don't install either as loader.efi / bootx64.efi, install as a new one and create an `efibootmgr` entry for the test loader
17:40:07 <kevans> actually, maybe leave the ordering of loader.env w.r.t. `cons_probe()` alone fr the moment, it installs hooks that may just do the right thing
19:44:57 <black_mambet> how to patch kde2 for freebsd?
19:46:35 <black_mambet> как пропатчить кде2 под фрибсд?
19:50:20 <wavefunction> :/
19:50:29 <black_mambet> how to patch kde2 for freebsd?
19:52:43 <boru> I think you might have a network problem. Your ping is 26 years.
19:56:59 <sig`> lol or just lagged and now you're in the future
20:10:49 <black_mambet> is nvidia-driver-470 still supported on freebsd? if yes, which version of freebsd is recommended?
20:11:24 <black_mambet> if not, are there any out-of-tree patches or ports to make it work on the latest release?
20:15:53 <sig`> black_mambet: yes it is still supported and it works on the current release and no patches needed
20:16:12 <sig`> x11/nvidia-driver-470
20:20:50 <mary751> I run FreeBSD 15.1 in different machines as both a host (bhyve/Sylve) and as a virtual machine. I noticed there was a new warning about issues in ports repository freeze, also I noticed that if I run pkg update and pkg upgrade I see a ton of things being reinstalled/upgraded. I hope this is normal if anyone has any insight let me know! FreeBSD's announcement: https://lists.freebsd.org/archives/freebsd-announce/2026-July/000294.html
20:22:36 <sig`> markmcb: did you update your pkg package?
20:23:07 <sig`> sorry mary751
20:31:10 <mary751> I thought pkg package updates in pkg update && pkg upgrade
20:34:54 <sig`> those are unrelated, the freeze is just a git-side cleanup.
20:35:31 <sig`> looks like someone commited a 150mb blob, that must have broke the github mirrror and it doesn't touch the pkg at all
20:35:56 <sig`> prabably the big reinstall list is just the pkgbase
20:36:17 <sig`> what does, pkg which /usr/bin/uname
20:36:34 <sig`> it say FreeBSD-runtime ?
22:06:49 <kerneldove> i need to set up port forwarding through the public ip to the private ip of a jail, using pf. can i just enable gateway_enable or do i need to set net.inet.ip.forwarding = 1? or both?
22:12:39 <isley> that's all gateway_enable does iirc
22:15:40 <kerneldove> ok i'll go through that
22:15:46 <kerneldove> tyvm and nice scotch