02:24:19 <skered> Is there a good reason find's user/group column is so long?  Other than it's been that way forever.
02:24:40 <skered> find's -ls.
03:08:52 <rtprio> probably the max length of a username or groupname
03:08:55 <rtprio> guessing
03:09:01 <rtprio> also: never used -ls
03:45:03 <tehpeh> Hey all, I'm looking for opinions: is there any reason or include or exclude boot environments from my zroot backups (handled by zfs-autobackup)?
03:46:30 <tehpeh> Two disadvantages I found so far: the snapshots for each BE are huge on my external backup disk, and second have a zfs hold on them so I can't easily run 'bectl destroy ...' to clean them up.
03:59:17 <ek> tehpeh: If the system boots and runs fine with no reason to to use any of the backups, you're completely free to delete them.
04:06:00 <tehpeh> ek: thanks, that's what I was thinking. Also with a years worth of auto-snapshots I could rollback anyway
04:06:25 <tehpeh> ...if I ever needed to
04:09:04 <ek> tehpeh: Depending on what the auto-snapshots are of, sure. If you're strictly talking about automated snapshots that happen before, say, a "freebsd-update" or something, those are safe to destroy if you're certain the currently active system is working. Old boot environment snapshots (especially really old) almost never need to be kept.
04:10:01 <ek> I usually keep just the previous BE snapshot. Active BE and one snapshot before "just in case." Otherwise, I wipe out anything older since it's basically useless (to me.)
04:11:24 <tehpeh> the auto-snapshots are created by zfs-autobackup via a daily cron job, so in theory they should cover the same peroid of any freebsd-update BE created during that time
04:11:41 <tehpeh> ooh, I'm keeping the last year of BEs... that does seem like overkill
04:21:00 <ek> I don't auto-remove them or anything. I just check periodically to make sure I'm not housing massive amounts of unneeded snapshots. Especially for the BE's.
04:22:02 <ek> I only clean them up maybe once a quarter or something. After a lengthy run of a stable system, of course.
04:59:32 <tehpeh> ek:sounds like a good plan, thanks
05:00:34 <ek> tehpeh: Sure thing. Hopefully, it all works out! (I don't see why it wouldn't)
05:03:38 <tehpeh> For those following, if you want to exclude BEs from snapshots made by zfs-autobackup, you can do that with, for example:
05:03:38 <tehpeh> zfs set autobackup:local=parent zroot/ROOT
05:03:38 <tehpeh> zfs set autobackup:local=true zroot/ROOT/default
05:07:18 <ek> Good to know, but I wouldn't recommend not backing up BE's. Of course, with autobackup, they may not be needed if the BE isn't being changed.
05:12:12 <ek> I still use my own custom snapshot script to backup everything I need to via cron. Hasn't failed me yet. Of course, there's been many projects providing the same thing over the years. I just haven't had a reason to migrate (yet.)
09:58:50 * Alver wonders who on earth thought it would be a good idea to silently override bitcoind.conf parameters in /usr/local/etc/rc.d/bitcoin, making files end up in the entirely wrong spot
10:08:29 <ix> is there an offtopic channel
10:09:14 <ix> yes
10:09:14 <paulf> freebsd-social
10:09:19 <ix> ty
10:52:48 <DarkUranium> Any CBSD users here? I'm trying to sort out my networking, and running into a problem.
10:53:35 <DarkUranium> tl;dr I'd like to have both jails and bhyve on 10.0.0.0/16 ... *that* part is working, I can even access the internet, ping everything on it, etc.
10:54:03 <DarkUranium> But local_unbound, listening on 10.0.0.1 (and with whitelisted access from 10.0.0.0/16) seems to be unreachable from VMs (but not from jails), with "connection refused".
11:44:34 <wunky> /3
12:09:05 <pertho> is anyone running redis server in a FreeBSD Jail (Yes, I know about "valkey").. what magic do you need to do with the "bind" and "tcp-backlog" to get it to run?
12:10:05 <pertho> I have to use 'bind <JAIL IP>' ? Seems 'bind *' makes it fail immediately
12:22:39 <harlan> I'm trying to use freebsd-update to update a 13.2-RELEASE box to 13.4, and one of the update files is not present.  freebsd-update -v debug ... says:
12:22:46 <harlan>  http://update2.freebsd.org/13.2-RELEASE/amd64/m/c00708e8651995c89a10e44bb04789ca96dc1021ab7b43ef1b7291e6f59cc1cc.gz: 404 Error (ignored)
12:22:57 <harlan> ideas on how I can fis this?
12:33:51 <voy4g3r2> does freebsd-update  -r 13.3-RELEASE fetch install give same result?
12:34:34 <voy4g3r2> i meant freebsd-update -r 13.3-RELEASE upgrade
12:45:44 <harlan> I'll try now...
12:46:32 <pertho> for non-VNET jails.. is '127.0.0.1' in the Jail treated as the Jail's IP itself to everything else?
12:46:32 <harlan> Yes, I get the same error trying to upgrade from 13.2 to 13.3
12:49:08 <voy4g3r2> pertho: within the jail do a ifconfig
12:53:23 <pertho> voy4g3r2: bastille0: flags=1008049<UP,LOOPBACK,RUNNING,MULTICAST,LOWER_UP> metric 0 mtu 16384 options=680003<RXCSUM,TXCSUM,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6> inet 10.100.0.4 netmask 0xffffff00 groups:lo
12:53:43 <pertho> I guess the jail treats' 10.100.0.4' as loopback/127.0.0.1 ?
12:54:22 <voy4g3r2> and when you do bind * redis goes.. piss off?
12:54:31 <pertho> I wonder if it'd be more secure to just export a socket from one jail to allow another jail to access rather than using the network stack?
12:54:50 <pertho> voy4g3r2: it was saying couldn't look up *::
12:55:02 <voy4g3r2> personally, i setup epairs for each jail and give it a unique ip address and use that ip address
12:55:21 <voy4g3r2> assuming this jail, you are setting up, is a VNET one?\
12:55:26 <pertho> yeah I'm not using VNET in this case
12:55:57 <pertho> setting redis to use: "bind 127.0.0.1 -::1" appears to make it listen on the bastille0 IP (10.100.0.4)
12:56:05 <mzar> pertho: from the host you can mount the FS with the sockest from one jail to another using nullfs
12:56:13 <voy4g3r2> or that
12:56:36 <voy4g3r2> pertho: correct, which will get "lost" because it is like what does 127.0.0.1 mean
12:56:44 <pertho> yeah .. socket has less overhead than a network connection.. (less to build up/tear down) yeah?
12:57:17 <voy4g3r2> that is an evaluation answer.. network stack, is easier for me.. because managing ip addresses in general are easier to me
12:57:29 <voy4g3r2> the "overhead" does not become a concern until it is :)
12:57:47 <mzar> it's also commont practice to have additional lo interface in the jail and run services on that address, it can be 127.0.x.1, where x≠0
12:57:59 <harlan> voy4g3r2: I'm not surprised that upgrading to 13.3 also failed, as the file it's looking for is in the 13.2/ subdir.
12:58:26 <pertho> mzar: there is lo0 but no addresses bound to it
12:58:48 <mzar> so you have to assign one
12:59:16 <mzar> whole 127.0.0.0/8 is for loopbacks
13:01:04 <mzar> but it has to be something else than lo0
13:02:01 <mzar> pertho: it looks like voy4g3r2 is also loopback
13:02:08 <mzar> so you have one
13:02:55 <voy4g3r2> https://pastebin.com/2h0W97Qw
13:03:02 <voy4g3r2> this is how i setup vnet jails
13:03:45 <pertho> yeah I don't have a specific need for a VNET jail in this case
13:04:16 <mzar> yes, usually we don't need vnet
13:05:27 <mzar> when you have loopback, all the services inside the jail will bind on the address of that loopback instead of 127.0.0.1
13:07:04 <mzar> sometimes VNET is required though, for example if you need to setup poudriere in the jail
13:13:40 <pertho> if only if it were that complex :D  Nah, I'm just running separate nginx, php, redis and mysql jails
13:14:31 <f451> gitmir.geo.freebsd.org has IPv6 address 2a02:80:0:3ffd::24ca:1 and responds "fatal: Could not read from remote repository." for git pull. Other IPs in gitmir.geo.freebsd.org work.
13:16:35 <f451> git pull is via ssh://anongit⊙gfo/ports.git
14:11:52 <DarkUranium> pertho: I don't recall having any issues running Redis in a jail.
14:11:56 <DarkUranium> But it's been a while.
14:12:36 <DarkUranium> pertho: You use bastille?
14:13:39 <ketas> i wonder who uses 127/8 anything other than just localhost
14:14:24 <ketas> s/anything/for anything/
14:15:25 <satanist> systemd-resolvd uses 127.0.0.53
14:16:13 <ketas> besides that?
14:16:29 <ketas> it also doesn't help that things assume
14:16:44 <ketas> 127/8 = localhost
14:16:52 <ketas> not just 127.0.0.1
14:40:32 <pertho> DarkUranium: yeah, using bastille
14:40:38 <pertho> the templates are very cool
14:41:08 <pertho> what's the best place to nullfs a socket from one jail into another? does it go in the jail's fstab or..?
14:42:29 <DarkUranium> pertho: Yeah, kind of deciding between {Bastille,AppJail}+vm_bhyve, or CBSD.
14:42:37 <DarkUranium> They all have templates of one sort or another.
14:42:55 <pertho> I'd only use bhyve if the apps I'm trying to run don't run in FreeBSD
14:43:05 <DarkUranium> Same. And unfortunately, I have a few of those.
14:43:09 <pertho> (or you actually need another OS)
14:43:16 <DarkUranium> (Linuxisms ...)
14:43:26 <pertho> yeah.. Linuxisms.. I hate 'em
14:44:18 <pertho> seeing now as more script kiddies are making malware for Linux. FreeBSD might be a much safer bet for security, plus.. Jails..
14:44:35 <DarkUranium> I've used FreeBSD for *aeons*.
14:44:59 <DarkUranium> But I do have a handful of Linux servers, mostly for stuff where pretty much the only distribution channel is Docker .....
14:45:10 <DarkUranium> Well, and gameservers. Those, I can *kind of* excuse, I guess?
14:45:15 <DarkUranium> (it's better than just Windows, at least)
14:46:21 <pertho> I'm making a proof-of-concept FreeBSD server with jails for $WORK.. one of the other sysadmins at work constantly gives me grief for using BSD, even though OpenBSD happily passed a ton of packets seamlessly and without issue for the past 12 years.. Want to make this rock solid and fast. Next step is getting MySQL and ZFS happy with each other
14:46:34 <DarkUranium> Nice!
14:47:26 <pertho> sadly, our dual OpenBSD failover (carp(4)) firewalls are being retired when we move to the new office next week. New company is using FortiGate and Juniper (*vomit*).. but won't be my responsibility any more :D
14:47:34 <DarkUranium> I'm moving my own stuff, which is currently a mishmash, to reproducible things. I figured I'll keep a strict directory repr (+ loop mounts to "adapt" where needed), so that I can backup trivially.
14:48:33 <DarkUranium> Basically separating `system` (non-persistent, possibly read-only), `cache` (persistent, but *not* backed up), `config` (persistent, possibly read-only [depending on the application, some need to write this]), and `data` (similar to config, but always read-write, and generally much bigger than config *and* updated more often)
14:48:39 <pertho> but I wanted to make this PoC to see if it would blow our Ubuntu Linux servers out of the water.. and ZFS.. can take snapshots every hour.. yeah Linux has ZFS support but I bet it's baked into FreeBSD better than it is on Linux
14:48:52 <DarkUranium> Yeah, it is ^^
14:49:09 <DarkUranium> zfs just saved my ass when my webhost went downhill (straight off a cliff in a manner of days, really)
14:49:19 <pertho> nice!
14:49:22 <DarkUranium> Basically, I did a zfs send to a backup server, and I do incremental sends periodically.
14:49:43 <pertho> I heard it's better security if the backup server can pull
14:49:49 <DarkUranium> (the server's still on that host until I rent a new one ... still evaluating them, but I'd *first* like to decide on above jail+bhyve options)
14:50:09 <DarkUranium> That makes sense, because pushing onto backup server means that the other one needs direct access. Write, in a sense.
14:50:16 * f451 uses tarsnap for backups
14:50:16 <DarkUranium> If the backup server pulls, you can even have it behind NAT!
14:50:20 <pertho> but yeah the hope is FreeBSD with all the web nonsense and moving bits in their own jails.. for security
14:50:36 <DarkUranium> That's *exactly* what I've been doing for years now :)
14:50:58 <DarkUranium> The only thing running on the "host" is currently a nginx reverse proxy (and next time, I'm thinking I'll jail that too).
14:51:19 <DarkUranium> (and I'll probably use HAproxy instead)
14:51:35 <DarkUranium> (not really unhappy with nginx, as much as I've been meaning to try HAproxy --- I have another similar setup that's based on it)
14:51:38 <pertho> right now I got (for the jails)  1) nginx reverse proxy (does letsencrypt, SSL termination)  2) php/web jail (runs nginx and php_fpm)   3) redis jail (just runs redis cache)   and will have 4) mysql jail.. you reckon it's best to keep them separated like that?
14:51:51 <DarkUranium> I have like ... 15 or something. I lost count.
14:52:36 <pertho> we've been using nginx for 14 years.. we're used to it. Been meaning to try out 'caddy' though.. but we lock down where PHP can run (for obvious reasons)
14:53:03 <rtprio> pertho: caddy does kind of feel weird but it 2 lines per vhost sure beats the 20 or so lines of nginx boilerplate
14:53:07 <DarkUranium> welp
14:53:10 <DarkUranium> # iocage list -h | wc -l
14:53:10 <DarkUranium>       40
14:53:16 <DarkUranium> pertho: I guess 15 is ... wrong.
14:53:23 <DarkUranium> (and yes, iocage .... the server is *OLD*)
14:53:24 <pertho> \o/
14:53:32 <DarkUranium> (not happy with iocage though)
14:53:53 <pertho> rtprio: yeah nginx.. so much boilerplate. What's the performance of caddy, in your experience?
14:53:59 <DarkUranium> rtprio: I make use of nginx's includes to do that part.
14:54:08 <pertho> can it handle high amount of connections/traffic?
14:54:20 <DarkUranium> What I've actually been meaning to do is make use of Dhall, Cue, or Jsonnet, and auto-(re)generate the full nginx config on changes.
14:54:32 <DarkUranium> (plus DNS and so on, I'd like to be able to access the jails by name via DNS)
14:54:39 <rtprio> pertho: it handles my homelab, including streaming jellyfin, so fine for my use
14:55:17 <DarkUranium> My own never even shows up in `top` (and a bunch of those jails *also* run nginx, mind --- mostly to adapt things for applications that rely on a reverse proxy)
14:55:22 <DarkUranium> (also PHP, etc)
14:55:25 <rtprio> DarkUranium: i hide the boilerplate in puppet, but it's still boilerplate
14:55:30 <DarkUranium> Fair.
14:56:01 <DarkUranium> I don't mind the boilerplate. Nginx is a good balance between Apache's .... whatever-you-might-call-it and Caddy's implicit assumptions.
14:56:11 <rtprio> pertho: my only complaint with caddy is it seems to take a long time with a soft restart
14:56:20 <DarkUranium> Quite happy with HAproxy too, I only have one nitpick with it, but it doesn't affect production.
14:57:35 <pertho> rtprio: how long is a long time?
14:57:57 <rtprio> more than a minute
14:58:07 <DarkUranium> rtprio: I've never used Puppet, how does it operate? Is it declaration-based like Terraform (i.e. you describe the full system state and it kind of does diffs), or how does it work?
14:58:10 <pertho> DarkUranium: we have much, much nginx boilerplate in Ansible (used to be Puppet 4 but we ditched Puppet)
14:58:21 <DarkUranium> Ditto for Ansible, I guess :D
14:58:27 <rtprio> service caddy restart is fast; caddy reload feels like it times out
14:59:05 <rtprio> DarkUranium: yeah, puppet changes your system to reflect its concept of state. i like the syntax better than terraform
14:59:09 <DarkUranium> Nice.
14:59:25 <DarkUranium> TBH, I've been kind of tempted to integrate this entire thing w/ Nomad, but ... extending Nomad with custom executors (to be able to adds jails + bhyve) is a PITA.
14:59:35 <DarkUranium> And I'd *still* need some custom work anyway, for the reverse proxy.
14:59:48 <td123> I recently installed freebsd on my desktop, and blindly assumed I could use binary packages for everything. But it /sounds/ like ports are maybe preferred? https://docs.freebsd.org/en/books/handbook/ports/#ports-using mentions you shouldn't mix ports and binary packages. If so, is there a way to automatically reinstall the binary packages to port equivalents?
15:00:07 <pertho> I don't like Puppet now that I've switched to Ansible. The problem with Puppet is, if you're ever dependent on an external Source of Truth (tm) - like over https.. and that source of truth goes down.. Puppet will merrifly bork your server config with bad stuff :D
15:00:31 <pertho> (when the server checks in with Puppet)
15:00:34 <DarkUranium> td123: I pretty much exclusively use binary packages, TBH. I only use ports if there isn't a package for a version I need (yet) or somesuch.
15:00:45 <DarkUranium> pertho: damn
15:00:55 <mzar> td123: you can mix everything as far as you are able to main it
15:00:58 <DarkUranium> In my case, it'd be on the same server, so that's less of a problem.
15:01:04 <mzar> s/main/maintain
15:01:30 <rtprio> pertho: yeah, the source of truth is the puppet server, not some external http server
15:02:05 <rtprio> but coding everything in yaml, jfc there has to be a better way
15:02:12 <DarkUranium> But yeah, I've been half-tempted to make my own thing, ha.
15:02:19 <rtprio> just having data (puppet's hiera) in yaml is bad enough
15:02:32 <rtprio> without inline yaml ansible scripts
15:03:02 <td123> DarkUranium: mzar: ok thanks, I'll keep using binary then
15:03:26 <DarkUranium> rtprio: You might actually enjoy one of those I've mentioned (Cue, Dhall, JSONNet). They can all export to YAML.
15:03:28 <DarkUranium> And/or JSON.
15:03:43 <pertho> rtprio: not if you have hiera pulling in external things from another https server like we had :D
15:03:51 <rtprio> json is for machines, not for typing by hand
15:04:05 <rtprio> jsonnet is tolerable, but seesh
15:04:17 <DarkUranium> Yeah, of those 3, that's the one I liked the least.
15:04:52 <DarkUranium> Cue is the most limiting of these (I *really* miss functions ...), but I enjoyed toying around with it.
15:04:57 <DarkUranium> Haven't used it in anger yet, though.
15:07:41 <pertho> anyway.. I don't suppose Bastille has a way to create zfs data sets? I only see zfs get/set in the template language
15:08:34 <pertho> I guess I'd have to: 1. bastille create ... 2. Do a zfs create on the dataset in the path in /usr/local/bastille/jails/.../root/var/lib/mysql and all that, then install MySQL in the jail and start it up?
15:09:35 <DarkUranium> lmao
15:09:46 <DarkUranium> One of the servers I just setup backups for, I was wondering why a logfile took so long to back up ...
15:09:52 <DarkUranium> -rw-rw-r--    1 1006     1006        9.5G Jul  2  2024 FactoryGame.log
15:10:58 <DarkUranium> I'd help you, but I've never, ever used Bastille, so.
15:11:00 <pertho> DarkUranium: is that file on zfs dataset? What does zfs get compressratio give you? :D
15:11:12 <DarkUranium> pertho: alas, Linux, because UnrealEngine game.
15:11:21 <DarkUranium> (Satisfactory, in case you're curious ... and I didn't even run it for that long ...)
15:11:34 <DarkUranium> Actually, it's on a zfs dataset now (the backup is)
15:11:38 <pertho> going to be nice to have web logs and cruft on lz4 compressed ZFS disks.. they'll take up such little space because most of the logs are repetitive
15:11:47 <DarkUranium> I actually did zstd because backups.
15:12:01 <pertho> is there much overhead with zstd?
15:12:25 <DarkUranium> Compute, sort of? There is a fast mode, but it targets better compression rather than CPU time.
15:12:29 <DarkUranium> (though it *is* fast nevertheless)
15:12:49 <DarkUranium> Mind, the backup is on spinning platters, so compression is probably going to read faster than uncompressed :P
15:14:34 <DarkUranium> pertho: I just checked. I don't know what the compression ratio on the log file alone is (I guess I'll zstd it manually just to see --- I'm deleting it anyway), but the entire thing is 3.31x.
15:14:45 <DarkUranium> Mind, that includes (already-compressed) game assets, binaries, etc.
15:16:32 <pertho> 3.31x is pretty good!
15:16:35 <DarkUranium> pffft
15:16:36 <DarkUranium> FactoryGame.log      :  2.68%   (10207489230 => 273515071 bytes, FactoryGame.log.zst)
15:16:46 <DarkUranium> 261MB vs 9.5GB
15:17:03 <DarkUranium> Taking the reciprocal, that's 37.31x :D
15:17:07 <rhaberkorn> I understand that in order to get something financed by the FreeBSD foundation, you basically have to team up with a committer. https://freebsdfoundation.org/get-involved/project-proposal-overview/
15:17:59 <DarkUranium> pertho: 1.74x after deleting this one file xD
15:19:35 <DarkUranium> Still not half bad for (after deleting the log) 22GB of data.
15:20:06 <pertho> better than a kick in the teeth :P
15:20:09 <DarkUranium> lol
15:20:34 <DarkUranium> But anyway, yeah, what I was thinking was of using Cue, Dhall, or whatnot to --- essentially --- make my own mini-Ansible/Puppet.
15:21:13 <pertho> https://cuelang.org/ ?
15:21:15 <DarkUranium> Especially since I want to do some high-level configs.
15:21:15 <DarkUranium> Yeah.
15:21:45 <pertho> the micromanagement is strong with this one
15:21:51 <DarkUranium> Hush! :P
15:22:18 <DarkUranium> It's more, there's so much stuff I need to configure at a high level. And I haven't found a decent alternative to Terraform yet, though I might try puppet.
15:22:33 <DarkUranium> Is that one any good with jails & bhyve? FreeBSD in general, I guess.
15:22:46 <pertho> use the best tool for the job.. might mean testing all kinds of things :)
15:22:52 <rtprio> tf and puppet solve different problems, really
15:23:09 <rtprio> so i find it extremely unlikely puppet would work as an alternative
15:23:21 <pertho> puppet's ABI moves fast and breaks more things than Ansible's does
15:23:30 <pertho> just from my experience
15:23:41 <rtprio> pertho: well, it's going to be closed source, so they solved that problem for you
15:24:02 <rtprio> puppet's abi changes with plenty of notice on major releases, sometimes
15:24:05 <DarkUranium> pertho: yeah, hence me going through Cue, Dhall, and JSONNet. I actually started investigating that for some game config, initially, ha.
15:24:15 <DarkUranium> Well, a game's data (think properties of individual objects, etc)
15:24:20 <pertho> rtprio: oh wow.. Puppet is going closed source? o_O
15:24:32 <DarkUranium> Well, that rules that out :|
15:24:47 <rtprio> vox will be forking it
15:25:35 <DarkUranium> I didn't know P4 owned Puppet. I have trauma from their source control -_-
15:25:44 <rtprio> DarkUranium: so do i
15:26:10 <DarkUranium> Apparently since May 2022.
15:26:48 <pertho> We used librarian-puppet extensively and it drove me mad
15:27:06 <pertho> I much preferred to write my own code not use other peoples' bad buggy code
15:27:09 <DarkUranium> The more I hear about this mess, the more I'm thinking of just rolling my own >_<
15:27:29 <pertho> DarkUranium: you know, that's probably for the best!
15:27:55 <DarkUranium> There's also the TrueNAS situation, I wonder what will become of that. Talks about forks, but nothing exists yet.
15:28:30 <pertho> maybe you're better off rolling your own NAS
15:28:44 <DarkUranium> Yeah, exactly. I mean, it's not super-hard to do.
15:28:54 <DarkUranium> The builtin alerts in the web UI were handy, but.
15:31:16 <DarkUranium> pertho: to be honest, something like sftpgo and/or minio plus {rsync,rclone,zfs send|recv,rdiff-backup} would handle pretty much everything I need ATM.
15:31:22 <rtprio> wait, what happened to truenas
15:31:38 <rtprio> (i've always rolled my own nas)
15:31:54 <DarkUranium> rtprio: "TrueNAS Core", which was the FreeBSD-based thing, is being discontinued ... in favour of "TrueNAS Scale" which is Linux, and not even that focused on being a NAS anymore (they talk a lot about containers, etc)
15:32:16 <DarkUranium> The last official release was 13.0, and the last semi-official was 13.3.
15:32:58 <pertho> FalseNAS
15:33:04 <rtprio> if it's not freebsd then why even bother with it
15:33:08 <DarkUranium> pertho: on the topic of rolling my own, I do have an experimental server setup, but the one thing I still haven't figured out is why my bhyve jails can't access local_unbound ...
15:33:13 <DarkUranium> rtprio: exactly.
15:33:33 <rtprio> but then what was the point of a (i'm assuming) web ui to run `adduser` and `zfs create`
15:33:38 <DarkUranium> I did recently learn of: https://xigmanas.com/xnaswp/
15:33:39 <DarkUranium> But yeah.
15:33:43 <pertho> DarkUranium: maybe use a bridge for bhyve? I'm not that familiar with bhyve, personally.
15:34:10 <DarkUranium> rtprio: It did do a bunch of other stuff, like NFS, smb, and (most importantly for me) a nice dashboard for various disk & resource-related alerts.
15:34:20 <DarkUranium> Nothing I can't live without, though --- and/or setup myself.
15:34:48 <pertho> DarkUranium: Prometheus and Grafana perhaps? :)
15:35:27 <DarkUranium> Yeah, I didn't know of it at the time (if it even existed, that server is *also* old :P)
15:35:56 <DarkUranium> pertho: On the topic of a bridge, I do have one. The server's listening on 10.0.0.1, which is setup as the resolver in bhyve.
15:36:02 <DarkUranium> But for some reason, the connection gets rejected.
15:36:07 <DarkUranium> I suspect firewall issues, but not sure.
15:36:26 <DarkUranium> Incidentally, it has no problems accessing the DHCP server, which is sitting on the same IP.
15:36:32 <pertho> pflog(4) is your friend
15:38:19 <DarkUranium> Yeah, need to figure it out properly.
15:55:33 <pertho> looks like I need to create the jail with bastille, then: zfs create -o recordsize=16k -o mountpoint=/usr/local/bastille/jails/alcatraz/root/var/lib/mysql jails/bastille/jails/alcatraz/mysql_data
15:57:01 <DarkUranium> HMM, SUS
15:57:21 <DarkUranium> If I turn off local_unbound, I get "REFUSED" only after a delay, as opposed to immediately. I think it might be local_unbound refusing it for whatever reason.
15:57:52 <pertho> IIRC, you need allow statements in unbound to allow clients to query
15:58:26 <pertho> ah ha it's /var/db/mysql LOL
15:58:51 <DarkUranium> pertho: they do exist, I suspect unbound's seeing a different IP incoming than the bhyve's external.
15:59:44 <pertho> DarkUranium: not NAT'ing are you?
15:59:56 <DarkUranium> I ..... what? `refused query from 10.0.1.1 port 43995 because of 0.0.0.0/32 refuse
15:59:56 <DarkUranium> `
16:00:01 <DarkUranium> Sorry about the newline.
16:00:11 <DarkUranium> pertho: I am, yeah. Or trying to, anyhow.
16:02:25 <DarkUranium> OMFG, I'M AN IDIOT
16:02:35 <DarkUranium> Excuse me while I go jump out a window or something.
16:03:15 <DarkUranium> pertho: So uhm ... you know how the bhyve VM has an IP of 10.0.1.1?
16:03:25 <DarkUranium> Well, I wanted to allow any 10.*.*.* ...
16:03:35 <DarkUranium> So, in my brilliant genius, I wrote 10.0.0.0/24.
16:03:37 <DarkUranium> Because brain fart.
16:03:59 <DarkUranium> It was refusing because it was told to do so, since 10.0.1.* is not in 10.0.0.0/24.
16:10:46 <pertho> 10.0.0.0/23 then? :D
16:10:52 <DarkUranium> lol
16:10:59 <DarkUranium> Well, I actually wanted /8, so :D
16:11:24 <pertho> overly broad, but if nothing else in your network uses 10/8, it should be OK :D
16:12:03 <DarkUranium> It's just for the DNS server, so.
16:12:25 <DarkUranium> The actual jails et. al. are on /16, so I figured I'd expand it a bit for any "external" thingies.
16:12:51 <DarkUranium> I noticed I say "so" a lot, so.
16:24:50 <pertho> is it best practice to create a zfs dataset outside of a jail, then use 'zfs jail' to attach it to said jail?
16:25:12 <DarkUranium> Probably, considering you need to explicitly give a jail permission to manipulate zfs datasets.
16:25:15 <DarkUranium> This way, it has fewer rights.
16:25:23 <pertho> that makes sense
16:26:14 <DarkUranium> On the topic of configuration languages, just learned of this one: https://nickel-lang.org/getting-started
16:53:40 <pertho> any special magic getting mysql working in a jail? When I start up mysql: /usr/local/etc/rc.d/mysql-server: WARNING: failed precmd routine for mysql
17:00:37 <xx> can someone explain which one of these information is the correct one? The website lists a version as both production/legacy https://0x0.st/8itF.png
17:03:13 <xx> and then on the download page https://0x0.st/8itC.png
17:03:19 <xx> it lists two different versions as production
17:13:04 <DarkUranium> pertho: I don't recall ever having problems, so. Hm.
17:13:14 <DarkUranium> Might be a permissions issue due to the mount?
17:37:31 <DarkUranium> xx: all of these are in support, that's why they're listed
17:37:37 <DarkUranium> And the "legacy" one is the previous major version
17:37:48 <DarkUranium> You probably want 14.2.
17:48:52 <pertho> ah.. I think it was innodb_use_atomic_writes.. was removed.. but yeah.. not sure how to handle the mysql data.. I got two pools 'zroot' (the main OS with a small-ish disk) and 'jails' a big disk I allocated just for the jails. I don't think 'zfs jail' is the right way to do this is it? What's the best practice for mounting zfs datasets into jails?
17:49:53 <xx> DarkUranium: ok
17:56:04 <DarkUranium> Not sure, I tended to use higher-level tools, so ...
18:08:53 <xx> who is Colin Percival <cperciva⊙Fo> and why are they pgp signing the checksums now instead of Glen Barber <gjb⊙Fo>?
18:09:00 <xx> they are not listed on the /security page
18:11:22 <xx> not here either https://docs.freebsd.org/en/articles/pgpkeys/
18:11:47 <xx> not here either https://docs.freebsd.org/en/books/handbook/pgpkeys/
18:19:24 <rtprio> afaik Colin is the release manager
18:23:18 <xx> has there been any announcement about the change of who signs the stuff now?
18:24:16 <xx> maybe this, but I don't know how legitimate the site is https://freebsdfoundation.org/blog/guiding-the-future-of-freebsd-releases-colin-percival-the-new-release-engineering-team-lead/
18:36:28 <rtprio> he's been the one for years
18:36:40 <rtprio> like four or more years
18:52:34 <xx> can someone please paste the full fingerprint of his pgp key in here? just so that I have additional verification
19:03:05 <Nicholaus04> Howdy, folks!
19:39:16 <DarkUranium> I almost forgot, this is another config lang: https://github.com/bazelbuild/starlark
19:39:23 <DarkUranium> It's basically a subset of Python, kinda.
21:16:05 <CrtxReavr> xx, rtprio, I feel like "Release Engineering Team Lead" is kinda of a dumbing down in title. . . for a long time he was the Security Officer Emeritus.
21:16:41 <xx> it would be appropriate to list him on the mentioned links
21:18:59 <CrtxReavr> 'Course. . . I guess once you're "Emeritus," you always are.
21:22:07 <luke_jobless_sb> xx: i've seen the name in videos for release/cloud related manage and profiling iirc.
21:33:44 <pstef> armin: https://reviews.freebsd.org/D48347 ls: --group-directories=first/last
21:40:53 <thorongil> hi there.  i'm trying to figure out whether my freebsd system is up to date.  i run freebsd-version -u or -k to get the patchlevel, but i can't seem to find any resources online that tell me what the current patchlevel is for each released.  i would have thought it would appear on the release errata page, but i'm not seeing it.  what am i missing?
21:45:56 <thorongil> if i click on the individual security advisories, it says what patchlevel the fix appears in, but (as far as i can tell) it doesn't say whether userland or kernel, and it would be more transparent if the main errata page clearly listed the current patchlevel.  assuming i'm not missing it.
22:19:35 <harlan> On a 13.2-RELEASE box I have, freebsd-update -v debug -r 13.4-RELEASE says: ...
22:19:54 <harlan> http://update2.freebsd.org/13.2-RELEASE/amd64/m/c00708e8651995c89a10e44bb04789ca96dc1021ab7b43ef1b7291e6f59cc1cc.gz: 404 Error (ignored)
22:19:57 <harlan> http://update2.freebsd.org/13.2-RELEASE/amd64/m/c00708e8651995c89a10e44bb04789ca96dc1021ab7b43ef1b7291e6f59cc1cc.gz: 404 Error (ignored)
22:20:40 <harlan> (sorry for the 2ble pste).  I'm not seeing that file on the 'net; ideas on how I can fix this?
22:44:02 <CrtxReavr> 13.2-RELEASE is EOL, so. . . definitely no.
22:44:56 <CrtxReavr> That info is literally always near the top of the freebsd.org main page.
22:50:09 <Remilia> thorongil: release patch levels can differ for kernel and userland
22:53:12 <Remilia> also, you can check if your system is up to date by running `freebsd-update fetch`
22:56:02 <Remilia> thorongil: oh and you can subscribe (RSS) to https://www.freebsd.org/security/feed.xml
23:18:05 <thorongil> Remilia: exactly.  the fact that userland and kernel versions can differ makes the patchlevel list on the errata pages much less useful.
23:18:38 <thorongil> and rss is nice for getting periodic updates, but less convenient if i want to check what the current patchlevel is
23:50:43 <harlan> CrtxReavr: That file is necessary to update to subsequent releases.  There are 3 files that get downloaded to update to a more recent version, and that one file is missing.