Puppetを介してIcinga2リモートクライアントを設定したいのですが、 公式ドキュメント のページ全体で、awesomeCLIウィザードの使用について説明しています、手動で実行する必要があります。
回避策はありますか?たぶん私はナギオスに戻るべきですか?
同じ問題がありました。これは、icinga2ノードウィザードコードからロジックを抽出した後に使用するものです。
必要な変数:
$pki_dir - /etc/icinga2/pki in the default installation
$fqdn - fully Host+domain name of the client.
$icinga2_master - resolvable fqdn of the master
$icinga2_master_port - the port the master is connectable on.
$ticket - generated on the master via 'icinga2 pki ticket --cn $fqdn'
コード:
mkdir icinga:icinga 0700 $pki_dir
icinga2 pki new-cert --cn $fqdn --key $pki_dir/$fqdn.key --cert $pki_dir/$fqdn.crt
icinga2 pki save-cert --key $pki_dir/$fqdn.key --cert $pki_dir/$fqdn.crt --trustedcert $pki_dir/trusted-master.crt --Host $icinga2_master
icinga2 pki request --Host $icinga2_master --port $icinga2_master_port --ticket $ticket --key $pki_dir/$fqdn.key --cert $pki_dir/$fqdn.crt --trustedcert $pki_dir/trusted-master.crt --ca $pki_dir/ca.key
icinga2 node setup --ticket $ticket --endpoint $icinga2_master --zone $fqdn --master_Host $icinga2_master --trustedcert $pki_dir/trusted-master.crt
systemctl restart icinga2 # or however you restart your icinga
TryTryAgainが書いたようなものです。最新のドキュメントは2つの異なる方法を説明しています。 トップダウンリモートコマンド実行およびトップダウン構成同期
このアプローチの違いは、リモートコマンドの実行がマスターからすべてのコマンドをトリガーする一方で、config syncが/etc/icinga2/zones.d
にあるすべての構成ファイルを子ノードに同期することです(サテライトおよびクライアント)、エンドポイントで直接コマンド実行をトリガーします。
マスターが子への接続を失ってもクライアントはチェックを実行するので、私はTop-Down Config Syncアプローチを使用することを好みます。
すべてのノードでAPI
機能を有効にする必要があります。
# /etc/icinga2/features-enabled/api.conf
object ApiListener "api" {
cert_path = "/etc/ssl/{{ hostname }}.pem"
key_path = "/etc/ssl/{{ hostname }}-key.pem"
ca_path = "/etc/ssl/rootca.pem"
// only on satelites and clients
accept_config = true
}
次に、ゾーンファイルを作成し、すべてのノードにコピーします。
# /etc/icinga2/zones.conf
// global zone used for zone overlapping configs
object Zone "global" {
global = true
}
// endpoints
object Endpoint "fqdn1.of.Host" {
Host = "fqdn1.of.Host"
}
object Endpoint "fqdn2.of.Host" {
Host = "fqdn2.of.Host"
}
// for each endpoint one zone
object Zone "fqdn1.of.Host" {
endpoints = [ "fqdn1.of.Host" ]
}
object Zone "fqdn2.of.Host" {
endpoints = [ "fqdn2.of.Host" ]
parent = "fqdn1.of.Host"
}
ベストプラクティスは、ノードのfqdnをエンドポイント名およびゾーン名として使用することです。 記憶:このzones.conf
をすべてのノードにコピーします。
次のステップは、/etc/icinga2/zones.d/
内のすべてのサービス、テンプレート、およびグループと、そのゾーンディレクトリ内の独自のhosts.conf内の各ホストを定義することです。
# /etc/icinga2/zones.d/global/templates.conf
template Host "generic-Host" {
max_check_attempts = 3
check_interval = 1m
retry_interval = 30s
check_command = "hostalive"
}
# /etc/icinga2/zones.d/fqdn1.of.Host/hosts.conf
// this is the master
object Host "fqdn1.of.Host" {
import "generic-Host"
address = "fqdn1.of.Host"
}
# /etc/icinga2/zones.d/fqdn2.of.Host/hosts.conf
// this is a satelite/client
object Host "fqdn2.of.Host" {
import "generic-Host"
address = "fqdn2.of.Host"
}
私のアプローチは、/etc/icinga2/conf.d
内のすべての一般的な(およびグローバルに使用される)ものと/etc/icinga2/zones.d/global
内のホスト固有のものを追加したため、/etc/icinga2/zones.d/fqdnX.of.Host
内の構成の使用を防ぐことでした。
最後に、conf.dのincludeステートメントを削除する必要があります
# /etc/icinga2/icinga2.conf
[...]
// include_recursive "conf.d"
それでおしまい。このセットアップでは、証明書を手動で管理するか、選択した構成管理を使用して管理する必要があります。生成されず、icinga pkiを使用しません。このための特定のツールがある限り、ツール固有のpkiを使用する必要がある理由はありません。