I'm not well versed with FreeBSD binary packages, but I'm not easily finding this info: I develop Golang applications mostly and build deb/rpm packages for them on macOS to privately distribute them to my fleet. I wish to support FreeBSD in some of my fleet. How would I most easily create a binary package (.txz?) for FreeBSD to privately distribute the software? (i.e. not via ports)

Cyrus: create a port and use the existing pkg building system to build your package

So it sounds like it's a requirement I do the initial building of it on a FreeBSD machine itself.

yes, i don't think you get many options to cross build freebsd binaries

Damn, I was afraid of that. Alright, thanks!

Cyrus: yeah, create the port, then use: freebsd.org/cgi/man.cgi?pkg-create(8)

Title: pkg-create(8)

An application, we'll call it Mumble (because that's its name) locked /dev/mixer. I closed the application out and it is no longer running, but /dev/mixer is still not capable of being opened by subsequent invokations. How could I potentially investigate?

i'd start with fstat

didn't think of that, only ran 'fuser'

What's the best way to retain older versions of packages in case a downgrade is necessary? I know you can grab them from /var/cache/pkg, assuming it hasn't been cleaned since.

Poudriere has an option to retain older versions, which I haven't looked at yet beyond setting it to >1. Does it keep the packages in the .real* dirs?

poudriere has a keep packages option iirc

not sure where it keeps them

my guess: it just precludes deleting them

with no other tracking

is it possible to disable PAM? any pitfalls in that?

How do I fix this error, Ports Collection support for your FreeBSD version has ended, and no ports are

guaranteed to build on this system. Please upgrade to a supported release. i'm running 13.0

13.0 isn't a supported release. I believe 13.1 is, or you can begin tracking stable.

(the latter, I don't recommend.)

can i upgrade to 13.1 ?

sn00p docs.freebsd.org/en/books/handbook/cutting-edge

Title: Chapter 24. Updating and Upgrading FreeBSD | FreeBSD Documentation Portal

upgrade then portsnap fetch

Title: FreeBSD 13.1-RELEASE Installation Instructions | The FreeBSD Project

i read this one

yeah that will work 13.1 is supported

how do we run sshd as a non-root user pls? UsePAM doc in man sshd_config implies it's possible but I CANT FIND DOC ON IT

polyex: As in, run as root then drop privileges?

Or run entirely as a non-root user?

polyex: that's interesting, and you have piqued my interest.... I found the line in question in sshd_config manpage

"If UsePAM is enabled, you will not be able to run sshd(8) as a non-root user."

I suppose you could always run /usr/sbin/sshd directly either interactively or through your own scripts? But I'm trying to think of the implications to the functionality of sshd though

rorf

koobs: Yeah, I was looking at different ways to approach it. The packages aren't deleted, but I was wondering if poudriere has to explicitly ignore those when invoking pkg-repo.

oh, wrong channel lol

Oh nevermind, misread my client. Thought I as in #freebsd-irc.

i'm doing this, freebsd-update upgrade -r 13.1-RELEASE and its at the point where it has a : and does nothing until I hit return is this what i'm supposed to do?

kevans: What would you reckon is the best way to implement poll in /etc/rc/jail?

kevans: Last I checked it was a stub, which makes sense. I needed to block until a jail terminates, but couldn't find an easy way to do it with jail(8) or service(8). So currently I launch the jail and then have a shell script that polls it every X seconds until it exits.

kevans: I worked up a couple of other alternatives where 1) Create a FIFO and read it (blocking), then from exec.poststop write to it so that it unblocks on jail exit. B) Invoke `service nginx poll` after the jail starts (nginx is just an example, couldn't determine a pid 1 or equivalent to poll within the jail when using rc).

kevans: Then it occured to me that `service jail poll myjail1 myjail2 ...` would be useful here. How that would be implemented is a different case, but having it there would be really nice.

kevans: In case you're curious, the use-case for me is that the orchestration system I use across multiple hosts requires that when it launches a service on a host, it expects the process to block. If it exits, then it's considered a failure. I run most of my services inside of jails, hence why I need it to block. Would prefer it be event-based, but polling is fine for now.

_xor: I had never heard of poll until just now, let me take a look here

ah, ok, so this is supposed to be like a "service needs restarted" kind of indicator in a sense

hmm, rc.d/jail currently doesn't do anything, but I guess the intuitive action would be to poll jls -d for the named jail

wez ya wanna run sshd as a service, not from a user, so i guess that means start as root then drop privs

not sure what else sshd_config means by that line about running sshd as non-root user

kevans: Yeah, I'm using jls with libxo and jq to query the jail status in a loop and exit once it's stopped.

kevans: ...but I was more curious about whether there was an event-triggered method for doing that rather than having to poll.

The FIFO method I mentioned earlier is that, but it's a bit hacky.

I'm going to man the jail api and see if there's a function for it, but I'm not exactly expecting there to be so that wouldn't be much better than a polling loop.

I had a really half-baked idea of adding some kqueue functionality for jails

I was also pondering a simple rc.d script to run within the jail where all it does is block, that's it. Then from the host an rc script can invoke wait_for_pids on the specific pid for that rc script running in the jail.

kevans: Like what? I mean what use-cases are you thinking of for that?

you'd basically tap out kevents on jail state changes, so jail(8) could gain a poll/test mode where it just blocks on kq

oooh that would be nice

Have it on my desk by Monday! Stat!

*rimshot*

hah

Hmm, I guess since jails can run without a process, then there's no reliable process that can be monitored within the jail, right? Like, there's no pid 1 or whatnot.

right

Does it make any sense to have a sysctl to indicate states?

reminds me

devmatch: panic: general protection fault: sysctl_devices() -> sysctl_root_handler_locked() in hw.bus.devices sysctl handler

so maybe not (yet) :D

heh

so anyone run sshd as non-root or know how? (last time ill spam it)

What's the issue?

I'd imagine you could explore /etc/rc.d/sshd and see if there's a knob for it, or check /etc/ssh/sshd_config to see if it has settings to allow changing users and/or dropping privileges or whatnot.

ya looked in both

5 hours ago hehe

im in last call mode on this by now

if we only allow public key ssh in, any good reason user accounts should still have a pw?

i got "sshd error protocol major versions differ 2 vs 1" showing up in my logs not sure how to reproduce it. anyone dealt with it?

sshd_config man page says "2" is the default, i didnt change it, so that's what i got. any 1 stuff must be client side then

but i looked at the ssh_config (client side) and nothing about how to configure a protocol version

how i do?

man for ssh has "protocol-version" but no mention of how to use it

just under -Q for querying server capabilities

seems like protocol v 1 is disabled or just not enabled in fbsd land so where tf that error msg come from?

both 13.1 boxes lol

polyex: protocol version 1 is disabled by default with newer openssh versions and freebsd got that some time ago IIRC

any idea how i got that error msg to show up then?

polyex: did you do anything when it happened?

prolly

ive been fiddling with sshd config today but never touched protocol

Title: BSD Now 471: De-Penguinization

Penguins are the best

sorry if I'm missing something obvious as I'm pretty much a newbie, but in a clean 13.0 system I'm having this error as of this morning when trying to run wget:

ld-elf.so.1: /lib/libc.so.7: version FBSD_1.7 required by /usr/local/bin/wget not found

to my eyes, it looks as if the binary for wget in 13.0 had been "upgraded" to one that was built against the 13.1 libraries

yesterday this didn't happen

13.0 has been past EOL. 13.1 is one of the currently supported version. Packages are built only for the supported releases.

polyex: "The OpenSSH SSH daemon supports SSH protocol 2 only."; see also 'ssh -Q protocol-version' (only '2' on FreeBSD)

uname -a: FreeBSD srv001 12.3-RELEASE-p6 FreeBSD 12.3-RELEASE-p6 GENERIC amd64 and freebsd-update fetch install: No updates needed to update system to 12.3-RELEASE-p7

like one says p7 but reality is p6 patch level

what does freebsd-version -uk report?

12.3-RELEASE-p6

12.3-RELEASE-p7

dang that's an old release

well it is maintained

Every time I go to upgrade a specific port, I do a google and wonder why there's 1. So much different info out there and 2. Why the process is so inscrutable :)

Like this version of the handbook talks about making a diff file docs.freebsd.org/en/books/porters-handbook/upgrading

Title: Chapter 11. Upgrading a Port | FreeBSD Documentation Portal

Some old posts talk about portupgrade which isn't even in the 13.0 port tree

SpaceBass_laptop: That's the _Porter's Handbook_: For those that are actually maintaing the port system, not a user updating to the most recent port. Most users should use pkg unless they need a non-standard option.

Using pkg: docs.freebsd.org/en/books/handbook/ports/#pkgng-intro : 'pkg upgrade' should be all most users need to update packages.

Title: Chapter 4. Installing Applications: Packages and Ports | FreeBSD Documentation Portal

Too late to convert this entire system to pkgs - everything was built with ports because I needed some options that weren't compiled in some pkg versions

SpaceBass_laptop: You can still use packages and just build the ports you need non-default options in.

So should I just go back into /usr/port/path/to/port and make reinstall?

Or use Poudriere to build all the ports you need and then use those packages. This is usually what's recommended. Especially for multi-system labs/DC's.

SpaceBass_laptop: Sure.

I've tried poudriere and, while I think of my self as a reasonably smart person, it breaks my brain

SpaceBass_laptop: There is a bit of a learning curve, but once it clicks, it's fairly straight forward to use.

It's really only getting it started that takes a bit to learn. Once everything is in place, it's mostly only a few commands to do everything.

I'll try it again once I get this one port update

I've found synth works very well for the mixed custom/vanilla (leveraging pre-built where possible) setup. (In comparison to poudriere, which felt like using a sledgehammer to tap in a finish nail.)

Although the first thing to double-check is that you still need the custom options; I've found some ports that I needed to config previously now have the options I want by default; worth looking.

And so long as you're 11+ (if I recall) even if they're built from ports, they are still installed via the pkg framework; 'pkg info' should list them, for example.

Yes. The ports system uses the package it creates to do the actual install. So, using "pkg" commands for any information will work for any port installs as well.

The big one is samba which doesn't have a package with bind 9.16 backend support - you can only do it through ports

poudriere-devel can do the prebuilt thing that synth does too (-b quarterly or -b latest)

tao: thanks!

carbonfiber: np

polyex, "grep ssh /etc/passwd" hints sshd will drop privilege.

Oh wait, someone mentioned that before.

V_PauAmma_V yes, in wrong window

saltd, context for that?

answer unfound