Pipeline builds have the annoying habit of sandboxing themselves, which means that they watch for "dangerous" commands. If your pipeline groovy script has a dangerous command (which can be a whole hell of a lot of things), it will not let you execute the command and fail the script.
If your sandbox is enabled, you need to approve of all dangerous executions, on the page found under: Manage Jenkins > In-process Script Approval
Or you could turn off the sandbox. Which is a funky and annoying guardian, that makes testing a script a devil of a thing.
Jenkins and script approval. One word. Nazis.
Maybe I'm the only one who's been having problems with the Jenkins Pipeline Plugin. Maybe I'm the only one who pounded away at my keyboard for three hours trying to find out why I couldn't get the name of the user who initiate the pipeline.
This piece of code. This one terrible piece of code
By default, Groovy sandboxing is turned on when you work on a pipeline job and when that happens, the compiler only lets through code that is either safe (which translates to Does Nothing) or else is approved by an administrator.
That all sounds good. That all sounds like a great way to control these jobs, and ensure good quality in the jobs.
But the approval process is a mess if you don't turn off Groovy sandboxing. Because Jenkins won't allow you to run the script with unapproved code, and Jenkins won't allow you to approve code without running the script first.
It gets better: Jenkins runs a job until it finds an unapproved action, after which it stops, and demands that you approve the action first.
In the example above, accessing the rawBuild variable is considered unsafe, so you have to approve it first. But the method getCauses() is also unsafe, but it won't bother to tell you that it's unsafe. Which means that you spend your morning doing things like this:
This piece of code. This one terrible piece of code
By default, Groovy sandboxing is turned on when you work on a pipeline job and when that happens, the compiler only lets through code that is either safe (which translates to Does Nothing) or else is approved by an administrator.
That all sounds good. That all sounds like a great way to control these jobs, and ensure good quality in the jobs.
But the approval process is a mess if you don't turn off Groovy sandboxing. Because Jenkins won't allow you to run the script with unapproved code, and Jenkins won't allow you to approve code without running the script first.
It gets better: Jenkins runs a job until it finds an unapproved action, after which it stops, and demands that you approve the action first.
In the example above, accessing the rawBuild variable is considered unsafe, so you have to approve it first. But the method getCauses() is also unsafe, but it won't bother to tell you that it's unsafe. Which means that you spend your morning doing things like this:
- Write the code
- Run the jenkins - it fails
- Go to the Script Approval page and approve the use of rawBuild
- Run the jenkins - it fails
- Go to the Script Approval page and approve the use of getCauses()
Jenkins2 errors: "No valid crumb was included in request "
After installing my Jenkins2 on Ubuntu 14.04, I got everything up and running, only to find jenkins.log filling up with error messages, to the tune of 60 per minute, 70,000 messages per day:
After a bit of Googling, the consensus was that this was connected to the Build Monitor Plugin, which I promptly uninstalled, but to no avail.
Digging a bit more, it looks like this is connected to the CSRF protection implemented in Jenkins2, but not found in Jenkins1. Once I disabled this, the logging stopped.
I'm not saying that this is the solution to the problem. I'm just saying that if you have this issue, can't fix it, then disabling CSRF protection will work.
To disable:
This is NOT a long term solution. This just stops the logging, until you can dig deeper and find the real source of the problem.
Sep 21, 2017 9:27:21 AM hudson.security.csrf.CrumbFilter doFilter WARNING: Found invalid crumb ad97b73a2a6de7a04b11f45e3fe9bf8f. Will check remaining parameters for a valid one... Sep 21, 2017 9:27:21 AM hudson.security.csrf.CrumbFilter doFilter WARNING: No valid crumb was included in request for /ajaxExecutors. Returning 403.
Digging a bit more, it looks like this is connected to the CSRF protection implemented in Jenkins2, but not found in Jenkins1. Once I disabled this, the logging stopped.
I'm not saying that this is the solution to the problem. I'm just saying that if you have this issue, can't fix it, then disabling CSRF protection will work.
To disable:
- Log in to Jenkins as an Administrator
- GOTO: Jenkins > Manage Jenkins > Configure Global Security and enable Prevent Cross Site Request Forgery exploits
- Uncheck this option
This is NOT a long term solution. This just stops the logging, until you can dig deeper and find the real source of the problem.
Elasticsearch plugin troubleshooting
Problem: Elasticsearch won't restart
After trying to start Elasticsearch, using
sudo service elasticsearch start, it confirmed that it had started elasticsearch, but when I ran
sudo service elasticsearch statusall I got in response was:
* elasticsearch is not running
Nothing more than that, which was goddammed annoying because I was busy trying to do real work (Reddit).
I found evidence of the cause in /var/log/elasticsearch/elasticsearch.log:
So it was a plugin. But what plugin?
I ran these commands to try and reinstall the licenses:
cd /usr/share/elasticsearch/bin sudo ./plugin remove license sudo ./plugin install license
After running that, I got a better error message:
ERROR: Plugin [watcher] is incompatible with Elasticsearch [2.4.6]. Was designed for version [2.4.4]
So it was the watcher plugin causing problems. Fixing it was easy enough though:
sudo ./plugin install watcher sudo ./plugin install license
That's all it took. I restarted elasticsearch and I was on my way.
Jenkins2 on AWS - make a redirect from http to https
You think it would be simple to set up a http redirect on an AWS Marketplace setup for Jenkins2, but it isn't. As it turns out, the instructions from AWS itself are wrong, and so are the instructions from Bitnami!
Here is the redirect that will work. This should be valid for most apache setups on AWS, and then I will show you how to apply it to a Jenkins2 server.
Add this to your apache conf file:
Then restart apache and you should have no problem after that.
To do this for Bitnami's implementation of Jenkins2 on AWS (this is the AWS Marketplace image), do the following:
Here is the redirect that will work. This should be valid for most apache setups on AWS, and then I will show you how to apply it to a Jenkins2 server.
Add this to your apache conf file:
RewriteEngine on
RewriteCond %{HTTP:X-Forwarded-Proto} ^http$
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]
Then restart apache and you should have no problem after that.
To do this for Bitnami's implementation of Jenkins2 on AWS (this is the AWS Marketplace image), do the following:
- Add the above change to the top of: /opt/bitnami/apps/jenkins/conf/httpd-prefix.conf
- Restart apache:
sudo /opt/bitnami/ctlscript.sh restart apache
REFERENCES
How to delete all broken symbolic links with a single line
If you are in the directory:
Careful! This will follow good symbolic links and delete bad sym links recursively!
If you want to list them instead, but not delete:
sudo find -L . -type l -delete
Careful! This will follow good symbolic links and delete bad sym links recursively!
If you want to list them instead, but not delete:
sudo find -L path-to-directory -type l
Subscribe to:
Posts (Atom)