oh wait.. it's still running

Something is wrong.

does anyone have a preferred FTP server with Kerberos support?

people still use ftp?

Hi. Where can I configure which user will send a mail with the daily/weekly/security periodic? Usually I got this mail from "root@mydomain" but now after 13-STABLE upgrade I get it from "polkitd@", sometimes "_sndio@" which is very strange.

I have had it spuriously from various sources because I didn't have my /etc/mail/mailer.conf set up for my then-Postfix, now-qmail setup; what MTA are you using?

For me those emails always come from root. I am using postfix so I can map them there in the canonical map.

imm_: that's definitely not normal, something has gone wrong on your system. you can't configure this as they should always be sent from root

imm_: can you paste the contents of /etc/passwd somewhere (e.g. on bsd.to)?

lw, I think that's a red herring. My passwd file wasn't muckled up and I still had this problem long ago.

strange, not having mailer.conf should just default to sendmail which shouldn't do this

(i mean, i believe you, but it's strange)

If /etc/mail/mail.conf is not set up then the result depends upon PATH and if something is hard coded for /usr/sbin/sendmail for example.

If something calls "sendmail" then gets /usr/local/sbin/sendmail and that is (in my case) postfix then the result might be different from /usr/sbin/sendmail being called from a hard coded path and not having /etc/mail/mail.conf configured it might send that one through the base sendmail instead.

s/mail.conf/mailer.conf/ as clearly I don't remember the exact path when typing this in off the top of my head.

rwp: whether this depend on $PATH isn't affected by whether mailer.conf exists. if mailer.conf doesn't exist, /usr/sbin/sendmail falls back to _PATH_DEFAULTMTA, it doesn't do a $PATH lookup. but the default (at least in -current) is dma, not sendmail like i said

at 13-stable the default was still sendmail I believe?

yeah, could be. i don't remember when the switch to dma happened

(imo it's wrong that postfix installs /usr/local/sbin/sendmail, but this is a whole other discussion...)

Looks like it is still sendmail to me on 13. And postfix is a port and ports install in /usr/local by policy.

rwp: it should be in /usr/local but it shouldn't be in /usr/local/sbin. /usr/local/libexec/postfix/sendmail would be more appropriate. that way there's only a single 'sendmail' on $PATH

I would be okay with that configuration. Note that I was not consulted in any way or at any time about this. :-)

yeah, i'm not disagreeing with you, it just occurs to me that this is wrong since you mentioned $PATH

In any case I was just pointing out one possible way for things to pop through two different MTAs on a system, in a confusing way.

I always set PATH so that /usr/local is ahead of /usr here. That way installed ports always have priority override to what is installed in base. That's just the way I think things should be done.

There are other things that are both in base and in ports and if PATH was for /usr before /usr/local then, say, installing openssh as a port would never be used and only the base version would be used. Just for an example. (I don't ever install the openssh port. I just always use the one in base.)

i'm having fun here with kerberos at the moment because i want to use /usr/bin/kinit to get a ticket to make sure the ticket is compatible with base libkrb5, but i have to /usr/local/bin/kadmin to manage the MIT KDC... (at least this one will be fixed when we get MIT krb in base)

Just for another tidbit on the mailer.conf topic... If /usr/local/etc/mail/mailer.conf exists then it overrides /etc/mail/mailer.conf and of course I set the /usr/local one so that I never need to merge at upgrade time. And then /usr/sbin/sendmail via mailwrapper will call the installed MTA port rather than the sendmail base.

Meaning that probably /etc/mail/mailer.conf is not really actually used if people are using /usr/local/etc/mail/mailer.conf instead. (shrug)

So far I have successfully avoided ever needing to learn much about kerberos. I have never worked in a kerberized environment.

this feels like an obvious question but what's the most straightforward way to chroot to /compat/linux as a non-root uid?

i can't use su(do) because my uid doesn't exist in the chroot... i suppose maybe i could add it

ah, maybe it makes more sense to change compat.linux.emul_path

I haven't tried this on freebsd in /compat but on other systems I can "sudo chroot /srv/chroots/foo su - rwp" or instead of su - use "login -f rwp" or instead use other similar things.

That's assuming that the uid that does exist that I want to run as is there and might be different from the one outside. If I want to run as root then I can run as root the same way of course. But otherwise yes one would need to have some uid in the chroot available to run.

does DRI under Linuxulator just... not work? Mesa is trying to load "amdgpu_dri.so" which doesn't exist anywhere, as far as i can see

lw: normally those would be in /usr/lib/dri

considering people are running steam games under the Linuxulator, I would imagine it's at least available even if it's not installed by default

tm512: /usr/lib/x86_64-linux-gnu/dri in this case. but it's not, and nothing seems to provide it (tried ubuntu 22.04 and 20.04)

as far as i can tell, it should be using radeonsi_dri.so, which does exist

linuxulator-steam-utils seems to utilize the CentOS 7 base, where there's a package linux-c7-dri

maybe i'll try centos instead

also MESA_LOADER_DRIVER_OVERRIDE will explicitly set the DRI driver to use. at least on Linux at one point I remember having to use that to stop it from trying to use iris which was causing me some desktop-breaking issues

32bit going away isn't exactly shocking.

32bit kernels, I guess I should say; lib32 will probably not go anywhere, if I understand the announcement correctly.

lw: rwp: AmyMalik: I'm using sendmail, like on 12-STABLE. If I do 'doas mail root' then it has the correct From:.

Feb 13 00:18:48 xxxx sendmail[56550]: 41CNImvB056550: from=polkitd, size=9261, class=0, nrcpts=1, msgid=<202402122318.41CNImvB056550@xxx>, relay=root@localhost

This is what I get in the maillog.

The strangest thing is that it changed from polkitd to _sndio back to polkitd :D

Maybe it's a problem with periodic, not sendmail?

imm_: 'id polkitd' ?

lw: /etc/passwd has not changed during upgrade, should I maybe run mkdb_pw or what's the command.

I have /etc/ in git, no diff on passwd.

uid=565(polkitd) gid=565(polkitd) groups=565(polkitd)

pwd_mkdb -p /etc/master.passwd, but it's unlikely not updating it would cause this

Yes, no change, only removed the # $FreeBSD$ thingy.

I created a hourly periodic that just does echo and exit 1. If I do 'periodic hourly' from root shell, I get a mail from "marko" which is my main user id. But I don't see marko anywhere in the root's env or anywhere.

tm512: gave up on Linuxulator, ran under Wine, works great. except no sound... but sound didn't work under Linuxulator either, apparently working audio is my eternal bane on freebsd

am I missing something with sha256sum here: dpaste.org/myyQj

Title: dpaste/myyQj (Perl)

daemon: yes, you're doing it wrong. sha256sum -c expects file containing lines of the form "<checksum> <filename>", then it verifies the checksum of each file, so you don't specify the filenames themselves on the command line. the manual page is a bit unclear on this

ah I see

if you invoke it as 'sha256' then -c expects its argument to be the hash, so you could use sha256 -c $(cat sha256.txt) file.txt

I went for:

checksum=$(cat "${link}.sha256.txt")

echo "$checksum $link" > "${link}.sha256.txt"

rebuild the checksum filke

but working :) link should probably be 'file' maybe

wait no it can be filename because .sha256.txt is extension

voy4g3r2: have you seen md5(1)? a single manual page for 25 different utilities, with 3 different command-line syntaxes

brrrrr

lw: yes it is ugly

but i am just using my feelings

Hi there, how to extract from tar archive only specific dir content into directory?

nerozero: tar xf file.tar some/directory

doesn't seems to work ...

tar -xf archive.tar.gz dir -C destination/

The error: No such file or directory

assuming 'dir' is the archived path you want to extract, tar xf archive.tar.gz -C destination dir

this is kinda works but it create a directory inside of the "destination"

is there a chance to extract only content of a "dir" without creating "destination/dir" ?

HA!

Found !

--strip-components=1

lw thanks !

lw: I did a lot of things so I can't be sure, but maybe it was stale aliases.db, but the users have not changed so it's strage.

aliases shouldn't affect the sender of a mail, only the destination

lw: Yeah, that was my thinking also, but in my test, if I have root: marko alias, then if I send from root to marko, I receive from marko to marko.

If I remove that alias, then it's from root.

odd. are you using sendmail? i wonder if this is related to the recent sendmail update

I'm using sendmail which was default for local mail for these periodics.

imm_: are you on 13-STABLE? if this only started happening recently, it might be worth asking gshapiro⊙fo

I'm on 13-STABLE, but I upgraded yesterday from 12-STABLE.

I suspect it's something in this upgrade process that was not done correctly

But now I can't replicate this issue with aliases, so disregard my conclusions.

well, maybe post on freebsd-stable@ anyway, it does seem like something is wrong somewhere

fwiw, sendmail update was 6 days ago: cgit.freebsd.org/src/commit/?h=stab…f2cb2dc3ddd6f325e323c281d1463a80ccf but if you upgraded yesterday maybe unrelated. it is a newer version than in 12, though

Title: src - FreeBSD source tree

Thanks for the help, I'll see how it runs the periodics now. If I'm able to narrow the problem, I'll post to the freebsd-stable@

But from hourly testing it seem to work now as expected. I don't understand it.

I shouldn't have rebuilt pwdb/alias.db/everything at once.

upgrading 13.2-RELEASE to 14.0-RELEASE. second stage freebsd-install has been running for like an hour now... dang

freebsd-update install*

yes it is super slow

if you installed src it uses 'install' to put into place every single file

maybe PKGBASE will be a reality one day .. :)

lw: the md5 man page has no .Xr issues and as such "out of scope" would md5 be a contrib package? i see a lot of packages that reference it...

but man.. perl, gnu, bsd options.. lets throw the kitchen sink at the utility.

mage: i hope we can flip the default on 16.0 for PkgBase

the only thing that is missing in freebsd-update is unattended upgrades

in my case I'm using jails for everything and config is in Saltstack, so I don't care about merging changes, etc .. I would like an option to by default installed new files, automatically override stuff, etc

Perhaps pkgbase would get you closer to what you want mage?

Hi. Is /usr/include/execinfo.h part of a library or is it from core FreeBSD? Do I need something special (link to something) to be able to make use of execinfo on FreeBSD?

it's a part of base

it's a part of libexecinfo, see backtrace(3)

Thanks! I'm not an actual FreeBSD user, I'm just testing my program here. Your overly standard compiler has already uncovered some errors in my code.

meator: that's an often overlooked feature of platform diversity :-)

try musl as well

hear, hear

My Linux distro supports musl, so that is easy to test. But I had to set up a VM to run FreeBSD. It was pretty painful actually, had to switch my hypervisor because libvirt doesn't work, but it's working now.

meator: libvirt didn't work for FreeBSD, or at all on the host?

Cursor movements weren't detected on FreeBSD guest. I kinda needed that.

Hrm. I've never tried a graphical FreeBSD guest inside libvirt. I run any number of console-only guests that way though.

Where could I get more information about libexecinfo?

Title: GitHub - ronchaine/libexecinfo: libexecinfo for `execinfo.h` in musl systems

mason: Thanks! I have fixed my buildsystem. It now tries to look for this library.

so i just finished upgrading from 13.2-RELEASE to 14.0-RELEASE and then i proceeded to upgrade ezjail's basejail

but after this i can no longer "su"

i get "su: pam_start: System error" every time in all jails

hjf: not sure, but can check for the existence of /etc/pam.d/su or /usr/local/etc/pam.d/su

folks with bastille had this issue of no console, and it remains to be solved in an automated fashion, but there is a PR for bastille for one way to solve it, which is a makeshift etcupdate procedure, which would fix the pam thing plus some other stuff

yeah, maybe hjf forgot to run etcupdate / mergemaster (i guess mergemaster is gone)

meator, I am running libvirt under Debian/Devuan/Ubuntu/Mint/Trisquel and running a FreeBSD guest VM is no problem. By "Cursor movements" I assume you mean arrow keys and those work okay here.

I did not find installing FreeBSD in a VM to be any problem. It was pretty much the same as installing using the Debian netinst image which is pretty much the same type of install interface.

rwp: I was assuming he meant mouse movements, but I could be confused.

I applaud your efforts to improve your code by compiling it on different platforms.

I mean this: pngimg.com/uploads/cursor/cursor_PNG78.png

The mouse works okay in a graphical environment too.

Okay. But the mouse pointer also works okay for me too in libvirt. I do use the X-Y tablet input device.

The mouse moves relative movements +/- direction from the current direction. The result is quite laggy behavior with high latency. Hard to use. But the default when installing is to attach an X-Y tablet device to the guest. The tablet produces absolute coordinate input.

The tablet input is so good that it is really impossible to think other than that one is on the bare metal device. I can play games using it.

I remember I spent at the very least half an hour trying to fix the cursor in libvirt/qemu/virt-manager but without success.

Computers can be the most frustrating things.

What do you mean, can be?

Right. Sorry. Computers *are* the most frustrating things. :-)

s/be\?/?/

The smallest of details can create the biggest of problems.

Did you have to install special packages, enable unusual services or edit config files to make the cursor (not the rectangle one) work rwp?

The funny thing is, the more you know about touching computers, the less simple issues you'll face.

Nope. And for me that is the default on Debian/Devuan without me needing to do anything. I think the default is set based upon the OS being installed based upon the templates used.

meator: moused(8) should be the only thing that needs to be enabled, and that's done by default if you plug in a USB mouse, because of devd(8).

At least for FreeBSD.

And humorously I always *disable* moused because it's just a waste for me.

I always set moused_nondefault_enable="NO" in /etc/rc.conf to keep it from starting at all. I don't want it.

I remember that there is some other (maybe obsolete) service that has been mentioned on some forums I was scavenging while debugging the problem. But even that service didn't help.

As you can tell by what I just said that I would recommend using text based installers. They are just a lot easier to use. Then it is almost nothing more than cursor keys and Enter and that's all that is needed. Can just fly through the installer and get something set up quickly.

I am looking at my VMs now to see exactly what input devices are connected.

Believe me, I am no stranger to the CLI (or TUI, which I have even written myself with ncurses).

I must apologize meator as when I look it looks like the libvirt template for freebsd does NOT include the tablet by default!

I am fishing out to see where these are actually set...

meator, In the meantime I suggest trying this. I would add a tablet input device in the Add Hardware part if you are using virt-manager: proulx.com/tmp/libvirt-tablet.png

Give me a moment and I will walk through it here and verify that I can get moused running that way at least. Since I disable all of that normally.

I want to verify that FreeBSD has the Ev Touch USB Graphics Tablet driver.

By the way, thanks to compiling my code on FreeBSD, I have uncovered that a part of my code doesn't comply to the C++ standard. The non-conformance was so cryptic that several knowledgeable members of #C++-general didn't know about it and both clang++ and g++ produce no warnings (nor errors) when it occurs on Linux even with all warning enabling flags I could think of. I believe that there are

thousands of people that have no idea it is non-standard, and who would blame them. But FreeBSD sure follows it to the letter. Not a warning, but an error!

For those who know C++: std::unordered_map<Key, const Value> (and it probably holds for std::map too) is not to spec.

At least for operator=

Every time I compile my code on another platform I learn something and it makes the code better.

I am going to need to apologize because where I had thought I was using the tablet it turns out that I am only using that on linux guests and not on freebsd guests.

And when trying to enable it here I am finding that things are not just working here.

I can attach the device. And it is there. bsd.to/RN5m/raw

Title: RN5m

I switched to Virtualbox and it's working, so I won't be trying libvirt. It isn't working well, but it's working "enough".

But at least moused is not happy with it. bsd.to/5M0J/raw

Title: 5M0J

So it doesn't work?

Nope. My apologies. I thought it was working. I was fooled.

So even you can't get it working right. It isn't just me.

I haven't given up yet though. It's only not working after one gives up trying.

That's the spirit.

This posting forums.freebsd.org/threads/qemu-kvm…running-x-and-a-working-mouse.82460 tells me that I need the utouch-kmod device and the xf86-input-evdev for X.

Title: QEMU/KVM FreeBSD Guest running X and a working mouse. | The FreeBSD Forums

I can't even use guest additions in Virtualbox because host and guest Virtualbox versions differ by a major version and are incompatible (FreeBSD's is too old) and the Virtualbox guest additions CD has no support for the BSDs.

JFTR but I am running FreeBSD native on bare metal and of course my mouse is working okay here. :-)

I am running Void Linux on bare metal and I can too confirm that both touchpad and mouse work well.

This fixed bug ticket contained useful information bugs.freebsd.org/bugzilla/show_bug.cgi?id=244079

Title: 244079 – QEMU / KVM Q35 USB Tablet (EVTouch) input device not captured by evdev

I now have X running in FreeBSD as a VM guest in libvirt and it seems to be using the tablet device okay. Thinking of removing the regular mouse device as a test in order to verify.

What I found was that I needed "pkg install utouch-kmod xf86-input-evdev" and then echo 'utouch_load="YES"' >> /boot/loader.conf in order to load the utouch driver from ports. And then X is working.

I still do not have moused working on the vt console though.

And this would not help with the install since ports kernel modules are not available at installation time.

I would still recommend the text mode installer using the cursor keys. For all of the operating systems. But that's me of course.

Note that the touchpad and the tablet are two different types of input devices. The touchpad is like the mouse as it uses relative input coordinates.

X-Y tablet input is en.wikipedia.org/wiki/Graphics_tablet and traditionally used with professional drawing systems.

Title: Graphics tablet - Wikipedia

I verified that I was using X-Y tablet by removing the mouse from the libvirt configuration. X is still working okay.

I still can't get moused to work with it okay though. It's not happy.

I am going to declare victory that the X-Y tablet does work okay for X in libvirt for a FreeBSD guest and stop messing further. Then go work on other things.

But this is not useful to you if you want to install using a graphical installer as it requires the utouch-kmod port which is not available until after install.

Is there a gui for the PF firewall? I know about pfsense, but this isn't a dedicated firewall box

poudriere keeps deleting some packages because of "new dependency": 0x0.st/HdEg.txt

last time it was because of a version use flag in the package (qt6, i dont remember exactly what was wrong, some hardcoding mismatch or seomthing), what would be the best way to try figure out whats the problem here (sort of debug makefiles in my ports)