3

Jenkins（1.477、1.480.3、および1.508）を実行しているVM（VMWareクラスター内）があり、SVNリポジトリ（Collabnet SVN 1.7.5-3150.92）へのコミットのビルドを実行します。リポジトリにはSSL接続を介してアクセスします。セキュリティ上の理由から、どちらのコンピューター（ビルドサーバーまたはSVNサーバー）もインターネットにアクセスできません。JenkinsビルドがSVNの開始を開始すると、ジョブのコンソールが更新され、「https://vcfs01.redacted-address.com/svn/MTCM/Trunk」が30〜90秒間更新されます。更新が開始されると、かなり高速になります。

Jenkinsを犯人として除外するために、TortoiseSVNを使用してビルドサーバーからチェックアウトすることで同じ問題を再現しました。Tortoiseでも同じ遅延が発生し、ファイルの転送が開始されると、転送速度は50〜70 KB / sの範囲になります（これはすばらしいことです）。

Kasperskyを使用しており、Kasperskyを搭載したプログラマーPCでは問題が発生しないため、問題として除外しました。また、100％確実にするために、両方のサーバーを除外しようとしました。

しばらくの間、WireSharkでhttp://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?dca976bb02bdc2e3からのHTTP GETの試行を確認したため、これは証明書失効チェックの問題であると確信していました。 。このKB記事の手順を使用して、JenkinsサーバーとSVNサーバーの両方で証明書失効チェックを無効にしました（後者が問題になるとは思えませんが）。この変更を行うと、windowsupdateサーバーへの接続は試行されなくなりましたが、代わりにhttp://crl.globalsign.com/gs/gsorganizationvalg2.crlからのHTTPGETが表示されました。CRLチェックの無効化に関するこの記事に出くわしました。両方のサーバーについてそこでの手順を実行しましたが、外部（インターネット）アドレスへのHTTPGETは表示されなくなりました。

Jenkinsサーバーがインターネットにアクセスできる場合、Tortoiseではハンドシェイクに約5秒かかります（ファイアウォールがアクセスを阻止する場合は約90秒です）。Tortoiseの高速ハンドシェイクにもかかわらず、Jenkinsの速度はファイアウォールが設置されていたときと同じです。

Jenkinsについて調査し（Jenkinsをバージョン1.477から1.508に更新しました）、シンボリックリンクに問題があるSVNKitに関する記事を見つけました。私の知る限り、シンボリックリンクは使用されていません。

WireSharkで見ているのは、JenkinsサーバーとSVNサーバーの間に初期アクティビティ（暗号化された接続の作成）があることです。最初のアクティビティが約30秒経過した後、さらにアクティビティがあります（アプリケーションデータが送信されます）。アプリケーションデータの後、さらに約30秒の遅延があり、さらにアプリケーションデータが送信され、暗号化された接続がリセットされ、更新が開始されます。

@Chrisと@Barmarが書いたことについてネットワーキンググループと話し、ネットワーキンググループは次のように述べました。

私たちのDNSサーバーにはすでに逆168.192ルックアップゾーンがあり、かなりの数のサーバーが配置されています。内部サーバーの古い不正なエントリを検索することを除いて、これらのゾーンで何もする必要はほとんどありませんでした。

これはルックアップの問題ではないと思いますが、ここで頭を悩ませています。Jenkinsマシン（172.25.2.106）とSVNサーバー（172.25.2.106）の間のフィルター処理されたキャプチャは、パケット送信間の一時停止を示しています。

WireSharkトレース

これらは両方ともWin2K8R2DatacenterVMwareマシンです。私たちのネットワークグループによると、これらのサーバーのDNSエントリ/ルックアップは構成され、正しく機能しています。

4

3 に答える 3

4

問題：ファイアウォールで保護されたサーバーのコマンドラインでSVNを呼び出した後、15秒間何も表示されない場合、プログラムは次のエラーで終了します。

svn：E170013：URL'SVN.REPOSITORY.REDACTED'のリポジトリに接続できません

svn：E730054：コンテキストの実行中にエラーが発生しました：既存の接続がリモートホストによって強制的に閉じられました。

調査：上記のエラーに関するインターネット調査では、関連情報は見つかりませんでした。

プロセストレース（procmon）は、SVNサーバーへのSSL / TLSハンドシェイク後に、Akamai（クラウドサービス）サーバーへの接続試行を示しました。サーバーのホスト名がプロセストレースに表示されませんでした。DNS逆引き参照では、ホスト名としてa184-51-112-88.deploy.static.akamaitechnologies.comまたはa184-51-112-80.deploy.static.akamaitechnologies.comが表示され、IPは184.51.112.88または184.51でした。 112.80（DNSキャッシュに2つのエントリ）。

パケットキャプチャツール（MMA）は、SVNサーバーへのSSL / TLSハンドシェイク後に、ホスト名ctldl.windowsupdate.comへの接続の試行を示しました。

Windows CryptoAPIはWindowsUpdateに接続して、証明書失効情報（CRL –証明書失効リスト）を取得しようとしていました。CRL取得のデフォルトのタイムアウトは15秒です。サーバーでの認証のタイムアウトは10秒です。15は10より大きいため、これは失敗します。

解決策：インターネット調査により、次のことが明らかになりました:(下の写真も参照）

解決策1：CRLタイムアウトを減らすグループポリシー->コンピューターの構成->Windowsの設定->セキュリティの設定->公開鍵のポリシー->証明書パス検証の設定->ネットワークの取得–下の図を参照してください。

https://subversion.open.collab.net/ds/viewMessage.do?dsForumId=4&dsMessageId=470698

support.microsoft.com/en-us/kb/2625048

blogs.technet.com/b/exchange/archive/2010/05/14/3409948.aspx

解決策2：CRLトラフィック用のファイアウォールを開く

support.microsoft.com/en-us/kb/2677070

解決策3：SVNコマンドラインフラグ（テストされていない）

serverfault.com/questions/716845/tortoise-svn-initial-connect-timeout-代替のsvnコマンドラインフラグソリューション。

追加情報：この問題のデバッグは特に困難でした。SVN 1.8は、クライアントのデバッグログを削除したSerfライブラリを優先して、Neon HTTP RA（リポジトリアクセス）ライブラリのサポートを無効にしました。[1]さらに、返されたSVNエラーコードはsvn_error_codes.hで指定された文字列と一致しませんでした[2]また、SVNエラーコードをENUMラベルに簡単にマッピングすることはできません。この場合、SVNエラーコードE170013はSVN_ERR_RA_CANNOT_CREATE_SESSIONにマッピングされます。

  1. stackoverflow.com/questions/8416989/is-it-possible-to-get-svn-client-debug-output
  2. people.apache.org/~brane/svndocs/capi/svn__error__codes_8h.html#ac8784565366c15a28d456c4997963660a044e5248bb3a652768e5eb3105d6f28f
  3. code.google.com/archive/p/serf/issues/172

提案されたSVNの変更：

  1. すべての操作と同様に、コマンドで詳細情報を有効にします

  2. エラーENUM名をstderrに追加します

  3. SerfLibraryデバッグログの構成フラグを追加します。

于 2016-01-27T20:22:10.050 に答える
2

DNS解決の問題、証明書失効リストの問題、または（！）IPv6の問題のいずれかであるように見えます。ステップバイステップの解決策を提供することはできませんが、確認すべき事項のリストは次のとおりです。

DNS

  • 影響を受けるマシン（クライアントとサーバー）でDNS解決が正しく機能することを確認します。
  • 関係するすべてのマシンがDNSにPTR（逆引き参照ゾーン）レコードを持っていること、およびこれらのレコードが正しいことを確認します。

証明書

  • 遅延はプレーンHTTPで再現されますか？
  • SVNサーバーに自己署名証明書がインストールされていますか？証明書はネットワーク上で信頼されていますか、それとも認証局によって署名されていますか？

IPv6

  • クライアントでIPv6を無効にして、SVNサーバーにアクセスしようとしましたか？この場合、遅延はありますか？

遅延のトラブルシューティングに役立つ別の方法もあります。

Subversionクライアントで低レベルのログを有効にして、コマンドラインクライアントで問題の再現を試みることができます。クライアントのデバッグ出力をチェックして、遅延がいつ発生するかを正確に確認します。遅延の前後はどうなりますか？

クライアントロギングを有効にする方法：

  1. クライアントのサーバーファイル[global]のセクションに 次の文字列を追加します。%APPDATA%\subversion\servers

    neon-debug-mask = 395

  2. 問題を再現します。操作が「遅れ」を開始するか、断続的に停止するかを確認します（操作が中断するときに注意する必要があります）。

neon-debug-maskの詳細については、SVNBookを参照してください。

ネオンデバッグマスク

これは、基になるHTTPライブラリであるNeonが、生成するデバッグ出力のタイプを選択するために使用する整数マスクです。デフォルト値は0で、これによりすべてのデバッグ出力が無音になります。SubversionがNeonを使用する方法の詳細については、第8章「Subversionの埋め込み」を参照してください。

于 2013-04-03T09:58:47.997 に答える
0

ネットワークグループは、これらのマシンがVMであり、VMToolsがインストールされていないことに気づきました。これでVMToolsがインストールされました。パフォーマンスは最初は同じように見えましたが、現在、更新には最大30秒かかります（Tortoiseよりも劣りますが、元の状態よりも優れています）。

于 2013-03-27T20:25:21.647 に答える