dch: Cool :) Thanks!

will the videos from the developer summit be available to watch later?

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.

mewt: was that the package, or port? it could build yet be broken

rtprio: package

what about pbkdf re geli

I guess I need to look into why exactly it is segfaulting, so I could try port with debug symbols possibly...

sigh

mewt: geli by default uses XTS and enough rounds of pbkdf2 to take 2 seconds on the current CPU

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

(pbkdf2 using hmac-sha512 as the pseudorandom function)

ah

Is there a CLI tool (similar to pw) to manipulate /etc/login.conf?

ty

_xor: no

is argon2id planned at all?

:|

it would require some work as many things needed be in base ( libargon library, etc )

Feels hacky to do echo "..." >> /etc/login.conf + cap_mkdb

note that geli needs to work in loader, which doesn't have unlimited memory

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)

hm, I deliberately did not respeci ~/.login_conf in some places when I added the extra login class support a while back

*respect

let me look it up

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

inside the jail.

app_login_class"..." doesn't respect ~/.login_class

(I didn't change that)

I was wondering about that :/ I saw a comment I wrote a while back in this service script that specifically says that.

you can specify limits directly in app_limits="..." in rc.conf

"// TODO: Figure out why this isn't setting the login class properly"

app_login_class basically does limits -C ... for which see the manpage

Yeah saw that in /etc/rc.subr

Guess I'm going to do that.

also, app_login_class only sets limits, not environment or other settings

Wait, so that means setenv and the like would be ignored for that?

unfortunately yes

I significantly expanded the extent to which environment vars from login classes were respected, but I didn't change everything

No biggie, good to know. Going to use app_env, app_env_file, and app_limits.

~/.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

so it can't increase hard limits

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.

you said you wanted it to be able to use mlock

by default there's a hard limit of memorylocked of 64kB or whatever

Is it required to run the process as root for that or is setting memorylocked=2048M enough for the login class?

and only root can increase that

if you set memorylocked in /etc/login.conf, then that setting is processed as root

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.

Yay, it all works as intended.

I wonder if we should have a /etc/login.conf.d

YES

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.

Obviously for /etc/login.conf.d it would just parse the files in there, but it would also make merging easier when updating.

Either that or /usr/local/etc/login.conf.d

that would be more iffy

though actually, since it'd all be handled in cap_mkdb, maybe not

Oh /etc/login.conf is a static string in there?

no

it'd be a matter of doing cap_mkdb -f login.conf.db /etc/login.conf /etc/login.conf.d/*

er, lose the .db

or cap_mkdb /etc/login.conf /etc/login.conf.d/*

some people have grumbled about wanting login.conf to be optionally in UCL, too

The syntax is a bit uncommon in that file as it currently is, at least it is to me.

it's the same as termcap

Yeah, still take a few seconds to adjust for me since I mostly use YAML/JSON/HCL. But that's just in my scenario.

opening login.conf is like taking a time machine

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)

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.

login.conf.d/username wouldn't really work

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?

~/.login_conf is nice because it's clearly scoped to the user and also doesn't need to be processed via cap_mkdb (IIRC).

login.conf.d/classname would work as a convention, but one might not want to enforce it

_xor: you recall correctly

_xor: but it's under the user's control and therefore can only do nonprivileged setup

It's the system-wide stuff that felt hacky to me so far, hence liking the idea of /etc/login.conf.d/...

I wish py-jc supported FreeBSD commands a bit better. For whatever, it's not parsing rsync output correctly.

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.

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.

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.

oh dear, I get to write another bug report against fsck

RhodiumToad: there's a load open right now

how do i explain to this person that nobody is going to get this fixed for 12.3 bugs.freebsd.org/bugzilla/show_bug.cgi?id=271465

Title: 271465 – Fatal trap 1: privileged instruction fault

does windows home now have hyperv?

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?

how did you install it and what message did you get about neovim?

looks like a conflict between lang/luajit and lang/luajit-devel

Beladona: what are you talking about with your pools and limits on pool size?

RhodiumToad imgur.com/3iWekbp.png

right, luajit conflict as I said

what can I do now?

rtprio its sorted now. I used df -h that I shouldn't have and got false info

poke the port maintainer for OBS to see whether the luajit version can be updated? (luajit 2.0 is pretty old)

or poke the port maintainer(s) for luajit for the conflicts to be resolved

or install the linux ports version of obs?

you could try, but I doubt that will work well.

because its a  linux port?

what "linux ports version" are you referring to?

I heard we can install linux apps in freebsd

yes, I run a printer driver that way

not sure how. and why it won't work well (obs)

obs is very multimedia-heavy, so you'll need a lot of prerequisite linux packages

ok

if there are ports for all the dependencies, it might be straightforward

poweroff in the installer reboots, actually 😒

it doesn't for me

poweroff generally works by asking ACPI to power off, but what happens then is largely out of freebsd's control

and you mean the "Shutdown" in the "final" menu, right?

yuripv: no, i mean, i was in the shell, doing some modifications, then, when i was done, I said: "poweroff", and it rebooted instead.

running on real hardware or a VM?

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

RhodiumToad: vm

what hypervisor?

libvirt/kvm

fix it! :D

this was with the i386 ISO on amd64 "hardware"

once booted, poweroff worked as expected

anyway, i now have an i386 "golden" image. on to amd64

need to do some tests of the current patchsets, and when I'm happy with that, I can move on to other ventures

meena: works for you? (re: 271465)

yuripv: i don't use Virtualbox, and i stopped using 12 as soon as 13 was branched :P

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

(i meant my update in there :D)

yuripv: yes, that's a very nice way of saying what i just said

meena! For the diplomat!

need to update github.com/canonical/cloud-init/blo…ain/templates/ntp.conf.freebsd.tmpl with reviews.freebsd.org/D39954

Title: cloud-init/ntp.conf.freebsd.tmpl at main · canonical/cloud-init · GitHub

Earlier today on "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

s/today/today via/

i wonder if this would've been merged quicker if i had submitted it via github: reviews.freebsd.org/D39975

Title: ⚙ D39975 tools/git: ensure git-arc is more platform indepdendent

does ports take github submissions now?

oh wait, that's src

I don't think ports does

src and doc do

same thing, different virtualisation: bugs.freebsd.org/bugzilla/show_bug.cgi?id=271484

Title: 271484 – Guest OS Rocky Linux 9.1 freezes sporadically

.

.

How to know the /dev/deviceName of a pool?

zpool list -v

I get gpt/zfs00erwe dev ide. not dev name

ah, so it was imported with gpt label

how to konw the /dev/name

"geom part list" will tell you

something like "geom part list | grep -C 10 zfs00erwe"

PSA: The performance impact of a nearly-full zfs pool on spinny disks is beyond negligible

great

evenin' all

Beladona: there isn't a /dev/deviceName of a pool

it's not in /dev/ ? what ae you trying to do?

I found it with what futune said

rtprio no straight forward way to find what is the dev name of the disk used in a pool? e.g /dev/ada1

but that's the components of the pool, not the pool itself

Beladona: mine shows in `zpool status`

mine shows the gpt id

node the /dev/ada1

did you create the pool with the gpt id?

I traced it via geom

do not recall

but all good now anyway

👍

14:47 < ChrisWarrick> where do you even get 10 TB of software

14:47 < dcb> emacs?

hehe. you meant docker ;] emacs is skinny nowadays.

I didn't mean anything. . .

But that was funny either way.

games these days can be hundreds of GiB...

The Point.

You missed it.

Heh, who said that quote about any non-trivial software will eventually end up with its own implementation of SMTP? (or something like that)

something about a non-trivial programming language containing most of a lisp?

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.

Title: Greenspun's tenth rule - Wikipedia

Something similar about Emacs too.

“I’ve finally learned what ‘upward compatible’ means. It means we get to keep all our old mistakes.”

Wouldn't that be backwards compatible?

_xor: jwz

For some reason syslogd is not forwarding logs to my configured remote logging host.

it only works when I use `logger -h remotehost Test`

if I use `logger Test`, it doesn't work, nor do any other logs get forwarded by the daemon

what's the snipet you have to send logs to the remotehost ?

what do you mean? from /etc/syslog.conf?

*.* @remotehost

are they both freebsd machines?

No, the remotehost is a Fedora Linux

Doesn't emacs recognize a signal to cancel the current operation?

Nevermind, got it.