00:00:16 <alepzi> new files
00:00:42 <V_PauAmma_V> What creates them?
00:01:40 <alepzi> quickwit a search engine that's run by daemon in a rc script
00:01:57 <alepzi> but wait it's the -o option of daemon
00:02:01 <alepzi> so i guess daemon does
00:06:38 <V_PauAmma_V> Quoting from daemon(8), "-o" paragraph: "If the file does not exist, it is created with permissions 0600." daemon(8) can't know what will go into the file, so has to be prudent. If you want the file world-readable, touch it before running daemon so it exists.
00:07:07 <alepzi> i was even reading the man page don't know how i forgot that!!
01:07:44 <crest> does anyone else have problems fetch packages from the official pkgbase repo for 14.0?
01:08:50 <crest> i can fetch from my own (locally compiled) pkgbase repo, but not from the official pkg.freebsd.org mirrors
01:09:08 <crest> pkg update -f -r base works
01:09:33 <crest> but pkg fetch -o /tmp -r base FreeBSD-clibs fails
01:09:57 <crest> it dies with an exit code != 0 but doesn't write any errors to stdout/stderr
01:56:07 <alepzi> does it make sense for a pid file to be +x?
02:10:17 <rwp> No.
06:02:26 <meena> crest: there definitely seems to be an issue on aarch64, not sure about amd64
09:05:55 <crest> meena: are you getting the same behavior on aarch64?
09:06:12 <crest> e.g. pkg install failing with exit status 21 without an error message
10:18:06 <meena> crest: https://gist.github.com/igalic/162ddc534e4141cffdf4dd36b13556b5 this seems bad.
10:18:08 <VimDiesel> Title: gist:162ddc534e4141cffdf4dd36b13556b5 · GitHub
10:23:12 <crest> looks like at least some official pkgbase repo mirros are broken?
10:31:55 <meena> crest: so, this machine is in germany; lemme try my local amd64 vm
10:32:00 <meandrain> I've change mac address of a freebsd machine using ifconfig_vtnet0_alias0 and now I have too lines in ifconfig:     ether and hwaddr. Which one will be broadcasted ?
10:32:16 <meena> never mind,that's already up to p6
10:32:43 <meena> meandrain: it should be the one you set
10:33:06 <meandrain> arp show the ether one ... so it seems to be ok
10:33:47 <crest> meandrain: iirc ether is the active one an and hwaddr is only displayed if ether has be changed to make it posssible to still track the interfaces by their hardwired default mac address
10:34:12 <meandrain> nice
10:35:31 <crest> meena: so you're most likely hitting the frankfurt pkg mirror by default
10:40:48 <meena> crest: if i switch to a different mirror, the error is the same.
10:41:10 <crest> meena: i see the same problem
10:41:15 <meena> so I reckon the issue is with (14:)FreeBSD:aarch64
10:42:03 <crest> not just aarch64
10:42:38 <crest> i'm unable to pkg update -r base with the example base.conf from the wiki
10:44:22 <meena> let's start a thread on pkgbase@?
10:45:49 <crest> sure
10:46:29 <meena> you said you're getting the same issue? on amd64?
10:47:01 <meena> I update my CURRENT dev VM every other day, and it doesn't have that issue
10:47:19 <crest> also https://lists.freebsd.org/archives/freebsd-pkgbase/2024-April/000398.html
10:47:20 <VimDiesel> Title: Re: FreeBSD kernel version 0
10:49:49 <crest> if bapt@ says this is the one and only correct fix and it won't be fixed by restoring the old pkg behaviour that means it will take an errata release to get the fix into releng/14.0
11:15:39 <meena> crest: agreed.
12:02:49 <polarian> I can't seem to get .login_conf locale working
12:03:10 <polarian> I set the charset to UTF-8 and set the locale to en_GB.UTF-8 and nothing...
12:03:14 <polarian> I have generated the db too
12:03:38 <polarian> I run locale as my user, and I still get C.UTF-8
12:03:47 <polarian> I have restarted my laptop and also relogged in
12:03:47 <V_PauAmma_V> Did ypu log out and back in?
12:03:50 <polarian> yes
12:03:51 <V_PauAmma_V> OK
12:07:20 <V_PauAmma_V> Tbat looks like a more-coffee-than-I-have-in-my-bloodstream problem.
12:15:09 <polarian> damn... anyone else got any ideas on what I could try?
12:17:52 <voy4g3r2> i may be late to this whole conversation (true statement, very little coffee) is locale in userland apps NOT taking over from your .login_conf?
12:26:50 <polarian> voy4g3r2: I set them in .login_conf, then generated the db, then rebooted and relogged in, nothing... running locale I can still see C.UTF-8 is the locale
12:30:48 <voy4g3r2> does locale -a show en_GB? or just C?
12:31:25 <polarian> voy4g3r2: both of them are elements of them yes
12:31:36 <polarian> if I grep the list, they will both appear
12:31:44 <polarian> (with en_GB having different charsets too)
12:33:50 <voy4g3r2> could you put your locale output in dpaste.org please?
12:36:54 <polarian> voy4g3r2: https://dpaste.org/ouinx
12:36:55 <VimDiesel> Title: dpaste/ouinx (Python)
12:38:48 <voy4g3r2> you said you updated the .login_conf, is that located in your $HOME dir and once you do that you rebuild the database with: cap_mkdb
12:43:10 <voy4g3r2> cap_mkdb $HOME/.login_conf (whereever you have it)
12:43:28 <voy4g3r2> SHOULD set the en_GB for that user and leave the system wide configuration intact
12:59:00 <polarian> voy4g3r2: yes I did that
12:59:06 <polarian> want me to dpaste that?
12:59:56 <voy4g3r2> sure
13:02:23 <meandrain> I've moved a FreeBSD 10.x running machine into bhyve, but now I get this:     https://pastebin.mozilla.org/rp8Ofua8        Any idea how to find the problem ?
13:02:24 <VimDiesel> Title: Mozilla Community Pastebin/rp8Ofua8 (JavaScript)
13:11:46 <voy4g3r2> meandrain: you move a FreeBSD 10.x install to a newer FreeBSD host? upon moving this machine to a bhyve instance, you are receiving the above message?
13:12:01 <meandrain> yes
13:12:11 <meandrain> the host is 14.0
13:12:22 <mrtnt> Let's say, that I send an unrelated TCP packet with RST or ACK flag set to a FreeBSD server. Such packet will get dropped. Is there a counter for example under /proc or visible with for example netstat, which counts such dropped packets?
13:13:50 <voy4g3r2> meandrain: how is your bhyve? do you have debug=on for the image? does that give more details for you?
13:14:19 <meandrain> no, I will do that
13:17:23 <meandrain> I don't know how to enable debug in bhyve
13:17:42 <voy4g3r2> find your .conf file for the bhyve instance and add an entry like this...
13:18:43 <voy4g3r2> https://dpaste.org/ypdZy
13:18:44 <VimDiesel> Title: dpaste/ypdZy (Bash)
13:19:11 <voy4g3r2> this is a configuration for a -CURRENT bhyve instance but the focus should be the last line
13:19:15 <meandrain> this is my bhyve start script:   https://pastebin.mozilla.org/nTtecdee
13:19:16 <VimDiesel> Title: Mozilla Community Pastebin/nTtecdee (JavaScript)
13:20:21 <voy4g3r2> oh crap, i use vm-script sorry
13:20:32 <voy4g3r2> so my option won't work, i forgot about that
13:21:02 <meandrain> my issue might be the bhyveload line ... the -d part
13:21:15 <meandrain> because I am not using zfs
13:21:34 <meandrain> well I am using zfs zvol for drive
13:22:57 <voy4g3r2> i am looking through man bhyve_config
13:23:05 <voy4g3r2> there is a way to link the gdb to the bhyve image
13:23:12 <meena> crest: okay, i *am* seeing the issue on amd64, too
13:24:43 <debdrup> mrtnt: blackhole(4) has a couple MIBs for sysctl(8) that let you tweak exactly how the blackholing works, but I don't believe there's a counter as such. However, FreeBSD will generate syslog messages if it spikes above 200, then limit it to 200. To find out the source, you'll have to use tcpdump or an IDS/IPS - the latter of which can be achieved by setting up a monitoring port in ipfw using the tee
13:24:49 <debdrup> rule, that you can then probabilistically filter using dummynet.
13:24:54 <meena> crest: https://gist.github.com/igalic/b566c56b251486576ea7b36b3bc230ee
13:24:55 <VimDiesel> Title: gist:b566c56b251486576ea7b36b3bc230ee · GitHub
13:25:20 <crest> meena: which pkg version are you running?
13:25:22 <crest> 1.21.2?
13:25:36 <debdrup> mrtnt: siftr(4) might be worth investigating, though.
13:25:43 <meena> crest: 1.21.2, which just updated
13:26:02 <meena> crest: see, i usually start my PkgBase upgrades with: pkg upgrade -r FreeBSD pkg
13:26:17 <crest> 1.21.2 was committed on 2024-04-23 to ports
13:26:39 <polarian> voy4g3r2: https://dpaste.org/dHsCN
13:26:40 <VimDiesel> Title: dpaste/dHsCN (Python)
13:26:54 <debdrup> siftr(4) is quite interesting, and I wish more people knew about it.
13:26:57 <crest> but i don't know how fast (or slow) the arm64 builders are
13:27:01 <polarian> ohhh the indexing is wrong
13:27:11 <polarian> neovim isn't displaying it though
13:29:30 <meena> crest: would be nice to see a comparision
13:29:43 <crest> between what?
13:29:54 <ridcully> polarian: isn't there the `lang=` missing?
13:30:08 <polarian> ridcully: hehe
13:30:10 <polarian> yes...
13:30:16 <polarian> thanks for pointing it out
13:32:34 <meena> crest: like, where is the build-queue between the different arch's builders.
13:32:55 <voy4g3r2> meandrain: i would get the gdb options going for your bhyve, unfortunately i do not know EXACT syntax (man bhyve_config) and see if it gives yuou more details.
13:33:15 <meandrain> yea, I'll try to catch a kernel dump
13:33:24 <meandrain> voy4g3r2: thank you!
13:34:33 <mrtnt> debdrup: thanks, I'll check the siftr(4)
13:59:08 <meandrain> voy4g3r2: I solved the problem, I kind of had a feeling that I've messed up with rsync of older files over newer os. So I delete everything new from the partition and rsync older machine to a blank partition, the restored boot. And now I can mount the root in bhyve
13:59:20 <voy4g3r2> nice!
13:59:39 <voy4g3r2> if you have the data on a zfs , i have found great success with zfs send and zfs recv
13:59:49 <voy4g3r2> it is "quicker" than rsync .. but awesome
14:34:18 <voy4g3r2> polarian: everything good from your side?
14:34:34 <voy4g3r2> i got a slew of meetings coming up and will be going dark
14:50:04 <polarian> voy4g3r2: yup
14:50:06 <polarian> it works now
14:50:17 <polarian> apart from claws-mail not detecting the locale :/
14:50:31 <polarian> its still trying to load C dictionary for hunspell (which I dont have)
15:19:46 <voy4g3r2> polarian: awesome, the hunspell may or may not be related but progress is always good
15:29:45 <last1> I hotswap removed and re-inserted a disk in my zfs pool, now it shows as removed
15:30:04 <last1>  diskid/DISK-PHYF117400FZ1P9DGN  REMOVED      0     0     0
15:30:09 <last1> its name used to be da56
15:30:33 <last1> I see in the logs that da56 was properly seen by FreeBSD
15:30:49 <VVD> try zpool replace
15:30:54 <last1> and if I do zfs replace -f diskid/DISK-PHYF117400FZ1P9DGN da56
15:31:15 <last1> it errors out with: /dev/da56 is part of active pool 'ssd_bkp'
15:31:27 <last1> err
15:31:33 <last1> zfs replace -f ssd_bkp ..
15:31:38 <VVD> zpool status
15:32:20 <last1> https://bsd.to/krpD
15:32:21 <VVD> probably u need -f or clear disk manually (with dd for example)
15:32:22 <VimDiesel> Title: dpaste/krpD (Plain Text)
15:32:44 <VVD> without formatting…
15:33:30 <last1> I did use -f
15:34:25 <last1> I haven't written to the zpool since I removed/inserted the drive
15:34:35 <last1> I really need to wipe it clean before trying again ?
15:41:43 <VVD> last1, try: zpool attach ssd_bkp da55 da56
15:43:16 <VVD> maybe add -f
15:43:40 <VVD> I mean: zpool attach -f
15:44:31 <last1> yeah, that's what I ended up doing
15:44:41 <last1> attach, have to resilver, etc
15:44:46 <last1> not ideal :|
15:46:26 <VVD> ye
15:46:38 <VVD> and then detach diskid/DISK-PHYF117400FZ1P9DGN
17:52:41 <crest> meena: did you catch the discussion on the pkgbase list about the changes in pkg 1.21?
18:34:46 <meena> crest: nah, i was staring at broken pytest output all day
18:39:10 <Devil_Kin> f/window close 14
18:39:20 <Devil_Kin> ugh, sorry
19:28:37 <bastelfreak> autojoin add
19:30:53 <bastelfreak> autojoin add --run
19:47:26 <alepzi> i got a pf block out going on. any way i can sniff what protocol it is and stuff about the connection attempt?
20:13:13 <V_PauAmma_V> See pflogd(8).
20:24:32 <markmcb> is there a preview of release notes (or something to that effect) for 14.1 anywhere?
20:27:34 <V_PauAmma_V> Not yet, that I've seen.
20:28:32 <alepzi> how can i say where fetch should dl a file to?
20:29:18 <alepzi> -o then absolute path?
20:30:02 <V_PauAmma_V> So the manual page says.
20:36:35 <alepzi> hm didn't work
20:37:06 <alepzi> jexec -l testjail fetch -a -o /tmp/file.zip https://...
20:37:24 <alepzi> running that in a scripted bsdinstall fwiw
20:39:48 <alepzi> wait nvm
20:46:18 <alepzi> ya it did work my bad
21:17:18 <Steeve> I'm coming from mostly GNU/Linux experience. For elevating privileges, is it reasonable to install the sudo package and allow members of "wheel" group to elevate? Or is there are reason to only $ su - into root and do things therein?
21:20:28 <V_PauAmma_V> I use sudo and wheel group membership as you mentioned. Others prefer doas instead. I would say both are reasonable approaches.
21:21:09 <Steeve> Thanks V_PauAmma_V
21:21:53 <tsoome> only embers of wheel group can su to root, so the direct difference is about if you know root password or not.
21:22:02 <tsoome> s/embers/members/
21:22:58 <Steeve> Thank you, I was curious if that pattern was a "no no" or somehow not appropriate to FreeBSD
21:23:56 <Steeve> For managing packages, if I do # pkg update; pkg upgrade,   as well as  # freebsd-update fetch and # freebsd-update install ,   does that bring my machine fully up to current?
21:24:46 <Steeve> managing updates***
21:26:06 <Steeve> Sorry I guess I shouldn't say "current" since I understand that to be a different thing in this context. I just want to know how to patch a machine so it is fully up to date with regard to security patches to the system, any libraries, packages, etc
21:26:17 <Steeve> This would be a 14.0 install
21:27:19 <TommyC> `freebsd-update fetch install' is for the base freebsd system, similar to RHEL's `dnf update' without any additional repos enabled/installed
21:27:45 <TommyC> the pkg update upgrade commands you mentioned are for pre-built packages, yes
21:28:07 <V_PauAmma_V> What "pkg upgrade" gets you to depend on whether you're using quarterly packages or latest packages. (Quarterly is the default, but sometimes security fixes don't make it to it until the next quarter.)
21:28:23 <V_PauAmma_V> s/depend/depends/
21:28:42 <Steeve> Thank you both
21:29:37 <V_PauAmma_V> See https://wiki.freebsd.org/Ports/QuarterlyBranch.
21:32:16 <Steeve> Thank you. Regarding that point about security fixes not making it into the current quarter, would best practice be to target "latest", say in the case of having something edge-facing... a web server for instance?
21:32:50 <Steeve> Like if I were deploying a public-facing nginx instance and want to keep it as secure as possible with regard to any library updates
21:34:03 <TommyC> Steeve: in my opinion, that's not a simple yes/no question
21:35:35 <TommyC> but if you believe the latest is the safest, then yeah you'd probably want the latest possible updates
21:38:11 <Steeve> Understood, thank you
21:40:12 <V_PauAmma_V> Problem with "latest" is the constant churn, which can increase your workload if you need (or want) to check each update for breaking changes, which sometimes happen, depending on upstream's stance on backward compatibility.
21:41:06 <Steeve> Yes makes sense
21:41:27 <Steeve> Thank you both, appreciate the input
23:04:49 <lw> V_PauAmma_V: are missing security updates in quarterly really a thing then?  i've always been a bit suspicious about running it but didn't have any specific examples
23:06:20 <lw> markmcb: https://www.freebsd.org/releases/14.1R/relnotes/ - but there's nothing there
23:06:21 <VimDiesel> Title: FreeBSD 14.1-RELEASE Release Notes | The FreeBSD Project
23:07:23 <lw> the releng branch hasn't even been created yet, relnotes can't really happen until then someone people are still pushing new changes to stable/14
23:12:47 <V_PauAmma_V> lw, from my own experience of late 2019, soon after switching from PC-BSD to FreeBSD, there was a security update to sudo that didn't make it to quarterly. That's when I switched to latest. Since then, I've occasionally seen people complain about relatively few security updates being applied to quarterly - whether because maintainers don't request them, committers don't apply them, or both, I can't
23:12:53 <V_PauAmma_V> say.
23:43:41 <markmcb> lw: thanks. i recall prior to 14.0 there was a non freebsd site that had lots of detailed notes on what was coming. seemed fairly informal, but it was insightful.
23:53:41 <V_PauAmma_V> Was that Phoronix by any chance?
23:56:39 <TommyC> to be fair, everything on that site looks informal
23:57:42 <lw> 'informal' is certainly one way to describe it
23:58:11 <TommyC> I think the harsher words I want to use aren't permitted in this channel. "be civilized" being in the /topic and all :)
23:58:59 <alepzi> failed to chown ... bad file descriptor <- what can cause that over and over in a jail during pkg install ...?