Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-11024

Some commands don't work when using _jenkins-cli.jar with -i switch, get-job and update-job for sure, not certain about others

    XMLWordPrintable

Details

    • Bug
    • Status: Resolved (View Workflow)
    • Major
    • Resolution: Cannot Reproduce
    • cli
    • None
    • CLI

    Description

      Add keys for authenticated login. Works fine with who-am-i, enable-job, disable-job, delete-job, create-job, but get-job and update-job fail claiming there is no job by that name. The very same command line with enable-job (as well as the others) works fine.

      Workaround is to see if enable-job fails (which it will if there is no job by that name, which was the point of using get-job), then delete-job and create-job instead of update-job if the job already exists. Note that this workaround causes the loss of job history upon deletion.

      Diagnostics:

      % java -jar jenkins/_jenkins-cli.jar -s http://localhost:9090/ -i jenkins/id_rsa get-job trunk-pacman.integration.vdev-regression
      No such job 'trunk-pacman.integration.vdev-regression'
      java -jar jenkins-cli.jar get-job args...
      Dumps the job definition XML to stdout
      JOB : Name of the job
      --username VAL : User name to authenticate yourself to Jenkins
      --password VAL : Password for authentication. Note that passing a
      password in arguments is insecure.
      --password-file VAL : File that contains the password

      % java -jar jenkins/_jenkins-cli.jar -s http://localhost:9090/ -i jenkins/id_rsa enable-job trunk-pacman.integration.vdev-regression
      % echo $?
      0

      Attachments

        Activity

          I accenditaly reproduce this issue at work.

          When using -i for ssh credential, build and some other command doesn't work for job who are not readable by annonymous. (enable-job work)

          The workaround is to activate "security based project" and to activate read access to anonymous user.

          It must be a visibility issue. CLI see only anonymous job, not jobs seen by account used with -i parameter. On other way, the build start when anonymous have not build rights. So it's only visibility issue.

          hicwic Steve Eckerlein added a comment - I accenditaly reproduce this issue at work. When using -i for ssh credential, build and some other command doesn't work for job who are not readable by annonymous. (enable-job work) The workaround is to activate "security based project" and to activate read access to anonymous user. It must be a visibility issue. CLI see only anonymous job, not jobs seen by account used with -i parameter. On other way, the build start when anonymous have not build rights. So it's only visibility issue.
          sdaigle S Daigle added a comment -

          Is this issue ever going to be resolved? In companies like mine where adding anonymous read access is not an option, and relying on many of the CLI commands, an issue like this limits the things we can do with Jenkins jobs outside the UI. If anyone has a workaround to this, that would be welcome.

          sdaigle S Daigle added a comment - Is this issue ever going to be resolved? In companies like mine where adding anonymous read access is not an option, and relying on many of the CLI commands, an issue like this limits the things we can do with Jenkins jobs outside the UI. If anyone has a workaround to this, that would be welcome.
          gouzi gouzi added a comment -

          The 'build' command does not work either, as the job name cannot be retrieved:
          $ java -jar jenkins-cli.jar -s http://localhost:8090 -i ~/.ssh/id_rsa build Project1

          No such job 'Project1'
          java -jar jenkins-cli.jar build args...
          Starts a build, and optionally waits for a completion.
          (...)

          And Project1 does exist!

          gouzi gouzi added a comment - The 'build' command does not work either, as the job name cannot be retrieved: $ java -jar jenkins-cli.jar -s http://localhost:8090 -i ~/.ssh/id_rsa build Project1 – No such job 'Project1' java -jar jenkins-cli.jar build args... Starts a build, and optionally waits for a completion. (...) – And Project1 does exist!

          The build command work, but you have to give anonymous read access to your Project1. Then CLI command will see it.
          Must be a visibility issue...

          hicwic Steve Eckerlein added a comment - The build command work, but you have to give anonymous read access to your Project1. Then CLI command will see it. Must be a visibility issue...
          kieranshaw Kieran Shaw added a comment -

          Agreed that this is an important issue, I don't want to give anonymous read access just to be able to use the CLI.

          kieranshaw Kieran Shaw added a comment - Agreed that this is an important issue, I don't want to give anonymous read access just to be able to use the CLI.

          Same issue here.

          barrett Barrett Strausser added a comment - Same issue here.

          Same here. Anonymous access is not acceptable. Looking for workaround.

          gargii Jan Gargulák added a comment - Same here. Anonymous access is not acceptable. Looking for workaround.
          netropic Max Burdge added a comment -

          I would also like a solution or workaround for this issue.

          netropic Max Burdge added a comment - I would also like a solution or workaround for this issue.
          drnic drnic added a comment - - edited

          Having the same issue with --username & --password authentication.

          drnic drnic added a comment - - edited Having the same issue with --username & --password authentication.
          drnic drnic added a comment -

          Sad panda for the 1.5 year old ticket

          drnic drnic added a comment - Sad panda for the 1.5 year old ticket
          drnic drnic added a comment -

          Confirming the workaround - I toggled the Job > Read checkbox for the anonymous user and I can now run builds via the CLI and anonymous users can not see anything when they visit the jenkins URL.

          drnic drnic added a comment - Confirming the workaround - I toggled the Job > Read checkbox for the anonymous user and I can now run builds via the CLI and anonymous users can not see anything when they visit the jenkins URL.
          drnic drnic added a comment -

          I wrote up the use of the CLI and how to setup this workaround http://starkandwayne.com/articles/2013/04/12/jenkins-builds-from-cli/

          drnic drnic added a comment - I wrote up the use of the CLI and how to setup this workaround http://starkandwayne.com/articles/2013/04/12/jenkins-builds-from-cli/
          hvamsik Vamsi Hari added a comment -

          wow, thanks a lot dr nic, it solved issues with jenkins-cli in our case,

          hvamsik Vamsi Hari added a comment - wow, thanks a lot dr nic, it solved issues with jenkins-cli in our case,
          jglick Jesse Glick added a comment -

          JENKINS-12543 covers the problems with username/password authentication. I could not reproduce any problems in current trunk with SSH authentication.

          jglick Jesse Glick added a comment - JENKINS-12543 covers the problems with username/password authentication. I could not reproduce any problems in current trunk with SSH authentication.
          swf Yves Schumann added a comment - - edited

          Im Using Jenkins-CLI to setup jobs based on an deactivated job template and modify the activation state of the created jobs in a second step. It seems that I run into this issue as the creation of new jobs works as expected but the activation fails:

          Calling jenkins api to create job 'eisfair__bcstorage' hudson.security.AccessDeniedException2: anonymous fehlt das Recht 'Job/Configure' 
           	at hudson.security.ACL.checkPermission(ACL.java:54)
           	at hudson.model.AbstractItem.checkPermission(AbstractItem.java:446)
           	...
          

          Why is there "anonymous" used? Username and password is the same as for job creation some milliseconds before!?

          Sad story as there are more than 500 jobs handled this way and it is absolutely annoying to do this by hand...

          swf Yves Schumann added a comment - - edited Im Using Jenkins-CLI to setup jobs based on an deactivated job template and modify the activation state of the created jobs in a second step. It seems that I run into this issue as the creation of new jobs works as expected but the activation fails: Calling jenkins api to create job 'eisfair__bcstorage' hudson.security.AccessDeniedException2: anonymous fehlt das Recht 'Job/Configure' at hudson.security.ACL.checkPermission(ACL.java:54) at hudson.model.AbstractItem.checkPermission(AbstractItem.java:446) ... Why is there "anonymous" used? Username and password is the same as for job creation some milliseconds before!? Sad story as there are more than 500 jobs handled this way and it is absolutely annoying to do this by hand...
          danielbeck Daniel Beck added a comment -

          Cannot reproduce on 1.584. java -jar jenkins-cli.jar -i ~/.ssh/id_rsa -s http://myjenkins get-job foo returns the job's config.xml. Anonymous has no permissions on that instance.

          Anyone still experiencing this on recent Jenkins versions?

          danielbeck Daniel Beck added a comment - Cannot reproduce on 1.584. java -jar jenkins-cli.jar -i ~/.ssh/id_rsa -s http://myjenkins get-job foo returns the job's config.xml. Anonymous has no permissions on that instance. Anyone still experiencing this on recent Jenkins versions?
          danielbeck Daniel Beck added a comment -

          No response to comment asking for updated information in over three months, so resolving as cannot Reproduce.

          danielbeck Daniel Beck added a comment - No response to comment asking for updated information in over three months, so resolving as cannot Reproduce.
          jswager1 Jason Swager added a comment -

          I'm experiencing this problem. Using CloudBees folders and roles/groups with absolutely no permissions for non-authenticated users.

          I can list-job through the folders and see the job. But trying to build it via the cli results in "ERROR: No such job"

          jswager1 Jason Swager added a comment - I'm experiencing this problem. Using CloudBees folders and roles/groups with absolutely no permissions for non-authenticated users. I can list-job through the folders and see the job. But trying to build it via the cli results in "ERROR: No such job"
          jswager1 Jason Swager added a comment -

          It's reproducible!

          jswager1 Jason Swager added a comment - It's reproducible!
          danielbeck Daniel Beck added a comment -

          jswager1 Then please provide enough information so it can be reproduced by someone else, from scratch. I.e. no "I have this Jenkins instance I've worked on for years and it does not work with that".

          danielbeck Daniel Beck added a comment - jswager1 Then please provide enough information so it can be reproduced by someone else, from scratch. I.e. no "I have this Jenkins instance I've worked on for years and it does not work with that".
          jswager1 Jason Swager added a comment - - edited

          Apologies, danielbeck, let me add the bare minimum reproduce steps.

          1. I installed a fresh Jenkins via it's docker container. The version it had was 1.642.2.
          2. Once running and connected, added the Folder Plugin and the Role-based Authorization Strategy (in my production scenario, we're using CloudBees Roles and Groups - but this one will suffice)
          3. Enable security via Manage Jenkins -> Global Security: Jenkins own database, allow users to sign-up, Role-Based Strategy.
          4. Create yourself as a user and sign in as yourself
          5. Under Manage Jenkins -> Manage and Assign Roles: Under Manage Roles, make sure "admin" role has access to everything. Under Assign Roles, remove "Anonymous" group from "admin", add yourself and give access to "admin" role.
          6. Back at Jenkins main page, create a Folder (via New Item -> Folder) called "alpha"
          7. In Folder "alpha" create a simple Freestyle Job called "test-job", make it do something - whatever. No parameters is easiest.

          Now for the command line work (command may be slightly incorrect; typing from memory here) - replace JENKINS_URL and userid as appropriate:

          1. At the command line, get the jenkins-cli: curl -o jenkins-cli JENKINS_URL/jnlpJars/jenkins-cli.jar
          2. Make it easy - login as you: java -jar jenkins-cli.jar -s JENKINS_URL login --username userid
          3. Verify you can see the alpha folder: java -jar jenkins-cli.jar -s JENKINS_URL list-jobs
          4. Verify you can see the test-job job: java -jar jenkins-cli.jar -s JENKINS_URL list-jobs alpha
          5. Try to run test-job: java -jar jenkins-cli.jar -s JENKINS_URL build alpha/test-job
          6. I get the following when I try:

          $ java -jar jenkins-cli.jar -s http://192.168.99.100:8080 build "alpha/test-job"
          No such job 'alpha/test-job'

          jswager1 Jason Swager added a comment - - edited Apologies, danielbeck , let me add the bare minimum reproduce steps. I installed a fresh Jenkins via it's docker container. The version it had was 1.642.2. Once running and connected, added the Folder Plugin and the Role-based Authorization Strategy (in my production scenario, we're using CloudBees Roles and Groups - but this one will suffice) Enable security via Manage Jenkins -> Global Security: Jenkins own database, allow users to sign-up, Role-Based Strategy. Create yourself as a user and sign in as yourself Under Manage Jenkins -> Manage and Assign Roles: Under Manage Roles, make sure "admin" role has access to everything. Under Assign Roles, remove "Anonymous" group from "admin", add yourself and give access to "admin" role. Back at Jenkins main page, create a Folder (via New Item -> Folder) called "alpha" In Folder "alpha" create a simple Freestyle Job called "test-job", make it do something - whatever. No parameters is easiest. Now for the command line work (command may be slightly incorrect; typing from memory here) - replace JENKINS_URL and userid as appropriate: At the command line, get the jenkins-cli: curl -o jenkins-cli JENKINS_URL/jnlpJars/jenkins-cli.jar Make it easy - login as you: java -jar jenkins-cli.jar -s JENKINS_URL login --username userid Verify you can see the alpha folder: java -jar jenkins-cli.jar -s JENKINS_URL list-jobs Verify you can see the test-job job: java -jar jenkins-cli.jar -s JENKINS_URL list-jobs alpha Try to run test-job: java -jar jenkins-cli.jar -s JENKINS_URL build alpha/test-job I get the following when I try: $ java -jar jenkins-cli.jar -s http://192.168.99.100:8080 build "alpha/test-job" No such job 'alpha/test-job'
          danielbeck Daniel Beck added a comment -

          jswager1 I don't see any use of the -i switch to use a non-default SSH key in your comment anywhere. How is that related to this issue? Looks like you're just experiencing JENKINS-12543.

          danielbeck Daniel Beck added a comment - jswager1 I don't see any use of the -i switch to use a non-default SSH key in your comment anywhere. How is that related to this issue? Looks like you're just experiencing JENKINS-12543 .
          jswager1 Jason Swager added a comment -

          Sorry - this is my mistake. This doens't involve the ssh keys, just a normal username/password login. Please close this issue and I'll open a different one.

          jswager1 Jason Swager added a comment - Sorry - this is my mistake. This doens't involve the ssh keys, just a normal username/password login. Please close this issue and I'll open a different one.
          danielbeck Daniel Beck added a comment -

          jswager1 I still maintain you're just seeing JENKINS-12543.

          danielbeck Daniel Beck added a comment - jswager1 I still maintain you're just seeing JENKINS-12543 .

          People

            Unassigned Unassigned
            tmeazell Timothy Meazell
            Votes:
            13 Vote for this issue
            Watchers:
            19 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved: