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.
Related
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.
My organization needs to make backups of our heavily customized Jenkins instance. After doing some research on different methods for backing up Jenkins, we decided to go the route of copying the whole Jenkins directory using xcopy and then moving the backup to a new instance on a different machine. (The reason for using xcopy is that its the only way to preserve they symbolic link files within each job.)
Here's the steps I have taken:
A batch file uses xcopy to copy the entire D:\Jenkins directory on a nightly basis from the old machine
I install a fresh instance of Jenkins on a new server
I stop the Jenkins service from running
I delete the current Jenkins directory in the new machine and then xcopy the backup in its place
I attempt to start the Jenkins service and I am met with the following error:
The Jenkins service on Local Computer started and then stopped. Some
services stop automatically if they are not in use by other services
or programs.
I have tried running jenkins.war from the command line and that just causes a Jenkins instance to start up that doesn't register as a windows service, and I cannot login to (even after disabling useSecurity), and looks like it doesn't have our modifications present.
I have also tried clearing the application log and that did not help.
I am not sure how to get the Jenkins service up and running.
The one folder you need to backup is the one referenced by the environment variable JENKINS_HOME
It is best to keep that folder separate from the installation folder like C:\Program Files (x86)\jenkins.
Then I prefer using a tomcat instance, and copy the jenkins.war in it: it is easier to upgrade:
Simply overwrite your jenkins.war with the new version. Tomcat should automatically redeploy the application.
What are the scenarios when jenkins must be restarted. Right now, I am setting up jenkins. And, I am facing lots of issues like permission denied, no such file or directory etc. So, once I install new command used by my build process, do I need to restart jenkins? If I change any environment variable, change ownership of the file, do I need to restart jenkins?
If you're getting permissions errors, I would ensure that the user running Jenkins has read/write access to the directory/file that you're trying to modify. Make sure that this user also owns the JENKINS_HOME directory.
Typically, Jenkins shouldn't need to be restarted in any of the situations that you stated.
If you post more details about what you're trying to do, I'm sure people here can help.
I have a newly installed jenkins server running on my computer, and am having some issues related to permissions.
It seems that jenkins creates the workspace directory as the root user, and then of course all task (including even pulling from the repository) fail, because they do not have permissions to modify the directory
Have a look at the Started-By Environment Variable plugin:
https://wiki.jenkins-ci.org/display/JENKINS/Started-By+Environment+Variable+Plugin
If you are just asking how to set up Jenkins to run under a different user in Linux it depends on how you installed it. Have a look at https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins for different setup options. I had a look at Installing Jenkins as a Unix daemon and at step 7 you need to setup a configuration file. Change the last line in that file (RUN_AS_USER=jenkins) to contain the user of your choice.
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?