I installed Jenkins using apt-get install jenkins. Then I made some changes in /etc/default/jenkins (which is, as far as I know, the only way to change the Jenkins system user etc.). Now I found out that this file becomes reverted with every update (using apt-get update).
In addition I changed the owner of some files of the jenkins installation (e.g. /var/lib/jenkins, /var/log/jenkins and some others) because I changed the user under which jenkins should run. Also these permission changes are reverted after every update.
There are two solutions I could think about, both not really "nice" and clean:
Install and run the jenkins.war manually without any package management
Write a DPKG-Post-Install-Trigger that fixes the problems after every update
Does anyone have a cleaner solution for that?
Two answers occur to me
1) Download the source package that apt-get uses and modify the users, permissions etc to suit your local use. Rebuild the package and either install it from cli with dpkg -i or make your own repository for local use.
or
2) Use a tool like puppet to manage the package install and then apply the changes required locally afterwards. The puppet "package/file/service" pattern explained in various places including here https://docs.puppetlabs.com/puppet_core_types_cheatsheet.pdf shows how to do the puppet manifests for this
Related
I'm creating a multi stage build docker file. In the deployment step that will actually run the program i'm running
RUN apk update && apk upgrade --no-cache
Should I also have this statement in my build stage?
It isn't necessary to always apt update/upgrade in your dockerfile. However it surely isn't a bad idea. Especially if you install packages with apt, you should make sure that the package list is up-to-date. So you always get the latest version of the package you want to install.
Installing security updates on build time does matter, especially if your base image is not that recent. But I wouldn't call it necessary and it also depends on how important it is for your base image to be up-to-date.
Well, it depends, it has both benefits and drawbacks.
Two links I found where they go through the idea of both approaches:
https://github.com/docker-library/php/issues/1007
https://github.com/grafana/grafana/issues/24132
In my opinion one of the good aspects of Docker is to have things reproducible and less 'it works on my machine' moments.
When you start calling things like apk update/upgrade the result depends on WHEN the call is executed. So basically you won't be able to recreate an image or compare one version in CVS to another. I would argue the minor security updates you might or might not get are not worth it.
Better to update to next specific release of the alpine base image for example and not to call apk update or upgrade.
Installed Jenkins on a Linux server and want to install some plugins manually.
I want to install Blue Ocean and Artifactory.
For both plugins I downloaded the hpi file and tried to install it, but I get a lot of dependency errors.
Do I now have to install those dependencies manually as well? or is there a better way to do this?
I tried to install one of those dependency and that one also had some dependency errors as well :-(
The Linux server is not able to access the internet.
Thanks!
Robert
You are correct that BlueOcean has a lot of dependencies.
Given you are not able to connect to the internet you will need to download all 21 BlueOcean related hpi files and upload them from the Manage Jenkins > Manage Plugins > Advanced tab.
Alternatively, if you have access to the server that your Jenkins instance is running on you can copy the hpi files into the %JENKINS_HOME%/plugins folder. The corresponding directories (exploded from the hpi, which is just a zip file) will be created on Jenkins restart.
The easiest way to acquire all 21 plugin files is to open The Jenkins plugin page and search for blueocean. Download the same numbered version of all 21 and upload them one by one. Order shouldn't be an issue. As long as they are all present on restart the dependencies will resolve.
Same process goes for any other plugin. If you're able to get the machine connected to the internet it will make the process a lot simpler as you will be able to use the update center, which manages dependencies and update notifications.
Same case here. Our Jenkins is setup in OpenShift which is not allowed to connect to the Internet. Downloading a plugin 1-by-1 is tiresome. Not to mention that each plugins have its own dependencies that needs to be downloaded as well.
Here's what you would do...
Run a Jenkins locally in a machine that can download plugins.
Download and update all the plugins you want using the Update Center.
Go %JENKINS_HOME%/plugins directory. Inside this folder you would see *.jpi. These are your plugins. Its dependencies will be downloaded as well.
Rename it to *.hpi then keep it in some directory.
To test...
In your local Jenkins delete everything in %JENKINS_HOME%/plugins directory then put all *.hpi in this directory.
Restart your local Jenkins.
Verify if the plugins you require are installed and updated.
I have a project which runs karma tests and need chromium-browser binary. For testing purposes I've manually install it with apt install but now that it is working I'll like to have an automatic way to install it on any Jenkins slave.
I've tried chromedriver-plugin but it doesn't seem to work and not maintained for over 2 years.
you can use the slave setup plugin
it will install the chromium-browser on the startup process. another option is to add the installation to the relevant job , and install the package only if it's not installed already.
BTW , how many slaves you have , did you install them manually or automatically ?
I could successfully install the jenkins online over my laptop. But while trying to install the jenkins offline (on my office workstation which cannot be connected to internet) the hell breaks loose.
After running the jenkins.war over command line although the jenkins was successfully installed yet some of the plugins were missing.I managed to get some help from the post How to install a plugin in Jenkins manually?
But then each of the plugins have to be individually downloaded and then copied over to my offline machine. So I had a trick.
I copied all the folders under .jenkins directory (in my online installation machine) and then copied them to my offline machine. Whoa!
It worked!
But I still get one single error:
Maven Integration Plugin V2.16 .javadoc 1.0 is missing. To fix, install v1.0 or later
So is there a way/website/pdf/repository which is a one stop solution/steps to smoothly install (read has all the required dependencies as a zip) Jenkins in offline mode. (If not, to the creators of Jenkins: Would it be a good idea to have one?)
I'm also searching for an easy way to manage the dependencies between the plugins but as far as I know there is no official tool for that.
Either you have a .zip file with all the plugins which you prepare one time or you fix the errors manually.
For your problem it should be enough to install the following .hpi file: https://updates.jenkins-ci.org/latest/javadoc.hpi (javadoc has no dependencies to other plugins)
You can download the .hpi version of plugins required and paste them in plugins folder at jenkins_home and then restart the jenkins,then you can able to use those plugins.
I installed Jenkins 1.531.1.1 on CentOS 5.5 by executing the below mentioned commands:
sudo wget -O /etc/yum.repos.d/jenkins.repo http://pkg.jenkins-ci.org/redhat/jenkins.repo
sudo rpm --import http://pkg.jenkins-ci.org/redhat/jenkins-ci.org.key
sudo yum install jenkins
I changed the JENKINS_HOME variable in the /etc/sysconfig/jenkins file to something other than /var/lib/jenkins. I changed the default port on which jenkins runs from 8080 to 9999. I also generated the ssh keys needed to pull code from github.
Unfortunately, when I try to define the github repository url in a Jenkins job, it failed to authenticate. When I checked grep jenkins /etc/passwd, the jenkins user was no longer there. I did the whole process twice and the user seems to be getting removed. Any pointers would be helpful!
The deployment team had set up a script to automatically delete any new users created just for maintenance purposes. The fact that it happened across multiple CentOS servers actually triggered me to ask this question.