antranigv: why turn ".com" into ".co ..."?

yuripv it's too long. to make sure the outputs fit a modern screen.

yuripv I know, I know, it was a single letter. I cut domains at 32 and IPv6 at 64

yuripv are you yuri⊙f ?

yuripv@

(locales and other base stuff rather than ports)

I see

antranigv: but if you have space for ... than that single letter wasn't to much, you should consider that in your cut off logic

nimaje good point!

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?

*thought

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.

antranigv: thanks for sharing!

oh, maybe need to clean up some stuff here as well regarding sendmail (=

there is a very interesting question in freebsd-jail right now

how to use sysrc against a jail, why it does not find the jail name as valid

uskerine: any errors?

uskerine, Does jexec find the jailhostname valid? If you run "jexec jailname cat /etc/rc.conf" does that succeed or fail?

AFAIK "sysrc -j jailhost foo=bar" runs something equivalent to "jexec jailhost sysrc foo=bar" and so must be able to "jexec jailhost command".

rwp: Thanks for yesterday's answers. I've filed bugs.freebsd.org/280029 just now.

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.

Thanks for filing the bug report. Last night you did say you were exhausted so any confusion is totally understandable.

And tonight it is the same for me. I should not be up this late. It's 0200 hours here.

rwp: I might have meant slighly drunk rather than exhausted, but same effect. Sweet dreams!

The difference was not important as the result was the same.

It's definitely time for me to crash. Good night all!

New colo server for fbsd is ordered. Kinda excited. :°)

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.

Apparently pf is not all that keen on filtering bridges, but ipfw is okay with it. Anyone have any insights in that?

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.

Alver any chance that you'd use Jailer? we don't have thin Jails, but I'll be happy to implement them

Of course the problem with thin jails is that there are 123234213 ways to configure them, so I ended up using zero.

Alver may I ask which colo is this, btw?

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)

antranigv: Hetzner. They're not perfect, but I'm quite happy with their services. Been there for 10+ years.

They're not expensive, good bandwidth, helpful support crews (which I needed extensively due to my previous mildly exotic setup).

It's possible I'll just go for plain "thick" jails even, it's not like the disk space is tight anyway.

I saw a number fly by here that said 6GB per thick jail - I can spare a good few then.

Alver that I think is too much

On my setup I have 16 jails and and total disk usage of 16GB, so I'm guessing ~1GB per thick jail.

Oh, heh. Okay, then I might just not bother with thin jails.

thin jails are nice when it comes to updating (though etcupdate on thin jails is more of an art at this point)

I know. . .

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.

And it makes me hold off on saving host-specific sessions, while I tweak the "Default Settings."

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.

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.

forget it - It is a client issue in the hw monitor sw

Anybody running znc with external modules?

Nevermind, /usr/local/lib/znc

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.

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.

That way local changes don't need to be merged again and again and again as they are first merged into the reference copy.

rwp: That seems to fit in with my theory.

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.

Perhaps I should modify the saved copies...

I would browse through /var/db/freebsd-update/* and see if that is where the reference copy is stashed. But it might be elsewhere.

Ah... /var/db/etcupdate/current/*

No reference to dvl or dan in that one

I haven't yet learned how that part of the system works yet. It's on the learn queue though.

FWIW, I did `[19:26 certs root /var/db/etcupdate] # grep -r dan *`

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.

Checked and curl is linked to libssl, so I'd imagine it should work if openssl s_client works.

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.

kevans: Answers, I demand answers! >:(

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?

"Place your CA's root certificate in /usr/local/share/certs. Make sure its filename ends with .pem."

Is that true? It needs to end with .pem?'

_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

Problem is that it should be using my internal CA certificates, which I have in /usr/local/share/certs/.

ca_root_nss, which provides the main bundle (i.e. cert.pem), is fine.

Oh wait, nevermind. Got it figured out, I think.

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.