I'm running a Jenkins CI server on an OS X machine. The server is running as a standard user 'john', and is started by running launchctl. One of the things this server does is build XCode projects using keys and certificates stored in a keychain 'xcode.keychain':
Jenkins (which is running under the user 'john' according to activity monitor) calls these commands from a script when the user presses a button on the web interface.
security default-keychain -s /Users/john/Library/Keychains/xcode.keychain
security unlock-keychain -p password /Users/john/Library/Keychains/xcode.keychain
xcodebuild ...
If I happen to be logged into the server as 'john' via the UI, the keychain gets unlocked properly when Jenkins calls those commands. But, if I'm not logged in, xcode.keychain doesn't get unlocked and the build fails. Any ideas?
I had to:
Right-click on the private key in my keychain that my build process
was trying to use
Click "Get Info"
Then the "Access Control" tab.
You can add specific apps (like "codesign") to the list of apps that
are allowed access to that key, or just allow access from all applications.
This cleared it up for me.
More info in these comments:
https://stackoverflow.com/a/12235462/544130
https://stackoverflow.com/a/14761060/544130
Running Jenkins without launchd works. I used the following command:
sudo su jenkins -c "JENKINS_HOME=/Users/Shared/Jenkins/Home /Library/Application\ Support/Jenkins/jenkins-runner.sh"
I stumbled upon the exact same issue recently.
security list-keychains -s /Users/john/Library/Keychains/xcode.keychain probably will fix your problem. Let me know if it works.
Recently I found a solution to this over there: Missing certificates and keys in the keychain while using Jenkins/Hudson as Continuous Integration for iOS and Mac development
You could try Jenkins.app, an alternative way to run Jenkins. It runs Jenkins in a user session, so Keychain should not be a problem.
Related
By running security list-keychain -d user locally, all user's keychains are listed, as expected... However, when remotely (ssh) running the same command, only the system keychain is presented.
Even weirder, when locally running the security default-keychain -d user command, it correctly presents the login keychain but when running the same command remotely (ssh) it keeps presenting the system keychain.
BTW, I'm running both commands with the same user.
Things that I've already tried to solve this:
Unlock all the keychains
Allow any application to access keychains certificates' private keys.
2.1 Allow ssh and ssh-agent apps to access those private keys as well
Tried to add those keychains to the search list
And other things I can't even remember
Any help is appreciated.
Thanks.
By restarting the mac mini machine, the problem was solved. Once again reboot to the rescue...
Hope this can help anyone out there.
Have fun.
I set up a CI server for Xamarin.Forms using TeamCity on a mini Mac. When I run the build command from the terminal as root it builds successfully, but when I try to fire up a build from the Web UI it fails with the following error:
/Library/Frameworks/Mono.framework/External/xbuild/Xamarin/iOS/Xamarin.iOS.Common.targets(0,0):
Tool exited with code: 1. Output: mdimport will not import on behalf
of root user. Exiting.
Amr, I cannot speak to Mac, but in Windows TC installs by default with the system account which would prevent any program/tools installed under a specific user account to run from TC Web UI. In Windows, I had to change the account for the service under which the teamcity server runs. I'm guessing you would have to do the same for Mac.
Stop the TC server service. Change the service user from system to your user. Start the TC server service.
this happens when you do:
sudo mdimport
but not:
mdimport
So, make sure that you currently own the current folder and you have read, write and execute permissions as well.
The solution is to install TeamCity in the recommended directory which is the /Library/TeamCity folder.
I have Jenkins running on OSX 10.8.2. I will often leave a session logged in and su'd into the Jenkins account.
On occasion I will get a cryptic call/email/text from a socially inept user who say simply that "Jenkins is broken" and attaches a useless log snippet indicating that Jenkins could not talk to a remote host because the keys were invalid. The Jenkins build fails. The first thing I do is a "whoami" on the session I'm logged into.
whoami -> _assetcache
I type "exit"
whoami -> root
sudo su - jenkins
whoami -> jenkins
What causes it to think the user has become _assetcache? Why is it fixed by simply logging back into the account? When I check ownership on the jenkins user files they show _assetserver for the user and group too, but logging out and back in seems to clear the issue every time. Any idea what may be causing the issue?
Thanks
I would still like to know what causes this, but I have a hack that addresses the issue and for whatever reason, as strange as it may seem, it works:
As root I run a cron script once a hour that executes: sudo su - jenkins
I don't consider the problem solved, but at least that's a workaround. Longer term, I'm recommending that we simply move off the OSX platform and onto a AWS platform.
[Not a duplicate of similar questions as explained further down]
I'm getting a code signing error when running XCodeBuild from within Jenkins but it will build ok from the command line or from within Xcode.
Several people have had this problem in the past and the common theme with them is that Jenkins gets run at launch time as the daemon user and thus tries to access the system keychain.
The solutions that people have applied are copying credentials to the system keychain or running a command to set which keychain to use.
However in my case if I look at launchd in the Activity Manager the user is showing up as the user I am logged onto the machine as, therefore Jenkins should be running as this user and not as the daemon user.
I tried setting which keychain to use by adding this command to the Jenkins script before running XCodeBuild
security list-keychains -s /Users/[user]/Library/Keychains/login.keychain
But that did not solve the problem.
The error I am getting is:
Code Sign error: The identity 'iPhone Developer: NNNNN (9TYX5WAM63)' doesn't match any valid, non-expired certificate/private key pair in your keychains"
So I tried moving the credentials to the system keychain but now get this error in Jenkins, but its still fine from the command line:
Code Sign error: Provisioning profile 'F152C66E-B99A-47F6-B262-376CE4403D71' can't be found
Also when I move the credentials to the system keychain I am no longer able to build from within XCOde - I get the same error as the top error message above.
I've also tried editing the org.jenkins-ci.plist file to set the user as who I'm logged onto the machine as, in accordance with this, but that too had no effect.
Missing certificates and keys in the keychain while using Jenkins/Hudson as Continuous Integration for iOS and Mac development
Any ideas what I could try next?
I feel for you as the last time we messed with this it was quite the challenge. We did this when we set up a CI server for a project. If I remember correctly (broadly) we followed these steps:
1) Set Jenkins up as a developer on the Apple Dev account
2) Created a cert and dev provisioning profile specifically for Jenkins
3) Setup a Jenkins user on the CI Server and delete any previous certs/prov profiles from xcode for that user
4) Add the Jenkins cert to the AD-Hoc Dist Profile (If you are trying to distribute an .ipa to HockeyApp you will need to to this for an archive build.)
5) Go into the xcode project file and delete any existing references to Provisioning Profiles
6) Download and Install the certs for this user and the appropriate Prov Profiles.
7) Before the build unlock the Jenkins user keychain. Do this only if the Jenkins user is not the user running the xcode build.
Verify that Xcode shows the Prov Profile as valid in the organiser when logged in as the Jenkins user.
I know my answer is somewhat vague and my intent is to be helpful. This type of error is usually caused by one of three things. Xcode cant find the profile, Xcode cant find the cert or Xcode found more then one profile (supposed to produce a different error but doesn't always) and has a mismatch of some kind. Usually redoing the Prov Profiles is the least painful solution.
Best of luck man. You will solve it it's just a huge headache!
Probably not the answer you are looking for, but i gave up on the XCodeBuild plugin for a number of reasons, and running my build through "Execute Shell" step.
You said your command line build works, so you already know the commands that are required. Just put that into the shell.
xcodebuild -verbose -alltargets -configuration Debug clean build CODE_SIGN_IDENTITY="${CODE_SIGN_IDENTITY}" PROVISIONING_PROFILE=${PROVISIONING_PROFILE}
&&
/usr/bin/xcrun -sdk iphoneos PackageApplication -v "${WORKSPACE}/client_trunk/build/Debug-iphoneos/${Application}.app" -o "${WORKSPACE}/client_trunk/build/Debug-iphoneos/${Application}-Debug-${shortVer}.${revVer}.ipa" --sign "${CODE_SIGN_IDENTITY}" --embed "/Users/[youruser]/Library/MobileDevice/Provisioning Profiles/${PROVISIONING_PROFILE}.mobileprovision"
Above, ${CODE_SIGN_IDENTITY} is the one that looks like iPhone Developer: blah
And ${PROVISIONING_PROFILE} is the hex number for the profile like F152C66E-B99A-47F6-B262-376CE4403D71
Follow instruction on the Xcode Plugin home page :
If this prompt is not showing on the build machine, you can force it to appear by running the codesign command that failed from a terminal on the build machine: /usr/bin/codesign --force --sign "iPhone Distribution: .....
Execute failed signing command from the terminal as a Jenkins user and select "Always allow"
Using Jenkins I got this error:
/Users/Shared/Jenkins/Home/jobs/ExampleTabbed-Integration/workspace/build/Debug-iphoneos/ExamplesTabbed.app: User interaction is not allowed.
Command /usr/bin/codesign failed with exit code 1
I fixed it by doing the following:
Add Build Step before the XCode (jenkins plugin) step
Add the following as the execute command:
security unlock-keychain -p "passwordhere" ${HOME}/Library/Keychains/login.keychain
In the XCode (via plugin) configuration I'm using the following:
Unlock Keychaing ? (unchecked)
Keychain path: ${HOME}/Library/Keychains/login.keychain
Keychain password: (empty)
It might be possible to remove the pre-step and use the actual xcode config to do it, but it's working as described with no problems.
Note this doesn't take into account using a more secure solution yet, but this was my solution to the xcode signing issue. I'm running on OSX with the Jenkins installer and running as a launchctl command, used by the default Jenkins installer application. If that helps.
Subprocesses of Java/Jenkins will need to have unlocked access to the Keychain.
Let's say your build / code-sign / release process is working fine. The only blocker is when you try running the exact same process in Jenkins.
Chances are that the keychain is locked, not for the user, but for Jenkins sub-processes.
The security command to unlock the keychain will need to be run as a Jenkins job, just once. Even if the same logged in user has already unlocked the keychain in the terminal.
So setup a simple freestyle job in Jenkins and add the following shell command as a build phase.
security unlock-keychain -p $PASSWORD /Users/$MACOS_USER/Library/Keychains/login.keychain-db
Provide $PASSWORD as an input parameter for the Jenkins job.
$MACOS_USER the macos username of the Mac keychain owner.
Once you've run this job choose "Always Allow" from the keychain prompt. Now, try your regular build/release job & it should work. Assuming you have all the required certificates in the login keychain.
NEVER HARDCODE PASSWORDS INTO CONFIG/JOBS/CODE etc.
Trying to run a simple
svn list svn+ssh://...
from within jenkins on os X, as an execute shell step. The job is not linked to a SVN repository - I am trying to do an svn list manually on the tags folder without having jenkins downloading a copy of each tag.
but other jobs are connected to svn and jenkins checks out code fine.
I have downloaded jenkins from here which runs jenkins as a daemon
The problem is ssh keys. After a few iterations, here where I am at.
In /Library/LaunchDaemons/org.jenkins-ci.plist I have set JENKINS_HOME as /Users/Shared/Jenkins/Home (that's where jenkins gets installed), and in there I have created ssh keys, without passphrase (for now)
The actual command I am running is
svn --config-dir=/Users/Shared/Jenkins/Home/.subversion list svn+ssh://...
to get around jenkins running shell steps as root without actually having root permissions (not sure why - jenkins is launched by loading /Library/LaunchDaemons/org.jenkins-ci.plist) and causing a permission error when it tires to read /var/root/.servers
in --config-dir=/Users/Shared/Jenkins/Home/.subversion/config I have added
ssh = $SVN_SSH ssh -v -i /Users/Shared/Jenkins/Home/.ssh/id_rsa
so ssh can connect to the server. The last missing step now is that the shell expects the passphrase and cannot get it from Keychain (obviously)
debug1: read_passphrase: can't open /dev/tty: Device not configured
I thought leaving an empty passphrase would do the job, but it doesn't. Any clues? Thanks in advance.
I don't think there is a workaround to "read_passphrase: can't open /dev/tty: Device not configured" - the command expects terminal input and can't get it, nor can it get Keychain to provide it. It's all tied in with running as a daemon.
In the end I downloaded the latest version of the jenkins installer and re-installed to run manually and not as a daemon, so it runs as me instead of some weird flavour of root, and the problem disappeared.