急速アップグレード後のタスク

急速アップグレード ワークフロー
一部のアイテムは、急速アップグレード プロセスで自動的に移行できません。 準備タスクの多くでは、ソース Gateway からデータをバックアップします。 バックアップ タスクは、「急速アップグレードを準備する」に表示されます。
は、復元タスクが自動急速手順の一部として自動化されていることを示します。
手動急速手順に従っている場合は、引き続きこのタスクを手動で実行する必要があります。
インストールに適用される以下のいずれかのタスクを完了してください。
カスタム アサーション、モジュール型アサーション、およびその他の Gateway アーティファクトの復元
以前にソース Gateway からカスタム アサーションおよびモジュール型アサーションをバックアップしていた場合は、このタスクを実行します。 ssgrestore.sh を実行して、プライマリ ノード、セカンダリ ノード、および残りの処理ノードでカスタム アサーションおよびモジュール型アサーションを復元します。 モジュール型アサーションがバージョン更新を必要とするか、Gateway 10 に適用可能かどうかを確認します。
/opt/SecureSpan/Gateway/config/backup/ssgrestore.sh -image name.zip -ca -ma
ssgrestore.sh を使用すると、カスタム アサーションおよびモジュール型アサーションに加えて、ログ ファイル、監査レコード、および設定ファイルなどその他のバックアップ済み Gateway アーティファクトも復元できます。 詳細については、「Gateway の復元」を参照してください。
PAPIM EPAgent ファイルと設定を復元する
以前に PAPIM EPAgent のファイルと設定をバックアップしていた場合は、これを実行します。
PAPIM EPAgent を復元する方法
  1. PAPIM ユーザを作成し、layer7 グループと gateway グループにユーザを追加します。
    # useradd -m <apmusr> # usermod -a -G layer7 apmus # usermod -a -G gateway apmusr
  2. /opt/apm105 バックアップ フォルダを復元します。
    ホスト名が変更されている場合は、/opt/apm105 /epagent/IntroscopeEPAgent で
    introscope.agent.hostName
    を更新します。
    /opt/apm105 のディレクトリ所有権を変更します。
    # chown -R apmusr:apmusr /opt/apm105
    ディレクトリの権限を変更します。
    # chmod -R 775 /opt/apm105
  3. スクリプト ファイル /etc/init.d/epagent を復元します。
    ファイル権限を変更します。
    # chmod 755 /etc/init.d/epagent
    ブート時に開始するように epagent サービスを設定します。
    # chkconfig --add epagent
  4. .bash_profile ファイルと my.cnf ファイルをユーザ ディレクトリ /home/apmusr/.my.cnf に復元します。
    ファイル所有権とファイル権限を変更します。
    # chown apmusr:apmusr /home/apmusr/.my.cnf # chown apmusr:apmusr /home/apmusr/.bash_profile # chmod 400 /home/apmusr/.my.cnf # chmod 400 /home/apmusr/.bash_profile
  5. epagent サービスを開始します:
    #service epagent start
.JAR ファイルをコピーする
一部の機能(JDBC や JMS など)が正しく動作するためには、.JAR ファイルが必要です。 すべての .JAR ファイルを、ソース Gateway からアップグレード先 Gateway の以下のディレクトリにコピーする必要があります。
/runtime/lib/ext /runtime/lib
iptables ファイルの変更を再適用する
ソース Gateway で
iptables
ファイルによるポート リダイレクトを行っていた場合は、アップグレード先 Gateway 上でこれらのリダイレクトを手動で再適用してください。
システム プロパティの変更をコピーする
/opt/SecureSpan/Gateway/node/default/etc/conf
内のファイル コンテンツに対して
プロパティが変更
されている場合は、その変更をソース Gateway からアップグレード先 Gateway に手動でコピーする必要があります。 たとえば、
system.properties
ファイルや
telemetry.properties
ファイル内のプロパティを変更している可能性があります。
アップグレード後の SafeNet Luna の更新
以下のいずれかのオプションを使用して、Luna HSM クライアントをインストールし、アップグレード先 Gateway 用に設定します。オプションによっては、必要に応じて java.security に変更を加えてください。
nShield HSM のアップグレード後のタスク
急速アップグレードに nShield Solo+ または Connect/Connect XC HSM が含まれている場合には、以下のアップグレード後の手順を適用します。
nShield Solo+ のアップグレード後のタスク
ソース Gateway アプライアンスから nShield Solo+ HSM 用の秘密鍵をバックアップしていた場合は、以下の手順に従ってターゲット Gateway アプライアンスにそれらを復元できます。
  1. /opt/nfast/kmdata フォルダからバックアップ ファイルを復元します。
  2. 以下のコマンドを使用して、適切な権限と所有権を設定します。
    kmdata dir: tar --same-owner -svf
  3. Gateway のメイン メニュー(アプライアンス)を使用して、Gateway で HSM を使用できるようにします。
nShield Connect/Connect XC のアップグレード後のタスク
バックアップした MySQL データベースをターゲット Gateway アプライアンスにインポートし、「手動急速アップグレード」トピックの説明に従って HSM (権限および所有権と共に復元されたキー)を再構成したら、Gateway のメイン メニュー(アプライアンス)を使用して、Gateway で HSM を使用できるようにします。
併置される OTK データベースのタスク
これらのタスクは、ソースとアップグレード先の Gateway で cluster.hostname が異なる場合にのみ適用します。
ソースとアップグレード先の Gateway で cluster.hostname が異なる場合には、併置される OTK データベースに対してアップグレード後の設定が必要です。 併置される OTK データベースは、Gateway ノードにローカルに展開されます。アップグレード先の Gateway で、Policy Manager を開き、以下のタスクを実行します。
  1. [Tasks]-[Global Settings]-[Manage Cluster Wide Properties]の順に移動します。
  2. アップグレード先の Gateway の
    cluster.hostname
    値を使用して、
    oauth_client_key.callback
    キーを追加します。
  3. この新しい値で
    cluster.hostname
    キーを編集します。
  4. [Tasks]-[Data Sources]-[Manage JDBC Connection]の順に移動します。
  5. OTK 接続を選択し、
    [Edit]
    をクリックします。
  6. 新しい cluster.hostname 値を反映するように JDBC URL を編集し、
    [OK]
    をクリックします。
  7. ホストの SSL 証明書が変更されている場合は、新しい SSL 証明書をインポートします。
    1. [Tasks]-[Certificates Keys & Secrets]-[Manage Certificates]の順に移動します。
    2. [Add]
      をクリックします。
    3. [Import from Private Key's Certificate Chain]
      を選択します。
    4. [Software DB]で[ssl]を選択します。
    5. [Next]
      をクリックします。
      [Next]
      をクリックします。
    6. 少なくとも最初の 3 つの使用オプションを選択します。
      [Next]
      をクリックします。
    7. [Certificate is a Trust Anchor]
      をクリックします。
    8. 完了
      ]をクリックします。
TSSG 関連のタスク
ソース TSSG とアップグレード先 TSSG で cluster.hostname が異なる場合は、TSSG を再登録する必要があります。
  1. すべての portal.* クラスタ プロパティおよび cluster.apiplan* クラスタ プロパティを削除します。
    mysql> delete from cluster_properties where propkey like 'portal.%'; mysql> delete from cluster_properties where propkey like 'cluster.apiplan%';
  2. 以下の信頼できる証明書を削除します。
    • analytics*
    • pssg
    • apim-ssg*
  3. ポータル関連のスケジュール済みタスクを削除します。 [Tasks]-[Global Settings]-[Manage Scheduled Tasks]の順に移動し、以下のタスクを削除します。
    • Portal *
    • Portal エンティティの削除
    • メトリック データ オフボックスの移動タスク
  4. TSSG を登録する方法については、Portal の指示に従います。
CentOS7 内の my.cnf ファイルを更新する
CentOS7 では、systemd が MySQL サーバの起動とシャットダウンを管理します。 [mysqld_safe]は、必要でないため、インストールされていません。 ログ ファイル パスや pid ファイルなど、一部のパラメータは my.cnf ファイルの
[mysqld_safe]
セクションに定義されています。 これらのパラメータがすべて正しく考慮されて反映されるようにするには、そのすべてのパラメータが
[mysqld]
セクションにコピーされるように
my.cnf
ファイルを編集します。
  1. my.cnf
    ファイルを編集します。
  2. [mysqld_safe]
    セクションのすべての内容を
    [mysqld]
    セクションに移動します。
    内容は以下のようになります。
    max_allowed_packet=1G net_buffer_length=100000 log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid
  3. MySQL サーバを再起動します。
pid ファイル
のパラメータ行が上書きされていることを確認してください。 パラメータの
[mysqld]
セクションに複数のエントリがある場合は、最後の行のみが優先され、それより前のエントリは無視されます。