As a long-time lurker on SO, I’m popping my question cherry with a tricky one regarding CruiseControl.NET, Subversion, and a remote repository. Here’s the problem:
Take a remote Subversion 1.6.6 repository running on Windows Server 2008 SP2, using Apache 2.2.14 as the gateway to enable access on Port 80 and 443 – we redirect unencrypted traffic to the secure port, and we have a properly-configured SSL layer running with a self-signed certificate. This all works – I can point a browser from my local machine (XP SP2 or Server 2008 SP2) to this repository, pass through the certificate verification painlessly, authenticate against the repository ACL, and see stuff in there. Equally, SVN commands executed on my local machine (either at the commandline or via TortoiseSVN) work flawlessly.
Now add CruiseControl.NET 1.4.4.83 – running for the moment on my local machine with a simple script to pull some sourcecode from the remote repository, and build a very basic application. This same script works perfectly against a local repository, so the only difference is the Subversion URL, which is now pointing to the remote server.
If I run CC.NET in a commandline shell (ccnet.exe) under my own account, it works.
If I run CC.NET as a service (ccservice.exe) however, it fails; by default, it runs as LOCALSERVICE, but I have already altered this to run with my credentials. In this mode, the very first Subversion command issued (SVN LOG) fails, complaining that it cannot connect to the server.
I have spent a good four or five days investigating this; I know it’s not a firewall-type problem, because the exact same command that CC.NET issues works in a commandline shell, and of course I can connect to the remote server via TortoiseSVN and a browser. It’s not the SSL and/or certificate getting in the way, as I have already imported the certificate – and again, this works fine in ‘manual’ mode using TortoiseSVN, a browser, or SVN commands at the commandline. It’s not a DNS resolution issue, because I can specify the actual IP address of the remote server, and it still fails to connect – but of course connects OK if I run in commandline mode…
I’ve even downloaded and prowled through the CC.NET sourcecode to see if there’s anything odd going on. As far as I can see, the only difference regarding issuing commands when running in service-mode is that an AllocConsole call has been made to prepare a console for the Subversion command processes to latch on to when they’re spawned.
The best guess I can make, at this stage, is that the AllocConsole session is somehow fundamentally different from a standard commandline session – in that, even though the service is running under my user credentials, somehow the AllocConsole does not have ‘proper’ network access. However, I don’t know enough about AllocConsole or the CC.NET sourcecode to be able to prove this, and I’m therefore at an impasse.
For the moment, I’m running CC.NET in commandline mode; however, this just feels unsatisfactory, because we prefer to run it in service mode (which works fine against repositories in our local domain) to avoid the necessity creating a scheduled task to start it up when the machine starts.
Anyone got any suggestions?
Cracked it. It wasn’t a firewall problem, it was a proxy problem.
We use Bluecoat here (yes, I know, not my call) and so the Subversion ‘servers’ file, which lives at ‘C:\Documents and Settings\All Users\Application Data\Subversion\’ on all our developer PCs has an entry to let us bypass the proxy to get out to specific external repositories. However, we tend to use TortoiseSVN mostly, and access this file through the property sheet – until now, not realising that it’s a Subversion file, not a TortoiseSVN file.
Naturally, since we don’t use TortoiseSVN on the build servers, we’ve never messed with the ‘servers’ file. However, now that CruiseControl.NET needs to get to an external repository (previously it has only talked to our internal repositories) it was unable to get past the Bluecoat roadblock.
Once the puzzle clicked into place, I created a ‘servers’ file on the build box, added our bypass configuration to it, and suddenly CruiseControl.NET and Subversion in Service Mode can see the remote repository.
I’m still not entirely sure why it worked in commandline mode but not service mode, but I’ve fixed it so I’m happy. 🙂