I created a job in jenkins and I want to build the project using ansible. I want to run my command on several host (that's why I use ansible). When I try to run the project it fails with some permission error:
/home/ubuntu/install.sh -s -U ubuntu -f 5
FATAL: command execution failed
java.io.IOException: Cannot run program "/usr/bin/ansible" (in directory "/var/lib/jenkins/jobs/Standard Demo/workspace"): error=13, Permission denied
at java.lang.ProcessBuilder.start(ProcessBuilder.java:1047)
at hudson.Proc$LocalProc.<init>(Proc.java:244)
at hudson.Proc$LocalProc.<init>(Proc.java:216)
Do you know what the problem is? I am logged into the jenkins server as admin user.
This is not an Ansible problem, it is a configuration issue in Jenkins. As others have noted, by default Jenkins will run as a "normal user" (typically jenkins). That is the user that jobs and steps (including shell scripts like the one you're calling) will run as. In your case, this user does not have sufficient permissions to run Ansible.
I don't recommend changing this default user because a. there are good security reasons for this setup, and b. it can actually be complex to do right, because you would have to address permissions issues for all of Jenkins to match the new user. However, it's quite easy to do things like run sudo from within a Script build step. Just use that tool (and a properly configured /etc/sudoers) to gain the permissions you need during the build.
Related
I'm trying to run kubectl commands inside jenkins pipeline but they are failing. Outside in powershell window they work fine but in the pipeline, they show this when doing:
kubectl cluster-info --v=99
I've tried adding --token $TOKEN (jwt generated) following some other thread's recommendation but didn't work. Anyone know why this is happening and any way to bypass it? All these commands work fine when ran outside the jenkins pipeline.
The problem was jenkins actually uses a different home directory and so even if your kubectl work in command line, it won't run if jenkins runs it from the pipeline as it doesn't have access to the credentials from the user directory.
So find your .kube config folder, usually in C:/users/ and then copy and paste that folder in the $JENKINS_HOME directory. The jenkins home directory can vary depending on how you installed it (for windows installers, it gets put in an obscure location inside System32). Once done, then jenkins will have access to the same certificates you use natively to run kubectl commands and it will have full access.
The session logging we have in {{/etc/profile}} can interfere with services that launch sub-shells as new users - specifically, it always launches an interactive terminal, regardless of the context, which can cause certain key processes (e.g. Jenkins) from being able to perform critical tasks.
We had a Jenkins version upgrade and after hte upgrade, Jenkins seems to not be able to restart. Here’s what’s happening
```ubuntu#hoatname:~$ sudo service jenkins status
Correct java version found
Jenkins Automation Server is not running
ubuntu#hostname:~$ sudo service jenkins start
Correct java version found
Starting Jenkins Automation Server jenkins jenkins#hostname:~$
jenkins#hostname:~$
jenkins#hostname:~$ sudo service jenkins status
[sudo] password for jenkins:
jenkins#hostname:~$ exit
exit
[fail]
ubuntu#hostname:~$
```
Essentially, it seems that “service jenkins start” is somehow causing a session to be created, which dumps it into a script. I suspect this is due to how /etc/profile contains a script-based session logger, and i suspect that Jenkins is attempting to execute this script when it su’s into its own jenkins user
What should I do to alleviate this?
I've installed Jenkins from repository for Red Hat 7.
sudo rpm --import https://pkg.jenkins.io/redhat-stable/jenkins.io.key
yum install jenkins
And got a very simple question - after install we have system user jenkins:
jenkins:x:956:967:Jenkins Automation Server:/var/lib/jenkins:/bin/false
What is general purpose of this user? (i know that it's running Jenkins Instance) That's all what it for?
Never thought about.. and no any search answer. :)
If I'm changing it to login user and changing password etc., What it can affect? Any future behavior/issues of the jenkins server?
Thank you.
Jenkins is basically a service/daemon i.e similar to lots of other services which doesn't actually needs a shell to run like apache sendmail etc.
Try comparing it with other services by doing cat /etc/passwd on your system.
Jenkins uses the user jenkins to manage permissions & segregation between services like other services do.
Jenkins by default uses sh shell to execute your shell commands defined in your build jobs.
In case you really want to login using jenkins user & perform operations, give it a shell by running below command -
usermod -s /bin/bash jenkins
I am trying to create a new directory and copy files to it. So I'm using a job of "Execute batch command".
First I tried to run: robocopy source destination /e.
Then I tried: mkdir destination. In both cases I got an "Access is denied" mssage.
If I try it myself manualy I am able to create a directory and copy files to it.
The destination is a remote computer's shared folder: \computerName\sharedFolder\
Anyone knows how to get access rights with Jenkins?
I know this post is a bit old but I found two solutions that work pretty well so I'm posting it in case somebody needs it.
First: allowing the disk usage for the current run
On your "Execute batch command" you can add a line:
net use \\server\folder /USER:domain\user password
You can then use \server\folder in your commands and it'll work.
Jenkins can even deal with credentials so that there's not in plain text.
The second solution is to boot Jenkins as a specific user so that all the commands will be run as this user.
To do this:
Open services app in windows
Search for Jenkins
Right click, properties
On Log On tab configure the credentials you want to use
Reboot Jenkins
I hope this helps someone
To find out the user under which your jobs run, create a "scratch" job in Jenkins. Give it a single "Execute Windows Batch command" build step and enter "set" as the text of your batch command. If your affected job is running on a Windows slave, make sure this job runs on the same slave. Run the job. Your console will show a list of the environment variables known to that job, the same as if you typed "set" in a Command Prompt window on your desktop. The difference will be that near the bottom, the username shown for "USERDOMAIN" and "USERNAME" in your command window will be you (the user you are logged in as); in the console output, it will be the user account that your Jenkins job runs under.
That user may not actually have login rights. And, if Jenkins is running as a service, you can't just set up a share in your command window: Jenkins jobs run under a different Windows "session" and that session will not see the share you created in your login session.
A not-very-secure way to get you over the hump would be to add parameters to your job for the username (string parameter) and password (password parameter). Before you need access to the drive, either in the same build step or in a 'Execute Windows Batch Command' step that runs prior to that build step, run "#net use : \computername\sharename %% /USER:%% /persistent:no". (for example: "#net use p: \COMPUTER\SHARE %PASSWORD% %USER% /persistent:no"). The "#" will keep the password from showing in the log. (However, the password will be associated with the job and will be encoded in Jenkins if "Allow rebuild" is enabled.) Make sure when you are done you clean up ("net use /delete") and you may need to test and clean up the drive letter before you try to connect, in case a previous job failed without releasing the drive letter.
In this scenario you would have to enter a username and password for someone who can access the share when you run the job. You could encode hidden parameters with these values pre-filled in, but that means that user's username and password are encoded into the job definition, and the default for the hidden password parameter would not be encrypted in the Jenkins config files.
There are definitely more secure ways to get the drive share enabled in the Jenkins service session, but depending on your environment this may be 'good enough' to get you past the block you are faced with right now. I have used tricks like these in an environment where I was not a Jenkins administrator and I had very limited access rights (and no admin rights) on the Jenkins slaves.
In my setup, the Jenkins slave service runs under a specific user (named jenkins).
It makes it easy to verify the access rights for that specific user.
Of course jenkins needs to have write access on the remote folder, both on the physical disk and the share.
I read the part of the Jenkins wiki that covers setting up a remote job to be monitored by a Jenkins instance. However, the documentation is confusing as it doesn't tell me what to configure on the Jenkins machine or the remote machine (the one that does the job).
Further, the documentation mentions Java commands that can be fired directly and others that need a servlet container. Do I have to install a servlet container on the remote machine?
Maybe it's all there but for me it's like a mix of two documentations. Can you please clarify:
What do I need to do on the remote machine?
What do I need to do on the Jenkins machine?
Thank you.
In Jenkins, you need to create a job using the "Monitor an external job" option. Give this a name, for example "nightly-backup".
On the machine where the external job is running, you need Java installed and some basic Jenkins JAR files, so that the job results can be sent to Jenkins.
As the wiki page says, on some versions of Debian or Ubuntu you can do this with:
sudo apt-get install jenkins-external-tool-monitor
Otherwise, you have to copy a bunch of JARs manually — i.e. those listed on the wiki page — to your remote machine.
Once you have the JARs available on your remote machine, you can execute whichever command you like there, so long as you prefix it with some Jenkins information: where to find the Jenkins installation, the main Java JAR, and the job name:
JENKINS_HOME=http://my-jenkins/ java -jar jenkins-core-*.jar nightly-backup ./backup.sh --nightly /home
Where http://my-jenkins/ is the base URL to Jenkins, nightly-backup matches the name of the "Monitor an external job" you created in Jenkins, and ./backup.sh --nightly /home is the command you wish to run.
The output of this ./backup.sh command will show up in Jenkins automatically once it's complete.
It looks like this is now called "jenkins-external-job-monitor", so you'd type:
sudo apt-get install jenkins-external-job-monitor