Thursday, 1 September 2011

Browse » Home » » » » Gadgets do not display correctly after upgrade to JIRA 4.0

Gadgets do not display correctly after upgrade to JIRA 4.0


This issue has been resolved in JIRA 4.0.1
Atlassian recommends upgrading to JIRA 4.0.1 or later. Refer to JIRA Dashboard and Gadgets Troubleshooting.
 Expand to see archived documentation for JIRA 4.0 only

Symptoms

The following errors may appear when using gadgets:
GadgetUrlBuilder: could not parse spec at rest/gadgets/1.0/g/com.atlassian.jira.gadgets:admin-gadget/gadgets/admin-gadget.xml
2009-10-07 21:44:25,201 http-9443-Processor23 ERROR anonymous 78259x3x3 17drnf0 https://www.example.com/secure/Dashboard.jspa [renderer.internal.http.HttpClientFetcher] Unable to retrieve response
org.apache.http.conn.ConnectTimeoutException: Connect to www.example.com/100.100.100.100:443 timed out

Cause

Before displaying a dashboard, JIRA will make http requests to retrieve all the gadget specs for that dashboard. If the URL of the gadget spec is an absolute URL this error message could be a normal occurrence because the gadget spec is simply not being hosted any longer.
However if the URL is a relative URL as in the error above, JIRA is having issues retrieving gadget specs it's hosting itself. Eventually JIRA will no longer retrieve gadget specs via a HTTP request back to itself and make an API call instead. This has not been implemented as of this writing.
The problem is caused if JIRA is setup behind a proxy (such as Apache) or if there are issues with SSL certificates. Here's a detailed list of all reported configurations that can cause this problem so far:
  1. JIRA sits behind a reverse proxy or load balancer and doesn't know the URL scheme, hostname or port that it's actually being accessed on.
  2. JIRA is running under SSL with a certificate that is self-signed or signed by a CA that is not in Java's cacerts file. You will probably see a message like javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated in your log file.
  3. Apache is mapping vhosts by IP address, and the hostname used in the URL resolves to a different IP on the server than it does in the rest of the network (e.g., because it's mapped to 127.0.0.1 in /etc/hosts). The symptom here is 404s coming from Apache and Tomcat not getting hit at all when requesting gadget specs.
  4. JIRA is setup with Apache enforcing access via basic auth. When JIRA makes a request for gadget specs via apache, the request fails with 401 since JIRA doesn't handle the basic auth challenge.
  5. The JIRA server is not able to communicate with itself using the host given in the request.
    1. A user has entered an entry in the hosts file on a different machine to the JIRA server for the server machine. When a request from this machine hits the server, the server wont know how to resolve the host used in the request.
    2. The host cannot communicate with itself using the IP resovled from the request (e.g. firewall or routing configuration).
  6. JIRA is setup behind a firewall that doesn't allow outgoing requests back to itself (Shindig requests to fetch gadget specs timeout).
  7. The Gliffy Plugin for JIRA version 2.1.0 is installed. This version contains classes that conflict with JIRA 4's dashboard. An updated version 2.1.1 is available for download from the Gliffy website.
Full Size
${macroBean.alt}

Resolution

If you are using Apache, please follow the documentation about setting up JIRA with Apache exactly:
Also ensure that outgoing requests are allowed by your firewall back to JIRA itself. If you're using iptables to redirect port 80 to 8080 then also ensure that you redirect any OUTGOING requests back to port 8080:
iptables -t nat -A OUTPUT -p tcp -d a.b.c.d --dport 80 -j DNAT --to a.b.c.d:8080
If you're suffering from the hosts file problem, make an entry in the JIRA server's hosts file for the hostname your JIRA instance is using.
The basic auth problem can be solved by not enforcing basic auth for requests from JIRA back to itself. E.g. all that needs to be excluded is calls to /jira/rest. This could perhaps be further limited to only exclude requests from the server's IP:
<Location "/jira/rest">
  Satisfy Any
  Order allow,deny
  Allow from all
</Location>
 
<Location "/jira">
  AuthName "Jira"
  AuthType Basic
  AuthUserFile /etc/apache2/passwords/passwords
  require valid-user
</Location>
If you are using SSL with a self signed certificate or signed by a CA that is not in Java's cacerts file you will need to import that certificate into the java trust store (cacerts file).
For a self signed certificate
  • export the certificate to a temporary location, for example
    keytool -exportcert -alias tomcat -file /home/user1/temp/tomcat.cert
  • import the certificate to the trust store
    sudo keytool -importcert -file /home/user1/temp/tomcat.cert -alias tomcat  -keystore $JAVA_HOME/jre/lib/security/cacerts
For a CA that is not in Java's cacerts file you need to import the CA's root certificate.
Download the Dashboard Diagnostic Plugin for more detailed logs and attach them to your JIRA case.

Advertisement:

No comments:

Post a Comment

Note: only a member of this blog may post a comment.