0

次のシナリオを検討してください。

マシン A のマスターとマシン B のスレーブで実行されている Jenkins。ハードコードされた Java パスを参照するマスターの XML 構成ではなく、環境 PATH 変数で「java」を参照するように変更されました。これは、マシン A で実行されているマスターでは正常に機能しますが、マシン B のスレーブはマスター ホスト PC に接続できなくなります。

マシン A のインバウンド トラフィックの (Windows) ファイアウォール ルールは、「C:\Program Files\Java\jre7\bin\java.exe」への任意のプロトコルおよびポート接続でのインバウンド通信を許可するため、Jenkins サービスは機能するはずですが、機能しません。 t。接続を機能させる唯一の方法は、ファイアウォールを無効にすることです。

4

1 に答える 1

0

「java」へのすべての接続を許可するようにインバウンド ファイアウォール ルールを設定したにもかかわらず、それが環境 PATH 値を取得することを期待していましたが、それでも接続を機能させることができませんでした。

最後に、「java」PATH変数を使用せずに「C:\Program Files\Java\jre7\bin\java.exe」を使用するようにjenkins.xmlファイルを変更し、これに一致するように受信ファイアウォールルールを設定し直しました。

興味深いのは、Windows が PATH 変数とリテラル ファイル パスを異なる方法で認識していたため、ファイアウォール ルールを満たさなかったことです (おそらく、設計とセキュリティ機能によるものでしょうか?)。

于 2013-07-05T00:21:38.753 に答える