Yay, 13.4! \o/

interesting, doas mount directory_which_is_in_fstab fails

Are you looking for sympathy or debugging? If sympathy then, "Well that's just terrible! I feel your pain." If debugging then, "What error message was emitted when it failed?"

sympathy because IDK if I should submit a bug report

oh, interesting, the bug stems from doas mount not taking $PWD into account, so { cd /mnt; doas mount fs/ } fails, but { doas mount /mnt/fs } succeeds

but umount works

oh nevermind, it didn't work either way

Mounts should always be absolute paths.

At least mounts using /etc/fstab should always be absolute paths. So that the string matches what is in the file.

except ZFs mounts which are relative paths

(not that you would usually mount zfs in fstab)

True that zfs is its own special case.

a bit off-topic, but there's a bug inside my 4K monitor and I no longer have warranty. Will it disintegrate/disappear slowly, or should I buy a new 4K, 5K, 6K, or 8K or is there something newer (10K) as long as they don't have *BSD driver issues?

darwin: what do you mean by "a bug"? like literally an insect lives inside your monitor?

yes: two actually. The first one did disintegrate/disappear

fortunately they so far go all the way down to the bottom left where it's not a big issue unless I'm fullscreen graphics-editing at those pixels (not many)

i'd give it a go with compressed air

well if you want to buy a new monitor, i'd say 4k is fine for most desktops, if you have a Mac consider 5k because of the strange way display scaling works on that OS, definitely don't bother with anything higher

On OpenBSD and Linux, installing the "zimg" package includes the libraries (.so and .a), but on FreeBSD it doesn't apparently. Why is that?

Ah, nevermind, I see I had to install "zbar" as well in order to get the libraries.

[00:00:10] [01] [00:00:00] Inspecting devel/popt | popt-1.19_1: determining shlib requirements

this is new, what does 'determining shlib requirements' mean?

kevans: sorry for the delay, (CEST tz here, I was sleeping) , yes I performed 3 freebsd-update install

oh no

Error: (2474) _mktemp:_mktemp:260: mkstemp failed on /poudriere/data/logs/bulk/main-lf/2024-09-17_07h54m48s/.write_atomic-.poudriere.snap_loadavg.HQa1OkM8: No space left on device

never saw this before, i wonder what changed

lw: that error makes me recall a rust build problem I had

there was an adjustment in poudriere.conf for tmp space for the build process to set

i already have USE_TMPFS=no

(in poudriere.conf)

oh wait i found the problem

[8!] daphne /usr/local/etc# df -h /

Filesystem Size Used Avail Capacity Mounted on

zroot/ROOT/default 5.5G 5.5G 0B 100% /

(as I had several problem in building rust on my poudriere vm, i decided to use poudriere-devel and fetch as many pkg as I can in dependancies, (with rust being one of this dependancy)

somehow /src/obj is 221GB

reset

i refuse

does anyone know which pkg is the 'dns' package for python 311 ?

I try import dns and it says the module can't be found

last1: py311-dnspython

holy shit my ports build actually finished

let's see if upgrading works

sidh: how much RAM on this guy?

kevans: 1GB RAM for the first, and 2 GB RAM for the second (proxmox VM , few services)

sidh: ZFS or UFS?

an associate noted they've seen similar failures in low RAM environments where the update ends up only sporadically deployed

dch: oh, hey

kevans: sup

dch: sidh just above is the one with that very partially updated system I mentioned

sidh: heya

yes, so I have seen this a couple of times on my mini-VMs (they act as ssh jump hosts, and run a lightweight auth services)

typically 1G RAM, and sometimes swap gets a little high

sidh: my speculation is that theres not enough ram during unpack or fetch, so box just runs out of memory and stuff randomly gets OOM killed

I don't see this every time, but I've seen it enough to know to run `freebsd-update IDS` *before* the reboot.

dch: thanks for the tips, will add that IDS to the routine

but here the question remains if the problem is not due to the freebsd-update -b -d procedure (as usually, we create a bootenv, and upgrade it once mounted)

in the first context of the bug, it is from a jail context, so with my BE, I'm in the same context

oh, someone marked it closed

kevans: really am sorry for my weird inconsistent system

sidh: we all have our snowflakes

I don't think the memory constraint would be any different if you do freebsd-update into a jail

btw I tried rustdate.over-yonder.net/download.html last week

its very nice, very fast.

also very new and you may find different/new/other bugs

freebsd-update written in rust, so no shell forking.

I read about the brainstorming in including rust in the basesystem, I have to admit that my first reaction was FEAR (several poudriere bulks that failed during rust after 12 hours+ building time) , but rust apps are known for their efficiancy, so I am quite wondering about it

^ weird right ?

jb1277976: Not really. afaik, pkg info shows info of *installed* packages.

aw

you can tell i'm still a noob

Everyone was, once. Contrary to belief, even the hardest bofh wasn't born with the knowledge. :)

yep, every bofh was once a pfy :P

Did you find out the differences between pkg-search(8) and pkg-info(8), then? ;)

I have an internal process use for symmetric encryption.

Previously I have used GnuPG v1 but GnuPG v2 makes non-interactive use if not impossible then so difficult that I haven't been able to accomplish it safely and securely yet.

I am contemplating using openssl encryption. Is there wisdom from the community that they might want to hint to me?

too many variables / what are you encrypting?

In this particular case it is part of server provisioning and I am encrypting a secrets.tar.gz of information targeted to a server. ssh host keys. https certs.

The entire process is rather involved but this is information which shouldn't be publicly available but I must transport from the secrets vault to the server getting provisioned.

you don't generate ssh host keys on the host itself?

anyway openssl could probably be fine for this

Can't. Let's take Github as an example. Let's say that every time you did a clone or push that it informed you that the host keys had changed?

When a new system is spun up to perform a role it must use the same role keys that have already been distributed by TOFU.

sure, ok

Handling secrets vault information in a secure way is one of those tedious details that makes provisioning, well, tedious!

Non-secrets details have a dozen competing infrastructures for provisioning. Such as puppet, chef, salt, ansible, and so on.

I wrote my own so of course I use my own. But they all fill the same conceptual block in the block diagram.

In GnuPG v2 it appears they decided to embrace interactive use only. gpg starts up a persistent gpg-agent to handle the passphrase interaction. Which if interactive would open a GUI dialog and interact with the user. I don't want that in batch mode operation acting automatically in a root privilege process. Avoiding that seems impossible. Working securely with that behavior will be tricky.

Seems the only answer is to abandon that tool. Therefore I must use another.

Humor found in gpg(1) man page "--no-use-agent This is dummy option. gpg2 always requires the agent."

in my case i use puppet with hiera, and with hiera i can use eyaml

root::salt: ENC[PKCS7,MIIBmQYJKoZIhvcNAQc...]