インストールとインストール後の設定が終わると、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 章「データベース移行ユーティリティー」を参照してください。
この章で説明する内容は次のとおりです。
設定に関する次の項目については、別の章で説明します。説明する内容は次のとおりです。
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” です。 |
"yes" に指定すると、ユーザーのデフォルトカレンダは公開読み取り/非公開書き込みに初期設定されます。"no" に指定すると、ユーザーのデフォルトカレンダは非公開読み取り/非公開書き込みに初期設定されます。デフォルトは “no” です。 |
|
user.allow.doublebook |
ユーザーカレンダの同じ時間帯に複数の予定をスケジューリングできるかどうかを指定します。
|
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
次の表に示すパラメータを 1 つ以上編集します。
ファイルを 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 ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを編集して、最初のログイン時のユーザーカレンダの自動プロビジョニングを無効にします。
パラメータ |
説明とデフォルト値 |
---|---|
get_freebusy の範囲指定の開始時刻に適用される、現在時刻からのオフセットを指定します。デフォルトは "30" です。 |
|
get_freebusy の範囲指定の終了時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは "30" です。 |
|
ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストに含めるかどうかを指定します。デフォルトは "yes" です。 |
|
ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストから削除できるかどうかを指定します。デフォルトは "no" です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
ここでは、カレンダユーザーの設定方法について説明します。 ここで説明する内容は次のとおりです。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示す 1 つ以上の ics.conf パラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
"yes" に設定すると、ユーザーによるパスワードの変更が許可されます。デフォルトは "no" です。 |
|
"yes" に設定すると、ユーザーは、書き込み可能な公開カレンダを所有できます。デフォルトは "yes" です。 |
|
ユーザーのデフォルトカレンダを、そのユーザーの登録済みカレンダリストから削除できるようにするかどうかを指定します。デフォルトは "no" です。 |
|
"yes" に設定すると、管理権限を持たないユーザーによるカレンダの作成が許可されます。デフォルトは "yes" です。 |
|
"yes" に設定すると、管理権限は持っていないが、そのカレンダに対する削除権を持っているユーザーによるカレンダの削除が許可されます。デフォルトは "yes" です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示す 1 つ以上の ics.conf パラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
"yes" に設定すると、set_userprefs によるユーザー設定の "cn" (LDAP ユーザーの共通名) の変更が許可されます。デフォルトは “no” です。 |
|
"yes" に設定すると、set_userprefs によるユーザー設定 "givenname" (LDAP ユーザーの名 (姓名の名)) の変更が許可されます。デフォルトは “no” です。 |
|
"yes" に設定すると、set_userprefs によるユーザー設定 "icsCalendar" (ユーザーのデフォルトカレンダ ID) の変更が許可されます。デフォルトは “no” です。 |
|
"yes" に設定すると、set_userprefs によるユーザー設定 mail (ユーザーの電子メールアドレス) の変更が許可されます。デフォルトは “no” です。 |
|
preferredlanguage |
"yes" に設定すると、set_userprefs によるユーザー設定 "preferredlanguage" (LDAP ユーザーの選択言語) の変更が許可されます。デフォルトは “no” です。 |
"yes" に設定すると、set_userprefs によるユーザー設定 "sn" (LDAP ユーザーの姓) の変更が許可されます。デフォルトは “no” です。 |
|
"yes" に設定すると、get_userprefs の LDAP プロキシ認証が有効になります。"no" に設定すると、匿名の LDAP 検索が行われます。デフォルトは “no” です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
ここでは、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” です。 |
"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 章「削除ログデータベースの管理」を参照してください。
設定を変更する権限を持つ管理者としてログインします。
/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 のバージョン。 |
ファイルを 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 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
LDAP 認証のベース DN。指定しない場合は local.ugldapbasedn の設定が適用されます。指定しない場合、サーバーは local.ugldaphost の値を使用します。 |
|
LDAP 認証用のホスト。指定しない場合は local.ugldaphost の値が使用されます。デフォルトは "localhost" です。 |
|
local.authldapbinddn で指定された、ユーザーのバインドに必要な資格情報 (パスワード)。 |
|
ユーザー DN の検索時に LDAP 認証ホストへのバインドに使用される DN。指定しない場合または空白 (" ") の場合は、匿名バインドと見なされます。 |
|
LDAP 認証用のポート。指定しない場合は local.ugldapport の値が使用されます。デフォルトは "389" です。 |
|
LDAP 認証用に維持される LDAP クライアント接続の最小数。指定しない場合は local.ugldappoolsize の値が使用されます。デフォルトは "1" です。 |
|
LDAP 認証用に維持される LDAP クライアント接続の最大数。指定しない場合は local.ugldapmaxpool の値が使用されます。デフォルトは "1024" です。 |
|
ユーザー検索に使用される認証フィルタを指定します。デフォルトは "(uid=%U)" です。 この値は、ドメインエントリの inetDomainSearchFilter 属性に格納されます。 別の属性でフィルタすることもできます。たとえば、このパラメータを "(mail=%U)" に設定することもできます。 認証に使用される属性に関係なく、認証されたユーザーの uid がそのユーザーの ID としてほかのすべての関数に渡されます。 |
|
プレーンテキスト形式のパスワードによるユーザーの認証に成功したあとの遅延時間 (秒単位)。デフォルトは "0" です。 |
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを 1 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
Calendar Server がキャッシュに保持する、認証されたユーザーの ID (uid) およびパスワードの最大数。デフォルトは “10000” です。 |
|
最後のアクセスから uid とパスワードがキャッシュから削除されるまでの秒数。デフォルトは “900” です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/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) の設定」も参照してください。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを 1 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
"yes" に設定すると、csadmind データベースチェックポイントスレッドが開始されます。“no” に設定すると、チェックポイントログファイルは作成されません。デフォルトは “yes” です。 |
|
管理セッション用の Berkeley データベースの最大キャッシュサイズ (バイト単位)。デフォルトは “8388608” です。 |
|
"yes" に設定すると、csadmind データベースデッドロック検出スレッドが開始されます。デフォルトは “yes” です。 |
|
"yes" に設定すると、csadmind ディスク容量低下監視スレッドが開始されます。デフォルトは “no” です。デフォルトでは、ディスク使用率は監視されません。 |
|
"yes" に設定すると、すべてのサービスを開始するときに csadmind サービスを開始し、すべてのサービスを終了するときに csadmind サービスを終了します。デフォルトは “yes” です。 |
|
csadmind で HTTP 接続をタイムアウトにするまでの秒数。デフォルトは “120” です。 |
|
許容される管理セッションの最大数。デフォルトは “100” です。 |
|
1 管理セッションで実行されるスレッドの最大数。デフォルトは “10” です。 |
|
同時に実行可能な管理プロセスの最大数。 |
|
デフォルトはなしです。このパラメータはシステムによって設定されます。 注意 – このパラメータはユーザー自身では設定しないでください。システムによって自動的に設定されます。Calendar Server でリモート管理を行うことはできません。このポート番号を変更すると、csadmind が起動しない可能性があります。 |
|
管理接続をタイムアウトにするまでの秒数。デフォルトは “900” です。 |
|
"yes" に設定すると、csadmind サービス応答スレッドが開始されます。デフォルトは “no” です。 |
|
管理セッション要求用の一時ディレクトリ。デフォルトはなしです。 |
|
csadmind で HTTP セッションをタイムアウトにするまで待機する秒数。デフォルトは “1800” です。 |
|
カレンダサービスの状態 (稼動、終了、待機) を調べる間隔 (秒単位)。デフォルトは “2” です。 |
|
カレンダサービスが開始するまで待機する秒数。デフォルトは “300” です。 |
|
カレンダサービスが終了するまで待機する秒数。デフォルトは “300” です。 |
|
カレンダサービスに終了コマンドを送信するまで待機する秒数。デフォルトは “60” です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを 1 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
この Calendar Server の管理権限を持つユーザー ID を空白文字で区切って指定します。デフォルトは “calmaster” です。 |
|
"yes" に設定すると、プロキシ経由のログインが許可されます。デフォルトは “no” です。 |
|
"yes" に設定すると、匿名アクセス (認証なし) が許可されます。これは特殊なタイプのログインであり、指定した制限付きのアクセス (通常は公開カレンダへの読み取り専用アクセス) のみが許可されます。デフォルトは “yes” です。 |
|
HTML ドキュメントを取得するための HTTP ホスト。ユーザーが完全修飾ホスト名を指定してカレンダデータにアクセスできるようにするには、mycal@sesta.com のように、Calendar Server が稼動するマシンの完全修飾ホスト名 (マシン名、DNS ドメインとサフィックスを含む) をこの値に指定する必要があります。 指定しない場合、ローカル HTTP ホストが適用されます。 |
|
cookie をサポートするかどうかをサーバーに指示します ("yes" または "no")。シングルサインオンを有効にするには、"yes" に設定する必要があります。デフォルトは “yes” です。 |
|
HTTP セッション用の Berkeley データベースの最大キャッシュサイズ。デフォルトは “8388308” です。 |
|
" " 以外の値を指定した場合は、TCP ドメインに基づくフィルタリングによってアクセスが許可されます。たとえば、「ALL: LOCAL.sesta.com」と指定した場合は、sesta.com ドメインのすべてのユーザーによるローカル HTTP アクセスが許可されます。複数のフィルタを指定する場合は、CR-LF (改行) で区切ります。デフォルトは "" です。 |
|
空白 (" ") 以外の値を指定した場合は、TCP ドメインに基づくフィルタリングによってアクセスが拒否されます。たとえば、「ALL: LOCAL.sesta.com」と指定した場合は、sesta.com ドメインのすべてのユーザーによる HTTP アクセスが拒否されます。複数のフィルタを指定する場合は、CR-LF (改行) で区切ります。デフォルトは " " (空白) です。 |
|
インポートされたファイルが一時的に格納されるディレクトリのlocal.queuedir への相対パス (指定する場合は絶対パス)。デフォルトは現在のディレクトリ (".") です。 |
|
"yes" に指定すると、既存のセッションを参照するすべての要求は、同じ IP アドレスから発せられているものとして検証されます。デフォルトは “yes” です。 |
|
"yes" に設定すると、すべてのサービスを開始するときに cshttpd サービスを開始し、すべてのサービスを終了するときに cshttpd サービスを終了します。デフォルトは “yes” です。 注意 – このパラメータで HTTP サービスを無効にすると HTTPS も無効になります。 |
|
HTTP 接続をタイムアウトにするまでの秒数。デフォルトは “120” です。 |
|
HTTP サービスがクライアント要求を待機する TCP アドレスを指定します。デフォルトは、任意のアドレスを示す "INADDR_ANY" です。 |
|
"yes" に指定すると、サーバーへの HTTP 接続が完全にログに記録されます。デフォルトは “no” です。 |
|
cshttpd サービスでの HTTP セッションの最大数。デフォルトは “5000” です。 |
|
cshttpd サービスでの HTTP 要求を処理するスレッドの最大数。デフォルトは “20” です。 |
|
サーバーでの実行が必要な HTTP サービス (cshttpd) プロセスの最大並行実行数。デフォルトは “1” です。 複数の CPU を持つサーバーについては、「複数 CPU 間でのロードバランスの使用」を参照してください。 |
|
Calendar Server ユーザーからの HTTP 要求用のポート。デフォルトは “80” です。 |
|
"" 以外を指定した場合は、TCP ドメインに基づくプロキシログインがフィルタリングによって許可されます。構文は service.http.domainallowed と同じです。デフォルトは "" です。 |
|
HTTP セッションをタイムアウトにするまでの秒数。デフォルトは “900” です。 |
|
HTTP セッションデータベース用のディレクトリ。デフォルトは “http” です。 |
|
cshttpd サービスで HTTP セッションをタイムアウトにするまでの秒数。デフォルトは “1800” です。 |
|
実行可能ファイルへのすべての URL 参照が格納されるディレクトリの、実行可能ファイルに対する相対パス。デフォルトは "" (NULL) です。 |
|
service.http.tmpdir |
HTTP セッション用の一時ディレクトリ。デフォルトは “/var/opt/SUNWics5/tmp” です。 |
デフォルトのカレンダクライアントが格納されるディレクトリ。WCAP アクセスのみを許可する場合は、"html" に設定します。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示す 1 つ以上の ics.conf パラメータを編集します。
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
Berkeley データベースのデッドロックを定期的にチェックするように Calendar Server を設定できます。
Berkeley データベースはデッドロック状態になる可能性があるため、それらのデータベースにアクセスしないようにします。この状態をできるだけ早く見つけるには、デッドロックの定期的チェックを有効にします。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
Berkeley データベースがデッドロック状態にあるかどうかを定期的に調べます。 デッドロック状態にある場合は、データベースのリセットを指示します。デフォルト値は “no” (無効) です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
デッドロックしたときの Berkeley データベースのリセット方法については、トラブルシューティングの章、「データベースの破損の検出」、「使用可能なツールの一覧」を参照してください。
通常、匿名アクセスはデフォルトで許可されています。匿名アクセスを制限する場合は、該当するパラメータを変更します。
設定を変更する権限を持つ管理者としてログインします。
/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
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表のパラメータを 1 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
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 です。 |
電子メールアドレスに対応する出席者のカレンダ ID の検索で使用されるデフォルトドメインの名前。たとえば、この値が "sesta.com" に設定されている場合、jsmith は jsmith@sesta.com として解決されます。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表のパラメータを 1 つ以上編集します。
次に示すすべてのパラメータ説明で、%s には出席者を 1 人だけ指定できます。
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
local.lookupldap.resource.use.ugldap |
リソースルックアップにユーザー/グループ LDAP サーバーを使用するか、検索用サーバーを使用するか。 “yes”: ユーザー/グループ LDAP サーバーを使用します。 “no”: 検索用サーバーを使用します。デフォルトは “no” です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
これらのパラメータは、ホストされていないドメイン環境でのみ使用します。ホストされたドメイン環境を導入した場合は、 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
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表のパラメータを 1 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
LDAP ユーザー設定認証用のバインド資格情報 (パスワード)。デフォルトはなしです。 |
|
LDAP ユーザー設定ホストへのバインドに使用される DN。このプロパティーの指定は必須。空白 (" ") または指定しない場合は、匿名バインドと見なされます。 |
|
LDAP ユーザー設定用に維持される LDAP クライアント接続の最小数。デフォルトは “1” です。 |
|
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 ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータ内のユーザー設定のリストを編集します。
パラメータ |
ユーザー設定のデフォルトリスト |
説明 |
---|---|---|
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 データキャッシュオプション」を参照してください。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを編集して、LDAP データキャッシュを有効にします。
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
LDAP データキャッシュの調整方法については、「LDAP データキャッシュのパフォーマンスの向上」を参照してください。
Calendar Server、または Calendar Server が動作しているサーバーが正しくシャットダウンされない場合は、データベースの破損と、それに伴ってその後の再起動時に発生する可能性のある問題を避けるために、ldap_cache ディレクトリ内のすべてのファイルを手動で削除してください。
LDAP SDK キャッシュは、デフォルトで無効になっています。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータを 1 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
"yes" に設定すると、LDAP SDK キャッシュが有効になります。デフォルトは “no” です。 |
|
service.ldapmemcache に "yes" を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。“0” を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは “30” です。 |
|
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 つ以上編集します。
パラメータ |
説明とデフォルト値 |
---|---|
get_freebusy の範囲指定の開始時刻に適用される、現在時刻からのオフセットを指定します。デフォルトは “30” です。 |
|
get_freebusy の範囲指定の終了時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは “30” です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すようにパラメータを編集します。
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
LDAP 組織ツリー (Schema 2) またはドメインコンポーネントツリー (Schema 1) のルートサフィックスをリセットすることは可能ですが、この作業は十分に注意して行う必要があります。これを行う場合は、設定プログラムを再実行することをお勧めします。
設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すパラメータのうちの 1 つを編集します。
パラメータ |
説明とデフォルト値 |
---|---|
ディレクトリ内の DC ツリーのルートサフィックス。Schema 1 によるホストされた (仮想) ドメインモードのサポートに必要です。 デフォルトは "o=internet" です。 「ホストされたドメイン環境の設定」も参照してください。 |
|
service.schema2root |
Schema 2 用の DIT (組織ツリー) のルートサフィックス。 デフォルト値はありません。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
この章では、カレンダデータベースを複数のバックエンドサーバーに分散させることを可能にするカレンダ検索データベース (CLD) プラグインの使用方法について説明します。CLD プラグインの有効化と設定の両方を行う必要があります。
フロントエンドとバックエンドのマシン間で機能を分けている Calendar Server のインストールでは、それぞれのハードウェアプラットフォームを同じにする必要があります。
つまり、ビッグエンディアンとスモールエンディアンとの間に互換性がないため、フロントエンドとバックエンドのマシンを含む 同じ Calendar Server で、x86 プラットフォームマシンと SPARC プラットフォームマシンの両方を使用することはできません。
この章で説明する内容は次のとおりです。
CLD プラグインのパフォーマンスを向上させる方法については、第 21 章「Calendar Server のパフォーマンスの調整」を参照してください。
この節では、CLD プラグインを実際に有効化および設定する前に理解しておく必要がある、概要および基礎的な情報を提供します。ここで説明する内容は次のとおりです。
カレンダ検索データベース (CLD) プラグインは単一カレンダインスタンス用の多数のバックエンドサーバーにユーザーカレンダとリソースカレンダを分散することによって、カレンダデータベースの水平方向のスケーラビリティーを提供します。複数のバックエンドサーバーにカレンダデータベースを配布している場合、Calendar Server は CLD プラグインを使用してカレンダが実際に格納されているサーバーを特定します。
Calendar Server は、DWP (データベースワイヤプロトコル) を使用してバックエンドサーバー上のカレンダデータにアクセスします。DWP は csdwpd サービスとして実行される内部プロトコルで、カレンダデータベースのネットワーク機能を提供します。
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 プラグインは、次の 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–2 は、フロントエンドサーバーとバックエンドサーバーの両方の機能を持つ 3 つのマシンを示しています。各マシンは、1 台のカレンダデータベースに接続されています。この構成では、カレンダを物理的に分散することができます。カレンダの所有者 (エンドユーザー) は、所有しているカレンダが格納されているマシンにログインします。構成の詳細については、「フロントエンドサーバーとバックエンドサーバーを同じマシンに設定するには」を参照してください。
次に、メディア使用状況プロファイルに基づいて、必要なバックエンドサーバー数とフロントエンドサーバー数、およびストレージの容量を算出するための簡単な数式を示します。
ここでは大まかに、次のような状況を想定します。
すべてのクライアントは Web クライアントである。
したがって、入力として使用されるのは、ユーザー総数と同時並行の割合のみです。
平均的なサイズのカレンダの予定のサイズは 2K である。
各ユーザーが、1 週間につき 5 つの予定または仕事を作成する。
CPU 利用率は 80%。
900 MHz の CPU
各 CPU に 1G バイトの RAM を搭載
2 年分のカレンダデータがシステムに保存されている。
数式は次のとおりです。
CPU 数 = 並行ユーザー数 / 4800
数式は次のとおりです。
CPU 数 = 設定済みの 500,000 ユーザーにつき 4 CPU
数式は次のとおりです。
ストレージの容量 = 電子メール 5 件 / 週 × 52 週 / 年 × 2K / メール (5*52*2K)
= 520K バイト / ユーザー / 年
カレンダデータ約 2 年分で、1 M バイト / ユーザー
ここでは、サーバーの設定方法について説明します。 ここで説明する内容は次のとおりです。
すべてのフロントエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すように、ics.conf パラメータを編集します。
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
すべてのバックエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すように、ics.conf パラメータを編集します。
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
すべてのサーバーで、設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
次の表に示すように、ics.conf パラメータを編集します。
ファイルを 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 とパスワードを使用できます。
バックエンドサーバーがパスワードを指定しない場合、認証は行われません。
次のパラメータは、ics.conf ファイルのインストール済みバージョンには含まれません。DWP 接続の認証を行う場合は、各フロントエンドサーバーの ics.conf ファイルに必要なパラメータを追加する必要があります。
すべてのフロントエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
ics.conf パラメータを、次の表に示すように追加します。
パラメータ |
説明 |
フロントエンドサーバーで、バックエンドサーバーとの DWP 接続の認証に使用される管理者のユーザー ID を指定します。back-end-server はサーバー名です。 |
|
フロントエンドサーバーで、バックエンドサーバーとの DWP 接続の認証に使用されるパスワードを指定します。back-end-server はサーバー名です。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
次のパラメータは、ics.conf ファイルのインストール済みバージョンには含まれません。DWP 接続の認証を行う場合は、各バックエンドサーバーの ics.conf ファイルに必要なパラメータを追加する必要があります。
すべてのバックエンドサーバーで、設定を変更する権限を持つ管理者としてログインします。
/etc/opt/SUNWics5/cal/config ディレクトリに移動します。
古い ics.conf ファイルをコピーして名前を変更し、保存します。
ics.conf パラメータを、次の表に示すように追加します。
パラメータ |
説明 |
バックエンドサーバーで、DWP 接続の認証に使用するユーザー ID を指定します。バックエンドサーバーがユーザー ID を指定しない場合、認証は行われません。 |
|
バックエンドサーバーで、DWP 接続の認証に使用するパスワードを指定します。バックエンドサーバーがパスワードを指定しない場合、認証は行われません。 |
ファイルを ics.conf として保存します。
Calendar Server を再起動します。
cal_svr_base /SUNWics5/cal/sbin/start-cal
Calendar Server の高可用性 (HA) 設定により、ソフトウェアとハードウェアの障害を監視し、回復処理を行うことができます。Calendar Server の高可用性機能は、フェイルオーバーサービスとして実装されます。この章では、Sun Cluster ソフトウェアによる Calendar Server HA の設定について説明します。
この章では、Calendar Server HA サービスのインストールと設定の方法について、次の項目で説明します。
付録 C 「高可用性 (HA) 設定のワークシート」 には、Calendar Server の高可用性設定の計画に役立つワークシートが用意されています。
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 設定をインストールおよび設定するには、スーパーユーザー (root) としてログインするか、スーパーユーザーになり、/dev/console に送信されるメッセージを表示するコンソールまたはウィンドウを指定します。
クラスタ内の各ノードで次の手順を実行します。
次の方法で、Calendar Server を実行する Calendar Server ランタイムユーザーおよびグループを作成します。
/etc/group ファイルに icsgroup (または選択した値) を追加します。
/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 製品 (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 には、選択されているすべての製品とパッケージを Java Enterprise System インストーラを使用してインストールします。Calendar Server をインストールするときは、デフォルトディレクトリ以外のディレクトリを指定する必要があります。「Calendar Server のインストールディレクトリの選択」を参照してください。
ノード 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 のインストールでは、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 設定オプション
HA 用の自動バックアップを設定するときは、クラスタの個々のノードで不完全なコピーが作成されないように、バックアップディレクトリを共有ストレージパーティションに配置する必要があります。バックアップディレクトリは容量が大きいため、パーティションのサイズに特に注意してください。
シンボリックリンクに対しては、ディスク容量の計算がうまく行われません。このため、自動バックアップディレクトリにはシンボリックリンクを使用しないでください。
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/
/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 . |
/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/ |
/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 パッケージのアンインストール処理は失敗します。
/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 を起動する前に、次のようにカレンダリソースのタイプを 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 |
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 サービスを起動、停止するときは、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』を参照してください。
『Sun Cluster Concepts Guide for Solaris OS』は、Sun Cluster ソフトウェアとデータサービスに関する一般的な背景情報を提供し、リソースタイプ、リソース、リソースグループの用語について解説します。
『Sun Cluster Data Services Planning and Administration Guide for Solaris OS』は、データサービスの計画と管理に関する一般的な情報を提供します。
『Sun Cluster System Administration Guide for Solaris OS』は、Sun Cluster の設定をソフトウェアで管理する手順について解説します。
『Sun Cluster Reference Manual for Solaris OS』は、SUNWscman および SUNWccon パッケージだけで利用できるコマンドも含め、Sun Cluster ソフトウェアで利用できるコマンドとユーティリティーについて解説します。
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 を実装するには、証明書データベースが必要です。証明書データベースには、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 {}; |
次の手順で、証明書要求の生成、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
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 が機能するには、Calendar Server の cshttpd プロセスが稼動している必要があります。cshttpd が稼動しているかどうかを確認するには、次のコマンドを実行します。
# ps -ef | grep cshttpd
証明書データベースに格納されている証明書の一覧を表示し、その有効期限を確認するには、次のコマンドを実行します。
# ./certutil -L -d /var/opt/SUNWics5/alias
SSL エラーについて、Calendar Server ログファイルを確認します。詳細は、「Calendar Server ログファイルの使用」を参照してください。
ブラウザに次の URL を指定し、SSL ポートに接続します。
https://server-name:ssl-port-number
それぞれの意味は次のとおりです。
server-name は Calendar Server が稼動しているサーバーの名前です。
ssl-port-number は、ics.conf ファイルの service.http.ssl.port パラメータに指定されている SSL ポート番号です。デフォルトは 443 です。
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" に設定する必要があります。
この章では、シングルサインオン (SSO) の設定方法について説明します。
シングルサインオン (SSO) を利用することで、ユーザーは認証を一度受けるだけで、信頼できる複数のアプリケーションを追加認証なしで使用できます。Calendar Server と Messaging Server を含め、Sun Java System コミュニケーションサーバーは次の方法で 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 が適切に設定されていれば、それらのサーバーにもアクセスできます。
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 サーバーにもアクセスできます。
カレンダセッションが有効なのは、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 サーバーの信頼できるサークルテクノロジを利用して (つまり 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 設定パラメータ
次の表は、Communications サーバーの信頼できるサークルテクノロジによって SSO を設定する場合の Messaging Server 設定パラメータを示しています。
表 9–2 Communications サーバーの信頼できるサークルテクノロジを利用して SSO を設定する場合の Messaging Server 設定パラメータ
Messaging Server で SSO を設定する方法については、『Sun Java System Messaging Server 6 2005Q4 Administration Guide』を参照してください。
設定時に、自動バックアップを有効にすることができます。ただし、自動バックアップは設定後にいつでも有効または無効にすることができます。データを保護し、運用停止時間を最小限に抑えるためには、すぐれたバックアップシステムの導入が不可欠です。
この章では、自動バックアップが実行されるように Calendar Server サービス csstored を設定する方法について説明します。この章で説明する内容は次のとおりです。
ここで説明する自動バックアッププロセスを使用しない場合は、独自のバックアップ計画を導入してデータを保護する必要があります。データを保護するためのほかの Calendar Server ツールの使用方法については、第 17 章「Calendar Server データのバックアップと復元」を参照してください。
csstored の概要については、次の Web サイトで入手できる『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』を参照してください。
ここで説明する内容は次のとおりです。
Calendar Server システムでは、カレンダデータベースの各トランザクション (カレンダやそのプロパティーへの追加、変更、または削除) をトランザクションログファイルに記録します。あらかじめ決められた間隔で、このログファイルは書き込みのために閉じて、別のログファイルが作成されます。次に、システムでは、時間があるときに、もっとも古い閉じたトランザクションログのトランザクションを実際のカレンダデータベースに適用します。ログに含まれているすべてのトランザクションがデータベースに適用されると、そのログには「適用済み」というマークが付けられます。
ホットバックアップが設定されている場合、実際のデータベースのスナップショットが 24 時間ごとに取得されます。適用済みのログは、その後、データベースのホットバックアップのコピーに適用されます。ホットバックアップデータベースは、まだ適用されていないトランザクションを除いては最新の状態です。
起動時に開始される 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 の実行を無効にする必要があります。
設定を変更する権限を持つ管理者としてログインします。
/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 を無効にしないでください。
Calendar Server はホストされた (または仮想) ドメインをサポートしています。ホストされたドメインのインストールでは、各ドメインが Calendar Server の同じインスタンスを共有するため、1 つのサーバーに複数のドメインが存在できます。各ドメインはネームスペースを定義し、1 つのネームスペースではすべてのユーザー、グループ、リソースが一意です。各ドメインには、変更可能な属性とユーザー設定もあります。
この章で説明する内容は次のとおりです。
『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』では、ホストされたドメインを使用するためのインストール準備に必要なすべての手順を説明しています。
現在のサイトに複数の Calendar Server インスタンスが設定されていたり、限定的な仮想ドメインモードが設定されている場合は、移行要件の評価について購入先の顧客サービスの担当者に問い合わせてください。
ここでは、ホストされたドメインの概要について、次の項目を説明します。
ホストされたドメインのインストールでは、LDAP ディレクトリは完全に区別され、部分的な交差もありません。 それぞれの LDAP ディレクトリが DNS (ドメイン名システム) 内のドメインを表します。ユーザー、グループおよびリソースの uid は各ドメイン内で一意です。たとえば、uid が jdoe のユーザーは各ドメインで 1 人だけです。識別名 (DN) は、各ドメインのルートを表します。
Calendar Server は、ホストされたドメインで次の両方の LDAP ディレクトリスキーマバージョンをサポートしています。
「Sun LDAP Schema 2」 (互換モードまたはネイティブモード)
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 を使用する、ホストされたドメインのインストールでの LDAP ディレクトリ構造を示しています。
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 を使用するホストされたドメインのインストールに対する LDAP ディレクトリ構造の例を示しています。
この構造には、ドメイン管理のための 2 つのツリーが含まれます。DC ツリーと組織ツリー (OSI) です。
DC ツリー
組織 (OSI) ツリー
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 に基づいてドメイン内のユーザー、リソース、またはグループを特定します。
ホストされたドメインのインストールでは、各ユーザーはそのドメイン内で一意のユーザー 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 を再起動します。
パラメータ |
説明 |
---|---|
ホストされた (仮想) ドメインモードのサポートを有効化 ("yes") または無効化 ("no") します。デフォルトは "no" です。 |
|
LDAP スキーマのバージョンを指定します。
|
|
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 パラメータは使用されません。 |
local.schemaversion = 2 の場合に、下にすべてのドメインが属するルートサフィックスを指定します。 例: "o=sesta.com" |
|
Calendar Server のこのインスタンスのデフォルトドメインを指定します。ログイン時にドメイン名が指定されない場合は、このドメイン名が適用されます。 例: "red.sesta.com" |
|
Calendar Server が "userid[login-separator ]domain" をパースするときに login-separator で使用される区切り文字を指定します。Calendar Server は各区切り文字を順に使用します。 デフォルトは "@+" です。 |
|
ドメイン管理者のユーザー ID を指定します。 例: DomainAdmin@sesta.com |
|
ドメイン間検索を制御します。
|
|
ドメインの言語を指定します。デフォルトは "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 サイト管理者ユーザーがすでにある場合は、次の手順を実行して、その管理者ユーザーをデフォルトドメインに移動します。
既存の calmaster LDAP エントリの LDAP ダンプを実行して、/tmp/calmaster.ldif などの一時ファイルに保存します。
次のように、ldapdelete を使用して、組織ツリーのルートサフィックス上の既存の calmaster LDAP エントリを削除します。
#ldapdelete -D "cn=Directory Manager" -w password uid=calmaster,ou=People,o=rootsuffix
次の 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 が、ホストされたドメインをすでに作成している場合は、Schema 1 または Schema 2 のいずれかに対してカレンダを有効にすることができます。 ここで説明する内容は次のとおりです。
ドメインでカレンダ管理を有効にするには、カレンダを有効にする各ドメインに対して、次のオブジェクトクラスと 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 |
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』を参照してください。