Jenkins unter OS X: xcodebuild gibt einen Code Sign-Fehler aus

107

Zusammenfassung:

Das Einrichten von Jenkins unter OS X wurde mit dem neuesten Installationsprogramm ( Stand: 1.449 - 9. März 2012 ) erheblich vereinfacht. Die Verwaltung des Codesignaturprozesses ist jedoch ohne einfache Antwort immer noch sehr schwierig.

Motivation:

Führen Sie einen kopflosen CI-Server aus, der den gängigen Best Practices für die Ausführung von Diensten unter OS X folgt ( von denen einige hier im Klartext erläutert werden ).

Hintergrund:

Prozess:

Installieren Sie Jenkins CI über das OS X- Installationspaket . Klicken Sie für den Schritt "Installationstyp" auf die Schaltfläche "Anpassen" und wählen Sie "Beim Booten als" Jenkins "beginnen."

Diskussion:

Die naive Erwartung an diesem Punkt war, dass ein Projekt im freien Stil mit dem Build-Skript xcodebuild -target MyTarget -sdk iphoneosfunktionieren sollte. Wie aus dem Titel dieses Beitrags hervorgeht, funktioniert und schlägt dies nicht mit:

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

Es ist offensichtlich genug, was passieren muss - Sie müssen dem Standardschlüsselbund ein gültiges Codesignaturzertifikat und einen privaten Schlüssel hinzufügen. Bei der Untersuchung, wie dies erreicht werden kann, habe ich keine Lösung gefunden, die das System nicht für ein gewisses Maß an Sicherheitslücke öffnet.

Problem 1: Kein Standardschlüsselbund für Jenkins Daemon

sudo -u jenkins security default-keychain ... ergibt "Ein Standardschlüsselbund konnte nicht gefunden werden"

Wie unten von Ivo Dancet ausgeführt , ist die UserShell für den Jenkins-Daemon standardmäßig auf / usr / bin / false eingestellt (ich denke, dies ist eine Funktion, kein Fehler). Folgen Sie seiner Antwort, um die UserShell in Bash zu ändern. Sie können sich dann sudo su jenkinsals Jenkins-Benutzer anmelden und eine Bash-Eingabeaufforderung erhalten.

  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

OK großartig. Wir haben jetzt einen Standardschlüsselbund. Lass uns weitermachen, oder? Aber warum haben wir uns überhaupt die Mühe gemacht, einen Standardschlüsselbund zu erstellen?

Fast alle Antworten, Vorschläge oder Konversationen, die ich während der Recherche gelesen habe, deuten darauf hin, dass man nur die Codesignaturzertifikate und -schlüssel in den Systemschlüsselbund stecken sollte. Wenn Sie security list-keychainsin Jenkins als Projekt im freien Stil ausgeführt werden, sehen Sie, dass der einzige verfügbare Schlüsselbund der Systemschlüsselbund ist. Ich denke, dort kamen die meisten Leute auf die Idee, ihr Zertifikat und ihren Schlüssel dort abzulegen. Dies scheint jedoch nur eine sehr schlechte Idee zu sein - insbesondere, da Sie zum Öffnen des Schlüsselbunds ein Nur- Text-Skript mit dem Kennwort erstellen müssen .

Problem 2: Hinzufügen von Codesignaturzertifikaten und privatem Schlüssel

Hier fange ich wirklich an, zimperlich zu werden. Ich habe das Gefühl, dass ich einen neuen öffentlichen / privaten Schlüssel erstellen sollte, der für die Verwendung mit Jenkins einzigartig ist. Mein Denkprozess ist, wenn der Jenkins-Daemon kompromittiert ist, kann ich das Zertifikat im Apple Provisioning Portal problemlos widerrufen und einen weiteren öffentlichen / privaten Schlüssel generieren. Wenn ich denselben Schlüssel und dasselbe Zertifikat für mein Benutzerkonto und Jenkins verwende, bedeutet dies mehr Aufwand (Schaden?), Wenn der Jenkins-Dienst angegriffen wird.

Wenn Sie auf die Antwort von Simon Urbanek zeigen , entsperren Sie den Schlüsselbund aus einem Skript mit einem Nur-Text-Passwort. Es scheint unverantwortlich, alles andere als "Einweg" -Zertifikate und -Schlüssel im Schlüsselbund des Jenkins-Dämons zu behalten.

Ich bin sehr an gegenteiligen Diskussionen interessiert. Bin ich übermäßig vorsichtig?

Um einen neuen CSR als Jenkins-Daemon im Terminal zu erstellen, habe ich Folgendes getan ...

  1. sudo su jenkins
  2. certtool r CertificateSigningRequest.certSigningRequest Sie werden zu Folgendem aufgefordert (die meisten davon habe ich bei der richtigen Antwort gut erraten; haben Sie bessere Einsichten? Bitte teilen Sie.) ...
    • Schlüssel und Zertifikatetikett eingeben:
    • Algorithmus auswählen: r(für RSA)
    • Geben Sie die Schlüsselgröße in Bit ein: 2048
    • Signaturalgorithmus auswählen: 5(für MD5)
    • Geben Sie die Herausforderungszeichenfolge ein:
    • Dann ein paar Fragen an RDN
  3. Senden Sie die generierte CSR-Datei (CertificateSigningRequest.certSigningRequest) unter einer neuen Apple ID an das Apple Provisioning Portal
  4. Genehmigen Sie die Anforderung und laden Sie die CER-Datei herunter
  5. security unlock-keychain
  6. security add-certificate ios_development.cer

Dies bringt uns einen Schritt näher ...

Problem 3: Bereitstellungsprofil und Entsperren des Schlüsselbunds

Ich habe im Provisioning Portal ein spezielles Provisioning-Profil erstellt, das nur für die Verwendung mit CI bestimmt ist, in der Hoffnung, dass ich die Auswirkungen etwas verringert habe, wenn etwas Schlimmes passiert. Best Practice oder übermäßig vorsichtig?

  1. sudo su jenkins
  2. mkdir ~/Library/MobileDevice
  3. mkdir ~/Library/MobileDevice/Provisioning\ Profiles
  4. Verschieben Sie das im Bereitstellungsportal eingerichtete Bereitstellungsprofil in diesen neuen Ordner. Wir sind jetzt zwei kurze Schritte davon entfernt, xcodebuild über die Befehlszeile als Jenkins auszuführen, und das bedeutet, dass wir auch kurz davor sind, die Jenkins CI-Builds zum Laufen zu bringen.
  5. security unlock-keychain -p <keychain password>
  6. xcodebuild -target MyTarget -sdk iphoneos

Jetzt erhalten wir eine erfolgreiche Erstellung über eine Befehlszeile, wenn wir als Jenkins-Daemon angemeldet sind. Wenn wir also ein Projekt im freien Stil erstellen und die letzten beiden Schritte (Nr. 5 und Nr. 6 oben) hinzufügen, können wir die Erstellung von automatisieren unser iOS Projekt!

Es ist vielleicht nicht notwendig, aber ich fühlte mich besser, jenkins UserShell wieder auf / usr / bin / false zu setzen, nachdem ich all dieses Setup erfolgreich erhalten hatte. Bin ich paranoid?

Problem 4: Standardschlüsselbund immer noch nicht verfügbar!

( BEARBEITEN: Ich habe die Änderungen an meiner Frage veröffentlicht, neu gestartet, um sicherzustellen, dass meine Lösung 100% ist, und natürlich habe ich einen Schritt ausgelassen. )

Selbst nach allen oben genannten Schritten müssen Sie die Launch Daemon-Liste unter /Library/LaunchDaemons/org.jenkins-ci.plist wie in dieser Antwort angegeben ändern . Bitte beachten Sie, dass dies auch ein openrdar-Fehler ist .

Es sollte so aussehen:

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

Mit diesem Setup würde ich auch das Xcode-Plugin für Jenkins empfehlen , was das Einrichten des xcodebuild-Skripts ein wenig erleichtert. An dieser Stelle würde ich auch empfehlen, die Manpages für xcodebuild zu lesen - verdammt, Sie haben es so weit im Terminal geschafft, oder?

Dieses Setup ist nicht perfekt und jeder Rat oder jede Einsicht wird sehr geschätzt.

Es fiel mir schwer, eine "richtige" Antwort auszuwählen, da ich zur Lösung meines Problems eine Sammlung von nahezu allen Eingaben verwendet habe. Ich habe versucht, allen mindestens eine Gegenstimme zu geben, aber Simon die Antwort zugesprochen, weil er meistens die ursprüngliche Frage beantwortet hat. Darüber hinaus verdient Sami Tikka viel Anerkennung für seine Bemühungen, Jenkins dazu zu bringen, AppleScript als einfache alte OS X-App zu verwenden. Wenn Sie nur daran interessiert sind, Jenkins in Ihrer Benutzersitzung schnell zum Laufen zu bringen (dh nicht als kopfloser Server), ist seine Lösung viel Mac-ähnlicher.

Ich hoffe, dass meine Bemühungen weitere Diskussionen anregen und der nächsten armen Seele helfen, zu glauben, dass sie Jenkins CI-Setup für ihre iOS-Projekte an einem Wochenende erhalten können, aufgrund all der wunderbaren Dinge, die sie darüber gehört haben.


Update: 9. August 2013

Bei so vielen positiven Stimmen und Favoriten dachte ich, ich würde 18 Monate später mit einigen kurzen Lektionen darauf zurückkommen.

Lektion 1: Setzen Sie Jenkins nicht dem öffentlichen Internet aus

Auf der WWDC 2012 habe ich diese Frage an die Ingenieure von Xcode und OS X Server weitergeleitet. Ich erhielt die Kakophonie "Tu das nicht!" von jemandem, den ich gefragt habe. Alle waren sich einig, dass ein automatisierter Erstellungsprozess großartig war, dass der Server jedoch nur über das lokale Netzwerk zugänglich sein sollte. Die Ingenieure von OS X Server schlugen vor, den Remotezugriff über VPN zuzulassen.

Lektion 2: Es gibt jetzt neue Installationsoptionen

Ich habe kürzlich einen CocoaHeads-Vortrag über meine Jenkins-Erfahrung gehalten und zu meiner großen Überraschung einige neue Installationsmethoden gefunden - Homebrew und sogar eine Bitnami Mac App Store- Version. Diese sind definitiv einen Besuch wert. Jonathan Wright hat einen Überblick darüber, wie Homebrew Jenkins funktioniert .

Lektion 3: Nein, im Ernst, setzen Sie Ihre Build-Box nicht dem Internet aus

Aus dem ursprünglichen Beitrag geht ziemlich klar hervor, dass ich weder Systemadministrator noch Sicherheitsexperte bin. Der gesunde Menschenverstand in Bezug auf private Dinge (Schlüsselanhänger, Anmeldeinformationen, Zertifikate usw.) ließ mich ziemlich unruhig werden, wenn ich meine Jenkins-Box ins Internet stellte. Nick Arnott von Neglected Potential konnte meine Heebie-Jeebies in diesem Artikel ziemlich leicht bestätigen .

TL; DR

Meine Empfehlung an andere, die ihren Erstellungsprozess automatisieren möchten, hat sich in den letzten anderthalb Jahren geändert. Stellen Sie sicher, dass sich Ihr Jenkins-Computer hinter Ihrer Firewall befindet. Installieren und einrichten Sie Jenkins als dedizierten Jenkins-Benutzer, entweder mithilfe des Installationsprogramms, der Bitnami Mac App Store-Version, des AppleScript von Sami Tikka usw.; Dies löst die meisten der oben beschriebenen Kopfschmerzen. Wenn Sie Remotezugriff benötigen, dauert das Einrichten von VPN-Diensten in OS X Server höchstens zehn Minuten. Ich benutze dieses Setup seit über einem Jahr und bin sehr zufrieden damit. Viel Glück!

edelaney05
quelle
10
Ich bin traurig, dass ich nur eine Gegenstimme zu dieser prägnanten und vollständigen Frage mit Antworten geben kann :)
Zsub
Etwas hat den Start von Jenkins unter OS X Yosemite unterbrochen - das Installationsprogramm von Jenkins verwendet.
Jonny
Verschieben Sie Ihr Zertifikat in den Systemschlüsselbund und seien Sie glücklich;)
Julian F. Weinert

Antworten:

30

Schlüsselanhänger müssen entsperrt werden, bevor sie verwendet werden können. Sie können security unlock-keychainzum Entsperren verwenden. Sie können dies interaktiv (sicherer) oder durch Angabe des Kennworts in der Befehlszeile (unsicher) tun, z.

security unlock-keychain -p mySecretPassword...

Das Einfügen in ein Skript gefährdet natürlich die Sicherheit dieses Schlüsselbunds. Daher wird häufig ein einzelner Schlüsselbund mit nur den Signaturanmeldeinformationen eingerichtet, um diesen Schaden zu minimieren.

In Terminalder Regel ist der Schlüsselbund bereits von Ihrer Sitzung entsperrt, da der Standardschlüsselbund beim Anmelden entsperrt ist, sodass Sie dies nicht tun müssen. Ein Prozess, der nicht in Ihrer Sitzung ausgeführt wird, hat jedoch keinen Schlüsselbund freigeschaltet, selbst wenn Sie der Benutzer sind (am häufigsten betrifft dies ssh, aber auch jeden anderen Prozess).

Simon Urbanek
quelle
Ich habe aber auch Schwierigkeiten, einen Schlüsselbund über den Systemschlüsselbund hinaus zu laden. security unlock-keychain -p password -k /path/codesign.keychainfunktioniert nicht
edelaney05
Haben Sie den Standardschlüsselbund wie in meinem obigen Beispiel verwendet? Beachten Sie, dass Sie benutzerdefinierte Schlüsselanhänger so einrichten müssen, dass sie sich zuerst im Suchpfad befinden. Versuchen Sie also zuerst den Standardschlüsselbund. Beachten Sie auch, dass es kein -kArgument dafür gibt, unlock-keychainsodass alles, was Sie versuchen, nicht richtig erscheint (siehe security help unlock-keychain).
Simon Urbanek
Ich habe etwas anderes ausprobiert, bin aber letztendlich wieder an derselben Stelle gelandet. Ich habe meine Frage bearbeitet, hoffentlich ist es etwas klarer?
edelaney05
Es ist völlig anders als die ursprüngliche Frage ... Zunächst sollten Sie sich als Jenkins anmelden (z. B. über sudo -u jenkins bash) und überprüfen, ob Sie die Berechtigungen für den gesamten Pfad richtig haben. Sie haben viele Dinge getan, die Sie nicht gesagt haben (z. B. dsclzum Erstellen des Benutzers), sodass Sie wirklich alleine sind. Sie sollten auch die Home-Einstellung überprüfen (je nachdem, ob Sie die Shell festlegen oder nicht, können sudo -u jenkins -iSie entsprechende Anmeldeeinstellungen abrufen).
Simon Urbanek
12

Angenommen, Sie möchten auch eine Ad-hoc-Verteilung über Jenkins durchführen. Dies erfordert, dass Jenkins zusätzlich zu den Bereitstellungsprofilen Zugriff auf ein Verteilungszertifikat und die Identität des Teamadministrators hat.

Wenn Sie eine exportierte Identität in einer CER-Datei verwenden, können Sie sie programmgesteuert so importieren. Mit der Option -A können alle Programme auf diesen Eintrag zugreifen. Alternativ können Sie mehrere -T /path/to/programSchalter verwenden, um Folgendes zuzulassen codesignund darauf xcodebuildzuzugreifen :.

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

Natürlich sollten wir auch das Apple WWDCRA-Zertifikat haben, das auf die gleiche Weise importiert wird:

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

Wir benötigen jedoch auch den privaten Schlüssel für die devcertificate.cer. Dazu müssen Sie den entsprechenden privaten Schlüssel als P12-Schlüssel exportieren und ein Kennwort festlegen. Platzieren Sie es an einem Ort, an dem Sie über Ihre Jenkins-Shell darauf zugreifen können, entsperren Sie den Schlüsselbund und importieren Sie es:

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

Das Importieren des Verteilungszertifikats funktioniert genauso. Ich weiß nicht, warum Sie den Schlüsselbund für den Import einer .p12 und nicht für eine .cer entsperren müssen, aber gut.

Sie benötigen auch Zugriff auf die Bereitstellungsprofile. Ich werde diese Anweisungen in Kürze in diesem Beitrag bearbeiten.

Zsub
quelle
1
Könnten Sie bitte mit den Anweisungen zum Zugriff auf das Bereitstellungsprofil aktualisieren?
Luke
Einen entsprechenden Ansatz finden Sie unter moduleset.com/what-we-know/2013/03/11/jenkins_keychain_timeouts .
Gili
5

Ich hatte das gleiche Problem und habe einige Zeit nach einer Antwort gesucht. Hier ist eine Sache, die ich gelernt habe.

Ich verwende Jenkins als den Benutzer von Jenkins, der vom Installationsprogramm erstellt wurde, und wie alle anderen erwähnt haben, hat er keinen Zugriff auf denselben Schlüsselbund wie Ihr normaler Benutzer. Anstatt zu versuchen, sich als Jenkins-Benutzer anzumelden, habe ich ein zweites Build-Projekt erstellt, das einfach einen Build-Schritt enthält: "Shell ausführen", in dem ich Befehle ausführe, die ich als Jenkins-Benutzer testen möchte.

Sobald ich das eingerichtet hatte, konnte ich den Befehl ausführen

security list-keychains

Und dies zeigte mir, dass das einzige, was Jenkins sehen konnte, der Systemschlüsselbund war.

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

Mit diesem Wissen öffnete ich dann die Keychain Access-App und kopierte mein "iPhone Developer: xxxx" -Zertifikat in den System-Schlüsselbund (Rechtsklick, Kopieren aus dem "Login" -Schlüsselbund).

Dadurch habe ich den Codezeichenfehler für das Zertifikat / private Schlüsselpaar bestanden, aber einen anderen mit dem Bereitstellungsprofil geöffnet (scheint ein ähnliches, aber anderes Problem zu sein).

Brianianey
quelle
Ich habe das gleiche Problem mit dem Bereitstellungsprofil. Überlegen Sie, wie Sie dieses Problem lösen können?
Santthosh
2
Ich habe festgestellt, dass die Bereitstellungsprofile für den Jenkins-Benutzer unter "/ Users / Shared / Jenkins / Library / MobileDevice / Provisioning Profiles" gespeichert sind, und habe daher einen Schritt in meinen Build eingefügt, um ein Bereitstellungsprofil aus meinem Git-Repo an diesen Speicherort zu kopieren. Auf diese Weise kann ich das Bereitstellungsprofil aktualisieren und in SCM übertragen, und Jenkins übernimmt diese Änderung automatisch.
Brianestey
Wenn Sie die login.keychain in Ihre Jenkins-Schlüsselbundbibliothek kopieren, müssen Sie sie chown, damit der Jenkins-Benutzer sie sicherheitshalber entsperren kann
Ganoro
1
Du bist der Held, ich habe mir 2 Tage lang die Haare auf dem Kopf gerissen und das Kopieren von Zertifikaten in das System geholfen
Roman Bobelyuk
5

Um das Passwort zu ändern, können Sie verwenden sudo passwd jenkins <new-pw>. Ich denke jedoch, es wäre besser, den Befehl dscl zu verwenden, um das Passwort zu ändern.

In meiner Installation hatte Jenkins (offizielles Installationsprogramm) eine Benutzer-Shell / usr / bin / false. Das Ändern in "Bash" löste das Problem, dass Sie sich nicht anmelden konnten:

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

Sie sollten sich jetzt anmelden können su jenkins.

Ivo Dancet
quelle
Dies war sehr hilfreich für mich - ich hatte ein ähnliches Problem mit dem create-keychainBefehl, der nicht mit dem Jenkins-Benutzer funktioniert. Das Ausführen dieses Befehls schien das Problem zu beheben.
lxt
Wenn ich den Befehl zum Ändern des Kennworts des Jenkins-Benutzers ausführe, werde ich nach dem aktuellen Kennwort gefragt. Ich habe keine Ahnung, was das ist und kann die Eingabetaste nicht drücken. Irgendwelche Vorschläge?
CMVR
4

Ich habe das Xcode-Plugin verwendet, um eine iOS-App zu erstellen. In der Konfiguration eines Projekts.

Wählen Sie Build-Schritt hinzufügen> Xcode> Codesignatur und OS X-Schlüsselbundoptionen.

Aktivieren Sie das Kontrollkästchen Schlüsselbund entsperren und fügen Sie es wie folgt hinzu (Beispiele) Geben Sie hier die Bildbeschreibung ein

Manchmal, wenn ich den Fehler bekomme

Code Sign Fehler: ...

Ich werde Jenkins erneut öffnen und das Passwort erneut eingeben, um es zu entsperren

Biolinh
quelle
3

Für Menschen Probleme mit Schlüsselanhänger mit, würde ich empfehlen Sie meine alternative Jenkins Installer auf jeden Fall versuchen https://github.com/stisti/jenkins-app , Downloads bei https://github.com/stisti/jenkins-app/downloads

Jenkins.app führt Jenkins in Ihrer Benutzersitzung aus, sodass Probleme mit dem Schlüsselbundzugriff kein Problem darstellen :)

sti
quelle
Die Sorge ist, dass sich dieser Jenkins-Benutzer im Benutzerbereich und nicht im Dämonbereich befindet. Wenn also ein Angreifer Ihren Jenkins-Benutzer gefährden könnte, hätte er vollen Zugriff auf Ihren Computer.
edelaney05
Dies könnte die Probleme lösen, die ich bekommen habe. Das Problem ist, dass ich eine vorhandene Jenkins-Installation habe (anders herum) und nicht alle meine Builds verlieren möchte - usw. Was wird in meinem Fall passieren?
Mike S
2

Wenn Sie sudo haben, können Sie passwd verwenden, um das Passwort des Jenkins-Benutzers zu ändern. Dann können Sie das Jenkins-Passwort erhalten.

Ich bin mir auch nicht sicher, ob dies das Problem für Sie ist, aber das ANT-Skript, das ich über Jenkins verwende, hat Folgendes:

<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>
Feasoron
quelle
1
Es scheint, als hätten Sie Jenkins unter einem "Macbuild" -Benutzer eingerichtet. Ich gehe davon aus, dass dieser Benutzer ein Benutzer und kein Daemon ist. Ich verstehe (jetzt) ​​definitiv, dass der Schlüsselbund über Befehlszeilenargumente entsperrt werden muss (siehe Simon Urbaneks Kommentare), aber ich bin mir immer noch nicht sicher, wie ich einen Standardschlüsselbund für den Jenkins-Daemon erstellen soll.
edelaney05
1

Aus irgendeinem Grund funktionierte das Dienstprogramm "Sicherheit" bei Lion mit neuer Jenkins-Installation nicht.

Nach "sudo su jenkins" konnte ein neuer Schlüsselbund erstellt werden, ignorierte jedoch stillschweigend alle Befehle "Standardschlüsselbund -s ..." oder "Entsperren", die den Status "Null beenden" zurückgaben und nichts auf die Konsole druckten. Das Auflisten von Standard- oder Anmeldeschlüsselanschlüssen ergab nichts, die Suchliste für Schlüsselanhänger enthielt nur Systemschlüsselbund, und ich konnte dies unabhängig von meiner Eingabe nicht ändern.

Nachdem ich mich auf dem Desktop dieses Benutzers angemeldet und das Schlüsselbund-Dienstprogramm gestartet hatte, wurde mein erstellter Schlüsselbund angezeigt, und danach funktionierte alles wie in den oberen Beiträgen beschrieben.

Ich frage mich, ob sich das Verhalten einiger anfänglicher Schlüsselanhänger in Lion geändert hat oder ob mir etwas fehlt.

Jazzkatze
quelle
Ich habe die oben genannten Schritte bei einer "sauberen" Installation von Lion ausgeführt. Vielleicht gab es also ein Sicherheitsproblem, bevor Sie hineingesprungen sind? Eine andere Möglichkeit ist, dass es seit meiner ersten Veröffentlichung ein Sicherheits- / OS X-Update gab.
edelaney05
0

Ich habe den privaten und öffentlichen Schlüssel für das Unternehmen zum Schlüsselbund hinzugefügt. Ich habe die Bereitstellungsprofile für die Produktion hinzugefügt, die ich erstellen werde.

Da dieser Benutzer kein Konto hatte, habe ich mich mit meinem Konto bei devcenter angemeldet. Die Bereitstellungszertifikate wurden heruntergeladen und in Xcode geladen.

Ich habe kein Zertifikat speziell für das Build-Rollenkonto hinzugefügt, z. Jenkins.

Ich habe dies dem Build-Skript hinzugefügt: Sicherheit entsperren-Schlüsselbund -p mySecretPassword wie oben, aber ...

Ich habe eine Datei ~ / .ssh / mypass erstellt und das Passwort zur Datei hinzugefügt.

Dann lautet der Befehl: Sicherheit entsperren-Schlüsselbund -p cat ~/.ssh/mypass

Builds funktionieren wie ein Champion. Ich bekomme die IPA-Datei, sie wird in der App Central geladen und funktioniert auf dem Gerät.

mpechner
quelle
0

Könnte JenkinsCI auch als OS X-Benutzer anstelle eines Daemons installieren und starten:

  1. Installieren Sie Jenkins mit dem offiziellen Installationsprogramm ( https://jenkins-ci.org/ ).
    • Weiter klicken
    • Klicken Sie auf "Anpassen"
    • Deaktivieren Sie "Beim Booten als 'Jenkins' starten" - * WICHTIG * Diese Option ermöglicht normalerweise kopflose Jenkins, die beim Schlüsselbundzugriff nicht gut funktionieren
  2. Starten http://127.0.0.1:8080
    • Vergewissern Sie sich, dass es NICHT gestartet wird
    • Möglicherweise müssen Jenkins gestoppt werden sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
  3. Doppelklick /Applications/Jenkins/jenkins.war
    • Natürlich sollte dies automatisiert werden, um @ start zu starten
  4. Öffnen http://127.0.0.1:8080
    • Überprüfen Sie, ob es jetzt ausgeführt wird
scotopic
quelle