upgraded Jenkins && broken it && repaired succefully – день прожит не зря

День прожит не зря!

На сегодня я запланировал для себя ничего не кодить – давно было хотел поиграться плагином для XCode. Это было нужно для того, чтобы организовать нормальный процесс прогона юнит тестов на сборочном сервере. Вместе с установкой плагина решил естественным образом обновить и сам Jenkins и все плагины на него установленные. Сказано – сделано. Но меня ожидало несколько подводных камней.

1. Внезапно выяснилось, что Jenkins, установлен через homebrew. Это само по себе нормально, но просто я об этом не знал – изначально Jenkins устанавливал и настраивал не я и тот человек уже не работает с нами. Узнал я об этой особенности когда решил перед обновлением обновить еще и все пакеты homebrew.

Здесь надо заметить, что есть одна большая проблема, которая меня бесит на Маках после Линюкса. Пользователи Windows меня вряд ли поймут. В Mac OS X в отличие от линюксов нет пакетного репозитория, а есть AppStore, к сожалению это не одно и то же. Когда я хочу купить и/или установить Офисный пакет (ВЕСЬ офисный пакет), я могу согласиться, что App Store это нормально. Но когда я хочу установить только одну программу из этого офисного пакета, например, электронные таблицы но при этом мне нужен какой-то хитрый плагин, например, конвертации этих электронных таблиц из/в Lotus 1-2-3 очень старой версии. Что мне делать? Ставить ВСЕ? Зачем? А если я хочу, как в данном случае поставить Jenkins, да так, чтобы он регулярно обновлялся. Что мне делать? Господа из Apple, когда вы сделаете свой нормальный пакетный менеджер? Почему ваши пользователи вынуждены пользоваться сторонними решениями (homebrew, macports etc), которые между собой плохо совместимы? Простите, отвлекся 🙂

2. Оказалось, что Jenkins хоть и установлен через homebrew, запускается, не рекомендованным для данного варианта способом – при логине пользователя, а по правильному – при старте машины.

3. Оказалось, что Mac OS X имеет сильно непривычную для меня систему автозапуска приложений. До сих пор я наивно полагал, что там есть /etc/init.d/ :)) Ну, вообщем, мне потребовалось минут 30 и один рестарт мака для того, чтобы убедиться, что все работает.

После того, как я получил работающий Jenkins, я на него поставил XCode плагин, а затем еще и обновил все уставленные плагины. И это была моя роковая ошибка :))

Что произошло? с виду все работало нормально. Я нормально залогинился, я видел все джобы и сборки. Только я ничего не мог сделать. У меня не было не то что административных прав, у меня вообще никаких прав не было. Секунд 30 я втыкал непонимающими глазами на интерфейс Дженкинса. Перелогинился, но это не помогло. Я лишился всех прав!

Что делать? Стал думать. Обратил внимание, на то, что в правом-верхнем углу вместо привычного “bsi” написано “Sergey I. Borisov”. Начал что-то подозревать. Зрительно представил список плагинов, которые собирались обновиться и вспомнил, что среди них был плагин “active-directory“. Сразу предположил, что дело в нем. Смотрю на changelog этого плагина и замечаю, что в последней версии есть такой замечательный фикс:
Canonicalize the user name as per writtein AD, instead of using what the user gave us (issue #12607)

Да! Теперь уже точно нет сомнений – это он все сломал! На самом деле, раньше мы логинились через LDAP и права были назначены пользователям типа “bsi”, а теперь при логине такого пользователя плагин запрашивает у LDAP сервера каноническое имя, которое “Sergey I. Borisov”, а ему права никто не назначал. То есть, вообще, нет ни одно пользователя с административными правами.

Какие у меня есть варианты?

  1. руками в конфигурации подправить что нибудь
  2. вернуть старый плагин или просто получить данный плагин без фикса
  3. получить административные или монопольные права, и выставить права “новым пользователям”.

Отклонировал гит репозиторий, запускаю процесс сборки плагина. Maven могуч!

Пока он работает, посмотрел глазами конфиг, стало страшно. Решил не трогать.

Начал с последнего варианта. Полез гуглить как можно получить административные или монопольные права в Jenkins, нашел одну статейку, но почему-то, когда я залогинился под локальным администратором, я не получил возможность редактировать права остальных пользователей. Отметаем.

Заодно, запускаю процесс архивации всей папки Jenkins – раньше этим никто не занимался.

В процессе работы мавена оказалось, что у меня на этой машине нет JDK. Удивился. Потом вспомнил, что я на текущей работе не программирую на Java 🙂 Пришлось сделать apt-get install … 🙂

Пока все (maven и tar+gzip) работали, я увидел, что Jenkins-то правильный пацан! Он сделал бэкапы всех плагинов перед их апгрейдом. Так что дальше все было просто: дождался окончания бэкапа, развернул старую версию плагина, зашел со своим именем, теперь JenkinsId был “bsi”, у которого есть административные права, выставил административные права пользователю “Sergey I. Borisov”, заменил плагин на новый, вуаля – у меня есть права! :))

Есть минус у моего решения – всем пользователям (Слава Богу их немного – всего 7 человек) пришлось снова выставлять все права вручную. Начальник предлагал оставить старый плагин, чтобы все осталось как было. Но я думаю рано или поздно кто-то все равно обновит этот плагин. Хотя-бы по необходимости, например, что API новой версии Jenkins стал несовместим со старым плагином.

Жаль, что так и не успел поиграться с XCode плагином – у меня сегодня был короткий рабочий день из-за накладки рабочей субботы с занятиями по расписанию в ТУСУР. В отчете на рабочий день так и написал:

upgraded Jenkins && broken it && repared succefully

P.S.: Как оказалось, я не один такой. Народ уже обнаружил и предложил несколько воркэроундов. Сразу не догадался туда глянуть :))

Update 2012-05-11: Множественные запросы пользователей вынудили автора откатить фикс. И вот в версии 1.28 от 7 мая этого фикса нет. Придется снова накатывать свежую версию и давать права пользователям со старым написанием имени. А жаль.

Leave a Reply