新しい投稿

検索

ダイジェスト
· 2025年6月2日

【週間ダイジェスト】 5/26 ～ 6/01 の開発者コミュニティへの投稿

#開発者コミュニティ公式 #ダイジェスト
5/26 ～ 6/01Week at a GlanceInterSystems Developer Community
InterSystems公式
· 2025年6月2日

IKO 3.8 リリースのご案内

#Kubernetes #InterSystems公式

InterSystems Kubernetes Operator (IKO) 3.8 がリリースされました。 IKO 3.8 は、多くのバグ修正とセキュリティ更新に加えて、新機能を追加しました。注目の機能は以下のようになっています。

  • コンピュート・グループ では、1つの IrisCluster から複数のタイプのコンピュートノードをデプロイすることで、異なるタイプのワークロードを処理できます。
  • ボリュームの統合 – データベースと WIJ を同じボリュームに統合するなど、より少ないボリュームでのデプロイを選択できるようになりました。

IKO のダウンロード、インストール、ファーストステップについては インストールガイド をご確認ください。IKO 3.8 ドキュメント には、IKO を InterSystems IRIS や InterSystems IRIS for Health とどのように組み合わせるかの手順が記載されています。IKO は WRC からダウンロードいただけます (Kubernetes で検索してください。） コンテナは InterSystems コンテナレジストリ から入手いただけます。

IKO で簡単に使える  irisCluster リソース定義をお使いいただくことで、 Kubernetes における InterSystems IRIS や InterSystems IRIS for Health の作業手順を単純化することができます。簡単なシャーディング、ミラーリング、ECP構成など、すべての機能については ドキュメント をご参照ください。

ディスカッション (0)0
続けるにはログインするか新規登録を行ってください
記事
· 2025年6月1日 7m read

InterSystems 製品のセキュリティの基本：ユーザとロール

#システム管理 #セキュリティ #ヒントとコツ #管理ポータル #Caché #Ensemble #HealthShare #InterSystems IRIS #InterSystems IRIS for Health

これは InterSystems FAQ サイトの記事です。

InterSystems 製品では、ユーザが持つロールによって「InterSystems 製品内で何ができるのか」が決まります。

では、ロールには何が含まれているのでしょうか。

ロールには、複数の特権を含めることができます。特権とは、リソース（保護対象）に対する許可の設定を指しています。

本記事では、IRIS の開発者である山田さん(Yamada) を例に、以下の内容をご説明します。

1) ロールから付与される特権（＝リソースに対する許可）について具体例を利用した確認方法

2) ロールを利用したセキュリティ設定について

《ご参考》

ビデオでの解説もあります。ラーニングパスの「InterSystems IRIS 管理の基本」の「4. セキュリティの構成と管理」をご参照ください。

ラーニングパスには、管理者ではないけれど管理概要も知っておきたい方向けの「開発者向け InterSystems IRIS の管理概要」もあります。ぜひご参照ください。

1) ロールから付与される特権（＝リソースに対する許可）について具体例を利用した確認方法

山田さんは開発者であるため、VSCode から T1 ネームスペースにアクセスし開発をしています。また、管理ポータルのシステムエクスプローラーメニューについても、T1 ネームスペースに対して操作ができるようにロールが付与されています。

現在、山田さんに付与されているロールは以下の通りです。

  • %Developer ロール （開発者用ロール）
  • %DB_T1ロール

《付与されるリソースのイメージ（全リソースについて記載していません）》

このロールから具体的にどのような特権が提供されているか、管理ポータルを利用して山田さんのプロファイルを参照します。

管理ポータル > システム管理 > セキュリティ > ユーザ > Yamadaの行の右端にある「プロファイル」のリンクをクリック

 

プロファイルのリンクをクリックした後は以下の表示です。

※ 権限の表はまだ下に続いていますが、図例は省略しています。

 

特権は保護対象であるリソースに対する【許可（READ／WRITE／USE）】の組み合わせで、データベースに対しては R（READ）または W（WRITE） 、接続経路（ターミナルや Mirror など）、管理ポータルメニュー、ユーザのアプリケーションに対しては U（USE）許可を設定できます。

山田さんに付与されている %Developer ロールから提供されるリソースの 1つ %Development リソースに付与されている許可を確認します。

%Developement リソースはインストール時用意される事前定義リソースで、管理ポータルのシステムエクスプローラーメニューが使用するアプリケーションパス (/csp/sys/exp) や VSCode から IRIS に接続する際内部的に使用している /api/aterlier のパスやクラスリファレンスのパス /csp/documatic に対しての U（USE：利用）許可が設定されています。

 

次に、%DB_T1 ロールから付与されるデータベース用リソース：%DB_T1 の許可を確認すると、 RW（READ と WRITE）が設定されています。

※ データベース用リソースとは、セキュリティ設定を強化する際に個々のデータベースに対して設定する定義で通常 %DB_データベース名で作成します。未設定のデータベースは、%DB_%DEFAULT リソースに含まれます。データベース用リソースを作成するとリソースに対する READ／WRITE の許可がセットされたデータベース用ロール（%DB_データベース名）が自動的に作成されます。

 

リソースには全ユーザに対して許可を与える設定もありパブリックで許可している設定は、プロファイルの「パブリックリソースにより付与」の列に表示されます。

 

つまり、リソースは、データベースであったり、ターミナルや Web ゲートウェイのような接続経路であったり、管理ポータルメニューやアプリケーションのエンドポイントだったり、保護対象となる何かを指していることがわかります。

この「保護対象」に対してどの許可を持つかをロールにまとめて定義し、そのロールをユーザに付与することで保護対象のリソースに対してアクセスできる・できない、が決まります。

※ 「アセット」は、セキュリティ設定項目上登場しない用語ですが、InterSystems 製品の保護対象の総称として使用している用語です。

ここまでの流れで、InterSystems 製品に対してセキュリティ設定を行う場合に登場する、ロール、特権、リソース、許可 の用語の意味を確認できました。

2) ロールを利用したセキュリティ設定について

次は、ロールを利用したセキュリティ設定について、具体的な例でご説明します。

開発者の山田さんは主に、クラス定義の作成・編集を行っています。開発者の鈴木さんは主に、テーブル定義の作成、データ登録や参照確認などを担当しています。

二人とも開発者であるため、管理ポータルのシステムエクスプローラーやターミナル（IRISへのログイン）、VSCode からのアクセスに必要な %Developer ロールと、T1 ネームスペースでソースコードの読み書きや実行に必要な %DB_T1 ロールが必要です。

この後、開発者が増える予定もあるため、個々のユーザにこの 2 つのロールを付与するのではなく、開発者用ロール：AppDeveloper を作成し、%Developer と %DB_T1 ロールのメンバーとして AppDeveloper ロールを設定し、新開発者は AppDeveloper ロールメンバーとして割り当てるほうが管理しやすくなりそうです。

また、SQLでテーブル定義を作成する場合は、SQL管理権限の %CREATE_TABLE が最低限必要なのと、既存テーブルに対して参照・更新・削除を行うためには操作対象テーブルに対する権限の設定も必要です。
これら権限は、SQLを中心に操作する開発者のみ付与されていればよいので、SqlDeveloper ロールを作成し必要な権限を設定し、開発者である鈴木さんに付与します。

ロールのイメージは以下の通りです。

 

以下の流れで作成します。

[1] AppDeveloper ロールの作成

[2] SqlDeveloperロールの作成

[3] AppDeveloperロールに山田さん（Yamada）と鈴木さん（Suzuki）さんを設定

[4] SqlDeveloperロールに鈴木さん（Suzuki）さんを設定

[5] テスト

 

[1] AppDeveloper ロールの作成

AppDeveloper ロールの作成手順は以下の通りです。

管理ポータル > システム管理 > セキュリティ > ロール > 新規ロール作成ボタンクリック

ロール名を記入し、保存ボタンを押した後の設定は以下の通りです。

完成図

 

[2] SqlDeveloperロールの作成

次に、SQL 開発者（鈴木さん）に付与する SqlDeveloper ロールを作成します。（既存に Sampleスキーマがある想定です）

最初に、SQL管理権限の設定です。

 

続いて、テーブル権限の追加です。例では T1ネームスペースにある Sample スキーマのテーブルに対して全権限付与しています。

 

[3] AppDeveloperロールに山田さん（Yamada）と鈴木さん（Suzuki）さんを設定

AppDeveloper ロールの設定は、以下の通りです。

 

[4] SqlDeveloperロールに鈴木さん（Suzuki）さんを設定

続いて、SqlDeveloper ロールのメンバーに鈴木さん（Suzuki）を追加したときの図です。

 

[5] テスト

設定が正しく行えているかテストします。

山田さんで管理ポータルにログインしたときは、SQLメニューでSQLの実行が行えませんが、鈴木さんでログインしたときはSQLの実行が行えます。

鈴木さんの場合は以下の通りです。

ここでご紹介した用語や設定方法は、InterSystems 製品共通の内容です。

適切なロールをユーザに付与することで、管理ポータルやアプリケーションに対して、アクセス可否を決定できます。

ディスカッション (0)1
続けるにはログインするか新規登録を行ってください
記事
· 2025年6月1日 5m read

ロックテーブルの参照方法とその見方

#システム管理 #ヒントとコツ #Caché #Ensemble #InterSystems IRIS #InterSystems IRIS for Health

これは InterSystems FAQ サイトの記事です。

ロックテーブルを参照する方法として、主に以下の3つの方法が挙げられます。

1. 管理ポータルで参照する方法
　⇒ 管理ポータル：システムオペレーション > ロック > ロックを表示（または管理）

2. ^LOCKTAB ユーティリティ を使用する方法
　⇒ %SYS> do ^LOCKTAB

3. プログラムで参照する方法
　⇒ プログラム内でロック情報を取得する方法


こちらの記事では、ロックテーブルで参照できる情報について、以下の３つのケースに分けて、かかるロックとその意味をご説明します。

１．トランザクションで更新クエリ実行時、他のプロセスで更新・参照した状態
２．デッドロックとなった状態
３．テーブルロックがかかった状態


目視で一番わかり易いのは、１の 管理ポータルで参照する方法 になるので、こちらで説明したいと思います。

最初に、
１．トランザクションで更新クエリ実行時、他のプロセスで更新・参照をすると、どのようなロックがかかるのか見ていきます。

a. プロセスA（PID=10044）にてトランザクションで、Sample.Personテーブルの ID=1 を更新します。    ⇒ Exclusive_e->Delock ロック

[SQL]TL1:USER>>update Sample.Person(Name) values('bbb') where ID=1

b. プロセスB（PID=46952）にて、Sample.Personテーブルの ID=1 を更新します。     ⇒ WaitExclusiveExact ロック
　→ ロックタイムアウト後（既定10秒）、[SQLCODE: <-110>:<ファイル中にロック競合が発生しました>] エラーが返ります。

[SQL]USER>>update Sample.Person(Name) values('ccc') where ID=1

c. プロセスC（PID=45680）にて、read commit モード で、Sample.Personテーブルの ID=1 を参照します。     ⇒ WaitSharedExact ロック
　→ ロックタイムアウト後（既定10秒）、[SQLCODE: <-114>:<ひとつまたはそれ以上のマッチする行が別のユーザによりロックされています>] エラーが返ります。

[SQL]USER>>set transaction isolation level read committed
[SQL]USER>>select * from Sample.Person where ID=1


管理ポータルでロックテーブル情報を見てみます。青四角がそれそれでの持しているロックになります。
※複数の増分ロックがかかっているときは、「Exclusive/5」のように、ロック数も表示されます。1つのロックの時は表示されません。


次に、
２．デッドロックが発生しているとき、どのようなロックの状態になるのか見てみます。

1. プロセス A(PID:43468) で次のコマンドを発行します ： lock +^MyGlobal(15)
2. プロセス B(PID:2198) で次のコマンドを発行します  ： lock +^MyOtherGlobal(15)
3. プロセス A で次のコマンドを発行します ： lock +^MyOtherGlobal(15)
   ⇒ この LOCK コマンドは返りません。このプロセスは、プロセス B がロックを解放するまでブロックされます。
4. プロセス B で次のコマンドを発行します ： lock +^MyGlobal(15)
   ⇒ この LOCK コマンドも返りません。このプロセスは、プロセス A がロックを解放するまでブロックされます。

プロセスA、プロセスB、ともにロックの解放待ちで、応答が返らない状態（デッドロック）になりました。


管理ポータルでロックテーブル情報を見てみます。

プロセスA（PID:43468）
　・^MyGlobal(15) に対する Exclusive（排他ロック）を保持
　・^MyOtherGlobal(15) に対し、WaitExclusiveExactで同一ロックに対する排他ロックの待機（ロック解放待ち）

プロセスB（PID:2198）
　・^MyOtherGlobal(15) に対する Exclusive（排他ロック）を保持
　・^MyGlobal(15) に対し、WaitExclusiveExactで同一ロックに対する排他ロックの待機（ロック解放待ち）

お互いに、それぞれが保持しているロックの解放待ちで、デッドロック状態となっていることが分かります。
 

デッドロックを防止するには以下のような方法があります。

  • 常に timeout 引数を使用する。
  • 増分 LOCK コマンドを発行する際にその順序に関して厳格なプロトコルに従う。すべてのプロセスが、ロック名に関して同じ順序に従っている限り、デッドロックが発生することはありません。単純なプロトコルは、照合順序でロックを追加するものです。
  • 増分ロックではなく単純ロックを使用する (つまり、+ 演算子を使用しない)。前述のとおり、単純ロックでは、LOCK コマンドは最初に、プロセスによって以前から保持されていたすべてのロックを解放します (ただし、実際には単純ロックはあまり使用されません)。


最後に、
３．テーブルロックがかかった状態では、どのようなロックがかかるのか見ていきます。

今回は、Create Table で作成した、SQLUser.tab1 テーブルで実験してみます。
現在、ロック閾値 が 1000(デフォルト) なので、トランザクションでそれ以上の更新をしてみます。

1回目の Insert で、「Exclusive_e->Delock」のロックが１つかかっているのが分かります。

2回目の Insert で、「Exclusive_e->Delock」のロックが２つになったのが分かります。 

1001回目の Insert では、テーブルロック閾値（1000）を超えたために、「Exclusive/1001E->Delock」というテーブルロックにまとめられたことが分かります。

 

    今回は、管理ポータルで参照する方法をご紹介しましたが、^LOCKTABユーティリティ や、プログラムで取得する方法 でも、同様の情報を見ることが可能です。

    なお、正常に終了したプロセスは取得していたロックを全て解放します。


    enlightened【ご参考】
    InterSystems製品のロックの基本

    ディスカッション (0)0
    続けるにはログインするか新規登録を行ってください
    質問
    · 2025年6月1日

    Primary startup failed, failed to read header ..... during Failover

    #ジャーナリング #Mirroring #HealthShare #InterSystems IRIS for Health #Health Connect

    I am attempting to failover my TEST environment to the Backup, and I keep getting an error stating that 

    06/01/25-18:47:54:516 (11864) 1 [Utility.Event] Primary startup failed, failed to read header of /archive/journal/MIRROR-IRISTEST-20250513.007 (file #63653)

    however, when I go to /archive/journal/, I am not finding any record of MIRROR-IRISTEST-20250513.007 (file #63653)

    to get out of this error message I have to restart what was the Primary and restart the Backup to get it back into a state that we can use it. 

    There is a Namespace/Database that is on the backup and not part of the mirror, which I need to get moved to being mirrored across all the instances of our TEST environment.

    Any idea why it is thinking that /archive/journal/MIRROR-IRISTEST-20250513.007 (file #63653) still exists, and it needs to read from it?
     

    1 Comment
    ディスカッション (1)1
    続けるにはログインするか新規登録を行ってください