Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

gadget.common.error.500 LAN DNS no https

Vincent Brandon
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 2, 2019

Hi All,

Just launched self-hosted Jira instance.  Get gadget.common.error.500 on the project summary page when I access the site from via the DNS route I set up, but not when I use the virtual machine IP address.

Setup (ips changed for security reasons):

VM Ubuntu 18.02-LTS Server with .bin installation of Jira/Confluence (10.0.0.2 for example)

VM Windows Server 2016 running DNS Server (10.0.0.3 for example).

--DNS ResourceRecordA -name jira.company.local -IPv4Address 10.0.0.2

 

*Recreating Problem:

In Jira, set baseURL to jira.company.local or jira.company.local:8080 and access via browser address <jira.company.local:8080> (see note, jira.company.local port forward not working)

-Site works fine besides the gadget problem.

In Jira, set baseURL to 10.0.0.2 or 10.0.0.2:8080 and access via browser address <jira.company.local:8080> (see note, jira.company.local port forward not working)

-Site works fine besides the gadget problem.

 

*Temporarily solving problem:

In Jira, set baseURL to 10.0.0.2 or 10.0.0.2:8080 and access via browser address <10.0.0.2:8080> (see note, 10.0.0.2 80 to 8080 port forward not working)

 

**Couple problems also arise

Port forwarding in the Tomcat server doesn't seem to be working.  I must create shortcuts for LAN users using :8080 port (Jira) or :8090 (Confluence).  Maybe I need to set explicit traffic redirection in Ubuntu?

 

When accessing via jira.company.local, some features don't work (adding comment gives stream error)

***Notes

https has NOT been enabled yet while testing.  No certificate present. 

1 answer

1 accepted

0 votes
Answer accepted
Shankar Asam {Appfire}
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 3, 2019

Hi Vincent,

Since you do not have a port forwarding and there is no proxy or web server in front of your JIRA and Confluence application servers, the best way is to set up base URL for JIRA as,

http://jira.company.local:8080

This way the incoming requests will hit your application server on the respective port (i.e 8080). I understand with this in place, the site works fine besides the gadget problem. You may have to now conquer the issues with gadgets. Check the logs and see what errors are throwing with respect to gadgets.

Do the application links set up correctly and working between JIRA / Confluence? Please see below link for further help.

https://confluence.atlassian.com/jirakb/gadgets-do-not-display-when-failing-to-access-xml-specification-218276785.html?_ga=2.35224804.43490080.1551681131-481060825.1546420234

 

thanks

Vincent Brandon
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 4, 2019

I think, since the gadgets use a REST API, we just need to enable reverse lookups on company.local and the gadgets should work.  

Confluence would not talk to Jira or vice versa via lookup using LAN IP addresses or fqdn.  They are hosted on the same VM, though (so same IP).  What did work was localhost:8080, localhost:8090 (127.0.0.1:8080 and 127.0.0.1:8090).  

We have multiple intranet web applications.  We'll examine a few options. 

One, I think, is having windows server portproxy all traffic to jira.company.local:80 to jira.company.local:8080 and confluence.company.local:8090.  Not super excited about that as windows portproxy doesn't have an allowupdate parameter, but that's ok.  Should be static for our use case.

Another is adjusting IP tables in the ubuntu VM hosting the application:

iptables -t nat -A OUTPUT -o lo -p tcp --dport 80 -j REDIRECT --to-port 8080

 But, then I can't host both applications on the same VM.  This is Ok... but I really don't want to deal with two databases for effectively the same package.  So we'll need spin up ANOTHER container to run postgresql.  I'm hoping I can figure out portproxy or create some kind of inner redirect.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events