tipos señas palabras lenguaje importancia definicion curso caracteristicas macos jenkins

macos - palabras - Jenkins en OS X: xcodebuild da error de código de señas



lenguaje de señas universal (11)

Agregué la clave privada y pública para la empresa al llavero. Agregué los perfiles de provisión para la producción que construiré.

Como este usuario no tenía una cuenta, inicié sesión en devcenter con mi cuenta. Descargó los certificados de aprovisionamiento y los cargó en Xcode.

No agregué un certificado específicamente para la cuenta de función de compilación, ej. Jenkins.

Añadí esto al guión de compilación: security unlock-keychain -p mySecretPassword como se indicó anteriormente, pero ...

Creé un archivo ~ / .ssh / mypass y agregué la contraseña al archivo.

Entonces, el comando se convierte en: security unlock-keychain -p cat ~/.ssh/mypass

Las construcciones funcionan como un campeón. Obtengo el archivo ipa, se carga en la aplicación central y funciona en el dispositivo.

Resumen:

La configuración de Jenkins en OS X se hizo mucho más fácil con el instalador más reciente ( desde 1.449 hasta el 9 de marzo de 2012 ), sin embargo, la gestión del proceso de firma de código sigue siendo muy difícil sin una respuesta directa.

Motivación:

Ejecute un servidor de CI sin interfaz que siga las mejores prácticas comunes para ejecutar servicios en OS X ( algunas de las cuales se explican aquí en lenguaje sencillo ).

Fondo:

Proceso:

Instale Jenkins CI mediante el paquete de instalador OS X. Para el paso "Tipo de instalación", haga clic en el botón Personalizar y seleccione "Comenzar en el arranque como ''jenkins''".

Discusión:

La ingenua expectativa en este punto era que un proyecto de estilo libre con el script de xcodebuild -target MyTarget -sdk iphoneos debería funcionar. Como se indica en el título de esta publicación, no funciona y falla con:

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

Es bastante obvio lo que necesita suceder: debe agregar un certificado de firma de código válido y una clave privada en el llavero predeterminado. Al investigar cómo lograr esto, no he encontrado una solución que no abra el sistema a algún nivel de vulnerabilidad.

Problema 1: Ningún llavero por defecto para jenkins daemon

sudo -u jenkins security default-keychain ... produce "No se pudo encontrar un llavero predeterminado"

Como señala Ivo Dancet , el UserShell está configurado en / usr / bin / false para el daemon jenkins de forma predeterminada (creo que esta es una característica, no un error); sigue su respuesta para cambiar el UserShell a bash. A continuación, puede usar sudo su jenkins para iniciar sesión como usuario de jenkins y obtener un aviso de 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

Bien, excelente. Tenemos un llavero predeterminado ahora; sigamos adelante ¿verdad? Pero, primero, ¿por qué nos molestamos en hacer un llavero por defecto?

Casi todas las respuestas, sugerencias o conversaciones que leí a lo largo de la investigación sugieren que uno debería simplemente arrojar sus certificados y claves de firma de código en el llavero del sistema. Si ejecuta security list-keychains como un proyecto de estilo libre en Jenkins, verá que el único llavero disponible es el llavero del sistema; Creo que ahí es donde a la mayoría de las personas se le ocurrió la idea de poner su certificado y clave allí. Pero, esto parece una muy mala idea, especialmente dado que tendrás que crear un script de texto plano con la contraseña para abrir el llavero .

Problema 2: Agregar certificados de firma de código y clave privada

Aquí es donde realmente empiezo a sentirme aprensivo. Tengo la intuición de que debería crear una nueva clave pública / privada única para usar con Jenkins. Mi proceso de pensamiento es si el daemon jenkins está comprometido, entonces puedo revocar fácilmente el certificado en el Portal de Aprovisionamiento de Apple y generar otra clave pública / privada. Si utilizo la misma clave y el mismo certificado para mi cuenta de usuario y para Jenkins, significa más molestias (¿daño?) Si se ataca el servicio jenkins.

Señalando la respuesta de Simon Urbanek, desbloqueará el llavero de un script con una contraseña de texto sin formato. Parece irresponsable guardar todo lo que no sean certificados y llaves "desechables" en el llavero de jenkins daemon.

Estoy muy interesado en cualquier discusión en contrario. ¿Estoy siendo demasiado cauteloso?

Para hacer una nueva CSR como el daemon jenkins en la Terminal I hice lo siguiente ...

  1. sudo su jenkins
  2. certtool r CertificateSigningRequest.certSigningRequest Se le solicitará lo siguiente (la mayoría de estos hice conjeturas con la respuesta correcta; ¿tiene mejor conocimiento? Por favor comparta).
    • Introduzca la clave y la etiqueta del certificado:
    • Seleccionar algoritmo: r (para RSA)
    • Ingrese el tamaño de la clave en bits: 2048
    • Seleccione el algoritmo de firma: 5 (para MD5)
    • Ingrese la cadena de desafío:
    • Entonces un montón de preguntas para RDN
  3. Envíe el archivo CSR generado (CertificateSigningRequest.certSigningRequest) al Portal de aprovisionamiento de Apple con una nueva ID de Apple.
  4. Aprobar la solicitud y descargar el archivo .cer
  5. security unlock-keychain
  6. security add-certificate ios_development.cer

Esto nos lleva un paso más cerca ...

Problema 3: perfil de provisión y desbloqueo de llavero

Hice un perfil especial de aprovisionamiento en el Portal de Aprovisionamiento solo para utilizarlo con CI con la esperanza de que, si algo malo sucede, he reducido el impacto un poco. ¿Buena práctica o demasiado cauteloso?

  1. sudo su jenkins
  2. mkdir ~/Library/MobileDevice
  3. mkdir ~/Library/MobileDevice/Provisioning/ Profiles
  4. Mueva el perfil de provisión que configura en el Portal de Aprovisionamiento a esta nueva carpeta. Ahora estamos a dos pasos de poder ejecutar xcodebuild desde la línea de comando como jenkins, y eso significa que también estamos cerca de lograr que el Jenkins CI ejecute compilaciones.
  5. security unlock-keychain -p <keychain password>
  6. xcodebuild -target MyTarget -sdk iphoneos

Ahora tenemos una compilación exitosa desde una línea de comando cuando inicia sesión como el daemon jenkins, por lo que si creamos un proyecto de estilo libre y agregamos esos dos pasos finales (n. ° 5 y n. ° 6 anteriores), podremos automatizar la construcción de nuestro proyecto iOS

Puede que no sea necesario, pero me sentí mejor configurando jenkins UserShell en / usr / bin / false después de obtener con éxito toda esta configuración. ¿Estoy siendo paranoico?

Problema 4: el llavero predeterminado aún no está disponible.

( EDIT: publiqué las ediciones de mi pregunta, reinicié para asegurarme de que mi solución era 100% y, por supuesto, dejé de lado un paso )

Incluso después de todos los pasos anteriores, tendrá que modificar el lanzamiento de Daemon plist en /Library/LaunchDaemons/org.jenkins-ci.plist como se indica en esta respuesta . Tenga en cuenta que esto también es un error openrdar .

Debe tener un aspecto como este:

<?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>

Con esta configuración, también recomendaría el complemento Xcode para Jenkins , lo que hace que la configuración del script xcodebuild sea un poco más fácil. En este punto, también recomendaría leer las páginas de manual para xcodebuild - demonios llegaste tan lejos en Terminal, ¿verdad?

Esta configuración no es perfecta, y cualquier consejo o idea es muy apreciada.

Me ha costado seleccionar una respuesta "correcta", ya que lo que he venido a usar para resolver mi problema era una recopilación de las opiniones de casi todos. Intenté darles a todos por lo menos un voto positivo, pero otorgué la respuesta a Simon porque respondió la pregunta original en su mayoría. Además, Sami Tikka merece mucho crédito por sus esfuerzos para lograr que Jenkins trabaje a través de AppleScript como una simple aplicación de OS X. Si solo está interesado en poner a Jenkins en marcha rápidamente dentro de su sesión de usuario (es decir, no como un servidor sin cabeza) su solución es mucho más parecida a Mac.

Espero que mis esfuerzos provoquen una mayor discusión y ayuden a la próxima pobre alma que venga a pensar que pueden obtener la configuración de Jenkins CI para sus proyectos de iOS en un fin de semana debido a todas las cosas maravillosas que han escuchado al respecto.

Actualización: 9 de agosto de 2013

Con tantos votaciones y favoritos, pensé que volvería a esto 18 meses después con algunas breves lecciones aprendidas.

Lección 1: No expongas a Jenkins a Internet público

En la WWDC 2012 llevé esta pregunta a los ingenieros de Xcode y OS X Server. Recibí una cacofonía de "¡no hagas eso!" de cualquier persona que pregunté. Todos estuvieron de acuerdo en que un proceso de compilación automatizado fue excelente, pero que el servidor solo debería poder accederse en la red local. Los ingenieros de OS X Server sugirieron permitir el acceso remoto a través de VPN.

Lección 2: ahora hay nuevas opciones de instalación

Recientemente di una charla sobre CocoaHeads sobre mi experiencia en Jenkins, y para mi sorpresa encontré algunos métodos de instalación nuevos: Homebrew e incluso una versión de Bitnami Mac App Store . Definitivamente vale la pena echarle un vistazo. Jonathan Wright tiene una esencia que detalla el funcionamiento de Homebrew Jenkins .

Lección 3: No, en serio, no expongas tu caja de construcción a Internet

De la publicación original queda bastante claro que no soy administrador de sistemas ni experto en seguridad. El sentido común sobre cosas privadas (llaveros, credenciales, certificados, etc.) me hizo sentir bastante incómodo acerca de poner mi caja de Jenkins en internet. Nick Arnott en Neglected Potential fue capaz de confirmar mi heebie-jeebies con bastante facilidad en este artículo .

TL; DR

Mi recomendación para otros que buscan automatizar su proceso de construcción ha cambiado en el último año y medio. Asegúrese de que su máquina Jenkins esté detrás de su firewall. Instale y configure Jenkins como un usuario dedicado de Jenkins, ya sea utilizando el instalador, la versión de Bitnami Mac App Store, AppleScript de Sami Tikka, etc .; esto resuelve la mayor parte del dolor de cabeza que detallo arriba. Si necesita acceso remoto, la configuración de servicios VPN en OS X Server toma diez minutos como máximo. He estado utilizando esta configuración durante más de un año y estoy muy contento con ella. ¡Buena suerte!

He tenido el mismo problema y he estado buscando por algún tiempo una respuesta. Aquí hay algo que aprendí.

Estoy ejecutando a jenkins como usuario de jenkins, usuario creado por el instalador, y como todos los demás han mencionado, no tiene acceso al mismo llavero que su usuario normal. En lugar de tratar de iniciar sesión como el usuario de jenkins, creé un segundo proyecto de compilación que simplemente tiene un paso de compilación que es "Ejecutar Shell" en el que ejecuto los comandos que deseo probar como el usuario de jenkins.

Una vez que tuve esa configuración, pude ejecutar el comando

security list-keychains

Y esto me reveló que lo único que podían ver los jenkins era el llavero del sistema.

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

Con ese conocimiento, abrí la aplicación Keychain Access y copié mi certificado "iPhone Developer: xxxx" en el llavero del sistema (clic con el botón derecho y copia desde el llavero de "inicio de sesión").

Esto hizo que pasara el error de signo de código de par de certificado / clave privada pero abrió otro con el perfil de aprovisionamiento (parece un problema similar pero diferente).

He usado el complemento de Xcode para crear una aplicación de iOS. En la configuración de un proyecto.

elija Agregar paso de compilación> Xcode> firma de código y opciones de llavero de OS X.

marque la casilla Desbloquear llavero y añádalo como se indica a continuación (para ver ejemplos)

a veces, si obtengo el error

Error de signo de código: ...

Reabriré Jenkins e ingresaré la contraseña nuevamente para desbloquear

Los llaveros deben desbloquearse antes de que puedan ser utilizados. Puede usar security unlock-keychain de desbloqueo de security unlock-keychain para desbloquear. Puede hacerlo interactivamente (más seguro) o especificando la contraseña en la línea de comando (inseguro), por ejemplo:

security unlock-keychain -p mySecretPassword...

Obviamente, poner esto en un script compromete la seguridad de ese llavero, por lo que a menudo las personas configuran un llavero individual con solo las credenciales de firma para minimizar dicho daño.

Normalmente, en la Terminal el llavero ya está desbloqueado en la sesión, ya que el llavero predeterminado está desbloqueado al iniciar sesión, por lo que no es necesario que lo haga. Sin embargo, cualquier proceso que no se ejecute en su sesión no tendrá llavero desbloqueado, incluso si lo tiene como usuario (lo más común es que afecte a ssh , pero también a cualquier otro proceso).

Para cambiar la contraseña, puede usar sudo passwd jenkins <new-pw> . Sin embargo, creo que sería mejor usar el comando dscl para cambiar la contraseña.

En mi instalación, jenkins (instalador oficial) tenía un usuario shell / usr / bin / false. Cambiarlo a bash resolvió el problema de no poder iniciar sesión:

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

Ahora debería poder iniciar sesión con su jenkins .

Para resolver este problema, intente iniciar sesión en http://appleid.apple.com y actualice sus preguntas de seguridad.

Me ayudó.

Por alguna razón, la utilidad de "seguridad" no funcionaba para mí en Lion con la nueva instalación de Jenkins.

Después de "sudo su jenkins" fue capaz de crear un nuevo llavero, pero silenciosamente ignoró todos los comandos "default-keychain -s ..." o "unlock" devolviendo el estado de salida cero e imprimiendo nada a la consola. El listado de llaveros por defecto o de inicio de sesión no dio nada, la lista de búsqueda de llaveros contenía solo el llavero del sistema, y ​​no pude cambiar esto, sea lo que sea que escribí.

Después de iniciar sesión en el escritorio de ese usuario y lanzar la herramienta de llavero, mostré mi llavero creado y después de eso todo funcionó como se describe en las publicaciones superiores.

Me pregunto si algo del comportamiento inicial de los llaveros cambió en Lion, o me falta algo?

Si tiene sudo, puede usar passwd para cambiar la contraseña del usuario de Jenkins. Entonces puedes obtener la contraseña de Jenkins.

Además, no estoy seguro de si este es el problema para ti, pero el script ANT que uso a través de Jenkins tiene esto:

<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>

Supongamos que también desea hacer una distribución ad hoc a través de Jenkins, esto requiere que Jenkins tenga acceso a un certificado de Distribución y a la identidad del administrador del equipo, además de los perfiles de aprovisionamiento.

Al usar una identidad exportada en un archivo .cer, puede importarla de forma programática como tal, el modificador -A permite a todos los programas acceder a esta entrada. Alternativamente, puede usar varios interruptores -T /path/to/program para permitir el acceso xcodebuild y xcodebuild :

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

Por supuesto, también deberíamos tener el certificado WWDCRA de Apple, importado de la misma manera:

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

Sin embargo, también necesitamos la clave privada para el devcertificate.cer . Para hacer esto, necesita exportar la clave privada correspondiente como una clave .p12 y establecer una contraseña. Colóquelo en un lugar donde pueda acceder desde su caparazón de Jenkins, desbloquee el llavero e impórtelo:

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

La importación del certificado de distribución funciona de la misma manera. No sé por qué necesitas desbloquear el llavero para importar un .p12 y no un .cer, pero bueno.

También necesitarás acceso a los perfiles de provisión. En breve, editaré esas instrucciones en esta publicación.

También podría instalar e iniciar JenkinsCI como usuario de OS X en lugar de un daemon:

  1. instala jenkins usando el instalador oficial ( https://jenkins-ci.org/ )
    • Haga clic en Siguiente
    • Haga clic en "Personalizar"
    • Deseleccione "Comenzar en el arranque como ''jenkins''" - * IMPORTANTE * esta opción normalmente permite un jenkins sin cabeza que no funciona bien con el acceso al llavero
  2. Lanzamiento http://127.0.0.1:8080
    • verificar que NO se lanza
    • puede necesitar detener jenkins sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
  3. Haga doble clic en /Applications/Jenkins/jenkins.war
    • por supuesto, esto debe ser automatizado para comenzar @ start up
  4. Abra http://127.0.0.1:8080
    • verificar que se está ejecutando