Запуск круиз-контроля .NET как услуга

Question

Я некоторое время настраивал и тестировал CCNet, используя Virtual PC для его размещения. Все прошло хорошо, и было решено перенести конфигурацию в расположение сервера - что прошло так, как и следовало ожидать. Несколько твиков и ударов, и у меня всё заработало, как и раньше.

Проблема в том, что теперь нам нужно запустить CCNet как сервис, который оказывается проблематичным.

Я настроил пользователя на уровне домена с теми же правами доступа, что и у меня (в конце концов, консольное приложение работало со мной уже около 3 месяцев) и настроил службу для работы под этим пользователем.

Я запустил службу, и она зависла! [Я не буду утомлять вас подробностями о том, как заставить службу останавливаться и закрывать сокеты, которые были открыты]. Когда я в конце концов смог снова запустить консоль, я выполнил «Запуск от имени» и ввел данные пользователя «cruisecontrol», нажал «ОК» и увидел, что возникла проблема с доступом к SVN через https. Я отсортировал это, запустив IE как 'cruisecontrol', перейдя в хранилище и приняв / установив сертификат. Затем, когда я запустил консольное приложение как 'cruisecontrol', оно зависло после следующих строк:

2009-01-15 16:55:50,994 [Pepsi Webservices:DEBUG] Running Subversion with arguments : log --xml --limit 1 <a href="https://ash-dev-005.[path" rel="nofollow noreferrer">https://ash-dev-005.[path</a> to trunk]</p> <p>2009-01-15 16:55:51,478 [Pepsi Webservices:DEBUG] Authentication realm: <a href="https://ash-dev-005.[path" rel="nofollow noreferrer">https://ash-dev-005.[path</a> to repository] Subversion Repositories

После истечения времени ожидания я могу закрыть консоль, запустить ее как обычно (то есть, как я), и она работает нормально. Я попытался войти на сервер как пользователь 'cruisecontrol' и попытался запустить консоль, но с тем же результатом.

Теперь, вот в чем дело: сегодня утром я вошел на сервер как пользователь 'cruisecontrol' и открыл окно команд. Я перешел к стволу моего проекта и набрал 'svn update', и мне предложили ввести пароль.

Это не удивительно, но строка выше этого приглашения была строкой «Область аутентификации: ...» выше! Если посмотреть на файл журнала, то сразу после того, как CCNet завершит процесс, появится запрос пароля. CCNet / SVN ожидает ввода пароля, а затем тайм-аут? Если так, то почему он не использует тот, который находится в файле конфигурации?

Я ввел пароль, и обновление прошло без проблем (поэтому у пользователя cruisecontrol есть разрешения на доступ к хранилищу с сервера). Я ввел команду снова и мне не было предложено второй раз, поэтому я попытался открыть новое командное окно и повторно запустить команду - по-прежнему не запрашивался пароль, поэтому я вышел из системы и снова (как в системе cruisecontrol) и повторил попытку, но все равно не получил запрос .

Хорошая новость заключается в том, что когда я запускаю консольное приложение от имени пользователя cruisecontrol (вошел ли он в систему как cruisecontrol или просто использует Run As), все выглядит нормально.

Так в чем мой вопрос? Хорошо, почему CCNet не использует пароль в файле конфигурации? Как ввод пароля в командной строке решил проблему (и будет ли она сохраняться)?

Любые предложения / понимание приветствуется.

Answer 1

Хммм - я мог ответить на свой вопрос здесь (или нет, покажет время).

По какой-то причине CCNet, похоже, не использует учетные данные в файле конфигурации (не знаю почему). Когда он вызывает SVN, он ожидает ввода пароля, даже если пользователь не видит его, а затем время ожидания, когда он его не получает.

При доступе к SVN из командной строки отображается пароль и его можно ввести, кроме того, пароль кэшируется в% app_data% \ Subversion \ auth \ svn.simple внутри зашифрованного файла для этого пользователя. Вот почему последующие команды не запрашивают пароль и почему консольное приложение будет работать без проблем.

Я собираюсь настроить CCService сейчас, так что, надеюсь, это будет работать так же, как консольное приложение сейчас.

Если у вас был подобный опыт, пожалуйста, дайте мне знать. Тем временем я могу поднять проблему с ThoughtWorks.

Answer 2

Относится к ответу Фредерика. На нашем сервере мы указываем учетные данные subversion в самом проекте. Блок sourcecontrol для одного из этих проектов будет выглядеть примерно так:

<sourcecontrol type="svn">
    <trunkUrl>http://myserver/svn/myproject/trunk</trunkUrl>
    <workingDirectory>C:\source\MyProject</workingDirectory>
    <username>foo</username>
    <password>bar</password>
    <autoGetSource>true</autoGetSource>
</sourcecontrol>

Answer 3

Насколько я помню, когда вы запускаете cc.net как сервис, он использует другой конфигурационный файл, тогда как вы запускаете его как консольное приложение. (ccservice.exe.config вместо cc.exe.config).

Answer 4

Дэйв, Довольно просто диагностировать, использует ли CruiseControl пароль в файле конфигурации или нет, поскольку вы увидите командную строку в журнале, а также фактический параметр пароля и пароль, если он используется и передан в svn. Если у вас есть пароль и пользователь в файле конфигурации, и они не передаются, первое, что я хотел бы проверить, это то, что ваш файл конфигурации действителен, а файл конфигурации в файловой системе - это то, что фактически используется. Если вы вносите недопустимое изменение в файл конфигурации, CC.NET просто игнорирует его, пока служба работает, и просто продолжает использовать версию, которую она кэшировала внутри, без каких-либо предупреждений или сообщений. Опять же, единственный способ проверить это - просмотреть конфигурацию через веб-панель мониторинга и убедиться, что она отражает то, что вы ожидаете, иначе вы можете отскочить от службы, и в этот момент она остановится и укажет на вашу ошибку. В конце концов, хотя вы можете обойти это, как вы сделали, кэшируя пароль с помощью Subversion.