Sun JavaTM System Calendar Server 6 2005Q4 (Calendar Server) は、企業やサービスプロバイダのカレンダおよびスケジュール管理を集中化するためのスケーラブルな Web ベースのソリューションです。Calendar Server は、個人およびグループの予定や作業のカレンダ機能に加え、会議室や機器などのリソースのカレンダ機能をサポートします。
基本設定のシナリオについては、『Sun Java System Communications Services 6 2005Q4 Deployment Planning Guide』を参照してください。
この章では、次の項目について説明します。
この章と以降の章で、完全修飾のディレクトリパスが指定された場合、そのパスは Solaris プラットフォームのディレクトリパスを示します。Solaris のデフォルトパスは次のとおりです。
/opt/SUNWics5/cal
/var/opt/SUNWics5
/etc/opt/SUNWics5
Linux® のデフォルトパスは次のとおりです。
/opt/sun/calendar
/var/opt/sun/
/etc/opt/sun
Linux ユーザーは、Solaris のデフォルトとして表示されているどのコマンドも Linux のデフォルトパスに置き換える必要があります。
Calendar Server のインストールおよび設定は、従来の Calendar Server リリース (2003Q4 以前のバージョン) から大幅に変更されています。Calendar Server 単独のインストーラはなくなりました。
Calendar Server 2003Q4 (6.0) 以降のバージョンをまだインストールしていない場合は、Sun Java Enterprise System インストーラを使用して 2005Q4 バージョンを入手する必要があります。このインストーラを使用すると、ほかの Sun コンポーネントおよびパッケージをインストールすることもできます。Sun Java Enterprise System インストーラについては、『Sun Java Enterprise System 2005Q4 Installation Guide for UNIX』を参照してください。
以前のバージョンの Sun Java Enterprise System からアップグレードする場合、アップグレードのプロセスは『Sun Java System 2005Q4 Upgrade and Migration Guide』に説明されています。
旧バージョンの Calendar Server からの移行については、第 4 章「データベース移行ユーティリティー」を参照してください。
Calendar Server をインストールしたあとに、設定を行う必要があります。インストーラのインストールプロセスでは、設定は行われません。
Directory Server セットアップスクリプト comm_dssetup.pl を実行して Sun Java System Directory Server 5 を設定します (まだスクリプトが実行されていない場合)。
このスクリプトは、次のディレクトリに格納されています。/opt/SUNWcomds/sbin
このスクリプトの実行については、第 2 章「ディレクトリ準備スクリプト (comm_dssetup.pl)」を参照してください。
Calendar Server 設定プログラム csconfigurator.sh を実行してサイト固有の要件を設定し、新しい ics.conf 設定ファイルを作成します。
ics.conf ファイルのパラメータについては、付録 E 「Calendar Server の設定パラメータ」 を参照してください。
このプログラムは、 次のディレクトリに格納されています。/opt/SUNWics5/sbin
csconfigurator.sh の実行については、第 3 章「Calendar Server 設定プログラム (csconfigurator.sh)」を参照してください。
Calendar Server の特別なアカウントには次のものがあります。
Calendar Server 管理者とは、関連付けられた特定のユーザー名とパスワードの組み合わせのうち、Calendar Server の管理権限を付与されているもののことです。たとえば、Calendar Server 管理者は Calendar Server サービスの起動と停止、ユーザーの追加と削除、カレンダの作成と削除などを実行できます。このユーザーは Calendar Server の管理権限を持ちますが、ディレクトリサーバーの管理権限を持つとは限りません。
Calendar Server 管理者のデフォルトのユーザー ID は calmaster ですが、Calendar Server の設定時に別のユーザーを指定することもできます。インストール後に別のユーザーを指定する場合は、ics.conf ファイルの service.admin.calmaster.userid パラメータの設定を変更します。
Calendar Server 管理者として指定するユーザー ID は、ディレクトリサーバー内の有効なユーザーアカウントである必要があります。Calendar Server の設定時に Calendar Server 管理者のユーザーアカウントがディレクトリサーバーに存在していない場合には、設定プログラムがアカウントを自動的に作成します。
次の表は、ics.conf ファイルで設定できる Calendar Server 管理者の構成パラメータを示しています。
表 1–1 Calendar Server (calmaster) 管理者の構成パラメータ
これらの特別なアカウントは Calendar Server の実行に使用されるユーザー ID とグループ ID を示しています。特別なアカウントが存在しないときは、特別な理由がないかぎり、設定プログラムによって自動的に作成されるデフォルト値 icsuser および icsgroup を使用することをお勧めします。
ただし、Calendar Server 設定プログラムの実行時に icsuser および icsgroup 以外の値を指定することもできます。これらの値は、それぞれ ics.conf ファイルの local.serveruid および local.servergid パラメータに格納されます。
Calendar Server をインストールするには、スーパーユーザー (root) としてログインするか、スーパーユーザーになる必要があります。スーパーユーザーとしてコマンド行ユーティリティーを実行し、Calendar Server を管理することもできます。ただし、一部の作業については Calendar Server ファイルへのアクセスの問題を回避するために、スーパーユーザーとしてではなく、icsuser および icsgroup (または選択した値) として実行する必要があります。
管理者がユーザーカレンダを管理できるようにするには、設定ファイル ics.conf でパラメータを設定する必要があります。デフォルトは "no" で、この種のプロキシ認証が許可されないことを意味します。
Communications Express を使用している場合は、このパラメータを "yes" に設定する必要があります。
このパラメータの設定方法およびプロキシログインが機能しているかどうかの確認方法については、「ログインと認証の設定」を参照してください。
エンドユーザーは、Sun Java System Communications Express の Web グラフィカルユーザーインタフェース (GUI) を使用して、クライアントマシンから Calendar Server に接続します。ユーザーは LDAP ディレクトリに一意のエントリを持っている必要があります。各ユーザーは 1 つ以上のカレンダを所有し、1 つ以上のグループに所属できます。
適切な権限を持つ管理者は、Delegated Administrator ユーティリティー (コマンド行) またはコンソール (GUI) を使用して、ユーザー LDAP エントリまたはリソース LDAP エントリを追加、削除、または変更できます。
Delegated Administrator ユーティリティー (commadmin) のマニュアルについては、『Sun Java System Communications Services 6 2005Q4 Delegated Administrator Guide』を参照してください。
Delegated Administrator コンソールのマニュアルについては、コンソールのオンラインヘルプを参照してください。
また、必要があれば、ldapmodify を使用して LDAP エントリを直接変更することもできます。ldapmodify については、『Sun ONE Directory Server Resource Kit 5.2 Tools Reference』を参照してください。
csuser など、Java Enterprise System 以前のバージョンで使用されるユーティリティープログラムは、今回のバージョンでも Calendar Server にバンドルされています。Access Manager を使用している場合は、ユーザー、ドメイン、またはリソース LDAP エントリの管理や作成にこれらのユーティリティーを使用しないでください。これには例外がいくつかあります。このような場合、このマニュアルでは適切なユーティリティーを示します。
この節では、ユーザーおよびそのカレンダ管理に関する次の点について説明します。
Calendar Server ユーザーは、手動または自動で作成できます。
手動: Directory Server が Schema 2 用に設定されている場合、管理者は Delegated Administrator ユーティリティーを使用してディレクトリサーバーにユーザーを追加し、Calendar Server の cscal ユーティリティーを使用してユーザーのデフォルトカレンダを作成できます。
Directory Server が Schema 1 用に設定されている場合、Calendar Server の csuser ユーティリティーを使用して、ユーザーとカレンダの両方を同時に作成します。
自動 (自動プロビジョニング): 自動プロビジョニングが設定されており、LDAP ディレクトリにすでにユーザーが存在している場合は、ユーザーが最初にログインしたときに Calendar Server によって自動的にデフォルトカレンダが作成されます。
ホストされていないドメインモードでは、Calendar Server によって、ユーザー ID からデフォルトカレンダのカレンダ ID (calid) が作成されます。たとえば、John Doe のユーザー ID が jdoe である場合、彼のデフォルトカレンダ calid は jdoe になります。
ホストされたドメインモードでは、calid はユーザー ID とユーザーのドメインの組み合わせです。たとえば、John Doe が example.com というドメインにいて、彼のユーザー ID が jdoe である場合、ホストされたドメイン環境での彼の calid は jdoe@example.com となります。
自動プロビジョニングを行うには、次の条件を満たす必要があります。
ics.conf ファイルの local.autoprovision パラメータの値が “yes” (デフォルト) に設定されている。
ホストされた (仮想) ドメインのモードで、ドメインでのカレンダの使用が有効に設定されている。ドメイン内の LDAP エントリに icsCalendarDomain オブジェクトクラスがある場合、ドメインのカレンダは使用可能になっている。
たとえば、ディレクトリサーバーに tchang が存在するが、カレンダ機能はまだ有効になっていない (つまり、デフォルトカレンダを持っていない) と仮定します。tchang がはじめて Calendar Server にログインするときに、tchang のカレンダ機能は Calendar Server によって自動的に有効になり、tchang という calid でデフォルトカレンダが作成されます。
Calendar Server は、ユーザーの認証とユーザー設定の格納に使用する、Sun Java System Directory Server などのディレクトリサーバーを必要とします。ただし、LDAP 以外のディレクトリサーバーに定義されているユーザーによるアクセスを許可できるように、Calendar Server には LDAP 以外のディレクトリにアクセスする場合に必要となるプラグインを記述するための Calendar Server API (CSAPI) が用意されています。CSAPI については、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。
Calendar Server では、ユーザーはディレクトリサーバーに格納されているユーザー設定属性を使用して、カレンダデータの表示方法をカスタマイズすることができます。ユーザー設定 (これと対をなすのが Calendar Server の設定パラメータ) は、ユーザーインタフェースでのカレンダデータの表示に適用され、カレンダを表示する際のユーザー名、電子メールアドレス、表示色などの項目がこれに含まれます。
設定できる項目については、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』の get_userprefs および set_userprefs の WCAP コマンドを参照してください。
カレンダグループとは、個々の登録済みカレンダの集合体であり、グループには名前がついています。カレンダをグループ化することで、複数のカレンダを組み合わせて 1 つのカレンダとして表示できます。ユーザーは、Communications Express のグラフィカルユーザーインタフェースを使用してグループを作成します。
たとえば、プライベートなカレンダ、部署のカレンダ、会社の休日カレンダをカレンダグループとして組み合わせることができます。また、カレンダグループを利用してカレンダのリストを並べて表示し、カレンダの所有者に予定への出席を依頼することもできます。
これらのグループが LDAP グループと混同されることはありません。このユーザーインタフェースで作成したグループは、icsSet 属性内のユーザーの LDAP エントリに格納されます。したがって、ほかのユーザーが LDAP 内の出席者を検索するときには、ユーザーインタフェースで作成したグループを表示することはできません。
Calendar Server ユーザーについては、第 14 章「ユーザーとリソースの管理」を参照してください。
リソースとは、会議室、またはプロジェクタなど、カレンダを使ってスケジューリングできるものをいいます。そのような項目ごとに異なるリソース LDAP エントリがあります。LDAP エントリとそれに関連するカレンダの作成には、次の該当するツールを使用してください。
Schema 2 の場合: リソース LDAP エントリの作成には Delegated Administrator を、カレンダの作成には Calendar Server ユーティリティーの resource を使用します。
Schema 1 の場合: リソース LDAP エントリとカレンダのどちらの作成にも csresource create コマンドを使用します。
この節では、Calendar Server データに関する次の項目について説明します。
Calendar Server のデータ形式は、RFC 2445「Internet Calendaring and Scheduling Core Object Specification (iCalendar)」に準拠しています。Calendar Server は次の形式をサポートしています。
XML (.xml): Communications Express へのインタフェース。
iCalendar (.ical): デフォルトの形式。
CSAPI を使用して、WCAP プロトコル用のトランスレータ DLL または共有ライブラリを開発できます。WCAP および CSAPI については、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。
カレンダデータは、iCalendar (.ical) 形式または XML (.xml) 形式でインポートおよびエクスポートできます。Calendar Server の管理者は、Calendar Server の csimport および csexport ユーティリティーを使用してカレンダデータをインポートおよびエクスポートできます。エンドユーザーは、Communications Express のユーザーインタフェースを使用してカレンダデータをインポートおよびエクスポートできます。
カレンダは、電子メールメッセージや Web ページに埋め込んだリンクとして参照させることができます。カレンダが読み取りアクセスを許可しているかぎり、ユーザーは Calendar Server にログインすることなく、リンクをクリックするだけでカレンダを表示することができます。たとえば、次のリンクは Auditorium というリソース空間を指定しています。
http://calendar.sesta.com:8080/?calid=Auditorium
Calendar Server は、受信者リストに送信されるサーバー側の電子メールアラームをサポートしています。電子メールメッセージの形式は設定変更が可能で、ユーザーまたはカレンダの属性としてではなく、サーバーの属性として維持されます。Calendar Server が限定的にサポートするのは、予定用の ITIP メソッド PUBLISH、REQUEST、REPLY、CANCEL を含む ITIP/IMIP 標準 (RFC 2446 および RFC 2447) です。
LDAP データキャッシュオプションを使用すると、LDAP ディレクトリサーバーが、コミットされたデータの利用可能性に遅延が発生するように設定されている場合でも、コミットされるとすぐに LDAP データが利用できるようになります。
たとえば、Calendar Server がスレーブ LDAP ディレクトリサーバー経由でマスター LDAP ディレクトリにアクセスするマスター/スレーブ LDAP 構成がサイトに配備されており、コミットされた LDAP データの利用可能性に遅延が発生している場合でも、LDAP データキャッシュを使用すると、Calendar Server クライアントは正確な LDAP データを入手できるようになります。
ここで説明する内容は次のとおりです。
次のガイドラインを使用して、サイトで LDAP データキャッシュを設定すべきかどうかを判断してください。
サイトの Calendar Server がマスター (またはルート) LDAP ディレクトリサーバーに直接アクセスしており、コミットされた LDAP データの利用可能性に遅延が発生していない場合は、LDAP データキャッシュを設定する必要はありません。local.ldap.cache.enable パラメータが "no" (デフォルト値) に設定されていることを確認してください。
「マスター/スレーブ LDAP 構成」が配備されており、Calendar Server がスレーブ LDAP ディレクトリサーバー経由でマスター LDAP ディレクトリにアクセスしている場合は、コミットされた LDAP データの利用可能性に遅延が発生します。LDAP データキャッシュを設定して、エンドユーザーが最新のデータを入手できるようにしてください。
マスター/スレーブ LDAP 構成には、マスター (ルート) ディレクトリサーバーと、1 つ以上のスレーブ (コンシューマまたはレプリカ) ディレクトリサーバーが含まれます。Calendar Server は、マスター LDAP ディレクトリサーバーに直接アクセスすることも、スレーブディレクトリサーバー経由でアクセスすることもできます。
Calendar Server がマスター LDAP ディレクトリサーバーに直接アクセスしていれば、LDAP は正確であり、LDAP データキャッシュを設定する必要はありません。
Calendar Server がスレーブディレクトリサーバー経由でマスター LDAP ディレクトリサーバーにアクセスしている場合は、LDAP データの変更は通常、LDAP リフェラルを使用して透過的にマスターディレクトリサーバーに書き込まれます。次に、LDAP リフェラルは、データをレプリケーションにより各スレーブディレクトリサーバーに戻します。
この 2 番目のタイプの構成では、コミットされた LDAP データがスレーブディレクトリサーバーで利用可能になるまでに遅延が発生するため、LDAP データが不正確になるという問題が発生する場合があります。
たとえば、Calendar Server が LDAP データの変更をコミットしても、マスターディレクトリサーバーが各スレーブディレクトリサーバーの更新を完了するまでの遅延のために、一定の時間は新しいデータが利用できません。以降の Calendar Server クライアント操作で古い LDAP データが使用されると、期限切れの内容が表示されます。
スレーブディレクトリサーバーを更新する際の遅延が短時間 (ほんの数秒) であれば、クライアントで問題が発生しないこともあります。しかし、遅延がそれ以上 (数分または数時間) になると、遅延の長さに応じてクライアントには不正確な LDAP データが表示されます。
次の表は、このような遅延によって影響を受ける操作と LDAP 属性を示しています。
操作 |
LDAP 属性 |
---|---|
自動プロビジョニング |
icsCalendar、icsSubscribed、 icsCalendarOwned、icsDWPHost |
カレンダグループ |
icsSet |
カレンダの作成 |
icsCalendarOwned、icsSubscribed |
カレンダの登録 |
icsSubscribed |
ユーザーオプション |
icsExtendedUserPrefs、icsFirstDay、 icsTimeZone、icsFreeBusy |
カレンダの検索 |
icsCalendarOwned |
LDAP データキャッシュは、マスターディレクトリサーバーが各スレーブディレクトリサーバーをまだ更新していない場合でも、Calendar Server クライアントに最新の LDAP データを提供することにより、マスター/スレーブ LDAP 構成の問題を解決します。
LDAP データキャッシュが有効になっていると、Calendar Server は、コミットされた LDAP データをキャッシュデータベース (ldapcache.db ファイル) に書き込みます。LDAP キャッシュデータベースは、デフォルトでは ldap_cache データベースディレクトリに配置されますが、必要に応じて別の場所を設定できます。
クライアントが単一ユーザーの LDAP データを変更すると、Calendar Server は、変更されたデータをスレーブディレクトリサーバーだけでなく、LDAP キャッシュデータベースにも書き込みます。以降のクライアント操作では、LDAP データがキャッシュデータベースから取得されます。このデータ取得は、単一ユーザーの次の操作に適用されます。
ログイン時のユーザーの属性
ユーザーのオプション (配色やタイムゾーンなど)
ユーザーのカレンダグループ
ユーザーの登録済みカレンダリスト
これにより、LDAP データキャッシュデータベースでは次のことが可能になります。
単一システム上のプロセス間でのデータ整合性。データベースは、マルチプロセッサシステム上のすべての Calendar Server プロセスで利用可能です。
ユーザーセッション間でのデータ持続性。データベースは永続的であり、更新は必要ありません。
LDAP データキャッシュでは、次のことを行うことはできません。
エントリのリストが予測される検索のためにキャッシュを読み取ること。たとえば、会議の出席者の検索がこれに当たります。このタイプの検索は、すべての LDAP 遅延の影響を受けます。たとえば、LDAP の検索オプションがアクティブになっており、新しいカレンダを作成したあとの遅延時間内に検索が実行された場合は、カレンダの検索で、新しく作成されたカレンダは表示されません。
複数のフロントエンドサーバーにわたるキャッシュの読み取りおよび書き込み。各フロントエンドサーバーは独自のキャッシュを備えており、ほかのキャッシュにあるデータは認識していません。
常に同じサーバーにログインするとは限らないユーザーを処理する機能。このようなユーザーの場合は、各サーバー上のキャッシュに別の LDAP データが生成されます。
Calendar Server は、ACL (アクセス制御リスト) を使用して、カレンダ、カレンダプロパティー、予定や仕事 (作業) などのカレンダコンポーネントへのアクセスを制御します。
ここで説明する内容は次のとおりです。
ユーザーが Communications Express 経由で Calendar Server にログインする場合、デフォルトでは、認証プロセスはユーザー名とパスワードを含むログイン情報を暗号化しません。サイトへのセキュリティー保護されたログインを希望する場合は、SSL (Secure Sockets Layer) プロトコルを使用してログインデータを暗号化するように Calendar Server を設定します。詳細は、第 8 章「SSL の設定」を参照してください。
カレンダ、カレンダプロパティー、カレンダコンポーネントへのアクセスの可否を決定する上で、Calendar Server は次のユーザーを区別します。
一次カレンダ所有者は、所有するカレンダに対する完全なアクセス権を持ちます。一次カレンダ所有者が本人所有のカレンダにアクセスする場合、Calendar Server はアクセス制御チェックを一切行いません。
calmaster などの管理者、または root などのスーパーユーザーは、アクセス制御の対象とはならず、カレンダまたはカレンダコンポーネントに対してどのような処理も実行できます。詳細は、「Calendar Server の特別なアカウント」を参照してください。
一次カレンダ所有者は、本人が所有するカレンダにその他の所有者を指定できます。その他の所有者は一次所有者に代わって予定や仕事 (作業) のスケジューリング、削除、変更、了解、拒否を実行できます。
ics.conf ファイルの service.http.allowanonymouslogin が “yes” (デフォルト) に設定されている場合、特別なカレンダ ID (calid) である anonymous は、任意のパスワードを使用して Calendar Server にアクセスできます。anonymous ユーザーは、特定のドメインに関連付けられていません。calstore.anonymous.calid パラメータを編集することにより、anonymous ユーザーの calid を変更できます。
カレンダのアクセス権が全員に読み取りアクセスを許可している場合にも、カレンダを匿名で表示できます。たとえば、次のリンクを使用することにより、ユーザーは tchang:meetings という calid のカレンダを匿名表示できます (全員にカレンダへの読み取りアクセス権が許可されている場合)。
http://calendar.sesta.com:8080/?calid=tchang:meetings
anonymous ユーザーは、カレンダ上で公開されている予定と仕事を表示、印刷、検索することはできますが、その他の処理は行えません。
リソースカレンダの匿名表示については、「カレンダへのリンク設定」を参照してください。
Calendar Server は、カレンダ、カレンダプロパティー、予定や仕事 (作業) などのカレンダコンポーネントへのアクセスを制御するために、ACL (アクセス制御リスト) を使用します。ACL は、1 つ以上の ACE (アクセス制御エントリ) から構成されます。ACE は同じカレンダまたはコンポーネントに集合的に適用される文字列であり、ACL 内の各 ACE はセミコロンで区切られます。次に例を示します。
jsmith^c^wd^g には 1 つの ACE が含まれる。
@@o^a^r^g;@@o^c^wdeic^g;@^a^sf^g には 3 つの ACE が含まれる。
ACE には次の要素が含まれ、各要素はキャレット (^) で区切られます。
「Who」: ACE の適用対象となる個人、ユーザー、ドメイン、またはユーザータイプ。
「What」: アクセスの対象となるターゲット。カレンダ、予定や仕事 (作業) などのカレンダコンポーネント、カレンダプロパティーなど。
「How」: 許可されるアクセス権の種類。読み取り、書き込み、削除など。
「Grant」: 許可または拒否される具体的なアクセス制御権。
たとえば、jsmith^c^wd^g という ACE は次のように機能します。
jsmith は ACE の適用対象を示す Who 要素。
c はアクセス対象ターゲットを示す What 要素 (カレンダコンポーネントのみ)。
wd は 許可または拒否されるアクセス権の種類を示す How 要素 (書き込みと削除)。
g はカレンダコンポーネントに対する特定のアクセス権 (書き込みと削除) を jsmith に与えることを示す Grant 要素。
Who 要素は、個人、ユーザー、ドメイン、特定のユーザータイプなど、ACE の適用対象を指定する ACE の主要値です。
Who 要素は UPN (Universal Principal Name) と呼ばれます。ユーザーの UPN はユーザーのログイン名とユーザーのドメインを組み合わせたものです。たとえば、ドメイン sesta.com に属するユーザー bill の UPN は、bill@sesta.com です。
表 1–2 ACE (アクセス制御エントリ) 文字列の “Who” 要素の形式
What 要素は、カレンダ、カレンダコンポーネント (予定または作業)、カレンダプロパティーなど、アクセスの対象となるターゲットを指定します。
表 1–3 ACE (アクセス制御エントリ) 文字列の “What” 要素の値
値 |
説明 |
|
---|---|---|
|
予定や作業などのカレンダコンポーネントを指定します |
|
|
名前、説明、所有者などのカレンダプロパティーを指定します |
|
|
コンポーネントとプロパティーの両方を含むカレンダ全体 (すべて) を指定します |
How 要素は、読み取り、書き込み、削除など、許可されるアクセス権の種類を指定します。
表 1–4 ACE (アクセス制御エントリ) 文字列の “How” 要素の種類
種類 |
説明 |
---|---|
r |
読み取りアクセス。 |
w |
書き込みアクセス。新規項目の追加、既存項目の変更を含みます。 |
d |
削除アクセス。 |
s |
スケジュール (出席依頼) アクセス。要求の送信、応答の受け付け、その他の ITIP スケジューリング操作を実行できます。 |
f |
空き/予定ありアクセス権のみ。空き/予定ありアクセスでは、ユーザーはカレンダにスケジュールされている時刻を確認することはできますが、予定の詳細を確認することはできません。その代わりに、スケジュールが組まれている時間帯には「利用不可」だけが表示されます。予定がスケジュールされていない時間帯には、「空き時間」が表示されます。 |
l |
ドメインのルックアップアクセス |
e |
応答アクセスの代行操作。このアクセス権を持つユーザーは、カレンダの一次所有者に代わって出席依頼を受け入れるか、または拒否することができます。ユーザーがカレンダの一次所有者以外の所有者として指定された段階で暗黙的に付与される権限であるため、このアクセス権を明示的に付与する必要はありません。 |
i |
出席依頼アクセスの代行操作。このアクセス権を持つユーザーは、カレンダの一次所有者に代わってほかのユーザーに出席を依頼したコンポーネントを作成、変更することができます。ユーザーがカレンダの一次所有者以外の所有者として指定された段階で暗黙的に付与される権限であるため、このアクセス権を明示的に付与する必要はありません。 |
c |
キャンセルアクセスの代行操作。このアクセス権を持つユーザーは、カレンダの一次所有者に代わってほかのユーザーに出席を依頼したコンポーネントを取り消すことができます。ユーザーがカレンダの一次所有者以外の所有者として指定された段階で暗黙的に付与される権限であるため、このアクセス権を明示的に付与する必要はありません。 |
z |
自己管理アクセス。認証されたユーザーは、アクセス制御エントリを追加または削除する権限を付与されます。この権限を持つユーザーは、自分自身で権限を追加したり削除したりすることができます。たとえば、UserA は、UserB のカレンダへの書き込みアクセス権はありませんが、UserB のカレンダへの自己管理アクセスを許可されているとします。これにより、UserA は、UserB のカレンダへの書き込みアクセスを自分自身に許可するためのアクセス制御エントリを追加できます。 注: この特権を使用した場合も、UserA は、UserB のカレンダへのアクセスをほかのユーザーに許可することはできません。たとえば、UserA が自己管理の特権を使用して、UserB のカレンダへのアクセスを UserC に許可することはできません。 |
Grant 要素は、d (削除) や r (読み取り) など、指定されたアクセス権の許可または拒否を指定します。
表 1–5 ACE (アクセス制御エントリ) 文字列の Grant 要素の値
値 |
説明 |
---|---|
g |
指定したアクセス制御権を付与します。 |
d |
指定したアクセス制御権を拒否します。 |
次に、ACE の使用例を示します。
コンポーネントとプロパティーの両方を含むカレンダ全体に対する読み取りアクセス権をユーザー ID jsmith に付与します。
jsmith^a^r^g
コンポーネントだけに対する書き込みアクセス権と削除アクセス権を jsmith に付与します。
jsmith^c^wd^g
sesta.com ドメインのすべてのユーザーに、コンポーネントのみに対するスケジュール、予定状況、読み取りのアクセス権を付与します。
@sesta.com^c^sfr^g
コンポーネントだけに対する書き込みアクセス権と削除アクセス権をすべての所有者に付与します。
@@o^c^wd^g
カレンダデータに対する jsmith によるあらゆるアクセスを拒否します。
jsmith^a^sfdwr^d
コンポーネントとプロパティーの両方を含むカレンダ全体に対する読み取り、スケジュール、空き時間確認のアクセス権をすべての所有者に付与します。
@@o^a^rsf^g
すべてのユーザーに読み取りアクセス権を付与します。
@^a^r^g
Calendar Server は、ACL を読み取るときに、ターゲットに対するアクセスの許可または拒否を指示する ACE のうち、最初に見つかったものを使用します。このため、ACL の順序は重要で、より一般的な制御の前に、より具体的な制御が配置されるように ACE 文字列の順序を決定する必要があります。
たとえば、カレンダ jsmith:sports の ACL 内の最初の ACE がすべてのユーザーに読み取りアクセス権を付与すると仮定します。次に、Calendar Server はこのカレンダに対する bjones によるアクセスを拒否する第 2 の ACE を見つけます。この場合、Calendar Server はこのカレンダに対する読み取りアクセス権を bjones に付与し、最初の ACE と矛盾する第 2 の ACE は無視されます。このため、bjones のような特定のユーザーのアクセス権を有効にするには、カレンダのすべてのユーザーに適用される ACE のように一般的なエントリの前に、bjones 用の ACE を配置する必要があります。
Sun Java System Calendar Server には、次の内部サブシステムが含まれます。
次の図は、これらのサブシステム間の論理フローを示しています。
クライアントは、HTTP プロトコル層を使用して要求を送信することによりカレンダデータを取得します。これは、カレンダ要求のサポートを効率化するための最小の HTTP サーバー実装です。これを実現するために、URL に WCAP (Web カレンダアクセスプロトコル) コマンドを追加します。
WCAP は Calendar Server 用の独自のインタフェースの記述に利用できるオープンプロトコルです。WCAP コマンド (拡張子は .wcap) を使用することにより、特定の管理コマンドを除くほとんどのサーバーコマンドを実行できます。WCAP コマンドを使用すると、HTML でラップされた XML または iCalendar として出力を要求できます。
WCAP コマンドについては、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。
コアサブシステムには、アクセス制御コンポーネント、カレンダデータベースコンポーネントから受信したデータをデータトランスレータを使用してフォーマットする WCAP、および任意の CSAPI プラグインが含まれます。コアサブシステムはカレンダ要求を処理し、WCAP 出力を生成します。また、コアサブシステムは 「Calendar Server API (CSAPI)」を含むユーザー認証も処理します。
データベースサブシステムは、Sleepycat Software の Berkeley DB (データベース API は未公開) を使用します。データベースサブシステムは、データベースとの間で予定、仕事 (作業)、アラームなどのカレンダデータを取得、格納します。カレンダデータは iCalendar 形式に基づいており、Calendar Server データに使用されるスキーマは iCalendar 標準のスーパーセットです。
データベースサブシステムは低次の形式でデータを返し、次にコア UI ジェネレータが、その低次のデータを変換して WCAP 経由で送信します。
配布されたカレンダデータベース用に、Calendar Server では Distributed Wire Protocol (DWP) を使用してネットワーク機能を提供します。詳細は、「分散型データベースサービス: csdwpd」を参照してください。
カレンダデータベースについては、第 16 章「csdb を使用した Calendar Server データベースの管理」を参照してください。
Calendar Server サービスは、デーモン (プロセス) として実行されます。次のサービスがあります。
csadmind サービスは、Calendar Server を管理するためのシングルポイントの認証を提供します。また、csadmind サービスはアラーム通知やグループスケジュール要求も管理します。
Calendar Server はプライマリトランスポートとして HTTP を使用するため、cshttpd サービスは Calendar Server エンドユーザーからの HTTP コマンドを待機し、ユーザーコマンドを受け取って、受信した WCAP コマンドで指定された形式に応じたカレンダデータを返します。データは、標準の RFC 2445 iCalendar 形式 (text/calendar) または XML 形式 (text/xml) でフォーマットできます。
設定が正しく行われると、csstored サービスによってカレンダデータベースの自動バックアップが作成されます。ただし、このサービスは設定されていない状態でインストールされます。Calendar Server の自動バックアップの設定は、csconfigurator.sh 設定プログラムの実行時に行うことも、このマニュアルの説明に従ってあとで行うこともできます。
サービスが設定されていない、無効の状態で起動されると、自動バックアップが無効になっていることを示すメッセージが 24 時間ごとに管理者に送信されます。
バックアップが実行されるようにこのサービスを設定する方法については、第 10 章「自動バックアップ (csstored) の設定」を参照してください。
設定が正しく行われると、サービスには次の機能が備わります。
システムが起動されると、その後 24 時間 (デフォルト設定) 間隔で、動作中の Calendar Server のカレンダデータベースのスナップショットを取得します。この間隔は設定可能です。サービスがいったん停止して再起動した場合は、最後のスナップショットを取得してから、設定された間隔が経過するまで新しいスナップショットは取得されません。
バックアップコピーに対して csdb verify を実行して、データベースを検証します。
データベースが破損するなど、検証ステップが失敗した場合、管理者に通知されます。ライブデータベースは読み取り専用モードにできるため、データベースをシャットダウンしなくても問題のトラブルシューティングを行うことができます。読み取り専用モードの間は、トランザクションの変更または削除は受け付けられません。ロギングも行われません。読み取り専用モードについては、「データベース破損時のサービス停止の防止 (読み取り専用モード)」を参照してください。
破損が見つかったときは、管理者が介入する必要があります。管理者には通知が送信されます。
検証が成功した場合は、csstored によって新たに次のタスクが実行されます。
データベースのスナップショットと、前回のスナップショット以降に適用されたすべてのトランザクションログファイルから構成されるアーカイブバックアップを作成します。
データベースのスナップショットと、それに適用されたトランザクションログファイルから構成されるホットバックアップを作成します。
ライブデータベースが破損した場合は、ホットバックアップによって、データの損失と停止時間を最小限に抑えながらデータベースの最新のバックアップを即座に入手できます。
自動バックアップコピーの復元方法については、「自動バックアップコピーの復元」を参照してください。
ENS サービスは、次のサービスから構成されます。
csnotifyd: csnotifyd サービスは予定と仕事 (作業) の通知を送信します。また、csnotifyd サービスはアラーム予定も登録します。アラーム予定が発生すると、csnotifyd は各受信者に SMTP メッセージアラームを送信します。
enpd: enpd サービスは予定アラームのブローカとして機能します。enpd サービスは csadmind サービスからアラームの通知を受け取り、この予定の登録を確認します。次に、登録アラーム通知を csnotifyd に渡すことにより、予定登録者に通知します。また、enpd サービスは csnotifyd から登録と登録の取り消し (登録解除) を受け取り、それを格納します。
enpd サービスと csnotifyd サービスは、cshttpd、csdwpd、および csadmind プロセスと同じサーバーで実行する必要はありません。
csdwpd サービスは、カレンダデータベースを複数のバックエンドサーバーに分散させる場合に必要です。csdwpd サービスを使用すると、カレンダデータベースを同じ Calendar Server 構成内の複数のバックエンドサーバーに分散させることにより、分散型のカレンダストアを形成できます。
csdwpd サービスはバックエンドサーバーでバックグラウンドで実行され、カレンダデータベースへのアクセスを必要とする DWP (データベースワイヤプロトコル) 準拠の要求を受け入れます。DWP は、Calendar Server データベースのネットワーク機能を提供する内部プロトコルです。
Calendar Server には、次の API と SDK が含まれています。
Calendar Server は、クライアントの通信に利用する、高レベルのコマンドベースプロトコルである WCAP 3.0 をサポートします。クライアントは、WCAP コマンド (拡張子は .wcap) を使用して、カレンダコンポーネント、ユーザー設定、カレンダプロパティー、タイムゾーンなどのその他のカレンダ情報を取得、変更、削除します。時刻、文字列、パラメータなど、WCAP 要素の多くは RFC 2445、RFC 2446、RFC 2447 仕様に準拠します。
WCAP は、次の形式の HTTP メッセージとして出力カレンダデータを返します。
標準の RFC 2445 iCalendar 形式 (text/calendar)
XML 形式 (text/xml)
WCAP コマンドを使用し、login.wcap を使用してログインする Calendar Server 管理者は、次の権限を持ちます。
WCAP コマンドのアクセス制御の対象から外れる
管理者は WCAP コマンドを使用して、ほかのユーザーのカレンダの読み取り (フェッチ)、変更 (格納)、または削除を行うことができます。管理者がこの権限を取得するには、ics.conf ファイルの次のパラメータを "yes" に設定する必要があります。
service.admin.calmaster.overrides.accesscontrol="yes"
任意のユーザーのユーザー設定を取得し、それを変更する
管理者は get_userprefs.wcap および set_userprefs.wcap を使用して、任意のユーザーのユーザー設定を取得し、それを変更することができます。管理者がこの権限を取得するには、ics.conf ファイルの次のパラメータを "yes" に設定する必要があります。
service.admin.calmaster.wcap.allowmodifyuserprefs="yes"
詳細は、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。
Calendar Server API (CSAPI) を利用すると、ユーザーのログイン認証、アクセス制御、カレンダの検索など、Calendar Server の機能面をカスタマイズできます。たとえば、Calendar Server はユーザー認証とユーザー設定の格納に LDAP ディレクトリサーバーのエントリを使用します。CSAPI を利用して LDAP ディレクトリサーバーを使用しない異なる認証メカニズムを実装することで、Calendar Server のデフォルトの認証を変更することができます。
CSAPI については、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。
ENS (予定通知サービス) は、アラームキューで予定を検出し、これらの予定に関する通知を登録者に送信するアラームディスパッチャーです。プログラマは ENS API を使用して Calendar Server が使用する公開と登録機能を変更し、予定の登録、予定の登録解除、登録者への予定の通知などの機能を実行させることができます。ENS API は、Published API、Subscriber API、Publish and Subscribe Dispatcher API から構成されます。
ENS API については、『Sun Java System Communications Services 6 2005Q4 Event Notification Service Guide』を参照してください。
Calendar Server には、ユーザー認証のための authSDK が用意されています。authSDK を使用して既存のポータルサービスと Calendar Server を統合することで、ユーザーは再認証の必要なくさまざまなアプリケーションにアクセスできるようになります。authSDK は、DLL/ 共有オブジェクトライブラリとヘッダーファイルにパッケージ化された機能から構成されます。
Calendar Server と authSDK の間の接続は、信頼関係を形成します。ユーザーがログインし、authSDK への認証が正常に行われると、Calendar Server はプロキシによって生成される証明書を受け付け、機能へのアクセスを許可します。
authSDK については、『Sun Java System Calendar Server 6 2005Q4 Developer’s Guide』を参照してください。