The post Using NGINX as an Atlassian JIRA Reverse Proxy appeared first on Justin Silver.
]]>I use JIRA in a cloud infrastructure where it’s obviously desirable to serve the contents over SSL, therefore I set up an NGINX as a JIRA reverse proxy for unencrypted requests to the JIRA backend service and handle the SSL on the front end with Let’s Encrypt. We need to let JIRA know that we are proxying it over HTTPS however by setting some values in server.xml first.
Notice that my Let’s Encrypt SSL certificates are in the /etc/letsencrypt/live/jira.doublesharp.com directory, but yours will be specific to the hostname you create them for. The certs are created via the letsencrypt command and use Nginx to process the validation request. Once created the generated PEM files can be used in your Nginx config. Note that you will need to comment out this line in the SSL config if they don’t yet exist, start Nginx to create the certs, uncomment the lines to enable SSL, and then restart Nginx once again (whew!).
Configure JIRA to add proxyName, proxyPort, scheme, and secure parameters to the Tomcat Connector in server.xml.
<Connector port="8081"
maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
bindOnInit="false"
proxyName="jira.doublesharp.com"
proxyPort="443"
scheme="https"
secure="true"
/>
Don’t forget to copy the database driver to $JIRA_INSTALL/lib.
Note use of “jira.doublesharp.com” in config and change as needed. This configuration uses a subdomain specific certificate from Let’s Encrypt, but you could also use a Wildcard Certificate for your JIRA reverse proxy setup as well which can help to consolidate your key generation.
# Upstream JIRA server on port 8081. Use 127.0.0.1 and not localhost to force IPv4.
upstream jira {
server 127.0.0.1:8081 fail_timeout=0;
}
# listen on HTTP2/SSL
server {
listen 443 ssl http2;
server_name jira.doublesharp.com;
# ssl certs from letsencrypt
ssl_certificate /etc/letsencrypt/live/jira.doublesharp.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/jira.doublesharp.com/privkey.pem;
location / {
# allow uploads up to 10MB
client_max_body_size 10m;
# set proxy headers for cloudflare/jira
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
# hand the request off to jira on non-ssl
proxy_pass http://jira;
}
}
# redirect HTTP and handle let's encrypt requests
server {
listen 80;
server_name jira.doublesharp.com;
root /var/lib/jira;
# handle letsencrypt domain validation
location ~ /.well-known {
allow all;
}
# send everything else to HTTPS
location / {
return 302 https://jira.doublesharp.com;
}
}
The post Using NGINX as an Atlassian JIRA Reverse Proxy appeared first on Justin Silver.
]]>The post Install Jenkins as a Service on CentOS 7 appeared first on Justin Silver.
]]>I have previously written about how to Install Jenkins on CentOS as a Service where it was necessary to write your own startup, shutdown, configuration, and init.d scripts. Luckily this is all much easier now as you can install the software directly from a yum repository – you’ll just need to fetch the repo from http://pkg.jenkins-ci.org/redhat/jenkins.repo.
Make sure you have Java on your system, then fetch the yum repository and install Jenkins.
yum -y install java curl http://pkg.jenkins-ci.org/redhat/jenkins.repo -o /etc/yum.repos.d/jenkins.repo rpm --import https://jenkins-ci.org/redhat/jenkins-ci.org.key yum -y install jenkins
Since CentOS 7 uses Systemd, use it to start the service on reboot.
systemctl enable jenkins service jenkins start
This will start jenkins on port 8080 by default (you can change these settings in /etc/sysconfig/jenkins). Leaving it as is and setting up a reverse Nginx proxy is my preference. Once you load the Jenkins home page you will be prompted to enter a password located in a file on your system to continue the setup. Here is a sample of my Nginx configuration.
# jenkins is upstream listening on port 8080
upstream jenkins {
server 127.0.0.1:8080 fail_timeout=0;
}
# nginx is listening on port 80
server {
listen 80;
server_name jenkins.example.com;
location / {
proxy_set_header Host $host:$server_port;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
proxy_pass http://jenkins;
}
}
Keep in mind that you may have issues initially proxying to Jenkins if SELinux is configured to block access to port 8080. If you try to load the site via Ngnix and get a “502 Bad Gateway” error, check out the /var/log/audit/audit.log – you will probably see errors regarding Nginx connecting to your port. You can either add the port by hand, or do it automatically with audit2allow.
mkdir ~/.semanage && cd ~/.semanage cat /var/log/audit/audit.log | grep nginx | grep denied | audit2allow -M semanage semodule -i semanage.pp
If you need to generate an SSH key for the Jenkins user, use sudo to run as the proper user.
sudo -u jenkins ssh-keygen
Enjoy!
The post Install Jenkins as a Service on CentOS 7 appeared first on Justin Silver.
]]>The post NGINX Reverse Proxy to Legacy Website appeared first on Justin Silver.
]]>NGINX reverse proxies can be a very powerful tool for many reasons and recently came to the rescue as I was at a loss as to how to provide access to a legacy website when launching the new one. The caveat in this case was that the legacy server is, well, old. It has many hard coded values throughout including URLs and only likes to listen on particular hostnames from time to time. Since I did not write this site and do not have access to the source code (it’s a DLL on a Windows box somewhere) I had to come up up with a solution to didn’t involve modifying the code.
The first option I thought of was to just update the /etc/hosts file (or Windows equivalent) to point the domain name to the old server IP address when needed, but this is a bit cumbersome. Comparing data between the new and old systems – presumably the main reason you would want to see the old server – is pretty much out. Faking the DNS is a no go.
An NGINX reverse proxy takes a request from a front-end NGINX server and passes it on to a back-end server in more traditional setup. In this situation the request is being made to the legacy server IP address and some special parameters are used to rewrite the domain information for redirects, cookies, and page content. We are also checking the port to determine if the request to the legacy server should be made via HTTP or HTTPS.
server {
# listen on 80 and 443, ssl if the latter
listen 80;
listen 443 ssl;
# this is the "new" url for the legacy site
server_name gamma.example.com;
# ssl config
ssl on;
ssl_certificate /etc/nginx/ssl/example.com.crt;
ssl_certificate_key /etc/nginx/ssl/example.com.key;
# legacy server IP address
set $legacy_ip 123.123.123.123;
# proxy over which protocol?
set $protocol http;
if ( $server_port = 443 ){
set $protocol https;
}
# pass everything through the proxy
location / {
# proxy all requests to the legacy server
proxy_pass $protocol://$legacy_ip;
# set the Host header on the request
proxy_set_header Host "www.example.com";
# replace redirect strings
proxy_redirect http://www.example.com/ /;
proxy_redirect https://www.example.com/ https://gamma.example.com/;
# replace cookie domains
proxy_cookie_domain 'www.example.com' 'gamma.example.com';
# replace page content
sub_filter_once off;
sub_filter 'www.example.com' 'gamma.example.com';
}
}
The post NGINX Reverse Proxy to Legacy Website appeared first on Justin Silver.
]]>