back to all blogsすべてのブログ投稿を表示

Open Liberty 23.0.0.2でのデータベース接続のテストとサーバー停止タイムアウトの設定

image of author image of author
Michal Broz and 浅田 かおり (翻訳) 2023年3月26日
他言語版へのリンク: English ,

Open Liberty 23.0.0.2 では、Admin Center Server Config ツールでデータベース接続をテストする新しいフィーチャーが導入されました。server stopコマンドに、サーバーが停止するまでの最大待機時間を指定するための-timeoutオプションが追加されました。このリリースでは、Jakarta RESTful Web Services 3.0フィーチャーのCVEに対処したものを含む、多くの重要なバグ修正も提供します。

In Open Liberty 23.0.0.2:

ランタイムに追加された新フィーチャーと一緒にガイドの更新を作成しました。

修正された主なバグリストは23.0.0.2からご確認いただけます。

23.0.0.2を使ってアプリを実行する

Mavenを使う時には下記の設定をお使いください。

<dependency>
    <groupId>io.openliberty</groupId>
    <artifactId>openliberty-runtime</artifactId>
    <version>23.0.0.2</version>
    <type>zip</type>
</dependency>

Gradleの場合はこちらです。

dependencies {
    libertyRuntime group: 'io.openliberty', name: 'openliberty-runtime', version: '[23.0.0.2,)'
}

Dockerの場合はこちらです。

FROM open-liberty

またはダウンロード・ページをご参照ください。

Stack Overflowで質問する

Admin Centerを使用してデータベース接続をテストする

データベース接続をテストする簡単な方法をお探しですか?このリリースでは、Liberty Admin Centerのフィーチャーを使用して、接続を検証できるようになりました。接続テストは、アプリケーションと同じコードパスを実行するため、サーバー構成に確信を持つことができます。Admin Centerの接続検証フィーチャーはREST APIsによるOpen Libertyアプリのデータベース接続テストで紹介した同じREST APIsで有効です。

データベース接続テストを有効にするには、サーバー構成に以下の最低限必要なフィーチャーのセットを用意する必要があります。

    <feature>adminCenter-1.0</feature>
    <feature>restConnector-2.0</feature>
    <feature>mpOpenApi-3.0</feature>

この例では mpOpenApi-3.0 フィーチャーを使用していますが、他のフィーチャーと互換性のある任意の MicroProfile OpenAPI バージョンを使用することができます。

例として、まずサーバーリソース DefaultDataSource をテストします。このリソースは、認証エイリアスを使用したコンテナ認証を使用してDerbyデータベースに接続するように構成されています。

以下のサンプル server.xml ファイルは、Admin Center のテスト接続フィーチャーを設定し、Derby データベースへの接続を設定するフィーチャーを有効にします。

<server description="new server">

    <!-- Enable features -->
    <featureManager>
        <feature>adminCenter-1.0</feature>
        <feature>restConnector-2.0</feature>
        <feature>jdbc-4.3</feature>
        <feature>mpOpenApi-3.0</feature>
    </featureManager>

    <!--リモートクライアントからこのサーバーにアクセスするには、次の要素にhost属性を追加してください 例:host="*" -->
    <httpEndpoint id="defaultHttpEndpoint" httpPort="9080" httpsPort="9443"/>

    <library id="derby">
      <file name="${server.config.dir}/derby/derby.jar"/>
    </library>

    <dataSource id="DefaultDataSource">
      <jdbcDriver libraryRef="derby"/>
      <!-- インメモリDerby Embeddedデータベースを参照するプロパティ例 -->
      <properties.derby.embedded databaseName="memory:defaultdb" createDatabase="create"/>
    </dataSource>

    <authData id="myAuth" user="dbuser" password="dbpass"/>

    <!-- デフォルトのSSL設定により、Javaランタイムのデフォルト証明書を信頼することが可能 -->
    <ssl id="defaultSSLConfig" trustDefaultCerts="true"/>

    <remoteFileAccess>
       <writeDir>${server.config.dir}</writeDir>
    </remoteFileAccess>

    <basicRegistry id="basic">
       <user name="admin" password="adminpwd"/>
    </basicRegistry>

    <!-- 管理者に「admin」を割り当てる -->
    <administrator-role>
        <user>admin</user>
    </administrator-role>

</server>

この server.xml の例では、Derby JAR をサーバー設定に追加するか、独自のデータベース設定を使用する必要があります。

  1. サンプルの server.xml ファイルを参考に Liberty サーバを設定し、サーバを起動します。サーバーが起動したら、ログを確認して、Admin Center に移動するための URL を見つけることができます。前の例では、https://localhost:9443/adminCenter/ URL を使用して Admin Center に移動することができます。

  2. Admin Center UI で、Server Config ツールを選択します。

    Server Config Tool
  3. 編集する server.xml を選択します。

    server.xml
  4. Design > Server メニューで、テストしたいリソースに移動し、Test** ボタンをクリックします。

    リソースを選択
  5. アプリケーションが使用する認証の種類を選択します。

    • コンテナ認証を使用するアプリケーションでは、コンテナ認証タブを選択し、デフォルト認証を使用するか、認証エイリアスを指定するか、ログインモジュール構成を選択するかを選択します。

      この例では、`dataSource`要素にデフォルトの認証を指定したり、ログインモジュールを設定するような構成にはなっていません。したがって、ドロップダウン・フィールドを使用して認証エイリアスを指定する必要があります。

      コンテナ認証
    • アプリケーション認証を使用するアプリケーションでは、アプリケーション認証タブを選択し、データベースリソースの有効なユーザー名とパスワードを入力します。

      アプリケーション認証
    • アプリケーションがリソース参照を使用しない場合、server.xmlconnectionManager elementを選択し、No resource referenceタブを選択し、データベースリソースの有効なユーザー名とパスワードを入力します。

    リソース参照なし
  6. Connection Testボタンをクリックすると、テストが実行され、結果が表示されます。 次の例は、接続テストに成功した例です。

接続テストに成功した例

さらにJava Database Connectivityに加えて、Jakartaコネクター, JakartaメッセージングCloudant Integrationリソースへのテスト接続も可能です。

GUIによるLibertyの管理については、Admin CenterでOpen Libertyを管理するドキュメントをご参照ください。

サーバーが停止するまでの待ち時間を指定する

Open Liberty 23.0.0.2 では、server stop コマンドに --timeout コマンドラインオプションが追加されました。 このオプションを使用すると、server stop コマンドがサーバーが停止したことを確認するために待機する最大時間を指定することができます。

今回のアップデート以前は、デフォルトの最大待機時間である30秒を調整することができませんでした。

タイムアウト値は分単位(m)、秒単位(s)、またはその両方を組み合わせて指定することができます。 単位が指定されない場合、デフォルトである秒が使用されます。 分と秒は組み合わせることができ、例えば 2m30s は2分30秒を意味します。

   ./server stop                   // 30 seconds
   ./server stop --timeout=45      // 45 seconds
   ./server stop --timeout=45s     // 45 seconds
   ./server stop --timeout=3m20s   // 3 minutes, 20 seconds

タイムアウト値のデフォルトは30秒です。サーバーの停止に常に30秒以上かかる場合は、-timeoutオプションを使用してタイムアウト値を増やすことを検討してください。

詳細はserver stop commandドキュメントをご参照ください。

本リリースにおけるセキュリティ脆弱性(CVE)修正

CVE CVSSスコア 脆弱性評価 影響を受けるバージョン ノート

CVE-2022-45787

5.5

Information disclosure

21.0.0.12 - 23.0.0.1

restfulWS-3.0 フィーチャーに影響あり

過去のセキュリティ脆弱性の修正のリストについては、Security vulnerability (CVE) listをご参照ください。

主なバグ修正

以下のセクションでは、このリリースで修正したバグの一部について説明します。興味がある場合はfull list of bugs fixed in 23.0.0.2をご参照ください。

  • サーブレット・フィーチャーの競合により、サーバーの起動に失敗する

    featureUtility installFeatureコマンドでEE7またはEE8の機能セットを個別にインストールする場合、以下の例のようにサーブレット・フィーチャーでの競合によりサーバー起動できない場合があります。

    com.ibm.ws.kernel.feature.internal.FeatureManager            E CWWKF0033E: The singleton features servlet-3.1 and servlet-3.0 cannot be loaded at the same time.  The configured features servlet-3.1 and apiDiscovery-1.0 include one or more features that cause the conflict. Your configuration is not supported; update server.xml to remove incompatible features.
    com.ibm.ws.logging.internal.impl.IncidentImpl                I FFDC1015I: An FFDC Incident has been created: "java.lang.IllegalArgumentException: Unable to load conflicting versions of features "com.ibm.websphere.appserver.servlet-3.1" and "com.ibm.websphere.appserver.servlet-3.0".  The feature dependency chains that led to the conflict are: com.ibm.websphere.appserver.servlet-3.1 and com.ibm.websphere.appserver.apiDiscovery-1.0 -> com.ibm.websphere.appserver.restHandler-1.0 -> io.openliberty.restHandler.internal-1.0 -> io.openliberty.webBundleSecurity.internal-1.0 -> io.openliberty.servlet.internal-3.0 -> com.ibm.websphere.appserver.servlet-3.0

    代わりにfeatureUtility installServerFeaturesコマンドを使用するとこの問題は発生しません。また、Jakarta EE 8の機能を使用する場合は、`mpJwt-1.2`フィーチャーをインストールすることで回避することができます。

    この問題は解決され、`featureUtility installFeature`コマンドは、すべての機能を`server.xml`に含めることができるようにインストールし、サーバーを正しく起動することができるようになりました。

  • アプリケーション停止時にManaged Executor ServicesからScheduled Futuresがリソースをリークする

    ManagedScheduledExecutorServiceImpl`の`futures`キューは、スケジュールされたフューチャーの参照を保持し、それが完了した後でも保持します。

    キューは、新しいタスクがスケジュールされると、プライベートな purgeFutures() メソッドによって定期的にクリーニングされますが、それ以外は積極的に削除されることはありませんし、アプリケーションがシャットダウンしたときにも呼ばれません。purgeFutures()`はプライベートなので、アプリケーションが自分自身で呼び出すことはできません。

    この問題は解決され、アプリケーションの停止時にリソースが自動的に解放されるようになりました。

  • HTTPヘッダー名の検証

    バグにより、HTTPリクエストで無効な文字がないかチェックされていませんでした。

    この問題は解決され、無効な文字を含むHTTPリクエストは、HTTPレスポンスに`400`レスポンスコードが含まれるようになりました。

  • DoNotAllowDuplicateSetCookies httpチャネル設定オプションが動作しない

    HTTPチャネルの設定プロパティ DoNotAllowDuplicateSetCookies=true を設定しても、HTTPレスポンスで重複した Set-Cookie クッキーを許可します。

    この問題は解決され、DoNotAllowDuplicateSetCookies=true`が設定されている場合、レスポンスヘッダーには重複した Set-Cookie のクッキーが含まれないようになりました。

  • batch-1.0、2.0を設定してもbatch-2.1の機能コンテンツは有効です

    ベータ版の batch-2.1 機能の一部として追加されたコンテンツは、ユーザーがbatch-1.0もしくは batch-2.0としてサーバーを設定しても読み込まれて有効になります。これは意図的ではなく、ユーザーの環境に応じてコンフリクトが発生する可能性があります。

    この問題は解決され、新しい batch-2.1 固有のコンテンツは batch-1.0batch-2.0 の機能で公開されなくなりました。

  • CWWKS1738Eメッセージで使用されるコンフィギュレーション属性名を修正

    ソーシャルメディア・ログイン・フィーチャー経由でOIDC RPを使用する場合、OPから返されたIDトークンに期待したユーザー名の項目がない場合に、誤ったコンフィギュレーション属性名を含むエラーメッセージが出てしまう可能性があります。以下は、そのようなエラーメッセージの例です。

    .ws.security.openidconnect.clients.common.AttributeToSubject E CWWKS1738E: The OpenID Connect client [client01] failed to authenticate the JSON Web Token because the claim [someBadName] specified by the [userIdentifier] configuration attribute was not included in the token.

    エラーメッセージは userIdentifier というコンフィグレーション属性に言及しています。しかし、`socialLogin-1.0`の機能では、同等のコンフィグレーション属性は実際には`userNameAttribute`と呼ばれます。

    この問題は、正しい属性名を参照するようにNLSメッセージを更新することで解決されました。

前回のリリース以降の新しいガイドと更新されたガイド

Open Libertyの特徴や機能が増え続ける中、できるだけ簡単に導入できるように、それらのトピックに関するopenliberty.ioへの新しいガイドを追加しています。既存のガイドも、報告されたバグや問題に対処し、内容を最新に保ち、トピックの内容を拡張するために更新されます。

アプリケーション認証

今すぐOpen Liberty 23.0.0.2を入手する