test

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

第 15 章 カレンダの管理

この章で説明する内容は次のとおりです。 カレンダの作成や管理を行うための Calendar Server コマンド行ユーティリティーの使用方法について説明します。

カレンダ管理の概要

Delegated Administrator では、カレンダの作成または管理は行えません。付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 で説明している Calendar Server ユーティリティーを使用してください。

カレンダを作成する前に、次の情報を確認しておく必要があります。

cscal または csresource を実行するには、Calendar Server が稼動しているシステムの管理権限を持つユーザーとしてログインする必要があります。これらのコマンドは、必ず /opt/SUNWics5/cal/sbin ディレクトリから実行してください。つまり、sbin ディレクトリに移動する必要があります。パスを指定して別のディレクトリから実行することはできません。

カレンダ固有の識別子 (calid) の作成

Calendar Server データベース内の各カレンダは、一意のカレンダ識別子 (ID) または calid によって識別されます。カレンダを作成するとき、calid を指定する必要があります。

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

Calid 構文

データベース内の各カレンダは、一意のカレンダ ID (calid) によって識別されます。次の calid 構文には、指定する項目が 3 つあります。

userid[@domain][:calendar-name]

指定する 3 つの項目は次のとおりです。

userid

Calendar Server インスタンスのドメインで一意のユーザー ID。

domain

ユーザーのドメイン名。

ホストされたドメインがない場合、ユーザーが属しているドメインには曖昧さがないため、ドメインの部分は省略可能です。

ホストされたドメインがあり、ドメインの部分が指定されていない場合、Calendar Server では ics.conf の service.defaultdomain で指定された値をドメインに使用します。ユーザーがデフォルトのドメインに属していない場合は、ドメイン部分を指定する必要があります。

ホストされたドメイン (仮想ドメインとも言う) については、第 11 章「ホストされたドメインの設定」および 第 13 章「ホストされたドメインの管理」を参照してください。

calendar-name

特定のユーザーにとって一意となるカレンダの名前で、省略可能です。所有者のデフォルトカレンダは 1 つだけですが、さまざまな目的のほかのカレンダを所有することが可能です。このようなデフォルト以外の各カレンダは、カレンダ名によって識別されます。たとえば、ユーザー John Doe の uid が jdoe である場合、そのデフォルトカレンダは jdoe@sesta.com になります。たとえば、リトルリーグチームのコーチが試合の記録を取るために使用する 補助カレンダは、次の calid として識別されることもあります。jdoe@sesta.com:baseball

カレンダ ID の作成規則

calid を作成する場合、次の規則を念頭に置いてください。

ホストしていない Calid からホストされたドメイン形式の Calid への変換

ホストされたドメインを持つ前に作成された calid があり、ホストされていないドメインの calid からホストされたドメインの calid へ変換する場合、既存の calid にドメイン部分を追加するために使用できる csvdmig というユーティリティーがあります。このユーティリティーの使用方法については、「csvdmig」 を参照してください。

ユーザーカレンダの自動作成

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

カレンダ自動作成機能

Calendar Server は、ユーザーが最初にログインしたときにデフォルトのカレンダを自動的に作成します。この機能を自動プロビジョニングといいます。自動プロビジョニングはデフォルトで有効にされています。ただし、自動プロビジョニングはユーザーカレンダにのみ使用可能です。 リソースカレンダは明示的に作成する必要があります。

Calendar Server は、その名前のカレンダが存在しないかぎり、ユーザー ID からこの新しいデフォルトカレンダのカレンダ ID (calid) を作成します。

たとえば、ユーザー ID が jsmith の John Smith が初めて Calendar Server にログインするときに、Calendar Server は calid として jsmith が設定されたデフォルトカレンダを自動的に作成します。それ以降に John Smith が作成する各カレンダの calid は、カレンダ名の先頭に jsmith: が追加されます。たとえば、John Smith があとで meetings という名前の新しいカレンダを作成する場合、ホストしていない環境内の新しいカレンダの calid は jsmith:meetings です。

注 –

デフォルトカレンダを持たないユーザーが参加予定者として指定される場合、Calendar Server はカレンダが見つからないことを示すエラーを返します。

Procedure自動プロビジョニングを有効にするには

自動プロビジョニングはデフォルトで有効にされています。しかし、自動プロビジョニングを無効にしたあとに再び有効にする必要がある場合は、次の手順を実行します。

手順

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

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

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

  4. 次の表に示す、Calendar Server 設定ファイル ics.conf に含まれる 1 つ以上のパラメータを編集します。

    パラメータ 

    説明とデフォルト値 

    local.autoprovision

    “yes” に設定すると、ユーザーが最初にログインしたときにデフォルトのカレンダが自動的に作成されます。自動プロビジョニングはデフォルトで有効にされています。 

    この機能を無効にするには、値を “no” に設定します。 

  5. ユーザーの LDAP エントリがカレンダに対して有効になっていることを検証します。

    このエントリには、icsCalendarUser オブジェクトクラスが含まれている必要があります。ユーザーの LDAP エントリにクラスがない場合は、追加します。

  6. サイトでホストされたドメインを使用している場合、カレンダの自動プロビジョニングを有効にする前に、ユーザーのドメインでカレンダが有効にされている必要があります。ドメインエントリに icsCalendarDomain オブジェクトクラスが含まれている必要があります。

  7. ファイルを保存します。

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

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

手順

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

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

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

  4. 次の表に示す、Calendar Server 設定ファイル ics.conf に含まれる 1 つ以上のパラメータを編集します。

    パラメータ 

    説明とデフォルト値 

    local.autoprovision

    パラメータを no に設定すると、ユーザーカレンダの自動プロビジョニングが無効になります。

  5. ファイルを保存します。

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

    注 –

    自動プロビジョニングが無効の場合、正常にログインするためには、そのユーザーに対して明示的にカレンダが作成されている必要があります。

カレンダのアクセス制御

Calendar Server は、ACL (アクセス制御リスト) を使用して、カレンダ、カレンダプロパティー、予定や仕事 (作業) などのカレンダコンポーネントへのアクセスを制御します。

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

アクセス制御の設定パラメータ

次の表は、Calendar Server がアクセス制御に使用する、ics.conf ファイル内の設定パラメータを示しています。

表 15–1 アクセス制御の設定パラメータ

パラメータ 

説明 

calstore.calendar.default.acl

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

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

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

calstore.calendar.owner.acl

カレンダ所有者のデフォルトのアクセス制御設定を指定します。デフォルトは次のとおりです。 

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

resource.default.acl

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

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

@^a^rsf^g"

公開、非公開の予定と仕事、およびフィルタ

新しい予定または仕事を作成するときに、ユーザーは予定または仕事に公開、非公開、または時刻と日付のみの公開 (極秘) を指定できます。

公開

ユーザーのカレンダに対する読み取りアクセス権を持つ誰もが予定また は仕事を表示できます。

非公開

カレンダの所有者だけが予定または仕事を表示できます。

時刻と日付のみの公開

これらは極秘の予定および仕事です。カレンダの所有者は予定または仕事を表示できます。カレンダに対する読み取りアクセス権を持つユーザーがカレンダにア クセスすると、「タイトルなしの予定」とカレンダに表示されます。

Calendar Server フィルタが非公開の、および時刻と日付のみが公開される極秘の予定と仕事を認識できるかどうかは、calstore.filterprivateevents によって決定されます。このパラメータはデフォルトで "yes" に設定されます。calstore.filterprivateevents を "no" に設定すると、Calendar Server は、非公開の、および時刻と日付のみが公開される予定と仕事を、公開されているものと同様に扱います。

アクセス制御のためのコマンド行ユーティリティー

次の表は、アクセス制御用の ACL を設定または変更するための Calendar Server コマンド行ユーティリティーを示しています。

表 15–2 アクセス制御のためのコマンド行ユーティリティー

ユーティリティー 

説明 

cscal

特定のユーザーまたはリソースのカレンダの ACL を設定するときは、-a オプションを指定して create コマンドまたは modify コマンドを実行します。

csresource

Schema 1 モードで csresource を使用してリソースカレンダを作成している場合、リソースカレンダに ACL を設定するには、csresource ユーティリティーに -a オプションを指定して実行します。

commadmin ユーザー

csuser

Schema 2 の commadmin ユーティリティーを使用して、ユーザーがカレンダを作成するときに使用するデフォルト ACL を変更します。

ユーザーがカレンダを作成するときに使用するデフォルトACL を変更するには、Schema 1 の csuser ユーティリティーに -a オプションを指定して実行します。

注 –

Delegated Administrator コンソールでアクセス権限を設定する場合は、「組織のプロパティー」ページ (または「新しい組織を作成」ウィザード) で「拡張権限を設定」ボタンをクリックすると、コンソールから管理できるアクセス権限のリストが表示されます。

カレンダの作成

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

cscal を使用したユーザーカレンダの作成

新しいカレンダを作成するには、cscal ユーティリティーの create コマンドを使用します。ユーザーまたはリソースのエントリは、LDAP ディレクトリ内にすでに存在している必要があります。LDAP ディレクトリへのユーザーやリソースの追加については、第 14 章「ユーザーとリソースの管理」を参照してください。

サイトで LDAP カレンダ検索データベース (CLD) プラグインを使用している場合、ユーザーまたはリソースのエントリの icsDWPHost LDAP 属性で指定されているのと同じバックエンドサーバー上で特定のユーザーまたはリソースのすべてのカレンダを作成する必要があります。別のバックエンドサーバーにカレンダを作成しようとすると、cscal ユーティリティーはエラーを返します。LDAP CLD プラグインについては、第 6 章「複数のマシンへのカレンダデータベースの分散の設定」を参照してください。

たとえば、jsmith というカレンダ ID (calid) を持つカレンダを新規作成するには、次のように実行します。

cscal -o jsmith -n JohnSmithCalendar create jsmith

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

John Smith が所有する Hobbies という表示名のカレンダを作成し、グループスケジュール機能のアクセス制御設定を適用するには、次のように実行します。

cscal -n Hobbies -o jsmith create Personal

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

次の例は、前の例に似たカレンダを新規作成しますが、カレンダを sports というカテゴリに関連付け、複数のユーザーからの予約を有効にして Ron Jones というもう一人の所有者を指定します。

cscal -n Hobbies -o jsmith -g sports -k yes -y rjones create Personal

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

次の例は、前の例と似たカレンダを作成しますが、グループスケジュール機能のアクセス制御設定が適用されます。

cscal -n Hobbies -o jsmith -a "@@o^a^sfr^g" create Personal

ここで、-a "@@o^a^sfr^g" は、このカレンダのコンポーネントとカレンダの両方のプロパティーに対するグループスケジュール機能のスケジュール権限、空き/ 予定ありの設定権限、読み取りアクセス権限を、ほかの所有者に与えます。

リソースカレンダの作成準備

リソースカレンダは、スケジューリングが可能な会議室、ノートパソコン、OHP、その他の機器などに関連付けられます。リソースカレンダにはアクセス制御リストが必要です。

表 15–3 に示すように、ics.conf ファイルの 2 つの設定用パラメータがリソースカレンダに適用されます。

表 15–3 に示すように、これらのパラメータのデフォルト値を変更するには、ics.conf ファイルを編集します。デフォルト値の変更は、新しいリソースカレンダだけに適用されます。 既存のリソースの値は変更されません。

Schema 1 の場合は、Calendar Server ユーティリティー cscal を使用して、既存のリソースカレンダの値を変更します。csresource ユーティリティーには modify コマンドはありません。

Schema 2 の場合は、Delegated Administrator ユーティリティーコマンド commadmin resource modify を使用します。Delegated Administrator コンソールでは、カレンダリソースについてのこれらの値を変更することはできません。

注 –

Calendar Server の通知ソフトウェアは、リソースに通知を送信するようにプログラミングされていません。 通知を受け取るのはユーザーだけです。

表 15–3 ics.conf ファイルに指定できるリソースカレンダの設定パラメータ

パラメータ 

説明とデフォルト値 

resource.default.acl

このパラメータには、リソースカレンダの作成時にデフォルトで適用されるアクセス制御設定を特定します。デフォルトのアクセス許可は、次の ACL (アクセス制御リスト) によって指定されます。 

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

この ACL は、コンポーネントとプロパティーの両方に対する読み取り、スケジュール、空き/予定ありの設定アクセス権をすべてのカレンダユーザーに付与します。 

リソースに対するアクセス権を変更するには、csresource ユーティリティーの create コマンドを使用してカレンダを作成するときに -a オプションを指定します。

resource.allow.doublebook

このパラメータには、リソースカレンダが複数のユーザーからの予約を許可するかどうかを指定します。複数のユーザーからの予約が許可される場合、リソースカレンダでは同時に複数の予定をスケジュールできます。 

デフォルトは "no"— で、複数のユーザーからの予約は許可されません。

リソースカレンダの複数のユーザーからの予約を許可するには、csresource ユーティリティーの create コマンドを使用してカレンダを作成するときに -k オプションを指定します。

新しいリソースカレンダの作成

Calendar Server では、リソースカレンダの自動プロビジョニングはサポートしていません。サイトに必要なリソースごとに、次の方法を使用する必要があります。

注 –

リソースの LDAP エントリがすでに存在する場合、csresource ではカレンダのみが作成されます。LDAP エントリは重複して作成されません。

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

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

csresource については、付録 D 「Calendar Server のコマンド行ユーティリティーのリファレンス」 を参照してください。

リソースカレンダでの複数のユーザーからの予約の許可

デフォルトでは、Calendar Server はリソースカレンダでの複数のユーザーからの予約 (resource.allow.doublebook パラメータ) を許可しません。このデフォルト設定は、部屋や装置などのリソースで予定の競合が生じることを防ぎます。ただし、リソースカレンダでの複数のユーザーからの予約を可能にするには、カレンダの作成時に csresource -k オプションを “yes” に設定します。

次のコマンドは、リソースの LDAP エントリとカレンダを作成しますが、-k オプションによってカレンダでの複数のユーザーからの予約が許可され、-o オプションによってカレンダの 所有者が bkamdar に設定されます。また、-y オプションによってもう一人の所有者が jsmith に設定されます。

csresource -m aud100@siroe.com -c aud100 -k yes
    -o bkamdar -y jsmith create Auditorium

リソースカレンダに対するアクセスの制限

特定のリソースの予定を指定できるユーザーを制御するには、リソースカレンダに対して書き込みアクセス権を持つユーザーを制限してください。たとえば、会議室の予定設定や機器の使用予約を特定のユーザーに限定することができます。

リソースカレンダの所有者を指定しない場合、ics.conf ファイルの service.admin.calmaster.userid パラメータの値が適用されます。

ユーザーカレンダの管理

ユーザーカレンダの作成が完了すると、「cscal」 ユーティリティーを使用して次の管理作業を実行できます。

カレンダを表示するには

すべてのカレンダ、あるユーザーが所有するすべてのカレンダ、または特定のカレンダのプロパティーを表示するには、cscal ユーティリティーの list コマンドを使用します。

たとえば、カレンダデータベース内のすべてのカレンダを表示するには、次のように実行します。

cscal list

jsmith が所有するすべてのカレンダを表示するには、次のように実行します。

cscal -o jsmith list

カレンダ ID が jsmith:meetings のカレンダのすべてのプロパティーを表示するには、次のように実行します。

cscal -v list jsmith:meetings

カレンダを削除するには

Calendar Server から 1 つ以上のカレンダを削除するには、cscal ユーティリティーの delete コマンドを使用します。このユーティリティーはカレンダを削除しますが、ディレクトリサーバーからユーザーを削除することはありません。

注意 – 注意 –

delete コマンドはすべてのカレンダ情報をカレンダデータベースから削除します。実行した処理を取り消すことはできません。カレンダを削除すると、それを復元できるのはカレンダデータがバックアップされている場合だけです。詳細は、第 17 章「Calendar Server データのバックアップと復元」を参照してください。

cscal ユーティリティーを使用して、1 つのカレンダまたは複数のカレンダを削除できます。

たとえば、jsmith:meetings というカレンダ ID を持つカレンダを削除するには、次のように実行します。

cscal delete jsmith:meetings

一次所有者が jsmith のすべてのカレンダを削除するには、次のように実行します。

cscal -o jsmith delete

削除されたユーザーのカレンダを消去するには

Calendar Server Utility コマンド csuser delete、あるいは Delegated Administrator Console または Utility を使用して 1 つ以上のユーザーを削除した場合、そのユーザーが所有していたカレンダがまだデータベース内に存在している可能性があります。

ユーザーのカレンダを消去するには、次の 2 つの方法があります。使用する方法は、ユーザーを削除するのに使用したツールにより異なります。

csuser

csuser ユーティリティーは、LDAP ディレクトリからユーザーを消去して、ユーザーのデフォルトのカレンダを消去しますが、ユーザーが所有していたその他のカレンダは消去しません。cscal を使用してこれらのカレンダを消去する方法については、「csuser を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。

Delegated Administrator

Delegated Administrator はカレンダを消去しません。Delegated Administrator を使用して削除するユーザーをマークし、Calendar Server Utility の csclean を使用してマークしたユーザーのカレンダを消去します。

csclean を使用して削除されたユーザーのカレンダを消去する方法については、「Delegated Administrator を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。

Delegated Administrator Utility の使用方法については、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。

Delegated Administrator Console の使用方法については、オンラインヘルプを参照してください。

Procedurecsuser を使用して削除されたユーザーのすべてのカレンダを消去するには

手順

  1. 削除された所有者の uid のすべてのカレンダを検索するには、cscal list を実行します。

    cscal -o owner list

  2. 所有者のすべてのカレンダを消去するには、cscal を使用します。

    cscal -o owner delete

  3. csuser list を再実行して、すべてのカレンダが消去されていることを確認します。

    注 –

    commadmin を使用してユーザーを「削除」としてマークし、ユーザーの LDAP エントリが削除されている場合は、この手順を使用します。

ProcedureDelegated Administrator を使用して削除されたユーザーのすべてのカレンダを消去するには

Delegated Administrator はカレンダを消去しません。Delegated Administrator によって「削除」とマークされたユーザーのすべてのカレンダを消去するには、csclean ユーティリティーを使用します。

手順

  1. csclean を使用して、「削除」とマークされているがまだ削除されていないユーザーのすべてのカレンダを消去します。

    たとえば、過去 10 日間で sesta.com ドメ イン内の「削除」とマークされたユーザーのすべてのカレンダを消去するには、次の コマンドを実行します。

    csclean -g 10 clean sesta.com

  2. ユーザーが LDAP から削除されている場合は、cscal を使用してください。

    手順については、「csuser を使用して削除されたユーザーのすべてのカレンダを消去するには」を参照してください。

カレンダを有効にするには

カレンダを有効化してユーザーがカレンダにアクセスできるようにするときは、cscal ユーティリティーの enable コマンドを使用します。

たとえば、デフォルト設定を適用した jsmith:meetings カレンダを有効化するには、次のように実行します。

cscal enable jsmith:meetings

jsmith:meetings カレンダを有効化し、複数のユーザーからの予約を禁止するには、次のように実行します。

cscal -k no enable jsmith:meetings

カレンダを無効にするには

ユーザーがカレンダにアクセスできないようにするには、cscal ユーティリティーの disable コマンドを使用します。disable コマンドはユーザーによるカレンダへのアクセスを禁止しますが、カレンダデータベースから情報を削除するわけではありません。

たとえば、ユーザーが jsmith:meetings にアクセスできないようにするには、次のように実行します。

cscal disable jsmith:meetings

カレンダプロパティーを変更するには

カレンダのプロパティーを変更するには、cscal ユーティリティーの modify コマンドを使用します。

たとえば、AllAdmins のグループスケジュール機能のアクセス制御設定を変更し、もう一人の所有者として RJones を指定するには、次のように実行します。

cscal -a "@@o^c^wd^g" -y RJones modify AllAdmins

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

カレンダからプロパティーを消去するには

カレンダからプロパティー値を消去するには、cscal ユーティリティーの modify コマンドを使用し、オプションの値を 2 つの二重引用符 ("") で指定することで対象となるオプションを指定します。

たとえば、jsmith:meetings から説明を消去するには、次のように実行します。

cscal -d "" modify jsmith:meetings

jsmith:meetings からすべてのカテゴリを消去するには、次のように実行します。

cscal -g "" modify jsmith:meetings

jsmith:meetings からその他の所有者を消去するには、次のように実行します。

cscal -y "" modify jsmith:meetings

「失われた」デフォルトカレンダを復元するには

ユーザーのデフォルトカレンダが Communications Express の「現在のカレンダ」ドロップダウンリストには表示されないが、データベースには存在する場合、ユーザーの LDAP エントリの次の属性を更新することで、カレンダを復元できます。

ここで、default_calid はユーザーのデフォルトカレンダの ID (calid) です。

Schema 2 の場合は、次のいずれかの方法を使用して属性を更新します。

Schema 1 の場合は、csattribute add コマンドを使用して属性を更新できます。

Procedureユーザーカレンダを別のバックエンドサーバーへ移動するには

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

手順

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


    csuser disable bkamdar

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


    csexport -c bkamdar calendar bkamdar.ics

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

  4. 新しいサーバーで、エクスポートされた各カレンダに対して、「csimport」 ユーティリティーを実行してファイルからカレンダデータベースにカレンダをインポートします。次に例を示します。


    csimport -c bkamdar calendar bkamdar.ics

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


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

  6. 新しいサーバーで、「csuser」 ユーティリティーを使用してユーザーカレンダのカレンダユーザーを有効にします。次に例を示します。


    csuser enable bkamdar

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


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

  8. 元のサーバーで、移動した各カレンダを削除します。次に例を示します。


    cscal -o bkamdar delete bkamdar

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

    注 –

    CLD キャッシュオプションを使用している場合、カレンダを別のバックエンドサーバーに移動した後に、CLD キャッシュをクリアしてサーバー名を消去してください。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが移動後のカレンダを見つけられなくなります。CLD キャッシュをクリアするには、次の手順を実行します。

    • Calendar Server を停止します。

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

    • Calendar Server を再起動します。

リソースカレンダの管理

リソースカレンダの作成後は、csresource ユーティリティーを使用して管理します。リソースカレンダを管理する手順は次のとおりです。

リソースカレンダおよび属性を表示するには

リソースカレンダを表示するには、csresource ユーティリティーの list コマンドを使用します。

たとえば、Calendar Server のすべてのリソースカレンダと、それに対応する LDAP 属性を表示するには、次のように実行します。

csresource list

Auditorium という特定のリソースカレンダのすべての LDAP 属性を表示するには、次のように実行します。

csresource -v list Auditorium

リソースカレンダを変更するには

リソースカレンダを変更するには、「cscal」 ユーティリティーの modify コマンドを使用します。csresource には modify コマンドはありません。

たとえば、Auditorium というリソースカレンダに所有者として tchang を設定し、もう一人の所有者として mwong を設定するには、次のように実行します。

cscal -o tchang -y mwong modify aud100

この例では、cscal ユーティリティーはカレンダ名 (Auditorium) ではなく、calid (aud100) を必要とします。

リソースカレンダを無効または有効にするには

ユーザーが予定をスケジュール設定できないようにするには、リソースカレンダを無効化する必要があります。たとえば、改修中で会議室を利用できない場合や、OHP が修理中の場合などがこれに該当します。

リソースカレンダの無効化と有効化には、csresource ユーティリティーの enable コマンドまたは disable コマンドを使用します。

たとえば、Auditorium というリソースカレンダを無効化するには、次のように実行します。

csresource disable Auditorium

あとからリソースカレンダを有効な状態に戻すには、次のように実行します。

csresource enable Auditorium

リソースカレンダを削除するには

リソースカレンダを削除するには、csresource ユーティリティーの delete コマンドを使用します。

たとえば、Auditorium というリソースカレンダを削除するには、次のように実行します。

csresource delete Auditorium

Calendar Server は次のメッセージを表示します。

Do you really want to delete this resource (y/n)?

カレンダを削除するときは「y」を入力し、処理をキャンセルするときは「n」を入力します。

「y」を入力すると、Calendar Server はカレンダを削除し、削除が完了したことを示すメッセージを表示します。

Procedureリソースカレンダを別のバックエンドサーバーへ移動するには

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

手順

  1. 元のサーバーで、「csresource」 ユーティリティーを実行してカレンダリソースを無効にします。たとえば、Auditorium という共通名を持つリソースを無効化するには、次のように実行します。


    csresource disable Auditorium

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


    csexport -c aud100 calendar aud100.ics

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

  4. 新しいサーバーで、エクスポートされた各カレンダに対して、「csimport」 ユーティリティーを実行してファイルからカレンダデータベースにカレンダをインポートします。次に例を示します。


    csimport -c bkamdar calendar bkamdar.ics

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


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

  6. 新しいサーバーで、「csresource」 ユーティリティーを実行してカレンダリソースを有効にします。次に例を示します。


    csresource enable bkamdar

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


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

  8. 元のサーバーで、移動した各カレンダを削除します。次に例を示します。


    cscal -o bkamdar delete bkamdar

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

    注 –

    CLD キャッシュオプションを使用していて、カレンダを別のバックエンドサーバーに移動した場合は、CLD キャッシュをクリアしてサーバー名を消去するとよいでしょう。CLD キャッシュに古いエントリが残されていると、フロントエンドサーバーが移動後のカレンダを見つけられなくなります。CLD キャッシュをクリアするには、次の手順を実行します。

    • Calendar Server を停止します。

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

    • Calendar Server を再起動します。

カレンダへのリンク設定

各カレンダに対する読み取りアクセスが許可されている場合は、1 つ以上のユーザーカレンダまたはリソースカレンダへのリンクを作成することができます。たとえば、カレンダへのリンクを Web ページや電子メールメッセージに埋め込むことができます。その他のユーザーは、Calendar Server にアクセスすることなく匿名でカレンダを表示できます。

1 つ以上のユーザーカレンダへのリンクを作成するには、次の構文を使用します。

http://CommunicationsExpresshostname:
CommunicationsExpressport/uwc/
   ?calid=calid-1[; ... ;calid-n]

複数のカレンダ ID (calid) を区切るときは、セミコロン (;) を使用します。

たとえば、jsmith@sesta.com および jdoe@siroe.com のデフォルトカレンダへのリンクは、次のようになります。

http://calendar.sesta.com:8080/?calid=jsmith@sesta;jdoe@siroe.com

calid が overhead_projector10 の OHP のリソースカレンダへのリンクは、次のようになります。

http://calendar.sesta.com:8080/uwc/?calid=overhead_projector10

カレンダデータのインポートとエクスポート

カレンダデータをファイルにエクスポートしたり、ファイルからインポートしたりするには、csexport ユーティリティーと csimport ユーティリティーを使用します。サポートされているカレンダデータの形式は、iCalendar (.ics) と XML (.xml) です。

csexport と csimport は、Calendar Server がインストールされているマシンでローカルに実行する必要があります。Calendar Server は稼動中でも停止していてもかまいません。

カレンダデータのインポート

csexport ユーティリティーを使用して作成したファイルからカレンダデータをインポートするときは、csimport を使用します。保存されているインポートファイルの形式は、そのファイルの拡張子 (.ics または .xml) で示されます。

たとえば、カレンダ ID (calid) が jsmithcal のカレンダに iCalendar 形式 (text/calendar MIME) で保存された jsmith.ics というファイルからデータをインポートするには、次のように実行します。

csimport -c jsmithcal calendar jsmith.ics

この jsmithcal カレンダに XML 形式 (text/xml MIME) で保存された jsmith.xml というファイルからデータをインポートするには、次のように実行します。

csimport -c jsmithcal calendar jsmith.xml

カレンダデータのエクスポート

カレンダデータをファイルにエクスポートするときは、csexport を使用します。ファイルの形式は、出力ファイルに指定する拡張子 (.ics または .xml) によって決定されます。

たとえば、カレンダ ID (calid) が jsmithcal のカレンダを iCalendar 形式 (text/calendar MIME) の jsmith.ics というファイルにエクスポートするには、次のように実行します。

csexport -c jsmithcal calendar jsmith.ics

この jsmithcal カレンダを XML 形式 (text/xml MIME) の jsmith.xml というファイルにエクスポートするには、次のように実行します。

csexport -c jsmithcal calendar jsmith.xml