Jira サーバーでガジェット名が __MSG_gadget と表示される問題を修正する

関連コンテンツ

  • 関連コンテンツがありません

お困りですか?

アトラシアン コミュニティをご利用ください。

コミュニティに質問

プラットフォームについて: Server と Data Center のみ - この記事は、サーバーおよびデータセンター プラットフォームのアトラシアン製品にのみ適用されます。

問題

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 を実行し、正常な結果が返されるかどうかを確認する
  • Jira サーバーで httpclienttest を実行して、SSL 設定が適切かどうか、および JRA-47568 - Getting issue details... STATUS の影響を受けていないかどうかを確認する
  • Jira でアプリケーション リンクを設定済みだが、問題があるように見受けられる
  • アウトバウンド プロキシが設定済みで、ベース URL がホワイトリストに追加されていない
  • プラグインを使用して匿名アクセスを防止している
  • HTTP プロキシの使用時に、HTTP コネクタにリバース プロキシ情報が不足している
  • AJP コネクタの使用時に、プロキシ サーバーの ProxyPass ディレクティブに retry 要素がない

原因

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

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

プロキシを使用しない場合

  1. ユーザーはダッシュボードのロード時に Jira にリクエストを送信します
  2. Jira はガジェットの URL 経由で自分自身への呼び出しを行います
  3. Jira は完了したページとガジェットの翻訳文字列を返します
プロキシを使用する場合

1. ユーザーはダッシュボードのロード時に Jira にリクエストを送信します
2. プロキシはこのリクエストを Jira に転送します
3. Jira はガジェット名を取得するためにガジェット URL 経由で自分自身へのコールバックを行い、プロキシへのリクエストを行い余す
4. プロキシはガジェットの翻訳文字列を提供するため、このリクエストを Jira に戻します
5. Jira はガジェットの翻訳文字列をプロキシに応答します
6. プロキシはこれを Jira に転送します
7. Jira は完了したページをプロキシに応答します
8. プロキシはこれをユーザーに転送します

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

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

推奨されるベスト プラクティスは、Jira を 1 つのドメイン名でのみ提供することです。複数の DNS 異なる IP アドレス (例: 外部および内部用) を設定した場合も、1 つのドメインに解決するようにします。たとえば、https://jira.atlassian.com は、外部 IP 131.103.28.11 (外部 DNS でマッピング) と内部 IP 192.168.1.2 (内部 DNS でマッピング) を持ちます。この FQDN については 1 つの証明書のみが設定されており、すべてのユーザーはこのドメインでのみアクセスします。

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

ソリューション

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 の証明書ストアに信頼されない既知の問題です。

証明書でSNI を使用している場合、次のリンクで追跡されているオープンな不具合の影響を受ける可能性があります。 JRA-47568 - Getting issue details... STATUS Jira の今後のリリースでこの不具合の修正が予定されています。現時点では、この課題のもっともシンプルな回避策は、Jira インスタンスで非 SNI の SSL 証明書を使用することです。この不具合の影響を受けているかどうかを確認するには、httpclienttest を、以降でリンクを紹介している SSLPoke ツールと組み合わせて使用します。SSLPoke テストがエラーなしで完了するが、httpclienttest で例外が報告される場合、この不具合の影響を受けています。


ソリューション

  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
 -A OUTPUT -o lo -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 8443 
-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
-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

XX.XXX.XXX.XX を宛先の IP アドレスで置き換えます。

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

このページで説明しているほかのテスト (SSLPoke など) には成功している場合があります。AJP はコネクタを超えてプロキシ情報を提供するため、プロキシ パラメータは必須ではありません。

原因

リバース プロキシと 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.+

Jira の再起動が必要です


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 で実行します。

この問題の完全な修正については、 JRASERVER-65595 - Getting issue details... STATUS をウォッチしてください。



説明After upgrading to Jira 7.1.x+, gadget titles appear as __MSG_gadget.xxxxxx
製品Jira
プラットフォームサーバー
最終更新日 2020 年 1 月 8 日

この内容はお役に立ちましたか?

はい
いいえ
この記事についてのフィードバックを送信する

関連コンテンツ

  • 関連コンテンツがありません
Powered by Confluence and Scroll Viewport.