# 管理の手引き

# パッケージ・プログラムを使用したクライアント・マシンの構成

パッケージ・プログラムにより、クライアントの構成プロセスが多くの点で自動化できます。パッケージ・プログラムを使用すると、グローバル構成ファイルを定義して、多くのクライアントのローカル・ディスクの構成が簡単に行えます。

## 説明の要約

本章では、指示されたコマンド、またはプロトタイプ・ファイルの命令を使用した以下のタスクの実行方法を説明します。

クライアント・マシンのローカル・ディスクの構成 | パッケージ
ディレクトリーを定義する | D[update_code] directory owner group mode_bits
ファイルを定義する | F[update_code] file source_file [owner group mode_bits]
記号リンクの定義 | L[update_code] link actual_file [owner group mode_bits]
ブロック・スペシャル装置の定義 | B device_name major_device_number minor_device_number owner group mode_bits
キャラクター型スペシャル装置の定義 | C device_name major_device_number minor_device_number owner group mode_bits
ソケットを定義する | S socket_name [owner group mode_bits]

## パッケージ・プログラムの使用

パッケージ・プログラムは、システム独立型のプロトタイプ・ファイルを使用して、標準のディスク構成を定義します。プロトタイプ・ファイルは、どのファイルがローカル・クライアント・ディスクに常駐すべきか、どのファイルが AFS へのリンクとなるべきか、などを指示します。この後、このプロトタイプ・ファイルは、それぞれのシステム・タイプごとに構成ファイルにコンパイルされます。

すべてのクライアント・マシンが同じ構成を持つわけではありません。異なるプロトタイプ・ファイルを異なるクライアント機能 (プリント・サーバー、正規クライアント、など) に作成することも可能です。.

パッケージ・プログラムは、ローカル・クライアント・ディスクの内容を構成ファイルと比較します。何らかの相違がある場合は、 パッケージが、AFS からのファイルをディスクにコピーし、ローカル・ディスクに必要な更新を行います。パッケージ・プログラムの構成で、システム構成の一部ではないファイルを削除したり、または特定のファイル (dkload など) が更新されたときに、クライアントを自動的にリブートすることもできます。

パッケージ・プログラムでは、プロトタイプ・ファイルが作成されるまで、ある程度の時間がかかりますが、以下のような利点が生じます。

- それぞれのマシンを個々に構成する必要がなくなる。プロトタイプ構成ファイルは、すべてのマシンに適用される。
- プロトタイプ・ファイルの変更およびクライアントのリブートをするだけで、マシン構成を変更することができる。
- ディスク編成が、一連のマシン全体に渡って一様になる。
- 構成ファイルが、そのディスク上のファイル・レコード、およびシンボリック・リンクの役割をする。

### ファイル・サーバー・マシン上でのパッケージの使用

パッケージは、クライアント・マシン上で使用するように設計されていますが、ファイル・サーバー・マシンのディスクの構成に使用することもできます。しかし、構成ファイル内の参照されたファイルのいずれかが、そのファイル・サーバー上のボリュームに常駐している場合、 パッケージ・プログラムは、リブート中 (また、そのファイル・サーバーの処理、およびボリューム・サーバーの処理が再開するまで) は、そのボリュームにアクセスできなくなります。

パッケージ・プログラムがファイルにアクセスできずにアボートした場合、ファイル・サーバー・マシン上のボリュームに常駐している AFS 内のファイルへの参照を除去する必要があります。これらの制約のため、以下この章では、 パッケージ・プログラムがクライアント構成に使用されていることを前提としています。

## パッケージの概説

パッケージ・プログラムを実行する前に、3 つの主なステップを踏む必要があります。

1. 機能特定型の プロトタイプ・ファイル (および、組み込まれている任意の ライブラリー・ファイル) を作成する。
2. パッケージを MAKE ファイルに変更し、プロトタイプ・ファイルをシステム特定型の 構成ファイル にコンパイルする。
3. 適切なパッケージ構成ファイルを自動的に実行するよう、クライアント・マシンを変更する。

以下は、これらのステップの要約です。

### プロトタイプ・ファイルの作成

クライアント・マシンが実行する各種機能および役割、およびこれらの機能をサポートするローカル・ディスク構成をリストすることより始めます。サンプルの役割には、AFS アクセスを提供する標準クライアント、プリンターを駆動するプリント・サーバー、および backup スイートからコマンドを発行するバックアップ・マシンが含まれます。役割ごとに、異なる プロトタイプ・ファイル を作成します。

プロトタイプ・ファイルは、特定の役割をサポートするディスク構成を定義します。通常、プロトタイプ・ファイルは、機能特定型のファイルですが、システムからは独立しています。つまり、システム特定型の値は、変数およびライブラリー・ファイルを使用して定義することができます。そのため、変数またはライブラリー・ファイルを変更すると、その変更は パッケージ・プログラムが起動されるときに、すべての該当するクライアントに伝達されます。

サンプル・プロトタイプ・ファイルおよびライブラリー・ファイル に、保守が簡単でフレキシブルなプロトタイプ・ファイルを構築するための方法が記載されています。

### プロトタイプ・ファイルのコンパイル

プロトタイプ・ファイルは、通常、システムからは独立したファイルですが、異なるシステム・タイプの必要性を満たすために `ifdef` ステートメントが組み込まれている場合があります。プロトタイプ・ファイルは、オペレーティング・システム特定型のバージョンを生成するためにコンパイルされます。コンパイル中、 パッケージ・プログラムは、それぞれのシステム・タイプごとに適切な定義を選択し、任意の変数を実際の値と置き換えます。これらのコンパイルされた、マシン特定型のファイルを、構成ファイルと呼びます。

プロトタイプ・ファイルは、パッケージ Makefile ファイル に記載されているように、標準タイプの Makefile ファイルを使用してコンパイルされます。

### クライアントの作成

システム特定型の構成ファイルが作成されると、 パッケージ・プログラムがそのクライアント上で実行できるようになります。最初に、 パッケージのバイナリーを使用可能にし、正しい構成ファイルを指定しなければなりません。

以下に記載されているようにクライアントを変更します。

1. .package ファイルを、デフォルト構成ファイルが定義されているクライアントのローカル・ディスクごとのルート ( / ) ディレクトリーに作成する。
2. パッケージのバイナリー (/etc/package) をローカル・ディスク上で使用可能にする。
3. マシンの初期設定ファイル (/etc/rc またはこれと同等) を修正して、package プログラムへの呼び出しを組み込む。

これらのステップは、クライアント・マシンの変更 に詳細に記されています。

## パッケージのディレクトリー構造

本機能グループは、AFS インストールの手引き に推奨されているように、 パッケージ関連のファイルが、/afs/cellname/wsadmin の 3 つのサブディレクトリーの src、lib および etc に導入されていることを前提としています。

これらのディレクトリーには、いくつかのサンプル・プロトタイプ、ライブラリー、および構成ファイルが含まれており、 パッケージ・プログラムの機能を説明する手助けとなります。ただし、これは所属するセルに適したものであるとは限らず、必要に応じて修正する必要があります。

### src ディレクトリー

src ディレクトリーには、いくつかのサンプル・プロトタイプ・ファイル (構成ファイルの作成に使用される) 、プロトタイプ・ファイルの作成に使用される MAKE ファイル 、および結果としてのコンパイルされた構成ファイルが含まれます。

プロトタイプ・ファイルは、function.proto 形式の名前をとります。たとえば、minimal.proto ファイルは、 AFS の実行に必要な最小限のライブラリー・ファイルを定義し、staff.dkload.proto ファイルは、動的カーネル・ロード・プログラムを使用したクライアントの構成を定義します。プロトタイプ・ファイルは、 hosts.equiv などのシステム管理ファイルの定義を含むこともできます。

Makefile は、システムから独立したプロトタイプ・ファイルをシステム特定型の構成ファイルにコンパイルするために使用されます。ユーザーのセル内での使用のためにこのファイルを変更するには、パッケージ Makefile ファイル を参照してください。

構成ファイルは、プロとタイプ・ファイルのコンパイルされたバージョンで、 function.sysname という名前で呼ばれています。構成ファイルは、etc サブディレクトリー内にも表示され、 パッケージプログラムがディスクを構成するときにアクセスします。

### lib ディレクトリー

lib ディレクトリーには、プロトタイプ・ファイル内で参照されたサンプル・ライブラリー・ファイルの多くが含まれます。たとえば、base.generic ファイルは、システムから独立したファイルで、セル名、システム・オプションおよび変数の各定義が組み込まれています。これらは、そのファイル内の owner、group、および mode_bits フィールド、およびシンボリック・リンクの定義の設定に使用されます。

### etc ディレクトリー

etc ディレクトリーには、src サブディレクトリー内のプロトタイプ・ファイルから作成された、システム特定型の構成ファイルが含まれます。 パッケージ・プログラムは、 etc ディレクトリー内の構成ファイルを使用して、ディスクを構成します。

いくつかのサンプル・ファイルには、異なるシステム・タイプ用にコンパイルされた、minimal、および staff プロトタイプ・ファイルが組み込まれています。

## サンプル・プロトタイプ・ファイルおよびライブラリー・ファイル

プロトタイプ・ファイルは、クライアントのローカル・ディスクの構成を定義するテンプレートです。プロトタイプ・ファイルは、通常、機能特定型のファイル (たとえば、バックアップ・マシン、プリント・サーバーなど) ですが、システム独立型のファイルです。プロトタイプ・ファイルは、 `ifdef` ステートメントおよび変数をサポートしますので、システム特定型の定義を組み込むことができます。実際のシステム特定型の構成ファイルは、そのプロトタイプ・ファイルがコンパイルされるときに生成されます。

プロトタイプ・ファイル内に定義されているコンポーネンツは、プリント・サーバーあるいはバックアップ・マシンのような特定の役割を実行するために、クライアントのローカル・ディスク上に常駐している必要のあるディレクトリー、ファイル、シンボリック・リンク、ブロック・スペシャル・デバイス、キャラクター型スペシャル・デバイス、およびソケットを組み込むことができます。そのため、それぞれの異なるクライアント機能ごとに固有のプロトタイプ・ファイルを構成することをお勧めします。

パッケージ・プログラムをより有効に、かつ保守を簡単にするために、特定のプロトタイプ・ファイルではなく、モジュラーで汎用的なプロトタイプ・ファイルを作成します。

- 汎用ライブラリー・ファイルを作成することによって、たくさんのプロトタイプ・ファイル内に同じライブラリー・ファイルを組み込むことができます。そのため、1 つのライブラリー・ファイルを変更することで、グローバルな構成変更を行うことができます。プロトタイプ・ファイルを個々に変更する必要はありません。
- 変数は、その変数の値を変更することで、定義を変更することができます。

### サンプル・プロトタイプ・ファイル

以下は、AFS を実行するのに必要な最低限の定義を含むサンプル・プロトタイプ・ファイルの一部です。 minimal.proto と呼ばれる類似ファイルが、src サブディレクトリーに常駐している場合があります。推奨されているように、このプロトタイプ・ファイルはライブラリー・ファイルを参照するのであって、実際の定義が組み込まれているのではありません。

                .
                .
       # Package prototype for a minimal configuration.
       # Base components
       %include ${wsadmin}/lib/base.generic
       # Machine-specific components
       %ifdef rs_aix42
       %include ${wsadmin}/lib/rs_aix42.readonly
       %include ${wsadmin}/lib/rs_aix42.AFS
       %endif rs_aix42
       %ifdef alpha_dux40
       %include ${wsadmin}/lib/alpha_dux40.readonly
       %include ${wsadmin}/lib/alpha_dux40.AFS
       %endif alpha_dux40
       %ifdef sun4x_56
       %include ${wsadmin}/lib/sun4x_56.readonly
       %include ${wsadmin}/lib/sun4x_56.AFS
       %endif sun4x_56
                .
                .

上記サンプルのコメントのない第 1 行目には、/lib/base.generic ライブラリー・ファイルが組み込まれます。このライブラリー・ファイルには、多くのプロトタイプ・ファイルに適した定義が含まれている場合があります。 base.generic ライブラリー・ファイルも、staff.proto あるいは backup.proto のように、他のプロトタイプ・ファイルに組み込まれている場合があります。サンプル・ライブラリー・ファイルは、次の機能グループに記載されています。

システム特定型の定義は、`ifdef` 文および変数 (たとえば、`${wsadmin}` を使用してパス名を指定します) を使用した場合に許可されているので注意が必要です。したがって、異なるファイル、ディレクトリー、シンボリック・リンク、およびデバイスが必要な場合でも、 AIX 4.2 あるいは Solaris 2.6 を実行しているマシンを同じプロとタイプ・ファイルを使用して構成することができます。

このサンプルの、コメントのない次の行には、管理者が異なるシステム・タイプの異なるライブラリー・ファイルを構成してあります。これらはそれぞれ、固有の構成ファイルにコンパイルされます。たとえば、このプロトタイプ・ファイルの下記の行は、値 `rs_aix42` が宣言されたら、構成ファイル用にライブラリー・ファイル lib/rs_aix42.readonly および lib/rs_aix42.AFS を使用するようパッケージ・プログラムに伝えます。 (システム・タイプの定義は、Makefile で宣言されます。パッケージ Makefile ファイル を参照してください。)

       %ifdef rs_aix42
       %include ${wsadmin}/lib/rs_aix42.readonly
       %include ${wsadmin}/lib/rs_aix42.AFS
       %endif rs_aix42

同様に、下記の行は、値 `sun4x_56` が宣言されたら、ライブラリー・ファイル lib/sun4x_56.readonly および lib/sun4x_56.AFS を使用するよう パッケージ・プログラムに伝えます。

       %ifdef sun4x_56
       %include ${wsadmin}/lib/sun4x_56.readonly
       %include ${wsadmin}/lib/sun4x_56.AFS
       %endif sun4x_56

### サンプル・ライブラリー・ファイル

以下は、基本的な構成定義のためのサンプル・ライブラリー・ファイルの一部です。base.genericと呼ばれる類似ファイルが、lib サブディレクトリーに常駐している場合があります。構成は、標準の `ifdef` ステートメントを使用して定義されますので、ご注意ください。

                .
                .
       #
       # Base package definitions.
       #
       %ifndef	cell
       %define	cell	abc.com
       %endif	cell
       %ifndef	sys
       %include /etc/package.sys
       %endif	sys
       %define	${name}		${name}
       %define	${cpu}		${cpu}
       %define	${sys}		${sys}
       %define	${dept}		${dept}
       %define	${hostname}	${hostname}
       %ifdef	rs_aix42
       %	define 	AIX
       %	define	rootlinks
       %ifndef	noafsd
       %	define	afsd
       %endif	noafsd
       %endif	rs_aix42
                .
                .
       #
       # Some definitions to handle common combinations of owner, group,
       # and protection fields.
       #
       %define	rzmode		root wheel 600
       %define	usermode	root wheel 666
       %define      systemmode	root wheel 644
       %define	diskmode	root wheel 644
       %define	ptymode		root wheel 666
       %define	ttymode		root wheel 666
                .
                .
       %define aix_rootbin	   root bin
       %define aix_rootprintq  root printq
       %define aix_rootstaff   root staff
       %define aix_rootsys	   root system
       %define aix_binbin      bin bin
       %define aix_binmail	   bin mail
       %define aix_binsys	   bin system
       %define aix_addsys	   adduser system
       %define aix_romode	   444
       %define aix_loginmode   544
       %define aix_usermode	   666
       %define aix_systemmode  644
       %define aix_textmode	   644
       %define aix_rwmode1	   660
       %define aix_allrugw	   664

以下のサンプル・ライブラリー・ファイルは、パッケージ特定型の構文を使用して、ファイル、ディレクトリー、ソケットなどを定義しています。構成ファイル行と呼ばれる各行は、ディスク構成の、ある特定のコンポーネントを定義します。この命令の正しい構文は、 パッケージ構成ファイル命令の構文 に簡単に記載されています。詳細は、AFS Administration Reference のパッケージ構成ファイルを参照してください。

このサンプルでは、ライブラリー・ファイルに、 rs_aix42 マシンの構成特有の命令が含まれています。ユーザーの lib サブディレクトリーに類似のライブラリー・ファイルがある場合があります。

                .
                .
       #
       # Generic configuration for an AFS rs_aix42 machine.
       #
       D	/                                       ${treemode}
       D	/afs
       FAQ	/unix	       ${machine}/unix.std 	${binmode}
       LA	/unix.std	/unix
       D	/bin					${treemode}
       F	/bin/as		${machine}		${binmode}
       F	/bin/ld		${machine}		${binmode}
       F	/bin/nm		${machine}		${binmode}
       FO	/bin/login	${afstest}		${suidmode}
                .
                .
       FAQ  /usr/vice/etc/ThisCell  ${common}/etc/ThisCell ${textmode}
       FQ	/usr/vice/etc/afsd      ${afstest}/root.client ${binmode}
       FA	/usr/vice/etc/bos       ${afstest}/bin/bos     ${binmode}
       FA	/usr/vice/etc/fs        ${afstest}/bin/fs      ${binmode}

## パッケージ構成ファイル命令の構文

ライブラリー・ファイル内では、構成ファイル命令は、特定のディスク構成の定義に使用されます。各命令は、クライアント・マシン上のファイル、ディレクトリー、ソケット、あるいはデバイスの定義に使用することができます。各有効命令タイプの構文は、ここに簡単に記載されています。フィールドの詳細記述については、 AFS コマンド解説書 に記載されています。

- D は、ディレクトリーを定義
- F は、ファイルを定義
- L は、リンクを定義
- B は、ブロック・スペシャル・デバイスを定義
- C は、キャラクター型スペシャル・デバイスを定義
- S は、ソケットを定義

注: | それぞれの構成命令は、単一行に改行なしで配置しなくてはなりません。ここで複数行にわたって現れる命令がありますが、これは単に読みやすくするためです。 構成ファイルは、完全に正しいものである必要があります。構文エラーや誤った値があると、 package コマンド・インタープリターは命令を実行せずに終了します。

### ローカル・ファイル対シンボリック・リンク

AFS 分散ファイル・システムの利点を生かすために、ローカル・クライアント・ディスク上のファイル数を最小限に抑えることをお勧めします。代わりに、AFS へと指しているシンボリック・リンクを作成します。こうすることによって、キャッシングおよびスワッピングのスペースを広げ、マシンのパフォーマンスを向上させます。

しかし、いくつかのファイルは、以下に記載されているように、ローカル・ディスク上に常駐しなければなりません。これらのファイルは、L (シンボリック・リンク) 命令ではなく F (ファイル) 命令を使用して、プロトタイプ・ファイルまたはライブラリー・ファイル内に作成してください。

以下のタイプのファイルは、すべての AFS クライアントのローカル・ディスク上に常駐していなければなりません。

- afsd プログラムの実行前に実行されたブート・シーケンス・ファイル。

  afsd が実行され、キャッシュ・マネージャーが初期化されるまで、AFS はクライアントからアクセスできません。afsd より前に実行されるファイルはいずれも、ローカル・クライアント・ディスク上に常駐していなければなりません。

  たとえば、ディスク・キャッシュを使用するマシンの場合、 /usr/vice/cache ディレクトリーは、キャッシュ・マネージャーを立ち上げる際には、キャッシュ・ファイルのロケーションの確保のために必ず存在していなければなりません。バイナリー・ファイル /etc/mount および /etc/umount は、マシンがブートする際にローカル・ディスク上で使用可能な状態である必要があり、 /usr/vice/cache ディレクトリーがマウントできるようにします。

  また、初期設定ファイル (/etc/rc またはこれに同等) およびファイル・システム・マッピング・ファイル (/etc/fstab またはこれに同等) など特定の UNIX ファイルは、ローカル・ディスク上に常駐していなければなりません。

- 診断および回復ファイル

  ある特定のコマンドが、ファイル・サーバーの故障が原因である問題の診断および回復に使用することができます。これらコマンドのバイナリーのコピーをローカル・ディスク上に配置しておくのがよいでしょう。たとえば、 bos および fs バイナリーをローカル・ディスクの /usr/vice/etc ディレクトリー、および /usr/afsws ディレクトリー (通常の構成における、 AFS へのシンボリック・リンク) に保管します。その上で、PATH 環境変数を設定し、 /usr/afsws が/usr/vice/etc の前に表示されるようにします。これにより、ユーザーが AFS にアクセスできない場合 (たとえば、ファイル・サーバー障害による)、bos および fs バイナリーのコピー (ローカル・ディスクの /usr/vice/etc にある) にアクセスすることができます。

- /usr/vice ディレクトリーのファイル

  cache サブディレクトリー内のキャッシュおよび etc サブディレクトリー内の構成ファイルを含む /usr/vice ディレクトリーの内容は、ローカル・ディスク上に常駐している必要がありますディレクトリー内のファイルの説明については、ローカル・ディスク上の構成ファイルおよびキャッシュ関連ファイル を参照してください。

### ディレクトリーの定義

D 命令は、ローカル・ディスク上に作成されるディレクトリーを定義します。シンボリック・リンク、ファイル、またはローカル・ディスクのその他の要素が同じ名前を持つ場合、これはディレクトリーに置き換えられます。ディレクトリーが既に存在する場合、その所有者、グループ、およびモード・ビットが、必要に応じて命令に適合するよう変更されます。

下記の命令を使用して、ディレクトリーを定義してください。

       D[update_code]   directory   owner   group   mode_bits

下の例は、/usr ディレクトリーを定義しています。

       D /usr root wheel 755

### ファイルの定義

F 命令は、ローカル・ディスク上に作成されるファイルを定義します。ソース・ファイルは、AFS 内あるいはローカル・ディスク内のいずれかに常駐することができます。

この名前のファイルがすでに存在する場合は、I 更新コードが指定されていない限り、そのファイルはソース・ファイルで更新 (上書き) されています。この名前のシンボリック・リンクあるいはディレクトリーが存在する場合は、パッケージがソース・ファイルと置き換えます。

注: | ファイルには、ローカル・ディスクに常駐しなければならないものがあります。これらは、シンボリック・リンクになることはできません。ローカル・ファイル対シンボリック・リンク を参照してください。

下記の命令を使用して、ファイルを定義してください。

       F[update_code]   file   source_file  [owner   group   mode_bits]

ソースとして /afs/abc.com/rs_aix42/bin/grep を使用して、ローカル・ディスク上にファイル /bin/grep を作成/更新する例。

       F /bin/grep /afs/abc.com/rs_aix42 root wheel 755

下の例では、2 つの更新コードが使用されており、owner 、group および mode_bits スロットが空です。そのため、そのディスク・ファイルはそれらのスロットにソース・ファイルの値を採用します。

       FAQ /usr/vice/etc/ThisCell /afs/abc.com/common/etc/ThisCell

### シンボリック・リンクの定義

L 命令は、ローカル・ディスク上に作成されるシンボリック・リンクを定義します。シンボリック・リンクは、AFS ファイル・システムまたはローカル・ディスクを指す場合があります。同一のシンボリック・リンクがすでに存在する場合、パッケージは何も行いません。しかし、同じ名前の要素がファイルまたはディレクトリーとしてディスク上に存在する場合は、 パッケージは、その要素をシンボリック・リンクと置き換えます。

注: | ファイルには、ローカル・ディスクに常駐しなければならないものがあります。これらは、シンボリック・リンクになることはできません。ローカル・ファイル対シンボリック・リンク を参照してください。

以下の命令を使用して、シンボリック・リンクを定義します。

       L[update_code]  link actual_file  [owner   group   mode_bits]

注: | 名前が番号記号 (#) またはパーセント記号 (%) で始まるファイルに対して、記号リンクを作成してはいけません。キャッシュ・マネージャーはこのようなリンクをそれぞれ標準の、または読み取り / 書き込みボリュームに対するマウント・ポイントと解釈します。

以下の例は、ローカル・ディスク上の /etc/ftpd から AFS 内の /afs/abc.com/hp_ux110/etc/ftpd へのシンボリック・リンクを作成します。owner、group および mode_bits の各フィールドが空のため、シンボリック・リンクはこれらのフィールドに実際のファイルから値を採用します。

       L /etc/ftpd /afs/abc.com/hp_ux110

この例は、A 更新コードを使用しています。

       LA /etc/printcap /afs/abc.com/common/etc/printcap.remote
                   root wheel 644

### ブロック・スペシャル・デバイスの定義

B 命令は、ブロック・スペシャル・デバイスを定義します。ブロック・スペシャル・デバイスは、ディスクのような、マルチバイト・ブロックのユニット内のデータを使用するデバイスです。同じ名前のデバイスがすでに存在する場合、 パッケージは、それを指定されたブロック・デバイスと置き換えます。

以下の命令を使用してブロック・スペシャル装置を定義します (ここでは読みやすくするため 2 行で表示します)。

       B device_name   major_device_number   minor_device_number  \
       owner   group   mode_bits

下の例は、/dev/hd0a と呼ばれるディスクのメジャー・デバイス番号およびマイナー・デバイス番号を 1 および 0 に定義しています。

       B /dev/hd0a 1 0 root wheel 644

### キャラクター型スペシャル・デバイスの定義

C 命令は、キャラクター型スペシャル・デバイスを定義します。これは、ターミナルまたは tty のような、一度に 1 つの文字のユニット内のデータを使用するデバイスです。同じ名前のデバイスがすでに存在する場合、パッケージは、それを指定されたキャラクター・デバイスと置き換えます。

以下の命令を使用してキャラクター型スペシャル・デバイスを定義します (ここでは読みやすくするため 2 行で表示します)。

       C device_name   major_device_number   minor_device_number  \
       owner   group   mode_bits

下記の例は、/dev/ttyp5 と呼ばれる tty のメジャー・デバイス番号およびマイナー・デバイス番号を 6 および 5 に定義しています。

       C /dev/ttyp5 6 5 root wheel 666

### ソケットの定義

S 命令は、ソケットを定義しています。ソケットは、UDP および TCP/IP 接続用の通信装置です。同じ名前のソケットがすでに存在する場合、パッケージは、それを置き換えます。

以下の命令を使用して、ソケットを定義してください。

       S   socket_name   [owner   group   mode_bits]

下の例は、/dev/printerと呼ばれるソケットを定義しています。

       S /dev/printer root wheel 777

## プロトタイプ・ファイルおよびライブラリー・ファイルの構成

この機能グループは、パッケージのプロトタイプ・ファイルおよびライブラリー・ファイルの作成に必要な、一般的なステップを説明しています。ガイドラインについては前章を、例についてはユーザーの wsadmin ディレクトリー内のファイルを参照してください。プロトタイプ・ファイルおよびライブラリー・ファイルの構造は、それぞれのセルごとに異なります。

### プロトタイプ・ファイルおよびそのコンポーネントのライブラリー・ファイルを構成するには

1. 3 つのパッケージ関連のサブディレクトリー (src、lib および etc) をセルのファイル・ツリーのどこに常駐させるかを決定します。以下の説明は、AFS インストールの手引き に記載されているように、3 つのサブディレクトリーが /afs/cellname/wsadmin ディレクトリーにロードされていることを前提としています。
2. セル内のクライアント・マシンにいくつの異なる機能を実行してほしいかを決定してください。それぞれの機能ごとに別々のプロトタイプ・ファイルを構成することをお勧めします。共通の機能には、以下が含まれます。
   - 標準ワークステーション: ユーザーに AFS 内ファイルへのアクセスを提供
   - プリンター・サーバー: プリンターを駆動する。「スタッフ機能」と結合する場合がある
   - バックアップ・マシン: AFS のバックアップ・システム・ソフトウェアを実行することにより、 AFS ボリュームのテープへのバックアップを実行する
3. すべてのクライアントに必要な最低限の機能 (AFS セットアップなど) を決定し、これらの汎用定義を 1 つ以上のライブラリー・ファイルに配置してください。
4. それぞれのクライアント (プリンター・サーバー、バックアップ・マシンなど) のタイプごとに、すべてのシステム独立型の定義を 1 つのファイルに配置し、すべてのオペレーティング・システム従属型の定義を別の 1 つのファイルに配置してください。

## パッケージ Makefile ファイル

適切なプロトタイプ・ファイルおよびライブラリー・ファイルを作成したら、必ずそのプロトタイプをシステム・タイプごとにコンパイルしなければなりません。結果は、システム特定型の構成ファイルとなります。

Makefile ファイルは、使用されているプロトタイプ・ファイルとライブラリー・ファイルの定義、およびコンパイルの順序の定義をします。この機能グループに記載されているように、 AFS に提供されているサンプルを変更することによってユーザーの Makefile を作成することをお勧めします。通常の構成では、これは /afs/cellname/wsadmin/src/Makefile に配置されています。

### 概説

以下のリストには、パッケージ Makefile ファイルの機能グループについて説明します。機能グループを開始するヘッダー名によりそれぞれを識別しています。詳細を以下に記します。

`CONFIG=`
  作成されるすべての構成ファイルをリストし、どのプロトタイプ・ファイルがどのシステム・タイプ用にコンパイルされるかを定義する。 CONFIG 機能グループ を参照してください。

`BASE_LIBS=`
  任意のプロトタイプ・ファイルに組み込まれているすべてのオペレーティング・システム独立型の、および機能独立型のライブラリー・ファイルのパス名をリストする。BASE_LIBS 機能グループ を参照してください。

`MACHINE_LIBS=`
  任意のプロトタイプ・ファイルに組み込まれているすべてのオペレーティング・システム特定型のライブラリー・ファイルのパス名をリストする。 MACHINE_LIBS 機能グループ を参照してください。

`LIBS=`
  `BASE_LIBS` および `MACHINE_LIBS` の組み合わせとして、`LIBS` を定義する 1 行命令。LIBS 機能グループ を参照してください。

`.SUFFIXES`
  プロトタイプ・ファイルまたは構成ファイル上に表示されるすべてのサフィックスを定義する。 .SUFFIXES 機能グループ を参照してください。

最後に、Makefile ファイルには、 パッケージ・プログラムが構成ファイルを生成するために従う命令セットが含まれます。この機能グループの変更は、一般に必要ありません。MAKE ファイルの命令機能グループ を参照してください。

### CONFIG 機能グループ

前述のように、構成ファイルは、特定のオペレーティング・システム・タイプ用にコンパイルされたプロトタイプ・ファイルです。 Makefile ファイルの `CONFIG` 機能グループは、どのプロトタイプ・ファイルをどのシステム・タイプ用にコンパイルするのかを定義します。結果として生じたコンパイル済みファイルは、システム特定型の構成ファイルです。

サンプルの Makefile ファイルから取った以下の例をよくお読みください。構成ファイルが、プロトタイプ・システムの組み合わせを prototype_file.sysname と指定して定義されています。プロトタイプ・システム・タイプの組み合わせごとに構成ファイルを生成する必要はありませんので、ご注意ください。

       #Makefile...
       #	(C) Copyright IBM Corporation 1999
       #	Licensed Materials - Property of IBM
       #	All Rights Reserved.
       #
       CONFIG = \
                staff.rs_aix42 \
                staff.alpha_dux40 \
                staff.xdm.alpha_dux40 \
                staff.sun4x_56 \
                staff.hp_ux110 \
                minimal.rs_aix42 \
                minimal.alpha_dux40 \
                minimal.hp_ux110 \
                minimal.sun4x_56

`CONFIG` 機能グループの項目は以下の形式をとります。

- 項目の最初の部分が、プロトタイプ・ファイルを定義しており、そのプロトタイプ・ファイルの名前 (拡張子 .proto は除く) と同じでなければなりません。入力の 2 番目の部分は、プロトタイプ・ファイルがコンパイルされるシステム・タイプを示しています。 .SUFFIXES 機能グループ に記載されているように、これらのサフィックスの完全なリストが、 Makefile ファイルの `.SUFFIXES` 機能グループにあります。この prototype_file.sysname 定義が、コンパイル済みの構成ファイルの名前になります。

  たとえば、staff.rs_aix42 は、 staff.proto ファイルが AIX 4.2 を実行しているマシン用にコンパイルされることを示しています。結果のコンパイル済み構成ファイルは、 staff.rs_aix42 と呼ばれます。

- 各構成ファイルは、必ず別々の行に表示されなければなりません。
- 最後を除いて、`CONFIG=` ヘッダーおよびすべての名前の後には円記号を付ける必要があります。円記号は、ブランク行にも必ず表示しなければなりません。

### BASE_LIBS 機能グループ

この機能グループでは、任意のプロトタイプ・ファイルに組み込まれているすべてのシステム独立型および機能独立型のライブラリー・ファイルの完全なパス名を定義します。 (システム特定型のライブラリー・ファイルは、 `MACHINE_LIBS` 機能グループに定義されています)。パス名には、 `${wsadmin}` 変数が組み込まれている場合があります。その値は、 make コマンド行に提供されています。

必ず、参照されているすべてのライブラリー・ファイルをプロトタイプ・ファイル内に組み込まなければなりません。組み込まれているファイルでも、使用されていないファイルは無視されます。

下の例をよくお読み下さい。すべての項目 (最後を除く) の後ろには、必ず円記号を付ける必要がありますので、ご注意ください。

       BASE_LIBS = \
    	   ${wsadmin}/src/admin \
    	   ${wsadmin}/lib/devel \
    	   ${wsadmin}/lib/base.generic

### MACHINE_LIBS 機能グループ

この機能グループは、プロトタイプ・ファイル内のすべてのオペレーティング・システム特定型のライブラリー・ファイルの完全なパス名をリストしています。 (システム独立型および機能独立型のライブラリー・ファイルは、 `BASE_LIBS` 機能グループに定義されています。)

下の例をよくお読み下さい。この例では、ライブラリー・ファイルがオペレーティング・システム・タイプによってグループ化されています。ここでも、すべての行 (最後を除く) の後ろには、必ず円記号が付いていなければなりません。 `${wsadmin}` 変数が許可されています。また、組み込まれているファイルでも使用されていないファイルは無視されます。

       MACHINE_LIBS = \
               ${wsadmin}/lib/rs_aix42.generic \
               ${wsadmin}/lib/rs_aix42.generic.dev \
               ${wsadmin}/lib/rs_aix42.readonly \
               ${wsadmin}/lib/rs_aix42.readwrite \
               ${wsadmin}/lib/rt_aix42.generic.printer \
        \
        .
        .
               ${wsadmin}/lib/alpha_dux40.AFS \
               ${wsadmin}/lib/hp_ux110.AFS \
               ${wsadmin}/lib/sun4x_56.AFS \
               ${wsadmin}/lib/rs_aix42.AFS

### LIBS 機能グループ

この機能グループには、1 つだけ命令が含まれています。その命令は、`LIBS` が、 `MACHINE_LIBS` および `BASE_LIBS` の組み合わせとして定義されていることを示しています。この行の後にブランク行を挿入して、この機能グループを次の行と分けてください。

       LIBS = ${MACHINE_LIBS} ${BASE_LIBS}

### .SUFFIXES 機能グループ

この機能グループでは、有効なマシン・タイプのサフィックスをリストします。このリストには、現在 AFS でサポートされているシステム・タイプが含まれます。未使用のサフィックスは無視されます。

       .SUFFIXES: .rs_aix42 \
                  .alpha_dux40 \
                  .proto \
                  .sun4x_56 \
                  .i386_linux22 \
                  .hp_ux110

### MAKE ファイルの命令機能グループ

Makefile ファイルの残りの部分では、 package プログラムによる構成ファイルの作成を制御します。

下の例をよくお読みください。ユーザーが、プログラミングおよび Makefile の概念に通じていることを前提としています。

       #The following appear on a single line each in the actual file
       .proto.rs_aix42: ;  mpp -Dwsadmin=${wsadmin} -Dsys=rs_aix42
                               -Dname=$* $*.proto > $@
       .proto.alpha_dux40: ; mpp -Dwsadmin=${wsadmin} -Dsys=alpha_dux40
                               -Dname=$* $*.proto > $@
       .proto.sun4x_56:  ; mpp -Dwsadmin=${wsadmin} -Dsys=sun4x_56
                               -Dname=$* $*.proto > $@
       .proto.hp_ux110:  ; mpp -Dwsadmin=${wsadmin} -Dsys=hp_ux110
                               -Dname=$* $*.proto > $@
       all: ${CONFIG}
       ${CONFIG}: ${LIBS}
       system: install
       install: ${CONFIG}
    	   cp ${CONFIG} ${wsadmin}/etc
       clean:
    	   rm -f ${CONFIG} *.BAK *.CKP

## MAKE ファイルの変更

以下のような場合に、パッケージ Makefile ファイルを変更します。

- 新規のプロトタイプ・ファイル (function.proto) を追加する。
- 新規のシステム・タイプを追加する。
- 新規のライブラリー・ファイルを追加する。

これらの理由で Makefile ファイルを変更する方法の簡単な例を、以下の機能グループで提供します。

### 新規のプロトタイプ・ファイルの追加

新規のプロトタイプ・ファイルを作成する場合、そのファイル名および Makefile ファイルの `CONFIG` 機能グループに新規のプロトタイプ・ファイルが構築される各システム・タイプを追加していください。

たとえば、 alpha_dux40 および hp_ux110 用の function.proto を追加するには、以下の項目を `CONFIG` 機能グループに追加します。

       CONFIG = \
       ...
               function.alpha_dux40 \
               function.hp_ux110 \
       ...

このプロトタイプ機能に新規のライブラリー・ファイルを追加した場合、それらを `MACHINE_LIBS` 機能グループに追加します。

### 新規のシステム・タイプの追加

新規のシステム・タイプ用に作成したいそれぞれのプロトタイプ・ファイルごとに、項目を `CONFIG` 機能グループに追加してください。任意の新規ライブラリーを `MACHINE_LIBS` 機能グループに、また、その新規のシステム・タイプを `.SUFFIXES` 機能グループに追加します。

以下の例は、この新規のシステム・タイプ用の staff および minimal プロトタイプ・ファイルを作成する際に適切な変更を示しています。

       CONFIG = \
       ...
               staff.sysname \
               minimal.sysname \
       ...

この新規のマシン・タイプに対応するライブラリー・ファイルが作成されている場合は、それらを `MACHINE_LIBS` 機能グループに追加します。

       MACHINE_LIBS = \
       ...
               ${wsadmin}/lib/sysname.generic \
               ${wsadmin}/lib/sysname.generic.dev \
               ${wsadmin}/lib/sysname.readonly \
               ${wsadmin}/lib/sysname.readwrite \
       ...

新規のシステム・タイプを `SUFFIXES` 機能グループに追加します。

       .SUFFIXES: ...\
                .sysname \
       ...

このシステムのための構成ファイルを構築するための行を、構成ファイルを構築するための残りのコマンドのある機能グループに追加してください。

       .proto.sysname: ; mpp -Dwsadmin=${wsadmin} \
       -Dsys=sysname  -Dname=$* $*.proto > $

### 新規のライブラリー・ファイルの追加

システム・タイプごとに新規のライブラリー・ファイルを追加する場合は (sysname.library_file)、これらのファイルを Makefile ファイルの MACHINE_LIBS 機能グループに追加します。

       MACHINE_LIBS = \
       ...
               ${wsadmin}/lib/rs_aix42.library_file \
       ...
               ${wsadmin}/lib/alpha_dux40.library_file \
       ...
               ${wsadmin}/lib/sun4x_56.library_file \
       ...

すべてのシステム・タイプに共通の新規のライブラリー・ファイルを追加する場合は (library_file)。これを `BASE_LIBS` 機能グループにのみ追加してください。

       BASE_LIBS = \
       ...
               ${wsadmin}/lib/library_file \
       ...

## プロトタイプ・ファイルのコンパイル

パッケージ・プログラムは、構成ファイルを生成し、 make コマンド行で wsadmin= と指定されるディレクトリーの etc および src サブディレクトリーにこれを導入します。プロトタイプ・ファイルまたはライブラリー・ファイルを変更する場合は、必ず再コンパイルしてください。

### プロトタイプ・ファイルをコンパイルするには

注: | 以下の説明では、パッケージ関連のファイルが /afs/cellname/wsadmin ディレクトリーに格納されていることを前提としています。別のディレクトリーを使用する場合は、その名前を /afs/cellname/wsadmin に置き換えてください。

1. /afs/cellname/wsadmin ディレクトリー、およびその src、lib および etc サブディレクトリーの特権を所有しているか確認します。必要があれば、fs listacl コマンドを発行します。

          % fs listacl [dir/file path]

2. /afs/cellname/wsadmin/src サブディレクトリーに変更します。

          % cd /afs/cellname/wsadmin/src

3. AFS に含まれる Makefile ファイルのバックアップ・コピーを作成します。

          % cp  Makefile Makefile.example

4. Makefile ファイルの `CONFIG`、 `BASE_LIBS` および `MACHINE_LIBS` 機能グループを変更します (CONFIG 機能グループ、BASE_LIBS 機能グループ、および MACHINE_LIBS 機能グループ を参照)。
5. make コマンドを使用して、プロトタイプ・ファイルをコンパイルします。

   wsadmin= 引き数を使用して、パッケージディレクトリーを指定します。これは、プロトタイプ・ファイルおよびライブラリー・ファイルの `${wsadmin}` 変数の値になります。

   パッケージ・プログラムは、構成ファイルを生成し、 wsadmin= ディレクトリーの etc および src サブディレクトリーにこれを導入します。

          % make system wsadmin=/afs/cellname/wsadmin

## クライアント・マシンの変更

クライアントが パッケージ・プログラムを自動的に実行するようにするには、以下のステップに従います。指示は、システム固有の構成ファイルを参照しないので、一般的なものです。必要であれば、 AFS Administration Reference に記載されているように、パッケージ・プログラムを特定の引き数で起動することもできます。

1. 使用する構成ファイルの指定

   クライアント・マシンのルート (/) ディレクトリーにある .package ファイルは、 パッケージ・コマンドへの引き数として指定変更されます。 .package ファイルは、 パッケージがどの構成ファイルを使用するか指定します。

2. ローカル・ディスクにコピーするか、あるいは AFS へのシンボリック・リンクを作成して、 パッケージ・バイナリーをクライアントに対して使用可能にします。
   - シンボリック・リンクは、ローカル・ディスクのスペースを節約します。しかし、ローカル・ディスクを格納しているファイル・サーバー・マシンがダウンすると、 パッケージ・バイナリーは、アクセス不能になります。
   - パッケージ・バイナリーをローカル・ディスクに置くことにより、ファイル・サーバーがダウンしていても パッケージ・プログラムを実行することができます。しかし、ファイル・サーバー・マシンが故障すると、ほとんどの構成ファイルの命令が AFS 内のファイルを参照するため、パッケージの実行が難しくなります。 パッケージ・バイナリーのローカル・コピーは、命令で参照されるファイルが複写ボリュームにある場合に便利です。
3. クライアント・マシンの初期設定ファイルを変更して、ブート時にパッケージ・プログラムを起動します。 パッケージ・プログラムが、 Q 更新コードの付いている任意のファイルを更新すると、そのクライアントは再度リブートします。

### パッケージ・プログラムを実行してクライアント・マシンを準備する

パッケージを実行するすべてのクライアント上で、以下に示した命令を繰り返してください。

下記の命令は、パッケージ構成ファイル (プロトタイプ・ファイルがコンパイルされたときに作成された) が、 /afs/cellname/wsadmin/etc に常駐していることを前提としています。

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. .package ファイルを、ルート ( /) ディレクトリーに作成し、使用するプロトタイプ・ファイルの名前を指定します。システム・タイプのサフィックス (.rs_aix42 など) は組み込まないでください。 パッケージ・プログラムは自動的に正しいのマシン・タイプを決定します。

          # echo "/afs/cellname/wsadmin/etc/config_file" >> /.package

   たとえば、クライアントをスタッフ・マシンのメンバーに構成したい場合は (適切なプロトタイプ・ファイルが、そのシステム・タイプ用に定義およびコンパイルされていることを前提として)、適当なコマンドは以下のようになります。

          # echo "/afs/cellname/wsadmin/etc/staff" >> /.package

3. パッケージ・バイナリーをローカル・ディスク上で /etc/package として使用可能にします。ファイルを作成したいか、またはシンボリック・リンクを作成したいかによって、下のコマンドのうちの 1 つを発行します。

   パッケージ・バイナリーをローカルに保管するには、以下のコマンドを入力します。

          # cp /afs/cellname/sysname/usr/afsws/etc/package   /etc/package

   シンボリック・リンクを作成するには、以下のコマンドを入力します。

          # ln -s /afs/cellname/sysname/usr/afsws/etc/package   /etc/package

4. afsd コマンドを起動した後に、下記の行を適切な初期設定ファイルに追加します。これがファイル・サーバー・マシンの場合、 bosserver コマンドは package コマンドに続けます。

   -v および -c オプションの使用を推奨します。-v フラグは詳細なトレースを作成し、 -c オプションは、構成ファイルのベース名にシステム・タイプを追加します。他のオプションの説明については、AFS Administration Reference を参照してください。

   注: | shutdown コマンドが、マシンをリブートするのに適切でない場合は、類似のコマンドに置き換える必要があります。

          if [ -f /etc/package ]; then
                  if [ -f /.package ]: then
                          /etc/package -v -c `cat /.package` >/dev/console
                  else
                          /etc/package -v >/dev/console
          fi
          case $? in
          0)
                  echo "Package completed successfully" >/dev/console 2>&1
                  date >/dev/console 2>&1
                  ;;
          4)
                  echo "Rebooting to restart system" >/dev/console 2>&1
                  echo >/fastboot
                  shutdown
                  ;;
          *)
                  echo "Update failed, continuing anyway" >/dev/console 2>&1
                  ;;
          esac
          fi

## パッケージ・プログラムの実行

プロトタイプ・ファイルの作成およびコンパイルと、クライアント・マシンの変更が終わったら、パッケージを実行する準備が整ったことになります。 package プログラムをマシンの AFS 初期化ファイルで呼び出して、リブート時に自動的に実行するのが最も簡単ですが、コマンド・シェル・プロンプトでもコマンドを発行できます。

構成ファイルは、完全に正しいものである必要があります。構文エラーや誤った値があると、プログラムは命令を実行せずに終了します。構成ファイルを検査するには、 package コマンドに -noaction および -debug フラグを付けてコマンド・シェル・プロンプトから発行します。これにより、実際に命令を実行せずに、潜在的な問題のリストが表示されます。

パッケージ・プログラムは、以下に示した一般規則に従います。完全な説明は、パッケージ構成ファイル命令の構文 にあります。

- パッケージは、R 更新コードがプロトタイプ・ファイル内で指定されない限り、ディスクからのいずれのファイルも削除しません。 R 更新コードが親ディレクトリーに関連している場合、パッケージは、構成ファイル内に指定されていないものはどれでも、ローカル・ディスクのディレクトリーから削除します。
- ローカル・ファイルが更新されるのは、ファイルが古い場合のみです。構成ファイルの F 命令ごとに、パッケージは、ローカル・ファイルの時間を指示されたソース・ファイルと比較します。ソース・ファイルの方がローカル・ファイルより新しい場合、そのファイルは更新されます。
- 初期設定ファイルが クライアント・マシンの変更 で推奨されているように変更されていると、 パッケージ・プログラムは、 Q 更新コードの付いている任意のファイルが更新されている場合、および パッケージ・プログラムが初期設定ファイルから起動されている場合に、ワークステーションを自動的にリブートします。Q 更新コードでマークされたファイルが変更すると、 パッケージ・プログラムは状況コード 4 で終了し、リブートします (初期設定ファイルに指示されているとおり)。変更が認識される前にリブートを必要とするファイル (オペレーティング・システム・カーネル、および /usr/vice/etc/CellServDB ファイル) は、構成ファイル内で Q 更新コードが付けられる必要があります。
- パッケージ・プログラムは、使用した構成ファイルを使用直後に /etc/package.sysname にコピーします。sysname がこのマシンのシステム・タイプを反映しています。パッケージ・コマンド・インタープリターは、ユーザーが構成ファイルの名前を提供していない場合、このファイルを照会します。ローカル・ディスクが構成されたか確認するには、その内容を検討します。

### リブートによるパッケージ・プログラムの起動

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. (推奨) 以下を確認します。
   - /.package ファイルが任意の構成ファイルを識別している
   - パッケージ・バイナリーが /etc/package として使用可能である。
   - 初期設定ファイルを正しく修正して、 パッケージ・プログラムを自動的に起動するようにしてある。
3. 適切なコマンドを使用して、マシンをリブートします。

          # shutdown

### パッケージ・プログラムを直接 (リブートせずに) 起動するには

1. まだの場合は、su コマンドを発行し、マシン上でローカル・スーパーユーザー root になります。

          % su root
          Password: root_password

2. 以下の確認します。
   - /.package ファイルが任意の構成ファイルを識別している
   - パッケージ・バイナリーが /etc/package として使用可能である。
   - 初期設定ファイルを正しく修正して、 パッケージ・プログラムを自動的に起動するようにしてある。
3. パッケージ・コマンドを発行します。

          # package  [initcmd]  [-config <base name of configuration file>]  \
           [-fullconfig <full name of configuration file, or stdin for standard input>]  \
           [-overwrite]  [-noaction]  [-verbose]  [-silent] [-rebootfiles]

   ここで、

   -config
     は、使用する構成ファイルのフルパス名を指定します。ファイルのベース名で終わるフルパス名で、マシン・タイプを示すサフィックスは省略されます。 パッケージが、マシンのタイプを決定する方法を覚えており、基本ファイル名の適切なバージョンを自動的に選択します。この引き数の適切な値の例は、staff.rs_aix42 ではなく、 staff です。パッケージに /.package を参照させて以下の値を提供することにより、その構成ファイルを覚えさせることも可能です。

     `cat /.package`

     この引き数は、 -fullconfig 引き数とは一緒に使用できません。

   -fullconfig
     使用する構成ファイルのフルネームを指定します。マシン・タイプの拡張子を付けて完全にします。例は、staff.rs_aix42 および minimal.hp_ux110 ファイルです。

     別の方法としては、 stdin があります。これは、発行元が標準入力経由で、パイプ接続されたファイルとして、または構成ファイルをキーボードからタイプ入力することによって、構成情報を提供することを示しています。 <Ctrl-d> を押して、入力を完了します。

     この引き数は、 -config 引き数とは一緒に使用できません。

   -overwrite
     最初の (owner) w (write) モード・ビットがファイルのローカル・ディスク・コピー上でオフになっていても、構成ファイルに指示されているソース・バージョンで、ローカル・ディスク上の要素を上書きします。 I 更新コードで保護されているファイルは、上書きされません。 F 命令の定義を参照してください。

   -noaction
     実際に実行するのではなく、コマンドの実行で起こりうる問題のトレースを、標準出力ストリームに表示します。-verbose フラグを追加した場合、トレースには、パッケージ・プログラムが試行したアクションも記録されます。

   -silent
     トレースのデフォルト・レベルを明示的に呼び出します。これには、コマンドを実行すると生ずる問題のリストのみが含まれます。

   -verbose
     標準出力ストリーム上で、コマンド・アクションの詳細トレースを生成します。トレースは、構成ファイル内の各要素の転送、および所有権 / モード・ビットの設定について報告します。

   -rebootfiles
     構成ファイル内で、Q 更新モードの付いた要素を上書きしないようにします。これにより、 パッケージ・プログラムが初期設定ファイルから起動した場合に、マシンが自動的にリブートしないようにできます。
4. Q コードでマークされたファイルが更新されたと思われる場合は、マシンをリブートします。このリブートは、自動的には起こりません。

[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]

(C) IBM Corporation 2000. All Rights Reserved