04:49:03 antranigv: why turn ".com" into ".co ..."? 04:49:34 yuripv it's too long. to make sure the outputs fit a modern screen. 04:50:00 yuripv I know, I know, it was a single letter. I cut domains at 32 and IPv6 at 64 04:50:29 yuripv are you yuri⊙f ? 04:50:54 yuripv@ 04:51:32 (locales and other base stuff rather than ports) 04:51:48 I see 05:31:08 antranigv: but if you have space for ... than that single letter wasn't to much, you should consider that in your cut off logic 05:44:31 nimaje good point! 06:35:22 Hi antranigv, browsing your blog, super cool articles! But just noticed, you're having sendmail_xx_enable in your several rc.conf files, by FreeBSD 14, I though dma is enabled and sendmail is already completely disabled and we do not need such lines in rc.conf anymore - am I wrong? 06:35:43 *thought 06:36:37 tercaL thanks for reading! I think you're right, I had that in my scripts from the FreeBSD 9 days and I keep using them :D I should also clean up jailer's provisioning I guess. 06:37:10 antranigv: thanks for sharing! 06:55:30 oh, maybe need to clean up some stuff here as well regarding sendmail (= 07:04:44 there is a very interesting question in freebsd-jail right now 07:05:22 how to use sysrc against a jail, why it does not find the jail name as valid 07:09:04 uskerine: any errors? 07:19:09 uskerine, Does jexec find the jailhostname valid? If you run "jexec jailname cat /etc/rc.conf" does that succeed or fail? 07:19:46 AFAIK "sysrc -j jailhost foo=bar" runs something equivalent to "jexec jailhost sysrc foo=bar" and so must be able to "jexec jailhost command". 07:55:37 <|cos|> rwp: Thanks for yesterday's answers. I've filed https://bugs.freebsd.org/280029 just now. 07:56:32 <|cos|> rwp: I might have been confused about kernels yesterday, not realizing different BE of course has different kernels. In the end it still seems to be user-land related though. 07:57:58 Thanks for filing the bug report. Last night you did say you were exhausted so any confusion is totally understandable. 07:58:26 And tonight it is the same for me. I should not be up this late. It's 0200 hours here. 08:07:02 <|cos|> rwp: I might have meant slighly drunk rather than exhausted, but same effect. Sweet dreams! 08:11:28 The difference was not important as the result was the same. 08:11:38 It's definitely time for me to crash. Good night all! 08:12:40 New colo server for fbsd is ordered. Kinda excited. :°) 08:13:30 Now to think of how I want to do the networking - probably thin jails with vnet, but not decided if I want to do filtering on bridges or not. 08:13:59 Apparently pf is not all that keen on filtering bridges, but ipfw is okay with it. Anyone have any insights in that? 12:52:32 Alver depends. I usually don't set pf on if_bridge, since systems are in the same network, I assume they have the same level of privilage and should be able to access each other. But when I did configure pf for a bridge, I didn't have issues. I think there might be a sysctl or two that you have to configure. 12:53:07 Alver any chance that you'd use Jailer? we don't have thin Jails, but I'll be happy to implement them 12:53:31 Of course the problem with thin jails is that there are 123234213 ways to configure them, so I ended up using zero. 12:54:19 Alver may I ask which colo is this, btw? 13:01:26 antranigv: nothing set in stone yet, but I think I'll go for Bastille. It looks doable and easy to modify (which is unlikely I'll ever need) 13:02:02 antranigv: Hetzner. They're not perfect, but I'm quite happy with their services. Been there for 10+ years. 13:02:53 They're not expensive, good bandwidth, helpful support crews (which I needed extensively due to my previous mildly exotic setup). 13:03:40 It's possible I'll just go for plain "thick" jails even, it's not like the disk space is tight anyway. 13:04:01 I saw a number fly by here that said 6GB per thick jail - I can spare a good few then. 13:08:47 Alver that I think is too much 13:10:08 On my setup I have 16 jails and and total disk usage of 16GB, so I'm guessing ~1GB per thick jail. 14:40:43 Oh, heh. Okay, then I might just not bother with thin jails. 15:02:41 thin jails are nice when it comes to updating (though etcupdate on thin jails is more of an art at this point) 15:12:16 I know. . . 15:13:01 I quite like putty. . . but it has wierd defaults. . . and I find on new-installs it takes a lot of setting customization to get into a sane config. 15:14:00 And it makes me hold off on saving host-specific sessions, while I tweak the "Default Settings." 15:36:16 Alver I am reading FreeBSD Mastery Jails, if I understood correctly, thin jail advantages use ZFS clones, and all disadvantages disappear when you start upgrading separtely the jails. If I understood well the advantages over the complexities, they are not worth for most of the times. 17:38:12 after upgrading to 14.1 I seem to only get temperature readings from APIC 0 and 1. Not 2-6. That is the cpus on the first processor card / HP DL 585. Has anyone experienced anything similar? They all seem to be running just fine. 17:45:20 forget it - It is a client issue in the hw monitor sw 19:01:53 Anybody running znc with external modules? 19:05:31 Nevermind, /usr/local/lib/znc 19:18:59 I have this interesting situation when upgrading some jails from FreeBSD 14.0 to 14.1 - In those jails, I had recently renamed my login accounts from dan to dvl. When merging /etc/master.passwd, I see dan in there, not dvl, despite being logged into that jail as dvl and seeing dvl when running vipw in that jail. I have no idea where this is coming from. etcupdate? I'm upgrading the jails via freebsd-update upgrade. 19:22:03 dvl, This is from fuzzy knowledge so caution but I think freebsd-update does things in 2 phases. One is a reference copy. That goes through a merge first. Then the reference copy is merged into the live copy. 19:22:27 That way local changes don't need to be merged again and again and again as they are first merged into the reference copy. 19:22:28 rwp: That seems to fit in with my theory. 19:22:56 And then later merges can be done automatically and accepted because they are not a new change. It's somewhat like a 3-way merge done in two 2-way steps. 19:23:18 Perhaps I should modify the saved copies... 19:24:18 I would browse through /var/db/freebsd-update/* and see if that is where the reference copy is stashed. But it might be elsewhere. 19:25:26 Ah... /var/db/etcupdate/current/* 19:26:15 No reference to dvl or dan in that one 19:26:39 I haven't yet learned how that part of the system works yet. It's on the learn queue though. 19:27:02 FWIW, I did `[19:26 certs root /var/db/etcupdate] # grep -r dan *` 23:24:27 <_xor> Hmm, strange. `openssl s_client -connect IP:PORT` returns ok when I use it to verify an internal server TLS certificate that's signed by an internal CA. But when I use curl on the same IP:PORT, it fails to verify TLS and errors out saying that it's unable to get the local issuer certificate. 23:24:52 <_xor> Checked and curl is linked to libssl, so I'd imagine it should work if openssl s_client works. 23:25:42 <_xor> Checked my internal CA certs and ran `certctl rehash` just to make sure, but no dice. I openssl verified the certificates locally as well, and it said they're ok. 23:26:35 <_xor> kevans: Answers, I demand answers! >:( 23:30:24 Hello, while installing FreeBSD, I have three choces of Russian keymap: Russian [ru.kbd], Russian (shift) [ru.shift.kbd], and Russian (winkeys) [ru.win.kbd]. What is the difference between them? 23:30:40 <_xor> "Place your CA's root certificate in /usr/local/share/certs. Make sure its filename ends with .pem." 23:30:45 <_xor> Is that true? It needs to end with .pem?' 23:34:58 _xor: curl is probably looking for /usr/local/etc/ssl/cert.pem that should be a symlink to ca-root-nss.crt in the share/certs dir 23:38:39 <_xor> Problem is that it should be using my internal CA certificates, which I have in /usr/local/share/certs/. 23:39:09 <_xor> ca_root_nss, which provides the main bundle (i.e. cert.pem), is fine. 23:41:24 <_xor> Oh wait, nevermind. Got it figured out, I think. 23:42:06 <_xor> Was missing --resolve arg to curl. Noticed just now that it was trying to use the IP address for SNI instead of the actual hostname.