Jira server Base URL health check fails

お困りですか?

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

コミュニティに質問

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

問題

The Base URL Health Check verifies if JIRA is able to access its own Base URL. Starting in JIRA 7.1, gadgets charts are generated using Javascript in the browser rather than server-side with Java. This had significant performance improvements as the server was offloading processing to the browsers and resulted in less CPU usage. Part of the change modified the way JIRA previously operated, and now it is required that the server can connect to itself.

影響

After upgrading to JIRA 7.1 or newer versions, gadget titles start showing as __MSG_gadget.xxxxxxx, __MSG_gadget.activity., __MSG_gadget.filter, _MSG_gadget.project.title_  and so on as per the example below:

例:

結果の確認

アイコン
結果
What this means

JIRA is able to access itself through the configured Base URL

Your dashboard gadgets should be generated and loaded correctly.

JIRA is not able to access itself through the configured Base URL. This is necessary so that dashboard gadgets can be generated successfully. Please verify the current Base URL and if necessary, review your network configurations to resolve the problem

Your dashboard gadgets may not be loading properly. Please follow the diagnosis and resolution steps below to resolve the problem.

診断

環境

  • Affects JIRA 7.1.x instances.
  • iptables80 から 8080、443 から 8443 にパケットを転送するよう設定されている
  • From the JIRA server itself, try curl -v <baseurl> to verify if JIRA is able to communicate with itself.
  • Run SSLPoke from the JIRA server itself and see if it returns successfully.
  • 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 .
  • There are application links configured on the instance but they seem to be having some issue.
  • As the symptoms for both environments are different, diagnosis and resolution steps are segregated into multiple sections below.

When accessing the Dashboard, the gadgets serves a response which is processed by the client (ie the browser) to generate gadgets. Whilst this happens, the server also connects to itself to provide the gadget's translated strings. JIRA uses the URL the instance is connected to, so the JIRA instance needs to be able to access itself.


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

  1. ユーザーはダッシュボードのロード時に Jira にリクエストを送信します
  2. JIRA will perform a call towards itself, through the gadget URL.
  3. JIRA reply with the completed page + gadget's translated strings
プロキシを使用する場合


1. User sends request towards JIRA on loading the Dashboard
2. Proxy forwarded this request to JIRA
3. JIRA will perform a call back to itself through the gadget URL to get the gadget's title. Performing request to Proxy
4. Proxy forwarded this request back to JIRA itself to provide the gadget's translated strings
5. JIRA replies gadget's translated strings to proxy
6. Proxy forwarded this accordingly to JIRA
7. JIRA replies with the completed page to proxy
8. Proxy forwarded this accordingly to use


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

  • Jira の手前にあるプロキシ レイヤーでのベーシックまたは証明書認証
  • ドメイン名の解決不可
  • Jira が提供されている IP が、Jira が実行されているサーバーとは異なる制限つきのサブネットにある
  • Jira が自己署名証明書で提供されているが、これが自身の証明書ストアに存在しない
  • There are more than 3 redirects between the entry point and the final JIRA server (this is tested in the base URL check and also configured in our gadgets).

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.

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


ソリューション

Cause 1: Jira applications with SSL Configured

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)Cause


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

If using SNI on the certificate, we have an open bug for this being tracked under JRA-47568 - Getting issue details... STATUS . A fix for this bug is present in JIRA Core 7.1.6 and above. Currently the most simple workaround for this issue is to use a non-SNI SSL certificate for your JIRA instance. You can confirm if you are affected by this bug by using httpclienttest in conjunction with the SSLPoke tool linked below. If theSSLPoke test works without error and thehttpclienttest reports an exception, you are experiencing the bug as above.

ソリューション

  1. Follow our instructions in our Unable to connect to SSL services due to "PKIX Path Building Failed" error knowledge base article to resolve the problem.
  2. Additionally verify the configuration with httpclienttest as described in the readme of that repository.


Cause 2: JIRA Applications with port forwarding configured

iptables などでポート フォワードを使用している環境に適用されます。

原因

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

解決状況:

You need to create a rule both for packets coming froman external IP sourcesAND for local packets eg.

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

Cause 3: Jira applications with a broken Proxy configuration

Applies to environments configured to use a Web Proxy. This can be determined by checking the "JVM Arguments" in the atlassian-jira.logforan existing proxy configurations.

原因

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

ソリューション

Add the JIRA Server's hostname to the -Dhttp.nonProxyHosts and -Dhttps.nonProxyHosts arguments as in Configure an outbound proxy for use in Jira server.

Make sure that the same domain is not being mentioned twice in an argument, e.g. - Dhttps .nonProxyHosts = jira|confluence|jira


Cause 4: JIRA configured with Apache in front with BasicAuth password restriction

原因

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

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

ソリューション

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

Order Allow,Deny
Allow from <hostname>
Satisfy Any

ソリューション 2

If using Shibbolethauthentication ,

  1. leave the /rest URLs outside theshibbolethauthentication.
  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>
説明The Base URL Health Check verifies if JIRA is able to access its own Base URL. Starting in JIRA 7.1, gadgets charts are generated using Javascript in the browser rather than server-side with Java. This had significant performance improvements as the server was offloading processing to the browsers and resulted in less CPU usage. Part of the change modified the way JIRA previously operated, and now it is required that the server can connect to itself.
製品Jira
プラットフォームServer, Data Center

最終更新日 2019 年 9 月 25 日

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

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.