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（这很好）。

我们使用卡巴斯基，并已将其排除为问题，因为在具有卡巴斯基的程序员 PC 上不会出现此问题。我们还尝试排除两台服务器只是为了确定 %100。

有一段时间我确信这是证书吊销检查的问题，因为我在 WireShark 中看到来自http://ctldl.windowsupdate.com/msdownload/update/v3/static/trustedr/en/disallowedcertstl.cab?dca976bb02bdc2e3的尝试 HTTP GET . 使用此知识库文章中的步骤，我在 Jenkins 服务器和 SVN 服务器上禁用了证书吊销检查（尽管我怀疑后者是否重要）。进行此更改后，我不再尝试连接到 windowsupdate 服务器，而是看到了来自http://crl.globalsign.com/gs/gsorganizationvalg2.crl的 HTTP GET 。我偶然发现了这篇关于禁用 CRL 检查的文章. 我对两个服务器都按照那里的步骤操作，不再看到对外部（互联网）地址的 HTTP GET。

当 Jenkins 服务器可以访问 Internet 时，Tortoise 中的握手需要大约 5 秒（而防火墙阻止访问时大约需要 90 秒）。尽管 Tortoise 的握手速度很快，但 Jenkins 的握手速度与防火墙安装时的速度相同！

我对 Jenkins 做了一些研究（我也将 Jenkins 从版本 1.477 更新到了 1.508），发现了一篇关于 SVNKit has questions with symbolic links 的文章。据我所知，没有使用任何符号链接。

我在 WireShark 中看到的是 Jenkins 服务器和 SVN 服务器之间有一些初始活动（创建加密连接）。在初始活动约 30 秒过去后，会有更多活动（发送应用程序数据）。在应用程序数据之后还有大约 30 秒的延迟，然后发送更多应用程序数据，加密连接被重置，更新开始。

我与网络小组讨论了@Chris 和@Barmar 所写的内容，网络小组说：

我们的 DNS 服务器已经有一个反向 168.192 查找区域，并且填充了很多服务器。除了搜索内部服务器的旧流氓条目外，我很少需要对这些区域做任何事情。

我认为这意味着这不是查找问题，但我在这里不知所措。这是 Jenkins 机器 (172.25.2.106) 和 SVN 服务器 (172.25.2.106) 之间的过滤捕获，显示了数据包传输之间的暂停：

WireShark 追踪

这两个都是 Win2K8 R2 Datacenter VMware 机器。根据我们的网络组，这些服务器的 DNS 条目/查找已配置并正常工作。

4

3 回答 3

4

问题：在防火墙服务器上的命令行上调用 SVN 后，15 秒内没有任何可见的事情发生，然后程序退出并出现以下错误：

svn：E170013：无法连接到 URL 'SVN.REPOSITORY.REDACTED' 的存储库

svn: E730054: Error running context: 现有连接被远程主机强行关闭。

调查：互联网对上述错误的研究没有发现任何相关信息。

进程跟踪 (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 Crypto API 试图连接到 Windows 更新以检索证书吊销信息（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 禁用了对 Neon HTTP RA（存储库访问）库的支持，转而支持删除客户端调试日志记录的 Serf 库。[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. 为 Serf Library 调试日志添加配置标志。

于 2016-01-27T20:22:10.050 回答
2

它看起来仍然是 DNS 解析问题、证书吊销列表问题或 (!) IPv6 问题。我无法为您提供分步解决方案，但以下是要检查的事项列表：

域名系统

  • 验证 DNS 解析是否在受影响的机器（客户端和服务器）上正常工作，
  • 验证所有涉及的机器在 DNS 上都有 PTR（反向查找区域）记录，并且这些记录是正确的。

证书

  • 延迟是否通过普通 HTTP 重现？
  • 您是否在 SVN 服务器上安装了自签名证书？证书是否在您的网络上受信任或由证书颁发机构签名？

IPv6

  • 您是否尝试在客户端上禁用 IPv6 并尝试访问 SVN 服务器？这种情况有延迟吗？

还有另一种方法可以帮助我们排查延迟问题：

您可以在 Subversion 客户端上启用低级别日志记录，并尝试使用命令行客户端重现该问题。检查客户端上的调试输出，看看延迟究竟是什么时候发生的。延迟之前和之后会发生什么？

HOWTO 启用客户端日志记录：

  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

网络组注意到这些机器是虚拟机并且没有安装 VMTools。他们现在已经安装了 VMTools。起初性能似乎相同，但现在更新大约需要 30 秒（仍然比 Tortoise 差，但比原来好）。

于 2013-03-27T20:25:21.647 回答