What are some good alternative browers for freebsd.. issue with Firefox so im looking elsewhere

Nvm install chrome via linux-installer

oxbar: chromium

how do i determine what version of freebsd i'm on?

uname -KU ?

i assume 1402000 means 14.2

my assumption is that it's something like that, but my assumptions have been wrong before

lol mine too, fair point

freebsd-version -kru (installed kernel, running kernel, installed userland)

neat

yup 14.2

i'm trying to make myself a 100% comprehensive guide to setting up a bsd web and mail server from scratch, so i can easily recreate the process and feel confident enough to ship out a collocated freebsd box

so i'm looking at the manual - the real manual - and it says you run pkg and that runs a baby pkg that actually installs the real pkg

is that still accurate, or does freebsd now come with the full real package manager already installed?

the problem with having pkg in the base system is that it would couple releases together

i appear to have the full pkg installed, and i'm trying to figure out if i installed it without noting it, or if its already there

pkg is not in base, you have to install it (by running the base pkg, which does that for you)

ok i must have failed to write that in my notes

well, it will do that automatically the first time you try to use pkg (it will ask you of course before installing anything, but not sure if it gives you more hints what is going on or if it just looks like when pkg updates itself)

yeah i must have done that already and not noted it

i'm going to start over and note it

i wonder how pkgbase will handle this, it would be weird that the tool to update base isn't shipped in base

this might be a question nobody knows anything about, HOWEVER

when i shutdown with `shutdown -h now`, the machine shuts down. But the hardware is a Mac, and it doesn't acutally power down the machine. It jsut sits there at like a dead prompt

is there a way to make shutdown also power down the hardware?

i have no idea if this will also be an issue on PC hardware

GoSox: you want shutdown -p, not shutdown -h

ahhhhh

confirmed

wow the drive formatting that freebsd uses, REALLY confuses macos

which isn't actually a problem, the real install will be on an HP server. but its kinda funny

anybody know how linuxlator decides what sound device to use?

I have sysctl hw.snd.default_unit=2 which works everywhere except linuxlator

oh crap, it looks like macos saw the hdd and ssd, and automatically turned it back into a fusion drive :/

i feel like i could design a general purpose GUI for freebsd and other unix systems that could be good enough and polished enough that people could really use it for popular general computer use

i should get on that some day

GoSox, xkcd.com/927

:)

hah

i would make a GUI that is based visually on MacOS 8 from the 90s, but functionally based on peak Mac OS X from the mid 2010's

and then have some options in settings to make certain functions windows-like to make those people happy

i would be interested in seeing your work product in this regard

Wasn't there a bsd derived os with a mac looking gui?

i truly don't even know where to begin, and i don't see myself ever having time to do it.

hello something?

well macos itself is based on nextstep

and also there was BeOS way back when which ran on macs but was not macos

hello system

apple was going to buy it and make it macos, i forget the story but that never ended up happening

yeah, it's called helloSystem

never heard of that

said mac looking ui is called hellodesktop

ive seen a lot of "mac like" UIs and they problem is they all seem to focus on the cosmetic ways to look like macos, but they ignore the fore functionality of the desktop that we mac guys really care about

my point was that if this is something you want to do, maybe talking to those guys would be worthwhile, to avoid duplicating effort

if it ever happens, which is unlikely, i would specifically want to start my own thing from scratch, and do everything exactly the way i want.

but don't hold your breath

hello, which program do you use to scan for vulnarabilities? I'm already using pkg audit but I'm looking for something for programs not installed through pkg

ideal something like $> get_cve_for geoserver,mapserver,a,list,of,programs

Is it possible to use ftruncate to punch holes in memfd-backed memory in FreeBSD?

isnt memfd a Linux syscall which was ported to linuxolator (the Linux compat layer)

I dont know the low level very well

ivy: thanks will take a look :)

> The memfd_create() function creates an anonymous shared memory object, identical to that created by shm_open() when SHM_ANON is specified. Newly created objects start off with a size of zero. The size of the new object must be adjusted via ftruncate(2).

where scared to death, seeing this message post install of lsof: lsof: WARNING: compiled for FreeBSD release 11.1-RELEASE-p6; this is 11.1-RELEASE-p4.

after checking all versions found that this is the post message in the lsof package itself ...

'lo world !

From here (France - RENATER provider), we can't join www.freebsd.org with IPv4 (IPv6 is ok)

ping 96.47.72.77 does't respond, mtr stops to 96.47.66.42 (other providers in france are ok)

dgeo no problem from here.

LXGHTNXNG: I could have just man'd it, embarrassing on my part

I assume the freebsd memfd_create is different from the Linux one hence linuxolater implementing its own one?

Hi

i'm trying to use dlib-cpp under FreeBSD (through the PHP dlib wrapper) and I encounter trouble since PHP crashes at its end due to a callback of an "unknown" address during __cxa_finalize call

after trying to find the problem, it seems it comes from dlib-cpp.

with a simple example program (dlopen libdlib and dlclose and exit) it reproduces the crash

it seems that dlib register a callback function called during cxa_finalize which is not unregistered when dlclose is performed

i don't know how to debug that.. if someone has an idea?

runxiyu: for memfd (which is really shm_alloc(2) wrapped in libc), ftruncate just reserves swap and pages are allocated on write(2) except in case of superpage-configured memfd

iirc

polarian: interface is compatible, native one inspired by linux

but on freebsd we created a shm_open2 to support some of the extra properties that a shm wants and we wrap that in libc instead of implementing it as its own syscall

s/shm wants/memfd wants/

nobody knows for my quesiton?

kevans: thanks

titou: can you throw up a pastebin or something with your simpler reproducer?

is bytecode affected affected by reciprocal tarrifs too ?

s/affected//

hmm using -j with pkg when the jail is a vnet jail causes it to hang on "Updating FreeBSD repository catalogue...", both the host and jail have network access...

"pkg: An error occured while fetching package" yeah it cant fetch them weird

kevans: here is a simple example which crashs: pastebin.com/edABC2hG

probably you have to manage VNET jails from the inside of the jail

if i remove the dlclose line, it works very well

mzar: possibly, it depends on how pkg -j is implemented

does it download the pkg on the host, and then install it into the jails path... or does it attempt to pull the pkg from within the jail

the benefits of VNET jails are overestimated

mzar: is it worth the added headache? not really

does it provide network isolation from the host? yes

does it provide layered network filtering? yes

but does this make a big enough security improvement to justify the headache and the longer setup? ehhhh

network performance gets degraded by VNET and more CPU cycles are needed, so it's also agains green computing, buy whocare

s

ok I can answer the question of where pkg is executed, its within the jail because I cant fetch from within the jail, but I can ping other hosts

weirddd

mzar: that is like saying IPv6 is more eco friendly because it does not require a nat

titou: oy, that's hairy

the amount of energy we are talking here is negligable

fraction of a watt

polarian: sure it is, ip6 doesn't require recomputation of checksums if packet is forwarded

kevans: do you have ideas about how to debug that?

do you guys know what happened to koobs ? I haven't seen him here since a while

mzar: we are talking about very little amounts of energy

OK, so let's reducy byteflow

*reduce

mzar: lets not bother with security features like encryption, it wastes cpu cycles too and slows things down

why bother with firewalls, all that packet matching takes cpu cycles

and slows down packets

it would be great to list the functions which will be called by cxa_finalize but I don't know how to access to this list without modifying the libc...

titou: the problem is that that's not an application problem

for sure... i'm afraid it's a FreeBSD libc bug?

libc/rtld, yeah

but why it only appears for this libray?!

this bug is documented since many years..

(at least 5 yaers)

do you know somone / a mailing list which will be able to help me solving this bug?

I was trying to distill it down into a simpler test case, but it's not as cut and dry as it looked initially

kevans: why?

titou: basic __cxa_atexit stuff is fine, so it's not just a global object trying to do teardown, and dlib doesn't seem to be doing anything too crazy on its own at first grep

titou: I'd recommend hacking up a libc that prints what it's doing at __cxa_finalize time and try to get a feel for all of the cxa_func's that are running when you do not dlclose it

for basic global object dtor that gets a __cxa_atexit, we seem to be doing fine and everything looks good

:/

so you're kind of looking for functions that are out of the ordinary in some way

it means recompile libc with debug enabled.. it's quite boring to do :)

polarian: one alternative is pkg -r $jail_root , with the repositories being configured in the host not the jail

jmnbtslsQE: ooo thats a cool tip, thanks...

the thing is I need http access within the jail... and I cant figure out why the packets are being dropped, icmp works

tcp is explicitly passed

but the host drops the resposne

if a connection can't be made, i'd think that's a firewall issue somehow

yeah but pf is stateful, why the fuck would it drop a response??

I have one idea of what it could be

is a connection made?

jmnbtslsQE: yup

maybe it's an ssl problem, or an MTU problem (where the response is too large to fit in the MTU of one of your interfaces)

I tcpdump'd my router, the response reaches WAN, and I get the response back from WAN, and it is indeed passed to the host

hmm MTU problem is possible... its on a wireguard interface and I had to drop the MTU a while back because packets wouldn't pass via wireguard

I found 1325 was a safe MTU to ensure packets passed...

but to be honest, I dont this is MTU

it's something where there should be clues in tcpdump at various places

if a response packet doesn't make it through, it should be clear on tcpdump which is the last interface to see it

but it's also worth noting, technically the treatment of packets during the tcp handshake could be different from the firewall's standpoint than for packets once the connection is established

not sure how that would happen here there for pf

though*

jmnbtslsQE: pf is stateful, if the packet passed originally, it will always pass, in fact it bypasses pf entirely in the network stack

which is why if you change pf rules you should also flush your state table

so the response *should* pass

pf does still see the stateful packets but if it has state for a packet it probably decide to not evaluate anything in the ruleset (don't remember)

indeed

there was a talk on it at fosdem which I watched

very good talk

OK

s/watched/attended/

polarian: do you actually rdr your http packets to the jail?

SKull: this shouldnt be needed

if I put in an inbound rule for the jail interface this would affect non-stateful packets

polarian: that depends on the setup

the weird thing is ICMP passes which is really weird

so just doing user@host: curl <your-jail> fails?

where host is the actual jail host.

kevans: that's very interesting! I guess I got the trick..

i'll try to make a simple example to recreate the bug

kevans: in fact for an unknown reason i can't reproduce __cxa_atexit is called during a call to a callback during __cxa_finalize which then is not called during this call (__cxa_finalize called during dlclose). Then it is called during the last __cxa_finalize call which is performed at the end of the process...

titou: libdlib pulls in so many other shlibs that I have to wonder if the problem is actually in libdlib or in one of the shlibs it pulls in

polarian: you can also optimise encryption and make it more green by the transition from RSA to ECDSA

titou: I trivially debunked that by trying the reproducer with all of the dependencies, so nevermind

mzar: imma just assume you are an eco extremist which fixates on small insignificant environmental issues, and misses the bigger picture

think of how wasteful the web is, and then tell me some security measures are too bad for the environment

polarian: I really don't care

then why comment on my use of vnet jails if you dont?

I like to stir the pot from time to time

> Trace/BPT trap

Ungoogled Chromium crashes

Any pointers to debug?

runxiyu: where'd you install it from

packages

yeah probably a packages vs ports issue again

if you make sure that all the dependencies are the right versions, using the right ABI and so on, and it still crashes, running it under gdb might provide some hints

although you'll probably need to rebuild the debug version with DCHECKs enabled for any more information

another worthwhile thing to check would be if regular chromium also crashes

titou: it's something about this thread_destruct_helper

threader_destruct_helper

kevans: in fact by hacking the libc i hit the problem into dlib. That's why i told you why it crashes

the problem come from calls to __cxa_atexit called into a callback called during __cxa_finalize. The new callback added by __cxa_atexit is not executed during the current __cxa_finalize call and stay into memory until __cxa_finalize is called with DSO set to NULL at the end of the procress

unfortunately the library has been unloaded from memory thus the callback doesn't exist anymore

this is due to a static class intance loaded during an "atexit" function which needs to call its destructor once it is no more used

the problematic line in dlib code is: threads_kernel_shared.cpp:49

titou: oh, sorry, I guess I misunderstood. that's a lot easier to write a reproducer for

i thought but i didn't succeed yet :)

the last thing is that it is easy to correct..

but it needs to update the FreeBSD libc code..

I succeed !

hmm, I thought I had it, but it also crashes if I don't dlclose: people.freebsd.org/~kevans/atexit-repro.c

toss yours this way?

something like that

it's almost the same

the fact that your initial one doesn't reproduce without dlclose() may be a coincidence, I suppose

my example code works if dlclose is not performed and crash if dlclose is performed

it crashs the same way as the dlib one during __cxa_finalize code

i'll write it the same way as you

oh, I'm dumb. I recompiled the shared object again, not the non-shared bits

artifact of trying to write both into a single self-contained file to pass along easier :-)

but you got the trick!

in fact one of the easy way to solve this bug would be to execute again __cxa_finalize if more than one callback is called during the last __cxa_finalize

it also would be possible to set a flag which indicates that cxa_finalize should be called again if the DSO passed to __cxa_atexit functions is the same as the one currently in use during the __cxa_finalize call

i could try to write something

what's the idiomatic way to disable(in the same way as accompished by devctl disable <device>) a pci device during boot, before the modules in kldload list are loaded?

where should I send the buggy example program and the associated patch?

titou: throw it on bugzilla and send me a link

this is why: I finally got i915kms and xorg to work with my iGPU even when my dGPU(which causes a kernel panic when i915kms is loaded), but right now I have to manually run devctl disable pci0:3:0:0, then manually load the driver, then I can start the X server

obviously I'd like to do all of this automatically on boot instead

when my dGPU is present*

I got

nextcloud-php80-25.0.2 in 13.1-RELEASE in an iocage on TrueNAS. I upgraded it within nextcloud to 28. Now I want to upgrade it to nextcloud-php84-31.0.2. I'm not sure what that will do to the nextcloud databases. Also pkg upgrade wants to remove nextcloud. I would rather upgrade php8 to 8.3 or 8.4 to upgrade nextcloud within nextcloud 28 >29 > 30 > 31 I didn't want to risk dataloss or loss of the nextcloud database.

and also, for later, I want to do this in a way that doesn't stop me from attaching the device to bhyve later on, cause I wanna try to port the linux driver to FreeBSD, and it'd be nice to not have to reboot every time I test it

kevans: my patch solved the bug

floogy: performing upgrade from the CLI is advised

but you can try risky path if you have full backup of the database

floogy: what was used as database backend on TrueNAS ?

kevans: do you know which kind of component is concerned? kern? not sure..

I think mariadb

well, the way stuff it handled currently for pkg nextcloud-php80 and nextcloud-php84 have nothing to do with each other, so it doesn't know that you would want to install nextcloud-php84 now, replacing nextcloud-php80

It wouldn't replace nextcloud-php80?

nextcloud is just a tarball, you extract it and run php script to upgrade

I have never been using FreeBSD package

titou: call it bin

kevans: bugs.freebsd.org/bugzilla/show_bug.cgi?id=285870

does no one know how to do this? I would've thought it was a fairly simple thing to do, but I can't find the manpage that tells me how

mtll: i thought it was in the bhyve section of the wiki

floogy: take a backup of both files and sql before doing anything

well yes, but right now I just want to know how to disable the pci device before i915kms is loaded by kld

I'll set up the bhyve stuff later

i believe it's the same approach

oic, nice, bit of a hack, but since I will be using it for bhyve anyway, an appropriate one, thanks

how to compile a port with a specific compiler (for instance gcc) ?

If you are writing the port currently and it needs a specific compiler USES=compiler docs.freebsd.org/en/books/porters-handbook/uses/#uses-compiler USES=llvm docs.freebsd.org/en/books/porters-handbook/uses/#uses-llvm or USE_GCC=yes docs.freebsd.org/en/books/porters-h…ndbook/makefiles/#makefile-use-vars and if you aren't writing the port, then why do you want to choose the

compiler?

nimaje: because the PHP wrapper use mangled C++ function names which are only compatible with the gcc output (for dlib-cpp)

but thank you for the answer

I would have expected that to come up when the port was written, not when someone tries to build it