CruiseControl.NET Service / Subversion - Невозможно подключиться к удаленному хранилищу - PullRequest
1 голос
/ 02 февраля 2010

Давно скрываясь от SO, я отвечаю на мой вопрос с вопросом о CruiseControl.NET, Subversion и удаленном репозитории. Вот проблема:

Возьмите удаленный репозиторий Subversion 1.6.6, работающий на Windows Server 2008 с пакетом обновления 2 (SP2), с использованием Apache 2.2.14 в качестве шлюза для обеспечения доступа через порты 80 и 443 - мы перенаправляем незашифрованный трафик на защищенный порт, и у нас настроенный слой SSL работает с самозаверяющим сертификатом. Это все работает - я могу указать браузер с моего локального компьютера (XP SP2 или Server 2008 SP2) на этот репозиторий, безболезненно пройти проверку сертификата, выполнить аутентификацию в ACL репозитория и посмотреть, что там есть. Точно так же команды SVN, выполняемые на моем локальном компьютере (в командной строке или через TortoiseSVN), работают безупречно.

Теперь добавьте CruiseControl.NET 1.4.4.83 - на данный момент работающий на моей локальной машине с простым скриптом, который извлекает некоторый исходный код из удаленного репозитория и создает простейшее приложение. Этот же скрипт отлично работает с локальным репозиторием, поэтому единственное отличие - это URL Subversion, который теперь указывает на удаленный сервер.

Если я запускаю CC.NET в командной строке (ccnet.exe) под своей учетной записью, это работает.

Однако, если я запускаю CC.NET как службу (ccservice.exe), она не работает; по умолчанию он работает как LOCALSERVICE, но я уже изменил его, чтобы он работал с моими учетными данными. В этом режиме самая первая введенная команда Subversion (SVN LOG) дает сбой, сообщая, что не может подключиться к серверу.

Я провел добрые четыре или пять дней, расследуя это; Я знаю, что это не проблема типа брандмауэра, потому что точно такая же команда, которую выдает CC.NET, работает в оболочке командной строки, и, конечно, я могу подключиться к удаленному серверу через TortoiseSVN и браузер. Это не мешает SSL и / или сертификату, так как я уже импортировал сертификат - и снова, это прекрасно работает в «ручном» режиме, используя TortoiseSVN, браузер или команды SVN в командной строке. Это не проблема разрешения DNS, потому что я могу указать фактический IP-адрес удаленного сервера, и он все равно не может подключиться - но, конечно, подключается нормально, если я работаю в режиме командной строки ...

Я даже скачал и просмотрел исходный код CC.NET, чтобы увидеть, происходит ли что-то странное. Насколько я вижу, единственное различие в выдаче команд при работе в сервисном режиме заключается в том, что был сделан вызов AllocConsole, чтобы подготовить консоль для командных процессов Subversion, к которым они могут привязываться при их порождении.

Лучшее предположение, которое я могу сделать на этом этапе, заключается в том, что сеанс AllocConsole каким-то образом принципиально отличается от стандартного сеанса командной строки - в том, что, хотя служба работает под моими учетными данными пользователя, каким-то образом AllocConsole не имеет ' правильный доступ к сети. Однако я недостаточно знаю об AllocConsole или исходном коде CC.NET, чтобы доказать это, и поэтому я в тупике.

На данный момент я запускаю CC.NET в режиме командной строки; однако, это просто кажется неудовлетворительным, потому что мы предпочитаем запускать его в сервисном режиме (который прекрасно работает с репозиториями в нашем локальном домене), чтобы избежать необходимости создания запланированной задачи для запуска при запуске компьютера.

Кто-нибудь получил какие-либо предложения?

1 Ответ

1 голос
/ 03 февраля 2010

взломали его. Это не была проблема с брандмауэром, это была проблема с прокси.

Мы используем Bluecoat здесь (да, я знаю, не мой звонок) и поэтому файл «серверы» Subversion, который находится в C: \ Documents and Settings \ All Users \ Application Data \ Subversion \ 'на всех наших разработчиках На ПК есть запись, позволяющая нам обходить прокси-сервер для доступа к определенным внешним репозиториям. Тем не менее, мы обычно используем TortoiseSVN и обращаемся к этому файлу через лист свойств - до сих пор, не осознавая, что это файл Subversion, а не файл TortoiseSVN.

Естественно, поскольку мы не используем TortoiseSVN на серверах сборки, мы никогда не путались с файлом 'Servers'. Однако теперь, когда CruiseControl.NET требуется получить доступ к внешнему репозиторию (ранее он говорил только с нашими внутренними репозиториями), он не смог преодолеть блокпост Bluecoat.

После того, как головоломка встала на место, я создал файл 'серверы' в окне сборки, добавил нашу конфигурацию обхода, и вдруг CruiseControl.NET и Subversion в сервисном режиме могут видеть удаленный репозиторий.

Я все еще не совсем уверен, почему это работает в режиме командной строки, но не в режиме обслуживания, но я исправил это, поэтому я счастлив. :)

...