代码之家 › 专栏 › 技术社区 › Eight-Bit Guru

CruiseControl.net服务/子版本-无法连接到远程存储库

cruisecontrol.net service svn windows

1

Eight-Bit Guru · 技术社区 · 15 年前

作为一个长期的潜伏者,我提出了一个关于CruiseControl.net、颠覆和远程存储库的棘手问题Cherry。问题是:

以运行在Windows Server 2008 SP2上的远程Subversion 1.6.6存储库为例,使用Apache 2.2.14作为网关来启用对端口80和443的访问-我们将未加密的通信重定向到安全端口,并且我们有一个正确配置的SSL层,运行时带有自签名证书。这一切都可以——我可以将浏览器从本地计算机(xp sp2或server 2008 sp2)指向此存储库,轻松地通过证书验证,根据存储库acl进行身份验证,并查看其中的内容。同样,在我的本地机器上执行的SVN命令(在命令行或通过Tortoissesvn)也能完美地工作。

现在添加CruiseControl.net 1.4.4.83-在本地计算机上运行一段时间,用一个简单的脚本从远程存储库中提取一些源代码,并构建一个非常基本的应用程序。同一个脚本对本地存储库非常有效,所以唯一的区别是SubversionURL,它现在指向远程服务器。

如果我用自己的帐户在命令行shell(cc net.exe)中运行cc.net,它就会工作。

但是,如果我以服务(cc service.exe)的形式运行cc.net,它将失败;默认情况下,它以localservice的形式运行,但我已经将其更改为使用我的凭据运行。在这种模式下,发出的第一个subversion命令(svn log)失败,并抱怨它无法连接到服务器。

我花了四五天的时间研究这个问题;我知道这不是防火墙类型的问题,因为CC.NET发布的命令在命令行shell中工作,当然我可以通过Tortoissesvn和浏览器连接到远程服务器。这不是ssl和/或证书阻碍的,因为我已经导入了证书——而且,在“手动”模式下,使用命令行中的tortoissesvn、浏览器或svn命令,这一点也很好。这不是一个DNS解析问题,因为我可以指定远程服务器的实际IP地址,但它仍然无法连接-但当然,如果我在命令行模式下运行,连接正常…

我甚至还下载了CC.NET源代码并在其中搜索,看看是否有什么奇怪的事情发生。据我所见,在以服务模式运行时发出命令的唯一区别是,已经进行了一个alloconsole调用,以便为subversion命令进程准备一个控制台,以便在生成它们时锁定它们。

在这个阶段,我能做的最好的猜测是,alloconsole会话在某种程度上与标准的命令行会话有着根本的不同——在这种情况下,即使服务是在我的用户凭证下运行的,alloconsole也没有“正确”的网络访问权。但是,我对alloconsole或cc.net源代码的了解不够,无法证明这一点,因此我陷入了僵局。

目前,我正在命令行模式下运行cc.net;但是,这只是感觉不满意,因为我们更喜欢在服务模式下运行它(这对本地域中的存储库很好),以避免在机器启动时创建一个计划任务来启动它。

有人有什么建议吗?

1 回复 | 直到 13 年前

1

Eight-Bit Guru 15 年前

把它弄碎了。这不是防火墙问题,而是代理服务器问题。

我们在这里使用BlueCoat(是的,我知道,不是我的电话),所以位于所有开发人员PC上的“C:\documents and settings\all users\application data\subversion”的Subversion“servers”文件有一个条目,可以让我们绕过代理服务器,进入特定的外部存储库。然而,我们倾向于使用Tortoissesvn,并通过属性表访问这个文件-直到现在,还没有意识到它是一个Subversion文件,而不是Tortoissesvn文件。

当然,由于我们在构建服务器上不使用Tortoissesvn,所以我们从未处理过“服务器”文件。然而,既然CruiseControl.net需要访问一个外部存储库(以前它只与我们的内部存储库对话),它就无法通过BlueCoat的障碍。

一旦拼图被点击到位,我在构建框上创建了一个“服务器”文件,添加了我们的旁路配置,然后突然CruiseControl.net和Subversion在服务模式下可以看到远程存储库。

我仍然不完全确定为什么它在命令行模式下工作,而不是服务模式,但我已经修复了它,所以我很高兴。:)