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

第 14 章 ユーザーとリソースの管理

この章では、ユーザーとリソースの管理のための Calendar Server ユーティリティーの使用方法について説明します。この章で説明する内容は次のとおりです。

ユーザー管理ツール

次のいずれかのユーザー管理ツールを使用して、カレンダのユーザーとリソースを管理できます。


注 –

Delegated Administrator はカレンダを管理しません。ユーザーとリソースのカレンダを作成するには、Calendar Server ユーティリティーを使用します。



注 –

Schema 2 および Delegated Administrator を使用している場合でも、Calendar Server コマンド行ユーティリティーを使用して特別な機能を実行する必要がある場合もあります。このような場合には、どのユーティリティーを使用すればよいか、作業指向のこのマニュアルの記述を参照してください。


ユーザーとリソースの作成

ここでは、Calendar Server の新規ユーザーとリソースの管理に関する次の情報について説明します。

Schema 2 の新規ユーザーを作成するには

Delegated Administrator コンソールまたはユーティリティーのいずれかを使用できます。

Schema 1 の新規ユーザーを作成するには

csuser ユーティリティーを使用します。たとえば、ユーザー jdoesesta.com ドメインに追加するには、次のように実行します。

csuser -m jdoe@sesta.com -d sesta.com create jdoe

Schema 2 の新規リソースを作成するには

Delegated Administrator コンソールまたはユーティリティーのどちらも使用できます。

Schema 1 の新規リソースを作成するには

csresource ユーティリティーを使用して、LDAP エントリとリソースカレンダの両方を作成します。たとえば、プロジェクタ P101 を追加するには、次のコマンドを使用します。

csresource -m p101@siroe.com -c p101 create Projector_101

csresource については、「csresource」を参照してください。

必須の mail 属性を追加するには

Calendar Server では、ユーザーおよびリソースに、ユーザーまたはリソースの電子メールアドレスを含む mail 属性が指定されていることが必要です。この属性を指定することにより、電子メールアドレスまたは calid を使用してカレンダやリソースの検索を実行できます。Delegated Administrator を使用して新規ユーザーを作成すると、mail 属性が自動的に追加されます。この処理は、そのユーザーにメールサービスが割り当てられていない場合でも実行されます。


注 –

Calendar Server では、リソースカレンダの電子メール通知をサポートしていません。

mail 属性を追加しても、ユーザーカレンダの電子メール通知は有効になりません。

ユーザーカレンダの電子メール通知を有効にするには、ユーザーの LDAP エントリに次の 2 つの属性を追加します。

icsExtendedUserPrefs:ceNotifyEnable=1 
icsExtendedUserPrefs:ceNotifyEmail=jdoe@sesta.com

以前のバージョンの Calendar Server (mail 属性が必要ではなかったバージョン) でユーザーおよびリソースを追加している場合、既存のユーザーおよびリソース LDAP エントリへの mail 属性の追加が必要になる場合があります。

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

mail 属性が設定されているかどうかをチェックするには

属性が設定されているかどうかをチェックするには、-v (verbose、詳細出力) オプションを指定して csattribute list コマンドを実行します。

csattribute -v list Room100

出力により mail 属性が設定されているかどうかがわかります。

cn=Room 100,ou=conferenceRooms,dc=sesta,dc=com
 has mail: Room100@sesta.com

mail 属性を既存のユーザーおよびリソースに追加するには

既存のユーザーおよびリソースに mail 属性を追加するには、次のいずれかの方法を使用します。

ユーザーの管理

ユーザーの作成が完了すると、csuser ユーティリティーを使用して次の管理作業を実行できます。

ユーザー情報を表示するには

すべてのカレンダユーザーを一覧表示したり、特定ユーザーのカレンダ属性を表示したりするときは、csuser ユーティリティーの list コマンドを使用します。

たとえば、カレンダ機能が有効なすべてのユーザーを表示するには、次のように実行します。

csuser list

jsmith という単一ユーザーのすべてのカレンダ属性を表示するには、次のように実行します。

csuser -v list jsmith

ユーザーを無効にするには

ユーザーを無効にする目的は、ユーザーが Calendar Server にログインできないようにすることです。この処理方法は、どのユーザー管理ツールを使用してユーザーを作成したかによって異なります。Delegated Administrator コンソールで作成したユーザーは、その管理にもこのツールを使用するようにしてください。同様に、Delegated Administrator ユーティリティーを使用してユーザーにカレンダサービスを割り当てた場合は、サービスを削除する場合もこのツールを使用します。最後に、ホストされていないドメイン環境にあるユーザーは、Calendar Server ユーティリティーだけを使用して管理するようにしてください。各ツールにより、少し処理が異なります。

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

Delegated Administrator コンソール

Delegated Administrator コンソールで、「ユーザー」一覧ページからユーザーを選択します。このユーザーのプロパティーで、カレンダサービスを含むサービスパッケージを削除します。これにより、このユーザーがカレンダに対して無効になり、ユーザーの icsStatusinactive に設定されます。


注 –

パッケージにその他のサービスも含まれている場合は、カレンダが含まれていない別のパッケージを使用して、これらのサービスを再度割り当てる必要があります。


Delegated Administrator ユーティリティー (commadmin user delete)

ユーザーがカレンダサービスにアクセスできないようにするには、次の例に示すように、ユーザーの LDAP エントリからサービスを削除します。

commadmin user delete jsmith -S cal

これにより、LDAP エントリを完全に削除することなく、このユーザーがカレンダに対して無効になります。さらに、このコマンドによって、ユーザーの icsStatusinactive に変更されます。

Calendar Server ユーティリティー (csuser disable)

disable コマンドにより、ユーザーはカレンダデータにアクセスできなくなりますが、そのユーザーの情報は LDAP エントリや Calendar Server データベースから削除されません。このコマンドによって、icsStatus 属性が active から inactive に変更されます。ホストされていないドメインモードには、カレンダサービスのようなものは存在しません。

たとえば、jsmith による Calendar Server へのアクセスを無効にするには、次のように実行します。

csuser disable jsmith

ただし、jsmith が現在 Calendar Server にログインしている場合は、ログオフするまで jsmith はカレンダデータへのアクセスを維持できます。

ユーザーを有効にするには

ユーザーを有効にするには、次のいずれかのユーティリティーを使用します。

Delegated Administrator コンソール

新規ユーザーと既存のユーザーの両方を有効にすることができます。

Delegated Administrator (commadmin user create)

ユーザーを作成する場合は、次の例に示すように、カレンダサービスに対してそのユーザーを有効にします。

commadmin user create jsmith -S cal

ユーザーの作成時に、カレンダサービスに対してユーザーを有効にしていない場合は、次の例に示すように、modify コマンドを使用して、あとでカレンダサービスをユーザーに追加できます。

commadmin user modify jsmith -S cal

Calendar Server ユーティリティー (csuser enable)

ユーザーエントリの作成時に csuser create を使用した場合、ユーザーは自動的に有効になります。

ユーザーが、カレンダ機能が有効でない別のユーザー (つまり、デフォルトカレンダを持たないユーザー) に要求を送信すると、Calendar Server はカレンダが見つからないことを示すエラーを送信元ユーザーに返します。

電子メールのエイリアスを設定するには

カレンダユーザー用の電子メールのエイリアスを設定する必要がある場合は、そのユーザーの LDAP エントリに mailalternateaddress 属性を追加します。mail 属性は主要メールアドレスを提供し、mailalternateaddress 属性は電子メールのエイリアスに使用されます。どちらの属性も、メールアドレスをユーザーのカレンダ ID (calid) にマッピングします。

この属性を追加するには、Calendar Server ユーティリティーの csattribute を使用するか、または ldapmodify で直接 LDAP を更新します。次の例では、csattribute を使用しています。


注 –

これらの変更を有効にするには、エイリアスのテーブルまたは設定の再構築が必要となる場合があります。Messaging Server (または使用するその他の電子メール製品) のマニュアル、およびメールサービスの変更に関するサイト固有のドキュメントおよび手順を参照してください。Messaging Server のマニュアルは、次の Web サイトで入手できます。http://docs.sun.com/coll/1312.1



例 14–1 csattribute を使用した電子メールのエイリアスの追加

たとえば、JohnSmith という名前のユーザーに対して、以下の値を持つ mailalternateaddress 属性を追加するには次のようにします。

csattribute -a mailalternateaddress=johns@sesta.com add johnsmith
 csattribute -a mailalternateaddress=jsmith@sesta.com add johnsmith

ユーザーのカレンダ機能の有効性を確認するには

ディレクトリサーバーに特定のユーザーが存在し、そのユーザーが Calendar Server のデータにアクセスできるかどうかを調べるには、csuser ユーティリティーの check コマンドを使用します。

たとえば、jsmith のカレンダ機能が有効であるかどうかを調べるには、次のように実行します。

csuser check jsmith

check コマンドによって、ユーザーが LDAP ディレクトリサーバーに存在しないことが検出された場合は、そのユーザーのディレクトリサーバーエントリを作成する必要があります。

LDAP からユーザーを削除するには

ユーザーをホストドメインまたはホストされていないドメインのどちらから削除するかに応じて異なるツールを使用します。


注意 – 注意 –

undelete コマンドはありません。

Delegated Administrator を使用してホストドメイン内のユーザーを削除したら、これらのユーザーは破棄して、最初から再度追加する必要があります。破棄されるまで、ユーザー名は再利用できません。

ホストされていないドメインについては、「ホストされていないドメインの場合のみ: 削除のマークは付いているが破棄されていないユーザーの削除取消し」を参照してください。


ProcedureDelegated Administrator を使用した Schema 2 でのユーザーの削除

Delegated Administrator のどちらのインタフェースでも、ユーザーに削除のマークを付けることができます。ただし、Delegated Administrator コンソールでは LDAP からユーザーを破棄できません。破棄するためには Delegated Administrator ユーティリティーを使用する必要があります。次の作業一覧は、LDAP からユーザーを削除するための手順を示しています。ユーザーは、最後の手順を完了するまで LDAP から実際には削除されません。

手順
  1. ユーザーエントリに削除のマークを付けます。

    Delegated Administrator コンソールの場合: 「ユーザー」一覧ページで、削除するユーザーを選択し、「削除」をクリックします。

    Delegated Administrator ユーティリティーの場合: commadmin user delete コマンドを使用します。次に例を示します。

    commadmin user delete -D chris -n siroe.com 
    -w bolton -l jsmith

    どちらの場合も、ユーザー LDAP エントリ内の icsStatus 属性が active から deleted に変更されます。

  2. 次の例に示すように、Calendar Server ユーティリティーの csclean を使用して、特定のドメインまたはすべてのドメインの削除したすべてのユーザーに属するすべてのカレンダを削除します。

    csclean clean “*”

    または、あるドメインの削除したすべてのユーザーに属するカレンダを削除するには、次の例に示すように実際のドメインを指定します。csclean clean sesta.com


    ヒント –

    ユーザーのカレンダを削除する前に LDAP からユーザーを誤って破棄した場合は、「ユーザーカレンダの管理」で説明されている cscal ユーティリティーを使用して、あとでカレンダを削除することができます。


  3. Delegated Administrator ユーティリティーのコマンド commadmin domain purge を使用して、削除のマークが付けられているすべてのユーザーのドメインを破棄します。

    次に例を示します。

    commadmin domain purge -D chris -d sesta.com -n siroe.com -w bolton

    この例では、sesta.com の削除のマークが付けられているすべてのユーザーが永久に削除されます。


    ヒント –

    ときどき、このユーティリティーを手動で実行し、LDAP ディレクトリをクリーンアップします。このコマンドについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。


Schema 1 環境でのユーザーの削除

指定されたユーザーの LDAP エントリとそのユーザーのデフォルトカレンダを削除するには、Calendar Server ユーティリティーの csuser delete コマンドを使用します。

たとえば、ユーザー jsmith の LDAP エントリおよびデフォルトカレンダを削除するには、次のコマンドを使用します。

csuser delete jsmith

このユーザーに属するその他のカレンダを削除する場合は、「ユーザーカレンダの管理」の説明に従って cscal を使用する必要があります。

ホストされていないドメインの場合のみ: 削除のマークは付いているが破棄されていないユーザーの削除取消し

ホストされていないドメインの場合は、削除のマークは付いているがまだ破棄されていないユーザーの削除を取り消すために、そのユーザーの icsStatus 属性を active にリセットすることが必要です。これを実行するには、ldapmodify を使用して直接 LDAP エントリを変更するか、または Calendar Server ユーティリティーの csattribute を使用します。

ただし、ホストされていないドメインでユーザーを破棄した後は、LDAP サーバー情報をバックアップから復元することしかできません。

ユーザーの属性をリセットするには

特定のユーザーのすべてのカレンダ LDAP 属性をデフォルトの設定に戻すには、csuser ユーティリティーの reset コマンドを使用します。

たとえば、jsmith のすべてのカレンダ属性をデフォルトの設定に戻すには、次のように実行します。

csuser reset jsmith

注 –

カレンダユーザーをリセットすると、icsCalendarUser (オブジェクトクラス)、icsSubscribedicsCalendarOwnedicsCalendaricsDWPHost (LDAP CLD が設定されている場合) を含むすべてのカレンダ属性がユーザーの LDAP エントリから消去されます。Calendar Server 管理者がユーザーに代わってカレンダを作成することはできません。

次の場合に、ユーザーの LDAP エントリにこれらの属性が復元されます。


ユーザー名を変更するには

1 つ以上のユーザー ID を変更する必要がある場合は、csrename ユーティリティーを実行します。このユーティリティーは、次の手順で実行します。


注 –

1 つのユーザー ID だけを変更する場合でも、データベース全体が書き換えられることに注意してください。そのため、これは実行するには「労力の多い」ユーティリティーです。

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


Procedureユーザーが書き込み可能な公開カレンダを所有するのを禁止するには

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

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

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

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

    パラメータ 

    説明とデフォルト値 

    service.wcap.

    allowpublicwritablecalendars

    ユーザーが書き込み可能な公開カレンダを所有できるようにします。これは、デフォルトで有効になっています (“yes” に設定されている)。

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

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

    cal_svr_base /SUNWics5/cal/sbin/start-cal

リソースの管理

リソースを追加したら、csresource を使用して次のように管理できます。

Procedureリソースをリスト表示するには

手順
  1. sbin ディレクトリに移動します。

  2. 1 つまたはすべてのリソースをリスト表示するには、csresource list コマンドを使用します。

    たとえば、すべてのリソースについてすべての情報をリスト表示するには、次のように実行します。

    ./csresource -v list

Procedureリソースを有効にするには

手順
  1. sbin ディレクトリに移動します。

  2. 1 つまたはすべてのリソースを有効にするには、csresource enable コマンドを使用します。

    たとえば、ConfRm12 というリソースを有効にするには、次のように実行します。

    ./csresource -v enable ConfRm12

Procedureリソースを無効にするには

手順
  1. sbin ディレクトリに移動します。

  2. 1 つ以上のリソースを無効にするには、csresource disable コマンドを使用します。たとえば、ConfRm12 というリソースを無効にするには、次のように実行します。

    ./csresource -v disable ConfRm12

Procedureリソースを削除するには

手順
  1. sbin ディレクトリに移動します。

  2. 1 つ以上のリソースを削除するには、csresource delete コマンドを使用します。たとえば、ConfRm12 というリソースを削除するには、次のように実行します。

    ./csresource -v delete ConfRm12

リソース電子メール用の Bitbucket チャネルを設定するには

ここでは、Messaging Server および Sendmail 用の bitbucket チャネルの設定方法について説明します。bitbucket チャネルは、リソースカレンダ用に生成された電子メールを破棄する方法の 1 つです。次の例では、sesta.com サーバー上の Room100 というリソースを使用しています。bitbucket チャネル (または同等機能) を設定しない場合は、リソースカレンダに送信される電子メールメッセージを定期的に削除する必要があります。

ここで説明する手順は次のとおりです。

ProcedureMessaging Server の Bitbucket チャネルを設定するには

手順
  1. imta.cnf ファイルに bitbucket チャネルが定義されていることを確認します。

  2. メッセージの送信先を bitbucket チャネルに設定するには、csattribute ユーティリティーを使用してリソースの電子メールアドレスを作成します。


    csattribute -a mail=Room100@bitbucket.sesta.com add Room100

ProcedureSendmail Bitbucket チャネルを設定するには

手順
  1. 適切なホストの /etc/aliases ファイルに次のようなエントリを追加します。


    Resource/Conference room aliases
     Room100: /dev/null
  2. csattribute ユーティリティーを使用して、リソースの電子メールアドレスを LDAP ディレクトリに追加します。


    csattribute -a mail=Room100@sesta.com add Room100

ユーザーおよびリソース LDAP 属性の管理

Calendar Server が使用する LDAP 属性の管理には、「csattribute」ユーティリティー、または ldapmodify を使用します。csattribute を使用すると、属性をリスト表示、追加、または削除できます。属性を変更するには、ldapmodify を使用します。ここで説明する内容は次のとおりです。

ProcedureLDAP エントリの属性をリスト表示するには

手順
  1. インストール時に指定した Calendar Server の実行ユーザーまたはグループ (icsusericsgroup など)、または root としてログインします。

  2. sbin ディレクトリに移動します。

  3. ユーザーまたはリソースの属性をリスト表示するには、csattribute list コマンドを使用します。たとえば、ドメイン tchang@sesta.com の属性をリスト表示するには、次のコマンドを実行します。

    ./csattribute -t user -d sesta.com list tchang

ProcedureLDAP エントリの属性を追加するには

手順
  1. インストール時に指定した Calendar Server の実行ユーザーまたはグループ (icsusericsgroup など)、または root としてログインします。

  2. この属性の変更をすぐに認識されるようにする場合は、Calendar Server を停止します。そうでない場合は、Calendar Server を停止する必要はありません。

  3. sbin ディレクトリに移動します。

  4. ユーザーまたはリソースに属性を追加するには、csattribute add コマンドを使用します。たとえば、Conference_Schedule という値を持つ LDAP 属性 icsCalendartchang というユーザーに追加するには、次のように実行します。

    ./csattribute -a icsCalendar=Conference_Schedule add tchang@sesta.com

ProcedureLDAP エントリの属性を削除するには

手順
  1. インストール時に指定した Calendar Server の実行ユーザーまたはグループ (icsusericsgroup など)、または root としてログインします。

  2. この属性の変更をすぐに認識されるようにする場合は、Calendar Server を停止します。そうでない場合は、Calendar Server を停止する必要はありません。

  3. sbin ディレクトリに移動します。

  4. ユーザーまたはリソースから属性を削除するには、csattribute delete コマンドを使用します。たとえば、Conference_Schedule という値を持つ LDAP 属性 icsCalendartchang というユーザーから削除するには、次のように実行します。

    ./csattribute -a icsCalendar=Conference_Schedule -t user 
       -d sesta.com delete tchang

LDAP エントリの属性を変更するには

LDAP エントリの属性を変更するには、ldapmodify を使用します。たとえば、uid=tchang という値を持つユーザーの状態を変更するには、次に示すように ldapmodify を使用します。


dn:uid=tchang,ou=people,o=sesta.com
 changetype: modify
 add: objectclass
 objectClass: icsCalendarUser
 add: icsStatus
 icsStatus: active

注 –

サイトで LDAP CLD プラグインを使用している場合は、csattribute を使用して icsDWPHost の値を変更することにより、あるバックエンドホストから別のバックエンドホストにユーザーのカレンダを移動しようとすることは避けてください。icsDWPHost を変更しても、カレンダは新しいバックエンドホストに移動されません。バックエンドサーバー間でカレンダを移動する方法については、「ユーザーカレンダの管理」を参照してください。