github.com/cowsql/cowsql#compatibility — cowsql runs on Linux and requires a kernel with support for native async I/O (not to be confused with POSIX AIO), which is used by the libuv backend of C-raft.

Title: GitHub - cowsql/cowsql: Embeddable, replicated and fault tolerant SQL engine.

hrm…

we've got a libuv port, so i reckon that checks out

it's Tier 2, tho

nope

(i.e. a libuv port is not enough, C-raft is explicitly Linux-only)

oh… hrm.

it does say "Patches are welcome to add support for more platforms."

looks like it's not used in the agent

How can a python module not support creation of a wheel? devel/py-maturin

Isn't it just a zip file?

port claims i386 wheels aren't possible.

maturin has rust code

rust works on i386?

But if there's i386 rust is that still an issue?

rust doesn't work well on i386

works at a baseline, sure

specify "well"

memory addressing issues, amongst others

more easily seen when building/linking with LTO

I can't seem to find it now but I think this make samba not possible on 12.4

12.4 i386

rather

I don't see py-maturin as a dep of samba416

oh I was looking at the amd64 builder... yeah py39-maturin

It could be something else...

there was a recent fix of py-dnspython that dropped a lot of deps

but. beefy5.nyi.freebsd.org/build.html?m…=124i386-default&build=f6493e8ca127

search for samba in skipped

that build started before the py-dnspython fix went in

it's trying to build py-dnspython 2.4.0, while the fixed one is 2.4.1

so the next run might work

Was the fix to pull in devel/py-maturin?

"Reduce dependencies" so maybe

py-dnspython was depending on py-poetry, which has a dependency list 3 miles long, instead of py-poetry-core, which does not

py-maturin is a dependency of py-poetry

(as are both rust and gcc12, and TONS of other stuff)

(honestly, when a build tool is pulling in fortran and various linear algebra packages, something is a bit wrong)

ok it seems a dry run a testport of samba413 in a i386 appears to want to build so that's good.

I guess as long has security fixes are back ported to 4.13 I don't need to worry about my i386 samab that has been chunging along with a gmirror for the past 12 years.

and so it has come to this freshbsd.org/freebsd/src/commit/136…495615f6d5cf7fb2284aff56c59a64a58b6

Title: FreeBSD / src / 136fc49 / release: update main to ALPHA1 - FreshBSD

\o/

also, a fix for py-maturin just went in to add 32-bit support back in

i still gotta get around to trying rust

seems more than a fad

is the localhost of a jail its public ip? what if jails aren't given an ip and only the host has an ip?

anyone know why extattr_get_fd(2) is prohibited for processes that have entered capabilities mode?

lattera[defcon]: it's enabled for capmode

I note there's a rights(4) fd capability for that

(more importantly it's properly annotated CAPENABLED: cgit.freebsd.org/src/tree/sys/kern/syscalls.master#n1972)

Title: syscalls.master « kern « sys - src - FreeBSD source tree

there anything you gotta do in a bhyve vm that you can't do in a jail?

polyex: Run other operating systems…

oo tyvm

jails are kind of like slim FreeBSD VMs that are powered by the host's kernel

Rather than a VM guest running its own kernel

of XYZ operating system

you can keep jails totally separate from eachother with the right config right?

Well, that's kind of the point of jails because of the containerization

can a jail be immutable? and have all of its logging go out over the network?

readonly, immutable, whatever

I imagine so, yes. Just make the jail's contents read-only (e.g. chflags -R schg) after setting up the network logging.

i guess it's syslog doing the network logging? how does it handle buffering if network flaps?

otis: procstat man page need fixing. penv is only available to the superuser

Hi, in a new 13.2-RELEASE-p2 jail I want to run vim and I get: ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found

not really, it's available to root or owner? (i.e. you can see the env for the programs you are running as user)

uname -UK gives: 1302001 1300139

I did freebsd-update fetch install several times but it doesn't update anymore.

yuripv: when I run without sudo, the only output i get is: procstat penv $fish_pid

38252: fish

-

that's it

$ penv $(pgrep irssi) ... long list of env vars follows

same when called as `procstat penv`

is fish running as your uid?

__sysctl("kern.proc.env.86893",4,0x45b034e51980,0x1a39b66f8a18,0x0,0) ERR#1 'Operation not permitted'

I've got security.bsd.unprivileged_proc_debug=0 sweet, i wonder if that affects it

that's when i'm trying to look up syslogd env as user :(

meena: yeah, that is

what a bad sysctl, it breaks truss as well

and emaste wants to enable it by default in 15

well, not, it. all the security options in bsdinstall should just be enabled, and the screen removed

but i think this one is probably a bad call

or keep screen but have them all selected by default?

I'm creating a new jail from a 13.2-RELEASE-p2 host, but the newly created jail is 13.0-RELEASE

how to force creation of jails the same version of host?

polyex: maybe. i just realised it was planned for 14, hackmd.io/JczFDHtiQYSeEyeK9182jw?view and the blurb is quite unclear as to what it wants

Title: FreeBSD 14.0 Planning - HackMD

martinrame: how are you creating the jails?

meena: with bsdinstall jail /path/to/jail

So the main problem is, that once a release is cut, we don't update the images

meena: I now setted DISTRIBUTIONS, BSDINSTALL_DISTDIR and BSDINSTALL_DISTSITE to let me install 13.2-RELEASE, but I want from now on to have 13.2-RELEASE as the default install, instead of 13.0-RELEASE.

after 13.2p2 is released, an ISO still gets you 13.2. and so do the base.txz etc archives

what that means in practice is that after install, you need to freebsd-update

meena: yes I did freebsd-update fetch, then install, then reboot, then install, but the kernel didn't match with the host.

that just means that the kernel didn't need an update, only the user land

which i find hard to believe given the last errata, but who am I to judge

meena: but it's something broken, for example if I want to run vim I get: lib/libc.so.7: version FBSD_1.7 required by /usr/local/lib/libpython3.9.so.1.0 not found.

yes, that does look very broken

meena: but martinrame said 13.0 gets installed, not that 13.2-p0 gets installed

oh

wtf

meena: btw I just installed 13.2 and everything works. But I'm sure the next time I want to create a jail I'll have the same issue.

So do i understand you correctly, that if you don't specify anything on the bsdinstall command line, you get 13.0.sounds like something in your freebsd-update on your host went wrong

hm, was your vim not build for 13.0? (probably as that is eol); packages aren't guranteed to work if the builder has a newer system than you

meena: yes, that's the issue. Now I need to figure out how to fix that 13.0 issue, because the host is 13.2-RELEASE-p2.

nimaje: I don't now, the jail is new, just created. The first thing I do is: pkg install vim

a 13.0 jail on a 13.2 host should work fine

nimaje: yes!, but not in this case.

martinrame: why don't you run freebsd-update on the host, and see what happens?

so you installed from the official repos? they are currently build with 13.1 as far as I know

nimaje: old jail should work fine if you have packages for that old jail

meena: I'll try later. I cannot break everything on a friday morning.

right. that would be inconvenient

meena: hehe

I have been participating remotely at a developer summit at California time for the past two days, so my sense of time has gone to shit

meena: which language/framework?

martinrame: cloud-init

On that note "Terraform" now has Business Source License, if that matters to any one

seems like bsdinstall jail just tries to install whatever you have in /usr/freebsd-dist without checking any version by default, is there some good way to check which version that is?

BSL sounds like bullshit license.

:)

how does BSD sound then?

bullshit distribution.?

nimaje: don't know, but the files there are from jun/2021

I was feeling snarky

then it can be 13.0 at most, so safe to delete (if there are no files in there bsdinstall will download them)

nimaje: great, I'll move elsewhere and re-try.

can a jail be readonly and immutable? and have all of its logging go out over the network?

hm, kenrap already answered that to you last time you asked "I imagine so, yes. Just make the jail's contents read-only (e.g. chflags -R schg) after setting up the network logging."

polyex: what's the point?

to have predictable control over state

there are things which need to be writable, var/run etc.

but I guess you can add mountpoints as you see fit

hm ok. can logging at least be shipped over network?

it's not only about logging... sure you can ship stuff over network

of course your use case has to allow an immutable system with network logging

just mount an nfs onto var/log

i guess it's syslog doing the network logging? how does it handle buffering if network flaps?

depends on the underlaying vfs.. in case of nfs it would block

what do you want to run in the jail? you have to look how to make that to log via the network

another logging daeomon would also be a choice of course

Hello.

i'm trying # mount /dev/da0 /mnt

hi

but mount: /dev/da0: Invalid fstype: Invalid argument

i know that my SATA dongle is kind of broken

which fs do you expect?

Try with "-t" to specify the file system?

that was Linux drive (ext4)

maybe -t ext3 works?

not sure if we've full ext4 support

From The Ports

*ugh*

-t ext3 shows the same

21:40 < V-T60> but mount: /dev/da0: Invalid fstype: Invalid argument

Try with "fusefs-ext2" package (found via: pkg search -x ext | grep fuse)

there is sysutils/fusefs-lkl which says it supports ext4

parv: installing

nimaje, Thanks

where did it unlock something?

i see no difference

nimaje well can't syslog log over network rather than to /var/log/messages or whatever?

there are no new mount_* options in my shell

did it add something in my PATH?

oh, i see, lklfuse

is this right command? lklfuse -o type=ext4 /dev/da0 /mnt/

fuse: failed to open fuse device: No such file or directory

polyex: syslogd seems to need some paths writable (to put its sockets and pid file), but supports forwarding logs to another host, see syslog.conf

ty!

V-T60, did you load the fuse kernel module first? "kldload fusefs" as root.

megaTherion: i would just star… by trying.

?

V-T60: it's vanishingly unlikely that /dev/da0 is the correct device name, since that's the whole disk rather than some partition

megaTherion: build a jail, configure log shipping, make it immutable, start it and see what's failing

sure

meena that's what i was wondering. build a jail, configure log shipping, make it immutable, then start it and see in the shipped logs what's failing and address each item

and eventually have a jail template that's as immutable as possible, hopefully 100%

but i want 2 things i hope aren't mutally exclusive. i want immutable jails, but i also want jails totally isolated... from the host AND other jails

so basically jail state only changes through network interface

that make sense?

does the jail need any kind of myself storage?

myself?

mutable

I'm very tired, and took off my glasses, and this phone keyboard cannot read my mind

hopefully i can keep jails totally immutable

so if a jail needs to write, it'll do it with network writes

give each jail a small tmpfs for stuff like /var/run ?

sure

i guess step 1 is like meena said, get a jail installed configured to log ship, then look into how to make it immutable to then start seeing what fails in the logs. agree RhodiumToad?

what about /tmp and /var/tmp ?

symlinks are your friend?

have /var/run be a tmpfs and make /var/run/.tmp and link /tmp and /var/tmp to it

is /var/run/* and /var/log/* the only 2 parts of a fbsd install that change as a system is running?

is anything writing to /var/log except syslogd?

anything that does can prolly be configured to route into syslogd

or do its own network logging

I suppose some programs will write there

so that would eliminate /var/log as a change point

ya i'll just have to track those down upon failure

depends on what you got running. periodic runs lots of things, many of them write to someplace in /var

ah, there's also the utx log if you run anything that allows user logins, like sshd

i wanna see how far i can push immutable jails and jails isolated from host/other jails

hmm

might want to look at ocijails

how would i ship those out?

i'll search ocijail ty

hm, tmpfs does support -o union, i think

Title: FreshPorts -- sysutils/ocijail: Experimental, proof-of-concept OCI-compatible runtime for jails

so you could mount a tmpfs on /var with -o union

(note, this is not unionfs, which still has warning labels on it)

Hi guys, \o/ If you can help me, I'm having a problem with poudriere-devel. In my poudriere.conf I have PACKAGE_FETCH_WHITELIST="gcc* rust cargo-c llvm*". But sometimes rust is builded and sometimes rust is fetched. Whats the parameter or conditional to be builded or fetched?

is it possible that it's trying to fetch a new version, finding it's not there in the repo, and building it instead?

the freebsd repos can lag the ports trees by a fair length of time thanks to the fact that it takes like 5 days to build the whole set

devnull: wanna give freebsd/poudriere #1064 a try?

Title: Avoid unnecessary package building with `-b` by removing duplicate options and dependencies by patmaddox · Pull Request #1064 · freebsd/poudriere · GitHub

RhodiumToad I don't know if it is.

meena interesting

probably

I will try. 8 hours to build rust :(

does it make sense to run zfs everywhere yet? like even in a bhyve vm on a host that's running zfs too

polyex: Opinions vary but ZFS on ZFS should have the primary ARC caching to metadata only to avoid double buffering.

if you did zfs on host and in a bhyve vm, would any data or metadata leak between the vm and host?

through zfs somehow

polyex: That’s an interesting question. Any two file systems would lay out their data in a similar manner. A VM is generally consiered to be a the full mercy of the host and have no privacy… but you could independently encrypt its storage. Do you have a specific concern or use case?

What do you mean leak? I'm assuming you're using a ZVOL for the bhyve VM, which should be mountable as a regular ol' block device. If you want to protect it from prying eyes, then encrypt it.

I’m assuming a raw file...

Personally, if I'm using ZFS on the host then I'd just use UFS in the VM.

isolating systems. learning about jails and bhyve. thinking a lot about keeping host and vm/jail from being able to see through the mirror

then also thinking about using zfs on guest vm, not because it needs it since host already has zfs, but for same management interface everywhere. would that buy anything?

Assume that anyone on the host can access VM data unless it's encrypted. Relatively safe to assume that the guest OS can't read host OS data (unless you explicitly somehow give it unrestricted access or whatnot).

polyex: Encryption is always your friend… within the confines of it also being able to separate you from your data.

polyex: I'd trust the ZFS on the host and just use a dataset for the guest.

A dataset is fine for a Jail but a VM would need a boot device, unless NFS-booted, and the 9p client is making progress but is not yet ready.

can whole disk encryption be done with ufs? only done it with zfs so far

VMs can live on zvols quite nicely.

mason does that mean setting up the vm itself to use a zfs fs? instead of ufs

polyex: No, the VM itself would use a traditional filesystem.

ah k

The host would take care of snapshots.

You can do some fun things with this, like store config in the zvol metadata so you can ship the VM around without external config.

oh damn

polyex: for encryption with ufs, one uses geli

so if host tries to look at bhyve guest it'll only see an encrypted view of the runtime?

... depends how you want to use it?

if geli is running in the vm, then the host sees only the encrypted data, yes

ya

ok amazing

can a jail encrypt itself from host's view?

no.

wtf

jail is using the host's filesystem

it's confined to some root, but it can't isolate itself from the host filesystem the way a vm can

i.e. the host can always see inside the jail

You can use `zfs jail|unjail` as well as setting the jailed proper on the ZFS dataset. Once you do that, it'll become inaccessible to the host.

that would be a killer feature imo. a way for jails to be encrypted so host can't peer into their contents

well, the host can read the ram of the vm, so it could find the key and the decrypted data there

right

(with enough work)

Yup, not black and white. More like, "How can I make this enough of a PITA to make the effort not worth it?"

so no way to completely obscure jail/vm from host... dang

A VM could have GELI or ZFS native encryption, as mentioned. Keys-in-RAM notwithstanding. Do note the various AMD “secure” virtualization features.

also, with a vm on an encrypted device, you have to get the key _into_ the vm somehow

I mean if you want to secure memory, then you have to start getting into hardware modules.

crest: might have some ideas. He’s been using FreeBSD with untrusted “cloud” providers.

crest how do you keep your systems private from peering in by untrusted hosts?

polyex: You can't reasonably.

(He’s in Berlin on a Friday and may not see this for awhile)

np

Hardware modules help to secure stuff like that. For example, secure enclave on Apple (iOS) to store private keys.

like encrypt vm and keep key in hardware enclave?

vm keeps key in*

And then how is that accessed just by a trusted party?

Or put differently, how long has it been since the last time your bank sent you a breach notice?

the host can still read the ram of the vm and read the decrypted data as the vm works on it, you need at least a basic level of trust in the host

michaeldexter: ?

crest we were talking about any ways to keep a fbsd bhyve vm or jail container private and totally isolated from an untrusted cloud host

polyex: i mostly use geli disk encryption, vpns and encrypted application protocols

polyex: you can't really protect against an actively attacking hoster

ok, figured

crest: If virtualized, can the host read the GELI key from RAM and bypass the VM’s encryption?

was just hoping

they have either physical access or even worse your code runs under their hypervisor

michaeldexter: sure it wouldn't even be hard

ah

because AES round keys are easy to find in memory

"trust" can mean many things. trusting the host not to make active attacks is one thing, trusting them not to leak data by accident is another

every common optimized implementation stores them as an array of 10,12 or 14 round keys (depending on key length)

just use the aes key schedule on every 16 byte of memory

Are the keys needed continuously or can they be purged from RAM after first use?

crest what do you mean encrypted application protocols? like when your jails and bhyve vms communicate with other servers in your infra, they have tls encrypted connections?

the first 128-256 bit are the key to be expanded for the other rounds

just extract them and try to decrypt the disks using all of them

since they are the raw keys there is no key derivation function slowing you down

you're basically asking for secure digital restriction mangement

even hardware assisted enclaves like intel SGX have been broken again and again

the only thing that kind of works in narrow usecases are dedicated secure coprocessors

as long as the communication between them and the application processors isn't compromised

but if you worry about data at rest e.g. having your hoster RMA a dead drive

michaeldexter: re: can the keys be purged, think about how you still need to actually access the disk.

or a reasonable layer for your defense in depth reboot -r allows freebsd to kill all processes, unmount all file systems, and instead of rebooting mount a new root file system (from a different device)

this can be used to have an unencrypted userland to ssh into, attach the encrypted partitions and reroot into those

the only downside is that you have to keep both patched and the kernel in sync

i prefer to mount the unencrypted /boot and either nullfs mount or symlink it

you can treat your unencrypted system as a chroot or jail to update it

for zfs the trick is to save the old root pool/dataset in a kernel env var to mount it first e.g. under /plain

because the pool layout recommended and created by bsdinstall to support zfs boot envs doesn't use the root pool dataset as root file system

so you can't just automount all pools

What crest said.

tyvm

michaeldexter, polyex: gist.github.com/Crest/5204f6ebeb3a28a118f5c4f8cab82353

Title: etc rc.conf (encrypted) · GitHub

michaeldexter: in case you didn't save the link last time you asked :-P

if it's something more than 1 person cares about should it be put in ports or the base system or?

polyex: imo this belongs into base

but it's an annoying new complexity to support well

have you asked core for a sponsor?

i have not

polyex: Realize that a false sense of security is incredibly dangerous. Deciding to use such a system on a public cloud provider is almost the definition of a false sense of security.

Your best bet is to own the hardware containing private data, and even then there are risks.

mason: it can still be useful for ticking compliance checkboxes

crest: Sure. Depends on the compliance burden I guess.

but the actual effective security isn't any better?

and at least on rented physical servers and colocated hardware without a trusted/trustworthy system console there is real security gained

polyex: Also, remember that if your data isn't backed up, that's yet again a point of vulnerability.

if only the ability to use the warranty on less than 100% destroyed drives

Rented hardware, yeah. I was thinking more "cloud VM".

Best just not to trust anything, ever. :P

exactly including the cloud hosters storage stack

crest because the data at rest is the decoy, not the encrypted 1

there is a difference between a plaintext file system easy to scrape if the shared block storage gets compromised

and an active attack against your virtual machine's registers and memory through the hypervisor

most people aren't public enemy number 1 all the time

as long as you keep in mind that disk encryption isn't everything and you are prepared loose everything if with the key...

what do you think about immutable servers?

i see ppl talking about how that's good and i think it makes sense

URL?

oh nothing recent just heard it for a while in the ether

immutable infrastructure is the keyword i think

I prefer my infrastructure REALLY LOUD. (Friday afternoon joke)

polyex: imo a good idea for single application jails treated as just runtimes for the application

ya like ppl say jails are better app containers than docker ever was

any more to add on it? really interested if so

polyex: jails have been *designed* as secure kernel level virtualisation from the beginning

aye, i was right in their desire of oci containers

they started out as safe but restrictive

llua nod

over time they gained enough features to allow almost everything not using special devices (e.g. gpus) to run in them

the mechanisms are all there and most have been for ~20 years

what's missing a consensus what to do with them

instead 1/10 writes their own jail manager scripts

from just 10 lines of shell and jail.conf to python modules or intergrations into things like nomad

it exists and works for the author

what doesn't exist is 10000 unmaintained dockerfiles/images to consume and the mindshare around them

theire is no jailctl import latest-complex-application

oh ya like a docker importer to fbsd jails

ya that would really show off the feature

it wouldn't

why not?