Until now, most of my PVE systems were manually configured with CheckMK agent and TLS. Yesterday i setup Dynamic Host Management and it’s running great but for two issues:
Existing hosts are now duplicated. i.e. <<linux.company.io>> (manually configured) sits beside <> (auto-created in CheckMK by DHM/Piggyback.
All auto-created systems are failing TLS - even though they are registered and functioning with TLS in their manual incarnation. i.e. <<linux.company.io>> works with TLS but <> fails.
My best guess is that this is a naming problem? I have manually create them with their local URL and piggyback uses the actual host name? This might also explain why TLS is failing; wrong name.
Questions:
What is the correct process for mixing DHM/Piggyback with manually created systems?
How is TLS going to self-register on an auto-configured piggyback system?
Please check your message, I think the forum software ate some of the hostnames in < >
TLS is host name dependend, so the DHM created hosts that have another fqdn (or just shortname?) so a host with another hostname is supposed to fail as “host.company.io” is not the same as “host”
I suppose, you don’t really want the duplicate hosts anyway, so my suggestion would be: don’t worry about TLS not working on the second/duplicate host, get rid of the duplicate host.
=> The piggyback mechanism has some documentation about renaming the incoming piggyback data so that it matches your existing hosts.
Right. Like many, I cannot live with a yellow light, so I have to fix it.
I realize that using the piggyback DHM is a far better way to go. Just need to recognize that it IDENTIFIES the machines, but I then need to manually TLS register them and all’s well. It means no phantom machines exist without my knowledge - and I like this a lot.
So I’ll delete the original, incorrectly named, instances and give preference to the DHM ones. Staff will just have to ensure that any new machine must be either fully setup - or erased from the cluster. No more phantoms.
