00:39:05 macpapo: missing kcmp is not a fatal error, it's fixed in current versions of freebsd (at least 15.0) but maybe wasn't backported yet, it shouldn't cause any issues though 01:44:54 hi. i was testing pf/altq, and noticed something strange. i have a very reduced pf.conf that defines different queues for different interfaces, and rules that i think should put traffic for each interface in their own queue. but all traffic seems to end up in the priq for the first interface. any idea whats wrong? here's my pf.conf. https://0x0.st/XgTn.txt 02:41:08 * ober kicks iwlwifi into associating unsuccessfully 02:43:44 ober: your iwlwifi isn't working ? 02:45:40 nope 02:47:45 https://gist.github.com/ober/12bca2760afe785b1de65d80981b402b my rc.conf/wpa_supplicant.conf 03:23:19 reinstalling it, I see it adds fcc rules to iwlwifi in rc.conf which make it work 05:07:30 maybe someone who still remembers X11: https://stackoverflow.com/questions/79035627/what-is-the-meaning-of-cannot-convert-string-to-type-xftfont-and-why-no-labels-t 05:57:25 does anyone use these 15.0 stab week builds? how are they? 07:41:01 jls 07:41:05 whoops 07:45:35 * kfv laughs 08:12:07 don't ever understand, it's bad for your health 08:14:52 ober: so its working ? 13:13:33 Where /etc/ttys defines vtys with getty and a display manager, is there a way to get one of the getty vtys (preferably ttyv0) to the foreground on boot? 16:37:46 /25 16:37:48 sorry 16:51:14 * debdrup wonders what's in window 25. 16:52:07 ober: I've heard that completely disabling powersaving is apparently one of the trick to make it work, so you could try that. 16:53:04 ivy: last week of the month 16:53:38 https://lists.freebsd.org/archives/freebsd-current/2024-September/006432.html 16:54:29 debdrup: the first rule of window 25 club is don't talk about window 25 club 16:54:52 kona: ha! 16:56:41 ivy: Gleb thankfully took my advice and included instructions on how to grab the tags he creates on his own branch, which makes it a lot easier to track and grab without paying attention to a busy mailing list. 16:57:08 * debdrup watches stabweek compile. 17:34:22 Hey 17:35:12 about 10 days ago, I asked for help - how to trace and find what application was "triggering" a binary (executing it). 17:35:48 Got good replies and tips on how to 'investigate' it. 17:35:57 ktrace and kdump? 17:36:50 Want to tell I manage to identify it, using ktrace/fake facade script point to real binary, etc... 17:38:28 the application generating the unwanted command was a network discovery tool, which was executing every 60 seconds. I disable it and now is working accordingly. 17:38:32 many thanks. 17:39:59 I would try dtrace and listen to exec probes 17:48:56 Where in FreeBSD can I find the DNS root servers IP addresses? 17:49:10 It must have them, right? 17:55:16 Very good cybercrypto! Always good to hear success stories. :-) 17:55:35 The way it works is you query some DNS server, say your ISP or Google's famous 8.8.8.8. What they query is anyone's [informed] guess. There's a lot going on. 17:57:21 why would they be needed? the common setup is recursive dns, not iterative dns starting at rootservers, is there even a iterative dns resolver in base? 17:57:26 The root servers list is typically "built" into a DNS server, as in the DNS server package such as bind918 or nsd. 17:57:52 s/nsd/unbound/ 17:58:08 I think any resolver must have a list of root servers. So I'd believe I'd find them somewere in a FreeBSD. 17:58:54 Although unbound usually just works from whatever upstream resolvers provide. 17:59:05 dansa, The root server file is /usr/local/etc/namedb/named.root 17:59:28 To find the IP address of ``hello.to.'', my resolver must get to the name servers of the /to/ TLD. The resolver won't know that until it asks the root servers who is responsible for the /to/ TLD. 17:59:58 rwp: I don't have that file. Must I install some package? 18:00:02 If you've installed bind918 or some other bind package, that one comes with root servers listed in /usr/local/etc/namedb/named.root 18:00:08 pkg install bind918 18:00:16 wouldn't a iterative resolver just ship a first cache of *.root-servers.net ? 18:00:18 If you don't have the file then you don't have BIND installed. 18:00:31 Yes, I don't have it then. 18:00:41 But shouldn't my resolver have such a list? 18:00:57 Maybe it's like embedded in the source code directly or something like that? 18:01:08 dansa: do you have a iterative resolver configured? 18:01:14 I presume that unbound has the similar file located elsewhere. It's usually called db.root elsewhere and it took me a moment to deduce it for use on BIND named. 18:01:37 nimaje: I don't know. Here's my resolv.conf: %cat /etc/resolv.conf 18:01:38 # Generated by resolvconf 18:01:38 search ec2.internal 18:01:38 nameserver 172.26.0.2 18:01:41 18:02:24 That will point to the nameserver running on 172.26.0.2. But on THAT nameserver it must either forward again or it will have a root nameserver file accessible on it. 18:05:09 The DNS names of the root servers are pretty static AIUI, though it has been a long time since I dug into that aspect of DNS. Anyway, if that's the case, then you can get (and presumably cache) the root servers by looking up (if you have a recursive resolver you can reach) a.root-servers.net through m.root-servers.net 18:05:11 Oh, so I don't really have a resolver, right? I'm only forwarding my requests to someone else? 18:05:22 It's basically a bootstrapping problem. When a nameserver powers up from a cold boot it has no idea where to start looking for data to convert from a name to a number. It consults the db.root file, ahem the named.root file here, and then finds the IP addresses of the 13 top level nameservers that can provide this data. Then it starts querying them for the next bit of information in the chain. 18:05:35 tmp_: IANA tells us who they are at https://www.iana.org/domains/root/servers 18:06:07 dansa: Ah, thanks. Like it wrote, it has been a while. 18:06:10 dansa, Your nameserver 172.26.0.2 directive is forwarding your query to that system and your system is not running a nameserver but the other system is. 18:06:30 rwp: that's what I think too, but my system seems unable to do that because it doesn't have the addresses of the root servers, so I guess it simply sends it all requests to an AWS server hoping to get the answers it needs? 18:06:50 rwp: got ya! that makes sense to me now. 18:06:57 tmp_, The list of top level nameservers are fairly stable but they do change at times. And when it changes things still work because 12 is doing the work of the 13 okay. But that allows a slow progression of upgrade of the file. 18:07:17 how can I run my own true resolver in FreeBSD? (I don't want a DNS server; just a resolver). Is there a nice little package? I guess DJBDNS, right? 18:07:38 FreeBSD comes with a basic unbound resolver built in. 18:07:55 Install either unbound or bind. Is unbound in base? /me goes to look... 18:07:59 Which just needs at least one forwarder to get started. 18:08:00 What's the /unbound/ word? The name of the package? 18:08:14 unbound looks like a port/pkg to me on 14.1R 18:08:43 BIND is the Berkeley Internet Name Daemon. BIND. So "unbound" is a joke. It's the opposite of bind. Joke. 18:08:57 unbound is the name of the software. There's a built-in version, and one in packages. If you have both, the built-in gets called local_unbound, often enough. 18:09:24 Similarly there is a tool called "dig" which can be used to dig into the DNS data. Though as a backronym it is called the domain internet groper. Whatever. We dig for data from dns. 18:09:27 rwp: nice! :) 18:09:33 The configuration for the built in is in /var/unbound/ 18:09:46 I kinda dislike dig because I never understand that output. 18:09:51 So an newer alternative of dig that a lot of people will be using now is "drill". Get it? dig. drill. Jokes abound! 18:09:55 I like /host/, though. 18:10:09 rwp: lol---I love the UNIX world. 18:10:18 * tmp_ uses `getent hosts ...` 18:10:37 tmp_: :) 18:10:39 The host command comes with the set of BIND utilities. Though there is also another host command that comes from a different set of dns utils which has slightly different output. I prefer host from the bind set of utils and use it most often too. 18:10:57 I’m tempted to try selfhosted Bitwarden. My ancient but wonderful auth app (for TOTP - time based one time password - ie 2FA codes) no longer works on my watch. The app hasn’t been available for years, but I’ve always liked the UI. Might as well get started right now. 18:10:59 I believe I'm using the one from BIND. I'm not sure. 18:11:20 getent is a good source of truth. Unfortunately on other systems it's not a great tool. So we end up needing to know how to run all of them at different times. 18:11:24 No, no. It looks like I'm using the alternative one. 18:11:39 COMPATIBILITY 18:11:39 host aims to be reasonably compatible with ‘host’ utility from BIND9 18:11:47 SEE ALSO 18:11:47 drill(1), resolv.conf(5) 18:11:47 18:11:51 Looks like I'm using drill. 18:12:38 drill on FreeBSD comes with the built-in unbound. 18:12:43 If your drill's host command outputs something like "www.example.com has address 93.184.215.14" then I am okay with it. 18:13:36 It does. I never noticed any difference in fact. 18:13:46 %host www.example.com 18:13:47 www.example.com has address 93.184.215.14 18:13:47 www.example.com has IPv6 address 2606:2800:21f:cb07:6820:80da:af6b:8b2c 18:13:47 18:13:52 For me on 14.1R /usr/bin/drill exists in base but I do not have an unbound daemon unless I install it from ports/pkgs. 18:14:09 I don't have an unbound daemon either---and don't want it either. 18:14:10 dansa, That host command seems fully compatible to me and I would use it no problem. 18:14:45 Cool. 18:15:08 So... On a server I always install a local BIND9 named in a caching configuration. But on a mobile laptop I almost never do because I must connect to random WiFi networks that force me through captured portals. 18:15:32 rwp: You don't have /usr/sbin/local-unbound ? 18:15:44 if you want a local resolver which isn't a DNS server, I'm afraid you have to use unbound 18:16:16 and yes, there is some kind of unbound variant in base. the installer offers it. 18:16:23 If you run an SMTP mail server then you will pretty much be required to run your own nameserver. And it is trivial so not a problem. Because DNSBLs will rate limit and if you aggregate up to an AWS server for example then it will be too many queries and you will be blocked. You must do your own DNSBL queries at your own rate. And by the time you get past the free level you will know what you are doing already. 18:16:27 duncan: I guess djbdns would do it too 18:16:31 I mean, /usr/sbin/local-unbound has been part of the system for quite a while now. 18:17:20 I do not know what distinguishes in from the port 18:17:41 here's something I'm puzzled about: if i tell my shell ``drill xyz. @198.41.0.4'' I get the addresses of the authorities for xyz; but if I say ``host -t ns xyz. 198.41.0.4'', I get nothing. 18:17:53 On a mobile laptop tryign to connect to a captured portal system a local caching nameserver will block the action of the captured portal as a security issue. Which it is correct in doing! But we must allow it. So to get through a captured portal one needs to forward through the DNS nameserver given by the DHCP exchange. 18:18:23 Difference between the built-in and the port is essentially version. Built-in on 14.1 is 1.15 while the port has 1.21. 18:18:34 tmp_, Oh /usr/sbin/local-unbound! That must be the local unbound that is offered to be configured for me automatically at installation time? I have tried that several times and it NEVER WORKS for me. NEVER! I have stopped trying. 18:19:35 dansa, What is "xyz." which cannot be a valid FQDN. I would not expect anything from it. Try "example.com." there instead. 18:20:23 well, xyz. is the address of the top-level domain xyz 18:20:25 no? 18:20:27 Perhaps one can query on a TLD name directly but it's not something I would have ever thought of doing. 18:20:33 Also the setup on the built-in is focused on having a cacheing resolver. With what would have been nameserver entries in /etc/resolv.conf going into unbound's forward-addr list, while /etc/resolv.conf switches nameserver to localhost. 18:20:40 You can't query "dig com." either. 18:20:49 And com is a TLD as well. 18:21:56 I can get the addresses of ``.'' 18:21:59 check it out: https://hastebin.skyra.pw/noholetiyo.prolog 18:22:53 rwp: I set up a local-unbound ages ago, so I don't remember how that works during the install. I've extended the config to have stub-zone entries for the local full DNS servers, so I pretty much just import that rather than set it up from scratch anymore. 18:24:02 I like using unbound on my laptop. I enable and disable it as I need for the captured portable problem. I simply install unbound on it. I can see that unbound is easier and simpler and more trouble free for resolving DNSSEC than BIND's named. But both do work. 18:24:21 For serving my DNS zones I have been using BIND's named forever so continue to do so. 18:24:39 Oh, I believe 198.41.0.4 doesn't know the XYZ top-level domain. 18:24:58 because if you just say ``host -t ns xyz.'', we get the authorities for it correctly. 18:25:09 They do different jobs, or rather, unbound does the caching recursive resolver, while nsd does the non-recursive server part. BIND does everything. 18:25:44 The trouble with BIND's named for DNSSEC is that when forwarding then DNSSEC validation must trust the server being forwarded the query. The unbound handles that part perfectly. But bind named needs to be instructed to do it that way needing one more line of config, which is one line that maybe isn't known to be needed. And then it doesn't work right. 18:26:24 The dig equiv to that host command is "dig com. ns" 18:26:56 And pretty much everything I say about dig is the same syntax for drill which is written to be dig compatible. 18:27:31 I am not saying not to use host -t ns as I use the host command for casual use all of the time too. Just also giving the dig syntax for it. 18:27:56 Which I should have added +short to in order to be the same as host: dig com. ns +short 18:28:43 And as long as I am passing by, to direct to a specific nameserver: dig @8.8.8.8 com. ns +short 18:29:20 yeah, with drill I get the expected answer (with ``%drill xyz. ns @198.41.0.4''). 18:29:24 But not with host. 18:29:49 Using host, I asked all root servers for xyz. and none of them knew what to say. 18:29:57 I asked one by one by hand. 18:30:20 I'm puzzled with that. 18:30:35 rwp: IIRC, local-unbound needs three things to work: A forward-zone: with forward-addr: entries in /var/unbound/unbound.conf , /etc/resolv.conf including a nameserver localhost line, and a local_unbound_enable="YES" in /etc/rc.conf 18:31:04 One at a time like this? for ns in $(dig @8.8.8.8 xyz. ns +short); do dig @$ns xyz. ns +short; done 18:31:28 I did manually. :) 18:31:33 I did [it] 18:33:10 tmp_, I will try local-unbound again at some point and figure out why it doesn't work for me. The /etc/resolv.conf always has "nameserver 127.0.0.1" when using a local caching nameserver. Since that's the point. The rc.conf is perfectly normal too. So it must be the /var/unbound/unbound.conf file which is mangled up for some reason. 18:33:45 As I said I just install unbound and configure it normally for using unbound when I want it to work. That always works as normal as things work and so I do it that way. 18:33:58 getting called away irl here bbiab 18:33:58 rwp: I can send you a copy of mine with the stub-zone:s stripped. 18:38:25 hiii! 18:38:34 I need help with NFSv4 ACL and ZFS 18:46:09 it's best to just ask your question 18:47:38 ScrewDriver1337: dontasktoask.com/ 18:49:26 create_args_wlan0="country US regdomain FCC" 18:49:34 seems to fix it jb1277976 debdrup 18:49:47 I have this NFS ACL on my share everyone@:--------------:-------:deny, owner@:rwxp--aARWcCos:fd-----:allow, group@:rwxp--aARWcCos:fd-----:allow 18:49:53 and I can't mount it with NFSv4 18:50:12 but I can mount another zfs dataset which has posixacl 19:09:52 so I enabled NFS_DEBUG in kernel 19:10:00 where I can see debug logs? how can I debug NFS? 19:38:29 hi, I have the following partition in the host that contains several jails: /dev/mfid2p1 on /data what can be done to share that partition with one jail? 19:41:09 uskerine: what do you mean? you want 2 jails to have a common disk area? 19:41:39 I have this partition mounted in the host: /dev/mfid2p1 on /data 19:41:46 and I would like /data be available for one jail 19:42:11 i think you would need to mount it in /jails/myjail/blah for the jail to have access to it 19:43:10 what about sharing it with the host or other jail? 19:44:44 the host can always access it 19:45:03 with another jail i suspect you would need something else,perhaps nfs ? 19:46:53 but this is an educated guess from what I am reading, right? like you have not had such setup before 19:47:13 i haven't had the need 19:59:56 what virtualization are you using and can it even access partitions directly? 20:00:56 zfs might be able to mount something and then use directories like normal if doing zfs, but I'm a bit fuzzy on that 20:01:13 but that's below partitions 20:41:15 networkmgr known to work? it seems to hang forever. despite being in the wheel group 20:46:16 cccccchchlkgjcdhultifbcgthjengefnvnlhjhuvggb 20:48:36 Hi Ober.. i cam now online.. which kind of issue are you facing ? 20:49:03 i am new to Freebsd but will try to help you :).. 20:49:32 irc is hard 20:56:14 ober IRC is atleast easy way to chat with other people regarding issues.. :) 21:12:55 uskerine: how about nullfs? 21:13:57 the_oz_: jails