Rularea xcodebuild de la un terminal bifurcat

voturi
58

Am încercat să setup un server automat de a construi pentru o aplicație pentru iPhone. Aș vrea să fie în măsură să aibă fiecare noapte adhoc beta construiește astfel încât testeri pot urmări dezvoltarea.

Am setted până Xcode cu succes Xcode pentru a efectua adhoc construiește și eu pot lansa, de asemenea, de a construi din linia de comandă:

xcodebuild configurație- AdHoc -sdk iphoneos2.2 construi curat

Problema Întâmpin este că următoarea linie nu funcționează de la un terminal bifurcat (folosind nohup sau ecran) și a eșuat cu următorul text

CodeSign eroare: Semnarea codului de identitate „iPhone de distribuție: XXXXX“ nu se potrivește cu orice certificat de cod de înscriere în Keychain. Odată adăugat la keychain, atingeți un fișier sau curățați proiectul pentru a continua.

Am verificat variabilele mele de mediu în cochilie și în nohup sau ecran și nu a găsit un indiciu. Cred că problema mea este că terminalul bifurcată nu poate avea acces la keychain, dar nu am nici o idee despre cum să-l permite.

Multumesc pentru ajutor

Întrebat 23/02/2009 la 13:11
sursa de către utilizator
În alte limbi...                            


13 răspunsuri

voturi
2

M-am uitat la comanda de securitate o se pare că Keychains atribuite la terminalul meu nu sunt la fel, atunci când bifurcată. Dacă am lansat comanda de securitate din terminalul am:

$ security list-keychains
  "/Users/yannooo/Library/Keychains/login.keychain"
  "/Library/Keychains/System.keychain"

întrucât , atunci când se utilizează ecranul am ieșire următoarele:

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

Deoarece certificatele mele construi sunt stocate în Keychain de conectare, codul de eroare semn am pare normal.

Stie cineva cum as putea atribui un breloc la un terminal? Am încercat acest lucru fără succes

security login-keychain -s /Users/yannooo/Library/Keychains/login.keychain

Vreo idee?

Publicat 23/02/2009 la 19:18
sursa de către utilizator

voturi
9

Ați putea să utilizați în security list-keychains -s ${HOME}/Library/Keychains/login.keychaininteriorul procesului de construcție pentru a adăuga în mod explicit Keychain de conectare la lista de căutare? Se pare ca de Terminalul bifurcată, procesul de construire nu vede Keychain dvs. de utilizator. Asta ar putea avea sens în cazul în care lista de căutare Keychain se bazează pe sesiunea de securitate curentă - o sesiune de terminal de bifurcat va părăsi sesiunea de conectare la fel ca și cum ai sshpeste conexiunea loopback.

Publicat 23/02/2009 la 21:28
sursa de către utilizator

voturi
4

Ca un alt poster spune,

security list-keychains -s  "~/Library/Keychains/login.keychain"

Dar cred că aveți acces la login.keychain numai atunci când sunteți conectat, în contextul GUI (am testat pe un sistem prin SSH și ecran, dar pe care am, de asemenea, se întâmplă să fie conectat prin intermediul VNC).

Aparent este posibil să se utilizeze launchctl pentru a selecta contextul GUI și rulați programul, dar cred că funcționează doar pentru „utilizatorul conectat“ prea.

Dacă încercați „ security show-keychain-info keychain-file“ , atunci veți obține următoarea eroare:

Interacțiunea cu utilizatorul nu este permisă

Și asta este o expresie pentru a căuta cu unele pentru mai multe informații. O altă soluție este de a pune certificatul în Keychain de sistem!

Publicat 23/02/2009 la 22:35
sursa de către utilizator

voturi
90

Am avut te eroare interacțiunea utilizatorului nu este permisă și rezolvată prin deblocarea Keychain prima

security unlock-keychain /Users/yannooo/Library/Keychains/login.keychain

De asemenea , am încercat să - mi în certs Keychain sistemului și a fost de lucru. Soluția mea finală a fost de a pune toate certs mele legate de iPhone - ul într - un breloc dedicat numit iPhone.keychain folosind Keychain Access aplicația

security list-keychains -s /Users/yannooo/Library/Keychains/iPhone.keychain 
security unlock-keychain -p keychainpassword /Users/yannooo/Library/Keychains/iPhone.keychain 
Publicat 24/02/2009 la 07:59
sursa de către utilizator

voturi
1

Dacă sunteți de executare xcodebuild ca root (care sunteți atunci când sudo), trebuie să vă conectați ca root și pune certificatele de semnare de la Keychain root. Apoi debloca keychain cu securitate ca mai sus.

Publicat 25/02/2009 la 05:57
sursa de către utilizator

voturi
6

Ok, problema a fost două lucruri pentru mine, prima a fost deblocarea Keychain;

security unlock-keychain login.keychain

În al doilea rând a fost (gol) frază de acces,

security import blahblahbackup.p12 -k login.keychain -T /usr/bin/codesign -P ""

UPDATE: A avut o mică problemă mai târziu, atunci când script-ul este declanșat de un script web sau sth. ca asta. Doar vede /Library/Keychains/System.chain. Deci, am găsit o soluție murdar (ceea ce poate duce la probleme de securitate, dar ok pentru mine);

  • Configurarea de conectare pubkey ssh ( de la utilizator care vrea să construiască apela script - ul, pentru a utilizatorului real , care are certificate și va rula xcodebuild) , în cazul meu, este același utilizator. Apache este de lucru ca someuserși totul pentru a construi este de configurare de pe someuser.
  • și script-ul meu php (pentru declanșare construi) a fost de asteptare ~ / build-script. M-am schimbat ca asa:

    ssh someuser @ localhost ~ / build-script

așa că funcționează într-un tty reală, și toate Keychain este accesibil, totul funcționează bine.

Publicat 27/10/2011 la 12:25
sursa de către utilizator

voturi
6

actualizarea pentru oameni care rulează în probleme similare cu Jenkins:

Dacă ați configurat Mac-ul pentru a lansa prin intermediul LaunchDaemons Jenkins, trebuie să vă asigurați-vă că pentru a adăuga

<key>SessionCreate</key>
<true />

Deci întreaga ci.plist ar arata astfel:

<?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>Label</key>
 <string>Jenkins</string>
 <key>UserName</key>
 <string>user</string>
 <key>GroupName</key>
 <string>staff</string>
 <key>ProgramArguments</key>
 <array>
 <string>/usr/bin/java</string>
 <string>-Xmx512m</string>
 <string>-jar</string>
 <string>/path/to/jenkins/jenkins.war</string>
 </array>
 <key>RunAtLoad</key>
 <true/>
 <key>KeepAlive</key>
 <true/>
 <key>EnvironmentVariables</key>
   <dict>
     <key>JENKINS_HOME</key>
     <string>/path/to/jenkins/home</string>
   </dict>
 <key>SessionCreate</key>
 <true />
</dict>
</plist>

Am fost blocat spirit aceeași problemă cât mai mulți oameni au de mai sus. Mai precis am experimentat problema atunci când rulează de la un script de shell Jenkins am primit aceeași ** interacțiune Utilizatorul nu este permisă ** eroarea. Când se execută dintr-o coajă ssh, scenariul meu a lucrat bine.

Diferența pe care cei mai mulți oameni au văzut , de asemenea , este că , dacă aveți o securitate lista-Keychain ați obține:

$ security list-keychain
  "/Library/Keychains/System.keychain"
  "/Library/Keychains/System.keychain"

Dar, atunci când rulează în coajă ssh, aș primi:

$ security list-keychain
    "/Users/<i>user_account_name</i>/Library/Keychains/login.keychain"
    "/Library/Keychains/System.keychain"

Și cei mai mulți oameni vor avea toate cheile / certs etc. în contul de utilizator keychain. La fel ca unii oameni au sugerat că este ușor de a face un nou lanț cheie, care este diferit de lanțul de cheie de utilizator, și reseve-l pentru lucrurile semnarea XCode. Am ajuns punerea mea aici: /Library/Keychains/sysiphone.keychain

Cred că problema este că pentru configurarea mea (și, eventual, pentru a ta), executați într-un domeniu de preferință de securitate diferit (sistem vs. utilizator). În cele din urmă - iată cum am ajuns sysiphone.keychain meu să apară:

$ sudo security list-keychains -d system -s "/Library/Keychains/sysiphone.keychain"
Password: *****
$ security list-keychains -d system
    "/Library/Keychains/sysiphone.keychain"

... și magic lucrurile au început să construiască în Jenkins. Wow ... asta a fost de circa 4 ore în jos de scurgere pentru mine. Suspin.

Publicat 06/04/2012 la 06:46
sursa de către utilizator

voturi
0

Am facut:

  • șterge login.keychaindin listă

  • crea propria keychain în $HOME/Library/Keychains/

  • adăugați-l Keychain lista (nu a specificat nici un anumit domeniu)

  • setați ca implicit

  • suna security unlock-keychainpe ea

  • adaugă certificat de semnare la nivel mondial (WWDRCA) să-l

  • import cheie privată și ambele dezvoltare și distribuție a certificatelor pentru ea

Dacă există login.keychain, eu încă obține „interacțiune utilizatorului nu este permis“ eroare. Astfel , ștergerea login.keychainfolosind în security delete-keychaincele din urmă a ajutat!

Publicat 16/04/2012 la 07:32
sursa de către utilizator

voturi
2

Sunt folosind Atlassian Bamboo 2.7 și OS X 10.7.3 Lion și am încercat, în fiecare abordare găsit în firul dar am fost încă obtinerea „interacțiunea utilizatorului nu este permis“ eroare.

Problema a fost că, într - o sesiune de terminal de la distanță (ca „superutilizator“ , cum ar fi în cazul bambus sau alt sistem construi automatizat), keychain care trebuie să fie deblocat care conține certificatele de semnare sunt diferite de ceea ce ar vedea normal ( de exemplu așa cum a fost demonstrat de Yann în aici ) , atunci când nu sunteți superutilizator.

Ceea ce în cele din urmă a lucrat pentru mine a fost să fac următoarele:

  1. ca administrator de sistem cum este descris aici
  2. a crea Keychain numai semnarea ( de exemplu ios.keychain)
  3. se adaugă certificatele de semnare să-l (împreună cu certificatul WWDRCA)

Verificați - l mergând suși rulează security list-keychainspe terminal. Ar trebui să vedeți ios.keychain printre listă. ( sudo security list-keychainsNu se va arăta același lucru):

sh-3.2# security list-keychains
"/private/var/root/Library/Keychains/login.keychain"
"/Library/Keychains/ios.keychain"
"/Library/Keychains/System.keychain"

Am descoperit că încă mai trebuie să adăugați ios.keychain la domeniul de aplicare dvs. de căutare înainte de a face unlock-keychaincomanda. În script - ul construi, au următoarele linii rula:

KEYCHAIN=/Library/Keychains/ios.keychain
# the -s option adds $KEYCHAIN to the search scope, while the -d option adds $KEYCHAIN to the system domain; both are needed
security -v list-keychains -d system -s $KEYCHAIN 
security -v unlock-keychain -p bambooiphone $KEYCHAIN
Publicat 19/04/2012 la 08:28
sursa de către utilizator

voturi
11

O altă soluție:

  • Deschideți Keychain Access
  • click dreapta pe cheia privată
  • Selectați "Get Info"
  • Selectați tab-ul "Access Control"
  • Faceți clic pe „Permiteți tuturor aplicațiilor să acceseze acest element“
  • Faceți clic pe „Salvați modificările“
  • Introduceți parola
  • se bucura
Publicat 02/09/2012 la 10:08
sursa de către utilizator

voturi
28

Există două (eventual trei componente!) La acest lucru. Una dintre ele este Keychain trebuie să fie deblocat. În al doilea rând, există o listă de control al accesului în interiorul keychain care spune permisiunile sunt date pentru aplicații în stat deblocat. Deci , chiar dacă aveți keychain cu succes deblocat, în cazul în care capacitatea de a accesa cheia privată și să semneze cu ea nu este dat , /usr/bin/codesignatunci veți primi în continuare acest mesaj. În cele din urmă, dacă sunteți pe Mac OS Sierra, ID - ul de partiție implicit alocat chei este incorect pentru a fi compatibil cu codesignbinar.

Soluția este după cum urmează:

1) Dacă aveți acces la Keychain Access GUI, atunci puteți acorda manual fiecare program sau / usr / bin / acces codesign făcând clic dreapta pe cheia privată, selectând fila „Access Control“ și apoi selectând „Permiteți toate aplicațiile pentru a accesa acest articol“radio sau lista«permite întotdeauna accesul prin aceste aplicații lista».

2) Dacă se confruntă cu această eroare, șansele sunt încercați să executați codesignpentru un utilizator non-conectare. În acest caz, în mod clar nu au acces la „Keychain Access“ GUI. Pentru aceste cazuri, verificați signautorizația lipsă de aplicare <null>, ceea ce înseamnă că se pare că toate aplicațiile, sau în mod specific /usr/bin/codesignprin utilizarea:

security dump-keychain -i login.keychain

Cu toate acestea, nu puteți adăuga sau modifica atributele de control al accesului în modul interactiv pentru un motiv sau altul șterge --only! De fapt , trebuie să ștergeți manual cheia și re-adăuga la keychain specificând -Tpavilion.

security import login.keychain -P "<password>" -T /usr/bin/codesign

În cazul în care -Tspecifică

-T  Specify an application which may access the imported key (multiple -T options are allowed)

3) Dacă sunteți pe Mac OS Sierra, modificați ID - ul de partiție pentru a include applepartiția. Probabil, acesta este spațiul de nume atribuit , codesigndeoarece acesta a fost distribuit de Apple.

security set-key-partition-list -S apple-tool:,apple: -k "<password>" login.keychain

NOTĂ : a apple-toolpartiției este introdus de securityinstrument, astfel încât comanda de mai sus păstrează acea partiție. Pentru mai multe informații cu privire la acest aspect, a se vedea: http://www.openradar.me/28524119

Publicat 07/02/2013 la 19:11
sursa de către utilizator

voturi
2

Deblocarea keychain de conectare nu a funcționat pentru mine. Crearea unui breloc separat folosind Keychain Access (numit iOS) și apoi adăugarea de aceste comenzi pentru a construi făcut de lucru (atunci când rulează Jenkins ca propriul meu de utilizare):

Lista-Keychains de securitate -v sistem -d -s ~ / Library / Keychains / iOS.keychain; securitate -v debloca-Keychain parola -p ~ / Library / Keychains / iOS.keychain;

Acest lucru pare mai promițător, deși: https://wiki.jenkins-ci.org/display/JENKINS/Xcode+Plugin#XcodePlugin-Userinteractionisnotallowed

Publicat 30/05/2013 la 21:36
sursa de către utilizator

voturi
2

Dacă desfășurați security list-keychainsși vedeți dvs. Keychain personalizate apar undeva în listă , dar încă nu funcționează, ar putea fi că difuzați în problema am avut prin care Keychains sunt verificate în ordine din lista de căutare, și din moment ce nu am fost descuierea login.keychainîn sesiunea mea SSH, ar eșua acolo , mai degrabă decât a trece la următoarea keychain din listă, care a fost unul personalizat am vrut să debloca.

Stabilirea listei de căutare la un breloc personalizat pe care le debloca cu security unlock-keychainlucrări. Folosind această metodă de răspunsul lui Yann va elimina , de asemenea , login.keychain din lista de căutare.

Pentru a păstra login.keychain:

security list-keychains -s ~/Library/Keychains/custom.keychain ~/Library/Keychains/login.keychain

În acest fel, atunci când se utilizează sesiunea GUI de la aparatul va avea în continuare acces la login.keychainelemente, dar semnarea cod va verifica keychain personalizat în primul rând, care reușește , dacă l - ați deblocat.

Publicat 15/10/2013 la 22:39
sursa de către utilizator

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more