Clarification: Wayland already is entirely ready for regular desktop usage. It is not yet ported to be ready for regular (simple, stable) desktop usage on any BSD operating system; FreeBSD has the most of the bunch.

(No comment about any of this being good, bad, etc. -- just a clarification)

cjs: there are some folks showing off hyprland screenshots in the FreeBSD Discord

It looks slick

i used wayland (via sway, on amdgpu) on freebsd 15.0 for a few months and had no issues, it seemed very stable

Isaac from rivervm is contracting at the foundation

finally, a useful Kerberos implementation in base: cgit.freebsd.org/src/commit/?id=7f2…78b9dd5f51c821d771b63d2e096f6fd49e9

dmesg 'linux: jid 0 pid 96821 (***): syscall arch_prctl not implemented', can you make dmesg ignores it?

how should I do so I can close my lid and still use my external monitor, as it is now, when I close the lid it´s going to sleep mode, but I still want that functionality..

nwe: try sysctl hw.acpi.lid_switch_state=NONE

regis: then I need to change it each time I dont have external monitor plugged in right?

I can't test it now and it's a default setting iirc so it should work like that out-of-the box though.

nwe: nah, /etc/sysctl.conf

nwe: But honestly, I'm not sure if it'll work and can't test it at the moment.

regis: ended up with devd and script, and set hw.acpi.lid_switch_state=NONE

i am not finding much useful documentation on using blacklistd + postfix... i want to blacklist SMTP clients which are listed in RBLs or attempt relaying, how/where do i configure this?

bugs.freebsd.org/bugzilla/show_bug.cgi?id=284444 suggests this might just work by default

I use Postscreen for that

i use postscreen as well, but how do i configure it? does it just work magically?

I have the following: gist.github.com/silenius/e84f3f83a818af8bcda3a0142d1d016d

mage: and this make postscreen add addresses to blacklistd? i don't see any blacklist-specific configuration there so i assume it does just work by default

no, I don't use blacklistd as I have HAProxy in front and blacklistd doesn't work with remote hosts

blacklistd is pretty useless as it works with socket files only

so i have this in maillog: Jun 5 12:13:29 fuchsia postfix/postscreen[34966]: DNSBL rank 4 for [80.94.92.152]:50674

which is higher than postscreen_dnsbl_threshold (2), but blacklistctl dump does not show an entry for it

ah, i wonder if this is because i run smtpd in a chroot

probably

there we go, with blacklistd_flags="-s /var/spool/postfix/var/run/blacklistd.sock" it works

+1 on mage postscreen approach. I'm happy to share my postscreen settings and RBLS which work for me

i already use postscreen, my question is how to make postscreen talk to blacklistd

and the answer is indeed "it works by default", but only if you manually create the socket in the postscreen chroot

which does not seem to be documented anywhere, but i'm also not sure where it could reasonably be documented...

ivy: sysartist.com/tmp/postscreen.txt

ivy: What would you use blacklistd for? I understand some kind of abuse like brute-force or bots?

regis: to drop connections from hosts which attempt to repeatedly connect, to avoid spamming maillog and creating unnecessary load on RBL servers

ivy: I really only needed to do it on shared hosting (and we also had to implement web panel option for people to whitelist themselves in case they got blocked after unsuccessful dovecot login auth attempts etc) but I seriously don't bother fith blacklistsd or fail2ban on my private MTA. You do you of couse.

regis: blacklistd is a bit faster than fail2ban, it can break connection upon failure, but software support is very limited

mzar: I'm not arguing around blacklistd/fail2ban comparison but just asked if any of these is really needed. That being said, I have little experience with blacklistd and never had issues with fail2ban's performance on environments like shared hosting - blocking addresses after several IMAP or SSH auth failures, bots scanning websites for vulns and getting given number of 404 responses during some

timespan, etc

I am sorry, I didn't follow

it's not "really needed" since postscreen will drop these connections anyway, but it avoids generating 10MB+ of /var/log/maillog per day on a system that processes < 500 actual emails per day, which wastes CPU cycles and makes it harder to notice actual issues

huh, when did abuseat.org get swallowed by spamhaus?

lines missing? always need plain? imgur.com/9RY3pcA

If creating a little utility, should I be storing state in /var/db/<program> or /usr/local/var/db/<program> ?

tk: /usr/local/var/db/ is nonexistent

Sure, but I can create it.

I assume you mean to imply that its non-existence suggests everything should be using /var/db regardless of whether it's installed to /bin or /usr/local/bin ?

tk: I don't know, can't judge, but never seen /usr/local/var/db/

tk: /opt/tk-rulez/<program>, but make the path easily configurable in case your utility ever gets included in FreeBSD or ports?

I doubt anyone will ever include my utility in anything. Would it be /opt/<organisation>/<program>/var/db then?

typically the buildsystem resolves $PREFIX or something to /usr, /usr/local or whatever floats your boat

The question is not where to put the binaries, I already understand the idea behind /opt and /usr and /usr/local, I was asking specifically about "database" type of data

tk: /var/db/ looks reasonable with regard to anothe db

tk: don't use /opt, that's an SVR4 thing, BSD doesn't use it. don't use /usr/local/var, ports specifically recommends against this because /usr/local is not meant to contain volatile data. use /var/db/<yourprogram> which is the standard path for this.

thanks ivy

Yes. I agree with: /var/db/<program>

security/krb5 puts its data in /usr/local/var but this is wrong and it shouldn't do that

Since its personal software on personal systems, the question really becomes what you desires to achieve?

also even *if* you want to use /opt, you don't use /opt/myprogram/var/db, you use /opt/myprogram/bin, /etc/opt/myprogram and /var/opt/myprogram

but again this is SVR4, not BSD

ek: You've read `man hier`. I'm uncertain if it answers your question.

ek: sorry. tk was the intended recipient.

Yeah I think hier(7) combined with what ivy said seems to answer what I needed

|cos|: All good!

ivy: [tj]: Well, it is great to know that the next -RELEASE will have some daily driver ready Wayland :)

That will make FreeBSD the first of the BSDs to have Wayland for someone who is not trying to write code for Wayland.

er, is there actually anything specific to 15 for Wayland? wouldn't really think so

-/20

not that i'm aware of, other than having a newer drm version

i was mainly responding to the person who said Wayland won't be stable for 10 years, which seems... inaccurate

adrian: are you going to land D50111 or do you want me to nag kevans for approval and do it myself?

er, wrong channel

ivy: Have you ad issues with "never drm" versions?

s/ad/had/

regis: i don't know what "never drm" means

ivy: Apologies - s/never/newer/

ivy: quoting you. I refer to: not that i'm aware of, other than having a newer drm version

regis: ah. the reason i mentioned that was that 15.0 has newer versions of drm-kmod than stable/release versions. so it's possible someone using 14.x might have encountered problems that i didn't.

i have no idea about specific versions of drm-kmod and i'm not currently using freebsd on desktop

ivy: Got it. I switched from 14-CURRENT directly to 15-CURRENT.

That being said, drm-kmot is a port and you can you can switch to 'latest' (HEAD) ports on 14.

s/kmot/kmod/

yes, but the 14.x "latest" version is older than the 15.0 "latest" version

the port makefile contains conditional code to build an older version on 14.x since it's missing KBI features that are in 15.0

(mostly related to LinuxKBI, aiui)

ivy: Are drm-kmod and amdgpu from HEAD working differently on 14?

regis: they don't "work differently" but they are different versions of amdgpu

By HEAD here, I mean latest ports and compiling from ports, not pulling pkg.

each new release of drm-XX-kmod typically requires new features from the Linux kernel being added to LinuxKBI, and those features are added in -CURRENT first, so it's typicaly that e.g. 15.0 has drm-66-kmod while 14.x only has drm-55-kmod, or whatever

('66' and '55' are made up version numbers, but you get the idea)

ivy: Ports HEAD is the same for release/stable and current iirc.

no, you're misunderstanding my point

lol

'drm-kmod' is a meta-port that depends on a specific port which is called drm-XX-kmod, where 'XX' is the version of the Linux kernel the drivers were taken from

ivy: Ah, so you mean that 14 is missing some linux features from linuxkbi to make this stuff work. Got it.

the metaport almost always chooses a higher 'XX' (Linux kernel version) for 15.0 than it does for 14.x

this means people using drm-kmod on 14.x have an older version of the DRM drivers than people on 15.0, even if they're both using drm-kmod from the ports main branch

ivy: I know what drm-kmod is. I was pulling it from github and testing different branches based on different Linux kernel versions before it was merged to ports.

regis: ok, then perhaps you weren't aware that this changed when the driver was added to ports. i'm not insulting you, i'm trying to explain why people on 14.x have an older version of the DRM drivers.

ivy: Thanks. I was under the impression that since you can install it on 15 from ports, you could do it on 14 from HEAD ports as well.

that is true, you can install drm-kmod on both 14.x and 15.0. however, on 14.x, you will get an older version of the drm-XX-kmod driver.

because drm-kmod is a metapackage which depends on the specific version of drm-XX-kmod for the version of freebsd it was built for

But the 'specific version' is the same from HEAD ports for 14 and 15

no, it's not

Unless there are some Makefile if/or

please look at graphics/drm-kmod/Makefile to understand this

right now, freebsd 15.0 gets drm-66-kmod, while 14.x gets drm-61-kmod

unless you're on arm64 or i386 in which case you only get drm-510-kmod...

ivy: OK, I understand that there some established defaults. But have you tried: git clone github.com/freebsd/drm-kmod; cd drm-kmod; branch -a and compiling from different branches?

these are not "defaults", this is the *only* supported drm-XX-kmod version on each release

regis: do that, give it a shot, then have a look at the code and see why it fails ;)

ivy: clone above repo, git checkout origin/6.6-lts

unless you have an example of a 14.x system running drm-66-kmod, which i would certainly be interested in

ivy: I have a TON of builds going, but I could try drm-66-kmod build with a pourdriere 14.2-RELEASE jail for lolz

SponiX: I'm the one suggesting, not the one requiring a hint ;)

SponiX: i recommend not wasting time to respond to someone on IRC, but it's up to you :-)

ivy: but I think even if it did manage to build properly it would likely kernel panic when it attempts to load

this discussion is fairly bizarre tbh, anyone who's actually used drm-kmod on freebsd is aware that newer freebsd versions have newer drm-kmod versions

regis: I'm on the old "try it and see" stance

i'm not sure why someone would try to argue this is not true, other than trolling

SponiX: Sure but I thought that you directed your comment not the right person. You wrote "give it it a shot" to me when I'm a guy here, telling someone how to do something.

ivy: You got your hints. Work on them.

lol

ivy: Not that I like responding to "lol" but tl;dr: pull the official repo and compile this fucking thing from proper branch on your 14

O my

root@bareMetalFreeBSD:/usr/ports # poudriere testport -j 142amd64 -p latest graphics/drm-66-kmod

=======================<phase:check-sanity>============================

===== env: DEVELOPER_MODE=yes DEVELOPER=1 STRICT_DEPENDS=yes USER=nobody UID=65534 GID=65534

===> drm-66-kmod-6.6.25.1402000_3 not supported on older than 1500031, no

kernel support.

*** Error code 1

It literally says to "check your sanity" lol

OK, my mistake. I was unaware of this.

SponiX: this person is obviously trolling, i suggest /ignore ...

ivy: you are correct, it for sure will not build

ivy: Its okay, I'm new to FreeBSD, and don't mind the extra time to confirm ;)

mason: have you seen this? openzfs/zfs #17340 -- apparently, they may have actually fixed the long-standing data corruption bug in ZFS native encryption

I stated that I switched direction from 14 CURRENT to 15 CURRENT. Sucks to be called a troll.

Yeah, its okay to just not know something. It happens

I've been doing Linux since roughly 1995. And only recently got into FreeBSD. So the "try it and see" was my honest recommendation. I wasn't trying to be an ass or anything

That does remind me though, I probably need to make another bectl snapshot in case I do jack up my OS

ivy: I haven't. Reading now - thanks! It would be extremely convenient for native encryption to be reliable.

mason: right? although aiui, they aren't quite sure why this actually fixes the problem. but apparently it does

ivy: Yeah, the commentary near the end makes me think I want to wait to see the test suite updated, a reliable root cause identified, and then for some time to pass with people happily encrypting away before I migrate.

this also doesn't change that they continued to ship ZFS encryption for years with a known data corruption bug and felt no need to informs users about it

apparently i am being told off in another channel for going on about this, but i find this very concerning

Oh? =looks=

anything related to data corruption should be taken seriously

the last episode of 2.5 Admins seemed to give it a decent explanation (the ZFS encryption bug/fix on raw sends)

finally got around to opening an issue for my weird poudriere bug: freebsd/poudriere #1225

ivy: might not be needed, but your jail OS version isn't filled out on that post

SponiX: yeah i wasn't sure what to put there

the poudriere jail is the same version as the host

also filed my first BIND bug: gitlab.isc.org/isc-projects/bind9/-/issues/5361

apparently today is bug day

> the poudriere jail is the same version as the host

version of?

regis: Version of the host. 15.0-CURRENT

how's 14.3 RC1 looking?

things seem to be going smoothly

nice