当前位置：theitroad>macos OS X 上的 Jenkins：xcodebuild 给出代码签名错误

macos OS X 上的 Jenkins：xcodebuild 给出代码签名错误

声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow 原文地址: http://stackoverflow.com/questions/9245149/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示：将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间：2020-10-21 08:52:17 　来源:igfitidea点击:

Jenkins on OS X: xcodebuild gives Code Sign error

macosjenkins

提问by edelaney05

Summary:

概括：

Setting up Jenkins on OS X has been made significantly easier with the most recent installer (as of 1.449 - March 9, 2012), however managing the process of code signing is still very difficult with no straightforward answer.

使用最新的安装程序（截至 1.449 - 2012 年 3 月 9 日），在 OS X 上设置 Jenkins 变得更加容易，但是管理代码签名过程仍然非常困难，没有直接的答案。

Motivation:

动机：

Run a headless CI server that follows common best practices for running services on OS X (Some of which is explained here in plain language).

运行一个 headless CI 服务器，它遵循在 OS X 上运行服务的常见最佳实践（其中一些在此处用简单的语言解释）。

Background:

背景：

Process:

过程：

Install Jenkins CI via OS X installer package. For the "Installation Type" step, click the Customize button, and choose "Start at boot as 'jenkins.'"

通过 OS X安装程序包安装 Jenkins CI 。对于“安装类型”步骤，单击“自定义”按钮，然后选择“启动时作为‘jenkins’启动。”

Discussion:

讨论：

The naive expectation at this point was that a free-style project with the build script xcodebuild -target MyTarget -sdk iphoneosshould work. As indicated by the title of this post, it does not and fails with:

在这一点上天真的期望是一个带有构建脚本的自由风格的项目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

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

It is obvious enough what needs to happen - you need to add a valid code signing certificate and a private key into the default keychain. In researching how to accomplish this, I have not found a solution that doesn't open up the system to some level of vulnerability.

很明显需要发生什么 - 您需要将有效的代码签名证书和私钥添加到默认钥匙串中。在研究如何实现这一点时，我还没有找到一种不会将系统打开到某种程度的漏洞的解决方案。

Problem 1: No default keychain for jenkins daemon

问题 1：jenkins 守护进程没有默认的钥匙串

sudo -u jenkins security default-keychain...yields "A default keychain could not be found"

sudo -u jenkins security default-keychain...产生“找不到默认钥匙串”

As pointed out below by Ivo Dancet, the UserShell is set to /usr/bin/false for the jenkins daemon by default (I think this is a feature, not a bug); follow his answer to change the UserShell to bash. You can then use sudo su jenkinsto get logged in as the jenkins user and get a bash prompt.

正如下面Ivo Dancet所指出的，默认情况下，jenkins 守护程序的 UserShell 设置为 /usr/bin/false （我认为这是一个功能，而不是一个错误）；按照他的回答将 UserShell 更改为 bash。然后，您可以使用sudo su jenkinsjenkins 用户身份登录并获得 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
  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

Okay, great. We've got a default keychain now; let's move on right? But, first why did we even bother making a default keychain?

好，太棒了。我们现在有一个默认的钥匙串；让我们继续吧？但是，首先为什么我们还要费心去制作一个默认的钥匙串呢？

Almost all answers, suggestions, or conversation I read throughout researching suggest that one should just chuck their code signing certs and keys into the system keychain. If you run security list-keychainsas a free-style project in Jenkins, you see that the only keychain available is the system keychain; I think that's where most people came up with the idea to put their certificate and key in there. But, this just seems like a very bad idea - especially given that you'll need to create a plain text script with the password to open the keychain.

我在整个研究过程中读到的几乎所有答案、建议或对话都表明，人们应该将他们的代码签名证书和密钥放入系统钥匙串中。如果你security list-keychains在 Jenkins 中作为一个自由风格的项目运行，你会看到唯一可用的钥匙串是系统钥匙串；我认为这就是大多数人想到将他们的证书和密钥放在那里的想法。但是，这似乎是一个非常糟糕的主意 - 特别是考虑到您需要使用密码创建纯文本脚本来打开 keychain。

Problem 2: Adding code signing certs and private key

问题二：添加代码签名证书和私钥

This is where I really start to get squeamish. I have a gut feeling that I should create a new public / private key unique for use with Jenkins. My thought process is if the jenkins daemon is compromised, then I can easily revoke the certificate in Apple's Provisioning Portal and generate another public / private key. If I use the same key and certificate for my user account and Jenkins, then it means more hassle (damage?) if the jenkins service is attacked.

这是我真正开始变得娇气的地方。我有一种直觉，我应该创建一个新的公钥/私钥，供 Jenkins 使用。我的想法是，如果 jenkins 守护进程受到威胁，那么我可以轻松地在 Apple 的 Provisioning Portal 中撤销证书并生成另一个公钥/私钥。如果我的用户帐户和 Jenkins 使用相同的密钥和证书，那么如果 jenkins 服务受到攻击，则意味着更多麻烦（损坏？）。

Pointing to Simon Urbanek's answeryou'll be unlocking the keychain from a script with a plain text password. It seems irresponsible to keep anything but "disposable" certificates and keys in the jenkins daemon's keychain.

指向Simon Urbanek 的回答，您将使用纯文本密码从脚本中解锁钥匙串。在 jenkins 守护进程的钥匙串中保留除“一次性”证书和密钥以外的任何东西似乎是不负责任的。

I am very interested in any discussion to the contrary. Am I being overly cautious?

我对任何相反的讨论都很感兴趣。我是否过于谨慎？

To make a new CSR as the jenkins daemon in Terminal I did the following...

为了在终端中创建一个新的 CSR 作为 jenkins 守护进程，我执行了以下操作...

  1. sudo su jenkins
  2. certtool r CertificateSigningRequest.certSigningRequestYou'll be prompted for the following (most of these I made educated guesses at the correct answer; do you have better insight? Please share.)...
    • Enter key and certificate label:
    • Select algorithm: r(for RSA)
    • Enter key size in bits: 2048
    • Select signature algorithm: 5(for MD5)
    • Enter challenge string:
    • Then a bunch of questions for RDN
  3. Submit the generated CSR file (CertificateSigningRequest.certSigningRequest) to Apple's Provisioning Portal under a new Apple ID
  4. Approve the request and download the .cer file
  5. security unlock-keychain
  6. security add-certificate ios_development.cer
  1. sudo su jenkins
  2. certtool r CertificateSigningRequest.certSigningRequest系统会提示您进行以下操作（其中大部分是我对正确答案做出的有根据的猜测；您有更好的见解吗？请分享。）...
    • 输入密钥和证书标签：
    • 选择算法：（r对于 RSA）
    • 以位为单位输入密钥大小： 2048
    • 选择签名算法：（5对于MD5）
    • 输入挑战字符串：
    • 然后是一堆RDN的问题
  3. 将生成的 CSR 文件 (CertificateSigningRequest.certSigningRequest) 以新的 Apple ID 提交到 Apple 的 Provisioning Portal
  4. 批准请求并下载 .cer 文件
  5. security unlock-keychain
  6. security add-certificate ios_development.cer

This takes us one step closer...

这让我们更近了一步......

Problem 3: Provisioning profile and Keychain unlocking

问题 3：配置文件和钥匙串解锁

I made a special provisioning profile in the Provisioning Portal just for use with CI in hopes that if something bad happens I've made the impact a little smaller. Best practice or overly cautious?

我在 Provisioning Portal 中创建了一个特殊的配置文件，仅用于 CI，希望如果发生不好的事情，我已经使影响变小了一点。最佳实践还是过于谨慎？

  1. sudo su jenkins
  2. mkdir ~/Library/MobileDevice
  3. mkdir ~/Library/MobileDevice/Provisioning\ Profiles
  4. Move the provisioning profile that you setup in the Provisioning Portal into this new folder. We're now two short steps away from being able to run xcodebuild from the the command line as jenkins, and so that means we're also close to being able to get the Jenkins CI running builds.
  5. security unlock-keychain -p <keychain password>
  6. xcodebuild -target MyTarget -sdk iphoneos
  1. sudo su jenkins
  2. mkdir ~/Library/MobileDevice
  3. mkdir ~/Library/MobileDevice/Provisioning\ Profiles
  4. 将您在 Provisioning Portal 中设置的配置文件移动到这个新文件夹中。我们现在距离能够像 jenkins 一样从命令行运行 xcodebuild 仅几步之遥，这意味着我们也接近能够让 Jenkins CI 运行构建。
  5. security unlock-keychain -p <keychain password>
  6. xcodebuild -target MyTarget -sdk iphoneos

Now we get a successful build from a command line when logged in as the jenkins daemon, so if we create a free-style project and add those final two steps (#5 and #6 above) we will be able to automate the building of our iOS project!

现在，当我们以 jenkins 守护进程身份登录时，我们可以从命令行成功构建，所以如果我们创建一个自由风格的项目并添加最后两个步骤（上面的 #5 和 #6），我们将能够自动构建我们的 iOS 项目！

It might not be necessary, but I felt better setting jenkins UserShell back to /usr/bin/false after I'd successfully gotten all this setup. Am I being paranoid?

可能没有必要，但我觉得在我成功完成所有这些设置后，我觉得将 jenkins UserShell 设置回 /usr/bin/false 更好。我是偏执狂吗？

Problem 4: Default keychain still not available!

问题 4：默认钥匙串仍然不可用！

(EDIT: I posted the edits to my question, rebooted to make sure my solution was 100%, and of course, I'd left out a step)

（编辑：我发布了对我的问题的编辑，重新启动以确保我的解决方案是 100%，当然，我遗漏了一个步骤）

Even after all the steps above, you'll need to modify the Launch Daemon plist at /Library/LaunchDaemons/org.jenkins-ci.plist as stated in this answer. Please note this is also an openrdar bug.

即使完成上述所有步骤，您仍需要修改 /Library/LaunchDaemons/org.jenkins-ci.plist 中的 Launch Daemon plist，如本答案所述。请注意，这也是一个openrdar 错误。

It should look like this:

它应该是这样的：

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

With this setup, I would also recommend the Xcode plugin for Jenkins, which makes setting up the xcodebuild script a little bit easier. At this point, I'd also recommend reading the man pages for xcodebuild - hell you made it this far in Terminal, right?

有了这个设置，我还会推荐Jenkins的Xcode 插件，这使得设置 xcodebuild 脚本更容易一些。在这一点上，我还建议阅读 xcodebuild 的手册页 - 你在终端中做到了这一点，对吧？

This setup is not perfect, and any advice or insight is greatly appreciated.

这种设置并不完美，非常感谢任何建议或见解。

I have had a hard time selecting a "correct" answer since what I've come to use to solve my problem was a collection of just about everyone's input. I've tried to give everyone at least an up vote, but award the answer to Simon because he mostly answered the original question. Furthermore, SamiTikkadeserves a lot of credit for his efforts getting Jenkins to work through AppleScript as a plain ol' OS X app. If you're only interested in getting Jenkins up and going quickly within your user session (i.e. not as a headless server) his solution is much more Mac-like.

我很难选择一个“正确”的答案，因为我用来解决我的问题的是几乎每个人的输入的集合。我试图给每个人至少投赞成票，但将答案授予西蒙，因为他主要回答了最初的问题。此外，Sami Tikka为让 Jenkins 通过 AppleScript 作为一个普通的 OS X 应用程序工作所做的努力值得称赞。如果您只想让 Jenkins 在您的用户会话中快速启动和运行（即不是作为无头服务器），那么他的解决方案更像 Mac。

I hope that my efforts spark further discussion, and help the next poor soul who comes along thinking they can get Jenkins CI setup for their iOS projects in a weekend because of all the wonderful things they've heard about it.

我希望我的努力能引发进一步的讨论，并帮助下一个可怜的人，他们认为他们可以在周末为他们的 iOS 项目设置 Jenkins CI，因为他们听说了所有美妙的事情。

Update: August 9, 2013

更新：2013 年 8 月 9 日

With so many upvotes and favorites, I thought I would come back to this 18 months later with some brief lessons learned.

有这么多的赞成票和最爱，我想我会在 18 个月后回到这里，并吸取一些简短的教训。

Lesson 1: Don't expose Jenkins to the public internet

第 1 课：不要将 Jenkins 暴露在公共互联网上

At the 2012 WWDC I took this question to the Xcode and OS X Server engineers. I received a cacophony of "don't do that!" from anyone I asked. They all agreed that an automated build process was great, but that the server should only be accessible on the local network. The OS X Server engineers suggested allowing remote access via VPN.

在 2012 年的 WWDC 上，我向 Xcode 和 OS X Server 工程师提出了这个问题。我听到了“不要那样做！”的刺耳声音。从我问过的任何人那里。他们都同意自动化构建过程很棒，但服务器只能在本地网络上访问。OS X Server 工程师建议允许通过 VPN 进行远程访问。

Lesson 2: There are new install options now

第 2 课：现在有新的安装选项

I recently gave a CocoaHeads talk about my Jenkins experience, and much to my surprise I found some new install methods - Homebrew and even a Bitnami Mac App Storeversion. These are definitely worth checking out. Jonathan Wrighthas a gist detailing getting Homebrew Jenkins working.

我最近在 CocoaHeads 上谈论了我的 Jenkins 体验，令我惊讶的是我发现了一些新的安装方法 - Homebrew 甚至是Bitnami Mac App Store版本。这些绝对值得一试。Jonathan Wright有一个详细说明如何让Homebrew Jenkins 工作的要点。

Lesson 3: No, seriously, don't expose your build box to the internet

第 3 课：不，说真的，不要将您的构建盒暴露在互联网上

It's pretty clear from the original post that I'm neither a system administrator nor security expert. Common sense about private-y stuff (keychains, credentials, certificates, etc) left me feeling pretty uneasy about putting my Jenkins box on the internet. Nick Arnottat Neglected Potential was able to confirm my heebie-jeebies pretty easily in this article.

从原始帖子中可以清楚地看出，我既不是系统管理员也不是安全专家。关于私人物品（钥匙串、凭证、证书等）的常识让我对将我的 Jenkins 盒子放在互联网上感到非常不安。Neglected Potential 的Nick Arnott在这篇文章中很容易地证实了我的 heebie-jeebies 。

TL;DR

TL; 博士

My recommendation to others looking to automate their build process has changed over the past year and a half. Make sure your Jenkins machine is behind your firewall. Install and set Jenkins up as a dedicated Jenkins user either using the installer, Bitnami Mac App Store version, Sami Tikka's AppleScript, etc; this resolves most of the headache I detail above. If you need remote access, setting up VPN services in OS X Server takes ten minutes tops. I've been using this setup for over a year and am very happy with it. Good luck!

在过去的一年半里，我对希望自动化构建过程的其他人的建议发生了变化。确保你的 Jenkins 机器在你的防火墙后面。使用安装程序、Bitnami Mac App Store 版本、Sami Tikka 的 AppleScript 等安装和设置 Jenkins 为专用 Jenkins 用户；这解决了我上面详述的大部分头痛问题。如果您需要远程访问，在 OS X Server 中设置 VPN 服务最多需要十分钟。我已经使用这个设置一年多了，对它非常满意。祝你好运！

采纳答案by Simon Urbanek

Keychains need to be unlocked before they can be used. You can use security unlock-keychainto unlock. You can do that interactively (safer) or by specifying the password on the command line (unsafe), e.g.:

钥匙串需要先解锁才能使用。可以security unlock-keychain用来解锁。您可以以交互方式（更安全）或通过在命令行上指定密码（不安全）来执行此操作，例如：

security unlock-keychain -p mySecretPassword...

Obviously, putting this into a script compromises the security of that keychain, so often people setup an individual keychain with only the signing credentials to minimize such damage.

显然，将其放入脚本会损害该钥匙串的安全性，因此人们通常只使用签名凭据设置单独的钥匙串，以最大程度地减少此类损坏。

Typically in Terminalthe keychain is already unlocked by your session, since the default keychain is unlocked on login, so you don't need to do that. However, any process not run in your session won't have unlocked keychain even if it has you as the user (most commonly this affects ssh, but also any other process).

通常，Terminal您的会话已将钥匙串中的钥匙串解锁，因为默认钥匙串在登录时已解锁，因此您无需这样做。但是，任何不在您的会话中运行的进程都不会解锁钥匙串，即使它有您作为用户（最常见的是这会影响ssh，但也会影响任何其他进程）。

回答by Zsub

Suppose you also want to do ad hoc distribution through Jenkins, this necessitates that Jenkins has access to a Distribution certificate, and the team admin identity, in addition to the provisioning profiles.

假设您还想通过 Jenkins 进行临时分发，这需要 Jenkins 有权访问分发证书和团队管理员身份，以及供应配置文件。

Using an exported identity in a .cer file, you can programmatically import it like so, the -A switch is to allow all programs access to this entry. Alternatively, you could use several -T /path/to/programswitches to allow codesignand xcodebuildaccess.:

在 .cer 文件中使用导出的标识，您可以像这样以编程方式导入它，-A 开关是允许所有程序访问此条目。或者，您可以使用多个-T /path/to/program开关来允许codesign和xcodebuild访问。：

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

Of course, we should also have the Apple WWDCRA certificate, imported in pretty much the same way:

当然，我们还应该有 Apple WWDCRA 证书，以几乎相同的方式导入：

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

However, we also need the private key for the devcertificate.cer. To do this, you need to export the corresponding private key as a .p12 key and set a password. Put it somewhere you can access it from your Jenkins shell, unlock the keychain, and import it:

但是，我们还需要devcertificate.cer. 为此，您需要将相应的私钥导出为 .p12 密钥并设置密码。把它放在你可以从 Jenkins shell 访问的地方，解锁钥匙串，然后导入它：

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

Importing the distribution certificate works the same way. I don't know why you need to unlock the keychain for importing a .p12 and not for a .cer, but well.

导入分发证书的工作方式相同。我不知道为什么你需要解锁钥匙串来导入 .p12 而不是 .cer，但是很好。

You will also need access to the provisioning profiles, I will edit those instructions into this post shortly.

您还需要访问配置文件，我将很快将这些说明编辑到这篇文章中。

回答by brianestey

I've had the same issue and have been searching around for some time for an answer. Here's one thing that I've learned.

我遇到了同样的问题，并一直在寻找答案。这是我学到的一件事。

I am running jenkins as the jenkins user, user created by the installer, and as everyone else has mentioned he doesn't have access to the same keychain that your normal user does. Instead of trying to login as the jenkins user, I created a second build project that simply has one build step that is "Execute Shell" in which I run commands I want to test as the jenkins user.

我正在运行 jenkins 作为 jenkins 用户，安装程序创建的用户，正如其他人所提到的，他无法访问与普通用户相同的钥匙串。我没有尝试以 jenkins 用户身份登录，而是创建了第二个构建项目，该项目只有一个构建步骤，即“执行 Shell”，在该步骤中我运行我想以 jenkins 用户身份进行测试的命令。

Once I had that set up, I could run the command

一旦我进行了设置，我就可以运行命令

security list-keychains

security list-keychains

And this revealed to me that the only thing that jenkins could see was the system keychain.

这让我知道詹金斯唯一能看到的就是系统钥匙串。

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

With that knowledge, I then opened the Keychain Access app and copied my "iPhone Developer: xxxx" certificate into the System keychain (Right-click, copy from the "login" keychain).

有了这些知识，然后我打开钥匙串访问应用程序并将我的“iPhone 开发人员：xxxx”证书复制到系统钥匙串中（右键单击，从“登录”钥匙串复制）。

This got me passed the certificate/private key pair code sign error but opened up another one with the provisioning profile (seems like a similar, but different, issue).

这让我通过了证书/私钥对代码签名错误，但打开了另一个带有配置文件的错误（似乎是一个类似但不同的问题）。

回答by Ivo Dancet

To change the password you can use sudo passwd jenkins <new-pw>. However I think it would be better to use the dscl command to change the password.

要更改密码，您可以使用sudo passwd jenkins <new-pw>. 但是我认为最好使用 dscl 命令来更改密码。

In my install jenkins (official installer) had a user shell /usr/bin/false. Changing it to bash solved the problem of not being able to login:

在我的安装中，jenkins（官方安装程序）有一个用户 shell /usr/bin/false。改成bash解决了无法登录的问题：

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

You should now be able to login with su jenkins.

您现在应该可以使用su jenkins.

回答by biolinh

I have used Xcode plugin to build iOS app. In configuration of a project.

我使用 Xcode 插件来构建 iOS 应用程序。在项目配置中。

choose Add build step > Xcode > code signing & OS X keychain options.

选择添加构建步骤 > Xcode > 代码签名和 OS X 钥匙串选项。

tick Unlock keychainbox and add as follow (for examples) enter image description here

勾选解锁钥匙串框并添加如下（例如） 在此处输入图片说明

somtimes, if I get the error

有时，如果我收到错误

Code Sign error: ...

代码签名错误：...

I will reopen Jenkins and enter password again to unlock

我将重新打开Jenkins并再次输入密码解锁

回答by sti

For people having problems with keychains, I would recommend you try my alternative Jenkins installer at https://github.com/stisti/jenkins-app, downloads at https://github.com/stisti/jenkins-app/downloads

对于具有与钥匙串问题的人，我建议你试试我的替代詹金斯在安装https://github.com/stisti/jenkins-app，下载在https://github.com/stisti/jenkins-app/downloads

Jenkins.app runs Jenkins in your user session, so keychain access issues are not an issue :)

Jenkins.app 在您的用户会话中运行 Jenkins，因此钥匙串访问问题不是问题:)

回答by Feasoron

If you have sudo, you can use passwd to change the Jenkins user's password. Then you can get the Jenkins password.

如果您有 sudo，则可以使用 passwd 来更改 Jenkins 用户的密码。然后你就可以得到Jenkins密码了。

Also, I'm not sure if this is the issue for you, but the ANT Script I use via Jenkins has this :

另外，我不确定这是否是您的问题，但是我通过 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>

回答by jazzcat

For some reason, "security" utility wasn't working for me on Lion with fresh Jenkins install.

出于某种原因，“安全”实用程序在安装了全新 Jenkins 的 Lion 上对我不起作用。

After "sudo su jenkins" it was able to create new keychain, but silently ignored all "default-keychain -s ..." or "unlock" commands returning zero exit status and printing nothing to the console. Listing default or login keychains gave nothing, keychains search list was containing only system keychain, and I couldn't change this whatever I type.

在“sudo su jenkins”之后，它能够创建新的钥匙串，但会默默地忽略所有“default-keychain -s ...”或“unlock”命令，返回零退出状态并且不向控制台打印任何内容。列出默认或登录钥匙串什么也没给出，钥匙串搜索列表只包含系统钥匙串，无论我输入什么，我都无法更改它。

After I logged in to that user's desktop and launched Keychain Utility, it did show my created keychain and after that everything worked as described in upper posts.

在我登录到该用户的桌面并启动钥匙串实用程序后，它确实显示了我创建的钥匙串，之后一切都如上篇文章中所述。

I am wondering whether some of initial keychains behavior changed in Lion, or am I missing something?

我想知道 Lion 中的某些初始钥匙串行为是否发生了变化，还是我遗漏了什么？

回答by mpechner

I added the private and public key for the company to the keychain. I added the provision profiles for the production I will be building.

我将公司的私钥和公钥添加到钥匙串中。我为我将要构建的产品添加了配置文件。

Since this user did not have an account I logged into devcenter with my account. Downloaded the provisioning certs and loaded them into Xcode.

由于该用户没有帐户，因此我使用我的帐户登录了 devcenter。下载配置证书并将它们加载到 Xcode 中。

I did not add a cert specifically for the build role account, ex. jenkins.

我没有专门为构建角色帐户添加证书，例如。詹金斯。

I did add this to the build script: security unlock-keychain -p mySecretPassword as above, but...

我确实将它添加到构建脚本中： security unlock-keychain -p mySecretPassword 如上所述，但是......

I created a file ~/.ssh/mypass and add the password to the file.

我创建了一个文件 ~/.ssh/mypass 并将密码添加到文件中。

Then the command becomes: security unlock-keychain -p cat ~/.ssh/mypass

然后命令变成：security unlock-keychain -p cat ~/.ssh/mypass

Builds are working like a champ. I get the ipa file, it loads on app central and works on the device.

构建工作就像一个冠军。我得到了 ipa 文件，它加载到应用程序中心并在设备上运行。

回答by scotopic

Could also install & launch JenkinsCI as a OS X user instead of a daemon:

也可以作为 OS X 用户而不是守护进程安装和启动 JenkinsCI：

  1. install jenkins using the official installer (https://jenkins-ci.org/)
    • Click next
    • Click "Customize"
    • Unselect "Start at boot as 'jenkins'" - * IMPORTANT *this option normally allows a headless jenkins which doesn't work well with keychain access
  2. Launch http://127.0.0.1:8080
    • verify it DOESN'T launch
    • may need to stop jenkins sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
  3. Double click /Applications/Jenkins/jenkins.war
    • of course this should be automated to start @ start up
  4. Open http://127.0.0.1:8080
    • verify it's now running
  1. 使用官方安装程序安装 jenkins ( https://jenkins-ci.org/)
    • 点击下一步
    • 点击“自定义”
    • 取消选择“启动时作为‘jenkins’启动” - * 重要 *此选项通常允许无头 jenkins，它不能很好地与钥匙串访问配合使用
  2. 发射 http://127.0.0.1:8080
    • 验证它不会启动
    • 可能需要停止詹金斯 sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
  3. 双击 /Applications/Jenkins/jenkins.war
    • 当然这应该自动启动@startup
  4. 打开 http://127.0.0.1:8080
    • 验证它现在正在运行

相关推荐

macos 在 Mac OS X 上安装 Maven

macos 在 Mac OS X 上安装 Maven

macos 调用 Mac 内核恐慌？

macos 调用 Mac 内核恐慌？

macos 更改 web root apache mac OS X

macos 更改 web root apache mac OS X

macos Ollydbg 等效于 Mac OS X

macos Ollydbg 等效于 Mac OS X

相关推荐
最近更新
标签