test

OpenWindows ユーザーズガイド

カレンダマネージャのトラブル

この節では、カレンダマネージャの基本的なトラブルについて説明します。

RPC 問題とカレンダマネージャのインストール

カレンダマネージャは、次の 2 つから構成されます。

カレンダマネージャのアプリケーションは、カレンダマネージャサービスがなくては機能しません。

カレンダマネージャがアポイントメントを表示しない場合、またはコンソールウィンドウに RPC のタイムアウトメッセージが表示された場合、rpc.cmsd が動作していないことがあります。ユーザの構成を検査するには、次の手順に従ってください。

  1. コマンドツールまたは シェルツールをオープンします。

    コマンドツールやシェルツールについては、第 6 章「コマンドツール、シェルツール、 コンソールウィンドウ」を参照してください。

  2. システムプロンプトに続けて、 ps -e | grep rpc.cmsd と入力して Return キーを押します。

    これは、文字列 rpc.cmsd が収められているすべてのプロセスを表示します。

  3. ウィンドウに表示されたリストを参照します。

    カレンダマネージャのサービスプロセスが収められたリストを図 A-1 に示します。ps リストのエントリ grep rpc.cmsd は無視できます。

    図 A-1 rpc.cmsd プロセスを示す ps リスト

    Graphic

    rpc.cmsd プロセスを実行していない場合、次のステップに従ってください。

    注 -

    カレンダマネージャのアプリケーションを実行している場合、ウィンドウメニューから「終了」を選択してカレンダマネージャを終了してください。

  1. ルートになります。

  2. システムプロンプトに続けて、vi /etc/inetd.CONF と入力します。

  3. エントリ Rpc.cmsd を捜します。

    指定されたパス名が正しく、かつ、そのパス名に Rpc.cmsd エントリが存在することを確認してください。存在しない場合、Rpc.cmsd の存在する場所を指すように、パスを変更してください。次のように入力して、inetd のプロセス ID を表示してください。

    ps -e | grep inetd

    次のように入力して、inetd.CONF ファイルを再び読み込んでください。

    kill -1 inetd-pid

  4. カレンダマネージャを再起動します。

  5. カレンダマネージャサービスが現在動作中であることを確認するため、 ps -e | grep rpc.cmsd と入力して、Return キーを押します。

SunOS およびカレンダマネージャのアップグレード

SunOS をアップグレードする場合、下記のディレクトリをバックアップして、その情報を保存しなければなりません。/var/spool/calendar

どのバックアップメディアを使うかはユーザの自由です。オペレーティングシステムのアップグレードが終了してから、このディレクトリを復元してください。

カレンダデータの紛失、またはヘッダ内の NO NAME

アポイントメントが表示されない場合、必要に応じて、インストールスクリプトを実行したことを確認してください。詳細については、「RPC 問題とカレンダマネージャのインストール」を参照してください。下記の手続きを行う前に、まず、カレンダマネージャの再起動を行なってください。

それでもアポイントメントが表示されず、しかもカレンダマネージャのヘッダに文字列 NO NAME が表示されている場合、おそらく /usr/spool/calendar ディレクトリおよびファイルのパーミッションが不正です。下記のステップで、パーミッションを確認してください。

  1. ls -lsa /usr/spool と入力し、ディレクトリ /usr/spool/calendar のパーミッションを検査します。

    パーミッションは、正確に drwxrwsrwt でなければなりません。これはデーモングループ内のデーモンが所有していなければなりません (必要ならば、システム管理者に確認してパーミッションを変更してください)。

  2. カレンダデータベースのパーミッションを検査するには、次のように入力します。

    ls -lsa /usr/spool/calendar/callog.<ユーザ名>

    <ユーザ名> はユーザの名前に置き換えてください。たとえば、次のように入力します。

    ls -lsa /usr/spool/calendar/callog.egret

    パーミッションは、正確に -r--rw---- でなければなりません。また、このファイルはユーザとデーモングループによって所有される必要があります。

リモートアクセスのトラブル

カレンダマネージャのリモートアクセスに関するトラブルには、基本的に 2 つの症状があります。

これらのアクセス問題を処置しようとした場合、3 つの項目について調べてください。

  1. メールドメインの概念を採用している NIS または DNS のシステムを使っている場合、ユーザドメイン内でカレンダを表示しようとしているか、または表示リスト内のドメインを指定したことを確認してください。たとえば、ユーザドメイン内でユーザ Rob のカレンダを表示しようとしている場合、Rob@host をそのまま指定できます。Eng と呼ばれるドメイン内にいて、Rob は Corp と呼ばれるドメイン内にある場合、表示リスト内に rob@host.Corp を指定する必要があります。

  2. リモートカレンダの所有者がユーザにブラウズ、挿入、削除のアクセスを許可したことを確認してください。

    アクセスを行うためには、次の 2 つの条件が満足されていなければなりません。

    1. アクセスリスト内の名前は、user@host または単に user の形式でなければなりません。なお、アクセスリスト内の名前が単に user の場合、ネットワーク上でそのユーザ名の人にアクセスが許可されます。NIS または DNS のシステムを使っている場合、アクセスリスト内のユーザ名が、user@domain または user@name.domain の形式でリストされていないことを確認してください。

    2. カレンダの所有者は、「アクセスリストとパーミッション」のプロパティウィンドウの「適用」ボタンの上でセレクトボタンでクリックしなければなりません。ユーザのワークステーションとリモートワークステーションの両方で、ユーザ ID とグループ ID を検査してください。これらの ID は、両方で一致しなければなりません。

  3. 次のように、各ワークステーション上でユーザ ID とグループ ID を決定してください。

    1. ファイル /etc/passwd 内でパスワードエントリを探してください。

      このファイルにエントリがある場合、ユーザ ID は 3 番目のフィールド (2 番目と 3 番目のコロンの間の数) です。グループ ID は 4 番目のフィールド (3 番目と 4 番目のコロンの間の数) です。たとえば、/etc/passwd ファイルのユーザ Egret のエントリが以下のような場合、

      egret:X4y8r2Bg:3286:10:& West:/home/egret/:/bin/csh

      ユーザ Egret のユーザ ID は 3286 であり、グループ ID は 10 です。 ユーザ ID とグループ ID の値は 0 〜 32767 でなければなりません。

    2. NIS システムを使っており、しかもファイル /etc/passwd にエントリがなく、/etc/passwd の最後の行が「+」で始まる場合、NIS passwd エントリのエントリを検査してください。NIS のユーザエントリを決定するには、コマンドツールまたはシェルツールに ypmatch username passwd と入力してください。

      たとえば、ユーザ Egret の NIS パスワードエントリを見つけるには、次のとおりに入力してください。

      ypmatch egret passwd

      システムがユーザエントリで応答した場合、ユーザ ID は 3 番目のフィールドであり、グループ ID は 4 番目のフィールドです。

ワークステーションへの第 2 カレンダの追加

ワークステーションに第 2 カレンダを追加したい場合、そのカレンダ用のダミーユーザを作成する必要があります。たとえば、ユーザの作業グループ全体に対するアポイントメントに、第 2 カレンダを追加したいことがあります。

ダミーユーザと新しいカレンダを作成するには、下記のステップを実行します。これらのステップは UNIX システム管理についての基礎的な理解を前提とするため、他の人の助けが必要になることもあります。ルートになって以下を実行してください。

  1. 第 2 カレンダを作成しようとするワークステーションの /etc/passwd ファイルにダミーエントリを追加します。

    名前、ダミーユーザ ID 等を指定する必要があります。

  2. cm および rpc.cmsd のプロセスを停止します。

  3. 新しいダミーユーザとしてログインし、新しいカレンダマネージャを起動します。

  4. グループ用のアクセスリストとパーミッションを編集します。

  5. カレンダ名をブラウズリストに追加します。

  6. ログアウトし、自分自身のログイン名で再びログインします。

    これで新しいカレンダを表示できます。

ワークステーション間でのカレンダの共用

ユーザがワークステーション間を移動し、しかもユーザの実際のカレンダには常にアクセスしたい場合、各ワークステーションでカレンダマネージャを実行していなければなりません。複数のワークステーションからユーザのカレンダにアクセスするには、下記の手順を実行します。

  1. ユーザの一次ワークステーションで、リモートワークステーションにあるユーザのカレンダに完全なアクセスリストのパーミッションを与えます。

    たとえば、ユーザ Egret には、work という名前のワークステーションに実際のカレンダがあり、sea および ocean という名前のリモートワークステーションにアカウントとカレンダがあると想定します。このユーザは egret@sea と egret@ocean を自分のカレンダアクセスリストに追加し、これらのユーザにブラウズ、挿入、および削除の完全なパーミッションを与えます。方法については、第 5 章「カレンダマネージャ」を参照してください。

  2. リモートワークステーションにログインしたとき、自分の実際のカレンダを表示します。

    完全なアクセスパーミッションがあるため、すべてのアポイントメントの読み出しや、アポイントメントの変更などが可能になります。

    前の例で、Egret が sea または ocean にログインすると、カレンダ egret@work を表示して、自分の実際のカレンダにアクセスできます。

    注 -

    リモートディスクから /usr/spool/calendar ディレクトリをマウントしないでください。これを行った場合、カレンダデータが失われることがあります。

バージョンの異なる OpenWindows とカレンダマネージャの実行

現行バージョンの OpenWindows を動作させた後で、旧バージョンの OpenWindows を動作させた場合、旧バージョンのカレンダマネージャはユーザのアポイントメントデータファイルを読み込めません。この問題を避けるには、現行バージョンのカレンダマネージャを起動する前に、下記のファイルをバックアップしてください。

/usr/spool/calendar/callog.<ユーザ名>

旧バージョンのカレンダマネージャに戻る前に、ディレクトリおよびファイルのパーミッションを保持しながら、古いファイルを復元してください。ユーザのバージョンとは異なるバージョンで動作しているカレンダを表示した場合、正常に動作するはずです。