Кратко о используемых конфигурациях:
Машина с установленной JIRA:
- Windows Server 2008 R2 x64
- Atlassian JIRA Standalone (v4.1.1#522)
Машина с MS SQL
- Windows 7 Ultimate x32
- Microsoft SQL Server 2008 (SP1) - 10.0.2531.0 (Intel X86)
Обе машины виртуалки, обе для разминок, поэтому ответ на вопрос, почему всё именно так, будет прост - потому что для разминок и так пойдет.
Для начала я ознакомился с первой инструкцией и соответственно со второй тоже.
Итак, следуя второй инструкции, для начала нам нужно:
- сделать бэкап существующей конфингурации. С этим проблем никаких, разве что с первой попытки сделать бэкап не получилось, потому что оказалось, что нужно явно указать в файле c:\Program Files (x86)\Atlassian\JIRA 4.1.1\atlassian-jira\WEB-INF\classes\jira-application.properties путь к папке, где у нас будет лежать бэкап и перезапустить Жиру. Потом перелогиниться, и со второй попытки сделать бэкап.
- настроить MS SQL. Тут тоже всё просто: выполняем с 1 - 3 пункт, остальные по мере необходимости. Я выбрал интегрированную проверку подлинности, поэтому пункт 2 у меня выглядел иначе: я добавил на сервер учетную запись, под которой запущена служба JIRA, замапил её к базе данных, и добавил её в группу db_owner. Пункт 7 я вообще не понял к чему.
- скачать и установить драйвер для MS SQL. Скачали. Надо распаковать и скопировать распакованный jtds-1.2.5.jar в папку lib. И тут у меня возник вопрос. В папке С:\Program Files (x86)\Atlassian\JIRA 4.1.1 аж 5 папок lib. Исключив наиболее неподходящие, я встал перед выбором: C:\Program Files (x86)\Atlassian\JIRA 4.1.1\lib\ или C:\Program Files (x86)\Atlassian\JIRA 4.1.1\atlassian-jira\WEB-INF\lib\. Внимательно приглядевшись к содержимому первой папки, я обнаружил в ней jtds-1.2.2.jar и решил, что эта папка именно та, которая мне нужна. Переименовал в ней jtds-1.2.2.jar в jtds-1.2.2.jar.bak и скопировал в неё новую версию драйвера. Полагаю, что без этого пункта вполне можно было обойтись.
- настроить JIRA для работы с MS SQL. Раз уж для конфигурирования мне предлагается утилита с графической оболочкой, грех ей не воспользоваться. Запускаю config.bat и... упс! В окне консоли замечаю появившуюся надпись: No JRE_HOME or JAVA_HOME environment variable is set - attempting to just run 'java' command. Хотя тулза запускается! Вот это да! Оказывается у меня при установке JDK не установились переменные окружения! Непорядок! Добавил переменную окружения, перезапустил тулзу - всё ОК, можно настраивать. Hostname - имя машины с SQL Server, порт - стандартный 1433, база - которую создали на втором шаге, имя пользователя... хм... а для интегрированной проверки подлинности имя пользователя и пароль нужно оставить пустыми. Оставляем. Но! Если вы запускаете утилиту от имени пользователя, у которого нет прав на доступ к SQL Server, кнопочка Test Connection станет бесполезна. Выхода два - либо разрешить доступ на SQL Server учетке, под которой настраиваем JIRA, либо тулзу запускать под учеткой, которой есть права доступ к SQL. Если с этим разобрались, нажимаем кнопочку Test Connection... И можем получить еще один упс: Could not connect to the DB: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property. Ага, кажется интегрированная аутентификация не работает - не находит нужную библиотеку. Смотрим внимательно на содержимое архива с драйвером SQL Server и видим в ней папочки IA64, x64 и x86, в которых и лежит заветная библиотека ntlmauth.dll. И снова вопрос - куда ее, родимую, и которую из них копировать? Методом научного тыка оказалось, что копировать надо в директорию JAVA_HOME/jre/bin и копировать ту, что в папочке x64 (капитан очевидность?). Скопировали, нажимаем кнопочку... ура, Connection successful! Для верности я жмакнул еще раз: Could not connect to the DB: I/O Error: SSO Failed: Native SSPI library not loaded. Check the java.library.path system property. Блин! Ладно, предположим это глюк. Нажимаем Save и выходим.
- настроить JIRA Entity Engine. Тут ничего особенного: находим файл, редактируем и сохраняем.
- перезапускаем JIRA.
И тут начались пляски с бубном:
Попробовал запустить службу с консоли - не запускается. Оказывается утилита для запуска сервера Tomcat, которая устанавливается инсталятором, собиралась под 32-х битную версию виртуальной машины Java, соответственно запустить службу с 64-х битной JVM не может. Поиски привели меня в репозиторий Tomcat, откуда были скачаны tomcat6.exe и tomcat6w.exe. Запуск с консоли в результате был успешным, а запуск службы приводил к той же ошибке. Отсутствие логов через какое-то время и какое-то количество установок и удалений служб и прочего ковыряния в реестре, все-таки запустило определенные мыслительные процессы у меня в голове: я догадался, что тупо не хватает прав на создание файлов!
Ну, а далее всё было просто - дал полный доступ к папке C:\Program Files (x86)\Atlassian для пользователя, под которым стартует служба JIRA, перезапустил службу - и, вуаля, появились логи! Открываю стартовую страницу и наконец-то вижу приглашение настроить JIRA. Далее следуя первой инструкции иду по ссылке Import your existing data и импортирую данные из созданного на первом шаге файла.
Квест пройден!
Кстати, раньше все работало потому, что при установке служба JIRA конфигурировалась на использование встроенной виртуальной машины, которая была 32-х битная, и запускалась служба под системной учетной записью.
P.S. У меня была свежеустановленная JIRA, потому тонкости с бэкапом и восстановлением вложений я не описал.
P.S.S. И снова здравствуйте! Теперь пришла пора разбираться с java.lang.OutOfMemoryError: PermGen space :)
