test

Sun Java System Calendar Server 6.3 管理ガイド

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

設定ファイル ics.conf を編集することで設定可能なさまざまな機能について説明します。

次の章で構成されています。

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

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

注 –

ics.conf ファイルでは、パラメータの重複が認められています。システムはファイル内のパラメータの最後のインスタンスの値を使用します。

ベストプラクティス:混乱を避けるには、ファイルの最後にカスタマイズ用のセクションを作成し、そこにカスタマイズを追加します。たとえば、! My ics.conf Changes というテキストで始まるコマンド行を作成します。その後、新しいパラメータや変更しているパラメータとそれらの値を追加します。変更を行なった理由を記したコメントをパラメータごとに追加し、現在の日付を追加します。こうすれば、あとでシステムに対して行なった変更の履歴がわかります。

処理効率を高めるために大幅なカスタマイズを行う場合は、変更前の元のパラメータをコメントアウトすることもできます。また、ファイルを定期的に見直して、使用されていない重複したパラメータをコメントアウトします。

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

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

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

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

注 –

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

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

4.1 Communications Express の設定

ここでは、Communications Express を設定する設定ファイルの 2 つのパラメータについて説明します。

Communications Express を使用するには次の設定を行なっておく必要があります。

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

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

  2. stop-cal を実行して Calendar Server サービスを停止します。

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

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

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

    service.http.allowadminproxy

    "yes" に設定すると、管理者のプロキシ認証が有効になります。デフォルトは "yes" です。

    service.http.admins

    Calendar Server の管理権限を持つユーザー ID をリスト表示します。デフォルトは “calmaster” です。複数の値を指定する場合は、各値を空白文字で区切ります。値の 1 つは、uwconfig.properties ファイルの calendar.wcap.adminid に指定されている値である必要があります。

    service.siteadmin.userid

    calmaster のユーザー ID。これは、uwcconfig.properties ファイルの calendar.wcap.adminid パラメータに指定されているユーザー ID と同じになります。

    service.siteadmin.cred

    calmaster のパスワード。これは、uwcconfig.properties ファイルの calendar.wcap.passwd パラメータに指定されているユーザー ID と同じになります。

    注 –

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

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

  7. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

参照

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

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

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

  2. stop-cal を実行して Calendar Server サービスを停止します。

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

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

  5. 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 環境 (データベースが複数のバックエンドに分散されている環境) で最良のパフォーマンスを得るためのシステム調整の指示とは矛盾しています。「21.2 DWP 環境でのカレンダ検索のパフォーマンス向上」を参照してください。

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

  7. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

    Communications Express の設定手順については、『Sun Java System Communications Express 6.3 管理ガイド』を参照してください。

4.2 カレンダの設定

ここでは、次の内容について説明します。

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

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

  2. stop-cal を実行して Calendar Server サービスを停止します。

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

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

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

    calstore.calendar.default.acl

    ユーザーがカレンダを作成したときに使用されるデフォルトのアクセス制御設定を指定します。形式は、ACE (アクセス制御エントリ) 引数をセミコロンで区切ったリスト形式の文字列です。デフォルトは次のとおりです。

    "@@o^a^r^g;@@o^c^wdeic^g;
@^a^fs^g;@^c^^g;@^p^r^g"

    ACE 形式については、「15.4 カレンダのアクセス制御」を参照してください。Calendar Server ユーティリティーについては、「D.5 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 に設定された noredirect パラメータを渡します。

    calstore.subscribed.include. defaultcalendar

    ユーザーのデフォルトカレンダを、そのユーザーの登録済みカレンダリストに含めるかどうかを指定します。デフォルトは “yes” です。

    service.wcap.login.calendar.publicread

    "yes" に指定すると、ユーザーのデフォルトカレンダは公開読み取り/非公開書き込みに初期設定されます。"no" を指定すると、ユーザーのデフォルトカレンダは非公開読み取り/非公開書き込みに初期設定されます。デフォルトは “no” です。

    user.allow.doublebook

    ユーザーカレンダの同じ時間帯に複数の予定をスケジューリングできるかどうかを指定します。

    • "no": 複数のユーザーからの予約は拒否されます。

    • "yes": 複数のユーザーからの予約は許可されます (デフォルト)。

      このパラメータは、ユーザーカレンダの作成時にのみ使用されます。作成後は、Calendar Server はカレンダプロパティーファイル (ics50calprops.db) を参照して複数のユーザーからの予約の可否を決定します。

      複数のユーザーからの予約のカレンダプロパティーの値を変更するには、-k オプションを指定して cscal を実行します。

    user.invite.autoprovision

    ユーザーが出席依頼を受信したがデフォルトカレンダがない場合に、ユーザーカレンダを自動作成するかどうかを指定します。このオプションはデフォルトで有効になっています ("yes")。

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

  7. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

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

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

  2. stop-cal を実行して Calendar Server サービスを停止します。

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

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

  5. 次の表に示すパラメータを 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.invite.autoaccept

    出席依頼がリソースに送信されたときに自動的に受諾とマークを付けるかどうかを指定します。デフォルトは "yes" です。

    resource.invite.autoprovision

    リソースに対し予定への出席依頼がなされたときに既存のカレンダがない場合、自動プロビジョニングを行うかどうかを指定します。

    デフォルトは "yes" です。

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

  7. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

Procedureグループカレンダを設定するには

グループカレンダは、ユーザーカレンダに類似した予定を使用してスケジュールできます。ただし、ユーザーはグループカレンダにログインできません。ユーザーがグループカレンダを閲覧するには、そのカレンダに登録しておく必要があります。グループカレンダを設定するには、次の手順に従って、ics.conf ファイルを編集します。

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

  2. stop-cal を実行して Calendar Server サービスを停止します。

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

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

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

    group.allow.doublebook

    グループカレンダが複数のユーザーから予約できるかどうかを指定します。デフォルトは yes です。

    group.default.acl

    グループカレンダのデフォルト ACL を指定します。

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

    group.invite.autoprovision

    自動プロビジョニングを有効にするか無効にするかを指定します。デフォルトは "yes" (有効) です。

    group.invite.autoaccept

    グループの出席依頼に自動的に PARTSTAT=ACCEPTED を与えるかどうかを指定します。

    group.invite.expand

    出席依頼に応じてグループを拡張するかどうかを指定します。

    "yes" の場合、calstore.group.attendee.maxsize パラメータの制約を満たすとリストが拡張されます。拡張に失敗したり、このパラメータが "no" に設定されている場合は、出席者リストにはグループ名だけが表示され、RSVP は要求されません。

    calstore.group.attendee.maxsize

    グループを拡張できるかどうかを指定します。"0" の値は拡張限度がないことを示します。どのサイズのグループも拡張できます。

    拡張は可能ですが、無制限ではありません。パラメータの値は、拡張したグループ内で許容できる出席者の最大数を示します。グループ内の出席者数が最大サイズを超えた場合、そのグループは拡張されません。

    "-1" の値は拡張できないことを示します。

    最大サイズを超えたために拡張できない場合、出席者リストにはグループ名だけが表示され、企画者にエラーが返されます。

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

  7. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal
参照

グループの設定については、「グループ用に Calendar Server を設定するには」を参照してください。

Procedureカレンダの自動プロビジョニングを無効にするには

ユーザーカレンダ、リソースカレンダ、およびグループカレンダの自動プロビジョニングはデフォルトで有効になっています。つまり、ログインしようとしたユーザーがまだデフォルトカレンダを持っていない場合、デフォルト設定を使用してユーザーカレンダが作成されます。

ユーザー、リソース、またはグループに対し予定への出席依頼が行われたが、デフォルトカレンダがまだ用意されていない場合、デフォルト設定を使用してリソースカレンダまたはグループカレンダが作成されます。

いずれかのカレンダの自動プロビジョニングを無効にするには、次の手順で示すように、ics.conf ファイルの該当するパラメータを変更します。

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

  2. stop-cal を実行して Calendar Server サービスを停止します。

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

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

  5. 次のパラメータを編集して、ユーザーカレンダ、リソースカレンダ、およびグループカレンダの自動プロビジョニングを無効にします。

    local.autoprovision

    ユーザーカレンダの自動プロビジョニングを有効にするか (“yes”)、無効にするか (“no”) を指定します。デフォルトは “yes” です。

    resource.invite.autoprovision

    リソースカレンダの自動プロビジョニングを有効にするか (“yes”)、無効にするか (“no”) を指定します。デフォルトは “yes” です。

    group.invite.autoprovision

    グループカレンダの自動プロビジョニングを有効にするか (“yes”)、無効にするか (“no”) を指定します。デフォルトは “yes” です。

    autoprovisioning

    ユーザーカレンダの自動出席依頼を有効にするか (“yes”)、無効にするか (“no”) を指定します。デフォルトは “yes” です。

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

  7. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

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

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

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

  2. stop-cal を実行して Calendar Server サービスを停止します。

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

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

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

    service.wcap.freebusybegin

    get_freebusy の範囲指定の開始時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは "30" です。

    service.wcap.freebusyend

    get_freebusy の範囲指定の終了時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは "30" です。

    calstore.freebusy.include.defaultcalendar

    ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストに含めるかどうかを指定します。デフォルトは "yes" です。

    calstore.freebusy.remove.defaultcalendar

    ユーザーのデフォルトカレンダを、そのユーザーの空き/予定ありカレンダリストから削除できるかどうかを指定します。デフォルトは "no" です。

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

  7. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

4.3 LDAP ユーザー、グループ、およびリソースのカレンダの設定

ここでは、LDAP ユーザー、グループ、およびリソースを設定する手順について説明します。

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

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

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

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

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

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

    local.lookupldapsearchattr.aclgroup

    ACL を評価するために、ユーザー、グループ、またはリソースが所属しているグループの指定に使用する属性。デフォルトは "aclgroupaddr" です。これはダイナミックグループの計算に使用されます。

    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" です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

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

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

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

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

  4. 次の表に示す 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” です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

Procedureグループ用に Calendar Server を設定するには

Calendar Server では LDAP グループをサポートしています。これはユーザーをまとめて名前を付けたものです。グループのメンバー構成は静的にすることも、動的に作成することもできます。グループは入れ子にすることができます。グループには、ユーザーの uid に相当する groupid が割り当てられます。メールアドレスも割り当てられます。

さらに、グループには、groupid に相当するグループ calid と、groupid@sesta.com などの追加ドメインを持つデフォルトカレンダを割り当てられます。グループカレンダには、設定データベースに格納されたユーザーインタフェース設定はありません。代わりに、グループの作成で使用する icsDefaultacl 属性が LDAP エントリに格納されています。

グループは、icsCalendarGroup のインスタンスとしてLDAP エントリ内で定義されます。グループカレンダのその他の属性については、『Sun Java System Communications Services 6 2005Q4 Schema Reference』を参照してください。

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

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

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

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

    local.lookupldapsearchattr.owner

    グループおよびリソースに使用する所有者属性。デフォルトは "owner" です。

    local.lookupldapsearchattr.coowner

    グループおよびリソースの二次所有者属性。デフォルトは "icsSecondaryowners" です。

    local.lookupldapsearchattr.groupid

    一意のグループ ID の格納に使用される属性。属性は "groupid" です。

    local.lookupldapsearchattr.defaultacl

    自動プロビジョニング時に各グループカレンダに与えられるデフォルト ACL の格納に使用される属性。デフォルトは "icsDefaultacl" です。

    local.lookupldapsearchattr.doublebook

    グループカレンダのダブルブッキングが許可されているかどうかを指定するために使用される属性。これは、デフォルトのグループカレンダを自動作成するときに使用される属性です。デフォルトは "icsDoublebooking" です。

    local.lookupldapsearchattr.autoaccept

    グループカレンダへの出席依頼を自動的に受諾するかどうかを指定するために使用される属性。これは、デフォルトのグループカレンダを自動作成するときに使用される属性です。デフォルトは "icsAutoaccept" です。

    local.lookupldapsearchattr.timezone

    自動作成されたグループカレンダのタイムゾーンを指定するために使用される属性。デフォルトは "icsTimezone" です。

    local.lookupldapsearchattr.aclgroup

    ACL を評価するために、ユーザー、グループ、またはリソースが所属しているグループの指定に使用する属性。デフォルトは "aclgroupaddr" です。グループの場合、これは入れ子になったグループに使用されます。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

参照

グループにカレンダを割り当てる予定の場合は、グループカレンダを設定する必要があります。「グループカレンダを設定するには」を参照してください。

グループを使用する場合は、グループ LDAP エントリで次のドメインレベルの設定を行なってください。

グループ用の Calendar Server ドメインの設定方法については、「11.1 Calendar Server バージョン 6.3 でのグループのドメイン設定の指定」を参照してください。　

4.4 Calendar Server の設定

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

ここでは、次の内容について説明します。

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

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

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

  2. stop-cal を使用して Calendar Server サービスを停止します。

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

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

  5. 次の表のパラメータを 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

    グループの拡張時に許容できるメンバーの最大数。デフォルト値の "0" は、サイズの限度を設けずにグループを拡張することを示します。

    -1 の値はグループを拡張できないことを示します。

    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 ディレクトリに存在することを検証する必要があります。デフォルトは "no" です。

    service.wcap.freebusy.redirecturl

    要求されたカレンダがローカルカレンダデータベースに存在しない場合は、代わりに、このパラメータで指定された URL を使用して検索を別のデータベースにリダイレクトできます。これは、特に 2 つのデータベース間で移行を行なっていて、どちらのデータベースもまだ使用されているときに作成されたスクリプトに使用されます。他方のデータベースを参照するかどうかを指定するには、get_freebusy.wcap コマンドを使用します。『Sun Java System Calendar Server 6.3 WCAP Developer’s Guide』の get_freebusy コマンドの説明を参照してください。

    store.partition.primary.path

    カレンダ情報が格納される一次ディスクパーティションの場所。デフォルトは "/var/opt/SUNWics5/csdb" です。

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

  7. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

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

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

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

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

  4. 次の表に示すパラメータを 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" です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

参照

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

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

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

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    service.wcap.format

    コマンドのデフォルトの出力形式を指定します。次の 2 つの形式がサポートされています。 

    • "text/calendar" (デフォルト)

    • "text/xml"

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

    service.wcap.version

    WCAP のバージョン。 

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

Procedure電子メール通知を有効にするには

次の 3 つのタイプの電子メール通知を有効にできます。

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    ine.invitation.enable

    "yes" - (デフォルト) 出席者へ出席依頼の通知を送信します。

    "no" - 出席者へ出席依頼の電子メール通知を送信しません。

    ine.cancellation.enable

    "yes" - (デフォルト) 出席者へ予定取り消しの通知を送信します。

    "no" - 出席者へ取り消しの通知を送信しません。

    ine.reply.enable

    "yes" - (デフォルト) 出席依頼に対する出席者の応答の通知を企画者に送信します。

    "no" - 応答の通知を企画者に送信しません。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

参照

通知の設定については、「E.4.1 Calendar Server 電子メール通知の構成パラメータとフォーマットファイル」を参照してください。

4.5 ログインと認証の設定

ここでは、ログインおよび認証の設定手順について説明します。

ここでは、次の内容について説明します。

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

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

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

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

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

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

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

    service.http.allowadminproxy

    管理者がプロキシログインを実行してユーザーカレンダを管理できるかどうかを指定します。 "yes" に設定すると、プロキシログインは許可されます。"no" に設定すると、プロキシログインは許可されません。デフォルト値は "yes" です。

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

  6. 次の WCAP コマンドを使用して、管理者プロキシログインが正しく機能することを確認します。


    http://server[:port]/login.wcap?
   user=admin-user&password=admin-password
   &proxyauth=calendar-user&fmt-out=text/html

    この例で使用されている各変数の意味は次のとおりです。

    • server は Calendar Server が稼動しているサーバーの名前。

    • port は Calendar Server のポート番号。デフォルトのポートは 80。

    • admin-user は Calendar Server の管理者。たとえば、calmaster など。

    • admin-password は admin-user のパスワード。

    • calendar-user は Calendar Server ユーザーの calid。

    • fmt-out は内容の出力形式の仕様。たとえば、テキスト、HTMLなど。

    コマンドの実行が成功すると、Calendar Server は calendar-user のカレンダを表示します。問題が発生した場合は、「Unauthorized」というメッセージが出力されます。

    次のような原因が考えられます。

    • admin-user が Calendar Server の管理者権限を持っていない。

    • admin-password が正しくない。

    • calendar-user が有効な Calendar Server ユーザーではない。

Procedure認証を設定するには

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.authldapbasedn

    LDAP 認証のベース DN。指定しない場合は local.ugldapbasedn の設定が適用されます。

    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" です。

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

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

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

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

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

    service.authcachesize

    Calendar Server がキャッシュに保持する、認証されたユーザーの ID (uid) およびパスワードの最大数。デフォルトは “10000” です。

    service.authcachettl

    最後のアクセスから uid とパスワードがキャッシュから削除されるまでの秒数。デフォルトは “900” です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

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

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

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

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

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

    service.dnsresolveclient

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

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

4.6 カレンダサービス (デーモン) の設定

ここでは、カレンダサービス (デーモン) の設定手順について説明します。

この項の内容は次のとおりです。

ヒント –

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

Procedure起動サービスと停止サービスを設定するには

start-cal および stop-cal コマンドは、Calendar Server の起動と停止を簡単に行うためのラッパースクリプトです。このユーティリティーは、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」で定義されています。

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

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.serveruid

    ランタイムユーザー ID (uid)。デフォルトは "icsuser" です。これは、スーパーユーザー権限が必要でない場合に使用するユーザー ID です。

    local.servergid

    ランタイムグループ ID (gid)。デフォルトは "icsgroup" です。これは、スーパーユーザー権限が必要でない場合に使用するグループ ID です。

    local.autorestart

    このパラメータが "yes" に設定されている場合、watcher に接続しているサービスが正しく切断せずに終了すると、このサービスは自動的に再起動します。

    local.autorestart.timeout

    自動再起動タイムアウト間隔を定義します。自動起動時に無限に再起動を繰り返さないようにするため、指定した間隔内に 2 度終了すると、サービスは再起動しません。デフォルト設定は 10 分です。 

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

  7. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の Watcher プロセスを設定するには

Watcher プロセス (watcher) は、ソケット接続の失敗を監視します。これは Calendar Server と Messaging Server の両方で使用されます。Calendar Server パラメータで Watcher の設定を行うには、次の手順を実行します。

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

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.watcher.enable

    このパラメータが "yes" に設定されている場合、起動プログラムは他のどのサービスよりも先に watcher を起動しようとします。また、デーモンはソケット接続を通じて接続します。デフォルトは "no" ですが、設定プログラムにより "yes" に変更されます。

    local.watcher.port

    これは watcher が待機するポートです。Messaging Server はポート 49994 を使用します。Calendar Server には、49995 などの別のポートを使用してください。

    local.watcher.config.file

    watcher の設定ファイル。相対パスの場合、config ディレクトリを基準としたパスになります。デフォルトは watcher.cnf です。

    service.autorestart

    "yes" に設定した場合、Watcher は、正しく切断せずに終了したすべての登録サービスを自動的に再起動します。サービスが 10 分間に 2 度終了すると、Watcher はサービスを再起動しません。

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

  7. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

参照

Watcher プロセスについては、『Sun Java System Messaging Server 6.3 管理ガイド』を参照してください。第 4 章と第 23 章で説明しています。

注 –

Watcher を有効にした場合、Watcher で監視する各サービスを Watcher プロセスに登録する必要があります。これは Calendar Server デーモン内部で自動的に行われます。またデーモンにより、各サービスのプロセス ID とその状態 ("init" または "ready") を含んだ pid ファイルが、cal-svr-base/data/proc ディレクトリに作成されます。

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

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.store.checkpoint.enable

    "yes" に設定すると、csadmind データベースチェックポイントスレッドが開始されます。"no" に設定すると、チェックポイントログファイルは作成されません。デフォルトは "yes" です。

    service.admin.dbcachesize

    管理セッション用の Berkeley データベースの最大キャッシュサイズ (バイト単位)。デフォルトは "8388608" です。

    local.store.deadlock.enable

    "yes" に設定すると、csadmind データベースデッドロック検出スレッドが開始されます。デフォルトは "yes" です。

    service.admin.diskusage

    "yes" に設定すると、csadmind ディスク容量低下監視スレッドが開始されます。デフォルトは "no" です。デフォルトでは、ディスク使用率は監視されません。

    service.admin.enable

    "yes" に設定すると、すべてのサービスを開始するときに csadmind サービスを開始し、すべてのサービスを終了するときに csadmind サービスを終了します。デフォルトは “yes” です。

    service.admin.maxthreads

    1 管理セッションで実行されるスレッドの最大数。デフォルトは “10” です。

    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” です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の HTTP サービス (cshttpd) を設定するには

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    service.http.admins

    この Calendar Server の管理権限を持つユーザー ID を空白文字で区切って指定します。デフォルトは "calmaster" です。

    service.http.allowadminproxy

    "yes" の場合、プロキシ経由のログインが許可されます。これがデフォルトです。

    service.http.allowanonymouslogin

    "yes" に設定すると、匿名アクセス (認証なし) が許可されます。これは特殊なタイプのログインであり、指定した制限付きのアクセス (通常は公開カレンダへの読み取り専用アクセス) のみが許可されます。デフォルトは "yes" です。

    service.http.calendarhostname

    HTML ドキュメントを取得するための HTTP ホスト。ユーザーが完全修飾ホスト名を指定してカレンダデータにアクセスできるようにするには、mycal@sesta.com のように、Calendar Server が稼動するマシンの完全修飾ホスト名 (マシン名、DNS ドメインとサフィックスを含む) をこの値に指定する必要があります。

    指定しない場合、ローカル HTTP ホストが適用されます。 

    service.http.commandlog

    このパラメータはデバッグ専用です。"yes" に設定した場合、システムにより、すべての着信コマンドが http.commands ログファイルに記録されます。

    本稼働中には使用しないでください。ログファイルがすぐに満杯になり、パフォーマンスが低下する可能性があります。 

    service.http.commandlog.all

    このパラメータはデバッグ専用です。"yes" に設定した場合、システムにより、すべての HTTP 要求が http.access ログファイルに記録されます。

    本稼働中には使用しないでください。ログファイルがすぐに満杯になり、パフォーマンスが低下する可能性があります。 

    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 を持つサーバーについては、「21.8 複数 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” です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 のアラーム通知を設定するには

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

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

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

  4. 次の表に示す 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” です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

4.7 Calendar Server バージョン 6.3 における Berkeley のデッドロックの定期的チェックの設定

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

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

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

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

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

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

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

    local.caldb.deadlock.autodetect

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

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

注意事項

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

4.8 Calendar Server バージョン 6.3 の LDAP の設定

ここでは、LDAP 用に Calendar Server を設定する手順について説明します。

ここでは、次の内容について説明します。

ProcedureCalendar Server バージョン 6.3 の LDAP への匿名アクセスを設定するには

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

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    calstore.anonymous.calid

    匿名ログインのカレンダ ID (calid) を指定します。デフォルトは "anonymous" です。

    service.http.allowanonymouslogin

    匿名アクセス (ログインなし) が許可されるかどうかを指定します。デフォルトは “yes” です。電子メールによるカレンダ URL の受信者は、ログインを行わないで空き/予定ありバージョンのカレンダにアクセスできます。

    service.wcap.anonymous.

    allowpubliccalendarwrite

    書き込み可能な公開カレンダへの匿名ユーザーによる書き込みが許可されるかどうかを指定します。デフォルトは “yes” です。

    service.wcap.userprefs.ldapproxyauth

    ユーザー設定に使用する匿名の LDAP 検索を有効にします。デフォルトは “no” で、匿名アクセスは許可されます。“yes” に設定することは、検索にプロキシ認証が使用されることを意味します。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の LDAP 出席者ルックアップを設定するには

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.lookupldap.search.

    minwildcardsize

    出席者ルックアップ検索のワイルドカード検索に使用する文字列の最小サイズを指定します。ゼロ (0) は常にワイルドカード検索を行うことを意味します。

    sasl.default.ldap.searchfilter

    ユーザー検索に使用される認証フィルタを指定します。デフォルトは次のとおりです。 "(uid=%s)"

    local.lookupldapbasedn

    LDAP 出席者ルックアップの DN を指定します。指定しない場合は local.ugldapbsedn の設定が適用されます。デフォルト値はありません。

    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

    出席者ルックアップの共通名属性を指定します。デフォルトは cn です。

    local.lookupldapsearchattr.

    objectclass

    出席者ルックアップのオブジェクトクラス属性を指定します。デフォルトは objectclass です。

    local.lookupldapsearchattr.

    objectclass.caluser

    カレンダユーザーのオブジェクトクラスを指定します。デフォルトは icsCalendarUser です。

    local.lookupldapsearchattr.

    objectclass.calresource

    カレンダリソースのオブジェクトクラスを指定します。デフォルトは icsCalendarResource です。

    local.lookupldapsearchattr.

    objectclass.group

    グループのオブジェクトクラスを指定します。デフォルトは icsCalendarGroup です。

    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 として解決されます。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の LDAP 出席者ルックアップの検索フィルタを設定するには

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

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

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

  4. 次の表のパラメータを 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: ワイルドカードを使用しない出席者の文字列。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の LDAP リソースルックアップを設定するには

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

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

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

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

    local.lookupldap.resource.use.ugldap

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

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

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

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の LDAP mail-to-calid ルックアップを設定するには

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    local.lookupldap.mailtocalid.search

    mail-to-calid ルックアップに使用する mail 属性を指定します。デフォルトは "(|(mail=%s)(mailalternateaddress=%s))” です。

    属性 mailalternateaddress の代わりに mailequivalentaddress を使用できます。

    local.ugldapbasedn

    mail-to-calid ルックアップのベース DN を指定します。 

    local.authldapbinddn

    mail-to-calid ルックアップに使用するホストにバインドされる DN を指定します。指定しない (デフォルト "") 場合は、匿名バインドと見なされます。

    local.authldapbindcred

    local.authldapbinddn で指定された DN のパスワードを指定します。デフォルトはありません。

    local.ugldaphost

    mail-to-calid ルックアップに使用される LDAP ホストを指定します。 

    local.ugldapmaxpool

    mail-to-calid ルックアップ用に維持されるクライアント接続の最大数を指定します。デフォルトは “1024” です。

    local.ugldappoolsize

    mail-to-calid ルックアップ用に維持されるクライアント接続の最小数を指定します。デフォルトは “1” です。

    local.ugldapport

    LDAP mail-to-calid ルックアップ用のポートを指定します。デフォルトはありません。 

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 のユーザー設定 LDAP ディレクトリを使用するように設定するには

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

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

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

  4. 次の表のパラメータを 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” に設定することは、検索にプロキシ認証が使用されることを意味します。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 のユーザー設定を指定するには

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

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

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

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

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

    パラメータ 

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

    説明 

    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 属性に保存されるユーザー設定を定義します。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の LDAP データキャッシュを有効にして設定するには

始める前に

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

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

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

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

  4. 次の表に示すパラメータを編集して、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 分) です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

参照

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

注意 – 注意 –

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

ProcedureCalendar Server バージョン 6.3 の LDAP SDK キャッシュを有効にして設定するには

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

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

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

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

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

    service.ldapmemcache

    "yes" に設定すると、LDAP SDK キャッシュが有効になります。デフォルトは “no” です。

    service.ldapmemcachettl

    service.ldapmemcache に "yes" を指定した場合、このパラメータは項目をキャッシュしておける最大秒数の設定に使用されます。“0” を指定した場合、項目をキャッシュしておける時間に制限が適用されなくなります。デフォルトは “30” です。

    service.ldapmemcachesize

    service.ldapmemcache に "yes" を指定した場合、このパラメータを使用して、キャッシュに使用できるメモリーの最大容量をバイト単位で設定します。“0” を指定した場合、キャッシュ容量の制限は適用されなくなります。デフォルトは “131072” です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 の空き/予定あり検索の期間を設定するには

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

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

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

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

    service.wcap.freebusybegin

    get_freebusy の範囲指定の開始時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは “30” です。

    service.wcap.freebusyend

    get_freebusy の範囲指定の終了時刻に適用される、現在時刻からのオフセットを指定します (日単位)。デフォルトは “30” です。

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

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

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

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

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

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

    service.calendarsearch.ldap. primaryownersearchfilter

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

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

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

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

  6. Calendar Server を再起動します。

    cal-svr-base /SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 で LDAP のルートサフィックスを設定するには

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

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

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

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

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

    service.dcroot

    ディレクトリ内の DC ツリーのルートサフィックス。Schema バージョン 1 および Schema バージョン 2 互換モード (1.5) による複数ドメインのサポートに必要です。デフォルトは "o=internet" です。

    「10.2 はじめての Calendar Server バージョン 6.3 の複数ドメイン環境の設定」も参照してください。

    service.schema2root

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

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

  6. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

第 5 章 Calendar Server バージョン 6.3 での複数のマシンへのカレンダデータベースの分散の設定

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

注意 – 注意 –

フロントエンドサーバーとバックエンドサーバーの両方で同じバージョンの Calendar Server を実行する必要があります。

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

ヒント –

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

5.1 Calendar Server バージョン 6.3 での CLD プラグインの基礎的な情報

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

ここでは、次の内容について説明します。

5.1.1 Calendar Server バージョン 6.3 での CLD プラグインの概要

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

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

5.1.2 Calendar Server バージョン 6.3 での CLD プラグインのしくみ

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

  1. エンドユーザーが Communications Express を使用してカレンダにアクセスすると、CLD プラグインはカレンダの calid から userid を取り出し、LDAP ディレクトリデータベースまたは CLD データキャッシュ (有効な場合) でカレンダの所有者を検索します。フロントエンドのマシンを設定する方法については、「CLD 用にフロントエンドサーバーを設定するには」を参照してください。

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

  3. Calendar Server は、ホスト名を使用して、DWP (データベースワイヤプロトコル) でバックエンドサーバー上のカレンダデータにアクセスします。

  4. Calendar Server は、ユーザーがログインしているサーバーに DWP でカレンダデータを送信するため、そのデータをユーザーインタフェースで表示できます。

ヒント –

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

5.1.3 Calendar Server バージョン 6.3 での CLD プラグインでサポートされる構成

ここでは、CLD プラグインについての概要を説明します。

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

ヒント –

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

5.1.3.1 Calendar Server バージョン 6.3 での複数のフロントエンドサーバーと複数のバックエンドサーバー

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

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

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

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

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

これは、フロントエンドサーバーとバックエンドサーバーが複数あるシステムの例を示しています。

5.1.3.2 Calendar Server バージョン 6.3 でフロントエンドサーバーとバックエンドサーバーの両方の機能を持つ複数のマシン

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

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

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

5.1.4 Calendar Server 6.3 のストレージ要件の簡単なサイジング式

ここでは、メディア使用状況プロファイルに基づいていくつかの簡単な数式を使った簡単なサイジング式について説明します。これによって、必要なバックエンドサーバー数とフロントエンドサーバー数、およびストレージの容量を算出できます。

この節の内容は次のとおりです。

5.1.4.1 Calendar Server 6.3 配備でのメディア使用状況プロファイルの定義

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

5.1.4.2 フロントエンドCPU の数

数式は次のとおりです。

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

5.1.4.3 バックエンドCPU の数

数式は次のとおりです。

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

5.1.4.4 必要なストレージの容量

数式は次のとおりです。

1 ユーザーあたりのストレージの容量 = 電子メール 100 件 / 週 × 52 週 / 年 × 5K / メール × オンラインでデータを維持する年数 x オンラインのコピー数 (5 バックアップ + 1 作業コピー) = 100*52*5K*2*(5+1) = 1 ユーザーあたり 65M バイトのストレージ。

つまり、2.6M バイト / ユーザー / 年 / オンラインコピー。

注 –

最終的な数字は、オンラインで維持するホットバックアップとアーカイブバックアップの数によって決まります。この例で使用する数は、バックアップコピー 5 つです。

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

ここでは、CLD および DWP 用にサーバーを設定する方法について説明します。

ここでは、次の内容について説明します。

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

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

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

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

  4. 次のリストに示すように、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

    このパラメータはデフォルトで有効 (値 = "yes") になっています。これは設定ファイル (ics.conf) には表示されません。

    無効 (値 = "no") にしたい場合は、設定ファイルに追加する必要があります。

    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" に設定) してください。フロントエンドマシンでホットバックアップを行う必要はありません。

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

  6. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

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

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

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

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

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

    パラメータ

    説明

    service.http.enable

    このパラメータを "no" に設定します。

    バックエンドサーバーでは HTTP は必要ありません。

    service.admin.enable

    このパラメータをデフォルト値の "yes" に設定して、管理サービス (csadmind) を有効にします。

    caldb.cld.type

    バックエンドのみのマシンの場合は、"local" に設定します。フロントエンドとバックエンドの両方のあるマシンの場合は、"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") にしてください。

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

  6. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

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

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

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

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

  4. 次の表に示すように、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" に設定) してください。

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

  6. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

5.3 Calendar Server バージョン 6.3 でのフロントエンドサーバーとバックエンドサーバーの間のセキュリティーの管理

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

ここでは、次の内容について説明します。

5.3.1 Calendar Server バージョン 6.3 での認証の行われ方

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

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

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

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

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

ProcedureCalendar Server バージョン 6.3 でフロントエンドサーバーの DWP 接続の認証を設定するには

始める前に
注意 – 注意 –

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

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

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

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

  4. 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 はサーバー名です。

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

  6. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

ProcedureCalendar Server バージョン 6.3 でバックエンドサーバーの DWP 接続の認証を設定するには

始める前に
注意 – 注意 –

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

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

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

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

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

    パラメータ

    説明

    service.dwp.admin.userid

    バックエンドサーバーで、DWP 接続の認証に使用するユーザー ID を指定します。バックエンドサーバーがユーザー ID を指定しない場合、認証は行われません。

    service.dwp.admin.cred

    バックエンドサーバーで、DWP 接続の認証に使用するパスワードを指定します。バックエンドサーバーがパスワードを指定しない場合、認証は行われません。

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

  6. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

第 6 章 Calendar Server 6.3 ソフトウェアでの高可用性 (フェイルオーバーサービス) の設定

この章では、Sun Cluster 3.0 または 3.1 を使用して、Calendar Server 6.3 ソフトウェア用の高可用性をインストールおよび設定する方法について説明します。

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

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

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

6.1 Calendar Server バージョン 6.3 の高可用性の選択の概要

高可用性は複数の方法で設定できます。ここでは、3 つのタイプの高可用性の概要について説明し、必要に適したタイプを選択するために役立つ情報を紹介します。

この節の内容は次のとおりです。

6.1.1 Calendar Server バージョン 6.3 の非対称型高可用性について

この図では、単純な非対称型 HA の Calendar Server インストールを示しています。

単純な非対称型高可用性システムには 2 つの物理ノードがあります。プライマリノードは常にアクティブであり、もう一方のノードはバックアップノードとして機能して、プライマリノードに障害が生じた場合に処理を継続できるようになっています。フェイルオーバーを行う場合、共有ディスクアレイがバックアップノードによって制御されるように切り替えられます。Calendar Server プロセスは、障害の発生したプライマリノードで停止し、バックアップノードで起動します。

このタイプの高可用性システムにはいくつかの長所があります。1 つの長所は、バックアップノードが専用であり、完全にプライマリノード用として確保されているという点です。したがって、フェイルオーバーの実行時に、バックアップノード上でリソースが競合することがありません。もう 1 つの長所は順次アップグレードを行えるということです。つまり、一方のノードでアップグレードを行いながら、他方のノードで Calendar Server ソフトウェアを実行し続けられます。1 番目のノードのアップグレード中に ics.conf ファイルを変更しても、設定ファイルは起動時に一度読み込まれるだけなので、その変更はセカンダリノードで実行しているもう一方の Calendar Server インスタンスには影響しません。新しい設定を有効にするには、カレンダプロセスを停止してから再起動する必要があります。もう一方のノードをアップグレードする場合は、アップグレードしたプライマリノードへのフェイルオーバーを実行し、セカンダリノード上でアップグレードを開始します。

注 –

もちろん、最初にセカンダリノードをアップグレードしてからプライマリノードをアップグレードすることもできます。

非対称型高可用性モデルにはいくつかの短所もあります。1 つの短所は、バックアップノードがほとんど常にアイドル状態になっているため、リソースが十分に活用されないという点です。もう 1 つの短所は、ストレージアレイが単一であるということです。単純な非対称型高可用性システムでは、ディスクアレイに障害が発生すると、バックアップが利用できなくなります。

6.1.2 Calendar Server バージョン 6.3 の対称型高可用性について

この図では、Calendar Server の単純な対称型 HA システムを示しています。どちらのノードにも Calendar Server のアクティブなインスタンスがあります。

単純な対称型高可用性システムには 2 つのアクティブな物理ノードがあり、独自のディスクアレイを備えています。各ディスクアレイは 2 つのストレージボリュームから構成され、一方のボリュームにはローカルカレンダストアが、もう一方のボリュームには他方のノードのカレンダストアのミラーイメージが格納されます。それぞれのノードは他方のバックアップノードとして動作します。一方のノードからバックアップノードへのフェイルオーバーが行われると、Calendar Server の 2 つのインスタンスがバックアップノード上で並列して動作しますが、それぞれのインスタンスは独自のインストールディレクトリから実行され、独自のカレンダストアにアクセスします。共有するものは、バックアップノードの演算能力だけです。

このタイプの高可用性システムの長所は、両方のノードが同時にアクティブになるため、マシンのリソースが十分に活用されるという点です。ただし、障害が発生すると、バックアップノードは両方のノードから Calendar Server のサービスを実行するので、リソースの競合が多くなります。

対称型高可用性はバックアップストレージアレイも実現します。ディスクアレイに障害が発生した場合に備え、その冗長イメージをバックアップノード上のサービスで取得しておくことができます。

注 –

対称型高可用性システムを設定するには、共有ディスク上に Calendar Server バイナリをインストールします。この場合、順次アップグレードを実行できなくなる可能性があります。順次アップグレードは、Calendar Server パッチリリースによるシステム更新時のダウンタイムをゼロまたは最小にする機能であり、Calendar Server の今後のリリースで予定されています。

6.1.3 N+1 (N 対 1) について: Calendar Server バージョン 6.3 の複数の非対称型高可用性

これは、複数の非対称型 HA の Calendar Server から構成され、それぞれのノードからのフェイルオーバーが同一のスタンバイノードに対して行われます。

この章で説明した 2 種類の高可用性システム以外にも、2 つを組み合わせて 3 番目のタイプも構成できます。このタイプが、複数ノードの非対称型高可用性システムです。このタイプでは、「N」個のディスクアレイと「N」個のノードがすべて、将来の使用のために確保され通常はアクティブでない同一のバックアップノードを使用します。このバックアップノードは「N」個のうちどのノードの Calendar Server でも実行できます。前述の図に示すように、バックアップノードは「N」個のノードの各ディスクアレイを共有します。同時に複数のノードに障害が発生した場合、バックアップノードには、最高「N」個の Calendar Server インスタンスを並列して実行する能力が必要になります。「N」個のノードにはそれぞれ独自のディスクアレイが割り当てられています。

N+1 モデルの長所は、Calendar Server の負荷を複数のノードに分散でき、すべてのノードの障害に対処するために必要なバックアップノードが 1 つで済むことです。

このタイプの高可用性の短所は、非対称型システムと同じく、バックアップノードがほとんど常にアイドル状態になっていることです。さらに、N+1 高可用性システムのバックアップノードは、複数の Calendar Server インスタンスを実行する必要が生じる場合に備え、余分な能力を備えている必要があります。つまり、非常に高価なマシンをアイドル状態で待機させておくことになります。ただしマシンのアイドル率は 1:N であり、一方、単一の非対称型システムの場合は 1:1 になります。

このタイプのシステムを設定するには、「N」個の各ノードとバックアップノードに対して、非対称型高可用性システムの手順を適用します。その都度同じバックアップノードを使用しますが、プライマリノードは異なります。

6.1.4 Calendar Server バージョン 6.3 配備に応じた高可用性モデルの選択

次の表には、各高可用性モデルの長所と短所がまとめられています。この情報を使用して、どのモデルが配備に適しているかを判断してください。

表 6–1 各高可用性モデルの長所と短所

モデル 

長所 

短所 

推奨の対象ユーザー 

非対称 

  • シンプルな構成

  • 100 パーセント確保できるバックアップノード

  • ダウンタイムのない順次アップグレード

マシンリソースは完全には利用されない。 

将来拡張を予定している小規模サービスプロバイダ 

対称 

  • システムリソースの活用

  • 高可用性

バックアップノードでのリソースの競合。 

HA には十分に冗長なディスクが必要。 

単一のサーバー障害に対してパフォーマンスの低下を許容できる小企業での配備 

N+1 

  • 負荷分散

  • 簡単な拡張

複雑な管理と設定。 

リソースの制約のない配信が必要な大規模サービスプロバイダ 

6.1.5 Calendar Server 6.3 配備での高可用性システムのダウンタイムの計算

次の表では、任意の日にシステム障害によってカレンダサービスが利用できなくなる確率を示しています。この計算では、平均で、システムクラッシュまたはサーバーハングにより 3 か月に 1 日各サーバーが停止し、12 か月に 1 日各ストレージデバイスが停止すると想定しています。また、両方のノードが同時に停止するという可能性の低いケースについては無視しています。

表 6–2 システムのダウンタイムの計算

モデル 

サーバーのダウンタイムの確率 

単一サーバー (高可用性なし) 

確率 (停止) = (4 日のシステム停止 + 1 日のストレージ停止)/365 = 1.37% 

非対称 

確率 (停止) = (0 日のシステム停止 + 1 日のストレージ停止)/365 = 0.27% 

対称 

確率 (停止) = (0 日のシステム停止 + 0 日のストレージ停止)/365 = (ほとんど 0) 

N + 1 非対称 

確率 (停止) = (5 時間のシステム停止 + 1 日のストレージ停止)/(365xN) = 0.27%/N 

6.2 Calendar Server バージョン 6.3 配備に応じた HA 環境の前提条件

ここでは、HA 環境に Calendar Server をインストールするための前提条件について説明します。

次の前提条件が適用されます。

6.2.1 Calendar Server 6.3 HA 配備での HAStoragePlus について

HAStoragePlus リソースタイプを使用すると、ローカルでマウントされたファイルシステムを Sun Cluster 環境内で高可用性にすることができます。Sun Cluster グローバルデバイスグループ上に存在するファイルシステムはすべて HAStoragePlus とともに使用できます。HAStoragePlus ファイルシステムは、どの時点でも 1 つのクラスタノードでのみ使用できます。これらのローカルマウントされるファイルシステムは、フェイルオーバーモードでのみ、またフェイルオーバーリソースグループ内でのみ使用できます。HAStoragePlus は、従来のグローバルファイルシステム (GFS)、つまりクラスタファイルシステム (CFS) のサポートに加え、フェイルオーバーファイルシステム (FFS) を提供します。

HAStoragePlus は、その前身である HAStorage に比べ次のような多くの長所があります。

注 –

2002 年 5 月以降にリリースされた Sun Cluster 3.0 によるデータサービスリソースグループ内では HAStoragePlus リソースを使用します。

HAStoragePlus については、『Sun Cluster Data Services Planning and Administration Guide for Solaris OS 』を参照してください。

6.3 Calendar Server 6.3 ソフトウェアを使用した非対称型高可用性配備の詳細な作業リスト

次に、非対称型高可用性に合わせて Calendar Server をインストールし設定するために必要な作業を示します。

  1. ノードの準備

    1. Solaris オペレーティングシステムソフトウェアをクラスタのすべてのノードにインストールします。

    2. Sun Cluster ソフトウェアをクラスタのすべてのノードにインストールします。

    3. Java Enterprise System インストーラを使用して、Calendar Server HA エージェントパッケージ (SUNWscics) をクラスタのすべてのノードにインストールします。

    4. 共有ディスク上にファイルシステムを作成します。

    5. Communications Suite 5 インストーラを使用して、クラスタのプライマリノードとセカンダリノードに Calendar Server をインストールします。

  2. ディレクトリサーバー LDAP ディレクトリが置かれているマシン上で、Directory Preparation Script (comm_dssetup.pl) を実行します。

  3. 1 番目のノード (プライマリノード)をインストールし設定します。

    1. Sun Cluster コマンド行インタフェースを使用して、プライマリノードで HA を設定します。

    2. プライマリノードで、Calendar Server 設定プログラム ( csconfigurator.sh) を実行します。

    3. Sun Cluster コマンド行インタフェースを使用して、セカンダリノードに切り替えます。

  4. プライマリノード上の Calendar Server の config ディレクトリから共有ディスクの config ディレクトリへのシンボリックリンクを作成します。

  5. 2 番目のノード (セカンダリノード) をインストールし設定します。

    1. プライマリノードの設定時に作成した状態ファイルを再利用してセカンダリノードで Calendar Server 設定プログラムを実行します。

    2. 設定ファイル (ics.conf) を編集します。

    3. Sun Cluster コマンド行インタフェースを使用して、Calendar Server のリソースグループを設定し有効にします。

    4. Sun Cluster コマンド行インタフェースを使用して、リソースグループが正しく作成されたかどうかをテストし、プライマリノードへのフェイルオーバーを実行します。

段階的な手順については、「6.6 非対称型高可用性環境での Calendar Server 6.3 ソフトウェアのインストールと設定」を参照してください。

6.4 Calendar Server 6.3 ソフトウェアを使用した対称型高可用性配備の詳細な作業リスト

次に、対称型高可用性に合わせて Calendar Server をインストールし設定するために必要な作業を示します。

  1. ノードの準備

    1. Solaris オペレーティングシステムソフトウェアをクラスタのすべてのノードにインストールします。

    2. Sun Cluster ソフトウェアをクラスタのすべてのノードにインストールします。

    3. クラスタファイルシステム (グローバルファイルシステム) またはフェイルオーバーファイルシステム (ローカルファイルシステム) のどちらかで、ファイルシステムを 6 つ作成します。

    4. 必要なディレクトリを作成します。

    5. Java Enterprise System インストーラを使用して、Calendar Server HA エージェントパッケージ (SUNWscics) をクラスタのすべてのノードにインストールします。

  2. 1 番目のノードをインストールし設定します。

    1. Communications Suite 5 インストーラを使用して、Calendar Server をクラスタの 1 番目のノードにインストールします。

    2. ディレクトリサーバー LDAP データベースが置かれているマシン上で、Directory Preparation Script (comm_dssetup.pl) を実行します。

      注 –

      2 つのノード上の Calendar Server のインスタンスが同じ LDAP サーバーを共有している場合、Calendar Server ソフトウェアを 2 番目のノードにインストールしたあとは、この手順を繰り返す必要はありません。

    3. Sun Cluster コマンド行インタフェースを使用して、1 番目のノードで HA を設定します。

    4. 1 番目のノードで、Calendar Server 設定プログラム ( csconfigurator.sh) を実行します。

    5. Sun Cluster コマンド行インタフェースを使用して、2 番目のノードへのフェイルオーバーを実行します。

    6. 1 番目のノードで設定ファイル (ics.conf) を編集します。

    7. Sun Cluster コマンド行インタフェースを使用して、1 番目のノードで Calendar Server のリソースグループを設定し有効にします。

    8. Sun Cluster コマンド行インタフェースを使用して、1 番目のノードのリソースグループを作成し有効にします。

    9. Sun Cluster コマンド行インタフェースを使用して、リソースグループが正しく作成されたかどうかをテストし、1 番目のノードへのフェイルオーバーを実行します。

  3. 2 番目のノードをインストールし設定します。

    1. Communications Suite 5 インストーラを使用して、Calendar Server をクラスタの 2 番目のノードにインストールします。

    2. Sun Cluster コマンド行インタフェースを使用して、2 番目のノードで HA を設定します。

    3. 1 番目のノードの設定時に作成した状態ファイルを再利用して、Calendar Server 設定プログラム (csconfigurator.sh) を 2 番目のノードで実行します。

    4. Sun Cluster コマンド行インタフェースを使用して、1 番目のノードへのフェイルオーバーを実行します。

    5. 2 番目のノードで設定ファイル (ics.conf) を編集します。

    6. Sun Cluster コマンド行インタフェースを使用して、2 番目のノードで Calendar Server のリソースグループを作成し有効にします。

    7. Sun Cluster コマンド行インタフェースを使用して、リソースグループが正しく作成されたかどうかをテストし、2 番目のノードへのフェイルオーバーを実行します。

段階的な手順については、「6.7 対称型高可用性 Calendar Server システムの設定」を参照してください。

6.5 Calendar Server バージョン 6.3 で高可用性を設定するためのすべての配備例で使用する命名規則

ヒント –

この節を印刷し、HA のインストールおよび設定プロセスの進行に応じて使用した値を記録してください。

ここでは、次の 4 つの表で、すべての例で使用する変数名について説明します。

表 6–3 非対称型の例で使用するディレクトリ名変数

名前の例 

ディレクトリ 

説明 

install-root

/opt

Calendar Server がインストールされているディレクトリ。 

cal-svr-base

/opt/SUNWics5/cal

すべての Calendar Server ファイルが格納されているディレクトリ。 

var-cal-dir

/var/opt/SUNWics5

/var ディレクトリ。

share-disk-dir

/cal

グローバルディレクトリ。つまり非対称型高可用性システムでのノード間で共有されるディレクトリ。 

表 6–4 対称型の例で使用するディレクトリ名変数

名前の例 

ディレクトリ 

説明 

install-rootCS1

install-rootCS2

/opt/Node1

/opt/Node2

Calendar Server のインスタンスがインストールされているディレクトリ。 

cal-svr-baseCS1

cal-svr-baseCS2

/opt/Node1/SUNWics5/cal

/opt/Node2/SUNWics5/cal

ノードのすべての Calendar Server ファイルが格納されているディレクトリ。 

var-cal-dirCS1

var-cal-dirCS2

/var/opt/Node1/SUNWics5

/var/opt/Node2/SUNWics5

各ノードの /var ディレクトリ。

share-disk-dirCS1

share-disk-dirCS2

/cal/Node1

/cal/Node2

Calendar Server の各インスタンスがそのフェイルオーバーノードと共有しているグローバル (共有) ディレクトリ。これは、対称型高可用性システムで使用されます。 

表 6–5 非対称型の例で使用するリソース名変数

変数名 

説明 

CAL-RG

カレンダリソースグループ。 

LOG-HOST-RS

論理ホスト名リソース。 

LOG-HOST-RS-Domain.com

完全修飾論理ホスト名リソース。 

CAL-HASP-RS

HAStoragePlus リソース。 

CAL-SVR-RS

Calendar Server リソースグループ。 

表 6–6 対称型の例で使用するリソース名変数

変数名 

説明 

CAL-CS1-RG

Calendar Server の 1 番目のインスタンスのカレンダリソースグループ。 

CAL-CS2-RG

Calendar Server の 2 番目のインスタンスのカレンダリソースグループ。 

LOG-HOST-CS1-RS

Calendar Server の 1 番目のインスタンスの論理ホスト名リソース。 

LOG-HOST-CS1-RS-Domain.com

Calendar Server の 1 番目のインスタンスの完全修飾論理ホスト名リソース。 

LOG-HOST-CS2-RS

Calendar Server の 2 番目のインスタンスの論理ホスト名リソース。 

LOG-HOST-CS2-RS-Domain.com

Calendar Server の 2 番目のインスタンスの完全修飾論理ホスト名リソース。 

CAL-HASP-CS1-RS

Calendar Server の 1 番目のインスタンスの HAStoragePlus リソース。 

CAL-HASP-CS2-RS

Calendar Server の 2 番目のインスタンスの HAStoragePlus リソース。 

CAL-SVR-CS1-RS

Calendar Server の 1 番目のインスタンスの Calendar Server リソースグループ。 

CAL-SVR-CS2-RS

Calendar Server の 2 番目のインスタンスの Calendar Server リソースグループ。 

表 6–7 非対称型の例における IP アドレスの変数名

論理 IP アドレス 

説明 

IPAddress

chsttpd デーモンが待機するポートの IP アドレス。標準的な IP 形式で指定してください。例: "123.45.67.890"

表 6–8 対称型の例における IP アドレスの変数名

論理 IP アドレス 

説明 

IPAddressCS1

Calendar Server の 1 番目のインスタンスの chsttpd デーモンが待機するポートの IP アドレス。標準的な IP 形式で指定してください。例: "123.45.67.890"

IPAddressCS2

Calendar Server の 2 番目のインスタンスの chsttpd デーモンが待機するポートの IP アドレス。標準的な IP 形式で指定してください。例: "123.45.67.890"

6.6 非対称型高可用性環境での Calendar Server 6.3 ソフトウェアのインストールと設定

ここでは、非対称型高可用性 Calendar Server クラスタの設定手順について説明します。

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

6.6.1 Calendar Server 6.3 HA 配備に応じたファイルシステムの作成

共有ディスク上にファイルシステムを作成します。/etc/vfstab はクラスタのすべてのノードで同じにしてください。

CFS の場合、次の例のようになります。

## Cluster File System/Global File System ##
/dev/md/penguin/dsk/d400 /dev/md/penguin/rdsk/d400 /cal ufs 2 yes global,logging

FFS の場合、次の例のようになります。

## Fail Over File System/Local File System ##
/dev/md/penguin/dsk/d400 /dev/md/penguin/rdsk/d400 /cal ufs 2 no logging
注 –

これらのコマンドのフィールドは、スペースではなくタブで区切られます。

6.6.2 Calendar Server 6.3 HA 配備におけるクラスタの全共有ディスクでのカレンダディレクトリの作成

クラスタのすべてのノードに対して、設定およびデータを保持している共有ディスク上に /Cal ディレクトリを作成します。たとえば、すべての共有ディスクに対して次のコマンドを実行します。

mkdir -P /Cal

6.6.3 Calendar Server 6.3 ソフトウェアの高可用性のインストールと設定

ここでは、Calendar Server の高可用性のインストールと設定に関する作業手順について説明します。

次の各作業を順番に実行して、設定をすべて行います。

Procedureクラスタの各ノードを準備するには

  1. Communications Suite 5 インストーラを使用して、クラスタのプライマリノードとセカンダリノードに Calendar Server をインストールします。

    注 –

    必ず、すべてのノードで同じインストールルートを指定してください。

    1. 「インストールディレクトリの指定」パネルで、両方のノードのインストールルートを入力します。

      これにより、次のディレクトリに Calendar Server バイナリがインストールされます。/install-root/SUNWics5/cal。このディレクトリは Calendar Server ベース (cal-svr-base) と呼ばれます。

    2. 「あとで設定」オプションを選択します。

    3. インストールの終了後、ファイルがインストールされたことを確認します。

      # pwd
/cal-svr-base

# ls -rlt

total 16
drwxr-xr-x   4 root     bin          512 Dec 14 12:52 share
drwxr-xr-x   3 root     bin          512 Dec 14 12:52 tools
drwxr-xr-x   4 root     bin         2048 Dec 14 12:52 lib
drwxr-xr-x   2 root     bin         1024 Dec 14 12:52 sbin
drwxr-xr-x   8 root     bin          512 Dec 14 12:52 csapi
drwxr-xr-x  11 root     bin         2048 Dec 14 12:52 html

  2. 既存のディレクトリサーバー LDAP に対して、ディレクトリ準備スクリプト (comm_dssetup.pl) を実行します。

    これにより、新しい LDAP スキーマ、インデックス、および設定データが設定され、ディレクトリサーバーの準備が整います。

    comm_dssetup.pl の実行手順と詳細については、『Sun Java Communications Suite 5 インストールガイド』の第 8 章「Directory Preparation Tool (comm_dssetup.pl) 」を参照してください。

Procedureプライマリノードを設定するには

前述のように Sun Cluster コマンド行インタフェースを使用して、1 番目のノードで HA を設定します。

注 –

例でのディレクトリ名と Sun Cluster リソース名の重要な点については、「6.5 Calendar Server バージョン 6.3 で高可用性を設定するためのすべての配備例で使用する命名規則」を参照してください。

  1. Calendar Server と HAStoragePlus リソースを登録します。

    ./scrgadm -a -t SUNW.HAStoragePlus
./scrgadm -a -t SUNW.scics

  2. フェイルオーバー Calendar Server リソースグループを作成します。

    たとえば、次の例では、プライマリノードを Node1、セカンダリノード (フェイルオーバーノード) を Node2 として、カレンダリソースグループ CAL-RG を作成します。

    ./scrgadm -a -g CAL-RG -h node1,node2

  3. Calendar Server リソースグループ内に論理ホスト名リソースを作成し、そのリソースグループをオンラインにします。

    たとえば、次の例では、論理ホスト名リソース LOG-HOST-RS を作成してから、リソースグループ CAL-RG をオンラインにします。

    ./scrgadm -a -L -g CAL-RG -l LOG-HOST-RS
./scrgadm -c -j LOG-HOST-RS -y    \
      R_description="LogicalHostname resource for LOG-HOST-RS"
./scswitch -Z -g CAL-RG

  4. HAStoragePlus リソースを作成し有効にします。

    たとえば、次の例では、HAStoragePlus リソース CAL-HASP-RS を作成し有効にします。

    scrgadm -a -j CAL-HASP-RS -g CAL-RG -t 
     SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/cal
scrgadm -c -j CAL-HASP-RS -y 
     R_description="Failover data service resource for SUNW.HAStoragePlus:4"
scswitch -e -j CAL-HASP-RS

Procedureプライマリノードで設定ユーティリティー (csconfigurator.sh) を実行するには

  1. 設定プログラムを実行します。

    たとえば、 /cal-svr-base/sbin ディレクトリから次のように実行します。

    # pwd
     /cal-svr-base/sbin

# ./csconfigurator.sh

    設定スクリプトの実行方法については、このガイドの第 2 章「Calendar Server 6.3 ソフトウェアの初期実行時設定プログラム (csconfigurator.sh)」を参照してください。

  2. 「ランタイム設定」パネルで、両方の Calendar Server 起動オプションを選択解除します。

  3. 「設定およびデータファイルの格納ディレクトリ」パネルで、共有ディスク上のすべてのディレクトリを設定します。次の場所を使用します。

    設定ディレクトリ

    /share-disk-dir/config

    データベースディレクトリ

    /share-disk-dir/csdb

    添付ファイルの保存用ディレクトリ

    /share-disk-dir/store

    ログディレクトリ

    /share-disk-dir/logs

    一時ファイルディレクトリ

    /share-disk-dir/tmp

    ディレクトリを指定し終えたら、「ディレクトリの作成」を選択します。

  4. 「アーカイブおよびホットバックアップの設定」パネルで、次のように指定します。

    アーカイブディレクトリ

    /share-disk-dir/csdb/archive

    ホットバックアップディレクトリ

    /share-disk-dir/csdb/hotbackup

    ディレクトリを指定し終えたら、「ディレクトリの作成」オプションを選択します。

  5. 設定が正しいことを確認します。

    設定出力の最後を調べ、「All Tasks Passed」というメッセージが記されていることを確認します。設定出力の最後の部分は、次のようになります。

    ...
All Tasks Passed. Please check install log 
/var/sadm/install/logs/Sun_Java_System_Calendar_Server_install.B12141351
 for further details.

    詳細な出力例については、「6.11 カレンダ設定プログラムの出力例 (簡略)」を参照してください。

  6. 「次へ」をクリックして設定を終了します。

Procedureセカンダリノードを設定するには

  1. セカンダリノードに切り替えます。

    Sun Cluster コマンド行インタフェースを使用して、セカンダリノードに切り替えます。たとえば、次のコマンドは、セカンダリ (フェイルオーバー) ノード Node2 にリソースグループを切り替えます。

    scswitch -z -g CAL-RG -h Node2

  2. Calendar Server の config ディレクトリから、共有ファイルシステムの config ディレクトリへのシンボリックリンクを作成します。

    たとえば、次のコマンドを実行します。

    # pwd
/cal-svr-base

# ln -s /share-disk-dir/config .
    注 –

    必ず、ln コマンドの最後にピリオド (.) を付けてください。

  3. プライマリノード設定の状態ファイルを使用して、セカンダリノード上で Calendar Server を設定します。

    設定プログラムを実行したときに作成した状態ファイルを実行して、プライマリノードの設定を共有します。

    たとえば、次のコマンドを実行します。

    # /cal-svr-base/sbin/csconfigurator.sh -nodisplay -noconsole -novalidate

    設定プログラムを初めて実行したときと同様に、すべての作業が成功していることを確認します。

  4. 設定ファイル (ics.conf) を編集します。

    ics.conf ファイルを編集して、ファイルの最後に次のパラメータを追加します。カレンダリソースの論理ホスト名は LOG-HOST-RS です。

    注 –

    この手順を行う前に、ics.conf ファイルをバックアップしておいてください。

    ! The following are the changes for making Calendar Server
! Highly Available
!
local.server.ha.enabled="yes"
local.server.ha.agent="SUNWscics"
service.http.listenaddr="IPAddress"
local.hostname="LOG-HOST-RS"
local.servername="LOG-HOST-RS"
service.ens.host="LOG-HOST-RS"
service.http.calendarhostname="LOG-HOST-RS-Domain.com"
local.autorestart="yes"
service.listenaddr="IPAddress"

  5. Calendar Server リソースグループを作成し、有効にします。

    この例の場合、リソースグループ名は CAL-SVR-RS です。また、論理ホストリソース名と HAStoragePlus リソース名を指定するように要求されます。

    ./scrgadm -a -j CAL-SVR-RS -g CAL-RG 
     -t SUNW.scics -x ICS_serverroot=/cal-svr-base 
     -y Resource_dependencies=CAL-HASP-RS,LOG-HOST-RS

./scrgadm -e -j CAL-SVR-RS

  6. フェイルオーバーを実行して、カレンダリソースグループの作成が成功したかどうかをテストします。

    ./ scswitch -z -g CAL-RG -h Node1

    この手順を終えると、Calendar Server の非対称型高可用性システムの作成と設定は終了です。次の節では、Sun Cluster にログオンしてデバッグを行うための設定方法について説明します。

    これで、非対称型の Calendar Server HA システムのインストールと設定は終了しました。

6.7 対称型高可用性 Calendar Server システムの設定

ここでは、対称型高可用性 Calendar Server システムの設定手順について説明します。

対称型高可用性 Calendar Server システムを設定する手順は次のとおりです。

6.7.1 最初の作業

Calendar Server をノードにインストールする前に完了しなければならない準備作業が 2 つあります。

準備作業は次のとおりです。

注 –

例の中では、さまざまな箇所で各ノードのインストールディレクトリ (cal-svr-base) を指定する必要があります。対称型 HA システムの cal-svr-base は非対称型 HA システムとは異なります。対称型 HA システムの場合、cal-svr-base の形式は、/opt/node/SUNWics5/cal になります。ここで、 /opt/node は Calendar Server をインストールしたルートディレクトリ (install-root) の名前です。

例として使用するため、および 2 つの Calendar Server インスタンスのインストールディレクトリを区別するために、cal-svr-baseCS1 および cal-svr-baseCS1 と名付けられています。

この例では、2 つの Calendar Server インスタンスのインストールルートが区別できるように、install-rootCS1 および install-rootCS2 と名付けられています。

Procedureファイルシステムの作成

  1. クラスタファイルシステム (グローバルファイルシステム) またはフェイルオーバーファイルシステム (ローカルファイルシステム) のどちらかを使用して、ファイルシステムを 6 つ作成します。

    次の例は、グローバルファイルシステムの場合です。/etc/vfstab ファイルの内容は次のようになります (フィールドはすべてタブで区切られている)。

    # Cluster File System/Global File System ##
/dev/md/penguin/dsk/d500  /dev/md/penguin/rdsk/d500  
    /cal-svr-baseCS1  ufs  2  yes  logging,global
/dev/md/penguin/dsk/d400  /dev/md/penguin/rdsk/d400  
    /share-disk-dirCS1  ufs  2  yes  logging,global
/dev/md/polarbear/dsk/d200  /dev/md/polarbear/rdsk/d200  
    /cal-svr-baseCS2  ufs  2  yes  logging,global
/dev/md/polarbear/dsk/d300  /dev/md/polarbear/rdsk/d300
    /share-disk-dirCS2  ufs  2  yes logging,global
/dev/md/polarbear/dsk/d600  /dev/md/polarbear/rdsk/d300 
    /var-cal-dirCS1  ufs  2   yes  logging,global
/dev/md/polarbear/dsk/d700  /dev/md/polarbear/rdsk/d300  
    /var-cal-dirCS2  ufs   2   yes  logging,global

    次の例は、フェイルオーバーファイルシステムの場合です。/etc/vfstab ファイルの内容は次のようになります (フィールドはすべてタブで区切られている)。

    # Failover File System/Local File System ##
/dev/md/penguin/dsk/d500  /dev/md/penguin/rdsk/d500  
    /cal-svr-baseCS1  ufs  2  yes  logging
/dev/md/penguin/dsk/d400  /dev/md/penguin/rdsk/d400  
    /share-disk-dirCS1  ufs  2  yes  logging
/dev/md/polarbear/dsk/d200  /dev/md/polarbear/rdsk/d200 
   /cal-svr-baseCS2  ufs  2  yes  logging
/dev/md/polarbear/dsk/d300  /dev/md/polarbear/rdsk/d300 
    /share-disk-dirCS2  ufs  2  yes  logging
/dev/md/polarbear/dsk/d600  /dev/md/polarbear/rdsk/d300 
    /var-cal-dirCS1  ufs  2   yes  logging
/dev/md/polarbear/dsk/d700  /dev/md/polarbear/rdsk/d300
   /var-cal-dirCS2  ufs  2   yes  logging

  2. クラスタのすべてのノードに、次の必須ディレクトリを作成します。

    # mkdir -p /install-rootCS1 share-disk-dirCS1 
     install-rootCS2 share-disk-dirCS2 var-cal-dirCS1 
     var-cal-dirCS2

6.7.1.1 Calendar Server HA パッケージのインストール

Calendar Server HA パッケージ (SUNWscics) をクラスタのすべてのノードにインストールします。

インストールは、Java Enterprise System インストーラから行う必要があります。

Java Enterprise System インストーラについては、『Sun Java Enterprise System 5 Installation and Configuration Guide』を参照してください。

6.7.2 Calendar Server の 1 番目のインスタンスのインストールと設定

この節の手順に従って、Calendar Server の 1 番目のインスタンスを インストールし設定します。ここでは、次の内容について説明します。

ProcedureCalendar Server をインストールするには

  1. ファイルがマウントされていることを確認します。

    プライマリノード (Node1) で次のコマンドを入力します。

    df -k

    次に、出力の例を示します。

    /dev/md/penguin/dsk/d500     35020572   
     34738 34635629   1%   /install-rootCS1
/dev/md/penguin/dsk/d400     35020572   
     34738 34635629   1%   /share-disk-dirCS1
/dev/md/polarbear/dsk/d300   35020572   
     34738 34635629   1%   /share-disk-dirCS2
/dev/md/polarbear/dsk/d200   35020572   
     34738 34635629   1%   /install-rootCS2
/dev/md/polarbear/dsk/d600   35020572   
     34738 34635629   1%   /var-cal-dirCS1
/dev/md/polarbear/dsk/d700   35020572   
     34738 34635629   1%   /var-cal-dirCS2

  2. Sun Java Systems Communications Suite インストーラを使用して、プライマリノードに Calendar Server をインストールします。

    1. 「インストールディレクトリの指定」パネルで、インストールルート (install-rootCS1) を指定します。

      たとえば、プライマリノードが red と名付けられており、ルートディレクトリが dawn である場合、インストールルートは /dawn/red になります。これが、1 番目のノードで Calendar Server をインストールするディレクトリです。

    2. 「後で設定」を選択します。

  3. ディレクトリサーバーのあるマシン上でディレクトリ準備ツールスクリプトを実行します。

Procedure1 番目のノードで Sun Cluster を設定するには

Sun Cluster コマンド行インタフェースを使用し、次の手順に従って 1 番目のノードで Sun Cluster を設定します。

  1. 次のリソースタイプを登録します。

    ./scrgadm -a -t SUNW.HAStoragePlus
./scrgadm -a -t SUNW.scics

  2. フェイルオーバーリソースグループを作成します。

    次の例では、リソースグループは CAL-CS1-RG であり、2 つのノードのうちプライマリノードには Node1 という名前が、フェイルオーバーノードには Node2 という名前が付けられています。

    ./scrgadm -a -g CAL-CS1-RG -h Node1,Node2

  3. このノードの論理ホスト名リソースを作成します。

    カレンダクライアントはこの論理ホスト名で待機します。次の例では LOG-HOST-CS1-RS を使用していますが、この箇所は実際のホスト名に変更します。

    ./scrgadm -a -L -g CAL-RG -l LOG-HOST-CS1-RS
./scrgadm -c -j LOG-HOST-CS1-RS -y R_description=
     "LogicalHostname resource for LOG-HOST-CS1-RS"

  4. リソースグループをオンラインにします。

    scswitch -Z -g CAL-CS1-RG

  5. HAStoragePlus リソースを作成し、フェイルオーバーリソースグループに追加します。

    次の例では、リソースは CAL-HASP-CS1-RS という名前になっています。ここは各自のリソース名に置き換えます。このマニュアルの例では、見やすくするために、行が 2 行に分かれて表示されています。

    ./scrgadm -a -j CAL-HASP-CS1-RS -g CAL-CS1-RG -t 
     SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/install-rootCS1,
     /share-disk-dirCS1,/cal-svr-baseCS1
./scrgadm -c -j CAL-HASP-CS1-RS -y R_description="Failover data 
     service resource for SUNW.HAStoragePlus:4"

  6. HAStoragePlus リソースを有効にします。

    ./scswitch -e -j CAL-HASP-CS1-RS

ProcedureCalendar Server の 1 番目のインスタンスを設定するには

  1. プライマリノードで設定プログラムを実行します。

    # cd /cal-svr-baseCS1/sbin/

# ./csconfigurator.sh

    設定スクリプトの実行手順については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

  2. 「ランタイム設定」パネルで、両方の Calendar Server 起動オプションを選択解除します。

  3. 「設定およびデータファイルの格納先ディレクトリ」パネルで、次のリストに示すように共有ディスクのディレクトリを指定します。

    設定ディレクトリ

    /share-disk-dirCS1/config

    データベースディレクトリ

    /share-disk-dirCS1/csdb

    添付ファイルの保存用ディレクトリ

    /share-disk-dirCS1/store

    ログディレクトリ

    /share-disk-dirCS1/logs

    一時ファイルディレクトリ

    /share-disk-dirCS1/tmp

    ディレクトリを指定し終えたら、「ディレクトリの作成」を選択します。

  4. 「アーカイブおよびホットバックアップの設定」パネルで、次のリストに示すように共有ディスクのディレクトリ名を指定します。

    アーカイブディレクトリ

    /share-disk-dirCS1/csdb/archive

    ホットバックアップディレクトリ

    /share-disk-dirCS1/csdb/hotbackup

    これらのディレクトリを指定したあとで、「ディレクトリの作成」を選択します。

  5. 設定が成功したことを確認します。

    設定プログラムにより一連のメッセージが表示されます。すべてのメッセージが PASSED で始まっている場合、成功したことを意味します。表示される出力例については、「6.11 カレンダ設定プログラムの出力例 (簡略)」の例を参照してください。

Procedure1 番目のインスタンスに対して最後の設定手順を実行するには

  1. Sun Cluster コマンド行インタフェースを使用して、2 番目のノードへのフェイルオーバーを実行します。

    次に例を示します。

    # /usr/cluster/bin/scswitch -z -g CAL-CS1-RG -h Node2

  2. 設定ファイル ics.conf を編集して、次の例に示すパラメータを追加します。

    注 –

    この手順を開始する前に、ics.conf ファイルをバックアップしておいてください。

    ! The following changes were made to configure Calendar Server
! Highly Available
!
local.server.ha.enabled="yes"
local.server.ha.agent="SUNWscics"
service.http.listenaddr="IPAddressCS1"
local.hostname="LOG-HOST-CS1-RS"
local.servername="LOG-HOST-CS1-RS"
service.ens.host="LOG-HOST-CS1-RS"
service.http.calendarhostname="LOG-HOST-CS1-RS-Domain.com"
local.autorestart="yes"
service.listenaddr = "IPAddressCS1"
    注 –

    service.http.calendarhostname に指定する値は完全修飾ホスト名です。

  3. Sun Cluster コマンド行インタフェースを使用して、Calendar Server リソースグループを作成します。

    カレンダリソースグループを作成し、有効にします。

    次に例を示します。

    ./scrgadm -a -j CAL-SVR-CS1-RS -g CAL-CS1-RG
      -t SUNW.scics  -x ICS_serverroot=/cal-svr-baseCS1
      -y Resource_dependencies=CAL-HASP-CS1-RS,LOG-HOST-CS1-RS

./scrgadm -e -j CAL-SVR-CS1-RS

  4. Sun Cluster コマンド行インターフェイスを使用して、Calendar Server リソースグループの作成が成功したかどうかをテストし、1 番目のノードへのフェイルオーバーを実行します。このノードがプライマリノードになります。

    次に例を示します。

    ./scswitch -z -g CAL-CS1-RG -h Node1

6.7.3 Calendar Server の 2 番目のインスタンスのインストールと設定

2 番目の Calendar Server インスタンスのプライマリノードは 2 番目のノード (Node2) です。

Procedure2 番目のノードに Calendar Server をインストールするには

  1. ファイルがマウントされていることを確認します。

    プライマリノード (Node2) で次のコマンドを入力します。

    df -k

    次のような出力が表示されます。

    /dev/md/penguin/dsk/d500     35020572   
     34738 34635629   1%   /install-rootCS1
/dev/md/penguin/dsk/d400     35020572   
     34738 34635629   1%   /share-disk-dirCS1
/dev/md/polarbear/dsk/d300   35020572   
     34738 34635629   1%   /share-disk-dirCS2
/dev/md/polarbear/dsk/d200   35020572   
     34738 34635629   1%   /install-rootCS2
/dev/md/polarbear/dsk/d600   35020572   
     34738 34635629   1%   /var-cal-dirCS1
/dev/md/polarbear/dsk/d700   35020572   
     34738 34635629   1%   /var-cal-dirCS2

  2. Sun Java Systems Communications Suite インストーラを使用して、新しいプライマリノード (2 番目のノード) に Calendar Server をインストールします。

    1. 「インストールディレクトリの指定」パネルで、2 番目のノードのインストールルート (/install-rootNode2) を指定します。

      たとえば、Node 2 マシンの名前が blue で、ルートディレクトリが ocean であれば、インストールディレクトリは /ocean/blue になります。

    2. 「あとで設定」オプションを選択します。

Procedure2 番目のインスタンスで Sun Cluster を設定するには

Sun Cluster コマンド行インタフェースを使用して、次の手順に示すように、Calendar Server の 2 番目のインスタンスを設定します。

  1. フェイルオーバーリソースグループを作成します。

    次の例では、リソースグループは CAL-CS2-RG であり、2 つのノードのうちプライマリノードには Node2 という名前が、フェイルオーバーノードには Node1 という名前が付けられています。

    ./scrgadm -a -g CAL-CS2-RG -h Node2,Node1

  2. 論理ホスト名リソースを作成します。

    カレンダクライアントはこの論理ホスト名で待機します。次の例では LOG-HOST-CS2-RS を使用していますが、実際のホスト名ではこの箇所を変更します。

    ./scrgadm -a -L -g CAL-CS2-RG -l LOG-HOST-CS2-RS
./scrgadm -c -j LOG-HOST-CS2-RS -y R_description="LogicalHostname 
     resource for LOG-HOST-CS2-RS"

  3. リソースグループをオンラインにします。

    scswitch -Z -g CAL-CS2-RG

  4. HAStoragePlus リソースを作成し、フェイルオーバーリソースグループに追加します。

    次の例では、リソースは CAL-SVR-CS2-RS という名前が付けられています。ここは各自のリソース名に置き換えます。

    ./scrgadm -a -j CAL-SVR-CS2-RS -g CAL-CS2-RG -t 
     SUNW.HAStoragePlus:4 -x FilesystemMountPoints=/install-rootCS2,
     /share-disk-dirCS2,/var-cal-dirCS2
./scrgadm -c -j CAL-HASP-CS2-RS -y R_description="Failover data 
     service resource for SUNW.HAStoragePlus:4"

  5. HAStoragePlus リソースを有効にします。

    ./scswitch -e -j CAL-HASP-CS2-RS

ProcedureCalendar Server の 2 番目のインスタンスを設定するには

  1. セカンダリノードで設定プログラムを再度実行します。

    # cd /cal-svr-baseCS2/sbin/

# ./csconfigurator.sh

    設定スクリプトの実行手順については、『Sun Java System Calendar Server 6.3 管理ガイド』を参照してください。

  2. 「ランタイム設定」パネルで、両方の Calendar Server 起動オプションを選択解除します。

  3. 「設定およびデータファイルの格納先ディレクトリ」パネルで、次のリストに示すように適切なディレクトリを指定します。

    設定ディレクトリ

    share-disk-dirCS2/config

    データベースディレクトリ

    /share-disk-dirCS2/csdb

    添付ファイルの保存用ディレクトリ

    /share-disk-dirCS2/store

    ログディレクトリ

    /share-disk-dirCS2/logs

    一時ファイルディレクトリ

    /share-disk-dirCS2/tmp

    ディレクトリを指定し終えたら、「ディレクトリの作成」を選択します。

  4. 「アーカイブおよびホットバックアップの設定」パネルで、次のリストに示すように適切なディレクトリ名を指定します。

    アーカイブディレクトリ

    /share-disk-dirCS2/csdb/archive

    ホットバックアップディレクトリ

    /share-disk-dirCS2/csdb/hotbackup

    これらのディレクトリを指定したあとで、「ディレクトリの作成」を選択します。

  5. 設定が成功したことを確認します。

    設定プログラムにより一連のメッセージが表示されます。すべてのメッセージが PASSED で始まっている場合、成功したことを意味します。表示される出力例については、「6.11 カレンダ設定プログラムの出力例 (簡略)」の例を参照してください。

Procedure2 番目のインスタンスに対して最後の設定手順を実行するには

  1. Sun Cluster コマンド行インタフェースを使用して、1 番目のノードへのフェイルオーバーを実行します。

    次に例を示します。

    # /usr/cluster/bin/scswitch -z -g CAL-CS2-RG -h Node1

  2. 設定ファイル ics.conf を編集して、次の例に示すパラメータを追加します。

    注 –

    示された値は例でのみ使用します。例の値は、各自の情報に置き換える必要があります。

    この手順を開始する前に、ics.conf ファイルをバックアップしておいてください。

    ! The following changes were made to configure Calendar Server
! Highly Available
!
local.server.ha.enabled="yes"
local.server.ha.agent="SUNWscics"
service.http.listenaddr="IPAddressCS2"
local.hostname="LOG-HOST-CS2-RS"
local.servername="LOG-HOST-CS2-RS"
service.ens.host="LOG-HOST-CS2-RS"
service.http.calendarhostname="LOG-HOST-CS2-RS-Domain.com"
local.autorestart="yes"
service.listenaddr = "IPAddressCS2"
    注 –

    service.http.calendarhostname の値は完全修飾ホスト名にする必要があります。

  3. Sun Cluster コマンド行インタフェースを使用して、Calendar Server リソースグループを作成します。

    Calendar Server リソースグループを作成し、有効にします。

    次に例を示します。

    ./scrgadm -a -j CAL-SVR-CS2-RS -g CAL-CS2-RG
      -t SUNW.scics -x ICS_serverroot=/cal-svr-baseCS2
      -y Resource_dependencies=CAL-HASP-CS2-RS,LOG-HOST-CS2-RS

./scrgadm -e -j CAL-SVR-CS2-RS

  4. Sun Cluster コマンド行インタフェースを使用して、カレンダリソースグループの作成が成功したかどうかをテストし、2 番目のノードへのフェイルオーバーを実行します。このノードがこの Calendar Server インスタンスのプライマリノードになります。

    次に例を示します。

    ./scswitch -z -g CAL-CS2-RG -h Node2

    これで、対称型 HA Calendar Server のインストールと設定が終了しました。

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

次のコマンドを使用して、Calendar Server HA サービスの起動、フェイルオーバー、無効化、削除、および再起動を行います。

Calendar Server HA サービスを有効にして起動するには
# scswitch -e -j CAL-SVR-RS
Calendar Server HA サービスのフェイルオーバーを実行するには
# scswitch -z -g CAL-RG -h Node2
Calendar Server HA サービスを無効にするには
# scswitch -n -j CAL-SVR-RS
Calendar Server リソースを削除するには
# scrgadm -r -j CAL-SVR-RS
Calendar Server HA サービスを再起動するには
# scrgadm -R -j CAL-SVR-RS

6.9 Calendar Server 設定から HA を削除するには

この節では、Sun Cluster 用の HA 設定を解除する方法について説明します。ここでは、この章で説明した単純な非対称型の設定例を使用します。このシナリオは各自のインストールに応じて変更する必要があります。

ProcedureHA コンポーネントを削除するには

  1. スーパーユーザーになります。

    注 –

    以降の Sun Cluster コマンドはすべて、スーパーユーザーとして実行する必要があります。

  2. リソースグループをオフラインにします。次のコマンドを使用して、リソースグループ内のすべてのリソース (たとえば Calendar Server および HA 論理ホスト名) を終了します 。


    # scswitch -F -g CAL-RG

  3. 個別のリソースを無効にします。

  4. 次のコマンドを実行して、リソースグループから 1 つずつリソースを削除します。


    # scswitch -n -j CAL-SVR-RS
# scswitch -n -j CAL-HASP-RS
# scswitch -n -j LOG-HOST-RS

  5. 次のコマンドを使用して、リソースグループ自体を削除します。


    # scrgadm -r -g CAL-RG

  6. リソースタイプを削除します (必要な場合)。リソースタイプをクラスタから削除する場合は、次のコマンドを使用します。


    # scrgadm -r -t SUNW.scics
# scrgadm -r -t SUNW.HAStorage

6.10 Sun Cluster でのデバッグ

Calendar Server Sun Cluster エージェントは次の 2 つの異なる API を使用してメッセージをログに記録します。

Procedureログを有効にするには

/var/adm ファイルは共有できないので、各 HA ノードで次の作業を行う必要があります。このファイルは、それぞれのノードのルートパーティションにあります。

  1. Calendar Server エージェント用のログディレクトリを作成します。

    mkdir -p /var/cluster/rgm/rt/SUNW.scics

  2. デバッグレベルを 9 に設定します。

    echo 9 >/var/cluster/rgm/rt/SUNW.scics/loglevel

    次の例は、ディレクトリで目にするようなログメッセージを示しています。最後の行で、ICS-serverroot が cal-svr-base、つまりインストールディレクトリを要求していることに注意してください。

    Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,cal-rs,ics_svc_start]: 
     [ID 831728 daemon.debug] Groupname icsgroup exists.
Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]: 
     [ID 383726 daemon.debug] Username icsuser icsgroup
Dec 11 18:24:46 mars SC[SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]: 
     [ID 244341 daemon.debug] ICS_serverroot = /cal-svr-base

  3. Sun Cluster データサービスログを有効にします。

    syslog.conf ファイルを編集して、次の行を追加します。

    daemon.debug /var/adm/clusterlog

    これにより、すべてのデバッグメッセージのログが daemon.debug /var/adm/clusterlog ファイルに記録されます。

  4. syslogd デーモンを再起動します。

    pkill -HUP syslogd

    すべての syslog デバッグメッセージは次の接頭部が冒頭に置かれています。

    SC[resourceTypeName, resourceGroupName, resourceName, methodName]

    次のメッセージ例では、見やすくするために、複数の行に分けて表示しています。

    Dec 11 15:55:52 Node1 SC
      [SUNW.scics,CAL-RG,CalendarResource,ics_svc_validate]:
      [ID 855581 daemon.error] Failed to get the configuration info
Dec 11 18:24:46 Node1 SC
      [SUNW.scics,CAL-RG,LOG-HOST-RS,ics_svc_start]:
      [ID 833212 daemon.info] Attempting to start the data service under 
      process monitor facility.

6.11 カレンダ設定プログラムの出力例 (簡略)

ここでは、設定プログラムの出力の一部を示します。実際の出力はこれよりもはるかに長くなります。出力の最後には、「All Tasks Passed」というメッセージが記されていることを確認します。ログファイルをよく調べてください。ファイルの場所は出力の最後に記述されています。

/usr/jdk/entsys-j2se/bin/java -cp /opt/Node2/SUNWics5/cal/share/lib:
     /opt/Node2/SUNWics5/cal/share -Djava.library.path=
     /opt/Node2/SUNWics5/cal/lib configure -nodisplay -noconsole -novalidate
# ./csconfigurator.sh -nodisplay -noconsole -novalidate
/usr/jdk/entsys-j2se/bin/java -cp /opt/Node2/SUNWics5/cal/share/lib:
     /opt/Node2/SUNWics5/cal/share -Djava.library.path=
     /opt/Node2/SUNWics5/cal/lib configure -nodisplay -noconsole -novalidate
Java Accessibility Bridge for GNOME loaded.

Loading Default Properties...

Checking disk space...

Starting Task Sequence
===== Mon Dec 18 15:33:29 PST 2006 =====
Running /bin/rm -f /opt/Node2/SUNWics5/cal/config
/opt/Node2/SUNWics5/cal/data

===== Mon Dec 18 15:33:29 PST 2006 =====
Running /usr/sbin/groupadd icsgroup

===== Mon Dec 18 15:33:29 PST 2006 =====
Running /usr/sbin/useradd -g icsgroup -d / icsuser

===== Mon Dec 18 15:33:30 PST 2006 =====
Running /usr/sbin/usermod -G icsgroup icsuser

===== Mon Dec 18 15:33:30 PST 2006 =====
Running /bin/sh -c /usr/bin/crle


===== Mon Dec 18 15:33:32 PST 2006 =====
Running /bin/chown icsuser:icsgroup /etc/opt/Node2/SUNWics5/config/watcher.
cnf


...

Sequence Completed

PASSED: /bin/rm -f /opt/Node2/SUNWics5/cal/config
/opt/Node2/SUNWics5/cal/data : status = 0

PASSED: /usr/sbin/groupadd icsgroup : status = 9

PASSED: /usr/sbin/useradd -g icsgroup -d / icsuser : status = 9


...

All Tasks Passed. Please check install log
/var/sadm/install/logs/Sun_Java_System_Calendar_Server_install.B12181533 for
further details.

6.12 関連マニュアル

Sun Cluster については、docs. sun.com に置かれた多くのマニュアルを参照してください。

一部のマニュアルのタイトルは次のとおりです。

第 7 章 SSL の構成

Secure Socket Layer (SSL) とは、クライアントと SSL 機能を持つサーバー間のセキュリティー保護された接続上で、データの暗号化と復号化を行うプロトコルです。サーバーは、デジタル証明書と暗号化用の公開鍵をクライアントに送信します。クライアントがサーバーの証明書を信頼すると、SSL 接続が確立されます。一方から他方へと渡されるすべてのデータが暗号化されます。データを復号化できるのは、クライアントとサーバーだけです。

Sun Java System サーバーは、デジタル証明書を検証することで、ユーザー認証をサポートしています。サーバーとの SSL セッションを確立するときに、パスワードの代わりにユーザーの証明書を提示します。証明書の信頼性が確認されると、そのユーザーは認証されます。Calendar Server は、カレンダクライアントのエンドユーザーと Calendar Server との間でデータを暗号化するために、SSL プロトコルをサポートしています。SSL をサポートするために、Calendar Server は Sun Java System Messaging Server でも使用されている NSS (Netscape Security Services) certutil の SSL ライブラリを使用します。NSS certutil ツールは、Calendar Server 製品の sbin ディレクトリにバンドルされています。

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

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

注 –

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

7.1 Calendar Server の SSL 設定

この節では、Calendar Server に SSL を設定するための手順について説明します。

ここでは、次の内容について説明します。

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

ゲートウェイがクライアントに公開鍵を送信するには、証明書が必要になります。証明書には、ゲートウェイの公開鍵、ゲートウェイの証明書に関連付けられた識別名、証明書のシリアル番号または発行日、および証明書の有効期限が含まれています。証明書は、ゲートウェイの ID を検証する証明書発行局 (CA) で発行されます。CA とは、1 人以上のユーザーによって信頼されている証明書発行局で、X.509 公開鍵証明書および CARL、または証明書失効リスト (CRL) を発行および管理します。CA は、公開鍵インフラストラクチャー (PKI) の基礎的な構成要素です。一方、PKI とは証明書および公開鍵と秘密鍵のペアを管理するために使用される一連のポリシー、プロセス、サーバープラットフォーム、ソフトウェア、およびワークステーションであり、公開鍵証明書の発行、管理、失効を行います。

CA はすべての証明書にその名前を挿入し、CRL は秘密鍵を用いて証明書を生成し、デジタル署名を付加します。CA が信頼されていることを確認すると (直接、または証明パスを通じて)、その CA によって発行される証明書を信頼できます。名前を照合すると、CA によって発行された証明書を簡単に識別できます。ただし、公開鍵を使用して証明書が有効であることを確認することができます。

CA は、次の 4 つの基本的な PKI の機能を実行します。

サーバーの証明書とキーのペアは、そのサーバーの識別情報を示します。これらは、サーバー内部または取り外し可能な外部のハードウェアカード (スマートカード) の証明書データベース内に保存されます。Calendar Server に SSL を実装するには、証明書データベースが必要です。証明書データベースには、CA (証明書発行局) と Calendar Server の証明書を定義する必要があります。ここでは、概念的な情報と、作業に関する情報を提供します。

始める前に

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

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

  2. /etc/opt/SUNWics5/config/sslpassword.conf に証明書データベースのパスワードを指定します。

    次に例を示します。


    # echo "password file entry" 
      /etc/opt/SUNWics5/config/sslpassword.conf

    password file entry の形式は次のとおりです。

    Internal (Software) Token: password

  3. 証明書データベースのディレクトリを作成します。次に例を示します。


    # cd /var/opt/SUNWics5
 # mkdir alias

  4. bin ディレクトリに移動し、証明書データベース (cert8.db) と鍵データベース (key3.db) を生成します。次に例を示します。


    # cd /opt/SUNWics5/cal/bin
 # ./certutil -N -d /etc/opt/SUNWics5/config
                 -f /etc/opt/SUNWics5/config/sslpassword.conf
    注 –

    certutil ユーティリティーを実行する必要がある場合は、例に従って実行するか、または certutil のヘルプページを参照して構文を理解してください。

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

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


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

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


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

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

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


    # ./certutil -V -u V -n SampleRootCA  
    -d /etc/opt/SUNWics5/config
 # ./certutil -V -u V -n SampleSSLServerCert 
   -d /etc/opt/SUNWics5/config

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


    # ./certutil -L -d /etc/opt/SUNWics5/config
 # ./certutil -L -n SampleSSLServerCert 
   -d /etc/opt/SUNWics5/config

  9. modutil を使用して、使用できるセキュリティーモジュール (secmod.db) をリスト表示します。次に例を示します。


    # ./modutil -list -dbdir /etc/opt/SUNWics5/config

  10. alias ファイルの所有者を icsuser と icsgroup (または Calendar Server を実行するそれ以外のユーザーとグループの ID) に変更します。次に例を示します。


    # find /etc/opt/SUNWics5/config -exec chown icsuser {};
 # find /etc/opt/SUNWics5/config -exec chgrp icsgroup {};

7.1.1 自己署名付き証明書

自己署名付き証明書は、ゲートウェイ固有の秘密鍵で署名されています。自己署名付き証明書は安全ではありませんが、証明書付き証明書が利用可能になる前に証明書を必要とするテストアプリケーションで使用できます。自己署名付き証明書は、CA の署名ではなく、独自の証明書要求を署名として使用します。

共通のフィールドが 10 個あり、PKI を通じて自己署名付き証明書を作成する際に必須となるのが 6 つ、残りの 4 つが任意のフィールドです。必須フィールドは、シリアル番号、証明書署名アルゴリズム識別子、証明書発行者名、証明書の有効期限、公開鍵、および件名です。任意のフィールドは、バージョン番号、2 つの一意の識別子、および拡張子です。任意のフィールドは、バージョン 2 および 3 の証明書でのみ表示されます。

必須の有効期限のフィールドは、証明書が有効になった日と失効する日を示します。NSS certutil が示すデフォルトの有効期限は 3 ヶ月です。ただし、証明書の有効期限のデータは、失効日になるまで信頼することはできません。X.509 CRL 機構は、発行済みの証明書の状態のアップデートを提供し、証明書の失効日を管理します。また、CA は証明書の有効期限を 1 〜 2 年に強制的に設定します。

証明書が失効したり、有効期限が切れたりすると、更新する必要があります。更新とは、新しい証明書を発行することによって公開鍵証明書に示されているデータバインディングの有効期限を延長する行為、またはプロセスを指します。次のコマンドを使用すると、証明書を有効にできます。

-V -n certname -b validity-time -u certusage [-e] [-l] [-d certdir]

次に、証明書を有効にするためのコマンドの使用方法の例を示します。

certutil -V -n jsmith@netscape.com -b 9803201212Z -u SR -e -l -d certdir.

証明書データベースツールに、次のような結果が表示されます。

Certificate:'jsmith@netscape.com' is valid.

または、

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Expired certificate

または、

UID=jsmith, E=jsmith@netscape.com, CN=John Smith, O=Netscape Communications Corp., C=US : Certificate not approved for this operation

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

次の手順で、証明書要求の生成、PKI (Public Key Infrastructure) の Web サイトへの要求の送信、証明書のインポートを行う方法について説明します。これらの手順では、証明書データベースが config ディレクトリに配置されていることを前提としています。

始める前に

証明書データベースとパスワードファイルは、両方とも同じディレクトリに常駐する必要があります。ここで示すデフォルトは config ディレクトリですが、別のディレクトリを選択することもできます。その場合は、このあとの手順を実行して別のパスパラメータを設定する必要があります。

  1. スーパーユーザー (root) としてログインします。

  2. bin ディレクトリに移動します。

    # cd /opt/SUNWics5/cal/bin

  3. 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 /etc/opt/SUNWics5/config 
-f /etc/opt/SUNWics5/config/sslpassword.conf  -z /etc/passwd -a

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

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

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

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

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


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

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


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

  8. 証明書データベース内の証明書をリスト表示します。

    # ./certutil -L -d /etc/opt/SUNWics5/config

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

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

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

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

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

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

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

  4. 次の表に示すパラメータを 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"

    local.ssldbpath

    "/etc/opt/SUNWics5/config"

    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.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"

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

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

    cal-svr-base/SUNWics5/cal/sbin/start-cal

7.2 Calendar Server 6.3 ソフトウェアの SSL のトラブルシューティング

まず、復元不可能な問題の発生に備え、証明書データベースを必ず定期的にバックアップしてください。ここでは、データベースのバックアップの作成後に考慮するべき事項について説明します。

7.2.1 cshttpd プロセスのチェック

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

# ps -ef | grep cshttpd

7.2.2 証明書の検証

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

# ./certutil -L -d /etc/opt/SUNWics5/config

7.2.3 Calendar Server ログファイルの確認

SSL エラーについて、Calendar Server ログファイルを確認します。

7.2.4 SSL ポートへの接続

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

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

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

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

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

7.2.5 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" に設定する必要があります。

第 8 章 Calendar Server 6.3 システムのシングルサインオンの設定

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

シングルサインオン (SSO) を利用することで、ユーザーは認証を一度受けるだけで、信頼できる複数のアプリケーションを追加認証なしで使用できます。

Calendar Server と Messaging Server を含め、Sun Java System コミュニケーションサーバーは次の方法で SSO を実装できます。

8.1 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 が適切に設定されていれば、それらのサーバーにもアクセスできます。

ProcedureCalendar Server で SSO を使用するには

  1. Access Manager と Directory Server がインストールされ、設定されていることを確認します。これらの製品のインストールと設定については、『Sun Java Enterprise System 5 インストールガイド (UNIX 版)』を参照してください。

  2. Calendar Server サービスの停止後、「8.1 Access Manager による SSO の設定」で示すパラメータを設定して Calendar Server の SSO を設定します。値を有効にするには、Calendar Server サービスを再起動する必要があります。

    注 –

    local.calendar.sso.amnamingurl パラメータを設定すると、Access Manager ソフトウェアがインストールされている場所に対して完全修飾ホスト名を使用する必要があります。

  3. Messaging Server で SSO を利用するための設定については、『Sun Java System Messaging Server 6.3 管理ガイド』を参照してください。

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

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

    パラメータ 

    説明 

    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“ です。 

    ヒント –

    ics.conf ファイルを変更する最善の方法とは、パラメータとその新しい値をファイルの末尾に追加することです。システムはファイル全体を読み取り、パラメータに対して最後に見つかった値を使用します。

8.1.1 Access Manager を利用したシングルサインオンに関する注意事項

この節では、Access Manager でシングルサインオン (SSO) を使用するうえで考慮すべきいくつかの事項について説明します。

次に、それらの考慮事項を示します。

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

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

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

表 8–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.appprefix で設定された値と一致する接頭辞値を持つクライアント側のすべての 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 構成パラメータを示しています。

表 8–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.3 管理ガイド』を参照してください。

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

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

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

注 –

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

csstored の概要については、『Sun Java Communications Suite 5 配備計画ガイド』を参照してください。

9.1 Calendar Server ストアサービス (csstored) の有効化

ストアサービスは、ics.conf ファイルで有効にする必要があります。次の ics. conf ファイルパラメータを "yes" に設定して、ストアサービスが有効になっていることを確認します。

local.store.enable

このパラメータが "yes" に設定されている場合、ストアにアクセスする各サービスは、正常に行われたストアサービスの起動によって異なります。

9.2 Calendar Server 6.3 システムでの自動バックアップの概要

この節では、Calendar Server システムで自動バックアップを実装する方法の概要について説明します。

この節の内容は、次のとおりです。

9.2.1 Calendar Server 6.3 システムでの自動バックアップの機能

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

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

9.2.2 Calendar Server 6.3 システムでのバックアップに対する csstored の機能

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

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

csstored が無効の場合、データベースにアクセスするその他のデーモンは機能しません。csstored デーモンは、データベースに必要なその他のタスクを実行します。このため、デーモンは無効にしないでください。

注 –

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

9.2.3 Calendar Server 6.3 システムでの循環バックアップの機能

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

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

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

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

設定ファイルの実行時に自動バックアップを設定していなかった場合は、後で設定できます。この節には、設定プログラムの実行後、Calendar Server 6.3 システムで自動バックアップを有効にするために必要な高レベルの手順のリストを掲載しています。

高レベルの作業は、次のとおりです。

9.3 Calendar Server 6.3 のバックアップのためのトランザクションログファイルの設定

この節では、トランザクションログファイルの設定の概要と方法の両方を説明します。

この節の内容は、次のとおりです。

9.3.1 Calendar Server 6.3 のバックアップのためのトランザクションログファイルについて

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

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

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

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

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

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

    cd /etc/opt/SUNWics5/config

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

    logfile.store.logname=storename.log

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

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

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

    cal-svr-base/SUNWics5/cal/sbin/start-cal

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

この節では、Calendar Server 管理者の電子メールアドレスの設定の概要と方法について説明します。

この節の内容は、次のとおりです。

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

なんらかのイベントまたはエラーが発生すると、電子メールによって管理者に通知します。

電子メールメッセージが生成されるイベントは次のとおりです。

ProcedureCalendar Server 6.3 システム管理者の電子メールアドレスを設定するには

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

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

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

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

    alarm.msgalarmnoticercpt="admin@email_address "

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

  7. Calendar Server を再起動します。

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.5 Calendar Server 6.3 データベースのホットバックアップの有効化

この節では、設定プログラムの実行時にホットバックアップを設定していなかった場合の、Calendar Server 6.3 データベースのホットバックアップの有効化の概要と方法について説明します。

この節の内容は、次のとおりです。

9.5.1 Calendar Server バージョン 6.3 のホットバックアップとは

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

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

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

ProcedureCalendar Server 6.3 システムのホットバックアップを有効にするには

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

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.hotbackup.enable="yes"

  5. ホットバックアップディレクトリのディレクトリパスを指定します。

    caldb.berkeleydb.hotbackup.path=
   /var/opt/SUNWics5/hotbackup_directory

    Calendar Server のデフォルトのホットバックアップディレクトリは、Solaris の場合は /var/opt/SUNWics5/csdb、Linux の場合は /var/opt/sun/calendar/csdb です。csdb ディレクトリは Communications Suite インストーラが認識できる便利なサブディレクトリであるため、このインストーラはデフォルトでアーカイブやホットバックアップディレクトリをこのディレクトリに置きます。

    注 –

    サイズの問題により、Calendar Server 管理者はアーカイブやホットバックアップを csdb ディレクトリ以外のディスク、ボリューム、またはパーティションに置くことを強くお勧めします。

    アーカイブおよびホットバックアップのディレクトリの数は設定可能です。このため、アーカイブとホットバックアップにそれぞれ 6 つのディレクトリを選択した場合、csdb ディレクトリには、ライブデータベースのコピーが 6 + 6 + 1 個できます。csstored ユーティリティーは、csdb のある物理ディスクと csdb ディレクトリのコンテンツのサイズに基づいて、必要なアーカイブとホットバックアップのサイズを計算します。

    アーカイブとホットバックアップのディレクトリは、使いやすいようにデフォルトで csdb ディレクトリ内にインストールされます。しかし、実際の配備では、csdb の外のディレクトリに配置してください。

    一次ディスクドライブにハードウェア障害が発生した場合に備えて、ホットバックアップを別のディスクまたはディスクサブシステムで行うこともできます。こうすることにより、一次ドライブまたはサブシステム上で発生する I/O の競合も減少する場合があります。

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

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

    cal-svr-base/SUNWics5/cal/sbin/start-cal

9.6 Calendar Server 6.3 データベースのアーカイブバックアップの有効化

この節では、設定プログラムの実行時にアーカイブバックアップを設定していなかった場合の、Calendar Server データベースのアーカイブバックアップの有効化の概要と方法について説明します。

この節の内容は、次のとおりです。

9.6.1 Calendar Server バージョン 6.3 のアーカイブバックアップとは

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

ProcedureCalendar Server 6.3 システムのアーカイブバックアップを有効にするには

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

  2. stop-cal コマンドを発行して Calendar Server サービスを停止します。

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

    cd /etc/opt/SUNWics5/config

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

    caldb.berkeleydb.archive.enable=”yes”

  5. アーカイブディレクトリのディレクトリパスを指定します。

    caldb.berkeleydb.archive.path=
   /var/opt/SUNWics5/archive_backup_directory

    一次ディスクドライブにハードウェア障害が発生した場合に備えて、アーカイブバックアップを別のディスクまたはディスクサブシステムで行うこともできます。こうすることにより、一次ドライブまたはサブシステム上で発生する I/O の競合も減少する場合があります。

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

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

    cal-svr-base/SUNWics5/cal/sbin/start-cal

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

第 10 章 Calendar Server 6.3 の複数ドメイン環境の設定

この章では、はじめて複数ドメイン環境を設定する場合の概要と手順について説明します。

ヒント –

以前、複数ドメイン環境内のドメインは、ホストされたドメインや仮想ドメインと呼ばれていました。このマニュアルでは、これらの用語を同じ意味で使用します。

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

10.1 Calendar Server バージョン 6.3 での複数ドメインの概要

Calendar Server 6.3 では、ユーザーおよびグループ LDAP エントリをまとめるデフォルトかつ唯一の方法として、複数ドメインが用意されています。つまり、ルートノードの下に少なくとも 1 つのドメインを作成し、すべてのユーザーおよびグループエントリをドメインノードの下に置く必要があります。以前のバージョンの Calendar Server では、ドメインを使用してユーザーおよびグループエントリをまとめる方法はオプションになっていました。ドメインをまったく使用せずに Calendar Server を実行できました。これは Calendar Server 6.3 には当てはまらず、少なくとも 1 つの (デフォルト) ドメインが必要になります。

複数ドメイン環境では、各ドメインが Calendar Server システムの同一のインスタンスを共有します。このため、単一のサーバーに複数のドメインを配備できます。各ドメインはネームスペースを定義し、1 つのネームスペースではすべてのユーザー、グループ、リソースが一意です。各ドメインには、変更可能な属性とユーザー設定もあります。ドメインのすべてのユーザー ID とカレンダ ID は完全修飾名にする必要があります。

設定プログラムでは、デフォルトドメインの設定に必要な情報を入力するように求められます。設定プログラムが終了し、必要なドメインをすべて作成し終えたら、ユーザーおよびグループ LDAP エントリを適切なドメインにコピーする前に、移行ユーティリティーを実行し非ドメイン ユーザーおよびグループ LDAP エントリをドメイン対応のユーザーおよびグループエントリに変換して、ユーザーおよびグループエントリを準備する必要があります。実行するユーティリティーは csmig と csvdmig です。

非ドメインバージョンの Calendar Server から Calendar Server 6.3 にアップグレードする場合は、次の選択肢があります。

現在のバージョンにアップグレードする前にホストされた (複数) ドメインを設定していた場合、ユーザー ID とカレンダ ID を変更する必要はありません。ただし、次の節で示すように、ics.conf の新しいパラメータの中には設定する必要のあるものもあります。「10.4 Calendar Server バージョン 6.3 の複数ドメインモードで必要な追加パラメータ」。

注意 – 注意 –

単一マシン上で複数の Calendar Server インスタンスを使用するように現在のサイトを設定していたり、限定的な仮想ドメインモードを実装している場合は、移行要件の評価について購入先の顧客サービスの担当者に問い合わせてください。

10.2 はじめての Calendar Server バージョン 6.3 の複数ドメイン環境の設定

非ドメイン環境や単一ドメイン環境から複数ドメイン環境に移行するには、LDAP エントリを作成する前に次の作業を実行する必要があります。

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

    Calendar Server バージョン 5 から移行する場合は、複数ドメインを設定する前に、必ず csmig、csvdmig、cs5migrate、および cs5migrate をあらかじめ実行しておいてください。これらの移行ユーティリティーについては、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」を参照してください。

  2. 実行していない場合は、comm_dsseetup.pl を実行します。

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

  4. stop-cal コマンドを発行して Calendar Server サービスを停止します。

  5. ics.conf ファイルを編集して、複数ドメインを有効にします。

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

    パラメータ 

    説明 

    service.virtualdomain.support

    複数ドメインのサポートを有効にします ("yes")。デフォルトは "yes" です。

    注 –

    単一ドメインで運用する予定の場合でも、このパラメータを "no" に変更しないでください。現在のバージョンの Calendar Server では、これが "yes" になっている必要があります。

    local.schemaversion

    LDAP スキーマのバージョンを指定します。

    service.dcroot

    複数ドメインのサポートの場合、これが local.ugldapbasedn と local.authldapbasedn に置き換わります。

    local.schemaversion="1" または local.schemaversion="1.5" の場合、すべてのドメインを下に抱えた DC ツリーのルートサフィックスを指定します。

    例: "o=internet"

    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" (英語) です。

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

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

    Schema バージョン 1 では、DC ツリーの構造に応じて、デフォルトドメイン (複数ドメインのいずれか 1 つ) を作成し、DC ツリーのルートサフィックスより 1 つ以上下のレベルに配置します。たとえば、ルートサフィックスが o=internet の場合、「10.3.3 Calendar Server バージョン 6.3 の 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

  7. デフォルトドメインエントリに対するカレンダサービスを有効にします。

    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

  8. システムで必要な数だけドメインを作成します。

    Schema バージョン 2 モードでドメインを追加する手順については、「13.2 新規の Calendar Server ドメインの作成」を参照してください。

    Schema バージョン 1 のドメインを作成するには、次の例に示すように、csdomain create を使用します。

    csdomain -n o=red.sesta.com,dc=red,dc=sesta,dc=com 
   create red.sesta.com

  9. 新しいドメインのカレンダ (必要に応じてメール) サービスを追加します。

  10. 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

  11. 以前の非ドメイン環境 (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

      管理者のグループエントリをドメインに移動する必要はありません。

  12. WCAP コマンドのすべてのカレンダ ID (calid) が完全修飾名で指定されるように、管理スクリプトを更新します。つまり、各 calid にドメイン名を含める必要があります。例: jsmith@sesta.com

10.3 Calendar Server バージョン 6.3 の複数ドメイン機能によるスキーマ選択への影響

ここでは、複数ドメインを実装するプロセスと、スキーマバージョンの選択に及ぼすその影響を十分に理解するために役立つ概念情報について説明します。

この項の内容は次のとおりです。

10.3.1 複数ドメインの概要と Calendar Server バージョン 6.3 のスキーマ選択への影響

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

Calendar Server は、Schema バージョン 1 と Schema バージョン 2 の両方の LDAP ディレクトリスキーマバージョンをサポートしています。Directory Server セットアップスクリプト(comm_dssetup.pl) を実行するときに、LDAP Schema バージョン 1 または LDAP Schema バージョン 2 のいずれかを選択できます。Schema バージョン 1 を使用する特別な理由がないかぎり、Schema バージョン 2 を使用してください。

Schema バージョン 1 を使用する場合には次の 2 つがあります。

10.3.2 Calendar Server バージョン 6.3 の Sun LDAP Schema バージョン 2

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

図 10–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 互換モードです。

10.3.3 Calendar Server バージョン 6.3 の Sun LDAP Schema バージョン 1

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

この構造には、ドメイン管理のための 2 つのツリーが含まれます。

図 10–2 LDAP Schema バージョン 1 を使用する場合の LDAP ディレクトリの構造

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

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

注 –

以前の LDAP 設定に DC ツリーが含まれていなかった場合、Schema バージョン 1 モードまたは Schema バージョン 2 互換モードを使用するには、「10.2 はじめての Calendar Server バージョン 6.3 の複数ドメイン環境の設定」の説明に従ってユーザー自身が DC ツリーノードを作成する必要があります。ただし、Schema バージョン 2 が推奨のモードです。

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

  1. DC ツリーで検索を行い、組織ツリー内のドメインのベース DN (inetDomainBaseDN 属性) をポイントする DN 値を持つドメインエントリを特定します。

  2. 組織ツリーで検索を行なってドメインエントリを特定し、そのエントリのベース DN に基づいてドメイン内のユーザー、リソース、またはグループを特定します。

10.4 Calendar Server バージョン 6.3 の複数ドメインモードで必要な追加パラメータ

Calendar Server 6 以降、すべての配備が複数ドメインに合わせて設定されています。これ以前のバージョンの Calendar Server からアップグレードする場合、ホストされた (複数) ドメインを設定していないときには、次のように、スキーマモードに合わせてパラメータを追加する必要があります。

10.4.1 Calendar Server バージョン 6.3 の Schema バージョン 1 パラメータの追加

次のパラメータがまだ存在していない場合は、設定ファイル (ics.conf) に追加してください。

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support ("yes" に設定)

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion ("1" に設定)

10.4.2 Calendar Server バージョン 6.3 の Schema バージョン 2 パラメータの追加

次のパラメータがまだ存在していない場合は、設定ファイル (ics.conf) に追加してください。

service.dcroot

service.defaultdomain

service.loginseparator

service.virtualdomain.support ("yes" に設定)

service.virtualdomain.scope

service.siteadmin.userid

service.siteadmin.cred

local.schemaversion ("2" に設定)

service.schema2root

10.5 Calendar Server 6.3 へのログイン

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

userid[@domain-name]

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

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

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

10.6 Calendar Server バージョン 6.3 での非ドメイン環境からの移行

Calendar Server バージョン 5.0 以前では、ドメインはありませんでした。したがって、ユーザー ID とカレンダ ID は完全修飾名である必要はありませんでした。つまり、jdoe@domain.com のように ID にドメイン名を含める必要はありませんでした。現バージョンの Calendar Server をインストールするまで、uid と calid が完全修飾名でなかった場合、データを変更する必要はありません。システムでは、完全修飾名ではない uid と calid が見つかった場合、デフォルトドメインに属するものと想定します。ただし、複数ドメインを実装する場合は、各ユーザーがどのドメインに所属するかを示すために、LDAP とコンポーネントデータベースを移行する必要があります。

さらに、別の方法でデータを移行する必要が生じる場合もあります。移行プログラムは複数あります。移行については、第 3 章「Calendar Server 6.3 のデータベース移行ユーティリティー」を参照してください。

第 11 章 Calendar Server 6.3 システムの既存ドメインのカスタマイズ

この章では、既存ドメインのカスタマイズに関する概念情報と手順について説明します。

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

11.1 Calendar Server バージョン 6.3 でのグループのドメイン設定の指定

LDAP でユーザーグループを設定している場合、複数のユーザーからの予約のドメインレベル設定を指定し、デフォルト ACL を設定できます。

11.1.1 Calendar Server バージョン 6.3 での複数のユーザーからの予約ドメイン設定の指定

ドメイン LDAP エントリの icsAllowRights 属性のビット 15 を設定します。複数のユーザーからの予約を許可しない場合は、"0" を使用します。複数のユーザーからの予約を許可する場合は、"1" を使用します。

11.1.2 Calendar Server バージョン 6.3 でのグループのデフォルト ACL の指定

グループのデフォルトアクセス制御設定をさまざまなレベルで変更できます。

ここでは、次の内容について説明します。

11.1.2.1 すべてのグループの場合

すべてのドメインのグループのデフォルト ACL は、ics.conf ファイルの group.default.acl パラメータで指定されます。デフォルト ACL は次のとおりです。

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

ACL は編集して変更できます。

11.1.2.2 特定のドメイン内のすべてのグループの場合

特定のドメイン内のグループのデフォルト ACL を変更するには、ドメイン LDAP エントリを編集する必要があります。icsExtendedDomainPrefs 属性の groupdefaultacl プロパティーの値を変更します。

11.1.2.3 ドメイン内の特定のグループの場合

特定のグループのデフォルト ACL を変更するには、グループ LDAP エントリを編集します。icsDefaultacl 属性の値を変更します。

11.2 Calendar Server 6.3 システムでのドメイン間の検索

ここでは、ドメイン間の検索の設定に関する概念情報と詳細な作業について説明します。

デフォルトでは、ユーザーが検索し、予定への出席を依頼できるユーザー、グループ、およびリソースは、各自のホームドメイン内のユーザーとグループに限定されています。ドメイン間の検索機能を利用することで、特定の要件を満たしているかぎり、あるドメインのユーザーが他のドメインのユーザー、グループ、およびリソースを検索することができます。

ドメイン間の検索の実装に必要な要件は次のとおりです。

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

11.3 Calendar Server バージョン 6.3 での Messaging Server により作成されたドメインの使用

Messaging Server ですでにドメインを作成している場合、Schema バージョン 1 または Schema バージョン 2 のどちらかのモードでカレンダサービスを追加できます。

ここでは、次の内容について説明します。

11.3.1 Calendar Server バージョン 6.3 の Schema バージョン 1 モードでのメッセージングドメインへのカレンダサービスの追加

ドメインにカレンダサービスを追加するには、次のオブジェクトクラスと 2 つの属性をドメインの LDAP エントリに追加します。

これには、次の 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

11.3.2 Calendar Server バージョン 6.3 の Schema 2 モードでのメッセージングドメインへのカレンダサービスの追加

Messaging Server が Schema バージョン 2 モードになっている場合、既存のドメインにカレンダサービスを追加するには、次の 2 つの手順を実行します。

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

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

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

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

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

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

commdirmig については、『Sun Java Communications Suite 5 Schema Migration Guide 』を参照してください。