I need to remotely trigger a Jenkins build hosted on CloudBees. Right now, I'm attempting to use jenkins-cli to no avail. Right now I am authenticating using a SSH key pair.
When I do:
$ java -jar jenkins-cli.jar -s https://... list-jobs All
I can see all the jobs, including the one I want to build. But when I do:
$ java -jar jenkins-cli.jar -s https://... build job1
No such job 'job1'
I've read about a workaround that involves adding permissions to the anonymous role. Even if I add every single permission to it, I get the same error.
If it helps, I'm using Jenkins 1.532.1.3. Thanks.
Today I ran into same problem and found the solution. The response 'no such job' comes when there is actually no such job or you don't have enough access to do requested operation.
Even when you have the access for requested operation and you are sending credentials with --username and --password arguments it still not works. Only solution I found was to use ssh authentication. So register your computer's ssh key to your jenkins and everything works fine. To register ssh key go to http://[yourjenkinsserver]/user/[username]/configure
I ran into the same error but managed to make it work by providing read permission in 'job' for anonymous user.
I encountered the same issue today on v1.621-1.1 while trying through a non-admin user which I named as 'vikas027'. In order to fix this I ticked all checkboxes under 'Job' column for user 'vikas027' and ticked 'Discover' and 'Read' (also under 'Job') for 'Anonymous' user. These settings are in http://<IP>:<port>/configureSecurity. Hope this helps someone.
Related
In Jenkins, I would like to execute my scriptler script via REST API from bash and curl. According to documentation it should work, but there isn't any working example.
I have created simple script testScr, which is just one liner: println "OK". I'm trying to execute it with curl:
curl -d '{}' --user <userid>:<Token> http://<jenkins_server>/scriptler/run/testScr > result.html
Resulting html says: "Oops! A problem occurred while processing the request."
How to do it correctly? Is even it working for somebody?
Yes that works for me.
Have you made sure that the user have the right permission and the token is corrct?
In my case I'm using Role-based Authorization Strategy
And you can execute it if you're admin
if you want another user different that admin execute it you can also grant permissions
I am using the credentials plugin in Jenkins to manage credentials for git and database access for my team's builds. I would like to copy the credentials from one jenkins instance to another, independent jenkins instance. How would I go about doing this?
UPDATE: TL;DR Follow the link provided below in a comment by Filip Stachowiak it is the easiest way to do it. In case it doesn't work for you go on reading.
Copying the $HUDSON_HOME/credentials.xml is not the solution because Jenkins encrypts paswords and these can't be decrypted by another instance unless both share a common key.
So, either you use the same encription keys in both Jenkins instances (Where's the encryption key stored in Jenkins? ) or what you can do is:
Create the same user/password, you need to share, in the 2nd Jenkins instance so that a valid password is generated
What is really important is that user ids in both credentials.xml are the same. For that (see the credentials.xml example below) for user: Jenkins the identifier <id>c4855f57-5107-4b69-97fd-298e56a9977d</id> must be the same in both credentials.xml
<com.cloudbees.plugins.credentials.SystemCredentialsProvider plugin="credentials#1.22">
<domainCredentialsMap class="hudson.util.CopyOnWriteMap$Hash">
<entry>
<com.cloudbees.plugins.credentials.domains.Domain>
<specifications/>
</com.cloudbees.plugins.credentials.domains.Domain>
<java.util.concurrent.CopyOnWriteArrayList>
<com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
<scope>GLOBAL</scope>
<id>c4855f57-5107-4b69-97fd-298e56a9977d</id>
<description>Para SVN</description>
<username>jenkins</username>
<password>J1ztA2vSXHbm60k5PjLl5jg70ZooSFKF+kRAo08UVts=
</password>
</com.cloudbees.plugins.credentials.impl.UsernamePasswordCredentialsImpl>
</java.util.concurrent.CopyOnWriteArrayList>
</entry>
</domainCredentialsMap>
</com.cloudbees.plugins.credentials.SystemCredentialsProvider>
I was also facing the same problem. What worked for me is I copied the credentials.xml, config.xml and the secrets folder from existing jenkins to the new instance. After the restart of jenkins things worked fine.
This is what worked for me.
Create a job in Jenkins that takes the credentials and writes them to output. If Jenkins replaces the password in the output with ****, just obfuscate it first (add a space between each character, reverse the characters, base64 encode it, etc.)
I used a Powershell job to base64 encode it:
[convert]::ToBase64String([text.encoding]::Default.GetBytes($mysecret))
And then used Powershell to convert the base64 string back to a regular string:
[text.encoding]::Default.GetString([convert]::FromBase64String("bXlzZWNyZXQ="))
After trying quite a few things for several days this is the best solution I found for migrating my secrets from a Jenkins 2.176 to a new clean Jenkins 2.249.1 jenkins-cli was the best approach for me.
The process is quite simple just dump the credentials from the old instance to a local machine, or Docker pod with java installed, as a XML file (unencrypted) and then uploaded to the new instance.
Before starting you should verify the following:
Access to the credentials section on both Jenkins instances
Download the jenkins-ccli.jar from one of the instances (https://www.your-jenkins-url.com/cli/)
Have User and Password/Token at hand.
Notice: In case your jenkins uses an oAuth service you will need to
create a token for your user. Once logged into jenkins at the top
right if you click your profile you can verify both username and
generate password.
Now for the special sauce, you have to execute both parts from the same machine/pod:
Notice: If your instances are using valid Certificates and you want to
secure your connection you must remove the -noCertificateCheck
flag from both commands.
# OLD JENKINS DUMP #
export USER=madox#example.com
export TOKEN=f561banana6ead83b587a4a8799c12c307
export SERVER=https://old-jenkins-url.com/
java -jar jenkins-cli.jar -noCertificateCheck -s $SERVER -auth $USER:$TOKEN list-credentials-as-xml "system::system::jenkins" > /tmp/jenkins_credentials.xml
# NEW JENKINS IMPORT #
export USER=admin
export TOKEN=admin
export SERVER=https://new-jenkins-url.com/
java -jar jenkins-cli.jar -noCertificateCheck -s $SERVER -auth $USER:$TOKEN import-credentials-as-xml "system::system::jenkins" < /tmp/jenkins_credentials.xml
If you have the credentials.xml available and the old Jenkins instance still running, there is a way to decrypt individual credentials so you can enter them in the new Jenkins instance via the UI.
The approach is described over at the DevOps stackexchange by kenorb.
This does not convert all the credentials for an easy, automated migration, but helps when you have only few credentials to migrate (manually).
To summarize, you visit the /script page over at the old Jenkins instance, and use the encrypted credential from the credentials.xml file in the following line:
println(hudson.util.Secret.decrypt("{EncryptedCredentialFromCredentialsXml=}"))
To migrate all credentials to a new server, from Jenkins: Migrating credentials:
Stop Jenkins on new server.
new-server # /etc/init.d/jenkins stop
Remove the identity.key.enc file on new server:
new-server # rm identity.key.enc
Copy secret* and credentials.xml to new server.
current-server # cd /var/lib/jenkins
current-server # tar czvf /tmp/credentials.tgz secret* credentials.xml
current-server # scp credentials.tgz $user#$new-server:/tmp/
new-server # cd /var/lib/jenkins
new-server # tar xzvf /tmp/credentials.tgz -C ./
Start Jenkins.
new-server # /etc/init.d/jenkins start
Migrating users from a Jenkins instance to another Jenkins on a new server -
I tried following https://stackoverflow.com/a/35603191 which lead to https://itsecureadmin.com/2018/03/26/jenkins-migrating-credentials/. However I did not succeed in following these steps.
Further, I experimented exporting /var/lib/jenkins/users (or {JENKINS_HOME}/users) directory to the new instance on new server. After restarting the Jenkins on new server - it looks like all the user credentials are available on new server.
Additionally, I cross-checked if the users can log in to the new Jenkins instance. It works for now.
PS: This code is for redhat servers
Old server:
cd /var/lib/jeknins
or cd into wherever your Jenkins home is
tar cvzf users.tgz ./users
New server:
cd /var/lib/jeknins
scp <user>#<oldserver>:/var/lib/jenkins/user.tgz ~/var/lib/jenkins/.
sudo tar xvzf users.tgz
systemctl restart jenkins
Did you try to copy the $JENKINS_HOME/users folder and the $JENKINS_HOME/credentials.xml file to the other Jenkins instance?
I want to protect some Jenkins builds from the auto cleanup. I have found the http://ci.jenkins.com/job/[job_name]/[build_v]/toggleLogKeep however this requires me to check the state. Are there any other end points I can use. Ideally it would be /keepBuildForever /dontKeepBuildForever
It looks like there is no good solution. The best way is to list all keep forever builds. Then check if it is already in the list, if not hit the /toggleLogKeep endpoint
buildsXml = http://ci.jenkins.com/api/xml?depth=2&xpath=/hudson/job/build[keepLog=%22true%22]/url&wrapper=forever
#check if your build is in buildsXml
After accidently deleting an important build, I found this alternative solution:
# if running inside a job, the following vars are already populated:
#JOB_NAME=yourjobname
#BUILD_NUMBER=123 #your build number
#JENKINS_HOST=192.168.1.11
#JENKINS_PORT=8080
#JENKINS_URL=http://${JENKINS_HOST}:${JENKINS_PORT}
wget --no-check-certificate "${JENKINS_URL}/jnlpJars/jenkins-cli.jar"
java -jar jenkins-cli.jar -s "$JENKINS_URL" keep-build "$JOB_NAME" "$BUILD_NUMBER"
I'm running jenkins and getting this error
hudson.security.AccessDeniedException2: anonymous is missing the Read
permission
I tried many times, deleted cookies and all.
Disabling security is not the solution. It's probably there for a reason. Try "login" instead
java -jar jenkins-cli.jar -s http://yourserver/jenkins/ login --username usr --password qwerty
cheers
Similar issue I faced but with GitHub OAuth plugin,my problem and solution explained here
Errors
hudson.security.AccessDeniedException2: anonymous is missing the Overall/Administer permission at hudson.security.ACL.checkPermission(ACL.java:57)
org.kohsuke.github.HttpException: Server returned HTTP response code: -1, message: 'null' for URL: https://ghe.acme.com/api/v3/user
https://wiki.jenkins-ci.org/display/JENKINS/Disable+security
I am able to run
java -jar jenkins-cli.jar -s http://server get-job myjob > myjob.xml
works for me using abouv url
In addition to the above link, use these simple and clear steps
I think some of the answers in here were partial. This is how I resolved it:
Step Jenkins
/etc/init.d/jenkins stop
sudo vi /var/lib/jenkins/config.xml (Please copy the complete text somewhere first, so that later you don't run in other problems)
2.A. change useSecurity element's value to false
false
2.B. Remove authorizationStrategy block
Start Jenkins again:
/etc/init.d/jenkins start
Access Jenkins through URL and reconfigure security again.
I have the following problem: I have an ANT-task in Jenkins-CI that (apparently) needs access to OSX' window server (it needs to show a window). After doing some research, it appears that only the currently logged in user and the 'root' user (or SUDO) can access OSX' window server.
The ANT task (Adobe ADL) is one that actually 'runs' a build, so it has to popup a screen.
I'm on a macBook running OSX 10.7.something (Lion), Jenkins 1.487, Ant 1.8.4.
What i have tried so far:
to start with, tried the 'barebone' < exec > task to invoke ADL. Works, but getting error that means that Jenkins running as daemon (with homedir /Users/shared/Jenkins/Home) cannot access OSX' Window Server.
Run Jenkins as myself, by changing USER_NAME, GROUP_NAME, JENKINS_HOME in the jenkins launchd.conf file: https://wiki.jenkins-ci.org/display/JENKINS/Thanks+for+using+OSX+Installer
this gives a lot of errors/trouble, which i tried to solve in communication with the creator of the Jenkins CI but, unfortunately to no avail.
Try to have Ant run an < exec > task (running a shell script) in which i try to sudo with a password using this sneaky way of passing a password to the stdinput: echo < password > | sudo -S < command > which is really bad, but as i'm running Jenkins locally (not reachable from the outside of my LAN) it's np.
Tried to have Ant run an < exec > task, using a 'redirector' with as inputstring my password. also superbad, but yea, i just want it to work. which it did not.
Tried a Jenkins SSH plugin: didn't work. I could, however, SSH to my own localhost using terminal, thing is, i don't know what the Jenkins SSH was trying to do (how can i figure that out anyway?) so i don't know why it wouldn't work.
Tried to have Ant run an SSHEXEC task (which, after some hours, finally worked. Ant for mac is borked, something with optional .jar tasks not being re-named correctly or something) but i'm getting a "com.jcraft.jsch.JSchException: Auth fail" which i googled for, and can't seem to resolve. only applicable solution is to have sshd accept password auths, did that, still got the same error.
I think what i want to accomplish was NOT worth the 2 days that i spent so far on this problem, although i learned a lot. However, i just want this to work and will not accept defeat, yet :)
My question: have you had to solve a similar problem, how did you go about it? are there any other methods i can try to solve this problem? Is there a method mentioned that should JUST _WORK_ and i did something wrong?
[edit] I have decided to go with the Jenkins standalone app, as i think (for me) this is a nicer solution in total, as my laptop is not a build server. Also, the Jenkins app can start at startup so it actually acts as a local server.
Just a quick guess: if you don't want the interactivity of the script, and the script can do without it, you can try to set the headless mode on the java command-line:
-Djava.awt.headless=true
I have decided to go with the Jenkins standalone app, as i think (for me) this is a nicer solution anyway, as my laptop is not a (headless) build server. Also, the Jenkins app can start at startup so it acts as a server too.