Windows上でのPuppetをトラブルシューティング

Included in Puppet Enterprise 2017.2.

ヒント

Process explorer

Process Explorerをインストールし、タスクマネージャと置き換えるように設定することを推奨します。 これにより、デバッグが大幅に簡単になります。

ロギング

puppetdログファイルからのメッセージをWindows Event Viewer経由で利用できます([Windows Logs] > [Application]を選択)。 デバッグを有効にするには、以下のようにPuppetサービスを停止して再起動します。

c:\>sc stop puppet && sc start puppet --debug --trace

PuppetのWindowsサービスコンポーネントも、同じlogディレクトリ内のwindows.logに記述し、サービスの問題解決に使用することができます。

よくある問題

インストール

Puppet MSIパッケージは、puppet.confファイルの既存のエントリを上書きします。 そのため、パッケージをアンインストールしてから、異なるPuppet masterホスト名を使って再インストールすると、Puppetは$confdir\puppet.confで新しい値を適用します。 インストール/アップグレード時には、必ず同じmasterホスト名を使用してください。

一般的に、アップグレード、アンインストール、再インストールの実行時には、システム上の設定データは保存されます。

システムを完全にクリーンアウトするには、必ずconfdirおよびvardirを削除してください。

同様に、MSIはPuppetLabs\facter\facts.dディレクトリに書き込まれたカスタムフィードを上書きしません。

無人インストール

以下のようなコマンドラインで無人インストールを実行しようとすると、インストールに失敗することがあります。

msiexec /qn /norestart /i puppet.msi

トラブルシューティングのためのデータを入手するには、/l*v install.txtなどのインストールログを指定します。 ログで以下のようなエントリを探します。

MSI (s) (7C:D0) [17:24:15:870]: Rejecting product '{D07C45E2-A53E-4D7B-844F-F8F608AFF7C8}': Non-assigned apps are disabled for non-admin users.
MSI (s) (7C:D0) [17:24:15:870]: Note: 1: 1708
MSI (s) (7C:D0) [17:24:15:870]: Product: Puppet -- Installation failed.
MSI (s) (7C:D0) [17:24:15:870]: Windows Installer installed the product. Product Name: Puppet. Product Version: 2.7.12. Product Language: 1033. Manufacturer: Puppet Labs. Installation success or error status: 1625.
MSI (s) (7C:D0) [17:24:15:870]: MainEngineThread is returning 1625
MSI (s) (7C:08) [17:24:15:870]: No System Restore sequence number for this installation.
Info 1625.This installation is forbidden by system policy. Contact your system administrator.

このようなエントリが見つかった場合は、Puppetをインストールするための十分な権限を持っていないことになります。 Run as Administratorオプションを選択してcmd.exeを実行し、再度試してみてください。

ファイルパス

パスセパレータ

Windowsでは、必ずパスセパレータにセミコロン(;)を使用してください。たとえば、modulepath=path1;path2のようになります。

ファイル区切り記号とバックスラッシュ

ほとんどのリソース属性については、Puppet言語でファイルセパレータとしてスラッシュまたはバックスラッシュを使用できます。 ただし一部には、必ずスラッシュを使わなければいけない属性や、必ずバックスラッシュを使わなければいけない属性もあります。

バックスラッシュをダブルクォーテーション(“)で囲むと、必ずエスケープされます。 シングルクォーテーション(‘)で囲むと、場合によってはエスケープされます。 たとえば、以下は有効なリソースです。

file { 'c:\path\to\file.txt': }
file { 'c:\\path\\to\\file.txt': }
file { "c:\\path\\to\\file.txt": }

しかし、以下のパスは、\p、\t、\fがエスケープシーケンスとして解釈されるため無効です。

file { "c:\path\to\file.txt": }

詳細については、Windowsでのバックスラッシュに関する言語リファレンスを参照してください。

UNCパス

UNCパスはWindowsでパッケージリソースとしてサポートされており、一般的な\\servername\directory\package.msiフォーマットが使用されます。 ファイルリソースとしてのUNCパスのサポートは、Puppet 3.4.0で追加されました。

大文字と小文字の区別

Windowsでは、一部のリソースの大文字と小文字が区別されません(ファイル、ユーザ、グループ)。 ただし、Puppetではこれらのリソースについて大文字と小文字が区別されることがあります。 リソース間の依存関係を確立する際には、必ず矛盾のないように文字を指定してください。 そうしないと、Puppetが依存関係を正しく解読できない場合があります。 たとえば、以下のマニフェストの場合、PuppetではFOOBARとfoobarが同じユーザとして認識されないため、適用は失敗します。

file { 'c:\foo\bar':
  ensure => directory,
  owner  => 'FOOBAR'
}
user { 'foobar':
  ensure => present
}
...
err: /Stage[main]//File[c:\foo\bar]: Could not evaluate: Could not find user FOOBAR

Diff

サードパーティのdiffユーティリティ(msys、gnudiff、cygwinなど)がインストールされ、diff設定が適切に設定されていない場合、PuppetはWindowsでdiffを表示しません(puppet agent --show_diffなど)。

リソースエラーおよび不具合

Exec

Windows execリソースを宣言する場合、リソースへのパスは通常、%WINDIR%環境変数に依存します。 これはシステムによって異なることがあるため、execリソースではpathfactを使うことができます。

exec { 'cmd.exe /c echo hello world':
  path => $::path
}

シェルのビルトインコマンド

Puppetは現在、Windowsでシェルプロバイダをサポートしていないため、シェルのビルトインコマンドを直接実行すると、失敗します。

exec { 'echo foo':
  path => 'c:\windows\system32;c:\windows'
}
...
err: /Stage[main]//Exec[echo foo]/returns: change from notrun to 0 failed: Could not find command 'echo'

その代わりに、ビルトインコマンドをcmd.exeでラッピングします。

exec { 'cmd.exe /c echo foo':
  path => 'c:\windows\system32;c:\windows'
}

32ビットバージョンのPuppetでは、ファイルシステムリダイレクト(system32がWindowsにより自動的にsysWOW64に切り替わる場所)の対象になる可能性がある点に留意してください。 リダイレクトについては、いくつかの対処方法があります。

または、前述のヒントを使うとさらに良いでしょう。

exec { 'cmd.exe /c echo foo':
  path => $::path
}

Powershell

デフォルトでは、powershellは制限付き実行ポリシーを適用しますが、それによりスクリプトの実行が妨げられます。 そのため、powershellコマンドでは適切な実行ポリシーを必ず指定してください。

exec { 'test':
  command => 'powershell.exe -executionpolicy remotesigned -file C:\test.ps1',
  path    => $::path
}

パッケージ

MSIまたはEXEパッケージのソースは、ローカルファイルシステム、ネットワークマッピングされたドライブ、UNCパスのいずれかにあるファイルにする必要があります。 URIベースのソースはサポートしていません。ただし、Puppet masterをソースとするファイルを定義してから、ローカルファイルをソースとするパッケージを定義すれば、同様の結果が得られます。

サービス

Windowsサービスは、ショートネームとディスプレイネームをサポートしています。 Puppetマニフェストでは、必ずショートネームを使用してください。 たとえば、wuauservを使用し、Automatic Updatesは使用しないでください。 sc queryでサービスとその各種ネームのリストを入手できます。

エラーメッセージ

  • Error: Could not connect via HTTPS to https://forge.puppet.com / Unable to verify the SSL certificate / The certificate may not be signed by a valid CA / The CA bundle included with OpenSSL may not be valid or up to date

    このエラーメッセージは、新たに導入されたWindowsノードでpuppet moduleサブコマンドを実行すると生じます。

    Puppet Forgeは、GeoTrust Global CA証明書により署名されたSSL証明書を使用します。 新たに導入されたWindowsノードでは、まだroot CAストアにCAがないことがあります。

    これを修正するには、2つのオプションがあります。 いずれか1つを選択してください。

    • Windows Updateを実行し、利用可能なアップデートをすべて適用した後、Webブラウザでhttps://forge.puppet.comを開きます。GeoTrust CAが自動ダウンロードのホワイトリストにあることがWebブラウザで認識されると、それがroot CAストアに追加されます。
    • GeoTrustのroot証明書リストから「GeoTrust Global CA」証明書をダウンロードし、certutil -addstore Root GeoTrust_Global_CA.pemを実行して手動でインストールします。
  • Service 'Puppet Agent' (puppet) failed to start. Verify that you have sufficient privileges to start system services.”

    このエラーメッセージは、未昇格のアカウントからUACシステムにPuppetをインストールする際に生じることがあります。 インストーラはPuppetをインストールするUACプロンプトを表示しますが、サービスを起動しようとしても昇格はしません。 MSIをインストールする際には、必ず昇格したcmd.exeプロセスから実行してください。

  • Cannot run on Microsoft Windows without the sys-admin, win32-process, win32-dir, win32-service and win32-taskscheduler gems.

    Puppetは指示されたWindows固有のgemを要求します。これはgem install <gem>を使ってインストールできます。

  • err: /Stage[main]//Scheduled_task[task_system]: Could not evaluate: The operation completed successfully.

    このエラーメッセージは、バージョン < 0.2.1 のwin32-taskscheduler gemを使用すると生じることがあります。 gem update win32-taskschedulerを実行してください。

  • err: /Stage[main]//Exec[C:/tmp/foo.exe]/returns: change from notrun to 0 failed: CreateProcess() failed: Access is denied.

    このエラーメッセージは、リモートPuppet masterから実行できない実行ファイルをリクエストした際に生じることがあります。 Windowsでファイルを実行可能にするためには、Puppet masterでユーザ/グループ実行ファイルビットを適切に設定してください(または、Windowsホスト上に存在するファイルモードを指定します)。

      file { "C:/tmp/foo.exe":
        source => "puppet:///modules/foo/foo.exe",
      }
    
      exec { 'C:/tmp/foo.exe':
        logoutput => true
      }
    
  • err: getaddrinfo: The storage control blocks were destroyed.

    このエラーは、agentがDNS名をIPアドレスとして解読できない場合に生じます(たとえば、serverca_serverなどのプロパティ)。 DNSに問題があるかどうかは、nslookup <dns>を実行して確認することができます。 この実行が失敗する場合は、Windows agent上のDNS設定に問題があります(たとえば、主要なdnsサフィックスが設定されていない、など)。 詳細については、http://technet.microsoft.com/en-us/library/cc959322.aspxを参照してください。

    このエラーは、agentの逆引きDNSエントリが適切でない場合にも生じることがあります。

  • err: Could not request certificate: The certificate retrieved from the master does not match the agent's private key.

    このエラーは通常、masterがすでに当該agentに対して証明書を発行していることを示すものです。 このエラーは、masterから証明書を回収したあとにagentのSSLディレクトリが削除された場合や、2つの異なるセキュリティコンテクストでagentを稼動した場合に生じます。 たとえば、Puppet agentをサービスとして稼働してから、非昇格セキュリティによりコマンドラインでpuppet agentを実行しようとした場合などに生じます。 特に、Start Command Prompt with Puppetを選択しながら、Run as Administratorを使用して権限を昇格しなかった場合に生じます。

  • err: Could not send report: SSL_connect returned=1 errno=0 state=SSLv3 read server certificate B: certificate verify failed. This is often because the time is out of sync on the server or client.”

    Active Directoryドメインの一部であるWindows agentは、時間が自動的にADと同期されているはずです。 ADドメインの一部ではないagentの場合、Windowsタイムサービスを手動で有効化し、追加する必要が生じることがあります。

      w32tm /register
      net start w32time
      w32tm /config /manualpeerlist:<ntpserver> /syncfromflags:manual /update
      w32tm /resync
    
  • “Error: Could not parse for environment production: Syntax error at ‘=’; expected ‘}’”

    このエラーは通常、コマンドラインでpuppet apply -eを使用し、提示されたコマンドがシングルクォーテーション(‘)で囲まれている場合に生じます。この場合、cmd.exeは、コマンド内の=>をリダイレクトとして解釈します。 この問題を解決するには、コマンドをダブルクォーテーション(“)で囲んでください。

↑ Back to top