Background
I have the following Jenkins config.
Ubuntu machine
Jenkins installed using apt-get, and is started as a service (service jenkins start).
To this point I have not made any modifications to Jenkins config.
We have several Ant projects for which I want to publish Javadocs using Jenkins.
After configuring the Javadoc plugin, I quickly hit this issue where only the Javadoc frames are displaying, without any content.
Some reading (here and here) told me that I need to configure Jenkins' Content Security Policy, and that this is done by modifying system properties passed to Jenkins.
However, despite digging around I have not found clear docs on how to pass these system properties to the Jenkins service. How do I do that?
Answering my own question.
To set system properties for the Jenkins service:
Steps
Stop Jenkins (service jenkins stop). You will need root privileges.
Edit the /etc/defaults/jenkins file.
Add an additional line for the JAVA_ARGS that you want to pass.
JAVA_ARGS="-Dhudson.model.DirectoryBrowserSupport.CSP=\"your CSP configuration here\""
Start Jenkins (service jenkins start).
Explanation
Look at /etc/init.d/jenkins for a line similar to:
NAME=jenkins
SCRIPTNAME=/etc/init.d/$NAME
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
These tell us that the Jenkins daemon will look for a file named /etc/default/jenkins. If present, it .s that file.
If you set $JAVA_ARGS in /etc/default/jenkins it will be substituted in the line below, located later in the /etc/init.d/jenkins file:
$SU -l $JENKINS_USER --shell=/bin/bash -c "$DAEMON $DAEMON_ARGS -- $JAVA $JAVA_ARGS -jar $JENKINS_WAR $JENKINS_ARGS" || return 2
Notes
Even after you do the above, the Javadoc may not load properly. Try doing a hard refresh (Ctrl-Shift-R on Chrome).
As detailed in (the Jenkins docs)[https://wiki.jenkins-ci.org/display/JENKINS/Configuring+Content+Security+Policy] there is a temporary way to do this as well. Read that page and try to understand the implications well.
Changing the Content Security Policy has serious implications especially if your Jenkins is public. It's worth the effort to understand just what policies you are modifying.
Related
How can I apply a new Jenkins configuration as code YAML file from a groovy script, similar to clicking the "Apply new configuration" button in the UI.
I didn't try yet, but this looks as a feasible approach to me:
In the Jenkins home directory (/var/lib/jenkins on my Ubuntu installation) there is a file io.jenkins.plugins.casc.CasCGlobalConfig.xml. Edit that in order to provide a path/URL to your YAML file. On my system that file has the content like below, and I assume that just replacing the value of the <configurationPath> element with your yaml path should be sufficient.
<io.jenkins.plugins.casc.CasCGlobalConfig plugin="configuration-as-code#1569.vb_72405b_80249">
<configurationPath>/PATH/TO/MY/jenkins.casc.yaml</configurationPath>
</io.jenkins.plugins.casc.CasCGlobalConfig>
This configuration seems to be automatically applied each time when Jenkins is restarted.
In order to apply the configuration immediately, there seems to be jenkins-cli api for that. See the http://YOUR_JENKINS/manage/cli page and look for the reload-jcasc-configuration command, which suggests: java -jar jenkins-cli.jar -s http://YOUR_JENKINS/ -webSocket reload-jcasc-configuration
You ask for a "groovy script". With that I can't help, but I guess that modifying a file or running the jenkins-cli should be perfectly doable in a groovy script.
I want to update Jenkins plugin via Artifactory.
Create a remote repo named Jenkins-update
Create a local repo named jenkins-update-center
Get the update-center.json from repo Jenkins-update to local and modify the URL from 'http://updates.jenkins-ci.org/' to my own URL 'https://artifacts.xxx.com/artifactory/Jenkins-update/' in update-center.json, then put update-center.json into local repo.
#!/bin/sh
curl -L -o /tmp/update-center.json http://localhost:8081/artifactory/Jenkins-update-cache/update-center.json
sed -i 's#http://updates.jenkins-ci.org/#https://artifacts.xxx.com/artifactory/Jenkins-update/#g' /tmp/update-center.json
curl -L -uuser:pass -T /tmp/update-center.json "http://localhost:8081/artifactory/jenkins-update-center/update-center.json"
Change the default update site from 'http://updates.jenkins-ci.org/' to 'https://artifacts.xxx.com/artifactory/jenkins-update-center/update-center.json' in Jenkins
There is an error 'SHA-512 digest mismatch: expected=49a22dc23f739a76623d10128b6803f79e0489de3ded0f1d01f3dfba4557136c7f318baaf4749a7713ec4b3f56633f2ac3afc4703e87d423ede029d68f84c74d in 'update site 'default''' when I click 'check now' button.
What should I do to make Jenkins update plugins from Artifactory?
Tkx
As soon as the content of update-center.json changed you need to re-generate "signature" section of this file.
For that you need to generate your key pair (see more details in How to create a local mirror of public Jenkins update site?)
Also you may use the following proposed approach :
there is probably a better way, by having a sandbox Jenkins on a system that has access to the internet. You update the server using the UI and then you can test that updated Jenkins thoroughly. When done, you just need to copy the war and hpi files over to your 'production' Jenkins. now you have even a nice process and QA in place.
Another way is to setup a transparent https proxy between your Jenkins and Artifactory server - in that case update-center.json will not change and signature verification should work fine.
With best regards,
Dmytro Gorbunov
As of 2023-01-10 there is a problem with making a mirror of the jenkins plugins on artifactory.
Artifactory documentation decribes only how to create a mirror: https://jfrog.com/knowledge-base/how-to-configure-artifactory-as-a-mirror-for-jenkins-plugins/
But this is not a complete solution. Because this leads to the situation when every plugin shall be manually updated. Having plugins with bunch of dependencies it is huge effort.
There is a need to generate a file: update-center.json
There is an internal jenkins tool to do this: https://github.com/jenkins-infra/update-center2, but documentation is poor and contains vague statements like:
With a few modifications it could easily be used to generate your corporate update center as well.
Without clear description, what shall be done.
I tried to follow steps and completely failed. Tool require some special environment variables, which are also not documented and so on.
So as of my experience mirroring jenkins plugins on artifactory is practically not possible. And honestly spoken, I would like to be wrong here.
I try to scan Jhipster generated code with Sonarqube during a Jenkins build.
My configuration is the following:
Gitlab as Docker Container
Jenkins 2 as Docker Container
Sonarqube 5.4 (higher is not permitted with MariaDB; right?) as Docker Container
This is a fresh install and all systems are communicating together.
When running builds, Jenkins is alerting about duplicates references in the 'bower_components' repository.
WARN: Too many duplication references on file
[moduleKey=Challenge1:0.1-HENDRIX,
relative=src/main/webapp/bower_components/angular-i18n/angular-locale_vun-tz.js,
basedir=/var/jenkins_home/workspace/Challenge-1] for block at line 20.
Keep only the first 100 references.
My problem is that I do not get the reasons why is alerting about it since few exclusions have been set at different levels:
1) Within pom.xml
<sonar.exclusions>src/main/webapp/content/**/*.*, src/main/webapp/bower_components/**/*.*, target/www/**/*.*</sonar.exclusions>
2) Within Jenkinsfile
node {
...
stage 'scan'
sh "${sonarqubeScannerHome}/bin/sonar-scanner -e -Dsonar.host.url=http://sonarqube:9000 -Dsonar.projectKey=Challenge1:'0.1-HENDRIX' -Dsonar.projectName='Challenge 1' -Dsonar.projectVersion='0.1-HENDRIX' -Dsonar.sources='src/' -Dsonar.coverage.exclusions=**/bower_components/**"
}
3) On sonarqube customizing itself (Analysis Scope).
EDIT:
This "non-exclusion" was originally leading to a memory dump that I could solved by extending the memory on sonarqube (sonar.properties).
sonar.web.javaOpts=-Xmx2048m -Xms512m -XX:MaxPermSize=160m -XX:+HeapDumpOnOutOfMemoryError -Djava.net.preferIPv4Stack=true
However, I a still am afraid that extending memory isn't the appropriate solution and I must be able to exclude some parts of code. What should I do to remove bower components from the scan analysis? (I probably made something wrong).
My mistake: I was using -Dsonar.coverage.exclusions instead of -Dsonar.global.exclusions
We have a Code Composer Studio (Eclipse) project that uses CMAKE to generate makefiles and build. The project compiles as expected when the project is manually imported onto the Jenkins slave (Win10 x64) and executed from the command line but fails when the build is handled by Jenkins. The failure always follows the same pattern: a singular letter is dropped from the path of an object file. For example, [Repo directory]/Cockpit_Scaling_and_Exceedance_data.dir becomes [Repo direcory]/Cockpit_Scaling_and_Exceedance_ata.dir and linking fails because it cannot find the referenced object file.
I made sure that there are no differences between the account environment variables and the system environment variables and have also configured the Jenkins Service to use the admin account on the slave instead of SYSTEM in order to get rid of as many differences between Jenkins and the command line as possible.
The project will build successfully using one of our other Jenkins slaves (also Win10 x64), so we know that it's not a Windows 10 issue or a problem with our Jenkins configuration. Since I can't find any differences between the configuration of the two slave machines, I was hoping that someone might be able to suggest somewhere to look for this path issue.
I never found out why the paths to object files were being mangled, but I did get the project to build successfully on the slave via Jenkins. All I did was change all of my system environment variables into user environment variables. I copy-pasted, so I know that the variables themselves did not change.
I have no idea why this corrected this issue as I had inserted a whoami call at the beginning of the build to confirm that Jenkins is indeed running as a user and not System. I guess from this point on all of my environment variables will be specific to a user and not SYSTEM...
EDIT: The problem has returned. I have made no further progress in tracking down the cause behind this issue, but I have found that I do not see this symptom when running the scripts in a bash environment instead of a Windows command prompt. Fortunately for me the scripts have all been written in such a way that they can be run in both environments, so I have had my coworkers use bash instead for them.
In any answer and in jenkins website tell me to set
<useSecurity>true</useSecurity>
in config.xml but in my jenkins folder don't have this file
config.xml doesn't get written until server is restarted at least once since installation.
Try restarting the Jenkins server.
This likely sounds like invalid Jenkins installation, or the file is in another place pointed by $JENKINS_HOME or $CATALINA_OPTS (e.g. ~/.jenkins or /var/usr/jenkins/.jenkins).
Another reason could be that by default Jenkins load all data from memory and you need to reload the configuration files from file system, so try restarting Jenkins.
Then double check in System Properties (at /systemInfo) that user.home points to the folder where you expect that file. Check also your System Log (/log/all) for any issues.
If above won't help, check the folder permission and if there is enough space (but you should have some error anyway). Or try reinstalling Jenkins.
According to Administering Jenkins documentation page, the config.xml Jenkins root configuration should be always in your JENKINS_HOME folder.
Once you've got config.xml, to disable security remove the lines with useSecurity and authorizationStrategy and restart Jenkins, or try executing these commands:
sudo ex +g/useSecurity/d +g/authorizationStrategy/d -scwq /var/lib/jenkins/config.xml
sudo /etc/init.d/jenkins restart