第 3 章 Calendar Server の管理

この章では、Sun^TM ONE Calendar Server の設定や管理の手順について説明します。

Calendar Server の管理は、コマンド行ユーティリティの実行と、ics.conf 設定ファイルの編集によって行われます。

コマンド行ユーティリティを実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。

Calendar Server の起動と停止

start-cal ユーティリティと stop-cal ユーティリティの使用


注	Calendar Server に用意されている csstart と csstop の各ユーティリティは、従来リリースとの互換性維持だけを目的としています。Calendar Server の起動と停止には、start-cal と stop-cal を使用することをお勧めします。

start-cal と stop-cal の各ユーティリティは、cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに格納されています。これらのユーティリティを Calendar Server がインストールされているローカルマシンで実行する必要があります。これに関連する問題については、「start-cal ユーティリティと stop-cal ユーティリティのトラブルシューティング」を参照してください。

start-cal ユーティリティは次の順序で Calendar Server サービスを開始します。

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

csnotifyd : 通知サービス

csadmind : 管理サービス

csdwpd : DWP (データベースワイヤプロトコル) サービス。リモート Calendar Server データベース設定だけによって起動される分散データベースサービス

cshttpd : HTTP サービス

これらのサービスの説明については、「Calendar Server Services」を参照してください。

start-cal コマンドを使用して Calendar Server を起動するには

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

cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。

Calendar Server を起動します。

./start-cal

stop-cal コマンドを使用して Calendar Server を停止するには

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

cal_svr_base/opt/SUNWics5/cal/sbin ディレクトリに移動します。

Calendar Server を停止します。

./stop-cal

start-cal ユーティリティと stop-cal ユーティリティのトラブルシューティング

Calendar Server の起動時と停止時に、次の問題が発生する可能性があります。

start-cal ユーティリティを実行しても Calendar Server の一部のプロセスが開始されない。たとえば、start-cal によって enpd、csnotifyd、csadmind プロセスは開始されるが、cshttpd が開始されない。このような場合は、Calendar Server の再起動を試みる前に、すべての Calendar Server プロセスを停止する必要がある

stop-cal ユーティリティを実行しても Calendar Server の一部のプロセスが終了されない。たとえば、stop-cal によって cshttpd 親プロセスは終了されるが、すべての cshttpd 子プロセスが終了されない。このような場合は、残りの Calendar Server プロセスを終了する必要がある

Solaris システムの 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

pkill -15 コマンドに終了されていない各プロセスの PID を指定して、プロセスを終了します。
例 :

pkill -15 9875

それぞれの ps コマンドをもう一度実行し、すべての Calendar Server プロセスが終了されていることを確認します。

稼動している Calendar Server プロセスが見つかったときは、pkill -9 コマンドを実行して終了します。
例 :

pkill -9 9875


警告	Calendar Server のすべてのプロセスを終了したら、Calendar Server を再起動する前に csdb ユーティリティの check コマンドを実行し、カレンダーデータベースに破損が生じているかどうかを確認します。 check コマンドについては、「カレンダーデータベースのチェックと再構築」を参照してください。

Calendar Server のタイムアウト値の設定

csadmind のタイムアウト値の設定

エンドユーザーの HTTP タイムアウト値の設定

csadmind のタイムアウト値の設定

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

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

エンドユーザーの HTTP タイムアウト値の設定

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

表 3-2 ics.conf に設定され、エンドユーザーに適用される HTTP タイムアウト値 (cshttpd サービス)
パラメータ	説明
service.http.idletimeout	cshttpd サービスがアイドル状態の HTTP 接続をタイムアウトにするまでの秒数デフォルトは 120 秒 (2 分)
service.http.resourcetimeout	cshttpd サービスがリソースカレンダーの HTTP セッションをタイムアウトにするまでの秒数デフォルトは 900 秒 (15 分)
service.http.sessiontimeout	cshttpd サービスが HTTP セッションをタイムアウトにするまでの秒数デフォルトは 1800 秒 (30 分)

シングルサインオン (SSO) の設定

シングルサインオン (SSO) を利用することで、ユーザーは認証を一度受けるだけで、信頼できる複数のアプリケーションを追加認証なしで使用できます。Calendar Server と Messaging Server を含め、Sun ONE Communications サーバーは次の方法で SSO を実装できます。

Identity Server による SSO の設定

Communications サーバーの信頼できるサークルテクノロジを利用した SSO の設定

Identity Server による SSO の設定

Calendar Server、Messaging Server を含め、Sun ONE サーバーは、Sun ONE Identity Server 6.1 以降を使用して SSO を実装できます。

Identity Server は、Sun ONE サーバーの SSO ゲートウェイとして機能します。ユーザーは Identity Server にログインすると、その他の Sun ONE サーバーで SSO が適切に設定されている限り、それらのサーバーにもアクセスできます。

Calendar Server で SSO を利用するには、次の手順を実行します。

Sun ONE Identity Server と Sun ONE Directory Server がインストールされ、設定が完了していることを確認します。これらの製品のインストールと設定については、『Sun Java Enterprise System インストールガイド』を参照してください。

表 3-3 に示されるパラメータを設定して Calendar Server 用の SSO を設定し、変更が適用されるように Calendar Server を再起動します。パラメータを設定するときは、必要に応じてコメント記号 (!) を外します。

注 : local.calendar.sso.amnamingurl パラメータを設定するときは、Identity Server の完全修飾名を指定する必要があります。

Messaging Server で SSO を利用するための設定については、『Sun ONE Messaging Server 6.0 Administrator's Guide』を参照してください。

ユーザーは、Directory Server LDAP ユーザー名とパスワードを使用して Identity Server にログインします。(Calendar Server や Messaging Server など、これ以外のサーバーにログインしたユーザーは SSO を利用できず、他の Sun ONE サーバーにアクセスできません。)

ログインが完了すると、ユーザーは適切な URL を指定して Calendar Express 経由で Calendar Server にアクセスできます。サーバーに SSO が適切に設定されていれば、Messaging Server など、その他の Sun ONE サーバーにもアクセスできます。

表 3-3 Identity Server を使用して SSO を設定するための Calendar Server 設定パラメータ
パラメータ	説明
local.calendar.sso.amnamingurl	Identity Server の SSO ネーミングサービスの URL を指定するデフォルトは、http://IdentityServer:port/amserver/namingservice ここで、IdentityServer は Identity Server の完全修飾名、port は Identity Server のポート番号
local.calendar.sso.amcookiename	Identity Server の SSO cookie 名を指定するデフォルトは iPlanetDirectoryPro
local.calendar.sso.amloglevel	Identity Server SSO のログレベルを指定する。範囲は 1 (少量) から 5 (詳細)。デフォルトは 3
local.calendar.sso.logname	Identity Server の SSO API ログファイル名を指定するデフォルトは am_sso.log
local.calendar.sso.singlesignoff	Calendar Server から Identity Server へのシングルサインオフを有効 (yes) または無効 (no) にする有効にした場合、ユーザーが Calendar Server からログアウトすると、そのユーザーは Identity Server からもログアウトされる。また、そのユーザーが Identity Server 経由で開始したすべてのセッション (Messaging Server の webmail セッションなど) も切断される Identity Server は認証ゲートウェイであるため、Identity Server から Calendar Server へのシングルサインオフは、常に有効になっているデフォルトは yes

Identity Server を利用した SSO についての考慮点

カレンダーセッションが有効なのは、Identity Server のセッションが有効である期間に限られます。ユーザーが Identity Server からログアウトすると、そのユーザーのカレンダーセッションは自動的に閉じられます (シングルサインオフ)。

SSO アプリケーションは、同じドメインに存在する必要があります。

SSO アプリケーションは、Identity Server の検証 URL (ネーミングサービス) にアクセスできる必要があります。

ブラウザは、Cookie をサポートしている必要があります。

Sun ONE Portal Server ゲートウェイを使用している場合は、次の Calendar Server パラメータを設定します。

service.http.ipsecurity="no"

render.xslonclient.enable="no"

Communications サーバーの信頼できるサークルテクノロジを利用した SSO の設定

Communications サーバーの信頼できるサークルテクノロジを利用して (つまり Identity Server を使用せずに) SSO を設定する場合は、次の点に注意してください。

信頼できるアプリケーションのそれぞれで SSO を設定する必要があります。

ブラウザのキャッシュに default.html ページが含まれている場合、SSO は正しく機能しません。SSO を使用する前に、ブラウザで default.html ページを再度読み込んでください。たとえば、Netscape Navigator であれば、Shift キーを押しながら更新ボタンをクリックします。

SSO は、「修飾されていない」URL だけで機能します。たとえば、http://servername であれば SSO は機能しますが、http://servername/command.shtml?view のような URL では機能しません。

表 3-4 は、Communications サーバーの信頼できるサークルテクノロジによって SSO を設定する場合の Calendar Server 設定パラメータを示しています。

表 3-4 Communications サーバーの信頼できるサークルテクノロジを利用して 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.apprefix で設定された値と一致する接頭辞値を持つクライアント側のすべての 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 値を設定する。信頼できるピア 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-5 は、Communications サーバーの信頼できるサークルテクノロジによって SSO を設定する場合の Messaging Server 設定パラメータを示しています。

表 3-5 Communications サーバーの信頼できるサークルテクノロジを利用して 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 がクライアントのログアウト時にクリアされる
local.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 値を設定する。信頼できるピア 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 である

Messaging Server の SSO の設定については、『Sun ONE Messaging Server 6.0 Administrator's Guide』を参照してください。

LDAP CLD (Calendar Lookup Database) プラグインの設定

LDAP CLD プラグインは単一カレンダーインスタンス用の多数のバックエンドサーバーにユーザーカレンダーとリソースカレンダーを分散することによって、カレンダーデータベースの水平方向のスケーラビリティを提供します。LDAP CLD プラグインは、特定のカレンダーが存在するバックエンドサーバーを icsDWPHost 属性に基づいて決定します。


注	Calendar Server 5.1.1 以降のリリースでは、CLD プラグインのメジャーバージョン番号は 1 から 2 に変わりました。マイナーバージョン番号は 0 で変わりません。独自の CLD プラグインを記述した場合は、この新しいメジャーバージョン番号をサポートできるようにプラグインを修正する必要があります。

LDAP CLD プラグインのしくみ

LDAP CLD プラグイン用の Calendar Server の構成

フロントエンドサーバーとバックエンドサーバーの間のセキュリティの管理

LDAP CLD プラグインのパフォーマンスの向上

CLD キャッシュのクリア

別のバックエンドサーバーへのカレンダーの移動

LDAP CLD プラグインのしくみ

LDAP CLD プラグインを使用することで、カレンダーデータベースを多数のバックエンドサーバーに分散することができます。データベース内の各カレンダーは、次の形式の一意のカレンダー ID (calid) によって識別されます。

userid は Calendar Server インスタンスの一意のユーザー ID

domain はユーザーのドメイン名で、省略可能

calendar-name はこのユーザーにとって一意となるカレンダーの名前で、省略可能

Calendar Server は、バックエンドサーバー上のカレンダーデータに次のようにアクセスします。

Calendar Express のエンドユーザーがカレンダーにアクセスすると、LDAP CLD プラグインはカレンダーの calid から userid を抽出し、LDAP サーバーデータベースでカレンダーの所有者を検索します。

カレンダーの所有者が特定されると、プラグインはその所有者の icsDWPHost LDAP 属性を使用してカレンダーが存在するバックエンドサーバーのホスト名を決定します。このホスト名は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。

Calendar Server は、ホスト名を使用して、DWP (データベースワイヤプロトコル) でバックエンドサーバー上のカレンダーデータにアクセスします。DWP は csdwpd サービスとして実行される内部プロトコルで、カレンダーデータベースのネットワーク機能を提供します。

Calendar Server は、ユーザーがログインしているサーバーに DWP でカレンダーデータを送信し、Calendar Express がエンドユーザーのブラウザにデータを表示します。



注	LDAP CLD プラグインを使用しているサイトで cscal ユーティリティを使用してカレンダーを新規作成するときは、ユーザーの icsDWPHost LDAP 属性によって指定される、ユーザーのカレンダーデータの格納 (予定) 場所と同じバックエンドサーバーに新しいカレンダーを作成する必要があります。別のバックエンドサーバーにカレンダーを作成しようとすると、Calendar Server はエラーを返します。詳細については、「cscal」を参照してください。

LDAP CLD プラグイン用の Calendar Server の構成

LDAP CLD プラグインは、次の Calendar Server 構成をサポートしています。

複数のフロントエンドサーバーと複数のバックエンドサーバー

複数のフロントエンド / バックエンドサーバーによる構成

これらの設定において、フロントエンドとバックエンドの各サーバーは、次の条件を満たす必要があります。

同じ Solaris オペレーティングシステムを稼動している

パッチを含め、同じリリースの Calendar Server を稼動している

DWP ポートに同じポート番号を使用している (service.dwp.port パラメータ)。デフォルトのポート番号は 59779

複数のフロントエンドサーバーと複数のバックエンドサーバー

次の図は、1 つの Calendar Server インスタンスが稼動する 2 つのフロントエンドサーバーと 2 つのバックエンドサーバーを示しています。必要に応じて 3 つ以上のフロントエンドまたはバックエンドサーバーを導入することもできます。

この構成では、サーバーをファイアウォールで保護し、LDAP データベースとカレンダーデータベースへのアクセスを制限することができます。カレンダーデータベースは 2 つのバックエンドサーバーに分散されます。

フロントエンドサーバーは CPU を多用します。ほとんどの CPU 時間は、エンドユーザーへのカレンダーデータの表示に使用されます。バックエンドサーバーはディスクを多用します。ほとんどの CPU 時間は、カレンダーデータベースへのアクセスに使用されます。

図 3-1 複数のフロントエンドサーバーと複数のバックエンドサーバー

フロントエンドサーバーの設定

フロントエンドサーバーを設定するには、各フロントエンドサーバーで ics.conf ファイルの次のパラメータを設定します。

カレンダーデータベースの検索プラグインを有効にします。

csapi.plugin.calendarlookup = "y"

Calendar Server がすべてのプラグインをロードするように指定します。

csapi.plugin.calendarlookup.name = "*"

カレンダー検索プラグインの種類に LDAP CLD プラグインを指定します。

caldb.cld.type = "directory"

DWP サービスのポート番号 (csdwpd) を設定します。

service.dwp.port = "59779"

デフォルトは 59779 です。設定するすべてのフロントエンドサーバーとバックエンドサーバーに同じポート番号を指定する必要があります。

各バックエンドサーバーのサーバー名を指定します。

caldb.dwp.server.backend-server-1.ip = "backend-server-1"
caldb.dwp.server.backend-server-2.ip = "backend-server-2"
...
caldb.dwp.server.backend-server-n.ip = "backend-server-n"

サーバー名は完全修飾名で指定します。この名前は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。パラメータの各部で同じサーバー名を完全修飾名で指定します。

例 :

caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

また、サーバー名はカレンダー所有者の icsDWPHost LDAP 属性で使用される名前と一致している必要があります。

デフォルトの DWP サーバー名を設定します。

caldb.dwp.server.default = "server-name"

server-name は、LDAP サーバーデータベース内のユーザーエントリまたはリソースエントリが icsDWPHost 属性を持たない場合に使用されるデフォルトサーバーの完全修飾名です。この名前は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。

例 :

caldb.dwp.server.default = "calendar.sesta.com"

変更を適用するために Calendar Server を再起動します。

フロントエンドサーバーの設定パラメータの例

次の例は、calendar.sesta.com と calendar.siroe.com という 2 つのバックエンドサーバーを持つフロントエンドサーバーの設定パラメータを示しています。デフォルトの DWP サーバーは calendar.sesta.com です。

コード例 3-1 フロントエンドサーバーの LDAP CLD 設定パラメータ

バックエンドサーバーの設定

バックエンドサーバーを設定するには、各バックエンドサーバーで ics.conf ファイルの次のパラメータを設定します。

DWP サービスを有効化し (csdwpd)、DWP ポート番号を設定します。

service.dwp.enable = "y"
service.dwp.port = "59779"

デフォルトのポート番号は 59779 です。設定するすべてのフロントエンドサーバーとバックエンドサーバーに同じポート番号を指定する必要があります。

バックエンドサーバーでは必要ないので、HTTP サービスを無効にします (管理サービスにはデフォルト値の yes を設定する必要があります)。

service.http.enable = "no"
service.admin.enable = "yes"

カレンダー検索プラグインの種類に LDAP CLD プラグインを指定します。

caldb.cld.type = "local"

バックエンドサーバーはカレンダーデータの検索を行わないので、csapi.plugin.calendarlookup を n に設定します。

csapi.plugin.calendarlookup = "n"

変更を適用するために Calendar Server を再起動します。

バックエンドサーバーの設定パラメータの例

次の例は、バックエンドサーバーの設定パラメータを示しています。

コード例 3-2 バックエンドサーバーの LDAP CLD 設定パラメータ

複数のフロントエンド / バックエンドサーバーによる構成

次の図は、それぞれが 1 つのカレンダーデータベースに接続された 3 つのフロントエンド / バックエンドサーバーを示しています。この構成では、カレンダーを物理的に分散することができます。各サーバーにはカレンダーが配置され、その所有者が Calendar Server にログインします。

図 3-2 複数のフロントエンド / バックエンドサーバーによる構成

フロントエンド / バックエンドサーバーの設定

フロントエンド / バックエンドサーバーを設定するには、各サーバーで ics.conf ファイルの次のパラメータを設定します。

DWP サービスを有効化します (csdwpd)。

service.dwp.enable = "y"

DWP サービスのポート番号 (csdwpd) を設定します。

service.dwp.port = "59779"

デフォルトは 59779 です。設定するすべてのフロントエンドサーバーとバックエンドサーバーに同じポート番号を指定する必要があります。

カレンダー検索プラグインを有効にします。

csapi.plugin.calendarlookup = "y"

Calendar Server がすべてのプラグインをロードするように指定します。

csapi.plugin.calendarlookup.name = "*"

Calendar Server が使用するカレンダー検索プラグインの種類を指定します。

caldb.cld.type = "directory"

デフォルトの DWP サーバー名を設定します。

caldb.dwp.server.default = "server-name"

例 :

caldb.dwp.server.default = "calendar.sesta.com"

ローカルサーバーを含め、構成に含まれるすべてのフロントエンド / バックエンドサーバーのサーバー名を設定します。

caldb.dwp.server.server-1.ip = "server-1"
caldb.dwp.server.server-2.ip = "server-2"
...
caldb.dwp.server.server-n.ip = "server-n"

例 :

caldb.dwp.server.calendar.sesta.com.ip = "calendar.sesta.com"

また、サーバー名はカレンダー所有者の icsDWPHost LDAP 属性で使用される名前と一致している必要があります。

変更を適用するために Calendar Server を再起動します。

各フロントエンド / バックエンドサーバーの設定パラメータの例

次の例は、フロントエンド / バックエンドサーバーの設定パラメータを示しています。サーバーは sesta.com、siroe.com、varrius.com です。デフォルトの DWP サーバーは sesta.com です。

コード例 3-3 各フロントエンド / バックエンドサーバーの LDAP CLD 設定パラメータ

フロントエンドサーバーとバックエンドサーバーの間のセキュリティの管理

フロントエンドサーバーは DWP (データベースワイヤプロトコル) を使用してバックエンドサーバーと通信します。DWP は転送メカニズムとして HTTP を使用するため、Calendar Server 6.0 は表 3-6 と表 3-7 に示す設定パラメータを使用して、フロントエンドサーバーとバックエンドサーバーの間の DWP 接続を認証します。

これらのパラメータは省略可能で、デフォルトでは ics.conf ファイルに設定されていません。DWP 接続の認証を行う場合は、フロントエンドサーバーとバックエンドサーバーのそれぞれの ics.conf ファイルに必要なパラメータを追加する必要があります。

表 3-6 DWP 接続を認証するためのバックエンド設定パラメータ
パラメータ	説明
service.dwp.admin.userid	バックエンドサーバーで、DWP 接続の認証に使用するユーザー ID を指定する。バックエンドサーバーがユーザー ID を指定しない場合、認証は行われない
service.dwp.admin.cred	バックエンドサーバーで、DWP 接続の認証に使用するパスワードを指定する。バックエンドサーバーがパスワードを指定しない場合、認証は行われない

表 3-7 DWP 接続を認証するためのフロントエンド設定パラメータ
パラメータ	説明
caldb.dwp.server.back-end-server.admin	フロントエンドサーバーで、バックエンドサーバーとの DWP 接続に使用されるユーザー ID を指定する。back-end-server はサーバー名
caldb.dwp.server.back-end-server.cred	フロントエンドサーバーで、バックエンドサーバーとの DWP 接続に使用されるパスワードを指定する。back-end-server はサーバー名

フロントエンドサーバーとバックエンドサーバーの間の DWP 接続の認証を設定するには、次の手順を実行します。

各フロントエンドサーバーの ics.conf ファイルに次のパラメータを追加します。

caldb.dwp.server.back-end-server.admin = "userid"
caldb.dwp.server.back-end-server.cred = "password"

back-end-server はバックエンドサーバーの名前、userid と password は Calendar Server が接続の認証に使用するユーザー ID とパスワード

back-end-server によって指定されるバックエンドサーバーの ics.conf ファイルに次のパラメータを追加します。

service.dwp.admin.userid = "userid"
service.dwp.admin.cred = "password"

userid と password は、フロントエンドサーバーで指定したものと同じユーザー ID とパスワード

フロントエンドサーバーが最初にバックエンドサーバーに接続したときに、パラメータに指定されたユーザー ID とパスワードが送信されます。バックエンドサーバーはパラメータを調べ、両方のパラメータが一致した場合に接続が認証されます。バックエンドサーバーは、次にセッション ID をフロントエンドサーバーに返します。フロントエンドサーバーは、バックエンドサーバーへの以後の DWP コマンドの送信時にこのセッション ID を使用します。

同じフロントエンドサーバーからの以後の接続では、次の場合を除いて認証の必要はありません。

バックエンドサーバーが再起動される

両サーバー間でのアクティビティがないためにセッションがタイムアウトする

フロントエンドサーバーとバックエンドサーバーが複数ある場合は、それぞれで同じユーザー ID とパスワードを使用できます。

バックエンドサーバーがこのパラメータにユーザー ID とパスワードを指定しない場合、認証は行われません。

LDAP CLD プラグインのパフォーマンスの向上

LDAP CLD プラグインを使用する Calendar Server のパフォーマンスを向上するには、次の設定パラメータを yes (各パラメータのデフォルト値) に設定します。

caldb.cld.cache.enable は CLD のキャッシュオプションを有効にします。このオプションがカレンダーユーザーの DWP ホストサーバー情報 (icsDWPHost LDAP 属性) を格納することで、LDAP ディレクトリサーバーへの呼び出しを減らすことができます。

service.calendarsearch.ldap は、LDAP プラグインまたはユーザー設定のプラグインを使用してカレンダー検索が行われることを指定します。

CLD キャッシュのクリア

CLD キャッシュオプションを使用している場合、ics.conf パラメータでサーバー名を変更したり、カレンダーを別のバックエンドサーバーに移動したときは、CLD キャッシュをクリアしてサーバー名を消去する必要があります。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが正しいバックエンドサーバーに接続できなくなったり、Calendar Server が移動後のカレンダーを見つけられなくなります。

Calendar Server を停止します。

cal_svr_base/var/opt/SUNWics5/csdb/cld_cache ディレクトリ内のすべてのファイルを消去します。ただし、cld_cache ディレクトリ自体は消去しません。

Calendar Server を再起動します。

別のバックエンドサーバーへのカレンダーの移動

あるバックエンドサーバーから別のバックエンドサーバーにユーザーカレンダーまたはリソースカレンダーを移動するには、次の手順を実行します。

元のサーバーで、ユーザーカレンダーの場合は csuser ユーティリティ、リソースカレンダーの場合は csresource ユーティリティを実行してカレンダーユーザーを無効にします。たとえば、ユーザー ID と calid が bkamdar のユーザーを無効にするには、次のように実行します。

csuser disable bkamdar

元のサーバーで、csexport ユーティリティを実行してカレンダーデータベースからファイルにカレンダーをエクスポートします。

例 :

csexport -c bkamdar calendar bkamdar.ics

ユーザーが複数のカレンダーを持っている場合は、カレンダーごとにこの手順を実行します。

エクスポートしたカレンダーファイル (*.ics) を元のサーバーから新しいサーバーにコピーします。

新しいサーバーで、csimport ユーティリティを実行してファイルからカレンダーデータベースにカレンダーをインポートします。

例 :

csimport -c bkamdar calendar bkamdar.ics

エクスポートしたそれぞれのカレンダーについてこの手順を繰り返します。

LDAP ディレクトリサーバーで csattribute ユーティリティを実行し、カレンダー所有者の icsDWPHost LDAP 属性が新しいバックエンドサーバーをポイントするように変更します。属性を変更するには、まず属性を削除し、新しい値を持つ属性を追加します。たとえば、新しいサーバー名を sesta.com に設定するには、次のように実行します。

csattribute -a icsDWPHost delete bkamdar
csattribute -a icsDWPHost=sesta.com add bkamdar

新しいサーバーで、ユーザーカレンダーの場合は csuser ユーティリティ、リソースカレンダーの場合は csresource ユーティリティを実行してカレンダーユーザーを有効にします。

例 :

csuser enable bkamdar

新しいサーバーで、次のコマンドを実行して属性が正しく、各カレンダーが正常に移動されていることを確認します。

例 :

cscal -v -o bkamdar list bkamdar
...
csattribute -v list bkamdar

元のサーバーで、移動した各カレンダーを削除します。

例 :

cscal -o bkamdar delete bkamdar

-o オプションを指定することで、一次所有者が bkamdar であるすべてのカレンダーが削除されます。

LDAP 属性の管理

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

LDAP 属性のリスト表示


注	LDAP CLD プラグインを利用しているサイトでは、icsDWPHost 属性の値を新しいバックエンドホストサーバーに変更するときに csattribute を使用しないでください。icsDWPHost を変更しても、新しいカレンダーは新しいバックエンドホストに作成されません。詳細については、「LDAP CLD (Calendar Lookup Database) プラグインの設定」を参照してください。

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

LDAP 属性の追加

LDAP サーバーに属性を追加するときは、csattribute ユーティリティの add コマンドを使用します。たとえば、Conference_Schedule という値を持つ LDAP 属性 icsCalendar を TChang というユーザーに追加するには、次のように実行します。

LDAP 属性の削除

LDAP サーバーから属性を削除するときは、csattribute ユーティリティの delete コマンドを使用します。たとえば、TChang というユーザーから LDAP 属性 icsCalendar を削除するには、次のように実行します。

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

グループスケジューリングを利用することで、Calendar Server ユーザーは会議などのイベントを作成し、他の参加者を招待することができます。ユーザーは空き時間 / 予定ありの設定検索機能を利用して、参加予定者が実際にイベントに参加できるかどうかを確認できます。

参加予定者が同じ Calendar Server に存在する場合は、イベントは参加者のカレンダーにスケジューリングされます。参加予定者が異なる Calendar Server に存在する場合は、電子メールで招待状が送信されます。参加予定者は、招待に応じる、または拒否することができます。

Calendar Server ユーザーは、参加予定者のカレンダーを一覧表示してグループのスケジュールを比較することもできます。

GSE キュー内のエントリの管理には、csschedule ユーティリティを使用します。csschedule は、Calendar Server がインストールされているローカルマシンで実行する必要があります。

GSE キュー内のエントリのリスト表示

GSE キュー内のエントリをリスト表示するには、csschedule ユーティリティの list コマンドを使用します。たとえば、GSE キュー内のすべてのエントリを表示するには、次のように実行します。

GSE キューに格納されている最初の 10 エントリをリスト表示するには、次のように実行します。

calid が Holiday_Schedule のカレンダーの GSE キューに含まれるすべてのエントリをリスト表示するには、次のように実行します。

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

GSE キュー内のエントリを削除するには、csschedule ユーティリティの delete コマンドを使用します。たとえば、GSE キュー内のすべてのエントリを削除するには、次のように実行します。

calA というカレンダーで、最初のスケジュール時刻が 2001 年 11 月 30 日の 13 時 30 分 45 秒、オフセット数が 1、一意の ID が 1111、定期予定 ID が 0、シーケンス番号が 0 のエントリを GSE キューから削除するには、次のように実行します。

Calendar Server の監視

Calendar Server のアクティビティを監視するには、csmonitor、csstats、cstool の各ユーティリティを使用します。ここでは、次の作業について説明します。

カウンタ統計情報のリスト表示

Calendar Server ログファイルの監視

カウンタ統計情報のリスト表示

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

並行接続の最大数と合計接続数

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

データベースの読み取り、書き込み、削除の回数

統計情報をリスト表示するには、csstats ユーティリティの list コマンドを使用します。たとえば、カウンタオブジェクトの種類と基本情報を表示するには、次のように実行します。

httpstat カウンタオブジェクトに関する統計情報だけを表示するときは、次のように実行します。

wcapstat カウンタオブジェクトに関する統計情報を 1 時間にわたって 10 秒おきに表示するときは、次のように実行します。

Calendar Server ログファイルの監視

Calendar Server の各サービスは、状態に関する情報をそれぞれのログファイルに書き込みます。表 3-8 に示すように、各ログファイルにはサービス名に関連する名前が付けられます。

Solaris システムでは、Calendar Server ログファイルは次のデフォルトディレクトリに格納されます。

各ログファイルは、設定時刻とサイズの制限に基づく、次の形式の新しい名前で新しいログファイルにロールオーバーされます。

ログイベント重要度

表 3-8 Calendar Server ログファイル
サービス名	ログファイル名
管理サービス (csadmind)	admin.log
分散データベースサービス (csdwpd)	dwp.log
HTTP サービス (cshttpd)	http.log
通知サービス (csnotifyd)	notify.log

表 3-9 に示すように、Calendar Server のログファイルに記録するイベントの重要度は、8 段階に分かれています。

表 3-9 Calendar Server ログエラー重要度
重要度	意味
EMERGENCY	システムが利用不可能な状態にある。このレベルは、最大重要度のイベントを示す
ALERT	直ちに対応が必要である
CRITICAL	危険な状態にある
ERROR	エラー状態にある
WARNING	警告状態にある
NOTICE	正常だが、特筆すべき状態にある。これは、各カレンダーサービスのデフォルトのレポートレベルである
INFORMATION	情報提供用
DEBUG	デバッグレベルのメッセージ

ログイベントはタイムスタンプ、サーバーホスト名、重要度、プロセス名 (プロセス ID)、イベントの種類、優先度、説明から構成される 1 行で表わされます。Calendar Server がログファイルにレポートするイベントの重要度は、ics.conf ファイル内の特定の設定を変更して指定できます。詳細は、「カレンダーログ情報の設定」を参照してください。

EMERGENCY、ALERT、CRITICAL、ERROR、WARNING レベルのエラーについて、ログファイルを定期的に調べてください。これらのエラーが見つかったときは、Calendar Server の動作で考えられる問題について調査します。NOTICE および INFORMATION レベルのログイベントは Calendar Server の通常動作中に生成されることがあります。これは、サーバーアクティビティの監視に役立つように提供されています。


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

Calendar Server に対する ping の実行

Calendar Server サービスが特定のポート番号で待機していることを確認するには、cstool ユーティリティの ping コマンドを実行します。サービスに対して ping を実行しても、サービスが実際に稼動しているかどうかは検証されません。ソケット接続が受け付けられるかどうかが検証されます。

http : HTTP サービス (cshttpd)

admin : 管理サービス (csadmind)



注	現在のリリースでは、DWP サービス (csdwpd)、イベント通知サービス (enpd)、通知サービス (csnotifyd) に対して ping を実行することはできません。

cstool を実行するには、Calendar Server が稼動している必要があります。

たとえば、calserver というホスト名のマシンに対して ping を実行し、cshttpd サービスがポート 80 で待機しているかどうかを確認するには、次のように実行します。

デフォルトでは、cstool は 120 秒間応答を待ちますが、タイムアウトオプション -t を使用してこの値を変更することができます。

Calendar Server 設定の再読み込み

現在のリリースでは、設定の再読み込みに cstool refresh コマンドを使用しないでください。その代わりに、stop-cal コマンドと start-cal コマンドを使用します。詳細については、「Calendar Server の起動と停止」を参照してください。