作为一个长期的潜伏者,我弹出了一个棘手的关于CruiseControl.NET,Subversion和远程存储库的问题。问题如下:CruiseControl.NET服务/ Subversion - 无法连接到远程存储库
将Windows Server 2008 SP2上运行的远程Subversion 1.6.6存储库使用Apache 2.2.14作为网关,以便在端口80和443上启用访问 - 我们将未加密的流量重定向到安全端口,以及我们有一个正确配置的使用自签名证书运行的SSL层。这一切都有效 - 我可以将浏览器从本地计算机(XP SP2或Server 2008 SP2)指向此存储库,轻松通过证书验证,根据存储库ACL进行身份验证,并查看其中的内容。同样,在本地机器上执行的SVN命令(无论是在命令行还是通过TortoiseSVN)都可以完美地工作。
现在添加CruiseControl.NET 1.4.4.83 - 在本地机器上运行一个简单的脚本,从远程存储库中提取一些源代码,并构建一个非常基本的应用程序。这个相同的脚本完全可以对付本地存储库,所以唯一的区别是Subversion URL现在指向远程服务器。
如果我在自己的帐户下的命令行shell(ccnet.exe)中运行CC.NET,它可以工作。
但是,如果我将CC.NET作为服务运行(ccservice.exe),则会失败;默认情况下,它作为LOCALSERVICE运行,但我已经改变了这个以使用我的凭据运行。在这种模式下,第一个发布的Subversion命令(SVN LOG)失败,抱怨它无法连接到服务器。
我已经花了好四五天时间来研究这个问题;我知道这不是一个防火墙类型的问题,因为与CC.NET问题完全相同的命令在命令行shell中工作,当然,我可以通过TortoiseSVN和浏览器连接到远程服务器。这不是SSL和/或证书阻碍,因为我已经导入了证书 - 再一次,这可以在使用TortoiseSVN,浏览器或命令行中的SVN命令的“手动”模式下正常工作。这不是一个DNS解析问题,因为我可以指定远程服务器的实际IP地址,但它仍然无法连接 - 但当然连接好,如果我在命令行模式下运行...
我甚至已经下载并通过CC.NET源代码来查看是否有任何奇怪的事情发生。据我所见,在服务模式下运行时发出命令的唯一区别是,AllocConsole调用已准备好一个控制台,以便Subversion命令进程在产生时锁定。
在这个阶段,我可以做出的最好的猜测是,AllocConsole会话与标准命令行会话有某种根本的不同 - 即使服务在我的用户凭证下运行,不知何故AllocConsole没有'正确的'网络访问。但是,我不太了解AllocConsole或CC.NET源代码以证明这一点,因此我陷入了僵局。
目前,我在命令行模式下运行CC.NET;然而,这只是让人感到不满意,因为我们更喜欢在服务模式下运行它(这对我们本地域中的存储库来说工作正常),以避免创建计划任务以在机器启动时启动它的必要性。
任何人有任何建议吗?