2022年4月30日土曜日

Zabbixの「nodata」関数を使って一定期間データが受信できない場合にトリガーで検知させる

自宅ではRaspberry PiにてPC周りの温度・湿度を計測しており、計測した温度・湿度情報は、zabbix_senderコマンドを用いてZabbixに送信して監視を実現している。Zabbixではグラフとして表示させ、年間での温度・湿度の変化を確認できるようにもしている。

Raspberry Piによる温度計測とZabbixへの連携方法の詳細を知りたい場合は、以下別記事にて記載しているので参照いただきたい。

温度・湿度の計測は基本的には問題なくできており満足しているが、まれに不調により計測が長時間失敗することがある(下図の赤枠箇所)。

このような、「一定時間Zabbixへ監視情報が送られてこない」状態は、Zabbixの「nodata」関数を利用することで監視することができる。本記事では、Zabbixの「nodata」関数を使って一定期間データが受信できない場合にトリガーで検知させる方法を記載する。

環境

環境は以下の通り。Zabbix 6.0を利用しているが、nodata関数自体は昔のバージョンから利用可能となる。

  • OS : CentOS Stream 8
  • Zabbix : 6.0.2

手順

1. トリガーを作成

nodata関数の記載は以下の通り。設定した秒数よりも長い時間データが未受信であれば1を返し、受信していれば0を返す。

nodata(監視対象アイテム,データ未受信の秒数)

なお、ZabbixのGUI上では設定単位が「時間」と書いてあるように見えるが、「Hour」の意味ではなく、あくまで設定値は「秒」である点に注意しよう。

データ未受信の秒数は30秒に1回チェックされることから、30秒以上で設定すること。

以上をふまえ、トリガーの設定内容は以下の通りとなる。

設定項目 設定例 説明
名前 No sensor data received 任意で指定する。
深刻度 警告 任意で指定する。
障害の条件式 nodata(/Template Sensor Temperature/rasp_temp,3600)=1 今回は1時間(3600秒)データが未受信の場合、トリガーにて障害検知できるようにする。
正常イベントの生成 復旧条件式 自動で障害復旧できるよう復旧条件式を指定する。
復旧条件式 nodata(/Template Sensor Temperature/rasp_temp,3600)=0 障害の条件式逆にnodata関数の結果が0であることを条件式として設定する。
有効 チェック トリガーを有効にする。

2. 動作確認

実際に設定したトリガーが動作することを確認してみよう。データ受信しないよう監視対象サーバを停止して、nodata関数で設定時間経過するのを待つ。すると、以下の通り正常にトリガーにて障害検知がされた。

監視対象サーバを復旧させ監視データの受信を再開すると、自動で「解決済」ステータスとなった。

以上で、Zabbixの「nodata」関数を使って一定期間データが受信できない場合にトリガーで検知させる手順は完了となる。

参考

2022年4月23日土曜日

「このワークステーションとプライマリドメインとの信頼関係に失敗しました。」のエラーを解消する。

仮想環境に構築したドメイン参加済みのWindows OSに対して、スナップショットなどからリストアすると、以下エラーによりドメインアカウントを用いてもログインができなくなることがある。

「このワークステーションとプライマリドメインとの信頼関係に失敗しました。」

これは「セキュアチャネルの破損」と呼ばれる事象であり、ドメイン再参加または、コマンドによるセキュアチャネルの修復作業が必要となる。

今回はPowerShellのコマンドを用いて本エラーを解消し、再びドメインアカウントにてログインできるようにする手順を記載する。

環境

  • ドメインコントローラ : Windows Server 2016
  • ドメイン参加対象のクライアント : Windows Server 2019

エラー解消手順

1. ロカールアカウントでログイン

ドメインアカウントではログインできないので、ローカルアカウントでログインを行う。

2. PowerShellにてセキュアチャネルの状態を確認

PowerShellを管理者として開き、Test-ComputerSecureChannelを実行する。セキュアチャネルが破損している場合は、以下の通りFalseと表示されるはずだ。

PS C:\> Test-ComputerSecureChannel
False

3. セキュアチャネルを修復

引き続きTest-ComputerSecureChannelを用いてセキュアチャネルの修復を行う。セキュアチャネルの修復には、-Repairオプションと-Credentialで任意のドメインアカウントを指定する。

PS C:\> Test-ComputerSecureChannel -Repair -Credential [ドメイン名]\[ドメインアカウント名]
True

指定したドメインアカウントのパスワード入力を求められるので入力する。

数秒待ちTrueが返ってくれば、セキュアチャネルの修復は完了となる。

4. ドメインアカウントで再ログイン

一度ログアウトし、ドメインアカウントにて再度ログインを行う。問題なくログインできれば作業は完了となる。

参考

2022年4月16日土曜日

Cisco Business 250 (CBS250-8T-E-2G) のファームウェアバージョンアップ手順

先日、Cisco Business 250の10ポートモデルである「CBS250-8T-E-2G」を購入した。購入した経緯としては、CLIを使ってCiscoライクなコマンドで設定できて、SNMPを使って監視できる機器が欲しかったことが理由となる。

Cisco Business 250はAmazonで売ってはいる。以下にAmazonの購入リンクを記載しておくが、Yahoo! ショッピングで探した方がより安価で購入することができるのでお勧めとなる。

届いたスイッチのファームウェアを確認すると最新のファームウェアではなかったことから、まずはファームウェア更新を行うことにした。

本記事では、Cisco Business 250のファームウェアバージョンアップ手順を記載する。

環境

Cisco Business 250の機器型番と新旧のファームウェアバージョンを以下に記載する。

  • 機器型番 : CBS250-8T-E-2G
  • 旧ファームウェアバージョン : 3.0.0.69
  • 新ファームウェアバージョン : 3.1.1.7

Cisco Business 250ファームウェアバージョンアップ手順

1. ファームウェア及び言語ファイルをダウンロード

ファームウェアは以下からダウンロードできる。

機器型番は「Business 250-8T-E-2G Smart Switch」を選択し、最新のファームウェアの「ダウンロード オプション」リンクを選択する。

次の画面では、ファームウェア本体と言語ファイルの2つのファイルをダウンロードする。なお、ファームウェアは40MB程度と軽量である。

  • Firmware image for CBS250 release 3.1.1.7
  • JapaneseLanguage file for Cisco Business 250 series switches release 3.1.1.7

2. GUIよりファームウェアを更新

ファームウェア更新はGUIより実施できる。Cisco Business 250のGUIにログインし、左メニューの「管理者」→「ファイル管理」→「ファームウェア操作」を選択する。

ファームウェア操作では以下を設定し、右上の「適用」ボタンを押すことでファームウェアの更新が開始される。

設定項目 設定値
操作タイプ ファームウェアの更新
コピー方式 HTTP/HTTPS
ファイル名 先ほどダウンロードしたファームウェアファイル (拡張子.bin)

1~2分ほど待機し、画面上部に「成功」と表示されれば成功となる。ただし、この段階では「アクティブなファームウェアバージョン」は旧ファームウェアバージョンのままとなる。

3. スイッチを再起動

新ファームウェアで起動させるため、スイッチの再起動を行う。左メニューの「管理者」→「リブート」を選択し、「即時」が選択された状態で右上の「リブート」を選択する。

4, ファームウェアの更新を確認

5分ほど待機しGUIにログインしなおして、再度、左メニューの「管理者」→「ファイル管理」→「ファームウェア操作」を選択する。「アクティブなファームウェアバージョン」が新ファームウェアバージョンとなっていれば問題ない。

5. 言語ファイルをアップロード

左メニューの「管理者」→「ファイル管理」→「ファイル操作」を選択する。ファイル操作では以下を設定し、右上の「適用」ボタンを押すことで言語ファイルがアップロードされる。

設定項目 設定値
操作タイプ ファイルの更新
宛先ファイルタイプ 言語ファイル
コピー方式 HTTP/HTTPS
ファイル名 先ほどダウンロードしたフ言語ファイル (拡張子.lang)

なお、言語ファイルがアップロードに成功すると、一時的に言語設定が英語に変更される。

この場合は一度GUIからログオフし、ログイン画面で言語設定を日本語に変更することで、日本語に戻すことが可能となる。

6. 言語ファイルの更新を確認

言語ファイルが更新されていることの確認は、左メニューの「ステータスと統計画面」→「システムサマリー」にて確認することができる。なお、ダウンロードした言語ファイルのバージョンは「3.1.1.7」と表記されているが、実際のバージョンは「3.1.0.59」である点に注意しよう。

以上で、Cisco Business 250のファームウェアバージョンアップは完了となる。

2022年4月9日土曜日

WireGuardの接続・切断のログをファイルに出力させる手順

WireGuardはOSSのVPNソフトウェアであり、ソースコードが4,000行程度と非常にコンパクトで、Linuxのカーネルモジュールとして動作するという特徴がある。

WireGuardにてVPN環境を構築する手順については、以下別記事で記載している。

WireGuardはVPN接続した際に、wgコマンドで接続状態を確認することができる。例えば、以下実行例ではpeer: YYYYYYYYの接続対象は、1時間36分前に接続があったことを確認できる (★箇所)。

# wg
interface: wg0
  public key: XXXXXXXX
  private key: (hidden)
  listening port: 51820

peer: YYYYYYYY
  endpoint: 12.34.56.78:52852
  allowed ips: 10.0.1.21/32
  latest handshake: 1 hours, 36 minutes, 38 seconds ago ★
  transfer: 150.96 KiB received, 903.67 KiB sent

しかし、WireGuardは接続・切断のログはファイルに出力されないため、アクセスログが残らないことからセキュリティ上問題となる場合がある。

そこで今回は、WireGuardの接続・切断のログをファイルに出力させる手順を記載する。

環境

今回はRHELクローンであるAlmaLinuxにて構築を行ったが、CentOSや本家RHELでも同様の手順で構築できるだろう。

  • OS : AlmaLinux release 8.5 (Arctic Sphynx)

WireGuardログ出力手順

1. kernelのDynamic debugを有効にする

WireGuardは設定ファイルなどではログを出力させることはできず、kernelのDynamic debugと呼ばれるデバッグログの出力機能を用いることによって、ログの出力が可能となる。

なお、Secure Bootが有効となっている場合は、本設定は「Operation not permitted」のエラーで失敗するため、Secure Bootを解除する必要がある。

Dynamic debugによるログの有効化・無効化は以下コマンドで実施できる。有効化されているかどうかは、/sys/kernel/debug/dynamic_debug/controlgrepし、=pという文字列が含まれているかどうかで確認できる (無効化されている場合は、=_という文字列になる)。

有効化

# echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control
# cat /sys/kernel/debug/dynamic_debug/control | grep -e 'wireguard.*=p'
/home/phil/rpmbuild/BUILD/wireguard-linux-compat-1.0.20211208/src/noise.c:818 [wireguard]wg_noise_handshake_begin_session =p "%s: Keypair %llu created for peer %llu\012"
/home/phil/rpmbuild/BUILD/wireguard-linux-compat-1.0.20211208/src/noise.c:125 [wireguard]keypair_free_kref =p "%s: Keypair %llu destroyed for peer %llu\012"
/home/phil/rpmbuild/BUILD/wireguard-linux-compat-1.0.20211208/src/device.c:420 [wireguard]wg_netns_pre_exit =p "%s: Creating namespace exiting\012"
~(以下略)~

無効化

# echo module wireguard -p > /sys/kernel/debug/dynamic_debug/control
# cat /sys/kernel/debug/dynamic_debug/control | grep -e 'wireguard.*=p'
★無効化されている場合は何も表示されない。

公式サイトではmodprobe wireguardを実行しエラーがない場合は、Dynamic debugによるログの有効化を行う手順になっている。本記事では、公式サイトのコマンドを採用する。

# modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

2. 再起動時にDynamic debugを有効にする

Dynamic debugは一時的な設定であり、再起動すると設定は無効化される。そこで、cronを使ってOS起動時にDynamic debugを有効にするコマンドを実行するよう設定する。modprobeコマンドは絶対パスで記載する点に注意しよう。

# crontab -l
@reboot /usr/sbin/modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control

設定後は一度OSを再起動して問題なく実行されることを確認しておこう。

# reboot
# tail -10 /var/log/cron
~(中略)~
Apr  1 06:51:04 t3036vpns CROND[1132]: (root) CMD (/usr/sbin/modprobe wireguard && echo module wireguard +p > /sys/kernel/debug/dynamic_debug/control)

3. rsyslogにて/var/log/messagesに出力させる

これでWireGuard接続時にログは出力されるようになり、journalctlではi以下のように接続ログが表示されるようになる。

# journalctl -n 10 --no-pager
~(中略)~
 4月 01 06:02:06 t3036vpns kernel: wireguard: wg0: Receiving handshake initiation from peer 1 (12.34.56.78:59755)
 4月 01 06:02:06 t3036vpns kernel: wireguard: wg0: Sending handshake response to peer 1 (12.34.56.78:59755)
 4月 01 06:02:06 t3036vpns kernel: wireguard: wg0: Keypair 4 created for peer 1
 4月 01 06:02:17 t3036vpns kernel: wireguard: wg0: Sending keepalive packet to peer 1 (12.34.56.78:59755)

しかし、このままでは/var/log/messagesには出力されないため、rsyslogの/var/log/messagesの設定にkern.debugを追加する。

# vi /etc/rsyslog.conf
~(中略)~
*.info;mail.none;authpriv.none;cron.none;kern.debug     /var/log/messages
~(以下略)~

# systemctl restart rsyslog

4. 動作確認

最後に、実際にWireGuardで接続・切断した際のログ出力を確認しておこう。

まずは接続時のログは以下となる。Receiving handshake initiationのメッセージにてWireGuardの接続が開始されたことを確認できる。

# tail -f /var/log/messages
~(中略)~
Apr  1 08:03:35 t3036vpns kernel: wireguard: wg0: Receiving handshake initiation from peer 1 (12.34.56.78:59511)
Apr  1 08:03:35 t3036vpns kernel: wireguard: wg0: Sending handshake response to peer 1 (12.34.56.78:59511)
Apr  1 08:03:35 t3036vpns kernel: wireguard: wg0: Keypair 2 created for peer 1
Apr  1 08:03:47 t3036vpns kernel: wireguard: wg0: Sending keepalive packet to peer 1 (12.34.56.78:59511)

切断時のログは以下となる。WireGuardは、接続対象から応答がなくなってから20回接続確認を行い、すべて失敗したらあきらめて (did not complete after 20 attempts, giving up) 切断するようだ。最終的なWireGuardの切断は、Zeroing out all keysのメッセージにて確認できる。

# tail -f /var/log/messages
~(中略)~
Apr  1 08:08:13 t3036vpns kernel: wireguard: wg0: Handshake for peer 1 (12.34.56.78:59511) did not complete after 5 seconds, retrying (try 19)
Apr  1 08:08:13 t3036vpns kernel: wireguard: wg0: Sending handshake initiation to peer 1 (12.34.56.78:59511)
Apr  1 08:08:19 t3036vpns kernel: wireguard: wg0: Handshake for peer 1 (12.34.56.78:59511) did not complete after 5 seconds, retrying (try 20)
Apr  1 08:08:19 t3036vpns kernel: wireguard: wg0: Sending handshake initiation to peer 1 (12.34.56.78:59511)
Apr  1 08:08:24 t3036vpns kernel: wireguard: wg0: Handshake for peer 1 (12.34.56.78:59511) did not complete after 20 attempts, giving up
Apr  1 08:13:00 t3036vpns kernel: wireguard: wg0: Zeroing out all keys for peer 1 (12.34.56.78:59511), since we haven't received a new one in 540 seconds
Apr  1 08:13:00 t3036vpns kernel: wireguard: wg0: Keypair 2 destroyed for peer 1

以上で、WireGuardの接続・切断のログをファイルに出力させる手順は完了となる。

参考

2022年4月2日土曜日

vCenter Server Appliance 7.0のバックアップ&リストア手順

vCenter Server Appliance (以下、vCSA) では、バックアップファイルを外部のファイルサーバなどに出力する機能が備わっており、VMwareとしても推奨するバックアップ手法となる。

今回、実際にバックアップファイルを出力しリストアを実施してみた。本記事では、vCSAのバックアップをCIFSファイルサーバに出力し、出力したバックアップファイルからリストアする手順を記載する。

環境

環境としてはvSphere 7.0を用いる。2台のvCSAを構築して拡張リンクモードで構成し、片方のvCSAをリストアしても、拡張リンクモード含め問題なく復旧できることを確認する。

  • vCenter Server : 7.0 Update 1d
  • ESXi : 7.0 Update 1c
  • CIFSファイルサーバ : QNAP TS-231P

バックアップ手順

1. アプライアンス管理画面にログイン

vCSAのバックアップはvSphere Clientではなく、vCSAのアプライアンス管理画面 (ポート番号5480) にて行う。

https://[vCSAのIPアドレス]:5480/

アプライアンス管理画面は、rootまたはSSO管理者 (例えばAdministrator@vsphere.local) でログインする。

2. バックアップを取得

アプライアンス管理画面のメニューより「バックアップ」から「今すぐバックアップ」ボタンを選択すると、1回限りのバックアップを取得できる。

なお、スケジュールを設定して定期的にバックアップを取得することも可能となる。通常は、日次などでバックアップ取得するようスケジュール設定すべきだろう。

バックアップは以下の設定項目がある。以下に各説明項目を記載する。

設定項目 説明
バックアップの場所 バックアップの場所を指定する。[プロトコル名]://[バックアップサーバのIPアドレス]/[フォルダ]といった形式で指定する。対応するプロトコルは、FTPS、HTTPS、SFTP、FTP、NFS、SMB、HTTPを指定できる。今回はSMBを指定する。
バックアップサーバの認証情報 バックアップファイル保存に必要な権限を持つユーザ、パスワードを入力する。
暗号化バックアップ バックアップファイルを暗号化する場合はパスワードを設定する。
DBの健全性チェック バックアップ時にDBの健全性チェックを行う場合はチェックする。デフォルトは有効であるため、特に理由がなければ有効で問題ない。
データ データに統計情報やイベントを含める場合はチェックする。サイズを削減したいなどの理由がある場合のみ無効にすればよいだろう。

3. バックアップ完了まで待機

バックアップ完了まで待機する。

私の環境のvCSAはほぼ新規構築状態となるため、バックアップファイルは約240MBとなり、バックアップは1分で完了した。

リストア手順

1. ESXiにログインしvCSAを登録解除

vCSAのリストア時に同じESXi上に元のvCSAが存在する場合、仮想マシン名が重複することにより、リストア時にエラーとなる。そのため、事前にESXiのVMware Host Clientにログインし、vCSAのシャットダウンとESXiからの登録解除を実施しておこう。

2. vCSAのインストーラよりリストアを開始

vCSAのISOイメージに含まれるinstaller.exeを起動しvCSAのインストーラを起動すると、「リストア」の選択項目があるため、それを選択する。

リストアは以下の設定項目がある。以下に各説明項目を記載する。

設定項目 説明
バックアップの詳細を入力 ここではリストア時と同様に、バックアップサーバのIPアドレスと認証情報を設定する。
vCenter Server のデプロイ ターゲット vCSAリストア先のESXiのIPアドレスを設定する。
ターゲット vCenter Server 仮想マシンのセットアップ リストアするvCSAの仮想マシン名とrootパスワードを設定する。通常は元のvCSAと同一の設定で問題ないだろう。なお、このタイミングで仮想マシン名の重複チェックがされるため、前段の手順で実施したvCSAの登録解除は必ず実施しておく必要がある。もし重複する場合は、「ターゲットに同じ名前の仮想マシンまたはテンプレートが存在するかどうかを確認中に問題が発生しました」のエラーでインストールを進めることができない
デプロイ サイズの選択 元のvCSAのサイズを選択すれば問題ない。
データストアの選択 vCSAが稼働するだけの十分な空き容量があるデータストアを選択する。
ネットワークの設定 元のvCSAのIPアドレス設定をすれば問題ない。

上記設定完了後、vCSAのデプロイが開始する。

3. 展開したvCSAにてリストアを実施

ここまではvCSAの通常のインストールウィザードと同様となるが、ここから先がリストアの場合は異なる。

以下に設定項目を記載する。

設定項目 説明
バックアップの詳細 ここは前述した手順で指定した情報から変更ができないが、バックアップに暗号化パスワードを設定していた場合は、解除パスワードを指定する。
Single Sign-On 構成 元のvCSAのSSO管理者のユーザ名とパスワードを入力する。通常はAdministrator@vsphere.localを選ぶことになるだろう。

上記設定完了後、リストアが開始する。

4. リストア完了まで待機

リストア完了まで待機する。リストア状況の進捗は表示されるが、97%になってから少し時間を要するので、気長に完了を待つこと。とはいっても、私の環境では、10分程度で完了した。

問題なく完了すると、「このvCenter Serverは正常にリストアされました」とメッセージが表示される。

5. リストア後の確認

リストア後、再度vSphere Clientでログインしてみよう。

なお、私の環境ではなぜか404のエラーでうまくログインできない事象が発生したが、一度ブラウザのキャッシュクリアやブラウザの落とし上げをしたり、少し時間をおいてからログインを試みると正常にログインできた。

ログインに成功すると、以下図の通り一台のvCSAは「親 (実体) なし」で表示され、リストアしたvCSAは末尾に「(1)」が名前に付与されていることがわかる。元のvCSAの情報がゴミとして残ってしまい「親 (実体) なし」となっているようだ。これは次の手順でインベントリから削除すれば問題ない。

また、左側のツリーには拡張リンクモードしている2台のvCSAが存在しており、リストアしても問題なく拡張リンクモードの構成は維持されていることが確認できる。

6. vCSAの仮想マシン名を修正

「親 (実体) なし」のvCSAは不要となるため、「インベントリから削除」する。インベントリから削除したのち、リストアしたvCSAを正しい名前に修正する。

以上で、vCSAのバックアップファイルからのリストアは完了となる。

参考

人気の投稿