is freebsd oem ready

I am unable to get Mariadb10.11 to interact with localhost, 127.0.0.1 nor /var/run/mysql/mysql.sock is this working as intended or something?

aparently the working as intended is some secret undocumented configuration?

there have been several threads in the forums, including hacks which break once php is upgraded. forums.freebsd.org/threads/mariadb-…-with-127-0-0-1-and-localhost.80959

Title: Solved - mariadb not seeing eye to eye with 127.0.0.1 and localhost | The FreeBSD Forums

hint: it's not solved, its a hack

the maintainer recused himself from explaining the definition of working as intended is bugs.freebsd.org/bugzilla/show_bug.cgi?id=254948

Title: 254948 – databases/mariadb105-server fails to resolve localhost

the relevant mysql 8.x port works out of the box with localhost 127.0.0.1

this was never dealt with getting mariadb to work out of the box bugs.freebsd.org/bugzilla/show_bug.cgi?id=267835

Title: 267835 – databases/mariadb106-server standard location of socket breaks default PHP config

soo many ports are in some cases hard coded to not work with mariadb >105

and mariadb103 was just eol a few months ago what a mess

that worked and now its gone

there is no solution provided only broken as intended

Oclair: so it doesn't work for you when the host name is the 127.1 address?

in any case, if you use the socket, then the socket path has to agree on both the server and the client side. So that solution doesn't seem to be a hack

is there a way to see which disk controller a drive is attached to?

devinfo shows the device tree

that's a very cool command that I didn't know, but I don't immediately see how it answers my questions

for example, adaX does not appear there

ah, yes, CAM devices don't show up for whatever reason

best bet is probably /var/run/dmesg.boot, then

ada0 at ahcich0 bus 0 scbus0 target 0 lun 0

and

ahcich0: <AHCI channel> at channel 0 on ahci0

so my ada0 is on channel 0 of device ahci0

pstef thanks for the help, on #maria a very kind soul recommended that I set a global environmental variable as root in #sh #MYSQL_UNIX_PORT=/var/run/mysql/mysql.sock #export MYSQL_UNIX_PORT #exit

how is that any better?

that does nothing?

nothing is better than something

Title: Solved - mariadb not seeing eye to eye with 127.0.0.1 and localhost | The FreeBSD Forums

Title: 267835 – databases/mariadb106-server standard location of socket breaks default PHP config

Title: 254948 – databases/mariadb105-server fails to resolve localhost

I am sure a few folks are curious what exactly was going on there...

for now the only problem I can see you having is that you refuse to configure your MariaDB server or the client (PHP in this case)

specifically, configure the path to the socket

defining the path to the socket initially was required to get php to work, other 3rd party out of the box things expecting mariadb to work are not so lucky

I still don't understand, each 3rd party needs to be configured so that it knows how to connect

pstef nope

what part of localhost is unclear?

mariadb out of the box in more cases than mine is not able to listen to localhost

whether you want to use TCP or the socket

mariadb <103 didn't have this issue

there seems to be a lot of confusion here

because things are not made simple as they are

so many threads no clear upgrading notice

step 1 is to decide whether you want to connect over TCP or over the socket

I just would like to know the intent

step 2 is to provide all the connection information to the client

pstef no the mariadb maintainer changed things around and kept things hidden

like what

documenting his work

stuff like moving the unix socket location should have been documented in UPDATING, afaict it is not there

I bet it was the upstream who changed it

quite likely, but it should have been documented there anyway

and even if that was documented in UPDATING you'd still get this complaint and unwillingness to consider using configuration files

my understanding is that mysql _clients_ treat "localhost" as meaning "use the unix socket" and NOT "resolve localhost as an IP address and use tcp"

that's my understanding too

I also think there is a preponderance perhaps as well to using /etc/hosts and defining the hostname because rc.conf is the freebsd way for ported software to get such info.... gah

from what I remember, you need to add the port number to change semantics

Oclair: what has /etc/hosts got to do with it? nothing as far as i can tell

what did I do to get an 8 year mailserver working again as far as I can tell what I did I will

the whole point is that mysql clients _are not using_ either /etc/hosts or any other name resolution method when "localhost" is specified

how are we supposed to know what you did?

there is a lot of talk about /etc/hosts here bugs.freebsd.org/bugzilla/show_bug.cgi?id=254948. and Status: Closed Works As Intended

Title: Invalid Bug ID

From MariaDB 10.6.1, a connection property specified via the command line (e.g. --port=3306) will force its type. The protocol that matches the respective connection property is used, e.g. a TCP/IP connection is created when --port is specified.

RhodiumToad: mysql making a distinction between localhost and 127.0.0.1 is asinine in the first place

sorry bad formatting bugs.freebsd.org/bugzilla/show_bug.cgi?id=254948

Title: 254948 – databases/mariadb105-server fails to resolve localhost

Oclair: again, if you choose the unix domain socket instead of TCP, localhost in this context is not resolved in any way

Oclair: the discussion there of /etc/hosts is ill-informed

it just means "look for the file on this computer"

Oclair: you have to understand that people contributing to discussions can be wrong, and often are

lots of people with bad information and Status: Closed Works As Intended

so what is the secret intent?

I see nothing in that bug report that shows it not working as intended.

Rhodiumtoad thanks for your valuable assistance

fortunately I got it working and from your perspective I have no idea how

what did you actually change?

fortunately I will get to wait until 2028 before I need to worry about it

you're not interested in knowing?

I guess the variable was set both as root in a separate shell (so a no-op) and just before starting the server. So probably the next restart the thing won't be able to connect again

Oclair: you do understand that the environment var thing you showed does _literally nothing_, right? environment variables are not global, they are inherited, so if you set one and then immediately quit the shell you set it in, the value you set no longer exists anywhere

please leave me alone thanks

if you need environment vars to be set when starting services, there are about three (depending on freebsd version) ways of doing that

how do I get 'ls' to output with capital directories first? it is weird to see 'bin' appear before 'Downloads'

ls | sort (the default sort does what you want, I think)

depends on locale

restarted the server works

fud

what's the easiest way to see a default config file, e.g., /etc/ssh/sshd_config? wanting to diff with what i've got.

I stand corrected.

Is there any free server management/control panel software running correctly with FreeBSD? I tried few, failed badly. Virtualmin was the closest one, it's glitch as well, though.

tercaL freebsd is not the right os for you

if you stay with FreeBSD forget there are things like cpanel

clear

oops

Umm...what am I missing here?

Well, I manage it in the terminal easily, it's quite cool, just asked for a friend with not really good UNIX knowledge.

Why is poudriere resolving py39-openssl-20.0.1,1 as being able to satisfy py39-openssl>=21,1?

And wanted to hear your suggestions here.

PyR3X: the sort order is controlled by the LC_COLLATE env var, or by LANG if that is not set

_xor: I don't think it is, do you have a more recent version in the build?

RhodiumToad: You mean a more recent version of py39-openssl in the queue?

RhodiumToad: If so, then apparently not. It ends up trying to use py39-openssl-20.0.1,1 and then fails for that port (py39-aioquic).

Though I just realized that I could try getting rid of the switch that tries to utilize packages from existing repositories (think it was marked alpha anyway).

what version number do you have in security/py-openssl/Makefile?

21.0.0

thanks for the explanation earlier RhodiumToad!

When this queue finishes, I'm either going to try deleting py39-openssl-20.0.1,1 from my existing repository or removing the arg to `poudriere bulk ...` that enables using existing package repos (I think it's -B, gotta look it up in a minute).

-B is to resume a previous build

I got some emails from the FreeBSD security team about SSH

How long before the patches make their way to packages?

RoyalYork: it's the base system, not the packages, from what I gather from the emails

so use freebsd-update fetch?

looks like 13.2-RELEASE-p2 is available to me (not sure when patch 2 came out)

RoyalYork: that's what the email said, yes

freebsd-version -k now shows 13.2-RELEASE-p2 for me

however uname shows 13.2-RELEASE-p1

ooops need to reboot

brb

yep, reboot did the trick

uname and freebsd-version all show p2

the freebsd-update says: "The following files are affected by updates. No changes have been downloaded, however, because the files have been modified locally: /etc/ssh/sshd_config" - any idea what has changed in sshd_config before I reboot? (Remote server without any access other than sshd here :/)

I would imagine that your config files settings are fine, however I would defer to another user here

tercaL: freshbsd.org/freebsd/src/commit/20b…c33d3f2549e121f34b3839e33e176a313fc

Title: FreeBSD / src / 20bcfc3 / ssh: Update to OpenSSH 9.3p2 - FreshBSD

or cgit.freebsd.org/src/commit/?id=20b…c33d3f2549e121f34b3839e33e176a313fc

Title: src - FreeBSD source tree

tercaL: looks like the only change is -#VersionAddendum FreeBSD-20230316

+#VersionAddendum FreeBSD-20230719

I'm not seeing my iwm0 wifi I get the following in dmesg

iwm0: <Intel(R) Dual Band Wireless AC 7260> mem 0xf7900000-0xf7901fff at device 0.0 on pci2

iwm0: hw rev 0x140, fw ver 17.352738.0, address 5c:51:4f:ed:48:c9

acpi_wmi0: <ACPI-WMI mapping> on acpi0

acpi_wmi0: Embedded MOF found

ACPI: \134_SB.AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)

acpi_wmi1: <ACPI-WMI mapping> on acpi0

nevermind needed wlans_iwm0="wlan0"

AFAIC, FreeBSD broke wifi several versions ago. Wifi NICs used to just appear as a device you ran ifconfig commands against. It was simple & easy.

You mean without the wlan[0-9]+ indirection?

Yeah.

Even if you had to use the NDIS2 wrapper for your wifi card, it still seemed less convoluded.

I wouldn't know.

CrtxReavr: The indirection does make me wonder if there's something gained thereby.

That's never been quite clear to me.

is there a simple way to just drop or icmp reject ipv6 fragment header?

satanist: You can drop frags altogether.

with what sysctl setting? or do I need to set this in ipfw?

has anyone been able to run the sample/test zenbleed code on freebsd?

satanist: I used to do it in ipf. I assume the other two options both do it. Looking.

i've gotten so far as it will compile, but fails when linking with a bunch of undefined symbols, and i'm afraid i'm not clever enough to get past that

satanist: from docs.freebsd.org/en/books/handbook/firewalls we see, for example, $cmd 00330 deny all from any to any frag in via $pif

Title: Chapter 33. Firewalls | FreeBSD Documentation Portal

yes right a firewall can hadle this, the question was is there an systctl (ifconfig or rc.conf) setting to do so

satanist: sysctl -a | grep frag | grep net.inet shows some counters, but nothing that would drop them at that level.

...at least as of 13.2

does setting ip6_maxfragsperpacket to 0 does the trick?

That sounds like a bad idea.

Is this referring to the recent advisory?

more or less, but no I don't look for a workaround instand of installing the patch

I just would like to disable fragmentation

V_PauAmma_V: yes, cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20593

Title: CVE - CVE-2023-20593

Title: Zenbleed is coming for you baby! | The FreeBSD Forums

No, not that one. I meant FreeBSD-SA-23:06.ipv6.

oh, sorry :)

Title: AtHe

i was able to install gmake, libsysinfo, and nasm and got a little further, but i haven't figure out how to get strdupa() or get_nprocs()

satanist, quoting from that email: "The kernel may be configured to drop all IPv6 fragments by setting the net.inet6.ip6.maxfrags sysctl to 0. Doing so will prevent the bug from being triggered, with the caveat that legitimate IPv6 fragments will be dropped." So that will do exactly what you want, for inbound IPv6 packets.

a thanks overread this point

The way IPv6 handles fragmentation is one of the cooler upgrades over Legacy IP.

whats the diffrent beside it's a option (optional next-header)?

Path MTU detection that's not an afterthought, IIRC.

satanist, can you view powerpoint files?

not tested, but if they work with libreoffice it will work, but would prefer an pdf

I'm not converting files for this. .

But look at page 12 of this deck.

wcarson: strdupa and get_nprocs are linuxisms, as far as I know

yeah, gcc-linuxisms, even. i found a macro #define for strdupa and replaced get_nprocs() with a static number for my system to work around it

pthread_attr_setaffinity_np is supported if you include <pthread_np.h> I think

ok, i'll try that! thank you

wcarson: We have some getnproc function now for compatibility

oh nice

RhodiumToad: that did indeed resolve that warning!

so yes you have to do path mtu discorvery, but still don't think this worth the complexity of fragmentation (in ip)

I don't see a function to get number of cpus

freshbsd.org/freebsd/src/commit/48b…3597654490cdc43bf0f591a539d3a28b590 nope, i was wrong, we just have nproc(1)

Title: FreeBSD / src / 48bfd35 / Add nproc(1) - FreshBSD

the right way is to use cpuset_getaffinity

CrtxReavr: btw not sure if this is intendet but the two example links have a to small mtu for ipv6

in particular, cpuset_getaffinity lets you count the number of cpus available to the current process, which may differ from the actual hardware number

RhodiumToad: as seen in the code i linked ;)

satanist, just a visual aid. . .

So in v4, if you want to get a packet from left to right, if the first router gets a 1000 byte packet, then it has to fragment it into packets smaller than 810 bytes. .

And then the next router, will have to fragment those down to 53 bytes. . .

And then the next router, will have to re-assemble them into 1000 byte packets again, all of this eating router CPU time.

Same scenario, in v6. . .

> And then the next router, will have to re-assemble them into 1000 byte packets again

routers don't reassemble, only the destination does

not true, he might do but most just don't bouther

Teh first router, will send an ICMPv6 error back to the sending host saying 'Woah, buddy. . . you can't send me any packets larger than 810 bytes, so start over!"

so the sending host will start over.

Isn't the minimum fragment size for v6 something like 1280?

When they hit the second router, it'll say 'Woah, buddy. . . you can't send me any packets larger than 810 bytes, so start over!"

path mtu discorvery is nice (also for v4), the fragmentation on ip level bothers me

s/810/53/bytes.

it's horrible complex and quite easy to get wrong

And then the receiving host will re-assemble them. . . puts the burden of fragmentation on the sending and receiving hosts.

PMTU doesn't exist for v4.

That's a slide deck for a presentation I gave for v6 to an incoming class of summer interns.

satanist: reassembling fragments not addressed to the router is a MUST NOT in the router requirements

oops, missed them

satanist: reassembling fragments not addressed to the router is a MUST NOT in the router requirements

RhodiumToad: in v4 or v6?

both

there's a good reason for it, too: want to guess?

reasambling is hard and needs ram

there's no guarantee that a single router will see all the fragments

a this also, I forgott

my networking class is a few years old

that's the main reason why it's a MUST NOT rather than anything less

but say that CrtxReavr not me, he might want to update the explanaitio for his lessens

also pmtu is posible with v4, by optional setting the dnf bit

yes require this in v6 is the better way

not merely possible, but essentially universal

bapt: hi, mind taking a look at D41151?