Дженкінс в ОС X: xcodebuild дає помилку з кодовим знаком

Підсумок:

Налаштування Дженкінса на OS X було значно спрощено з останнім інсталятором ( станом на 1.449 - 9 березня 2012 р. ), Проте керувати процесом підписання коду все ще дуже складно, без прямої відповіді.

Мотивація:

Запустіть безголовий сервер CI, який дотримується загальних найкращих практик роботи служб на OS X ( Деякі з них пояснюються тут простою мовою ).

Фон:

• 12 жовтня 2009 р. - Як автоматизувати побудову додатків для iPhone за допомогою Хадсона
• 15 червня 2011 р. - Дженкінс на Mac OS X; git w / ssh відкритий ключ
• 23 червня 2011 р. - безперервна розгортання додатків для iOS за допомогою Jenkins та TestFlight
• 26 липня 2011 р. - Пропущені сертифікати та ключі в брелоку під час використання Дженкінса / Хадсона як безперервної інтеграції для розробки iOS та Mac
• 30 серпня 2011 р. - Не знайдено файл із забезпеченням коду у Дженкінса
• 20 вересня 2011 р. - як налаштувати Дженкінс CI на Mac
• 14 вересня 2011 - Запуск Дженкінса на Mac
• 12 листопада 2011 року - Howto: Встановіть Jenkins на OS X і змусьте її створювати Mac-матеріали
• 23 січня 2012 р. - зміни майбутніх установців Jenkins OSX
• 7 березня 2012 р. - Дякуємо за використання інсталятора OSX

Процес:

Встановіть Jenkins CI через OS X установчого пакета . Для кроку "Тип встановлення" натисніть кнопку Налаштувати та виберіть "Почати з завантаження як" jenkins ".

Обговорення:

Наївне сподівання в цей момент полягало в тому, що проект вільного стилю зі сценарієм зборки xcodebuild -target MyTarget -sdk iphoneosповинен працювати. Як зазначено в назві цієї публікації, вона не спрацьовує:

Code Sign error: The identity 'iPhone Developer' doesn't match any valid certificate/private key pair in the default keychain

Досить очевидно, що має відбутися - вам потрібно додати дійсний сертифікат підпису коду та приватний ключ у брелок за замовчуванням. Досліджуючи, як цього досягти, я не знайшов рішення, яке б не відкривало систему до певного рівня вразливості.

Проблема 1: Немає брелока за замовчуванням для демона jenkins

sudo -u jenkins security default-keychain ... виходить "Не вдалося знайти брелок за замовчуванням"

Як зазначав нижче Іво Дангт , UserShell встановлений на / usr / bin / false для демона jenkins (я думаю, це функція, а не помилка); дотримуйтесь його відповіді, щоб змінити UserShell на bash. Потім ви можете використовуватись sudo su jenkinsдля входу в систему як користувача jenkins та отримати підказку bash.

1. sudo su jenkins
2. cd ~/Library
3. mkdir Keychains
4. cd Keychains
5. security create-keychain <keychain-name>.keychain
6. security default-keychain -s <keychain-name>.keychain

Гаразд, чудово. Зараз у нас є брелок за замовчуванням; давайте рухатимемось праворуч? Але, по-перше, чому ми навіть турбувались робити брелок за замовчуванням?

Майже всі відповіді, пропозиції чи бесіди, які я читав під час дослідження, свідчать про те, що потрібно просто зафіксувати свої сертифікати та ключі для підпису коду в системний брелок. Якщо ви працюєте security list-keychainsяк проект у вільному стилі в Дженкінсі, ви бачите, що єдиний доступний брелок - це системний брелок; Я думаю, що саме там більшість людей виникла ідея поставити там свій сертифікат і ключ. Але це здається дуже поганою ідеєю - особливо враховуючи, що вам потрібно буде створити звичайний текстовий скрипт із паролем, щоб відкрити брелок .

Проблема 2: Додавання сертифікатів підпису коду та приватного ключа

Ось тут я справді починаю скупитися. У мене є відчуття, що я повинен створити новий публічний / приватний ключ, унікальний для використання з Дженкінсом. Моя думка полягає в тому, що якщо демон демону Дженкінса порушений, я можу легко відкликати сертифікат на порталі надання послуг Apple і генерувати інший публічний / приватний ключ. Якщо я використовую той самий ключ та сертифікат для свого облікового запису користувача та Jenkins, то це означає більше клопоту (пошкодження?), Якщо напад на службу jenkins.

Вказуючи на відповідь Саймона Урбанека, ви розблокуєте брелок із сценарію із простим текстовим паролем. Здається безвідповідальним зберігати що-небудь, крім "одноразових" сертифікатів і ключів у брелоку демона демона.

Мене дуже цікавить будь-яка дискусія, що суперечить. Я надто обережний?

Щоб створити новий КСВ як демон Дженкіна в Терміналі, я зробив наступне ...

1. sudo su jenkins
2. certtool r CertificateSigningRequest.certSigningRequest Вам буде запропоновано наступне (більшість із них я зробив освічені здогадки за правильною відповіддю; чи ви краще розумієте? Будь ласка, поділіться.) ...
   • Введіть ключ та ярлик сертифіката:
   • Вибір алгоритму: r(для RSA)
   • Введіть розмір ключа у бітах: 2048
   • Виберіть алгоритм підпису: 5(для MD5)
   • Введіть рядок виклику:
   • Потім купа питань для RDN
3. Подайте згенерований файл CSR (CertificateSigningRequest.certSigningRequest) на Портал надання послуг Apple під новим Apple ID
4. Підтвердьте запит та завантажте файл .cer
5. security unlock-keychain
6. security add-certificate ios_development.cer

Це робить нас на крок ближче ...

Проблема 3: Надання профілю та розблокування брелка

Я створив спеціальний профіль резервування на Порталі забезпечення лише для використання з CI, сподіваючись, що якщо трапиться щось погане, я зробив вплив трохи меншим. Найкраща практика або надмірно обережна?

1. sudo su jenkins
2. mkdir ~/Library/MobileDevice
3. mkdir ~/Library/MobileDevice/Provisioning\ Profiles
4. Перемістіть профіль резервування, встановлений на порталі надання, у цю нову папку. Зараз ми знаходимося в двох коротких кроках від того, щоб можна запустити xcodebuild з командного рядка як jenkins, і це означає, що ми також близькі до того, щоб отримати можливість керувати конструкціями Jenkins CI.
5. security unlock-keychain -p <keychain password>
6. xcodebuild -target MyTarget -sdk iphoneos

Тепер ми отримуємо успішне складання з командного рядка при вході в систему як демон демону, тому якщо ми створимо проект у вільному стилі та додамо ці останні два кроки (№5 та №6 вище), ми зможемо автоматизувати будівництво наш iOS проект!

Це може не бути необхідним, але я почував себе кращим, щоб повернути jenkins UserShell назад до / usr / bin / false після того, як я успішно отримав усі ці налаштування. Я параноїк?

Проблема 4: Брелок за замовчуванням досі недоступний!

( EDIT: Я розмістив зміни до свого запитання, перезавантажив, щоб переконатися, що рішення було 100%, і, звичайно, я залишив крок )

Навіть після всіх описаних вище кроків вам потрібно буде змінити список запуску Daemon за адресою /Library/LaunchDaemons/org.jenkins-ci.plist, як зазначено у цій відповіді . Зверніть увагу, це також помилка openrdar .

Це повинно виглядати так:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
        <key>EnvironmentVariables</key>
        <dict>
                <key>JENKINS_HOME</key>
                <string>/Users/Shared/Jenkins/Home</string>
        </dict>
        <key>GroupName</key>
        <string>daemon</string>
        <key>KeepAlive</key>
        <true/>
        <key>Label</key>
        <string>org.jenkins-ci</string>
        <key>ProgramArguments</key>
        <array>
                <string>/bin/bash</string>
                <string>/Library/Application Support/Jenkins/jenkins-runner.sh</string>
        </array>
        <key>RunAtLoad</key>
        <true/>
        <key>UserName</key>
        <string>jenkins</string>
        <!-- **NEW STUFF** -->
        <key>SessionCreate</key>
        <true />
</dict>
</plist>

За допомогою цього налаштування я також рекомендую плагін Xcode для Jenkins , що робить налаштування сценарію xcodebuild трохи простішим. На даний момент я також рекомендую прочитати сторінки чоловіків для xcodebuild - пекло ви це зробили так далеко в Терміналі, правда?

Ця установка не є ідеальною, і будь-яка порада чи розуміння дуже цінується.

Мені важко було вибрати "правильну" відповідь, оскільки те, що я почав використовувати для вирішення своєї проблеми, було збіркою інформації про кожного. Я намагався дати кожному принаймні проголосувати, але нагородив Саймоном відповідь, оскільки він здебільшого відповів на початкове запитання. Крім того, Самі Тікка заслуговує великої заслуги на свої зусилля змусити Дженкінса працювати через AppleScript як звичайний додаток OS X. Якщо ви тільки зацікавлені в тому, щоб підняти Дженкінса і швидко пройти в рамках свого сеансу користувача (тобто не як безголовий сервер), його рішення набагато більше схоже на Mac.

Я сподіваюсь, що мої зусилля викликають подальше обговорення та допоможуть наступній бідній душі, яка змушена думати, що вони зможуть влаштувати програму Jenkins CI для своїх проектів на iOS у вихідні через усі чудові речі, які вони про них чули.

Оновлення: 9 серпня 2013 року

Маючи таку кількість нагород та фаворитів, я думав, що повернусь до цього 18 місяців пізніше, коли я отримав кілька коротких уроків.

Урок 1: Не піддавайте Дженкінса публічному Інтернету

На 2012 WWDC я поставив це питання інженерам Xcode та OS X Server. Я отримав какофонію "не роби цього!" від кого б я не питав. Вони погодилися, що процес автоматизованої збірки був чудовим, але сервер повинен бути доступний лише в локальній мережі. Інженери OS X Server запропонували дозволити віддалений доступ через VPN.

Урок 2: Зараз є нові варіанти встановлення

Нещодавно я розповів CocoaHeads про свій досвід Дженкінса, і, на моє здивування, я знайшов нові методи встановлення - Homebrew і навіть версію магазину додатків Bitnami Mac . Це, безумовно, варто перевірити. Джонатан Райт має суть, в якій детально описує роботу доморощеного Дженкінса .

Урок 3: Ні, серйозно, не виставляйте свій збірник в Інтернеті

З оригіналу повідомлення досить зрозуміло, що я не системний адміністратор і не експерт із безпеки. Здоровий глузд щодо приватних матеріалів (брелоки, облікові дані, сертифікати тощо) залишив мене дуже непростим щодо розміщення моєї коробки Дженкінса в Інтернеті. Нік Арнотт з «Нехтуваного потенціалу» зміг досить легко підтвердити моїх гебі-джибі в цій статті .

TL; DR

Моя рекомендація іншим, хто прагне автоматизувати процес збирання, змінилася за останні півтора року. Переконайтесь, що ваша машина Дженкінса знаходиться за вашим брандмауером. Встановіть і налаштуйте Дженкінса як відданого користувача Дженкінса, використовуючи інсталятор, версію магазину програм Bitnami Mac, AppleScript Самі Тікки тощо; це вирішує більшу частину головного болю, про який я детально описувався вище. Якщо вам потрібен віддалений доступ, налаштування служб VPN в OS X Server займає десять хвилин. Я використовую цю установку вже більше року і дуже задоволений нею. Удачі!

Брелоки потрібно розблокувати, перш ніж їх можна використовувати. Ви можете використовувати security unlock-keychainдля розблокування. Це можна зробити інтерактивно (безпечніше) або вказавши пароль в командному рядку (небезпечно), наприклад:

security unlock-keychain -p mySecretPassword...

Очевидно, що введення цього сценарію загрожує безпеці цього брелка, тому люди часто встановлюють окремий брелок лише з обліковими записами для підписання, щоб мінімізувати такий збиток.

Зазвичай у Terminalбрелок вже розблоковано ваш сеанс, оскільки брелок за замовчуванням розблокований під час входу, тому вам не потрібно цього робити. Однак будь-який процес, не запущений у вашому сеансі, не матиме розблокованої брелок брелоків, навіть якщо він є вами як користувач (найчастіше це стосується ssh, але і будь-який інший процес).

Припустимо, ви також хочете займатися спеціальним розповсюдженням через Дженкінса, це вимагає, щоб Дженкінс мав доступ до сертифікату розповсюдження та ідентифікації адміністратора команди на додаток до профілів резервування.

Використовуючи експортовану ідентичність у файлі .cer, ви можете програмно імпортувати його так, перемикач -A дозволяє надати всім програмам доступ до цього запису. Крім того, ви можете використовувати кілька -T /path/to/programкомутаторів для дозволу codesignта xcodebuildдоступу.

$ security import devcertificate.cer -k jenkins.keychain -A

Звичайно, у нас також повинен бути сертифікат Apple WWDCRA, імпортований приблизно так само:

$ security import AppleWWDRCA.cer -k jenkins.keychain -A

Однак нам також потрібен приватний ключ для devcertificate.cer. Для цього потрібно експортувати відповідний приватний ключ у вигляді .p12 ключа та встановити пароль. Помістіть його десь, ви можете отримати доступ до нього зі своєї оболонки Дженкінса, розблокувати брелок та імпортувати його:

$ security unlock-keychain -p YourKeychainPass jenkins.keychain
$ security import devprivatekey.p12 -k login.keychain -P ThePasswordYouSetWhenExporting -A

Імпорт сертифікату розповсюдження працює аналогічно. Я не знаю, чому вам потрібно розблокувати брелок для імпорту .p12, а не для .cer, але добре.

Вам також знадобиться доступ до профілів резервування, я незабаром відредагую ці інструкції в цій публікації.

У мене був той самий питання, і я вже деякий час шукаю відповіді. Ось одне, що я навчився.

Я працюю як jenkins як користувач jenkins, користувач, створений інсталятором, і, як усі інші згадували, він не має доступу до тієї ж брелки, що і ваш звичайний користувач. Замість того, щоб намагатися увійти як користувач jenkins, я створив другий проект збірки, який просто має один крок збірки, це "Виконати оболонку", в якому я виконую команди, які хочу перевірити як користувач jenkins.

Після того, як я встановив це, я міг запустити команду

security list-keychains

І це виявило мені, що єдине, що могли бачити дженкіни, - це системний брелок.

+ security list-keychains
    "/Library/Keychains/System.keychain"
    "/Library/Keychains/System.keychain"

Маючи ці знання, я відкрив додаток Keychain Access і скопіював свій сертифікат "iPhone Developer: xxxx" в системний брелок (клацніть правою кнопкою миші, скопіюйте з брелка "Логін").

Через це я передав помилку знаку коду пари сертифіката / приватного ключа, але відкрив ще один із профілем надання (схоже, подібний, але інший випуск).

Щоб змінити пароль, який ви можете використовувати sudo passwd jenkins <new-pw>. Однак я думаю, що для зміни пароля було б краще використовувати команду dscl.

У моїй установці jenkins (офіційний інсталятор) мав оболонку користувача / usr / bin / false. Змінивши його на bash, вирішила проблему неможливості увійти:

sudo dscl . -change /Users/jenkins UserShell /usr/bin/false /bin/bash

Тепер ви можете мати можливість увійти в систему su jenkins.

Я використовував плагін Xcode для створення програми для iOS. У конфігурації проекту.

виберіть пункт Додати крок складання> Xcode> підписання коду та параметри брелока OS X.

поставте галочку Розблокувати вікно брелока та додайте наступне (для прикладів)

інколи, якщо я отримаю помилку

Помилка знаку коду: ...

Я знову відкрию Дженкінса і знову введу пароль, щоб розблокувати

Для людей, які мають проблеми з брелками, я рекомендую спробувати інший інсталятор Jenkins за адресою https://github.com/stisti/jenkins-app , завантаження за адресою https://github.com/stisti/jenkins-app/downloads

Jenkins.app запускає Дженкінса у вашому сеансі користувача, тому проблеми доступу з брелоками не є проблемою :)

Якщо у вас є sudo, ви можете використовувати passwd, щоб змінити пароль користувача Jenkins. Тоді ви можете отримати пароль Дженкінса.

Крім того, я не впевнений, чи це проблема для вас, але сценарій ANT, який я використовую через Дженкінса, має таке:

<target name="unlock_keychain">
    <exec executable="security">
        <arg value="-v"/>
        <arg value="unlock-keychain"/>          
        <arg value="-p"/>
        <arg value="<My Password>"/>
        <arg value="/Users/macbuild/Library/Keychains/login.keychain"/>
    </exec>
</target>

Чомусь утиліта "безпеки" не працювала для мене на Lion із свіжою установкою Jenkins.

Після "sudo su jenkins" він зміг створити новий брелок, але мовчки проігнорував усі команди "keychain -s ..." або "unlock", повертаючи нульовий статус виходу і нічого не друкуючи на консоль. Перелік ключових ланцюжків за замовчуванням або вхід не давав нічого, список пошукових брелоків містив лише системну брелок, і я не міг змінити це, що б я не вводив.

Після того як я увійшов на робочий стіл цього користувача і запустив утиліту Keychain, він показав створений брелок, після чого все працювало так, як описано у верхніх публікаціях.

Мені цікаво, чи змінилася якась початкова поведінка брелоків у Лева, чи я щось пропускаю?

Я додав приватний та відкритий ключ компанії до брелка. Я додав профілі забезпечення виробництва, яке буду будувати.

Оскільки у цього користувача не було облікового запису, я ввійшов у програму devcenter зі своїм акаунтом. Завантажили сертинг резервування та завантажили їх у Xcode.

Я не додав сертифікат спеціально для рольового облікового запису, наприклад. джинкіни.

Я додав це до сценарію збірки: безпека розблокування-брелок -p mySecretPassword, як вище, але ...

Я створив файл ~ / .ssh / mypass і додав пароль до файлу.

Тоді команда стає: безпека unlock-keychain -p cat ~/.ssh/mypass

Будинки працюють як шампіньон. Я отримую файл ipa, він завантажується в центральній програмі та працює на пристрої.

Можна також встановити та запустити JenkinsCI як користувача OS X замість демон:

1. встановити jenkins за допомогою офіційного інсталятора ( https://jenkins-ci.org/ )
   • Клацніть далі
   • Натисніть "Налаштувати"
   • Зніміть позначку "Почати з завантаження як" jenkins "- * ВАЖЛИВО * Ця опція зазвичай дозволяє безголові джинкіни, які не працюють добре з доступом до брелоків
2. Запуск http://127.0.0.1:8080
   • переконайтеся, що НЕ запускається
   • може знадобитися зупинити джинкіни sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
3. Подвійне клацання /Applications/Jenkins/jenkins.war
   • Звичайно, це потрібно автоматизувати для запуску @ запуску
4. відчинено http://127.0.0.1:8080
   • переконайтеся, що він зараз працює

Щоб вирішити цю проблему, спробуйте увійти на сторінку http://appleid.apple.com та оновіть питання безпеки.

Це мені допомогло.