Jenkins runs as root instead of Jenkins - jenkins

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.

Related

How to attach build log files to Jenkins?

I'm building Jenkins pipeline and after pipeline fails with server installation some logs are generated on machine where server is being installed.
I want to attach those logs to Jenkins build so person can see that file from Jenkins build only instead of going to machine and find it out.
I saw a plugin Copy To Slave Plugin but for installation when I searched for it in Jenkins, it's not listed.
Could you please suggest which plugin will help me to attach log files to Jenkins build?
Due to the complex nature of filesystems, Jenkins is not capable to copy logs from extraneous locations like those outside of the Jenkins root directory. This is for security reasons, which is why the Copy to Slave Plugin you referred to earlier has been discontinued.
In short, Jenkins spawns processes that spawn other processes that are owned by different users in the filesystem (e.g. root). For this reason, it is highly probable that the log files you are referring to are located elsewhere on the file system (i.e. not in $JENKINS_HOME), and thus are not owned by the jenkins user.
It is possible to use cat or tail on the log files in the Jenkins build itself. In combination with a plugin like Log Parser, this can provide some nice output in another screen.
I would be interested about what do you mean by “install”? Can the install happen during the building of a Docker image? Or in a pre-built Docker container? If this is the case, you can copy the “installed” files to the destination.
This would help you, because any log files created during the “install” can be copied out from the docker container and attached to the Jenkins build as an archived artifact.
For this, you don’t even need a plug-in.

How do I move Jenkins from one server to another?

I need to move Jenkins version 2.32 from Server A to Jenkins 2.72.1 Server B.
Both server have ubuntu 16.04.3
I could not install any plugin and take back up in Server A due to memory issues. Is there any way that I could achieve this?
Copy all the files in your JENKINS_HOME directory over to the new server.
Point JENKINS_HOME on the new server at the new directory.
Copy the Jenkins war file (or your servlet container setup if you have one) over to the new machine and start it up.
All Jenkins settings, jobs, plugins, config, etc. live in JENKINS_HOME. You just need a copy of it to start it elsewhere.
Following JENKINS/Administering+Jenkins, you still need to make a backup of JENKINS_HOME.
See also How to Migrate a Jenkins Job to New Jenkins Server
If you want to exclude the plugins for space issue, you can list them in a text file, and reload them with a groovy script.

Jenkins service won't start after backup

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.

Jenkins Service vs Jenkins Jar File Permission

I have Jenkins 1.6 installed as a service on a CentOS machine.
At some point in the past the service stopped/crashed/? and Jenkins was restarted from the command line, java -jar jenkins.war, as the root user.
While it was running as root some plugins were updates/installed, and jobs created created/ran. Any new files created are now owned by the root user/group and not by the jenkins user/group.
Meaning, when the service was restarted Jenkins could not read these files. Resulting in plugins not running and most jobs not being loaded.
Manually restoring the permissions(chown, chgrp) to the plugins solves the plugin related issues.
For the jobs it's easy to spot new ones and fix them. Any existing ones that were re run and created new files are more difficult to find.
Then there may be other files which the Jenkins server created, not as part of a job or plugin which need to be changed. The errors are not always obvious, and crop up slowly over time.
Am I better adding the jenkins user to the root group? could this cause issues?
Or manually changing the permissions, hope i got them all! And fix others that come up?
Any suggestions appreciated.
In the end we manually changed the file permissions back to Jenkins. There were some immediate jobs that failed in the following days. And a few which only came up a few months later.
For the most part it worked well.

Change Jenkins from running as windows service to CLI, while remaining the jobs

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.

Resources