PEM upgrade best practices and remediation

PEM upgrade best practices and remediation#

このページは、PEMアップグレードをエンドツーエンドで計画、実行、検証、および必要に応じて修復するのに役立ちます。アップグレード中にアクセス許可が失われる理由を説明し、損失をトリガーする操作をリストし、予防と修復の両方のためにすぐに実行できるSQLを提供します。

EDBは、PEM-6100およびPEM-6103で繰り返しの障害モードを追跡します。製品側の修正は別途出荷されます。このページは、その間に顧客対応のギャップを埋め、その後もベストプラクティスのリファレンスとして役立ちます。

PEMアップグレードで権限を保持する方法#

アップグレード中に、PEMは、 pem 、pemdata 、およびpemhistory スキーマのいくつかの内部ビューとファンクション-最もよく知られているprobe_target_view 、probe_schedule_view 、avail_agents 、avail_servers 、およびバージョン間でシグネチャが変更される少数のファンクション。モニタリングが機能し続けるには、これらのオブジェクトはPEMワーカーロール pem_user 、pem_admin 、およびpem_agent で読み取り可能なままである必要があります。

PEMはPostgreSQLのALTER DEFAULT PRIVILEGES に依存して、これらのオブジェクトのいずれかが再作成されるたびに標準の付与を自動的に適用します。 PostgreSQLは、これらのルールを登録したロール—通常は元のPEMインストール多くの場合enterprisedb またはpostgres を実行したロールによってキー付けられるpg_default_acl に保存します。

PEMアップグレードは、正確に2つの状況で許可を失う可能性があります。

  • 所有者の変更。 PEMオブジェクトでREASSIGN OWNED BY <old> TO <new> またはALTER ... OWNER TO <new> を実行しました。 REASSIGN OWNED BY は、オブジェクトの所有権を転送し、既存のACLを保持しますが、 pg_default_acl のエントリをコピーしません。これらは<old> にアタッチされたままです。 <new> によって作成される将来のオブジェクトアップグレード中に再作成されるビューなどは、付与を継承しません。

  • クロスロールアップグレード。 最初にPEMをインストールしたユーザーとは別のOS/データベースユーザーでconfigure-pem-server.sh を実行しています。インストール時に登録されたデフォルト特権ルールは、別のロールでは起動されません。

どちらの場合も、アップグレードは正常に完了しましたが、ワーカーログはすぐにレポートします。

ERROR: permission denied for view probe_schedule_view
ERROR: permission denied for view probe_target_view
ERROR: permission denied for function create_default_server_alerts

そして、すべての監視対象サーバーはPEM Web UIに DOWN と表示されます。

アップグレードする前にクラスターを確認する#

PEMバックエンドデータベースでPostgreSQLスーパーユーザーとして実行します。

SELECT DISTINCT defaclrole::regrole AS defaults_bound_to,
       defaclnamespace::regnamespace AS schema
FROM   pg_default_acl
WHERE  defaclnamespace::regnamespace::text IN (pem,pemdata,pemhistory);

返されたロールがconfigure-pem-server.sh を実行するロールと一致する場合、アップグレードはそのままで安全に実行できます。そうでない場合は、最初に アップグレード前の準備 を処理します。

してはいけないこと#

アップグレードの前#

Do

  • バックアップを取ります pg_dumpall --globals-only およびpg_dump -Fc -d pem 。

  • 最初にPEMをインストールしたOSユーザーとPostgreSQLロールをメモします。そのロールとしてアップグレードを実行します。

  • 上記の検証クエリを実行します。

  • 可能であれば、最初に非実稼働環境でアップグレードをテストします。

しないでください

  • 最初に アップグレード前の準備 を完了することなく、 pem 、pemdata 、またはpemhistory スキーマまたはそのオブジェクトの所有権を変更しないでください。これには、REASSIGN OWNED BY 、ALTER ... OWNER TO 、およびALTER ROLE ... RENAME TO が含まれます。

  • 回避策として``PUBLIC`` に特権を付与しないでください。すべてのデータベースユーザーにPEMの内部を公開します。 pem_user 、pem_admin 、およびpem_agent にのみ付与します。

  • **PEM管理のテーブル、ビュー、ファンクション、またはトリガーを直接変更しないでください。

アップグレード中#

Do

  • デフォルトの権限が登録されているロールとしてconfigure-pem-server.sh を実行します。

  • スクリプト出力を監視します。続行する前に停止してエラーを調査します。

しないでください

  • PEMをインストールしたユーザーとは別のOSまたはデータベースユーザー でアップグレードを実行しないでください新しいロールの アップグレード前の準備 を完了していない場合。

  • アップグレード中にPEMバックエンドでスクリプトを中断したり、他のDDLを実行したりしないでください。

アップグレード後#

Do

  • アップグレード後の検証 で検証を実行します。

  • サービスを開始してから2分間/var/log/pem/worker.log を監視します。

  • すべての監視対象サーバーがWeb UIで UP に移行することを確認します。

しないでください

  • worker.log のpermission denied エラーは無視しないでください。これらは、付与が失われ、修復が必要であることを意味します。 すでに影響を受けているクラスターの修復 を参照してください。

  • 検証に合格するまで、 新しいエージェントまたはプローブを追加しないでください 。

アップグレード前の準備#

このセクションは、アップグレード前チェックで不一致が示された場合、つまり、PEM所有者を変更するか、インストールとは別のロールでアップグレードを実行する場合にのみ適用します。すべてのSQLをPostgreSQLスーパーユーザーとして実行します。すべてのブロックはべき等です。

ステップ1-PEMサービスを停止します#

sudo systemctl stop pemagent
sudo systemctl stop pemserver

ステップ2-所有権を譲渡する 所有権を変更する場合のみ#

REASSIGN OWNED BY <old_owner> TO <new_owner>;
GRANT <old_owner> TO <new_owner>;   -- lets <new_owner> inherit role memberships

ステップ3-アップグレードロールのデフォルト特権を登録する#

<upgrade_role> を、configure-pem-server.sh を実行するロールに置き換えます。

- - Schema: pem
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT SELECT  ON TABLES    TO pem_user;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT ALL     ON TABLES    TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT SELECT  ON TABLES    TO pem_agent;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT USAGE   ON SEQUENCES TO pem_user;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT ALL     ON SEQUENCES TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT EXECUTE ON FUNCTIONS TO pem_user;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT ALL     ON FUNCTIONS TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pem GRANT EXECUTE ON FUNCTIONS TO pem_agent;

- - Schema: pemdata
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemdata GRANT SELECT                         ON TABLES    TO pem_user;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemdata GRANT ALL                            ON TABLES    TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemdata GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES    TO pem_agent;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemdata GRANT ALL                            ON SEQUENCES TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemdata GRANT ALL                            ON FUNCTIONS TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemdata GRANT EXECUTE                        ON FUNCTIONS TO pem_agent;

- - Schema: pemhistory
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemhistory GRANT SELECT                         ON TABLES    TO pem_user;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemhistory GRANT ALL                            ON TABLES    TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemhistory GRANT SELECT, INSERT, UPDATE, DELETE ON TABLES    TO pem_agent;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemhistory GRANT ALL                            ON SEQUENCES TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemhistory GRANT ALL                            ON FUNCTIONS TO pem_admin;
ALTER DEFAULT PRIVILEGES FOR ROLE <upgrade_role> IN SCHEMA pemhistory GRANT EXECUTE                        ON FUNCTIONS TO pem_agent;

ステップ4-孤立したデフォルトを古いロールから取り消しますオプショナル、所有権を変更した場合のみ#

ALTER DEFAULT PRIVILEGES FOR ROLE <old_owner> IN SCHEMA pem        REVOKE ALL ON TABLES, SEQUENCES, FUNCTIONS FROM pem_user, pem_admin, pem_agent;
ALTER DEFAULT PRIVILEGES FOR ROLE <old_owner> IN SCHEMA pemdata    REVOKE ALL ON TABLES, SEQUENCES, FUNCTIONS FROM pem_user, pem_admin, pem_agent;
ALTER DEFAULT PRIVILEGES FOR ROLE <old_owner> IN SCHEMA pemhistory REVOKE ALL ON TABLES, SEQUENCES, FUNCTIONS FROM pem_user, pem_admin, pem_agent;

ステップ5-スキーマUSAGEセーフティネット#

GRANT USAGE ON SCHEMA pem, pemdata, pemhistory TO pem_user, pem_admin, pem_agent;

ステップ6-検証クエリとアップグレードを再実行します#

アップグレードする前にクラスターを確認する からクエリーを再実行します。デフォルトが<upgrade_role> にバインドされたことを確認して、アップグレードを実行します。

sudo /usr/bin/dnf upgrade -y ./edb-pem*.rpm --allowerasing
sudo /usr/edb/pem/bin/configure-pem-server.sh

アップグレード後の検証#

PEMバックエンドデータベースでPostgreSQLスーパーユーザーとして次を実行します。

- - Confirm grants on the views most commonly affected.
- - Each output should show entries for pem_user, pem_admin, and pem_agent.
\dp pem.probe_target_view
\dp pem.probe_schedule_view
\dp pem.avail_agents
\dp pem.avail_servers

- - Smoke-test as pem_agent.
SET ROLE pem_agent;
SELECT count(*) FROM pem.probe_schedule_view;
SELECT count(*) FROM pem.probe_target_view;
RESET ROLE;

- - Sweep for any object pem_user cant read.
- - Zero rows = clean. Repeat with pem_admin and pem_agent.
SELECT c.relkind, n.nspname || . || c.relname AS object
FROM   pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE  n.nspname IN (pem,pemdata,pemhistory)
  AND  c.relkind IN (r,v,m)
  AND  NOT has_table_privilege(pem_user, c.oid, SELECT)
ORDER BY 1,2;

サービスを開始し、ログを2分間監視します。

sudo systemctl start pemserver
sudo systemctl start pemagent
tail -f /var/log/pem/worker.log

permission denied メッセージは表示されません。 PEM Web UIで、すべての監視対象サーバーが UP に移行することを確認します。

すでに影響を受けているクラスターの修復#

アップグレードが既に完了し、probe_target_view 、probe_schedule_view 、avail_agents 、avail_servers 、またはcreate_default_server_alerts のpermission denied エラーが表示されている場合は、PostgreSQLのスーパーユーザーとして以下のインプレース修復を実行します。正常なクラスターではべき等で安全です。

GRANT USAGE ON SCHEMA pem, pemdata, pemhistory TO pem_user, pem_admin, pem_agent;

- - Schema: pem
GRANT SELECT  ON ALL TABLES    IN SCHEMA pem TO pem_user, pem_agent;
GRANT ALL     ON ALL TABLES    IN SCHEMA pem TO pem_admin;
GRANT EXECUTE ON ALL FUNCTIONS IN SCHEMA pem TO pem_user, pem_admin, pem_agent;
GRANT USAGE   ON ALL SEQUENCES IN SCHEMA pem TO pem_user;
GRANT ALL     ON ALL SEQUENCES IN SCHEMA pem TO pem_admin;

- - Schema: pemdata
GRANT SELECT                         ON ALL TABLES    IN SCHEMA pemdata TO pem_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES    IN SCHEMA pemdata TO pem_agent;
GRANT ALL                            ON ALL TABLES    IN SCHEMA pemdata TO pem_admin;
GRANT EXECUTE                        ON ALL FUNCTIONS IN SCHEMA pemdata TO pem_user, pem_admin, pem_agent;
GRANT ALL                            ON ALL SEQUENCES IN SCHEMA pemdata TO pem_admin;

- - Schema: pemhistory
GRANT SELECT                         ON ALL TABLES    IN SCHEMA pemhistory TO pem_user;
GRANT SELECT, INSERT, UPDATE, DELETE ON ALL TABLES    IN SCHEMA pemhistory TO pem_agent;
GRANT ALL                            ON ALL TABLES    IN SCHEMA pemhistory TO pem_admin;
GRANT EXECUTE                        ON ALL FUNCTIONS IN SCHEMA pemhistory TO pem_user, pem_admin, pem_agent;
GRANT ALL                            ON ALL SEQUENCES IN SCHEMA pemhistory TO pem_admin;

再起動は必要ありません。次のプローブサイクル約60秒以内に、新しい権限が取得されます。次回のアップグレードで同じ問題が発生するのを防ぐには、そのアップグレードを実行するロールの アップグレード前の準備 も完了します。

例 所有権を変更したアップグレード#

これは、最も一般的な非標準のシナリオの具体的なチュートリアルです。 PEMは、old_owner が所有するソースサーバーにインストールされました。クラスターは、企業標準の所有者がnew_owner であるターゲットサーバーで復元されています。目標は、最終的な所有者がnew_owner でPEMをアップグレードすることです。

重要なのは順序です。次の手順をこの順序で実行します。

  1. バックアップを取ります してはいけないこと を参照してください。

  2. サービスを停止します アップグレード前の準備 のステップ1。

  3. 所有権を転送します REASSIGN OWNED BY old_owner TO new_owner; GRANT old_owner TO new_owner; ステップ2。

  4. デフォルトFOR ROLE new_owner を登録しますステップ3。

  5. 孤立したデフォルトFOR ROLE old_owner を取り消しますステップ4。

  6. スキーマUSAGEセーフティネットを適用しますステップ5。

  7. RPMアップグレードとconfigure-pem-server.sh をnew_owner として実行します ステップ6。

  8. アップグレード後の検証を実行します。

  9. サービスを開始します。

ステップ4がスキップされる場合、ステップ7はpem.probe_target_view およびpem.probe_schedule_view をnew_owner として再作成します。 PostgreSQLは、 pg_default_acl でnew_owner のデフォルトを見つけず、これらはまだold_owner にバインドされており、ビューは許可なしで思いつきます。ワーカーログには、permission denied for view ... と すでに影響を受けているクラスターの修復 のリカバリーが必要であることがすぐに示されます。

目次