Is there a channel to discuss ports bugs/feature requets ?

mns: #freebsd-ports ? Though I don't know how active it is

edenist: thanks. only one way to find out :-)

btw if i lock root, why can daemons, like sshd, still start running as root? when i tried to run caddy's rc.d with a user i made then locked, it said it couldn't start

alepzi, That one I can answer. It's because those daemons like sshd do not ever "login" to the system. They are started from other processes which are already running.

can't they login as themselves?

At boot time the system boots and that is not a login. That starts the kernel. Which is not a login. That starts init. Which is not a login. Which runs the rc scripts. Which are not a login.

so why does caddy's rc.d script fail, it's a login?

I don't know anything about caddy. What is it? Can I look at what it is doing and see?

web server

so it's ok to lock root account and it won't prevent system services from running as normal?

I can't imagine it being a good idea to "pw lock root" the root account but I think most things would not notice.

why bad?

The infrastructure of any system is running as root. Trying to lock out the root account is similar in flavor in my mind to shutdown.

Certainly powering off the system will keep it from running anything. But that's not a useful system.

are there ways to brick your system other than rm -rf /

if there are that would make sense as one of them

The superuser root user is the fundamental user of the system. Blocking it I think won't work but if you are blocking it then you are blocking the system from functioning at the basic level.

well if i NEVER login as root why not lock it.

all pw usermod -w no does is disable password auth, but not other auth methods

I can't imagine being able to do system administration without using root access. How would that even work?

so i don't think that's powerful enough

sudo

sudo is blocked on locked accounts.

well i can do privileged things so dunno

user account is in wheel

You can do privileged things because it is not locked.

no, it's with root being locked

like sudo id, shows root

sudo ls -la /root, etc

That's only because you can't actually lock root out of the system.

Since root is the superuser and we call it the superuser because it is like superman and able to do things that normal accounts cannot.

so then it should be fine to lock it?

I think everything will still work and you won't notice.

I still think it is not a good idea because you are testing something that no one else is testing.

this feels like those paradoxes where you ask can an all powerful god make a rock so big he can't lift it. can the root destroy the system so bad root can't login?

ok so how do you lock down root account without locking it

Why isn't just using a starred out password field enough? That's what everyone has always done and is a well tested path.

Star out the password field.

because that only disables password auth, but NOT ssh key auth

so disable root login and pw login in sshd_conf? ya, did that too

but what about some other auth method?

Off the top of my head this command will do it: "pw usermod -n root -w no" But let me double check that I have that syntax correct.

pw lock covers all of them

ya that disables password auth

NOT all auth methods

Yes. That's a good syntax for it.

the man page is wrong when it says it disables login

pw lock disables all auth, -w no disables pass auth only

pw lock goes FURTHER and puts *LOCKED* at in the password field. And in FreeBSD some additional things look for that field and block access based upon it.

ya

I fear that some of those things might be things you actually really want to work for the system.

and i've verified that causes a rc.d service to fail to start, but -w no doesn't

ya me too

feels kinda loose

freebsd i mean

How does FreeBSD feel loose? It feels tight to me. Because that "*LOCKED*" thing is more than other operating systems do.

but you say to not use it

and to use the weak af -w no

I think it is a bad idea to use it for the root user. It's certainly fine for all of the other accounts. But we are debating the merits of using it for the superuser account.

right so ur point is irrelevant

for root you say don't use locked, but only locked is REAL login disable

Anything unrelated to elephants is irrelephant.

-w no isn't

Hmm... I am rolling around "real login disable" in my mind with regards to the root user. I don't think it really makes sense there.

And here you have already said that caddy does not work with it that way.

I am going to go peek at the caddy rc script and see what it is doing...

my guess is system started services, like them in base, are started either before auth is checked, or through a backdoor after auth is checked

If anyone else wants to look too: cgit.freebsd.org/ports/tree/www/caddy/files/caddy.in

Title: caddy.in « files « caddy « www - ports - FreeBSD ports tree

The boot time init scripts are definitely not the back door btw as that is definitely the front door. :-)

so same interface any other service or exec permissions are checked?

if /var/log/messages is written to, is it safe to assume that pw lock root causing any problems would show up in the messages log?

What do you have in your /etc/rc.conf file related to caddy? grep caddy /etc/rc.conf and if it is more than two lines please pastebin for me?

lemme look

Most things would log problems to /var/log/messages okay. It's always good to keep an eye on that file.

I use a utility to email lines from /var/log/messages and the other files there that are not filtered out. I filter out all normal things and then exceptional conditions are emailed to me.

oh wait no i remember now it was a rc.d script for an inhouse bin that ran daemon and it starts the bin

don't have access to the script rn sadly

nice

how often do you get emails?

johnjaye, It does feel a little like those paradoxes. But normally root has no permission restrictions. chmod a-rw to remove all read permissions from a file and yet root can still read the file because, root is the superuser. This means that lots of things done to limit permissions just have no effect on root.

alepzi, I *aggressively* filter the logs and so not very often. I only get emails when there are exceptional conditions. Like the disk filling up.

At cgit.freebsd.org/ports/tree/www/caddy/files/caddy.in#n109 line 109 and line 131 we see that su -m "${caddy_user}" is used to start the caddy process. Without knowing anything other than that you are locking accounts and that this script is failing for you then I suspect that is the most likely place for things to fail. But would need to debug it to actually know.

Title: caddy.in « files « caddy « www - ports - FreeBSD ports tree

any fundamental diff in how sudo works vs su?

or both use same auth interfaces etc

It's slightly better than a complete guess. But having actual data is always preferred. Ground truth is always the best.

Conceptually both su and sudo end up in the same place. But implementation wise they are written by different people and have a different implementation.

i'm gonna switch to doas if i can because it's way smaller

su is of course the original command from the beginning to use to switch user and hence the name and require the target password. sudo came along somewhat later to require the source user password instead of the destination password because that solves the problem of changing passwords and not sharing passwords.

doas is basically the same as sudo in concept but again written by a different person with a different implement.

alepzi: I prefer sudo over doas. sudo has a nice facility that uses sha256 digests to verify commands you're trying to run. If anyone changes the files, the digest verification fails and sudo wont run the command. a very helpful feature.

Stuff here irl bbiab...

what's that mean msn? sorry i dumb

"verify commands"

"changes the files"

a user's home dir is owned by them, but the user can't rm -rf their home dir because root:wheel owns /home the containing dir right?

sudo is based on rules, rules in which you can define what commands are run by what users/groups. what if you have a sudo rule to start caddy and someone changes that startup file and modifies it in a way that compromises root access ?

What I think it means is that sudo can (optionally) run sha256 on the file for the command you're trying to execute, compare it against its stored value. If they don't match), sudo will refuse to run the command, as it may have been infected with a trojan or some other malware.

when does sudo generate those hashes? on OS start?

i take it if i want to share a host based zfs dataset with a bhyve image.. i have to use something like nfs so the guest can see the hosts zfs dataset?

alepzi: you have to provide it as part of the rules for sudo, its in the manpage

ah ok and doas doesn't have that?

seems like a good feature

alepzi: no doas does not have that.

alepzi: for the home dir, yes you are correct /home is owned by root:wheel so you can't remove the /home/user directory, but you can remove everything inside that directory. To remove /home/user you need write privs in /home

so to have perms to a dir you need perms on the containing dir

otherwise you just have perms IN a dir

(where you have perms on the containing dir)

ty

any reason home dirs aren't 0700?

like why give world read?

I always wondered this myself, I think the same thing happens in Linux environments.

you usually want it 770 or at least 750, that way you can share with others on your system, using group settings.

but I agree it doesn't need to be world accessible

alepzi: why using caddy instead of lighttpd or nginx ?

easy ssl cert autorenew lol

I get that with lighttpd as well.

oh ya?

any other things you know lighttpd vs caddy? sell me

I use dehydrated to do the autorenewal with Let's Encrypt. I have lighttpd, postfix, dove, etc. all use the renewed certificates. with caddy the certs are used just by caddy as I recall. Also caddy's licensing.

feels like it's been a long time since I've heard about lighttpd. at least in the past wasn't it kinda notorious for memory leaks?

I'm thinking like circa 2010-2011

I am having troubles setting the mountpoint of a ZFS dataset. I'm getting:

cannot set property for 'storage/archive/git': 'mountpoint' cannot be set on dataset in a non-global zone

have not seen this one before - any ideas?

ya 1 of the things i like about caddy is it uses Go, a more modern less error prone lang than C and C++ even if it's not as fast

i really want to move everything to shit like rust

personally, I've been using nginx for years, proxying to thttpd for CGI. dunno if the last bit is actually great for high load, but for a low-traffic server it works

if linux rewrites in rust and freebsd doesn't i think that'll be the coffin

I switched to lighttpd from apache around 2008 I think and it has always focused on being secure, small and fast. Never had memory issues with it.

solved: dataset was jailed

I might have to take a look at caddy again, seems like there have been improvements since the last time I looked at it

ya

tm512: imo gzdoom should instead be including the files outside of the namespace then `using ::foo` each one it actually needs back in

iirc how it works

s/one/symbol/

anyone know how to convert /etc/rc.local script into /usr/local/etc/rc.d/ script? i tried to just mv /etc/rc.local /usr/local/etc/rc.d/sysctl but it doesn't seem to get run

alepzi: what i find weird about the rust is it seems like it's replacing c++ more than c

so D or Go might make more sense as "modern" alernatives to C

seems to me to be replacing both

rust has no GC but go does so imo it's better as c replacement than go

kevans: with C++, if a symbol is not in the current namespace, doesn't it already just look in the parent namespace? that's the impression I got when I asked about that in #c++ last night

alepzi: Rust is more of a C++ replacement. both are "everything but the kitchen sink" languages. Go's comparison to C is more with its simplicity, afaict

C simple lol

yeah. i think D is closest to what i'm thinking of. something like, C but no enforced gc but without all the goofy UB rules.

compared to the alternatives for systems programming languages, C is very simple

not necessarily simple to use, but definitely leans more towards minimalism for its feature set

there's a silly example of using undefined behavior to format your hard drive. it relies on gcc reasoning that since a function call can't be undefined it must be an unused function therefore it substitutes it in.

kevans: if I get around to patching GZDoom (properly, not my #undef hack) before you do, I'll send over the patch. hopefully it applies both on the g4.11.3 tag and on HEAD so I only have to make it once and can send a pull request upstream

has anyone tried to "pass" a zfs dataset on a host bhyve to one of the bhyve images downstream? currently it looks like with a nfs share i COULD do it.. but was curious if there was another option available, that i may not be aware of.

all searches are pointing to nfs or smb is the only way.. but before i go down that.. was just throwing feelers out

FreeBSD's lack of support for Xbox Series X|S controllers kinda defeats the point of getting GZDoom running though, at least for me

tm512: can you elaborate. is it the xbox 360 dpad being crap issue i brought up?

this doesn't have anything to do with the 360 controllers

there's just no driver available for Xbox controllers newer than the 360, and I'm not clear on exactly what would need to be done to modify the 360 controller driver

right. but i meant is it because you only have xbox one controllers. or that the 360 ones are deficient in some way

my Series X|S controller is the only one I have that works reliably

I have a 360 controller, but the cable is in terrible shape, struggles to maintain a connection

on top of that one of the analog sticks is really worn out, although it'd still be usable if it weren't for the cable

i had an old 360 controller i could give you. but idk what i did with it

i'll have to go hunt around a bit.

the controllers are pretty cheap it seems. I'd rather get newer controller support in the driver, though, since in general the newer controllers are just nicer to use

nicer d-pad, also the controller grips are textured and don't get quite as slippery with sweaty hands

kinda gross, but it's just a reality like during the warmer months of the year and/or when adrenaline gets pumping

kinda wondering if things will Just Work if xb360gp.ko is instructed to recognize the newer controllers, like given the proper USB (sub)class IDs. Linux's xpad driver seems to have a bunch of extra stuff for the newer gamepads, but peeking at NetBSD's code, I wasn't seeing any special handling for the newer ones

could've been stuff elsewhere that I was missing, though

so maybe I was misremembering NetBSD's support of this controller. it does not show up as a joystick under SDL, even though NetBSD loads the uhidev driver for it

so perhaps NetBSD's driver can't be used as a direct reference for extending FreeBSD's driver

apparently on Linux, when these controllers are paired over bluetooth, the device-specific xpad driver is not used, in favor of the generic HID bluetooth profile. I wonder if that could be a workaround on FreeBSD? assuming the bluetooth HID stuff is mature enough to support stuff like axes on gamepads

and that libraries like SDL actually know how to interface with that stuff on FreeBSD

anyone know how to convert /etc/rc.local script into /usr/local/etc/rc.d/ script? i tried to just mv /etc/rc.local /usr/local/etc/rc.d/sysctl but it doesn't seem to get run

alepzi: see /etc/rc.d/motd for an example of a trivial rc.d script. just replace motd_start with whatever you want to run (and change the name, of course)

also, are you aware of /etc/sysctl.conf? usually there's no need to run sysctl in rc.local

i wanna set up a sysctl security mac portacl rules line, using a var from $(id -u username)

ya i have some stuff in /etc/sysctl.conf. i guess i could maybe put it in there

would like to put it in like a /etc/sysctl.conf.d/ instead

i don't like big combined files

hi, i'm new to freebsd. the page freshports.org/multimedia/wireplumber shows "Package not present on quarterly. ". does this mean there is no prebuilt / binary package available until the next quarter OR it is available but require installing it differently? `pkg search multimedia/wireplumber` doesn't show me anything on freebsd 14

Title: FreshPorts -- multimedia/wireplumber: Session and policy manager for PipeWire

termbin.com/7bst is the /etc/rc.local i'm trying to reimplement better

petrj: it means that port isn't in the quarterly ports tree at all, because it was only added yesterday. so you need to either switch from quarterly to latest, or wait for the next quarterly release, which i think should be in early April

not sure if boot loader, sysctl, rc, or some other config mechanism is best

alepzi: regarding switching to latest, should just be changing the URL that pkg points to, then running `pkg update` to fetch the new package lists, though presumably this makes you more likely to run into issues with packages before they have the opportunity to be fixed

I don't recall any problems personally though

the repository URL will be in /etc/pkg/FreeBSD.conf

note that according to that page there's no package for this port anyway, probably because the builder hasn't run yet

so even if you switch to latest you'll need to wait for the package to be available, or else build it from source via ports if you really need it right now

what is pipewire like on FreeBSD anyway? I think I recall reading something that made it seem like it doesn't really integrate well with other packages, because you'll still have other packages (like firefox) pulling in actual pulseaudio

doesn't seem aware of pipewire as an alternative provider of a pulseaudio server

termbin.com/7bst is the /etc/rc.local i'm trying to reimplement better. not sure if boot loader, sysctl, rc, or some other config mechanism is best?

alepzi: docs.freebsd.org/en/books/handbook/mac/#mac-portacl sysctl.conf is best, no need to reinvent the wheel

Title: Chapter 18. Mandatory Access Control | FreeBSD Documentation Portal

and i can put the var setting line in it too?

nope

ok so it's not an option for me

so maybe rc.bsdextended is for you ?

well rc.local is working already so i'd want it to be an improvement

otherwise why bother

OK

there should really be a /etc/sysctl.conf.d/ for parity with the other systems

rc etc

not that that would fix my problem

alepzi: there are no other systems to pair with

you must be missing the point

seems weird that man rc.local says to split rc.local up into /usr/local/etc/rc.d/ services. like this is stuff that's run, never 'stopped'

tm512: is there already a linux driver for that?

lw i guess your point with rc.d/motd is that it's also just some code that needs to run, and not really a 'daemon' that you can start/stop/restart...

alepzi: there's no expectation that an rc.d service should support stopping. /etc/rc.d/motd that i mentioned earlier has no stop action, for example. neither does /etc/rc.d/sysctl iirc

ok tyvm i'll duplicate rc.d/motd and go from there

you can restart motd, though, which you would do if you updated motd.template, or you would restart sysctl if you updated /etc/sysctl.conf. it seems like your script is the same way, you would want to restart it if you changed the configuration

and this requires in our rc config to have ourmotdclone_enable="YES" to get the rc.d script run?

yes

ok

johnjaye: for the Xbox Series X|S controllers? yeah, the xpad driver, which also handles 360 controllers, supports them basically flawlessly

there are a lot more people working with Linux though and there's probably quite a bit more interest in having game controllers work

tm512: ah it sounds like an interesting project.

sadly i'm just studying the ports system and have no idea how to do a driver in freebsd nor linux

does the arch handbook talk about it?

I think there's a page on their wiki about controllers, but that's Linux-specific stuff

seems like FreeBSD's controller support has no relation. the Linux xpad driver is GPL-licensed, fwiw

even if it were ported to FreeBSD it would need to be developed out of tree like drm-kmod

and at this point there's no point since FreeBSD already has its own foundation for game controller support, the specifics just have to be implemented

oh i see. is that what they call "clean room" implementation?

ah and the hard work is in "the specifics". well anyway i'd like to write a driver of some kind, dunno if that would even be possible for a first project though.

no, that's when you write a new driver based on a description of another driver, without looking at the source code (or a new implementation of anything, not necessarily a driver)

lw: right that's what i mean if you wanted to avoid the GPL license

with a clean room implementation you can use any license you want, so such driver could go into src with a BSD license

ah, i thought you were asking if out-of-tree was the same as clean room

I dunno if I'd even call the stuff that's already inside src for game controllers would really be "clean room" since the goal isn't to clone some specific driver or interface, though maybe the term could still apply

ah i see it's in the dev/hid folder

my impression is that often people just look at the linux driver and write a freebsd driver from that, which is maybe a bit iffy from a legal point of view, but i've never heard anyone complain about that

oh ok, makes sense

unless you're like, copy+pasting entire lines of code from the linux driver, in which case just don't do that :-)

lw: also it's probably more like reading it as a spec sheet type thing. since the driver infrastructures are probably very different

if you've written a driver do you know a good tutorial on getting started

I would like to get this controller working with FreeBSD, but A) I'm not familiar with FreeBSD's code or driver development in general and B) I would need to confirm that support *is* actually lacking currently, and that I'm not just messing up my configuration

i have not written a driver from scratch, but i think the book 'The Design and Implementation of the FreeBSD Operating System' might be a good place to start

but I've got both usbhid loaded and enabled, and hgame loaded, and the usbhid driver doesn't even attempt to attach to the Xbox controller

tm512: can i test that with a vm or do i need a on the dist install and then try plugging in an xbox controller?

if I plug in my 360 controller it does though, as usbhid0

johnjaye: well, I think bhyve lacks USB passthrough, if I'm not mistaken

oh

you sure?

it does afaik, but you can passthrough an entire USB controller, like if you have a separate USB PCIe card

i meant the freebsd vm running on my linux laptop

johnjaye: if KVM allows USB passthrough then yeah

NetBSD's driver does indeed pick up on my Xbox Series X|S controller, through their uhidev driver, though I failed to get anything using SDL to actually see it, could've been a failure to configure things (like maybe permissions?) properly. but that makes me a bit suspicious of FreeBSD's silence when I plug in the controller

the only message I get is from ugen

NetBSD's uhidev is seemingly analogous to FreeBSD's usbhid, both are for USB HID support, clearly the controller is supporting this protocol or whatever, makes me think that usbhid should at least be able to attach to it even if it doesn't provide the expected functionality

I dunno if there's some devd stuff I could do to force usbhid to attach to a device with the controller's IDs

if i'm setting sysctl security.mac.portacl.rules in a rc.d/file, what do i need to REQUIRE?

tm512: regardless it sounds fun, hit me up if there's any way i can help

ok i got it working. rc.local gone now

listchans mml/who oz1tmm

whoops, sorry :)

LISTCHANS: Unknown command

tm512: what driver are you using for a 360 controller?

re: gzdoom, right, but they want it accessible via that namespace from other namespaces, presumably

I think the easiest approach is to just move al the includes out of the namespace, then see what fails to build because the names aren't where they're expected to be and just `use` those back in where the includes were

poudriere on a different host with a different cpu, but same architecture will produce compatible binaries for any cpu (intel vs amd, x86 as an example)?

beastwick: amd64 == x86_64 != i386, so with default settings the answer is: Yes

mzar okay so that's good, I am just curious though, are the packages built with generic options, no cpu optimization flags?

I have one older intel cpu and the packages will be built on a more recent amd chip

so like, I think with that setup on a gentoo binhost I'd have problems, but not sure about Poudriere

oh I have to take a look at make.conf but I am guessing optimized flags is default off

yeah, my assumption is the defaults are not tuned to cpu specific optimization flags, which is to my benefit here

kevans: it loads xb360gp for the 360 controller. can't really test to ensure that the controller actually *works* through the driver, though, because at this point the cable is even more finicky than it was when it prompted me to just get a new controller

hence my interest in being able to use my Series X|S controller

kevans: as for GZDoom, FileSys is supposed to be an abstraction over OS-specific file stuff, I doubt that code outside of the namespace uses these. one way to find out though

if I had to guess, it's got the headers inside the namespace to cut down on the number of WIN32 ifdef-else-endif?

anyway, off to work

lw: strongswan works and i detest it less then the old racoon. if it supports your usecase openiked could be a less painful alternativ

the other question is does it have to be ipsec or does wireguard fit your usecase?

I am thinking of using FreeBSD as my hypervisor to run VMs, jails, containers(thru linux), etc. Is the CBSD route the best way to do this? On top of this, I also want to use the operating system as a NAS. Do you folks see any issues with using the OS as NAS in this scenario?

freebsd is very popular for nas, including some of the biggest nas in the world like netflix cdn

I want to build a powerful enough machine to meet all kinds of meets. Would you still recommend a dedicated harware to run FreeBSD as a NAS solution?

all kinds of needs is too vague. I always try with what i have and measure exactly where its deficient.

some say nas should always be a dedicated machine behind a dedicated firewall, but the use cases are so vast

In my case running AI models, running VMs, containers(via Linux guest host), plex server, gaming(pass through)

yes, thats a very, very small use case. you can probably get away with anything. I am doing that, except i don't use plex, my wii is jailbroken to load games/movies/music from smb. i use a thinkpad x230 (ancient) and a dedicated nas on apu2 (ancient and low power).

if i had a desktop made in the last 10 years, I imagine that'd be all I need.

if your computer is powerful enough to play with ai, its probably more than enough to have a nas vm, but iirc there's... caveats

-- due to the protocols, nothing to do with freebsd

my house is using 181kw/month lol

tm512: that doesn't actually cut down on if-else, though

you still need to know the names

tm512: ah, I see what you meant

anywho: ZDoom/gzdoom #2470

Title: src: filesystem: move includes out of the FileSys namespace by kevans91 · Pull Request #2470 · ZDoom/gzdoom · GitHub