I've got a jenkins CI installed from a debian package (1.424.6 version, Debian/Ubuntu distribution, running on ubuntu 12.04). I read on the web that jenkins provides an automatic upgrade button, just like in . But I don't have such thing on my jenkins. I tried to find answers on google and in jenkins config, but failed. Maybe it's impossible for debian/ubuntu installed package?
It's a permissions problem, If you trust in your Jenkins security configuration just run:
$ chown -R jenkins /usr/share/jenkins
Then restart jenkins and the upgrade button should be shown, and you can upgrade to last version, otherwise you have to use debian package system whose Jenkins version is not the latest.
as it states in the https://wiki.jenkins-ci.org/display/JENKINS/Automated+Upgrade "Using the Upgrade-Button from within Jenkins (available since 1.318) will not work if Jenkins was installed from a Debian package (results in permission denied errors when trying to download the new WAR file)!"
so even if you find the button it will fail.
but it also says that
aptitude update && aptitude install jenkins
will update the jenkins to the newest version, give it a try :)
Change the ownership (to jenkins UID and GID) of the directory where the jenkins.war resides and the WAR file itself. For example, the following works for RHEL:
chown jenkins:jenkins /usr/lib/jenkins
chown jenkins:jenkins /usr/lib/jenkins/jenkins.war
https://wiki.jenkins-ci.org/display/JENKINS/Automated+Upgrade
If you've installed via the OS X installer, the 'jenkins' running the
process does not own the .war file. To get auto-upgrade working, just
fix the permissions so the jenkins user can write the WAR (in
/Applications/Jenkins).
run the command to find the location of jenkins.war
ps -aux | grep jenkins
output like this:
jenkins 27765 172 11.0 3528188 432288 ? Ssl 12:23 4:16 /etc/alternatives/java -Djava.awt.headless=true -DJENKINS_HOME=/var/lib/jenkins -jar /usr/lib/jenkins/jenkins.war --logfile=/var/log/jenkins/jenkins.log --webroot=/var/cache/jenkins/war --httpPort=8080 --ajp13Port=8009 --debug=5 --handlerCountMax=100 --handlerCountMaxIdle=20
location of jenkins.war is:
/usr/lib/jenkins/jenkins.war
run command to fix /usr/lib/jenkins/jenkins.war permissions. for example:
chmod 777 /usr/lib/jenkins/jenkins.war
then refresh manage page. and you will see the button.
In my case, I had installed jenkins with snap. I brought everything down with docker-compose. Then I copied the downloaded jenkins.war to the snap directory. Next, brought things up with docker-compose, then latest version appeared in the jenkins ui.
Related
After the latest updates to gcloud and docker I'm unable to access images on my google container repository. Locally when I run: gcloud auth configure-docker as per the instructions after updating gcloud, I get the following message:
WARNING: `docker-credential-gcloud` not in system PATH.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.
gcloud credential helpers already registered correctly.
Running which docker-credential-gcloud returns docker-credential-gcloud not found.
I have no other gcloud-related path issues and for the life of me can't figure out how to install/add docker-credential-gcloud to path. Here's what I have installed (shown via gcloud version):
Google Cloud SDK 197.0.0
beta 2017.09.15
bq 2.0.31
container-builder-local
core 2018.04.06
docker-credential-gcr
gsutil 4.30
I also have Docker CE Version 18.03.0-ce-mac60 (23751).
Here's my $PATH:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin
I also ran source /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/path.zsh.inc on original gcloud install.
Notice: All docker-credential-gcr below can be replaced with docker-credential-gcloud. I think it is just different versions of gcloud, I might be wrong.
I used Homebrew Cask to install gcloud too. I installed docker-credential-gcr with
$ gcloud components install docker-credential-gcr
And then like you said, which docker-credential-gcr doesn't gave you anything.
So I ran which gcloud to find there is a symlink to gcloud in /usr/local/bin. This symlink is created by Homebrew when you installed gcloud at first place. Now docker-credential-gcr wasn't installed by Homebrew but by gcloud itself, so there isn't a symlink.
I called readlink /usr/local/bin/gcloud and found out gcloud is installed in /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/.
Then:
$ ls /usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin
There you should see docker-credential-gcr listed there.
I simply linked it to /usr/local/bin:
$ ln -s \
/usr/local/Caskroom/google-cloud-sdk/latest/google-cloud-sdk/bin/docker-credential-gcr \
/usr/local/bin/
Then run:
$ docker-credential-gcr configure-docker
It should succeed.
Just had the same issue on Windows, running Docker with Linux containers, Docker engine v19.03.8. Using docker compose. I do not use gcloud for my dockerfiles...
DT1001 dockerpycreds.errors.InitializationError:
docker-credential-gcloud not installed or not available in PATH
Option 1: Edit the docker configuration file and remove all gcloud entries from there.
Windows c:/Users/<your account>/.docker/config.json
Linux & MacOS ~/.docker/config.json
Option 2: Go to Troubleshoot -> Reset to factory defaults.
After this my docker compose was creating containers and running the images without any issues.
On MacOS
Step 1：
Install gcloud and docker-credential-gcr,
following this tutorial
Step 2:
$ ln -s /usr/local/google-cloud-sdk/bin/docker-credential-gcr /usr/local/bin/docker-credential-gcloud
Step 3:
$ rm -rf ~/.docker
Step 4:
$ docker-compose build --pull
Finished!
Never found a way to directly resolve the docker-credential-gcloud issue, but the following got me up and running again. WARNING: the following will delete all your existing docker images and install a bunch of gcloud utilities:
gcloud components install docker-credential-gcr,
Restart the terminal completely
docker-credential-gcr configure-docker.
screen ~/Library/Containers/com.docker.docker/Data/com.docker.driver.amd64-linux/tty
umount /var/lib/docker/overlay2
rm -rf /var/lib/docker
Restart the terminal completely.
The new version of google-cloud-sdk has only docker-credential-gcr but not docker-credential-gcloud anymore. On the other hand one of my python packages always requested docker-credential-gcloud.
The solution was to symlink docker-credential-gcloud to docker-credential-gcr:
ln -s /path/to/google-cloud-sdk/bin/docker-credential-gcr /usr/local/bin/docker-credential-gcloud
ls -l /usr/local/bin | grep docker should now print:
...
docker-credential-gcloud -> /path/to/google-cloud-sdk/bin/docker-credential-gcr
...
Usually, this error indicates that your $PATH variable has been clobbered by a package or program you have recently installed so that the Google Cloud SDK can't be found.
$PATH is altered by many programs when they install by altering ~/.profile, ~/.bash_profile or ~/.bashrc or their non-bash equivalents. With a bad $PATH, Google Cloud SDK is configured in docker but can't be seen as executables so we get this error. This assumes you have used the Google Cloud SDK in the past, but if gcloud is configured with your docker then you probably have. Don't reinstall gcloud or disable it, you already have it on your system and that is fine.
The solution then is to fix your $PATH, not to install anything.
echo $PATH
This should be a pretty long : delimited list of directories that your files are in. Do you see a google-cloud-sdk/bin in the string? Is the string way too short given all the trouble you've gotten into in your life on this computer? You use NVM but it is missing? Use Homebrew but it is missing? Try brew from the command line, does it work?
If the answer is "no" to any of the above, inspect the files above to see if there are any new entries at the bottom of each that might have broken things. Did you just install anything new?
Something is clobbering your $PATH and you need to figure out what that is. For me it is usually something to do with Anaconda Python via the conda init command. For you it might be nvm or something else. Figure out what it is and fix the problem. Don't start over with a new $PATH and install the same stuff over again or disable gcloud authentication.
It really seems to be something with the Homebrew Cask. I uninstalled the cask and then reinstalled the Google Cloud SDK by manually downloading the tar ball and running the packaged install script as described there.
Now docker-credential-gcloud is in my path:
$ which docker-credential-gcloud
/Users/moritz/google-cloud-sdk/bin/docker-credential-gcloud
I can't figure out what Google is trying to achieve here. On Linux there is docker-credential-gcloud and on Windows there is docker-credential-gcr.exe, and then there is docker-credential-gcloud.cmd which calls gcloud auth docker-helper. This is kind of a nightmare if you're trying to write portable build scripts or gradle rules because not everything seems capable of finding and calling docker-credential-gcloud.cmd when you exec docker-credential-gcloud... it might work from the dos prompt, but in general doesn't work.
After a ton of fooling around with .bat scripts, cygwin scripts, .cmd scripts and so forth, I found the best solution was to go into the gcloud installation and just copy docker-credential-gcr.exe docker-credential-gcloud.exe ... not a very satisfying solution, but is the only thing I found that would do the trick.
I got the issue when I tried to SSH from Google Cloud Build into an Engine VM Instance, so I had
steps:
- name: 'gcr.io/cloud-builders/gcloud'
args: ['compute', 'ssh',
'--project', '$PROJECT_ID',
'--zone', 'asia-southeast1-b',
'--strict-host-key-checking=no',
'username#instance-1',
'--command' ,'sh start.sh'
My start.sh
#!/bin/sh
echo "Started: $(date --iso-8601=seconds)"
docker pull gcr.io/aaa/bbbc/cccc
echo "Finished: $(date --iso-8601=seconds)"
The issue was How to set PATH when running a ssh command?
https://unix.stackexchange.com/questions/332532/how-to-set-path-when-running-a-ssh-command
So I just faced the same problem where I am trying to pull an image from GCR to an GCP instance and want to share my solution.
I ran gcloud auth configure-docker and got the warning:
WARNING: `docker-credential-gcloud\` not in system PATH.
gcloud's Docker credential helper can be configured but it will not work until this is corrected.
I applied the accepted answer for this thread and ran gcloud components install docker-credential-gcr and got a long error:
ERROR: (gcloud.components.install) You cannot perform this action because this Cloud SDK installation is managed by an external package manager.
Please consider using a separate installation of the Cloud SDK created through the default mechanism described at: https://cloud.google.com/sdk/
When no solution was working, I uninstalled the Google provided google-cloud-sdk package that was installed via snap and instlled with distro specifice package manager, for me that is apt-get as instructed in the Installing Google Cloud SDK: Installation options page and re-ran the gcloud auth configure-docker and this time it solved my problem.
In my case the problem was due to how WSL 1 works with Docker on Windows. At first I only installed and initialized gcloud in WSL Ubuntu, not in Windows. However as Docker daemon is actually run by Windows, you need to install gcloud for Windows as well (and don't forget to run all of the inits and authorizations there).
On Windows 10/11, you need to ensure that C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\ is added to your system $PATH environment variable. It may not have been added if the Google Cloud SDK was not able to add it during GCloud installation. So add it manually like this:
Windows Task Bar ➔ Press the search icon 🔍 or the search bar
Type "environment" ➔ and click on "Edit the System Environment Variables" (ensure that you have Administrator access)
At the bottom of the dialog, click the Environment Variables... button
System Variables ➔ click Path ➔ Edit... ➔ New ➔ paste in C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\ (replace "USERNAME" with your username)
Close and restart any open Command Prompt windows.
Then verify on the Git Bash for Windows console:
Optional: Note that the AppData folder is hidden by default, so you may want to unhide AppData first, to see its contents.
Restart the Git Bash Terminal window
echo $PATH ➔ This should print a long string that contains: :/c/Users/USERNAME/AppData/Local/Google/Cloud SDK/google-cloud-sdk/bin
where docker-credential-gcloud ➔ This should print C:\Users\USERNAME\AppData\Local\Google\Cloud SDK\google-cloud-sdk\bin\docker-credential-gcloud.cmd
For a few days I am trying to set Jenkins on Tomcat7 without any result... I read many tutorials and I could not find any help...
I set a virtual system on VirtualBox -> Ubuntu 12.04.04
Using apt-get I installed tomcat7, and then Jenkins.
While using them separately by usingcommad sudo service tomcat7 start or sudo service jenkins start both services starts and are visable on my localhost.
However, when I copied jenkins.war to /var/lib/tomcat7/webapps I cannot run it via tomcat.
I have set JENKINS_HOME as /var/lib/jenkins.
In the folder /usr/share/tomcat7 i run these commands: sudo mkdir .jenkins | sudo chown tomcat7:nogroup .jenkins
And from localhost:8080/manager jenkins is viable:
When I try localhost:8080/jenkins as tutorials says I get en error message:
I really have no idea what am I doing wrong...
What else may I try to make it work?
I had the same issue. Please check Java compatibility version with the "Jenkins.war" file. I used Java 8 for Jenkins version 2.107.1.
I would suggest to shutdown restart the tomcat server. As it should be able to read the .war file. Hence, you will go through additional setup.
Check the version of your jenkins.war file
Check the compatibe java version for hat jenkins version in web
Download that version of java and define system environment variables path for JAVA_HOME
Open "Monitor tomcat" in that JAVA define the path of jvm.dll
example C:\Program Files\Java\jdk-11.0.16\bin\server\jvm.dll
This picture shows how to run in windows:
Please check your JRE path, as I face a similar issue where JRE_HOME was incorrectly set
JRE_HOME=/usr/jdk/jdk1.6.0_21,
It started working when I correct it to latest JRE version
JRE_HOME=/usr/jdk/jdk1.7.0_09/jre.
After upgrading my macOS to Sierra, when I start Jenkins using launchctl load I cannot connect to localhost:8080. If I call launchctl load again, I see response "service already loaded". There is no log file at the default location /var/log/jenkins/ (as set in jenkins-ci.plist). I also tried to create jenkins.log there and chown to jenkins user, but still nothing is printed there.
If I try to start Jenkins using java -jar jenkins.war, I can connect to localhost, but Jenkins runs as a new installation.
I have the latest JRE 1.8.0_102 installed.
How to diagnose the problem?
Seems that Sierra changed the permission of Jenkis folder. So the best solution is:
1. Add execute permissions to org.jenkins-ci.plist:
sudo chmod +x /Library/LaunchDaemons/org.jenkins-ci.plist
2. Set jenkins as the owner of /var/log/jenkins:
sudo chown jenkins /var/log/jenkins
3. Start Jenkins:
sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
This happened to me when I upgraded to Sierra and I managed to solve it with the answer from #mac.slusarek . But it happened again recently. This time I had allowed a minor update of the OS and I had also been playing around with SDK Man to switch JDK's. Not sure which one broke my Jenkins but this time around it was not a permissions issue.
I noticed from the logs Jenkins was trying to run on Java 9-ea, which is apparently not supported yet. I had installed Jenkins using the Jenkins installer for Mac, so tried uninstalling:
/Library/Application\ Support/Jenkins/Uninstall.command
and installing again but the issue didn't go away.
Then I found this article suggesting to instead install it using Homebrew. It was as easy as running:
$brew install jenkins
Since I only run it locally for development I don't need to start it as a daemon, so now I just run it by typing
$jenkins
Problem solved. I hope this helps others.
I fixed it by setting the appropriate JAVA_HOME variable. The way I diagnosed it was to look at the errors that were thrown as Jenkins was trying to run:
tail -f /var/log/jenkins/jenkins.log
Then I tried to run it:
sudo launchctl load -w /Library/LaunchDaemons/org.jenkins-ci.plist
If it says it's already loaded, unload it first:
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
Then run it:
sudo launchctl load -w /Library/LaunchDaemons/org.jenkins-ci.plist
The error I saw was that Jenkins needed Java 8, not Java 10. So I unloaded:
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
and then installed Java 8. Then I edited the plist file:
sudo nano /Library/LaunchDaemons/org.jenkins-ci.plist
and added the appropriate JAVA_HOME environment variable:
<dict>
<key>JENKINS_HOME</key>
<string>/Users/Shared/Jenkins/Home</string>
<key>JAVA_HOME</key>
<string>/Library/Java/JavaVirtualMachines/jdk1.8.0_161.jdk/Contents/Home</string>
</dict>
Finally, I tried the launchctl command again:
sudo launchctl load -w /Library/LaunchDaemons/org.jenkins-ci.plist
and voilà!
I had the same issue, installing the JDK didn't made the trick
However changing the rights of the log directory (in my case /var/log/jenkins) and restarting Jenkins worked.
Seems that moving to Sierra changed the rights on this folder.
In my case, the install on Catalina (OSX 10.15) somehow didn't even create the /var/log/jenkins file. I had to
sudo mkdir /var/log/jenkins
and then take ownership and then Jenkins started normally. Just did the normal OSX installer so not sure why the install was corrupt.
As I mentioned in the question, I had JRE installed. After I installed JDK, Jenkins is able to start normally.
This same thing happened to me when I upgraded from Sierra to High Sierra. I followed the instructions outlined above by mac.slusarek, however the jenkins ID no longer existed on my computer. I created the jenkins id as a Standard user.
Also, the files under /Users/Shared/Jenkins were no longer owned by jenkins. After I cat out the error log with the command:
sudo cat /var/log/jenkins/jenkins.log
After seeing the error:
Exception in thread "main" java.io.IOException: Jenkins has failed to create a
temporary file in /Users/Shared/Jenkins/tmp
at Main.extractFromJar(Main.java:368)
at Main._main(Main.java:210)
at Main.main(Main.java:112)
Caused by: java.io.IOException: Permission denied
at java.io.UnixFileSystem.createFileExclusively(Native Method)
at java.io.File.createTempFile(File.java:2024)
at Main.extractFromJar(Main.java:365)
... 2 more
I fixed the ownership with the command:
sudo chown -R jenkins /Users/Shared/Jenkins
I had the same problem.
I manually enabled the read + write access to the
/Users/Shared/Jenkins
Folder.
I was facing issue in loading jenkins-cli.plist command on my MacOs(Mojave version).
Mac Version : Mojave 10.14.6
Jenkins Version : 2.190.1
I installed jenkins using .pkg file.
Reference link : https://java2blog.com/install-jenkins-mac-os-x/
When executing below command,
sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
I was facing error saying "already loaded".
Solution:
step 1. Check jenkins logs for exact error.
tail -f /var/log/jenkins/jenkins.log
(In my case, it was port binding issue, port 8080 was already being used by some other application)
step 2. So I decided to start jenkins on some other port (say 7070).You can do this by using below commands.
sudo defaults write /Library/Preferences/org.jenkins-ci.plist httpPort 7070
sudo launchctl unload /Library/LaunchDaemons/org.jenkins-ci.plist
sudo launchctl load /Library/LaunchDaemons/org.jenkins-ci.plist
step 3. Try to access it in browser, http://localhost:7070. It should work!!
I'm trying to install Jenkins on a Tomcat 7 container.
When I try to open the Jenkins web app I get following error:
Unable to create the home directory '/home/myuser/jenkins/work'. This is most
likely a permission problem.
To change the home directory, use JENKINS_HOME environment variable or set
the JENKINS_HOME system property. See Container-specific documentation for
more details of how to do this.
Before starting Tomcat, I did chmod uog+rwx /home/myuser/jenkins. So, I suppose that Jenkins should be able to create a subdirectory there.
But obviously it can't.
How can I fix this problem?
Update 1:
lt -lt returns
drwxrwxrwx 2 root ec2-user 4096 Jun 23 10:25 jenkins
for /home/myuser/jenkins. /home/myuser/jenkins/work doesn't exist because Jenkins is supposed to create it.
Update 2: Just tried to create the work directory and to run chmod uog+rwx on it. It didn't help.
Update 3: Additional information:
I need Jenkins in order to
run lengthy tests in the night (fast unit tests are run before every mvn install, slow tests are executed every night) and
save software quality metrics (checkstyle, PMD, FindBugs, unit test coverage etc.) over time.
I have only one machine available for that and there is a Tomcat7 container installed there already.
At the moment, I don't want to invest additional money into buying new machines.
The machine with the Tomcat7 container (and where I want Jenkins to be installed) is an Amazon EC2 microinstance (OS version is given below).
$ cat /etc/*-release
LSB_VERSION=base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Amazon Linux AMI release 2013.03
Update 4 (29.06.2013 13:34 MSK): The output of yum list does not contain any Jenkins/Hudson package.
If Tomcat is running as a separate user you will need to give execute permission to your home directory to that user - either by giving it to all or by creating a group especially for you and the tomcat user.
(UPDATE) More specifically: You say you already did chmod uog+rwx /home/myuser/jenkins, if Tomcat is not running asl 'myuser' it also needs execute permission on /home and on /home/myuser to be able to open /home/myuser/jenkins. If you are not picky about other users on the system opening your homedir you could allow this by: chmod a+x /home/myuser. (I'm assuming here the permissions for /home are already ok)
If you are running tomcat as 'myuser' the filsystem permissions look fine, but Tomcat's own permission system might be the problem as webapps are not allowed to touch the filesystem if the default settings of the security manager are on.
See: https://wiki.jenkins-ci.org/display/JENKINS/Tomcat
You don't specify more about your exact Tomcat/OS setup so I can't give exact details, but the fast way to find out if it's a security manager issue is to give AllPermission to you webapp. If you don't run in a safe environment it is advisable to only use that as a test, and setup only the really needed permissions later.
run these three commands
cd /usr/share/tomcat7
sudo mkdir .jenkins
sudo chown tomcat7:nogroup .jenkins
https://seleniumwithjavapython.wordpress.com/home/jenkins-installation/
It looks like the problem may be that jenkins cannot see /home/myuser, and therefore it cannot access the jenkins folder inside this (even though it has write permissions in /home/myuser/jenkins, I believe the fact it can't read /home/myuser causes a problem).
Try running the below command and then see if Jenkins works after that:
chmod +r /home/myuser
#robjohncox Yes - drwx------ 5 myuser myuser 4096 Jun 23 10:25 myuser
you must add +x to this dir to make it possible for jenkins to access it's contents, to be precise whole path has to have +x enabled for everyone.
Also, what commands have you used to move it's home dir from default - possible error is somwhere there. Cheers, Piotr
i'm trying to get jenkins running on debian 7 but i keep getting this error while apt-get install jenkins is running.
Setting up dbus (1.6.8-1) ...
Failed to open connection to "system" message bus: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
[ ok ] Starting system message bus: dbus.
Also i get the message that jenkins is started at the end and no error message:
[ ok ] Starting Jenkins Continuous Integration Server: jenkins.
but /etc/init.d/jenkins status gives me the output that jenkins is not running. also ls -alh /var/lib/jenkins gives me an empty folder.
So the install fails with no error.
This is the way i'm running the install:
wget -q -O - http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key | apt-key add -
sh -c 'echo deb http://pkg.jenkins-ci.org/debian binary/ > /etc/apt/sources.list.d/jenkins.list'
apt-get update
apt-get install jenkins
Has anyone of you tried installing jenkins on a fresh debian 7?
looking forward for helping answers.
kind regards and thanks in advance
So i solved the problem finally.
I expected the Java SDK to have the right JRE in it, so i downloaded it from the Oracle website: jdk1.7.0_21-x64-linux.tar.gz after installing and registering this to my machine it worked java -version and javac -version.
Problem was the version of this JRE did not work with Jenkins so thanks to #wako, i installed openjdk-7-jre and i have now two jre's running on my machine but jenkins started finally. need to figure out if openjdk-7-jre suits my plans or if i need to fall back to Debian 6.
This is an issue with apt-get and not with Jenkins -
please make sure you run it as root.
Can try to install (or upgrade) another package, to confirm.
I had the same problem on the debian 7 freshly installed, via the light version of debian 7 with the ssh server only installed.
First I add the repository as you specified it, try to install jenkins but some dependencies were broken (daemon-psmisc-java2-runtime).
To solve the problem I did an:
apt-get -f upgrade
And it was OK
To complete the installation of jenkins you will need apache2 and java-jre
apt-get install apache2 openjdk-7-jre