この節では、DeskSet で利用できるツールについて説明します。
バインダの実行中にはユーザデータベースがロックされるため、一度に 1 つのバインダしか実行できません。バインダが起動できず、しかもユーザデータベースに書き込むためのパーミッションがないことを示すメッセージがコンソールに表示された場合、ユーザが他のバインダを現在実行中である可能性があります。
バインダエントリに対応すると思われるファイル形式エントリが表示されない場合、その理由はおそらく、バインダがそのバインダエントリを読み込む前に、そのエントリのコピーを読み込んだためです。重複したエントリがあると、バインダは最初に読み込んだエントリだけを使います。バインダが読み込んだ最初のエントリは、ベースウィンドウにあるスクローリングリストの最初のバインダエントリと必ずしも一致しません。したがって、 「コピー」ボタンを使ってエントリを複写する際には、注意が必要です。特定のバインダエントリ用のエントリが表示されない場合は、重複したエントリを見つけて削除してください。
計算ツールが、ゼロ除算などのエラーを検出した場合、Error という語が表示されます。計算ツールにこれ以降の計算を実行させるには、Clr キーで計算ツールをクリアしなければなりません。
この節では、カレンダマネージャの基本的なトラブルについて説明します。
カレンダマネージャは、次の 2 つから構成されます。
rpc.cmsd (カレンダマネージャサービス) と呼ばれるデータベースマネージャ。これは、カレンダマネージャ用の情報を管理します。
cm と呼ばれるカレンダマネージャのアプリケーション自身。
カレンダマネージャのアプリケーションは、カレンダマネージャサービスがなくては機能しません。
カレンダマネージャがアポイントメントを表示しない場合、またはコンソールウィンドウに RPC のタイムアウトメッセージが表示された場合、rpc.cmsd が動作していないことがあります。ユーザの構成を検査するには、次の手順に従ってください。
コマンドツールまたは シェルツールをオープンします。
コマンドツールやシェルツールについては、第 6 章「コマンドツール、シェルツール、 コンソールウィンドウ」を参照してください。
システムプロンプトに続けて、 ps -e | grep rpc.cmsd と入力して Return キーを押します。
これは、文字列 rpc.cmsd が収められているすべてのプロセスを表示します。
ウィンドウに表示されたリストを参照します。
カレンダマネージャのサービスプロセスが収められたリストを図 A-1 に示します。ps リストのエントリ grep rpc.cmsd は無視できます。
rpc.cmsd プロセスを実行していない場合、次のステップに従ってください。
カレンダマネージャのアプリケーションを実行している場合、ウィンドウメニューから「終了」を選択してカレンダマネージャを終了してください。
ルートになります。
システムプロンプトに続けて、vi /etc/inetd.CONF と入力します。
エントリ Rpc.cmsd を捜します。
指定されたパス名が正しく、かつ、そのパス名に Rpc.cmsd エントリが存在することを確認してください。存在しない場合、Rpc.cmsd の存在する場所を指すように、パスを変更してください。次のように入力して、inetd のプロセス ID を表示してください。
ps -e | grep inetd |
次のように入力して、inetd.CONF ファイルを再び読み込んでください。
kill -1 inetd-pid |
カレンダマネージャを再起動します。
カレンダマネージャサービスが現在動作中であることを確認するため、 ps -e | grep rpc.cmsd と入力して、Return キーを押します。
SunOS をアップグレードする場合、下記のディレクトリをバックアップして、その情報を保存しなければなりません。/var/spool/calendar
どのバックアップメディアを使うかはユーザの自由です。オペレーティングシステムのアップグレードが終了してから、このディレクトリを復元してください。
アポイントメントが表示されない場合、必要に応じて、インストールスクリプトを実行したことを確認してください。詳細については、「RPC 問題とカレンダマネージャのインストール」を参照してください。下記の手続きを行う前に、まず、カレンダマネージャの再起動を行なってください。
それでもアポイントメントが表示されず、しかもカレンダマネージャのヘッダに文字列 NO NAME が表示されている場合、おそらく /usr/spool/calendar ディレクトリおよびファイルのパーミッションが不正です。下記のステップで、パーミッションを確認してください。
ls -lsa /usr/spool と入力し、ディレクトリ /usr/spool/calendar のパーミッションを検査します。
パーミッションは、正確に drwxrwsrwt でなければなりません。これはデーモングループ内のデーモンが所有していなければなりません (必要ならば、システム管理者に確認してパーミッションを変更してください)。
カレンダデータベースのパーミッションを検査するには、次のように入力します。
ls -lsa /usr/spool/calendar/callog.<ユーザ名> |
<ユーザ名> はユーザの名前に置き換えてください。たとえば、次のように入力します。
ls -lsa /usr/spool/calendar/callog.egret |
パーミッションは、正確に -r--rw---- でなければなりません。また、このファイルはユーザとデーモングループによって所有される必要があります。
カレンダマネージャのリモートアクセスに関するトラブルには、基本的に 2 つの症状があります。
ブラウザアクセスできると考えられるリモートカレンダを表示しようとするが、アポイントメント時間しか表示されない。
アクセスできると考えられるリモートカレンダ上で、アポイントメントを挿入、削除、または変更しようとするが、カレンダマネージャは、アポイントメントエディタのフッタ内に「アクセスは拒否されました ... 」というエラーメッセージを表示する。
これらのアクセス問題を処置しようとした場合、3 つの項目について調べてください。
メールドメインの概念を採用している NIS または DNS のシステムを使っている場合、ユーザドメイン内でカレンダを表示しようとしているか、または表示リスト内のドメインを指定したことを確認してください。たとえば、ユーザドメイン内でユーザ Rob のカレンダを表示しようとしている場合、Rob@host をそのまま指定できます。Eng と呼ばれるドメイン内にいて、Rob は Corp と呼ばれるドメイン内にある場合、表示リスト内に rob@host.Corp を指定する必要があります。
リモートカレンダの所有者がユーザにブラウズ、挿入、削除のアクセスを許可したことを確認してください。
アクセスを行うためには、次の 2 つの条件が満足されていなければなりません。
アクセスリスト内の名前は、user@host または単に user の形式でなければなりません。なお、アクセスリスト内の名前が単に user の場合、ネットワーク上でそのユーザ名の人にアクセスが許可されます。NIS または DNS のシステムを使っている場合、アクセスリスト内のユーザ名が、user@domain または user@name.domain の形式でリストされていないことを確認してください。
カレンダの所有者は、「アクセスリストとパーミッション」のプロパティウィンドウの「適用」ボタンの上でセレクトボタンでクリックしなければなりません。ユーザのワークステーションとリモートワークステーションの両方で、ユーザ ID とグループ ID を検査してください。これらの ID は、両方で一致しなければなりません。
次のように、各ワークステーション上でユーザ ID とグループ ID を決定してください。
ファイル /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 でなければなりません。
NIS システムを使っており、しかもファイル /etc/passwd にエントリがなく、/etc/passwd の最後の行が「+」で始まる場合、NIS passwd エントリのエントリを検査してください。NIS のユーザエントリを決定するには、コマンドツールまたはシェルツールに ypmatch username passwd と入力してください。
たとえば、ユーザ Egret の NIS パスワードエントリを見つけるには、次のとおりに入力してください。
ypmatch egret passwd |
システムがユーザエントリで応答した場合、ユーザ ID は 3 番目のフィールドであり、グループ ID は 4 番目のフィールドです。
ワークステーションに第 2 カレンダを追加したい場合、そのカレンダ用のダミーユーザを作成する必要があります。たとえば、ユーザの作業グループ全体に対するアポイントメントに、第 2 カレンダを追加したいことがあります。
ダミーユーザと新しいカレンダを作成するには、下記のステップを実行します。これらのステップは UNIX システム管理についての基礎的な理解を前提とするため、他の人の助けが必要になることもあります。ルートになって以下を実行してください。
第 2 カレンダを作成しようとするワークステーションの /etc/passwd ファイルにダミーエントリを追加します。
名前、ダミーユーザ ID 等を指定する必要があります。
cm および rpc.cmsd のプロセスを停止します。
新しいダミーユーザとしてログインし、新しいカレンダマネージャを起動します。
グループ用のアクセスリストとパーミッションを編集します。
カレンダ名をブラウズリストに追加します。
ログアウトし、自分自身のログイン名で再びログインします。
これで新しいカレンダを表示できます。
ユーザがワークステーション間を移動し、しかもユーザの実際のカレンダには常にアクセスしたい場合、各ワークステーションでカレンダマネージャを実行していなければなりません。複数のワークステーションからユーザのカレンダにアクセスするには、下記の手順を実行します。
ユーザの一次ワークステーションで、リモートワークステーションにあるユーザのカレンダに完全なアクセスリストのパーミッションを与えます。
たとえば、ユーザ Egret には、work という名前のワークステーションに実際のカレンダがあり、sea および ocean という名前のリモートワークステーションにアカウントとカレンダがあると想定します。このユーザは egret@sea と egret@ocean を自分のカレンダアクセスリストに追加し、これらのユーザにブラウズ、挿入、および削除の完全なパーミッションを与えます。方法については、第 5 章「カレンダマネージャ」を参照してください。
リモートワークステーションにログインしたとき、自分の実際のカレンダを表示します。
完全なアクセスパーミッションがあるため、すべてのアポイントメントの読み出しや、アポイントメントの変更などが可能になります。
前の例で、Egret が sea または ocean にログインすると、カレンダ egret@work を表示して、自分の実際のカレンダにアクセスできます。
リモートディスクから /usr/spool/calendar ディレクトリをマウントしないでください。これを行った場合、カレンダデータが失われることがあります。
現行バージョンの OpenWindows を動作させた後で、旧バージョンの OpenWindows を動作させた場合、旧バージョンのカレンダマネージャはユーザのアポイントメントデータファイルを読み込めません。この問題を避けるには、現行バージョンのカレンダマネージャを起動する前に、下記のファイルをバックアップしてください。
/usr/spool/calendar/callog.<ユーザ名>
旧バージョンのカレンダマネージャに戻る前に、ディレクトリおよびファイルのパーミッションを保持しながら、古いファイルを復元してください。ユーザのバージョンとは異なるバージョンで動作しているカレンダを表示した場合、正常に動作するはずです。
時計ツールの秒数表示は、システム性能に悪影響を与えることがあります。
ワークスペースの色が黒の場合、時計ツールがワークスペース上のアイコンのときに見えなくなります。時計ツールアイコンを、ワークスペースの色ではなく、ウィンドウのバックグラウンド色でペイントする方法については、clock のマニュアルページを参照してください。
この節では、Deskset のアプリケーションから別のアプリケーションにドラッグ&ドロップを試みるときに発生するエラーメッセージについて説明します。
サーバが一定時間内に受信アプリケーションと接続できない場合、このメッセージが表示されます。XView アプリケーションに対するデフォルトのタイムアウト値は 3 秒です。
ユーザの ‾/.Xdefaults ファイルに 1 行を追加することによって、この値は変更できます。この値を 5 秒に変更したい場合、
Selection.Timeout 5 |
という行を ‾/.Xdefaults ファイルに追加し、コマンド行から xrdb ‾/.Xdefaults と入力して、新しいタイムアウト値をサーバに設定してください。
受信アプリケーションのドラッグ&ドロップのターゲットが送信側に応答していない場合、このメッセージも表示されます。この場合、受信アプリケーションを再起動することによって、問題が解決します。
ドラッグされたオブジェクトがルートウィンドウにドロップされました。通常、この場合はファイルマネージャはそのアイテムがオープンされるとみなしますが、送信側アプリケーションはこれをエラーとみなします。
ドラッグ&ドロップのコネクションを確立しようとしているとき、原因不明の内部エラーが発生しました。
ドラッグ&ドロップを実行中に原因不明の内部エラーが発生しました。ドラッグ&ドロップ操作をもう一度試みてください。
この節では、ファイルマネージャに共通の問題点に対する解決策を説明します。
ファイルマネージャの「ファイル」メニューから「フォーマット」を使ってフロッピーディスクをフォーマットしようとしても正常に動作しない場合、ユーザのシステムはフォーマットプログラムが動作できるように設定されていない可能性があります。システム管理者に確認してください。
バインダでファイルのアイコンを変更しても、ファイルマネージャには変化がない場合、バインダの変更を保存した後でファイルマネージャを再起動したかどうか確認してください。ファイルマネージャをすでに再起動していた場合、バインダで変更内容を再検査してください。変更したエントリが、バインダの「保存 (Save)」ボタンでユーザデータベースに保存されたことを確認してください。また、表示されたファイルが、バインダで変更されたファイルのクラスに本当に分類されるものかどうかも確認してください。
ファイルマネージャが 3 種類の総称アイコン (フォルダ、アプリケーション、および文書) しか表示しない場合、ファイルマネージャはバインダのデータベースとの接続に失敗したことになります。問題の発生場所を示すエラーメッセージが表示されているかどうか、コンソールウィンドウを調べてください。
フロッピーディスクまたは CD のウィンドウを削除した場合、「フォルダ変更」メニューのボタンからこれらのウィンドウを選択して、再表示することができます。これらは、 「フォルダ変更」メニューのアプリケーション固有の部分に常に表示されています。 「フォルダ変更」メニューの使い方については、第 2 章「ファイルマネージャ」を参照してください。
ファイルマネージャを使って、ファイルを他のアプリケーションにドラッグ&ドロップし、ファイルマネージャのフッタにエラーメッセージ「ドラッグ&ドロップ: ターゲットが正しくありません。」が出力された場合、そのファイルは、ファイル形式を認識しない場所またはドロップ操作をサポートしない場所にドロップされたことになります。
ファイルの内枠に表示されるはずのファイルが表示されない場合、これらのファイルの表示を抑制できるファイルマネージャのプロパティウィンドウから表示フィルタパターンを指定していないことを確認してください。フィルタが指定されると、ファイルマネージャウィンドウのヘッダには常にフィルタが表示されます。この問題を解決するには、「表示」-> 「アイコン形式で名前順」を選択してみてください。
リモートシステム間でのファイル転送にトラブルがある場合、ユーザはファイル、ディレクトリ、またはシステムにアクセスするための適切なパーミッションを持っていない可能性があります。あるいは、そのリモートシステムはネットワークを通じてアクセスできない可能性があります。ファイルを所有する人 (または、ファイルの転送を依頼した人) に連絡して、転送が可能となるようにパーミッションを変更してください。リモートシステムがユーザのネットワークで使えるかどうかを判断するには、システム管理者に連絡してください。
ファイルマネージャが内容によるファイル表示を行っているとき、ファイルの最初の画面を表示できるよう、これを読み出して圧縮する必要があります。Sun アイコン、X Bitmap、および X Pixmap ファイルに関しては、圧縮作業はかなり高速に行われます。しかし、Sun の大きなラスタイメージの圧縮には少し時間が必要です。したがって、アイコンファイルだけを見れば十分な場合、「現在のフォルダ設定」と「新しいフォルダのデフォルト」のプロパティで、内容表示の設定は「モノクロアイコン」と「カラーアイコン」だけを選択します。
イメージツールを実行しようとして下記のメッセージを受け取った場合、XIL パッケージをインストールする必要があります。
ld.so.1: imagetool: can't find file libxil.so.1 killed |
システム管理者に確認してください。
複数バージョンのメールプログラムを実行する場合、メールツールはユーザの In-Box の状態について混乱することがあります。メールツールが In-Box のオープンに長時間を要する場合、メールツールのロックファイルを削除しなければならないことがあります。 「変更内容を保存」操作に十分なディスク容量がない場合、現在のメールファイルからメッセージを除去する必要があります。この節では、これらの問題の認識と訂正の方法について説明します。さらに、メールツールの In-Box を見つけるディレクトリや、メールツールまたはウィンドウシステムのクラッシュ時にクリアまたは失われた、作成中のメールメッセージを見つけるディレクトリについても説明します。
同時に複数バージョンのメールツール (またはメールツールアプリケーションとメールプログラム) を実行した場合、メールツールアプリケーションの 1 つを「変更内容を保存」または「終了」するように、メールツールアプリケーションから警告を受け取ることがあります。これは、両方のバージョンが In-Box を変更しようとしたためです。In-Box の状態についての混乱の発生を避けるには、警告指示に従ってください。
別のメールツールやメールプログラムを実行する前に、メールツールの「処理終了」または「変更内容を保存」を選択しなかった場合、メールツールを終了するように警告指示されます。変更内容を保存した場合、メールツールを「終了」するか、または 「変更内容を保存」を行なって元の状態を保つかを選択できます。
メールツールの終了を避けるには、毎日の終り、またはマシンにログインしてリモートからメールを読みそうなときに、「ファイル」メニューから 「処理終了」を選択する習慣をつけてください。
「処理終了」の選択を忘れ、メールを読むためにリモートからマシンにログインした場合、下記のステップに従うことによって、メールツールに 「処理終了」を選択するよう指示できます。
シェルツールのプロンプトから、 ps -e | grep mailtool と入力し、Return キーを押します。
図 A-2 に示すようなリストが出力されます。
(grep mailtool のリストではなく) mailtool の行の左側のカラムから、プロセス番号 (PID) を見つけます。
プロセス番号は各行の最初の数字です。
kill -USR1 PID と入力して、Return キーを押します。
上の例ではプロセス番号は 1431 であるため、次のように入力します。 kill -USR1 1431
いつものように、リモート位置からメールを読み取ります。
メールツールを次にオープンしたとき、リモート位置から In-Box に対して行なった変更内容が組み込まれ、メールツールの一部として記録されます。
上記のステップは、DeskSet のメールツールアプリケーションでのみ有効です。他のバージョンのメールツールにこれらのステップを使った場合、メールツールが停止します。
メールユーティリティではロックファイルを使って、複数のプロセスがユーザのメールスプールファイルを同時に変更することを防止します。メールツールが突然終了した場合、ロックファイルはそのまま残されます。
In-Box を明確に要求したときに、または「ファイル」メニューから 「処理終了」を選択した後でメールツールをオープンしたときに、メールツールによる In-Box のオープンに長時間を要する場合、ロックファイルを調べてください。ディレクトリ /var/mail に <ユーザ名>.lock という名前のファイルがないか探してください。ここでの <ユーザ名> はユーザのログイン名です。
このファイルを削除するには、システムプロンプトに続けて次のように入力します。
rm /var/mail/<ユーザ名>.lock. |
たとえば、<ユーザ名> が mary の場合、次のように入力します。
rm /var/mail/mary.lock. |
あるいは、ファイルマネージャ内のロックファイルを見つけ出して、これをごみ箱 にドラッグして削除します。
メールツールの In-Box のデフォルトの位置は /var/mail/<ユーザ名> です。環境変数 $MAIL が存在する場合、メールツールはこの値を In-Box の位置として使います。
メールツールアプリケーションまたはウィンドウシステムがクラッシュしたとき、メールメッセージが作成中であった場合、ホームディレクトリ内のファイル dead.letter から、メッセージのコピーを回復できます。ただし、80 個の編集情報ごとにアプリケーションがファイルに記録するため、最後の 80 個分の編集情報は失われることがあります。
作成ウィンドウの「クリア」ボタンの上でセレクトボタンをクリックするたびに、または作成ウィンドウの「送信」メニューから「メッセージのクリア」を選択するたびに、ユーザのメッセージはファイル dead.letter に保存されます。
dead.letter および保存変数の詳細については、mail のマニュアルページを参照してください。
「ファイル」メニューから 「変更内容を保存」や 「処理終了」を選択したり、あるいはメールフォルダを切り替えることによって変更内容を保存しようとしたりして、メールツールからディスク容量の尽きたことを警告された場合、現在のメールファイルからメッセージを除去して、保存できるサイズにまで小さくしなければなりません。
メッセージは、削除または移動によって除去できます。大きなメッセージを除去するのが最も効果的です。「表示」メニューの「表示順序」サブメニューから「サイズ」を選択することによって、最も大きなメッセージを見つけ出すことができます。
大きすぎるファイルをメールツールのアタッチメントウィンドウにドラッグ&ドロップした場合、メールツールがスワップ領域を使い果たすことがあります。この対策としては、スワップ領域を増大させることです。
バインダデータベース内にあるファイルのプリントスクリプトが不適切な場合 (このファイルは ASCII ファイルではなく、おそらく /usr/openwin/lib/cetables にある)、印刷ツールは、そのファイルをプリントしようとすると停止してしまいます。プリントスクリプトには $FILE、$PRINTER、または $COPIES 変数が存在しないことがあります。バインダを使ってプリントスクリプトを変更する方法については、第 16 章「バインダ」を参照してください。
ファイルをプリントし、そのプリンタでは適切なフィルタが利用できない場合、エラーメッセージが返されます。
スナップショットでの潜在的な問題点は、他のアプリケーションでは使えないようなサイズのラスタファイルを作成することです。以下でこの問題について説明します。
他のアプリケーションでスナップショットファイルを使うことが困難な場合があります。その原因は、グレースケールモニタまたはカラーモニタからのスナップショットを白黒画像しか扱えないアプリケーションに組み込もうとしたためです。
ラスタファイルには高さ、幅、および深さの 3 つのディメンションがあります。白黒のラスタファイルは深さ 1 ビットです。グレースケールおよびカラーのラスタファイルは、通常、深さ 8 ビットです。自然色のラスタファイルは深さ 24 ビットです。4 ビットの画面でスナップショットを取った場合、これは 8 ビットのラスタファイルとして保存されます。
ラスタファイルの深さは、シェルツールまたはコマンドツールのプロンプトで file <ラスタファイル名> と入力するか、またはファイルマネージャからファイルを選択して 情報ウィンドウを表示することによって調べられます。図 A-3 に示した例では、最後が .rs で終わるすべてのファイルのファイル特性が示されています。このリストには、8 ビットのラスタファイル (snapshot.rs) が 1 つあり、残りはすべて 1 ビットのファイルです。
ある画像を、ユーザのモニタと同じ深さに変換する最善の方法は、イメージツールを使うことです。スナップショットを取り、それを表示します。カラー項目から「モノクロ」を選択して、「保存」ボタンを押します。第 13 章「イメージツール」を参照してください。
この節では、テープツールに関して発生する共通の問題点、およびその可能な解決策について説明します。
tar テープからファイルを読み出しているときに checksum エラーを受け取った場合、テープ上のブロックサイズとユーザの指定したブロックサイズが一致していない可能性があります。
ブロックサイズを訂正するには、テープツールのプロパティウィンドウからブロック I/O を選択します。表示されるテキストフィールドで、(テープからの) 正しいブロックサイズを入力してください。
テープからファイルを取り出し、これらのファイルがユーザの指定する宛先ディレクトリにコピーされない場合、テープの内容をリストし、ファイル名の前に絶対パス名が付けられているかどうか確認します。絶対パス名を持つファイルを取り出したとき、そのパスは宛先ディレクトリとして使われます。
システムインストール時にテープ装置を接続していなければ、テープ装置名は自動的にシステム構成に取り込まれません。
最初のシステムインストールの後でテープ装置を追加したが、その後でシステムを再起動しなかった場合に、このエラーメッセージが表示されます。システムを再構成して新しいテープ装置名を組み込むには、システムをシャットダウンして次のようなフラグを使用して再起動して下さい。
OK プロンプトに対して次のように入力します。
boot -r |
boot> プロンプトに対して次のように入力します。
b -r |