02:45:43 <u0_a853> is freebsd oem ready
02:52:23 * kenrap grabs the popcorn
07:03:34 <Oclair> 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?
07:04:41 <Oclair> aparently the working as intended is some secret undocumented configuration?
07:06:23 <Oclair> there have been several threads in the forums, including hacks which break once php is upgraded. https://forums.freebsd.org/threads/mariadb-not-seeing-eye-to-eye-with-127-0-0-1-and-localhost.80959/
07:06:24 <VimDiesel> Title: Solved - mariadb not seeing eye to eye with 127.0.0.1 and localhost | The FreeBSD Forums
07:06:38 <Oclair> hint: it's not solved, its a hack
07:07:08 <Oclair> the maintainer recused himself from explaining the definition of working as intended is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254948
07:07:12 <VimDiesel> Title: 254948 – databases/mariadb105-server fails to resolve localhost
07:08:14 <Oclair> the relevant mysql 8.x port works out of the box with localhost 127.0.0.1
07:45:08 <Oclair> this was never dealt with getting mariadb to work out of the box https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267835
07:45:10 <VimDiesel> Title: 267835 – databases/mariadb106-server standard location of socket breaks default PHP config
07:45:47 <Oclair> soo many ports are in some cases hard coded to not work with mariadb >105
07:46:13 <Oclair> and mariadb103 was just eol a few months ago what a mess
07:46:23 <Oclair> that worked and now its gone
07:47:31 <Oclair> there is no solution provided only broken as intended
12:03:46 <pstef> Oclair: so it doesn't work for you when the host name is the 127.1 address?
12:11:40 <pstef> 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
14:26:30 <futune> is there a way to see which disk controller a drive is attached to?
14:27:44 <RhodiumToad> devinfo  shows the device tree
14:29:53 <futune> that's a very cool command that I didn't know, but I don't immediately see how it answers my questions
14:30:20 <futune> for example, adaX does not appear there
14:39:11 <RhodiumToad> ah, yes, CAM devices don't show up for whatever reason
14:39:21 <RhodiumToad> best bet is probably /var/run/dmesg.boot, then
14:39:43 <RhodiumToad> ada0 at ahcich0 bus 0 scbus0 target 0 lun 0
14:41:02 <RhodiumToad> and
14:41:06 <RhodiumToad> ahcich0: <AHCI channel> at channel 0 on ahci0
14:41:36 <RhodiumToad> so my ada0 is on channel 0 of device ahci0
14:56:24 <Oclair> 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
14:56:42 <pstef> how is that any better?
14:57:15 <RhodiumToad> that does nothing?
15:01:03 <Oclair> nothing is better than something
15:01:05 <Oclair> https://forums.freebsd.org/threads/mariadb-not-seeing-eye-to-eye-with-127-0-0-1-and-localhost.80959/
15:01:06 <VimDiesel> Title: Solved - mariadb not seeing eye to eye with 127.0.0.1 and localhost | The FreeBSD Forums
15:01:33 <Oclair> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267835
15:01:35 <VimDiesel> Title: 267835 – databases/mariadb106-server standard location of socket breaks default PHP config
15:01:46 <Oclair> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254948
15:01:48 <VimDiesel> Title: 254948 – databases/mariadb105-server fails to resolve localhost
15:02:38 <Oclair> I am sure a few folks are curious what exactly was going on there...
15:04:26 <pstef> 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)
15:04:49 <pstef> specifically, configure the path to the socket
15:05:08 <Oclair> 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
15:06:03 <pstef> I still don't understand, each 3rd party needs to be configured so that it knows how to connect
15:06:17 <Oclair> pstef nope
15:06:48 <Oclair> what part of localhost is unclear?
15:07:36 <Oclair> mariadb out of the box in more cases than mine is not able to listen to localhost
15:07:41 <pstef> whether you want to use TCP or the socket
15:07:55 <Oclair> mariadb <103 didn't have this issue
15:08:44 <RhodiumToad> there seems to be a lot of confusion here
15:09:13 <Oclair> because things are not made simple as they are
15:10:15 <Oclair> so many threads no clear upgrading notice
15:10:36 <pstef> step 1 is to decide whether you want to connect over TCP or over the socket
15:10:38 <Oclair> I just would like to know the intent
15:10:52 <pstef> step 2 is to provide all the connection information to the client
15:11:26 <Oclair> pstef no the mariadb maintainer changed things around and kept things hidden
15:11:45 <pstef> like what
15:12:33 <Oclair> documenting his work
15:14:16 <RhodiumToad> stuff like moving the unix socket location should have been documented in UPDATING, afaict it is not there
15:14:41 <pstef> I bet it was the upstream who changed it
15:14:59 <RhodiumToad> quite likely, but it should have been documented there anyway
15:15:27 <pstef> and even if that was documented in UPDATING you'd still get this complaint and unwillingness to consider using configuration files
15:15:43 <RhodiumToad> 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"
15:15:58 <pstef> that's my understanding too
15:16:25 <Oclair> 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
15:16:27 <pstef> from what I remember, you need to add the port number to change semantics
15:16:59 <RhodiumToad> Oclair: what has /etc/hosts got to do with it? nothing as far as i can tell
15:17:32 <Oclair> what did I do to get an 8 year mailserver working again as far as I can tell what I did I will
15:17:48 <RhodiumToad> the whole point is that mysql clients _are not using_ either /etc/hosts or any other name resolution method when "localhost" is specified
15:18:14 <RhodiumToad> how are we supposed to know what you did?
15:19:20 <Oclair> there is a lot of talk about /etc/hosts here https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254948. and Status: 	Closed Works As Intended
15:19:22 <VimDiesel> Title: Invalid Bug ID
15:19:54 <pstef> 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.
15:19:54 <rtprio> RhodiumToad: mysql making a distinction between localhost and 127.0.0.1 is asinine in the first place
15:20:45 <Oclair> sorry bad formatting https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254948
15:20:48 <VimDiesel> Title: 254948 – databases/mariadb105-server fails to resolve localhost
15:21:39 <pstef> Oclair: again, if you choose the unix domain socket instead of TCP, localhost in this context is not resolved in any way
15:21:53 <RhodiumToad> Oclair: the discussion there of /etc/hosts is ill-informed
15:21:57 <pstef> it just means "look for the file on this computer"
15:22:11 <RhodiumToad> Oclair: you have to understand that people contributing to discussions can be wrong, and often are
15:22:31 <Oclair> lots of people with bad information and Status:     Closed Works As Intended
15:22:45 <Oclair> so what is the secret intent?
15:22:48 <RhodiumToad> I see nothing in that bug report that shows it not working as intended.
15:24:30 <Oclair> Rhodiumtoad thanks for your valuable assistance
15:24:53 <Oclair> fortunately I got it working and from your perspective I have no idea how
15:25:02 <RhodiumToad> what did you actually change?
15:26:29 <Oclair> fortunately I will get to wait until 2028 before I need to worry about it
15:29:37 <RhodiumToad> you're not interested in knowing?
15:29:38 <pstef> 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
15:31:14 <RhodiumToad> 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
15:32:09 <Oclair> please leave me alone thanks
15:32:13 <RhodiumToad> if you need environment vars to be set when starting services, there are about three (depending on freebsd version) ways of doing that
15:32:43 * RhodiumToad happy to oblige
16:04:47 <PyR3X> how do I get 'ls' to output with capital directories first? it is weird to see 'bin' appear before 'Downloads'
16:12:14 <V_PauAmma_V> ls | sort (the default sort does what you want, I think)
16:23:04 <yuripv> depends on locale
16:26:35 <Oclair> restarted the server works
16:26:49 <Oclair> fud
16:27:02 <markmcb> 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.
16:28:09 <V_PauAmma_V> I stand corrected.
16:28:23 <tercaL> 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.
16:28:48 <Oclair> tercaL freebsd is not the right os for you
16:29:44 <Oclair> if you stay with FreeBSD forget there are things like cpanel
16:32:36 <_xor> clear
16:32:38 <_xor> oops
16:38:02 <_xor> Umm...what am I missing here?
16:38:03 <_xor> https://termbin.com/8895
16:38:18 <tercaL> Well, I manage it in the terminal easily, it's quite cool, just asked for a friend with not really good UNIX knowledge.
16:38:58 <_xor> Why is  poudriere resolving py39-openssl-20.0.1,1 as being able to satisfy py39-openssl>=21,1?
16:39:09 <tercaL> And wanted to hear your suggestions here.
16:40:39 <RhodiumToad> PyR3X: the sort order is controlled by the LC_COLLATE env var, or by LANG if that is not set
16:40:54 * RhodiumToad prefers LC_COLLATE=C
16:44:00 <RhodiumToad> _xor: I don't think it is, do you have a more recent version in the build?
16:48:22 <_xor> RhodiumToad: You mean a more recent version of py39-openssl in the queue?
16:49:20 <_xor> 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).
16:49:48 <_xor> 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).
16:49:49 <RhodiumToad> what version number do you have in security/py-openssl/Makefile?
16:50:17 <_xor> 21.0.0
16:50:22 <futune> thanks for the explanation earlier RhodiumToad!
16:52:15 <_xor> 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).
16:53:48 <RhodiumToad> -B is to resume a previous build
17:15:00 <RoyalYork> I got some emails from the FreeBSD security team about SSH
17:15:19 <RoyalYork> How long before the patches make their way to packages?
17:15:52 <meena> RoyalYork: it's the base system, not the packages, from what I gather from the emails
17:17:04 <RoyalYork> so use freebsd-update fetch?
17:17:37 <RoyalYork> looks like 13.2-RELEASE-p2 is available to me (not sure when patch 2 came out)
17:17:55 <meena> RoyalYork: that's what the email said, yes
17:19:25 <RoyalYork> freebsd-version -k now shows 13.2-RELEASE-p2 for me
17:19:44 <RoyalYork> however uname shows 13.2-RELEASE-p1
17:20:19 <RoyalYork> ooops need to reboot
17:20:31 <RoyalYork> brb
17:24:51 <RoyalYork> yep, reboot did the trick
17:24:57 <RoyalYork> uname and freebsd-version all show p2
17:25:10 <tercaL> 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 :/)
17:26:16 <RoyalYork> I would imagine that your config files settings are fine, however I would defer to another user here
17:28:59 <meena> tercaL: https://freshbsd.org/freebsd/src/commit/20bcfc33d3f2549e121f34b3839e33e176a313fc
17:29:00 <VimDiesel> Title: FreeBSD / src / 20bcfc3 / ssh: Update to OpenSSH 9.3p2 - FreshBSD
17:29:49 <meena> or https://cgit.freebsd.org/src/commit/?id=20bcfc33d3f2549e121f34b3839e33e176a313fc
17:29:50 <VimDiesel> Title: src - FreeBSD source tree
17:30:40 <meena> tercaL: looks like the only change is -#VersionAddendum FreeBSD-20230316
17:30:41 <meena> +#VersionAddendum FreeBSD-20230719
18:33:50 <PyR3X> I'm not seeing my iwm0 wifi I get the following in dmesg
18:33:54 <PyR3X> iwm0: <Intel(R) Dual Band Wireless AC 7260> mem 0xf7900000-0xf7901fff at device 0.0 on pci2
18:33:56 <PyR3X> iwm0: hw rev 0x140, fw ver 17.352738.0, address 5c:51:4f:ed:48:c9
18:33:58 <PyR3X> acpi_wmi0: <ACPI-WMI mapping> on acpi0
18:34:00 <PyR3X> acpi_wmi0: Embedded MOF found
18:34:02 <PyR3X> ACPI: \134_SB.AMW0.WQMO: 1 arguments were passed to a non-method ACPI object (Buffer) (20201113/nsarguments-361)
18:34:04 <PyR3X> acpi_wmi1: <ACPI-WMI mapping> on acpi0
18:37:04 <PyR3X> nevermind needed wlans_iwm0="wlan0"
19:59:58 <CrtxReavr> 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.
20:03:09 <V_PauAmma_V> You mean without the wlan[0-9]+ indirection?
20:03:59 <CrtxReavr> Yeah.
20:04:36 <CrtxReavr> Even if you had to use the NDIS2 wrapper for your wifi card, it still seemed less convoluded.
20:07:48 <V_PauAmma_V> I wouldn't know.
20:32:30 <mason> CrtxReavr: The indirection does make me wonder if there's something gained thereby.
20:32:39 <mason> That's never been quite clear to me.
20:33:00 <satanist> is there a simple way to just drop or icmp reject ipv6 fragment header?
20:33:20 <mason> satanist: You can drop frags altogether.
20:34:33 <satanist> with what sysctl setting? or do I need to set this in ipfw?
20:34:57 <wcarson> has anyone been able to run the sample/test zenbleed code on freebsd?
20:35:09 <mason> satanist: I used to do it in ipf. I assume the other two options both do it. Looking.
20:35:25 <wcarson> 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
20:35:58 <mason> satanist: from https://docs.freebsd.org/en/books/handbook/firewalls/ we see, for example, $cmd 00330 deny all from any to any frag in via $pif
20:35:59 <VimDiesel> Title: Chapter 33. Firewalls | FreeBSD Documentation Portal
20:36:23 <satanist> yes right a firewall can hadle this, the question was is there an systctl (ifconfig or rc.conf) setting to do so
20:37:37 <mason> satanist: sysctl -a | grep frag | grep net.inet shows some counters, but nothing that would drop them at that level.
20:37:50 <mason> ...at least as of 13.2
20:43:45 <satanist> does setting ip6_maxfragsperpacket to 0 does the trick?
20:44:27 <CrtxReavr> That sounds like a bad idea.
20:45:02 <V_PauAmma_V> Is this referring to the recent advisory?
20:46:33 <satanist> more or less, but no I don't look for a workaround instand of installing the patch
20:46:55 <satanist> I just would like to disable fragmentation
20:47:36 <wcarson> V_PauAmma_V: yes, https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2023-20593
20:47:37 <VimDiesel> Title: CVE - CVE-2023-20593
20:47:45 <wcarson> https://forums.freebsd.org/threads/zenbleed-is-coming-for-you-baby.89764/
20:47:46 <VimDiesel> Title: Zenbleed is coming for you baby! | The FreeBSD Forums
20:48:44 <V_PauAmma_V> No, not that one. I meant FreeBSD-SA-23:06.ipv6.
20:48:53 <wcarson> oh, sorry :)
20:49:02 <wcarson> https://bsd.to/AtHe/raw
20:49:03 <VimDiesel> Title: AtHe
20:49:23 <wcarson> 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()
20:52:02 <V_PauAmma_V> 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.
20:52:47 <satanist> a thanks overread this point
20:54:45 <CrtxReavr> The way IPv6 handles fragmentation is one of the cooler upgrades over Legacy IP.
20:56:38 <satanist> whats the diffrent beside it's a option (optional next-header)?
20:58:11 <V_PauAmma_V> Path MTU detection that's not an afterthought, IIRC.
20:59:02 <CrtxReavr> satanist, can you view powerpoint files?
21:00:16 <satanist> not tested, but if they work with libreoffice it will work, but would prefer an pdf
21:00:26 <CrtxReavr> https://trioptimum.com/~crtxreavr/tmp/4swede.pptx
21:00:35 <CrtxReavr> I'm not converting files for this. .
21:00:42 <CrtxReavr> But look at page 12 of this deck.
21:01:17 <RhodiumToad> wcarson: strdupa and get_nprocs are linuxisms, as far as I know
21:01:47 <wcarson> 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
21:02:34 <RhodiumToad> pthread_attr_setaffinity_np is supported if you include <pthread_np.h> I think
21:04:15 <wcarson> ok, i'll try that! thank you
21:04:38 <meena> wcarson: We have some getnproc function now for compatibility
21:05:16 <wcarson> oh nice
21:05:25 <wcarson> RhodiumToad: that did indeed resolve that warning!
21:06:08 <satanist> so yes you have to do path mtu discorvery, but still don't think this worth the complexity of fragmentation (in ip)
21:06:13 <RhodiumToad> I don't see a function to get number of cpus
21:07:07 <meena> https://freshbsd.org/freebsd/src/commit/48bfd3597654490cdc43bf0f591a539d3a28b590 nope, i was wrong, we just have nproc(1)
21:07:08 <VimDiesel> Title: FreeBSD / src / 48bfd35 / Add nproc(1) - FreshBSD
21:07:15 <RhodiumToad> the right way is to use cpuset_getaffinity
21:08:02 <satanist> CrtxReavr: btw not sure if this is intendet but the two example links have a to small mtu for ipv6
21:08:16 <RhodiumToad> in particular, cpuset_getaffinity lets you count the number of cpus available to the current process, which may differ from the actual hardware number
21:08:31 <meena> RhodiumToad: as seen in the code i linked ;)
21:10:34 <CrtxReavr> satanist, just a visual aid. . .
21:11:47 <CrtxReavr> 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. .
21:12:13 <CrtxReavr> And then the next router, will have to fragment those down to 53 bytes. . .
21:12:44 <CrtxReavr> And then the next router, will have to re-assemble them into 1000 byte packets again, all of this eating router CPU time.
21:13:07 <CrtxReavr> Same scenario, in v6. . .
21:13:22 <satanist> > And then the next router, will have to re-assemble them into 1000 byte packets again
21:13:30 <RhodiumToad> routers don't reassemble, only the destination does
21:13:43 <satanist> not true, he might do but most just don't bouther
21:13:49 <CrtxReavr> 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!"
21:14:13 <CrtxReavr> so the sending host will start over.
21:14:30 <mquin> Isn't the minimum fragment size for v6 something like 1280?
21:14:42 <CrtxReavr> 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!"
21:14:44 <satanist> path mtu discorvery is nice (also for v4), the fragmentation on ip level bothers me
21:14:54 <CrtxReavr> s/810/53/bytes.
21:15:14 <satanist> it's horrible complex and quite easy to get wrong
21:15:18 <CrtxReavr> And then the receiving host will re-assemble them. . . puts the burden of fragmentation on the sending and receiving hosts.
21:15:39 <CrtxReavr> PMTU doesn't exist for v4.
21:16:40 <CrtxReavr> That's a slide deck for a presentation I gave for v6 to an incoming class of summer interns.
21:21:10 <RhodiumToad> satanist: reassembling fragments not addressed to the router is a MUST NOT in the router requirements
21:21:25 <RhodiumToad> oops, missed them
21:24:53 <RhodiumToad> satanist: reassembling fragments not addressed to the router is a MUST NOT in the router requirements
21:25:36 <satanist> RhodiumToad: in v4 or v6?
21:25:45 <RhodiumToad> both
21:26:02 <RhodiumToad> there's a good reason for it, too: want to guess?
21:26:29 <satanist> reasambling is hard and needs ram
21:26:45 <RhodiumToad> there's no guarantee that a single router will see all the fragments
21:27:07 <satanist> a this also, I forgott
21:27:23 <satanist> my networking class is a few years old
21:27:31 <RhodiumToad> that's the main reason why it's a MUST NOT rather than anything less
21:31:01 <satanist> but say that CrtxReavr not me, he might want to update the explanaitio for his lessens
21:31:33 <satanist> also pmtu is posible with v4, by optional setting the dnf bit
21:32:04 <satanist> yes require this in v6 is the better way
21:32:10 <RhodiumToad> not merely possible, but essentially universal
23:13:54 <yuripv> bapt: hi, mind taking a look at D41151?