朝から昼寝

整理しておきたいIT関連の小ネタ

はてなブログはSearch Consoleの所有権確認でGTM不可のよう

概要

Google Search Consoleの初期登録(プロパティ作成)の際に必要となるサイトの所有権確認。いくつかある方法のうち、Google Tag Manager(GTM)を用いた確認は手間がかからず便利ですが、はてなブログではうまく所有権確認できませんでした。
本記事は、はてなブログにおいて、Google Search Consoleのサイト所有権確認の方法としてGTMが使用できない点とその代替手段について記載します。
2022年9月時点の確認結果です。

本記事の目的

  • はてなブログにおいて、Google Search Consoleのサイト所有権確認の方法としてGTMが使用できない点を理解する。
  • 別の方法でサイト所有権確認を行う。

基本

事象

GTMを設定済みであれば、Search Consoleのサイト所有権確認の方法としてGTMを利用すると便利です。所有権確認のためにWebサイトやDNSの修正等の設定作業が不要なためです。

しかしながら、はてなブログでは、はてなブログ全体用(?)にもともと設定されているGTMコンテナスニペット(GTM-P4CXTW)があるので、この確認方法は使えないようです。
はてなブログ設定詳細設定Google タグマネージャに自分が用意したGTMのコンテナIDを入力してから所有権確認を実行しても、以下のようなエラーとなります。

GTMによる所有権確認失敗
GTMによる所有権確認失敗
"サイトのホームページで Google タグ マネージャー コンテナ ID が見つかりませんでした。"

はてなブログの全てのページの要素内には、はてなブログ全体用(?)のGTMコンテナスニペットを識別するため以下のコードが埋め込まれています。

<!-- Google Tag Manager -->
<script>(function(w,d,s,l,i){w[l]=w[l]||[];w[l].push({'gtm.start':
new Date().getTime(),event:'gtm.js'});var f=d.getElementsByTagName(s)[0],
j=d.createElement(s),dl=l!='dataLayer'?'&l='+l:'';j.async=true;j.src=
'https://www.googletagmanager.com/gtm.js?id='+i+dl;f.parentNode.insertBefore(j,f);
})(window,document,'script','dataLayer','GTM-P4CXTW');</script>
<!-- End Google Tag Manager -->

はてなブログ設定詳細設定Google タグマネージャから入力したコンテナIDは、上記の"GTM-P4CXTW"より下に追加される動作になるようです。
(上か下かが原因で所有権確認ができないのかを正確に検証はしていませんが、GTMのコードが複数あることにより所有権確認が失敗していると思われます)

対処方法

GTMでなく、HTMLタグ(metaタグ)により所有権確認できます。所有権確認の方法はどれを選んでもSearch Consoleの利用に問題はありません。

所有権確認の方法としてHTMLタグを選択した際に表示されるmetaタグの値をコピーし、はてなブログ設定詳細設定Google Search Console(旧 Google ウェブマスター ツール)に入力します。

コピーする文字列は、metaタグ全体でなく、<meta name="google-site-verification" content="xxxxx">の中の、"xxxxx"の部分だけです。

はてなブログの設定箇所
はてなブログの設定箇所

詳細

その他のエラー

GTMによる所有権確認として、はてなブログ設定デザインからnoscriptのコードをタイトル下に入れるという確認も行いましたが、以下のエラーでうまくいきませんでした。

GTMによる所有権確認失敗2
GTMによる所有権確認失敗2
"サイトの Google タグ マネージャー スニペットが、ページ上の正しい場所に配置されていません。"

参考URL等

Hyper-Vゲストの通信をホスト側で制限(拡張ACL: Add-VMNetworkAdapterExtendedAcl)

概要

仮想環境において、ゲストの通信を必要最低限の範囲に制限しておきたい場合があります。特に、ネットワーク側のファイアウォール設定だけでは都合が悪い場合、ホスト側で制限をかけられると便利です。
本記事は、Hyper-V環境でAdd-VMNetworkAdapterExtendedAclコマンドレット(拡張ACL)によりゲストの通信を制限する方法についてまとめたものです。Windows 10上のHyper-Vで確認したものですが、Windows Serverでも同様です。
この拡張ACLは便利ですが、Microsoftのページを含む公開情報では欲しい説明を探しづらく、仕様把握に手間取りました。事前に知っておきたかったと思うポイントを整理しておきます。

本記事の目的

  • Hyper-V環境で拡張ACLの使用方法を把握する。

基本

拡張ACLの概要とユースケース

  • 概要

    • Hyper-Vホスト上のWindowsファイアウォールは、ゲストの通信に対しては適用されません。そのため、ゲストの通信をホスト側で制限したい場合にはAdd-VMNetworkAdapterExtendedAclのような別の設定が必要です。
    • Add-VMNetworkAdapterExtendedAclは、Hyper-V上の各仮想ネットワークアダプタに対し、アクセス制御ルール(ACL)を作成するコマンドレットです。Add-VMNetworkAdapterAclACLと対比する場合等、"拡張ACL"と呼ぶこともあります。
    • IPアドレスやポート番号によるACLを作成可能です。
    • 簡易的な実装ではあるものの、各ゲストOS内の設定でなくホスト側で集中的にアクセス制御できる利点があります。
    • 拡張ACLは、初期状態では未定義であり、ゲストの通信は全て許可されます。
    • 仮想スイッチの種類に関わらず拡張ACLを使用可能です。補足事項は後述します。
    • NAT(WinNAT)の有無に関わらず、拡張ACLを使用可能です。
    • 仮想マシンごと(仮想ネットワークアダプタごと)に定義が必要です。便利な一括設定の方法については後述します。

  • ユースケース
    以下のように、トラブル防止等の理由により、Add-VMNetworkAdapterExtendedAclを使用できます。

    • そのHyper-V環境をテストや検証のために使用する際、Hyper-Vの外にある本番環境に影響を与えないようにしたい
      • ゲストから特定のネットワーク以外に対する通信を遮断したい
      • あるいは、逆に特定のネットワークに対する通信を遮断したい
    • ゲストOSのローカルファイアウォール設定だけでなく、追加の対策としてホスト側でも通信を制限しておきたい
    • ネットワーク側のファイアウォール設定では都合がよくない
    • セキュリティポリシー上、ゲストに許可する通信を必要最低限の範囲に制限しておきたい

設定例

例として、以下の図に示すアクセス制御を実現するACLを設定してみます。

例として設定する拡張ACL
設定する拡張ACLの例

例1 (基本的な定義)

Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -Weight 1 …(1)
Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Inbound -VMName "VM1" -Weight 1 …(1')

Add-VMNetworkAdapterExtendedAcl -Action Deny -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.0/16 -Weight 10 …(2)
Add-VMNetworkAdapterExtendedAcl -Action Deny -Direction Inbound -VMName "VM1" -RemoteIPAddress 172.16.0.0/16 -Weight 10 …(2')

Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -RemoteIPAddress 192.168.0.0/24 -Weight 11 …(3)
Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Inbound -VMName "VM1" -RemoteIPAddress 192.168.0.0/24 -Weight 11 …(3')

Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.1/32 -RemotePort 53 -Protocol TCP -Weight 21 -Stateful $True …(4)
Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.1/32 -RemotePort 53 -Protocol UDP -Weight 22 -Stateful $True …(4')

Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.2/32 -RemotePort 443 -Protocol TCP -Weight 23 -Stateful $True …(5)

図中のVM1という仮想マシンに対してACLを設定します。

  • (1)、(1') デフォルトアクション/社外ネットワーク(インターネット)との通信

    • 他のどのACLにもマッチしない場合に適用するACLです。IPアドレスやポート番号の指定はありません。
    • -Weight 1は最後に評価されるACLという意味です。
    • 今回の例ではインターネット向けの通信を許可するため、-Action Allowとしています。拒否したい場合は-Action Denyを指定します。
    • 例なので明示的に定義していますが、この許可ACLは定義しなくても動作に変わりはありません(デフォルトでマッチするACLが無ければ許可されるため)。
      • デフォルトで拒否したい場合には、-Action DenyACL定義が必要です。
    • なお今回の例では、仮想マシンは社外に公開するサービスが無く、社外から仮想マシンに対する通信は社外向けファイアウォールにより遮断されることを前提にしています。

  • (2)、(2') 社内ネットワーク(172.16.0.0/16)との通信

    • 社内ネットワーク(172.16.0.0/16)に対する通信を拒否するACLです。
    • -Weightは10なので、-Weightが1~9のACLより優先されます。逆に-Weightが11以上のACLはこのACLより優先されます。

  • (3)、(3') Hyper-V内ネットワーク(192.168.0.0/24)との通信

    • Hyper-V内ネットワーク(192.168.0.0/24)に対する通信を許可するACLです。
    • 例なので明示的に定義していますが、この許可ACLは定義しなくても動作に変わりはありません(マッチするACLが無ければ許可されるため)。
      • (1)のデフォルトアクションが拒否である場合、このような個別の許可ACLの定義が必要です。

  • (4)、(4') DNSサーバ(172.16.0.1)との通信

    • DNSサーバ(172.16.0.1)に対する通信を許可するACLです。
      • (2)の拒否ACLよりこのACLが先に評価されるよう、-Weightの値を10より大きな値にしてあります。
    • DNSの通信ポート(53)を指定してあります。
      • DNS通信なのでTCPUDPの両方を許可します。
      • 同じポート番号ですが、-Protocol TCP-Protocol UDP、それぞれ定義が必要です。理由は後述します。
    • -Stateful $Trueにて、ステートフルなアクセス制御となるよう指定します。
      • このACL 1つで、DNSサーバに対する行きパケットが許可されると、その戻りパケットも自動的に許可されます。
      • -Direction Inboundの方向の拒否ACLが無い場合は、戻りパケットを許可する必要性が無いため、-Stateful $Trueの指定は不要です。

  • (5) Webサーバ(172.16.0.2)との通信

    • Webサーバ(172.16.0.2)との通信を許可するACLです。
    • (4)と同様ですが、HTTPSなのでTCPのみの定義です。

例2 (省略した定義)

次に、例1からできるだけACLを省略した場合の例を記載します。

以下のいずれかに該当する場合、Hyper-Vの外のネットワークとの通信に関する-Direction Inboundの方向の拒否ACLは不要です。

  • 仮想マシンがNAT(WinNAT)の有効な仮想ネットワーク配下にある場合
  • NAT以外の仮想ネットワーク構成で、Hyper-Vの外から仮想マシンに対する通信を一律許可したい場合

省略しても動作に変わりのないACLを省略、さらに-Direction Inboundの方向の拒否ACLを省略すると、以下のようになります。

Add-VMNetworkAdapterExtendedAcl -Action Deny -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.0/16 -Weight 10 …(2)

Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.1/32 -RemotePort 53 -Protocol TCP -Weight 21 -Stateful $True …(4)
Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.1/32 -RemotePort 53 -Protocol UDP -Weight 22 -Stateful $True …(4')

Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "VM1" -RemoteIPAddress 172.16.0.2/32 -RemotePort 443 -Protocol TCP -Weight 23 -Stateful $True …(5)

かなりシンプルになります。仮想スイッチの構成にもよりますが、図に記載のアクセス制御を実現するだけであれば、この定義で十分です。
(2')のInbound方向のACLを定義していないので、(4)~(5)の-Stateful $Trueは省略可です。

詳細

仮想スイッチの種類ごとの拡張ACLの適用

どの仮想スイッチを使用していても拡張ACLは適用できますが、考慮するポイントが少しずつ違うので整理しておきます。

なお、New-VMSwitchにより個別に作成した仮想スイッチでも使用可能です。

コマンドレット説明

Add-VMNetworkAdapterExtendedAcl

以下のように実行できるコマンドです。

Add-VMNetworkAdapterExtendedAcl -Action Allow -Direction Outbound -VMName "仮想マシン名" -RemoteIPAddress x.x.x.x/x -RemotePort x -Protocol x -Weight x -Stateful $True

主要なオプションは以下です。

  • -Action(必須)

    • パケットが条件にマッチした際のアクションです。
    • 指定可能な値は、Allow(許可)、Deny(拒否)のいずれかです。

  • -Direction(必須)

    • そのACLを適用するパケットの方向です。
    • 指定可能な値は、Inbound、Outboundのいずれかです。
    • 省略時に両方向に適用されてくれたりすると定義をシンプルにできるのですが、残念ながら必須オプションです。

  • -Weight(必須)

    • ACLエントリに対する優先度指定です。大きな値のACLが先に適用されます。
      • いったんACLがパケットに適用されると、そのパケットには他のACLエントリは適用されません。
    • 指定可能な値は、1以上の整数です(型はINT32のようです)。
      • 大規模なACL設計でなければ、例えば1~100程度でも十分でしょう。
    • 一般的なファイアウォールのルールと同様に考えると良いでしょう。
      • ACLの数が多い場合には、狭いスコープの条件から広いスコープの条件の順に優先されるよう定義する等、設計上のポリシーを決めておくと良いです。

  • -LocalIPAddress-RemoteIPAddress(任意)

  • -LocalPort-RemotePort(任意)

    • そのACLを適用するポート番号です。TCPUDPに対して適用できます。
    • -LocalPort仮想マシン側のポート番号、-RemotePortがその通信先のポート番号です。
    • 指定可能な値は、以下のいずれかです。
      • "443"のように単一のポート番号
      • "49152-49182"のようにポート番号の範囲
    • 省略時は全てのポート番号が対象になります。

  • -Protocol(任意)

  • -Stateful(任意)

    • ステートフルなアクセス制御とするかどうかを指定します。
      • -Stateful $Trueを指定した許可ACLは、そのACL 1つで行きパケットが許可されると、その戻りパケットも自動的に許可されます。
    • 指定可能な値は、Bool値です(PowerShellの"$True"や"$False"を指定可能)。
    • -Statefulを指定する際には、-Protocolの指定が必須のようです。詳細は後述します。
    • 省略時はステートフルなアクセス制御を行いません。

  • -IdleSessionTimeout(任意)

    • 無通信タイムアウトを秒単位で指定します。
    • 指定可能な値は、1以上の整数です(型はINT32のようです)。
    • 省略時は255が設定されるようです(Get-VMNetworkAdapterExtendedAclの結果より)。

Get-VMNetworkAdapterExtendedAcl

以下のように実行できるコマンドです。

`Get-VMNetworkAdapterExtendedAcl -VMName "仮想マシン名"

定義済みのACLの内容を出力します。

以下、出力例です(一部省略してあります)。 デフォルトで仮想マシン(仮想ネットワークアダプタParentAdapter)ごとにソートはされるようです。

Direction          : Outbound
Action             : Allow
LocalIPAddress     : ANY
RemoteIPAddress    : 172.16.0.1/32
LocalPort          : ANY
RemotePort         : 53
Protocol           : TCP
Weight             : 21
Stateful           : True
IdleSessionTimeout : 255
IsolationID        : 0
ParentAdapter      : VMNetworkAdapter (Name = 'ネットワーク アダプター', VMName = 'VM1') [VMId = 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx']
IsTemplate         : False
CimSession         : CimSession: .
ComputerName       : DESKTOP-XXXXXX
IsDeleted          : False

…

Direction          : Outbound
Action             : Allow
LocalIPAddress     : ANY
RemoteIPAddress    : 192.168.0.0/24
LocalPort          : ANY
RemotePort         : ANY
Protocol           : ANY
Weight             : 11
Stateful           : False
IdleSessionTimeout : 0
IsolationID        : 0
ParentAdapter      : VMNetworkAdapter (Name = 'ネットワーク アダプター', VMName = 'VM1') [VMId = 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx']
IsTemplate         : False
CimSession         : CimSession: .
ComputerName       : DESKTOP-XXXXXX
IsDeleted          : False

…

Direction          : Inbound
Action             : Allow
LocalIPAddress     : ANY
RemoteIPAddress    : 192.168.0.0/24
LocalPort          : ANY
RemotePort         : ANY
Protocol           : ANY
Weight             : 11
Stateful           : False
IdleSessionTimeout : 0
IsolationID        : 0
ParentAdapter      : VMNetworkAdapter (Name = 'ネットワーク アダプター', VMName = 'VM1') [VMId = 'xxxxx-xxxxx-xxxxx-xxxxx-xxxxx']
IsTemplate         : False
CimSession         : CimSession: .
ComputerName       : DESKTOP-XXXXXX
IsDeleted          : False

Remove-VMNetworkAdapterExtendedAcl

以下のように実行できるコマンドです。

特定のACLを1つ削除する場合は、-Direction-Weightを指定して実行します。
Remove-VMNetworkAdapterExtendedAcl -VMName "VM1" -Direction InBound -Weight 23

その仮想マシンに紐づくACLを全て削除する場合は、ACLをオブジェクトで渡して実行します。
Get-VMNetworkAdapterExtendedAcl -VMName "VM1" | Remove-VMNetworkAdapterExtendedAcl

注意点として、ACLの削除が成功しても失敗しても何も出力されません。このコマンドを実行する前後でGet-VMNetworkAdapterExtendedAclの結果をテキストに保存しておき、差分チェックすると安心です。

-Stateful $True指定時に-Protocol指定が必須な理由と対処

Microsoftのページに記載は見当たりませんが、Add-VMNetworkAdapterExtendedAclでは、-Statefulを指定する際、-Protocolの指定が必須のようです。

その理由として、-Protocolの省略時は、全てのIPベースのプロトコルが対象となるようですが、このときTCPUDP以外の-Statefulに対応できないプロトコルも対象になってしまうためと思われます。例えば拡張ACLでは、ICMPに対して-Statefulを指定できないので、行きと戻り両方のパケットにACLを適用する場合には、InboundとOutboundの両方の定義が必要です。

この動作により、DNS等、TCPUDPで同じポート番号を使用するプロトコルにステートフルなACLを適用する場合に配慮が必要となります。
具体的には、-Protocol TCPACLと、-Protocol UDPACLをそれぞれ定義することになります。
これは、-Protocolを省略すると-Stateful指定はできないという点、また-ProtocolTCPUDPの2つを指定することができないという点から、結果的にACLを複数定義する必要性があるということです。

拡張ACLは、一般的なファイアウォールに比べると簡易的な実装ではあるので、このあたりは注意して使うしかないでしょう。

Add-VMNetworkAdapterAclとAdd-VMNetworkAdapterExtendedAclの違い

Add-VMNetworkAdapterAcl(ACLの追加)とAdd-VMNetworkAdapterExtendedAcl(拡張ACLの追加)は、異なるコマンドレットです。
異なるACLを扱います。併用すべきではないでしょう。混在させた場合の動作は不明です。

後者の拡張ACLが新しい機能です。Windows Server 2012 R2から使用できるようになったようです。

前者のACLは、ポート番号を指定したACLやステートフルなACLを作成できません。ACL自体に優先度指定は無く、最長マッチしたACLが優先的に適用されます。

後者の拡張ACLの方が多機能です。ポート番号を指定したACLやステートフルなACLを作成できます。ACLごとに優先度指定(-Weight)が可能です。ただしMACアドレスベースのアクセス制御に関しては前者のACLにのみ備わっているようです。IPベースのACLと言えるでしょう。

また参考までに、構成によってはSCVMM経由で拡張ACLの管理ができるようです(portACL)。

拡張ACLの一括設定

仮想マシンを対象に拡張ACLを一括設定

拡張ACLは全仮想マシンに適用されるグローバルな定義を設定できません。

代替手段として、全仮想マシンの仮想ネットワークアダプタを対象に、一括設定する方法があります。

Get-VMNetworkAdapter -vmname "*" | Get-VMNetworkAdapterExtendedAcl > "C:\any\path\before.txt"

Get-VMNetworkAdapter -vmname "*" | Add-VMNetworkAdapterExtendedAcl …
Get-VMNetworkAdapter -vmname "*" | Add-VMNetworkAdapterExtendedAcl …
…(定義したい分、繰り返す)…

Get-VMNetworkAdapter -vmname "*" | Get-VMNetworkAdapterExtendedAcl > "C:\any\path\after.txt"
  • 全ての仮想マシン("*")を対象にGet-VMNetworkAdapterコマンドレットを実行して得られる仮想ネットワークアダプタのオブジェクトを、Add-VMNetworkAdapterExtendedAcl等にパイプで渡すと、一括で処理してくれます。

  • 例えば、仮想マシンを追加した際に実行するバッチとして準備しておくことで、全ての仮想マシンに対して一律同じ設定を維持できます。

  • なお、繰り返し全ての仮想マシンを対象にAdd-VMNetworkAdapterExtendedAclを実行すると、追加しようとするACLと同じACL(同じ-Direction-Weight)が既に存在することになります。この場合、そのACLの追加に関してはAdd-VMNetworkAdapterExtendedAclがエラーとなりますので、重複した内容のACLが登録されることはありません。ACLが未設定の仮想ネットワークアダプタに対してのみ追加されます。
    言い換えると、Add-VMNetworkAdapterExtendedAclACLの上書きをしません。

仮想マシンを対象に拡張ACLを一括削除

同様に、全仮想マシンの仮想ネットワークアダプタを対象に、既に定義されている拡張ACLを一括削除する方法です。

Get-VMNetworkAdapter -vmname "*" | Get-VMNetworkAdapterExtendedAcl  | Remove-VMNetworkAdapterExtendedAcl
もしくは
Get-VMNetworkAdapterExtendedAcl -VMName "*" | Remove-VMNetworkAdapterExtendedAcl

(参考)ホストWindows側の仮想ネットワークアダプタに対するACL設定

あまりユースケースが無さそうですが、ホストWindows側の仮想ネットワークアダプタに対してACL設定することもできるようです。
-ManagementOSオプションを使用します。このサイトに例が載っています。拡張ACLでなくVMNetworkAdapterACLの方ですが、拡張ACLでも-ManagementOSオプションは使用可能です。

以下、Add-VMNetworkAdapterAclで試した際のメモです。

参考URL等

ipv6.methodにおけるdisabledとignoreの違い(NetworkManager、IPv6無効化)

概要

基本的にIPv6対応できるようシステム運用すべきなのですが、事情によりIPv6を無効化しないといけない場合もあります。無効化の方法は多様ですが、その方法の1つとしてNetworkManager経由(nmcli等)による設定が挙げられます。
本記事は、NetworkManager経由でIPv6を無効化する手順や、その際に使用するipv6.methodパラメタにおける"disabled"と"ignore"の違いについてまとめたものです。対象は主にRHEL7、CentOS7以降です。

※システムのIPv6対応は計画的に進めましょう。

本記事の目的

  • LinuxにおけるIPv6の無効化手順の概要を把握する。
  • NetworkManager経由でIPv6を無効化する手順や、その際に使用するipv6.methodパラメタにおける"disabled"と"ignore"の違いを把握する。

基本

NetworkManager経由でIPv6を無効化する手順

nmcliコマンドを使用した手順を記載します。

# nmcli connection mod (device名) ipv6.method disabled  
# nmcli connection up (device名)  
# ip address show (device名)

指定したdeviceに対し、ipv6.methodパラメタの値を"disabled"に変更後、connection upで反映します。
基本的に"disabled"で良いと思われますが、"ignore"との違いについては後述します。
反映後は、ip address show実行時にinet6のアドレスが表示されないことで、そのインタフェースにIPv6アドレスが割り当てられていないことを確認します。

なお、(device名)の部分は、"eth0"や"ens192"等を指定します。
その環境で認識されているdevice名を確認する場合は、# nmcli connection show# nmcli device statusを実行します。

NetworkManager関連のパラメタ設定状況を確認する場合は、# nmcli connection show (device名)です。

ipv6.methodにおける"disabled"と"ignore"の違い

"disabled"の方が、"ignore"より強力な無効化設定です。

  • "disabled"
    そのネットワークデバイスに対するIPv6設定を行いません。さらに、同デバイスに対するカーネルパラメタdisable_ipv6に"1"が設定されるため、そのデバイスIPv6自体を使用不可にします。
    /proc/sys/net/ipv6/conf/(device名)/disable_ipv6(net.ipv6.conf.(device名).disable_ipv6)の値のことです。

  • "ignore"
    そのネットワークデバイスに対するIPv6設定を行いません。カーネルパラメタは変更されないので、NetworkManager以外の方法でネットワークデバイスに対するIPv6設定をすることは可能です。
    内部的にIPv6スタックは有効な状態のままという意味です。

よって、「そのネットワークデバイスIPv6が動作しないようにしたい」という意味では、"disabled"が安心です。

詳細

(一般的な話)ネットワーク設定方法の選び方

IPv6の無効化手順として、本記事ではNetworkManagerを使用した方法を記載していますが、他にも色々な方法があります。
より根本的に無効化したい場合は、カーネルパラメタやgrubの設定といった方法が考えられます(カーネルパラメタのnet.ipv6.conf.all.disable_ipv6 = 1やnet.ipv6.conf.default.disable_ipv6 = 1、grubipv6.disable=1やipv6.disable_ipv6=1等)。

Linuxのネットワーク設定方法としては、以下のような種類が挙げられます。

上から、管理ツール(ユーザインタフェース)寄りの設定方法、下にいくほどカーネル寄りで内部的な設定方法と言えます。

標準でNetworkManagerを採用するLinuxディストリビューションでは、基本的にNetworkManager経由での設定が推奨されていると思います。
逆に、NetworkManagerを使用するのであれば、network-scriptを直接変更することは避けましょう。
NetworkManagerで調整できない設定については、カーネルパラメタやカーネル起動時のパラメタを使用する必要性があります。

ネットワーク設定に限らず、システムを運用する上で、どの設定方法を優先して使用するか決めておくと、構成管理や作業管理の品質を確保しやすくなります。

"disabled"と"ignore"に関するマニュアル等の記載

ipv6.methodで指定可能な値は、"auto"(デフォルト)、"dhcp"、"disabled"、"ignore"、"link-local"、"manual"、"shared"です。

$ man nm-settings-nmcliにて、ipv4.methodipv6.methodに指定可能な値についての記載があります。

method IP configuration method. NMSettingIP4Config and NMSettingIP6Config both support "disabled", "auto", "manual", and "link-local". See the subclass-specific documentation for other values. … https://developer-old.gnome.org/NetworkManager/stable/nm-settings-nmcli.html#nm-settings-nmcli.property.ipv4.method

"disabled"は明記されていますが、"ignore"については記載されていないので、別ドキュメントを参照する必要性がありそうです("See the subclass-specific documentation for other values.")。

うまくドキュメントを辿れなかったのですが、おそらくnm-setting-ip6-config.hにある以下の説明が該当しそうです。

/* * NM_SETTING_IP6_CONFIG_METHOD_IGNORE: * * IPv6 is not required or is handled by some other mechanism, and NetworkManager * should not configure IPv6 for this connection. / https://github.com/heftig/NetworkManager/blob/master/libnm-util/nm-setting-ip6-config.h

"ignore"は、IPv6が不要であるか、他の機能によって制御される場合を想定した値のようです。

ipv6.methodを変更した際のカーネルパラメタの変化

ipv6.methodを変更した際のカーネルパラメタの変化を確認してみます(network-scriptの方への影響は確認していません)。

  • ipv6.methodが"auto"の場合(デフォルト)
# cat /proc/sys/net/ipv6/conf/ens192/disable_ipv6
0
  • ipv6.methodが"disabled"の場合
# nmcli connection modify ens192 ipv6.method disabled
# nmcli connection up ens192
# cat /proc/sys/net/ipv6/conf/ens192/disable_ipv6
1
  • ipv6.methodが"ignore"の場合
(いったんautoに戻してから確認)
# nmcli connection modify ens192 ipv6.method auto
# nmcli connection up ens192
# cat /proc/sys/net/ipv6/conf/ens192/disable_ipv6
0

# nmcli connection modify ens192 ipv6.method ignore
# nmcli connection up ens192
# cat /proc/sys/net/ipv6/conf/ens192/disable_ipv6
0
  • (参考)ipv6.methodの値を変更しても、全デバイスを対象(all)としたnet.ipv6.conf.all.disable_ipv6の値は影響を受けない
# cat /proc/sys/net/ipv6/conf/all/disable_ipv6
0

参考URL等

Chronyによる時刻同期ノウハウ2(複数NTPサーバ指定時、NTPサーバ移行)

概要

Chronyは、RHEL7、CentOS7以降におけるデフォルトの時刻同期機能(NTP実装)です。従来はntpdがありました。
本記事は、Chronyにおいて複数のNTPサーバを指定する場合についてまとめたものです。主に、RHEL7、CentOS7以降でOS標準のChronyを使用した環境を対象としていますが、基本的にはどのシステムでも共通です。

Chronyの基本的なノウハウについては、別記事に記載してありますので、本記事は少し応用的な内容です。

本記事の目的

  • Chronyにおいて複数のNTPサーバを指定する。
  • 複数のNTPサーバ指定により参照設定を冗長構成とする際のポイントを把握する。
  • NTPサーバを移行する際のシナリオを検討する。

基本

参照先NTPサーバの指定(serverとpoolの違い)

Chronyでは参照先NTPサーバの指定方法として、serverpoolの2種類の設定(ディレクティブ)があります。

どちらもほぼ同じ動作が可能であり、大きな違いはありません。
基本的にはserverで十分です。ntpdと同様の指定方法なので、経験的に慣れてらっしゃる方も多いでしょう。
ポイントとしては、同期先として指定するNTPサーバのDNS登録名(ホスト名、FQDN)を1つにまとめて運用したい場合は、poolを使用すべきです。
これは、NTPサーバのリプレース時の移行シナリオとも関連します(後述)。

  • serverディレクティブ

    • server ntp-server1.domain.comのように、NTPサーバを指定します。
    • 複数のNTPサーバを指定する場合、各NTPサーバについてserver行を分けて記載します。
    • 指定したNTPサーバを名前解決した際に、複数のIPアドレスが得られた場合、そのうちの1つだけを時刻ソースとして扱います。
  • poolディレクティブ

    • pool pool.ntp-servers.domain.comのように、プール(=NTPサーバ(群))を指定します。
    • 複数のプールを指定する場合、各プールについてpool行を分けて記載します。
    • 指定したNTPサーバを名前解決した際に、複数のIPアドレスが得られた場合、それら全てを時刻ソースとして扱います(ただしデフォルトでmaxsourcesオプションで指定された最大4つまで)。
      • 名前解決時に複数のIPアドレスが得られる環境での使用を想定したディレクティブです。
      • 例: pool.ntp.orgに登録されているプールである"jp.pool.ntp.org"を名前解決すると、以下の4つのIPアドレスが得られます。これらは全てNTPサーバのIPアドレスです。このような名前をpoolとして設定することになります。
        162.159.200.1
        133.243.238.163
        162.159.200.123
        133.243.238.243
  • serverディレクティブとpoolディレクティブ共通

    • 複数の時刻ソースがある場合、そのうちの1台と同期します(selected source)。
    • 同期していたNTPサーバが使用不可になった場合の動作は後述します。
    • 同期している時刻ソース以外の時刻ソースも同期処理に組み込まれ、同期精度の向上に使用される動作(combining algorithm)については後述します。

マニュアルに設定例が記載されています。

なお、指定したNTPサーバやプールの名前解決の結果、Aレコード(IPv4)以外にAAAAレコード(IPv6)が得られた場合、そのIPv6アドレスも時刻ソースとして扱われます。IPv6通信環境が整っていない場合には注意が必要です。

NTPサーバが使用不可となった場合の動作

  • NTPサーバのIPアドレス変更
    NTPサーバのIPアドレス(DNSレコードに登録されたIPアドレス)は変更されることがあるという前提でchronydは動作します。

    • 時刻ソースは、直近8回のリクエストに対して有効な応答が得られなかった場合、その時刻ソースは名前解決し直したIPアドレスに置き換えられます(参考:chronyc refresh)。
    • 同期していたNTPサーバ(selected source)が使用不可になった場合も、名前解決し直したIPアドレスに置き換えられます。
      使用不可とは、直近8回のリクエストに対して有効な応答が得られなかった(unreachable)、正しくない時刻ソースとみなされた(falseticker)、distanceが大きくなりすぎた等です。この置き換えは、多くても30分に1回程度です。
      この動作は、serverディレクティブに関する説明ですが、poolでも同様と思われます。
    • 名前解決を強制的に再実行するには、chronyc refreshコマンドを実行します。
    • 同期対象としていたNTPサーバのDNSレコードが変更された場合も、変更前のNTPサーバが所定の基準を満たして利用可能なままであれば、chronydはそのNTPサーバを同期対象として使用し続けます。
      • serverディレクティブの場合、chronyc sourcesコマンドでは、変更前のIPアドレスだけがソースとして見えた状態になります。
      • poolディレクティブの場合、chronyc sourcesコマンドでは、変更前と変更後のIPアドレスの両方がソースとして見えた状態になります(定期的に名前の再解決をしているようです)。
  • NTPサーバの障害等を含む停止時の動作は以下の通りです。

    • 前述の通り、NTPサーバのIPアドレス変更を例に挙げましたが、NTPサーバ側の障害等によりそのNTPサーバと通信不可になった場合も同様の動作です。
    • 名前解決の結果に変更が無かったとしても、他に利用可能な時刻ソースがあればそれを使用するよう再選択されます。
    • なお、同期対象のソース(best source)が利用不可になった場合には、次に最善の時刻ソースが選択されます。
      ただし、所定のアルゴリズムに従い、切り替えまで時間がかかる場合があります(3.7. An unreachable source is selected?))。

NTPサーバの移行シナリオ

名前引継ぎによるNTPサーバ移行を前提に記載します。NTPサーバのDNS上の名前を変更せず、そのDNSレコードに登録されたIPアドレスを新しいNTPサーバのものに変更する移行のことです。
新しい名前を用意する場合については省略しますが、NTPクライアント側で設定変更が必須になります。

前述の通り、NTPサーバのIPアドレス(DNSレコードに登録されたIPアドレス)は変更されることがあるという前提でchronydは動作します。 よって、NTPクライアントとして動作するChronyで、NTPサーバの移行に際して特別な対応は不要です。

その上で、さらに万全を期す場合には、以下のようなシナリオが考えられます。

  • 旧NTPサーバを稼働させたまま(平行稼働)、DNSレコードのIPアドレスを新NTPサーバのものに変更する。
  • poolディレクティブでNTPサーバを指定するNTPクライアント
    新NTPサーバの稼働後、既存NTPクライアント側でchronyc -n sourcesコマンドを実行して新NTPサーバのIPアドレスが時刻ソースとして表示されていることを確認の上、安全なタイミングでchronyc delete (旧NTPサーバのIPアドレス)を実行し、参照先NTPサーバを切り替える。
  • serverディレクティブでNTPサーバを指定するNTPクライアント
    新NTPサーバの稼働後、安全なタイミングで既存NTPクライアント側でchronyc refreshコマンドを実行し参照先NTPサーバを切り替える。
  • 想定外の状況に備え、chronyc reselectコマンドの実行やchronydの再起動を実施可能な手順にしておく。

詳細は、本記事の詳細や、各種マニュアルを参照願います。

詳細

時刻ソースの選択(source selection)

chronydは、chrony.confのserverpoolで定義された各時刻ソースを名前解決し、その中から同期対象の時刻ソースを選びます。

同期対象として、chrony内部のアルゴリズム従い最も最適な時刻ソースが選ばれます。

時刻ソースは、以下のように分類されます。

  • 選択された時刻ソース:selected sources (*、+)

    • the best source (*)
      同期対象として選ばれた最適な時刻ソースです。
    • other sources selected for synchronisation, which are combined with the best source (+)
      最適な時刻ソース以外に同期対象として選ばれた時刻ソースです。
      最適な時刻ソースと共に時刻精度向上のための計算に組み込まれます(combining algorithm)。
  • 選択可能な時刻ソース:selectable sources (-)

    • 直近で通信可能(reachable)であり、かつ、falsetickerではないと判断された時刻ソースです。
    • selectable sourcesの中から選ばれたものが、selected sourcesとなります。
    • distanceの値が大きすぎる時刻ソースは、chronyc sourcesでは"-"と表示されますが、chronyc selectdataでは"D"と表示されます。
  • 選択不可能な時刻ソース:unselectable sources (?)

    • 通信不可(unreachable)、測定値不足等により、selectable sourcesにならなかったものです。

時刻ソース選択には時間がかかる場合があります。chronydの起動後やreselect後、時刻ソース選択が完了し同期対象の時刻ソース(*)決定するまでにかかる時間は、数秒から数分程度と思われます。

時刻ソース選択の状況は、chronyc sourceschronyc selectdataにて確認できます(後述)。

なお、最適な時刻ソースが変わった場合でも、頻繁に同期対象時刻ソースが切り替わらないよう、chronydはそれまで同期対象だった時刻ソースを引き続き利用するよう考慮されています。
選択アルゴリズムの調整方法として、chrony.confのreselectdistディレクティブ(デフォルト100ms)、reselectdistディレクティブ(デフォルト0.001s)、maxdistance(デフォルト3s)、maxjitter(デフォルト1s)等があります。

3台以上のNTPサーバを指定すべき

NTPクライアントは、最低3台以上のNTPサーバを指定すべきです。これは正しくない時刻ソースを適切に検出するためです。
例えば2台のNTPサーバを指定していた場合、正しくない時刻ソースがあった場合に、どちらが正しくない時刻ソースなのかを判定することは困難です。

開発元のFAQに記載があります。

ちなみに、poolディレクティブで指定可能なmaxsourcesオプションは、1つのpoolから使用可能な時刻ソースの最大数を定義するものですが、このオプションのデフォルトは4(定義可能な最大値は16)です。

4台程度の時刻ソースを指定しておくことが妥当なのでしょう。RedHat社のマニュアルでは、最低4つのNTPサーバの指定が推奨されています。

パブリックNTPサーバの情報を公開しているpool.ntp.orgにおいても、1つのpoolあたりに定義されているNTPサーバの数は4つのようです。

例:jp.pool.ntp.org

$ dig  0.jp.pool.ntp.org
…
;; ANSWER SECTION:
0.jp.pool.ntp.org.      0       IN      A       45.76.211.39
0.jp.pool.ntp.org.      0       IN      A       40.74.139.173
0.jp.pool.ntp.org.      0       IN      A       129.250.35.251
0.jp.pool.ntp.org.      0       IN      A       133.100.9.2

優先するNTPサーバの指定(serverとpoolのオプション)

serverディレクティブとpoolディレクティブにはオプションがたくさんあります(詳細は$ man chrony.conf)。
poolディレクティブでは、serverディレクティブで使用可能な全てオプションに加え、maxsourcesオプションを使用可能です。

ここでは、NTPサーバを複数指定した際の優先設定についてのみ、記載します。

  • prefer
    他の時刻ソースより、このオプションが指定されたソースを優先的に使用します。

  • trust
    指定した時刻ソースが常に正しいものであるとみなします。
    trustオプションが付与された他の時刻ソースと一致しない場合にのみ、falseticker(正しくない時刻ソース)として扱われる場合があります。

  • require
    時刻同期に際し、このオプションが付与された時刻ソースが少なくとも1つは利用可能であることを必要とするオプションです。 利用可能(selectable)とは、直近で通信可能であり、かつfalsetickerとみなされていない(recently reachable and not a falseticker)である状態です。
    trustオプションと一緒に使用することにより、信頼のおける時刻ソースを同期対象に組み込むようにできます。
    requiretrustが付与された時刻ソースがある場合、他の時刻ソースはその時刻ソースと一致するものだけが使用されるようになります。

時刻ソースの選択状況の確認、管理

同期対象のNTPサーバを確認、管理したいときに使えるchronycコマンドのオプションがいくつかあります。
詳細は$ man chronycで確認できます。

また、同期状態を強制的に変更するケースとしては、NTPサーバ移行や、ネットワーク障害後の復旧が挙げられます。
ただ、chronydを再起動すれば済むケースも多いので、参考情報です。

時刻ソースの選択状況の表示(sources)

基本的なオプションです。

$ chronyc sources

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#* GPS0                          0   4   377    11   -479ns[ -621ns] +/-  134ns
^? foo.example.net               2   6   377    23   -923us[ -924us] +/-   43ms
^+ bar.example.net               1   6   377    21  -2629us[-2619us] +/-   86ms
The columns are as follows:

前述の通り、選択された時刻ソース(*、-)、最適可能な時刻ソース(-)、選択不可能な時刻ソース(\?)を確認できます。

NTPサーバをIPアドレスで表示(-n sources)

chronyc -n sourcesコマンドを実行すると、Name/IP address列の内容がIPアドレスで表示されます。DNS逆引きされません。
※"-n"は"sources"の前に記載する必要性があります。

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* 1.2.3.4                   2   6   377    23   -923us[ -924us] +/-   43ms
^+ 5.6.7.8                   1   6   377    21  -2629us[-2619us] +/-   86ms
※IPアドレスは実際のホストとは関係ありません。

小文字の"-n"でなく、大文字の"-N"の場合は、chrony.confでで定義されたホスト名やIPアドレスが表示されます。

NTPサーバの名前解決を強制実行(refresh)

chronyc refreshコマンドを実行すると、chrony.confで指定したNTPサーバの名前解決を強制的に再実行します。
$ man chronycでは、chronydが動作するホストが一時停止(サスペンド)後、別ネットワークに接続して復旧した場合が想定されています。

名前解決により、それまで同期対象だったIPアドレスとは別のIPアドレスを新たに取得した場合、新しい方が時刻ソースに加えられます。
serverディレクトリで指定した時刻ソースの場合、別のIPアドレスを新たに取得すると、新しい方が時刻ソースに加えられ、古い方は時刻ソースから消えます。
poolディレクトリの場合、それまで同期対象だった時刻ソースを引き続き利用可能であれば、同期対象の時刻ソースは変更されません。別のIPアドレスを新たに取得すると、新しい方が時刻ソースには加えられます。

なお、手動でchronyc refreshを実行しなくても、同期していたNTPサーバ(selected source)が使用不可になった場合、自動的にそのNTPサーバを名前解決し直したものに置き換えられます。
ただ、使用不可と判断されるのは8回のポーリングの後になるので、即時で置き換えたい場合には、このchronyc refreshコマンドを実行します。

同期対象のNTPサーバの再選択を強制実行(reselect)

chronyc reselectコマンドを実行すると、時刻ソースの選択アルゴリズムに従い同期対象とするNTPサーバ選択を強制的に再実行します。

chronydは、時刻ソースの切り替え多発を避けるため、既に同期しているNTPサーバが時間の経過とともに最適な時刻ソース(best source)ではなくなったとしても、そのNTPサーバと同期し続けます。
chronyc reselectコマンドは、最適な時刻ソースを強制的に選び直し、同期するNTPサーバを切り替えるために使用できます。

chronyc reselectにより、"*"や"+"だったソースがいったん"-"になり、その後"*"や"+"*が再決定されます(source selection完了)。

時刻ソースを強制削除、強制再選択(delete)

chronyc delete (時刻ソースのIPアドレス)コマンドを実行すると、それまで登録されていた時刻ソースを削除できます。

chronyc sourceコマンドの一覧から削除されます。
それまで同期対象だった時刻ソースとの時刻同期を強制的に解除したい場合にも使用できます。

chronyc refreshchronyc reselectchronyc offlineを実行しても、それまで同期対象だった時刻ソースを引き続き利用可能であれば、同期対象の時刻ソースは変更されないようです。chronydのサービスを再起動すれば解決しますが、サービス再起動したくない場合にはdeleteが有用です。

その他(selectdata)

  • chronyc selectdata
    時刻ソースの詳細を表示できます。

時刻ソースをたくさん登録してみた

動作把握のため、パブリックNTPサーバのプールを複数登録してみました。
※これは推奨する設定ではありません。NTPサーバ側の負荷にもなり得るので動作確認後すぐに設定解除済みです。

chrony.confに以下を記載し、chronydを再起動します。

pool  pool.ntp.org iburst
pool  0.pool.ntp.org iburst
pool  1.pool.ntp.org iburst
pool  2.pool.ntp.org iburst
pool  3.pool.ntp.org iburst

プール1つあたり4つのIPアドレスが登録されているので、名前解決により得られるNTPサーバのIPアドレス数は、4 × 5 = 20です。

まず$ chronyc -n sourcesで確認してみます。

2,3分で時刻ソースの選択(source selection)が終わったようです(messagesにもログあり)。
表示された時刻ソースは19件です(何らかの理由で1つ表示されていないです)。
S列に"*"や"+"のフラグがつきました。

同期対象の時刻ソース(*,+)については、時刻同期しているためLast sampleの値が小さいです(us:microseconds、ms:milliseconds)。 []の中の値が、前回の計測時点でのシステムクロックと時刻ソースとの間のオフセット(差異)です。

$ chronyc -n sources
MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^+ 133.243.238.243               1   6   377    51    -41us[  -41us] +/- 4313us
^- 162.159.200.1                 3   6   377    56    +51ms[  +51ms] +/-  157ms
^- 162.159.200.123               3   6   377    50    +51ms[  +51ms] +/-  151ms
^* 133.243.238.163               1   6   377    53    +76us[  +73us] +/- 4241us
^- 202.181.103.212               2   6   377     0   +142us[ +142us] +/-   15ms
^- 3.114.30.212                  2   6   377    49   -375us[ -375us] +/-   26ms
^+ 45.32.55.38                   2   6   377    50    -39us[  -39us] +/- 4782us
^- 116.91.118.97                 2   6   377    41  -5230us[-5230us] +/-   15ms
^- 40.74.139.173                 2   6   377    50   +570us[ +570us] +/-   31ms
^- 138.3.216.120                 2   8    41    46   -106us[ -106us] +/- 6147us
^- 122.215.240.52                2   6   377    52    +33ms[  +33ms] +/-   88ms
^- 18.180.64.47                  2   6   377    51    +39us[  +39us] +/-   33ms
^- 129.250.35.251                2   6   377    54  -2481us[-2483us] +/-   67ms
^- 122.215.240.51                2   6   377    55    +34ms[  +34ms] +/-   83ms
^- 129.250.35.250                2   6   377    56  -2483us[-2486us] +/-   75ms
^- 45.76.211.39                  2   6   377    54    +34us[  +31us] +/-   37ms
^- 194.0.5.123                   2   6   377    52    +11us[  +11us] +/-   26ms
^+ 133.130.121.141               2   6   377    53    -51us[  -54us] +/- 5482us
^? 133.100.9.2                   0   8     0     -     +0ns[   +0ns] +/-    0ns

次に$ chronyc selectdata -aで確認してみます。Name/IP Address列には、そのIPアドレスを逆引きした際に得られるNTPサーバの名前が表示されます。
selectdataを指定すると、より詳細なステータスを確認できます。

同期対象として選ばれたものは、国内と思われるサーバ(jpドメイン配下)が多いです。chronydにより計算されるdistance値の小さい時刻ソースが同期対象として選ばれますので、このようにネットワーク的に近いNTPサーバが選ばれやすいです。

S列に"D"があるものが多いです。これらは、distance値が大きすぎる時刻ソースです。同期対象としては選ばれません。
(maxdistanceディレクティブのデフォルト値である3秒より大きいということです)

ID#00000000XXは、まだ時刻ソースのIPアドレスが割り当てられていないエントリで、使用されないものです。

Intervalは、前回の測定からのインターバル時間の上下限(時刻ソース選択時点のdistance値を考慮した上でのオフセットを含む値)のようです。

$ chronyc selectdata -a
S Name/IP Address        Auth COpts EOpts Last Score     Interval  Leap
=======================================================================
+ ntp-a2.nict.go.jp         N ----- -----   10   1.0 -4242us +4286us  N
D time.cloudflare.com       N ----- -----   14   1.0  -101ms  +202ms  N
D time.cloudflare.com       N ----- -----   10   1.0  -100ms  +208ms  N
* ntp-b2.nict.go.jp         N ----- -----   11   1.0 -4123us +4301us  N
D sv1.localdomain1.com      N ----- -----   23   1.0   -15ms   +15ms  N
D ec2-3-114-30-212.ap-nort> N ----- -----    9   1.0   -19ms   +19ms  N
+ ipv4.ntp3.rbauman.com     N ----- -----    9   1.0 -5167us +5143us  N
D s97.GchibaFL4.vectant.ne> N ----- -----    0   1.0   -19ms +9531us  N
D 40.74.139.173             N ----- -----    9   1.0   -25ms   +26ms  N
D 138.3.216.120             N ----- -----  498   1.0  -271ms  +274ms  N
D 122x215x240x52.ap122.ftt> N ----- -----   53   1.0   -41ms  +108ms  N
D ap-northeast-1.clearnet.> N ----- -----   51   1.0   -42ms   +42ms  N
D y.ns.gin.ntt.net          N ----- -----   54   1.0   -83ms   +78ms  N
D 122x215x240x51.ap122.ftt> N ----- -----    0   1.0   -36ms  +104ms  N
D x.ns.gin.ntt.net          N ----- -----    1   1.0   -69ms   +64ms  N
D tama.paina.net            N ----- -----    0   1.0   -24ms   +24ms  N
M ID#0000000033             N ----- -----    0   1.0    +0ns    +0ns  ?
D any.time.nl               N ----- -----   63   1.0   -24ms   +24ms  N
M ID#0000000035             N ----- -----    0   1.0    +0ns    +0ns  ?
M ID#0000000036             N ----- -----    0   1.0    +0ns    +0ns  ?
M ID#0000000037             N ----- -----    0   1.0    +0ns    +0ns  ?
M ID#0000000038             N ----- -----    0   1.0    +0ns    +0ns  ?
+ mail1.marinecat.net       N ----- -----    1   1.0 -5305us +5077us  N
M 133.100.9.2               N ----- -----    0   1.0    +0ns    +0ns  ?

次に$ chronyc -n selectdata -aで確認してみます。Name/IP Address列には、その時刻ソースのIPアドレスが逆引きされずにそのまま表示されます。

$ chronyc -n selectdata -a
S Name/IP Address        Auth COpts EOpts Last Score     Interval  Leap
=======================================================================
+ 133.243.238.243           N ----- -----    1   1.0 -4242us +4285us  N
D 162.159.200.1             N ----- -----    5   1.0  -101ms  +202ms  N
D 162.159.200.123           N ----- -----    0   1.0  -100ms  +208ms  N
* 133.243.238.163           N ----- -----    2   1.0 -4122us +4300us  N
D 202.181.103.212           N ----- -----   14   1.0   -15ms   +15ms  N
D 3.114.30.212              N ----- -----    0   1.0   -19ms   +19ms  N
+ 45.32.55.38               N ----- -----    0   1.0 -5165us +5141us  N
D 116.91.118.97             N ----- -----   55   1.0   -30ms   +33ms  N
(以下略)

次に$ chronyc -N selectdata -aで確認してみます。"-N"を指定すると、Name/IP Address列には、その時刻ソースに対応するchrony.conf上で指定したNTPサーバの名前が表示されます。
"3.pool.ntp.org"が多いですが、ID#00000000XXのエントリがそのように表示されているだけのようです。

$ chronyc -N selectdata -a
S Name/IP Address        Auth COpts EOpts Last Score     Interval  Leap
=======================================================================
+ pool.ntp.org              N ----- -----    1   1.0 -4242us +4285us  N
D pool.ntp.org              N ----- -----    5   1.0  -101ms  +202ms  N
D pool.ntp.org              N ----- -----    0   1.0  -100ms  +208ms  N
* pool.ntp.org              N ----- -----    2   1.0 -4122us +4300us  N
D 0.pool.ntp.org            N ----- -----   14   1.0   -15ms   +15ms  N
D 0.pool.ntp.org            N ----- -----    0   1.0   -19ms   +19ms  N
+ 0.pool.ntp.org            N ----- -----    0   1.0 -5165us +5141us  N
D 0.pool.ntp.org            N ----- -----   55   1.0   -30ms   +33ms  N
D 1.pool.ntp.org            N ----- -----    0   1.0   -24ms   +26ms  N
D 1.pool.ntp.org            N ----- -----  448   1.0  -244ms  +247ms  N
D 1.pool.ntp.org            N ----- -----    2   1.0   -41ms  +108ms  N
D 1.pool.ntp.org            N ----- -----    0   1.0   -42ms   +42ms  N
D 2.pool.ntp.org            N ----- -----    3   1.0   -83ms   +78ms  N
D 2.pool.ntp.org            N ----- -----    4   1.0   -36ms  +104ms  N
D 2.pool.ntp.org            N ----- -----    5   1.0   -69ms   +64ms  N
D 2.pool.ntp.org            N ----- -----    3   1.0   -24ms   +24ms  N
M 3.pool.ntp.org            N ----- -----    0   1.0    +0ns    +0ns  ?
D 3.pool.ntp.org            N ----- -----    1   1.0   -24ms   +24ms  N
M 3.pool.ntp.org            N ----- -----    0   1.0    +0ns    +0ns  ?
M 3.pool.ntp.org            N ----- -----    0   1.0    +0ns    +0ns  ?
M 3.pool.ntp.org            N ----- -----    0   1.0    +0ns    +0ns  ?
M 3.pool.ntp.org            N ----- -----    0   1.0    +0ns    +0ns  ?
+ 3.pool.ntp.org            N ----- -----    1   1.0 -5286us +5080us  N
M 3.pool.ntp.org            N ----- -----    0   1.0    +0ns    +0ns  ?

最後に$ chronyc -n sourcestats -aで確認してみます。sourcestatsでは、別の情報が表示されます。

同期対象となっていた時刻ソースでは、OffsetStd Devの値が他のものに比べて小さいです(us:microseconds、ms:milliseconds)。

$ chronyc -n sourcestats -a
Name/IP Address            NP  NR  Span  Frequency  Freq Skew  Offset Std Dev
==============================================================================
133.243.238.243            13   9   777     -0.049      0.078    -47us  15us
162.159.200.1              23  12   25m     +0.919      2.576    +53ms 1336us
162.159.200.123            23  12   25m     +0.094      3.309    +52ms 1883us
133.243.238.163            23  11   25m     -0.001      0.038    +85us  19us
202.181.103.212             9   5   518     -0.059      0.130    +87us  14us
3.114.30.212               19  11  1168     +0.031      0.626   -501us 256us
45.32.55.38                22  13   23m     +0.045      0.068  +2388ns  33us
116.91.118.97              15   7   969     +0.169      0.632  -1244us 155us
40.74.139.173              18   8  1168     -1.854      0.166   -755us  63us
138.3.216.120               8   5   24m     -0.270      0.560   -249us 118us
122.215.240.52             23  10   25m     +0.098      0.132    +34ms  82us
18.180.64.47               23  11   25m     +0.217      0.551   +140us 294us
129.250.35.251             23  11   24m     +0.018      0.078  -2429us  43us
122.215.240.51             23  10   24m     -0.000      0.226    +34ms 121us
129.250.35.250             23  10   24m     +0.016      0.069  -2428us  38us
45.76.211.39               23  13   24m     -0.031      0.055    -17us  31us
ID#0000000033               0   0     0     +0.000   2000.000     +0ns 4000ms
194.0.5.123                 7   5   451     -0.100      0.704    -49us  45us
ID#0000000035               0   0     0     +0.000   2000.000     +0ns 4000ms
ID#0000000036               0   0     0     +0.000   2000.000     +0ns 4000ms
118.27.19.72               12   8   524     -0.077      0.280    -57us  35us
ID#0000000038               0   0     0     +0.000   2000.000     +0ns 4000ms
133.130.121.141            23  11   25m     -0.010      0.064    -61us  37us
133.100.9.2                 0   0     0     +0.000   2000.000     +0ns 4000ms

備忘用

  • 2.7. How can I improve the accuracy of the system clock with NTP sources?

    • The optimal polling interval depends mainly on two factors, stability of the network latency and stability of the system clock (which mainly depends on the temperature sensitivity of the crystal oscillator and the maximum rate of the temperature change).
    • For best stability, the CPU should be running at a constant frequency (i.e. disabled power saving and performance boosting). Energy-Efficient Ethernet (EEE) should be disabled in the network.
  • maxdistance

    • The distance estimates the maximum error of the source. It includes the root dispersion and half of the root delay (round-trip time) accumulated on the path to the primary source.
  • combinelimit

    • 同期対象ソースのdistanceにcombinelimitの値を乗じたものより小さい時刻ソースが、combine対象となる。
    • If the selected source was specified with the prefer option, it can be combined only with other sources specified with this option.
    • 0にすると1つのソースのみ使用される。conbine アルゴリズムが無効となる。

サービス再起動すると他のサービスも再起動する(Systemd,Requires)

概要

Systemdで依存関係を定義してあると、サービスを再起動した際、他のサービスも再起動します(当たり前ですが)。
本記事は、SystemdのRequiresディレクティブについて整理しておきたい点をまとめたものです。対象は主にRHEL7、CentOS7以降です。
なお、Systemdの基本的なサービス管理については、こちらの記事にまとめてあります。

本記事の目的

  • SytemdのRequiresディレクティブについて把握する。
  • Requires以外にWants,BindsToディレクティブについて把握する。

基本

サービス再起動すると他のサービスも再起動する動作

サービスA(例えばアプリケーション)とサービスB(例えばDB)があり、サービスAのユニットファイルに、Requires=(サービスB)が設定されているとします。

[サービスA] →(依存)→ [サービスB]
ということです。

このときの基本的な動作について記載します。

  1. サービスAの起動
    # systemctl start (サービスA) →サービスBも起動
    サービスAを起動すると、サービスBも起動されます。
    ※これがRequiresディレクティブの主な役割

  2. サービスBの再起動
    # systemctl restart (サービスB) →サービスAも再起動
    サービスBを再起動すると、サービスAも再起動されます。

  3. サービスBの停止
    # systemctl stop (サービスB) →サービスAも停止
    サービスBを停止すると、サービスAも停止されます。
    ※ただし、その後サービスBだけを起動しても、サービスAは起動しないので注意

  4. systemdを経由しないサービスBの停止
    →サービスAは停止しません。
    systemctlコマンドを使用せずにサービスBが停止した場合に該当します。停止の理由は様々で、サービスBの仕様動作、不具合、関連デバイスの取り外し等が挙げられます。

Afterディレクティブとの関連性

サービスAのユニットファイルに、After=(サービスB)が記載されていると、前述の"1. サービスAの起動"や"2. サービスBの再起動"の際、サービスBの起動が完了してからサービスAの起動を開始します。
記載されていない場合、同時に起動開始されます。
例えば、サービス起動時にDB接続できないと起動失敗するアプリケーションの場合、Afterディレクティブの設定が必要でしょう。

詳細

関連ディレクティブ(Wants、BindsTo)

  • 依存関係の強さは弱いものから順に、Wants < Requires < BindsTo です。

  • 前述の"1. サービスAの起動"の動作のみでよければ、Requiresの代わりにWantsディレクティブを使用すべきです。

  • 前述の"4. systemdを経由しないサービスBの停止 "の際にもサービスAを停止させたい場合、Requiresの代わりにBindsToディレクティブを使用すべきです。
    BindsToで指定したユニットがactiveでない限り、自身のユニットはactiveにならないという設定です。

関連URL等

vCenterでファイルアップロード失敗「不明な理由で操作が失敗しました」

概要

vSphere Client(vCenterのWeb画面)にてデータストアにISOファイル等をファイルアップロードしようとすると、「不明な理由で操作が失敗しました」というエラーが発生することがあります。
本記事は、このエラーの対処方法についてまとめたものです。

本記事の目的

  • 「不明な理由で操作が失敗しました」のエラーに対処する。

目次

基本

現象

vSphere Client(vCenterのWeb画面)にてデータストアにISOファイル等をファイルアップロードしようとすると、以下のエラーが発生します。

不明な理由で操作が失敗しました。通常この問題は、ブラウザが証明書を信頼できない場合に発生します。自己署名証明書またはカスタム証明書を使用している場合は、下記の URL を新しいブラウザ タブで開いて証明書を受け入れてから、操作を再試行してください。

https://(ESXiサーバ)

問題が解決しない場合は、次のナレッジベースの記事で別の解決策を参照してください: http://kb.vmware.com/kb/2147256

対処

エラーメッセージにある通り、KB2147256に従い、接続元ブラウザにてルートCA証明書を信頼する設定を行うとエラーを回避できます。
その他の原因については後述します。

  1. vCenterのベースURLにアクセスします。
    例えば、https://vcenter.yourdomain.com/です。
    (https://vcenter.yourdomain.com/ui/のように、"…com/"の後に"ui/"のような文字がある場合、それを削除したURL)

  2. "信頼されたルートCA証明書をダウンロード"を選択します。

    vCenterのベースURL
    vCenterのベースURL

  3. ダウンロードしたzipファイルを解凍し、ルートCA証明書ファイルを確認します。
    "win"フォルダ配下の"xxxxxxxx.crt"というファイルがルートCA証明書です。
    ※ちなみに"lin"、"mac"、"win"という3つのフォルダがありますが、配下のファイルは拡張子が異なるだけで、中身は同一です。

  4. vSphere Clientを使用するブラウザにて、上記のルートCA証明書を信頼するよう設定します。
    Chromeの場合、設定画面(chrome://settings/security)のプライバシーとセキュリティセキュリティ証明書の管理から証明書の設定画面を開くことができます。
    ChromeやEdgeならOSの証明書ストア、FirefoxならFirefox専用の証明書ストアです。

  5. "証明書"画面にて、インポートを選択し、"証明書のインポートウィザード"を実行します。
    先ほど解凍した"xxxxxxxx.crt"ファイルを選択し、"信頼されたルート証明機関"にインポートします。
    "証明書ストアの選択"画面では、証明書の種類に基づいて、自動的に証明書ストアを選択するのままでも問題ないはずです。 確実に操作するなら、証明書をすべて次のストアに配置するから"信頼されたルート証明機関"を選択するのが良いです。

  6. "証明書"の"信頼されたルート証明機関"に、インポートしたルートCA証明書が表示されることを確認します。
    vCenterデフォルトのルートCA証明書は、発行者名称が"CA"となっており若干適当のようです。

    信頼されたルート証明機関に追加
    信頼されたルート証明機関に追加

  7. ブラウザのウィンドウを終了後、起動し直してから、vSphere Client(vCenterのWeb画面)にてデータストアにISOファイル等をファイルアップロードすると、エラー発生せず成功するはずです。

なお上記対処後は、ブラウザのURL欄の南京錠マークからvCenter画面の証明書を表示すると、証明書の警告が解消されていることが分かります。

ブラウザにてvCenter画面の証明書を確認
ブラウザにてvCenter画面の証明書を確認

証明書の検証にて問題なし
証明書の検証にて問題なし

詳細

原因の補足

エラーメッセージにある"https://(ESXiサーバ)"のURLから分かるように、ファイルのアップロード操作はvSphere ClientのURLへのアクセス(vCenterサーバとの通信)ではなく、アップロードしようとしているデータストアにアクセス可能なESXiサーバのうちいずれかのURLへのアクセスです。
vCenterは直接データストアにデータを書き込むことはできないため、このような実装になっているようです。

vSphere ClientにてvCenterにアクセスする際は、ルートCA証明書を信頼する設定をしていなくても証明書の警告を無視すればWeb画面を表示することができますが、このファイルのアップロード操作の際には、この証明書の警告を無視する操作ができないため、今回のエラーが発生していると思われます。

なお、vCenter環境では、vCenterサーバがルートCAとなり、vCenterおよび各ESXiサーバのHTTPSサービス用の証明書として、一律このルートCAから発行されたものが使用されるようです。

ルートCA証明書の登録で解決しない場合

なお、ルートCA証明書を正しく登録しても、このエラーを回避できない場合があります。
例えば、ブラウザを起動する端末にて、エラーメッセージにある"https://(ESXiサーバ)"の、"(ESXiサーバ)"部分の名前解決ができない場合です。この場合、"(ESXiサーバ)"のDNS登録状況、あるいは端末側のDNS設定やhosts設定の見直しが必要です。

オカムラ シルフィーなどの高級チェアを安く買う

概要

在宅勤務に際し、オカムラのシルフィーを購入したときの記録です。
IT系の仕事は基本的に座り続けるのでチェア選びは重要です。
本記事は働き方系の雑記として、チェア選び関連の情報をまとめます。シルフィーのことを中心に記載します。

シルフィーのカタログはこちらです。

目次

選び方

私が重視したポイントは以下です。

  • 1. 背面のサポート(腰回り~背すじ)
    • 身長175~180cm、体格細め、腰痛あり
  • 2. 通気性の良いメッシュ素材
  • 3. とりあえず高級チェアを自宅で使ってみたい

1. 背面のサポート(腰回り~背すじ)

細めの体型、腰痛もちなので、背もたれのフィット感を重視しました。

  • 腰回り~背すじのフィット感
    • シルフィーの特徴、背もたれのカーブを調整できるバックカーブアジャスト機構はかなり良いです。体型や姿勢に合わせて背中のフィット感を調整でき、体幹のグラつきを抑えます。
      他にはあまり無い機能なので、これを重視するならシルフィーが最適でしょう。
    • あと、オプションでランバーサポートを後付けしました。
    • また、シルフィーは背もたれの高さを、ハイバックとローバックから選べます。
      とりあえずハイバックの方がカッコよかったので、ハイバックにしました(背中全体でもたれかかることはあまり無いのと、ヘッドレスト(エクストラハイバック)も不要なので機能的にはローバックで十分でした)。

  • リクライニングの硬さを調整できる機能
    • もたれかかったときの背もたれの反発の強弱 or 固定の調整です。
      これはシルフィーでなくても、ある程度グレードのチェアには備わっています。

2. 通気性の良いメッシュ素材

蒸れるのが嫌なので、メッシュ素材のものを探しました。

  • 背もたれ
    • シルフィーの背もたれは、クッション素材とメッシュ素材から選べます。
    • 背もたれはメッシュ素材にしました。

  • 座面
    • シルフィーは、座面はクッション素材のみです。メッシュ素材はありません。
    • クッション素材の方が座り心地や耐久性は良いですが、座面のメッシュ素材を必須要件にする場合、他のチェアが候補になってきます(コンテッサアーロンチェア等、でも高いです)。

3. とりあえず高級チェアを自宅で使ってみたい

単に気持ちよく働くための投資です。
在宅勤務が本格化し、「どうせなら高級チェアを使ってみたい」と思いました。
…とは言うものの、いきなり10万円オーバーの新品チェアを買う勇気や予算も無かったので、手ごろな中古品を探しました。

買い方

本体とオプション

チェア本体は、予算内で目的のモデルが見つかれば即購入がオススメです。
本体選びで確定しないといけない部分は、主に以下です。

  • 背もたれの高さ(ハイバック/ローバック)
  • 脚の素材(樹脂/アルミ)

それ以外の部分は、オプションを後で買い足して自分で取り付けることも可能です。

  • ランバーサポート
  • ヘッドレスト
  • 肘置き(アジャストアーム/デザインアーム)

ちなみにアジャストアーム付きのものを購入しましたが、机の上でキーボードを操作し続けるためほぼ使いませんでした(外しました)。

チェア本体を安く買えるお店

  • サテライト
    私はここで買いました。
    オカムラのシルフィー (Sylphy)やサブリナ (Sabrina)がかなり安いです。
    (すぐ売れて在庫が無くなるのでマメにチェックすると良いかも)

  • オフィスバスターズ

    • 品揃え、在庫が多いです。急いでいたらこちらになりそうです。

チェアオプション

オプション全種類を常時取り扱っているお店は少ないですが、例えばランバーサポートだと以下のように売られています。


背もたれがクッション素材の本体にはランバーサポート取り付けはできません。
なお、ランバーサポートの取り付けは少しコツが要りました。

チェアマット

フローリングの部屋での使用が多いと思いますので、チェアマットは必須でしょう。マットが無いと床がキズだらけになります。
シルフィーのキャスターはよく転がるので、ツルツル素材ではなくカーペット素材の方を、あとは手入れが楽そうなものがおすすめです。


余談

私は、シルフィーを購入して快適に在宅勤務できるようになりました。
仕事の効率も上がった?かも知れません。

なお、他にも色々なメーカーのチェアがあります。
メーカー取り扱い店舗や、あるいは職場/近場の会議室等に、気になっている商品があれば現物を見てみましょう(会社にあるチェアの定価を調べてみると、意外と高かったりします)。

まずは実際に見て触って座って、自分に合った商品を探すのも楽しいと思います。
もちろんお店ならその場で購入もできます。

あと、今回のチェア選びで候補になっていたものは以下あたりです。
(次回買い替え時の備忘用に)