2

私は Chef を使用して Windows 2012 Server (RTM) を構成しています。これには Octopus Tentacle サービスのインストールも含まれており、Octopus Deploy を使用してこのインスタンスにソフトウェアをデプロイできます。

私のワークステーション (Chef クライアント) は、Windows 7 x64 SP1 を実行しています。サーバーは VMware Workstation でホストされ、Windows 2012 Server x64 RTM を実行しています。これは sysprep されたベースライン イメージから起動され、Chef レシピが新しい Octopus 証明書を作成しようとするまで、すべてがうまく機能しています。

octopus.rb Chef レシピは Powershell のチャンクをラップし、実際に Octopus Tentacle のインストールを行うビットは次のようになります。

$wc = New-Object System.Net.WebClient
$wc.DownloadFile("#{source_path_tanticle}", "#{install_path_tanticle}")
Start-Process -FilePath msiexec -ArgumentList /i, "#{install_path_tanticle}", /quiet -Wait  | out-file -filepath C:\\Octopus.log -append
netsh advfirewall firewall add rule name="Octopus" dir=in action=allow protocol=TCP localport=#{tanticle_port}  | out-file -filepath C:\\Octopus.log -append

cd "C:\\Program Files (x86)\\Octopus Tentacle\\Agent"
.\\tentacle.exe configure --appdir="C:\\Applications" --port=#{tanticle_port} --trust="#{octopus_server_Thumbprint}" | out-file -filepath C:\\Octopus.log -append
.\\tentacle.exe new-certificate | out-file -filepath C:\\Octopus.log -append
.\\tentacle.exe register-with --server=$octopusServer --publicHostname=$publicDnsName --environment=$environment --role=web --apikey=$octopusServerApiKey | out-file -filepath C:\\Octopus.log -append

このスクリプトが呼び出すtentacle.exe new-certificateと、次のものがスローされますUnauthorizedAccessException。

Generating and installing a new cetificate...
System.UnauthorizedAccessException: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
   at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
   at Octopus.Shared.Security.CertificateGenerator.Generate(String fullName, Boolean exportable) in c:\w\e6923628be6eaf72\source\Octopus.Shared\Security\CertificateGenerator.cs:line 25
   at Octopus.Tentacle.Commands.NewCertificateCommand.Execute() in c:\w\e6923628be6eaf72\source\Octopus.Tentacle\Commands\NewCertificateCommand.cs:line 31
   at Octopus.Shared.Startup.CommandProcessor.Process(String[] args) in c:\w\e6923628be6eaf72\source\Octopus.Shared\Startup\CommandProcessor.cs:line 40

Chef クライアント サービスは管理者として実行されているため (少なくとも、インストール中に作成された octopus.log ファイルに $env:username をダンプすると、管理者と表示されます)、Octopus の触手がどのファイル/フォルダー/リソースを試みているのかわかりませんアクセスするために。

ノードをブートストラップするために実行される実際の Chef コマンドは次のとおりです。

 knife bootstrap windows winrm 192.168.202.137 -x Administrator -P p@ssw0rd -r 'role[web_server]'

ここで、192.168.202.137 は新しく起動した Win2012 サーバーの IP アドレスで、p@ssw0rd はそのサーバーのローカル管理者パスワードです。

管理者としてログインしているときにサーバーで同じコマンドを手動で実行すると完全に機能するため、chef/winrm/powershell リモート処理と関係があります。

1つの理論は、クライアントとサーバーで異なるOSを実行しているため（Win7 x64とWin2012）、ある種のDCOM / WinRMセキュリティエッジケースに遭遇しているということです-ただし、ここでの呼び出しチェーンはcmd.exe-> Rubyです- > WinRM -> Ruby -> Powershell このような問題をどのように修正するか、または検証するかについて、私は少し迷っています...

4

3 に答える 3

2

なぜこれが発生するのかはまだよくわかりませんが、 mixlib-shelloutに疑似「実行」を実行させることで回避できます。これはまったく同じユーザーですが、どういうわけか Windows では、実際にユーザーとして完全にログインしていなくても、ユーザーとしてログインできるように見えることに注意してください....

理論的には、start-processは (ユーザーのパスワードを必要とせずに) 同じことを実行できるはずですが、それを確実に実行することは苦痛の世界でした。

于 2013-09-30T15:02:28.213 に答える