Jenkins on OSX gets a identity crisis - macos

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.

Related

Jenkins User Not Accessible In Bash and Builds Not Working

I am trying to become a Jenkins user through this command - sudo su -s /bin/bash jenkins.
When I do run it, this happens in my shell: bash-4.2$ Killed.
I have been trying to debug it by identifying the memory allocation used on the server (we have plenty), reading debug lines of processes being killed, and the jenkins log but there's nothing that leads me towards a solution.
How do I start to debug this problem and what could be going on? There aren't any obvious errors being thrown my way.
I've discovered that when I restart the server, I can log in as the jenkins user and the jenkins builds work. However, shortly thereafter, I cannot log in and the builds no longer work.

Cannot open graphical application through command line?

I am having trouble opening graphical applications in linux (Sublime Text 2 in this case) through the terminal. I am using Fedora 17. I get this error for other graphical applications that I try to open up through the command line as well.
[root#computer djproject]# sublime settings.py
No protocol specified
(sublime:4202): Gtk-WARNING **: cannot open display: :0
Also, I get the same type of error when I try to do:
sudo sublime
Note in the command above I was logged in as a regular user without root access. Also 'sublime' is mapped to Sublime Text 2, and I have tested it before in other scenarios, so it is not the problem. Also, I have set this particular user up as a valid sudoer and the sudo command also works in other cases.
While researching the problem I came across many similar cases with no clear solution.
The following link has a user with a similar problem (although using ssh and on Ubuntu, rather than local and Fedora in my case).
Thanks in advance!
I spent quite a lot of time trying to figure this problem out, and came across this thread as I found a fix.
My problem was simply that I was running my commands from within the byobu session. I opened a new terminal tab and successfully ran the same commands.
Since DISPLAY is being defined, this may be a problem with permissions. How are you starting X? (As far as I know normally X is started by root and when you login you are granted access such that these issues don't occur, unless you're running sudo from a different account than the one you're logged into X with.)
You need to provide the correct 'cookie' file to access the session (simply being root isn't enough to get in). For users this is normally ~/.Xauthority, so executing xauth merge /home/<user>/.Xauthority should do the trick.
Alternatively have you tried gksu?
I actually needed this (run an X application from CLI with a different user), and valid workarround is to SSH -X:
user1 owns X
user2 is the second user that wants to run an X program from CLI, in this example, eclipse ide
user1:~$ ssh -X user2#localhost
The authenticity of host 'localhost (127.0.0.1)' can't be established.
ECDSA key fingerprint is
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'localhost' (ECDSA) to the list of known hosts.
user2#localhost's password:
Welcome to Ubuntu 14.04.1 LTS (GNU/Linux 3.13.0-44-generic x86_64)
user2:~$
user2:~$ /opt/eclipse/eclipse
I know this is 5 years old post, but I spend much time to solve issue like this on installation of Renderman of Pixar. Then I like to send my solution that maybe helps someone else
The problem is because of this "sudoer (here root) has no access to graphical space". (I don't know it is always or sometimes. I faced this issue on Ubuntu 16.04)
Doing the following solved my issue:
first, start Terminal as graphical user, Alt+Ctrl+T
then, execute these lines
$ unset XAUTHORITY
$ xhost add $DISPLAY . 123f
$ xhost +local:all
$ sudo xclock # or any graphical program needs sudoer
Let me know your feedbacks

Fixing Jenkins privileges on build

I have a complex script - that Jenkins executes on build - which needs to check for events in /var/log/syslog. In order to do so, I added the user "jenkins" to the group syslog belongs to and set the file permissions to 0640.
The script above runs perfectly fine when manually executed, but when invoked by Jenkins build system it fails: indeed, the output console shows that the script has not the permission to read /var/log/syslog when invoked via Jenkins.
A quick check with whoami shows that the building process runs with "jenkins" as user, though. Hence, I cannot understand why the script behavior is different.
I haven't used jenkins, so this might not be what's going on, but do you know if you are running under SELinux or any other sort of mandatory-access-control system?
That tends to be my knee-jerk reaction to strange permissions issues.
If SELinux is enabled, try checking /var/log/audit/audit.log to see if there are any denials to read /var/log/syslog.
If you are on Linux, the command "getenforce" should tell you whether SELinux is running or not.

Cron job to mount encrypted sparse bundle

I can run the following command in terminal to mount an encrypted sparsebundle where the bundle password is stored in the keychain.
hdiutil attach '/Volumes/Backup/Mac1.sparsebundle'
I would like to have that command run on a schedule, so I'm using CronniX to create a cron job with that command. But, when it runs at the scheduled time, nothing happens. When I check the cron daemon mail in terminal, it says the following:
hdiutil: attach failed - Authentication error
I'm assuming that it isn't able to read the password from keychain? I don't know. Hoping somebody can shed some light on things, or point me in the right direction.
Thanks
hdiutil depends on some environment variables. Check this (ENVIRONMENT section). So, probably the environment is different when you run from terminal and from cron. According to error, I think this is due to absence of com_apple_diskimages_insecureHTTP. However the same effect will give adding -insecurehttp to the arguments or specify SSL certificate with -cacert/-capath.

Keychain won't unlock from Jenkins script unless user logged in

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.

Resources