06:04:38 i forgot, what are good ways to change the terminals (plain/pure/non-X) to black on white text, temporarily, and also saving that setting? 08:22:54 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=271388 08:22:57 Title: 271388 – irc/soju: update to v0.6.1 08:23:09 is ashish here ? 08:58:07 RhodiumToad, Thank you; good to know/be reminded that "pkg" knows about "flavor" & package+flavor name depends per port(🤡) 09:02:43 the hard part would be, how could pkg know or guess what flavor is required if you specify only a package origin (i.e. cat/port rather than a packagename) 09:03:25 for some flavor types, like x11/nox11 variants of packages, are very different in functionality 09:06:16 pkg-query(8) does not mention if it works on (un)installed packages ... wait per "EXAMPLES" section, only installed ones 09:06:17 RhodiumToad: do we have a "default" flavour? 09:06:39 parv: pkg rquery queries a repository 09:06:57 pkg query queries the local installed pkg db 09:07:11 meena: every origin has a default flavor, yes 09:07:25 RhodiumToad, I read that; thought was limited to "repository"-related data (URL, ABI, etc). Appreciate the correction 09:07:53 rquery can only query a subset of the package data, i.e. only the parts that are entered into the repository metadata 09:08:12 so you can't get things like (iirc) file manifests or so on 09:08:22 but annotations are in the metadata, so you can see those 09:16:41 Does not find -x11 version: pkg rquery '%n %Av %At' -x vim # Try with s/vim/vim-x11; "-x" is not effective 09:18:17 Now OTOH: pkg search -x vim # 👍🏽 09:39:50 parv: I get the same amount of stuff for pkg search vim and pkg search -x vim (23) 09:42:22 meena, Use of "-x" is now a habit after non-x search not finding things most of the time; also now would need to only tweak the search term & not have to worry about lack of "-x" option 09:47:04 I also thought pkg-rquery would find "vim-x11" with "-x" with term of "vim" but did not 09:47:41 -x seems to be behaving pretty weirdly 09:47:53 pkg rquery -I -x 'vim' finds a lot of stuff 09:48:20 oh I see 09:48:32 you're infected with a GNUism 09:48:47 has to be pkg rquery -x '%n Av %At' vim 09:49:05 pkg rquery -x '%n %Av %At' vim 09:49:42 (remember, all options come before all arguments) 09:49:45 RhodiumToad, Right diagnosis doctor. 09:50:34 Sorry meena, RhodiumToad to bother with mistyped command 09:55:32 .oO( Oh man /me is laughing at own error ) 13:00:04 How is the freebsd bluetooth audio support between: shit and non existent? :D 13:02:35 last I heard, there was a virtual_oss bluetooth audio connector, but I never tried it 13:25:05 ok I guess if the normal bluetooth is plane zero I shouldnt even dare to look at the RPI 3-4 bluetooth support with FBSD 13:26:12 pretty sure bluetooth is not supported on rpi3-4 on fbsd 13:26:36 unless possibly via an external usb dongle? 13:27:03 note that the internal audio isn't supported on rpi 3/4 either 13:30:14 Other BSDs are probably even worse, FBSD usually number 1 in new hw support compared to the other two. 13:39:45 Hi, I have gotten 4 checksum errors on all 4 physical disks in a raidz2 volume. https://pastebin.com/y9S7WMeu 13:39:47 Title: $ sudo zpool status -v - Pastebin.com 13:40:20 smartmontools do not show any wear or error information for the disks 13:40:32 It seems like a memmory or controller error. 13:40:48 can happen 13:40:54 Question is how can I remove the "files" that are listed in the output? 13:43:25 Based on the output in https://pastebin.com/y9S7WMeu 13:43:27 Title: $ sudo zpool status -v - Pastebin.com 13:43:34 Is there anything that I can or should do? 13:46:11 * RhodiumToad not enough of a zfs expert to answer that one 13:46:25 hang around, someone else may know 13:46:54 looks like metadata 13:54:12 https://pastebin.com/Xyn0cj4T <-- does anyone know which periodic script this is ? 13:54:13 Title: cat /etc/periodic.confdaily_status_security_chksetuid_fs="ufs,zfs"daily_st - Pastebin.com 13:59:00 in what version? 13:59:04 13.2 13:59:25 I killed them all yesterday, now it's back on, most likely because it runs on /backups which has millions of files 13:59:58 greping for find just shows: / /ssd_bkp /zroot /usr/obj /usr/ports /usr/home /backups /backups/veeam67 /backups/dd /backups/test /backups/mfs /backups/mail /backups/logs /ssd_bkp/mfs /dev/null (find) 14:00:08 there's no script that respects those settings, where did you get them from? 14:00:57 the chksetuid script in 13.2 processes all zfs and ufs filesystems that have neither noexec nor nosuid set 14:01:08 the trick is to set nosuid on all data filesystems 14:02:50 I copied them from another 13.2 server, hmm, maybe I am going cuckoo 14:03:52 /etc/periodic/security/100.chksetuid is the script in question 14:04:27 the only option it recognizes is one to disable it completely 14:04:42 so for zfs I just setuid=off on the zfs pool ? 14:05:07 you do whatever it takes to make it show up as "nosuid" in the output of mount 14:05:16 I believe it's a dataset property 14:05:27 (rather than a pool one) 14:06:41 backups on /backups (zfs, local, nosuid, nfsv4acls) 14:06:46 cool 16:08:43 I heard you like backups so we put backups on /backups. 16:12:11 indeed! 16:12:23 would setting nosuid on the dataset change the snapshots somehow ? 16:12:48 I tried doing a zfs send/receive and now it errors out with: cannot receive incremental stream: destination backups/veeam has been modified 17:52:27 is there a way i could get the original sshd_config thats supposed to shop with my ssh version? 17:52:48 I replaced it, and that broke sftp, because I may have used a config from a different system :s 17:54:45 ah found the problem 17:55:18 it was from a bsd where I installed another openssh in /usr/local... so the sftp subsystem pointed to /usr/local/libexec instead of /usr/libexec 18:01:35 if you know your freebsd version you can get the sshd_config from the original sources easily enough. 18:02:00 you can get any original config file by downloading and extracting base.txz for that version 18:02:23 yeah, if you don't mind downloading a large file 18:04:06 https://github.com/freebsd/freebsd-src/blob/releng/13.2/crypto/openssh/sshd_config 18:04:07 Title: freebsd-src/sshd_config at releng/13.2 · freebsd/freebsd-src · GitHub 18:11:06 <3 20:32:58 I have a few hosts running 13.2 that are periodically dumping this message to the console: Deprecated code (to be removed in FreeBSD 14): Asymmetric crypto features via /dev/crypto 20:33:12 But they don't mention what the calling program or jail is. How to track this down? 20:38:59 spork_css: aye, that doesn't seem very useful 21:38:11 spork_css: can you use dtrace to see what opens /dev/crypto ? 21:38:38 i have no idea if this is spectacularly explosive on a production system 21:43:36 spork_css: I'm guessing it is either 30e25f930445e1b76d16f3219b627b7b92aa2a42 or ecedef531b0c481f424513004db59c4e8943cf2b 21:43:44 and see https://reviews.freebsd.org/D26810 for more info on the latter 21:43:45 Title: ⚙ D26810 Mark asymmetric cryptography via OCF deprecated for 14.0. 21:44:27 and https://reviews.freebsd.org/D24346 also 21:44:28 Title: ⚙ D24346 Remove support for the algorithms deprecated in r348876. 21:45:14 spork_css: so basically you need to figure out what's trying algos like 3DES, blowfish, etc. 21:45:35 probably something that also wants openssl < 1.1.0 21:47:52 I have some very old jails, including one on 8.4 (not on the internet)... might have to move that to bhyve if that's it. 23:38:19 i forgot, what are good ways to change the terminals (plain/pure/non-X) to black on white text, temporarily, and also saving that setting?