Apigee Edge 4.54.00 をロールバックする

Edge 4.54.00 への更新中にエラーが発生した場合は、エラーの原因となったコンポーネントをロールバックしてから、更新を再試行できます。

Edge 4.54.00 は、次のいずれかのメジャー リリース バージョンにロールバックできます。

  • バージョン 4.53.00
  • バージョン 4.53.01

詳細については、Apigee Edge のリリース プロセスをご覧ください。

ロールバックの順序

コンポーネントのロールバックは、アップグレードされた順序の逆順で行う必要があります。プライベート クラウド 4.54.00 の一般的なロールバック順序は次のようになります。

  • Cassandra、Zookeeper をロールバックします。
  • Qpid、その他の分析関連コンポーネント、Postgres をロールバックします。
  • ロールバック UI
  • LDAP をロールバックします。
  • 管理サーバーをロールバックします。
  • ルーターとメッセージ プロセッサをロールバックする。

たとえば、すべての Router と Message Processor、すべての管理サーバー、LDAP、いくつかの UI ノードをバージョン 4.53.00（または 4.53.01）からバージョン 4.54.00 にアップグレードし、ロールバックするとします。この場合、次のことを行います。

  • アップグレードされた UI ノードをロールバックする
  • LDAP ノードをロールバックする
  • Management Server ノードを 1 つずつロールバックする
  • すべての RMP を 1 つずつロールバックする

ロールバックを実行できるユーザー

ロールバックを実行するユーザーは、Edge を最初に更新したユーザー、または root として実行しているユーザーと同じである必要があります。

デフォルトでは、Edge コンポーネントはユーザー「apigee」として実行されます。場合によっては、Edge コンポーネントを別のユーザーとして実行することがあります。たとえば、ルーターが 1000 未満の特権ポートにアクセスする必要がある場合は、ルーターを root として実行するか、これらのポートにアクセスできるユーザーとして実行する必要があります。また、あるコンポーネントをあるユーザーとして実行し、別のコンポーネントを別のユーザーとして実行することもできます。

Cassandra をロールバックする

特定のノードで Cassandra のメジャー アップグレードが実行されると、Cassandra はそのノードに保存されているデータのスキーマを変更します。そのため、直接のインプレース ロールバックは実現できません。

ロールバックのシナリオ

次の表に、使用できるロールバック戦略の概要を示します。

シナリオ ロールバック戦略
単一の DC、一部の Cassandra ノードがアップグレード済み バックアップを使用する
複数の DC、1 つの DC 内の一部のノードがアップグレード済み 既存の DC から再構築する
複数の DC、一部の DC のすべての Cassandra ノードがアップグレードされている 既存の DC から再構築する
複数の DC、最後の DC の Cassandra ノードがアップグレードされている アップグレードを完了してみてください。不可能な場合は、バックアップを使用して 1 つの DC をロールバックします。ロールバックされた DC から残りの DC を再構築します。

一般的な考慮事項

ロールバックを検討する際は、次の点に注意してください。

  • Cassandra のアップグレード中の Cassandra のロールバック: Cassandra のアップグレード中に問題が発生した場合は、ロールバックを検討することをおすすめします。アップグレード プロセス中の状態に基づいて、この記事のロールバック戦略に沿って対応します。
  • バックアップを使用したロールバック: Cassandra 5.0.X から取得したバックアップは、Cassandra 4.0.X のバックアップと互換性がありません。バックアップの復元を使用して Cassandra をロールバックするには、アップグレードを試みる前に Cassandra 4.0.X のバックアップを作成する必要があります。

再構築を使用して Cassandra をロールバックする

前提条件

  • 複数のデータセンターにまたがって Edge for Private Cloud 4.53.00/4.53.01 クラスタを運用している。
  • Cassandra を 4.0.X から 5.0.X にアップグレードする際に問題が発生しました。
  • クラスタに、古いバージョンの Cassandra（Cassandra 4.0.X）をまだ実行している完全に機能するデータセンターが 1 つ以上ある。

この手順は、既存のデータセンターからのデータ ストリーミングに依存しています。Cassandra に保存されているデータの量によっては、かなりの時間がかかることがあります。ロールバックの進行中は、このデータセンターからランタイム トラフィックを迂回させる準備をしてください。

手順の概要

  1. ロールバックするデータセンター（一部または完全にアップグレード済み）を 1 つ選択します。ランタイム トラフィックを別の機能しているデータセンターに転送します。
  2. データセンター内のシードノードを特定し、いずれかのシードノードから開始します。
  3. Cassandra ノードを停止、アンインストール、クリーンアップします。
  4. ノードに古いバージョンの Cassandra をインストールし、必要に応じて構成します。
  5. 先ほど追加した追加の構成を削除します。
  6. データセンター内のすべてのシードノードに対して、上記の手順を 1 つずつ繰り返します。
  7. データセンター内の残りのすべての Cassandra ノードについて、上記の手順を 1 つずつ繰り返します。
  8. 既存の機能しているデータセンターからノードを 1 つずつ再構築します。
  9. Cassandra に接続されているデータセンター内のすべての edge-* コンポーネントを再起動します。
  10. トラフィックをテストして、このデータセンターにリダイレクトします。
  11. 各データセンターでこの手順を 1 つずつ繰り返します。

詳細な手順

  1. Cassandra ノードのすべてまたは一部がアップグレードされているデータセンターを 1 つ選択します。このデータセンターの Cassandra ノードがロールバックされている間、このデータセンターからすべてのランタイム プロキシ トラフィックと管理トラフィックを迂回させます。ノードで nodetool ring コマンドが実行されたときに、すべての Cassandra ノードが UN（Up/Normal）状態であることを確認します。特定のノードがダウンしている場合は、問題をトラブルシューティングして、それらのノードを復元してから続行します。

    下記の例をご覧ください。

    /opt/apigee/apigee-cassandra/bin/nodetool status
Datacenter: dc-1
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC1-1IP1  456.41 KiB  1            100.0%            78fc4ddd-2ed9-4a8c-98a2-63a38c2f1920  ra-1
UN  DC1-1IP2  870.93 KiB  1            100.0%            160db01a-64ab-43a7-b9ea-3b7f8f66d52b  ra-1
UN  DC1-1IP3  824.08 KiB  1            100.0%            21d61543-d59e-403a-bf5d-bfe7f664baa6  ra-1
Datacenter: dc-2
================
Status=Up/Down
|/ State=Normal/Leaving/Joining/Moving
--  Address      Load       Tokens       Owns (effective)  Host ID                               Rack
UN  DC2-1IP1   802.08 KiB  1            100.0%            583e0576-336d-4ce7-9729-2ae74e0abde2  ra-1
UN  DC2-1IP2   844.4 KiB   1            100.0%            fef794d5-f4c2-4a4e-bb05-9adaeb4aea4b  ra-1
UN  DC2-1IP3   878.12 KiB  1            100.0%            3894b3d9-1f5a-444d-83db-7b1e338bbfc9  ra-1

    ノードで nodetool describecluster を実行すると、クラスタ全体の現在の状態を把握できます。たとえば、次の図は、すべての DC-1 ノードが Cassandra バージョン 4 で、すべての DC-2 ノードが Cassandra バージョン 3 である 2 データセンター クラスタのインスタンスを示しています。

    # On nodes where Cassandra is upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]

Stats for all nodes:
    Live: 6
    Joining: 0
    Moving: 0
    Leaving: 0
    Unreachable: 0

Data Centers:
    dc-1 #Nodes: 3 #Down: 0
    dc-2 #Nodes: 3 #Down: 0

Database versions:
    5.0.8: [DC-1-IP1:7000, DC-1-IP2:7000, DC-1-IP3:7000]
    4.0.13: [DC-2-IP1:7000, DC-2-IP2:7000, DC-2-IP3:7000]

Keyspaces:
    system_schema -> Replication class: LocalStrategy {}
    system -> Replication class: LocalStrategy {}
    auth -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    cache -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    devconnect -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    dek -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    user_settings -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apprepo -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    kms -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    identityzone -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    audit -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    analytics -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    keyvaluemap -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    counter -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    apimodel_v2 -> Replication class: NetworkTopologyStrategy {dc-2=3, dc-1=3}
    system_distributed -> Replication class: SimpleStrategy {replication_factor=3}
    system_traces -> Replication class: SimpleStrategy {replication_factor=2}
    system_auth -> Replication class: SimpleStrategy {replication_factor=1}

# On nodes where Cassandra is not upgraded
/opt/apigee/apigee-cassandra/bin/nodetool describecluster
Cluster Information:
    Name: Apigee
    Snitch: org.apache.cassandra.locator.PropertyFileSnitch
    DynamicEndPointSnitch: enabled
    Partitioner: org.apache.cassandra.dht.RandomPartitioner
    Schema versions:
        2eadcd74-0245-309a-9992-3625afa70038: [DC-1-IP1, DC-1-IP2, DC-1-IP3]
        129dc15e-198e-3c11-b64c-701044a3a1ad: [DC-2-IP1, DC-2-IP2, DC-2-IP3]
  2. データセンター内のシードノードを特定する: 付録のシードノードを特定する方法セクションをご覧ください。いずれかのシードノードで次の手順を実行します。
  3. Cassandra のノードからデータを停止、アンインストール、クリーンアップします。このデータセンターの Cassandra バージョン 5 の最初のシードノードを選択します。やめて。 
    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe out Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra
  4. ノードに古い Cassandra ソフトウェアをインストールし、いくつかの構成を設定します。Edge for Private Cloud 4.53.00/4.53.01 のブートストラップ ファイルを実行します。
    5. # Download bootstrap of 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap of 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
  5. /opt/apigee/customer/application/cassandra.properties ファイルを作成または編集します。
  6. ファイルに次の内容を追加します。ipOfNode は、Cassandra が他の Cassandra ノードとの通信に使用するノードの IP アドレスです。
    conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
  7. ファイルの所有者が apigee ユーザーであり、apigee ユーザーがファイルを読み取れることを確認します。
    chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
  8. Cassandra をインストールして設定します。
    9. # Install cassandra version 4.0.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install
# Setup cassandra while passing standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile
# Ensure Cassandra version is correct and service is running
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status
  9. ノードが起動したことを確認します。このノードとクラスタ内の他のノードで次のコマンドを確認します。ノードが「UN」（Up/Normal）状態であることを報告する必要があります。
    /opt/apigee/apigee-cassandra/bin/nodetool status
  10. 以前に追加した余分な構成を /opt/apigee/customer/application/cassandra.properties ファイルから削除します。
  11. データセンター内のすべての Cassandra シードノードで、手順 3 ～ 10 を 1 つずつ繰り返します。
  12. データセンター内の残りのすべての Cassandra ノードで、手順 3 ～ 10 を 1 つずつ繰り返します。
  13. 古い Cassandra バージョンを実行しているデータセンターから、データセンター内のすべてのノードを再ビルドします。この手順は、一度に 1 つのノードで実行します。
    /opt/apigee/apigee-cassandra/bin/nodetool rebuild -dc <name of working DC>

    この手順には時間がかかることがあります。必要に応じて streamingthroughput を調整できます。nodetool netstats でオペレーションの完了ステータスを確認します。

  14. （省略可）データが再構築されない場合は、Cassandra ノードで修復コマンドを実行します。
    /opt/apigee/apigee-cassandra/bin/nodetool -h node-IP repair -pr
  15. データセンター内のすべての edge-* コンポーネントを 1 つずつ再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  16. トラフィックを検証して、このデータセンターに転送します。このデータセンターでランタイム トラフィックと管理 API の検証を実行し、プロキシと管理 API のトラフィックをこのデータセンターにリダイレクトします。
  17. ロールバックするデータセンターごとに上記の手順を繰り返します。

バックアップを使用して Cassandra をロールバックする

前提条件

  1. Cassandra を 4.0.X から 5.0.X にアップグレードする際に問題が発生しました。
  2. ロールバックするノードのバックアップがある。バックアップは、4.0.X から 5.0.X へのアップグレードを試みる前に取得されました。

手順

  1. ロールバックするノードを 1 つ選択します。バックアップを使用してデータセンター内のすべてのノードをロールバックする場合は、まずシードノードから開始します。付録の「シードノードを特定する方法」のセクションを参照してください。

  2. Cassandra ノードを停止、アンインストール、クリーンアップします。

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Uninstall Cassandra software
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra uninstall

# Wipe Cassandra data
rm -rf /opt/apigee/data/apigee-cassandra

  3. ノードに古い Cassandra ソフトウェアをインストールして構成します。

    • Edge for Private Cloud 4.53.00/4.53.01 のブートストラップ ファイルを実行します。
      • # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    • ファイル /opt/apigee/customer/application/cassandra.properties を作成または編集します。
      • conf_jvm_options_custom_settings=-Dcassandra.replace_address=ipOfNode -Dcassandra.allow_unsafe_replace=true
    • ファイルの所有者が apigee ユーザーであり、読み取り可能であることを確認します。
      • chown apigee:apigee /opt/apigee/customer/application/cassandra.properties
    • Cassandra をインストールして設定します。
      • # Install Cassandra version 4.0.X
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra install

# Set up Cassandra with the standard configuration file
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra setup -f configFile

# Verify Cassandra version and check service status
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra version
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra status

    ノードが起動したことを確認します。このノードとクラスタ内の他のノードで次のコマンドを確認します。ノードは、このノードが「UN」状態であることを報告する必要があります。

    /opt/apigee/apigee-cassandra/bin/nodetool status

  4. Cassandra サービスを停止し、バックアップを復元します。詳しくは、バックアップと復元のドキュメントをご覧ください。

    # Stop Cassandra service on the node
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra stop

# Wipe the data directory in preparation for restore
rm -rf /opt/apigee/data/apigee-cassandra/data

# Restore the backup taken before the upgrade attempt
/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra restore backupFile

  5. バックアップが復元されたら、追加の構成を削除します。

    以前に追加した構成を /opt/apigee/customer/application/cassandra.properties ファイルから削除します。

  6. ノードで Cassandra サービスを起動します。

    /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra start

  7. バックアップを使用してロールバックする各 Cassandra ノードで、手順を 1 つずつ繰り返します。

  8. すべての Cassandra ノードが復元されたら、すべての edge-* コンポーネントを 1 つずつ再起動します。

    /opt/apigee/apigee-service/bin/apigee-service edge-message-processor restart
/opt/apigee/apigee-service/bin/apigee-service edge-router restart
/opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart

バックアップの最適化（高度なオプション）

最新のデータを含むレプリカが利用可能な場合は、バックアップの復元中にデータ損失を最小限に抑える（または排除する）ことができます。レプリカが利用可能な場合は、バックアップを復元した後、復元されたノードで修復を実行します。

付録

シードノードを特定する方法

データセンター内の Cassandra ノードで、次のコマンドを実行します。

/opt/apigee/apigee-service/bin/apigee-service apigee-cassandra configure -search conf_cassandra_seeds

このコマンドは複数行を出力します。出力の最後の行を確認します。最後の行に表示されている IP アドレスはシードノードです。次の例では、DC-1-IP1、DC-1-IP2、DC-2-IP1、DC-2-IP2 がシードノードの IP です。

Found key conf_cassandra_seeds, with value, "127.0.0.1", in /opt/apigee/apigee-cassandra/token/default.properties

Found key conf_cassandra_seeds, with value, 127.0.0.1, in /opt/apigee/apigee-cassandra/token/application/cassandra.properties

Found key conf_cassandra_seeds, with value, "DC-1-IP1, DC-1-IP2, DC-2-IP1, DC-2-IP2", in /opt/apigee/token/application/cassandra.properties
apigee-configutil: apigee-cassandra: # OK

ZooKeeper をロールバックする

ロールバック

ロールバックが必要な場合:

  1. まず、オブザーバーとフォロワーでロールバック手順を実行します。オブザーバーとフォロワーの選択については、リーダー、フォロワー、オブザーバーを特定するをご覧ください。
  2. ロールバックするバージョン（4.53.00 または 4.53.01）のブートストラップをダウンロードして実行します。このプロセスは、ノードに外部インターネット接続があるかどうか、またはオフライン インストールを行っているかどうかによって異なる場合があります。
  3. ノードで ZooKeeper が実行されている場合は、停止します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper stop
  4. 既存の zookeeper をアンインストールします。
      /opt/apigee/apigee-service/bin/apigee-service apigee-zookeeper uninstall
  5. 通常どおり Zookeeper をインストールします。
      /opt/apigee/apigee-setup/bin/setup.sh -p zk -f <silent-config-file>
  6. すべてのフォロワーとオブザーバーがロールバックされたら、リーダーノードで手順 2 ～ 5 を行い、リーダーノードをロールバックします。
  7. すべてのノードがロールバックされたら、クラスタの健全性を確認し、クラスタにリーダーノードがあることを確認します。

バックアップを復元

バックアップから復元するを参照してください。

Qpid をロールバックする

以前の機能リリースにロールバックするには、ロールバックするバージョンの bootstrap.sh ファイルをダウンロードしてください。v 4.53.00/4.53.01 にロールバックするには、bootstrap_4.53.00.sh をダウンロードします。

Qpid をロールバックするには、すべての Qpid ホストで次の手順を行います。

  1. 既存の Qpid ブローカーを停止します。
    apigee-service apigee-qpidd stop
  2. ファイアウォールを適用して、すべての Message Processor からのブローカー ポート 5672 への受信トラフィックをブロックします。このファイアウォールは、Qpid ノード インスタンスのレベル、または他の外部ファイアウォール/ネットワーク コンポーネントのレベルで適用できます。

    すべての Message Processor の IP アドレスに対して同じ手順を行うことをおすすめします。たとえば、IPTables を使用して、Message Processor の IP アドレスからポート 5672 の Qpid ノードに送信されるリクエストをドロップするには、次のようなコマンドを使用します。

    iptables -A INPUT -p tcp --dport 5672 -s MESSAGE_PROCESSOR_IP -j DROP
  3. Qpid ブローカーを再度起動して、既存のメッセージ（存在する場合）をドレインします。
    apigee-service apigee-qpidd start
  4. 既存のキューが空であることを確認します。確認するには、Qpid 管理ポータルにログインします。
    http://QPID_NODE_IP:8090
  5. キューがドレインされたことを確認したら、Qpid を停止してアンインストールします。
    /opt/apigee/apigee-service/bin/apigee-service apigee-qpidd stop
/opt/apigee/apigee-service/bin/apigee-service apigee-qpidd uninstall
  6. Qpid データ ディレクトリを削除します。
    rm -r APIGEE_ROOT/data/apigee-qpidd
  7. Qpid ブローカーを再インストールします。 
    /opt/apigee/apigee-setup/bin/setup.sh -p qs -f configFile
  8. Qpid ブローカーを再インストールしたら、次のコマンドを使用してファイアウォール設定を削除し、既存の設定を一覧表示します。
    iptables -F
iptables -L

Postgres をロールバックする

バージョン 4.54.00 からバージョン 4.53.00/4.53.01 にダウングレードするには、Edge コンポーネントに加えて Postgres のアップデートをロールバックする必要があります。

マスター / スタンバイ構成で Postgres を更新するときに Postgres の更新をロールバックするには:

  • 新しいスタンバイ ノードをプロモートして、Postgres マスターにします。新しい Postgres マスターは、以前の Edge インストールと同じバージョンになります。
  • 古いスタンバイ ノードを新しいマスターのスタンバイ ノードとして構成します。古いスタンバイ ノードは、以前の Edge インストールと同じバージョンになります。
  • 新しいマスターノードとスタンバイ ノードを分析グループとコンシューマー グループに登録します。

ロールバックが完了すると、古いマスターノードは不要になります。その後、古いマスターノードをデコミッションできます。

始める前に

Postgres 18 から 17/14 へのロールバックを実行する前に、新しいスタンバイ ホストと古いスタンバイ ホストの両方で次の手順を行い、apigee-postgresql の max_locks_per_transaction プロパティを更新します。

  1. 存在しない場合は、ファイル /opt/apigee/customer/application/postgresql.properties を作成します。
  2. このファイルの所有権を apigee に変更します。
    sudo chown apigee:apigee /opt/apigee/customer/application/postgresql.properties
  3. ファイルに次のプロパティを追加します。 
    conf/postgresql.conf+max_locks_per_transaction=30000
  4. apigee-postgresql を構成します。
    apigee-service apigee-postgresql configure
  5. apigee-postgresql を再起動します。
    apigee-service apigee-postgresql restart

詳細なロールバック手順

  1. 新しいスタンバイ Postgres ノードが実行されていることを確認します。
    /opt/apigee/apigee-service/bin/apigee-all status

    Postgres が実行されていない場合は、次のコマンドで起動します。

    /opt/apigee/apigee-service/bin/apigee-all start
  2. 古いマスターノードと古いスタンバイ ノードで Postgres が停止していることを確認します。
    /opt/apigee/apigee-service/bin/apigee-all status

    Postgres が実行中の場合は、停止します。

    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop  
/opt/apigee/apigee-service/bin/apigee-service apigee-postgresql stop
  3. インストールされている場合は、古いスタンバイ ノードで Qpid を起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server start
  4. 新しいスタンバイ ノードを Postgres マスターとして昇格させます。
    1. 新しいスタンバイ ノードを新しいマスターに昇格させます。
      apigee-service apigee-postgresql promote-standby-to-master old_master_IP

      プロンプトが表示されたら、「apigee」ユーザーの Postgres パスワードを入力します。デフォルトは「postgres」です。

    2. 現在のバージョンの Edge のインストールに使用した構成ファイルを編集して、次の項目を指定します。
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    3. 新しいマスターを構成します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-master -f configFile
  5. 古いスタンバイ ノードを新しいバージョンにすでにアップグレードしている場合は、まず古いスタンバイ ノードの Apigee ソフトウェアをダウングレードする必要があります。古いスタンバイ ノードに古いバージョンがまだ存在する場合は、この手順をスキップして手順 6 に進みます。
    1. 古いスタンバイ ノードで Postgres を停止します。
      apigee-service apigee-postgresql stop
apigee-service edge-postgres-server stop
    2. 古いスタンバイ ノードから Postgres をアンインストールします。
      apigee-service apigee-postgresql uninstall
apigee-service edge-postgres-server uninstall
apigee-service edge-analytics uninstall
    3. 古いスタンバイ ノードから Postgres データ ディレクトリを削除します。
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    4. 古いスタンバイ ノードで、古いバージョンのブートストラップ（ロールバックする Apigee バージョン用）をダウンロードして実行します。正確な手順は、インターネットベースのインストールとオフライン インストールのどちらを使用しているかによって異なる場合があります。以前のバージョンの Apigee ブートストラップを実行すると、以前のバージョンの Apigee データで yum リポジトリが設定されます。
    5. 古いスタンバイ ノードに Postgres コンポーネントを設定します。
      /opt/apigee/apigee-setup/bin/setup.sh -p ps -f configFile
    6. 古いスタンバイ ノードの Postgres コンポーネントが古いバージョンにロールバックされたことを確認します。
      apigee-service apigee-postgresql version
apigee-service edge-postgres-server version
  6. 古いスタンバイ ノードを再構築します。
    1. Edge の現在のバージョンのインストールに使用した構成ファイルを編集して、次の内容を指定します。
      # IP address of the new master:
PG_MASTER=new_standby_IP
# IP address of the old standby node
PG_STANDBY=old_standby_IP
    2. 古いスタンバイ ノードのデータ ディレクトリを削除します。
      cd /opt/apigee/data/apigee-postgresql/pgdata
rm -rf *
    3. 古いスタンバイ ノードを新しいマスターのスタンバイ ノードとして再構成します。
      /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql setup-replication-on-standby -f configFile
    4. 古いスタンバイ ノードで Postgres が実行されていることを確認します。
      /opt/apigee/apigee-service/bin/apigee-all status

      Postgres が実行されていない場合は、起動します。

      /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server start
  7. 新しいマスターの /opt/apigee/apigee-postgresql/conf/pg_hba.conf ファイルを表示して、新しいスタンバイ ノードが追加されたことを確認します。
  8. Management Server で次のコマンドを実行して、現在の分析情報とコンシューマー グループ情報を表示します。
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    このコマンドは、name フィールドにアナリティクス グループ名を返し、consumer-groups の name フィールドにコンシューマー グループ名を返します。また、postgres-server フィールドと datastores フィールドに、古い Postgres マスターノードとスタンバイ ノードの UUID も返されます。次のような形式の出力が表示されます。

    {
  "name" : "axgroup-001",
  "properties" : {
  },
  "scopes" : [ "VALIDATE~test", "sgilson~prod" ],
  "uuids" : {
    "qpid-server" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "postgres-server" : [
      "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256"
    ]
  },
  "consumer-groups" : [ {
    "name" : "consumer-group-001",
    "consumers" : [ "8381a053-433f-4382-bd2a-100fd37a1592", "4b6856ec-ef05-498f-bac6-ef5f0d5f6521" ],
    "datastores" :
      [ "ab1158bd-1d59-4e2a-9c95-24cc2cfa6edc:27f90844-efab-4b32-8a23-8f85cdc9a256" ],
      "properties" : {     }
    }
  ],
  "data-processors" : {
  }
}
  9. 古いマスターノードで次の curl コマンドを実行して、古いマスターの UUID アドレスを取得します。
    curl -u sysAdminEmail:password http://node_IP:8084/v1/servers/self

    出力の最後に、ノードの UUID が次の形式で表示されます。

    "type" : [ "postgres-server" ],
"uUID" : "599e8ebf-5d69-4ae4-aa71-154970a8ec75"
  10. 前の手順を繰り返して、古いスタンバイ ノードと新しいマスターの IP アドレスを取得します。
  11. コンシューマー グループから古いマスターノードとスタンバイ ノードを削除します。
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores/masterUUID,standbyUUID" -v

    ここで、axgroup-001 と consumer-group-001 は、分析グループとコンシューマー グループのデフォルト名です。masterUUID,standbyUUID は、上記の現在の分析情報と消費者グループ情報を確認したときに表示された順序と同じです。standbyUUID,masterUUID として指定する必要がある場合があります。

    consumer-groups の datastores プロパティが空になっているはずです。

  12. 分析グループから古いマスターノードとスタンバイ ノードを削除します。
    curl -u sysAdminEmail:password -X DELETE \
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v

    uuids の下の postgres-server プロパティが空になっているはずです。

  13. 新しい PG マスターノードとスタンバイ ノードを、分析グループとコンシューマー グループに登録します。
    curl -u sysAdminEmail:password -X POST -H "Content-Type: application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/servers?uuid=masterUUID,standbyUUID&type=postgres-server" -v
curl -u sysAdminEmail:password -X POST -H "Content-Type:application/json" -d ''
  "http://ms_IP:8080/v1/analytics/groups/ax/axgroup-001/consumer-groups/consumer-group-001/datastores?uuid=masterUUID,standbyUUID" -v
  14. 分析グループを検証します。 
    curl -u sysAdminEmail:password http://ms_IP:8080/v1/analytics/groups/ax

    新しいマスターノードとスタンバイ ノードの UUID が、分析グループとコンシューマー グループに表示されます。

  15. Edge Management Server を再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-management-server restart
  16. すべての Qpid サーバーを再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-qpid-server restart
  17. すべての Postgres サーバーを再起動します。
    /opt/apigee/apigee-service/bin/apigee-service edge-postgres-server restart
  18. 両方のサーバーで次のスクリプトを実行して、レプリケーション ステータスを確認します。レプリケーションが成功したことを確認するには、両方のサーバーで同じ結果が表示される必要があります。

    新しいマスターで、次のコマンドを実行します。

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-master

    マスターであることを確認します。古いスタンバイ ノードで、次のコマンドを実行します。

    /opt/apigee/apigee-service/bin/apigee-service apigee-postgresql postgres-check-standby

    スタンバイであることを確認します。

  19. 複数の API リクエストを行った後、前の手順を繰り返して、ノードが同期していることを確認します。
  20. 古い Postgres マスターをデコミッションします。

    または、古いマスターから Qpid をアンインストールし、新しいマスターノードに Qpid をインストールすることもできます。Qpid をアンインストールしたら、古いマスターノードをデコミッションできます。

新しい Edge UI をロールバックする

Apigee Edge for Private Cloud 4.54.00 では、従来の UI（edge-ui）が新しい Edge UI（edge-management-ui）に置き換えられます。4.54.00 では UI コンポーネントが変更されるため、バージョン 4.53.00 または 4.53.01 にロールバックするには、edge-management-ui をアンインストールして、以前の UI プロファイルを再インストールする必要があります。

  • クラシック UI（edge-ui）: ui プロファイルを再インストールします。
  • 新しい Edge UI（edge-ui と edge-management-ui）: ui プロファイルと ue プロファイルの両方をそれぞれのノードに再インストールします。

ノードの UI をロールバックするには:

  1. 4.54.00 の新しい Edge UI を停止してアンインストールし、以前のバージョンをインストールしてロールバックします。
    1. 4.54.00 の新しい Edge UI（edge-management-ui）を停止してアンインストールします。
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui stop
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui uninstall
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui-static uninstall
    2. Apigee Edge for Private Cloud 4.53.00/4.53.01 のブートストラップ ファイルを実行します。
      # Download bootstrap for 4.53.00
curl https://software.apigee.com/bootstrap_4.53.00.sh -o /tmp/bootstrap_4.53.00.sh -u uName:pWord

# Execute bootstrap for 4.53.00
sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord
    3. apigee-setup を 4.54.00 から以前のバージョンにロールバックします。
      # Uninstall apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall

# Install apigee-setup
/opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  2. 4.53.00/4.53.01 UI 構成を復元します。
    • 4.53.00 または 4.53.01 のインストールからサイレント構成ファイルをバックアップした場合は、そのバックアップ ファイルをロールバック手順に使用します。それ以外の場合は、4.54.00 サイレント構成ファイルで、アップグレード中に削除またはコメントアウトされた 4.53.00 または 4.53.01 UI プロパティを復元またはコメント解除します。参考として、UI のアップグレード セクションをご覧ください。
    • アップグレード中に /opt/apigee/customer/application/ui.properties が削除された場合は、バックアップ ディレクトリから復元します。
      cp -rf /opt/apigee/backup/ui/customer/application/ui.properties /opt/apigee/customer/application/
chown apigee:apigee /opt/apigee/customer/application/ui.properties
  3. 以前の UI バージョンを再インストールして構成します。
    • 従来の UI（edge-ui）に戻す:
      1. Classic UI をインストールして設定します（基本認証の場合、追加の手順は必要ありません）。
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
      2. SSO が有効になっている場合は、Classic UI で SSO を構成します（最初に apigee-sso が実行されていることを確認します）。
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
    • 4.53.00 または 4.53.01 の新しい Edge UI（edge-management-ui と Shoehorn edge-ui）にロールバックする:
      1. サイレント構成ファイルで EDGEUI_ENABLE_UNIFIED_UI=y が設定されていることを確認し、ui プロファイルと ue プロファイルをインストールして設定します。
        /opt/apigee/apigee-setup/bin/setup.sh -p ui -f configFile
/opt/apigee/apigee-setup/bin/setup.sh -p ue -f configFile
      2. SSO が有効になっている場合は、両方の UI コンポーネントで SSO を構成します（最初に apigee-sso が実行されていることを確認します）。
        /opt/apigee/apigee-service/bin/apigee-service edge-ui configure-sso -f configFile
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui configure-sso -f configFile
  4. ロールバックされた UI のステータスとバージョンを確認します。
    • 従来の UI（edge-ui）の場合:
      /opt/apigee/apigee-service/bin/apigee-service edge-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-ui version
    • 新しい Edge UI（edge-management-ui）の場合:
      /opt/apigee/apigee-service/bin/apigee-service edge-management-ui status
/opt/apigee/apigee-service/bin/apigee-service edge-management-ui version

OpenLDAP をロールバックする

このセクションでは、Edge for Private Cloud 4.54.00 の Symas OpenLDAP 2.6.10 を OpenLDAP 2.4.46（Edge for Private Cloud 4.53.00）または Symas OpenLDAP 2.6.7（Edge for Private Cloud 4.53.01）にロールバックする手順について説明します。アップグレード前の有効な LDAP バックアップを使用して、LDAP クラスタ全体でロールバックを実行する必要があります。

主な目的は、既知の正常なバックアップから LDAP クラスタ全体を整合性のある状態に戻すことです。この手順は、シングルサーバー、アクティブ / アクティブ、アクティブ / パッシブのすべてのシナリオで同じです。

始める前に

  • バックアップの非互換性: アップグレードを試みる前に apigee-service apigee-openldap backup を使用して取得した OpenLDAP 2.4.46（Edge for Private Cloud 4.53.00）または Symas OpenLDAP 2.6.7（Edge for Private Cloud 4.53.01）のアップグレード前のバックアップを使用します。アップグレード後に作成されたバックアップは互換性がなく、使用できません。
  • Management API のダウンタイム: LDAP のロールバック中は Management API を使用できなくなるため、管理タスクに影響する可能性があります。LDAP のロールバックに進む前に、すべての edge-management-server インスタンスと edge-ui インスタンスをシャットダウンします。
  • データ損失のリスク: 有効で互換性のあるバックアップがないまま続行すると、データが失われ、復元できなくなるリスクがあります。
  • 有効なバックアップ: アップグレード前の有効な LDAP バックアップが必要です。
  • silent.conf ファイルのバックアップ: アップグレードとロールバックの手順中に構成が混同されないように、以前のバージョンと現在のバージョンの両方の silent.conf ファイルのバックアップを保持します。
  • ロールバック シーケンス: OpenLDAP をロールバックする前に、Cassandra、ZooKeeper、Qpid、PostgreSQL、apigee-sso、Edge UI のロールバック手順を完了します。

ロールバック手順

  1. 管理サーバーと UI をシャットダウンします。LDAP のロールバックに進む前に、すべての edge-management-server インスタンスと edge-ui インスタンスをシャットダウンします。
    apigee-service edge-management-server stop
apigee-service edge-ui stop
  2. 現在の LDAP エントリ数を記録する（LDAP を停止する前）: すべての LDAP サーバーから参照用の合計レコード数を取得します。YOUR_PASSWORD は現在の LDAP マネージャーのパスワードに置き換えます。（レコード数はすべての LDAP サーバーで一致している必要があります）。 
    # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
  3. 新しい LDAP 2.6 を停止してアンインストールする: apigee-openldap サービスを停止し、その構成ディレクトリとデータ ディレクトリを削除します。整合性を確保するため、クラスタ内のすべての LDAP サーバーでこの手順を一度に 1 つのノードで実行します。
    apigee-service apigee-openldap stop
apigee-service apigee-openldap uninstall
rm -rf /opt/apigee/data/apigee-openldap/*
  4. 以前の LDAP バージョン 2.4.46 または 2.6.7 をインストールします。
    • 古い LDAP バージョンをインストールします。 
      /opt/apigee/apigee-setup/bin/setup.sh -p ld -f /opt/silent.conf
    • LDAP バージョンを検証する: 
      source ~/.bash_profile
ldapsearch -VV

# Expected output if rolled back to 4.53.00:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.4.46

# Expected output if rolled back to 4.53.01:
ldapsearch: @(#) $OpenLDAP: ldapsearch 2.6.7
    • 各 LDAP ノードで、手順 4 の上記の手順を 1 つずつ繰り返します。
  5. 残存データをクリーンアップする: すべての LDAP サーバーで、新しくインストールしたサービスを 1 つずつ停止し、データ ディレクトリをクリーンアップして、バックアップからの復元に備えます。
    apigee-service apigee-openldap stop
rm -rf /opt/apigee/data/apigee-openldap/*
  6. LDAP データを復元する: 単一サーバーのセットアップの場合は、手順 6b に直接進みます。マルチサーバー設定の場合は、ステップ 6a に進みます。
    1. アクティブな LDAP サーバーを特定する: LDAP データを復元する前に、次のコマンドを実行してアクティブなサーバー（プロバイダ）を特定します。
      grep -i '^olcSyncrepl:' /opt/apigee/data/apigee-openldap/slapd.d/cn=config/olcDatabase*.ldif
    2. LDAP データを復元します（復元する前に、すべてのサーバーでステップ 5 が完了していることを確認してください）。
      • 単一またはアクティブな LDAP サーバー（手順 6a で決定）で、バックアップ ディレクトリに移動し、アップグレード前のバックアップを復元します（例: 2025.07.28,13.59.00。アップグレード前のバックアップがディレクトリ内の最新のバックアップである場合は、タイムスタンプを省略します）。
        cd /opt/apigee/backup/openldap

# To restore a specific backup, provide the timestamp as shown below:
apigee-service apigee-openldap restore 2025.07.28,13.59.00

# Note: If no timestamp is provided, the latest available backup will be restored by default:
apigee-service apigee-openldap restore

# It is recommended to specify the backup explicitly to avoid restoring an unintended version.
      • apigee-openldap サービスを起動します。
        apigee-service apigee-openldap start
  7. 残りの LDAP サーバーを起動する: 複数サーバーのセットアップがある場合は、残りの各 LDAP サーバーでサービスを起動します。
    apigee-service apigee-openldap start
  8. 最終検証:
    • ロールバックが成功し、データが LDAP クラスタ全体で一貫していることを確認します。
    • すべての LDAP サーバーで検証コマンドを実行します。YOUR_PASSWORD は現在の LDAP マネージャーのパスワードに置き換えます。レコード数はすべてのサーバーで同じである必要があり、手順 2 で取得した数と一致する必要があります。
      # Note: Replace 'YOUR_PASSWORD' with your current LDAP manager password.
ldapsearch -o ldif-wrap=no -b "dc=apigee,dc=com" -D "cn=manager,dc=apigee,dc=com" -H ldap://:10389 -LLL -x -w 'YOUR_PASSWORD' | wc -l
    • データが正しく、整合性があることを確認したら、組織の標準手順に従って edge-management-server、edge-ui、その他の依存コンポーネントを起動します。

Edge コンポーネントをロールバックする

共通コードを含むコンポーネント

次の Edge コンポーネントは共通のコードを共有しています。したがって、ノード上のこれらのコンポーネントのいずれかをロールバックするには、そのノード上にあるこれらのコンポーネントをすべてロールバックする必要があります。

  • edge-management-server（Management Server）
  • edge-message-processor（Message Processor）
  • edge-router（ルーター）
  • edge-postgres-server（Postgres サーバー）
  • edge-qpid-server（Qpid サーバー）

たとえば、ノードに Management Server、Router、Message Processor がインストールされている場合、いずれか 1 つをロールバックするには、3 つすべてをロールバックする必要があります。

以前のメジャー リリースまたはマイナー リリースにロールバックするには、コンポーネントをホストする各ノードで次の操作を行います。

  1. ロールバックするバージョンの bootstrap.sh ファイルをダウンロードします。

    • 4.53.00/4.53.01 にロールバックするには、bootstrap_4.53.00.sh/bootstrap_4.53.01.sh をダウンロードします。
  2. ロールバックするコンポーネントを停止します。
    1. ノード上の共通コードを含むコンポーネントをロールバックするには、次の例に示すように、すべてのコンポーネントを停止する必要があります。
      /opt/apigee/apigee-service/bin/apigee-service edge-management-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-router stop
/opt/apigee/apigee-service/bin/apigee-service edge-message-processor stop
/opt/apigee/apigee-service/bin/apigee-service edge-qpid-server stop
/opt/apigee/apigee-service/bin/apigee-service edge-postgres-server stop
    2. ノード上の他のコンポーネントをロールバックするには、そのコンポーネントのみを停止します。
      /opt/apigee/apigee-service/bin/apigee-service component stop
  3. 収益化をロールバックする場合は、すべての管理サーバー ノードと Message Processor ノードからアンインストールします。
    /opt/apigee/apigee-service/bin/apigee-service edge-mint-gateway uninstall
  4. ノードでロールバックするコンポーネントをアンインストールします。
    1. ノード上の共通コードを含むコンポーネントをロールバックするには、次の例に示すように、edge-gateway コンポーネント グループと apigee-cassandra-client コンポーネント グループをアンインストールして、すべてのコンポーネントをアンインストールする必要があります。
      /opt/apigee/apigee-service/bin/apigee-service edge-gateway uninstall
       
      /opt/apigee/apigee-service/bin/apigee-service apigee-cassandra-client uninstall
    2. Nginx をロールバックするには:
      ### Find the apigee-nginx RPM
rpm -qa | grep -i "apigee-nginx"

### Remove the apigee-nginx RPM
dnf remove apigee-nginx-1.30.x
    3. ノード上の他のコンポーネントをロールバックするには、次の例に示すように、そのコンポーネントのみをアンインストールします。
      /opt/apigee/apigee-service/bin/apigee-service component uninstall

      ここで、component はコンポーネント名です。

    4. Edge Router をロールバックするには、edge-gateway コンポーネント グループをアンインストールするだけでなく、/opt/nginx/conf.d ファイルの内容を削除する必要があります。
      cd /opt/nginx/conf.d
rm -rf *
  5. 4.54.00 バージョンの apigee-setup をアンインストールします。
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup uninstall
  6. apigee-service ユーティリティのバージョン 4.53.00 とその依存関係をインストールします。次の例では、apigee-service のバージョン 4.53.00 をインストールします。
    sudo bash /tmp/bootstrap_4.53.00.sh apigeeuser=uName apigeepassword=pWord

    ここで、uName と pWord は Apigee から受け取ったユーザー名とパスワードです。pWord を省略すると、入力を求めるプロンプトが表示されます。

    エラーが発生した場合は、手順 1 で bootstrap.sh ファイルをダウンロードしたことを確認してください。

  7. apigee-setup のインストール: 
    /opt/apigee/apigee-service/bin/apigee-service apigee-setup install
  8. 古いバージョンのコンポーネントをインストールします。
    /opt/apigee/apigee-setup/bin/setup.sh -p component -f configFile

    ここで、component はインストールするコンポーネント、configFile は古いバージョンの構成ファイルです。

  9. Qpid をロールバックする場合は、iptables をフラッシュします。
    sudo iptables -F
  10. ロールバックするコンポーネントをホストするノードごとに、このプロセスを繰り返します。

mTLS をロールバックする

mTLS の更新をロールバックするには、すべてのホストで次の操作を行います。

  1. Apigee を停止します。
    apigee-all stop
  2. mTLS を停止します。
    apigee-service apigee-mtls uninstall
  3. mTLS を再インストールします。
    apigee-service apigee-mtls install
apigee-service apigee-mtls setup -f /opt/silent.conf