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:
- 12. Oktober 2009 - So automatisieren Sie die Erstellung Ihrer iPhone-App mit Hudson
- 15. Juni 2011 - Jenkins unter Mac OS X; Git w / ssh öffentlichen Schlüssel
- 23. Juni 2011 - Kontinuierliche Bereitstellung von iOS-Apps mit Jenkins und TestFlight
- 26. Juli 2011 - Fehlende Zertifikate und Schlüssel im Schlüsselbund bei Verwendung von Jenkins / Hudson als kontinuierliche Integration für die iOS- und Mac-Entwicklung
- 30. August 2011 - Xcode-Bereitstellungsdatei bei Jenkins nicht gefunden
- 20. September 2011 - So richten Sie Jenkins CI auf einem Mac ein
- 14. September 2011 - Jenkins auf einem Mac zum Laufen bringen
- 12. November 2011 - Howto: Installieren Sie Jenkins unter OS X und lassen Sie es Mac-Inhalte erstellen
- 23. Januar 2012 - Bevorstehende Änderungen am Jenkins OSX-Installationsprogramm
- 7. März 2012 - Vielen Dank, dass Sie OSX Installer verwenden
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 iphoneos
funktionieren 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 jenkins
als Jenkins-Benutzer anmelden und eine Bash-Eingabeaufforderung erhalten.
sudo su jenkins
cd ~/Library
mkdir Keychains
cd Keychains
security create-keychain <keychain-name>.keychain
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-keychains
in 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 ...
sudo su jenkins
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
- Senden Sie die generierte CSR-Datei (CertificateSigningRequest.certSigningRequest) unter einer neuen Apple ID an das Apple Provisioning Portal
- Genehmigen Sie die Anforderung und laden Sie die CER-Datei herunter
security unlock-keychain
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?
sudo su jenkins
mkdir ~/Library/MobileDevice
mkdir ~/Library/MobileDevice/Provisioning\ Profiles
- 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.
security unlock-keychain -p <keychain password>
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!
Antworten:
Schlüsselanhänger müssen entsperrt werden, bevor sie verwendet werden können. Sie können
security unlock-keychain
zum Entsperren verwenden. Sie können dies interaktiv (sicherer) oder durch Angabe des Kennworts in der Befehlszeile (unsicher) tun, z.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
Terminal
der 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 diesssh
, aber auch jeden anderen Prozess).quelle
security unlock-keychain -p password -k /path/codesign.keychain
funktioniert nicht-k
Argument dafür gibt,unlock-keychain
sodass alles, was Sie versuchen, nicht richtig erscheint (siehesecurity help unlock-keychain
).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.dscl
zum 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önnensudo -u jenkins -i
Sie entsprechende Anmeldeeinstellungen abrufen).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/program
Schalter verwenden, um Folgendes zuzulassencodesign
und daraufxcodebuild
zuzugreifen :.Natürlich sollten wir auch das Apple WWDCRA-Zertifikat haben, das auf die gleiche Weise importiert wird:
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: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.
quelle
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.
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).
quelle
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:
Sie sollten sich jetzt anmelden können
su jenkins
.quelle
create-keychain
Befehl, der nicht mit dem Jenkins-Benutzer funktioniert. Das Ausführen dieses Befehls schien das Problem zu beheben.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)
Manchmal, wenn ich den Fehler bekomme
Ich werde Jenkins erneut öffnen und das Passwort erneut eingeben, um es zu entsperren
quelle
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 :)
quelle
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:
quelle
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.
quelle
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.
quelle
Könnte JenkinsCI auch als OS X-Benutzer anstelle eines Daemons installieren und starten:
http://127.0.0.1:8080
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
/Applications/Jenkins/jenkins.war
http://127.0.0.1:8080
quelle
Um dieses Problem zu beheben, melden Sie sich bei http://appleid.apple.com an und aktualisieren Sie Ihre Sicherheitsfragen.
Es hat mir geholfen.
quelle