Kompira Enterprise v1.6系アップデート時の注意点
# はじめに
Kompira Enterprise をアップデートを検討する際は、各リリースのリリースノートを参照して仕様変更や注意点について確認するようにしてください。この資料では、以前のバージョンから最新バージョンまでの注意点についてまとめます。

## v1.6.13
- **【重要】Python 3.12 に対応し、Python 3.9 以前のサポートを終了しました。**
    - **新規インストールする場合は Python 3.12 を Kompira の環境として利用するように構成します。**
        - インストールする OS によって、Python のマイクロバージョン（3.9.x の x の部分）は異なります。
    - **既存環境をアップデートする場合は Python 3.12 で Kompira 環境を新たに構築しなおします。**
        - KE 1.6.12 まではアップデート時に既存環境の Python バージョンを保持していましたが、1.6.13 では Python バージョンを更新するように変更されました。
        - 既存の /opt/kompira 環境に追加でインストールされていた Python パッケージがある場合は、新しい環境にも追加でインストールするかを選択することができます。
        - KE 1.6.12 以前の環境をアップデートする場合の注意点や手順については「[KE1.6.12 以前からのアップデート](https://docbase.io/posts/4026804/sharing/fe54333d-c1ea-4180-8806-ec0dd1a8907a#22-ke1612-%E4%BB%A5%E5%89%8D%E3%81%8B%E3%82%89%E3%81%AE%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88)」を参照してください。
    - **v1.6.13 以降は Python 3.12 で Kompira が動作することになるため、ライブラリオブジェクトの動作に影響を与える可能性があります。** 以下のような場面では、十分に動作確認するようにしてください。
        - Python 3.9 以前の環境で利用していたライブラリオブジェクトを流用する場合。
        - ユーザが自身で Kompira 環境に追加の Python モジュールをインストールして利用する場合。
- **【重要】kompira のログファイルのローテーションを Python ではなく logrotate サービスで行うように変更しました。**
    - ログファイル名などは従来通りですが、ログ監視などを行なっている場合は十分に動作確認するようにしてください。
- EOL になった PostgreSQL 12 ～ 13 のサポートを終了しました。
    - 該当する古い PostgreSQL がインストールされている環境で Kompira をアップデートすると、古い PostgreSQL はそのまま保持されます。
        - PostgreSQL をアップグレードしたい場合は、install.sh に `--postgresql-version=18` などと指定してください。

## v1.6.12
- **【重要】ジョブフロー型定義を一部変更しました。**
    - "errors" フィールドについて、その型を Dictionary 型 から LargeText 型に変更しました。
    - 従来は {行番号: エラー情報, ...} というデータ構造でしたが、エラー箇所の位置情報の詳細化のためには適していないため、フィールド型としては LargeText 型に変更して、エラー情報は JSON 化して保存するようにしました。
    - このフィールドは "invisible" 修飾子が付けられているため、編集画面や詳細画面では見えませんし、エクスポートデータなどにも出力されません。ただしデータベース上には記録されており、そのデータ構造の変更になりますので、データを直接参照しているような場合には修正が必要になります。
- OS標準ではない追加リポジトリ (epel, pgdg*, modern-erlang*, rabbitmq-server* など) については、Kompira のインストール後にデフォルト無効化となるようになりました。
    - インストーラ外で追加リポジトリのパッケージのアップデートをしたい場合は、明示的なリポジトリの有効化指定が必要になります。

## v1.6.11
- **【重要】Kompira 環境が Python 3.9 に対応しました。**
    - **新規インストールする場合は Python 3.9 を Kompira の環境として利用するように構成します。**
        - インストールする OS によって、Python のマイクロバージョン（3.9.x の x の部分）は異なります。
        - 既存のライブラリオブジェクトを流用する場合、Python のバージョン変更に伴って動作が変わる可能性がありますので、十分に動作確認を行なうようにしてください。
        - Kompira v1.6.11 以降を Python 3.8 を利用して新規インストールしたい場合は「[Python 3.8 を利用した新規インストール](https://docbase.io/posts/3764487/sharing/5e749e90-d025-476f-8ae4-5e009ae144da#212-python-38-%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9F%E6%96%B0%E8%A6%8F%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB)」を参照してください。
            - ただし、下記の新規サポート対象になった RHEL 9系 および AmazonLinux 2023 環境については Python 3.8 に対応していないため、この「Python 3.8 を利用した新規インストール」手順は利用できません。
    - **既存環境をアップデートする場合は Python のバージョンの変更はされず保持します。**
        - 既存の /opt/kompira/bin 配下にインストール済みの python のバージョンが保持されます。
        - Python 3.8 などで構成されている Kompira v1.6.10 以前の環境を v1.6.11 以降にアップデートするときに、Python もアップデートしたいという場合は「[Python 3.9 を利用したアップデート](https://docbase.io/posts/3764487/sharing/5e749e90-d025-476f-8ae4-5e009ae144da#222-python-39-%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9F%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88)」を参照してください。
            - ただし、RHEL 7.X および AmazonLinux2 環境については Python 3.9 に対応していないため、この「Python 3.9 を利用したアップデート」手順は利用できません。

- **新規インストール環境では Python 3.9 で Kompira が動作することになるため、ライブラリオブジェクトの動作に影響を与える可能性があります。**以下のような場面では、十分に動作確認するようにしてください。
    - Python 3.6 や Python 3.8 環境で利用していたライブラリオブジェクトを流用する場合。
    - ユーザが自身で Kompira 環境に追加の Python モジュールをインストールして利用する場合。

## v1.6.10
- **【重要】PostgreSQL 13 以上のインストールに対応しました。**
    - **Kompira を新規インストールする場合は、その時点の Kompira およびインストール先の OS が対応している最新の PostgreSQL をインストールします。**
    - **Kompira をアップデートする場合は、既存の PostgreSQL のメジャーバージョンを保持します。** ただし PostgreSQL のマイナーアップデートは実施されます。
    - Kompira v1.6.10 時点で、インストール先の OS ごとに対応する PostgreSQL の最新版は以下のとおりです。
        - RHEL8 / RockyLinux8 / AlmaLinux8 / MiracleLinux8: PostgreSQL 17.x
        - RHEL7: PostgreSQL 15.x
        - AmazonLinux2: PostgreSQL 14.x

- **既存の Kompira 1.6 環境のアップデート時に PostgreSQL のメジャーバージョンをアップグレードできるようになりました。** 
    - **PostgreSQL のアップグレード時はサーバ内で全てのデータをコピーすることになるため、データベースクラスタが利用しているデータ量と同程度の空き容量が必要になります。**
    - **冗長構成における PostgreSQL のアップグレードは両系停止アップデートを基本とした専用の手順となります。**
    - PostgreSQL のアップグレードの詳細な手順については「[PostgreSQL のアップグレード手順](https://docbase.io/posts/3589916/sharing/29f35251-b6f0-4955-8c6d-b087e1059638)」を参考にしてください。
    - なお、AmazonLinux2 環境については PostgreSQL のアップグレードに対応していません。

- 不具合修正または仕様変更により、既存ジョブフローの動作が変わる場合があります。
    - チャネルオブジェクトに対するイベント待ちジョブで権限チェックがなされていない問題を修正しました。チャネルオブジェクトに対するイベント待ちジョブでは少なくとも読み込み権限が必要になります。peek_mode=true でない場合は、さらに書き込み権限が必要になります。 **権限のないイベント待ちジョブを行なっていた場合、アップデート後は実行時エラーになります。**
    - フィールド値でオブジェクトを並び替えしたときに当該フィールドのデータを持たないオブジェクトが一覧に含まれない問題を修正しました。**該当する並び替えを行なっていた場合、アップデート後は並び替えの結果得られるオブジェクト一覧が変わります。**
    - mailto() に指定したアドレスリスト (TO:. CC:, BCC: など) を Python が不正な (RFC 2822 に準拠していない) 形式であると検知した場合は、mailto() のエラーとなるようになりました。この事象は Kompira 環境に利用した Python が脆弱性 CVE-2023-27043 に対応したバージョンの場合において発生します。**不正なアドレスリストを指定していた場合、アップデート後は mailto() が実行時エラーになる場合があります。**
    - Directory.find() メソッドでフィールド値による並び順に対応していない型のフィールドを指定するとエラーになるようになりました。order_by で並び順を指定できるフィールドは、``Password`` / ``Array<T>`` / ``Dictionary<T>`` 以外の型のフィールドです。並び替えに対応していない ``Password`` / ``Array<T>`` / ``Dictionary<T>`` 型のフィールドを order_by に指定した場合はエラーになります。
    - Text オブジェクトでいくつかの拡張子は設定できないようになりました。`update`, `delete`, `rename`, `property` は拡張子として設定できません。**設定できない拡張子を持つ Text オブジェクトデータのインポートもエラーになります。**

## v1.6.9
- **【重要】Kompira 環境が Python 3.8 に対応しました。**
    - **新規インストールする場合は Python 3.8 を Kompira の環境として利用するように構成します。**
        - インストールする OS によって、Python のマイクロバージョン（3.8.x の x の部分）は異なります。
        - 既存のライブラリオブジェクトを流用する場合、Python のバージョン変更に伴って動作が変わる可能性がありますので、十分に動作確認を行なうようにしてください。
        - Kompira v1.6.9 以降を Python 3.6 を利用して新規インストールしたい場合は「[Python 3.6 を利用した新規インストール](https://docbase.io/posts/3161227/sharing/625567c0-cdca-4209-8e80-a619e31e654d#212-python-36-%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9F%E6%96%B0%E8%A6%8F%E3%82%A4%E3%83%B3%E3%82%B9%E3%83%88%E3%83%BC%E3%83%AB)」を参照してください。
    - **既存環境をアップデートする場合は Python のバージョンの変更はされず保持します。**
        - 既存の /opt/kompira/bin 配下にインストール済みの python のバージョンが保持されます。
        - Python 3.6 で構成されている Kompira v1.6.8 以前の環境を v1.6.9 以降にアップデートするときに、Python もアップデートしたいという場合は「[Python 3.8 を利用したアップデート](https://docbase.io/posts/3161227/sharing/625567c0-cdca-4209-8e80-a619e31e654d#222-python-38-%E3%82%92%E5%88%A9%E7%94%A8%E3%81%97%E3%81%9F%E3%82%A2%E3%83%83%E3%83%97%E3%83%87%E3%83%BC%E3%83%88)」を参照してください。

- **新規インストール環境では Python 3.8 で Kompira が動作することになるため、ライブラリオブジェクトの動作に影響を与える可能性があります。**以下のような場面では、十分に動作確認するようにしてください。
    - Python 3.6 環境で利用していたライブラリオブジェクトを流用する場合。
    - ユーザが自身で Kompira 環境に追加の Python モジュールをインストールして利用する場合。
- ディレクトリ形式でのエクスポート・インポート処理において、代表フィールド（ジョブフローの source フィールドなど）の改行コードの取り扱いが変わっています。
    - 代表フィールドの改行コードはデータベース上では CRLF に、ディレクトリ形式でエクスポートしたファイルは OS 標準の改行コード（Linux であれば LF）になることに注意してください。
    - エクスポートしたデータを github などの外部リポジトリで履歴管理を行なっている場合は、今回のアップデート後の1回については改行コードが差分となる可能性があります。

## v1.6.8.post2
- rabbitmq-server がマイナーバージョンアップした場合は、`rabbitmqctl enable_feature_flag all` コマンドにより rabbitmq-server の機能をすべて有効化するようにしてください。
    - rabbitmq-server が動作中に `rabbitmqctl list_feature_flags` コマンドを実行すると、機能が有効化されているか確認することが出来ます。全ての機能が `enabled` という表記になっているか確認してください。以下は v3.10 での例ですが、機能の数はバージョンによって異なります。

        ```
        # rabbitmqctl list_feature_flags
        Listing feature flags ...
        name    state
        classic_mirrored_queue_version  enabled
        implicit_default_bindings       enabled
        maintenance_mode_status enabled
        quorum_queue    enabled
        stream_queue    enabled
        user_limits     enabled
        virtual_host_metadata   enabled
        ```

    - 以前のアップデート後に機能の有効化を実施しておらず有効 (enabled) になっていない機能がある場合は、Kompira のアップデートを開始する前に `rabbitmqctl enable_feature_flag all` コマンドを実行してください。
    - install.sh が rabbitmq-server のマイナーバージョンアップを検出した場合は、インストールスクリプトの最後に以下のような表示があります。

        ```
        [2023-07-04 22:06:37] INFO: --------------------------------------------------------------------------
        [2023-07-04 22:06:37] INFO: 
        [2023-07-04 22:06:37] INFO: RabbitMQ is upgraded: 3.10.7 -> 3.11.19
        [2023-07-04 22:06:37] INFO: 
        [2023-07-04 22:06:37] INFO: After rabbitmq-server has started, check the feature flags with the following command.
        [2023-07-04 22:06:37] INFO: 
        [2023-07-04 22:06:37] INFO:     # rabbitmqctl list_feature_flags
        [2023-07-04 22:06:37] INFO: 
        [2023-07-04 22:06:37] INFO: If there are any feature flags that are not enabled, 
        [2023-07-04 22:06:37] INFO: enable all feature flags with the following command after the upgrade is complete.
        [2023-07-04 22:06:37] INFO: 
        [2023-07-04 22:06:37] INFO:     # rabbitmqctl enable_feature_flag all
        [2023-07-04 22:06:37] INFO: 
        [2023-07-04 22:06:37] INFO: --------------------------------------------------------------------------
        ```

    - この場合、アップデート後に `rabbitmqctl enable_feature_flag all` コマンドを実行して rabbitmq-server の機能をすべて有効化するようにしてください。

        ```
        # rabbitmqctl enable_feature_flag all
        Enabling all feature flags ...
        ```

    - 冗長構成のアップデートで rabbitmq-server がマイナーバージョンアップした場合は、2台とも更新を終えてクラスタが正常に起動した後に、いずれかのノードで `rabbitmqctl enable_feature_flag all` コマンドを実行するようにしてください。
    - **冗長構成ではこの手順を実施しておかないと、次回のマイナーアップデートで rabbitmq-server が起動できなくなる可能性がありますので、特に注意してください。**

- 冗長構成でのアップデートでは rabbitmq-server はマイナーバージョンが +1 づつしか更新しないようになりました。
    - 現状 3.10.x がインストールされていて最新版は 3.12.x がリリースされていたとしても、3.11.x へのアップデートが実施されます。このようなアップデート後により新しいバージョンが利用可能な場合は、インストールスクリプトの最後に以下のような表示があります。

        ```
        [2023-07-04 22:37:26] INFO: --------------------------------------------------------------------------
        [2023-07-04 22:37:26] INFO: 
        [2023-07-04 22:37:26] INFO: A newer rabbitmq-server is available.
        [2023-07-04 22:37:26] INFO:     current version: 3.11.19
        [2023-07-04 22:37:26] INFO:     available versions:  3.8 3.9 3.10 3.11 3.12
        [2023-07-04 22:37:26] INFO: 
        [2023-07-04 22:37:26] INFO: Please consider updating to every 1 minor version.
        [2023-07-04 22:37:26] INFO: 
        [2023-07-04 22:37:26] INFO: --------------------------------------------------------------------------
        ```

    - このような動作のため、冗長構成で rabbitmq-server を最新版にしたい場合は、複数回アップデートを実施する必要がある場合があります。（rabbitmq-server 3.8.0 以降であれば最新版でなくとも kompira としては動作します）
    - このとき冗長構成として必ず2台セットで rabbitmq-server のマイナーバージョンが +1 づつ更新するようにしてください。たとえばスタンバイ側だけ2回アップデートしてから、アクティブ側も2回アップデートするといった手順は取らないようにしてください。
    - 冗長構成で rabbitmq-server がマイナーアップデートした場合は、2台とも更新を終えてクラスタが正常に起動した後に、前述の rabbitmq-server の機能を有効化する手順を実施するようにしてください。
- 冗長構成のアップデートでアップデート前の rabbitmq-server のバージョンが古すぎる（3.3.X など）場合は、rabbitmq-server のローリングアップデートができないため、両系停止アップデート手順を実施する必要があります。

## v1.6.8
- v1.6.8 でオブジェクトの検索結果（Directory.find() メソッドの結果）などを示す新しい型として「遅延評価配列」が導入されています。
    - v1.6.8 より前の find() の結果は `Array` 型でしたが、遅延評価配列は `LazyArray` 型となります。このようにいくつかの場面でのデータ型が変更になっているため、例えば type() で得られる型名で処理を分岐しているような場合は、意図通りに動作しない可能性がありますのでご注意ください。
- v1.6.8 で標準ユーティリティが付属するようになり、添付されるジョブフローがライセンス上の「ジョブフロー数」のカウント対象になります。
    - ジョブフロー数上限が設定されているライセンスを利用されていて、すでにジョブフロー数が上限に達しているかほぼ余裕が無いような場合は、標準ユーティリティが利用いただけない可能性があります。
- v1.6.8 でセキュリティ強化として rabbitmq-server が SSL 接続するようになり、また一部安全でない接続を禁止するようになりました。
    - 外部ネットワークに配置した kompira_jobmngrd や kompira_sendevt から、内部ネットワークに配置した Kompira サーバ（の rabbitmq-server）に SSL 接続するようにする場合、TCP/5671 ポート (AMPQS) へのアクセスを許可するようにしてください。
    - 外部に配置する kompira_jobmngrd や kompira_sendevt も、Kompira サーバと合わせてアップデートしてください。
- rabbitmq-server の SSL 接続対応に関連して rabbitmq-server および kompira 側の設定が変更にあります。しかし、v1.6.8 より前のバージョンからのアップデートでは、互換性のために以前の構成のまま動作するようになっています。アップデート後に v1.6.8 新規インストールでの構成と同様にする場合は、以下を参考に設定を変更してください。
    - **【注意】冗長構成で設定を変更する場合は、両系を停止した状態で行うようにしてください。**
    - kompira_jobmngrd, kompira_sendevt が rabbitmq-server に SSL 接続するようにする。
        - アップデート時に /opt/kompira/kompira.conf.new というファイルが作成されますので、これを /opt/kompira/kompira.conf にコピーして再起動すると、SSL 接続するようになります。
    - rabbitmq-server が外部からの非 SSL での接続を禁止するようにする。
        - /etc/rabbitmq/conf.d/30-tcp.conf の listeners.tcp.1 という行を listeners.tcp.1 = 127.0.0.1:5672 と変更して再起動すると、外部からの非 SSL でのアクセスが禁止されます。
    - rabbitmq-server が外部からの guest ユーザでのアクセスを禁止するようにする。
        - /etc/rabbitmq/rabbitmq.conf の loopback_users=none という行を削除して再起動すると、外部からの guest ユーザでのアクセスが禁止されます。

## v1.6.7
- v1.6.7 での SSL 関連のライブラリアップデートに伴い、Legacy TLS (v1.0/v1.1) での接続が非推奨になりました。Kompira サーバの OS 設定によっては、Windows 2008R2 など古い Windows に WinRS (HTTPS) で接続できなくなる可能性があります。
    - Kompira サーバに crypto-policies が導入されている場合、設定ファイル `/etc/crypto-policies/back-ends/opensslcnf.config` を編集して `TLS.MinProtocol = TLSv1.0` とすると、TLSv1 でも接続できるようになります。
- v1.6.7 にアップデートした後に、何らかの理由で v1.6.6 以前にダウングレードする場合は、事前に以下のコマンドを実行してセッション情報を削除してください。この手順を実行せずにダウングレードすると、内部エラーになりログインできない状態になる場合があります。その場合にも下記手順を実行してください。

    ```
    $ echo -e "from django.contrib.sessions.models import Session\nSession.objects.all().delete()" | /opt/kompira/bin/manage.py shell
    ```

## v1.6.6
- v1.6.6 で冗長構成のアップデート手順が変更になりました。
    - 以下のように、アップデート後に pcs cluster start 手順が不要になりました。詳細についてはマニュアル「1.9.3. アップデート」を参照してください。
    - 両系停止アップデート手順（切り替えを伴わない）
        - スタンバイ系を停止 (pcs cluster stop)
        - アクティブ系を停止 (pcs cluster stop --force)
        - アクティブ系をアップデート (./install.sh)
        - スタンバイ系をアップデート (./install.sh)
    - 片系停止アップデート手順（切り替えを伴う）
        - スタンバイ系を停止 (pcs cluster stop)
        - スタンバイ系をアップデート (./install.sh)
        - アクティブ系を停止 (pcs cluster stop)
        - 旧アクティブ系をアップデート (./install.sh)

- v1.6.4 ～ v1.6.5 で冗長構成を新規に構築した環境では、パスワードフィールド用の secret key が同期されないという不具合が見つかっております。これに該当する場合は、フェイルオーバーした際に新たなアクティブ系でパスワードフィールドの値が読み込めなくなる、といった問題が生じます。ご利用中の冗長構成の環境で、以下のシークレットキーファイルの内容が同一であるか確認してください。内容が同一であれば、不具合は生じていません。

   ```
   /var/opt/kompira/.secret_key
   ```

    シークレットキーファイルの内容が異なる場合は不具合が生じているため、v1.6.6 にアップデートする前に復旧させる必要があります。詳しくは以下の資料を参考にしてください。
    - [[KE16不具合] 冗長構成でパスワードフィールド用の secret key が同期されない](https://docbase.io/posts/2531947/sharing/97a1c155-edc4-4157-8465-3313243d8dad)

- 冗長構成を v1.6.5 までにアップデートしたことがある環境では、rabbitmq-server の設定ファイルである /etc/rabbitmq/rabbitmq.conf がシングル構成用に書き換えられている場合（内容が1行になっている場合が該当します）があります。そうした環境でアップデートのために install.sh を実行したとき、その最後に以下のような警告メッセージが表示されるようになりました。

    ```
    [2022-07-22 12:00:00] WARN: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    [2022-07-22 12:00:00] WARN: 
    [2022-07-22 12:00:00] WARN: CORRUPT CONFIG DETECTED! (/etc/rabbitmq/rabbitmq.conf)
    [2022-07-22 12:00:00] WARN: 
    [2022-07-22 12:00:00] WARN: YOU CAN RESTART THE CLUSTER AS IS.
    [2022-07-22 12:00:00] WARN: HOWEVER THE FOLLOWING MEASURES ARE RECOMMENDED.
    [2022-07-22 12:00:00] WARN: 
    [2022-07-22 12:00:00] WARN: 
    [2022-07-22 12:00:00] WARN: Please copy /etc/rabbitmq/rabbitmq.conf.new to /etc/rabbitmq/rabbitmq.conf
    [2022-07-22 12:00:00] WARN: before restarting the cluster.
    [2022-07-22 12:00:00] WARN: 
    [2022-07-22 12:00:00] WARN:   # cp -f -S .old -b /etc/rabbitmq/rabbitmq.conf.new /etc/rabbitmq/rabbitmq.conf
    [2022-07-22 12:00:00] WARN: 
    [2022-07-22 12:00:00] WARN: CAUTION: PLEASE COPY ON EACH NODES WHEN BOTH CLUSTERS ARE STOPPED.
    [2022-07-22 12:00:00] WARN: 
    [2022-07-22 12:00:00] WARN: !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
    ```

    この場合、このまま利用することも可能ですが、冗長構成用に改めて用意した設定ファイル（setup_cluster.sh 実行時のものと同様です）に置き換えることを推奨します。メッセージに表示されているように、以下のコマンドをそれぞれのノードで実行してください。

    ```
    # cp -f -S .old -b /etc/rabbitmq/rabbitmq.conf.new /etc/rabbitmq/rabbitmq.conf
    ```

    ただし、設定ファイルをコピーする際は両系のクラスタが停止している状態で実施する必要がありますのでご注意ください。手順的には以下を参考にしてください。

    1. 両系を停止する（スタンバイ系を先に停止させて、後に、アクティブ系を停止させてください）
    2. 設定ファイルをコピーコマンドなどで置き換えてください。
    3. 両系を再開する（アクティブ系を先に再開させて、後に、スタンバイ系を再開させてください）

## v1.6.4
- v1.6.4 から添付ファイルがデータベースに保存されるようになり、また合わせてサイズ制限が緩和されました。データベース上では添付ファイルの実サイズより大きい容量を必要とするため、大きな添付ファイルを扱う場合はディスクの空き容量にご注意ください。
- v1.6.4 からサーバ上に添付ファイルの実体は保持しなくなりますので、サーバ上に添付ファイルの実体が存在することを前提としたジョブフローなどは正常に動作しなくなります。
- v1.6.3 以前からアップデートした場合、既存の添付ファイルは kompirad 起動時に自動的にデータベースに保存されます。そのため、添付ファイルの数が多い場合は起動に時間がかかる場合があります。また、データベース保存に移行した後も、添付ファイルに対応するサーバ上の実ファイルはそのまま残っていますので、不要な場合は手動で `/var/opt/kompira/upload` を削除してください。
- 冗長構成を v1.6.3 以前から v1.6.4 以降にアップデートした場合、pacemaker 配下で lsyncd サービスが動作する設定のままとなっています。v1.6.4 環境で lsyncd が動作していても影響はありませんが、lsyncd サービスを停止させる場合は冗長構成のアップデートが正常に終えたあとに、root 権限で以下のコマンドを実行してください。

    ```
    # pcs resource delete res_lsyncd
    ```

## v1.6.3
- CentOS 7 環境における冗長構成アップデートの注意点
    - 対象：v1.6.0～v1.6.2.post1 から v1.6.2.post2 以降へのアップデート
    - 詳細については以下をご確認ください。
        - https://docbase.io/posts/2118544/sharing/aaab9c34-93a2-4af6-85e0-7b50cef07d3a

## v1.6.2.post5
- 本リリースにより冗長構成の初期セットアップ時に適用される構成パラメータを変更しています。既存の冗長構成においても同様の構成パラメータ変更を適用することを推奨します。アクティブ系の Kompira サーバ上で以下のコマンドを実行してください。

```
# pcs resource update res_pgsql op demote on-fail=restart
# pcs resource update res_pgsql op stop on-fail=ignore
```

上記のパラメータ変更により、冗長構成における以下の問題を解消します。
- Kompiraサーバがクラッシュして、（PostgreSQLのが正しく停止しなかった状態で）そのサーバが再起動してクラスタに参加しようとした時に、アクティブ側の稼働を停止してしまう問題を解消します。（op demote on-fail=restart による解消）
- PostgreSQLプロセスが単独でクラッシュした場合、フェールオーバに失敗する問題を解消します。（op stop on-fail=ignore による解消）

## その他の注意点
### rabbitmq-server のバージョンが古い場合
アップデート前の rabbitmq-server のバージョンが 3.3.X など古い場合に注意が必要です。アップデートによって rabbitmq-server のバージョンが 3.10.X など一気に上がるために、rabbitmq-server の起動に失敗して、結果として install.sh の実行に失敗してしまいます。

この場合、以下の手順により対処することができます。

```
(1) rabbitmq-server の停止
# systemctl stop rabbitmq-server

(2) 起動失敗の原因となっているファイルを移動（バックアップ）
# mv /var/lib/rabbitmq/mnesia /tmp/mnesia.bak

(3) rabbitmq-server の起動
# systemctl start rabbitmq-server

(4) Kompiraのバックアップデータ確認
# ls -l /var/opt/kompira/kompira_backup.json.gz

(5) --no-backup オプション付きで install.sh を再実行
# ./install.sh --no-backup
```
