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.
Related
I feel totally in the dark, and hope you guys can help.
So I have a jenkins server setup connect to p4v and everything running smoothly.
I can trigger the builds on jenkins manually without any problems.
Now however I'd like to setup so Jenkins (using the perforce plugin) acually polls from perforce everytime I submit something new in a specific folder.
This seems fairly straightforward running on linux, just adding a script file in perforce and a perforce trigger to run that file using curl to send a message to jenkins to start the build.
However i'm running windows, and I dont find any information about how to solve this particular problem on windows. Anyone, to help?
The main problem seems to be that all tutorials I find on this uses a .sh script which isnt run in windows, I wonder if there is some other way to do this in windows?
I managed to solve this by using the following Jenkins plugin:
https://wiki.jenkins.io/display/JENKINS/Build+Token+Trigger+Plugin
and curl:
https://curl.haxx.se/
If someone else has the same issue here is the step by step process I went through to set it up on Windows.
In your Jenkins project, enable: Trigger builds remotely (e.g., from scripts)
Enter an Authentication Token, can be anything, ex: buildCode
On the command line as p4 admin enter: p4 triggers
In the trigger, file go to the bottom
Enter the actual p4 trigger: SomeTriggerName change-commit //DepotLocationToTriggerOn/... %//DepotLocationOfScriptToBeTriggered/trigger.bat%
Observe: When the batch file to be run in the trigger is in a depot path it must be surrounded by %
Submit the trigger.bat to p4 in the choosen location. The batch file need to contain the following code C:\curl-7.60.0-win64-mingw\bin\curl.exe -u userID:APIToken JenkinsIP/job/TestJob/build?token=buildCode
Curl must be in that specific folder on the p4v server machine.
The userID and APIToken is found by going to the user drop down and enter Configure, then clicking API Token.
Hope this might help someone else with a similar problem :).
My company is using Jenkins for their CI and so far we've only been using it for our web apps, but now we're getting to the windows service apps we use and I'm looking for some guidance on this.
Currently we have a batch script that shuts down the service then do an Hg update and then turns the service back on.
I need Jenkins to run it as admin so that windows will allow the script to toggle the services.
My question is, how hard is it for Jenkins to run something with elevated privileges?
With PsService you can execute a remote command (start/stop/restart) and provide a username and a password for elevated access.
Once you manage to do this all you need to do is to "write that line" in jenkins. Meaning that if you use pipeline you'll do it with credentials binding. Of course you need to create jenkins credentials with the aforementioned username and password.
I have a jenkins setup with multiple users which are logging in with Active Directory plugin. This is useful so that each user can access his own tasks.
However each user also has different permissions on the local network, such as access to different folders etc. I have noticed that the permissions given to each task is not linked to the user but to the account under which the slave is running as service. Is there a way to change that so that the task is executed on the slave under the credential (and hence permissions) of the user?
Thank you
The problem is: there is only one slave process running the different job assigned to that server by the Jenkins master.
So the slave itself runs as one user (generally, a dedicated account or a system account).
Since you can get the user id as environment variable (with a plugin like JENKINS Build User Vars Plugin), you might consider configuring the job in order for it build step to "run as" the user who triggered the build.
See for instance the JENKINS Authorize Project plugin.
However, as mentioned this answer:
The "Authorize Project" plugin does not change the OS level user that is running commands.
It only sets the Jenkins user that is running the job and any downstream jobs, using Jenkins authentication (whatever it might be).
So you are left with build step with runas or su -c commands in order to be sure that your task does run with the right user.
I had the similar issue and I can recall for managing more control on projects I used role strategy plugin and setup global security using LDAP servers (Active directory should also be ok).
And I used authorized project plugin.
Have a look and I hope it should solve your purpose. Let me know on comment section for any clarification.
you can partially fix your problem this way:
install the slave as a service using the Java Web Start method and JLNP
go to Services control panel in windows
under Properties -> Connection replace the local system connection with a specific user
rebooted the service
This at least gives you the ability to use one account instead of system.
I'm working with Jenkins servers in three different environments:Development-Staging-Production.
We work out the kinks in our Jenkins jobs in dev, test them in stage, and then finally move them to production. We do that be either replicating the job in the GUI (cut and paste) or tarring up the job directory and moving it to the next environment via the command line.
I'm wondering if the move option can be done with the service accounts that run these jobs. I can see the user account directories and config files under /var/lib/jenkins/users. What I don't see are the security settings that get applied to the user from the "Configure Global Security" screen in the GUI.
For these service accounts, we have the minimal authorization of READ on Global and READ and BUILD on Jobs.
What I'd like to be able to do is prove a service account in dev and then promote it to Stage and Prod from the command line vs having to manually recreate the account in the GUI for each upstream environment. If the API key could also be moved along with it that would be great.
Any thoughts or ideas?
User permissions are in config.xml under the Jenkins root folder, in section <authorizationStrategy>
This file contains other global settings, so just copying it would not be advisable
Just a wild thought, but why not use a master-slave config and trigger builds on the desired remote machine based on some "environment" parameter. You can also look through the plugins section to see if you can find something useful such as the:
node label parameter which allows to define and select the label for the node where you want the build to run
copy to slave that facilitates copying files to and from a slave
That way you'll only have one job configuration which can be executed on different environments without too much hustle.
I need to execute few of the Jenkins jobs such as "Release to Production" through Jenkins UI using logged on user credential. The reason is, we have separate Support Team Members, who have access to the production boxes and not the Dev team members. So, in order to deploy any code base to production, all the Windows Deploy Commands (ex, create, update files, folder etc.) needs to be run with specific user credential who has access to the Production Box. So that even the Dev team members who don't have access to the Production box but are Jenkins Admin, execute the same job should result in failure due to "Access Denied". The job should succeed only if its been run by Support Team members with their credential.
I tried using parameterized plugin but couldn't able to pass the Password successfully to the batch file which contains MSDeploy instructions. Even the Jenkins console log displays the parameter passed in its console output, which is a security issue.
I checked Role based security plugin, but that doesn't help me much. I just need a plugin which should ask for user to provide their credential before start building the Job and should use the user credential to get the job executed, so that my MSDeploy command will be able to deploy the code on Production boxes, when the Support team member build that Job using their credential. I wish there was support for impersonation.
Right now all the Jenkins Jobs are getting executed using the service account which the Tomcat service is configured to run with on which Jenkins is hosted.
Any help would be appreciated.
Just in case there is any confusion a Jenkins job will always run as the same OS user. The Matrix based security applies to users who log into the Jenkins server and controls features like creating or launching jobs.
You could configure the job to use a set of generic production credentials and then prevent your developers from invoking the job.
Perhaps a better approach would be to separate the process that builds the code from the one that deploys the code. The following diagram (Taken from the xebia-france project) demonstrates how some of my favourite tools Rundeck and Nexus can be integrated with Jenkins.
Finally, I highly recommend reading the following link:
Using Rundeck and Chef to build devops tool chains
Hi I know I'm coming late on this thread, but I just fell on this issue and had a hard time solving it, so I thought I might just share what I managed to set-up.
First things first: if you want to run a Jenkins job "as a specific user" (with all the correct habilitations) the easiest way is to run a Jenkins SLAVE as this user.
Then you might very well stumble into the following: you probably want to run serveral slaves on the same windows machine as windows services. This is very fine, as long as each slave has his own Remote root directory and probably have a specific "label" too.
Once you managed to run your slave as a windows service, launch the service console (run services.msc). Edit the newly created service properties, go to Log On tab. Select "Log on as: This account" and enter your account credentials.
Cheers :)
You can utilize the built in windows runas or Powershell InvokeCommand cmdlet and -Credential to run - Both these would store the username/password in plain text - So do think about the risks, but this gives you flexibility.
I'm surprised this doesn't have a better answer of set an agent on another machine to run as another service and define agent as a special "type" which picks up the jobs - Something along those lines is what I would expect but I haven't seen an implementation like that in Jenkins (I'm new to Jenkins so was looking for an answer and found this thread).
Something else that could be considered for someone more familiar with Jenkins is when you set the custom path to MSBuild could you set that to runas /user:... msbuild.exe perhaps? I don't have an extra Jenkins server currently to try that on.