問題

Jira 7.1.x 以降へのアップグレード後、ガジェット名が次のスクリーンショットのように __MSG_gadget.xxxxxx  と表示される。

診断

環境

• Jira 7.1.x 以降

次のいずれかの条件に該当する可能性があります。

• iptables または firewalld がパケットを 80 から 8080、または 443 から 8443 に転送するように構成されている
• Jira サーバーにて、ベース URL 経由で自身との通信が行えない (curl -v <base_url> を実行して確認)
• Jira サーバーで SSLPoke を実行し、正常な結果が返されるかどうかを確認する
• Additionally run the httpclienttest from the Jira server itself to confirm if the SSL configuration is okay, as this will verify if you're affected by  JRA-47568 - Getting issue details... STATUS
• Jira でアプリケーション リンクを設定済みだが、問題があるように見受けられる
• アウトバウンド プロキシが設定済みで、ベース URL がホワイトリストに追加されていない
• プラグインを使用して匿名アクセスを防止している
• HTTP プロキシの使用時に、HTTP コネクタにリバース プロキシ情報が不足している
• AJP コネクタの使用時に、プロキシ サーバーの ProxyPass ディレクティブに retry 要素がない
• Depending on the setup and environment, a CORS error might be happening when Jira is connecting to itself 

原因

Jira 7.1.x 以降では、ガジェットの変更が行われています。サーバーサイドの Java ではなくブラウザの JavaScript を使用して多数の図を生成するようになりました。これによってサーバー側のプロセスをブラウザにオフロードし、パフォーマンスの大幅な改善と、CPU 使用率の低減を実現しました。これには Jira の処理の変更も含まれ、変更後は Jira は自分自身に接続可能である必要があります。

ダッシュボードにアクセスすると、ガジェットは、ガジェットを生成するクライアント (ブラウザ) によって処理されるレスポンスを返します。この際、サーバーはガジェットの翻訳文字列を取得するために自分自身への接続も行います。Jira はインスタンスの接続先の URL を使用するため、Jira インスタンスは自分自身に接続可能である必要があります。

この処理が行えない場合、エラーが発生します。要因として次のものが考えられます。

• Jira の手前にあるプロキシ レイヤーでのベーシックまたは証明書認証
• ドメイン名の解決不可
• Jira が提供されている IP が、Jira が実行されているサーバーとは異なる制限つきのサブネットにある
• Jira が自己署名証明書で提供されているが、これが自身の証明書ストアに存在しない

The recommended best practice is to have Jira served on one domain name only. This can have different IPs (for example internal and external) configured by different DNS, however will only resolve to one domain. For example https://Jira.atlassian.com has an external IP of 131.103.28.11 (mapped to by external DNS) and an internal IP of 192.168.1.2 (mapped with an internal DNS). It has one certificate for that FQDN, and all users access it on that domain only.

 この問題には、環境固有の原因がある場合もあります。詳細については以降を参照してください。

ソリューション

SSL を設定済みの Jira アプリケーション

atlassian-Jira.log ファイルに次の情報が表示されます。

2016-02-26 14:22:28,843 http-bio-8443-exec-11 ERROR admin 862x395x1 m32d6k xx.xx.xx.xx /secure/MyJiraHome.jspa [c.a.g.r.internal.http.HttpClientFetcher] Unable to retrieve response
javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
	at sun.security.ssl.Alerts.getSSLException(Alerts.java:192)

原因

これは、証明書が Java の証明書ストアに信頼されない既知の問題です。

ソリューション

1. Jira が自分自身を信頼するために、Jira の SSL 証明書を自身の証明書ストアにインポートする必要があります。この問題を解決するには、「PKIX パスの構築に失敗するために SSL サービスへの接続に失敗する」ナレッジベース記事のソリューションをご確認ください。

2. また、httpclienttest の設定が、リポジトリの readme の説明に合致しているかどうかを確認します。

ポート フォワードを設定済みの Jira アプリケーション

iptables または firewalld などでポート フォワーディングを使用している環境に適用されます。

原因

80 から 8080、443 から 8443 にパケットを転送するように iptables または firewalld を構成済みの場合、ガジェット名が壊れ、__MSG_gadget.xxxxxxx として表示される可能性があります。これは、外部ソースからのパケットのみを転送するようなルールが設定されている場合に発生します。  

ソリューション

外部の IP ソースからのパケットとローカル パケットの両方のためにルールを作成する必要があります。

iptables の使用

iptables -t nat -I OUTPUT -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080

iptables -t nat -A OUTPUT -o lo -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443 

iptables -t nat -A OUTPUT -d XX.XXX.XXX.XX/32 -o lo -p tcp -m tcp --dport 80 -j DNAT --to-destination XX.XXX.XXX.XX:8080
iptables -t nat -A OUTPUT -d XX.XXX.XXX.XX/32 -o lo -p tcp -m tcp --dport 443 -j DNAT --to-destination XX.XXX.XXX.XX:8443

Firewalld の使用

ファイアウォール ゾーンの外部ポート フォワーディングを構成します。

</description>
  <service name="dhcpv6-client"/>
  <service name="ssh"/>
  <service name="http"/>
  <service name="https"/>
  <port protocol="tcp" port="80"/>
  <port protocol="tcp" port="443"/>
  <port protocol="tcp" port="8080"/>
  <port protocol="tcp" port="8443"/>
  <forward-port to-port="8443" protocol="tcp" port="443"/>
  <forward-port to-port="8080" protocol="tcp" port="80"/>
</zone>

ローカル トラフィック用に追加の転送ルールを作成します。

firewall-cmd --permanent --direct --add-rule ipv4 nat OUTPUT 0 -p tcp -o lo --dport 80 -j REDIRECT --to-ports 8080
firewall-cmd --permanent --direct --add-rule ipv4 nat OUTPUT 0 -p tcp -o lo --dport 443 -j REDIRECT --to-ports 8443

アプリケーション リンクが壊れている Jira アプリケーション

atlassian-Jira.log ファイルに次の情報が表示されます。

2016-02-26 13:48:12,564 http-nio-2186-exec-23 ERROR      [o.a.c.c.C.[.[localhost].[/JSP-262186].[servlet-module-container-servlet]] Servlet.service() for servlet [servlet-module-container-servlet] in context with path [/JSP-262186] threw exception
com.atlassian.templaterenderer.RenderingException: org.apache.velocity.exception.MethodInvocationException: 
Invocation of method 'getText' in  class com.sun.proxy.$Proxy12830 threw exception java.lang.NullPointerException at com/atlassian/applinks/oauth/auth/outbound_nonapplinks.vm[line 52, column 44]
	at com.atlassian.templaterenderer.velocity.one.six.internal.VelocityTemplateRendererImpl.render(VelocityTemplateRendererImpl.java:109)
	at sun.reflect.GeneratedMethodAccessor1986.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	...
Caused by: org.apache.velocity.exception.MethodInvocationException: Invocation of method 'getText' in  class com.sun.proxy.$Proxy12830 threw exception java.lang.NullPointerException at com/atlassian/applinks/oauth/auth/outbound_nonapplinks.vm[line 52, column 44]
	at org.apache.velocity.runtime.parser.node.ASTMethod.handleInvocationException(ASTMethod.java:337)
	at org.apache.velocity.runtime.parser.node.ASTMethod.execute(ASTMethod.java:284)
	at org.apache.velocity.runtime.parser.node.ASTReference.execute(ASTReference.java:262)
	at org.apache.velocity.runtime.parser.node.ASTReference.render(ASTReference.java:342)
	at org.apache.velocity.runtime.parser.node.SimpleNode.render(SimpleNode.java:336)
	at org.apache.velocity.Template.merge(Template.java:235)
	at com.atlassian.templaterenderer.velocity.one.six.internal.VelocityTemplateRendererImpl.render(VelocityTemplateRendererImpl.java:100)
	... 234 more
Caused by: java.lang.NullPointerException
	at com.atlassian.Jira.i18n.AbstractI18nResolver.getText(AbstractI18nResolver.java:24)
	at sun.reflect.GeneratedMethodAccessor1918.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	...

原因

Jira で設定されているアプリケーション リンクが壊れている可能性があります。壊れたアプリケーション リンクとは、ほかのアプリケーションにリンクされたアプリケーション (Confluence など) が動作せず、そこへのアクセスも行えないことを意味します。原因には、ネットワークの問題、オフラインのアプリケーション、アプリケーション リンク設定の破損などが含まれます。また、信頼済みの証明書が存在しないときにアプリケーション リンクを確立しようとして適切に作成できなかった可能性もあります。

壊れたアプリケーション リンクを確認するには、[管理] > [アプリケーション] > [アプリケーション リンク] に移動し、次のようにオフラインとして表示されているリンクがないかどうかを確認します。

管理者としてログインしているときに「G」と 2 回入力して、管理者用の検索ボックスに「アプリケーション リンク」と入力することもできいます。

壊れたアプリケーション リンクを修復する方法については、「アプリケーション リンクのトラブルシューティング ガイド」もご参照ください。

ソリューション

アプリケーション リンクを削除して再作成するか、「アプリケーション リンクのトラブルシューティング ガイド」の手順に従い、壊れたアプリケーション リンクを修復します。

 プロキシ設定が壊れている Jira アプリケーション

原因

Web プロキシが Jira サーバーを適切に解決できないため、Jira が自分自身に接続できない。

ソリューション

「Jira アプリケーションでアウトバウンド HTTP / HTTPS プロキシを設定する方法」に従い、-Dhttp.nonProxyHosts および -Dhttps.nonProxyHosts 引数に Jira サーバーのホスト名を追加します。

Apache Web Server と AJP Connector を使用している Jira アプリケーション

診断

プロキシ ログに次のようなメッセージが表示される場合があります。

[Sat Feb 23 15:08:42.168550 2019] [proxy:error] [pid 22708:tid 140608035321600] AH00940: AJP: disabled connection for (x.x.x.x)
[Sat Feb 23 15:08:46.079259 2019] [proxy:error] [pid 22710:tid 140608060499712] (111) Connection refused: AH00957: AJP: attempt to connect to x.x.x.x:8009 (x.x.x.x) failed
[Sat Feb 23 15:08:46.079298 2019] [proxy:error] [pid 22710:tid 140608060499712] AH00959: ap_proxy_connect_backend disabling worker for (x.x.x.x) for 60s

原因

リバース プロキシと Jira との通信でエラーが発生した場合 (特にリモート マシンにある場合)、バックエンドのワーカーが無効化され、以降のコネクションで中断が発生する場合があります。

ソリューション

proxyPass ディレクティブに retry=0 を追加することで、この問題の発生頻度を減らせる場合があります。

<Location />
  ProxyPass / ajp://localhost:8009/ retry=0
  ProxyPassReverse / ajp://localhost:8009/ retry=0
</Location>

変更を適用するには Apache を再起動します。

Jira の手前に Web プロキシが設定されていて、ベーシック認証によるパスワード制限が適用されている

原因

Web プロキシが認証を要求しているため、Jira が自分自身に接続できない。

不具合として次のチケットが起票されています。 JRA-61273 - Getting issue details... STATUS

Apache の場合の解決方法

パスワードなしのアクセスを許可するようにサーバー自身の IP を追加します。

Order Allow,Deny
Allow from <hostname>
Satisfy Any

IIS の場合の解決方法

[Basic authentication] または [Integrated Windows authentication] の代わりに [Anonymous access] を使用します。詳細な手順については、「Jira アプリケーションを IIS と連携する」ドキュメントのトラブルシューティング セクションをご確認ください。

Shibboleth の場合の解決方法

Shibboleth 認証を使用している場合、次の手順を実行します。

1. /rest URL を Shibboleth 認証の外部に設定します。
2. /rest URL は Shibboleth の保護対象外である必要があります。
3. 例:

<LocationMatch "^(/rest)/[^/]+">
AuthType None
Require all granted
</LocationMatch>

<LocationMatch "/">
AuthType Shibboleth
ShibRequireSession On
require valid-user
ShibUseEnvironment On
Order allow,deny
Allow from all
</LocationMatch>

Jira で匿名リクエストがブロックされている

原因

既知の原因として、すべての匿名リクエストをブロックする Prevent Anonymous Access プラグインを Jira が使用している場合があります。これは /rest/gadgets/1.0/g/messagebundle... へのリクエストをブロックするため、Jira はガジェット名を表示できなくなります。

ソリューション

上述のプラグインには、ホワイトリスト ページが付属します。次のエンドポイントをホワイトリストに追加することで、Jira でガジェット名を適切に取得できます。

/rest/gadgets/1.0/g/messagebundle.+

Web Fragment Finder アプリ

原因

LittleProxy が com.wittified.webfragment-finder とやり取りしようとしている内容のログが記録されます。これは Web Fragment Finder アドオンのものです。

2017-04-14 06:42:16,602 LittleProxy-ClientToProxyWorker-0 WARN b757 758x82771x1 dh8gtn 62.153.237.114 /rest/plugins/1.0/com.wittified.webfragment-finder-key [i.netty.channel.ChannelInitializer] Failed to initialize a channel. Closing: [id: 0x3e6311c8, /127.0.0.1:33660 => /127.0.0.1:8888]
2017-04-14 06:42:16,602 LittleProxy-ClientToProxyWorker-1 WARN b757 758x82771x1 dh8gtn 62.153.237.114 /rest/plugins/1.0/com.wittified.webfragment-finder-key [i.netty.channel.ChannelInitializer] Failed to initialize a channel. Closing: [id: 0x9b85bea9, /127.0.0.1:33662 => /127.0.0.1:8888]

ソリューション

1. Web Fragment Finder アドオンを無効化します。
2. Jira を再起動します。

SAN を使用する SSL 証明書

JIra 7.4 以降で、Jira が SAN を使用した SSL で実行されている場合に該当します。

原因

Apache HttpClient の不具合により、Jira が自分自身との接続に失敗する。次のエラーがログに表示される。

2017-10-10 17:04:06,623 HealthCheck:thread-5 ERROR ServiceRunner     [c.a.t.j.healthcheck.support.BaseUrlHealthCheck] An error occurred when performing the Base URL healthcheck:
java.lang.ClassCastException: [B cannot be cast to java.lang.String
    at org.apache.http.conn.ssl.DefaultHostnameVerifier.getSubjectAltNames(DefaultHostnameVerifier.java:309)

回避策

1. SAN を使用しない SSL 証明書を一時的に使用します。
2. JIra を一時的に HTTP で実行します。

CORS errors when connecting 

Depending on how your environment is set up, a CORS error could be happening.

原因

Jira fails to communicate with itself due to CORS verifications failing. 

1.  Enable HTTP debugging to identify what's failing during the HTTP request Jira is doing when trying to load the gadget's name;
   1. Go to *Cog > System > Logging and Profiling*
   2. Click on "Configure logging level for another package"
   3. Enter {{org.apache.http}} for the Package name → Set Logging Level to *DEBUG* → *Add*
   4. Start monitoring the {{$jira-home/log/atlassian-jira.log}} file;

   5. Now, reload Jira dashboard and go to add a gadget. Keep an eye on the log file for a line starting with /rest/config/1.0/directoryitems/local.json, as in the example below:

      2023-11-01 11:20:12,042-0300 http-nio-8941-exec-2 DEBUG admin 680x402x2 aoiost 0:0:0:0:0:0:0:1 /rest/config/1.0/directoryitems/local.json [o.apache.http.headers] http-outgoing-169 << HTTP/1.1 200 
      2023-11-01 11:20:12,042-0300 http-nio-8941-exec-2 DEBUG admin 680x402x2 aoiost 0:0:0:0:0:0:0:1 /rest/config/1.0/directoryitems/local.json [o.apache.http.headers] http-outgoing-169 << X-AREQUESTID: 680x426x2

If CORS errors are happening, you should see some lines similar to:

2023-11-16 10:32:48,232+0000 http-nio-8080-exec-7 WARN MYUSERID 632x11278x1 67wlxl [JIRAIP] /rest/config/1.0/directoryitems/local.json [c.a.g.r.internal.http.HttpClientFetcher] A request to [THIS-IS-THE-URL]/rest/gadgets/1.0/g/messagebundle/und/gadget.common%2Cgadget.resolutiontime has been denied. To allow requests to this URL add the application URL to your whitelist (http://confluence.atlassian.com/x/KQfCDQ).

回避策

1. In Jira, go to Cog > System > Allowlist
2. On "Type", select "Wildcard expression", and on expression try the following expression, making sure to replace with the same exact URL that you are seeing on the example above, in the "THIS-IS-THE-URL" section:
   • THIS-IS-THE-URL/*
     • Example: http://myJiraInstance.com:8080/*
   • Check "Allow Incoming"
   • Check "Allow anonymous users"
3. Try refreshing the dashboard and see if the gadget's names are rendered now