01:00:29 <gh00p> 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?
01:03:08 <gh00p> 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
01:04:24 <gh00p> Sorry, *one* of the first.
01:09:46 <sfox> fuck
01:23:18 <rtprio> gh00p: what's /etc/ssl/certs look like, in the jail
01:32:48 <gh00p> rtprio: almost identical to the host (where pkg works). There's one more file on the host, 'cd8c0d63.1'.
01:33:32 <gh00p> Copying that file to the jail's certs dir didn't help.
01:35:59 <gh00p> I get similar errors when I use `fetch` to hit other https sites.
01:50:50 <gh00p> It happens with any HTTPS target, it seems. I get it with `fetch` too. https://termbin.com/bwn0
01:52:03 <gh00p> Oh, I just said that. I seem to be monopolizing the conversation.
01:56:52 <rtprio> they are symlinks, you know
01:57:03 <rtprio> and that termbin looks like they're broken symlinks
02:02:26 <gh00p> Ah, that's it! The thin jail has it certs in /s/etc/ssl/certs, so '../../..` resolves incorrecly. Why has this never happened before?
02:03:18 <rtprio> because /s/usr/share/certs/trusted doesn't exist ?
02:03:32 <rtprio> is the jail name 's'?
02:08:09 <gh00p> 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.
02:10:32 <gh00p> And /usr/share/verts/trusted exists, but is not visible as `../../../usr...` from /s/etc/ssl/certs. I need one more `../`.
02:13:31 <rtprio> check out /usr/src/usr.sbin/certctl/certctl.sh might fix it for you
02:19:30 <gh00p> Looks promising. I'll need to deal with my readonly filesystem, but maybe rehashing updates the symlinks
02:19:40 <gh00p> Thanks for the tip.
02:20:55 <gh00p> I'll update them manually if I have to, but I'd much rather add this to my jail provisioning scripts.
02:38:35 <gh00p> Solved with certctl! Thanks very much!
02:40:15 <rtprio> 👍
08:25:11 <antranigv> mornings y'all
08:38:21 <Hecate> hey antranigv :)
08:41:22 <ant-y> Hello, all. Upon wake-up from suspend, my laptop was optining the "Display" application. I found a fix: <https://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
08:41:23 <ant-y> (zzz(8))?
08:43:32 <ant-x> ^ Reset means restore to default, and in my keys it caused that property to disappear from the settings, so that reset == remove.
10:59:30 <dwho> 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 ?
11:08:54 <rtprio> how did you upgrade?
11:12:06 <dwho> rtprio: freebsd-update -r 14.1-RELEASE upgrade
11:17:24 <rtprio> you need to update virtualbox too
11:22:19 <dwho> rtprio: I will try,
11:32:14 <dwho> rtprio: I upgrade virtualbox but I have the same trouble
11:34:10 <rtprio> and restarted the system?
11:34:41 <dwho> rtprio: I have not reboot
11:35:08 <dwho> I will reboot
11:35:11 <rtprio> great
11:35:14 <rtprio> see you soon
11:35:25 <dwho> rtprio: Thanks
11:39:53 <dwho> rtprio: I reboot but I have same trouble
11:44:21 <vkarlsen> dwho: You need to rebuild and reinstall /usr/ports/emulators/virtualbox-ose-kmod
11:44:36 <rtprio> oh, thanks vkarlsen
11:44:43 <vkarlsen> dwho: The pkg for it is built for the 14.0 kernel, and won't work with 14.1
11:45:32 <dwho> vkarlsen: Thank you very much
11:46:40 <dwho> vkarlsen: I use pkg and I 'm not use ports
11:48:32 <vkarlsen> 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
11:50:17 <dwho> vkarlsen: thanks
11:53:24 <vkarlsen> I could give you my pkg if you really get stuck, but you shouldn't install pkgs from strangers, especially not kernel modules
12:00:16 <dwho> vkarlsen: No thanks , I will make the ports , but it's kind of you
12:50:47 * ant-x vouches for vkarlsen
14:17:50 <Grabunhold_> I'm trying to write an rc script for a python tool I made. This is what I've got so far: https://pastebin.com/zGWAcksK
14:17:51 <Grabunhold_> 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
14:37:26 <ant-x> 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?
14:37:42 <Grabunhold_> ant-x: not so far
14:38:14 <Grabunhold_> 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?
14:38:17 <ant-x> My experience is so low that I log whatever stuff I am trying to use/debug...
14:38:18 <Grabunhold_> could that be a thing?
14:38:38 <ant-x> By loggin I mean the simplest thing possible: direct output to a file.,
14:42:40 <Grabunhold_> ant-x: gimme a sec
14:42:47 <Grabunhold_> adding debug logging
14:43:00 <ant-x> Yes -- the stone-age method.
14:43:16 <Grabunhold_> at least we can still bring out the axe, hehe
14:43:21 <ant-x> The problem with debug loggin is you had better remove it after use~!
14:44:04 <Grabunhold_> the first and foremost problem is that every test takes ages because i have to reboot this stupid server that i'm testing on
14:44:08 <Grabunhold_> and the firmware takes ages
14:47:35 <Grabunhold_> okay, I added this: if [ "$1" = "stop" ]; then echo "$(date): Received stop command" >> /var/log/debug_stop; fi
14:47:36 <ant-x> In that case, be very liberal with your debug logging.
14:47:58 <Grabunhold_> when running "service anlasser stop", I get the proper line in /var/log/debug_stop
14:48:03 <ant-x> Better and safer to log every command received by your service.
14:48:04 <Grabunhold_> however, when rebooting I don't
14:48:43 <Grabunhold_> so it seems that the rc script isn't even invoked with the "stop" argument during shutdown
14:50:15 <ant-x> Grabunhold_, I got it: you neglected to add the `shutdown' keyword.
14:50:51 <Grabunhold_> ant-x: huh? check https://pastebin.com/zGWAcksK again, line 5
14:50:59 <Grabunhold_> or is that wrong somehow?
14:51:30 <ant-x> Ough, so it /is/ there all right.
14:53:17 <Grabunhold_> i have removed the "python" keyword, i'm not even sure that I need it. is there a list of keywords with explanations somewhere?
14:53:27 <ant-x> Grabunhold_, see: "Operation of	rc.shutdown" in <https://man.freebsd.org/cgi/man.cgi?query=rc.shutdown> . Does it mean the actual command is `faststop'?
14:54:41 <ant-x> For an overview of stanard keywords, see: <https://man.freebsd.org/cgi/man.cgi?query=rcorder> .
14:57:09 <Grabunhold_> hmm, why did i even limit the logging. i have changed the script to simply log all arguments, not only "stop"
14:57:18 <Grabunhold_> let's see try the reboot again
14:58:01 <Grabunhold_> should have listened and been more liberal with logging like you said!
14:58:32 <ant-x> See the note about `faststop' at the end of section 7 here: <https://docs.freebsd.org/en/articles/rc-scripting/#rcng-hookup>
14:59:10 <ant-x> Grabunhold_, At least in debug logging, liberalism is a good thing.
14:59:19 <Grabunhold_> okay, i got "faststart" during boot but no "stop" or "faststop" during shutdown...
15:01:44 <ant-x> Try calling `rcorder -k shutdown' and see if it detects your script.
15:03:13 <Grabunhold_> next reboot, next "faststart", no "stop" or "faststop".
15:03:14 <Grabunhold_> "rcorder -k shutdown /usr/local/etc/rc.d/*" does indeed list /usr/local/etc/rc.d/anlasser
15:04:09 <ant-x> Then I am at a loss. Have you tried placing your script in /etc/rc.d instead?
15:04:55 <Grabunhold_> not so far. might try that next. for the record: manually invoking "service faststop anlasser" works and correctly logs into the debug file
15:05:32 <ant-x> Does you script really run a deamon process with pid?
15:05:56 <Grabunhold_> it runs via DAEMON(3)
15:06:10 <Grabunhold_> so it doesn't fork into the background itself
15:06:59 <Grabunhold_> 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"
15:07:04 <ant-x> Are you logging as early as possible, that is before `. /etc/rc.subr` ?
15:07:35 <Grabunhold_> no, after that. but it does work for all my manual invocations so far... i will move it above that line
15:08:32 <ant-x> It is best to do it before, lest you miss a case, however improbably, that rc.subr terminates .
15:08:55 <Grabunhold_> last experiment before i got to got, unfortunately. many thanks for your help and time, it's very much appreciated
15:09:00 <Grabunhold_> reboot is running...
15:09:37 <ant-x> Have you added the early undonditional logging?
15:10:04 <Grabunhold_> yep
15:11:08 <ant-x> If you solve this mystery, please let me know (using memoserv if I am not online) -- I have a learner's interest in it.
15:11:14 <Grabunhold_> nope, "faststart" only
15:11:26 <ant-x> Duh...
15:11:47 <Grabunhold_> 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
15:11:49 <ant-x> Sounds like a stupid error, or a problem with DAEMON(3)...
15:12:10 <ant-x> Thanks.
17:47:43 <rtprio> i suspect you don't have all the bits in your rc script
20:49:29 <Grabunhold_> rtprio: and I have no idea what bits that may be
21:08:00 <jbo-> lw, ping
21:55:27 <ant-x> Grabunhold_, looking at some other rc.d scripts, I wonder is the DAEMON keyword might help...
21:57:04 <ant-x> ^ I mean REQUIRE: DAEMON
22:01:41 <Grabunhold_> ant-x: as in line 4 here? https://pastebin.com/zGWAcksK
22:04:31 <ant-x> Yes.
22:07:18 <Grabunhold_> so i've already done that, or am i misunderstanding what you mean?
22:10:37 <jauntyd> exit
22:11:41 <ant-x> Grabunhold_, yes, you have.
22:12:32 <ant-x> Guys, I accidentally destroyed my /usr/local/etc/rc.d/dbus . Where can I find a copy?
22:14:00 <Grabunhold_> I'm gonna sleep a whole, cya guys tomorrow! Thanks for all the suggestions and help
22:14:21 <ant-x> Good night, let the solution come to you in sleep!
22:27:44 <souji> ant-x: If you are still searching, it is in the ports tree
22:27:51 <souji> https://cgit.freebsd.org/ports/tree/devel/dbus/files/dbus.in
22:28:05 <ant-x> souji, I was trying to extract the .pkg file...
22:28:56 <souji> ant-x: is also a way to do it... I guess
22:29:01 <rwp> 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
22:29:10 <rwp> Then install dbus again: pkg install -f dbus
22:30:08 <ant-x> souji, Thank you, you saved me. I just curl'ed the plain version of the page.
22:30:30 <ant-x> rwp, Right, I tried to install it, but it was already installed. I did not try the -f option.
22:30:59 <souji> nw
22:31:04 <ant-x> I have read the pkg manual, but did not find a way to extract a .pkg file, only to list its contents.
22:37:25 <rwp> 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
22:38:50 <ant-x> rwp, even though .pkg is not a tar archive?
22:40:14 <rwp> Really?  What does "xzcat /var/cache/pkg/dbus-1.14.10_5,1~ec69e040c9.pkg | file -" say for you?
22:40:29 <rwp> Using a version that you have available of course.
22:41:49 <ant-x> Ouch, I read it was txz, but that was in an unofficial source.
22:42:37 <rwp> 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.
22:43:01 <rwp> Meaning that one no longer needs to include z or J or any of the other specific compressions when reading an existing archive.
22:43:35 <rwp> 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.
22:43:48 <rwp> And v gives a long listing like ls -l.
22:44:05 <rwp> so tvf is table of contents, verbosely like ls -l, file listed as following.
22:45:08 <rwp> 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.
22:47:06 <ant-x> 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
22:47:34 <ant-x> Whew. It works now.
22:48:54 <ant-x> 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.
22:49:02 <rwp> Do you by any chance use Boot Environments or snapshots?  You could then reach into a previous snapshot and retrieve it from there.
22:50:02 <rwp> Good night!
22:50:49 <ant-x> rwp, no, I am learing the simplest things on the simplest filesystems. Good-night, rwp.
22:51:00 <rwp> You might look to see if you have a snapshot: ll /.zfs/snapshot/*/usr/local/etc/rc.d/dbus
22:51:38 <rwp> I would also say if you have any other system then you could copy it from there.  But anyway:  Good Night!
23:09:46 <rtprio> Grabunhold_: you did read the handbook section on this, yeah?
23:45:14 <phryk> Is there an option for `date` to output the date in the short format defined for LC_TIME?
23:53:54 <rtprio> what is LC_TIME
23:54:36 <rtprio> phryk: if anything, it would be in `man strftime`
23:54:51 <phryk> the env var that sets which locale is used for time-specific localization
23:55:11 <phryk> rtprio: i don't think so. that's for supplying an explicit format string.
23:56:47 <rtprio> %Ex, maybe?
23:57:15 <rtprio> hrm
23:58:01 <phryk> ah, right – `date +%Ex`, thanks.
23:58:57 <rtprio> well, not certain about that,
23:59:05 <rtprio> doesn't say short or not short but could be the right thing
23:59:09 <rwp> Let me advocate for "date +%F" instead as that's more standard.
23:59:25 <rwp> Not the F that is standard but the 2024-07-22 output format.
23:59:57 <rwp> The format %Y-%m-%d is more standard and portable.