iPlanet Calendar Server 管理者ガイド: 第 3 章 Calendar Server の管理

前へ目次索引 DocHome 次へ

iPlanet Calendar Server 管理者ガイド

第 3 章 Calendar Server の管理

この章では、iPlanet Calendar Server の管理方法と構成方法について説明します。
この章は、次の節に分かれています。

Calendar Server の起動と停止

Calendar Server タイムアウト値の構成

シングルサインオン (SSO) の構成

データベースワイヤプロトコル (DWP) の構成

LDAP 属性の管理

グループスケジューリングエンジン (GSE) キューの管理

Calendar Server の監視

Calendar Server の ping

Calendar Server 構成の更新
Calendar Server の管理は、コマンド行ユーティリティを実行し、ics.conf 構成ファイルを編集して行います。
コマンド行ユーティリティを実行するには、Calendar Server が稼動しているシステムに対して管理権限を持つユーザとしてログインする必要があります。
詳細については、第 7 章「Calendar Server コマンド行ユーティリティ、第 8 章「Calendar Server の構成」を参照してください。

Calendar Server の起動と停止

Calendar Server の起動方法と停止方法は、次のとおりです。

Solaris などの UNIX システムと Windows NT システムは、start-cal コマンドと stop-cal コマンドを使用します。「start-cal コマンドと stop-cal コマンドの使用法」を参照してください。

Windows NT システムでは、「コントロールパネル」の「サービス」を使用することもできます。「Windows NT「コントロールパネル」の使用法」を参照してください。

注 Calendar Server には csstart ユーティリティと csstop ユーティリティがありますが、これは旧リリースとの互換性を図ることだけを目的に用意されています。Calendar Server の起動と停止には、start-cal コマンドと stop-cal コマンドを使用することをiPlanet はお勧めします。

start-cal コマンドと stop-cal コマンドの使用法

start-cal ユーティリティと stop-cal ユーティリティは、server-root/cal/bin ディレクトリに入っています。これらのユーティリティは、Calendar Server がインストールされているローカルマシン上で実行する必要があります。発生する可能性がある問題については、「start-cal コマンドと stop-cal コマンドのトラブルシューティング」を参照してください。
start-cal コマンドは、各種の Calendar Server サービスを次の順序で起動します。

enpd－イベント通知サービス (ENS)

csnotifyd－通知サービス

csadmind－管理サービス

csdwpd－分散データベースサービス (リモート Calendar Server データベース構成のときのみ起動される)

cshttpd－HTTP サービス
これらのサービスの詳細については、「Calendar Server サービス」を参照してください。

start-cal コマンドを使用して Calendar Server を起動する手順は、次のとおりです。

システムに対して管理権限を持つユーザとしてログインします。

server-root/cal/bin ディレクトリに移動します。たとえば Solaris システムの場合は次のとおりです。

cd /opt/SUNWics5/cal/bin

Calendar Server を起動します。

./start-cal

stop-cal コマンドを使用して Calendar Server を停止する手順は、次のとおりです。

Calendar Server が稼動しているシステムに対して管理権限を持つユーザとしてログインします。

server-root/cal/bin ディレクトリに移動します。たとえば Solaris システムの場合は次のとおりです。

cd /opt/SUNWics5/cal/bin

Calendar Server を停止します。

./stop-cal

Windows NT「コントロールパネル」の使用法

Windows NT システムの場合には、「コントロールパネル」の「サービス」ダイアログボックスを使用します。

Windows NT の「コントロールパネル」を使用して Calendar Server の起動と停止を行う手順は、次のとおりです。

Windows NT システムに対して管理権限を持つユーザとしてログインします。

「コントロールパネル」から「サービス」ダイアログボックスを表示します。

「スタート」>「設定」>「コントロールパネル」>「サービス」

「サービス」の中の目的の Calendar Server サービス (管理、DWP、HTTP、ENS、または通知) をクリックし、「開始」または「停止」をクリックします。
詳細については、Windows NT のオンラインヘルプを参照してください。

start-cal コマンドと stop-cal コマンドのトラブルシューティング

Calendar Server の起動や停止を行なっているときに、次の問題が発生する可能性があります。

start-cal コマンドによって起動されない Calendar Server プロセスがあります。たとえば enpd、csnotifyd、csadmind といったプロセスは start-cal によって起動されても、cshttpd は起動されないことがあります。この場合、Calendar Server を再起動する前にすべての Calendar Server プロセスを停止する必要があります。

stop-cal コマンドによって停止されない Calendar Server プロセスがあります。たとえば、cshttpd 親プロセスは stop-cal によって停止されても、cshttpd 子プロセスは停止されないことがあります。この場合、残りの Calendar Server プロセスを停止する必要があります。

Windows NT システム上の Calendar Server プロセスを停止する手順は、次のとおりです。

Calendar Server が稼動しているシステムに対して管理権限を持つユーザとしてログインします。

実行中の Calendar Server プロセスをタスクマネージャで確認して停止します。

Solaris と他の UNIX システム上の Calendar Server プロセスを停止する手順は、次のとおりです。

Calendar Server が稼動しているシステムに対して管理権限を持つユーザとしてログインします。

各サービスに対して ps コマンドを次のように入力し、実行中の Calendar Server プロセスのプロセス ID (PID) を調べます。

ps -elf | grep cs-process

cs-process   は、enpd、csnotifyd、csdwpd、csadmind、または cshttpd です。たとえば、次のようになります。

ps -elf | grep cshttpd

実行中のプロセスそれぞれの PID を使用し、pkill -15 コマンドでプロセスを終了します。たとえば、次のようになります。

pkill -15 9875

各 ps コマンドを再び入力し、すべての Calendar Server プロセスが停止したことを確認します。

まだ実行中の Calendar Server プロセスがある場合には、pkill -9 コマンドを使用して終了させます。たとえば、次のようになります。

pkill -9 9875

注意
すべての Calendar Server プロセスを停止したら、Calendar Server を再起動する前に、カレンダーデータベースが破損していないことを csdb ユーティリティの check コマンドでチェックしてみるとよいでしょう。
check コマンドについては、「カレンダーデータベースのチェックと再構築」を参照してください。

Calendar Server タイムアウト値の構成

csadmind のタイムアウト値の構成

エンドユーザの HTTP タイムアウト値の構成
ics.conf パラメータの編集方法については、「ics.conf 構成ファイルの編集」を参照してください。

csadmind のタイムアウト値の構成

表 3-1 は、管理 (csadmin) サービスで使用する ics.conf ファイル内の Calendar Server タイムアウトパラメータを示しています。

表 3-1    管理サービス (csadmin) の HTTP タイムアウト値

パラメータ

説明

service.admin.idletimeout

アイドル状態の HTTP 接続を csadmind サービスがタイムアウトするまでの秒数を指定する
デフォルトは、120 秒 (2 分)

service.admin.resourcetimeout

リソースカレンダーの HTTP セッションを csadmind サービスがタイムアウトするまでの秒数を指定する
デフォルトは、900 秒 (15 分)

service.admin.sessiontimeout

HTTP セッションを csadmind サービスがタイムアウトするまでの秒数を指定する
デフォルトは、1800 秒 (30 分)

エンドユーザの HTTP タイムアウト値の構成

表 3-2 は、ics.conf ファイルに定義されている、エンドユーザに適用される Calendar Server HTTP タイムアウトパラメータを示しています。

表 3-2    ics.conf に定義されている、エンドユーザ (cshttpd サービス) 対象の HTTP タイムアウト値

パラメータ

説明

service.http.idletimeout

アイドル状態の HTTP 接続を、cshttpd サービスがタイムアウトするまでの秒数を指定する
デフォルトは、120 秒 (2 分)

service.http.resourcetimeout

リソースカレンダーの HTTP セッションを、cshttpd サービスがタイムアウトするまでの秒数を指定する
デフォルトは、900 秒 (15 分)

service.http.sessiontimeout

HTTP セッションを cshttpd サービスがタイムアウトするまでの秒数を指定する
デフォルトは、1800 秒 (30 分)

シングルサインオン (SSO) の構成

シングルサインオン (SSO) によって、ユーザーは一度認証されると、その後再度認証されなても複数の信頼アプリケーションを使用することができます。たとえば、Messenger Express と Calendar Express の両方で SSO が有効である場合、いったん Messenger Express にログインしたユーザは、再度認証されなくても Calendar Express を使用することができます。
SSO を構成する際は、次の点に注意してください。

各信頼アプリケーションを SSO 用に構成する必要があります。

default.html ページがブラウザのキャッシュに入っている場合は、SSO は正しく動作しません。SSO を使用する前に、必ず default.html ページをブラウザに再読み込みしてください。たとえば Netscape Navigator の場合には、Shift キーを押し下げて「再読込」をクリックします。

SSO は、裸の URL に対してのみ機能します。たとえば、http://servername の場合は SSO が機能しますが、http://servername/command.shtml?view のような URL に対しては機能しません。
次の例は、sesta.com ドメインにおける Calendar Server (Calendar Express) と Messaging Server (Messenger Express) の SSO 構成を示しています。

シングルサインオン (SSO) を構成する手順は、次のとおりです。

管理権限を持つユーザとしてログインします。

Calendar Server と Messaging Server を停止します。

表 3-3 のとおりに Calendar Server の ics.conf ファイルを編集します (Calendar Server SSO 構成パラメータについては、「シングルサインオン(SSO)の構成」を参照してください)。

表 3-3    SSO のための Calendar Server 構成

パラメータ

説明

sso.enable = "1"

SSO を有効にするには、このパラメータを "1" (デフォルト) に設定する必要がある。"0" は、SSO を無効にする

sso.appid = "ics50"

このパラメータは、特定の Calendar Server インストレーションに一意のアプリケーション ID を指定する。各信頼アプリケーションにも、一意のアプリケーション ID を持たせる必要がある。デフォルトは、"ics50"

sso.appprefix = "ssogrp1"

このパラメータは、SSO cookie のフォーマッティングに使用する接頭辞の値を指定する。Calendar Server はこの接頭辞を持つ SSO cookie だけを認識することになるので、信頼アプリケーションすべてが同じ値を使用する必要がある。デフォルトは、"ssogrp1"

sso.cookiedomain = ".sesta.com"

このパラメータにより、ブラウザは指定ドメインに属するサーバだけに cookie を送信する。値の先頭は、ピリオド (.) で始める必要がある

sso.singlesignoff = "true"

値が "true" (デフォルト) の場合、sso.appprefix に設定されている値と一致する接頭辞を持つクライアント上の全ての SSO cookie を、クライアントがログアウトするときにすべてクリアする

sso.userdomain = "sesta.com"

このパラメータは、ユーザの SSO 認証の一部として使用されるドメインを設定する。

sso.appid.url = "verifyurl"
たとえば、次のようになります。
sso.ics50.url = "http://sesta.com:8883/VerifySSO?"
sso.msg50.url = "http://sesta.com:8882/VerifySSO?"

このパラメータは、Calendar Server 構成の SSO ピアホストの URL 検証値を設定する。1 つの信頼される SSO ピアホストにつき、1 つのパラメータが必要です。パラメータは、以下で構成される

アプリケーション ID (appid) は、受け付けるべき SSO cookie を持つ SSO ピアホストを示す

URL 検証 ("verifyurl") は、ホスト URL、ホストポート番号、および VerifySSO? (末尾の ? も含む) で構成される

この例の Calendar Server アプリケーション ID は ics50、ホスト URL は sesta.com、ポートは 8883
また、Messenger Express アプリケーション ID は msg50、ホスト URL は sesta.com、ポートは 8882

表 3-4 に従い、configutil を使用して Messaging Server の構成パラメータを設定します。これらのパラメータを二重引用符 (") で囲む必要はありません。

表 3-4    SSO のための Messaging Server 構成

パラメータ

説明

local.webmail.sso.enable = 1

SSO を有効にするには、このパラメータをゼロ以外の値に設定する必要がある

local.webmail.sso.prefix = ssogrp1

このパラメータは、HTTP サーバが設定する SSO cookie のフォーマッティングで使用する接頭辞を指定する

local.webmail.sso.id = msg50

このパラメータは、Messaging Server に一意のアプリケーション ID (msg50) を指定する
各信頼アプリケーションにも、一意のアプリケーション ID を持たせる必要がある

local.webmail.sso.cookiedomain = .sesta.com

このパラメータは、HTTP サーバが設定するすべての SSO cookie の cookie ドメイン値を指定する

local.webmail.sso.singlesignoff = 1

ゼロ以外の値の場合、local.webmail.sso.prefix に設定されている値と一致する接頭辞を持つクライアント上の SSO cookie は、クライアントがログアウトするときにすべてクリアされる

sso.appid.url = "verifyurl"
たとえば、次のようになります。
local.sso.ics50.verifyurl = http://sesta.com:8883/VerifySSO?
local.sso.msg50.verifyurl = http://sesta.com:8882/VerifySSO?

このパラメータは、Messaging Server 構成の SSO ピアホストの URL 検証値を設定する。1 つの信頼される SSO ピアホストにつき、1 つのパラメータが必要。パラメータは、以下で構成される

アプリケーション ID (appid) は、受け付けるべき SSO cookie を持つ SSO ピアホストを示す

URL 検証 ("verifyurl") は、ホスト URL、ホストポート番号、および VerifySSO? (末尾の ? も含む) で構成される

この例の Messaging Server アプリケーション ID は msg50、ホスト URL は sesta.com、ポートは 8882
また、Calendar Server アプリケーション ID は ics50、ホスト URL は sesta.com、ポートは 8883

Calendar Server と Messaging Server を再起動し、構成を更新します。

詳細については、「Calendar Server の起動と停止」を参照してください。Messaging Server については、『iPlanet Messaging Server 管理者ガイド』を参照してください。

データベースワイヤプロトコル (DWP) の構成

DWP は Calendar Server で使用されるプロプライエタリプロトコルであり、ネットワーク上でカレンダーデータベースの操作を行います。DWP はトランスポートメカニズムとして HTTP を使用し、カレンダーデータベース API のサブセットが組み込まれています。
カレンダーデータベースがローカルサーバ上に常駐している場合は、Calendar Server Database サブシステムは、calid を使用してデータベース内のカレンダーにアクセスします。ただし、カレンダーデータベースがネットワーク上に存在している場合 (バックエンドサーバ上など)、Calendar Server は、カレンダーが実際に常駐しているサーバのネットワークアドレスを決定するためにカレンダー検索データベースプラグインを使用する必要があります。それから、他のサーバ上の DWP (csdwpd) サービスにリクエストが送られて処理されます。

1 台のフロントエンドマシンと 1 台のバックエンドサーバ

図 3-1 は、1 台のフロントエンドマシンと 1 台のバックエンドサーバを使用した Calendar Server 構成を示しています。DWP を使用するには、フロントエンドマシンとバックエンドサーバが同じオペレーティングシステムを使用しており、かつ同じバージョンの Calendar Server (たとえば 5.1) を使用している必要があります。
図 3-1    1 台のフロントエンドマシンと 1 台のバックエンドサーバによる Calendar Server 構成

図 3-1 に示されている構成におけるフロントエンドマシンは、次の処理を行います。

ネットワーク上に常駐するカレンダーデータに対するクライアント要求を処理する。

バックエンドサーバに対してカレンダーデータを要求する。

カレンダーデータを最初に XML ドキュメントツリーに変換する。

XSL ファイルを XML ドキュメントツリーに適用して HTML を出力する。

HTML をクライアントに送り返す。
バックエンドサーバは、次の処理を行う。

あらゆるカレンダーデータベース要求を処理する。

グループスケジューリングエンジン (GSE) 要求キューを処理する。

アラームキューを監視する。

ens サービスと csnotifyd サービスを使用してアラームを送信する。
DWP を構成するには、フロントエンドマシンとバックエンドサーバの両方で ics.conf パラメータを設定する必要があります。

フロントエンドマシン上で DWP パラメータを構成する手順は、次のとおりです。

管理特権を持つユーザとして、フロントエンドマシンにログインします。

Calendar Server コマンド行ユーティリティが入っている server-root/cal/bin ディレクトリに移動し、stop-cal コマンドを使用して Calendar Server を停止します。

server-root/cal/bin/config/ ディレクトリに移動し、表 3-5 に示されている ics.conf パラメータを編集します (複数台のフロントエンドマシンと 1 台のバックエンドサーバを使用して構成する方法については、複数のフロントエンドマシンを参照してください)。

表 3-5    フロントエンドマシンの DWP 構成パラメータ

パラメータ

説明

service.http.enable = "yes"

"yes" (デフォルト) は、ローカル構成が cshttpd サービスを必要とすることを意味する

csapi.plugin.calendarlookup = "y"

"y" (yes) を設定すると、CSAPI サブシステムがカレンダー検索データベースを読み込む

csapi.plugin.calendarlookup.name = "*"

このパラメータは、プラグイン名を指定する。現行リリースでは、"*" (デフォルト) を設定すると、CSAPI サブシステムがカレンダー検索データベースプラグインを読み込む

caldb.cld.type = "algorithmic"

このパラメータは、使用するカレンダー検索データベースプラグインを指定する。デフォルトは "local" ですが、hostname サーバに正常に接続するためには "algorithmic" を設定する。

caldb.dwp.server.hostname.ip = "hostname"

このパラメータは、DWP サービスが稼動しているバックエンドサーバの名前 (ネットワークアドレス) を指定する。このパラメータは DWP を使用するサービスすべてに読み込まれ、起動時には各サービスが DWP サービスと接続しようとする
たとえばサーバ名が sesta であるとき、このパラメータは次のようになる
caldb.dwp.server.sesta.ip = "sesta"

caldb.dwp.server.hostname.port = "9779"

このパラメータは、DWP (csdwpd) サービスが使用するポートを指定する。デフォルトは、"9779" です。このパラメータは、caldb.dwp.server.hostname.ip 値とともに使用されする。hostname 部分は、 caldb.dwp.server.hostname.ip の中の hostname と同じにする必要がある。たとえば、次のようになる
caldb.dwp.server.sesta.port = "9779"

caldb.cld.server.hostname.regexpr = "expression"

caldb.cld.type が "algorithmic" である場合、このパラメータは、指定のカレンダー ID が格納されている物理サーバを決定するためにカレンダー検索データベースプラグインが使用する正規表現を指定する。たとえば、次のようになる
caldb.cld.server.sesta.regexpr = "^[^\n]"
これは、sesta サーバ上のカレンダー ID すべてに一致する

Calendar Server コマンド行ユーティリティが入っている server-root/cal/bin ディレクトリに移動し、start-cal コマンドを使用して Calendar Server を再起動します。

フロントエンドマシンでは、cshttpd サービスと csadmind サービスが必要です。

バックエンドサーバ上で DWP パラメータを構成する手順は、次のとおりです。

管理特権を持つユーザとしてバックエンドサーバにログインします。

Calendar Server コマンド行ユーティリティが入っている server-root/cal/bin ディレクトリに移動し、stop-cal コマンドを使用して Calendar Server を停止します。

server-root/cal/bin/config/ ディレクトリに移動し、表 3-6 に示されている ics.conf パラメータを編集します。

表 3-6    単一バックエンドサーバにおける DWP 構成パラメータ

パラメータ

説明

service.dwp.enable = "yes"

DWP (csdwpd) サービスを有効にする。他のサービスを起動したときに、Calendar Server が csdwpd サービスを起動する。また、service.dwp.port に指定されているポートで csdwpd サービスが待機する
デフォルトは "no" であるため、"yes" に設定しなおす必要がある

service.dwp.port = "9779"

このパラメータは、csdwpd サービスが使用するポートを指定する
デフォルトは、"9779"

service.notify.enable = "yes"
service.admin.enable = "yes"
service.ens.enable = "yes"

バックエンドサーバ上の各々の呼サービスを有効にする。各々サービスを有効にするには、"yes" (デフォルト) に設定する必要がある

Calendar Server コマンド行ユーティリティが入っている server-root/cal/bin ディレクトリに移動し、start-cal コマンドを使用して、Calendar Server を再起動します。

バックエンドサーバでは、csdwpd、csadmind、enpd、および csnotifyd の各サービスが必要です。

以上の結果、フロントエンドマシンから Calendar Express を使用して、バックエンドサーバ上の Calendar Server データベースにアクセスできます。その仕組みは、次のとおりです。
フロントエンドマシン上で起動された cshttpd サービスは、データベースサブシステムを初期化します。このサービスは、caldb.dwp.server.host.ip パラメータと caldb.dwp.server.host.port パラメータを ics.conf ファイルから読み込み、ホスト IP アドレス値とポート値を使用してバックエンドサーバとの接続を試みます。接続が成功すると、cshttpd サービスはバックエンドサーバ上で DWP トランザクションに排他的に使用される csdwpd サービスに関連づけて、接続プールを作成します。
この接続プールの初期サイズは、caldb.dwp.initconns. パラメータの値に設定されますが、caldb.dwp.maxcons パラメータで指定した最大値まで増やすことができます。プール内の各接続は HTTP/1.1 持続接続であり、何らかの接続上の障害があると、エラーメッセージがログファイルに書き込まれます。
フロントエンドマシンとバックエンドサーバとの DWP 接続が切断されると (たとえば、バックエンドサーバを再起動するなど)、フロントエンドマシンはバックエンドサーバとの再接続を試みます。DWP 接続が切断されている間はカレンダーデータに対するリクエストは失敗し、接続が回復するまでデータは利用不能になります。

複数のフロントエンドマシン

図 3-2 は、複数のフロントエンドマシンと 1 台のバックエンドサーバを使用した Calendar Server 構成を示しています。2 台のフロントエンドマシン (cal1.example.com と cal2.example.com) の構成パラメータは同じであり、フロントエンドマシン上で DWP パラメータを構成する手順は page 69で説明しています。フロントエンドマシンをさらに追加してフロントエンドの負荷を分散することが可能です。
図 3-2    複数のフロントエンドマシンと 1 台のバックエンドサーバによる Calendar Server 構成

LDAP 属性の管理

Calendar Server が使用する LDAP 属性を管理するには、csattribute ユーティリティを使用します。

LDAP 属性の一覧表示

ユーザやリソースの LDAP 属性をリストするには、csattribute ユーティリティの add コマンドを使用します。たとえば、TChang というユーザの LDAP 属性を一覧表示するには、次のコマンドを入力します。
csattribute list TChang

LDAP 属性の追加

LDAP サーバに属性を追加するには、csattribute ユーティリティの add コマンドを使用します。たとえば、ユーザ TChang に Conference_Schedule の値を持つ LDAP 属性 icsCalendar を追加するには、次のコマンドを入力します。
csattribute -a icsCalendar=Conference_Schedule add TChang

LDAP 属性の削除

LDAP サーバから属性を削除するには、csattribute ユーティリティの delete コマンドを使用します。たとえば、TChang から LDAP 属性 icsCalendar を削除するには、次のコマンドを入力します。
csattribute -a icsCalendar delete TChang

グループスケジューリングエンジン (GSE) キューの管理

グループスケジューリングによって、Calendar Server ユーザは会議などのイベントを作成し、他の出席者に出席依頼をすることができます。空き時間検索機能を使用すれば、出席依頼をうけた人がイベントに実際に参加できるかどうかを確認できます。
出席予定者が同じ Calendar Server 上に存在する場合、イベントは出席者のカレンダーにスケジューリングされます。出席予定者が同じ Calendar Server 上に存在しない場合は、出席依頼が電子メールで送られます。出席予定者は、この出席依頼を受諾または拒否します。
Calendar Server ユーザは、出席者のカレンダーを並べて表示し、グループスケジュールを比較することもできます。
GSE キューのエントリを管理するには、csschedule ユーティリティを使用します。csschedule は、Calendar Server がインストールされているローカルマシン上で実行する必要があります。

GSE キューのエントリの一覧表示

GSE キューのエントリをリストするには、csschedule ユーティリティの list コマンドを使用します。たとえば、GSE キューのエントリすべてをリストするには、次のコマンドを入力します。
csschedule list
GSE キューに格納されている先頭から 10 個のエントリを一覧表示するには、次のコマンドを入力します。
csschedule -c 10 list
Holiday_Schedule という calid を持つカレンダーの GSE キューのエントリすべてを一覧表示するには、次のコマンドを入力します。
csschedule -v list Holiday_Schedule

GSE キューのエントリの削除

GSE キューのエントリを削除するには、csschedule ユーティリティの delete コマンドを使用します。たとえば、GSE キューのエントリすべてを削除するには、次のコマンドを入力します。
csschedule -v delete
カレンダー calA の GSE キューにある、最初のスケジュール時間が 2001 年 11 月 30 日の 13:30:45、オフセット番号 1、一意識別子 1111、繰り返し ID 0、シーケンス番号 0 のエントリを削除するには、次のコマンドを入力します。
csschedule -v -t 20011130T133045Z -o 1 -u 1111 -r 0 -n 0 delete calA

Calendar Server の監視

Calendar Server アクティビティを監視するには、csstats ユーティリティと cstool ユーティリティを使用します。以降では、次の項目について説明します。

カウンタ統計の一覧表示

Calendar Server ログファイルの監視

 カウンタ統計の一覧表示

csstats ユーティリティは、カレンダー構成ファイル (counter.conf) に定義されているカウンタオブジェクトからの統計情報を表示します。httpstat、authstat、wcapstat、dbstat などのカウンタオブジェクトは、次のような Calendar Server 情報を表示します。

最大同時接続数と合計接続数

ログインと接続の成功数と失敗数の合計

データベースの読み取り、書き込み、および削除の数
Calendar Server カウンタ統計の詳細については、カウンタ構成(counter.conf)ファイルを参照してください。
統計情報を一覧表示するには、csstats ユーティリティの list コマンドを使用します。たとえば、利用できるカウンタオブジェクトとタイプに関する基本情報を表示するには、次のコマンドを入力します。
csstats list
httpstat カウンタオブジェクトに関する統計をリストするには、次のコマンドを入力します。
csstats list http
wcapstat カウンタオブジェクトに関する統計を 1 時間の間 10 秒ごとにリストするには、次のコマンドを入力します。
csstats -i 360 -s 10 list wcap

Calendar Server ログファイルの監視

Calendar Server サービスは、ステータス情報を各自のログファイルに書き込みます。各ログファイルには、表 3-7 のとおり、対応するサービス名に基づく名前が付いています。

表 3-7    Calendar Server ログファイル

サービス名

ログファイル名

csadmind

admin.log

csdwpd

dwp.log

cshttpd

http.log

csnotifyd

notify.log

Calendar Server ログファイルは、デフォルトのログディレクトリに格納されます。

Solaris システムの場合

/var/opt/SUNWics5/logs

Solaris 以外の UNIX システムの場合

/var/opt/iPlanet/CalendarServer5/logs

Windows NT システムの場合

c:\Program Files\iPlanet\CalendarServer5\var\logs

各ログファイルは、以下のとおり、設定されている時間とサイズ制限に基づく、新しい名前を持つ新しいログファイルと交換されます。
サービス名.タイムスタンプ.#
たとえば、次のようになります。
admin.20000801115354.1
http.20000801115354.2

ログイベント重要度レベル

表 3-8 に示されているとおり、Calendar Server のログファイルに書き込まれるイベントの重要度には 8 種類のレベルがあります。

表 3-8    iPlanet Calendar Server ログエラー重要度レベル

重要度レベル

意味

EMERGENCY

システムが使用不能。重要度が最も高い (最も問題がある) イベントを示す

ALERT

ただちに処置を施す必要がある

CRITICAL

重大な状態

ERROR

エラー

WARNING

警告

NOTICE

正常ではあるが、通知の必要がある状態。これが、各カレンダーサービスにおけるデフォルトのレポートレベル

INFORMATION

情報

DEBUG

デバッグレベルのメッセージ

ログイベントは、関連する、タイムスタンプ、サーバのホスト名、重要度レベル、プロセス名 (プロセス ID)、イベントのタイプ、優先順位、および記述を 1 行にして表されます。ics.conf ファイル特定の構成の設定値を変更することにより、Calendar Server がログファイルに出力するイベントの重要度レベルを指定することができます。これについては、カレンダーログ情報の構成を参照してください。
EMERGENCY、ALERT、CRITICAL、ERROR、および WARNING のレベルのエラーが発生したかどうかをログファイルを調べて定期的にチェックし、発生していた場合には、イベントを調査して Calendar Server の動作に問題がないかどうかを確認します。NOTICE と INFORMATION のレベルのログイベントは、Calendar Server が正常に稼動しているときに出力され、サーバのアクティビティの監視を助けるものです。

注 Calendar Server に関してテクニカルサポートを要請する際、問題解決の手段としてログファイルの提出が求められることがあります。

Calendar Server の ping

Calendar Server サービスが指定のポート番号を使用していることを確認するには、cstool ユーティリティの ping コマンドを使用します。サービスを ping してもサービスが実際に稼動しているかどうかは確認されませんが、ソケット接続を受け付けるかどうかを知ることができます。
Calendar Server サービスオプションは、次のとおりです。

http－HTTP サービス (cshttpd)

admin－管理サービス (csadmind)

注現在のリリースでは、分散データベースサービス (csdwpd)、イベント通知サービス (enpd)、および通知サービス (csnotifyd) の ping は行えません。

cstool を実行するには、Calendar Server が稼動している必要があります。
たとえば、calserver というホスト名を持つマシンを ping して cshttpd サービスがポート 80 を使用しているかどうかを確認するには、次のコマンドを入力します。
cstool -p 80 -h calserver ping http
デフォルトの場合、cstool は応答を 120 秒間待ちますが、-t timeout オプションを使用すると、この値を変更できます。

Calendar Server 構成の更新

Calendar Server サービスの構成の更新を強制するには、cstool ユーティリティの refresh コマンドを使用します。サービスを指定しなかった場合、すべての Calendar Server サービスの構成が更新されます。
cstool を実行するには、Calendar Server が稼動している必要があります。
たとえば、ローカル Calendar Server に全サービスの構成を更新させるには、次のコマンドを入力します。
cstool refresh

パラメータ	説明
service.admin.idletimeout	アイドル状態の HTTP 接続を csadmind サービスがタイムアウトするまでの秒数を指定するデフォルトは、120 秒 (2 分)
service.admin.resourcetimeout	リソースカレンダーの HTTP セッションを csadmind サービスがタイムアウトするまでの秒数を指定するデフォルトは、900 秒 (15 分)
service.admin.sessiontimeout	HTTP セッションを csadmind サービスがタイムアウトするまでの秒数を指定するデフォルトは、1800 秒 (30 分)

パラメータ	説明
service.http.idletimeout	アイドル状態の HTTP 接続を、cshttpd サービスがタイムアウトするまでの秒数を指定するデフォルトは、120 秒 (2 分)
service.http.resourcetimeout	リソースカレンダーの HTTP セッションを、cshttpd サービスがタイムアウトするまでの秒数を指定するデフォルトは、900 秒 (15 分)
service.http.sessiontimeout	HTTP セッションを cshttpd サービスがタイムアウトするまでの秒数を指定するデフォルトは、1800 秒 (30 分)

パラメータ	説明
sso.enable = "1"	SSO を有効にするには、このパラメータを "1" (デフォルト) に設定する必要がある。"0" は、SSO を無効にする
sso.appid = "ics50"	このパラメータは、特定の Calendar Server インストレーションに一意のアプリケーション ID を指定する。各信頼アプリケーションにも、一意のアプリケーション ID を持たせる必要がある。デフォルトは、"ics50"
sso.appprefix = "ssogrp1"	このパラメータは、SSO cookie のフォーマッティングに使用する接頭辞の値を指定する。Calendar Server はこの接頭辞を持つ SSO cookie だけを認識することになるので、信頼アプリケーションすべてが同じ値を使用する必要がある。デフォルトは、"ssogrp1"
sso.cookiedomain = ".sesta.com"	このパラメータにより、ブラウザは指定ドメインに属するサーバだけに cookie を送信する。値の先頭は、ピリオド (.) で始める必要がある
sso.singlesignoff = "true"	値が "true" (デフォルト) の場合、sso.appprefix に設定されている値と一致する接頭辞を持つクライアント上の全ての SSO cookie を、クライアントがログアウトするときにすべてクリアする
sso.userdomain = "sesta.com"	このパラメータは、ユーザの SSO 認証の一部として使用されるドメインを設定する。
sso.appid.url = "verifyurl" たとえば、次のようになります。 sso.ics50.url = "http://sesta.com:8883/VerifySSO?" sso.msg50.url = "http://sesta.com:8882/VerifySSO?"	このパラメータは、Calendar Server 構成の SSO ピアホストの URL 検証値を設定する。1 つの信頼される SSO ピアホストにつき、1 つのパラメータが必要です。パラメータは、以下で構成されるアプリケーション ID (appid) は、受け付けるべき SSO cookie を持つ SSO ピアホストを示す URL 検証 ("verifyurl") は、ホスト URL、ホストポート番号、および VerifySSO? (末尾の ? も含む) で構成されるこの例の Calendar Server アプリケーション ID は ics50、ホスト URL は sesta.com、ポートは 8883 また、Messenger Express アプリケーション ID は msg50、ホスト URL は sesta.com、ポートは 8882

パラメータ	説明
local.webmail.sso.enable = 1	SSO を有効にするには、このパラメータをゼロ以外の値に設定する必要がある
local.webmail.sso.prefix = ssogrp1	このパラメータは、HTTP サーバが設定する SSO cookie のフォーマッティングで使用する接頭辞を指定する
local.webmail.sso.id = msg50	このパラメータは、Messaging Server に一意のアプリケーション ID (msg50) を指定する各信頼アプリケーションにも、一意のアプリケーション ID を持たせる必要がある
local.webmail.sso.cookiedomain = .sesta.com	このパラメータは、HTTP サーバが設定するすべての SSO cookie の cookie ドメイン値を指定する
local.webmail.sso.singlesignoff = 1	ゼロ以外の値の場合、local.webmail.sso.prefix に設定されている値と一致する接頭辞を持つクライアント上の SSO cookie は、クライアントがログアウトするときにすべてクリアされる
sso.appid.url = "verifyurl" たとえば、次のようになります。 local.sso.ics50.verifyurl = http://sesta.com:8883/VerifySSO? local.sso.msg50.verifyurl = http://sesta.com:8882/VerifySSO?	このパラメータは、Messaging Server 構成の SSO ピアホストの URL 検証値を設定する。1 つの信頼される SSO ピアホストにつき、1 つのパラメータが必要。パラメータは、以下で構成されるアプリケーション ID (appid) は、受け付けるべき SSO cookie を持つ SSO ピアホストを示す URL 検証 ("verifyurl") は、ホスト URL、ホストポート番号、および VerifySSO? (末尾の ? も含む) で構成されるこの例の Messaging Server アプリケーション ID は msg50、ホスト URL は sesta.com、ポートは 8882 また、Calendar Server アプリケーション ID は ics50、ホスト URL は sesta.com、ポートは 8883

パラメータ	説明
service.http.enable = "yes"	"yes" (デフォルト) は、ローカル構成が cshttpd サービスを必要とすることを意味する
csapi.plugin.calendarlookup = "y"	"y" (yes) を設定すると、CSAPI サブシステムがカレンダー検索データベースを読み込む
csapi.plugin.calendarlookup.name = "*"	このパラメータは、プラグイン名を指定する。現行リリースでは、"*" (デフォルト) を設定すると、CSAPI サブシステムがカレンダー検索データベースプラグインを読み込む
caldb.cld.type = "algorithmic"	このパラメータは、使用するカレンダー検索データベースプラグインを指定する。デフォルトは "local" ですが、hostname サーバに正常に接続するためには "algorithmic" を設定する。
caldb.dwp.server.hostname.ip = "hostname"	このパラメータは、DWP サービスが稼動しているバックエンドサーバの名前 (ネットワークアドレス) を指定する。このパラメータは DWP を使用するサービスすべてに読み込まれ、起動時には各サービスが DWP サービスと接続しようとするたとえばサーバ名が sesta であるとき、このパラメータは次のようになる caldb.dwp.server.sesta.ip = "sesta"
caldb.dwp.server.hostname.port = "9779"	このパラメータは、DWP (csdwpd) サービスが使用するポートを指定する。デフォルトは、"9779" です。このパラメータは、caldb.dwp.server.hostname.ip 値とともに使用されする。hostname 部分は、 caldb.dwp.server.hostname.ip の中の hostname と同じにする必要がある。たとえば、次のようになる caldb.dwp.server.sesta.port = "9779"
caldb.cld.server.hostname.regexpr = "expression"	caldb.cld.type が "algorithmic" である場合、このパラメータは、指定のカレンダー ID が格納されている物理サーバを決定するためにカレンダー検索データベースプラグインが使用する正規表現を指定する。たとえば、次のようになる caldb.cld.server.sesta.regexpr = "^[^\n]" これは、sesta サーバ上のカレンダー ID すべてに一致する

パラメータ	説明
service.dwp.enable = "yes"	DWP (csdwpd) サービスを有効にする。他のサービスを起動したときに、Calendar Server が csdwpd サービスを起動する。また、service.dwp.port に指定されているポートで csdwpd サービスが待機するデフォルトは "no" であるため、"yes" に設定しなおす必要がある
service.dwp.port = "9779"	このパラメータは、csdwpd サービスが使用するポートを指定するデフォルトは、"9779"
service.notify.enable = "yes" service.admin.enable = "yes" service.ens.enable = "yes"	バックエンドサーバ上の各々の呼サービスを有効にする。各々サービスを有効にするには、"yes" (デフォルト) に設定する必要がある

サービス名	ログファイル名
csadmind	admin.log
csdwpd	dwp.log
cshttpd	http.log
csnotifyd	notify.log

重要度レベル	意味
EMERGENCY	システムが使用不能。重要度が最も高い (最も問題がある) イベントを示す
ALERT	ただちに処置を施す必要がある
CRITICAL	重大な状態
ERROR	エラー
WARNING	警告
NOTICE	正常ではあるが、通知の必要がある状態。これが、各カレンダーサービスにおけるデフォルトのレポートレベル
INFORMATION	情報
DEBUG	デバッグレベルのメッセージ

前へ目次索引 DocHome 次へ
Copyright © 2002 Sun Microsystems, Inc. All rights reserved.

最終更新日： 2002 年 1 月 22 日