OS: Centos 7
Objective:
Current jira instance: <Server IP addr>:8099
Need to go to hostname: jira.companyname.com
Things I did: According to link: https://confluence.atlassian.com/kb/proxying-atlassian-server-applications-with-apache-http-server-mod_proxy_http-806032611.html
A. For atlassian application:
1. Stopped JIRA
2. Not using context path so ignored
3. For connector directive, In server.xml, added
proxyName="jira.companyname.com"
proxyPort="8099"
scheme="http"/>
B. For Apache HTTP server
1. mod_proxy enabled by default in Centos.
2. Configure virtual host using mod_proxy,
Since includeOptional statement present in httpd.conf, In conf.d folder created an jira-vm.conf file with following.
<VirtualHost *:80>
ServerName jira.companyname.com
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Proxy *>
Require all granted
</Proxy>
ProxyPass / http://<ip addr>:8099
ProxyPassReverse / http://<ip addr>:8099
</VirtualHost>
3. Restart apache
systemctl restart httpd.service
4. Modify CentOS SELinux policy
$ sudo /usr/sbin/setsebool -P httpd_can_network_connect 1
C. Restart JIRA.
Result:
I dont see any response on jira.company.com
On ipaddr:8099 I see my jira instance with error:
"
JIRA is reporting that it is running on the hostname 'jira.clarionus.com', which does not match the hostname used to run these diagnostics, '<ip addr>'. This is known to cause JIRA to construct URLs using the incorrect hostname, which will result in errors in the dashboard, among other issues."
Server.xml snippet:
<Connector port="8099"
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.company.com"
proxyPort="80"
scheme="http"/>
Things I have tried:
1. Restarted Jira after changing XML proxyPort to 8099 instead of 80. Result: same error. Reverted back to 80.
2. Checked if conf file is case sensitive with On and Off. Result: same error.
3. Atlassian won't help as our support expired last month. :(
What other areas should I look into?
Thank you for your time
Edit: For Solution, See my post towards the end summarizing the issues I faced.
Priyank, do you have the Apache as a proxy server imposed on you? I just went through this exercise with both Jira and Confluence (way fussier) and, after struggling for a couple of days with httpd, I threw in the towel and gave NGINX a shot.
2 hours after going down the NGINX rabbit hole, it worked. Perfectly. The configurations were a metric tonne easier to get "right". The only "gotcha" was that NGINX doesn't use cert chains quite directly. One needs to manually add in the chain to the cert file. ALSO, the way openssl creates them seems to have the cert chain in the wrong order - I had to make sure I had host -> intermediate -> root in order in the file.
Aside from that gotcha, I shall NEVER struggle with httpd again. The other bonus is that the "cookbook" examples on the Atlassian pages just... work.
Mike, Moses,
I configured NGNIX and I have discovered that there is a deeper problem to this than I first thought.
When I do an nslookup, the domain jira.companyname.com is linked to domain address 216.XX.XXX.XXX. (Accessible through outside network-Internet anywhere)
And the server IP addr that I was trying my configurations for is 10.XX.XXX.XXX (Accessible through inside company network only)
Since I was trying to link server IP addr to jira.companyname.com, it was giving me the error? This is my understanding. Correct me if I am wrong. Its still giving me the error with server IP addr and the jira.companyname.com domain.
Basically the task is "to proxy internal traffic that accesses 10.91.121.163 to Jira.companyname.com" as well as "to proxy external traffic from 216.XX.XXX.XXX to jira.companyname.com"
Not sure if I am clear enough here.
1. Will reverse proxy help me here? Or what else should I consider?
2. What Ip addr should be used in conf file? 216.XX or 10.XX because it does not work for 10.XX so far.
3. I could not find any related documentation. I am using the wrong keyword to search maybe. Can you point me in the right direction?
Your assistance helps me thoroughly.
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I'd have stayed with Apache HTTP :p - at least I am fond of it and find it pretty easy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Priyank,
Your environment is largely the same as what I have here. What I've done is ALL traffic (whether in the office or not) goes to the public IP address. This gave me a measure of security as well since I can BLOCK the Jira host IP address from direct access. The ONLY way through to the server is via the NGINX host. If I need to get directly to the server (which in your case would be the 10.x.x.x address, I actually have to be on a VPN.
I have the internal IP address simply serving via tomcat on 8080 with NGINX heading in that direction. That saves me the trouble of having to configure SSL on the internal address on Tomcat as well. One place to manage certs.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Mike,
Your idea makes sense. And in this case I still need to get the jira.companyname.com active.
But I am failing to understand how I can get the jira.companyname.com to work. I am pulling my hair but still cant seem to figure out what is the problem.
jira.companyname.com (216.x.x.x.x) still does not match the expected hostname 10.x.x.x
After adding proper lines in the .nginx.conf file as well as the server.xml file.
I am not using a context path. But I will try to follow the instructions to add context path and see if that gets me anywhere.
Thank you
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
include /etc/nginx/conf.d/*.conf;
server {
listen 80;
server_name jira.companyname.com;
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://10.x.x.x:8099;
client_max_body_size 10M;
}
}
I made these changes based on this post. In the configure NGNIX section.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Also the server.xml snippet is attached.
<!-- Nginx Proxy Connector -->
<Connector port="8099"
maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"
proxyName="jira.companyname.com"
proxyPort="80"
scheme="http"/>
<!-- Standard HTTP Connector -->
<Connector port="8082"
maxThreads="150"
minSpareThreads="25"
connectionTimeout="20000"
enableLookups="false"
maxHttpHeaderSize="8192"
protocol="HTTP/1.1"
useBodyEncodingForURI="true"
redirectPort="8443"
acceptCount="100"
disableUploadTimeout="true"/>
As per instructions in the same link.
Where should the instance for 216.x.x.x external access ipaddr be placed if anywhere?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
SO... this assumes that:
Note: mine is abstracted by having all this in containers which make it look local. If you're NOT local and have a separate NGINX server that has both internal and external NICs, your DNS for JIRA would point at the NGINX server. The "proxy_pass" directive would point at wherever tomcat is serving JIRA
The chunk in server.xml
<Connector
port="8080"
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.company.com"
proxyPort="443"
scheme="https"
/>
The nginx jira config file
server {
server_name .jira.company.com;
listen 80;
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl;
server_name .jira.company.com;
ssl_certificate /etc/nginx/certs/jira2018-chained.crt;
ssl_certificate_key /etc/nginx/certs/jira2018.key;
client_max_body_size 0;
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:8080;
}
}
Note also the server_name directive with the leading ".". That allows a match between jira.company.com OR *.jira.company.com (for test instances using the same NGINX conf
I have the following "default" config that i definitively renamed to "0.conf" to ensure it loads FIRST
# Instructions for defaults found on https://irulan.net/nginx-http-and-https-default-server/
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name _;
server_name_in_redirect off;
log_not_found off;
return 410;
}
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server ipv6only=on;
server_name _;
ssl_certificate /etc/nginx/certs/snakeoil-certificate.pem;
ssl_certificate_key /etc/nginx/certs/snakeoil-key.pem;
## To ensure old/ancient versions of Nginx to be secure and not fall victim
## to SSLv3 vulnerabilities, uncomment the following lines:
#
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_ciphers HIGH:!aNULL:!MD5;
server_name_in_redirect off;
log_not_found off;
return 410;
}
Another "gotcha" I'd had was the config order loading. It loads by natural sort order so before I changed the config name of default, it was loading in the wrong order (mostly borked confluence but I like to be definitive what loads when)
This also includes a "fake" cert in the middle for default listens. With this, things like nmap will see 80 and 443 open but will NOT, by default, see any applications listening
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So... here is what I have that seems to work. In my case, NGINX logically appears local to the Jira server. The DNS points at wherever NGINX is. If NGINX is not local to JIRA, merely change the "proxy_pass" directive to point at wherever Tomcat is serving JIRA.
My server.xml (I do NOT have the fallback port)
<Connector
port="8080"
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.company.com"
proxyPort="443"
scheme="https"
/>
NGINX Default config (file definitively named 0.conf to force loading FIRST; the config files are loaded in natural system sort order). This default also nicely obscures stuff; nmap will return ports 80 and 443 open but NOT any applications on them.
# Instructions for defaults found on https://irulan.net/nginx-http-and-https-default-server/
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name _;
server_name_in_redirect off;
log_not_found off;
return 410;
}
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server ipv6only=on;
server_name _;
ssl_certificate /etc/nginx/certs/snakeoil-certificate.pem;
ssl_certificate_key /etc/nginx/certs/snakeoil-key.pem;
## To ensure old/ancient versions of Nginx to be secure and not fall victim
## to SSLv3 vulnerabilities, uncomment the following lines:
#
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_ciphers HIGH:!aNULL:!MD5;
server_name_in_redirect off;
log_not_found off;
return 410;
}
NGINX Jira config (named jira.conf). The "." in front of the server_name argument is the special wildcard that matches the explict host name as well as *.hostname so you can use the same config for test and other environment instances.
server {
server_name .jira.company.com;
listen 80;
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl;
server_name .jira.company.com;
ssl_certificate /etc/nginx/certs/jira2018-chained.crt;
ssl_certificate_key /etc/nginx/certs/jira2018.key;
client_max_body_size 0;
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:8080;
}
}
If you need it, here is my Confluence config named confluence.conf
server {
server_name .confluence.company.com;
listen 80;
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl;
server_name .confluence.company.com;
ssl_certificate /etc/nginx/certs/confluence2018-chained.crt;
ssl_certificate_key /etc/nginx/certs/confluence2018.key;
ssl_session_timeout 5m;
ssl_protocols SSLv2 SSLv3 TLSv1 TLSv1.1 TLSv1.2;
ssl_ciphers HIGH:!aNULL:!MD5;
ssl_prefer_server_ciphers on;
location /{
client_max_body_size 0;
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:8090/;
}
location /synchrony {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:8091/synchrony;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "Upgrade";
}
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Moses Thomas, without proxy servers we'd have SO much less to talk about :P
Anyway, I posted my (sanitized) server.xml block and the 3 NGINX conf files that make JIRA and Confluence work behind my proxy server and the assumptions for the config (copied these straight out of my dev box)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Mike RathwellI wanted to also post mine but there will be no need i can see they look more the same in structure, i hope @Priyank will fix his issue with this code provided.
Best!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Moses Thomas, that was my hope that this fixes it. HOWEVER, in looking at @Priyank files, I note the include *.conf just before his configuration.
@Priyank, I got bit by almost this same thing initially and alluded to it above; the order the conf files are loaded. I had tried, as you did, to toss that config in the default.conf and just use that. It broke. SO I started with the box stock install and did the following:
This makes sure all the required stuff gets loaded by default, the obfuscation stuff gets loaded BEFORE the default so the default.conf only modifies the configuration then the jira.conf (and confluence.conf) is added on the configuration with the directives specific to each.
And this time I rooted around in my Dockerfiles, source conf files, and exec'd into my test NGINX container to look at what is RUNNING in real life to make sure I wasn't talking out my.... hat...
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Mike RathwellYou don't need to keep the confluence.conf file seperate you can add the setting in /etc/nginx.conf and /etc/nginx/conf.d/jira.conf to be compact and easy to manipulate.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Moses Thomas That is very true. In my case, however, I have this all containerized and tried to make it so only ADDing my bits discretely I get a couple of things:
I did largely the same with Jira and Confluence configs - Added ONLY variables to the setenv.sh to ADD my own JVM Opts and memory settings during build and the rest is docker entrypoint scripts that xmlstarlet changes based on environment to server.xml and dbconfig.xml files.
Also I am not smart enough to deal with more than one thing at one time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Moses Thomas, @Mike Rathwell,
Hi Guys,
Your support through this is deeply appreciated.
So I did a port scan on jira.companyname.com yesterday, I should have done it long ago. And port 80 & 443 appear closed.
So much time and effort spent and turns out the other department didn't do this before they gave me the domain name.
Well, lesson learnt.
I have emailed the team asking them to open those ports after which I can resume my testing. Hopefully today they can figure it out so I can implement the changes you guys mentioned above. I will keep you posted.
Once again, Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Moses Thomas@Mike Rathwell@Vickey Palzor Lepcha,
I was finally able to finish this task. Here is the summary of issues faced.
1. The initial issue and the reason why I created this post was because no matter what I tried, I had a port mismatch on dashboard with Apache and NGINX.
Reason was that ports were not accessible from outside.
I totally misunderstood a text from IT that instructed me to change the DMZ port and to add a new NIC to the server. After some research I was able to make this change.
2. After I was sure the changes were ok, I was still not able to access the server. Access ports on the new server were not opened by IT when they gave me the info.
After some deliberation, we rectified that and the new NIC was up and running.
3. Going back to JIRA, I updated the server address on the nginx.conf file and JIRA was accessible from the internet. Voila!!
Or so I thought, Turns out it was still not accessible from the internal network because of some routing rules that the IT folks had in place. And also this was just HTTP not HTTPS.
4. IT came back to me with updates on their policy and they opened the ports for internal access. Jira was accessible at HTTP.
I started working on the HTTPS and sent a generated cert to IT and they forwarded it to our CA.
CA came back with a cert but the download option was not available for Nginx but only Apache. I tried to fit it in just so hoping that there was no compatibility problem.
5. But no, I got Nginx cert mismatch error. After some more research I found some post on godaddy for this case. I had to concatenate the two different certs from CA into one. After this change I thought I am all set.
6. But now when I access the site on browser, I got "URL scheme 'http', which does not match the scheme used to run these diagnostics, 'https'." on the Jira dashboard.
I changed the base URL in settings which fixed the issue. But wait.
7. In chrome, by the address bar, I got "Your connection is not fully secure" prompt for HTTPS.
When I had first switched over to Nginx, the post I had followed had recommended I add a standard HTTP connector to my server.xml file along with HTTP & HTTPS. After some troubleshooting, I understood this was the issue. I commented out that instance from my server.xml and restarted Jira.
Success!! Sweet rewarding success!!
I have learnt a lot over the course of these few days that I am truly happy. And this isn't even my primary job!
Thank you all for your support.
I deeply appreciate your assistance.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I had a tough time myself when AJP was introduced with JIRA for the first time. Eventually, it has been smooth.
The take away is this - you will have quite a smooth JIRA upgrades( system admin perspective) now that you know what could get reset on server.xml file during upgrade :p
Congratulations on your learning journey - we all are learning.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@PriyankGood to get feed back from you and happy :) that you have learned and we tried to help as much as we can.
Best!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Mike Rathwell @Priyank Exactly i use nginx also and this would have been lot easier to use instead of apache i vote ngnix so may be you consider using this reverse proxy server.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
How about your ajp ? Did you enable them ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
As per PartB in this document to enable mod_proxy_ajp:
Since Centos7 has mod_proxy_ajp_proxy modules enabled by default, I did not touch that.
In the same document as per PartB, 2. Configure the virtual hosts using mod_proxy_ajp:
Here is my code snippet at the end of my httpd.conf that I added.
<VirtualHost *:80>
ServerName jira.companyname.com
ProxyRequests Off
ProxyVia Off
# ProxyPreserveHost On
<Proxy *>
Require all granted
# Order deny,allow
# Allow from all
</Proxy>
ProxyPass / http://<ipaddr>:8099
ProxyPassReverse / http://<ipaddr>:8099
# <Location />
# Require all granted
# </Location>
</VirtualHost>
I think I followed the steps as described. I tried few things with the Location tag, proxypreservehost and order allow. But ended up commenting it out as it did not help.
Thank you for your time and patience.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Did you enable it on your server.xml ?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
VIckey,
Yes I made those changes in the xml file.
<Connector port="8099"
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.company.com"
proxyPort="80"
scheme="http"/>
I added the last 3 lines of code for this purpose in this file.
Thank you for your time.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Did you uncomment the ajp connection line ? your protocol doesnt say AJP .
It should be something like this ;
<Connector port="8009" redirectPort="8443" enableLookups="false" protocol="AJP/1.3" URIEncoding="UTF-8"
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I don't think what you've shown above is for AJP
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
And your apache configurations should have something like this ;
ProxyPass / ajp://localhost:8009/
ProxyPassReverse / ajp://localhost:8009
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Vickey,
So I checked some links and there seem to be 2 ways of Proxying Atlassian server applications with Apache server. One is 'mod_proxy_http' and second on is 'mod_proxy_ajp' protocol.
Since all my efforts so far have been using mod_proxy_http, I am trying to exhaust all possibilities that come my way using this method.
If nothing works I will switch over to ajp as you recommend.
As of now like some others suggested, I am looking into NGINX in place of Apache. Hopefully that will bear some fruit.
I deeply appreciate your time and input.
Thank you.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Dang it... seems to have lost my post.
SO... here we go. This assumes that you have NGINX on your Jira host. If not, the proxy_pass directive in the below config changes to wherever Tomcat is serving Jira. Also , I did NOT put in the "fallback" port.
The DNS should point at wherever your NGINX server is running ONLY and even if it is running on a separate host. If it is a separate host from Jira, the NGINX server would then forward to the place stated in proxy_pass directive.
Server.xml
<Connector
port="8080"
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.company.com"
proxyPort="443"
scheme="https"
/>
NGINX - first the default configuration which is explicitly named 0.conf so it loads FIRST. The nice thing about this default is that something like nmap will ONLY see an open 80 and 443 but NOT return any applications by default.
# Instructions for defaults found on https://irulan.net/nginx-http-and-https-default-server/
server {
listen 80 default_server;
listen [::]:80 default_server ipv6only=on;
server_name _;
server_name_in_redirect off;
log_not_found off;
return 410;
}
server {
listen 443 ssl default_server;
listen [::]:443 ssl default_server ipv6only=on;
server_name _;
ssl_certificate /etc/nginx/certs/snakeoil-certificate.pem;
ssl_certificate_key /etc/nginx/certs/snakeoil-key.pem;
## To ensure old/ancient versions of Nginx to be secure and not fall victim
## to SSLv3 vulnerabilities, uncomment the following lines:
#
# ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
# ssl_ciphers HIGH:!aNULL:!MD5;
server_name_in_redirect off;
log_not_found off;
return 410;
}
Then the jira.conf file. The "." before the server_name is a special wildcard match for NGINX so it'll match jira.company.com or *.jira.company.com so I can use the same config for both production and test, for example
server {
server_name .jira.company.com;
listen 80;
location / {
return 301 https://$server_name$request_uri;
}
}
server {
listen 443 ssl;
server_name .jira.company.com;
ssl_certificate /etc/nginx/certs/jira2018-chained.crt;
ssl_certificate_key /etc/nginx/certs/jira2018.key;
client_max_body_size 0;
location / {
proxy_set_header X-Forwarded-Host $host;
proxy_set_header X-Forwarded-Server $host;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_pass http://localhost:8080;
}
}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Firstly do you have apache server install on the host jira is running? check ip adress
and its better to have a static address in Centos7 where Jira is running, one more thing is you DNS server able to resolve the host name where Jira is running?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Moses,
Yes Apache is installed as I get the version info on "httpd -v"
[root@srvvmjira bin]# httpd -v Server version: Apache/2.4.6 (CentOS) Server built: Apr 20 2018 18:10:38 [root@srvvmjira bin]#
And Static IP address is in use. Which I confirmed by "ifconfig"
Yes my DNS server can access <ipaddr>:8099 and can access JIRA. But it can't access jira.companyname.com so far.
Does that make sense? Or I might be confused.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For now comment ProxyReserveHost and add these two lines in proxy in <Proxy*> </Proxy> in xml proxy port should be 80 and restart jira again and see what happens?
Order deny,allow
Allow from all
Best regards,
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Moses,
I tried with the above recommendations. But it did not have any effect so far.
Here is my error log: Dashboard Diagnostics: Mismatched URL Hostname JIRA is reporting that it is running on the hostname 'jira.companyname.com', which does not match the hostname used to run these diagnostics, '<ip addr>'. This is known to cause JIRA to construct URLs using the incorrect hostname, which will result in errors in the dashboard, among other issues.
I am running apache 2.4 and as per this document,
For V2.4, I think the Proxy tag should contain Require all granted.
What might be wrong? Any other ideas?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.