01:02:54 <_xor> dch: Cool :) Thanks!
02:25:40 <johnjaye> will the videos from the developer summit be available to watch later?
02:41:25 <rtprio> mewt:      geli supports two encryption modes: XTS, which was standardized as IEEE P1619 and CBC with unpredictable IV.  The CBC mode used by geli is very similar to the mode ESSIV.
02:42:07 <rtprio> mewt: was that the package, or port? it could build yet be broken
03:56:36 <mewt> rtprio: package
03:56:50 <mewt> what about pbkdf re geli
03:58:21 <mewt> I guess I need to look into why exactly it is segfaulting, so I could try port with debug symbols possibly...
03:58:24 <mewt> sigh
04:47:20 <RhodiumToad> mewt: geli by default uses XTS and enough rounds of pbkdf2 to take 2 seconds on the current CPU
04:49:02 <RhodiumToad> mewt: the encryption mode and the number of pbkdf2 rounds can be specified as options when creating a provider or, for the iteration count, when setting a new key
04:51:03 <RhodiumToad> (pbkdf2 using hmac-sha512 as the pseudorandom function)
04:51:17 <mewt> ah
04:51:17 <_xor> Is there a CLI tool (similar to pw) to manipulate /etc/login.conf?
04:51:19 <mewt> ty
04:51:38 <RhodiumToad> _xor: no
04:51:42 <mewt> is argon2id planned at all?
04:51:45 <_xor> :|
04:52:26 <angry_vincent> it would require some work as many things needed be in base ( libargon library, etc )
04:52:40 <_xor> Feels hacky to do echo "..." >> /etc/login.conf + cap_mkdb
04:53:23 <RhodiumToad> note that geli needs to work in loader, which doesn't have unlimited memory
04:56:53 <_xor> Hmm, what are the reasons to NOT set a home directory for this daemon and place a .login_conf in there & use that class? (I'm sure there are good reasons, probably security-related, but can't think of any specifics off the top of my head)
04:57:42 <RhodiumToad> hm, I deliberately did not respeci ~/.login_conf in some places when I added the extra login class support a while back
04:57:47 <RhodiumToad> *respect
04:58:22 <RhodiumToad> let me look it up
04:59:35 <_xor> Basically I have a port with a rc script that invokes /usr/sbin/daemon + app process. The app requires mlock (512m-1024m or so) and I don't want to have to run it as root. So my options seem to be to create a new login class in /etc/login.conf and set app_login_class="..." in the rc script OR jail it, enable mlock on the jail, & let it have root
04:59:35 <_xor> inside the jail.
05:04:19 <RhodiumToad> app_login_class"..." doesn't respect ~/.login_class
05:04:40 <RhodiumToad> (I didn't change that)
05:05:08 <_xor> I was wondering about that :/ I saw a comment I wrote a while back in this service script that specifically says that.
05:05:12 <RhodiumToad> you can specify limits directly in app_limits="..."  in rc.conf
05:05:18 <_xor> "// TODO: Figure out why this isn't setting the login class properly"
05:05:42 <RhodiumToad> app_login_class  basically does  limits -C ...   for which see the manpage
05:05:52 <_xor> Yeah saw that in /etc/rc.subr
05:06:00 <_xor> Guess I'm going to do that.
05:06:02 <RhodiumToad> also, app_login_class only sets limits, not environment or other settings
05:06:33 <_xor> Wait, so that means setenv and the like would be ignored for that?
05:07:34 <RhodiumToad> unfortunately yes
05:10:31 <RhodiumToad> I significantly expanded the extent to which environment vars from login classes were respected, but I didn't change everything
05:11:20 <_xor> No biggie, good to know. Going to use app_env, app_env_file, and app_limits.
05:12:27 <RhodiumToad> ~/.login_conf wouldn't have worked for another reason: when it is respected, it's run with the user's permissions and not root's
05:12:39 <RhodiumToad> so it can't increase hard limits
05:13:52 <_xor> I was about to say that's what I want actually, to limit the service user/process, but then realized you need root (wheel?) privileges to set those limits FOR the subject.
05:14:41 <RhodiumToad> you said you wanted it to be able to use mlock
05:15:13 <RhodiumToad> by default there's a hard limit of memorylocked of 64kB or whatever
05:15:23 <_xor> Is it required to run the process as root for that or is setting memorylocked=2048M enough for the login class?
05:15:24 <RhodiumToad> and only root can increase that
05:15:45 <RhodiumToad> if you set memorylocked in /etc/login.conf, then that setting is processed as root
05:16:33 <_xor> Yup, that's what I'm doing now. It's why I asked about the CLI tool for /etc/login.conf instead of doing echo "..." >> /etc/login.conf earlier.
05:26:12 <_xor> Yay, it all works as intended.
05:26:13 <RhodiumToad> I wonder if we should have a /etc/login.conf.d
05:26:20 <_xor> YES
05:27:28 <_xor> I use that kind of approach in a few places. My rc scripts use ETCDIR/profiles.d/... to read environment variables for various profiles, which can be activated via app_profiles="profile0 profile1 ..." in /etc/rc.conf.
05:28:00 <_xor> Obviously for /etc/login.conf.d it would just parse the files in there, but it would also make merging easier when updating.
05:28:33 <_xor> Either that or /usr/local/etc/login.conf.d
05:28:48 <RhodiumToad> that would be more iffy
05:29:20 <RhodiumToad> though actually, since it'd all be handled in cap_mkdb, maybe not
05:30:09 <_xor> Oh /etc/login.conf is a static string in there?
05:30:19 <RhodiumToad> no
05:34:17 <RhodiumToad> it'd be a matter of doing  cap_mkdb -f login.conf.db /etc/login.conf /etc/login.conf.d/*
05:34:33 <RhodiumToad> er, lose the .db
05:34:43 <RhodiumToad> or  cap_mkdb /etc/login.conf /etc/login.conf.d/*
05:35:51 <RhodiumToad> some people have grumbled about wanting login.conf to be optionally in UCL, too
05:36:28 <_xor> The syntax is a bit uncommon in that file as it currently is, at least it is to me.
05:36:38 <RhodiumToad> it's the same as termcap
05:37:30 <_xor> Yeah, still take a few seconds to adjust for me since I mostly use YAML/JSON/HCL. But that's just in my scenario.
05:41:13 <meena> opening login.conf is like taking a time machine
05:42:28 * RhodiumToad is always a bit skeptical of UCL; a "universal" configuration language that doesn't even have a wikipedia entry
05:43:22 <otis> i wonder what semantics should login.conf.d files have, eventually. if concatenate them (or read one by one) or have login.conf.d/$(username) or login.conf.d/$(classname)
05:43:34 <_xor> HCL isn't bad. I read grumblings about YAML, and I'm sure they're there, but I haven't yet run into many problems with it. I use yq heavily to query YAML files.
05:43:42 <RhodiumToad> login.conf.d/username wouldn't really work
05:44:40 <Beladona> it seems one same drive, the zfs has created limits on each pool size. If i freeup the space on one pool, will the other pool get some space too?  I have 2 databases on 2 pools but drive is same. If I delete one database, will I get space on the other pool?
05:44:54 <_xor> ~/.login_conf is nice because it's clearly scoped to the user and also doesn't need to be processed via cap_mkdb (IIRC).
05:44:55 <RhodiumToad> login.conf.d/classname would work as a convention, but one might not want to enforce it
05:45:13 <RhodiumToad> _xor: you recall correctly
05:45:38 <RhodiumToad> _xor: but it's under the user's control and therefore can only do nonprivileged setup
05:45:50 <_xor> It's the system-wide stuff that felt hacky to me so far, hence liking the idea of /etc/login.conf.d/...
05:47:22 <_xor> I wish py-jc supported FreeBSD commands a bit better. For whatever, it's not parsing rsync output correctly.
05:49:08 <_xor> I have a script that gets invoked by the bulk.sh hook in poudriere. Part of that involves copying the packages to a remote repo and regenerating the repository there.
05:49:54 <_xor> During that process, it uses rsync --archive --delete --itemize-changes ..., and I wanted to be able to create an easy-to-read, clear list of creations/modifications/deletions.
05:51:24 <_xor> Oh yeah, that's right, I also had to split the passed in origin to get the base package name and delete any older versions in the remote repo, otherwise pkg on the clients was crying about duplicate dependency listings.
06:56:13 <RhodiumToad> oh dear, I get to write another bug report against fsck
07:16:34 <meena> RhodiumToad: there's a load open right now
07:18:55 <meena> how do i explain to this person that nobody is going to get this fixed for 12.3 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271465
07:18:57 <VimDiesel> Title: 271465 – Fatal trap 1: privileged instruction fault
07:26:18 * RhodiumToad submits bug
07:31:15 <rtprio> does windows home now have hyperv?
07:37:06 <Beladona> OBS studio when installed, removes neovim. Its a lib issue I think. Don't know when it will be solved. Meanwhile, can i install the linux's version of obs?
07:42:31 <RhodiumToad> how did you install it and what message did you get about neovim?
07:45:22 <RhodiumToad> looks like a conflict between lang/luajit and lang/luajit-devel
07:48:44 <rtprio> Beladona: what are you talking about with your pools and limits on pool size?
07:49:59 <Beladona> RhodiumToad https://imgur.com/3iWekbp.png
07:50:33 <RhodiumToad> right, luajit conflict as I said
07:50:50 <Beladona> what can I do now?
07:51:16 <Beladona> rtprio its sorted now. I used df -h that I shouldn't have and got false info
07:51:25 <RhodiumToad> poke the port maintainer for OBS to see whether the luajit version can be updated? (luajit 2.0 is pretty old)
07:52:15 <RhodiumToad> or poke the port maintainer(s) for luajit for the conflicts to be resolved
07:52:40 <Beladona> or install the linux ports version of obs?
07:52:56 <RhodiumToad> you could try, but I doubt that will work well.
07:53:10 <Beladona> because its a  linux port?
07:53:55 <RhodiumToad> what "linux ports version" are you referring to?
07:54:08 <Beladona> I heard we can install linux apps in freebsd
07:54:19 <RhodiumToad> yes, I run a printer driver that way
07:54:36 <Beladona> not sure how. and why it won't work well (obs)
07:55:49 <RhodiumToad> obs is very multimedia-heavy, so you'll need a lot of prerequisite linux packages
07:56:06 <Beladona> ok
07:56:20 <RhodiumToad> if there are ports for all the dependencies, it might be straightforward
08:16:19 <meena> poweroff in the installer reboots, actually 😒
08:17:05 <yuripv> it doesn't for me
08:18:08 <RhodiumToad> poweroff generally works by asking ACPI to power off, but what happens then is largely out of freebsd's control
08:18:11 <yuripv> and you mean the "Shutdown" in the "final" menu, right?
08:20:01 <meena> yuripv: no, i mean, i was in the shell, doing some modifications, then, when i was done, I said: "poweroff", and it rebooted instead.
08:20:23 <RhodiumToad> running on real hardware or a VM?
08:20:24 <meena> which is very annoying, cuz it meant that cloud-init was running without any data-source, so it took about 3 minutes to do nothing
08:20:27 <meena> RhodiumToad: vm
08:20:35 <RhodiumToad> what hypervisor?
08:20:37 <meena> libvirt/kvm
08:20:43 <yuripv> fix it! :D
08:20:53 * RhodiumToad points to previous statement about ACPI
08:20:55 <meena> this was with the i386 ISO on amd64 "hardware"
08:21:08 <meena> once booted, poweroff worked as expected
08:21:42 <meena> anyway, i now have an i386 "golden" image. on to amd64
08:22:01 <meena> need to do some tests of the current patchsets, and when I'm happy with that, I can move on to other ventures
08:31:55 <yuripv> meena: works for you? (re: 271465)
08:44:19 <meena> yuripv: i don't use Virtualbox, and i stopped using 12 as soon as 13 was branched :P
08:45:25 <meena> yuripv:  but, the reporter themselves said that 12.4 works, but they've been instructed to use 12.3, which, i mean, come on! it's panicking. Your instructions are either bunk, or you now need to learn how to patch FreeBSD and recompile it, and you need to find the patch you need to backport to 12.3
08:46:13 <yuripv> (i meant my update in there :D)
08:47:04 <meena> yuripv: yes, that's a very nice way of saying what i just said
08:48:24 <parv> meena! For the diplomat!
08:50:52 <meena> need to update https://github.com/canonical/cloud-init/blob/main/templates/ntp.conf.freebsd.tmpl with https://reviews.freebsd.org/D39954
08:50:53 <VimDiesel> Title: cloud-init/ntp.conf.freebsd.tmpl at main · canonical/cloud-init · GitHub
08:51:13 <parv> Earlier today on "https://bugs.freebsd.org/bugzilla/" both pages "Bugs (reported|changed) in ... last 7 days" looked very similar. Not having "reported" or "changed" on the page title, could not tell if I had seen one or the other already
08:51:48 <parv> s/today/today via/
08:52:20 * parv curses self for butchering the correction
08:55:54 <meena> i wonder if this would've been merged quicker if i had submitted it via github: https://reviews.freebsd.org/D39975
08:55:55 <VimDiesel> Title: ⚙ D39975 tools/git: ensure git-arc is more platform indepdendent
08:56:28 <RhodiumToad> does ports take github submissions now?
08:56:37 <RhodiumToad> oh wait, that's src
09:06:27 <meena> I don't think ports does
09:06:33 <meena> src and doc do
10:50:27 <meena> same thing, different virtualisation: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271484
10:50:29 <VimDiesel> Title: 271484 – Guest OS Rocky Linux 9.1 freezes sporadically
13:11:58 <luser> .
13:12:11 <luser> .
17:12:08 <Beladona> How to know the /dev/deviceName of a pool?
17:16:51 <futune> zpool list -v
17:17:18 <Beladona> I get gpt/zfs00erwe dev ide. not dev name
17:17:41 <futune> ah, so it was imported with gpt label
17:18:00 <Beladona> how to konw the /dev/name
17:19:51 <futune> "geom part list" will tell you
17:20:53 <futune> something like "geom part list | grep -C 10 zfs00erwe"
17:21:47 <spork_css> PSA: The performance impact of a nearly-full zfs pool on spinny disks is beyond negligible
17:22:10 <Beladona> great
17:32:04 <hectorgrey> evenin' all
17:35:08 <rtprio> Beladona: there isn't a /dev/deviceName of a pool
17:35:25 <rtprio> it's not in /dev/ ? what ae you trying to do?
17:35:37 <Beladona> I found it with what futune said
17:36:09 <Beladona> rtprio no straight forward way to find what is the dev name of the disk used in a pool? e.g /dev/ada1
17:36:10 <rtprio> but that's the components of the pool, not the pool itself
17:36:27 <rtprio> Beladona: mine shows in `zpool status`
17:36:34 <Beladona> mine shows the gpt id
17:36:42 <Beladona> node the /dev/ada1
17:36:47 <rtprio> did you create the pool with the gpt id?
17:36:49 <Beladona> I traced it via geom
17:36:54 <Beladona> do not recall
17:37:05 <Beladona> but all good now anyway
17:37:48 <rtprio> 👍
17:57:13 <CrtxReavr> 14:47 < ChrisWarrick> where do you even get 10 TB of software
17:57:15 <CrtxReavr> 14:47 < dcb> emacs?
18:00:10 <Demosthenex> hehe. you meant docker ;] emacs is skinny nowadays.
18:01:38 <CrtxReavr> I didn't mean anything. . .
18:01:45 <CrtxReavr> But that was funny either way.
18:02:23 <futune> games these days can be hundreds of GiB...
18:03:49 <CrtxReavr> The Point.
18:03:51 <CrtxReavr> You missed it.
19:55:50 <_xor> Heh, who said that quote about any non-trivial software will eventually end up with its own implementation of SMTP? (or something like that)
19:58:43 <gcd> something about a non-trivial programming language containing most of a lisp?
20:00:10 <_xor> Yeah, something like that. There are a few quotes akin to it. I think the one I'm thinking of had to do with Adobe Acrobat and it's crappy implementation for sending SMTP messages.
20:00:14 <mason> https://en.wikipedia.org/wiki/Greenspun%27s_tenth_rule
20:00:16 <VimDiesel> Title: Greenspun's tenth rule - Wikipedia
20:00:16 <_xor> Something similar about Emacs too.
20:02:03 <_xor> “I’ve finally learned what ‘upward compatible’ means.  It means we get to keep all our old mistakes.”
20:02:09 <_xor> Wouldn't that be backwards compatible?
20:26:39 <meena> _xor: jwz
22:44:49 <hyperreal> For some reason syslogd is not forwarding logs to my configured remote logging host.
22:45:15 <hyperreal> it only works when I use `logger -h remotehost Test`
22:45:38 <hyperreal> if I use `logger Test`, it doesn't work, nor do any other logs get forwarded by the daemon
22:48:35 <rtprio> what's the snipet you have to send logs to the remotehost ?
22:49:28 <hyperreal> what do you mean? from /etc/syslog.conf?
22:50:22 <hyperreal> *.* @remotehost
22:51:22 <rtprio> are they both freebsd machines?
22:51:34 <hyperreal> No, the remotehost is a Fedora Linux
23:30:41 <_xor> Doesn't emacs recognize a signal to cancel the current operation?
23:31:01 <_xor> Nevermind, got it.