UNIX®、Linux、および macOS での Caché の使用法
この章では、UNIX®、Linux、および macOS に固有の管理手順について説明します。この章では、以下の項目について説明します。
UNIX® のユーザ、グループおよび権限
UNIX® プラットフォームでの Caché インストールはすべて、以下のユーザおよびグループを有しています。
-
root — Caché は root によってインストールされ、Caché システム・デーモンによる処理の一部は root として実行します。
-
インスタンスの所有者 — このユーザがほとんどのインストール・ファイルが所有し、インスタンスを完全にコントロールします。最小の初期セキュリティ設定でインストールした場合は、root が既定の所有者となります。それ以外の場合、インストール中に所有者の指定を求められます。
-
Caché スーパーサーバの実効ユーザとそのジョブ — 受信要求処理のためにスーパーサーバにより生成された Caché プロセスはすべて、このユーザとして実行されます。JOBSERVER プロセスによりホストされるジョブのほかにタスク・マネージャのジョブおよびユーザ定義の起動ルーチン (^%ZSTART など) もこのユーザで実行されます。既定では、このユーザが cacheusr となりますが、インストール中にユーザを変更することができます。
-
Caché プロセスの実効グループ — すべての Caché プロセスは、自動的にこのグループとして実行され、Caché 内部においての通常のユーザが Caché データベースやジャーナル・ファイルにアクセスできますが、それまではこれらのファイルへのアクセスが認められない場合があります。これらおよびその他の Caché ファイルに対してファイルのアクセス権限を設定することにより、このグループが適正なアクセスを得られます。セキュリティの高いシステムでは、実際のユーザがこのグループのメンバとなる必要がありません。既定では、このグループが cacheusr となりますが、インストール中にグループを変更することができます。
-
インスタンスの開始と停止を許可されたグループ — このグループ、root、およびインスタンスの所有者は、Caché を開始および停止することができます。
すべてのジャーナルおよびジャーナル・ディレクトリは、Caché プロセスの実効グループのグループに設定されたグループ所有権を備え、そのグループに完全アクセス権限 (ジャーナルには rw、ジャーナル・ディレクトリには rwx) を与える必要があります。ジャーナルおよびジャーナル・ディレクトリを所有しているユーザは、それらが作成された方法によって異なる場合があります。
Caché 内で作成されたジャーナルおよびジャーナル・ディレクトリは、適切なアクセス権限で作成されます。ただし、(スクリプトまたは管理者のアクションを通じて) 外部的にジャーナルおよびジャーナル・ディレクトリの移動、コピー、作成を行う場合は、適正なアクセス権限が確実に維持されるようにする必要があります。アクセス権限を適切に設定できないと、不測かつ深刻なエラーを誘発するおそれがあります。
以下の例では、Caché プロセスの実効グループのプロセスは cacheusr、インスタンスの所有者は cacheowner ですが、それぞれのファイルは作成された状況に応じて異なるユーザ所有権を持っていると仮定します。例えば以下のようになります。
journal directory cacheowner cacheusr drwxrwxr-x
20170801.001 cacheowner cacheusr -rw-rw----
これらの設定は部分的に、Caché インストールの install-dir/bin ディレクトリ内の実行可能ファイルに対する一連のアクセス権限として維持されます。関連するプロパティには、所有権、グループ、モード、set-UID、set-GID ビットがあります。オペレーティング・システム・レベルでの管理タスク実行時に、これらのアクセス権限を変更しないよう注意してください。
データベースおよびデータベース・ディレクトリのアクセス権限
すべてのデータベースおよびデータベース・ディレクトリは、Caché プロセスの実効グループのグループに設定されたグループ所有権を備え、そのグループに完全アクセス権限 (データベースには rw、データベース・ディレクトリには rwx) を与える必要があります。データベースおよびデータベース・ディレクトリを所有しているユーザは、それらが作成された方法によって異なる場合があります。
Caché 内で作成されたデータベースおよびデータベース・ディレクトリは、適切なアクセス権限で作成されます。しかし、(スクリプトまたは管理者のアクションを通じて) 外部的にデータベースおよびデータベース・ディレクトリの移動、コピー、作成を行う場合、適正なアクセス権限を確実に維持する必要があります。アクセス権限を適切に設定できないと、不測かつ深刻なエラーを誘発するおそれがあります。
以下の例では、Caché プロセスの実効グループのプロセスが cacheusr であり、かつインスタンスの所有者が cacheowner ですが、ファイルは各自が作成された状況により、異なるユーザ所有権を備えていることを想定しています。
dataset directory cacheowner cacheusr drwxrwxr-x
CACHE.DAT cacheowner cacheusr -rw-rw----
UNIX® での起動
Caché インスタンスがプロセスの開始、停止、および新規プロセスの作成の制御に使用するリソースは、以下のリソースです。
-
install-dir\mgr ディレクトリの cache.ids ファイル。
-
共有メモリ。
デーモン・リソース・ロック
Caché では、推奨されるファイル・ロックを使用して、異なるマシン上で同一のインスタンスが同時に複数で起動されないようにします。推奨されるファイル・ロックでは、1 つのロック・ファイル (ここでは、install-dir/bin ディレクトリのファイル・クロック) を複数リソースの排他ロックに使用できます。制御プロセス、ライト・デーモン、およびジャーナル・デーモンのそれぞれによって、ロック・ファイル内でロックされるセクションが異なります。ロック・ファイルの当該のセクションが既にロックされている場合は、起動が強制終了します。別のデーモンが保持しているロックは、デーモン・リソース・ロックと呼ばれます。
ファイル・ロックはプロセスが終了するまで、そのプロセスによって保持されます。このように、保持されているロックが存在している場合は、いずれかのノードでいずれかのデーモン・プロセスが実行中であることが示されます。ただし、インスタンスの実行が正常であるかどうか、問題なく実行されているかどうかは示されません。
cache.ids ファイル
cache.ids ファイルには、Caché が開始されたノードの名前が格納されます。cache.ids ファイルの存在によって、Caché ユーティリティ、およびユーザ作成のスクリプトは、インスタンスが起動され実行中であることを認識できます。たいていの場合、起動時にはこのファイルが無視されます。ただし、cache.ids の読み取り時にエラーが発生した場合は、Caché が起動されなくなります。これまでのバージョンの Caché では、共有メモリ識別子が cache.ids ファイルにも格納されていましたが、今回のリリースからは格納されません。
起動シーケンス
起動シーケンスの理解を深めるため、インスタンスがノード A とノード B という 2 つの異なるノード (マシン) から起動できると考えてみましょう。cache.ids ファイルは、(共有ファイルに対する) デーモン・リソース・ロックの場合と同様に両方のノードから認識できます。しかし、共有メモリ自体は、作成されたノード (つまり、Caché を起動したノード) でのみ認識できます。
手順 1. インスタンスの状態のチェック
起動ルーチンによって cache –cV が実行され、インスタンスの状態が検出されます。最初、インスタンスの共有メモリへのアタッチが試行されます。
-
インスタンスの共有メモリがない場合は、デーモン・リソース・ロックが調べられます。
-
保持されているデーモン・リソース・ロックが存在しない場合は、インスタンスは “停止” しているとレポートされます。
-
デーモン・リソース・ロックが保持されている場合、cache.ids ファイルで指定されたノード上でインスタンスが実行中であるとレポートされます。cache.ids ファイルが存在しない場合は、デーモンを実行中の場所に関する情報を取得できません。
アクション : ユーザは ccontrol stop、または ccontrol force を実行し、該当するノード上で実行中のインスタンスを中止する必要があります。これによってデーモンが停止し、cache.ids ファイルが削除されます。
-
-
アタッチが成功した場合、システムは起動され、実行中であると見なされます。この状態がユーザにレポートされます。起動は中止されます。
-
共有メモリがまだアタッチされているために起動を完了できないことを示すエラーが表示される場合は、メモリが解放されるまで数分待ちます。それでもインスタンスが起動しない場合は、インターシステムズのサポート窓口Opens in a new tabまでご連絡ください。
手順 2. Caché の起動
Caché の起動プロセス (cache) が実行されます。チェックが繰り返し実行され、起動リソースに対して別の起動処理が完了していないことが保証されます。
-
デーモン・リソース・ロックが保持されている場合は、このインスタンスのいずれかのノードで 1 つ以上のデーモンが実行されていることを示します。この場合 Caché はこれをレポートして、エラーによって終了します。起動は中止されます。
cache.ids ファイルが存在していないと、デーモンが実行されているノードが不明になります。
アクション : いずれかのノード上で起動が行われていると見なされます。インスタンスが開始されたノードを判定するには、cache.ids ファイルを調べます。
Caché の起動が続行されます。
Caché の管理
sysmgr グループ内のユーザ ID を持つユーザは、シェルから ccontrol を実行できます (“Caché 複数インスタンスの使用法” の章で "Caché インスタンスの制御" を参照)。このコマンドは、install-dir/bin ディレクトリの Caché の実行可能ファイルやスクリプトを呼び出します。以下のセクションでは、Caché インスタンスでこれらの管理タスクを実行する方法について説明します。
インストールの所有者は、該当インスタンスの開始および停止、システム管理の実行、該当インスタンスの診断プログラムの実行などが可能な、すべての権限を保持します。
インスタンスの所有者であるユーザ ID のみが、すべての診断操作を実行できます。また、そうすることが必要です。これで、作成されたすべてのファイルやリソースは、root ユーザではなくインスタンスの所有者のものとなります (root ユーザ以外はこれらのリソースにアクセスできなくなります)。このため、root ユーザの所有ではないインスタンスに対して、root ユーザが何らかの管理 (インスタンスの開始や停止など) をできないようにすることをお勧めします。root ユーザが管理できるインスタンスは、その root ユーザが所有するもののみとする必要があります。
Caché の開始
Caché を開始するには、システム・レベルでスタートアップ・プロシージャを実行します。このプロシージャは、既定の構成ファイル、または指定した構成ファイルのいずれかを起動します。
コンソール・マシンでない場合は、Telnet を実行して、Caché がインストールされているターゲットのマシンに接続します。UNIX® で Caché システムを開始する前に、以下の条件のうち 1 つを満たしている必要があります。
-
スーパーユーザであること
-
root ユーザとしてサイン・インしていること (root 以外のアカウントでログインしているときでも、su (スーパーユーザ) コマンドで root に変更できます)。
-
UNIX® グループ ID が、システムの停止と開始の特権を持つよう Caché のインストールで指定したグループに一致していること。
インストール時にこれらの特権を指定する方法の詳細は、"Caché インストール・ガイド" の “UNIX® および Linux への Caché のインストール” の章を参照してください。
ccontrol コマンドを使用して Caché を開始します。
ccontrol start <instname>
instname は、開始する Caché インスタンスの名前です。詳細は、このドキュメントの “Caché 複数インスタンスの使用法” の章の "Caché インスタンスの制御"を参照してください。
sysmgr グループ内のユーザ ID を持つユーザは、シェルから ccontrol start を実行できます。このコマンドにより、現在のノードまたは別のノードでインスタンスが実行されていないことの確認、共有メモリや複数のスレーブ・ライト・デーモン (SWD) を含む基本的な Caché デーモンの作成、その他のデーモン (ECP デーモンなど) を作成するスタートアップ・ルーチン (^STU) の実行の後に、ユーザのログインが許可されます。
Caché の実行
ユーザはそのユーザ ID およびグループ ID (この例では anyuser:anygroup) に関係なく、シェルから csession を実行できます ("Caché 複数インスタンスの使用法"の章で “Caché インスタンスの接続” を参照)。これによって install-dir/bin ディレクトリで cuxsession が実行されます。
Caché を anyuser:cacheusr として実行すると、Kerberos ネゴシエーションを含む標準スタートアップ・ロジックが実行され、$USERNAME と一連のログイン・ロールが識別されます。多くの場合、この $USERNAME 値は、csession を呼び出した実際のユーザと関連付けられています。したがって、どのユーザも Caché を実行できますが、Caché でのユーザのアクティビティは、そのユーザに割り当てられたセキュリティ・ロールによって定義され、制限されます。
install-dir/bin ディレクトリから Caché の実行可能ファイル (cache.exe) を呼び出す方法で、Caché を開始しないでください。
Caché 実行可能ファイルは、それ自体は setgid 実行可能ファイルではありません。Caché を開始するユーザの代わりにグループを適切に設定するのは、csession ラッパの役割です。ccontrol の既定の機能によるセットアップとして /usr/bin ディレクトリから Caché を実行している場合は、これは問題ではありません。ccontrol は既定で /usr/bin/ ディレクトリ内に cache という名前の実行可能ファイルをセットアップし、アクセス許可を適切に設定する csession を呼び出すリンクとなります。
macOS 10.11 以降では、ccontrol と csession は /usr/bin からのリンクを使用して、/usr/local/bin に格納されます。
Caché の停止
通常は、Caché システムを実行したままの状態にしておきます。しかし、オペレーティング・システムに再起動が必要であれば、システムをシャットダウンする前に Caché を停止します。バックアップやデータベースの修復ユーティリティなど Caché のメンテナンス・タスクの場合は、Caché を停止させる必要はありません。
UNIX® で Caché を停止するには、Caché の開始時と同じ手順を行います。以下の条件のうち 1 つを満たしている必要があります。
-
スーパーユーザであること
-
ルート・ユーザとしてサイン・インしていること (root 以外のアカウントでログインしているときでも、su (スーパーユーザ) コマンドで root に変更できます)。
-
UNIX® グループ ID が、システムの停止と開始の特権を持つよう Caché のインストールで指定したグループに一致していること。
コマンド行から Caché を停止するには以下の作業を行います。
-
ccontrol stop コマンドを使用します。
ccontrol stop <instname>
instname は、停止する Caché インスタンスの名前です。ccontrol オプションの詳細は、このドキュメントの “Caché 複数インスタンスの使用法” の章の "Caché インスタンスの制御" を参照してください。
Caution:ccontrol force コマンドで Caché を停止することができますが、データが失われることがあるので、これを行うときは注意が必要です。
-
このプロシージャは Caché SHUTDOWN ユーティリティを呼び出し、状態レポートを表示します。レポートで起動中のプロセスをチェックし、次のステップが必要かどうかを決定します。
-
必要な場合は、システム上のすべてのユーザにメッセージを送信します。
Do you want to broadcast a message to anyone? No=> Yes Send a message to other terminals. Message => Please sign off Terminal => /dev/tty/06 Terminal => Message =>
-
Message プロンプトで Enter キーを押すまで、メッセージの送信後も他のメッセージを送信できます。
-
他のシステムの状態を参照するかどうかを尋ねられた場合、参照するには「Yes」と入力し、参照する必要がない場合は Enter キーを押します。
-
「Yes」と応答すると、システムの状態が再度表示され、動作中のターミナルを確認できます。
-
停止したい時は「Yes」と入力します。「No」と応答すると、シャットダウン・プロシージャを中止し、Caché は起動されたままになります。
UNIX® プラットフォームでは、Caché インスタンスを停止または再起動するか、強制的にダウンすると、そのインスタンスは、すべてのプロセスが共有メモリからアタッチ解除されるまで最大で 30 秒待機します。30 秒が経過すると、インスタンスは閉じます。インスタンスが閉じた後にまだ共有メモリにアタッチされているプロセスがある場合、インスタンスの再起動は失敗します。