デスクトップは、高度にネットワーク化された環境で十分動作するように設計されています。デスクトップのアーキテクチャにより、システム管理者はネットワーク全体にコンピューティング・リソースを分散させることができます。その中には次のものが含まれています。 ネットワーキング「サーバ」も参照してください アプリケーション アプリケーションのデータ・ファイル デスクトップ・セッション・サービス（ログイン・マネージャやファイル・マネージャなどのデスクトップ・アプリケーション） ヘルプ・サービス。ヘルプのデータ・ファイルは中央のヘルプ・サーバに置くことができます。 オペレーティング・システムはさまざまなネットワーキング・サービスを提供します。その中には、分散ファイル・システムとリモート実行も含まれます。Ｘサーバは追加のネットワーキング機能を提供します。その中には、リモート・ディスプレイへのアクセスやセキュリティ・サービスも含まれます。 デスクトップは、これらのネットワーキング機能の最上部にユーザ・インタフェースを重ねます。このインタフェースとその基となるアーキテクチャの目的は、次のようなネットワーク・システムを構築することです。 簡単に使用できること。ネットワーク内でアプリケーションとデータの位置を気にすることなくアプリケーションを実行し、データ・ファイルにアクセスすることができます。 簡単に管理できること。デスクトップは、システムがリモート・データとアプリケーションを簡単に検索できるようアプリケーション統合ツールとネットワーク検索パスを提供します。さらに、デスクトップのファイル名のマッピング・プロセスは、サーバが多数含まれる複雑なネットワークの管理を簡単にします。 柔軟性があること。デスクトップの管理機能が共通ネットワーク環境に合うように設計されていると、デスクトップは他のカスタマイズされたネットワーク構成を多く取り入れることができます。 ネットワーキングにより特定のディスプレイにいるユーザは、他のシステムに分散されたさまざまなコンピューティング・サービスにアクセスできるようになります。たとえば、次のようなサービスにアクセスできます。 デスクトップ・セッションとそのアプリケーション（たとえば、ワークスペース・マネージャとファイル・マネージャ） 他のアプリケーション データ・ファイル ネットワーキングでは、他のひとつ以上のシステムにコンピューティング・サービスを提供するシステムを説明する用語として サーバ定義 サーバ を使用します。システムがサーバからサービスを受ける場合、それはそのサーバの クライアント定義 クライアント と呼びます。 複雑なネットワークでは、システムはネットワーク全体の多数のシステム上にあるサービスを使用することもあります。さらに、システムは特殊なタイプのサーバ（たとえばセッション・サーバ）として動作したり、クライアント（たとえばアプリケーション・サーバのクライアント）になることもあります。 デスクトップ環境では、一般的なネットワーク構成に次の主要コンポーネントのうちのいくつかの組み合わせを含んでいます。 ディスプレイ ここでＸサーバを実行します。 ログイン/セッション・サーバ セッションサーバログイン ここでデスクトップ・アプリケーション（ログイン・マネージャやワークスペース・マネージャなど）を実行します。 アプリケーション・サーバ サーバアプリケーションアプリケーション・サーバ定義 ここで他のアプリケーションを実行します。 ファイル・サーバ サーバファイルファイル・サーバ ここにアプリケーションが使用するデータが格納されています。 もっとも一般的なネットワーク構成のひとつには、アプリケーション・サーバにアクセスするシステムがあります。 は、アプリケーション・サーバを使用しているワークステーションを示します。Ｘサーバとデスクトップ・セッションは、ワークステーション上で実行中です。

ネットワークはまた、 ファイル・サーバ ファイル・サーバを使用して大量のデータを保存します。このデータは、アプリケーション・サーバ上で実行中のアプリケーションや、デスクトップ・アプリケーションによって使用されることがあります（たとえば、ファイル・マネージャは[ファイル・マネージャ]ウィンドウでデータ・ファイルを表示するために、データ・ファイルにアクセスする必要があります）。

Ｘ端末セッション・サービスの取得 Ｘ端末はＸサーバを実行し、別のシステムからデスクトップ・セッション・サービスを取得します。

デスクトップには柔軟性があるので、もっと複雑なネットワーク構成をサポートできます。ファイル・サーバに加えてアプリケーション・サーバで使用可能なさまざまなサービスの提供もします。

ディスプレイ Ｘサーバを実行中のシステム。 ログイン・サーバとセッション・サーバ デスクトップ・セッション（ログイン・マネージャ、セッション・マネージャ、ウィンドウ・マネージャ、ファイル・マネージャなど）を実行中のシステム。 アプリケーション・サーバ アプリケーションが実行されているシステム。実行ホスト とも呼ばれます。 ファイル・サーバ アプリケーションのデータ・ファイルが格納されているシステム。 ヘルプ・サーバ サーバヘルプヘルプ・サーバ ヘルプ・データ・ファイルが格納されているシステム (アクション) データベース・サーバアクション・サーバ、「データベース・サーバ」も参照してくださいデータベース・サーバ アクションとデータ型定義が入っているファイルが格納されているシステム アイコン・サーバサーバアイコンアイコン・サーバ アイコン・ファイルが格納されているシステム ネットワークには、パスワード・サーバ、メール・サーバ、ビデオ・サーバなどの追加のサーバが含まれている場合があります。 デスクトップ・ネットワーキングを構成するための一般的な手順としては、次の３つがあります。 基本オペレーティング・システムのネットワーク・サービスを構成します。 デスクトップが依存しているオペレーティング・システムによって提供されるネットワーク・サービスがあります。 を参照してください。 デスクトップ・ネットワーキングのソフトウェアとサービスをインストールし、設定します。 設定中のクライアントやサーバのシステムの種類に関係なく、デスクトップが必要とするサービスがあります。 を参照してください。 サーバまたはクライアントの特定の型を設定します。 たとえば、アプリケーション・サーバを構成するには、ファイル・サーバを構成する場合とは異なる手順が必要です。 を参照してください。 デスクトップには、次の基本ネットワーキング構成が必要です。 ユーザは、セッション・サーバ上と、デスクトップ・サービスをセッション・サーバに提供する各システム上にログイン・アカウントを持っていなければなりません。ユーザは、すべてのクライアントとサーバのシステムで同じユーザIDとグループIDを持っていなければなりません。 システムは、セッションおよび他のアプリケーションによって使用されるデータが入っているリモート・ファイル・システムにアクセスできなければなりません。 lp プリント・スプーラは、リモート・プリンタにアクセスできるように構成されていなければなりません。 sendmail は、電子メール・サービス用に構成されていなければなりません。 Ｘ認証が設定されていなければなりません。 この節では、デスクトップ・ネットワーキングに必要なログイン・アカウントについて説明します。 ユーザは、次のコンポーネントにログイン・アカウントを持っていなければなりません。 デスクトップにサービスを提供しているすべてのシステム。この中には、アプリケーション・サーバ、ファイル・サーバ、およびネットワーク・プリンタを提供するシステムも含まれます。 ユーザがアクセスできるすべてのセッション・サーバ。通常、セッション・サーバはＸ端末で使用されます。 UNIX ユーザは、ログイン名と UIDユーザID 数値ユーザID (UID) により識別されます。デスクトップ・ネットワークでは、ユーザはすべてのクライアントとサーバのシステム上に同じログイン名と UID を持っていなければなりません。 UNIX ユーザは、ひとつ以上のログイン・グループにも割り当てられます。各グループはグループ名と GIDグループID 数値グループID (GID) を持っています。デスクトップ・ネットワークでは、すべてのシステムは一貫したグループ名とグループIDを使用しなければなりません。 詳細については、 id(1) または id(1m) のマニュアル・ページを参照してください。 デスクトップは、システム間でファイルを共有するために NFS を使用します。共有ファイルが入っているネットワークのすべてのファイル・システムを識別し、確実に適切なシステムに正しくマウントしなければなりません。 ファイル共有NFSファイルリモート・アクセスファイルマウント 一般的に、次のリモート・ファイル・アクセスを提供しなければなりません。 ホーム・ディレクトリ共有 ユーザのホーム・ディレクトリは、すべてのデスクトップのクライアントとサーバのシステムによって共有されなければなりません。これは、次の理由により必要です。 ホーム・ディレクトリには、リモート・システム上のアプリケーションによってアクセスされなければならないデータ・ファイルがあります。たとえば、データ・ファイルを使用するアプリケーションは、デフォルトのデータ・ファイルの位置としてよくホーム・ディレクトリを使用します。 認証ディレクトリdtspcd認証ディレクトリ ホーム・ディレクトリは、デフォルトの dtspcd 認証ディレクトリです。dtspcd の詳細については、 を参照してください。 ホーム・ディレクトリにはないデータ・ファイルにアクセスする必要がある場合、これらのデータ・ファイルはデータ・ファイルで動作するデスクトップのクライアントとサーバのシステムによって共有されなければなりません。 デスクトップのインストールディレクトリと構成ディレクトリ（/usr/dt と /etc/dt）は、アプリケーションのすべてが同じデスクトップ構成ファイルにアクセスするように、すべてのデスクトップのクライアントとサーバのシステムによって共有されなければなりません。 デスクトップ・ネットワークは、ネットワーク上のすべてのクライアントとサーバのシステム間で共有されている単一のホーム・ディレクトリを持っている場合に、もっとも効率的に動作します。 ネットワーク・ホーム・ディレクトリにより、ユーザは個人用のカスタマイズと構成を失うことなく、ネットワークで別のシステムを使用することができます。これは、個人用のカスタマイズと、前のセッションを復元するのに必要な情報を、ホーム・ディレクトリのサブディレクトリに保存するからです。 次のものにも共通ホーム・ディレクトリが必要です。 デフォルトのＸ認証機構。 を参照してください。 デスクトップのサブプロセス・コントロール・デーモン。このデーモンはリモート・アプリケーションの起動に含まれますが、ユーザのホーム・ディレクトリに書き込むことができなければなりません。 同じ名前を使用して、すべてのシステムからデータ・ファイルにアクセスできるようにネトワークを構成しなければなりません。これは、ファイル名の一貫性 を提供するものとして知られ、適切な シンボリック・リンクファイル名の一貫性 シンボリック・リンクを作成することにより通常は達成されます。たとえば、ディレクトリの実際のマウント位置へのシンボリック・リンクを作成することにより、各ユーザのホーム・ディレクトリが /users/login_name として使用可能になるように各システムを構成できます。 デスクトップは、ローカル・プリンタまたはリモート・プリンタにアクセスするために lp プリント・スプーラlp プリント・スプーラを使用します。lp スプーラの構成については lpadmin(1m) のマニュアル・ページを参照してください。 プリンタテスト デスクトップのグラフィカル・インタフェースを使用して印刷を試みようとする前に、lp コマンドlp コマンドを使用してすべてのプリンタに正しく印刷できることをテストしてください。 プリンタデバイス名 一貫したプリンタ・デバイス名を使用することを強く推奨します。たとえば、直接接続されているシステム上で特定のプリンタが Postscript1 とされている場合、そのプリンタにリモート・アクセスしている他のすべてのシステムも Postscript1 という名前を使用してください。 デスクトップのメール・プログラムは、システム間でメールを配信するために sendmail を使用します。電子メールの接続性の構成方法の詳細については、 sendmailsendmail(1m) のマニュアル・ページを参照してください。 デスクトップからメールを送信または受信しようとする前に、mailxmailx コマンドを使用してメールを正しく送信および受信できることをテストしてください。 デスクトップは、ローカル・ディスプレイにアクセスするためのリモート・アプリケーション（Ｘクライアント）に認証を与えるのにデフォルトのＸ機構を使用します。Ｘ機構を構成するのにもっとも簡単な方法は、各ユーザに対してネットワーク・ホーム・ディレクトリを提供することです。これにより、次の要件が確実に満たされます。 ユーザは、HomeDirectory/.Xauthority ファイルへの書き込み権と読み取り権を持っていなければなりません。 アプリケーション・サーバの .Xauthority ファイルには、アプリケーションが実行されるディスプレイの「マジック・クッキー (magic cookie)」が入っていなければなりません。 詳細については、 X(1) または xauth(1) のマニュアル・ページを参照してください。 この節では、デスクトップに固有のネットワーク構成要件について説明します。これらの機能は基本オペレーティング・システムではなくデスクトップによって提供されます。 この節は、次の２つの部分に分かれます。 ログイン・サービスとセッション・サービス アプリケーションとそのデータベースが必要とするサービスの構成。これには、アプリケーション、データベース、アイコン、ヘルプ・サーバとそのクライアントを含みます。 ログイン/セッション・サーバは、ディスプレイとＸサーバにデスクトップ・サービス（ログイン・マネージャ、セッション・マネージャ、ファイル・マネージャ、ウィンドウ・マネージャなど）を提供するシステムです。 一般的に、セッション・サーバはサービスをＸ端末に提供します。しかし、ネットワーク構成は、Ｘ端末とワークステーションの両方によってアクセスされるひとつ以上のサーバにセッション・サービスを集中するように設定できます。 ログイン・マネージャは、ログイン・サービスを他のディスプレイに提供するデスクトップ・コンポーネントです。ユーザがログインすると、セッション・マネージャはユーザに対して起動されます。 サーバセッションＸ端末サーバログイン ログイン/セッション・サーバとＸ端末の構成の詳細については、 を参照してください。 入力メソッド・サーバ (IMS) は dtimsstart コマンドによって起動されます。dtimsstart は、通常、スクリプト /usr/dt/config/Xsession.d/0020.dtims によって Xsession 起動時（ユーザ・ログイン時）に自動的に起動されます。 現在選択されているロケール、環境変数、構成ファイル、およびコマンド行オプションに依存して、dtimsstart は、ユーザが使用する入力メソッド・サーバの選択を可能にする選択ウィンドウを表示します。選択ウィンドウでは、リモート・システムでの入力メソッド・サーバの起動を要求することもできます。この場合、dtimsstart は、次のことを行います。 DtImsGetRemoteConf アクションを実行して、指定されたリモート・システムに登録された入力メソッド・サーバに関する情報を収集します。 選択ウィンドウに、登録されている入力メソッド・サーバの一覧を表示します。 DtImsRunRemoteIms アクションを実行して、ユーザが選択した入力メソッド・サーバを、リモート・システムで起動します。 リモート・システムで入力メソッド・サーバを検索するとき、dtimsstart は、登録された入力メソッド・サーバのみを収集します。システムに（ローカルまたはリモートで）入力サーバを登録するには、次に示すことが要件となります。 現在のロケールのエントリ・ファイルで定義されていること。各ロケールには、そのロケールをサポートする入力メソッド・サーバの一覧である固有のエントリ・ファイルがあります。ロケールのエントリ・ファイルの位置は、/usr/dt/config/ims/<locale_name> です。 システムにそれ自身のエントリ・ファイルがあること。入力メソッド・サーバのエントリ・ファイルには、入力メソッド・サーバの属性が記述されています。属性には、サポートされているプロトコル、入力メソッド・サーバが実行されるサーバ名、入力メソッド・サーバのコマンド行オプション、および入力メソッド・サーバがリモート実行を許可するかどうかの指示があります。入力メソッド・サーバのエントリ・ファイルの位置は、/usr/dt/config/ims/<ims_name> です。 ファイル書式に関する説明と例については、dtimsstart のマニュアル・ページを参照してください。 入力メソッド・サーバが見つけられるホストを定義するために、imServerHosts アプリケーション・リソースを構成することができます。このリソース（ユーザ選択のための入力メソッド・サーバを識別するときスタイル・マネージャによって使用されます）には、コンマで区切られたホスト名の一覧があります。次に例を示します。 *imServerHosts: xylo,expo この節では、デスクトップに共通のネットワーキングに必要な条件について説明します。 アプリケーション・サーバ構成サーバアプリケーションアプリケーション・サーバ データベース・サーバ構成サーバデータベースデータベース・サーバ アイコン・サーバ構成サーバアイコンアイコン・サーバ ヘルプ・サーバ構成サーバヘルプヘルプ・サーバ デスクトップが必要とするオペレーティング・システム・ネットワーク構成を提供します。 を参照してください。 ファイルネットワーキングで必要なネットワーキング〜で必要なファイル デスクトップまたはファイルの最小のセットをインストールします。 次のものをインストールしなければなりません。 共通デスクトップ環境の実行時のファイル・セット全体 または、 CDE-MIN ファイルCDE-TT ファイル CDE-MIN および CDE-TT のファイル・セット インストールとファイル・セットは、ベンダにより異なる可能性があります。 ToolTalk ファイル名データベース・サーバ・デーモン rpc.ttdbserver 用にシステムを構成します。 ファイル名データベース・サーバrpc.ttdbserver これは、デスクトップをインストールすると自動的に行われます。詳細については、 を参照してください。 サブプロセス・コントロール・デーモン（dtspcddtspcd）をインストールし、構成します。 これは、デスクトップをインストールすると自動的に行われます。詳細については、 を参照してください。 ファイルリモート・データ 必要なリモート・データをすべてマウントします。 データを使用しているアプリケーションが実行中であるシステム以外のシステムにデータがある場合、データは「リモート」だとみなされます。 たとえば、次のような場合があります。 アプリケーションがファイル・サーバにあるデータを使用する場合、それらのファイルをマウントしなればなりません。 ファイル・マネージャのアイコンがアイコン・サーバにある場合、セッション・サーバはそれらのファイルをマウントしなければなりません。 ネットワークがデスクトップ・ヘルプ・ファイルのためにヘルプ・サーバを使用する場合、セッション・サーバとすべてのアプリケーション・サーバはヘルプ・データをマウントしなければなりません。 マウント・ポイントの詳細については、次の節の を参照してください。 ファイル名のマッピング デスクトップはひとつのシステムから別のシステムにファイル名を渡す場合、そのファイル名を宛先システムにとって意味のある名前に変換、または「マップ」しなければなりません。このマッピングが必要なのは、ファイルが別のシステムの別の位置にマウントされ、そのため別の名前を使用してアクセスしなければならない場合があるためです。たとえば、sysA の /projects/big ファイルは、sysB の /net/sysA/projects/big としてアクセスされる可能性があります。 このファイル名マッピングを正しく実行するためには、次の条件のうちのいずれかひとつが真でなければなりません。 mount コマンドをファイル・システムを静的にマウントするために使用する。これらの静的マウントは、/etc/checklist、/etc/mnttab、または /etc/filesystems などのファイルで通常は構成されます。 システム間で正しく動作するファイル名マッピングの場合、ファイル・システムのマウントは一貫したホスト名を使用しなければなりません。ホストがいくつかの名前で認識される場合（たとえば別名、または異なる名前で認識される２つ以上の LAN アドレスを持っている場合）、すべてのマウントに対して同じ名前と名前形式を使用しなければなりません。 または、オートマウンタを、デフォルトの /net マウント・ポイントとしてファイル・システムをマウントするのに使用する。 または、 オートマウンタ オートマウンタを、/net 以外の位置にファイル・システムをマウントするのに使用し、DTMOUNTPOINT 環境変数をマウント・ポイントを示すために設定する。次の節の を参照してください。 オートマウンタの詳細については、automount(1m) のマニュアル・ページを参照してください。 DTMOUNTPOINT 変数使用するプロセス 次の条件が真の場合、DTMOUNTPOINT 環境変数を設定しなければなりません。 オートマウンタを、ファイル・システムをマウントするのに使用する。 かつ、リモート・ファイル・システムを /net 以外の位置にマウントする。 DTMOUNTPOINT 変数プロセスが必要とする DTMOUNTPOINT は次のようなプロセスに対して設定する必要があります。 ワークスペース・マネージャ (dtwm) とファイル・マネージャ (dtfile) などのログインするときに自動的に起動されるユーザのデスクトップ・プロセス inetd などの機構によって起動される rpc.ttdbserverrpc.ttdbserver と dtspcd などのシステム・プロセス ローカル・システムまたはリモート・システム上のデスクトップによって起動されるアプリケーション シェル・コマンド行からユーザによって起動されるアプリケーション これらのプロセスのすべてに対して DTMOUNTPOINT を設定するには、次のようにします。 ファイル /etc/inetd.conf を次のように編集します。 inetd.conf dtspcddtspcd エントリをみつけ、次の行を追加します。 -mount_point mount_point rpc.ttdbserver エントリをみつけ、次の行を追加します。 -m mount_point たとえば、オートマウンタが /nfs のようなマウント・ポイントで使用中の場合、/etc/inetd.conf のエントリは次のようになります。 dtspc stream tcp nowait root /usr/dt/bin/dtspcd /usr/dt/bin/dtspcd -mount_point /nfs rpc stream tcp wait root /usr/dt/bin/rpc.ttdbserver 100083 1 rpc.ttdbserver -m /nfs /etc/inetd.conf を再読み込みするシステム上の手続きを実行します。詳細については、inetd(1m) のマニュアル・ページを参照してください。 DTMOUNTPOINT 変数ユーザによって継承された DTMOUNTPOINT の値がユーザのログインによって継承されるように設定します。 これは、/etc/dt/config/Xsession.d に変数を設定することによって実行できます。環境変数設定の詳細については、 を参照してください。 デスクトップ サブプロセス・コントロール・サービス、「SPC」を参照してください<$nopage> サブプロセス・コントロール (SPCSPC) サービスは、クライアント/サーバのコマンド実行を提供します。 デスクトップ サブプロセス・コントロール・デーモン、「dtspcd」を参照してください<$nopage> サブプロセス・コントロール・デーモン (dtspcddtspcd) は、リモート・アプリケーションを起動するためにデスクトップによって使用されます。このデーモンは、コマンドを実行するためにリモート・クライアントから要求を受けとる inet デーモンです。inet デーモンの構成方法の詳細については、inetd.conf(1m) のマニュアル・ページを参照してください。 デスクトップ・アクション呼び出しライブラリは、リモート・アクションを呼び出すために SPC サービスを使用します。 dtspc が /etc/services と /etc/inetd.conf の両方に適切に登録されていることを確認します。 dtspcd(1m) のマニュアル・ページを参照してください。 HP-UX のみ。/usr/adm/inetd.sec を適切な方法で確実に構成します。 inetd.secinetd.sec(4) のマニュアル・ページを参照してください。 サブプロセス・コントロール・サービスに対する認証は、ファイル・システム認証に基づきます。dtspcd は、すべての SPC クライアント・システムによってもマウントされる 認証ディレクトリ にアクセスできなければなりません。 デフォルトでは、 dtspcd認証ディレクトリ認証ディレクトリdtspcd 認証ディレクトリがユーザのホーム・ディレクトリです。しかし、/etc/inetd.conf ディレクトリに -auth_dir オプションを設定することにより、別の位置を使用するように dtspcd を構成することができます。詳細については、dtspcd(1m) のマニュアル・ページを参照してください。 SPC 認証はファイル・システム認証に基づいているので、SPC サービスは分散ファイル・システムと同じ程度に安全なだけです。分散ファイル・システムを信頼していないネットワーク上のデスクトップを使用している場合、dtspcd を使用できないようにしたい場合があります。dtspcd を使用できないようにするには、/etc/services の dtspc エントリ をコメントアウトしてください。 リモート・システムでアプリケーションを起動するためにデスクトップがアクションを使用する場合、ユーザの環境変数はリモート・システムにコピーされ、アプリケーションの環境に配置されます。 デフォルトでは、環境変数のいくつかはリモート・システムにコピーされる前に変更されます。変数をアプリケーションの環境に位置付ける前に、追加のアプリケーション環境変数の処理を実行するように、アクション呼び出しコンポーネントとデスクトップのサブプロセス・コントロール・サービスの両方を構成できます。 デフォルトの構成とその変更方法の詳細については、dtactionfile(4) と dtspcdenv(4) のマニュアル・ページを参照してください。 ToolTalk のひとつのコンポーネントは、ToolTalk データベース・サーバ /usr/dt/bin/rpc.ttdbserver です。 ToolTalk データベース・サーバは、ToolTalk メッセージ・サービスによってファイル名マッピングのために使用されます。このサーバは、デスクトップがインストールされ、追加構成が不要な場合、通常は /etc/inetd.conf に登録されます。 ToolTalk データベース・サーバとその構成オプションの詳細については、rpc.ttdbserver(1m) のマニュアル・ページを参照してください。 ToolTalk メッセージ・サーバは ttsession です。デフォルトでは、このサーバには構成は必要はありません。ログイン中このサーバは Xession スクリプトによって起動されます。 ToolTalk メッセージ・サーバとその構成オプションの詳細については、ttsession のマニュアル・ページを参照してください。 ttsession カレンダ・アプリケーションのひとつのコンポーネントは、カレンダ・デーモン rpc.cmsdrpc.cmsd です。デスクトップがインストールされ、追加の構成が不要な場合、通常は /etc/inetd.conf に登録されます。 カレンダ・デーモンとその構成オプションの詳細については、rpc.cmsd(1) のマニュアル・ページを参照してください。 この節では、次のコンポーネントの特定の構成要件について説明します。 アプリケーション・サーバとそのクライアント 特定のサービスを提供するデスクトップ・サーバ — データベース・サーバ、アイコン・サーバ、ヘルプ・サーバ また、ネットワーク・アプリケーションの次の２つの特殊構成に対するネットワーキング要件についても説明します。 リモート実行ホスト フィイル・システムをマウントして実行中のアプリケーション アクション、データ型データベース、ヘルプ・ファイル、アイコン・ファイルなどのアプリケーション・デスクトップ構成ファイルを見つけるのに使用する検索パスを指定するために、デスクトップは環境変数セットを使用します。 検索パスの環境変数の使用方法の詳細については、 または dtenvvar(5) のマニュアル・ページを参照してください。 標準アプリケーション・サーバ構成において、アプリケーション・サーバにはアプリケーションに関連付けられた次のようなバイナリ・ファイルと構成ファイルが入っています。 アプリケーション実行可能ファイル app-defaults、メッセージ・カタログ、そのアプリケーションの共有ライブラリなどの標準アプリケーション構成ファイル デスクトップ構成ファイル アクションとデータ型定義ファイル アイコン・イメージ・ファイル デスクトップ・ヘルプ・データ・ファイル

デスクトップが必要とするオペレーティング・システムのネットワーク構成を提供します。 を参照してください。 サーバに対して必要な一般デスクトップ構成を提供します。 を参照してください。 アプリケーションをインストールします。 アプリケーションが自動的にそれ自身を登録しない場合は、登録手続きを実行しなければなりません。 を参照してください。 デスクトップが必要とするオペレーティング・システムのネットワーク構成を提供します。 を参照してください。 クライアントに対して必要な一般デスクトップ構成を提供します。 を参照してください。 システム共通か個人用かによって、アプリケーション・サーバをアプリケーション検索パスに追加します。 システム共通 DTSPSYSAPPHOSTS 変数を /etc/dt/config/Xsession.d/0010.dtpathsDTSPSYSAPPHOSTS 変数 に設定します。 個人用 DTSPUSERAPPHOSTS 変数を HomeDirectory/.dtprofileDTSPUSERAPPHOSTS 変数 に設定します。 たとえば、/etc/dt/config/Xsession.d/0010.dtpaths にある次の行は、SysAAA と SysBBB というホスト名が付いているシステムをアプリケーション検索パスに追加します。 DTSPSYSAPPHOSTS=SysAAA:,SysBBB: アプリケーション検索パスの設定の詳細については、次を参照してください。 通常は、アクションと、アプリケーションに関連付けられたデータ型定義、アイコン、ヘルプ・ファイルは、アプリケーションとして同じシステムにインストールされます。 たとえば、ヘルプのデータ・ファイルの一般的な構成について考えてみます。 ファイル・マネージャのヘルプ・ファイルは通常、セッション・サーバにあります。ヘルプ検索パスはセッション・サーバで適切な位置を自動的に検索するため、デスクトップはそれらのファイルを見つけます。 他のアプリケーションのヘルプ・ファイルは通常、アプリケーションとして同じアプリケーション・サーバにあります。アプリケーション検索パスを変更するとヘルプ検索パスを自動的に変更するので、セッション・サーバはそれらのファイルを見つけます。 ネットワークのどこかにデータベース（アクションとデータ型）、ヘルプ、またはアイコン・データを置きたい場合があるかもしれません。たとえば、ネットワークが複数のセッション・サーバを使用する場合、デスクトップ・アプリケーション（ファイル・マネージャ、スタイル・マネージャなど）のすべてのヘルプ・データ・ファイルが格納されているヘルプ・サーバを作成することを推奨します。こうすると、ヘルプ・ファイルを各セッション・サーバで複製する必要がなくなるため、ディスク・スペースを節約することができます。 デスクトップが必要とするオペレティーング・システム・ネットワーク構成を提供します。 を参照してください。 クライアントに対して必要な一般デスクトップ構成を提供します。 を参照してください。 データベース・ファイル、ヘルプ・ファイル、またはアイコン・ファイルをインストールします。 ファイルはシステム上のどこにでも置くことができます。しかし、システムがアプリケーション・サーバを指定すると自動的に検索されるディレクトリがあるので、次の位置を使用するとより簡単になります。 データベース・ファイル: /etc/dt/appconfig/types/language ヘルプ・ファイル: /etc/dt/appconfig/help/language アイコン・ファイル: /etc/dt/appconfig/icons/language データベース・サーバを設定する場合、コマンド (EXEC_STRING) を実行する位置を指定するためにアクションに書き込む必要があります。 を参照してください。 デスクトップが必要とするオペレーティング・サーバ・ネットワーク構成を提供します。 を参照してください。 クライアントに対して必要な一般デスクトップ構成を提供します。 を参照してください。 データベース・サーバ、アイコン・サーバ、またはヘルプ・サーバを適切な検索パスに追加します。 の で指定された位置にデータ・ファイルを格納した場合、アプリケーション検索パスを変更できます。 他の位置にデータ・ファイルを格納した場合、特定の検索パスを変更しなければなりません。 たとえば、ヘルプ・ファイルをシステム SysCCC にあるディレクトリ /etc/dt/help に格納した場合、次の行を /etc/dt/config/Xsession.d/0010.dtpaths に追加します。 DTSPSYSHELP=/net/SysCCC/etc/dt/help 検索パスの設定の詳細については、次を参照してください。 この節では、次のようなアプリケーションを実行するためにシステムを構成する方法について説明します。 アクションが入っているシステム、つまりリモート実行ホスト以外の場所にあるアプリケーション ファイル・システム・マウントに対してローカルにあるアプリケーション 典型的なアプリケーション・サーバ構成では、アクション定義はアプリケーション実行可能ファイルと同じシステムにあります。しかし、 アクションリモート・アプリケーションの実行 アクションは他のシステムにあるコマンドを実行するために書き込むことができます。この構成では、アプリケーションが入っているシステムは 実行ホスト指定 実行ホスト EXEC_HOST、「ホスト<$nopage」を参照してください> と呼びます。 アクション定義は、セッション・サーバまたはセッション・サーバにアクションとデータ型のサービスを提供するシステムに置くことができます。このシステムを データベース・サーバデータベース・ホストデータベース・サーバ または データベース・ホスト と呼びます。 アクション定義は、コマンド (EXEC_STRING) を実行する位置を指定するために EXEC_HOST フィールドを使用します。たとえば、次のアクション定義は、ホスト名が SysDDD であるシステムで xload クライアントが実行されるように指定します。 ACTION XloadSysDDD { TYPE COMMAND EXEC_HOST SysDDD EXEC_STRING /usr/bin/X11/xload -label SysDDD } EXEC_HOST フィールド複数の値EXEC_HOST が２つ以上のホスト名を指定する場合、デスクトップはアクションを実行できるホストを見つけるまで順番に各ホストで EXEC_STRING を実行しようとします。たとえば、次の EXEC_HOST フィールドはアクションが最初に SysDDD、失敗した場合は SysEEE で EXEC_STRING を実行するように指定しています。 EXEC_HOST SysDDD,SysEEE EXEC_HOST フィールドデフォルト値EXEC_HOST フィールドがアクション用に設定されていない場合、デフォルト値は %DatabaseHost% になります。%DatabaseHost% の値はデータ検索パスから取得されます。 たとえば、データベース検索パスは、/etc/dt/config/Xsession.d/0010.dtpaths に次の行を追加することによって変更されたとします。 データベース検索パスEXEC_HOST への影響DTSPSYSDATABASEHOSTS 変数EXEC_HOST への影響EXEC_HOST フィールドデータベース検索パスによる影響 DTSPSYSDATABASEHOSTS=SysAAA:,/net/SysBBB/etc/dt/appconfig/types/C SysAAA はホスト修飾子構文を使用して指定されます。つまり SysAAA: になります。検索パスのこの要素を使用して見つけられるアクション定義は、データベース・ホストを SysAAA に設定します。しかし、検索パスの /net/SysBBB… 部分を使用して見つけられるアクションは、構文にはホスト修飾子が含まれていないのでデータベース・ホストにローカル・システムを設定します。 デスクトップが必要とするオペレーティング・システムのネットワーク構成を提供します。 を参照してください。 サーバに対して必要な一般デスクトップ構成を提供します。 を参照してください。 アプリケーションをローカル実行のために適切な方法で確実にインストールします。 デスクトップが必要とするオペレーティング・システム・ネットワーク構成を提供します。 を参照してください。 サーバに対して必要な一般デスクトップ構成を提供します。 を参照してください。 アクション定義とアプリケーション・グループを作成しインストールします。 および を参照してください。 デスクトップが必要とするオペレーティング・システム・ネットワーク構成を提供します。 を参照してください。 クライアントに対して必要な一般デスクトップ構成を提供します。 を参照してください。 データベース・ホストを組み込むためにアクション検索パスを変更します。 を参照してください。 実行ホストを組み込むためにアプリケーション検索パスを変更します。 を参照してください。 標準アプリケーション・サーバ構成は、アプリケーション・サーバでアプリケーションを実行します。リモート・システムにアプリケーションをインストールし、セッション・サーバでローカルに実行するほうが望ましい場合もあります。

特別な構成は必要ありません。 アプリケーション検索パスを変更します。アプリケーションへのローカル絶対パスを使用します。 たとえば、sysAAA に登録されたアプリケーションを見つけるには、次の変数定義を使用します。 DTSPSYSAPPHOSTS=/net/SysAAA/etc/dt/appconfig/appmanager/C セッション・サーバは、app-defaults、メッセージ・カタログ、共有ライブラリなどのアプリケーションの構成ファイルにアクセスできなければなりません。