Heya. I'm trying to make thin jail in 14-RELEASE the same way I've made them in previous versions, but after I make the jail the `pkg` command gets SSL error when it tries to bootstrap. Did I forget something?

The first in the long series of errors is this; 00202166573D0000:error:0A000086:SSL routines:tls_post_process_server_certificate:certificate verify failed:/usr/src/crypto/openssl/ssl/statem/statem_clnt.c:1890:Certificate verification failed for /C=US/O=Let's Encrypt/CN=R3

Sorry, *one* of the first.

fuck

gh00p: what's /etc/ssl/certs look like, in the jail

rtprio: almost identical to the host (where pkg works). There's one more file on the host, 'cd8c0d63.1'.

Copying that file to the jail's certs dir didn't help.

I get similar errors when I use `fetch` to hit other https sites.

It happens with any HTTPS target, it seems. I get it with `fetch` too. termbin.com/bwn0

Oh, I just said that. I seem to be monopolizing the conversation.

they are symlinks, you know

and that termbin looks like they're broken symlinks

Ah, that's it! The thin jail has it certs in /s/etc/ssl/certs, so '../../..` resolves incorrecly. Why has this never happened before?

because /s/usr/share/certs/trusted doesn't exist ?

is the jail name 's'?

no, `/s/` is the mountpoint of the jail skeleton, from within the jail. Everything outside /s is mounted read-only, /var is a symlink to s/var, /usr/local is a symlink to /s/usr-local, etc.

And /usr/share/verts/trusted exists, but is not visible as `../../../usr...` from /s/etc/ssl/certs. I need one more `../`.

check out /usr/src/usr.sbin/certctl/certctl.sh might fix it for you

Looks promising. I'll need to deal with my readonly filesystem, but maybe rehashing updates the symlinks

Thanks for the tip.

I'll update them manually if I have to, but I'd much rather add this to my jail provisioning scripts.

Solved with certctl! Thanks very much!

👍

mornings y'all

hey antranigv :)

Hello, all. Upon wake-up from suspend, my laptop was optining the "Display" application. I found a fix: <forums.freebsd.org/threads/90827/#post-627318>: reset the XF86Display property from the "Keyboard shortcuts" section of Xfce settings. That settings was bound to any keyboard combination, so why was it firing? Nor is it an Xfce default, but FreeBSD-specific. Does anybody have the same symptom when your computer waskes up after suspend

(zzz(8))?

^ Reset means restore to default, and in my keys it caused that property to disappear from the settings, so that reset == remove.

Hello everybody , when I have freeBSD 14.0 RELEASE , myvirtualbox run nice but I have upgrade 14.1 RELEASE , virtualbox don't run , I have error Kernel driver not installed (rc=-1908), I check kenel driver and they are loaded, can you help me please ?

how did you upgrade?

rtprio: freebsd-update -r 14.1-RELEASE upgrade

you need to update virtualbox too

rtprio: I will try,

rtprio: I upgrade virtualbox but I have the same trouble

and restarted the system?

rtprio: I have not reboot

I will reboot

great

see you soon

rtprio: Thanks

rtprio: I reboot but I have same trouble

dwho: You need to rebuild and reinstall /usr/ports/emulators/virtualbox-ose-kmod

oh, thanks vkarlsen

dwho: The pkg for it is built for the 14.0 kernel, and won't work with 14.1

vkarlsen: Thank you very much

vkarlsen: I use pkg and I 'm not use ports

dwho: I figured. But you will need virtualbox-ose-kmod to be built for your kernel, so for that you will need to build it from ports. You'll also need to have the kernel source in /usr/src

vkarlsen: thanks

I could give you my pkg if you really get stuck, but you shouldn't install pkgs from strangers, especially not kernel modules

vkarlsen: No thanks , I will make the ports , but it's kind of you

I'm trying to write an rc script for a python tool I made. This is what I've got so far: pastebin.com/zGWAcksK

it starts my code on system startup, I can stop/start in manually, "status" works, but it seems it doesn't properly stop it on system shutdown - at least my "got sigterm, shutting down" doesn't appear in /var/log/messages during shutdown although a manual stop of the service makes that line appear

Grabunhold_, have you tried implementing your own stop command and log its execution? Or at least log the invocations of your rc.d script together with $1?

ant-x: not so far

ant-x: i also thought that maybe the logger was gone already when my script finally got stopped because i'm missing a dependency or something?

My experience is so low that I log whatever stuff I am trying to use/debug...

could that be a thing?

By loggin I mean the simplest thing possible: direct output to a file.,

ant-x: gimme a sec

adding debug logging

Yes -- the stone-age method.

at least we can still bring out the axe, hehe

The problem with debug loggin is you had better remove it after use~!

the first and foremost problem is that every test takes ages because i have to reboot this stupid server that i'm testing on

and the firmware takes ages

okay, I added this: if [ "$1" = "stop" ]; then echo "$(date): Received stop command" >> /var/log/debug_stop; fi

In that case, be very liberal with your debug logging.

when running "service anlasser stop", I get the proper line in /var/log/debug_stop

Better and safer to log every command received by your service.

however, when rebooting I don't

so it seems that the rc script isn't even invoked with the "stop" argument during shutdown

Grabunhold_, I got it: you neglected to add the `shutdown' keyword.

ant-x: huh? check pastebin.com/zGWAcksK again, line 5

or is that wrong somehow?

Ough, so it /is/ there all right.

i have removed the "python" keyword, i'm not even sure that I need it. is there a list of keywords with explanations somewhere?

Grabunhold_, see: "Operation of rc.shutdown" in <man.freebsd.org/cgi/man.cgi?query=rc.shutdown> . Does it mean the actual command is `faststop'?

For an overview of stanard keywords, see: <man.freebsd.org/cgi/man.cgi?query=rcorder> .

hmm, why did i even limit the logging. i have changed the script to simply log all arguments, not only "stop"

let's see try the reboot again

should have listened and been more liberal with logging like you said!

See the note about `faststop' at the end of section 7 here: <docs.freebsd.org/en/articles/rc-scripting/#rcng-hookup>

Grabunhold_, At least in debug logging, liberalism is a good thing.

okay, i got "faststart" during boot but no "stop" or "faststop" during shutdown...

Try calling `rcorder -k shutdown' and see if it detects your script.

next reboot, next "faststart", no "stop" or "faststop".

"rcorder -k shutdown /usr/local/etc/rc.d/*" does indeed list /usr/local/etc/rc.d/anlasser

Then I am at a loss. Have you tried placing your script in /etc/rc.d instead?

not so far. might try that next. for the record: manually invoking "service faststop anlasser" works and correctly logs into the debug file

Does you script really run a deamon process with pid?

it runs via DAEMON(3)

so it doesn't fork into the background itself

but the script does indeed keep running, needs a proper shutdown and that shutdown does work properly when manually invoked via "service anlasser stop" or "/usr/local/etc/rc.d/anlasser stop"

Are you logging as early as possible, that is before `. /etc/rc.subr` ?

no, after that. but it does work for all my manual invocations so far... i will move it above that line

It is best to do it before, lest you miss a case, however improbably, that rc.subr terminates .

last experiment before i got to got, unfortunately. many thanks for your help and time, it's very much appreciated

reboot is running...

Have you added the early undonditional logging?

yep

If you solve this mystery, please let me know (using memoserv if I am not online) -- I have a learner's interest in it.

nope, "faststart" only

Duh...

ant-x: i will try to remember that :) will share the source for the python stuff in the coming days, too. it's a bhyve manager

Sounds like a stupid error, or a problem with DAEMON(3)...

Thanks.

i suspect you don't have all the bits in your rc script

rtprio: and I have no idea what bits that may be

lw, ping

Grabunhold_, looking at some other rc.d scripts, I wonder is the DAEMON keyword might help...

^ I mean REQUIRE: DAEMON

ant-x: as in line 4 here? pastebin.com/zGWAcksK

Yes.

so i've already done that, or am i misunderstanding what you mean?

exit

Grabunhold_, yes, you have.

Guys, I accidentally destroyed my /usr/local/etc/rc.d/dbus . Where can I find a copy?

I'm gonna sleep a whole, cya guys tomorrow! Thanks for all the suggestions and help

Good night, let the solution come to you in sleep!

ant-x: If you are still searching, it is in the ports tree

souji, I was trying to extract the .pkg file...

ant-x: is also a way to do it... I guess

ant-x, First locate the package containing that file. "pkg which /usr/local/etc/rc.d/dbus" which is unsurprisingly /usr/local/etc/rc.d/dbus was installed by package dbus-1.14.10_5,1

Then install dbus again: pkg install -f dbus

souji, Thank you, you saved me. I just curl'ed the plain version of the page.

rwp, Right, I tried to install it, but it was already installed. I did not try the -f option.

nw

I have read the pkg manual, but did not find a way to extract a .pkg file, only to list its contents.

Since FreeBSD tar uses libarchive it means tar is now even more powerful. Just use tar: tar xvf /var/cache/pkg/dbus-1.14.10_5,1~ec69e040c9.pkg /usr/local/etc/rc.d/dbus

rwp, even though .pkg is not a tar archive?

Really? What does "xzcat /var/cache/pkg/dbus-1.14.10_5,1~ec69e040c9.pkg | file -" say for you?

Using a version that you have available of course.

Ouch, I read it was txz, but that was in an unofficial source.

The 'z' used to be needed to indicate that it was a gzip'd tar file. But that is no longer needed when libarchive is used to identify the compression method dynamically.

Meaning that one no longer needs to include z or J or any of the other specific compressions when reading an existing archive.

The t and x are conflicting though. I don't understand that. Maybe they both work together okay but it used to be either t for table of contents or x for extract the file.

And v gives a long listing like ls -l.

so tvf is table of contents, verbosely like ls -l, file listed as following.

There are some crazy syntax things suitable for a trivia contest that I will avoid overwhelming people with and just say, ignore those for now.

Thank. I am tryng to restore my dbus, and hope it runs now that I have substituded the correct prefix in the dbus.in file for rc.d

Whew. It works now.

Now I must to bed. I will continue rc.d experiments tomorrow. I wanted to make a simle script to run at resume event, because handling it via devd is out of the question, beucase it does not support multiple subscriptions, and alway runs the first mathcing rule.

Do you by any chance use Boot Environments or snapshots? You could then reach into a previous snapshot and retrieve it from there.

Good night!

rwp, no, I am learing the simplest things on the simplest filesystems. Good-night, rwp.

You might look to see if you have a snapshot: ll /.zfs/snapshot/*/usr/local/etc/rc.d/dbus

I would also say if you have any other system then you could copy it from there. But anyway: Good Night!

Grabunhold_: you did read the handbook section on this, yeah?

Is there an option for `date` to output the date in the short format defined for LC_TIME?

what is LC_TIME

phryk: if anything, it would be in `man strftime`

the env var that sets which locale is used for time-specific localization

rtprio: i don't think so. that's for supplying an explicit format string.

%Ex, maybe?

hrm

ah, right – `date +%Ex`, thanks.

well, not certain about that,

doesn't say short or not short but could be the right thing

Let me advocate for "date +%F" instead as that's more standard.

Not the F that is standard but the 2024-07-22 output format.

The format %Y-%m-%d is more standard and portable.