Sun Java System Calendar Server 6 2005Q4 管理ガイド

パート III Calendar Server の設定のカスタマイズ

第 5 章 Calendar Server のカスタマイズ

インストールとインストール後の設定が終わると、Calendar Server をそのまま実行できます。しかし、設定ファイル ics.conf を編集すれば、システムをカスタマイズ、または再設定することができます。

この章と、パート III「Calendar Server の設定のカスタマイズ」以降の章には、Calendar Server の再設定に使用できる手順や情報が記載されています。

ics.conf は、次のディレクトリにあります。

Solaris の場合: /etc/opt/SUNWics5/cal/config

Linux の場合: /etc/opt/sun/calendar/config

注 –

次の作業を完了するまでは、設定ファイルの編集は行わないでください。

Calendar Server 6 2005Q4 をインストールするか、Calendar Server 6 2005Q4 にアップグレードします。
インストール後の設定プログラム comm_dssetup.pl および csconfigurator.sh を実行します。
既存のカレンダデータベースに対して必要な csmig、csvdmig、および commdirmig を実行します。第 4 章「データベース移行ユーティリティー」を参照してください。

この章で説明する内容は次のとおりです。

注 –

設定に関する次の項目については、別の章で説明します。説明する内容は次のとおりです。

Communications Express の設定

Calendar Server で、Communications Express に関する次の設定を行う必要があります。

プロキシ認証を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すように、ics.conf パラメータを編集します。

パラメータ	説明とデフォルト値
`service.http.allowadminproxy`	`“yes”` に設定すると、管理者のプロキシ認証が有効になります。デフォルトは `“no”` です。
`service.http.admins`	Calendar Server の管理権限を持つユーザー ID をリスト表示します。デフォルトは “calmaster” です。複数の値を指定する場合は、各値を空白文字で区切ります。値の 1 つは、`uwconfig.properties` ファイルの `calendar.wcap.adminid` に指定されている値である必要があります。
`service.admin.calmaster.userid`	calmaster のユーザー ID。これは、`uwcconfig.properties` ファイルの `calendar.wcap.adminid` パラメータに指定されているユーザー ID と同じになります。
`service.admin.calmaster.cred`	calmaster のパスワード。これは、`uwcconfig.properties` ファイルの `calendar.wcap.passwd` パラメータに指定されているパスワードと同じになります。

注 –

uwcconfig.properties ファイルは、 comms_express_svr_base/WEB-INF/config ディレクトリにあります。ここで comm_express_svr_base は、Communications Express がインストールされているディレクトリです。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

参照

Communications Express の設定手順については、を参照してください。

匿名アクセスを有効にするには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

ics.conf に含まれる次のパラメータを編集して、匿名アクセスを有効にします。

パラメータ	説明とデフォルト値
`service.wcap.anonymous.` `allowpubliccalendarwrite`	匿名アクセスのユーザーによる公開カレンダへの書き込みを有効または無効にします。アクセスを有効にするには、この値を `"yes"` に設定します (デフォルト)。
`service.wcap.allowpublicwritablecalendars`	ユーザーが書き込み可能な公開カレンダを所有できるようにします。これは、デフォルトで有効になっています (`"yes"` に設定)。
`service.http.allowanonymouslogin`	必要に応じて、このパラメータを `"yes"` に設定し、匿名アクセス (ログイン) を有効にします。デフォルト値は `"yes"` です。
`service.calendarsearch.ldap`	匿名ログインが有効になっているときには、セキュリティー上の理由から、カレンダ検索を行う際に最初に LDAP を検索できないようにしたい場合があります。その場合には、このパラメータを `"no"` に設定します (デフォルト)。

注 –

Communications Express では、service.calendarsearch.ldap パラメータの値を "no" に設定する必要があります。この設定は、DWP 環境 (データベースが複数のバックエンドに分散されている環境) で最良のパフォーマンスを得るためのシステム調整の指示とは矛盾しています。「DWP 環境でのカレンダ検索のパフォーマンス向上」を参照してください。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

Communications Express の設定手順については、『Sun Java System Communications Express 6 2005Q4 Administration Guide』を参照してください。

カレンダの設定

ユーザーカレンダを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`calstore.calendar.default.acl`	ユーザーがカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。形式は、ACE (アクセス制御エントリ) 引数をセミコロンで区切ったリスト形式の文字列です。デフォルトは次のとおりです。 "@@o^a^r^g;@@o^c^wdeic^g; @^a^fs^g;@^c^^g;@^p^r^g" ACE 形式については、「カレンダのアクセス制御」を参照してください。Calendar Server ユーティリティーについては、「cscal」を参照してください。
`calstore.calendar.owner.acl`	カレンダ所有者のデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。`"@@o^a^rsf^g;@@o^c^wdeic^g"`
`calstore.freebusy.include.defaultcalendar`	ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストに含めるかどうかを指定します。デフォルトは `“yes”` です。
`calstore.freebusy.remove.defaultcalendar`	ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストから削除できるかどうかを指定します。デフォルトは `“no”` です。
`service.wcap.freebusy.redirecturl`	異なるデータベースでのカレンダの検索に使用する URL を指定します。このパラメータは、カレンダデータベースの移行中にのみ使用します。カレンダが 2 つの異なるデータベースに分かれている間は、現在の Calendar Server データベース以外の URL を指定できます。システムでは、まず Calendar Server のカレンダデータベースを検索し、ユーザーが見つからない場合は、リダイレクト URL が利用できるかどうかを確認します。この機能をオフにするには、`get_freebusy` コマンドで `1` に設定された `redirect` パラメータを渡します。
`calstore.subscribed.include.` `defaultcalendar`	ユーザーのデフォルトカレンダを、そのユーザーの登録済みカレンダリストに含めるかどうかを指定します。デフォルトは “yes” です。
`service.wcap.login.calendar.publicread`	`"yes"` に指定すると、ユーザーのデフォルトカレンダは公開読み取り/非公開書き込みに初期設定されます。"no" に指定すると、ユーザーのデフォルトカレンダは非公開読み取り/非公開書き込みに初期設定されます。デフォルトは `“no”` です。
`user.allow.doublebook`	ユーザーカレンダの同じ時間帯に複数の予定をスケジューリングできるかどうかを指定します。 `"no"`: 複数のユーザーからの予約は拒否されます。 `"yes"`: 複数のユーザーからの予約は許可されます (デフォルト)。このパラメータは、ユーザーカレンダの作成時にのみ使用されます。作成後は、Calendar Server はカレンダプロパティーファイル (`ics50calprops.db`) を参照して複数のユーザーからの予約の可否を決定します。複数のユーザーからの予約のカレンダプロパティーの値を変更するには、`-k` オプションを指定して `cscal` を実行します。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

リソースカレンダを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`resource.allow.doublebook`	カレンダの作成時に、リソースカレンダ (会議室や視聴覚機器などのリソースのカレンダ) の同一時間帯に複数の予定をスケジューリングできるように設定するかどうかを指定します。 `"no"`: 複数のユーザーからの予約は拒否されます。 `"yes"`: 複数のユーザーからの予約は許可されます。このパラメータは、リソースカレンダの作成時にのみ使用されます。リソースカレンダの作成後は、Calendar Server はカレンダのプロパティー (`ics50calprops.db`) を参照して複数のユーザーからの予約の可否を決定します。リソースカレンダのカレンダプロパティーを変更して複数のユーザーからの予約の可否を変更する場合は、`-k` オプションを指定して `csresource` コマンドを実行します。
`resource.default.acl`	リソースカレンダを作成するときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 "@@o^a^r^g;@@o^c^wdeic^g; @^a^rsf^g"

パラメータ

説明とデフォルト値

resource.allow.doublebook

カレンダの作成時に、リソースカレンダ (会議室や視聴覚機器などのリソースのカレンダ) の同一時間帯に複数の予定をスケジューリングできるように設定するかどうかを指定します。

"no": 複数のユーザーからの予約は拒否されます。
"yes": 複数のユーザーからの予約は許可されます。
このパラメータは、リソースカレンダの作成時にのみ使用されます。

リソースカレンダの作成後は、Calendar Server はカレンダのプロパティー (ics50calprops.db) を参照して複数のユーザーからの予約の可否を決定します。

リソースカレンダのカレンダプロパティーを変更して複数のユーザーからの予約の可否を変更する場合は、-k オプションを指定して csresource コマンドを実行します。

resource.default.acl

リソースカレンダを作成するときに使用されるデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。

"@@o^a^r^g;@@o^c^wdeic^g;
@^a^rsf^g"

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base/SUNWics5/cal/sbin/start-cal

ログイン時のユーザーカレンダの自動プロビジョニングを無効にするには

ユーザーカレンダの自動プロビジョニングは、デフォルトで有効になっています。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次のパラメータを編集して、最初のログイン時のユーザーカレンダの自動プロビジョニングを無効にします。

パラメータ	説明とデフォルト値
`local.autoprovision`	ユーザーカレンダの自動プロビジョニングを有効にするか (`“yes”`)、無効にするか (`“no”`) を指定します。デフォルトは `“yes”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

空き/予定あり検索を設定するには

空き/予定ありビューは、いくつかの目的で使用されます。空き/予定ありビューの生成方法をカスタマイズするための ics.conf パラメータがいくつか用意されています。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを編集して、最初のログイン時のユーザーカレンダの自動プロビジョニングを無効にします。

パラメータ	説明とデフォルト値
`service.wcap.freebusybegin`	`get_freebusy` の範囲指定の開始時刻に適用される、現在時刻からのオフセットを指定します。デフォルトは `"30"` です。
`service.wcap.freebusyend`	`get_freebusy` の範囲指定の終了時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは `"30"` です。
`calstore.freebusy.include.defaultcalendar`	ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストに含めるかどうかを指定します。デフォルトは `"yes"` です。
`calstore.freebusy.remove.defaultcalendar`	ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストから削除できるかどうかを指定します。デフォルトは `"no"` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

カレンダユーザーの設定

ここでは、カレンダユーザーの設定方法について説明します。ここで説明する内容は次のとおりです。

ユーザーを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示す 1 つ以上の ics.conf パラメータを編集します。

パラメータ	説明とデフォルト値
`service.wcap.allowchangepassword`	`"yes"` に設定すると、ユーザーによるパスワードの変更が許可されます。デフォルトは `"no"` です。
`service.wcap.allowpublicwritablecalendars`	`"yes"` に設定すると、ユーザーは、書き込み可能な公開カレンダを所有できます。デフォルトは `"yes"` です。
`calstore.subscribed.remove.defaultcalendar`	ユーザーのデフォルトカレンダを、そのユーザーの登録済みカレンダリストから削除できるようにするかどうかを指定します。デフォルトは `"no"` です。
`service.wcap.allowcreatecalendars`	`"yes"` に設定すると、管理権限を持たないユーザーによるカレンダの作成が許可されます。デフォルトは `"yes"` です。
`service.wcap.allowdeletecalendars`	`"yes"` に設定すると、管理権限は持っていないが、そのカレンダに対する削除権を持っているユーザーによるカレンダの削除が許可されます。デフォルトは `"yes"` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ユーザー設定を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示す 1 つ以上の ics.conf パラメータを編集します。

パラメータ	説明とデフォルト値
`service.wcap.allowsetprefs.cn`	`"yes"` に設定すると、`set_userprefs` によるユーザー設定の "cn" (LDAP ユーザーの共通名) の変更が許可されます。デフォルトは “no” です。
`service.wcap.allowsetprefs.givenname`	`"yes"` に設定すると、`set_userprefs` によるユーザー設定 `"givenname"` (LDAP ユーザーの名 (姓名の名)) の変更が許可されます。デフォルトは `“no”` です。
`service.wcap.allowsetprefs.icsCalendar`	`"yes"` に設定すると、`set_userprefs` によるユーザー設定 `"icsCalendar"` (ユーザーのデフォルトカレンダ ID) の変更が許可されます。デフォルトは `“no”` です。
`service.wcap.allowsetprefs.mail`	`"yes"` に設定すると、`set_userprefs` によるユーザー設定 mail (ユーザーの電子メールアドレス) の変更が許可されます。デフォルトは `“no”` です。
`service.wcap.allowsetprefs.` `preferredlanguage`	`"yes"` に設定すると、`set_userprefs` によるユーザー設定 `"preferredlanguage"` (LDAP ユーザーの選択言語) の変更が許可されます。デフォルトは `“no”` です。
`service.wcap.allowsetprefs.sn`	`"yes"` に設定すると、`set_userprefs` によるユーザー設定 "sn" (LDAP ユーザーの姓) の変更が許可されます。デフォルトは `“no”` です。
`service.wcap.userprefs.ldapproxyauth`	`"yes"` に設定すると、`get_userprefs` の LDAP プロキシ認証が有効になります。"no" に設定すると、匿名の LDAP 検索が行われます。デフォルトは `“no”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

Calendar Server の設定

ここでは、ics.conf ファイルを編集してサーバー側の設定をカスタマイズする手順について説明します。ここで説明する内容は次のとおりです。

サーバーの動作を設定するには

カレンダは、次の表に示すデフォルトによって設定されます。カレンダを再設定する場合は、次の手順を実行します。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表のパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`calstore.calendar.create.lowercase`	カレンダの新規作成時、または LDAP CLD プラグインを使用してカレンダを検索する場合に、Calendar Server がカレンダ ID (`calid`) を小文字に変換するかどうかを指定します。デフォルトは `“no”` です。
`calstore.default.timezoneID`	ファイルのインポート時に使用されるタイムゾーン ID であり、それ以外に予定、カレンダ、ユーザーのタイムゾーン ID は存在しません。デフォルトは `"America/New_York"` です。無効な値を指定すると、サーバーは GMT (グリニッジ標準時) タイムゾーンを適用します。
`calstore.filterprivateevents`	Calendar Server が、非公開かつ極秘の (時刻と日付のみが公開される) 予定と仕事をフィルタリング (認識) できるかどうかを指定します。`"no"` に設定すると、Calendar Server はそれらを公開の予定および作業と同様に扱います。デフォルトは `“yes”` です。
`calstore.group.attendee.maxsize`	予定を拡張するときに、LDAP グループで許可される最大出席者数。値 `"0"` (デフォルト値) は、グループ全体を拡張することを意味します。
`calstore.recurrence.bound`	定期拡張で作成できる予定の最大数。デフォルトは `“60”` です。
`calstore.userlookup.maxsize`	ユーザー検索の LDAP ルックアップで返される結果の最大数。値 `"0"` は制限のないことを意味します。デフォルトは `“200”` です。
`calstore.unqualifiedattendee.fmt1.type`	予定の出席者についてディレクトリルックアップを行うときに、`jdoe` や `jdoe:tv` などの文字列を Calendar Server がどのように扱うかを指定します。設定できる値は、次のとおりです。`uid`、`cn`、`gid`、`res`、`mailto`、`cap`デフォルトは `“uid”` です。
`calstore.unqualifiedattendee.fmt2.type`	Calendar Server が予定の出席者についてディレクトリルックアップを行うときに、`jdoe@sesta.com` などのアットマーク (`@`) を含む文字列をどのように扱うかを指定します。設定できる値は、次のとおりです。`uid`、`cn`、`gid`、`res`、`mailto`、`cap`。デフォルトは `“mailto”` です。
`calstore.unqualifiedattendee.fmt3.type`	予定の出席者についてディレクトリルックアップを行うときに、`john doe` などの空白文字を含む文字列を Calendar Server がどのように扱うかを指定します。設定できる値は、次のとおりです。`uid`、`cn`、`gid`、`res`、`cap`。デフォルトは `“cn”` です。
`service.wcap.validateowners`	`"yes"` に設定すると、サーバーはディレクトリ内に存在するカレンダの各所有者を検証する必要があります (LDAP、または CSAPI 互換のユーザーディレクトリメカニズムを使用)。デフォルトは `“no”` です。
`service.wcap.freebusy.redirecturl`	要求されたカレンダがローカルカレンダデータベースに存在しない場合は、代わりに、このパラメータで指定された URL を使用して検索を別のデータベースにリダイレクトできます。これは、特に 2 つのデータベース間で移行を行っていて、どちらのデータベースもまだ使用されているときに作成されたスクリプトに使用されます。他方のデータベースを参照するかどうかを指定するには、`get_freebusy.wcap` コマンドを使用します。『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』の `get_freebusy` コマンドの説明を参照してください。
`store.partition.primary.path`	カレンダ情報が格納される一次ディスクパーティションの場所。デフォルトは `“/var/opt/SUNWics5/csdb”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

カレンダのログを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`logfile.admin.logname`	このログファイルには、実行された管理ツールコマンドの履歴が格納されます。デフォルトは `"admin.log"` です。
`logfile.buffersize`	ログバッファーのサイズ (バイト単位)。デフォルトは `"0"` です。ログファイルの各エントリのサイズを指定します。バッファーがあまりにも早くいっぱいになる場合は、サイズを大きくすることを検討してください。
`logfile.dwp.logname`	DWP (データベースワイヤプロトコル) に関連の管理ツールを記録するログファイルの名前。デフォルトは `"dwp.log"` です。フロントエンドサーバーごとに 1 つ指定します。
`logfile.expirytime`	ログファイルの有効期限 (秒単位)。デフォルトは `"604800"` です。この時間を過ぎると、クリーンアップルーチンによってログが破棄されます。ログをアーカイブする場合は、独自のルーチンを作成する必要があります。
`logfile.flushinterval`	バッファーの内容をログファイルにフラッシュする間隔 (秒単位)。デフォルトは `"60"` です。システムのログ情報の量がかなり多く、バッファーが 60 秒以内にいっぱいになる場合は、情報が失われます。その場合は、この間隔を短くすることを検討してください。この間隔を短くすると、システムのオーバーヘッドが増えるので注意してください。
`logfile.http.logname`	`cshttpd` サービスの現在のログファイルの名前。デフォルトは `"http.log"` です。
`logfile.http.access.logname`	現在の HTTP アクセスログファイルの名前。
`logfile.logdir`	ログファイルが格納されるディレクトリ。デフォルトは `"/var/opt/SUNWics5/logs"` です。
`logfile.loglevel`	サーバーがログに記録する情報の詳細度を指定します。各ログレベルには、次のいずれかのレベルが割り当てられます。`CRITICAL`、`ALERT`、`ERROR`、`WARNING`、`NOTICE`、`INFORMATION`、`DEBUG` (重要度順)。デフォルトは `“NOTICE”` です。 `CRITICAL` に設定すると、Calendar Server がログに記録する情報の詳細度がもっとも低くなります。もっとも高い詳細度でログを記録するには、`DEBUG` を指定します。また、より詳細度の高いログレベルに設定すると、そのレベルより低い各重要度のログもすべて記録されます。たとえば、`WARNING` に設定すると、`CRITICAL`、`ERROR`、および `WARNING` レベルのログエントリのみが記録されます。`DEBUG` に設定すると、すべてのログが記録されます。
`logfile.maxlogfiles`	ログディレクトリ内のログファイルの最大数。デフォルトは `"10"` です。システムが 11 番目のログを作成しようとする前に、クリーンアップルーチンが実行されて古いログファイルが破棄されます。
`logfile.maxlogfilesize`	すべてのログファイルの最大合計ディスク容量 (バイト単位)。デフォルトは `"2097152"` です。次のログファイルを作成するとこの制限を超えてしまう場合、システムはもっとも古いログを削除してディスクの空き容量を増やそうとします。
`logfile.minfreediskspace`	ログ記録用に必要な最小ディスク空き容量 (バイト単位)。この値に達すると、Calendar Server は古いログファイルの有効期限を終了してディスクの空き容量を増やそうとします。最小空き容量を回復できない場合、ログの記録は一時的に停止されます。デフォルト `"5242880"` です。
`logfile.notify.logname`	`csnotifyd` サービスのログファイルの名前。デフォルトは `"notify.log"` です。
`logfile.rollovertime`	ログファイルのローテーション間隔 (秒単位)。つまり、新しいログファイルの作成が開始される間隔を指定します。デフォルトは `"86400"` です。
`logfile.store.logname`	カレンダストアのログファイルの名前。デフォルトは `"store.log"` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

参照

カレンダデータベースのトランザクションのログを設定する場合は、第 10 章「自動バックアップ (csstored) の設定」を参照してください。

削除された予定や作業を格納するための削除ログを設定する必要はありません。第 18 章「削除ログデータベースの管理」を参照してください。

WCAP コマンドを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示す 1 つ以上の ics.conf パラメータを編集します。

パラメータ	説明とデフォルト値
`service.wcap.format`	コマンドのデフォルトの出力形式を指定します。デフォルトは `“text/calendar”` です。`text/js` は下位互換性のためにサポートされています。 Connector for Microsoft Outlook を使用する場合は、`text/calendar` に設定する必要があります。
`service.wcap.version`	WCAP のバージョン。

パラメータ

説明とデフォルト値

service.wcap.format

コマンドのデフォルトの出力形式を指定します。デフォルトは “text/calendar” です。text/js は下位互換性のためにサポートされています。

Connector for Microsoft Outlook を使用する場合は、text/calendar に設定する必要があります。

service.wcap.version

WCAP のバージョン。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ログインと認証の設定

プロキシ管理者のログインを設定するには

プロキシログインは、Communications Express 用に設定する必要があります。Communications Express 用にプロキシログインを設定する方法については、「Communications Express の設定」を参照してください。

管理者が Communications Express の外部で Calendar Server にプロキシログインできるようにするには、次の手順を実行します。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次のパラメータを編集します。

パラメータ	説明とデフォルト値
`service.http.allowadminproxy`	管理者がプロキシログインを実行してユーザーカレンダを管理できるかどうかを指定します。`“yes”` に設定すると、プロキシログインは許可されます。`“no”` に設定すると、プロキシログインは許可されません。デフォルト値は `“no”` です。

新しい値を適用するために Calendar Server を再起動します。

次の WCAP コマンドを使用して、管理者プロキシログインが正しく機能することを確認します。
http://server[:port]/login.wcap? user=admin-user&password=admin-password &proxyauth=calendar-user
それぞれの意味は次のとおりです。
- server は Calendar Server が稼動しているサーバーの名前。
- port は Calendar Server のポート番号。デフォルトのポートは 80。
- admin-user は Calendar Server の管理者。たとえば、calmaster など。
- admin-password は admin-user のパスワード。
- calendar-user は Calendar Server ユーザーの calid。
コマンドの実行が成功すると、Calendar Server は calendar-user のカレンダを表示します。問題が発生した場合は、「Unauthorized」というメッセージが出力されます。次のような原因が考えられます。
- admin-user が Calendar Server の管理者権限を持っていない。
- admin-password が正しくない。
- calendar-user が有効な Calendar Server ユーザーではない。

認証を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`local.authldapbasedn`	LDAP 認証のベース DN。指定しない場合は local.ugldapbasedn の設定が適用されます。指定しない場合、サーバーは `local.ugldaphost` の値を使用します。
`local.authldaphost`	LDAP 認証用のホスト。指定しない場合は `local.ugldaphost` の値が使用されます。デフォルトは `"localhost"` です。
`local.authldapbindcred`	`local.authldapbinddn` で指定された、ユーザーのバインドに必要な資格情報 (パスワード)。
`local.authldapbinddn`	ユーザー DN の検索時に LDAP 認証ホストへのバインドに使用される DN。指定しない場合または空白 (`" "`) の場合は、匿名バインドと見なされます。
`local.authldapport`	LDAP 認証用のポート。指定しない場合は `local.ugldapport` の値が使用されます。デフォルトは `"389"` です。
`local.authldappoolsize`	LDAP 認証用に維持される LDAP クライアント接続の最小数。指定しない場合は `local.ugldappoolsize` の値が使用されます。デフォルトは `"1"` です。
`local.authldapmaxpool`	LDAP 認証用に維持される LDAP クライアント接続の最大数。指定しない場合は `local.ugldapmaxpool` の値が使用されます。デフォルトは `"1024"` です。
`local.user.authfilter`	ユーザー検索に使用される認証フィルタを指定します。デフォルトは `"(uid=%U)"` です。この値は、ドメインエントリの `inetDomainSearchFilter` 属性に格納されます。別の属性でフィルタすることもできます。たとえば、このパラメータを `"(mail=%U)"` に設定することもできます。認証に使用される属性に関係なく、認証されたユーザーの `uid` がそのユーザーの ID としてほかのすべての関数に渡されます。
`service.plaintextloginpause`	プレーンテキスト形式のパスワードによるユーザーの認証に成功したあとの遅延時間 (秒単位)。デフォルトは `"0"` です。

認証キャッシュを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`service.authcachesize`	Calendar Server がキャッシュに保持する、認証されたユーザーの ID (`uid`) およびパスワードの最大数。デフォルトは `“10000”` です。
`service.authcachettl`	最後のアクセスから `uid` とパスワードがキャッシュから削除されるまでの秒数。デフォルトは `“900”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ログイン時のクライアント IP アドレスの確認を有効にするには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを編集します。

パラメータ	説明とデフォルト値
`service.dnsresolveclient`	`"yes"` に設定すると、HTTP アクセスが許可されているときに、クライアント IP アドレスが DNS に対して照合されます。デフォルトは `“no”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

カレンダサービスの設定

ヒント –

第 10 章「自動バックアップ (csstored) の設定」も参照してください。

管理サービス (csadmind) を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`service.admin.checkpoint`	`"yes"` に設定すると、`csadmind` データベースチェックポイントスレッドが開始されます。`“no”` に設定すると、チェックポイントログファイルは作成されません。デフォルトは `“yes”` です。
`service.admin.dbcachesize`	管理セッション用の Berkeley データベースの最大キャッシュサイズ (バイト単位)。デフォルトは “8388608” です。
`service.admin.deadlock`	`"yes"` に設定すると、`csadmind` データベースデッドロック検出スレッドが開始されます。デフォルトは `“yes”` です。
`service.admin.diskusage`	`"yes"` に設定すると、`csadmind` ディスク容量低下監視スレッドが開始されます。デフォルトは `“no”` です。デフォルトでは、ディスク使用率は監視されません。
`service.admin.enable`	`"yes"` に設定すると、すべてのサービスを開始するときに `csadmind` サービスを開始し、すべてのサービスを終了するときに `csadmind` サービスを終了します。デフォルトは `“yes”` です。
`service.admin.idletimeout`	`csadmind` で HTTP 接続をタイムアウトにするまでの秒数。デフォルトは `“120”` です。
`service.admin.maxsessions`	許容される管理セッションの最大数。デフォルトは `“100”` です。
`service.admin.maxthreads`	1 管理セッションで実行されるスレッドの最大数。デフォルトは `“10”` です。
`service.admin.numprocesses`	同時に実行可能な管理プロセスの最大数。
`service.admin.port`	デフォルトはなしです。このパラメータはシステムによって設定されます。注意 – このパラメータはユーザー自身では設定しないでください。システムによって自動的に設定されます。Calendar Server でリモート管理を行うことはできません。このポート番号を変更すると、`csadmind` が起動しない可能性があります。
`service.admin.resourcetimeout`	管理接続をタイムアウトにするまでの秒数。デフォルトは `“900”` です。
`service.admin.serverresponse`	"yes" に設定すると、csadmind サービス応答スレッドが開始されます。デフォルトは `“no”` です。
`service.admin.sessiondir.path`	管理セッション要求用の一時ディレクトリ。デフォルトはなしです。
`service.admin.sessiontimeout`	`csadmind` で HTTP セッションをタイムアウトにするまで待機する秒数。デフォルトは `“1800”` です。
`service.admin.sleeptime`	カレンダサービスの状態 (稼動、終了、待機) を調べる間隔 (秒単位)。デフォルトは `“2”` です。
`service.admin.starttime`	カレンダサービスが開始するまで待機する秒数。デフォルトは `“300”` です。
`service.admin.stoptime`	カレンダサービスが終了するまで待機する秒数。デフォルトは `“300”` です。
`service.admin.stoptime.next`	カレンダサービスに終了コマンドを送信するまで待機する秒数。デフォルトは `“60”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

HTTP サービス (cshttpd) を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`service.http.admins`	この Calendar Server の管理権限を持つユーザー ID を空白文字で区切って指定します。デフォルトは `“calmaster”` です。
`service.http.allowadminproxy`	"yes" に設定すると、プロキシ経由のログインが許可されます。デフォルトは `“no”` です。
`service.http.allowanonymouslogin`	"yes" に設定すると、匿名アクセス (認証なし) が許可されます。これは特殊なタイプのログインであり、指定した制限付きのアクセス (通常は公開カレンダへの読み取り専用アクセス) のみが許可されます。デフォルトは `“yes”` です。
`service.http.calendarhostname`	HTML ドキュメントを取得するための HTTP ホスト。ユーザーが完全修飾ホスト名を指定してカレンダデータにアクセスできるようにするには、`mycal@sesta.com` のように、Calendar Server が稼動するマシンの完全修飾ホスト名 (マシン名、DNS ドメインとサフィックスを含む) をこの値に指定する必要があります。指定しない場合、ローカル HTTP ホストが適用されます。
`service.http.cookies`	cookie をサポートするかどうかをサーバーに指示します ("yes" または "no")。シングルサインオンを有効にするには、`"yes"` に設定する必要があります。デフォルトは `“yes”` です。
`service.http.dbcachesize`	HTTP セッション用の Berkeley データベースの最大キャッシュサイズ。デフォルトは `“8388308”` です。
`service.http.domainallowed`	`" "` 以外の値を指定した場合は、TCP ドメインに基づくフィルタリングによってアクセスが許可されます。たとえば、「`ALL: LOCAL.sesta.com`」と指定した場合は、`sesta.com` ドメインのすべてのユーザーによるローカル HTTP アクセスが許可されます。複数のフィルタを指定する場合は、`CR-LF` (改行) で区切ります。デフォルトは `""` です。
`service.http.domainnotallowed`	空白 (`" "`) 以外の値を指定した場合は、TCP ドメインに基づくフィルタリングによってアクセスが拒否されます。たとえば、「`ALL: LOCAL.sesta.com`」と指定した場合は、`sesta.com` ドメインのすべてのユーザーによる HTTP アクセスが拒否されます。複数のフィルタを指定する場合は、`CR-LF` (改行) で区切ります。デフォルトは `" "` (空白) です。
`service.http.attachdir.path`	インポートされたファイルが一時的に格納されるディレクトリのlocal.queuedir への相対パス (指定する場合は絶対パス)。デフォルトは現在のディレクトリ (`"."`) です。
`service.http.ipsecurity`	`"yes"` に指定すると、既存のセッションを参照するすべての要求は、同じ IP アドレスから発せられているものとして検証されます。デフォルトは `“yes”` です。
`service.http.enable`	`"yes"` に設定すると、すべてのサービスを開始するときに `cshttpd` サービスを開始し、すべてのサービスを終了するときに `cshttpd` サービスを終了します。デフォルトは `“yes”` です。注意 – このパラメータで HTTP サービスを無効にすると HTTPS も無効になります。
`service.http.idletimeout`	HTTP 接続をタイムアウトにするまでの秒数。デフォルトは `“120”` です。
`service.http.listenaddr`	HTTP サービスがクライアント要求を待機する TCP アドレスを指定します。デフォルトは、任意のアドレスを示す `"INADDR_ANY"` です。
`service.http.logaccess`	`"yes"` に指定すると、サーバーへの HTTP 接続が完全にログに記録されます。デフォルトは `“no”` です。
`service.http.maxsessions`	cshttpd サービスでの HTTP セッションの最大数。デフォルトは `“5000”` です。
`service.http.maxthreads`	`cshttpd` サービスでの HTTP 要求を処理するスレッドの最大数。デフォルトは `“20”` です。
`service.http.numprocesses`	サーバーでの実行が必要な HTTP サービス (`cshttpd`) プロセスの最大並行実行数。デフォルトは `“1”` です。複数の CPU を持つサーバーについては、「複数 CPU 間でのロードバランスの使用」を参照してください。
`service.http.port`	Calendar Server ユーザーからの HTTP 要求用のポート。デフォルトは `“80”` です。
`service.http.proxydomainallowed`	`""` 以外を指定した場合は、TCP ドメインに基づくプロキシログインがフィルタリングによって許可されます。構文は `service.http.domainallowed` と同じです。デフォルトは `""` です。
`service.http.resourcetimeout`	HTTP セッションをタイムアウトにするまでの秒数。デフォルトは `“900”` です。
`service.http.sessiondir.path`	HTTP セッションデータベース用のディレクトリ。デフォルトは `“http”` です。
`service.http.sessiontimeout`	`cshttpd` サービスで HTTP セッションをタイムアウトにするまでの秒数。デフォルトは `“1800”` です。
`service.http.sourceurl`	実行可能ファイルへのすべての URL 参照が格納されるディレクトリの、実行可能ファイルに対する相対パス。デフォルトは `""` (NULL) です。
`service.http.tmpdir`	HTTP セッション用の一時ディレクトリ。デフォルトは `“/var/opt/SUNWics5/tmp”` です。
`service.http.uidir.path`	デフォルトのカレンダクライアントが格納されるディレクトリ。WCAP アクセスのみを許可する場合は、`"html"` に設定します。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

アラーム通知を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示す 1 つ以上の ics.conf パラメータを編集します。

パラメータ	説明とデフォルト値
`alarm.diskstat.msgalarmdescription`	ディスク容量の不足時に送信されるメッセージ。デフォルトのメッセージは `“percentage calendar partition diskspace available”` です。
`alarm.diskstat.msgalarmstatinterval`	ディスク容量を監視する間隔 (秒単位)。デフォルトは `“3600”` です。
`alarm.diskstat.msgalarmthreshold`	警告メッセージの送信対象となる使用可能なディスク容量の割合 (パーセント)。デフォルトは `“10”` です。
`alarm.diskstat.msgalarmthresholddirection`	`alarm.diskstat.msgalarmthreshold` に設定される割合を上回っているか、または下回っているか。`-1` は下回っており、`1` は上回っています。デフォルトは `“-1”` です。
`alarm.diskstat.msgalarmwarninginterval`	不十分なディスク容量に関する警告メッセージを送信する間隔 (時間単位)。デフォルトは `“24”` です。
`alarm.msgalarmnoticehost`	サーバーアラームの送信に使用される SMTP サーバーのホスト名。デフォルトは `“localhost”` です。
`alarm.msgalarmnoticeport`	サーバーアラームの送信に使用される SMTP ポート。デフォルトは `“25”` です。
`alarm.msgalarmnoticercpt`	サーバーアラームの送信先電子メールアドレス。`“Postmaster@localhost”`
`alarm.msgalarmnoticesender`	サーバーが送信するアラームの送信元として指定される電子メールアドレス。デフォルトは `“Postmaster@localhost”` です。
`alarm.msgalarmnoticetemplate`	送信する電子メールアラームのデフォルト形式。 `"From: %s\nTo: %s\nSubject: ALARM: %s of \"%s\" is n\n%s\n"`
`alarm.responsestat.msgalarmdescription`	サービスからの応答がない場合に送信されるメッセージ。デフォルトは `“calendar service not responding”` です。
`alarm.responsestat.msgalarmstatinterval`	サービスを監視する間隔 (秒単位)。デフォルトは `“3600”` です。
`alarm.responsestat.msgalarmthreshold`	デフォルトは `“100”` (サービスの応答がない場合にのみ警告メッセージを送信する) です。
`alarm.responsestat.` `msgalarmthresholddirection`	`alarm.responsestat.msgalarmthreshold` の割合を上回っているか、または下回っているかを指定します。-1 は下回っており、1 は上回っています。デフォルトは `“-1”` です。
`alarm.responsestat.` `msgalarmwarninginterval`	サービスからの応答がないことに関する警告メッセージを送信する間隔 (時間単位)。デフォルトは `“24”` です。
`local.rfc822header.allow8bit`	このサーバーが送信する電子メールメッセージでの 8 ビットヘッダーの使用を許可 (`"y"`)、または拒否 (`"n"`) します。
`service.admin.alarm`	管理ツールのアラーム通知を有効 (`"yes"`)、または無効 (`"no"`) にします。デフォルトは `“yes”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

Berkeley データベースのデッドロックの定期的チェックの設定

Berkeley データベースのデッドロックを定期的にチェックするように Calendar Server を設定できます。

Berkeley データベースはデッドロック状態になる可能性があるため、それらのデータベースにアクセスしないようにします。この状態をできるだけ早く見つけるには、デッドロックの定期的チェックを有効にします。

Berkeley データベースのデッドロックの定期的チェックを有効にするには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを編集します。

パラメータ	説明とデフォルト値
`local.caldb.deadlock.autodetect`	Berkeley データベースがデッドロック状態にあるかどうかを定期的に調べます。デッドロック状態にある場合は、データベースのリセットを指示します。デフォルト値は `“no”` (無効) です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

注意事項

デッドロックしたときの Berkeley データベースのリセット方法については、トラブルシューティングの章、「データベースの破損の検出」、「使用可能なツールの一覧」を参照してください。

Calendar Server の LDAP の設定

LDAP への匿名アクセスを設定するには

通常、匿名アクセスはデフォルトで許可されています。匿名アクセスを制限する場合は、該当するパラメータを変更します。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`calstore.anonymous.calid`	匿名ログインのカレンダ ID (`calid`) を指定します。デフォルトは `“anonymous”` です。
`service.http.allowanonymouslogin`	匿名アクセス (ログインなし) が許可されるかどうかを指定します。デフォルトは `“yes”` です。電子メールによるカレンダ URL の受信者は、ログインを行わないで空き/予定ありバージョンのカレンダにアクセスできます。
`service.wcap.anonymous.` `allowpubliccalendarwrite`	書き込み可能な公開カレンダへの匿名ユーザーによる書き込みが許可されるかどうかを指定します。デフォルトは `“yes”` です。
`service.wcap.userprefs.ldapproxyauth`	ユーザー設定に使用する匿名の LDAP 検索を有効にします。デフォルトは `“no”` で、匿名アクセスは許可されます。`“yes”` に設定することは、検索にプロキシ認証が使用されることを意味します。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

LDAP 出席者ルックアップを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表のパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`local.lookupldap.search.` `minwildcardsize`	出席者ルックアップ検索のワイルドカード検索に使用する文字列の最小サイズを指定します。ゼロ (`0`) は常にワイルドカード検索を行うことを意味します。
`local.lookupldap.user.authfilter`	ユーザー検索に使用される認証フィルタを指定します。デフォルトは `“(uid=%s)”` です。
`local.lookupldapbasedn`	LDAP 出席者ルックアップの DN を指定します。指定しない場合は `local.ugldapbasedn` の設定が適用されます。デフォルト値はありません。
`local.lookupldapbinddn`	LDAP 出席者ルックアップに使用するホストにバインドされる DN を指定します。指定しない (デフォルトは `“”`) 場合は、匿名バインドと見なされます。
`local.lookupldapbindcred`	`local.lookupldapbinddn` で識別されるユーザーの資格情報 (パスワード)。デフォルト値はありません。
`local.lookupldaphost`	LDAP 出席者ルックアップのホスト名。指定しない場合は `local.ugldaphost` の設定が適用されます。
`local.lookupldapmaxpool`	LDAP 出席者ルックアップ用に維持される LDAP クライアント接続の最大数を指定します。指定しない場合は `local.ugldapmaxpool` の設定が適用されます。デフォルトは `“1024”` です。
`local.lookupldappoolsize`	LDAP 出席者ルックアップ用に維持される LDAP クライアント接続の最小数を指定します。指定しない場合は `local.ugldappoolsize` の設定が適用されます。デフォルトは `“1”` です。
`local.lookupldapport`	LDAP 出席者ルックアップに使用するポートを指定します。指定しない場合は `local.ugldapport` の設定が適用されます。
`local.lookupldapsearchattr.calid`	出席者ルックアップの calid 属性を指定します。デフォルトは `icsCalendar` です。
`local.lookupldapsearchattr.mail`	出席者ルックアップの mail 属性を指定します。デフォルトは `mail` です。
`local.lookupldapsearchattr.` `mailalternateaddress`	出席者ルックアップの代替メールアドレス属性を指定します。デフォルトは `mailalternateaddress` です。
`local.lookupldapsearchattr.` `mailequivalentaddres`	出席者ルックアップの等価メールアドレス属性を指定します。デフォルトは `mailequivalentaddress` です。
`local.lookupldapsearchattr.` `calendar`	出席者ルックアップのカレンダ属性を指定します。デフォルトは `icsCalendar` です。
`local.lookupldapsearchattr.cn`	出席者ルックアップの共通名属性を指定します。デフォルトは `icsCalendar` です。
`local.lookupldapsearchattr.` `objectclass`	出席者ルックアップのオブジェクトクラス属性を指定します。デフォルトは `objectclass` です。
`local.lookupldapsearchattr.` `objectclass.caluser`	カレンダユーザーのオブジェクトクラスを指定します。デフォルトは `icsCalendarUser` です。
`local.lookupldapsearchattr.` `objectclass.calresource`	カレンダリソースのオブジェクトクラスを指定します。デフォルトは `icsCalendarResource` です。
`local.lookupldapsearchattr.` `objectclass.group`	グループのオブジェクトクラスを指定します。デフォルトは `groupofuniquenames` です。
`local.lookupldapsearchattr.` `objectclass.person`	個人のオブジェクトクラスを指定します。デフォルトは `person` です。
`local.lookupldapsearchattr.` `memberurl`	出席者ルックアップのメンバー URL 属性を指定します。デフォルトは `memberurl` です。
`local.lookupldapsearchattr.` `uniquemember`	出席者ルックアップの一意のメンバー属性を指定します。デフォルトは `uniquemember` です。
`local.lookupldapsearchattr.` `givenname`	出席者ルックアップの名前 (姓名の名) 属性を指定します。デフォルトは `givenname` です。
`local.lookupldapsearchattr.sn`	出席者ルックアップのスクリーンネーム属性を指定します。デフォルトは `sn` です。
`local.smtp.defaultdomain`	電子メールアドレスに対応する出席者のカレンダ ID の検索で使用されるデフォルトドメインの名前。たとえば、この値が `"sesta.com"` に設定されている場合、jsmith は `jsmith@sesta.com` として解決されます。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

LDAP 出席者ルックアップの検索フィルタを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表のパラメータを 1 つ以上編集します。

ヒント –

次に示すすべてのパラメータ説明で、%s には出席者を 1 人だけ指定できます。

パラメータ	説明とデフォルト値
`local.lookupldap.calid.direct`	ダイレクトルックアップを使用した calid 検索タイプ用の検索フィルタ。デフォルトは次のとおりです: `"(icsCalendar=%s)"` %s: 出席者を表す文字列。
`local.lookupldap.cn.direct`	ダイレクトルックアップでの cn 検索タイプ用の検索フィルタ。デフォルトは次のとおりです。 "(&(cn=%s) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person)))" `%s`: 出席者を表す文字列。
`local.lookupldap.cn.search`	検索ダイアログのルックアップでの cn 検索タイプ用の検索フィルタ。デフォルト (1 人の出席者を表す文字列 (`%s`) の場合: "(&(cn=%s) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person)))" ワイルドカード検索 (検索文字列が複数) の場合: "(&(cn=%w) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person)))" `%w`: 出席者を表す文字列のリストが展開されます。例: `%w=”Mary Ann Smith”` は次のように展開されます。 (& (cn=Mary) (cn=”Ann”) (cn=Smith*)
`local.lookupldap.gid`	`gid` 検索タイプ用の検索フィルタ。デフォルトは次のとおりです。 "(&(cn=%s) (objectclass=groupofuniquenames))" `%s`: 1 人の出席者を表す文字列。
`local.lookupldap.mailto.indomain`	`local.smtp.defaultdomain` によって指定されたドメインでの mailto 検索タイプ用の検索フィルタ。デフォルトは次のとおりです。 "(\|(mail=%s)(mail=%h)(mail=<%s\>) (uid=%o))" `%s`: 出席者を表す文字列。 `%o`: 出席者の `uid`。 `%h`: ドメイン部分のない照会文字列。例: `%s=jdoe@sesta.com`、`%o=jdoe@sesta.com` 、`%h=jdoe` の場合、値は次のようになります。 (\|(mail=jdoe@varrius.com) (mail=jdoe) (mail=<jdoe@varrius.com\>) (uid=jdoe@varrius.com))
`local.lookupldap.mailto.outdomain`	`local.smtp.defaultdomain` によって指定されたドメイン以外のドメインでの mailto 検索タイプ用の検索フィルタ。デフォルトは次のとおりです。`"(\|(mail=%s)(uid=%s))"` `%s`: 出席者を表す文字列。
`local.lookupldap.res`	`res` 検索タイプ (リソース検索) 用の検索フィルタ。デフォルトは次のとおりです。 "(&(cn=%s) (objectclass=icsCalendarResource))" `%s`: 出席者を表す文字列。
`local.lookupldap.res.ugldap`	ユーザー/グループ LDAP サーバーのみでの `res` 検索タイプ (リソース検索) 用の検索フィルタ。このパラメータは、`local.lookupldap.resource.use.ugldap` が `“yes”` に設定されているときにのみ設定します。デフォルトは次のとおりです。 "(&(cn=%s) (objectclass=icsCalendarResource))" `%s`: 出席者を表す文字列。
`local.lookupldap.uid.direct`	ダイレクトルックアップを使用した `uid` 検索タイプ用の検索フィルタ。デフォルトは次のとおりです。 "(\|(uid=%s)(&(cn=%s) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person))))" `%s`: 出席者を表す文字列。
`local.lookupldap.uid.search`	検索ダイアログを使用した `uid` 検索タイプルックアップ用の検索フィルタ。デフォルトは次のとおりです。 "(\|(uid=%o)(&(cn=%w) (\|(objectclass=groupofuniquenames) (objectclass=icsCalendarResource) (objectclass=person))))" `%s`: 出席者を表す文字列。 `%w`: ワイルドカードを使用した出席者の文字列。 `%o`: ワイルドカードを使用しない出席者の文字列。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

LDAP リソースルックアップを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを編集します。

パラメータ	説明とデフォルト値
`local.lookupldap.resource.use.ugldap`	リソースルックアップにユーザー/グループ LDAP サーバーを使用するか、検索用サーバーを使用するか。 `“yes”`: ユーザー/グループ LDAP サーバーを使用します。 `“no”`: 検索用サーバーを使用します。デフォルトは `“no”` です。

パラメータ

説明とデフォルト値

local.lookupldap.resource.use.ugldap

リソースルックアップにユーザー/グループ LDAP サーバーを使用するか、検索用サーバーを使用するか。

“yes”: ユーザー/グループ LDAP サーバーを使用します。

“no”: 検索用サーバーを使用します。デフォルトは “no” です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

LDAP mail-to-calid ルックアップを設定するには

これらのパラメータは、ホストされていないドメイン環境でのみ使用します。ホストされたドメイン環境を導入した場合は、 maillookup パラメータが無視され、ユーザーとグループの LDAP 値 (ugldap) が使用されます。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表のパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`local.lookupldap.mailtocalid.search`	mail-to-calid ルックアップに使用する mail 属性を指定します。デフォルトは `"(\|(mail=%s)(mailalternateaddress=%s))”` です。属性 `mailalternateaddress` の代わりに `mailequivalentaddress` を使用できます。
`local.maillookupldapbasedn`	mail-to-calid ルックアップのベース DN を指定します。指定しない場合は `local.ugldapbasedn` の設定が適用されます。
`local.maillookupldapbinddn`	mail-to-calid ルックアップに使用するホストにバインドされる DN を指定します。指定しない (デフォルトは `“”`) 場合は、匿名バインドと見なされます。
`local.maillookupldapbindcred`	`local.maillookupldapbinddn` で指定された DN のパスワードを指定します。デフォルトはなしです。
`local.maillookupldaphost`	mail-to-calid ルックアップに使用される LDAP ホストを指定します。指定しない場合は `local.ugldaphost` の設定が適用されます。
`local.maillookupldapmaxpool`	mail-to-calid ルックアップ用に維持されるクライアント接続の最大数を指定します。指定しない場合は `local.ugldapmaxpool` の設定が適用されます。デフォルトは `“1024”` です。
`local.maillookupldappoolsize`	mail-to-calid ルックアップ用に維持されるクライアント接続の最小数を指定します。指定しない場合は `local.ugldappoolsize` の設定が適用されます。デフォルトは `“1”` です。
`local.maillookupldapport`	LDAP mail-to-calid ルックアップ用のポートを指定します。指定しない場合は `local.ugldapport` の設定が適用されます。デフォルトはなしです。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ユーザー設定 LDAP ディレクトリを使用するように Calendar Server を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表のパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`local.enduseradmincred`	LDAP ユーザー設定認証用のバインド資格情報 (パスワード)。デフォルトはなしです。
`local.enduseradmindn`	LDAP ユーザー設定ホストへのバインドに使用される DN。このプロパティーの指定は必須。空白 (`" "`) または指定しない場合は、匿名バインドと見なされます。
`local.ugldappoolsize`	LDAP ユーザー設定用に維持される LDAP クライアント接続の最小数。デフォルトは `“1”` です。
`local.ugldapmaxpool`	LDAP ユーザー設定用に維持される LDAP クライアント接続の最大数。デフォルトは `“1024”` です。
`service.wcap.userprefs.ldapproxyauth`	ユーザー設定に使用する匿名の LDAP 検索を有効にします。デフォルトは `“no”` で、匿名アクセスは許可されます。`“yes”` に設定することは、検索にプロキシ認証が使用されることを意味します。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ユーザー設定を指定するには

デフォルトのリストからユーザー設定を削除して、指定できるユーザー設定を制限することができます。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータ内のユーザー設定のリストを編集します。

パラメータ	ユーザー設定のデフォルトリスト	説明
`local.` `ugldapicsextendeduserprefs`	`"ceColorSet,` `ceFontFace,` `ceFontSizeDelta,` `ceDateOrder,` `ceDateSeparator,` `ceClock,` `ceDayHead,` `ceDayTail,` `ceInterval,` `ceToolText,` `ceToolImage,` `ceDefaultAlarmStart,` `ceSingleCalendarTZID,` `ceAllCalendarTZIDs,` `ceDefaultAlarmEmail,` `ceNotifyEmail,` `ceNotifyEnable,` `ceDefaultView,` `ceExcludeSatSun,` `ceGroupInviteAll"`	ユーザー設定値は、LDAP に保存されます。このパラメータは、LDAP の `icsExtendedUserPrefs` 属性に保存されるユーザー設定を定義します。

パラメータ

ユーザー設定のデフォルトリスト

説明

local.

ugldapicsextendeduserprefs

"ceColorSet,

ceFontFace,

ceFontSizeDelta,

ceDateOrder,

ceDateSeparator,

ceClock,

ceDayHead,

ceDayTail,

ceInterval,

ceToolText,

ceToolImage,

ceDefaultAlarmStart,

ceSingleCalendarTZID,

ceAllCalendarTZIDs,

ceDefaultAlarmEmail,

ceNotifyEmail,

ceNotifyEnable,

ceDefaultView,

ceExcludeSatSun,

ceGroupInviteAll"

ユーザー設定値は、LDAP に保存されます。このパラメータは、LDAP の icsExtendedUserPrefs 属性に保存されるユーザー設定を定義します。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

LDAP データキャッシュを有効にして設定するには

始める前に

LDAP データキャッシュの概要については、「LDAP データキャッシュオプション」を参照してください。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを編集して、LDAP データキャッシュを有効にします。

パラメータ	説明とデフォルト値
`local.ldap.cache.enable`	LDAP キャッシュを有効または無効にします。`“yes”` に設定すると、キャッシュが有効になります。`“no”` に設定すると、キャッシュが無効になります。デフォルトは `“no”` です。
`local.ldap.cache.checkpointinterval`	チェックポイントスレッドがスリープするまでの秒数を指定します。デフォルトは 60 秒です。
`local.ldap.cache.circularlogging`	処理が完了したあとにデータベースログファイルを削除するかどうかを指定します。デフォルトは `"yes"` です。
`local.ldap.cache.homedir.path`	LDAP データキャッシュデータベースの物理的な場所を指定します。デフォルトは次のとおりです。 cal_svr_base/var/opt/SUNWics5 /csdb/ldap_cache
`local.ldap.cache.logfilesizemb`	チェックポイントファイルの最大サイズを M バイト単位で指定します。デフォルトは 10M バイトです。
`local.ldap.cache.maxthreads`	LDAP データキャッシュデータベースの最大スレッド数を指定します。デフォルトは `"1000"` です。
`local.ldap.cache.mempoolsizemb`	共有メモリーのサイズを M バイト単位で指定します。デフォルトは `"4"`M バイトです。
`local.ldap.cache.entryttl`	現在は実装されていません。 LDAP データキャッシュエントリの存続時間 (TTL) を秒単位で指定します。デフォルトは `"3600"` 秒 (1 時間) です。
`local.ldap.cache.stat.enable`	LDAP データキャッシュへのアクセスをログに記録し、ログファイルに統計情報を出力するかどうかを指定します。デフォルトは no です。注 – このパラメータはデバッグモードだけに適用されます。
`local.ldap.cache.stat.interval`	統計情報レポートをログファイルに書き込む間隔を秒単位で指定します。デフォルトは `"1800"` 秒 (30 分) です。
`local.ldap.cache.cleanup.interval`	データベースクリーンアップの間隔を秒単位で指定します。デフォルトは `"1800"` 秒 (30 分) です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

参照

LDAP データキャッシュの調整方法については、「LDAP データキャッシュのパフォーマンスの向上」を参照してください。

注意 –

Calendar Server、または Calendar Server が動作しているサーバーが正しくシャットダウンされない場合は、データベースの破損と、それに伴ってその後の再起動時に発生する可能性のある問題を避けるために、ldap_cache ディレクトリ内のすべてのファイルを手動で削除してください。

LDAP SDK キャッシュを有効にして設定するには

LDAP SDK キャッシュは、デフォルトで無効になっています。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
service.ldapmemcache	"yes" に設定すると、LDAP SDK キャッシュが有効になります。デフォルトは “no” です。
service.ldapmemcachettl	`service.ldapmemcache` に `"yes"` を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。`“0”` を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは `“30”` です。
service.ldapmemcachesize	`service.ldapmemcache` に `"yes"` を指定した場合、このパラメータを使用して、キャッシュに使用できるメモリーの最大容量をバイト単位で設定します。`“0”` を指定した場合、キャッシュ容量の制限は適用されなくなります。デフォルトは `“131072”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

空き/予定あり検索の期間を設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	説明とデフォルト値
`service.wcap.freebusybegin`	`get_freebusy` の範囲指定の開始時刻に適用される、現在時刻からのオフセットを指定します。デフォルトは `“30”` です。
`service.wcap.freebusyend`	`get_freebusy` の範囲指定の終了時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは `“30”` です。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

カレンダプロパティーのワイルドカード LDAP 検索を有効にするには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すようにパラメータを編集します。

パラメータ	説明とデフォルト値
`service.calendarsearch.ldap.` `primaryownersearchfilter`	検索文字列との完全一致を見つけるために `search_calprops` 検索に使用されるデフォルトの検索フィルタ。検索文字列がプロパティー値に含まれていれば一致と見なされるワイルドカード検索を有効にするには、このパラメータのコメントを解除します。これにより、システムは次の検索フィルタを使用できるようになります。 "(&(\|(uid=%s)(cn=%s)) (objectclass=icsCalendarUser))" この検索フィルタを有効にすると、パフォーマンスが低下する可能性があります。

パラメータ

説明とデフォルト値

service.calendarsearch.ldap.

primaryownersearchfilter

検索文字列との完全一致を見つけるために search_calprops 検索に使用されるデフォルトの検索フィルタ。検索文字列がプロパティー値に含まれていれば一致と見なされるワイルドカード検索を有効にするには、このパラメータのコメントを解除します。これにより、システムは次の検索フィルタを使用できるようになります。

"(&(|(uid=*%s*)(cn=*%s*))
(objectclass=icsCalendarUser))"

この検索フィルタを有効にすると、パフォーマンスが低下する可能性があります。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

LDAP のルートサフィックスを設定するには

LDAP 組織ツリー (Schema 2) またはドメインコンポーネントツリー (Schema 1) のルートサフィックスをリセットすることは可能ですが、この作業は十分に注意して行う必要があります。これを行う場合は、設定プログラムを再実行することをお勧めします。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータのうちの 1 つを編集します。

パラメータ	説明とデフォルト値
`service.dcroot`	ディレクトリ内の DC ツリーのルートサフィックス。Schema 1 によるホストされた (仮想) ドメインモードのサポートに必要です。デフォルトは `"o=internet"` です。「ホストされたドメイン環境の設定」も参照してください。
`service.schema2root`	Schema 2 用の DIT (組織ツリー) のルートサフィックス。デフォルト値はありません。

パラメータ

説明とデフォルト値

service.dcroot

ディレクトリ内の DC ツリーのルートサフィックス。Schema 1 によるホストされた (仮想) ドメインモードのサポートに必要です。デフォルトは "o=internet" です。

「ホストされたドメイン環境の設定」も参照してください。

service.schema2root

Schema 2 用の DIT (組織ツリー) のルートサフィックス。デフォルト値はありません。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

第 6 章複数のマシンへのカレンダデータベースの分散の設定

この章では、カレンダデータベースを複数のバックエンドサーバーに分散させることを可能にするカレンダ検索データベース (CLD) プラグインの使用方法について説明します。CLD プラグインの有効化と設定の両方を行う必要があります。

注意 –

フロントエンドとバックエンドのマシン間で機能を分けている Calendar Server のインストールでは、それぞれのハードウェアプラットフォームを同じにする必要があります。

つまり、ビッグエンディアンとスモールエンディアンとの間に互換性がないため、フロントエンドとバックエンドのマシンを含む同じ Calendar Server で、x86 プラットフォームマシンと SPARC プラットフォームマシンの両方を使用することはできません。

この章で説明する内容は次のとおりです。

ヒント –

CLD プラグインのパフォーマンスを向上させる方法については、第 21 章「Calendar Server のパフォーマンスの調整」を参照してください。

基礎的な情報

この節では、CLD プラグインを実際に有効化および設定する前に理解しておく必要がある、概要および基礎的な情報を提供します。ここで説明する内容は次のとおりです。

CLD プラグインの概要

カレンダ検索データベース (CLD) プラグインは単一カレンダインスタンス用の多数のバックエンドサーバーにユーザーカレンダとリソースカレンダを分散することによって、カレンダデータベースの水平方向のスケーラビリティーを提供します。複数のバックエンドサーバーにカレンダデータベースを配布している場合、Calendar Server は CLD プラグインを使用してカレンダが実際に格納されているサーバーを特定します。

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

CLD プラグインのしくみ

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

エンドユーザーが Communications Express を使用してカレンダにアクセスすると、CLD プラグインはカレンダの calid から userid を取り出し、LDAP ディレクトリデータベースまたは CLD データキャッシュ (有効な場合) でカレンダの所有者を検索します。フロントエンドのマシンを設定する方法については、「CLD 用にフロントエンドサーバーを設定するには」を参照してください。
カレンダの所有者が特定されると、プラグインはその icsDWPHost LDAP 属性の値を使用してカレンダが存在するバックエンドサーバーのホスト名を決定します。このホスト名は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。
Calendar Server は、ホスト名を使用して、DWP (データベースワイヤプロトコル) でバックエンドサーバー上のカレンダデータにアクセスします。
Calendar Server は、ユーザーがログインしているサーバーに DWP でカレンダデータを送信するため、そのデータをユーザーインタフェースで表示できます。

ヒント –

サイトで CLD プラグインを使用している場合、同じユーザー用に作成されたすべてのカレンダが、LDAP ユーザーエントリの icsDWPHost LDAP 属性によって指定されているのと同じバックエンドサーバーに格納される必要があります。別のバックエンドサーバーにカレンダを作成しようとすると、Calendar Server はエラーを返します。

CLD プラグインでサポートされる構成

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

ヒント –

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

同じハードウェアプラットフォーム上にある
同じオペレーティングシステムを稼動している
パッチを含め、同じリリースの Calendar Server を稼動している
DWP ポートに同じポート番号を使用している (service.dwp.port パラメータ)。デフォルトのポート番号は 59779 です。

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

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

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

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

構成の詳細については、「CLD および DWP 用の Calendar Server の設定」を参照してください。

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

この図は、複数のバックエンドと複数のフロントエンドの両方を含むシステムの例を示します。

フロントエンドサーバーとバックエンドサーバーの両方の機能を持つ複数のマシン

図 6–2 は、フロントエンドサーバーとバックエンドサーバーの両方の機能を持つ 3 つのマシンを示しています。各マシンは、1 台のカレンダデータベースに接続されています。この構成では、カレンダを物理的に分散することができます。カレンダの所有者 (エンドユーザー) は、所有しているカレンダが格納されているマシンにログインします。構成の詳細については、「フロントエンドサーバーとバックエンドサーバーを同じマシンに設定するには」を参照してください。

図 6–2 フロントエンドサーバーとバックエンドサーバーの両方の機能を持つ複数のマシン

この図は、フロントエンドとバックエンドの両方の機能を持つマシンの例を示しています。

簡単なサイジング式

次に、メディア使用状況プロファイルに基づいて、必要なバックエンドサーバー数とフロントエンドサーバー数、およびストレージの容量を算出するための簡単な数式を示します。

メディア使用状況プロファイルの定義

ここでは大まかに、次のような状況を想定します。

すべてのクライアントは Web クライアントである。

したがって、入力として使用されるのは、ユーザー総数と同時並行の割合のみです。
平均的なサイズのカレンダの予定のサイズは 2K である。
各ユーザーが、1 週間につき 5 つの予定または仕事を作成する。
CPU 利用率は 80%。
900 MHz の CPU
各 CPU に 1G バイトの RAM を搭載
2 年分のカレンダデータがシステムに保存されている。

フロントエンド CPU の数

数式は次のとおりです。

CPU 数 = 並行ユーザー数 / 4800

バックエンド CPU の数

数式は次のとおりです。

CPU 数 = 設定済みの 500,000 ユーザーにつき 4 CPU

必要なストレージの容量

数式は次のとおりです。

ストレージの容量 = 電子メール 5 件 / 週 × 52 週 / 年 × 2K / メール (5*52*2K)

= 520K バイト / ユーザー / 年

カレンダデータ約 2 年分で、1 M バイト / ユーザー

CLD および DWP 用の Calendar Server の設定

ここでは、サーバーの設定方法について説明します。ここで説明する内容は次のとおりです。

CLD 用にフロントエンドサーバーを設定するには

手順

すべてのフロントエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すように、ics.conf パラメータを編集します。

パラメータ	説明
`csapi.plugin.loadall`	`cs_` で始まるすべてのプラグインを `cal_svr_base/SUNWics5/cal/bin/plugins` ディレクトリにロードする場合は、すべてのフロントエンドサーバーでこの値を `“y”` に設定します。 `csapi.plugin.calendarlookup.name` に名前が含まれる特定のプラグインのみをロードする場合は、`“n”` に設定します。
`csapi.plugin.calendarlookup`	このパラメータを `"yes"` に設定します。
`csapi.plugin.calendarlookup.name`	プラグインの名前 `"calendarlookup"` に設定します。すべてのプラグインをロードする場合は、`"*"` に設定します。
`caldb.cld.type`	カレンダを複数のバックエンドに分散させるか (`“directory”` に設定)、またはカレンダを Calendar Server のインストール先と同じサーバーに格納するか (デフォルト値 `“local”` に設定) を指定します。
`service.dwp.enable`	フロントエンドマシンがバックエンドとしても機能しない場合、DWP サービスを無効にします。次に例を示します。`service.dwp.enable="no"`
`service.dwp.port`	デフォルトのポートは `“59979”` です。すべてのフロントエンドサーバーとバックエンドサーバーに同じポート番号を指定する必要があります。
`service.store.enable`	`csstored` は、カレンダデータベースをバックアップするという設定なので、フロントエンドマシンには不要です。ただし、このプロセスを無効にする必要はありません。このパラメータを `"no"` に設定すると、フロントエンドマシンで `csstored` プロセスを無効にするように選択できます。これにより、設定されていない日単位のレポート出力のプロセスが停止します。
`caldb.dwp.server.backend-server-n` `.ip`	これは多値パラメータです。Calendar Server 配備内のバックエンドサーバーごとに 1 つの `ics.conf` パラメータを作成します。このパラメータの値は、バックエンドサーバーのホスト名です。サーバー名は完全修飾名で指定します。この名前は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。サーバー名は、パラメータの名前と値の両方で同一であり、完全修飾名である必要があります。次に例を示します。 caldb.dwp.server.calendar1.sesta.com= "calendar1.sesta.com" caldb.dwp.server.calendar2.sesta.com= "calendar2.sesta.com"
`caldb.dwp.server.default`	ユーザーまたはリソースの LDAP エントリが icsDWPHost 属性を持たない場合、システムが使用するデフォルトの DWP サーバー名を設定します。サーバー名は完全修飾名であり、DNS によって解決可能でなければなりません。次に例を示します。 caldb.dwp.sever.default= "calendar1.sesta.com"
`local.authldaphost`	Directory Server がインストールされているホストの名前。デフォルトは `"localhost"` です。
`local.ugldaphost`	LDAP ユーザー設定が格納されているホストの名前。ユーザー設定を別の LDAP ホストに格納しない場合は、このパラメータを `local.authldaphost` と同じ値に設定してください。
`service.ens.enable`	このパラメータを `"no"` に設定して、このフロントエンドサーバーの ENS (予定通知サービス) (`enpd`) を無効にします。 ENS は、バックエンドサーバーでのみ有効にしてください。
`caldb.serveralarms`	`"0"` に設定して、フロントエンドのサーバーアラームを無効にします。サーバーアラームは、バックエンドサーバーでのみ有効 (`"1"`) にしてください。
`caldb.serveralarms.dispatch`	このパラメータを `"no"` に設定して、アラームディスパッチャーを無効にします。アラームディスパッチャーは、バックエンドサーバーでのみ有効 (`"yes"`) にしてください。
`service.notify.enable`	このパラメータを `"no"` に設定して、通知サービスを無効にします。通知サービスは、バックエンドサーバーでのみ有効 (`"yes"`) にしてください。
`caldb.berkeleydb.archive.enable`	このパラメータを `"no"` に設定して、自動アーカイブバックアップサービスを無効にします。フロントエンドマシンでアーカイブを設定する必要はありません。
`caldb.berkeleydb.hotbackup.enable`	自動ホットバックアップサービスは無効に ( `"no"` に設定) してください。フロントエンドマシンでホットバックアップを行う必要はありません。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

CLD および DWP 用にバックエンドサーバーを設定するには

手順

すべてのバックエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すように、ics.conf パラメータを編集します。

パラメータ	説明
`service.http.enable`	このパラメータを `"no"` に設定します。バックエンドサーバーでは HTTP は必要ありません。
`service.admin.enable`	このパラメータをデフォルト値の `"yes"` に設定して、管理サービス (`csadmind`) を有効にします。
`caldb.cld.type`	カレンダを複数のバックエンドに分散させるか (`“directory”` に設定)、またはカレンダを Calendar Server のインストール先と同じサーバーに格納するか (デフォルト値 `“local”` に設定) を指定します。 CLD および DWP の場合、すべてのフロントエンドおよびバックエンドサーバーでこの値を `"directory"` に設定する必要があります。
`csapi.plugin.calendarlookup`	このパラメータを `"no"` に設定します。バックエンドサーバーではプラグインは必要ありません。
`service.dwp.enable`	`"yes"` に設定すると、DWP を有効にします。
`service.dwp.port`	デフォルトのポートは `“59979”` です。すべてのフロントエンドサーバーとバックエンドサーバーに同じポート番号を指定する必要があります。
`caldb.dwp.server.backend-server-n` `.ip`	これは多値パラメータです。Calendar Server 配備内のバックエンドサーバーごとに 1 つの `ics.conf` パラメータを作成します。このパラメータの値は、バックエンドサーバーのホスト名です。サーバー名は完全修飾名で指定します。この名前は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。サーバー名は、パラメータの名前と値の両方で同一であり、完全修飾名である必要があります。次に例を示します。 caldb.dwp.server.calendar1.sesta.com= "calendar1.sesta.com" caldb.dwp.server.calendar2.sesta.com= "calendar2.sesta.com"
`caldb.dwp.server.default`	ユーザーまたはリソースの LDAP エントリが `icsDWPHost` 属性を持たない場合、システムが使用するデフォルトの DWP サーバー名を設定します。サーバー名は完全修飾名であり、DNS によって解決可能でなければなりません。次に例を示します。 caldb.dwp.sever.default= "calendar1.sesta.com"
`local.authldaphost`	Directory Server がインストールされているホストの名前。デフォルトは `"localhost"` です。
`local.ugldaphost`	LDAP ユーザー設定が格納されているホストの名前。ユーザー設定を別の LDAP ホストに格納しない場合は、このパラメータを `local.authldaphost` と同じ値に設定してください。
`service.ens.enable`	このパラメータを `"yes"` に設定して、バックエンドサーバーの ENS (予定通知サービス) (`enpd`) を有効にします。
`caldb.serveralarms`	サーバーアラームは、バックエンドサーバーでは有効に (`"1"`) してください。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

フロントエンドサーバーとバックエンドサーバーを同じマシンに設定するには

手順

すべてのサーバーで、設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すように、ics.conf パラメータを編集します。

パラメータ	説明
`csapi.plugin.loadall`	`cs_` で始まるすべてのプラグインを cal_svr_base`/SUNWics5/cal/bin/plugins` ディレクトリにロードする場合は、すべてのフロントエンドサーバーでこの値を `“y”` に設定します。 `csapi.plugin.calendarlookup.name` に名前が含まれる CLD プラグインのみをロードする場合は、`“n”` に設定します。
`csapi.plugin.calendarlookup`	このパラメータを `"yes"` に設定します。
`csapi.plugin.calendarlookup.name`	すべてのプラグインをロードする場合は、`"*"` に設定します。 CLD プラグインのみをロードする場合は、プラグインの名前 `"calendarlookup"` に設定します。
`caldb.cld.type`	カレンダを複数のバックエンドに分散させるか (`“directory”` に設定)、またはカレンダを Calendar Server のインストール先と同じサーバーに格納するか (デフォルト値 `“local”` に設定) を指定します。
`service.dwp.enable`	`"yes"` に設定すると、DWP を有効にします。
`service.dwp.port`	デフォルトのポートは `“59979”` です。すべてのフロントエンドサーバーとバックエンドサーバーに同じポート番号を指定する必要があります。
`caldb.dwp.server.backend-server-n` `.ip`	これは多値パラメータです。Calendar Server 配備内のバックエンドサーバーごとに 1 つの `ics.conf` パラメータを作成します。このパラメータの値は、バックエンドサーバーのホスト名です。サーバー名は完全修飾名で指定します。この名前は、DNS (ドメイン名サービス) によって有効な IP アドレスに解決する必要があります。サーバー名は、パラメータの名前と値の両方で同一であり、完全修飾名である必要があります。次に例を示します。 caldb.dwp.server.calendar1.sesta.com= "calendar1.sesta.com" caldb.dwp.server.calendar2.sesta.com= "calendar2.sesta.com"
`caldb.dwp.server.default`	ユーザーまたはリソースの LDAP エントリが icsDWPHost 属性を持たない場合、システムが使用するデフォルトの DWP サーバー名を設定します。サーバー名は完全修飾名であり、DNS によって解決可能でなければなりません。次に例を示します。 aldb.dwp.sever.default= "calendar1.sesta.com"
`local.authldaphost`	Directory Server がインストールされているホストの名前。デフォルトは `“localhost”` です (フロントエンドと同じサーバーで)。
`local.ugldaphost`	LDAP ユーザー設定が格納されているホストの名前。ユーザー設定を別の LDAP ホストに格納しない場合は、このパラメータを `local.authldaphost` と同じ値に設定してください。
`service.ens.enable`	`"yes"` に設定して、ENS を有効にします。
`caldb.serveralarms`	サーバーアラームは、バックエンドサーバーでは有効に (`"1"`) してください。
`caldb.serveralarms.dispatch`	アラームディスパッチャーは、バックエンドサーバーでは有効に (`"yes"`) してください。
`service.notify.enable`	通知サービスは、バックエンドサーバーでは有効に (`"yes"`) してください。
`caldb.berkeleydb.archive.enable`	自動アーカイブバックアップサービスは、バックエンドシステムでは有効に (`"yes"` に設定) してください。
`caldb.berkeleydb.hotbackup.enable`	自動ホットバックアップサービスは、バックエンドシステムでは有効に (`"yes"` に設定) してください。

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

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

フロントエンドサーバーとバックエンドサーバーの間でパスワード認証を設定できます。ここでは、両サーバー間のセキュリティー保護された通信の設定方法と、それがどのように機能するかについて説明します。説明する内容は次のとおりです。

認証の行われ方

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

フロントエンドサーバーは、バックエンドサーバーへの最初の接続時に、ics.conf ファイルに指定されたユーザー ID とパスワードを送信します。バックエンドサーバーは、ics.conf ファイルのパラメータをチェックし、一致すると、認証は成功します。バックエンドサーバーは、次にセッション ID をフロントエンドサーバーに返します。フロントエンドサーバーは、バックエンドサーバーへの以後の DWP コマンドの送信時にこのセッション ID を使用します。

同じフロントエンドサーバーからの以後の接続では認証は必要ありません。ただし、バックエンドサーバーを再起動したり、2 つのサーバー間でアクティビティーがないためにセッションがタイムアウトしたりした場合には認証が必要となります。

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

バックエンドサーバーがパスワードを指定しない場合、認証は行われません。

フロントエンドサーバーの DWP 接続の認証を設定するには

始める前に

注意 –

次のパラメータは、ics.conf ファイルのインストール済みバージョンには含まれません。DWP 接続の認証を行う場合は、各フロントエンドサーバーの ics.conf ファイルに必要なパラメータを追加する必要があります。

手順

すべてのフロントエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

ics.conf パラメータを、次の表に示すように追加します。

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

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

バックエンドサーバーの DWP 接続の認証を設定するには

始める前に

注意 –

次のパラメータは、ics.conf ファイルのインストール済みバージョンには含まれません。DWP 接続の認証を行う場合は、各バックエンドサーバーの ics.conf ファイルに必要なパラメータを追加する必要があります。

手順

すべてのバックエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

ics.conf パラメータを、次の表に示すように追加します。

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

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

第 7 章高可用性 (フェイルオーバーサービス) の設定

Calendar Server の高可用性 (HA) 設定により、ソフトウェアとハードウェアの障害を監視し、回復処理を行うことができます。Calendar Server の高可用性機能は、フェイルオーバーサービスとして実装されます。この章では、Sun Cluster ソフトウェアによる Calendar Server HA の設定について説明します。

この章では、Calendar Server HA サービスのインストールと設定の方法について、次の項目で説明します。

付録 C 「高可用性 (HA) 設定のワークシート」には、Calendar Server の高可用性設定の計画に役立つワークシートが用意されています。

HA 設定の要件

Calendar Server の HA 設定には、次の表に示すソフトウェアが必要です。

ソフトウェアとバージョン	注意とパッチ
Solaris 9 OS SPARC プラットフォームのみ	Solaris 9 OS のすべてのバージョンがサポートされます。 Solaris 9 OS は Sun Cluster 3.0 U3 以降を必要とします。 Solaris 9 OS には Solaris LVM (Logical Volume Manager) が含まれます。
Solaris 8 OS SPARC プラットフォームのみ	Solaris 8 MU7 (Maintenance Update 7) OS 以降、および必要パッチの追加
Sun Cluster 3.0 U3 または 3.1	クラスタのすべてのノードに Sun Cluster ソフトウェアがインストールされ、設定が完了している必要があります。 Sun Cluster 3.1 をインストールするには、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』に記載されているインストール手順に従って Java Enterprise System インストーラを使用します。 Sun Cluster ソフトウェアのインストールが完了したら、クラスタを設定する必要があります。詳細は、Sun Cluster System Administration Guide for Solaris OSを参照してください。関連するマニュアルについては、「関連マニュアル」を参照してください。 Sun Cluster のパッチ Solaris 9 OS については、Sun Cluster InfoDoc 49704 を参照してください。 Solaris 8 OS については、Sun Cluster InfoDoc 49705 を参照してください。
Solstice DiskSuite 4	Solstice DiskSuite は Solaris 8 OS だけで利用できます。 Solaris 9 OS には LVM (Logical Volume Manager) が含まれるので、Solstice DiskSuite は必要ありません。
VxVM (Veritas Volume Manager) 3.x	Solaris 8 OS はバージョン 3.2 以降および必須パッチを必要とします。 Solaris 9 OS はバージョン 3.5 以降および必須パッチを必要とします。
VxFS (Veritas File System) 3.x	Solaris 8 OS はバージョン 3.4 以降および必須パッチを必要とします。 Solaris 9 OS はバージョン 3.5 以降および必須パッチを必要とします。 HAStoragePlus は 110435-08 以降のパッチを必要とします。

インストールと設定

ここで紹介する Calendar Server の HA 設定の例では、次の名前を使用します。

例で使用する名前	説明
`/global/cal/`	グローバルファイルシステムのマウントポイント
`cal-logical-host`	論理ホスト名
`cal-logical-host-ip`	論理ホストの IP 数値アドレス
`cs-admin`@`cal-logical-host`	Calendar Server 管理者の電子メールアドレス
`cal-node-1`	ノード 1
`cal-node-2`	ノード 2
`cal-resource-group`	カレンダリソースグループ
`cal-resource-group-store`	Calendar Server のストレージリソース
`cal-resource`	Calendar Server リソース

Calendar Server の HA 設定をインストールおよび設定するには

これは Calendar Server HA 設定のインストールおよび設定に必要な手順の詳細なリストです。

手順

「スーパーユーザーとしてログインする」

「クラスタ内の各ノードを準備する」

「Sun Java Enterprise System の製品とパッケージをインストールする」

「論理ホストを設定する」

「ストレージリソースを有効化する」

「インストール後の設定プログラムを実行する」

「自動バックアップディレクトリを共有ストレージに配置する」

「Calendar Server の config ディレクトリを変更する」

「Calendar Server の ics.conf ファイルを編集する」

「HA Calendar Server を起動する」

「HA 設定を検証する」

スーパーユーザーとしてログインする

Calendar Server の HA 設定をインストールおよび設定するには、スーパーユーザー (root) としてログインするか、スーパーユーザーになり、/dev/console に送信されるメッセージを表示するコンソールまたはウィンドウを指定します。

クラスタ内の各ノードを準備する

クラスタ内の各ノードで次の手順を実行します。

次の方法で、Calendar Server を実行する Calendar Server ランタイムユーザーおよびグループを作成します。
1. /etc/group ファイルに icsgroup (または選択した値) を追加します。
2. /etc/passwd ファイルに icsuser (または選択した値) を追加します。
ヒント –
デフォルト名は icsuser と icsgroup です。別の名前を使用することもできますが、UID と GID の番号は、クラスタ内のすべてのノードで同一である必要があります。ユーザー名を root とすることはできません。

ユーザー名とグループ名は、「インストール後の設定プログラムを実行する」の手順を実行するときに指定する必要があります。
/etc/vfstab ファイルの次のフィールドを追加または設定します。
- mount point を /global/cal (または「Calendar Server のインストールディレクトリの選択」で選択したファイルシステムのマウントポイント) に設定します。
  - mount at boot オプションを no に設定します。
  - mount options を、FFS の場合は logging、GFS の場合は global,logging に設定します。

Sun Java Enterprise System の製品とパッケージをインストールする

Sun Java Enterprise System 製品 (Calendar Server など) のインストールは、従来の Sun 製品 (Sun ONE、iPlanet など) から大幅に変更されています。Sun Java Enterprise System 製品をインストールするには、Sun Java Enterprise System インストーラを使用する必要があります。

このインストーラについては、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。

次の表は、Calendar Server の HA 設定に必要な Sun の製品とパッケージを示しています。

製品またはパッケージ	ノード 1	ノード 2
Sun Cluster ソフトウェア	必要	必要
Calendar Server (6.0 以降)	必要	不要
Calendar Server 用の Sun Cluster エージェント (`SUNWscics` パッケージ)	必要	必要
共有コンポーネント (`SUNWicu`、`SUNWldk`、`SUNWpr`、`SUNWsasl`、`SUNWtls` の各パッケージ)	必要	必要

ノード 1

ノード 1 には、選択されているすべての製品とパッケージを Java Enterprise System インストーラを使用してインストールします。Calendar Server をインストールするときは、デフォルトディレクトリ以外のディレクトリを指定する必要があります。「Calendar Server のインストールディレクトリの選択」を参照してください。

ノード 2

ノード 2 では、次の手順を実行します。

Java Enterprise System インストーラを使用して、Sun Cluster と Calendar Server 用の Sun Cluster エージェント (SUNWscics パッケージ) をインストールします。
注: Calendar Server 用の Sun Cluster エージェントだけをインストールすることはできません。Sun Cluster 用の Sun Java Enterprise System エージェントを選択すると、Java Enterprise System インストーラはすべてのエージェントをインストールします。
pkgadd コマンドを使用して、共有コンポーネント (SUNWicu、SUNWldk、SUNWpr、SUNWsasl、SUNWtls の各パッケージ) をインストールします。「共有コンポーネントのインストール」を参照してください。

Calendar Server のインストールディレクトリの選択

Calendar Server のインストールでは、Java Enterprise System インストーラはデフォルトインストールディレクトリ /opt を使用します。

しかし、HA 設定では、グローバルインストールディレクトリを指定する必要があります。例: /global/cal/opt/

共有コンポーネントのインストール

ノート 2 で必要な共有コンポーネントを利用できるようにするには、次のパッケージをインストールする必要があります。

SUNWicu – International Components for Unicode User Files
SUNWldk – LDAP C SDK
SUNWpr – Netscape Portable Runtime Interface
SUNWsasl – Simple Authentication and Security Layer (SASL)
SUNWtls – Network Security Services

これらのパッケージは、次のディレクトリに格納されています。

.../Solaris_sparc/Product/shared_components/Packages/SUNWldk
 .../Solaris_sparc/Product/shared_components/Solaris_8/Packages
 .../Solaris_sparc/Product/shared_components/Solaris_9/Packages

これらのパッケージをインストールするには、上のいずれかのディレクトリに移動し、pkgadd コマンドを実行します。次に例を示します。

# pkgadd -d . SUNWicu SUNWpr SUNWsasl SUNWtls

論理ホストを設定する

論理ホストを設定するには、次の手順を実行します。

cal-resource-group という Calendar Server フェイルオーバーリソースグループを作成します。
# scrgadm -a -g cal-resource-group -h cal-node-2,cal-node-1
リソースグループに cal-logical-host という論理ホスト名を追加します。Calendar Server はこのホスト名を待機します。
# scrgadm -a -L -g cal-resource-group -l cal-logical-host
リソースグループをオンライン状態にします。
# scswitch -Z -g cal-resource-group

ストレージリソースを有効化する

ストレージリソースを有効化するには、次の手順を実行します。

ServicePaths プロパティーにマウントポイントを指定して、ストレージリソースを登録します。

# scrgadm -a 
    -j cal-resource-group-store
    -g cal-resource-group
    -t SUNW.HAStorage
    -x ServicePaths=/global/cal
    -x AffinityOn=True

ストレージリソースを有効化します。
# scswitch -e -j cal-resource-group-store
SUNW.HAStoragePlus がグローバルファイルシステム (GFS) の設定も選択している場合は、ServicePaths プロパティーではなく、FileSystemMountPoints プロパティーの設定が必要です。

インストール後の設定プログラムを実行する

Calendar Server のインストールが完了したら、第 2 章「ディレクトリ準備スクリプト (comm_dssetup.pl)」で説明している手順に従って Directory Server セットアップスクリプト (comm_dssetup.pl) と Calendar Server 設定プログラム (csconfigurator.sh) を実行します。

次の表は、HA 設定用に指定が必要な設定情報を示しています。

表 7–1 HA 設定用の Calendar Server 設定オプション


設定パネル	説明
ランタイム設定	「ランタイムユーザー ID」と「ランタイムグループ ID」「ランタイムユーザー ID」は、Calendar Server を実行するユーザーの名前です。この名前に root を指定することはできません。デフォルトは icsuser です。「ランタイムグループ ID」は、Calendar Server を実行するグループの名前です。デフォルトは icsgroup です。これらの名前は設定プログラムによって自動的に作成されますが、この章の最初に説明した各ノードの準備の一環として、設定プログラムを実行するに作成しておいてください。これらの名前は次のファイルに設定されている必要があります。クラスタ内のすべてのノードの `/etc/passwd` に格納されている icsuser (または選択した名前) クラスタ内のすべてのノードの `/etc/etc/group` に格納されている icsgroup (または選択した名前) Calendar Server の起動次のオプションはどちらも選択しないでください。インストールが成功したら起動するシステムの起動時に起動する
ディレクトリの選択	データベース、一時ファイル、ログファイルの場所として、グローバルパーティションを選択します。次に例を示します。データベースの場合: `/global` `/cal/var/csdb` 一時ファイルの場合: `/global` `/cal/var/tmp` ログの場合: `/global` `/cal/var/logs` バックアップの場合: `/global` `/cal/var/hotbackupdb`、および `/global` `/cal/var/archivedb`

自動バックアップディレクトリを共有ストレージに配置する

HA 用の自動バックアップを設定するときは、クラスタの個々のノードで不完全なコピーが作成されないように、バックアップディレクトリを共有ストレージパーティションに配置する必要があります。バックアップディレクトリは容量が大きいため、パーティションのサイズに特に注意してください。

シンボリックリンクに対しては、ディスク容量の計算がうまく行われません。このため、自動バックアップディレクトリにはシンボリックリンクを使用しないでください。

Calendar Server の config ディレクトリを変更する

Calendar Server は、設定ファイルを config ディレクトリに格納します。以前のリリースの場合は、config ディレクトリの場所が変更されています。新しい場所は次のとおりです。

/etc/opt/SUNWics5/config/

古い config ディレクトリへのシンボリックリンクは次のディレクトリに格納されます。

/opt/SUNWics5/cal
/opt/SUNWics5/cal/lib
/opt/SUNWics5/cal/sbin

Calendar Server 設定プログラム csconfigurator.sh の実行後、後続の手順で説明するように、古い各ディレクトリのシンボリックリンクを削除して新しいディレクトリへのリンクに置き換えます。これらの手順では、/etc/opt/SUNWics5/config にある元の設定ファイルの設定が維持されることに注意してください。

開始する前に、config ディレクトリの内容の所有者が icsuser と icsgroup (またはランタイムユーザー ID とランタイムグループ ID に指定した名前) であることを確認します。

# ls -ld config
 ... icsuser icsgroup ... config/

/opt/SUNWics5/cal で見つかったシンボリックリンクを変更する方法

/global/cal/opt/SUNWics5/cal ディレクトリに移動します。次に例を示します。
# cd /global/cal/opt/SUNWics5/cal/
この /global/cal はファイルシステムのマウントポイントです。
config が新しい config ディレクトリへのシンボリックリンクであることを確認します。次に例を示します。
# ls -l config ... config -\> /etc/opt/SUNWics5/config/
/opt/SUNWics5/cal/ ディレクトリでシンボリックリンク config を削除します。
# cd /opt/SUNWics5/cal # rm config
所有者と権限を維持したまま、/etc/opt/SUNWics5/config の内容を新しい HA ディレクトリにコピーします。
# cd /global/cal/opt/SUNWics5/cal # cp -pr /etc/opt/SUNWics5/config .

/opt/SUNWics5/lib で見つかったシンボリックリンクを変更する方法

/global/cal/opt/SUNWics5/cal/lib ディレクトリで、config が /etc/opt/SUNWics5/config へのシンボリックリンクであることを確認します。
# cd /global/cal/opt/SUNWics5/cal/lib # ls -l config ... config -\> /etc/opt/SUNWics5/config/
config シンボリックリンクを削除します。
# rm config
新しい config の場所へのシンボリックリンクを作成します。
# ln -s ../config config

新しいリンクを検証します。

# ls -l config
 ... config -\> ../config/

/opt/SUNWics5/sbin で見つかったシンボリックリンクを変更する方法

/global/cal/opt/SUNWics5/cal/lib ディレクトリで、config が /etc/opt/SUNWics5/config へのシンボリックリンクであることを確認します。
# cd /global/cal/opt/SUNWics5/cal/sbin # ls -l config ... config -\> /etc/opt/SUNWics5/config/
config シンボリックリンクを削除します。
# rm config
新しい config の場所へのシンボリックリンクを作成します。
# ln -s ../config config
新しいリンクを検証します。
# ls -l config ... config -\> ../config/
注 –
Calendar Server をアンインストールするときは、Java Enterprise System アンインストーラを使用します。このアンインストーラは、SUNWics5 および SUNWica5 パッケージを削除します。

ただし、Calendar Server の HA 設定では、アンインストーラを実行する前に、まず、場所を変更した config ディレクトリとその内容を削除する必要があります。次に例を示します。
# cd /global/cal/opt/SUNWics5/cal/ # rm -rf config
config ディレクトリを削除しないと、SUNWics5 パッケージのアンインストール処理は失敗します。

Calendar Server の ics.conf ファイルを編集する

/opt/SUNWics5/cal/config ディレクトリで、ics.conf 設定ファイルを次のように編集します。

次のパラメータを追加します。

local.server.ha.enabled="yes"
 local.server.ha.agent="SUNWscics"

service.listenaddr パラメータの名前を service.http.listenaddr に変更し、このパラメータに論理ホストの IP アドレスを設定します。次に例を示します。
service.http.listenaddr = "cal-logical-host-ip"
この “cal-logical-host-ip” は、論理ホストの数値 IP アドレスです。例: 123.321.12.2

ローカルホスト名を参照するすべてのパラメータが、論理ホスト名を参照するように変更します。次に例を示します。

local.hostname="cal-logical-host"
 local.servername="cal-logical-host"
 service.ens.host="cal-logical-host"
 service.http.calendarhostname="cal-logical-host.sesta.com"

HA Calendar Server を起動する

HA Calendar Server を起動する前に、次のようにカレンダリソースのタイプを SUNWscics として登録し、カレンダリソースを作成します。

カレンダリソースのタイプを登録します。
# scrgadm -a -t SUNW.scics

カレンダリソースを作成します。

# scrgadm -a 
        -j cal-resource 
        -g cal-resource-group
        -t SUNW.scics 
        -x Confdir_list=/global/cal/cal-resource-group 
        -y Resource_dependencies=cal-resource-group-store 
        -y Port_list=80/tcp

リソースを有効化し、Calendar Server を起動します。
# scswitch -e -j cal-resource

HA 設定を検証する

Calendar Server を起動したら、すべての必要プロセスまたはデーモン (csadmind、enpd、csnotifyd、cshttpd) が稼動していることを確認します。

また、バックアップノードへのサービスの切り替えを行い、高可用性が確保されていることを確認します。たとえば、サービスが cal-node-1 で稼動している場合、次のコマンドを実行してサービスを cal-node-2 に切り替えます。

# scswitch -z -g cal-resource-group
                            -h cal-node-2

次に、cal-node-2 ですべてのプロセスが開始されることを確認します。

トラブルシューティング用に、エラーメッセージがコンソールと /var/adm/messages に出力されます。

ログレベルは /var/cluster/rgm/rt/SUNW.scics/loglevel ファイルに設定されています。詳細度を最大にするときは、“9” に設定します。

ログ機能の使用方法については、「関連マニュアル」を参照してください。

Calendar Server の HA サービスの起動と停止

Calendar Server の HA サービスを起動、停止するときは、Sun Cluster の scswitch コマンドを使用します。Calendar Server の start-cal、csstart、stop-cal、または csstop ユーティリティーを使用しないでください。次に例を示します。

Calendar Server の HA サービスを起動するには

# scswitch -e -j cal-resource

Calendar Server の HA サービスを停止するには

# scswitch -n -j cal-resource

Calendar Server の HA サービスを再起動するには

# scswitch -R -j cal-resource

Sun Cluster の scswitch コマンドについては、『Sun Cluster Reference Manual for Solaris OS』を参照してください。

第 8 章 SSL の設定

Calendar Server は、カレンダクライアントのエンドユーザーと Calendar Server との間でデータを暗号化するために、SSL (Secure Sockets Layer) プロトコルをサポートしています。SSL をサポートするために、Calendar Server は Sun Java System Messaging Server でも使用されている NSS (Netscape Security Services) の SSL ライブラリを使用します。

ics.conf ファイルを使用して、Calendar Server のログインとパスワードだけ、またはカレンダセッション全体を暗号化するように Calendar Server を設定できます。

この章では、SSL の設定に必要な次の 3 つの作業とトラブルシューティングについて説明します。

注 –

Calendar Server はクライアントベースの SSL 認証をサポートしません。

Calendar Server の SSL 設定

証明書データベースを作成するには

Calendar Server に SSL を実装するには、証明書データベースが必要です。証明書データベースには、CA (証明書発行局) と Calendar Server の証明書を定義する必要があります。ここでは、概念的な情報と、作業に関する情報を提供します。

始める前に

証明書データベースを作成する前に、次のことを把握しておいてください。

Mozilla ツール — このリリースには次の Mozilla ツールが用意されています。
- 証明書データベースツール (certutil): 証明書データベースを作成、管理します。詳細は、次の Web サイトを参照してください。
```
http://mozilla.org/projects/security/pki/
        nss/tools/certutil.html
```
  ヒント –
  証明書データベースの生成を試みる前に、ツールの構文に慣れておいてください。
- セキュリティーモジュールデータベースツール (modutil): 使用できるセキュリティーモジュールに関する情報を表示します。詳細は、次の Web サイトを参照してください。
```
http://mozilla.org/projects/security/pki/
        nss/tools/modutil.html
```
  これらのユーティリティーは、次のディレクトリに格納されています。
```
/opt/SUNWics5/cal/lib
```
  または、最新バージョンを Web サイトからダウンロードしてください。
ライブラリパス変数 — Mozilla ツールを使用するには、事前に LD_LIBRARY_PATH 変数を適切に設定する必要があります。次に例を示します。
```
setenv LD_LIBRARY_PATH /opt/SUNWics5/cal/lib
```
例で使用するファイルとディレクトリ — この章で紹介する例は、次のファイルとディレクトリを使用します。
- alias は、証明書データベースを格納したディレクトリです。次のディレクトリの中に alias ディレクトリを作成します。
```
/var/opt/SUNWics5
```
  また、alias ディレクトリは定期的にバックアップしてください。
- sslPasswordFile は、証明書データベースのパスワードを記録したテキストファイルです。これは certutil ユーティリティーが使用するファイルで、Calendar Server は使用しません。次のディレクトリに sslPasswordFile を作成します。
```
/etc/opt/SUNWics5/config
```
- /etc/passwd には、乱数生成用のエントロピーが用意されています。つまり、このディレクトリは、乱数生成機能が真にランダムな結果を確実に生成するのに役立つ、有効で一意なシードを生成するために使用されます。

手順

スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

/etc/opt/SUNWics5/config/sslPasswordFile に certutil の証明書データベースパスワードを指定します。次に例を示します。
# echo "password" /etc/opt/SUNWics5/config/sslPasswordFile
password には実際のパスワードを指定します。

証明書データベースの alias ディレクトリを作成します。次に例を示します。
# cd /var/opt/SUNWics5 # mkdir alias

bin ディレクトリに移動し、証明書データベース (cert8.db) と鍵データベース (key3.db) を生成します。次に例を示します。
# cd /opt/SUNWics5/cal/bin # ./certutil -N -d /var/opt/SUNWics5/alias -f /etc/opt/SUNWics5/config/sslPasswordFile
注 –
certutil ユーティリティーを実行する必要がある場合は、例に従って実行するか、または certutil のヘルプページを参照して構文を理解してください。

たとえばこの場合、-d /ファイル情報を指定せずに -N オプションを付けてユーティリティーを実行することは避けてください。

デフォルトの自己署名ルート CA (証明書発行局) 証明書を生成します。次に例を示します。

# ./certutil -S -n SampleRootCA -x -t "CTu,CTu,CTu"
 -s "CN=My Sample Root CA, O=sesta.com" -m 25000
 -o /var/opt/SUNWics5/alias/SampleRootCA.crt
 -d /var/opt/SUNWics5/alias
 -f /etc/opt/SUNWics5/config/sslPasswordFile -z
 /etc/passwd

ホスト用の証明書を生成します。次に例を示します。

# ./certutil -S -n SampleSSLServerCert -c SampleRootCA 
 -t "u,u,u"
 -s "CN=hostname.sesta.com, O=sesta.com" -m 25001
 -o /var/opt/SUNWics5/alias/SampleSSLServer.crt
 -d /var/opt/SUNWics5/alias 
 -f /etc/opt/SUNWics5/config/sslPasswordFile
 -z /etc/passwd

hostname.sesta.com はサーバーホスト名です。

証明書を検証します。次に例を示します。

# ./certutil -V -u V -n SampleRootCA  
    -d /var/opt/SUNWics5/alias
 # ./certutil -V -u V -n SampleSSLServerCert 
   -d /var/opt/SUNWics5/alias

証明書をリスト表示します。次に例を示します。

# ./certutil -L -d /var/opt/SUNWics5/alias
 # ./certutil -L -n SampleSSLServerCert 
   -d /var/opt/SUNWics5/alias

modutil を使用して、使用できるセキュリティーモジュール (secmod.db) をリスト表示します。次に例を示します。
# ./modutil -list -dbdir /var/opt/SUNWics5/alias

alias ファイルの所有者を icsuser と icsgroup (または Calendar Server を実行するそれ以外のユーザーとグループの ID) に変更します。次に例を示します。
# find /var/opt/SUNWics5/alias -exec chown icsuser {}; # find /var/opt/SUNWics5/alias -exec chgrp icsgroup {};

ルート CA (証明書発行局) に証明書を要求し、証明書をインポートするには

次の手順で、証明書要求の生成、PKI (Public Key Infrastructure) の Web サイトへの要求の送信、証明書のインポートを行う方法について説明します。

手順

スーパーユーザー (root) としてログインするか、スーパーユーザーになります。

bin ディレクトリに移動します。
# cd /opt/SUNWics5/cal/bin

certutil を使用して、証明書発行局または PKI (Public Key Infrastructure) の Web サイトに適した証明書要求を作成します。次に例を示します。

# ./certutil -R -s "CN=hostname.sesta.com, 
OU=hostname/ SSL Web Server, O=Sesta, 
C=US" -p "408-555-1234" -o hostnameCert.req 
-g 1024  -d /var/opt/SUNWics5/alias 
-f /etc/opt/SUNWics5/config/sslPasswordFile  -z /etc/passwd -a

ここで、“hostname.sesta.com” はサーバーホスト名です。

SSL Web サーバー用のテスト証明書を CA (証明書発行局) または PKI (Public Key Infrastructure) の Web サイトに要求します。hostnameCert.req ファイルの内容をコピーして証明書要求に貼り付けます。

証明書への署名が完了し、準備が整った時点で通知が送信されてきます。

証明書発行局証明書チェーンと SSL サーバー証明書をテキストファイルにコピーします。

証明書認証局証明書チェーンを証明書データベースにインポートし、認証チェーンを確立します。次に例を示します。

# ./certutil -A -n "GTE CyberTrust Root"
    -t "TCu,TCu,TCuw" 
    -d /var/opt/SUNWics5/alias 
    -a 
    -i /export/wspace/Certificates/CA_Certificate_1.txt
    -f /etc/opt/SUNWics5/config/sslPasswordFile
# ./certutil -A -n "Sesta TEST Root CA" 
    -t "TCu,TCu,TCuw" 
    -d /var/opt/SUNWics5/alias 
    -a 
    -i /export/wspace/Certificates/CA_Certificate_2.txt
    -f /etc/opt/SUNWics5/config/sslPasswordFile

署名された SSL サーバー証明書をインポートします。

# ./certutil -A -n "hostname SSL Server Test Cert"
    -t "u,u,u" -d /var/opt/SUNWics5/alias 
    -a 
    -i /export/wspace/Certificates/SSL_Server_Certificate.txt
    -f /etc/opt/SUNWics5/config/sslPasswordFile

証明書データベース内の証明書をリスト表示します。
# ./certutil -L -d /var/opt/SUNWics5/alias

ics.conf ファイルで、署名された SSL サーバー証明書の SSL サーバーニックネームを設定します。例: “hostname SSL Server Test Cert”

注: ics.conf ファイルの service.http.calendarhostname パラメータと service.http.ssl.sourceurl パラメータのホスト名は、SSL 証明書のホスト名と一致する必要があります (システムに複数のエイリアスがある場合)。例: calendar.sesta.com

ics.conf ファイルの SSL パラメータを設定するには

Calendar Server に SSL を実装するには、ics.conf ファイルの特定のパラメータを設定する必要があります。次の表に示されているパラメータのいずれかが ics.conf ファイルにない場合、指定した値とともにファイルに追加します。システムの起動時 (start-cal の実行時) は ics.conf が読み取り専用であるため、新しい値は Calendar Server が再起動されるまで反映されません。これらの SSL パラメータについては、「SSL の設定」を参照してください。

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の表に示すパラメータを 1 つ以上編集します。

パラメータ	値
`encryption.rsa.nssslactivation`	`“on”`
`encryption.rsa.nssslpersonalityssl`	`“SampleSSLServerCert”`
`encryption.rsa.nsssltoken`	`“internal”`
`service.http.tmpdir`	`“/var/opt/SUNWics5/tmp”`
`service.http.uidir.path`	`“html”`
`service.http.ssl.cachedir`	`“.”`
`service.http.ssl.cachesize`	`“10000”`
`service.http.ssl.certdb.password`	`" "` (適切なパスワードを入力)
`service.http.ssl.certdb.path`	`“/var/opt/SUNWics5/alias”`
`service.http.ssl.port.enable`	`“yes”`
`service.http.ssl.port`	`"443"` (デフォルトの SSL ポート) 注 – HTTP のデフォルトポートであるポート `"80"` ではありません。
`service.http.securesession`	`"yes"` (セッション全体を暗号化する)
`service.http.ssl.sourceurl`	`“https”//localhost:port”` (ローカルホスト名、および `service.http.ssl.port` の値を入力)
`service.http.ssl.ssl2.ciphers`	`““`
`service.http.ssl.ssl2.sessiontimeout`	`“0”`
`service.http.ssl.ssl3.ciphers`	`"rsa_red_40_md5,` `rsa_rc2_40_md5,` `rsa_des_sha,` `rsa_rc4_128_md5,` `rsa_3des_sha"`
`service.http.ssl.ssl3.sessiontimeout`	`“0”`
`service.http.sslusessl`	`“yes”`

ファイルを ics.conf として保存します。

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

cal_svr_base/SUNWics5/cal/sbin/start-cal

SSL のトラブルシューティング

まず、復元不可能な問題の発生に備え、証明書データベースを必ず定期的にバックアップしてください。SSL に問題があるときは、次の項目を調べます。

cshttpd プロセスのチェック

SSL が機能するには、Calendar Server の cshttpd プロセスが稼動している必要があります。cshttpd が稼動しているかどうかを確認するには、次のコマンドを実行します。

# ps -ef | grep cshttpd

証明書の検証

証明書データベースに格納されている証明書の一覧を表示し、その有効期限を確認するには、次のコマンドを実行します。

# ./certutil -L -d /var/opt/SUNWics5/alias

Calendar Server ログファイルの確認

SSL エラーについて、Calendar Server ログファイルを確認します。詳細は、「Calendar Server ログファイルの使用」を参照してください。

SSL ポートへの接続

ブラウザに次の URL を指定し、SSL ポートに接続します。

https://server-name:ssl-port-number

それぞれの意味は次のとおりです。

server-name は Calendar Server が稼動しているサーバーの名前です。

ssl-port-number は、ics.conf ファイルの service.http.ssl.port パラメータに指定されている SSL ポート番号です。デフォルトは 443 です。

cshttpd の標準 HTTP ポートでの待機を停止する方法

HTTP と HTTPS は別々のポート (SSL は 443、HTTP は 80) で待機するため、両方が同じポートで待機することはありません。現在、標準の HTTP ポートでの待機を停止するよう cshttpd に通知するための手段はありません。ただし、管理者が service.http.port を非公開の番号に変更することはできます。

注意 –

cshttpd が HTTP で待機しないようにするために service.http.enable ="no" を設定することは避けてください。その設定を行うと、HTTPS も失敗する可能性があります。SSL を適切に設定するには、service.http.enable と service.http.ssl.port.enable の両方を "yes" に設定する必要があります。

第 9 章シングルサインオンの設定

この章では、シングルサインオン (SSO) の設定方法について説明します。

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

Access Manager による SSO の設定

Calendar Server および Messaging Server を含む Sun Java Enterprise System サーバーは、Sun Java System Access Manager (リリース 6 2003Q4 以降) を使用して SSO を実装できます。

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

Calendar Server で SSO を使用するには

手順

Access Manager と Directory Server がインストールされ、設定されていることを確認します。これらの製品のインストールと設定については、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。

「Access Manager による SSO の設定」に示すパラメータを設定して Calendar Server 用に SSO を設定し、Calendar Server を再起動して値を有効にします。パラメータを設定するときは、必要に応じてコメント記号 (!) を外します。

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

Messaging Server で SSO を利用するための設定については、『Sun Java System Messaging Server 6 2005Q4 Administration Guide』を参照してください。

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

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

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

Access Manager を利用した SSO に関する注意事項

カレンダセッションが有効なのは、Access Manager のセッションが有効である期間に限られます。ユーザーが Access Manager からログアウトすると、そのユーザーのカレンダセッションは自動的に閉じます (シングルサインオフ)。
SSO アプリケーションは、同じドメインに存在する必要があります。
SSO アプリケーションは、Access Manager の検証 URL (ネーミングサービス) にアクセスできる必要があります。
ブラウザは、Cookie をサポートしている必要があります。
Sun Java System Portal Server ゲートウェイを使用している場合は、次の Calendar Server パラメータを設定します。
- service.http.ipsecurity="no"
- render.xslonclient.enable="no"

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

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

信頼できるアプリケーションのそれぞれで SSO を設定する必要があります。
ブラウザのキャッシュに default.html ページが含まれている場合、SSO は正しく機能しません。SSO を使用する前に、ブラウザで default.html ページを再度読み込んでください。たとえば、Netscape Navigator であれば、Shift キーを押しながら更新ボタンをクリックします。
SSO は、「修飾されていない」URL でのみ機能します。たとえば、http://servername であれば SSO は機能します。

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

表 9–1 Communications サーバーの信頼できるサークルテクノロジを利用して SSO を設定する場合の Calendar Server 設定パラメータ


パラメータ	説明
`sso.enable`	SSO を有効にするには、このパラメータを 1 (デフォルト) に設定する必要があります。"0" に設定すると SSO は無効になります。
`sso.appid`	このパラメータには、Calendar Server の特定のインストールを指定する一意のアプリケーション ID を指定します。信頼できるそれぞれのアプリケーションは、一意のアプリケーション ID を持ちます。デフォルトは `"ics50"` です。
`sso.appprefix`	このパラメータには、SSO cookie のフォーマットに使用される接頭辞の値を指定します。Calendar Server は、この接頭辞を持つ SSO cookie だけを認識するため、信頼できるすべてのアプリケーションがこれと同じ値を使用する必要があります。デフォルトは `"ssogrp1"` です。
`sso.cookiedomain`	このパラメータにより、ブラウザは指定ドメイン内のサーバーだけに cookie を送信します。この値は、ピリオド (.) から開始する必要があります。
`sso.singlesignoff`	`“true”` (デフォルト) に設定すると、sso.apprefix で設定された値と一致する接頭辞値を持つクライアント側のすべての SSO cookie がクライアントのログアウト時にクリアされます。
`sso.userdomain`	このパラメータには、ユーザーの SSO 認証の一部として使用されるドメインを設定します。
sso.`appid`.url = "`verifyurl`"	このパラメータには、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` です。次に例を示します。 sso.ics50.url= "http://sesta.com:8883 /VerifySSO?" sso.msg50.url= "http://sesta.com:8882 /VerifySSO?"

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

表 9–2 Communications サーバーの信頼できるサークルテクノロジを利用して SSO を設定する場合の Messaging Server 設定パラメータ


パラメータ	説明
`local.webmail.sso.enable`	SSO を有効にするには、パラメータにゼロ以外の値を設定する必要があります。
`local.webmail.sso.prefix`	このパラメータには、HTTP サーバーが設定する SSO cookie のフォーマットに使用される接頭辞を指定します。次に例を示します。`ssogrp1`
`local.webmail.sso.id`	このパラメータには、Messaging Server の一意のアプリケーション ID (たとえば、`msg50`) を指定します。信頼できるそれぞれのアプリケーションは、一意のアプリケーション ID を持ちます。
`local.webmail.sso.cookiedomain`	このパラメータには、HTTP サーバーが設定するすべての SSO cookie の cookie ドメイン値を指定します。
`local.webmail.sso.singlesignoff`	ゼロ以外の値に設定すると、`local.webmail.sso.prefix` で設定された値と一致する接頭辞値を持つクライアント側のすべての SSO cookie がクライアントのログアウト時にクリアされます。
`local.sso.appid.url=` `verifyurl`	このパラメータには、Messaging Server 設定のピア SSO ホストの確認 URL 値を設定します。信頼できるピア SSO ホストごとに 1 つのパラメータが必要となります。パラメータには次の要素が含まれます。アプリケーション ID (`appid`)。対象となる各 SSO cookie のそれぞれのピア SSO ホストを識別する確認 URL (`verifyurl`)。ホスト URL、ホストポート番号、および `VerifySSO?` (最後の `?` を含む) から構成される次に例を示します。 `local.sso.ics50.verifyurl=` `http://sesta.com:8883/VerifySSO?` この例では、Calendar Server のアプリケーション ID は `ics50`、ホスト URL は `sesta.com`、ポートは `8883` です。 `local.sso.msg50.verifyurl=` `http://sesta.com:8882/VerifySSO?` この例では、Messaging Server のアプリケーション ID は `msg50`、ホスト URL は `sesta.com`、ポートは `8882` です。

Messaging Server で SSO を設定する方法については、『Sun Java System Messaging Server 6 2005Q4 Administration Guide』を参照してください。

第 10 章自動バックアップ (csstored) の設定

設定時に、自動バックアップを有効にすることができます。ただし、自動バックアップは設定後にいつでも有効または無効にすることができます。データを保護し、運用停止時間を最小限に抑えるためには、すぐれたバックアップシステムの導入が不可欠です。

この章では、自動バックアップが実行されるように Calendar Server サービス csstored を設定する方法について説明します。この章で説明する内容は次のとおりです。

注 –

ここで説明する自動バックアッププロセスを使用しない場合は、独自のバックアップ計画を導入してデータを保護する必要があります。データを保護するためのほかの Calendar Server ツールの使用方法については、第 17 章「Calendar Server データのバックアップと復元」を参照してください。

csstored の概要については、次の Web サイトで入手できる『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』を参照してください。

自動バックアップの概要

ここで説明する内容は次のとおりです。

自動バックアップの機能

Calendar Server システムでは、カレンダデータベースの各トランザクション (カレンダやそのプロパティーへの追加、変更、または削除) をトランザクションログファイルに記録します。あらかじめ決められた間隔で、このログファイルは書き込みのために閉じて、別のログファイルが作成されます。次に、システムでは、時間があるときに、もっとも古い閉じたトランザクションログのトランザクションを実際のカレンダデータベースに適用します。ログに含まれているすべてのトランザクションがデータベースに適用されると、そのログには「適用済み」というマークが付けられます。

ホットバックアップが設定されている場合、実際のデータベースのスナップショットが 24 時間ごとに取得されます。適用済みのログは、その後、データベースのホットバックアップのコピーに適用されます。ホットバックアップデータベースは、まだ適用されていないトランザクションを除いては最新の状態です。

csstored の機能

起動時に開始される Calendar Server サービスの 1 つに csstored があります。このサービスを設定すると、カレンダデータベースの自動バックアップ (ホットバックアップかアーカイブバックアップのどちらか、またはその両方) が実行されます。

csstored の自動バックアップ用の設定は、設定プログラム csconfigurator.sh を実行するときに行うことができます。その時点で自動バックアップのどちらかまたは両方を選択した場合は、これ以上の設定手順は必要ありません。

設定プログラムで自動バックアップを選択しなかった場合は、自動バックアップが無効になっていますが、csstored プロセスは実行されます。ただし、自動バックアップが有効になるまで、csstored によって実行される機能は、csstored が設定されていない (自動バックアップが有効になっていない) ことを知らせる管理者の情報メッセージを 24 時間ごとに生成することのみです。

注 –

自動バックアップが無効になっているときは、循環ログの ics.conf パラメータである caldb.berkeley.circularlogging を “yes” に設定することをお勧めします。これにより、古いデータベーストランザクションログが破棄されるため、ディスク容量を節約できます。

循環バックアップの機能

自動バックアップが有効になっている場合、csstored は、循環バックアップシステムを使用してバックアップデータベースファイルで保持されるバックアップコピーの数を自動的に管理します。

csstored は、バックアップコピーがその最大数まで蓄積されるか、許容される最大ディスク容量に達するまで、バックアップをバックアップデータベースディレクトリに格納します。どちらかの上限に達すると、保持されるコピー数が最小数になり、ディスク容量がしきい値を下回るまで、バックアップコピーは古いものから先に破棄されます。

循環バックアップの制御には、1 組の ics.conf パラメータが使用されます。これらのパラメータにはデフォルト値が用意されているため、特にカスタマイズは必要ありません。システム内でのバックアップの動作方法を調整する場合は、「自動バックアップの調整」を参照してください。

自動バックアップを有効にするための高レベルの手順

自動バックアップを有効にするための一連の作業の概略は次のとおりです。

トランザクションログファイルの設定

ここで説明する内容は次のとおりです。

トランザクションログファイルについて

トランザクションログファイルは、Calendar Server で最後のスナップショット以降にカレンダデータベースに対して行われた追加、変更、および削除をすべて取り込むために使用されます。トランザクションは実際には、ログファイルが書き込みのために閉じるまで、ライブデータベースに適用されることはありません。間隔を表すパラメータは、古いログファイルを閉じて、新しいログファイルを作成する頻度を指定します。

ログファイル名は、設定可能な名前の末尾に一意の番号を付けて表します。

ログファイルが閉じると、ライブデータベースにいつでも適用できます。ライブデータベースへの適用は非同期的に行われます。つまり、ログファイルの作成とそのファイルへのトランザクションの書き込みが「リアルタイム」で行われる一方で、トランザクションをデータベースに適用するプログラムが、ログファイルへのトランザクションの書き込みに関係なく単独で実行されます。システムがビジー状態の場合は、データベースへの適用を待機するログファイルの数が増加する可能性があります。システムに余力があるときは、トランザクションを適用するプログラムが遅れを「取り戻し」、実際にはアイドル状態で次のトランザクションログを待機していることもあります。

トランザクションは、ライブデータベースに適用されたあと、ホットバックアップのスナップショット (有効な場合) に適用されます。また、ログファイルはスナップショットが格納されているディレクトリと同じアーカイブディレクトリに書き込まれます。

トランザクションログファイルを設定するには

手順

コマンド行で、ics.conf が格納されているディレクトリに移動します。

cd/etc/opt/SUNWics5/config

トランザクションログ名を指定します。

logfile.store.logname= storename.log

トランザクションログディレクトリのディレクトリパスを指定します。

デフォルト値は次のとおりです。logfile.logdir="logs"

ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

管理者の電子メールアドレスの指定

ここで説明する内容は次のとおりです。

管理者に送信される電子メールメッセージ

なんらかのイベントまたはエラーが発生すると、電子メールによって管理者に通知します。電子メールメッセージが生成されるイベントは次のとおりです。

自動バックアップが有効になっていないか、正しく設定されていない。

スナップショットが取得されるときに自動バックアップが有効になっていないと、自動バックアップが正しく設定されていないことが csstored プロセスによって 24 時間ごとに通知されます。
ディスク容量のしきい値を超えている。

このメッセージは、その状態が解消されるまで定期的に送信されます。
サービスが停止しているか、再起動できない。

電子メール通知には、サービスを起動できるようにするために必要な対処法が記載されています。

管理者の電子メールアドレスを設定するには

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次の ics.conf パラメータを編集して、管理者の電子メールアドレスを指定します。

alarm.msgalarmnoticercpt=” admin@email_address”

ファイルを ics.conf として保存します。

Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

ホットバックアップの有効化

ここで説明する内容は次のとおりです。

ホットバックアップとは

ホットバックアップは、現在書き込み中のトランザクションログを除くすべてのトランザクションログが適用されている最新のスナップショットで構成されていることが理想的です。しかし、システムのビジー状態によっては、トランザクションログの適用が遅れることがあります。このため、データベースにもホットバックアップにも適用されていないログファイルがいくつか存在する可能性があります。

このようにライブデータベースと「ほぼ同じ内容」にするのは、なんらかの大惨事が発生した場合やデータベースの破損が見つかった場合に停止時間とデータの損失を最小限に抑えるためです。

新しいホットバックアップは、24 時間ごとに新しいスナップショットが取得されるときに開始されます。古いホットバックアップは検証され、破棄されるまで保存されます。詳細は、「循環バックアップの機能」を参照してください。

ホットバックアップを有効にするには

手順

コマンド行で、ics.conf が格納されているディレクトリに移動します。

cd /etc/opt/SUNWics5/config

次の ics.conf パラメータを “yes” に設定して、ホットバックアップを有効にします。

caldb.berkeleydb.hotbackup.enable=”yes”

ホットバックアップディレクトリのディレクトリパスを指定します。
```
caldb.berkeleydb.hotbackup.path=
   /var/opt/SUNWics5/hotbackup_directory
```
一次ディスクドライブにハードウェア障害が発生した場合に備えて、ホットバックアップを別のディスクまたはディスクサブシステムで行うこともできます。こうすることにより、一次ドライブまたはサブシステム上で発生する I/O の競合も減少する場合があります。

高可用性 (HA) の設定を行っている場合は、このパスを共有ストレージ (/global /cal/) のサブディレクトリとして指定します。第 7 章「高可用性 (フェイルオーバーサービス) の設定」も参照してください。

ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。

cal_svr_base /SUNWics5/cal/sbin/start-cal

ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

アーカイブバックアップの有効化

ここで説明する内容は次のとおりです。

アーカイブバックアップとは

アーカイブバックアップは、スナップショットと、そのために作成されたログファイルから構成されます。ログファイルは、スナップショットには適用されません。アーカイブデータベースは、破棄されるまでディスクに残ります。「循環バックアップの機能」を参照してください。

アーカイブバックアップを有効にするには

手順

コマンド行で、ics.conf が格納されているディレクトリに移動します。

cd /etc/opt/SUNWics5/config

次の ics.conf パラメータを “yes” に設定して、アーカイブバックアップを有効にします。

caldb.berkeleydb.archive.enable=”yes”

アーカイブディレクトリのディレクトリパスを指定します。
```
caldb.berkeleydb.archive.path=
   /var/opt/SUNWics5/archive_backup_directory
```
一次ディスクドライブにハードウェア障害が発生した場合に備えて、アーカイブバックアップを別のディスクまたはディスクサブシステムで行うこともできます。こうすることにより、一次ドライブまたはサブシステム上で発生する I/O の競合も減少する場合があります。

高可用性 (HA) の設定を行っている場合は、このパスを共有ストレージ ( /global/cal/) のサブディレクトリとして指定します。第 7 章「高可用性 (フェイルオーバーサービス) の設定」も参照してください。

ics.conf ファイルの編集が終わったら、Calendar Server を再起動します。
```
cal_svr_base/SUNWics5/cal/sbin/start-cal
```
ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

警告メッセージの無効化

ここでは、設定されていない csstored プロセスによる日常的な警告メッセージについて、およびその停止方法について説明します。ここで説明する内容は次のとおりです。

メッセージが発行される理由

start-cal プログラムはデフォルトで csstored プロセスを起動します。バックエンドマシンで、バックアップ用に csstored を設定していない場合、またはフロントエンドマシンにバックアップする必要があるデータベースを格納していない場合、設定されていないすべてのマシンから、24 時間ごとに情報メッセージが送信されます。csstored によるこのようなメッセージが必要ない場合は、csstored の実行を無効にする必要があります。

csstored の実行を無効にする方法

手順

設定を変更する権限を持つ管理者としてログインします。

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

古い ics.conf ファイルをコピーして名前を変更し、保存します。

次のパラメータを ics.conf ファイルに追加して、csstored の実行を無効にします。

service.store.enable="no"

ファイルを ics.conf として保存します。

Calendar Server を再起動します。
```
cal_svr_base/SUNWics5/cal/sbin/start-cal
```
ics.conf ファイルを編集するときにカレンダサービスを停止する必要はありませんが、変更を適用するためにサービスを再起動する必要があります。

注 –
自動バックアップ用に csstored を設定したマシンでは、csstored を無効にしないでください。

第 11 章ホストされたドメインの設定

Calendar Server はホストされた (または仮想) ドメインをサポートしています。ホストされたドメインのインストールでは、各ドメインが Calendar Server の同じインスタンスを共有するため、1 つのサーバーに複数のドメインが存在できます。各ドメインはネームスペースを定義し、1 つのネームスペースではすべてのユーザー、グループ、リソースが一意です。各ドメインには、変更可能な属性とユーザー設定もあります。

この章で説明する内容は次のとおりです。

注 –

『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』では、ホストされたドメインを使用するためのインストール準備に必要なすべての手順を説明しています。

注意 –

現在のサイトに複数の Calendar Server インスタンスが設定されていたり、限定的な仮想ドメインモードが設定されている場合は、移行要件の評価について購入先の顧客サービスの担当者に問い合わせてください。

ホストされたドメインの概要

ここでは、ホストされたドメインの概要について、次の項目を説明します。

LDAP ディレクトリの構造

ホストされたドメインのインストールでは、LDAP ディレクトリは完全に区別され、部分的な交差もありません。それぞれの LDAP ディレクトリが DNS (ドメイン名システム) 内のドメインを表します。ユーザー、グループおよびリソースの uid は各ドメイン内で一意です。たとえば、uid が jdoe のユーザーは各ドメインで 1 人だけです。識別名 (DN) は、各ドメインのルートを表します。

Calendar Server は、ホストされたドメインで次の両方の LDAP ディレクトリスキーマバージョンをサポートしています。

「Sun LDAP Schema 2」 (互換モードまたはネイティブモード)
「Sun LDAP Schema 1」

Directory Server セットアップスクリプト (comm_dssetup.pl) を実行するときに、LDAP Schema 1 または LDAP Schema 2 のいずれかを選択できます。次の点に注意してください。

新規インストール: Calendar Server を新規インストールとしてサイトにインストールする場合は、LDAP Schema 2 を使用します。
アップグレード: Calendar Server バージョン 5 からのアップグレードでは、スキーマバージョンを次のように選択します。
- シングルサインオン (SSO) などの Access Manager 機能を使用する場合、または Delegated Administrator を使用する場合は、LDAP Schema 2 を選択します。
- ホストされたドメインがない、Access Manager 機能を使用しない、または Delegated Administrator によるユーザーのプロビジョニングを行わない場合は、どちらのスキーマバージョンも使用できます。ただし、可能であれば LDAP Schema 2 を使用します。

Sun LDAP Schema 2

次の図は、Sun LDAP Schema 2 を使用する、ホストされたドメインのインストールでの LDAP ディレクトリ構造を示しています。

図 11–1 LDAP Schema 2 を使用する場合の LDAP ディレクトリの構造

この図は、1 つのツリー (組織ツリー) だけを使用し、DC ツリーのない純粋な Schema 2 環境の例を示しています。

LDAP Schema 2 ではフラットな LDAP ディレクトリ構造を使用します。つまり、ドメインはすべて同じレベルにあり、入れ子にはされません。ホストされたドメインのインストールでは、最初のレベルのエントリ (この図では varriusDomain、sestaDomain、および siroeDomain) がディレクトリ構造内で並列である必要があります。これらのエントリを入れ子にすることはできません。

シングルサインオン (SSO) などの Access Manager 機能を使用する場合、または Delegated Administrator を使用してユーザーをプロビジョニングする場合は、Schema 2 が必要です。ただし、複合型の形態として、DC ツリーと組織ツリーの両方を使用する 2 ツリースキーマも存在します。これは Schema 1 に似ていますが、Schema 2 のオブジェクトクラスと属性を使用します。これは、設定プログラム (csconfigurator.sh) では Schema 1.5 と呼ばれる Schema 2 互換モードです。

Sun LDAP Schema 1

次の図は、Sun LDAP Schema 1 を使用するホストされたドメインのインストールに対する LDAP ディレクトリ構造の例を示しています。

この構造には、ドメイン管理のための 2 つのツリーが含まれます。DC ツリーと組織ツリー (OSI) です。

DC ツリー
組織 (OSI) ツリー

図 11–2 LDAP Schema 1 を使用する場合の LDAP ディレクトリの構造

この図は、Schema 1、LDAP の 2 つのツリーからなる構造の例を示します。

DC ツリー (ノード) は、指定したドメイン名からドメインエントリを決定する DNS に似ています。LDAP 属性 inetdomainbasedn は、ベース DN をポイントします。ベース DN は、組織ツリー (ノード) 内のドメインのユーザー、リソース、およびグループのルートです。各ドメインでは、Calendar Server のユーザー、リソース、グループの ID は一意である必要があります。

注 –

以前の LDAP 設定に DC ツリーが含まれていなかった場合、Schema 1 モードまたは Schema 2 互換モードを使用するためには、「ホストされたドメイン環境の設定」の説明に従ってユーザー自身が DC ツリーノードを作成する必要があります。

LDAP Schema 1 を使用する、ホストされたドメインのインストールでは、ディレクトリ検索でエントリを特定するために次の 2 つの手順が必要です。

DC ツリーで検索を行い、組織ツリー内のドメインのベース DN (inetDomainBaseDN 属性) をポイントする DN 値を持つドメインエントリを特定します。
組織ツリーで検索を行ってドメインエントリを特定し、そのエントリのベース DN に基づいてドメイン内のユーザー、リソース、またはグループを特定します。

Calendar Server へのログイン

ホストされたドメインのインストールでは、各ユーザーはそのドメイン内で一意のユーザー ID (uid) を持つ必要があります。Calendar Server へのログインは、次の形式で行います。

userid[@domain-name]

domain-name を省略すると、ics.conf ファイルの service.defaultdomain パラメータに設定されているデフォルトドメイン名が適用されます。このため、ユーザーは userid を指定するだけでデフォルトドメインにログインできます。

ホストされていないドメイン環境でのインストールでは、domain-name は不要です。ドメイン名を指定しても無視されます。

自動プロビジョニングが有効になっている場合、ユーザーが最初にログインしたときに Calendar Server はそのユーザーのデフォルトカレンダを作成します。カレンダ作成については、第 15 章「カレンダの管理」を参照してください。

ログインの許可は、icsStatus 属性または icsAllowedServiceAccess 属性に基づいています。詳細は、「LDAP 属性とプロパティー名」を参照してください。

ドメイン間の検索

デフォルトでは、ユーザーが検索し、予定への出席を依頼できるユーザーやグループは、各自のドメイン内のユーザーとグループに限定されています。ドメイン間の検索機能を利用することで、あるドメインのユーザーがほかのドメインのユーザーやグループを検索することができます。ただし、次の要件を満たしている必要があります。

各ドメインは、ほかのドメインからのドメイン間検索を許可または拒否するアクセス制御リスト (ACL) を icsExtendedDomainPrefs 属性の domainAccess プロパティーに指定することができる。このためドメインは、そのドメイン内の検索を特定のドメイン、またはすべてのドメインを対象に許可または拒否することができる。

domainAccess については、「LDAP 属性とプロパティー名」を参照してください。ACL の一般的な説明については、「アクセス制御リスト (ACL)」を参照してください。
各ドメインは、そのドメインのユーザーが検索できる外部ドメインを指定できる。ユーザーやグループを探すためにユーザーが検索する外部ドメインは、LDAP 属性 icsDomainNames によって決定される (外部ドメインの ACL が検索を許可している場合)。

たとえば、various.org ドメインの icsDomainNames に sesta.com と siroe.com が含まれる場合、various.org のユーザーは sesta.com と siroe.com に対するドメイン間検索を実行できます。icsDomainNames については、「LDAP 属性とプロパティー名」を参照してください。

ドメイン間検索を有効にする方法については、「ドメイン間の検索の有効化」を参照してください。

ホストされていないドメイン環境のサポート

Calendar Server はホストされていないドメイン (つまり、シングルドメインを持つ) 環境での操作も引き続きサポートしています。たとえば、Calendar Server バージョン 5 以前の旧バージョンがインストールされている場合、ics.conf のパラメータ service.virtualdomain.support を "no" に設定すれば、シングルドメイン環境でも操作できます。「ホストされたドメインの有効化」も参照してください。

ただし、旧バージョンのコンポーネントデータベースを現在のバージョンに移行する必要があります。移行の詳細については、第 4 章「データベース移行ユーティリティー」を参照してください。

ホストされたドメイン環境の設定

ここでは、ホストされたドメインエントリを LDAP に新しく作成する前に実行しなければならない基本作業について説明します。

データベース移行ユーティリティーを実行します。

Calendar Server バージョン 5 から移行する場合、ホストされたドメインを設定する前に、cs5migrate、csmig、および csvdmig を実行済みであることを確認してください。Sun のテクニカルサポートから最新バージョンの cs5migrate を入手できます。これらの移行ユーティリティーについては、第 4 章「データベース移行ユーティリティー」を参照してください。
実行していない場合は、comm_dsseetup.pl を実行します。

これにより、ホストされたドメインのサポートに必要なパラメータで、ics.conf ファイルが更新されます。

ics.conf ファイルを編集して、ホストされたドメインを有効にします。

次の表に、ホストされたドメインのサポートに使用される ics.conf ファイルの設定パラメータの一覧とその説明を示します。この表に示すパラメータのいずれかが ics.conf ファイルに含まれていない場合は、パラメータとそのパラメータに関連する値をファイルに追加し、変更を適用するために Calendar Server を再起動します。

パラメータ	説明
`service.virtualdomain.support`	ホストされた (仮想) ドメインモードのサポートを有効化 (`"yes"`) または無効化 (`"no"`) します。デフォルトは `"no"` です。
`local.schemaversion`	LDAP スキーマのバージョンを指定します。 `"1"` = 「Sun LDAP Schema 1」。`service.dcroot` も参照してください。 `"2"` = 「Sun LDAP Schema 2」。`service.schema2root` も参照してください。デフォルトは `"1"` です。
`service.dcroot`	`local.schemaversion = 1` の場合に、LDAP ディレクトリの DC ツリーのルートサフィックスを指定します。例: `"o=internet"` ホストされた (仮想) ドメインモードでは、Calendar Server は `service.dcroot` パラメータを使用し、`local.ugldapbasedn` および `local.authldapbasedn` パラメータは使用されません。反対に、ホストされていない (仮想) ドメインモードでは、Calendar Server は `local.ugldapbasedn` および local.authldapbasedn パラメータを使用し、`service.dcroot` パラメータは使用されません。
`service.schema2root`	`local.schemaversion = 2` の場合に、下にすべてのドメインが属するルートサフィックスを指定します。例: `"o=sesta.com"`
`service.defaultdomain`	Calendar Server のこのインスタンスのデフォルトドメインを指定します。ログイン時にドメイン名が指定されない場合は、このドメイン名が適用されます。例: `"red.sesta.com"`
`service.loginseparator`	Calendar Server が `"userid[login-separator` `]domain"` をパースするときに `login-separator` で使用される区切り文字を指定します。Calendar Server は各区切り文字を順に使用します。デフォルトは `"@+"` です。
`service.siteadmin.userid`	ドメイン管理者のユーザー ID を指定します。例: `DomainAdmin@sesta.com`
`service.virtualdomain.scope`	ドメイン間検索を制御します。 `"primary"`: ユーザーがログインしているドメイン内だけの検索 `"select"`: 検索が許可されている任意のドメインでの検索デフォルトは `"select"` です。
`local.domain.language`	ドメインの言語を指定します。デフォルトは `"en"` (英語) です。

デフォルトドメインエントリを作成します。

Schema 2 では、デフォルトドメインは Delegated Administrator 設定プログラム (config-commda) によって作成されます。

Schema 1 では、DC ツリーの構造に応じて、デフォルトドメイン (ホストされたドメインのいずれか 1 つ) を DC ツリーのルートサフィックスより 1 つ以上下のレベルに作成します。たとえば、ルートサフィックスが o=internet である場合、「Sun LDAP Schema 1」に示すように、1 つ下のレベルのノードは com になります。ただし、デフォルトドメインは sesta.com など、さらに 1 ノード下になります。DC ツリーノードを作成する場合は、次の例に示すように、csdomain を実行します。
```
csdomain -n o=com,dc=com,o=internet create comcsdomain
    -n o=sesta.com,dc=sesta,dc=com,o=internet create sesta.com
```
デフォルトドメインエントリに対するカレンダサービスを有効にします。

Schema 1 の場合: csattribute を使用して、LDAP の o=sesta.com ドメインエントリに、icsCalendarDomain オブジェクトクラスを追加します。

Schema 2 の場合: Delegated Administrator の設定後、カレンダサービス (およびメールサービス) を追加するように、Delegated Administrator 設定プログラムで作成されたデフォルトドメインを変更します。次の例では、カレンダサービスとメールサービスがホストされたドメインに追加されます。

commadmin domain modify -D admin -w passwd -d defaultdomain -S cal,mail
ホストされたドメインをシステムに必要なだけ作成します。

Schema 2 モードでホストされたドメインを追加する方法については、「新規のホストされたドメインの作成」を参照してください。

Schema 1 のホストされたドメインを作成するには、次の例に示すように、csdomain create を使用します。
```
csdomain -n o=red.sesta.com,dc=red,dc=sesta,dc=com 
   create red.sesta.com
```
「ホストされたドメイン環境の設定」の説明に従って、ホストされた新規ドメインに対するカレンダサービスを有効にします。
calmaster サイト管理者ユーザーが存在しない場合、作成します。

Schema 2 では、次の例に示すように commadmin user create コマンドを使用して calmaster ユーザーを作成します。
```
commadmin user create -D admin -w passwd -F Calendar
    -L Administrator -l calmaster -W calmasterpasswd -d sesta.com -S cal
```
注 –
Delegated Administrator コンソールの「新規ユーザー」ウィザードを使用して calmaster を作成する方法については、Delegated Administrator オンラインヘルプを参照してください。

Schema 1 では、次の例に示すように、csuser を使用して calmaster ユーザーを組織ツリー上に作成します。
```
csuser o=sesta.com,o=rootsuffix -d sesta.com
    -g Calendar -s Administrator -ycalmasterpasswordcreate calmaster
```
以前のホストされていないドメイン環境 (Schema 1) に calmaster サイト管理者ユーザーがすでにある場合は、次の手順を実行して、その管理者ユーザーをデフォルトドメインに移動します。
1. 既存の calmaster LDAP エントリの LDAP ダンプを実行して、/tmp/calmaster.ldif などの一時ファイルに保存します。
2. 次のように、ldapdelete を使用して、組織ツリーのルートサフィックス上の既存の calmaster LDAP エントリを削除します。
```
#ldapdelete -D "cn=Directory Manager" -w password 
   uid=calmaster,ou=People,o=rootsuffix
```
3. 次の LDIF の例に示すように、カレンダ管理者のグループエントリを変更 (uniqueMember 属性を更新) して変更内容を反映させます。
  dn:cn=Calendar Administrators,ou=Groups,o=rootsuffix changetype:modifyreplace:uniqueMember uniqueMember:uid=calmaster,ou=People,o=sesta.com,o=rootsuffix
  グループエントリをホストされたドメインに移動する必要はありません。
WCAP コマンドの calid が完全修飾名で指定されるように、管理スクリプトを更新します。つまり、各 calid にドメイン名を含める必要があります。例: jsmith@sesta.com

Messaging Server を利用して作成したドメインの使用

Messaging Server が、ホストされたドメインをすでに作成している場合は、Schema 1 または Schema 2 のいずれかに対してカレンダを有効にすることができます。ここで説明する内容は次のとおりです。

Schema 1 メッセージングドメインでのカレンダ管理を有効にする

ドメインでカレンダ管理を有効にするには、カレンダを有効にする各ドメインに対して、次のオブジェクトクラスと 2 つの属性を LDAP ドメインエントリに追加します。

オブジェクトクラス: icsCalendarDomain。
属性: icsStatus。値を “active” に設定します。
属性: icsExtendedDomainPrefs。属性オプション domainAccess の値を、アクセス制御に使用する ACL に設定します。

これは 2 つの方法で行うことができます。csattribute add コマンドを使用するか、次の例に示すように ldapmodify を使用します。

dn:dc=sesta,dc=com,o=internet
 changetype:modify
 add:objectclass
 objectClass:icsCalendarDomain
 add:icsStatus
 icsStatus:active
 add:icsExtendedDomainPrefs
 icsExtendedDomainPrefs:domainAccess=@@d^a^slfrwd^g;anonymous^a^r^g;@^a^s^g

Schema 2 メッセージングドメインでのカレンダ管理を有効にする

commdirmig を使用して既存の Messaging Server LDAP エントリを Schema 2 にすでに移行しているか、Messaging Server LDAP エントリを Schema 2 モードで独自に作成した場合は、次の 2 つの手順でカレンダ管理を有効にします。

Delegated Administrator ユーティリティーの commadmin domain modify コマンドに -S オプションを指定して実行し、カレンダサービスを各ドメインに追加します。

または、Delegated Administrator コンソールを使用して、カレンダサービスを含むサービスパッケージを、影響を受けるドメインに割り当てます。これを行うには、「組織」一覧ページの「サービスパッケージを割り当て」ボタンを使用します。
Delegated Administrator ユーティリティーの commadmin user modify コマンドに -S オプションを指定して実行し、カレンダを有効にした各ドメインの各ユーザーにカレンダサービスを追加します。

または、Delegated Administrator コンソールを使用して、カレンダサービスを含むサービスパッケージを、影響を受けるドメインの各ユーザーに割り当てます。これを行うには、影響を受ける各組織で、「ユーザー」一覧ページの「サービスパッケージを割り当て」ボタンを使用します。

commadmin コマンドについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。

Delegated Administrator コンソールについては、コンソールのオンラインヘルプを参照してください。

commdirmig については、『Sun Java System Communications Services 6 2005Q4 Schema Migration Guide』を参照してください。

パート III Calendar Server の設定のカスタマイズ

第 5 章 Calendar Server のカスタマイズ

Communications Express の設定

プロキシ認証を設定するには

手順

参照

匿名アクセスを有効にするには

手順

カレンダの設定

ユーザーカレンダを設定するには

手順

リソースカレンダを設定するには

手順

ログイン時のユーザーカレンダの自動プロビジョニングを無効にするには

手順

空き/予定あり検索を設定するには

手順

カレンダユーザーの設定

ユーザーを設定するには

手順

ユーザー設定を設定するには

手順

Calendar Server の設定

サーバーの動作を設定するには

手順

カレンダのログを設定するには

手順

参照

WCAP コマンドを設定するには

手順

ログインと認証の設定

プロキシ管理者のログインを設定するには

手順

認証を設定するには

手順

認証キャッシュを設定するには

手順

ログイン時のクライアント IP アドレスの確認を有効にするには

手順

カレンダサービスの設定

管理サービス (csadmind) を設定するには

手順

HTTP サービス (cshttpd) を設定するには

手順

アラーム通知を設定するには

手順

Berkeley データベースのデッドロックの定期的チェックの設定

Berkeley データベースのデッドロックの定期的チェックを有効にするには

手順

注意事項

Calendar Server の LDAP の設定

LDAP への匿名アクセスを設定するには

手順

LDAP 出席者ルックアップを設定するには

手順

LDAP 出席者ルックアップの検索フィルタを設定するには

手順

LDAP リソースルックアップを設定するには

手順

LDAP mail-to-calid ルックアップを設定するには

手順

ユーザー設定 LDAP ディレクトリを使用するように Calendar Server を設定するには

手順

ユーザー設定を指定するには

手順

LDAP データキャッシュを有効にして設定するには

始める前に

手順

参照

LDAP SDK キャッシュを有効にして設定するには

手順

空き/予定あり検索の期間を設定するには

手順

カレンダプロパティーのワイルドカード LDAP 検索を有効にするには

手順

LDAP のルートサフィックスを設定するには

手順

第 6 章 複数のマシンへのカレンダデータベースの分散の設定

基礎的な情報

CLD プラグインの概要

第 6 章複数のマシンへのカレンダデータベースの分散の設定

第 7 章高可用性 (フェイルオーバーサービス) の設定

第 9 章シングルサインオンの設定