I am trying to setup a Jenkins/Hudson CI in a distributed environment. I am curious about the following questions:
1) does the slave account need to be a root/administrator account? If lower privilege can run whats the minimum access?
2) On a slave node, does one projects jobs have access to another project files that previously built on the same node? How would you prevent this?
3) How do you secure someone from not being able to format your disk with a bat file running in a pre or post build script?
1) The slave account does not have to be root or administrator. It only needs full access to the folder you give in the "Remote FS root" field of the slave configuration.
2) Yes it does. Each project folder is owned by the user that is used to run the slave. You can access other project folders using relative paths: $WORKSPACE/../OTHER_PROJECT/. I'm not sure if there is a default way to prevent this. However, you have two options:
Delete the workspace after your build (use plugin Workspace Cleanup Plugin)
Create a separate slave/user combination for each project - the slave can be the same, but you'd have to create a separate user for each project.
3) Formatting a disk completely would require privileged access. You should not give your slave user those rights. I'm not sure whether your slave is Unix or Windows based, but either way, you should be able to prevent your user from being allowed to do any such task. Like stated in A1, the slave user only needs enough access to be able to read/write/execute in its "Remote FS root" folder.
Just out of curiosity - what OS are you running on your slave?
Related
I am implementing Jenkins into already established Perforce workflow.
Each of the workspaces we have in Perforce(and there is a lot of them) is using the Drive letter( for example D:\ ) as the root directory for the workspace.
I am using p4Plugin in Jenkins to sync the code before running the actual scripts. And Jenkins has it's own workspace which is being used every time I start to sync the code.
I tried using the Spec file, for workspace behavior in P4 Plugin, where I would specify the root to be D:\ but whenever it loads it will still create jenkins workspace root.
I also tried using the Static workspace behavior, and that will work, but the problem is that in order for that workflow to work, the person needs to create a workspace manually on the worker of jenkins setup, and then create the job, which is then defeating the purpose of using jenkins at first. Plus we need a workspace per job.
Which made me think, if I use an already existing workspace with D:\ being the root, and use a Temp workspace behavior in jenkins, that it will copy the root settings as well as other ones. But unfortunatelly it also sets the sync to be to the jenkins workspace.
In short, all I want is to be able to use the D:\ drive to sync all the code instead of putting them into the jenkins root directory and syncing the code to the project folders inside.(ex C:\JenkinsData\syncProject...)
That's the design of the p4 plugin. It puts the workspace where jenkins asks us to.
See property jenkins.model.Jenkins.workspacesDir here: https://wiki.jenkins.io/display/JENKINS/Features+controlled+by+system+properties
I don't think the default in that wiki is correct.
On all your master and slaves, you can try to change that to just D:\
That assumes your client view definitions (right hand side) will not overlap.
Otherwise:
A "form-in client" trigger script can alter the root. The script should only change jenkins relevant clients, so you'll need to pass something to the script in the trigger definition to signify that it is for a jenkins job. Examples could be a client naming convention and/or the clientip.
Your Perforce Admin, if that's not you, will have to assist.
Is there a way i can change the user the jenkins run without losing existing jenkins data/cofig. I tried changing the user in services.msc, however it crashed jenkins and was not able to load jenkins after changing user.
ps. Actually there are couple of jobs in which clone(git, tfs) happening with some user, however when it comes to running scripts/commands i get permission and attribute(readonly) issues as Jenkins is not running with same account that was used to clone repositories
Maybe your new user has not privileges on Jenkins home folder (C:\Program Files (x86)\Jenkins in my case). Just check rights on this folder.
I'm just getting started with Jenkins and I have a few doubts that must be silly, but I'm stuck at it.
After I build my project Jenkins save the build file in some specific path?
Using Ranorex for automation test, is it better to put my files locally on the server or push them to a repository?
Note: I just start tried to use this, at this moment I can check for changes at BitBucket, build the file, build the Ranorex test and run the test.
Jenkins is quite a versatile application that allows system setup to specific needs and requirements of the test project. So i'd say go with the way that seems most logical/easiest. It's kind of a learning process as well so you will be able to understand the working flow of Jenkins itself.
But to answer your 2 questions:
1) By build files i believe you mean the test reports? - For this I actually use the Jenkins UserContent folder. This requires the "Copy to slave" plugin to be installed. With this you will get an additional Post-build Action where you can specify the files that will be copied over to the UserContent folder. But don't forget to specify a common layout for the naming of report files through the Ranorex run parameters ("/rf"). The UserContent folder actually acts as a web server and you can directly link the URLs for email reports. (eg. "http://Jenkins-server.com/UserContent/Regression-Client-Test-#1.html")
2) This totally depends on the system setup. But i can give you an example on how our system is currently set up. So we have Jenkins which runs on a Linux machine. It is only used to manage and run the tests and the actual machine does not include the automation test project. Then we have the test machine which runs on Windows and holds the actual automation tests. This machine is connected to Jenkins through the Slave functionality. So basically when someone starts a test job Jenkins from the Linux machine sends a command to the slave to start the automated tests. When the test run has finished post-build actions take over and copy the report files from the Slave machine to the Linux machines UserContent folder.
Now when talking about the test project management. It's a good idea to use a gir repository which will add another layer of somewhat "security". But if you have a small team (or you are the only test developer) then there is no actual need for it. You just copy the project to the test machine to a specified folder whenever needed/updated and you are ready to run it.
Regards,
Martin
I have a Jenkins installation which runs as a Windows Service under a specific user. Now, we want to be able to access the UI for system tests, which is not allowed with this user.
My idea was to start Jenkins from the command line (using Jenkins.war) such that it is run with allowance of desktop interaction, while still using the specific user.
However, when I run this I get an 'empty' Jenkins, so nothing is configured (no settings, no jobs). Do I have to do something special to run Jenkins from the command line retaining the settings and jobs once it has been installed as a service?
Jenkins stores its configuration in a directory (called JENKINS_HOME), whose location is generally based on the user under which Jenkins is running.
You can see where this is via: Manage Jenkins > Configure System > Home directory (at the top of the page).
To run Jenkins as another user, you need to copy the JENKINS_HOME contents to the "Home directory" value you see when running that user (probably something like c:\users\username\.jenkins).
Or you can set the JENKINS_HOME environment variable to point to the system installation directory (if you installed from the MSI, this is likely within c:\Program Files (x86)\jenkins). Then Jenkins will start up, reading the existing settings and jobs. Though in this case, you need to make sure that your user has the same access rights as the system service had.
I am setting up develop environment for java project.
And my team decide to use Jenkins for CI, and AWS EC2(linux) for server.
I succeeded to make an war file by jenkins job.
But, I can't find a way how to copy war file to EC2, and restart tomcat server on EC2.
I googled about it using "jenkins ec2 deploy", but in fail.
somebody help me!
Step 1. Install Jenkins plugin
Open your favorite browser and navigate to Jenkins. Log in and select “Manage Jenkins” followed by “Manage Plugins”. Select the “Available” tab, locate the “Deploy to container” plugin and install it.
Step 2. Edit tomcat-users.xml
In order for Tomcat to accept remote deployments, you have to add a user with the role manager-script. To do so, edit the file ../conf/tomcat-users.xml and add the following line:
<user username="deployer" password="deployer" roles="manager-script" />
Step 3. Edit the Jenkins job
Back in Jenkins, go to your job and select “Configure”. Next, scroll down to the bottom of the page to the “Post-build Actions”. Select the option “Deploy war/ear to a container” from the “Add post-build action” dropdown button. Fill in the new fields.
Step 4. Run the Job project and verify the end results
Schedule a build for your job in Jenkins. If you check out the log file you should see one or more lines near the end indicating that the war file has been deployed.
If you check the logfiles in Tomcat (catalina.out) you should also see that your application has been succesfully deployed.
Lastly, if you point your browser to the URL and context path you’ve specified in the job configuration in Jenkins (e.g., http://your-server:8080/mywebapp), you should be able to open your freshly deployed application.
Credits to Jdev.it
More info can be found here
With EC2 (or any other deployment practice too), first determine your production servers are going to be mutable or immutable.
[Mutable]
The servers will be running forever, and you perform on-going updates as explained in the blogpost mentioned above (elizabetht) for Java war, or many other ways for different languages/platform.
[Immutable]
The servers are re-created (vs. upgraded) by automation mechanism such as scripting, or using config. mgmt tools like Puppet/Chef/Ansible or vendor specific initialization mechanism like AWS Userdata/Docker dockerfile/Vagrant vagrantfile, or using many other provisioning tools.
Generally speaking databases or queues should be Mutable category, and all other compute nodes are better be Immutable category. The benefits of Immutable category are a lot including easy HA, disaster recovery and also enables Blue/Green deployment and much more.